diff --git a/.agents/hooks/enforce-git-hygiene.sh b/.agents/hooks/enforce-git-hygiene.sh
new file mode 100755
index 000000000000..d125e2835bea
--- /dev/null
+++ b/.agents/hooks/enforce-git-hygiene.sh
@@ -0,0 +1,20 @@
+#!/bin/bash
+# PreToolUse hook for the Bash tool.
+# Blocks dangerous git patterns that cause CI failures.
+set -euo pipefail
+
+input=$(cat)
+command=$(echo "$input" | jq -r '.tool_input.command // empty')
+
+if [ -z "$command" ]; then
+  exit 0
+fi
+
+# Block 'git add .' / 'git add -A' / 'git add --all'
+# These stage package-lock.json and other generated files.
+if echo "$command" | grep -qE 'git\s+add\s+(\.|--all|-A)(\s|$|;)'; then
+  echo "BLOCKED: do not use 'git add .' / 'git add -A' / 'git add --all'. Stage files explicitly by name." >&2
+  exit 2
+fi
+
+exit 0
diff --git a/.agents/hooks/enforce-vendored.sh b/.agents/hooks/enforce-vendored.sh
new file mode 100755
index 000000000000..d7404d7c66e2
--- /dev/null
+++ b/.agents/hooks/enforce-vendored.sh
@@ -0,0 +1,25 @@
+#!/bin/bash
+# PreToolUse hook for Edit and Write tools.
+# Blocks edits to vendored content that must be fixed upstream.
+set -euo pipefail
+
+input=$(cat)
+file_path=$(echo "$input" | jq -r '.tool_input.file_path // empty')
+
+if [ -z "$file_path" ]; then
+  exit 0
+fi
+
+# Block edits to vendored Hugo modules.
+if echo "$file_path" | grep -qE '/_vendor/'; then
+  echo "BLOCKED: _vendor/ is vendored from upstream Hugo modules. Fix in the source repo instead." >&2
+  exit 2
+fi
+
+# Block edits to vendored CLI reference data.
+if echo "$file_path" | grep -qE '/data/cli/'; then
+  echo "BLOCKED: data/cli/ is generated from upstream repos (docker/cli, docker/buildx, etc.). Fix in the source repo instead." >&2
+  exit 2
+fi
+
+exit 0
diff --git a/.agents/settings.json b/.agents/settings.json
new file mode 100644
index 000000000000..f9a81de3a2e3
--- /dev/null
+++ b/.agents/settings.json
@@ -0,0 +1,27 @@
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash .agents/hooks/enforce-vendored.sh"
+          }
+        ],
+        "description": "Block edits to vendored content (_vendor/, data/cli/)"
+      },
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "if": "Bash(git add *)",
+            "command": "bash .agents/hooks/enforce-git-hygiene.sh"
+          }
+        ],
+        "description": "Block git add . and dangerous patterns"
+      }
+    ]
+  }
+}
diff --git a/.agents/skills/agent-readiness-audit/SKILL.md b/.agents/skills/agent-readiness-audit/SKILL.md
new file mode 100644
index 000000000000..afb2e56a3add
--- /dev/null
+++ b/.agents/skills/agent-readiness-audit/SKILL.md
@@ -0,0 +1,228 @@
+---
+name: agent-readiness-audit
+description: >
+  Audit a documentation site for agent-friendliness: discovery, markdown
+  delivery, crawlability, semantic structure, machine-readable surfaces,
+  and content legibility. Use when asked to assess docs.docker.com or any
+  docs site for AI/agent readiness, produce a scored report, compare with
+  external scanners, or generate a remediation list. Triggers on:
+  "audit docs for agent readiness", "how agent-friendly is docs.docker.com",
+  "score our docs for AI agents", "review llms.txt / markdown / crawlability",
+  "create an agent-readiness remediation plan".
+argument-hint: "<base-url>"
+---
+
+# Agent Readiness Audit
+
+Audit the live site, not the source tree alone. Prefer the same fetch path
+an external agent would use in the wild: direct HTTP requests, sitemap
+sampling, and page-level inspection.
+
+Do not reduce the result to a homepage-only scan or a binary checklist.
+
+## 1. Set scope
+
+Use `$ARGUMENTS` as the base URL when provided. Otherwise infer the base
+URL from context and state the assumption.
+
+Decide whether the host being audited is:
+
+- a docs-only host
+- an app/tool host
+- a mixed host
+
+This matters for optional checks such as MCP, plugin manifests, or other
+tool discovery files. Do not penalize a docs-only host for missing
+tooling manifests that belong on a separate service.
+
+For `docs.docker.com`, treat the public docs host as docs-only. Docker's
+MCP server is published separately, so missing MCP files on the docs host
+should be reported as `N/A`, not as a failure.
+
+## 2. Gather sitewide signals
+
+Always check these resources first:
+
+- `/llms.txt`
+- `/llms-full.txt`
+- `/robots.txt`
+- `/sitemap.xml`
+
+Only check host-level tool manifests when the host is an app/tool host,
+mixed host, or explicitly advertises them:
+
+- `/.well-known/ai-plugin.json`
+- `/.well-known/agent.json`
+- `/.well-known/agents.json`
+
+Use the bundled script for a baseline:
+
+```bash
+bash .agents/skills/agent-readiness-audit/scripts/baseline-probes.sh \
+  "$ARGUMENTS"
+```
+
+The script produces baseline evidence only. You still need to interpret
+what matters for a docs property and score it with the rubric.
+
+For docs-only hosts, you may skip tool-manifest probes to reduce noise:
+
+```bash
+CHECK_TOOL_MANIFESTS=0 \
+  bash .agents/skills/agent-readiness-audit/scripts/baseline-probes.sh \
+  "$ARGUMENTS"
+```
+
+## 3. Sample representative pages
+
+Use the sitemap when available. Do not rely on the homepage alone.
+
+If `llms.txt` exists, sample some URLs from it as well. This helps catch
+stale or misleading discovery surfaces that a sitemap-only sample would miss.
+
+Sample at least 12 pages when the site is large enough, and cover multiple
+page types:
+
+- homepage or docs landing page
+- section landing pages
+- task guides
+- product manuals
+- reference or API pages
+- tutorial or learning pages
+
+If the sitemap is missing or unusable, discover pages through internal
+links and note the lower confidence.
+
+If the site has distinct delivery patterns, sample each one. For example:
+
+- normal content pages
+- generated reference pages
+- versioned docs
+- localized docs
+
+## 4. Run fetch-path checks on each sample
+
+For each sampled page, verify:
+
+- HTML fetch status, content type, and final URL
+- `Accept: text/markdown` behavior
+- direct markdown route behavior such as `<page>.md` or another stable path
+- page-level markdown alternate links and whether they actually resolve
+- whether page actions such as "Open Markdown" agree with the working route
+- whether the HTML title or H1 matches the markdown H1 closely enough for
+  retrieval parity
+- whether main content is present in the initial HTML
+- redirect chain length and canonical URL consistency
+- obvious chrome/noise in the markdown response
+
+Do not assume a `.md` mirror exists just because another site uses one.
+Verify the actual markdown path the site exposes.
+
+Treat these as separate signals:
+
+- negotiated markdown works
+- a stable direct markdown URL works
+- the page advertises the correct markdown URL
+
+If the page advertises dead markdown alternates but a working markdown route
+exists, do not fail markdown delivery outright. Score it as a discoverability
+and consistency problem instead.
+
+For API or generated reference pages, also verify whether a machine-readable
+asset such as OpenAPI YAML is directly linked and fetchable.
+
+## 5. Judge structure and legibility
+
+Measure structural signals:
+
+- exactly one `h1`
+- sane heading hierarchy
+- `main` and `article` presence where appropriate
+- canonical tags
+- JSON-LD or breadcrumb structured data
+- stable anchors and deep-linkable headings
+
+Also make a qualitative judgment about agent legibility:
+
+- markdown strips site chrome cleanly
+- headings are specific and task-oriented
+- code blocks stay intelligible without client-side JS
+- the page is not dominated by banners, injected chat, or nav noise
+
+Measure code block labeling explicitly when code samples are common. A page
+type with many untagged fenced blocks should lose points even if the prose is
+otherwise clean.
+
+For page types that intentionally render interactive UIs with JavaScript,
+judge them separately from normal docs pages. If the HTML shell is thin,
+check whether the page still provides:
+
+- a fetchable markdown summary
+- a directly linked machine-readable asset
+- a usable non-JS fallback
+
+## 6. Score with the rubric
+
+Use [references/rubric.md](references/rubric.md).
+
+Rules:
+
+- score only what you verified
+- mark non-applicable checks as `N/A`
+- normalize the final score against applicable points only
+- do not let optional manifest checks dominate the grade
+
+Apply the foundational caps from the rubric. A site with broken discovery
+or broken markdown delivery should not earn a high grade because it has
+clean metadata.
+
+Do not average away a weak page type. If one major page type, such as API
+reference, is materially worse than the rest of the corpus, call it out as
+the weakest segment and reflect it in the category notes.
+
+## 7. Compare with external scanners when useful
+
+If external scanner results are available, compare them to your live
+findings. Treat them as secondary evidence.
+
+If a scanner and the live fetch disagree:
+
+- trust the live fetch
+- report the mismatch explicitly
+- explain whether the scanner is testing a different assumption
+
+## 8. Produce a remediation list
+
+Turn findings into a short backlog:
+
+- `P0`: fetchability or discovery blockers
+- `P1`: recurring structural or parity issues
+- `P2`: polish, optional manifests, or low-impact enhancements
+
+For each remediation, include:
+
+- the failing signal
+- why it matters to agents
+- a concrete fix
+- whether it is sitewide or page-type-specific
+
+## 9. Report in a stable format
+
+Use [references/report-template.md](references/report-template.md).
+
+Always include:
+
+- overall score and grade
+- confidence level
+- sampled URLs or sample strategy
+- category scores
+- highest-priority findings
+- remediation backlog
+
+## Notes
+
+- Favor docs-delivery checks over marketing-site heuristics.
+- Do not fail a docs host for lacking MCP or plugin manifests unless the
+  host itself is meant to expose tools.
+- Treat raw byte size as supporting evidence, not as a primary scoring input.
+- Prefer short evidence excerpts and commands over long copied page text.
diff --git a/.agents/skills/agent-readiness-audit/references/report-template.md b/.agents/skills/agent-readiness-audit/references/report-template.md
new file mode 100644
index 000000000000..e1592eb5054b
--- /dev/null
+++ b/.agents/skills/agent-readiness-audit/references/report-template.md
@@ -0,0 +1,63 @@
+# Agent Readiness Report Template
+
+Use this structure for final audit output.
+
+```markdown
+## Agent Readiness Audit
+
+**Site:** <base-url>
+**Date:** <YYYY-MM-DD>
+**Overall score:** <score>/100
+**Grade:** <A-F>
+**Confidence:** <High|Medium|Low>
+
+### Summary
+
+<2-4 sentence verdict focused on what an external agent can actually
+discover, fetch, and interpret on this site.>
+
+### Category Scores
+
+| Category | Score | Notes |
+| --- | ---: | --- |
+| Discovery and policy | <x>/<y> | <short note> |
+| Retrieval and markdown delivery | <x>/<y> | <short note> |
+| Structure and semantics | <x>/<y> | <short note> |
+| Crawlability and delivery behavior | <x>/<y> | <short note> |
+| Machine-readable surfaces | <x>/<y> | <short note or N/A> |
+| Content legibility | <x>/<y> | <short note> |
+
+### Sample
+
+- Sample strategy: <sitemap / internal links / explicit URLs>
+- Sampled pages: <count>
+- Page types covered: <landing, guide, manual, reference, ...>
+- Weakest page type: <if any>
+
+### Findings
+
+- `P0`: <highest-priority blocker with evidence>
+- `P1`: <important recurring issue with evidence>
+- `P2`: <lower-priority or optional improvement>
+
+### Remediation
+
+- `P0`: <fix>, because <why it matters to agents>
+- `P1`: <fix>, because <why it matters to agents>
+- `P2`: <fix>, because <why it matters to agents>
+
+### Evidence
+
+- Sitewide checks: <llms.txt, robots.txt, sitemap.xml, manifests>
+- Fetch-path checks: <markdown negotiation, direct markdown routes,
+  advertised alternates, parity>
+- Structural checks: <h1/main/article/canonical/json-ld/title-h1 parity>
+- Code block checks: <fence count, language-tag coverage>
+- Scanner comparison: <optional>
+```
+
+## Notes
+
+- Keep the summary short and outcome-oriented.
+- Findings should refer to concrete URLs or page types.
+- If a criterion is `N/A`, say why instead of leaving it blank.
diff --git a/.agents/skills/agent-readiness-audit/references/rubric.md b/.agents/skills/agent-readiness-audit/references/rubric.md
new file mode 100644
index 000000000000..51f089ed6135
--- /dev/null
+++ b/.agents/skills/agent-readiness-audit/references/rubric.md
@@ -0,0 +1,129 @@
+# Agent Readiness Rubric
+
+Score the site on a 100-point scale before normalization. If a criterion is
+not applicable, remove its points from the denominator instead of treating
+it as failed.
+
+## Grade bands
+
+- `A`: 90-100
+- `B`: 80-89
+- `C`: 65-79
+- `D`: 50-64
+- `F`: below 50
+
+## Confidence levels
+
+- `High`: sitemap available and at least 12 sampled pages across at least
+  four page types
+- `Medium`: six to 11 sampled pages, or weaker coverage of page types
+- `Low`: fewer than six sampled pages, or homepage-biased sampling
+
+## Foundational caps
+
+Apply these after computing the raw score:
+
+- No `sitemap.xml` and no `llms.txt`: maximum grade `C`
+- Markdown delivery fails on most sampled pages and no usable alternate
+  markdown path exists: maximum grade `D`
+- Main content is missing from initial HTML on more than 25% of sampled
+  pages: maximum grade `D`
+- `robots.txt` blocks broad crawl access to the docs site and the block is
+  not clearly intentional: maximum grade `F`
+
+Optional manifest gaps alone must not drop a docs-only host below `B`.
+
+## Categories
+
+### 1. Discovery and policy - 15 points
+
+- `5` `llms.txt` exists, is fetchable, and is useful for agent discovery
+- `4` `sitemap.xml` exists and includes the main docs corpus
+- `4` `robots.txt` is accessible and does not unintentionally block major
+  crawl agents or search agents
+- `2` curated bulk-discovery aid exists, such as `llms-full.txt` or an
+  equivalent machine-readable catalog
+
+When `llms.txt` exists, sample some URLs from it. Stale or misleading
+discovery links should reduce this category even if the file itself exists.
+
+### 2. Retrieval and markdown delivery - 25 points
+
+- `8` `Accept: text/markdown` works on sampled pages or an equivalent
+  negotiated markdown response exists
+- `5` a stable direct markdown route works on sampled pages
+- `5` page-level markdown hints, alternates, or UI actions point to a
+  working markdown URL
+- `4` markdown responses strip navigation chrome and preserve headings,
+  links, and code blocks cleanly
+- `3` HTML and markdown stay in parity across the sampled set
+
+### 3. Structure and semantics - 20 points
+
+- `6` sampled pages have one `h1` and a mostly consistent heading hierarchy
+- `5` `main` or `article` marks the primary content and the content is
+  present in the initial HTML
+- `4` canonical tags and stable final URLs are correct
+- `3` structured data such as breadcrumbs or article metadata exists where
+  appropriate
+- `2` headings expose stable anchors or deep-link targets, and the HTML title
+  or H1 stays reasonably aligned with the markdown H1
+
+### 4. Crawlability and delivery behavior - 15 points
+
+- `5` crawl directives are sane for a public docs property
+- `4` the site does not depend on client-side rendering to expose core
+  content
+- `3` cache and freshness signals are reasonable for bots, such as
+  `ETag`, `Last-Modified`, or useful cache headers
+- `3` redirect chains are short and predictable
+
+### 5. Machine-readable surfaces - 10 points
+
+- `4` API or reference sections expose OpenAPI, schema, or downloadable
+  machine-readable assets where relevant
+- `3` pages with interactive JavaScript reference UIs still provide a usable
+  non-JS fallback such as markdown, YAML, or another directly linked asset
+- `3` tool manifests such as MCP, plugin, or agent descriptors exist only
+  when the audited host is actually meant to expose tools
+
+### 6. Content legibility - 15 points
+
+- `5` markdown is clean and low-noise rather than a dump of site chrome
+- `4` headings and section intros are specific enough for retrieval and
+  chunking
+- `3` fenced code blocks are mostly language-tagged and remain copyable and
+  interpretable
+- `3` repeated banners, chat chrome, consent overlays, or other boilerplate
+  do not overwhelm the main content
+
+## Scoring guidance
+
+Use the full category only when the signal is consistently good across the
+sample. Partial credit is expected.
+
+Examples:
+
+- A sitewide `llms.txt` that exists but is stale or too shallow may earn
+  partial credit rather than full credit.
+- If markdown works only on some page types, score that criterion based on
+  observed coverage instead of failing or passing it outright.
+- If a working markdown route exists but the page advertises a dead
+  alternate URL, deduct in markdown discoverability rather than in raw
+  markdown availability.
+- If `llms.txt` exists but points to stale, broken, or inconsistent paths,
+  deduct in discovery rather than in core fetchability.
+- If tool manifests are irrelevant to the host, mark them `N/A`.
+- If a major page type is weaker than the rest of the site, note that
+  explicitly instead of letting stronger page types hide it in the average.
+
+## Reporting guidance
+
+For every category, include one line that explains the score:
+
+- what was tested
+- what passed
+- what limited the score
+
+Use evidence from live fetches. Do not score from assumptions about the
+framework or source repository.
diff --git a/.agents/skills/agent-readiness-audit/scripts/baseline-probes.sh b/.agents/skills/agent-readiness-audit/scripts/baseline-probes.sh
new file mode 100755
index 000000000000..50875aee068d
--- /dev/null
+++ b/.agents/skills/agent-readiness-audit/scripts/baseline-probes.sh
@@ -0,0 +1,287 @@
+#!/usr/bin/env bash
+
+set -euo pipefail
+
+if [[ $# -lt 1 ]]; then
+  echo "usage: $0 <base-url> [sample-url ...]" >&2
+  exit 1
+fi
+
+if ! command -v curl >/dev/null 2>&1; then
+  echo "curl is required" >&2
+  exit 1
+fi
+
+if ! command -v rg >/dev/null 2>&1; then
+  echo "rg is required" >&2
+  exit 1
+fi
+
+BASE_URL="${1%/}"
+shift || true
+SAMPLE_SIZE="${SAMPLE_SIZE:-12}"
+LLMS_SAMPLE_SIZE="${LLMS_SAMPLE_SIZE:-2}"
+CHECK_TOOL_MANIFESTS="${CHECK_TOOL_MANIFESTS:-1}"
+TMPDIR="$(mktemp -d)"
+trap 'rm -rf "$TMPDIR"' EXIT
+
+count_matches() {
+  local pattern="$1"
+  local file="$2"
+  rg -o "$pattern" "$file" 2>/dev/null | wc -l | tr -d ' ' || true
+}
+
+header_value() {
+  local header_file="$1"
+  local name="$2"
+  awk -F': ' -v target="$name" '
+    tolower($1) == tolower(target) { value = $2 }
+    END {
+      gsub(/\r/, "", value)
+      print value
+    }
+  ' "$header_file"
+}
+
+normalize_text() {
+  printf '%s' "$1" \
+    | tr '[:upper:]' '[:lower:]' \
+    | sed -E 's/[[:space:]]+/ /g; s/^[[:space:]]+//; s/[[:space:]]+$//; s/ \| docker docs$//'
+}
+
+code_fence_stats() {
+  local file="$1"
+  awk '
+    BEGIN { in_block = 0; total = 0; tagged = 0 }
+    /^```/ {
+      line = $0
+      sub(/^```[[:space:]]*/, "", line)
+      if (!in_block) {
+        total++
+        if (line != "") {
+          tagged++
+        }
+        in_block = 1
+      } else {
+        in_block = 0
+      }
+    }
+    END {
+      printf "%d\t%d\n", total, tagged
+    }
+  ' "$file"
+}
+
+resource_probe() {
+  local url="$1"
+  local label="$2"
+  local body="$TMPDIR/resource-body"
+  local headers="$TMPDIR/resource-headers"
+  local status
+  local content_type
+  local bytes
+
+  status="$(curl -sS -L -o "$body" -D "$headers" -w '%{http_code}' "$url" || true)"
+  content_type="$(header_value "$headers" "content-type")"
+  bytes="$(wc -c < "$body" | tr -d ' ')"
+
+  printf '%s\t%s\t%s\t%s\t%s\n' "$label" "$url" "$status" "$content_type" "$bytes"
+}
+
+page_probe() {
+  local url="$1"
+  local html="$TMPDIR/page-html"
+  local html_headers="$TMPDIR/page-html-headers"
+  local md="$TMPDIR/page-md"
+  local md_headers="$TMPDIR/page-md-headers"
+  local direct_md="$TMPDIR/page-direct-md"
+  local direct_md_headers="$TMPDIR/page-direct-md-headers"
+  local alt_md="$TMPDIR/page-alt-md"
+  local alt_md_headers="$TMPDIR/page-alt-md-headers"
+  local status
+  local content_type
+  local final_url
+  local h1_count
+  local main_count
+  local article_count
+  local canonical_count
+  local jsonld_count
+  local md_alt
+  local md_alt_url
+  local direct_md_url
+  local html_title
+  local html_h1
+  local md_h1
+  local md_status
+  local md_content_type
+  local md_bytes
+  local direct_md_status
+  local direct_md_content_type
+  local md_alt_status="na"
+  local md_alt_content_type="na"
+  local title_md_h1_match="no"
+  local html_h1_md_h1_match="no"
+  local code_blocks_total
+  local code_blocks_tagged
+
+  status="$(
+    curl -sS -L -o "$html" -D "$html_headers" \
+      -w '%{http_code}\t%{url_effective}' "$url" || true
+  )"
+  content_type="$(header_value "$html_headers" "content-type")"
+  final_url="${status#*$'\t'}"
+  status="${status%%$'\t'*}"
+
+  h1_count="$(count_matches '<h1[ >]' "$html")"
+  main_count="$(count_matches '<main[ >]' "$html")"
+  article_count="$(count_matches '<article[ >]' "$html")"
+  canonical_count="$(count_matches 'rel=canonical' "$html")"
+  jsonld_count="$(count_matches 'application/ld\+json' "$html")"
+  md_alt="$(
+    rg -o 'type=text/markdown href=[^ >]+|href=[^ >]+[^>]*type=text/markdown' \
+      "$html" -m 1 2>/dev/null | sed -E 's/.*href=([^ >]+).*/\1/' || true
+  )"
+
+  md_status="$(curl -sS -L -H 'Accept: text/markdown' -o "$md" -D "$md_headers" -w '%{http_code}' "$url" || true)"
+  md_content_type="$(header_value "$md_headers" "content-type")"
+  md_bytes="$(wc -c < "$md" | tr -d ' ')"
+  direct_md_url="$(printf '%s' "$final_url" | sed 's#/$##').md"
+  direct_md_status="$(curl -sS -L -o "$direct_md" -D "$direct_md_headers" -w '%{http_code}' "$direct_md_url" || true)"
+  direct_md_content_type="$(header_value "$direct_md_headers" "content-type")"
+  html_title="$(rg -o '<title>[^<]+' "$html" -m 1 2>/dev/null | sed 's/<title>//' || true)"
+  html_h1="$(rg -o '<h1[^>]*>[^<]+' "$html" -m 1 2>/dev/null | sed -E 's/<h1[^>]*>//' || true)"
+  md_h1="$(awk '/^# / { sub(/^# /, ""); print; exit }' "$md" || true)"
+
+  if [[ -n "$html_title" && -n "$md_h1" ]]; then
+    if [[ "$(normalize_text "$html_title")" == "$(normalize_text "$md_h1")" ]]; then
+      title_md_h1_match="yes"
+    fi
+  fi
+
+  if [[ -n "$html_h1" && -n "$md_h1" ]]; then
+    if [[ "$(normalize_text "$html_h1")" == "$(normalize_text "$md_h1")" ]]; then
+      html_h1_md_h1_match="yes"
+    fi
+  fi
+
+  IFS=$'\t' read -r code_blocks_total code_blocks_tagged < <(code_fence_stats "$md")
+
+  if [[ -n "$md_alt" ]]; then
+    if [[ "$md_alt" =~ ^https?:// ]]; then
+      md_alt_url="$md_alt"
+    elif [[ "$md_alt" == /* ]]; then
+      md_alt_url="${BASE_URL}${md_alt}"
+    else
+      md_alt_url="${BASE_URL}/${md_alt}"
+    fi
+    md_alt_status="$(curl -sS -L -o "$alt_md" -D "$alt_md_headers" -w '%{http_code}' "$md_alt_url" || true)"
+    md_alt_content_type="$(header_value "$alt_md_headers" "content-type")"
+  else
+    md_alt_url="na"
+  fi
+
+  printf '%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\n' \
+    "$url" \
+    "$status" \
+    "$content_type" \
+    "$final_url" \
+    "$h1_count" \
+    "$main_count" \
+    "$article_count" \
+    "$canonical_count" \
+    "$jsonld_count" \
+    "$md_status" \
+    "$md_content_type" \
+    "$md_bytes" \
+    "$direct_md_url" \
+    "$direct_md_status" \
+    "$direct_md_content_type" \
+    "$md_alt_url" \
+    "$md_alt_status" \
+    "$md_alt_content_type" \
+    "$title_md_h1_match" \
+    "$html_h1_md_h1_match" \
+    "$code_blocks_total" \
+    "$code_blocks_tagged"
+}
+
+llms_urls() {
+  local llms="$TMPDIR/llms-sample.txt"
+  local llms_status
+
+  llms_status="$(curl -sS -L -o "$llms" -w '%{http_code}' "$BASE_URL/llms.txt" || true)"
+  if [[ "$llms_status" == "200" ]]; then
+    rg -o '\(https?://[^)]+\)' "$llms" 2>/dev/null \
+      | tr -d '()' \
+      | rg "^${BASE_URL//./\\.}" \
+      | rg -v '/404\.html$|/search/?$|\.xml$|\.txt$' \
+      | awk -v limit="$LLMS_SAMPLE_SIZE" '!seen[$0]++ && NR <= limit { print }'
+  fi
+}
+
+sitemap_urls() {
+  local sitemap="$TMPDIR/sitemap.xml"
+  local sitemap_status
+
+  sitemap_status="$(curl -sS -L -o "$sitemap" -w '%{http_code}' "$BASE_URL/sitemap.xml" || true)"
+  if [[ "$sitemap_status" == "200" ]]; then
+    rg -o '<loc>[^<]+' "$sitemap" \
+      | sed 's/<loc>//' \
+      | rg "^${BASE_URL//./\\.}" \
+      | rg -v '/404\.html$|/search/?$|\.xml$|\.txt$' \
+      | awk '!seen[$0]++ { print }'
+  fi
+}
+
+sample_urls() {
+  if [[ $# -gt 0 ]]; then
+    printf '%s\n' "$@"
+    return
+  fi
+
+  local sample_file="$TMPDIR/sampled-urls.txt"
+
+  {
+    llms_urls
+    sitemap_urls
+  } | awk -v limit="$SAMPLE_SIZE" '
+    !seen[$0]++ {
+      print
+      count++
+      if (count >= limit) {
+        exit
+      }
+    }
+  ' > "$sample_file"
+
+  if [[ ! -s "$sample_file" ]]; then
+    printf '%s/\n' "$BASE_URL"
+  else
+    cat "$sample_file"
+  fi
+}
+
+printf 'META\tbase-url\t%s\n' "$BASE_URL"
+if [[ $# -gt 0 ]]; then
+  printf 'META\tsample-source\texplicit\n'
+else
+  printf 'META\tsample-source\tllms-and-sitemap-or-homepage\n'
+fi
+printf '\nSITEWIDE\n'
+printf 'label\turl\tstatus\tcontent-type\tbytes\n'
+resource_probe "$BASE_URL/llms.txt" "llms.txt"
+resource_probe "$BASE_URL/llms-full.txt" "llms-full.txt"
+resource_probe "$BASE_URL/robots.txt" "robots.txt"
+resource_probe "$BASE_URL/sitemap.xml" "sitemap.xml"
+if [[ "$CHECK_TOOL_MANIFESTS" == "1" ]]; then
+  resource_probe "$BASE_URL/.well-known/ai-plugin.json" "ai-plugin.json"
+  resource_probe "$BASE_URL/.well-known/agent.json" "agent.json"
+  resource_probe "$BASE_URL/.well-known/agents.json" "agents.json"
+fi
+
+printf '\nPAGES\n'
+printf 'url\tstatus\tcontent-type\tfinal-url\th1\tmain\tarticle\tcanonical\tjsonld\tmd-negotiate-status\tmd-negotiate-content-type\tmd-bytes\tmd-direct-url\tmd-direct-status\tmd-direct-content-type\tmd-alt-url\tmd-alt-status\tmd-alt-content-type\ttitle-md-h1-match\th1-md-h1-match\tcode-blocks-total\tcode-blocks-tagged\n'
+while IFS= read -r page_url; do
+  [[ -z "$page_url" ]] && continue
+  page_probe "$page_url"
+done < <(sample_urls "$@")
diff --git a/.agents/skills/create-lab-guide/SKILL.md b/.agents/skills/create-lab-guide/SKILL.md
new file mode 100644
index 000000000000..a1d559a026b5
--- /dev/null
+++ b/.agents/skills/create-lab-guide/SKILL.md
@@ -0,0 +1,115 @@
+---
+name: create-lab-guide
+description: "Clone a dockersamples Labspace repo, extract learning objectives and module structure from labspace.yaml, and produce a Hugo guide page under content/guides/ with correct frontmatter, labspace-launch shortcode, and Docker docs style compliance. Use when asked to create a lab guide, write a Labspace page, add a Docker lab tutorial, migrate a lab to docs, or document a hands-on lab."
+---
+
+# Create Lab Guide
+
+Create a guide page for a Docker Labspace: clone the source repo, extract
+structure from `labspace.yaml`, write the Hugo markdown page, and validate.
+
+## Inputs
+
+- **REPO_NAME**: GitHub repo in the `dockersamples` org (e.g. `labspace-ai-fundamentals`)
+
+## Step 1: Clone the labspace repo
+
+```bash
+TMPDIR=$(mktemp -d)
+git clone --depth 1 https://github.com/dockersamples/{REPO_NAME}.git "$TMPDIR/{REPO_NAME}"
+```
+
+## Step 2: Extract key information
+
+Read these files from the cloned repo:
+
+| File | Purpose |
+|------|---------|
+| `README.md` | Lab purpose and overview |
+| `labspace/labspace.yaml` | Module structure and content paths |
+| `labspace/*.md` | Module content (only files listed in `labspace.yaml`) |
+| `.github/workflows/*.yml` | Published Compose file URL for the launch command |
+| `compose.override.yaml` | Check for top-level `model` specs (triggers `model-download` param) |
+
+Extract:
+1. A short description for the `description` and `summary` frontmatter fields.
+2. Learning objectives from the module content.
+3. Whether a model download is required (`compose.override.yaml` → top-level `model` key).
+
+## Step 3: Write the guide markdown
+
+Place the file at `content/guides/lab-{GUIDE_ID}.md`.
+
+```markdown
+---
+title: "Lab: { Short title }"
+linkTitle: "Lab: { Short title }"
+description: |
+  A short description of the lab for SEO and social sharing.
+summary: |
+  A short summary of the lab for the guides listing page. 2-3 lines.
+keywords: AI, Docker, Model Runner, agentic apps, lab, labspace
+aliases: # Include only for AI-related labs
+  - /labs/docker-for-ai/{REPO_NAME_WITHOUT_LABSPACE_PREFIX}/
+params:
+  tags: [ai, labs]
+  time: 20 minutes
+  resource_links:
+    - title: A resource link pointing to relevant documentation or code
+      url: /ai/model-runner/
+    - title: Labspace repository
+      url: https://github.com/dockersamples/{REPO_NAME}
+---
+
+Short explanation of the lab and what it covers.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/{REPO_NAME}" >}}
+
+## What you'll learn
+
+By the end of this Labspace, you will have completed the following:
+
+- Objective #1
+- Objective #2
+- Objective #3
+
+## Modules
+
+| # | Module | Description |
+|---|--------|-------------|
+| 1 | Module #1 | Description of module #1 |
+| 2 | Module #2 | Description of module #2 |
+| 3 | Module #3 | Description of module #3 |
+```
+
+Conditional rules:
+- All lab guides **must** include `labs` in `params.tags`.
+- AI-related labs: also add `ai` tag and an alias under `/labs/docker-for-ai/`.
+- If a model download is required: add `model-download: true` to the `labspace-launch` shortcode.
+
+## Step 4: Apply Docker docs style rules
+
+Follow STYLE.md and COMPONENTS.md. Key rules:
+
+| Avoid | Use instead |
+|-------|-------------|
+| "we", "let's" | Imperative voice or "you" |
+| "simply", "easily", "just" | Remove the hedge word |
+| "allows you to" / "enables you to" | "lets you" or rephrase |
+| "click" | "select" |
+| Bold for emphasis / product names | Bold only for UI elements |
+| "currently", "new", "recently" | Remove time-relative language |
+
+Use `console` as the language hint for shell blocks with `$` prompts.
+Use contractions ("it's", "you're", "don't").
+
+## Step 5: Validate
+
+1. Confirm frontmatter has `title`, `description`, `keywords`, and `params.tags` including `labs`.
+2. Run `npx --no-install rumdl fmt <file>` to format.
+3. Run `docker buildx bake lint vale` and fix any errors.
+4. Re-read the file and verify: correct shortcode syntax, objectives match source content, modules match `labspace.yaml`, no vendored paths edited.
+
+Do not proceed to commit until validation passes.
diff --git a/.agents/skills/create-pr/SKILL.md b/.agents/skills/create-pr/SKILL.md
new file mode 100644
index 000000000000..2bec1eb3d360
--- /dev/null
+++ b/.agents/skills/create-pr/SKILL.md
@@ -0,0 +1,180 @@
+---
+name: create-pr
+description: >
+  Push the current branch and create a pull request against docker/docs.
+  Use after changes are committed and reviewed. "create a PR", "submit the
+  fix", "open a pull request for this".
+---
+
+# Create PR
+
+Push the branch and create a properly structured pull request.
+
+## 1. Verify the branch
+
+Confirm you're on a dedicated branch, not the default branch:
+
+```bash
+git branch --show-current   # must not be main or master
+```
+
+If this returns `main` or `master`, stop. Create a branch and move your
+commits onto it before continuing.
+
+Confirm commits exist and the working tree is clean:
+
+```bash
+git log --oneline main..HEAD   # confirm commits exist
+git status --porcelain         # must print nothing
+```
+
+If `git status --porcelain` prints anything, there are uncommitted or
+unstaged changes. Stop and commit them — or unstage stray files like
+`package-lock.json` — before opening a PR. Don't open a PR mid-edit.
+
+## 2. Push the branch
+
+Identify the remote that points at your fork. Inspect the remotes:
+
+```bash
+git remote -v
+```
+
+If `origin` is your fork, use it. If `origin` points at canonical
+`docker/docs` (the upstream), push to your separate fork remote instead —
+never push the branch to `docker/docs` directly:
+
+```bash
+FORK_REMOTE=origin   # or the name of your fork remote if origin is upstream
+git push -u "$FORK_REMOTE" <branch-name>
+```
+
+## 3. Create the PR
+
+Before creating a PR for an issue, check whether that issue already has an open
+linked PR:
+
+```bash
+gh api repos/docker/docs/issues/<issue-number>/timeline --paginate \
+  --jq '.[] | select((.event=="cross-referenced" or .event=="connected" or .event=="referenced") and .source.issue.pull_request and .source.issue.state=="open") | {url: .source.issue.html_url, title: .source.issue.title}'
+```
+
+If this returns an open PR that addresses the same issue, stop. Don't open a
+duplicate PR; report the existing PR instead. Only proceed if there is no open
+linked PR, or if the existing PR clearly does not address the issue and you
+explain why in the new PR body.
+
+Derive the fork owner dynamically from the same fork remote you pushed to:
+
+```bash
+FORK_OWNER=$(git remote get-url "$FORK_REMOTE" | sed -E 's|.*[:/]([^/]+)/[^/]+(\.git)?$|\1|')
+```
+
+```bash
+gh pr create --repo docker/docs \
+  --head "${FORK_OWNER}:<branch-name>" \
+  --title "<concise summary under 70 chars>" \
+  --body "$(cat <<'EOF'
+## Summary
+
+<1-2 sentences: what was wrong and what was changed>
+
+Closes #NNNN
+
+Generated by <active coding agent name>
+EOF
+)"
+```
+
+Prefix the title with the change type to match repo convention — `docs:` for
+documentation changes (or another scope like `hub:` when appropriate), for
+example `docs: fix broken link on install page`.
+
+Keep the body short. Reviewers need to know what changed and why — nothing
+else. Do **not** add a "Test plan" section — documentation PRs don't need one.
+
+Use an accurate disclosure footer that names the active coding agent, for
+example `Generated by Codex` or `Generated by Claude Code`.
+
+### Optional: Netlify preview entry path
+
+If the PR primarily edits a single page or a focused section of pages, add a
+`@netlify` stanza to the PR body (for example, just below the Summary). This
+sets the entry path for the Netlify deploy preview so reviewers land on the
+edited page instead of the site root:
+
+```markdown
+@netlify /desktop/setup/install/
+```
+
+The stanza takes a single published URL path. Derive it from the source file
+path: drop the `content/` prefix and `.md` suffix, strip the `/manuals`
+segment, and add a trailing slash. For example,
+`content/manuals/desktop/setup/install/mac-install.md` becomes
+`/desktop/setup/install/mac-install/`.
+
+Only add this when the change is focused on one page or section. Skip it for
+PRs that touch many unrelated pages — there is no useful single entry path.
+
+### Optional: Preview links
+
+When the change is focused, also add direct links to the deploy preview in the
+PR body so reviewers can jump straight to the affected pages. The preview URL
+embeds the PR number:
+
+```
+https://deploy-preview-<pr-number>--docsdocker.netlify.app/path/to/page/
+```
+
+The PR number isn't known until `gh pr create` returns, so add these links
+after creating the PR by updating the body:
+
+```bash
+gh pr edit <pr-number> --repo docker/docs --body "..."
+```
+
+Use the same source-path-to-URL mapping as the `@netlify` stanza above.
+
+## 4. Apply labels and request review
+
+Use the Issues API for labels — `gh pr edit --add-label` silently fails:
+
+```bash
+gh api repos/docker/docs/issues/<pr-number>/labels \
+  --method POST \
+  --field 'labels[]=status/review'
+```
+
+Request review:
+
+```bash
+gh pr edit <pr-number> --repo docker/docs --add-reviewer docker/docs-team
+```
+
+Verify the reviewer was assigned:
+
+```bash
+gh pr view <pr-number> --repo docker/docs --json reviewRequests \
+  --jq '.reviewRequests[].slug'
+```
+
+If the team doesn't appear, use the API directly:
+
+```bash
+gh api repos/docker/docs/pulls/<pr-number>/requested_reviewers \
+  --method POST --field 'team_reviewers[]=docs-team'
+```
+
+## 5. Report
+
+Print the PR URL and current CI state:
+
+```bash
+gh pr view <pr-number> --repo docker/docs --json url,state
+gh pr checks <pr-number> --repo docker/docs --json name,state
+```
+
+## Notes
+
+- Always use `Closes #NNNN` (not "Fixes") for GitHub auto-close linkage
+- One issue, one branch, one PR — never combine
diff --git a/.agents/skills/curate-whats-new/SKILL.md b/.agents/skills/curate-whats-new/SKILL.md
new file mode 100644
index 000000000000..fb9bd323906b
--- /dev/null
+++ b/.agents/skills/curate-whats-new/SKILL.md
@@ -0,0 +1,101 @@
+---
+name: curate-whats-new
+description: Curate noteworthy Docker launches from documentation pull requests merged during a requested period. Use when generating or reviewing data/whats-new.json, preparing the Docker Docs What's new timeline, or deciding which documented releases merit Docker-wide highlights.
+---
+
+# Curate What's New
+
+Treat merged documentation as evidence that a capability shipped, but do not
+treat a documentation change as news by itself.
+
+Include an item only when the merged documentation directly shows all of the
+following:
+
+- A released user-facing feature, material enhancement, or broader availability
+  milestone that was not available before the period
+- A substantial capability or workflow, not new syntax or a small control
+  within an existing workflow
+- Enough Docker-wide editorial significance to merit proactively telling users
+  about it outside product release notes
+- A useful published page and a factual title and description
+
+Apply a high bar. The result is a curated launch archive, not a complete
+changelog. A specialized feature can qualify when its user impact is
+substantial. A quiet period can produce few or no items.
+
+## Exclusions
+
+Exclude documentation maintenance; fixes; rewrites; guidance for old behavior;
+routine release or generated-content syncs; limitations, prerequisites, and
+workarounds; narrow flags, settings, command variants, protocols, and
+compatibility changes; incremental UI, safety, permissions, or observability
+improvements; and lower-level Engine, Build, networking, or storage changes.
+These qualify only when they are part of an independently newsworthy
+product-level launch.
+
+Judge the user outcome, not PR size, product popularity, labels, changed lines,
+a dedicated page, or the existence of a new API or command.
+
+## Select highlights
+
+Include every qualifying launch; do not impose a quota. Mark the five most
+important as `featured: true`, or all items when fewer than five qualify. Rank
+by the magnitude and distinctness of the user outcome and the value of helping
+its audience discover it. Breadth can matter, but a major capability for a
+specialized audience can outrank a smaller change for a broad audience. Recency
+and product variety are not ranking goals.
+
+Create one item per launch and combine PRs that document the same launch.
+Preserve existing copy while it remains accurate and qualifies. Change featured
+status only when the relative importance of the candidate set changes.
+
+## Procedure
+
+1. Read `data/whats-new.json`.
+2. Determine the review mode from the request:
+   - If the request does not specify a publication window, end it on the
+     previous UTC day and start it 29 days earlier.
+   - For an incremental review, list PRs merged from the day after the supplied
+     checkpoint through the end of the publication window. Retain existing
+     items inside the publication window without re-reviewing their source PRs.
+     If the request does not supply a checkpoint, use the existing
+     `period_end` from `data/whats-new.json`.
+   - For a full review, inspect every PR merged in the supplied publication
+     window.
+3. List PRs in the range that applies to the review mode:
+
+   ```console
+   $ gh pr list --repo docker/docs --state merged --search 'merged:START..END' --limit 200
+   ```
+
+   If an incremental search returns no PRs, skip candidate inspection and only
+   remove expired items.
+4. Inspect the diff and resulting pages for every plausible new candidate.
+5. Decide what qualifies using only evidence in the merged documentation.
+6. Remove existing items published before the requested publication window.
+   Add newly qualifying launches, combine related PRs, and reconsider featured
+   status across the resulting list. Do not replace or rewrite retained items
+   merely because they were not part of the incremental candidate range.
+7. Replace `period_start`, `period_end`, and `items` in
+   `data/whats-new.json`. Sort items by `published` date, newest first.
+8. Report the curation outcome in the response:
+   - Enumerate every newly selected entry by product, title, and source PRs.
+   - Summarize retained and expired entries by count. Identify any retained
+     entry whose content or sources changed.
+   - Explain only the most relevant plausible exclusions. Do not enumerate
+     routine maintenance PRs that were never credible candidates.
+
+If the request includes creating a pull request, use the same report in the PR
+body with `## Summary`, `## Selected entries`, and `## Curation notes`
+sections. Put each selected entry on one Markdown bullet and reference PRs as
+`#NNNN` rather than full same-repository links. Do not hard-wrap bullets. Do
+not create `.pr-body.md` or another handoff file unless the request explicitly
+asks for one.
+
+Each item must contain `product`, `title`, `description`, `url`, `published`,
+`source_prs`, and `featured`. Use the canonical product name, a published
+internal URL, the merge date in `YYYY-MM-DD` format, and source PR numbers.
+
+Write factual, restrained copy. Avoid superlatives, promotional language, and
+claims about ease or importance. Do not modify tracked files other than
+`data/whats-new.json`.
diff --git a/.agents/skills/curate-whats-new/agents/openai.yaml b/.agents/skills/curate-whats-new/agents/openai.yaml
new file mode 100644
index 000000000000..6b51529d64a8
--- /dev/null
+++ b/.agents/skills/curate-whats-new/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Curate What's New"
+  short_description: "Curate noteworthy Docker launches from merged docs"
+  default_prompt: "Use $curate-whats-new to curate Docker launches published during the requested date range."
diff --git a/.agents/skills/fix-issue/SKILL.md b/.agents/skills/fix-issue/SKILL.md
new file mode 100644
index 000000000000..4f32fe91f5bb
--- /dev/null
+++ b/.agents/skills/fix-issue/SKILL.md
@@ -0,0 +1,85 @@
+---
+name: fix-issue
+description: >
+  Fix a single GitHub issue end-to-end: triage, research, write the fix,
+  review, and create a PR. Use when asked to fix an issue: "fix issue 1234",
+  "resolve #500", "create a PR for issue 200".
+argument-hint: "<issue-number>"
+---
+
+# Fix Issue
+
+Given GitHub issue **$ARGUMENTS**, decide what to do with it and either
+close it or fix it. This skill orchestrates the composable skills — it owns
+the decision tree, not the individual steps.
+
+## 1. Triage
+
+Invoke `/triage-issue $ARGUMENTS` to understand the issue and decide what
+to do. This runs in a forked subagent and returns a verdict.
+
+## 2. Act on the triage result
+
+If triage says **close it** — comment with the reason and close:
+```bash
+gh issue close $ARGUMENTS --repo docker/docs \
+  --comment "<one sentence explaining why>
+
+Generated by <active coding agent name>"
+```
+Done.
+
+If triage says **escalate upstream** — comment noting the repo and stop:
+```bash
+gh issue comment $ARGUMENTS --repo docker/docs \
+  --body "This needs to be fixed in <upstream-repo>.
+
+Generated by <active coding agent name>"
+```
+Done.
+
+If triage says **leave it open** — comment explaining what was checked and
+what's unclear. Do not close.
+Done.
+
+End every issue comment with an accurate agent-disclosure footer that names
+the active coding agent, for example `Generated by Codex` or `Generated by
+Claude Code`.
+
+If triage says **fix it** — proceed to step 3.
+
+## 3. Research
+
+Invoke `/research` to locate affected files, verify facts, and identify
+the fix. The issue context carries over from triage. This runs inline —
+findings stay in conversation context for the write step.
+
+If research reveals the issue is upstream or cannot be fixed (e.g.
+unverifiable URLs), comment on the issue and stop.
+
+## 4. Write
+
+Invoke `/write` to create a branch, make the change, format, self-review,
+and commit.
+
+## 5. Review
+
+Invoke `/review-changes` to check the diff for correctness, coherence, and
+mechanical compliance. This runs in a forked subagent with fresh context.
+
+If issues are found, fix them and re-review until clean.
+
+## 6. Create PR
+
+Invoke `/create-pr` to push the branch and open a pull request.
+
+## 7. Return to main
+
+```bash
+git checkout main
+```
+
+## 8. Report
+
+Summarize what happened: the issue number, what was done (closed, escalated,
+fixed with a PR link), and why — in a sentence or two.
diff --git a/.agents/skills/maintain-pr/SKILL.md b/.agents/skills/maintain-pr/SKILL.md
new file mode 100644
index 000000000000..ceb563616a43
--- /dev/null
+++ b/.agents/skills/maintain-pr/SKILL.md
@@ -0,0 +1,89 @@
+---
+name: maintain-pr
+description: >
+  Maintain and follow up on a single Docker documentation pull request that
+  you own or are responsible for updating. Check CI and review feedback, fix
+  actionable failures, push changes, reply to comments, and report status.
+  Use for requests such as "babysit this PR", "check the status of my PR",
+  "fix CI on my PR", or "address review comments on #500". Do not use for
+  maintainer review of an incoming contribution; use review-pr for that.
+---
+
+# Maintain PR
+
+Do one maintenance pass over the specified author-owned PR: inspect its
+state, fix actionable failures or feedback, reply to reviewers, and report
+the result. This workflow may modify the branch and GitHub because the user
+is asking to maintain the PR. Do not apply it to an incoming PR merely
+because the user asks to review or assess it.
+
+## 1. Gather PR state
+
+```bash
+gh pr view <PR> --repo docker/docs --json state,title,url,headRefName,headRepositoryOwner,comments,reviews,reviewDecision
+gh pr checks <PR> --repo docker/docs --json name,state,detailsUrl
+gh api repos/docker/docs/pulls/<PR>/comments \
+  --jq '[.[] | {id, author: .user.login, body, path, line, in_reply_to_id}]'
+```
+
+Always check both top-level reviews and inline comments. A review with an
+empty body may still contain line-level feedback. Confirm that the PR is one
+the user owns or is authorized to update before checking out or pushing its
+branch. If not, stop and use `review-pr`.
+
+## 2. Handle terminal states
+
+If merged, report the final state and identify unanswered review comments.
+Reply only when the user remains responsible for follow-up.
+
+If closed without merge, read the closing context and report the reason.
+Common causes include maintainer rejection, supersession, or automation.
+
+## 3. Diagnose CI failures
+
+- Read the failure details.
+- Determine whether the failure comes from the PR or predates it.
+- Fix actionable failures in the PR's changed files.
+- Report pre-existing or upstream failures without changing unrelated files.
+
+Follow repository instructions for formatting, targeted linting, explicit
+staging, commits, and pushes. Preserve unrelated working-tree changes.
+
+## 4. Address review feedback
+
+Treat every review comment as a claim to verify. Implement it only when the
+evidence supports it; explain any evidence-based disagreement.
+
+After each fix:
+
+1. Format and validate the changed files.
+2. Commit and push the focused change.
+3. Reply to every addressed thread with what changed or why no change was
+   made.
+4. End replies with an accurate agent-disclosure footer, such as
+   `Generated by Codex`.
+5. Resolve threads only after replying.
+6. Re-request review when appropriate.
+
+Use the inline comment endpoint to reply:
+
+```bash
+gh api repos/docker/docs/pulls/<PR>/comments \
+  --method POST \
+  --field in_reply_to=<COMMENT_ID> \
+  --field body='<RESPONSE>'
+```
+
+Use GraphQL to retrieve unresolved review-thread IDs and resolve only the
+threads that were addressed. Do not silently fix feedback without replying.
+
+## 5. Report
+
+```markdown
+## PR #<number>: <title>
+
+**State:** <open, merged, or closed>
+**CI:** <passing, failing, or pending>
+**Review:** <approved, changes requested, or pending>
+**Action taken:** <changes, replies, and thread resolution, or none needed>
+```
diff --git a/.agents/skills/maintain-pr/agents/openai.yaml b/.agents/skills/maintain-pr/agents/openai.yaml
new file mode 100644
index 000000000000..54c4fb6d1d86
--- /dev/null
+++ b/.agents/skills/maintain-pr/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Maintain PR"
+  short_description: "Maintain an authored PR through review and CI"
+  default_prompt: "Use $maintain-pr to maintain this pull request through CI and review follow-up."
diff --git a/.agents/skills/migrate-content-ia/SKILL.md b/.agents/skills/migrate-content-ia/SKILL.md
new file mode 100644
index 000000000000..cf0bf697ee89
--- /dev/null
+++ b/.agents/skills/migrate-content-ia/SKILL.md
@@ -0,0 +1,384 @@
+---
+name: migrate-content-ia
+description: >
+  Handle Hugo docs information-architecture moves: discover old vs new URLs,
+  add front matter aliases (Phase 1), update in-repo links (Phase 2), interactive
+  List 2 resolution and fragment validation (Phase 3; no guessing). Supports
+  PR-scoped mapping plus whole-content sweeps for inbound links to that mapping,
+  or a full-site follow-up. Triggers on: "IA migration", "redirects for moved
+  pages", "fix links after content move", "PR-scoped link/anchor pass",
+  "aliases for old URLs". After branch work, chain the review-changes skill
+  (main...HEAD) before a PR. Agents must run the in-file required procedure
+  and definition of done, not the phases alone in isolation.
+---
+
+# Migrate content IA (redirects + links + anchors)
+
+Use this skill when pages **move or rename** under `content/` and you must
+preserve old public URLs and/or fix cross-references. Work in **phases**;
+choose **PR-scoped** vs **full-site** mode per run.
+
+**Read first:** **CLAUDE.md** / **AGENTS.md** (URL rules, vendored areas, external
+links, special cases) and **hugo.yaml** (`permalinks`, `refLinksErrorLevel`,
+`disablePathToLower`). For **prose and link text**, follow **STYLE.md**; for
+**components, front matter, and link examples**, follow **COMPONENTS.md**.
+
+**Related skills:** **research** helps map moves and find inbound links; **write**
+commits minimal edits. Run this skill’s phases after the move is identified (or
+in parallel with research for large IA work).
+
+## Agent: required procedure (do not skip)
+
+**Common mistake (wrong):** use **`git diff main...HEAD` (or the PR’s file
+list) as the full set of places to fix links** for a migration. That set shows
+**what *moved***; it is **not** the list of every page that **points *to*** a
+moved page. Inbound stragglers are often in files the PR **never** touched. You
+must still **sweep the repo** for every string in the **old path and published-URL set**
+for this run, not only for “files in the diff.”
+
+**Definition of done (when the migration is *finished*):** **Both** of the
+following (unless the user or **AGENTS.md** **explicitly defers** a **List 2**
+item in **Phase 3**; document the deferral):
+
+1. **`docker buildx bake validate`** passes for the branch, with no new
+   build/link errors from this work.
+2. A **sweep of the old path and published-URL set for this run** (see
+   [Sweep commands](#sweep-commands) below) finds **no** remaining
+   migration-relevant **inbound** reference—**including**:
+   - links to an old **source** path (plain `.md` and equivalent `ref` forms),
+   - links that use the old path **and** a `#fragment`,
+   - and, where your mapping includes them, old **published-style** `link:` /
+   `url:` / full-site URL strings,  
+   **except** intentional entries to keep: for example `aliases` on the **new**
+   canonical page, or **redirects.yml** *sources* you must not edit per policy.
+   (A hit on a **source** that is only an `alias` line on the new page is
+   **expected**—do not “fix” that away; distinguish alias rows from straggler
+   links in body or nav config.)
+
+**Chaining (policy):** when this branch’s content work is ready for handoff,
+**run the [review-changes](../review-changes/SKILL.md) skill** on
+**`main...HEAD`** (or **`merge-base`…`HEAD`** for a different target branch) so
+the **whole branch** is re-read for cross-page issues before opening a PR. Do
+not treat phases 0–3 alone as the final check.
+
+**Run in order (mandatory for agents):**
+
+1. **Scope the moves (mapping input):** set the Git range like **review-changes**
+   (for a PR to `main`: `git diff --name-only main...HEAD`; for another target:
+   `BASE=$(git merge-base <target-branch> HEAD)` then
+   `git diff --name-only $BASE...HEAD`, as in **Phase 0.5**). Include
+   renames; build the **old → new** table (source and published) per **Phase
+   0**.
+2. **Sweep and list:** for every **old** path/URL in that table, run
+   [Sweep commands](#sweep-commands) on the **allowed** trees. Record
+   every hit as **List 1** (no `#`) or **List 2** (old path with `#...`) per
+   **Phase 0.5**.
+3. **Phased edits:** **Phase 1** (`aliases`), then **Phase 2** (List 1), then
+   **Phase 3** (List 2) with **no guessing**—as in the sections below.
+4. **Re-sweep** the same old-path set, then run **`docker buildx bake
+   validate`**. The **Definition of done** above is met or you have **explicit
+   defers** for the remainder.
+5. **review-changes:** run **[review-changes](../review-changes/SKILL.md)**
+   on the branch vs **`main`…`HEAD`** (or the correct base) before a PR.
+
+### Sweep commands
+
+Use a **repository** search (e.g. `rg` / your IDE) so **nothing** in the
+allowed scope is only eyeballed.
+
+**Trees to include** (at minimum): all of `content/`, plus **`data/`** and
+**`layouts/`** when a migration can appear in config, `link:`-like fields,
+shortcodes, or hardcoded path strings. Follow **Vendored / generated** rules in
+**AGENTS.md**; do not edit disallowed files.
+
+**What to search for (repeat per row in the old side of the mapping):**
+
+- **Hugo / source form:** path segments that identify the *old* file, e.g.
+  `manuals/.../old-segment/...` or `../old-segment/.../page.md` as your tree
+  uses; include variants that still appear in the repo.
+- **Published / site form:** e.g. `/admin/.../old-slug/` in front matter, nav
+  `url:`, or `https://docs.docker.com/...` in allowed files—**match the
+  file’s** established pattern, per **Conventions** below.
+- **Anchors:** search for the **old path string**; matches that also include
+  `#...` belong on **List 2** for **Phase 3** unless the whole link is
+  a pure path-only case.
+
+[scripts/scope-pr-files.sh](scripts/scope-pr-files.sh) (if present) prints
+**`PR_SCOPE_FILES` only**—it does **not** replace this sweep. Use it to build
+the **old → new** table, **not** to list where inbound links were fixed.
+
+## Progressive disclosure (optional)
+
+The procedure below stays in this file. If a run produces a very large
+**old → new** URL table, store that table in **`reference.md`** in this skill
+directory and link it from the task summary, so the agent reads the long
+mapping only when needed.
+
+## Modes
+
+- **PR-scoped (typical for a single PR)**  
+  - **What the PR “owns” (focus):** use `git diff` / `base...HEAD` to know which
+    pages and renames the branch actually moves (`PR_SCOPE_FILES`). The **old →
+    new** mapping and **List 1 / List 2** for this migration are defined from
+    **that** work, not from unrelated areas.
+  - **Where to look for stale references (sweep):** search broadly—typically all
+    of `content/` (and config, shortcodes, layouts, per Conventions)—for **inbound**
+    links and fields whose **target** is an **old** path or URL in **this** PR’s
+    mapping. Inbound stragglers are often in files the PR never touched; finding
+    them is **in scope** for this migration.  
+  - **What to edit:** update **any** file in the allowed trees that contains a
+    **migration-relevant** reference (target ∈ this PR’s old path set) according
+    to the phases below. **Do not** treat `PR_SCOPE_FILES` as a hard limit on
+    *which files you may save* for **inbound** link repairs (unless
+    project policy for a given PR says otherwise; then follow policy and
+    **defer** out-of-PR file fixes).
+  - **Out of scope (defer / ignore in this run):** link and anchor problems that
+    are **not** about this PR’s old→new map—e.g. a different area’s own slug
+    issues, rot unrelated to the remapped path set. *Example:* a PR that only
+    remaps `content/strawberry/...` should not “fix the whole site”; it **should**
+    still fix a link under `mango/…` that **points at** an old `strawberry/…` path
+    in the mapping, and **should not** chase **mango/**-only issues that do
+    not involve those old targets.
+
+- **Full-site (complete migration after the PR)**  
+  - Update stragglers **across the repo** (or all inbound links to moved
+    sections), including config-driven `link:` fields if policy allows.  
+  - Still make **minimal** edits; no drive-by rewrites to **unrelated** targets
+    outside the run’s **declared** mapping and lists.
+
+### No guessing
+
+- The agent must **not** guess **replacement paths, published URLs, or fragment
+  IDs** (including for consolidated pages, renamed headings, or
+  “semantic” remaps of `#anchor` → new `#…`). If the user has not given an
+  explicit new target, **ask**, **defer**, or **stop** per **AGENTS.md**; never
+  infer, autocomplete, or substitute a plausible fragment from the target page’s
+  heading list. That rule applies in **every** phase, including after validation
+  in Phase 3.
+
+---
+
+## Conventions (links, anchors, redirects)
+
+### Front matter `aliases` (redirects)
+
+- Per **COMPONENTS.md**, `aliases` are **URLs that redirect to this page**.
+- Add or **merge** on the **new canonical** page; do not drop unrelated
+  entries. Match local examples: **published-style paths** (leading `/`), and
+  **trailing `/`** when that matches existing pages in the same area.
+- **No** speculative redirects for URLs that were never published.
+- **Collision check** before adding: no other page or redirect may already
+  own the same old path.
+- If the site also uses **`data/redirects.yml`**, only add entries when
+  project policy requires it; avoid duplicating the same old URL in
+  `aliases` **and** `redirects.yml` unless maintainers do.
+
+### Internal links in Markdown (STYLE.md + COMPONENTS.md)
+
+- Use **relative paths to source files** (e.g. `../section/page.md`) with
+  **`.md`**, following **COMPONENTS.md** examples, unless the file already
+  uses an established pattern (e.g. some `link:` or nav fields use **published**
+  paths without `manuals` or `.md` — **match the surrounding file**).
+- Keep **CLAUDE.md** / **AGENTS.md** rules: internal ref targets under
+  `content/manuals/...` often use the full **`/manuals/...`** path; published
+  URLs omit the `manuals` segment—do not confuse the two when fixing links.
+- **Link text (STYLE.md):** descriptive, ~**5 words**; no “click here” or
+  “learn more”; **no** end punctuation **inside** the link text; **no** bold/italic
+  on link text unless normal in the sentence.
+- **Headings (STYLE):** **sentence case**; do not rename headings in passing
+  unless the migration requires it (heading changes break fragments).
+
+### Shortcodes and layouts (links not only in Markdown)
+
+- **Phase 2–3 scope includes** any **shortcode or layout partial** (under
+  **Modes**, search broadly for inbound links to the migration; **edits** follow
+  the same file-level rules as for Markdown) that emits links: e.g. `ref` /
+  `relref`, `link` fields in shortcode args, or hardcoded
+  `docs.docker.com` / path strings. Grep for old paths, slugs, and fragments
+  under `layouts/shortcodes/` (and `layouts/_default/` if partials build nav).
+- Match each file’s existing pattern; do not rewrite working shortcode style
+  just to “clean up.”
+
+### Fragments / anchors (Phase 3)
+
+- List 1 / List 2: fragment-bearing **cross-references to old paths** are tracked
+  on **List 2** in Phase 0.5; do not bulk-rewrite them in the **List 1** pass
+  (Phase 2). See Phase 0.5 and Phase 2.
+- **Valid `#fragment` values:** after the user supplies a new fragment, it should
+  match the **target** page’s **generated** heading ID (Hugo slugification; see
+  **CLAUDE.md** / **AGENTS.md**). The agent still **validates** (see Phase 3) and
+  must **not** “pick” a different id from the page to replace a bad answer—**No
+  guessing**.
+- Same-page: `[Text](#section-id)`.
+- Cross-page: when user-provided, `#fragment` must still be checked against the
+  **target** file. Validate fragments in shortcodes the same way as in body
+  Markdown.
+
+### External URLs (**AGENTS.md**)
+
+- Do not commit **guessed** replacement URLs. If a URL cannot be verified,
+  treat as blocked or drop the fragment per AGENTS guidance. See also **No
+  guessing** above; internal and external link targets are treated the same for
+  inference: **none** without user input or a verified source.
+
+### Special cases (**AGENTS.md**)
+
+- **Engine API version** pages: respect coordinated **`/latest/` `aliases`**
+  rules—never leave two version files both owning `/latest/`.
+- **Vendored / generated** trees: read-only; see CLAUDE.md. Do not “fix” links
+  there if policy forbids.
+
+---
+
+## Phase 0 — Discovery (read-only; may use whole repo)
+
+1. Read **hugo.yaml** (permalinks, `refLinksErrorLevel`, `disablePathToLower`).
+2. From the branch (diff, renames), build a **mapping table**:
+   - old source path → new source path  
+   - old published URL → new published URL (from permalink rules)
+3. **Case:** with `disablePathToLower: true`, filesystem path **case** appears in
+   URLs—**directory and link casing must match** (e.g. `setup` vs `Setup`).
+4. When planning **inbound link** fixes, treat old-path references as two
+   categories: **no fragment** vs **with `#fragment`**. That split feeds
+   **List 1** and **List 2** in Phase 0.5 and drives Phase 2 ordering (see
+   there).
+
+---
+
+## Phase 0.5 — PR-scoped evaluation (required before edits in PR mode)
+
+1. **Set `PR_SCOPE_FILES` (Git scope for PR mode)**  
+   - When the PR **targets `main`**, use the same triple-dot form as
+     **review-changes**:  
+     `git diff --name-only main...HEAD`  
+   - For a **different target branch** or a custom base, use the merge base:  
+     `BASE=$(git merge-base <target-branch> HEAD)`  
+     then:  
+     `git diff --name-only "$BASE"...HEAD`  
+   - Those paths define **what moved** in the branch; they are the primary input
+     to the **old → new** path/URL table. They are **not** a hard cap on *where
+     to search* for **inbound** links (see **Modes**): sweeps for links **to** old
+     paths usually cover all of `content/` (and other trees per Conventions).  
+   - If project policy **limits edits** to the diff for a given PR, follow that
+     and **defer** link fixes in files outside the diff; note the exception in
+     the task if the user relaxes that policy.
+
+2. Build checklists (see **Modes** for sweep vs area-of-work):
+   - path/URL mapping this run must honor (old source path → new; old published
+     → new, from the **PR’s** moves in PR-scoped mode, or the **declared** full
+     migration in full-site mode)
+   - **List 1 — old path, no fragment:** every **inbound** reference, found on
+     the **sweep** surface, to a moved **old** path that does **not** include a
+     `#...` fragment (e.g. `…/banana.md` in the repo’s link style for that
+     file).
+   - **List 2 — old path with fragment:** every **inbound** reference, found on
+     the same sweep, to a moved **old** path that **includes** a `#...` fragment
+     (e.g. `…/banana.md#anchor` or the published-style equivalent in context). The
+     **same** old path string may appear on **both** List 1 and List 2 for
+     different links; duplication across the two lists is OK.
+   - **Matching rules:** when recording List 1 / List 2, use **one** consistent
+     path representation for comparison (e.g. relative `../path/banana.md` vs
+     root-anchored) **per the conventions in this doc** and the **surrounding
+     file’s** established pattern. Agents compare and skip List 2 links in the
+     List 1 pass using the **same** representation rules.
+3. **Out of scope** for the lists: only include references whose **old** target
+   is in this run’s **mapping**. Do not build List 1/2 for unrelated **mango/**
+   (or other) problems unless those links also target an **old** path that this
+   migration renames. Defer those issues separately (see **Modes**).
+
+---
+
+## Phase 1 — `aliases` (old published URLs)
+
+1. On each **new** canonical page, add or merge **`aliases`** for every **real**
+   former public URL.
+2. Do not strip existing unrelated aliases.
+3. **PR-scoped:** add aliases only where the canonical file is in scope or the
+   project requires it; otherwise list missing alias targets for follow-up.
+
+---
+
+## Phase 2 — In-repo link reference updates
+
+1. **List 1 first (path only):** update references that belong to **List 1**
+   (old path, **no** fragment). Replace old source paths or old published URLs
+   with the **new** targets; preserve each file’s link pattern (relative vs
+   root-anchored `.md` paths). **Do not** apply the same bulk path replacement to
+   links that appear in **List 2** (old path **with** `#...`) during this
+   sub-step—**leave** every **List 2** link **unchanged** for now.
+2. **After List 1 is complete:** **re-scan** the **same** **sweep** surface as
+   in Phase 0.5 (e.g. all of `content/` plus config) or **print** a clear list of
+   all **remaining** **List 2** entries. Those links should still point at the
+   **old** path and **old** fragment until Phase 3.  
+3. **Full-site (extra sweep):** after steps 1–2, still use **AGENTS “Page
+   deletion checklist”**-style thoroughness for **config / front matter**
+   `link:` and similar so nav and grids are not left on old slugs. Apply the
+   **List 1 / List 2** rules there too: path-only old references first; defer
+   fragment-bearing rewrites in line with **List 2** until Phase 3.
+4. **PR-scoped (which files to change):** apply List 1 and later Phase 3 updates
+   to **every** file the **sweep** finds with a **migration-relevant** reference
+   (inbound to an **old** path in the mapping), including files **not** in
+   `PR_SCOPE_FILES`, per **Modes**. **Log** and **defer** (do not “fix”)
+   unrelated stragglers. If policy forbids out-of-PR file edits, defer per step 1
+   of Phase 0.5.  
+5. Include **shortcodes and layout partials** (see Conventions and **Modes** for
+   sweep vs focus).
+
+---
+
+## Phase 3 — List 2: interactive path and fragment resolution
+
+**Prerequisites:** Phase 2 has updated **List 1**; **List 2** still lists **old
+path + `#...`** (unchanged) for this migration. See **Modes** for which files
+may be edited; **No guessing** applies.
+
+1. **Print List 2** to the user: every remaining **old path** + `#anchor` (in the
+   agreed representation), so nothing is hidden before the loop.
+2. **For each distinct** `old-path#oldAnchor` (or process in the order the user
+   prefers, one at a time):  
+   - Ask: **What is the new path (and fragment, if any) for this content?** The
+     user may give a new source path, published URL, and/or `#newAnchor` per
+     project conventions.  
+   - **Validate** the user’s answer: open the **target** page (or resolve the
+     target) and check that `#newAnchor` (if any) **exists** as a real heading
+     / generated id on that page, per **CLAUDE.md** / **AGENTS.md** (same rules
+     as the rest of the site). **Do not** replace the user’s fragment with a
+     “better” one from the file.  
+   - If validation **fails** (unknown target file, or `#newAnchor` not found on
+     the page): **warn** clearly (what failed: path vs missing fragment), then
+     **ask again** for a corrected path and/or fragment. **Repeat** until
+     validation passes or the user **defers** / **drops** the fragment (per
+     **AGENTS.md**). **Never** guess a new fragment to fix the problem.  
+   - When validation **passes:** update **all** in-repo references that match
+     that **same** `old-path#oldAnchor` to the user-approved `new-path#newAnchor`
+     (respect each file’s link style; include shortcodes/layouts on the same
+     **sweep** surface as Phase 2).  
+3. **Repeat** from step 1: **re-print** or **re-scan** for **List 2** until it is
+   **empty** or the user defers the remainder.  
+4. **PR-scoped / full-site:** the **loop** is the same. **Edits** follow **Modes**:
+   migration-relevant **inbound** links may live in any file on the sweep; do
+   not expand into **unrelated** link debt from other areas. Defer as in **Modes**
+   and Phase 0.5.
+
+---
+
+## Optional: scripts helper
+
+This skill includes a small **scope helper** so agents do not re-derive Git
+recipes. See [scripts/scope-pr-files.sh](scripts/scope-pr-files.sh) — it prints
+paths in PR scope for a given target branch (default `main`).
+
+---
+
+## Verification
+
+```bash
+docker buildx bake validate
+```
+
+Use the **Definition of done** in **Agent: required procedure (do not skip)**
+as the final bar: **validate** must pass, and the **sweep** must be clean for
+**plain** and **`#fragment`** old-path references, **or** the remainder must be
+**explicitly deferred** in **Phase 3** per **AGENTS.md** / the user. Mid-run,
+**Phase 2** may still leave **List 2** links unchanged **until** Phase 3; that
+intermediate state is **not** the finished migration.
diff --git a/.agents/skills/migrate-content-ia/scripts/scope-pr-files.sh b/.agents/skills/migrate-content-ia/scripts/scope-pr-files.sh
new file mode 100644
index 000000000000..d027ee3e47af
--- /dev/null
+++ b/.agents/skills/migrate-content-ia/scripts/scope-pr-files.sh
@@ -0,0 +1,22 @@
+#!/bin/bash
+# List files changed on the current branch since merge-base with the target
+# branch — suitable for PR_SCOPE_FILES in PR-scoped migrate-content-ia runs.
+#
+# Usage:
+#   ./scope-pr-files.sh [target-branch]
+# Default target-branch: main
+#
+# Example (Bash / Git Bash, from repo root):
+#   bash .agents/skills/migrate-content-ia/scripts/scope-pr-files.sh
+# Example (other base):
+#   bash .../scope-pr-files.sh upstream/main
+set -euo pipefail
+
+target="${1:-main}"
+
+if ! base=$(git merge-base "$target" HEAD 2>/dev/null); then
+  echo "Error: could not merge-base with '$target'. Fetch remotes or pass a valid branch." >&2
+  exit 1
+fi
+
+git diff --name-only "$base"...HEAD
diff --git a/.agents/skills/research/SKILL.md b/.agents/skills/research/SKILL.md
new file mode 100644
index 000000000000..db9f98c3ffa0
--- /dev/null
+++ b/.agents/skills/research/SKILL.md
@@ -0,0 +1,93 @@
+---
+name: research
+description: >
+  Research a documentation topic — locate affected files, understand the
+  problem, identify what to change. Use when investigating an issue, a
+  question, or a topic before writing a fix. Triggers on: "research issue
+  1234", "investigate what needs changing for #500", "what files are
+  affected by #200", "where is X documented", "is our docs page about Y
+  accurate", "look into how we document Z".
+---
+
+# Research
+
+Thoroughly investigate the topic at hand and produce a clear plan for
+the fix. The goal is to identify exact files, named targets within those
+files, and the verified content needed for the fix.
+
+## 1. Gather context
+
+If the input is a GitHub issue number, fetch it:
+
+```bash
+gh issue view <number> --repo docker/docs \
+  --json number,title,body,labels,comments
+```
+
+Otherwise, work from what was provided — a description, a URL, a question,
+or prior conversation context. Identify the topic, affected feature, or
+page to investigate.
+
+## 2. Locate affected files
+
+Search `content/` using the URL or topic from the issue. Remember the
+`/manuals` prefix mapping when converting URLs to file paths.
+
+For each candidate file, read the relevant section to confirm it contains
+the reported problem.
+
+## 3. Check vendored ownership
+
+Before planning any edit, verify the file is editable locally:
+
+- `_vendor/` — read-only, vendored via Hugo modules
+- `data/cli/` — read-only, generated from upstream YAML
+- `content/reference/cli/` — read-only, generated from `data/cli/`
+- Everything else in `content/` — editable
+
+If the fix requires upstream changes, identify the upstream repo and note
+it as out of scope. See the vendored content table in CLAUDE.md.
+
+## 4. Find related content
+
+Look for pages that may need updating alongside the primary fix:
+
+- Pages that link to the affected content
+- Include files (`content/includes/`) referenced by the page
+- Related pages in the same section describing the same feature
+
+## 5. Verify facts
+
+If the issue makes a factual claim about how a feature behaves, verify it.
+Follow external links, read upstream source, check release notes. Do not
+plan a fix based on an unverified claim.
+
+If the fix requires a replacement URL and that URL cannot be verified (e.g.
+network restrictions), report it as a blocker rather than guessing.
+
+## 6. Check the live site (if needed)
+
+For URL or rendering issues, fetch the live page:
+
+```
+https://docs.docker.com/<path>/
+```
+
+## 7. Report findings
+
+Summarize what you found — files to change, the specific problem in each,
+what the fix should be, and any constraints. This context feeds directly
+into the write step.
+
+Be specific: name the file, the section or element within it, and the
+verified content needed. "Fix the broken link in networking.md" is not
+specific enough. "In `compose/networking.md`, the 'Custom networks' section,
+remove the note about `driver_opts` being ignored — this was fixed in
+Compose 2.24" is.
+
+## Notes
+
+- Research quality bounds write quality. Vague research produces broad
+  changes; precise research produces minimal ones.
+- Do not create standalone research files — findings stay in conversation
+  context for the write step.
diff --git a/.agents/skills/review-changes/SKILL.md b/.agents/skills/review-changes/SKILL.md
new file mode 100644
index 000000000000..f147883a44b2
--- /dev/null
+++ b/.agents/skills/review-changes/SKILL.md
@@ -0,0 +1,107 @@
+---
+name: review-changes
+description: >
+  Review uncommitted or recently committed documentation changes for
+  correctness, coherence, and style compliance. Use before creating a PR
+  to catch issues. "review my changes", "review the diff", "check the fix
+  before submitting", "does this look right".
+context: fork
+model: opus
+---
+
+# Review Changes
+
+Evaluate whether the changes correctly and completely solve the stated
+problem, without introducing new issues. Start with no assumptions — the
+change may contain mistakes. Your job is to catch what the writer missed,
+not to rubber-stamp the diff.
+
+## 1. Identify what changed
+
+Determine the scope of changes to review:
+
+```bash
+# Uncommitted changes
+git diff --name-only
+
+# Last commit
+git diff --name-only HEAD~1
+
+# Entire branch vs main
+git diff --name-only main...HEAD
+```
+
+Pick the right comparison for what's being reviewed. If reviewing a branch,
+use `main...HEAD` to see all changes since the branch diverged.
+
+## 2. Read each changed file in full
+
+Do not just read the diff. For every changed file, read the entire file to
+understand the full context the change lives in. A diff can look correct in
+isolation but contradict something earlier on the same page.
+
+Then read the diff for the detailed changes:
+
+```bash
+# Adjust the comparison to match step 1
+git diff --unified=10              # uncommitted
+git diff --unified=10 HEAD~1       # last commit
+git diff --unified=10 main...HEAD  # branch
+```
+
+## 3. Follow cross-references
+
+For each changed file, check what links to it and what it links to:
+
+- Search for other pages that reference the changed content (grep for the
+  filename, heading anchors, or key phrases)
+- Read linked pages to verify the change doesn't create contradictions
+  across pages
+- Check that anchor links in cross-references still match heading IDs
+
+A change that's correct on its own page can break the story told by a
+related page.
+
+## 4. Verify factual accuracy
+
+Don't assume the change is factually correct just because it reads well.
+
+- If the change describes how a feature behaves, verify against upstream
+  docs or source code
+- If the change includes a URL, check that it resolves
+- If the change references a CLI flag, option, or API field, confirm it
+  exists
+
+## 5. Evaluate as a reader
+
+Consider someone landing on this page from a search result, with no prior
+context:
+
+- Does the page make sense on its own?
+- Is the changed section clear without having read the issue or diff?
+- Would a reader be confused by anything the change introduces or leaves
+  out?
+
+## 6. Review code and template changes
+
+For non-Markdown changes (JS, HTML, CSS, Hugo templates):
+
+- Trace through the common execution path
+- Trace through at least one edge case (no stored preference, Alpine fails
+  to load, first visit vs returning visitor)
+- Ask whether the change could produce unexpected browser or runtime
+  behavior that no automated tool would catch
+
+## 7. Decision
+
+**Approve** if the change is correct, coherent, complete, and factually
+accurate.
+
+**Request changes** if:
+- The change does not correctly solve the stated problem
+- There is a factual error or contradiction (on-page or cross-page)
+- A cross-reference is broken or misleading
+- A reader would be confused
+
+When requesting changes, be specific: quote the exact text that is wrong,
+explain why, and suggest the correct fix.
diff --git a/.agents/skills/review-pr/SKILL.md b/.agents/skills/review-pr/SKILL.md
new file mode 100644
index 000000000000..7f5bfdb59b09
--- /dev/null
+++ b/.agents/skills/review-pr/SKILL.md
@@ -0,0 +1,205 @@
+---
+name: review-pr
+description: >
+  Review one or more incoming Docker documentation pull requests as a
+  maintainer. Independently validate technical claims, assess editorial fit
+  and information architecture, choose a verdict, and draft exact inline or
+  PR-wide feedback behind a confirmation gate. Use for requests such as
+  "review PR 123", "is this PR correct?", "does this information belong
+  here?", "validate this PR", or "help review backlog PRs". Do not use to
+  maintain or fix a PR you own; use maintain-pr for that.
+---
+
+# Review PR
+
+Review incoming contributions for factual correctness and whether they make
+the documentation better as a whole. Treat a technically true addition as
+insufficient when it is misplaced, overemphasized, redundant, or unhelpful
+to the page's intended reader.
+
+## Preserve the write boundary
+
+Perform the review in two phases:
+
+1. Research the PR, decide a verdict, and present the exact proposed
+   comment or review text.
+2. Wait for explicit user confirmation, then post only the confirmed text.
+
+Before confirmation, do not post comments, submit a GitHub review, approve or
+request changes, resolve threads, push commits, edit labels, or otherwise
+mutate GitHub. A request to review or draft feedback is not confirmation to
+post it. Ask `Post these comments?` and stop. Treat revisions to a draft as
+unconfirmed until the user explicitly asks to post them.
+
+## 1. Gather the full context
+
+For each PR, inspect its metadata, body, commits, changed files, checks,
+conversation, reviews, and linked issues. Always fetch inline comments
+separately because `gh pr view --json reviews` omits them.
+
+```bash
+gh pr view <PR> --repo docker/docs \
+  --json number,title,url,state,author,body,baseRefName,headRefName,headRefOid,commits,files,comments,reviews,reviewDecision,statusCheckRollup
+gh api repos/docker/docs/pulls/<PR>/comments \
+  --jq '[.[] | {id, author: .user.login, body, path, line, side, commit_id}]'
+gh pr diff <PR> --repo docker/docs
+```
+
+Read linked issues and relevant discussion. An issue is evidence that a
+reader was confused, but it does not establish the reporter's diagnosis or
+justify a new highlighted note by itself. Green CI establishes only that automated
+checks passed, not that the content is correct.
+
+Fetch the PR head when local inspection is useful. Compare it with the
+canonical upstream base rather than assuming the local branch is fresh.
+Read each changed file in full, not only its diff.
+
+## 2. Research independently
+
+Verify every material claim against authoritative sources such as product
+source code, upstream documentation, specifications, release notes, or safe
+local reproduction. Do not accept the PR description, issue diagnosis, or
+existing review feedback as fact.
+
+Search the documentation for related explanations and canonical pages. Read
+`STYLE.md`, `COMPONENTS.md`, and applicable repository instructions. Check
+whether a changed file is generated or maintained upstream and identify the correct
+upstream repository instead of proposing a local edit.
+
+Distinguish among:
+
+- a wrong fact
+- a correct fact expressed inaccurately
+- a correct fact placed on the wrong page
+- content already explained elsewhere
+- a real discovery problem better addressed with a short signpost and link
+- a request that needs no documentation change.
+
+If an external claim or replacement URL cannot be verified, report that
+limitation instead of guessing.
+
+## 3. Assess editorial fit
+
+Apply these questions to each addition:
+
+- Does it change a reader's decision or next action on this page?
+- Is this the canonical page for the concept?
+- Is the fact general, or specific to this page, feature, or component?
+- Is the information already documented elsewhere?
+- Would a concise local signpost to canonical coverage solve the discovery
+  problem better than duplicating the explanation?
+- Is the visual and textual weight proportional to the information's value?
+- Does it preserve the page's scope, flow, and character?
+
+Prefer one coherent explanation in the canonical location. Add local context
+only when it helps the reader complete the task at hand. Avoid stray notes,
+callouts, and exhaustive edge cases whose prominence exceeds their value.
+
+## 4. Choose a decisive verdict
+
+Lead with one of these outcomes:
+
+- **Approve**: correct, useful, well placed, and ready to merge.
+- **Approve with optional polish**: ready to merge; suggestions are genuinely
+  non-blocking.
+- **Focused rewrite**: the underlying need is valid, but wording, scope,
+  placement, or structure should change before merge.
+- **Close / no docs change**: incorrect, redundant, out of scope, or not a
+  documentation problem.
+
+Explain the verdict with evidence. When wording is the issue, provide exact
+replacement text rather than a vague request to improve it.
+
+## 5. Place feedback deliberately
+
+Use an inline comment when the finding is anchored to a narrow changed line
+or range and acting on it is local. Examples include an inaccurate sentence,
+an ambiguous option description, a broken link, or a precise wording
+replacement.
+
+Use a PR-wide comment for scope, information architecture, overall approach,
+multiple intertwined edits, or a proposed replacement section. Do not attach
+holistic feedback to an arbitrary line.
+
+Use both when appropriate: put the overall direction in the PR-wide comment
+and line-specific corrections inline. Do not repeat the same point in both.
+Consolidate related feedback so the author receives the fewest comments that
+remain clear and actionable.
+
+For every proposed inline comment, resolve and display the current changed
+file path and right-side diff line. If the target line is not part of the
+current diff or cannot be identified reliably, use a PR-wide comment that
+quotes the target text instead. Never guess a line number.
+
+End comments posted on the user's behalf with an accurate agent-disclosure
+footer, such as `Generated by Codex`.
+
+## 6. Present drafts and stop
+
+Before any GitHub write, show the review in this form, omitting empty
+sections:
+
+```markdown
+## Verdict
+
+Focused rewrite
+
+## Findings
+
+- <finding and evidence>
+
+## Proposed inline comments
+
+1. `path/to/file.md:42`
+   > Exact comment text
+
+## Proposed PR-wide comment
+
+> Exact comment text
+
+Post these comments?
+```
+
+For multiple PRs, give each PR its own verdict and comment set. Make the
+confirmation scope unambiguous. Do not interpret approval of one PR's drafts
+as approval to post comments on the others.
+
+## 7. Post only confirmed feedback
+
+Immediately before posting, re-fetch the PR head SHA and diff. If either the
+head or an inline target changed, stop and show the updated draft or
+placement for confirmation.
+
+Post confirmed inline comments as a single comment-only review when
+practical. Use the current head SHA and right-side diff lines:
+
+```bash
+gh api repos/docker/docs/pulls/<PR>/reviews --method POST --input <payload>
+```
+
+The JSON payload contains `commit_id`, `event: "COMMENT"`, and a `comments`
+array whose entries contain `path`, `line`, `side: "RIGHT"`, and `body`.
+Submitting a review with `APPROVE` or `REQUEST_CHANGES` requires separate,
+explicit user authorization; a verdict alone does not grant it.
+
+Post confirmed holistic feedback separately:
+
+```bash
+gh pr comment <PR> --repo docker/docs --body-file <file>
+```
+
+Use a safely created temporary file or API input so Markdown, backticks, and
+shell substitutions are preserved literally. Post exactly the confirmed
+text. Verify the resulting review/comments and report their URLs and
+placements. If GitHub rejects an inline location, do not silently fall back
+to a PR-wide comment; report the failure and prepare a revised placement for
+confirmation.
+
+## Definition of done
+
+- Verify technical claims with authoritative evidence.
+- Evaluate usefulness, placement, duplication, and proportionality.
+- Give a decisive verdict and exact actionable wording.
+- Choose inline and PR-wide placement based on the feedback's scope.
+- Show every exact draft and target before any GitHub mutation.
+- Post only after explicit confirmation and verify what was posted.
diff --git a/.agents/skills/review-pr/agents/openai.yaml b/.agents/skills/review-pr/agents/openai.yaml
new file mode 100644
index 000000000000..05b429a0082d
--- /dev/null
+++ b/.agents/skills/review-pr/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Review PR"
+  short_description: "Validate incoming documentation pull requests"
+  default_prompt: "Use $review-pr to validate this incoming documentation PR and draft maintainer feedback."
diff --git a/.agents/skills/testcontainers-guides-migrator/SKILL.md b/.agents/skills/testcontainers-guides-migrator/SKILL.md
new file mode 100644
index 000000000000..b934d1af4d7d
--- /dev/null
+++ b/.agents/skills/testcontainers-guides-migrator/SKILL.md
@@ -0,0 +1,401 @@
+---
+name: testcontainers-guide-migrator
+description: >
+  Migrate a Testcontainers guide from testcontainers.com into the Docker docs site (docs.docker.com).
+  Converts AsciiDoc to Hugo Markdown, updates code to the latest Testcontainers API, splits into
+  chapters with stepper navigation, verifies code compiles and tests pass, and validates against
+  Docker docs style rules. Use when asked to migrate a testcontainers guide, add a TC guide, or
+  port content from testcontainers.com to Docker docs.
+---
+
+# Migrate a Testcontainers Guide
+
+You are migrating guides from https://testcontainers.com/guides/ into the Docker docs Hugo site.
+Each guide lives in its own GitHub repo under `testcontainers/tc-guide-*`, written in AsciiDoc.
+The source repos are listed in the testcontainers-site build.sh:
+https://github.com/testcontainers/testcontainers-site/blob/main/build.sh#L23-L45
+
+## Inputs
+
+The user provides one or more guides to migrate. Resolve these from the inventory below:
+
+- **REPO_NAME**: GitHub repo (e.g. `tc-guide-getting-started-with-testcontainers-for-java`)
+- **SLUG**: guide slug inside `guide/` dir (e.g. `getting-started-with-testcontainers-for-java`)
+- **LANG**: language identifier (go, java, dotnet, nodejs, python)
+- **GUIDE_ID**: short kebab-case name (e.g. `getting-started`)
+
+## Guide inventory
+
+These are the 21 guides from testcontainers.com/guides/ and their source repos:
+
+| # | Title | Repo | Lang | GUIDE_ID |
+|---|-------|------|------|----------|
+| 1 | Introduction to Testcontainers | tc-guide-introducing-testcontainers | (none) | introducing |
+| 2 | Getting started for Java | tc-guide-getting-started-with-testcontainers-for-java | java | getting-started |
+| 3 | Testing Spring Boot REST API | tc-guide-testing-spring-boot-rest-api | java | spring-boot-rest-api |
+| 4 | Testcontainers lifecycle (JUnit 5) | tc-guide-testcontainers-lifecycle | java | lifecycle |
+| 5 | Configuration of services in container | tc-guide-configuration-of-services-running-in-container | java | service-configuration |
+| 6 | Replace H2 with real database | tc-guide-replace-h2-with-real-database-for-testing | java | replace-h2 |
+| 7 | Testing ASP.NET Core web app | tc-guide-testing-aspnet-core | dotnet | aspnet-core |
+| 8 | Testing Spring Boot Kafka Listener | tc-guide-testing-spring-boot-kafka-listener | java | spring-boot-kafka |
+| 9 | REST API integrations with MockServer | tc-guide-testing-rest-api-integrations-using-mockserver | java | mockserver |
+| 10 | Getting started for .NET | tc-guide-getting-started-with-testcontainers-for-dotnet | dotnet | getting-started |
+| 11 | AWS integrations with LocalStack | tc-guide-testing-aws-service-integrations-using-localstack | java | aws-localstack |
+| 12 | Testcontainers in Quarkus apps | tc-guide-testcontainers-in-quarkus-applications | java | quarkus |
+| 13 | Getting started for Go | tc-guide-getting-started-with-testcontainers-for-go | go | getting-started |
+| 14 | jOOQ and Flyway with Testcontainers | tc-guide-working-with-jooq-flyway-using-testcontainers | java | jooq-flyway |
+| 15 | Getting started for Node.js | tc-guide-getting-started-with-testcontainers-for-nodejs | nodejs | getting-started |
+| 16 | REST API integrations with WireMock | tc-guide-testing-rest-api-integrations-using-wiremock | java | wiremock |
+| 17 | Local dev with Testcontainers Desktop | tc-guide-simple-local-development-with-testcontainers-desktop | java | local-dev-desktop |
+| 18 | Micronaut REST API with WireMock | tc-guide-testing-rest-api-integrations-in-micronaut-apps-using-wiremock | java | micronaut-wiremock |
+| 19 | Micronaut Kafka Listener | tc-guide-testing-micronaut-kafka-listener | java | micronaut-kafka |
+| 20 | Getting started for Python | tc-guide-getting-started-with-testcontainers-for-python | python | getting-started |
+| 21 | Keycloak with Spring Boot | tc-guide-securing-spring-boot-microservice-using-keycloak-and-testcontainers | java | keycloak-spring-boot |
+
+Already migrated: **#2 (Java getting-started)**, **#13 (Go getting-started)**, **#20 (Python getting-started)**
+
+## Step 0: Pre-flight
+
+1. Confirm `testing-with-docker` tag exists in `data/tags.yaml`. If not, add:
+   ```yaml
+   testing-with-docker:
+     title: Testing with Docker
+   ```
+2. Check if new terms need adding to `_vale/config/vocabularies/Docker/accept.txt`.
+3. Read `STYLE.md` and `COMPONENTS.md` to refresh on Docker docs conventions.
+
+## Step 1: Clone the guide repo
+
+Clone the guide repo to a temporary directory. This gives you all source files locally — no HTTP calls needed.
+
+```bash
+git clone --depth 1 https://github.com/testcontainers/{REPO_NAME}.git <tmpdir>/{REPO_NAME}
+```
+
+Where `<tmpdir>` is a temporary directory on your system (e.g. the output of `mktemp -d`).
+
+The repo structure is:
+- `<tmpdir>/{REPO_NAME}/guide/{SLUG}/index.adoc` — the AsciiDoc guide source
+- `<tmpdir>/{REPO_NAME}/src/` — application source code (referenced by `include::` directives)
+- `<tmpdir>/{REPO_NAME}/testdata/` — test data files (SQL scripts, configs, etc.)
+- `<tmpdir>/{REPO_NAME}/pom.xml` or `go.mod` — build config
+
+1. Read `guide/{SLUG}/index.adoc` to get the guide content.
+2. Find all `include::{codebase}/path/to/file[]` directives. The `{codebase}` attribute points to a remote URL, but since you have the repo cloned, read the files directly from disk instead (e.g. `include::{codebase}/src/main/java/Foo.java[]` → read `<tmpdir>/{REPO_NAME}/src/main/java/Foo.java`).
+3. If includes have `[lines="X..Y"]`, extract only those lines from the local file.
+4. Note the `[source,lang]` block preceding each include — that determines the code fence language.
+
+This cloned repo also serves as the base for Step 6 (code verification) — you can run the tests directly in it to confirm they pass before updating the code to the latest API.
+
+## Step 2: Convert AsciiDoc to Markdown
+
+| AsciiDoc | Markdown |
+|---|---|
+| `== Heading` | `## Heading` |
+| `=== Heading` | `### Heading` |
+| `*bold*` (AsciiDoc bold) | `**bold**` |
+| `https://url[Link text]` | `[Link text](url)` |
+| `[source,lang]\n----\ncode\n----` | `` ```lang\ncode\n``` `` |
+| `[source,shell]` with `$` prompts | `` ```console `` |
+| `[NOTE]\ntext` or `====\n[NOTE]\n...\n====` | `> [!NOTE]\n> text` |
+| `[TIP]\ntext` | `> [!TIP]\n> text` |
+| `:toc:`, `:toclevels:`, `:codebase:` | Remove entirely |
+| `include::{codebase}/path[]` | Replace with fetched code in a code fence |
+| YAML front matter (date, draft, repo) | Remove; transform to Docker docs format |
+
+## Step 3: Apply Docker docs style rules
+
+These are mandatory (from STYLE.md and AGENTS.md):
+
+- **No "we"**: "We are going to create" → "Create" or "Start by creating"
+- **No "let us" / "let's"**: → imperative voice or "You can..."
+- **No hedge words**: remove "simply", "easily", "just", "seamlessly"
+- **No meta-commentary**: remove "it's worth noting", "it's important to understand"
+- **No "allows you to" / "enables you to"**: → "lets you" or rephrase
+- **No "click"**: → "select"
+- **No bold for emphasis or product names**: only bold UI elements
+- **No time-relative language**: remove "currently", "new", "recently", "now"
+- **No exclamations**: remove "Voila!!!" etc.
+- Use `console` language hint for interactive shell blocks with `$` prompts
+- Use contractions: "it's", "you're", "don't"
+
+## Step 4: Update code to latest Testcontainers API
+
+Research the latest API version for the target language before writing code.
+
+**Best practices reference**: The Testcontainers team maintains Claude skills with up-to-date API patterns and best practices for each language at https://github.com/testcontainers/claude-skills/ — check the relevant language skill (testcontainers-go, testcontainers-node, testcontainers-dotnet) for current API signatures, cleanup patterns, wait strategies, and anti-patterns to avoid.
+
+For each language, check the cloned repo's existing code, then update to the latest API. Key patterns per language:
+
+**Go** (testcontainers-go v0.41.0):
+- `postgres.RunContainer(ctx, opts...)` → `postgres.Run(ctx, "image", opts...)`
+- `testcontainers.WithImage(...)` → image is now the 2nd positional param to `Run()`
+- Manual `WithWaitStrategy(wait.ForLog(...))` → `postgres.BasicWaitStrategies()`
+- `t.Cleanup(func() { ctr.Terminate(ctx) })` → `testcontainers.CleanupContainer(t, ctr)`
+- `if err != nil { log.Fatal(err) }` → `require.NoError(t, err)` (use testify require/assert)
+- Helper functions should accept `t *testing.T` as first param, call `t.Helper()`
+- No `TearDownSuite()` needed if `CleanupContainer` is registered in the helper
+- Go version prerequisite: 1.25+
+
+**Java** (testcontainers-java 2.0.4):
+- Artifacts renamed in 2.x: `org.testcontainers:postgresql` → `org.testcontainers:testcontainers-postgresql`
+- Check the latest version at https://java.testcontainers.org/
+- Use `@Testcontainers` and `@Container` annotations for JUnit 5 lifecycle
+- Prefer module-specific containers (e.g. `PostgreSQLContainer`) over `GenericContainer`
+- Use `@DynamicPropertySource` for Spring Boot integration
+
+**.NET** (testcontainers-dotnet):
+- Check the latest NuGet package version
+- Use `IAsyncLifetime` for container lifecycle in xUnit
+- Use builder pattern: `new PostgreSqlBuilder().Build()`
+
+**Node.js** (testcontainers-node):
+- Check the latest npm version
+- Use module-specific packages (e.g. `@testcontainers/postgresql`)
+- Use `GenericContainer` for services without a dedicated module
+
+**Python** (testcontainers-python):
+- Check the latest PyPI version
+- Use context managers (`with PostgresContainer() as postgres:`)
+- Use module-specific containers when available
+
+For all languages: consult the corresponding Testcontainers skill at https://github.com/testcontainers/claude-skills/ for current best practices and anti-patterns.
+
+## Step 5: Create guide directory structure
+
+Directory: `content/guides/testcontainers-{LANG}-{GUIDE_ID}/`
+
+Each guide is its own top-level entry under `/guides/`. Do NOT nest guides inside a shared parent section — otherwise they won't appear individually in the tag/language filters on the guides listing page.
+
+### _index.md (landing page)
+
+```yaml
+---
+title: {Full guide title}
+linkTitle: {Short title for guides listing}
+description: {One-line description}
+keywords: testcontainers, {lang}, testing, {technologies used}
+summary: |
+  {2-3 line summary for the guides listing card}
+toc_min: 1
+toc_max: 2
+tags: [testing-with-docker]
+languages: [{lang}]
+params:
+  time: {estimated} minutes
+---
+
+<!-- Source: https://github.com/testcontainers/{REPO_NAME} -->
+```
+
+Content: what you'll learn (bulleted list), prerequisites, and a NOTE linking to `https://testcontainers.com/getting-started/` for newcomers.
+
+### Sub-pages (chapters)
+
+Split the guide into logical chapters. Each sub-page:
+
+```yaml
+---
+title: {Chapter title}
+linkTitle: {Short title for stepper}
+description: {One-line description}
+weight: {10, 20, 30, ...}
+---
+```
+
+**No `tags`, `languages`, or `params` on sub-pages** — only on `_index.md`.
+
+Typical chapter breakdown:
+| Weight | File | Content |
+|--------|------|---------|
+| 10 | `create-project.md` | Project setup, dependencies, business logic |
+| 20 | `write-tests.md` | First test using testcontainers |
+| 30 | `test-suites.md` | Reusing containers, test helpers, suites |
+| 40 | `run-tests.md` | Running tests, summary, further reading |
+
+Adapt the split to the guide's content — some guides may need fewer or more chapters.
+
+## Step 6: Verify code compiles and tests pass
+
+This is CRITICAL. The code in the guide MUST compile and all tests MUST pass. Do not skip this step.
+
+### 6a: Use the cloned repo as the verification project
+
+The repo you cloned in Step 1 (`<tmpdir>/{REPO_NAME}`) already contains a working project with all source files, build config, and tests. Use it as the starting point:
+
+```bash
+cd <tmpdir>/{REPO_NAME}
+```
+
+First, verify the **original** code compiles and tests pass before you change anything. This confirms a good baseline.
+
+### 6b: Update the code in the cloned repo
+
+After confirming the original works, apply the API updates (from Step 4) directly in the cloned repo's source files. This is the same code you're putting in the guide — keep them in sync.
+
+### 6c: Update dependencies and compile
+
+Run compilation inside a container for reproducibility — no need to install the language toolchain on the host. Use the appropriate language Docker image, mounting the cloned repo:
+
+```bash
+docker run --rm -v "<tmpdir>/{REPO_NAME}":/app -w /app <language-image> sh -c "<compile command>"
+```
+
+Pick the right image for the language (e.g. `golang:1.25-alpine`, `maven:3-eclipse-temurin-21`, `gradle:jdk21`, `mcr.microsoft.com/dotnet/sdk:9.0`, `node:22-alpine`, `python:3.13-alpine`). Update dependencies to the latest Testcontainers version and compile.
+
+If compilation fails, fix the code and update the guide markdown to match.
+
+### 6d: Run tests in a container with Docker socket mounted
+
+Run tests in the same kind of container, but **mount the Docker socket** so Testcontainers can create sibling containers.
+
+#### macOS Docker Desktop workarounds
+
+When running on macOS with Docker Desktop, these environment variables and flags are **required**:
+
+- **`TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal`** — On macOS, containers can't reach sibling containers via the Docker bridge IP (`172.17.0.x`). This tells Testcontainers (including Ryuk) to connect via `host.docker.internal` instead. **Do NOT disable Ryuk** — it is a core Testcontainers feature and the guides must demonstrate proper usage.
+- **`docker-java.properties`** with `api.version=1.47` — Docker Desktop's minimum API version is 1.44, but docker-java defaults to 1.24. Create this file in the project root and mount it to `/root/.docker-java.properties` inside Java containers.
+- **`-Dspotless.check.skip=true`** — The Spotless Maven plugin in the source repos is incompatible with JDK 21. Skip it since it's a code formatter, not part of the test.
+- **`-Dmicronaut.test.resources.enabled=false`** — Micronaut's Test Resources service starts a separate process that can't connect to Docker from inside a container. The guide tests use Testcontainers directly, not Test Resources. Only needed for Micronaut guides.
+#### Java guide test command
+
+```bash
+# Create docker-java.properties in the project root
+echo "api.version=1.47" > <tmpdir>/{REPO_NAME}/docker-java.properties
+
+docker run --rm \
+  -v "<tmpdir>/{REPO_NAME}":/app \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  -v "<tmpdir>/{REPO_NAME}/docker-java.properties":/root/.docker-java.properties \
+  -e DOCKER_HOST=unix:///var/run/docker.sock \
+  -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \
+  -w /app \
+  maven:3.9-eclipse-temurin-21 \
+  mvn -B test -Dspotless.check.skip=true -Dspotless.apply.skip=true
+```
+
+For Quarkus guides, use `maven:3.9-eclipse-temurin-17` instead (Quarkus 3.22.3 compiles for Java 17).
+
+#### Go guide test command
+
+```bash
+docker run --rm \
+  -v "<tmpdir>/{REPO_NAME}":/app \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  -e DOCKER_HOST=unix:///var/run/docker.sock \
+  -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \
+  -w /app \
+  golang:1.25-alpine \
+  sh -c "apk add --no-cache gcc musl-dev && go test -v -count=1 ./..."
+```
+
+#### Python guide test command
+
+```bash
+docker run --rm \
+  -v "<tmpdir>/{REPO_NAME}":/app \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  -e DOCKER_HOST=unix:///var/run/docker.sock \
+  -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \
+  -w /app \
+  python:3.13-slim \
+  sh -c "pip install -r requirements.txt && python -m pytest"
+```
+
+#### .NET guide test command
+
+```bash
+docker run --rm \
+  -v "<tmpdir>/{REPO_NAME}":/app \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  -e DOCKER_HOST=unix:///var/run/docker.sock \
+  -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \
+  -w /app \
+  mcr.microsoft.com/dotnet/sdk:9.0 \
+  dotnet test
+```
+
+#### Node.js guide test command
+
+```bash
+docker run --rm \
+  -v "<tmpdir>/{REPO_NAME}":/app \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  -e DOCKER_HOST=unix:///var/run/docker.sock \
+  -e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal \
+  -w /app \
+  node:22-alpine \
+  sh -c "npm install && npm test"
+```
+
+#### Important: run tests sequentially
+
+Run guide tests **one at a time**. Running multiple concurrent DinD or sibling-container tests can overwhelm Docker Desktop's containerd store and cause `meta.db: input/output error` corruption, requiring a Docker Desktop restart.
+
+### 6e: Fix until green
+
+If any test fails, debug and fix the code in both the temporary project AND the guide markdown. Re-run until all tests pass. Do not proceed until verified.
+
+## Step 7: Update cross-references
+
+1. **`content/manuals/testcontainers.md`**: Add a bullet under the `## Guides` section:
+   ```markdown
+   - [Guide title](/guides/testcontainers-{LANG}-{GUIDE_ID}/)
+   ```
+2. **Do NOT update** `content/guides/testcontainers-cloud/_index.md` — keep its external links.
+3. Link to `https://testcontainers.com/getting-started/` for the Testcontainers overview.
+4. Use internal paths for already-migrated guides; keep `testcontainers.com` links for unmigrated ones.
+
+## Step 8: Validate
+
+**IMPORTANT**: Run ALL validation locally before committing. Vale checks run on CI and will block the PR if they fail — fixing after push wastes CI cycles and review time.
+
+1. `npx --no-install rumdl fmt content/guides/testcontainers-{LANG}-{GUIDE_ID}/`
+2. `npx --no-install rumdl fmt content/manuals/testcontainers.md`
+3. `docker buildx bake lint` — must pass with no errors
+4. `docker buildx bake vale` — then check for errors in the new files:
+   ```bash
+   grep -A2 "testcontainers-{LANG}-{GUIDE_ID}" tmp/vale.out
+   ```
+   Fix ALL errors before proceeding. Common issues:
+   - **Vale.Spelling**: tech terms (library names, tools) not in the dictionary → add to `_vale/config/vocabularies/Docker/accept.txt` (alphabetical order)
+   - **Vale.Terms**: wrong casing (e.g. "python" → "Python") → fix in the markdown. Watch for package names like `testcontainers-python` triggering false positives — rephrase to "Testcontainers for Python" in prose.
+   - **Docker.Avoid**: hedge words like "very", "simply" → reword
+   - **Docker.We**: first-person plural → rewrite to "you" or imperative
+   - Info-level suggestions (e.g. "VS Code" → "versus") are not blocking but review them
+
+   Re-run `docker buildx bake vale` after fixes until no errors remain in the new files.
+5. Verify in local dev server (`HUGO_PORT=1314 docker compose watch`):
+   - Guide appears when filtering by its language
+   - Guide appears when filtering by `Testing with Docker` tag
+   - Stepper navigation works across chapters
+   - All links resolve (no 404s)
+6. Verify all external URLs return 200:
+   ```bash
+   curl -s -o /dev/null -w "%{http_code}" -L "{url}"
+   ```
+
+## Step 9: Commit
+
+One commit per guide. Message format:
+```
+feat(guides): add testcontainers {lang} {guide-id} guide
+
+Migrated from https://github.com/testcontainers/{REPO_NAME}
+Updated to testcontainers-{lang} v{version} API.
+```
+
+## Special cases
+
+- **introducing-testcontainers**: Language-agnostic, conceptual. May overlap with `content/manuals/testcontainers.md`. Review for deduplication before migrating.
+- **local-dev-testcontainers-desktop**: About Testcontainers Desktop (now part of Docker Desktop). May need significant rewriting rather than mechanical migration.
+- **Java guides**: Many share the same language. Each still gets its own `testcontainers-java-{GUIDE_ID}` directory.
+
+## Reference: completed migration (Go getting-started)
+
+Use `content/guides/testcontainers-go-getting-started/` as the reference implementation:
+- `_index.md` — landing page with frontmatter, prerequisites, learning objectives
+- `create-project.md` (weight: 10) — project setup and business logic
+- `write-tests.md` (weight: 20) — first test with testcontainers-go
+- `test-suites.md` (weight: 30) — container reuse with testify suites
+- `run-tests.md` (weight: 40) — running tests, summary, further reading
diff --git a/.agents/skills/triage-issue/SKILL.md b/.agents/skills/triage-issue/SKILL.md
new file mode 100644
index 000000000000..c4fcf19bb855
--- /dev/null
+++ b/.agents/skills/triage-issue/SKILL.md
@@ -0,0 +1,150 @@
+---
+name: triage-issue
+description: >
+  Analyze a single GitHub issue for docker/docs — check whether the problem
+  still exists, determine a verdict, and report findings. Use when asked to
+  triage, assess, or review an issue, even if the user doesn't say "triage"
+  explicitly: "triage issue 1234", "is issue 500 still valid", "should we
+  close #200", "look at this issue", "what's going on with #200".
+argument-hint: "<issue-number>"
+context: fork
+---
+
+# Triage Issue
+
+Given GitHub issue **$ARGUMENTS** from docker/docs, figure out whether
+it's still a real problem and say what should happen next.
+
+## 1. Fetch the issue
+
+```bash
+gh issue view $ARGUMENTS --repo docker/docs \
+  --json number,title,body,state,labels,createdAt,updatedAt,closedAt,assignees,author,comments
+```
+
+## 2. Understand the problem
+
+Read the issue body and all comments. Identify:
+
+- What is the reported problem?
+- What content, URL, or file does it reference?
+- Has anyone already proposed a fix or workaround in the comments?
+
+Check for linked PRs in the issue timeline, not only in the issue body or
+comments:
+
+```bash
+gh api repos/docker/docs/issues/$ARGUMENTS/timeline --paginate \
+  --jq '.[] | select(.event=="cross-referenced" or .event=="connected" or .event=="referenced") | {event, created_at, source: .source.issue.html_url, title: .source.issue.title, state: .source.issue.state}'
+```
+
+If an open PR already addresses the issue, don't open another PR. Review the
+existing PR instead, and report that the issue already has an associated PR. A
+merged PR is strong evidence the issue is fixed. A closed-without-merge PR means
+the issue is likely still open.
+
+## 3. Follow URLs
+
+Find all `docs.docker.com` URLs in the issue body and comments. For each:
+
+- Fetch the URL to check if it still exists (404 = content removed or moved)
+- Check whether the content still contains the problem described
+- Note when the page was last updated relative to when the issue was filed
+
+For non-docs URLs (GitHub links, external references), fetch them too if
+they are central to understanding the issue.
+
+## 4. Check the repository
+
+If the issue references specific files, content sections, or code:
+
+- Find and read the current version of that content
+- Check whether the problem has been fixed, content moved, or file removed
+- Remember the `/manuals` prefix mapping when looking up files
+
+## 5. Check for upstream ownership
+
+If the issue is about content in `_vendor/` or `data/cli/`, it cannot be
+fixed here. Identify which upstream repo owns it (see the vendored content
+table in CLAUDE.md).
+
+## 6. Decide and act
+
+After investigating, pick one of these verdicts and take the corresponding
+action on the issue:
+
+- **Close it** — the problem is already fixed, the content no longer exists,
+  or the issue is too outdated to be useful. Close the issue with a comment
+  explaining why:
+
+  ```bash
+  gh issue close $ARGUMENTS --repo docker/docs \
+    --comment "Closing: <one-sentence reason>"
+  ```
+
+- **Fix it** — the problem is real and fixable in this repo. Name the
+  file(s) and what needs to change. Label the issue `status/confirmed` and
+  remove `status/triage` if present:
+
+  ```bash
+  gh api repos/docker/docs/issues/$ARGUMENTS/labels \
+    --method POST --field 'labels[]=status/confirmed'
+  gh api repos/docker/docs/issues/$ARGUMENTS/labels/status%2Ftriage \
+    --method DELETE || true
+  ```
+
+- **Escalate upstream** — the problem is real but lives in vendored content.
+  Name the upstream repo. Label the issue `status/upstream` and remove
+  `status/triage` if present:
+
+  ```bash
+  gh api repos/docker/docs/issues/$ARGUMENTS/labels \
+    --method POST --field 'labels[]=status/upstream'
+  gh api repos/docker/docs/issues/$ARGUMENTS/labels/status%2Ftriage \
+    --method DELETE || true
+  ```
+
+- **Leave it open** — you can't determine the current state, or the issue
+  needs human judgment. Label the issue `status/needs-analysis`:
+
+  ```bash
+  gh api repos/docker/docs/issues/$ARGUMENTS/labels \
+    --method POST --field 'labels[]=status/needs-analysis'
+  gh api repos/docker/docs/issues/$ARGUMENTS/labels/status%2Ftriage \
+    --method DELETE || true
+  ```
+
+Don't overthink the classification. An old issue isn't stale if the problem
+still exists. An upstream issue is still valid — it's just not fixable here.
+
+Also apply the most relevant `area/` label based on the content affected.
+Available area labels: `area/accounts`, `area/admin`, `area/ai`,
+`area/api`, `area/billing`, `area/build`, `area/build-cloud`, `area/cli`,
+`area/compose`, `area/compose-spec`, `area/config`, `area/contrib`,
+`area/copilot`, `area/desktop`, `area/dhi`, `area/engine`,
+`area/enterprise`, `area/extensions`, `area/get-started`, `area/guides`,
+`area/hub`, `area/install`, `area/networking`, `area/offload`,
+`area/release-notes`, `area/samples`, `area/scout`, `area/security`,
+`area/storage`, `area/subscription`, `area/swarm`, `area/ux`. Pick one
+(or at most two if the issue clearly spans areas). Skip if none fit.
+
+```bash
+gh api repos/docker/docs/issues/$ARGUMENTS/labels \
+  --method POST --field 'labels[]=area/<name>'
+```
+
+## 7. Report
+
+Write a short summary: what the issue reports, what you found, and what
+should happen next. Reference the specific files, URLs, or PRs that support
+your conclusion. Skip metadata fields — the issue itself has the dates and
+labels. Mention the action you took (closed, labeled, etc.).
+
+## Notes
+
+- Always check timeline cross-references before deciding to fix an issue
+- Do not narrate your process — produce the final report
+- End every issue comment with an accurate agent-disclosure footer that names
+  the active coding agent, for example `Generated by Codex` or `Generated by
+Claude Code`.
+.
diff --git a/.agents/skills/write/SKILL.md b/.agents/skills/write/SKILL.md
new file mode 100644
index 000000000000..1b6879aa7d84
--- /dev/null
+++ b/.agents/skills/write/SKILL.md
@@ -0,0 +1,87 @@
+---
+name: write
+description: >
+  Write a documentation fix on a branch. Makes the minimal change, formats,
+  self-reviews, and commits. Use after research has identified what to change.
+  "write the fix", "make the changes", "implement the fix for #1234".
+hooks:
+  PostToolUse:
+    - matcher: "Edit|Write"
+      hooks:
+        - type: command
+          command: "bash ${CLAUDE_SKILL_DIR}/scripts/post-edit.sh"
+---
+
+# Write
+
+Make the minimal change that resolves the issue. Research has already
+identified what to change — this skill handles the edit, formatting,
+self-review, and commit.
+
+## 1. Create a branch
+
+```bash
+git checkout -b fix/issue-<number>-<short-desc> main
+```
+
+Use a short kebab-case description derived from the issue title (3-5 words).
+
+## 2. Read then edit
+
+Always read each file before modifying it. Make the minimal change that
+fixes the issue. Do not improve surrounding content, add comments, or
+address adjacent problems.
+
+Follow the writing guidelines in CLAUDE.md, STYLE.md, and COMPONENTS.md.
+
+## 3. Front matter check
+
+Every content page requires `title`, `description`, and `keywords` in its
+front matter. If any are missing from a file you touch, add them.
+
+## 4. Validate
+
+rumdl runs automatically after each edit via the PostToolUse hook.
+Run lint manually after all edits are complete:
+
+```bash
+scripts/lint.sh <changed-files>
+```
+
+The lint script runs rumdl and Vale on only the files you pass it,
+so the output is scoped to your changes. Fix any errors it reports.
+
+## 5. Self-review
+
+Re-read each changed file: right file, right lines, change is complete,
+front matter is present. Run `git diff` and verify only intended changes
+are present.
+
+## 6. Commit
+
+Stage only the changed files:
+
+```bash
+git add <files>
+git diff --cached --name-only  # verify — no package-lock.json or other noise
+git commit -m "$(cat <<'EOF'
+docs: <short description under 72 chars> (fixes #NNNN)
+
+<What was wrong: one sentence citing the specific problem.>
+<What was changed: one sentence describing the exact edit.>
+
+Co-Authored-By: Claude <noreply@anthropic.com>
+EOF
+)"
+```
+
+The commit body is mandatory. A reviewer reading only the commit should
+understand the problem and the fix without opening the issue.
+
+## Notes
+
+- Never edit `_vendor/` or `data/cli/` — these are vendored
+- If a file doesn't exist, check for renames:
+  `git log --all --full-history -- "**/filename.md"`
+- If the fix requires a URL that cannot be verified, stop and report a
+  blocker rather than guessing
diff --git a/.agents/skills/write/scripts/post-edit.sh b/.agents/skills/write/scripts/post-edit.sh
new file mode 100755
index 000000000000..73ac30611824
--- /dev/null
+++ b/.agents/skills/write/scripts/post-edit.sh
@@ -0,0 +1,12 @@
+#!/bin/bash
+# PostToolUse hook for Edit/Write in the write skill.
+# Auto-formats Markdown files with rumdl after each edit.
+set -euo pipefail
+
+input=$(cat)
+file_path=$(echo "$input" | jq -r '.tool_input.file_path // empty')
+
+[ -z "$file_path" ] && exit 0
+[[ "$file_path" != *.md ]] && exit 0
+
+npx --no-install rumdl fmt "$file_path" 2>/dev/null
diff --git a/.claude b/.claude
new file mode 120000
index 000000000000..c0ca46856636
--- /dev/null
+++ b/.claude
@@ -0,0 +1 @@
+.agents
\ No newline at end of file
diff --git a/.dockerignore b/.dockerignore
index 24fffe8d3b34..ff3cf374b3bc 100644
--- a/.dockerignore
+++ b/.dockerignore
@@ -3,6 +3,7 @@
 .gitignore
 .idea
 .hugo_build.lock
+hugo_stats.json
 _releaser
 CONTRIBUTING.md
 Dockerfile
diff --git a/.gitattributes b/.gitattributes
index 2929076bea1e..5d685b7d139e 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -3,3 +3,11 @@
 
 # Fine-tune GitHub's language detection
 content/**/*.md linguist-detectable
+
+# Mark generated and vendored content
+# These files should not be edited directly in this repository
+
+# Vendored Hugo modules (from upstream repositories)
+/_vendor/** linguist-generated=true
+# Generated CLI reference data (vendored from upstream)
+/data/cli/** linguist-generated=true
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 7c8329fc10fc..9d959ab3647a 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -3,9 +3,9 @@
 
 # For more details, see https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
 
-/content/manuals/build/ @crazy-max @aevesdocker
+/content/manuals/build/ @dvdksn
 
-/content/manuals/build-cloud/ @crazy-max @aevesdocker 
+/content/manuals/build-cloud/ @craig-osterhout
 
 /content/manuals/compose/ @aevesdocker
 
@@ -19,26 +19,28 @@
 
 /content/manuals/docker-hub/ @craig-osterhout
 
-/content/manuals/engine/ @thaJeztah @aevesdocker 
+/content/manuals/engine/ @dvdksn
 
-/content/reference/api/engine/ @thaJeztah @aevesdocker 
+/content/reference/api/engine/ @dvdksn
 
-/content/reference/cli/ @thaJeztah @aevesdocker 
+/content/reference/cli/ @dvdksn
 
 /content/manuals/subscription/ @sarahsanders-docker
 
 /content/manuals/security/ @aevesdocker @sarahsanders-docker
 
-/content/manuals/trusted-content/ @craig-osterhout
-
-/content/manuals/docker-hub/official_images/ @craig-osterhout
-
-/content/manuals/registry/ @craig-osterhout
-
 /content/manuals/admin/ @sarahsanders-docker
 
 /content/manuals/billing/ @sarahsanders-docker
 
 /content/manuals/accounts/ @sarahsanders-docker
 
-/_vendor @sarahsanders-docker
+/content/manuals/ai/ @dvdksn
+
+/content/manuals/ai/sandboxes/governance/ @craig-osterhout
+
+/_vendor @dvdksn
+
+/content/manuals/offload/ @craig-osterhout
+
+/content/manuals/dhi/ @craig-osterhout
diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml
index 8762e0feb7a1..33e46038c05d 100644
--- a/.github/ISSUE_TEMPLATE/config.yml
+++ b/.github/ISSUE_TEMPLATE/config.yml
@@ -6,15 +6,9 @@ contact_links:
   - name: Moby
     url: https://github.com/moby/moby/issues
     about: Bug reports for Docker Engine
-  - name: Docker Desktop for Windows
-    url: https://github.com/docker/for-win/issues
-    about: Bug reports for Docker Desktop for Windows 
-  - name: Docker Desktop for Mac
-    url: https://github.com/docker/for-mac/issues
-    about: Bug reports for Docker Desktop for Mac 
-  - name: Docker Desktop for Linux
-    url: https://github.com/docker/for-linux/issues
-    about: Bug reports for Docker Desktop for Linux 
+  - name: Docker Desktop
+    url: https://github.com/docker/desktop-feedback
+    about: Bug reports for Docker Desktop
   - name: Docker Compose
     url: https://github.com/docker/compose/issues
     about: Bug reports for Docker Compose
diff --git a/.github/agents/docs-scanner.yaml b/.github/agents/docs-scanner.yaml
new file mode 100644
index 000000000000..88b660f64b4e
--- /dev/null
+++ b/.github/agents/docs-scanner.yaml
@@ -0,0 +1,189 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/docker/docker-agent/refs/heads/main/cagent-schema.json
+models:
+  claude-sonnet:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    max_tokens: 8192
+    temperature: 0.3
+
+agents:
+  root:
+    model: claude-sonnet
+    description: Daily documentation quality scanner for Docker docs
+    add_prompt_files:
+      - STYLE.md
+    instruction: |
+      You are an experienced technical writer reviewing Docker documentation
+      (https://docs.docker.com/) for substantive quality problems. The docs
+      are maintained in this repository under content/. Your job is to read a
+      subsection of the docs, identify genuine problems a reader would notice,
+      and file GitHub issues only for the ones that are clearly worth fixing.
+
+      ## Setup
+
+      1. Read `.cache/scan-history.json` using `read_file`.
+         This file tracks every previously scanned directory as a JSON object:
+         ```json
+         {
+           "scanned": {
+             "content/manuals/desktop/networking/": "2026-02-24",
+             "content/manuals/build/cache/": "2026-02-23"
+           }
+         }
+         ```
+         If the file does not exist or is empty, treat it as `{"scanned": {}}`.
+
+      2. Call `get_memories` to load any learned patterns from previous scans
+         (false positives to skip, codebase context, human feedback).
+
+      3. Use `list_directory` to explore `content/manuals/` and find all leaf
+         directories (no subdirectories). Skip these top-level paths entirely:
+         content/reference/, content/languages/, content/tags/,
+         content/includes/.
+
+      4. Pick a leaf directory to scan:
+         - FIRST CHOICE: a directory that does NOT appear in scan-history.json
+         - FALLBACK: if every leaf directory has been scanned, pick the one
+           with the OLDEST date in scan-history.json
+
+      5. Call `directory_tree` on the selected leaf and read ALL its files.
+         Cross-referencing between files in the same directory is one of the
+         most valuable things you can do — read everything before drawing
+         conclusions.
+
+      6. Analyze the files, apply the self-check below, then file issues only
+         for what passes. **File only what is genuinely worth fixing.** If you
+         find one strong issue, file one. If you find nothing substantive, file
+         zero. A run with zero issues is a success, not a failure. Do not
+         search for issues to fill a quota.
+
+      7. After scanning, update `.cache/scan-history.json` using `write_file`.
+         Read the current content, add or update the scanned path with today's
+         date (YYYY-MM-DD), and write the full updated JSON back.
+
+      8. If you learn anything useful for future scans (false positive patterns,
+         codebase context), call `add_memory` to store it. Do NOT use
+         `add_memory` for scan tracking — that is what scan-history.json is for.
+
+      ## What good issues look like
+
+      Ask yourself: would a reader following this documentation be confused or
+      misled? The bar is high. File issues only when the answer is clearly yes.
+
+      - **Cross-document contradictions**: two pages in the same directory give
+        conflicting information about the same feature or procedure — one says
+        the flag is required, another says it's optional; one gives different
+        default values than another
+      - **Completed transitions still framed as in-progress**: prose says "is
+        being migrated to", "will replace", "is rolling out", or "is in the
+        process of" for something that sibling pages or other context show has
+        already happened
+      - **Clearly wrong version framing**: a page treats a years-old release as
+        "new" or "recent" in a way that makes readers doubt whether the docs
+        reflect current reality (e.g. "Docker Engine 23.0 introduced this" where
+        23.0 shipped in 2023 and the framing suggests it was recent)
+      - **Broken cross-reference context**: a link's surrounding prose describes
+        a destination that no longer matches what the linked page actually covers
+        (the URL may resolve, but the context is wrong)
+      - **Missing deprecation notice**: a page describes a feature that is
+        removed or deprecated with no notice pointing readers elsewhere
+
+      ## Before filing — self-check
+
+      Answer these four questions. If you can't answer 1 and 2 with yes, or if
+      3 or 4 is yes, do not file the issue.
+
+      1. Can I quote the specific wrong text from the file?
+      2. Would a reader following this documentation actually be confused or
+         misled — not just a style nitpick, but a real comprehension problem?
+      3. Is this something already caught by automated tooling?
+         - Broken or missing links → htmltest catches these; do not file
+         - Time-relative words ("currently", "recently", "still", "yet",
+           "new") with no broader context problem → Vale catches these
+         - Formatting or style problems → rumdl/Vale catch these
+      4. Is this a legitimate product feature gate? "Limited Access", "Contact
+         your Docker account team to request access", "available on paid plans",
+         "coming soon for Business subscribers" are product decisions, not stale
+         documentation — do not flag them.
+
+      ## What not to file
+
+      - **Broken links** — htmltest catches these; do not file. This includes
+        links to non-existent files within the repo ("broken cross-reference"
+        is still a broken link). Only file if the URL resolves but the
+        surrounding prose misdescribes the destination.
+      - **Single time-relative words** in otherwise accurate sentences —
+        "currently", "recently", "still", "yet", "usually" — Vale already flags
+        these; your job is to find problems Vale can't see
+      - **Feature gates and access tiers** — "Limited Access" badges, "Contact
+        sales", "request access" language — these are intentional product
+        decisions
+      - **Vague verification tasks** — "verify this diagram is up to date",
+        "check these links are still valid" — if you cannot identify the
+        specific problem from reading the file, don't file
+      - **Style and formatting** — Vale and rumdl handle these
+      - **Suspicions without evidence** — you must quote the specific wrong text
+
+      ## Filing issues
+
+      Check for duplicates first:
+      ```bash
+      FILE_PATH="path/to/file.md"
+      gh issue list --repo docker/docs --label "agent/generated" --state open --search "in:body \"$FILE_PATH\""
+      ```
+
+      Then create:
+      ```bash
+      ISSUE_TITLE="[docs-scanner] Brief description"
+      cat << 'EOF' | gh issue create \
+        --repo docker/docs \
+        --title "$ISSUE_TITLE" \
+        --label "agent/generated" \
+        --body-file -
+      **File:** `path/to/file.md`
+
+      ### Issue
+
+      What's wrong, with an exact quote from the file:
+
+      > quoted text
+
+      ### Why this matters
+
+      Explain how a reader would be confused or misled by this.
+
+      ### Suggested fix
+
+      What should change, with specific alternative wording where possible.
+
+      ---
+      *Found by nightly documentation quality scanner*
+      EOF
+      ```
+
+      ## Output
+
+      ```
+      SCAN COMPLETE
+      Subsection: content/manuals/desktop/features/
+      Files checked: N
+      Issues created: N (or "0 — nothing substantive found")
+      - #123: [docs-scanner] Issue title
+      ```
+
+    toolsets:
+      - type: filesystem
+        tools:
+          - read_file
+          - read_multiple_files
+          - write_file
+          - list_directory
+          - directory_tree
+      - type: memory
+        path: .cache/scanner-memory.db
+      - type: shell
+
+permissions:
+  allow:
+    - shell:cmd=gh issue list --*
+    - shell:cmd=gh issue create --*
diff --git a/.github/agents/whats-new-examples/2026-07-13--2026-08-11.json b/.github/agents/whats-new-examples/2026-07-13--2026-08-11.json
new file mode 100644
index 000000000000..0277ac5b85c3
--- /dev/null
+++ b/.github/agents/whats-new-examples/2026-07-13--2026-08-11.json
@@ -0,0 +1,96 @@
+{
+  "period_start": "2026-07-13",
+  "period_end": "2026-08-11",
+  "items": [
+    {
+      "product": "Docker Desktop",
+      "title": "Use Docker VMM on Mac and Windows",
+      "description": "Run Docker Desktop with Docker's container-optimized hypervisor on supported Mac and Windows systems.",
+      "url": "/desktop/features/vmm/",
+      "published": "2026-08-10",
+      "source_prs": [25702, 25726],
+      "featured": true
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Connect sandboxes through an MCP gateway",
+      "description": "Register local or remote MCP servers on the host, reuse them across sandboxes, and govern server and tool access with Cedar policies.",
+      "url": "/ai/sandboxes/mcp-gateway/",
+      "published": "2026-08-06",
+      "source_prs": [25559, 25707],
+      "featured": true
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Author version 2 sandbox kits",
+      "description": "Define kit setup, permissions, networking, and API key or OAuth credential requirements with the version 2 kit schema.",
+      "url": "/ai/sandboxes/customize/kit-reference/#schema-versions",
+      "published": "2026-08-06",
+      "source_prs": [25467, 25707],
+      "featured": false
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Run Claude Code with local models",
+      "description": "Route Claude Code sandbox requests to the bundled local-model server or an existing Ollama installation.",
+      "url": "/ai/sandboxes/agents/claude-code/#use-a-local-model",
+      "published": "2026-08-06",
+      "source_prs": [25641, 25707],
+      "featured": false
+    },
+    {
+      "product": "Docker AI Governance",
+      "title": "Search and forward audit events",
+      "description": "Search and export policy decisions from Docker Cloud, or forward events to Splunk, Dynatrace, and custom HTTPS endpoints.",
+      "url": "/ai/sandboxes/governance/audit/",
+      "published": "2026-08-03",
+      "source_prs": [25679, 25687],
+      "featured": true
+    },
+    {
+      "product": "Docker Desktop",
+      "title": "Install from the Microsoft Store without administrator privileges",
+      "description": "Fresh Microsoft Store installations on Windows use per-user mode by default.",
+      "url": "/desktop/release-notes/#4850",
+      "published": "2026-08-03",
+      "source_prs": [25665],
+      "featured": false
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Share agent skills across sandboxes",
+      "description": "Import skills from supported host agents into a persistent store that sandboxes can share.",
+      "url": "/ai/sandboxes/workflows/#share-agent-skills",
+      "published": "2026-07-24",
+      "source_prs": [25588],
+      "featured": false
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Connect editors and desktop apps over SSH",
+      "description": "Use a sandbox from VS Code, Cursor, Claude Desktop, ChatGPT, or another SSH-capable tool.",
+      "url": "/ai/sandboxes/integrations/",
+      "published": "2026-07-24",
+      "source_prs": [25557],
+      "featured": true
+    },
+    {
+      "product": "Docker Hardened Images",
+      "title": "Query the DHI catalog from AI assistants",
+      "description": "Search DHI repositories, inspect images, retrieve SBOMs, check CVEs, and manage mirrors through the DHI MCP server.",
+      "url": "/dhi/tools/mcp/",
+      "published": "2026-07-23",
+      "source_prs": [25589],
+      "featured": false
+    },
+    {
+      "product": "Docker Enterprise",
+      "title": "Authenticate GitHub Actions with OIDC connections",
+      "description": "Exchange GitHub OIDC tokens for short-lived access to Docker resources without storing long-lived workflow credentials.",
+      "url": "/enterprise/security/oidc-connections/",
+      "published": "2026-07-21",
+      "source_prs": [25336],
+      "featured": true
+    }
+  ]
+}
diff --git a/.github/agents/whats-new-examples/2026-07-13--2026-08-11.yaml b/.github/agents/whats-new-examples/2026-07-13--2026-08-11.yaml
new file mode 100644
index 000000000000..da5a56f64868
--- /dev/null
+++ b/.github/agents/whats-new-examples/2026-07-13--2026-08-11.yaml
@@ -0,0 +1,39 @@
+# Human-reviewed example and regression criteria for the curate-whats-new skill.
+# This file is not loaded into the skill's runtime context.
+period_start: 2026-07-13
+period_end: 2026-08-11
+example_output: 2026-07-13--2026-08-11.json
+
+expected_archive:
+  - Docker VMM on Mac and Windows
+  - Docker Sandboxes MCP gateway
+  - Docker Sandboxes kit schema version 2
+  - Claude Code with local models
+  - Docker AI Governance audit search, export, and forwarding
+  - Microsoft Store per-user installation
+  - Shared agent skills across sandboxes
+  - Docker Sandboxes editor and app integrations
+  - Docker Hardened Images MCP server
+  - Enterprise OIDC connections
+
+featured_guidance:
+  strong:
+    - Docker VMM on Mac and Windows
+    - Docker AI Governance audit search, export, and forwarding
+    - Docker Sandboxes editor and app integrations
+    - Enterprise OIDC connections
+  either_is_reasonable:
+    - Docker Sandboxes MCP gateway
+    - Docker Sandboxes kit schema version 2
+
+must_exclude:
+  - Gordon safety modes and custom rules
+  - Swarm direct server return networking
+  - Engine image mounts
+  - Unix sockets on Windows
+  - Narrow flags, command variants, protocol options, and compatibility switches
+
+notes:
+  - Do not require product diversity.
+  - Treat featured choices as editorial judgment, not an exact golden ordering.
+  - Reject lower-level or incremental changes even when they are technically new.
diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index b34db2bb4014..4382b20c4501 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -1,7 +1,26 @@
+---
 version: 2
 updates:
-  - package-ecosystem: "github-actions"
+  - package-ecosystem: github-actions
+    directory: /
+    cooldown:
+      default-days: 7
     open-pull-requests-limit: 10
-    directory: "/"
     schedule:
-      interval: "daily"
+      interval: daily
+  - package-ecosystem: npm
+    directory: /
+    schedule:
+      interval: daily
+    allow:
+      - dependency-name: '@docker/marlin-sdk-web-public'
+    open-pull-requests-limit: 1
+
+  - package-ecosystem: gomod
+    directory: /
+    cooldown:
+      default-days: 7
+    ignore:
+      - dependency-name: '*'
+    schedule:
+      interval: weekly
diff --git a/.github/labeler.yml b/.github/labeler.yml
index 11cef0e77f6d..d7a4a910758e 100644
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@@ -1,3 +1,9 @@
+area/ai:
+  - changed-files:
+      - any-glob-to-any-file:
+          - content/manuals/ai/**
+          - content/reference/cli/model/**
+
 area/release:
   - changed-files:
       - any-glob-to-any-file:
@@ -26,7 +32,7 @@ area/tests:
   - changed-files:
       - any-glob-to-any-file:
           - .htmltest.yml
-          - .markdownlint.json
+          - .rumdl.toml
           - .vale.ini
           - _vale/**
           - hack/test/*
@@ -44,6 +50,11 @@ area/build-cloud:
       - any-glob-to-any-file:
           - content/manuals/build-cloud/**
 
+area/offload:
+  - changed-files:
+      - any-glob-to-any-file:
+          - content/manuals/offload/**
+
 area/compose:
   - changed-files:
       - any-glob-to-any-file:
@@ -56,6 +67,11 @@ area/desktop:
       - any-glob-to-any-file:
           - content/manuals/desktop/**
 
+area/dhi:
+  - changed-files:
+      - any-glob-to-any-file:
+          - content/manuals/dhi/**
+
 area/engine:
   - changed-files:
       - any-glob-to-any-file:
@@ -165,6 +181,11 @@ area/copilot:
       - any-glob-to-any-file:
           - content/manuals/copilot/**
 
+ci:
+  - changed-files:
+      - any-glob-to-any-file:
+          - .github/workflows/**
+
 hugo:
   - changed-files:
       - any-glob-to-any-file:
@@ -173,7 +194,6 @@ hugo:
           - hugo_stats.json
           - i18n/**
           - layouts/**
-          - postcss.config.js
           - static/**
           - tailwind.config.js
 
diff --git a/.github/prompts/freshness-tier1.prompt.md b/.github/prompts/freshness-tier1.prompt.md
new file mode 100644
index 000000000000..41a784ccb232
--- /dev/null
+++ b/.github/prompts/freshness-tier1.prompt.md
@@ -0,0 +1,17 @@
+---
+mode: 'edit'
+---
+
+Imagine you're an experienced technical writer. You need to review content for
+how fresh and up to date it is. Apply the following:
+
+1. Fix spelling errors and typos
+2. Verify whether the markdown structure conforms to common markdown standards
+3. Ensure the content follows our [style guide file](../instructions/styleguide-instructions.md) as a guide.
+4. Make sure the titles on the page provide better context about the content (for an improved search experience).
+5. Ensure all the components formatted correctly.
+6. Improve the SEO keywords.
+7. If you find numbered lists, make sure their numbering only uses 1's.
+8. Ensure each line is limited to 80 characters.
+
+Do your best and don't be lazy.
\ No newline at end of file
diff --git a/.github/prompts/freshness-tier2.prompt.md b/.github/prompts/freshness-tier2.prompt.md
new file mode 100644
index 000000000000..e6cd05cba72e
--- /dev/null
+++ b/.github/prompts/freshness-tier2.prompt.md
@@ -0,0 +1,23 @@
+---
+mode: 'edit'
+---
+
+Imagine you're an experienced technical writer. You need to review content for
+how fresh and up to date it is. Apply the following:
+
+1. Improve the presentational layer - components, splitting up the page into smaller pages
+   Consider the following:
+
+    1. Can you use tabs to display multiple variants of the same steps?
+    2. Can you make a key item of information stand out with a call-out?
+    3. Can you reduce a large amount of text to a series of bullet points?
+    4. Are there other code components you could use?
+2. Check if any operating systems or package versions mentioned are still current and supported
+3. Check the accuracy of the content
+4. If appropriate, follow the document from start to finish to see if steps make sense in sequence
+5. Try to add some helpful next steps to the end of the document, but only if there are no *Next steps* or *Related pages* section, already.
+6. Try to clarify, shorten or improve the efficiency of some sentences.
+7. Check for LLM readability.
+8. Ensure each line is limited to 80 characters.
+
+Do your best and don't be lazy.
diff --git a/.github/prompts/review.prompt.md b/.github/prompts/review.prompt.md
new file mode 100644
index 000000000000..47a39e8e14c5
--- /dev/null
+++ b/.github/prompts/review.prompt.md
@@ -0,0 +1,7 @@
+---
+mode: edit
+description: You are a technical writer reviewing an article for clarity, conciseness, and adherence to the documentation writing style guidelines.
+---
+Review the article for clarity, conciseness, and adherence to our documentation [style guidelines](../instructions/styleguide-instructions.md).
+
+Provide concrete and practical suggestions for improvement.
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index b62404c71e05..f92187e766b8 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -25,20 +25,19 @@ jobs:
     steps:
       -
         name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@4d04d5d9486b7bd6fa91e7baf45bbb4f8b9deedd # v4
         with:
           version: ${{ env.SETUP_BUILDX_VERSION }}
           driver-opts: image=${{ env.SETUP_BUILDKIT_IMAGE }}
       -
         name: Build
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@82490499d2e5613fcead7e128237ef0b0ea210f7 # v7
         with:
           files: |
             docker-bake.hcl
-          targets: releaser-build
-          set: |
-            *.cache-from=type=gha,scope=releaser
-            *.cache-to=type=gha,scope=releaser,mode=max
+          targets: |
+            releaser-build
+            releaser-test
 
   build:
     runs-on: ubuntu-24.04
@@ -47,24 +46,21 @@ jobs:
     steps:
       -
         name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5
       -
         name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@4d04d5d9486b7bd6fa91e7baf45bbb4f8b9deedd # v4
       -
         name: Build
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@82490499d2e5613fcead7e128237ef0b0ea210f7 # v7
         with:
           source: .
           files: |
             docker-bake.hcl
           targets: release
-          set: |
-            *.cache-from=type=gha,scope=build
-            *.cache-to=type=gha,scope=build,mode=max
       -
         name: Check Cloudfront config
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@82490499d2e5613fcead7e128237ef0b0ea210f7 # v7
         with:
           source: .
           targets: aws-cloudfront-update
@@ -74,17 +70,6 @@ jobs:
           AWS_CLOUDFRONT_ID: 0123456789ABCD
           AWS_LAMBDA_FUNCTION: DockerDocsRedirectFunction-dummy
 
-  vale:
-    if: ${{ github.event_name == 'pull_request' }}
-    runs-on: ubuntu-24.04
-    steps:
-      - uses: actions/checkout@v4
-      - uses: errata-ai/vale-action@reviewdog
-        env:
-          PIP_BREAK_SYSTEM_PACKAGES: 1
-        with:
-          files: content
-
   validate:
     runs-on: ubuntu-24.04
     strategy:
@@ -92,24 +77,35 @@ jobs:
       matrix:
         target:
           - lint
+          - vale
           - test
           - unused-media
           - test-go-redirects
           - dockerfile-lint
-          - path-warnings
+          - validate-vendor
     steps:
+      -
+        name: Checkout
+        uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5
       -
         name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@4d04d5d9486b7bd6fa91e7baf45bbb4f8b9deedd # v4
       -
         name: Validate
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@82490499d2e5613fcead7e128237ef0b0ea210f7 # v7
         with:
+          source: .
           files: |
             docker-bake.hcl
           targets: ${{ matrix.target }}
-          set: |
-            *.args.BUILDKIT_CONTEXT_KEEP_GIT_DIR=1
-            *.cache-to=type=gha,scope=validate-${{ matrix.target }},mode=max
-            *.cache-from=type=gha,scope=validate-${{ matrix.target }}
-            *.cache-from=type=gha,scope=build
+      -
+        name: Install reviewdog
+        if: ${{ matrix.target == 'vale' && github.event_name == 'pull_request' }}
+        uses: reviewdog/action-setup@d8a7baabd7f3e8544ee4dbde3ee41d0011c3a93f # v1.5.0
+      -
+        name: Run reviewdog for vale
+        if: ${{ matrix.target == 'vale' && github.event_name == 'pull_request' }}
+        run: |
+          cat ./tmp/vale.out | reviewdog -f=rdjsonl -name=vale -reporter=github-pr-annotations -fail-on-error=false -filter-mode=added -level=info -fail-level=warning
+        env:
+          REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
index 8ce0b6285e80..4570805dc6af 100644
--- a/.github/workflows/deploy.yml
+++ b/.github/workflows/deploy.yml
@@ -1,5 +1,5 @@
 name: deploy
-
+# Deploys the Docker Docs website when merging to the `main` branch.
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
   cancel-in-progress: true
@@ -8,9 +8,8 @@ on:
   workflow_dispatch:
   push:
     branches:
-      - lab
       - main
-      - published
+      - lab
 
 env:
   # Use edge release of buildx (latest RC, fallback to latest stable)
@@ -22,88 +21,54 @@ permissions:
   id-token: write
   contents: read
 
+# The `main` branch is deployed to the production environment.
+# The `lab` branch is deployed to a separate environment for testing purposes.
 jobs:
   publish:
     runs-on: ubuntu-24.04
     if: github.repository_owner == 'docker'
     steps:
-      -
-        name: Prepare
-        run: |
-          HUGO_ENV=development
-          DOCS_AWS_REGION=us-east-1
-          if [ "${{ github.ref }}" = "refs/heads/main" ]; then
-            HUGO_ENV=staging
-            DOCS_URL="https://docs-stage.docker.com"
-            DOCS_AWS_IAM_ROLE="arn:aws:iam::710015040892:role/stage-docs-docs.docker.com-20220818202135984800000001"
-            DOCS_S3_BUCKET="stage-docs-docs.docker.com"
-            DOCS_S3_CONFIG="s3-config.json"
-            DOCS_CLOUDFRONT_ID="E1R7CSW3F0X4H8"
-            DOCS_LAMBDA_FUNCTION_REDIRECTS="DockerDocsRedirectFunction-stage"
-            DOCS_SLACK_MSG="Successfully deployed docs-stage from main branch. $DOCS_URL"
-          elif [ "${{ github.ref }}" = "refs/heads/published" ]; then
-            HUGO_ENV=production
-            DOCS_URL="https://docs.docker.com"
-            DOCS_AWS_IAM_ROLE="arn:aws:iam::710015040892:role/prod-docs-docs.docker.com-20220818202218674300000001"
-            DOCS_S3_BUCKET="prod-docs-docs.docker.com"
-            DOCS_S3_CONFIG="s3-config.json"
-            DOCS_CLOUDFRONT_ID="E228TTN20HNU8F"
-            DOCS_LAMBDA_FUNCTION_REDIRECTS="DockerDocsRedirectFunction-prod"
-            DOCS_SLACK_MSG="Successfully deployed docs from published branch. $DOCS_URL"
-          elif [ "${{ github.ref }}" = "refs/heads/lab" ]; then
-            HUGO_ENV=lab
-            DOCS_URL="https://docs-labs.docker.com"
-            DOCS_AWS_IAM_ROLE="arn:aws:iam::710015040892:role/labs-docs-docs.docker.com-20220818202218402500000001"
-            DOCS_S3_BUCKET="labs-docs-docs.docker.com"
-            DOCS_S3_CONFIG="s3-config.json"
-            DOCS_CLOUDFRONT_ID="E1MYDYF65FW3HG"
-            DOCS_LAMBDA_FUNCTION_REDIRECTS="DockerDocsRedirectFunction-labs"
-          else
-            echo >&2 "ERROR: unknown branch ${{ github.ref }}"
-            exit 1
-          fi
-          SEND_SLACK_MSG="true"
-          if [ -z "$DOCS_AWS_IAM_ROLE" ] || [ -z "$DOCS_S3_BUCKET" ] || [ -z "$DOCS_CLOUDFRONT_ID" ] || [ -z "$DOCS_SLACK_MSG" ]; then
-            SEND_SLACK_MSG="false"
-          fi
-          echo "BRANCH_NAME=${GITHUB_REF#refs/heads/}" >> $GITHUB_ENV
-          echo "HUGO_ENV=$HUGO_ENV" >> $GITHUB_ENV
-          echo "DOCS_URL=$DOCS_URL" >> $GITHUB_ENV
-          echo "DOCS_AWS_REGION=$DOCS_AWS_REGION" >> $GITHUB_ENV
-          echo "DOCS_AWS_IAM_ROLE=$DOCS_AWS_IAM_ROLE" >> $GITHUB_ENV
-          echo "DOCS_S3_BUCKET=$DOCS_S3_BUCKET" >> $GITHUB_ENV
-          echo "DOCS_S3_CONFIG=$DOCS_S3_CONFIG" >> $GITHUB_ENV
-          echo "DOCS_CLOUDFRONT_ID=$DOCS_CLOUDFRONT_ID" >> $GITHUB_ENV
-          echo "DOCS_LAMBDA_FUNCTION_REDIRECTS=$DOCS_LAMBDA_FUNCTION_REDIRECTS" >> $GITHUB_ENV
-          echo "DOCS_SLACK_MSG=$DOCS_SLACK_MSG" >> $GITHUB_ENV
-          echo "SEND_SLACK_MSG=$SEND_SLACK_MSG" >> $GITHUB_ENV
       -
         name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5
         with:
           fetch-depth: 0
+      -
+        name: Set environment variables
+        uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
+        env:
+          INPUT_GITHUB-REF: ${{ github.ref }}
+        with:
+          script: |
+            const fs = require('fs');
+            const env = JSON.parse(fs.readFileSync('hack/releaser/env.json', 'utf8'));
+            const ref = core.getInput('github-ref');
+            if (!env.hasOwnProperty(ref)) {
+              core.setFailed(`ERROR: unknown branch ${ref}`);
+            }
+            for (const [key, value] of Object.entries(env[ref])) {
+              core.exportVariable(key, value);
+              core.info(`${key}=${value}`);
+            }
       -
         name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@4d04d5d9486b7bd6fa91e7baf45bbb4f8b9deedd # v4
         with:
           version: ${{ env.SETUP_BUILDX_VERSION }}
           driver-opts: image=${{ env.SETUP_BUILDKIT_IMAGE }}
       -
         name: Build website
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@82490499d2e5613fcead7e128237ef0b0ea210f7 # v7
         with:
           source: .
           files: |
             docker-bake.hcl
           targets: release
-          set: |
-            *.cache-from=type=gha,scope=deploy-${{ env.BRANCH_NAME }}
-            *.cache-to=type=gha,scope=deploy-${{ env.BRANCH_NAME }},mode=max
           provenance: false
       -
         name: Configure AWS Credentials
         if: ${{ env.DOCS_AWS_IAM_ROLE != '' }}
-        uses: aws-actions/configure-aws-credentials@v4
+        uses: aws-actions/configure-aws-credentials@d979d5b3a71173a29b74b5b88418bfda9437d885 # v6.1.1
         with:
           role-to-assume: ${{ env.DOCS_AWS_IAM_ROLE }}
           aws-region: ${{ env.DOCS_AWS_REGION }}
@@ -112,7 +77,6 @@ jobs:
         if: ${{ env.DOCS_S3_BUCKET != '' }}
         run: |
           aws --region ${{ env.DOCS_AWS_REGION }} s3 sync \
-            --acl public-read \
             --delete \
             --exclude "*" \
             --include "*.webp" \
@@ -121,29 +85,37 @@ jobs:
             --content-type="image/webp" \
             public s3://${{ env.DOCS_S3_BUCKET }}/
           aws --region ${{ env.DOCS_AWS_REGION }} s3 sync \
-            --acl public-read \
             --delete \
             --exclude "*.webp" \
+            --exclude "pagefind/*.pf_meta" \
+            --exclude "pagefind/fragment/*.pf_fragment" \
             public s3://${{ env.DOCS_S3_BUCKET }}/
       -
-        name: Update S3 config
-        if: ${{ env.DOCS_S3_BUCKET != '' && env.DOCS_S3_CONFIG != '' }}
-        uses: docker/bake-action@v6
-        with:
-          source: .
-          files: |
-            docker-bake.hcl
-          targets: aws-s3-update-config
-          set: |
-            *.cache-from=type=gha,scope=releaser
-        env:
-          AWS_REGION: ${{ env.DOCS_AWS_REGION }}
-          AWS_S3_BUCKET: ${{ env.DOCS_S3_BUCKET }}
-          AWS_S3_CONFIG: ${{ env.DOCS_S3_CONFIG }}
+        name: Upload pagefind files with compression headers
+        if: ${{ env.DOCS_S3_BUCKET != '' }}
+        run: |
+          aws --region ${{ env.DOCS_AWS_REGION }} s3 cp \
+            --recursive \
+            --content-encoding="gzip" \
+            --content-type="application/octet-stream" \
+            --metadata-directive="REPLACE" \
+            public/pagefind/ s3://${{ env.DOCS_S3_BUCKET }}/pagefind/ \
+            --exclude "*" \
+            --include "*.pf_meta" \
+            --include "*.pf_fragment"
+      -
+        name: Set markdown Content-Type on llms.txt
+        if: ${{ env.DOCS_S3_BUCKET != '' }}
+        run: |
+          aws --region ${{ env.DOCS_AWS_REGION }} s3 cp \
+            s3://${{ env.DOCS_S3_BUCKET }}/llms.txt \
+            s3://${{ env.DOCS_S3_BUCKET }}/llms.txt \
+            --content-type="text/markdown" \
+            --metadata-directive="REPLACE"
       -
         name: Update Cloudfront config
         if: ${{ env.DOCS_CLOUDFRONT_ID != '' }}
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@82490499d2e5613fcead7e128237ef0b0ea210f7 # v7
         with:
           source: .
           files: |
@@ -161,8 +133,3 @@ jobs:
         env:
           AWS_REGION: us-east-1 # cloudfront is only available in us-east-1 region
           AWS_MAX_ATTEMPTS: 5
-      -
-        name: Send Slack notification
-        if: ${{ env.SEND_SLACK_MSG == 'true' }}
-        run: |
-          curl -X POST -H 'Content-type: application/json' --data '{"text":"${{ env.DOCS_SLACK_MSG }}"}' ${{ secrets.SLACK_WEBHOOK }}
diff --git a/.github/workflows/labeler.yml b/.github/workflows/labeler.yml
index bdaa6a0e52b2..f04373c54158 100644
--- a/.github/workflows/labeler.yml
+++ b/.github/workflows/labeler.yml
@@ -1,11 +1,11 @@
 name: labeler
 
 concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}
+  group: ${{ github.workflow }}-${{ github.event.pull_request.number }}
   cancel-in-progress: true
 
 on:
-  pull_request_target:
+  pull_request_target: # zizmor: ignore[dangerous-triggers] safe here, this workflow only applies labels and never checks out or executes PR code
 
 jobs:
   labeler:
@@ -16,4 +16,4 @@ jobs:
     steps:
       -
         name: Run
-        uses: actions/labeler@8558fd74291d67161a8a78ce36a881fa63b766a9 # v5.0.0
+        uses: actions/labeler@f27b608878404679385c85cfa523b85ccb86e213 # v6.1.0
diff --git a/.github/workflows/merge.yml b/.github/workflows/merge.yml
deleted file mode 100644
index 7b842d08e746..000000000000
--- a/.github/workflows/merge.yml
+++ /dev/null
@@ -1,35 +0,0 @@
-name: merge
-
-concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: true
-
-# open or update publishing PR when there is a push to main
-on:
-  workflow_dispatch:
-  push:
-    branches:
-      - main
-
-jobs:
-  main-to-published:
-    runs-on: ubuntu-24.04
-    if: github.repository_owner == 'docker'
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          ref: published
-      - name: Reset published branch
-        run: |
-          git fetch origin main:main
-          git reset --hard main
-      - name: Create Pull Request
-        uses: peter-evans/create-pull-request@271a8d0340265f705b14b6d32b9829c1cb33d45e
-        with:
-          delete-branch: false
-          branch: published-update
-          commit-message: publish updates from main
-          labels: area/release
-          title: publish updates from main
-          body: |
-            Automated pull request for publishing docs updates.
diff --git a/.github/workflows/nightly-docs-scan.yml b/.github/workflows/nightly-docs-scan.yml
new file mode 100644
index 000000000000..24022dda42fe
--- /dev/null
+++ b/.github/workflows/nightly-docs-scan.yml
@@ -0,0 +1,86 @@
+name: Nightly Documentation Scan
+
+on:
+  schedule:
+    # Run every day at 3am UTC
+    - cron: "0 3 * * *"
+  workflow_dispatch:
+    inputs:
+      dry-run:
+        description: "Report issues but do not create them"
+        type: boolean
+        default: false
+
+permissions:
+  contents: read
+  issues: write
+
+concurrency:
+  group: nightly-docs-scan
+  cancel-in-progress: false
+
+jobs:
+  scan:
+    runs-on: ubuntu-latest
+    timeout-minutes: 20
+    permissions:
+      id-token: write
+      contents: read
+      issues: write
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5
+        with:
+          fetch-depth: 1
+
+      - name: Ensure cache directory exists
+        run: mkdir -p "${{ github.workspace }}/.cache"
+
+      - name: Restore scanner state
+        uses: actions/cache/restore@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
+        with:
+          path: |
+            ${{ github.workspace }}/.cache/scanner-memory.db
+            ${{ github.workspace }}/.cache/scan-history.json
+          key: docs-scanner-state-${{ github.repository }}-${{ github.run_id }}
+          restore-keys: |
+            docs-scanner-state-${{ github.repository }}-
+
+      - name: Configure AWS credentials
+        id: aws-credentials
+        continue-on-error: true
+        uses: aws-actions/configure-aws-credentials@d979d5b3a71173a29b74b5b88418bfda9437d885 # v6.1.1
+        with:
+          role-to-assume: arn:aws:iam::710015040892:role/docker-agent-action-20260409141318957000000001
+          aws-region: us-east-1
+
+      - name: Fetch bot PAT
+        if: steps.aws-credentials.outcome == 'success'
+        run: |
+          PAT=$(aws secretsmanager get-secret-value \
+            --secret-id docker-agent-action/github-app \
+            --query SecretString \
+            --output text | jq -r '.pat')
+          echo "::add-mask::$PAT"
+          echo "GITHUB_APP_TOKEN=$PAT" >> "$GITHUB_ENV"
+
+      - name: Run documentation scan
+        uses: docker/docker-agent-action@e96a4bb40cac114f64358621e1d08346c8eadc8c # v2.0.1
+        env:
+          GH_TOKEN: ${{ env.GITHUB_APP_TOKEN || github.token }}
+        with:
+          agent: ${{ github.workspace }}/.github/agents/docs-scanner.yaml
+          prompt: "${{ inputs.dry-run == true && 'DRY RUN MODE: Do not create any GitHub issues. Report what you would create but skip the gh issue create commands.' || 'Run the nightly documentation scan as described in your instructions.' }}"
+          anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
+          github-token: ${{ env.GITHUB_APP_TOKEN || github.token }}
+          timeout: 1200
+
+      - name: Save scanner state
+        uses: actions/cache/save@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
+        if: always()
+        with:
+          path: |
+            ${{ github.workspace }}/.cache/scanner-memory.db
+            ${{ github.workspace }}/.cache/scan-history.json
+          key: docs-scanner-state-${{ github.repository }}-${{ github.run_id }}
diff --git a/.github/workflows/notify-release-notes-pr.yml b/.github/workflows/notify-release-notes-pr.yml
new file mode 100644
index 000000000000..81db118a51b1
--- /dev/null
+++ b/.github/workflows/notify-release-notes-pr.yml
@@ -0,0 +1,45 @@
+name: Notify Slack on Desktop Release Notes PR
+
+on:
+  workflow_run:
+    workflows: ["Release Notes PR Trigger"]
+    types: [completed]
+
+jobs:
+  notify:
+    runs-on: ubuntu-24.04
+    if: github.repository_owner == 'docker' && github.event.workflow_run.conclusion == 'success'
+    steps:
+      - name: Download PR details
+        uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8
+        with:
+          name: pr-details
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          run-id: ${{ github.event.workflow_run.id }}
+
+      - name: Read PR details
+        id: pr
+        run: |
+          echo "url=$(jq -r .url pr-details.json)" >> "$GITHUB_OUTPUT"
+          echo "title=$(jq -r .title pr-details.json)" >> "$GITHUB_OUTPUT"
+          echo "author=$(jq -r .author pr-details.json)" >> "$GITHUB_OUTPUT"
+
+      - name: Notify Slack
+        uses: slackapi/slack-github-action@45a88b9581bfab2566dc881e2cd66d334e621e2c # v3.0.3
+        with:
+          method: chat.postMessage
+          token: ${{ secrets.SLACK_BOT_TOKEN }}
+          payload: |
+            {
+              "channel": "${{ secrets.SLACK_RELEASE_CHANNEL_ID }}",
+              "text": "Desktop release notes",
+              "blocks": [
+                {
+                  "type": "section",
+                  "text": {
+                    "type": "mrkdwn",
+                    "text": ":memo: *Desktop release notes*:\n<${{ steps.pr.outputs.url }}|${{ steps.pr.outputs.title }}> by <https://github.com/${{ steps.pr.outputs.author }}|${{ steps.pr.outputs.author }}>"
+                  }
+                }
+              ]
+            }
diff --git a/.github/workflows/pr-review-trigger.yml b/.github/workflows/pr-review-trigger.yml
new file mode 100644
index 000000000000..4606240577a2
--- /dev/null
+++ b/.github/workflows/pr-review-trigger.yml
@@ -0,0 +1,41 @@
+name: PR Review - Trigger
+on:
+  pull_request:
+    types: [opened, review_requested]
+  pull_request_review_comment:
+    types: [created]
+
+permissions: {}
+
+jobs:
+  save-context:
+    if: >
+      github.event_name != 'pull_request' ||
+      github.event.action != 'review_requested' ||
+      github.event.requested_reviewer.login == 'docker-agent'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Save event context
+        env:
+          PR_NUMBER: ${{ github.event.pull_request.number }}
+          PR_HEAD_SHA: ${{ github.event.pull_request.head.sha }}
+          REQUESTED_REVIEWER: ${{ github.event.requested_reviewer.login }}
+          COMMENT_JSON: ${{ toJSON(github.event.comment) }}
+        run: |
+          mkdir -p context
+          printf '%s' "${{ github.event_name }}" > context/event_name.txt
+          printf '%s' "$PR_NUMBER" > context/pr_number.txt
+          printf '%s' "$PR_HEAD_SHA" > context/pr_head_sha.txt
+          if [ "${{ github.event_name }}" = "pull_request" ]; then
+            printf '%s' "$REQUESTED_REVIEWER" > context/requested_reviewer.txt
+          fi
+          if [ "${{ github.event_name }}" = "pull_request_review_comment" ]; then
+            printf '%s' "$COMMENT_JSON" > context/comment.json
+          fi
+
+      - name: Upload context
+        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
+        with:
+          name: pr-review-context
+          path: context/
+          retention-days: 1
diff --git a/.github/workflows/pr-review.yml b/.github/workflows/pr-review.yml
new file mode 100644
index 000000000000..e91f1f3c99fc
--- /dev/null
+++ b/.github/workflows/pr-review.yml
@@ -0,0 +1,93 @@
+name: PR Review
+on:
+  issue_comment:
+    types: [created]
+  workflow_run:
+    workflows: ["PR Review - Trigger"]
+    types: [completed]
+
+permissions:
+  contents: read # Required at top-level to give `issue_comment` events access to the secrets below.
+
+jobs:
+  review:
+    uses: docker/docker-agent-action/.github/workflows/review-pr.yml@06e1767af06263c93d712449cbf859778d9392ee # v2.0.5
+    # Scoped to the job so other jobs in this workflow aren't over-permissioned
+    permissions:
+      contents: read # Read repository files and PR diffs
+      pull-requests: write # Post review comments
+      issues: write # Create security incident issues if secrets detected
+      checks: write # (Optional) Show review progress as a check run
+      id-token: write # Required for OIDC authentication to AWS Secrets Manager
+      actions: write # Download artifacts from trigger workflow
+    with:
+      trigger-run-id: ${{ github.event_name == 'workflow_run' && format('{0}', github.event.workflow_run.id) || '' }}
+      add-prompt-files: STYLE.md,COMPONENTS.md
+      additional-prompt: |
+        ## Documentation Review Focus
+
+        This is Docker's official documentation.
+        You are reviewing **DOCUMENTATION**, not code. Focus on documentation quality, not software bugs.
+
+        **Style guides are available via prompt files (STYLE.md, COMPONENTS.md)** - reference them when evaluating changes.
+
+        ## Priority Issues
+
+        ### 1. Vendored/Generated Content (CRITICAL - Auto-reject)
+        Check for vendored or generated files before reviewing any changed content.
+        Treat these paths as vendored/generated:
+        - Any file in `_vendor/` directory (vendored from upstream repos)
+        - Any YAML file in `data/*/*.yaml` subdirectories (CLI reference data generated from upstream)
+          - Examples: `data/engine-cli/*.yaml`, `data/buildx/*.yaml`, `data/scout-cli/*.yaml`
+          - Exception: root-level data/ files are manually maintained (allow edits)
+        - `content/reference/api/ai-governance/api.yaml` (verbatim copy of the upstream OpenAPI spec, vendored from the private docker/governor-services repo via `hack/sync-governance-api.sh`)
+
+        If all changed files are vendored/generated:
+        - Leave at most one PR-level review comment.
+        - Do not leave inline comments.
+        - Do not review style, wording, markdown, command accuracy, links, or content quality inside those files.
+        - Say only that the PR edits vendored/generated content, identify the affected path pattern, and direct the author to make the change upstream and sync it back.
+
+        If a PR changes both vendored/generated files and hand-authored files:
+        - Leave one comment for the vendored/generated file issue.
+        - Review only the hand-authored files for the remaining priority issues below.
+        - Do not leave style, wording, markdown, command accuracy, link, or content-quality comments on vendored/generated files.
+
+        ### 2. Missing Redirects When Removing/Moving Pages (HIGH)
+        When a PR removes or moves a page:
+        - Check if the PR adds an `aliases:` entry in the front matter of the target/replacement page
+        - Example: If `/old/path.md` is removed, there should be `aliases: ["/old/path/"]` in the new page
+
+        ### 3. Markdown Formatting
+        - Poor markdown syntax (unclosed code blocks, broken lists, indentation issues, etc.)
+
+        ### 4. AI-Generated Patterns (HIGH PRIORITY)
+        Flag AI-isms from STYLE.md:
+        - Hedge words: simply, just, easily, quickly, seamlessly
+        - Redundant phrases: "in order to", "allows you to"
+        - Meta-commentary: "it's worth noting that"
+        - Marketing speak: "robust", "powerful", "cutting-edge"
+        - Passive voice: "is used by" → "uses"
+
+        ### 5. Scope Preservation
+        Does the change match existing document's length and tone?
+        Check STYLE.md "Scope preservation".
+
+        ### 6. Content Accuracy
+        - Factually incorrect information (wrong commands, wrong API endpoints)
+        - Broken links or references
+        - Contradictory content
+        - Mismatched information (e.g., code example shows X but text says Y)
+        - Security issues in example code
+
+        ### 7. Front Matter & Hugo Syntax
+        - Missing required fields: `title`, `description`, `keywords`
+        - Incorrect shortcode syntax (check COMPONENTS.md)
+        - Invalid component usage
+
+        ## Severity
+        - **high**: Will mislead users or break things (incorrect commands, wrong APIs, security issues, editing vendored files, missing redirects)
+        - **medium**: Could confuse users or violates style guide (AI-isms, scope inflation, unclear instructions, markdown formatting)
+        - **low**: Minor suggestions (rarely report)
+
+        Most issues should be MEDIUM. HIGH is for critical problems only.
diff --git a/.github/workflows/release-notes-pr-trigger.yml b/.github/workflows/release-notes-pr-trigger.yml
new file mode 100644
index 000000000000..1bd3b1c13b1b
--- /dev/null
+++ b/.github/workflows/release-notes-pr-trigger.yml
@@ -0,0 +1,30 @@
+name: Release Notes PR Trigger
+
+on:
+  pull_request:
+    types: [opened]
+    paths:
+      - content/manuals/desktop/release-notes.md
+
+jobs:
+  trigger:
+    runs-on: ubuntu-24.04
+    if: github.repository_owner == 'docker'
+    steps:
+      - name: Save PR details
+        env:
+          PR_URL: ${{ github.event.pull_request.html_url }}
+          PR_TITLE: ${{ github.event.pull_request.title }}
+          PR_AUTHOR: ${{ github.event.pull_request.user.login }}
+        run: |
+          jq -n \
+            --arg url "$PR_URL" \
+            --arg title "$PR_TITLE" \
+            --arg author "$PR_AUTHOR" \
+            '{url: $url, title: $title, author: $author}' > pr-details.json
+
+      - name: Upload PR details
+        uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7
+        with:
+          name: pr-details
+          path: pr-details.json
diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
new file mode 100644
index 000000000000..1a48cc3e3532
--- /dev/null
+++ b/.github/workflows/stale.yml
@@ -0,0 +1,206 @@
+# This workflow warns and then closes issues and PRs that have had no activity for a specified amount of time.
+# It also handles lifecycle slash commands for managing stale labels.
+# For more information, see: https://github.com/actions/stale
+#
+# Security: Actions are pinned to full commit SHA to prevent supply chain attacks.
+# To update, check releases and update both the SHA and version comment.
+#
+# Debug mode:
+# - Lifecycle commands: Set DEBUG_ONLY to 'true' in the lifecycle-commands job env
+# - Stale action: Set debug-only to true in the stale job configuration
+name: Mark stale issues and pull requests
+
+on:
+  schedule:
+    - cron: '30 1 * * *'  # Daily at 1:30 AM UTC
+  issue_comment:
+    types: [created]
+
+jobs:
+  lifecycle-commands:
+    runs-on: ubuntu-latest
+    if: github.event_name == 'issue_comment'
+    permissions:
+      issues: write
+      pull-requests: write
+    
+    steps:
+      - name: Handle lifecycle commands
+        uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
+        env:
+          # Set to 'true' to test without making actual changes
+          DEBUG_ONLY: 'false'
+        with:
+          script: |
+            const comment = context.payload.comment.body.toLowerCase().trim();
+            const debugOnly = process.env.DEBUG_ONLY === 'true';
+            
+            if (debugOnly) {
+              console.log('🔍 DEBUG MODE: No changes will be made');
+            }
+            
+            // Define commands and their required permissions
+            const commands = {
+              '/lifecycle frozen': { label: 'lifecycle/frozen', requiresWrite: true },
+              '/lifecycle stale': { label: 'lifecycle/stale', requiresWrite: true },
+              '/lifecycle active': { action: 'remove-stale', requiresWrite: false },
+              '/remove-lifecycle frozen': { action: 'remove-frozen', requiresWrite: true },
+              '/remove-lifecycle stale': { action: 'remove-stale', requiresWrite: false }
+            };
+            
+            // Check if comment contains a lifecycle command
+            const commandKey = Object.keys(commands).find(cmd => 
+              comment === cmd || comment.startsWith(cmd + ' ')
+            );
+            
+            if (!commandKey) {
+              console.log('No lifecycle command found in comment');
+              return;
+            }
+            
+            const commandConfig = commands[commandKey];
+            const issue_number = context.issue.number;
+            
+            // Check user permissions for restricted commands
+            if (commandConfig.requiresWrite) {
+              if (debugOnly) {
+                console.log(`Would check permissions for user ${context.payload.comment.user.login} for ${commandKey}`);
+              } else {
+                try {
+                  const { data: userPermission } = await github.rest.repos.getCollaboratorPermissionLevel({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    username: context.payload.comment.user.login
+                  });
+                  
+                  const hasWriteAccess = ['admin', 'write', 'maintain'].includes(userPermission.permission);
+                  
+                  if (!hasWriteAccess) {
+                    console.log(`User ${context.payload.comment.user.login} does not have permission for ${commandKey}`);
+                    await github.rest.reactions.createForIssueComment({
+                      owner: context.repo.owner,
+                      repo: context.repo.repo,
+                      comment_id: context.payload.comment.id,
+                      content: '-1'
+                    });
+                    return;
+                  }
+                  console.log(`User ${context.payload.comment.user.login} has ${userPermission.permission} access`);
+                } catch (error) {
+                  console.log('Error checking permissions:', error.message);
+                  return;
+                }
+              }
+            }
+            
+            // Handle remove commands
+            if (commandConfig.action && commandConfig.action.startsWith('remove-')) {
+              const labelToRemove = commandConfig.action === 'remove-stale' ? 'lifecycle/stale' : 'lifecycle/frozen';
+              
+              if (debugOnly) {
+                console.log(`Would remove ${labelToRemove} label from issue #${issue_number}`);
+                console.log('Would react with 👍 to comment');
+              } else {
+                try {
+                  await github.rest.issues.removeLabel({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    issue_number: issue_number,
+                    name: labelToRemove
+                  });
+                  console.log(`Removed ${labelToRemove} label`);
+                  
+                  await github.rest.reactions.createForIssueComment({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    comment_id: context.payload.comment.id,
+                    content: '+1'
+                  });
+                } catch (error) {
+                  console.log(`Label ${labelToRemove} not found or already removed`);
+                }
+              }
+            }
+            // Handle add label commands
+            else if (commandConfig.label) {
+              if (debugOnly) {
+                console.log(`Would add ${commandConfig.label} label to issue #${issue_number}`);
+                console.log('Would react with 👍 to comment');
+              } else {
+                try {
+                  await github.rest.issues.addLabels({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    issue_number: issue_number,
+                    labels: [commandConfig.label]
+                  });
+                  console.log(`Added ${commandConfig.label} label`);
+                  
+                  await github.rest.reactions.createForIssueComment({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    comment_id: context.payload.comment.id,
+                    content: '+1'
+                  });
+                } catch (error) {
+                  console.log(`Error adding label: ${error.message}`);
+                }
+              }
+            }
+
+  stale:
+    runs-on: ubuntu-latest
+    if: github.event_name == 'schedule'
+    permissions:
+      issues: write
+      pull-requests: write
+      actions: write  # required for actions/stale to delete its state cache between runs
+
+    steps:
+      - uses: actions/stale@b5d41d4e1d5dceea10e7104786b73624c18a190f # v10.2.0
+        with:
+          ascending: false
+          operations-per-run: 30
+          
+          # Exempt labels - issues/PRs with these labels will never be marked stale
+          exempt-issue-labels: 'kind/help-wanted,status/need-more-info,status/needs-analysis,lifecycle/frozen'
+          exempt-pr-labels: 'kind/help-wanted,status/need-more-info,status/needs-analysis,lifecycle/frozen'
+          
+          # Use lifecycle/stale label to match existing convention
+          stale-issue-label: 'lifecycle/stale'
+          stale-pr-label: 'lifecycle/stale'
+          
+          # Stale messages
+          stale-issue-message: |
+            There hasn't been any activity on this issue for a long time. If the problem is still relevant, **add a comment** to keep it open. Otherwise, this issue will be automatically closed in 14 days.
+            
+            **To remove the stale label:** Comment `/lifecycle active`
+            **To freeze (requires write access):** Comment `/lifecycle frozen`
+          stale-pr-message: |
+            Thanks for the PR. We'd like to make our product docs better, but haven't been able to review all the suggestions. As our docs change often and quickly diverge, we do not have the bandwidth to review and rebase old PRs.
+            
+            If the updates are still relevant, please rebase your PR against the latest version of the docs and **add a comment** when it's ready. This helps our maintainers focus on active contributions. If there's no activity, this PR will be closed in 30 days.
+            
+            **To remove the stale label:** Comment `/lifecycle active`
+            **To freeze (requires write access):** Comment `/lifecycle frozen`
+          
+          # Close messages
+          close-issue-message: |
+            Closing this issue as there hasn't been any activity for a long time. 
+            
+            If the problem is still relevant, please **open a new issue** and complete the issue template so we can capture the details required to investigate further. This helps our maintainers focus on active issues.
+          close-pr-message: |
+            Closing this PR as there hasn't been any activity for a long time. 
+            
+            If the updates are still relevant, please review our [contribution guidelines](https://github.com/docker/docs/blob/main/CONTRIBUTING.md) and **create a new PR** against the latest version of our docs.
+          
+          # Timing configuration NOTE: If you change days-before-issue-close or
+          # days-before-pr-close, also update the hardcoded values in the
+          # stale-issue-message and stale-pr-message above to match.
+          days-before-issue-stale: 180  # 6 months
+          days-before-pr-stale: 180     # 6 months
+          days-before-issue-close: 14   # 2 weeks after stale
+          days-before-pr-close: 30      # 1 month after stale
+          
+          # Debug mode - set to true for dry-run testing (no actual changes)
+          debug-only: false
diff --git a/.github/workflows/sync-cli-docs.yml b/.github/workflows/sync-cli-docs.yml
new file mode 100644
index 000000000000..382a0f86fad5
--- /dev/null
+++ b/.github/workflows/sync-cli-docs.yml
@@ -0,0 +1,131 @@
+name: sync-cli-docs
+
+on:
+  schedule:
+    # Run daily at 02:00 UTC
+    - cron: '0 2 * * *'
+  workflow_dispatch:
+    inputs:
+      version:
+        description: "(optional) Docker CLI version - defaults to docker_ce_version in hugo.yaml"
+        required: false
+        default: ""
+  pull_request:
+    paths:
+      - '.github/workflows/sync-cli-docs.yml'
+      - 'hack/sync-cli-docs.sh'
+
+permissions:
+  contents: write
+  pull-requests: write
+
+env:
+  BRANCH_NAME: "bot/sync-cli-docs"
+
+jobs:
+  sync-cli-docs:
+    runs-on: ubuntu-24.04
+    steps:
+      -
+        name: Checkout docs repo
+        uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5
+        with:
+          fetch-depth: 0
+      -
+        name: Get version from hugo.yaml
+        id: get-version
+        run: |
+          if [ -n "${{ inputs.version }}" ]; then
+            VERSION="${{ inputs.version }}"
+          else
+            VERSION=v$(grep "docker_ce_version:" hugo.yaml | awk '{print $2}' | tr -d '"')
+          fi
+
+          echo "version=$VERSION" >> "$GITHUB_OUTPUT"
+          echo "Docker CLI version: **$VERSION**" | tee -a "$GITHUB_STEP_SUMMARY"
+      -
+        name: Checkout docker/cli repo
+        uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5
+        with:
+          repository: docker/cli
+          path: cli-source
+          ref: ${{ steps.get-version.outputs.version }}
+          fetch-depth: 0
+      -
+        name: Create update branch
+        id: create-branch
+        env:
+          BRANCH_NAME: ${{ env.BRANCH_NAME }}
+        run: |
+          git checkout -b "$BRANCH_NAME"
+          git config user.name "github-actions[bot]"
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+      -
+        name: Run sync script
+        id: sync
+        run: |
+          set +e
+          ./hack/sync-cli-docs.sh HEAD cli-source
+          EXIT_CODE=$?
+          set -e
+
+          if [ $EXIT_CODE -eq 0 ]; then
+            echo "changes=true" >> "$GITHUB_OUTPUT"
+            echo "Changes detected - syncing CLI docs" >> "$GITHUB_STEP_SUMMARY"
+          elif [ $EXIT_CODE -eq 100 ]; then
+            echo "changes=false" >> "$GITHUB_OUTPUT"
+            echo "No changes to sync - CLI docs are up to date" >> "$GITHUB_STEP_SUMMARY"
+          else
+            echo "::error::Script failed with exit code $EXIT_CODE"
+            exit $EXIT_CODE
+          fi
+
+      -
+        name: Show PR
+        if: steps.sync.outputs.changes == 'true'
+        run: |
+          git show "${{ env.BRANCH_NAME }}"
+      -
+        name: Create or update Pull Request
+        if: steps.sync.outputs.changes == 'true' && github.event_name != 'pull_request'
+        env:
+          GH_TOKEN: ${{ github.token }}
+          BRANCH_NAME: ${{ env.BRANCH_NAME }}
+          PR_TITLE: "cli: sync docs with cli ${{ steps.get-version.outputs.version }}"
+          PR_BODY: |
+            ## Summary
+
+            Automated sync of CLI documentation from docker/cli repository.
+
+            **CLI Version:** ${{ steps.get-version.outputs.version }}
+
+            ---
+
+            > [!IMPORTANT]
+            > **Reviewer:** Please close and reopen this PR to trigger CI checks.
+            > See: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow#triggering-a-workflow-from-a-workflow
+        run: |
+          # Check for existing open PR from this branch
+          EXISTING_PR=$(gh pr list --state open --head "$BRANCH_NAME" --json url --jq ".[0].url // empty")
+
+          if [ -n "$EXISTING_PR" ]; then
+            echo "Updating existing PR: $EXISTING_PR" >> "$GITHUB_STEP_SUMMARY"
+            git push -u origin "$BRANCH_NAME" --force
+            gh pr edit "$EXISTING_PR" --title "$PR_TITLE" --body "$PR_BODY"
+          else
+            # Check if a closed PR with the same title already exists
+            CLOSED_PR=$(gh pr list --state closed --search "$PR_TITLE in:title" --json url --jq ".[0].url // empty")
+            if [ -n "$CLOSED_PR" ]; then
+              echo "A closed PR already exists for this version: $CLOSED_PR" >> "$GITHUB_STEP_SUMMARY"
+              echo "Skipping PR creation."
+              exit 0
+            fi
+
+            echo "Creating new PR" >> "$GITHUB_STEP_SUMMARY"
+            git push -u origin "$BRANCH_NAME"
+            gh pr create \
+              --title "$PR_TITLE" \
+              --body "$PR_BODY" \
+              --base main \
+              --head "$BRANCH_NAME"
+          fi
diff --git a/.github/workflows/sync-docker-agent-docs.yml b/.github/workflows/sync-docker-agent-docs.yml
new file mode 100644
index 000000000000..3f24f332ca56
--- /dev/null
+++ b/.github/workflows/sync-docker-agent-docs.yml
@@ -0,0 +1,130 @@
+name: sync-docker-agent-docs
+
+on:
+  schedule:
+    # Run daily at 02:30 UTC, offset from sync-cli-docs
+    - cron: '30 2 * * *'
+  workflow_dispatch:
+    inputs:
+      version:
+        description: "(optional) docker-agent version - defaults to the latest release tag"
+        required: false
+        default: ""
+  pull_request:
+    paths:
+      - '.github/workflows/sync-docker-agent-docs.yml'
+
+permissions:
+  contents: write
+  pull-requests: write
+
+env:
+  BRANCH_NAME: "bot/sync-docker-agent-docs"
+  MODULE_NAME: "github.com/docker/docker-agent"
+
+jobs:
+  sync-docker-agent-docs:
+    runs-on: ubuntu-24.04
+    steps:
+      -
+        name: Checkout docs repo
+        uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5
+        with:
+          fetch-depth: 0
+      -
+        name: Get target version
+        id: get-version
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          if [ -n "${{ inputs.version }}" ]; then
+            VERSION="${{ inputs.version }}"
+          else
+            VERSION=$(gh release view --repo docker/docker-agent --json tagName --jq .tagName)
+          fi
+          CURRENT=$(go list -m -f '{{ .Version }}' "$MODULE_NAME" || true)
+
+          echo "version=$VERSION" >> "$GITHUB_OUTPUT"
+          echo "current=$CURRENT" >> "$GITHUB_OUTPUT"
+          echo "docker-agent version: **$VERSION** (currently pinned: **$CURRENT**)" | tee -a "$GITHUB_STEP_SUMMARY"
+      -
+        name: Set up Docker Buildx
+        if: steps.get-version.outputs.version != steps.get-version.outputs.current
+        uses: docker/setup-buildx-action@4d04d5d9486b7bd6fa91e7baf45bbb4f8b9deedd # v4
+      -
+        # go mod edit sets the version before plain make vendor: passing
+        # VENDOR_MODULE would run hugo mod get, which records docker-agent's
+        # full transitive graph as indirect requires in go.mod.
+        name: Update vendor
+        if: steps.get-version.outputs.version != steps.get-version.outputs.current
+        run: |
+          go mod edit -require "${MODULE_NAME}@${{ steps.get-version.outputs.version }}"
+          make vendor
+      -
+        name: Detect changes
+        id: changes
+        if: steps.get-version.outputs.version != steps.get-version.outputs.current
+        run: |
+          if [ -n "$(git status --porcelain)" ]; then
+            echo "changes=true" >> "$GITHUB_OUTPUT"
+            echo "Changes detected - syncing Docker Agent docs" >> "$GITHUB_STEP_SUMMARY"
+          else
+            echo "changes=false" >> "$GITHUB_OUTPUT"
+            echo "No changes to sync - Docker Agent docs are up to date" >> "$GITHUB_STEP_SUMMARY"
+          fi
+      -
+        name: Commit changes
+        if: steps.changes.outputs.changes == 'true'
+        env:
+          BRANCH_NAME: ${{ env.BRANCH_NAME }}
+          VERSION: ${{ steps.get-version.outputs.version }}
+        run: |
+          git checkout -b "$BRANCH_NAME"
+          git config user.name "github-actions[bot]"
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+          git add -A
+          git commit -m "docker-agent: sync docs with docker-agent $VERSION"
+      -
+        name: Create or update Pull Request
+        if: steps.changes.outputs.changes == 'true' && github.event_name != 'pull_request'
+        env:
+          GH_TOKEN: ${{ github.token }}
+          BRANCH_NAME: ${{ env.BRANCH_NAME }}
+          PR_TITLE: "docker-agent: sync docs with docker-agent ${{ steps.get-version.outputs.version }}"
+          PR_BODY: |
+            ## Summary
+
+            Automated sync of Docker Agent documentation from the docker/docker-agent repository.
+
+            **docker-agent version:** ${{ steps.get-version.outputs.version }}
+
+            ---
+
+            > [!IMPORTANT]
+            > **Reviewer:** Please close and reopen this PR to trigger CI checks.
+            > See: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow#triggering-a-workflow-from-a-workflow
+        run: |
+          # Check for existing open PR from this branch
+          EXISTING_PR=$(gh pr list --state open --head "$BRANCH_NAME" --json url --jq ".[0].url // empty")
+
+          if [ -n "$EXISTING_PR" ]; then
+            echo "Updating existing PR: $EXISTING_PR" >> "$GITHUB_STEP_SUMMARY"
+            git push -u origin "$BRANCH_NAME" --force
+            gh pr edit "$EXISTING_PR" --title "$PR_TITLE" --body "$PR_BODY"
+          else
+            # Check if a closed PR with the same title already exists
+            CLOSED_PR=$(gh pr list --state closed --search "$PR_TITLE in:title" --json url --jq ".[0].url // empty")
+            if [ -n "$CLOSED_PR" ]; then
+              echo "A closed PR already exists for this version: $CLOSED_PR" >> "$GITHUB_STEP_SUMMARY"
+              echo "Skipping PR creation."
+              exit 0
+            fi
+
+            echo "Creating new PR" >> "$GITHUB_STEP_SUMMARY"
+            git push -u origin "$BRANCH_NAME"
+            gh pr create \
+              --title "$PR_TITLE" \
+              --body "$PR_BODY" \
+              --base main \
+              --head "$BRANCH_NAME"
+          fi
diff --git a/.github/workflows/validate-upstream.yml b/.github/workflows/validate-upstream.yml
index 0ac2645c76ad..727b552ea437 100644
--- a/.github/workflows/validate-upstream.yml
+++ b/.github/workflows/validate-upstream.yml
@@ -34,12 +34,12 @@ jobs:
     steps:
       -
         name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5
         with:
           repository: docker/docs
       -
         name: Download data files
-        uses: actions/download-artifact@v4
+        uses: actions/download-artifact@634f93cb2916e3fdff6788551b99b062d0335ce0 # v5
         if: ${{ inputs.data-files-id != '' && inputs.data-files-folder != '' }}
         with:
           name: ${{ inputs.data-files-id }}
@@ -51,7 +51,7 @@ jobs:
         # that folder. If not, create a placeholder stub file for the data file.
         name: Copy data files
         if: ${{ inputs.data-files-id != '' && inputs.data-files-folder != '' }}
-        uses: actions/github-script@v7
+        uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8
         with:
           script: |
             const fs = require('fs');
@@ -61,7 +61,7 @@ jobs:
               const yamlSrcFilename = path.basename(yamlSrcPath);
               const yamlSrcNoExt = yamlSrcPath.replace(".yaml", "");
               const hasSubCommands = (await (await glob.create(yamlSrcNoExt)).glob()).length > 1;
-              const yamlDestPath = path.join('data', `${{ inputs.data-files-folder }}`, yamlSrcFilename);
+              const yamlDestPath = path.join('data', 'cli', `${{ inputs.data-files-folder }}`, yamlSrcFilename);
               let placeholderPath = path.join("content/reference/cli", yamlSrcFilename.replace('_', '/').replace(/\.yaml$/, '.md'));
               if (hasSubCommands) {
                 placeholderPath = placeholderPath.replace('.md', '/_index.md');
@@ -84,22 +84,19 @@ jobs:
             }
       -
         name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@4d04d5d9486b7bd6fa91e7baf45bbb4f8b9deedd # v4
         with:
           version: ${{ env.SETUP_BUILDX_VERSION }}
           driver-opts: image=${{ env.SETUP_BUILDKIT_IMAGE }}
       -
         name: Validate
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@82490499d2e5613fcead7e128237ef0b0ea210f7 # v7
         with:
           source: .
           files: |
             docker-bake.hcl
           targets: validate-upstream
           provenance: false
-          set: |
-            *.cache-from=type=gha,scope=docs-upstream
-            *.cache-to=type=gha,scope=docs-upstream
         env:
           UPSTREAM_MODULE_NAME: ${{ inputs.module-name }}
           UPSTREAM_REPO: ${{ github.repository }}
diff --git a/.gitignore b/.gitignore
index 72f90137613a..7c450914435b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,10 +1,19 @@
+.hugo_build.lock
+hugo_stats.json
+.idea/
+.vscode/mcp.json
+.vscode/settings.json
+.vscode/tasks.json
 **/.DS_Store
 **/desktop.ini
-.vscode
 node_modules
-.hugo_build.lock
-resources
 public
-tmp
+resources
 static/pagefind
-.idea/
+tmp
+# Binary installed by cagent-action in CI
+cagent
+# cagent tmp files
+.cagent
+.pr-body.md
+.validation.log
diff --git a/.htmltest.yml b/.htmltest.yml
index e7cb321e1bec..ea2330397f44 100644
--- a/.htmltest.yml
+++ b/.htmltest.yml
@@ -9,6 +9,8 @@ IgnoreDirectoryMissingTrailingSlash: true
 IgnoreURLs:
 - "^/reference/api/hub/.*$"
 - "^/reference/api/engine/v.+/#.*$"
+- "^/reference/api/registry/.*$"
+- "^/pagefind/.*$"
 IgnoreDirs:
 - "registry/configuration"
 - "compose/compose-file" # temporarily ignore until upstream is fixed
diff --git a/.markdownlint.json b/.markdownlint.json
deleted file mode 100644
index 58ab5995dd85..000000000000
--- a/.markdownlint.json
+++ /dev/null
@@ -1,24 +0,0 @@
-{
-  "default": false,
-  "blanks-around-headings": true,
-  "hr-style": true,
-  "heading-start-left": true,
-  "single-h1": true,
-  "no-trailing-punctuation": true,
-  "no-missing-space-atx": true,
-  "no-multiple-space-atx": true,
-  "no-missing-space-closed-atx": true,
-  "no-multiple-space-closed-atx": true,
-  "no-space-in-emphasis": true,
-  "no-space-in-code": true,
-  "no-space-in-links": true,
-  "no-empty-links": true,
-  "ol-prefix": {"style": "ordered"},
-  "no-reversed-links": true,
-  "reference-links-images": {
-    "shortcut_syntax": false
-  },
-  "fenced-code-language": true,
-  "table-pipe-style": true,
-  "table-column-count": true
-}
diff --git a/.npmrc b/.npmrc
new file mode 100644
index 000000000000..97b895e2f968
--- /dev/null
+++ b/.npmrc
@@ -0,0 +1 @@
+ignore-scripts=true
diff --git a/.prettierignore b/.prettierignore
new file mode 100644
index 000000000000..de056073aff3
--- /dev/null
+++ b/.prettierignore
@@ -0,0 +1 @@
+**/*.md
diff --git a/.rumdl.toml b/.rumdl.toml
new file mode 100644
index 000000000000..9ad17f216170
--- /dev/null
+++ b/.rumdl.toml
@@ -0,0 +1,44 @@
+[global]
+flavor = "hugo"
+enable = [
+  "MD011",
+  "MD018",
+  "MD019",
+  "MD020",
+  "MD021",
+  "MD022",
+  "MD023",
+  "MD025",
+  "MD026",
+  "MD029",
+  "MD035",
+  "MD037",
+  "MD038",
+  "MD039",
+  "MD040",
+  "MD042",
+  "MD052",
+  "MD055",
+  "MD056",
+  "MD059",
+]
+exclude = [
+  "content/manuals/desktop/previous-versions/*.md",
+  "content/manuals/engine/release-notes/*.md",
+]
+
+[MD029]
+style = "one_or_ordered"
+
+[MD052]
+shortcut-syntax = false
+
+[MD059]
+prohibited-texts = [
+  "click here",
+  "here",
+  "link",
+  "more",
+  "learn more",
+  "find out more",
+]
diff --git a/.sbx/kits/hugo/spec.yaml b/.sbx/kits/hugo/spec.yaml
new file mode 100644
index 000000000000..815ddac9f7d3
--- /dev/null
+++ b/.sbx/kits/hugo/spec.yaml
@@ -0,0 +1,52 @@
+schemaVersion: "2"
+kind: mixin
+name: hugo
+displayName: Hugo
+description: Installs the Hugo Extended static site generator from a pinned GitHub release.
+
+permissions:
+  network:
+    allow:
+      # Release tarball download (install time, one-shot).
+      # github.com 302-redirects to release-assets.githubusercontent.com for binary downloads.
+      - github.com
+      - release-assets.githubusercontent.com
+
+setup:
+  install:
+    - command: |
+        set -euo pipefail
+        # Keep in sync with ARG HUGO_VERSION in this repo's Dockerfile.
+        HUGO_VERSION=0.163.0
+        ARCH=$(dpkg --print-architecture)
+        case "$ARCH" in
+          amd64)
+            TARBALL="hugo_extended_${HUGO_VERSION}_Linux-64bit.tar.gz"
+            SHA256="6291775b7d012f9b10fb377ba914e5b1589c0b0d2531b695fa9029be14750111"
+            ;;
+          arm64)
+            TARBALL="hugo_extended_${HUGO_VERSION}_linux-arm64.tar.gz"
+            SHA256="ed50d3ec8c5b427013137e38718a5d398a90956ce9e3a8a3cb7ebf3fdd01072b"
+            ;;
+          *)
+            echo "unsupported arch: $ARCH" >&2
+            exit 1
+            ;;
+        esac
+        curl --proto '=https' --tlsv1.2 -fsSL \
+          -o /tmp/hugo.tgz \
+          "https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/${TARBALL}"
+        echo "${SHA256}  /tmp/hugo.tgz" | sha256sum -c -
+        tar -C /usr/local/bin -xzf /tmp/hugo.tgz hugo
+        rm /tmp/hugo.tgz
+        hugo version
+      user: "0"
+      description: "Install pinned Hugo Extended CLI"
+
+agentInstructions:
+  content: |
+    ## Hugo static site generator
+
+    The `hugo` CLI (extended edition, v0.163.0) is installed and available on
+    `PATH`. This repository builds https://docs.docker.com/ with Hugo. Run
+    `hugo version` to confirm, and `hugo server` to preview the site locally.
diff --git a/.sbx/kits/rumdl/spec.yaml b/.sbx/kits/rumdl/spec.yaml
new file mode 100644
index 000000000000..dfda7f855b88
--- /dev/null
+++ b/.sbx/kits/rumdl/spec.yaml
@@ -0,0 +1,52 @@
+schemaVersion: "2"
+kind: mixin
+name: rumdl
+displayName: rumdl
+description: Installs the rumdl Markdown linter/formatter from a pinned GitHub release, matching the version this repository uses.
+
+permissions:
+  network:
+    allow:
+      # Release tarball download (install time, one-shot).
+      # github.com 302-redirects to release-assets.githubusercontent.com for binary downloads.
+      - github.com
+      - release-assets.githubusercontent.com
+
+setup:
+  install:
+    - command: |
+        set -euo pipefail
+        # Keep in sync with the "rumdl" devDependency version in this repo's package.json.
+        RUMDL_VERSION=0.2.49
+        ARCH=$(dpkg --print-architecture)
+        case "$ARCH" in
+          amd64)
+            TARBALL="rumdl-v${RUMDL_VERSION}-x86_64-unknown-linux-gnu.tar.gz"
+            SHA256="e208db27143592a18b26d9d42e6e76133a2dcdb8738d2ed0f8d3b44027b2d8d6"
+            ;;
+          arm64)
+            TARBALL="rumdl-v${RUMDL_VERSION}-aarch64-unknown-linux-gnu.tar.gz"
+            SHA256="b57cfdc83f4bbe0714c4a7642464107a5c64f258d5925d67bc9b3816dbe0701a"
+            ;;
+          *)
+            echo "unsupported arch: $ARCH" >&2
+            exit 1
+            ;;
+        esac
+        curl --proto '=https' --tlsv1.2 -fsSL \
+          -o /tmp/rumdl.tgz \
+          "https://github.com/rvben/rumdl/releases/download/v${RUMDL_VERSION}/${TARBALL}"
+        echo "${SHA256}  /tmp/rumdl.tgz" | sha256sum -c -
+        tar -C /usr/local/bin -xzf /tmp/rumdl.tgz rumdl
+        rm /tmp/rumdl.tgz
+        rumdl --version
+      user: "0"
+      description: "Install pinned rumdl CLI"
+
+agentInstructions:
+  content: |
+    ## rumdl Markdown linter
+
+    The `rumdl` CLI is installed and available on `PATH`. Format a Markdown
+    file with `rumdl fmt <file>` and lint it with `rumdl check <file>` (or
+    the project's `scripts/lint.sh <file>...`, which also runs Vale).
diff --git a/.vale-rdjsonl.tmpl b/.vale-rdjsonl.tmpl
new file mode 100644
index 000000000000..662f973385c2
--- /dev/null
+++ b/.vale-rdjsonl.tmpl
@@ -0,0 +1,31 @@
+{{- /* Range over the linted files */ -}}
+
+{{- range .Files}}
+
+{{- $path := .Path -}}
+
+{{- /* Range over the file's alerts */ -}}
+
+{{- range .Alerts -}}
+
+{{- $error := "" -}}
+{{- if eq .Severity "error" -}}
+    {{- $error = "ERROR" -}}
+{{- else if eq .Severity "warning" -}}
+    {{- $error = "WARNING" -}}
+{{- else -}}
+    {{- $error = "INFO" -}}
+{{- end}}
+
+{{- /* Variables setup */ -}}
+
+{{- $line := printf "%d" .Line -}}
+{{- $col := printf "%d" (index .Span 0) -}}
+{{- $check := printf "%s" .Check -}}
+{{- $message := printf "%s" .Message -}}
+
+{{- /* Output */ -}}
+
+{"message": "[{{ $check }}] {{ $message | jsonEscape }}", "location": {"path": "{{ $path }}", "range": {"start": {"line": {{ $line }}, "column": {{ $col }}}}}, "severity": "{{ $error }}"}
+{{end -}}
+{{end -}}
diff --git a/.vale.ini b/.vale.ini
index 710e13b2ff2f..398c9a2fd843 100644
--- a/.vale.ini
+++ b/.vale.ini
@@ -1,17 +1,36 @@
 StylesPath = _vale
 MinAlertLevel = suggestion
-
+IgnoredScopes = text.frontmatter, code, tt, b, strong, i, a
 Vocab = Docker
 
-[*.md]
-BasedOnStyles = Vale, Docker
-# Exclude `{{< ... >}}`, `{{% ... %}}`, [Who]({{< ... >}})
-TokenIgnores = ({{[%<] .* [%>]}}.*?{{[%<] ?/.* [%>]}}), \
-(\[.+\]\({{< .+ >}}\)), \
-[^\S\r\n]({{[%<] \w+ .+ [%>]}})\s, \
-[^\S\r\n]({{[%<](?:/\*) .* (?:\*/)[%>]}})\s, \
-(?sm)({{[%<] .*?\s[%>]}})
+# Generated reference content — disable rules that don't apply
+[content/reference/**]
+Docker.Capitalization = NO
+Vale.Spelling = NO
+Vale.Terms = NO
 
-# Exclude `{{< myshortcode `This is some <b>HTML</b>, ... >}}`
-BlockIgnores = (?sm)^({{[%<] \w+ [^{]*?\s[%>]}})\n$, \
-(?s) *({{< highlight [^>]* ?>}}.*?{{< ?/ ?highlight >}})
+# Skip release notes and old desktop changelog content entirely
+[{content/manuals/*/release-notes.md,content/manuals/*/release-notes/**,content/manuals/**/release-notes.md,content/manuals/desktop/previous-versions/**}]
+Docker.Avoid = NO
+Docker.Capitalization = NO
+Docker.Exclamation = NO
+Docker.Forbidden = NO
+Docker.GenericCTA = NO
+Docker.HeadingPunctuation = NO
+Docker.ListComma = NO
+Docker.OxfordComma = NO
+Docker.RecommendedWords = NO
+Docker.Spacing = NO
+Docker.Terms = NO
+Docker.URLFormat = NO
+Docker.Units = NO
+Docker.VersionText = NO
+Docker.We = NO
+Vale.Spelling = NO
+Vale.Repetition = NO
+Vale.Terms = NO
+
+[*.md]
+BasedOnStyles = Docker, Vale
+TokenIgnores = ({{[^}]+}}\S*)
+BlockIgnores = (?m)^[ \t]*({{[^}]+}})[ \t]*$, (\[[^\]]*{{[^}]+}}[^\]]*\]\([^)]*\)), ({{<\s*file\s[^>]*>}}[\s\S]*?{{<\s*/\s*file\s*>}})
diff --git a/.vscode/docker.code-snippets b/.vscode/docker.code-snippets
new file mode 100644
index 000000000000..1c2817d4183a
--- /dev/null
+++ b/.vscode/docker.code-snippets
@@ -0,0 +1,67 @@
+{
+  "Insert Hugo Note Admonition": {
+    "prefix": ["admonition", "note"],
+    "body": ["> [!NOTE]", "> $1"],
+    "description": "Insert a Hugo note admonition",
+  },
+  "Insert Hugo Important Admonition": {
+    "prefix": ["admonition", "important"],
+    "body": ["> [!IMPORTANT]", "> $1"],
+    "description": "Insert a Hugo important admonition",
+  },
+  "Insert Hugo Warning Admonition": {
+    "prefix": ["admonition", "warning"],
+    "body": ["> [!WARNING]", "> $1"],
+    "description": "Insert a Hugo warning admonition",
+  },
+  "Insert Hugo Tip Admonition": {
+    "prefix": ["admonition", "tip"],
+    "body": ["> [!TIP]", "> $1"],
+    "description": "Insert a Hugo tip admonition",
+  },
+  "Insert Hugo Tabs": {
+    "prefix": ["admonition", "tabs"],
+    "body": [
+      "",
+      "{{< tabs group=\"$1\" >}}",
+      "{{< tab name=\"$2\">}}",
+      "",
+      "$3",
+      "",
+      "{{< /tab >}}",
+      "{{< tab name=\"$4\">}}",
+      "",
+      "$5",
+      "",
+      "{{< /tab >}}",
+      "{{</tabs >}}",
+      "",
+    ],
+    "description": "Insert a Hugo tabs block with two tabs and snippet stops for names and content",
+  },
+  "Insert Hugo code block (no title)": {
+    "prefix": ["codeblock", "block"],
+    "body": ["```${1:json}", "$2", "```", ""],
+    "description": "Insert a Hugo code block with an optional title",
+  },
+  "Insert Hugo code block (with title)": {
+    "prefix": ["codeblock", "codettl", "block"],
+    "body": ["```${1:json} {title=\"$2\"}", "$3", "```", ""],
+    "description": "Insert a Hugo code block with an optional title",
+  },
+  "Insert a Button": {
+    "prefix": ["button"],
+    "body": ["{{< button url=\"$1\" text=\"$2\" >}}"],
+    "description": "Insert a Hugo button",
+  },
+  "Insert Visual Studio Code": {
+    "prefix": ["vscode", "vs"],
+    "body": ["Visual Studio Code"],
+    "description": "Insert 'Visual Studio Code'",
+  },
+  "Insert reusable snippet": {
+    "prefix": ["include","reuse"],
+    "body": ["{{% include \"$1\" %}}"],
+    "description": "Insert a reusable snippet stored in the `includes` folder",
+  }
+}
\ No newline at end of file
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 000000000000..d335fddbe7ed
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,310 @@
+# AGENTS.md
+
+Instructions for AI agents working on Docker documentation.
+This site builds https://docs.docker.com/ using Hugo.
+
+## Project structure
+
+```text
+content/          # Documentation source (Markdown + Hugo front matter)
+├── manuals/      # Product docs (Engine, Desktop, Hub, etc.)
+├── guides/       # Task-oriented guides
+├── reference/    # API and CLI reference
+└── includes/     # Reusable snippets
+layouts/          # Hugo templates and shortcodes
+data/             # YAML data files (CLI reference, etc.)
+assets/           # CSS (Tailwind v4) and JS (Alpine.js)
+static/           # Images, fonts
+_vendor/          # Vendored Hugo modules (read-only)
+```
+
+## URL prefix stripping
+
+The `/manuals` prefix is stripped from published URLs:
+`content/manuals/desktop/install.md` becomes `/desktop/install/` on the live
+site.
+
+When writing internal cross-references in source files, keep the `/manuals/`
+prefix in the path — Hugo requires the full source path. The stripping only
+affects the published URL, not the internal link target. Anchor links must
+exactly match the generated heading ID (Hugo lowercases and slugifies
+headings).
+
+## Vendored content (do not edit)
+
+Content in `_vendor/` and CLI reference data in `data/cli/` are vendored
+from upstream repos. Content pages under `content/reference/cli/` are
+generated from `data/cli/` YAML. Do not edit any of these files — changes
+must go to the source repository:
+
+| Content | Source repo |
+|---------|-------------|
+| CLI reference (`docker`, `docker build`, etc.) | docker/cli |
+| Buildx reference | docker/buildx |
+| Compose reference | docker/compose |
+| Model Runner reference | docker/model-runner |
+| Dockerfile reference | moby/buildkit |
+| Engine API reference | moby/moby |
+| AI Governance API (`content/reference/api/ai-governance/api.yaml`) | docker/governor-services (private) |
+
+If a validation failure or broken link traces back to vendored content, note
+the upstream repo that needs fixing. Do not attempt to fix it locally.
+
+`content/reference/api/ai-governance/api.yaml` is a verbatim copy of the
+upstream `openapi.yaml` — do not edit it by hand. Re-vendor it with
+`hack/sync-governance-api.sh`, which fetches the latest spec from the private
+`docker/governor-services` repo (using your own `gh` auth).
+
+## Writing guidelines
+
+Read and follow [STYLE.md](STYLE.md) and [COMPONENTS.md](COMPONENTS.md).
+These contain all style rules, shortcode syntax, and front matter requirements.
+
+### Style violations to avoid
+
+Every piece of writing must avoid these words and patterns (enforced by Vale):
+
+- Hedge words: "simply", "easily", "just", "seamlessly"
+- Meta-commentary: "it's worth noting", "it's important to understand"
+- "allows you to" or "enables you to" — use "lets you" or rephrase
+- "we" — use "you" or "Docker"
+- "click" — use "select"
+- Bold for emphasis or product names — only bold UI elements
+- Time-relative language: "currently", "new", "recently", "now"
+
+### Version-introduction notes
+
+Explicit version anchors ("Starting with Docker Desktop version X...") are
+different from time-relative language — they mark when a feature was
+introduced, which is permanently true.
+
+- Recent releases (~6 months): leave version callouts in place
+- Old releases: consider removing if the callout adds little value
+- When in doubt, keep the callout and flag for maintainer review
+
+### Vale gotchas
+
+- Use lowercase "config" in prose — `vale.Terms` flags a capital-C "Config"
+
+### Updating the vocabulary
+
+If Vale flags a legitimate tech term, product name, or compound identifier
+as a misspelling, add it to `_vale/config/vocabularies/Docker/accept.txt`.
+This is optional — only update when a real new term is missing, not to
+silence individual violations.
+
+- Use the canonical form for case-sensitive product names (`PyTorch`,
+  `GitHub`, `Kubernetes`, `BuildKit`). `Vale.Terms` enforces that exact
+  case across the docs.
+- Use `[Aa]bcd` character-class regex for words that legitimately appear
+  in multiple cases (e.g., sentence-starting capitalization, or a name
+  that's also a generic noun). This covers spelling without enforcing
+  a single canonical form.
+- Avoid broad regex patterns — entries that match many words at once
+  (especially with `(?i)`) suppress other rule checks on every match.
+- Don't add a wrong-cased entry to silence one false positive — it
+  cascades into `Vale.Terms` violations on every correct usage.
+
+## Alpine.js patterns
+
+Do not combine Alpine's `x-show` with the HTML `hidden` attribute on the
+same element. `x-show` toggles inline `display` styles, but `hidden` applies
+`display: none` via the user-agent stylesheet — the element stays hidden
+regardless of `x-show` state. Use `x-cloak` for pre-Alpine hiding instead.
+The site defines `[x-cloak=""] { display: none !important }` in `global.css`.
+
+## Front matter requirements
+
+Every content page under `content/` requires:
+
+- `title:` — page title
+- `description:` — short description for SEO/previews
+- `keywords:` — list of search keywords
+
+Additional common fields:
+
+- `linkTitle:` — sidebar label (keep under 30 chars)
+- `weight:` — ordering within a section
+
+## Sidebar navigation
+
+The section sidebar is rendered by
+`layouts/_partials/sidebar/sections.html`. It starts at `.FirstSection` and
+recursively walks each section's `.Pages`. Page weight controls the default
+order. Section front matter can group entries with `sidebar.groups`, reverse
+their order with `sidebar.reverse`, override a link with `sidebar.goto`, and
+add a badge with `sidebar.badge`.
+
+The sidebar expands the current page's ancestor sections and marks the current
+page with `aria-current`. When changing the recursive templates, pass all
+navigation state through both `renderChildren` and `renderList`. Keep the page
+filter and the `$hasChildren` calculation aligned so an expand control never
+points to an empty list or disappears for a rendered list.
+
+## Hidden pages
+
+Set `sitemap: false` to hide a page from site-wide discovery. This setting:
+
+- Excludes the page from `sitemap.xml`, `metadata.json`, and `llms-full.txt`
+- Excludes the page body from the site search index
+- Adds a `noindex` robots meta tag
+
+The page is still built and remains available through direct links. This is
+not an access control mechanism.
+
+Hugo does not automatically apply `sitemap: false` from a section page to its
+descendants. To hide an entire subtree, cascade the value from the section's
+`_index.md`:
+
+```yaml
+sitemap: false
+cascade:
+  sitemap: false
+```
+
+## Hidden sections in the sidebar
+
+The sidebar uses `sitemap` as a navigation visibility filter. A hidden page is
+absent from the sidebar outside its active navigation path. The current page
+and its ancestors remain visible so direct links to hidden pages do not produce
+an empty navigation path.
+
+When the active path enters a hidden section, `revealHidden` propagates down
+that branch and renders the whole hidden subtree. This keeps the section's
+navigation available while you are in it. The state must remain scoped to that
+branch so unrelated hidden pages stay hidden.
+
+## Hugo shortcodes
+
+Shortcodes are defined in `layouts/shortcodes/`. Syntax reference is in
+COMPONENTS.md. Wrong shortcode syntax fails silently during build but
+produces broken HTML — always check COMPONENTS.md for correct syntax.
+
+## Commands
+
+```sh
+npx --no-install rumdl fmt <file>  # Format Markdown before committing
+npx prettier --write <file>        # Format non-Markdown files
+scripts/lint.sh <file>...          # Lint specific files (rumdl + Vale)
+docker buildx bake validate        # Run all validation checks
+docker buildx bake lint            # Markdown linting only
+docker buildx bake vale            # Style guide checks only
+docker buildx bake test            # HTML and link checking
+```
+
+For incremental work, prefer `scripts/lint.sh` over the `bake` targets —
+it runs the same checks on just the files you pass, so the output stays
+scoped to your changes instead of the whole repo.
+
+### Validation in git worktrees
+
+`docker buildx bake validate` fails in git worktrees because Hugo cannot
+resolve the worktree path. Use `lint` and `vale` targets separately instead.
+Never modify `hugo.yaml` to work around this. The `test`, `path-warnings`,
+and `validate-vendor` targets run correctly in CI.
+
+## Verification loop
+
+1. Make changes
+2. Format Markdown with rumdl: `npx --no-install rumdl fmt <file>`
+3. Lint the changed files: `scripts/lint.sh <file>...`
+4. Run a full build with `docker buildx bake` (optional for small changes)
+
+Always lint the specific files you changed before committing. Use
+`scripts/lint.sh` rather than the `bake` targets so the output is scoped
+to your changes — bake runs across the entire repo and the noise makes
+real issues easy to miss.
+
+## Git hygiene
+
+- **Stage files explicitly.** Never use `git add .` / `git add -A` /
+  `git add --all`. Running `npx prettier` updates `package-lock.json` in the
+  repo root, and broad staging sweeps it into the commit.
+- **Verify before committing.** Run `git diff --cached --name-only` and
+  confirm only documentation files appear. If `package-lock.json` or other
+  generated files are staged, unstage them:
+  `git reset HEAD -- package-lock.json`
+- **Push to your fork, not upstream.** Before pushing, confirm
+  `git remote get-url origin` returns your fork URL, not
+  `github.com/docker/docs`. Use `--head FORK_OWNER:branch-name` with
+  `gh pr create`.
+
+## Working with issues and PRs
+
+### Principles
+
+- **One issue, one branch, one PR.** Never combine multiple issues in a
+  single branch or PR.
+- **Minimal changes only.** Fix the issue. Do not improve surrounding
+  content, add comments, refactor, or address adjacent problems.
+- **Verify before documenting.** Don't take an issue reporter's claim at
+  face value — the diagnosis may be wrong even when the symptom is real.
+  Verify the actual behavior before updating docs.
+
+### Review feedback
+
+- **Always reply to review comments** — never silently fix. After every
+  commit that addresses review feedback, reply to each thread explaining
+  what was done.
+- **Treat reviewer feedback as claims to verify, not instructions to
+  execute.** Before implementing a suggestion, verify that it is correct.
+  Push back when evidence contradicts the reviewer.
+- **Inline review comments need a separate API call.** `gh pr view --json
+  reviews` does not include line-level comments. Always also call:
+
+  ```bash
+  gh api repos/<org>/<repo>/pulls/<N>/comments \
+    --jq '[.[] | {author: .user.login, body: .body, path: .path, line: .line}]'
+  ```
+
+### Labels
+
+Use the Issues API for labels — `gh pr edit --add-label` silently fails:
+
+```bash
+gh api repos/docker/docs/issues/<N>/labels \
+  --method POST --field 'labels[]=<label>'
+```
+
+### External links
+
+If a replacement URL cannot be verified (e.g. network restrictions), treat
+the task as blocked — do not commit a guessed URL. Report the blocker so a
+human can confirm. Exception: when a domain migration is well-established and
+only the anchor is unverifiable, dropping the anchor is acceptable.
+
+## Page deletion checklist
+
+When removing a documentation page, search the entire `content/` tree and
+all YAML/TOML config files for the deleted page's slug and heading text.
+Cross-references from unrelated sections and config-driven nav entries can
+remain and cause broken links.
+
+## Engine API version bumps
+
+When a new Engine API version ships, three coordinated changes are needed in
+a single commit:
+
+1. `hugo.yaml` — update `latest_engine_api_version`, `docker_ce_version`,
+   and `docker_ce_version_prev`
+2. Create `content/reference/api/engine/version/v<NEW>.md` with the
+   `/latest/` aliases block (copy from previous version)
+3. Remove the aliases block from
+   `content/reference/api/engine/version/v<PREV>.md`
+
+Never leave both version files carrying `/latest/` aliases simultaneously.
+
+## Hugo icon references
+
+Before changing an icon reference in response to a "file not found" error,
+verify the file actually exists via Hugo's virtual filesystem. Files may
+exist in `node_modules/@material-symbols/svg-400/rounded/` but not directly
+in `assets/icons/`. Check both locations before concluding an icon is
+missing.
+
+## Self-improvement
+
+After completing work that reveals a non-obvious pattern or repo quirk not
+already documented here, propose an update to this file. For automated
+sessions, note the learning in a comment on the issue. For human-supervised
+sessions, discuss with the user whether to update CLAUDE.md directly.
diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 120000
index 000000000000..47dc3e3d863c
--- /dev/null
+++ b/CLAUDE.md
@@ -0,0 +1 @@
+AGENTS.md
\ No newline at end of file
diff --git a/COMPONENTS.md b/COMPONENTS.md
new file mode 100644
index 000000000000..69eeef375181
--- /dev/null
+++ b/COMPONENTS.md
@@ -0,0 +1,632 @@
+# Docker Documentation Components Guide
+
+This guide explains how to use components, shortcodes, and special features
+when writing Docker documentation. For writing style and grammar, see
+[STYLE.md](STYLE.md).
+
+## Front matter
+
+Every documentation page requires front matter at the top of the file.
+
+### Required fields
+
+```yaml
+---
+title: Install Docker Engine on Ubuntu
+description: Instructions for installing Docker Engine on Ubuntu
+keywords: requirements, apt, installation, ubuntu
+---
+```
+
+| Field       | Description                                                  |
+| ----------- | ------------------------------------------------------------ |
+| title       | Page title, used in `<h1>` and `<title>` tag                 |
+| description | SEO description (150-160 characters), added to HTML metadata |
+| keywords    | Comma-separated keywords for SEO                             |
+
+### Optional fields
+
+| Field           | Description                                                        |
+| --------------- | ------------------------------------------------------------------ |
+| linkTitle       | Shorter title for navigation and sidebar (if different from title) |
+| weight          | Controls sort order in navigation (lower numbers appear first)     |
+| aliases         | List of URLs that redirect to this page                            |
+| toc_min         | Minimum heading level in table of contents (default: 2)            |
+| toc_max         | Maximum heading level in table of contents (default: 3)            |
+| notoc           | Set to `true` to disable table of contents                         |
+| sitemap         | Set to `false` to exclude from search engine indexing              |
+| sidebar.badge   | Add badge to sidebar (see [Badges](#badges))                       |
+| sidebar.reverse | Reverse sort order of pages in section                             |
+| sidebar.goto    | Override sidebar link URL                                          |
+
+### Example with optional fields
+
+```yaml
+---
+title: Install Docker Engine on Ubuntu
+linkTitle: Install on Ubuntu
+description: Instructions for installing Docker Engine on Ubuntu
+keywords: requirements, apt, installation, ubuntu, install, uninstall
+weight: 10
+aliases:
+  - /engine/installation/linux/ubuntu/
+  - /install/linux/ubuntu/
+toc_max: 4
+params:
+  sidebar:
+    badge:
+      color: blue
+      text: Beta
+---
+```
+
+### Series (guide) pages
+
+Section pages under `content/guides/` automatically use the `series` layout
+(via a Hugo cascade in `hugo.yaml`). Series pages support additional front
+matter parameters for the metadata card:
+
+```yaml
+---
+title: Getting started
+description: Learn the basics of Docker
+summary: |
+  A longer summary shown on the series landing page.
+params:
+  proficiencyLevel: Beginner
+  time: 15 minutes
+  prerequisites: None
+---
+```
+
+| Field            | Description                              |
+| ---------------- | ---------------------------------------- |
+| summary          | Extended description for the series page |
+| proficiencyLevel | Skill level (Beginner, Intermediate)     |
+| time             | Estimated time to complete               |
+| prerequisites    | Prerequisites or "None"                  |
+
+## Shortcodes
+
+Shortcodes are reusable components that add rich functionality to your
+documentation.
+
+### Tabs
+
+Use tabs for platform-specific instructions or content variations.
+
+**Example:**
+
+{{< tabs >}}
+{{< tab name="Linux" >}}
+
+```console
+$ docker run hello-world
+```
+
+{{< /tab >}}
+{{< tab name="macOS" >}}
+
+```console
+$ docker run hello-world
+```
+
+{{< /tab >}}
+{{< tab name="Windows" >}}
+
+```powershell
+docker run hello-world
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+**Syntax:**
+
+```markdown
+{{</* tabs */>}}
+{{</* tab name="Linux" */>}}
+Content for Linux
+{{</* /tab */>}}
+{{</* tab name="macOS" */>}}
+Content for macOS
+{{</* /tab */>}}
+{{</* /tabs */>}}
+```
+
+**Tab groups (synchronized selection):**
+
+Use the `group` attribute to synchronize tab selection across multiple tab
+sections:
+
+```markdown
+{{</* tabs group="os" */>}}
+{{</* tab name="Linux" */>}}
+Linux content for first section
+{{</* /tab */>}}
+{{</* tab name="macOS" */>}}
+macOS content for first section
+{{</* /tab */>}}
+{{</* /tabs */>}}
+
+{{</* tabs group="os" */>}}
+{{</* tab name="Linux" */>}}
+Linux content for second section
+{{</* /tab */>}}
+{{</* tab name="macOS" */>}}
+macOS content for second section
+{{</* /tab */>}}
+{{</* /tabs */>}}
+```
+
+When a user selects "Linux" in the first section, all tabs in the "os" group
+switch to "Linux".
+
+### Accordion
+
+Use accordions for collapsible content like optional steps or advanced
+configuration.
+
+**Example:**
+
+{{< accordion title="Advanced configuration" >}}
+
+```yaml
+version: "3.8"
+services:
+  web:
+    build: .
+    ports:
+      - "8000:8000"
+```
+
+{{< /accordion >}}
+
+**Syntax:**
+
+```markdown
+{{</* accordion title="Advanced configuration" */>}}
+Content inside the accordion
+{{</* /accordion */>}}
+```
+
+### Include
+
+Reuse content across multiple pages using the include shortcode. Include
+files must be in the `content/includes/` directory.
+
+**Syntax:**
+
+```markdown
+{{</* include "filename.md" */>}}
+```
+
+**Example:**
+
+```markdown
+{{</* include "install-prerequisites.md" */>}}
+```
+
+### Badges
+
+Use badges to highlight new, beta, experimental, or deprecated content.
+
+**Example:**
+
+{{< badge color=blue text="Beta" >}}
+{{< badge color=violet text="Experimental" >}}
+{{< badge color=green text="New" >}}
+{{< badge color=gray text="Deprecated" >}}
+
+**Syntax:**
+
+Inline badge:
+
+```markdown
+{{</* badge color=blue text="Beta" */>}}
+```
+
+Badge as link:
+
+```markdown
+[{{</* badge color=blue text="Beta feature" */>}}](link-to-page.md)
+```
+
+Sidebar badge (in front matter):
+
+```yaml
+---
+title: Page title
+params:
+  sidebar:
+    badge:
+      color: violet
+      text: Experimental
+---
+```
+
+**Color options:**
+
+- `blue` - Beta content
+- `violet` - Experimental or early access
+- `green` - New GA content
+- `amber` - Warning or attention
+- `red` - Critical
+- `gray` - Deprecated
+
+**Usage guidelines:**
+
+- Use badges for no longer than 2 months post-release
+- Use violet for experimental/early access features
+- Use blue for beta features
+- Use green for new GA features
+- Use gray for deprecated features
+
+### Summary bars
+
+Summary bars indicate subscription requirements, version requirements, or
+administrator-only features at the top of a page.
+
+**Example:**
+
+{{< summary-bar feature_name="Docker Scout" >}}
+
+**Setup:**
+
+1. Add feature to `/data/summary.yaml`:
+
+```yaml
+features:
+  Docker Scout:
+    subscription: Business
+    availability: GA
+    requires: "Docker Desktop 4.17 or later"
+```
+
+2. Add shortcode to page:
+
+```markdown
+{{</* summary-bar feature_name="Docker Scout" */>}}
+```
+
+**Attributes in summary.yaml:**
+
+| Attribute    | Description                           | Values                                            |
+| ------------ | ------------------------------------- | ------------------------------------------------- |
+| subscription | Subscription tier required            | All, Personal, Pro, Team, Business                |
+| availability | Product development stage             | Experimental, Beta, Early Access, GA, Retired     |
+| requires     | Minimum version requirement           | String describing version (link to release notes) |
+| for          | Indicates administrator-only features | Administrators                                    |
+
+### Buttons
+
+Create styled buttons for calls to action.
+
+**Syntax:**
+
+```markdown
+{{</* button text="Download Docker Desktop" url="/get-docker/" */>}}
+```
+
+### Cards
+
+Create card layouts for organizing content.
+
+**Syntax:**
+
+```markdown
+{{</* card
+  title="Get started"
+  description="Learn Docker basics"
+  link="/get-started/"
+*/>}}
+```
+
+### Icons
+
+Use Material Symbols icons in your content.
+
+**Syntax:**
+
+```markdown
+{{</* icon name="check_circle" */>}}
+```
+
+Browse available icons at
+[Material Symbols](https://fonts.google.com/icons).
+
+## Callouts
+
+Use GitHub-style callouts to emphasize important information. Use sparingly -
+only when information truly deserves special emphasis.
+
+**Syntax:**
+
+```markdown
+> [!NOTE]
+> This is a note with helpful context.
+
+> [!TIP]
+> This is a helpful suggestion or best practice.
+
+> [!IMPORTANT]
+> This is critical information users must understand.
+
+> [!WARNING]
+> This warns about potential issues or consequences.
+
+> [!CAUTION]
+> This is for dangerous operations requiring extreme care.
+```
+
+**When to use each type:**
+
+| Type      | Use for                                                        | Color  |
+| --------- | -------------------------------------------------------------- | ------ |
+| Note      | Information that may not apply to all readers or is tangential | Blue   |
+| Tip       | Helpful suggestions or best practices                          | Green  |
+| Important | Issues of moderate magnitude                                   | Yellow |
+| Warning   | Actions that may cause damage or data loss                     | Red    |
+| Caution   | Serious risks                                                  | Red    |
+
+## Code blocks
+
+Format code with syntax highlighting using triple backticks and language
+hints.
+
+### Language hints
+
+Common language hints:
+
+- `console` - Interactive shell with `$` prompt
+- `bash` - Bash scripts
+- `dockerfile` - Dockerfiles
+- `yaml` - YAML files
+- `json` - JSON data
+- `go`, `python`, `javascript` - Programming languages
+- `powershell` - PowerShell commands
+
+**Interactive shell example:**
+
+````markdown
+```console
+$ docker run hello-world
+```
+````
+
+**Bash script example:**
+
+````markdown
+```bash
+#!/usr/bin/bash
+echo "Hello from Docker"
+```
+````
+
+### Variables in code
+
+Use `<VARIABLE_NAME>` format for placeholder values:
+
+````markdown
+```console
+$ docker tag <IMAGE_NAME> <REGISTRY>/<IMAGE_NAME>:<TAG>
+```
+````
+
+This syntax renders variables in a special color and font style.
+
+### Highlighting lines
+
+Highlight specific lines with `hl_lines`:
+
+````markdown
+```go {hl_lines=[3,4]}
+func main() {
+    fmt.Println("Hello")
+    fmt.Println("This line is highlighted")
+    fmt.Println("This line is highlighted")
+}
+```
+````
+
+### Collapsible code blocks
+
+Make long code blocks collapsible:
+
+````markdown
+```dockerfile {collapse=true}
+# syntax=docker/dockerfile:1
+FROM golang:1.21-alpine
+RUN apk add --no-cache git
+# ... more lines
+```
+````
+
+## Images
+
+Add images using standard Markdown syntax with optional query parameters for
+sizing and borders.
+
+**Basic syntax:**
+
+```markdown
+![Alt text description](/assets/images/image.png)
+```
+
+**With size parameters:**
+
+```markdown
+![Alt text](/assets/images/image.png?w=600&h=400)
+```
+
+**With border:**
+
+```markdown
+![Alt text](/assets/images/image.png?border=true)
+```
+
+**Combined parameters:**
+
+```markdown
+![Alt text](/assets/images/image.png?w=600&h=400&border=true)
+```
+
+**Best practices:**
+
+- Store images in `/static/assets/images/`
+- Use descriptive alt text for accessibility
+- Compress images before adding to repository
+- Capture only relevant UI, avoid unnecessary whitespace
+- Use realistic text, not lorem ipsum
+- Remove unused images from repository
+
+## Videos
+
+Embed videos using HTML video tags or platform-specific embeds.
+
+**Local video:**
+
+```html
+<video controls width="100%">
+  <source src="/assets/videos/demo.mp4" type="video/mp4" />
+</video>
+```
+
+**YouTube embed:**
+
+```html
+<iframe
+  width="560"
+  height="315"
+  src="https://www.youtube.com/embed/VIDEO_ID"
+  frameborder="0"
+  allow="autoplay; encrypted-media"
+  allowfullscreen
+>
+</iframe>
+```
+
+## Links
+
+Use standard Markdown link syntax. For internal links, use relative paths
+with source filenames.
+
+**External link:**
+
+```markdown
+[Docker Hub](https://hub.docker.com/)
+```
+
+**Internal link (same section):**
+
+```markdown
+[Installation guide](install.md)
+```
+
+**Internal link (different section):**
+
+```markdown
+[Get started](/get-started/overview.md)
+```
+
+**Link to heading:**
+
+```markdown
+[Prerequisites](#prerequisites)
+```
+
+**Best practices:**
+
+- Use descriptive link text (around 5 words)
+- Front-load important terms
+- Avoid generic text like "click here" or "learn more"
+- Don't include end punctuation in link text
+- Use relative paths for internal links
+
+## Lists
+
+### Unordered lists
+
+```markdown
+- First item
+- Second item
+- Third item
+  - Nested item
+  - Another nested item
+```
+
+### Ordered lists
+
+```markdown
+1. First step
+2. Second step
+3. Third step
+   1. Nested step
+   2. Another nested step
+```
+
+### Best practices
+
+- Limit bulleted lists to 5 items when possible
+- Don't add commas or semicolons to list item ends
+- Capitalize list items for ease of scanning
+- Make all list items parallel in structure
+- For nested sequential lists, use lowercase letters (a, b, c)
+
+## Tables
+
+Use standard Markdown table syntax with sentence case for headings.
+
+**Example:**
+
+```markdown
+| Feature        | Description                     | Availability |
+| -------------- | ------------------------------- | ------------ |
+| Docker Compose | Multi-container orchestration   | All          |
+| Docker Scout   | Security vulnerability scanning | Business     |
+| Build Cloud    | Remote build service            | Pro, Team    |
+```
+
+**Best practices:**
+
+- Use sentence case for table headings
+- Don't leave cells empty - use "N/A" or "None"
+- Align decimals on the decimal point
+- Keep tables scannable - avoid dense content
+
+## Quick reference
+
+### File structure
+
+```plaintext
+content/
+├── manuals/              # Product documentation
+│   ├── docker-desktop/
+│   ├── docker-hub/
+│   └── ...
+├── guides/               # Learning guides
+├── reference/            # API and CLI reference
+└── includes/             # Reusable content snippets
+```
+
+### Common patterns
+
+**Platform-specific instructions:**
+
+Use tabs with consistent names: Linux, macOS, Windows
+
+**Optional content:**
+
+Use accordions for advanced or optional information
+
+**Version/subscription indicators:**
+
+Use badges or summary bars
+
+**Important warnings:**
+
+Use callouts (NOTE, WARNING, CAUTION)
+
+**Code examples:**
+
+Use `console` for interactive shells, appropriate language hints for code
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 2ce05f85a896..22766bb85dd1 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -3,11 +3,14 @@
 We value documentation contributions from the Docker community. We'd like to
 make it as easy as possible for you to work in this repository.
 
-Our style guide and instructions on using our page templates and components is
-available in the [contribution section](https://docs.docker.com/contribute/) on
-the website.
+Before contributing, review our documentation standards:
 
-The following guidelines describe the ways in which you can contribute to the
+- [STYLE.md](STYLE.md) - Writing style, voice, grammar, and formatting
+  guidelines
+- [COMPONENTS.md](COMPONENTS.md) - How to use Hugo shortcodes, front matter,
+  and components
+
+The following guidelines describe how to contribute to the
 Docker documentation at <https://docs.docker.com/>, and how to get started.
 
 ## Reporting issues
@@ -91,6 +94,9 @@ To stop the development server:
 1. In your terminal, press `<Ctrl+C>` to exit the file watch mode of Compose.
 2. Stop the Compose service with the `docker compose down` command.
 
+> [!NOTE]
+> Alternatively, if you have installed Hugo, you can build with `hugo serve`.
+
 ### Testing
 
 Before you push your changes and open a pull request, we recommend that you
@@ -105,13 +111,17 @@ If this command doesn't result in any errors, you're good to go!
 
 ## Content not edited here
 
-CLI reference documentation is maintained in upstream repositories. It's
-partially generated from code, and is only vendored here for publishing. To
-update the CLI reference docs, refer to the corresponding repository:
+CLI reference documentation is maintained in upstream repositories and
+generated from YAML data files in `data/cli/`. A Hugo content adapter
+(`content/reference/cli/_content.gotmpl`) turns these data files into pages
+automatically. To update the CLI reference docs, refer to the corresponding
+repository:
 
 - [docker/cli](https://github.com/docker/cli)
 - [docker/buildx](https://github.com/docker/buildx)
 - [docker/compose](https://github.com/docker/compose)
+- [docker/model-runner](https://github.com/docker/model-runner)
+- [docker/mcp-gateway](https://github.com/docker/mcp-gateway)
 
 Feel free to raise an issue on this repository if you're not sure how to
 proceed, and we'll help out.
diff --git a/Dockerfile b/Dockerfile
index c7e22db80cc7..b0ab6a5993cf 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,12 +1,13 @@
 # syntax=docker/dockerfile:1
 # check=skip=InvalidBaseImagePlatform
 
-ARG ALPINE_VERSION=3.21
-ARG GO_VERSION=1.23.8
+ARG ALPINE_VERSION=3.23
+ARG GO_VERSION=1.26
 ARG HTMLTEST_VERSION=0.17.0
-ARG HUGO_VERSION=0.141.0
-ARG NODE_VERSION=22
-ARG PAGEFIND_VERSION=1.3.0
+ARG VALE_VERSION=3.17.0
+ARG HUGO_VERSION=0.163.0
+ARG NODE_VERSION=24
+ARG PAGEFIND_VERSION=1.5.2
 
 # base defines the generic base stage
 FROM golang:${GO_VERSION}-alpine${ALPINE_VERSION} AS base
@@ -14,7 +15,8 @@ RUN apk add --no-cache \
     git \
     nodejs \
     npm \
-    gcompat
+    gcompat \
+    rsync
 
 # npm downloads Node.js dependencies
 FROM base AS npm
@@ -48,16 +50,19 @@ ARG HUGO_ENV="development"
 ARG DOCS_URL="https://docs.docker.com"
 ENV HUGO_CACHEDIR="/tmp/hugo_cache"
 RUN --mount=type=cache,target=/tmp/hugo_cache \
-    hugo --gc --minify -e $HUGO_ENV -b $DOCS_URL
+    hugo \
+      --gc \
+      --minify \
+      --panicOnWarning \
+      --printPathWarnings \
+      --printUnusedTemplates \
+      -b $DOCS_URL \
+      -e $HUGO_ENV
+RUN ./hack/flatten-and-resolve.js public
 
 # lint lints markdown files
-FROM davidanson/markdownlint-cli2:v0.14.0 AS lint
-USER root
-RUN --mount=type=bind,target=. \
-    /usr/local/bin/markdownlint-cli2 \
-    "content/**/*.md" \
-    "#content/manuals/engine/release-notes/*.md" \
-    "#content/manuals/desktop/previous-versions/*.md"
+FROM ghcr.io/rvben/rumdl:0.2.49-alpine AS lint
+RUN --mount=type=bind,target=. rumdl check content
 
 # test validates HTML output and checks for broken links
 FROM wjdp/htmltest:v${HTMLTEST_VERSION} AS test
@@ -66,6 +71,23 @@ COPY --from=build /project/public ./public
 ADD .htmltest.yml .htmltest.yml
 RUN htmltest
 
+# vale
+FROM jdkato/vale:v${VALE_VERSION} AS vale-run
+WORKDIR /src
+ARG GITHUB_ACTIONS
+RUN --mount=type=bind,target=.,rw <<EOT
+  set -e
+  mkdir /out
+  args=""
+  [ "$GITHUB_ACTIONS" = "true" ] && args="--output=.vale-rdjsonl.tmpl"
+  set -x
+  vale sync
+  vale $args content/ | tee /out/vale.out
+EOT
+
+FROM scratch AS vale
+COPY --from=vale-run /out/vale.out /
+
 # update-modules downloads and vendors Hugo modules
 FROM build-base AS update-modules
 # MODULE is the Go module path and version of the module to update
@@ -74,8 +96,6 @@ RUN <<"EOT"
 set -ex
 if [ -n "$MODULE" ]; then
     hugo mod get ${MODULE}
-    RESOLVED=$(cat go.mod | grep -m 1 "${MODULE/@*/}" | awk '{print $1 "@" $2}')
-    go mod edit -replace "${MODULE/@*/}=${RESOLVED}";
 else
     echo "no module set";
 fi
@@ -87,6 +107,22 @@ FROM scratch AS vendor
 COPY --from=update-modules /project/_vendor /_vendor
 COPY --from=update-modules /project/go.* /
 
+FROM base AS validate-vendor
+RUN --mount=target=/context \
+  --mount=type=bind,from=vendor,target=/out \
+  --mount=target=.,type=tmpfs <<EOT
+set -e
+rsync -a /context/. .
+git add -A
+rm -rf _vendor
+cp -rf /out/* .
+if [ -n "$(git status --porcelain -- go.mod go.sum _vendor)" ]; then
+  echo >&2 'ERROR: Vendor result differs. Please vendor your package with "make vendor"'
+  git status --porcelain -- go.mod go.sum _vendor
+  exit 1
+fi
+EOT
+
 # build-upstream builds an upstream project with a replacement module
 FROM build-base AS build-upstream
 # UPSTREAM_MODULE_NAME is the canonical upstream repository name and namespace (e.g. moby/buildkit)
@@ -112,18 +148,6 @@ RUN apk add --no-cache fd ripgrep
 WORKDIR /test
 RUN --mount=type=bind,target=. ./hack/test/unused_media
 
-# path-warnings checks for duplicate target paths
-FROM build-base AS path-warnings
-RUN hugo --printPathWarnings > ./path-warnings.txt
-RUN <<EOT
-DUPLICATE_TARGETS=$(grep "Duplicate target paths" ./path-warnings.txt)
-if [ ! -z "$DUPLICATE_TARGETS" ]; then
-    echo "$DUPLICATE_TARGETS"
-    echo "You probably have a duplicate alias defined. Please check your aliases."
-    exit 1
-fi
-EOT
-
 # pagefind installs the Pagefind runtime
 FROM base AS pagefind
 ARG PAGEFIND_VERSION
diff --git a/README.md b/README.md
index 39500fb38823..13f534ebbc64 100644
--- a/README.md
+++ b/README.md
@@ -1,52 +1,40 @@
 # Docs @ Docker
 
-<img src="static/assets/images/docker-docs.png" alt="Welcome to Docker Documentation" style="max-width: 50%;">
+<div align="center">
+<img src="static/assets/images/docker-docs.svg" alt="Welcome to Docker Documentation">
+</div>
+<br/>
+<br/>
 
-Welcome to the Docker Documentation repository. This is the source for
-[https://docs.docker.com/](https://docs.docker.com/).
+Welcome to the Docker Documentation repository. This is the source for the [Docker Docs Website](https://docs.docker.com/).
 
-Feel free to send us pull requests and file issues. Our docs are completely
-open source, and we deeply appreciate contributions from the Docker community!
+Feel free to open pull requests or issues. Our docs are completely open source, and we deeply appreciate contributions from the Docker community!
 
 ## Provide feedback
 
-We’d love to hear your feedback. Please file documentation issues only in the
-Docs GitHub repository. You can file a new issue to suggest improvements or if
-you see any errors in the existing documentation.
+We’d love to hear your feedback! To submit feedback:
 
-Before submitting a new issue, check whether the issue has already been
-reported. You can join the discussion using an emoji, or by adding a comment to
-an existing issue. If possible, we recommend that you suggest a fix to the issue
-by creating a pull request.
+- Click **[New issue](https://github.com/docker/docs/issues/new)** on the docs repository, or
+- Click **Request changes** in the right column of every page on
+  [docs.docker.com](https://docs.docker.com/), or
+- Click **Give feedback** on every page in the docs.
 
-You can ask general questions and get community support through the [Docker
-Community Slack](https://dockr.ly/comm-slack). Personalized support is available
+To get community support, use the [Docker Community Slack](https://dockr.ly/comm-slack). Personalized support is available
 through the Docker Pro, Team, and Business subscriptions. See [Docker
-Pricing](https://www.docker.com/pricing) for details.
+Pricing](https://www.docker.com/pricing?ref=Docs&refAction=DocsReadme) for details.
 
 If you have an idea for a new feature or behavior change in a specific aspect of
-Docker or have found a product bug, file that issue in the project's code
+Docker or have found a product bug, file an issue in the project's
 repository.
 
-We've made it easy for you to file new issues.
-
-- Click **[New issue](https://github.com/docker/docs/issues/new)** on the docs repository and fill in the details, or
-- Click **Request docs changes** in the right column of every page on
-  [docs.docker.com](https://docs.docker.com/) and add the details, or
-
-  ![Request changes link](/static/assets/images/docs-site-feedback.png)
-
-- Click the **Give feedback** link on the side of every page in the docs.
-
-  ![Docs feedback on each page](/static/assets/images/feedback-widget.png)
-
 ## Contribute to Docker docs
 
-We value your contribution. We want to make it as easy as possible to submit
-your contributions to the Docker docs repository. Changes to the docs are
-handled through pull requests against the `main` branch. To learn how to
-contribute, see [CONTRIBUTING.md](CONTRIBUTING.md).
+We welcome contributions! To get started:
+
+- [CONTRIBUTING.md](CONTRIBUTING.md) - Contribution workflow and setup
+- [STYLE.md](STYLE.md) - Writing style and content guidelines
+- [COMPONENTS.md](COMPONENTS.md) - Component and shortcode usage
 
 ## Copyright and license
 
-Copyright 2013-2025 Docker, Inc., released under the <a href="https://github.com/docker/docs/blob/main/LICENSE">Apache 2.0 license</a> .
+Copyright 2013-2026 Docker, Inc., released under the [Apache 2.0 license](https://github.com/docker/docs/blob/main/LICENSE).
diff --git a/STYLE.md b/STYLE.md
new file mode 100644
index 000000000000..6909b4b28a4c
--- /dev/null
+++ b/STYLE.md
@@ -0,0 +1,643 @@
+# Docker Documentation Style Guide
+
+This guide consolidates voice, grammar, formatting, and terminology
+standards for Docker documentation. Follow these guidelines to create
+clear, consistent, and helpful content. For instructions on how to use
+components, shortcodes, and other features, see [COMPONENTS.md](COMPONENTS.md).
+
+## Voice and tone
+
+Write like a knowledgeable colleague explaining something useful. We're
+developers writing for developers.
+
+### Core principles: The 4Cs
+
+1. **Correct** - Information is accurate
+2. **Concise** - Succinct without unnecessary words
+3. **Complete** - Includes enough detail to complete the task
+4. **Clear** - Easy to understand
+
+### Writing approach
+
+- **Be honest.** Give all the facts. Don't use misdirection or
+  ambiguous statements.
+- **Be concise.** Don't bulk up communication with fluffy words or
+  complex metaphors. Get to the point.
+- **Be relaxed.** Casual but not lazy, smart but not arrogant, focused
+  but not cold. Be welcoming and warm.
+- **Be inclusive.** Every person is part of our community, regardless
+  of experience level.
+
+### Tone guidelines
+
+- Use a natural, friendly, and respectful tone
+- Use contractions to sound conversational (it's, you're, don't)
+- Avoid overdoing politeness - skip "please" in most technical documentation
+- Be clear over comical
+- Use positive language - emphasize what users can do, not what they can't
+
+**Positive language example:**
+
+Instead of: "Features such as Single Sign-on (SSO), Image Access
+Management, Registry Access Management are not available in Docker Team
+subscription."
+
+Use: "Features such as Single Sign-on (SSO), Image Access Management,
+Registry Access Management are available in Docker Business subscription."
+
+### Avoiding marketing language
+
+Documentation should be factual and direct, not promotional.
+
+**Avoid hedge words** that overstate ease or capability:
+
+- ❌ simply, just, easily, seamlessly (implies ease when it may not be
+  easy)
+- ❌ robust, powerful (marketing language)
+- ✅ Instead: describe what it actually does
+
+**Avoid excessive enthusiasm:**
+
+- ❌ "powerful feature", "game-changing", "revolutionary", "amazing"
+- ✅ Instead: describe the feature and its benefits factually
+
+**Avoid meta-commentary:**
+
+These phrases add no value - state the fact directly:
+
+- ❌ "It's worth noting that..."
+- ❌ "It's important to understand that..."
+- ❌ "Keep in mind that..."
+- ✅ Instead: state the information directly
+
+### Voice and perspective
+
+- **Use "you" not "we"**: Focus on what the user can do, not what "we"
+  created
+  - ❌ "We provide a feature that helps you deploy"
+  - ✅ "Deploy your applications with..."
+- **Avoid "please"**: Don't use in normal explanations or "please note"
+  phrases
+- **Write timelessly**: Avoid "currently" or "as of this writing" - the
+  documentation describes the product as it is today
+
+### Explain technical behavior
+
+Explain behavior from the reader's perspective. Lead with the observable
+outcome, then add the implementation details needed to explain it.
+
+Prefer:
+
+> Changes made by the agent stay inside the sandbox until you fetch them. The
+> agent works in a separate Git clone inside the sandbox.
+
+Avoid:
+
+> A session that works directly in the sandbox clone still can't modify your
+> host repository.
+
+The preferred version tells readers where changes happen and when they become
+visible. The second version makes readers reconstruct the relationship between
+the session, sandbox clone, and host repository.
+
+Separate guarantees from variable behavior. Don't present behavior controlled
+by another tool as a product default or guarantee. When behavior varies,
+structure the explanation in this order:
+
+1. State what always happens
+2. State what the product doesn't control
+3. Tell the reader what to do
+
+For example:
+
+> The `--clone` flag creates the clone, but it doesn't separate one task from
+> another. To keep parallel tasks isolated, instruct your agent tool to create
+> a separate branch or worktree for each task.
+
+Avoid chains of qualifications such as "may," "can," and "depends" that leave
+the reader without a conclusion. Keep qualifiers that are needed for accuracy.
+State what controls the behavior and what the reader should do.
+
+### Scope preservation
+
+When updating existing documentation, resist the urge to expand
+unnecessarily. Users value brevity.
+
+**Understand the current document:**
+Read it fully to grasp its scope, length, and character. Is it a minimal
+how-to or a comprehensive reference?
+
+**Match the existing character:**
+If the document is brief and direct (90 lines), keep it that way. Don't
+transform a focused guide into an exhaustive tutorial.
+
+**Add only what's genuinely missing:**
+Fill gaps, don't elaborate. If the document already covers a topic
+adequately, don't expand it.
+
+**Value brevity:**
+Say what needs to be said, then stop. Not every topic needs
+prerequisites, troubleshooting, best practices, and examples sections.
+
+**Respect the original intent:**
+The document exists in its current form for a reason. Improve it, don't
+remake it.
+
+Good additions fill genuine gaps. Bad additions change the document's
+character. When in doubt, add less rather than more.
+
+Include caveats, failure scenarios, and fallback behavior only when they affect
+a decision or action. Don't turn a clarification into a catalog of edge
+cases.
+
+## Grammar and style
+
+Write in US English with US grammar.
+
+### Acronyms and initialisms
+
+- Spell out lesser-known acronyms on first use, then follow with the
+  acronym in parentheses: "single sign-on (SSO)"
+- Don't spell out common acronyms like URL, HTML, API
+- Use all caps for file type acronyms: JPEG, PNG
+- Don't use apostrophes for plurals: URLs not URL's
+- Avoid introducing acronyms in headings - introduce them in the body
+  text that follows
+
+### Capitalization
+
+Use sentence case for almost everything: headings, titles, links, buttons,
+navigation labels.
+
+- Capitalize Docker solutions: Docker Desktop, Docker Hub, Docker Extensions
+- Capitalize job titles only when they immediately precede a name:
+  "Chief Executive Officer Scott Johnston" but "Scott Johnston, chief
+  executive officer"
+- Follow company capitalization preferences: DISH, bluecrux
+- Match UI capitalization when referring to specific interface elements
+
+### Contractions
+
+Use contractions to maintain a conversational tone, but don't overdo it.
+
+- Stay consistent - don't switch between "you are" and "you're" in the
+  same content
+- Avoid negative contractions when possible (can't, don't, won't) -
+  rewrite to be positive
+- Never contract a noun with a verb (your container is ready, not your
+  container's ready)
+
+### Clear subjects and modifiers
+
+Name the actor when a system includes multiple tools or components. Repeat the
+noun instead of using an ambiguous pronoun. For example, distinguish between
+what a CLI creates, what an agent edits, and what remains on the host.
+
+Avoid unclear subjects:
+
+- ❌ After enabling auto-log-out, your users are logged out
+- ✅ When you enable auto-log-out, your users are logged out
+
+### Dates and numbers
+
+- Use US date format: June 26, 2021 or Jun. 26, 2021
+- Spell out numbers one through nine, except in units: 4 MB
+- Use numerals for 10 and above: 10, 625, 1000
+- Use decimals instead of fractions: 0.5 not ½
+- For numbers with five or more digits, use spaces instead of commas:
+  14 586 not 14,586
+- For version numbers: version 4.8.2, v1.0, Docker Hub API v2
+
+### Punctuation
+
+- **Commas:** Use the Oxford comma (serial comma) in lists
+- **Colons:** Use to introduce lists or provide explanations
+- **Semicolons:** Don't use - write two sentences instead
+- **Em dashes:** Use sparingly with spaces on either side: "text - like
+  this - text"
+- **Hyphens:** Use for compound adjectives before nouns:
+  "up-to-date documentation"
+- **Exclamation marks:** Avoid
+- **Parentheses:** Avoid in technical documentation - they reduce
+  readability
+
+### Conciseness and redundant phrases
+
+Remove unnecessary words to make documentation clearer and more direct.
+
+Keep an adjective or qualifier only when it changes how readers understand the
+behavior or complete the task. If removing it doesn't change an outcome,
+decision, or next step, remove it. Apply the same test to implementation
+details.
+
+**Eliminate redundant phrases:**
+
+- ❌ "in order to" → ✅ "to"
+- ❌ "serves the purpose of" → ✅ state what it does directly
+- ❌ "allows you to" → ✅ "lets you" or state what it does
+- ❌ "enables you to" → ✅ "lets you" or state what it does
+
+### Bold and italics
+
+Use bold **only** for UI elements (buttons, menus, field labels). Never
+use bold for emphasis, product names, or feature names.
+
+- ✅ Select **Save** (UI button - use bold)
+- ✅ Docker Hub provides storage (product name - no bold)
+- ✅ This is important to understand (emphasis - no bold)
+- ❌ **Docker Desktop** is a tool (product name - don't bold)
+- ❌ This is **very important** (emphasis - don't bold)
+- ❌ The **build** command (command name - don't bold)
+
+**Italics:**
+Use italics sparingly, as this formatting can be difficult to read in
+digital experiences. Notable exceptions are titles of articles, blog
+posts, or specification documents.
+
+## Formatting
+
+### Content types and detail balance
+
+Different content types require different writing approaches. Match your
+style and detail level to the content type.
+
+**Getting Started / Tutorials:**
+
+- Step-by-step instructions
+- Assume beginner knowledge
+- Explain _why_ at each step
+- Include more context and explanation
+
+**How-to Guides:**
+
+- Task-focused and goal-oriented
+- Assume intermediate knowledge
+- Focus on _how_ efficiently
+- Less explanation, more direct steps
+
+**Reference Documentation:**
+
+- Comprehensive and exhaustive
+- Assume advanced knowledge
+- Focus on _what_ precisely
+- Complete parameter lists and options
+
+**Concept Explanations:**
+
+- Educational and foundational
+- Any skill level
+- Focus on _understanding_ over doing
+- Theory before practice
+
+**Match detail to context:**
+
+- **First mention** of a concept: explain it
+- **Subsequent mentions**: link to the explanation or use the term
+  directly if recently explained
+- **Common knowledge** (to your audience): state it, don't explain it
+- **Edge cases**: mention them but don't let them dominate the main flow
+
+### Headings
+
+- Keep headings short (no more than eight words)
+- Front-load the most important words
+- Use descriptive, action-oriented language
+- Skip leading articles (a, the)
+- Avoid puns, teasers, and cultural references
+- Page titles should be action-oriented: "Install Docker Desktop",
+  "Enable SCIM"
+
+### Page structure and flow
+
+Every page should answer two questions in the first paragraph:
+
+1. **What will I learn?** - State what the page covers
+2. **Why does this matter?** - Explain the benefit or use case
+
+**Good opening:**
+
+```markdown
+Docker Compose Watch automatically updates your running containers when
+you change code. This eliminates the manual rebuild-restart cycle during
+development.
+```
+
+**Weak opening:**
+
+```markdown
+Docker Compose Watch is a powerful feature that enables developers to
+streamline their development workflow by providing automatic
+synchronization capabilities.
+```
+
+**Transitions and flow:**
+Connect ideas naturally. Each section should flow logically from the
+previous one. Save detailed discussions for after showing basic usage -
+don't front-load complexity.
+
+**Good flow:**
+
+1. Prerequisites
+2. Basic usage (show the simple case first)
+3. Advanced options (add complexity after basics are clear)
+
+**Jarring flow:**
+
+1. Prerequisites
+2. Overview of all capabilities (too much before seeing it work)
+3. Basic usage
+
+**Avoid structural problems:**
+
+- Don't start multiple sentences or sections with the same structure
+  (varies pacing and improves readability)
+- Don't over-explain obvious things (trust the reader's competence)
+- Don't use "**Bold:** format" for subsection labels (use plain text
+  with colon)
+
+### Guide structure
+
+Guides are single-page - don't split a guide into multiple sub-pages
+(for example, separate "overview", "configure", and "deploy" pages for
+one guide). Cover the full task on one page and use headings to
+organize sections.
+
+Store each guide as a single Markdown file directly under
+`content/guides/` (for example, `content/guides/django.md`), not
+wrapped in its own directory with an `index.md`. Guide images belong in
+the shared `content/guides/images/` folder, prefixed with the guide's
+slug, not in a per-guide directory - see [Images](STYLE.md#images).
+
+### Lists
+
+- Limit bulleted lists to five items when possible
+- Don't add commas or semicolons to list item ends
+- Capitalize list items for ease of scanning
+- Make all list items parallel in structure
+- Start each item with a capital letter unless it's a parameter or
+  command
+- For nested sequential lists, use lowercase letters: 1. Top level,
+  a. Child step
+
+**Avoid marketing-style list formatting:**
+
+Don't use "**Term** - Description" format, which reads like marketing
+copy:
+
+❌ **Bad example:**
+
+- **Build** - Creates images from Dockerfiles
+- **Run** - Starts containers from images
+- **Push** - Uploads images to registries
+
+✅ **Good alternatives:**
+
+Use simple descriptive bullets:
+
+- Build images from Dockerfiles
+- Start containers from images
+- Upload images to registries
+
+Or use proper prose when appropriate:
+"Docker lets you build images from Dockerfiles, start containers from
+images, and upload images to registries."
+
+### Code and commands
+
+Format Docker commands, instructions, filenames, and package names as
+inline code using backticks: `docker build`
+
+**Code example pattern:**
+
+Follow this three-step pattern for code examples:
+
+1. **State** what you're doing (brief)
+2. **Show** the command or code
+3. **Explain** the result or key parts (if not obvious)
+
+**Example:**
+
+````markdown
+Build your image:
+
+```console
+$ docker build -t my-app .
+```
+
+This creates an image tagged `my-app` using the Dockerfile in the
+current directory.
+````
+
+**When to show command output:**
+
+- Show output when it helps understanding
+- Show output when users need to verify results
+- Don't show output for commands with obvious results
+- Don't show output when it's not relevant to the point
+
+For code block syntax, language hints, variables, and advanced features
+(line highlighting, collapsible blocks), see
+[COMPONENTS.md](COMPONENTS.md#code-blocks).
+
+### Links
+
+- Use plain, descriptive language (around five words)
+- Front-load important terms at the beginning
+- Avoid generic calls to action like "click here" or "find out more"
+- Don't include end punctuation in link text
+- Use relative links with source filenames for internal links
+- Don't make link text bold or italic unless it would be in normal
+  body copy
+
+### Images
+
+**Best practices:**
+
+- Capture only relevant UI - don't include unnecessary white space
+- Use realistic text, not lorem ipsum
+- Keep images small and focused
+- Compress images before adding to repository
+- Remove unused images from repository
+
+**File organization:**
+
+- Store guide images in the shared `content/guides/images/` folder,
+  not in a per-guide directory
+- Prefix filenames with the guide's slug to avoid collisions (for
+  example, `kafka-architecture.webp`)
+
+For image syntax and parameters (sizing, borders), see
+[COMPONENTS.md](COMPONENTS.md#images).
+
+### Callouts
+
+Use callouts sparingly to emphasize important information. Use them only
+when information truly deserves special emphasis - for warnings, critical
+notes, or important context that affects how users approach a task.
+
+Callout types: Note (informational), Tip (helpful suggestion), Important
+(moderate issue), Warning (potential damage/loss), Caution (serious risk).
+
+For syntax and detailed usage guidelines, see
+[COMPONENTS.md](COMPONENTS.md#callouts).
+
+### Tables
+
+- Use sentence case for table headings
+- Don't leave cells empty - use "N/A" or "None" if needed
+- Align decimals on the decimal point
+
+### Navigation instructions
+
+- Use location, then action: "From the **Visibility** drop-down list, select Public"
+- Be brief and specific: "Select **Save**"
+- Start with the reason if a step needs one: "To view changes, select the link"
+
+### Optional steps
+
+Start optional steps with "Optional." followed by the instruction:
+
+_1. Optional. Enter a description for the job._
+
+### File types and units
+
+- Use formal file type names: "a PNG file" not "a .png file"
+- Use abbreviated units with spaces: "10 GB" not "10GB" or
+  "10 gigabytes"
+
+## Word list
+
+### Recommended terms
+
+| Use                                   | Don't use              |
+| ------------------------------------- | ---------------------- |
+| lets                                  | allows                 |
+| turn on, toggle on                    | enable                 |
+| turn off, toggle off                  | disable                |
+| select                                | click                  |
+| following                             | below                  |
+| previous                              | above                  |
+| checkbox                              | check box              |
+| username                              | account name           |
+| sign in                               | sign on, log in, login |
+| sign up, create account               | register               |
+| for example, such as                  | e.g.                   |
+| run                                   | execute                |
+| want                                  | wish                   |
+| Kubernetes                            | K8s                    |
+| repository                            | repo                   |
+| administrator (first use), admin (UI) | -                      |
+| and                                   | & (ampersand)          |
+| move through, navigate to             | scroll                 |
+| (be more precise)                     | respectively           |
+| versus                                | vs, vs.                |
+| use                                   | utilize                |
+| help                                  | facilitate             |
+
+Use "turn on" and "turn off" for UI toggles, switches, and settings a user
+flips in the interface. In general prose, "enable" and "disable" are
+acceptable when describing a feature or capability becoming available — for
+example, "When you enable auto-log-out, your users are logged out." Don't
+treat every "enable" or "disable" as a violation.
+
+### Version numbers
+
+- Use "earlier" not "lower": Docker Desktop 4.1 and earlier
+- Use "later" not "higher" or "above": Docker Desktop 4.1 and later
+
+### Quick transformations
+
+Common phrases to transform for clearer, more direct writing:
+
+| Instead of...            | Write...                     |
+| ------------------------ | ---------------------------- |
+| In order to build        | To build                     |
+| This allows you to build | This lets you build / Build  |
+| Simply run the command   | Run the command              |
+| We provide a feature     | Docker provides / You can    |
+| Utilize the API          | Use the API                  |
+| This facilitates testing | This helps test / This tests |
+| Click the button         | Select the button            |
+| It's worth noting that X | X (state it directly)        |
+
+### UI elements
+
+- **tab vs view** - Use "view" for major UI sections, "tab" for
+  sub-sections
+- **toggle** - You "turn on" or "turn off" a toggle
+
+## Docker terminology
+
+### Products and features
+
+- **Docker Compose** - The application or all functionality associated
+  with it
+- **`docker compose`** - Use code formatting for commands
+- **Docker Compose CLI** - The family of Compose commands from
+  Docker CLI
+- **Compose plugin** - The add-on for Docker CLI that can be
+  enabled/disabled
+- **compose.yaml** - Current designation for the Compose file (use
+  code formatting)
+
+### Technical terms
+
+- **Digest** - Long string automatically created when you push an
+  image
+- **Member** - A user of Docker Hub who is part of an organization
+- **Namespace** - Organization or user name; every image needs a
+  namespace
+- **Node** - Physical or virtual machine running Docker Engine in
+  swarm mode
+  - Manager nodes: Perform swarm management and orchestration
+  - Worker nodes: Execute tasks
+- **Registry** - Online storage for Docker images
+- **Repository** - Lets users share container images with team,
+  customers, or community
+
+### Platform terminology
+
+- **Multi-platform** - Broad: Mac/Linux/Windows; Narrow: Linux/amd64
+  and Linux/arm64
+- **Multi-architecture (multi-arch)** - CPU architecture or
+  hardware-architecture-based; don't use as synonym for multi-platform
+
+## Quick reference
+
+### Voice checklist
+
+- ✅ Direct and practical
+- ✅ Conversational with active voice
+- ✅ Specific and actionable
+- ✅ Lead with observable outcomes
+- ❌ Corporate-speak
+- ❌ Condescending
+- ❌ Overly formal
+
+### Structure checklist
+
+- ✅ Answer "What will I learn?" in the first paragraph
+- ✅ Answer "Why does this matter?" in the first paragraph
+- ✅ Front-load important information in headings and lists
+- ✅ Connect ideas naturally between sections
+- ✅ Use examples to clarify concepts
+- ✅ Match content type (tutorial vs how-to vs reference vs concept)
+- ✅ Follow code example pattern: state → show → explain
+- ✅ Preserve document scope (don't unnecessarily expand)
+
+### Common mistakes
+
+- ❌ Using "click" instead of "select"
+- ❌ Using "below" instead of "following"
+- ❌ Starting sentences with numbers (recast the sentence)
+- ❌ Using apostrophes in plural acronyms
+- ❌ Leaving table cells empty
+- ❌ Using commas in large numbers (use spaces)
+- ❌ Referring to file types by extension (.png file)
+- ❌ Using bold for product names or emphasis (only for UI elements)
+- ❌ Using "**Term** - Description" format in lists
+- ❌ Using hedge words (simply, easily, just, seamlessly)
+- ❌ Using meta-commentary (it's worth noting that...)
+- ❌ Using "we" instead of "you" or "Docker"
+- ❌ Showing command output when it's not needed
+- ❌ Not explaining what users will learn in first paragraph
diff --git a/_vale/.vale-config/0-Hugo.ini b/_vale/.vale-config/0-Hugo.ini
deleted file mode 100644
index 4347ca9e902a..000000000000
--- a/_vale/.vale-config/0-Hugo.ini
+++ /dev/null
@@ -1,10 +0,0 @@
-[*.md]
-# Exclude `{{< ... >}}`, `{{% ... %}}`, [Who]({{< ... >}})
-TokenIgnores = ({{[%<] .* [%>]}}.*?{{[%<] ?/.* [%>]}}), \
-(\[.+\]\({{< .+ >}}\)), \
-[^\S\r\n]({{[%<] \w+ .+ [%>]}})\s, \
-[^\S\r\n]({{[%<](?:/\*) .* (?:\*/)[%>]}})\s
-
-# Exclude `{{<  myshortcode `This is some <b>HTML</b>, ... >}}`
-BlockIgnores = (?sm)^({{[%<] \w+ [^{]*?\s[%>]}})\n$, \
-(?s) *({{< highlight [^>]* ?>}}.*?{{< ?/ ?highlight >}})
diff --git a/_vale/Docker/Acronyms.yml b/_vale/Docker/Acronyms.yml
deleted file mode 100644
index 476d8937d5b9..000000000000
--- a/_vale/Docker/Acronyms.yml
+++ /dev/null
@@ -1,164 +0,0 @@
-extends: conditional
-message: "'%s' has no definition."
-link: https://docs.docker.com/contribute/style/grammar/#acronyms-and-initialisms
-level: warning
-ignorecase: false
-# Ensures that the existence of 'first' implies the existence of 'second'.
-first: '\b([A-Z]{2,5})\b'
-second: '(?:\b[A-Z][a-z]+ )+\(([A-Z]{2,5})s?\)'
-# ... with the exception of these:
-exceptions:
-  - ACH
-  - AGPL
-  - AI
-  - API
-  - ARM
-  - ARP
-  - ASP
-  - AUFS
-  - AWS
-  - BIOS
-  - BPF
-  - BSD
-  - CFS
-  - CI
-  - CIDR
-  - CISA
-  - CLI
-  - CNCF
-  - CORS
-  - CPU
-  - CSS
-  - CSV
-  - CUDA
-  - CVE
-  - DAD
-  - DCT
-  - DEBUG
-  - DHCP
-  - DNS
-  - DOM
-  - DPI
-  - DSOS
-  - DVP
-  - ECI
-  - ELK
-  - FAQ
-  - FPM
-  - FUSE
-  - GB
-  - GCC
-  - GDB
-  - GET
-  - GHSA
-  - GNOME
-  - GNU
-  - GPG
-  - GPL
-  - GPU
-  - GRUB
-  - GTK
-  - GUI
-  - GUID
-  - HEAD
-  - HTML
-  - HTTP
-  - HTTPS
-  - IAM
-  - IBM
-  - ID
-  - IDE
-  - IP
-  - IPAM
-  - IPC
-  - IT
-  - JAR
-  - JIT
-  - JSON
-  - JSX
-  - KDE
-  - LESS
-  - LLDB
-  - LLM
-  - LTS
-  - MAC
-  - MATE
-  - MCP
-  - mcp
-  - MDM
-  - MDN
-  - MSI
-  - NAT
-  - NET
-  - NFS
-  - NOTE
-  - NTFS
-  - NTLM
-  - NUMA
-  - NVDA
-  - OCI
-  - OS
-  - OSI
-  - OSS
-  - PATH
-  - PDF
-  - PEM
-  - PID
-  - PHP
-  - POSIX
-  - POST
-  - QA
-  - QEMU
-  - RAM
-  - REPL
-  - REST
-  - RFC
-  - RHEL
-  - RPM
-  - RSA
-  - SAML
-  - SARIF
-  - SBOM
-  - SCIM
-  - SCM
-  - SCSS
-  - SCTP
-  - SDK
-  - SLES
-  - SLSA
-  - SOCKS
-  - SPDX
-  - SQL
-  - SSD
-  - SSH
-  - SSL
-  - SSO
-  - SVG
-  - TBD
-  - TCP
-  - TCP
-  - TIP
-  - TLS
-  - TODO
-  - TTY
-  - TXT
-  - UDP
-  - URI
-  - URL
-  - USB
-  - USD
-  - UTF
-  - UTS
-  - UUID
-  - VAT
-  - VDI
-  - VIP
-  - VLAN
-  - VM
-  - VPN
-  - WSL
-  - XML
-  - XSS
-  - YAML
-  - ZFS
-  - ZIP
diff --git a/_vale/Docker/Capitalization.yml b/_vale/Docker/Capitalization.yml
index 0b6ed0bb563e..ab22a9d32f13 100644
--- a/_vale/Docker/Capitalization.yml
+++ b/_vale/Docker/Capitalization.yml
@@ -7,4 +7,4 @@ action:
   params:
     - Docker
 tokens:
-  - '[^\[/]docker[^/]'
+  - '[^\[/\-.]docker[^/\-.\w]'
diff --git a/_vale/Docker/Exclamation.yml b/_vale/Docker/Exclamation.yml
index 6059a42870b1..53c606a3fc67 100644
--- a/_vale/Docker/Exclamation.yml
+++ b/_vale/Docker/Exclamation.yml
@@ -7,5 +7,10 @@ action:
   params:
     - trim_right
     - "!"
+# Product names that legitimately end in an exclamation point. List the
+# name without the trailing "!" — the exception is matched against the
+# word that precedes the exclamation point.
+exceptions:
+  - 'SDKMAN'
 tokens:
   - '\w+!(?:\s|$)'
diff --git a/_vale/Docker/Forbidden.yml b/_vale/Docker/Forbidden.yml
new file mode 100644
index 000000000000..d8b7a37ae8c9
--- /dev/null
+++ b/_vale/Docker/Forbidden.yml
@@ -0,0 +1,6 @@
+extends: substitution
+message: "Use '%s' instead of '%s'."
+level: error
+ignorecase: false
+swap:
+  Docker CE: Docker Engine
diff --git a/_vale/Docker/HeadingLength.yml b/_vale/Docker/HeadingLength.yml
deleted file mode 100644
index 270ccf80aed1..000000000000
--- a/_vale/Docker/HeadingLength.yml
+++ /dev/null
@@ -1,7 +0,0 @@
-extends: occurrence
-message: "Try to keep headings short (< 8 words)."
-link: https://docs.docker.com/contribute/style/formatting/#headings-and-subheadings
-scope: heading
-level: suggestion
-max: 8
-token: \b(\w+)\b
diff --git a/_vale/Docker/HeadingSentenceCase.yml b/_vale/Docker/HeadingSentenceCase.yml
deleted file mode 100644
index b5edebee1b24..000000000000
--- a/_vale/Docker/HeadingSentenceCase.yml
+++ /dev/null
@@ -1,8 +0,0 @@
-extends: capitalization
-message: "Use sentence case for headings: '%s'."
-level: warning
-scope: heading
-match: $sentence
-threshold: 0.4
-indicators:
-  - ":"
diff --git a/_vale/Docker/RecommendedWords.yml b/_vale/Docker/RecommendedWords.yml
index 2721e0881fb1..8a37d58f0e1f 100644
--- a/_vale/Docker/RecommendedWords.yml
+++ b/_vale/Docker/RecommendedWords.yml
@@ -10,14 +10,11 @@ swap:
   '\b(?:ie|i\.e\.)[\s,]': that is
   (?:account name|accountname|user name): username
   (?:drop down|dropdown): drop-down
-  (?:log out|logout): sign out
-  (?:sign on|log on|log in|logon|login): sign in
-  above: previous
+  \blog out\b: sign out
+  \b(?:sign on|log on|log in)\b: sign in
   adaptor: adapter
-  admin(?! console): administrator
   administrate: administer
   afterwards: afterward
-  allow: let
   allows: lets
   alphabetic: alphabetical
   alphanumerical: alphanumeric
@@ -27,7 +24,6 @@ swap:
   anti-virus: antivirus
   appendixes: appendices
   assembler: assembly
-  below: following
   check box: checkbox
   check boxes: checkboxes
   click: select
@@ -39,5 +35,5 @@ swap:
   repo: repository
   scroll: navigate
   url: URL
-  vs: versus
+  '\bvs\b(?!\.|\s+Code)': versus
   wish: want
diff --git a/_vale/Docker/SentenceLength.yml b/_vale/Docker/SentenceLength.yml
deleted file mode 100644
index 41bcdd12603f..000000000000
--- a/_vale/Docker/SentenceLength.yml
+++ /dev/null
@@ -1,7 +0,0 @@
-extends: occurrence
-message: "Write short, concise sentences. (<=40 words)"
-scope: sentence
-link: https://docs.docker.com/contribute/checklist/
-level: warning
-max: 40
-token: \b(\w+)\b
diff --git a/_vale/Docker/Units.yml b/_vale/Docker/Units.yml
index cc9134fe5456..4e67c1ac2799 100644
--- a/_vale/Docker/Units.yml
+++ b/_vale/Docker/Units.yml
@@ -3,8 +3,8 @@ message: "Use '%s' instead of '%s'"
 link: https://docs.docker.com/contribute/style/recommended-words/
 level: error
 swap:
-  (?:kilobytes?|KB): kB
+  kilobytes?: kB
   gigabytes?: GB
   megabytes?: MB
   petabytes?: PB
-  terrabytes?: TB
+  terabytes?: TB
diff --git a/_vale/Docker/VersionText.yml b/_vale/Docker/VersionText.yml
index 3210997efce1..37061de8da20 100644
--- a/_vale/Docker/VersionText.yml
+++ b/_vale/Docker/VersionText.yml
@@ -4,9 +4,9 @@ link: https://docs.docker.com/contribute/style/recommended-words/#later
 scope: raw
 raw:
   - '\bv?'
-  - '(?P<major>0|[1-9]\d*)\.?'
-  - '(?P<minor>0|[1-9]\d*)?\.?'
-  - '(?P<patch>0|[1-9]\d*)?'
+  - '(?P<major>0|[1-9]\d*)\.'
+  - '(?P<minor>0|[1-9]\d*)'
+  - '(?:\.(?P<patch>0|[1-9]\d*))?'
   - '(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?'
   - '(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?'
   - '\b (and|or) (higher|above)'
diff --git a/_vale/Docker/We.yml b/_vale/Docker/We.yml
index 331d477bea2e..bc94d6da743a 100644
--- a/_vale/Docker/We.yml
+++ b/_vale/Docker/We.yml
@@ -1,10 +1,11 @@
 extends: existence
 message: "Avoid using first-person plural like '%s'."
 level: warning
-ignorecase: true
+ignorecase: false
 tokens:
-  - we
-  - we'(?:ve|re)
-  - ours?
+  - '[Ww]e'
+  - "[Ww]e'(?:ve|re)"
+  - '[Oo]urs?'
   - us
-  - let's
+  - Us
+  - "[Ll]et's"
diff --git a/_vale/config/vocabularies/Docker/accept.txt b/_vale/config/vocabularies/Docker/accept.txt
index f2621ae38394..48cfd4c6fdd2 100644
--- a/_vale/config/vocabularies/Docker/accept.txt
+++ b/_vale/config/vocabularies/Docker/accept.txt
@@ -1,128 +1,311 @@
 (?i)[A-Z]{2,}'?s
+jq
+zstd
+Zstandard
+untracked
+ripgrep
+exfiltration
+sandboxing
+Adreno
+Aleksandrov
+Awaitility
 Amazon
 Anchore
+Ansible
 Apple
 Artifactory
+armhf
+[Aa]uditability
+auditable
+[Aa]utoconfiguration
+autolock
+[Aa]llowlist(ing)?
 Azure
+Azure AD
+[Bb]ackport
+[Bb]enchmarked
+bootup
+Bitnami
 Btrfs
+Bugsnag
 BuildKit
+buildkitd
 BusyBox
+cagent
+CD
 CentOS
 Ceph
+cgroup
 Chrome
 Chrome DevTools
+CI
+CI/CD
 Citrix
+classpath
+cli
+CLI
 CloudFront
+composable
 Codefresh
 Codespaces
-CouchDB
+config
+containerd
 Couchbase
+CouchDB
+CrowdStrike
+[Cc]ybersecurity
+datacenter
+datasource
 Datadog
+DBeaver
 Ddosify
 Debootstrap
+denylist
+deprovisioning
+deserialization
+deserialize[d]?
 Dev
-Dex
 Dev Environments?
+Dex
+displayName
 Django
+DMR
 Docker Build Cloud
 Docker Business
-Docker Dasboard
+Docker Dashboard
 Docker Desktop
 Docker Engine
 Docker Extension
 Docker Hub
 Docker Scout
 Docker Team
-Docker's
 Docker-Sponsored Open Source
+Docker's
 Dockerfile
+dockerignore
 Dockerize
+Dockerized
 Dockerizing
+Dependabot
+DuckDuckGo
+Dynatrace
 Entra
+EPERM
+ESXi
 Ethernet
+[Ee]xploitability
+[Ff]ailover
 Fargate
 Fedora
+Filebeat
+firewalld
 Flink
+Fluentd
+g?libc
 GeoNetwork
+GGUF
 Git
-GitHub( Actions)?
+Gitea
+GitHub
+GitHub Actions
 Google
+Gradle
 Grafana
 Gravatar
+gRPC
+Groq
+Grype
+Gunicorn
 HyperKit
-IPv[46]
-IPvlan
+inferencing
+initializer
+Initializr
+inotify
 Intel
 Intune
-JFrog
+IPsec
+iptables
+IPv[46]
+IPvlan
+isort
 Jamf
+JavaScript
 JetBrains
+JFrog
 JUnit
+Kata
+Keycloak
 Kerberos
+Kiro
 Kitematic
 Kubeadm
+kubectl
+kubefwd
+kubelet
 Kubernetes
-Laravel
 Laradock
+Laravel
+libseccomp
 Linux
+Liquibase
 LinuxKit
+logback
+Loggly
 Logstash
-Mac
+lookup
+macOS
+macvlan
 Mail(chimp|gun)
+mfsymlinks
+Micronaut
 Microsoft
+minikube
+misconfiguration
+[Mm]ixins?
+monorepos?
+musl
 MySQL
-NFSv\d
+nameserver
+namespaced?
+namespacing
+Neovim
+Npgsql
+netfilter
+netlabel
+netlink
 Netplan
+NFSv\d
 Nginx
+npm
+nvm
 Nutanix
 Nuxeo
+NVIDIA
 OAuth
+Okta
 Ollama
+osquery
+osxfs
 OTel
-Okta
-PKG
 Paketo
+PAT
+perl
+pgAdmin
+pgx
+PKG
+plaintext
+plist
+pluggable
 Postgres
+psycopg
+pytest
 PowerShell
 Python
+Qualcomm
+Quickview
+rebalance
+reimplement
+reloader
+repinning
+Rego
+Rekor
+ROCm
+rollback
+rootful
+rqt
+runc
+RViz
 Ryuk
 S3
-SQLite
+scrollable
+SELinux
 Slack
+snapshotters?
+Sigstore
 Snyk
 Solr
 SonarQube
+Sonoma
+Splunk
+SQLite
+stargz
+stdin
+stdout
+subfolder
+sudo
+[Ss]ubvolume
 Syft
+syntaxes
 Sysbox
+sysctl
+sysctls
 Sysdig
+systemd
+teleop
 Testcontainers
+tmpfs
 Traefik
+Trivy
 Trixie
+Turtlesim
+typesafe
 Ubuntu
+ufw
+uv
+umask
+[Uu]ncaptured
+unconfigured
+undeterminable
 Unix
+unmarshalling
+unmanaged
+upsert
+Visual Studio Code
 VMware
+VPNKit
+vSphere
+Vulkan
+Vue
 Wasm
+Wasmtime
 Windows
+windowsfilter
 WireMock
+workdir
+WORKDIR
+[Ww]orktrees?
+[Pp]assthrough
+[Pp]reconfigured
 Xdebug
+xUnit
+XQuartz
+youki
+Yubikey
 Zscaler
 Zsh
 [Aa]nonymized?
 [Aa]utobuild
 [Aa]llowlist
+[Aa]gentic
 [Aa]utobuilds?
 [Aa]utotests?
+[Aa]utoscaling
 [Bb]uildx
 [Bb]uildpack(s)?
 [Bb]uildx
 [Cc]odenames?
 [Cc]ompose
 [Cc]onfigs
+[dD]eduplicate
+[Dd]enylist
+[Dd]ev
+[Dd]iscoverability
 [Dd]istroless
 [Ff]ilepaths?
 [Ff]iletypes?
 [GgCc]oroutine
 [Hh]ealthcheck
+[Hh]eredoc
 [Hh]ostname
 [Ii]nfosec
 [Ii]nline
@@ -138,8 +321,11 @@ Zsh
 [Pp]rocfs
 [Pp]roxied
 [Pp]roxying
+[pP]yright
+README
 [Rr]eal-time
 [Rr]egex(es)?
+[Rr]uleset(s)?
 [Rr]untimes?
 [Ss]andbox(ed)?
 [Ss]eccomp
@@ -153,6 +339,9 @@ Zsh
 [Ss]warm
 [Ss]yscalls?
 [Ss]ysfs
+[Tt]eardown
+[Tt]echnographic
+[Tt]odo
 [Tt]oolchains?
 [Uu]narchived?
 [Uu]ngated
@@ -162,54 +351,100 @@ Zsh
 [Vv]irtiofs
 [Vv]irtualize
 [Ww]alkthrough
-bootup
-cgroup
-config
-containerd
-datacenter
-deprovisioning
-deserialization
-deserialize
-displayName
-dockerignore
-firewalld
-g?libc
-gRPC
-inotify
-iptables
-kubectl
-kubefwd
-kubelet
-lookup
-macOS
-macvlan
-mfsymlinks
-minikube
-monorepos?
-musl
-nameserver
-namespace
-namespacing
-netfilter
-netlabel
-npm
-osquery
-osxfs
-pgAdmin
-rollback
-rootful
-runc
-snapshotters?
-stdin
-stdout
-syntaxes
-sysctls
-systemd
-tmpfs
-ufw
-uid
-umask
-unmanaged
-vSphere
-vpnkit
-windowsfilter
+[Tt]oolsets?
+[Rr]eachability
+[Rr]erank(ing|ed)?
+[Ee]vals?
+[Ll]abspaces?
+[Uu]nsloth
+AppArmor
+[Aa]utolocking
+[Bb]oolean
+[Bb]reakpoint
+CMD
+[Dd]eno
+[Dd]evicemapper
+[Dd]ockerbot
+[Dd]ockerd
+docker_ce_version
+[Ee]nv
+ESLint
+gzip
+HAProxy
+[Ii]nlined
+journald
+JSON
+keypair
+Kustomize
+latest_engine_api_version
+[Mm]iddleware
+[Nn]onroot
+param
+[Pp]erformant
+Pinecone
+Qdrant
+[Rr]outable
+[Ss]emver
+setuid
+SHA
+spaCy
+src
+stderr
+Streamlit
+[Ss]ubcommand
+syslog
+TCP
+thinpool
+[Tt]runked
+UID
+[Uu]nencrypted
+[Uu]nmount
+URL
+VM
+Vite
+Vitest
+Wolfi
+[Aa]utoextend
+[Bb]ackoff
+[Bb]crypt
+[Bb]undler
+copy_up
+[Dd]eclaratively
+[Dd]eduplication
+dnf
+docker_gwbridge
+[Gg]lobbing
+GPG
+KVM
+[Mm]ulticast
+[Mm]isconfigured
+oldstable
+OpenSSL
+[Ss]tringified
+SwarmKit
+[Uu]ncomment
+bootloader
+Buildkite
+crypto
+Graylog
+Heartbleed
+Kubuntu
+Libnetwork
+lockfile
+Lubuntu
+multimodal
+multithreading
+Log4Shell
+NLP
+Nodemon
+oldoldstable
+parallelizable
+PHPUnit
+pnpm
+PyTorch
+Shellshock
+Spring4Shell
+superset
+tokenization
+WebGL
+Xubuntu
diff --git a/_vendor/github.com/docker/buildx/docs/bake-reference.md b/_vendor/github.com/docker/buildx/docs/bake-reference.md
index d658d891edd8..635fd96188a1 100644
--- a/_vendor/github.com/docker/buildx/docs/bake-reference.md
+++ b/_vendor/github.com/docker/buildx/docs/bake-reference.md
@@ -43,7 +43,7 @@ The following attributes are overridden by the last occurrence:
 - `target.cache-to`
 - `target.dockerfile-inline`
 - `target.dockerfile`
-- `target.outputs`
+- `target.output`
 - `target.platforms`
 - `target.pull`
 - `target.tags`
@@ -227,6 +227,8 @@ The following table shows the complete list of attributes that you can assign to
 | [`description`](#targetdescription)             | String  | Description of a target                                              |
 | [`dockerfile-inline`](#targetdockerfile-inline) | String  | Inline Dockerfile string                                             |
 | [`dockerfile`](#targetdockerfile)               | String  | Dockerfile location                                                  |
+| [`entitlements`](#targetentitlements)           | List    | Permissions that the build process requires to run                   |
+| [`extra-hosts`](#targetextra-hosts)             | List    | Customs host-to-IP mapping                                           |
 | [`inherits`](#targetinherits)                   | List    | Inherit attributes from other targets                                |
 | [`labels`](#targetlabels)                       | Map     | Metadata for images                                                  |
 | [`matrix`](#targetmatrix)                       | Map     | Define a set of variables that forks a target into multiple targets. |
@@ -234,8 +236,10 @@ The following table shows the complete list of attributes that you can assign to
 | [`no-cache-filter`](#targetno-cache-filter)     | List    | Disable build cache for specific stages                              |
 | [`no-cache`](#targetno-cache)                   | Boolean | Disable build cache completely                                       |
 | [`output`](#targetoutput)                       | List    | Output destinations                                                  |
+| [`policy`](#targetpolicy)                       | List    | Policies to validate build sources and metadata                      |
 | [`platforms`](#targetplatforms)                 | List    | Target platforms                                                     |
 | [`pull`](#targetpull)                           | Boolean | Always pull images                                                   |
+| [`resources`](#targetresources)                 | Map     | Resource limits for build containers                                 |
 | [`secret`](#targetsecret)                       | List    | Secrets to expose to the build                                       |
 | [`shm-size`](#targetshm-size)                   | List    | Size of `/dev/shm`                                                   |
 | [`ssh`](#targetssh)                             | List    | SSH agent sockets or keys to expose to the build                     |
@@ -297,7 +301,12 @@ example adds annotations to both the image index and manifests.
 
 ```hcl
 target "default" {
-  output = [{ type = "image", name = "foo" }]
+  output = [
+    {
+      type = "image"
+      name = "foo"
+    }
+  ]
   annotations = ["index,manifest:org.opencontainers.image.authors=dvdksn"]
 }
 ```
@@ -314,11 +323,11 @@ This attribute accepts the long-form CSV version of attestation parameters.
 target "default" {
   attest = [
     {
-      type = "provenance",
-      mode = "max",
+      type = "provenance"
+      mode = "max"
     },
     {
-      type = "sbom",
+      type = "sbom"
     }
   ]
 }
@@ -336,12 +345,12 @@ This takes a list value, so you can specify multiple cache sources.
 target "app" {
   cache-from = [
     {
-      type = "s3",
-      region = "eu-west-1",
+      type = "s3"
+      region = "eu-west-1"
       bucket = "mybucket"
     },
     {
-      type = "registry",
+      type = "registry"
       ref = "user/repo:cache"
     }
   ]
@@ -360,12 +369,12 @@ This takes a list value, so you can specify multiple cache export targets.
 target "app" {
   cache-to = [
     {
-      type = "s3",
-      region = "eu-west-1",
+      type = "s3"
+      region = "eu-west-1"
       bucket = "mybucket"
     },
     {
-      type = "inline",
+      type = "inline"
     }
   ]
 }
@@ -407,6 +416,11 @@ target "app" {
 ```
 
 This resolves to the current working directory (`"."`) by default.
+Set `BUILDX_BAKE_FILE_RELATIVE_PATHS=1` to resolve local directory paths in
+`target.context` and `target.contexts` relative to the Bake file that defines
+each path. Compose files use the first Compose file directory as the base, which
+matches Compose project directory semantics. Use `cwd://` for paths that should
+remain relative to the current working directory when this opt-in is enabled.
 
 ```console
 $ docker buildx bake --print -f - <<< 'target "default" {}'
@@ -445,9 +459,9 @@ a context based on the pattern of the context value.
 ```hcl
 # docker-bake.hcl
 target "app" {
-    contexts = {
-        alpine = "docker-image://alpine:3.13"
-    }
+  contexts = {
+    alpine = "docker-image://alpine:3.13"
+  }
 }
 ```
 
@@ -462,9 +476,9 @@ RUN echo "Hello world"
 ```hcl
 # docker-bake.hcl
 target "app" {
-    contexts = {
-        src = "../path/to/source"
-    }
+  contexts = {
+    src = "../path/to/source"
+  }
 }
 ```
 
@@ -485,12 +499,13 @@ COPY --from=src . .
 ```hcl
 # docker-bake.hcl
 target "base" {
-    dockerfile = "baseapp.Dockerfile"
+  dockerfile = "baseapp.Dockerfile"
 }
+
 target "app" {
-    contexts = {
-        baseapp = "target:base"
-    }
+  contexts = {
+    baseapp = "target:base"
+  }
 }
 ```
 
@@ -507,11 +522,11 @@ functionality.
 
 ```hcl
 target "lint" {
-    description = "Runs golangci-lint to detect style errors"
-    args = {
-        GOLANGCI_LINT_VERSION = null
-    }
-    dockerfile = "lint.Dockerfile"
+  description = "Runs golangci-lint to detect style errors"
+  args = {
+    GOLANGCI_LINT_VERSION = null
+  }
+  dockerfile = "lint.Dockerfile"
 }
 ```
 
@@ -577,6 +592,20 @@ target "integration-tests" {
 
 Entitlements are enabled with a two-step process. First, a target must declare the entitlements it requires. Secondly, when invoking the `bake` command, the user must grant the entitlements by passing the `--allow` flag or confirming the entitlements when prompted in an interactive terminal. This is to ensure that the user is aware of the possibly insecure permissions they are granting to the build process.
 
+### `target.extra-hosts`
+
+Use the `extra-hosts` attribute to define customs host-to-IP mapping for the
+target. This has the same effect as passing a [`--add-host`][add-host] flag to
+the build command.
+
+```hcl
+target "default" {
+  extra-hosts = {
+    my_hostname = "8.8.8.8"
+  }
+}
+```
+
 ### `target.inherits`
 
 A target can inherit attributes from other targets.
@@ -861,7 +890,7 @@ This is the same as the `--no-cache` flag for `docker build`.
 
 ```hcl
 target "default" {
-  no-cache = 1
+  no-cache = true
 }
 ```
 
@@ -877,6 +906,25 @@ target "default" {
 }
 ```
 
+> [!NOTE]
+> Local outputs with `mode=delete` require granting `--allow=buildx.local.delete`
+> when invoking `docker buildx bake`.
+
+### `target.policy`
+
+Policies to validate build sources and metadata. Each entry uses the same keys
+as the `--policy` flag for `docker buildx build` (`filename`, `reset`,
+`disabled`, `strict`, `log-level`). Bake also automatically loads
+`Dockerfile.rego` alongside the target Dockerfile when present.
+
+```hcl
+target "default" {
+  policy = [
+    { filename = "extra.rego" },
+  ]
+}
+```
+
 ### `target.platforms`
 
 Set target platforms for the build target.
@@ -901,6 +949,29 @@ target "default" {
 }
 ```
 
+### `target.resources`
+
+Sets cgroup resource limits for the containers that run `RUN` instructions
+during the build. The supported keys are `memory`, `memory-swap`, `cpu-shares`,
+`cpu-period`, `cpu-quota`, `cpuset-cpus`, and `cpuset-mems`. These map to the
+equivalent `docker build` flags and to the
+[`--resource`](https://docs.docker.com/reference/cli/docker/buildx/build/#resource)
+flag for `docker buildx build`.
+
+```hcl
+target "default" {
+  resources = {
+    memory      = "2g"
+    memory-swap = "4g"
+    cpu-quota   = 50000
+  }
+}
+```
+
+> [!NOTE]
+> These limits require a BuildKit daemon that supports per-step resource limits
+> and only take effect on Linux. They don't affect the build cache key.
+
 ### `target.secret`
 
 Defines secrets to expose to the build target.
@@ -913,8 +984,15 @@ variable "HOME" {
 
 target "default" {
   secret = [
-    { type = "env", id = "KUBECONFIG" },
-    { type = "file", id = "aws", src = "${HOME}/.aws/credentials" },
+    {
+      type = "env"
+      id = "KUBECONFIG"
+    },
+    {
+      type = "file"
+      id = "aws"
+      src = "${HOME}/.aws/credentials"
+    }
   ]
 }
 ```
@@ -928,6 +1006,14 @@ RUN --mount=type=secret,id=KUBECONFIG,env=KUBECONFIG \
     helm upgrade --install
 ```
 
+You can override the source for an existing secret without changing the target's
+secret IDs. The secret must already be declared by the target.
+
+```console
+$ docker buildx bake --set default.secret.aws=env=AWS_CREDENTIALS
+$ docker buildx bake --set default.secret.KUBECONFIG=src=/path/to/kubeconfig
+```
+
 ### `target.shm-size`
 
 Sets the size of the shared memory allocated for build containers when using
@@ -971,6 +1057,12 @@ RUN --mount=type=ssh \
     && git clone git@github.com:user/my-private-repo.git
 ```
 
+> [!NOTE]
+> When overriding `ssh` from the command line with `--set`, use the inline
+> `id=path` string form rather than the object form shown above, for example
+> `docker buildx bake --set "*.ssh=default=$HOME/.ssh/id_ed25519"`. Separate
+> multiple paths with commas. See [`bake --set`][set] for details.
+
 ### `target.tags`
 
 Image names and tags to use for the build target.
@@ -1068,7 +1160,9 @@ or interpolate them in attribute values in your Bake file.
 
 ```hcl
 variable "TAG" {
+  type = string
   default = "latest"
+  description = "Tag to use for build"
 }
 
 target "webapp-dev" {
@@ -1081,6 +1175,8 @@ You can assign a default value for a variable in the Bake file,
 or assign a `null` value to it. If you assign a `null` value,
 Buildx uses the default value from the Dockerfile instead.
 
+You can also add a description of the variable's purpose with the `description` field. This attribute is useful when combined with the `docker buildx bake --list=variables` option, providing a more informative output when listing the available variables in a Bake file.
+
 You can override variable defaults set in the Bake file using environment variables.
 The following example sets the `TAG` variable to `dev`,
 overriding the default `latest` value shown in the previous example.
@@ -1089,6 +1185,206 @@ overriding the default `latest` value shown in the previous example.
 $ TAG=dev docker buildx bake webapp-dev
 ```
 
+Variables can also be assigned an explicit type.
+If provided, it will be used to validate the default value (if set), as well as any overrides.
+This is particularly useful when using complex types which are intended to be overridden.
+The previous example could be expanded to apply an arbitrary series of tags.
+```hcl
+variable "TAGS" {
+  default = ["latest"]
+  type = list(string)
+}
+
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = [for tag in TAGS: "docker.io/username/webapp:${tag}"]
+}
+```
+
+This example shows how to generate three tags without changing the file
+or using custom functions/parsing:
+```console
+$ TAGS=dev,latest,2 docker buildx bake webapp-dev
+```
+
+### Variable typing
+
+The following primitive types are available:
+* `string`
+* `number`
+* `bool`
+
+The type is expressed like a keyword; it must be expressed as a literal:
+```hcl
+variable "OK" {
+  type = string
+}
+
+# cannot be an actual string
+variable "BAD" {
+  type = "string"
+}
+
+# cannot be the result of an expression
+variable "ALSO_BAD" {
+  type = lower("string")
+}
+```
+Specifying primitive types can be valuable to show intent (especially when a default is not provided),
+but bake will generally behave as expected without explicit typing.
+
+Complex types are expressed with "type constructors"; they are:
+* `tuple([<type>,...])`
+* `list(<type>)`
+* `set(<type>)`
+* `map(<type>)`
+* `object({<attr>=<type>},...})`
+
+The following are examples of each of those, as well as how the (optional) default value would be expressed:
+```hcl
+# structured way to express "1.2.3-alpha"
+variable "MY_VERSION" {
+  type = tuple([number, number, number, string])
+  default = [1, 2, 3, "alpha"]
+}
+
+# JDK versions used in a matrix build
+variable "JDK_VERSIONS" {
+  type = list(number)
+  default = [11, 17, 21]
+}
+
+# better way to express the previous example; this will also
+# enforce set semantics and allow use of set-based functions
+variable "JDK_VERSIONS" {
+  type = set(number)
+  default = [11, 17, 21]
+}
+
+# with the help of lookup(), translate a 'feature' to a tag
+variable "FEATURE_TO_NAME" {
+  type = map(string)
+  default = {featureA = "slim", featureB = "tiny"}
+}
+
+# map a branch name to a registry location
+variable "PUSH_DESTINATION" {
+  type = object({branch = string, registry = string})
+  default = {branch = "main", registry = "prod-registry.invalid.com"}
+}
+
+# make the previous example more useful with composition
+variable "PUSH_DESTINATIONS" {
+  type = list(object({branch = string, registry = string}))
+  default = [
+    {branch = "develop", registry = "test-registry.invalid.com"},
+    {branch = "main", registry = "prod-registry.invalid.com"},
+  ]
+}
+```
+Note that in each example, the default value would be valid even if typing was not present.
+If typing was omitted, the first three would all be considered `tuple`;
+you would be restricted to functions that operate on `tuple` and, for example, not be able to add elements.
+Similarly, the third and fourth would both be considered `object`, with the limits and semantics of that type.
+In short, in the absence of a type, any value delimited with `[]` is a `tuple`
+and value delimited with `{}` is an `object`.
+Explicit typing for complex types not only opens up the ability to use functions applicable to that specialized type,
+but is also a precondition for providing overrides.
+
+> [!NOTE]
+> See [HCL Type Expressions][typeexpr] page for more details.
+
+### Overriding variables
+
+As mentioned in the [intro to variables](#variable), primitive types (`string`, `number`, and `bool`)
+can be overridden without typing and will generally behave as expected.
+(When explicit typing is not provided, a variable is assumed to be primitive when the default value lacks `{}` or `[]` delimiters;
+a variable with neither typing nor a default value is treated as `string`.)
+Naturally, these same overrides can be used alongside explicit typing too;
+they may help in edge cases where you want `VAR=true` to be a `string`, where without typing,
+it may be a `string` or a `bool` depending on how/where it's used.
+Overriding a variable with a complex type can only be done when the type is provided.
+This is still done via environment variables, but the values can be provided via CSV or JSON.
+
+#### CSV overrides
+
+This is considered the canonical method and is well suited to interactive usage.
+It is assumed that `list` and `set` will be the most common complex type,
+as well as the most common complex type designed to be overridden.
+Thus, there is full CSV support for `list` and `set`
+(and `tuple`; despite being considered a structural type, it is more like a collection type in this regard).
+
+
+There is limited support for `map` and `object` and no support for composite types;
+for these advanced cases, an alternative mechanism [using JSON](#json-overrides) is available.
+
+#### JSON overrides
+
+Overrides can also be provided via JSON.
+This is the only method available for providing some complex types and may be convenient if overrides are already JSON
+(for example, if they come from a JSON API).
+It can also be used when dealing with values are difficult or impossible to specify using CSV (e.g., values containing quotes or commas).
+To use JSON, simply append `_JSON` to the variable name.
+In this contrived example, CSV cannot handle the second value; despite being a supported CSV type, JSON must be used:
+```hcl
+variable "VALS" {
+  type = list(string)
+  default = ["some", "list"]
+}
+```
+```console
+$ cat data.json
+["hello","with,comma","with\"quote"]
+$ VALS_JSON=$(< data.json) docker buildx bake
+
+# CSV equivalent, though the second value cannot be expressed at all 
+$ VALS='hello,"with""quote"' docker buildx bake
+```
+
+This example illustrates some precedence and usage rules:
+```hcl
+variable "FOO" {
+  type = string
+  default = "foo"
+}
+
+variable "FOO_JSON" {
+  type = string
+  default = "foo"
+}
+```
+
+The variable `FOO` can *only* be overridden using CSV because `FOO_JSON`, which would typically used for a JSON override,
+is already a defined variable.
+Since `FOO_JSON` is an actual variable, setting that environment variable would be expected to a CSV value.
+A JSON override *is* possible for this variable, using environment variable `FOO_JSON_JSON`.
+
+```Console
+# These three are all equivalent, setting variable FOO=bar
+$ FOO=bar docker buildx bake <...>
+$ FOO='bar' docker buildx bake <...>
+$ FOO="bar" docker buildx bake <...>
+
+# Sets *only* variable FOO_JSON; FOO is untouched
+$ FOO_JSON=bar docker buildx bake <...>
+
+# This also sets FOO_JSON, but will fail due to not being valid JSON
+$ FOO_JSON_JSON=bar docker buildx bake <...>
+
+# These are all equivalent
+$ cat data.json
+"bar"
+$ FOO_JSON_JSON=$(< data.json) docker buildx bake <...>
+$ FOO_JSON_JSON='"bar"' docker buildx bake <...>
+$ FOO_JSON=bar docker buildx bake <...>
+
+# This results in setting two different variables, both specified as CSV (FOO=bar and FOO_JSON="baz")
+$ FOO=bar FOO_JSON='"baz"' docker buildx bake <...>
+
+# These refer to the same variable with FOO_JSON_JSON having precedence and read as JSON (FOO_JSON=baz)
+$ FOO_JSON=bar FOO_JSON_JSON='"baz"' docker buildx bake <...>
+```
+
 ### Built-in variables
 
 The following variables are built-ins that you can use with Bake without having
@@ -1101,11 +1397,17 @@ to define them.
 
 ### Use environment variable as default
 
-You can set a Bake variable to use the value of an environment variable as a default value:
+If an environment variable exists with the same name as a declared Bake
+variable, Bake uses that environment variable value instead of the declared
+default.
+
+To disable this environment-based variable lookup, set
+`BUILDX_BAKE_DISABLE_VARS_ENV_LOOKUP=1`.
+
 
 ```hcl
 variable "HOME" {
-  default = "$HOME"
+  default = "/root"
 }
 ```
 
@@ -1169,8 +1471,7 @@ $ docker buildx bake
 
 ## Function
 
-A [set of general-purpose functions][bake_stdlib]
-provided by [go-cty][go-cty]
+A [set of general-purpose functions][bake_stdlib] provided by [go-cty][go-cty]
 are available for use in HCL files:
 
 ```hcl
@@ -1208,8 +1509,9 @@ target "webapp-dev" {
 
 <!-- external links -->
 
+[add-host]: https://docs.docker.com/reference/cli/docker/buildx/build/#add-host
 [attestations]: https://docs.docker.com/build/attestations/
-[bake_stdlib]: https://github.com/docker/buildx/blob/master/bake/hclparser/stdlib.go
+[bake_stdlib]: https://github.com/docker/buildx/blob/master/docs/bake-stdlib.md
 [build-arg]: https://docs.docker.com/reference/cli/docker/image/build/#build-arg
 [build-context]: https://docs.docker.com/reference/cli/docker/buildx/build/#build-context
 [cache-backends]: https://docs.docker.com/build/cache/backends/
@@ -1223,7 +1525,9 @@ target "webapp-dev" {
 [platform]: https://docs.docker.com/reference/cli/docker/buildx/build/#platform
 [run_mount_secret]: https://docs.docker.com/reference/dockerfile/#run---mounttypesecret
 [secret]: https://docs.docker.com/reference/cli/docker/buildx/build/#secret
+[set]: https://docs.docker.com/reference/cli/docker/buildx/bake/#set
 [ssh]: https://docs.docker.com/reference/cli/docker/buildx/build/#ssh
 [tag]: https://docs.docker.com/reference/cli/docker/image/build/#tag
 [target]: https://docs.docker.com/reference/cli/docker/image/build/#target
+[typeexpr]: https://github.com/hashicorp/hcl/tree/main/ext/typeexpr
 [userfunc]: https://github.com/hashicorp/hcl/tree/main/ext/userfunc
diff --git a/_vendor/github.com/docker/buildx/docs/bake-stdlib.md b/_vendor/github.com/docker/buildx/docs/bake-stdlib.md
new file mode 100644
index 000000000000..569b072bd305
--- /dev/null
+++ b/_vendor/github.com/docker/buildx/docs/bake-stdlib.md
@@ -0,0 +1,1554 @@
+---
+title: Bake standard library functions
+---
+
+<!---MARKER_STDLIB_START-->
+
+| Name                                                | Description                                                                                                                                                                                                                                          |
+|:----------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| [`absolute`](#absolute)                             | If the given number is negative then returns its positive equivalent, or otherwise returns the given number unchanged.                                                                                                                               |
+| [`add`](#add)                                       | Returns the sum of the two given numbers.                                                                                                                                                                                                            |
+| [`and`](#and)                                       | Applies the logical AND operation to the given boolean values.                                                                                                                                                                                       |
+| [`base64decode`](#base64decode)                     | Decodes a string containing a base64 sequence.                                                                                                                                                                                                       |
+| [`base64encode`](#base64encode)                     | Encodes a string to a base64 sequence.                                                                                                                                                                                                               |
+| [`basename`](#basename)                             | Returns the last element of a path.                                                                                                                                                                                                                  |
+| [`bcrypt`](#bcrypt)                                 | Computes a hash of the given string using the Blowfish cipher.                                                                                                                                                                                       |
+| [`byteslen`](#byteslen)                             | Returns the total number of bytes in the given buffer.                                                                                                                                                                                               |
+| [`bytesslice`](#bytesslice)                         | Extracts a subslice from the given buffer.                                                                                                                                                                                                           |
+| [`can`](#can)                                       | Tries to evaluate the expression given in its first argument.                                                                                                                                                                                        |
+| [`ceil`](#ceil)                                     | Returns the smallest whole number that is greater than or equal to the given value.                                                                                                                                                                  |
+| [`chomp`](#chomp)                                   | Removes one or more newline characters from the end of the given string.                                                                                                                                                                             |
+| [`chunklist`](#chunklist)                           | Splits a single list into multiple lists where each has at most the given number of elements.                                                                                                                                                        |
+| [`cidrhost`](#cidrhost)                             | Calculates a full host IP address within a given IP network address prefix.                                                                                                                                                                          |
+| [`cidrnetmask`](#cidrnetmask)                       | Converts an IPv4 address prefix given in CIDR notation into a subnet mask address.                                                                                                                                                                   |
+| [`cidrsubnet`](#cidrsubnet)                         | Calculates a subnet address within a given IP network address prefix.                                                                                                                                                                                |
+| [`cidrsubnets`](#cidrsubnets)                       | Calculates many consecutive subnet addresses at once, rather than just a single subnet extension.                                                                                                                                                    |
+| [`coalesce`](#coalesce)                             | Returns the first of the given arguments that isn't null, or raises an error if there are no non-null arguments.                                                                                                                                     |
+| [`coalescelist`](#coalescelist)                     | Returns the first of the given sequences that has a length greater than zero.                                                                                                                                                                        |
+| [`compact`](#compact)                               | Removes all empty string elements from the given list of strings.                                                                                                                                                                                    |
+| [`concat`](#concat)                                 | Concatenates together all of the given lists or tuples into a single sequence, preserving the input order.                                                                                                                                           |
+| [`contains`](#contains)                             | Returns true if the given value is a value in the given list, tuple, or set, or false otherwise.                                                                                                                                                     |
+| [`convert`](#convert)                               | Converts a value to a specified type constraint, using HCL's customdecode extension for type expression support.                                                                                                                                     |
+| [`csvdecode`](#csvdecode)                           | Parses the given string as Comma Separated Values (as defined by RFC 4180) and returns a map of objects representing the table of data, using the first row as a header row to define the object attributes.                                         |
+| [`dirname`](#dirname)                               | Returns the directory of a path.                                                                                                                                                                                                                     |
+| [`distinct`](#distinct)                             | Removes any duplicate values from the given list, preserving the order of remaining elements.                                                                                                                                                        |
+| [`divide`](#divide)                                 | Divides the first given number by the second.                                                                                                                                                                                                        |
+| [`element`](#element)                               | Returns the element with the given index from the given list or tuple, applying the modulo operation to the given index if it's greater than the number of elements.                                                                                 |
+| [`equal`](#equal)                                   | Returns true if the two given values are equal, or false otherwise.                                                                                                                                                                                  |
+| [`flatten`](#flatten)                               | Transforms a list, set, or tuple value into a tuple by replacing any given elements that are themselves sequences with a flattened tuple of all of the nested elements concatenated together.                                                        |
+| [`floor`](#floor)                                   | Returns the greatest whole number that is less than or equal to the given value.                                                                                                                                                                     |
+| [`format`](#format)                                 | Constructs a string by applying formatting verbs to a series of arguments, using a similar syntax to the C function \"printf\".                                                                                                                      |
+| [`formatdate`](#formatdate)                         | Deprecated: use formattimestamp instead. Formats a timestamp given in RFC 3339 syntax into another timestamp in some other machine-oriented time syntax, as described in the format string.                                                          |
+| [`formatlist`](#formatlist)                         | Constructs a list of strings by applying formatting verbs to a series of arguments, using a similar syntax to the C function \"printf\".                                                                                                             |
+| [`formattimestamp`](#formattimestamp)               | Formats a timestamp string in RFC 3339 syntax or a unix timestamp integer into another timestamp in some other machine-oriented time syntax, as described in the format string. The special format string "X" returns the unix timestamp in seconds. |
+| [`greaterthan`](#greaterthan)                       | Returns true if and only if the second number is greater than the first.                                                                                                                                                                             |
+| [`greaterthanorequalto`](#greaterthanorequalto)     | Returns true if and only if the second number is greater than or equal to the first.                                                                                                                                                                 |
+| [`hasindex`](#hasindex)                             | Returns true if if the given collection can be indexed with the given key without producing an error, or false otherwise.                                                                                                                            |
+| [`homedir`](#homedir)                               | Returns the current user's home directory.                                                                                                                                                                                                           |
+| [`indent`](#indent)                                 | Adds a given number of spaces after each newline character in the given string.                                                                                                                                                                      |
+| [`index`](#index)                                   | Returns the element with the given key from the given collection, or raises an error if there is no such element.                                                                                                                                    |
+| [`indexof`](#indexof)                               | Finds the element index for a given value in a list.                                                                                                                                                                                                 |
+| [`int`](#int)                                       | Discards any fractional portion of the given number.                                                                                                                                                                                                 |
+| [`join`](#join)                                     | Concatenates together the elements of all given lists with a delimiter, producing a single string.                                                                                                                                                   |
+| [`jsondecode`](#jsondecode)                         | Parses the given string as JSON and returns a value corresponding to what the JSON document describes.                                                                                                                                               |
+| [`jsonencode`](#jsonencode)                         | Returns a string containing a JSON representation of the given value.                                                                                                                                                                                |
+| [`keys`](#keys)                                     | Returns a list of the keys of the given map in lexicographical order.                                                                                                                                                                                |
+| [`length`](#length)                                 | Returns the number of elements in the given collection.                                                                                                                                                                                              |
+| [`lessthan`](#lessthan)                             | Returns true if and only if the second number is less than the first.                                                                                                                                                                                |
+| [`lessthanorequalto`](#lessthanorequalto)           | Returns true if and only if the second number is less than or equal to the first.                                                                                                                                                                    |
+| [`log`](#log)                                       | Returns the logarithm of the given number in the given base.                                                                                                                                                                                         |
+| [`lookup`](#lookup)                                 | Returns the value of the element with the given key from the given map, or returns the default value if there is no such element.                                                                                                                    |
+| [`lower`](#lower)                                   | Returns the given string with all Unicode letters translated to their lowercase equivalents.                                                                                                                                                         |
+| [`max`](#max)                                       | Returns the numerically greatest of all of the given numbers.                                                                                                                                                                                        |
+| [`md5`](#md5)                                       | Computes the MD5 hash of a given string and encodes it with hexadecimal digits.                                                                                                                                                                      |
+| [`merge`](#merge)                                   | Merges all of the elements from the given maps into a single map, or the attributes from given objects into a single object.                                                                                                                         |
+| [`min`](#min)                                       | Returns the numerically smallest of all of the given numbers.                                                                                                                                                                                        |
+| [`modulo`](#modulo)                                 | Divides the first given number by the second and then returns the remainder.                                                                                                                                                                         |
+| [`multiply`](#multiply)                             | Returns the product of the two given numbers.                                                                                                                                                                                                        |
+| [`negate`](#negate)                                 | Multiplies the given number by -1.                                                                                                                                                                                                                   |
+| [`not`](#not)                                       | Applies the logical NOT operation to the given boolean value.                                                                                                                                                                                        |
+| [`notequal`](#notequal)                             | Returns false if the two given values are equal, or true otherwise.                                                                                                                                                                                  |
+| [`or`](#or)                                         | Applies the logical OR operation to the given boolean values.                                                                                                                                                                                        |
+| [`parseint`](#parseint)                             | Parses the given string as a number of the given base, or raises an error if the string contains invalid characters.                                                                                                                                 |
+| [`pow`](#pow)                                       | Returns the given number raised to the given power (exponentiation).                                                                                                                                                                                 |
+| [`range`](#range)                                   | Returns a list of numbers spread evenly over a particular range.                                                                                                                                                                                     |
+| [`regex`](#regex)                                   | Applies the given regular expression pattern to the given string and returns information about a single match, or raises an error if there is no match.                                                                                              |
+| [`regex_replace`](#regex_replace)                   | Applies the given regular expression pattern to the given string and replaces all matches with the given replacement string.                                                                                                                         |
+| [`regexall`](#regexall)                             | Applies the given regular expression pattern to the given string and returns a list of information about all non-overlapping matches, or an empty list if there are no matches.                                                                      |
+| [`replace`](#replace)                               | Replaces all instances of the given substring in the given string with the given replacement string.                                                                                                                                                 |
+| [`reverse`](#reverse)                               | Returns the given string with all of its Unicode characters in reverse order.                                                                                                                                                                        |
+| [`reverselist`](#reverselist)                       | Returns the given list with its elements in reverse order.                                                                                                                                                                                           |
+| [`rsadecrypt`](#rsadecrypt)                         | Decrypts an RSA-encrypted ciphertext.                                                                                                                                                                                                                |
+| [`sanitize`](#sanitize)                             | Replaces all non-alphanumeric characters with a underscore, leaving only characters that are valid for a Bake target name.                                                                                                                           |
+| [`semvercmp`](#semvercmp)                           | Returns true if version satisfies a constraint.                                                                                                                                                                                                      |
+| [`sethaselement`](#sethaselement)                   | Returns true if the given set contains the given element, or false otherwise.                                                                                                                                                                        |
+| [`setintersection`](#setintersection)               | Returns the intersection of all given sets.                                                                                                                                                                                                          |
+| [`setproduct`](#setproduct)                         | Calculates the cartesian product of two or more sets.                                                                                                                                                                                                |
+| [`setsubtract`](#setsubtract)                       | Returns the relative complement of the two given sets.                                                                                                                                                                                               |
+| [`setsymmetricdifference`](#setsymmetricdifference) | Returns the symmetric difference of the two given sets.                                                                                                                                                                                              |
+| [`setunion`](#setunion)                             | Returns the union of all given sets.                                                                                                                                                                                                                 |
+| [`sha1`](#sha1)                                     | Computes the SHA1 hash of a given string and encodes it with hexadecimal digits.                                                                                                                                                                     |
+| [`sha256`](#sha256)                                 | Computes the SHA256 hash of a given string and encodes it with hexadecimal digits.                                                                                                                                                                   |
+| [`sha512`](#sha512)                                 | Computes the SHA512 hash of a given string and encodes it with hexadecimal digits.                                                                                                                                                                   |
+| [`signum`](#signum)                                 | Returns 0 if the given number is zero, 1 if the given number is positive, or -1 if the given number is negative.                                                                                                                                     |
+| [`slice`](#slice)                                   | Extracts a subslice of the given list or tuple value.                                                                                                                                                                                                |
+| [`sort`](#sort)                                     | Applies a lexicographic sort to the elements of the given list.                                                                                                                                                                                      |
+| [`split`](#split)                                   | Produces a list of one or more strings by splitting the given string at all instances of a given separator substring.                                                                                                                                |
+| [`strlen`](#strlen)                                 | Returns the number of Unicode characters (technically: grapheme clusters) in the given string.                                                                                                                                                       |
+| [`substr`](#substr)                                 | Extracts a substring from the given string.                                                                                                                                                                                                          |
+| [`subtract`](#subtract)                             | Returns the difference between the two given numbers.                                                                                                                                                                                                |
+| [`timeadd`](#timeadd)                               | Adds the duration represented by the given duration string to the given RFC 3339 timestamp string, returning another RFC 3339 timestamp.                                                                                                             |
+| [`timestamp`](#timestamp)                           | Returns a string representation of the current date and time.                                                                                                                                                                                        |
+| [`title`](#title)                                   | Replaces one letter after each non-letter and non-digit character with its uppercase equivalent.                                                                                                                                                     |
+| [`trim`](#trim)                                     | Removes consecutive sequences of characters in "cutset" from the start and end of the given string.                                                                                                                                                  |
+| [`trimprefix`](#trimprefix)                         | Removes the given prefix from the start of the given string, if present.                                                                                                                                                                             |
+| [`trimspace`](#trimspace)                           | Removes any consecutive space characters (as defined by Unicode) from the start and end of the given string.                                                                                                                                         |
+| [`trimsuffix`](#trimsuffix)                         | Removes the given suffix from the start of the given string, if present.                                                                                                                                                                             |
+| [`try`](#try)                                       | Variadic function that tries to evaluate all of is arguments in sequence until one succeeds, in which case it returns that result, or returns an error if none of them succeed.                                                                      |
+| [`unixtimestampparse`](#unixtimestampparse)         | Given a unix timestamp integer, will parse and return an object representation of that date and time. A unix timestamp is the number of seconds elapsed since January 1, 1970 UTC.                                                                   |
+| [`upper`](#upper)                                   | Returns the given string with all Unicode letters translated to their uppercase equivalents.                                                                                                                                                         |
+| [`urlencode`](#urlencode)                           | Applies URL encoding to a given string.                                                                                                                                                                                                              |
+| [`uuidv4`](#uuidv4)                                 | Generates and returns a Type-4 UUID in the standard hexadecimal string format.                                                                                                                                                                       |
+| [`uuidv5`](#uuidv5)                                 | Generates and returns a Type-5 UUID in the standard hexadecimal string format.                                                                                                                                                                       |
+| [`values`](#values)                                 | Returns the values of elements of a given map, or the values of attributes of a given object, in lexicographic order by key or attribute name.                                                                                                       |
+| [`zipmap`](#zipmap)                                 | Constructs a map from a list of keys and a corresponding list of values, which must both be of the same length.                                                                                                                                      |
+
+
+<!---MARKER_STDLIB_END-->
+
+## `absolute`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    val = "${absolute(-42)}" # => 42
+  }
+}
+```
+
+## `add`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${add(123, 1)}" # => 124
+  }
+}
+```
+
+## `and`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${and(true, false)}" # => false
+  }
+}
+```
+
+## `base64decode`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    decoded = "${base64decode("SGVsbG8=")}" # => "Hello"
+  }
+}
+```
+
+## `base64encode`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    encoded = "${base64encode("Hello")}" # => "SGVsbG8="
+  }
+}
+```
+
+## `basename`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    file = "${basename("/usr/local/bin/docker")}" # => "docker"
+  }
+}
+```
+
+## `bcrypt`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    hash = "${bcrypt("mypassword")}" # => "$2a$10$..."
+  }
+}
+```
+
+## `byteslen`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    length = "${byteslen("Docker")}" # => 6
+  }
+}
+```
+
+## `bytesslice`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    part = "${bytesslice("Docker", 0, 3)}" # => "Doc"
+  }
+}
+```
+
+## `can`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    safe = "${can(parseint("123", 10))}" # => true
+  }
+}
+```
+
+## `ceil`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    rounded = "${ceil(3.14)}" # => 4"
+  }
+}
+```
+
+## `chomp`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${chomp("Hello\n\n")}" # => "Hello"
+  }
+}
+```
+
+## `chunklist`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${chunklist([1,2,3,4,5], 2)}"     # => [[1,2],[3,4],[5]]
+  }
+}
+```
+
+## `cidrhost`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${cidrhost("10.0.0.0/16", 5)}"   # => "10.0.0.5"
+  }
+}
+```
+
+## `cidrnetmask`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    mask = "${cidrnetmask("10.0.0.0/16")}"     # => "255.255.0.0"
+  }
+}
+```
+
+## `cidrsubnet`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    subnet = "${cidrsubnet("10.0.0.0/16", 4, 2)}" # => "10.0.32.0/20"
+  }
+}
+```
+
+## `cidrsubnets`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    subs = "${cidrsubnets("10.0.0.0/16", 4, 4)}" # => ["10.0.0.0/20","10.0.16.0/20",...]
+  }
+}
+```
+
+## `coalesce`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    first = "${coalesce(null, "", "docker")}"  # => "docker"
+  }
+}
+```
+
+## `coalescelist`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    first = "${coalescelist([], [1,2], [3])}" # => [1,2]
+  }
+}
+```
+
+## `compact`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    list = "${compact(["a", "", "b", ""])}" # => ["a","b"]
+  }
+}
+```
+
+## `concat`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    list = "${concat([1,2],[3,4])}" # => [1,2,3,4]
+  }
+}
+```
+
+## `contains`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    check = "${contains([1,2,3], 2)}" # => true
+  }
+}
+```
+
+## `convert`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${convert("42", number)}" # => 42
+  }
+}
+```
+
+## `csvdecode`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    data = "${csvdecode("name,age\nAlice,30\nBob,40")}" # => [{"name":"Alice","age":"30"},{"name":"Bob","age":"40"}]
+  }
+}
+```
+
+## `dirname`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    dir = "${dirname("/usr/local/bin/docker")}" # => "/usr/local/bin"
+  }
+}
+```
+
+## `distinct`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${distinct([1,2,2,3,3,3])}" # => [1,2,3]
+  }
+}
+```
+
+## `divide`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${divide(10, 2)}" # => 5
+  }
+}
+```
+
+## `element`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    val = "${element(["a","b","c"], 1)}" # => "b"
+  }
+}
+```
+
+## `equal`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    check = "${equal(2, 2)}" # => true
+  }
+}
+```
+
+## `flatten`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    flat = "${flatten([[1,2],[3,4],[5]])}" # => [1,2,3,4,5]
+  }
+}
+```
+
+## `floor`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${floor(3.99)}" # => 3
+  }
+}
+```
+
+## `format`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${format("Hello, %s!", "World")}" # => "Hello, World!"
+  }
+}
+```
+
+## `formatdate`
+
+> [!WARNING]
+> Deprecated: use `formattimestamp` instead. `formatdate` only accepts RFC3339
+> timestamp strings.
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    date = "${formatdate("YYYY-MM-DD", "2025-09-16T12:00:00Z")}" # => "2025-09-16"
+  }
+}
+```
+
+## `formattimestamp`
+
+Formats either an RFC3339 timestamp string or a unix timestamp integer.
+The special format `X` returns the unix timestamp in seconds.
+
+```hcl
+# docker-bake.hcl
+variable "SOURCE_DATE_EPOCH" {
+  type    = number
+  default = formattimestamp("X", "2015-10-21T00:00:00Z") # => 1445385600
+}
+
+target "default" {
+  dockerfile = "Dockerfile"
+  labels = {
+    "org.opencontainers.image.created" = formattimestamp("YYYY-MM-DD'T'hh:mm:ssZ", SOURCE_DATE_EPOCH) # => "2015-10-21T00:00:00Z"
+  }
+  args = {
+    build_date = formattimestamp("YYYY-MM-DD", "2025-09-16T12:00:00Z") # => "2025-09-16"
+  }
+}
+```
+
+## `formatlist`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    list = "${formatlist("Hi %s", ["Alice", "Bob"])}" # => ["Hi Alice","Hi Bob"]
+  }
+}
+```
+
+## `greaterthan`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${greaterthan(2, 5)}" # => true
+  }
+}
+```
+
+## `greaterthanorequalto`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${greaterthanorequalto(5, 5)}" # => true
+  }
+}
+```
+
+## `hasindex`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    exists = "${hasindex([10, 20, 30], 1)}"  # => true
+    missing = "${hasindex([10, 20, 30], 5)}" # => false
+  }
+}
+```
+
+## `homedir`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    home = "${homedir()}" # => e.g., "/home/user"
+  }
+}
+```
+
+## `indent`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    text = "${indent(4, "Hello\nWorld")}" 
+    # => "    Hello\n    World"
+  }
+}
+```
+
+## `index`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    val = "${index({foo = "bar", baz = "qux"}, "baz")}" # => "qux"
+  }
+}
+```
+
+## `indexof`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    pos = "${indexof(["a","b","c"], "b")}" # => 1
+  }
+}
+```
+
+## `int`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    number = "${int(3.75)}" # => 3
+  }
+}
+```
+
+## `join`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    csv = "${join(",", ["a","b","c"])}" # => "a,b,c"
+  }
+}
+```
+
+## `jsondecode`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    obj = "${jsondecode("{\"name\":\"Docker\",\"stars\":5}")}" # => {"name":"Docker","stars":5}
+  }
+}
+```
+
+## `jsonencode`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    str = "${jsonencode({name="Docker", stars=5})}" # => "{\"name\":\"Docker\",\"stars\":5}"
+  }
+}
+```
+
+## `keys`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    list = "${keys({foo = 1, bar = 2, baz = 3})}" 
+    # => ["bar","baz","foo"] (sorted order)
+  }
+}
+```
+
+## `length`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    size = "${length([1,2,3,4])}" # => 4
+  }
+}
+```
+
+## `lessthan`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${lessthan(10, 3)}" # => false
+  }
+}
+```
+
+## `lessthanorequalto`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${lessthanorequalto(5, 7)}" # => true
+  }
+}
+```
+
+## `log`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    val = "${log(100, 10)}" # => 2
+  }
+}
+```
+
+## `lookup`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    found    = "${lookup({a="apple", b="banana"}, "a", "none")}" # => "apple"
+    fallback = "${lookup({a="apple", b="banana"}, "c", "none")}" # => "none"
+  }
+}
+```
+## `lower`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    val = "${lower("HELLO")}" # => "hello"
+  }
+}
+```
+
+## `max`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${max(3, 9, 7)}" # => 9
+  }
+}
+```
+
+## `md5`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    hash = "${md5("docker")}" # => "597dd5f6a..." (hex string)
+  }
+}
+```
+
+## `merge`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    combined = "${merge({a=1, b=2}, {b=3, c=4})}" # => {a=1, b=3, c=4}
+  }
+}
+```
+
+## `min`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${min(3, 9, 7)}" # => 3
+  }
+}
+```
+
+## `modulo`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${modulo(10, 3)}" # => 1
+  }
+}
+```
+
+## `multiply`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${multiply(6, 7)}" # => 42
+  }
+}
+```
+
+## `negate`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${negate(7)}" # => -7
+  }
+}
+```
+
+## `not`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${not(true)}" # => false
+  }
+}
+```
+
+## `notequal`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${notequal(4, 5)}" # => true
+  }
+}
+```
+
+## `or`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${or(true, false)}" # => true
+  }
+}
+```
+
+## `parseint`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${parseint("ff", 16)}" # => 255
+  }
+}
+```
+
+## `pow`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${pow(3, 2)}" # => 9
+  }
+}
+```
+
+## `range`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${range(0, 5)}" # => [0,1,2,3,4]
+  }
+}
+```
+
+## `regex`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${regex("h.llo", "hello")}" # => "hello"
+  }
+}
+```
+
+## `regex_replace`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${regex_replace("[0-9]+", "abc123xyz", "NUM")}" # => "abcNUMxyz"
+  }
+}
+```
+
+## `regexall`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = matches = "${regexall("[a-z]+", "abc123xyz")}" # => ["abc","xyz"]
+  }
+}
+```
+
+## `replace`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${replace("banana", "na", "--")}" # => "ba-- --"
+  }
+}
+```
+
+## `reverse`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${reverse("stressed")}" # => "desserts"
+  }
+}
+```
+
+## `reverselist`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${reverselist([1,2,3])}" # => [3,2,1]
+  }
+}
+```
+
+## `rsadecrypt`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${rsadecrypt("eczGaDhXDbOFRZ...", "MIIEowIBAAKCAQEAgUElV5...")}"
+  }
+}
+```
+
+## `sanitize`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${sanitize("My App! v1.0")}" # => "My_App__v1_0"
+  }
+}
+```
+
+## `semvercmp`
+
+This function checks if a semantic version fits within a set of constraints.
+See [Checking Version Constraints](https://github.com/Masterminds/semver?tab=readme-ov-file#checking-version-constraints)
+for details.
+
+```hcl
+# docker-bake.hcl
+variable "ALPINE_VERSION" {
+  default = "3.23"
+}
+
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  platforms = semvercmp(ALPINE_VERSION, ">= 3.20") ? [
+    "linux/amd64",
+    "linux/arm64",
+    "linux/riscv64"
+  ] : [
+    "linux/amd64",
+    "linux/arm64"
+  ]
+}
+```
+
+## `sethaselement`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${sethaselement([1,2,3], 2)}"  # => true
+  }
+}
+```
+
+## `setintersection`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${setintersection(["a","b","c"], ["b","c","d"])}" # => ["b","c"]
+  }
+}
+```
+
+## `setproduct`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${setproduct(["x","y"], [1,2])}" # => [["x",1],["x",2],["y",1],["y",2]]
+  }
+}
+```
+
+## `setsubtract`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${setsubtract([1,2,3], [2])}" # => [1,3]
+  }
+}
+```
+
+## `setsymmetricdifference`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${setsymmetricdifference([1,2,3], [3,4])}" # => [1,2,4]
+  }
+}
+```
+
+## `setunion`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${setunion(["a","b"], ["b","c"])}" # => ["a","b","c"]
+  }
+}
+```
+
+## `sha1`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${sha1("hello")}" # => "aaf4c61d..." (hex)
+  }
+}
+```
+
+## `sha256`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${sha256("hello")}" # => "2cf24dba..." (hex)
+  }
+}
+```
+
+## `sha512`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${sha512("hello")}" # => "9b71d224..." (hex)
+  }
+}
+```
+
+## `signum`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    zero = "${signum(0)}"    # => 0
+    pos  = "${signum(12)}"   # => 1
+    neg  = "${signum(-12)}"  # => -1
+  }
+}
+```
+
+## `slice`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${slice(["a","b","c","d"], 1, 3)}" # => ["b","c"]
+  }
+}
+```
+
+## `sort`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${sort(["b","c","a"])}" # => ["a","b","c"]
+  }
+}
+```
+
+## `split`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${split(",", "a,b,c")}" # => ["a","b","c"]
+  }
+}
+```
+
+## `strlen`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${strlen("Docker")}" # => 6
+  }
+}
+```
+
+## `substr`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${substr("abcdef", 2, 3)}" # => "cde"
+  }
+}
+```
+
+## `subtract`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${subtract(10, 3)}" # => 7
+  }
+}
+```
+
+## `timeadd`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${timeadd("2025-09-24T12:00:00Z", "1h30m")}" # => "2025-09-24T13:30:00Z"
+  }
+}
+```
+
+## `timestamp`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${timestamp()}" # => current RFC3339 time at evaluation
+  }
+}
+```
+
+## `title`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${title("hello world-from_docker")}" # => "Hello World-From_Docker"
+  }
+}
+```
+
+## `trim`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${trim("--hello--", "-")}" # => "hello"
+  }
+}
+```
+
+## `trimprefix`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${trimprefix("docker-build", "docker-")}" # => "build"
+  }
+}
+```
+
+## `trimspace`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${trimspace("   hello   ")}" # => "hello"
+  }
+}
+```
+
+## `trimsuffix`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${trimsuffix("filename.txt", ".txt")}" # => "filename"
+  }
+}
+```
+
+## `try`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    # First expr errors (invalid hex), second succeeds → returns 255
+    val1 = "${try(parseint("zz", 16), parseint("ff", 16))}" # => 255
+
+    # First expr errors (missing key), fallback string is used
+    val2 = "${try(index({a="apple"}, "b"), "fallback")}"    # => "fallback"
+  }
+}
+```
+
+## `unixtimestampparse`
+
+The returned object has the following attributes:
+* `year` (Number) The year for the unix timestamp.
+* `year_day` (Number) The day of the year for the unix timestamp, in the range 1-365 for non-leap years, and 1-366 in leap years.
+* `day` (Number) The day of the month for the unix timestamp.
+* `month` (Number) The month of the year for the unix timestamp.
+* `month_name` (String) The name of the month for the unix timestamp (ex. "January").
+* `weekday` (Number) The day of the week for the unix timestamp.
+* `weekday_name` (String) The name of the day for the unix timestamp (ex. "Sunday").
+* `hour` (Number) The hour within the day for the unix timestamp, in the range 0-23.
+* `minute` (Number) The minute offset within the hour for the unix timestamp, in the range 0-59.
+* `second` (Number) The second offset within the minute for the unix timestamp, in the range 0-59.
+* `rfc3339` (String) The RFC3339 format string.
+* `iso_year` (Number) The ISO 8601 year number.
+* `iso_week` (Number) The ISO 8601 week number.
+
+```hcl
+# docker-bake.hcl
+variable "SOURCE_DATE_EPOCH" {
+  type    = number
+  default = 1690328596
+}
+
+target "default" {
+  args = {
+    SOURCE_DATE_EPOCH = SOURCE_DATE_EPOCH
+  }
+  labels = {
+    "org.opencontainers.image.created" = unixtimestampparse(SOURCE_DATE_EPOCH).rfc3339
+  }
+}
+```
+
+## `upper`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    result = "${upper("hello")}" # => "HELLO"
+  }
+}
+```
+
+## `urlencode`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    url = "${urlencode("a b=c&d")}" # => "a+b%3Dc%26d"
+  }
+}
+```
+
+## `uuidv4`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    id = "${uuidv4()}" # => random v4 UUID each evaluation
+  }
+}
+```
+
+## `uuidv5`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    # Uses the DNS namespace UUID per RFC 4122
+    # "6ba7b810-9dad-11d1-80b4-00c04fd430c8"
+    id = "${uuidv5("6ba7b810-9dad-11d1-80b4-00c04fd430c8", "example.com")}"
+    # => always "9073926b-929f-31c2-abc9-fad77ae3e8eb" for "example.com"
+  }
+}
+```
+
+## `values`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    vals = "${values({a=1, c=3, b=2})}" # => [1,2,3] (ordered by key: a,b,c)
+  }
+}
+```
+
+## `zipmap`
+
+```hcl
+# docker-bake.hcl
+target "webapp-dev" {
+  dockerfile = "Dockerfile.webapp"
+  tags = ["docker.io/username/webapp:latest"]
+  args = {
+    obj = "${zipmap(["name","stars"], ["Docker", 5])}" # => {name="Docker", stars=5}
+  }
+}
+```
diff --git a/_vendor/github.com/docker/cli/docs/deprecated.md b/_vendor/github.com/docker/cli/docs/deprecated.md
index 30fe60f0ea2e..37ffcbc4705b 100644
--- a/_vendor/github.com/docker/cli/docs/deprecated.md
+++ b/_vendor/github.com/docker/cli/docs/deprecated.md
@@ -53,16 +53,22 @@ The following table provides an overview of the current status of deprecated fea
 
 | Status     | Feature                                                                                                                            | Deprecated | Remove |
 |------------|------------------------------------------------------------------------------------------------------------------------------------|------------|--------|
+| Deprecated | [Support for cgroup v1](#support-for-cgroup-v1)                                                                                    | v29.0      | -      |
+| Deprecated | [`--pause` option on `docker commit`](#--pause-option-on-docker-commit)                                                            | v29.0      | v30.0  |
+| Deprecated | [Legacy links environment variables](#legacy-links-environment-variables)                                                          | v28.4      | v30.0  |
+| Deprecated | [Special handling for quoted values for TLS flags](#special-handling-for-quoted-values-for-tls-flags)                              | v28.4      | v29.0  |
+| Deprecated | [Empty/nil fields in image Config from inspect API](#emptynil-fields-in-image-config-from-inspect-api)                             | v28.3      | v29.0  |
 | Deprecated | [Configuration for pushing  non-distributable artifacts](#configuration-for-pushing-non-distributable-artifacts)                   | v28.0      | v29.0  |
 | Deprecated | [`--time` option on `docker stop` and `docker restart`](#--time-option-on-docker-stop-and-docker-restart)                          | v28.0      | -      |
-| Deprecated | [Non-standard fields in image inspect](#non-standard-fields-in-image-inspect)                                                      | v27.0      | v28.0  |
+| Removed    | [Non-standard fields in image inspect](#non-standard-fields-in-image-inspect)                                                      | v27.0      | v28.2  |
 | Removed    | [API CORS headers](#api-cors-headers)                                                                                              | v27.0      | v28.0  |
-| Deprecated | [Graphdriver plugins (experimental)](#graphdriver-plugins-experimental)                                                            | v27.0      | v28.0  |
+| Removed    | [Graphdriver plugins (experimental)](#graphdriver-plugins-experimental)                                                            | v27.0      | v28.0  |
 | Deprecated | [Unauthenticated TCP connections](#unauthenticated-tcp-connections)                                                                | v26.0      | v28.0  |
-| Deprecated | [`Container` and `ContainerConfig` fields in Image inspect](#container-and-containerconfig-fields-in-image-inspect)                | v25.0      | v26.0  |
-| Deprecated | [Deprecate legacy API versions](#deprecate-legacy-api-versions)                                                                    | v25.0      | v26.0  |
+| Removed    | [`Container` and `ContainerConfig` fields in Image inspect](#container-and-containerconfig-fields-in-image-inspect)                | v25.0      | v26.0  |
+| Removed    | [Deprecate legacy API versions](#deprecate-legacy-api-versions)                                                                    | v25.0      | v26.0  |
 | Removed    | [Container short ID in network Aliases field](#container-short-id-in-network-aliases-field)                                        | v25.0      | v26.0  |
-| Deprecated | [IsAutomated field, and `is-automated` filter on `docker search`](#isautomated-field-and-is-automated-filter-on-docker-search)     | v25.0      | v26.0  |
+| Removed    | [Mount `bind-nonrecursive` option](#mount-bind-nonrecursive-option)                                                                | v25.0      | v29.0  |
+| Removed    | [IsAutomated field, and `is-automated` filter on `docker search`](#isautomated-field-and-is-automated-filter-on-docker-search)     | v25.0      | v28.2  |
 | Removed    | [logentries logging driver](#logentries-logging-driver)                                                                            | v24.0      | v25.0  |
 | Removed    | [OOM-score adjust for the daemon](#oom-score-adjust-for-the-daemon)                                                                | v24.0      | v25.0  |
 | Removed    | [BuildKit build information](#buildkit-build-information)                                                                          | v23.0      | v24.0  |
@@ -71,7 +77,7 @@ The following table provides an overview of the current status of deprecated fea
 | Removed    | [Btrfs storage driver on CentOS 7 and RHEL 7](#btrfs-storage-driver-on-centos-7-and-rhel-7)                                        | v20.10     | v23.0  |
 | Removed    | [Support for encrypted TLS private keys](#support-for-encrypted-tls-private-keys)                                                  | v20.10     | v23.0  |
 | Removed    | [Kubernetes stack and context support](#kubernetes-stack-and-context-support)                                                      | v20.10     | v23.0  |
-| Deprecated | [Pulling images from non-compliant image registries](#pulling-images-from-non-compliant-image-registries)                          | v20.10     | -      |
+| Removed    | [Pulling images from non-compliant image registries](#pulling-images-from-non-compliant-image-registries)                          | v20.10     | v28.2  |
 | Removed    | [Linux containers on Windows (LCOW)](#linux-containers-on-windows-lcow-experimental)                                               | v20.10     | v23.0  |
 | Deprecated | [BLKIO weight options with cgroups v1](#blkio-weight-options-with-cgroups-v1)                                                      | v20.10     | -      |
 | Removed    | [Kernel memory limit](#kernel-memory-limit)                                                                                        | v20.10     | v23.0  |
@@ -80,9 +86,9 @@ The following table provides an overview of the current status of deprecated fea
 | Deprecated | [CLI plugins support](#cli-plugins-support)                                                                                        | v20.10     | -      |
 | Deprecated | [Dockerfile legacy `ENV name value` syntax](#dockerfile-legacy-env-name-value-syntax)                                              | v20.10     | -      |
 | Removed    | [`docker build --stream` flag (experimental)](#docker-build---stream-flag-experimental)                                            | v20.10     | v20.10 |
-| Deprecated | [`fluentd-async-connect` log opt](#fluentd-async-connect-log-opt)                                                                  | v20.10     | v28.0  |
+| Removed    | [`fluentd-async-connect` log opt](#fluentd-async-connect-log-opt)                                                                  | v20.10     | v28.0  |
 | Removed    | [Configuration options for experimental CLI features](#configuration-options-for-experimental-cli-features)                        | v19.03     | v23.0  |
-| Deprecated | [Pushing and pulling with image manifest v2 schema 1](#pushing-and-pulling-with-image-manifest-v2-schema-1)                        | v19.03     | v27.0  |
+| Removed    | [Pushing and pulling with image manifest v2 schema 1](#pushing-and-pulling-with-image-manifest-v2-schema-1)                        | v19.03     | v28.2  |
 | Removed    | [`docker engine` subcommands](#docker-engine-subcommands)                                                                          | v19.03     | v20.10 |
 | Removed    | [Top-level `docker deploy` subcommand (experimental)](#top-level-docker-deploy-subcommand-experimental)                            | v19.03     | v20.10 |
 | Removed    | [`docker stack deploy` using "dab" files (experimental)](#docker-stack-deploy-using-dab-files-experimental)                        | v19.03     | v20.10 |
@@ -107,6 +113,7 @@ The following table provides an overview of the current status of deprecated fea
 | Deprecated | [`-h` shorthand for `--help`](#-h-shorthand-for---help)                                                                            | v1.12      | v17.09 |
 | Removed    | [`-e` and `--email` flags on `docker login`](#-e-and---email-flags-on-docker-login)                                                | v1.11      | v17.06 |
 | Deprecated | [Separator (`:`) of `--security-opt` flag on `docker run`](#separator--of---security-opt-flag-on-docker-run)                       | v1.11      | v17.06 |
+| Deprecated | [Links on the default bridge network](#links-on-the-default-bridge-network)                                                        | v1.10      | -      |
 | Deprecated | [Ambiguous event fields in API](#ambiguous-event-fields-in-api)                                                                    | v1.10      | -      |
 | Removed    | [`-f` flag on `docker tag`](#-f-flag-on-docker-tag)                                                                                | v1.10      | v1.12  |
 | Removed    | [HostConfig at API container start](#hostconfig-at-api-container-start)                                                            | v1.10      | v1.12  |
@@ -120,10 +127,127 @@ The following table provides an overview of the current status of deprecated fea
 | Removed    | [`--run` flag on `docker commit`](#--run-flag-on-docker-commit)                                                                    | v0.10      | v1.13  |
 | Removed    | [Three arguments form in `docker import`](#three-arguments-form-in-docker-import)                                                  | v0.6.7     | v1.12  |
 
-## Configuration for pushing non-distributable artifacts
+### Support for cgroup v1
 
-**Deprecated in Release: v28.0**
-**Target For Removal In Release: v29.0**
+**Deprecated in release: v29.0**
+
+Support for cgroup v1 is deprecated in the v29.0 release, however, it will continue
+to be supported until May 2029.
+The latest release in May 2029 may not necessarily support cgroup v1,
+but there will be at least one maintained branch with the support for cgroup v1.
+
+The cgroup version currently in use can be checked by running the `docker info` command:
+
+```console
+$ docker info
+<...>
+Server:
+ <...>
+ Cgroup Version: 2
+ <...>
+```
+
+### `--pause` option on `docker commit`
+
+**Deprecated in release: v29.0**
+
+**Target for removal in release: v30.0**
+
+The `--pause` option is enabled by default since Docker v1.1.0 to prevent
+committing containers in an inconsistent state, but can be disabled by
+setting the `--pause=false` option. In docker CLI v29.0 this flag is
+replaced by a `--no-pause` flag instead. The `--pause` option is still
+functional in the v29.0 release, printing a deprecation warning, but
+will be removed in docker CLI v30.
+
+### Legacy links environment variables
+
+**Deprecated in release: v28.4**
+
+**Disabled by default in release: v29.0**
+
+**Target for removal in release: v30.0**
+
+Containers attached to the default bridge network can specify "legacy links" (e.g.
+using `--links` on the CLI) to get access to other containers attached to that
+network. The linking container (i.e., the container created with `--links`) automatically
+gets environment variables that specify the IP address and port mappings of the linked
+container. However, these environment variables are prefixed with the linked
+container's names, making them impractical.
+
+Starting with Docker v29.0, these environment variables are no longer set by
+default. Users who still depend on them can start Docker Engine with the
+environment variable `DOCKER_KEEP_DEPRECATED_LEGACY_LINKS_ENV_VARS=1` set.
+
+Support for legacy links environment variables, as well as the `DOCKER_KEEP_DEPRECATED_LEGACY_LINKS_ENV_VARS`
+will be removed in Docker Engine v30.0.
+
+### Special handling for quoted values for TLS flags
+
+**Deprecated in release: v28.4**
+
+**Target for removal in release: v29.0**
+
+The `--tlscacert`, `--tlscert`, and `--tlskey` command-line flags had
+non-standard behavior for handling values contained in quotes (`"` or `'`).
+Normally, quotes are handled by the shell, for example, in the following
+example, the shell takes care of handling quotes before passing the values
+to the `docker` CLI:
+
+```console
+docker --some-option "some-value-in-quotes" ...
+```
+
+However, when passing values using an equal sign (`=`), this may not happen
+and values may be handled including quotes;
+
+```console
+docker --some-option="some-value-in-quotes" ...
+```
+
+This caused issues with "Docker Machine", which used this format as part
+of its `docker-machine config` output, and the CLI carried special, non-standard
+handling for these flags.
+
+Docker Machine reached EOL, and this special handling made the processing
+of flag values inconsistent with other flags used, so this behavior is
+deprecated. Users depending on this behavior are recommended to specify
+the quoted values using a space between the flag and its value, as illustrated
+above.
+
+### Empty/nil fields in image Config from inspect API
+
+**Deprecated in release: v28.3**
+
+**Target for removal in release: v29.0**
+
+The `Config` field returned by `docker image inspect` (and the `GET /images/{name}/json`
+API endpoint) currently includes certain fields even when they are empty or nil.
+Starting in Docker v29.0, the following fields will be omitted from the API response
+when they contain empty or default values:
+
+- `Cmd`
+- `Entrypoint`
+- `Env`
+- `Labels`
+- `OnBuild`
+- `User`
+- `Volumes`
+- `WorkingDir`
+
+Applications consuming the image inspect API should be updated to handle the
+absence of these fields gracefully, treating missing fields as having their
+default/empty values.
+
+For API version corresponding to Docker v29.0, these fields will be omitted when
+empty. They will continue to be included when using clients that request an older
+API version for backward compatibility.
+
+### Configuration for pushing non-distributable artifacts
+
+**Deprecated in release: v28.0**
+
+**Target for removal in release: v29.0**
 
 Non-distributable artifacts (also called foreign layers) were introduced in
 docker v1.12 to accommodate Windows images for which the EULA did not allow
@@ -161,7 +285,7 @@ entirely.
 
 ### `--time` option on `docker stop` and `docker restart`
 
-**Deprecated in Release: v28.0**
+**Deprecated in release: v28.0**
 
 The `--time` option for the `docker stop`, `docker container stop`, `docker restart`,
 and `docker container restart` commands has been renamed to `--timeout` for
@@ -171,8 +295,9 @@ Users are encouraged to migrate to using the `--timeout` option instead.
 
 ### Non-standard fields in image inspect
 
-**Deprecated in Release: v27.0**
-**Target For Removal In Release: v28.0**
+**Deprecated in release: v27.0**
+
+**Removed in release: v28.2**
 
 The `Config` field returned shown in `docker image inspect` (and as returned by
 the `GET /images/{name}/json` API endpoint) returns additional fields that are
@@ -184,8 +309,9 @@ but are not omitted in the response when left empty. As these fields were not
 intended to be part of the image configuration response, they are deprecated,
 and will be removed from the API in thee next release.
 
-The following fields are currently included in the API response, but are not
-part of the underlying image's `Config` field, and deprecated:
+The following fields are not part of the underlying image's `Config` field, and
+removed in the API response for API v1.50 and newer, corresponding with v28.2.
+They continue to be included when using clients that use an older API version:
 
 - `Hostname`
 - `Domainname`
@@ -196,39 +322,37 @@ part of the underlying image's `Config` field, and deprecated:
 - `OpenStdin`
 - `StdinOnce`
 - `Image`
-- `NetworkDisabled` (already omitted unless set)
-- `MacAddress` (already omitted unless set)
-- `StopTimeout` (already omitted unless set)
+- `NetworkDisabled` (omitted unless set on older API versions)
+- `MacAddress` (omitted unless set on older API versions)
+- `StopTimeout` (omitted unless set on older API versions)
 
 [Docker image specification]: https://github.com/moby/docker-image-spec/blob/v1.3.1/specs-go/v1/image.go#L19-L32
 [OCI image specification]: https://github.com/opencontainers/image-spec/blob/v1.1.0/specs-go/v1/config.go#L24-L62
 
 ### Graphdriver plugins (experimental)
 
-**Deprecated in Release: v27.0**
-**Disabled by default in Release: v27.0**
-**Target For Removal In Release: v28.0**
+**Deprecated in**: v27.0**. 
+
+**Disabled by default in release: v27.0**
+
+**Target for removal in release: v28.0**
 
 [Graphdriver plugins](https://github.com/docker/cli/blob/v26.1.4/docs/extend/plugins_graphdriver.md)
-are an experimental feature that allow extending the Docker Engine with custom
+were an experimental feature that allowed extending the Docker Engine with custom
 storage drivers for storing images and containers. This feature was not
-maintained since its inception, and will no longer be supported in upcoming
-releases.
-
-Support for graphdriver plugins is disabled by default in v27.0, and will be
-removed v28.0. An `DOCKERD_DEPRECATED_GRAPHDRIVER_PLUGINS` environment variable
-is provided in v27.0 to re-enable the feature. This environment variable must
-be set to a non-empty value in the daemon's environment.
+maintained since its inception.
 
-The `DOCKERD_DEPRECATED_GRAPHDRIVER_PLUGINS` environment variable, along with
-support for graphdriver plugins, will be removed in v28.0. Users of this feature
-are recommended to instead configure the Docker Engine to use the [containerd image store](https://docs.docker.com/storage/containerd/)
+Support for graphdriver plugins was disabled by default in v27.0, and removed
+in v28.0. Users of this feature are recommended to instead configure the Docker
+Engine to use the [containerd image store](https://docs.docker.com/storage/containerd/)
 and a custom [snapshotter](https://github.com/containerd/containerd/tree/v1.7.18/docs/snapshotters)
 
 ### API CORS headers
 
-**Deprecated in Release: v27.0**
-**Disabled by default in Release: v27.0**
+**Deprecated in release: v27.0**
+
+**Disabled by default in release: v27.0**
+
 **Removed in release: v28.0**
 
 The `api-cors-header` configuration option for the Docker daemon is insecure,
@@ -248,8 +372,9 @@ If you need to access the API through a browser, use a reverse proxy.
 
 ### Unauthenticated TCP connections
 
-**Deprecated in Release: v26.0**
-**Target For Removal In Release: v28.0**
+**Deprecated in release: v26.0**
+
+**Target for removal in release: v28.0**
 
 Configuring the Docker daemon to listen on a TCP address will require mandatory
 TLS verification. This change aims to ensure secure communication by preventing
@@ -275,21 +400,23 @@ configuring TLS (or SSH) for the Docker daemon, refer to
 
 ### `Container` and `ContainerConfig` fields in Image inspect
 
-**Deprecated in Release: v25.0**
-**Target For Removal In Release: v26.0**
+**Deprecated in release: v25.0**
+
+**Removed in release: v26.0**
 
 The `Container` and `ContainerConfig` fields returned by `docker inspect` are
 mostly an implementation detail of the classic (non-BuildKit) image builder.
 These fields are not portable and are empty when using the
 BuildKit-based builder (enabled by default since v23.0).
-These fields are deprecated in v25.0 and will be omitted starting from v26.0.
-If image configuration of an image is needed, you can obtain it from the
-`Config` field.
+These fields are deprecated in v25.0 and are omitted starting from v26.0 (
+API version v1.45 and up). If image configuration of an image is needed,
+you can obtain it from the `Config` field.
 
 ### Deprecate legacy API versions
 
-**Deprecated in Release: v25.0**
-**Target For Removal In Release: v26.0**
+**Deprecated in release: v25.0**
+
+**Target for removal in release: v26.0**
 
 The Docker daemon provides a versioned API for backward compatibility with old
 clients. Docker clients can perform API-version negotiation to select the most
@@ -326,25 +453,28 @@ Error response from daemon: client version 1.23 is too old. Minimum supported AP
 upgrade your client to a newer version
 ```
 
+Support for API versions lower than `1.24` has been permanently removed in Docker
+Engine v26, and the minimum supported API version will be incrementally raised
+in releases following that.
+
+<!-- keeping the paragraphs below for when we incrementally raise the minimum API version -->
+<!--
 An environment variable (`DOCKER_MIN_API_VERSION`) is introduced that allows
 re-enabling older API versions in the daemon. This environment variable must
 be set in the daemon's environment (for example, through a [systemd override
 file](https://docs.docker.com/config/daemon/systemd/)), and the specified
-API version must be supported by the daemon (`1.12` or higher on Linux, or
-`1.24` or higher on Windows).
-
-Support for API versions lower than `1.24` will be permanently removed in Docker
-Engine v26, and the minimum supported API version will be incrementally raised
-in releases following that.
+API version must be supported by the daemon (`1.24` or higher).
 
 We do not recommend depending on the `DOCKER_MIN_API_VERSION` environment
 variable other than for exceptional cases where it's not possible to update
 old clients, and those clients must be supported.
+-->
 
 ### Container short ID in network Aliases field
 
-**Deprecated in Release: v25.0**
-**Removed In Release: v26.0**
+**Deprecated in release: v25.0**
+
+**Removed in release: v26.0**
 
 The `Aliases` field returned by `docker inspect` contains the container short
 ID once the container is started. This behavior is deprecated in v25.0 but
@@ -356,10 +486,32 @@ A new field `DNSNames` containing the container name (if one was specified),
 the hostname, the network aliases, as well as the container short ID, has been
 introduced in v25.0 and should be used instead of the `Aliases` field.
 
+### Mount `bind-nonrecursive` option
+
+**Deprecated in release: v25.0**
+
+**Removed in release: v29.0**
+
+The `bind-nonrecursive` option was replaced with the [`bind-recursive`]
+option (see [cli-4316], [cli-4671]). The option was still accepted, but
+printed a deprecation warning:
+
+```console
+bind-nonrecursive is deprecated, use bind-recursive=disabled instead
+```
+
+In the v29.0 release, this warning is removed, and returned as an error.
+Users should use the equivalent `bind-recursive=disabled` option instead.
+
+[`bind-recursive`]: https://docs.docker.com/engine/storage/bind-mounts/#recursive-mounts
+[cli-4316]: https://github.com/docker/cli/pull/4316
+[cli-4671]: https://github.com/docker/cli/pull/4671
+
 ### IsAutomated field, and `is-automated` filter on `docker search`
 
-**Deprecated in Release: v25.0**
-**Target For Removal In Release: v26.0**
+**Deprecated in release: v25.0**
+
+**Removed in release: v28.2**
 
 The `is_automated` field has been deprecated by Docker Hub's search API.
 Consequently, the `IsAutomated` field in image search will always be set
@@ -368,12 +520,13 @@ results.
 
 The `AUTOMATED` column has been removed from the default `docker search`
 and `docker image search` output in v25.0, and the corresponding `IsAutomated`
-templating option will be removed in v26.0.
+templating has been removed in v28.2.
 
 ### Logentries logging driver
 
-**Deprecated in Release: v24.0**
-**Removed in Release: v25.0**
+**Deprecated in release: v24.0**
+
+**Removed in release: v25.0**
 
 The logentries service SaaS was shut down on November 15, 2022, rendering
 this logging driver non-functional. Users should no longer use this logging
@@ -383,8 +536,9 @@ after upgrading.
 
 ### OOM-score adjust for the daemon
 
-**Deprecated in Release: v24.0**
-**Removed in Release: v25.0**
+**Deprecated in release: v24.0**
+
+**Removed in release: v25.0**
 
 The `oom-score-adjust` option was added to prevent the daemon from being
 OOM-killed before other processes. This option was mostly added as a
@@ -403,8 +557,9 @@ the daemon.
 
 ### BuildKit build information
 
-**Deprecated in Release: v23.0**
-**Removed in Release: v24.0**
+**Deprecated in release: v23.0**
+
+**Removed in release: v24.0**
 
 [Build information](https://github.com/moby/buildkit/blob/v0.11/docs/buildinfo.md)
 structures have been introduced in [BuildKit v0.10.0](https://github.com/moby/buildkit/releases/tag/v0.10.0)
@@ -415,7 +570,7 @@ information is also embedded into the image configuration if one is generated.
 
 ### Legacy builder for Linux images
 
-**Deprecated in Release: v23.0**
+**Deprecated in release: v23.0**
 
 Docker v23.0 now uses BuildKit by default to build Linux images, and uses the
 [Buildx](https://docs.docker.com/buildx/working-with-buildx/) CLI component for
@@ -446,7 +601,7 @@ you to report issues in the [BuildKit issue tracker on GitHub](https://github.co
 
 ### Legacy builder fallback
 
-**Deprecated in Release: v23.0**
+**Deprecated in release: v23.0**
 
 [Docker v23.0 now uses BuildKit by default to build Linux images](#legacy-builder-for-linux-images),
 which requires the Buildx component to build images with BuildKit. There may be
@@ -492,7 +647,7 @@ be possible in a future release.
 
 ### Btrfs storage driver on CentOS 7 and RHEL 7
 
-**Removed in Release: v23.0**
+**Removed in release: v23.0**
 
 The `btrfs` storage driver on CentOS and RHEL was provided as a technology preview
 by CentOS and RHEL, but has been deprecated since the [Red Hat Enterprise Linux 7.4 release](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-btrfs),
@@ -504,9 +659,9 @@ of Docker will no longer provide this driver.
 
 ### Support for encrypted TLS private keys
 
-**Deprecated in Release: v20.10**
+**Deprecated in release: v20.10**
 
-**Removed in Release: v23.0**
+**Removed in release: v23.0**
 
 Use of encrypted TLS private keys has been deprecated, and has been removed.
 Golang has deprecated support for legacy PEM encryption (as specified in
@@ -520,8 +675,9 @@ to decrypt the private key, and store it un-encrypted to continue using it.
 
 ### Kubernetes stack and context support
 
-**Deprecated in Release: v20.10**
-**Removed in Release: v23.0**
+**Deprecated in release: v20.10**
+
+**Removed in release: v23.0**
 
 Following the deprecation of [Compose on Kubernetes](https://github.com/docker/compose-on-kubernetes),
 support for Kubernetes in the `stack` and `context` commands has been removed from
@@ -549,7 +705,9 @@ CLI configuration file are no longer used, and ignored.
 
 ### Pulling images from non-compliant image registries
 
-**Deprecated in Release: v20.10**
+**Deprecated in release: v20.10**
+
+**Removed in release: v28.2**
 
 Docker Engine v20.10 and up includes optimizations to verify if images in the
 local image cache need updating before pulling, preventing the Docker Engine
@@ -559,7 +717,7 @@ image registry to conform to the [Open Container Initiative Distribution Specifi
 While most registries conform to the specification, we encountered some registries
 to be non-compliant, resulting in `docker pull` to fail.
 
-As a temporary solution, Docker Engine v20.10 includes a fallback mechanism to
+As a temporary solution, Docker Engine v20.10 added a fallback mechanism to
 allow `docker pull` to be functional when using a non-compliant registry. A
 warning message is printed in this situation:
 
@@ -568,21 +726,19 @@ warning message is printed in this situation:
             pull by tag. This fallback is DEPRECATED, and will be removed in a future
             release.
 
-The fallback is added to allow users to either migrate their images to a compliant
-registry, or for these registries to become compliant.
-
-Note that this fallback only addresses failures on `docker pull`. Other commands,
-such as `docker stack deploy`, or pulling images with `containerd` will continue
-to fail.
+The fallback was added to allow users to either migrate their images to a
+compliant registry, or for these registries to become compliant.
 
-Given that other functionality is still broken with these registries, we consider
-this fallback a _temporary_ solution, and will remove the fallback in an upcoming
-major release.
+GitHub deprecated the legacy `docker.pkg.github.com` registry, and it was
+[sunset on Feb 24th, 2025](https://github.blog/changelog/2025-01-23-legacy-docker-registry-closing-down/)
+in favor of GitHub Container Registry (GHCR, ghcr.io), making this fallback
+no longer needed.
 
 ### Linux containers on Windows (LCOW) (experimental)
 
-**Deprecated in Release: v20.10**
-**Removed in Release: v23.0**
+**Deprecated in release: v20.10**
+
+**Removed in release: v23.0**
 
 The experimental feature to run Linux containers on Windows (LCOW) was introduced
 as a technical preview in Docker 17.09. While many enhancements were made after
@@ -594,7 +750,7 @@ Developers who want to run Linux workloads on a Windows host are encouraged to u
 
 ### BLKIO weight options with cgroups v1
 
-**Deprecated in Release: v20.10**
+**Deprecated in release: v20.10**
 
 Specifying blkio weight (`docker run --blkio-weight` and `docker run --blkio-weight-device`)
 is now marked as deprecated when using cgroups v1 because the corresponding features
@@ -604,35 +760,23 @@ When using cgroups v2, the `--blkio-weight` options are implemented using
 
 ### Kernel memory limit
 
-**Deprecated in Release: v20.10**
-**Removed in Release: v23.0**
+**Deprecated in release: v20.10**
+
+**Removed in release: v23.0**
 
 Specifying kernel memory limit (`docker run --kernel-memory`) is no longer supported
 because the [Linux kernel deprecated `kmem.limit_in_bytes` in v5.4](https://github.com/torvalds/linux/commit/0158115f702b0ba208ab0b5adf44cae99b3ebcc7).
-The OCI runtime specification now marks this option (as well as `--kernel-memory-tcp`)
-as ["NOT RECOMMENDED"](https://github.com/opencontainers/runtime-spec/pull/1093),
+The OCI runtime specification now marks this option as ["NOT RECOMMENDED"](https://github.com/opencontainers/runtime-spec/pull/1093),
 and OCI runtimes such as `runc` no longer support this option.
 
-Docker API v1.42 and up now ignores this option when set. Older versions of the
-API continue to accept the option, but depending on the OCI runtime used, may
-take no effect.
-
-> [!NOTE]
-> While not deprecated (yet) in Docker, the OCI runtime specification also
-> deprecated the `memory.kmem.tcp.limit_in_bytes` option. When using `runc` as
-> runtime, this option takes no effect. The Linux kernel did not explicitly
-> deprecate this feature, and there is a tracking ticket in the `runc` issue
-> tracker to determine if this option should be reinstated or if this was an
-> oversight of the Linux kernel maintainers (see [opencontainers/runc#3174](https://github.com/opencontainers/runc/issues/3174)).
->
-> The `memory.kmem.tcp.limit_in_bytes` option is only supported with cgroups v1,
-> and not available on installations running with cgroups v2. This option is
-> only supported by the API, and not exposed on the `docker` command-line.
+The Docker API no longer handles the kernel-memory fields, and Docker CLI v29.0
+removes the `--kernel-memory` option.
 
 ### Classic Swarm and overlay networks using cluster store
 
-**Deprecated in Release: v20.10**
-**Removed in Release: v23.0**
+**Deprecated in release: v20.10**
+
+**Removed in release: v23.0**
 
 Standalone ("classic") Swarm has been deprecated, and with that the use of overlay
 networks using an external key/value store. The corresponding`--cluster-advertise`,
@@ -640,8 +784,9 @@ networks using an external key/value store. The corresponding`--cluster-advertis
 
 ### Support for legacy `~/.dockercfg` configuration files
 
-**Deprecated in Release: v20.10**
-**Removed in Release: v23.0**
+**Deprecated in release: v20.10**
+
+**Removed in release: v23.0**
 
 The Docker CLI up until v1.7.0 used the `~/.dockercfg` file to store credentials
 after authenticating to a registry (`docker login`). Docker v1.7.0 replaced this
@@ -656,9 +801,9 @@ been removed.
 
 ### Configuration options for experimental CLI features
 
-**Deprecated in Release: v19.03**
+**Deprecated in release: v19.03**
 
-**Removed in Release: v23.0**
+**Removed in release: v23.0**
 
 The `DOCKER_CLI_EXPERIMENTAL` environment variable and the corresponding `experimental`
 field in the CLI configuration file are deprecated. Experimental features are
@@ -670,13 +815,13 @@ format.
 
 ### CLI plugins support
 
-**Deprecated in Release: v20.10**
+**Deprecated in release: v20.10**
 
 CLI Plugin API is now marked as deprecated.
 
 ### Dockerfile legacy `ENV name value` syntax
 
-**Deprecated in Release: v20.10**
+**Deprecated in release: v20.10**
 
 The Dockerfile `ENV` instruction allows values to be set using either `ENV name=value`
 or `ENV name value`. The latter (`ENV name value`) form can be ambiguous, for example,
@@ -700,8 +845,9 @@ ENV ONE="" TWO="" THREE="world"
 
 ### `docker build --stream` flag (experimental)
 
-**Deprecated in Release: v20.10**
-**Removed in Release: v20.10**
+**Deprecated in release: v20.10**
+
+**Removed in release: v20.10**
 
 Docker v17.07 introduced an experimental `--stream` flag on `docker build` which
 allowed the build-context to be incrementally sent to the daemon, instead of
@@ -717,8 +863,9 @@ files.
 
 ### `fluentd-async-connect` log opt
 
-**Deprecated in Release: v20.10**
-**Removed in Release: v28.0**
+**Deprecated in release: v20.10**
+
+**Removed in release: v28.0**
 
 The `--log-opt fluentd-async-connect` option for the fluentd logging driver is
 [deprecated in favor of `--log-opt fluentd-async`](https://github.com/moby/moby/pull/39086).
@@ -729,15 +876,16 @@ fluent#New: AsyncConnect is now deprecated, use Async instead
 ```
 
 Users are encouraged to use the `fluentd-async` option going forward, as support
-for the old option will be removed in a future release.
+for the old option has been removed.
 
 ### Pushing and pulling with image manifest v2 schema 1
 
-**Deprecated in Release: v19.03**
+**Deprecated in release: v19.03**
 
-**Disabled by default in Release: v26.0**
+**Disabled by default in release: v26.0**
+
+**Removed in release: v28.2**
 
-**Target For Removal In Release: v27.0**
 
 The image manifest [v2 schema 1](https://distribution.github.io/distribution/spec/deprecated-schema-v1/)
 and "Docker Image v1" formats were deprecated in favor of the
@@ -748,28 +896,22 @@ formats.
 These legacy formats should no longer be used, and users are recommended to
 update images to use current formats, or to upgrade to more current images.
 Starting with Docker v26.0, pulling these images is disabled by default, and
-produces an error when attempting to pull the image:
+support has been removed in v28.2. Attempting to pull a legacy image now
+produces an error:
 
 ```console
 $ docker pull ubuntu:10.04
 Error response from daemon:
-[DEPRECATION NOTICE] Docker Image Format v1 and Docker Image manifest version 2, schema 1 support is disabled by default and will be removed in an upcoming release.
+Docker Image Format v1 and Docker Image manifest version 2, schema 1 support has been removed.
 Suggest the author of docker.io/library/ubuntu:10.04 to upgrade the image to the OCI Format or Docker Image manifest v2, schema 2.
 More information at https://docs.docker.com/go/deprecated-image-specs/
 ```
 
-An environment variable (`DOCKER_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE`) is
-added in Docker v26.0 that allows re-enabling support for these image formats
-in the daemon. This environment variable must be set to a non-empty value in
-the daemon's environment (for example, through a [systemd override file](https://docs.docker.com/config/daemon/systemd/)).
-Support for the `DOCKER_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE` environment variable
-will be removed in Docker v27.0 after which this functionality is removed permanently.
-
 ### `docker engine` subcommands
 
-**Deprecated in Release: v19.03**
+**Deprecated in release: v19.03**
 
-**Removed in Release: v20.10**
+**Removed in release: v20.10**
 
 The `docker engine activate`, `docker engine check`, and `docker engine update`
 provided an alternative installation method to upgrade Docker Community engines
@@ -782,9 +924,9 @@ standard package managers.
 
 ### Top-level `docker deploy` subcommand (experimental)
 
-**Deprecated in Release: v19.03**
+**Deprecated in release: v19.03**
 
-**Removed in Release: v20.10**
+**Removed in release: v20.10**
 
 The top-level `docker deploy` command (using the "Docker Application Bundle"
 (.dab) file format was introduced as an experimental feature in Docker 1.13 /
@@ -793,9 +935,9 @@ subcommand.
 
 ### `docker stack deploy` using "dab" files (experimental)
 
-**Deprecated in Release: v19.03**
+**Deprecated in release: v19.03**
 
-**Removed in Release: v20.10**
+**Removed in release: v20.10**
 
 With no development being done on this feature, and no active use of the file
 format, support for the DAB file format and the top-level `docker deploy` command
@@ -804,8 +946,9 @@ using compose files.
 
 ### Support for the `overlay2.override_kernel_check` storage option
 
-**Deprecated in Release: v19.03**
-**Removed in Release: v24.0**
+**Deprecated in release: v19.03**
+
+**Removed in release: v24.0**
 
 This daemon configuration option disabled the Linux kernel version check used
 to detect if the kernel supported OverlayFS with multiple lower dirs, which is
@@ -815,8 +958,9 @@ option was no longer used.
 
 ### AuFS storage driver
 
-**Deprecated in Release: v19.03**
-**Removed in Release: v24.0**
+**Deprecated in release: v19.03**
+
+**Removed in release: v24.0**
 
 The `aufs` storage driver is deprecated in favor of `overlay2`, and has been
 removed in a Docker Engine v24.0. Users of the `aufs` storage driver must
@@ -834,8 +978,9 @@ maintenance of the `aufs` storage driver.
 
 ### Legacy overlay storage driver
 
-**Deprecated in Release: v18.09**
-**Removed in Release: v24.0**
+**Deprecated in release: v18.09**
+
+**Removed in release: v24.0**
 
 The `overlay` storage driver is deprecated in favor of the `overlay2` storage
 driver, which has all the benefits of `overlay`, without its limitations (excessive
@@ -850,9 +995,11 @@ backported), there is no reason to keep maintaining the `overlay` storage driver
 
 ### Device mapper storage driver
 
-**Deprecated in Release: v18.09**
-**Disabled by default in Release: v23.0**
-**Removed in Release: v25.0**
+**Deprecated in release: v18.09**
+
+**Disabled by default in release: v23.0**
+
+**Removed in release: v25.0**
 
 The `devicemapper` storage driver is deprecated in favor of `overlay2`, and has
 been removed in Docker Engine v25.0. Users of the `devicemapper` storage driver
@@ -868,9 +1015,9 @@ is no reason to continue maintenance of the `devicemapper` storage driver.
 
 ### Use of reserved namespaces in engine labels
 
-**Deprecated in Release: v18.06**
+**Deprecated in release: v18.06**
 
-**Removed In Release: v20.10**
+**Removed in release: v20.10**
 
 The namespaces `com.docker.*`, `io.docker.*`, and `org.dockerproject.*` in engine labels
 were always documented to be reserved, but there was never any enforcement.
@@ -882,7 +1029,7 @@ use, and will error instead in v20.10 and above.
 
 **Disabled In Release: v17.12**
 
-**Removed In Release: v19.03**
+**Removed in release: v19.03**
 
 The `--disable-legacy-registry` flag was disabled in Docker 17.12 and will print
 an error when used. For this error to be printed, the flag itself is still present,
@@ -890,9 +1037,9 @@ but hidden. The flag has been removed in Docker 19.03.
 
 ### Interacting with V1 registries
 
-**Disabled By Default In Release: v17.06**
+**Disabled by default in release: v17.06**
 
-**Removed In Release: v17.12**
+**Removed in release: v17.12**
 
 Version 1.8.3 added a flag (`--disable-legacy-registry=false`) which prevents the
 Docker daemon from `pull`, `push`, and `login` operations against v1
@@ -909,7 +1056,7 @@ start when set.
 
 ### Asynchronous `service create` and `service update` as default
 
-**Deprecated In Release: v17.05**
+**Deprecated in release: v17.05**
 
 **Disabled by default in release: [v17.10](https://github.com/docker/docker-ce/releases/tag/v17.10.0-ce)**
 
@@ -923,9 +1070,9 @@ and `docker service scale` in Docker 17.10.
 
 ### `-g` and `--graph` flags on `dockerd`
 
-**Deprecated In Release: v17.05**
+**Deprecated in release: v17.05**
 
-**Removed In Release: v23.0**
+**Removed in release: v23.0**
 
 The `-g` or `--graph` flag for the `dockerd` or `docker daemon` command was
 used to indicate the directory in which to store persistent data and resource
@@ -934,9 +1081,9 @@ flag. These flags were deprecated and hidden in v17.05, and removed in v23.0.
 
 ### Top-level network properties in NetworkSettings
 
-**Deprecated In Release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
+**Deprecated in release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
 
-**Target For Removal In Release: v17.12**
+**Target for removal in release: v17.12**
 
 When inspecting a container, `NetworkSettings` contains top-level information
 about the default ("bridge") network;
@@ -953,18 +1100,18 @@ information.
 
 ### `filter` option for `/images/json` endpoint
 
-**Deprecated In Release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
+**Deprecated in release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
 
-**Removed In Release: v20.10**
+**Removed in release: v20.10**
 
 The `filter` option to filter the list of image by reference (name or name:tag)
 is now implemented as a regular filter, named `reference`.
 
 ### `repository:shortid` image references
 
-**Deprecated In Release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
+**Deprecated in release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
 
-**Removed In Release: v17.12**
+**Removed in release: v17.12**
 
 The `repository:shortid` syntax for referencing images is very little used,
 collides with tag references, and can be confused with digest references.
@@ -974,32 +1121,32 @@ in Docker 17.12.
 
 ### `docker daemon` subcommand
 
-**Deprecated In Release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
+**Deprecated in release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
 
-**Removed In Release: v17.12**
+**Removed in release: v17.12**
 
 The daemon is moved to a separate binary (`dockerd`), and should be used instead.
 
 ### Duplicate keys with conflicting values in engine labels
 
-**Deprecated In Release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
+**Deprecated in release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
 
-**Removed In Release: v17.12**
+**Removed in release: v17.12**
 
 When setting duplicate keys with conflicting values, an error will be produced, and the daemon
 will fail to start.
 
 ### `MAINTAINER` in Dockerfile
 
-**Deprecated In Release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
+**Deprecated in release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
 
 `MAINTAINER` was an early very limited form of `LABEL` which should be used instead.
 
 ### API calls without a version
 
-**Deprecated In Release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
+**Deprecated in release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
 
-**Target For Removal In Release: v17.12**
+**Target for removal in release: v17.12**
 
 API versions should be supplied to all API calls to ensure compatibility with
 future Engine versions. Instead of just requesting, for example, the URL
@@ -1007,9 +1154,9 @@ future Engine versions. Instead of just requesting, for example, the URL
 
 ### Backing filesystem without `d_type` support for overlay/overlay2
 
-**Deprecated In Release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
+**Deprecated in release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
 
-**Removed In Release: v17.12**
+**Removed in release: v17.12**
 
 The overlay and overlay2 storage driver does not work as expected if the backing
 filesystem does not support `d_type`. For example, XFS does not support `d_type`
@@ -1023,18 +1170,18 @@ Refer to [#27358](https://github.com/docker/docker/issues/27358) for details.
 
 ### `--automated` and `--stars` flags on `docker search`
 
-**Deprecated in Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
+**Deprecated in release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
 
-**Removed In Release: v20.10**
+**Removed in release: v20.10**
 
 The `docker search --automated` and `docker search --stars` options are deprecated.
 Use `docker search --filter=is-automated=<true|false>` and `docker search --filter=stars=...` instead.
 
 ### `-h` shorthand for `--help`
 
-**Deprecated In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
+**Deprecated in release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
 
-**Target For Removal In Release: v17.09**
+**Target for removal in release: v17.09**
 
 The shorthand (`-h`) is less common than `--help` on Linux and cannot be used
 on all subcommands (due to it conflicting with, e.g. `-h` / `--hostname` on
@@ -1043,58 +1190,71 @@ on all subcommands (due to it conflicting with, e.g. `-h` / `--hostname` on
 
 ### `-e` and `--email` flags on `docker login`
 
-**Deprecated In Release: [v1.11.0](https://github.com/docker/docker/releases/tag/v1.11.0)**
+**Deprecated in release: [v1.11.0](https://github.com/docker/docker/releases/tag/v1.11.0)**
 
-**Removed In Release: [v17.06](https://github.com/docker/docker-ce/releases/tag/v17.06.0-ce)**
+**Removed in release: [v17.06](https://github.com/docker/docker-ce/releases/tag/v17.06.0-ce)**
 
 The `docker login` no longer automatically registers an account with the target registry if the given username doesn't exist. Due to this change, the email flag is no longer required, and will be deprecated.
 
 ### Separator (`:`) of `--security-opt` flag on `docker run`
 
-**Deprecated In Release: [v1.11.0](https://github.com/docker/docker/releases/tag/v1.11.0)**
+**Deprecated in release: [v1.11.0](https://github.com/docker/docker/releases/tag/v1.11.0)**
 
-**Target For Removal In Release: v17.06**
+**Target for removal in release: v17.06**
 
 The flag `--security-opt` doesn't use the colon separator (`:`) anymore to divide keys and values, it uses the equal symbol (`=`) for consistency with other similar flags, like `--storage-opt`.
 
+### Links on the default bridge network
+
+**Deprecated in release: v1.10**
+**Target for removal in release: v30.0**
+
+The `--link` option on `docker create` and `docker run`, when used with no
+`--network` specified, was deprecated in v1.10 and will be removed in a future
+release. Custom networks should be used instead. Docker 29.6 added a deprecation
+warning when this option is used for the default bridge network.
+
+Note that the `--link` option is still supported when a non-default network
+is used.
+
 ### Ambiguous event fields in API
 
-**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
+**Deprecated in release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
 
 The fields `ID`, `Status` and `From` in the events API have been deprecated in favor of a more rich structure.
 See the events API documentation for the new format.
 
 ### `-f` flag on `docker tag`
 
-**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
+**Deprecated in release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
 
-**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
+**Removed in release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
 
 To make tagging consistent across the various `docker` commands, the `-f` flag on the `docker tag` command is deprecated. It is no longer necessary to specify `-f` to move a tag from one image to another. Nor will `docker` generate an error if the `-f` flag is missing and the specified tag is already in use.
 
 ### HostConfig at API container start
 
-**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
+**Deprecated in release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
 
-**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
+**Removed in release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
 
 Passing an `HostConfig` to `POST /containers/{name}/start` is deprecated in favor of
 defining it at container creation (`POST /containers/create`).
 
 ### `--before` and `--since` flags on `docker ps`
 
-**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
+**Deprecated in release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
 
-**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
+**Removed in release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
 
 The `docker ps --before` and `docker ps --since` options are deprecated.
 Use `docker ps --filter=before=...` and `docker ps --filter=since=...` instead.
 
 ### Driver-specific log tags
 
-**Deprecated In Release: [v1.9.0](https://github.com/docker/docker/releases/tag/v1.9.0)**
+**Deprecated in release: [v1.9.0](https://github.com/docker/docker/releases/tag/v1.9.0)**
 
-**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
+**Removed in release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
 
 Log tags are now generated in a standard way across different logging drivers.
 Because of which, the driver specific log tag options `syslog-tag`, `gelf-tag` and
@@ -1106,9 +1266,9 @@ $ docker --log-driver=syslog --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"
 
 ### Docker Content Trust ENV passphrase variables name change
 
-**Deprecated In Release: [v1.9.0](https://github.com/docker/docker/releases/tag/v1.9.0)**
+**Deprecated in release: [v1.9.0](https://github.com/docker/docker/releases/tag/v1.9.0)**
 
-**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
+**Removed in release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
 
 Since 1.9, Docker Content Trust Offline key has been renamed to Root key and the Tagging key has been renamed to Repository key. Due to this renaming, we're also changing the corresponding environment variables
 
@@ -1117,25 +1277,25 @@ Since 1.9, Docker Content Trust Offline key has been renamed to Root key and the
 
 ### `/containers/(id or name)/copy` endpoint
 
-**Deprecated In Release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
+**Deprecated in release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
 
-**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
+**Removed in release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
 
 The endpoint `/containers/(id or name)/copy` is deprecated in favor of `/containers/(id or name)/archive`.
 
 ### LXC built-in exec driver
 
-**Deprecated In Release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
+**Deprecated in release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
 
-**Removed In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
+**Removed in release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
 
 The built-in LXC execution driver, the lxc-conf flag, and API fields have been removed.
 
 ### Old Command Line Options
 
-**Deprecated In Release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
+**Deprecated in release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
 
-**Removed In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
+**Removed in release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
 
 The flags `-d` and `--daemon` are deprecated. Use the separate `dockerd` binary instead.
 
@@ -1179,34 +1339,34 @@ The following double-dash options are deprecated and have no replacement:
 - `docker ps --before-id`
 - `docker search --trusted`
 
-**Deprecated In Release: [v1.5.0](https://github.com/docker/docker/releases/tag/v1.5.0)**
+**Deprecated in release: [v1.5.0](https://github.com/docker/docker/releases/tag/v1.5.0)**
 
-**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
+**Removed in release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
 
 The single-dash (`-help`) was removed, in favor of the double-dash `--help`
 
 ### `--api-enable-cors` flag on `dockerd`
 
-**Deprecated In Release: [v1.6.0](https://github.com/docker/docker/releases/tag/v1.6.0)**
+**Deprecated in release: [v1.6.0](https://github.com/docker/docker/releases/tag/v1.6.0)**
 
-**Removed In Release: [v17.09](https://github.com/docker/docker-ce/releases/tag/v17.09.0-ce)**
+**Removed in release: [v17.09](https://github.com/docker/docker-ce/releases/tag/v17.09.0-ce)**
 
 The flag `--api-enable-cors` is deprecated since v1.6.0. Use the flag
 `--api-cors-header` instead.
 
 ### `--run` flag on `docker commit`
 
-**Deprecated In Release: [v0.10.0](https://github.com/docker/docker/releases/tag/v0.10.0)**
+**Deprecated in release: [v0.10.0](https://github.com/docker/docker/releases/tag/v0.10.0)**
 
-**Removed In Release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
+**Removed in release: [v1.13.0](https://github.com/docker/docker/releases/tag/v1.13.0)**
 
 The flag `--run` of the `docker commit` command (and its short version `-run`) were deprecated in favor
 of the `--changes` flag that allows to pass `Dockerfile` commands.
 
 ### Three arguments form in `docker import`
 
-**Deprecated In Release: [v0.6.7](https://github.com/docker/docker/releases/tag/v0.6.7)**
+**Deprecated in release: [v0.6.7](https://github.com/docker/docker/releases/tag/v0.6.7)**
 
-**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
+**Removed in release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
 
 The `docker import` command format `file|URL|- [REPOSITORY [TAG]]` is deprecated since November 2013. It's no longer supported.
diff --git a/_vendor/github.com/docker/cli/docs/extend/legacy_plugins.md b/_vendor/github.com/docker/cli/docs/extend/legacy_plugins.md
index 2c6ba4bc1a2e..11269df40439 100644
--- a/_vendor/github.com/docker/cli/docs/extend/legacy_plugins.md
+++ b/_vendor/github.com/docker/cli/docs/extend/legacy_plugins.md
@@ -10,6 +10,14 @@ This document describes the Docker Engine plugins generally available in Docker
 Engine. To view information on plugins managed by Docker,
 refer to [Docker Engine plugin system](_index.md).
 
+> [!NOTE]
+> Legacy plugins are superseded by Docker Engine's managed plugin system.
+> For plugins installed and managed by Docker, use
+> [`docker plugin install`](https://docs.docker.com/reference/cli/docker/plugin/install/)
+> and the [Docker Engine plugin system](_index.md). The third-party plugins
+> listed on this page are provided for historical reference, and archived
+> projects are marked accordingly.
+
 You can extend the capabilities of the Docker Engine by loading third-party
 plugins. This page explains the types of plugins and provides links to several
 volume and network plugins for Docker.
@@ -30,7 +38,8 @@ Follow the instructions in the plugin's documentation.
 
 ## Finding a plugin
 
-The sections below provide an overview of available third-party plugins.
+The sections below provide an overview of third-party plugins that use the
+legacy plugin model.
 
 ### Network plugins
 
@@ -44,22 +53,21 @@ The sections below provide an overview of available third-party plugins.
 
 | Plugin                                                                                             | Description                                                                                                                                                                                                                                                                                                   |
 |:---------------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Azure File Storage plugin](https://github.com/Azure/azurefile-dockervolumedriver)                 | Lets you mount Microsoft [Azure File Storage](https://azure.microsoft.com/blog/azure-file-storage-now-generally-available/) shares to Docker containers as volumes using the SMB 3.0 protocol. [Learn more](https://azure.microsoft.com/blog/persistent-docker-volumes-with-azure-file-storage/).             |
+| [Azure File Storage plugin](https://github.com/Azure/azurefile-dockervolumedriver) (archived)      | Lets you mount Microsoft [Azure File Storage](https://azure.microsoft.com/blog/azure-file-storage-now-generally-available/) shares to Docker containers as volumes using the SMB 3.0 protocol. [Learn more](https://azure.microsoft.com/blog/persistent-docker-volumes-with-azure-file-storage/).             |
 | [BeeGFS Volume Plugin](https://github.com/RedCoolBeans/docker-volume-beegfs)                       | An open source volume plugin to create persistent volumes in a BeeGFS parallel file system.                                                                                                                                                                                                                   |
 | [Blockbridge plugin](https://github.com/blockbridge/blockbridge-docker-volume)                     | A volume plugin that provides access to an extensible set of container-based persistent storage options. It supports single and multi-host Docker environments with features that include tenant isolation, automated provisioning, encryption, secure deletion, snapshots and QoS.                           |
 | [Contiv Volume Plugin](https://github.com/contiv/volplugin)                                        | An open source volume plugin that provides multi-tenant, persistent, distributed storage with intent based consumption. It has support for Ceph and NFS.                                                                                                                                                      |
-| [Convoy plugin](https://github.com/rancher/convoy)                                                 | A volume plugin for a variety of storage back-ends including device mapper and NFS. It's a simple standalone executable written in Go and provides the framework to support vendor-specific extensions such as snapshots, backups and restore.                                                                |
+| [Convoy plugin](https://github.com/rancher/convoy) (archived)                                      | A volume plugin for a variety of storage back-ends including device mapper and NFS. It's a simple standalone executable written in Go and provides the framework to support vendor-specific extensions such as snapshots, backups and restore.                                                                |
 | [DigitalOcean Block Storage plugin](https://github.com/omallo/docker-volume-plugin-dostorage)      | Integrates DigitalOcean's [block storage solution](https://www.digitalocean.com/products/storage/) into the Docker ecosystem by automatically attaching a given block storage volume to a DigitalOcean droplet and making the contents of the volume available to Docker containers running on that droplet.  |
 | [DRBD plugin](https://www.drbd.org/en/supported-projects/docker)                                   | A volume plugin that provides highly available storage replicated by [DRBD](https://www.drbd.org). Data written to the docker volume is replicated in a cluster of DRBD nodes.                                                                                                                                |
-| [Flocker plugin](https://github.com/ScatterHQ/flocker)                                             | A volume plugin that provides multi-host portable volumes for Docker, enabling you to run databases and other stateful containers and move them around across a cluster of machines.                                                                                                                          |
-| [Fuxi Volume Plugin](https://github.com/openstack/fuxi)                                            | A volume plugin that is developed as part of the OpenStack Kuryr project and implements the Docker volume plugin API by utilizing Cinder, the OpenStack block storage service.                                                                                                                                |
-| [gce-docker plugin](https://github.com/mcuadros/gce-docker)                                        | A volume plugin able to attach, format and mount Google Compute [persistent-disks](https://cloud.google.com/compute/docs/disks/persistent-disks).                                                                                                                                                             |
-| [GlusterFS plugin](https://github.com/calavera/docker-volume-glusterfs)                            | A volume plugin that provides multi-host volumes management for Docker using GlusterFS.                                                                                                                                                                                                                       |
+| [Flocker plugin](https://github.com/ScatterHQ/flocker) (archived)                                  | A volume plugin that provides multi-host portable volumes for Docker, enabling you to run databases and other stateful containers and move them around across a cluster of machines.                                                                                                                          |
+| [Fuxi Volume Plugin](https://github.com/openstack-archive/fuxi) (archived)                         | A volume plugin that is developed as part of the OpenStack Kuryr project and implements the Docker volume plugin API by utilizing Cinder, the OpenStack block storage service.                                                                                                                                |
+| [gce-docker plugin](https://github.com/mcuadros/gce-docker) (archived)                             | A volume plugin able to attach, format and mount Google Compute [persistent-disks](https://cloud.google.com/compute/docs/disks/persistent-disks).                                                                                                                                                             |
+| [GlusterFS plugin](https://github.com/calavera/docker-volume-glusterfs) (archived)                 | A volume plugin that provides multi-host volumes management for Docker using GlusterFS.                                                                                                                                                                                                                       |
 | [Horcrux Volume Plugin](https://github.com/muthu-r/horcrux)                                        | A volume plugin that allows on-demand, version controlled access to your data. Horcrux is an open-source plugin, written in Go, and supports SCP, [Minio](https://www.minio.io) and Amazon S3.                                                                                                                |
 | [HPE 3Par Volume Plugin](https://github.com/hpe-storage/python-hpedockerplugin/)                   | A volume plugin that supports HPE 3Par and StoreVirtual iSCSI storage arrays.                                                                                                                                                                                                                                 |
-| [Infinit volume plugin](https://infinit.sh/documentation/docker/volume-plugin)                     | A volume plugin that makes it easy to mount and manage Infinit volumes using Docker.                                                                                                                                                                                                                          |
-| [IPFS Volume Plugin](https://github.com/vdemeester/docker-volume-ipfs)                              | An open source volume plugin that allows using an [ipfs](https://ipfs.io/) filesystem as a volume.                                                                                                                                                                                                            |
-| [Keywhiz plugin](https://github.com/calavera/docker-volume-keywhiz)                                | A plugin that provides credentials and secret management using Keywhiz as a central repository.                                                                                                                                                                                                               |
+| [IPFS Volume Plugin](https://github.com/vdemeester/docker-volume-ipfs) (archived)                  | An open source volume plugin that allows using an [ipfs](https://ipfs.io/) filesystem as a volume.                                                                                                                                                                                                            |
+| [Keywhiz plugin](https://github.com/calavera/docker-volume-keywhiz) (archived)                     | A plugin that provides credentials and secret management using Keywhiz as a central repository.                                                                                                                                                                                                               |
 | [Linode Volume Plugin](https://github.com/linode/docker-volume-linode)                             | A plugin that adds the ability to manage Linode Block Storage as Docker Volumes from within a Linode. |
 | [Local Persist Plugin](https://github.com/CWSpear/local-persist)                                   | A volume plugin that extends the default `local` driver's functionality by allowing you specify a mountpoint anywhere on the host, which enables the files to *always persist*, even if the volume is removed via `docker volume rm`.                                                                         |
 | [NetApp Plugin](https://github.com/NetApp/netappdvp) (nDVP)                                        | A volume plugin that provides direct integration with the Docker ecosystem for the NetApp storage portfolio. The nDVP package supports the provisioning and management of storage resources from the storage platform to Docker hosts, with a robust framework for adding additional platforms in the future. |
diff --git a/_vendor/github.com/docker/cli/docs/extend/plugin_api.md b/_vendor/github.com/docker/cli/docs/extend/plugin_api.md
index a0b0a7367552..0cf2d9e1d6bf 100644
--- a/_vendor/github.com/docker/cli/docs/extend/plugin_api.md
+++ b/_vendor/github.com/docker/cli/docs/extend/plugin_api.md
@@ -21,7 +21,7 @@ which registers itself by placing a file on the daemon host in one of the plugin
 directories described in [Plugin discovery](#plugin-discovery).
 
 Plugins have human-readable names, which are short, lowercase strings. For
-example, `flocker` or `weave`.
+example, `myplugin`.
 
 Plugins can run inside or outside containers. Currently running them outside
 containers is recommended.
@@ -45,12 +45,12 @@ spec files can be located either under `/etc/docker/plugins` or `/usr/lib/docker
 
 The name of the file (excluding the extension) determines the plugin name.
 
-For example, the `flocker` plugin might create a Unix socket at
-`/run/docker/plugins/flocker.sock`.
+For example, a plugin named `myplugin` might create a Unix socket at
+`/run/docker/plugins/myplugin.sock`.
 
 You can define each plugin into a separated subdirectory if you want to isolate definitions from each other.
-For example, you can create the `flocker` socket under `/run/docker/plugins/flocker/flocker.sock` and only
-mount `/run/docker/plugins/flocker` inside the `flocker` container.
+For example, you can create the `myplugin` socket under `/run/docker/plugins/myplugin/myplugin.sock` and only
+mount `/run/docker/plugins/myplugin` inside the `myplugin` container.
 
 Docker always searches for Unix sockets in `/run/docker/plugins` first. It checks for spec or json files under
 `/etc/docker/plugins` and `/usr/lib/docker/plugins` if the socket doesn't exist. The directory scan stops as
diff --git a/_vendor/github.com/docker/cli/docs/extend/plugins_authorization.md b/_vendor/github.com/docker/cli/docs/extend/plugins_authorization.md
index b8678debd59d..605fac16fa04 100644
--- a/_vendor/github.com/docker/cli/docs/extend/plugins_authorization.md
+++ b/_vendor/github.com/docker/cli/docs/extend/plugins_authorization.md
@@ -74,9 +74,14 @@ The sequence diagrams below depict an allow and deny authorization flow:
 Each request sent to the plugin includes the authenticated user, the HTTP
 headers, and the request/response body. Only the user name and the
 authentication method used are passed to the plugin. Most importantly, no user
-credentials or tokens are passed. Finally, not all request/response bodies
-are sent to the authorization plugin. Only those request/response bodies where
-the `Content-Type` is either `text/*` or `application/json` are sent.
+credentials or tokens are passed.
+
+> [!NOTE]
+> Authorization plugins enforce requests to the Docker daemon's HTTP API only. gRPC method
+> calls, whether dispatched natively or upgraded through `POST /grpc`, are not subject to authorization.
+> Furthermore, HTTP request/response bodies where the `Content-Type` is `application/json` are forwarded;
+> bodies of any other type are not visible to the plugin and cannot be used for enforcement,
+> even though the daemon acts on this data.
 
 For commands that can potentially hijack the HTTP connection (`HTTP
 Upgrade`), such as `exec`, the authorization plugin is only called for the
@@ -86,6 +91,38 @@ passed to the authorization plugins. For commands that return chunked HTTP
 response, such as `logs` and `events`, only the HTTP request is sent to the
 authorization plugins.
 
+The Engine's authorization middleware fails closed: when a plugin returns an error or returns `Allow: false`,
+the request is denied and the error is surfaced to the client. Plugins should also fail closed: if the plugin
+cannot confidently evaluate a request, it should return an error or `Allow: false`.
+
+> [!WARNING]
+> Because the plugin receives the [**raw** request body](#authzpluginauthzreq) from the daemon, it must
+> apply the same decoding semantics as the daemon to be sure it evaluates the request the daemon will
+> act on. The daemon decodes JSON with Go's [`encoding/json.Unmarshal`](https://pkg.go.dev/encoding/json#Unmarshal).
+>
+> The same requirement applies to the response body. Plugins that depend on `ResponseBody`
+> inspection for redaction or content-filtering should restrict their policies to endpoints
+> whose response is produced as a single write (typical of REST-style API responses). For
+> commands whose responses are streamed or are likely to exceed the [buffer](#response-body-size-and-partial-buffering) through multiple
+> writes, do not rely on `ResponseBody` for security-relevant decisions; perform the filtering
+> in a separate layer in front of the daemon.
+
+### Response body size and partial buffering
+
+The internal buffer that holds the response body between the daemon's HTTP
+handler and the plugin's response authorization callback (`responseModifier`,
+defined in [`pkg/authorization/response.go`](https://github.com/moby/moby/blob/master/pkg/authorization/response.go))
+has a fixed capacity of 64 KiB (`maxBufferSize`).
+
+For most non-streaming endpoints the full response is buffered for plugin
+inspection regardless of total size, because Go's `encoding/json` encoder
+serializes the complete payload into a single underlying write. The
+streaming-response exclusion noted above (for example, `logs` and `events`)
+is the practical effect of this 64 KiB threshold combined with the
+`io.WriteFlusher` write pattern used by streaming handlers, where each write
+is immediately drained to the client and is therefore no longer available
+for plugin inspection by the time the handler returns.
+
 During request/response processing, some authorization flows might
 need to do additional queries to the Docker daemon. To complete such flows,
 plugins can call the daemon API similar to a regular user. To enable these
@@ -209,7 +246,7 @@ Name                   | Type              | Description
 User                   | string            | The user identification
 Authentication method  | string            | The authentication method used
 Request method         | enum              | The HTTP method (GET/DELETE/POST)
-Request URI            | string            | The HTTP request URI including API version (e.g., v.1.17/containers/json)
+Request URI            | string            | The HTTP request URI including API version, as sent by the client (e.g., v.1.17/containers/json)
 Request headers        | map[string]string | Request headers as key value pairs (without the authorization header)
 Request body           | []byte            | Raw request body
 
@@ -232,7 +269,7 @@ Name                    | Type              | Description
 User                    | string            | The user identification
 Authentication method   | string            | The authentication method used
 Request method          | string            | The HTTP method (GET/DELETE/POST)
-Request URI             | string            | The HTTP request URI including API version (e.g., v.1.17/containers/json)
+Request URI             | string            | The HTTP request URI including API version, as sent by the client (e.g., v.1.17/containers/json)
 Request headers         | map[string]string | Request headers as key value pairs (without the authorization header)
 Request body            | []byte            | Raw request body
 Response status code    | int               | Status code from the Docker daemon
diff --git a/_vendor/github.com/docker/cli/docs/extend/plugins_network.md b/_vendor/github.com/docker/cli/docs/extend/plugins_network.md
index 8f94546b01b4..0ff0a64b1b6a 100644
--- a/_vendor/github.com/docker/cli/docs/extend/plugins_network.md
+++ b/_vendor/github.com/docker/cli/docs/extend/plugins_network.md
@@ -61,11 +61,4 @@ plugin protocol
 
 The network driver protocol, in addition to the plugin activation call, is
 documented as part of libnetwork:
-[https://github.com/moby/moby/blob/master/libnetwork/docs/remote.md](https://github.com/moby/moby/blob/master/libnetwork/docs/remote.md).
-
-## Related Information
-
-To interact with the Docker maintainers and other interested users, see the IRC channel `#docker-network`.
-
-- [Docker networks feature overview](https://docs.docker.com/engine/userguide/networking/)
-- The [LibNetwork](https://github.com/docker/libnetwork) project
+[https://github.com/moby/moby/blob/master/daemon/libnetwork/docs/remote.md](https://github.com/moby/moby/blob/master/daemon/libnetwork/docs/remote.md).
diff --git a/_vendor/github.com/docker/cli/docs/extend/plugins_services.md b/_vendor/github.com/docker/cli/docs/extend/plugins_services.md
index f0c2dc503ddc..fb914047b80d 100644
--- a/_vendor/github.com/docker/cli/docs/extend/plugins_services.md
+++ b/_vendor/github.com/docker/cli/docs/extend/plugins_services.md
@@ -38,7 +38,7 @@ node1 is the manager and node2 is the worker.
 
     ```console
     $ docker swarm join \
-      --token SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c \
+      --token SWMTKN-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233... \
       192.168.99.100:2377
     ```
 
diff --git a/_vendor/github.com/docker/cli/docs/extend/plugins_volume.md b/_vendor/github.com/docker/cli/docs/extend/plugins_volume.md
index 8da7deb742c9..688350f6231b 100644
--- a/_vendor/github.com/docker/cli/docs/extend/plugins_volume.md
+++ b/_vendor/github.com/docker/cli/docs/extend/plugins_volume.md
@@ -45,7 +45,7 @@ accepts a volume name and path on the host, and the `--volume-driver` flag
 accepts a driver type.
 
 ```console
-$ docker volume create --driver=flocker volumename
+$ docker volume create --driver=myplugin volumename
 
 $ docker container run -it --volume volumename:/data busybox sh
 ```
@@ -61,11 +61,18 @@ separated by a colon (`:`) character.
 - The `Mountpoint` is the path on the host (v1) or in the plugin (v2) where the
   volume has been made available.
 
-### `volumedriver`
+### `--volume-driver`
 
-Specifying a `volumedriver` in conjunction with a `volumename` allows you to
-use plugins such as [Flocker](https://github.com/ScatterHQ/flocker) to manage
-volumes external to a single host, such as those on EBS.
+Specifying the `--volume-driver` flag together with a volume name (using
+`--volume`) allows you to use plugins to manage volumes for the container.
+
+The `--volume-driver` flag is used as a default for all volumes created for
+the container, including anonymous volumes. Use the [`--mount`] flag with
+the [`volume-driver`] option to specify the driver to use for each volume
+individually.
+
+[`--mount`]: https://docs.docker.com/reference/cli/docker/container/run/#mount
+[`volume-driver`]: https://docs.docker.com/engine/storage/volumes/#start-a-container-which-creates-a-volume-using-a-volume-driver
 
 ## Create a VolumeDriver
 
diff --git a/_vendor/github.com/docker/cli/docs/reference/dockerd.md b/_vendor/github.com/docker/cli/docs/reference/dockerd.md
index b55b66c30b1d..1dcb19162654 100644
--- a/_vendor/github.com/docker/cli/docs/reference/dockerd.md
+++ b/_vendor/github.com/docker/cli/docs/reference/dockerd.md
@@ -24,10 +24,12 @@ A self-sufficient runtime for containers.
 
 Options:
       --add-runtime runtime                   Register an additional OCI compatible runtime (default [])
+      --allow-direct-routing                  Allow remote access to published ports on container IP addresses
       --authorization-plugin list             Authorization plugins to load
       --bip string                            IPv4 address for the default bridge
       --bip6 string                           IPv6 address for the default bridge
   -b, --bridge string                         Attach containers to a network bridge
+      --bridge-accept-fwmark string           In bridge networks, accept packets with this firewall mark/mask
       --cdi-spec-dir list                     CDI specification directories to use
       --cgroup-parent string                  Set parent cgroup for all containers
       --config-file string                    Daemon configuration file (default "/etc/docker/daemon.json")
@@ -57,6 +59,7 @@ Options:
       --exec-root string                      Root directory for execution state files (default "/var/run/docker")
       --experimental                          Enable experimental features
       --feature map                           Enable feature in the daemon
+      --firewall-backend string               Firewall backend to use, iptables or nftables
       --fixed-cidr string                     IPv4 subnet for the default bridge network
       --fixed-cidr-v6 string                  IPv6 subnet for the default bridge network
   -G, --group string                          Group for the unix socket (default "docker")
@@ -607,7 +610,7 @@ $ sudo dockerd --add-runtime <runtime>=<path>
 
 Defining runtime arguments via the command line is not supported.
 
-For an example configuration for a runc drop-in replacment, see
+For an example configuration for a runc drop-in replacement, see
 [Alternative container runtimes > youki](https://docs.docker.com/engine/daemon/alternative-runtimes/#youki)
 
 ##### Configure the default container runtime
@@ -839,42 +842,49 @@ $ docker run -it --add-host host.docker.internal:host-gateway \
 PING host.docker.internal (2001:db8::1111): 56 data bytes
 ```
 
-### Enable CDI devices
-
-> [!NOTE]
-> This is experimental feature and as such doesn't represent a stable API.
->
-> This feature isn't enabled by default. To this feature, set `features.cdi` to
-> `true` in the `daemon.json` configuration file.
+### Configure CDI devices
 
 Container Device Interface (CDI) is a
 [standardized](https://github.com/cncf-tags/container-device-interface/blob/main/SPEC.md)
 mechanism for container runtimes to create containers which are able to
 interact with third party devices.
 
+CDI is currently only supported for Linux containers and is enabled by default
+since Docker Engine 28.3.0.
+
 The Docker daemon supports running containers with CDI devices if the requested
 device specifications are available on the filesystem of the daemon.
 
-The default specification directors are:
+The default specification directories are:
 
 - `/etc/cdi/` for static CDI Specs
 - `/var/run/cdi` for generated CDI Specs
 
-Alternatively, you can set custom locations for CDI specifications using the
+#### Set custom locations
+
+To set custom locations for CDI specifications, use the
 `cdi-spec-dirs` option in the `daemon.json` configuration file, or the
-`--cdi-spec-dir` flag for the `dockerd` CLI.
+`--cdi-spec-dir` flag for the `dockerd` CLI:
 
 ```json
 {
-  "features": {
-     "cdi": true
-  },
   "cdi-spec-dirs": ["/etc/cdi/", "/var/run/cdi"]
 }
 ```
 
-When CDI is enabled for a daemon, you can view the configured CDI specification
-directories using the `docker info` command.
+You can view the configured CDI specification directories using the `docker info` command.
+
+#### Disable CDI devices
+
+The feature in enabled by default. To disable it, use the `cdi` options in the `daemon.json` file:
+
+```json
+"features": {
+  "cdi": false
+},
+```
+
+To check the status of the CDI devices, run `docker info`.
 
 #### Daemon logging format {#log-format}
 
@@ -948,8 +958,6 @@ the `--cgroup-parent` option on the daemon.
 #### Daemon metrics
 
 The `--metrics-addr` option takes a TCP address to serve the metrics API.
-This feature is still experimental, therefore, the daemon must be running in experimental
-mode for this feature to work.
 
 To serve the metrics API on `localhost:9323` you would specify `--metrics-addr 127.0.0.1:9323`,
 allowing you to make requests on the API at `127.0.0.1:9323/metrics` to receive metrics in the
@@ -1049,26 +1057,28 @@ $ echo $?
 
 ##### On Linux
 
-The default location of the configuration file on Linux is
-`/etc/docker/daemon.json`. Use the `--config-file` flag to specify a
-non-default location.
+The default location of the configuration file on Linux is `/etc/docker/daemon.json`.
+If the file does not exist, you need to create it first. Use the `--config-file`
+flag to specify a non-default location.
 
 The following is a full example of the allowed configuration options on Linux:
 
 ```json
 {
+  "allow-direct-routing": false,
   "authorization-plugins": [],
   "bip": "",
   "bip6": "",
   "bridge": "",
+  "bridge-accept-fwmark": "",
   "builder": {
     "gc": {
       "enabled": true,
-      "defaultKeepStorage": "10GB",
+      "defaultReservedSpace": "10GB",
       "policy": [
-        { "keepStorage": "10GB", "filter": ["unused-for=2200h"] },
-        { "keepStorage": "50GB", "filter": ["unused-for=3300h"] },
-        { "keepStorage": "100GB", "all": true }
+        { "maxUsedSpace": "512MB", "keepDuration": "48h", "filter": [ "type=source.local" ] },
+        { "reservedSpace": "10GB", "maxUsedSpace": "100GB", "keepDuration": "1440h" },
+        { "reservedSpace": "50GB", "minFreeSpace": "20GB", "maxUsedSpace": "200GB", "all": true }
       ]
     }
   },
@@ -1111,6 +1121,7 @@ The following is a full example of the allowed configuration options on Linux:
     "cdi": true,
     "containerd-snapshotter": true
   },
+  "firewall-backend": "",
   "fixed-cidr": "",
   "fixed-cidr-v6": "",
   "group": "",
@@ -1197,8 +1208,9 @@ The following is a full example of the allowed configuration options on Linux:
 ##### On Windows
 
 The default location of the configuration file on Windows is
-`%programdata%\docker\config\daemon.json`. Use the `--config-file` flag
-to specify a non-default location.
+`%programdata%\docker\config\daemon.json`. If the file does not exist, you need
+to create it first. Use the `--config-file` flag to specify a non-default
+location.
 
 The following is a full example of the allowed configuration options on Windows:
 
@@ -1300,7 +1312,7 @@ The list of currently supported options that can be reconfigured is this:
 | ---------------------------------- | ----------------------------------------------------------------------------------------------------------- |
 | `debug`                            | Toggles debug mode of the daemon.                                                                           |
 | `labels`                           | Replaces the daemon labels with a new set of labels.                                                        |
-| `live-restore`                     | Toggles [live restore](https://docs.docker.com/engine/containers/live-restore/).                            |
+| `live-restore`                     | Toggles [live restore](https://docs.docker.com/engine/daemon/live-restore/).                                |
 | `max-concurrent-downloads`         | Configures the max concurrent downloads for each pull.                                                      |
 | `max-concurrent-uploads`           | Configures the max concurrent uploads for each push.                                                        |
 | `max-download-attempts`            | Configures the max download attempts for each pull.                                                         |
diff --git a/_vendor/github.com/docker/cli/docs/reference/run.md b/_vendor/github.com/docker/cli/docs/reference/run.md
index db06ad71f669..4824233685c9 100644
--- a/_vendor/github.com/docker/cli/docs/reference/run.md
+++ b/_vendor/github.com/docker/cli/docs/reference/run.md
@@ -248,10 +248,18 @@ $ docker run -it --mount type=bind,source=[PATH],target=[PATH] busybox
 ```
 
 In this case, the `--mount` flag takes three parameters. A type (`bind`), and
-two paths. The `source` path is a the location on the host that you want to
+two paths. The `source` path is the location on the host that you want to
 bind mount into the container. The `target` path is the mount destination
 inside the container.
 
+By default, bind mounts require the source path to exist on the daemon host. If the
+source path doesn't exist, an error is returned. To create the source path on
+the daemon host if it doesn't exist, use the `bind-create-src` option:
+
+```console
+$ docker run -it --mount type=bind,source=[PATH],target=[PATH],bind-create-src busybox
+```
+
 Bind mounts are read-write by default, meaning that you can both read and write
 files to and from the mounted location from the container. Changes that you
 make, such as adding or editing files, are reflected on the host filesystem:
@@ -326,7 +334,6 @@ container:
 | `-m`, `--memory=""`        | Memory limit (format: `<number>[<unit>]`). Number is a positive integer. Unit can be one of `b`, `k`, `m`, or `g`. Minimum is 6M.                                                                                                                                                        |
 | `--memory-swap=""`         | Total memory limit (memory + swap, format: `<number>[<unit>]`). Number is a positive integer. Unit can be one of `b`, `k`, `m`, or `g`.                                                                                                                                                  |
 | `--memory-reservation=""`  | Memory soft limit (format: `<number>[<unit>]`). Number is a positive integer. Unit can be one of `b`, `k`, `m`, or `g`.                                                                                                                                                                  |
-| `--kernel-memory=""`       | Kernel memory limit (format: `<number>[<unit>]`). Number is a positive integer. Unit can be one of `b`, `k`, `m`, or `g`. Minimum is 4M.                                                                                                                                                 |
 | `-c`, `--cpu-shares=0`     | CPU shares (relative weight)                                                                                                                                                                                                                                                             |
 | `--cpus=0.000`             | Number of CPUs. Number is a fractional number. 0.000 means no limit.                                                                                                                                                                                                                     |
 | `--cpu-period=0`           | Limit the CPU CFS (Completely Fair Scheduler) period                                                                                                                                                                                                                                     |
@@ -419,7 +426,7 @@ $ docker run -it -m 300M ubuntu:24.04 /bin/bash
 
 We set memory limit only, this means the processes in the container can use
 300M memory and 300M swap memory, by default, the total virtual memory size
-(--memory-swap) will be set as double of memory, in this case, memory + swap
+(`--memory-swap`) will be set as double of memory, in this case, memory + swap
 would be 2*300M, so processes can use 300M swap memory as well.
 
 ```console
@@ -492,80 +499,6 @@ parameter can be changed to select the priority of which containers will
 be killed when the system is out of memory, with negative scores making them
 less likely to be killed, and positive scores more likely.
 
-### Kernel memory constraints
-
-Kernel memory is fundamentally different than user memory as kernel memory can't
-be swapped out. The inability to swap makes it possible for the container to
-block system services by consuming too much kernel memory. Kernel memory includes：
-
- - stack pages
- - slab pages
- - sockets memory pressure
- - tcp memory pressure
-
-You can setup kernel memory limit to constrain these kinds of memory. For example,
-every process consumes some stack pages. By limiting kernel memory, you can
-prevent new processes from being created when the kernel memory usage is too high.
-
-Kernel memory is never completely independent of user memory. Instead, you limit
-kernel memory in the context of the user memory limit. Assume "U" is the user memory
-limit and "K" the kernel limit. There are three possible ways to set limits:
-
-<table>
-  <thead>
-    <tr>
-      <th>Option</th>
-      <th>Result</th>
-    </tr>
-  </thead>
-  <tbody>
-    <tr>
-      <td class="no-wrap"><strong>U != 0, K = inf</strong> (default)</td>
-      <td>
-        This is the standard memory limitation mechanism already present before using
-        kernel memory. Kernel memory is completely ignored.
-      </td>
-    </tr>
-    <tr>
-      <td class="no-wrap"><strong>U != 0, K &lt; U</strong></td>
-      <td>
-        Kernel memory is a subset of the user memory. This setup is useful in
-        deployments where the total amount of memory per-cgroup is overcommitted.
-        Overcommitting kernel memory limits is definitely not recommended, since the
-        box can still run out of non-reclaimable memory.
-        In this case, you can configure K so that the sum of all groups is
-        never greater than the total memory. Then, freely set U at the expense of
-        the system's service quality.
-      </td>
-    </tr>
-    <tr>
-      <td class="no-wrap"><strong>U != 0, K &gt; U</strong></td>
-      <td>
-        Since kernel memory charges are also fed to the user counter and reclamation
-        is triggered for the container for both kinds of memory. This configuration
-        gives the admin a unified view of memory. It is also useful for people
-        who just want to track kernel memory usage.
-      </td>
-    </tr>
-  </tbody>
-</table>
-
-Examples:
-
-```console
-$ docker run -it -m 500M --kernel-memory 50M ubuntu:24.04 /bin/bash
-```
-
-We set memory and kernel memory, so the processes in the container can use
-500M memory in total, in this 500M memory, it can be 50M kernel memory tops.
-
-```console
-$ docker run -it --kernel-memory 50M ubuntu:24.04 /bin/bash
-```
-
-We set kernel memory without **-m**, so the processes in the container can
-use as much memory as they want, but they can only use 50M kernel memory.
-
 ### Swappiness constraint
 
 By default, a container's kernel can swap out a percentage of anonymous pages.
@@ -1087,7 +1020,7 @@ Additionally, you can set any environment variable in the container by using
 one or more `-e` flags. You can even override the variables mentioned above, or
 variables defined using a Dockerfile `ENV` instruction when building the image.
 
-If the you name an environment variable without specifying a value, the current
+If you name an environment variable without specifying a value, the current
 value of the named variable on the host is propagated into the container's
 environment:
 
@@ -1214,7 +1147,7 @@ starting a container, you can override the `USER` instruction by passing the
 -u="", --user="": Sets the username or UID used and optionally the groupname or GID for the specified command.
 ```
 
-The followings examples are all valid:
+The following examples are all valid:
 
 ```text
 --user=[ user | user:group | uid | uid:gid | user:gid | uid:group ]
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose.md b/_vendor/github.com/docker/compose/v2/docs/reference/compose.md
deleted file mode 100644
index d1a1c2a46272..000000000000
--- a/_vendor/github.com/docker/compose/v2/docs/reference/compose.md
+++ /dev/null
@@ -1,210 +0,0 @@
-# docker compose
-
-```text
-docker compose [-f <arg>...] [options] [COMMAND] [ARGS...]
-```
-
-<!---MARKER_GEN_START-->
-Define and run multi-container applications with Docker
-
-### Subcommands
-
-| Name                            | Description                                                                             |
-|:--------------------------------|:----------------------------------------------------------------------------------------|
-| [`attach`](compose_attach.md)   | Attach local standard input, output, and error streams to a service's running container |
-| [`build`](compose_build.md)     | Build or rebuild services                                                               |
-| [`commit`](compose_commit.md)   | Create a new image from a service container's changes                                   |
-| [`config`](compose_config.md)   | Parse, resolve and render compose file in canonical format                              |
-| [`cp`](compose_cp.md)           | Copy files/folders between a service container and the local filesystem                 |
-| [`create`](compose_create.md)   | Creates containers for a service                                                        |
-| [`down`](compose_down.md)       | Stop and remove containers, networks                                                    |
-| [`events`](compose_events.md)   | Receive real time events from containers                                                |
-| [`exec`](compose_exec.md)       | Execute a command in a running container                                                |
-| [`export`](compose_export.md)   | Export a service container's filesystem as a tar archive                                |
-| [`images`](compose_images.md)   | List images used by the created containers                                              |
-| [`kill`](compose_kill.md)       | Force stop service containers                                                           |
-| [`logs`](compose_logs.md)       | View output from containers                                                             |
-| [`ls`](compose_ls.md)           | List running compose projects                                                           |
-| [`pause`](compose_pause.md)     | Pause services                                                                          |
-| [`port`](compose_port.md)       | Print the public port for a port binding                                                |
-| [`ps`](compose_ps.md)           | List containers                                                                         |
-| [`publish`](compose_publish.md) | Publish compose application                                                             |
-| [`pull`](compose_pull.md)       | Pull service images                                                                     |
-| [`push`](compose_push.md)       | Push service images                                                                     |
-| [`restart`](compose_restart.md) | Restart service containers                                                              |
-| [`rm`](compose_rm.md)           | Removes stopped service containers                                                      |
-| [`run`](compose_run.md)         | Run a one-off command on a service                                                      |
-| [`scale`](compose_scale.md)     | Scale services                                                                          |
-| [`start`](compose_start.md)     | Start services                                                                          |
-| [`stats`](compose_stats.md)     | Display a live stream of container(s) resource usage statistics                         |
-| [`stop`](compose_stop.md)       | Stop services                                                                           |
-| [`top`](compose_top.md)         | Display the running processes                                                           |
-| [`unpause`](compose_unpause.md) | Unpause services                                                                        |
-| [`up`](compose_up.md)           | Create and start containers                                                             |
-| [`version`](compose_version.md) | Show the Docker Compose version information                                             |
-| [`wait`](compose_wait.md)       | Block until containers of all (or specified) services stop.                             |
-| [`watch`](compose_watch.md)     | Watch build context for service and rebuild/refresh containers when files are updated   |
-
-
-### Options
-
-| Name                   | Type          | Default | Description                                                                                         |
-|:-----------------------|:--------------|:--------|:----------------------------------------------------------------------------------------------------|
-| `--all-resources`      | `bool`        |         | Include all resources, even those not used by services                                              |
-| `--ansi`               | `string`      | `auto`  | Control when to print ANSI control characters ("never"\|"always"\|"auto")                           |
-| `--compatibility`      | `bool`        |         | Run compose in backward compatibility mode                                                          |
-| `--dry-run`            | `bool`        |         | Execute command in dry run mode                                                                     |
-| `--env-file`           | `stringArray` |         | Specify an alternate environment file                                                               |
-| `-f`, `--file`         | `stringArray` |         | Compose configuration files                                                                         |
-| `--parallel`           | `int`         | `-1`    | Control max parallelism, -1 for unlimited                                                           |
-| `--profile`            | `stringArray` |         | Specify a profile to enable                                                                         |
-| `--progress`           | `string`      | `auto`  | Set type of progress output (auto, tty, plain, json, quiet)                                         |
-| `--project-directory`  | `string`      |         | Specify an alternate working directory<br>(default: the path of the, first specified, Compose file) |
-| `-p`, `--project-name` | `string`      |         | Project name                                                                                        |
-
-
-<!---MARKER_GEN_END-->
-
-## Examples
-
-### Use `-f` to specify the name and path of one or more Compose files
-Use the `-f` flag to specify the location of a Compose [configuration file](/reference/compose-file/).
-
-#### Specifying multiple Compose files
-You can supply multiple `-f` configuration files. When you supply multiple files, Compose combines them into a single
-configuration. Compose builds the configuration in the order you supply the files. Subsequent files override and add
-to their predecessors.
-
-For example, consider this command line:
-
-```console
-$ docker compose -f compose.yaml -f compose.admin.yaml run backup_db
-```
-
-The `compose.yaml` file might specify a `webapp` service.
-
-```yaml
-services:
-  webapp:
-    image: examples/web
-    ports:
-      - "8000:8000"
-    volumes:
-      - "/data"
-```
-If the `compose.admin.yaml` also specifies this same service, any matching fields override the previous file.
-New values, add to the `webapp` service configuration.
-
-```yaml
-services:
-  webapp:
-    build: .
-    environment:
-      - DEBUG=1
-```
-
-When you use multiple Compose files, all paths in the files are relative to the first configuration file specified
-with `-f`. You can use the `--project-directory` option to override this base path.
-
-Use a `-f` with `-` (dash) as the filename to read the configuration from stdin. When stdin is used all paths in the
-configuration are relative to the current working directory.
-
-The `-f` flag is optional. If you don’t provide this flag on the command line, Compose traverses the working directory
-and its parent directories looking for a `compose.yaml` or `docker-compose.yaml` file.
-
-#### Specifying a path to a single Compose file
-You can use the `-f` flag to specify a path to a Compose file that is not located in the current directory, either
-from the command line or by setting up a `COMPOSE_FILE` environment variable in your shell or in an environment file.
-
-For an example of using the `-f` option at the command line, suppose you are running the Compose Rails sample, and
-have a `compose.yaml` file in a directory called `sandbox/rails`. You can use a command like `docker compose pull` to
-get the postgres image for the db service from anywhere by using the `-f` flag as follows:
-
-```console
-$ docker compose -f ~/sandbox/rails/compose.yaml pull db
-```
-
-### Use `-p` to specify a project name
-
-Each configuration has a project name. Compose sets the project name using
-the following mechanisms, in order of precedence:
-- The `-p` command line flag
-- The `COMPOSE_PROJECT_NAME` environment variable
-- The top level `name:` variable from the config file (or the last `name:`
-from a series of config files specified using `-f`)
-- The `basename` of the project directory containing the config file (or
-containing the first config file specified using `-f`)
-- The `basename` of the current directory if no config file is specified
-Project names must contain only lowercase letters, decimal digits, dashes,
-and underscores, and must begin with a lowercase letter or decimal digit. If
-the `basename` of the project directory or current directory violates this
-constraint, you must use one of the other mechanisms.
-
-```console
-$ docker compose -p my_project ps -a
-NAME                 SERVICE    STATUS     PORTS
-my_project_demo_1    demo       running
-
-$ docker compose -p my_project logs
-demo_1  | PING localhost (127.0.0.1): 56 data bytes
-demo_1  | 64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.095 ms
-```
-
-### Use profiles to enable optional services
-
-Use `--profile` to specify one or more active profiles
-Calling `docker compose --profile frontend up` starts the services with the profile `frontend` and services
-without any specified profiles.
-You can also enable multiple profiles, e.g. with `docker compose --profile frontend --profile debug up` the profiles `frontend` and `debug` is enabled.
-
-Profiles can also be set by `COMPOSE_PROFILES` environment variable.
-
-### Configuring parallelism
-
-Use `--parallel` to specify the maximum level of parallelism for concurrent engine calls.
-Calling `docker compose --parallel 1 pull` pulls the pullable images defined in the Compose file
-one at a time. This can also be used to control build concurrency.
-
-Parallelism can also be set by the `COMPOSE_PARALLEL_LIMIT` environment variable.
-
-### Set up environment variables
-
-You can set environment variables for various docker compose options, including the `-f`, `-p` and `--profiles` flags.
-
-Setting the `COMPOSE_FILE` environment variable is equivalent to passing the `-f` flag,
-`COMPOSE_PROJECT_NAME` environment variable does the same as the `-p` flag,
-`COMPOSE_PROFILES` environment variable is equivalent to the `--profiles` flag
-and `COMPOSE_PARALLEL_LIMIT` does the same as the `--parallel` flag.
-
-If flags are explicitly set on the command line, the associated environment variable is ignored.
-
-Setting the `COMPOSE_IGNORE_ORPHANS` environment variable to `true` stops docker compose from detecting orphaned
-containers for the project.
-
-Setting the `COMPOSE_MENU` environment variable to `false` disables the helper menu when running `docker compose up`
-in attached mode. Alternatively, you can also run `docker compose up --menu=false` to disable the helper menu.
-
-### Use Dry Run mode to test your command
-
-Use `--dry-run` flag to test a command without changing your application stack state.
-Dry Run mode shows you all the steps Compose applies when executing a command, for example:
-```console
-$ docker compose --dry-run up --build -d
-[+] Pulling 1/1
- ✔ DRY-RUN MODE -  db Pulled                                                                                                                                                                                                               0.9s
-[+] Running 10/8
- ✔ DRY-RUN MODE -    build service backend                                                                                                                                                                                                 0.0s
- ✔ DRY-RUN MODE -  ==> ==> writing image dryRun-754a08ddf8bcb1cf22f310f09206dd783d42f7dd                                                                                                                                                   0.0s
- ✔ DRY-RUN MODE -  ==> ==> naming to nginx-golang-mysql-backend                                                                                                                                                                            0.0s
- ✔ DRY-RUN MODE -  Network nginx-golang-mysql_default                                    Created                                                                                                                                           0.0s
- ✔ DRY-RUN MODE -  Container nginx-golang-mysql-db-1                                     Created                                                                                                                                           0.0s
- ✔ DRY-RUN MODE -  Container nginx-golang-mysql-backend-1                                Created                                                                                                                                           0.0s
- ✔ DRY-RUN MODE -  Container nginx-golang-mysql-proxy-1                                  Created                                                                                                                                           0.0s
- ✔ DRY-RUN MODE -  Container nginx-golang-mysql-db-1                                     Healthy                                                                                                                                           0.5s
- ✔ DRY-RUN MODE -  Container nginx-golang-mysql-backend-1                                Started                                                                                                                                           0.0s
- ✔ DRY-RUN MODE -  Container nginx-golang-mysql-proxy-1                                  Started                                     Started
-```
-From the example above, you can see that the first step is to pull the image defined by `db` service, then build the `backend` service.  
-Next, the containers are created. The `db` service is started, and the `backend` and `proxy` wait until the `db` service is healthy before starting.
-
-Dry Run mode works with almost all commands. You cannot use Dry Run mode with a command that doesn't change the state of a Compose stack such as `ps`, `ls`, `logs` for example.
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_events.md b/_vendor/github.com/docker/compose/v2/docs/reference/compose_events.md
deleted file mode 100644
index b71f4c993d50..000000000000
--- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_events.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# docker compose events
-
-<!---MARKER_GEN_START-->
-Stream container events for every container in the project.
-
-With the `--json` flag, a json object is printed one per line with the format:
-
-```json
-{
-    "time": "2015-11-20T18:01:03.615550",
-    "type": "container",
-    "action": "create",
-    "id": "213cf7...5fc39a",
-    "service": "web",
-    "attributes": {
-      "name": "application_web_1",
-      "image": "alpine:edge"
-    }
-}
-```
-
-The events that can be received using this can be seen [here](/reference/cli/docker/system/events/#object-types).
-
-### Options
-
-| Name        | Type   | Default | Description                               |
-|:------------|:-------|:--------|:------------------------------------------|
-| `--dry-run` | `bool` |         | Execute command in dry run mode           |
-| `--json`    | `bool` |         | Output events as a stream of json objects |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-Stream container events for every container in the project.
-
-With the `--json` flag, a json object is printed one per line with the format:
-
-```json
-{
-    "time": "2015-11-20T18:01:03.615550",
-    "type": "container",
-    "action": "create",
-    "id": "213cf7...5fc39a",
-    "service": "web",
-    "attributes": {
-      "name": "application_web_1",
-      "image": "alpine:edge"
-    }
-}
-```
-
-The events that can be received using this can be seen [here](https://docs.docker.com/reference/cli/docker/system/events/#object-types).
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_exec.md b/_vendor/github.com/docker/compose/v2/docs/reference/compose_exec.md
deleted file mode 100644
index 8b54def472e9..000000000000
--- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_exec.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# docker compose exec
-
-<!---MARKER_GEN_START-->
-This is the equivalent of `docker exec` targeting a Compose service.
-
-With this subcommand, you can run arbitrary commands in your services. Commands allocate a TTY by default, so
-you can use a command such as `docker compose exec web sh` to get an interactive prompt.
-
-### Options
-
-| Name              | Type          | Default | Description                                                                      |
-|:------------------|:--------------|:--------|:---------------------------------------------------------------------------------|
-| `-d`, `--detach`  | `bool`        |         | Detached mode: Run command in the background                                     |
-| `--dry-run`       | `bool`        |         | Execute command in dry run mode                                                  |
-| `-e`, `--env`     | `stringArray` |         | Set environment variables                                                        |
-| `--index`         | `int`         | `0`     | Index of the container if service has multiple replicas                          |
-| `-T`, `--no-TTY`  | `bool`        | `true`  | Disable pseudo-TTY allocation. By default `docker compose exec` allocates a TTY. |
-| `--privileged`    | `bool`        |         | Give extended privileges to the process                                          |
-| `-u`, `--user`    | `string`      |         | Run the command as this user                                                     |
-| `-w`, `--workdir` | `string`      |         | Path to workdir directory for this command                                       |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-This is the equivalent of `docker exec` targeting a Compose service.
-
-With this subcommand, you can run arbitrary commands in your services. Commands allocate a TTY by default, so
-you can use a command such as `docker compose exec web sh` to get an interactive prompt.
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_logs.md b/_vendor/github.com/docker/compose/v2/docs/reference/compose_logs.md
deleted file mode 100644
index 4c8ba7e34867..000000000000
--- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_logs.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# docker compose logs
-
-<!---MARKER_GEN_START-->
-Displays log output from services
-
-### Options
-
-| Name                 | Type     | Default | Description                                                                                    |
-|:---------------------|:---------|:--------|:-----------------------------------------------------------------------------------------------|
-| `--dry-run`          | `bool`   |         | Execute command in dry run mode                                                                |
-| `-f`, `--follow`     | `bool`   |         | Follow log output                                                                              |
-| `--index`            | `int`    | `0`     | index of the container if service has multiple replicas                                        |
-| `--no-color`         | `bool`   |         | Produce monochrome output                                                                      |
-| `--no-log-prefix`    | `bool`   |         | Don't print prefix in logs                                                                     |
-| `--since`            | `string` |         | Show logs since timestamp (e.g. 2013-01-02T13:23:37Z) or relative (e.g. 42m for 42 minutes)    |
-| `-n`, `--tail`       | `string` | `all`   | Number of lines to show from the end of the logs for each container                            |
-| `-t`, `--timestamps` | `bool`   |         | Show timestamps                                                                                |
-| `--until`            | `string` |         | Show logs before a timestamp (e.g. 2013-01-02T13:23:37Z) or relative (e.g. 42m for 42 minutes) |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-Displays log output from services
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_start.md b/_vendor/github.com/docker/compose/v2/docs/reference/compose_start.md
deleted file mode 100644
index 08db7ef2135a..000000000000
--- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_start.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# docker compose start
-
-<!---MARKER_GEN_START-->
-Starts existing containers for a service
-
-### Options
-
-| Name        | Type   | Default | Description                     |
-|:------------|:-------|:--------|:--------------------------------|
-| `--dry-run` | `bool` |         | Execute command in dry run mode |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-Starts existing containers for a service
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_events.yaml b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_events.yaml
deleted file mode 100644
index fe6d4216ce1f..000000000000
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_events.yaml
+++ /dev/null
@@ -1,54 +0,0 @@
-command: docker compose events
-short: Receive real time events from containers
-long: |-
-    Stream container events for every container in the project.
-
-    With the `--json` flag, a json object is printed one per line with the format:
-
-    ```json
-    {
-        "time": "2015-11-20T18:01:03.615550",
-        "type": "container",
-        "action": "create",
-        "id": "213cf7...5fc39a",
-        "service": "web",
-        "attributes": {
-          "name": "application_web_1",
-          "image": "alpine:edge"
-        }
-    }
-    ```
-
-    The events that can be received using this can be seen [here](/reference/cli/docker/system/events/#object-types).
-usage: docker compose events [OPTIONS] [SERVICE...]
-pname: docker compose
-plink: docker_compose.yaml
-options:
-    - option: json
-      value_type: bool
-      default_value: "false"
-      description: Output events as a stream of json objects
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: dry-run
-      value_type: bool
-      default_value: "false"
-      description: Execute command in dry run mode
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_start.yaml b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_start.yaml
deleted file mode 100644
index 902b688d3e7c..000000000000
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_start.yaml
+++ /dev/null
@@ -1,24 +0,0 @@
-command: docker compose start
-short: Start services
-long: Starts existing containers for a service
-usage: docker compose start [SERVICE...]
-pname: docker compose
-plink: docker_compose.yaml
-inherited_options:
-    - option: dry-run
-      value_type: bool
-      default_value: "false"
-      description: Execute command in dry run mode
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/compose.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose.md
new file mode 100644
index 000000000000..d80bb86ec626
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose.md
@@ -0,0 +1,264 @@
+
+# docker compose
+
+```text
+docker compose [-f <arg>...] [options] [COMMAND] [ARGS...]
+```
+
+<!---MARKER_GEN_START-->
+Define and run multi-container applications with Docker
+
+### Subcommands
+
+| Name                            | Description                                                                             |
+|:--------------------------------|:----------------------------------------------------------------------------------------|
+| [`attach`](compose_attach.md)   | Attach local standard input, output, and error streams to a service's running container |
+| [`bridge`](compose_bridge.md)   | Convert compose files into another model                                                |
+| [`build`](compose_build.md)     | Build or rebuild services                                                               |
+| [`commit`](compose_commit.md)   | Create a new image from a service container's changes                                   |
+| [`config`](compose_config.md)   | Parse, resolve and render compose file in canonical format                              |
+| [`cp`](compose_cp.md)           | Copy files/folders between a service container and the local filesystem                 |
+| [`create`](compose_create.md)   | Creates containers for a service                                                        |
+| [`down`](compose_down.md)       | Stop and remove containers, networks                                                    |
+| [`events`](compose_events.md)   | Receive real time events from containers                                                |
+| [`exec`](compose_exec.md)       | Execute a command in a running container                                                |
+| [`export`](compose_export.md)   | Export a service container's filesystem as a tar archive                                |
+| [`images`](compose_images.md)   | List images used by the created containers                                              |
+| [`kill`](compose_kill.md)       | Force stop service containers                                                           |
+| [`logs`](compose_logs.md)       | View output from containers                                                             |
+| [`ls`](compose_ls.md)           | List running compose projects                                                           |
+| [`pause`](compose_pause.md)     | Pause services                                                                          |
+| [`port`](compose_port.md)       | Print the public port for a port binding                                                |
+| [`ps`](compose_ps.md)           | List containers                                                                         |
+| [`publish`](compose_publish.md) | Publish compose application                                                             |
+| [`pull`](compose_pull.md)       | Pull service images                                                                     |
+| [`push`](compose_push.md)       | Push service images                                                                     |
+| [`restart`](compose_restart.md) | Restart service containers                                                              |
+| [`rm`](compose_rm.md)           | Removes stopped service containers                                                      |
+| [`run`](compose_run.md)         | Run a one-off command on a service                                                      |
+| [`scale`](compose_scale.md)     | Scale services                                                                          |
+| [`start`](compose_start.md)     | Start services                                                                          |
+| [`stats`](compose_stats.md)     | Display a live stream of container(s) resource usage statistics                         |
+| [`stop`](compose_stop.md)       | Stop services                                                                           |
+| [`top`](compose_top.md)         | Display the running processes                                                           |
+| [`unpause`](compose_unpause.md) | Unpause services                                                                        |
+| [`up`](compose_up.md)           | Create and start containers                                                             |
+| [`version`](compose_version.md) | Show the Docker Compose version information                                             |
+| [`volumes`](compose_volumes.md) | List volumes                                                                            |
+| [`wait`](compose_wait.md)       | Block until containers of all (or specified) services stop.                             |
+| [`watch`](compose_watch.md)     | Watch build context for service and rebuild/refresh containers when files are updated   |
+
+
+### Options
+
+| Name                   | Type          | Default | Description                                                                                         |
+|:-----------------------|:--------------|:--------|:----------------------------------------------------------------------------------------------------|
+| `--all-resources`      | `bool`        |         | Include all resources, even those not used by services                                              |
+| `--ansi`               | `string`      | `auto`  | Control when to print ANSI control characters ("never"\|"always"\|"auto")                           |
+| `--compatibility`      | `bool`        |         | Run compose in backward compatibility mode                                                          |
+| `--dry-run`            | `bool`        |         | Execute command in dry run mode                                                                     |
+| `--env-file`           | `stringArray` |         | Specify an alternate environment file                                                               |
+| `-f`, `--file`         | `stringArray` |         | Compose configuration files                                                                         |
+| `--parallel`           | `int`         | `-1`    | Control max parallelism, -1 for unlimited                                                           |
+| `--profile`            | `stringArray` |         | Specify a profile to enable                                                                         |
+| `--progress`           | `string`      |         | Set type of progress output (auto, tty, plain, json, quiet)                                         |
+| `--project-directory`  | `string`      |         | Specify an alternate working directory<br>(default: the path of the, first specified, Compose file) |
+| `-p`, `--project-name` | `string`      |         | Project name                                                                                        |
+
+
+<!---MARKER_GEN_END-->
+
+## Examples
+
+### Use `-f` to specify the name and path of one or more Compose files
+Use the `-f` flag to specify the location of a Compose [configuration file](/reference/compose-file/).
+
+#### Specifying multiple Compose files
+You can supply multiple `-f` configuration files. When you supply multiple files, Compose combines them into a single
+configuration. Compose builds the configuration in the order you supply the files. Subsequent files override and add
+to their predecessors.
+
+For example, consider this command line:
+
+```console
+$ docker compose -f compose.yaml -f compose.admin.yaml run backup_db
+```
+
+The `compose.yaml` file might specify a `webapp` service.
+
+```yaml
+services:
+  webapp:
+    image: examples/web
+    ports:
+      - "8000:8000"
+    volumes:
+      - "/data"
+```
+If the `compose.admin.yaml` also specifies this same service, any matching fields override the previous file.
+New values, add to the `webapp` service configuration.
+
+```yaml
+services:
+  webapp:
+    build: .
+    environment:
+      - DEBUG=1
+```
+
+When you use multiple Compose files, all paths in the files are relative to the first configuration file specified
+with `-f`. You can use the `--project-directory` option to override this base path.
+
+Use a `-f` with `-` (dash) as the filename to read the configuration from stdin. When stdin is used all paths in the
+configuration are relative to the current working directory.
+
+The `-f` flag is optional. If you don’t provide this flag on the command line, Compose traverses the working directory
+and its parent directories looking for a `compose.yaml` or `docker-compose.yaml` file.
+
+#### Specifying a path to a single Compose file
+You can use the `-f` flag to specify a path to a Compose file that is not located in the current directory, either
+from the command line or by setting up a `COMPOSE_FILE` environment variable in your shell or in an environment file.
+
+For an example of using the `-f` option at the command line, suppose you are running the Compose Rails sample, and
+have a `compose.yaml` file in a directory called `sandbox/rails`. You can use a command like `docker compose pull` to
+get the postgres image for the db service from anywhere by using the `-f` flag as follows:
+
+```console
+$ docker compose -f ~/sandbox/rails/compose.yaml pull db
+```
+
+#### Using an OCI published artifact
+You can use the `-f` flag with the `oci://` prefix to reference a Compose file that has been published to an OCI registry.
+This allows you to distribute and version your Compose configurations as OCI artifacts.
+
+To use a Compose file from an OCI registry:
+
+```console
+$ docker compose -f oci://registry.example.com/my-compose-project:latest up
+```
+
+You can also combine OCI artifacts with local files:
+
+```console
+$ docker compose -f oci://registry.example.com/my-compose-project:v1.0 -f compose.override.yaml up
+```
+
+The OCI artifact must contain a valid Compose file. You can publish Compose files to an OCI registry using the
+`docker compose publish` command.
+
+#### Using a git repository
+You can use the `-f` flag to reference a Compose file from a git repository. Compose supports various git URL formats:
+
+Using HTTPS:
+```console
+$ docker compose -f https://github.com/user/repo.git up
+```
+
+Using SSH:
+```console
+$ docker compose -f git@github.com:user/repo.git up
+```
+
+You can specify a specific branch, tag, or commit:
+```console
+$ docker compose -f https://github.com/user/repo.git@main up
+$ docker compose -f https://github.com/user/repo.git@v1.0.0 up
+$ docker compose -f https://github.com/user/repo.git@abc123 up
+```
+
+You can also specify a subdirectory within the repository:
+```console
+$ docker compose -f https://github.com/user/repo.git#main:path/to/compose.yaml up
+```
+
+When using git resources, Compose will clone the repository and use the specified Compose file. You can combine
+git resources with local files:
+
+```console
+$ docker compose -f https://github.com/user/repo.git -f compose.override.yaml up
+```
+
+### Use `-p` to specify a project name
+
+Each configuration has a project name. Compose sets the project name using
+the following mechanisms, in order of precedence:
+- The `-p` command line flag
+- The `COMPOSE_PROJECT_NAME` environment variable
+- The top level `name:` variable from the config file (or the last `name:`
+from a series of config files specified using `-f`)
+- The `basename` of the project directory containing the config file (or
+containing the first config file specified using `-f`)
+- The `basename` of the current directory if no config file is specified
+Project names must contain only lowercase letters, decimal digits, dashes,
+and underscores, and must begin with a lowercase letter or decimal digit. If
+the `basename` of the project directory or current directory violates this
+constraint, you must use one of the other mechanisms.
+
+```console
+$ docker compose -p my_project ps -a
+NAME                 SERVICE    STATUS     PORTS
+my_project_demo_1    demo       running
+
+$ docker compose -p my_project logs
+demo_1  | PING localhost (127.0.0.1): 56 data bytes
+demo_1  | 64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.095 ms
+```
+
+### Use profiles to enable optional services
+
+Use `--profile` to specify one or more active profiles
+Calling `docker compose --profile frontend up` starts the services with the profile `frontend` and services
+without any specified profiles.
+You can also enable multiple profiles, e.g. with `docker compose --profile frontend --profile debug up` the profiles `frontend` and `debug` is enabled.
+
+Profiles can also be set by `COMPOSE_PROFILES` environment variable.
+
+### Configuring parallelism
+
+Use `--parallel` to specify the maximum level of parallelism for concurrent engine calls.
+Calling `docker compose --parallel 1 pull` pulls the pullable images defined in the Compose file
+one at a time. This can also be used to control build concurrency.
+
+Parallelism can also be set by the `COMPOSE_PARALLEL_LIMIT` environment variable.
+
+### Set up environment variables
+
+You can set environment variables for various docker compose options, including the `-f`, `-p` and `--profiles` flags.
+
+Setting the `COMPOSE_FILE` environment variable is equivalent to passing the `-f` flag,
+`COMPOSE_PROJECT_NAME` environment variable does the same as the `-p` flag,
+`COMPOSE_PROFILES` environment variable is equivalent to the `--profiles` flag
+and `COMPOSE_PARALLEL_LIMIT` does the same as the `--parallel` flag.
+
+If flags are explicitly set on the command line, the associated environment variable is ignored.
+
+Setting the `COMPOSE_IGNORE_ORPHANS` environment variable to `true` stops docker compose from detecting orphaned
+containers for the project.
+
+Setting the `COMPOSE_MENU` environment variable to `false` disables the helper menu when running `docker compose up`
+in attached mode. Alternatively, you can also run `docker compose up --menu=false` to disable the helper menu.
+
+### Use Dry Run mode to test your command
+
+Use `--dry-run` flag to test a command without changing your application stack state.
+Dry Run mode shows you all the steps Compose applies when executing a command, for example:
+```console
+$ docker compose --dry-run up --build -d
+[+] Pulling 1/1
+ ✔ DRY-RUN MODE -  db Pulled                                                                                                                                                                                                               0.9s
+[+] Running 10/8
+ ✔ DRY-RUN MODE -    build service backend                                                                                                                                                                                                 0.0s
+ ✔ DRY-RUN MODE -  ==> ==> writing image dryRun-754a08ddf8bcb1cf22f310f09206dd783d42f7dd                                                                                                                                                   0.0s
+ ✔ DRY-RUN MODE -  ==> ==> naming to nginx-golang-mysql-backend                                                                                                                                                                            0.0s
+ ✔ DRY-RUN MODE -  Network nginx-golang-mysql_default                                    Created                                                                                                                                           0.0s
+ ✔ DRY-RUN MODE -  Container nginx-golang-mysql-db-1                                     Created                                                                                                                                           0.0s
+ ✔ DRY-RUN MODE -  Container nginx-golang-mysql-backend-1                                Created                                                                                                                                           0.0s
+ ✔ DRY-RUN MODE -  Container nginx-golang-mysql-proxy-1                                  Created                                                                                                                                           0.0s
+ ✔ DRY-RUN MODE -  Container nginx-golang-mysql-db-1                                     Healthy                                                                                                                                           0.5s
+ ✔ DRY-RUN MODE -  Container nginx-golang-mysql-backend-1                                Started                                                                                                                                           0.0s
+ ✔ DRY-RUN MODE -  Container nginx-golang-mysql-proxy-1                                  Started                                     Started
+```
+From the example above, you can see that the first step is to pull the image defined by `db` service, then build the `backend` service.  
+Next, the containers are created. The `db` service is started, and the `backend` and `proxy` wait until the `db` service is healthy before starting.
+
+Dry Run mode works with almost all commands. You cannot use Dry Run mode with a command that doesn't change the state of a Compose stack such as `ps`, `ls`, `logs` for example.
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_alpha.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_alpha.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_alpha.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_alpha.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_dry-run.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_dry-run.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_dry-run.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_dry-run.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_generate.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_generate.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_generate.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_generate.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_publish.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_publish.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_publish.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_publish.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_scale.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_scale.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_scale.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_scale.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_viz.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_viz.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_viz.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_viz.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_watch.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_watch.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_watch.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_alpha_watch.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_attach.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_attach.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_attach.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_attach.md
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge.md
new file mode 100644
index 000000000000..78d3da4934c5
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge.md
@@ -0,0 +1,22 @@
+# docker compose bridge
+
+<!---MARKER_GEN_START-->
+Convert compose files into another model
+
+### Subcommands
+
+| Name                                                   | Description                                                                  |
+|:-------------------------------------------------------|:-----------------------------------------------------------------------------|
+| [`convert`](compose_bridge_convert.md)                 | Convert compose files to Kubernetes manifests, Helm charts, or another model |
+| [`transformations`](compose_bridge_transformations.md) | Manage transformation images                                                 |
+
+
+### Options
+
+| Name        | Type   | Default | Description                     |
+|:------------|:-------|:--------|:--------------------------------|
+| `--dry-run` | `bool` |         | Execute command in dry run mode |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_convert.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_convert.md
new file mode 100644
index 000000000000..d4b91ba172d2
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_convert.md
@@ -0,0 +1,17 @@
+# docker compose bridge convert
+
+<!---MARKER_GEN_START-->
+Convert compose files to Kubernetes manifests, Helm charts, or another model
+
+### Options
+
+| Name                     | Type          | Default | Description                                                                          |
+|:-------------------------|:--------------|:--------|:-------------------------------------------------------------------------------------|
+| `--dry-run`              | `bool`        |         | Execute command in dry run mode                                                      |
+| `-o`, `--output`         | `string`      | `out`   | The output directory for the Kubernetes resources                                    |
+| `--templates`            | `string`      |         | Directory containing transformation templates                                        |
+| `-t`, `--transformation` | `stringArray` |         | Transformation to apply to compose model (default: docker/compose-bridge-kubernetes) |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_transformations.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_transformations.md
new file mode 100644
index 000000000000..1e1c7be392b1
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_transformations.md
@@ -0,0 +1,22 @@
+# docker compose bridge transformations
+
+<!---MARKER_GEN_START-->
+Manage transformation images
+
+### Subcommands
+
+| Name                                                 | Description                    |
+|:-----------------------------------------------------|:-------------------------------|
+| [`create`](compose_bridge_transformations_create.md) | Create a new transformation    |
+| [`list`](compose_bridge_transformations_list.md)     | List available transformations |
+
+
+### Options
+
+| Name        | Type   | Default | Description                     |
+|:------------|:-------|:--------|:--------------------------------|
+| `--dry-run` | `bool` |         | Execute command in dry run mode |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_transformations_create.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_transformations_create.md
new file mode 100644
index 000000000000..187e8d9eca30
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_transformations_create.md
@@ -0,0 +1,15 @@
+# docker compose bridge transformations create
+
+<!---MARKER_GEN_START-->
+Create a new transformation
+
+### Options
+
+| Name           | Type     | Default | Description                                                                 |
+|:---------------|:---------|:--------|:----------------------------------------------------------------------------|
+| `--dry-run`    | `bool`   |         | Execute command in dry run mode                                             |
+| `-f`, `--from` | `string` |         | Existing transformation to copy (default: docker/compose-bridge-kubernetes) |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_transformations_list.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_transformations_list.md
new file mode 100644
index 000000000000..ce0a5e6911ad
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_bridge_transformations_list.md
@@ -0,0 +1,20 @@
+# docker compose bridge transformations list
+
+<!---MARKER_GEN_START-->
+List available transformations
+
+### Aliases
+
+`docker compose bridge transformations list`, `docker compose bridge transformations ls`
+
+### Options
+
+| Name            | Type     | Default | Description                                |
+|:----------------|:---------|:--------|:-------------------------------------------|
+| `--dry-run`     | `bool`   |         | Execute command in dry run mode            |
+| `--format`      | `string` | `table` | Format the output. Values: [table \| json] |
+| `-q`, `--quiet` | `bool`   |         | Only display transformer names             |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_build.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_build.md
similarity index 83%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_build.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_build.md
index 98d573e44c38..a715974dfa57 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_build.md
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_build.md
@@ -17,13 +17,16 @@ run `docker compose build` to rebuild it.
 |:----------------------|:--------------|:--------|:------------------------------------------------------------------------------------------------------------|
 | `--build-arg`         | `stringArray` |         | Set build-time variables for services                                                                       |
 | `--builder`           | `string`      |         | Set builder to use                                                                                          |
+| `--check`             | `bool`        |         | Check build configuration                                                                                   |
 | `--dry-run`           | `bool`        |         | Execute command in dry run mode                                                                             |
 | `-m`, `--memory`      | `bytes`       | `0`     | Set memory limit for the build container. Not supported by BuildKit.                                        |
 | `--no-cache`          | `bool`        |         | Do not use cache when building the image                                                                    |
 | `--print`             | `bool`        |         | Print equivalent bake file                                                                                  |
+| `--provenance`        | `string`      |         | Add a provenance attestation                                                                                |
 | `--pull`              | `bool`        |         | Always attempt to pull a newer version of the image                                                         |
 | `--push`              | `bool`        |         | Push service images                                                                                         |
-| `-q`, `--quiet`       | `bool`        |         | Don't print anything to STDOUT                                                                              |
+| `-q`, `--quiet`       | `bool`        |         | Suppress the build output                                                                                   |
+| `--sbom`              | `string`      |         | Add a SBOM attestation                                                                                      |
 | `--ssh`               | `string`      |         | Set SSH authentications used when building service images. (use 'default' for using your default SSH Agent) |
 | `--with-dependencies` | `bool`        |         | Also build dependencies (transitively)                                                                      |
 
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_commit.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_commit.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_commit.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_commit.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_config.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_config.md
similarity index 86%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_config.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_config.md
index 9e87efd29cbc..e2e773feae54 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_config.md
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_config.md
@@ -5,19 +5,18 @@
 It merges the Compose files set by `-f` flags, resolves variables in the Compose file, and expands short-notation into
 the canonical format.
 
-### Aliases
-
-`docker compose config`, `docker compose convert`
-
 ### Options
 
 | Name                      | Type     | Default | Description                                                                 |
 |:--------------------------|:---------|:--------|:----------------------------------------------------------------------------|
 | `--dry-run`               | `bool`   |         | Execute command in dry run mode                                             |
 | `--environment`           | `bool`   |         | Print environment used for interpolation.                                   |
-| `--format`                | `string` | `yaml`  | Format the output. Values: [yaml \| json]                                   |
+| `--format`                | `string` |         | Format the output. Values: [yaml \| json]                                   |
 | `--hash`                  | `string` |         | Print the service config hash, one per line.                                |
 | `--images`                | `bool`   |         | Print the image names, one per line.                                        |
+| `--lock-image-digests`    | `bool`   |         | Produces an override file with image digests                                |
+| `--models`                | `bool`   |         | Print the model names, one per line.                                        |
+| `--networks`              | `bool`   |         | Print the network names, one per line.                                      |
 | `--no-consistency`        | `bool`   |         | Don't check model consistency - warning: may produce invalid Compose output |
 | `--no-env-resolution`     | `bool`   |         | Don't resolve service env files                                             |
 | `--no-interpolate`        | `bool`   |         | Don't interpolate environment variables                                     |
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_cp.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_cp.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_cp.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_cp.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_create.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_create.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_create.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_create.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_down.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_down.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_down.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_down.md
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/compose_events.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_events.md
new file mode 100644
index 000000000000..066b5cf3831c
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_events.md
@@ -0,0 +1,56 @@
+# docker compose events
+
+<!---MARKER_GEN_START-->
+Stream container events for every container in the project.
+
+With the `--json` flag, a json object is printed one per line with the format:
+
+```json
+{
+    "time": "2015-11-20T18:01:03.615550",
+    "type": "container",
+    "action": "create",
+    "id": "213cf7...5fc39a",
+    "service": "web",
+    "attributes": {
+      "name": "application_web_1",
+      "image": "alpine:edge"
+    }
+}
+```
+
+The events that can be received using this can be seen [here](/reference/cli/docker/system/events/#object-types).
+
+### Options
+
+| Name        | Type     | Default | Description                               |
+|:------------|:---------|:--------|:------------------------------------------|
+| `--dry-run` | `bool`   |         | Execute command in dry run mode           |
+| `--json`    | `bool`   |         | Output events as a stream of json objects |
+| `--since`   | `string` |         | Show all events created since timestamp   |
+| `--until`   | `string` |         | Stream events until this timestamp        |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+Stream container events for every container in the project.
+
+With the `--json` flag, a json object is printed one per line with the format:
+
+```json
+{
+    "time": "2015-11-20T18:01:03.615550",
+    "type": "container",
+    "action": "create",
+    "id": "213cf7...5fc39a",
+    "service": "web",
+    "attributes": {
+      "name": "application_web_1",
+      "image": "alpine:edge"
+    }
+}
+```
+
+The events that can be received using this can be seen [here](https://docs.docker.com/reference/cli/docker/system/events/#object-types).
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/compose_exec.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_exec.md
new file mode 100644
index 000000000000..2312b101b911
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_exec.md
@@ -0,0 +1,42 @@
+# docker compose exec
+
+<!---MARKER_GEN_START-->
+This is the equivalent of `docker exec` targeting a Compose service.
+
+With this subcommand, you can run arbitrary commands in your services. Commands allocate a TTY by default, so
+you can use a command such as `docker compose exec web sh` to get an interactive prompt.
+
+By default, Compose will enter container in interactive mode and allocate a TTY, while the equivalent `docker exec`
+command requires passing `--interactive --tty` flags to get the same behavior. Compose also supports those two flags
+to offer a smooth migration between commands, whenever they are no-op by default. Still, `interactive` can be used to
+force disabling interactive mode (`--interactive=false`), typically when `docker compose exec` command is used inside
+a script.
+
+### Options
+
+| Name              | Type          | Default | Description                                                                      |
+|:------------------|:--------------|:--------|:---------------------------------------------------------------------------------|
+| `-d`, `--detach`  | `bool`        |         | Detached mode: Run command in the background                                     |
+| `--dry-run`       | `bool`        |         | Execute command in dry run mode                                                  |
+| `-e`, `--env`     | `stringArray` |         | Set environment variables                                                        |
+| `--index`         | `int`         | `0`     | Index of the container if service has multiple replicas                          |
+| `-T`, `--no-tty`  | `bool`        | `true`  | Disable pseudo-TTY allocation. By default 'docker compose exec' allocates a TTY. |
+| `--privileged`    | `bool`        |         | Give extended privileges to the process                                          |
+| `-u`, `--user`    | `string`      |         | Run the command as this user                                                     |
+| `-w`, `--workdir` | `string`      |         | Path to workdir directory for this command                                       |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+This is the equivalent of `docker exec` targeting a Compose service.
+
+With this subcommand, you can run arbitrary commands in your services. Commands allocate a TTY by default, so
+you can use a command such as `docker compose exec web sh` to get an interactive prompt.
+
+By default, Compose will enter container in interactive mode and allocate a TTY, while the equivalent `docker exec`
+command requires passing `--interactive --tty` flags to get the same behavior. Compose also supports those two flags
+to offer a smooth migration between commands, whenever they are no-op by default. Still, `interactive` can be used to
+force disabling interactive mode (`--interactive=false`), typically when `docker compose exec` command is used inside
+a script.
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_export.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_export.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_export.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_export.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_images.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_images.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_images.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_images.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_kill.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_kill.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_kill.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_kill.md
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/compose_logs.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_logs.md
new file mode 100644
index 000000000000..bcbb39e20810
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_logs.md
@@ -0,0 +1,25 @@
+# docker compose logs
+
+<!---MARKER_GEN_START-->
+Displays log output from services
+
+### Options
+
+| Name                                                                                                                                                                       | Type     | Default | Description                                                                                    |
+|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------|:--------|:-----------------------------------------------------------------------------------------------|
+| `--dry-run`                                                                                                                                                                | `bool`   |         | Execute command in dry run mode                                                                |
+| [`-f`](https://docs.docker.com/reference/cli/docker/container/logs/#follow), [`--follow`](https://docs.docker.com/reference/cli/docker/container/logs/#follow)             | `bool`   |         | Follow log output                                                                              |
+| `--index`                                                                                                                                                                  | `int`    | `0`     | index of the container if service has multiple replicas                                        |
+| `--no-color`                                                                                                                                                               | `bool`   |         | Produce monochrome output                                                                      |
+| `--no-log-prefix`                                                                                                                                                          | `bool`   |         | Don't print prefix in logs                                                                     |
+| [`--since`](https://docs.docker.com/reference/cli/docker/container/logs/#since)                                                                                            | `string` |         | Show logs since timestamp (e.g. 2013-01-02T13:23:37Z) or relative (e.g. 42m for 42 minutes)    |
+| [`-n`](https://docs.docker.com/reference/cli/docker/container/logs/#tail), [`--tail`](https://docs.docker.com/reference/cli/docker/container/logs/#tail)                   | `string` | `all`   | Number of lines to show from the end of the logs for each container                            |
+| [`-t`](https://docs.docker.com/reference/cli/docker/container/logs/#timestamps), [`--timestamps`](https://docs.docker.com/reference/cli/docker/container/logs/#timestamps) | `bool`   |         | Show timestamps                                                                                |
+| [`--until`](https://docs.docker.com/reference/cli/docker/container/logs/#until)                                                                                            | `string` |         | Show logs before a timestamp (e.g. 2013-01-02T13:23:37Z) or relative (e.g. 42m for 42 minutes) |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+Displays log output from services
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_ls.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_ls.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_ls.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_ls.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_pause.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_pause.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_pause.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_pause.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_port.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_port.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_port.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_port.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_ps.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_ps.md
similarity index 85%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_ps.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_ps.md
index 3572c5305568..54305e2157a1 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_ps.md
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_ps.md
@@ -61,50 +61,50 @@ example-bar-1   alpine    "/entrypoint.…"   bar        4 seconds ago   exited
 By default, the `docker compose ps` command uses a table ("pretty") format to
 show the containers. The `--format` flag allows you to specify alternative
 presentations for the output. Currently, supported options are `pretty` (default),
-and `json`, which outputs information about the containers as a JSON array:
+and `json`, which outputs information about the containers as JSON Lines
+(one JSON object per line), aligned with the output of `docker ps --format json`:
 
 ```console
 $ docker compose ps --format json
-[{"ID":"1553b0236cf4d2715845f053a4ee97042c4f9a2ef655731ee34f1f7940eaa41a","Name":"example-bar-1","Command":"/docker-entrypoint.sh nginx -g 'daemon off;'","Project":"example","Service":"bar","State":"exited","Health":"","ExitCode":0,"Publishers":null},{"ID":"f02a4efaabb67416e1ff127d51c4b5578634a0ad5743bd65225ff7d1909a3fa0","Name":"example-foo-1","Command":"/docker-entrypoint.sh nginx -g 'daemon off;'","Project":"example","Service":"foo","State":"running","Health":"","ExitCode":0,"Publishers":[{"URL":"0.0.0.0","TargetPort":80,"PublishedPort":8080,"Protocol":"tcp"}]}]
+{"ID":"1553b0236cf4d2715845f053a4ee97042c4f9a2ef655731ee34f1f7940eaa41a","Name":"example-bar-1","Command":"/docker-entrypoint.sh nginx -g 'daemon off;'","Project":"example","Service":"bar","State":"exited","Health":"","ExitCode":0,"Publishers":null}
+{"ID":"f02a4efaabb67416e1ff127d51c4b5578634a0ad5743bd65225ff7d1909a3fa0","Name":"example-foo-1","Command":"/docker-entrypoint.sh nginx -g 'daemon off;'","Project":"example","Service":"foo","State":"running","Health":"","ExitCode":0,"Publishers":[{"URL":"0.0.0.0","TargetPort":80,"PublishedPort":8080,"Protocol":"tcp"}]}
 ```
 
 The JSON output allows you to use the information in other tools for further
 processing, for example, using the [`jq` utility](https://stedolan.github.io/jq/)
-to pretty-print the JSON:
+to pretty-print each object:
 
 ```console
 $ docker compose ps --format json | jq .
-[
-  {
-    "ID": "1553b0236cf4d2715845f053a4ee97042c4f9a2ef655731ee34f1f7940eaa41a",
-    "Name": "example-bar-1",
-    "Command": "/docker-entrypoint.sh nginx -g 'daemon off;'",
-    "Project": "example",
-    "Service": "bar",
-    "State": "exited",
-    "Health": "",
-    "ExitCode": 0,
-    "Publishers": null
-  },
-  {
-    "ID": "f02a4efaabb67416e1ff127d51c4b5578634a0ad5743bd65225ff7d1909a3fa0",
-    "Name": "example-foo-1",
-    "Command": "/docker-entrypoint.sh nginx -g 'daemon off;'",
-    "Project": "example",
-    "Service": "foo",
-    "State": "running",
-    "Health": "",
-    "ExitCode": 0,
-    "Publishers": [
-      {
-        "URL": "0.0.0.0",
-        "TargetPort": 80,
-        "PublishedPort": 8080,
-        "Protocol": "tcp"
-      }
-    ]
-  }
-]
+{
+  "ID": "1553b0236cf4d2715845f053a4ee97042c4f9a2ef655731ee34f1f7940eaa41a",
+  "Name": "example-bar-1",
+  "Command": "/docker-entrypoint.sh nginx -g 'daemon off;'",
+  "Project": "example",
+  "Service": "bar",
+  "State": "exited",
+  "Health": "",
+  "ExitCode": 0,
+  "Publishers": null
+}
+{
+  "ID": "f02a4efaabb67416e1ff127d51c4b5578634a0ad5743bd65225ff7d1909a3fa0",
+  "Name": "example-foo-1",
+  "Command": "/docker-entrypoint.sh nginx -g 'daemon off;'",
+  "Project": "example",
+  "Service": "foo",
+  "State": "running",
+  "Health": "",
+  "ExitCode": 0,
+  "Publishers": [
+    {
+      "URL": "0.0.0.0",
+      "TargetPort": 80,
+      "PublishedPort": 8080,
+      "Protocol": "tcp"
+    }
+  ]
+}
 ```
 
 ### <a name="status"></a> Filter containers by status (--status)
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_publish.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_publish.md
similarity index 88%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_publish.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_publish.md
index 8e5d181336b2..9a82fc260a73 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_publish.md
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_publish.md
@@ -7,6 +7,7 @@ Publish compose application
 
 | Name                      | Type     | Default | Description                                                                    |
 |:--------------------------|:---------|:--------|:-------------------------------------------------------------------------------|
+| `--app`                   | `bool`   |         | Published compose application (includes referenced images)                     |
 | `--dry-run`               | `bool`   |         | Execute command in dry run mode                                                |
 | `--oci-version`           | `string` |         | OCI image/artifact specification version (automatically determined by default) |
 | `--resolve-image-digests` | `bool`   |         | Pin image tags to digests                                                      |
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_pull.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_pull.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_pull.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_pull.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_push.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_push.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_push.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_push.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_restart.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_restart.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_restart.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_restart.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_rm.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_rm.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_rm.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_rm.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_run.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_run.md
similarity index 99%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_run.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_run.md
index 25b28d1ded85..14fb85479266 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_run.md
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_run.md
@@ -70,8 +70,8 @@ specified in the service configuration.
 | `-i`, `--interactive`   | `bool`        | `true`   | Keep STDIN open even if not attached                                             |
 | `-l`, `--label`         | `stringArray` |          | Add or override a label                                                          |
 | `--name`                | `string`      |          | Assign a name to the container                                                   |
-| `-T`, `--no-TTY`        | `bool`        | `true`   | Disable pseudo-TTY allocation (default: auto-detected)                           |
 | `--no-deps`             | `bool`        |          | Don't start linked services                                                      |
+| `-T`, `--no-tty`        | `bool`        | `true`   | Disable pseudo-TTY allocation (default: auto-detected)                           |
 | `-p`, `--publish`       | `stringArray` |          | Publish a container's port(s) to the host                                        |
 | `--pull`                | `string`      | `policy` | Pull image before running ("always"\|"missing"\|"never")                         |
 | `-q`, `--quiet`         | `bool`        |          | Don't print anything to STDOUT                                                   |
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_scale.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_scale.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_scale.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_scale.md
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/compose_start.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_start.md
new file mode 100644
index 000000000000..06229e5940ef
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_start.md
@@ -0,0 +1,19 @@
+# docker compose start
+
+<!---MARKER_GEN_START-->
+Starts existing containers for a service
+
+### Options
+
+| Name             | Type   | Default | Description                                                                |
+|:-----------------|:-------|:--------|:---------------------------------------------------------------------------|
+| `--dry-run`      | `bool` |         | Execute command in dry run mode                                            |
+| `--wait`         | `bool` |         | Wait for services to be running\|healthy. Implies detached mode.           |
+| `--wait-timeout` | `int`  | `0`     | Maximum duration in seconds to wait for the project to be running\|healthy |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+Starts existing containers for a service
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_stats.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_stats.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_stats.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_stats.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_stop.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_stop.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_stop.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_stop.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_top.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_top.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_top.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_top.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_unpause.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_unpause.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_unpause.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_unpause.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_up.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_up.md
similarity index 97%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_up.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_up.md
index b831cb16d342..b7f17a0fac91 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_up.md
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_up.md
@@ -44,6 +44,7 @@ If the process is interrupted using `SIGINT` (ctrl + C) or `SIGTERM`, the contai
 | `--no-recreate`                | `bool`        |          | If containers already exist, don't recreate them. Incompatible with --force-recreate.                                                               |
 | `--no-start`                   | `bool`        |          | Don't start the services after creating them                                                                                                        |
 | `--pull`                       | `string`      | `policy` | Pull image before running ("always"\|"missing"\|"never")                                                                                            |
+| `--quiet-build`                | `bool`        |          | Suppress the build output                                                                                                                           |
 | `--quiet-pull`                 | `bool`        |          | Pull without printing progress information                                                                                                          |
 | `--remove-orphans`             | `bool`        |          | Remove containers for services not defined in the Compose file                                                                                      |
 | `-V`, `--renew-anon-volumes`   | `bool`        |          | Recreate anonymous volumes instead of retrieving data from the previous containers                                                                  |
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_version.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_version.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_version.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_version.md
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/compose_volumes.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_volumes.md
new file mode 100644
index 000000000000..6bad874f187b
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/compose_volumes.md
@@ -0,0 +1,16 @@
+# docker compose volumes
+
+<!---MARKER_GEN_START-->
+List volumes
+
+### Options
+
+| Name            | Type     | Default | Description                                                                                                                                                                                                                                                                                                                                                                                                                          |
+|:----------------|:---------|:--------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `--dry-run`     | `bool`   |         | Execute command in dry run mode                                                                                                                                                                                                                                                                                                                                                                                                      |
+| `--format`      | `string` | `table` | Format output using a custom template:<br>'table':            Print output in table format with column headers (default)<br>'table TEMPLATE':   Print output in table format using the given Go template<br>'json':             Print in JSON format<br>'TEMPLATE':         Print output using the given Go template.<br>Refer to https://docs.docker.com/go/formatting/ for more information about formatting output with templates |
+| `-q`, `--quiet` | `bool`   |         | Only display volume names                                                                                                                                                                                                                                                                                                                                                                                                            |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_wait.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_wait.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_wait.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_wait.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_watch.md b/_vendor/github.com/docker/compose/v5/docs/reference/compose_watch.md
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/compose_watch.md
rename to _vendor/github.com/docker/compose/v5/docs/reference/compose_watch.md
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose.yaml
similarity index 87%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose.yaml
index 58ec47802a55..c5fdb9375105 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose.yaml
@@ -6,6 +6,7 @@ pname: docker
 plink: docker.yaml
 cname:
     - docker compose attach
+    - docker compose bridge
     - docker compose build
     - docker compose commit
     - docker compose config
@@ -36,10 +37,12 @@ cname:
     - docker compose unpause
     - docker compose up
     - docker compose version
+    - docker compose volumes
     - docker compose wait
     - docker compose watch
 clink:
     - docker_compose_attach.yaml
+    - docker_compose_bridge.yaml
     - docker_compose_build.yaml
     - docker_compose_commit.yaml
     - docker_compose_config.yaml
@@ -70,6 +73,7 @@ clink:
     - docker_compose_unpause.yaml
     - docker_compose_up.yaml
     - docker_compose_version.yaml
+    - docker_compose_volumes.yaml
     - docker_compose_wait.yaml
     - docker_compose_watch.yaml
 options:
@@ -135,6 +139,17 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: insecure-registry
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Use insecure registry to pull Compose OCI artifacts. Doesn't apply to images
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: no-ansi
       value_type: bool
       default_value: "false"
@@ -167,7 +182,6 @@ options:
       swarm: false
     - option: progress
       value_type: string
-      default_value: auto
       description: Set type of progress output (auto, tty, plain, json, quiet)
       deprecated: false
       hidden: false
@@ -287,6 +301,57 @@ examples: |-
     $ docker compose -f ~/sandbox/rails/compose.yaml pull db
     ```
 
+    #### Using an OCI published artifact
+    You can use the `-f` flag with the `oci://` prefix to reference a Compose file that has been published to an OCI registry.
+    This allows you to distribute and version your Compose configurations as OCI artifacts.
+
+    To use a Compose file from an OCI registry:
+
+    ```console
+    $ docker compose -f oci://registry.example.com/my-compose-project:latest up
+    ```
+
+    You can also combine OCI artifacts with local files:
+
+    ```console
+    $ docker compose -f oci://registry.example.com/my-compose-project:v1.0 -f compose.override.yaml up
+    ```
+
+    The OCI artifact must contain a valid Compose file. You can publish Compose files to an OCI registry using the
+    `docker compose publish` command.
+
+    #### Using a git repository
+    You can use the `-f` flag to reference a Compose file from a git repository. Compose supports various git URL formats:
+
+    Using HTTPS:
+    ```console
+    $ docker compose -f https://github.com/user/repo.git up
+    ```
+
+    Using SSH:
+    ```console
+    $ docker compose -f git@github.com:user/repo.git up
+    ```
+
+    You can specify a specific branch, tag, or commit:
+    ```console
+    $ docker compose -f https://github.com/user/repo.git@main up
+    $ docker compose -f https://github.com/user/repo.git@v1.0.0 up
+    $ docker compose -f https://github.com/user/repo.git@abc123 up
+    ```
+
+    You can also specify a subdirectory within the repository:
+    ```console
+    $ docker compose -f https://github.com/user/repo.git#main:path/to/compose.yaml up
+    ```
+
+    When using git resources, Compose will clone the repository and use the specified Compose file. You can combine
+    git resources with local files:
+
+    ```console
+    $ docker compose -f https://github.com/user/repo.git -f compose.override.yaml up
+    ```
+
     ### Use `-p` to specify a project name
 
     Each configuration has a project name. Compose sets the project name using
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_dry-run.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_dry-run.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_dry-run.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_dry-run.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_generate.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_generate.yaml
similarity index 99%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_generate.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_generate.yaml
index 0932af080ecc..f31429c2d725 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_generate.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_generate.yaml
@@ -45,7 +45,7 @@ inherited_options:
       kubernetes: false
       swarm: false
 deprecated: false
-hidden: false
+hidden: true
 experimental: false
 experimentalcli: true
 kubernetes: false
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_publish.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_publish.yaml
similarity index 75%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_publish.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_publish.yaml
index 1566677472ae..9059cbf48695 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_publish.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_publish.yaml
@@ -5,6 +5,26 @@ usage: docker compose alpha publish [OPTIONS] REPOSITORY[:TAG]
 pname: docker compose alpha
 plink: docker_compose_alpha.yaml
 options:
+    - option: app
+      value_type: bool
+      default_value: "false"
+      description: Published compose application (includes referenced images)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: insecure-registry
+      value_type: bool
+      default_value: "false"
+      description: Use insecure registry
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: oci-version
       value_type: string
       description: |
@@ -58,7 +78,7 @@ inherited_options:
       kubernetes: false
       swarm: false
 deprecated: false
-hidden: false
+hidden: true
 experimental: false
 experimentalcli: true
 kubernetes: false
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_scale.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_scale.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_scale.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_scale.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_viz.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_viz.yaml
similarity index 99%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_viz.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_viz.yaml
index b179d648ef83..c07475caac8a 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_viz.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_viz.yaml
@@ -69,7 +69,7 @@ inherited_options:
       kubernetes: false
       swarm: false
 deprecated: false
-hidden: false
+hidden: true
 experimental: false
 experimentalcli: true
 kubernetes: false
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_watch.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_watch.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_watch.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_alpha_watch.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_attach.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_attach.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_attach.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_attach.yaml
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge.yaml
new file mode 100644
index 000000000000..5ef9ebf55850
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge.yaml
@@ -0,0 +1,29 @@
+command: docker compose bridge
+short: Convert compose files into another model
+long: Convert compose files into another model
+pname: docker compose
+plink: docker_compose.yaml
+cname:
+    - docker compose bridge convert
+    - docker compose bridge transformations
+clink:
+    - docker_compose_bridge_convert.yaml
+    - docker_compose_bridge_transformations.yaml
+inherited_options:
+    - option: dry-run
+      value_type: bool
+      default_value: "false"
+      description: Execute command in dry run mode
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_convert.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_convert.yaml
new file mode 100644
index 000000000000..f55f0b233c3c
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_convert.yaml
@@ -0,0 +1,59 @@
+command: docker compose bridge convert
+short: |
+    Convert compose files to Kubernetes manifests, Helm charts, or another model
+long: |
+    Convert compose files to Kubernetes manifests, Helm charts, or another model
+usage: docker compose bridge convert
+pname: docker compose bridge
+plink: docker_compose_bridge.yaml
+options:
+    - option: output
+      shorthand: o
+      value_type: string
+      default_value: out
+      description: The output directory for the Kubernetes resources
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: templates
+      value_type: string
+      description: Directory containing transformation templates
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: transformation
+      shorthand: t
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Transformation to apply to compose model (default: docker/compose-bridge-kubernetes)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: dry-run
+      value_type: bool
+      default_value: "false"
+      description: Execute command in dry run mode
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_transformations.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_transformations.yaml
new file mode 100644
index 000000000000..2ab5661f0b2a
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_transformations.yaml
@@ -0,0 +1,29 @@
+command: docker compose bridge transformations
+short: Manage transformation images
+long: Manage transformation images
+pname: docker compose bridge
+plink: docker_compose_bridge.yaml
+cname:
+    - docker compose bridge transformations create
+    - docker compose bridge transformations list
+clink:
+    - docker_compose_bridge_transformations_create.yaml
+    - docker_compose_bridge_transformations_list.yaml
+inherited_options:
+    - option: dry-run
+      value_type: bool
+      default_value: "false"
+      description: Execute command in dry run mode
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_transformations_create.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_transformations_create.yaml
new file mode 100644
index 000000000000..e8dd9e58a51e
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_transformations_create.yaml
@@ -0,0 +1,36 @@
+command: docker compose bridge transformations create
+short: Create a new transformation
+long: Create a new transformation
+usage: docker compose bridge transformations create [OPTION] PATH
+pname: docker compose bridge transformations
+plink: docker_compose_bridge_transformations.yaml
+options:
+    - option: from
+      shorthand: f
+      value_type: string
+      description: |
+        Existing transformation to copy (default: docker/compose-bridge-kubernetes)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: dry-run
+      value_type: bool
+      default_value: "false"
+      description: Execute command in dry run mode
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_transformations_list.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_transformations_list.yaml
new file mode 100644
index 000000000000..3afd3a84b8e7
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_bridge_transformations_list.yaml
@@ -0,0 +1,47 @@
+command: docker compose bridge transformations list
+aliases: docker compose bridge transformations list, docker compose bridge transformations ls
+short: List available transformations
+long: List available transformations
+usage: docker compose bridge transformations list
+pname: docker compose bridge transformations
+plink: docker_compose_bridge_transformations.yaml
+options:
+    - option: format
+      value_type: string
+      default_value: table
+      description: 'Format the output. Values: [table | json]'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: quiet
+      shorthand: q
+      value_type: bool
+      default_value: "false"
+      description: Only display transformer names
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: dry-run
+      value_type: bool
+      default_value: "false"
+      description: Execute command in dry run mode
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_build.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_build.yaml
similarity index 87%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_build.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_build.yaml
index 3f53dcf73628..e645a40aac21 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_build.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_build.yaml
@@ -33,6 +33,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: check
+      value_type: bool
+      default_value: "false"
+      description: Check build configuration
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: compress
       value_type: bool
       default_value: "true"
@@ -108,7 +118,6 @@ options:
       swarm: false
     - option: progress
       value_type: string
-      default_value: auto
       description: Set type of ui output (auto, tty, plain, json, quiet)
       deprecated: false
       hidden: true
@@ -116,6 +125,15 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: provenance
+      value_type: string
+      description: Add a provenance attestation
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: pull
       value_type: bool
       default_value: "false"
@@ -140,7 +158,16 @@ options:
       shorthand: q
       value_type: bool
       default_value: "false"
-      description: Don't print anything to STDOUT
+      description: Suppress the build output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: sbom
+      value_type: string
+      description: Add a SBOM attestation
       deprecated: false
       hidden: false
       experimental: false
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_commit.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_commit.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_commit.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_commit.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_config.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_config.yaml
similarity index 86%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_config.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_config.yaml
index 15b1e7dc3989..3efc922b219e 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_config.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_config.yaml
@@ -1,5 +1,4 @@
 command: docker compose config
-aliases: docker compose config, docker compose convert
 short: Parse, resolve and render compose file in canonical format
 long: |-
     `docker compose config` renders the actual data model to be applied on the Docker Engine.
@@ -21,7 +20,6 @@ options:
       swarm: false
     - option: format
       value_type: string
-      default_value: yaml
       description: 'Format the output. Values: [yaml | json]'
       deprecated: false
       hidden: false
@@ -48,6 +46,36 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: lock-image-digests
+      value_type: bool
+      default_value: "false"
+      description: Produces an override file with image digests
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: models
+      value_type: bool
+      default_value: "false"
+      description: Print the model names, one per line.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: networks
+      value_type: bool
+      default_value: "false"
+      description: Print the network names, one per line.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: no-consistency
       value_type: bool
       default_value: "false"
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_convert.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_convert.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_convert.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_convert.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_cp.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_cp.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_cp.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_cp.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_create.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_create.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_create.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_create.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_down.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_down.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_down.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_down.yaml
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_events.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_events.yaml
new file mode 100644
index 000000000000..7c4cb4297f97
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_events.yaml
@@ -0,0 +1,72 @@
+command: docker compose events
+short: Receive real time events from containers
+long: |-
+    Stream container events for every container in the project.
+
+    With the `--json` flag, a json object is printed one per line with the format:
+
+    ```json
+    {
+        "time": "2015-11-20T18:01:03.615550",
+        "type": "container",
+        "action": "create",
+        "id": "213cf7...5fc39a",
+        "service": "web",
+        "attributes": {
+          "name": "application_web_1",
+          "image": "alpine:edge"
+        }
+    }
+    ```
+
+    The events that can be received using this can be seen [here](/reference/cli/docker/system/events/#object-types).
+usage: docker compose events [OPTIONS] [SERVICE...]
+pname: docker compose
+plink: docker_compose.yaml
+options:
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output events as a stream of json objects
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: since
+      value_type: string
+      description: Show all events created since timestamp
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: until
+      value_type: string
+      description: Stream events until this timestamp
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: dry-run
+      value_type: bool
+      default_value: "false"
+      description: Execute command in dry run mode
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_exec.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_exec.yaml
similarity index 84%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_exec.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_exec.yaml
index b2a1cf20685f..a76b8259049d 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_exec.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_exec.yaml
@@ -5,6 +5,12 @@ long: |-
 
     With this subcommand, you can run arbitrary commands in your services. Commands allocate a TTY by default, so
     you can use a command such as `docker compose exec web sh` to get an interactive prompt.
+
+    By default, Compose will enter container in interactive mode and allocate a TTY, while the equivalent `docker exec`
+    command requires passing `--interactive --tty` flags to get the same behavior. Compose also supports those two flags
+    to offer a smooth migration between commands, whenever they are no-op by default. Still, `interactive` can be used to
+    force disabling interactive mode (`--interactive=false`), typically when `docker compose exec` command is used inside
+    a script.
 usage: docker compose exec [OPTIONS] SERVICE COMMAND [ARGS...]
 pname: docker compose
 plink: docker_compose.yaml
@@ -52,12 +58,12 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
-    - option: no-TTY
+    - option: no-tty
       shorthand: T
       value_type: bool
       default_value: "true"
       description: |
-        Disable pseudo-TTY allocation. By default `docker compose exec` allocates a TTY.
+        Disable pseudo-TTY allocation. By default 'docker compose exec' allocates a TTY.
       deprecated: false
       hidden: false
       experimental: false
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_export.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_export.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_export.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_export.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_images.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_images.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_images.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_images.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_kill.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_kill.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_kill.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_kill.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_logs.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_logs.yaml
similarity index 90%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_logs.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_logs.yaml
index 92d94dd108cf..6b657ff8cb08 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_logs.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_logs.yaml
@@ -10,6 +10,7 @@ options:
       value_type: bool
       default_value: "false"
       description: Follow log output
+      details_url: /reference/cli/docker/container/logs/#follow
       deprecated: false
       hidden: false
       experimental: false
@@ -50,6 +51,7 @@ options:
       value_type: string
       description: |
         Show logs since timestamp (e.g. 2013-01-02T13:23:37Z) or relative (e.g. 42m for 42 minutes)
+      details_url: /reference/cli/docker/container/logs/#since
       deprecated: false
       hidden: false
       experimental: false
@@ -62,6 +64,7 @@ options:
       default_value: all
       description: |
         Number of lines to show from the end of the logs for each container
+      details_url: /reference/cli/docker/container/logs/#tail
       deprecated: false
       hidden: false
       experimental: false
@@ -73,6 +76,7 @@ options:
       value_type: bool
       default_value: "false"
       description: Show timestamps
+      details_url: /reference/cli/docker/container/logs/#timestamps
       deprecated: false
       hidden: false
       experimental: false
@@ -83,6 +87,7 @@ options:
       value_type: string
       description: |
         Show logs before a timestamp (e.g. 2013-01-02T13:23:37Z) or relative (e.g. 42m for 42 minutes)
+      details_url: /reference/cli/docker/container/logs/#until
       deprecated: false
       hidden: false
       experimental: false
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_ls.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_ls.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_ls.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_ls.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_pause.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_pause.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_pause.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_pause.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_port.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_port.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_port.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_port.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_ps.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_ps.yaml
similarity index 80%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_ps.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_ps.yaml
index d03702756954..9f8d4ba447a9 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_ps.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_ps.yaml
@@ -130,50 +130,50 @@ examples: |-
     By default, the `docker compose ps` command uses a table ("pretty") format to
     show the containers. The `--format` flag allows you to specify alternative
     presentations for the output. Currently, supported options are `pretty` (default),
-    and `json`, which outputs information about the containers as a JSON array:
+    and `json`, which outputs information about the containers as JSON Lines
+    (one JSON object per line), aligned with the output of `docker ps --format json`:
 
     ```console
     $ docker compose ps --format json
-    [{"ID":"1553b0236cf4d2715845f053a4ee97042c4f9a2ef655731ee34f1f7940eaa41a","Name":"example-bar-1","Command":"/docker-entrypoint.sh nginx -g 'daemon off;'","Project":"example","Service":"bar","State":"exited","Health":"","ExitCode":0,"Publishers":null},{"ID":"f02a4efaabb67416e1ff127d51c4b5578634a0ad5743bd65225ff7d1909a3fa0","Name":"example-foo-1","Command":"/docker-entrypoint.sh nginx -g 'daemon off;'","Project":"example","Service":"foo","State":"running","Health":"","ExitCode":0,"Publishers":[{"URL":"0.0.0.0","TargetPort":80,"PublishedPort":8080,"Protocol":"tcp"}]}]
+    {"ID":"1553b0236cf4d2715845f053a4ee97042c4f9a2ef655731ee34f1f7940eaa41a","Name":"example-bar-1","Command":"/docker-entrypoint.sh nginx -g 'daemon off;'","Project":"example","Service":"bar","State":"exited","Health":"","ExitCode":0,"Publishers":null}
+    {"ID":"f02a4efaabb67416e1ff127d51c4b5578634a0ad5743bd65225ff7d1909a3fa0","Name":"example-foo-1","Command":"/docker-entrypoint.sh nginx -g 'daemon off;'","Project":"example","Service":"foo","State":"running","Health":"","ExitCode":0,"Publishers":[{"URL":"0.0.0.0","TargetPort":80,"PublishedPort":8080,"Protocol":"tcp"}]}
     ```
 
     The JSON output allows you to use the information in other tools for further
     processing, for example, using the [`jq` utility](https://stedolan.github.io/jq/)
-    to pretty-print the JSON:
+    to pretty-print each object:
 
     ```console
     $ docker compose ps --format json | jq .
-    [
-      {
-        "ID": "1553b0236cf4d2715845f053a4ee97042c4f9a2ef655731ee34f1f7940eaa41a",
-        "Name": "example-bar-1",
-        "Command": "/docker-entrypoint.sh nginx -g 'daemon off;'",
-        "Project": "example",
-        "Service": "bar",
-        "State": "exited",
-        "Health": "",
-        "ExitCode": 0,
-        "Publishers": null
-      },
-      {
-        "ID": "f02a4efaabb67416e1ff127d51c4b5578634a0ad5743bd65225ff7d1909a3fa0",
-        "Name": "example-foo-1",
-        "Command": "/docker-entrypoint.sh nginx -g 'daemon off;'",
-        "Project": "example",
-        "Service": "foo",
-        "State": "running",
-        "Health": "",
-        "ExitCode": 0,
-        "Publishers": [
-          {
-            "URL": "0.0.0.0",
-            "TargetPort": 80,
-            "PublishedPort": 8080,
-            "Protocol": "tcp"
-          }
-        ]
-      }
-    ]
+    {
+      "ID": "1553b0236cf4d2715845f053a4ee97042c4f9a2ef655731ee34f1f7940eaa41a",
+      "Name": "example-bar-1",
+      "Command": "/docker-entrypoint.sh nginx -g 'daemon off;'",
+      "Project": "example",
+      "Service": "bar",
+      "State": "exited",
+      "Health": "",
+      "ExitCode": 0,
+      "Publishers": null
+    }
+    {
+      "ID": "f02a4efaabb67416e1ff127d51c4b5578634a0ad5743bd65225ff7d1909a3fa0",
+      "Name": "example-foo-1",
+      "Command": "/docker-entrypoint.sh nginx -g 'daemon off;'",
+      "Project": "example",
+      "Service": "foo",
+      "State": "running",
+      "Health": "",
+      "ExitCode": 0,
+      "Publishers": [
+        {
+          "URL": "0.0.0.0",
+          "TargetPort": 80,
+          "PublishedPort": 8080,
+          "Protocol": "tcp"
+        }
+      ]
+    }
     ```
 
     ### Filter containers by status (--status) {#status}
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_publish.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_publish.yaml
similarity index 76%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_publish.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_publish.yaml
index 44a7a46dd421..c3189d89c573 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_publish.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_publish.yaml
@@ -5,6 +5,26 @@ usage: docker compose publish [OPTIONS] REPOSITORY[:TAG]
 pname: docker compose
 plink: docker_compose.yaml
 options:
+    - option: app
+      value_type: bool
+      default_value: "false"
+      description: Published compose application (includes referenced images)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: insecure-registry
+      value_type: bool
+      default_value: "false"
+      description: Use insecure registry
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: oci-version
       value_type: string
       description: |
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_pull.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_pull.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_pull.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_pull.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_push.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_push.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_push.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_push.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_restart.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_restart.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_restart.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_restart.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_rm.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_rm.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_rm.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_rm.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_run.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_run.yaml
similarity index 99%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_run.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_run.yaml
index 61c7ca0e8cbc..bc9f81e9ed0a 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_run.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_run.yaml
@@ -158,21 +158,21 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
-    - option: no-TTY
-      shorthand: T
+    - option: no-deps
       value_type: bool
-      default_value: "true"
-      description: 'Disable pseudo-TTY allocation (default: auto-detected)'
+      default_value: "false"
+      description: Don't start linked services
       deprecated: false
       hidden: false
       experimental: false
       experimentalcli: false
       kubernetes: false
       swarm: false
-    - option: no-deps
+    - option: no-tty
+      shorthand: T
       value_type: bool
-      default_value: "false"
-      description: Don't start linked services
+      default_value: "true"
+      description: 'Disable pseudo-TTY allocation (default: auto-detected)'
       deprecated: false
       hidden: false
       experimental: false
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_scale.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_scale.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_scale.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_scale.yaml
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_start.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_start.yaml
new file mode 100644
index 000000000000..56f9bcdff7c8
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_start.yaml
@@ -0,0 +1,46 @@
+command: docker compose start
+short: Start services
+long: Starts existing containers for a service
+usage: docker compose start [SERVICE...]
+pname: docker compose
+plink: docker_compose.yaml
+options:
+    - option: wait
+      value_type: bool
+      default_value: "false"
+      description: Wait for services to be running|healthy. Implies detached mode.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: wait-timeout
+      value_type: int
+      default_value: "0"
+      description: |
+        Maximum duration in seconds to wait for the project to be running|healthy
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: dry-run
+      value_type: bool
+      default_value: "false"
+      description: Execute command in dry run mode
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_stats.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_stats.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_stats.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_stats.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_stop.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_stop.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_stop.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_stop.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_top.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_top.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_top.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_top.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_unpause.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_unpause.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_unpause.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_unpause.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_up.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_up.yaml
similarity index 97%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_up.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_up.yaml
index 47e0c5259ebb..8c78a8fa683e 100644
--- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_up.yaml
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_up.yaml
@@ -211,6 +211,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: quiet-build
+      value_type: bool
+      default_value: "false"
+      description: Suppress the build output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: quiet-pull
       value_type: bool
       default_value: "false"
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_version.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_version.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_version.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_version.yaml
diff --git a/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_volumes.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_volumes.yaml
new file mode 100644
index 000000000000..20516db7f137
--- /dev/null
+++ b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_volumes.yaml
@@ -0,0 +1,52 @@
+command: docker compose volumes
+short: List volumes
+long: List volumes
+usage: docker compose volumes [OPTIONS] [SERVICE...]
+pname: docker compose
+plink: docker_compose.yaml
+options:
+    - option: format
+      value_type: string
+      default_value: table
+      description: |-
+        Format output using a custom template:
+        'table':            Print output in table format with column headers (default)
+        'table TEMPLATE':   Print output in table format using the given Go template
+        'json':             Print in JSON format
+        'TEMPLATE':         Print output using the given Go template.
+        Refer to https://docs.docker.com/go/formatting/ for more information about formatting output with templates
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: quiet
+      shorthand: q
+      value_type: bool
+      default_value: "false"
+      description: Only display volume names
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: dry-run
+      value_type: bool
+      default_value: "false"
+      description: Execute command in dry run mode
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_wait.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_wait.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_wait.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_wait.yaml
diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_watch.yaml b/_vendor/github.com/docker/compose/v5/docs/reference/docker_compose_watch.yaml
similarity index 100%
rename from _vendor/github.com/docker/compose/v2/docs/reference/docker_compose_watch.yaml
rename to _vendor/github.com/docker/compose/v5/docs/reference/docker_compose_watch.yaml
diff --git a/_vendor/github.com/docker/docker-agent/docs/community/_index.md b/_vendor/github.com/docker/docker-agent/docs/community/_index.md
new file mode 100644
index 000000000000..764483d9718c
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/community/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Community"
+description: "Contributing, troubleshooting, and telemetry."
+weight: 80
+---
diff --git a/_vendor/github.com/docker/docker-agent/docs/community/contributing/index.md b/_vendor/github.com/docker/docker-agent/docs/community/contributing/index.md
new file mode 100644
index 000000000000..302997a137dc
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/community/contributing/index.md
@@ -0,0 +1,131 @@
+---
+title: "Contributing"
+description: "Docker Agent is open source. Here's how to set up your development environment and contribute."
+keywords: docker agent, ai agents, community, contributing
+weight: 10
+canonical: https://docs.docker.com/ai/docker-agent/community/contributing/
+---
+
+_Docker Agent is open source. Here's how to set up your development environment and contribute._
+
+## Development Setup
+
+### Prerequisites
+
+- [Go 1.26](https://go.dev/dl/) or higher
+- API key(s) for your chosen AI provider
+- [Task](https://taskfile.dev/installation/)
+- [golangci-lint](https://golangci-lint.run/docs/welcome/install/local/)
+
+> [!NOTE]
+> **Platform Support**
+>
+> macOS and Linux are fully supported for development. On Windows, use `task build-local` to build via Docker.
+
+### Build from Source
+
+```bash
+# Clone and build
+git clone https://github.com/docker/docker-agent.git
+cd docker-agent
+task build
+
+# Set API keys
+export OPENAI_API_KEY=your_key_here
+export ANTHROPIC_API_KEY=your_key_here
+
+# Run an example
+./bin/docker-agent run examples/code.yaml
+```
+
+### Development Commands
+
+| Command            | Description                                     |
+| ------------------ | ----------------------------------------------- |
+| `task build`       | Build the binary to `./bin/docker-agent`        |
+| `task test`        | Run all tests (clears API keys for determinism) |
+| `task lint`        | Run golangci-lint                               |
+| `task format`      | Format code                                     |
+| `task dev`         | Run lint, test, and build in sequence           |
+| `task build-local` | Build for local platform via Docker             |
+| `task cross`       | Cross-platform builds (all architectures)       |
+
+## Dogfooding
+
+Use Docker Agent to work on Docker Agent! The project includes a specialized developer agent:
+
+```bash
+cd docker-agent
+docker agent run ./golang_developer.yaml
+```
+
+This agent is an expert Go developer that understands the Docker Agent codebase. Ask it questions, request fixes, or have it implement features.
+
+## Core Concepts
+
+- **Root Agent** — Main entry point that coordinates the system
+- **Sub-Agents** — Specialized agents for specific domains
+- **Tools** — External capabilities via MCP
+- **Models** — AI provider configurations
+
+## Code Style
+
+The project uses `golangci-lint` with strict rules. As long as `task lint` passes, the code is stylistically acceptable.
+
+Key conventions:
+
+- Use `fmt.Errorf("context: %w", err)` for error wrapping
+- Always pass `context.Context` as the first parameter
+- Use `slog` for structured logging
+- Use functional options pattern for constructors
+- In tests: use `t.Context()`, `t.TempDir()`, `t.Setenv()`, and `t.Parallel()`
+
+## Opening Issues
+
+File issues on the [GitHub issue tracker](https://github.com/docker/docker-agent/issues). Please:
+
+> [!NOTE]
+> **See also**
+>
+> [Troubleshooting](../troubleshooting/index.md) — Common issues and debug mode. [Telemetry](../telemetry/index.md) — What data is collected and how to opt out.
+
+- Use the included issue template
+- Search for existing issues before creating new ones
+- Only use issues for bugs and feature requests (not support)
+
+## Submitting Pull Requests
+
+1. **Fork** the repository and create a branch for your changes
+2. **Write** your code following the style and testing guidelines above
+3. **Test** your changes: run `task lint` and `task test`
+4. **Sign** your commits with `git commit -s` (DCO required)
+5. **Open a pull request** against the `main` branch
+
+> [!TIP]
+> Use the dogfooding agent (`docker agent run ./golang_developer.yaml`) to help write and review your changes before submitting.
+
+## Sign Your Work
+
+All contributions require a Developer Certificate of Origin (DCO) sign-off:
+
+```bash
+# Sign commits automatically
+git config user.name "Your Name"
+git config user.email "your.email@example.com"
+git commit -s -m "Your commit message"
+```
+
+## Community
+
+Find us on [Slack](https://dockercommunity.slack.com/archives/C09DASHHRU4) for questions and discussions.
+
+## Code of Conduct
+
+We want to keep the Docker Agent community welcoming, inclusive, and collaborative. Key guidelines:
+
+- **Be nice** — Be courteous, respectful, and polite. No abuse of any kind will be tolerated.
+- **Encourage diversity** — Make everyone feel welcome regardless of background.
+- **Keep it legal** — Share only content you own and don't break the law.
+- **Stay on topic** — Post to the correct channel and avoid off-topic discussions.
+
+The governance for this repository is handled by Docker Inc.
diff --git a/_vendor/github.com/docker/docker-agent/docs/community/opentelemetry/index.md b/_vendor/github.com/docker/docker-agent/docs/community/opentelemetry/index.md
new file mode 100644
index 000000000000..ae6b3c9a1304
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/community/opentelemetry/index.md
@@ -0,0 +1,99 @@
+---
+title: "OpenTelemetry Tracing"
+description: "Export Docker Agent traces to any OTLP backend, including Langfuse and LangSmith, for debugging agentic workflows."
+keywords: docker agent, ai agents, community, opentelemetry tracing
+weight: 40
+canonical: https://docs.docker.com/ai/docker-agent/community/opentelemetry/
+---
+
+_Docker Agent can export OpenTelemetry traces of an agent run to any OTLP/HTTP backend. This is separate from [product-analytics telemetry](../telemetry/index.md) and is opt-in via the `--otel` flag._
+
+When enabled, Docker Agent emits OpenTelemetry GenAI (`gen_ai.*`) and MCP (`mcp.*`) spans following the [OpenTelemetry semantic conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/). Spans cover the agent turn, model calls (with token usage and cost attributes), tool calls, MCP client/server activity, sub-agent hand-offs, and provider fallbacks. W3C `traceparent` context is propagated so the whole run renders as a single connected trace tree.
+
+## Enabling
+
+```bash
+docker agent run agent.yaml --otel
+```
+
+Without an exporter endpoint configured, spans are recorded locally as no-ops. To ship them somewhere, set the standard OTLP environment variables described below.
+
+## Configuration
+
+Docker Agent reads the standard OTLP environment variables:
+
+| Variable | Purpose |
+| --- | --- |
+| `OTEL_EXPORTER_OTLP_ENDPOINT` | Base OTLP/HTTP endpoint. The signal subpath (`/v1/traces`, `/v1/metrics`, `/v1/logs`) is appended automatically. |
+| `OTEL_EXPORTER_OTLP_HEADERS` | Comma-separated `key=value` headers sent with every export request (for example, an `Authorization` header). |
+| `OTEL_RESOURCE_ATTRIBUTES` | Extra resource attributes merged into every span. |
+| `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT` | Set to `true` to capture prompt and response message content as span attributes. Off by default. |
+
+> [!NOTE]
+> **Base endpoint, not the full signal URL**
+>
+> Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the **base** endpoint (for example `https://cloud.langfuse.com/api/public/otel`). Docker Agent appends `/v1/traces` for you, matching the value documented by Langfuse and LangSmith. A bare `host:port` is also accepted and gets `https://` (or `http://` for localhost).
+
+> [!WARNING]
+> **Message content can contain sensitive data**
+>
+> `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT` is off by default because chat history routinely contains PII, secrets, and internal documents. Enable it only for backends and environments where exporting that content is acceptable.
+
+## Backends
+
+Protocol support is OTLP over HTTP (`http/protobuf`). gRPC endpoints are not currently supported.
+
+### Langfuse
+
+[Langfuse](https://langfuse.com) exposes an OTLP endpoint and authenticates with HTTP Basic auth built from a project's public and secret keys.
+
+```bash
+# Base64 of "public_key:secret_key"
+LANGFUSE_AUTH=$(echo -n "pk-lf-...:sk-lf-..." | base64)
+
+export OTEL_EXPORTER_OTLP_ENDPOINT="https://cloud.langfuse.com/api/public/otel"
+export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Basic ${LANGFUSE_AUTH}"
+
+docker agent run agent.yaml --otel
+```
+
+Regional and self-hosted hosts use the same `/api/public/otel` base path:
+
+| Region | Endpoint |
+| --- | --- |
+| EU | `https://cloud.langfuse.com/api/public/otel` |
+| US | `https://us.cloud.langfuse.com/api/public/otel` |
+| Self-hosted (>= v3.22.0) | `http://localhost:3000/api/public/otel` |
+
+### LangSmith
+
+[LangSmith](https://docs.langchain.com/langsmith/trace-with-opentelemetry) authenticates with an `x-api-key` header (the raw API key, with no `Basic`/`Bearer` prefix). An optional `Langsmith-Project` header routes traces to a named project.
+
+```bash
+export OTEL_EXPORTER_OTLP_ENDPOINT="https://api.smith.langchain.com/otel"
+export OTEL_EXPORTER_OTLP_HEADERS="x-api-key=<your-api-key>,Langsmith-Project=<project>"
+
+docker agent run agent.yaml --otel
+```
+
+### OpenTelemetry Collector
+
+Any OTLP/HTTP collector (the OpenTelemetry Collector, Grafana Alloy, Jaeger, and so on) works by pointing at its base endpoint:
+
+```bash
+export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4318"
+docker agent run agent.yaml --otel
+```
+
+> [!NOTE]
+> **Langfuse and LangSmith ingest traces only**
+>
+> Both backends accept the traces signal only. Docker Agent also wires metric and log exporters at the same endpoint, so their periodic exports return `404` against trace-only backends. This is harmless to traces but appears in the debug log. Point a full OTLP collector at the endpoint if you also want metrics and logs.
+
+## Inspecting traces locally
+
+Use `--debug` to print telemetry activity to the debug log (`~/.cagent/cagent.debug.log` by default) without standing up a backend:
+
+```bash
+docker agent run agent.yaml --otel --debug
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/community/telemetry/index.md b/_vendor/github.com/docker/docker-agent/docs/community/telemetry/index.md
new file mode 100644
index 000000000000..54974db155f8
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/community/telemetry/index.md
@@ -0,0 +1,79 @@
+---
+title: "Telemetry"
+description: "Docker Agent collects anonymous usage data to help improve the tool. Telemetry can be disabled at any time."
+keywords: docker agent, ai agents, community, telemetry
+weight: 30
+canonical: https://docs.docker.com/ai/docker-agent/community/telemetry/
+---
+
+_Docker Agent collects anonymous usage data to help improve the tool. Telemetry can be disabled at any time._
+
+On first startup, Docker Agent displays a notice about telemetry collection so you're always informed. All events are processed synchronously when recorded.
+
+## Disabling Telemetry
+
+```bash
+# Disable via environment variable
+$ TELEMETRY_ENABLED=false docker agent run agent.yaml
+
+# Or export it in your shell profile
+$ export TELEMETRY_ENABLED=false
+```
+
+> [!NOTE]
+> **Default**
+>
+> Telemetry is **enabled by default**. Set `TELEMETRY_ENABLED=false` to opt out.
+
+## What's Collected ✅
+
+- Command names and success/failure status
+- Agent names and model types
+- Tool names and whether calls succeed or fail
+- Token counts (input/output totals) and estimated costs
+- Session metadata (durations, error counts)
+
+## What's NOT Collected ❌
+
+- User input or prompts
+- Agent responses or generated content
+- File contents
+- API keys or credentials
+- Personally identifying information (PII)
+
+> [!TIP]
+> **See events locally**
+>
+> Use `--debug` to see telemetry events printed to the debug log without sending them anywhere additional.
+
+```bash
+docker agent run agent.yaml --debug
+```
+
+## Event Types
+
+The telemetry system uses structured, type-safe events:
+
+| Event Type  | What It Tracks                                                      |
+| ----------- | ------------------------------------------------------------------- |
+| **Command** | CLI command execution with success status                           |
+| **Tool**    | Agent tool calls with timing and error information                  |
+| **Token**   | LLM token usage by model, session, and cost                         |
+| **Session** | Agent session lifecycle with start/end events and aggregate metrics |
+
+## For Developers
+
+Telemetry is automatically wrapped around all commands. To record additional events, use the context-based API:
+
+```bash
+// Recommended: context-based telemetry (clean, testable)
+if telemetryClient := telemetry.FromContext(ctx); telemetryClient != nil {
+    telemetryClient.RecordToolCall(ctx, "filesystem", "session-id", "agentName", time.Millisecond*500, nil)
+    telemetryClient.RecordTokenUsage(ctx, "gpt-4", 100, 50, 0.01)
+}
+
+// Or use direct calls
+telemetry.TrackCommand("run", args)
+```
+
+Events are processed synchronously when `Track()` is called, sending HTTP requests immediately.
diff --git a/_vendor/github.com/docker/docker-agent/docs/community/troubleshooting/index.md b/_vendor/github.com/docker/docker-agent/docs/community/troubleshooting/index.md
new file mode 100644
index 000000000000..1e73169e067b
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/community/troubleshooting/index.md
@@ -0,0 +1,342 @@
+---
+title: "Troubleshooting"
+description: "Common issues and how to resolve them when working with Docker Agent."
+keywords: docker agent, ai agents, community, troubleshooting
+weight: 20
+canonical: https://docs.docker.com/ai/docker-agent/community/troubleshooting/
+---
+
+_Common issues and how to resolve them when working with Docker Agent._
+
+## Common Errors
+
+### Context Window Exceeded
+
+Error message: `context_length_exceeded` or similar.
+
+- Use `/compact` in the TUI to summarize and reduce conversation history
+- Set `num_history_items` in agent config to limit messages sent to the model
+- Switch to a model with larger context (Claude Sonnet 4.5 supports 1M tokens, Gemini up to 2M)
+- Break large tasks into smaller conversations
+
+### Max Iterations Reached
+
+The agent hit its `max_iterations` limit without completing the task.
+
+- Increase `max_iterations` in agent config (default is unlimited, but many agents set 20-50)
+- Check if the agent is stuck in a loop (enable `--debug` to see tool calls)
+- Break complex tasks into smaller steps
+
+### Model Fallback Triggered
+
+When the primary model fails, Docker Agent automatically switches to fallback models. Look for log messages like `"Switching to fallback model"`.
+
+- **429 errors:** Rate limited — the cooldown period keeps using the fallback
+- **5xx errors:** Server issues — retries with exponential backoff first, then falls back
+- **4xx errors:** Client errors — skips directly to next model
+
+Configure fallback behavior in your agent config:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    fallback:
+      models: [openai/gpt-5-mini, openai/gpt-4o-mini]
+      retries: 2 # retries per model for 5xx errors
+      cooldown: 1m # how long to stick with fallback after 429
+```
+
+## Missing credentials or model errors
+
+When Docker Agent can't find a usable model at startup, it fails fast with an actionable error. The message names the exact next step. `docker agent doctor` is the fastest way to see the full picture — which providers have credentials, whether Docker Model Runner is reachable, and which model `auto` would pick.
+
+### Required environment variables not set
+
+An agent (or a tool it uses) depends on environment variables that aren't configured:
+
+```text
+The following environment variables must be set:
+ - ANTHROPIC_API_KEY
+
+Provide them using any of these sources:
+ - Shell environment:      export ANTHROPIC_API_KEY=<value>
+ - Env file:               docker agent run --env-from-file <file> ...
+ - Docker Agent env file:  docker agent setup (stores the key in ~/.config/cagent/.env)
+
+See https://docs.docker.com/ai/docker-agent/guides/secrets/ for details.
+```
+
+Set the variable through any of the listed [secret sources](../../guides/secrets/index.md). When the missing variable is a model-provider API key, the error also suggests running a local model instead (`docker agent run --model dmr/ai/qwen3 ...`), which needs no API key, and links to the [Set Up a Model](../../getting-started/set-up-a-model/index.md) tutorial.
+
+### No model available (`auto` selection failed)
+
+The `auto` model selector found no configured cloud provider and no usable Docker Model Runner model:
+
+```text
+No model is currently available.
+
+To fix this, you can:
+  - Pull a Docker Model Runner model, e.g. `docker model pull ai/qwen3`
+  - Install Docker Model Runner: https://docs.docker.com/ai/model-runner/get-started/
+  - Configure an API key for a cloud provider:
+    - anthropic: ANTHROPIC_API_KEY
+    - openai: OPENAI_API_KEY
+    ...
+```
+
+Either configure a cloud provider API key (see [API keys not set](#api-keys-not-set) below) or pull a local model. The [Set Up a Model](../../getting-started/set-up-a-model/index.md) tutorial walks through both paths. Run `docker agent doctor` to see which providers have credentials and whether Docker Model Runner is reachable.
+
+### Docker Model Runner model not pulled
+
+A `dmr/...` model was requested but isn't available locally:
+
+```text
+model ai/qwen3 is not pulled in Docker Model Runner
+
+To resolve this, you can:
+  - Pull it first: docker model pull ai/qwen3
+  - Or choose a model that is already available (see `docker model ls`).
+```
+
+If instead you see `cannot query Docker Model Runner at <url>`, Docker Model Runner isn't installed or running — see the [Model Runner get-started guide](https://docs.docker.com/ai/model-runner/get-started/).
+
+> [!TIP]
+> **Diagnose before you run**
+>
+> Run `docker agent doctor` (or `docker agent doctor ./agent.yaml` to include a file's requirements) to check all three issues in one shot. It exits non-zero when something would block a run, making it useful as a CI preflight. See the [CLI reference](../../features/cli/index.md#docker-agent-doctor).
+
+## Debug Mode
+
+The first step for any issue is enabling debug logging. This provides detailed information about what Docker Agent is doing internally.
+
+```bash
+# Enable debug logging (writes to ~/.cagent/cagent.debug.log)
+$ docker agent run config.yaml --debug
+
+# Write debug logs to a custom file
+$ docker agent run config.yaml --debug --log-file ./debug.log
+
+# Enable OpenTelemetry tracing for deeper analysis
+$ docker agent run config.yaml --otel
+```
+
+> [!TIP]
+> Always enable `--debug` when reporting issues. The log file contains detailed traces of API calls, tool executions, and agent interactions.
+
+## Agent Not Responding
+
+### API keys not set
+
+Each model provider requires its own API key as an environment variable:
+
+| Provider      | Environment Variable                                |
+| ------------- | --------------------------------------------------- |
+| OpenAI        | `OPENAI_API_KEY`                                    |
+| Anthropic     | `ANTHROPIC_API_KEY`                                 |
+| Google Gemini | `GOOGLE_API_KEY` or `GEMINI_API_KEY`                |
+| Mistral       | `MISTRAL_API_KEY`                                   |
+| xAI           | `XAI_API_KEY`                                       |
+| Nebius        | `NEBIUS_API_KEY`                                    |
+| MiniMax       | `MINIMAX_API_KEY`                                   |
+| Requesty      | `REQUESTY_API_KEY`                                  |
+| OpenRouter    | `OPENROUTER_API_KEY`                                |
+| GitHub Copilot | `GITHUB_TOKEN` (PAT with `copilot` scope)          |
+| Azure OpenAI  | `AZURE_API_KEY` (override with `token_key`)         |
+| AWS Bedrock   | `AWS_BEARER_TOKEN_BEDROCK` or AWS credentials chain |
+
+```bash
+# Verify your keys are set
+$ env | grep API_KEY
+```
+
+### Incorrect model name
+
+Model names must match the provider's naming exactly. Common mistakes:
+
+- Using a deprecated model name (e.g. `gpt-4` instead of `gpt-5-mini` or `gpt-4o`)
+- Model references are case-sensitive: `openai/gpt-5-mini` ≠ `openai/GPT-5-mini`
+
+### Network connectivity
+
+If the agent hangs or times out, check that you can reach the provider's API endpoint. Firewalls, VPNs, or proxy settings may block requests.
+
+## Tool Execution Failures
+
+### MCP tools not found or failing
+
+- Ensure the MCP tool command is installed and on your `PATH`
+- Check file permissions — tools need to be executable
+- Test MCP tools independently before integrating with Docker Agent
+- For Docker-based MCP tools (`ref: docker:*`), ensure Docker Desktop is running
+
+### Filesystem / shell tool errors
+
+- Verify the agent has the correct toolset configured (`type: filesystem`, `type: shell`)
+- Check that the working directory exists and is accessible
+- On macOS, ensure terminal has the necessary permissions (e.g., Full Disk Access)
+
+### Tool lifecycle issues
+
+MCP and LSP toolsets are managed by a supervisor that auto-restarts them when they crash or drop their session. The TUI exposes that supervisor through two slash commands:
+
+- `/tools` — the unified tools dialog. Its top section lists every toolset with its current state (`Stopped`, `Starting`, `Ready`, `Degraded`, `Restarting`, `Failed`), restart count, and last error; the bottom section lists every tool the agent can call. Start here whenever a tool seems missing or stuck.
+- `/toolset-restart <name>` — force a supervisor-driven reconnect of the named toolset. Useful after completing OAuth, when a remote MCP server has been redeployed, or when a language server like `gopls` is unresponsive.
+
+Remote MCP servers that return `401 invalid_token` (e.g. because the stored OAuth token was revoked or rotated) are now self-healing: Docker Agent silently exchanges the refresh token for a new one when possible, or surfaces an OAuth re-authentication prompt on your next message when refresh is not possible. No more stuck toolsets that require a process restart — but if you want to trigger re-auth immediately, `/toolset-restart <name>` forces it right away.
+
+MCP tools using stdio transport must complete the initialization handshake before becoming available. If tools fail silently:
+
+1. Run `/tools` to see whether the toolset is `Failed` or stuck in `Restarting`, and what the last error was.
+2. Enable `--debug` and look for MCP protocol messages in the log
+3. Check that the MCP server process starts and responds to `initialize`
+4. Verify environment variables required by the tool are set (check `env` and `env_file` in the toolset config)
+
+> [!NOTE]
+> **Startup tool-listing timeout**
+>
+> At startup, Docker Agent queries each toolset for its tool list. If a toolset does not respond within 10 seconds (e.g. a wedged MCP stdio server that never answers `tools/list`), that toolset is skipped with a warning and the remaining toolsets load normally. The sidebar resolves showing whichever tools did load — no infinite spinner. Enable `--debug` to see the warning message, and use `/toolset-restart <name>` once the server becomes responsive.
+
+If a toolset keeps crashing in a tight loop, tune the [`lifecycle`](../../configuration/tools/index.md#toolset-lifecycle) block on the toolset (e.g. raise `backoff.initial`, lower `max_restarts`, or switch to the `best-effort` profile) so a flaky dependency does not amplify into a restart storm.
+
+## Configuration Errors
+
+### YAML syntax issues
+
+Docker Agent validates config at startup and reports errors with line numbers. Common problems:
+
+- Incorrect indentation (YAML is whitespace-sensitive)
+- Missing quotes around values containing special characters (`:`, `#`, `{`, `}`)
+- Using tabs instead of spaces
+
+### Missing references
+
+- Local agents in `sub_agents` must be defined in the `agents` section (external OCI references like `myorg/agent:tag` are resolved from registries automatically)
+- Named model references must exist in the `models` section (or use inline format like `openai/gpt-5`)
+- RAG source names referenced by agents must be defined in the `rag` section
+
+### Toolset validation
+
+- The `path` field is valid for `memory` and `tasks` toolsets, and for the agent-level `cache` block
+- MCP toolsets need either `command` (stdio), `remote` (Streamable HTTP/SSE), or `ref` (Docker)
+- Provider names must be one of: `openai`, `anthropic`, `google`, `amazon-bedrock`, `dmr`, etc.
+
+> [!NOTE]
+> **Schema Validation**
+>
+> Use the [JSON schema](https://github.com/docker/docker-agent/blob/main/agent-schema.json) in your editor for real-time config validation and autocompletion.
+
+## Session &amp; Connectivity Issues
+
+### Downgrade fails with a newer-database error
+
+If an older Docker Agent binary cannot open the session database after an upgrade,
+the database may contain a schema migration that the older binary does not know.
+Restore a database created by the older version, or use a binary that includes the
+migration.
+
+### Port conflicts
+
+When running Docker Agent as an API server or MCP server, ensure the port is not already in use:
+
+```bash
+# Check if port 8080 is in use
+$ lsof -i :8080
+
+# Use a different port
+$ docker agent serve api config.yaml --listen :9090
+```
+
+### MCP endpoint accessibility
+
+For remote MCP servers, verify the endpoint is reachable:
+
+```bash
+# Test streamable HTTP endpoint
+$ curl -v https://mcp-server.example.com/mcp
+```
+
+### Session isolation
+
+The API server stores every conversation as a distinct session in the SQLite database (`session.db` by default). Each session is identified by its UUID and only mixes messages when the same session ID is reused. If conversations seem to bleed into each other:
+
+- Make sure each client creates a fresh session via `POST /api/sessions` (don't reuse session IDs across users).
+- Confirm `--session-db` points to the path you expect — a stale database from another run can resurface old sessions.
+- Use `GET /api/sessions/:id` to inspect what is actually stored, and `DELETE /api/sessions/:id` to clear sessions you don't want anymore.
+
+### HTTP 413: request body too large
+
+Three kinds of process reject an oversized request body with `413 Request Entity Too Large`: `docker agent serve api`, `docker agent serve chat`, and an interactive run's control plane ([`docker agent run --listen`](../../features/api-server/index.md#listen)). They aren't configured the same way: `serve api` and `serve chat` each expose their own `--max-request-size` flag (1 MiB default). A `--listen` control plane has no such flag — it enforces a fixed, non-configurable 1 MiB limit — and no `--auth-token` either. Work through these layers in order:
+
+1. **Identify which server is involved.** `serve api`, `serve chat`, and an attached run's `--listen` control plane are three separate kinds of process. `serve api` and `serve chat` each have their own `--max-request-size` flag and 1 MiB default — check the flags the process that returned the 413 was actually started with. A `--listen` control plane has no `--max-request-size` flag: its 1 MiB cap is fixed.
+2. **Measure the serialized request body, not a source file's size.** JSON string escaping and, for any base64-encoded binary content, base64's ~33% expansion both inflate the wire size well past the original file size — a file just under the limit can still push the encoded request over it.
+3. **Rule out an intermediary.** If a reverse proxy, gateway, or load balancer sits in front of Docker Agent, it usually enforces its own, independent body-size limit — often with a differently formatted error — and can reject the request before Docker Agent ever sees it.
+4. **Confirm who actually returned the error.** A 413 (or a context-length error) can also come from the model provider itself once the request reaches it; that is a separate limit unrelated to `--max-request-size` — see [Context Window Exceeded](#context-window-exceeded) above.
+5. **Resolve it.** Once you've confirmed Docker Agent's own server rejected the request, send less content — split it across turns. On `serve api` or `serve chat` you can also restart the server with a deliberately chosen, larger `--max-request-size` (see [API Server](../../features/api-server/index.md#cli-flags) or [Chat Server](../../features/chat-server/index.md#cli-flags)). A `--listen` control plane has no `--max-request-size` flag to raise — sending less content is the only fix.
+
+A few things that catch people out:
+
+- `--max-request-size` is set once at process startup and applies to every request that server handles — it isn't per-request or per-client. Only `serve api` and `serve chat` have it; a `--listen` control plane's 1 MiB cap can't be changed.
+- `0` or a negative value falls back to the 1 MiB default; it does not mean "no limit".
+- Retrying the same oversized body against the same server won't succeed — the limit doesn't change between requests.
+- On all three, the body-size check runs ahead of request authentication, so an oversized request can come back as 413 even without valid credentials.
+- Piping stdin into a **local** run (`docker agent run agent.yaml -`) never crosses Docker Agent's own inbound HTTP boundary — Docker Agent may still send that content onward to a model/provider over HTTP, but no request reaches Docker Agent's own server to be measured against a `--max-request-size` cap. Piping stdin into `docker agent run --remote ... -`, however, does cross that boundary: the CLI serializes that stdin text into a native API run request and sends it to whichever Docker Agent server the `--remote` address points at — a `serve api` process or another run's `--listen` control plane, never `serve chat`, which speaks a different protocol — so it's measured against that server's own limit like any other request (a configurable `--max-request-size` for `serve api`, or the fixed 1 MiB cap for a `--listen` control plane). That initial request carries only message text — conversion currently drops any attachment resolved locally (`@path`, `/attach`, `--attach`) for the first message, so it alone can't be the cause of a 413. But a `--remote` run doesn't stay text-only for its whole lifetime: a locally resolved attachment added to a *later* message while the agent is still busy — via the default steer behavior or an explicit follow-up (Alt+Enter) — is forwarded as part of that native API request, counts toward the same limit, and can trigger 413 just like any other oversized request.
+
+> [!WARNING]
+> Raising `--max-request-size` increases how much memory an unauthenticated or malicious client can force the server to buffer per request. Pick a value with your deployment's exposure in mind, and pair any non-loopback listener with `--auth-token` (API server) or `--api-key`/`--api-key-env` (chat server). A `--listen` control plane has neither flag — keep it on loopback, a unix socket, or behind an authenticating reverse proxy if it must be reachable from elsewhere.
+
+## Performance Issues
+
+### High memory usage
+
+- Large context windows (64K+ tokens) consume significant memory — consider reducing `max_tokens`
+- Use `num_history_items` in agent config to limit conversation history
+- For DMR (local models), tune `runtime_flags` for your hardware (e.g., `--ngl` for GPU layers)
+
+### Slow responses
+
+- Check if MCP tools are adding latency (visible in debug logs)
+- Use the `/cost` command in TUI to see token usage and identify expensive interactions
+- For DMR, consider enabling [speculative decoding](../../providers/dmr/index.md) for faster inference
+
+### Tool resource leaks
+
+Monitor for tools that don't clean up properly — check debug logs for MCP server start/stop lifecycle events. Orphaned tool processes can consume system resources.
+
+## Agent Store Issues
+
+### Pull / push failures
+
+```bash
+# Test registry connectivity
+$ docker pull docker.io/username/agent:latest
+
+# Verify pulled agent content
+$ docker agent share pull docker.io/username/agent:latest
+```
+
+### Agent content issues
+
+- Ensure the pushed YAML is valid — run `docker agent run` locally before pushing
+- Check that referenced resources (MCP tools, files) are available on the target machine
+- For auto-refresh (`--pull-interval`), verify the registry is accessible from the server
+
+## Log Analysis
+
+When reviewing debug logs, search for these key patterns:
+
+| Log Pattern                 | What It Indicates                                                                                |
+| --------------------------- | ------------------------------------------------------------------------------------------------ |
+| `"Starting runtime stream"` | Agent execution beginning                                                                        |
+| `"Tool call"`               | A tool is being executed                                                                         |
+| `"Tool call result"`        | Tool execution completed                                                                         |
+| `"Stream stopped"`          | Agent finished processing                                                                        |
+| `HTTP 429`                  | Rate limiting — consider adding a [fallback model](../../configuration/agents/index.md) |
+| `context canceled`          | Operation was interrupted (timeout or user cancel)                                               |
+| `[RAG Manager]`             | RAG retrieval operations                                                                         |
+| `[Reranker]`                | Reranking operations                                                                             |
+
+> [!WARNING]
+> **Still stuck?**
+>
+> If these steps don't resolve your issue, file a bug on the [GitHub issue tracker](https://github.com/docker/docker-agent/issues) with your debug log attached, or ask on [Slack](https://dockercommunity.slack.com/archives/C09DASHHRU4).
diff --git a/_vendor/github.com/docker/docker-agent/docs/concepts/_index.md b/_vendor/github.com/docker/docker-agent/docs/concepts/_index.md
new file mode 100644
index 000000000000..a4a44d04328a
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/concepts/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Core Concepts"
+description: "The core ideas behind Docker Agent: agents, models, tools, and multi-agent teams."
+weight: 20
+---
diff --git a/_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md b/_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md
new file mode 100644
index 000000000000..092f7af5104c
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md
@@ -0,0 +1,114 @@
+---
+title: "Agents"
+description: "Agents are the core building blocks of Docker Agent. Each agent is an AI-powered entity with a model, instructions, tools, and optional sub-agents."
+keywords: docker agent, ai agents, concepts, agents
+weight: 10
+canonical: https://docs.docker.com/ai/docker-agent/concepts/agents/
+---
+
+_Agents are the core building blocks of Docker Agent. Each agent is an AI-powered entity with a model, instructions, tools, and optional sub-agents._
+
+## What is an Agent?
+
+An agent in Docker Agent is defined by:
+
+- **Model** — The AI model powering it (e.g., Claude, GPT-5, Gemini). See [Models](../models/index.md).
+- **Description** — A brief summary of what the agent does (used by other agents for delegation)
+- **Instruction** — The system prompt that defines the agent's behavior and personality
+- **Tools** — Capabilities like filesystem access, shell commands, or external APIs
+- **Sub-agents** — Other agents it can delegate tasks to
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Expert software developer
+    instruction: |
+      You are an expert developer. Write clean, efficient code
+      and explain your reasoning step by step.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
+
+## The Root Agent
+
+Every Docker Agent configuration has a **root agent** — the entry point that receives user messages. In a single-agent setup, this is the only agent. In a multi-agent setup, the root agent acts as a coordinator, delegating tasks to specialized sub-agents.
+
+> [!NOTE]
+> **Naming**
+>
+> The first agent defined in your YAML (or the one named `root`) is the root agent by default. You can also specify which agent to start with using `docker agent run config.yaml -a agent_name`.
+
+## Agent Properties
+
+| Property               | Type    | Required | Description                                                    |
+| ---------------------- | ------- | -------- | -------------------------------------------------------------- |
+| `model`                | string  | ✓        | Model reference (inline like `openai/gpt-5` or a named model) |
+| `description`          | string  | ✓        | What the agent does — used by other agents for delegation      |
+| `instruction`          | string  | ✓        | System prompt defining behavior                                |
+| `toolsets`             | array   | ✗        | List of tool configurations                                    |
+| `sub_agents`           | array   | ✗        | Names of agents this agent can delegate to                     |
+| `fallback`             | object  | ✗        | Fallback model configuration for resilience                    |
+| `add_date`             | boolean | ✗        | Include current date in context                                |
+| `add_environment_info` | boolean | ✗        | Include OS, working directory, git info in context             |
+| `max_iterations`       | int     | ✗        | Max tool-calling loops (default: unlimited)                    |
+| `commands`             | object  | ✗        | Named prompts callable via `/command`                          |
+| `skills`               | boolean \| list | ✗    | Enable skill discovery and loading. `true` = `["local"]`; list values may combine `"local"` with remote skill-server URLs. |
+
+## Model Fallbacks
+
+Agents can automatically fail over to alternative models when the primary model is unavailable:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    fallback:
+      models:
+        - openai/gpt-5
+        - google/gemini-3.5-flash
+      retries: 2 # retries per model for 5xx errors
+      cooldown: 1m # stick with fallback after 429
+```
+
+## Named Commands
+
+Define reusable prompts that can be invoked as commands:
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5
+    instruction: You are a helpful assistant.
+    commands:
+      df: "Check how much free space I have on my disk"
+      greet: "Say hello to ${env.USER}"
+```
+
+```bash
+# Run a named command
+$ docker agent run agent.yaml /df
+$ docker agent run agent.yaml /greet
+```
+
+Commands support environment variable interpolation using JavaScript template literal syntax. Undefined variables expand to empty strings.
+
+## Default Agent
+
+Running `docker agent run` without a config argument uses `docker-agent.yaml`, `docker-agent.yml`, or `docker-agent.hcl` from the current directory when present. Otherwise, it uses a capable built-in default agent for quick tasks without needing any configuration.
+
+```bash
+# Use the project config or built-in default agent
+$ docker agent run
+
+# Override the default with an alias
+$ docker agent alias add default /path/to/my-agent.yaml
+$ docker agent run  # now runs your custom agent
+```
+
+> [!TIP]
+> **See also**
+>
+> For reusable task-specific instructions, see [Skills](../../features/skills/index.md). For multi-agent patterns, see [Multi-Agent](../multi-agent/index.md). For full config reference, see [Agent Config](../../configuration/agents/index.md).
diff --git a/_vendor/github.com/docker/docker-agent/docs/concepts/distribution/index.md b/_vendor/github.com/docker/docker-agent/docs/concepts/distribution/index.md
new file mode 100644
index 000000000000..a2ea3aafde5f
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/concepts/distribution/index.md
@@ -0,0 +1,135 @@
+---
+title: "Agent Distribution"
+description: "Package, share, and run agents via OCI-compatible registries — just like container images."
+keywords: docker agent, ai agents, concepts, agent distribution
+weight: 50
+canonical: https://docs.docker.com/ai/docker-agent/concepts/distribution/
+aliases:
+  - /ai/docker-agent/sharing-agents/
+---
+
+_Package, share, and run agents via OCI-compatible registries — just like container images._
+
+## Overview
+
+Docker Agent agents can be pushed to any OCI-compatible registry (Docker Hub, GitHub Container Registry, etc.) and pulled/run anywhere. This makes sharing agents as easy as sharing Docker images.
+
+> [!TIP]
+> For CLI commands related to distribution, see [CLI Reference](../../features/cli/index.md) (`docker agent share push`, `docker agent share pull`, `docker agent alias`).
+
+## Pushing Agents
+
+```bash
+# Push to Docker Hub
+$ docker agent share push ./agent.yaml docker.io/username/my-agent:latest
+
+# Push to GitHub Container Registry
+$ docker agent share push ./agent.yaml ghcr.io/username/my-agent:v1.0
+```
+
+## Pulling Agents
+
+```bash
+# Pull an agent
+$ docker agent share pull docker.io/username/my-agent:latest
+
+# Pull from Docker Hub shorthand
+$ docker agent share pull myorg/agent:tag
+```
+
+## Running from a Registry
+
+Run agents directly from a registry without pulling first:
+
+```bash
+# Run directly from Docker Hub
+$ docker agent run docker.io/username/my-agent:latest
+
+# Docker Hub shorthand (docker.io is implied)
+$ docker agent run myorg/agent:tag
+
+# Run with a specific agent from a multi-agent config
+$ docker agent run docker.io/username/dev-team:latest -a developer
+```
+
+## Using as Sub-Agents
+
+Registry agents can be used directly as sub-agents in a multi-agent configuration — no need to define them locally:
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5
+    description: Coordinator
+    instruction: Delegate tasks to the right sub-agent.
+    sub_agents:
+      - myorg/agent:tag             # auto-named "agent"
+      - my_reviewer:myorg/reviewer  # explicitly named "my_reviewer"
+```
+
+External sub-agents are automatically named after their last path segment. Use the `name:reference` syntax to give them a custom name.
+
+Tag references are checked against the registry on every `docker agent run`, which adds a network round-trip per sub-agent at startup. Pin them to a digest (`myorg/agent@sha256:…`) to serve them from cache instead.
+
+See [Pin external sub-agents to a digest](../multi-agent/index.md#pin-external-sub-agents-to-a-digest) and [External Sub-Agents](../multi-agent/index.md#external-sub-agents-from-registries) for details.
+
+## Using with Aliases
+
+Combine OCI references with aliases for convenient access:
+
+```bash
+# Create an alias for a registry agent
+$ docker agent alias add coder myorg/coder --yolo
+
+# Now just run
+$ docker agent run coder
+```
+
+## Using with API Server
+
+The API server supports OCI references with auto-refresh:
+
+```bash
+# Start API from registry, auto-pull every 10 minutes
+$ docker agent serve api docker.io/username/agent:latest --pull-interval 10
+```
+
+## Private Repositories
+
+Docker Agent supports pulling from private GitHub repositories and registries that require authentication. Use standard Docker login or GitHub authentication:
+
+```bash
+# Login to a registry
+$ docker login docker.io
+
+# Now push/pull works with private repos
+$ docker agent share push ./agent.yaml docker.io/myorg/private-agent:latest
+$ docker agent run docker.io/myorg/private-agent:latest
+```
+
+> [!NOTE]
+> **Docker authentication**
+>
+> When pulling or running an agent from a `docker.com` or `*.docker.com` HTTPS URL (e.g. `desktop.docker.com`), Docker Agent automatically forwards a Docker token for authentication. If Docker Desktop is running and signed in, its token is used; otherwise, Docker Agent exchanges the access token stored by `docker login` for a fresh Docker token. Either way, no explicit login step is required beyond `docker login` (or being signed into Docker Desktop).
+>
+> Note: `docker.io` (the standard Docker Hub registry domain) is a separate domain and is **not** covered by automatic token forwarding. Agents pulled from `docker.io` or `registry-1.docker.io` still require `docker login docker.io` for private repositories.
+
+> [!NOTE]
+> **Troubleshooting**
+>
+> Having issues with push/pull? See [Troubleshooting](../../community/troubleshooting/index.md) for common registry issues.
+
+## Local Development
+
+For local development and testing, you can run an agent directly from a local HTTP server without a registry:
+
+```bash
+# Serve an agent config locally
+$ python3 -m http.server 8080
+
+# Run it directly via HTTP
+$ docker agent run http://localhost:8080/agent.yaml
+$ docker agent run http://127.0.0.1:8080/agent.yaml
+```
+
+This is useful for iterating on agent configs served from a local dev server before pushing to a registry. Both `localhost` and `127.0.0.1` addresses are supported with plain `http://` URLs.
diff --git a/_vendor/github.com/docker/docker-agent/docs/concepts/models/index.md b/_vendor/github.com/docker/docker-agent/docs/concepts/models/index.md
new file mode 100644
index 000000000000..d966769d4562
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/concepts/models/index.md
@@ -0,0 +1,175 @@
+---
+title: "Models"
+description: "Models are the AI brains behind your agents. Docker Agent supports multiple providers and flexible configuration."
+keywords: docker agent, ai agents, concepts, models
+weight: 20
+canonical: https://docs.docker.com/ai/docker-agent/concepts/models/
+---
+
+_Models are the AI brains behind your agents. Docker Agent supports multiple providers and flexible configuration._
+
+## Inline vs. Named Models
+
+There are two ways to assign a model to an agent:
+
+### Inline (Quick)
+
+Use the `provider/model` shorthand directly in the agent definition:
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5
+    instruction: You are a helpful assistant.
+```
+
+### Named (Full Control)
+
+Define models in a `models` section and reference them by name:
+
+```yaml
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    max_tokens: 64000
+    temperature: 0.7
+
+agents:
+  root:
+    model: claude
+    instruction: You are a helpful assistant.
+```
+
+Named models let you configure temperature, token limits, thinking budgets, and other parameters. They're also reusable across multiple agents.
+
+## First Available Models
+
+A named model can also select the first usable model from a priority list. This
+is useful for shared configs that should prefer paid cloud models when their API
+keys are present, but still work with a local fallback:
+
+```yaml
+models:
+  smart:
+    first_available:
+      - anthropic/claude-sonnet-4-5
+      - openai/gpt-5
+      - dmr/ai/qwen3
+
+agents:
+  root:
+    model: smart
+    instruction: You are a helpful assistant.
+```
+
+At load time, Docker Agent selects the first candidate whose credentials are
+configured. You only need credentials for one candidate. See
+[Model Configuration](../../configuration/models/index.md#first-available-models)
+for details.
+
+## Supported Providers
+
+| Provider            | Key              | Example Models                       | API Key Env Var                     |
+| ------------------- | ---------------- | ------------------------------------ | ----------------------------------- |
+| OpenAI              | `openai`         | gpt-5, gpt-5-mini, gpt-4o            | `OPENAI_API_KEY`                    |
+| Anthropic           | `anthropic`      | claude-sonnet-4-5, claude-opus-5     | `ANTHROPIC_API_KEY`                 |
+| Google              | `google`         | gemini-3.5-flash, gemini-3-pro       | `GOOGLE_API_KEY` / `GEMINI_API_KEY` |
+| AWS Bedrock         | `amazon-bedrock` | Claude, Nova, Llama models           | AWS credentials                     |
+| Docker Model Runner | `dmr`            | ai/qwen3, ai/llama3.2                | None (local)                        |
+| Mistral             | `mistral`        | Mistral models                       | `MISTRAL_API_KEY`                   |
+| xAI                 | `xai`            | Grok models                          | `XAI_API_KEY`                       |
+| Nebius              | `nebius`         | Open-source and specialised models   | `NEBIUS_API_KEY`                    |
+| NVIDIA NIM          | `nvidia`         | Nemotron, Llama, Qwen, DeepSeek (open models) | `NVIDIA_API_KEY`               |
+| MiniMax             | `minimax`        | MiniMax models                       | `MINIMAX_API_KEY`                   |
+| Baseten             | `baseten`        | DeepSeek, Kimi, GLM, Llama models    | `BASETEN_API_KEY`                   |
+| OVHcloud            | `ovhcloud`       | Qwen, Llama, Mistral, DeepSeek (EU-hosted) | `OVH_AI_ENDPOINTS_ACCESS_TOKEN` |
+| Groq                | `groq`           | Llama, Qwen, GPT-OSS (fast inference) | `GROQ_API_KEY`                     |
+| Fireworks AI        | `fireworks`      | Kimi, Llama, Qwen, DeepSeek, GLM (open models) | `FIREWORKS_API_KEY`         |
+| DeepSeek            | `deepseek`       | DeepSeek-V3 chat and R1 reasoner     | `DEEPSEEK_API_KEY`                  |
+| Cerebras            | `cerebras`       | GPT-OSS, GLM (fast inference)         | `CEREBRAS_API_KEY`                  |
+| Together AI         | `together`       | Llama, Qwen, DeepSeek, Kimi (open models) | `TOGETHER_API_KEY`             |
+| Hugging Face        | `huggingface`    | Llama, Qwen, DeepSeek, GLM (open models) | `HF_TOKEN`                      |
+| Cloudflare Workers AI | `cloudflare-workers-ai` | Llama, Mistral, Qwen, Gemma (edge-hosted open models) | `CLOUDFLARE_API_TOKEN` + `CLOUDFLARE_ACCOUNT_ID` |
+| Moonshot AI         | `moonshot`       | Kimi K2 chat, reasoning, and coding models | `MOONSHOT_API_KEY`             |
+| Vercel AI Gateway   | `vercel`         | Multi-provider gateway               | `AI_GATEWAY_API_KEY`                |
+| Cloudflare AI Gateway | `cloudflare-ai-gateway` | Multi-provider gateway         | `CLOUDFLARE_API_TOKEN` + `CLOUDFLARE_ACCOUNT_ID` + `CLOUDFLARE_GATEWAY_ID` |
+| Requesty            | `requesty`       | Multi-provider gateway               | `REQUESTY_API_KEY`                  |
+| OpenRouter          | `openrouter`     | Multi-provider gateway               | `OPENROUTER_API_KEY`                |
+| Azure OpenAI        | `azure`          | gpt-4o, gpt-5 on Azure               | `AZURE_API_KEY` + `base_url`        |
+| [Ollama](../../providers/local/index.md) | `ollama` | Any local Ollama model | None (local; optional `base_url`) |
+| GitHub Copilot      | `github-copilot` | Copilot-hosted OpenAI/Anthropic      | `GITHUB_TOKEN` (PAT with `copilot`) |
+| ChatGPT (OpenAI account) | `chatgpt`   | gpt-5 family via ChatGPT subscription | None (sign in via `docker agent setup`) |
+
+See the [Model Providers](../../providers/overview/index.md) section for detailed configuration guides.
+
+## Model Properties
+
+| Property            | Type       | Description                                       |
+| ------------------- | ---------- | ------------------------------------------------- |
+| `provider`          | string     | Provider identifier (required)                    |
+| `model`             | string     | Model name (required)                             |
+| `description`       | string     | Human-readable summary of the model's purpose     |
+| `temperature`       | float      | Randomness: 0.0 (deterministic) to 1.0 (creative) |
+| `max_tokens`        | int        | Maximum response length                           |
+| `top_p`             | float      | Nucleus sampling: 0.0 to 1.0                      |
+| `frequency_penalty` | float      | Reduce repetition: 0.0 to 2.0                     |
+| `presence_penalty`  | float      | Encourage topic diversity: 0.0 to 2.0             |
+| `base_url`          | string     | Custom API endpoint                               |
+| `thinking_budget`   | string/int | Reasoning effort configuration                    |
+| `task_budget`       | int/object | Total token budget for an agentic task (Anthropic; honored by Opus 4.7 today) |
+| `provider_opts`     | object     | Provider-specific options                         |
+
+## Reasoning / Thinking Budget
+
+Control how much the model "thinks" before responding:
+
+| Provider   | Format     | Values                                                              | Default                          |
+| ---------- | ---------- | ------------------------------------------------------------------- | -------------------------------- |
+| OpenAI     | string     | `minimal`, `low`, `medium`, `high`, `xhigh`, `max`                  | `medium` (always-reasoning models only) |
+| Anthropic  | int or str | 1024–32768 tokens, or `adaptive`, `adaptive/<effort>`, effort level | off                              |
+| Gemini 2.5 | int        | 0 (off), -1 (dynamic), or token count                               | -1 (dynamic)                     |
+| Gemini 3   | string     | `minimal`, `low`, `medium`, `high`                                  | varies                           |
+| All        | string/int | `none` or `0` clears Docker Agent's local config                    | —                                |
+
+`none` and `0` are not universal API-level disable switches. On genuine OpenAI
+gpt-5.6+ endpoints (Sol/Terra/Luna), `none` is a real `reasoning_effort` value
+that Docker Agent sends as-is and the model does not reason. On older OpenAI
+models, `none`/`0` only clear the local `thinking_budget` — omitting the field
+has the same effect — and the model falls back to the API's own default effort
+(still reasoning internally for always-reasoning models like the o-series).
+Providers with a true optional-thinking switch (Gemini 2.5, Claude, local
+models) are fully disabled by `none`/`0`. See the
+[Thinking / Reasoning guide](../../guides/thinking/index.md#disabling-thinking)
+for the full per-provider breakdown.
+
+```yaml
+models:
+  deep-thinker:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    thinking_budget: 16384
+
+  fast-responder:
+    provider: openai
+    model: gpt-5.6
+    thinking_budget: none # real API-level disable on gpt-5.6+
+```
+
+> [!NOTE]
+> **Multi-provider teams**
+>
+> Different agents can use different providers in the same config. See [Multi-Agent](../multi-agent/index.md) for patterns.
+
+## Alloy Models
+
+"Alloy models" let you use more than one model in the same conversation — Docker Agent alternates between them to leverage the strengths of each:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5,openai/gpt-5
+    instruction: You are a helpful assistant.
+```
+
+Read more about the alloy model concept at [xbow.com/blog/alloy-agents](https://xbow.com/blog/alloy-agents).
diff --git a/_vendor/github.com/docker/docker-agent/docs/concepts/multi-agent/index.md b/_vendor/github.com/docker/docker-agent/docs/concepts/multi-agent/index.md
new file mode 100644
index 000000000000..e9632ff020d5
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/concepts/multi-agent/index.md
@@ -0,0 +1,421 @@
+---
+title: "Multi-Agent Systems"
+description: "Build teams of specialized agents that collaborate and delegate tasks to each other."
+keywords: docker agent, ai agents, concepts, multi-agent systems
+linkTitle: "Multi-Agent"
+weight: 40
+canonical: https://docs.docker.com/ai/docker-agent/concepts/multi-agent/
+---
+
+_Build teams of specialized agents that collaborate and delegate tasks to each other._
+
+## Why Multi-Agent?
+
+Complex tasks benefit from specialization. Instead of one monolithic agent trying to do everything, you can create a **team** of focused agents:
+
+- A **coordinator** that understands the overall goal and delegates
+- A **developer** that writes code with filesystem and shell access
+- A **reviewer** that checks code quality
+- A **researcher** that searches the web for information
+
+Each agent has its own model, tools, and instructions — optimized for its specific role.
+
+## Two Patterns: Delegation vs. Handoffs
+
+Docker Agent supports two multi-agent patterns:
+
+| | **Delegation** (`sub_agents`) | **Handoffs** (`handoffs`) |
+|---|---|---|
+| **Topology** | Hierarchical (parent → child → parent) | Peer-to-peer graph (A → B → C → A) |
+| **Session** | Child runs in a **sub-session** | Conversation stays in the **same session** |
+| **Context** | Child gets a clean task description | Next agent sees the **full conversation history** |
+| **Control flow** | Parent blocks until child finishes, then continues | Active agent switches — previous agent is no longer in the loop |
+| **Tool** | `transfer_task` | `handoff` |
+| **Best for** | Task delegation to specialists | Pipeline workflows, conversational routing |
+
+You can combine both patterns in the same configuration — an agent can have both `sub_agents` and `handoffs`.
+
+> [!TIP]
+> **When to use which**
+>
+> **`sub_agents`** — Use when a coordinator needs to send tasks to specialists and synthesize their results.
+>
+> **`handoffs`** — Use when agents should take turns processing the same conversation (pipelines, routing).
+>
+> **`background_agents`** — Use when multiple independent tasks can run simultaneously.
+
+## Delegation with `sub_agents`
+
+Agents delegate tasks using the built-in `transfer_task` tool, which is automatically available to any agent with `sub_agents`. The parent agent sends a task to a child agent, waits for the result, and then continues.
+
+1. **User** sends a message to the root agent
+2. **Root agent** analyzes the request and decides which sub-agent should handle it
+3. **Root agent** calls `transfer_task` with the target agent, task description, and expected output
+4. **Sub-agent** processes the task in its own agentic loop using its tools
+5. **Results** flow back to the root agent, which responds to the user
+
+```bash
+# The transfer_task tool call looks like:
+transfer_task(
+  agent="developer",
+  task="Create a REST API endpoint for user authentication",
+  expected_output="Working Go code with tests"
+)
+```
+
+> [!NOTE]
+> **Auto-Approved**
+>
+> Unlike other tools, `transfer_task` is always auto-approved — no user confirmation needed. This allows seamless delegation between agents.
+
+## Handoffs Routing
+
+Handoffs are a peer-to-peer routing pattern where agents **hand off the entire conversation** to another agent. Unlike delegation, there is no sub-session — the conversation stays in a single session and the active agent simply switches.
+
+This pattern is ideal for:
+
+- **Pipeline workflows** — data flows through a chain of specialized agents
+- **Conversational routing** — a coordinator routes the user to the right specialist, who can route back when done
+- **Graph topologies** — agents can form cycles (A → B → C → A), enabling iterative workflows
+
+### How It Works
+
+1. **User** sends a message to the starting agent
+2. **Agent A** processes the message, then calls `handoff` to route to **Agent B**
+3. **Agent B** becomes the active agent and sees the **full conversation history**
+4. **Agent B** can respond, use its own tools, or hand off to another agent
+5. This continues until an agent responds directly without handing off
+
+```bash
+# The handoff tool call looks like:
+handoff(
+  agent="summarizer"
+)
+```
+
+> [!NOTE]
+> **Scoped Handoff Targets**
+>
+> Each agent can only hand off to agents listed in its own `handoffs` array. The `handoff` tool is automatically injected — you don't need to add it manually.
+
+### Example
+
+A coordinator routes to a researcher, who hands off to a summarizer, who returns to the coordinator:
+
+```text
+Root ──→ Researcher ──→ Summarizer ──→ Root
+```
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Coordinator that routes queries
+    instruction: |
+      Route research queries to the researcher.
+    handoffs:
+      - researcher
+
+  researcher:
+    model: openai/gpt-5
+    description: Web researcher
+    instruction: |
+      Search the web, then hand off to the summarizer.
+    toolsets:
+      - type: mcp
+        ref: docker:duckduckgo
+    handoffs:
+      - summarizer
+
+  summarizer:
+    model: openai/gpt-5
+    description: Summarizes findings
+    instruction: |
+      Summarize the research results, then hand off
+      back to root.
+    handoffs:
+      - root
+```
+
+> [!TIP]
+> **Full pipeline example**
+>
+> For a more complex handoff graph with branching and multiple processing stages, see [`examples/handoff.yaml`](https://github.com/docker/docker-agent/blob/main/examples/handoff.yaml).
+
+### Forced Handoffs
+
+With `handoffs`, the **model decides** whether to call the `handoff` tool — which means it can forget to, breaking pipelines that depend on a strict order. `force_handoff` removes that uncertainty: whenever the agent produces a final response, the **runtime itself** routes the conversation to the named agent, bypassing the LLM's tool-calling entirely. The full conversation context carries over.
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Extracts key facts from the input
+    instruction: |
+      Extract the key facts from the user's input as a bullet list.
+    force_handoff: summarizer
+
+  summarizer:
+    model: anthropic/claude-sonnet-4-5
+    description: Produces the final summary
+    instruction: |
+      Summarize the extracted facts for the user.
+```
+
+Rules enforced at config load time:
+
+- The target must be an agent defined in the config (or an external reference)
+- An agent cannot `force_handoff` to itself
+- Chains of `force_handoff` edges must not form a cycle (A → B → A is rejected)
+
+See [`examples/force_handoff.yaml`](https://github.com/docker/docker-agent/blob/main/examples/force_handoff.yaml) for a runnable example.
+
+## Parallel Delegation with Background Agents
+
+`transfer_task` is **sequential** — the coordinator waits for the sub-agent to finish before continuing. When you need to fan out work to multiple agents at the same time, use the `background_agents` toolset instead.
+
+Add it to your coordinator's toolsets:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Research coordinator
+    sub_agents: [researcher, analyst, writer]
+    toolsets:
+      - type: think
+      - type: background_agents
+```
+
+The coordinator can then:
+
+1. **Dispatch** several tasks at once with `run_background_agent` — each returns a task ID immediately
+2. **Monitor** progress with `list_background_agents` or `view_background_agent`
+3. **Collect** results once tasks complete
+4. **Cancel** tasks that are no longer needed with `stop_background_agent`
+
+```bash
+# Start two tasks in parallel
+run_background_agent(agent="researcher", task="Find recent papers on LLM agents")
+run_background_agent(agent="analyst", task="Analyze our current architecture")
+
+# Check on all tasks
+list_background_agents()
+
+# Read results when ready
+view_background_agent(task_id="agent_task_abc123")
+```
+
+## External Sub-Agents from Registries
+
+Sub-agents don't have to be defined locally — you can reference agents from any OCI-compatible registry directly in your `sub_agents` list. This lets you compose teams using shared agents without duplicating their configuration.
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5
+    description: Coordinator that delegates to local and external sub-agents
+    instruction: |
+      Delegate tasks to the most appropriate sub-agent.
+    sub_agents:
+      - local_helper
+      - myorg/agent:tag # pulled from registry automatically
+
+  local_helper:
+    model: openai/gpt-5
+    description: A local helper agent for simple tasks
+    instruction: You are a helpful assistant.
+```
+
+External sub-agents are automatically named after their last path segment (without the tag) — for example, `myorg/agent:tag` becomes `agent`. You can also give them an explicit name using the `name:reference` syntax:
+
+```yaml
+    sub_agents:
+      - my_agent:myorg/agent:tag  # available as "my_agent"
+      - reviewer:docker.io/myorg/review-agent:latest
+```
+
+### Pin external sub-agents to a digest
+
+External references use a tag by default: `myorg/agent` is shorthand for `myorg/agent:latest`. Tag references are re-resolved against the registry on **every** `docker agent run`: each unpinned external sub-agent triggers a digest lookup at startup, even when that sub-agent is never invoked in the session. On a healthy connection this typically adds a second or two per reference (it depends on your network and registry), and it is one of the paths that can stall if the registry or credential helper misbehaves.
+
+Pinning a reference to an immutable digest (`@sha256:…`) makes the runtime serve it straight from the local cache with no network round-trip, so startup stays fast and your team is fully reproducible:
+
+```yaml
+    sub_agents:
+      - reviewer:docker.io/myorg/review-agent@sha256:44117e73263afa5c861bdf3730dae7925918ffdd146827eee5bcff20bc55e8fa
+```
+
+Copy the digest from your registry (Docker Hub shows it next to the tag) or read it with a standard OCI tool such as `docker buildx imagetools inspect <reference>`. Docker Agent logs a startup warning for any external OCI reference that still uses a tag instead of a digest.
+
+External references in `handoffs` and `force_handoff` carry the same per-run cost, so pin those to a digest too.
+
+> [!TIP]
+> External sub-agents work with any OCI-compatible registry. See [Agent Distribution](../distribution/index.md) for more on registry references.
+>
+> See [`examples/sub-agents-from-registry.yaml`](https://github.com/docker/docker-agent/blob/main/examples/sub-agents-from-registry.yaml) for a complete example mixing local and external sub-agents.
+
+## Harness-Backed Sub-Agents
+
+Sub-agents can be backed by external coding CLIs — Claude Code, Codex, opencode, or pi — instead of a model API. Add a `harness:` block in place of a `model:` field to create a harness sub-agent:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Orchestrator that plans and delegates
+    instruction: |
+      Break down coding tasks and delegate to the coding agents.
+    sub_agents:
+      - claude-coder
+      - codex-coder
+
+  claude-coder:
+    description: Claude Code specialist
+    harness:
+      type: claude-code
+      effort: high
+
+  codex-coder:
+    description: Codex specialist
+    harness:
+      type: codex
+```
+
+The orchestrator uses `transfer_task` to send work to a harness sub-agent just like any other sub-agent. Docker Agent handles the orchestration and hooks; the external CLI drives the coding loop.
+
+> [!TIP]
+> **Learn more**
+>
+> See [Coding Harnesses](../../features/harnesses/index.md) for the full field reference, parallel dispatch patterns, and what does not work inside harness agents.
+
+## Example: Development Team
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Technical lead coordinating development
+    instruction: |
+      You are a technical lead managing a development team.
+      Analyze requests and delegate to the right specialist.
+      Ensure quality by reviewing results before responding.
+    sub_agents: [developer, reviewer, tester]
+    toolsets:
+      - type: think
+
+  developer:
+    model: anthropic/claude-sonnet-4-5
+    description: Expert software developer
+    instruction: |
+      You are an expert developer. Write clean, efficient code
+      and follow best practices.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+
+  reviewer:
+    model: openai/gpt-5
+    description: Code review specialist
+    instruction: |
+      You review code for quality, security, and maintainability.
+      Provide actionable feedback.
+    toolsets:
+      - type: filesystem
+
+  tester:
+    model: openai/gpt-5
+    description: Quality assurance engineer
+    instruction: |
+      You write tests and ensure software quality. Run tests
+      and report results.
+    toolsets:
+      - type: shell
+      - type: todo
+```
+
+## Example: Research Team
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Research coordinator
+    instruction: |
+      Coordinate research tasks. Delegate web searches to
+      the researcher and writing to the writer.
+    sub_agents: [researcher, writer]
+    toolsets:
+      - type: think
+
+  researcher:
+    model: openai/gpt-5
+    description: Web researcher
+    instruction: Search the web and gather information.
+    toolsets:
+      - type: mcp
+        ref: docker:duckduckgo
+      - type: memory
+        path: ./research.db
+
+  writer:
+    model: anthropic/claude-sonnet-4-5
+    description: Content writer
+    instruction: Write clear, well-structured content.
+    toolsets:
+      - type: filesystem
+```
+
+## Multi-Model Teams
+
+A key advantage of multi-agent systems is using different models for different roles — picking the best model for each job:
+
+```yaml
+models:
+  fast:
+    provider: openai
+    model: gpt-5-mini
+    temperature: 0.2 # precise
+
+  creative:
+    provider: openai
+    model: gpt-5
+    temperature: 0.8 # creative
+
+  local:
+    provider: dmr
+    model: ai/qwen3 # runs locally, no API cost
+
+agents:
+  analyst:
+    model: fast # cheap and fast for analysis
+  writer:
+    model: creative # creative for content
+  helper:
+    model: local # free for simple tasks
+```
+
+## Shared Tools
+
+Tools like `todo` can be shared between agents for collaborative task tracking:
+
+```yaml
+toolsets:
+  - type: todo
+    shared: true # all agents see the same todo list
+```
+
+## Best Practices
+
+- **Keep agents focused** — Each agent should have a clear, narrow role
+- **Write clear descriptions** — The coordinator uses descriptions to decide who to delegate to
+- **Give minimal tools** — Only give each agent the tools it needs for its specific role
+- **Use the think tool when needed** — For models without native reasoning, give coordinators the think tool so they reason about delegation. Models with built-in thinking (e.g., via `thinking_budget`) don't need it
+- **Use the right model** — Use capable models for complex reasoning, cheap models for simple tasks
+- **Choose the right pattern** — Use `sub_agents` for hierarchical task delegation, `handoffs` for pipeline workflows and conversational routing
+
+> [!NOTE]
+> **Beyond Docker Agent**
+>
+> For interoperability with other agent frameworks, Docker Agent supports the [A2A protocol](../../features/a2a/index.md) and can expose agents via [MCP Mode](../../features/mcp-mode/index.md).
diff --git a/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md b/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md
new file mode 100644
index 000000000000..149e876d9a7a
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md
@@ -0,0 +1,78 @@
+---
+title: "Tools"
+description: "Tools give agents the ability to interact with the world — read files, run commands, search the web, query databases, and more."
+keywords: docker agent, ai agents, concepts, tools
+weight: 30
+canonical: https://docs.docker.com/ai/docker-agent/concepts/tools/
+---
+
+_Tools give agents the ability to interact with the world — read files, run commands, search the web, query databases, and more._
+
+## How Tools Work
+
+When an agent needs to perform an action, it makes a **tool call**. The Docker Agent runtime executes the tool and returns the result to the agent, which can then use it to continue its work.
+
+1. Agent receives a user message
+2. Agent decides it needs to use a tool (e.g., read a file)
+3. Docker Agent executes the tool and returns the result
+4. Agent incorporates the result and responds
+
+> [!NOTE]
+> **Tool Confirmation**
+>
+> By default, Docker Agent asks for user confirmation before executing tools that have side effects (shell commands, file writes). Use `--yolo` to auto-approve all tool calls.
+
+## Built-in Tools
+
+Docker Agent ships with several built-in tools that require no external dependencies. Each is enabled by adding its `type` to the agent's `toolsets` list:
+
+| Tool | Description |
+| --- | --- |
+| [Filesystem](../../tools/filesystem/index.md) | Read, write, list, search, and navigate files and directories |
+| [Shell](../../tools/shell/index.md) | Execute shell commands synchronously |
+| [Background Jobs](../../tools/background-jobs/index.md) | Run and manage long-running shell commands |
+| [Think](../../tools/think/index.md) | Step-by-step reasoning scratchpad for planning and decision-making |
+| [Todo](../../tools/todo/index.md) | Task list management for complex multi-step workflows |
+| [Tasks](../../tools/tasks/index.md) | Persistent task database shared across sessions |
+| [Memory](../../tools/memory/index.md) | Persistent key-value storage backed by SQLite |
+| [Fetch](../../tools/fetch/index.md) | Read content from HTTP/HTTPS URLs (GET only) |
+| [Script](../../tools/script/index.md) | Define custom shell scripts as named tools |
+| [LSP](../../tools/lsp/index.md) | Connect to Language Server Protocol servers for code intelligence |
+| [API](../../tools/api/index.md) | Create custom tools that call HTTP APIs without writing code |
+| [OpenAPI](../../tools/openapi/index.md) | Generate tools from an OpenAPI 3.x document |
+| [RAG](../../tools/rag/index.md) | Retrieval-augmented generation over indexed sources |
+| [Model Picker](../../tools/model-picker/index.md) | Let the agent pick between several models per turn |
+| [User Prompt](../../tools/user-prompt/index.md) | Ask users questions and collect interactive input |
+| [Open URL](../../tools/open-url/index.md) | Open a fixed URL in the user's default browser |
+| [Transfer Task](../../tools/transfer-task/index.md) | Delegate tasks to sub-agents (auto-enabled with `sub_agents`) |
+| [Background Agents](../../tools/background-agents/index.md) | Dispatch work to sub-agents concurrently |
+| [Handoff](../../tools/handoff/index.md) | Hand the conversation off to another local agent in the same config (auto-enabled with `handoffs:`) |
+| [A2A](../../tools/a2a/index.md) | Connect to remote agents via the Agent-to-Agent protocol |
+| [MCP Catalog](../../tools/mcp-catalog/index.md) | Discover and activate remote MCP servers from the Docker MCP Catalog on demand |
+| [Git](../../tools/git/index.md) | Read-only git repository inspection |
+| [Scheduler](../../tools/scheduler/index.md) | Schedule instructions to run at a time or on a recurring interval |
+| [Webhook](../../tools/webhook/index.md) | Outbound notifications to Slack, Discord, Telegram, IFTTT, and more |
+| [Plan](../../tools/plan/index.md) | Shared persistent scratchpad for multi-agent collaboration |
+| [Session Plan](../../tools/session_plan/index.md) | Per-session plan tracker for the draft/review/execute workflow |
+| [Session Context](../../tools/session_context/index.md) | Reference a previous session as context |
+
+## MCP Tools
+
+Docker Agent supports the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) for extending agents with external tools. There are three ways to connect MCP tools:
+
+- **Docker MCP** (recommended) — Run MCP servers in Docker containers via the [MCP Gateway](https://github.com/docker/mcp-gateway). Browse the [Docker MCP Catalog](https://hub.docker.com/search?q=&type=mcp).
+- **Local MCP (stdio)** — Run MCP servers as local processes communicating over stdin/stdout.
+- **Remote MCP (Streamable HTTP / SSE)** — Connect to MCP servers running on a network. See [Remote MCP Servers](../../features/remote-mcp/index.md).
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:duckduckgo
+```
+
+See [Tool Config](../../configuration/tools/index.md#mcp-tools) for full MCP configuration reference.
+
+> [!TIP]
+> **See also**
+>
+> For full configuration reference, see [Tool Config](../../configuration/tools/index.md).
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/_index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/_index.md
new file mode 100644
index 000000000000..7b70d5fcfd0f
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Configuration"
+description: "Complete reference for configuring agents in YAML or HCL."
+weight: 30
+---
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md
new file mode 100644
index 000000000000..9da240a9cb06
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md
@@ -0,0 +1,618 @@
+---
+title: "Agent Configuration"
+description: "Complete reference for defining agents in your YAML configuration."
+keywords: docker agent, ai agents, configuration, yaml, agent configuration
+linkTitle: "Agent Config"
+weight: 30
+canonical: https://docs.docker.com/ai/docker-agent/configuration/agents/
+---
+
+_Complete reference for defining agents in your YAML configuration._
+
+A configuration must define at least one agent under `agents`.
+
+## Full Schema
+
+<!-- yaml-lint:skip -->
+```yaml
+agents:
+  agent_name:
+    model: string # Required: model reference
+    description: string # Required: what this agent does
+    instruction: string # Required (unless instruction_file): system prompt
+    instruction_file: string | [list] # Optional: load the system prompt from one or more files relative to this config (mutually exclusive with instruction)
+    sub_agents: [list] # Optional: local or external sub-agent references
+    toolsets: [list] # Optional: tool configurations (use `type: rag` for RAG sources)
+    fallback: # Optional: fallback config
+      models: [list]
+      retries: 2
+      cooldown: 1m
+    add_date: boolean # Optional: add date to context
+    add_environment_info: boolean # Optional: add env info to context
+    add_prompt_files: [list] # Optional: include additional prompt files
+    add_description_parameter: bool # Optional: add description to tool schema
+    redact_secrets: boolean # Optional: scrub detected secrets out of tool args, outgoing chat messages, and tool output
+    code_mode_tools: boolean # Optional: let the agent write JavaScript to orchestrate tool calls (see Code Mode)
+    max_iterations: int # Optional: max tool-calling loops
+    max_consecutive_tool_calls: int # Optional: max identical consecutive tool calls
+    max_old_tool_call_tokens: int # Optional: token budget for old tool call content (disabled unless positive)
+    max_tool_result_tokens: int # Optional: per-tool-result token cap with middle-out truncation (disabled unless positive)
+    num_history_items: int # Optional: limit conversation history
+    session_compaction: boolean # Optional: disable automatic session compaction (default: true)
+    compaction_threshold: float # Optional: context-window fraction that triggers auto-compaction (0–1, default: 0.9)
+    compaction_model: string # Optional: model used for session-compaction (summary generation)
+    use_toolsets: [list] # Optional: names of top-level toolsets to merge into this agent
+    readonly: boolean # Optional: restrict all toolsets to read-only tools only
+    skills: boolean | [list] # Optional: enable skill discovery (true/false or list of names and/or sources)
+    use_commands: [list] # Optional: names of top-level commands groups to merge into this agent
+    use_skills: [list] # Optional: names of top-level skills groups to merge into this agent
+    commands: # Optional: named prompts
+      name: "prompt text" # or {instruction: "prompt", agent: "sub_agent_name"} or {url: "https://..."} (TUI only)
+    welcome_message: string # Optional: message shown at session start
+    handoffs: [list] # Optional: agent names this agent can hand off to
+    force_handoff: string # Optional: agent that always receives the conversation when this agent stops
+    hooks: # Optional: lifecycle hooks
+      pre_tool_use: [list]
+      tool_response_transform: [list]
+      post_tool_use: [list]
+      session_start: [list]
+      session_end: [list]
+      on_user_input: [list]
+      stop: [list]
+      notification: [list]
+    structured_output: # Optional: constrain output format
+      name: string
+      schema: object
+    cache: # Optional: response cache (skip the model on repeat questions)
+      enabled: boolean
+      case_sensitive: boolean
+      trim_spaces: boolean
+      path: string
+    harness: # Optional: delegate to an external coding CLI (Claude Code, Codex, opencode, pi)
+      type: string # Required: claude-code | codex | opencode | pi
+      model: string # Optional: model override forwarded to the CLI (omit for the CLI's own default)
+      effort: string # claude-code only: low | medium | high | xhigh | max (omit for the Claude Code default)
+      agent: string # opencode only: agent profile name
+      thinking: boolean # opencode only: enable extended thinking
+```
+
+> [!TIP]
+> **See also**
+>
+> For model parameters, see [Model Config](../models/index.md). For tool details, see [Tool Config](../tools/index.md). For multi-agent patterns, see [Multi-Agent](../../concepts/multi-agent/index.md).
+
+## Properties Reference
+
+| Property                    | Type    | Required | Description                                                                                                                                                                   |
+| --------------------------- | ------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `model`                     | string  | ✓        | Model reference. Either inline (`openai/gpt-5`) or a named model from the `models` section.                                                                              |
+| `description`               | string  | ✓        | Brief description of the agent's purpose. Used by coordinators to decide delegation.                                                                                          |
+| `instruction`               | string  | ✓        | System prompt that defines the agent's behavior, personality, and constraints. Required unless `instruction_file` is set.                                                      |
+| `instruction_file`          | string \| array  | ✗        | Path(s) to a file or files (relative to the config file's directory) whose contents become the agent's instruction, loaded at startup. Accepts a single path or a list; multiple files are concatenated in order, separated by a blank line. Mutually exclusive with `instruction`. Each path must be a local relative path inside the config directory (absolute paths and `..` traversal are rejected). Only supported for local file-based configs, not OCI/URL sources. See [External Instruction Files](#external-instruction-files) below. |
+| `sub_agents`                | array   | ✗        | List of agent names or external OCI references this agent can delegate to. Supports local agents, registry references (e.g., `myorg/agent:tag`), and named references (`name:reference`). Automatically enables the `transfer_task` tool. Pin external OCI references to a digest (`name@sha256:…`) to skip the per-run registry lookup that tag references incur. See [External Sub-Agents](../../concepts/multi-agent/index.md#external-sub-agents-from-registries). |
+| `toolsets`                  | array   | ✗        | List of tool configurations. See [Tool Config](../tools/index.md).                                                                                                        |
+| `fallback`                  | object  | ✗        | Automatic model failover configuration.                                                                                                                                       |
+| `add_date`                  | boolean | ✗        | When `true`, injects the current date into the agent's context.                                                                                                               |
+| `add_environment_info`      | boolean | ✗        | When `true`, injects working directory, OS, CPU architecture, and git info into context.                                                                                      |
+| `add_prompt_files`          | array   | ✗        | List of file paths whose contents are appended to the system prompt. Useful for including coding standards, guidelines, or additional context.                                |
+| `add_description_parameter` | boolean | ✗        | When `true`, adds agent descriptions as a parameter in tool schemas. Helps with tool selection in multi-agent scenarios.                                                      |
+| `redact_secrets`            | boolean | ✗        | When `true`, scrubs detected secrets (API keys, tokens, private keys, etc.) out of tool-call arguments, outgoing chat messages, and tool output before they reach a tool, the model, or downstream consumers. See [Redacting Secrets](#redacting-secrets) below.   |
+| `code_mode_tools`           | boolean | ✗        | When `true`, replaces the agent's individual tools with a single tool that runs a JavaScript script calling as many of them as needed in one turn. See [Code Mode](../../features/code-mode/index.md). |
+| `max_iterations`            | int     | ✗        | Maximum number of tool-calling loops. Default: unlimited (0). Set this to prevent infinite loops.                                                                             |
+| `max_consecutive_tool_calls` | int     | ✗        | Maximum consecutive identical tool calls before the agent is terminated, preventing degenerate loops. Default: `5`.                                                          |
+| `max_old_tool_call_tokens`  | int     | ✗        | Maximum number of tokens to keep from old tool call arguments and results. Older tool calls beyond this budget have their content replaced with a placeholder, saving context space. Tokens are approximated as `len/4`. Truncation is disabled by default; set a positive value to enable it. Set to `-1` to disable truncation (unlimited). |
+| `max_tool_result_tokens`    | int     | ✗        | Maximum number of tokens to keep from each tool result when it is added to the session. Oversized results are truncated middle-out: the head and tail are kept and the removed middle is replaced with a truncation marker. Textual documents attached to the result share the same budget. Tokens are approximated as `len/4`. The cap is disabled by default; set a positive value to enable it. `0` and `-1` both leave tool results unbounded. |
+| `num_history_items`         | int     | ✗        | Limit the number of conversation history messages sent to the model. Useful for managing context window size with long conversations. Default: unlimited (all messages sent). |
+| `session_compaction`        | boolean | ✗        | When `false`, disables automatic session compaction for this agent: neither the proactive threshold trigger nor the post-overflow auto-recovery runs. The manual `/compact` command remains available. Default: `true`. See the [Context & Compaction guide](../../guides/compaction/index.md). |
+| `compaction_threshold`      | float   | ✗        | Fraction of the model's context window at which proactive auto-compaction triggers. Must be greater than `0` and at most `1`. A `compaction_threshold` set on the agent's model takes precedence. Default: `0.9`. See the [Context & Compaction guide](../../guides/compaction/index.md). |
+| `compaction_model`          | string  | ✗        | Model used for session compaction (summary generation). Can be a named model or an inline `provider/model` string. This agent-level value takes precedence over a `compaction_model` set on the agent's model or provider; when none is set, the agent's own model compacts. See the [Context & Compaction guide](../../guides/compaction/index.md). |
+| `skills`                    | bool/array | ✗     | Enable automatic skill discovery. `true` loads all discovered local skills, `false` disables them. A list can mix skill sources (`local` or `https://…` URLs) and skill names to include — see [Skills](../../features/skills/index.md).                                                     |
+| `commands`                  | object  | ✗        | Named prompts that can be run with `docker agent run config.yaml /command_name`. Can be simple strings or objects with `instruction` and/or `agent` fields for agent switching, or a `url` field to open a link in the browser (TUI only). See [Named Commands](#named-commands) below. |
+| `use_commands`              | list of string | ✗   | Names of top-level `commands` groups to merge into this agent. Inline `commands` entries take precedence on name conflicts. Default: `[]`. |
+| `use_skills`                | list of string | ✗   | Names of top-level `skills` groups to merge into this agent. Inline skills are deduplicated by name against merged entries. Default: `[]`. |
+| `use_toolsets`              | list of string | ✗   | Names of top-level `toolsets` groups to merge into this agent. See [Reusable Toolsets](../overview/index.md#reusable-toolsets-toolsets). Default: `[]`. |
+| `readonly`                  | boolean | ✗   | When `true`, every toolset on this agent is filtered to expose only read-only tools (those annotated with a read-only hint). Mutating tools are removed at load time and cannot be called even if the model tries. See [Read-Only Agents](#read-only-agents) below. |
+| `welcome_message`           | string  | ✗        | Message displayed to the user when a session starts. Rendered as Markdown in the TUI. **Not sent to the model** — it exists purely for the user's benefit. Useful for telling users what the agent can do and what commands are available. |
+| `handoffs`                  | array   | ✗        | List of agent names this agent can hand off the conversation to. Enables the `handoff` tool. See [Handoffs Routing](../../concepts/multi-agent/index.md#handoffs-routing).                  |
+| `force_handoff`             | string  | ✗        | Name of an agent that unconditionally receives the conversation whenever this agent produces a final response. The runtime performs the switch itself, bypassing the LLM's tool-calling, guaranteeing deterministic pipelines. Must not reference the agent itself, and chains must not form a cycle. See [Forced Handoffs](../../concepts/multi-agent/index.md#forced-handoffs). |
+| `hooks`                     | object  | ✗        | Lifecycle hooks for running commands at various points. See [Hooks](../hooks/index.md).                                                                                   |
+| `structured_output`         | object  | ✗        | Constrain agent output to match a JSON schema. See [Structured Output](../structured-output/index.md).                                                                    |
+| `cache`                     | object  | ✗        | Response cache. When the same user question is asked again, the previous answer is replayed verbatim and the model is not called. See [Response Cache](#response-cache) below.                  |
+| `harness`                   | object  | ✗        | Run this agent through an external coding CLI instead of a model. **Note:** Any `toolsets:` defined on the same agent are silently ignored when `harness:` is set — the external CLI brings its own tools. See [Coding Harnesses](../../features/harnesses/index.md). |
+
+> [!WARNING]
+> **max_iterations**
+>
+> Default is `0` (unlimited). Always set `max_iterations` for agents with powerful tools like `shell` to prevent infinite loops. A value of 20–50 is typical for development agents.
+
+> [!TIP]
+> **Managing long sessions**
+>
+> `max_old_tool_call_tokens`, `max_tool_result_tokens`, `num_history_items`, `session_compaction`, and `compaction_threshold` all help keep long-running sessions inside the model's context window. See the [Context & Compaction guide](../../guides/compaction/index.md) for how to combine them.
+
+## External Instruction Files
+
+Long system prompts can be kept in their own files instead of being inlined in
+the YAML, using `instruction_file`. This separates infrastructure configuration
+(models, providers, tools) from behavioral content (the prompt), which keeps
+version-control diffs focused, reduces merge conflicts on shared configs, and
+lets instruction content be edited without risking YAML syntax errors.
+
+```yaml
+agents:
+  coordinator:
+    model: openai/gpt-5-mini
+    description: Routes work between specialist agents
+    instruction_file: instructions/coordinator.md
+    sub_agents:
+      - writer
+  writer:
+    model: openai/gpt-5-mini
+    description: Drafts and edits written content
+    instruction_file: instructions/writer.md
+```
+
+The path is resolved relative to the config file's directory and the file's
+contents are loaded as the agent's instruction when the config is loaded. Notes:
+
+- **Mutually exclusive** with `instruction`. Setting both is an error.
+- Each path must be a **local relative path inside the config directory**.
+  Absolute paths and `..` traversal are rejected.
+- A **list** of files is also accepted; their contents are concatenated in
+  order, separated by a blank line. This lets a shared preamble be reused
+  across agents while each agent appends its own specifics:
+
+  ```yaml
+  agents:
+    writer:
+      model: openai/gpt-5-mini
+      description: Drafts and edits written content
+      instruction_file:
+        - instructions/shared-preamble.md
+        - instructions/writer.md
+  ```
+
+- Only supported for **local file-based configs**, not agents loaded from OCI
+  registries or URLs. When an agent is pushed with `docker agent share push`,
+  the file contents are inlined into the pushed artifact, so the published
+  agent stays self-contained.
+
+A runnable example lives in [`examples/instruction_file.yaml`](https://github.com/docker/docker-agent/blob/main/examples/instruction_file.yaml).
+
+## Prompt Files
+
+`add_prompt_files` injects the contents of one or more files into the agent's
+context at the start of every turn — handy for repo-wide conventions like
+`AGENTS.md` or `CLAUDE.md` that should stay available without being pasted
+into `instruction`:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: A helpful coding assistant
+    instruction: You are an expert software developer.
+    add_prompt_files:
+      - AGENTS.md
+```
+
+For each name, the agent loads the closest match found by walking up from the
+current working directory, plus (if it's a different file) a copy at that
+name directly under the user's home directory — so a personal `~/AGENTS.md`
+can layer on top of a repo-local one. Missing files are skipped rather than
+erroring. Because resolution and the read happen on every turn, edits to the
+file are picked up without restarting the agent.
+
+Use `--prompt-file` to add files for a single run without editing the
+config. It's merged with any `add_prompt_files` already set on the agent,
+with duplicates dropped:
+
+```bash
+$ docker agent run agent.yaml --prompt-file CONTRIBUTING.md
+```
+
+Resolved prompt files show up as their own entries in the `/context` dialog — see [File Attachments](../../features/tui/index.md#file-attachments) in the Terminal UI guide.
+
+See [Choosing a Large-Input Strategy](../../guides/headless/index.md#choosing-a-large-input-strategy) for how prompt files compare to `@`/`/attach` attachments, the `rag` toolset, and sending content over the API/chat server.
+
+## Response Cache
+
+The response cache short-circuits the model when the same user question is asked again. The first time a question is asked, the agent calls the model normally and stores the assistant's reply. Subsequent identical questions skip the model entirely and replay the stored reply verbatim.
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5
+    description: Cached assistant
+    instruction: You are a helpful assistant.
+    cache:
+      enabled: true          # required to turn the cache on
+      case_sensitive: false  # default: false ("Hello" == "hello")
+      trim_spaces: true      # default: false ("  hello  " == "hello")
+      path: ./cache.json     # optional: persist to disk; omit for in-memory
+```
+
+| Property         | Type    | Default | Description                                                                                                                                                                                                                       |
+| ---------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `enabled`        | boolean | `false` | Master switch. When `false` (or when the `cache` section is omitted), no caching is performed.                                                                                                                                     |
+| `case_sensitive` | boolean | `false` | When `true`, questions must match exactly (including case) to hit the cache.                                                                                                                                                       |
+| `trim_spaces`    | boolean | `false` | When `true`, leading and trailing whitespace is stripped from the question before it is compared.                                                                                                                                  |
+| `path`           | string  | _empty_ | When set, cache entries are persisted to a JSON file at the given path and reloaded on startup so the cache survives restarts. Relative paths resolve against the agent config directory. When empty, the cache lives in memory only. |
+
+**How it works**
+
+- The cache key is the latest user message in the session, normalized according to `case_sensitive` and `trim_spaces`.
+- On a hit, the cached reply is added to the session as the assistant message and stop hooks fire normally — the rest of the agent (tools, sub-agents, the model) is bypassed.
+- On a miss, the agent runs normally; the final assistant message produced by the first stop of the run is then stored under the question's key.
+- Only the response to the original user question of a run is cached; follow-up turns inside the same `RunStream` are not.
+
+**File-backed storage**
+
+When `path` is set, every `Store` rewrites the entire cache file. Writes are **atomic**: the new content is written to a sibling temp file, `fsync`'d, and renamed over the destination, so a concurrent reader (or a process that crashes mid-write) will always see either the previous content or the new content in full — never a partially written file. The parent directory is also `fsync`'d after the rename so the rename itself is durable.
+
+**Cross-process sharing**
+
+Multiple processes can share the same `path:` cache file safely. Every `Store` takes an exclusive advisory lock on a sibling `<path>.lock` file (POSIX `flock(2)` on Unix, `LockFileEx` on Windows), reloads the current on-disk state under the lock, merges the new entry, and writes back atomically. Two processes that store *different* keys at the same time both see their writes preserved on disk; the lock window is short (one read + one fsync'd write).
+
+`Lookup` watches the file's modification time and reloads the in-memory map when the file has advanced since its last load, so writes from a sibling process become visible without a restart. The `<path>.lock` sentinel file is created on first write and never deleted: removing it would let two processes lock different inodes and lose mutual exclusion.
+
+## Redacting Secrets
+
+The `redact_secrets` flag is a single agent-level switch that scrubs accidentally leaked credentials, tokens, and private keys out of an agent's I/O. It wires up three complementary defenses:
+
+1. A `pre_tool_use` built-in hook that scrubs detected secrets from the **arguments of every tool call**, before the tool sees them.
+2. A `before_llm_call` built-in hook that scrubs the same patterns from **outgoing chat messages** — message content, multi-part text content, prior reasoning content, and the JSON-encoded arguments of any tool call still in the conversation — before they reach the model provider.
+3. A `tool_response_transform` built-in hook that scrubs **tool output at the source**, so the secret never reaches event consumers, the persisted session file, the `post_tool_use` hook input, or the next LLM call.
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5
+    description: A helpful assistant that scrubs secrets before they leak
+    instruction: |
+      You are a helpful assistant. If the user accidentally pastes a token,
+      do your best work without echoing the secret back.
+    redact_secrets: true
+    toolsets:
+      - type: shell
+```
+
+Detection uses the [portcullis](https://github.com/docker/portcullis) ruleset, which recognises common secret patterns including:
+
+- GitHub Personal Access Tokens (`ghp_*`, `gho_*`, `ghu_*`, `ghs_*`, `ghr_*`, fine-grained `github_pat_*`)
+- AWS access keys (`AKIA*`, `ASIA*`, …) and secret access keys
+- GitLab PATs (`glpat-*`), Hugging Face tokens (`hf_*`)
+- Stripe (`sk_live_*`, `pk_test_*`, …), Slack (`xoxb-*`, …), Shopify, Twilio, Discord, Atlassian, Mailchimp, SendGrid, and many more
+- JWTs, GCP service-account JSON, Heroku keys, Docker Hub PATs (`dckr_pat_*`)
+- PEM-encoded private keys (`-----BEGIN … PRIVATE KEY-----` blocks)
+
+Each detected span is replaced with the literal string `[REDACTED]`; the surrounding text is preserved so a redacted argument still looks like a legitimate flag (e.g. `--token=[REDACTED]`). Redaction is idempotent — applying it twice yields the same result.
+
+> [!NOTE]
+> **False positives vs. false negatives**
+>
+> False positives are extremely rare: every rule pairs a regex with a discriminating keyword, so plain English never trips detection. **False negatives are possible** — only patterns the ruleset recognises are scrubbed, so this is a defense-in-depth feature, not a substitute for keeping secrets out of the conversation in the first place. Pair it with a proper [secret manager](../../guides/secrets/index.md) for the credentials your agent actually needs.
+
+> [!NOTE]
+> **Equivalent hook entry**
+>
+> Setting `redact_secrets: true` on the agent is shorthand for auto-registering all three legs of the feature as hook entries. They share the _same_ built-in name (`type: builtin`, `command: redact_secrets`) on `pre_tool_use`, `before_llm_call`, and `tool_response_transform` respectively — the implementation dispatches on the hook event. You can spell them out by hand to scope a leg to a subset of tools (set `matcher:` to a regex), stack them with other rewriters in a specific order, or enable just one or two legs. See [`examples/redact_secrets_hooks.yaml`](https://github.com/docker/docker-agent/blob/main/examples/redact_secrets_hooks.yaml) for a complete manual wiring and the [Hooks reference](../hooks/index.md#available-built-ins) for the builtin's event coverage.
+
+## Welcome Message
+
+Display a message when users start a session:
+
+```yaml
+agents:
+  assistant:
+    model: openai/gpt-5
+    description: Development assistant
+    instruction: You are a helpful coding assistant.
+    welcome_message: |
+      👋 Welcome! I'm your development assistant.
+
+      I can help you with:
+      - Writing and reviewing code
+      - Running tests and debugging
+      - Explaining concepts
+
+      What would you like to work on?
+```
+
+## Deferred Tool Loading
+
+Toolsets support `defer` to load tools on-demand and speed up agent startup. See [Deferred Tool Loading](../tools/index.md#deferred-tool-loading) for details.
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Multi-purpose assistant
+    instruction: You have access to many tools.
+    toolsets:
+      - type: mcp
+        ref: docker:github-official
+        defer: true
+      - type: filesystem
+```
+
+## Fallback Configuration
+
+Automatically switch to backup models when the primary fails:
+
+| Property   | Type   | Default | Description                                                |
+| ---------- | ------ | ------- | ---------------------------------------------------------- |
+| `models`   | array  | `[]`    | Fallback models to try in order                            |
+| `retries`  | int    | `2`     | Retries per model for 5xx errors. `-1` to disable.         |
+| `cooldown` | string | `1m`    | How long to stick with a fallback after a rate limit (429) |
+
+**Error handling:**
+
+- **Retryable** (same model with backoff): HTTP 5xx, 408, network timeouts
+- **Non-retryable** (skip to next model): HTTP 429, 4xx client errors
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    fallback:
+      models:
+        - openai/gpt-5
+        - google/gemini-3.5-flash
+      retries: 2
+      cooldown: 1m
+```
+
+## Named Commands
+
+> [!TIP]
+> **Full reference**
+>
+> This section covers the basics. For URL commands, agent-switching commands, reusable top-level `commands:` groups, and hiding commands with `--disable-commands`, see [Custom Commands](../commands/index.md).
+
+Define reusable prompt shortcuts that can send prompts to the current agent, switch to a different sub-agent, or open a URL in the browser:
+
+> **Note:** Named slash commands execute immediately, even while the agent is processing another message. Unlike regular chat messages (which are queued), slash commands interrupt or direct the agent even while it is mid-response.
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5
+    instruction: You are a system administrator.
+    commands:
+      df: "Check how much free space I have on my disk"
+      logs: "Show me the last 50 lines of system logs"
+      greet: "Say hello to ${env.USER}"
+      deploy: "Deploy ${env.PROJECT_NAME || 'app'} to ${env.ENV || 'staging'}"
+      
+      # Advanced format with agent switching
+      plan:
+        agent: planner  # Switch to the 'planner' agent
+        instruction: "Create a detailed plan for: ${args.join(\" \")}"  # Optional: send this prompt after switching
+      
+      # Agent switching without instruction - forwards remaining text as prompt
+      review:
+        agent: reviewer  # Any text after /review is sent to the reviewer agent
+
+      # URL command - opens a link in the browser instead of messaging the agent
+      docs:
+        description: "Open the documentation"
+        url: https://docs.docker.com/
+```
+
+### Command Formats
+
+Commands support three formats:
+
+1. **Simple string format**: The string becomes the instruction sent to the current agent
+
+   ```yaml
+   df: "Check disk space"
+   ```
+
+2. **Advanced object format**: Supports agent switching and optional instructions
+
+   ```yaml
+   plan:
+     agent: planner  # Required: name of any agent defined in the team
+     instruction: "Plan: ${args.join(\" \")}"  # Optional: prompt to send after switching
+     description: "Switch to planning mode"  # Optional: shown in help text
+   ```
+
+3. **URL format**: Opens a link in the browser instead of messaging the agent
+
+   ```yaml
+   docs:
+     url: https://docs.docker.com/          # Required: URL to open
+     description: "Open the documentation"  # Optional: shown in help text
+   ```
+
+When `agent` is set without `instruction`, any text typed after the slash command (e.g., `/plan build a web app`) is forwarded as a prompt to the target agent. The target agent can be **any agent defined in the team configuration** — it does not need to be listed in the current agent's `sub_agents` array.
+
+**Argument and expansion syntax**
+
+An `instruction` string can reference the command's arguments and expand tool calls:
+
+- `${args[0]}`, `${args[1]}`, … — individual positional arguments, in the order the user typed them after the command
+- `${args.join(" ")}` — all arguments joined into a single string
+- `${tool_name({...})}` — calls a tool and inlines its return value (any tool available to the agent)
+- `!tool_name(key=value)` — legacy tool-call form: calls a tool with plain `key=value` arguments and inlines its output
+
+### Agent-Switching Commands
+
+Commands with an `agent` field switch the active agent for that command's scope. This is useful for building workflow shortcuts where `/plan`, `/review`, `/deploy` each route the user to the appropriate specialist.
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5
+    description: Main assistant
+    instruction: You are a project coordinator.
+    sub_agents: [planner, reviewer]
+    commands:
+      # Switch to planner with a pre-filled prompt
+      plan:
+        agent: planner
+        instruction: "Create a detailed plan for: ${args.join(\" \")}"
+      # Switch to reviewer; any text after /review is forwarded
+      review:
+        agent: reviewer
+      # Simple prompt command (no switching)
+      status: "Summarize what we have accomplished so far"
+
+  planner:
+    model: openai/gpt-5
+    description: Planning specialist
+    instruction: You create detailed project plans.
+
+  reviewer:
+    model: anthropic/claude-sonnet-4-5
+    description: Code review specialist
+    instruction: You review code and suggest improvements.
+```
+
+**Agent-switching vs. `handoff`**
+
+| | Agent-switching command | `handoff` tool |
+| --- | --- | --- |
+| **Trigger** | User runs `/command` | Model calls `handoff()` |
+| **Session** | Stays in the same session | Stays in the same session |
+| **History** | Target agent sees full conversation | Target agent sees full conversation |
+| **Return** | User must explicitly switch back | Target agent can chain to another agent |
+
+**Agent-switching vs. `transfer_task`**
+
+`transfer_task` launches a **sub-session**: the root agent sends a task, the child runs in isolation, and the result is returned to the root. The root agent stays in control and the child's work is never in the main conversation. Use `transfer_task` (via `sub_agents`) when you want delegation with a clean result; use agent-switching commands when you want to *become* a different agent for the rest of the conversation.
+
+See [`examples/agent_switching_commands.yaml`](https://github.com/docker/docker-agent/blob/main/examples/agent_switching_commands.yaml) for a complete example.
+
+```bash
+# Run commands from the CLI
+$ docker agent run agent.yaml /df
+$ docker agent run agent.yaml /greet
+$ PROJECT_NAME=myapp ENV=production docker agent run agent.yaml /deploy
+```
+
+Commands use JavaScript template literal syntax (`${env.VAR}`) for environment variable interpolation. Undefined variables expand to empty strings.
+
+The same syntax is also expanded in agent and toolset instructions: `agents.<name>.instruction` and `toolsets[*].instruction` support `${env.X}` placeholders (with optional `||` defaults and ternary expressions). `agents.<name>.description` and `agents.<name>.welcome_message` also support it.
+
+Note that path-like fields (`working_dir`, `path`) primarily use a shell-style syntax (`$VAR`, `${VAR}`, `~`), and also accept `${env.X}` as an alias (though not richer JS expressions). See [Variable Expansion in Config Fields](../overview/index.md#variable-expansion-in-config-fields) for the full table.
+
+### URL Commands
+
+A command with a `url` field opens that URL in the user's default browser instead of sending a prompt to the agent. Any URI scheme the OS knows how to dispatch works — both standard web URLs and custom schemes such as `docker-desktop://` for deep links. URL commands are TUI-only — they have no effect when run from the CLI.
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5
+    description: An agent with handy URL shortcuts.
+    instruction: You are a helpful assistant.
+    commands:
+      feedback:
+        description: "Open the feedback site for this session"
+        url: https://example.com/feedback?session={{session_id}}
+      docs:
+        description: "Open the documentation"
+        url: https://docs.docker.com/
+      desktop:
+        description: "Open this session in Docker Desktop"
+        url: docker-desktop://dashboard/session/{{session_id}}
+```
+
+The `{{session_id}}` token is replaced at invocation time with the current session ID (URL-query-escaped so it can't break the URL or inject extra query parameters), letting a command deep-link to something scoped to the conversation. This token deliberately uses `{{...}}` rather than the `${...}` JS-expansion syntax, since the session ID is only known at dispatch time.
+
+URLs are validated before being handed to the OS opener: a parseable URL with a non-empty scheme is required, and flag-like inputs (those starting with `-`) are rejected to prevent argument injection.
+
+See [`examples/url_commands.yaml`](https://github.com/docker/docker-agent/blob/main/examples/url_commands.yaml) for a complete example.
+
+## Read-Only Agents
+
+Set `readonly: true` on an agent to restrict all of its toolsets to tools that are annotated as read-only. Mutating tools are filtered out at load time — the agent cannot list or call them, even if the model hallucinates a call.
+
+You can also set `readonly: true` on an individual toolset to restrict only that toolset while leaving others unrestricted.
+
+```yaml
+agents:
+  # Agent-level readonly: every toolset is restricted to read-only tools.
+  inspector:
+    model: anthropic/claude-sonnet-4-5
+    description: Read-only inspector that can explore but never modify.
+    instruction: Explore the project. Do not make changes.
+    readonly: true
+    toolsets:
+      - type: filesystem
+      - type: shell
+
+  # Toolset-level readonly: only the filesystem toolset is restricted;
+  # the shell toolset keeps all of its tools.
+  mixed:
+    model: anthropic/claude-sonnet-4-5
+    description: Read-only file access, full shell access.
+    instruction: You can read files and run any shell command.
+    toolsets:
+      - type: filesystem
+        readonly: true
+      - type: shell
+```
+
+See [`examples/readonly.yaml`](https://github.com/docker/docker-agent/blob/main/examples/readonly.yaml) for a complete example.
+
+> [!NOTE]
+> **Which tools are read-only?**
+>
+> Whether a tool is read-only is determined by its `ReadOnlyHint` annotation. For built-in tools, read-only operations (list/read/search) carry the hint; mutating operations (write/delete/execute) do not. Custom and MCP tools expose the hint via their own annotations.
+
+## Complete Example
+
+```yaml
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    max_tokens: 64000
+
+agents:
+  root:
+    model: claude
+    description: Technical lead coordinating development
+    instruction: |
+      You are a technical lead. Analyze requests and delegate
+      to the right specialist. Always review work before responding.
+    welcome_message: "👋 I'm your tech lead. How can I help today?"
+    sub_agents: [developer, researcher]
+    add_date: true
+    add_environment_info: true
+    fallback:
+      models: [openai/gpt-5]
+    toolsets:
+      - type: think
+    commands:
+      review: "Review all recent code changes for issues"
+    hooks:
+      session_start:
+        - type: command
+          command: "./scripts/setup.sh"
+
+  developer:
+    model: claude
+    description: Expert software developer
+    instruction: Write clean, tested, production-ready code.
+    max_iterations: 30
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+      - type: todo
+
+  researcher:
+    model: openai/gpt-5
+    description: Web researcher with memory
+    instruction: Search for information and remember findings.
+    toolsets:
+      - type: mcp
+        ref: docker:duckduckgo
+      - type: memory
+        path: ./research.db
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/agentsignore/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/agentsignore/index.md
new file mode 100644
index 000000000000..67bbcf96ee75
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/agentsignore/index.md
@@ -0,0 +1,105 @@
+---
+title: "Ignoring files"
+description: "Hide files from the agent with a .agentsignore file, using the same syntax as .gitignore."
+keywords: docker agent, ai agents, configuration, agentsignore, gitignore, ignore, secrets
+weight: 75
+canonical: https://docs.docker.com/ai/docker-agent/configuration/agentsignore/
+---
+
+_Hide files from the agent with a `.agentsignore` file, using the same syntax as `.gitignore`._
+
+## Overview
+
+Put a `.agentsignore` file in your project and the agent stops seeing the paths it lists. Matched files are absent from directory listings and searches, and reads, writes and edits targeting them are refused.
+
+```text
+# .agentsignore
+secrets.env
+*.key
+.env.*
+build/
+docs/**/*.draft.md
+!public.key
+```
+
+There is nothing to configure. The file's presence is the opt-in, and it is picked up automatically by the [filesystem toolset](../../tools/filesystem/index.md).
+
+## Syntax
+
+The syntax is `.gitignore` syntax — parsed with the same library git uses, so patterns behave identically to `.gitignore` and `.dockerignore`:
+
+| Pattern | Matches |
+| --- | --- |
+| `secrets.env` | that name at any depth (`secrets.env`, `config/secrets.env`) |
+| `/secrets.env` | that name at the project root only |
+| `*.key` | any file with the extension |
+| `build/` | the directory and everything under it |
+| `docs/**/*.draft.md` | nested matches via `**` |
+| `!public.key` | re-includes a path an earlier pattern excluded |
+| `# comment` | ignored, as are blank lines |
+
+## Where the file is found
+
+The nearest `.agentsignore` at or above the working directory is used, so starting a run in a subdirectory still honours the project's file. Patterns are anchored to the directory containing the file, exactly as git anchors to the directory containing `.gitignore`.
+
+Unlike `.gitignore`, **a git repository is not required** — `.agentsignore` works in any directory.
+
+## What it affects
+
+| Behaviour | Effect |
+| --- | --- |
+| `list_directory`, `directory_tree` | matched entries are omitted |
+| `search_files_content` | matched files are skipped |
+| `read_file`, `read_multiple_files` | refused |
+| `write_file`, `edit_file` | refused, including for files that do not exist yet |
+| `create_directory`, `remove_directory` | refused |
+| `permissions` | matching deny rules are derived automatically, so `/permissions` shows them |
+
+Paths are resolved before matching — symlinks, `./` prefixes and `..` segments are all normalised — so an ignored file cannot be reached by spelling it differently.
+
+The `.agentsignore` file is itself always hidden: it names the very things being kept back, so handing it to the agent would be a map of what to look for.
+
+> [!NOTE]
+> `.agentsignore` is independent of the filesystem toolset's [`ignore_vcs`](../tools/index.md) option. Setting `ignore_vcs: false` turns off `.gitignore` filtering but does **not** un-hide `.agentsignore` entries.
+
+## Relationship to `.gitignore`
+
+They are separate, and they do different amounts of work.
+
+`.gitignore` is respected by default (`ignore_vcs`), but only as a **display filter**: gitignored files are hidden from listings and searches while `read_file` still opens them. That is reasonable for build output, which is noise rather than secret.
+
+`.agentsignore` is for content the agent should not have at all, so it blocks reads and writes as well. Use `.gitignore` for noise, `.agentsignore` for secrets.
+
+## Limits
+
+> [!WARNING]
+> `.agentsignore` governs the filesystem toolset. It is **not** a sandbox.
+>
+> An agent with the [`shell`](../../tools/shell/index.md) toolset can still run `cat secrets.env`, because the shell runs commands the toolset never inspects. The same applies to any toolset that reaches the filesystem on its own, such as [`lsp`](../../tools/lsp/index.md).
+>
+> Treat `.agentsignore` as a strong default that keeps sensitive files out of the agent's view and context — not as a boundary against an agent actively trying to reach them. When you need a real boundary, combine it with [permissions](../permissions/index.md) that restrict `shell`, or run in [sandbox mode](../sandbox/index.md).
+
+The derived permission rules are best-effort for the same reason: permission patterns match the argument string as the model wrote it, without resolving it first, so `./secrets.env` can slip past a rule written for `secrets.env`. The filesystem toolset's own check resolves paths first and is the part that actually enforces.
+
+## Example
+
+```text
+# .agentsignore
+
+# Secrets
+.env
+.env.*
+secrets.env
+*.pem
+*.key
+!public.key          # this one is safe to read
+
+# Credentials directories
+.aws/
+.ssh/
+
+# Large build output the agent doesn't need
+build/
+dist/
+node_modules/
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/budget/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/budget/index.md
new file mode 100644
index 000000000000..07086c2c5d8e
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/budget/index.md
@@ -0,0 +1,217 @@
+---
+title: "Budget"
+description: "Cap what a single run may spend in money, tokens, or working time."
+keywords: docker agent, ai agents, configuration, yaml, budget, cost, limits
+weight: 75
+canonical: https://docs.docker.com/ai/docker-agent/configuration/budget/
+---
+
+_Cap what a single run may spend in money, tokens, or working time._
+
+## Overview
+
+A budget sets ceilings on a run. When a ceiling is crossed the run stops with a message naming the exact limit that tripped, and the TUI tracks consumption live while the run is still going.
+
+Every limit is optional and an unset limit is unlimited, so you can cap money, tokens, time, or any combination. Declare no budget at all and runs are unbudgeted, which is the default.
+
+There are two ways to declare one, and they compose:
+
+| Block | Scope |
+| --- | --- |
+| `budget` | One run-wide ceiling, charged for every agent. |
+| `budgets` | Named budgets an agent opts into by name. |
+
+### A run-wide budget
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-4o-mini
+    description: An agent on a short leash.
+    instruction: You are a helpful assistant.
+
+budget:
+  max_cost: 0.50
+  max_tokens: 100000
+  max_time: 10m
+```
+
+| Field | Type | Description |
+| --- | --- | --- |
+| `max_cost` | number | Maximum spend, in USD. |
+| `max_tokens` | integer | Maximum cumulative input+output tokens. |
+| `max_time` | string | Maximum time the agents spend working, in Go duration format (`10m`, `30s`, `1h30m`). |
+
+### Named budgets
+
+Define budgets by name under the top-level `budgets` key, then have each agent opt in by listing names in its own `budgets` field. The fields are the same three.
+
+```yaml
+budgets:
+  shell-work:
+    max_cost: 0.03
+    max_tokens: 8000
+  research:
+    max_time: 1m
+
+agents:
+  root:
+    model: openai/gpt-4o-mini
+    description: Does shell work.
+    instruction: You are a helpful assistant.
+    budgets: [shell-work]
+  researcher:
+    model: openai/gpt-4o-mini
+    description: Answers questions.
+    instruction: You answer questions concisely.
+    budgets: [shell-work, research]
+```
+
+An agent may list several budgets; all of them apply, and the first to be exhausted stops the run. A run-wide `budget` applies on top of any named budget, so the ceiling that binds is whichever runs out first.
+
+Referencing a budget name that isn't defined is a config error, caught at parse time rather than silently leaving the agent uncapped.
+
+## A name is one shared pot
+
+When several agents reference the same budget name they draw from the **same** ceiling — not a copy each. Above, `root` and `researcher` share `shell-work`: together they cannot spend more than `$0.03`.
+
+This is deliberate, and it is the whole reason budgets are worth having. If each agent received its own allowance, a run could spend `max_cost` × N simply by fanning out to N sub-agents, and the ceiling would mean nothing for exactly the workloads that most need one.
+
+Give agents **distinct budget names** when you want independent pots.
+
+The same applies to the run-wide `budget`: every sub-session inside a run (transferred tasks, sub-agents, skills) spends from that one wallet.
+
+## Scope: a budget spans the session
+
+Spend accumulates for the life of the **session**, across every message you send — it does not reset each time you hit enter. A `max_cost: 0.50` you could re-spend on every message would not be a ceiling at all.
+
+Starting a new session starts a fresh budget. It is a per-session ceiling, not a lifetime quota across sessions.
+
+> [!NOTE]
+> `max_time` measures the time the agents actually spend **working** — the sum of their turn durations — not wall-clock since the session opened. Because a budget spans a session, and a session sits idle while you read and type, wall-clock would let a budget expire during a coffee break: leave the TUI open for ten minutes and your next message would instantly trip a `max_time` of `2m` without the agent having done anything.
+
+## What stops a run
+
+Crossing any limit — run-wide or named — stops the run and produces:
+
+- an assistant message in the transcript naming the limit and the amounts,
+- a `budget_exceeded` event carrying `budget`, `limit`, `used`, `max`, `config_path` and, under `stop_message`, the assistant stop message itself (agent name, role, content and timestamp only),
+- a `notification` hook at `warning` level,
+- a stream end reason of `budget_exceeded`, so a stopped run is distinguishable from a completed one in telemetry.
+
+The message names the exact YAML path to raise, so there is no ambiguity about which of several budgets tripped:
+
+```text
+Execution stopped after reaching the configured budgets.shell-work.max_cost
+limit (used $0.0312 of $0.0300).
+```
+
+Unlike [`max_iterations`](../agents/index.md), a budget stop is **terminal** — there is no prompt offering to continue. A budget is a ceiling you set deliberately, so raising it means editing the config rather than answering a dialog.
+
+## Budget stops in evaluation output
+
+When a budgeted agent is exercised with `docker agent eval`, a budget stop is recorded as a structured termination. It is not an error, and it is distinct from an ordinary stream stop: the run output JSON exposes it as an optional `eval_result.termination` object on the affected session.
+
+```json
+"eval_result": {
+  "passed": true,
+  "termination": {
+    "reason": "budget_exceeded",
+    "budget": "run",
+    "limit": "max_cost",
+    "used": "$0.0312",
+    "max": "$0.0300",
+    "config_path": "budget.max_cost",
+    "message": "Execution stopped after reaching the configured budget.max_cost limit (used $0.0312 of $0.0300)."
+  }
+}
+```
+
+- `reason` is always `budget_exceeded`. The other fields are optional and are copied from the runtime's `budget_exceeded` event through an allow-list: only `budget`, `limit`, `used`, `max`, `config_path`, and `message` are ever taken, each sanitized (invalid UTF-8 and control characters stripped, bounded length) and omitted when missing or unusable.
+- The stored session (SQLite database and sessions JSON) keeps the stop marker at its chronological position, followed exactly once by the assistant stop message rebuilt from the event's embedded `stop_message` (again only agent name, role, content, and timestamp are taken, sanitized the same way). When the event carries no usable `stop_message`, the marker stands alone; nothing is invented from `termination.message`.
+- The termination is informational: it does not change `passed`, `failures`, or `error`. A run that completed normally or failed with an error simply has no `termination` field, and older outputs written before the field existed load unchanged.
+
+## Tracking spend in the TUI
+
+The sidebar's Token Usage panel lists every active budget by name, with consumption against each ceiling it declares:
+
+```text
+run        $0.12/$0.50 · 12.3K/100.0K · 2m14s/10m
+shell-work $0.09/$0.10 · 4.3K/20.0K
+```
+
+Only the ceilings you configured appear. Each reading is colored by the sidebar's shared gauge bands — the same ones a context gauge uses as it nears compaction — so a budget turns amber well before its ceiling and red just short of it, and a run about to be stopped is visible before it stops.
+
+For a per-agent view of who spent what, set **Sidebar info mode** to `Detailed` in `/settings` → Appearance: the Agents section then reports each agent's cost alongside its effort and context. The budget line deliberately does not repeat that breakdown — the same numbers twice would crowd the sidebar's narrowest column. The per-agent split is still carried on the `budget_usage` event for programmatic consumers, and `/cost` has a **By Agent** section.
+
+## Limits and caveats
+
+### Unpriced models do not count towards `max_cost`
+
+Only responses the runtime can price count towards `max_cost`. A model with no pricing data — an unknown model ID, or a custom endpoint such as a local or private deployment — contributes nothing, because there is no honest number to add.
+
+Such a run emits a warning and the TUI marks the reading `(unpriced spend)`, rather than silently reading low because the spend is invisible. To make a custom endpoint count, price it explicitly with a model-level [`cost`](../models/index.md#custom-token-pricing) block:
+
+```yaml
+models:
+  local:
+    provider: openai
+    model: my-model
+    base_url: http://localhost:8000/v1
+    cost:
+      input: 0.15
+      output: 0.60
+
+agents:
+  root:
+    model: local
+    description: A locally-served agent with real cost accounting.
+    instruction: You are a helpful assistant.
+
+budget:
+  max_cost: 0.50
+```
+
+### Limits are checked at turn boundaries
+
+A run is checked between turns, so it can overshoot by at most the turn already in flight. `max_time` in particular will not interrupt a model call or tool that has already started; the run stops at the first boundary after the limit is reached.
+
+This is the same granularity [`max_iterations`](../agents/index.md) has, and it keeps the ceiling out of the streaming hot path. Set limits with a little headroom rather than at the exact number you cannot exceed.
+
+### `max_tokens` here is not the model's `max_tokens`
+
+The `max_tokens` in a budget is a **cumulative** count of input+output tokens across the whole run. It is unrelated to the provider- or model-level [`max_tokens`](../models/index.md), which caps the output of a single response.
+
+It is also not the session's context length: compaction resets that, while the budget keeps counting.
+
+## Examples
+
+Cap money only, and let the run take as long as it needs:
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-4o
+    description: A cost-capped agent.
+    instruction: You are a helpful assistant.
+
+budget:
+  max_cost: 5.00
+```
+
+Cap working time for an unattended job:
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-4o-mini
+    description: A time-boxed agent.
+    instruction: You are a helpful assistant.
+    toolsets:
+      - type: shell
+
+budget:
+  max_time: 15m
+```
+
+See [`examples/budget.yaml`](https://github.com/docker/docker-agent/blob/main/examples/budget.yaml) for a runnable configuration.
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md
new file mode 100644
index 000000000000..1b621b1f1a6e
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md
@@ -0,0 +1,218 @@
+---
+title: "Custom Commands"
+description: "Define slash commands that send prompts, open URLs, or switch agents, and reuse them across agents with top-level command groups."
+keywords: docker agent, ai agents, configuration, yaml, custom commands, slash commands
+linkTitle: "Custom Commands"
+weight: 55
+canonical: https://docs.docker.com/ai/docker-agent/configuration/commands/
+---
+
+_Define slash commands that send prompts, open URLs, or switch agents._
+
+## What Slash Commands Are
+
+A slash command is a named shortcut a user types in the TUI (`/df`, `/deploy`, `/plan`) or on the CLI (`docker agent run agent.yaml /df`) instead of typing out a full prompt. Every agent can declare its own commands under `commands:`, and top-level `commands:` groups let multiple agents share the same set without duplicating them.
+
+Unlike regular chat messages — which are queued while the agent is busy — slash commands (both built-in and named) execute immediately, even mid-response.
+
+Commands come in three shapes:
+
+| Shape | What it does |
+| --- | --- |
+| [Prompt command](#prompt-commands) | Sends a prompt to the current agent |
+| [URL command](#url-commands) | Opens a link in the user's browser (full TUI only) |
+| [Agent-switching command](#agent-switching-commands) | Switches the active agent, optionally with a prompt (full TUI and CLI) |
+
+> [!IMPORTANT]
+> **Behavior differs by frontend**
+>
+> `url` and `agent` are only fully honored in the **full TUI**, which checks `url` before `agent` (a URL command opens the browser and stops there; an agent-switching command switches before sending any instruction). The **lean TUI** doesn't special-case either field — it only resolves a command's expanded text and sends it as a chat message, so a URL-only command silently sends whatever trailing text followed the slash (often nothing, opening no browser) and an agent-switching command sends its instruction to the *current* agent instead of the target. The **CLI** (`docker agent run agent.yaml /command`) switches agents like the full TUI, but has no browser to open, so `url` has no effect there. The **HTTP API** (`POST /api/sessions/:id/agent/:agent`) resolves agent-switching commands server-side: if the message content starts with a slash command whose `agent` field is set, the active agent is switched and the message is rewritten before the turn runs. Prompt-only and URL commands are not resolved server-side and pass through to the model unchanged.
+
+## Prompt Commands
+
+The simplest form: a string value that becomes the instruction sent to the current agent.
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: A system administrator assistant.
+    instruction: You are a system administrator.
+    commands:
+      df: "Check how much free space I have on my disk"
+      logs: "Show me the last 50 lines of system logs"
+      greet: "Say hello to ${env.USER}"
+```
+
+For more control, use the object form with an `instruction:` field, plus an optional `description:` shown in completion dialogs and help text:
+
+```yaml
+commands:
+  deploy:
+    description: "Deploy the application to staging"
+    instruction: "Deploy ${env.PROJECT_NAME || 'app'} to ${env.ENV || 'staging'}"
+```
+
+Commands support JavaScript template literal syntax (`${env.VAR}`) for environment variable interpolation, with optional `||` defaults and ternary expressions — the same syntax as agent `instruction` and `description`. Undefined variables expand to the empty string. See [Variable Expansion in Config Fields](../overview/index.md#variable-expansion-in-config-fields) for the full picture.
+
+Prompt commands can also reference the text typed after the slash and call tools, using the same `${...}` expansion engine as `${env.VAR}`:
+
+- `${args[0]}`, `${args[1]}`, … — individual positional arguments (whitespace-tokenized; quoted substrings keep their spaces together).
+- `${args}` or `${args.join(" ")}` — the full argument list.
+- `${tool_name({key: value, ...})}` — calls an agent tool and inlines its output. JS expressions are evaluated before tool commands, so tool output is never itself re-evaluated as JS.
+- `` !tool_name(key=value) `` — legacy bang syntax for the same tool-call inlining; still supported alongside `${tool_name({...})}`.
+
+If `instruction` uses none of the `${args...}` placeholders, any text typed after the slash is appended to the resolved instruction automatically.
+
+```yaml
+commands:
+  fix:
+    description: "Fix a file, with optional extra options"
+    instruction: "Fix the file ${args[0]} with options ${args[1]}"
+  run:
+    description: "Run a command with all the typed arguments"
+    instruction: 'Run command with args: ${args.join(" ")}'
+  lint:
+    description: "Show the current lint output"
+    instruction: 'Lint: ${shell({cmd: "task lint"})}'
+```
+
+```bash
+# Run commands from the CLI too
+$ docker agent run agent.yaml /df
+$ docker agent run agent.yaml /greet
+$ docker agent run agent.yaml /fix main.go --verbose
+$ PROJECT_NAME=myapp ENV=production docker agent run agent.yaml /deploy
+```
+
+## URL Commands
+
+A command with a `url` field opens that URL in the user's default browser instead of sending a prompt to the agent. Any URI scheme the OS knows how to dispatch works — standard web URLs and custom schemes such as `docker-desktop://` for deep links.
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: An agent with handy URL shortcuts.
+    instruction: You are a helpful assistant.
+    commands:
+      feedback:
+        description: "Open the feedback site for this session"
+        url: https://example.com/feedback?session={{session_id}}
+      docs:
+        description: "Open the documentation"
+        url: https://docs.docker.com/
+      desktop:
+        description: "Open this session in Docker Desktop"
+        url: docker-desktop://dashboard/session/{{session_id}}
+```
+
+The `{{session_id}}` token is replaced at invocation time with the current session ID (URL-query-escaped so it can't break the URL or inject extra query parameters), letting a command deep-link to something scoped to the conversation. This token deliberately uses `{{...}}` rather than the `${...}` JS-expansion syntax, since the session ID is only known at dispatch time.
+
+URLs are validated before being handed to the OS opener: a parseable URL with a non-empty scheme is required, and flag-like inputs (those starting with `-`) are rejected to prevent argument injection.
+
+> [!NOTE]
+> **Full TUI only**
+>
+> URL commands only open a browser in the full TUI. The CLI and lean TUI don't check the `url` field at all, so `docker agent run agent.yaml /docs` never opens a browser there — but the command is still dispatched: its resolved text (usually empty, for a URL-only command) is sent as a prompt and can trigger a model turn.
+
+See [`examples/url_commands.yaml`](https://github.com/docker/docker-agent/blob/main/examples/url_commands.yaml) for a complete example.
+
+## Agent-Switching Commands
+
+A command with an `agent` field switches the active agent for the rest of the conversation. This is useful for building workflow shortcuts where `/plan`, `/review`, `/deploy` each route the user to the right specialist.
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Main assistant
+    instruction: You are a project coordinator.
+    sub_agents: [planner, reviewer]
+    commands:
+      # Switch to planner with a pre-filled prompt
+      plan:
+        agent: planner
+        instruction: "Create a detailed plan for: ${args.join(' ')}"
+      # Switch to reviewer; any text after /review is forwarded
+      review:
+        agent: reviewer
+
+  planner:
+    model: anthropic/claude-sonnet-4-5
+    description: Planning specialist
+    instruction: You create detailed project plans.
+
+  reviewer:
+    model: anthropic/claude-sonnet-4-5
+    description: Code review specialist
+    instruction: You review code and suggest improvements.
+```
+
+When `agent` is set **without** `instruction`, any text typed after the slash command (e.g. `/review fix the auth bug`) is forwarded as a prompt to the target agent. When both are set, the agent is switched first, then the instruction is sent to the new agent. Either way, the target can be **any agent defined in the team**, not just one of the current agent's own `sub_agents` — `sub_agents` above is shown because `planner` and `reviewer` also happen to be delegation targets, not because `agent:` requires it.
+
+Agent switching stays in the same session — the target agent sees the full conversation history, and the user must explicitly switch back (there's no automatic return). This is different from the two other ways agents hand off work:
+
+| | Agent-switching command | `handoff` tool | `transfer_task` |
+| --- | --- | --- | --- |
+| **Trigger** | User runs `/command` | Model calls `handoff()` | Model calls `transfer_task()` |
+| **Session** | Stays in the same session | Stays in the same session | Launches an isolated sub-session |
+| **History** | Target agent sees full conversation | Target agent sees full conversation | Child runs in isolation; only the result returns |
+| **Control** | User must explicitly switch back | Target agent can chain to another agent | Root agent stays in control |
+
+Use `transfer_task` (via `sub_agents`) when you want delegation with a clean result; use agent-switching commands when you want to *become* a different agent for the rest of the conversation.
+
+See [`examples/agent_switching_commands.yaml`](https://github.com/docker/docker-agent/blob/main/examples/agent_switching_commands.yaml) for a complete example.
+
+## Reusable Command Groups
+
+Repeated command sets across agents can be hoisted into the top-level `commands:` section and pulled in by name with `use_commands:` — the same reuse pattern as `mcps:` for MCP servers and `toolsets:` for shared toolsets.
+
+```yaml
+commands:
+  ci:
+    deploy: "Deploy the application"
+    test: "Run the test suite"
+
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Lead developer
+    instruction: You are the lead developer. Coordinate the team.
+    use_commands: [ci]      # reuse the "ci" command group
+    commands:
+      lint: "Run the linter"  # inline command, merged in (wins on conflict)
+
+  docs-writer:
+    model: anthropic/claude-sonnet-4-5
+    description: Documentation writer
+    instruction: You write and maintain the project documentation.
+    use_commands: [ci]      # same group, reused without duplication
+```
+
+An agent's own inline `commands:` entries take precedence over merged `use_commands:` entries on name conflicts. See [`examples/shared-commands-skills.yaml`](https://github.com/docker/docker-agent/blob/main/examples/shared-commands-skills.yaml) for a complete example that also covers the equivalent `skills:` / `use_skills:` pattern.
+
+## Hiding Commands
+
+Use `--disable-commands` to hide and disable specific slash commands in the TUI — built-in ones (`/cost`, `/eval`, `/model`, …) or your own named ones. Accepts a comma-separated list; the leading slash is optional and matching is case-insensitive.
+
+```bash
+$ docker agent run agent.yaml --disable-commands="/cost,/eval,/model"
+```
+
+This is useful for shipping a distributed agent with a narrower command surface — for example, hiding `/model` so a published agent always runs its intended model.
+
+## Built-in Commands
+
+The TUI ships its own slash commands (`/new`, `/compact`, `/sessions`, `/settings`, …) alongside whatever an agent defines. See [Slash Commands](../../features/tui/index.md#slash-commands) in the TUI reference for the full list.
+
+## Command Configuration Reference
+
+| Property | Type | Description |
+| --- | --- | --- |
+| `description` | string | Shown in completion dialogs and help text. |
+| `instruction` | string | The prompt sent to the agent. Supports argument expansion (`${args[0]}`, `${args.join(" ")}`, …), tool calls (`${tool_name({...})}`), and the legacy bang syntax `!tool_name(...)`. |
+| `agent` | string | Name of an agent in the team to switch to when this command is invoked — any agent in the team's `agents:` map, not just one of the current agent's `sub_agents`. When set without `instruction`, any text typed after the slash command is forwarded as a prompt to the target agent. |
+| `url` | string | URL to open in the user's default browser when this command is invoked, instead of sending a prompt to the agent (full TUI only — see [URL Commands](#url-commands)). The token `{{session_id}}` is replaced at invocation time with the current session ID (URL-query-escaped). |
+
+`instruction` and `agent` can be combined (the agent is switched first, then the instruction is sent to the new agent). In the full TUI, if `url` is set, it takes precedence over `agent` and `instruction` — the command only opens the browser; the lean TUI and CLI don't check `url` at all, so a URL-only command instead sends its (usually empty) resolved text as a prompt. See [Behavior differs by frontend](#what-slash-commands-are) above. The simple string form is shorthand for `{ instruction: "..." }`.
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/flavors/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/flavors/index.md
new file mode 100644
index 000000000000..05be0fcf499b
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/flavors/index.md
@@ -0,0 +1,172 @@
+---
+title: "Flavors"
+description: "Ship one agent file with named variants, enabled at run time as YAML patches."
+keywords: docker agent, ai agents, configuration, yaml, flavors, patch, variants, overrides
+weight: 95
+canonical: https://docs.docker.com/ai/docker-agent/configuration/flavors/
+---
+
+_Ship one agent file with named variants, enabled at run time as YAML patches._
+
+## Overview
+
+A flavor is a named YAML patch declared in the agent file itself, under the
+top-level `flavors` section. Enabling a flavor applies its patch on top of the
+rest of the document before the config is parsed, so one file can carry
+several variants — a cheaper model for local runs, extra tools for CI, a more
+verbose instruction for debugging — without duplicating the whole config.
+
+```yaml
+agents:
+  root:
+    model: claude
+    instruction: You are a helpful assistant.
+
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+
+flavors:
+  cheap:
+    models:
+      claude:
+        model: claude-3-5-haiku-latest
+```
+
+Enable flavors with the repeatable `--flavor` flag:
+
+```bash
+$ docker agent run agent.yaml --flavor cheap
+```
+
+The flag works on every command that runs an agent — `run`, `chat`, `eval`,
+`serve api`, `serve a2a`, `serve mcp` — and order matters: patches apply in
+the order the flavors are requested, each on top of the previous result.
+
+```bash
+$ docker agent run agent.yaml --flavor cheap --flavor verbose
+```
+
+Flavors the file does not define are ignored (with a debug log), so you can
+enable the same flavor set across a fleet of agents and each file only reacts
+to the names it declares. External sub-agents loaded from OCI or URL
+references receive the same enabled flavors.
+
+## Merge Semantics
+
+Patches follow [JSON Merge Patch](https://www.rfc-editor.org/rfc/rfc7386)
+semantics, with two extensions for arrays:
+
+| Patch value | Effect |
+| --- | --- |
+| Object | Merged recursively into the existing object. |
+| Scalar or array | Replaces the existing value. |
+| `null` | Deletes the key. |
+| Key ending in `+` | Appends the items to the existing array. |
+| Key ending in `-` | Removes matching entries from an array or object. |
+
+### Merging and replacing
+
+An object patch only touches the keys it names — siblings survive:
+
+```yaml
+flavors:
+  verbose:
+    agents:
+      root:
+        instruction: Explain your reasoning in detail.  # model, tools, ... unchanged
+```
+
+### Deleting a key
+
+Set it to `null`:
+
+```yaml
+flavors:
+  no-limit:
+    models:
+      claude:
+        max_tokens: null
+```
+
+### Appending to an array
+
+Plain arrays replace wholesale. To add entries instead, suffix the key
+with `+`:
+
+```yaml
+agents:
+  root:
+    toolsets:
+      - type: think
+
+flavors:
+  with-shell:
+    agents:
+      root:
+        toolsets+:
+          - type: shell
+```
+
+With `--flavor with-shell` the root agent gets both `think` and `shell`.
+
+### Removing entries
+
+Suffix the key with `-`. Each item in the patch value selects what to remove:
+
+- From an **array**: a scalar removes equal elements; an object removes every
+  element it partially matches (all of the matcher's keys must be present
+  with matching values).
+- From an **object**: items are key names to drop.
+
+```yaml
+flavors:
+  slim:
+    agents:
+      root:
+        toolsets-:
+          - type: shell   # drop every shell toolset, however configured
+        sub_agents-:
+          - checker       # drop by value
+    models-:
+      - spare             # drop the named model definition
+```
+
+> [!NOTE]
+> The `+` and `-` suffixes are reserved inside flavor patches: a patch cannot
+> set a literal key ending in either character. Base documents are unaffected.
+
+## Inspecting the Result
+
+`docker agent debug config` prints the config exactly as the runtime sees it,
+flavors applied:
+
+```bash
+$ docker agent debug config agent.yaml --flavor cheap --flavor with-shell
+```
+
+## HCL
+
+Flavors work in [HCL configs](../hcl/index.md) too, as labeled blocks. The
+append/remove operators need quoted attribute names inside object
+expressions:
+
+```hcl
+flavors "with-shell" {
+  agents = {
+    root = {
+      "toolsets+" = [{ type = "shell" }]
+    }
+  }
+}
+```
+
+## Notes
+
+- Flavors require config schema version 13 or later; older versions reject
+  the `flavors` key with a hint to bump the top-level `version` field.
+- Patches apply before validation, so a flavored config is validated exactly
+  like a hand-written one.
+- `docker agent push` publishes the raw document, `flavors` section included,
+  so consumers of a pushed agent can enable its flavors too.
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/hcl/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/hcl/index.md
new file mode 100644
index 000000000000..7a465e47a1c0
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/hcl/index.md
@@ -0,0 +1,306 @@
+---
+title: "HCL Configuration"
+description: "Write Docker Agent configs in HCL instead of YAML, using labeled blocks, heredocs, and the same underlying schema."
+keywords: docker agent, ai agents, configuration, yaml, hcl configuration
+weight: 20
+canonical: https://docs.docker.com/ai/docker-agent/configuration/hcl/
+---
+
+_Write Docker Agent configs in HCL instead of YAML. It maps to the same Docker Agent schema and validation rules._
+
+`docker-agent` supports `.hcl` config files anywhere it supports `.yaml` or `.yml` files. HCL is useful if you prefer labeled blocks, less punctuation, and heredocs for long prompts.
+
+> [!TIP]
+> **Same config model, different syntax**
+>
+> YAML and HCL are just two syntaxes for the same Docker Agent configuration model. Docker Agent converts HCL to the equivalent YAML structure internally, then runs the normal schema validation and loading pipeline.
+
+## Minimal Example
+
+```hcl
+#!/usr/bin/env docker agent run
+
+agent "root" {
+  model       = "openai/gpt-5"
+  description = "A helpful assistant"
+  instruction = <<-EOT
+  You are a helpful assistant.
+  EOT
+
+  toolset "think" {}
+}
+```
+
+Run it exactly like a YAML config:
+
+```bash
+$ docker agent run agent.hcl
+$ docker agent run --exec agent.hcl "Summarize this repository"
+$ docker agent serve api ./agents/   # directories may mix .yaml, .yml, and .hcl files
+```
+
+> [!TIP]
+> **See also**
+>
+> HCL changes the syntax, not the meaning of fields. For what each field does, see [Agent Config](../agents/index.md), [Model Config](../models/index.md), and [Tool Config](../tools/index.md).
+
+## YAML vs HCL
+
+These two configs are equivalent:
+
+```yaml
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+
+agents:
+  root:
+    model: claude
+    description: Coding assistant
+    instruction: You help with software development.
+    toolsets:
+      - type: filesystem
+      - type: shell
+```
+
+```hcl
+model "claude" {
+  provider = "anthropic"
+  model    = "claude-sonnet-4-5"
+}
+
+agent "root" {
+  model       = "claude"
+  description = "Coding assistant"
+  instruction = "You help with software development."
+
+  toolset "filesystem" {}
+  toolset "shell" {}
+}
+```
+
+## Core Conventions
+
+HCL follows a few simple mapping rules:
+
+| HCL syntax | YAML shape |
+| --- | --- |
+| `agent "root" { ... }` | `agents.root` |
+| `model "claude" { ... }` | `models.claude` |
+| `provider "team" { ... }` | `providers.team` |
+| `mcp "github" { ... }` | `mcps.github` |
+| `rag "docs" { ... }` | `rag.docs` |
+| `command "fix" { ... }` inside an agent | `commands.fix` |
+| `toolset "shell" {}` | list item in `toolsets` with `type: shell` |
+| `metadata { ... }`, `permissions { ... }` | singleton blocks with the same top-level name |
+
+### Top-level keyed maps become labeled blocks
+
+In YAML, several sections are maps keyed by name. In HCL, those become labeled blocks:
+
+```hcl
+model "claude" {
+  provider = "anthropic"
+  model    = "claude-sonnet-4-5"
+}
+
+agent "root" {
+  model       = "claude"
+  description = "Primary assistant"
+  instruction = "You are helpful."
+}
+```
+
+The supported top-level labeled blocks are:
+
+- `agent`
+- `model`
+- `provider`
+- `mcp`
+- `rag`
+
+The supported top-level singleton blocks are:
+
+- `metadata`
+- `permissions`
+
+### Toolsets use the block label as `type`
+
+Instead of writing list entries with `type: ...`, HCL uses a `toolset` block whose label becomes the tool type:
+
+```hcl
+agent "root" {
+  model       = "openai/gpt-5"
+  description = "Dev assistant"
+  instruction = "You can inspect and modify code."
+
+  toolset "filesystem" {}
+
+  toolset "mcp" {
+    ref = "docker:github-official"
+  }
+}
+```
+
+### Commands use labeled blocks too
+
+Agent commands are often nicer to write in HCL because each command gets its own block:
+
+```hcl
+agent "root" {
+  model       = "openai/gpt-5"
+  description = "Build helper"
+  instruction = "You help with builds."
+
+  command "fix-lint" {
+    description = "Fix lint issues"
+    instruction = "Run the linter, then fix any problems."
+  }
+}
+```
+
+## Strings and Heredocs
+
+Use quoted strings for short values and heredocs for long prompts, welcome messages, or embedded JSON.
+
+```hcl
+agent "root" {
+  model       = "openai/gpt-5"
+  description = "Friendly assistant"
+
+  instruction = <<-EOT
+  You are a helpful assistant.
+
+  Keep answers concise and practical.
+  EOT
+}
+```
+
+### Escaping literal `${...}`
+
+HCL treats `${...}` inside strings and heredocs as template interpolation. If you need the literal text `${...}` in your prompt, escape it as `$${...}`.
+
+This matters for command prompts that intentionally show Docker Agent template snippets:
+
+```hcl
+command "fix-lint" {
+  instruction = <<-EOT
+  Run the linter and inspect the result:
+
+  $${shell({cmd: "task lint"})}
+  EOT
+}
+```
+
+The model will receive the literal `${shell({cmd: "task lint"})}` text.
+
+## Loading Files with `file()`
+
+The `file()` function reads a UTF-8 text file and returns its contents as a string. Relative paths are resolved from the HCL config file's directory, and reads are restricted to that directory.
+
+This keeps long prompts out of the config:
+
+```hcl
+agent "root" {
+  model       = "openai/gpt-5"
+  description = "Coding assistant"
+  instruction = file("prompts/coding.md")
+}
+```
+
+With a single argument, the file contents are returned exactly as written — any `${...}` in the file stays literal, so runtime snippets like `${shell({cmd: "..."})}` pass through untouched.
+
+### Rendering files as templates
+
+Pass an object as the second argument to render the file as an HCL template. Each key becomes a variable available inside the file:
+
+```hcl
+agent "reviewer" {
+  model       = "openai/gpt-5"
+  description = "Go reviewer"
+  instruction = file("prompts/reviewer.md", {
+    language   = "Go"
+    strictness = "high"
+  })
+}
+
+agent "py_reviewer" {
+  model       = "openai/gpt-5"
+  description = "Python reviewer"
+  instruction = file("prompts/reviewer.md", {
+    language   = "Python"
+    strictness = "relaxed"
+  })
+}
+```
+
+With `prompts/reviewer.md` containing:
+
+```markdown
+You review ${language} code with ${strictness} strictness.
+```
+
+Templates support the full HCL template syntax, including `%{ for }` and `%{ if }` directives:
+
+```markdown
+Rules:
+%{ for rule in rules ~}
+- ${rule}
+%{ endfor ~}
+```
+
+Two things to keep in mind:
+
+- Referencing a variable that is not in the object is an error.
+- No functions are available inside templates, so a template cannot call `file()` again. If the file needs a literal `${...}` while being rendered as a template, escape it as `$${...}` inside the file.
+
+## Repeated Blocks Become Lists
+
+Some YAML sections are lists. In HCL, those are written as repeated blocks.
+
+For example, model routing rules become repeated `routing { ... }` blocks:
+
+```hcl
+model "smart_router" {
+  provider = "openai"
+  model    = "gpt-5"
+
+  routing {
+    model    = "anthropic/claude-sonnet-4-5"
+    examples = [
+      "Write a detailed technical document",
+      "Review this code for security issues",
+    ]
+  }
+
+  routing {
+    model    = "openai/gpt-5"
+    examples = [
+      "Generate some creative ideas",
+      "Help me brainstorm",
+    ]
+  }
+}
+```
+
+The same idea applies to other list-shaped sections such as RAG `strategy` blocks and hook event entries.
+
+## Important Differences from Terraform
+
+Docker Agent uses HCL as a configuration syntax, not as Terraform:
+
+- There are no modules, `locals`, or `variable` blocks.
+- The only function available in expressions is [`file()`](#loading-files-with-file); Terraform's function library (including `templatefile()`, which `file()` with a vars object replaces) is not available.
+- Prefer normal literal values: strings, numbers, booleans, lists, objects, and nested blocks.
+- After conversion, the result is validated exactly like the equivalent YAML config.
+
+If you already know Terraform, think of Docker Agent HCL as a thin block-based syntax over the existing config schema.
+
+## Examples
+
+See these real configs in the repository:
+
+- [`examples/pirate.hcl`](https://github.com/docker/docker-agent/blob/main/examples/pirate.hcl)
+- [`examples/gopher.hcl`](https://github.com/docker/docker-agent/blob/main/examples/gopher.hcl)
+- [`examples/instructions_from_file.hcl`](https://github.com/docker/docker-agent/blob/main/examples/instructions_from_file.hcl)
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/hooks/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/hooks/index.md
new file mode 100644
index 000000000000..34efe9d2b8e4
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/hooks/index.md
@@ -0,0 +1,952 @@
+---
+title: "Hooks"
+description: "Run shell commands at various points during agent execution for deterministic control over behavior."
+keywords: docker agent, ai agents, configuration, yaml, hooks
+weight: 60
+canonical: https://docs.docker.com/ai/docker-agent/configuration/hooks/
+---
+
+_Run shell commands at various points during agent execution for deterministic control over behavior._
+
+## Overview
+
+Hooks allow you to execute shell commands or scripts at key points in an agent's lifecycle. They provide deterministic control that works alongside the LLM's behavior, enabling validation, logging, environment setup, and more.
+
+> [!NOTE]
+> **Use Cases**
+>
+> - Validate or transform tool inputs before execution
+> - Log all tool calls to an audit file
+> - Block dangerous operations based on custom rules
+> - Validate, redact, or enrich user prompts before they reach the model
+> - Programmatically approve or deny tool calls without prompting the user
+> - Steer or veto context-window compaction
+> - Audit sub-agent handoffs in multi-agent setups
+> - Set up the environment when a session starts
+> - Clean up resources when a session ends
+> - Log or validate model responses before returning to the user
+> - Send external notifications on agent errors or warnings
+
+## Hook Types
+
+Docker Agent dispatches the following hook events:
+
+| Event                       | When it fires                                                                     | Can block? |
+| --------------------------- | --------------------------------------------------------------------------------- | ---------- |
+| `pre_tool_use`              | Before a tool call executes                                                       | Yes        |
+| `tool_response_transform`   | Between a tool's execution and the runtime's emission/record of the response      | No         |
+| `post_tool_use`             | After a tool completes — fires for both success and failure                       | Yes        |
+| `permission_request`        | Just before the runtime would prompt the user to approve a tool                   | Yes        |
+| `session_start`             | When a session begins or resumes                                                  | No         |
+| `user_prompt_submit`        | Once per user message, after submission and before the model runs                 | Yes        |
+| `user_steering_messages_submit` | Each time queued steering messages are drained (mid-turn, after stop, or while idle) | Yes    |
+| `user_followup_submit`      | Each time a queued follow-up message starts a fresh turn (end-of-turn)             | Yes        |
+| `turn_start`                | At the start of every agent turn (each model call)                                | No         |
+| `turn_end`                  | At the end of every agent turn — fires no matter why the turn ended               | No         |
+| `before_llm_call`           | Just before every model call (after `turn_start`)                                 | Yes        |
+| `after_llm_call`            | After every successful model call, before the response is recorded                | No         |
+| `session_end`               | When a session terminates                                                         | No         |
+| `pre_compact`               | Just before the runtime compacts the session transcript                           | Yes        |
+| `before_compaction`         | Just before a compaction runs — can veto or supply a custom summary               | Yes        |
+| `after_compaction`          | After a successful compaction (summary applied to the session)                    | No         |
+| `subagent_stop`             | When a sub-agent (transferred task / background / skill sub-session) finishes     | No         |
+| `on_user_input`             | When the agent is waiting for user input                                          | No         |
+| `stop`                      | When the model finishes responding                                                | No         |
+| `notification`              | When the agent emits a notification (error or warning)                            | No         |
+| `on_error`                  | When the runtime hits an error during a turn (fires alongside `notification`)     | No         |
+| `on_max_iterations`         | When the runtime reaches its configured `max_iterations` limit                    | No         |
+| `on_agent_switch`           | When the runtime moves the active agent (transfer_task, handoff, return)          | No         |
+| `on_session_resume`         | When the user explicitly approves continuation past `max_iterations`              | No         |
+| `on_tool_approval_decision` | After the runtime's approval chain (permissions / yolo / readonly / ask) resolves | No         |
+| `worktree_create`           | After `docker agent run --worktree` creates a git worktree, before the session     | Yes        |
+
+> [!NOTE]
+> **Two compaction events**
+>
+> `pre_compact` and `before_compaction` both fire just before a compaction. `pre_compact` is the original event and is best-suited to _steering_ the LLM-generated summary by appending guidance via `additional_context`. `before_compaction` is the newer, structured event: it carries the input/output token counts, the model's context limit, and a `compaction_reason` so handlers can decide based on real session pressure, and it can _replace_ the LLM-generated summary verbatim via `hook_specific_output.summary`.
+
+## Configuration
+
+You can configure hooks directly in an agent YAML file under the agent's `hooks:` block:
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-4o
+    description: An agent with hooks
+    instruction: You are a helpful assistant.
+    hooks:
+      # Run before specific tools
+      pre_tool_use:
+        - matcher: "shell|edit_file"
+          hooks:
+            - type: command
+              command: "./scripts/validate-command.sh"
+              timeout: 30
+
+      # Run after all tool calls
+      post_tool_use:
+        - matcher: "*"
+          hooks:
+            - type: command
+              command: "./scripts/log-tool-call.sh"
+
+      # Run when session starts
+      session_start:
+        - type: command
+          command: "./scripts/setup-env.sh"
+
+      # Run when session ends
+      session_end:
+        - type: command
+          command: "./scripts/cleanup.sh"
+
+      # Run when agent is waiting for user input
+      on_user_input:
+        - type: command
+          command: "./scripts/notify.sh"
+
+      # Run when the model finishes responding
+      stop:
+        - type: command
+          command: "./scripts/log-response.sh"
+
+      # Run on agent errors and warnings
+      notification:
+        - type: command
+          command: "./scripts/alert.sh"
+```
+
+Each event takes a list of hooks. A single hook can also be written directly
+as a mapping, without the list dash:
+
+```yaml
+stop:
+  type: command
+  command: "./scripts/log-response.sh"
+```
+
+## Global (user-level) hooks
+
+Global hooks let you apply the same hook configuration to every agent you run. Define them in your user config file at `~/.config/cagent/config.yaml` under `settings.hooks`:
+
+```yaml
+# ~/.config/cagent/config.yaml
+settings:
+  hooks:
+    session_start:
+      - type: command
+        command: "~/.config/cagent/hooks/session-start.sh"
+    pre_compact:
+      - type: command
+        command: "~/.config/cagent/hooks/pre-compact.sh"
+    pre_tool_use:
+      - matcher: "shell"
+        hooks:
+          - type: command
+            command: "~/.config/cagent/hooks/check-shell.sh"
+```
+
+Global hooks use the same schema as agent-level hooks and are additive. If an event is configured in multiple places, all matching hooks run in this order:
+
+1. Agent-config hooks from the agent YAML
+2. Global hooks from `settings.hooks`
+3. Hook drop-ins from `<config-dir>/hooks.d/` (lexicographic file order)
+4. CLI hooks from `--hook-*` flags
+
+Global hooks cannot be suppressed by an individual agent. Use them for user-wide audit logging, personal guardrails, notifications, and setup/cleanup behavior that should apply everywhere.
+
+### Hook drop-in files (`hooks.d`)
+
+External tools that integrate with Docker Agent (terminal emulators, IDEs, audit or observability sidecars) shouldn't have to rewrite your `config.yaml` to install a hook. Instead, Docker Agent also loads every `*.yaml` / `*.yml` file from the `hooks.d` directory next to your user config (default: `~/.config/cagent/hooks.d/`). Each file is a standalone hooks block with the same schema as the content of `settings.hooks`:
+
+```yaml
+# ~/.config/cagent/hooks.d/50-mytool.yaml
+session_start:
+  - type: command
+    command: mytool notify --event session-start
+stop:
+  - type: command
+    command: mytool notify --event stop
+```
+
+- Files are loaded in lexicographic order and merged additively after `settings.hooks` (use numeric prefixes like `10-`, `50-` to control ordering).
+- A malformed file is skipped with a logged warning; a broken drop-in never breaks a run.
+- Installing an integration means writing one self-contained file; uninstalling means deleting it. No shared-file edits, no conflicts between tools.
+
+The config directory can be relocated with the `--config-dir` flag or the `DOCKER_AGENT_CONFIG_DIR` (legacy `CAGENT_CONFIG_DIR`) environment variable, which external tools can use to locate `hooks.d` under non-default config dirs.
+
+## Built-in Hooks
+
+In addition to shell `command` hooks, Docker Agent ships a small library of **built-in hooks** — in-process Go functions that run without spawning a subprocess. They're invoked with `type: builtin`, where `command` is the builtin's registered name and `args` are passed through as the builtin's parameters.
+
+```yaml
+hooks:
+  turn_start:
+    - type: builtin
+      command: add_date
+    - type: builtin
+      command: add_prompt_files
+      args:
+        - GUIDELINES.md
+        - PROJECT.md
+  session_start:
+    - type: builtin
+      command: add_environment_info
+  before_llm_call:
+    - type: builtin
+      command: max_iterations
+      args: ["50"]
+```
+
+Built-ins are typically zero-config and faster than equivalent shell hooks because they don't fork a process. They cover the common "inject context into every turn / session" patterns out of the box.
+
+### Available built-ins
+
+| Builtin                 | Event                                                                                     | Args                  | What it does                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| ----------------------- | ----------------------------------------------------------------------------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `add_date`              | `turn_start`                                                                              | _none_                | Prepends `Today's date: YYYY-MM-DD` so the model always knows the current date.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| `add_environment_info`  | `session_start`                                                                           | _none_                | Adds the working directory, git-repo status, OS, and CPU architecture.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
+| `add_prompt_files`      | `turn_start`                                                                              | `[file1, file2, ...]` | Reads each named file from the workdir hierarchy (walking up) and the home directory, and appends their contents.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| `add_git_status`        | `turn_start`                                                                              | _none_                | Adds the output of `git status --short --branch` (no-op outside a git repo or when git isn't installed).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| `add_git_diff`          | `turn_start`                                                                              | _none_, or `["full"]` | Adds `git diff --stat` by default. Pass `args: ["full"]` to emit the full unified diff. Output is capped to 4 KB.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| `add_directory_listing` | `session_start`                                                                           | _none_                | Adds an alphabetical listing of the cwd's top-level entries (skips dot-files, capped at 100 with a "... and N more").                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| `add_user_info`         | `session_start`                                                                           | _none_                | Adds the current OS user (username and full name) and the hostname.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| `add_recent_commits`    | `session_start`                                                                           | _none_, or `["<N>"]`  | Adds `git log --oneline -n N`. `N` defaults to 10; pass a positive integer to override.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
+| `max_iterations`        | `before_llm_call`                                                                         | `["<N>"]` (required)  | Hard-stops the agent after `N` model calls. Stateless: the runtime supplies the iteration counter on every dispatch.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| `snapshot`              | `session_start`, `turn_start`, `turn_end`, `pre_tool_use`, `post_tool_use`, `session_end` | _none_                | Records filesystem snapshots in a shadow git repo under the Docker Agent data directory. No-op outside git repos; respects the source repo's ignore rules and skips newly-added files larger than 2 MiB.                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| `redact_secrets`        | `pre_tool_use`, `before_llm_call`, `tool_response_transform`                              | _none_                | Scrubs detected secrets (API keys, tokens, private keys, …) out of tool call arguments, outgoing chat content, and tool output. The same builtin handles all three events and dispatches on the event name. Auto-registered on all three events by `redact_secrets: true` on the agent — see [`examples/redact_secrets_hooks.yaml`](https://github.com/docker/docker-agent/blob/main/examples/redact_secrets_hooks.yaml) for the manual wiring.                                                                                                                                                                                     |
+| `limit_large_tool_results` | `tool_response_transform`, `session_end`                                               | _none_                | **Always-on safety hook** — automatically injected by the runtime, no configuration required. When a tool result from the `filesystem`, `shell`, `mcp`, or `a2a` categories exceeds 2,000 lines or 50 KiB, the full payload is written to a per-session temp file and replaced in the conversation with a notice plus a bounded excerpt (2,000 lines, up to 50 KiB): the tail for most tools, but the head for the built-in filesystem `read_file`, whose notice suggests a follow-up call with `line`/`limit` to continue reading. The `session_end` leg deletes the temp directory. Internal toolsets (`memory`, `plan`, `tasks`, `think`, …) are not affected. |
+| `safer_shell`           | `pre_tool_use`                                                                            | _none_                | **Deprecated compatibility shim.** The runtime now classifies every shell command natively (`safe` / `destructive` / `unknown`) and gates it through the session's [safety mode](../permissions/index.md#safety-modes), so this builtin no longer emits verdicts. Pinned entries keep working as pure labellers that attach classification metadata (`safety_label`, `blast_radius`, `category`, `reason`) to the call. Filters by tool name internally (no-op for non-shell calls). |
+| `unload`                | `on_agent_switch`                                                                         | _none_                | POSTs `{"model": "<id>"}` to each of the previous agent's DMR model endpoints (`/_unload` by default, overridable per-model via `unload_api`) to free the GPU/RAM the just-departing model was holding. Pure HTTP — reads the model snapshot the runtime ships on `on_agent_switch` and depends on no provider-specific runtime state. Non-DMR providers (OpenAI, Anthropic, …) are silently skipped, so cross-provider chains are safe. Errors are logged and swallowed; agent switching never blocks on a slow or unreachable engine (each call has a 10 s timeout). See [`examples/unload_on_switch.yaml`](https://github.com/docker/docker-agent/blob/main/examples/unload_on_switch.yaml). |
+
+> [!NOTE]
+> **Per-turn vs. per-session**
+>
+> `turn_start` built-ins recompute every turn and contribute **transient** context that is _not_ persisted to the session — perfect for fast-moving signals like the date or current git state. `session_start` built-ins run once per session and their context **persists** across turns and resumes — pick this for stable context like the OS user or the initial directory listing.
+
+> [!NOTE]
+> **Auto-injected built-ins**
+>
+> The agent flags `add_date: true`, `add_environment_info: true`, `add_prompt_files: [...]`, and `redact_secrets: true` are shorthands that auto-register the matching built-in hook. You don't need to repeat them under `hooks:` — set the flag _or_ the hook entry(ies), not both. `redact_secrets: true` auto-registers the same builtin on all three of `pre_tool_use`, `before_llm_call`, and `tool_response_transform`; you can also wire any subset of them by hand for finer-grained control (per-tool matchers, ordering with other rewriters, …).
+>
+> `limit_large_tool_results` is injected unconditionally by the runtime — it is always active and cannot be removed from config.
+
+A minimal snapshot wiring looks like this:
+
+```yaml
+hooks:
+  turn_start:
+    - type: builtin
+      command: snapshot
+  turn_end:
+    - type: builtin
+      command: snapshot
+  session_end:
+    - type: builtin
+      command: snapshot
+```
+
+The shadow repository stores tree objects only; it never writes commits or touches the source repository's `.git` directory. The source repository's `.gitignore` and `info/exclude` rules are mirrored before each capture so ignored files do not appear in snapshots. The built-in only records undo checkpoints when files changed, so a final no-op model response does not hide the last changed snapshot.
+
+You can also enable snapshots globally for every agent with user config:
+
+```yaml
+settings:
+  snapshot: true
+```
+
+Omit `snapshot` or set it to `false` to leave automatic snapshots off; manually configured snapshot hooks still run.
+
+See [`examples/snapshot_hooks.yaml`](https://github.com/docker/docker-agent/blob/main/examples/snapshot_hooks.yaml) for a complete snapshot hook configuration. For an overview of the snapshot feature and the `/undo` / `/snapshots` commands, see [Snapshots](../../features/snapshots/index.md).
+
+> [!WARNING]
+> **Two flavors of `max_iterations`**
+>
+> The `max_iterations` agent field has its own UX (it pauses and asks the user to resume past the limit). The `max_iterations` built-in hook is a **hard stop with no resume** — when its counter trips, the agent terminates with a block decision. Use the agent field for interactive sessions and the built-in hook to enforce non-negotiable caps in unattended runs.
+
+## Matcher Patterns
+
+The `matcher` field uses regex patterns to match tool names:
+
+| Pattern            | Matches                       |
+| ------------------ | ----------------------------- |
+| `*`                | All tools                     |
+| `shell`            | Only the `shell` tool         |
+| `shell\|edit_file` | Either `shell` or `edit_file` |
+| `mcp:.*`           | All MCP tools (regex)         |
+
+## Hook Input
+
+Hooks receive JSON input via stdin with context about the event:
+
+```json
+{
+  "session_id": "abc123",
+  "cwd": "/path/to/project",
+  "hook_event_name": "pre_tool_use",
+  "tool_name": "shell",
+  "tool_use_id": "call_xyz",
+  "tool_input": {
+    "cmd": "rm -rf /tmp/cache",
+    "cwd": "."
+  }
+}
+```
+
+### Common Fields
+
+Every hook event carries:
+
+| Field             | Description                           |
+| ----------------- | ------------------------------------- |
+| `session_id`      | The current session's ID.             |
+| `cwd`             | The runtime's working directory.      |
+| `hook_event_name` | The event name (e.g. `pre_tool_use`). |
+
+### Per-Event Extra Fields
+
+In addition to the common fields, each event ships its own payload:
+
+| Event                       | Extra fields                                                                                                          |
+| --------------------------- | --------------------------------------------------------------------------------------------------------------------- |
+| `pre_tool_use`              | `agent_name`, `tool_name`, `tool_use_id`, `tool_input`                                                                |
+| `tool_response_transform`   | `tool_name`, `tool_use_id`, `tool_input`, `tool_response`                                                             |
+| `post_tool_use`             | `agent_name`, `tool_name`, `tool_use_id`, `tool_input`, `tool_response`, `tool_error`                                 |
+| `permission_request`        | `agent_name`, `tool_name`, `tool_use_id`, `tool_input`                                                                |
+| `session_start`             | `source` — one of `startup`, `resume`, `clear`, `compact`                                                             |
+| `user_prompt_submit`        | `prompt` — the text the user just submitted                                                                           |
+| `user_steering_messages_submit` | `steering_messages` — the drained steering messages, in submission order                                         |
+| `user_followup_submit`      | `prompt` — the text of the dequeued follow-up message                                                                |
+| `turn_start`                | _none_ (just the common fields)                                                                                       |
+| `turn_end`                  | `agent_name`, `reason` — one of `normal`, `continue`, `steered`, `error`, `canceled`, `hook_blocked`, `loop_detected` |
+| `before_llm_call`           | `iteration` — 1-based run-loop iteration counter (the model call this hook is gating), `model_id`                    |
+| `after_llm_call`            | `agent_name`, `stop_response`, `last_user_message`, `model_id`, `usage`, `cost`                                       |
+| `session_end`               | `reason` — one of `clear`, `logout`, `prompt_input_exit`, `other`                                                     |
+| `pre_compact`               | `source` — one of `manual`, `auto`, `overflow`, `tool_overflow`                                                       |
+| `before_compaction`         | `input_tokens`, `output_tokens`, `context_limit`, `compaction_reason` (one of `threshold`/`overflow`/`manual`)        |
+| `after_compaction`          | `input_tokens`, `output_tokens`, `context_limit`, `compaction_reason`, `summary`                                      |
+| `subagent_stop`             | `agent_name` (the sub-agent), `parent_session_id`, `stop_response`                                                    |
+| `on_user_input`             | _none_                                                                                                                |
+| `stop`                      | `agent_name`, `stop_response`, `last_user_message`                                                                    |
+| `notification`              | `notification_level` (`error` or `warning`), `notification_message`                                                   |
+| `on_error`                  | `notification_level` (always `error`), `notification_message`                                                         |
+| `on_max_iterations`         | `notification_level` (always `warning`), `notification_message`                                                       |
+| `on_agent_switch`           | `from_agent`, `to_agent`, `agent_switch_kind` (`transfer_task`, `transfer_task_return`, `handoff`, or `force_handoff`)                 |
+| `on_session_resume`         | `previous_max_iterations`, `new_max_iterations`                                                                       |
+| `on_tool_approval_decision` | `tool_name`, `tool_use_id`, `tool_input`, `approval_decision`, `approval_source`                                      |
+| `worktree_create`           | `worktree_path`, `worktree_branch`, `worktree_source_dir` (`cwd` is also set to the new worktree)                     |
+
+Notes:
+
+- `tool_response` for `post_tool_use` carries the tool's result; `tool_error` is `true` when the tool failed (the failure detail is surfaced inside `tool_response`).
+- `agent_name` on `pre_tool_use`, `post_tool_use`, and `permission_request` identifies the agent that issued the tool call — in multi-agent setups this follows the active sub-agent, not always the root agent.
+- `prompt` is only populated for `user_prompt_submit`. Sub-sessions (transferred tasks, background agents, skills) do **not** fire this event because their kick-off message is synthesised by the runtime, not authored by the user.
+- `steering_messages` is only populated for `user_steering_messages_submit`. It carries the user messages the runtime just drained from the steering queue — messages submitted while the agent was already working (mid-turn, after the model stopped, or while idle before the first model call).
+- `prompt` is also populated for `user_followup_submit`, carrying the text of the dequeued follow-up message (a user message queued for end-of-turn processing via the FollowUp API / queue, as opposed to mid-turn steering).
+- `stop_response` carries the model's final assistant text for `stop`, `after_llm_call`, and `subagent_stop`. `last_user_message` carries the latest user message at dispatch time.
+- `model_id` is populated for `after_llm_call` (and `before_llm_call`) in the canonical `<provider>/<model>` form (e.g. `anthropic/claude-sonnet-4-5`). For harness agents, `model_id` is the harness label (e.g. `claude-code`) rather than a canonical model name — see [Coding Harnesses](../../features/harnesses/index.md).
+- `usage` and `cost` are populated for `after_llm_call` only. `usage` is the per-call token usage object (`input_tokens`, `output_tokens`, `cached_input_tokens`, `cached_write_tokens`, and `reasoning_tokens` — the last is itself omitted for non-reasoning models); the whole object is absent when the provider reported no usage. `cost` is the USD price of that one model response. For a **native model call** it is the price computed from `usage` and the model's pricing table, and equals the cost the session records for the turn: it is **absent** when the response is unpriced (no pricing data on file, or no usage) and an explicit `0` for a priced call that was free — so a present `cost` is authoritative and an absent one means "unpriced", with no need to cross-check `usage`. Models the catalogue does not price (custom endpoints, local models) can be priced explicitly with the model-level [`cost`](../models/index.md#custom-token-pricing) config. (For harness agents the meaning differs — see the next note.) A cost ledger can therefore record per-call spend from the payload alone, without subscribing to the runtime event channel.
+- For [harness agents](../../features/harnesses/index.md), `cost` is the harness's own reported total for the call rather than a computed price, and is present only when the harness reported a non-zero cost (some harnesses, e.g. `codex`, report token counts but no cost — those turns carry `usage` with `cost` absent, even though the recorded message stores `0`).
+- `after_llm_call` fires for **every** model call, including calls made inside sub-sessions (transferred tasks, background agents, skills). For those, `session_id` is the sub-session's id. Summing `cost` across `after_llm_call` events therefore captures **all** spend, including sub-sessions (and even sub-sessions that error before their cost is persisted). Do **not** add a separately-queried session cost total on top: the runtime's own total already recurses into and includes completed sub-session spend, so combining the two double-counts. Pick one source — the summed hook costs — as the authoritative ledger.
+- `context_limit` is `0` when the model definition is unavailable (treat `0` as "unknown", not as a real limit).
+- `approval_decision` is one of `allow`, `deny`, `canceled`. `approval_source` is a stable classifier of which step decided (e.g. `yolo`, `session_permissions_allow`, `session_permissions_deny`, `team_permissions_allow`, `team_permissions_deny`, `pre_tool_use_hook_allow`, `pre_tool_use_hook_deny`, `readonly_hint`, `user_approved`, `user_approved_session`, `user_approved_safe`, `user_approved_tool`, `user_rejected`, `context_canceled`).
+
+## Hook Output
+
+Hooks communicate back via JSON output to stdout:
+
+```json
+{
+  "continue": true,
+  "stop_reason": "Optional message when continue=false",
+  "suppress_output": false,
+  "system_message": "Warning message to show user",
+  "decision": "block",
+  "reason": "Explanation for the decision",
+  "hook_specific_output": {
+    "hook_event_name": "pre_tool_use",
+    "permission_decision": "allow",
+    "permission_decision_reason": "Command is safe",
+    "updated_input": { "cmd": "modified command" }
+  }
+}
+```
+
+All fields are optional. Returning `{}` (or no output at all) means "do nothing, continue normally".
+
+### Output Fields
+
+| Field             | Type    | Description                                     |
+| ----------------- | ------- | ----------------------------------------------- |
+| `continue`        | boolean | Whether to continue execution (default: `true`) |
+| `stop_reason`     | string  | Message to show when `continue=false`           |
+| `suppress_output` | boolean | Hide stdout from transcript                     |
+| `system_message`  | string  | Warning message to display to user              |
+| `decision`        | string  | For blocking: `block` to prevent operation      |
+| `reason`          | string  | Explanation for the decision                    |
+
+### Pre-Tool-Use / Permission-Request Specific Output
+
+The `hook_specific_output` for `pre_tool_use` (and `permission_request`) supports:
+
+| Field                        | Type   | Description                             |
+| ---------------------------- | ------ | --------------------------------------- |
+| `permission_decision`        | string | `allow`, `deny`, or `ask`               |
+| `permission_decision_reason` | string | Explanation for the decision            |
+| `updated_input`              | object | Modified tool input (replaces original) |
+| `metadata`                   | object | (`permission_request` and `pre_tool_use` entries with `preempt_yolo: true` only) string key/value annotations merged onto the tool-call confirmation prompt — see below |
+
+### Preempting auto-approval from `pre_tool_use`
+
+`pre_tool_use` entries default to firing AFTER the deterministic approval
+pipeline (custom allow rules / safety mode), so an auto-approved call
+skips them entirely. For security-critical checks that MUST run on every
+call regardless of the safety mode (including `autonomous`, the legacy
+`--yolo`), set `preempt_yolo: true` on the matcher entry:
+
+```yaml
+hooks:
+  pre_tool_use:
+    - matcher: "*"
+      preempt_yolo: true
+      hooks:
+        - type: command
+          command: ./security-check.sh
+```
+
+The entry then fires in a dedicated stage 0 BEFORE `Decide()`:
+
+- `deny` rejects the call outright; the user is not prompted.
+- `ask` forces user confirmation. The default `pre_tool_use` lane and
+  `permission_request` are skipped on this path so a policy-level
+  allow there can't override the security verdict. The one exception
+  is a session-scoped allow grant (the interactive "always allow this
+  tool" decision) — an informed user opt-in made in response to this
+  very prompt.
+- `allow` is advisory — the pipeline still runs `Decide()` and the
+  rest of `pre_tool_use`. Same shape as a regular `allow` on the
+  default lane, just observed earlier.
+- No verdict (empty `permission_decision`) falls through.
+
+Hook crashes on a `preempt_yolo: true` entry fail closed (deny), matching
+the default `pre_tool_use` posture.
+
+Preempting entries can attach structured context via
+`hook_specific_output.metadata` (`map[string]string`). The runtime merges
+that into the tool-call confirmation event, on top of the metadata it
+already derives from its own safety classification (`safety_label`,
+`blast_radius`, `category`, `reason`). Key conventions with special
+rendering in the TUI confirmation prompt:
+
+- `safety_label` — the three-value taxonomy: `safe`, `destructive`, or
+  `unknown`.
+- `blast_radius` — one of `safe`, `low`, `medium`, `high`, `unknown`.
+  Rendered as a colored severity badge (green / yellow / red / muted).
+- `category` — taxonomy tag (e.g. `fs-delete`, `dk-volume-del`).
+
+Plus a free-form `reason` key that the dialog shows as supporting
+context. Other keys render as plain text. Last writer wins on key
+clashes across hooks, and preempting entries win over the runtime's own
+classification.
+
+### Tool-Response-Transform Specific Output
+
+The `hook_specific_output` for `tool_response_transform` supports:
+
+| Field                   | Type   | Description                                   |
+| ----------------------- | ------ | --------------------------------------------- |
+| `updated_tool_response` | string | Rewritten tool output (replaces the original) |
+
+This is the symmetric counterpart of `pre_tool_use`'s `updated_input`, applied to tool **results** instead of tool **arguments**. The rewrite reaches every downstream consumer — event subscribers, the persisted session file, the `post_tool_use` hook input, and the next LLM call. Use it to truncate excessive output, scrub PII, or normalise tool dialects. The built-in `redact_secrets` registers itself on this event as the third leg of the redact_secrets feature.
+
+### Context-Contributing Events
+
+For `session_start`, `user_prompt_submit`, `user_steering_messages_submit`, `user_followup_submit`, `turn_start`, `post_tool_use`, `pre_compact`, and `stop`, hooks may set `hook_specific_output.additional_context` to inject text into the conversation. `turn_start` context is **transient** (recomputed every turn, never persisted); `session_start` context **persists** for the life of the session. `user_steering_messages_submit` and `user_followup_submit` context is **transient** like `user_prompt_submit` — it is spliced into the steered/follow-up turn only and never persisted. (`worktree_create` also surfaces stdout, but to the CLI user rather than the conversation — the session doesn't exist yet.)
+
+### Before-Compaction Specific Output
+
+For `before_compaction`, the `hook_specific_output.summary` field, when non-empty, replaces the LLM-generated compaction summary. The runtime applies the string verbatim and skips the model call.
+
+```json
+{
+  "hook_specific_output": {
+    "hook_event_name": "before_compaction",
+    "summary": "User asked to refactor pkg/foo. Done in commit abc123."
+  }
+}
+```
+
+Returning `decision: "block"` (or exit code 2) instead vetoes the compaction entirely. Be cautious about denying when `compaction_reason` is `overflow`: the runtime is recovering from a context-overflow error and a denial there will leave the session unable to make progress.
+
+### Plain Text Output
+
+For `session_start`, `user_prompt_submit`, `user_steering_messages_submit`, `user_followup_submit`, `turn_start`, `post_tool_use`, `pre_compact`, and `stop` hooks, plain text written to stdout (i.e., output that is not valid JSON) is captured as additional context for the agent. For `pre_compact` it is appended to the compaction prompt; for the others it is spliced into the conversation as a (transient or persisted) system message depending on the event.
+
+## Exit Codes
+
+Hook exit codes have special meaning:
+
+| Exit Code | Meaning                                |
+| --------- | -------------------------------------- |
+| `0`       | Success — continue normally            |
+| `2`       | Blocking error — stop the operation    |
+| Other     | Error — logged but execution continues |
+
+## Per-hook options
+
+Hooks have a default timeout of 60 seconds. You can also give hooks a name, add environment variables, choose a working directory, and control how non-security hook failures behave:
+
+```yaml
+hooks:
+  post_tool_use:
+    - matcher: "shell"
+      hooks:
+        - name: "summarize shell output"
+          type: command
+          command: "./summarize.sh"
+          timeout: 120 # 2 minutes
+          working_dir: ./hooks
+          env:
+            PROFILE: dev
+          on_error: warn # warn | ignore | block
+```
+
+`pre_tool_use` is fail-closed for safety: a failed pre-tool hook blocks the tool call regardless of `on_error`.
+
+`working_dir` and `env` apply to `command` and `builtin` hooks. For `builtin` hooks, `working_dir` is resolved with the same logic as `command` hooks (absolute path wins; relative paths join onto the executor directory). `working_dir` accepts `~`, `$VAR`, `${VAR}` and `${env.VAR}`; `env` values expand only the plain `${env.VAR}` form (resolved from the OS process environment), keeping any other `$` literal (see [Variable Expansion in Config Fields](../overview/index.md#variable-expansion-in-config-fields)). A `working_dir` that expands to an empty string (e.g. an unset variable) falls back to the executor's directory with a warning. For `model` hooks, both fields are accepted by the schema but have no effect: model hooks render a prompt template and call the LLM API directly — no subprocess is spawned and no file I/O is performed, so working directory and environment variables have no applicable semantics.
+
+> [!WARNING]
+> **Performance**
+>
+> Hooks run synchronously and can slow down agent execution. Keep hook scripts fast and efficient. Consider using `suppress_output: true` for logging hooks to reduce noise.
+
+> [!NOTE]
+> **Session End and Cancellation**
+>
+> `session_end` hooks are designed to run even when the session is interrupted (e.g., Ctrl+C). They are still subject to their configured timeout.
+
+## Examples
+
+### Validation Script
+
+A simple pre-tool-use hook that blocks dangerous shell commands:
+
+```bash
+#!/bin/bash
+# scripts/validate-command.sh
+
+# Read JSON input from stdin
+INPUT=$(cat)
+TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name')
+CMD=$(echo "$INPUT" | jq -r '.tool_input.cmd // empty')
+
+# Block dangerous commands
+if [[ "$TOOL_NAME" == "shell" ]]; then
+  if [[ "$CMD" =~ ^sudo ]] || [[ "$CMD" =~ rm.*-rf ]]; then
+    echo '{"decision": "block", "reason": "Dangerous command blocked by policy"}'
+    exit 2
+  fi
+fi
+
+# Allow everything else (returning {} means "do nothing, continue normally")
+echo '{}'
+exit 0
+```
+
+### Audit Logging
+
+A post-tool-use hook that logs all tool calls:
+
+```bash
+#!/bin/bash
+# scripts/log-tool-call.sh
+
+INPUT=$(cat)
+TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
+TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name')
+SESSION_ID=$(echo "$INPUT" | jq -r '.session_id')
+
+# Append to audit log
+echo "$TIMESTAMP | $SESSION_ID | $TOOL_NAME" >> ./audit.log
+
+# Don't block execution
+echo '{"continue": true}'
+exit 0
+```
+
+### Session Lifecycle
+
+Session start and end hooks for environment setup and cleanup:
+
+```yaml
+hooks:
+  session_start:
+    - type: command
+      timeout: 10
+      command: |
+        INPUT=$(cat)
+        SESSION_ID=$(echo "$INPUT" | jq -r '.session_id // "unknown"')
+        echo "Session $SESSION_ID started at $(date)" >> /tmp/agent-session.log
+        echo '{"hook_specific_output":{"additional_context":"Session initialized."}}'
+
+  session_end:
+    - type: command
+      timeout: 10
+      command: |
+        INPUT=$(cat)
+        SESSION_ID=$(echo "$INPUT" | jq -r '.session_id // "unknown"')
+        REASON=$(echo "$INPUT" | jq -r '.reason // "unknown"')
+        echo "Session $SESSION_ID ended ($REASON) at $(date)" >> /tmp/agent-session.log
+```
+
+### Response Logging with Stop Hook
+
+Log every model response for analytics or compliance:
+
+```yaml
+hooks:
+  stop:
+    - type: command
+      timeout: 10
+      command: |
+        INPUT=$(cat)
+        SESSION_ID=$(echo "$INPUT" | jq -r '.session_id // "unknown"')
+        RESPONSE_LENGTH=$(echo "$INPUT" | jq -r '.stop_response // ""' | wc -c | tr -d ' ')
+        echo "[$(date)] Session $SESSION_ID - Response: $RESPONSE_LENGTH chars" >> /tmp/agent-responses.log
+```
+
+The `stop` hook is useful for:
+
+- **Response quality checks** — validate that responses meet criteria before returning
+- **Analytics** — track response lengths, patterns, or content
+- **Compliance logging** — record all agent outputs for audit
+
+### Error Notifications
+
+Send alerts when the agent encounters errors:
+
+```yaml
+hooks:
+  notification:
+    - type: command
+      timeout: 10
+      command: |
+        INPUT=$(cat)
+        LEVEL=$(echo "$INPUT" | jq -r '.notification_level // "unknown"')
+        MESSAGE=$(echo "$INPUT" | jq -r '.notification_message // "no message"')
+        echo "[$(date)] [$LEVEL] $MESSAGE" >> /tmp/agent-notifications.log
+```
+
+The `notification` hook fires when:
+
+- The model returns an error (all models failed) — also fires `on_error`
+- A degenerate tool call loop is detected — also fires `on_error`
+- The maximum iteration limit is reached — also fires `on_max_iterations`
+
+Use `on_error` and `on_max_iterations` instead of `notification` when you want a structured handler for one of these conditions without parsing `notification_level`.
+
+### Turn-Start: per-turn context
+
+`turn_start` fires at the start of every agent turn (each model call). Anything you contribute via `additional_context` (or plain stdout) is appended as a **transient** system message for that turn only — it is *not* persisted to the session. Use it for fast-moving signals like the date, current git state, or per-turn prompt files. The built-in hooks `add_date`, `add_prompt_files`, `add_git_status`, and `add_git_diff` all target this event.
+
+### Turn-End: per-turn finalizer
+
+`turn_end` is the symmetric counterpart of `turn_start`. It fires once per turn when the iteration finishes — no matter why. The runtime guarantees the dispatch on every exit path (a normal stop, an error, a hook-driven shutdown, the loop detector, even context cancellation), and it uses `context.WithoutCancel` internally so handlers run to completion on Ctrl+C.
+
+The `reason` field classifies the exit:
+
+| `reason`        | When                                                         |
+| --------------- | ------------------------------------------------------------ |
+| `normal`        | Model finished cleanly with no follow-up                     |
+| `continue`      | More iterations to come (e.g. tool calls, follow-up message) |
+| `steered`       | Drained steered messages prompted a re-entry                 |
+| `error`         | Model call failed (`handleStreamError` exited the loop)      |
+| `canceled`      | Context was cancelled (e.g. Ctrl+C)                          |
+| `hook_blocked`  | `before_llm_call` or `post_tool_use` denied the call         |
+| `loop_detected` | The consecutive-tool-call loop detector terminated the turn  |
+
+`turn_end` is observational — the result is ignored. Use it to time turns, accumulate per-turn metrics (token usage, tool counts), or notify external observability pipelines symmetrically with `turn_start`.
+
+### Before/After-LLM-Call: budget guards and model auditing
+
+`before_llm_call` fires immediately before every model call (after `turn_start` has assembled the messages). It cannot contribute context — use `turn_start` for that — but it can **stop the run** by returning `decision: block` (or exit code 2). The built-in `max_iterations` hook implements a hard cap on top of this event.
+
+`after_llm_call` fires immediately after each successful model call, before the response is recorded into the session and tool calls are dispatched. The assistant text is in `stop_response`, and the call's `usage` and `cost` carry the per-turn token usage and computed USD spend (see the field notes above). Use it for response auditing, redaction logging, quality metrics, or a sidecar cost ledger that records per-call spend without subscribing to the runtime event channel. Failed model calls fire `on_error` instead.
+
+### Before/After-Compaction: structured compaction control
+
+`before_compaction` fires immediately before a compaction. Unlike `pre_compact`, it carries structured token-pressure data: `input_tokens`, `output_tokens`, `context_limit`, and a `compaction_reason` (`threshold`, `overflow`, or `manual`). Hooks can either:
+
+- veto compaction by returning `decision: block` (the runtime skips compaction entirely), or
+- replace the LLM-generated summary by returning `hook_specific_output.summary` (the runtime applies that summary verbatim and skips the model call).
+
+`after_compaction` fires after a successful compaction. It carries the produced `summary` along with the *pre-compaction* `input_tokens` / `output_tokens` so observability handlers can naturally express "compacted from X to Y". `after_compaction` is purely observational; output is ignored.
+
+### Agent-Switch and Session-Resume: observability for multi-agent and long runs
+
+`on_agent_switch` fires whenever the runtime moves the active agent to a new one — `transfer_task`, `handoff`, `force_handoff`, or the return after a transferred task completes. The cause is in `agent_switch_kind`, the source and destination in `from_agent` and `to_agent`. Use it for audit, transcript, and metrics pipelines that track which agent ran which tools.
+
+The built-in [`unload`](#available-built-ins) hooks into this event to release the resources held by the previous agent's models. It's the canonical way to run two heavy local models on a GPU that can only fit one at a time:
+
+```yaml
+agents:
+  coder:
+    model: qwen3-large
+    handoffs: [reviewer]
+    hooks:
+      on_agent_switch:
+        - type: builtin
+          command: unload
+  reviewer:
+    model: qwen3-coder
+    handoffs: [coder]
+    hooks:
+      on_agent_switch:
+        - type: builtin
+          command: unload
+
+models:
+  qwen3-large:
+    provider: dmr
+    model: ai/qwen3-large
+  qwen3-coder:
+    provider: dmr
+    model: ai/qwen3-coder
+```
+
+At every transfer the runtime ships a snapshot of the previous agent's model endpoints on the `on_agent_switch` hook input, and the `unload` builtin POSTs `{"model": "<id>"}` to each DMR endpoint's `/_unload` URL over plain HTTP. For cloud providers (OpenAI, Anthropic, …) the hook is a silent no-op since they don't expose an HTTP unload endpoint. Cross-provider chains are safe — only DMR endpoints are touched. See [`examples/unload_on_switch.yaml`](https://github.com/docker/docker-agent/blob/main/examples/unload_on_switch.yaml) for the full file.
+
+`on_session_resume` fires when the user explicitly approves the runtime to continue past its configured `max_iterations` limit. `previous_max_iterations` carries the cap that was reached and `new_max_iterations` carries the new cap after approval. Useful for alerting on extended-runtime sessions or for billing / quota pipelines that meter resumes.
+
+### Tool-Approval-Decision: who-approved-what audit trail
+
+`on_tool_approval_decision` fires after the runtime's tool-approval chain (permissions / yolo / readonly / pre_tool_use hooks / interactive prompt) has resolved a verdict for a tool call. `approval_decision` is `allow`, `deny`, or `canceled`; `approval_source` is a stable classifier of which step produced the verdict. Observational only — it gives audit pipelines a single, structured "who approved what" record without re-implementing the chain.
+
+### Worktree-Create: prepare an isolated checkout
+
+`worktree_create` fires once, just after `docker agent run --worktree[=name]` creates a fresh [git worktree](../../features/cli/index.md) and **before** the session starts. Each hook runs **inside** the new worktree — its working directory (and `cwd` in the input) is the fresh checkout — so setup commands operate on the new tree rather than your original one. The worktree path and branch are in `worktree_path` and `worktree_branch`, and `worktree_source_dir` carries the repository root it was branched from.
+
+Use it to prepare the checkout before the agent begins: copy untracked files git won't carry over (`.env`, local config), install dependencies, or warm caches. Because the worktree lives under the Docker Agent data directory — not next to your checkout — resolve the original files through `worktree_source_dir` rather than a relative path. A hook may **abort the run** by returning `decision: block` / `{"continue": false}` / exit code 2 (for example, when a setup step fails); plain stdout is surfaced as additional context.
+
+```yaml
+hooks:
+  worktree_create:
+    # Copy untracked dotfiles git won't bring into the new worktree.
+    - name: seed local env
+      type: command
+      command: |
+        INPUT=$(cat)
+        SRC=$(echo "$INPUT" | jq -r '.worktree_source_dir // ""')
+        [ -n "$SRC" ] && [ -f "$SRC/.env" ] && [ ! -f .env ] && cp "$SRC/.env" .env
+        echo "Prepared worktree"
+    # Install dependencies, aborting the run on failure.
+    - name: install dependencies
+      type: command
+      timeout: 600
+      command: |
+        if [ -f package.json ]; then
+          npm install || { echo '{"continue": false, "system_message": "npm install failed"}'; exit 2; }
+        fi
+```
+
+Unlike most events, `worktree_create` is dispatched from the CLI rather than the run loop, because the worktree (and the working directory the runtime, session, tools, and snapshot machinery all capture) must be settled before the runtime and session exist. See [`examples/worktree_create_hook.yaml`](https://github.com/docker/docker-agent/blob/main/examples/worktree_create_hook.yaml) for the full file.
+
+### Pre-Compact: steer the summary
+
+`pre_compact` fires just before the runtime compacts the session transcript. Its `source` field tells you why compaction was triggered:
+
+- `manual` — the user invoked `/compact`
+- `auto` — proactive compaction at the configured threshold
+- `overflow` — emergency compaction after a context-overflow error
+- `tool_overflow` — proactive compaction triggered by tool results pushing the estimated context past the threshold
+
+Return `additional_context` (or plain stdout) to append guidance to the compaction prompt without modifying the agent's instruction. Block the event (`decision: block` / exit code 2) to cancel compaction — useful when you want to handle truncation yourself.
+
+### User-Prompt-Submit: gate or enrich every user message
+
+`user_prompt_submit` fires once per user message, after the prompt is recorded in the session and before the first model call. The submitted text is in `prompt`. Use it to:
+
+- block prompts that violate policy (`decision: block` / exit code 2),
+- inject per-prompt context (`additional_context` is spliced as a transient system message for that turn),
+- audit user prompts to a log.
+
+It does **not** fire for sub-sessions (transferred tasks, background agents, skill sub-sessions) because their kick-off message is synthesised by the runtime.
+
+### User-Steering-Messages-Submit: gate or enrich mid-flight steering
+
+`user_steering_messages_submit` is the steering-queue analogue of `user_prompt_submit`. It fires each time the runtime drains the steering queue — messages the user submitted while the agent was already working: mid-turn (after a batch of tool calls), after the model stopped, or while idle before the first model call. The drained messages arrive as a JSON array in `steering_messages`. Use it to:
+
+- block a run when steering violates policy (`decision: block` / exit code 2),
+- inject context in response to the steering (`additional_context` is spliced as a transient system message for the steered turn — never persisted, exactly like `user_prompt_submit`),
+- audit steering messages to a log.
+
+Unlike `turn_end` with `reason: steered`, which only observes the mid-turn and post-stop drains, this event fires on **every** drain — including steering applied while the agent was idle before its first model call.
+
+```yaml
+hooks:
+  user_steering_messages_submit:
+    - type: command
+      timeout: 5
+      command: |
+        INPUT=$(cat)
+        COUNT=$(echo "$INPUT" | jq -r '.steering_messages | length')
+        echo "$INPUT" | jq -r '.steering_messages[]' >> /tmp/agent-steering.log
+        if [ "$COUNT" -gt 0 ]; then
+          echo '{"hook_specific_output":{"additional_context":"The user sent new instructions while you were working — re-read the latest user messages and adjust course before continuing."}}'
+        fi
+```
+
+### User-Followup-Submit: gate or enrich queued follow-ups
+
+`user_followup_submit` is the follow-up-queue analogue of `user_prompt_submit`. It fires each time the runtime dequeues a follow-up message at the end of a turn and starts a fresh turn for it. Follow-ups are user messages queued for end-of-turn processing (the FollowUp API / queue) — distinct from mid-turn steering: the model sees a follow-up as fresh input, not an interruption, and each follow-up gets a full undivided turn. The follow-up text is in `prompt`. Use it to:
+
+- block a queued follow-up that violates policy (`decision: block` / exit code 2),
+- inject per-follow-up context (`additional_context` is spliced as a transient system message for the follow-up turn — never persisted, exactly like `user_prompt_submit`),
+- audit follow-up messages to a log.
+
+This closes the gap left by `user_prompt_submit`, which fires only for the first interactive prompt and never for queued follow-ups.
+
+```yaml
+hooks:
+  user_followup_submit:
+    - type: command
+      timeout: 5
+      command: |
+        INPUT=$(cat)
+        echo "$INPUT" | jq -r '.prompt' >> /tmp/agent-followups.log
+```
+
+### Subagent-Stop: observe handoff completions
+
+`subagent_stop` fires whenever a sub-agent finishes — `transfer_task` returns, a background agent completes, or a skill sub-session ends. It runs against the *parent* agent's hooks executor, so handlers configured on the orchestrator see every child completion in one place. The sub-agent's name is in `agent_name`, the parent's session ID in `parent_session_id`, and the child's final assistant message in `stop_response`.
+
+### Permission-Request: programmatic tool approval
+
+`permission_request` fires just before the runtime would prompt the user to approve a tool call (i.e. when neither the safety mode nor a permissions rule short-circuited the decision). Use the same `hook_specific_output.permission_decision` shape as `pre_tool_use` to auto-approve or auto-deny the call:
+
+```yaml
+hooks:
+  permission_request:
+    - matcher: "shell"
+      hooks:
+        - type: command
+          command: |
+            INPUT=$(cat)
+            CMD=$(echo "$INPUT" | jq -r '.tool_input.cmd // ""')
+            if echo "$CMD" | grep -qE '^(ls|pwd|cat) '; then
+              echo '{"hook_specific_output":{"permission_decision":"allow","permission_decision_reason":"safe read-only command"}}'
+            fi
+```
+
+Return nothing to fall through to the usual interactive confirmation.
+
+When the hook falls through (returns no `permission_decision`), it can still attach key/value `metadata` to the confirmation prompt the runtime shows the user. The runtime merges it onto any static metadata the toolset attached to the tool (hook keys win on a clash) and emits it on the tool-call confirmation message, so clients (TUI, HTTP) can render extra per-call context. Keys from multiple matching hooks are merged; the last hook in config order wins on a clash.
+
+```yaml
+hooks:
+  permission_request:
+    - matcher: "shell"
+      hooks:
+        - type: command
+          command: |
+            INPUT=$(cat)
+            CMD=$(echo "$INPUT" | jq -r '.tool_input.cmd // ""')
+            if echo "$CMD" | grep -qE '\brm\b'; then
+              echo '{"hook_specific_output":{"metadata":{"risk":"high","note":"deletes files"}}}'
+            fi
+```
+
+### LLM as a Judge (Auto-Approving Tool Calls)
+
+The `model` hook type asks an LLM and translates its reply into the
+hook's native output — no Go code, no shell glue, no JSON parsing on
+your side. Combined with the well-known `pre_tool_use_decision`
+schema it gives you a fully-configurable LLM judge that decides
+`allow` / `ask` / `deny` per tool call.
+
+```yaml
+hooks:
+  pre_tool_use:
+    - matcher: "shell|edit_file|mcp:.*"
+      hooks:
+        - type: model
+          model: openai/gpt-4o-mini
+          timeout: 15
+          schema: pre_tool_use_decision
+          prompt: |
+            You are a security judge for an autonomous agent.
+            Decide whether this tool call is safe to auto-approve.
+
+            Tool: {{ .ToolName }}
+            Args: {{ .ToolInput | toJSON }}
+
+            Project rules:
+            - Reads under the working directory are safe.
+            - Writes to ~/.ssh / ~/.aws / ~/.docker are deny.
+```
+
+| Field     | Required         | Description                                                                                                                                                               |
+| --------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `model`   | yes              | Model spec (`provider/model`, e.g. `openai/gpt-4o-mini`). The judge model — small/cheap is recommended.                                                                   |
+| `prompt`  | yes              | Go [`text/template`](https://pkg.go.dev/text/template) body. Sees the hook [Input](#hook-input) as data, plus the `toJSON` and `truncate <n>` helpers.                    |
+| `schema`  | no               | Well-known response interpretation. `pre_tool_use_decision` produces a `permission_decision` verdict; omit for free-form text injected as `additional_context`.           |
+| `timeout` | no (default 60s) | Per-call timeout. **Timeouts fail closed (deny) for `pre_tool_use`** regardless of any other setting. Match it to your judge model's typical latency plus a small buffer. |
+
+The `pre_tool_use_decision` schema constrains the judge to reply with
+strict `{decision, reason}` JSON. Providers that honor structured
+output (OpenAI, ...) are asked to emit that shape directly; on
+providers that ignore it the framework still parses tolerant
+JSON-in-text. Anything unparseable propagates as a hook error and the
+executor falls closed (deny) on `pre_tool_use`.
+
+Pair it with deterministic `permissions:` rules so destructive calls
+(e.g. `sudo`, `rm -rf`) are blocked even if the judge is misled, and
+obvious read-only calls bypass the LLM entirely. See
+[`examples/llm_judge.yaml`](https://github.com/docker/docker-agent/blob/main/examples/llm_judge.yaml)
+for a complete configuration.
+
+**Security considerations**:
+
+- **Sensitive data**: Tool arguments (including file paths, command
+  arguments, and any other parameters) are sent to the judge LLM. Avoid
+  using the judge on tools that handle secrets, or ensure your judge
+  model is self-hosted.
+- **Defense in depth**: The judge should not be your only security
+  layer. Use deterministic `permissions:` rules to block obviously
+  dangerous operations (e.g., `sudo`, `rm -rf`) before the judge sees
+  them, as shown in the example configuration.
+
+## CLI Flags
+
+You can add hooks from the command line without modifying the agent's YAML file. This is useful for one-off debugging, audit logging, or layering hooks onto an existing agent.
+
+| Flag                   | Description                                      |
+| ---------------------- | ------------------------------------------------ |
+| `--hook-pre-tool-use`  | Run a command before every tool call             |
+| `--hook-post-tool-use` | Run a command after every tool call              |
+| `--hook-session-start` | Run a command when a session starts              |
+| `--hook-session-end`   | Run a command when a session ends                |
+| `--hook-on-user-input` | Run a command when waiting for input             |
+| `--hook-stop`          | Run a command when the model finishes responding |
+
+All flags are repeatable — pass multiple to register multiple hooks.
+
+```bash
+# Add a session-start hook
+$ docker agent run agent.yaml --hook-session-start "./scripts/setup-env.sh"
+
+# Combine multiple hooks
+$ docker agent run agent.yaml \
+  --hook-pre-tool-use "./scripts/validate.sh" \
+  --hook-post-tool-use "./scripts/log.sh"
+
+# Add hooks to an agent from a registry
+$ docker agent run myorg/coder \
+  --hook-pre-tool-use "./audit.sh"
+```
+
+> [!NOTE]
+> **Merging behavior**
+>
+> Agent-config, global, drop-in, and CLI hooks are additive. For each event, hooks run in this order: agent-config hooks first, then global hooks from `settings.hooks`, then [hook drop-ins](#hook-drop-in-files-hooksd) from `hooks.d/`, then CLI hooks. No source replaces another, and individual agents cannot opt out of global hooks.
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/models/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/models/index.md
new file mode 100644
index 000000000000..0626bd48ef43
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/models/index.md
@@ -0,0 +1,639 @@
+---
+title: "Model Configuration"
+description: "Complete reference for defining models with providers, parameters, and reasoning settings."
+keywords: docker agent, ai agents, configuration, yaml, model configuration
+linkTitle: "Model Config"
+weight: 40
+canonical: https://docs.docker.com/ai/docker-agent/configuration/models/
+---
+
+_Complete reference for defining models with providers, parameters, and reasoning settings._
+
+## Full Schema
+
+<!-- yaml-lint:skip -->
+```yaml
+models:
+  model_name:
+    first_available: [list] # Optional: candidate model refs, tried in order by available credentials.
+                            # Mutually exclusive with other model settings.
+    provider: string # Required unless using first_available. One of: openai, anthropic, google, amazon-bedrock,
+                     # dmr, mistral, xai, nebius, nvidia, minimax, baseten, ovhcloud, groq, fireworks, deepseek, cerebras, together, huggingface, moonshot, vercel, cloudflare-workers-ai, cloudflare-ai-gateway, requesty, openrouter,
+                     # azure, ollama, github-copilot, or a named provider defined
+                     # under the top-level `providers:` section.
+    model: string # Required: model identifier
+    description: string # Optional: human-readable summary of the model's purpose or strengths
+    temperature: float # Optional: 0.0–2.0 (provider-dependent; e.g. Anthropic caps at 1.0)
+    max_tokens: integer # Optional: response length limit
+    top_p: float # Optional: 0.0–1.0
+    frequency_penalty: float # Optional: -2.0–2.0
+    presence_penalty: float # Optional: -2.0–2.0
+    base_url: string # Optional: custom API endpoint
+    token_key: string # Optional: env var for API token
+    thinking_budget: string|int # Optional: reasoning effort
+    task_budget: int|object # Optional: total task token budget (Anthropic)
+    parallel_tool_calls: boolean # Optional: allow parallel tool calls
+    track_usage: boolean # Optional: track token usage
+    routing: [list] # Optional: rule-based model routing
+    capabilities: # Optional: override attachment capabilities
+      image: boolean # Optional: whether the model accepts image attachments
+      pdf: boolean # Optional: whether the model accepts PDF attachments
+    cost: # Optional: explicit token pricing (USD per 1M tokens)
+      input: float # Optional: price per 1M input tokens
+      output: float # Optional: price per 1M output tokens
+      cache_read: float # Optional: price per 1M cached input tokens
+      cache_write: float # Optional: price per 1M cache-write tokens
+    provider_opts: # Optional: provider-specific options
+      key: value
+    title_model: string # Optional: model used for session-title generation
+    compaction_model: string # Optional: model used for session-compaction (summary generation)
+    compaction_threshold: float # Optional: context-window fraction that triggers auto-compaction (0–1, default: 0.9)
+    bypass_models_gateway: boolean # Optional: skip the models gateway for this model (implied by a custom base_url)
+```
+
+## Properties Reference
+
+| Property              | Type       | Required | Description                                                                           |
+| --------------------- | ---------- | -------- | ------------------------------------------------------------------------------------- |
+| `first_available`     | array      | ✗        | Candidate model references tried in order; selects the first whose credentials are configured. Mutually exclusive with other model settings. |
+| `provider`            | string     | ✓/✗      | Required for regular model definitions; omitted for `first_available` selectors. Provider: `openai`, `anthropic`, `google`, `amazon-bedrock`, `dmr`, `mistral`, `xai`, `nebius`, `nvidia`, `minimax`, `baseten`, `ovhcloud`, `groq`, `fireworks`, `deepseek`, `cerebras`, `together`, `huggingface`, `moonshot`, `vercel`, `cloudflare-workers-ai`, `cloudflare-ai-gateway`, `requesty`, `openrouter`, `azure`, `ollama`, `github-copilot`, `chatgpt`, or any [named provider](../../providers/custom/index.md). |
+| `model`               | string     | ✓/✗      | Required for regular model definitions; omitted for `first_available` selectors. Model name (e.g., `gpt-4o`, `claude-sonnet-4-5`, `gemini-3.5-flash`) |
+| `description`         | string     | ✗        | Informational, human-readable summary of the model's purpose or strengths (e.g., "fast and cheap, good for summaries"). Not sent to the model. Can be combined with `first_available` (a selector's description is kept when it resolves). |
+| `temperature`         | float      | ✗        | Sampling randomness. Range is provider-dependent — typically `0.0–2.0` (Anthropic caps at `1.0`). `0.0` is deterministic. |
+| `max_tokens`          | int        | ✗        | Maximum response length in tokens                                                     |
+| `top_p`               | float      | ✗        | Nucleus sampling threshold (`0.0–1.0`)                                                |
+| `frequency_penalty`   | float      | ✗        | Penalize repeated tokens (`-2.0–2.0`)                                                 |
+| `presence_penalty`    | float      | ✗        | Encourage topic diversity (`-2.0–2.0`)                                                |
+| `base_url`            | string     | ✗        | Custom API endpoint URL (for self-hosted or proxied endpoints)                        |
+| `token_key`           | string     | ✗        | Environment variable name containing the API token (overrides provider default)       |
+| `thinking_budget`     | string/int | ✗        | Reasoning effort control                                                              |
+| `task_budget`         | int/object | ✗        | Total token budget for an agentic task (forwarded to Anthropic; see [Task Budget](#task-budget)). |
+| `parallel_tool_calls` | boolean    | ✗        | Allow model to call multiple tools at once                                            |
+| `track_usage`         | boolean    | ✗        | Track and report token usage for this model                                           |
+| `routing`             | array      | ✗        | Rule-based routing to different models. See [Model Routing](../routing/index.md). |
+| `capabilities`        | object     | ✗        | Override attachment capabilities for this model. See [Attachment Capability Overrides](#attachment-capability-overrides). |
+| `cost`                | object     | ✗        | Explicit token pricing in USD per 1M tokens, overriding the built-in catalogue. See [Custom Token Pricing](#custom-token-pricing). |
+| `provider_opts`       | object     | ✗        | Provider-specific options (see provider pages)                                        |
+| `title_model`         | string     | ✗        | Model used for session-title generation. Can be a named model from the `models:` section or an inline `provider/model` string. When omitted, the agent's primary model generates titles. Cannot be combined with `first_available`. |
+| `compaction_model`    | string     | ✗        | Model used for session compaction (summary generation). Can be a named model or an inline `provider/model` string. The agent-level `compaction_model` takes precedence over this value, which in turn takes precedence over a provider-level default. When none is set, the primary model compacts. Cannot be combined with `first_available`. See the [Context & Compaction guide](../../guides/compaction/index.md). |
+| `compaction_threshold` | float     | ✗        | Fraction of the context window at which proactive auto-compaction triggers for agents running this model. Must be greater than `0` and at most `1`. Takes precedence over the agent-level `compaction_threshold`. Cannot be combined with `first_available`. Default: `0.9`. See the [Context & Compaction guide](../../guides/compaction/index.md). |
+| `bypass_models_gateway` | boolean  | ✗        | When `true`, this model connects directly to its provider even when a models gateway (`--models-gateway` / `DOCKER_AGENT_MODELS_GATEWAY`) is configured. Implied by a custom `base_url`. See [Gateway Bypass](#gateway-bypass). |
+
+## Attachment Capability Overrides
+
+For custom OpenAI-compatible providers, local models (Ollama, DMR), and any
+model the built-in catalogue does not describe, Docker Agent cannot
+auto-detect whether the endpoint accepts image or PDF attachments. When the
+model is absent from the catalogue, Docker Agent logs a diagnostic and falls
+back to text-only, silently dropping attachments.
+
+Declare `capabilities` to make the model's attachment support authoritative
+and skip the catalogue lookup entirely:
+
+```yaml
+models:
+  llava-local:
+    provider: ollama
+    model: llava
+    capabilities:
+      image: true   # accepts image attachments
+      pdf: false    # does not accept PDFs
+
+  proxy-vision:
+    provider: vision-proxy
+    model: gpt-4o
+    capabilities:
+      image: true
+      pdf: true
+```
+
+| Field                  | Type    | Description                                       |
+| ---------------------- | ------- | ------------------------------------------------- |
+| `capabilities.image`   | boolean | Whether the model accepts image attachments       |
+| `capabilities.pdf`     | boolean | Whether the model accepts PDF attachments         |
+
+The flags must match what the endpoint actually accepts. Claiming a modality
+that the endpoint does not support leads to a provider-side API error. When
+`capabilities` is omitted the behaviour is unchanged (catalogue lookup then
+conservative text-only fallback).
+
+See [`examples/capability-overrides.yaml`](https://github.com/docker/docker-agent/blob/main/examples/capability-overrides.yaml) for a complete example.
+
+## Custom Token Pricing
+
+Docker Agent prices each model call from the [models.dev](https://models.dev/)
+catalogue. Models the catalogue does not know — custom OpenAI-compatible
+providers, local models, private deployments — are "unpriced": every call is
+recorded at $0 despite consuming tokens, with only a log warning.
+
+Declare `cost` to price a model explicitly, in **USD per one million tokens**.
+When set, it takes precedence over the catalogue and makes an uncatalogued
+model priced:
+
+```yaml
+models:
+  internal-gpt:
+    provider: internal-llm
+    model: gpt-4o
+    cost:
+      input: 1.25 # USD per 1M input tokens
+      output: 5.00 # USD per 1M output tokens
+      cache_read: 0.125 # USD per 1M cached input tokens
+      cache_write: 1.5625 # USD per 1M cache-write tokens
+
+  # Also works for catalogued models, e.g. a negotiated enterprise discount:
+  discounted-sonnet:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    cost:
+      input: 2.4
+      output: 12.0
+```
+
+| Field              | Type  | Description                             |
+| ------------------ | ----- | --------------------------------------- |
+| `cost.input`       | float | USD price per 1M input tokens           |
+| `cost.output`      | float | USD price per 1M output tokens          |
+| `cost.cache_read`  | float | USD price per 1M cached input tokens    |
+| `cost.cache_write` | float | USD price per 1M cache-write tokens     |
+
+The declared prices feed per-turn cost computation, session cost tracking, the
+`/model` picker, and the [`after_llm_call` hook](../hooks/index.md)'s `cost`
+field. Prices must not be negative; omitted fields default to `0`. An all-zero
+table means "priced, free" — distinct from omitting `cost` entirely
+(unpriced). Cannot be combined with `first_available` (set it on the candidate
+models instead).
+
+See [`examples/custom-pricing.yaml`](https://github.com/docker/docker-agent/blob/main/examples/custom-pricing.yaml) for a complete example.
+
+## Delegating Session-Title Generation
+
+The `title_model` field lets a heavyweight primary model hand off the cheap
+title-generation call to a smaller, faster model:
+
+```yaml
+model: anthropic/claude-opus-4-7
+title_model: anthropic/claude-haiku-4-5
+```
+
+The value can be a named entry from the `models` stanza or an inline
+`provider/model` string. When omitted, the agent's primary model generates
+titles.
+
+> [!WARNING]
+> **Constraint**
+>
+> `title_model` cannot be combined with `first_available` model selection — the combination is rejected at validation time.
+
+## Delegating Session Compaction
+
+> [!TIP]
+> **Full guide**
+>
+> For a task-oriented walkthrough of automatic vs. on-demand compaction, trimming tool results, and reading the context gauge, see [Managing Context & Compaction](../../guides/compaction/index.md). This section covers the `compaction_model` and `compaction_threshold` fields themselves.
+
+The `compaction_model` field lets a heavyweight primary model hand off the expensive
+compaction (summary generation) call to a smaller, faster model:
+
+```yaml
+models:
+  primary:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    compaction_model: fast
+  fast:
+    provider: anthropic
+    model: claude-haiku-4-5
+```
+
+The value can be a named entry from the `models` stanza or an inline
+`provider/model` string. Resolution priority: an agent-level `compaction_model`
+wins, then the model-level value, then a provider-level default set in the
+`providers` section; when none is set, the primary model compacts. For an
+agent listing several models (`model: a,b`), the first listed model that sets
+a value (or whose provider sets a default) wins at that level.
+
+```yaml
+providers:
+  my_anthropic:
+    provider: anthropic
+    # Default for every agent whose model uses this provider.
+    compaction_model: anthropic/claude-haiku-4-5
+```
+
+If the compaction model has a **smaller context window** than the primary,
+Docker Agent triggers compaction against the smaller window so the summary
+call can always ingest the full conversation. Pair the primary with a
+compaction model whose window is at least as large to keep the proactive
+trigger aligned with the primary's window.
+
+By default the proactive trigger fires when the estimated token usage crosses
+**90%** of the context window. The `compaction_threshold` field tunes that
+fraction (greater than `0`, at most `1`): lower values compact earlier and
+keep requests smaller, higher values compact later and keep more verbatim
+history. It can be set on the model (as above, taking precedence) or on the
+agent, and automatic compaction can be disabled entirely per agent with
+`session_compaction: false` — see [Agent Config](../agents/index.md#properties-reference).
+
+```yaml
+models:
+  primary:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    compaction_model: fast
+    # Compact at 80% of the window instead of the default 90%.
+    compaction_threshold: 0.8
+```
+
+> [!WARNING]
+> **Constraint**
+>
+> `compaction_model` cannot be combined with `first_available` model selection — the combination is rejected at validation time.
+
+See [`examples/compaction_model.yaml`](https://github.com/docker/docker-agent/blob/main/examples/compaction_model.yaml)
+and [`examples/compaction_threshold.yaml`](https://github.com/docker/docker-agent/blob/main/examples/compaction_threshold.yaml)
+for complete examples.
+
+## Gateway Bypass
+
+When a models gateway (`--models-gateway` / `DOCKER_AGENT_MODELS_GATEWAY`) is configured,
+models without a custom `base_url` route through it by default. Set
+`bypass_models_gateway: true` on a specific model to make it connect directly
+to its provider instead:
+
+```yaml
+models:
+  gateway-model:
+    provider: openai
+    model: gpt-5
+
+  direct-model:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    bypass_models_gateway: true  # uses ANTHROPIC_API_KEY directly
+```
+
+The bypassed model authenticates with the provider's own credentials
+(`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `token_key`, etc.) rather than the
+gateway's short-lived token. The rest of the agent's models continue routing
+through the gateway as before.
+
+Bypass is propagated transparently through router models: a bypass-flagged routing
+model passes the flag to all of its routed targets automatically.
+
+> [!WARNING]
+> **Security note**
+>
+> On an untrusted config, a malicious `base_url` combined with `bypass_models_gateway: true` could route provider credentials to an attacker-controlled endpoint. Only enable this on configs you control.
+
+> [!WARNING]
+> **Constraint**
+>
+> `bypass_models_gateway: true` cannot be combined with `first_available` — the combination is rejected at validation time.
+
+See [`examples/bypass_models_gateway.yaml`](https://github.com/docker/docker-agent/blob/main/examples/bypass_models_gateway.yaml) for a complete example.
+
+## First Available Models
+
+Use `first_available` when the same agent should work with whichever provider credentials are available in the current environment. Docker Agent checks the candidates in order at load time and replaces the selector with the first candidate whose required environment variables are configured.
+
+```yaml
+models:
+  smart:
+    first_available:
+      - anthropic/claude-sonnet-4-6
+      - openai/gpt-5
+      - google/gemini-3.5-flash
+      - dmr/ai/qwen3 # local fallback; no API key required
+
+agents:
+  root:
+    model: smart
+    instruction: You are a helpful assistant.
+```
+
+Candidates can be inline `provider/model` references or names from the same `models:` section. Local providers such as `dmr` and `ollama` do not require credentials, so they are useful as final fallbacks.
+
+If none of the candidates has credentials configured, Docker Agent reports the missing environment variables grouped by candidate. You only need to configure one group of credentials, not every provider in the list.
+
+A `first_available` model is only a selector. Except for the informational `description`, it cannot be combined with `provider`, `model`, `routing`, `token_key`, budgets, sampling options, or other model settings. Put those settings on named candidate models instead:
+
+```yaml
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-6
+    max_tokens: 64000
+
+  gpt:
+    provider: openai
+    model: gpt-5
+    thinking_budget: low
+
+  smart:
+    first_available:
+      - claude
+      - gpt
+      - dmr/ai/qwen3
+```
+
+See [`examples/first_available.yaml`](https://github.com/docker/docker-agent/blob/main/examples/first_available.yaml) for a complete example.
+
+## Thinking Budget
+
+Control how much reasoning the model does before responding. This varies by provider:
+
+### OpenAI
+
+Uses effort levels as strings:
+
+```yaml
+models:
+  gpt:
+    provider: openai
+    model: gpt-5.6
+    thinking_budget: low # none | minimal | low | medium | high | xhigh | max (xhigh needs gpt-5.2+; none/max need gpt-5.6+; minimal dropped on gpt-5.6+)
+```
+
+### Anthropic
+
+Uses an integer token budget (1024–32768), or — on adaptive-capable models (Opus 4.6+) — `adaptive`, `adaptive/<effort>`, or a bare effort level:
+
+```yaml
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    thinking_budget: 16384 # must be < max_tokens
+
+  opus:
+    provider: anthropic
+    model: claude-opus-4-6
+    thinking_budget: adaptive # or adaptive/<effort>, or low | medium | high | xhigh | max
+```
+
+### Google Gemini 2.5
+
+Uses an integer token budget. `0` disables, `-1` lets the model decide:
+
+```yaml
+models:
+  gemini:
+    provider: google
+    model: gemini-2.5-flash
+    thinking_budget: -1 # dynamic (default)
+```
+
+### Google Gemini 3
+
+Uses effort levels like OpenAI:
+
+```yaml
+models:
+  gemini3:
+    provider: google
+    model: gemini-3-flash
+    thinking_budget: medium # minimal | low | medium | high
+```
+
+### Disabling Thinking
+
+```yaml
+thinking_budget: none # or 0
+```
+
+`none` and `0` both clear Docker Agent's local thinking configuration (omitting `thinking_budget` has the same effect); neither is guaranteed to reach the API as a real "off" switch:
+
+- **OpenAI gpt-5.6+** (Sol/Terra/Luna) is the only case with a genuine API-level `none` reasoning effort: Docker Agent sends it as-is and the model does not reason.
+- **Older OpenAI reasoning models** (o-series, gpt-5 through gpt-5.5) have no such switch: `none`/`0` just clear the local config, and the model falls back to the API's own default effort and still reasons internally. Same for other always-reasoning models (Gemini 3).
+- Providers with a true optional-thinking switch (Gemini 2.5, Claude, local models) are fully disabled by `none`/`0`.
+
+```yaml
+models:
+  fast-responder:
+    provider: openai
+    model: gpt-5.6
+    thinking_budget: none # real API-level disable on gpt-5.6+
+```
+
+See the [Thinking / Reasoning guide](../../guides/thinking/index.md) for per-provider details, including AWS Bedrock and Docker Model Runner.
+
+## Task Budget
+
+**Anthropic-only.**
+
+`task_budget` caps the **total** number of tokens the model may spend across a
+multi-step agentic task — combining thinking, tool calls, and final output
+tokens. It lets long-running agents self-regulate effort without having to
+choose a tight per-call `max_tokens`.
+
+It is forwarded to Anthropic's
+[`output_config.task_budget`](https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7)
+request field. Docker Agent automatically attaches the required
+`task-budgets-2026-03-13` beta header whenever this field is set.
+
+You can configure `task_budget` on **any** Claude model — Docker Agent never
+gates it by model name. At the time of writing only **Claude Opus 4.7**
+actually honors the field; other Claude models will reject requests that
+include it. Check the Anthropic release notes linked above for the current
+list of supported models.
+
+### Integer shorthand
+
+```yaml
+models:
+  opus:
+    provider: anthropic
+    model: claude-opus-4-7
+    task_budget: 128000 # total tokens for the whole task
+    thinking_budget: adaptive # works nicely together
+```
+
+### Object form
+
+Equivalent, and forward-compatible with future budget types:
+
+```yaml
+models:
+  opus:
+    provider: anthropic
+    model: claude-opus-4-7
+    task_budget:
+      type: tokens # only "tokens" is supported today
+      total: 128000
+```
+
+Setting `task_budget: 0` (or omitting the field) disables the feature — the
+model falls back to the provider's default behavior.
+
+Like other inheritable model settings, `task_budget` can also be declared on a
+[provider definition](../../providers/custom/index.md) and is
+inherited by every model that references that provider.
+
+See [`examples/task_budget.yaml`](https://github.com/docker/docker-agent/blob/main/examples/task_budget.yaml) for a complete example.
+
+## Interleaved Thinking
+
+For Anthropic and Bedrock Claude models, interleaved thinking allows tool calls during model reasoning. It is auto-enabled whenever a thinking budget is configured:
+
+```yaml
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    thinking_budget: 8192
+    # interleaved_thinking is auto-enabled when thinking_budget is set
+    provider_opts:
+      interleaved_thinking: false # disable if needed
+```
+
+## Thinking Display (Anthropic)
+
+For Anthropic Claude models, `thinking_display` controls whether thinking blocks are returned in responses when thinking is enabled. Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default (`omitted`); Docker Agent requests `summarized` thinking by default for adaptive/effort-based budgets so reasoning stays visible. Set this provider option to override:
+
+```yaml
+models:
+  opus-4-7:
+    provider: anthropic
+    model: claude-opus-4-7
+    thinking_budget: adaptive
+    provider_opts:
+      thinking_display: omitted # "summarized" or "omitted" ("display" on pre-4.6 models only)
+```
+
+`display` (full thinking blocks) is only accepted by pre-4.6 token-thinking models (e.g. Sonnet 4.5, Haiku 4.5); newer models (Opus/Sonnet 4.6+, Sonnet 5, Fable 5) only accept `summarized` and `omitted`, and Docker Agent rejects the configuration at startup.
+
+See the [Anthropic provider page](../../providers/anthropic/index.md#thinking-display) for details.
+
+## Custom HTTP Headers
+
+For OpenAI-compatible providers (`openai`, `github-copilot`, `mistral`, `xai`,
+`nebius`, `nvidia`, `minimax`, `baseten`, `ovhcloud`, `groq`, `fireworks`, `deepseek`, `cerebras`, `together`, `huggingface`, `moonshot`, `vercel`, `cloudflare-workers-ai`, `cloudflare-ai-gateway`, `requesty`, `openrouter`, `ollama`, and any custom provider using the OpenAI API),
+`provider_opts.http_headers` adds arbitrary HTTP headers to every outgoing
+request:
+
+```yaml
+models:
+  my_model:
+    provider: openai
+    model: gpt-4o
+    provider_opts:
+      http_headers:
+        X-Request-Source: docker-agent
+        X-Tenant-Id: my-team
+```
+
+Header names are matched case-insensitively. The `github-copilot` provider
+automatically sets `Copilot-Integration-Id: copilot-developer-cli` — see the
+[GitHub Copilot provider page](../../providers/github-copilot/index.md)
+for details.
+
+## Examples by Provider
+
+```yaml
+models:
+  # OpenAI
+  gpt:
+    provider: openai
+    model: gpt-5
+
+  # Anthropic
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    max_tokens: 64000
+
+  # Google Gemini
+  gemini:
+    provider: google
+    model: gemini-3.5-flash
+    temperature: 0.5
+
+  # AWS Bedrock
+  bedrock:
+    provider: amazon-bedrock
+    model: global.anthropic.claude-sonnet-4-5-20250929-v1:0
+    provider_opts:
+      region: us-east-1
+
+  # OpenRouter
+  openrouter:
+    provider: openrouter
+    model: meta-llama/llama-3.3-70b-instruct
+
+  # Docker Model Runner (local)
+  local:
+    provider: dmr
+    model: ai/qwen3
+    max_tokens: 8192
+```
+
+For detailed provider setup, see the [Model Providers](../../providers/overview/index.md) section.
+
+## Custom Endpoints
+
+Use `base_url` to point to custom or self-hosted endpoints:
+
+```yaml
+models:
+  # Azure OpenAI
+  azure_gpt:
+    provider: openai
+    model: gpt-4o
+    base_url: https://my-resource.openai.azure.com/openai/deployments/gpt-4o
+    token_key: AZURE_OPENAI_API_KEY
+
+  # Self-hosted vLLM
+  local_llama:
+    provider: openai # vLLM is OpenAI-compatible
+    model: meta-llama/Llama-3.2-3B-Instruct
+    base_url: http://localhost:8000/v1
+
+  # Proxy or gateway
+  proxied:
+    provider: openai
+    model: gpt-4o
+    base_url: https://proxy.internal.company.com/openai/v1
+    token_key: INTERNAL_API_KEY
+```
+
+The `model` and `base_url` fields accept `${env.VAR}` (or `${VAR}`) references, which are substituted from the environment when the model is loaded. This keeps the model id or endpoint out of the config when it is supplied by the environment, e.g. a Docker Compose / DMR setup:
+
+```yaml
+models:
+  nemotron3:
+    provider: dmr
+    model: "${env.NEMOTRON3_MODEL}"
+    base_url: "${env.DMR_BASE_URL}"
+```
+
+See [Variable Expansion in Config Fields](../overview/index.md#variable-expansion-in-config-fields) for the full set of fields and supported syntaxes.
+
+See [Local Models](../../providers/local/index.md) for more examples of custom endpoints.
+
+## Inheriting from Provider Definitions
+
+Models can reference a named provider to inherit shared defaults. Model-level settings always take precedence:
+
+```yaml
+providers:
+  my_anthropic:
+    provider: anthropic
+    token_key: MY_ANTHROPIC_KEY
+    max_tokens: 16384
+    thinking_budget: 8192
+    temperature: 0.5
+
+models:
+  claude:
+    provider: my_anthropic
+    model: claude-sonnet-4-5
+    # Inherits max_tokens, thinking_budget, temperature from provider
+
+  claude_fast:
+    provider: my_anthropic
+    model: claude-haiku-4-5
+    thinking_budget: 1024  # Overrides provider default
+```
+
+See [Provider Definitions](../../providers/custom/index.md) for the full list of inheritable properties.
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/overview/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/overview/index.md
new file mode 100644
index 000000000000..705a698cf4af
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/overview/index.md
@@ -0,0 +1,537 @@
+---
+title: "Configuration Overview"
+description: "Docker Agent uses YAML or HCL configuration files to define agents, models, tools, and their relationships."
+keywords: docker agent, ai agents, configuration, yaml, configuration overview
+linkTitle: "Overview"
+weight: 10
+canonical: https://docs.docker.com/ai/docker-agent/configuration/overview/
+aliases:
+  - /ai/docker-agent/reference/config/
+---
+
+_Docker Agent uses YAML or HCL configuration files to define agents, models, tools, and their relationships._
+
+## File Structure
+
+A Docker Agent config can be written in YAML or HCL. The examples on this page use YAML; see [HCL Configuration](../hcl/index.md) for the block-based HCL syntax.
+
+A Docker Agent config has these main sections:
+
+```bash
+# 1. Version — configuration schema version (optional but recommended)
+version: 15
+
+# 2. Metadata — optional agent metadata for distribution
+metadata:
+  author: my-org
+  description: My helpful agent
+  version: "1.0.0"
+
+# 3. Models — define AI models with their parameters
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    max_tokens: 64000
+
+# 4. Agents — define AI agents with their behavior (at least one is required)
+agents:
+  root:
+    model: claude
+    description: A helpful assistant
+    instruction: You are helpful.
+    toolsets:
+      - type: think
+
+# 5. RAG — define retrieval-augmented generation sources (optional)
+rag:
+  docs:
+    docs: ["./docs"]
+    strategies:
+      - type: chunked-embeddings
+        embedding_model: openai/text-embedding-3-small
+
+# 6. MCPs — reusable MCP server definitions (optional)
+mcps:
+  github:
+    remote:
+      url: https://api.githubcopilot.com/mcp
+      transport_type: sse
+
+# 7. Providers — optional reusable provider definitions
+providers:
+  my_provider:
+    provider: anthropic  # or openai (default), google, amazon-bedrock, etc.
+    token_key: MY_API_KEY
+    max_tokens: 16384
+
+# 8. Permissions — agent-level tool permission rules (optional)
+#    For user-wide global permissions, see ~/.config/cagent/config.yaml
+permissions:
+  allow: ["read_*"]
+  deny: ["shell:cmd=sudo*"]
+
+# 9. Commands & Skills — reusable, named groups shared across agents (optional)
+commands:
+  ci:
+    deploy: "Deploy the application"
+skills:
+  base: [local, git]
+
+# 10. Toolsets — reusable, named toolset definitions shared across agents (optional)
+toolsets:
+  fs:
+    type: filesystem
+```
+
+## Minimal Config
+
+The simplest possible configuration — a single agent with an inline model:
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5
+    description: A helpful assistant
+    instruction: You are a helpful assistant.
+```
+
+The same config in HCL:
+
+```hcl
+agent "root" {
+  model       = "openai/gpt-5"
+  description = "A helpful assistant"
+  instruction = "You are a helpful assistant."
+}
+```
+
+## Inline vs Named Models
+
+Models can be referenced inline or defined in the `models` section:
+
+- **Inline** — quick and simple. Use `provider/model` syntax directly: `model: openai/gpt-5`
+- **Named** — full control over parameters, reusable across agents: `model: my_claude`
+
+## Config Sections
+
+- [**HCL Configuration**](../hcl/index.md) — write the same agent schema in HCL using labeled blocks, heredocs, and block-based tool definitions.
+- [**Agent Config**](../agents/index.md) — all agent properties: model, instruction, tools, sub-agents, hooks, and more.
+- [**Model Config**](../models/index.md) — provider setup, parameters, thinking budget, and provider-specific options.
+- [**Tool Config**](../tools/index.md) — built-in tools, MCP tools, Docker MCP, LSP, API tools, and tool filtering.
+
+## Advanced Configuration
+
+- [**Hooks**](../hooks/index.md) — run shell commands at lifecycle events like tool calls and session start/end.
+- [**Permissions**](../permissions/index.md) — control which tools auto-approve, require confirmation, or are blocked.
+- [**Sandbox Mode**](../sandbox/index.md) — run agents in an isolated Docker container for security.
+- [**Structured Output**](../structured-output/index.md) — constrain agent responses to match a specific JSON schema.
+- [**Flavors**](../flavors/index.md) — ship one agent file with named variants, enabled at run time as YAML patches.
+
+## Environment Variables
+
+API keys and secrets are read from environment variables — never stored in config files. See [Managing Secrets](../../guides/secrets/index.md) for all the ways to provide credentials (env files, Docker Compose secrets, the Docker Agent env file):
+
+| Variable                   | Provider                                            |
+| -------------------------- | --------------------------------------------------- |
+| `OPENAI_API_KEY`           | OpenAI                                              |
+| `ANTHROPIC_API_KEY`        | Anthropic                                           |
+| `GOOGLE_API_KEY` / `GEMINI_API_KEY` | Google Gemini                              |
+| `MISTRAL_API_KEY`          | Mistral                                             |
+| `XAI_API_KEY`              | xAI                                                 |
+| `NEBIUS_API_KEY`           | Nebius                                              |
+| `MINIMAX_API_KEY`          | MiniMax                                             |
+| `REQUESTY_API_KEY`         | Requesty                                            |
+| `OPENROUTER_API_KEY`       | OpenRouter                                          |
+| `GITHUB_TOKEN`             | GitHub Copilot (PAT with `copilot` scope)           |
+| `AZURE_API_KEY`            | Azure OpenAI (override with `token_key`)            |
+| `AWS_BEARER_TOKEN_BEDROCK` | AWS Bedrock (or the standard AWS credentials chain) |
+
+**Tool Auto-Installation:**
+
+| Variable              | Description                                                     |
+| --------------------- | --------------------------------------------------------------- |
+| `DOCKER_AGENT_AUTO_INSTALL` | Set to `false` to disable automatic tool installation           |
+| `DOCKER_AGENT_TOOLS_DIR`    | Override the base directory for installed tools (default: `~/.cagent/tools/`) |
+
+**Runtime overrides:**
+
+| Variable                            | Description                                                                                          |
+| ----------------------------------- | ---------------------------------------------------------------------------------------------------- |
+| `DOCKER_AGENT_DEFAULT_MODEL`        | Default model used when none is specified, in `provider/model` form (e.g. `openai/gpt-5`).      |
+| `DOCKER_AGENT_MODELS_GATEWAY`       | Route model traffic through a gateway. Equivalent to the `--models-gateway` flag.                    |
+| `DOCKER_AGENT_HIDE_TELEMETRY_BANNER`| Set to `1` to suppress the first-run telemetry notice.                                               |
+| `DOCKER_AGENT_AUTO_UPDATE`          | Set to a truthy value (`1`, `true`, `yes`, `on`) to let standalone release binaries self-update before running. See [Optional Self-Updates](../../getting-started/installation/index.md#optional-self-updates). |
+| `DOCKER_AGENT_NO_TOKEN_EXCHANGE`    | Set to `1` to stop Docker Agent from exchanging the access token stored by `docker login` for a Docker token. See [Docker authentication](../../guides/secrets/index.md#docker-authentication). |
+| `DOCKER_AGENT_HUB_LOGIN_URL`        | Point the token exchange at a Docker staging environment. Ignored unless it is an HTTPS `docker.com` URL. |
+
+> [!NOTE]
+> **Legacy `CAGENT_*` aliases**
+>
+> The same variables are also accepted with the legacy `CAGENT_` prefix (e.g. `CAGENT_DEFAULT_MODEL`, `CAGENT_MODELS_GATEWAY`, `CAGENT_HIDE_TELEMETRY_BANNER`) for backward compatibility. Prefer the `DOCKER_AGENT_*` form in new setups.
+
+> [!IMPORTANT]
+> Model references are case-sensitive: `openai/gpt-5` is not the same as `openai/GPT-5`.
+
+## Variable Expansion in Config Fields
+
+Docker Agent expands `${env.VAR}` references in many config fields. This is the **canonical syntax everywhere** — prefer it for every field. Two engines back it: a full JavaScript evaluator for prompt/HTTP fields (where you also get defaults, ternaries, and tool calls), and a simpler path expander for filesystem/env fields (which additionally accepts the legacy `$VAR` / `${VAR}` / `~` shell forms). Picking `${env.VAR}` everywhere always works; the one caveat is that the path expander does not evaluate richer JS expressions. Using a shell-style `$VAR` in a JS-templated field is currently a silent no-op, so the literal string is passed through. Tracking issue: [#2615](https://github.com/docker/docker-agent/issues/2615).
+
+### JavaScript template literals — `${env.VAR}`
+
+Used wherever the agent prompt or HTTP traffic is templated. Backed by a JS evaluator, so you also get `||` defaults, ternaries, and tool calls (`${tool({...})}`).
+
+Applies to:
+
+- `agents.<name>.description`
+- `agents.<name>.welcome_message`
+- `agents.<name>.instruction`
+- `agents.<name>.commands.*` (string form and `instruction:` field)
+- `toolsets[*].instruction`
+- `toolsets[*].headers` and `toolsets[*].remote.headers` (MCP, A2A, OpenAPI, fetch, API)
+
+For `api` toolsets, `api_config.endpoint` and `api_config.headers` are also rendered through the JS expander (the same syntax applies).
+
+```yaml
+agents:
+  root:
+    description: "Assistant for ${env.USER || 'guest'}"
+    commands:
+      deploy: "Deploy ${env.PROJECT_NAME || 'app'} to ${env.ENV || 'staging'}"
+    toolsets:
+      - type: openapi
+        url: https://api.example.com
+        headers:
+          Authorization: "Bearer ${env.INTERNAL_TOKEN}"
+```
+
+Undefined variables expand to the empty string.
+
+### Path & env fields — `${env.VAR}` (canonical), `$VAR` / `${VAR}` / `~` (aliases)
+
+Used for filesystem paths and process environment values. Backed by `os.ExpandEnv` plus tilde expansion against the current user's home directory. The canonical `${env.VAR}` form is accepted here too, so a single syntax works across every field; the bare `$VAR` / `${VAR}` shell forms remain supported as aliases.
+
+Applies to:
+
+- `agents.<name>.toolsets[*].working_dir` (MCP, LSP)
+- `agents.<name>.toolsets[*].path` (memory, tasks)
+- `agents.<name>.toolsets[*].env` values (MCP, shell, script, LSP)
+- `agents.<name>.toolsets[*].shell.<tool>.working_dir` (script tools)
+- `agents.<name>.hooks.*.working_dir`
+- The `~` prefix is also accepted in any path-like field documented as such.
+
+```yaml
+agents:
+  root:
+    toolsets:
+      - type: memory
+        path: "~/notes/${env.PROJECT}/memory.db"
+      - type: mcp
+        command: my-server
+        working_dir: "${env.HOME}/work"
+```
+
+Unlike the JS-templated fields above, these accept only a plain variable reference: richer JS expressions (e.g. `${env.VAR || 'default'}`) are **not** evaluated here, and the legacy `$VAR` / `${VAR}` forms keep working for backward compatibility.
+
+Hook and script-tool `env` values expand only the plain `${env.VAR}` form, resolved against the **OS process environment** (dotenv/secret-provider values are not consulted); a bare `$VAR` or `${VAR}` is passed through **literally**, so values that legitimately contain `$` (passwords, templates) are never mangled:
+
+```yaml
+agents:
+  root:
+    hooks:
+      session_start:
+        - type: command
+          command: ./notify.sh
+          working_dir: "~/scripts"                # ~, $VAR, ${VAR}, ${env.VAR} all work
+          env:
+            API_TOKEN: "${env.NOTIFY_TOKEN}"      # expanded
+            PASSWORD: "pa$$word"                  # kept literal
+```
+
+Model definitions follow the same rule. The `models.<name>.model` and `models.<name>.base_url` fields are expanded when the provider is built, accepting both `${env.VAR}` and `${VAR}`. This is useful when the model id or endpoint is injected by the environment (for example a Docker Compose / DMR setup that exports the model reference as a variable):
+
+```yaml
+models:
+  nemotron3:
+    provider: dmr
+    model: "${env.NEMOTRON3_MODEL}" # resolved from the environment at load time
+    base_url: "${DMR_BASE_URL}"     # ${VAR} is accepted as well
+```
+
+`token_key` is **not** expanded: it already names the environment variable that holds the API token, so its value is used as a key rather than substituted. An unset variable in `model` or `base_url` is reported as an error instead of dialing with an empty value.
+
+### Quick reference
+
+| Field                                         | `${env.X}` | `$X` / `${X}` | `~` |
+| --------------------------------------------- | :--------: | :-----------: | :-: |
+| `description`, `welcome_message`              |     ✓      |       ✗       |  ✗  |
+| `instruction` (agent and toolset)             |     ✓      |       ✗       |  ✗  |
+| `commands.*`                                  |     ✓      |       ✗       |  ✗  |
+| `headers`, `remote.headers`, `api_config.headers` |     ✓      |       ✗       |  ✗  |
+| `models.*.model`, `models.*.base_url`         |     ✓      |       ✓       |  ✗  |
+| `working_dir`, `path` (toolset, script tool, hook) |     ✓      |       ✓       |  ✓  |
+| `env` values (toolset)                        |     ✓      |       ✓       |  ✗  |
+| `env` values (hook, script tool)              |     ✓      |   literal     |  ✗  |
+
+The `~` prefix is meaningful only in path-like fields (`working_dir`, `path`). In hook and script-tool `env` values, "literal" means a bare `$X` / `${X}` is passed to the process unchanged — only `${env.X}` is substituted there, so values containing `$` survive intact.
+
+Prefer `${env.X}` everywhere. The bare `$X` / `${X}` and `~` forms are accepted only in path and `env` value fields, where they remain supported for backward compatibility.
+
+## Validation
+
+Docker Agent validates your configuration at startup:
+
+- Local `sub_agents` must reference agents defined in the config (external OCI references like `myorg/agent:tag` are pulled from registries automatically; pin them to a digest with `@sha256:…` to avoid a per-run registry lookup)
+- Named model references must exist in the `models` section
+- Provider names must be valid (`openai`, `anthropic`, `google`, `dmr`, etc.)
+- Required environment variables (API keys) must be set
+- Tool-specific fields are validated (e.g., `path` is only valid for `memory`)
+
+## JSON Schema
+
+For YAML editor autocompletion and validation, use the [Docker Agent JSON Schema](https://github.com/docker/docker-agent/blob/main/agent-schema.json). Add this to the top of your YAML file:
+
+```bash
+# yaml-language-server: $schema=https://raw.githubusercontent.com/docker/docker-agent/main/agent-schema.json
+```
+
+## Config Versioning
+
+Docker Agent configs are versioned. The current version is `15`. Add the version at the top of your config:
+
+```yaml
+version: 15
+
+agents:
+  root:
+    model: openai/gpt-5
+    # ...
+```
+
+When you load an older config, Docker Agent automatically migrates it to the latest schema. It's recommended to include the version to ensure consistent behavior.
+
+If you use a config key that requires a newer schema version, Docker Agent will fail with a strict-parse error and include a hint like:
+
+```text
+hint: this key is supported by config version 12; update the top-level 'version' field (currently 11)
+```
+
+Bump the `version` field as directed to enable the new key.
+
+## Metadata Section
+
+Optional metadata for agent distribution via OCI registries:
+
+```yaml
+metadata:
+  author: my-org
+  license: Apache-2.0
+  description: A helpful coding assistant
+  readme: | # Displayed in registries
+    This agent helps with coding tasks.
+  version: "1.0.0"
+  tags: [coding, review]
+```
+
+| Field         | Description                                |
+| ------------- | ------------------------------------------ |
+| `author`      | Author or organization name                |
+| `license`     | License identifier (e.g., Apache-2.0, MIT) |
+| `description` | Short description for the agent            |
+| `readme`      | Longer markdown description                |
+| `version`     | Semantic version string                    |
+| `tags`        | Tags for categorization and discovery      |
+
+See [Agent Distribution](../../concepts/distribution/index.md) for publishing agents to registries.
+
+## Reusable MCP Servers (`mcps:`)
+
+The top-level `mcps:` section defines named MCP server configurations that agents can reference with `toolsets: [{type: mcp, ref: <name>}]`. This avoids repeating the same command / URL / headers across agents and keeps credentials in one place.
+
+```yaml
+mcps:
+  github:
+    remote:
+      url: https://api.githubcopilot.com/mcp
+      transport_type: sse
+  playwright:
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-playwright"]
+
+agents:
+  root:
+    model: openai/gpt-5
+    toolsets:
+      - type: mcp
+        ref: github        # reuse the definition above
+      - type: mcp
+        ref: playwright
+```
+
+An `mcps` entry accepts every field a regular `type: mcp` toolset accepts (command/args/env, `remote` with `url`/`transport_type`/`headers`/`oauth`, `tools` filter, `instruction`, `defer`, …) — the `type: mcp` is implicit. See the [Tool Config](../tools/index.md) page for all options and the [Remote MCP Servers](../../features/remote-mcp/index.md) guide for remote setups.
+
+## Reusable Toolsets (`toolsets:`)
+
+The top-level `toolsets:` map defines named toolset configurations that agents can reference by name through `use_toolsets:`. This avoids repeating the same toolset definition across multiple agents — the same pattern as `mcps:` for MCP servers and `commands:` / `skills:` for reusable prompt groups.
+
+Any toolset type is supported, including ones that reference MCP or RAG definitions. Shared toolsets are resolved before the MCP/RAG pass, so they can contain `{type: mcp, ref: <name>}` references.
+
+```yaml
+toolsets:
+  fs:               # a named shared toolset
+    type: filesystem
+  docs:
+    type: fetch
+    allowed_domains:
+      - docker.com
+
+agents:
+  root:
+    model: openai/gpt-5
+    # Pull in shared toolsets by name; inline toolsets come first.
+    use_toolsets: [fs, docs]
+    toolsets:
+      - type: think
+
+  reviewer:
+    model: openai/gpt-5
+    # Reuse the same filesystem toolset without copying its definition.
+    use_toolsets: [fs]
+```
+
+Inline `toolsets:` entries listed directly on the agent take precedence in ordering (they come first) and are always included alongside referenced ones.
+
+See [`examples/shared-toolsets.yaml`](https://github.com/docker/docker-agent/blob/main/examples/shared-toolsets.yaml) for a complete example.
+
+## Reusable Commands & Skills (`commands:` / `skills:`)
+
+The top-level `commands:` and `skills:` sections define named, reusable groups that agents pull in by name through `use_commands:` / `use_skills:`. This avoids repeating the same command set or skill configuration across agents. Each group value uses the exact same format as an agent's own `commands` / `skills` field.
+
+Referenced groups are merged into the agent during config loading. An agent's own inline `commands` / `skills` entries take precedence on name conflicts.
+
+```yaml
+commands:
+  ci:                       # a named command group
+    deploy: "Deploy the application"
+    test: "Run the test suite"
+skills:
+  base: [local, git]        # a named skill group
+
+agents:
+  root:
+    model: openai/gpt-5
+    use_commands: [ci]        # reuse the "ci" command group
+    use_skills: [base]        # reuse the "base" skill group
+    commands:
+      lint: "Run the linter"  # inline command, merged in (wins on conflict)
+  reviewer:
+    model: openai/gpt-5
+    use_commands: [ci]        # same group, reused without duplication
+```
+
+See [`examples/shared-commands-skills.yaml`](https://github.com/docker/docker-agent/blob/main/examples/shared-commands-skills.yaml) for a complete example.
+
+## Custom Providers Section
+
+Define reusable provider configurations with shared defaults. Providers can wrap any provider type — not just OpenAI-compatible endpoints:
+
+```yaml
+providers:
+  # OpenAI-compatible custom endpoint
+  azure:
+    api_type: openai_chatcompletions
+    base_url: https://my-resource.openai.azure.com/openai/deployments/gpt-4o
+    token_key: AZURE_OPENAI_API_KEY
+
+  # Anthropic with shared model defaults
+  team_anthropic:
+    provider: anthropic
+    token_key: TEAM_ANTHROPIC_KEY
+    max_tokens: 32768
+    thinking_budget: 16384
+
+models:
+  azure_gpt:
+    provider: azure
+    model: gpt-4o
+
+  claude:
+    provider: team_anthropic
+    model: claude-sonnet-4-5
+    # Inherits max_tokens, thinking_budget from provider
+
+agents:
+  root:
+    model: claude
+```
+
+| Field                 | Description                                                                              |
+| --------------------- | ---------------------------------------------------------------------------------------- |
+| `provider`            | Underlying provider type: `openai` (default), `anthropic`, `google`, `amazon-bedrock`, etc. |
+| `api_type`            | API schema: `openai_chatcompletions` (default) or `openai_responses`. OpenAI-only.        |
+| `base_url`            | Base URL for the API endpoint. Required for OpenAI-compatible providers.                  |
+| `token_key`           | Environment variable name for the API token.                                              |
+| `temperature`         | Default sampling temperature.                                                             |
+| `max_tokens`          | Default maximum response tokens.                                                          |
+| `thinking_budget`     | Default reasoning effort/budget.                                                          |
+| `task_budget`         | Default total token budget for an agentic task (Anthropic; honored by Claude Opus 4.7 today).  |
+| `top_p`               | Default top-p sampling parameter.                                                         |
+| `frequency_penalty`   | Default frequency penalty.                                                                |
+| `presence_penalty`    | Default presence penalty.                                                                 |
+| `parallel_tool_calls` | Enable parallel tool calls by default.                                                    |
+| `track_usage`         | Track token usage by default.                                                             |
+| `provider_opts`       | Provider-specific options.                                                                |
+
+See [Provider Definitions](../../providers/custom/index.md) for more details.
+
+## Reusable YAML (anchors & aliases)
+
+YAML anchors (`&name`), aliases (`*name`) and merge keys (`<<`) are part of the YAML spec, and Docker Agent's config parser supports them. Use them to declare a value once and reuse it elsewhere in the same file, instead of copy-pasting the same block across agents.
+
+This complements the named-reuse sections above (`mcps:`, `commands:` / `skills:`, `providers:`). Reach for anchors when you want to share something those sections don't cover, such as an instruction string or a block of agent settings.
+
+Reuse a value verbatim with an anchor and an alias:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Coordinator.
+    instruction: &house_rules |
+      You are part of the Acme engineering team.
+      Cite the files you looked at and keep changes minimal.
+  reviewer:
+    model: anthropic/claude-sonnet-4-5
+    description: Reviews code changes.
+    instruction: *house_rules        # the same instruction, declared once
+```
+
+Compose a block with a merge key (`<<`), then override individual fields:
+
+```yaml
+agents:
+  reviewer: &specialist
+    model: anthropic/claude-sonnet-4-5
+    description: Reviews code changes.
+    instruction: |
+      You are a meticulous software professional.
+    toolsets:
+      - type: filesystem
+  documenter:
+    <<: *specialist                   # inherit model, instruction, toolsets
+    description: Writes documentation. # then override one field
+```
+
+> [!WARNING]
+> **Where anchors can live**
+>
+> An anchor has to sit on a real value inside a known section (for example a real agent, model, or MCP entry, as above). Parking anchors in a separate top-level block such as `defaults:` or `prompts:` fails, because the parser rejects unknown top-level keys.
+
+> [!WARNING]
+> **Overriding merged keys**
+>
+> Overriding a key that a `<<` merge already set works only in the `agents:` section, as shown above. Every other section (`models:`, `mcps:`, `providers:`, `rag:`) is parsed strictly and reports the override as a duplicate key. There, use `<<` only to add new fields, or use the named-reuse sections above when you need per-entry overrides.
+
+Anchors are for static reuse within a single file, not dynamic values or cross-file composition. For environment-specific settings, see [Variable Expansion in Config Fields](#variable-expansion-in-config-fields), which substitutes `${env.VAR}` at load time. Templating tags such as `!include` are not acted on: the tag is ignored and its argument is kept as a plain string, so no other file is loaded. Circular aliases are not detected, so keep references acyclic.
+
+See [`examples/yaml-anchors.yaml`](https://github.com/docker/docker-agent/blob/main/examples/yaml-anchors.yaml) for a complete example.
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/permissions/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/permissions/index.md
new file mode 100644
index 000000000000..c49f5df5501b
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/permissions/index.md
@@ -0,0 +1,314 @@
+---
+title: "Permissions"
+description: "Control which tools can execute automatically, require confirmation, or are blocked entirely."
+keywords: docker agent, ai agents, configuration, yaml, permissions
+weight: 70
+canonical: https://docs.docker.com/ai/docker-agent/configuration/permissions/
+---
+
+_Control which tools can execute automatically, require confirmation, or are blocked entirely._
+
+## Overview
+
+Permissions provide fine-grained control over tool execution. You can configure which tools are auto-approved (run without asking), which require user confirmation, and which are completely blocked.
+
+> [!NOTE]
+> **Evaluation Order**
+>
+> Permissions are evaluated in this order: **Deny → Allow → Ask**. Deny patterns take priority, then allow patterns, and anything else falls through to the session's [safety mode](#safety-modes).
+
+## Safety Modes
+
+Every session runs in a **safety mode** that decides what happens when no permission rule matched a tool call. The runtime labels each call `safe` (safe-listed shell command such as `ls` or `git status`, or a read-only-annotated tool), `destructive` (destructive shell command such as `rm -rf`, or a destructive-annotated tool), or `unknown` — and the mode gates on that label:
+
+| Mode | safe | destructive | unknown |
+| ---- | ---- | ----------- | ------- |
+| `strict` | ask | ask | ask |
+| `balanced` | **allow** | ask | ask |
+| `restricted` | **allow** | deny | deny |
+| `autonomous` | **allow** | **allow** | **allow** |
+
+- **`strict`** prompts for every tool call, read-only ones included. Only an `allow:` rule silences a prompt.
+- **`balanced`** runs safe calls silently and asks about everything else.
+- **`restricted`** is the fail-closed profile for unattended/headless runs: safe calls run silently and everything else is **denied without asking** — the mode's fallback never prompts. Custom rules still win: an `allow:` rule can approve a destructive/unknown call, a `deny:` rule always blocks, and session-scoped `ask:` rules still prompt (as can a `preempt_yolo` hook). Restricted is defense in depth against unwanted tool calls, not a security boundary — for real isolation use [sandbox mode](../sandbox/index.md).
+- **`autonomous`** is the legacy `--yolo` behavior: everything runs. Only `deny:` rules, session-scoped `ask:` rules, and `preempt_yolo` hooks still gate.
+
+Pick a mode with the `--safety` flag (`docker-agent run --safety balanced ...`), the `safety_policy` field on session create (`POST /api/sessions`) or mid-session (`PATCH /api/sessions/:id/safety-policy`), or escalate directly from a confirmation prompt (`B` switches to balanced, `A` to autonomous; the `restricted` fallback never prompts, so the mode is only selected via flag/config/API). Sessions that never choose a mode keep the historical default: read-only tools auto-approve, everything else asks.
+
+### Declarative Safety Defaults
+
+Safety modes can also be declared as **defaults** in YAML, at four scopes:
+
+| Scope | Location | Owner |
+| ----- | -------- | ----- |
+| Alias | `aliases.<name>.safety` in `~/.config/cagent/config.yaml` (or `docker agent alias add ... --safety <mode>`) | User |
+| Global settings | `settings.safety` in `~/.config/cagent/config.yaml` | User |
+| Per-agent | `agents.<name>.safety` in the agent YAML | Agent author |
+| Config-wide | `runtime.safety` in the agent YAML | Agent author |
+
+```yaml
+# Agent YAML (author-declared defaults)
+runtime:
+  safety: balanced # config-wide default for new sessions
+
+agents:
+  root:
+    safety: strict # overrides runtime.safety for this agent
+```
+
+All four fields accept only the four canonical modes — `strict`, `balanced`, `restricted`, `autonomous` (yes, an author may declare `autonomous`) — and any other value fails loading with an error naming the field. The legacy spellings remain as aliases for `autonomous`: `settings.YOLO`, the alias `yolo` option, and the `--yolo` flag. When both are set at the same scope, `safety` wins over the legacy `YOLO`/`yolo`.
+
+For a **new** root session the first source in this order wins:
+
+1. explicit `--safety` flag
+2. explicit `--yolo` flag
+3. alias `safety`/`yolo` option
+4. `settings.safety`/`settings.YOLO` (user config)
+5. selected agent's `agents.<name>.safety`
+6. `runtime.safety`
+7. the historical default (read-only tools auto-approve, everything else asks)
+
+**Resuming a session never re-applies defaults**: the stored mode is kept unless you pass an explicit `--safety` or `--yolo` flag for that run. Agent switches, handoffs, and delegated sub-agent sessions inherit the active session's mode rather than resetting it.
+
+Sessions created through the API (`POST /api/sessions`) without a `safety_policy` receive the author-declared defaults (5–6) when their first run starts — the earliest point the agent configuration is loaded. If the server restarts before that first run, the session keeps the historical unset default (7).
+
+> [!WARNING]
+> **Trust: author defaults never outrank you.** `runtime.safety` and `agents.<name>.safety` are written by the agent's author — which may be a config you pulled from a URL or an OCI registry. They only fill the gap when you expressed no preference: any user-owned source (CLI flag, alias option, user settings) always takes precedence, and a resumed session keeps its stored mode. Still, an author default of `autonomous` means a fresh session runs every tool call unprompted — review third-party configs before running them, or pin your own floor with `settings.safety` / `--safety`.
+
+**Custom rules always win over the mode**, with one asymmetry: `ask:` rules written in an agent's YAML (or global config) are agent-author advisories and yield to a user-chosen `balanced`/`restricted`/`autonomous` mode (under `restricted` they resolve to the mode's allow-or-deny verdict rather than introducing a prompt), while `ask:` rules granted at the session level (interactive "always ask" decisions, the session permissions API) always prompt.
+
+## Permission Levels
+
+Permissions can be defined at two levels:
+
+| Level | Location | Scope |
+| ----- | -------- | ----- |
+| **Agent-level** | Agent YAML config (`permissions:` section) | Applies to that specific agent config |
+| **Global (user-level)** | `~/.config/cagent/config.yaml` under `settings.permissions` | Applies to every agent you run |
+
+Hooks follow the same user-config pattern: agent-level hooks live under `agents.<name>.hooks`, and global hooks live under `settings.hooks`. See [Hooks](../hooks/index.md#global-user-level-hooks).
+
+Both levels use the same `allow`/`ask`/`deny` pattern syntax. When both are present, they are **merged** at startup -- patterns from both sources are combined into a single checker. See [Merging Behavior](#merging-behavior) for details.
+
+## Agent-Level Configuration
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-4o
+    description: Agent with permission controls
+    instruction: You are a helpful assistant.
+
+permissions:
+  # Auto-approve these tools (no confirmation needed)
+  allow:
+    - "read_file"
+    - "read_*" # Glob patterns
+    - "shell:cmd=ls*" # With argument matching
+
+  # Always ask before running these tools, even if an allow pattern would match
+  ask:
+    - "shell:cmd=git push*"
+    - "write_file:path=/home/user/important/*"
+
+  # Block these tools entirely
+  deny:
+    - "shell:cmd=sudo*"
+    - "shell:cmd=rm*-rf*"
+    - "dangerous_tool"
+```
+
+The three lists are evaluated in order `deny` → `allow` → `ask`, so an `ask:` entry lets you add a confirmation layer on top of an otherwise-allowed tool.
+
+## Global Permissions
+
+Global permissions let you enforce rules across **all** agents, regardless of which agent config you run. Define them in your user config file:
+
+```yaml
+# ~/.config/cagent/config.yaml
+settings:
+  permissions:
+    deny:
+      - "shell:cmd=sudo*"
+      - "shell:cmd=rm*-rf*"
+    allow:
+      - "read_*"
+      - "shell:cmd=ls*"
+      - "shell:cmd=cat*"
+```
+
+This is useful for setting personal safety guardrails that apply everywhere -- for example, always blocking `sudo` or always auto-approving read-only tools -- without relying on each agent config to include those rules.
+
+### Merging Behavior
+
+When both global and agent-level permissions are present, they are merged into a single set of patterns before evaluation. The merge works as follows:
+
+- **Deny patterns from either source block the tool.** A global deny cannot be overridden by an agent-level allow, and vice versa.
+- **Allow patterns from either source auto-approve the tool** (as long as no deny pattern matches).
+- **Ask patterns from either source force confirmation** (as long as no deny or allow pattern matches).
+
+The evaluation order remains the same after merging: **Deny > Allow > Ask > default Ask**.
+
+> [!TIP]
+> **Example: Global deny + agent allow**
+>
+> If your global config denies `shell:cmd=sudo*` and an agent config allows `shell:cmd=sudo apt update`, the deny wins. Deny patterns always take priority regardless of source.
+
+## Pattern Syntax
+
+Permissions support glob-style patterns with optional argument matching:
+
+### Simple Patterns
+
+| Pattern        | Matches                        |
+| -------------- | ------------------------------ |
+| `shell`        | Exact match for `shell` tool   |
+| `read_*`       | Any tool starting with `read_` |
+| `github_*`     | Any GitHub MCP tool            |
+| `*`            | All tools                      |
+
+### Argument Matching
+
+You can match tools based on their argument values using `tool:arg=pattern` syntax:
+
+```yaml
+permissions:
+  allow:
+    # Allow shell only when cmd starts with "ls" or "cat"
+    - "shell:cmd=ls*"
+    - "shell:cmd=cat*"
+
+    # Allow edit_file only in specific directory
+    - "edit_file:path=/home/user/safe/*"
+
+  deny:
+    # Block shell with sudo
+    - "shell:cmd=sudo*"
+
+    # Block writes to system directories
+    - "write_file:path=/etc/*"
+    - "write_file:path=/usr/*"
+```
+
+> [!NOTE]
+> **Colons inside argument values are preserved.** Only the `:key=` token boundaries between
+> argument conditions split a pattern — colons that appear inside a value are treated as
+> ordinary characters and do not start a new condition. Check a tool’s actual argument names
+> (and whether they accept a string or a list) before writing an argument-matching pattern.
+
+### Multiple Argument Conditions
+
+Chain multiple argument conditions with colons. All conditions must match:
+
+```yaml
+permissions:
+  allow:
+    # Allow shell with ls in current directory
+    - "shell:cmd=ls*:cwd=."
+
+  deny:
+    # Block shell with rm -rf anywhere
+    - "shell:cmd=rm*:cmd=*-rf*"
+```
+
+## Glob Pattern Rules
+
+Patterns follow filepath.Match semantics with some extensions:
+
+- `*` — matches any sequence of characters (including spaces)
+- `?` — matches any single character
+- `[abc]` — matches any character in the set
+- `[a-z]` — matches any character in the range
+
+Matching is **case-insensitive**.
+
+> [!TIP]
+> **Trailing Wildcards**
+>
+> Trailing wildcards like `sudo*` match any characters including spaces, so `sudo*` matches `sudo rm -rf /`.
+
+## Decision Types
+
+| Decision  | Behavior                                            |
+| --------- | --------------------------------------------------- |
+| **Allow** | Tool executes immediately without user confirmation |
+| **Ask**   | User must confirm before tool executes (default)    |
+| **Deny**  | Tool is blocked and returns an error to the agent   |
+
+## Examples
+
+### Read-Only Agent
+
+Allow all read operations, block all writes:
+
+```yaml
+permissions:
+  allow:
+    - "read_file"
+    - "read_multiple_files"
+    - "list_directory"
+    - "directory_tree"
+    - "search_files_content"
+  deny:
+    - "write_file"
+    - "edit_file"
+    - "shell"
+```
+
+### Safe Shell Agent
+
+Allow specific safe commands, block dangerous ones:
+
+```yaml
+permissions:
+  allow:
+    - "shell:cmd=ls*"
+    - "shell:cmd=cat*"
+    - "shell:cmd=grep*"
+    - "shell:cmd=find*"
+    - "shell:cmd=head*"
+    - "shell:cmd=tail*"
+    - "shell:cmd=wc*"
+  deny:
+    - "shell:cmd=sudo*"
+    - "shell:cmd=rm*"
+    - "shell:cmd=mv*"
+    - "shell:cmd=chmod*"
+    - "shell:cmd=chown*"
+```
+
+### MCP Tool Permissions
+
+Control MCP tools by their qualified names:
+
+```yaml
+permissions:
+  allow:
+    # Allow all GitHub read operations
+    - "github_get_*"
+    - "github_list_*"
+    - "github_search_*"
+  deny:
+    # Block destructive GitHub operations
+    - "github_delete_*"
+    - "github_close_*"
+```
+
+## Combining with Hooks
+
+Permissions work alongside [hooks](../hooks/index.md). The evaluation order is:
+
+1. Run **`preempt_yolo` pre_tool_use hooks** — security-critical checks that no mode or allow rule can bypass
+2. Check **deny** patterns — if matched, tool is blocked
+3. Check **allow** patterns — if matched, tool is auto-approved
+4. Check **ask** patterns — if matched, the user is prompted directly, skipping the default `pre_tool_use` lane
+5. If no rule matched, apply the **[safety mode](#safety-modes)** to the call's safety label — may auto-approve (or, under `restricted`, deny)
+6. On a mode "ask", run **pre_tool_use hooks** — hooks can allow, deny, or ask
+7. If no decision, **ask user** for confirmation
+
+Default-lane hooks only see calls the mode routed to "ask"; they cannot override deny decisions or explicit `ask:` rules.
+
+> [!WARNING]
+> **Security Note**
+>
+> Permissions are enforced client-side. They help prevent accidental operations but should not be relied upon as a security boundary for untrusted agents. For stronger isolation, use [sandbox mode](../sandbox/index.md).
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/routing/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/routing/index.md
new file mode 100644
index 000000000000..54c187bbf63f
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/routing/index.md
@@ -0,0 +1,170 @@
+---
+title: "Model Routing"
+description: "Route requests to different models based on the content of user messages."
+keywords: docker agent, ai agents, configuration, yaml, model routing
+weight: 100
+canonical: https://docs.docker.com/ai/docker-agent/configuration/routing/
+---
+
+_Route requests to different models based on the content of user messages._
+
+## Overview
+
+Model routing lets you define a "router" model that automatically selects the best underlying model based on the user's message. This is useful for cost optimization, specialized handling, or load balancing across models.
+
+> [!NOTE]
+> **How It Works**
+>
+> Docker Agent uses NLP-based text similarity (via Bleve full-text search) to match user messages against example phrases you define. The route with the best-matching examples wins, and that model handles the request.
+
+## Configuration
+
+Add `routing` rules to any model definition. The model's `provider`/`model` fields become the fallback when no route matches:
+
+```yaml
+models:
+  smart_router:
+    # Fallback model when no routing rule matches
+    provider: openai
+    model: gpt-5-mini
+
+    # Routing rules
+    routing:
+      - model: anthropic/claude-sonnet-4-5
+        examples:
+          - "Write a detailed technical document"
+          - "Help me architect this system"
+          - "Review this code for security issues"
+          - "Explain this complex algorithm"
+
+      - model: openai/gpt-5
+        examples:
+          - "Generate some creative ideas"
+          - "Write a story about"
+          - "Help me brainstorm"
+          - "Come up with names for"
+
+      - model: openai/gpt-5-mini
+        examples:
+          - "What time is it"
+          - "Convert this to JSON"
+          - "Simple math calculation"
+          - "Translate this word"
+
+agents:
+  root:
+    model: smart_router
+    description: Assistant with intelligent model routing
+    instruction: You are a helpful assistant.
+```
+
+## Routing Rules
+
+Each routing rule has:
+
+| Field      | Type   | Required | Description                                                   |
+| ---------- | ------ | -------- | ------------------------------------------------------------- |
+| `model`    | string | ✓        | Target model (inline format or reference to `models` section) |
+| `examples` | array  | ✓        | Example phrases that should route to this model               |
+
+## Matching Behavior
+
+The router:
+
+1. Extracts the last user message from the conversation
+2. Searches all examples using full-text search
+3. Aggregates match scores by route (best score per route wins)
+4. Selects the route with the highest overall score
+5. Falls back to the base model if no good match is found
+
+> [!TIP]
+> **Writing Good Examples**
+>
+> - Use diverse phrasing that captures the intent
+> - Include keywords users actually use
+> - Add 5-10 examples per route for best results
+> - Examples don't need to be exact matches — the router uses semantic similarity
+
+## Use Cases
+
+### Cost Optimization
+
+Route simple queries to cheaper models:
+
+```yaml
+models:
+  cost_optimizer:
+    provider: openai
+    model: gpt-5-mini # Cheap fallback
+    routing:
+      - model: anthropic/claude-sonnet-4-5
+        examples:
+          - "Complex analysis"
+          - "Detailed research"
+          - "Multi-step reasoning"
+```
+
+### Specialized Models
+
+Route coding tasks to code-specialized models:
+
+```yaml
+models:
+  task_router:
+    provider: openai
+    model: gpt-5-mini # General fallback
+    routing:
+      - model: anthropic/claude-sonnet-4-5
+        examples:
+          - "Write code"
+          - "Debug this function"
+          - "Review my implementation"
+          - "Fix this bug"
+      - model: openai/gpt-5
+        examples:
+          - "Write a blog post"
+          - "Help me with writing"
+          - "Summarize this document"
+```
+
+### Load Balancing
+
+Distribute load across equivalent models from different providers:
+
+```yaml
+models:
+  load_balancer:
+    provider: openai
+    model: gpt-5-mini
+    routing:
+      - model: anthropic/claude-sonnet-4-5
+        examples:
+          - "First request pattern"
+          - "Another request type"
+      - model: google/gemini-2.5-flash
+        examples:
+          - "Different request pattern"
+          - "Alternative query style"
+```
+
+## Debugging
+
+Enable debug logging to see routing decisions:
+
+```bash
+$ docker agent run config.yaml --debug
+```
+
+Look for log entries like:
+
+```text
+"Rule-based router selected model" router=smart_router selected_model=anthropic/claude-sonnet-4-5
+"Route matched" model=anthropic/claude-sonnet-4-5 score=2.45
+```
+
+> [!WARNING]
+> **Limitations**
+>
+> - Routing only considers the last user message, not full conversation context
+> - Very short messages may not match well — consider your fallback carefully
+> - Each routed model creates a separate provider connection
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/sandbox/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/sandbox/index.md
new file mode 100644
index 000000000000..ec8cf9540d50
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/sandbox/index.md
@@ -0,0 +1,286 @@
+---
+title: "Sandbox Mode"
+description: "Run agents in an isolated sandbox VM managed by sbx."
+keywords: docker agent, sbx, ai agents, configuration, yaml, sandbox mode
+weight: 80
+canonical: https://docs.docker.com/ai/docker-agent/configuration/sandbox/
+---
+
+_Run agents in an isolated sandbox VM managed by [`sbx`](https://docs.docker.com/ai/sandboxes/)._
+
+## Overview
+
+Sandbox mode is Docker Agent's integration with
+[`sbx`](https://docs.docker.com/ai/sandboxes/), Docker's sandbox product. `sbx`
+provides the runtime, CLI, and VM; Docker Agent is one of its built-in agents.
+The `--sandbox` flag asks `sbx` to create or reuse a VM and launches Docker
+Agent inside it.
+
+All shell, filesystem, and process activity happens inside that VM, so a
+misbehaving agent cannot touch files outside the mounted working directory or
+reach long-lived host state. Docker Agent does not implement the sandbox or
+start a raw `docker run` container; it orchestrates the installed `sbx` CLI.
+
+> [!NOTE]
+> **Requirements**
+>
+> Install and configure the [`sbx` CLI](https://docs.docker.com/ai/sandboxes/) before
+> using `--sandbox`.
+
+## Usage
+
+Enable sandbox mode with the `--sandbox` flag on the `docker agent run` command:
+
+```bash
+docker agent run --sandbox agent.yaml
+```
+
+Docker Agent asks `sbx` to launch or reuse a sandbox VM, mounts the current
+working directory, and runs the agent inside it.
+
+## Flags
+
+| Flag          | Default                                      | Description                                                                                               |
+| ------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
+| `--sandbox`   | `false`                                      | Enable sandbox mode.                                                                                      |
+| `--template`  | `docker/docker-agent-sbx-templates:latest`   | OCI image used as the sandbox template. Passed to `sbx create -t`. See [Sandbox templates](#sandbox-templates). |
+| `--no-kit`    | `false`                                      | Disable the [auto-kit](#auto-kit) — do not stage skills or prompt files into the sandbox.                 |
+
+```bash
+# Use a custom template image
+docker agent run --sandbox --template myorg/custom-agent-template:latest agent.yaml
+
+# Run without staging skills / prompt files into the sandbox
+docker agent run --sandbox --no-kit agent.yaml
+```
+
+### Always sandbox a given agent
+
+Add `--sandbox` to an [alias](../../features/cli/index.md#docker-agent-alias) so the
+sandbox path is taken automatically whenever that alias is invoked:
+
+```bash
+docker agent alias add safe-coder myorg/coder --sandbox
+docker agent run safe-coder
+```
+
+An explicit `--sandbox=false` on the command line still wins, so you can opt
+out of the sandbox for a single run without touching the alias.
+
+### Bake the default into the agent config
+
+Agent authors can declare a sandbox default in the YAML itself. Any caller of
+the agent then gets the sandbox path automatically, without having to know
+(or remember) to pass `--sandbox`:
+
+```yaml
+# agent.yaml
+runtime:
+  sandbox: true
+
+agents:
+  root:
+    model: openai/gpt-4o
+    description: A helpful assistant
+    instruction: You are a helpful assistant.
+    toolsets:
+      - type: shell
+```
+
+```bash
+docker agent run agent.yaml   # runs in a sandbox automatically
+```
+
+The rule is the same as for aliases: an explicit `--sandbox=false` on the
+CLI overrides the config default, so you can debug an agent on the host
+without editing its YAML.
+
+### Declare a network allowlist
+
+The runner already opens the [tool install hosts](#network-allowlist) and
+the [models gateway](#how-it-works) automatically, but agents that talk
+to endpoints those resolvers can't infer (custom MCP servers, third-party
+APIs, registries not covered by the aqua resolver) would still see a 403
+from the sandbox proxy on first contact.
+
+Declare those hosts in `runtime.network_allowlist` and they are unioned
+with the inferred set, so the agent can reach them on its first request:
+
+```yaml
+# agent.yaml
+runtime:
+  sandbox: true
+  network_allowlist:
+    - api.example.com
+    - registry.npmjs.org
+```
+
+Each entry is a hostname with an optional `:port` suffix. Commas and
+whitespace are rejected to keep a single entry from smuggling several
+rules into the policy engine. The runner prints the resulting allowlist
+before launch so you can audit exactly which hosts the run opens up.
+
+### Persist your own allowlist
+
+For hosts you keep needing across agents (a corporate proxy, a
+self-hosted registry, ...) `docker agent sandbox allow` writes the
+entry into `~/.config/cagent/config.yaml` once and unions it with the
+inferred and agent-declared sets on every subsequent `--sandbox` run:
+
+```bash
+# I just got a `Blocked by network policy` 403 on api.example.com.
+docker agent sandbox allow api.example.com
+
+# See what's currently persisted.
+docker agent sandbox list
+
+# Drop a host you no longer need.
+docker agent sandbox deny api.example.com
+```
+
+When the kit's per-toolset host resolver fails (the `! using fallback
+host set` line in the launch summary), the runner now prints a hint
+pointing at this command so you can turn the missing host into a
+one-line, persistent fix instead of relying on the wider conservative
+fallback host set.
+
+## Sandbox templates
+
+A sandbox template is the OCI image the sandbox VM boots from. It determines
+the base OS and the tools available inside the VM, including whether the
+`docker-agent` binary is already there. `--template` (or `-t` on `sbx
+create`) selects it.
+
+### The default template
+
+`--template` defaults to `docker/docker-agent-sbx-templates:latest`, the
+template this repository's own CI builds and publishes from the most recent
+`v*` release — see [The repo-published templates](#the-repo-published-templates)
+for what it contains and the other available tags.
+
+### The repo-published templates
+
+This repository's own CI builds and publishes the sandbox template — from
+the `template` stage of the
+[`Dockerfile`](https://github.com/docker/docker-agent/blob/main/Dockerfile) —
+as `docker/docker-agent-sbx-templates`:
+
+| Tag       | Built from                    | Use it when                                                        |
+| --------- | ------------------------------ | ------------------------------------------------------------------- |
+| `:latest` | The most recent `v*` release   | You want the newest Docker Agent template with release stability (the default). |
+| `:edge`   | The current `main` branch      | You want today's `main` build and can tolerate lower stability.   |
+
+(Each release also publishes a matching version-pinned tag, e.g.
+`docker/docker-agent-sbx-templates:1.2.3`.)
+
+`:latest` is the default. Reach for `:edge` only when you specifically
+need an unreleased fix or feature and can tolerate the occasional breakage.
+For reproducible runs, pin to a digest instead of a tag, e.g.
+`docker/docker-agent-sbx-templates@sha256:...`.
+
+Select one with `--template`:
+
+```bash
+$ docker agent run --sandbox --template docker/docker-agent-sbx-templates:edge agent.yaml
+```
+
+Or point the [`sbx`](https://docs.docker.com/ai/sandboxes/) CLI at it
+directly, without going through Docker Agent:
+
+```bash
+$ sbx create -t docker/docker-agent-sbx-templates:latest
+```
+
+> [!TIP]
+> The [`sbx` documentation](https://docs.docker.com/ai/sandboxes/) covers the
+> sandbox CLI and runtime independently of Docker Agent.
+
+### What they contain
+
+The `template` stage in this repository's
+[`Dockerfile`](https://github.com/docker/docker-agent/blob/main/Dockerfile)
+layers onto `docker/sandbox-templates:shell-docker` and adds:
+
+- The `docker-agent` binary.
+- `vim` and `tmux`, for interactive debugging inside the VM.
+- The **`docker-mcp`** Docker CLI plugin, installed at `~/.docker/cli-plugins/docker-mcp`.
+
+The image carries the label `com.docker.sandboxes.flavor=docker-agent-docker`
+so sandbox tooling can identify it.
+
+## Example
+
+```yaml
+# agent.yaml
+agents:
+  root:
+    model: openai/gpt-4o
+    description: Agent with sandboxed shell
+    instruction: You are a helpful assistant.
+    toolsets:
+      - type: shell
+```
+
+```bash
+docker agent run --sandbox agent.yaml
+```
+
+## How It Works
+
+1. `--sandbox` tells Docker Agent to invoke the installed `sbx` CLI.
+2. A new sandbox VM is created from the image passed via `--template`.
+3. The current working directory is mounted into the VM; the agent binary is copied in.
+4. The [auto-kit](#auto-kit) is staged on the host and bind-mounted read-only into the VM, so the agent sees its skills and prompt files inside the sandbox.
+5. The default-deny network proxy is opened for the configured [models gateway](../../features/cli/index.md#runtime-configuration-flags) and any package hosts the auto-installer needs for the agent's MCP/LSP toolsets.
+6. All tools (shell, filesystem, background jobs, etc.) run inside the VM.
+7. When the session ends, Docker Agent exits but does not stop or remove the sandbox VM; both the VM and the kit are kept around so subsequent runs from the same workspace can reuse them. A fresh sandbox is created only when the mount set has changed.
+
+### What the default template includes
+
+The default template (`docker/docker-agent-sbx-templates:latest`) is built
+from this repository's own `Dockerfile` — see
+[What they contain](#what-they-contain) for the exact contents, including
+the `docker-mcp` CLI plugin.
+
+## Auto-Kit
+
+The sandbox VM has its own filesystem and `$HOME` — none of the host's `~/.agents/skills/`, `~/.claude/skills/`, project-level `.agents/skills/`, or prompt files like `AGENTS.md` and `CLAUDE.md` are visible inside it. To bridge that gap, Docker Agent automatically builds a **kit**: a self-contained directory staged on the host before the sandbox starts and bind-mounted read-only into the VM at the same path.
+
+The kit is built whenever `--sandbox` is used with an agent reference. It is opt-out via `--no-kit`.
+
+### What gets staged
+
+For the agent referenced on the command line, the kit collects:
+
+- **Local [skills](../../features/skills/index.md)** — every `SKILL.md` discovered on the host (global `~/.codex/skills/`, `~/.claude/skills/`, `~/.agents/skills/`, plus project `.claude/skills/`, `.github/skills/` and `.agents/skills/`) is copied under `<kit>/skills/<skill-name>/`. The in-sandbox skills loader reads from the kit instead of the (non-existent) host `$HOME`.
+- **Prompt files** — every file referenced via the agent's `add_prompt_files` (`AGENTS.md`, `CLAUDE.md`, …) is collected. Files that already live under the working directory are left alone (the live workspace mount surfaces them); files outside it (e.g. an `AGENTS.md` in `$HOME`) are copied under `<kit>/prompt_files/`.
+- **A manifest** — `<kit>/manifest.json` records what was staged. The on-disk copy is sanitised so it cannot be used to map the host filesystem from inside the sandbox.
+
+Before launch, Docker Agent prints a summary of what was staged so you can see exactly which skills and prompt files the agent will have access to inside the sandbox.
+
+### Secret redaction
+
+Every text file copied into the kit is run through [portcullis](https://github.com/docker/portcullis), which redacts secrets that match its detection patterns (API keys, tokens, …) in the staged copy. The kit's printed summary marks files as `(redacted)` whenever at least one secret was replaced. Detection is best-effort — portcullis recognises common secret formats but novel or obfuscated tokens may slip through, so the kit is not a substitute for keeping secrets out of skill sources in the first place.
+
+### Network allowlist
+
+The sandbox templates ship with a default-deny network proxy that allows the major model providers but blocks `*.docker.com` and every package-registry / source host the auto-installer reaches for. When the agent declares MCP or LSP toolsets that have a `command` and an installable `version`, the kit build resolves each toolset's package against the [aqua](https://aquaproj.github.io/) registry and computes the minimal set of hosts the in-sandbox auto-installer will need (Go module proxy + toolchain bootstrap for `go_install` packages, GitHub release hosts for `github_release` packages, …). Those hosts, `models.dev` (needed so the in-sandbox agent can resolve model metadata such as context limits, pricing, and capabilities — without it the first catalog lookup fails with a `403 Blocked by network policy` error), and the configured [`--models-gateway`](../../features/cli/index.md#runtime-configuration-flags) — are then allow-listed on the sandbox proxy. If a per-toolset registry lookup fails, a conservative fallback union is used so the run can still succeed; the affected toolsets are surfaced in the printed summary.
+
+### Caching
+
+Kits are stored under the Docker Agent cache directory (`~/Library/Caches/cagent/sandbox-kits/<hash>` on macOS) keyed by a content hash of the agent reference. Reusing the same agent across runs reuses the same kit directory in place; disk usage is bounded by the number of distinct agents you have run. Kits are deliberately kept on disk between runs because the reused sandbox VM holds a hard reference to the kit's bind-mount path — deleting it would leave the sandbox un-startable.
+
+### Disabling the kit
+
+Pass `--no-kit` to skip the kit build entirely. The agent then runs without any host-side skills or external prompt files visible inside the sandbox, and the network allowlist falls back to the template defaults. Useful for debugging the sandbox itself, or for agents that don't depend on host skills.
+
+```bash
+docker agent run --sandbox --no-kit agent.yaml
+```
+
+> [!WARNING]
+> **Limitations**
+>
+> - Sandboxes are reused across runs from the same workspace; if the required mount set changes (e.g. a new kit is staged), the previous sandbox is removed and a fresh one is created.
+> - Only the working directory, the agent config directory, and (when staged) the kit directory are mounted; other host files are not visible to the agent.
+> - Network egress is constrained by the sandbox backend's default-deny policy plus the per-run allowlist described above.
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/structured-output/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/structured-output/index.md
new file mode 100644
index 000000000000..9dc4c9e30343
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/structured-output/index.md
@@ -0,0 +1,250 @@
+---
+title: "Structured Output"
+description: "Force the agent to respond with JSON matching a specific schema."
+keywords: docker agent, ai agents, configuration, yaml, structured output
+weight: 90
+canonical: https://docs.docker.com/ai/docker-agent/configuration/structured-output/
+---
+
+_Force the agent to respond with JSON matching a specific schema._
+
+## Overview
+
+Structured output constrains the agent's responses to match a predefined JSON schema. This is useful for building agents that need to produce machine-readable output for downstream processing, API responses, or integration with other systems.
+
+> [!NOTE]
+> **When to Use**
+>
+> - Building API endpoints that need consistent JSON responses
+> - Data extraction and transformation pipelines
+> - Agents that feed into other automated systems
+> - Ensuring predictable output format for parsing
+
+## Configuration
+
+```yaml
+agents:
+  analyzer:
+    model: openai/gpt-4o
+    description: Code analyzer that outputs structured results
+    instruction: |
+      Analyze the provided code and identify issues.
+      Return your findings in the structured format.
+    structured_output:
+      name: analysis_result
+      description: Code analysis findings
+      strict: true
+      schema:
+        type: object
+        properties:
+          issues:
+            type: array
+            items:
+              type: object
+              properties:
+                severity:
+                  type: string
+                  enum: ["error", "warning", "info"]
+                line:
+                  type: integer
+                message:
+                  type: string
+              required: ["severity", "line", "message"]
+          summary:
+            type: string
+        required: ["issues", "summary"]
+```
+
+## Properties
+
+| Property      | Type    | Required | Description                                                       |
+| ------------- | ------- | -------- | ----------------------------------------------------------------- |
+| `name`        | string  | ✓        | Name identifier for the output schema                             |
+| `description` | string  | ✗        | Description of what the output represents                         |
+| `strict`      | boolean | ✗        | Enforce strict schema adherence — `native` mode only (default: `false`) |
+| `schema`      | object  | ✓        | JSON Schema defining the output structure                         |
+| `mode`        | string  | ✗        | Enforcement mode: `native` (default) or `tool` (see [Modes](#modes)) |
+
+## Modes
+
+### `native` (default)
+
+The schema is passed to the provider's native structured-output support (OpenAI JSON mode, Gemini JSON mode, ...). Omitting `mode` keeps this behavior.
+
+### `tool`
+
+```yaml
+structured_output:
+  mode: tool
+  name: analysis_result
+  schema:
+    type: object
+    properties:
+      summary:
+        type: string
+    required: ["summary"]
+```
+
+In tool mode nothing is sent to the provider's native structured-output API. Instead, the runtime exposes an internal tool named `__structured_output__` whose parameters are exactly the configured schema. The model works normally — including calling other tools — and delivers its final answer by calling that tool, alone, as the only tool call of its response. The runtime validates the arguments against the schema:
+
+- A valid call ends the turn; the validated (compacted) JSON becomes the final assistant message.
+- Invalid JSON gets a detailed tool error so the model can correct itself and retry.
+- If the model answers in plain text instead, the runtime injects a transient system reminder and retries (at most 2 reminders), then fails with a `structured_output_failed` error.
+
+Tool-mode validation applies the full JSON Schema, including `additionalProperties` — unexpected fields are rejected when the schema forbids them. External `$ref` references (`http(s)://`, `file://`, cross-document) are rejected when the schema is compiled; only same-document references starting with `#` (e.g. `#/definitions/item`) are allowed. The `strict` flag has no effect in tool mode.
+
+Fork-mode skills (`context: fork`) run as exempt sub-sessions: the skill produces its own plain-text answer for the calling agent and is not required to call the output tool. The parent agent still delivers its final answer through the tool.
+
+Use tool mode when the model must combine tool use with a schema-constrained final answer, or when the provider has no native structured-output support. See [`examples/structured-output-tool-mode.yaml`](https://github.com/docker/docker-agent/blob/main/examples/structured-output-tool-mode.yaml).
+
+## Schema Format
+
+The schema follows [JSON Schema](https://json-schema.org/) specification. Common schema types:
+
+### Simple Object
+
+```yaml
+schema:
+  type: object
+  properties:
+    name:
+      type: string
+    count:
+      type: integer
+    active:
+      type: boolean
+  required: ["name", "count"]
+```
+
+### Array of Objects
+
+```yaml
+schema:
+  type: object
+  properties:
+    items:
+      type: array
+      items:
+        type: object
+        properties:
+          id:
+            type: string
+          value:
+            type: number
+        required: ["id", "value"]
+  required: ["items"]
+```
+
+### Enum Values
+
+```yaml
+schema:
+  type: object
+  properties:
+    status:
+      type: string
+      enum: ["pending", "approved", "rejected"]
+    priority:
+      type: string
+      enum: ["low", "medium", "high", "critical"]
+  required: ["status"]
+```
+
+## Strict Mode
+
+`strict` only applies to `native` mode: it is passed to the provider's structured-output API. Tool mode ignores it and always validates against the full schema instead. When `strict: true`, the model is constrained to only produce output that exactly matches the schema. This provides stronger guarantees but may limit the model's flexibility.
+
+- **`strict: false` (default)** — model aims to match the schema but may include additional fields or slight variations.
+- **`strict: true`** — model output is constrained to exactly match the schema. Stronger guarantees.
+
+## Provider Support
+
+Structured output support varies by provider:
+
+| Provider      | Support    | Notes                                   |
+| ------------- | ---------- | --------------------------------------- |
+| OpenAI        | ✓ Full     | Native JSON mode with schema validation |
+| Anthropic     | ✓ Full     | Tool-based structured output            |
+| Google Gemini | ✓ Full     | Native JSON mode                        |
+| AWS Bedrock   | ✓ Partial  | Depends on underlying model             |
+| DMR           | ⚠️ Limited | Depends on model capabilities           |
+
+## Example: Data Extraction Agent
+
+```yaml
+agents:
+  extractor:
+    model: openai/gpt-4o
+    description: Extract structured data from text
+    instruction: |
+      Extract contact information from the provided text.
+      Return all found contacts in the structured format.
+    structured_output:
+      name: contacts
+      description: Extracted contact information
+      strict: true
+      schema:
+        type: object
+        properties:
+          contacts:
+            type: array
+            items:
+              type: object
+              properties:
+                name:
+                  type: string
+                  description: Full name of the contact
+                email:
+                  type: string
+                  description: Email address
+                phone:
+                  type: string
+                  description: Phone number
+                company:
+                  type: string
+                  description: Company or organization
+              required: ["name"]
+          total_found:
+            type: integer
+            description: Total number of contacts found
+        required: ["contacts", "total_found"]
+```
+
+## Example: Classification Agent
+
+```yaml
+agents:
+  classifier:
+    model: anthropic/claude-sonnet-4-5
+    description: Classify support tickets
+    instruction: |
+      Classify the support ticket into the appropriate category
+      and priority level based on its content.
+    structured_output:
+      name: ticket_classification
+      strict: true
+      schema:
+        type: object
+        properties:
+          category:
+            type: string
+            enum:
+              ["billing", "technical", "account", "feature_request", "other"]
+          priority:
+            type: string
+            enum: ["low", "medium", "high", "urgent"]
+          confidence:
+            type: number
+            minimum: 0
+            maximum: 1
+            description: Confidence score between 0 and 1
+          reasoning:
+            type: string
+            description: Brief explanation for the classification
+        required: ["category", "priority", "confidence"]
+```
+
+> [!WARNING]
+> **Tool Limitations**
+>
+> When using native structured output, the agent typically cannot use tools since its response format is constrained to the schema. Design your agent workflow accordingly — native structured output agents work best for single-turn analysis or extraction tasks. Use `mode: tool` when the agent needs to call tools before producing its schema-constrained final answer.
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md
new file mode 100644
index 000000000000..ff25b1f45ba0
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md
@@ -0,0 +1,518 @@
+---
+title: "Tool Configuration"
+description: "Complete reference for configuring built-in tools, MCP tools, and Docker-based tools."
+keywords: docker agent, ai agents, configuration, yaml, tool configuration
+linkTitle: "Tool Config"
+weight: 50
+canonical: https://docs.docker.com/ai/docker-agent/configuration/tools/
+aliases:
+  - /ai/docker-agent/reference/toolsets/
+---
+
+_Complete reference for configuring built-in tools, MCP tools, and Docker-based tools._
+
+## Built-in Tools
+
+Built-in tools are included with Docker Agent and require no external dependencies. Add them to your agent's `toolsets` list by `type`. Each tool's dedicated page covers its full configuration options, available operations, and examples.
+
+| Type | Description | Page |
+| --- | --- | --- |
+| `filesystem` | Read, write, list, search, navigate | [Filesystem](../../tools/filesystem/index.md) |
+| `git` | Read-only repository inspection (status, log, branches, show, blame) | [Git](../../tools/git/index.md) |
+| `shell` | Execute shell commands synchronously | [Shell](../../tools/shell/index.md) |
+| `background_jobs` | Run and manage long-running shell commands | [Background Jobs](../../tools/background-jobs/index.md) |
+| `scheduler` | Schedule instructions to run at a time or on a recurring interval | [Scheduler](../../tools/scheduler/index.md) |
+| `think` | Reasoning scratchpad | [Think](../../tools/think/index.md) |
+| `plan` | Shared persistent scratchpad for multi-agent collaboration | [Plan](../../tools/plan/index.md) |
+| `session_plan` | Per-session markdown plan for the draft-review-execute workflow | [Session Plan](../../tools/session_plan/index.md) |
+| `session_context` | Reference a previous session as context (read-only) | [Session Context](../../tools/session_context/index.md) |
+| `todo` | Task list management | [Todo](../../tools/todo/index.md) |
+| `memory` | Persistent key-value storage (SQLite) | [Memory](../../tools/memory/index.md) |
+| `tasks` | Persistent task database shared across sessions | [Tasks](../../tools/tasks/index.md) |
+| `fetch` | HTTP `GET` requests with text/markdown/html output | [Fetch](../../tools/fetch/index.md) |
+| `script` | Custom shell scripts as tools | [Script](../../tools/script/index.md) |
+| `lsp` | Language Server Protocol integration | [LSP](../../tools/lsp/index.md) |
+| `api` | Custom HTTP API tools | [API](../../tools/api/index.md) |
+| `openapi` | Import every operation of an OpenAPI 3.x document as tools | [OpenAPI](../../tools/openapi/index.md) |
+| `rag` | Retrieval-augmented generation over indexed sources | [RAG](../../tools/rag/index.md) |
+| `model_picker` | Let the agent pick between several models per turn | [Model Picker](../../tools/model-picker/index.md) |
+| `user_prompt` | Interactive user input | [User Prompt](../../tools/user-prompt/index.md) |
+| `open_url` | Open a fixed URL in the user's default browser | [Open URL](../../tools/open-url/index.md) |
+| `transfer_task` | Delegate to sub-agents (auto-enabled) | [Transfer Task](../../tools/transfer-task/index.md) |
+| `background_agents` | Parallel sub-agent dispatch | [Background Agents](../../tools/background-agents/index.md) |
+| `webhook` | Reliable notifications to a configured destination, with retries (Slack, Discord, Telegram, IFTTT, Teams, …) | [Webhook](../../tools/webhook/index.md) |
+| `handoff` | Local conversation handoff to another agent in the same config (auto-enabled by `handoffs:`) | [Handoff](../../tools/handoff/index.md) |
+| `a2a` | A2A remote agent connection | [A2A](../../tools/a2a/index.md) |
+| `mcp_catalog` | Discover and activate remote MCP servers from the Docker MCP Catalog on demand | [MCP Catalog](../../tools/mcp-catalog/index.md) |
+
+**Example:**
+
+```yaml
+toolsets:
+  - type: filesystem
+  - type: shell
+  - type: background_jobs
+  - type: think
+  - type: todo
+  - type: memory
+    path: ./dev.db
+```
+
+## MCP Tools
+
+Extend agents with external tools via the [Model Context Protocol](https://modelcontextprotocol.io/). For a standalone overview of the `mcp` toolset see the [MCP tool page](../../tools/mcp/index.md).
+
+> [!TIP]
+> **Reusable MCP definitions**
+>
+> Repeated MCP server definitions can be hoisted into the top-level `mcps:` section and referenced by name with `{type: mcp, ref: <name>}`. See [Reusable MCP Servers](../overview/index.md#reusable-mcp-servers-mcps).
+
+### Docker MCP (Recommended)
+
+Run MCP servers as secure Docker containers via the [MCP Gateway](https://github.com/docker/mcp-gateway):
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:duckduckgo # web search
+  - type: mcp
+    ref: docker:github-official # GitHub integration
+```
+
+Browse available tools at the [Docker MCP Catalog](https://hub.docker.com/search?q=&type=mcp).
+
+| Property      | Type   | Description                                                      |
+| ------------- | ------ | ---------------------------------------------------------------- |
+| `ref`         | string | Docker MCP reference (`docker:name`)                             |
+| `tools`       | array  | Optional: only expose these tools                                |
+| `instruction` | string | Custom instructions injected into the agent's context            |
+| `config`      | any    | MCP server-specific configuration (passed during initialization) |
+| `working_dir` | string | Working directory for the MCP gateway subprocess. Only applies when the catalog entry runs as a local process (not remote). Relative paths are resolved against the agent's working directory. Supports `${env.VAR}` (canonical), plus `~` and shell-style `$VAR`/`${VAR}` expansion ([details](../overview/index.md#variable-expansion-in-config-fields)). |
+
+### Local MCP (stdio)
+
+Run MCP servers as local processes communicating over stdin/stdout:
+
+```yaml
+toolsets:
+  - type: mcp
+    command: python
+    args: ["-m", "mcp_server"]
+    tools: ["search", "fetch"]
+    env:
+      API_KEY: value
+```
+
+| Property | Type | Description |
+| --- | --- | --- |
+| `command` | string | Command to execute the MCP server |
+| `args` | array | Command arguments |
+| `tools` | array | Optional: only expose these tools |
+| `env` | object | Environment variables (key-value pairs) |
+| `working_dir` | string | Working directory for the MCP server process. Relative paths are resolved against the agent's working directory. Defaults to the agent's working directory when omitted. Supports `${env.VAR}` (canonical), plus `~` and shell-style `$VAR`/`${VAR}` expansion ([details](../overview/index.md#variable-expansion-in-config-fields)). |
+| `instruction` | string | Custom instructions injected into the agent's context |
+| `version` | string | Package reference for [auto-installing](#auto-installing-tools) the command binary |
+
+### Remote MCP (Streamable HTTP / SSE)
+
+Connect to MCP servers over the network:
+
+```yaml
+toolsets:
+  - type: mcp
+    remote:
+      url: "https://mcp-server.example.com"
+      transport_type: "streamable"
+      headers:
+        Authorization: "Bearer your-token"
+    # Optional: allow OAuth helper requests to reach private/internal IPs.
+    allow_private_ips: true
+    tools: ["search_web", "fetch_url"]
+```
+
+| Property                | Type    | Description                                                                                                           |
+| ----------------------- | ------- | --------------------------------------------------------------------------------------------------------------------- |
+| `remote.url`            | string  | URL of the MCP server. Accepts `https://`, `http://`, and `unix://` (Unix domain socket) schemes.                     |
+| `remote.transport_type` | string  | `streamable` or `sse`                                                                                                 |
+| `remote.headers`        | object  | HTTP headers sent on every request. Values support `${env.VAR}` and `${headers.NAME}` placeholders, resolved per request. `${env.VAR}` reads an environment variable; `${headers.NAME}` forwards a header from the caller's incoming request (useful when Docker Agent runs as an API server). |
+| `allow_private_ips`     | boolean | Permit remote MCP OAuth helper requests to dial non-public IP addresses. Use only for trusted internal servers.        |
+
+## Auto-Installing Tools
+
+When configuring MCP or LSP tools that require a binary command, Docker Agent can **automatically download and install** the command if it's not already available on your system. This uses the [aqua registry](https://github.com/aquaproj/aqua-registry) — a curated index of CLI tool packages.
+
+### How It Works
+
+1. When a toolset with a `command` is loaded, Docker Agent checks if the command is available in your `PATH`
+2. If not found, it checks the Docker Agent tools directory (`~/.cagent/tools/bin/`)
+3. If still not found, it looks up the command in the aqua registry and installs it automatically
+
+### Explicit Package Reference
+
+Use the `version` property to specify exactly which package to install:
+
+```yaml
+toolsets:
+  - type: mcp
+    command: gopls
+    version: "golang/tools@v0.21.0"
+    args: ["mcp"]
+  - type: lsp
+    command: rust-analyzer
+    version: "rust-lang/rust-analyzer@2024-01-01"
+    file_types: [".rs"]
+```
+
+The format is `owner/repo` or `owner/repo@version`. When a version is omitted, the latest release is used.
+
+### Automatic Detection
+
+If the `version` property is not set, Docker Agent tries to auto-detect the package from the command name by searching the aqua registry:
+
+```yaml
+toolsets:
+  - type: mcp
+    command: gopls  # auto-detected as golang/tools
+    args: ["mcp"]
+```
+
+### Checksum Verification
+
+Where the aqua registry includes a checksum manifest, downloaded binaries are verified against it before installation. Verification behaviour depends on the checksum type advertised:
+
+- **Strong checksums (sha256, sha512, etc.)** — verified before the binary is installed. If the downloaded archive does not match, the install is aborted and an error is returned (fails closed).
+- **Unsupported or weak checksum types (e.g. md5, sha1)** — skipped with a warning; installation proceeds without verification.
+- **No manifest** — if no checksum is advertised in the registry entry, the binary is installed without verification.
+
+### version_overrides Resolution
+
+The auto-installer correctly resolves **`version_overrides`** entries in the aqua registry. Many common tools (for example, `fzf`) keep their package configuration — including download URLs and checksums — under `version_overrides` rather than at the top level of their registry entry. These tools previously failed to install silently; they are now handled correctly.
+
+### Disabling Auto-Install
+
+**Per toolset** — set `version` to `"false"` or `"off"`:
+
+```yaml
+toolsets:
+  - type: mcp
+    command: my-custom-server
+    version: "false"
+```
+
+**Globally** — set the `DOCKER_AGENT_AUTO_INSTALL` environment variable:
+
+```bash
+export DOCKER_AGENT_AUTO_INSTALL=false
+```
+
+### Environment Variables
+
+| Variable                     | Default            | Description                                      |
+| ---------------------------- | ------------------ | ------------------------------------------------ |
+| `DOCKER_AGENT_AUTO_INSTALL`  | (enabled)          | Set to `false` to disable all auto-installation  |
+| `DOCKER_AGENT_TOOLS_DIR`     | `~/.cagent/tools/` | Base directory for installed tools               |
+| `GITHUB_TOKEN`               | —                  | GitHub token to raise API rate limits (optional) |
+
+Installed binaries are placed in `~/.cagent/tools/bin/` and cached so they are only downloaded once.
+
+> [!TIP]
+> Auto-install supports both Go packages (via `go install`) and GitHub release binaries (via archive download). The aqua registry metadata determines which method is used.
+
+## Toolset Lifecycle
+
+Long-running toolsets — local MCP servers (stdio), remote MCP servers (Streamable HTTP / SSE), and LSP servers — are managed by a single supervisor that can auto-reconnect them when they crash, time out, or drop their session. The `lifecycle` block on the toolset lets you tune that supervisor per toolset. It applies to every `type: mcp` and `type: lsp` toolset.
+
+The simplest knob is `profile`, which picks a preset:
+
+| Profile | Auto-restart | Use case |
+| --- | --- | --- |
+| `resilient` | Yes | Default. Exponential backoff on disconnect; the agent keeps running if the toolset is unavailable. Matches the historical Docker Agent behaviour. |
+| `strict` | No | Fail-fast. Marks the toolset as required. Intended for CI / headless runs where a missing dependency should be a hard error. |
+| `best-effort` | No | Single attempt, no retries. Good for experimental MCPs whose flakiness should not amplify into a restart loop. |
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:duckduckgo
+    lifecycle:
+      profile: resilient   # default; shown here for clarity
+
+  - type: lsp
+    command: gopls
+    file_types: [".go"]
+    lifecycle:
+      profile: strict
+
+  - type: mcp
+    ref: docker:openbnb-airbnb
+    lifecycle:
+      profile: best-effort
+```
+
+### Tuning the defaults
+
+Any field set on `lifecycle` overrides the profile preset, so you can mix-and-match: pick a profile and only override the knobs you care about.
+
+```yaml
+toolsets:
+  - type: mcp
+    command: ["docker", "mcp", "gateway"]
+    lifecycle:
+      profile: resilient
+      max_restarts: 10        # keep trying longer than the default of 5
+      backoff:
+        initial: 500ms
+        max: 1m
+        multiplier: 2
+        jitter: 0.2           # 20% random offset to avoid thundering-herd retries
+```
+
+| Property | Type | Description |
+| --- | --- | --- |
+| `profile` | string | One of `resilient` (default), `strict`, `best-effort`. Picks defaults for every other field. |
+| `restart` | string | When the supervisor should reconnect after a disconnect: `never`, `on_failure` (default), or `always`. For **remote** MCP toolsets (Streamable HTTP / SSE), `on_failure` is automatically promoted to `always` so idle-timeout closes reconnect gracefully — `never` is still honored. |
+| `max_restarts` | int | Maximum consecutive restart attempts before the toolset is marked `Failed`. `0` uses the profile default (5); `-1` means unlimited. |
+| `backoff.initial` | duration | First wait between attempts (Go duration: `500ms`, `1s`, …). Default: `1s`. |
+| `backoff.max` | duration | Cap on the wait between attempts. Default: `32s`. |
+| `backoff.multiplier` | number | Multiplier applied each attempt. Default: `2`. |
+| `backoff.jitter` | number | Fraction (0..1) of the computed delay applied as a uniform random offset. `0` disables jitter (default). |
+| `required` | boolean | Marks the toolset as critical. Today this is informational; a future eager-startup phase will refuse to start the agent when a required toolset cannot reach Ready. Defaults to `true` under `strict`, `false` otherwise. |
+| `startup_timeout` | duration | Cap on the initial connect+initialize duration. Enforced since v1.94.0: on expiry the toolset stays stopped and the runtime retries on the next turn. |
+| `call_timeout` | duration | Cap on an individual tool call, including one reconnect-retry. Enforced: on expiry the call is cancelled and surfaced to the model as a tool error; cancellation is propagated to the server. `0`/unset means no timeout — opt-in only, no profile default. |
+
+> [!NOTE]
+> **`required` is not yet enforced**
+>
+> The schema validates this field and the supervisor stores it, but no code path acts on it yet. It is documented now so config files written today keep working when the planned eager-startup phase lands. Picking the `strict` profile is forward-compatible — it will start enforcing `required=true` automatically.
+
+### Inspecting and restarting toolsets at runtime
+
+The TUI exposes the supervisor through two slash commands:
+
+- `/tools` — the unified tools dialog. Its top section lists every toolset on the current agent with its lifecycle state (`Stopped`, `Starting`, `Ready`, `Degraded`, `Restarting`, `Failed`), restart count, and last error; its bottom section lists every tool the agent can call, grouped by category. Use this to answer both "what can the agent do?" and "is anything degraded?" with one command.
+- `/toolset-restart <name>` — force the supervisor to reconnect the named toolset. Useful after completing OAuth, when a remote MCP server has been redeployed, or when an LSP like `gopls` is stuck.
+
+See the [TUI reference](../../features/tui/index.md) for the full list of slash commands.
+
+See [`examples/lifecycle.yaml`](https://github.com/docker/docker-agent/blob/main/examples/lifecycle.yaml) for a complete lifecycle configuration example.
+
+## TOON-Encoded Tool Outputs
+
+Many MCP servers return verbose JSON responses that consume a lot of context budget. The `toon` field on a toolset transparently re-encodes matching tools' JSON output as [TOON](https://github.com/alpkeskin/gotoon) — a compact, model-friendly key/value format — before the result is shown to the model.
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    toon: ".*"          # toonify every tool from this MCP server
+  - type: mcp
+    command: my-server
+    toon: "list_.*,get_.*" # only toonify list_/get_ tools
+```
+
+| Property | Type   | Description |
+| -------- | ------ | ----------- |
+| `toon`   | string | Comma-delimited list of regular expressions matching tool names whose JSON output should be re-encoded as TOON. Non-JSON outputs and non-matching tools are passed through untouched. |
+
+When a tool's output is not valid JSON, it is returned unchanged — TOON encoding is best-effort and never breaks tools that emit plain text.
+
+> [!NOTE]
+> **When to use TOON**
+>
+> TOON typically yields 30-60% smaller payloads than equivalent JSON for MCP tools that return arrays of records (issue lists, search results, file listings, …). It works best when the schema is regular; one-off responses with deeply nested or heterogeneous shapes may benefit less.
+
+## Per-Toolset Model Routing
+
+The `model` field on a toolset overrides which LLM is invoked for the **next turn** after a tool from that toolset returns — letting you process simple tool results (file reads, knowledge-base lookups, shell stdout) with a cheaper or faster model while keeping the agent's primary model for reasoning.
+
+```yaml
+models:
+  primary:
+    provider: anthropic
+    model: claude-sonnet-4-5
+  fast:
+    provider: anthropic
+    model: claude-haiku-4-5
+
+agents:
+  root:
+    model: primary
+    toolsets:
+      - type: filesystem
+        model: fast            # process file reads with the fast model
+      - type: shell
+        model: fast            # ditto for shell stdout
+      - type: mcp
+        ref: docker:github-official
+        model: openai/gpt-4o-mini  # inline provider/model also works
+```
+
+| Property | Type   | Description |
+| -------- | ------ | ----------- |
+| `model`  | string | Model used for the LLM turn that processes tool results from this toolset. Either a name from the `models:` section or an inline `provider/model` (e.g. `openai/gpt-4o-mini`). The override is **one-shot**: subsequent turns return to the agent's primary model. |
+
+When multiple tool calls in a single turn come from toolsets with different `model` overrides, the runtime picks the override of the **first** tool call that has one set. See [`examples/per_tool_model_routing.yaml`](https://github.com/docker/docker-agent/blob/main/examples/per_tool_model_routing.yaml) for a complete configuration.
+
+## Tool Filtering
+
+Toolsets may expose many tools. Use the `tools` property to whitelist only the ones your agent needs. This works for any toolset type — not just MCP:
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    tools: ["list_issues", "create_issue", "get_pull_request"]
+  - type: filesystem
+    tools: ["read_file", "search_files_content"]
+  - type: shell
+    tools: ["shell"]
+```
+
+> [!TIP]
+> Filtering tools improves agent performance — fewer tools means less confusion for the model about which tool to use.
+
+## Tool Instructions
+
+Add context-specific instructions that get injected when a toolset is loaded:
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    instruction: |
+      Use these tools to manage GitHub issues.
+      Always check for existing issues before creating new ones.
+      Label new issues with 'triage' by default.
+```
+
+By default, the `instruction:` field **replaces** the toolset's built-in instructions (if any). To keep the built-in guidance and add your own rules on top, include the `{ORIGINAL_INSTRUCTIONS}` placeholder anywhere in your instruction text. At runtime it expands to the toolset's default instructions:
+
+```yaml
+toolsets:
+  # Enrich: keep built-in instructions, then add your own rules
+  - type: filesystem
+    instruction: |
+      {ORIGINAL_INSTRUCTIONS}
+
+      ## Project-specific rules
+      - Never modify files outside the `src/` directory.
+      - Always create a backup before overwriting a file.
+
+  # Enrich: prepend your rules before the built-in instructions
+  - type: shell
+    instruction: |
+      Important: only run commands inside the project root.
+      {ORIGINAL_INSTRUCTIONS}
+
+  # Replace: omit the placeholder to discard built-in instructions entirely
+  - type: mcp
+    ref: docker:github-official
+    instruction: |
+      Only read GitHub issues. Never create, edit, or close anything.
+```
+
+Three patterns at a glance:
+
+| Pattern | Description |
+| --- | --- |
+| `{ORIGINAL_INSTRUCTIONS}` then your text | Append your rules after the defaults |
+| Your text then `{ORIGINAL_INSTRUCTIONS}` | Prepend your rules before the defaults |
+| No placeholder | Replace the defaults entirely |
+
+See [`examples/toolset_instructions.yaml`](https://github.com/docker/docker-agent/blob/main/examples/toolset_instructions.yaml) for a complete example.
+
+## Deferred Tool Loading
+
+Load tools on-demand to speed up agent startup. When a toolset is deferred, its tools are registered lazily — the tool server process is not started until the agent first calls one of its tools. This is useful for large toolsets (e.g., an MCP server with hundreds of tools) where startup time matters.
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    defer: true
+  - type: mcp
+    ref: docker:slack
+    defer: true
+  - type: filesystem
+```
+
+Or defer specific tools within a toolset:
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    defer:
+      - "list_issues"
+      - "search_repos"
+```
+
+When `defer` is a list of tool names, only those specific tools are deferred; all other tools in the toolset load eagerly. Setting `defer: true` defers the entire toolset.
+
+### Tool Discovery with `search_tool`
+
+When an entire toolset is deferred (`defer: true`), the deferred toolset exposes two built-in tools to the agent:
+
+- **`search_tool`** — Discover available deferred tools by keyword. The search uses **fuzzy matching** against both tool names and descriptions: all characters of the query must appear in the target string in order (but not necessarily adjacently), so a query like `"crfil"` matches `"create_file"`. Returns a list of matching tool names with descriptions.
+- **`add_tool`** — Activate a discovered tool by name so it becomes available for use.
+
+These tools let the agent browse a large toolset on-demand without activating every tool upfront.
+
+See [`examples/deferred.yaml`](https://github.com/docker/docker-agent/blob/main/examples/deferred.yaml) for a complete example.
+
+## Combined Example
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Full-featured developer assistant
+    instruction: You are an expert developer.
+    toolsets:
+      # Built-in tools
+      - type: filesystem
+      - type: shell
+      - type: think
+      - type: todo
+      - type: memory
+        path: ./dev.db
+      - type: user_prompt
+      # LSP for code intelligence
+      - type: lsp
+        command: gopls
+        file_types: [".go"]
+      # Custom scripts
+      - type: script
+        shell:
+          run_tests:
+            description: Run the test suite
+            cmd: task test
+          lint:
+            description: Run the linter
+            cmd: task lint
+      # Custom API tool
+      - type: api
+        api_config:
+          name: get_status
+          method: GET
+          endpoint: "https://api.example.com/status"
+          instruction: Check service health
+      # Docker MCP tools
+      - type: mcp
+        ref: docker:github-official
+        tools: ["list_issues", "create_issue"]
+      - type: mcp
+        ref: docker:duckduckgo
+      # Remote MCP
+      - type: mcp
+        remote:
+          url: "https://internal-api.example.com/mcp"
+          transport_type: "streamable"
+          headers:
+            Authorization: "Bearer ${env.INTERNAL_TOKEN}"
+```
+
+> [!WARNING]
+> **Toolset Order Matters**
+>
+> If multiple toolsets provide a tool with the same name, the first one wins. Order your toolsets intentionally.
diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/user-settings/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/user-settings/index.md
new file mode 100644
index 000000000000..92a050df6d03
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/configuration/user-settings/index.md
@@ -0,0 +1,134 @@
+---
+title: "User Settings"
+description: "Full reference for the global settings block in ~/.config/cagent/config.yaml: theme, layout, YOLO, sound, snapshots, permissions, hooks, keybindings, and how they interact with agent config and CLI flags."
+keywords: docker agent, ai agents, configuration, yaml, user settings, user config
+linkTitle: "User Settings"
+weight: 110
+canonical: https://docs.docker.com/ai/docker-agent/configuration/user-settings/
+---
+
+_Full reference for the global settings block in your user config file._
+
+## Where Settings Live
+
+Docker Agent reads a single user-level config file, independent of any agent YAML:
+
+```text
+~/.config/cagent/config.yaml
+```
+
+The `settings:` block inside it holds preferences that apply to every agent you run — appearance, behavior, notifications, and a few global safety defaults. Everything under `settings:` is optional; an unset field falls back to the documented default.
+
+```yaml
+# ~/.config/cagent/config.yaml
+settings:
+  theme: dracula
+  lean: false
+  sound: true
+```
+
+You rarely need to hand-edit this file. Most fields are managed from the TUI's `/settings` dialog (**Appearance**, **Behavior**, **Notifications** tabs) — press <kbd>Enter</kbd> there to apply and persist a change. A few fields (`permissions`, `hooks`, `keybindings`) have no dialog UI and are only set by editing the file directly.
+
+> [!NOTE]
+> This page documents `settings:`. The user config file also has top-level sections outside `settings:` — `aliases:`, `providers:`, `board:`, `credential_helper:`, `sandbox_allowlist:` — which are not covered here.
+
+## Settings Reference
+
+| Setting | Type | Default | Description |
+| --- | --- | --- | --- |
+| `hide_tool_results` | boolean | `false` | Hide tool call results in the TUI by default. Mirrors the `--hide-tool-results` flag and the <kbd>Ctrl</kbd>+<kbd>O</kbd> toggle. |
+| `expand_thinking` | boolean | `false` | Start new sessions with thinking/tool blocks expanded instead of collapsed. |
+| `split_diff_view` | boolean | `true` | Render file-edit diffs side-by-side instead of unified. |
+| `render_images` | boolean | `true` | Render images in the TUI using the Kitty graphics protocol. Applies to both tool-result images and Markdown images in agent responses. Automatically disabled when the terminal does not support Kitty. |
+| `theme` | string | `default` | Theme name, loaded from a built-in theme or `~/.cagent/themes/<name>.yaml`. The special value `auto` follows the terminal's light/dark background. See [Theming](../../features/tui/index.md#theming). |
+| `theme_dark` | string | `default` | Theme applied when `theme: auto` and the terminal background is dark. |
+| `theme_light` | string | `default-light` | Theme applied when `theme: auto` and the terminal background is light. |
+| `YOLO` | boolean | `false` | Auto-approve all tool calls globally, across every agent you run. Mirrors the `--yolo` flag and the `/yolo` command. Legacy alias for `safety: autonomous`; when both are set, `safety` wins. |
+| `safety` | string | _unset_ | Default [safety mode](../permissions/index.md#safety-modes) for new sessions: `strict`, `balanced`, `restricted`, or `autonomous` (any other value fails config loading). Wins over the legacy `YOLO` flag. Applied when no explicit `--safety`/`--yolo` flag and no alias safety option was given; wins over the agent YAML's `agents.<name>.safety` / `runtime.safety` defaults. Never changes the mode of a resumed session. |
+| `lean` | boolean | `false` | Make the [lean TUI](../../features/tui/index.md#lean-tui) (simplified, minimal-chrome interface) the default for interactive runs instead of the full TUI. |
+| `tab_title_max_length` | int | `20` | Maximum display length for tab titles; longer titles are truncated with an ellipsis. |
+| `restore_tabs` | boolean | `false` | Restore previously open tabs when launching the TUI. |
+| `sound` | boolean | `false` | Play a notification sound on task success or failure. |
+| `sound_threshold` | int | `10` | Minimum duration in seconds a task must run before a success sound plays (failures always play). |
+| `snapshot` | boolean | `false` | Enable automatic shadow-git snapshots at turn boundaries globally. See [Snapshots](../../features/snapshots/index.md). |
+| `cache_stable_prompts` | boolean | `false` | Keep changing trusted context (date, environment info, dynamic prompt files) out of the frozen system prefix and append chronological updates instead, improving prompt-cache hit rates on long sessions. |
+| `warn_on_cache_miss` | boolean | `false` | Warn when a model call after the first one in a session reports no cached input tokens (a prompt-cache miss). Managed from the **Notifications** tab of `/settings`. |
+| `busy_send_mode` | string | `steer` | What happens to a message sent while the agent is working: `steer` injects it into the ongoing stream; `queue` holds it until the current turn ends. |
+| `interrupt_confirmation` | string | `always` | Controls how the <kbd>Esc</kbd> key interrupts a running stream: `always` (default) shows a confirmation dialog; `double-tap` requires pressing <kbd>Esc</kbd> twice within 1 second; `none` interrupts immediately without confirmation. Managed from the **Behavior** tab of `/settings`. |
+| `permissions` | object | _unset_ | Global tool-permission rules (`allow` / `ask` / `deny`), merged with agent-level and session-level permissions. See [Permissions](../permissions/index.md#global-permissions). |
+| `hooks` | object | _unset_ | Global lifecycle hooks applied to every agent, additive with agent-config and CLI hooks. See [Global (user-level) hooks](../hooks/index.md#global-user-level-hooks). |
+| `keybindings` | array | _unset_ | Remap TUI keyboard shortcuts. See [Custom Keybindings](../../features/tui/index.md#custom-keybindings) for the full list of actions and syntax. |
+| `layout` | object | _unset_ | Sidebar position and section visibility. See [Layout Settings](#layout-settings) below. |
+
+## Layout Settings
+
+`layout` customizes the TUI's sidebar. The zero value (an omitted `layout:` block, or any field left out) is the default: sidebar on the right, every section visible, normal spacing.
+
+| Field | Type | Default | Description |
+| --- | --- | --- | --- |
+| `sidebar_position` | string | `right` | `right`, `left`, `top`, or `bottom`. Left/right keep a full vertical sidebar; top/bottom render a compact horizontal band. |
+| `section_spacing` | string | `normal` | `compact`, `normal`, or `relaxed` — the number of blank lines between sidebar sections. |
+| `hide_session_path` | boolean | `false` | Hide the working-directory (session path) line, including its git branch. |
+| `hide_usage` | boolean | `false` | Hide the token-usage section. |
+| `hide_agents` | boolean | `false` | Hide the Agents section. |
+| `active_agents_only` | boolean | `false` | Show only agents active in the current session in the Agents section (and the top/bottom band), instead of the whole configured team. Ignored while the Agents section is hidden. |
+| `hide_tools` | boolean | `false` | Hide the Tools section. |
+| `hide_todos` | boolean | `false` | Hide the Todos section. |
+
+```yaml
+settings:
+  layout:
+    sidebar_position: left
+    section_spacing: compact
+    hide_usage: true
+```
+
+## Complete Example
+
+```yaml
+# ~/.config/cagent/config.yaml
+settings:
+  theme: auto
+  theme_dark: dracula
+  theme_light: default-light
+  lean: false
+  expand_thinking: false
+  split_diff_view: true
+  render_images: true
+  hide_tool_results: false
+  sound: true
+  sound_threshold: 10
+  snapshot: true
+  cache_stable_prompts: true
+  warn_on_cache_miss: true
+  busy_send_mode: queue
+  interrupt_confirmation: double-tap
+  restore_tabs: true
+  tab_title_max_length: 24
+  layout:
+    sidebar_position: right
+    section_spacing: normal
+  permissions:
+    deny:
+      - "shell:cmd=sudo*"
+    allow:
+      - "read_*"
+  hooks:
+    session_start:
+      - type: command
+        command: "~/.config/cagent/hooks/session-start.sh"
+  keybindings:
+    - action: "commands"
+      keys: ["f2", "ctrl+k"]
+```
+
+## Precedence Rules
+
+User settings are a **low-priority** source: they establish defaults, and anything more specific wins.
+
+- **CLI flags over user settings — except plain boolean flags going from `true` to `false`.** Where a `docker agent run` flag mirrors a setting, passing the flag for a specific run takes precedence over the setting for that run only, and the flag never modifies the saved user config file. This holds cleanly for `--lean` / `lean`, `--theme` / `theme`, and the safety flags `--safety` / `--yolo` (see below), which track whether the flag was explicitly passed on the command line. `--hide-tool-results` / `hide_tool_results` doesn't: it's a plain boolean with no "was this explicitly set" tracking, so passing `--hide-tool-results=false` cannot turn a saved `hide_tool_results: true` setting off for that run — the saved `true` wins and is reapplied on top of the flag. Passing the flag to turn it *on* works as expected regardless of the saved setting.
+- **Safety has its own, fully-specified chain.** For a **new** session the first source in this order wins: explicit `--safety` flag > explicit `--yolo` flag > alias `safety`/`yolo` option > `settings.safety`/`settings.YOLO` > the agent YAML's `agents.<name>.safety` > the agent YAML's `runtime.safety` > the built-in default (read-only tools auto-approve, everything else asks). At each scope the `safety` field wins over the legacy `YOLO`/`yolo` boolean. Your settings therefore beat anything an agent author declared in YAML — an agent config loaded from a file, URL, or OCI registry can never override your `settings.safety`, alias option, or CLI flag. An explicit `--yolo=false` suppresses a saved `YOLO: true` / alias `yolo` for that run (other settings and YAML defaults still apply). **Resumed sessions keep their stored mode**: settings and alias defaults never touch them; only an explicit `--safety` or `--yolo` flag overrides a resume. See [Safety Modes](../permissions/index.md#safety-modes).
+- **Aliases sit between CLI flags and user settings.** An [alias](../../features/cli/index.md#docker-agent-alias) (`docker agent alias add ...`) can bundle its own `yolo`, `safety`, `model`, `hide_tool_results`, and `sandbox` defaults; those apply when the corresponding flag was not explicitly passed, the same way user settings do, but are resolved after user settings so an alias's own choices take priority over your global defaults.
+- **Permissions are merged, not overridden.** Global `settings.permissions` and an agent's own `permissions:` are combined into a single set of `deny` → `allow` → `ask` patterns before evaluation — a global deny always blocks, regardless of what the agent config allows. See [Merging Behavior](../permissions/index.md#merging-behavior).
+- **Hooks are additive, not overridden.** For a given lifecycle event, hooks from the agent config, `settings.hooks`, `hooks.d/` drop-ins, and `--hook-*` CLI flags **all** run, in that order. Global hooks cannot be suppressed by an individual agent.
+- **Everything else is a plain default.** Fields with no CLI or agent-config equivalent (`sound`, `sound_threshold`, `restore_tabs`, `tab_title_max_length`, `split_diff_view`, `render_images`, `cache_stable_prompts`, `warn_on_cache_miss`, `busy_send_mode`, `keybindings`, `layout`) only ever come from `settings:` (or the `/settings` dialog that writes it) — there is nothing to override them per run.
diff --git a/_vendor/github.com/docker/docker-agent/docs/demo.gif b/_vendor/github.com/docker/docker-agent/docs/demo.gif
new file mode 100644
index 000000000000..03d4bfc0ec7a
Binary files /dev/null and b/_vendor/github.com/docker/docker-agent/docs/demo.gif differ
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/_index.md b/_vendor/github.com/docker/docker-agent/docs/features/_index.md
new file mode 100644
index 000000000000..70959847b98c
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Features"
+description: "Interfaces and features: TUI, CLI, API server, protocols, and more."
+weight: 50
+---
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/a2a/index.md b/_vendor/github.com/docker/docker-agent/docs/features/a2a/index.md
new file mode 100644
index 000000000000..a09f5b006536
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/a2a/index.md
@@ -0,0 +1,106 @@
+---
+title: "A2A Protocol"
+description: "Expose Docker Agent agents via Google's Agent-to-Agent (A2A) protocol for interoperability with other agent frameworks."
+keywords: docker agent, ai agents, features, a2a protocol
+weight: 60
+canonical: https://docs.docker.com/ai/docker-agent/features/a2a/
+aliases:
+  - /ai/docker-agent/integrations/a2a/
+---
+
+_Expose Docker Agent agents via Google's Agent-to-Agent (A2A) protocol for interoperability with other agent frameworks._
+
+## Overview
+
+The `docker agent serve a2a` command starts an A2A server that exposes your agents using the [A2A protocol](https://a2a-protocol.org/latest/). This enables communication between Docker Agent and other agent frameworks that support A2A.
+
+> [!WARNING]
+> **Early support**
+>
+> A2A support is functional but still evolving. Tool calls, artifacts, and memory features have limited A2A integration. See limitations below.
+
+## Usage
+
+```bash
+# Start A2A server for an agent
+$ docker agent serve a2a ./agent.yaml
+
+# Specify a custom address
+$ docker agent serve a2a ./agent.yaml --listen 127.0.0.1:9000
+
+# Use an agent from an OCI registry
+$ docker agent serve a2a myorg/agent:tag
+```
+
+## Flags
+
+| Flag                              | Default          | Description                                                                                                          |
+| --------------------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------- |
+| `-l, --listen <addr>`             | `127.0.0.1:8082` | Address to listen on.                                                                                                |
+| `-a, --agent <name>`              | (first agent)    | Name of the agent to expose when the config contains multiple agents. Defaults to the team's first agent.            |
+| `-s, --session-db <path>`         | `<data-dir>/session.db` | Path to the SQLite session database.                                                                          |
+| `--working-dir <path>`            | current dir      | Working directory the agent runs in.                                                                                 |
+| `--env-from-file <file>`          | (none)           | Load additional environment variables from a `.env` file (repeatable).                                               |
+| `--models-gateway <url>`          | (none)           | Route all provider traffic through a models gateway URL.                                                             |
+| `--code-mode-tools`               | `false`          | Expose tools as a single "code" toolset that accepts a JavaScript snippet to run.                                    |
+| `--hook-pre-tool-use <cmd>`       | (none)           | Add a pre-tool-use hook (repeatable). See [Hooks](../../configuration/hooks/index.md).                     |
+| `--hook-post-tool-use <cmd>`      | (none)           | Add a post-tool-use hook (repeatable).                                                                               |
+| `--hook-session-start <cmd>`      | (none)           | Add a session-start hook (repeatable).                                                                               |
+| `--hook-session-end <cmd>`        | (none)           | Add a session-end hook (repeatable).                                                                                 |
+| `--hook-on-user-input <cmd>`      | (none)           | Add an on-user-input hook (repeatable).                                                                              |
+| `--hook-stop <cmd>`               | (none)           | Add a stop hook, fired when the model finishes responding (repeatable).                                              |
+| `--auth-token <token>`            | (none)           | Bearer token required for agent-card and invocation requests.                                                        |
+| `--cors-origin <origins>`          | (none)           | Allowed browser origins, comma-separated; empty disables CORS.                                                       |
+| `--insecure-no-auth`              | `false`          | Allow an unauthenticated non-loopback listener (unsafe).                                                             |
+| `--safety <policy>`               | `restricted`     | Tool safety policy; `autonomous` is permitted only through this explicit CLI flag.                                   |
+
+## Authentication and network exposure
+
+Loopback listeners may run without authentication. Non-loopback listeners require
+`--auth-token` unless `--insecure-no-auth` explicitly acknowledges the exposure.
+Clients must send `Authorization: Bearer <token>` for both agent-card discovery
+and JSON-RPC invocation. Configure browser access with `--cors-origin`; it accepts
+comma-separated literal origins or `~`-prefixed regular expressions and permits
+credentials only for matching origins.
+
+```bash
+$ docker agent serve a2a ./agent.yaml --auth-token "$A2A_TOKEN" \
+    --cors-origin http://localhost:3000
+```
+
+## Tool safety and migration
+
+A2A sessions default to the `restricted` tool safety policy. Precedence is the
+`--safety` flag, then agent YAML, then runtime YAML. YAML may select `strict`,
+`balanced`, or `restricted`; `safety: autonomous` stops startup and directs the
+operator to `--safety autonomous`. That CLI flag is the only deliberate opt-in
+to autonomous tool execution.
+
+Existing deployments should choose an explicit policy before upgrading. Migration
+027 labels pre-existing sessions as `run`, so they cannot be resumed through
+`/invoke`; clients must start new A2A contexts. An A2A context ID that collides
+with another session is rejected without changing that session.
+
+Downgrading to a binary that predates migration 027 fails because the session
+database has a newer schema (`ErrNewerDatabase`). Restore an older database, or
+use a binary that includes the migration. Revert changes without removing the
+migration catalogue entry.
+
+## Features
+
+- **Auto port selection** — Picks an available port if not specified
+- **Agent card** — Provides standard A2A agent metadata
+- **Full Docker Agent features** — Supports all tools, models, and gateway features
+- **Multiple sources** — Load agents from files or OCI registries
+
+> [!TIP]
+> **See also**
+>
+> For exposing agents via MCP instead, see [MCP Mode](../mcp-mode/index.md). For stdio-based integration, see [ACP](../acp/index.md). For the HTTP API, see [API Server](../api-server/index.md).
+
+## Current Limitations
+
+- Tool calls are handled internally, not exposed as separate A2A events
+- A2A artifact support not yet integrated
+- A2A memory features not yet integrated
+- Multi-agent (sub-agent) scenarios need further work
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/acp/index.md b/_vendor/github.com/docker/docker-agent/docs/features/acp/index.md
new file mode 100644
index 000000000000..52b6dff515ef
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/acp/index.md
@@ -0,0 +1,117 @@
+---
+title: "ACP (Agent Client Protocol)"
+description: "Expose Docker Agent agents via the Agent Client Protocol for integration with ACP-compatible hosts like VS Code, IDEs, and other developer tools."
+keywords: docker agent, ai agents, features, acp (agent client protocol)
+linkTitle: "ACP"
+weight: 70
+canonical: https://docs.docker.com/ai/docker-agent/features/acp/
+aliases:
+  - /ai/docker-agent/integrations/acp/
+---
+
+_Expose Docker Agent agents via the Agent Client Protocol for integration with ACP-compatible hosts like VS Code, IDEs, and other developer tools._
+
+## Overview
+
+The `docker agent serve acp` command starts an ACP server that communicates over **stdio** (standard input/output). This makes it ideal for integration with editors, IDEs, and other tools that spawn agent processes — the host sends JSON-RPC messages to Docker Agent's stdin and reads responses from stdout.
+
+ACP is built on the [ACP Go SDK](https://github.com/coder/acp-go-sdk) and provides a standardized way for client applications to interact with AI agents.
+
+> [!NOTE]
+> **ACP vs A2A vs MCP**
+>
+> **ACP** connects an agent to a *host application* (IDE, CLI tool) via stdio. **A2A** connects *agents to other agents* over HTTP. **MCP** exposes agents as *tools* for other MCP clients. Choose based on your integration target.
+
+## Usage
+
+```bash
+# Start ACP server on stdio
+$ docker agent serve acp ./agent.yaml
+
+# With a multi-agent team config
+$ docker agent serve acp ./team.yaml
+
+# From an OCI registry
+$ docker agent serve acp myorg/agent:tag
+
+# With a custom session database
+$ docker agent serve acp ./agent.yaml --session-db ./my-sessions.db
+```
+
+## How It Works
+
+1. The host application spawns `docker agent serve acp agent.yaml` as a child process
+2. Communication happens over **stdin/stdout** using the ACP protocol
+3. The host sends user messages, Docker Agent processes them through the agent
+4. Agent responses, tool calls, and events stream back to the host
+5. Sessions are persisted in a SQLite database for continuity
+
+```bash
+# Conceptual flow:
+Host Application
+  └── spawns: docker agent serve acp agent.yaml
+        ├── stdin  ← JSON-RPC requests from host
+        └── stdout → JSON-RPC responses to host
+```
+
+## Features
+
+- **Stdio transport** — No network ports needed; ideal for subprocess integration
+- **Session persistence** — SQLite-backed sessions survive process restarts
+- **Full agent support** — All Docker Agent features work: tools, multi-agent, model fallbacks
+- **Multi-agent configs** — Team configurations with sub-agents work transparently
+- **Filesystem operations** — Agents can read/write files relative to the host's working directory
+
+## CLI Flags
+
+```bash
+docker agent serve acp <agent-file>|<registry-ref> [flags]
+```
+
+| Flag                              | Default                | Description                                                                                                          |
+| --------------------------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------- |
+| `-s, --session-db <path>`         | `<data-dir>/session.db` | Path to the SQLite session database.                                                                                 |
+| `--working-dir <path>`            | current dir            | Working directory the agent runs in.                                                                                 |
+| `--env-from-file <file>`          | (none)                 | Load additional environment variables from a `.env` file (repeatable).                                               |
+| `--models-gateway <url>`          | (none)                 | Route all provider traffic through a models gateway URL.                                                             |
+| `--code-mode-tools`               | `false`                | Expose tools as a single "code" toolset that accepts a JavaScript snippet to run.                                    |
+| `--hook-pre-tool-use <cmd>`       | (none)                 | Add a pre-tool-use hook (repeatable). See [Hooks](../../configuration/hooks/index.md).                     |
+| `--hook-post-tool-use <cmd>`      | (none)                 | Add a post-tool-use hook (repeatable).                                                                               |
+| `--hook-session-start <cmd>`      | (none)                 | Add a session-start hook (repeatable).                                                                               |
+| `--hook-session-end <cmd>`        | (none)                 | Add a session-end hook (repeatable).                                                                                 |
+| `--hook-on-user-input <cmd>`      | (none)                 | Add an on-user-input hook (repeatable).                                                                              |
+| `--hook-stop <cmd>`               | (none)                 | Add a stop hook, fired when the model finishes responding (repeatable).                                              |
+
+## Integration Example
+
+A host application would spawn Docker Agent as a subprocess and communicate via the ACP protocol:
+
+```javascript
+// Pseudocode for an IDE extension
+const child = spawn("docker", ["agent", "serve", "acp", "./agent.yaml"]);
+
+// Send a message to the agent
+child.stdin.write(
+  JSON.stringify({
+    jsonrpc: "2.0",
+    method: "agent/run",
+    params: { message: "Explain this code" },
+  }),
+);
+
+// Read responses
+child.stdout.on("data", (data) => {
+  const response = JSON.parse(data);
+  // Handle agent response, tool calls, etc.
+});
+```
+
+> [!TIP]
+> **When to use ACP**
+>
+> Use ACP when building **IDE integrations**, **editor plugins**, or any tool that wants to embed a Docker Agent agent as a subprocess. For HTTP-based integrations, use the [API Server](../api-server/index.md) instead.
+
+> [!NOTE]
+> **See also**
+>
+> For HTTP-based agent access, see the [API Server](../api-server/index.md). For agent-to-agent communication, see [A2A Protocol](../a2a/index.md). For exposing agents as MCP tools, see [MCP Mode](../mcp-mode/index.md).
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/api-server/index.md b/_vendor/github.com/docker/docker-agent/docs/features/api-server/index.md
new file mode 100644
index 000000000000..2c1bc999702c
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/api-server/index.md
@@ -0,0 +1,394 @@
+---
+title: "API Server"
+description: "Expose your agents via an HTTP API for programmatic access, web frontends, and integrations."
+keywords: docker agent, ai agents, features, api server
+weight: 80
+canonical: https://docs.docker.com/ai/docker-agent/features/api-server/
+---
+
+_Expose your agents via an HTTP API for programmatic access, web frontends, and integrations._
+
+## Overview
+
+The `docker agent serve api` command starts an HTTP server that exposes your agents through a REST-style API with Server-Sent Events (SSE) streaming. Use it to build web UIs, integrate with CI/CD pipelines, or connect agents to other services.
+
+```bash
+# Start the API server
+$ docker agent serve api agent.yaml
+
+# Custom listen address
+$ docker agent serve api agent.yaml --listen 0.0.0.0:8080
+
+# With session persistence
+$ docker agent serve api agent.yaml --session-db ./sessions.db
+
+# Auto-refresh from OCI registry every 10 minutes
+$ docker agent serve api myorg/coder --pull-interval 10
+```
+
+> [!TIP]
+> **When to use API server vs. chat server**
+>
+> Use the **API server** when you want full control over sessions, agent execution, tool-call confirmations, and streamed runtime events — this is Docker Agent's native protocol. Use the [Chat Server](../chat-server/index.md) when you want to plug Docker Agent into existing OpenAI-compatible tooling (chat UIs, IDE integrations, OpenAI SDK clients) instead.
+
+## Endpoints
+
+All endpoints are under the `/api` prefix.
+
+### Agents
+
+| Method | Path              | Description                       |
+| ------ | ----------------- | --------------------------------- |
+| `GET`  | `/api/agents`     | List all available agents         |
+| `GET`  | `/api/agents/:id` | Get an agent's full configuration |
+
+Each agent entry in the `GET /api/agents` response contains:
+
+| Field        | Type            | Description                                                                                   |
+| ------------ | --------------- | --------------------------------------------------------------------------------------------- |
+| `name`       | string          | Agent identifier (config filename without `.yaml`).                                           |
+| `description`| string          | The root agent's `description` field.                                                         |
+| `multi`      | boolean         | `true` when the config defines more than one agent.                                           |
+| `commands`   | array of string | Sorted list of named command keys defined on the root agent. Omitted when no commands exist.  |
+
+### Sessions
+
+| Method   | Path                                | Description                                             |
+| -------- | ----------------------------------- | ------------------------------------------------------- |
+| `GET`    | `/api/sessions`                     | List all sessions                                       |
+| `POST`   | `/api/sessions`                     | Create a new session. Accepts an optional `title` field — when set, it is stored and LLM title generation is skipped. |
+| `GET`    | `/api/sessions/:id`                 | Get a session by ID (messages, tokens, permissions)     |
+| `GET`    | `/api/sessions/:id/status`          | Lightweight runtime state (streaming, title, agent, tokens). Requires an attached runtime. |
+| `GET`    | `/api/sessions/:id/snapshot`        | Full state in one call (stored fields + runtime state + `last_event_seq`) for gapless resync — see [Reconnecting without gaps](#reconnecting-without-gaps). |
+| `GET`    | `/api/sessions/:id/events`          | Live session event stream (SSE) with sequence numbers and replay. Available for a run attached via [`--listen`](#listen), or once a session has raised at least one out-of-band event (e.g. a background job's elicitation, answered via `POST .../elicitation`), which creates a session-scoped event log on demand carrying such out-of-band events — see [Session event stream](#session-event-stream-and-reconnection) for what each kind of log contains. |
+| `DELETE` | `/api/sessions/:id`                 | Delete a session                                        |
+| `PATCH`  | `/api/sessions/:id/title`           | Update session title                                    |
+| `PATCH`  | `/api/sessions/:id/permissions`     | Update session permissions                              |
+| `POST`   | `/api/sessions/:id/fork`            | Fork a session at a user message — creates a new session with messages `[0, message_index)` of the parent (see [Session Forking](#session-forking)) |
+| `POST`   | `/api/sessions/:id/messages`        | Append a message directly to a session's history (bypasses the model). Returns `409 Conflict` while the session has an active run (see [Agent Execution](#agent-execution)). |
+| `PATCH`  | `/api/sessions/:id/messages/:msg_id` | Update an existing message by ID. Returns `409 Conflict` while the session has an active run. |
+| `POST`   | `/api/sessions/:id/resume`          | Resume a paused session (after tool confirmation)       |
+| `POST`   | `/api/sessions/:id/tools/toggle`    | Toggle auto-approve (YOLO) mode                         |
+| `POST`   | `/api/sessions/:id/elicitation`     | Respond to an MCP tool elicitation request. Pass the `elicitation_id` from the `elicitation_request` event to target a specific concurrent request; omitted, it resolves the sole pending one. |
+| `POST`   | `/api/sessions/:id/steer`           | Inject messages into a running turn (pre-empts current) |
+| `POST`   | `/api/sessions/:id/followup`        | Enqueue messages to run after the current turn finishes (supports an `Idempotency-Key` — see [Idempotent follow-ups](#idempotent-follow-ups)). |
+| `GET`    | `/api/sessions/:id/models`          | List available models for the session's current agent   |
+
+### Agent Execution
+
+| Method | Path                                       | Description                                                                          |
+| ------ | ------------------------------------------ | ------------------------------------------------------------------------------------ |
+| `POST` | `/api/sessions/:id/agent/:agent`           | Run the root agent for a session (SSE stream)                                        |
+| `POST` | `/api/sessions/:id/agent/:agent/:name`     | Run a specific named agent (SSE stream)                                              |
+| `GET`  | `/api/agents/:id/:agent_name/tools/count`  | Count tools currently available to `:agent_name` (accounts for deferred toolsets).   |
+
+**Path parameters:**
+
+- **`:agent`** — The agent identifier, which is the **config filename without the `.yaml` extension**. This must match the filename passed to `docker agent serve api`. For example, if you start the server with `docker agent serve api my-assistant.yaml`, the agent identifier is `my-assistant`. When serving a directory of YAML files, each file becomes a separate agent identified by its filename without the extension.
+- **`:name`** _(optional)_ — The name of a specific sub-agent defined in a multi-agent configuration. If omitted, the request targets the `root` agent. For example, in a config that defines agents named `root`, `coder`, and `reviewer`, use `/api/sessions/:id/agent/my-config/coder` to run the `coder` sub-agent directly.
+
+**Examples:**
+
+```bash
+# Single-agent config: my-assistant.yaml
+# Start: docker agent serve api my-assistant.yaml
+# Run the root agent:
+curl -N -X POST http://localhost:8080/api/sessions/$SID/agent/my-assistant \
+  -H "Content-Type: application/json" \
+  -d '{"messages":[{"role": "user", "content": "Hello!"}]}'
+
+# Multi-agent config: team.yaml (defines agents: root, coder, reviewer)
+# Start: docker agent serve api team.yaml
+# Run the root agent:
+curl -N -X POST http://localhost:8080/api/sessions/$SID/agent/team \
+  -H "Content-Type: application/json" \
+  -d '{"messages":[{"role": "user", "content": "Review this PR"}]}'
+
+# Run a specific sub-agent (reviewer):
+curl -N -X POST http://localhost:8080/api/sessions/$SID/agent/team/reviewer \
+  -H "Content-Type: application/json" \
+  -d '{"messages":[{"role": "user", "content": "Review this PR"}]}'
+```
+
+### Health
+
+| Method | Path        | Description                               |
+| ------ | ----------- | ----------------------------------------- |
+| `GET`  | `/api/ping` | Health check — returns `{"status": "ok"}` |
+
+### OAuth
+
+| Method | Path                     | Description                                                                                                                                                                                                                                          |
+| ------ | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `POST` | `/api/mcp-oauth/callback` | Deliver an OAuth deeplink callback to a pending unmanaged OAuth flow. Success path: `?state=<state>&code=<code>`; authorization-server error path: `?state=<state>&error=<error>&error_description=<desc>`. Returns 400 if `state` is missing or neither `code` nor `error` is provided; 404 if no flow is awaiting that `state`. See [Remote MCP OAuth](../remote-mcp/index.md) for details. |
+
+## Streaming Responses
+
+The agent execution endpoints (`POST /api/sessions/:id/agent/:agent`) return **Server-Sent Events (SSE)**. The request body is a JSON object with a `messages` array and an optional `model` field. Setting `model` applies a persistent per-agent override on the session before the turn starts (subsequent turns reuse it). An empty or omitted `model` leaves the existing override untouched. (Each event is a JSON object representing a runtime event — remember that `:agent` is the config filename without the `.yaml` extension.):
+
+```bash
+# Send a message and stream the response
+# (assuming the server was started with: docker agent serve api my-agent.yaml)
+$ curl -N -X POST http://localhost:8080/api/sessions/$SID/agent/my-agent \
+  -H "Content-Type: application/json" \
+  -d '{"messages":[{"role": "user", "content": "Hello!"}]}'
+
+# Same call, but switch the agent's model for this turn (and persist it):
+$ curl -N -X POST http://localhost:8080/api/sessions/$SID/agent/my-agent \
+  -H "Content-Type: application/json" \
+  -d '{"messages":[{"role":"user","content":"Hello!"}],"model":"openai/gpt-4o"}'
+
+# Response (SSE stream):
+data: {"type":"stream_started","session_id":"...","agent":"root"}
+data: {"type":"agent_choice","content":"Hello! How","agent":"root"}
+data: {"type":"agent_choice","content":" can I help","agent":"root"}
+data: {"type":"agent_choice","content":" you today?","agent":"root"}
+data: {"type":"stream_stopped","session_id":"...","agent":"root"}
+```
+
+Event types include:
+
+- `stream_started` / `stream_stopped` — Agent execution lifecycle
+- `agent_choice` — Streamed text content (partial responses)
+- `tool_call` — Agent requesting tool execution
+- `tool_call_confirmation` — Tool call waiting for user approval
+- `tool_call_response` — Tool execution result
+- `plan_changed` — A shared plan was created, updated, or deleted through the plan toolset. The payload carries the plan's `scope`, `name`, `action`, and `version` — never its content. Shared plans are deliberately process-global: every active stream served by the same process subscribes to the same shared plan notifier and receives the event regardless of which session performed the mutation, and the payload does not identify the mutating session (read the plan's `author` metadata for collaborative attribution).
+- `error` — Error during execution
+
+## Typical Workflow
+
+1. **List agents** — `GET /api/agents` to discover available agents
+2. **Create session** — `POST /api/sessions` to start a conversation
+3. **Send message** — `POST /api/sessions/:id/agent/:agent` with user messages
+4. **Stream response** — Read SSE events as the agent processes
+5. **Handle confirmations** — If a tool call needs approval, `POST /api/sessions/:id/resume`
+6. **Continue** — Send follow-up messages to the same session
+
+```bash
+# 1. List available agents
+$ curl http://localhost:8080/api/agents
+[{"name":"my-agent","multi":false,"description":"A helpful assistant","commands":["deploy","review"]}]
+
+# 2. Create a session
+$ curl -X POST http://localhost:8080/api/sessions \
+  -H "Content-Type: application/json" -d '{}'
+{"id":"abc-123","title":"","created_at":"..."}
+
+# Create a session with a pre-supplied title (skips LLM title generation)
+$ curl -X POST http://localhost:8080/api/sessions \
+  -H "Content-Type: application/json" -d '{"title":"deploy check"}'
+{"id":"def-456","title":"deploy check","created_at":"..."}
+# title preserved; LLM title generation skipped
+
+# 3. Run the agent with a message
+$ curl -N -X POST http://localhost:8080/api/sessions/abc-123/agent/my-agent \
+  -H "Content-Type: application/json" \
+  -d '{"messages":[{"role":"user","content":"What files are in the current directory?"}]}'
+```
+
+## CLI Flags
+
+```bash
+docker agent serve api <agent-file>|<agents-dir> [flags]
+```
+
+| Flag               | Default          | Description                                      |
+| ------------------ | ---------------- | ------------------------------------------------ |
+| `-l, --listen`     | `127.0.0.1:8080` | Address to listen on                             |
+| `--auth-token`     | (none)           | Bearer token required for all API requests. Leave empty to disable authentication (safe when listening on loopback interfaces only). Recommended when `--listen` binds to a network-reachable interface. |
+| `--max-request-size <bytes>` | `1048576` (1 MiB) | Maximum request body size in bytes. Requests whose body exceeds this limit are rejected with HTTP 413 (Request Entity Too Large) — see [Troubleshooting: HTTP 413](../../community/troubleshooting/index.md#http-413-request-body-too-large) if you hit this. |
+| `--session-workingdir-root` | (none — unrestricted) | Confine the `working_dir` accepted by `POST /api/sessions` to this directory: after resolving symlinks, the requested directory must be the root or one of its descendants. By default any clean host directory is accepted — the intended behaviour for local single-user daemons that open arbitrary workspaces — but raw values containing `..` are always rejected. Set a root whenever the API serves callers that must not reach arbitrary host paths (multi-user or network-exposed deployments). |
+| `-s, --session-db` | `session.db`     | Path to the SQLite session database              |
+| `--pull-interval`  | `0` (disabled)   | Auto-pull OCI reference every N minutes          |
+| `--fake`           | (none)           | Replay AI responses from cassette file (testing) |
+| `--record`         | (none)           | Record AI API interactions to cassette file. Routes through `--models-gateway` when one is configured. |
+| `--mcp-oauth-redirect-uri` | (none)   | Public HTTPS URL advertised as the OAuth `redirect_uri` for unmanaged MCP OAuth flows. When set, Docker Agent drives PKCE and code exchange in-process and sends the full authorize URL to the client via elicitation. See [Remote MCP](../remote-mcp/index.md) for details. |
+
+> [!NOTE]
+> **What `--max-request-size` does and doesn't cover**
+>
+> This is a finite, process-wide cap on one serialized inbound HTTP request body — it isn't a model context-window limit, and raising it doesn't increase what a provider/model accepts or how large a local attachment/prompt file can be. A larger cap also means the server buffers more memory per request from an unauthenticated or malicious client, so weigh that against your deployment's exposure. If a reverse proxy or gateway sits in front of this server, it may enforce its own, lower cap regardless of this flag. See [Troubleshooting: HTTP 413](../../community/troubleshooting/index.md#http-413-request-body-too-large) for full diagnosis.
+
+> [!TIP]
+> **Live profiling (advanced)**
+>
+> For production diagnostics, set the `CAGENT_PPROF_ADDR` environment variable (or the hidden `--pprof-addr` flag) to a TCP address such as `127.0.0.1:6060`. Docker Agent will start a Go pprof HTTP server at `/debug/pprof/`, which you can query with `go tool pprof`. Use a loopback address — a non-loopback binding logs a security warning. This flag is intentionally hidden from `--help`.
+
+> [!TIP]
+> **Multi-agent configs**
+>
+> You can point `docker agent serve api` at a directory containing multiple agent YAML files. Each becomes a separate agent accessible via `/api/agents`. Combine with `--pull-interval` to auto-refresh agents from an OCI registry.
+
+## Session Persistence
+
+Sessions are stored in a SQLite database (default: `session.db` in the current directory). This means:
+
+- Sessions survive server restarts
+- Multiple server instances can share a database
+- Use `--session-db` to specify a custom path
+
+## Tool Call Approval
+
+By default, tool calls require approval. In the API workflow:
+
+1. Agent makes a tool call → server emits a `tool_call_confirmation` event
+2. Client reviews and sends `POST /api/sessions/:id/resume` with the decision
+3. Execution continues based on approval/denial
+
+Toggle auto-approve with `POST /api/sessions/:id/tools/toggle` for automated workflows.
+
+## Driving a running TUI with `--listen` {#listen}
+
+The same session API can be exposed by an **interactive run** so an external
+process can drive it — send follow-up prompts, observe progress, read the
+title — without scraping the terminal. Start a normal run and add `--listen`:
+
+```bash
+# Expose this run's control plane on a TCP port...
+$ docker agent run agent.yaml --listen 127.0.0.1:8080
+
+# ...or on a unix socket (no port to allocate; access is gated by file
+# permissions). npipe:// (Windows) and fd:// are also accepted.
+$ docker agent run agent.yaml --listen unix:///tmp/my-run.sock
+```
+
+The run keeps its interactive TUI; the control plane runs alongside it. A
+follow-up delivered over HTTP is processed exactly as if it had been typed
+into the TUI: it starts a turn even when the agent is idle, generates the
+session title on the first turn, and streams the resulting events to both the
+terminal and every connected API client.
+
+```bash
+# Send a follow-up to the attached run (SID is the --session id):
+$ curl -X POST http://127.0.0.1:8080/api/sessions/$SID/followup \
+    -H 'Content-Type: application/json' \
+    -d '{"messages":[{"content":"Now add tests"}]}'
+```
+
+> [!NOTE]
+> **Discovering a run**
+>
+> Each run started with `--listen` writes a discovery record to `<data-dir>/runs/<pid>.json` containing its address and session id, so a supervising process can find a live run by session id, pid, or address.
+
+> [!WARNING]
+> **This control plane has a fixed 1 MiB request-body cap and no built-in authentication**
+>
+> Unlike the standalone `docker agent serve api` process above, an attached run's `--listen` control plane exposes neither `--max-request-size` nor `--auth-token`: every request is capped at a fixed, non-configurable 1 MiB body (returning HTTP 413 above it — see [Troubleshooting: HTTP 413](../../community/troubleshooting/index.md#http-413-request-body-too-large)), and there is no bearer token to require. If you need a configurable cap, built-in bearer auth, or a network-reachable listener, run a standalone `docker agent serve api` deployment instead. Otherwise, keep `--listen` on loopback, a unix socket, or behind an authenticating reverse proxy.
+
+## Session event stream and reconnection
+
+`GET /api/sessions/:id/events` is a **Server-Sent Events** stream of the
+session's runtime events — `stream_started`, `agent_choice`, `tool_call`,
+`session_title`, `token_usage`, `stream_stopped`, and so on. Unlike the
+per-request stream returned by the agent-execution endpoint, it is
+session-scoped and survives across turns, so a client can watch a session for
+its whole lifetime. It is available for a run attached via
+[`--listen`](#listen), and — since a session-scoped event log is created on
+demand the first time a session raises an out-of-band event, such as an
+`elicitation_request` from a background job — for any API-created session
+that has produced at least one (see the
+[Sessions endpoint table](#sessions) above). The two kinds of log differ in
+coverage: a `--listen` run feeds its full runtime event stream into the log,
+while an on-demand log for an API-created session carries the session's
+out-of-band events — not necessarily all ordinary turn events, which flow on
+the per-request SSE stream of the [agent-execution](#agent-execution)
+request that runs the turn.
+
+Each event carries a monotonic **sequence number** in the SSE `id:` field, and
+the server buffers recent events. This makes the stream resumable:
+
+- **Resume after a drop** — reconnect with the standard `Last-Event-ID` header
+  (sent automatically by browser `EventSource` clients) or a `?since=<seq>`
+  query parameter. Buffered events newer than that point are replayed before
+  live tailing resumes, so nothing is missed.
+- **Gap signal** — if the resume point has already fallen out of the buffer, the
+  server sends a single `{"type":"gap"}` event (with no id) before the replay.
+  The client should re-fetch the snapshot to resync, then continue tailing.
+- **End of session** — when the session is ended server-side (for example via
+  `DELETE /api/sessions/:id`) the server sends a terminal
+  `{"type":"session_exited"}` event and closes the stream; a client that
+  receives it should stop. A stream that closes **without** `session_exited` is
+  a dropped connection — including the run process itself exiting — so reconnect
+  with the last id; if the run is gone the reconnection simply fails.
+
+### Reconnecting without gaps
+
+`GET /api/sessions/:id/snapshot` returns the session's full state in one
+response — stored fields (messages, tokens, permissions), live runtime state
+(`streaming`, current `agent`), and `last_event_seq`: the sequence number of
+the most recent event. Pair it with the event stream for an exact, gapless
+resync:
+
+```bash
+# 1. Read the full state and the stream position it corresponds to.
+$ SEQ=$(curl -s http://127.0.0.1:8080/api/sessions/$SID/snapshot | jq .last_event_seq)
+
+# 2. Tail everything that happens after that point (replaying anything that
+#    occurred between the two calls).
+$ curl -N "http://127.0.0.1:8080/api/sessions/$SID/events?since=$SEQ"
+```
+
+This snapshot-then-tail pattern lets a client (or a client that just
+restarted) rebuild a session's state and keep it correct without polling.
+
+### Waiting for readiness
+
+`GET /api/sessions/:id/status` reports a session's runtime state. Add
+`?wait=<duration>` (e.g. `?wait=10s`) to block until that specific session's
+runtime is attached and ready to accept follow-ups, then return its status, or
+`503` on timeout. This is session-scoped, unlike `GET /api/ready`, which fires
+as soon as any session is ready.
+
+## Session Forking
+
+`POST /api/sessions/:id/fork` creates a new session whose history is a copy of the parent up to (but **excluding**) a specified user message. This lets a client "branch" a conversation — e.g. rewind to an earlier question and try a different prompt — without losing the shared history that came before.
+
+**Request body:**
+
+```json
+{ "user_message_index": 1 }
+```
+
+`user_message_index` is a **0-based ordinal** that counts only user-role messages in the parent's flat, user-visible message list. The targeted user message is **excluded** from the fork so clients can prefill it into their chat input for the user to edit and resubmit.
+
+**Example:**
+
+```bash
+# Fork a session before the second user message (ordinal 1)
+$ curl -X POST http://localhost:8080/api/sessions/$SID/fork \
+  -H 'Content-Type: application/json' \
+  -d '{"user_message_index": 1}'
+# Returns: api.SessionResponse for the new forked session
+# New session title: "<parent title> (fork 1)", "(fork 2)", etc.
+```
+
+**Validation:**
+
+- Out-of-range ordinals (negative, or at/past the user-message count) return `400 Bad Request`.
+- An ordinal that resolves to a user message inside a sub-session returns `400 Bad Request`. A sub-session is a nested session created when a multi-agent config delegates work to a child agent; its messages are embedded within the parent session's message list and cannot be used as a fork boundary.
+
+## Idempotent follow-ups
+
+`POST /api/sessions/:id/followup` accepts an optional `Idempotency-Key`
+header, making the request safe to retry after a network timeout. A repeat
+with a key already seen for the session is acknowledged without delivering the
+follow-up again:
+
+```bash
+$ curl -X POST http://127.0.0.1:8080/api/sessions/$SID/followup \
+    -H 'Content-Type: application/json' \
+    -H 'Idempotency-Key: 7f3a-...' \
+    -d '{"messages":[{"content":"Ship it"}]}'
+# => {"status":"queued_streaming","duplicate":false}
+# A retry with the same key => {"status":"duplicate","duplicate":true}
+```
+
+The response `status` is `queued_streaming` (a turn is running or starting),
+`queued_idle` (delivered to an idle headless session, runs on the next turn),
+or `duplicate`.
+
+> [!NOTE]
+> **See also**
+>
+> For interactive use, see the [Terminal UI](../tui/index.md). For agent-to-agent communication, see [A2A Protocol](../a2a/index.md) and [ACP](../acp/index.md). For MCP integration, see [MCP Mode](../mcp-mode/index.md). For an OpenAI-compatible chat-completions API, see the [Chat Server](../chat-server/index.md).
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/board/index.md b/_vendor/github.com/docker/docker-agent/docs/features/board/index.md
new file mode 100644
index 000000000000..176966a7e59c
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/board/index.md
@@ -0,0 +1,97 @@
+---
+title: "Kanban Board"
+description: "Orchestrate multiple agents from a Kanban TUI: each card runs an agent in a tmux session on an isolated git worktree."
+keywords: docker agent, ai agents, features, board, kanban, orchestration
+linkTitle: "Kanban Board"
+weight: 15
+canonical: https://docs.docker.com/ai/docker-agent/features/board/
+---
+
+_Board is a Kanban TUI for orchestrating agents. Each card launches an agent
+in a tmux session on an isolated git worktree, and moving a card forward
+through the pipeline sends the destination column's prompt to its agent._
+
+## Launching the board
+
+```bash
+$ docker agent board
+```
+
+Requirements: `tmux` and `git` must be installed.
+
+## How it works
+
+- **Cards run agents.** Creating a card (`n`) launches `docker agent run` in
+  a dedicated tmux session, working in a fresh git worktree branched from the
+  project's upstream default branch. The card's title, running/idle status,
+  and failures are mirrored live from the agent's control plane.
+- **Startup phases.** While an agent is coming up its card moves through three
+  intermediate statuses before reaching **running**: `starting` (tmux session
+  created, process booting, no worktree yet) → `loading` (worktree present;
+  agent loading config, models, and tools) → `attaching` (control-plane socket
+  bound; board waiting for the first snapshot).
+- **Columns are a pipeline.** The default pipeline is
+  Dev → Review → Push → Done, and it's fully customizable: manage columns
+  from the board (`c`) or in the config file. Moving a card forward (`]`)
+  sends the destination column's prompt to the card's agent; moving it back
+  (`[`) sends nothing.
+- **Attach anytime.** Press `enter` (or double-click a card) to attach your
+  terminal to the agent's session and interact with it directly; `ctrl+q`
+  detaches and returns to the board.
+- **Everything is recoverable.** Quitting the board leaves agents running in
+  tmux; restarting it reattaches to them. If an agent process dies, the board
+  relaunches it and resumes the same conversation and worktree. An agent that
+  keeps crashing at startup turns its card red instead of relaunching
+  forever: attach to it (`enter`) to read the error output, then move the
+  card forward to relaunch it, or delete it.
+
+## Key bindings
+
+| Key           | Action                                              |
+| ------------- | --------------------------------------------------- |
+| `n`           | Create a card (project + prompt)                    |
+| `enter`       | Attach to the card's agent (`ctrl+q` detaches)      |
+| `d`           | View the card's worktree diff                       |
+| `o`           | Open the card's worktree in `$DOCKER_AGENT_BOARD_EDITOR` (`code`) |
+| `s`           | Open an interactive shell in the card's worktree    |
+| `[` / `]`     | Move the card back / forward                        |
+| `1`-`9`       | Move the card to column N                           |
+| `x`           | Delete the card, its session, worktree, and branch  |
+| `p`           | Manage projects (add, edit, reorder, remove)        |
+| `c`           | Manage columns (add, edit, reorder, remove)         |
+| `e`           | Edit the selected column's prompt                   |
+| `←↓↑→` `hjkl` | Navigate                                            |
+| mouse         | Click selects, double-click attaches, drag moves, wheel scrolls |
+| `?`           | Help                                                |
+| `q`           | Quit (agents keep running)                          |
+
+## Configuration
+
+Everything is configured in the global config file
+(`~/.config/cagent/config.yaml`) or through the TUI itself (`p` for projects,
+`c` for columns, `e` for column prompts):
+
+```yaml
+board:
+  projects:
+    - name: my-app
+      path: /Users/me/src/my-app
+      agent: coder # any agent ref; defaults to the built-in agent
+  columns:
+    - id: dev
+      name: Dev
+      emoji: 🔨
+    - id: review
+      name: Review
+      emoji: 🔍
+      prompt: Review the local changes and fix any issues you find.
+    - id: done
+      name: Done
+      emoji: ✅
+```
+
+Omitting `columns` keeps the default pipeline. Column `id`s identify a
+column across renames (cards remember the column they are in by id); when
+omitted, the id is derived from the column's name. When a card enters a
+column with a `prompt`, that prompt is delivered to the card's agent as its
+next message.
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/chat-server/index.md b/_vendor/github.com/docker/docker-agent/docs/features/chat-server/index.md
new file mode 100644
index 000000000000..6b9957568064
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/chat-server/index.md
@@ -0,0 +1,255 @@
+---
+title: "Chat Server"
+description: "Expose your agents through an OpenAI-compatible Chat Completions API so any tool that already speaks OpenAI can drive a Docker Agent agent."
+keywords: docker agent, ai agents, features, chat server
+weight: 90
+canonical: https://docs.docker.com/ai/docker-agent/features/chat-server/
+---
+
+_Expose your agents through an OpenAI-compatible Chat Completions API so any tool that already speaks OpenAI can drive a Docker Agent agent._
+
+## Overview
+
+The `docker agent serve chat` command starts an HTTP server that exposes one or
+more agents through an **OpenAI-compatible Chat Completions API** at
+`/v1/chat/completions` and `/v1/models`. Any client that already speaks the
+OpenAI protocol — for example
+[Open WebUI](https://github.com/open-webui/open-webui), `curl`, the OpenAI
+Python SDK, or LangChain — can drive a Docker Agent agent without any custom
+integration.
+
+```bash
+# Single agent — exposed as the model `root`
+$ docker agent serve chat agent.yaml
+
+# Multi-agent config — every agent in the team becomes a model
+$ docker agent serve chat ./team.yaml
+
+# Pick a specific agent from a multi-agent config
+$ docker agent serve chat ./team.yaml --agent reviewer
+
+# Run an agent straight from the registry
+$ docker agent serve chat myorg/agent:tag --listen 127.0.0.1:9090
+
+# Require a Bearer token, sourced from an env var
+$ docker agent serve chat agent.yaml --api-key-env CHAT_BEARER_TOKEN
+```
+
+> [!TIP]
+> **When to use chat server vs. API server**
+>
+> Use the **chat server** when you want to plug Docker Agent into existing OpenAI-compatible tooling (chat UIs, IDE integrations, OpenAI SDK clients). Use the [API server](../api-server/index.md) when you want full control over sessions, agent execution, tool-call confirmations, and streamed runtime events.
+
+## Endpoints
+
+The OpenAI-compatible endpoints live under the `/v1` prefix to match the
+OpenAI API surface. The OpenAPI specification is served at the top level so it
+can be discovered without authentication.
+
+| Method | Path                   | Description                                                            |
+| ------ | ---------------------- | ---------------------------------------------------------------------- |
+| `GET`  | `/v1/models`           | List the agents that this server exposes as models                     |
+| `POST` | `/v1/chat/completions` | Send messages and receive a completion (regular or streaming)          |
+| `GET`  | `/openapi.json`        | OpenAPI specification for the chat server                              |
+
+The model identifier in `POST /v1/chat/completions` is the **agent name**.
+For a single-agent config that's typically `root`; for a multi-agent config,
+each named agent becomes its own selectable model.
+
+## Quick Start
+
+```bash
+# 1. Start the server
+$ docker agent serve chat agent.yaml
+Listening on 127.0.0.1:8083
+OpenAI-compatible chat completions endpoint: http://127.0.0.1:8083/v1/chat/completions
+
+# 2. List exposed agents (models)
+$ curl http://127.0.0.1:8083/v1/models
+{"object":"list","data":[{"id":"root","object":"model","owned_by":"docker-agent"}]}
+
+# 3. Send a chat request
+$ curl http://127.0.0.1:8083/v1/chat/completions \
+    -H 'Content-Type: application/json' \
+    -d '{
+      "model": "root",
+      "messages": [{"role": "user", "content": "Hello!"}]
+    }'
+```
+
+### Streaming
+
+Set `"stream": true` in the request body to receive a Server-Sent Events
+(SSE) stream of OpenAI-format `chat.completion.chunk` deltas:
+
+```bash
+$ curl -N http://127.0.0.1:8083/v1/chat/completions \
+    -H 'Content-Type: application/json' \
+    -d '{
+      "model": "root",
+      "stream": true,
+      "messages": [{"role": "user", "content": "Stream a poem"}]
+    }'
+```
+
+### Drive it from the OpenAI Python SDK
+
+Because the wire format is OpenAI-compatible, point any OpenAI client at the
+chat server's `base_url` and use the agent name as the model:
+
+```python
+from openai import OpenAI
+
+client = OpenAI(
+    base_url="http://127.0.0.1:8083/v1",
+    api_key="not-needed-when-no-api-key-flag",  # required by the SDK, ignored if no auth
+)
+
+resp = client.chat.completions.create(
+    model="root",
+    messages=[{"role": "user", "content": "Hello!"}],
+)
+print(resp.choices[0].message.content)
+```
+
+## Server-side Conversation Caching
+
+By default the server is **stateless**: every request must contain the full
+message history, exactly like OpenAI's API. Enable server-side caching by
+setting `--conversations-max` to a positive value, then send a stable
+`X-Conversation-Id` header on each request:
+
+```bash
+$ docker agent serve chat agent.yaml --conversations-max 100 --conversation-ttl 30m
+```
+
+```bash
+$ curl http://127.0.0.1:8083/v1/chat/completions \
+    -H 'Content-Type: application/json' \
+    -H 'X-Conversation-Id: my-thread-1' \
+    -d '{
+      "model": "root",
+      "messages": [{"role": "user", "content": "Remember my name is Alice"}]
+    }'
+
+$ curl http://127.0.0.1:8083/v1/chat/completions \
+    -H 'Content-Type: application/json' \
+    -H 'X-Conversation-Id: my-thread-1' \
+    -d '{
+      "model": "root",
+      "messages": [{"role": "user", "content": "What is my name?"}]
+    }'
+```
+
+Cached conversations are evicted after `--conversation-ttl` of inactivity, or
+when the cache hits `--conversations-max` items (oldest entries are evicted
+first).
+
+### Failure-safe caching
+
+When a request fails — for example because the model returns an error or the `--request-timeout` expires — the conversation cache is **not updated**. The server clones the cached session before processing each request and only commits the updated session when the turn completes successfully. This means:
+
+- A failed turn leaves the conversation in the same state it was before the request.
+- Clients can safely retry with the same `X-Conversation-Id` after a failure.
+- Transient errors do not corrupt the conversation history.
+
+## Authentication
+
+The chat server defaults to loopback binding. A non-loopback `--listen` address requires `--api-key`, `--api-key-env`, or the explicit `--insecure-no-auth` override. An environment variable selected by `--api-key-env` must be set and non-empty.
+
+To require a Bearer
+token, pass `--api-key` (literal value) or `--api-key-env` (name of an
+environment variable that holds the value):
+
+```bash
+$ docker agent serve chat agent.yaml --api-key-env CHAT_BEARER_TOKEN
+```
+
+Clients must then send an `Authorization: Bearer <token>` header on every
+request to `/v1/*`. Both `/v1/models` and `/v1/chat/completions` are
+protected once a key is set.
+
+> [!WARNING]
+> **Public exposure**
+>
+> The default listen address is `127.0.0.1:8083`. Non-loopback binding is rejected unless `--api-key`, `--api-key-env`, or `--insecure-no-auth` is supplied. Use the insecure override only behind a trusted authentication boundary.
+
+## Tool safety
+
+The chat server resolves its safety policy in this order: `--safety`, agent configuration, runtime configuration, then `restricted`. Cached conversations retain the more restrictive of their prior policy and the server policy, so a continuation cannot regain permissions after the server policy becomes stricter.
+
+## CORS
+
+CORS is **disabled by default**. To allow a browser-based client to call the
+server, set `--cors-origin` to the exact origin (scheme + host + port) that
+should be allowed:
+
+```bash
+$ docker agent serve chat agent.yaml --cors-origin https://my-ui.example.com
+```
+
+## CLI Flags
+
+```bash
+docker agent serve chat <agent-file>|<registry-ref> [flags]
+```
+
+| Flag                          | Default            | Description                                                                                                       |
+| ----------------------------- | ------------------ | ----------------------------------------------------------------------------------------------------------------- |
+| `-a, --agent <name>`          | (all agents)       | Name of the agent to expose. If omitted, every agent in the config is exposed as a separate model.                |
+| `-l, --listen <addr>`         | `127.0.0.1:8083`   | Address to listen on.                                                                                             |
+| `--cors-origin <origin>`      | (none)             | Allowed CORS origin (e.g. `https://example.com`). Empty disables CORS.                                            |
+| `--api-key <token>`           | (none)             | Required Bearer token clients must present (`Authorization: Bearer <token>`). Empty disables auth.                |
+| `--api-key-env <name>`        | (none)             | Read the required API key from this non-empty environment variable.                                               |
+| `--insecure-no-auth`          | `false`            | Permit unauthenticated non-loopback binding. Use only behind a trusted authentication boundary.                  |
+| `--safety <policy>`           | `restricted`       | Tool safety policy. CLI value overrides agent/runtime configuration.                                               |
+| `--max-request-size <bytes>`  | `1048576` (1 MiB)  | Maximum request body size in bytes. Requests whose body exceeds this limit are rejected with HTTP 413 (Request Entity Too Large) — see [Troubleshooting: HTTP 413](../../community/troubleshooting/index.md#http-413-request-body-too-large) if you hit this. |
+| `--request-timeout <dur>`     | `5m`               | Per-request timeout (covers model + tool calls + streaming).                                                      |
+| `--conversations-max <n>`     | `0`                | Cache up to N conversations server-side, keyed by `X-Conversation-Id`. `0` disables — clients must resend history. |
+| `--conversation-ttl <dur>`    | `30m`              | Idle TTL after which a cached conversation is evicted.                                                            |
+| `--max-idle-runtimes <n>`     | `4`                | Maximum number of idle runtimes pooled per agent. `0` disables pooling.                                           |
+
+All [runtime configuration flags](../cli/index.md#runtime-configuration-flags)
+(`--working-dir`, `--env-from-file`, `--models-gateway`, `--hook-*`, …) are
+also accepted.
+
+> [!NOTE]
+> **What `--max-request-size` does and doesn't cover**
+>
+> This is a finite, process-wide cap on one serialized inbound HTTP request body — it isn't a model context-window limit, and raising it doesn't increase what a provider/model accepts or how large a local attachment/prompt file can be. A larger cap also means the server buffers more memory per request from an unauthenticated or malicious client, so weigh that against your deployment's exposure. If a reverse proxy or gateway sits in front of this server, it may enforce its own, lower cap regardless of this flag. See [Troubleshooting: HTTP 413](../../community/troubleshooting/index.md#http-413-request-body-too-large) for full diagnosis.
+
+## Image Inputs
+
+Messages can include OpenAI-style `image_url` content parts alongside `text`:
+
+```json
+{"type": "image_url", "image_url": {"url": "data:image/png;base64,..."}}
+```
+
+A `data:` URL embeds the image bytes directly in the JSON body, so its base64-encoded size counts toward `--max-request-size` above like any other request content. A remote `http(s)://` URL is passed through to the selected model provider rather than fetched by the chat server itself — whether it works depends on that provider and model: some accept a remote URL directly, others only accept `data:` URLs, and a provider/model without image support drops the part. Don't assume a remote image URL will be fetched or rendered universally; verify against the specific provider/model you've configured.
+
+## Open WebUI Integration
+
+Open WebUI can talk to any OpenAI-compatible endpoint. To plug Docker Agent
+in:
+
+1. Start the chat server, optionally with auth:
+
+    ```bash
+    $ docker agent serve chat agent.yaml \
+        --listen 127.0.0.1:8083 \
+        --cors-origin http://localhost:3000 \
+        --api-key-env OPEN_WEBUI_TOKEN
+    ```
+
+2. In Open WebUI, add an OpenAI-compatible connection:
+
+    - **API Base URL:** `http://127.0.0.1:8083/v1`
+    - **API Key:** the value of `OPEN_WEBUI_TOKEN`
+
+3. Each agent in your config appears as a selectable model.
+
+> [!NOTE]
+> **See also**
+>
+> For the Docker Agent–native HTTP API (sessions, tool-call confirmation, runtime events), see the [API Server](../api-server/index.md). For full CLI flag documentation, see the [CLI Reference](../cli/index.md#docker-agent-serve-chat).
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/cli/index.md b/_vendor/github.com/docker/docker-agent/docs/features/cli/index.md
new file mode 100644
index 000000000000..41db671d409d
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/cli/index.md
@@ -0,0 +1,840 @@
+---
+title: "CLI Reference"
+description: "Complete reference for all Docker Agent command-line commands and flags."
+keywords: docker agent, ai agents, features, cli reference
+weight: 30
+canonical: https://docs.docker.com/ai/docker-agent/features/cli/
+aliases:
+  - /ai/docker-agent/reference/cli/
+---
+
+_Complete reference for all Docker Agent command-line commands and flags._
+
+> [!TIP]
+> **No config needed**
+>
+> Running `docker agent run` without a config argument uses `docker-agent.yaml`, `docker-agent.yml`, or `docker-agent.hcl` from the current directory when present. Otherwise, it uses a built-in default agent that is perfect for quick experimentation.
+
+## Commands
+
+### `docker agent run`
+
+Launch the interactive TUI with an agent configuration (`.yaml`, `.yml`, or `.hcl`).
+
+```bash
+$ docker agent run [config] [message...] [flags]
+```
+
+| Flag                                    | Description                                                                                                                               |
+| --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `-a, --agent <name>`                    | Run a specific agent from the config                                                                                                      |
+| `--yolo`                                | Auto-approve tool calls (unless explicitly denied). Legacy alias for `--safety autonomous`.                                              |
+| `--safety <mode>`                       | Safety mode for tool approval: `strict` (ask for everything), `balanced` (auto-approve safe calls), `restricted` (auto-approve safe calls, deny the rest — fail-closed for unattended runs), or `autonomous` (approve everything). Wins over `--yolo` when both are given. Without the flag, the mode falls back to alias/user-config defaults, then the agent YAML's `agents.<name>.safety` / `runtime.safety`; a resumed session keeps its stored mode unless `--safety`/`--yolo` is passed explicitly. See [Safety Modes](../../configuration/permissions/index.md#safety-modes). |
+| `--model <ref>`                         | Override model(s). Use `provider/model` for all agents, or `agent=provider/model` for specific agents. Comma-separate multiple overrides. |
+| `--session <id>`                        | Resume a previous session. Supports relative refs (`-1` = newest by creation time, `-2` = second-newest, … — creation order, not last-used). An explicit ID that does not exist yet is created with that ID, so a supervisor can own the session ID upfront and reuse it across runs. |
+| `-s, --session-db <path>`               | Path to the SQLite session database (default: `<data-dir>/session.db`, so `~/.cagent/session.db` unless `--data-dir` is set)              |
+| `--session-read-only`                   | Open the TUI in read-only mode: conversation history is displayed but no new messages can be sent to the LLM. Cannot be used with `--exec`. |
+| `--prompt-file <path>`                  | Include file contents as additional system context (repeatable)                                                                           |
+| `--attach <path>`                       | Attach an image file to the initial message                                                                                               |
+| `--dry-run`                             | Initialize the agent without executing anything (useful for validating a config)                                                          |
+| `--remote <addr>`                       | Use a remote runtime at the given address instead of running the agent locally. Mutually exclusive with `--sandbox`, `--worktree`, `--worktree-pr`, `--worktree-base`, `--session`, `--session-db`, `--record`, and `--fake` — a remote runtime owns its own session storage and execution environment, so these local-only concerns don't apply. |
+| `--listen <addr>`                       | Expose this run's control plane over HTTP so an external process can drive the running TUI (send follow-ups, stream events, read the title). Accepts `host:port` or `unix://`, `npipe://`, `fd://`. Hidden from `docker agent run --help` — like `debug`, it's a stable but advanced/automation-oriented flag rather than a day-to-day one. See the [API Server](../api-server/index.md#listen) guide for the full walkthrough. |
+| `--session-workingdir-root <path>`      | Confine the `working_dir` of sessions created through the `--listen` control plane to this directory and its descendants (default: no restriction — any clean host directory is accepted, though raw values containing `..` are rejected). Recommended when the control plane is reachable by other users. Hidden from `--help`, like `--listen`. |
+| `--lean`                                | Use a simplified, non-alternate-screen TUI. Unlike the default full-screen TUI, this renders inline in the normal terminal buffer — useful in environments where an alternate screen is unwanted (e.g. inside tmux panes, CI with a tty, or log-friendly pipelines). Like the full TUI, displays an ASCII art banner on startup when the chat is empty. |
+| `--app-name <name>`                     | Override the application name label shown in the TUI (status bar, window title, "/exit" notifications).                                   |
+| `--sidebar`                             | Control sidebar visibility. Set to `--sidebar=false` to hide the sidebar and disable the Ctrl+B toggle (default: `true`).                 |
+| `--disable-commands <list>`             | Hide and disable specific slash commands in the TUI. Accepts a comma-separated list of command names (leading slash optional, case-insensitive). E.g. `--disable-commands="/cost,/eval,/model"`. |
+| `--theme <name>`                        | Preselect a TUI theme by name, or `auto` to follow the terminal's light/dark background (overrides the theme from user config; ignored outside the interactive TUI) |
+| `--on-event <type>=<cmd>`               | Run a shell command when an event of the given type fires (`*=<cmd>` matches any event). Repeatable.                                      |
+| `--json`                                | Output results as newline-delimited JSON (use with `--exec`)                                                                              |
+| `--hide-tool-calls`                     | Hide tool calls in the output                                                                                                             |
+| `--hide-tool-results`                   | Hide tool call results in the output                                                                                                      |
+| `--sandbox`                             | Run the agent in sandbox mode using `sbx` (see [Sandbox](../../configuration/sandbox/index.md))                                 |
+| `--template <image>`                    | Template image for the sandbox (default: `docker/docker-agent-sbx-templates:latest`)                                                      |
+| `--no-kit`                              | Disable the [auto-kit](../../configuration/sandbox/index.md#auto-kit): do not stage skills or prompt files into the sandbox    |
+| `--agent-picker [refs]`                 | Show a full-screen interactive picker before launching, letting you browse and select an agent. Accepts an optional comma-separated list of agent references to show (defaults to the built-in `default` and `coder` agents plus any agent configs found in `~/.agents`). Arrow keys navigate; `?` toggles the YAML preview panel; `l` (or mouse-click) toggles the **Lean Mode** checkbox to launch in the lean TUI; `b` (or clicking **[ Open Board ]**) opens the Kanban board (`docker agent board`) instead of running an agent; Enter confirms. Not available in `--exec` or non-TTY modes. |
+| `-w, --worktree [name]`                 | Run the agent in a fresh git worktree of the working directory, isolating its changes from your checkout. Optionally name it (`--worktree=my-feature`); otherwise a name is generated. Requires the working directory to be inside a git repository. Every tool (the shell included) runs inside the worktree. Combine with `--working-dir` to branch from another repository, and with `--session` to resume into the same worktree later. Cannot be combined with `--remote` or `--sandbox`. When the session ends, a clean worktree is removed automatically; one with work prompts to keep or remove (never in `--exec`). |
+| `--worktree-base <ref>`                  | Branch the `--worktree` from `<ref>` (a branch, tag, commit, or remote-tracking ref like `origin/main`) instead of the current `HEAD`. A remote-tracking ref is fetched first so the worktree starts from the latest remote state. Requires `--worktree`; cannot be combined with `--worktree-pr`, `--remote`, or `--sandbox`. |
+| `--worktree-pr <number\|url>`            | Run the agent in a git worktree checked out on an existing GitHub pull request (PR number, `#123`, or PR URL). Continues the PR's branch so commits push back to it. Requires the [GitHub CLI](https://cli.github.com/) (`gh`). Cannot be combined with `--worktree`, `--remote`, or `--sandbox`. |
+| `--working-dir <path>`                  | Set the working directory for the session (applies to tools and relative paths)                                                           |
+| `--env-from-file <path>`                | Load environment variables from file (repeatable)                                                                                         |
+| `--flavor <name>`                       | Enable a config flavor, a YAML patch defined under the config's `flavors` section (repeatable, applied in order). See [Flavors](../../configuration/flavors/index.md). |
+| `--code-mode-tools`                     | Provide a single tool to call other tools via JavaScript (forces code-mode tools globally)                                                |
+| `--models-gateway <addr>`               | Route model traffic through a gateway. Also reads `DOCKER_AGENT_MODELS_GATEWAY` (legacy `CAGENT_MODELS_GATEWAY`) env var.                  |
+| `--hook-pre-tool-use <cmd>`             | Add a pre-tool-use hook command (repeatable). See [Hooks](../../configuration/hooks/index.md).                                  |
+| `--hook-post-tool-use <cmd>`            | Add a post-tool-use hook command (repeatable)                                                                                             |
+| `--hook-session-start <cmd>`            | Add a session-start hook command (repeatable)                                                                                             |
+| `--hook-session-end <cmd>`              | Add a session-end hook command (repeatable)                                                                                               |
+| `--hook-on-user-input <cmd>`            | Add an on-user-input hook command (repeatable)                                                                                            |
+| `--hook-stop <cmd>`                     | Add a stop hook command, fired when the model finishes responding (repeatable)                                                            |
+| `--fake <path>`                         | Replay AI responses from a cassette file (for testing). Mutually exclusive with `--record`.                                               |
+| `--fake-stream [ms]`                    | When replaying with `--fake`, simulate streaming with a delay between chunks (defaults to 15ms when given without a value).               |
+| `--record [path]`                       | Record AI API interactions to a cassette file and generate a TUI e2e test from the session (auto-generates filename if no path given). Routes through `--models-gateway` when one is configured. |
+| `-d, --debug`                           | Enable debug logging                                                                                                                      |
+| `--log-file <path>`                     | Custom debug log location                                                                                                                 |
+| `-o, --otel`                            | Enable OpenTelemetry observability: traces, metrics, and logs. Requires `OTEL_EXPORTER_OTLP_ENDPOINT` to export to a collector. |
+
+```bash
+# Examples
+$ docker agent run agent.yaml
+$ docker agent run agent.yaml "Fix the bug in auth.go"
+$ docker agent run agent.yaml -a developer --yolo
+$ docker agent run agent.yaml --model anthropic/claude-sonnet-4-5
+$ docker agent run agent.yaml --model "dev=openai/gpt-4o,reviewer=anthropic/claude-sonnet-4-5"
+$ docker agent run agent.yaml --session -1  # resume last session
+$ docker agent run agent.yaml --session -1 --session-read-only  # review last session without sending messages
+$ docker agent run agent.yaml --prompt-file ./context.md  # include file as context
+
+# Add hooks from the command line
+$ docker agent run agent.yaml --hook-session-start "./scripts/setup-env.sh"
+$ docker agent run agent.yaml --hook-pre-tool-use "./scripts/validate.sh" --hook-post-tool-use "./scripts/log.sh"
+
+# Queue multiple messages (processed in sequence)
+$ docker agent run agent.yaml "question 1" "question 2" "question 3"
+
+# Customize TUI display
+$ docker agent run agent.yaml --app-name "My Project"
+$ docker agent run agent.yaml --sidebar=false
+$ docker agent run agent.yaml --disable-commands="/cost,/eval,/model"
+
+# Browse and pick an agent interactively
+$ docker agent run --agent-picker
+$ docker agent run --agent-picker=myorg/coder,myorg/researcher
+```
+
+> [!TIP]
+> **Lean, inline TUI**
+>
+> Pass `--lean` to get a lightweight TUI that renders inline in your terminal (no alternate screen). Like the full TUI, it displays an ASCII art banner on startup when the chat is empty, and supports the same slash commands and streaming output, making it handy inside tmux, scripts, or any context where a full-screen takeover is unwanted.
+
+> [!TIP]
+> **Isolate a run in a git worktree**
+>
+> When the working directory is inside a git repository, `--worktree` creates a fresh [git worktree](https://git-scm.com/docs/git-worktree) and points the session at it, so the agent's edits land on a separate branch and never touch your checkout. Every tool — the shell included — runs inside the worktree. The worktree is stored under `<data-dir>/worktrees/<name>` on a branch named `worktree-<name>`.
+
+```bash
+# Run in an isolated worktree with a generated name (e.g. "focused_turing")
+$ docker agent run agent.yaml --worktree
+$ docker agent run agent.yaml -w "Refactor the auth package"
+
+# Give the worktree (and its branch) an explicit name
+$ docker agent run agent.yaml --worktree=auth-refactor
+
+# Branch the worktree from another ref instead of the current HEAD.
+# A remote-tracking ref is fetched first, so the worktree starts from the
+# latest remote state.
+$ docker agent run agent.yaml --worktree=auth-refactor --worktree-base origin/main
+
+# Resume a worktree run later: the session remembers its worktree, so you
+# don't pass --worktree again (which would fail — the worktree already exists).
+$ docker agent run agent.yaml --worktree=auth-refactor   # first run, creates it
+$ docker agent run agent.yaml --session -1               # resumes into the same worktree
+
+# Check out an existing GitHub pull request to continue it (requires gh)
+$ docker agent run agent.yaml --worktree-pr 123
+$ docker agent run agent.yaml --worktree-pr https://github.com/owner/repo/pull/123
+```
+
+With `--worktree-pr`, the PR's head branch is checked out tracking its remote (via the [GitHub CLI](https://cli.github.com/)), so commits made during the run push straight back to the pull request. The worktree is stored under `<data-dir>/worktrees/pr-<number>`.
+
+When the interactive session ends, the worktree is cleaned up based on its state:
+
+- **Clean** (no uncommitted changes, untracked files, or new commits): the worktree and its branch are removed automatically.
+- **Has work** (uncommitted changes, untracked files, or new commits): you're prompted to keep or remove it. Keeping preserves the directory and branch so you can return later; removing discards the worktree, its branch, and all that work.
+- **Non-interactive runs** (`--exec`): the worktree is never cleaned up — it's left in place for inspection.
+
+A worktree is only ever removed if `--worktree` created it for this run; a pre-existing worktree is never touched.
+
+A kept worktree can be resumed: pass `--session` (a relative ref like `-1`, or the session id) and the run reattaches to the same worktree directory and branch automatically. Don't re-pass `--worktree` on resume — that would try to create a new worktree and fail because it already exists.
+
+### `docker agent run --exec`
+
+Run an agent in non-interactive (headless) mode. No TUI — output goes to stdout.
+
+```bash
+$ docker agent run --exec [config] [message...] [flags]
+```
+
+```bash
+# One-shot task
+$ docker agent run --exec agent.yaml "Create a Dockerfile for a Python Flask app"
+
+# With auto-approve
+$ docker agent run --exec agent.yaml --yolo "Set up CI/CD pipeline"
+
+# Multi-turn conversation
+$ docker agent run --exec agent.yaml "question 1" "question 2" "question 3"
+```
+
+### `docker agent new`
+
+Interactively generate a new agent configuration file.
+
+```bash
+$ docker agent new [flags]
+
+# Examples
+$ docker agent new
+$ docker agent new --model openai/gpt-5
+$ docker agent new --model dmr/ai/gemma3-qat:12B --max-iterations 15
+```
+
+### `docker agent getting-started`
+
+Run a short (about 2 minutes), skippable interactive tour inside the chat UI: sending messages, approving tool calls, the command palette (<kbd>Ctrl</kbd>+<kbd>K</kbd>), slash commands, and how agents are configured. Aliased as `docker agent tour`. Requires an interactive terminal.
+
+```bash
+$ docker agent getting-started
+```
+
+Replay it anytime with this command, or with the `/getting-started` slash command inside a running TUI session.
+
+### `docker agent models`
+
+List models available for use with `--model`. By default only shows models for providers you have credentials for. Aliases: `docker agent models list`, `docker agent models ls`.
+
+```bash
+$ docker agent models [flags]
+```
+
+| Flag                   | Default | Description                                                                        |
+| ---------------------- | ------- | ---------------------------------------------------------------------------------- |
+| `-p, --provider <id>`  | (none)  | Filter models by provider name (e.g. `openai`, `anthropic`, `dmr`, `ollama`, …).   |
+| `--format <fmt>`       | `table` | Output format: `table` or `json`.                                                  |
+| `-a, --all`            | `false` | Include models from all providers, not just those you have credentials for.        |
+
+```bash
+# Examples
+$ docker agent models                                 # only providers you can use
+$ docker agent models --all                           # every provider the catalog knows about
+$ docker agent models --provider openai
+$ docker agent models --format json | jq
+```
+
+When a models gateway is configured (`--models-gateway`, `DOCKER_AGENT_MODELS_GATEWAY`, or the user config), the command first queries the gateway's `/v1/models` endpoint. A non-empty response is authoritative for the models routed through the gateway: the listing shows the models the gateway serves (`--provider` filters within it), alongside any custom providers you have configured, which serve their models from their own endpoints rather than through the gateway. If the gateway cannot be queried or serves no usable model (endpoint not implemented, empty list, invalid response, timeout, missing authentication), the command falls back to the providers you have configured directly — provider API keys, provider aliases, and custom providers — plus the model catalog; a failure of one source never prevents the others from being listed. The Docker Desktop token is only sent (and required) when the gateway targets a trusted Docker URL.
+
+### `docker agent toolsets`
+
+List the built-in toolset types available for use in an agent configuration. Each type can be referenced under `toolsets:` in an agent YAML file. Use this to discover what's available without leaving the terminal.
+
+```bash
+$ docker agent toolsets [flags]
+```
+
+| Flag             | Default | Description                       |
+| ---------------- | ------- | --------------------------------- |
+| `--format <fmt>` | `table` | Output format: `table` or `json`. |
+
+```bash
+# Examples
+$ docker agent toolsets                                # human-readable table
+$ docker agent toolsets --format json | jq             # machine-readable (type, summary, docs URL)
+```
+
+### `docker agent setup`
+
+Set up a model interactively. Four paths:
+
+- **Built-in cloud provider**: pick a provider Docker Agent already knows (Anthropic, OpenAI, Google, Groq, Hugging Face, ...) and connect it. Credentials vary by provider: most take an API key or token, stored in the Docker Agent env file `~/.config/cagent/.env`, while `chatgpt` signs in with your ChatGPT account in the browser.
+- **Local model**: check Docker Model Runner and pull a model. No API key needed.
+- **Custom OpenAI-compatible endpoint**: register an endpoint that is not built in (vLLM, LiteLLM, a corporate gateway, ...) with its base URL, API format, and API key variable, saved to your [user configuration](../../providers/custom/index.md#global-providers-user-configuration) so its models work everywhere via `--model <name>/<model>`.
+- **Claude Code harness**: use a Claude subscription through the official `claude` CLI. The wizard checks that the CLI is installed and logged in, offers to run `claude auth login --claudeai` (only after you confirm), and writes a ready-to-run `claude-code-agent.yaml`. See [Coding Harnesses](../harnesses/index.md).
+
+Ends with the exact command to start chatting. Secret values are never printed, and Docker Agent never reads or copies the Claude CLI's credentials.
+
+The wizard is also offered automatically when an interactive run finds no usable model (decline-able; set `DOCKER_AGENT_NO_SETUP=1` to suppress the offer).
+
+```bash
+$ docker agent setup
+```
+
+### `docker agent doctor`
+
+Diagnose the model and credential setup. Reports which model providers have credentials and where each credential comes from (shell environment, env file, Docker Desktop, …), whether Docker Model Runner is reachable and which models are pulled, and which model the `auto` selection would pick. Secret values are never printed. Exits with a non-zero status when an issue would prevent an agent from running, which makes it usable in scripts and CI.
+
+```bash
+$ docker agent doctor [agent-file|registry-ref] [flags]
+```
+
+With an agent file, also lists the environment variables that file requires (model credentials and tool secrets such as `GITHUB_PERSONAL_ACCESS_TOKEN`), whether each one is set, and from which source. When the file declares a [`claude-code` harness](../harnesses/index.md) agent, the doctor additionally checks that the official `claude` CLI is installed and logged in, reporting its version and safe login metadata (auth method, API provider, subscription type — never your email, organization, or tokens); a missing or logged-out CLI is reported as an issue with the `claude auth login --claudeai` remediation.
+
+| Flag                     | Default | Description                                                    |
+| ------------------------ | ------- | -------------------------------------------------------------- |
+| `--json`                 | `false` | Output the full report in JSON format (for scripting).         |
+| `--env-from-file <file>` | (none)  | Also check variables supplied by an env file.                  |
+| `--models-gateway <url>` | (none)  | Diagnose against a models gateway (credentials come from it).  |
+
+```bash
+# Examples
+$ docker agent doctor                        # credential, DMR, and auto-selection state
+$ docker agent doctor ./agent.yaml           # also check that file's requirements
+$ docker agent doctor --json | jq .issues
+```
+
+### `docker agent serve api`
+
+Start the HTTP API server for programmatic access. The argument can be a single agent file, a registry reference, or a directory — when given a directory, every `.yaml`/`.yml`/`.hcl` file in it is exposed as a separate entry under `/api/agents`.
+
+```bash
+$ docker agent serve api <agent-file>|<agents-dir>|<registry-ref> [flags]
+```
+
+| Flag                       | Default            | Description                                                                                                |
+| -------------------------- | ------------------ | ---------------------------------------------------------------------------------------------------------- |
+| `-l, --listen <addr>`      | `127.0.0.1:8080`   | Address to listen on.                                                                                      |
+| `--auth-token <token>`     | (none)             | Bearer token required for all API requests. When set, every request must include `Authorization: Bearer <token>`. Leave empty to disable authentication (safe when listening on loopback interfaces only). |
+| `--max-request-size <bytes>` | `1048576` (1 MiB) | Maximum request body size. Requests exceeding this limit are rejected with HTTP 413 — see [Troubleshooting: HTTP 413](../../community/troubleshooting/index.md#http-413-request-body-too-large).                      |
+| `--session-workingdir-root <path>` | (none)     | Confine the `working_dir` of sessions created via `POST /api/sessions` to this directory and its descendants (symlinks are resolved before the check). Unrestricted by default — any clean host directory is accepted (raw values containing `..` are rejected), as local single-user daemons rely on. Recommended for multi-user or network-exposed deployments. |
+| `-s, --session-db <path>`  | `session.db`       | Path to the SQLite session database (relative paths resolve against the working directory).                |
+| `--pull-interval <minutes>`| `0`                | Periodically re-pull OCI/URL references and refresh the agent definition. `0` disables auto-pull.          |
+| `--fake <path>`             | (none)             | Replay AI responses from a cassette file (for testing). Mutually exclusive with `--record`.               |
+| `--record [path]`           | (none)             | Record AI API interactions to a cassette file. Routes through `--models-gateway` when one is configured. |
+| `--mcp-oauth-redirect-uri <url>` | (none)        | OAuth redirect URI for the unmanaged MCP OAuth flow in server mode. When set, the runtime drives PKCE and code exchange in-process and sends the full authorize URL to the client via elicitation. See [Remote MCP](../remote-mcp/index.md) for details. |
+
+> **Diagnostics:** Set `CAGENT_PPROF_ADDR=127.0.0.1:6060` (or `--pprof-addr`, a hidden flag) to start a live Go pprof server at `/debug/pprof/`. Use a loopback address; a non-loopback binding logs a security warning.
+
+All [runtime configuration flags](#runtime-configuration-flags) (`--working-dir`, `--env-from-file`, `--models-gateway`, `--hook-*`, …) are also accepted.
+
+```bash
+# Examples
+$ docker agent serve api agent.yaml
+$ docker agent serve api agent.yaml --listen :8080
+$ docker agent serve api ./agents/                          # directory of agent YAML/HCL configs
+$ docker agent serve api ociReference --pull-interval 10    # auto-refresh
+```
+
+See [API Server](../api-server/index.md) for the full HTTP API reference.
+
+### `docker agent serve mcp`
+
+Expose agents as MCP tools for use in Claude Desktop, Claude Code, or other MCP clients. Defaults to stdio transport; use `--http` to start a streaming HTTP server instead.
+
+```bash
+$ docker agent serve mcp <config> [flags]
+```
+
+| Flag                   | Default            | Description                                                                                       |
+| ---------------------- | ------------------ | ------------------------------------------------------------------------------------------------- |
+| `-a, --agent <name>`   | (all agents)       | Name of the agent to expose. If omitted, every agent in the config is exposed as a separate tool. |
+| `--tool-name <name>`   | (agent name)       | Override the MCP tool identifier clients call; only valid when exposing a single agent.           |
+| `--http`               | `false`            | Use streaming HTTP transport instead of stdio.                                                    |
+| `--safety <policy>`    | `restricted`       | HTTP MCP safety policy; no effect on stdio or `--attach`.                                         |
+| `--auth-token <token>` | (none)             | Required Bearer token for HTTP MCP requests.                                                       |
+| `--insecure-no-auth`   | `false`            | Permit unauthenticated non-loopback HTTP MCP binding.                                              |
+| `-l, --listen <addr>`  | `127.0.0.1:8081`   | Address to listen on (only used with `--http`).                                                   |
+| `--mcp-keepalive <dur>`| `0` (disabled)     | Interval between MCP keep-alive pings (e.g. `30s`).                                               |
+| `--attach [target]`    | (none)             | Attach to a running TUI run by pid, address, or session id; given without a value, selects the most recent run.   |
+
+All [runtime configuration flags](#runtime-configuration-flags) are also accepted.
+
+```bash
+# Examples
+$ docker agent serve mcp agent.yaml                                # stdio transport
+$ docker agent serve mcp agent.yaml --http --listen 127.0.0.1:9090 # streaming HTTP
+$ docker agent serve mcp agent.yaml --working-dir /path/to/project
+$ docker agent serve mcp myorg/coder
+```
+
+See [MCP Mode](../mcp-mode/index.md) for detailed setup.
+
+### `docker agent serve a2a`
+
+Start an A2A (Agent-to-Agent) protocol server.
+
+```bash
+$ docker agent serve a2a <config> [flags]
+```
+
+| Flag                   | Default            | Description                                                                                |
+| ---------------------- | ------------------ | ------------------------------------------------------------------------------------------ |
+| `-a, --agent <name>`   | (team default)     | Name of the agent to run. Defaults to the team's first agent if not specified.             |
+| `-l, --listen <addr>`  | `127.0.0.1:8082`   | Address to listen on.                                                                       |
+| `-s, --session-db <path>` | `<data-dir>/session.db` | Path to the SQLite session database.                                                 |
+
+All [runtime configuration flags](#runtime-configuration-flags) are also accepted.
+
+```bash
+# Examples
+$ docker agent serve a2a agent.yaml
+$ docker agent serve a2a agent.yaml --listen 127.0.0.1:9000
+$ docker agent serve a2a myorg/agent:tag
+```
+
+### `docker agent serve acp`
+
+Start an ACP (Agent Client Protocol) server over stdio. This allows external clients to interact with your agents using the ACP protocol.
+
+```bash
+$ docker agent serve acp <config> [flags]
+```
+
+| Flag                      | Default                     | Description                                       |
+| ------------------------- | --------------------------- | ------------------------------------------------- |
+| `-s, --session-db <path>` | `<data-dir>/session.db`     | Path to the SQLite session database.              |
+
+All [runtime configuration flags](#runtime-configuration-flags) are also accepted.
+
+```bash
+# Examples
+$ docker agent serve acp agent.yaml
+$ docker agent serve acp ./team.yaml
+$ docker agent serve acp myorg/agent:tag
+```
+
+See [ACP](../acp/index.md) for details on the Agent Client Protocol.
+
+### `docker agent serve chat`
+
+Start an HTTP server that exposes one or more agents through an **OpenAI-compatible Chat Completions API** at `/v1/chat/completions` and `/v1/models`. This lets any tool that already speaks the OpenAI protocol — for example [Open WebUI](https://github.com/open-webui/open-webui), `curl`, the OpenAI Python SDK, or LangChain — drive a Docker Agent agent without any custom integration.
+
+```bash
+$ docker agent serve chat <config> [flags]
+```
+
+| Flag                          | Default            | Description                                                                                                       |
+| ----------------------------- | ------------------ | ----------------------------------------------------------------------------------------------------------------- |
+| `-a, --agent <name>`          | (all agents)       | Name of the agent to expose. If omitted, every agent in the config is exposed as a separate model.                |
+| `-l, --listen <addr>`         | `127.0.0.1:8083`   | Address to listen on.                                                                                             |
+| `--cors-origin <origin>`      | (none)             | Allowed CORS origin (e.g. `https://example.com`). Empty disables CORS.                                            |
+| `--api-key <token>`           | (none)             | Required Bearer token clients must present (`Authorization: Bearer <token>`). Empty disables auth.                |
+| `--api-key-env <name>`        | (none)             | Read the required API key from this non-empty environment variable.                                      |
+| `--insecure-no-auth`           | `false`            | Permit unauthenticated non-loopback binding.                                                                  |
+| `--safety <policy>`            | `restricted`       | Tool safety policy; CLI value overrides agent/runtime configuration.                                           |
+| `--max-request-size <bytes>`  | `1048576` (1 MiB)  | Maximum request body size. Requests exceeding this limit are rejected with HTTP 413 — see [Troubleshooting: HTTP 413](../../community/troubleshooting/index.md#http-413-request-body-too-large).                                                                                        |
+| `--request-timeout <dur>`     | `5m`               | Per-request timeout (covers model + tool calls + streaming).                                                      |
+| `--conversations-max <n>`     | `0`                | Cache up to N conversations server-side, keyed by `X-Conversation-Id`. `0` disables — clients must resend history. |
+| `--conversation-ttl <dur>`    | `30m`              | Idle TTL after which a cached conversation is evicted.                                                            |
+| `--max-idle-runtimes <n>`     | `4`                | Maximum number of idle runtimes pooled per agent. `0` disables pooling.                                           |
+
+```bash
+# Examples
+$ docker agent serve chat agent.yaml
+$ docker agent serve chat ./team.yaml --agent reviewer
+$ docker agent serve chat myorg/agent:tag --listen 127.0.0.1:9090
+$ docker agent serve chat agent.yaml --api-key-env CHAT_BEARER_TOKEN
+
+# Drive it from any OpenAI-compatible client
+$ curl http://127.0.0.1:8083/v1/chat/completions \
+    -H 'Content-Type: application/json' \
+    -d '{"model": "root", "messages": [{"role": "user", "content": "hello"}]}'
+```
+
+See [Chat Server](../chat-server/index.md) for the full feature reference.
+
+### `docker agent board`
+
+Launch a full-screen Kanban TUI for orchestrating multiple agents at once. Each card runs an agent in its own tmux session on an isolated git worktree; moving a card forward through the pipeline (Dev → Review → Push → Done) delivers the destination column's prompt to that card's agent. Projects and column prompts are stored in the global config file (`~/.config/cagent/config.yaml`) and can be managed from the TUI.
+
+```bash
+$ docker agent board
+```
+
+Takes no arguments or flags. Requires `tmux` and `git` to be installed.
+
+See [Kanban Board](../board/index.md) for key bindings, configuration, and workflow details.
+
+### `docker agent share push` / `docker agent share pull`
+
+Share agents via OCI registries.
+
+```bash
+# Push an agent
+$ docker agent share push ./agent.yaml docker.io/username/my-agent:latest
+
+# Pull an agent
+$ docker agent share pull docker.io/username/my-agent:latest
+
+# Force pull, overwriting the local copy
+$ docker agent share pull docker.io/username/my-agent:latest --force
+```
+
+| Flag       | Applies to | Description                                                |
+| ---------- | ---------- | ---------------------------------------------------------- |
+| `--force`  | `pull`     | Force pull even if the configuration already exists locally |
+
+See [Agent Distribution](../../concepts/distribution/index.md) for full registry workflow details.
+
+### `docker agent sessions diff`
+
+Compare two recorded sessions and report the first point where the agent behaved
+differently — the triage answer when a task that worked yesterday does not work
+today.
+
+```bash
+$ docker agent sessions diff <session-a> <session-b> [flags]
+```
+
+```console
+$ docker agent sessions diff -1 -2
+Comparing a1b2c3d4 (7 turns) against e5f6a7b8 (9 turns)
+
+❌ First divergence at turn 3 (after 3 matching turn(s)).
+   a1b2c3d4 called:
+     read_file({"path":"pkg/cache/cache.go"})
+   e5f6a7b8 called:
+     search_files_content({"query":"persistToDisk","path":"."})
+
+Everything after this point is downstream of the divergence and is not compared.
+```
+
+Session references accept a full ID, a unique ID prefix, or a relative form such
+as `-1` for the most recent run.
+
+| Flag                    | Default                 | Description                                    |
+| ----------------------- | ----------------------- | ------------------------------------------------ |
+| `-s, --session-db`      | `<data-dir>/session.db` | Path to the session database                   |
+| `--json`                | `false`                 | Emit the comparison as JSON                    |
+| `--fail-on-divergence`  | `false`                 | Exit non-zero when the two sessions diverge    |
+
+Comparison is over the sequence of tool calls, not the assistant's prose: model
+output is nondeterministic, so two runs of the same task almost always word
+things differently while doing the same work. Turns taken by delegated
+sub-agents are included in sequence. Reporting stops at the first divergence —
+everything after it is downstream of that difference.
+
+This locates *where* two runs diverged, not *why*. Re-running a session against
+a different model while holding the environment fixed is a separate, unbuilt
+feature.
+
+### `docker agent eval`
+
+Run agent evaluations against a directory of recorded sessions.
+
+```bash
+$ docker agent eval <agent-file>|<registry-ref> [<eval-dir>|./evals] [flags]
+```
+
+| Flag                | Default                              | Description                                                                |
+| ------------------- | ------------------------------------ | -------------------------------------------------------------------------- |
+| `-c, --concurrency` | num CPUs                             | Number of concurrent evaluation runs                                       |
+| `--judge-model`     | `anthropic/claude-opus-5` | Model for LLM-as-a-judge relevance scoring (format: `provider/model`)      |
+| `--output <dir>`    | `<eval-dir>/results`                 | Directory for results, logs, and session databases                         |
+| `--only <pattern>`  | (all)                                | Only run evals with file names matching these patterns (repeatable)        |
+| `--base-image`      | (default)                            | Custom base image for eval containers                                      |
+| `--container-runtime` | `docker`                           | Container runtime executable for building and running evaluations (e.g. `podman`) |
+| `--keep-containers` | `false`                              | Keep containers after evaluation (don't remove with `--rm`)                |
+| `-e, --env`         | (none)                               | Environment variables to pass to container (`KEY` or `KEY=VALUE`, repeatable) |
+| `--repeat <n>`      | `1`                                  | Number of times to repeat each evaluation (useful for computing baselines) |
+| `--baseline <file>` | (none)                               | Compare against a previously saved run JSON (`<output>/<run>.json`) and exit non-zero on regression |
+| `--regression-tolerance <n>` | `0`                         | How far an aggregate quality rate may fall before `--baseline` reports a regression (0–1) |
+
+All [runtime configuration flags](#runtime-configuration-flags) are also accepted.
+
+```bash
+# Examples
+$ docker agent eval agent.yaml                            # use ./evals
+$ docker agent eval agent.yaml ./my-evals                 # custom directory
+$ docker agent eval agent.yaml -c 8                       # 8 concurrent evaluations
+$ docker agent eval agent.yaml --keep-containers          # keep containers for debugging
+$ docker agent eval agent.yaml --only "auth*"             # only run matching evals
+$ docker agent eval agent.yaml --repeat 5                 # repeat each eval 5 times
+$ docker agent eval agent.yaml --container-runtime podman # use a Docker-compatible runtime such as Podman
+```
+
+See [Evaluation](../evaluation/index.md) for details on creating eval sessions and interpreting results.
+
+### `docker agent version`
+
+Print the version and commit hash for your `docker-agent` install.
+
+```bash
+$ docker agent version
+docker agent version v1.54.0
+Commit: 1737035c
+```
+
+### `docker agent alias`
+
+Manage agent aliases for quick access.
+
+```bash
+# List aliases
+$ docker agent alias ls
+
+# List aliases as JSON
+$ docker agent alias list --json
+
+# Add an alias
+$ docker agent alias add pirate /path/to/pirate.yaml
+$ docker agent alias add other ociReference
+
+# Add an alias with runtime options
+$ docker agent alias add yolo-coder myorg/coder --yolo
+$ docker agent alias add careful-coder myorg/coder --safety balanced
+$ docker agent alias add fast-coder myorg/coder --model openai/gpt-4o-mini
+$ docker agent alias add safe-coder myorg/coder --sandbox
+$ docker agent alias add turbo myorg/coder --yolo --model anthropic/claude-sonnet-4-5
+
+# Use an alias
+$ docker agent run pirate
+$ docker agent run yolo-coder
+```
+
+**Alias Options:** Aliases can include runtime options that apply automatically when used:
+
+- `--yolo` — Auto-approve tool calls (unless explicitly denied) when running the alias. Legacy alias for `--safety autonomous`.
+- `--safety <mode>` — Default [safety mode](../../configuration/permissions/index.md#safety-modes) (`strict`, `balanced`, `restricted`, or `autonomous`) when running the alias. Wins over the alias's `yolo` option; both are stored declaratively in the user config (`aliases.<name>.safety` / `aliases.<name>.yolo`), so you can also edit them there by hand.
+- `--model <ref>` — Override the model for the alias
+- `--hide-tool-results` — Hide tool call results in the TUI when running the alias
+- `--sandbox` — Always run the alias inside a [Docker sandbox](../../configuration/sandbox/index.md)
+
+Alias safety options are defaults for new sessions: an explicit `--safety`/`--yolo` on the command line wins over them, they win over `settings.safety`/`settings.YOLO` and over anything declared in the agent YAML, and they never change the mode of a resumed session.
+
+When listing aliases, options are shown in brackets:
+
+```bash
+$ docker agent alias ls
+Registered aliases (3):
+
+  fast-coder  → myorg/coder [model=openai/gpt-4o-mini]
+  turbo       → myorg/coder [yolo, model=anthropic/claude-sonnet-4-5]
+  yolo-coder  → myorg/coder [yolo]
+
+Run an alias with: docker agent run <alias>
+```
+
+Pass `--json` to output aliases as a JSON array instead of the formatted table. Each entry includes the alias `name` and its options:
+
+```bash
+$ docker agent alias list --json
+[
+  {
+    "name": "fast-coder",
+    "path": "myorg/coder",
+    "model": "openai/gpt-4o-mini"
+  },
+  {
+    "name": "turbo",
+    "path": "myorg/coder",
+    "yolo": true,
+    "model": "anthropic/claude-sonnet-4-5"
+  },
+  {
+    "name": "yolo-coder",
+    "path": "myorg/coder",
+    "yolo": true
+  }
+]
+```
+
+JSON output is sorted by name and omits false/zero-valued fields. This is useful for scripting and automation.
+
+> [!TIP]
+> **Override alias options**
+>
+> Command-line flags override alias options. For example, `docker agent run yolo-coder --yolo=false` disables yolo mode even though the alias has it enabled.
+
+> [!TIP]
+> **Set a default agent**
+>
+> Create a `default` alias to customize what `docker agent` starts with no arguments:
+>
+> ```console
+> $ docker agent alias add default /my/default/agent.yaml
+> ```
+>
+> Then simply run `docker agent` — it will launch that agent automatically.
+
+### `docker agent sandbox`
+
+Manage settings shared by every [`--sandbox`](../../configuration/sandbox/index.md) run — today, the persistent network allowlist that turns a `Blocked by network policy` 403 into a one-line, durable fix:
+
+```bash
+# Allow a host on every subsequent --sandbox run.
+$ docker agent sandbox allow api.example.com
+
+# Or several at once.
+$ docker agent sandbox allow api.example.com registry.npmjs.org:443
+
+# See what's persisted in ~/.config/cagent/config.yaml.
+$ docker agent sandbox list
+
+# Drop a host you no longer need.
+$ docker agent sandbox deny api.example.com
+```
+
+Entries are unioned with the gateway, the kit-resolved tool install hosts, and any `runtime.network_allowlist` declared by the agent. The launch summary lists every source separately so you can see which holes were punched by which layer.
+
+### `docker agent plans`
+
+Manage the plans agents collaborate on, from the host — without starting a session. Two plan systems are covered:
+
+- **Shared plans** — the named, versioned documents of the [plan toolset](../../tools/plan/index.md). Fully manageable: create, update, set status, export, delete.
+- **Session plans** — the single per-session plan of the "draft, review, execute" workflow. Read-only here (`list`, `get`, `export`); they belong to their session and are changed from within it. A mutation aimed at a session plan fails with an `unsupported` error explaining what to do instead.
+
+```bash
+$ docker agent plans <subcommand> [flags]
+```
+
+| Subcommand | Description |
+| ---------- | ----------- |
+| `list [--session <id>]` | List shared plans with scope, name, status, version, updated time, and title. With `--session`, that session's plan is listed first when it exists. Plans that exist but cannot be read are reported as warnings on stderr (in the `warnings` field with `--json`), so they are never mistaken for missing. |
+| `get <name>` | Print a plan. Content goes to stdout and a concise metadata line goes to stderr, so `> file` captures the content alone (use `export` for a byte-exact copy). `get --session <id>` prints a session's plan; the name is then omitted (`--scope shared\|session` disambiguates explicitly, and `--session` alone implies session scope). |
+| `create <name> --file <path>` | Create a new shared plan with content from `--file` (required — the CLI never prompts; `--file -` reads stdin). Create-only: an existing name fails with a version conflict instead of overwriting. `--title`, `--author`, and `--status` set metadata. |
+| `update <name> --file <path>` | Replace the content of an existing shared plan (never creates). Omitted `--title`/`--author`/`--status` flags preserve the current values; passing them (even empty) overwrites. |
+| `status <name> <status>` | Set a shared plan's free-form status without touching its body (bumps the version). |
+| `export <name> --output <path>` | Write a plan's content, byte-exact, to a file (parents created, atomic write). An existing destination is refused (`invalid_argument`) and left untouched; add `--force` to replace an existing regular file atomically. Works for both scopes: `export --session <id> --output <path>`. |
+| `delete <name>` | Delete a shared plan. A `--force` delete also recovers a corrupt plan. |
+
+Plan content passed via `--file` (a regular file, or stdin with `--file -`) is capped at 10 MiB — the same limit the plan storage itself enforces — and a directory or non-regular file (device, named pipe) is rejected up front; violations fail with an `invalid_argument` error.
+
+**Concurrency guard:** every mutation (`update`, `status`, `delete`) requires exactly one of two mutually exclusive flags — the CLI is headless and never prompts:
+
+- `--expected-version <n>` — the version you last read (from `get` or `list`; must be ≥ 1). When the plan changed in the meantime the command fails with a version conflict, reports the current version, leaves the plan untouched, and exits with code **3** (all other failures exit with 1).
+- `--force` — deliberately write without the optimistic-lock guard (last writer wins).
+
+`create` takes no guard: it is inherently create-only and conflicts (exit code 3) when the name already exists.
+
+**JSON output:** every subcommand accepts `--json`. Success documents go to stdout with a top-level `"schema_version": "1"` marker and stable service-model keys (`plans`, `plan`, `export`, `deleted`) whose fields are snake_case (`updated_at`, `session_id`, `bytes_written`; a zero/unknown `updated_at` is omitted); empty plan lists encode as `[]`, and no prose or ANSI is mixed in. Failures print a single JSON object to stderr:
+
+```json
+{"schema_version":"1","error":{"code":"conflict","message":"...","scope":"shared","name":"p","expected_version":1,"current_version":2}}
+```
+
+with `code` one of `conflict` (including `expected_version` and `current_version`), `not_found`, `invalid_argument`, `unsupported`, `corrupt`, `storage`, or `error`; `scope`, `name`, and `op` are included where the failure carries them. Validation performed before a subcommand runs is covered too: a missing required flag, a violated `--expected-version`/`--force` group rule, and wrong positional arguments are reported as the same JSON object (code `invalid_argument`) whenever `--json` is present. One residual: flags are parsed left-to-right and parsing stops at the first unknown flag or invalid flag value, so such an error is reported as JSON only when `--json` appears before it on the command line; errors raised before a `plans` subcommand is resolved at all (e.g. an unknown subcommand) also remain plain text.
+
+```bash
+# Examples
+$ docker agent plans list
+$ docker agent plans list --json | jq '.plans[].name'
+$ docker agent plans create release --file ./plan.md --title "Release plan" --status draft
+$ cat plan.md | docker agent plans create release --file -
+$ docker agent plans get release > plan.md            # content only; metadata on stderr
+$ docker agent plans update release --file ./plan.md --expected-version 1
+$ docker agent plans status release done --expected-version 2
+$ docker agent plans export release --output ./plan.md
+$ docker agent plans export release --output ./plan.md --force   # replace an existing file
+$ docker agent plans delete release --expected-version 3
+$ docker agent plans delete scratch --force
+$ docker agent plans get --session <session-id>       # a session's plan
+$ docker agent plans export --session <session-id> --output ./session-plan.md
+```
+
+Plans live under the data directory (`~/.cagent/plans/` and `~/.cagent/session_plans/` by default), so `--data-dir` selects which store the commands operate on.
+
+### `docker agent debug`
+
+Troubleshooting subcommands for inspecting how an agent config resolves and generating diagnostic output — useful when a config isn't behaving the way you expect. `debug` doesn't appear in `docker agent --help` (it's a diagnostic surface, not a day-to-day command), but every subcommand below is stable and fully supported.
+
+```bash
+$ docker agent debug <subcommand> [flags]
+```
+
+| Subcommand | Description |
+| ---------- | ----------- |
+| `config <agent-file>` | Print the fully-resolved, canonical form of an agent's configuration (defaults applied, references resolved). |
+| `toolsets <agent-file>` | List every toolset each agent in the config exposes, with each tool's name and description. |
+| `skills <agent-file>` | List the skills discovered for each agent, marking forked skills. |
+| `title <agent-file> <question>` | Generate a session title for `<question>` using the same title-generation path the TUI uses (including any configured `title_model`), without starting a session. See [Session Titles](../sessions/index.md#session-titles). |
+| `auth` | Print parsed Docker authentication info from the token in use (source, subject, issuer, expiry, username/email). Add `--json` for machine-readable output. |
+| `oauth list` | List stored MCP OAuth tokens (resource, scope, expiry, redacted access token). Add `--json` for machine-readable output. |
+| `oauth remove <resource-url>` | Remove a stored MCP OAuth token. |
+| `oauth login <agent-file> <mcp-name>` | Perform an interactive OAuth login for a remote MCP server declared in the config, by its name or URL. See [Remote MCP Servers](../remote-mcp/index.md). |
+
+```bash
+# Examples
+$ docker agent debug config agent.yaml
+$ docker agent debug toolsets agent.yaml
+$ docker agent debug skills agent.yaml
+$ docker agent debug title agent.yaml "How do I configure a fallback model?"
+$ docker agent debug auth --json
+$ docker agent debug oauth list
+$ docker agent debug oauth login agent.yaml github
+```
+
+> [!WARNING]
+> **`debug auth --json` prints the full bearer token**
+>
+> The text output of `debug auth` truncates the token to a short preview, but `--json` includes the complete, unredacted JWT in its `token` field. Never paste `debug auth --json` output into logs, issue trackers, or bug reports — anyone with that token can act as you against Docker. Use the plain-text output (or redact the `token` field yourself) when sharing diagnostic output.
+
+The `Source` field says where the token came from: `docker desktop`, or `minted from the stored access token` when it was obtained by exchanging the access token `docker login` stored. See [Docker authentication](../../guides/secrets/index.md#docker-authentication).
+
+The `config`, `toolsets`, `skills`, and `title` subcommands also accept [runtime configuration flags](#runtime-configuration-flags) (`--working-dir`, `--models-gateway`, …); `title` additionally accepts `--model` to override the model used to resolve the config before generating the title.
+
+### `docker agent completion`
+
+Generate a shell completion script for `bash`, `zsh`, `fish`, or `powershell`.
+
+```bash
+$ docker agent completion <bash|zsh|fish|powershell>
+
+# Examples
+# Bash: load for the current session
+$ source <(docker agent completion bash)
+
+# Zsh: install permanently (adjust the path for your $fpath)
+$ docker agent completion zsh > "${fpath[1]}/_docker-agent"
+```
+
+Run `docker agent completion <shell> --help` for shell-specific installation instructions.
+
+### Self-update
+
+When installed from a standalone GitHub release binary, Docker Agent can opt in to updating itself. It's disabled by default; set `DOCKER_AGENT_AUTO_UPDATE` to a truthy value (`1`, `true`, `yes`, `on`) to enable it for a command or a shell session:
+
+```bash
+$ DOCKER_AGENT_AUTO_UPDATE=1 docker agent run
+```
+
+When enabled, every command checks the latest GitHub release before running. If a newer release exists, an interactive session asks whether to install it; a non-interactive session (CI, piped input) proceeds automatically. On yes, Docker Agent downloads the asset for your OS/architecture, verifies its checksum, replaces the current binary, and re-executes with the same arguments. The whole mechanism is fail-safe: any failure at any step falls back to running the current binary. Self-update never triggers for `version`, `help`, `--help`/`-h` (including per-subcommand help), `completion`, or the Docker CLI plugin metadata handshake.
+
+See [Optional Self-Updates](../../getting-started/installation/index.md#optional-self-updates) for the full walkthrough. Docker Desktop and Homebrew installs already manage updates and don't need this.
+
+## Global Flags
+
+These flags are available on every `docker agent` command:
+
+| Flag                      | Description                                                                            |
+| ------------------------- | -------------------------------------------------------------------------------------- |
+| `-d, --debug`             | Enable debug logging (default location: `~/.cagent/cagent.debug.log`)                  |
+| `--log-file <path>`       | Custom debug log location (only used with `--debug`)                                   |
+| `-o, --otel`              | Enable OpenTelemetry observability: traces, metrics, and logs. Requires `OTEL_EXPORTER_OTLP_ENDPOINT` to export to a collector. |
+| `--cache-dir <path>`      | Override the cache directory (default: `~/Library/Caches/cagent` on macOS)             |
+| `--config-dir <path>`     | Override the config directory (default: `~/.config/cagent`). Also reads `DOCKER_AGENT_CONFIG_DIR` (legacy `CAGENT_CONFIG_DIR`) env var. |
+| `--data-dir <path>`       | Override the data directory (default: `~/.cagent`; holds `session.db`, worktrees, plans, …)            |
+| `--help`                  | Show help for any command                                                              |
+
+### OpenTelemetry environment variables
+
+When `--otel` is enabled, the standard [OTel SDK env vars](https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/) are honored (`OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_RESOURCE_ATTRIBUTES`, etc.). Two additional Docker Agent-specific variables control GenAI instrumentation:
+
+| Variable | Default | Description |
+| -------- | ------- | ----------- |
+| `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT` | `false` | Set to `true` to capture prompt text, model responses, tool arguments, and tool results as span attributes. Off by default because these fields may contain PII. |
+| `OTEL_SEMCONV_STABILITY_OPT_IN` | (dual-emit) | Set to `gen_ai_latest_experimental` to emit only the spec-defined `gen_ai.*` keys from the [GenAI semantic conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/). The default dual-emit mode emits both `gen_ai.*` and legacy keys so existing dashboards continue working. |
+
+## Runtime Configuration Flags
+
+These flags are accepted by every command that loads an agent (`run`, `run --exec`, `new`, `eval`, `serve api`, `serve mcp`, `serve a2a`, `serve acp`, `serve chat`). They are listed once here to avoid repetition in the per-command tables above.
+
+| Flag                            | Description                                                                                                              |
+| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
+| `--working-dir <path>`          | Set the working directory for the session (applies to tools and relative paths).                                         |
+| `--env-from-file <path>`        | Load environment variables from file (repeatable).                                                                       |
+| `--flavor <name>`               | Enable a config flavor, a YAML patch defined under the config's `flavors` section (repeatable, applied in order). See [Flavors](../../configuration/flavors/index.md). |
+| `--code-mode-tools`             | Provide a single tool to call other tools via JavaScript (forces code-mode tools globally).                              |
+| `--models-gateway <addr>`       | Route model traffic through a gateway. Reads `DOCKER_AGENT_MODELS_GATEWAY` (legacy `CAGENT_MODELS_GATEWAY`) env var.      |
+| `--hook-pre-tool-use <cmd>`     | Add a pre-tool-use hook command (repeatable). See [Hooks](../../configuration/hooks/index.md).                 |
+| `--hook-post-tool-use <cmd>`    | Add a post-tool-use hook command (repeatable).                                                                           |
+| `--hook-session-start <cmd>`    | Add a session-start hook command (repeatable).                                                                           |
+| `--hook-session-end <cmd>`      | Add a session-end hook command (repeatable).                                                                             |
+| `--hook-on-user-input <cmd>`    | Add an on-user-input hook command (repeatable).                                                                          |
+| `--hook-stop <cmd>`             | Add a stop hook command, fired when the model finishes responding (repeatable).                                          |
+| `--mcp-oauth-redirect-uri <url>` | Public HTTPS URL to advertise as the OAuth `redirect_uri` for MCP servers running in unmanaged OAuth mode. When set, docker-agent drives PKCE and the code exchange in-process instead of expecting the client to. See [Remote MCP](../remote-mcp/index.md) for details. |
+
+## Agent References
+
+Commands that accept a config support multiple reference types:
+
+| Type          | Example                                     |
+| ------------- | ------------------------------------------- |
+| Local file    | `./agent.yaml`                              |
+| OCI registry  | `docker.io/username/agent:latest`           |
+| Hub shorthand | `myorg/agent:tag`                           |
+| Alias         | `pirate` (after `docker agent alias add`)   |
+| Default       | (no argument) — uses project config or built-in default agent |
+
+> [!NOTE]
+> **Debugging**
+>
+> Having issues? See [Troubleshooting](../../community/troubleshooting/index.md) for debug mode, log analysis, and common solutions.
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/code-mode/index.md b/_vendor/github.com/docker/docker-agent/docs/features/code-mode/index.md
new file mode 100644
index 000000000000..80a55978a991
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/code-mode/index.md
@@ -0,0 +1,66 @@
+---
+title: "Code Mode"
+description: "Let an agent write JavaScript that orchestrates several tool calls in one turn instead of calling tools one at a time."
+keywords: docker agent, ai agents, features, code mode
+weight: 115
+canonical: https://docs.docker.com/ai/docker-agent/features/code-mode/
+---
+
+_Let an agent write JavaScript that orchestrates several tool calls in one turn instead of calling tools one at a time._
+
+## What Code Mode Is
+
+By default, a model calls one tool at a time: it emits a tool call, waits for the result, then decides what to call next. For a task that chains many tool calls together — "list every open issue, then for each one fetch its comments, then summarize" — that means one model round-trip per step.
+
+**Code Mode** replaces the agent's individual tools with a single tool, `run_tools_with_javascript`, that runs a JavaScript script. Every tool the agent would otherwise call directly is exposed to that script as a plain JavaScript function (synchronous — no `await`/`async` needed). The model writes a script that calls as many of them as it needs, combines and filters the results, and returns a single string — all in one tool call.
+
+## Enabling Code Mode
+
+Set `code_mode_tools: true` on an agent:
+
+```yaml
+# examples/code_mode.yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Demonstrates the use of Code Mode with tools
+    instruction: Use your tool to help the user with their github requests.
+    code_mode_tools: true
+    commands:
+      demo: How many issues in docker/docker-agent have a number that is prime?
+    toolsets:
+      - type: mcp
+        ref: docker:github-official
+```
+
+Every toolset configured on the agent (the GitHub MCP server here) is wrapped: the model no longer sees the individual GitHub tools, only `run_tools_with_javascript`, with each wrapped tool documented as TypeScript interfaces, type aliases, and function declarations inside its description.
+
+To force Code Mode for every agent in a run regardless of their individual config, use the `--code-mode-tools` CLI flag (or the equivalent `--code-mode-tools` [runtime configuration flag](../cli/index.md#runtime-configuration-flags), accepted by `run`, `run --exec`, `serve api`, `serve mcp`, and the other commands that load an agent):
+
+```bash
+$ docker agent run agent.yaml --code-mode-tools
+```
+
+## When It Helps
+
+Code Mode is worth enabling when an agent's task typically needs **many tool calls chained together**, especially with conditional logic or filtering in between — for example, paging through a large result set, cross-referencing several API calls, or reducing a large payload down to the few fields the model actually needs before it ever sees them. Each of those becomes one model turn instead of many, which cuts both latency and token spend on tool-call/response round-trips.
+
+It is not a general-purpose replacement for direct tool calls: for an agent that mostly makes one or two independent tool calls per turn, Code Mode adds the overhead of writing and reasoning about a script for no real benefit.
+
+## Limits & Security Notes
+
+- **One string result.** The script must return a string; use `console.*` inside the script to print debug information if something doesn't behave as expected — it comes back as `stdout`/`stderr` alongside the result.
+- **Failures are diagnosable.** If the script throws or returns unexpectedly, the response includes the tool calls it made before failing (name, arguments, and result or error), so the model can see what happened and adjust the script on the next attempt.
+- **Not every tool is wrapped.** Tools in the `todo` category are excluded from the script environment and stay directly callable as ordinary tools — Code Mode does not replace them.
+- **The script runs in an embedded, sandboxed JS engine** ([goja](https://github.com/dop251/goja)), not Node.js or a browser: there is no filesystem, network, or process access beyond the tool functions injected into it.
+
+## Interaction With Permissions and Tool Approval
+
+[Permissions](../../configuration/permissions/index.md) and interactive tool-call approval are enforced when the **runtime dispatches a tool call requested by the model** — which, with Code Mode enabled, is only `run_tools_with_javascript` itself. The individual tool calls a script makes from inside that JavaScript are invoked directly and do **not** go through a second round of permission checks or approval prompts.
+
+In practice this means enabling `code_mode_tools` collapses the approval granularity from "one prompt per tool call" down to "one prompt for the whole script". Treat that single approval as authorizing everything the script's toolset could do:
+
+> [!WARNING]
+> **Coarser approval granularity**
+>
+> Approving a `run_tools_with_javascript` call approves every tool it might invoke internally, including ones that would otherwise need a separate `ask` or be blocked by a `deny` pattern under [Permissions](../../configuration/permissions/index.md). If an agent's toolset includes anything destructive, consider whether Code Mode's coarser granularity is acceptable for that agent before enabling it. Delegating to a separate, non-Code-Mode agent isn't a way out either: [handoff](../../tools/handoff/index.md) and [transfer_task](../../tools/transfer-task/index.md) are themselves wrapped like any other tool once `code_mode_tools` is on, but they have no code-mode-compatible handler — the model's script gets `tool "handoff" is not available in code mode` if it tries to call them. This only rules out the model *choosing* to delegate from inside the script: a configured `force_handoff` target on the agent still runs deterministically after the agent's turn naturally stops, regardless of Code Mode, since it's applied by the runtime outside the tool-call dispatch path Code Mode replaces. Keep `code_mode_tools` off any agent whose model needs to hand off or transfer to one that holds a destructive toolset.
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/evaluation/index.md b/_vendor/github.com/docker/docker-agent/docs/features/evaluation/index.md
new file mode 100644
index 000000000000..c90701dec2e4
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/evaluation/index.md
@@ -0,0 +1,311 @@
+---
+title: "Evaluation"
+description: "Measure agent quality with automated evaluations — tool call accuracy, response relevance, output size, and more."
+keywords: docker agent, ai agents, features, evaluation
+weight: 100
+canonical: https://docs.docker.com/ai/docker-agent/features/evaluation/
+aliases:
+  - /ai/docker-agent/evals/
+---
+
+_Measure agent quality with automated evaluations — tool call accuracy, response relevance, output size, and more._
+
+## Overview
+
+The `docker agent eval` command runs your agent against a set of recorded sessions and scores the results. Each eval session captures a user question, the expected tool calls, and criteria the response must satisfy. Docker Agent replays the question, compares the agent's behavior to expectations, and produces a report.
+
+> [!NOTE]
+> **Container runtime required**
+>
+> Evaluations run inside containers for isolation. Each eval gets a clean environment with optional setup scripts. A running Docker-compatible container CLI/runtime is required: Docker Desktop or Docker Engine by default, or another Docker-compatible runtime such as Podman selected with `--container-runtime`.
+
+## Quick Start
+
+```bash
+# Run evaluations for an agent
+$ docker agent eval agent.yaml
+
+# Specify a custom evals directory
+$ docker agent eval agent.yaml ./my-evals
+
+# Run with 8 concurrent evaluations
+$ docker agent eval agent.yaml -c 8
+
+# Only run evals matching a pattern
+$ docker agent eval agent.yaml --only "auth*"
+
+# Repeat each eval 5 times to compute a baseline
+$ docker agent eval agent.yaml --repeat 5
+
+# Repeat a specific eval 5 times
+$ docker agent eval agent.yaml --only "auth*" --repeat 5
+
+# Use a Docker-compatible runtime such as Podman
+$ docker agent eval agent.yaml --container-runtime podman
+```
+
+## Eval Directory Structure
+
+By default, Docker Agent looks for eval sessions in an `evals/` directory next to your agent config:
+
+```bash
+my-agent/
+├── agent.yaml
+└── evals/
+    ├── 41b179a2-....json          # Eval session 1
+    ├── 5d83e247-....json          # Eval session 2
+    └── results/                   # Output (auto-created)
+        ├── adjective-noun-1234.json
+        ├── adjective-noun-1234.log
+        ├── adjective-noun-1234.db
+        └── adjective-noun-1234-sessions.json
+```
+
+## Eval Session Format
+
+Each eval file is a JSON session that captures a complete conversation. The key fields for evaluation are the user message, the expected tool calls (recorded from a real session), and optional eval criteria:
+
+```json
+{
+  "id": "41b179a2-ed19-4ae2-a45d-95775aaa90f7",
+  "title": "Counting Files in Local Folder",
+  "messages": [
+    {
+      "message": {
+        "message": {
+          "role": "user",
+          "content": "How many files in the local folder?"
+        }
+      }
+    },
+    {
+      "message": {
+        "agent_name": "root",
+        "message": {
+          "role": "assistant",
+          "tool_calls": [
+            {
+              "id": "call_abc123",
+              "type": "function",
+              "function": {
+                "name": "list_directory",
+                "arguments": "{\"path\":\"./\"}"
+              }
+            }
+          ]
+        }
+      }
+    },
+    {
+      "message": {
+        "agent_name": "root",
+        "message": {
+          "role": "assistant",
+          "content": "There are 2 files in the local folder..."
+        }
+      }
+    }
+  ],
+  "evals": {
+    "relevance": [
+      "The response mentions exactly 2 files",
+      "The response lists README.md and agent.yaml"
+    ],
+    "size": "S",
+    "working_dir": "my-project",
+    "setup": "echo 'hello' > test.txt"
+  }
+}
+```
+
+## Eval Criteria
+
+The `evals` object inside each session controls what gets scored:
+
+| Field         | Type     | Description                                                                               |
+| ------------- | -------- | ----------------------------------------------------------------------------------------- |
+| `relevance`   | string[] | Statements that must be true about the agent's response. Scored by an LLM judge.          |
+| `size`        | string   | Expected response size: `S`, `M`, `L`, or `XL`. Compared against actual output length.    |
+| `working_dir` | string   | Subdirectory under `evals/working_dirs/` to mount as the container's working directory.   |
+| `setup`       | string   | Shell script to run in the container before the agent executes (e.g., create test files). |
+
+## Scoring Metrics
+
+Docker Agent evaluates agents across three dimensions:
+
+| Metric              | How It's Measured                                                                                                         |
+| ------------------- | ------------------------------------------------------------------------------------------------------------------------- |
+| **Tool Calls (F1)** | F1 score between the expected tool call sequence (from the recorded session) and the actual tool calls made by the agent. |
+| **Relevance**       | An LLM judge (configurable via `--judge-model`) evaluates whether each relevance statement is satisfied by the response.  |
+| **Size**            | Whether the response length matches the expected size category (S/M/L/XL).                                                |
+
+## Serve-safety verification and rollback
+
+When changing an agent served over MCP HTTP, chat, or A2A, add an evaluation that attempts an approval-requiring tool call and verifies the resolved safety policy and authentication behavior. Run the evaluation with the same explicit `--safety` setting used in deployment. If a rollout must be reversed, stop the affected listener, restore the prior agent configuration and explicit safety flag, then restart only after confirming non-loopback listeners still require authentication. Do not restore an unauthenticated network listener as a rollback shortcut.
+
+## Creating Eval Sessions
+
+The easiest way to create eval sessions is from real conversations:
+
+1. Run your agent interactively: `docker agent run agent.yaml`
+2. Have a conversation that tests the behavior you care about
+3. Use the `/eval` slash command in the TUI to save the session as an eval file
+4. Edit the generated JSON to add `evals` criteria (relevance, size, etc.)
+
+> [!TIP]
+> Start with tool call scoring (automatic from recorded sessions), then add relevance criteria for the responses you care most about.
+
+## CLI Flags
+
+```bash
+$ docker agent eval <agent-file>|<registry-ref> [<eval-dir>|./evals]
+```
+
+| Flag                | Default                     | Description                                                       |
+| ------------------- | --------------------------- | ----------------------------------------------------------------- |
+| `-c, --concurrency` | num CPUs                    | Number of concurrent evaluation runs                              |
+| `--judge-model`     | `anthropic/claude-opus-5` | Model for LLM-as-a-judge relevance scoring                        |
+| `--output`          | `<eval-dir>/results`  | Directory for results, logs, and session databases                |
+| `--only`            | (all)                       | Only run evals with file names matching these patterns            |
+| `--base-image`      | (default)                   | Custom base image for eval containers (see [Custom Base Images](#custom-base-images)) |
+| `--container-runtime` | `docker`                  | Container runtime executable for building and running evaluations (e.g. `podman`) |
+| `--keep-containers` | `false`                     | Keep containers after evaluation (don't remove with `--rm`)       |
+| `-e, --env`         | (none)                      | Environment variables to pass to container (`KEY` or `KEY=VALUE`) |
+| `--repeat`          | `1`                         | Number of times to repeat each evaluation (useful for computing baselines) |
+| `--baseline`        | (none)                      | Compare against a previously saved run JSON and exit non-zero on regression (see [Regression gate](#regression-gate)) |
+| `--regression-tolerance` | `0`                    | How far an aggregate quality rate may fall before `--baseline` reports a regression (0–1) |
+
+### Regression gate
+
+`--baseline` compares the run against a previous one and exits non-zero when
+quality regressed, so an eval suite can gate CI:
+
+```console
+$ docker agent eval ./agent.yaml --baseline results/2026-08-01-run.json
+```
+
+The baseline is the run JSON written by a previous invocation —
+`<output>/<run-name>.json` — so there is no separate artifact to produce.
+
+Four rules decide the verdict, and they are worth knowing before wiring this
+into CI:
+
+- **The tolerance governs aggregate rates only.** An LLM judge does not return
+  the same score twice, so without a tolerance the gate flaps. `--regression-tolerance 0.05`
+  lets an aggregate rate fall five points before it counts.
+- **An evaluation that passed and now fails always gates**, regardless of the
+  tolerance. That transition is the signal the gate exists to catch, so it is
+  never absorbed.
+- **Cost is reported but never gates.** A provider price change is not a quality
+  regression.
+- **An added *failing* evaluation gates** via the aggregate rate, even though no
+  existing evaluation regressed. A suite that got worse should say so — but it
+  means committing a known-failing eval needs a tolerance bump or a fix.
+
+A baseline that carries no evaluations, or a run that produced none (an
+`--only` pattern that matched nothing), is rejected rather than reported as
+passing: a gate that cannot fail is worse than no gate.
+
+### Provider Credentials
+
+Eval containers are isolated from your host environment. Dedicated model
+provider API keys (for example `ANTHROPIC_API_KEY` or `OPENAI_API_KEY`) are
+forwarded into eval containers automatically, so most provider setups work
+without extra flags.
+
+> [!WARNING]
+> **`GITHUB_TOKEN` and `GH_TOKEN` are not forwarded automatically**
+>
+> GitHub tokens are broad credentials (git, `gh`, CI, packages), not dedicated
+> model API keys, so for security reasons Docker Agent does not forward them
+> into eval containers — even when they are set in your shell or in
+> `~/.config/cagent/.env`. If your agent uses the `github-copilot` provider,
+> pass the token explicitly by name:
+>
+> ```bash
+> docker agent eval agent.yaml ./evals -e GITHUB_TOKEN
+> ```
+>
+> When using a custom env file, both flags are required:
+>
+> ```bash
+> docker agent eval agent.yaml ./evals \
+>   --env-from-file /path/to/secrets.env \
+>   -e GITHUB_TOKEN
+> ```
+
+Note that the LLM judge runs on the host, not inside the eval container. If
+the token is not forwarded, judge validation can succeed while every
+evaluated agent run fails to authenticate.
+
+### Custom Base Images
+
+When `--base-image` is set, the eval harness builds a derived image on top of your base image at evaluation time. Two things happen automatically:
+
+1. **The docker-agent binary is injected** — it is copied from `docker/docker-agent:edge` into the derived image at build time, so you don't need to include it in your base image.
+2. **The entrypoint is overridden** — Docker Agent replaces your base image's entrypoint with its own `/run.sh` wrapper.
+
+Your base image therefore only needs to provide the runtime environment: language runtimes, installed dependencies, test fixtures, the appropriate working directory, and so on. Any `ENTRYPOINT` or `CMD` defined in your base image is ignored.
+
+## Output
+
+After a run completes, Docker Agent produces:
+
+- **Console summary** — Pass/fail status per eval with metric breakdowns
+- **JSON results** — Full structured results for programmatic analysis
+- **SQLite database** — Complete sessions for detailed investigation and debugging
+- **Sessions JSON** — Exported session data for analysis
+- **Log file** — Debug-level log of the entire evaluation run
+
+> [!TIP]
+> **Debugging Failed Evals**
+>
+> Use `--keep-containers` to preserve containers after evaluation. You can then inspect them with your selected runtime's `exec` command (`docker exec` by default, `podman exec` with `--container-runtime podman`) to understand why an eval failed. The session database (`.db` file) contains the full conversation history for each eval.
+
+```bash
+$ docker agent eval demo.yaml ./evals
+
+  ✓ Counting Files in Local Folder
+    ✓ tool calls  ✓ relevance 2/2
+  ✓ Checking the Content of README.md File
+    ✓ tool calls  ✓ relevance 1/1
+
+✅     Tool Calls: 100.0% avg F1 (2 evals)
+✅      Relevance: 3/3 passed (100.0%)
+
+Total Cost: $0.012345
+Total Time: 12s
+
+Sessions DB: ./evals/results/happy-panda-1234.db
+Sessions JSON: ./evals/results/happy-panda-1234-sessions.json
+Log: ./evals/results/happy-panda-1234.log
+```
+
+## Example
+
+Here's a minimal evaluation setup:
+
+```yaml
+# agent.yaml
+agents:
+  root:
+    model: openai/gpt-4o
+    description: Test agent
+    instruction: You know how to read/write and list files.
+    toolsets:
+      - type: filesystem
+```
+
+```bash
+# Create evals from interactive sessions
+$ docker agent run agent.yaml
+# ... have conversations, then use /eval to save them
+
+# Run the evaluations
+$ docker agent eval agent.yaml ./evals
+```
+
+> [!NOTE]
+> **See also**
+>
+> Use `/eval` in the [TUI](../tui/index.md) to create eval sessions from conversations. See the [CLI Reference](../cli/index.md) for all `docker agent eval` flags. Example eval configs are in [examples/eval](https://github.com/docker/docker-agent/tree/main/examples/eval) on GitHub.
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/harnesses/index.md b/_vendor/github.com/docker/docker-agent/docs/features/harnesses/index.md
new file mode 100644
index 000000000000..b091bfea3ec9
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/harnesses/index.md
@@ -0,0 +1,287 @@
+---
+title: "Coding Harnesses"
+description: "Delegate coding tasks to external AI coding CLIs (Claude Code, Codex, opencode) as sub-agents."
+keywords: docker agent, ai agents, features, coding harnesses
+weight: 50
+canonical: https://docs.docker.com/ai/docker-agent/features/harnesses/
+---
+
+_Delegate coding tasks to external AI coding CLIs (Claude Code, Codex, opencode) as sub-agents._
+
+## Overview
+
+A **harness** agent delegates its work to an external coding CLI — `claude` (Claude Code), `codex` (OpenAI Codex), `opencode`, or `pi` — instead of calling a model API directly. The external CLI drives the coding loop while Docker Agent provides orchestration, hooks, permissions, and distribution.
+
+This pattern gives you the best of both worlds:
+
+- **External CLI strengths** — deep IDE integration, specialized coding workflows, CLI-native tool access
+- **Docker Agent strengths** — multi-agent coordination, hook-based auditing and policy enforcement, permission controls, OCI distribution, and the full agent config schema
+
+> [!NOTE]
+> **When to use harnesses**
+>
+> Use a harness when you want a Claude Code / Codex / opencode session to act as a sub-agent inside a larger Docker Agent workflow — for example, an orchestrator that plans work and delegates coding tasks to specialized harness agents.
+
+## Prerequisites
+
+The external CLI must be installed and available on `PATH` before starting Docker Agent:
+
+| Harness type | Required binary | Install |
+| --- | --- | --- |
+| `claude-code` | `claude` | [docs.anthropic.com/en/docs/claude-code](https://docs.anthropic.com/en/docs/claude-code) |
+| `codex` | `codex` | [github.com/openai/codex](https://github.com/openai/codex) |
+| `opencode` | `opencode` | [opencode.ai](https://opencode.ai) |
+| `pi` | `pi` | Refer to the `pi` CLI documentation for installation instructions. |
+
+Docker Agent will report an error at session start if the required binary is not found. The `claude-code` harness additionally needs the CLI to be logged in — see [Authentication](#authentication-claude-subscription-no-api-key) below.
+
+## Configuration
+
+Add a `harness:` block to any agent definition to make it harness-backed:
+
+```yaml
+agents:
+  coder:
+    description: A Claude Code harness agent
+    harness:
+      type: claude-code
+```
+
+Harness agents do **not** need a `model:` field — the external CLI manages its own model selection.
+
+### Field Reference
+
+| Field | Applies to | Type | Description |
+| --- | --- | --- | --- |
+| `type` | all | string | **Required.** One of `claude-code`, `codex`, `opencode`, `pi` |
+| `model` | all | string | Optional model override forwarded to the CLI. When omitted, the CLI uses its own default model. |
+| `effort` | `claude-code` | string | Reasoning effort: `low` \| `medium` \| `high` \| `xhigh` \| `max` — forwarded as `--effort`. When omitted, Claude Code uses its own default. |
+| `agent` | `opencode` | string | opencode agent profile name |
+| `thinking` | `opencode` | boolean | Enable extended thinking — forwarded as `--thinking` |
+
+### Claude Code
+
+```yaml
+agents:
+  coder:
+    description: Claude Code coding agent
+    harness:
+      type: claude-code
+      model: claude-sonnet-4-5 # optional: alias (sonnet, opus, haiku) or full model ID
+      effort: high # low | medium | high | xhigh | max
+```
+
+- `model` accepts whatever the `claude` CLI accepts for `--model`: an alias
+  like `sonnet`, `opus`, or `haiku`, or a full model ID like
+  `claude-sonnet-4-5`. Omit it to use Claude Code's own default model. This is
+  **not** a Docker Agent `provider/model` reference — the harness model never
+  goes through Docker Agent's model providers or routing.
+- `effort` is forwarded as `--effort` and must be one of `low`, `medium`,
+  `high`, `xhigh`, or `max`. Omit it to use Claude Code's own default.
+
+#### Authentication (Claude subscription, no API key)
+
+The `claude-code` harness runs the official CLI with the CLI's **own login**.
+A Claude (claude.ai) subscription sign-in is all it needs — no
+`ANTHROPIC_API_KEY` and no Docker Agent model credential are required for the
+harness agent itself. Log in once:
+
+```bash
+$ claude auth login --claudeai   # interactive, opens a browser
+$ claude auth status --text      # verify the login
+```
+
+The login is stored per OS user by the CLI (in its own configuration and, on
+macOS, the keychain) and is found via `HOME` and the process environment. Run
+the login **as the same OS user and environment that run `docker agent`** — a
+login made under another user, container, or `sudo` context is invisible to
+the harness. Docker Agent never reads, copies, or stores the CLI's tokens; it
+only launches `claude`, which authenticates itself.
+
+If the CLI is not logged in when a harness agent runs, the `claude` subprocess
+fails at session start and the agent reports a harness error — Docker Agent
+never opens a browser or starts a login on its own. Diagnose and fix with:
+
+```bash
+$ docker agent doctor ./agent.yaml   # checks install + login for claude-code harness files
+$ docker agent setup                 # pick "Claude Code harness" to be walked through it
+```
+
+`docker agent doctor <file>` probes the CLI only when the file declares a
+`claude-code` harness, and reports installation, version, and safe login
+metadata (auth method, API provider, subscription type — never your email,
+organization, or tokens). `docker agent setup` offers to run the official
+`claude auth login --claudeai` for you (only after you confirm) and writes a
+ready-to-run `claude-code-agent.yaml`.
+
+> [!WARNING]
+> **The harness bypasses Claude Code's permission prompts**
+>
+> Docker Agent runs the CLI non-interactively with its own tools and passes
+> `--dangerously-skip-permissions`: Claude Code edits files and runs commands
+> without asking. Only point a harness agent at a repository you trust, and
+> prefer isolation — `docker agent run --worktree` runs it on an isolated git
+> worktree, keeping its changes off your checkout (a worktree with work, or
+> from a non-interactive run, is kept for inspection per the normal cleanup
+> rules). `docker agent run --sandbox` does not automatically carry the
+> `claude` CLI or its login into the sandbox, so it cannot isolate the
+> harness unless the sandbox image is separately provisioned and
+> authenticated.
+
+### Codex
+
+```yaml
+agents:
+  coder:
+    description: Codex coding agent
+    harness:
+      type: codex
+      model: o4-mini     # optional model override
+```
+
+### opencode
+
+```yaml
+agents:
+  coder:
+    description: opencode coding agent
+    harness:
+      type: opencode
+      agent: my-profile  # optional agent profile
+      thinking: true     # enable extended thinking
+```
+
+## What Does NOT Work
+
+Harness agents bypass the Docker Agent model pipeline entirely. As a result:
+
+- **Docker Agent toolsets are inactive.** The external CLI provides its own tools — filesystem, shell, etc. Any `toolsets:` defined on a harness agent are silently ignored.
+- **`model:` routing is unavailable.** The harness CLI manages model selection; Docker Agent's `models:` configuration and routing rules do not apply to harness agents.
+- **Token usage tracking depends on the external CLI.** Docker Agent records usage when the CLI reports it (Claude Code and Codex both report usage data). If the CLI does not emit usage data, the session will show zero token usage.
+
+> [!WARNING]
+> **No Docker Agent toolsets inside a harness**
+>
+> Do not configure `toolsets:` on a harness agent — they are silently ignored. If you need Docker Agent toolsets alongside external coding capabilities, use a standard sub-agent with `transfer_task` rather than a harness.
+
+## Hook Behavior
+
+Hooks work normally on harness agents, including `before_llm_call` and `after_llm_call`. `before_llm_call` runs before the prompt is forwarded to the external CLI and can block or rewrite the run; `after_llm_call` fires after the CLI returns its final response.
+
+The `model_id` field in hook payloads is set to the harness label (e.g. `claude-code`) rather than a canonical `provider/model` string. This applies to `before_llm_call`, `after_llm_call`, and any other event that carries `model_id`.
+
+See [Hooks](../../configuration/hooks/index.md) for the full hook reference.
+
+## Recipe: Root Harness Agent
+
+The simplest setup: a single root agent that hands everything to Claude Code.
+No `models:` section, no API key — the CLI's subscription login does the work.
+This is exactly the file `docker agent setup` generates for the Claude Code
+harness path (as `claude-code-agent.yaml`).
+
+```yaml
+# claude-code-agent.yaml
+agents:
+  root:
+    description: Claude Code running on your Claude subscription
+    harness:
+      type: claude-code
+      effort: medium # low | medium | high | xhigh | max; omit for the Claude Code default
+      # model: claude-sonnet-4-5   # optional; omit for the Claude Code default
+```
+
+```bash
+$ docker agent run claude-code-agent.yaml
+$ docker agent doctor claude-code-agent.yaml   # verify the CLI is installed and logged in
+```
+
+## Recipe: Orchestrator + Harness Sub-Agents (Sequential)
+
+An orchestrator plans the work and delegates to specialized harness agents one at a time. Each coding agent runs in its own sub-session and reports results back.
+
+```yaml
+# examples/coding_harnesses.yaml
+
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+
+agents:
+  root:
+    model: claude
+    description: Orchestrator that plans and delegates coding tasks
+    instruction: |
+      You are a project orchestrator. Break down coding requests into
+      focused tasks and delegate each task to the most appropriate
+      coding agent. Collect results and synthesize a final summary.
+    sub_agents:
+      - claude-coder
+      - codex-coder
+
+  claude-coder:
+    description: Claude Code specialist for complex refactors
+    harness:
+      type: claude-code
+      model: claude-sonnet-4-5
+      effort: xhigh
+
+  codex-coder:
+    description: Codex specialist for code generation
+    harness:
+      type: codex
+```
+
+Only the orchestrator's `model: claude` needs an Anthropic API key — the
+`claude-coder` harness agent authenticates through the CLI's own subscription
+login.
+
+The root agent calls `transfer_task` to send work to a harness sub-agent, waits for the result, and continues. See the [full example on GitHub](https://github.com/docker/docker-agent/blob/main/examples/coding_harnesses.yaml).
+
+## Recipe: Parallel Harness Dispatch
+
+Combine the `background_agents` toolset with harness sub-agents to dispatch multiple coding tasks simultaneously:
+
+```yaml
+# examples/coding_harness_background_agents.yaml
+
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+
+agents:
+  root:
+    model: claude
+    description: Orchestrator that fans out coding tasks in parallel
+    instruction: |
+      Use background agents to run multiple coding tasks at once.
+      Dispatch all tasks, then collect results when each finishes.
+    sub_agents:
+      - claude-coder
+      - codex-coder
+    toolsets:
+      - type: background_agents
+
+  claude-coder:
+    description: Frontend specialist (Claude Code)
+    harness:
+      type: claude-code
+      effort: medium
+
+  codex-coder:
+    description: Backend specialist (Codex)
+    harness:
+      type: codex
+```
+
+The orchestrator calls `run_background_agent` for each task, monitors progress with `list_background_agents`, and collects results with `view_background_agent`. See the [full example on GitHub](https://github.com/docker/docker-agent/blob/main/examples/coding_harness_background_agents.yaml).
+
+For the general background agents reference, see [Background Agents](../../tools/background-agents/index.md).
+
+## See Also
+
+- [Multi-Agent Systems](../../concepts/multi-agent/index.md) — orchestration patterns
+- [Background Agents](../../tools/background-agents/index.md) — parallel task dispatch
+- [Hooks](../../configuration/hooks/index.md) — auditing and policy enforcement
+- [Agent Configuration](../../configuration/agents/index.md) — full agent schema reference
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/mcp-mode/index.md b/_vendor/github.com/docker/docker-agent/docs/features/mcp-mode/index.md
new file mode 100644
index 000000000000..9e3ae0bf69eb
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/mcp-mode/index.md
@@ -0,0 +1,134 @@
+---
+title: "MCP Mode"
+description: "Expose your Docker Agent agents as MCP tools for use in Claude Desktop, Claude Code, and other MCP-compatible applications."
+keywords: docker agent, ai agents, features, mcp mode
+weight: 40
+canonical: https://docs.docker.com/ai/docker-agent/features/mcp-mode/
+---
+
+_Expose your Docker Agent agents as MCP tools for use in Claude Desktop, Claude Code, and other MCP-compatible applications._
+
+## Why MCP Mode?
+
+The `docker agent serve mcp` command makes your agents available to any application that supports the [Model Context Protocol](https://modelcontextprotocol.io/). This means you can:
+
+- Use custom agents directly within **Claude Desktop** or **Claude Code**
+- Share specialized agents across different applications
+- Build reusable agent teams consumable from any MCP client
+- Integrate domain-specific agents into existing workflows
+
+> [!NOTE]
+> **What is MCP?**
+>
+> The [Model Context Protocol](https://modelcontextprotocol.io/) is an open standard for connecting AI tools. See also [Remote MCP Servers](../remote-mcp/index.md) for connecting to cloud services.
+
+## Basic Usage
+
+```bash
+# Expose a local config (stdio transport, the default)
+$ docker agent serve mcp ./agent.yaml
+
+# Expose from a registry
+$ docker agent serve mcp myorg/agent:tag
+
+# Set the working directory
+$ docker agent serve mcp ./agent.yaml --working-dir /path/to/project
+```
+
+## Transports
+
+By default, `serve mcp` uses the stdio transport — ideal for clients that spawn the server as a subprocess (Claude Desktop, Claude Code, Cursor, …).
+
+To expose the MCP server over streaming HTTP instead, pass `--http`:
+
+```bash
+# Streaming HTTP transport on the default 127.0.0.1:8081
+$ docker agent serve mcp ./agent.yaml --http
+
+# Override the listen address / port; non-loopback HTTP requires authentication
+$ docker agent serve mcp ./agent.yaml --http --listen 0.0.0.0:9090 --auth-token "$MCP_BEARER_TOKEN"
+```
+
+| Flag                   | Default            | Description                                                                                                  |
+| ---------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------ |
+| `--http`               | `false`            | Use streaming HTTP transport instead of stdio.                                                               |
+| `-l`, `--listen`       | `127.0.0.1:8081`   | Address to listen on when `--http` is enabled.                                                               |
+| `-a`, `--agent`        | all agents         | Expose a single named agent instead of every agent in the config.                                            |
+| `--tool-name`          | (none)             | Override the MCP tool identifier clients call (defaults to agent name); only valid when exposing one agent.  |
+| `--auth-token`          | (none)             | Require this Bearer token for HTTP requests. Required for non-loopback HTTP unless explicitly overridden.       |
+| `--insecure-no-auth`    | `false`            | Permit unauthenticated non-loopback HTTP. Use only behind a trusted authentication boundary.                    |
+| `--safety`              | `restricted`       | Tool safety policy for HTTP requests. CLI value overrides agent/runtime configuration.                           |
+| `--mcp-keepalive`      | `0`                | Interval between MCP keep-alive pings (e.g. `30s`); `0` disables keep-alive.                                 |
+
+Runtime configuration flags such as `--working-dir`, `--env-from-file`, `--models-gateway`, and hook flags are also available — see the [CLI reference](../cli/index.md).
+
+## HTTP security
+
+HTTP MCP defaults to loopback binding. A non-loopback `--listen` address requires `--auth-token`; use `--insecure-no-auth` only when a trusted reverse proxy or network boundary authenticates clients. The safety policy is resolved in this order: `--safety`, agent configuration, runtime configuration, then `restricted`. These HTTP-only flags do not affect stdio or `--attach` operation.
+
+## Using with Claude Desktop
+
+Add a configuration to your Claude Desktop MCP settings file:
+
+- **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json`
+- **Windows:** `%APPDATA%\Claude\claude_desktop_config.json`
+
+```json
+{
+  "mcpServers": {
+    "myagent": {
+      "command": "/usr/local/bin/docker",
+      "args": [
+        "agent", 
+        "serve",
+        "mcp",
+        "myorg/coder",
+        "--working-dir",
+        "/home/user/projects"
+      ],
+      "env": {
+        "ANTHROPIC_API_KEY": "your_key_here",
+        "OPENAI_API_KEY": "your_key_here"
+      }
+    }
+  }
+}
+```
+
+Restart Claude Desktop after updating the configuration.
+
+## Using with Claude Code
+
+```bash
+$ claude mcp add --transport stdio myagent \
+  --env OPENAI_API_KEY=$OPENAI_API_KEY \
+  --env ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
+  -- docker agent serve mcp myorg/agent:tag --working-dir $(pwd)
+```
+
+## Multi-Agent in MCP Mode
+
+When you expose a multi-agent configuration via MCP, each agent becomes a separate tool in the MCP client:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Main coordinator
+    sub_agents: [designer, engineer]
+  designer:
+    model: openai/gpt-5-mini
+    description: UI/UX design specialist
+  engineer:
+    model: anthropic/claude-sonnet-4-5
+    description: Software engineer
+```
+
+All three agents (`root`, `designer`, `engineer`) appear as separate tools in Claude Desktop or Claude Code.
+
+## Troubleshooting
+
+- **Agents not appearing:** Verify the `docker-agent` binary path and restart the MCP client
+- **Permission errors:** Ensure `docker-agent` has execute permissions (`chmod +x`)
+- **Missing API keys:** Pass all required keys in the `env` section
+- **Working directory issues:** Verify the `--working-dir` path exists and is accessible
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/remote-mcp/index.md b/_vendor/github.com/docker/docker-agent/docs/features/remote-mcp/index.md
new file mode 100644
index 000000000000..564233bd57c7
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/remote-mcp/index.md
@@ -0,0 +1,308 @@
+---
+title: "Remote MCP Servers"
+description: "Connect Docker Agent to cloud services via remote MCP servers with built-in OAuth authentication."
+keywords: docker agent, ai agents, features, remote mcp servers
+weight: 120
+canonical: https://docs.docker.com/ai/docker-agent/features/remote-mcp/
+---
+
+_Connect Docker Agent to cloud services via remote MCP servers with built-in OAuth authentication._
+
+## Overview
+
+Docker Agent supports connecting to remote MCP servers over **Streamable HTTP**, **SSE** (Server-Sent Events), and **Unix domain sockets**. Streamable HTTP is the current recommended transport for most hosted MCP servers. Many popular services offer MCP endpoints with OAuth — Docker Agent handles the authentication flow automatically.
+
+```yaml
+toolsets:
+  - type: mcp
+    remote:
+      url: "https://mcp.linear.app/mcp"
+      transport_type: "streamable"
+```
+
+## Unix Domain Sockets
+
+Use a `unix://` URL to connect to an MCP server listening on a local Unix socket. This is useful when running Docker Agent inside a container and exposing an MCP server from the host via a bind-mounted socket:
+
+```yaml
+toolsets:
+  - type: mcp
+    remote:
+      url: "unix:///tmp/mcp-notify.sock"
+      transport_type: "streamable"
+```
+
+The path after `unix://` is the absolute path to the socket file. Configured `headers` are forwarded over the socket connection. OAuth discovery is not supported for Unix socket URLs.
+
+> [!TIP]
+> **OAuth flow**
+>
+> When you connect to a remote MCP server that requires OAuth, Docker Agent opens your browser automatically for authentication. Tokens are cached for subsequent sessions.
+
+> [!TIP]
+> **Cancelling the authorization dialog**
+>
+> If you dismiss the OAuth authorization dialog, the request is cancelled cleanly — no repeated prompts appear. The agent will report that authorization was declined. To try again, simply re-enable the server or repeat the request that triggered the flow.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: mcp
+    remote:
+      url: "https://mcp.example.com/mcp"
+      transport_type: "streamable" # or "sse" for legacy servers
+      headers:
+        Authorization: "Bearer ${env.MY_TOKEN}" # resolved per request
+    # Optional: use only for trusted internal/private MCP or OAuth endpoints.
+    allow_private_ips: true
+```
+
+For full configuration details, see the [Tool Config](../../configuration/tools/index.md) page.
+
+Set `allow_private_ips: true` on a remote MCP toolset only when the MCP server or its OAuth registration/token endpoints intentionally resolve to private, loopback, or link-local addresses. The default blocks those OAuth helper requests to reduce SSRF risk.
+
+> [!NOTE]
+> **Headers forwarded during OAuth discovery**
+>
+> Configured `headers` are forwarded to OAuth protected-resource-metadata discovery requests directed at the MCP server's own host — not to third-party authorization servers. This allows services like Grafana Cloud that require a routing header (e.g. `X-Grafana-URL`) on the discovery request to scope the OAuth flow correctly. Headers are never sent to a different host than the one in `remote.url`.
+
+> [!NOTE]
+> **Per-request header template expansion**
+>
+> Header values in `remote.headers` support `${env.VAR}` and `${headers.NAME}` placeholders. Both are resolved on every outbound HTTP request (not just once at initialization), so short-lived credentials and forwarded caller headers always reflect the latest values:
+>
+> - `${env.VAR}` — reads the named environment variable. Useful for credentials stored in a secret manager that rotates them in-process.
+> - `${headers.NAME}` — forwards the named header from the caller's incoming HTTP request. Only meaningful when Docker Agent is running as an API server (`docker agent serve api`) and a client passes authentication headers that the upstream MCP server also accepts.
+
+> [!NOTE]
+> **Automatic reconnection after idle timeouts**
+>
+> Remote MCP connections (Streamable HTTP / SSE) automatically reconnect after the server closes an idle connection — no configuration needed. Services like Notion and Linear close idle connections periodically; Docker Agent detects the clean close and reconnects with exponential backoff. To tune reconnect behaviour or disable reconnection entirely, use the [`lifecycle` block](../../configuration/tools/index.md#toolset-lifecycle).
+
+> [!NOTE]
+> **Automatic recovery from revoked or rotated OAuth tokens**
+>
+> If a remote MCP server rejects the cached token with a `401 invalid_token` error (for example, because the token was revoked or rotated server-side), Docker Agent handles the failure automatically:
+>
+> - **Silent refresh:** when a refresh token is available, Docker Agent silently exchanges it for a new access token and replays the request — no user interaction required.
+> - **Re-authentication prompt:** when the refresh token is absent or has also expired, the toolset transitions to a "needs re-auth" state and surfaces an OAuth prompt on your next message (exactly like the first-time flow).
+>
+> Either way, the agent never burns 5 reconnect attempts on an auth failure — it fails fast and either refreshes silently or defers to interactive re-auth. If you want to trigger re-auth immediately without waiting for the next message, run `/toolset-restart <name>` from the TUI.
+
+### OAuth for servers without Dynamic Client Registration
+
+Most remote MCP servers that require OAuth support [Dynamic Client Registration (RFC 7591)](https://datatracker.ietf.org/doc/html/rfc7591) — no configuration is needed, Docker Agent handles the flow for you.
+
+For servers that do **not** support DCR, Docker Agent falls back automatically:
+
+1. **Interactive credential prompt**: Docker Agent presents a dialog asking for your `client_id` (required) and optionally a `client_secret`. This covers servers that require pre-registered app credentials but don't advertise them via DCR.
+2. **Explicit `oauth:` block** (recommended when you know the credentials in advance): add the block described below to skip the interactive prompt and supply credentials directly in config.
+
+```yaml
+toolsets:
+  - type: mcp
+    remote:
+      url: "https://mcp.example.com/mcp"
+      transport_type: "streamable"
+      oauth:
+        clientId: "my-app-client-id"
+        clientSecret: "my-app-client-secret" # optional (public clients may omit)
+        callbackPort: 8765                   # optional; picks a free port otherwise
+        scopes:                              # optional; server-specific
+          - read
+          - write
+```
+
+| Field          | Type            | Required | Description                                                                                      |
+| -------------- | --------------- | -------- | ------------------------------------------------------------------------------------------------ |
+| `clientId`     | string          | ✗        | OAuth client ID registered with the remote MCP server. When omitted, Docker Agent uses Dynamic Client Registration or prompts interactively. |
+| `clientSecret` | string          | ✗        | OAuth client secret. Requires `clientId`. Omit for public clients using PKCE.                    |
+| `callbackPort` | integer         | ✗        | Local port to receive the OAuth redirect. If omitted, Docker Agent picks a random free port.    |
+| `scopes`       | array[string]   | ✗        | Scopes to request during the authorization step. Values are server-specific.                     |
+| `callbackRedirectURL` | string   | ✗        | Custom OAuth redirect URI. Useful when the auth server requires HTTPS or a pre-registered URL. The literal placeholder `${callbackPort}` is replaced with the actual local callback port. See below.            |
+
+Secrets should be stored in a credential helper or environment variable rather than committed — see [Secrets](../../guides/secrets/index.md) for interpolation patterns.
+
+> [!TIP]
+> The `oauth:` block also works **without** `clientId`. Use it to pin the callback port, request specific scopes, or set a custom redirect URL while still letting Docker Agent obtain the client ID via Dynamic Client Registration (or the interactive prompt).
+
+### Custom redirect URI (`callbackRedirectURL`)
+
+Some authorization servers require the OAuth `redirect_uri` to be HTTPS or to match a URL that was pre-registered during app creation — neither of which plays nicely with a locally-bound loopback address such as `http://127.0.0.1:8765/callback`.
+
+To work around this, set `callbackRedirectURL` to a public URL that redirects back to the local callback server. The literal placeholder `${callbackPort}` is substituted with the actual port the local callback server is listening on (either `callbackPort` when set, or the randomly-assigned port otherwise).
+
+```yaml
+toolsets:
+  - type: mcp
+    remote:
+      url: "https://mcp.example.com/mcp"
+      transport_type: "streamable"
+      oauth:
+        clientId: "my-app-client-id"
+        callbackPort: 8765
+        # Advertise this URL to the authorization server. The external
+        # service at redirect.example.com is expected to 302-redirect the
+        # browser to http://127.0.0.1:8765/callback preserving the query
+        # string (code, state, …).
+        callbackRedirectURL: "https://redirect.example.com/cb?port=${callbackPort}"
+```
+
+The local callback server still listens on the loopback interface on `callbackPort`; only the `redirect_uri` advertised to the authorization server changes.
+
+**Validation rules:**
+
+- The URL must be absolute (scheme + host) once `${callbackPort}` has been substituted.
+- Only `http` and `https` schemes are accepted.
+- `http` is only allowed when the host is a loopback address (`127.0.0.1`, `::1`, `localhost`); any other host must use `https` to avoid exposing the authorization `code` on the wire (RFC 8252 §7.3).
+
+### Unmanaged OAuth flow (server mode)
+
+When running `docker agent serve api` (no local browser, no callback server), the runtime delegates the OAuth dance to the connected client via an MCP elicitation. There are two sub-behaviors, selected by the `--mcp-oauth-redirect-uri` flag:
+
+- **`--mcp-oauth-redirect-uri=<URL>` set** (recommended for hosts like Docker Desktop): the runtime generates `state` + PKCE + (optional) Dynamic Client Registration in-process, builds the full authorize URL, and emits an elicitation whose `Meta` includes:
+
+  | Key                          | Value                                                            |
+  | ---------------------------- | ---------------------------------------------------------------- |
+  | `docker-agent/type`                | `"oauth_flow"`                                                   |
+  | `docker-agent/server_url`          | The MCP server URL (for display / favicon)                       |
+  | `docker-agent/authorize_url`       | The full URL the client should open in the user's browser        |
+  | `docker-agent/state`               | The `state` value the client must echo back when replying        |
+  | `auth_server`                | Issuer of the authorization server                               |
+  | `auth_server_metadata`       | RFC 8414 authorization-server metadata document                  |
+  | `resource_metadata`          | RFC 9728 protected-resource metadata document                    |
+
+  The client opens the browser at the URL provided in the `docker-agent/authorize_url` meta field, receives the OAuth callback at whatever endpoint the configured `redirect_uri` resolves to (typically a host-controlled bouncer that 302s into a deeplink), and replies to the elicitation with `accept` and `Content = {"code": "...", "state": "..."}`. The runtime verifies the `state`, exchanges the `code` at the token endpoint (using the same `redirect_uri` for RFC 6749 §4.1.3 binding), stores the token, and replays the original MCP request with `Authorization: Bearer ...`.
+
+- **Flag not set** (client-driven): the runtime emits the elicitation meta below and expects the client to drive the OAuth flow itself (PKCE, DCR, token exchange) and reply with `Content = {"access_token": "...", "refresh_token": "...", ...}`:
+
+  | Key                          | Value                                                            |
+  | ---------------------------- | ---------------------------------------------------------------- |
+  | `docker-agent/type`          | `"oauth_flow"`                                                   |
+  | `docker-agent/server_url`    | The MCP server URL (for display / favicon)                       |
+  | `auth_server`                | Issuer of the authorization server                               |
+  | `auth_server_metadata`       | RFC 8414 authorization-server metadata document                  |
+  | `resource_metadata`          | RFC 9728 protected-resource metadata document                    |
+
+The client-driven `{access_token, ...}` reply shape is still accepted on the `--mcp-oauth-redirect-uri` path too: a client that prefers to do the exchange itself can ignore the `docker-agent/authorize_url`/`docker-agent/state` keys.
+
+A per-toolset `callbackRedirectURL` (in the YAML) overrides the runtime-wide `--mcp-oauth-redirect-uri` for that toolset.
+
+> [!WARNING]
+> **Security note**
+>
+> The `POST /api/mcp-oauth/callback` route is open by default (no auth required) when `--auth-token` is unset. State values are 128-bit opaque tokens, so brute-force is infeasible, but a state value that leaks (e.g. via debug logs or a compromised host) could be exploited by an attacker to inject a code. Set `--auth-token` when `docker agent serve api` listens on a network-reachable interface. When set, `--auth-token` enforces Bearer-token authentication on all API routes including this callback endpoint.
+
+## Project Management &amp; Collaboration
+
+| Service    | URL                                | Transport | Description                           |
+| ---------- | ---------------------------------- | --------- | ------------------------------------- |
+| Asana      | `https://mcp.asana.com/sse`        | sse       | Task and project management           |
+| Atlassian  | `https://mcp.atlassian.com/v1/mcp/authv2` | streamable | Jira, Confluence integration          |
+| Linear     | `https://mcp.linear.app/mcp`       | streamable | Issue tracking and project management |
+| Monday.com | `https://mcp.monday.com/sse`       | sse       | Work management platform              |
+| Intercom   | `https://mcp.intercom.com/sse`     | sse       | Customer communication platform       |
+
+## Development &amp; Infrastructure
+
+| Service                  | URL                                            | Transport  | Description                       |
+| ------------------------ | ---------------------------------------------- | ---------- | --------------------------------- |
+| GitHub                   | `https://api.githubcopilot.com/mcp`            | sse        | Version control and collaboration |
+| Buildkite                | `https://mcp.buildkite.com/mcp`                | streamable | CI/CD platform                    |
+| Netlify                  | `https://netlify-mcp.netlify.app/mcp`          | streamable | Web hosting and deployment        |
+| Vercel                   | `https://mcp.vercel.com/`                      | sse        | Web deployment platform           |
+| Cloudflare Bindings      | `https://bindings.mcp.cloudflare.com/sse`      | sse        | Edge computing resources          |
+| Cloudflare Observability | `https://observability.mcp.cloudflare.com/sse` | sse        | Monitoring and analytics          |
+| Grafbase                 | `https://api.grafbase.com/mcp`                 | streamable | GraphQL backend platform          |
+| Neon                     | `https://mcp.neon.tech/sse`                    | sse        | Serverless Postgres database      |
+| Prisma                   | `https://mcp.prisma.io/mcp`                    | streamable | Database ORM and toolkit          |
+| Sentry                   | `https://mcp.sentry.dev/sse`                   | sse        | Error tracking and monitoring     |
+
+## Content &amp; Media
+
+| Service    | URL                                               | Transport  | Description                       |
+| ---------- | ------------------------------------------------- | ---------- | --------------------------------- |
+| Canva      | `https://mcp.canva.com/mcp`                       | streamable | Design and graphics platform      |
+| Miro       | `https://mcp.miro.com/`                           | streamable | Collaborative whiteboard platform (Enterprise plan required; see [official docs](https://developers.miro.com/docs/miro-mcp)) |
+| Cloudinary | `https://asset-management.mcp.cloudinary.com/sse` | sse        | Media management and optimization |
+| InVideo    | `https://mcp.invideo.io/sse`                      | sse        | Video creation platform           |
+| Webflow    | `https://mcp.webflow.com/sse`                     | sse        | Website builder and CMS           |
+| Wix        | `https://mcp.wix.com/sse`                         | sse        | Website builder platform          |
+| Notion     | `https://mcp.notion.com/mcp`                      | streamable | Documentation and knowledge base  |
+
+## Communication &amp; Voice
+
+| Service     | URL                                 | Transport  | Description                 |
+| ----------- | ----------------------------------- | ---------- | --------------------------- |
+| Fireflies   | `https://api.fireflies.ai/mcp`      | streamable | Meeting transcription       |
+| Listenetic  | `https://mcp.listenetic.com/v1/mcp` | streamable | Audio intelligence platform |
+| Carbonvoice | `https://mcp.carbonvoice.app`       | sse        | Voice communication tools   |
+| Telnyx      | `https://api.telnyx.com/v2/mcp`     | streamable | Communications platform     |
+| Dialer      | `https://getdialer.app/sse`         | sse        | Phone communication tools   |
+
+## Storage &amp; File Management
+
+| Service | URL                                 | Transport | Description              |
+| ------- | ----------------------------------- | --------- | ------------------------ |
+| Box     | `https://mcp.box.com`               | sse       | Cloud content management |
+| Egnyte  | `https://mcp-server.egnyte.com/sse` | sse       | Enterprise file sharing  |
+
+## Business &amp; Finance
+
+| Service       | URL                                       | Transport  | Description                |
+| ------------- | ----------------------------------------- | ---------- | -------------------------- |
+| PayPal        | `https://mcp.paypal.com/sse`              | sse        | Payment processing         |
+| Plaid         | `https://api.dashboard.plaid.com/mcp/sse` | sse        | Financial data integration |
+| Square        | `https://mcp.squareup.com/sse`            | sse        | Payment processing         |
+| Close         | `https://mcp.close.com/mcp`               | streamable | CRM platform               |
+| Dodo Payments | `https://mcp.dodopayments.com/sse`        | sse        | Payment processing         |
+
+## Analytics &amp; Data
+
+| Service     | URL                                     | Transport  | Description                    |
+| ----------- | --------------------------------------- | ---------- | ------------------------------ |
+| ThoughtSpot | `https://agent.thoughtspot.app/mcp`     | streamable | Analytics and BI platform      |
+| Meta Ads    | `https://mcp.pipeboard.co/meta-ads-mcp` | streamable | Facebook advertising analytics |
+
+## Utilities &amp; Tools
+
+| Service       | URL                                | Transport  | Description                     |
+| ------------- | ---------------------------------- | ---------- | ------------------------------- |
+| Apify         | `https://mcp.apify.com`            | sse        | Web scraping and automation     |
+| SimpleScraper | `https://mcp.simplescraper.io/mcp` | streamable | Web scraping tool               |
+| GlobalPing    | `https://mcp.globalping.dev/sse`   | sse        | Network diagnostics             |
+| Jam           | `https://mcp.jam.dev/mcp`          | streamable | Bug reporting and collaboration |
+
+## Example: Multi-Service Agent
+
+Combine multiple remote MCP servers in a single agent:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    instruction: |
+      You help manage projects and deployments.
+    toolsets:
+      - type: mcp
+        remote:
+          url: "https://mcp.linear.app/mcp"
+          transport_type: "streamable"
+        instruction: Use Linear for issue tracking.
+      - type: mcp
+        remote:
+          url: "https://api.githubcopilot.com/mcp"
+          transport_type: "sse"
+        instruction: Use GitHub for code and PRs.
+      - type: mcp
+        remote:
+          url: "https://mcp.vercel.com/"
+          transport_type: "sse"
+        instruction: Use Vercel for deployments.
+```
+
+> [!NOTE]
+> **Growing list**
+>
+> This list is updated as more services add MCP support. If a service you use isn't listed, check their documentation — many providers are adding MCP endpoints regularly.
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/sessions/index.md b/_vendor/github.com/docker/docker-agent/docs/features/sessions/index.md
new file mode 100644
index 000000000000..dd264814b476
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/sessions/index.md
@@ -0,0 +1,135 @@
+---
+title: "Sessions"
+description: "How Docker Agent stores conversations, resumes them across runs, and tracks their token cost."
+keywords: docker agent, ai agents, features, sessions
+weight: 25
+canonical: https://docs.docker.com/ai/docker-agent/features/sessions/
+---
+
+_How Docker Agent stores conversations, resumes them across runs, and tracks their token cost._
+
+## What a Session Is
+
+Every `docker agent run` creates or resumes a **session**: the record of a conversation, including every message, tool call, sub-agent run, and cost. Sessions are what makes `/undo`, `/sessions`, `--session <id>`, and cost tracking possible — the agent itself is stateless between runs, but the session is not.
+
+A session is only persisted to disk once it has content (the first message added), so a run you cancel before sending anything never leaves an empty session behind.
+
+## Where Sessions Are Stored
+
+Sessions live in a SQLite database, `session.db`, under the [data directory](../cli/index.md#global-flags) (`~/.cagent` by default):
+
+```bash
+$ ls ~/.cagent/session.db
+```
+
+Override the location with `-s`/`--session-db`, or by overriding the data directory itself with `--data-dir`:
+
+```bash
+# Use a project-local session database instead of the global one
+$ docker agent run agent.yaml --session-db ./sessions.db
+```
+
+## Resuming a Session
+
+Pass `--session <id>` to continue a previous conversation instead of starting a new one:
+
+```bash
+# Resume by explicit session ID
+$ docker agent run agent.yaml --session 3f9c1e2a-...
+
+# Resume the most recently created session
+$ docker agent run agent.yaml --session -1
+
+# Resume the session created before that one
+$ docker agent run agent.yaml --session -2
+```
+
+`--session` accepts two kinds of reference:
+
+- **A relative offset** (`-1`, `-2`, …): sessions are ordered by **creation time**, newest first — `-1` is the most recently *created* session, `-2` the one created before it, and so on. This is creation order, not last-used order: resuming an older session with `--session <id>` does not make it the new `-1`; the next `-1` still resolves to whichever session was created most recently. A relative offset that has no matching session (for example `-1` with an empty database) is an error.
+- **An explicit ID**: if a session with that ID already exists, it is resumed. If it doesn't exist yet, docker agent **creates it with that ID** instead of failing. This lets a supervisor (for example a board or a script) choose a session ID up front and reuse it across runs — the first run creates the session, later runs resume it.
+
+## Read-Only Sessions
+
+Add `--session-read-only` to open a session for viewing without sending new messages — useful for reviewing a past conversation without accidentally continuing it:
+
+```bash
+$ docker agent run agent.yaml --session -1 --session-read-only
+```
+
+`--session-read-only` requires the TUI: it cannot be combined with `--exec`, since there would be nothing to display without one.
+
+## Browsing Sessions in the TUI
+
+Press `/sessions` to open the session browser: search and filter past conversations, see which ones were started in the current working directory ("This workspace") versus elsewhere ("Other locations"), and restore one with <kbd>Enter</kbd>. Restoring a session reopens it in its original working directory. See [Session Management](../tui/index.md#session-management) in the Terminal UI docs for the full set of session-browser and session-title features (starring, branching by editing a past message, and so on).
+
+### Tabs
+
+<kbd>Ctrl</kbd>+<kbd>T</kbd> opens a new tab running an additional agent session alongside the current one; <kbd>Ctrl</kbd>+<kbd>N</kbd>/<kbd>Ctrl</kbd>+<kbd>P</kbd> cycle between tabs and <kbd>Ctrl</kbd>+<kbd>W</kbd> closes the current one. By default, tabs are not restored the next time you launch the TUI. Set `restore_tabs: true` in your user config to reopen the same tabs (and their sessions) on the next launch:
+
+```yaml
+# ~/.config/cagent/config.yaml
+settings:
+  restore_tabs: true
+```
+
+## Session Titles
+
+Docker Agent auto-generates a short title for each session from your first message, using a one-shot call to the agent's own model. Point that call at a smaller, cheaper model instead with `title_model` on a model definition:
+
+```yaml
+# examples/title_model.yaml
+models:
+  primary:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    # Generate session titles with the cheaper Haiku model instead of Sonnet.
+    title_model: fast
+  fast:
+    provider: anthropic
+    model: claude-haiku-4-5
+
+agents:
+  root:
+    model: primary
+    description: An assistant that generates session titles with a cheaper model.
+    instruction: You are a helpful assistant.
+```
+
+When `title_model` is omitted, title generation reuses the agent's own model. Set or regenerate a title from inside the TUI with `/title` (see [Session Title Editing](../tui/index.md#session-title-editing)) — regenerating sends every user message in the session so far, not just the first — or generate one from the command line without starting a session at all:
+
+```bash
+$ docker agent debug title agent.yaml "How do I configure a fallback model?"
+```
+
+See [`docker agent debug title`](../cli/index.md#docker-agent-debug) for details.
+
+## Usage & Cost Tracking
+
+Every tracked model call — the main conversation turns and compaction calls — updates the session's cumulative input/output token counts and cost. Check them at any time with `/cost` in the TUI, or disable tracking per-model with `track_usage: false` if you don't want a model's calls counted (for example, a free local model). Auxiliary one-shot calls the runtime makes on your behalf, such as automatic session-title generation, call the model directly and are not folded into this total.
+
+Cost is computed from the [models.dev](https://models.dev/) pricing catalogue by default. For a custom endpoint, a private deployment, or a negotiated enterprise rate the catalogue doesn't know about, declare pricing explicitly with a model's `cost:` block:
+
+```yaml
+# examples/custom-pricing.yaml
+models:
+  internal-gpt:
+    provider: internal-llm
+    model: gpt-4o
+    cost:
+      input: 1.25 # USD per 1M input tokens
+      output: 5.00 # USD per 1M output tokens
+      cache_read: 0.125 # USD per 1M cached input tokens
+      cache_write: 1.5625 # USD per 1M cache-write tokens
+```
+
+An all-zero `cost:` table means "priced, free" — distinct from a model with no `cost:` at all, which falls back to the catalogue (and bills $0 for models the catalogue doesn't know).
+
+> [!NOTE]
+> **Cost never decreases**
+>
+> A session's cumulative cost is a running total updated after every *tracked* model call — the same main conversation turns and compaction calls described above. Compacting the conversation (manually with `/compact`, or automatically — see the agent's `session_compaction`/`compaction_threshold` fields in the [Agent Config reference](../../configuration/agents/index.md)) reshapes the message history sent back to the model, but never touches this running total. Auxiliary one-shot calls such as automatic session-title generation are not tracked and are not reflected in this total: `/cost` covers everything the session's tracked calls have spent, not literally every model call the runtime makes on your behalf.
+
+## Resuming Into a Worktree
+
+A session created during a `--worktree` run remembers which worktree it used. Resuming it with `--session` reattaches to the same worktree directory and branch automatically — you don't need to pass `--worktree` again. See [`--worktree`](../cli/index.md#docker-agent-run) in the CLI reference for the full worktree lifecycle.
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md b/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md
new file mode 100644
index 000000000000..bba760387a0a
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md
@@ -0,0 +1,378 @@
+---
+title: "Skills"
+description: "Skills provide specialized instructions that agents can load on demand when a task matches a skill's description."
+keywords: docker agent, ai agents, features, skills
+weight: 110
+canonical: https://docs.docker.com/ai/docker-agent/features/skills/
+---
+
+_Skills provide specialized instructions that agents can load on demand when a task matches a skill's description._
+
+## How Skills Work
+
+1. Docker Agent scans standard directories for `SKILL.md` files
+2. Skill metadata (name, description) is injected into the agent's system prompt
+3. When a user request matches a skill, the agent reads the full instructions
+4. The agent follows the skill's detailed instructions to complete the task
+
+## Enabling Skills
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-4o
+    instruction: You are a helpful assistant.
+    skills: true
+    toolsets:
+      - type: filesystem # required for reading skill files
+```
+
+> [!TIP]
+> Skills are perfect for encoding team-specific workflows (PR review, deployment, coding standards) that apply across projects.
+
+## Filtering Skills
+
+The `skills` field also accepts a list, letting you restrict the agent to a specific subset of skills instead of exposing every discovered one. List items are classified automatically:
+
+- `"local"` or any `http://` / `https://` URL → a **source** to load skills from
+- any other string → the **name** of a skill to include
+
+When only names are given, local sources are used by default.
+
+```yaml
+agents:
+  # Load every discovered local skill (same as `skills: true`).
+  full:
+    skills: true
+
+  # Load local skills, but only expose "commit" and "poem".
+  scoped:
+    skills:
+      - commit
+      - poem
+
+  # Combine an explicit source with a name filter.
+  remote_filtered:
+    skills:
+      - https://skills.example.com
+      - commit
+
+  # Disable skills entirely.
+  none:
+    skills: false
+```
+
+A name that doesn't match any discovered skill is logged as a warning at startup but is otherwise ignored.
+
+## Inline Skills
+
+Instead of (or alongside) loading skills from files and URLs, you can define skills directly in the agent config. An inline skill is a mapping item in the `skills` list, freely mixed with the string items above:
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-4o
+    instruction: You are a helpful assistant.
+    skills:
+      - name: changelog
+        description: Write a concise changelog entry from a diff or description.
+        instructions: |
+          Produce a single changelog entry in Keep a Changelog style.
+          Pick the right category (Added, Changed, Fixed, Removed) and write
+          one imperative sentence summarising the user-visible change.
+
+      # A fork-mode inline skill runs in an isolated sub-agent.
+      - name: triage
+        description: Triage a bug report in an isolated context.
+        context: fork
+        instructions: |
+          Restate the problem, list likely root causes most-probable-first,
+          and propose the smallest reproduction and next concrete action.
+
+      # Inline skills mix freely with sources and name filters.
+      - local
+    toolsets:
+      - type: filesystem
+```
+
+Inline skills carry their body in the config itself, so they need no `SKILL.md` file and require no filesystem source. They are **always exposed** — the name filter only applies to file- and URL-based skills. Because inline skills travel inside the agent YAML, they also work in `--sandbox` mode without any kit staging, and they can be shared with the agent via `share push`.
+
+### Inline Skill Fields
+
+| Field           | Required | Description                                                                |
+| --------------- | -------- | -------------------------------------------------------------------------- |
+| `name`          | Yes      | Skill identifier used by `read_skill` / `run_skill` and the `/<name>` command |
+| `description`   | Yes      | Short description shown to the agent for skill matching                    |
+| `instructions`  | Yes      | The skill body (what a `SKILL.md` would contain below its frontmatter)     |
+| `context`       | No       | Set to `fork` to run the skill as an isolated sub-agent                    |
+| `model`         | No       | Override the model used while running a fork-mode skill                    |
+| `allowed_tools` | No       | For a fork-mode skill, restricts the sub-session to the parent tools whose names match an entry (glob or exact). See [Scoping a fork skill's tools](#scoping-a-fork-skills-tools). |
+| `toolsets`      | No       | For a fork-mode skill, names of top-level [`toolsets`](../../configuration/overview/index.md#reusable-toolsets-toolsets) to expose in the sub-session on top of the inherited tools. |
+
+> [!NOTE]
+> **Inline vs. file-based skills**
+>
+> Inline skills support the subset of the SKILL.md format that fits in YAML. They cannot bundle supporting files (no `read_skill_file`) or use `` !`command` `` expansion. For skills that need bundled resources or executable helpers, use a `SKILL.md` directory instead.
+
+## SKILL.md Format
+
+<!-- yaml-lint:skip -->
+```yaml
+---
+name: create-dockerfile
+description: Create optimized Dockerfiles for applications
+license: Apache-2.0
+metadata:
+  author: my-org
+  version: "1.0"
+---
+
+# Creating Dockerfiles
+
+When asked to create a Dockerfile:
+
+1. Analyze the application type and language
+2. Use multi-stage builds for compiled languages
+3. Minimize image size by using slim base images
+4. Follow security best practices (non-root user, etc.)
+```
+
+### Frontmatter Fields
+
+| Field            | Required | Description                                                                 |
+| ---------------- | -------- | --------------------------------------------------------------------------- |
+| `name`           | Yes      | Unique skill identifier                                                     |
+| `description`    | Yes      | Short description shown to the agent for skill matching                     |
+| `context`        | No       | Set to `fork` to run the skill as an isolated sub-agent (see below)         |
+| `model`          | No       | Override the model used while running the skill as a sub-agent (fork only)  |
+| `allowed-tools`  | No       | For a fork-mode skill, restricts the sub-session to the parent tools whose names match an entry (YAML list or comma-separated string). See [Scoping a fork skill's tools](#scoping-a-fork-skills-tools). |
+| `toolsets`       | No       | For a fork-mode skill, names of top-level [`toolsets`](../../configuration/overview/index.md#reusable-toolsets-toolsets) to expose in the sub-session (YAML list or comma-separated string). |
+| `license`        | No       | License identifier (e.g. `Apache-2.0`)                                      |
+| `compatibility`  | No       | Free-text compatibility notes                                               |
+| `metadata`       | No       | Arbitrary key-value pairs (e.g. `author`, `version`)                        |
+
+## Running a Skill as a Sub-Agent
+
+By default, when an agent invokes a skill it reads the instructions inline into its own conversation. For complex, multi-step skills this can consume a large portion of the agent's context window and pollute the parent conversation with intermediate tool calls.
+
+Adding `context: fork` to the SKILL.md frontmatter tells the agent to run the skill in an **isolated sub-agent** instead:
+
+<!-- yaml-lint:skip -->
+```yaml
+---
+name: bump-go-dependencies
+description: Update Go module dependencies one by one
+context: fork
+---
+
+# Bump Dependencies
+
+1. List outdated deps
+2. Update each one, run tests, commit or revert
+3. Produce a summary table
+```
+
+When the agent encounters a task that matches a `context: fork` skill, it uses the `run_skill` tool instead of `read_skill`. This:
+
+- **Spawns a child session** with the skill content as the system prompt and the caller's task as the user message
+- **Isolates the context window** — the sub-agent has its own conversation history, so lengthy tool-call chains don't eat into the parent's token budget
+- **Folds the result** — only the sub-agent's final answer is returned to the parent as the tool result
+- **Inherits the parent's model and tools** — the sub-agent can use all tools available to the parent agent (scope this with `allowed_tools` / `toolsets`, see [Scoping a fork skill's tools](#scoping-a-fork-skills-tools))
+
+> [!TIP]
+> **When to use context: fork**
+>
+> Use `context: fork` for skills that involve many steps, heavy tool usage, or that should not clutter the main conversation — for example dependency bumping, large refactors, or code generation pipelines.
+
+### Overriding the model for a fork skill
+
+Fork skills can declare a `model` field in their frontmatter to use a
+different model than the parent agent for the duration of the sub-session.
+This is useful when a skill is best handled by a faster, cheaper, or more
+specialised model — for example a powerful reasoning model for refactors,
+or a fast model for routine bookkeeping work. The override only applies
+while the skill is running; the parent agent keeps its own model.
+
+The `model` value accepts either a named model from the agent config or
+an inline `provider/model` reference (and the same comma-separated alloy
+syntax as the rest of the agent config):
+
+<!-- yaml-lint:skip -->
+```yaml
+---
+name: bump-go-dependencies
+description: Update Go module dependencies one by one
+context: fork
+model: openai/gpt-4o-mini
+---
+
+# Bump Dependencies
+
+1. ...
+```
+
+If the model reference cannot be resolved (unknown name, missing
+credentials, runtime not configured for model switching, …) the skill
+falls back to the agent's currently-active model (its configured
+default, or any override the user previously set via the model picker)
+and a warning is logged.
+
+When the skill completes, the agent's previous model is restored — but
+only if no one else changed the model in the meantime. If the user
+switches the model via the TUI model picker while the fork skill is
+running, their choice is preserved (the deferred restore becomes a
+no-op).
+
+### Scoping a fork skill's tools
+
+By default a fork skill inherits the parent agent's entire tool set. Two
+optional fields let you scope what the sub-session can use. Both apply
+**only to fork-mode skills** and work the same whether the skill is
+inline or loaded from a `SKILL.md` file.
+
+`allowed_tools` (frontmatter: `allowed-tools`) is an **allow-list** over
+the inherited tools: only tools whose names match an entry are kept,
+everything else is hidden from the sub-session. Entries support glob
+patterns (e.g. `read_*`) and otherwise match exactly. This is the
+Claude-Code-compatible `allowed-tools` field, now enforced for fork
+skills rather than merely recorded.
+
+`toolsets` references reusable [top-level toolsets](../../configuration/overview/index.md#reusable-toolsets-toolsets)
+by name. The referenced toolsets are exposed in the sub-session **in
+addition to** the inherited tools, and they bypass the `allowed_tools`
+filter (the skill explicitly asked for them).
+
+```yaml
+toolsets:
+  web:
+    type: fetch
+
+agents:
+  root:
+    model: openai/gpt-4o
+    instruction: You are a helpful assistant.
+    toolsets:
+      - type: filesystem
+      - type: shell
+    skills:
+      # Inherits the parent tools but is restricted to read-only filesystem
+      # access while it runs — shell and write tools are hidden.
+      - name: audit
+        description: Review the repository layout without modifying anything.
+        context: fork
+        allowed_tools:
+          - read_file
+          - list_directory
+          - directory_tree
+        instructions: Inspect the repository structure and summarise it.
+
+      # Brings in the top-level `web` toolset on top of the parent's tools.
+      - name: research
+        description: Research a topic using web fetches in an isolated context.
+        context: fork
+        toolsets:
+          - web
+        instructions: Research the requested topic and summarise with links.
+```
+
+The equivalent in a `SKILL.md` file uses frontmatter lists:
+
+<!-- yaml-lint:skip -->
+```yaml
+---
+name: research
+description: Research a topic using web fetches
+context: fork
+allowed-tools:
+  - fetch
+toolsets:
+  - web
+---
+```
+
+> [!NOTE]
+> **Fork only**
+>
+> Both fields are rejected by config validation when set on a non-fork skill, and a `toolsets` entry that doesn't resolve to a top-level toolset is a load-time error.
+
+## Search Paths
+
+Skills are discovered from these locations (later overrides earlier):
+
+### Global
+
+| Path                | Search Type                             |
+| ------------------- | --------------------------------------- |
+| `~/.codex/skills/`  | Recursive (searches all subdirectories) |
+| `~/.claude/skills/` | Flat (immediate children only)          |
+| `~/.agents/skills/` | Recursive (searches all subdirectories) |
+
+### Project (from git root to current directory)
+
+| Path              | Search Type                                |
+| ----------------- | ------------------------------------------ |
+| `.claude/skills/` | Flat (cwd only)                            |
+| `.github/skills/` | Flat (each directory from git root to cwd) |
+| `.agents/skills/` | Flat (each directory from git root to cwd) |
+
+## Invoking Skills
+
+Skills can be invoked in multiple ways:
+
+- **Automatic:** The agent detects when your request matches a skill's description and loads it automatically
+- **Explicit:** Reference the skill name in your prompt: "Use the create-dockerfile skill to..."
+- **Slash command:** Use `/{skill-name}` to invoke a skill directly
+
+```bash
+# In the TUI, invoke skill directly:
+/create-dockerfile
+
+# Or mention it in your message:
+"Create a dockerfile for my Python app (use the create-dockerfile skill)"
+```
+
+## Precedence
+
+When multiple skills share the same name:
+
+1. Global skills load first
+2. Project skills load next, from git root toward current directory
+3. Skills closer to the current directory override those further away
+4. At the same directory level, `.agents/skills/` overrides `.github/skills/`
+
+## Skills in Sandbox Mode
+
+When you run an agent with [`--sandbox`](../../configuration/sandbox/index.md), the sandbox VM has its own filesystem with no access to your host's skill directories. Docker Agent handles this transparently via the [auto-kit](../../configuration/sandbox/index.md#auto-kit): every discovered local skill is staged into a per-agent kit on the host, run through best-effort secret redaction (see the [auto-kit](../../configuration/sandbox/index.md#secret-redaction) docs), and bind-mounted read-only into the sandbox so the agent sees the same skills inside the VM as on the host. No configuration is required — use `--no-kit` only if you explicitly want to run the sandbox without any host skills.
+
+## Creating a Skill
+
+```bash
+# Create the skill directory
+$ mkdir -p ~/.agents/skills/create-dockerfile
+
+# Write the SKILL.md file
+$ cat > ~/.agents/skills/create-dockerfile/SKILL.md << 'EOF'
+---
+name: create-dockerfile
+description: Create optimized Dockerfiles for applications
+---
+
+# Creating Dockerfiles
+
+When asked to create a Dockerfile:
+
+1. Analyze the application type and language
+2. Use multi-stage builds for compiled languages
+3. Use slim base images to minimize size
+4. Run as non-root user for security
+EOF
+```
+
+The skill will automatically be available to any agent with skills enabled (`skills: true`, or a list that targets its name — see [Filtering Skills](#filtering-skills)).
+
+> [!NOTE]
+> **See also**
+>
+> Skills are enabled in the [Agent Config](../../configuration/agents/index.md) with the `skills` property (boolean or list). For tool-based capabilities, see [Tools](../../concepts/tools/index.md).
+>
+> Example configs: [`examples/skills_inline.yaml`](https://github.com/docker/docker-agent/blob/main/examples/skills_inline.yaml) (inline skill definition), [`examples/skills_fork_toolsets.yaml`](https://github.com/docker/docker-agent/blob/main/examples/skills_fork_toolsets.yaml) (scoping a fork skill's tools), [`examples/skills_filter.yaml`](https://github.com/docker/docker-agent/blob/main/examples/skills_filter.yaml) (filtering which skills load).
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/snapshots/index.md b/_vendor/github.com/docker/docker-agent/docs/features/snapshots/index.md
new file mode 100644
index 000000000000..bc624bf89123
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/snapshots/index.md
@@ -0,0 +1,112 @@
+---
+title: "Snapshots"
+description: "Shadow-git snapshots capture your workspace at turn boundaries so you can review what an agent changed and undo it without touching your real git history."
+keywords: docker agent, ai agents, features, snapshots
+weight: 20
+canonical: https://docs.docker.com/ai/docker-agent/features/snapshots/
+---
+
+_Shadow-git snapshots capture your workspace at turn boundaries so you can review what an agent changed and undo it without touching your real git history._
+
+## Overview
+
+When snapshots are enabled, Docker Agent records the state of your working
+directory as the agent runs. Each checkpoint is stored in a **shadow git
+repository** kept under the Docker Agent data directory — completely separate
+from your project's own `.git`. This lets you:
+
+- **Review** exactly which files an agent touched on a given turn.
+- **Undo** the most recent change with `/undo`.
+- **Reset** the workspace back to any earlier checkpoint — or all the way to
+  its pre-agent state.
+
+Snapshots only ever touch files on disk. They never write commits to your
+repository, never move your `HEAD`, and never appear in `git log` or
+`git status`.
+
+> [!NOTE]
+> **Git repositories only**
+>
+> The snapshot machinery is a no-op outside a git worktree. It needs a git
+> repository to scope which files belong to your project and to mirror the
+> repository's ignore rules.
+
+## Enabling Snapshots
+
+The simplest way is to enable snapshots globally for every agent in your user
+config:
+
+```yaml
+# ~/.config/cagent/config.yaml
+settings:
+  snapshot: true
+```
+
+Omit `snapshot` or set it to `false` to leave automatic snapshots off.
+
+You can also wire the [`snapshot` built-in hook](../../configuration/hooks/index.md#available-built-ins)
+into a single agent instead of enabling it globally:
+
+```yaml
+hooks:
+  turn_start:
+    - type: builtin
+      command: snapshot
+  turn_end:
+    - type: builtin
+      command: snapshot
+  session_end:
+    - type: builtin
+      command: snapshot
+```
+
+Manually configured snapshot hooks always run, even when `settings.snapshot`
+is unset. See [`examples/snapshot_hooks.yaml`](https://github.com/docker/docker-agent/blob/main/examples/snapshot_hooks.yaml)
+for a complete configuration.
+
+## Using Snapshots in the TUI
+
+When snapshots are enabled, the [TUI](../tui/index.md)
+exposes two slash commands:
+
+- **`/undo`** restores files from the most recent snapshot (one step back).
+- **`/snapshots`** opens a dialog listing every captured snapshot and the
+  number of files in each. Use <kbd>↑</kbd>/<kbd>↓</kbd> (or
+  <kbd>j</kbd>/<kbd>k</kbd>) to highlight an entry, then press <kbd>r</kbd> to
+  reset the workspace to that point. Pick `<original>` to revert every snapshot
+  and bring the workspace back to its pre-agent state. <kbd>Esc</kbd> closes the
+  dialog without changing anything.
+
+Neither command removes messages from the session transcript — they only touch
+files on disk. Both commands (and their command-palette entries) are hidden
+when snapshots are turned off.
+
+## How It Works
+
+- **Shadow repository.** The first time a snapshot is taken for a worktree,
+  Docker Agent initializes a separate shadow git directory under the data
+  directory (`~/.cagent/snapshot/...` by default), keyed by a hash of the
+  worktree path. The shadow repo stores tree objects only — it never writes
+  commits and never touches your source repository's `.git`.
+- **Ignore rules are mirrored.** Before each capture, the source repository's
+  `.gitignore` and `info/exclude` rules are mirrored into the shadow repo so
+  ignored files never appear in snapshots.
+- **Large files are skipped.** Newly-added files larger than 2 MiB are excluded
+  from snapshots to keep the shadow repo small.
+- **Checkpoints only on change.** A checkpoint is recorded only when files
+  actually changed, so a final no-op model response does not hide the last
+  meaningful snapshot.
+- **Scoped to the working directory.** Snapshot operations are scoped to the
+  agent's working directory within the worktree, so a sub-directory agent only
+  captures and restores files under that directory.
+- **Garbage collection.** Wiring `snapshot` into `session_end` (or enabling it
+  globally) runs `git gc` against the shadow repo so old, unreferenced objects
+  are pruned over time.
+
+## See Also
+
+- [Hooks](../../configuration/hooks/index.md) — the `snapshot`
+  built-in and the events it can run on.
+- [Terminal UI](../tui/index.md) — the `/undo` and
+  `/snapshots` commands.
+- [`examples/snapshot_hooks.yaml`](https://github.com/docker/docker-agent/blob/main/examples/snapshot_hooks.yaml) — a complete snapshot hook configuration.
diff --git a/_vendor/github.com/docker/docker-agent/docs/features/tui/index.md b/_vendor/github.com/docker/docker-agent/docs/features/tui/index.md
new file mode 100644
index 000000000000..5a06b6ebbc88
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/features/tui/index.md
@@ -0,0 +1,591 @@
+---
+title: "Terminal UI (TUI)"
+description: "Docker Agent's default interface is a rich, interactive terminal UI with file attachments, themes, session management, and more."
+keywords: docker agent, ai agents, features, terminal ui (tui)
+linkTitle: "Terminal UI"
+weight: 10
+canonical: https://docs.docker.com/ai/docker-agent/features/tui/
+---
+
+_Docker Agent's default interface is a rich, interactive terminal UI with file attachments, themes, session management, and more._
+
+![Docker Agent TUI in action showing an interactive agent session](../../demo.gif)
+
+## Launching the TUI
+
+Both the full TUI and the lean TUI display a centered ASCII art Docker Agent banner on startup when the chat is empty. The banner is automatically hidden once the agent starts responding or when a custom welcome message is configured.
+
+```bash
+# Launch with a config
+$ docker agent run agent.yaml
+
+# Start with an initial message
+$ docker agent run agent.yaml "Help me refactor this code"
+
+# Auto-approve all tool calls
+$ docker agent run agent.yaml --yolo
+
+# Enable debug logging
+$ docker agent run agent.yaml --debug
+
+# Override the application name shown in the status bar and window title
+$ docker agent run agent.yaml --app-name "My Project"
+
+# Preselect a color theme
+$ docker agent run agent.yaml --theme dracula
+
+# Hide the sidebar (cannot be re-enabled via Ctrl+B)
+$ docker agent run agent.yaml --sidebar=false
+
+# Disable specific slash commands
+$ docker agent run agent.yaml --disable-commands="/cost,/eval,/model"
+
+# Open in read-only mode to review a past session without sending new messages
+$ docker agent run agent.yaml --session -1 --session-read-only
+
+# Use the lean TUI for this run
+$ docker agent run agent.yaml --lean
+```
+
+### Lean TUI
+
+The lean TUI uses a simplified terminal interface with minimal chrome. To make it the default for interactive runs, set `lean` in your user config:
+
+```yaml
+# ~/.config/cagent/config.yaml
+settings:
+  lean: true
+```
+
+Omit `lean` or set it to `false` to keep the full TUI as the default. You can still use `--lean` for a single run, or `--lean=false` to use the full TUI when `settings.lean` is enabled. See [User Settings](../../configuration/user-settings/index.md) for the full precedence rules between flags and user config.
+
+The lean TUI supports **steering** and **follow-ups** while the agent is running. Press <kbd>Enter</kbd> to steer the active turn, or <kbd>Alt</kbd>+<kbd>Enter</kbd> to queue the message as a separate turn after the current one finishes. Pending messages appear with muted styling at the end of the live stream.
+
+The lean TUI supports a focused set of slash commands: `/new`, `/compact`, `/model`, `/effort`, `/clear`, `/help`, `/exit` (alias: `/quit`), plus any agent-defined commands. Type `/model` (or `/model <provider/model>`) to switch the active model inline — the command opens a fuzzy-searchable list of available models.
+
+## Slash Commands
+
+Type `/` during a session to see available commands, or press <kbd>Ctrl</kbd>+<kbd>K</kbd> for the command palette:
+
+| Command            | Description                                                                          |
+| ------------------ | ------------------------------------------------------------------------------------ |
+| `/new`             | Start a new conversation                                                             |
+| `/clear`           | Clear the current conversation (keep session, drop messages)                         |
+| `/compact`         | Summarize and compact the conversation history                                       |
+| `/fork`            | Fork the current session into a new branch                                           |
+| `/copy`            | Copy the entire conversation to clipboard                                            |
+| `/copy-last`       | Copy only the last assistant message to clipboard                                    |
+| `/undo`            | Restore file changes from the latest snapshot (only when snapshots are enabled)      |
+| `/snapshots`       | List captured snapshots (only when snapshots are enabled)                            |
+| `/export`          | Export the session as HTML                                                           |
+| `/sessions`        | Browse and load past sessions                                                        |
+| `/plans`           | Browse and manage plans: every [shared plan](../../tools/plan/index.md) plus the current session's [session plan](../../tools/session_plan/index.md). Filter, open a detail view, refresh, export to a file, and — for shared plans — set status, edit/create in `$VISUAL`/`$EDITOR`, and delete, all guarded against concurrent edits. Not available in the lean TUI |
+| `/model`           | Change the model for the current agent                                               |
+| `/effort`          | Set the current model's reasoning-effort level (`/effort <none\|minimal\|low\|medium\|high\|xhigh\|max>`, or `/effort` alone to pick from the supported levels; reasoning models only). Press <kbd>Tab</kbd> after `/effort` and a space to complete a level the current model supports |
+| `/settings`        | Manage appearance, behavior, and notification preferences                           |
+| `/yolo`            | Toggle automatic tool call approval                                                  |
+| `/title`           | Set or regenerate session title                                                      |
+| `/attach`          | Attach a file to your message                                                        |
+| `/shell`           | Open a shell                                                                         |
+| `/star`            | Star/unstar the current session                                                      |
+| `/context`         | Show a context-window breakdown: estimated tokens per category (system prompt, tool definitions, prompt files, messages, tool results, compaction summary), a team-level **Live sessions** view (the current session plus every running sub-agent session with its agent, short session ID, and context budget), plus a per-file inventory of attached files and prompt files. When a compaction has occurred, the dialog also displays the verbatim text of the most recent compaction summary. When a dedicated `compaction_model` caps the effective limit below the primary model's own window, a second line reads "compaction cap: `<model>` • `<N>` tokens" — Live-sessions rows are silent on the cap, and the sidebar shows a minimal ⚠ capped marker without repeating the model or the figure (the `/context` header is the authoritative source of the model + number). Use the arrow keys to select a row: press <kbd>Enter</kbd> on a live session to explicitly compact it, or <kbd>d</kbd> on an attached file to drop it |
+| `/drop`            | Remove an attached file from the session context (`/drop <path>`, or `/drop` alone to review and drop from the `/context` dialog). Press <kbd>Tab</kbd> after `/drop` and a space to complete an attached file's path |
+| `/cost`            | Show cost breakdown for this session. Includes a **By Agent** section (alongside **By Model**) showing cumulative cost per agent; unattributed usage and compaction spend appear in their own buckets. |
+| `/eval`            | Create an evaluation report                                                          |
+| `/pause`           | Pause/resume the runtime loop. While the agent is mid-request, the resize handle shows "Pausing…" until the in-flight request completes; once the loop is blocked the indicator changes to "⏸ Paused". Run `/pause` again to resume. |
+| `/tools`           | Show every toolset (with lifecycle state) and the tools they expose                  |
+| `/skills`          | List skills available to the current agent                                           |
+| `/toolset-restart` | Force a supervisor-driven reconnect of the named toolset (`/toolset-restart <name>`). Press <kbd>Tab</kbd> after `/toolset-restart` and a space to complete a toolset name; non-restartable toolsets are shown dimmed and cannot be selected. |
+| `/permissions`     | Inspect and edit tool permission rules                                               |
+| `/speak`           | Voice input via system speech-to-text (macOS only)                                   |
+| `/exit`            | Exit the application (aliases: `/quit`, `/q`)                                        |
+
+Slash commands (both built-in and named) execute immediately when entered. Regular chat messages sent while the agent is working are steered into the ongoing stream by default: the agent picks them up mid-turn (they appear in the transcript at the point the agent sees them) without breaking the stream. Prefer the previous end-of-turn behavior? Switch **While agent is working** to `Queue` on the **Behavior** tab of `/settings`; queued messages are processed in order once the stream stops.
+
+Agent-defined commands (prompts, URL links, agent-switching shortcuts) are configured under `commands:` in the agent YAML — see [Custom Commands](../../configuration/commands/index.md) for the full reference, including how to hide commands with `--disable-commands`.
+
+### Agents Panel
+
+The sidebar's **Agents** section lists every agent in the team and has two display modes selectable via **Sidebar info mode** in `/settings`:
+
+- **Compact** (default) — The current agent is shown as a focus **card** (rendered in place at its position in the list) with its name, a wrapped description, its full `provider/model`, and a thinking line. Every other agent is shown as a compact **two-line row** — line 1 is the shortcut/spinner, the agent name (in its accent color), and a right-aligned thinking **gauge**; line 2 is the indented full `provider/model` and, once the agent has run, its latest **context usage** as a right-aligned percentage of its context window.
+- **Detailed** — Each agent is shown as a responsive card with labeled **Effort**, **Context**, and **Cost** metrics on a single line (or split across lines at narrow sidebar widths), making cumulative per-agent cost visible at a glance across the team.
+
+Agents are separated by a blank line so rows stay visually distinct. The effort **gauge** is the only visual language for thinking; the focus card and the Agent Inspector spell out the exact level alongside it. Left-click any agent to switch to it.
+
+On large teams the roster can be trimmed to the agents that matter right now: enable **Active agents only** (nested under **Agents** in `/settings` → Appearance → Sidebar sections, off by default) to list only agents active in the current session — the selected or working agent, participants of an in-flight transfer, and any agent with recorded participation (usage or attributed cost, including agents restored with a reloaded session). The filter also applies to the top/bottom band, is purely presentational — <kbd>Ctrl</kbd>+<kbd>number</kbd> shortcuts keep their original team positions and agent cycling still walks the whole team — and is unavailable while the Agents section itself is hidden.
+
+#### Agent inspector
+
+Open a read-only **Agent Inspector** to inspect any agent's full configuration combined with its live state. The instruction/system prompt is deliberately omitted; everything else the agent declares is shown:
+
+- **Right-click any agent** (card or row) to open the inspector without switching to it.
+- **<kbd>Ctrl</kbd>+left-click any agent** does the same — a fallback for terminals that don't forward right-clicks.
+- **Left-click** always switches to the agent.
+
+The title is rendered in the agent's accent color. Sections appear in this order, and any empty section is omitted:
+
+- **Description** — the agent's wrapped description.
+- **Live state** — a `● current agent` line when the inspected agent is the one currently running.
+- **Model / Fallback / Thinking** — the `provider/model`, any fallback models, and the gauge + value thinking line (omitted for models with no selectable thinking, e.g. harness-backed agents).
+- **Context** — the agent's latest known context usage, e.g. `Context: 12.8K of 128.0K tokens (10%)` (a bare token count when the context limit is unknown; omitted until the agent has run). Sub-agent and background-agent runs are accounted for. When a dedicated `compaction_model` caps the effective limit below the primary model's own window, the token-usage line also shows a short "⚠ capped" marker (see `/context` for the model and figure).
+- **Cost** — the agent's cumulative cost across all runs in the session tree. Repeated session snapshots are not double-counted. Omitted until the agent has run.
+- **Sub-agents (N) / Handoffs (N) / Skills (N)** — compact, inline, comma-separated lists wrapped to the dialog width.
+- **Limits** — the configured per-agent limits that are set, e.g. `Limits: max-iter 50 · history 40 · max-tool-calls 5`.
+- **Options** — the enabled option flags, e.g. `Options: add-date · add-environment-info · redact-secrets`.
+- **Toolsets (N)** — one line per toolset with a status marker, its name, kind, and tool count, followed by the indented tool names.
+- **Commands (N)** — the slash commands the agent defines, each with its description.
+
+Each toolset carries a single-width status marker reflecting its **live** lifecycle: `●` started (serving), `○` stopped (not yet started), or `⚠` error. The tools listed under a toolset are the **live** tool names when it has started; for a toolset that has not started, the inspector instead shows its declared `tools:` allow-list prefixed with `declared:` (and shows nothing when the toolset declares no allow-list and therefore serves every tool). This lets you see both what an agent is configured with and what is actually running, even before the agent has been used.
+
+The dialog scrolls when the content is long; press <kbd>Esc</kbd> to close it. Remote runtimes (which hold no local team config) degrade gracefully — the config-derived sections are simply omitted.
+
+Model identifiers on line 2 are truncated **from the left** (e.g. `…claude-sonnet-4-6`) only when they overflow, so the informative tail (variant/version) is preserved. As the sidebar narrows the model keeps its own line, and near the minimum width line 1's gauge collapses to a single cell to keep the name readable.
+
+The thinking state of each model is shown with a gauge + value on the card and a gauge or badge on the row (no `✻` glyph):
+
+| Model state            | Card line                      | Row badge              |
+| ---------------------- | ------------------------------ | ---------------------- |
+| Effort level           | `thinking ▰▰▰▰▱▱ high`         | `▰▰▰▰▱▱` (effort gauge)  |
+| Adaptive budget        | `thinking auto adaptive`       | `auto`                 |
+| Token budget           | `thinking ◉ 8.2K tokens`        | `◉ 8.2K`               |
+| Disabled (capable)     | `thinking ▱▱▱▱▱▱ off` (dimmed)  | `▱▱▱▱▱▱` (empty gauge)  |
+| Not reasoning-capable  | _(omitted)_                    | _(omitted)_            |
+
+The **effort gauge** is a fixed-width six-cell indicator (`▰` filled, `▱` empty) so the badge column stays aligned. It maps the six selectable levels one-to-one onto filled-cell counts — `minimal` → `▰▱▱▱▱▱`, `low` → `▰▰▱▱▱▱`, `medium` → `▰▰▰▱▱▱`, `high` → `▰▰▰▰▱▱`, `xhigh` → `▰▰▰▰▰▱`, `max` → `▰▰▰▰▰▰` — so the cell count alone is lossless, with a low→high color ramp as a secondary cue. A capable-but-disabled model shows a dim empty gauge (`▱▱▱▱▱▱` `off`), adaptive budgets show `auto`, and token budgets keep `◉ <count>`. The same gauge + value renders on the focus card, the Agent Inspector, and the row.
+
+Harness-backed agents (e.g. `claude-code`) show the harness type as their model and no thinking gauge. Press **Shift+Tab** to cycle the current model's thinking-effort level; a `✻ Thinking: <level>` toast confirms the change (useful when the sidebar is hidden).
+
+### Agent Delegation Feedback
+
+When a parent agent calls `transfer_task` to delegate work to a sub-agent, the TUI provides live visual feedback in both the sidebar and the chat.
+
+**Sidebar — Transfer box:** As soon as the delegation starts, an animated **Transfer** box appears below the agent roster, showing the direction of the handoff with a traveling dot:
+
+```text
+╭─ Transfer ─────────────────╮
+│  parent  ●──────►  child   │
+╰────────────────────────────╯
+```
+
+The box stays visible for at least 1.5 seconds. Once the sub-agent produces its first message, reasoning, or tool output, the box hides (still honoring the minimum window) to keep the sidebar focused on the active agent. If the sub-agent is slow or silent, the box hides after a 3-second maximum cutoff. The header shows a `↔` marker while any delegation is still in flight, even after the box hides.
+
+**Sidebar — Return box:** When the sub-agent finishes and control returns to the parent, a brief **Return** box animates the reverse direction for up to 1.5 seconds, then disappears:
+
+```text
+╭─ Return ───────────────────╮
+│  child  ●──────►  parent   │
+╰────────────────────────────╯
+```
+
+**Chat — return transition:** Alongside the sidebar Return animation, the chat shows a one-line static transition between the two agent badges:
+
+```text
+[child]  returned control to  [parent]
+```
+
+This transition is not persisted — it does not reappear when you reload the session.
+
+### Context-Usage Gauge
+
+The context percentage shown in the sidebar token-usage section, and the fill bar in the lean TUI status line, both color-escalate as the active session approaches the auto-compaction threshold:
+
+| State   | Color  | Trigger |
+| ------- | ------ | ------- |
+| Normal  | (default) | Usage below 75% of the compaction threshold |
+| Warning | Orange | Usage at or above 75% of the compaction threshold |
+| Critical | Red   | Usage at or above 95% of the compaction threshold |
+
+While a compaction is running the percentage is replaced by a **"compacting…"** indicator; token counts remain visible in the lean TUI status line.
+
+The thresholds are proportional to the agent's configured `compaction_threshold` (default `0.9`), so a custom value keeps a predictable visual runway. See [Compaction Threshold](../../configuration/models/index.md#delegating-session-compaction) for configuration details.
+
+Clicking the token/context part of the sidebar's usage reading (the glyph, token count, context percentage — or the "compacting…" marker — and the `⚠ capped` marker) opens the `/context` dialog with the full breakdown. Clicking the cost part (the `$` figure and the sub-session count) opens the `/cost` dialog instead. The "Token Usage" section title itself is not clickable.
+
+### Thinking and Tool Details
+
+Reasoning/thinking blocks are collapsed by default and carry a `Thinking` header badge. When collapsed, the TUI shows a short preview and compact tool summaries. Expand a block to see the full thinking content and the real tool renderers, including detailed tool output such as file edit diffs.
+
+To start new sessions with thinking/tool blocks expanded by default, set `expand_thinking` in your user config:
+
+```yaml
+# ~/.config/cagent/config.yaml
+settings:
+  expand_thinking: true
+```
+
+Set it to `false` or omit it to keep the default collapsed behavior. See [User Settings](../../configuration/user-settings/index.md) for the full settings reference.
+
+### Mermaid Diagrams
+
+The TUI renders Mermaid diagram blocks inline rather than displaying raw syntax. When an assistant message contains a fenced code block tagged ` ```mermaid `, the TUI parses the diagram and draws an ASCII representation directly in the conversation:
+
+| Diagram type                                   | Support                                           |
+| ---------------------------------------------- | ------------------------------------------------- |
+| `graph` / `flowchart`                          | ✅ Rendered inline                                 |
+| `sequenceDiagram`                              | ✅ Rendered inline                                 |
+| `stateDiagram` / `stateDiagram-v2`             | ✅ Rendered inline (supports `direction TD/TB/BT/LR/RL`) |
+| Other types (`classDiagram`, `erDiagram`, …) | Falls back to a syntax-highlighted code block     |
+
+Mermaid rendering works in both the full TUI and the lean TUI. Unsupported or syntactically invalid diagram blocks are displayed as ordinary fenced code blocks — no configuration is required and there is no way to disable it.
+
+### LaTeX Math Rendering
+
+The TUI renders LaTeX math expressions as terminal-friendly Unicode text. When an assistant message contains inline math (delimited by `$…$`) or display math (delimited by `$$…$$`), the TUI converts supported LaTeX commands to their Unicode equivalents and displays them directly in the conversation.
+
+Supported features include:
+
+- Greek letters (`\alpha`, `\beta`, `\gamma`, …)
+- Mathematical operators (`\times`, `\div`, `\pm`, `\oplus`, …)
+- Relations (`\le`, `\ge`, `\approx`, `\equiv`, …)
+- Set operators (`\cap`, `\cup`, `\subset`, `\in`, …)
+- Calculus symbols (`\int`, `\sum`, `\prod`, `\partial`, `\nabla`, …)
+- Arrows and logic (`\to`, `\implies`, `\forall`, `\exists`, …)
+- Superscripts and subscripts (e.g., `x^2`, `a_i`)
+- Fractions (`\frac{a}{b}`), square roots (`\sqrt{x}`), and matrices
+- Common functions (`\sin`, `\cos`, `\log`, `\lim`, …)
+
+Unsupported or syntactically invalid LaTeX expressions fall back to displaying the raw source. LaTeX rendering works in both the full TUI and the lean TUI, requires no configuration, and cannot be disabled.
+
+### Markdown Images
+
+The TUI fetches and renders images referenced in agent responses using the Kitty graphics protocol. When an assistant message contains a standard Markdown image reference, the TUI downloads the image in the background and displays it inline at the point of the reference. While the image is loading a placeholder is shown; once loaded, the message re-renders with the image in place.
+
+Only `http://`, `https://`, and `data:image/…;base64,…` URIs are resolved. `file://`, `sandbox://`, and any other URI scheme are rejected as a security measure against prompt-injection attacks that could otherwise read local files. Bare relative paths (e.g. `./output.png`, used for agent-generated images) are read via the local filesystem. Images that fail to load are silently dropped — the surrounding message text is unaffected. Image rendering requires a terminal that supports the Kitty graphics protocol; it is automatically disabled when the terminal does not support it. You can also disable it explicitly via `render_images: false` in `~/.config/cagent/config.yaml` or the **Render images** toggle in `/settings`.
+
+### Snapshots, `/undo`, and `/snapshots`
+
+Enable shadow-git snapshots globally in `~/.config/cagent/config.yaml`:
+
+```yaml
+settings:
+  snapshot: true
+```
+
+When enabled, Docker Agent records filesystem snapshots at turn boundaries. The TUI exposes two slash commands that operate on those snapshots:
+
+- **`/undo`** restores files from the most recent snapshot (one step back).
+- **`/snapshots`** opens a dialog showing how many snapshots have been captured and the number of files in each one. Use <kbd>↑</kbd>/<kbd>↓</kbd> (or <kbd>j</kbd>/<kbd>k</kbd>) to highlight an entry, then press <kbd>r</kbd> to reset the workspace to that point. Pick `<original>` to revert every snapshot and bring the workspace back to its pre-agent state. <kbd>Esc</kbd> closes the dialog without changing anything.
+
+Neither command removes messages from the session transcript — they only touch files on disk. Both commands (and the matching command-palette entries) are hidden when snapshots are turned off. Omit `snapshot` or set it to `false` to leave automatic snapshots off; agents can still configure snapshot hooks manually.
+
+See [Snapshots](../snapshots/index.md) for how the shadow-git machinery works and how to wire it per-agent.
+
+## File Attachments
+
+Attach file contents to your messages using the `@` trigger:
+
+1. Type `@` to open the file completion menu
+2. Start typing to filter files (respects `.gitignore`)
+3. Select a file to insert the reference
+
+```bash
+# In the chat input:
+Explain what the code in @pkg/agent/agent.go does
+```
+
+The agent receives the full file contents in a structured `<attachments>` block, while the UI shows just the reference.
+
+For large or frequently-reused documents, or for getting content to an agent over the API or chat server instead of the TUI, see [Choosing a Large-Input Strategy](../../guides/headless/index.md#choosing-a-large-input-strategy).
+
+Attached files are also recorded on the session so sub-agents spawned by task transfer can read them. To review what is attached, open `/context`: the dialog lists every attached file (and resolved prompt file) with a per-file token estimate and, when a compaction has occurred, displays the verbatim text of the most recent compaction summary. Use <kbd>↑</kbd>/<kbd>↓</kbd> to select an attached file and press <kbd>d</kbd> (or <kbd>x</kbd>/<kbd>Del</kbd>) to drop it, or run `/drop <path>` directly — press <kbd>Tab</kbd> after `/drop` and a space to complete the path from the currently attached files. Dropping stops sharing the file with sub-agents and skills; content already inlined in earlier messages stays in the conversation until compaction, and the file can always be re-attached with `@` or `/attach`.
+
+### Team Context Budgets and Targeted Compaction
+
+The `/context` dialog also shows a **Live sessions** section: the current session plus every currently running sub-agent session (foreground children spawned by task transfer and long-running `run_background_agent` tasks). Each row shows the agent name, a short session ID (so two concurrent runs of the same agent stay distinguishable), and that session's context budget: used tokens, context limit, and percentage, or an explicit "limit unknown" reading when the model's window cannot be resolved. Live-sessions rows do not repeat the compaction-cap wording themselves — the dialog's header line is the sole authority on which model, if any, caps the effective limit.
+
+When a compaction has occurred, the dialog displays the verbatim text of the most recent compaction summary below the file inventory, under a "Latest compaction summary" section. This shows exactly what was summarized, preserving hard newlines and soft-wrapping long lines to the dialog width.
+
+Select a live session with <kbd>↑</kbd>/<kbd>↓</kbd> and press <kbd>Enter</kbd> to explicitly compact it. Cross-agent compaction happens only on this explicit request: no idle-triggered automatic compaction is added, and the existing automatic threshold and overflow-recovery compaction of sub-agent sessions is unchanged. The request is queued onto the target session's own run loop and executes at the next safe point between model turns, so it cannot corrupt an in-flight turn. The dialog closes and a notification confirms the request; a second notification reports the outcome (compacted, skipped, or failed) with the agent's name. Selecting the main row runs the same compaction as `/compact`. `/compact` itself keeps compacting the current root session. Remote runtimes do not expose live-session tracking, so the section is omitted there.
+
+## Runtime Model Switching
+
+Change the AI model during a session with `/model` or <kbd>Ctrl</kbd>+<kbd>M</kbd>. Model switching works in both the full TUI and the lean TUI.
+
+1. Press <kbd>Ctrl</kbd>+<kbd>M</kbd> (full TUI) or type `/model` (both TUIs)
+2. Select from config models or type a custom `provider/model`
+3. The model switch is saved with the session and restored on reload
+
+When a models gateway is configured (`--models-gateway`) and it exposes an OpenAI-style `/v1/models` endpoint, the picker lists the models actually served by the gateway (merged with the models defined in the agent config). When the gateway doesn't expose `/v1/models`, the picker falls back to the regular catalog.
+
+The picker's catalog entries come from [models.dev](https://models.dev) and are cached locally for a day. Press <kbd>Ctrl</kbd>+<kbd>R</kbd> in the picker to force model discovery to run again, including a refetch of the models.dev catalog.
+
+> [!TIP]
+> Use model switching to try a more capable model for complex tasks, or a cheaper one for simple queries — without modifying your YAML config.
+
+## Editable Messages
+
+Edit any previous user message to branch the conversation. Hover a past user message and click **✎ edit** (or select it with the keyboard and press <kbd>e</kbd>) to modify it — the agent will re-process from that point, while the original session history is preserved. This is great for exploring alternative approaches without losing your work.
+
+Hovering a user or assistant message also reveals a **⎘ copy** button that copies the message text to the clipboard (<kbd>c</kbd> when a message is selected).
+
+## Error Recovery
+
+When an agent turn fails (fatal model error, hook block, loop detection, tool-setup failure), the TUI displays the error in the message stream and persists it to the session store. Errors survive a reload and are shown exactly where they occurred, making them visible in shared or remote sessions.
+
+Each error message includes a clickable **↻ retry** button. Clicking it resumes the conversation from the point of failure — without retyping your last message. This lets you recover from transient failures (rate limits, network blips, model API errors) in one click.
+
+## Session Management
+
+Docker Agent automatically saves your sessions. Use `/sessions` to browse past conversations:
+
+- **Browse** past sessions with search and filtering. The search matches against session **titles** and **session IDs** (full UUIDs, dash-less variants, and partial fragments all resolve correctly — useful when jumping back to a session from a copied ID or log).
+- **Workspace grouping**: sessions are grouped by **git repository root** (worktree-aware) — sessions from any subdirectory or linked worktree of the same repository are grouped together under "This workspace", and the header shows the repository root path. Sessions outside the current repository appear under "Other locations" with their originating directory. Press <kbd>Ctrl</kbd>+<kbd>G</kbd> in the browser to cycle between all, current-workspace only, and other-directory views. Restoring a session reopens it in its original directory, so the label always matches where a restore will land.
+- **Star** important sessions with `/star`
+- **Branch** conversations by editing any previous user message — preserving the original session history
+- **Resume** sessions with `docker agent run config.yaml --session <id>`
+- **Relative refs**: `--session -1` for the last session, `-2` for the one before
+
+### Session Title Editing
+
+Customize session titles to make them more meaningful and easier to find. By default, Docker Agent auto-generates titles based on your first message, but you can override or regenerate them at any time.
+
+**Using the `/title` command:**
+
+```bash
+/title                     # Regenerate title using AI (based on recent messages)
+/title My Custom Title     # Set a specific title
+```
+
+**Using the sidebar:**
+
+1. Click the pencil icon (✎) next to the session title in the sidebar
+2. Type your new title
+3. Press <kbd>Enter</kbd> to save, or <kbd>Escape</kbd> to cancel
+
+> [!NOTE]
+> Manually set titles are preserved and won’t be overwritten by auto-generation. Title changes are persisted immediately to the session.
+
+## Keyboard Shortcuts
+
+| Shortcut   | Action                                          |
+| ---------- | ----------------------------------------------- |
+| Ctrl+K     | Open command palette                            |
+| Ctrl+M     | Switch model                                    |
+| Ctrl+R     | Reverse history search (search previous inputs) |
+| Ctrl+G     | Cancel reverse history search                   |
+| Ctrl+S     | Cycle to next agent in the team                 |
+| Shift+Tab  | Cycle the current model's thinking-effort level (shows a `✻ Thinking: <level>` toast) |
+| Ctrl+1 – 9 | Switch directly to agent _N_ in the team list   |
+| Ctrl+T     | Open a new tab (additional agent session)       |
+| Ctrl+W     | Close the current tab                           |
+| Ctrl+N     | Next tab                                        |
+| Ctrl+P     | Previous tab                                    |
+| Ctrl+B     | Toggle the sidebar (full-UI mode only; disabled when --sidebar=false) |
+| Ctrl+Y     | Toggle YOLO mode (auto-approve tool calls)      |
+| Ctrl+O     | Toggle hide tool results                        |
+| Ctrl+Z     | Suspend TUI to background (resume with `fg`)    |
+| Ctrl+X     | Clear queued messages                           |
+| Escape     | Cancel current operation                        |
+| Enter      | Send message (or steer while the agent is running) |
+| Alt+Enter  | Queue a follow-up turn while the agent is running |
+| Shift+Enter | Insert a newline |
+| Up/Down    | Navigate message history                        |
+
+Press <kbd>Ctrl</kbd>+<kbd>H</kbd> to view the complete list of all available keyboard shortcuts.
+
+### Custom Keybindings
+
+You can remap the shortcuts above by adding a `keybindings` list to the `settings` block of your `~/.config/cagent/config.yaml` (see [User Settings](../../configuration/user-settings/index.md#settings-reference) for the field reference). Each entry maps an action to one or more key combinations in [Bubbles key format](https://github.com/charmbracelet/bubbles) (for example `ctrl+q`, `alt+enter`, `f2`). Unlisted actions keep their defaults.
+
+This is the recommended way to replace the `Ctrl+J` newline fallback, which conflicts with common editor/terminal shortcuts (for example inside VS Code).
+
+```yaml
+settings:
+  keybindings:
+    # Insert a newline with Alt+Enter instead of Ctrl+J. Shift+Enter still
+    # works automatically on terminals that report it.
+    - action: "editor_newline"
+      keys: ["alt+enter"]
+    # Allow several keys for one action.
+    - action: "commands"
+      keys: ["f2", "ctrl+k"]
+    - action: "quit"
+      keys: ["ctrl+q"]
+```
+
+**Valid actions:**
+
+| Action                     | Default      | Description                            |
+| -------------------------- | ------------ | -------------------------------------- |
+| `editor_send`              | `enter`      | Send the current message               |
+| `editor_newline`           | `ctrl+j`     | Insert a newline in the input          |
+| `quit`                     | `ctrl+c`     | Quit (opens the exit confirmation)     |
+| `switch_focus`             | `tab`        | Switch focus between panels            |
+| `commands`                 | `ctrl+k`     | Open the command palette               |
+| `help`                     | `ctrl+h`     | Show the help dialog                   |
+| `toggle_yolo`              | `ctrl+y`     | Toggle YOLO mode                       |
+| `toggle_hide_tool_results` | `ctrl+o`     | Toggle hiding tool results             |
+| `cycle_agent`              | `ctrl+s`     | Cycle to the next agent                |
+| `model_picker`             | `ctrl+m`     | Open the model picker                  |
+| `clear_queue`              | `ctrl+x`     | Clear queued messages                  |
+| `suspend`                  | `ctrl+z`     | Suspend the TUI                        |
+| `toggle_sidebar`           | `ctrl+b`     | Toggle the sidebar                     |
+| `edit_external`            | `ctrl+g`     | Edit input in an external editor       |
+| `history_search`           | `ctrl+r`     | Incremental history search             |
+
+`Shift+Enter` for newline is detected from your terminal's capabilities and is always available where supported, independent of `editor_newline`.
+
+Invalid entries are ignored with a warning (visible with `--debug`) so a bad config never breaks the TUI: unknown actions, empty or malformed keys, and keys that would collide with another action are dropped while every other binding keeps working.
+
+## History Search
+
+Press <kbd>Ctrl</kbd>+<kbd>R</kbd> to enter incremental history search mode. Start typing to filter through your previous inputs. Press <kbd>Enter</kbd> to select a match, or <kbd>Escape</kbd> to cancel.
+
+## Settings
+
+Run `/settings` to open the settings dialog. Use <kbd>Tab</kbd> to switch between **Appearance**, **Behavior**, and **Notifications**.
+
+> [!TIP]
+> **Full settings reference**
+>
+> This section covers the `/settings` dialog. For the complete list of `settings:` fields (including ones with no dialog UI, like `permissions`, `hooks`, and `keybindings`) and how they interact with CLI flags and aliases, see [User Settings](../../configuration/user-settings/index.md).
+
+The **Appearance** tab selects the theme and customizes the layout. Layout changes show a live schematic preview and apply immediately to the UI behind the dialog:
+
+- **Sidebar position**: `Right` (default), `Left`, `Top`, or `Bottom`. Left/right keep the full vertical sidebar next to the chat; top/bottom render it as a compact horizontal band above or below the chat (session title, working directory, token usage, plus a one-line summary of the current agent and its model; in multi-agent configurations all team agents are listed by name after the current agent).
+- **Sidebar info mode**: `Compact` (default) or `Detailed`. Controls how the Agents panel renders agent rows — see [Agents Panel](#agents-panel) for details. Persisted as `settings.layout.sidebar_info_mode: detailed`; compact is the default and omitted from the config.
+- **Section spacing**: `Compact`, `Normal` (default), or `Relaxed`, the number of blank lines between the sidebar sections (1, 2, or 3).
+- **Sidebar sections**: toggle the visibility of the **Session path** (the working directory line, including its git branch) and the **Token usage**, **Agents**, **Tools**, and **Todos** sections. The session title is always shown.
+
+Appearance also controls split-diff rendering, expanded thinking, and whether tool results are hidden by default. Select **Theme** to open the theme picker.
+
+The **Behavior** tab controls busy-message handling, the auto-approve default, tab restoration, automatic snapshots, lean UI, and the maximum tab-title length. Restore-tabs and lean-UI changes take effect on the next launch. Enabling auto-approve requires confirmation.
+
+The **Notifications** tab enables completion sounds and sets the minimum task duration before a sound plays.
+
+Press <kbd>Enter</kbd> to apply and persist, or <kbd>Escape</kbd> to cancel and restore the previous layout. The settings are saved globally in `~/.config/cagent/config.yaml`:
+
+```yaml
+# ~/.config/cagent/config.yaml
+settings:
+  busy_send_mode: queue # steer (default), queue
+  layout:
+    sidebar_position: left # right (default), left, top, bottom
+    sidebar_info_mode: detailed # compact (default, omitted), detailed
+    section_spacing: compact # normal (default), compact, relaxed
+    hide_session_path: false
+    hide_usage: true
+    hide_agents: false
+    active_agents_only: false # true to filter to session-active agents
+    hide_tools: false
+    hide_todos: false
+```
+
+## Theming
+
+Customize the TUI appearance with built-in or custom themes:
+
+```bash
+# Open Settings and select Theme under Appearance
+/settings
+```
+
+### Built-in Themes
+
+`default`, `default-light`, `catppuccin-latte`, `catppuccin-mocha`, `dracula`, `gruvbox-dark`, `gruvbox-light`, `nord`, `one-dark`, `solarized-dark`, `tokyo-night`
+
+### Auto Theme (match the terminal)
+
+The special theme `auto` follows the terminal's light/dark background instead of naming a fixed theme. Select **Auto (match terminal)** from **Settings → Appearance → Theme**, pass `--theme auto`, or set it in your user config:
+
+```yaml
+settings:
+  theme: auto
+  theme_dark: default # optional, theme used on dark backgrounds (default: default)
+  theme_light: default-light # optional, theme used on light backgrounds (default: default-light)
+```
+
+At startup the terminal background is queried (OSC 11) to pick the dark or light theme of the pair; non-interactive runs (pipes, CI) fall back to the dark theme. In terminals that report appearance changes (DEC mode 2031 — Ghostty, kitty, contour, …), flipping the OS or terminal appearance while Docker Agent is running switches the theme live. Terminals without that mode re-sync when the window regains focus.
+
+### Custom Themes
+
+Create theme files in `~/.cagent/themes/` as YAML. Theme files are **partial overrides** — you only need to specify the colors you want to change. Any omitted keys fall back to the built-in default theme values.
+
+```yaml
+# ~/.cagent/themes/my-theme.yaml
+name: "My Custom Theme"
+
+colors:
+  # Backgrounds
+  background: "#1a1a2e"
+  background_alt: "#16213e"
+
+  # Text colors
+  text_bright: "#ffffff"
+  text_primary: "#e8e8e8"
+  text_secondary: "#b0b0b0"
+  text_muted: "#707070"
+
+  # Accent colors
+  accent: "#4fc3f7"
+  brand: "#1d96f3"
+
+  # Status colors
+  success: "#4caf50"
+  error: "#f44336"
+  warning: "#ff9800"
+  info: "#00bcd4"
+
+# Optional: Customize syntax highlighting colors
+chroma:
+  comment: "#6a9955"
+  keyword: "#569cd6"
+  literal_string: "#ce9178"
+
+# Optional: Customize markdown rendering colors
+markdown:
+  heading: "#4fc3f7"
+  link: "#569cd6"
+  code: "#ce9178"
+```
+
+### Applying Themes
+
+**In user config** (`~/.config/cagent/config.yaml`, see [User Settings](../../configuration/user-settings/index.md) for the full reference):
+
+```yaml
+settings:
+  theme: my-theme # References ~/.cagent/themes/my-theme.yaml
+```
+
+**At launch:** Pass `--theme <name>` to `docker agent run` to preselect a theme for that session. This overrides `settings.theme` in your config but is not saved. Invalid theme names print an error at startup listing the available options. Has no effect in `--exec` mode. `--theme auto` enables the [auto theme](#auto-theme-match-the-terminal) for the session.
+
+**At runtime:** Open `/settings`, select **Theme** on the Appearance tab, and choose from the available themes. Your selection is saved globally in `~/.config/cagent/config.yaml` under `settings.theme` and persists across sessions.
+
+> [!TIP]
+> **Hot Reload**
+>
+> Custom themes auto-reload when you save changes to the file — no restart needed. This makes it easy to tweak colors in real-time.
+
+> [!WARNING]
+> **Partial overrides**
+>
+> All user themes are applied on top of the `default` theme. If you want to customize a built-in theme (e.g., `dracula`), copy its full YAML from the [built-in themes on GitHub](https://github.com/docker/docker-agent/tree/main/pkg/tui/styles/themes) into `~/.cagent/themes/` and edit the copy. Otherwise, omitted values will use `default` colors, not the original theme's colors.
+
+## Tool Permissions
+
+When an agent calls a tool, Docker Agent shows a confirmation dialog by default. You can:
+
+- **Approve once** — Allow this specific call
+- **Always allow** — Permanently approve this tool/command for the session
+- **Deny** — Reject the tool call
+
+**Granular permissions:** The permission system supports pattern-based matching. When you “Always allow” a specific tool command, only that exact pattern is auto-approved — other commands from the same tool still require confirmation. This lets you auto-approve safe, read-only operations while maintaining control over destructive ones.
+
+> [!TIP]
+> **YOLO mode**
+>
+> Use `--yolo` or the `/yolo` command to auto-approve all tool calls. You can also toggle this mid-session. For aliases, set `--yolo` when creating the alias: `docker agent alias add fast myorg/coder --yolo`.
+
+## Notifications
+
+The TUI displays transient notification banners for agent warnings, errors, and other runtime events. Notifications auto-dismiss after a short delay unless the mouse is hovering over them — hovering pauses the timer so you have time to read the message.
+
+| Interaction | Behaviour |
+| ----------- | --------- |
+| Hover       | Pauses auto-dismiss; the notification stays visible until the mouse moves away |
+| Click       | Copies the notification text to the clipboard |
+| × (close)   | Dismisses immediately; the glyph turns red when hovered |
+
+Hint text in the top-left corner of the notification border shows the available actions at a glance.
diff --git a/_vendor/github.com/docker/docker-agent/docs/getting-started/_index.md b/_vendor/github.com/docker/docker-agent/docs/getting-started/_index.md
new file mode 100644
index 000000000000..46eeae898947
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/getting-started/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Getting Started"
+description: "Install Docker Agent and build your first agent."
+weight: 10
+---
diff --git a/_vendor/github.com/docker/docker-agent/docs/getting-started/installation/index.md b/_vendor/github.com/docker/docker-agent/docs/getting-started/installation/index.md
new file mode 100644
index 000000000000..43e52344c5b8
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/getting-started/installation/index.md
@@ -0,0 +1,150 @@
+---
+title: "Installation"
+description: "Get Docker Agent running on your system in minutes."
+keywords: docker agent, ai agents, getting started, installation
+weight: 20
+canonical: https://docs.docker.com/ai/docker-agent/getting-started/installation/
+---
+
+_Get Docker Agent running on your system in minutes._
+
+## Prerequisites
+
+- An API key for at least one AI provider (OpenAI, Anthropic, Google, etc.)
+- **Optional:** [Docker Desktop](https://www.docker.com/products/docker-desktop/) — for running containerized MCP tools and Docker Model Runner
+
+## Docker Desktop (Pre-installed)
+
+Starting with [Docker Desktop 4.63](https://docs.docker.com/desktop/release-notes/#4630), **Docker Agent is already available**. No separate installation needed — just open a terminal and run:
+
+```bash
+$ docker agent version
+```
+
+> [!TIP]
+> Docker Desktop bundles Docker Agent and keeps it up to date. This is the easiest way to get started, especially if you want to use Docker MCP tools and Docker Model Runner.
+
+## Homebrew (macOS / Linux)
+
+Install Docker Agent using [Homebrew](https://brew.sh/):
+
+```bash
+# Install
+$ brew install docker-agent
+
+# Verify
+$ docker-agent version
+```
+
+You can also install Docker Agent as a docker CLI plugin, by copying the `docker-agent` binary in `~/.docker/cli-plugins`. You can then run `docker agent version`.
+
+## Download Binary Releases
+
+Download [prebuilt binary releases](https://github.com/docker/docker-agent/releases) for Windows, macOS, and Linux from the GitHub Releases page.
+
+### macOS / Linux
+
+```bash
+# Download the latest release
+OS=$(uname -s | tr '[:upper:]' '[:lower:]')
+ARCH=$(uname -m); case "$ARCH" in x86_64) ARCH=amd64;; aarch64) ARCH=arm64;; esac
+curl -L "https://github.com/docker/docker-agent/releases/latest/download/docker-agent-${OS}-${ARCH}" -o docker-agent
+chmod +x docker-agent
+sudo mv docker-agent /usr/local/bin/
+docker-agent version
+
+# or alternatively, instead of moving to /usr/local/bin:
+mkdir -p ~/.docker/cli-plugins
+sudo mv docker-agent ~/.docker/cli-plugins
+docker agent version
+```
+
+### Windows
+
+Download `docker-agent-windows-amd64.exe` from the [releases page](https://github.com/docker/docker-agent/releases), rename it to `docker-agent.exe` and add it to your PATH. Alternatively you can move it to `~/.docker/cli-plugins`
+
+## Optional Self-Updates
+
+When Docker Agent is installed from a standalone GitHub release binary, you can opt in to automatic self-updates by setting `DOCKER_AGENT_AUTO_UPDATE` to a truthy value (`1`, `true`, `yes`, or `on`):
+
+```bash
+# Enable for one command
+DOCKER_AGENT_AUTO_UPDATE=1 docker agent run
+
+# Or enable for the current shell session
+export DOCKER_AGENT_AUTO_UPDATE=1
+docker agent run
+```
+
+With self-updates enabled, Docker Agent checks the latest GitHub release before normal commands run. If a newer release exists and your session is interactive, Docker Agent asks whether you want to install it or keep running your current version. When the answer is yes (or the session is non-interactive, such as CI or piped input, in which case the update proceeds automatically), it downloads the asset for your OS and architecture, verifies the release-provided SHA-256 digest/checksum, replaces the current binary, and restarts the command with the same arguments.
+
+Self-updates are fail-safe: if checking, downloading, verifying, installing, or restarting fails, Docker Agent keeps running the current binary. Version/help/completion commands and Docker CLI plugin metadata handshakes do not trigger self-updates.
+
+> [!NOTE]
+> **Package-manager installs**
+>
+> Docker Desktop and Homebrew already manage Docker Agent updates. Prefer those update mechanisms when you installed Docker Agent that way. Self-updates are mainly intended for standalone release binaries.
+
+## Build from Source
+
+For the latest features, or to contribute, build from source:
+
+### Prerequisites
+
+- [Go 1.26](https://go.dev/dl/) or higher
+- [Task](https://taskfile.dev/installation/) (build tool)
+- [golangci-lint](https://golangci-lint.run/docs/welcome/install/local/) (for linting)
+
+```bash
+# Clone the repository
+git clone https://github.com/docker/docker-agent.git
+cd docker-agent
+
+# Build the binary
+task build
+
+# The binary is at ./bin/docker-agent
+./bin/docker-agent --help
+```
+
+> [!TIP]
+> **Building on Windows**
+>
+> On Windows, use `task build-local` instead of `task build`. This builds the binary inside a Docker container using Docker Buildx, which avoids issues with Windows-specific toolchain setup and CGo cross-compilation. The output goes to the `./dist` directory.
+
+## Set Up API Keys
+
+Docker Agent needs API keys for the model providers you want to use. Set them as environment variables:
+
+```bash
+# Pick one (or more) depending on your provider
+export OPENAI_API_KEY="sk-..."           # OpenAI
+export ANTHROPIC_API_KEY="sk-ant-..."    # Anthropic
+export GOOGLE_API_KEY="AI..."            # Google Gemini (or GEMINI_API_KEY)
+export GITHUB_TOKEN="ghp-..."            # GitHub Copilot (PAT with copilot scope)
+export MISTRAL_API_KEY="..."             # Mistral
+export OPENROUTER_API_KEY="..."          # OpenRouter
+```
+
+See [Configuration Overview](../../configuration/overview/index.md#environment-variables) for the full list of supported providers and environment variables.
+
+> [!NOTE]
+> You only need the key(s) for the provider(s) you configure in your agent YAML. If you use Docker Model Runner (DMR), no API key is needed — models run locally.
+
+## Verify Installation
+
+```bash
+# Check the version
+$ docker agent version
+
+# Run the default agent
+$ docker agent run
+
+# Or run an agent from an OCI registry
+$ docker agent run myorg/agent:tag
+```
+
+## What's Next?
+
+- [**Quick Start**](../quickstart/index.md) — create and run your first agent in under 5 minutes.
+- [**Troubleshooting**](../../community/troubleshooting/index.md) — something not working? Debug mode, common issues, and solutions.
diff --git a/_vendor/github.com/docker/docker-agent/docs/getting-started/introduction/index.md b/_vendor/github.com/docker/docker-agent/docs/getting-started/introduction/index.md
new file mode 100644
index 000000000000..0ade379b873c
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/getting-started/introduction/index.md
@@ -0,0 +1,74 @@
+---
+title: "Introduction"
+description: "Docker Agent is a multi-agent runtime that lets you build, run, and share AI agents with a YAML or HCL config — no glue code required."
+keywords: docker agent, ai agents, getting started, introduction
+weight: 10
+canonical: https://docs.docker.com/ai/docker-agent/getting-started/introduction/
+---
+
+_Docker Agent is a multi-agent runtime that lets you build, run, and share AI agents with a YAML or HCL config — no glue code required._
+
+## What is Docker Agent?
+
+Docker Agent is an open-source tool from Docker that orchestrates AI
+agents with specialized capabilities and tools. Instead of writing
+code to wire up LLMs, tools, and workflows, you **declare** your
+agents in YAML or HCL — their model, personality, tools, and how they
+collaborate — and Docker Agent handles the rest.
+
+- **Multi-Agent Architecture** — build hierarchical teams of agents that specialize in different tasks and delegate work to each other.
+- **Rich Tool Ecosystem** — built-in tools for files, shell, memory, and todos. Extend with any MCP server from [Docker's MCP catalog](https://hub.docker.com/u/mcp).
+- **Multi-Model Support** — OpenAI, Anthropic, Google Gemini, AWS Bedrock, Docker Model Runner, and reusable provider definitions with shared defaults.
+- **Package & Share** — push agents to OCI registries and pull them anywhere, just like Docker images.
+- **Multiple Interfaces** — interactive TUI, headless CLI, HTTP API server, MCP mode, and A2A protocol support.
+- **Security-First Design** — tool confirmation prompts, containerized MCP tools via Docker, client isolation, and resource scoping.
+
+## Why Docker Agent?
+
+After spending years building AI agents using various frameworks, the
+Docker team kept asking the same questions:
+
+- **How do we make building agents less of a hassle?** — Most agents
+  use the same building blocks. Docker Agent provides them out of the
+  box.
+- **Can we reuse those building blocks?** — Declarative YAML or HCL
+  configs mean you can mix and match agents, models, and tools without
+  rewriting code.
+- **How can we share agents easily?** — Push agents to any OCI
+  registry and run them anywhere with a single command.
+
+Docker Agent is built in the open so the community can make use of
+this work and contribute to its future.
+
+## How it works
+
+At its core, Docker Agent follows a simple loop:
+
+1. **You define agents** in YAML or HCL — their model, instructions, tools, and sub-agents.
+2. **You run an agent** via the TUI, CLI, or API.
+3. **The agent processes your request** — calling tools, delegating to sub-agents, and reasoning step by step.
+4. **Results stream back in real-time** via an event-driven architecture.
+
+```yaml
+# A minimal agent definition
+agents:
+  root:
+    model: openai/gpt-5
+    description: A helpful assistant
+    instruction: You are a helpful assistant.
+    toolsets:
+      - type: think
+```
+
+```bash
+# Run it
+$ docker agent run agent.yaml
+```
+
+> [!TIP]
+> Jump straight to the [Quick Start](../quickstart/index.md) if you want to build your first agent right away.
+
+## What's next?
+
+- [**Installation**](../installation/index.md) — install Docker Agent on macOS, Linux, or Windows.
+- [**Quick Start**](../quickstart/index.md) — build your first agent in under 5 minutes.
diff --git a/_vendor/github.com/docker/docker-agent/docs/getting-started/quickstart/index.md b/_vendor/github.com/docker/docker-agent/docs/getting-started/quickstart/index.md
new file mode 100644
index 000000000000..f3f9056a829d
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/getting-started/quickstart/index.md
@@ -0,0 +1,156 @@
+---
+title: "Quick Start"
+description: "Get up and running with Docker Agent in under 5 minutes. Pick whichever path suits you best."
+keywords: docker agent, ai agents, getting started, quick start
+weight: 30
+canonical: https://docs.docker.com/ai/docker-agent/getting-started/quickstart/
+aliases:
+  - /ai/docker-agent/tutorial/
+---
+
+_Get up and running with Docker Agent in under 5 minutes. Pick whichever path suits you best._
+
+## Option A: Run the Default Agent
+
+The fastest way to try Docker Agent — no config file needed:
+
+```bash
+# Launch the default agent with the interactive TUI
+$ docker agent run
+```
+
+This starts a general-purpose assistant with sensible defaults. Just start chatting.
+
+> [!NOTE]
+> This needs a model: a cloud provider API key, or a local model pulled through Docker Model Runner. [Set Up a Model](../set-up-a-model/index.md) walks through both paths.
+
+## Option B: Run an Agent from a Registry
+
+Run an agent shared through any OCI-compatible registry — no local YAML needed:
+
+```bash
+$ docker agent run myorg/agent:tag
+```
+
+## Option C: Generate a Config Interactively
+
+Use the `docker agent new` command to scaffold a config file through prompts:
+
+```bash
+# Interactive wizard
+$ docker agent new
+
+# Or specify options directly
+$ docker agent new --model openai/gpt-5
+
+# Override iteration limits
+$ docker agent new --model dmr/ai/gemma3-qat:12B --max-iterations 15
+```
+
+This generates an `agent.yaml` in the current directory. Then run it:
+
+```bash
+$ docker agent run agent.yaml
+```
+
+## Option D: Write Your Own Config
+
+Create an `agent.yaml` by hand for full control. Here's a minimal example:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: A helpful coding assistant
+    instruction: |
+      You are an expert software developer. Help users write
+      clean, efficient code. Explain your reasoning.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
+
+This gives your agent:
+
+- **Claude Sonnet 4.5** as the underlying model
+- **Filesystem access** to read and write files
+- **Shell access** to run commands
+- **Think tool** for step-by-step reasoning
+
+This config needs `ANTHROPIC_API_KEY` set. See [Set Up a Model](../set-up-a-model/index.md) for where to put it, or use a local `dmr/...` model that needs no key.
+
+```bash
+# Launch the interactive terminal UI
+$ docker agent run agent.yaml
+```
+
+> [!TIP]
+> **Prefer HCL?**
+>
+> You can write the same config as `agent.hcl` using labeled blocks and heredocs. See [HCL Configuration](../../configuration/hcl/index.md).
+
+## Try It Out
+
+Once your agent is running, try asking it to:
+
+- _"List the files in the current directory"_
+- _"Create a Python script that fetches weather data"_
+- _"Explain what the code in main.go does"_
+
+> [!TIP]
+> Add `--yolo` to auto-approve all tool calls: `docker agent run agent.yaml --yolo`
+
+## Take the Interactive Tour
+
+Prefer to learn by doing? Run:
+
+```bash
+$ docker agent getting-started
+```
+
+This launches a short, scripted tour inside the chat UI: sending messages, approving tool calls, the command palette, and slash commands. It's skippable at any point with <kbd>Esc</kbd>, and you can replay it later with the same command or the `/getting-started` slash command.
+
+## Non-Interactive Mode
+
+Use `docker agent run --exec` for one-shot tasks:
+
+```bash
+# Ask a single question
+$ docker agent run --exec agent.yaml "Create a Dockerfile for a Node.js app"
+
+# Pipe input
+$ cat error.log | docker agent run --exec agent.yaml "What's wrong in this log?"
+```
+
+## Add More Power
+
+Give your agent persistent memory and web search:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Research assistant with memory
+    instruction: |
+      You are a research assistant. Search the web for information,
+      remember important findings, and provide thorough analysis.
+    toolsets:
+      - type: think
+      - type: memory
+        path: ./research.db
+      - type: mcp
+        ref: docker:duckduckgo
+```
+
+> [!NOTE]
+> **Docker MCP Tools**
+>
+> The `ref: docker:duckduckgo` syntax runs the DuckDuckGo MCP server in a Docker container. This is the recommended way to use MCP tools — secure, isolated, and easy to configure. Requires Docker Desktop.
+
+## What's Next?
+
+- [**Understand Agents**](../../concepts/agents/index.md) — learn how agents work and what you can configure.
+- [**Multi-Agent Systems**](../../concepts/multi-agent/index.md) — build teams of collaborating agents.
+- [**Configuration Reference**](../../configuration/overview/index.md) — full reference for all YAML and HCL options.
+- [**Troubleshooting**](../../community/troubleshooting/index.md) — something not working? Debug tips and common fixes.
diff --git a/_vendor/github.com/docker/docker-agent/docs/getting-started/set-up-a-model/index.md b/_vendor/github.com/docker/docker-agent/docs/getting-started/set-up-a-model/index.md
new file mode 100644
index 000000000000..bff584def8d3
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/getting-started/set-up-a-model/index.md
@@ -0,0 +1,276 @@
+---
+title: "Set Up a Model"
+description: "Make a model available to Docker Agent: connect a cloud provider, run a local model with Docker Model Runner, or register a custom OpenAI-compatible endpoint."
+keywords: docker agent, ai agents, getting started, set up a model, api key, local model, docker model runner, custom endpoint
+weight: 25
+canonical: https://docs.docker.com/ai/docker-agent/getting-started/set-up-a-model/
+---
+
+_Most agents need a model to think with: connect a built-in cloud provider, run a model locally with Docker Model Runner, or register a custom OpenAI-compatible endpoint. This page walks through each path end to end — plus the exception: agents that delegate to the Claude Code CLI on a Claude subscription, which need no model at all._
+
+## Pick a Path
+
+|               | Built-in cloud provider (Path A)                 | Local model (Path B)                     |
+| ------------- | ------------------------------------------------ | ---------------------------------------- |
+| You need      | An account and a credential (usually an API key) | Docker Desktop with Model Runner enabled |
+| Cost          | Pay per token                                    | Free once the model is downloaded        |
+| Your data     | Sent to the provider                             | Never leaves your machine                |
+| Model quality | Frontier models (Claude, GPT-5, Gemini)          | Open models sized to your hardware       |
+
+You can set up both. When you don't name a model, Docker Agent's `auto` selection picks the first cloud provider with a configured credential and falls back to a locally pulled Docker Model Runner model.
+
+Two more paths cover the remaining cases: if your models sit behind your own OpenAI-compatible endpoint (vLLM, LiteLLM, a corporate gateway), register it with its base URL as a [custom endpoint](#path-c-custom-openai-compatible-endpoint) (Path C); and if you have a **Claude subscription**, the [Claude Code harness](#path-d-claude-code-harness-claude-subscription) (Path D) runs the official `claude` CLI as the agent, with no API key and no local model required.
+
+> [!TIP]
+> **Prefer a wizard?**
+>
+> `docker agent setup` walks through the same choices interactively: pick a built-in provider and store its credential, check Docker Model Runner and pull a local model, register a custom OpenAI-compatible endpoint, or set up the Claude Code harness. This page is the manual version. See the [CLI reference](../../features/cli/index.md#docker-agent-setup).
+
+## Path A: Built-in Cloud Provider
+
+Docker Agent ships built-in support for many cloud providers: Anthropic, OpenAI, Google Gemini, Groq, Hugging Face, AWS Bedrock, GitHub Copilot, and more. You pick these by name instead of registering a custom provider. The providers `docker agent setup` lists — Groq and Hugging Face among them — come with a predefined endpoint, so setting the provider's credential is enough; some other built-in aliases need manual configuration, such as Azure OpenAI with your resource endpoint as `base_url`. The credential is usually an API key, but not always: Hugging Face uses the `HF_TOKEN` token, GitHub Copilot a `GITHUB_TOKEN`, AWS Bedrock your AWS credentials, and `chatgpt` signs in with your ChatGPT account in the browser via `docker agent setup`, with no key to paste. The steps below show the API-key flow that most providers follow.
+
+### 1. Get an API key
+
+Create a key in your provider's console:
+
+| Provider      | Environment variable | Get a key at                                                        |
+| ------------- | -------------------- | ------------------------------------------------------------------- |
+| Anthropic     | `ANTHROPIC_API_KEY`  | [console.anthropic.com](https://console.anthropic.com/settings/keys) |
+| OpenAI        | `OPENAI_API_KEY`     | [platform.openai.com](https://platform.openai.com/api-keys)          |
+| Google Gemini | `GOOGLE_API_KEY`     | [aistudio.google.com](https://aistudio.google.com/apikey)            |
+
+Every other provider with an API key works the same way. See [Model Providers](../../providers/overview/index.md) for the full list, each provider's credential variable, and the exceptions noted above.
+
+### 2. Store the key
+
+The fastest option is an environment variable in your shell:
+
+```bash
+$ export ANTHROPIC_API_KEY=sk-ant-...
+```
+
+That lasts for the current shell session. To set a key up once, use any other built-in secret source:
+
+```bash
+# Env file, passed at run time
+$ echo 'ANTHROPIC_API_KEY=sk-ant-...' > .env
+$ docker agent run --env-from-file .env
+
+# Docker Agent env file, read automatically on every run
+# (`docker agent setup` writes it for you with owner-only permissions)
+$ echo 'ANTHROPIC_API_KEY=sk-ant-...' >> ~/.config/cagent/.env
+$ chmod 600 ~/.config/cagent/.env
+```
+
+The entry name must match the environment variable the provider expects. [Managing Secrets](../../guides/secrets/index.md) covers every source (Docker Compose secrets, credential helpers, 1Password references) and the order they are checked in.
+
+> [!IMPORTANT]
+> Keys never go in `agent.yaml`. If you use an env file, add it to `.gitignore`.
+
+### 3. Verify
+
+`docker agent doctor` shows whether the key is visible and where it comes from:
+
+```bash
+$ docker agent doctor
+```
+
+```text
+User configuration
+  ~/.config/cagent/config.yaml: ok
+
+Model provider credentials
+  PROVIDER    STATUS    CREDENTIAL          SOURCE
+  anthropic   found     ANTHROPIC_API_KEY   environment
+  openai      not set   OPENAI_API_KEY      -
+  ...
+
+Docker Model Runner
+  Status: not installed (https://docs.docker.com/ai/model-runner/get-started/)
+
+Model auto-selection
+  auto -> anthropic/claude-sonnet-4-6
+
+No issues found.
+```
+
+### 4. Run
+
+```bash
+$ docker agent run
+```
+
+With no config file, the default agent picks the provider you configured. To name a model explicitly, use `--model` or the `model` field in your config:
+
+```bash
+$ docker agent run --model anthropic/claude-sonnet-4-5
+```
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: A helpful coding assistant
+    instruction: You are an expert software developer.
+```
+
+## Path B: Local Model (Docker Model Runner)
+
+Docker Model Runner (DMR) runs open models on your own machine: no API key, no per-token cost, and prompts never leave your computer.
+
+### 1. Install Docker Model Runner
+
+Model Runner ships with [Docker Desktop](https://www.docker.com/products/docker-desktop/) (enable it under **Settings > AI**) and is also available for Docker Engine. Check that it responds:
+
+```bash
+$ docker model status
+```
+
+If the command is missing or fails, follow the [Model Runner get-started guide](https://docs.docker.com/ai/model-runner/get-started/).
+
+### 2. Pull a model
+
+```bash
+$ docker model pull ai/qwen3
+```
+
+`ai/qwen3` is the model Docker Agent reaches for by default, but any model from the [Docker Hub `ai` catalog](https://hub.docker.com/u/ai) works. Pick one sized for your machine's memory. List what you have locally:
+
+```bash
+$ docker model ls
+```
+
+### 3. Verify
+
+```bash
+$ docker agent doctor
+```
+
+```text
+User configuration
+  ~/.config/cagent/config.yaml: ok
+
+Model provider credentials
+  PROVIDER    STATUS    CREDENTIAL          SOURCE
+  anthropic   not set   ANTHROPIC_API_KEY   -
+  ...
+
+Docker Model Runner
+  Status: reachable, 1 model(s) pulled:
+    - ai/qwen3:latest
+
+Model auto-selection
+  auto -> dmr/ai/qwen3:latest
+
+No issues found.
+```
+
+### 4. Run
+
+```bash
+$ docker agent run --model dmr/ai/qwen3
+```
+
+Or in your config:
+
+```yaml
+agents:
+  root:
+    model: dmr/ai/qwen3
+    description: A local assistant
+    instruction: You are a helpful assistant.
+```
+
+When no cloud key is configured, bare `docker agent run` auto-selects a pulled local model, so after `docker model pull` you can run with no flags at all. The [Docker Model Runner provider page](../../providers/dmr/index.md) covers context size, runtime flags, and other tuning options.
+
+## Path C: Custom OpenAI-compatible Endpoint
+
+If your models are served from your own endpoint (vLLM, LiteLLM, a corporate gateway, an API proxy), register it as a custom provider: you supply its base URL, the API format, and the environment variable holding its API key, if it needs one. Built-in providers such as Groq or Hugging Face don't need this; use [Path A](#path-a-built-in-cloud-provider) and set their credential instead.
+
+The interactive wizard is the quickest way:
+
+```bash
+$ docker agent setup   # pick "Custom OpenAI-compatible endpoint"
+```
+
+Or define the provider once in your user configuration (`~/.config/cagent/config.yaml`):
+
+```yaml
+providers:
+  myprovider:
+    base_url: https://llm.corp.example.com/v1
+    api_type: openai_chatcompletions
+    token_key: MYPROVIDER_API_KEY
+```
+
+Its models then work with every command:
+
+```bash
+$ docker agent models --provider myprovider
+$ docker agent run --model myprovider/<model>
+```
+
+See [Provider Definitions](../../providers/custom/index.md#global-providers-user-configuration) for the full reference, including per-agent-file providers and gateway behavior.
+
+## Path D: Claude Code Harness (Claude Subscription)
+
+If you already pay for a Claude subscription, an agent can delegate its work to
+the official Claude Code CLI instead of calling a model API. This is an
+**external CLI, not provider API access**: Docker Agent launches `claude`,
+which authenticates with its own subscription login — no `ANTHROPIC_API_KEY`,
+no Docker Model Runner, and no token ever passes through Docker Agent.
+
+### 1. Install and log in
+
+Install [Claude Code](https://docs.anthropic.com/en/docs/claude-code), then
+log in **as the same OS user and environment that run `docker agent`**:
+
+```bash
+$ claude auth login --claudeai   # interactive, opens a browser
+$ claude auth status --text      # verify
+```
+
+### 2. Create a harness agent
+
+`docker agent setup` (pick "Claude Code harness") generates this file for you,
+or write it yourself:
+
+```yaml
+# claude-code-agent.yaml
+agents:
+  root:
+    description: Claude Code running on your Claude subscription
+    harness:
+      type: claude-code
+      effort: medium # low | medium | high | xhigh | max; omit for the Claude Code default
+```
+
+### 3. Verify and run
+
+```bash
+$ docker agent doctor claude-code-agent.yaml   # checks the CLI is installed and logged in
+$ docker agent run claude-code-agent.yaml
+```
+
+The harness runs the CLI non-interactively and bypasses Claude Code's
+permission prompts, so use it in a repository you trust — see the security
+notes and full field reference in [Coding Harnesses](../../features/harnesses/index.md).
+
+## Check Your Setup Anytime
+
+`docker agent doctor` reports which providers have credentials (and from which source), whether Docker Model Runner is reachable and which models are pulled, and which model `auto` would pick. Secret values are never printed.
+
+```bash
+$ docker agent doctor                     # credential, DMR, and auto-selection state
+$ docker agent doctor ./agent.yaml        # also check that file's requirements
+```
+
+It exits non-zero when something would block a run, which makes it usable as a CI preflight. See the [CLI reference](../../features/cli/index.md#docker-agent-doctor).
+
+## What's Next?
+
+- [**Quick Start**](../quickstart/index.md) — run your first agent now that a model is available.
+- [**Models**](../../concepts/models/index.md) — inline vs. named models, fallbacks, and `auto` selection.
+- [**Managing Secrets**](../../guides/secrets/index.md) — every way to store credentials, compared.
+- [**Troubleshooting**](../../community/troubleshooting/index.md#missing-credentials-or-model-errors) — decode "no model available" and credential errors.
diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/_index.md b/_vendor/github.com/docker/docker-agent/docs/guides/_index.md
new file mode 100644
index 000000000000..3e7b3780ad13
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/guides/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Guides"
+description: "Practical guides for building and running agents."
+weight: 70
+---
diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/compaction/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/compaction/index.md
new file mode 100644
index 000000000000..67027ff65c03
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/guides/compaction/index.md
@@ -0,0 +1,149 @@
+---
+title: "Managing Context & Compaction"
+description: "How to keep long Docker Agent sessions from filling the model's context window: automatic and on-demand compaction, trimming tool results, and reading the context gauge."
+keywords: docker agent, ai agents, guides, context window, compaction, session compaction
+weight: 50
+canonical: https://docs.docker.com/ai/docker-agent/guides/compaction/
+---
+
+_How to keep long-running sessions from filling the model's context window._
+
+## Why long sessions fill the context window
+
+Every model has a fixed context window — a maximum number of tokens it can read per request. As a session grows, the system prompt, tool definitions, prompt files, and the full message history (including every tool call and its result) all count against that budget. A long-running agent — one that reads many files, runs many commands, or just keeps chatting for a while — eventually approaches the limit. Once a request no longer fits, the model provider rejects it and the session stalls.
+
+Docker Agent addresses this with **compaction**: replacing older parts of the conversation with a compact AI-generated summary, freeing up room for the session to keep going. This guide covers the levers you have — automatic compaction, on-demand compaction, and trimming individual tool results — and how to read the context gauge so you know where a session stands.
+
+## Let Docker Agent compact automatically
+
+By default, every agent proactively compacts its own session once estimated token usage crosses **90%** of the model's context window:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: A long-running research assistant
+    instruction: You are a helpful assistant.
+```
+
+No configuration is required to get this behavior — it's on by default. Three fields let you tune it:
+
+| Field | Where | Description |
+| --- | --- | --- |
+| `session_compaction` | agent | Set to `false` to disable automatic compaction entirely for this agent (both the proactive threshold trigger and the post-overflow auto-recovery). The manual `/compact` command still works. Default: `true`. |
+| `compaction_threshold` | agent or model | Fraction of the context window (greater than `0`, at most `1`) at which proactive compaction fires. A value set on the model takes precedence over the agent-level value. Default: `0.9`. |
+| `compaction_model` | agent, model, or provider | Delegate the compaction (summary-generation) call to a different, usually cheaper and faster, model. The agent-level value wins, then the model-level value, then the provider-level default. |
+
+Lower the threshold to compact earlier and keep individual requests smaller and cheaper; raise it to keep more verbatim history in context before the first summary happens:
+
+```yaml
+models:
+  primary:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    # Compact at 80% of the window instead of the default 90%.
+    compaction_threshold: 0.8
+```
+
+Compaction itself is a model call — feeding the full conversation to a model and asking for a summary — and it's the most expensive call in a session simply because it's the one that runs when the context is largest. There's rarely a reason to spend your primary reasoning model on it. Point `compaction_model` at something smaller instead; every other call still runs on the primary model:
+
+```yaml
+models:
+  primary:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    compaction_model: fast
+  fast:
+    provider: anthropic
+    model: claude-haiku-4-5
+```
+
+> [!IMPORTANT]
+> **Context window mismatch**
+>
+> If `compaction_model` has a **smaller** context window than the primary model, Docker Agent triggers compaction against the smaller window so the summary call can always ingest the full conversation. Pair the primary model with a compaction model whose window is at least as large to keep the proactive trigger aligned with the primary model's window.
+>
+> The `/context` header and the sidebar's context gauge surface this cap when it applies: the `/context` header shows a second line reading "compaction cap: `<model>` • `<N>` tokens", and the sidebar shows a short "⚠ capped" marker. Live-sessions rows do not carry cap wording; the sidebar marker deliberately doesn't repeat the model name or figure — the `/context` header is the sole authority on why the reported limit is smaller than the primary model's own window.
+
+Disable compaction only when you specifically want a session to keep full, unabridged history and are willing to risk hitting the context limit:
+
+```yaml
+agents:
+  archivist:
+    model: anthropic/claude-sonnet-4-5
+    description: An assistant that never auto-compacts its sessions.
+    instruction: You keep full conversation history and never lose context.
+    session_compaction: false
+```
+
+See [`examples/compaction_model.yaml`](https://github.com/docker/docker-agent/blob/main/examples/compaction_model.yaml) and [`examples/compaction_threshold.yaml`](https://github.com/docker/docker-agent/blob/main/examples/compaction_threshold.yaml) for complete configurations, and [Delegating Session Compaction](../../configuration/models/index.md#delegating-session-compaction) in the Model Config reference for the full field-level details.
+
+## Compact on demand
+
+You don't have to wait for the automatic threshold. Two TUI commands give you direct control:
+
+- **`/compact`** — summarize and compact the current session's history right now, regardless of how full the context window is. Useful before starting a new phase of work that doesn't need the earlier detail.
+- **`/context`** — open a context-window breakdown: estimated tokens per category (system prompt, tool definitions, prompt files, messages, tool results, compaction summary), a **Live sessions** view listing the current session plus every running sub-agent session with its own context budget, and a per-file inventory of attachments and prompt files. When a compaction has occurred, the dialog also displays the verbatim text of the most recent compaction summary, preserving hard newlines and soft-wrapping long lines to the dialog width.
+
+From `/context`, select any live session with the arrow keys and press <kbd>Enter</kbd> to explicitly compact it — including a sub-agent's session, not just the main one. This is the only way cross-agent compaction happens: there's no idle-triggered automatic compaction of sub-agent sessions, so a long-running background agent stays under your control. The request is queued onto the target session's own run loop and applied at the next safe point between model turns, so it never corrupts an in-flight turn.
+
+```bash
+$ docker agent run agent.yaml
+# ... work for a while ...
+# Type /context to see the current breakdown, or /compact to summarize now
+```
+
+## Trim tool results to save room
+
+Compaction deals with the whole conversation at once. For sessions dominated by a few oversized tool results — a full build log, a large file dump — three agent-level fields let you cap the damage before it ever reaches compaction:
+
+| Field | What it bounds | Behavior |
+| --- | --- | --- |
+| `max_tool_result_tokens` | Each tool result, as it's added to the session | Oversized results are truncated **middle-out**: the head and tail are kept (usually the most informative parts) and the removed middle is replaced with a truncation marker. |
+| `max_old_tool_call_tokens` | The total budget for **old** tool call arguments and results | Once older tool calls exceed the budget, their content is replaced wholesale with a placeholder — freeing context space without touching recent, still-relevant calls. |
+| `num_history_items` | The number of non-system conversation messages kept in history | A message-**count** limit, not a token budget. The oldest non-protected messages are dropped first once the count is exceeded; **system and user messages are always protected** and are never counted against or removed by this limit, so the assembled history can exceed `num_history_items` and every user message survives even a long single-turn agentic loop. |
+
+`max_tool_result_tokens` and `max_old_tool_call_tokens` are approximated as `len/4` tokens (the industry rule-of-thumb of ~4 characters per token); `num_history_items` counts messages, not tokens. All three are disabled by default (`0`). Set a positive value to enable them:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: An assistant whose tool results are capped at ~2000 tokens each.
+    instruction: |
+      You are a helpful assistant with shell access. Very large command
+      outputs are truncated in the middle — the beginning and end are
+      always preserved, and a marker shows where content was removed.
+    max_tool_result_tokens: 2000
+    toolsets:
+      - type: shell
+```
+
+> [!TIP]
+> **Use both together**
+>
+> `max_tool_result_tokens` bounds each result the moment it's recorded; `max_old_tool_call_tokens` reclaims space from calls that are no longer fresh. Combine them on tool-heavy agents (shell, filesystem) to keep the session lean well before it approaches the compaction threshold.
+
+See [`examples/max_tool_result_tokens.yaml`](https://github.com/docker/docker-agent/blob/main/examples/max_tool_result_tokens.yaml) for a complete example, and [Agent Config](../../configuration/agents/index.md#properties-reference) for the full field reference.
+
+## Read the context gauge
+
+The TUI's sidebar token-usage section (and the fill bar in the [lean TUI](../../features/tui/index.md#lean-tui) status line) color-escalates as a session approaches its compaction threshold, so you can see trouble coming before a request fails:
+
+| State | Color | Trigger |
+| --- | --- | --- |
+| Normal | (default) | Usage below 75% of the compaction threshold |
+| Warning | Orange | Usage at or above 75% of the compaction threshold |
+| Critical | Red | Usage at or above 95% of the compaction threshold |
+
+While a compaction is running, the percentage is replaced by a **"compacting…"** indicator; token counts remain visible in the lean TUI status line. The thresholds scale with the agent's configured `compaction_threshold` (default `0.9`), so a custom value keeps a predictable visual runway — for example, a `compaction_threshold: 0.8` session turns orange at 60% usage (75% of 0.8) instead of 67.5%.
+
+Open `/context` at any time for the full per-category breakdown behind that percentage.
+
+## What happens to cost across compaction
+
+Compaction summarizes history, but it never resets what a session has actually cost you. Session cost tracking is **monotonic across compaction**: the running total only ever goes up, even though the summarized conversation itself is now smaller. Check `/cost` to see the current breakdown at any point, before or after a compaction has run.
+
+## Related: deferred tool loading
+
+Compaction and result trimming manage context that's already in the session. If large toolsets are inflating your **starting** context instead — many MCP servers, hundreds of tools — look at [deferred tool loading](../../configuration/tools/index.md#deferred-tool-loading), which registers a toolset's tools lazily instead of eagerly at startup.
diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/go-sdk/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/go-sdk/index.md
new file mode 100644
index 000000000000..909729e16f3c
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/guides/go-sdk/index.md
@@ -0,0 +1,650 @@
+---
+title: "Go SDK"
+description: "Use Docker Agent as a Go library to embed AI agents in your applications."
+keywords: docker agent, ai agents, guides, go sdk
+weight: 40
+canonical: https://docs.docker.com/ai/docker-agent/guides/go-sdk/
+---
+
+_Use Docker Agent as a Go library to embed AI agents in your applications._
+
+## Overview
+
+Docker Agent can be used as a Go library, allowing you to build AI agents directly into your Go applications. This gives you full programmatic control over agent creation, tool integration, and execution.
+
+> [!NOTE]
+> **Import Path**
+>
+> ```go
+> import "github.com/docker/docker-agent/pkg/..."
+> ```
+
+## Core Packages
+
+| Package                | Purpose                                  |
+| ---------------------- | ---------------------------------------- |
+| `pkg/agent`            | Agent creation and configuration         |
+| `pkg/runtime`          | Agent execution and event streaming      |
+| `pkg/session`          | Conversation state management            |
+| `pkg/team`             | Multi-agent team composition             |
+| `pkg/tools`            | Tool interface and utilities             |
+| `pkg/tools/builtin`    | Built-in tools (shell, filesystem, etc.) |
+| `pkg/model/provider/*` | Model provider clients                   |
+| `pkg/config/latest`    | Configuration types                      |
+| `pkg/environment`      | Environment and secrets                  |
+| `pkg/embeddedchat`     | Headless chat session for embedding the agent runtime in a custom UI |
+| `pkg/tui/components/toolconfirm` | Tool-confirmation policy: `Decision` enum, `BuildPermissionPattern`, key bindings, and rejection-reason presets. Share this instead of copying the permission-pattern logic. |
+| `pkg/tui/service`      | `StaticSessionState` — a `SessionStateReader` with conservative fixed values, for rendering message/tool views outside the full TUI app. Replaces hand-rolled nine-method stubs. |
+| `pkg/tui/animation`    | `Stopper` / `StopView` — animation lifecycle contract. Call `StopAnimation` on views removed from the UI to prevent leaked tick subscriptions. |
+| `pkg/tui/components/transcript` | Embedded transcript view with read-only `Messages()` accessor for observing conversation structure in host tests and persistence layers. |
+
+## Embedding TUI Components
+
+When building custom UIs on top of Docker Agent's TUI primitives, four packages define the contracts that keep the runtime and the UI in sync:
+
+- **`pkg/tui/components/toolconfirm`** — import this package for the permission-decision policy rather than copying the pattern-building logic. The `Decision` enum, `BuildPermissionPattern` helper, and rejection-reason presets are the canonical source of truth: whatever pattern is shown to the user in the confirmation dialog is exactly the pattern granted to the runtime.
+- **`pkg/tui/service`** — use `StaticSessionState` as a stub `SessionStateReader` when rendering individual message or tool views outside the full TUI app. It returns conservative fixed values for all nine interface methods, eliminating the need for hand-rolled stubs.
+- **`pkg/tui/animation`** — implement `animation.Stopper` on any view that owns a tick-based animation. Call `StopAnimation` whenever a view is removed from the UI hierarchy to prevent leaked `time.Tick` subscriptions from firing against a dead view.
+- **`pkg/tui/components/transcript`** — embed the transcript view for displaying conversation history. Use the `Messages()` method to read the current slice of transcript messages (treat as read-only — mutations desync renders). This is useful for host-side tests asserting on chat history, and for persistence layers that need to snapshot conversation state.
+
+## Headless Embedded Chat (`pkg/embeddedchat`)
+
+`pkg/embeddedchat` is a thin wrapper around the Docker Agent runtime that lets you drive an agent from your own UI instead of running Docker Agent's Bubble Tea application. It handles runtime construction, event projection, and conversation state, exposing a simple `Send` / `Confirm` / `Restart` / `Close` API.
+
+### Creating a session
+
+```go
+import (
+    "context"
+    "fmt"
+    "strings"
+
+    dagentcfg "github.com/docker/docker-agent/pkg/config"
+    dagentruntime "github.com/docker/docker-agent/pkg/runtime"
+    "github.com/docker/docker-agent/pkg/embeddedchat"
+)
+
+chat, err := embeddedchat.New(ctx, embeddedchat.Config{
+    // AgentSource can be a file path, raw YAML bytes, or an OCI reference.
+    AgentSource: dagentcfg.NewBytesSource("agent", []byte(agentYAML)),
+})
+if err != nil {
+    return err
+}
+defer chat.Close()
+```
+
+### Sending a message and reading events
+
+`Send` appends the user message to the conversation and returns a channel of `Event` values. Drain the channel until it closes.
+
+```go
+events, err := chat.Send(ctx, "Hello! What can you do?")
+if err != nil {
+    return err
+}
+
+var response strings.Builder
+for ev := range events {
+    switch {
+    case ev.Text != "":
+        response.WriteString(ev.Text)
+    case ev.Tool != nil && ev.Tool.NeedsConfirmation:
+        // Approve the pending tool call (use ResumeApproveSession to allow all).
+        if err := chat.Confirm(ctx, dagentruntime.ResumeApprove()); err != nil {
+            return err
+        }
+    case ev.Tool != nil && ev.Tool.Finished:
+        fmt.Printf("[tool %s finished]\n", ev.Tool.Def.Name)
+    case ev.Err != nil:
+        fmt.Printf("error: %v\n", ev.Err)
+    case ev.Done:
+        fmt.Println("\n[turn complete]")
+    }
+}
+fmt.Print(response.String())
+```
+
+### Restarting the conversation
+
+To start a fresh conversation without recreating the runtime:
+
+```go
+if err := chat.Restart(); err != nil {
+    return err
+}
+```
+
+### Event types
+
+| Field          | When set                                                                 |
+| -------------- | ------------------------------------------------------------------------ |
+| `Text`         | Assistant text delta; accumulate into a string for the full reply.       |
+| `Tool`         | A tool call started, needs confirmation, or finished.                    |
+| `Tool.NeedsConfirmation` | Runtime is blocked until `Confirm` is called.              |
+| `Tool.Finished` | Tool call completed; `Tool.IsError` is true if it errored.             |
+| `Err`          | A user-facing runtime error; no further content events follow.           |
+| `Done`         | Clean end of turn; no more events.                                       |
+| `RuntimeEvent` | The original `runtime.Event` for callers that need the full stream.      |
+
+For advanced use (custom elicitation, raw event inspection), call `chat.Runtime()` to access the underlying `runtime.Runtime` directly.
+
+> [!WARNING]
+> **Breaking change: `Runtime.ResumeElicitation` (#3584)**
+>
+> `Runtime.ResumeElicitation` gained an `elicitationID` parameter so responses can
+> be correlated with a specific concurrent elicitation request (needed once
+> multiple background jobs can be eliciting input at the same time). It is
+> declared **variadic** (`elicitationID ...string`) specifically so existing
+> *callers* of the 3-argument form keep compiling unchanged — `rt.ResumeElicitation(ctx, action, content)`
+> still works and falls back to resolving the sole pending request.
+>
+> If you implement your own `runtime.Runtime` (rather than embedding
+> `runtime.LocalRuntime`/`runtime.RemoteRuntime`), you do need to update your
+> method's signature to match, and also add an `OnElicitationRequest(handler
+> func(runtime.Event))` method (a no-op is fine if your runtime never raises
+> elicitations) — both are required interface methods, matching the existing
+> no-op-able pattern already used by `OnToolsChanged`/`OnBackgroundEvent`.
+
+## Optional Provider Build Tags
+
+By default Docker Agent includes all four cloud providers (OpenAI, Anthropic, Google, Amazon Bedrock). When embedding Docker Agent in your own binary you can compile out unneeded providers — together with their transitive SDK dependencies — to reduce binary size.
+
+Each provider is gated by a negative build tag prefixed `docker_agent_` to avoid collisions with your own project's tags:
+
+| Build tag                    | Provider dropped         | Major dependency removed                          |
+| ---------------------------- | ------------------------ | ------------------------------------------------- |
+| `docker_agent_no_openai`     | OpenAI                   | `github.com/openai/openai-go`                     |
+| `docker_agent_no_anthropic`  | Anthropic                | `github.com/anthropics/anthropic-sdk-go` (partial — see note) |
+| `docker_agent_no_google`     | Google / Vertex AI       | `google.golang.org/genai`, Vertex auth stack, and indirectly the Anthropic and OpenAI SDKs via Vertex Model Garden |
+| `docker_agent_no_bedrock`    | Amazon Bedrock           | `github.com/aws/aws-sdk-go-v2` stack (the largest provider dependency tree) |
+
+To build without Bedrock and OpenAI:
+
+```bash
+go build -tags 'docker_agent_no_bedrock docker_agent_no_openai' ./...
+```
+
+Requesting a model whose provider was compiled out fails at construction time with a clear `"not compiled into this build"` error. The `dmr` (Docker Model Runner) provider and the rule-based router are always compiled in.
+
+> [!WARNING]
+> **Anthropic + Google dependency**
+>
+> The Google provider's Vertex Model Garden support also imports the Anthropic SDK, so the Anthropic dependency is only fully removed when _both_ `docker_agent_no_anthropic` and `docker_agent_no_google` are set.
+
+## RAG Toolset (opt-out)
+
+The RAG toolset (`type: rag`) is included in `NewDefaultToolsetRegistry()` (from `pkg/teamloader/toolsets`) and `loaderdefaults.Opts()` (from `pkg/teamloader/defaults`, using the conventional import alias `loaderdefaults`).
+
+The underlying tree-sitter code parser uses cgo, but build-tag guards in `pkg/rag/treesitter` mean importing the package is safe regardless of `CGO_ENABLED`: with `CGO_ENABLED=0` the parser stub compiles in and returns a runtime error on first use rather than failing at compile time.
+
+If you want to exclude the RAG toolset from your binary entirely — surfacing a load-time warning on the agent rather than a deferred runtime error from the `!cgo` stub — remove it from the registry before passing it to `teamloader.Load`:
+
+```go
+import (
+    "github.com/docker/docker-agent/pkg/teamloader"
+    loadertoolsets "github.com/docker/docker-agent/pkg/teamloader/toolsets"
+)
+
+// Opt out of the RAG toolset; a config that declares type: rag attaches
+// a load-time warning to the agent instead of failing at document processing.
+creators := loadertoolsets.DefaultToolsetCreators()
+delete(creators, "rag")
+registry := teamloader.NewToolsetRegistry(creators)
+```
+
+Pass the custom registry via `teamloader.WithToolsetRegistry(registry)` when calling `teamloader.Load`. Note that `teamloader.Load()` does not return an error for unknown toolset types — the failure is recorded as a load-time warning and can be retrieved with `agent.DrainWarnings()`; it is also surfaced via logging and TUI notifications.
+
+## Registering Custom Built-in Themes
+
+When embedding Docker Agent, you can contribute your own built-in themes via `styles.RegisterBuiltinThemes`. Registered themes integrate seamlessly with the existing theme picker, `/theme` command, and `settings.theme` config key — they behave exactly like Docker Agent's own bundled themes.
+
+```go
+import (
+    "embed"
+
+    "github.com/docker/docker-agent/pkg/tui/styles"
+)
+
+//go:embed themes/*.yaml
+var brandThemes embed.FS
+
+// Call at startup, before applying any persisted theme:
+if err := styles.RegisterBuiltinThemes(brandThemes); err != nil {
+    return err
+}
+```
+
+Each theme file lives at `themes/<name>.yaml` inside the embedded filesystem and is a **partial override** — only the colors you want to change are required; everything else falls back to `DefaultTheme()`.
+
+```yaml
+# themes/brand.yaml
+name: Brand
+colors:
+  accent: "#FF6A00"
+  background: "#1A0F0A"
+```
+
+If `name:` is omitted, Docker Agent uses the filename stem as the display name in the theme picker (e.g. `brand` from `themes/brand.yaml`).
+
+To replace Docker Agent's default theme entirely, ship the file as `themes/default.yaml` — it masks the bundled default while inheriting any colors you don't set.
+
+**Semantics:**
+
+- Registered sources take precedence over bundled themes; a registered ref overrides a bundled theme of the same name.
+- Among multiple registered sources, last-registered wins on a collision.
+- `RegisterBuiltinThemes` validates eagerly (nil fs, missing `themes/` dir) so errors surface at registration time, not at picker time.
+
+## MCP OAuth Token Persistence
+
+By default, MCP OAuth tokens are stored in-memory only and are not persisted across process restarts. The CLI registers a keyring-backed store automatically at startup; when embedding Docker Agent as a library you must do this yourself if you want tokens to survive restarts.
+
+Call `keyringstore.Register()` **before** any MCP toolset is initialised to enable the OS keyring-backed token store:
+
+```go
+import "github.com/docker/docker-agent/pkg/tools/mcp/keyringstore"
+
+func main() {
+    // Must be called before teamloader.Load() on configs with remote MCP
+    // toolsets; calling it after the store is created panics.
+    keyringstore.Register()
+    // ... rest of your startup code
+}
+```
+
+> [!WARNING]
+> **Call order matters**
+>
+> If `keyringstore.Register()` is called after the default token store has already been lazily initialised, Docker Agent panics. The store is initialised when any remote MCP toolset is constructed — which happens inside `teamloader.Load()`. Always call `keyringstore.Register()` before calling `teamloader.Load()` on a config that includes remote MCP toolsets.
+
+If you do not need persistent OAuth tokens (for example, in short-lived batch jobs or tests), omit the call and tokens will be kept in-memory for the process lifetime.
+
+## JavaScript Command Expressions (opt-in)
+
+Slash-command instructions can embed `${...}` JavaScript expressions (`${args[0]}`, `${args.join(" ")}`, `${tool({...})}`). Evaluating them requires the goja JavaScript engine, which is deliberately kept out of `pkg/runtime`'s import graph so code-built embedders don't link it by default.
+
+The CLI, `teamloader.Load()`, `pkg/cli.Run()` and `embeddedchat/defaults` enable it automatically. If you build teams in code, call `runtime.ResolveCommand` (or `cli.PrepareUserMessage`) directly **and** use `${...}` expressions in commands, register the evaluator yourself:
+
+```go
+import "github.com/docker/docker-agent/pkg/runtime/jscommands"
+
+func main() {
+    jscommands.Register()
+    // ... rest of your startup code
+}
+```
+
+Without the registration, `${...}` expressions are left unexpanded and a warning naming the fix is logged; everything else about command resolution (including the legacy `!tool(...)` syntax) works as usual.
+
+## Basic Example
+
+Create a simple agent and run it:
+
+```go
+package main
+
+import (
+    "context"
+    "fmt"
+    "log"
+    "os/signal"
+    "syscall"
+
+    "github.com/docker/docker-agent/pkg/agent"
+    "github.com/docker/docker-agent/pkg/config/latest"
+    "github.com/docker/docker-agent/pkg/environment"
+    "github.com/docker/docker-agent/pkg/model/provider/openai"
+    "github.com/docker/docker-agent/pkg/runtime"
+    "github.com/docker/docker-agent/pkg/session"
+    "github.com/docker/docker-agent/pkg/team"
+)
+
+func main() {
+    ctx, cancel := signal.NotifyContext(context.Background(),
+        syscall.SIGINT, syscall.SIGTERM)
+    defer cancel()
+
+    if err := run(ctx); err != nil {
+        log.Fatal(err)
+    }
+}
+
+func run(ctx context.Context) error {
+    // Create model provider
+    llm, err := openai.NewClient(
+        ctx,
+        &latest.ModelConfig{
+            Provider: "openai",
+            Model:    "gpt-4o",
+        },
+        environment.NewDefaultProvider(),
+    )
+    if err != nil {
+        return err
+    }
+
+    // Create agent
+    assistant := agent.New(
+        "root",
+        "You are a helpful assistant.",
+        agent.WithModel(llm),
+        agent.WithDescription("A helpful assistant"),
+    )
+
+    // Create team and runtime
+    t := team.New(team.WithAgents(assistant))
+    rt, err := runtime.New(t)
+    if err != nil {
+        return err
+    }
+
+    // Run with a user message
+    sess := session.New(
+        session.WithUserMessage("What is 2 + 2?"),
+    )
+
+    messages, err := rt.Run(ctx, sess)
+    if err != nil {
+        return err
+    }
+
+    // Print the response
+    fmt.Println(messages[len(messages)-1].Message.Content)
+    return nil
+}
+```
+
+## Custom Tools
+
+Define custom tools for your agent:
+
+```go
+package main
+
+import (
+    "context"
+    "encoding/json"
+    "fmt"
+
+    "github.com/docker/docker-agent/pkg/tools"
+)
+
+// Define the tool's input schema
+type AddNumbersArgs struct {
+    A int `json:"a"`
+    B int `json:"b"`
+}
+
+// Implement the tool handler
+func addNumbers(_ context.Context, toolCall tools.ToolCall) (*tools.ToolCallResult, error) {
+    var args AddNumbersArgs
+    if err := json.Unmarshal([]byte(toolCall.Function.Arguments), &args); err != nil {
+        return nil, err
+    }
+
+    result := args.A + args.B
+    return tools.ResultSuccess(fmt.Sprintf("%d", result)), nil
+}
+
+func main() {
+    // Create the tool definition
+    addTool := tools.Tool{
+        Name:        "add",
+        Category:    "math",
+        Description: "Add two numbers together",
+        Parameters:  tools.MustSchemaFor[AddNumbersArgs](),
+        Handler:     addNumbers,
+    }
+
+    // Use with an agent
+    calculator := agent.New(
+        "root",
+        "You are a calculator. Use the add tool for arithmetic.",
+        agent.WithModel(llm),
+        agent.WithTools(addTool),
+    )
+    // ...
+}
+```
+
+## Streaming Responses
+
+Process events as they happen:
+
+```go
+func runStreaming(ctx context.Context, rt runtime.Runtime, sess *session.Session) error {
+    events := rt.RunStream(ctx, sess)
+
+    for event := range events {
+        switch e := event.(type) {
+        case *runtime.StreamStartedEvent:
+            fmt.Println("Stream started")
+
+        case *runtime.AgentChoiceEvent:
+            // Print response chunks as they arrive
+            fmt.Print(e.Content)
+
+        case *runtime.ToolCallEvent:
+            fmt.Printf("\n[Tool call: %s]\n", e.ToolCall.Function.Name)
+
+        case *runtime.ToolCallConfirmationEvent:
+            // Auto-approve tool calls
+            rt.Resume(ctx, runtime.ResumeRequest{
+                Type: runtime.ResumeTypeApproveSession,
+            })
+
+        case *runtime.ToolCallResponseEvent:
+            fmt.Printf("[Tool response: %s]\n", e.Response)
+
+        case *runtime.StreamStoppedEvent:
+            fmt.Println("\nStream stopped")
+
+        case *runtime.ErrorEvent:
+            return fmt.Errorf("error: %s", e.Error)
+        }
+    }
+
+    return nil
+}
+```
+
+## Multi-Agent Teams
+
+Create agents that delegate to sub-agents:
+
+```go
+package main
+
+import (
+    "github.com/docker/docker-agent/pkg/agent"
+    "github.com/docker/docker-agent/pkg/team"
+    "github.com/docker/docker-agent/pkg/tools/builtin"
+)
+
+func createTeam(llm provider.Provider) *team.Team {
+    // Create a child agent
+    researcher := agent.New(
+        "researcher",
+        "You research topics thoroughly.",
+        agent.WithModel(llm),
+        agent.WithDescription("Research specialist"),
+    )
+
+    // Create root agent with sub-agents
+    coordinator := agent.New(
+        "root",
+        "You coordinate research tasks.",
+        agent.WithModel(llm),
+        agent.WithDescription("Team coordinator"),
+        agent.WithSubAgents(researcher),
+        agent.WithToolSets(builtin.NewTransferTaskTool()),
+    )
+
+    return team.New(team.WithAgents(coordinator, researcher))
+}
+```
+
+## Built-in Tools
+
+Use Docker Agent's built-in tools:
+
+```go
+import (
+    "github.com/docker/docker-agent/pkg/config"
+    "github.com/docker/docker-agent/pkg/tools/builtin"
+)
+
+func createAgentWithBuiltinTools(llm provider.Provider) *agent.Agent {
+    // Runtime config for tools that need it
+    rtConfig := &config.RuntimeConfig{
+        Config: config.Config{
+            WorkingDir: "/path/to/workdir",
+        },
+    }
+
+    return agent.New(
+        "root",
+        "You are a developer assistant.",
+        agent.WithModel(llm),
+        agent.WithToolSets(
+            // Shell tool for running commands
+            builtin.NewShellTool(os.Environ(), rtConfig),
+            // Filesystem tools
+            builtin.NewFilesystemTool(rtConfig.Config.WorkingDir),
+            // Think tool for reasoning
+            builtin.NewThinkTool(),
+            // Todo tool for task tracking
+            builtin.NewTodoTool(),
+        ),
+    )
+}
+```
+
+## HTTP Middleware / Transport Wrappers
+
+Use `options.WithHTTPTransportWrapper` to inject HTTP middleware into the transport chain of all provider clients built by Docker Agent. This is useful for request tracing, injecting custom headers, collecting metrics, or any other cross-cutting concern at the HTTP layer.
+
+```go
+import (
+    "net/http"
+
+    "github.com/docker/docker-agent/pkg/model/provider/options"
+)
+
+type headerTransport struct {
+    base http.RoundTripper
+}
+
+func (t *headerTransport) RoundTrip(req *http.Request) (*http.Response, error) {
+    req = req.Clone(req.Context())
+    req.Header.Set("X-Request-Source", "my-app")
+    return t.base.RoundTrip(req)
+}
+
+// Example: add a custom header to every outbound LLM request
+wrapper := options.WithHTTPTransportWrapper(
+    func(base http.RoundTripper) http.RoundTripper {
+        return &headerTransport{base: base}
+    },
+)
+
+client, err := openai.NewClient(ctx, &latest.ModelConfig{
+    Provider: "openai",
+    Model:    "gpt-4o",
+}, env, wrapper)
+```
+
+The wrapper receives the already-instrumented transport (OpenTelemetry, SSE decompression, Desktop proxy support) as its `base` argument, so wrapping it preserves all built-in behaviour.
+
+**Supported providers:** Anthropic, OpenAI, Gemini (GeminiAPI backend), Bedrock. Works in both direct and gateway/proxy mode.
+
+> [!WARNING]
+> **Vertex AI not supported**
+>
+> Vertex AI uses an ADC-managed HTTP client that Docker Agent cannot intercept. When a transport wrapper is set, Docker Agent falls back to the GeminiAPI backend instead of Vertex AI — a debug message is logged.
+
+In **gateway mode** the wrapper is called on every LLM request because gateway clients are rebuilt each call for short-lived auth tokens. In **direct mode** it is called once at client construction. Rate-limit responses (HTTP 429) are classified as non-retryable by the runtime and cause the model chain to skip to the next fallback, so wrappers that track per-request outcomes will observe these as failures rather than retried calls.
+
+Returning `nil` from your wrapper function is not allowed; Docker Agent logs a warning and keeps the original transport instead.
+
+## Using Different Providers
+
+```go
+import (
+    "github.com/docker/docker-agent/pkg/model/provider/anthropic"
+    "github.com/docker/docker-agent/pkg/model/provider/gemini"
+    "github.com/docker/docker-agent/pkg/model/provider/openai"
+)
+
+// OpenAI
+openaiClient, _ := openai.NewClient(ctx, &latest.ModelConfig{
+    Provider: "openai",
+    Model:    "gpt-4o",
+}, env)
+
+// Anthropic
+anthropicClient, _ := anthropic.NewClient(ctx, &latest.ModelConfig{
+    Provider: "anthropic",
+    Model:    "claude-sonnet-4-5",
+}, env)
+
+// Google Gemini
+geminiClient, _ := gemini.NewClient(ctx, &latest.ModelConfig{
+    Provider: "google",
+    Model:    "gemini-3.5-flash",
+}, env)
+```
+
+## Session Options
+
+```go
+import "github.com/docker/docker-agent/pkg/session"
+
+sess := session.New(
+    // Set a title for the session
+    session.WithTitle("Code Review Task"),
+
+    // Add user message
+    session.WithUserMessage("Review this code for bugs"),
+
+    // Limit iterations
+    session.WithMaxIterations(20),
+)
+```
+
+## Error Handling
+
+```go
+messages, err := rt.Run(ctx, sess)
+if err != nil {
+    if errors.Is(err, context.Canceled) {
+        // User cancelled
+        log.Println("Operation cancelled")
+        return nil
+    }
+    if errors.Is(err, context.DeadlineExceeded) {
+        // Timeout
+        log.Println("Operation timed out")
+        return nil
+    }
+    // Other error
+    return fmt.Errorf("runtime error: %w", err)
+}
+
+// Check for errors in the event stream
+for event := range rt.RunStream(ctx, sess) {
+    if errEvent, ok := event.(*runtime.ErrorEvent); ok {
+        return fmt.Errorf("stream error: %s", errEvent.Error)
+    }
+}
+```
+
+## Complete Example
+
+See the [examples/golibrary](https://github.com/docker/docker-agent/tree/main/examples/golibrary) directory for complete working examples:
+
+- `simple/` — Basic agent with no tools
+- `tool/` — Custom tool implementation
+- `stream/` — Streaming event handling
+- `multi/` — Multi-agent with sub-agents
+- `builtintool/` — Using built-in tools
diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/headless/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/headless/index.md
new file mode 100644
index 000000000000..76a87bd4d505
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/guides/headless/index.md
@@ -0,0 +1,225 @@
+---
+title: "Running Agents Headless & in CI"
+description: "Run Docker Agent without a TUI: structured JSON output, event hooks, sandboxed CI isolation, and a GitHub Actions example."
+keywords: docker agent, ai agents, guides, headless, ci, github actions, sandbox
+weight: 50
+canonical: https://docs.docker.com/ai/docker-agent/guides/headless/
+---
+
+_Run Docker Agent without a TUI: structured JSON output, event hooks, sandboxed CI isolation, and a GitHub Actions example._
+
+## `--exec` Mode Basics
+
+`--exec` runs an agent without the interactive TUI: output goes to stdout and the process exits when the conversation is done. It's the mode to use in scripts, CI, and any context without a terminal.
+
+```bash
+# One-shot task, message as an argument
+$ docker agent run --exec agent.yaml "Summarize the open issues in this repo"
+
+# Pipe the message via stdin instead
+$ echo "Summarize the open issues in this repo" | docker agent run --exec agent.yaml -
+
+# Multiple messages are processed as a multi-turn conversation, in order
+$ docker agent run --exec agent.yaml "question 1" "question 2" "question 3"
+```
+
+See [`docker agent run --exec`](../../features/cli/index.md#docker-agent-run---exec) for the full flag reference.
+
+## Choosing a Large-Input Strategy
+
+Docker Agent has several unrelated mechanisms for getting a large document, file, or dataset in front of an agent. Which one fits depends on whether the content is local to the machine running Docker Agent, how often it needs to be revisited, and whether you're driving the agent through the CLI/TUI or over one of the HTTP servers:
+
+| You have… | Use… | Notes |
+| --- | --- | --- |
+| A file on disk, for one interactive turn | `@path` or `/attach` in the TUI (see [File Attachments](../../features/tui/index.md#file-attachments)), `--attach` at startup (seeds an interactive TUI run just as readily as `--exec`), or `/attach` under `--exec` | Read from the local filesystem and inlined into the message once it clears a local admission check. That never crosses Docker Agent's own inbound HTTP boundary for a local (non-`--remote`) run or for the *first* message of a `--remote` run — but a locally resolved attachment added to a *later* message on a remote run does cross it; see the remote-runtime row below. The admission check itself, and how a rejection is reported, differ by entry point; see the read-time limits below. |
+| Instructions/context every agent turn should see | `add_prompt_files` in the agent config, or `--prompt-file` on the CLI (see [Prompt Files](../../configuration/agents/index.md#prompt-files)) | Re-read from disk **in full** on every turn and injected as instruction context; local, not an HTTP upload, and not subject to the attachment inlining checks above — memory and the model's context window are the practical ceilings. |
+| A one-off piece of text for a **local** headless run | stdin, without `--remote` (see [`--exec` Mode Basics](#--exec-mode-basics) above) | The piped text becomes the message directly; it never crosses Docker Agent's own inbound HTTP boundary and has no size cap of its own, though Docker Agent may still send it onward to a model/provider over HTTP. |
+| A one-off piece of text driving a **remote** runtime | stdin with `docker agent run --remote ... -` | The CLI serializes that stdin text into a native API run request sent to whichever Docker Agent server the `--remote` address points at — a `serve api` process or another run's [`--listen`](../../features/api-server/index.md#listen) control plane, never `serve chat` — so it's measured against that server's own limit: `serve api`'s configurable `--max-request-size`, or a `--listen` control plane's fixed, non-configurable 1 MiB cap. See the HTTP body limit below. That *initial* request carries only message text: conversion currently drops any attachment resolved locally (`@path`/`/attach`, `--attach`) for the first message before it's sent. A *later* message to the same remote run — sent while the agent is still busy, via the default steer behavior or an explicit follow-up (Alt+Enter) — does forward a locally resolved attachment as part of that native API request, so it counts toward the same limit and can 413 like any other oversized request. Client-side `--prompt-file` values are **not** forwarded to a remote runtime either way; prompt files configured on the agent itself (`add_prompt_files`) still resolve, but on the server's filesystem. |
+| A document collection you'll query repeatedly, or one too large to inline at all | The [`rag` toolset](../../tools/rag/index.md) | Indexed once in the background; each query retrieves only the relevant chunks into context, instead of the whole collection. |
+| An OpenAI-compatible client driving Docker Agent over HTTP | [Chat Server](../../features/chat-server/index.md) | Accepts OpenAI-style `text` and [`image_url`](../../features/chat-server/index.md#image-inputs) content parts. The whole request travels as a single HTTP body capped by that server's `--max-request-size`; a data URL's bytes count toward it, while a remote `http(s)://` image URL is passed to the provider rather than fetched by the chat server, and works only if that provider/model supports it. |
+| A native integration driving Docker Agent's own session/control protocol | [API Server](../../features/api-server/index.md) | Supports the documented session, run, and event-streaming flows over a single capped HTTP body; see the note below on the upload contract this does *not* provide. |
+| A supervisor process driving an already-running interactive session | An attached run's [`--listen`](../../features/api-server/index.md#listen) control plane | Exposes the same session/follow-up/event-streaming API as the API server, but with a fixed, non-configurable 1 MiB request-body cap and no `--auth-token` — there's no `--max-request-size` or `--auth-token` flag for this surface. Keep it on loopback, a unix socket, or behind an authenticating reverse proxy if it must be reachable from elsewhere. |
+
+Three independent ceilings apply, and hitting one says nothing about the others:
+
+1. **The HTTP body limit** — applies to any request reaching one of Docker Agent's three inbound HTTP surfaces: `docker agent serve api`, `docker agent serve chat`, or an interactive run's [`--listen`](../../features/api-server/index.md#listen) control plane. `docker agent run --remote ... -` builds a native run request from stdin and sends it to whichever of `serve api` or a `--listen` control plane the remote address points at — never `serve chat`, which speaks a different protocol. `serve api` and `serve chat` each enforce their own `--max-request-size` (1 MiB default, configurable) and return `413 Request Entity Too Large` above it; a `--listen` control plane enforces the same 1 MiB default but exposes no `--max-request-size` flag (or `--auth-token`) to change it — it's fixed, and reducing the request is the only remedy. See [Troubleshooting: HTTP 413](../../community/troubleshooting/index.md#http-413-request-body-too-large) for how to diagnose and resolve it. Local (non-`--remote`) stdin and prompt files never cross this boundary; a locally resolved `@path`/`/attach`/`--attach` attachment doesn't either for a remote run's initial message, but one added to a later steer or follow-up message on that same remote run does — see the remote-runtime row above.
+2. **Local read-time limits, which differ by path** — the TUI and non-TUI (CLI/`--exec`) message assembly don't share one text/binary rule. The TUI (both `/attach` and a typed `@path` reference) runs every file reference through one flat size ceiling *before* it looks at the file's type; non-TUI assembly — the CLI's `--attach` flag and `--exec`'s own `/attach` parsing — inlines text up to its own ceiling and hands supported binary files (images, PDFs) to a separate path with a higher cap, so a binary file that's fine for `--attach`/`--exec` can still be too big for the TUI's flatter, lower ceiling. Either way an oversized file is rejected rather than silently truncated or allowed to exhaust memory, but whether you're actually told about it depends on the surface: only the interactive TUI's `/attach` command shows a visible error notification (with a file-picker fallback), while a bare `@path` reference is only checked speculatively as you type — a rejection there is logged at debug level only, and the reference is left as plain text in your message with no on-screen notice. Outside the interactive TUI, neither the CLI's `--attach` flag nor `--exec`'s `/attach` (which reuses the same non-TUI assembly and rejection path as `--attach`, not the TUI's notification flow) prints anything about a rejected attachment in normal run output — the message just falls back to text-only, and the reason is visible only in the debug log when `--debug` is enabled. Prompt files (`add_prompt_files`/`--prompt-file`) have no equivalent guard — they're read in full on every turn regardless of size, so memory and the model's context window are what actually bound them.
+3. **Model/provider context and media limits** — even content that clears the first two layers still has to fit the model's token/context window, and binary attachments (images, PDF, audio, video) only work if the model declares support for that media type (see [Attachment Capability Overrides](../../configuration/models/index.md#attachment-capability-overrides)). Exceeding the context window is a separate failure from either limit above — see [Context Window Exceeded](../../community/troubleshooting/index.md#context-window-exceeded).
+
+> [!NOTE]
+> **No file-upload endpoint**
+>
+> None of Docker Agent's three inbound HTTP surfaces — the API server, the chat server, or an attached run's `--listen` control plane — exposes a multipart file-upload endpoint, and none of them fetches a remote URL on your behalf — the chat server's `image_url` support only ever passes a remote URL through to the provider (see the table above). Content reaches an agent either locally (`@path`/`/attach`, prompt files, `rag`) or embedded directly in the HTTP message body those servers already document; there is no separate attachment channel over any of them.
+
+## Structured Output for Machines
+
+Two independent things make an `--exec` run's output easy to parse: how the transcript is emitted, and what shape the model's own answer takes.
+
+**`--json`** switches the transcript itself from human-readable text to newline-delimited JSON: one JSON object per runtime event (messages, tool calls, tool results, errors, …), instead of formatted text interleaved with tool-call boxes. Pipe it into `jq` or any NDJSON-aware log processor:
+
+```bash
+$ docker agent run --exec agent.yaml --json "List the 5 largest files in this repo" | jq -c 'select(.type == "agent_choice")'
+```
+
+**`structured_output`** constrains the *model's own response* to a JSON schema you define on the agent, independent of `--json`. Use it when downstream code needs the model's answer in a predictable shape (a list of findings, a classification, …) rather than free-form prose. See [Structured Output](../../configuration/structured-output/index.md) for the full field reference — combine it with `--json` in `--exec` to get both a parseable transcript and a schema-validated final answer.
+
+## Reacting to Events
+
+`--on-event <type>=<cmd>` runs a shell command whenever an event of the given type fires, with the event's JSON payload piped to the command's stdin. Use `*=<cmd>` to match every event type. The flag is repeatable.
+
+> [!WARNING]
+> **`--on-event` does nothing under `--exec`**
+>
+> Event hooks are installed on the interactive App's event bus. A `docker agent run --exec` run returns before that wiring happens, so `--on-event` is silently a no-op there — no error, no hook ever runs. Use `--on-event` with a normal interactive run or `--lean` (which still installs hooks; it just skips the alternate screen). For a headless `--exec` run, get the same effect by parsing the `--json` NDJSON stream yourself and shelling out on the events you care about — for example `stream_stopped`, which fires when a turn ends normally.
+
+```bash
+# Post a Slack notification when the agent finishes a turn (interactive or --lean only)
+$ docker agent run agent.yaml --lean --on-event stream_stopped="./notify-slack.sh" "Fix the failing test"
+
+# Log every event to a file for later inspection
+$ docker agent run agent.yaml --lean --on-event "*=cat >> events.ndjson" "Fix the failing test"
+
+# Headless equivalent: capture the --json NDJSON stream, then react to it yourself
+$ docker agent run --exec agent.yaml --json "Fix the failing test" | tee events.ndjson
+$ jq -e 'select(.type == "stream_stopped")' events.ndjson >/dev/null && ./notify-slack.sh
+```
+
+Hooks run asynchronously and are never waited on: each is spawned detached from the run's own context, and the process exits (`os.Exit`) as soon as the run finishes without waiting for, or signaling, any hook subprocess still in flight. A hook's own failure is logged but never fails the run — and, independent of that, its fate at process exit is unspecified: it may keep running as an orphaned process, or it may be torn down by whatever supervises the job (a CI runner tearing down its container, a shell killing its process group, …), depending on your environment rather than on anything docker-agent guarantees. Don't rely on `--on-event` for anything that must demonstrably finish before the process exits; have the hook script itself detach (e.g. `nohup`/`disown`) and/or write its own completion marker if you need proof it ran.
+
+## Running Unattended in CI
+
+Interactively, the TUI prompts for confirmation before a tool call runs unless it's covered by an `allow` permission pattern. There's no one to answer that prompt in CI, so an unattended `--exec` run needs an explicit policy for what may run without asking — otherwise every tool call the model attempts is rejected outright (there's no stdin to prompt, so `--exec` without one just answers "no" on your behalf; see [`--json`'s auto-reject behavior](#structured-output-for-machines) above).
+
+Two different questions come up here, and it's worth keeping them separate:
+
+- **What is allowed to run without asking?** — the safety mode (`--safety strict|balanced|restricted|autonomous`, with `--yolo` as the legacy spelling of `autonomous`) and permission allow-lists answer this.
+- **What happens if the model runs something it shouldn't have?** — only `--sandbox` answers that one. The rest of this section explains why, and treats that distinction as the whole point.
+
+### `--sandbox`: the isolation boundary
+
+For an untrusted or autonomous agent — anything acting without a human watching approvals — **`--sandbox` is the isolation boundary to reach for**, not a cleverer allow-list. It runs the entire agent, shell calls included, inside a VM managed by [`sbx`](https://docs.docker.com/ai/sandboxes/): a misbehaving or successfully-prompt-injected agent can't touch anything outside the mounted working directory or reach other host/CI state, regardless of which command it runs. That VM isn't disposable or ephemeral — a sandbox matching the current workspace and mount set is retained and reused across subsequent runs rather than torn down when the session ends (see [How It Works](../../configuration/sandbox/index.md#how-it-works)). See [Sandbox Mode](../../configuration/sandbox/index.md) for the full flag reference, `sbx` requirement, network allowlist, and kit staging behavior.
+
+```bash
+$ docker agent run --sandbox --exec agent.yaml --json "Fix the failing test"
+```
+
+Because the blast radius is contained by the VM boundary, `--sandbox` also makes unattended operation reasonable in CI — and it defaults to exactly that: unless you already passed a `--yolo` or `--safety` flag of your own, `--sandbox` injects `--yolo` for the agent process it runs inside the VM, so the command above already runs unattended with no confirmation prompts. Passing `--yolo` explicitly (`--sandbox --yolo --exec ...`) is equivalent and can make the intent clearer in a script, but it's optional. To keep confirmation prompts even inside the sandbox, select a stricter mode (`--sandbox --safety strict`) or opt out of the legacy default with `--yolo=false` — `--sandbox` only fills in `--yolo` when neither safety flag was set.
+
+If your CI provider already runs each job in its own disposable VM or container — many hosted runners do — and nothing on the runner matters once the job ends, that may already give you an isolation boundary on its own. `--sandbox` still gives you the same guarantee independent of the CI provider, and starts to matter as soon as the agent runs on a persistent self-hosted runner, a long-lived container, or your own workstation.
+
+### Defense in depth, not a boundary: permissions and shell command matching
+
+Permission allow-lists (`permissions.allow` on the agent, or `settings.permissions.allow` globally — see [Permissions](../../configuration/permissions/index.md)) and the balanced safety mode's shell classifier (see [Safety modes](../../configuration/permissions/index.md#safety-modes)) narrow what runs without asking. Used well, they cut down how often you're prompted and catch obviously destructive calls before they run. They are **not** a security boundary:
+
+- Both work by matching the shell command **string** (or, for `permissions`, the tool's arguments). The classifier's safe-list refuses to vouch for any command carrying shell metacharacters (`;`, `&`, `|`, `<`, `>`, backticks, `$(`, newlines — spaced or not), so `ls && rm -rf ~`, `grep foo|rm -rf /`, and `grep x > /etc/passwd` all fall through to a confirmation instead of inheriting a safe verdict. But string matching still can't reason about what a command actually *does* — see the next point.
+- Command-string and argument matching in general can't reason about what a command actually does; a dynamically built string, an unusual quoting form, or a wrapper script can slip past any fixed set of patterns.
+
+For unattended runs, the `restricted` safety mode packages this stance as a fail-closed default: classifier-safe calls run, every other unmatched call is **denied outright** instead of falling through to a confirmation prompt nobody will answer. Pair it with an allow-list scoped to what the job actually needs — explicit `allow` rules still win over the mode, so the job's known-good commands run even when the classifier can't vouch for them:
+
+```yaml
+# agent.yaml — the allow-list overrides restricted's deny for these calls
+permissions:
+  allow:
+    - "shell:cmd=go test*"
+    - "shell:cmd=go build*"
+```
+
+```bash
+# Safe and allow-listed calls run; every other call is denied without prompting
+$ docker agent run --exec --safety restricted agent.yaml --json "Fix the failing test"
+```
+
+Like the allow-list itself, `restricted` is defense in depth, not a security boundary: it narrows what runs unattended, but only `--sandbox` contains what a misbehaving agent can do with the calls that are allowed.
+
+Treat permissions and the balanced/restricted modes as a way to reduce prompt fatigue and catch the obvious cases, paired with least-privilege CI credentials — never as the reason a CI job is safe to run unattended. For that, use `--sandbox`.
+
+> [!WARNING]
+> **`--yolo` without `--sandbox` runs untrusted, unattended code with no boundary**
+>
+> A CI job is exactly the environment where a runaway or misled agent does the most damage before anyone notices — no one is at the keyboard to catch a bad `shell` call before it runs, and, per above, a permission allow-list or the shell classifier can't be trusted to catch everything either. If you can't add `--sandbox`, prefer `--safety restricted` with a permission allow-list scoped to what the job actually needs over blanket `--yolo`, and budget for the credentials and blast radius of the agent's toolsets as if the job itself were compromised — see [`examples/permissions.yaml`](https://github.com/docker/docker-agent/blob/main/examples/permissions.yaml) for a worked allow/deny list.
+
+> [!NOTE]
+> **A worktree is not a security boundary either**
+>
+> [`--worktree`](../../features/cli/index.md#docker-agent-run) isolates *which branch and checkout* the agent modifies — it gives the agent its own working directory and branch so your primary checkout stays untouched — but the shell toolset still runs as a native process on the host, and the worktree shares the repository's underlying object store with the rest of your checkouts. It's checkout isolation, not a security boundary. Only `--sandbox` provides that.
+
+## Providing Secrets in CI
+
+Never put provider API keys or MCP tokens in the agent config file. Inject them as environment variables from your CI provider's secret store, or via `--env-from-file` with a file materialized at job start. See [Managing Secrets](../secrets/index.md) for every supported method, including Docker Compose secrets and 1Password references — both of which map cleanly onto CI secret stores.
+
+## Disabling Telemetry
+
+Docker Agent's anonymous usage telemetry is enabled by default. In CI you may want it off:
+
+```bash
+$ TELEMETRY_ENABLED=false docker agent run --exec agent.yaml "..."
+```
+
+See [Telemetry](../../community/telemetry/index.md) for exactly what is (and isn't) collected.
+
+## Example: GitHub Actions
+
+A bare OCI registry reference (`myorg/coder`) has no local config you control, so a security-sensitive CI job should check in a small agent config instead. This example runs a checked-in review agent non-interactively against the repository being built:
+
+```yaml
+# .github/agents/review-agent.yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Reviews the changes in a pull request for bugs and security issues
+    instruction: Review the changes in this PR for bugs and security issues.
+    toolsets:
+      - type: shell
+```
+
+```yaml
+# .github/workflows/agent-review.yml
+name: Agent code review
+on:
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  review:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          persist-credentials: false
+
+      - name: Install docker-agent
+        run: |
+          curl -L "https://github.com/docker/docker-agent/releases/latest/download/docker-agent-linux-amd64" -o docker-agent
+          chmod +x docker-agent
+          sudo mv docker-agent /usr/local/bin/
+
+      - name: Run the review agent
+        env:
+          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+          TELEMETRY_ENABLED: "false"
+        run: |
+          docker-agent run --exec --yolo .github/agents/review-agent.yaml --json \
+            "Review the changes in this PR for bugs and security issues" \
+            | tee agent-events.ndjson
+
+      - name: Upload transcript
+        if: always()
+        uses: actions/upload-artifact@v4
+        with:
+          name: agent-events
+          path: agent-events.ndjson
+```
+
+This job auto-approves every shell call the review agent makes (`--yolo`) rather than trying to allow-list every `git`/`grep`/`cat` invocation a code review might need — the read surface for "review this diff" is open-ended, and a fixed pattern list is exactly the kind of shell-matching boundary the [previous section](#defense-in-depth-not-a-boundary-permissions-and-shell-command-matching) says not to rely on. If your CI environment has `sbx` installed and configured (GitHub-hosted `ubuntu-latest` does not ship it out of the box), add `--sandbox` and get a real isolation boundary around that `--yolo`:
+
+```bash
+$ docker-agent run --sandbox --exec --yolo .github/agents/review-agent.yaml --json "..."
+```
+
+Without `--sandbox`, this workflow's safety instead rests on least-privilege secrets (only `ANTHROPIC_API_KEY` is injected — no repo-write token), the top-level `permissions: contents: read` block and `persist-credentials: false` on the checkout step (which together mean the job never holds a write-capable `GITHUB_TOKEN` and never persists one to disk for `git` to pick up), and the job running on a GitHub-hosted, ephemeral runner that's discarded after the job.
+
+This example omits the GitHub MCP toolset (`docker:github-official`) shown in earlier revisions of this guide: that server requires a `GITHUB_PERSONAL_ACCESS_TOKEN` this workflow doesn't provide, and — because the toolset above has no `name:` field — its tools would be exposed under their raw MCP names (`get_file_contents`, `search_code`, …) rather than a `github_*`-style qualified name, so permission patterns written against that prefix wouldn't match anything anyway. If your review agent needs GitHub API access, add the toolset back with an explicit `name: github`, wire `GITHUB_PERSONAL_ACCESS_TOKEN` through `env:` from a repository secret, and write any `permissions` patterns against the tool names it actually exposes (`github_get_*` only works once the toolset carries that `name:`).
+
+Swap the model, toolsets, and provider secret for your own — the shape (checkout, install the binary, run `--exec` with `--json` against a checked-in config, upload the transcript) generalizes to any CI provider that can run a shell step.
diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/secrets/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/secrets/index.md
new file mode 100644
index 000000000000..26fe93547132
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/guides/secrets/index.md
@@ -0,0 +1,247 @@
+---
+title: "Managing Secrets"
+description: "How to securely provide API keys and credentials to Docker Agent using environment variables, env files, Docker Compose secrets, and 1Password references."
+keywords: docker agent, ai agents, guides, managing secrets
+weight: 30
+canonical: https://docs.docker.com/ai/docker-agent/guides/secrets/
+---
+
+_How to securely provide API keys and credentials to Docker Agent._
+
+## Overview
+
+Docker Agent needs API keys to talk to model providers (OpenAI, Anthropic, etc.) and MCP tool servers (GitHub, Slack, etc.). These keys are **never stored in config files**. Instead, Docker Agent resolves them at runtime through a chain of secret providers, checked in order (see `pkg/environment/default.go`):
+
+| Priority | Provider | Description |
+| --- | --- | --- |
+| 1 | [Environment variables](#environment-variables) | `export OPENAI_API_KEY=sk-...` |
+| 2 | [Docker Compose secrets](#docker-compose-secrets) | Files in `/run/secrets/` |
+| 3 | [Docker Agent env file](#docker-agent-env-file) | `~/.config/cagent/.env`, written by `docker agent setup` |
+| 4 | [Credential helper](#credential-helper) | Custom command declared in `~/.config/cagent/config.yaml` under `credential_helper:` |
+| 5 | [Docker Desktop](#docker-desktop) | Secrets stored by the Docker Desktop backend (no setup on a Desktop install) |
+
+The first provider that has a value wins. You can mix and match — for example, use environment variables for one key and the Docker Agent env file for another.
+
+> [!NOTE]
+> Older Docker Agent versions could also read secrets from the macOS Keychain and the `pass` password manager. These sources are no longer consulted: migrate any keys stored there to one of the sources above, e.g. by re-running `docker agent setup`.
+
+Whatever provider returns the value, if that value looks like a [1Password secret reference](#1password-references) (it starts with `op://`), Docker Agent resolves it through the `op` CLI before handing it to a model provider or tool.
+
+When Docker Agent runs an agent with `--sandbox` and a Docker AI gateway is configured, the sandbox proxy authenticates gateway requests itself: it injects your Docker login token into HTTPS requests to the gateway host (docker.com domains only). The token never enters the sandbox — inside it, `DOCKER_TOKEN` is a proxy-managed placeholder.
+
+## Environment Variables
+
+The simplest approach. Set variables in your shell before running Docker Agent:
+
+```bash
+export OPENAI_API_KEY=sk-...
+export ANTHROPIC_API_KEY=sk-ant-...
+docker agent run agent.yaml
+```
+
+Common variables:
+
+| Variable | Provider |
+| --- | --- |
+| `OPENAI_API_KEY` | OpenAI |
+| `ANTHROPIC_API_KEY` | Anthropic |
+| `GOOGLE_API_KEY` | Google Gemini |
+| `MISTRAL_API_KEY` | Mistral |
+| `OPENROUTER_API_KEY` | OpenRouter |
+| `XAI_API_KEY` | xAI |
+| `NEBIUS_API_KEY` | Nebius |
+
+MCP tools may require additional variables. For example, the GitHub MCP server needs `GITHUB_PERSONAL_ACCESS_TOKEN`. These are passed to tools via the `env` field in your config:
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    env:
+      GITHUB_PERSONAL_ACCESS_TOKEN: $GITHUB_PERSONAL_ACCESS_TOKEN
+```
+
+## Env Files
+
+For convenience, you can store secrets in a `.env` file and pass it to Docker Agent with `--env-from-file`:
+
+```bash
+# .env
+OPENAI_API_KEY=sk-...
+ANTHROPIC_API_KEY=sk-ant-...
+GITHUB_PERSONAL_ACCESS_TOKEN=ghp_...
+```
+
+```bash
+docker agent run agent.yaml --env-from-file .env
+```
+
+The file format supports:
+
+- `KEY=VALUE` pairs, one per line
+- Comments starting with `#`
+- Quoted values: `KEY="value with spaces"`
+- Blank lines are ignored
+
+> [!IMPORTANT]
+> Add `.env` to your `.gitignore` to avoid committing secrets to version control.
+
+## Docker Agent env file
+
+A `.env` file (same format as above) at `~/.config/cagent/.env` is read automatically on every run — no `--env-from-file` flag needed. It is where [`docker agent setup`](../../features/cli/index.md#docker-agent-setup) stores API keys when you choose the env-file location, and you can edit it by hand:
+
+```bash
+# ~/.config/cagent/.env
+OPENAI_API_KEY=sk-...
+```
+
+The file is created with owner-only permissions (`0600`), but the values are stored in plain text.
+
+## Docker Compose Secrets
+
+When running Docker Agent in a container with Docker Compose, you can use [Compose secrets](https://docs.docker.com/compose/how-tos/use-secrets/) to inject credentials securely. Compose mounts secrets as files under `/run/secrets/`, and Docker Agent reads from this location automatically.
+
+### From a file
+
+Store each secret in its own file, then reference it in `compose.yaml`:
+
+```bash
+echo -n "sk-ant-your-key-here" > .anthropic_api_key
+```
+
+```yaml
+# compose.yaml
+services:
+  agent:
+    image: docker/docker-agent
+    command: run --exec /app/agent.yaml "Hello!"
+    secrets:
+      - ANTHROPIC_API_KEY
+    volumes:
+      - ./agent.yaml:/app/agent.yaml:ro
+
+secrets:
+  ANTHROPIC_API_KEY:
+    file: ./.anthropic_api_key
+```
+
+Docker Compose mounts the file as `/run/secrets/ANTHROPIC_API_KEY`. Docker Agent picks it up with no extra configuration.
+
+### From a host environment variable
+
+In CI/CD pipelines, secrets are often injected as environment variables. Compose can forward these to `/run/secrets/`:
+
+```yaml
+secrets:
+  ANTHROPIC_API_KEY:
+    environment: "ANTHROPIC_API_KEY"
+```
+
+### Multiple secrets
+
+```yaml
+services:
+  agent:
+    image: docker/docker-agent
+    command: run --exec /app/agent.yaml "Summarize my GitHub issues"
+    secrets:
+      - ANTHROPIC_API_KEY
+      - GITHUB_PERSONAL_ACCESS_TOKEN
+    volumes:
+      - ./agent.yaml:/app/agent.yaml:ro
+
+secrets:
+  ANTHROPIC_API_KEY:
+    file: ./.anthropic_api_key
+  GITHUB_PERSONAL_ACCESS_TOKEN:
+    file: ./.github_token
+```
+
+### Why use Compose secrets over environment variables?
+
+| Aspect | Environment Variables | Compose Secrets |
+| --- | --- | --- |
+| Storage | In memory, visible via `docker inspect` | Mounted as tmpfs files under `/run/secrets/` |
+| Visibility | Shown in process list and inspect output | Not exposed in `docker inspect` |
+| Best for | Development | Production and CI/CD |
+
+## Credential Helper
+
+Docker Agent can shell out to an external credential helper you define in your user config. This is useful when your organisation already has a secrets daemon you want to reuse (HashiCorp Vault, 1Password CLI, `bitwarden-cli`, etc.).
+
+Declare the helper in `~/.config/cagent/config.yaml`:
+
+```yaml
+# ~/.config/cagent/config.yaml
+credential_helper:
+  command: op
+  args: ["read", "op://Personal/docker-agent"]
+```
+
+The command is invoked with the variable name appended as the final argument, and must print the secret value to stdout.
+
+## Docker Desktop
+
+On machines where Docker Desktop is installed, Docker Agent queries Docker Desktop's backend for secrets stored against your signed-in Docker account. This is transparent — no extra configuration — and it is how signed-in Docker users get provider API keys without setting any environment variables.
+
+## Docker Authentication
+
+Routing model traffic through the [Docker models gateway](../../configuration/models/index.md) needs a Docker token. Docker Desktop hands out one that is valid for 15 minutes and cannot be renewed by Docker Agent, so when Desktop has nothing usable to offer — it is signed out, not running, or its own refresh is stuck — Docker Agent exchanges the long-lived access token that `docker login` left in your credential store for a fresh Docker token, the same exchange `docker login` itself performs. Signing in with `docker login` is therefore enough; Docker Desktop is not required.
+
+Only Docker access tokens are exchanged — the `dckr_…` secrets `docker login` stores — never an account password, and the exchange goes to Docker Hub over HTTPS. The resulting bearer token is cached in a private file under Docker Agent's cache directory so sibling processes reuse it instead of minting their own, and it stops being used within seconds of a `docker logout` or an account switch. Run `docker agent debug auth` to see which token is in use and where it came from.
+
+Set `DOCKER_AGENT_NO_TOKEN_EXCHANGE=1` to opt out: Docker Agent then relies on Docker Desktop alone.
+
+## 1Password References
+
+Any secret value resolved through the chain above can be a **1Password secret reference** instead of the literal secret. If the value starts with `op://`, Docker Agent resolves it by invoking the [1Password CLI](https://developer.1password.com/docs/cli/) (`op read <reference>`) and uses the result.
+
+This works with every provider — most commonly an environment variable or env file:
+
+```bash
+export OPENAI_API_KEY="op://Personal/OpenAI/api-key"
+docker agent run agent.yaml
+```
+
+References follow the `op://<vault>/<item>/<field>` format. Make sure the `op` CLI is installed and you are signed in (`op signin`) so that non-interactive reads succeed.
+
+> [!WARNING]
+> **Behaviour when resolution fails**
+>
+> If the value starts with `op://` but the `op` CLI is not installed, or the reference cannot be read (not signed in, wrong path, locked vault), Docker Agent logs a warning and uses an **empty value** — it never forwards the raw `op://` reference to a model provider or tool. Resolved references (and deterministic failures) are cached for the lifetime of the run; transient failures such as a cancelled lookup are not cached, so a later attempt can retry.
+
+## Choosing a Method
+
+| Method | Best for | Setup effort |
+| --- | --- | --- |
+| Environment variables | Quick local development, scripts | Low |
+| Env files | Team projects, multiple keys | Low |
+| Docker Agent env file | Keys used across all projects, written by `docker agent setup` | Low |
+| Docker Compose secrets | Containerized deployments, CI/CD | Medium |
+| Credential helper | Reusing an existing secrets daemon (Vault, 1Password CLI, ...) | Medium |
+| 1Password references (`op://`) | Teams already using 1Password | Low |
+
+You can combine methods. For example, store long-lived provider keys in the Docker Agent env file and pass project-specific MCP tokens via env files.
+
+## Preventing Secret Leaks
+
+Provider keys live in the secret store and are passed to Docker Agent through the chain above — the agent itself never receives them as input. But the **content of a conversation** can still leak credentials: a user pasting a token, a tool returning a config file with embedded keys, a transcript dumped into a prompt.
+
+For that defense-in-depth case, set `redact_secrets: true` on an agent. It scrubs detected secrets out of:
+
+- the arguments of every outgoing tool call (before the tool sees them),
+- every outgoing chat message (before the model provider sees them), and
+- every tool's output (before it reaches event consumers, the persisted session file, the `post_tool_use` hook input, or the next LLM call).
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5
+    description: A helpful assistant
+    instruction: You are a helpful assistant.
+    redact_secrets: true
+    toolsets:
+      - type: shell
+```
+
+The ruleset covers GitHub PATs, AWS / GCP / Azure credentials, Stripe / Slack / GitLab / Hugging Face tokens, JWTs, PEM-encoded private keys, Docker Hub PATs, and many others. Each detected span is replaced with the literal `[REDACTED]`. See the [Redacting Secrets](../../configuration/agents/index.md#redacting-secrets) section in the agent configuration reference for the full picture and important caveats about false negatives.
diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/thinking/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/thinking/index.md
new file mode 100644
index 000000000000..fbdef06dee3b
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/guides/thinking/index.md
@@ -0,0 +1,363 @@
+---
+title: "Thinking / Reasoning"
+description: "Control how much a model reasons before responding. Works across OpenAI, Anthropic, Google Gemini, AWS Bedrock, and Docker Model Runner."
+keywords: docker agent, ai agents, guides, thinking / reasoning
+weight: 20
+canonical: https://docs.docker.com/ai/docker-agent/guides/thinking/
+---
+
+_Control how much a model reasons before responding. Works across OpenAI, Anthropic, Google Gemini, AWS Bedrock, and Docker Model Runner._
+
+## What Is Thinking?
+
+Several modern models support an extended reasoning phase that happens before they produce visible output. During this phase the model plans, evaluates options, and works through the problem — internally, not shown in the response by default. This typically improves accuracy on complex tasks like coding, math, and multi-step planning, at the cost of higher token usage and latency.
+
+Docker Agent exposes this through a single `thinking_budget` field on any named model. The value format differs slightly by provider, but the semantics are the same: higher effort means more thorough reasoning.
+
+> [!NOTE]
+> **Think tool vs. thinking budget**
+>
+> The [think tool](../../tools/think/index.md) is a scratchpad for models that lack native reasoning. If your model supports `thinking_budget`, you do not need the think tool.
+
+## Quick Reference
+
+| Provider            | Format     | Values                                                                                  | Default            |
+| ------------------- | ---------- | --------------------------------------------------------------------------------------- | ------------------ |
+| OpenAI              | string     | `none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`; `xhigh` on gpt-5.2+, `none`/`max` on gpt-5.6+ only, `minimal` dropped on gpt-5.6+ | `medium` (API default) |
+| Anthropic           | int or str | 1024–32768 tokens, or `minimal`–`max`, `adaptive`, `adaptive/<effort>`, `none`          | off                |
+| Gemini 2.5          | int        | `0` (off), `-1` (dynamic), or token count (max 24576 / 32768)                           | `-1` (dynamic)     |
+| Gemini 3            | string     | `minimal`, `low`, `medium`, `high`                                                      | API default (model-dependent) |
+| AWS Bedrock         | int or str | 1024–32768 tokens (`minimal`–`max` mapped to tokens); `adaptive`, `adaptive/<effort>` for Opus 4.6+ (rejected by older Claude models) | off                |
+| Docker Model Runner | int or str | token count, `minimal`–`max` (mapped to tokens), `adaptive` (unlimited), `none`         | engine default     |
+
+String values are case-insensitive. The full set of accepted strings is `none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`, `adaptive`, and `adaptive/<effort>` — but each provider only honors the subset listed above. Unsupported values either fail at request time (OpenAI) or are mapped/ignored as described per provider below.
+
+> `thinking_budget` is only applied by the providers listed above. Other OpenAI-compatible providers (xAI, Mistral, Ollama, …) currently ignore it — see [xAI and Mistral](#xai-grok-and-mistral).
+
+## OpenAI
+
+OpenAI reasoning models (o-series, gpt-5, gpt-5-mini, gpt-5.6 family) use a string effort level that maps to their `reasoning_effort` API parameter. The `xhigh` level requires gpt-5.2+; `none` and `max` require gpt-5.6+ (Sol/Terra/Luna); `minimal` is dropped on gpt-5.6+.
+
+```yaml
+models:
+  gpt-thinker:
+    provider: openai
+    model: gpt-5.6
+    thinking_budget: high   # none | minimal | low | medium | high | xhigh | max
+```
+
+**Effort levels:**
+
+| Level     | Description                                              |
+| --------- | -------------------------------------------------------- |
+| `none`    | No reasoning. Sent as-is on gpt-5.6+ (a real API value); on older models it just disables the local `thinking_budget` (the API's own default still applies). |
+| `minimal` | Fastest; lightest reasoning pass. Not accepted on gpt-5.6+ (dropped from the API). |
+| `low`     | Quick reasoning for straightforward tasks.               |
+| `medium`  | Balanced default.                                        |
+| `high`    | More thorough; recommended for complex tasks.            |
+| `xhigh`   | Near-maximum effort; slower but most accurate. Requires gpt-5.2+. |
+| `max`     | Maximum effort. Requires gpt-5.6+.                       |
+
+Token counts, `adaptive`, and `adaptive/<effort>` are rejected with a configuration error at request time. `xhigh` is only supported by gpt-5.2 and later minor versions (e.g. gpt-5.2, gpt-5.4-mini); `none` and `max` are only supported by gpt-5.6 and later (Sol/Terra/Luna); `minimal` is not accepted on gpt-5.6+. Older models (o1, o3-mini) only accept `low`/`medium`/`high` — sending an unsupported level returns an API error.
+
+> [!WARNING]
+> **Tokens and max_tokens**
+>
+> Older OpenAI reasoning models always reason internally — even with `thinking_budget: none` there are hidden reasoning tokens that count against `max_tokens`. On gpt-5.6+ (Sol/Terra/Luna), `none` is a real API value that genuinely disables reasoning. Docker Agent automatically raises the output-token floor for its internal low-effort calls (e.g. title generation) so hidden reasoning cannot starve visible text output.
+
+## Anthropic
+
+Anthropic Claude supports two thinking modes: a **token budget** (older models) and **adaptive / effort-based** thinking (newer models).
+
+### Token budget (Claude 4 and earlier)
+
+Set an explicit number of thinking tokens (1024–32768). This must be less than `max_tokens`:
+
+```yaml
+models:
+  claude-thinker:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    thinking_budget: 16384   # tokens reserved for internal reasoning
+```
+
+Docker Agent auto-adjusts `max_tokens` when you set a thinking budget but leave `max_tokens` at its default. If you set `max_tokens` explicitly, it must be greater than `thinking_budget`.
+
+### Adaptive thinking (Opus 4.6+ and Sonnet 4.6)
+
+Newer Claude models support adaptive thinking, where the model decides how much to think. **Claude Opus 4.6, 4.7, 4.8, and Sonnet 4.6 only support adaptive thinking** — they reject token-based budgets. Use `adaptive`, `adaptive/<effort>`, or a bare effort level — on Anthropic, a bare effort level like `high` is shorthand for adaptive thinking at that effort:
+
+```yaml
+models:
+  claude-adaptive:
+    provider: anthropic
+    model: claude-opus-4-6
+    thinking_budget: adaptive          # model decides effort (defaults to high)
+
+  claude-adaptive-low:
+    provider: anthropic
+    model: claude-opus-4-6
+    thinking_budget: low               # same as adaptive/low
+
+  claude-adaptive-max:
+    provider: anthropic
+    model: claude-opus-4-6
+    thinking_budget: adaptive/max      # adaptive/low | adaptive/medium | adaptive/high | adaptive/xhigh | adaptive/max
+```
+
+**Adaptive effort levels and per-model support:**
+
+| Level     | Opus 4.5 | Sonnet 4.5 / Haiku | Sonnet 4.6 | Opus 4.6 | Opus 4.7 / 4.8 | Fable 5 | Mythos 5 | Mythos preview |
+| --------- | :------: | :----------------: | :--------: | :------: | :------------: | :-----: | :------: | :------------: |
+| `low`     | ✓        | ✓                  | ✓          | ✓        | ✓              | ✓       | ✓        | ✓              |
+| `medium`  | ✓        | ✓                  | ✓          | ✓        | ✓              | ✓       | ✓        | ✓              |
+| `high`    | ✓        | ✓                  | ✓          | ✓        | ✓              | ✓       | ✓        | ✓              |
+| `xhigh`   | —        | —                  | —          | —        | ✓              | ✓       | ✓        | —              |
+| `max`     | —        | —                  | ✓          | ✓        | ✓              | ✓       | ✓        | ✓              |
+
+`minimal` is treated as `low` (bare form only). `high` is the default when `adaptive` is used without an effort level.
+
+> [!WARNING]
+> **Effort strings require adaptive-capable models**
+>
+> Every string effort value on Anthropic is sent as adaptive thinking (`output_config.effort`), which only newer Claude models (Opus 4.6+, Sonnet 4.6) accept. For older models like Sonnet 4.5, use an integer token budget instead. Conversely, models that _only_ support adaptive thinking (Opus 4.6, 4.7, 4.8, Sonnet 4.6) automatically have token budgets coerced to `adaptive` (a warning is logged).
+
+### Disabling thinking
+
+```yaml
+thinking_budget: none   # or 0
+```
+
+### Interleaved thinking
+
+Interleaved thinking lets the model reason between tool calls — useful for complex agentic tasks. Docker Agent auto-enables it whenever a thinking budget is configured on a Claude model, so you only need to set it explicitly to turn it off:
+
+```yaml
+models:
+  claude-interleaved:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    thinking_budget: 16384
+    # interleaved_thinking is auto-enabled; disable it explicitly if needed:
+    provider_opts:
+      interleaved_thinking: false
+```
+
+> [!NOTE]
+> **Temperature and top_p**
+>
+> When extended thinking is enabled, Anthropic requires `temperature=1.0`. Docker Agent automatically suppresses any `temperature` or `top_p` settings you have configured — they are silently ignored while thinking is active.
+
+### Thinking display
+
+Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default at the API level. To keep reasoning visible, Docker Agent requests `summarized` thinking whenever adaptive/effort-based thinking is used without an explicit `thinking_display`. Use `thinking_display` in `provider_opts` to override:
+
+```yaml
+models:
+  opus-47:
+    provider: anthropic
+    model: claude-opus-4-7
+    thinking_budget: adaptive
+    provider_opts:
+      thinking_display: omitted   # summarized | omitted (display: pre-4.6 models only)
+```
+
+| Value        | Behavior                                                                              |
+| ------------ | ------------------------------------------------------------------------------------- |
+| `summarized` | Thinking blocks returned with a text summary (Docker Agent default for adaptive thinking). |
+| `display`    | Full thinking blocks returned for display. Pre-4.6 token-thinking models only — rejected by Opus/Sonnet 4.6+, Sonnet 5, and Fable 5 (Docker Agent fails fast with a configuration error). |
+| `omitted`    | Thinking blocks hidden — only the signature is returned.                               |
+
+Full thinking tokens are billed regardless of `thinking_display`.
+
+### Task budget (Anthropic)
+
+`task_budget` caps total tokens across an entire multi-step agentic task (thinking + tool calls + output combined):
+
+```yaml
+models:
+  opus-bounded:
+    provider: anthropic
+    model: claude-opus-4-7
+    thinking_budget: adaptive
+    task_budget: 128000   # total token ceiling for the whole task
+```
+
+See the [Anthropic provider page](../../providers/anthropic/index.md#task-budget) for details.
+
+## Google Gemini
+
+Gemini 2.5 and Gemini 3 use different formats.
+
+### Gemini 2.5 (token budget)
+
+```yaml
+models:
+  gemini-off:
+    provider: google
+    model: gemini-2.5-flash
+    thinking_budget: 0      # disable thinking
+
+  gemini-dynamic:
+    provider: google
+    model: gemini-2.5-flash
+    thinking_budget: -1     # let the model decide (default)
+
+  gemini-fixed:
+    provider: google
+    model: gemini-2.5-flash
+    thinking_budget: 8192   # fixed token budget (max 24576 for Flash, 32768 for Pro)
+```
+
+### Gemini 3 (level-based)
+
+```yaml
+models:
+  gemini3-flash:
+    provider: google
+    model: gemini-3-flash
+    thinking_budget: medium   # minimal | low | medium | high
+
+  gemini3-pro:
+    provider: google
+    model: gemini-3-pro
+    thinking_budget: high     # low | high (Pro supports fewer levels)
+```
+
+## AWS Bedrock (Claude)
+
+Bedrock Claude uses a token budget like Anthropic. String effort levels (`minimal`–`max`) are mapped automatically:
+
+| Effort level | Token budget |
+| ------------ | ------------ |
+| `minimal`    | 1,024        |
+| `low`        | 2,048        |
+| `medium`     | 8,192        |
+| `high`       | 16,384       |
+| `xhigh`/`max`| 32,768       |
+
+```yaml
+models:
+  bedrock-claude-thinker:
+    provider: amazon-bedrock
+    model: global.anthropic.claude-sonnet-4-5-20250929-v1:0
+    thinking_budget: 8192   # or use an effort level: medium
+    provider_opts:
+      region: us-east-1
+
+  bedrock-claude-interleaved:
+    provider: amazon-bedrock
+    model: global.anthropic.claude-sonnet-4-5-20250929-v1:0
+    thinking_budget: high
+    provider_opts:
+      region: us-east-1
+      # interleaved_thinking is auto-enabled when thinking_budget is set
+```
+
+**Claude Opus 4.6+ on Bedrock requires adaptive thinking** — these models reject `thinking.type=enabled` (token budgets). Configure them with `adaptive` or `adaptive/<effort>`; Docker Agent auto-coerces token budgets and effort levels on these models with a warning:
+
+```yaml
+models:
+  bedrock-opus-adaptive:
+    provider: amazon-bedrock
+    model: global.anthropic.claude-opus-4-8
+    thinking_budget: adaptive/high
+    provider_opts:
+      region: us-east-1
+```
+
+> [!WARNING]
+> **Bedrock thinking requirements**
+>
+> Bedrock Claude requires token-based `thinking_budget` values to be ≥ 1024 and less than `max_tokens`. Docker Agent logs a warning and ignores the budget if either condition is violated. Interleaved thinking requires the `interleaved-thinking-2025-05-14` beta header, which Docker Agent adds automatically; it is auto-enabled whenever a token thinking budget is set on a Bedrock-hosted Claude model (adaptive thinking interleaves on its own).
+
+## Docker Model Runner (local models)
+
+For local models, `thinking_budget` is forwarded to the inference engine. Both token counts and effort strings work; effort strings map to the same token scale as Bedrock (`minimal`=1024 … `xhigh`/`max`=32768), and `adaptive` means unlimited:
+
+```yaml
+models:
+  local:
+    provider: dmr
+    model: ai/qwen3
+    thinking_budget: medium   # llama.cpp: reasoning-budget=8192; vLLM: thinking_token_budget=8192
+```
+
+- **llama.cpp**: sent as `reasoning-budget` at model-configure time.
+- **vLLM**: sent as `thinking_token_budget` on each request.
+- **MLX / SGLang**: no reasoning-budget knob; the value is silently ignored.
+
+See the [Docker Model Runner provider page](../../providers/dmr/index.md) for details.
+
+## xAI (Grok) and Mistral
+
+xAI and Mistral run through Docker Agent's OpenAI-compatible client, but the `reasoning_effort` parameter is only sent for OpenAI reasoning model names (o-series, gpt-5). **Setting `thinking_budget` on Grok or Mistral models currently has no effect** — the value is accepted by config validation but never sent to the API.
+
+Grok and Mistral reasoning models (e.g. `grok-3-mini`, `magistral`) manage reasoning on their own; for non-reasoning models, consider the [think tool](../../tools/think/index.md) instead.
+
+## Disabling Thinking
+
+Use `none` or `0` to disable thinking on any provider:
+
+```yaml
+models:
+  fast-model:
+    provider: openai
+    model: gpt-5-mini
+    thinking_budget: none
+
+  gemini-no-think:
+    provider: google
+    model: gemini-2.5-flash
+    thinking_budget: 0
+```
+
+`none` and `0` clear Docker Agent's thinking configuration — no thinking parameter is sent. Models that always reason (OpenAI o-series, gpt-5 through gpt-5.5, Gemini 3) then fall back to the API's default behavior and still reason internally; gpt-5.6+ (Sol/Terra/Luna) sends `none` as a real API value that genuinely disables reasoning. Models with optional thinking (Gemini 2.5, Claude, local models) are also fully disabled.
+
+## Choosing an Effort Level
+
+| Task complexity                  | Recommended level       |
+| -------------------------------- | ----------------------- |
+| Simple factual Q&A               | `none` / `minimal`      |
+| General-purpose chat             | `low` / `medium`        |
+| Coding, debugging, analysis      | `medium` / `high`       |
+| Complex reasoning, planning      | `high` / `xhigh`        |
+| Research, difficult math/logic   | `xhigh` / `max`         |
+| Long agentic tasks (Anthropic)   | `adaptive`              |
+
+## Changing Thinking Level at Runtime
+
+While running in the TUI, press **Shift+Tab** to cycle the thinking effort level for the current model without editing your YAML config, or type `/effort <level>` to jump straight to a specific level (e.g. `/effort high`). Running `/effort` without an argument opens a picker listing the levels the current model supports:
+
+- The level steps through the model's supported range (model-specific), wrapping around — for example `none → minimal → low → medium → high → none` on OpenAI gpt-5/o-series, `none → minimal → low → medium → high → xhigh → none` on gpt-5.2+, `none → low → medium → high → xhigh → max → none` on gpt-5.6+ (no `minimal`), `none → low → medium → high → max → none` on Anthropic Opus 4.6 and Sonnet 4.6, and `none → low → medium → high → xhigh → max → none` on Anthropic Opus 4.7+, Fable 5, and Mythos 5. For older Anthropic models (e.g. Sonnet 4.5) that only accept token budgets, effort-string cycling has no effect — use an integer `thinking_budget` in your YAML config instead.
+- The current level is shown in the sidebar next to the model name (e.g. `openai/gpt-5 • high`).
+- This applies as a session override — it is **not** saved to the config file. The next session starts from the level defined in your YAML.
+- For models that don't support reasoning, and for remote runtimes, Shift+Tab is a no-op and an informational message is displayed.
+- `/effort` only accepts levels the current model supports; requesting an unsupported level shows the model's supported list. Like Shift+Tab, it is unavailable for non-reasoning models and remote runtimes.
+- Press <kbd>Tab</kbd> after `/effort` and a space to complete a level from the current model's supported range; it lists the same levels the picker shows (and, like the picker, offers no candidates for non-reasoning models or remote runtimes).
+
+## Sharing Thinking Config Across Models
+
+Define a provider with a default `thinking_budget` and all models that reference it inherit it:
+
+```yaml
+providers:
+  deep-anthropic:
+    provider: anthropic
+    thinking_budget: adaptive/high
+    max_tokens: 32768
+
+models:
+  claude-smart:
+    provider: deep-anthropic
+    model: claude-opus-4-6     # inherits thinking_budget: adaptive/high
+
+  claude-faster:
+    provider: deep-anthropic
+    model: claude-opus-4-6
+    thinking_budget: low       # overrides to adaptive/low
+```
+
+## Full Example
+
+See [`examples/thinking_budget.yaml`](https://github.com/docker/docker-agent/blob/main/examples/thinking_budget.yaml) for a runnable config covering all providers.
diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/tips/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/tips/index.md
new file mode 100644
index 000000000000..bde25ee34a7c
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/guides/tips/index.md
@@ -0,0 +1,477 @@
+---
+title: "Tips & Best Practices"
+description: "Expert guidance for building effective, efficient, and secure agents."
+keywords: docker agent, ai agents, guides, tips & best practices
+weight: 10
+canonical: https://docs.docker.com/ai/docker-agent/guides/tips/
+aliases:
+  - /ai/docker-agent/best-practices/
+---
+
+_Expert guidance for building effective, efficient, and secure agents._
+
+## Configuration Tips
+
+### Auto Mode for Quick Start
+
+Don't have a config file? Docker Agent can automatically detect your available API keys and use an appropriate model:
+
+```bash
+# Automatically uses the best available provider
+$ docker agent run
+
+# Provider priority: Anthropic → OpenAI → Google → Mistral → Amazon Bedrock → DMR
+```
+
+The special `auto` model value also works in configs:
+
+```yaml
+agents:
+  root:
+    model: auto # Uses best available provider
+    description: Adaptive assistant
+    instruction: You are a helpful assistant.
+```
+
+### Environment Variable Interpolation
+
+Commands support JavaScript template literal syntax for environment variables:
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-4o
+    description: Deployment assistant
+    instruction: You help with deployments.
+    commands:
+      # Simple variable
+      greet: "Hello ${env.USER}!"
+
+      # With default value
+      deploy: "Deploy to ${env.ENV || 'staging'}"
+
+      # Multiple variables
+      release: "Release ${env.PROJECT} v${env.VERSION || '1.0.0'}"
+```
+
+### Model Aliases Are Auto-Pinned
+
+Docker Agent automatically resolves model aliases to their latest pinned versions. This ensures reproducible behavior:
+
+```yaml
+# You write:
+model: anthropic/claude-sonnet-4-5
+
+# docker-agent resolves to:
+# anthropic/claude-sonnet-4-5-20250929 (or latest available)
+```
+
+To use a specific version, specify it explicitly in your config.
+
+## Performance Tips
+
+### Defer Tools for Faster Startup
+
+Large MCP toolsets can slow down agent startup. Use `defer` to load tools on-demand:
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-4o
+    description: Multi-tool assistant
+    instruction: You have many tools available.
+    toolsets:
+      - type: mcp
+        ref: docker:github-official
+        defer: true
+      - type: mcp
+        ref: docker:slack
+        defer: true
+      - type: mcp
+        ref: docker:linear
+        defer: true
+```
+
+Or defer specific tools within a toolset:
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    defer:
+      - "list_issues"
+      - "search_repos"
+  - type: mcp
+    ref: docker:slack
+    defer:
+      - "list_channels"
+```
+
+### Filter MCP Tools
+
+Many MCP servers expose dozens of tools. Filter to only what you need:
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    # Only expose these specific tools
+    tools:
+      - list_issues
+      - create_issue
+      - get_pull_request
+      - create_pull_request
+```
+
+Fewer tools means faster tool selection and less confusion for the model.
+
+### Set max_iterations
+
+Always set `max_iterations` for agents with powerful tools to prevent infinite loops:
+
+```yaml
+agents:
+  developer:
+    model: anthropic/claude-sonnet-4-5
+    description: Development assistant
+    instruction: You are a developer.
+    max_iterations: 30 # Reasonable limit for development tasks
+    toolsets:
+      - type: filesystem
+      - type: shell
+```
+
+Typical values: 20-30 for development agents, 10-15 for simple tasks.
+
+## Reliability Tips
+
+### Use Fallback Models
+
+Configure fallback models for resilience against provider outages or rate limits:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Reliable assistant
+    instruction: You are a helpful assistant.
+    fallback:
+      models:
+        # Different provider for resilience
+        - openai/gpt-4o
+        # Cheaper model as last resort
+        - openai/gpt-4o-mini
+      retries: 2 # Retry 5xx errors twice
+      cooldown: 1m # Stick with fallback for 1 min after rate limit
+```
+
+**Best practices for fallback chains:**
+
+- Use different providers for true redundancy
+- Order by preference (best first)
+- Include a cheaper/faster model as last resort
+
+### Use Think Tool for Non-Reasoning Models
+
+The `think` tool provides a reasoning scratchpad for models that lack built-in thinking capabilities:
+
+```yaml
+toolsets:
+  - type: think # Useful for models without native reasoning
+```
+
+The agent uses it as a scratchpad for planning and decision-making. If your model already supports a [thinking budget](../../configuration/models/index.md#thinking-budget) (e.g., Claude with extended thinking, OpenAI o-series, Gemini with thinking enabled), you don't need this tool — the model can reason internally.
+
+## Security Tips
+
+### Use --yolo Mode Carefully
+
+The `--yolo` flag auto-approves all tool calls without confirmation:
+
+```bash
+# Auto-approve everything (use with caution!)
+$ docker agent run agent.yaml --yolo
+```
+
+**When it's appropriate:**
+
+- CI/CD pipelines with controlled inputs
+- Automated testing
+- Agents with only safe, read-only tools
+
+**When to avoid:**
+
+- Interactive sessions with untested prompts
+- Agents with shell or filesystem write access
+- Any situation where unreviewed actions could cause harm
+
+### Combine Permissions with Sandbox
+
+For defense in depth, use both permissions and [sandbox mode](../../configuration/sandbox/index.md):
+
+```yaml
+agents:
+  secure_dev:
+    model: anthropic/claude-sonnet-4-5
+    description: Secure development assistant
+    instruction: You are a secure coding assistant.
+    toolsets:
+      - type: filesystem
+      - type: shell
+
+permissions:
+  allow:
+    - "read_*"
+    - "shell:cmd=go*"
+    - "shell:cmd=npm*"
+  deny:
+    - "shell:cmd=sudo*"
+    - "shell:cmd=rm*-rf*"
+```
+
+```bash
+# Run with sandbox enabled
+docker-agent run --sandbox agent.yaml
+```
+
+### Set Global Permission Guardrails
+
+Use [global permissions](../../configuration/permissions/index.md#global-permissions) in your user config to enforce safety rules across every agent:
+
+```yaml
+# ~/.config/cagent/config.yaml
+settings:
+  permissions:
+    deny:
+      - "shell:cmd=sudo*"
+      - "shell:cmd=rm*-rf*"
+      - "shell:cmd=git push --force*"
+    allow:
+      - "read_*"
+      - "shell:cmd=ls*"
+      - "shell:cmd=cat*"
+```
+
+These rules merge with any agent-level permissions. Deny patterns from your global config cannot be overridden by agent configs, so you can trust that dangerous commands stay blocked regardless of which agent you run.
+
+### Use Hooks for Audit Logging
+
+Log all tool calls for compliance or debugging:
+
+```yaml
+agents:
+  audited:
+    model: openai/gpt-4o
+    description: Audited assistant
+    instruction: You are a helpful assistant.
+    hooks:
+      post_tool_use:
+        - matcher: "*"
+          hooks:
+            - type: command
+              command: "./scripts/audit-log.sh"
+```
+
+## Multi-Agent Tips
+
+### Handoffs vs Sub-Agents
+
+Understand the difference between `sub_agents` and `handoffs`:
+
+- **`sub_agents` (transfer_task)** — delegates a task to a child in a sub-session, waits for the result, then continues. Hierarchical: the parent remains in control.
+
+  ```yaml
+  sub_agents: [researcher, writer]
+  ```
+
+- **`handoffs` (peer-to-peer)** — hands off the entire conversation to another agent in the same session. The active agent switches and sees the full history. Agents can form cycles.
+
+  ```yaml
+  handoffs:
+    - specialist
+    - summarizer
+  ```
+
+See [Multi-Agent Systems](../../concepts/multi-agent/index.md) for a detailed comparison.
+
+### Give Sub-Agents Clear Descriptions
+
+The root agent uses descriptions to decide which sub-agent to delegate to:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Technical lead
+    instruction: Delegate to specialists based on the task.
+    sub_agents: [frontend, backend, devops]
+
+  frontend:
+    model: openai/gpt-4o
+    # Good: specific and actionable
+    description: |
+      Frontend specialist. Handles React, TypeScript, CSS, 
+      UI components, and browser-related issues.
+
+  backend:
+    model: openai/gpt-4o
+    # Good: clear domain boundaries
+    description: |
+      Backend specialist. Handles APIs, databases, 
+      server logic, and Go/Python code.
+
+  devops:
+    model: openai/gpt-4o
+    description: |
+      DevOps specialist. Handles CI/CD, Docker, Kubernetes,
+      infrastructure, and deployment pipelines.
+```
+
+## Debugging Tips
+
+### Enable Debug Logging
+
+Use the `--debug` flag to see detailed execution logs:
+
+```bash
+# Default log location: ~/.cagent/cagent.debug.log
+$ docker agent run agent.yaml --debug
+
+# Custom log location
+$ docker agent run agent.yaml --debug --log-file ./debug.log
+```
+
+### Check Token Usage
+
+Use the `/cost` command during a session to see token consumption:
+
+```text
+/cost
+
+Token Usage:
+  Input:  12,456 tokens
+  Output:  3,789 tokens
+  Total:  16,245 tokens
+```
+
+### Compact Long Sessions
+
+If a session gets too long, use `/compact` to summarize and reduce context:
+
+```text
+/compact
+
+Session compacted. Summary generated and history trimmed.
+```
+
+## More Tips
+
+### User-Defined Default Model
+
+Set your preferred default model in `~/.config/cagent/config.yaml`:
+
+```yaml
+settings:
+  default_model: anthropic/claude-sonnet-4-5
+```
+
+This model is used by the built-in default agent when you run `docker agent run` without a config argument and no project-level `docker-agent.yaml`, `docker-agent.yml`, or `docker-agent.hcl` exists.
+
+### Get Desktop Notifications with Hooks
+
+Long-running agents shouldn't require staring at the terminal. Add [global hooks](../../configuration/hooks/index.md#global-user-level-hooks) to your user config so every agent notifies you when it needs attention or finishes:
+
+```yaml
+# ~/.config/cagent/config.yaml
+settings:
+  hooks:
+    # Agent is waiting for your input (question, approval prompt, ...)
+    on_user_input:
+      - type: command
+        command: osascript -e 'display notification "Agent needs your input" with title "docker-agent"'
+
+    # Agent finished responding
+    stop:
+      - type: command
+        command: osascript -e 'display notification "Task finished" with title "docker-agent"'
+```
+
+On Linux, replace `osascript` with `notify-send`:
+
+```yaml
+command: notify-send "docker-agent" "Agent needs your input"
+```
+
+Hooks inherit Docker Agent's environment, so this works as-is from a desktop terminal. In detached contexts (SSH, tmux started outside your desktop session, containers), `notify-send` needs the session's `DISPLAY` and `DBUS_SESSION_BUS_ADDRESS` to reach the notification daemon, and fails silently without them. Pass them with the per-hook `env` option:
+
+```yaml
+on_user_input:
+  - type: command
+    command: notify-send "docker-agent" "Agent needs your input"
+    env:
+      DISPLAY: ":0"
+      DBUS_SESSION_BUS_ADDRESS: "unix:path=/run/user/1000/bus"
+```
+
+To also get alerted on errors and warnings, hook the `notification` event and read the message from the JSON payload on stdin:
+
+```yaml
+settings:
+  hooks:
+    notification:
+      - type: command
+        timeout: 10
+        command: |
+          MESSAGE=$(cat | jq -r '.notification_message // "Agent error"')
+          osascript -e "display notification \"$MESSAGE\" with title \"docker-agent\""
+```
+
+If a sound is enough, set `settings: { sound: true }` instead — Docker Agent plays a failure sound when a task errors, and a success sound when a task that ran longer than `sound_threshold` seconds (default 10) completes.
+
+See the [Hooks documentation](../../configuration/hooks/index.md) for the full list of events, their payloads, and per-hook options (`env`, `working_dir`, `timeout`).
+
+### GitHub PR Reviewer Example
+
+Use Docker Agent as a GitHub Actions PR reviewer:
+
+```yaml
+# .github/workflows/pr-review.yml
+name: PR Review
+on:
+  pull_request:
+    types: [opened, synchronize]
+
+jobs:
+  review:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Run docker-agent review
+        env:
+          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          # Install docker-agent
+          curl -fsSL https://get.docker-agent.dev | sh
+
+          # Run the review
+          docker agent run --exec reviewer.yaml --yolo \
+            "Review PR #${{ github.event.pull_request.number }}"
+```
+
+With a simple reviewer agent:
+
+```yaml
+# reviewer.yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: PR reviewer
+    instruction: |
+      Review pull requests for code quality, bugs, and security issues.
+      Be constructive and specific in your feedback.
+    toolsets:
+      - type: mcp
+        ref: docker:github-official
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/_index.md b/_vendor/github.com/docker/docker-agent/docs/providers/_index.md
new file mode 100644
index 000000000000..22c440cfe7a5
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Model Providers"
+description: "Model providers supported by Docker Agent."
+weight: 60
+---
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/anthropic/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/anthropic/index.md
new file mode 100644
index 000000000000..69c8041f1d35
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/anthropic/index.md
@@ -0,0 +1,241 @@
+---
+title: "Anthropic"
+description: "Use Claude Sonnet 4, Claude Sonnet 4.5, and other Anthropic models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, anthropic
+weight: 20
+canonical: https://docs.docker.com/ai/docker-agent/providers/anthropic/
+---
+
+_Use Claude Sonnet 4, Claude Sonnet 4.5, and other Anthropic models with Docker Agent._
+
+## Setup
+
+```bash
+# Set your API key
+export ANTHROPIC_API_KEY="sk-ant-..."
+```
+
+### Workload Identity Federation (no API key)
+
+Authenticate with short-lived tokens minted from your own OIDC identity
+provider instead of a long-lived API key. See Anthropic's
+[Workload Identity Federation guide](https://platform.claude.com/docs/en/build-with-claude/workload-identity-federation)
+to provision a Federation Rule, then configure Docker Agent with a typed
+`auth:` block:
+
+```yaml
+providers:
+  anthropic-wif:
+    provider: anthropic
+    auth:
+      type: workload_identity_federation
+      workload_identity_federation:
+        federation_rule_id: fdrl_REPLACE_ME
+        organization_id: 00000000-0000-0000-0000-000000000000
+        # Optional: only required for target_type=SERVICE_ACCOUNT rules.
+        service_account_id: svac_REPLACE_ME
+        identity_token:
+          # Pick exactly one of: file, env, command, url
+          file: /var/run/secrets/anthropic.com/token
+
+models:
+  claude:
+    provider: anthropic-wif
+    model: claude-sonnet-4-5
+```
+
+`identity_token` accepts four mutually exclusive sources:
+
+| Source    | When to use                                                                                                              |
+| --------- | ------------------------------------------------------------------------------------------------------------------------ |
+| `file`    | Kubernetes projected service-account tokens, SPIFFE/SPIRE helpers, Vault sidecars — anything that rotates a file on disk |
+| `env`     | The token is already exported in an environment variable                                                                 |
+| `command` | Shell out to a CLI on every refresh (`gcloud auth print-identity-token`, `az account get-access-token`, ...)              |
+| `url`     | Fetch from an HTTP(S) endpoint (cloud metadata servers, GitHub Actions OIDC token URL, ...)                              |
+
+For `url`, both the URL and any header values support `${env.VAR}` expansion
+against the runtime environment (the legacy `${VAR}` form is also accepted),
+which lets you wire the GitHub Actions OIDC
+token endpoint without putting secrets in YAML:
+
+```yaml
+identity_token:
+  url: ${env.ACTIONS_ID_TOKEN_REQUEST_URL}&audience=https://api.anthropic.com
+  headers:
+    Authorization: bearer ${env.ACTIONS_ID_TOKEN_REQUEST_TOKEN}
+  response_field: value
+```
+
+`auth:` is mutually exclusive with `--gateway`. Token-refresh failures are
+surfaced through the normal error path with a clear `anthropic workload
+identity federation: failed to refresh identity token from <kind> source
+(federation_rule=fdrl_…): ...` message in the TUI.
+
+A complete walkthrough of all four sources lives in
+[`examples/anthropic_wif.yaml`](https://github.com/docker/docker-agent/blob/main/examples/anthropic_wif.yaml).
+
+## Configuration
+
+### Inline
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+```
+
+### Named Model
+
+```yaml
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    max_tokens: 64000
+```
+
+## Available Models
+
+| Model ID            | Description                                         |
+| ------------------- | --------------------------------------------------- |
+| `claude-opus-5`     | Highest-capability Opus model; full effort ladder (low–max) |
+| `claude-opus-4-7`   | Previous Opus flagship; supports task budget        |
+| `claude-sonnet-4-5` | Most capable Sonnet; supports extended thinking     |
+| `claude-sonnet-4-0` | Previous Sonnet generation, still supported         |
+| `claude-haiku-4-5`  | Fast and inexpensive, good for tight loops          |
+
+## Thinking Budget
+
+Anthropic accepts either an integer token budget or a string effort value. Thinking is off unless you set `thinking_budget`; when set, interleaved thinking is auto-enabled.
+
+**Token budget** (1024–32768; works on all extended-thinking Claude models):
+
+```yaml
+models:
+  claude-deep:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    thinking_budget: 16384 # must be < max_tokens
+```
+
+**Adaptive / effort-based** (Claude Opus 4.6+, Sonnet 4.6 — every string value is sent as adaptive thinking via `output_config.effort`):
+
+```yaml
+models:
+  opus-adaptive:
+    provider: anthropic
+    model: claude-opus-4-6
+    thinking_budget: adaptive # model decides effort (defaults to high)
+
+  opus-effort:
+    provider: anthropic
+    model: claude-opus-4-6
+    thinking_budget: high # low | medium | high | xhigh | max (same as adaptive/<effort>)
+```
+
+On models that reject token-based thinking (Opus 4.6, 4.7, 4.8, Sonnet 4.6), an integer budget is automatically coerced to `adaptive` with a logged warning. See the [Thinking / Reasoning guide](../../guides/thinking/index.md) for the full cross-provider reference.
+
+## Interleaved Thinking
+
+Auto-enabled whenever a thinking budget is configured on a Claude model. Allows tool calls during model reasoning for more integrated problem-solving:
+
+```yaml
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    provider_opts:
+      interleaved_thinking: false # disable if needed
+```
+
+## Task Budget
+
+`task_budget` caps the **total** number of tokens the model may spend across a
+multi-step agentic task — combined thinking, tool calls, and final output. It
+is forwarded as
+[`output_config.task_budget`](https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7)
+and is ideal for letting long-running agents self-regulate effort without
+tightening `max_tokens` on every call.
+
+Docker Agent automatically attaches the required `task-budgets-2026-03-13`
+beta header whenever this field is set. You can configure `task_budget` on
+**any** Claude model — Docker Agent never gates it by model name. At the time
+of writing, only **Claude Opus 4.7** actually honors the field; other Claude
+models (Sonnet 4.5, Opus 4.5 / 4.6, etc.) are expected to reject requests
+that include it. Check the Anthropic release notes linked above for the
+current list of supported models.
+
+```yaml
+models:
+  opus:
+    provider: anthropic
+    model: claude-opus-4-7
+    task_budget: 128000 # integer shorthand → { type: tokens, total: 128000 }
+    thinking_budget: adaptive
+```
+
+Object form (forward-compatible with future budget types):
+
+```yaml
+  opus:
+    provider: anthropic
+    model: claude-opus-4-7
+    task_budget:
+      type: tokens
+      total: 128000
+```
+
+See the full schema on the [Model Configuration](../../configuration/models/index.md#task-budget) page.
+
+## Server-Side Fallbacks
+
+When the primary model refuses a request (e.g. Claude Fable 5's safety
+classifiers ending the turn with stop reason `refusal`), Anthropic can retry
+the request with backup models in a single round trip. Set `fallbacks` in
+`provider_opts` to a list of model IDs, in priority order:
+
+```yaml
+models:
+  fable:
+    provider: anthropic
+    model: claude-fable-5
+    provider_opts:
+      fallbacks:
+        - claude-opus-4-8
+        - claude-sonnet-4-6
+```
+
+Docker Agent automatically attaches the required
+`server-side-fallback-2026-06-01` beta header and forwards the option as
+`fallbacks: [{"model": "..."}]`. The response's `model` field reports which
+model actually served the request.
+
+Fallback models receive the exact same request as the primary model
+(thinking configuration, task budget, beta features, ...), so list only
+models that accept the same request shape. Not available on Bedrock, Vertex
+AI, or the Message Batches API.
+
+## Thinking Display
+
+Controls whether thinking blocks are returned in responses when thinking is enabled. Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default (`omitted`); Docker Agent counters this by requesting `summarized` thinking whenever an adaptive/effort-based budget is used without an explicit `thinking_display`, so reasoning stays visible in the UI. Set `thinking_display` in `provider_opts` to override:
+
+```yaml
+models:
+  claude-opus-4-7:
+    provider: anthropic
+    model: claude-opus-4-7
+    thinking_budget: adaptive
+    provider_opts:
+      thinking_display: omitted # "summarized" or "omitted" ("display" on pre-4.6 models only)
+```
+
+Valid values:
+
+- `summarized`: thinking blocks are returned with summarized thinking text (Docker Agent's default for adaptive/effort-based budgets).
+- `display`: thinking blocks are returned for display. Only accepted by pre-4.6 token-thinking models (e.g. Sonnet 4.5, Haiku 4.5); models from the adaptive-thinking generation onward (Opus/Sonnet 4.6+, Sonnet 5, Fable 5) reject it, and Docker Agent fails fast with a configuration error instead of sending a request the API would refuse.
+- `omitted`: thinking blocks are returned with an empty thinking field; the signature is still returned for multi-turn continuity. Useful to reduce time-to-first-text-token when streaming.
+
+Note: `thinking_display` applies to both `thinking_budget` with token counts and adaptive/effort-based budgets. For token-count budgets no default is applied (the API already defaults to `summarized`). Full thinking tokens are billed regardless of the `thinking_display` value.
+
+> [!NOTE]
+> Anthropic thinking budget values below 1024 or greater than or equal to `max_tokens` are ignored (a warning is logged).
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/baseten/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/baseten/index.md
new file mode 100644
index 000000000000..f36428484838
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/baseten/index.md
@@ -0,0 +1,91 @@
+---
+title: "Baseten"
+description: "Use Baseten AI models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, baseten
+weight: 40
+canonical: https://docs.docker.com/ai/docker-agent/providers/baseten/
+---
+
+_Use Baseten AI models with Docker Agent._
+
+## Overview
+
+Baseten provides AI models through an OpenAI-compatible API. Docker Agent includes built-in support for Baseten as an alias provider.
+
+## Setup
+
+1. Get an API key from [Baseten](https://www.baseten.co/)
+2. Set the environment variable:
+
+   ```bash
+   export BASETEN_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use Baseten:
+
+```yaml
+agents:
+  root:
+    model: baseten/deepseek-ai/DeepSeek-V3.1
+    description: Assistant using Baseten
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  baseten_model:
+    provider: baseten
+    model: deepseek-ai/DeepSeek-V3.1
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: baseten_model
+    description: Assistant using Baseten
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+Baseten hosts various open models through its Model APIs. Check the [Baseten documentation](https://docs.baseten.co/) for the current model catalog.
+
+| Model                          | Description                    |
+| ------------------------------ | ------------------------------ |
+| `deepseek-ai/DeepSeek-V3.1`    | DeepSeek V3.1 model            |
+| `moonshotai/Kimi-K2.5`         | Moonshot Kimi K2.5 model       |
+| `openai/gpt-oss-120b`          | GPT-OSS 120B model             |
+| `zai-org/GLM-5`                | GLM-5 model                    |
+
+## How It Works
+
+Baseten is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://inference.baseten.co/v1`
+- **Token Variable:** `BASETEN_API_KEY`
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: baseten/deepseek-ai/DeepSeek-V3.1
+    description: Code assistant using DeepSeek
+    instruction: |
+      You are an expert programmer using DeepSeek V3.1.
+      Write clean, well-documented code.
+      Follow best practices for the language being used.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/bedrock/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/bedrock/index.md
new file mode 100644
index 000000000000..f7e190a08602
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/bedrock/index.md
@@ -0,0 +1,175 @@
+---
+title: "AWS Bedrock"
+description: "Access Claude, Nova, Llama, and more through AWS infrastructure with enterprise-grade security and compliance."
+keywords: docker agent, ai agents, model providers, llm, aws bedrock
+weight: 30
+canonical: https://docs.docker.com/ai/docker-agent/providers/bedrock/
+---
+
+_Access Claude, Nova, Llama, and more through AWS infrastructure with enterprise-grade security and compliance._
+
+## Prerequisites
+
+- AWS account with Bedrock enabled in your region
+- Model access granted in the [Bedrock Console](https://console.aws.amazon.com/bedrock/) (some models require approval)
+- AWS credentials configured (see authentication below)
+
+## Configuration
+
+```yaml
+models:
+  bedrock-claude:
+    provider: amazon-bedrock
+    model: global.anthropic.claude-sonnet-4-5-20250929-v1:0
+    max_tokens: 64000
+    provider_opts:
+      region: us-east-1
+```
+
+## Authentication
+
+### Option 1: Bedrock API Key (Simplest)
+
+```bash
+export AWS_BEARER_TOKEN_BEDROCK="your-key"
+```
+
+```yaml
+models:
+  bedrock:
+    provider: amazon-bedrock
+    model: global.anthropic.claude-sonnet-4-5-20250929-v1:0
+    token_key: AWS_BEARER_TOKEN_BEDROCK # env var name
+    provider_opts:
+      region: us-east-1
+```
+
+### Option 2: AWS Credentials (Default)
+
+Uses the standard AWS SDK credential chain: env vars → shared credentials → config → IAM roles.
+
+```yaml
+models:
+  bedrock:
+    provider: amazon-bedrock
+    model: global.anthropic.claude-sonnet-4-5-20250929-v1:0
+    provider_opts:
+      profile: my-aws-profile
+      region: us-east-1
+```
+
+### With IAM Role Assumption
+
+```yaml
+models:
+  bedrock:
+    provider: amazon-bedrock
+    model: global.anthropic.claude-sonnet-4-5-20250929-v1:0
+    provider_opts:
+      role_arn: "arn:aws:iam::123456789012:role/BedrockAccessRole"
+      external_id: "my-external-id"
+```
+
+## Provider Options
+
+| Option                   | Type   | Default                | Description                          |
+| ------------------------ | ------ | ---------------------- | ------------------------------------ |
+| `region`                 | string | us-east-1              | AWS region                           |
+| `profile`                | string | —                      | AWS profile name                     |
+| `role_arn`               | string | —                      | IAM role ARN for assume role         |
+| `role_session_name`      | string | docker-agent-bedrock-session | Session name for assumed role        |
+| `external_id`            | string | —                      | External ID for role assumption      |
+| `endpoint_url`           | string | —                      | Custom endpoint (VPC/testing)        |
+| `interleaved_thinking`   | bool   | auto                   | Allow reasoning between tool calls (Claude); auto-enabled when a thinking budget is set on a Claude model; adds the required beta header automatically |
+| `disable_prompt_caching` | bool   | false                  | Disable automatic prompt caching     |
+
+## Inference Profiles
+
+Use inference profile prefixes for optimal routing:
+
+| Prefix    | Routes To                                |
+| --------- | ---------------------------------------- |
+| `global.` | All commercial AWS regions (recommended) |
+| `us.`     | US regions only                          |
+| `eu.`     | EU regions only (GDPR compliance)        |
+| `apac.`   | Asia Pacific regions only                |
+
+> [!TIP]
+> **Inference profiles**
+>
+> Use `global.` prefix on model IDs for automatic cross-region routing. Use `eu.` prefix for GDPR compliance.
+
+## Thinking Budget (Claude on Bedrock)
+
+Bedrock Claude models support extended thinking — an internal reasoning phase before the model produces its response. Set `thinking_budget` to a token count (1024–32768) or an effort level string that maps automatically:
+
+| Effort level | Token budget |
+| ------------ | ------------ |
+| `minimal`    | 1,024        |
+| `low`        | 2,048        |
+| `medium`     | 8,192        |
+| `high`       | 16,384       |
+| `xhigh`/`max`| 32,768       |
+
+```yaml
+models:
+  bedrock-claude-thinking:
+    provider: amazon-bedrock
+    model: global.anthropic.claude-sonnet-4-5-20250929-v1:0
+    thinking_budget: 8192   # tokens, or use an effort string like "medium"
+    max_tokens: 16384       # must be > thinking_budget
+    provider_opts:
+      region: us-east-1
+```
+
+`thinking_budget` must be ≥ 1024 and less than `max_tokens`. Values outside this range are logged as a warning and ignored.
+
+### Adaptive thinking (Opus 4.6+)
+
+Newer Claude Opus models (4.6, 4.7, 4.8) **reject token-based thinking** — Bedrock returns a `ValidationException` asking for `thinking.type=adaptive`. For these models, use adaptive thinking:
+
+```yaml
+models:
+  bedrock-opus-adaptive:
+    provider: amazon-bedrock
+    model: global.anthropic.claude-opus-4-8
+    thinking_budget: adaptive/high   # adaptive | adaptive/low | adaptive/medium | adaptive/high | adaptive/xhigh | adaptive/max
+    provider_opts:
+      region: us-east-1
+```
+
+Docker Agent recognizes these models (including Bedrock-style IDs) and transparently coerces a configured token budget or effort level to adaptive thinking, logging a warning — so `thinking_budget: 32768` on Opus 4.8 won't fail, but `adaptive` or `adaptive/<effort>` is the recommended configuration. On older models that still use token-based thinking (e.g. Sonnet 4.5), `adaptive` is forwarded as-is and rejected by Bedrock — use a token count or effort level there instead.
+
+> [!NOTE]
+> **Temperature and top_p**
+>
+> Bedrock Claude suppresses `temperature` and `top_p` while extended thinking is active — Anthropic requires `temperature=1.0` internally.
+
+## Interleaved Thinking (Claude on Bedrock)
+
+Interleaved thinking lets the model reason between tool calls, not just at the start. This is useful for complex agentic tasks. Enable it alongside a thinking budget:
+
+```yaml
+models:
+  bedrock-claude-interleaved:
+    provider: amazon-bedrock
+    model: global.anthropic.claude-sonnet-4-5-20250929-v1:0
+    thinking_budget: high
+    provider_opts:
+      region: us-east-1
+      # interleaved_thinking is auto-enabled when thinking_budget is set
+```
+
+Docker Agent auto-enables `interleaved_thinking` whenever a thinking budget is configured on a Bedrock-hosted Claude model and automatically adds the `interleaved-thinking-2025-05-14` beta header. If you set `interleaved_thinking: false` while a thinking budget is active, a warning is logged because the budget may be ignored by Bedrock without the beta header.
+
+See the [Thinking / Reasoning guide](../../guides/thinking/index.md) for a full cross-provider overview.
+
+## Prompt Caching
+
+Automatically enabled for supported models to reduce latency and costs. System prompts, tool definitions, and recent messages are cached with a 5-minute TTL.
+
+```bash
+# Disable if needed
+provider_opts:
+  disable_prompt_caching: true
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/cerebras/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/cerebras/index.md
new file mode 100644
index 000000000000..bf0dba14c912
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/cerebras/index.md
@@ -0,0 +1,103 @@
+---
+title: "Cerebras"
+description: "Use Cerebras models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, cerebras
+weight: 50
+canonical: https://docs.docker.com/ai/docker-agent/providers/cerebras/
+---
+
+_Use Cerebras models with Docker Agent._
+
+## Overview
+
+[Cerebras](https://www.cerebras.ai/) serves open-weight models such as GPT-OSS
+and GLM through an OpenAI-compatible API on its wafer-scale hardware, delivering
+some of the highest tokens/sec available. That speed makes it a strong fit for
+latency-sensitive coding workflows. Docker Agent includes built-in support for
+Cerebras as an alias provider.
+
+## Setup
+
+1. Create an API key from the [Cerebras Cloud console](https://cloud.cerebras.ai/).
+2. Set the environment variable:
+
+   ```bash
+   export CEREBRAS_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use Cerebras:
+
+```yaml
+agents:
+  root:
+    model: cerebras/gpt-oss-120b
+    description: Assistant using Cerebras
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  cerebras_model:
+    provider: cerebras
+    model: gpt-oss-120b
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: cerebras_model
+    description: Assistant using Cerebras
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+Cerebras hosts a curated set of open-weight models. Check the
+[Cerebras models documentation](https://inference-docs.cerebras.ai/models/overview)
+for current model IDs, context limits, and pricing.
+
+| Model | Description |
+| --- | --- |
+| `gpt-oss-120b` | Open-weight GPT-OSS reasoning model with tool calling |
+| `zai-glm-4.7` | Z.AI GLM-4.7 reasoning model with tool calling |
+
+> Model IDs are case-sensitive and must be passed exactly as the catalogue lists
+> them. Cerebras may serve additional models not in the built-in catalog; those
+> still work but resolve to default capability metadata locally.
+
+## How It Works
+
+Cerebras is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://api.cerebras.ai/v1`
+- **Token Variable:** `CEREBRAS_API_KEY`
+
+Because Cerebras fronts open-weight models whose chat templates may only accept
+a single leading system message, Docker Agent coalesces its per-source system
+messages (agent instruction plus each toolset's instructions) into one before
+sending the request.
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: cerebras/gpt-oss-120b
+    description: Fast code assistant using Cerebras
+    instruction: |
+      You are an expert programmer.
+      Write clean, well-documented code and follow language best practices.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/chatgpt/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/chatgpt/index.md
new file mode 100644
index 000000000000..ed50250056b5
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/chatgpt/index.md
@@ -0,0 +1,128 @@
+---
+title: "ChatGPT (OpenAI account)"
+description: "Use your ChatGPT Plus/Pro/Business subscription with Docker Agent by signing in with your OpenAI account, no API key needed."
+keywords: docker agent, ai agents, model providers, llm, chatgpt, openai, codex, subscription
+weight: 55
+canonical: https://docs.docker.com/ai/docker-agent/providers/chatgpt/
+---
+
+_Use your ChatGPT subscription with Docker Agent by signing in with your OpenAI account. No API key needed._
+
+## Overview
+
+The `chatgpt` provider authenticates with a ChatGPT account (the same
+"Sign in with ChatGPT" flow used by OpenAI's Codex CLI) instead of an
+`OPENAI_API_KEY`. Usage is billed against your ChatGPT Plus, Pro, or
+Business plan rather than pay-per-token API credits.
+
+Under the hood, Docker Agent talks to the ChatGPT Codex backend
+(`https://chatgpt.com/backend-api/codex`), which serves the `gpt-5` model
+family over the OpenAI Responses API. GPT-5.6 (Sol/Terra/Luna) is served
+there too; GPT-5.2 and GPT-5.3-Codex are deprecated for ChatGPT sign-in.
+
+## Prerequisites
+
+- A paid **ChatGPT** subscription (Plus, Pro, or Business).
+- A browser on the machine running the sign-in (the OAuth flow uses a
+  fixed `localhost:1455` callback).
+
+## Sign In
+
+```bash
+docker agent setup
+```
+
+Pick **chatgpt** in the provider list: instead of asking for an API key, the
+wizard opens your browser on the ChatGPT sign-in page and stores the
+resulting OAuth credential in the Docker Agent config directory
+(`~/.config/cagent/chatgpt-auth.json`, owner-only permissions). The access
+token is refreshed automatically; you only need to sign in again if the
+refresh token is revoked.
+
+Related commands:
+
+```bash
+docker agent doctor                        # the chatgpt row shows the credential state
+rm ~/.config/cagent/chatgpt-auth.json      # sign out (remove the stored sign-in)
+```
+
+## Configuration
+
+### Inline
+
+```yaml
+agents:
+  root:
+    model: chatgpt/gpt-5.6
+    instruction: You are a helpful assistant.
+```
+
+### Named model
+
+```yaml
+models:
+  gpt:
+    provider: chatgpt
+    model: gpt-5.6
+    thinking_budget: medium
+
+agents:
+  root:
+    model: gpt
+```
+
+## Available Models
+
+The Codex backend serves the models available to your ChatGPT plan,
+typically:
+
+| Model                | Best For                              |
+| -------------------- | -------------------------------------- |
+| `gpt-5.6`            | Alias for `gpt-5.6-sol`; general purpose, strong reasoning |
+| `gpt-5.6-sol`        | Frontier model, most capable          |
+| `gpt-5.6-terra`      | Everyday workhorse                    |
+| `gpt-5.6-luna`       | High-volume, cost-efficient           |
+| `gpt-5.2`            | Deprecated for ChatGPT sign-in        |
+| `gpt-5.2-codex`      | Deprecated for ChatGPT sign-in        |
+
+The effort picker exposes Low/Medium/High/XHigh/Max on the GPT-5.6 family
+(no Minimal).
+
+## How It Works
+
+- **Auth:** the `docker agent setup` sign-in runs an OAuth 2.0
+  authorization-code + PKCE flow against `auth.openai.com`. The stored login
+  is exposed to credential checks (doctor, `first_available`, auto model
+  selection) as the virtual `CHATGPT_OAUTH_TOKEN` variable.
+- **API:** requests go to the Responses API only; the backend has no Chat
+  Completions endpoint, so `api_type` is pinned automatically.
+- **Request shape:** the backend requires stateless requests (`store: false`)
+  and a top-level `instructions` field, so Docker Agent moves system messages
+  there. Client-side sampling parameters (`temperature`, `top_p`,
+  `max_tokens`) are not supported by the backend and are dropped.
+
+## Setting the Token Explicitly
+
+`CHATGPT_OAUTH_TOKEN` can also be set like any other credential (shell
+environment, `--env-from-file`, ...). An explicitly set value takes
+precedence over the stored sign-in. This is useful for short-lived CI runs
+with a pre-minted access token, but note that such a token expires and is not
+refreshed.
+
+## ChatGPT Subscription vs. OpenAI API Key
+
+| | `chatgpt` | `openai` |
+| --- | --- | --- |
+| Credential | ChatGPT account sign-in | `OPENAI_API_KEY` |
+| Billing | Included in the ChatGPT plan (rate-limited) | Pay per token |
+| Models | `gpt-5` family served by the Codex backend | Full OpenAI API catalog |
+| Sampling controls (`temperature`, ...) | Not supported | Supported |
+| Embeddings / reranking | Not supported | Supported |
+
+When both credentials are configured, automatic model selection prefers
+`openai`; pin `--model chatgpt/gpt-5.6` (or use a named model) to use the
+subscription.
+
+> [!NOTE]
+> Use of the Codex backend is governed by OpenAI's terms for ChatGPT and
+> Codex. Sign-in is per user; do not share the stored credential.
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-ai-gateway/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-ai-gateway/index.md
new file mode 100644
index 000000000000..558d8c6e03b0
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-ai-gateway/index.md
@@ -0,0 +1,115 @@
+---
+title: "Cloudflare AI Gateway"
+description: "Use Cloudflare AI Gateway models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, cloudflare ai gateway
+weight: 60
+canonical: https://docs.docker.com/ai/docker-agent/providers/cloudflare-ai-gateway/
+---
+
+_Use Cloudflare AI Gateway models with Docker Agent._
+
+## Overview
+
+[Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/) is a
+single OpenAI-compatible endpoint that routes to models from OpenAI, Anthropic,
+Workers AI and more, with caching, rate limiting and observability. Docker Agent
+includes built-in support for AI Gateway as an alias provider.
+
+The alias sends your token in the standard `Authorization: Bearer` header, so it
+works out of the box with a gateway that has **authentication disabled** (the
+default), typically to route to your own Workers AI models through a gateway you
+own. See [Authentication](#authentication) below for the unified-billing /
+authenticated-gateway caveat.
+
+## Setup
+
+The gateway endpoint is account- and gateway-scoped, so its base URL is resolved
+from your account ID and gateway ID. Three environment variables are required:
+
+```bash
+export CLOUDFLARE_ACCOUNT_ID=your-account-id
+export CLOUDFLARE_GATEWAY_ID=your-gateway-id
+export CLOUDFLARE_API_TOKEN=your-api-token
+```
+
+Create a gateway from the
+[AI Gateway dashboard](https://dash.cloudflare.com/?to=/:account/ai/ai-gateway)
+and an API token with the appropriate permissions.
+
+## Usage
+
+AI Gateway model IDs use the gateway's `provider/model` form (for example
+`workers-ai/@cf/meta/llama-3.1-8b-instruct` or `openai/gpt-4o`); the gateway
+routes each request to the underlying provider.
+
+### Inline Syntax
+
+```yaml
+agents:
+  root:
+    model: cloudflare-ai-gateway/workers-ai/@cf/meta/llama-3.1-8b-instruct
+    description: Assistant using Cloudflare AI Gateway
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  cloudflare_model:
+    provider: cloudflare-ai-gateway
+    model: "workers-ai/@cf/meta/llama-3.1-8b-instruct"
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: cloudflare_model
+    description: Assistant using Cloudflare AI Gateway
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+AI Gateway exposes models from many providers behind one endpoint. Check the
+[AI Gateway documentation](https://developers.cloudflare.com/ai-gateway/) for
+the current provider list, model IDs, and how billing works.
+
+> Model IDs are case-sensitive and must be passed exactly as the gateway lists
+> them, including the `provider/` prefix.
+
+## How It Works
+
+Cloudflare AI Gateway is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://gateway.ai.cloudflare.com/v1/${CLOUDFLARE_ACCOUNT_ID}/${CLOUDFLARE_GATEWAY_ID}/compat`
+- **Token Variable:** `CLOUDFLARE_API_TOKEN`
+
+The base URL is templated: `${CLOUDFLARE_ACCOUNT_ID}` and
+`${CLOUDFLARE_GATEWAY_ID}` are substituted from the environment when the provider
+is built, so both must be set in addition to `CLOUDFLARE_API_TOKEN`. Because the
+gateway can route to open-weight models with strict chat templates, Docker Agent
+coalesces consecutive system messages into a single leading one for this
+provider.
+
+## Authentication
+
+Docker Agent authenticates by sending `CLOUDFLARE_API_TOKEN` in the standard
+`Authorization: Bearer` header. On the `.../compat` endpoint that header is
+treated as the **provider** key, so this alias works when:
+
+- the gateway has **authentication disabled** (the default), and
+- the routed models accept that token as their provider key, which is the case
+  for **Workers AI** models (`workers-ai/@cf/...`).
+
+A gateway with **authentication enabled** (required for
+[unified billing](https://developers.cloudflare.com/ai-gateway/features/unified-billing/))
+instead expects the token in Cloudflare's `cf-aig-authorization` header. The
+alias does not send that header, and custom `provider_opts.http_headers` values
+are not environment-expanded, so an authenticated gateway is **not supported out
+of the box** today. For that setup, use an unauthenticated gateway, or configure
+a [custom provider](../custom/index.md) against the
+Cloudflare AI Gateway REST API.
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-workers-ai/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-workers-ai/index.md
new file mode 100644
index 000000000000..68477296aee6
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-workers-ai/index.md
@@ -0,0 +1,91 @@
+---
+title: "Cloudflare Workers AI"
+description: "Use Cloudflare Workers AI models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, cloudflare workers ai
+weight: 70
+canonical: https://docs.docker.com/ai/docker-agent/providers/cloudflare-workers-ai/
+---
+
+_Use Cloudflare Workers AI models with Docker Agent._
+
+## Overview
+
+[Cloudflare Workers AI](https://developers.cloudflare.com/workers-ai/) runs
+open-weight models (Llama, Mistral, Qwen, Gemma, and more) on Cloudflare's
+global edge network through an OpenAI-compatible endpoint. No separate provider
+accounts are needed for the supported models. Docker Agent includes built-in
+support for Workers AI as an alias provider.
+
+## Setup
+
+Workers AI is account-scoped, so its base URL is resolved from your account ID.
+Two environment variables are required:
+
+```bash
+export CLOUDFLARE_ACCOUNT_ID=your-account-id
+export CLOUDFLARE_API_TOKEN=your-api-token
+```
+
+Create an API token with the `Workers AI` permission from the
+[Cloudflare dashboard](https://dash.cloudflare.com/profile/api-tokens). Your
+account ID is shown on the Workers AI page.
+
+## Usage
+
+Workers AI model IDs use the `@cf/...` form (for example
+`@cf/meta/llama-3.1-8b-instruct`).
+
+### Inline Syntax
+
+```yaml
+agents:
+  root:
+    model: cloudflare-workers-ai/@cf/meta/llama-3.1-8b-instruct
+    description: Assistant using Cloudflare Workers AI
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  cloudflare_model:
+    provider: cloudflare-workers-ai
+    model: "@cf/meta/llama-3.1-8b-instruct"
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: cloudflare_model
+    description: Assistant using Cloudflare Workers AI
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+Check the
+[Workers AI models catalog](https://developers.cloudflare.com/workers-ai/models/)
+for the current list, IDs, and pricing.
+
+| Model | Description |
+| --- | --- |
+| `@cf/meta/llama-3.1-8b-instruct` | Meta Llama 3.1 8B Instruct |
+| `@cf/mistralai/mistral-small-3.1-24b-instruct` | Mistral Small 3.1 24B Instruct |
+| `@cf/qwen/qwen2.5-coder-32b-instruct` | Qwen 2.5 Coder 32B Instruct |
+
+## How It Works
+
+Cloudflare Workers AI is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://api.cloudflare.com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/ai/v1`
+- **Token Variable:** `CLOUDFLARE_API_TOKEN`
+
+The base URL is templated: `${CLOUDFLARE_ACCOUNT_ID}` is substituted from the
+environment when the provider is built, so `CLOUDFLARE_ACCOUNT_ID` must be set in
+addition to `CLOUDFLARE_API_TOKEN`. Because Workers AI serves open-weight models
+with strict chat templates, Docker Agent coalesces consecutive system messages
+into a single leading one for this provider.
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/custom/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/custom/index.md
new file mode 100644
index 000000000000..427585502d7b
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/custom/index.md
@@ -0,0 +1,315 @@
+---
+title: "Provider Definitions"
+description: "Define reusable provider configurations with shared defaults for any provider type — OpenAI, Anthropic, Google, Bedrock, and more."
+keywords: docker agent, ai agents, model providers, llm, provider definitions
+weight: 280
+canonical: https://docs.docker.com/ai/docker-agent/providers/custom/
+---
+
+_Define reusable provider configurations with shared defaults for any provider type — OpenAI, Anthropic, Google, Bedrock, and more._
+
+## Overview
+
+The `providers` section in your agent YAML lets you define named provider configurations that models can reference. This is useful for:
+
+- **Grouping shared defaults** — Set temperature, max_tokens, thinking_budget once and share across models
+- **Custom endpoints** — Connect to self-hosted models, API proxies, or gateways
+- **Centralizing credentials** — Define token_key once for all models using a provider
+- **Any provider type** — Works with OpenAI, Anthropic, Google, Bedrock, and any OpenAI-compatible API
+
+> [!NOTE]
+> **Works with any provider**
+>
+> The `providers` section supports all provider types: `openai`, `anthropic`, `google`, `amazon-bedrock`, `dmr`, and any built-in alias. When the `provider` field is not set, it defaults to `openai` for backward compatibility.
+
+## Configuration
+
+### OpenAI-compatible endpoint
+
+```yaml
+providers:
+  my_gateway:
+    base_url: https://api.example.com/v1
+    token_key: MY_API_KEY
+
+models:
+  my_model:
+    provider: my_gateway
+    model: gpt-4o
+
+agents:
+  root:
+    model: my_model
+    instruction: You are a helpful assistant.
+```
+
+### Anthropic with shared defaults
+
+```yaml
+providers:
+  my_anthropic:
+    provider: anthropic
+    token_key: MY_ANTHROPIC_KEY
+    max_tokens: 16384
+    thinking_budget: 8192
+
+models:
+  claude_smart:
+    provider: my_anthropic
+    model: claude-sonnet-4-5
+    # Inherits max_tokens: 16384, thinking_budget: 8192
+
+  claude_fast:
+    provider: my_anthropic
+    model: claude-haiku-4-5
+    thinking_budget: 1024  # Overrides provider default
+
+agents:
+  root:
+    model: claude_smart
+    instruction: You are a helpful assistant.
+```
+
+### Google with shared temperature
+
+```yaml
+providers:
+  my_google:
+    provider: google
+    temperature: 0.3
+
+models:
+  gemini:
+    provider: my_google
+    model: gemini-2.5-flash
+    # Inherits temperature: 0.3
+
+agents:
+  root:
+    model: gemini
+    instruction: You are a helpful assistant.
+```
+
+## Provider Properties
+
+| Property              | Type       | Description                                                                           | Default                  |
+| --------------------- | ---------- | ------------------------------------------------------------------------------------- | ------------------------ |
+| `provider`            | string     | Underlying provider type: `openai`, `anthropic`, `google`, `amazon-bedrock`, `dmr`, etc. | `openai`                 |
+| `api_type`            | string     | API schema: `openai_chatcompletions` or `openai_responses`. Only for OpenAI-compatible providers. When omitted, the API type is selected automatically based on the model name: newer models (gpt-4.1, o-series, gpt-5, Codex) default to `openai_responses`; all others default to `openai_chatcompletions`. | `auto (model-dependent)` |
+| `base_url`            | string     | Base URL for the API endpoint. Required for OpenAI-compatible providers, optional for native providers. | —                        |
+| `token_key`           | string     | Environment variable name containing the API token.                                   | —                        |
+| `unload_api`          | string     | Optional path (or absolute URL) to the provider's model-unload endpoint. Used by the [`unload`](../../configuration/hooks/index.md#available-built-ins) built-in hook to release model resources between agent switches. Relative paths resolve against `base_url`'s scheme + host; absolute URLs are used verbatim. Today only Docker Model Runner ships a provider that calls this endpoint; cloud providers don't implement the underlying interface and the hook silently skips them. | —                        |
+| `temperature`         | float      | Default sampling temperature (0.0–2.0).                                               | —                        |
+| `max_tokens`          | int        | Default maximum response tokens.                                                      | —                        |
+| `top_p`               | float      | Default nucleus sampling threshold (0.0–1.0).                                         | —                        |
+| `frequency_penalty`   | float      | Default frequency penalty (-2.0–2.0).                                                 | —                        |
+| `presence_penalty`    | float      | Default presence penalty (-2.0–2.0).                                                  | —                        |
+| `parallel_tool_calls` | boolean    | Whether to enable parallel tool calls by default.                                     | —                        |
+| `track_usage`         | boolean    | Whether to track token usage by default.                                              | —                        |
+| `thinking_budget`     | string/int | Default reasoning effort/budget.                                                      | —                        |
+| `task_budget`         | int/object | Default total token budget for an agentic task (forwarded to Anthropic; honored by Claude Opus 4.7 today). Integer shorthand or `{type: tokens, total: N}`. | —                        |
+| `compaction_model`    | string     | Default model used for session compaction (summary generation) by agents whose model uses this provider. Named model or inline `provider/model` string. Agent-level and model-level `compaction_model` take precedence. | —                        |
+| `provider_opts`       | object     | Provider-specific options passed through to the client.                               | —                        |
+
+## Default Inheritance
+
+Models referencing a provider inherit all its defaults. Model-level settings always take precedence:
+
+```yaml
+providers:
+  my_anthropic:
+    provider: anthropic
+    token_key: MY_ANTHROPIC_KEY
+    max_tokens: 16384
+    temperature: 0.7
+    thinking_budget: high
+
+models:
+  # Inherits everything from provider
+  claude_default:
+    provider: my_anthropic
+    model: claude-sonnet-4-5
+
+  # Overrides temperature and thinking_budget, inherits the rest
+  claude_custom:
+    provider: my_anthropic
+    model: claude-sonnet-4-5
+    temperature: 0.2
+    thinking_budget: low
+```
+
+`compaction_model` works slightly differently: it is not merged into the model
+but resolved per agent, with the agent-level `compaction_model` winning over
+the model-level one, which wins over the provider-level default.
+
+## Shorthand Syntax
+
+Once a provider is defined, you can use the shorthand `provider_name/model` syntax:
+
+```yaml
+agents:
+  root:
+    model: my_gateway/gpt-4o-mini  # uses the provider's defaults
+  researcher:
+    model: my_anthropic/claude-sonnet-4-5  # uses anthropic provider defaults
+```
+
+## API Types
+
+Only applicable for OpenAI-compatible providers (when `provider` is `openai` or unset):
+
+- **`openai_chatcompletions`** — Standard OpenAI Chat Completions API. Works with most OpenAI-compatible endpoints.
+- **`openai_responses`** — OpenAI Responses API. For newer models that require the Responses API format.
+
+> If `api_type` is not set, Docker Agent automatically selects the API type based on the model name. You only need to set `api_type` explicitly to override the detected default.
+
+## Examples
+
+### vLLM / Ollama
+
+```yaml
+providers:
+  local_llm:
+    base_url: http://localhost:8000/v1
+
+agents:
+  root:
+    model: local_llm/llama-3.1-8b
+```
+
+> [!NOTE]
+> **Reasoning tokens from OpenAI-compatible providers**
+>
+> Models that stream reasoning under `delta.reasoning` (e.g. Qwen3 served via OVHcloud AI Endpoints, OpenRouter, or a self-hosted vLLM / SGLang deployment) are fully supported. Docker Agent reads both the `delta.reasoning_content` and `delta.reasoning` fields from the stream, so thinking blocks are captured and shown in the TUI regardless of which field the server uses.
+
+### API Router (Requesty, LiteLLM)
+
+```yaml
+providers:
+  router:
+    base_url: https://router.requesty.ai/v1
+    token_key: REQUESTY_API_KEY
+
+agents:
+  root:
+    model: router/anthropic/claude-sonnet-4-5
+```
+
+### Azure OpenAI
+
+```yaml
+models:
+  azure_model:
+    provider: azure
+    model: gpt-4o
+    base_url: https://your-llm.openai.azure.com
+    provider_opts:
+      api_version: 2024-12-01-preview
+```
+
+### Anthropic Team Setup
+
+```yaml
+providers:
+  team_anthropic:
+    provider: anthropic
+    token_key: TEAM_ANTHROPIC_KEY
+    max_tokens: 32768
+    thinking_budget: high
+    temperature: 0.5
+
+models:
+  architect:
+    provider: team_anthropic
+    model: claude-sonnet-4-5
+
+  reviewer:
+    provider: team_anthropic
+    model: claude-haiku-4-5
+    thinking_budget: low  # faster reviews
+
+agents:
+  root:
+    model: architect
+    sub_agents: [code_reviewer]
+  code_reviewer:
+    model: reviewer
+```
+
+### Multi-Provider with Shared Defaults
+
+```yaml
+providers:
+  fast_openai:
+    base_url: https://api.openai.com/v1
+    token_key: OPENAI_API_KEY
+    temperature: 0.3
+    max_tokens: 8192
+
+  smart_anthropic:
+    provider: anthropic
+    token_key: ANTHROPIC_API_KEY
+    max_tokens: 64000
+    thinking_budget: high
+
+agents:
+  root:
+    model: smart_anthropic/claude-sonnet-4-5
+    sub_agents: [helper]
+  helper:
+    model: fast_openai/gpt-4o-mini
+```
+
+## Global Providers (User Configuration)
+
+Providers defined in an agent file only apply to that file. To make a custom
+provider available to every command (`docker agent run`, `new`, `models`, ...),
+define it once in your user configuration (`~/.config/cagent/config.yaml`)
+under the same `providers` key:
+
+```yaml
+# ~/.config/cagent/config.yaml
+providers:
+  myprovider:
+    base_url: https://llm.corp.example.com/v1
+    api_type: openai_chatcompletions
+    token_key: MYPROVIDER_API_KEY
+```
+
+The easiest way to register one is the interactive wizard:
+
+```bash
+docker agent setup
+# pick "3. Custom OpenAI-compatible endpoint", then enter the base URL,
+# API format, and the environment variable holding the API key
+```
+
+Once registered, the provider works everywhere:
+
+```bash
+docker agent models --provider myprovider   # list the endpoint's models
+docker agent new --model myprovider/mymodel # build agents with it
+docker agent run --model myprovider/mymodel # chat with it
+```
+
+Global providers are merged into every loaded agent configuration; when an
+agent file defines a provider with the same name, the agent file wins. Note
+that automatic model selection (`model: auto`) never picks a custom provider,
+so reference its models explicitly with `--model <name>/<model>` or
+`default_model`.
+
+## How It Works
+
+When you reference a provider:
+
+1. The provider's `provider` field determines which API client to use (defaults to `openai`)
+2. The provider's `base_url` and `token_key` are applied to the model (if not already set on the model)
+3. All model-level defaults (temperature, max_tokens, thinking_budget, etc.) are inherited (model settings take precedence)
+4. For OpenAI-compatible providers, the `api_type` is stored in `provider_opts.api_type`
+5. The model is used with the appropriate API client
+
+A provider with a `base_url` implies `bypass_models_gateway: true` for every
+model that references it: user-chosen endpoints are never routed through a
+configured models gateway, and such models authenticate with the provider's
+own credentials (`token_key`). See
+[Gateway Bypass](../../configuration/models/index.md#gateway-bypass).
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/deepseek/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/deepseek/index.md
new file mode 100644
index 000000000000..e62710a4f413
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/deepseek/index.md
@@ -0,0 +1,96 @@
+---
+title: "DeepSeek"
+description: "Use DeepSeek models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, deepseek
+weight: 80
+canonical: https://docs.docker.com/ai/docker-agent/providers/deepseek/
+---
+
+_Use DeepSeek models with Docker Agent._
+
+## Overview
+
+[DeepSeek](https://www.deepseek.com/) serves its frontier chat and reasoning
+models through an OpenAI-compatible API, with strong price/performance on coding
+and reasoning tasks. Docker Agent includes built-in support for DeepSeek as an
+alias provider.
+
+## Setup
+
+1. Create an API key from the [DeepSeek Platform](https://platform.deepseek.com/api_keys).
+2. Set the environment variable:
+
+   ```bash
+   export DEEPSEEK_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use DeepSeek:
+
+```yaml
+agents:
+  root:
+    model: deepseek/deepseek-chat
+    description: Assistant using DeepSeek
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  deepseek_model:
+    provider: deepseek
+    model: deepseek-chat
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: deepseek_model
+    description: Assistant using DeepSeek
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+DeepSeek exposes a small, vendor-controlled model lineup. Check the
+[DeepSeek models documentation](https://api-docs.deepseek.com/quick_start/pricing)
+for current model IDs, context limits, and pricing.
+
+| Model | Description |
+| --- | --- |
+| `deepseek-chat` | DeepSeek-V3, general-purpose chat and tool calling |
+| `deepseek-reasoner` | DeepSeek-R1, extended-reasoning model |
+
+> Model IDs are case-sensitive and must be passed exactly as the catalogue lists
+> them.
+
+## How It Works
+
+DeepSeek is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://api.deepseek.com/v1`
+- **Token Variable:** `DEEPSEEK_API_KEY`
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: deepseek/deepseek-chat
+    description: Code assistant using DeepSeek-V3
+    instruction: |
+      You are an expert programmer.
+      Write clean, well-documented code and follow language best practices.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/dmr/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/dmr/index.md
new file mode 100644
index 000000000000..65b0528bec80
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/dmr/index.md
@@ -0,0 +1,253 @@
+---
+title: "Docker Model Runner"
+description: "Run AI models locally with Docker — no API keys, no costs, full data privacy."
+keywords: docker agent, ai agents, model providers, llm, docker model runner
+weight: 90
+canonical: https://docs.docker.com/ai/docker-agent/providers/dmr/
+---
+
+_Run AI models locally with Docker — no API keys, no costs, full data privacy._
+
+## Overview
+
+Docker Model Runner (DMR) lets you run open-source AI models directly on your machine. Models run in Docker, so there's no API key needed and no data leaves your computer.
+
+Docker Agent automatically discovers models you have already pulled from DMR. When no model is explicitly configured, auto-selection prefers a locally-installed model (choosing the model specified via the `model:` key in the agent YAML if it is already pulled locally, or otherwise the first available non-embedding model) rather than always defaulting to `ai/qwen3:latest` and triggering a pull prompt.
+
+> [!TIP]
+> **No API key needed**
+>
+> DMR runs models locally — your data never leaves your machine. Great for development, sensitive data, or offline use.
+
+## Prerequisites
+
+- [Docker Desktop](https://www.docker.com/products/docker-desktop/) with the Model Runner feature enabled
+- Verify with: `docker model status --json`
+
+## Configuration
+
+### Inline
+
+```yaml
+agents:
+  root:
+    model: dmr/ai/qwen3
+```
+
+### Named Model
+
+```yaml
+models:
+  local:
+    provider: dmr
+    model: ai/qwen3
+    max_tokens: 8192
+```
+
+## Available Models
+
+Any model available through Docker Model Runner can be used. Common options:
+
+| Model         | Description                                           |
+| ------------- | ----------------------------------------------------- |
+| `ai/qwen3`    | Qwen 3 — versatile, good for coding and general tasks |
+| `ai/llama3.2` | Llama 3.2 — Meta's open-source model                  |
+
+## Runtime Flags
+
+Pass flags to the underlying inference runtime (e.g., llama.cpp) using `provider_opts.runtime_flags`:
+
+```yaml
+models:
+  local:
+    provider: dmr
+    model: ai/qwen3
+    max_tokens: 8192
+    provider_opts:
+      runtime_flags: ["--threads", "8"]
+```
+
+Runtime flags also accept a single string:
+
+```yaml
+provider_opts:
+  runtime_flags: "--threads 8"
+```
+
+Use only flags your Model Runner backend allows (see `docker model configure --help` and backend docs). **Do not** put sampling parameters (`temperature`, `top_p`, penalties) in `runtime_flags` — set them on the model (`temperature`, `top_p`, etc.); they are sent **per request** via the OpenAI-compatible chat API.
+
+## Context size
+
+`max_tokens` controls the **maximum output tokens** per chat completion request. To set the engine's **total context window**, use `provider_opts.context_size`:
+
+```yaml
+models:
+  local:
+    provider: dmr
+    model: ai/qwen3
+    max_tokens: 4096            # max output tokens (per-request)
+    provider_opts:
+      context_size: 32768       # total context window (sent via _configure)
+```
+
+If `context_size` is omitted, Model Runner uses its default. `max_tokens` is **not** used as the context window.
+
+Docker Agent's auto-compaction scales its summary and keep-tail token budgets proportionally to `context_size`. This ensures compaction works correctly even for small context windows — for example, an 8k-token local model will not have its session history wiped during compaction.
+
+## Thinking / reasoning budget
+
+When using the **llama.cpp** backend, `thinking_budget` is sent as structured `llamacpp.reasoning-budget` on `_configure` (maps to `--reasoning-budget`). String efforts use the same token mapping as other providers; `adaptive` maps to unlimited (`-1`).
+
+When using the **vLLM** backend, `thinking_budget` is sent as `thinking_token_budget` in each chat completion request. Effort levels map to token counts using the same scale as other providers; `adaptive` maps to unlimited (`-1`).
+
+```yaml
+models:
+  local:
+    provider: dmr
+    model: ai/qwen3
+    thinking_budget: medium   # llama.cpp: reasoning-budget=8192; vLLM: thinking_token_budget=8192
+```
+
+On **MLX** and **SGLang** backends, `thinking_budget` is silently ignored — those engines do not currently expose a per-request reasoning token budget knob.
+
+## vLLM-specific configuration
+
+When running a model on the **vLLM** backend, additional engine-level settings can be passed via `provider_opts` and are forwarded to model-runner's `_configure` endpoint:
+
+- `gpu_memory_utilization` — fraction of GPU memory (0.0–1.0) vLLM may use. Values outside this range are rejected.
+- `hf_overrides` — map of Hugging Face config overrides applied when vLLM loads the model.
+
+```yaml
+models:
+  vllm-local:
+    provider: dmr
+    model: ai/some-model-safetensors
+    provider_opts:
+      gpu_memory_utilization: 0.9
+      hf_overrides:
+        max_model_len: 8192
+        dtype: bfloat16
+```
+
+`hf_overrides` keys (including nested ones) must match `^[a-zA-Z_][a-zA-Z0-9_]*$` — the same rule model-runner enforces server-side to block injection via flags. Invalid keys are rejected at client creation time so you fail fast instead of after a round-trip.
+
+These options are ignored on non-vLLM backends.
+
+## Keeping models resident in memory (`keep_alive`)
+
+By default model-runner unloads idle models after a few minutes. Override the idle timeout via `provider_opts.keep_alive`:
+
+```yaml
+models:
+  sticky:
+    provider: dmr
+    model: ai/qwen3
+    provider_opts:
+      keep_alive: "30m"   # duration string
+      # keep_alive: "0"   # unload immediately after each request
+      # keep_alive: "-1"  # keep loaded forever
+```
+
+Accepted values: any Go duration string (`"30s"`, `"5m"`, `"1h"`, `"2h30m"`), `"0"` (immediate unload), or `"-1"` (never unload). Invalid values are rejected before the configure request is sent.
+
+## Unloading models on agent switch
+
+In multi-agent setups where two DMR models can't fit in GPU memory simultaneously, wire the [`unload`](../../configuration/hooks/index.md#available-built-ins) built-in hook into each agent's `on_agent_switch` chain. Every time the active agent transfers control, the runtime POSTs to the engine's `_unload` endpoint to free the previous model's resources before the next one is loaded:
+
+```yaml
+agents:
+  coder:
+    model: qwen3-large
+    handoffs: [reviewer]
+    hooks:
+      on_agent_switch:
+        - type: builtin
+          command: unload
+  reviewer:
+    model: qwen3-coder
+    handoffs: [coder]
+    hooks:
+      on_agent_switch:
+        - type: builtin
+          command: unload
+```
+
+The unload URL is derived from `base_url` by replacing the trailing `/v1` segment (e.g. `http://127.0.0.1:12434/engines/llama.cpp/v1/` → `http://127.0.0.1:12434/engines/llama.cpp/_unload`). Override it explicitly via the provider-level `unload_api` field when running against a non-standard model-runner deployment:
+
+```yaml
+providers:
+  my_dmr:
+    provider: dmr
+    base_url: http://model-runner.docker.internal/engines/v1
+    unload_api: /engines/_unload   # default; absolute URLs also work
+
+models:
+  big:
+    provider: my_dmr
+    model: ai/qwen3
+```
+
+Unload errors are logged and swallowed — a stuck or unreachable engine never blocks an agent transfer (each call is bounded to 10 s). Pair this with [`keep_alive`](#keeping-models-resident-in-memory-keep_alive) only when you want the model to *also* survive idle periods within a single agent's run; the hook controls **between-agent** unloads independently.
+
+> [!WARNING]
+> **Single-tenant assumption**
+>
+> The `_unload` endpoint is engine-level: it evicts the model from DMR's memory regardless of who is using it. If two concurrent sessions on the same runtime (e.g. an API server serving multiple users) hit the same agent, switching away in session A will yank the model out from under session B's in-flight request, which then has to wait for a reload. Wire `unload` only when the agents using these models are not run concurrently — typically a single TUI/CLI session.
+
+See [`examples/unload_on_switch.yaml`](https://github.com/docker/docker-agent/blob/main/examples/unload_on_switch.yaml) for the full example.
+
+## Operating mode (`mode`)
+
+Model-runner normally infers the backend mode from the request path. You can pin it explicitly via `provider_opts.mode`:
+
+```yaml
+provider_opts:
+  mode: embedding   # one of: completion, embedding, reranking, image-generation
+```
+
+Most agents don't need this — leave it unset unless you know you need it.
+
+## Raw runtime flags (`raw_runtime_flags`)
+
+`runtime_flags` (a list) is the preferred way to pass flags. If you have a pre-built command-line string you'd rather ship verbatim, use `raw_runtime_flags` instead:
+
+```yaml
+provider_opts:
+  raw_runtime_flags: "--threads 8 --batch-size 512"
+```
+
+Model-runner parses the string with shell-style word splitting. `runtime_flags` and `raw_runtime_flags` are mutually exclusive — setting both is an error.
+
+## Speculative Decoding
+
+Use a smaller draft model to predict tokens ahead for faster inference:
+
+```yaml
+models:
+  fast-local:
+    provider: dmr
+    model: ai/qwen3:14B
+    max_tokens: 8192
+    provider_opts:
+      speculative_draft_model: ai/qwen3:0.6B-F16
+      speculative_num_tokens: 16
+      speculative_acceptance_rate: 0.8
+```
+
+## Custom Endpoint
+
+If `base_url` is omitted, Docker Agent auto-discovers the DMR endpoint. To set manually:
+
+```yaml
+models:
+  local:
+    provider: dmr
+    model: ai/qwen3
+    base_url: http://127.0.0.1:12434/engines/llama.cpp/v1
+```
+
+## Troubleshooting
+
+- **Plugin not found:** Ensure Docker Model Runner is enabled in Docker Desktop. Docker Agent will fall back to the default URL.
+- **Endpoint empty:** Verify the Model Runner is running with `docker model status --json`.
+- **Performance:** Use `runtime_flags` to tune GPU layers (`--ngl`) and thread count (`--threads`).
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/fireworks/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/fireworks/index.md
new file mode 100644
index 000000000000..9644653071f8
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/fireworks/index.md
@@ -0,0 +1,102 @@
+---
+title: "Fireworks AI"
+description: "Use Fireworks AI models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, fireworks ai
+weight: 100
+canonical: https://docs.docker.com/ai/docker-agent/providers/fireworks/
+---
+
+_Use Fireworks AI models with Docker Agent._
+
+## Overview
+
+[Fireworks AI](https://fireworks.ai/) is a fast inference host for open-weight
+models, serving Kimi K2, Llama, Qwen, DeepSeek, GLM and others through an
+OpenAI-compatible API. Docker Agent includes built-in support for Fireworks AI
+as an alias provider.
+
+## Setup
+
+1. Create an API key from the [Fireworks dashboard](https://fireworks.ai/account/api-keys).
+2. Set the environment variable:
+
+   ```bash
+   export FIREWORKS_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use Fireworks AI:
+
+```yaml
+agents:
+  root:
+    model: fireworks/accounts/fireworks/models/kimi-k2-instruct
+    description: Assistant using Fireworks AI
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  fireworks_model:
+    provider: fireworks
+    model: accounts/fireworks/models/kimi-k2-instruct
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: fireworks_model
+    description: Assistant using Fireworks AI
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+Fireworks serves a broad, changing catalog of open-weight models. Model IDs use
+the `accounts/fireworks/models/<name>` form. Check the
+[Fireworks model library](https://fireworks.ai/models) for current IDs, context
+limits, and pricing.
+
+| Model | Description |
+| --- | --- |
+| `accounts/fireworks/models/kimi-k2-instruct` | Kimi K2, large open MoE chat and tool-calling model |
+| `accounts/fireworks/models/llama-v3p3-70b-instruct` | Llama 3.3 70B instruct |
+| `accounts/fireworks/models/qwen3-235b-a22b` | Qwen 3 235B MoE |
+
+> Model IDs are case-sensitive and must be passed exactly as the catalogue lists
+> them.
+
+## How It Works
+
+Fireworks AI is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://api.fireworks.ai/inference/v1`
+- **Token Variable:** `FIREWORKS_API_KEY`
+
+Because Fireworks fronts open-weight models whose chat templates may reject more
+than one leading system message, Docker Agent coalesces its per-source system
+messages into a single one for this provider.
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: fireworks/accounts/fireworks/models/kimi-k2-instruct
+    description: Code assistant using Kimi K2 on Fireworks AI
+    instruction: |
+      You are an expert programmer.
+      Write clean, well-documented code and follow language best practices.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/github-copilot/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/github-copilot/index.md
new file mode 100644
index 000000000000..3e4e7c3cd3e5
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/github-copilot/index.md
@@ -0,0 +1,161 @@
+---
+title: "GitHub Copilot"
+description: "Use GitHub Copilot's hosted models (GPT-4o, Claude, Gemini, and more) with Docker Agent through your GitHub subscription."
+keywords: docker agent, ai agents, model providers, llm, github copilot
+weight: 110
+canonical: https://docs.docker.com/ai/docker-agent/providers/github-copilot/
+---
+
+_Use GitHub Copilot's hosted models with Docker Agent through your existing GitHub subscription._
+
+## Overview
+
+GitHub Copilot exposes an OpenAI-compatible Chat Completions API at
+`https://api.githubcopilot.com`. Docker Agent ships with built-in support for
+it as the `github-copilot` provider, so any user with a paid GitHub Copilot
+subscription can reuse their entitlement from Docker Agent.
+
+## Prerequisites
+
+- An active **GitHub Copilot** subscription (Individual, Business, or Enterprise).
+- A **personal access token** with the `copilot` scope, exported as `GITHUB_TOKEN`.
+
+```bash
+export GITHUB_TOKEN="ghp_..."
+```
+
+## Running Evals
+
+Eval cases (`docker agent eval`) run in isolated containers. Unlike dedicated
+provider API keys, `GITHUB_TOKEN` and `GH_TOKEN` are **not** forwarded into
+eval containers automatically, because a GitHub token grants far broader
+access than a model API key. Pass the token explicitly:
+
+```bash
+docker agent eval agent.yaml ./evals -e GITHUB_TOKEN
+```
+
+See [Evaluation](../../features/evaluation/index.md#provider-credentials)
+for details, including behavior with `--env-from-file`.
+
+## Configuration
+
+### Inline
+
+```yaml
+agents:
+  root:
+    model: github-copilot/gpt-4o
+    instruction: You are a helpful assistant.
+```
+
+### Named model
+
+```yaml
+models:
+  copilot:
+    provider: github-copilot
+    model: gpt-4o
+    temperature: 0.7
+    max_tokens: 4000
+
+agents:
+  root:
+    model: copilot
+```
+
+## Available Models
+
+The exact set of models you can call depends on your Copilot plan. The most
+commonly available ones today are:
+
+| Model                    | Best For                            |
+| ------------------------ | ----------------------------------- |
+| `gpt-4o`                 | Multimodal, balanced performance    |
+| `gpt-4o-mini`            | Fast and cheap                      |
+| `claude-sonnet-4`        | Strong coding and analysis          |
+| `gemini-2.5-pro`         | Google's flagship, large context    |
+| `o3-mini`                | Reasoning-focused                   |
+
+Check the
+[GitHub Copilot documentation](https://docs.github.com/en/copilot)
+for the current model list.
+
+## `Copilot-Integration-Id` Header
+
+GitHub's Copilot API rejects requests that don't carry a
+`Copilot-Integration-Id` header with a `Bad Request` error. Docker Agent
+automatically sends `copilot-developer-cli` for the `github-copilot`
+provider, so PAT-based usage works out of the box.
+
+We specifically chose `copilot-developer-cli` (instead of, say,
+`vscode-chat`) because it is the integration id accepted by the Copilot
+API for **both** OAuth tokens and Personal Access Tokens. Most
+Docker Agent users authenticate with a PAT exported as `GITHUB_TOKEN`,
+and `vscode-chat` is rejected for those tokens.
+
+If you need to send a different integration id — for example if your
+organization allows-lists a specific value — you can override it via
+`provider_opts.http_headers`:
+
+```yaml
+models:
+  copilot:
+    provider: github-copilot
+    model: gpt-4o
+    provider_opts:
+      http_headers:
+        Copilot-Integration-Id: my-custom-integration
+```
+
+Header names are matched case-insensitively, so `copilot-integration-id`
+works too.
+
+## Chat Completions vs. Responses API
+
+GitHub Copilot proxies OpenAI models behind two endpoints: the legacy
+`/chat/completions` and the newer `/responses`. Newer models (the `gpt-5`
+family, Codex variants, etc.) are only served via `/responses` and reject
+`/chat/completions` with a `400 Bad Request`. Docker Agent auto-selects the
+right endpoint per model, so no configuration is needed in the common case.
+
+If you ever need to force one or the other, set `api_type` explicitly:
+
+```yaml
+models:
+  copilot:
+    provider: github-copilot
+    model: gpt-5
+    provider_opts:
+      api_type: openai_responses # or openai_chatcompletions
+```
+
+## Custom HTTP Headers
+
+`provider_opts.http_headers` is a generic escape hatch that works for any
+OpenAI-compatible provider, not just GitHub Copilot. Every key/value pair
+is added to every outgoing request:
+
+```yaml
+models:
+  my_model:
+    provider: openai
+    model: gpt-4o
+    provider_opts:
+      http_headers:
+        X-Request-Source: docker-agent
+        X-Tenant-Id: my-team
+```
+
+## How It Works
+
+GitHub Copilot is implemented as a built-in alias in Docker Agent:
+
+- **API type:** OpenAI-compatible (Chat Completions)
+- **Base URL:** `https://api.githubcopilot.com`
+- **Token variable:** `GITHUB_TOKEN`
+- **Default headers:** `Copilot-Integration-Id: copilot-developer-cli`
+
+This means the same client as OpenAI is used, so every OpenAI feature
+supported by Docker Agent (tool calling, structured output, multimodal
+inputs, etc.) is available when the underlying model supports it.
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/google/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/google/index.md
new file mode 100644
index 000000000000..efbb27817169
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/google/index.md
@@ -0,0 +1,174 @@
+---
+title: "Google Gemini"
+description: "Use Gemini 2.5 Flash, Gemini 3 Pro, and other Google models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, google gemini
+weight: 120
+canonical: https://docs.docker.com/ai/docker-agent/providers/google/
+---
+
+_Use Gemini 2.5 Flash, Gemini 3 Pro, and other Google models with Docker Agent._
+
+## Setup
+
+Docker Agent reads the first credential it finds from these environment variables (see `pkg/model/provider/gemini/client.go`):
+
+| Variable                    | Purpose                                                                             |
+| --------------------------- | ----------------------------------------------------------------------------------- |
+| `GOOGLE_API_KEY`            | Primary Gemini API key.                                                             |
+| `GEMINI_API_KEY`            | Alternative name for the Gemini API key (also used by the official Google SDK).     |
+| `GOOGLE_GENAI_USE_VERTEXAI` | When set (any value), routes through Vertex AI instead of the Gemini Developer API. |
+| `GOOGLE_CLOUD_PROJECT`      | GCP project used when `GOOGLE_GENAI_USE_VERTEXAI` is set or for Vertex AI Model Garden. |
+| `GOOGLE_CLOUD_LOCATION`     | GCP region for Vertex AI (defaults to the SDK default).                             |
+
+```bash
+# Gemini Developer API
+export GOOGLE_API_KEY="AI..."   # or GEMINI_API_KEY
+
+# Vertex AI (no API key; uses Application Default Credentials)
+gcloud auth application-default login
+export GOOGLE_GENAI_USE_VERTEXAI=1
+export GOOGLE_CLOUD_PROJECT="my-gcp-project"
+export GOOGLE_CLOUD_LOCATION="us-central1"
+```
+
+## Configuration
+
+### Inline
+
+```yaml
+agents:
+  root:
+    model: google/gemini-3.5-flash
+```
+
+### Named Model
+
+```yaml
+models:
+  gemini:
+    provider: google
+    model: gemini-3.5-flash
+    temperature: 0.5
+```
+
+## Available Models
+
+| Model              | Best For                        |
+| ------------------ | ------------------------------- |
+| `gemini-3-pro`     | Most capable Gemini model       |
+| `gemini-3-flash`   | Fast, efficient, good balance   |
+| `gemini-2.5-flash` | Fast inference, cost-effective  |
+| `gemini-2.5-pro`   | Strong reasoning, large context |
+
+## Thinking Budget
+
+Gemini supports two approaches depending on the model version:
+
+> [!WARNING]
+> **Different thinking formats**
+>
+> Gemini 2.5 uses **token-based** budgets (integers). Gemini 3 uses **level-based** budgets (strings like `low`, `high`). Make sure you use the right format for your model version.
+
+### Gemini 2.5 (Token-based)
+
+```yaml
+models:
+  gemini-no-thinking:
+    provider: google
+    model: gemini-2.5-flash
+    thinking_budget: 0 # disable thinking
+
+  gemini-dynamic:
+    provider: google
+    model: gemini-2.5-flash
+    thinking_budget: -1 # dynamic (model decides) — default
+
+  gemini-fixed:
+    provider: google
+    model: gemini-2.5-flash
+    thinking_budget: 8192 # fixed token budget
+```
+
+### Gemini 3 (Level-based)
+
+```yaml
+models:
+  gemini-3-pro:
+    provider: google
+    model: gemini-3-pro
+    thinking_budget: high # default for Pro: low | high
+
+  gemini-3-flash:
+    provider: google
+    model: gemini-3-flash
+    thinking_budget: medium # default for Flash: minimal | low | medium | high
+```
+
+## Built-in Tools (Grounding)
+
+Gemini models support built-in tools that let the model access Google Search and Google Maps
+directly during generation. Enable them via `provider_opts`:
+
+```yaml
+models:
+  gemini-grounded:
+    provider: google
+    model: gemini-2.5-flash
+    provider_opts:
+      google_search: true
+      google_maps: true
+      code_execution: true
+```
+
+| Option           | Description                                          |
+| ---------------- | ---------------------------------------------------- |
+| `google_search`  | Enables Google Search grounding for up-to-date info  |
+| `google_maps`    | Enables Google Maps grounding for location queries   |
+| `code_execution` | Enables server-side code execution for computations  |
+
+## Vertex AI Model Garden
+
+You can use non-Gemini models (e.g. Claude, Llama) hosted on Google Cloud's
+[Vertex AI Model Garden](https://cloud.google.com/vertex-ai/generative-ai/docs/partner-models/use-partner-models)
+through the `google` provider. When a `publisher` is specified in `provider_opts`,
+requests are routed through the appropriate Vertex AI endpoint instead of the
+Gemini SDK:
+
+- **Anthropic Claude** (`publisher: anthropic`) uses the Anthropic-native
+  `:rawPredict` / `:streamRawPredict` endpoints. Claude models on Vertex AI do
+  not support the OpenAI `/chat/completions` path.
+- **Other publishers** (e.g. `meta`, `mistral`) use Vertex AI's
+  OpenAI-compatible `/chat/completions` endpoint.
+
+### Authentication
+
+Vertex AI uses Google Cloud Application Default Credentials (ADC). Make sure you
+are authenticated:
+
+```bash
+gcloud auth application-default login
+```
+
+### Configuration
+
+```yaml
+models:
+  claude-on-vertex:
+    provider: google
+    model: claude-sonnet-4-20250514
+    provider_opts:
+      project: my-gcp-project       # GCP project ID (or set GOOGLE_CLOUD_PROJECT)
+      location: us-east5             # GCP region (or set GOOGLE_CLOUD_LOCATION)
+      publisher: anthropic           # Model publisher (anthropic, meta, etc.)
+```
+
+| Option      | Description                                                                          |
+| ----------- | ------------------------------------------------------------------------------------ |
+| `project`   | GCP project ID. Falls back to `GOOGLE_CLOUD_PROJECT` env var                         |
+| `location`  | GCP region (e.g. `us-east5`, `us-central1`). Falls back to `GOOGLE_CLOUD_LOCATION`   |
+| `publisher`  | Model publisher (e.g. `anthropic`, `meta`, `mistral`). Must not be `google`          |
+
+> [!NOTE]
+> **Gemini models on Vertex AI**
+>
+> Setting `publisher: google` (or omitting `publisher`) uses the native Gemini SDK path. The Model Garden endpoint is only used for non-Google publishers.
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/groq/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/groq/index.md
new file mode 100644
index 000000000000..4c7d3945581c
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/groq/index.md
@@ -0,0 +1,99 @@
+---
+title: "Groq"
+description: "Use Groq fast-inference models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, groq
+weight: 130
+canonical: https://docs.docker.com/ai/docker-agent/providers/groq/
+---
+
+_Use Groq models with Docker Agent._
+
+## Overview
+
+[Groq](https://groq.com/) serves open-weight models on its LPU inference engine
+through an OpenAI-compatible API, with a focus on very low latency. Docker Agent
+includes built-in support for Groq as an alias provider.
+
+## Setup
+
+1. Create an API key from the [Groq Console](https://console.groq.com/keys).
+2. Set the environment variable:
+
+   ```bash
+   export GROQ_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use Groq:
+
+```yaml
+agents:
+  root:
+    model: groq/llama-3.3-70b-versatile
+    description: Assistant using Groq
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  groq_model:
+    provider: groq
+    model: llama-3.3-70b-versatile
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: groq_model
+    description: Assistant using Groq
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+Groq hosts a rotating catalogue of open-weight models. Check the
+[Groq models documentation](https://console.groq.com/docs/models) for current
+model IDs, context limits, and rate limits.
+
+| Model | Description |
+| --- | --- |
+| `llama-3.3-70b-versatile` | Llama 3.3 70B, reliable general-purpose chat and tool calling |
+| `llama-3.1-8b-instant` | Llama 3.1 8B, fastest and cheapest |
+| `openai/gpt-oss-120b` | GPT-OSS 120B, strong reasoning and tool calling |
+| `openai/gpt-oss-20b` | GPT-OSS 20B, compact reasoning model |
+| `qwen/qwen3-32b` | Qwen3 32B, reasoning and tool calling |
+| `meta-llama/llama-4-scout-17b-16e-instruct` | Llama 4 Scout MoE |
+
+> Model IDs are case-sensitive and must be passed exactly as the catalogue lists
+> them.
+
+## How It Works
+
+Groq is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://api.groq.com/openai/v1`
+- **Token Variable:** `GROQ_API_KEY`
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: groq/llama-3.3-70b-versatile
+    description: Code assistant using Llama 3.3
+    instruction: |
+      You are an expert programmer.
+      Write clean, well-documented code and follow language best practices.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/huggingface/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/huggingface/index.md
new file mode 100644
index 000000000000..8b5860100a71
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/huggingface/index.md
@@ -0,0 +1,101 @@
+---
+title: "Hugging Face"
+description: "Use Hugging Face Inference Providers with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, hugging face
+weight: 140
+canonical: https://docs.docker.com/ai/docker-agent/providers/huggingface/
+---
+
+_Use Hugging Face Inference Providers with Docker Agent._
+
+## Overview
+
+[Hugging Face Inference Providers](https://huggingface.co/docs/inference-providers/index)
+routes requests to open models (Llama, Qwen, DeepSeek, Kimi, GLM and others)
+across many backends through a single OpenAI-compatible endpoint. Docker Agent
+includes built-in support for Hugging Face as an alias provider.
+
+## Setup
+
+1. Create a token from the [Hugging Face token settings](https://huggingface.co/settings/tokens).
+2. Set the environment variable:
+
+   ```bash
+   export HF_TOKEN=your-token
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use Hugging Face:
+
+```yaml
+agents:
+  root:
+    model: huggingface/meta-llama/Llama-3.3-70B-Instruct
+    description: Assistant using Hugging Face Inference Providers
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  huggingface_model:
+    provider: huggingface
+    model: meta-llama/Llama-3.3-70B-Instruct
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: huggingface_model
+    description: Assistant using Hugging Face Inference Providers
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+Hugging Face routes to a broad, changing catalog of open-weight models. Check the
+[Hugging Face models page](https://huggingface.co/models?inference_provider=all)
+for current model IDs, context limits, and pricing.
+
+| Model | Description |
+| --- | --- |
+| `meta-llama/Llama-3.3-70B-Instruct` | Llama 3.3 70B, general-purpose chat and tool calling |
+| `Qwen/Qwen3-235B-A22B` | Qwen3 235B mixture-of-experts instruct model |
+| `deepseek-ai/DeepSeek-V3.2` | DeepSeek, strong coding and reasoning |
+
+> Model IDs are case-sensitive and must be passed exactly as the catalogue lists
+> them.
+
+## How It Works
+
+Hugging Face is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://router.huggingface.co/v1`
+- **Token Variable:** `HF_TOKEN`
+
+Because Hugging Face fronts open-weight models whose chat templates may reject
+more than one leading system message, Docker Agent coalesces its per-source
+system messages into a single one for this provider.
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: huggingface/Qwen/Qwen3-Coder-480B-A35B-Instruct
+    description: Code assistant using Qwen3 Coder on Hugging Face
+    instruction: |
+      You are an expert programmer.
+      Write clean, well-documented code and follow language best practices.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/local/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/local/index.md
new file mode 100644
index 000000000000..c4122a108cdd
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/local/index.md
@@ -0,0 +1,223 @@
+---
+title: "Local Models (Ollama, vLLM, LocalAI)"
+description: "Run Docker Agent with locally hosted models for privacy, offline use, or cost savings."
+keywords: docker agent, ai agents, model providers, llm, local models, ollama, vllm, localai, offline models
+linkTitle: "Local Models"
+weight: 150
+canonical: https://docs.docker.com/ai/docker-agent/providers/local/
+aliases:
+  - /ai/docker-agent/local-models/
+  - /ai/docker-agent/providers/ollama/
+---
+
+_Run Docker Agent with locally hosted models for privacy, offline use, or cost savings._
+
+## Overview
+
+Docker Agent can connect to any OpenAI-compatible local model server. This guide covers the most popular options:
+
+- **Ollama** — Easy-to-use local model runner
+- **vLLM** — High-performance inference server
+- **LocalAI** — OpenAI-compatible API for various backends
+
+> [!TIP]
+> **Docker Model Runner**
+>
+> For the easiest local model experience, consider [Docker Model Runner](../dmr/index.md) which is built into Docker Desktop and requires no additional setup.
+
+## Ollama
+
+Ollama is a popular tool for running LLMs locally. Docker Agent includes a built-in `ollama` alias for easy configuration.
+
+### Setup
+
+1. Install Ollama from [ollama.ai](https://ollama.ai/)
+2. Pull a model:
+
+   ```bash
+   ollama pull llama3.2
+   ollama pull qwen2.5-coder
+   ```
+
+3. Start the Ollama server (usually runs automatically):
+
+   ```bash
+   ollama serve
+   ```
+
+### Configuration
+
+Use the built-in `ollama` alias:
+
+```yaml
+agents:
+  root:
+    model: ollama/llama3.2
+    description: Local assistant
+    instruction: You are a helpful assistant.
+```
+
+The `ollama` alias automatically uses:
+
+- **Base URL:** `http://localhost:11434/v1`
+- **API Type:** OpenAI-compatible
+- **No API key required**
+
+### Custom Port or Host
+
+If Ollama runs on a different host or port:
+
+```yaml
+models:
+  my_ollama:
+    provider: ollama
+    model: llama3.2
+    base_url: http://192.168.1.100:11434/v1
+
+agents:
+  root:
+    model: my_ollama
+    description: Remote Ollama assistant
+    instruction: You are a helpful assistant.
+```
+
+### Popular Ollama Models
+
+| Model            | Size | Best For              |
+| ---------------- | ---- | --------------------- |
+| `llama3.2`       | 3B   | General purpose, fast |
+| `llama3.1`       | 8B   | Better reasoning      |
+| `qwen2.5-coder`  | 7B   | Code generation       |
+| `mistral`        | 7B   | General purpose       |
+| `codellama`      | 7B   | Code tasks            |
+| `deepseek-coder` | 6.7B | Code generation       |
+
+## vLLM
+
+vLLM is a high-performance inference server optimized for throughput.
+
+### Setup
+
+```bash
+# Install vLLM
+pip install vllm
+
+# Start the server
+python -m vllm.entrypoints.openai.api_server \
+  --model meta-llama/Llama-3.2-3B-Instruct \
+  --port 8000
+```
+
+### Configuration
+
+```yaml
+providers:
+  vllm:
+    api_type: openai_chatcompletions
+    base_url: http://localhost:8000/v1
+
+agents:
+  root:
+    model: vllm/meta-llama/Llama-3.2-3B-Instruct
+    description: vLLM-powered assistant
+    instruction: You are a helpful assistant.
+```
+
+## LocalAI
+
+LocalAI provides an OpenAI-compatible API that works with various backends.
+
+### Setup
+
+```bash
+# Run with Docker
+docker run -p 8080:8080 --name local-ai \
+  -v ./models:/models \
+  localai/localai:latest-cpu
+```
+
+### Configuration
+
+```yaml
+providers:
+  localai:
+    api_type: openai_chatcompletions
+    base_url: http://localhost:8080/v1
+
+agents:
+  root:
+    model: localai/gpt4all-j
+    description: LocalAI assistant
+    instruction: You are a helpful assistant.
+```
+
+## Generic Custom Provider
+
+For any OpenAI-compatible server:
+
+```yaml
+providers:
+  my_server:
+    api_type: openai_chatcompletions
+    base_url: http://localhost:8000/v1
+    # token_key: MY_API_KEY  # if auth required
+
+agents:
+  root:
+    model: my_server/model-name
+    description: Custom server assistant
+    instruction: You are a helpful assistant.
+```
+
+## Performance Tips
+
+> [!NOTE]
+> **Local Model Considerations**
+>
+> - **Memory:** Larger models need more RAM/VRAM. A 7B model typically needs 8-16GB RAM.
+> - **GPU:** GPU acceleration dramatically improves speed. Check your server's GPU support.
+> - **Context length:** Local models often have smaller context windows than cloud models.
+> - **Tool calling:** Not all local models support function/tool calling. Test your model's capabilities.
+
+## Example: Offline Development Agent
+
+```yaml
+agents:
+  developer:
+    model: ollama/qwen2.5-coder
+    description: Offline code assistant
+    instruction: |
+      You are a software developer working offline.
+      Focus on code quality and clear explanations.
+    max_iterations: 20
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+      - type: todo
+```
+
+## Troubleshooting
+
+### Connection Refused
+
+Ensure your model server is running and accessible:
+
+```bash
+curl http://localhost:11434/v1/models  # Ollama
+curl http://localhost:8000/v1/models   # vLLM
+```
+
+### Model Not Found
+
+Verify the model is downloaded/available:
+
+```bash
+ollama list  # List available Ollama models
+```
+
+### Slow Responses
+
+- Check if GPU acceleration is enabled
+- Try a smaller model
+- Reduce `max_tokens` in your config
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/minimax/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/minimax/index.md
new file mode 100644
index 000000000000..e6eeac606e38
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/minimax/index.md
@@ -0,0 +1,92 @@
+---
+title: "MiniMax"
+description: "Use MiniMax AI models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, minimax
+weight: 160
+canonical: https://docs.docker.com/ai/docker-agent/providers/minimax/
+---
+
+_Use MiniMax AI models with Docker Agent._
+
+## Overview
+
+MiniMax provides AI models through an OpenAI-compatible API. Docker Agent includes built-in support for MiniMax as an alias provider.
+
+## Setup
+
+1. Get an API key from [MiniMax](https://www.minimaxi.com/)
+2. Set the environment variable:
+
+   ```bash
+   export MINIMAX_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use MiniMax:
+
+```yaml
+agents:
+  root:
+    model: minimax/MiniMax-M2.5
+    description: Assistant using MiniMax
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  minimax_model:
+    provider: minimax
+    model: MiniMax-M2.5
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: minimax_model
+    description: Assistant using MiniMax
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+Check the [MiniMax documentation](https://www.minimaxi.com/document/introduction) for the current model catalog.
+
+| Model                    | Description                                     |
+| ------------------------ | ----------------------------------------------- |
+| `MiniMax-M2.5`           | Peak performance, 204K context                  |
+| `MiniMax-M2.5-highspeed` | Same as M2.5 but faster (~100 tps)              |
+| `MiniMax-M2.1`           | Multi-language programming capabilities         |
+| `MiniMax-M2.1-highspeed` | Faster variant of M2.1 (~100 tps)               |
+| `MiniMax-M2`             | Agentic capabilities, advanced reasoning        |
+
+## How It Works
+
+MiniMax is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai`)
+- **Base URL:** `https://api.minimax.io/v1`
+- **Token Variable:** `MINIMAX_API_KEY`
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: minimax/MiniMax-M2.5
+    description: Code assistant using MiniMax
+    instruction: |
+      You are an expert programmer using MiniMax M2.5.
+      Write clean, well-documented code.
+      Follow best practices for the language being used.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/mistral/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/mistral/index.md
new file mode 100644
index 000000000000..7e40916d53c6
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/mistral/index.md
@@ -0,0 +1,106 @@
+---
+title: "Mistral"
+description: "Use Mistral AI models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, mistral
+weight: 170
+canonical: https://docs.docker.com/ai/docker-agent/providers/mistral/
+---
+
+_Use Mistral AI models with Docker Agent._
+
+## Overview
+
+Mistral AI provides powerful language models through an OpenAI-compatible API. Docker Agent includes built-in support for Mistral as an alias provider.
+
+## Setup
+
+1. Get an API key from [Mistral Console](https://console.mistral.ai/)
+2. Set the environment variable:
+
+   ```bash
+   export MISTRAL_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use Mistral:
+
+```yaml
+agents:
+  root:
+    model: mistral/mistral-large-latest
+    description: Assistant using Mistral
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  mistral:
+    provider: mistral
+    model: mistral-large-latest
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: mistral
+    description: Assistant using Mistral
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+| Model                   | Description                       | Context |
+| ----------------------- | --------------------------------- | ------- |
+| `mistral-large-latest`  | Most capable Mistral model        | 128K    |
+| `mistral-medium-latest` | Balanced performance and cost     | 128K    |
+| `mistral-small-latest`  | Fast and cost-effective (default) | 128K    |
+| `codestral-latest`      | Optimized for code generation     | 32K     |
+| `open-mistral-nemo`     | Open-weight model                 | 128K    |
+| `ministral-8b-latest`   | Compact 8B parameter model        | 128K    |
+| `ministral-3b-latest`   | Smallest Mistral model            | 128K    |
+
+Check the [Mistral Models documentation](https://docs.mistral.ai/getting-started/models/) for the latest available models.
+
+## Auto-Detection
+
+When you run `docker agent run` without specifying a config and no project-level `docker-agent.yaml`, `docker-agent.yml`, or `docker-agent.hcl` exists, Docker Agent automatically detects available providers. If `MISTRAL_API_KEY` is set and higher-priority providers (OpenAI, Anthropic, Google) are not available, Mistral will be used with `mistral-small-latest` as the default model.
+
+## Extended Thinking
+
+Docker Agent's `thinking_budget` field is **not applied** to Mistral models: the underlying OpenAI-compatible client only sends `reasoning_effort` for OpenAI reasoning model names (o-series, gpt-5). Setting `thinking_budget` on a Mistral model passes config validation but has no effect on the request.
+
+Mistral reasoning models (e.g. `magistral`) reason on their own without configuration. For non-reasoning models, use the [think tool](../../tools/think/index.md) instead.
+
+## How It Works
+
+Mistral is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://api.mistral.ai/v1`
+- **Token Variable:** `MISTRAL_API_KEY`
+
+This means Mistral uses the same client as OpenAI, making it fully compatible with all OpenAI features supported by Docker Agent.
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: mistral/codestral-latest
+    description: Expert code assistant
+    instruction: |
+      You are an expert programmer using Codestral.
+      Write clean, efficient, well-documented code.
+      Explain your reasoning when helpful.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/moonshot/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/moonshot/index.md
new file mode 100644
index 000000000000..f370592b492d
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/moonshot/index.md
@@ -0,0 +1,97 @@
+---
+title: "Moonshot AI"
+description: "Use Moonshot AI (Kimi) models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, moonshot ai
+weight: 180
+canonical: https://docs.docker.com/ai/docker-agent/providers/moonshot/
+---
+
+_Use Moonshot AI (Kimi) models with Docker Agent._
+
+## Overview
+
+[Moonshot AI](https://www.moonshot.ai/) serves its Kimi model family through an
+OpenAI-compatible API. The Kimi K2 models have strong momentum for coding and
+agentic tasks. Docker Agent includes built-in support for Moonshot AI as an
+alias provider.
+
+## Setup
+
+1. Create an API key from the [Moonshot AI console](https://platform.moonshot.ai/console/api-keys).
+2. Set the environment variable:
+
+   ```bash
+   export MOONSHOT_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use Moonshot AI:
+
+```yaml
+agents:
+  root:
+    model: moonshot/kimi-k2-0905-preview
+    description: Assistant using Moonshot AI
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  moonshot_model:
+    provider: moonshot
+    model: kimi-k2-0905-preview
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: moonshot_model
+    description: Assistant using Moonshot AI
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+Moonshot AI exposes a vendor-controlled Kimi model lineup. Check the
+[Moonshot API documentation](https://platform.moonshot.ai/docs/api) for current
+model IDs, context limits, and pricing.
+
+| Model | Description |
+| --- | --- |
+| `kimi-k2-0905-preview` | Kimi K2, general-purpose chat, coding, and tool calling |
+| `kimi-k2-turbo-preview` | Kimi K2 optimized for higher throughput |
+| `kimi-k2-thinking` | Kimi K2 extended-reasoning model |
+
+> Model IDs are case-sensitive and must be passed exactly as the catalogue lists
+> them.
+
+## How It Works
+
+Moonshot AI is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://api.moonshot.ai/v1`
+- **Token Variable:** `MOONSHOT_API_KEY`
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: moonshot/kimi-k2-0905-preview
+    description: Code assistant using Kimi K2
+    instruction: |
+      You are an expert programmer.
+      Write clean, well-documented code and follow language best practices.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/nebius/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/nebius/index.md
new file mode 100644
index 000000000000..deadbaaea4b3
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/nebius/index.md
@@ -0,0 +1,90 @@
+---
+title: "Nebius"
+description: "Use Nebius AI models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, nebius
+weight: 190
+canonical: https://docs.docker.com/ai/docker-agent/providers/nebius/
+---
+
+_Use Nebius AI models with Docker Agent._
+
+## Overview
+
+Nebius provides AI models through an OpenAI-compatible API. Docker Agent includes built-in support for Nebius as an alias provider.
+
+## Setup
+
+1. Get an API key from [Nebius AI](https://nebius.ai/)
+2. Set the environment variable:
+
+   ```bash
+   export NEBIUS_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use Nebius:
+
+```yaml
+agents:
+  root:
+    model: nebius/deepseek-ai/DeepSeek-V3
+    description: Assistant using Nebius
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  nebius_model:
+    provider: nebius
+    model: deepseek-ai/DeepSeek-V3
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: nebius_model
+    description: Assistant using Nebius
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+Nebius hosts various open models. Check the [Nebius documentation](https://nebius.ai/docs) for the current model catalog.
+
+| Model                               | Description                     |
+| ----------------------------------- | ------------------------------- |
+| `deepseek-ai/DeepSeek-V3`           | DeepSeek V3 model               |
+| `Qwen/Qwen2.5-72B-Instruct`         | Qwen 2.5 72B instruction-tuned  |
+| `meta-llama/Llama-3.3-70B-Instruct` | Llama 3.3 70B instruction-tuned |
+
+## How It Works
+
+Nebius is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://api.studio.nebius.com/v1`
+- **Token Variable:** `NEBIUS_API_KEY`
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: nebius/deepseek-ai/DeepSeek-V3
+    description: Code assistant using DeepSeek
+    instruction: |
+      You are an expert programmer using DeepSeek V3.
+      Write clean, well-documented code.
+      Follow best practices for the language being used.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/nvidia/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/nvidia/index.md
new file mode 100644
index 000000000000..330dad99f0bd
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/nvidia/index.md
@@ -0,0 +1,115 @@
+---
+title: "NVIDIA NIM"
+description: "Use NVIDIA NIM models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, nvidia, nim, nemotron
+weight: 290
+canonical: https://docs.docker.com/ai/docker-agent/providers/nvidia/
+---
+
+_Use NVIDIA NIM models with Docker Agent._
+
+## Overview
+
+NVIDIA provides access to Nemotron and many other open-weight models through
+[build.nvidia.com](https://build.nvidia.com/) (with a free tier) via an
+OpenAI-compatible API. Docker Agent includes built-in support for NVIDIA as an
+alias provider. The same alias also works against a self-hosted
+[NVIDIA NIM](https://docs.nvidia.com/nim/) deployment by overriding `base_url`.
+
+## Setup
+
+1. Get an API key from [build.nvidia.com](https://build.nvidia.com/)
+2. Set the environment variable:
+
+   ```bash
+   export NVIDIA_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use NVIDIA NIM:
+
+```yaml
+agents:
+  root:
+    model: nvidia/nvidia/nemotron-3-super-120b-a12b
+    description: Assistant using NVIDIA NIM
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  nemotron:
+    provider: nvidia
+    model: nvidia/nemotron-3-super-120b-a12b
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: nemotron
+    description: Assistant using NVIDIA NIM
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+NVIDIA NIM hosts Nemotron alongside many other open models (Llama, Qwen,
+DeepSeek, Mistral, ...). Check the [NVIDIA API catalog](https://build.nvidia.com/)
+for the current model list.
+
+| Model                                       | Description                       |
+| -------------------------------------------- | ---------------------------------- |
+| `nvidia/nemotron-3-super-120b-a12b`         | Nemotron 3 Super, reasoning + tool calling |
+| `nvidia/nemotron-3-nano-30b-a3b`            | Nemotron 3 Nano, smaller/faster    |
+| `meta/llama-3.3-70b-instruct`               | Llama 3.3 70B instruction-tuned    |
+| `qwen/qwen3-coder-480b-a35b-instruct`       | Qwen3 Coder, code-focused          |
+
+## On-Prem / Self-Hosted NIM
+
+For self-hosted NIM deployments, point `base_url` at your own endpoint instead
+of the hosted `integrate.api.nvidia.com` API:
+
+```yaml
+models:
+  local_nim:
+    provider: nvidia
+    model: meta/llama-3.3-70b-instruct
+    base_url: http://localhost:8000/v1
+```
+
+## How It Works
+
+NVIDIA is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://integrate.api.nvidia.com/v1`
+- **Token Variable:** `NVIDIA_API_KEY`
+
+Because NIM fronts open-weight models whose chat templates often only accept
+a single system message, Docker Agent coalesces the agent instruction and any
+toolset instructions into one leading system message before sending the
+request.
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: nvidia/nvidia/nemotron-3-super-120b-a12b
+    description: Code assistant using Nemotron
+    instruction: |
+      You are an expert programmer using NVIDIA Nemotron.
+      Write clean, well-documented code.
+      Follow best practices for the language being used.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/openai/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/openai/index.md
new file mode 100644
index 000000000000..abd11c54fbe8
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/openai/index.md
@@ -0,0 +1,138 @@
+---
+title: "OpenAI"
+description: "Use GPT-5.6, GPT-4o, GPT-5, GPT-5-mini, and other OpenAI models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, openai
+weight: 200
+canonical: https://docs.docker.com/ai/docker-agent/providers/openai/
+---
+
+_Use GPT-5.6, GPT-4o, GPT-5, GPT-5-mini, and other OpenAI models with Docker Agent._
+
+## Setup
+
+```bash
+# Set your API key
+export OPENAI_API_KEY="sk-..."
+```
+
+> [!TIP]
+> No API key? A ChatGPT Plus/Pro/Business subscription can be used instead
+> through the [`chatgpt` provider](../chatgpt/index.md): sign in once with
+> `docker agent setup` (pick chatgpt).
+
+## Configuration
+
+### Inline
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5.6
+```
+
+### Named Model
+
+```yaml
+models:
+  gpt:
+    provider: openai
+    model: gpt-5.6
+    max_tokens: 4000
+```
+
+## Available Models
+
+| Model            | Best For                                             |
+| ---------------- | ----------------------------------------------------- |
+| `gpt-5.6`         | Alias for `gpt-5.6-sol`; tracks the flagship model    |
+| `gpt-5.6-sol`     | Frontier model, most capable, complex reasoning       |
+| `gpt-5.6-terra`   | Everyday workhorse; successor to the `-mini` tier     |
+| `gpt-5.6-luna`    | High-volume, cost-efficient; successor to `-nano` tier |
+| `gpt-5`           | Previous-generation flagship                          |
+| `gpt-5-mini`      | Previous-generation fast, cost-effective model        |
+| `gpt-4o`          | Multimodal, balanced performance                      |
+| `gpt-4o-mini`     | Cheapest, fast for simple tasks                       |
+
+Starting with GPT-5.6, OpenAI renamed the `-mini`/`-nano` size tiers to `-terra`/`-luna` (with `-sol` denoting the frontier tier previously left unsuffixed).
+
+Find more model names at [modelnames.ai](https://modelnames.ai/) or in the [official OpenAI docs](https://platform.openai.com/docs/models).
+
+## Thinking Budget
+
+OpenAI reasoning models (o-series, gpt-5, gpt-5-mini, gpt-5.6 family) support extended thinking through the `reasoning_effort` API parameter. Set `thinking_budget` to control the effort level:
+
+```yaml
+models:
+  gpt-thinker:
+    provider: openai
+    model: gpt-5.6
+    thinking_budget: high   # none | minimal | low | medium | high | xhigh | max
+```
+
+**Effort levels:**
+
+| Level     | Description                                              |
+| --------- | -------------------------------------------------------- |
+| `none`    | No reasoning. On `gpt-5.6`+ this is a real API value that is sent as-is; on older models it just disables the local `thinking_budget` (the API's own default still applies). |
+| `minimal` | Fastest; lightest reasoning pass. Not accepted on `gpt-5.6`+ (dropped from the API). |
+| `low`     | Quick reasoning for straightforward tasks.               |
+| `medium`  | Balanced default.                                        |
+| `high`    | More thorough; recommended for complex tasks.            |
+| `xhigh`   | Near-maximum effort; slower but most accurate. Requires `gpt-5.2`+. |
+| `max`     | Maximum effort. Requires `gpt-5.6`+ (Sol/Terra/Luna).    |
+
+Token counts, `adaptive`, and `adaptive/<effort>` are rejected with a configuration error at request time. Older models (o1, o3-mini) only accept `low`/`medium`/`high`; `xhigh` requires `gpt-5.2`+; `none` and `max` require `gpt-5.6`+; `minimal` is not accepted on `gpt-5.6`+.
+
+> [!WARNING]
+> **Hidden reasoning tokens**
+>
+> OpenAI reasoning models always produce hidden reasoning tokens that count against `max_tokens` — even with `thinking_budget: none` on older models. Docker Agent automatically raises the output-token floor for its internal low-effort calls so reasoning cannot starve visible text output.
+
+See the [Thinking / Reasoning guide](../../guides/thinking/index.md) for a cross-provider overview.
+
+> [!TIP]
+> **Custom endpoints**
+>
+> Use `base_url` for proxies and OpenAI-compatible services. See [Custom Providers](../custom/index.md) for full setup.
+
+## Custom Endpoint
+
+Use `base_url` to connect to OpenAI-compatible APIs:
+
+```yaml
+models:
+  custom:
+    provider: openai
+    model: gpt-5-mini
+    base_url: https://your-proxy.example.com/v1
+```
+
+## WebSocket Transport
+
+For OpenAI Responses API models (gpt-4.1+, o-series, gpt-5), you can use WebSocket streaming instead of the default SSE (Server-Sent Events):
+
+```yaml
+models:
+  fast-gpt:
+    provider: openai
+    model: gpt-4.1
+    provider_opts:
+      transport: websocket  # Use WebSocket instead of SSE
+```
+
+### Benefits
+
+- **~40% faster** for workflows with 20+ tool calls
+- **Persistent connection** reduces per-turn overhead
+- **Server-side caching** of connection state
+- **Automatic fallback** to SSE if WebSocket fails
+
+### Requirements
+
+- Only works with Responses API models: `gpt-4.1+`, `o1`, `o3`, `o4`, `gpt-5`
+- NOT compatible with the `--models-gateway` flag (automatically falls back to SSE when a gateway is configured)
+- Requires `OPENAI_API_KEY` environment variable
+
+### Example
+
+See [`examples/websocket_transport.yaml`](https://github.com/docker/docker-agent/blob/main/examples/websocket_transport.yaml) for a complete example.
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/opencode-go/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/opencode-go/index.md
new file mode 100644
index 000000000000..69199c31f557
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/opencode-go/index.md
@@ -0,0 +1,160 @@
+---
+title: "OpenCode Go"
+description: "Use OpenCode Go models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, opencode go
+weight: 210
+canonical: https://docs.docker.com/ai/docker-agent/providers/opencode-go/
+---
+
+_Use OpenCode Go models with Docker Agent._
+
+## Overview
+
+[OpenCode Go](https://opencode.ai/docs/go) is a low-cost subscription service ($5 first month, then $10/month) that provides reliable access to popular open-source coding models. It serves models through both OpenAI-compatible and Anthropic-compatible APIs from globally distributed endpoints.
+
+Docker Agent includes built-in support for OpenCode Go as an alias provider.
+
+## Setup
+
+1. Subscribe to OpenCode Go at [opencode.ai/auth](https://opencode.ai/auth)
+2. Copy your API key from the console
+3. Set the environment variable:
+
+   ```bash
+   export OPENCODE_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use OpenCode Go:
+
+```yaml
+agents:
+  root:
+    model: opencode-go/deepseek-v4-flash
+    description: Assistant using OpenCode Go
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  my_model:
+    provider: opencode-go
+    model: deepseek-v4-pro
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: my_model
+    description: Assistant using OpenCode Go
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+You can retrieve the full, up-to-date model list at any time:
+
+```bash
+curl https://opencode.ai/zen/go/v1/models
+```
+
+### OpenAI-Compatible
+
+These models use the `/v1/chat/completions` endpoint and work directly with the `opencode-go` alias:
+
+| Model               | Description                           |
+| ------------------- | ------------------------------------- |
+| `deepseek-v4-flash` | Fast and cost-effective DeepSeek model |
+| `deepseek-v4-pro`   | Most capable DeepSeek model           |
+| `kimi-k2.7-code`    | Kimi K2.7 optimized for code          |
+| `kimi-k2.6`         | Kimi K2.6 model                       |
+| `kimi-k2.5`         | Kimi K2.5 model                       |
+| `glm-5.2`           | GLM 5.2 flagship model                |
+| `glm-5.1`           | GLM 5.1 model                         |
+| `glm-5`             | GLM 5 model                           |
+| `mimo-v2.5`         | MiMo V2.5 efficient model             |
+| `mimo-v2.5-pro`     | MiMo V2.5 Pro model                   |
+| `mimo-v2-pro`       | MiMo V2 Pro model                     |
+| `mimo-v2-omni`      | MiMo V2 Omni model                    |
+| `hy3-preview`       | HY3 preview model                     |
+
+### Anthropic-Compatible
+
+These models use the `/v1/messages` endpoint and require a [custom provider definition](../custom/index.md):
+
+| Model             | Description              |
+| ----------------- | ------------------------ |
+| `minimax-m3`      | MiniMax M3 model         |
+| `minimax-m2.7`    | MiniMax M2.7 model       |
+| `minimax-m2.5`    | MiniMax M2.5 model       |
+| `qwen3.7-max`     | Qwen 3.7 Max model       |
+| `qwen3.7-plus`    | Qwen 3.7 Plus model      |
+| `qwen3.6-plus`    | Qwen 3.6 Plus model      |
+| `qwen3.5-plus`    | Qwen 3.5 Plus model      |
+
+To use an Anthropic-compatible model, define a custom provider:
+
+```yaml
+providers:
+  opengo-ant:
+    provider: anthropic
+    base_url: https://opencode.ai/zen/go
+    token_key: OPENCODE_API_KEY
+
+models:
+  qwen:
+    provider: opengo-ant
+    model: qwen3.7-max
+
+agents:
+  root:
+    model: qwen
+    description: Assistant using Qwen through OpenCode Go
+    instruction: You are a helpful assistant.
+```
+
+## How It Works
+
+OpenCode Go is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://opencode.ai/zen/go/v1`
+- **Token Variable:** `OPENCODE_API_KEY`
+
+This means OpenCode Go uses the same client as OpenAI, making it fully compatible with all OpenAI features supported by Docker Agent.
+
+For Anthropic-compatible models (MiniMax, Qwen), Docker Agent uses a custom provider pointing to the Anthropic client at `https://opencode.ai/zen/go` with the same token.
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: opencode-go/deepseek-v4-flash
+    description: Expert code assistant
+    instruction: |
+      You are an expert programmer using DeepSeek V4 Flash.
+      Write clean, efficient, well-documented code.
+      Explain your reasoning when helpful.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
+
+## Usage Limits
+
+OpenCode Go subscriptions include the following limits:
+
+- **5-hour rolling limit** — $12 of usage
+- **Weekly limit** — $30 of usage
+- **Monthly limit** — $60 of usage
+
+Limits are defined as dollar values. More expensive models allow fewer requests per limit period. You can also [add Zen balance](https://opencode.ai/auth) to continue usage beyond the limits.
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/opencode-zen/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/opencode-zen/index.md
new file mode 100644
index 000000000000..dc765cfd43f1
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/opencode-zen/index.md
@@ -0,0 +1,224 @@
+---
+title: "OpenCode Zen"
+description: "Use OpenCode Zen models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, opencode zen
+weight: 220
+canonical: https://docs.docker.com/ai/docker-agent/providers/opencode-zen/
+---
+
+_Use OpenCode Zen models with Docker Agent._
+
+## Overview
+
+[OpenCode Zen](https://opencode.ai/docs/zen) is a curated gateway of tested and verified AI models provided by the OpenCode team. It offers pay-per-use access to a wide range of models — from GPT and Claude to open-source models — all through a single API key. Several free models are also available.
+
+Docker Agent includes built-in support for OpenCode Zen as an alias provider for OpenAI-compatible models. Anthropic and Google models are supported via custom provider definitions.
+
+## Setup
+
+1. Sign in to [OpenCode Zen](https://opencode.ai/auth), add billing information, and copy your API key
+2. Set the environment variable:
+
+   ```bash
+   export OPENCODE_API_KEY=your-api-key
+   ```
+
+3. Verify available models:
+
+   ```bash
+   curl https://opencode.ai/zen/v1/models
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use OpenCode Zen with a free model:
+
+```yaml
+agents:
+  root:
+    model: opencode-zen/deepseek-v4-flash-free
+    description: Assistant using OpenCode Zen (free)
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  zen_model:
+    provider: opencode-zen
+    model: gpt-5.5
+    temperature: 0.7
+    max_tokens: 16384
+
+agents:
+  root:
+    model: zen_model
+    description: Assistant using OpenCode Zen
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+### Free Models
+
+These models are available at no cost:
+
+| Model                     | Description                        |
+| ------------------------- | ---------------------------------- |
+| `deepseek-v4-flash-free`  | Free DeepSeek V4 Flash             |
+| `mimo-v2.5-free`          | Free MiMo V2.5 model               |
+| `qwen3.6-plus-free`       | Free Qwen 3.6 Plus model           |
+| `minimax-m3-free`         | Free MiniMax M3 model              |
+| `nemotron-3-ultra-free`   | Free Nemotron 3 Ultra model        |
+| `north-mini-code-free`    | Free North Mini Code model         |
+| `big-pickle`              | Free stealth model                 |
+
+### OpenAI-Compatible (Chat Completions)
+
+These models use the `/v1/chat/completions` endpoint and work directly with the `opencode-zen` alias:
+
+| Model                 | Description                        |
+| --------------------- | ---------------------------------- |
+| `deepseek-v4-pro`     | DeepSeek V4 Pro model              |
+| `deepseek-v4-flash`   | Fast DeepSeek V4 model             |
+| `glm-5.2`             | GLM 5.2 model                      |
+| `glm-5.1`             | GLM 5.1 model                      |
+| `glm-5`               | GLM 5 model                        |
+| `kimi-k2.6`           | Kimi K2.6 model                    |
+| `kimi-k2.5`           | Kimi K2.5 model                    |
+| `minimax-m2.7`        | MiniMax M2.7 model                 |
+| `minimax-m2.5`        | MiniMax M2.5 model                 |
+| `grok-build-0.1`      | Grok Build 0.1 model               |
+
+### OpenAI-Compatible (Responses API)
+
+These models use the `/v1/responses` endpoint and are auto-detected by Docker Agent based on the model name:
+
+| Model                  | Description                       |
+| ---------------------- | --------------------------------- |
+| `gpt-5.5`              | Latest GPT model                  |
+| `gpt-5.5-pro`          | GPT 5.5 Pro, highest capability   |
+| `gpt-5.4`              | GPT 5.4 model                     |
+| `gpt-5.4-pro`          | GPT 5.4 Pro model                 |
+| `gpt-5.4-mini`         | GPT 5.4 Mini model                |
+| `gpt-5.4-nano`         | GPT 5.4 Nano, fastest             |
+| `gpt-5.3-codex`        | GPT 5.3 Codex for coding          |
+| `gpt-5.3-codex-spark`  | GPT 5.3 Codex Spark               |
+| `gpt-5.2`              | GPT 5.2 model                     |
+| `gpt-5.2-codex`        | GPT 5.2 Codex                     |
+| `gpt-5.1`              | GPT 5.1 model                     |
+| `gpt-5.1-codex`        | GPT 5.1 Codex                     |
+| `gpt-5.1-codex-max`    | GPT 5.1 Codex Max                 |
+| `gpt-5.1-codex-mini`   | GPT 5.1 Codex Mini                |
+| `gpt-5`                | GPT 5 model                       |
+| `gpt-5-codex`          | GPT 5 Codex                       |
+| `gpt-5-nano`           | GPT 5 Nano                        |
+
+### Anthropic-Compatible (Messages API)
+
+These models use the `/v1/messages` endpoint and require a [custom provider definition](../custom/index.md):
+
+| Model                   | Description                   |
+| ----------------------- | ----------------------------- |
+| `claude-fable-5`        | Claude Fable 5 model          |
+| `claude-opus-4-8`       | Claude Opus 4.8 model         |
+| `claude-opus-4-7`       | Claude Opus 4.7 model         |
+| `claude-opus-4-6`       | Claude Opus 4.6 model         |
+| `claude-opus-4-5`       | Claude Opus 4.5 model         |
+| `claude-opus-4-1`       | Claude Opus 4.1 model         |
+| `claude-sonnet-4-6`     | Claude Sonnet 4.6 model       |
+| `claude-sonnet-4-5`     | Claude Sonnet 4.5 model       |
+| `claude-sonnet-4`       | Claude Sonnet 4 model         |
+| `claude-haiku-4-5`      | Claude Haiku 4.5 model        |
+| `qwen3.7-max`           | Qwen 3.7 Max model            |
+| `qwen3.7-plus`          | Qwen 3.7 Plus model           |
+| `qwen3.6-plus`          | Qwen 3.6 Plus model           |
+| `qwen3.5-plus`          | Qwen 3.5 Plus model           |
+
+To use an Anthropic-compatible model:
+
+```yaml
+providers:
+  opencode-zen-claude:
+    provider: anthropic
+    base_url: https://opencode.ai/zen
+    token_key: OPENCODE_API_KEY
+
+models:
+  claude:
+    provider: opencode-zen-claude
+    model: claude-sonnet-4-5
+
+agents:
+  root:
+    model: claude
+    description: Assistant using Claude through OpenCode Zen
+    instruction: You are a helpful assistant.
+```
+
+### Google-Compatible
+
+These models require a [custom provider definition](../custom/index.md) with a Google-compatible client:
+
+| Model               | Description              |
+| ------------------- | ------------------------ |
+| `gemini-3.5-flash`  | Gemini 3.5 Flash model   |
+| `gemini-3.1-pro`    | Gemini 3.1 Pro model     |
+| `gemini-3-flash`    | Gemini 3 Flash model     |
+
+To use a Google model:
+
+```yaml
+providers:
+  opencode-zen-gemini:
+    provider: google
+    base_url: https://opencode.ai/zen
+    token_key: OPENCODE_API_KEY
+
+models:
+  gemini:
+    provider: opencode-zen-gemini
+    model: gemini-3.5-flash
+
+agents:
+  root:
+    model: gemini
+    description: Assistant using Gemini through OpenCode Zen
+    instruction: You are a helpful assistant.
+```
+
+## How It Works
+
+OpenCode Zen is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (auto-detects Responses API for GPT models, Chat Completions for others)
+- **Base URL:** `https://opencode.ai/zen/v1`
+- **Token Variable:** `OPENCODE_API_KEY`
+
+The same API key works for both OpenCode Go and OpenCode Zen — they are part of the same platform. Zen uses a pay-per-use billing model, while Go uses a fixed subscription.
+
+For Anthropic-compatible models, Docker Agent uses a custom provider pointing to the Anthropic client at `https://opencode.ai/zen` with the same token. For Google models, a custom provider points to the Google client at `https://opencode.ai/zen` (the Google SDK appends its own `/v1beta/models/...` path segment).
+
+### Differences from OpenCode Go
+
+| Aspect | OpenCode Zen | OpenCode Go |
+|--------|-------------|-------------|
+| Billing | Pay-per-use | $10/month subscription |
+| Models | GPT-5.x, Claude, Gemini, open-source | Open-source only |
+| Free models | Yes (7 models) | No |
+| Base URL | `https://opencode.ai/zen/v1` | `https://opencode.ai/zen/go/v1` |
+
+## Usage Limits and Pricing
+
+OpenCode Zen uses a pay-per-use model. See the [OpenCode Zen documentation](https://opencode.ai/docs/zen) for current pricing. Automatic top-up and monthly usage limits are available from the console.
+
+You can retrieve the full model catalog at any time:
+
+```bash
+curl https://opencode.ai/zen/v1/models
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/openrouter/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/openrouter/index.md
new file mode 100644
index 000000000000..b01d40211ef8
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/openrouter/index.md
@@ -0,0 +1,88 @@
+---
+title: "OpenRouter"
+description: "Use OpenRouter models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, openrouter
+weight: 230
+canonical: https://docs.docker.com/ai/docker-agent/providers/openrouter/
+---
+
+_Use OpenRouter models with Docker Agent._
+
+## Overview
+
+OpenRouter provides access to models from many providers through an OpenAI-compatible API. Docker Agent includes built-in support for OpenRouter as an alias provider.
+
+## Setup
+
+1. Get an API key from [OpenRouter](https://openrouter.ai/settings/keys)
+2. Set the environment variable:
+
+   ```bash
+   export OPENROUTER_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use OpenRouter:
+
+```yaml
+agents:
+  root:
+    model: openrouter/meta-llama/llama-3.3-70b-instruct
+    description: Assistant using OpenRouter
+    instruction: You are a helpful assistant.
+```
+
+OpenRouter model IDs usually include the upstream provider name, such as `anthropic/claude-sonnet-4-5` or `meta-llama/llama-3.3-70b-instruct`. Docker Agent splits only the first slash, so the full upstream model ID is preserved.
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  openrouter_llama:
+    provider: openrouter
+    model: meta-llama/llama-3.3-70b-instruct
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: openrouter_llama
+    description: Assistant using OpenRouter
+    instruction: You are a helpful assistant.
+```
+
+## Pricing and Model Metadata
+
+Docker Agent fetches OpenRouter model metadata from [models.dev](https://models.dev/), including pricing per 1M input/output tokens, cache pricing when available, context limits, output limits, and modalities. This powers cost tracking and the model picker in the same way as other first-class providers.
+
+If models.dev is unavailable, Docker Agent falls back to its embedded catalog snapshot.
+
+## How It Works
+
+OpenRouter is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai`)
+- **Base URL:** `https://openrouter.ai/api/v1`
+- **Token Variable:** `OPENROUTER_API_KEY`
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: openrouter/meta-llama/llama-3.3-70b-instruct
+    description: Code assistant using OpenRouter
+    instruction: |
+      You are an expert programmer.
+      Write clean, maintainable code.
+      Explain trade-offs when helpful.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/overview/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/overview/index.md
new file mode 100644
index 000000000000..662ca2a43043
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/overview/index.md
@@ -0,0 +1,104 @@
+---
+title: "Model Providers"
+description: "Docker Agent supports multiple AI model providers. Choose the right one for your use case, or use multiple providers in the same configuration."
+keywords: docker agent, ai agents, model providers, llm
+linkTitle: "Overview"
+weight: 10
+canonical: https://docs.docker.com/ai/docker-agent/providers/overview/
+aliases:
+  - /ai/docker-agent/model-providers/
+---
+
+_Docker Agent supports multiple AI model providers. Choose the right one for your use case, or use multiple providers in the same configuration._
+
+## Supported Providers
+
+- [**OpenAI**](../openai/index.md) — GPT-5, GPT-5-mini, GPT-4o. The most widely used AI models.
+- [**Anthropic**](../anthropic/index.md) — Claude Sonnet 4.5, Claude Opus 4.7. Excellent for coding and analysis.
+- [**Google Gemini**](../google/index.md) — Gemini 2.5 Flash, Gemini 3 Pro. Fast and cost-effective.
+- [**AWS Bedrock**](../bedrock/index.md) — access Claude, Nova, Llama, and more through AWS infrastructure.
+- [**Docker Model Runner**](../dmr/index.md) — run models locally with Docker. No API keys, no costs.
+- [**Local Models**](../local/index.md) — run Ollama, vLLM, or LocalAI locally. No API key required.
+- [**Provider Definitions**](../custom/index.md) — define reusable provider configurations with shared defaults for any provider type.
+
+## Quick Comparison
+
+| Provider            | Key              | Local? | Strengths                                             |
+| ------------------- | ---------------- | ------ | ----------------------------------------------------- |
+| OpenAI              | `openai`         | No     | Broad model selection, tool calling, multimodal       |
+| Anthropic           | `anthropic`      | No     | Strong coding, extended thinking, large context       |
+| Google              | `google`         | No     | Fast inference, competitive pricing, multimodal       |
+| AWS Bedrock         | `amazon-bedrock` | No     | Enterprise features, multiple models, AWS integration |
+| Docker Model Runner | `dmr`            | Yes    | No API costs, data privacy, offline capable           |
+| Local Models (Ollama / vLLM) | `ollama` / custom | Yes | No API costs, full data privacy, any OpenAI-compatible server |
+
+## Additional Built-in Providers
+
+Docker Agent also includes built-in aliases for these providers:
+
+| Provider       | Alias            | API Key / Env Variable              |
+| -------------- | ---------------- | ----------------------------------- |
+| ChatGPT (OpenAI account) | [`chatgpt`](../chatgpt/index.md) | None (sign in via `docker agent setup`) |
+| OpenCode Zen   | `opencode-zen`   | `OPENCODE_API_KEY`                  |
+| OpenCode Go    | `opencode-go`    | `OPENCODE_API_KEY`                  |
+| Mistral        | `mistral`        | `MISTRAL_API_KEY`                   |
+| xAI (Grok)     | `xai`            | `XAI_API_KEY`                       |
+| Nebius         | `nebius`         | `NEBIUS_API_KEY`                    |
+| NVIDIA NIM     | `nvidia`         | `NVIDIA_API_KEY`                    |
+| MiniMax        | `minimax`        | `MINIMAX_API_KEY`                   |
+| Baseten        | `baseten`        | `BASETEN_API_KEY`                   |
+| OVHcloud       | `ovhcloud`       | `OVH_AI_ENDPOINTS_ACCESS_TOKEN`     |
+| Groq           | `groq`           | `GROQ_API_KEY`                      |
+| Fireworks AI   | `fireworks`      | `FIREWORKS_API_KEY`                 |
+| DeepSeek       | `deepseek`       | `DEEPSEEK_API_KEY`                  |
+| Cerebras       | `cerebras`       | `CEREBRAS_API_KEY`                  |
+| Together AI    | `together`       | `TOGETHER_API_KEY`                  |
+| Hugging Face   | `huggingface`    | `HF_TOKEN`                          |
+| Cloudflare Workers AI | `cloudflare-workers-ai` | `CLOUDFLARE_API_TOKEN` + `CLOUDFLARE_ACCOUNT_ID` |
+| Moonshot AI    | `moonshot`       | `MOONSHOT_API_KEY`                  |
+| Vercel AI Gateway | `vercel`      | `AI_GATEWAY_API_KEY`                |
+| Cloudflare AI Gateway | `cloudflare-ai-gateway` | `CLOUDFLARE_API_TOKEN` + `CLOUDFLARE_ACCOUNT_ID` + `CLOUDFLARE_GATEWAY_ID` |
+| Requesty       | `requesty`       | `REQUESTY_API_KEY`                  |
+| OpenRouter     | `openrouter`     | `OPENROUTER_API_KEY`                |
+| Azure OpenAI   | `azure`          | `AZURE_API_KEY` + `base_url`        |
+| [Ollama](../local/index.md) | `ollama` | None (local; optional `base_url`) |
+| GitHub Copilot | `github-copilot` | `GITHUB_TOKEN` (PAT with `copilot` scope) |
+
+```bash
+# Use built-in providers inline
+agents:
+  root:
+    model: mistral/mistral-large-latest
+```
+
+> [!TIP]
+> **Multi-provider teams**
+>
+> Use expensive models for complex reasoning and cheaper/local models for routine tasks. See the example below.
+
+## Using Multiple Providers
+
+Different agents can use different providers in the same configuration:
+
+```yaml
+models:
+  claude:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    max_tokens: 64000
+  gpt:
+    provider: openai
+    model: gpt-5
+  local:
+    provider: dmr
+    model: ai/qwen3
+
+agents:
+  root:
+    model: claude # coordinator uses Claude
+    sub_agents: [coder, helper]
+  coder:
+    model: gpt # coder uses GPT-5
+  helper:
+    model: local # helper runs locally for free
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/ovhcloud/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/ovhcloud/index.md
new file mode 100644
index 000000000000..53298c8d57ac
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/ovhcloud/index.md
@@ -0,0 +1,108 @@
+---
+title: "OVHcloud"
+description: "Use OVHcloud AI Endpoints models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, ovhcloud
+weight: 240
+canonical: https://docs.docker.com/ai/docker-agent/providers/ovhcloud/
+---
+
+_Use OVHcloud AI Endpoints models with Docker Agent._
+
+## Overview
+
+[OVHcloud AI Endpoints](https://endpoints.ai.cloud.ovh.net/) serves open-weight
+models through an OpenAI-compatible API, hosted in the EU. Docker Agent includes
+built-in support for OVHcloud as an alias provider.
+
+## Setup
+
+1. Create an access token from the
+   [OVHcloud AI Endpoints portal](https://endpoints.ai.cloud.ovh.net/).
+2. Set the environment variable:
+
+   ```bash
+   export OVH_AI_ENDPOINTS_ACCESS_TOKEN=your-access-token
+   ```
+
+## Usage
+
+### Inline Syntax
+
+```yaml
+agents:
+  root:
+    model: ovhcloud/Qwen3.5-397B-A17B
+    description: Assistant using OVHcloud
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+```yaml
+models:
+  ovhcloud_model:
+    provider: ovhcloud
+    model: Qwen3.5-397B-A17B
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: ovhcloud_model
+    description: Assistant using OVHcloud
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+OVHcloud hosts a rotating catalogue of open-weight models. Check the
+[AI Endpoints catalogue](https://endpoints.ai.cloud.ovh.net/) for current model
+IDs, context limits, and free-tier availability.
+
+| Model | Description |
+| --- | --- |
+| `Qwen3.5-397B-A17B` | Large Qwen3.5 MoE — strong general, coding, and reasoning |
+| `Qwen3-32B` | Mid-size Qwen3 — fast, tool-calling, reasoning |
+| `Qwen3.6-27B` | Compact Qwen3.6 — fast and efficient |
+| `Qwen3.5-9B` | Small Qwen3.5 — lightweight, free-tier friendly |
+| `Qwen3-Coder-30B-A3B-Instruct` | Qwen3 Coder MoE — optimised for code generation |
+| `Meta-Llama-3_3-70B-Instruct` | Llama 3.3 70B — reliable general-purpose chat |
+| `Mistral-Small-3.2-24B-Instruct-2506` | Compact, fast, tool-calling |
+
+> Model IDs are case-sensitive and must be passed exactly as the catalogue lists
+> them.
+
+## How It Works
+
+OVHcloud is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://oai.endpoints.kepler.ai.cloud.ovh.net/v1`
+- **Token Variable:** `OVH_AI_ENDPOINTS_ACCESS_TOKEN`
+
+Docker Agent automatically coalesces consecutive system messages into one for
+OVHcloud, because some OVHcloud models return an empty stream when a request
+carries more than one system message.
+
+## Free tier
+
+OVHcloud offers rate-limited free access to several models. Under heavy
+rate-limiting the endpoint may return an empty response; Docker Agent surfaces
+this as a warning rather than failing. For sustained use, an access token with a
+paid plan avoids the free-tier request-rate cap.
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: ovhcloud/Qwen3.5-397B-A17B
+    description: Code assistant using Qwen3.5
+    instruction: |
+      You are an expert programmer.
+      Write clean, well-documented code and follow language best practices.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/together/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/together/index.md
new file mode 100644
index 000000000000..8dda71006171
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/together/index.md
@@ -0,0 +1,101 @@
+---
+title: "Together AI"
+description: "Use Together AI models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, together ai
+weight: 250
+canonical: https://docs.docker.com/ai/docker-agent/providers/together/
+---
+
+_Use Together AI models with Docker Agent._
+
+## Overview
+
+[Together AI](https://www.together.ai/) is one of the largest hosts of open
+models, serving Llama, Qwen, DeepSeek, Kimi, GLM and others through an
+OpenAI-compatible API. Docker Agent includes built-in support for Together AI as
+an alias provider.
+
+## Setup
+
+1. Create an API key from the [Together AI settings](https://api.together.ai/settings/api-keys).
+2. Set the environment variable:
+
+   ```bash
+   export TOGETHER_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use Together AI:
+
+```yaml
+agents:
+  root:
+    model: together/meta-llama/Llama-3.3-70B-Instruct-Turbo
+    description: Assistant using Together AI
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  together_model:
+    provider: together
+    model: meta-llama/Llama-3.3-70B-Instruct-Turbo
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: together_model
+    description: Assistant using Together AI
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+Together AI serves a broad, changing catalog of open-weight models. Check the
+[Together AI model library](https://docs.together.ai/docs/serverless-models) for
+current model IDs, context limits, and pricing.
+
+| Model | Description |
+| --- | --- |
+| `meta-llama/Llama-3.3-70B-Instruct-Turbo` | Llama 3.3 70B, general-purpose chat and tool calling |
+| `Qwen/Qwen3-235B-A22B-Instruct-2507-tput` | Qwen3 235B mixture-of-experts instruct model |
+| `deepseek-ai/DeepSeek-V3` | DeepSeek-V3, strong coding and reasoning |
+
+> Model IDs are case-sensitive and must be passed exactly as the catalogue lists
+> them.
+
+## How It Works
+
+Together AI is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://api.together.xyz/v1`
+- **Token Variable:** `TOGETHER_API_KEY`
+
+Because Together AI fronts open-weight models whose chat templates may reject
+more than one leading system message, Docker Agent coalesces its per-source
+system messages into a single one for this provider.
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: together/Qwen/Qwen3-235B-A22B-Instruct-2507-tput
+    description: Code assistant using Qwen3 on Together AI
+    instruction: |
+      You are an expert programmer.
+      Write clean, well-documented code and follow language best practices.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/vercel/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/vercel/index.md
new file mode 100644
index 000000000000..f2278690bb23
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/vercel/index.md
@@ -0,0 +1,109 @@
+---
+title: "Vercel AI Gateway"
+description: "Use Vercel AI Gateway models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, vercel ai gateway
+weight: 260
+canonical: https://docs.docker.com/ai/docker-agent/providers/vercel/
+---
+
+_Use Vercel AI Gateway models with Docker Agent._
+
+## Overview
+
+[Vercel AI Gateway](https://vercel.com/docs/ai-gateway) is a single, unified
+OpenAI-compatible endpoint that routes to models from OpenAI, Anthropic, Google,
+xAI and more at list price with no markup, plus provider routing and failover.
+It lets you reach many providers with one API key. Docker Agent includes
+built-in support for Vercel AI Gateway as an alias provider.
+
+## Setup
+
+1. Create an API key from the [Vercel AI Gateway dashboard](https://vercel.com/docs/ai-gateway).
+2. Set the environment variable:
+
+   ```bash
+   export AI_GATEWAY_API_KEY=your-api-key
+   ```
+
+## Usage
+
+Vercel AI Gateway model IDs use a `creator/model` form (for example
+`openai/gpt-5.6-sol` or `anthropic/claude-sonnet-4.5`); the gateway routes each
+request to the underlying provider. The gateway lists explicit variant slugs
+only (`openai/gpt-5.6-sol`, `-terra`, `-luna`) — there is no unsuffixed
+`openai/gpt-5.6` alias on the gateway.
+
+### Inline Syntax
+
+The simplest way to use Vercel AI Gateway:
+
+```yaml
+agents:
+  root:
+    model: vercel/openai/gpt-5.6-sol
+    description: Assistant using Vercel AI Gateway
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  vercel_model:
+    provider: vercel
+    model: openai/gpt-5.6-sol
+    max_tokens: 8192
+
+agents:
+  root:
+    model: vercel_model
+    description: Assistant using Vercel AI Gateway
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+Vercel AI Gateway exposes models from many providers behind one endpoint. Check
+the [Vercel AI Gateway documentation](https://vercel.com/docs/ai-gateway) for
+the current model list, IDs, and pricing.
+
+| Model | Description |
+| --- | --- |
+| `openai/gpt-5.6-sol` | OpenAI GPT-5.6 Sol (frontier) routed through the gateway |
+| `openai/gpt-5.6-terra` | OpenAI GPT-5.6 Terra (workhorse) routed through the gateway |
+| `openai/gpt-5.6-luna` | OpenAI GPT-5.6 Luna (high-volume) routed through the gateway |
+| `anthropic/claude-sonnet-4.5` | Anthropic Claude Sonnet routed through the gateway |
+| `google/gemini-2.5-flash` | Google Gemini routed through the gateway |
+
+> Model IDs are case-sensitive and must be passed exactly as the gateway lists
+> them, including the `creator/` prefix.
+
+## How It Works
+
+Vercel AI Gateway is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://ai-gateway.vercel.sh/v1`
+- **Token Variable:** `AI_GATEWAY_API_KEY`
+
+Because the gateway can route to open-weight models with strict chat templates,
+Docker Agent coalesces consecutive system messages into a single leading one for
+this provider.
+
+## Example: Code Assistant
+
+```yaml
+agents:
+  coder:
+    model: vercel/anthropic/claude-sonnet-4.5
+    description: Code assistant via Vercel AI Gateway
+    instruction: |
+      You are an expert programmer.
+      Write clean, well-documented code and follow language best practices.
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/xai/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/xai/index.md
new file mode 100644
index 000000000000..638e5018826b
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/providers/xai/index.md
@@ -0,0 +1,99 @@
+---
+title: "xAI (Grok)"
+description: "Use xAI's Grok models with Docker Agent."
+keywords: docker agent, ai agents, model providers, llm, xai (grok)
+weight: 270
+canonical: https://docs.docker.com/ai/docker-agent/providers/xai/
+---
+
+_Use xAI's Grok models with Docker Agent._
+
+## Overview
+
+xAI provides the Grok family of models through an OpenAI-compatible API. Docker Agent includes built-in support for xAI as an alias provider.
+
+## Setup
+
+1. Get an API key from [xAI Console](https://console.x.ai/)
+2. Set the environment variable:
+
+   ```bash
+   export XAI_API_KEY=your-api-key
+   ```
+
+## Usage
+
+### Inline Syntax
+
+The simplest way to use xAI:
+
+```yaml
+agents:
+  root:
+    model: xai/grok-3
+    description: Assistant using Grok
+    instruction: You are a helpful assistant.
+```
+
+### Named Model
+
+For more control over parameters:
+
+```yaml
+models:
+  grok:
+    provider: xai
+    model: grok-3
+    temperature: 0.7
+    max_tokens: 8192
+
+agents:
+  root:
+    model: grok
+    description: Assistant using Grok
+    instruction: You are a helpful assistant.
+```
+
+## Available Models
+
+| Model              | Description                        | Context |
+| ------------------ | ---------------------------------- | ------- |
+| `grok-3`           | Latest and most capable Grok model | 131K    |
+| `grok-3-fast`      | Faster variant with lower latency  | 131K    |
+| `grok-3-mini`      | Compact model for simpler tasks    | 131K    |
+| `grok-3-mini-fast` | Fast variant of the mini model     | 131K    |
+| `grok-2`           | Previous generation model          | 128K    |
+| `grok-vision`      | Vision-capable model               | 32K     |
+
+Check the [xAI documentation](https://docs.x.ai/docs) for the latest available models.
+
+## Extended Thinking
+
+Docker Agent's `thinking_budget` field is **not applied** to xAI models: the underlying OpenAI-compatible client only sends `reasoning_effort` for OpenAI reasoning model names (o-series, gpt-5). Setting `thinking_budget` on a Grok model passes config validation but has no effect on the request.
+
+Grok reasoning models (e.g. `grok-3-mini`) reason on their own without configuration. For non-reasoning models, use the [think tool](../../tools/think/index.md) instead.
+
+## How It Works
+
+xAI is implemented as a built-in alias in Docker Agent:
+
+- **API Type:** OpenAI-compatible (`openai_chatcompletions`)
+- **Base URL:** `https://api.x.ai/v1`
+- **Token Variable:** `XAI_API_KEY`
+
+## Example: Research Assistant
+
+```yaml
+agents:
+  researcher:
+    model: xai/grok-3
+    description: Research assistant with real-time knowledge
+    instruction: |
+      You are a research assistant using Grok.
+      Provide well-researched, factual responses.
+      Cite sources when available.
+    toolsets:
+      - type: mcp
+        ref: docker:duckduckgo
+      - type: think
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/_index.md b/_vendor/github.com/docker/docker-agent/docs/tools/_index.md
new file mode 100644
index 000000000000..ca9847f9a25d
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Built-in Tools"
+description: "Built-in toolsets agents can use out of the box."
+weight: 40
+---
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md
new file mode 100644
index 000000000000..f07a9fe62435
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/a2a/index.md
@@ -0,0 +1,43 @@
+---
+title: "A2A Tool"
+description: "Connect to remote agents via the Agent-to-Agent protocol."
+keywords: docker agent, ai agents, tools, toolsets, a2a tool
+linkTitle: "A2A"
+weight: 60
+canonical: https://docs.docker.com/ai/docker-agent/tools/a2a/
+---
+
+_Connect to remote agents via the Agent-to-Agent protocol._
+
+## Overview
+
+The A2A tool connects to a remote agent exposed over the A2A (Agent-to-Agent) protocol. Unlike [`handoff`](../handoff/index.md), which only targets local agents declared in the same config, `a2a` reaches out to an agent running on the network.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: a2a
+    url: "http://localhost:8080/a2a"
+    # Optional: custom tool name (defaults to a sanitized form of the URL / agent card name)
+    name: research_agent
+    # Optional: custom HTTP headers (typically for auth)
+    headers:
+      Authorization: "Bearer ${env.A2A_TOKEN}"
+      X-Tenant: "acme"
+```
+
+The `Authorization` header shown above authenticates to endpoints served with `docker agent serve a2a --auth-token`.
+
+## Properties
+
+| Property   | Type             | Required | Description                                                                                              |
+| ---------- | ---------------- | -------- | -------------------------------------------------------------------------------------------------------- |
+| `url`      | string           | ✓        | A2A server endpoint URL (must include scheme).                                                           |
+| `name`     | string           | ✗        | Tool name registered for the remote agent. Defaults to a name derived from the server's agent card.     |
+| `headers`  | map\[string\]string | ✗     | Extra HTTP headers sent with every request (useful for `Authorization`, tenant selection, tracing, \u2026). |
+
+> [!TIP]
+> **See also**
+>
+> For full details on the A2A protocol and serving agents as A2A endpoints, see [A2A Protocol](../../features/a2a/index.md).
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/api/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/api/index.md
new file mode 100644
index 000000000000..73e802bd5b89
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/api/index.md
@@ -0,0 +1,252 @@
+---
+title: "API Tool"
+description: "Create custom tools that call HTTP APIs."
+keywords: docker agent, ai agents, tools, toolsets, api tool
+linkTitle: "API"
+weight: 240
+canonical: https://docs.docker.com/ai/docker-agent/tools/api/
+---
+
+_Create custom tools that call HTTP APIs._
+
+## Overview
+
+The API tool type lets you define custom tools that make HTTP requests to external APIs. This is useful for integrating agents with REST APIs, webhooks, or any HTTP-based service without writing code.
+
+> [!NOTE]
+> **When to Use**
+>
+> - Integrating with REST APIs that don't have an MCP server
+> - Simple HTTP operations (GET, POST)
+> - Quick prototyping before building a full MCP server
+
+## Configuration
+
+```yaml
+agents:
+  assistant:
+    model: openai/gpt-4o
+    description: Assistant with API access
+    instruction: You can look up weather information.
+    toolsets:
+      - type: api
+        api_config:
+          name: get_weather
+          method: GET
+          endpoint: "https://api.weather.example/v1/current?city=${city}"
+          instruction: Get current weather for a city
+          args:
+            city:
+              type: string
+              description: City name to get weather for
+          required: ["city"]
+          headers:
+            Authorization: "Bearer ${env.WEATHER_API_KEY}"
+```
+
+## Properties
+
+The `api` toolset accepts the following toolset-level fields in addition to the `api_config` block:
+
+| Property            | Type    | Required | Description                                                                                                                                                                                                                                                       |
+| ------------------- | ------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `api_config`        | object  | ✓        | The HTTP tool definition. See the table below.                                                                                                                                                                                                                    |
+| `timeout`           | int     | ✗        | HTTP client timeout in seconds (default: `30`). Applies to every call the generated tool makes.                                                                                                                                                                   |
+| `allow_private_ips` | boolean | ✗        | Opt in to dialling **non-public** IP addresses (loopback, RFC1918, link-local — including the cloud-metadata endpoint at `169.254.169.254` — multicast and the unspecified address). Set to `true` only when the configured endpoint legitimately targets internal services. See [Reaching internal services](#reaching-internal-services). |
+
+### `api_config`
+
+| Property        | Type   | Required | Description                                      |
+| --------------- | ------ | -------- | ------------------------------------------------ |
+| `name`          | string | ✓        | Tool name (how the agent references it)          |
+| `method`        | string | ✓        | HTTP method: `GET` or `POST`                     |
+| `endpoint`      | string | ✓        | URL endpoint (supports `${param}` interpolation) |
+| `instruction`   | string | ✗        | Description shown to the agent                   |
+| `args`          | object | ✗        | Parameter definitions (JSON Schema properties)   |
+| `required`      | array  | ✗        | List of required parameter names                 |
+| `headers`       | object | ✗        | HTTP headers to include. Values support `${env.VAR}` and `${headers.NAME}` placeholders (the latter forwards a header from the caller's incoming request, useful when docker agent is itself exposed as an HTTP server). |
+| `output_schema` | object | ✗        | JSON Schema for the response. Used by MCP / Code Mode consumers; tool responses are still returned to the model as raw strings.                                                                                          |
+
+## HTTP Methods
+
+### GET Requests
+
+For GET requests, parameters are interpolated into the URL:
+
+```yaml
+toolsets:
+  - type: api
+    api_config:
+      name: search_users
+      method: GET
+      endpoint: "https://api.example.com/users?q=${query}&limit=${limit}"
+      instruction: Search for users by name
+      args:
+        query:
+          type: string
+          description: Search query
+        limit:
+          type: integer
+          description: Maximum results (default 10)
+      required: ["query"]
+```
+
+### POST Requests
+
+For POST requests, parameters are sent as JSON in the request body:
+
+```yaml
+toolsets:
+  - type: api
+    api_config:
+      name: create_task
+      method: POST
+      endpoint: "https://api.example.com/tasks"
+      instruction: Create a new task
+      args:
+        title:
+          type: string
+          description: Task title
+        description:
+          type: string
+          description: Task description
+        priority:
+          type: string
+          enum: ["low", "medium", "high"]
+          description: Task priority
+      required: ["title"]
+      headers:
+        Content-Type: "application/json"
+        Authorization: "Bearer ${env.API_TOKEN}"
+```
+
+## URL Interpolation
+
+Use `${param}` syntax to insert parameter values into URLs:
+
+```yaml
+endpoint: "https://api.example.com/users/${user_id}/posts/${post_id}"
+```
+
+Parameter values are inserted as strings by the template expansion. Add URL encoding in the template when needed (for example, `${encodeURIComponent(city)}`).
+
+## Headers
+
+Headers can include environment variables:
+
+```yaml
+headers:
+  Authorization: "Bearer ${env.API_KEY}"
+  X-Custom-Header: "static-value"
+  Content-Type: "application/json"
+```
+
+## Output Schema
+
+Optionally document the expected response format:
+
+```yaml
+toolsets:
+  - type: api
+    api_config:
+      name: get_user
+      method: GET
+      endpoint: "https://api.example.com/users/${id}"
+      instruction: Get user details by ID
+      args:
+        id:
+          type: string
+          description: User ID
+      required: ["id"]
+      output_schema:
+        type: object
+        properties:
+          id:
+            type: string
+          name:
+            type: string
+          email:
+            type: string
+          created_at:
+            type: string
+```
+
+## Example: GitHub API
+
+```yaml
+agents:
+  github_assistant:
+    model: openai/gpt-4o
+    description: Assistant that can query GitHub
+    instruction: You can look up GitHub repositories and users.
+    toolsets:
+      - type: api
+        api_config:
+          name: get_repo
+          method: GET
+          endpoint: "https://api.github.com/repos/${owner}/${repo}"
+          instruction: Get information about a GitHub repository
+          args:
+            owner:
+              type: string
+              description: Repository owner (user or org)
+            repo:
+              type: string
+              description: Repository name
+          required: ["owner", "repo"]
+          headers:
+            Accept: "application/vnd.github.v3+json"
+            Authorization: "Bearer ${env.GITHUB_TOKEN}"
+
+      - type: api
+        api_config:
+          name: get_user
+          method: GET
+          endpoint: "https://api.github.com/users/${username}"
+          instruction: Get information about a GitHub user
+          args:
+            username:
+              type: string
+              description: GitHub username
+          required: ["username"]
+          headers:
+            Accept: "application/vnd.github.v3+json"
+```
+
+## Limitations
+
+- Only supports GET and POST methods
+- Response body is limited to 1MB
+- Default 30-second timeout per request (override with the `timeout` field)
+- Only HTTP and HTTPS URLs are supported
+- No support for file uploads or multipart forms
+- By default, requests to non-public IP ranges (loopback, RFC1918, link-local, the cloud-metadata endpoint, multicast, the unspecified address) are refused at dial time — even when DNS for an otherwise-public host resolves there. Set `allow_private_ips: true` to disable that check.
+
+## Reaching internal services
+
+```yaml
+toolsets:
+  - type: api
+    timeout: 60
+    allow_private_ips: true
+    api_config:
+      name: get_local_status
+      method: GET
+      endpoint: "http://localhost:8080/health"
+      instruction: Check the local service health
+```
+
+> [!WARNING]
+> **SSRF**
+>
+> Setting `allow_private_ips: true` re-exposes the SSRF surface for this tool. Only enable it when the configured `endpoint` is a trusted internal service — a prompt-injected agent cannot redirect the call elsewhere because the endpoint is fixed in config, but redirects from the configured host can still reach unexpected places.
+
+> [!TIP]
+> **For Complex APIs**
+>
+> For APIs that need authentication flows, pagination, or complex request/response handling, consider using an MCP server instead. The API tool is best for simple, stateless HTTP operations.
+
+> [!WARNING]
+> **Security**
+>
+> API keys and tokens in headers are visible in debug logs. Use environment variables (`${env.VAR}`) rather than hardcoding secrets in configuration files.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md
new file mode 100644
index 000000000000..0c6afbfaaed9
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/background-agents/index.md
@@ -0,0 +1,120 @@
+---
+title: "Background Agents Tool"
+description: "Dispatch work to sub-agents concurrently and collect results asynchronously."
+keywords: docker agent, ai agents, tools, toolsets, background agents tool
+linkTitle: "Background Agents"
+weight: 90
+canonical: https://docs.docker.com/ai/docker-agent/tools/background-agents/
+---
+
+_Dispatch work to sub-agents concurrently and collect results asynchronously._
+
+## Overview
+
+The background agents tool lets an orchestrator dispatch work to sub-agents concurrently and collect results asynchronously. Unlike [transfer_task](../transfer-task/index.md) (which blocks until the sub-agent finishes), background agent tasks run in parallel — the orchestrator can start several tasks, do other work, and check on them later.
+
+## Available Tools
+
+| Tool                     | Description                                                     |
+| ------------------------ | --------------------------------------------------------------- |
+| `run_background_agent`   | Start a sub-agent task in the background; returns a task ID     |
+| `list_background_agents` | List all background tasks with their status and runtime         |
+| `view_background_agent`  | View live output or final result of a task by ID                |
+| `stop_background_agent`  | Cancel a running task by ID                                     |
+
+### `run_background_agent` parameters
+
+| Parameter         | Type   | Required | Description                                                                 |
+| ----------------- | ------ | -------- | --------------------------------------------------------------------------- |
+| `agent`           | string | ✓        | Name of the sub-agent to run. Must be listed under the caller's `sub_agents`. |
+| `task`            | string | ✓        | Clear, concise description of the task the sub-agent should achieve.        |
+| `expected_output` | string | ✗        | Optional description of the result format the caller expects.               |
+
+`run_background_agent` returns a **task ID** string. Tools run by the sub-agent inherit the parent session's permissions. Because background tasks run non-interactively, any tool call that would normally prompt the user for approval will be automatically denied. To allow background agents to run mutating tools, you must explicitly approve them in the parent session (e.g. via YOLO mode or explicit allow rules).
+
+Background delegation shares the same runtime guards as `transfer_task`: delegation cycles are rejected and chains are capped at 10 nested delegations. See [Delegation Limits](../transfer-task/index.md#delegation-limits).
+
+### `view_background_agent` and `stop_background_agent` parameters
+
+| Parameter | Type   | Required | Description                                                    |
+| --------- | ------ | -------- | -------------------------------------------------------------- |
+| `task_id` | string | ✓        | Task ID returned by `run_background_agent` or `list_background_agents`. |
+
+`list_background_agents` takes no parameters.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: background_agents
+```
+
+No configuration options. Requires the agent to have `sub_agents` configured so the background tasks have agents to dispatch to.
+
+## Example
+
+```yaml
+agents:
+  coordinator:
+    model: openai/gpt-4o
+    description: Orchestrates parallel research
+    instruction: Fan out research tasks and synthesize results.
+    sub_agents: [researcher]
+    toolsets:
+      - type: background_agents
+      - type: think
+
+  researcher:
+    model: openai/gpt-4o
+    description: Web researcher
+    instruction: Research topics thoroughly.
+    toolsets:
+      - type: mcp
+        ref: docker:duckduckgo
+```
+
+> [!TIP]
+> **When to Use**
+>
+> Use `background_agents` when your orchestrator needs to fan out work to multiple specialists in parallel — for example, researching several topics simultaneously or running independent code analyses side by side.
+
+In the TUI, each background task's token usage is accounted for live: the sidebar's Agents panel shows the sub-agent's context usage percentage on its roster row, the Agent Inspector shows its exact token counts, and the task's cost joins the session total.
+
+## Using Harness Sub-Agents
+
+Background agents work equally well with [harness-backed sub-agents](../../features/harnesses/index.md) — sub-agents driven by external coding CLIs such as Claude Code or Codex. This lets you dispatch multiple independent coding tasks in parallel:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Orchestrator that fans out coding tasks
+    instruction: |
+      Dispatch the frontend and backend tasks in parallel,
+      then collect results and produce a summary.
+    sub_agents:
+      - claude-coder
+      - codex-coder
+    toolsets:
+      - type: background_agents
+
+  claude-coder:
+    description: Frontend specialist (Claude Code)
+    harness:
+      type: claude-code
+      effort: medium
+
+  codex-coder:
+    description: Backend specialist (Codex)
+    harness:
+      type: codex
+```
+
+The orchestrator calls `run_background_agent` for each coding task, then uses `list_background_agents` and `view_background_agent` to collect results when they finish.
+
+> [!NOTE]
+> **Harness toolsets are ignored**
+>
+> Harness agents use the external CLI's own tools — any `toolsets:` configured on the harness agent are silently ignored. See [Coding Harnesses](../../features/harnesses/index.md) for details and caveats.
+
+See [`examples/coding_harness_background_agents.yaml`](https://github.com/docker/docker-agent/blob/main/examples/coding_harness_background_agents.yaml) for a complete configuration.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md
new file mode 100644
index 000000000000..8a7a3915e678
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md
@@ -0,0 +1,89 @@
+---
+title: "Background Jobs Tool"
+description: "Run and manage long-running shell commands."
+keywords: docker agent, ai agents, tools, toolsets, background jobs, shell
+linkTitle: "Background Jobs"
+weight: 21
+canonical: https://docs.docker.com/ai/docker-agent/tools/background-jobs/
+---
+
+_Run and manage long-running shell commands._
+
+## Overview
+
+The `background_jobs` toolset starts shell commands that should keep running while the agent continues with other work, such as local servers, file watchers, long builds, or test suites. It returns a job ID immediately, captures combined stdout/stderr up to 10 MB per job, and terminates all running jobs when the agent session ends.
+
+Use the [`shell`](../shell/index.md) toolset for short synchronous commands. Add both toolsets when an agent needs both synchronous commands and long-running processes.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: shell
+  - type: background_jobs
+```
+
+### Options
+
+| Property       | Type    | Description                                                                                                                                          |
+| -------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `env`    | object  | Environment variables to set for all background job commands.                                                                                        |
+| `recall` | boolean | Let `run_background_job` expose a `recall` parameter so jobs can steer the agent when they finish (see [Background job recall](#background-job-recall)). Default `false`. |
+
+### Custom Environment Variables
+
+```yaml
+toolsets:
+  - type: background_jobs
+    env:
+      MY_VAR: "value"
+      PATH: "${env.PATH}:/custom/bin"
+```
+
+### Background job recall
+
+Set `recall: true` to let the `run_background_job` tool expose a `recall` boolean parameter:
+
+```yaml
+toolsets:
+  - type: background_jobs
+    recall: true
+```
+
+When the agent starts a background job with `recall: true`, Docker Agent sends a steering message back into the running agent loop after the job finishes. The message contains a short completion sentence and the job output, so the agent can react without polling `view_background_job`.
+
+Use recall for finite background work where completion matters (for example, a long build or test suite). Avoid it for servers and watchers that are expected to run until stopped. See [`examples/shell_recall.yaml`](https://github.com/docker/docker-agent/blob/main/examples/shell_recall.yaml) for a complete configuration.
+
+## Available Tools
+
+The background jobs toolset exposes five tools:
+
+| Tool Name              | Description                                                                                    |
+| ---------------------- | ---------------------------------------------------------------------------------------------- |
+| `run_background_job`   | Start a command asynchronously and return a job ID immediately. Use for servers/watchers/etc. |
+| `list_background_jobs` | List all background jobs with their status, runtime, and metadata.                             |
+| `view_background_job`  | View the buffered output and status of a specific background job by ID.                        |
+| `stop_background_job`  | Stop a running background job. Child processes are terminated too.                             |
+| `wait_background_job`  | Block until a job finishes and return its exit code and output. Safe on already-finished jobs. |
+
+### `run_background_job` parameters
+
+| Parameter | Type    | Required | Description                                                                                                                                 |
+| --------- | ------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
+| `cmd`     | string  | ✓        | The shell command to execute in the background.                                                                                             |
+| `cwd`     | string  | ✗        | Working directory to run the command in (default: `.`).                                                                                     |
+| `recall`  | boolean | ✗        | Only available when the `background_jobs` toolset has `recall: true`. When true, send a steering message with the job output when it finishes. |
+
+`view_background_job` and `stop_background_job` each take a single required `job_id` string returned by `run_background_job` or `list_background_jobs`.
+
+### `wait_background_job` parameters
+
+| Parameter | Type    | Required | Description                                                                                                    |
+| --------- | ------- | -------- | -------------------------------------------------------------------------------------------------------------- |
+| `job_id`  | string  | ✓        | Job ID returned by `run_background_job` or `list_background_jobs`.                                             |
+| `timeout` | integer | ✗        | Maximum seconds to wait (default: `60`). If the job is still running when the limit fires, the tool returns the current output with a notice and the job continues in the background. |
+
+> [!WARNING]
+> **Safety**
+>
+> Background jobs run shell commands with the same access as the agent process. Stop servers and watchers when they are no longer needed, and use [Sandbox Mode](../../configuration/sandbox/index.md) for additional isolation.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md
new file mode 100644
index 000000000000..fa793a54ac07
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/fetch/index.md
@@ -0,0 +1,173 @@
+---
+title: "Fetch Tool"
+description: "Read content from HTTP/HTTPS URLs."
+keywords: docker agent, ai agents, tools, toolsets, fetch tool
+linkTitle: "Fetch"
+weight: 50
+canonical: https://docs.docker.com/ai/docker-agent/tools/fetch/
+---
+
+_Read content from HTTP/HTTPS URLs._
+
+## Overview
+
+The fetch tool lets agents retrieve content from one or more HTTP/HTTPS URLs. It is **read-only** — only `GET` requests are supported. The tool respects `robots.txt`, limits response size (1 MB per URL), and can return content as plain text, Markdown (converted from HTML), or raw HTML.
+
+> [!NOTE]
+> **GET only**
+>
+> The fetch tool does **not** support `POST`, `PUT`, `DELETE` or other methods, and does not expose request bodies or per-call custom headers (the toolset can still attach static [credential headers](#custom-headers) to every request). To call REST endpoints with other verbs, use the [API tool](../api/index.md) or an [OpenAPI toolset](../openapi/index.md).
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: fetch
+```
+
+### Options
+
+| Property            | Type          | Default | Description                                                                                                                                                                                                                                                                                                      |
+| ------------------- | ------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `timeout`           | int           | `30`    | Default request timeout in seconds (overridable per tool call).                                                                                                                                                                                                                                                  |
+| `allowed_domains`   | array[string] | _none_  | Allow-list of hosts the tool may fetch. When set, every URL whose host is **not** in the list is rejected before any network call is made. Mutually exclusive with `blocked_domains`.                                                                                                                            |
+| `blocked_domains`   | array[string] | _none_  | Deny-list of hosts the tool must not fetch. URLs whose host matches one of these patterns are rejected before any network call (including `robots.txt`) is made. Mutually exclusive with `allowed_domains`.                                                                                                      |
+| `allow_private_ips` | boolean       | `false` | Opt in to dialling **non-public** IP addresses (loopback, RFC1918, link-local — including the cloud-metadata endpoint at `169.254.169.254` — multicast, and the unspecified address). Required to reach `localhost` / internal services. See [SSRF protection](#ssrf-protection-and-reaching-localhost) below. |
+| `headers`           | map[string]string | _none_ | Static HTTP headers attached to **every** request the toolset issues (including `robots.txt`). Values support `${env.VAR}` for secrets. Caller-supplied entries override the default `User-Agent` and the format-driven `Accept` header. Headers are stripped on cross-host redirects so credentials never leak to a third-party host. See [Custom headers](#custom-headers) below. |
+
+### Domain matching
+
+Domain patterns in `allowed_domains` and `blocked_domains` use the following rules (case-insensitive):
+
+- **Bare domain** — `example.com` matches the host `example.com` _and_ any subdomain such as `docs.example.com`. It does **not** match unrelated hosts that share a suffix (e.g. `badexample.com`).
+- **Leading dot** — `.example.com` matches **only** strict subdomains (`docs.example.com`, `a.b.example.com`), not the apex `example.com`.
+- **Wildcard glob** — `*.example.com` is an alias for the leading-dot form; the apex is excluded. The `*` is only valid as a leading `*.` token (entries like `foo.*`, `*.*.example.com`, or a bare `*` are rejected at config-load time).
+- **IP literal** — IP addresses are matched exactly (`169.254.169.254`).
+- **CIDR range** — `169.254.0.0/16`, `10.0.0.0/8`, `::1/128`, `fc00::/7`. Matches when the URL's host parses as an IP inside the network. Hostname hosts never match a CIDR pattern. Malformed CIDRs are rejected at config-load time.
+- **Trailing dots** in FQDN-form URLs (`http://example.com./`) are stripped before matching, so they cannot bypass a deny-list entry.
+
+The lists are mutually exclusive: a single fetch toolset may set either `allowed_domains` or `blocked_domains`, but not both.
+
+When a list is configured, every redirect target is re-checked against the same list. A request to an allowed origin that redirects to a forbidden host is rejected before any data is read from the redirect.
+
+> [!WARNING]
+> **Limitations**
+>
+> Matching is purely string-based on the URL host. It does **not** perform DNS resolution and does **not** normalise alternative IP encodings (decimal `2852039166`, hex `0xa9.0xfe.0xa9.0xfe`, octal, etc. IPv4-mapped IPv6 addresses ARE normalized to their IPv4 form). If you need to deny access to a specific IP, also list its alternative encodings, or block at the network layer.
+
+### Custom Timeout
+
+```yaml
+toolsets:
+  - type: fetch
+    timeout: 60
+```
+
+### Custom headers
+
+Attach static headers — typically credentials — to every request. Values support `${env.VAR}` interpolation so secrets stay out of YAML, and headers are dropped on cross-host redirects so a redirect chain cannot leak them to a third-party host:
+
+```yaml
+toolsets:
+  - type: fetch
+    allowed_domains:
+      - docs.internal.example.com
+    headers:
+      Authorization: "Bearer ${env.INTERNAL_DOCS_TOKEN}"
+      X-Internal-Client: "docker-agent"
+```
+
+> [!WARNING]
+> **Pair credential headers with an allow-list**
+>
+> When `headers` carries credentials (e.g. `Authorization`), set `allowed_domains` to the specific hosts that should receive them. Stdlib already strips a small allow-list (`Authorization`, `Cookie`, `WWW-Authenticate`) on cross-domain redirects, and the fetch tool additionally strips every operator-supplied header on cross-host redirects — but an allow-list is the strongest guarantee against accidental exfiltration.
+
+### Restrict to specific domains
+
+```yaml
+toolsets:
+  - type: fetch
+    allowed_domains:
+      - docker.com          # docker.com and *.docker.com
+      - github.com          # github.com and *.github.com
+      - .githubusercontent.com  # only subdomains, e.g. raw.githubusercontent.com
+```
+
+### Block sensitive hosts
+
+```yaml
+toolsets:
+  - type: fetch
+    blocked_domains:
+      - 169.254.169.254       # cloud metadata endpoint (literal IP)
+      - 169.254.0.0/16        # entire link-local range (CIDR)
+      - 10.0.0.0/8            # RFC1918 private range
+      - "*.internal.example.com"  # any subdomain (wildcard)
+      - internal.example.com  # internal corporate hostname
+```
+
+> [!NOTE]
+> **Already blocked by default**
+>
+> You do **not** need to add loopback, RFC1918, link-local (incl. `169.254.169.254`), multicast or the unspecified address to `blocked_domains` to be safe — the fetch tool already refuses connections to those ranges at dial time, after DNS resolution. The example above is only useful if you also want to reject those hosts _before_ any network call (and to surface a clearer error message to the agent), or if you have set `allow_private_ips: true` and want to deny a specific subset.
+
+### SSRF protection and reaching localhost
+
+By default, the fetch tool refuses connections to **non-public IP addresses** — even when DNS for an otherwise-public host resolves to one of them (so DNS rebinding is also blocked). The check happens at dial time, after DNS resolution, and rejects:
+
+- **Loopback** — `127.0.0.0/8`, `::1` (this is what blocks `http://localhost/...` and `http://127.0.0.1/...`)
+- **RFC1918 private ranges** — `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`
+- **Link-local** — `169.254.0.0/16` (IPv4, including the cloud-metadata endpoint `169.254.169.254`) and `fe80::/10` (IPv6)
+- **Multicast** and the **unspecified** address (`0.0.0.0`, `::`)
+- **IPv4-mapped IPv6** — addresses like `::ffff:127.0.0.1` or `::ffff:169.254.169.254` are normalized to their IPv4 form and blocked accordingly
+
+This is the default because LLM-driven fetches are a classic Server-Side Request Forgery (SSRF) vector: a prompt-injected URL can otherwise reach internal services, cloud metadata, or admin interfaces on the host running the agent.
+
+If an agent legitimately needs to call **localhost** or an **internal service**, opt in with `allow_private_ips: true`:
+
+```yaml
+toolsets:
+  - type: fetch
+    allow_private_ips: true
+    allowed_domains:
+      - localhost
+      - 127.0.0.1
+      - 10.0.0.0/8            # internal corporate range
+```
+
+> [!WARNING]
+> **Pair with an allow-list**
+>
+> Setting `allow_private_ips: true` alone re-exposes the SSRF surface. We strongly recommend combining it with an `allowed_domains` entry that restricts the tool to the specific internal hosts or CIDRs the agent actually needs (e.g. `localhost`, `127.0.0.1`, or your internal CIDR).
+>
+> **Note:** `allowed_domains` is checked _before_ DNS resolution (string-based on hostname), while the SSRF check happens _after_ DNS resolution (on the resolved IP). This means `allowed_domains` and `blocked_domains` are evaluated independently of `allow_private_ips` and continue to apply. A public hostname in `allowed_domains` that resolves to a private IP will still be blocked unless `allow_private_ips: true` is set.
+
+## Tool Interface
+
+The toolset exposes a single tool, `fetch`, with the following parameters:
+
+| Parameter | Type           | Required | Description                                                                                                 |
+| --------- | -------------- | -------- | ----------------------------------------------------------------------------------------------------------- |
+| `urls`    | array[string]  | ✓        | One or more HTTP/HTTPS URLs to fetch (all via `GET`).                                                       |
+| `format`  | string         | ✓        | Output format: `text`, `markdown`, or `html`. HTML responses are converted to text/markdown when requested. |
+| `timeout` | integer        | ✗        | Per-call request timeout in seconds. Overrides the toolset default. Valid range: `1`–`300`.                 |
+
+Responses are capped at **1 MB** per URL. Hosts that disallow the agent's user-agent via `robots.txt` are skipped with a clear error.
+
+> [!TIP]
+> **Fetch vs. API Tool**
+>
+> Use `fetch` when the agent needs to read arbitrary public URLs at runtime. Use the [API tool](../api/index.md) to expose specific, structured HTTP endpoints (including non-`GET` verbs) as named tools.
+
+## Domain Filtering
+
+The `allowed_domains`, `blocked_domains`, and `allow_private_ips` options let you control which hosts the fetch tool may reach. The complete reference is in the [Options](#options) table and [Domain matching](#domain-matching) section above.
+
+**Key points:**
+
+- `allowed_domains` — allow-list; only listed hosts (and their subdomains for bare-domain entries) are reachable
+- `blocked_domains` — deny-list; mutually exclusive with `allowed_domains` (a config error is thrown if both are set)
+- `allow_private_ips` — defaults to `false`; set to `true` to reach loopback / RFC-1918 / link-local addresses
+- The same `allow_private_ips` flag is also supported on `api`, `openapi`, `a2a`, and remote `mcp` toolsets
+
+See [`examples/fetch_domain_filtering.yaml`](https://github.com/docker/docker-agent/blob/main/examples/fetch_domain_filtering.yaml) for a complete filtering example, and [`examples/remote_mcp_allow_private_ips.yaml`](https://github.com/docker/docker-agent/blob/main/examples/remote_mcp_allow_private_ips.yaml) for the equivalent pattern on remote MCP toolsets.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md
new file mode 100644
index 000000000000..19b0be53e1c2
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/filesystem/index.md
@@ -0,0 +1,145 @@
+---
+title: "Filesystem Tool"
+description: "Read, write, list, search, and navigate files and directories."
+keywords: docker agent, ai agents, tools, toolsets, filesystem tool
+linkTitle: "Filesystem"
+weight: 10
+canonical: https://docs.docker.com/ai/docker-agent/tools/filesystem/
+---
+
+_Read, write, list, search, and navigate files and directories._
+
+## Overview
+
+The filesystem tool gives agents the ability to explore codebases, read and edit files, create new files, search across files, and navigate directory structures.
+
+### Path resolution
+
+Paths are resolved relative to the **working directory** (the directory where the agent session started, or the directory specified with `--workdir`):
+
+- **Relative paths** (e.g., `src/main.go`, `../README.md`) are joined with the working directory.
+- **Absolute paths** must match the host operating system:
+  - Unix/Linux/macOS: `/home/user/project/file.txt`
+  - Windows: `C:\Users\user\project\file.txt` or `C:/Users/user/project/file.txt`
+- **Home directory expansion**: paths starting with `~` or `~/` expand to the user's home directory.
+
+When a file is not found, error messages include the resolved absolute path to help diagnose incorrect base directories or path formats.
+
+> [!IMPORTANT]
+> Agents must use paths appropriate for the host OS. A Windows absolute path like `C:\file.txt` on a Unix system (or vice versa) is rejected with a clear error message.
+
+### Empty directory detection
+
+When `list_directory` encounters an empty directory or a directory where all entries are hidden by ignore patterns (e.g., only a `.git` folder when `ignore_vcs: true`), it explicitly reports the state:
+
+- **Empty directory**: "Directory is empty: /path/to/dir"
+- **All entries ignored**: "Directory has no visible entries (N hidden by ignore patterns): /path/to/dir"
+
+This helps agents distinguish between an empty directory and a tool failure, avoiding unnecessary retries with shell commands.
+
+## Available Tools
+
+| Tool                   | Description                                                               |
+| ---------------------- | ------------------------------------------------------------------------- |
+| `read_file`            | Read the contents of a file (whole file, or a line range of a text file)  |
+| `read_multiple_files`  | Read several files in one call (more efficient than multiple `read_file`) |
+| `write_file`           | Create or overwrite a file with new content                               |
+| `edit_file`            | Make line-based edits (find-and-replace) in an existing file. Each edit must specify a non-empty `oldText` to match and replace; empty `oldText` values are rejected with an error. |
+| `list_directory`       | List files and directories at a given path (explicitly reports empty directories) |
+| `directory_tree`       | Recursive tree view of a directory                                        |
+| `create_directory`     | Create a new directory (creates parent directories as needed)             |
+| `remove_directory`     | Remove an empty directory                                                 |
+| `search_files_content` | Search for text or regex patterns across files                            |
+
+## edit_file Validation
+
+The `edit_file` tool applies a sequence of find-and-replace edits to a file in memory, then writes the result back atomically. Each edit must provide a non-empty `oldText` value:
+
+- **Valid**: `{"oldText": "line one", "newText": "LINE ONE"}`
+- **Invalid**: `{"oldText": "", "newText": "INJECTED"}` — rejected with error
+
+An empty `oldText` is never a meaningful edit: Go's `strings.Contains(s, "")` is always `true`, and `strings.Replace(s, "", new, 1)` silently inserts at offset 0. Without validation, this would prepend content to the file while still reporting success. The tool now returns an explicit error ("oldText must not be empty") when an edit has an empty `oldText`, and no changes are written to disk.
+
+When a sequence contains multiple edits and a later one is rejected, the entire operation fails and the file is left untouched — edits are applied in memory and only written once at the end, so partial application is not possible.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: filesystem
+```
+
+### Options
+
+| Property | Type | Default | Description |
+| --- | --- | --- | --- |
+| `ignore_vcs` | boolean | `true` | When `true` (default), `.git` directories and `.gitignore` patterns are excluded from listings and searches. Set to `false` to include them. |
+| `post_edit` | array | `[]` | Commands to run after editing files matching a path pattern |
+| `post_edit[].path` | string | — | Glob pattern for files (e.g., `*.go`, `src/*/*.ts`) |
+| `post_edit[].cmd` | string | — | Command to run (use `${file}` for the edited file path) |
+| `allow_list` | array | `[]` | Directories the tools may access. Empty = unrestricted (default). |
+| `deny_list` | array | `[]` | Directories the tools must not access. Takes precedence over `allow_list`. |
+
+### Path access control
+
+By default the filesystem tools are unrestricted: relative paths resolve
+from the working directory, but absolute paths and `..` traversals can
+reach anywhere the agent process can. Configure `allow_list` and/or
+`deny_list` to sandbox the toolset.
+
+Entries in either list are expanded as follows:
+
+- `"."` — the agent's working directory
+- `"~"` or `"~/..."` — the user's home directory
+- `"$VAR"` / `"${VAR}"` / `"${env.VAR}"` — environment variable expansion
+- absolute paths — used as-is
+- relative paths — anchored at the working directory
+
+Symlinks are resolved before the containment check, so a symlink inside an
+allowed root cannot be used to escape it. When an `allow_list` is set,
+each entry is opened as a Go [`*os.Root`](https://pkg.go.dev/os#Root) so
+that the kernel's rooted-lookup semantics also reject `..` and symlink
+escapes at I/O time, not just at resolve time.
+
+```yaml
+toolsets:
+  - type: filesystem
+    # Restrict every operation to the working directory and the user's
+    # home folder, then carve credentials out of the home folder.
+    allow_list:
+      - "."
+      - "~"
+    deny_list:
+      - "~/.ssh"
+      - "~/.aws"
+```
+
+When the path supplied by the agent is rejected, the tool returns a
+structured error rather than performing any filesystem I/O. This makes the
+restriction visible to the model so it can adjust its plan.
+
+### Post-Edit Hooks
+
+Automatically run formatting, linting, or other commands after the agent edits a file. The command fires once per file after each edit operation (`write_file` and `edit_file`). Use `${file}` as a placeholder for the absolute path of the edited file.
+
+```yaml
+toolsets:
+  - type: filesystem
+    ignore_vcs: false
+    post_edit:
+      - path: "*.go"
+        cmd: "gofmt -w ${file}"
+      - path: "*.ts"
+        cmd: "prettier --write ${file}"
+      - path: "src/*/*.py"
+        cmd: "black ${file}"
+```
+
+| Property | Type | Description |
+| --- | --- | --- |
+| `path` | string | Glob pattern matched against the file path. `*.go` matches any `.go` file; `src/*/*.ts` matches `.ts` files inside `src/`. |
+| `cmd` | string | Shell command to run. `${file}` expands to the absolute path of the just-edited file. |
+
+Post-edit commands run with the same working directory as the agent. If a command exits non-zero, the error is logged and surfaced to the model as a warning, but the edit is not rolled back.
+
+See [`examples/post_edit.yaml`](https://github.com/docker/docker-agent/blob/main/examples/post_edit.yaml) for a complete example.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/git/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/git/index.md
new file mode 100644
index 000000000000..9568b7508dfa
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/git/index.md
@@ -0,0 +1,100 @@
+---
+title: "Git Tool"
+description: "Read-only inspection of the working git repository."
+keywords: docker agent, ai agents, tools, toolsets, git tool
+linkTitle: "Git"
+weight: 125
+canonical: https://docs.docker.com/ai/docker-agent/tools/git/
+---
+
+_Read-only inspection of the working git repository._
+
+## Overview
+
+The git toolset gives an agent structured, **read-only** access to the working repository — status, history, branches, a commit's changes, and line-level authorship. It is implemented with go-git, so it needs **no `git` binary**.
+
+Compared with running `git` through the `shell` tool, the git toolset returns clean, structured output the model can read reliably, is **safe by construction** (no command can modify the repository), and works even when `shell` is disabled or no `git` binary is installed.
+
+> [!NOTE]
+> The git toolset is read-only. To stage, commit, or check out, use the [`shell`](../shell/index.md) tool.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: git
+```
+
+No configuration options. The repository is opened at the agent's working directory; a subdirectory still resolves to the repository root.
+
+> [!WARNING]
+> **The repository is discovered by walking up parent directories.** If the working
+> directory is not itself a repository but an ancestor is (for example a
+> home directory tracked as dotfiles), the toolset resolves to that ancestor and
+> `git_show` / `git_blame` can expose its full history and file contents. The
+> filesystem toolset's allow/deny lists do **not** apply here. Only enable this
+> toolset where the surrounding repository is safe to read.
+
+> [!NOTE]
+> **Performance.** go-git is pure Go, which costs speed on large repositories:
+> `git_status` rehashes the whole worktree, and `git_blame` scales with history
+> depth times file size — its 400-line output cap is applied *after* the full
+> computation, so it does not make blaming a large file cheaper.
+
+## Tools
+
+| Tool | Description |
+| --- | --- |
+| `git_status` | Current branch and changed files (staged / unstaged / untracked). |
+| `git_log` | Recent commits (hash, date, author, subject). |
+| `git_branches` | Local branches, current one marked with `*`. |
+| `git_show` | A commit's metadata, message, and changed files with +/- counts. |
+| `git_blame` | Line-by-line authorship for a file. |
+
+### `git_log`
+
+| Parameter | Required | Description |
+| --- | --- | --- |
+| `limit` | No | Maximum number of commits to return (default 20). |
+| `path` | No | Only show commits that touch this path. |
+
+### `git_show`
+
+| Parameter | Required | Description |
+| --- | --- | --- |
+| `ref` | No | Commit hash or revision to show (default HEAD). |
+
+### `git_blame`
+
+| Parameter | Required | Description |
+| --- | --- | --- |
+| `path` | Yes | File path to blame, relative to the repository root. |
+| `rev` | No | Commit or revision to blame at (default HEAD). |
+
+## Example
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5-mini
+    description: A code review assistant
+    instruction: |
+      Review the working changes: check git_status, then git_show the latest
+      commit, and summarize what changed.
+    toolsets:
+      - type: git
+      - type: filesystem
+```
+
+Example `git_status` output:
+
+```text
+On branch master
+1 changed file(s) [XY = staged/worktree; M=modified A=added D=deleted R=renamed ?=untracked]:
+   M main.go
+```
+
+> [!TIP]
+> **When to use**
+>
+> Use the git toolset whenever the agent needs repository context — before editing, to review recent history, or to find who last touched a line — without exposing the writable `shell` surface.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md
new file mode 100644
index 000000000000..4375be03daac
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/handoff/index.md
@@ -0,0 +1,63 @@
+---
+title: "Handoff Tool"
+description: "Hand off the active conversation to another local agent defined in the same config."
+keywords: docker agent, ai agents, tools, toolsets, handoff tool
+linkTitle: "Handoff"
+weight: 70
+canonical: https://docs.docker.com/ai/docker-agent/tools/handoff/
+---
+
+_Hand off the active conversation to another local agent defined in the same config._
+
+## Overview
+
+The `handoff` tool lets an agent transfer control of the **current conversation** to another agent in the **same config file**. Unlike [`transfer_task`](../transfer-task/index.md), which delegates a sub-task and collects the result, `handoff` rewires the session so the receiving agent continues the conversation directly with the user.
+
+This is the core mechanism for **handoffs routing** — a pattern where a router agent classifies the user's request and hands it off to a specialist, which then owns the rest of the session.
+
+> [!NOTE]
+> **Local only**
+>
+> The `handoff` tool only targets agents declared in the **same** config file by their local name. It does **not** open network connections. To delegate to a remote agent over the network, use the [A2A toolset](../a2a/index.md) instead.
+
+## Configuration
+
+The tool is enabled implicitly when an agent declares a non-empty `handoffs:` list. You do **not** add `- type: handoff` under `toolsets:` — it is not a toolset type.
+
+```yaml
+agents:
+  router:
+    model: openai/gpt-4o
+    description: Routes questions to the right specialist
+    instruction: |
+      Classify the user's question and hand off to the most appropriate
+      specialist. If unsure, ask a clarifying question first.
+    handoffs: [billing, support]
+
+  billing:
+    model: openai/gpt-4o
+    description: Billing specialist
+    instruction: Answer billing questions.
+
+  support:
+    model: openai/gpt-4o
+    description: Technical support specialist
+    instruction: Help with technical issues.
+```
+
+The router agent automatically gets a `handoff` tool it can call to switch the conversation to `billing` or `support`.
+
+## Tool Interface
+
+The `handoff` tool takes a single parameter:
+
+| Parameter | Type   | Required | Description                                                       |
+| --------- | ------ | -------- | ----------------------------------------------------------------- |
+| `agent`   | string | ✓        | The local name of the agent to hand off the conversation to.      |
+
+Only names listed in the current agent's `handoffs:` field are valid targets.
+
+> [!TIP]
+> **See also**
+>
+> For sub-task delegation (caller stays in control, waits for the result), see [Transfer Task](../transfer-task/index.md). For remote agent connections over the network, see the [A2A toolset](../a2a/index.md). For the broader pattern, see [Handoffs Routing](../../concepts/multi-agent/index.md#handoffs-routing).
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md
new file mode 100644
index 000000000000..b2d97b7227b6
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md
@@ -0,0 +1,227 @@
+---
+title: "LSP Tool"
+description: "Connect to Language Server Protocol servers for code intelligence."
+keywords: docker agent, ai agents, tools, toolsets, lsp tool
+linkTitle: "LSP"
+weight: 220
+canonical: https://docs.docker.com/ai/docker-agent/tools/lsp/
+---
+
+_Connect to Language Server Protocol servers for code intelligence._
+
+## Overview
+
+The LSP tool connects your agent to any Language Server Protocol (LSP) server, providing comprehensive code intelligence capabilities like go-to-definition, find references, diagnostics, and more.
+
+> [!NOTE]
+> **What is LSP?**
+>
+> The [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) is a standard for providing language features like autocomplete, go-to-definition, and diagnostics. Most programming languages have LSP servers available.
+
+## Available Tools
+
+The LSP toolset provides these tools to the agent:
+
+| Tool                    | Description                                   | Read-Only |
+| ----------------------- | --------------------------------------------- | --------- |
+| `lsp_workspace`         | Get workspace info and available capabilities | ✓         |
+| `lsp_hover`             | Get type info and documentation for a symbol  | ✓         |
+| `lsp_definition`        | Find where a symbol is defined                | ✓         |
+| `lsp_references`        | Find all references to a symbol               | ✓         |
+| `lsp_document_symbols`  | List all symbols in a file                    | ✓         |
+| `lsp_workspace_symbols` | Search symbols across the workspace           | ✓         |
+| `lsp_diagnostics`       | Get errors and warnings for a file            | ✓         |
+| `lsp_code_actions`      | Get available quick fixes and refactorings    | ✓         |
+| `lsp_rename`            | Rename a symbol across the workspace          | ✗         |
+| `lsp_format`            | Format a file                                 | ✗         |
+| `lsp_call_hierarchy`    | Find incoming/outgoing calls                  | ✓         |
+| `lsp_type_hierarchy`    | Find supertypes/subtypes                      | ✓         |
+| `lsp_implementations`   | Find interface implementations                | ✓         |
+| `lsp_signature_help`    | Get function signature at call site           | ✓         |
+| `lsp_inlay_hints`       | Get type annotations and parameter names      | ✓         |
+
+## Configuration
+
+```yaml
+agents:
+  developer:
+    model: anthropic/claude-sonnet-4-5
+    description: Code developer with LSP support
+    instruction: You are a software developer.
+    toolsets:
+      - type: lsp
+        command: gopls
+        args: []
+        file_types: [".go"]
+      - type: filesystem
+      - type: shell
+```
+
+## Properties
+
+| Property      | Type   | Required | Description                                                                                                                  |
+| ------------- | ------ | -------- | ---------------------------------------------------------------------------------------------------------------------------- |
+| `command`     | string | ✓        | LSP server executable command                                                                                                |
+| `args`        | array  | ✗        | Command-line arguments for the LSP server                                                                                    |
+| `env`         | object | ✗        | Environment variables for the LSP process                                                                                    |
+| `file_types`  | array  | ✗        | File extensions this LSP handles (e.g., `[".go", ".mod"]`)                                                                   |
+| `working_dir` | string | ✗        | Working directory for the LSP server process. Relative paths are resolved against the agent's working directory. Defaults to the agent's working directory when omitted. |
+| `version`     | string | ✗        | Package reference for [auto-installing](../../configuration/tools/index.md#auto-installing-tools) the command binary |
+
+## Common LSP Servers
+
+Here are configurations for popular languages:
+
+### Go (gopls)
+
+```yaml
+toolsets:
+  - type: lsp
+    command: gopls
+    version: "golang/tools@v0.21.0" # optional: auto-install if not in PATH
+    file_types: [".go"]
+```
+
+If your Go module lives in a subdirectory (e.g. a monorepo where `go.mod` is under `./backend`), set `working_dir` so `gopls` is started from the module root:
+
+```yaml
+toolsets:
+  - type: lsp
+    command: gopls
+    file_types: [".go"]
+    working_dir: ./backend # gopls must be started from the module root
+```
+
+### TypeScript/JavaScript (typescript-language-server)
+
+```yaml
+toolsets:
+  - type: lsp
+    command: typescript-language-server
+    args: ["--stdio"]
+    file_types: [".ts", ".tsx", ".js", ".jsx"]
+```
+
+### Python (pylsp)
+
+```yaml
+toolsets:
+  - type: lsp
+    command: pylsp
+    file_types: [".py"]
+```
+
+### Rust (rust-analyzer)
+
+```yaml
+toolsets:
+  - type: lsp
+    command: rust-analyzer
+    file_types: [".rs"]
+```
+
+### C/C++ (clangd)
+
+```yaml
+toolsets:
+  - type: lsp
+    command: clangd
+    file_types: [".c", ".cpp", ".h", ".hpp"]
+```
+
+## Multiple LSP Servers
+
+You can configure multiple LSP servers for different file types:
+
+```yaml
+agents:
+  polyglot:
+    model: anthropic/claude-sonnet-4-5
+    description: Multi-language developer
+    instruction: You are a full-stack developer.
+    toolsets:
+      - type: lsp
+        command: gopls
+        file_types: [".go"]
+      - type: lsp
+        command: typescript-language-server
+        args: ["--stdio"]
+        file_types: [".ts", ".tsx", ".js", ".jsx"]
+      - type: lsp
+        command: pylsp
+        file_types: [".py"]
+      - type: filesystem
+      - type: shell
+```
+
+## Workflow Instructions
+
+The LSP tool includes built-in instructions that guide the agent on how to use it effectively. The agent learns to:
+
+1. Start with `lsp_workspace` to understand available capabilities
+2. Use `lsp_workspace_symbols` to find relevant code
+3. Use `lsp_references` before modifying any symbol
+4. Check `lsp_diagnostics` after every code change
+5. Apply `lsp_format` after edits are complete
+
+> [!TIP]
+> **Best Practice**
+>
+> Always include the `filesystem` tool alongside LSP. The agent needs filesystem access to read and write code files, while LSP provides intelligence about the code.
+
+## Capability Detection
+
+Not all LSP servers support all features. During the `initialize` handshake, Docker Agent reads the server's `ServerCapabilities` and **filters out the `lsp_*` tools the server does not advertise**. The model never sees, for example, `lsp_inlay_hints` against a server that doesn't support it, so it can't waste a turn calling a tool that would only fail.
+
+The agent uses `lsp_workspace` to discover what's available:
+
+```text
+Workspace Information:
+- Root: /path/to/project
+- Server: gopls v0.14.0
+- File types: .go
+
+Available Capabilities:
+- Hover: Yes
+- Go to Definition: Yes
+- Find References: Yes
+- Rename: Yes
+- Code Actions: Yes
+- Formatting: Yes
+- Call Hierarchy: Yes
+- Type Hierarchy: Yes
+...
+```
+
+## Auto-Restart and Lifecycle
+
+LSP toolsets are managed by the same supervisor as MCP toolsets, so a crashed `gopls` (or any other language server) is reconnected automatically with exponential backoff. Use the [`lifecycle`](../../configuration/tools/index.md#toolset-lifecycle) block to tune the policy per toolset — for example, mark `gopls` as `strict` if your CI flow requires it to be available, or use `/toolset-restart gopls` from the TUI to force a reconnect when the server gets stuck.
+
+```yaml
+toolsets:
+  - type: lsp
+    command: gopls
+    file_types: [".go"]
+    lifecycle:
+      profile: resilient # default: auto-restart on crash with exponential backoff
+```
+
+## Position Format
+
+All LSP tools use **1-based** line and character positions:
+
+- Line 1 is the first line of the file
+- Character 1 is the first character on a line
+
+```json
+{
+  "file": "/path/to/file.go",
+  "line": 42,
+  "character": 15
+}
+```
+
+> [!TIP]
+> **Auto-Installation**
+>
+> Docker Agent can automatically download and install LSP servers if they are not found in your PATH. Use the `version` property to specify a package, or let Docker Agent auto-detect it from the command name. See [Auto-Installing Tools](../../configuration/tools/index.md#auto-installing-tools) for details.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md
new file mode 100644
index 000000000000..d395a3ef6de7
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md
@@ -0,0 +1,113 @@
+---
+title: "MCP Catalog Tool"
+description: "Let the agent discover and activate remote MCP servers from the Docker MCP Catalog on demand."
+keywords: docker agent, ai agents, tools, toolsets, mcp catalog tool
+linkTitle: "MCP Catalog"
+weight: 120
+canonical: https://docs.docker.com/ai/docker-agent/tools/mcp-catalog/
+---
+
+_Let the agent discover and activate remote MCP servers from the Docker MCP Catalog on demand._
+
+## Overview
+
+The `mcp_catalog` toolset gives an agent access to a curated subset of the [Docker MCP Catalog](https://hub.docker.com/search?q=&type=mcp) — every server in this subset is reachable over the **streamable-http** transport, so Docker Agent can talk to it directly without the MCP gateway or a local subprocess.
+
+Servers are **not** active by default. Instead, the toolset exposes a small set of meta-tools the agent uses to search, enable, and disable servers as a turn unfolds. Tools from un-enabled servers stay hidden, so the prompt is not flooded with hundreds of tool definitions the agent will never use.
+
+> [!NOTE]
+> **When to use it**
+>
+> Use `mcp_catalog` when you want the agent to _decide at runtime_ which third-party services it needs (Notion, Stripe, Brave Search, …) instead of pinning that decision in YAML up front. For a fixed set of servers, declare each one with [`type: mcp`](../../configuration/tools/index.md#mcp-tools) directly — the catalog adds an extra layer of meta-tools that pure `type: mcp` entries do not need.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: mcp_catalog
+```
+
+The catalog is embedded in the `docker-agent` binary and refreshed with each release. By default every server in the embedded subset is offered.
+
+### Restricting the offered servers
+
+Two optional lists narrow what the toolset offers, so an agent sees a focused, predictable menu instead of the full catalog:
+
+- **`allowed_servers`** — when non-empty, **only** these catalog server ids are searchable and enableable; every other entry is hidden.
+- **`blocked_servers`** — removes individual ids from the offered set. It is applied **after** `allowed_servers`, so a server listed in both is blocked (block wins over allow).
+
+Both take server ids (the `id` field returned by `search_remote_mcp_servers`). An empty or omitted list disables that filter.
+
+```yaml
+toolsets:
+  - type: mcp_catalog
+    allowed_servers:
+      - docker-docs
+      - microsoft-learn
+      - hugging-face
+    blocked_servers:
+      - gitmcp
+```
+
+## Meta-Tools
+
+Up to five tools are exposed to the model. The disable / reset-auth pair only appears once at least one server is enabled, so the meta-tool surface stays minimal until the agent activates something.
+
+| Tool                            | When visible            | Description                                                                                                                                          |
+| ------------------------------- | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `search_remote_mcp_servers`     | Always                  | Case-insensitive fuzzy search over id, title, description, category and tags. Returns id, auth requirements (`oauth` / `none`) and URL. |
+| `enable_remote_mcp_server`      | Always                  | Activate a server by id. **Blocks** until the connection (and any required OAuth handshake) completes; on success the server's tools are immediately live and the model continues with the user's original request in the same turn. |
+| `list_remote_mcp_servers`       | Always                  | Show currently enabled servers and their connection state.                                                                                           |
+| `disable_remote_mcp_server`     | After first enable      | Stop a server and remove its tools from the active set.                                                                                              |
+| `reset_remote_mcp_server_auth`  | After first enable      | Drop persisted OAuth credentials so the next enable triggers a fresh authorization flow. No-op for `none` servers.                       |
+
+### Workflow
+
+1. The agent calls `search_remote_mcp_servers` with a keyword matching the user's intent (`"notion"`, `"stripe"`, `"docs"`, `"browser"`, `"grafana"`, …).
+2. It picks a matching server id and calls `enable_remote_mcp_server`. **`enable` blocks** until the MCP handshake (and any required OAuth flow) completes:
+   - on success the server's tools are available **in the same turn** — the agent goes straight to the user's original request, no re-ask required;
+   - on failure (user dismissed the authorization dialog, server refused) the tool returns an error result naming the specific reason so the agent can recover instead of pretending the server is connected.
+3. It uses the newly activated tools as it would any other.
+4. When done, it calls `disable_remote_mcp_server` to remove the server from the active set.
+
+## Authentication
+
+The catalog only includes servers Docker Agent can authenticate itself, so there are two auth flavours:
+
+- **`oauth`** — `enable_remote_mcp_server` surfaces an authorization URL through the elicitation pipeline (the same one used by YAML-declared remote MCP toolsets) and blocks until the user either authorizes or cancels. Once the user authorizes, tokens are persisted in the OS keyring and re-used on subsequent runs. Use `reset_remote_mcp_server_auth` to wipe them. If the user dismisses the dialog, `enable` returns an error result naming the decline so the agent can ask whether to retry.
+- **`none`** — No authentication. The server is reachable as soon as it is enabled.
+
+Servers that require a caller-provided API key are intentionally excluded from the catalog. To use one, declare it explicitly with [`type: mcp`](../../configuration/tools/index.md#mcp-tools) and supply the key via an environment variable.
+
+## Example
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Agent that can on-demand connect to remote MCP servers from the Docker MCP Catalog.
+    instruction: |
+      You can discover and activate remote MCP servers on demand.
+      Use search_remote_mcp_servers to find a server matching the
+      user's intent, then enable_remote_mcp_server to activate it.
+      Be conservative: enable only the servers you actually need for
+      the task at hand. Disable a server with disable_remote_mcp_server
+      once you are done with it.
+    toolsets:
+      - type: mcp_catalog
+```
+
+A complete, runnable configuration lives in [`examples/mcp_catalog.yaml`](https://github.com/docker/docker-agent/blob/main/examples/mcp_catalog.yaml). A curated, allow/block-listed variant lives in [`examples/mcp_catalog_filtered.yaml`](https://github.com/docker/docker-agent/blob/main/examples/mcp_catalog_filtered.yaml).
+
+## Notes and Limitations
+
+- **Streamable-http only.** The catalog deliberately excludes servers that require a local subprocess or the MCP gateway — declare those with [`type: mcp`](../../configuration/tools/index.md#mcp-tools) instead.
+- **Catalog membership changes between releases.** The set of available servers is updated with each Docker Agent release as integrations are added or removed. Servers present in one release may not appear in the next.
+- **Blocking enable.** DNS, TCP, MCP handshake and any OAuth flow happen synchronously inside `enable_remote_mcp_server` so the agent gets a deterministic result in the same turn. On startup, however, the runtime probes tools non-interactively (`mcp.WithoutInteractivePrompts`); OAuth-pending servers fail fast there and are silently deferred to the next interactive turn — including the sidebar-only tool-count pass, where a dialog would be impossible.
+- **No prompt discovery.** MCP prompt lookups (`/prompts`) walk YAML-declared `mcp` toolsets directly; prompts exposed by servers activated through the catalog are not surfaced. Tools — the primary interface — work fine.
+- **Frozen at build time.** The list of servers is embedded in the binary. New entries land with each Docker Agent release.
+
+> [!TIP]
+> **Pair with permissions**
+>
+> Because the agent decides which third-party services to talk to, this toolset works best with explicit [permissions](../../configuration/permissions/index.md) on the surrounding tools (filesystem writes, shell commands) so a misrouted server cannot exfiltrate data unnoticed.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md
new file mode 100644
index 000000000000..b1acb0cca7ea
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md
@@ -0,0 +1,309 @@
+---
+title: "MCP Tool"
+description: "Extend agents with external tools via the Model Context Protocol."
+keywords: docker agent, ai agents, tools, toolsets, mcp tool
+linkTitle: "MCP"
+weight: 130
+canonical: https://docs.docker.com/ai/docker-agent/tools/mcp/
+aliases:
+  - /ai/docker-agent/integrations/mcp/
+---
+
+_Extend agents with external tools via the Model Context Protocol (MCP)._
+
+## Overview
+
+The `mcp` toolset connects your agent to any MCP server — a process or remote service that exposes tools, resources, and prompts over the [Model Context Protocol](https://modelcontextprotocol.io/). Three flavours are supported:
+
+| Flavour | Transport | Best for |
+| --- | --- | --- |
+| **Docker MCP** | Container via the [MCP Gateway](https://github.com/docker/mcp-gateway) | Curated, sandboxed servers from the [Docker MCP Catalog](https://hub.docker.com/u/mcp) |
+| **Local stdio** | Subprocess over stdin/stdout | Custom or community MCP servers run from a binary or `npx`/`pip` package |
+| **Remote** | Streamable HTTP or SSE | Cloud services with hosted MCP endpoints (Linear, Notion, Atlassian, …) |
+
+> [!NOTE]
+> **What is MCP?**
+>
+> The [Model Context Protocol](https://modelcontextprotocol.io/) is an open standard for connecting AI tools. Docker Agent can both _use_ MCP servers (this page) and _expose_ agents as MCP servers — see [MCP Mode](../../features/mcp-mode/index.md).
+
+## Docker MCP (Recommended)
+
+Run MCP servers as secure Docker containers via the MCP Gateway. The `ref: docker:<name>` syntax pulls a curated definition from the Docker MCP Catalog:
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:duckduckgo        # web search
+  - type: mcp
+    ref: docker:github-official   # GitHub integration
+    tools: ["list_issues", "create_issue"]
+```
+
+Browse available servers at the [Docker MCP Catalog](https://hub.docker.com/u/mcp).
+
+| Property      | Type   | Description                                                      |
+| ------------- | ------ | ---------------------------------------------------------------- |
+| `ref`         | string | Docker MCP reference (`docker:name`) or a name from the [reusable `mcps:`](../../configuration/overview/index.md#reusable-mcp-servers-mcps) block. |
+| `tools`       | array  | Optional whitelist — only expose these tools to the model.       |
+| `instruction` | string | Custom instructions injected into the agent's context.           |
+| `config`      | any    | MCP server-specific configuration passed during initialization.  |
+| `working_dir` | string | Working directory for the MCP gateway subprocess. Only applies when the catalog entry runs as a local process (not remote). Relative paths are resolved against the agent's working directory. Supports `${env.VAR}` (canonical), plus `~` and shell-style `$VAR`/`${VAR}` expansion ([details](../../configuration/overview/index.md#variable-expansion-in-config-fields)). |
+
+## Local MCP (stdio)
+
+Run MCP servers as local processes communicating over stdin/stdout:
+
+```yaml
+toolsets:
+  - type: mcp
+    command: python
+    args: ["-m", "mcp_server"]
+    tools: ["search", "fetch"]
+    env:
+      API_KEY: value
+```
+
+| Property      | Type   | Description |
+| ------------- | ------ | ----------- |
+| `command`     | string | Command to execute the MCP server. |
+| `args`        | array  | Command arguments. |
+| `tools`       | array  | Optional whitelist — only expose these tools. |
+| `env`         | object | Environment variables (key-value pairs). |
+| `working_dir` | string | Working directory for the MCP server process. Relative paths are resolved against the agent's working directory. Defaults to the agent's working directory when omitted. Supports `${env.VAR}` (canonical), plus `~` and shell-style `$VAR`/`${VAR}` expansion ([details](../../configuration/overview/index.md#variable-expansion-in-config-fields)). |
+| `instruction` | string | Custom instructions injected into the agent's context. |
+| `version`     | string | Package reference for [auto-installing](../../configuration/tools/index.md#auto-installing-tools) the command binary. |
+
+> [!TIP]
+> **Auto-installation**
+>
+> If the `command` is not in your `PATH`, Docker Agent looks it up in the [aqua registry](https://github.com/aquaproj/aqua-registry) and installs it for you. Use `version: "false"` to opt out, or set `DOCKER_AGENT_AUTO_INSTALL=false` globally. See [Auto-Installing Tools](../../configuration/tools/index.md#auto-installing-tools).
+
+## Remote MCP (Streamable HTTP / SSE)
+
+Connect to MCP servers over the network. OAuth flows (including [Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591)) are handled automatically — Docker Agent opens your browser when authentication is required and caches tokens for subsequent sessions. Tokens are refreshed silently when they expire or are revoked server-side; if a silent refresh is not possible, the OAuth prompt reappears on the next message.
+
+```yaml
+toolsets:
+  - type: mcp
+    remote:
+      url: "https://mcp.linear.app/mcp"
+      transport_type: "streamable"               # or "sse" for legacy servers
+      headers:
+        Authorization: "Bearer ${env.LINEAR_TOKEN}"
+    # Optional: allow OAuth helper requests to reach private/internal IPs.
+    allow_private_ips: false
+    tools: ["search_issues", "create_issue"]
+```
+
+| Property                | Type    | Description |
+| ----------------------- | ------- | ----------- |
+| `remote.url`            | string  | Base URL of the MCP server. |
+| `remote.transport_type` | string  | `streamable` or `sse`. |
+| `remote.headers`        | object  | HTTP headers sent on every request. Values support `${env.VAR}` and `${headers.NAME}` placeholders, resolved per request. See [Remote MCP Servers](../../features/remote-mcp/index.md#per-request-header-template-expansion) for details. |
+| `remote.oauth`          | object  | Explicit OAuth client credentials for servers that don't support DCR. See [Remote MCP Servers](../../features/remote-mcp/index.md#oauth-for-servers-without-dynamic-client-registration). |
+| `allow_private_ips`     | boolean | Permit remote MCP OAuth helper requests to dial non-public IP addresses. Use only for trusted internal servers. |
+
+For a curated list of public remote MCP endpoints (Linear, GitHub, Vercel, Notion, …) and full OAuth configuration details, see [Remote MCP Servers](../../features/remote-mcp/index.md).
+
+## MCP Prompts
+
+MCP servers can expose **prompts** — named, parameterized templates that the server provides via the `/prompts` endpoint. Docker Agent discovers these at toolset startup and registers them as **slash commands** in the TUI, so you can invoke them directly from the input box.
+
+```text
+# Type / to see available prompts alongside built-in commands
+/review         # invoke an MCP prompt named "review"
+/summarize My text here   # invoke with the first argument filled in
+```
+
+**How it works:**
+
+- Each MCP prompt appears in the command palette (accessible via <kbd>Ctrl</kbd>+<kbd>K</kbd>) under the **MCP Prompts** category.
+- Typing `/<prompt-name>` in the input box invokes the prompt immediately.
+- If the prompt declares arguments and you provide text after the slash command, that text is mapped to the first declared argument.
+- If a required argument is missing, Docker Agent opens the argument input dialog before running the prompt.
+- When no argument is needed or all required arguments are supplied, the prompt runs immediately.
+
+> [!NOTE]
+> MCP prompt discovery requires a YAML-declared `mcp` toolset. Prompts from servers activated through the [Docker MCP Catalog](../../tools/mcp-catalog/index.md) (`ref: docker:<name>`) are not currently surfaced.
+
+## Embedded Resources
+
+MCP tool results can include embedded resources — images, PDFs, and text files returned directly in the tool response. Docker Agent preserves these as attachments and forwards them to the model as native content blocks:
+
+- **Anthropic** — images become `image` blocks in the `tool_result`; PDFs and other documents become `document` blocks.
+- **OpenAI** — images are forwarded as `input_image` data URIs; PDFs as `input_file` data URIs in the tool result content.
+- **Bedrock** and **Gemini** — receive equivalent provider-native representations.
+
+No configuration is required. When an MCP server returns an embedded resource alongside its text output, the resource is automatically attached and sent to the model on the next turn. This is useful for MCP servers that generate charts, export PDFs, or return binary data as part of their responses.
+
+## Reusable Definitions (`mcps:`)
+
+Repeated MCP server configurations can be hoisted into the top-level `mcps:` section and referenced by name with `{type: mcp, ref: <name>}`:
+
+```yaml
+mcps:
+  github:
+    remote:
+      url: https://api.githubcopilot.com/mcp
+      transport_type: sse
+  playwright:
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-playwright"]
+
+agents:
+  root:
+    model: openai/gpt-5
+    toolsets:
+      - type: mcp
+        ref: github
+      - type: mcp
+        ref: playwright
+```
+
+See [Reusable MCP Servers](../../configuration/overview/index.md#reusable-mcp-servers-mcps) for the full reference.
+
+## Common Options
+
+These properties apply to every MCP toolset regardless of flavour:
+
+### Tool filtering
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    tools: ["list_issues", "create_issue", "get_pull_request"]
+```
+
+Whitelisting tools improves model accuracy — fewer choices means less confusion.
+
+### Deferred loading
+
+Skip the toolset's startup cost until its tools are actually called:
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    defer: true
+  # Or defer specific tools within a toolset:
+  - type: mcp
+    ref: docker:slack
+    defer: ["list_channels", "search_messages"]
+```
+
+### Custom instructions
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    instruction: |
+      Use these tools to manage GitHub issues.
+      Always check for existing issues before creating new ones.
+      Label new issues with 'triage' by default.
+```
+
+### TOON-encoded outputs
+
+Re-encode verbose JSON outputs as the compact [TOON](https://github.com/alpkeskin/gotoon) format to save context budget. Typically yields 30–60% smaller payloads on list/search tools.
+
+`toon` is a regex string that is matched against tool names. Any tool whose name matches the pattern has its JSON output transparently re-encoded as TOON before it is shown to the model. The re-encoding reduces schema verbosity, which is especially useful when a model struggles with large or repetitive tool output.
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    toon: ".*"            # toonify every tool from this server
+  - type: mcp
+    command: my-server
+    toon: "list_.*,get_.*" # only toonify list_/get_ tools
+```
+
+The value is a comma-separated list of regexes (or a single regex). A tool name must match at least one pattern to be re-encoded. Setting `toon: ".*"` re-encodes all tools from that toolset.
+
+See [`examples/github-toon.yaml`](https://github.com/docker/docker-agent/blob/main/examples/github-toon.yaml) for a practical example using the GitHub MCP server.
+
+### Per-toolset model routing
+
+Process tool results from this toolset with a different (typically cheaper / faster) model. The override is one-shot — subsequent turns return to the agent's primary model:
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:github-official
+    model: openai/gpt-4o-mini
+```
+
+See [Per-Toolset Model Routing](../../configuration/tools/index.md#per-toolset-model-routing).
+
+### Lifecycle (auto-restart, profiles)
+
+Local stdio and remote MCP servers are supervised: crashed servers reconnect automatically with exponential backoff. **Remote** MCP servers (Streamable HTTP / SSE) also reconnect after idle/clean connection closes — services like Notion and Linear periodically close idle connections, and Docker Agent reconnects transparently. Tune the policy with the `lifecycle` block:
+
+```yaml
+toolsets:
+  - type: mcp
+    ref: docker:duckduckgo
+    lifecycle:
+      profile: resilient   # default; auto-restart with backoff
+  - type: mcp
+    command: docker
+    args: ["mcp", "gateway"]
+    lifecycle:
+      profile: strict      # fail-fast: required, no retries
+```
+
+See [Toolset Lifecycle](../../configuration/tools/index.md#toolset-lifecycle) for all profiles and tuning knobs, and [`/toolset-restart`](../../features/tui/index.md) to force a reconnect from the TUI.
+
+## Combined Example
+
+```yaml
+mcps:
+  github:
+    remote:
+      url: https://api.githubcopilot.com/mcp
+      transport_type: sse
+
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Full-featured developer assistant
+    instruction: You are an expert developer.
+    toolsets:
+      # Docker MCP catalog entry
+      - type: mcp
+        ref: docker:duckduckgo
+
+      # Reusable definition from the top-level mcps: block
+      - type: mcp
+        ref: github
+        tools: ["list_issues", "create_issue"]
+        toon: "list_.*"
+
+      # Local stdio server with auto-install
+      - type: mcp
+        command: gopls
+        version: "golang/tools@v0.21.0"
+        args: ["mcp"]
+
+      # Remote MCP with OAuth (handled automatically)
+      - type: mcp
+        remote:
+          url: "https://mcp.linear.app/mcp"
+          transport_type: "streamable"
+        instruction: Use Linear for issue tracking.
+```
+
+> [!WARNING]
+> **Toolset order matters**
+>
+> If multiple toolsets provide a tool with the same name, the first one wins: the duplicate from the later toolset is ignored and a warning identifies both toolsets. Order your toolsets intentionally. To keep both tools callable, give the MCP toolset a unique `name:` (its tools are then exposed as `<name>_<tool>`) or restrict the overlapping toolset with its `tools:` filter.
+
+## See Also
+
+- [Tool Configuration](../../configuration/tools/index.md) — full reference for every toolset type, plus shared options (lifecycle, TOON, model routing, …).
+- [Reusable MCP Servers](../../configuration/overview/index.md#reusable-mcp-servers-mcps) — the top-level `mcps:` block.
+- [Remote MCP Servers](../../features/remote-mcp/index.md) — catalog of public remote MCP endpoints + OAuth recipes.
+- [MCP Mode](../../features/mcp-mode/index.md) — expose your own agents as MCP tools to Claude Desktop, Claude Code, etc.
+- [Auto-Installing Tools](../../configuration/tools/index.md#auto-installing-tools) — automatic installation of MCP server binaries.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md
new file mode 100644
index 000000000000..1e5671a304ea
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/memory/index.md
@@ -0,0 +1,59 @@
+---
+title: "Memory Tool"
+description: "Persistent key-value storage backed by SQLite for cross-session recall."
+keywords: docker agent, ai agents, tools, toolsets, memory tool
+linkTitle: "Memory"
+weight: 100
+canonical: https://docs.docker.com/ai/docker-agent/tools/memory/
+---
+
+_Persistent key-value storage backed by SQLite for cross-session recall._
+
+## Overview
+
+The memory tool provides persistent key-value storage backed by SQLite. Data survives across sessions, allowing agents to remember facts, user preferences, project context, and past decisions. Memories can be organized with categories and searched by keyword.
+
+By default, the database is stored at `~/.cagent/memory/<config-name>/memory.db`, where `<config-name>` is derived from the loaded configuration (typically the YAML file name) and falls back to `default` when unavailable. When the agent is loaded from an OCI reference (e.g. `docker/my-agent:latest`), characters that are reserved in filesystem paths (such as `:`) are sanitised in the `<config-name>` segment — the agent's display name elsewhere is unchanged. Agents declared in the same configuration share this database by default; set an explicit `path` per toolset to isolate them.
+
+## Available Tools
+
+| Tool              | Description                                                                      |
+| ----------------- | -------------------------------------------------------------------------------- |
+| `add_memory`      | Store a new memory with optional category                                        |
+| `get_memories`    | Retrieve all stored memories                                                     |
+| `delete_memory`   | Delete a specific memory by ID                                                   |
+| `search_memories` | Search memories by keywords and/or category (more efficient than `get_memories`) |
+| `update_memory`   | Update an existing memory's content and/or category by ID                        |
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: memory
+```
+
+### Options
+
+| Property | Type   | Default                                   | Description                      |
+| -------- | ------ | ----------------------------------------- | -------------------------------- |
+| `path`   | string | `~/.cagent/memory/<config-name>/memory.db` | Path to the SQLite database file |
+
+### Custom Database Path
+
+```yaml
+toolsets:
+  - type: memory
+    path: ./agent_memory.db
+```
+
+## Categories
+
+Memories support an optional `category` field for organization and filtering. Common categories include:
+
+- `preference` — User preferences and settings
+- `fact` — Factual information about the project or user
+- `project` — Project-specific context
+- `decision` — Past decisions and their rationale
+
+> [!TIP]
+> Memory is especially useful for long-running assistants that need to recall information across conversations — like coding preferences, project conventions, or context discovered during previous sessions.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md
new file mode 100644
index 000000000000..0c0d4613021c
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/model-picker/index.md
@@ -0,0 +1,73 @@
+---
+title: "Model Picker Tool"
+description: "Let the agent pick between several models per turn."
+keywords: docker agent, ai agents, tools, toolsets, model picker tool
+linkTitle: "Model Picker"
+weight: 200
+canonical: https://docs.docker.com/ai/docker-agent/tools/model-picker/
+---
+
+_Let the agent pick between several models per turn._
+
+## Overview
+
+The model picker tool gives an agent the ability to dynamically choose which model to use for each turn of the conversation. This is useful when you want the agent to route different types of requests to different models — for example, using a fast, inexpensive model for simple queries and a more capable model for complex reasoning tasks.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: model_picker
+    models:
+      - openai/gpt-5-mini
+      - anthropic/claude-sonnet-4-5
+      - openai/gpt-5
+```
+
+### Options
+
+| Property | Type           | Required | Description                                                  |
+| -------- | -------------- | -------- | ------------------------------------------------------------ |
+| `models` | array[string]  | ✓        | List of model references the agent can choose from. Use `provider/model` format. |
+
+## How It Works
+
+When the model picker toolset is enabled, the agent gets two tools: `change_model` to switch to one of the configured models, and `revert_model` to return to its default model. The agent decides which model to use based on the complexity of the task, cost considerations, or other factors you describe in its instruction.
+
+## Example
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5-mini  # Default model
+    instruction: |
+      You are a helpful assistant. For simple questions, use gpt-5-mini.
+      For complex reasoning or coding tasks, switch to claude-sonnet-4-5 or gpt-5.
+    toolsets:
+      - type: model_picker
+        models:
+          - openai/gpt-5-mini
+          - anthropic/claude-sonnet-4-5
+          - openai/gpt-5
+```
+
+> [!TIP]
+> **Cost optimization**
+>
+> The model picker tool is particularly useful for cost optimization: let the agent use a cheap model by default and only escalate to expensive models when necessary.
+
+## Tool Interface
+
+The toolset exposes two tools:
+
+### `change_model`
+
+| Parameter | Type   | Required | Description                                                                 |
+| --------- | ------ | -------- | --------------------------------------------------------------------------- |
+| `model`   | string | ✓        | The model to switch to. Must be one of the configured models.               |
+
+### `revert_model`
+
+Takes no parameters. Reverts the agent to its original/default model.
+
+The switch takes effect immediately: the next inference call — including the remainder of the current agentic loop — uses the new model.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md
new file mode 100644
index 000000000000..b2a97dd44b36
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md
@@ -0,0 +1,95 @@
+---
+title: "Open URL Tool"
+description: "Open a fixed URL in the user's default browser."
+keywords: docker agent, ai agents, tools, toolsets, open url tool
+linkTitle: "Open URL"
+weight: 40
+canonical: https://docs.docker.com/ai/docker-agent/tools/open-url/
+---
+
+_Open a fixed URL in the user's default browser._
+
+## Overview
+
+The `open_url` toolset exposes a single, argument-less tool that opens a URL
+baked into the toolset definition in the user's default browser. The model
+never supplies the URL — it just calls the tool by name. Launching the browser
+is cross-platform: Docker Agent uses `open` on macOS, `xdg-open` on Linux, and
+`rundll32` on Windows.
+
+> [!NOTE]
+> **When to Use**
+>
+> - Letting an agent open a dashboard, documentation page, or deep link on demand
+> - Deep-linking into a desktop app via a custom URI scheme (e.g. `docker-desktop://`)
+> - Any "take me there" action where the destination is fixed and known up front
+
+## Configuration
+
+```yaml
+agents:
+  assistant:
+    model: openai/gpt-4o
+    description: Assistant that can open the dashboard
+    instruction: When the user asks to see the dashboard, call open_dashboard.
+    toolsets:
+      - type: open_url
+        name: open_dashboard
+        url: https://example.com/dashboard
+```
+
+## Properties
+
+| Property | Type   | Required | Description                                                                                          |
+| -------- | ------ | -------- | ---------------------------------------------------------------------------------------------------- |
+| `url`    | string | ✓        | URL to open. Supports `${env.VAR}` interpolation. Any scheme the OS can dispatch is allowed.         |
+| `name`   | string | ✗        | Tool name the agent references. Defaults to `open_url`. Use a descriptive name when configuring several. |
+
+## Multiple URLs
+
+Add one toolset entry per destination, each with its own `name`:
+
+```yaml
+toolsets:
+  - type: open_url
+    name: open_dashboard
+    url: https://example.com/dashboard
+  - type: open_url
+    name: open_docs
+    url: https://docs.example.com/${env.DOCS_VERSION}
+```
+
+## URL Interpolation
+
+The `url` field supports `${env.VAR}` placeholders, expanded at call time
+against the runtime environment:
+
+```yaml
+toolsets:
+  - type: open_url
+    name: open_docs
+    url: https://docs.example.com/${env.DOCS_VERSION}
+```
+
+## Custom URI Schemes
+
+Any scheme the operating system knows how to dispatch works, including deep
+links into desktop applications:
+
+```yaml
+toolsets:
+  - type: open_url
+    name: open_in_docker_desktop
+    url: docker-desktop://dashboard/apps
+```
+
+## Limitations
+
+- The URL must include a scheme (e.g. `https://`); bare paths are rejected.
+- URLs that look like a command-line flag (starting with `-`) are refused to
+  prevent argument injection into the platform `open` helper.
+- The tool opens the URL on the **host** running Docker Agent; in headless or
+  remote environments where no browser/launcher is available, the call fails
+  gracefully and reports the error to the agent.
+
+See [`examples/open_url.yaml`](https://github.com/docker/docker-agent/blob/main/examples/open_url.yaml) for a complete configuration.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md
new file mode 100644
index 000000000000..56c0c30561cc
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/openapi/index.md
@@ -0,0 +1,83 @@
+---
+title: "OpenAPI Tool"
+description: "Automatically generate tools from an OpenAPI specification."
+keywords: docker agent, ai agents, tools, toolsets, openapi tool
+linkTitle: "OpenAPI"
+weight: 230
+canonical: https://docs.docker.com/ai/docker-agent/tools/openapi/
+---
+
+_Automatically generate tools from an OpenAPI specification._
+
+## Overview
+
+The OpenAPI tool fetches an OpenAPI 3.x specification from a URL and creates one tool per API operation. Each endpoint's parameters, request body, and description are translated into a callable tool that the agent can invoke directly.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: openapi
+    url: "https://petstore3.swagger.io/api/v3/openapi.json"
+```
+
+### With custom headers
+
+Pass custom headers to every HTTP request made by the generated tools (for example, for authentication):
+
+```yaml
+toolsets:
+  - type: openapi
+    url: "https://api.example.com/openapi.json"
+    headers:
+      Authorization: "Bearer ${env.API_TOKEN}"
+      X-Custom-Header: "my-value"
+```
+
+### Custom timeout
+
+Override the default 30-second HTTP timeout (applies both to fetching the spec and to the generated tool calls):
+
+```yaml
+toolsets:
+  - type: openapi
+    url: "https://api.example.com/openapi.json"
+    timeout: 60
+```
+
+### Reaching internal services
+
+By default the OpenAPI tool refuses connections to non-public IP addresses, blocking SSRF attempts even when DNS resolves an otherwise-public host to an internal range. Opt in with `allow_private_ips` when the spec or its `servers` entries legitimately target localhost or your internal network:
+
+```yaml
+toolsets:
+  - type: openapi
+    url: "http://localhost:8080/openapi.json"
+    allow_private_ips: true
+```
+
+## Properties
+
+| Property            | Type              | Required | Description                                                                                                                                                                                                                                                       |
+| ------------------- | ----------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `url`               | string            | ✓        | URL of the OpenAPI specification (JSON format). Supports `${env.VAR}` interpolation.                                                                                                                                                                              |
+| `headers`           | map[string]string | ✗        | Custom HTTP headers sent with every request — both the spec fetch and every generated tool call. Values support `${env.VAR}` and `${headers.NAME}` placeholders (the latter forwards a header from the caller's incoming request when docker agent is exposed as a server). |
+| `timeout`           | int               | ✗        | HTTP client timeout in seconds (default: `30`). Applies to both the spec fetch and the generated tools' requests.                                                                                                                                                 |
+| `allow_private_ips` | boolean           | ✗        | Opt in to dialling **non-public** IP addresses (loopback, RFC1918, link-local — including the cloud-metadata endpoint at `169.254.169.254` — multicast and the unspecified address). Set to `true` only when the spec or its servers legitimately target internal services. By default such addresses are refused at dial time, after DNS resolution, so DNS rebinding cannot bypass the check. |
+
+## How it works
+
+1. The spec is fetched from the configured `url` at startup.
+2. Each operation (GET, POST, PUT, …) becomes a separate tool named after its `operationId` (or `method_path` when no `operationId` is set).
+3. Path and query parameters are exposed as tool parameters. Request body properties are prefixed with `body_`.
+4. Read-only operations (GET, HEAD, OPTIONS) are annotated accordingly.
+5. Responses are returned as text; errors include the HTTP status code.
+
+## Limits
+
+- The OpenAPI spec must be **10 MB or less**.
+- Individual API responses are truncated at **1 MB**.
+
+## Example
+
+See the full [Pet Store example](https://github.com/docker/docker-agent/blob/main/examples/openapi-petstore.yaml) for a working agent configuration.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md
new file mode 100644
index 000000000000..3f27b0198939
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md
@@ -0,0 +1,166 @@
+---
+title: "Plan Tool"
+description: "Shared persistent scratchpad for multi-agent collaboration."
+keywords: docker agent, ai agents, tools, toolsets, plan tool
+linkTitle: "Plan"
+weight: 150
+canonical: https://docs.docker.com/ai/docker-agent/tools/plan/
+---
+
+_Shared persistent scratchpad for multi-agent collaboration._
+
+## Overview
+
+The plan tool gives agents a shared, persistent scratchpad of named documents. Any agent in a multi-agent config that loads the `plan` toolset can read and write the same plans, and those plans survive across sessions. This makes it straightforward to wire a planner agent that sketches work and one or more executor agents that consume it without any custom tool wiring.
+
+Plans are stored as JSON files in the Docker Agent data directory (`~/.cagent/plans/` by default). Agents that share a process serialize on a single mutex, and every write or delete additionally holds an advisory lock on a sentinel file in the plans directory, so writers in *separate* Docker Agent processes are serialized too: concurrent edits can never silently overwrite each other, and a stale revision always fails with a deterministic version conflict. Writes are atomic (temp file + rename), so a reader never observes partial content.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: plan
+```
+
+No additional options are required. All agents that include `type: plan` in their toolsets share the same plans.
+
+## Available Tools
+
+| Tool                    | Description                                                                                       |
+| ----------------------- | ------------------------------------------------------------------------------------------------- |
+| `write_plan`            | Create or update a shared plan by name. Replaces the entire plan content — read it first to preserve what you want to keep. Each write bumps the revision number. |
+| `read_plan`             | Read a shared plan by name, including its title, content, author, status, revision number, and last-updated timestamp. |
+| `list_plans`            | List all shared plans with their name, title, author, status, revision, and last-updated timestamp. |
+| `delete_plan`           | Delete a shared plan by name.                                                                     |
+| `update_plan_from_file` | Create or update a plan, taking the new content from a file on disk instead of inline. Use it with `export_plan_to_file` to edit a large plan without re-sending its whole body. |
+| `export_plan_to_file`   | Write a plan's content to a file. The content goes to disk and is **not** returned as tool output, so materialising a plan costs no tokens. |
+| `set_plan_status`       | Set a plan's free-form status without rewriting its body. The plan must already exist. |
+| `get_plan_status`       | Read a plan's status and current revision without fetching its body.                  |
+
+### Cheap edits with file-based revisions
+
+Re-sending a whole plan on every revision is expensive. The file-based tools let
+an agent edit a plan without paying input-token cost for its body:
+
+1. `export_plan_to_file` writes the current plan content to a path. The content
+   is written to disk and is **not** returned.
+2. The agent edits that file in place with its filesystem tools.
+3. `update_plan_from_file` commits the file's new contents as the next revision.
+
+### Free-form status
+
+Each plan carries a free-form `status` string. There is no fixed vocabulary:
+define your own in the system prompt (e.g. `idle`, `in-progress`, `blocked`,
+`done`, `canceled`). Read and write it independently of the body with
+`get_plan_status` and `set_plan_status`, or pass `status` to `write_plan` and
+`update_plan_from_file`. The TUI surfaces the status next to the plan title.
+
+### Optimistic locking
+
+When several sessions edit the same plan, concurrent writes could silently
+overwrite each other. Every read returns a `revision` number; pass the value you
+last read as `last_known_revision` to `write_plan`, `update_plan_from_file`,
+`set_plan_status`, or `delete_plan`. If the plan changed since (its current
+revision no longer matches), the write is rejected with a version-conflict
+error and the caller should re-read the plan and retry. The revision check and
+the write happen under the storage's cross-process file lock, so the conflict
+is detected reliably even when the competing writer runs in a different Docker
+Agent process. Omit `last_known_revision` to write unconditionally (last
+writer wins).
+
+### Plan Names
+
+Plan names must match the pattern `[a-z0-9][a-z0-9_-]*` (lowercase letters, digits, `-`, `_`). This is enforced structurally so two different inputs can never collapse onto the same file and path-traversal is impossible by construction.
+
+### Plan Fields
+
+Each plan document contains:
+
+| Field      | Description                                               |
+| ---------- | --------------------------------------------------------- |
+| `name`     | The plan's unique slug name                               |
+| `title`    | A short human-readable title (optional)                   |
+| `content`  | The full Markdown or free-form plan text                  |
+| `author`   | Free-form label identifying who last wrote the plan       |
+| `status`   | Free-form lifecycle label (optional), e.g. `in-progress`  |
+| `revision` | Monotonically increasing version counter, bumped on every write |
+| `updatedAt`| ISO 8601 timestamp of the last write                      |
+
+## Example
+
+Two agents collaborate on a shared plan — the architect drafts it and the builder refines it:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Coordinator
+    instruction: |
+      Route work between the architect and the builder.
+    handoffs: [architect, builder]
+
+  architect:
+    model: anthropic/claude-sonnet-4-5
+    description: Drafts high-level plans
+    instruction: |
+      Use list_plans and read_plan to inspect existing plans, then write_plan
+      to create or revise one. Always read before writing. When done, hand off
+      to the builder.
+    toolsets:
+      - type: plan
+    handoffs: [builder]
+
+  builder:
+    model: openai/gpt-4o
+    description: Adds implementation steps to plans
+    instruction: |
+      Read the architect's plan with read_plan, then use write_plan to append
+      concrete implementation steps. Always read before writing. When done,
+      hand off back to root.
+    toolsets:
+      - type: plan
+    handoffs: [root]
+```
+
+See [`examples/shared_plan.yaml`](https://github.com/docker/docker-agent/blob/main/examples/shared_plan.yaml) for a complete working example.
+
+## Error Handling
+
+- `read_plan` returns a distinct "not found" error when a plan does not exist, as opposed to any other I/O error, so callers can tell "plan missing" from "plan unreadable."
+- `list_plans` skips corrupt entries but reports them in a `warnings` field so an agent can detect and recover from a bad state (e.g., by calling `delete_plan`).
+- `delete_plan` can remove a corrupt plan to recover from a bad state.
+
+## Managing plans from the host
+
+Shared plans can also be inspected and managed outside a session with the [`docker agent plans`](../../features/cli/index.md#docker-agent-plans) command group: list, get, create, update, set status, export, and delete — with the same optimistic-locking semantics as the tools (`--expected-version` guards a write and a stale version fails with exit code 3; `--force` writes unconditionally). Session plans (the per-session "draft, review, execute" plan) can be listed, read, and exported through the same commands but stay owned by their session and cannot be mutated from the host.
+
+```bash
+$ docker agent plans list
+$ docker agent plans get release > plan.md
+$ docker agent plans update release --file ./plan.md --expected-version 1
+```
+
+### The `/plans` browser in the TUI
+
+Inside the full-screen TUI, the `/plans` slash command (also in the <kbd>Ctrl</kbd>+<kbd>K</kbd> command palette) opens a plan browser over the same store the agents use, so changes made by agents mid-session appear immediately. The list shows every shared plan plus the current session's [session plan](../session_plan/index.md), with each plan's scope, identity (name, or session ID for the session plan), status, version (`-` for the unversioned session plan), last update time, and title.
+
+Keybindings:
+
+| Key | Action |
+| --- | ------ |
+| <kbd>↑</kbd>/<kbd>↓</kbd>, mouse | Navigate; <kbd>Enter</kbd> or double-click opens a detail view with the full metadata and scrollable markdown content |
+| <kbd>/</kbd> | Filter by name, title, status, or scope (<kbd>Esc</kbd> leaves filter mode) |
+| <kbd>r</kbd> | Refresh from storage |
+| <kbd>x</kbd> | Export the selected plan to `<name>.md` (shared) or `session-plan-<short-id>.md` (session) in the session's working directory. An existing file is never overwritten — the export fails with a notification instead |
+| <kbd>s</kbd> | Set a shared plan's free-form status via a small input dialog |
+| <kbd>e</kbd> | Edit a shared plan's content in `$VISUAL`/`$EDITOR` |
+| <kbd>n</kbd> | Create a new shared plan: pick a name, then draft the content in `$VISUAL`/`$EDITOR` (an empty draft aborts) |
+| <kbd>d</kbd> | Delete a shared plan after a confirmation that names the plan and its version |
+| <kbd>Esc</kbd> | Close the detail view / the browser |
+
+Every mutation is guarded by the version shown on screen (the same optimistic locking as `last_known_revision`): if an agent changed the plan in the meantime, the write is rejected, a notification reports the current version, the newer content is left intact and re-read into the browser, and an edit draft is kept in a temp file so nothing is lost. Session plans are read-only here — status, edit, and delete report why instead of attempting the write. The browser also refreshes live when agents in the same process write, re-status, or delete plans (and when this session's agent updates its session plan); in the lean TUI, which has no overlays, `/plans` is unavailable.
+
+> [!TIP]
+> **Plan vs. Todo vs. Tasks**
+>
+> Use **plan** for shared, free-form documents that multiple agents collaborate on (design docs, requirements, work items). Use [todo](../todo/index.md) for lightweight in-session task lists. Use [tasks](../tasks/index.md) for a structured, persistent task database with priorities and dependencies.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md
new file mode 100644
index 000000000000..0aa77a99350f
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md
@@ -0,0 +1,267 @@
+---
+title: "RAG Tool"
+description: "Give your agents access to document knowledge bases with background indexing, multiple retrieval strategies, and hybrid search."
+keywords: docker agent, ai agents, tools, toolsets, rag tool
+linkTitle: "RAG"
+weight: 110
+canonical: https://docs.docker.com/ai/docker-agent/tools/rag/
+aliases:
+  - /ai/docker-agent/rag/
+---
+
+_Give your agents access to document knowledge bases with background indexing, multiple retrieval strategies, and hybrid search._
+
+## Overview
+
+The `rag` toolset lets agents search through your documents to find relevant information before responding. Knowledge bases are declared once at the top of the config under `rag:` and then referenced from any agent via `type: rag, ref: <name>`. Docker Agent supports:
+
+- **Background indexing** — Files are indexed automatically and re-indexed on change
+- **Multiple strategies** — Semantic embeddings, BM25 keyword search, and LLM-enhanced search
+- **Hybrid search** — Combine strategies with result fusion for best results
+- **Reranking** — Re-score results with specialized models for improved relevance
+
+RAG is the strategy to reach for when a document collection is too large to inline directly, or gets queried repeatedly across turns/sessions — see [Choosing a Large-Input Strategy](../../guides/headless/index.md#choosing-a-large-input-strategy) for how it compares to `@`/`/attach` attachments and prompt files.
+
+## Quick Start
+
+```yaml
+rag:
+  my_docs:
+    tool:
+      description: "Technical documentation"
+    docs: [./documents, ./some-doc.md]
+    strategies:
+      - type: chunked-embeddings
+        embedding_model: openai/text-embedding-3-small
+        database: ./docs.db
+        vector_dimensions: 1536
+
+agents:
+  root:
+    model: openai/gpt-4o
+    instruction: |
+      You have access to a knowledge base. Use it to answer questions.
+    toolsets:
+      - type: rag
+        ref: my_docs
+```
+
+## Retrieval Strategies
+
+### Chunked Embeddings (Semantic Search)
+
+Uses embedding models to find semantically similar content. Best for understanding intent, synonyms, and paraphrasing.
+
+```yaml
+strategies:
+  - type: chunked-embeddings
+    embedding_model: openai/text-embedding-3-small
+    database: ./vector.db
+    vector_dimensions: 1536
+    similarity_metric: cosine_similarity
+    threshold: 0.5
+    limit: 10
+    embedding_batch_size: 50
+    chunking:
+      size: 1000
+      overlap: 100
+```
+
+### Semantic Embeddings (LLM-Enhanced)
+
+Uses an LLM to generate semantic summaries of each chunk before embedding, capturing meaning and intent. Best for code search and understanding implementations.
+
+```yaml
+strategies:
+  - type: semantic-embeddings
+    embedding_model: openai/text-embedding-3-small
+    vector_dimensions: 1536
+    chat_model: openai/gpt-4o-mini
+    database: ./semantic.db
+    ast_context: true # include AST metadata
+    chunking:
+      size: 1000
+      code_aware: true # AST-aware chunking
+```
+
+> [!NOTE]
+> **Trade-offs**
+>
+> Semantic embeddings provide higher quality retrieval but slower indexing (LLM call per chunk) and additional API costs.
+
+### BM25 (Keyword Search)
+
+Traditional keyword matching using the BM25 algorithm. Best for exact terms, technical jargon, and code identifiers.
+
+```yaml
+strategies:
+  - type: bm25
+    database: ./bm25.db
+    k1: 1.5 # term frequency saturation
+    b: 0.75 # length normalization
+    threshold: 0.3
+    limit: 10
+    chunking:
+      size: 1000
+      overlap: 100
+```
+
+## Hybrid Search
+
+Combine multiple strategies for best results. Strategies run in parallel and results are fused together:
+
+```yaml
+rag:
+  hybrid:
+    docs: [./docs]
+    strategies:
+      - type: chunked-embeddings
+        embedding_model: openai/text-embedding-3-small
+        database: ./vector.db
+        vector_dimensions: 1536
+        limit: 20
+        chunking: { size: 1000, overlap: 100 }
+      - type: bm25
+        database: ./bm25.db
+        limit: 15
+        chunking: { size: 1000, overlap: 100 }
+    results:
+      fusion:
+        strategy: rrf # Reciprocal Rank Fusion
+        k: 60
+      deduplicate: true
+      limit: 5
+```
+
+## Fusion Strategies
+
+| Strategy   | Best For                          | Description                                                        |
+| ---------- | --------------------------------- | ------------------------------------------------------------------ |
+| `rrf`      | General use (recommended)         | Reciprocal Rank Fusion — rank-based, no score normalization needed |
+| `weighted` | Known performance characteristics | Weight strategies differently (e.g., embeddings: 0.7, BM25: 0.3)   |
+| `max`      | Same scoring scale                | Takes the maximum score from any strategy                          |
+
+## Reranking
+
+Re-score retrieved documents with a specialized model to improve relevance:
+
+```yaml
+results:
+  reranking:
+    model: openai/gpt-4o-mini
+    top_k: 10 # only rerank top 10
+    threshold: 0.3 # minimum score after reranking
+    criteria: |
+      Prioritize official documentation over blog posts.
+      Prefer recent information and practical examples.
+  limit: 5
+```
+
+Supported reranking providers: **DMR** (native `/rerank` endpoint), **OpenAI**, **Anthropic**, **Gemini**.
+
+## Code-Aware Chunking
+
+For source code, enable AST-based chunking to keep functions and methods intact:
+
+```yaml
+chunking:
+  size: 2000
+  code_aware: true # Uses tree-sitter for AST-based chunking
+```
+
+> [!NOTE]
+> **Language Support**
+>
+> Currently supports Go (`.go`) files. More languages will be added. Falls back to plain text chunking for unsupported file types.
+
+## Debugging RAG
+
+Enable debug logging to see retrieval details:
+
+```bash
+$ docker agent run config.yaml --debug --log-file debug.log
+```
+
+Look for log tags: `[RAG Manager]`, `[Chunked-Embeddings Strategy]`, `[BM25 Strategy]`, `[RRF Fusion]`, `[Reranker]`.
+
+**Permanent model errors abort early.** If the embedding model, semantic-LLM model, or reranking model returns a permanent error (HTTP 400, 401, 404, or 429 — invalid config, bad auth, unknown model, or rate limit), Docker Agent treats the model configuration as invalid and stops immediately rather than retrying doomed requests:
+
+- **Indexing** — the entire indexing run is aborted after the first permanent failure (including 429). The error is surfaced in the logs so you know immediately if a model name or API key is wrong, rather than silently producing incomplete results.
+- **Reranking** — a permanent error (including 429) permanently disables the reranker for the lifetime of the manager. Subsequent queries fall back to un-reranked results. Only transient errors (5xx, timeouts) fall back and retry on the next query.
+
+> [!TIP]
+> **Examples**
+>
+> See the [RAG examples](https://github.com/docker/docker-agent/tree/main/examples/rag) in the GitHub repo for complete, runnable configurations.
+
+## Configuration Reference
+
+### Top-Level RAG Fields
+
+| Field         | Type     | Default | Description                                                    |
+| ------------- | -------- | ------- | -------------------------------------------------------------- |
+| `docs`        | []string | —       | Document paths/directories (shared across strategies)          |
+| `description` | string   | —       | Human-readable description of this RAG source                  |
+| `respect_vcs` | boolean  | `true`  | Respect `.gitignore` files when indexing documents             |
+| `strategies`  | []object | —       | Array of retrieval strategy configurations                     |
+| `results`     | object   | —       | Post-processing: fusion, reranking, deduplication, final limit |
+
+### Chunked-Embeddings Strategy
+
+| Field                       | Type   | Default             | Description                                                  |
+| --------------------------- | ------ | ------------------- | ------------------------------------------------------------ |
+| `embedding_model`           | string | —                   | **Required.** Embedding model reference                      |
+| `database`                  | string | —                   | Path to local SQLite database                                |
+| `vector_dimensions`         | int    | —                   | Embedding dimensions (e.g., 1536 for text-embedding-3-small) |
+| `similarity_metric`         | string | `cosine_similarity` | Similarity metric                                            |
+| `threshold`                 | float  | `0.5`               | Minimum similarity score (0–1)                               |
+| `limit`                     | int    | `5`                 | Max results from this strategy                               |
+| `embedding_batch_size`      | int    | `50`                | Chunks per embedding request                                 |
+| `max_embedding_concurrency` | int    | `3`                 | Max concurrent embedding requests                            |
+| `chunking.size`             | int    | `1500`              | Chunk size in characters (`4000` when `code_aware` is set)   |
+| `chunking.overlap`          | int    | `75`                | Overlap between chunks in characters                         |
+| `chunking.code_aware`       | bool   | `false`             | AST-based chunking (Go files only)                           |
+
+### Semantic-Embeddings Strategy
+
+| Field                      | Type   | Default    | Description                                                        |
+| -------------------------- | ------ | ---------- | ------------------------------------------------------------------ |
+| `embedding_model`          | string | —          | **Required.** Embedding model reference                            |
+| `chat_model`               | string | —          | **Required.** LLM for generating semantic summaries                |
+| `vector_dimensions`        | int    | —          | **Required.** Embedding dimensions                                 |
+| `database`                 | string | —          | Path to local SQLite database                                      |
+| `semantic_prompt`          | string | (built-in) | Custom prompt template (`${path}`, `${content}`, `${ast_context}`) |
+| `ast_context`              | bool   | `false`    | Include tree-sitter AST metadata in prompts                        |
+| `threshold`                | float  | `0.5`      | Minimum similarity score (0–1)                                     |
+| `limit`                    | int    | `5`        | Max results                                                        |
+| `max_indexing_concurrency` | int    | `3`        | Max concurrent file indexing                                       |
+| `chunking.size`            | int    | `1500`     | Chunk size in characters (`4000` when `code_aware` is set)         |
+| `chunking.overlap`         | int    | `75`       | Overlap between chunks                                             |
+| `chunking.code_aware`      | bool   | `false`    | AST-based chunking                                                 |
+
+### BM25 Strategy
+
+| Field              | Type   | Default | Description                                     |
+| ------------------ | ------ | ------- | ----------------------------------------------- |
+| `database`         | string | —       | Path to local SQLite database                   |
+| `k1`               | float  | `1.5`   | Term frequency saturation (1.2–2.0 recommended) |
+| `b`                | float  | `0.75`  | Length normalization (0–1)                      |
+| `threshold`        | float  | `0.0`   | Minimum BM25 score                              |
+| `limit`            | int    | `5`     | Max results                                     |
+| `chunking.size`    | int    | `1500`  | Chunk size in characters                        |
+| `chunking.overlap` | int    | `75`    | Overlap between chunks                          |
+
+### Results (Post-Processing)
+
+| Field                 | Type   | Default | Description                                                 |
+| --------------------- | ------ | ------- | ----------------------------------------------------------- |
+| `fusion.strategy`     | string | `rrf`   | Fusion method: `rrf`, `weighted`, or `max`                  |
+| `fusion.k`            | int    | `60`    | RRF rank constant                                           |
+| `deduplicate`         | bool   | `true`  | Remove duplicate results                                    |
+| `limit`               | int    | `15`    | Final number of results                                     |
+| `include_score`       | bool   | `false` | Include relevance scores in results                         |
+| `return_full_content` | bool   | `false` | Return full document content instead of just matched chunks |
+| `reranking.model`     | string | —       | Reranking model reference                                   |
+| `reranking.top_k`     | int    | (`limit`) | Only rerank top K results. Defaults to the results `limit` when set.  |
+| `reranking.threshold` | float  | `0.5`   | Minimum relevance score after reranking                     |
+| `reranking.criteria`  | string | —       | Custom relevance guidance for the reranking model           |
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md
new file mode 100644
index 000000000000..16635f7f77f2
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md
@@ -0,0 +1,96 @@
+---
+title: "Scheduler Tool"
+description: "Schedule instructions to run at a time or on a recurring interval."
+keywords: docker agent, ai agents, tools, toolsets, scheduler tool, cron
+linkTitle: "Scheduler"
+weight: 135
+canonical: https://docs.docker.com/ai/docker-agent/tools/scheduler/
+---
+
+_Schedule instructions to run at a time or on a recurring interval._
+
+## Overview
+
+The scheduler toolset lets an agent make something happen at a chosen time or on a repeating cadence during a session. You give it an instruction and a schedule; when the schedule is due, the instruction is delivered back to the agent, which then carries out the action with its normal tools (`shell`, `api`, `fetch`, and so on).
+
+The scheduler does not run shell or API calls itself. When a schedule fires it injects the instruction into the agent loop via the runtime's recall mechanism — the same primitive [`background_jobs`](../background-jobs/index.md) uses to report completed work — and the agent decides how to act. This keeps every action under the agent's normal tools and permissions rather than adding a second, unattended
+command runner.
+
+> [!NOTE]
+> Schedules only fire while the session is running (interactive TUI or a server mode) and are not persisted across restarts. Scheduling requires a host that supports recall; if it does not, `create_schedule` returns an error.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: scheduler
+```
+
+No configuration options.
+
+## Tools
+
+| Tool | Description |
+| --- | --- |
+| `create_schedule` | Register an instruction to run at a time or interval. |
+| `list_schedules` | List active schedules with their id, spec, and next fire time. |
+| `cancel_schedule` | Remove a schedule by id. |
+
+### `create_schedule`
+
+| Parameter | Required | Description |
+| --- | --- | --- |
+| `prompt` | Yes | The instruction to deliver to the agent when the schedule fires. |
+| `when` | Yes | When to fire (see [Schedule specs](#schedule-specs)). |
+| `name` | No | Optional human-readable label. |
+
+Returns the new schedule's id and its next fire time.
+
+### `cancel_schedule`
+
+| Parameter | Required | Description |
+| --- | --- | --- |
+| `id` | Yes | The id of the schedule to cancel (from `create_schedule` or `list_schedules`). |
+
+## Schedule specs
+
+The `when` argument accepts:
+
+| Form | Meaning | Example |
+| --- | --- | --- |
+| `in:<duration>` | One-shot, after a delay | `in:10m` |
+| `at:<RFC3339>` | One-shot, at an absolute future time | `at:2026-07-14T09:00:00Z` |
+| `every:<duration>` | Recurring, at a fixed interval | `every:1h` |
+| `minutely` / `hourly` / `daily` / `weekly` | Recurring preset intervals | `hourly` |
+
+Durations use Go's duration syntax (`30s`, `15m`, `2h`). Preset and `every:` intervals are measured from the schedule's creation time (for example `hourly` fires every hour after it is created), not aligned to wall-clock slots.
+
+> [!IMPORTANT]
+> **Recurring schedules have a one-minute minimum.** Every fire injects a message into the agent loop and typically costs an LLM turn, so `every:` values below `1m` are rejected — a typo such as `every:1s` in place of `every:1h` would otherwise become a runaway token burn. One-shot schedules (`in:` / `at:`) are not restricted, since they fire once.
+
+## Example
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5-mini
+    description: A monitoring assistant
+    instruction: |
+      Every 15 minutes, run `git fetch` and tell me if origin/main moved.
+    toolsets:
+      - type: scheduler
+      - type: shell
+```
+
+The agent calls:
+
+```text
+create_schedule(prompt="Run git fetch and report if origin/main moved", when="every:15m")
+```
+
+Every 15 minutes it is reminded, runs the command with the `shell` tool, and reports back.
+
+> [!TIP]
+> **When to use**
+>
+> Use the scheduler for recurring monitoring, timed one-shots, and unattended housekeeping loops during a long-running session. For work that should run immediately and be awaited, use [`background_jobs`](../background-jobs/index.md) instead.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/script/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/script/index.md
new file mode 100644
index 000000000000..b4f912705517
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/script/index.md
@@ -0,0 +1,64 @@
+---
+title: "Script Tool"
+description: "Define custom shell scripts as named tools with typed parameters."
+keywords: docker agent, ai agents, tools, toolsets, script tool
+linkTitle: "Script"
+weight: 30
+canonical: https://docs.docker.com/ai/docker-agent/tools/script/
+---
+
+_Define custom shell scripts as named tools with typed parameters._
+
+## Overview
+
+The script tool lets you define custom shell scripts as named tools. Unlike the generic [shell tool](../shell/index.md) where the agent writes the command, script tools execute predefined commands — ideal for exposing safe, well-scoped operations with descriptive names.
+
+## Configuration
+
+### Simple Scripts
+
+```yaml
+toolsets:
+  - type: script
+    shell:
+      run_tests:
+        cmd: task test
+        description: Run the project test suite
+      lint:
+        cmd: task lint
+        description: Run the linter
+```
+
+### Scripts with Parameters
+
+Use `${param}` interpolation and JSON Schema to define typed arguments:
+
+```yaml
+toolsets:
+  - type: script
+    shell:
+      deploy:
+        cmd: ./scripts/deploy.sh ${env}
+        description: Deploy to an environment
+        args:
+          env:
+            type: string
+            enum: [staging, production]
+        required: [env]
+```
+
+## Properties
+
+| Property                          | Type   | Description                                                |
+| --------------------------------- | ------ | ---------------------------------------------------------- |
+| `shell.<name>.cmd`                | string | Shell command to execute (supports `${arg}` interpolation) |
+| `shell.<name>.description`        | string | Description shown to the model                             |
+| `shell.<name>.args`               | object | Parameter definitions (JSON Schema properties)             |
+| `shell.<name>.required`           | array  | Required parameter names                                   |
+| `shell.<name>.env`                | object | Environment variables for this script                      |
+| `shell.<name>.working_dir`        | string | Working directory for script execution                     |
+
+> [!TIP]
+> **Script vs. Shell**
+>
+> Use the [shell tool](../shell/index.md) when the agent needs to run arbitrary commands. Use the script tool when you want to expose specific, predefined operations with clear names and typed parameters — giving the agent less freedom but more safety.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md
new file mode 100644
index 000000000000..9f241bb551db
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/session_context/index.md
@@ -0,0 +1,67 @@
+---
+title: "Session Context Tool"
+description: "Reference a previous session as context in the current one."
+keywords: docker agent, ai agents, tools, toolsets, session context tool
+linkTitle: "Session Context"
+weight: 210
+canonical: https://docs.docker.com/ai/docker-agent/tools/session_context/
+---
+
+_Reference a previous session as context, without manual export/import._
+
+## Overview
+
+The `session_context` toolset lets an agent discover earlier sessions and pull one in as context for the current session. It removes the manual workaround of exporting a conversation to HTML and re-attaching it with an `@` mention.
+
+The tool surface is two read-only tools:
+
+| Tool            | Description                                                                                                  |
+| --------------- | ------------------------------------------------------------------------------------------------------------ |
+| `list_sessions` | List previous sessions (most recent first) with id, title, creation time and message count.                  |
+| `read_session`  | Return the transcript of a previous session, by id or by a relative reference like `-1`.                      |
+
+The session the agent is currently running in is never listed by `list_sessions` and cannot be read by `read_session` (a circular reference returns an error).
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: session_context
+```
+
+No configuration options. Both tools are read-only and operate against the same session store the runtime already uses for persistence.
+
+Restrict the toolset to a subset of tools the standard way:
+
+```yaml
+# An agent that may browse but never pull a full transcript into context.
+toolsets:
+  - type: session_context
+    tools:
+      - list_sessions
+```
+
+## Selecting a session
+
+`read_session` accepts either form:
+
+- A concrete id returned by `list_sessions`, e.g. `read_session("a1b2c3...")`.
+- A relative reference: `-1` is the most recent session, `-2` the second most recent, and so on. Relative references resolve against the same ordering `list_sessions` uses (most recent first), excluding sub-sessions.
+
+## Transcript size
+
+A long session could overflow the current context window, so `read_session` caps the rendered transcript. When a transcript is larger than the budget, the oldest messages are dropped (the most recent are usually the most useful for continuing work) and a note records how many were omitted:
+
+```text
+[12 earlier message(s) omitted to fit the context budget; showing the most recent 8]
+```
+
+## Notes
+
+- `list_sessions` defaults to 20 sessions and is capped at 100; pass `limit` to request fewer.
+- `read_session` returns an error when the session is not found, when the reference cannot be resolved, or when it points at the current session.
+- Both tools are read-only: they never modify, branch, or delete sessions.
+
+## Example
+
+See [`examples/session_context.yaml`](https://github.com/docker/docker-agent/blob/main/examples/session_context.yaml) for a complete working example.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md
new file mode 100644
index 000000000000..ea4c8e4970f0
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/session_plan/index.md
@@ -0,0 +1,134 @@
+---
+title: "Session Plan Tool"
+description: "Per-session plan tracker for the draft, review, execute workflow."
+keywords: docker agent, ai agents, tools, toolsets, session plan tool
+linkTitle: "Session Plan"
+weight: 160
+canonical: https://docs.docker.com/ai/docker-agent/tools/session_plan/
+---
+
+_Per-session plan tracker for the "draft, review, execute" workflow._
+
+## Overview
+
+The `session_plan` toolset gives one agent a place to write a plan for the current session, signal that the plan is ready, and let the host route the next turn to an executing agent.
+
+Different from the [`plan` toolset](../plan/index.md) — `plan` is for shared, named plans multiple agents collaborate on over many sessions. `session_plan` is for one ephemeral plan per session, scoped to that session by ID.
+
+Plans live as Markdown files under:
+
+```text
+~/.cagent/session_plans/<session-id>.md
+```
+
+The tool surface is three tools:
+
+| Tool                 | Description                                                                                          |
+| -------------------- | ---------------------------------------------------------------------------------------------------- |
+| `write_session_plan` | Create or replace this session's plan as markdown. There's exactly one plan per session.             |
+| `read_session_plan`  | Read the plan written for the current session and return it as markdown.                             |
+| `exit_plan_mode`     | Signal that the plan is ready for review. Does not switch agents on its own.                         |
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: session_plan
+```
+
+No configuration options. The plan path is derived from the session ID; the agent does not name plans.
+
+Restrict the toolset to a subset of tools the standard way:
+
+```yaml
+# An agent that consumes a plan but should not be able to (re)write or finalize one.
+toolsets:
+  - type: session_plan
+    tools:
+      - read_session_plan
+```
+
+## When to call exit_plan_mode
+
+Call `exit_plan_mode` once the plan is complete and you do not intend to change it on the next turn. It validates that a plan exists for the session and returns a "ready for review" tool result. It does **not** switch agents or solicit user approval on its own — the host application owns the next-turn routing (for example, by reading the tool result, by a UI affordance the user toggles, or by a `handoff` declared on the agent).
+
+This separation keeps the tool reusable across UIs: a CLI that prints tool results inline, a chat UI with a plan-mode toggle, and a server that auto-routes the next turn through a `handoff` can all consume the same signal without one stepping on another.
+
+## Storage and cleanup
+
+- Plans are markdown files written atomically (temp + rename), so concurrent readers — in this process or another — never observe a partial write.
+- A best-effort sweep on first use of the toolset removes plan files older than 30 days under the plans directory. Stranded plans for long-gone sessions do not accumulate.
+- The session ID identifies the file directly. There is no in-process mutex or revision counter, because two sessions cannot map to the same path.
+
+## Events
+
+A `session_plan_updated` event is emitted whenever `write_session_plan` succeeds:
+
+```json
+{
+  "type": "session_plan_updated",
+  "session_id": "...",
+  "path": "/Users/.../.cagent/session_plans/<session-id>.md",
+  "content": "# my plan\n...",
+  "agent_name": "planner"
+}
+```
+
+Embedders that render the plan inline can subscribe and update without re-reading the file.
+
+## Managing session plans from the host
+
+A session plan belongs to its session: hosts can read and export it, never change it.
+
+- **CLI** — the [`docker agent plans`](../../features/cli/index.md#docker-agent-plans) command group lists, reads (`get --session <session-id>`), and exports session plans alongside shared plans. Mutations (`update`, `status`, `delete`) are refused with an `unsupported` error explaining the ownership rule.
+- **TUI** — the `/plans` browser (see the [plan toolset docs](../plan/index.md#the-plans-browser-in-the-tui) for the full keybinding table) includes the **current session's** plan as the `session` scope row; plans of other sessions are never enumerated. Its identity is the session ID and its version column shows `-` — session plans have no versions. <kbd>Enter</kbd> opens the detail view (scope, session ID, update time, scrollable markdown) and <kbd>x</kbd> exports to `session-plan-<short-id>.md` in the working directory (refusing to overwrite an existing file). <kbd>e</kbd> opens the plan body in your external editor (`$VISUAL` or `$EDITOR`) for editing — the write is unguarded and last-write-wins by design. Status and delete visibly report that session plans don't support them (session plans belong to their session and carry no shared-plan metadata). The browser refreshes live on the `session_plan_updated` event, so a plan the agent just wrote appears without reopening.
+
+## Example
+
+A two-agent workflow: `root` executes, `planner` plans. `/plan` hands off to the planner; `exit_plan_mode` signals "ready", and the host decides what happens next.
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: Executes approved plans
+    instruction: |
+      You execute plans the planner has handed off. When you see a message
+      that a plan has been approved, read it with read_session_plan and work
+      through its steps in order.
+    toolsets:
+      - type: session_plan
+        tools:
+          - read_session_plan
+      - type: filesystem
+      - type: shell
+    commands:
+      plan:
+        description: "Switch to the planner"
+        agent: planner
+
+  planner:
+    model: anthropic/claude-sonnet-4-5
+    description: Investigates and writes plans for review
+    instruction: |
+      Investigate the user's request, then write the plan with
+      write_session_plan. Iterate with the user until the plan is complete,
+      then call exit_plan_mode to mark it ready for review.
+    toolsets:
+      - type: session_plan
+      - type: filesystem
+        readonly: true
+      - type: user_prompt
+```
+
+See [`examples/session_plan.yaml`](https://github.com/docker/docker-agent/blob/main/examples/session_plan.yaml) for a complete working example.
+
+## Error Handling
+
+- `read_session_plan` and `exit_plan_mode` return a "no plan written yet" error when called before `write_session_plan`.
+- `write_session_plan` validates the session ID and refuses to write anything that could escape the plans directory; in practice the runtime generates UUIDs so this only triggers if an embedder supplies a hand-crafted ID.
+
+> [!TIP]
+> **session_plan vs. plan vs. todo vs. tasks**
+>
+> Use **session_plan** when one agent drafts an approach for the user to review before another agent executes it (ephemeral, one per session). Use [plan](../plan/index.md) for shared, named plans multiple agents collaborate on over many sessions. Use [todo](../todo/index.md) for lightweight in-session task lists. Use [tasks](../tasks/index.md) for a structured, persistent task database with priorities and dependencies.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md
new file mode 100644
index 000000000000..5da9fc8f8233
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md
@@ -0,0 +1,117 @@
+---
+title: "Shell Tool"
+description: "Execute arbitrary shell commands in the user's environment."
+keywords: docker agent, ai agents, tools, toolsets, shell tool
+linkTitle: "Shell"
+weight: 20
+canonical: https://docs.docker.com/ai/docker-agent/tools/shell/
+---
+
+_Execute arbitrary shell commands in the user's environment._
+
+## Overview
+
+The shell tool allows agents to execute arbitrary shell commands synchronously. This is one of the most powerful tools — it lets agents run builds, install dependencies, query APIs, and interact with the system. Each call runs in a fresh, isolated shell session — no state persists between calls.
+
+Commands have a default 30-second timeout and require user confirmation unless `--yolo` is used. For servers, watchers, and other long-running commands, add the [`background_jobs`](../background-jobs/index.md) toolset alongside `shell`.
+
+### Shell interpreter detection
+
+The shell tool automatically detects and names the resolved shell interpreter (e.g., `bash`, `zsh`, `powershell`, `pwsh`, `cmd`) in its description to the model, along with the operating system (Linux, macOS, Windows). This helps models use the correct shell syntax for the host environment.
+
+For example:
+
+- On Linux with bash: "Executes the given shell command with bash on Linux."
+- On Windows with PowerShell: "Executes the given shell command with powershell on Windows. Use Windows PowerShell 5.1 syntax: chain commands with ";" (not "&&"), and avoid POSIX commands/flags like "ls -la"."
+
+This reduces wasted turns where models assume POSIX syntax on Windows or vice versa.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: shell
+```
+
+### Options
+
+| Property       | Type    | Description                                                                                          |
+| -------------- | ------- | --------------------------------------------------------------------------------------------------- |
+| `env`          | object  | Environment variables to set for all shell commands                                                 |
+| `safer`        | boolean | Deprecated and ignored — shell commands are always classified now (see [Command classification](#command-classification)). Kept so existing YAMLs still parse. |
+| `sudo_askpass` | boolean | Opt in to prompting for a `sudo` password (see [Sudo support](#sudo-support)). Default `false`.     |
+
+### Custom Environment Variables
+
+```yaml
+toolsets:
+  - type: shell
+    env:
+      MY_VAR: "value"
+      PATH: "${env.PATH}:/custom/bin"
+```
+
+### Command classification
+
+Every shell command is classified against an embedded taxonomy before the approval decision — no opt-in required:
+
+- **Destructive matches** (`rm -rf <path>`, `docker volume rm`, `mkfs`, `dd if=… of=/dev/<disk>`, …) are labelled `destructive` with a `blast_radius` (`low` / `medium` / `high`) and a `category` tag. The TUI confirmation dialog renders the blast radius with a color badge.
+- **Known-safe reads** (`ls`, `cat`, `git status`, `git diff`, `docker ps`, `docker logs`, `kubectl get`, …) are labelled `safe`.
+- **Everything else** is labelled `unknown`.
+
+The session's [safety mode](../../configuration/permissions/index.md#safety-modes) decides what each label means: `strict` asks about everything, `balanced` auto-runs safe commands and asks about destructive/unknown ones, `restricted` auto-runs safe commands and denies destructive/unknown ones without asking (fail-closed for unattended runs), `autonomous` runs everything. Custom permission rules always win over the mode.
+
+Compound shell (`a && b`, `a; b`, `a | b`) is never matched against the safe allowlist; any destructive segment falls through to ask. The full taxonomy lives in [`pkg/safety/safety_patterns.json`](https://github.com/docker/docker-agent/blob/main/pkg/safety/safety_patterns.json).
+
+See [`examples/safety_modes.yaml`](https://github.com/docker/docker-agent/blob/main/examples/safety_modes.yaml) for a full example. The legacy `safer: true` toolset flag is deprecated and ignored.
+
+### Sudo support
+
+By default a shell command has no controlling terminal, so a `sudo` command that needs a password hangs until it times out (the agent usually gives up and falls back to printing manual instructions).
+
+Set `sudo_askpass: true` to enable a sudo privilege escalation flow:
+
+```yaml
+toolsets:
+  - type: shell
+    sudo_askpass: true
+```
+
+When enabled, `sudo` commands prompt you for your password through the host UI (the input is masked). The password is handed to `sudo` over a private, per-session socket via the standard `SUDO_ASKPASS` mechanism — it is never written to the command line, the logs, or stored by the agent.
+
+The bridge environment variables (`SUDO_ASKPASS`, `CAGENT_ASKPASS_SOCKET`, `CAGENT_ASKPASS_TOKEN`) are added only to commands that invoke `sudo`, but within such a command they are visible to every child process, not just `sudo`. They carry a socket path and a session token, not the password; the socket lives in a `0700` directory, so only your own user can reach it.
+
+Notes and limitations:
+
+- Unix only. The flag has no effect on Windows.
+- Interactive UI only. In headless / non-interactive runs the prompt is declined automatically and `sudo` fails as before.
+- Only a bare `sudo ...` invocation in a POSIX shell (`sh`, `bash`, `zsh`, ...) is handled. `sudo` called by absolute path (`/usr/bin/sudo`), via `env sudo`, from inside a nested script, or under a non-POSIX shell (e.g. `fish`) is not intercepted and behaves as before.
+- Caching is `sudo`'s own. Because each shell tool call runs in a fresh shell with no controlling terminal, `sudo`'s credential cache does not persist across separate tool calls: you are prompted once per shell command that uses `sudo`. Within a single command, multiple `sudo` calls (e.g. `sudo a && sudo b`) usually share one prompt, subject to `sudo`'s own timestamp configuration.
+- The prompt must be answered within the command's timeout; raise the `timeout` parameter for `sudo` commands that may wait on input.
+- Prompts are serialized: if a single command runs two `sudo` calls in parallel (e.g. `sudo a & sudo b`), the second waits for the first prompt to be answered rather than opening two dialogs at once.
+
+## Available Tools
+
+The shell toolset exposes one tool:
+
+| Tool Name | Description                                                                  |
+| --------- | ---------------------------------------------------------------------------- |
+| `shell`   | Run a command synchronously and return its combined output when it finishes. |
+
+### `shell` parameters
+
+| Parameter | Type    | Required | Description                                                               |
+| --------- | ------- | -------- | ------------------------------------------------------------------------- |
+| `cmd`     | string  | ✓        | The shell command to execute.                                             |
+| `cwd`     | string  | ✗        | Working directory to run the command in (default: `.`).                   |
+| `timeout` | integer | ✗        | Per-call execution timeout in seconds (default: `30`).                    |
+
+> [!WARNING]
+> **Safety**
+>
+> The shell tool gives agents full access to the system shell. Always set `max_iterations` on agents that use the shell tool to prevent infinite loops. A value of 20–50 is typical for development agents. Use [Sandbox Mode](../../configuration/sandbox/index.md) for additional isolation.
+
+> [!NOTE]
+> **Tool Confirmation**
+>
+> By default, Docker Agent asks for user confirmation before executing shell commands. Use `--yolo` to auto-approve all tool calls.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md
new file mode 100644
index 000000000000..9d399f96958b
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/tasks/index.md
@@ -0,0 +1,59 @@
+---
+title: "Tasks Tool"
+description: "Persistent task database with priorities and dependencies, shared across sessions."
+keywords: docker agent, ai agents, tools, toolsets, tasks tool
+linkTitle: "Tasks"
+weight: 180
+canonical: https://docs.docker.com/ai/docker-agent/tools/tasks/
+---
+
+_Persistent task database with priorities and dependencies, shared across sessions._
+
+## Overview
+
+The tasks tool provides a persistent task database that survives across agent sessions. Unlike the [Todo tool](../todo/index.md), which maintains an in-memory task list for the current session only, the tasks tool stores tasks in a JSON file on disk so they can be accessed and updated across multiple sessions. Tasks support priorities and dependencies — a task is _blocked_ until every task it depends on is `done`.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: tasks
+    path: ./tasks.json  # Optional: custom database path
+```
+
+### Options
+
+| Property | Type   | Default       | Description                                                                                                                  |
+| -------- | ------ | ------------- | ---------------------------------------------------------------------------------------------------------------------------- |
+| `path`   | string | `tasks.json`  | Path to the JSON task database. Relative paths resolve against the agent config directory (or `--working-dir` when set).     |
+
+## Available Tools
+
+The tasks toolset exposes these tools:
+
+| Tool Name           | Description                                                                                                              |
+| ------------------- | ------------------------------------------------------------------------------------------------------------------------ |
+| `create_task`       | Create a new task with a title, description (or markdown file path), optional priority, and optional dependencies.       |
+| `get_task`          | Get full details of a single task by ID, including its effective status (`blocked` if any dependency is not `done`).     |
+| `update_task`       | Update a task's title, description, priority, status, or dependency list.                                                |
+| `delete_task`       | Delete a task by ID. Also removes it from other tasks' dependency lists.                                                 |
+| `list_tasks`        | List tasks sorted by priority (critical first) with blocked tasks last. Optionally filter by status or priority.         |
+| `next_task`         | Return the highest-priority actionable task — one that is not blocked and not done. Great for "what should I work on?". |
+| `add_dependency`    | Add a dependency: a task is blocked until the task it depends on is `done`.                                              |
+| `remove_dependency` | Remove a dependency from a task.                                                                                         |
+
+## Example
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-4o
+    toolsets:
+      - type: tasks
+        path: ./project-tasks.json
+```
+
+> [!TIP]
+> **Tasks vs. Todo**
+>
+> Use the **tasks** tool when you need persistence across sessions, priorities, or dependencies (e.g., long-running projects, recurring work). Use the [todo tool](../todo/index.md) for ephemeral, session-scoped task lists.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/think/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/think/index.md
new file mode 100644
index 000000000000..24873fcacfe3
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/think/index.md
@@ -0,0 +1,30 @@
+---
+title: "Think Tool"
+description: "Step-by-step reasoning scratchpad for planning and decision-making."
+keywords: docker agent, ai agents, tools, toolsets, think tool
+linkTitle: "Think"
+weight: 140
+canonical: https://docs.docker.com/ai/docker-agent/tools/think/
+---
+
+_Step-by-step reasoning scratchpad for planning and decision-making._
+
+## Overview
+
+The think tool is a reasoning scratchpad that lets agents think step-by-step before acting. The agent can write its thoughts without producing visible output to the user — ideal for planning complex tasks, breaking down problems, and reasoning through multi-step solutions.
+
+This is a lightweight tool with no side effects. It is most useful for models that lack built-in reasoning or thinking capabilities (e.g., smaller or older models). For models that already support native thinking — such as Claude with extended thinking, OpenAI o-series, or Gemini with a thinking budget — this tool is unnecessary since the model can reason internally.
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: think
+```
+
+No configuration options.
+
+> [!TIP]
+> **When to use**
+>
+> Use the think tool with models that don't have native reasoning capabilities. If your model already supports a [thinking budget](../../configuration/models/index.md#thinking-budget), you likely don't need this tool.
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md
new file mode 100644
index 000000000000..7f2154379cce
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/todo/index.md
@@ -0,0 +1,54 @@
+---
+title: "Todo Tool"
+description: "Task list management for complex multi-step workflows."
+keywords: docker agent, ai agents, tools, toolsets, todo tool
+linkTitle: "Todo"
+weight: 170
+canonical: https://docs.docker.com/ai/docker-agent/tools/todo/
+---
+
+_Task list management for complex multi-step workflows._
+
+## Overview
+
+The todo tool provides task list management. Agents can create, update, list, and track progress on tasks with status tracking (pending, in-progress, completed). Useful for complex multi-step workflows where the agent needs to stay organized and ensure all steps are completed.
+
+## Available Tools
+
+| Tool           | Description                              |
+| -------------- | ---------------------------------------- |
+| `create_todo`  | Create a new task                        |
+| `create_todos` | Create multiple tasks at once            |
+| `update_todos` | Update status of one or more tasks       |
+| `list_todos`   | List all current tasks with their status |
+
+### Task Statuses
+
+| Status        | Description                  |
+| ------------- | ---------------------------- |
+| `pending`     | Task has not been started    |
+| `in-progress` | Task is currently being done |
+| `completed`   | Task is finished             |
+
+## Configuration
+
+```yaml
+toolsets:
+  - type: todo
+```
+
+### Options
+
+| Property | Type    | Default | Description                                                             |
+| -------- | ------- | ------- | ----------------------------------------------------------------------- |
+| `shared` | boolean | `false` | When `true`, todos are shared across all agents in a multi-agent config |
+
+### Shared Todos
+
+In multi-agent setups, enable shared todos so all agents can see and update the same task list:
+
+```yaml
+toolsets:
+  - type: todo
+    shared: true
+```
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md
new file mode 100644
index 000000000000..9d3bc2a03a07
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/transfer-task/index.md
@@ -0,0 +1,73 @@
+---
+title: "Transfer Task Tool"
+description: "Delegate tasks to sub-agents in multi-agent setups."
+keywords: docker agent, ai agents, tools, toolsets, transfer task tool
+linkTitle: "Transfer Task"
+weight: 80
+canonical: https://docs.docker.com/ai/docker-agent/tools/transfer-task/
+---
+
+_Delegate tasks to sub-agents in multi-agent setups._
+
+## Overview
+
+The `transfer_task` tool allows an agent to delegate tasks to specialized sub-agents and receive their results. This is the core mechanism for multi-agent orchestration.
+
+**You don't need to add it manually** — it's automatically available when an agent has `sub_agents` configured.
+
+## Configuration
+
+The tool is enabled implicitly when `sub_agents` is set:
+
+```yaml
+agents:
+  coordinator:
+    model: openai/gpt-4o
+    description: Coordinates work across specialists
+    instruction: Analyze requests and delegate to the right specialist.
+    sub_agents: [developer, researcher]
+
+  developer:
+    model: anthropic/claude-sonnet-4-5
+    description: Expert software developer
+    instruction: Write clean, production-ready code.
+    toolsets:
+      - type: filesystem
+      - type: shell
+
+  researcher:
+    model: openai/gpt-4o
+    description: Web researcher
+    instruction: Search for information online.
+    toolsets:
+      - type: mcp
+        ref: docker:duckduckgo
+```
+
+The coordinator agent automatically gets a `transfer_task` tool that can delegate to `developer` or `researcher`.
+
+## Tool Interface
+
+The `transfer_task` tool takes three parameters:
+
+| Parameter         | Type   | Required | Description                                                                                 |
+| ----------------- | ------ | -------- | ------------------------------------------------------------------------------------------- |
+| `agent`           | string | ✓        | Name of the sub-agent to delegate to. Must be listed under the caller's `sub_agents`.        |
+| `task`            | string | ✓        | Clear, concise description of the task the sub-agent should achieve.                        |
+| `expected_output` | string | ✓        | Description of the result/format the caller expects back.                                   |
+
+The call blocks until the sub-agent returns its result, which becomes the tool's response. For non-blocking parallel delegation, use [`background_agents`](../background-agents/index.md) instead.
+
+## Delegation Limits
+
+Sub-agents can have `sub_agents` of their own, so multi-level delegation chains are supported. Two runtime guards keep chains sane, applied to both `transfer_task` and `run_background_agent`:
+
+- **Cycles are rejected.** A delegation targeting an agent that is already part of the active delegation chain (for example `a -> b -> a`) fails with an error naming the cycle.
+- **Depth is capped at 10 nested delegations.** The root agent delegating to its first sub-agent counts as depth 1; a call that would exceed the cap fails with an error stating the attempted depth.
+
+A rejected delegation returns a tool error to the calling agent and never starts the sub-agent.
+
+> [!TIP]
+> **See also**
+>
+> For parallel task delegation, see [Background Agents](../background-agents/index.md). For multi-agent patterns, see [Multi-Agent](../../concepts/multi-agent/index.md).
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md
new file mode 100644
index 000000000000..739892c93750
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/user-prompt/index.md
@@ -0,0 +1,186 @@
+---
+title: "User Prompt Tool"
+description: "Ask the user questions and collect interactive input during agent execution."
+keywords: docker agent, ai agents, tools, toolsets, user prompt tool
+linkTitle: "User Prompt"
+weight: 190
+canonical: https://docs.docker.com/ai/docker-agent/tools/user-prompt/
+---
+
+_Ask the user questions and collect interactive input during agent execution._
+
+## Overview
+
+The user prompt tool allows agents to ask questions and collect input from users during execution. This enables interactive workflows where the agent needs clarification, confirmation, or additional information before proceeding.
+
+> [!NOTE]
+> **When to Use**
+>
+> - When the agent needs clarification before proceeding
+> - Collecting credentials or configuration values
+> - Presenting choices and getting user decisions
+> - Confirming destructive or important actions
+
+## Configuration
+
+```yaml
+agents:
+  assistant:
+    model: openai/gpt-4o
+    description: Interactive assistant
+    instruction: |
+      You are a helpful assistant. When you need information
+      from the user, use the user_prompt tool to ask them.
+    toolsets:
+      - type: user_prompt
+      - type: filesystem
+      - type: shell
+```
+
+## Tool Interface
+
+The `user_prompt` tool takes these parameters:
+
+| Parameter | Type   | Required | Description                                                                                        |
+| --------- | ------ | -------- | -------------------------------------------------------------------------------------------------- |
+| `message` | string | ✓        | The question or prompt to display.                                                                 |
+| `title`   | string | ✗        | Optional title for the dialog window in the TUI. Defaults to `"Question"` when not provided.       |
+| `schema`  | object | ✗        | JSON Schema defining the expected response structure (object or primitive).                        |
+
+## Response Format
+
+The tool returns a JSON response:
+
+```json
+{
+  "action": "accept",
+  "content": {
+    "field1": "user value",
+    "field2": true
+  }
+}
+```
+
+### Action Values
+
+| Action    | Meaning                                    |
+| --------- | ------------------------------------------ |
+| `accept`  | User provided a response (check `content`) |
+| `decline` | User declined to answer                    |
+| `cancel`  | User cancelled the prompt                  |
+
+## Schema Examples
+
+### Simple String Input
+
+```json
+{
+  "type": "string",
+  "title": "API Key",
+  "description": "Enter your API key"
+}
+```
+
+### Multiple Choice
+
+```json
+{
+  "type": "string",
+  "enum": ["development", "staging", "production"],
+  "title": "Environment",
+  "description": "Select the target environment"
+}
+```
+
+### Boolean Confirmation
+
+```json
+{
+  "type": "boolean",
+  "title": "Confirm",
+  "description": "Are you sure you want to proceed?"
+}
+```
+
+### Object with Multiple Fields
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "username": {
+      "type": "string",
+      "description": "Your username"
+    },
+    "password": {
+      "type": "string",
+      "description": "Your password"
+    },
+    "remember": {
+      "type": "boolean",
+      "description": "Remember credentials"
+    }
+  },
+  "required": ["username", "password"]
+}
+```
+
+### Number Input
+
+```json
+{
+  "type": "integer",
+  "title": "Port Number",
+  "description": "Enter the port number (1024-65535)",
+  "minimum": 1024,
+  "maximum": 65535
+}
+```
+
+## Example Usage
+
+Here's how an agent might use the user prompt tool:
+
+```text
+Agent: I need to deploy this application. Let me ask which environment to target.
+
+[Calls user_prompt with message: "Which environment should I deploy to?"
+ and schema with enum: ["development", "staging", "production"]]
+
+User selects: "staging"
+
+Agent: Great, I'll deploy to staging. Let me confirm this action.
+
+[Calls user_prompt with message: "Deploy to staging? This will replace the current version."
+ and schema with type: "boolean"]
+
+User confirms: true
+
+Agent: Deploying to staging...
+```
+
+## UI Presentation
+
+How the prompt appears depends on the interface:
+
+- **TUI**: Displays an interactive dialog with appropriate input controls
+- **CLI (exec mode)**: Prints the prompt and reads from stdin
+- **API/MCP**: Returns an elicitation request to the client
+
+> [!TIP]
+> **Best Practice**
+>
+> Provide clear, concise messages. Include context about why you're asking and what the information will be used for. Use schemas with descriptions to guide users on expected input format.
+
+## Handling Responses
+
+The agent should handle all possible actions:
+
+- **accept**: Process the `content` and continue
+- **decline**: Acknowledge and try an alternative approach or explain what's needed
+- **cancel**: Stop the current operation gracefully
+
+> [!WARNING]
+> **Context Requirement**
+>
+> The user prompt tool requires an elicitation handler to be configured. It works in the TUI and CLI modes but may not be available in all contexts (e.g., some MCP client configurations).
diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md
new file mode 100644
index 000000000000..ded710754192
--- /dev/null
+++ b/_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md
@@ -0,0 +1,143 @@
+---
+title: "Webhook Tool"
+description: "Reliable outbound notifications to Slack, Discord, Telegram, IFTTT, and more."
+keywords: docker agent, ai agents, tools, toolsets, webhook, slack, discord, telegram, ifttt, notifications
+linkTitle: "Webhook"
+weight: 145
+canonical: https://docs.docker.com/ai/docker-agent/tools/webhook/
+---
+
+_Reliable outbound notifications to Slack, Discord, Telegram, IFTTT, and more._
+
+## Overview
+
+The webhook toolset delivers a notification to a destination **you configure**. The
+agent supplies only the message text: it never sees or chooses the URL, because a
+webhook URL is itself a credential (Slack and Mattermost embed a secret path,
+Discord a token, IFTTT a key, Telegram a bot token).
+
+This is not a general HTTP client — that is the [`api`](../api/index.md) toolset.
+The webhook toolset owns *delivery*:
+
+- **At-least-once delivery.** Transient failures (`429`, `5xx`, network errors) are
+  retried with exponential backoff, honouring the server's `Retry-After`. A `4xx`
+  is permanent and fails immediately without wasting retries.
+- **Non-blocking.** The call returns as soon as the notification is queued, so a
+  slow or retrying endpoint never stalls the agent's turn. The agent is messaged
+  back **only if delivery ultimately fails**.
+- **Storm protection.** An identical message to the same destination inside a short
+  window is suppressed, and notifications are rate limited, so a looping agent
+  cannot flood a channel.
+- **Provider-shaped payloads.** Each service's wire format is applied for you.
+
+## Configuration
+
+The destination lives in `webhook_config`. Use `${env.VAR}` for anything secret —
+values are expanded at call time and never stored in the config file.
+
+```yaml
+toolsets:
+  - type: webhook
+    webhook_config:
+      provider: slack
+      url: ${env.SLACK_WEBHOOK_URL}
+```
+
+| Field | Required | Description |
+| --- | --- | --- |
+| `url` | Yes | Webhook endpoint. Usually embeds a secret — prefer `${env.VAR}`. |
+| `provider` | No | Payload shape (default `generic`). |
+| `headers` | No | Extra headers, for endpoints authenticating with a token. |
+| `chat_id` | No | Destination chat — required for `provider: telegram`. |
+
+`timeout` on the toolset (seconds) overrides the per-request HTTP timeout.
+
+## Providers
+
+| Provider | Payload sent | Where the secret lives |
+| --- | --- | --- |
+| `slack`, `mattermost`, `rocketchat`, `googlechat`, `teams`, `generic` | `{"text": message}` | secret webhook URL |
+| `discord` | `{"content": message}` | token in the webhook URL |
+| `ifttt` | `{"value1": message, "value2": …, "value3": …}` | key in the webhook URL |
+| `telegram` | `{"chat_id": …, "text": message}` | bot token in the URL, plus `chat_id` |
+
+Aliases are accepted: `msteams`/`microsoft_teams` → `teams`, `google_chat`/`gchat`
+→ `googlechat`, `rocket.chat` → `rocketchat`.
+
+### Per-service examples
+
+```yaml
+# Slack / Mattermost / Rocket.Chat — the URL is the credential
+toolsets:
+  - type: webhook
+    webhook_config:
+      provider: slack
+      url: ${env.SLACK_WEBHOOK_URL}
+```
+
+```yaml
+# Discord — the token is part of the webhook URL
+toolsets:
+  - type: webhook
+    webhook_config:
+      provider: discord
+      url: ${env.DISCORD_WEBHOOK_URL}
+```
+
+```yaml
+# Telegram — bot token in the URL, chat_id selects the destination chat
+toolsets:
+  - type: webhook
+    webhook_config:
+      provider: telegram
+      url: https://api.telegram.org/bot${env.TELEGRAM_BOT_TOKEN}/sendMessage
+      chat_id: "123456789"
+```
+
+```yaml
+# IFTTT — the key is part of the trigger URL
+toolsets:
+  - type: webhook
+    webhook_config:
+      provider: ifttt
+      url: https://maker.ifttt.com/trigger/build_failed/with/key/${env.IFTTT_KEY}
+```
+
+```yaml
+# Generic endpoint authenticating with a bearer token
+toolsets:
+  - type: webhook
+    webhook_config:
+      provider: generic
+      url: https://alerts.example.com/notify
+      headers:
+        Authorization: Bearer ${env.ALERTS_TOKEN}
+```
+
+## `send_webhook`
+
+| Parameter | Required | Description |
+| --- | --- | --- |
+| `message` | Yes | The message text to deliver. |
+| `value2`, `value3` | No | Extra IFTTT data fields (`provider: ifttt`). |
+
+Returns immediately once queued. On success nothing further happens; if delivery
+ultimately fails, the agent receives a message saying so.
+
+## Example
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5-mini
+    instruction: If a check fails, notify the team with send_webhook.
+    toolsets:
+      - type: webhook
+        webhook_config:
+          provider: slack
+          url: ${env.SLACK_WEBHOOK_URL}
+```
+
+> [!NOTE]
+> Requests to non-public addresses are refused (the SSRF-safe HTTP client), and the
+> configured URL is never echoed back to the model or into error messages.
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model.yaml
new file mode 100644
index 000000000000..6d1588f6f05c
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model.yaml
@@ -0,0 +1,74 @@
+command: docker model
+short: Docker Model Runner
+long: |-
+    Use Docker Model Runner to run and interact with AI models directly from the command line.
+    For more information, see the [documentation](/ai/model-runner/)
+pname: docker
+plink: docker.yaml
+cname:
+    - docker model bench
+    - docker model context
+    - docker model df
+    - docker model gateway
+    - docker model inspect
+    - docker model install-runner
+    - docker model launch
+    - docker model list
+    - docker model logs
+    - docker model package
+    - docker model ps
+    - docker model pull
+    - docker model purge
+    - docker model push
+    - docker model reinstall-runner
+    - docker model requests
+    - docker model restart-runner
+    - docker model rm
+    - docker model run
+    - docker model search
+    - docker model show
+    - docker model skills
+    - docker model start-runner
+    - docker model status
+    - docker model stop-runner
+    - docker model tag
+    - docker model uninstall-runner
+    - docker model unload
+    - docker model version
+clink:
+    - docker_model_bench.yaml
+    - docker_model_context.yaml
+    - docker_model_df.yaml
+    - docker_model_gateway.yaml
+    - docker_model_inspect.yaml
+    - docker_model_install-runner.yaml
+    - docker_model_launch.yaml
+    - docker_model_list.yaml
+    - docker_model_logs.yaml
+    - docker_model_package.yaml
+    - docker_model_ps.yaml
+    - docker_model_pull.yaml
+    - docker_model_purge.yaml
+    - docker_model_push.yaml
+    - docker_model_reinstall-runner.yaml
+    - docker_model_requests.yaml
+    - docker_model_restart-runner.yaml
+    - docker_model_rm.yaml
+    - docker_model_run.yaml
+    - docker_model_search.yaml
+    - docker_model_show.yaml
+    - docker_model_skills.yaml
+    - docker_model_start-runner.yaml
+    - docker_model_status.yaml
+    - docker_model_stop-runner.yaml
+    - docker_model_tag.yaml
+    - docker_model_uninstall-runner.yaml
+    - docker_model_unload.yaml
+    - docker_model_version.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_bench.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_bench.yaml
new file mode 100644
index 000000000000..65071532f5fe
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_bench.yaml
@@ -0,0 +1,69 @@
+command: docker model bench
+short: Benchmark a model's performance at different concurrency levels
+long: |-
+    Benchmark a model's performance showing tokens per second at different concurrency levels.
+
+    This command runs a series of benchmarks with 1, 2, 4, and 8 concurrent requests by default,
+    measuring the tokens per second (TPS) that the model can generate.
+usage: docker model bench MODEL
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: concurrency
+      value_type: intSlice
+      default_value: '[1,2,4,8]'
+      description: Concurrency levels to test
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: duration
+      value_type: duration
+      default_value: 30s
+      description: Duration to run each concurrency test
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output results in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: prompt
+      value_type: string
+      default_value: |
+        Write a comprehensive 100 word summary on whales and their impact on society.
+      description: Prompt to use for benchmarking
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: timeout
+      value_type: duration
+      default_value: 5m0s
+      description: Timeout for each individual request
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose.yaml
new file mode 100644
index 000000000000..4ed9874c0f10
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose.yaml
@@ -0,0 +1,28 @@
+command: docker model compose
+pname: docker model
+plink: docker_model.yaml
+cname:
+    - docker model compose down
+    - docker model compose metadata
+    - docker model compose up
+clink:
+    - docker_model_compose_down.yaml
+    - docker_model_compose_metadata.yaml
+    - docker_model_compose_up.yaml
+options:
+    - option: project-name
+      value_type: string
+      description: compose project name
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: true
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose_down.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose_down.yaml
new file mode 100644
index 000000000000..39ff0baf59ee
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose_down.yaml
@@ -0,0 +1,21 @@
+command: docker model compose down
+usage: docker model compose down
+pname: docker model compose
+plink: docker_model_compose.yaml
+inherited_options:
+    - option: project-name
+      value_type: string
+      description: compose project name
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: true
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose_metadata.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose_metadata.yaml
new file mode 100644
index 000000000000..d618dcc588a6
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose_metadata.yaml
@@ -0,0 +1,23 @@
+command: docker model compose metadata
+short: Metadata for Docker Compose
+long: Metadata for Docker Compose
+usage: docker model compose metadata
+pname: docker model compose
+plink: docker_model_compose.yaml
+inherited_options:
+    - option: project-name
+      value_type: string
+      description: compose project name
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: true
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose_up.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose_up.yaml
new file mode 100644
index 000000000000..17e91577948c
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_compose_up.yaml
@@ -0,0 +1,90 @@
+command: docker model compose up
+usage: docker model compose up
+pname: docker model compose
+plink: docker_model_compose.yaml
+options:
+    - option: backend
+      value_type: string
+      default_value: llama.cpp
+      description: inference backend to use
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: context-size
+      value_type: int64
+      default_value: "-1"
+      description: context size for the model
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: model
+      value_type: stringArray
+      default_value: '[]'
+      description: model to use
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: runtime-flags
+      value_type: string
+      description: raw runtime flags to pass to the inference engine
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: speculative-draft-model
+      value_type: string
+      description: draft model for speculative decoding
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: speculative-min-acceptance-rate
+      value_type: float64
+      default_value: "0"
+      description: minimum acceptance rate for speculative decoding
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: speculative-num-tokens
+      value_type: int
+      default_value: "0"
+      description: number of tokens to predict speculatively
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: project-name
+      value_type: string
+      description: compose project name
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: true
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_configure.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_configure.yaml
new file mode 100644
index 000000000000..77f914fdcf6a
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_configure.yaml
@@ -0,0 +1,105 @@
+command: docker model configure
+aliases: docker model configure, docker model config
+short: Manage model runtime configurations
+long: Manage model runtime configurations
+usage: docker model configure [--context-size=<n>] [--speculative-draft-model=<model>] [--hf_overrides=<json>] [--gpu-memory-utilization=<float>] [--mode=<mode>] [--think] [--keep-alive=<duration>] MODEL [-- <runtime-flags...>]
+pname: docker model
+plink: docker_model.yaml
+cname:
+    - docker model configure show
+clink:
+    - docker_model_configure_show.yaml
+options:
+    - option: context-size
+      value_type: int32
+      description: context size (in tokens)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gpu-memory-utilization
+      value_type: float64
+      description: |
+        fraction of GPU memory to use for the model executor (0.0-1.0) - vLLM only
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: hf_overrides
+      value_type: string
+      description: HuggingFace model config overrides (JSON) - vLLM only
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: keep-alive
+      value_type: string
+      description: |
+        duration to keep model loaded (e.g., '5m', '1h', '0' to unload immediately, '-1' to never unload)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: mode
+      value_type: string
+      description: |
+        backend operation mode (completion, embedding, reranking, image-generation)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: speculative-draft-model
+      value_type: string
+      description: draft model for speculative decoding
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: speculative-min-acceptance-rate
+      value_type: float64
+      default_value: "0"
+      description: minimum acceptance rate for speculative decoding
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: speculative-num-tokens
+      value_type: int
+      default_value: "0"
+      description: number of tokens to predict speculatively
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: think
+      value_type: bool
+      description: enable reasoning mode for thinking models
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: true
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_configure_show.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_configure_show.yaml
new file mode 100644
index 000000000000..588c5c1b3e8f
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_configure_show.yaml
@@ -0,0 +1,13 @@
+command: docker model configure show
+short: Show model configurations
+long: Show model configurations
+usage: docker model configure show [MODEL]
+pname: docker model configure
+plink: docker_model_configure.yaml
+deprecated: false
+hidden: true
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context.yaml
new file mode 100644
index 000000000000..05a532ba7272
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context.yaml
@@ -0,0 +1,24 @@
+command: docker model context
+short: Manage Docker Model Runner contexts
+long: Manage Docker Model Runner contexts
+pname: docker model
+plink: docker_model.yaml
+cname:
+    - docker model context create
+    - docker model context inspect
+    - docker model context ls
+    - docker model context rm
+    - docker model context use
+clink:
+    - docker_model_context_create.yaml
+    - docker_model_context_inspect.yaml
+    - docker_model_context_ls.yaml
+    - docker_model_context_rm.yaml
+    - docker_model_context_use.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_create.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_create.yaml
new file mode 100644
index 000000000000..47e5bb49db1d
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_create.yaml
@@ -0,0 +1,61 @@
+command: docker model context create
+short: Create a named Model Runner context
+long: Create a named Model Runner context
+usage: docker model context create NAME
+pname: docker model context
+plink: docker_model_context.yaml
+options:
+    - option: description
+      value_type: string
+      description: Optional human-readable description for this context
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: host
+      value_type: string
+      description: Model Runner API base URL (e.g. http://192.168.1.100:12434)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls
+      value_type: bool
+      default_value: "false"
+      description: Enable TLS for connections to this context
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls-ca-cert
+      value_type: string
+      description: Path to a custom CA certificate PEM file for TLS verification
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls-skip-verify
+      value_type: bool
+      default_value: "false"
+      description: Skip TLS server certificate verification
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_inspect.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_inspect.yaml
new file mode 100644
index 000000000000..82c897dd3874
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_inspect.yaml
@@ -0,0 +1,13 @@
+command: docker model context inspect
+short: Display detailed information about one or more contexts
+long: Display detailed information about one or more contexts
+usage: docker model context inspect NAME [NAME...]
+pname: docker model context
+plink: docker_model_context.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_ls.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_ls.yaml
new file mode 100644
index 000000000000..cf97594f1df3
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_ls.yaml
@@ -0,0 +1,14 @@
+command: docker model context ls
+aliases: docker model context ls, docker model context list
+short: List Model Runner contexts
+long: List Model Runner contexts
+usage: docker model context ls
+pname: docker model context
+plink: docker_model_context.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_rm.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_rm.yaml
new file mode 100644
index 000000000000..2efa303bb1b0
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_rm.yaml
@@ -0,0 +1,14 @@
+command: docker model context rm
+aliases: docker model context rm, docker model context remove
+short: Remove one or more Model Runner contexts
+long: Remove one or more Model Runner contexts
+usage: docker model context rm NAME [NAME...]
+pname: docker model context
+plink: docker_model_context.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_use.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_use.yaml
new file mode 100644
index 000000000000..720281626cfe
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_context_use.yaml
@@ -0,0 +1,15 @@
+command: docker model context use
+short: Set the active Model Runner context
+long: |-
+    Set the active Model Runner context. Pass "default" to revert to
+    automatic backend detection.
+usage: docker model context use NAME
+pname: docker model context
+plink: docker_model_context.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_df.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_df.yaml
new file mode 100644
index 000000000000..7f1ba55b875d
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_df.yaml
@@ -0,0 +1,13 @@
+command: docker model df
+short: Show Docker Model Runner disk usage
+long: Show Docker Model Runner disk usage
+usage: docker model df
+pname: docker model
+plink: docker_model.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_gateway.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_gateway.yaml
new file mode 100644
index 000000000000..b6cf57a39bdc
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_gateway.yaml
@@ -0,0 +1,182 @@
+command: docker model gateway
+short: Run an OpenAI-compatible LLM gateway
+long: |-
+    `docker model gateway` starts a local OpenAI-compatible HTTP gateway that routes
+    requests to one or more configured LLM providers. It supports Docker Model Runner
+    as a first-class provider, alongside Ollama, OpenAI, Anthropic, Groq, Mistral,
+    Azure OpenAI, and many other OpenAI-compatible endpoints.
+
+    The gateway is configured through a YAML file that declares the model list,
+    provider routing, load-balancing, retries, and fallbacks.
+
+    ### Configuration file format
+
+    ```yaml
+    model_list:
+      - model_name: <alias exposed to clients>
+        params:
+          model: <provider>/<upstream-model-name>
+          api_base: <optional base URL override>
+          api_key: <optional key or os.environ/VAR_NAME>
+
+    general_settings:
+      master_key: <optional API key required by clients>
+      num_retries: <optional integer, default 0>
+      fallbacks:
+        - <primary-alias>: [<fallback-alias>, ...]
+    ```
+
+    The `model` field under `params` uses the format `provider/model-name`.
+    Supported provider prefixes include: `docker_model_runner`, `openai`,
+    `anthropic`, `ollama`, `groq`, `mistral`, `together_ai`, `deepseek`,
+    `fireworks_ai`, `openrouter`, `perplexity`, `xai`, `nvidia_nim`,
+    `cerebras`, `sambanova`, `deepinfra`, `azure`, `azure_ai`, `vllm`,
+    `lm_studio`, `huggingface`.
+
+    API keys can be supplied inline, as `os.environ/VAR_NAME` references, or as
+    `${VAR_NAME}` references. The gateway resolves well-known environment variables
+    automatically (for example, `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`).
+usage: docker model gateway
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: config
+      shorthand: c
+      value_type: string
+      description: Path to the YAML configuration file
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: host
+      value_type: string
+      default_value: 0.0.0.0
+      description: Host address to bind to
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: port
+      shorthand: p
+      value_type: uint16
+      default_value: "4000"
+      description: Port to listen on
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose
+      shorthand: v
+      value_type: bool
+      default_value: "false"
+      description: Enable verbose (debug) logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Route requests to Docker Model Runner
+
+    ```yaml
+    model_list:
+      - model_name: smollm2
+        params:
+          model: docker_model_runner/ai/smollm2
+          api_base: http://localhost:12434/engines/llama.cpp/v1
+    ```
+
+    ```console
+    $ docker model gateway --config config.yaml
+    ```
+
+    The gateway starts on `http://0.0.0.0:4000`. Send requests using any
+    OpenAI-compatible client:
+
+    ```console
+    $ curl http://localhost:4000/v1/chat/completions \
+        -H "Content-Type: application/json" \
+        -d '{
+          "model": "smollm2",
+          "messages": [{"role": "user", "content": "Hello"}]
+        }'
+    ```
+
+    ### Route requests to multiple providers with fallback
+
+    ```yaml
+    model_list:
+      - model_name: fast
+        params:
+          model: groq/llama-3.1-8b-instant
+          api_key: os.environ/GROQ_API_KEY
+      - model_name: smart
+        params:
+          model: openai/gpt-4o
+          api_key: os.environ/OPENAI_API_KEY
+      - model_name: local
+        params:
+          model: docker_model_runner/ai/smollm2
+          api_base: http://localhost:12434/engines/llama.cpp/v1
+
+    general_settings:
+      num_retries: 2
+      fallbacks:
+        - fast: [local]
+        - smart: [fast, local]
+    ```
+
+    ```console
+    $ docker model gateway --config config.yaml --port 8080
+    ```
+
+    ### Secure the gateway with an API key
+
+    ```yaml
+    model_list:
+      - model_name: smollm2
+        params:
+          model: docker_model_runner/ai/smollm2
+          api_base: http://localhost:12434/engines/llama.cpp/v1
+
+    general_settings:
+      master_key: os.environ/GATEWAY_API_KEY
+    ```
+
+    ```console
+    $ GATEWAY_API_KEY=my-secret docker model gateway --config config.yaml
+    ```
+
+    Clients must then pass the key as a Bearer token or via the `x-api-key` header:
+
+    ```console
+    $ curl http://localhost:4000/v1/chat/completions \
+        -H "Content-Type: application/json" \
+        -d '{"model": "smollm2", "messages": [{"role": "user", "content": "Hi"}]}'
+    ```
+
+    ### Use a custom host and port
+
+    ```console
+    $ docker model gateway --config config.yaml --host 127.0.0.1 --port 9000
+    ```
+
+    ### Enable debug logging
+
+    ```console
+    $ docker model gateway --config config.yaml --verbose
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_inspect.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_inspect.yaml
new file mode 100644
index 000000000000..c422f0210389
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_inspect.yaml
@@ -0,0 +1,35 @@
+command: docker model inspect
+short: Display detailed information on one model
+long: Display detailed information on one model
+usage: docker model inspect MODEL
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: openai
+      value_type: bool
+      default_value: "false"
+      description: List model in an OpenAI format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: remote
+      shorthand: r
+      value_type: bool
+      default_value: "false"
+      description: Show info for remote models
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_install-runner.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_install-runner.yaml
new file mode 100644
index 000000000000..562fd6bbfbff
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_install-runner.yaml
@@ -0,0 +1,123 @@
+command: docker model install-runner
+short: Install Docker Model Runner (Docker Engine only)
+long: |
+    This command runs implicitly when a docker model command is executed. You can run this command explicitly to add a new configuration.
+usage: docker model install-runner
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: backend
+      value_type: string
+      description: 'Specify backend (llama.cpp|vllm|diffusers). Default: llama.cpp'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: do-not-track
+      value_type: bool
+      default_value: "false"
+      description: Do not track models usage in Docker Model Runner
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gpu
+      value_type: string
+      default_value: auto
+      description: Specify GPU support (none|auto|cuda|rocm|musa|cann)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: host
+      value_type: string
+      default_value: 127.0.0.1
+      description: Host address to bind Docker Model Runner
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: port
+      value_type: uint16
+      default_value: "0"
+      description: |
+        Docker container port for Docker Model Runner (default: 12434 for Docker Engine, 12435 for Cloud mode)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: proxy-cert
+      value_type: string
+      description: Path to a CA certificate file for proxy SSL inspection
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls
+      value_type: bool
+      default_value: "false"
+      description: Enable TLS/HTTPS for Docker Model Runner API
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls-cert
+      value_type: string
+      description: Path to TLS certificate file (auto-generated if not provided)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls-key
+      value_type: string
+      description: Path to TLS private key file (auto-generated if not provided)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls-port
+      value_type: uint16
+      default_value: "0"
+      description: |
+        TLS port for Docker Model Runner (default: 12444 for Docker Engine, 12445 for Cloud mode)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_launch.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_launch.yaml
new file mode 100644
index 000000000000..58f074ee0237
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_launch.yaml
@@ -0,0 +1,84 @@
+command: docker model launch
+short: Launch an app configured to use Docker Model Runner
+long: |-
+    Launch an app configured to use Docker Model Runner.
+
+    Without arguments, lists all supported apps.
+
+    Supported apps: anythingllm, claude, codex, openclaw, opencode, openwebui
+
+    Examples:
+      docker model launch
+      docker model launch opencode
+      docker model launch claude -- --help
+      docker model launch openwebui --port 3000
+      docker model launch claude --config
+usage: docker model launch [APP] [-- APP_ARGS...]
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: config
+      value_type: bool
+      default_value: "false"
+      description: Print configuration without launching
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: detach
+      value_type: bool
+      default_value: "false"
+      description: Run containerized app in background
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: dry-run
+      value_type: bool
+      default_value: "false"
+      description: Print what would be executed without running it
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: image
+      value_type: string
+      description: Override container image for containerized apps
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: model
+      value_type: string
+      description: Model to use (for opencode)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: port
+      value_type: int
+      default_value: "0"
+      description: Host port to expose (web UIs)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_list.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_list.yaml
new file mode 100644
index 000000000000..242462f4c145
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_list.yaml
@@ -0,0 +1,55 @@
+command: docker model list
+aliases: docker model list, docker model ls
+short: List the models pulled to your local environment
+long: List the models pulled to your local environment
+usage: docker model list [OPTIONS] [MODEL]
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: List models in a JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: openai
+      value_type: bool
+      default_value: "false"
+      description: List models in an OpenAI format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: openaiurl
+      value_type: string
+      description: OpenAI-compatible API endpoint URL to list models from
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: quiet
+      shorthand: q
+      value_type: bool
+      default_value: "false"
+      description: Only show model IDs
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_logs.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_logs.yaml
new file mode 100644
index 000000000000..4f5daf177fe8
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_logs.yaml
@@ -0,0 +1,35 @@
+command: docker model logs
+short: Fetch the Docker Model Runner logs
+long: Fetch the Docker Model Runner logs
+usage: docker model logs [OPTIONS]
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: follow
+      shorthand: f
+      value_type: bool
+      default_value: "false"
+      description: View logs with real-time streaming
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: no-engines
+      value_type: bool
+      default_value: "false"
+      description: Exclude inference engine logs from the output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_package.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_package.yaml
new file mode 100644
index 000000000000..7bc696c5b7ca
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_package.yaml
@@ -0,0 +1,149 @@
+command: docker model package
+short: Package a model into a Docker Model OCI artifact
+long: |-
+    Package a model into a Docker Model OCI artifact.
+
+    The model source must be one of:
+      --gguf               A GGUF file (single file or first shard of a sharded model)
+      --safetensors-dir    A directory containing .safetensors and configuration files
+      --dduf               A .dduf (Diffusers Unified Format) archive
+      --from               An existing packaged model reference
+
+    By default, the packaged artifact is loaded into the local Model Runner content store.
+    Use --push to publish the model to a registry instead.
+
+    MODEL specifies the target model reference (for example: myorg/llama3:8b).
+    When using --push, MODEL must be a registry-qualified reference.
+
+    Packaging behavior:
+
+      GGUF
+        --gguf must point to a .gguf file.
+        For sharded models, point to the first shard. All shards must:
+          • reside in the same directory
+          • follow an indexed naming convention (e.g. model-00001-of-00015.gguf)
+        All shards are automatically discovered and packaged together.
+
+      Safetensors
+        --safetensors-dir must point to a directory containing .safetensors files
+        and required configuration files (e.g. model config, tokenizer files).
+        All files under the directory (including nested subdirectories) are
+        automatically discovered. Each file is packaged as a separate OCI layer.
+
+      DDUF
+        --dduf must point to a .dduf archive file.
+
+      Repackaging
+        --from repackages an existing model. You may override selected properties
+        such as --context-size to create a variant of the original model.
+
+      Multimodal models
+        Use --mmproj to include a multimodal projector file.
+usage: docker model package (--gguf <path> | --safetensors-dir <path> | --dduf <path> | --from <model>) [--license <path>...] [--mmproj <path>] [--context-size <tokens>] [--push] MODEL
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: chat-template
+      value_type: string
+      description: absolute path to chat template file (must be Jinja format)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: context-size
+      value_type: uint64
+      default_value: "0"
+      description: context size in tokens
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: dduf
+      value_type: string
+      description: absolute path to DDUF archive file (Diffusers Unified Format)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: format
+      value_type: string
+      default_value: docker
+      description: |
+        output artifact format: "docker" (default) or "cncf" (CNCF ModelPack spec)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: from
+      value_type: string
+      description: reference to an existing model to repackage
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gguf
+      value_type: string
+      description: absolute path to gguf file
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: license
+      shorthand: l
+      value_type: stringArray
+      default_value: '[]'
+      description: absolute path to a license file
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: mmproj
+      value_type: string
+      description: absolute path to multimodal projector file
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: push
+      value_type: bool
+      default_value: "false"
+      description: |
+        push to registry (if not set, the model is loaded into the Model Runner content store)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: safetensors-dir
+      value_type: string
+      description: absolute path to directory containing safetensors files and config
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_ps.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_ps.yaml
new file mode 100644
index 000000000000..0f4cf1e63b77
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_ps.yaml
@@ -0,0 +1,13 @@
+command: docker model ps
+short: List running models
+long: List running models
+usage: docker model ps
+pname: docker model
+plink: docker_model.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_pull.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_pull.yaml
new file mode 100644
index 000000000000..c939304581de
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_pull.yaml
@@ -0,0 +1,33 @@
+command: docker model pull
+short: Pull a model from Docker Hub or HuggingFace to your local environment
+long: |
+    Pull a model to your local environment. Downloaded models also appear in the Docker Desktop Dashboard.
+usage: docker model pull MODEL
+pname: docker model
+plink: docker_model.yaml
+examples: |-
+    ### Pulling a model from Docker Hub
+
+    ```console
+    docker model pull ai/smollm2
+    ```
+
+    ### Pulling from HuggingFace
+
+    You can pull GGUF models directly from [Hugging Face](https://huggingface.co/models?library=gguf).
+
+    **Note about quantization:** If no tag is specified, the command tries to pull the `Q4_K_M` version of the model.
+    If `Q4_K_M` doesn't exist, the command pulls the first GGUF found in the **Files** view of the model on HuggingFace.
+    To specify the quantization, provide it as a tag, for example:
+    `docker model pull hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF:Q4_K_S`
+
+    ```console
+    docker model pull hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_purge.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_purge.yaml
new file mode 100644
index 000000000000..425923b91d37
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_purge.yaml
@@ -0,0 +1,25 @@
+command: docker model purge
+short: Remove all models
+long: Remove all models
+usage: docker model purge [OPTIONS]
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: force
+      shorthand: f
+      value_type: bool
+      default_value: "false"
+      description: Forcefully remove all models
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_push.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_push.yaml
new file mode 100644
index 000000000000..65c9ddfbe64f
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_push.yaml
@@ -0,0 +1,13 @@
+command: docker model push
+short: Push a model to Docker Hub or Hugging Face
+long: Push a model to Docker Hub or Hugging Face
+usage: docker model push MODEL
+pname: docker model
+plink: docker_model.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_reinstall-runner.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_reinstall-runner.yaml
new file mode 100644
index 000000000000..35d328b55181
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_reinstall-runner.yaml
@@ -0,0 +1,123 @@
+command: docker model reinstall-runner
+short: Reinstall Docker Model Runner (Docker Engine only)
+long: |
+    This command removes the existing Docker Model Runner container and reinstalls it with the specified configuration. Models and images are preserved during reinstallation.
+usage: docker model reinstall-runner
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: backend
+      value_type: string
+      description: 'Specify backend (llama.cpp|vllm|diffusers). Default: llama.cpp'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: do-not-track
+      value_type: bool
+      default_value: "false"
+      description: Do not track models usage in Docker Model Runner
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gpu
+      value_type: string
+      default_value: auto
+      description: Specify GPU support (none|auto|cuda|rocm|musa|cann)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: host
+      value_type: string
+      default_value: 127.0.0.1
+      description: Host address to bind Docker Model Runner
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: port
+      value_type: uint16
+      default_value: "0"
+      description: |
+        Docker container port for Docker Model Runner (default: 12434 for Docker Engine, 12435 for Cloud mode)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: proxy-cert
+      value_type: string
+      description: Path to a CA certificate file for proxy SSL inspection
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls
+      value_type: bool
+      default_value: "false"
+      description: Enable TLS/HTTPS for Docker Model Runner API
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls-cert
+      value_type: string
+      description: Path to TLS certificate file (auto-generated if not provided)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls-key
+      value_type: string
+      description: Path to TLS private key file (auto-generated if not provided)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls-port
+      value_type: uint16
+      default_value: "0"
+      description: |
+        TLS port for Docker Model Runner (default: 12444 for Docker Engine, 12445 for Cloud mode)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_requests.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_requests.yaml
new file mode 100644
index 000000000000..eecab3ba3607
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_requests.yaml
@@ -0,0 +1,45 @@
+command: docker model requests
+short: Fetch requests+responses from Docker Model Runner
+long: Fetch requests+responses from Docker Model Runner
+usage: docker model requests [OPTIONS]
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: follow
+      shorthand: f
+      value_type: bool
+      default_value: "false"
+      description: Follow requests stream
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: include-existing
+      value_type: bool
+      default_value: "false"
+      description: |
+        Include existing requests when starting to follow (only available with --follow)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: model
+      value_type: string
+      description: Specify the model to filter requests
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_restart-runner.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_restart-runner.yaml
new file mode 100644
index 000000000000..652fb64b0808
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_restart-runner.yaml
@@ -0,0 +1,77 @@
+command: docker model restart-runner
+short: Restart Docker Model Runner (Docker Engine only)
+long: |-
+    This command restarts the Docker Model Runner without pulling container images. Use this command to restart the runner when you already have the required images locally.
+
+    For the first-time setup or to ensure you have the latest images, use `docker model install-runner` instead.
+usage: docker model restart-runner
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: do-not-track
+      value_type: bool
+      default_value: "false"
+      description: Do not track models usage in Docker Model Runner
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gpu
+      value_type: string
+      default_value: auto
+      description: Specify GPU support (none|auto|cuda|rocm|musa|cann)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: host
+      value_type: string
+      default_value: 127.0.0.1
+      description: Host address to bind Docker Model Runner
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: port
+      value_type: uint16
+      default_value: "0"
+      description: |
+        Docker container port for Docker Model Runner (default: 12434 for Docker Engine, 12435 for Cloud mode)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: proxy-cert
+      value_type: string
+      description: Path to a CA certificate file for proxy SSL inspection
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_rm.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_rm.yaml
new file mode 100644
index 000000000000..1a1028dc8a79
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_rm.yaml
@@ -0,0 +1,25 @@
+command: docker model rm
+short: Remove local models downloaded from Docker Hub
+long: Remove local models downloaded from Docker Hub
+usage: docker model rm [MODEL...]
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: force
+      shorthand: f
+      value_type: bool
+      default_value: "false"
+      description: Forcefully remove the model
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_run.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_run.yaml
new file mode 100644
index 000000000000..9ffb3785c542
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_run.yaml
@@ -0,0 +1,103 @@
+command: docker model run
+short: Run a model and interact with it using a submitted prompt or chat mode
+long: |-
+    When you run a model, Docker calls an inference server API endpoint hosted by the Model Runner through Docker Desktop. The model stays in memory until another model is requested, or until a pre-defined inactivity timeout is reached (currently 5 minutes).
+
+    You do not have to use Docker model run before interacting with a specific model from a host process or from within a container. Model Runner transparently loads the requested model on-demand, assuming it has been pulled and is locally available.
+
+    You can also use chat mode in the Docker Desktop Dashboard when you select the model in the **Models** tab.
+usage: docker model run MODEL [PROMPT]
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: color
+      value_type: string
+      default_value: "no"
+      description: Use colored output (auto|yes|no)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: detach
+      shorthand: d
+      value_type: bool
+      default_value: "false"
+      description: Load the model in the background without interaction
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: openaiurl
+      value_type: string
+      description: OpenAI-compatible API endpoint URL to chat with
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: websearch
+      value_type: bool
+      default_value: "false"
+      description: Enable web search tool during chat
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### One-time prompt
+
+    ```console
+    docker model run ai/smollm2 "Hi"
+    ```
+
+    Output:
+
+    ```console
+    Hello! How can I assist you today?
+    ```
+
+    ### Interactive chat
+
+    ```console
+    docker model run ai/smollm2
+    ```
+
+    Output:
+
+    ```console
+    > Hi
+    Hi there! It's SmolLM, AI assistant. How can I help you today?
+    > /bye
+    ```
+
+    ### Pre-load a model
+
+    ```console
+    docker model run --detach ai/smollm2
+    ```
+
+    This loads the model into memory without interaction, ensuring maximum performance for subsequent requests.
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_search.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_search.yaml
new file mode 100644
index 000000000000..72129bd7a32e
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_search.yaml
@@ -0,0 +1,57 @@
+command: docker model search
+short: Search for models on Docker Hub and HuggingFace
+long: |-
+    Search for models from Docker Hub (ai/ namespace) and HuggingFace.
+
+    When no search term is provided, lists all available models.
+    When a search term is provided, filters models by name/description.
+
+    Examples:
+      docker model search                       # List available models from Docker Hub
+      docker model search llama                 # Search for models containing "llama"
+      docker model search --source=all          # Search both Docker Hub and HuggingFace
+      docker model search --source=huggingface  # Only search HuggingFace
+      docker model search --limit=50 phi        # Search with custom limit
+      docker model search --json llama          # Output as JSON
+usage: docker model search [OPTIONS] [TERM]
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output results as JSON
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: limit
+      shorthand: "n"
+      value_type: int
+      default_value: "32"
+      description: Maximum number of results to show
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: source
+      value_type: string
+      default_value: all
+      description: 'Source to search: all, dockerhub, huggingface'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_show.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_show.yaml
new file mode 100644
index 000000000000..c119856732f3
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_show.yaml
@@ -0,0 +1,25 @@
+command: docker model show
+short: Show information for a model
+long: Display detailed information about a model in a human-readable format.
+usage: docker model show MODEL
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: remote
+      shorthand: r
+      value_type: bool
+      default_value: "false"
+      description: Show info for remote models
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_skills.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_skills.yaml
new file mode 100644
index 000000000000..27274b18b0f1
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_skills.yaml
@@ -0,0 +1,79 @@
+command: docker model skills
+short: Install Docker Model Runner skills for AI coding assistants
+long: |-
+    Install Docker Model Runner skills for AI coding assistants.
+
+    Skills are configuration files that help AI coding assistants understand
+    how to use Docker Model Runner effectively for local model inference.
+
+    Supported targets:
+      --codex     Install to ~/.codex/skills (OpenAI Codex CLI)
+      --claude    Install to ~/.claude/skills (Claude Code)
+      --opencode  Install to ~/.config/opencode/skills (OpenCode)
+      --dest      Install to a custom directory
+
+    Example:
+      docker model skills --claude
+      docker model skills --codex --claude
+      docker model skills --dest /path/to/skills
+usage: docker model skills
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: claude
+      value_type: bool
+      default_value: "false"
+      description: Install skills for Claude Code (~/.claude/skills)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: codex
+      value_type: bool
+      default_value: "false"
+      description: Install skills for OpenAI Codex CLI (~/.codex/skills)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: dest
+      value_type: string
+      description: Install skills to a custom directory
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: force
+      shorthand: f
+      value_type: bool
+      default_value: "false"
+      description: Overwrite existing skills without prompting
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: opencode
+      value_type: bool
+      default_value: "false"
+      description: Install skills for OpenCode (~/.config/opencode/skills)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_start-runner.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_start-runner.yaml
new file mode 100644
index 000000000000..740e36c53a1d
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_start-runner.yaml
@@ -0,0 +1,125 @@
+command: docker model start-runner
+short: Start Docker Model Runner (Docker Engine only)
+long: |-
+    This command starts the Docker Model Runner without pulling container images. Use this command to start the runner when you already have the required images locally.
+
+    For the first-time setup or to ensure you have the latest images, use `docker model install-runner` instead.
+usage: docker model start-runner
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: backend
+      value_type: string
+      description: 'Specify backend (llama.cpp|vllm|diffusers). Default: llama.cpp'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: do-not-track
+      value_type: bool
+      default_value: "false"
+      description: Do not track models usage in Docker Model Runner
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gpu
+      value_type: string
+      default_value: auto
+      description: Specify GPU support (none|auto|cuda|rocm|musa|cann)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: host
+      value_type: string
+      default_value: 127.0.0.1
+      description: Host address to bind Docker Model Runner
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: port
+      value_type: uint16
+      default_value: "0"
+      description: |
+        Docker container port for Docker Model Runner (default: 12434 for Docker Engine, 12435 for Cloud mode)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: proxy-cert
+      value_type: string
+      description: Path to a CA certificate file for proxy SSL inspection
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls
+      value_type: bool
+      default_value: "false"
+      description: Enable TLS/HTTPS for Docker Model Runner API
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls-cert
+      value_type: string
+      description: Path to TLS certificate file (auto-generated if not provided)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls-key
+      value_type: string
+      description: Path to TLS private key file (auto-generated if not provided)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tls-port
+      value_type: uint16
+      default_value: "0"
+      description: |
+        TLS port for Docker Model Runner (default: 12444 for Docker Engine, 12445 for Cloud mode)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_status.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_status.yaml
new file mode 100644
index 000000000000..8f0b789f85bb
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_status.yaml
@@ -0,0 +1,25 @@
+command: docker model status
+short: Check if the Docker Model Runner is running
+long: |
+    Check whether the Docker Model Runner is running and displays the current inference engine.
+usage: docker model status
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Format output in JSON
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_stop-runner.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_stop-runner.yaml
new file mode 100644
index 000000000000..8d565b868191
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_stop-runner.yaml
@@ -0,0 +1,27 @@
+command: docker model stop-runner
+short: Stop Docker Model Runner (Docker Engine only)
+long: |-
+    This command stops the Docker Model Runner by removing the running containers, but preserves the container images on disk. Use this command when you want to temporarily stop the runner but plan to start it again later.
+
+    To completely remove the runner including images, use `docker model uninstall-runner --images` instead.
+usage: docker model stop-runner
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: models
+      value_type: bool
+      default_value: "false"
+      description: Remove model storage volume
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_tag.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_tag.yaml
new file mode 100644
index 000000000000..6239e6138751
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_tag.yaml
@@ -0,0 +1,14 @@
+command: docker model tag
+short: Tag a model
+long: |
+    Specify a particular version or variant of the model. If no tag is provided, Docker defaults to `latest`.
+usage: docker model tag SOURCE TARGET
+pname: docker model
+plink: docker_model.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_uninstall-runner.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_uninstall-runner.yaml
new file mode 100644
index 000000000000..e93363d5381b
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_uninstall-runner.yaml
@@ -0,0 +1,43 @@
+command: docker model uninstall-runner
+short: Uninstall Docker Model Runner (Docker Engine only)
+long: Uninstall Docker Model Runner (Docker Engine only)
+usage: docker model uninstall-runner
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: backend
+      value_type: string
+      description: Uninstall a deferred backend (e.g. vllm, diffusers)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: images
+      value_type: bool
+      default_value: "false"
+      description: Remove docker/model-runner images
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: models
+      value_type: bool
+      default_value: "false"
+      description: Remove model storage volume
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_unload.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_unload.yaml
new file mode 100644
index 000000000000..ee0de45bb327
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_unload.yaml
@@ -0,0 +1,34 @@
+command: docker model unload
+aliases: docker model unload, docker model stop
+short: Unload running models
+long: Unload running models
+usage: docker model unload (MODEL [MODEL ...] [--backend BACKEND] | --all)
+pname: docker model
+plink: docker_model.yaml
+options:
+    - option: all
+      value_type: bool
+      default_value: "false"
+      description: Unload all running models
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: backend
+      value_type: string
+      description: Optional backend to target
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_version.yaml b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_version.yaml
new file mode 100644
index 000000000000..2674843c99eb
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/docker_model_version.yaml
@@ -0,0 +1,13 @@
+command: docker model version
+short: Show the Docker Model Runner version
+long: Show the Docker Model Runner version
+usage: docker model version
+pname: docker model
+plink: docker_model.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model.md
new file mode 100644
index 000000000000..e26c01924be3
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model.md
@@ -0,0 +1,47 @@
+# docker model
+
+<!---MARKER_GEN_START-->
+Docker Model Runner
+
+### Subcommands
+
+| Name                                            | Description                                                            |
+|:------------------------------------------------|:-----------------------------------------------------------------------|
+| [`bench`](model_bench.md)                       | Benchmark a model's performance at different concurrency levels        |
+| [`context`](model_context.md)                   | Manage Docker Model Runner contexts                                    |
+| [`df`](model_df.md)                             | Show Docker Model Runner disk usage                                    |
+| [`gateway`](model_gateway.md)                   | Run an OpenAI-compatible LLM gateway                                   |
+| [`inspect`](model_inspect.md)                   | Display detailed information on one model                              |
+| [`install-runner`](model_install-runner.md)     | Install Docker Model Runner (Docker Engine only)                       |
+| [`launch`](model_launch.md)                     | Launch an app configured to use Docker Model Runner                    |
+| [`list`](model_list.md)                         | List the models pulled to your local environment                       |
+| [`logs`](model_logs.md)                         | Fetch the Docker Model Runner logs                                     |
+| [`package`](model_package.md)                   | Package a model into a Docker Model OCI artifact                       |
+| [`ps`](model_ps.md)                             | List running models                                                    |
+| [`pull`](model_pull.md)                         | Pull a model from Docker Hub or HuggingFace to your local environment  |
+| [`purge`](model_purge.md)                       | Remove all models                                                      |
+| [`push`](model_push.md)                         | Push a model to Docker Hub or Hugging Face                             |
+| [`reinstall-runner`](model_reinstall-runner.md) | Reinstall Docker Model Runner (Docker Engine only)                     |
+| [`requests`](model_requests.md)                 | Fetch requests+responses from Docker Model Runner                      |
+| [`restart-runner`](model_restart-runner.md)     | Restart Docker Model Runner (Docker Engine only)                       |
+| [`rm`](model_rm.md)                             | Remove local models downloaded from Docker Hub                         |
+| [`run`](model_run.md)                           | Run a model and interact with it using a submitted prompt or chat mode |
+| [`search`](model_search.md)                     | Search for models on Docker Hub and HuggingFace                        |
+| [`show`](model_show.md)                         | Show information for a model                                           |
+| [`skills`](model_skills.md)                     | Install Docker Model Runner skills for AI coding assistants            |
+| [`start-runner`](model_start-runner.md)         | Start Docker Model Runner (Docker Engine only)                         |
+| [`status`](model_status.md)                     | Check if the Docker Model Runner is running                            |
+| [`stop-runner`](model_stop-runner.md)           | Stop Docker Model Runner (Docker Engine only)                          |
+| [`tag`](model_tag.md)                           | Tag a model                                                            |
+| [`uninstall-runner`](model_uninstall-runner.md) | Uninstall Docker Model Runner (Docker Engine only)                     |
+| [`unload`](model_unload.md)                     | Unload running models                                                  |
+| [`version`](model_version.md)                   | Show the Docker Model Runner version                                   |
+
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+Use Docker Model Runner to run and interact with AI models directly from the command line.
+For more information, see the [documentation](https://docs.docker.com/ai/model-runner/)
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_bench.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_bench.md
new file mode 100644
index 000000000000..fbeaf5ac5358
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_bench.md
@@ -0,0 +1,21 @@
+# docker model bench
+
+<!---MARKER_GEN_START-->
+Benchmark a model's performance showing tokens per second at different concurrency levels.
+
+This command runs a series of benchmarks with 1, 2, 4, and 8 concurrent requests by default,
+measuring the tokens per second (TPS) that the model can generate.
+
+### Options
+
+| Name            | Type       | Default                                                                         | Description                           |
+|:----------------|:-----------|:--------------------------------------------------------------------------------|:--------------------------------------|
+| `--concurrency` | `intSlice` | `[1,2,4,8]`                                                                     | Concurrency levels to test            |
+| `--duration`    | `duration` | `30s`                                                                           | Duration to run each concurrency test |
+| `--json`        | `bool`     |                                                                                 | Output results in JSON format         |
+| `--prompt`      | `string`   | `Write a comprehensive 100 word summary on whales and their impact on society.` | Prompt to use for benchmarking        |
+| `--timeout`     | `duration` | `5m0s`                                                                          | Timeout for each individual request   |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_configure.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_configure.md
new file mode 100644
index 000000000000..81fc1546bd5e
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_configure.md
@@ -0,0 +1,14 @@
+# docker model configure
+
+<!---MARKER_GEN_START-->
+Configure runtime options for a model
+
+### Options
+
+| Name             | Type    | Default | Description              |
+|:-----------------|:--------|:--------|:-------------------------|
+| `--context-size` | `int64` | `-1`    | context size (in tokens) |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context.md
new file mode 100644
index 000000000000..d5c05658ce3b
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context.md
@@ -0,0 +1,19 @@
+# docker model context
+
+<!---MARKER_GEN_START-->
+Manage Docker Model Runner contexts
+
+### Subcommands
+
+| Name                                  | Description                                             |
+|:--------------------------------------|:--------------------------------------------------------|
+| [`create`](model_context_create.md)   | Create a named Model Runner context                     |
+| [`inspect`](model_context_inspect.md) | Display detailed information about one or more contexts |
+| [`ls`](model_context_ls.md)           | List Model Runner contexts                              |
+| [`rm`](model_context_rm.md)           | Remove one or more Model Runner contexts                |
+| [`use`](model_context_use.md)         | Set the active Model Runner context                     |
+
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_create.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_create.md
new file mode 100644
index 000000000000..cee0c6338275
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_create.md
@@ -0,0 +1,18 @@
+# docker model context create
+
+<!---MARKER_GEN_START-->
+Create a named Model Runner context
+
+### Options
+
+| Name                | Type     | Default | Description                                                   |
+|:--------------------|:---------|:--------|:--------------------------------------------------------------|
+| `--description`     | `string` |         | Optional human-readable description for this context          |
+| `--host`            | `string` |         | Model Runner API base URL (e.g. http://192.168.1.100:12434)   |
+| `--tls`             | `bool`   |         | Enable TLS for connections to this context                    |
+| `--tls-ca-cert`     | `string` |         | Path to a custom CA certificate PEM file for TLS verification |
+| `--tls-skip-verify` | `bool`   |         | Skip TLS server certificate verification                      |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_inspect.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_inspect.md
new file mode 100644
index 000000000000..75357d4a1d61
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_inspect.md
@@ -0,0 +1,8 @@
+# docker model context inspect
+
+<!---MARKER_GEN_START-->
+Display detailed information about one or more contexts
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_ls.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_ls.md
new file mode 100644
index 000000000000..5d9e980d85d4
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_ls.md
@@ -0,0 +1,12 @@
+# docker model context ls
+
+<!---MARKER_GEN_START-->
+List Model Runner contexts
+
+### Aliases
+
+`docker model context ls`, `docker model context list`
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_rm.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_rm.md
new file mode 100644
index 000000000000..65a408590f82
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_rm.md
@@ -0,0 +1,12 @@
+# docker model context rm
+
+<!---MARKER_GEN_START-->
+Remove one or more Model Runner contexts
+
+### Aliases
+
+`docker model context rm`, `docker model context remove`
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_use.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_use.md
new file mode 100644
index 000000000000..f6544f63fd1d
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_context_use.md
@@ -0,0 +1,9 @@
+# docker model context use
+
+<!---MARKER_GEN_START-->
+Set the active Model Runner context. Pass "default" to revert to
+automatic backend detection.
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_df.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_df.md
new file mode 100644
index 000000000000..e6a4073670b4
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_df.md
@@ -0,0 +1,8 @@
+# docker model df
+
+<!---MARKER_GEN_START-->
+Show Docker Model Runner disk usage
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_gateway.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_gateway.md
new file mode 100644
index 000000000000..630ef5ecc96c
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_gateway.md
@@ -0,0 +1,150 @@
+# docker model gateway
+
+<!---MARKER_GEN_START-->
+Run an OpenAI-compatible LLM gateway that routes requests to configured providers.
+
+Supported providers include Docker Model Runner, Ollama, OpenAI, Anthropic,
+Groq, Mistral, Azure OpenAI, and many more OpenAI-compatible endpoints.
+
+### Options
+
+| Name              | Type     | Default   | Description                         |
+|:------------------|:---------|:----------|:------------------------------------|
+| `-c`, `--config`  | `string` |           | Path to the YAML configuration file |
+| `--host`          | `string` | `0.0.0.0` | Host address to bind to             |
+| `-p`, `--port`    | `uint16` | `4000`    | Port to listen on                   |
+| `-v`, `--verbose` | `bool`   |           | Enable verbose (debug) logging      |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+`docker model gateway` starts a local OpenAI-compatible HTTP gateway that routes
+requests to one or more configured LLM providers. It supports Docker Model Runner
+as a first-class provider, alongside Ollama, OpenAI, Anthropic, Groq, Mistral,
+Azure OpenAI, and many other OpenAI-compatible endpoints.
+
+The gateway is configured through a YAML file that declares the model list,
+provider routing, load-balancing, retries, and fallbacks.
+
+### Configuration file format
+
+```yaml
+model_list:
+  - model_name: <alias exposed to clients>
+    params:
+      model: <provider>/<upstream-model-name>
+      api_base: <optional base URL override>
+      api_key: <optional key or os.environ/VAR_NAME>
+
+general_settings:
+  master_key: <optional API key required by clients>
+  num_retries: <optional integer, default 0>
+  fallbacks:
+    - <primary-alias>: [<fallback-alias>, ...]
+```
+
+The `model` field under `params` uses the format `provider/model-name`.
+Supported provider prefixes include: `docker_model_runner`, `openai`,
+`anthropic`, `ollama`, `groq`, `mistral`, `together_ai`, `deepseek`,
+`fireworks_ai`, `openrouter`, `perplexity`, `xai`, `nvidia_nim`,
+`cerebras`, `sambanova`, `deepinfra`, `azure`, `azure_ai`, `vllm`,
+`lm_studio`, `huggingface`.
+
+API keys can be supplied inline, as `os.environ/VAR_NAME` references, or as
+`${VAR_NAME}` references. The gateway resolves well-known environment variables
+automatically (for example, `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`).
+
+## Examples
+
+### Route requests to Docker Model Runner
+
+```yaml
+model_list:
+  - model_name: smollm2
+    params:
+      model: docker_model_runner/ai/smollm2
+      api_base: http://localhost:12434/engines/llama.cpp/v1
+```
+
+```console
+$ docker model gateway --config config.yaml
+```
+
+The gateway starts on `http://0.0.0.0:4000`. Send requests using any
+OpenAI-compatible client:
+
+```console
+$ curl http://localhost:4000/v1/chat/completions \
+    -H "Content-Type: application/json" \
+    -d '{
+      "model": "smollm2",
+      "messages": [{"role": "user", "content": "Hello"}]
+    }'
+```
+
+### Route requests to multiple providers with fallback
+
+```yaml
+model_list:
+  - model_name: fast
+    params:
+      model: groq/llama-3.1-8b-instant
+      api_key: os.environ/GROQ_API_KEY
+  - model_name: smart
+    params:
+      model: openai/gpt-4o
+      api_key: os.environ/OPENAI_API_KEY
+  - model_name: local
+    params:
+      model: docker_model_runner/ai/smollm2
+      api_base: http://localhost:12434/engines/llama.cpp/v1
+
+general_settings:
+  num_retries: 2
+  fallbacks:
+    - fast: [local]
+    - smart: [fast, local]
+```
+
+```console
+$ docker model gateway --config config.yaml --port 8080
+```
+
+### Secure the gateway with an API key
+
+```yaml
+model_list:
+  - model_name: smollm2
+    params:
+      model: docker_model_runner/ai/smollm2
+      api_base: http://localhost:12434/engines/llama.cpp/v1
+
+general_settings:
+  master_key: os.environ/GATEWAY_API_KEY
+```
+
+```console
+$ GATEWAY_API_KEY=my-secret docker model gateway --config config.yaml
+```
+
+Clients must then pass the key as a Bearer token or via the `x-api-key` header:
+
+```console
+$ curl http://localhost:4000/v1/chat/completions \
+    -H "Content-Type: application/json" \
+    -d '{"model": "smollm2", "messages": [{"role": "user", "content": "Hi"}]}'
+```
+
+### Use a custom host and port
+
+```console
+$ docker model gateway --config config.yaml --host 127.0.0.1 --port 9000
+```
+
+### Enable debug logging
+
+```console
+$ docker model gateway --config config.yaml --verbose
+```
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_inspect.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_inspect.md
new file mode 100644
index 000000000000..7df015093814
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_inspect.md
@@ -0,0 +1,15 @@
+# docker model inspect
+
+<!---MARKER_GEN_START-->
+Display detailed information on one model
+
+### Options
+
+| Name             | Type   | Default | Description                    |
+|:-----------------|:-------|:--------|:-------------------------------|
+| `--openai`       | `bool` |         | List model in an OpenAI format |
+| `-r`, `--remote` | `bool` |         | Show info for remote models    |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_install-runner.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_install-runner.md
new file mode 100644
index 000000000000..de40a5028656
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_install-runner.md
@@ -0,0 +1,27 @@
+# docker model install-runner
+
+<!---MARKER_GEN_START-->
+Install Docker Model Runner (Docker Engine only)
+
+### Options
+
+| Name             | Type     | Default     | Description                                                                                            |
+|:-----------------|:---------|:------------|:-------------------------------------------------------------------------------------------------------|
+| `--backend`      | `string` |             | Specify backend (llama.cpp\|vllm\|diffusers). Default: llama.cpp                                       |
+| `--debug`        | `bool`   |             | Enable debug logging                                                                                   |
+| `--do-not-track` | `bool`   |             | Do not track models usage in Docker Model Runner                                                       |
+| `--gpu`          | `string` | `auto`      | Specify GPU support (none\|auto\|cuda\|rocm\|musa\|cann)                                               |
+| `--host`         | `string` | `127.0.0.1` | Host address to bind Docker Model Runner                                                               |
+| `--port`         | `uint16` | `0`         | Docker container port for Docker Model Runner (default: 12434 for Docker Engine, 12435 for Cloud mode) |
+| `--proxy-cert`   | `string` |             | Path to a CA certificate file for proxy SSL inspection                                                 |
+| `--tls`          | `bool`   |             | Enable TLS/HTTPS for Docker Model Runner API                                                           |
+| `--tls-cert`     | `string` |             | Path to TLS certificate file (auto-generated if not provided)                                          |
+| `--tls-key`      | `string` |             | Path to TLS private key file (auto-generated if not provided)                                          |
+| `--tls-port`     | `uint16` | `0`         | TLS port for Docker Model Runner (default: 12444 for Docker Engine, 12445 for Cloud mode)              |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+ This command runs implicitly when a docker model command is executed. You can run this command explicitly to add a new configuration.
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_launch.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_launch.md
new file mode 100644
index 000000000000..161e2a3a3062
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_launch.md
@@ -0,0 +1,30 @@
+# docker model launch
+
+<!---MARKER_GEN_START-->
+Launch an app configured to use Docker Model Runner.
+
+Without arguments, lists all supported apps.
+
+Supported apps: anythingllm, claude, codex, openclaw, opencode, openwebui
+
+Examples:
+  docker model launch
+  docker model launch opencode
+  docker model launch claude -- --help
+  docker model launch openwebui --port 3000
+  docker model launch claude --config
+
+### Options
+
+| Name        | Type     | Default | Description                                     |
+|:------------|:---------|:--------|:------------------------------------------------|
+| `--config`  | `bool`   |         | Print configuration without launching           |
+| `--detach`  | `bool`   |         | Run containerized app in background             |
+| `--dry-run` | `bool`   |         | Print what would be executed without running it |
+| `--image`   | `string` |         | Override container image for containerized apps |
+| `--model`   | `string` |         | Model to use (for opencode)                     |
+| `--port`    | `int`    | `0`     | Host port to expose (web UIs)                   |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_list.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_list.md
new file mode 100644
index 000000000000..24d260a5d86a
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_list.md
@@ -0,0 +1,21 @@
+# docker model list
+
+<!---MARKER_GEN_START-->
+List the models pulled to your local environment
+
+### Aliases
+
+`docker model list`, `docker model ls`
+
+### Options
+
+| Name            | Type     | Default | Description                                            |
+|:----------------|:---------|:--------|:-------------------------------------------------------|
+| `--json`        | `bool`   |         | List models in a JSON format                           |
+| `--openai`      | `bool`   |         | List models in an OpenAI format                        |
+| `--openaiurl`   | `string` |         | OpenAI-compatible API endpoint URL to list models from |
+| `-q`, `--quiet` | `bool`   |         | Only show model IDs                                    |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_logs.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_logs.md
new file mode 100644
index 000000000000..8c5810924a18
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_logs.md
@@ -0,0 +1,15 @@
+# docker model logs
+
+<!---MARKER_GEN_START-->
+Fetch the Docker Model Runner logs
+
+### Options
+
+| Name             | Type   | Default | Description                                   |
+|:-----------------|:-------|:--------|:----------------------------------------------|
+| `-f`, `--follow` | `bool` |         | View logs with real-time streaming            |
+| `--no-engines`   | `bool` |         | Exclude inference engine logs from the output |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_package.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_package.md
new file mode 100644
index 000000000000..571b77c1fa36
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_package.md
@@ -0,0 +1,60 @@
+# docker model package
+
+<!---MARKER_GEN_START-->
+Package a model into a Docker Model OCI artifact.
+
+The model source must be one of:
+  --gguf               A GGUF file (single file or first shard of a sharded model)
+  --safetensors-dir    A directory containing .safetensors and configuration files
+  --dduf               A .dduf (Diffusers Unified Format) archive
+  --from               An existing packaged model reference
+
+By default, the packaged artifact is loaded into the local Model Runner content store.
+Use --push to publish the model to a registry instead.
+
+MODEL specifies the target model reference (for example: myorg/llama3:8b).
+When using --push, MODEL must be a registry-qualified reference.
+
+Packaging behavior:
+
+  GGUF
+    --gguf must point to a .gguf file.
+    For sharded models, point to the first shard. All shards must:
+      • reside in the same directory
+      • follow an indexed naming convention (e.g. model-00001-of-00015.gguf)
+    All shards are automatically discovered and packaged together.
+
+  Safetensors
+    --safetensors-dir must point to a directory containing .safetensors files
+    and required configuration files (e.g. model config, tokenizer files).
+    All files under the directory (including nested subdirectories) are
+    automatically discovered. Each file is packaged as a separate OCI layer.
+
+  DDUF
+    --dduf must point to a .dduf archive file.
+
+  Repackaging
+    --from repackages an existing model. You may override selected properties
+    such as --context-size to create a variant of the original model.
+
+  Multimodal models
+    Use --mmproj to include a multimodal projector file.
+
+### Options
+
+| Name                | Type          | Default  | Description                                                                            |
+|:--------------------|:--------------|:---------|:---------------------------------------------------------------------------------------|
+| `--chat-template`   | `string`      |          | absolute path to chat template file (must be Jinja format)                             |
+| `--context-size`    | `uint64`      | `0`      | context size in tokens                                                                 |
+| `--dduf`            | `string`      |          | absolute path to DDUF archive file (Diffusers Unified Format)                          |
+| `--format`          | `string`      | `docker` | output artifact format: "docker" (default) or "cncf" (CNCF ModelPack spec)             |
+| `--from`            | `string`      |          | reference to an existing model to repackage                                            |
+| `--gguf`            | `string`      |          | absolute path to gguf file                                                             |
+| `-l`, `--license`   | `stringArray` |          | absolute path to a license file                                                        |
+| `--mmproj`          | `string`      |          | absolute path to multimodal projector file                                             |
+| `--push`            | `bool`        |          | push to registry (if not set, the model is loaded into the Model Runner content store) |
+| `--safetensors-dir` | `string`      |          | absolute path to directory containing safetensors files and config                     |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_ps.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_ps.md
new file mode 100644
index 000000000000..15f5371553f6
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_ps.md
@@ -0,0 +1,8 @@
+# docker model ps
+
+<!---MARKER_GEN_START-->
+List running models
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_pull.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_pull.md
new file mode 100644
index 000000000000..246cc59d78af
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_pull.md
@@ -0,0 +1,32 @@
+# docker model pull
+
+<!---MARKER_GEN_START-->
+Pull a model from Docker Hub or HuggingFace to your local environment
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+Pull a model to your local environment. Downloaded models also appear in the Docker Desktop Dashboard.
+
+## Examples
+
+### Pulling a model from Docker Hub
+
+```console
+docker model pull ai/smollm2
+```
+
+### Pulling from HuggingFace
+
+You can pull GGUF models directly from [Hugging Face](https://huggingface.co/models?library=gguf).
+
+**Note about quantization:** If no tag is specified, the command tries to pull the `Q4_K_M` version of the model.
+If `Q4_K_M` doesn't exist, the command pulls the first GGUF found in the **Files** view of the model on HuggingFace.
+To specify the quantization, provide it as a tag, for example:
+`docker model pull hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF:Q4_K_S`
+
+```console
+docker model pull hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF
+```
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_purge.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_purge.md
new file mode 100644
index 000000000000..4fcc85c349dd
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_purge.md
@@ -0,0 +1,14 @@
+# docker model purge
+
+<!---MARKER_GEN_START-->
+Remove all models
+
+### Options
+
+| Name            | Type   | Default | Description                  |
+|:----------------|:-------|:--------|:-----------------------------|
+| `-f`, `--force` | `bool` |         | Forcefully remove all models |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_push.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_push.md
new file mode 100644
index 000000000000..7b040fe0bf82
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_push.md
@@ -0,0 +1,13 @@
+# docker model push
+
+<!---MARKER_GEN_START-->
+Push a model to Docker Hub or Hugging Face
+
+
+<!---MARKER_GEN_END-->
+
+### Example
+
+```console
+docker model push <namespace>/<model>
+```
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_reinstall-runner.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_reinstall-runner.md
new file mode 100644
index 000000000000..457b322e5789
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_reinstall-runner.md
@@ -0,0 +1,27 @@
+# docker model reinstall-runner
+
+<!---MARKER_GEN_START-->
+Reinstall Docker Model Runner (Docker Engine only)
+
+### Options
+
+| Name             | Type     | Default     | Description                                                                                            |
+|:-----------------|:---------|:------------|:-------------------------------------------------------------------------------------------------------|
+| `--backend`      | `string` |             | Specify backend (llama.cpp\|vllm\|diffusers). Default: llama.cpp                                       |
+| `--debug`        | `bool`   |             | Enable debug logging                                                                                   |
+| `--do-not-track` | `bool`   |             | Do not track models usage in Docker Model Runner                                                       |
+| `--gpu`          | `string` | `auto`      | Specify GPU support (none\|auto\|cuda\|rocm\|musa\|cann)                                               |
+| `--host`         | `string` | `127.0.0.1` | Host address to bind Docker Model Runner                                                               |
+| `--port`         | `uint16` | `0`         | Docker container port for Docker Model Runner (default: 12434 for Docker Engine, 12435 for Cloud mode) |
+| `--proxy-cert`   | `string` |             | Path to a CA certificate file for proxy SSL inspection                                                 |
+| `--tls`          | `bool`   |             | Enable TLS/HTTPS for Docker Model Runner API                                                           |
+| `--tls-cert`     | `string` |             | Path to TLS certificate file (auto-generated if not provided)                                          |
+| `--tls-key`      | `string` |             | Path to TLS private key file (auto-generated if not provided)                                          |
+| `--tls-port`     | `uint16` | `0`         | TLS port for Docker Model Runner (default: 12444 for Docker Engine, 12445 for Cloud mode)              |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+This command removes the existing Docker Model Runner container and reinstalls it with the specified configuration. Models and images are preserved during reinstallation.
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_requests.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_requests.md
new file mode 100644
index 000000000000..970dc3c3d6ed
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_requests.md
@@ -0,0 +1,16 @@
+# docker model requests
+
+<!---MARKER_GEN_START-->
+Fetch requests+responses from Docker Model Runner
+
+### Options
+
+| Name                 | Type     | Default | Description                                                                      |
+|:---------------------|:---------|:--------|:---------------------------------------------------------------------------------|
+| `-f`, `--follow`     | `bool`   |         | Follow requests stream                                                           |
+| `--include-existing` | `bool`   |         | Include existing requests when starting to follow (only available with --follow) |
+| `--model`            | `string` |         | Specify the model to filter requests                                             |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_restart-runner.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_restart-runner.md
new file mode 100644
index 000000000000..80565a8dfa1a
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_restart-runner.md
@@ -0,0 +1,24 @@
+# docker model restart-runner
+
+<!---MARKER_GEN_START-->
+Restart Docker Model Runner (Docker Engine only)
+
+### Options
+
+| Name             | Type     | Default     | Description                                                                                            |
+|:-----------------|:---------|:------------|:-------------------------------------------------------------------------------------------------------|
+| `--debug`        | `bool`   |             | Enable debug logging                                                                                   |
+| `--do-not-track` | `bool`   |             | Do not track models usage in Docker Model Runner                                                       |
+| `--gpu`          | `string` | `auto`      | Specify GPU support (none\|auto\|cuda\|rocm\|musa\|cann)                                               |
+| `--host`         | `string` | `127.0.0.1` | Host address to bind Docker Model Runner                                                               |
+| `--port`         | `uint16` | `0`         | Docker container port for Docker Model Runner (default: 12434 for Docker Engine, 12435 for Cloud mode) |
+| `--proxy-cert`   | `string` |             | Path to a CA certificate file for proxy SSL inspection                                                 |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+This command restarts the Docker Model Runner without pulling container images. Use this command to restart the runner when you already have the required images locally.
+
+For the first-time setup or to ensure you have the latest images, use `docker model install-runner` instead.
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_rm.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_rm.md
new file mode 100644
index 000000000000..6463903bd899
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_rm.md
@@ -0,0 +1,14 @@
+# docker model rm
+
+<!---MARKER_GEN_START-->
+Remove local models downloaded from Docker Hub
+
+### Options
+
+| Name            | Type   | Default | Description                 |
+|:----------------|:-------|:--------|:----------------------------|
+| `-f`, `--force` | `bool` |         | Forcefully remove the model |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_run.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_run.md
new file mode 100644
index 000000000000..b6190d26a032
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_run.md
@@ -0,0 +1,61 @@
+# docker model run
+
+<!---MARKER_GEN_START-->
+Run a model and interact with it using a submitted prompt or chat mode
+
+### Options
+
+| Name             | Type     | Default | Description                                          |
+|:-----------------|:---------|:--------|:-----------------------------------------------------|
+| `--color`        | `string` | `no`    | Use colored output (auto\|yes\|no)                   |
+| `--debug`        | `bool`   |         | Enable debug logging                                 |
+| `-d`, `--detach` | `bool`   |         | Load the model in the background without interaction |
+| `--openaiurl`    | `string` |         | OpenAI-compatible API endpoint URL to chat with      |
+| `--websearch`    | `bool`   |         | Enable web search tool during chat                   |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+When you run a model, Docker calls an inference server API endpoint hosted by the Model Runner through Docker Desktop. The model stays in memory until another model is requested, or until a pre-defined inactivity timeout is reached (currently 5 minutes).
+
+You do not have to use Docker model run before interacting with a specific model from a host process or from within a container. Model Runner transparently loads the requested model on-demand, assuming it has been pulled and is locally available.
+
+You can also use chat mode in the Docker Desktop Dashboard when you select the model in the **Models** tab.
+
+## Examples
+
+### One-time prompt
+
+```console
+docker model run ai/smollm2 "Hi"
+```
+
+Output:
+
+```console
+Hello! How can I assist you today?
+```
+
+### Interactive chat
+
+```console
+docker model run ai/smollm2
+```
+
+Output:
+
+```console
+> Hi
+Hi there! It's SmolLM, AI assistant. How can I help you today?
+> /bye
+```
+
+### Pre-load a model
+
+```console
+docker model run --detach ai/smollm2
+```
+
+This loads the model into memory without interaction, ensuring maximum performance for subsequent requests.
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_search.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_search.md
new file mode 100644
index 000000000000..b146e60c6d18
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_search.md
@@ -0,0 +1,27 @@
+# docker model search
+
+<!---MARKER_GEN_START-->
+Search for models from Docker Hub (ai/ namespace) and HuggingFace.
+
+When no search term is provided, lists all available models.
+When a search term is provided, filters models by name/description.
+
+Examples:
+  docker model search                       # List available models from Docker Hub
+  docker model search llama                 # Search for models containing "llama"
+  docker model search --source=all          # Search both Docker Hub and HuggingFace
+  docker model search --source=huggingface  # Only search HuggingFace
+  docker model search --limit=50 phi        # Search with custom limit
+  docker model search --json llama          # Output as JSON
+
+### Options
+
+| Name            | Type     | Default | Description                                   |
+|:----------------|:---------|:--------|:----------------------------------------------|
+| `--json`        | `bool`   |         | Output results as JSON                        |
+| `-n`, `--limit` | `int`    | `32`    | Maximum number of results to show             |
+| `--source`      | `string` | `all`   | Source to search: all, dockerhub, huggingface |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_show.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_show.md
new file mode 100644
index 000000000000..d8c37da522a8
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_show.md
@@ -0,0 +1,14 @@
+# docker model show
+
+<!---MARKER_GEN_START-->
+Display detailed information about a model in a human-readable format.
+
+### Options
+
+| Name             | Type   | Default | Description                 |
+|:-----------------|:-------|:--------|:----------------------------|
+| `-r`, `--remote` | `bool` |         | Show info for remote models |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_skills.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_skills.md
new file mode 100644
index 000000000000..39ecc0ed7212
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_skills.md
@@ -0,0 +1,32 @@
+# docker model skills
+
+<!---MARKER_GEN_START-->
+Install Docker Model Runner skills for AI coding assistants.
+
+Skills are configuration files that help AI coding assistants understand
+how to use Docker Model Runner effectively for local model inference.
+
+Supported targets:
+  --codex     Install to ~/.codex/skills (OpenAI Codex CLI)
+  --claude    Install to ~/.claude/skills (Claude Code)
+  --opencode  Install to ~/.config/opencode/skills (OpenCode)
+  --dest      Install to a custom directory
+
+Example:
+  docker model skills --claude
+  docker model skills --codex --claude
+  docker model skills --dest /path/to/skills
+
+### Options
+
+| Name            | Type     | Default | Description                                             |
+|:----------------|:---------|:--------|:--------------------------------------------------------|
+| `--claude`      | `bool`   |         | Install skills for Claude Code (~/.claude/skills)       |
+| `--codex`       | `bool`   |         | Install skills for OpenAI Codex CLI (~/.codex/skills)   |
+| `--dest`        | `string` |         | Install skills to a custom directory                    |
+| `-f`, `--force` | `bool`   |         | Overwrite existing skills without prompting             |
+| `--opencode`    | `bool`   |         | Install skills for OpenCode (~/.config/opencode/skills) |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_start-runner.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_start-runner.md
new file mode 100644
index 000000000000..24cf2fe12f33
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_start-runner.md
@@ -0,0 +1,29 @@
+# docker model start-runner
+
+<!---MARKER_GEN_START-->
+Start Docker Model Runner (Docker Engine only)
+
+### Options
+
+| Name             | Type     | Default     | Description                                                                                            |
+|:-----------------|:---------|:------------|:-------------------------------------------------------------------------------------------------------|
+| `--backend`      | `string` |             | Specify backend (llama.cpp\|vllm\|diffusers). Default: llama.cpp                                       |
+| `--debug`        | `bool`   |             | Enable debug logging                                                                                   |
+| `--do-not-track` | `bool`   |             | Do not track models usage in Docker Model Runner                                                       |
+| `--gpu`          | `string` | `auto`      | Specify GPU support (none\|auto\|cuda\|rocm\|musa\|cann)                                               |
+| `--host`         | `string` | `127.0.0.1` | Host address to bind Docker Model Runner                                                               |
+| `--port`         | `uint16` | `0`         | Docker container port for Docker Model Runner (default: 12434 for Docker Engine, 12435 for Cloud mode) |
+| `--proxy-cert`   | `string` |             | Path to a CA certificate file for proxy SSL inspection                                                 |
+| `--tls`          | `bool`   |             | Enable TLS/HTTPS for Docker Model Runner API                                                           |
+| `--tls-cert`     | `string` |             | Path to TLS certificate file (auto-generated if not provided)                                          |
+| `--tls-key`      | `string` |             | Path to TLS private key file (auto-generated if not provided)                                          |
+| `--tls-port`     | `uint16` | `0`         | TLS port for Docker Model Runner (default: 12444 for Docker Engine, 12445 for Cloud mode)              |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+This command starts the Docker Model Runner without pulling container images. Use this command to start the runner when you already have the required images locally.
+
+For the first-time setup or to ensure you have the latest images, use `docker model install-runner` instead.
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_status.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_status.md
new file mode 100644
index 000000000000..baa630073db8
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_status.md
@@ -0,0 +1,17 @@
+# docker model status
+
+<!---MARKER_GEN_START-->
+Check if the Docker Model Runner is running
+
+### Options
+
+| Name     | Type   | Default | Description           |
+|:---------|:-------|:--------|:----------------------|
+| `--json` | `bool` |         | Format output in JSON |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+Check whether the Docker Model Runner is running and displays the current inference engine.
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_stop-runner.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_stop-runner.md
new file mode 100644
index 000000000000..99a6b0cda601
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_stop-runner.md
@@ -0,0 +1,19 @@
+# docker model stop-runner
+
+<!---MARKER_GEN_START-->
+Stop Docker Model Runner (Docker Engine only)
+
+### Options
+
+| Name       | Type   | Default | Description                 |
+|:-----------|:-------|:--------|:----------------------------|
+| `--models` | `bool` |         | Remove model storage volume |
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+This command stops the Docker Model Runner by removing the running containers, but preserves the container images on disk. Use this command when you want to temporarily stop the runner but plan to start it again later.
+
+To completely remove the runner including images, use `docker model uninstall-runner --images` instead.
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_tag.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_tag.md
new file mode 100644
index 000000000000..3f1615e296fc
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_tag.md
@@ -0,0 +1,11 @@
+# docker model tag
+
+<!---MARKER_GEN_START-->
+Tag a model
+
+
+<!---MARKER_GEN_END-->
+
+## Description
+
+Specify a particular version or variant of the model. If no tag is provided, Docker defaults to `latest`.
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_uninstall-runner.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_uninstall-runner.md
new file mode 100644
index 000000000000..8beb8744fd48
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_uninstall-runner.md
@@ -0,0 +1,16 @@
+# docker model uninstall-runner
+
+<!---MARKER_GEN_START-->
+Uninstall Docker Model Runner (Docker Engine only)
+
+### Options
+
+| Name        | Type     | Default | Description                                         |
+|:------------|:---------|:--------|:----------------------------------------------------|
+| `--backend` | `string` |         | Uninstall a deferred backend (e.g. vllm, diffusers) |
+| `--images`  | `bool`   |         | Remove docker/model-runner images                   |
+| `--models`  | `bool`   |         | Remove model storage volume                         |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_unload.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_unload.md
new file mode 100644
index 000000000000..17060c649651
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_unload.md
@@ -0,0 +1,19 @@
+# docker model unload
+
+<!---MARKER_GEN_START-->
+Unload running models
+
+### Aliases
+
+`docker model unload`, `docker model stop`
+
+### Options
+
+| Name        | Type     | Default | Description                |
+|:------------|:---------|:--------|:---------------------------|
+| `--all`     | `bool`   |         | Unload all running models  |
+| `--backend` | `string` |         | Optional backend to target |
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_version.md b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_version.md
new file mode 100644
index 000000000000..eb32c61fd979
--- /dev/null
+++ b/_vendor/github.com/docker/model-runner/cmd/cli/docs/reference/model_version.md
@@ -0,0 +1,8 @@
+# docker model version
+
+<!---MARKER_GEN_START-->
+Show the Docker Model Runner version
+
+
+<!---MARKER_GEN_END-->
+
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_attestation_add.yaml b/_vendor/github.com/docker/scout-cli/docs/docker_scout_attestation_add.yaml
deleted file mode 100644
index f6850825358b..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_attestation_add.yaml
+++ /dev/null
@@ -1,54 +0,0 @@
-command: docker scout attestation add
-aliases: docker scout attestation add, docker scout attest add
-short: Add attestation to image
-long: The docker scout attestation add command adds attestations to images.
-usage: docker scout attestation add OPTIONS IMAGE [IMAGE...]
-pname: docker scout attestation
-plink: docker_scout_attestation.yaml
-options:
-    - option: file
-      value_type: stringSlice
-      default_value: '[]'
-      description: File location of attestations to attach
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: predicate-type
-      value_type: string
-      description: Predicate-type for attestations
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: debug
-      value_type: bool
-      default_value: "false"
-      description: Debug messages
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: verbose-debug
-      value_type: bool
-      default_value: "false"
-      description: Verbose debug
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-experimental: false
-experimentalcli: true
-kubernetes: false
-swarm: false
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_docker-cli-plugin-hooks.yaml b/_vendor/github.com/docker/scout-cli/docs/docker_scout_docker-cli-plugin-hooks.yaml
deleted file mode 100644
index a36ba75bb9b2..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_docker-cli-plugin-hooks.yaml
+++ /dev/null
@@ -1,33 +0,0 @@
-command: docker scout docker-cli-plugin-hooks
-short: runs the plugins hooks
-long: runs the plugins hooks
-usage: docker scout docker-cli-plugin-hooks
-pname: docker scout
-plink: docker_scout.yaml
-inherited_options:
-    - option: debug
-      value_type: bool
-      default_value: "false"
-      description: Debug messages
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: verbose-debug
-      value_type: bool
-      default_value: "false"
-      description: Verbose debug
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_policy.yaml b/_vendor/github.com/docker/scout-cli/docs/docker_scout_policy.yaml
deleted file mode 100644
index 077907ee2b08..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_policy.yaml
+++ /dev/null
@@ -1,140 +0,0 @@
-command: docker scout policy
-short: |
-    Evaluate policies against an image and display the policy evaluation results (experimental)
-long: |-
-    The `docker scout policy` command evaluates policies against an image.
-    The image analysis is uploaded to Docker Scout where policies get evaluated.
-
-    The policy evaluation results may take a few minutes to become available.
-usage: docker scout policy [IMAGE | REPO]
-pname: docker scout
-plink: docker_scout.yaml
-options:
-    - option: env
-      value_type: string
-      description: Name of the environment to compare to
-      deprecated: true
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: exit-code
-      shorthand: e
-      value_type: bool
-      default_value: "false"
-      description: Return exit code '2' if policies are not met, '0' otherwise
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: only-policy
-      value_type: stringSlice
-      default_value: '[]'
-      description: Comma separated list of policies to evaluate
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: org
-      value_type: string
-      description: Namespace of the Docker organization
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: output
-      shorthand: o
-      value_type: string
-      description: Write the report to a file
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: platform
-      value_type: string
-      description: Platform of image to pull policy results from
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: to-env
-      value_type: string
-      description: Name of the environment to compare to
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: to-latest
-      value_type: bool
-      default_value: "false"
-      description: Latest image processed to compare to
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: debug
-      value_type: bool
-      default_value: "false"
-      description: Debug messages
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: verbose-debug
-      value_type: bool
-      default_value: "false"
-      description: Verbose debug
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-examples: |-
-    ### Evaluate policies against an image and display the results
-
-    ```console
-    $ docker scout policy dockerscoutpolicy/customers-api-service:0.0.1
-    ```
-
-    ### Evaluate policies against an image for a specific organization
-
-    ```console
-    $ docker scout policy dockerscoutpolicy/customers-api-service:0.0.1 --org dockerscoutpolicy
-    ```
-
-    ### Evaluate policies against an image with a specific platform
-
-    ```console
-    $ docker scout policy dockerscoutpolicy/customers-api-service:0.0.1 --platform linux/amd64
-    ```
-
-    ### Compare policy results for a repository in a specific environment
-
-    ```console
-    $ docker scout policy dockerscoutpolicy/customers-api-service --to-env production
-    ```
-deprecated: false
-experimental: false
-experimentalcli: true
-kubernetes: false
-swarm: false
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_watch.yaml b/_vendor/github.com/docker/scout-cli/docs/docker_scout_watch.yaml
deleted file mode 100644
index 30b6dbef4718..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_watch.yaml
+++ /dev/null
@@ -1,161 +0,0 @@
-command: docker scout watch
-short: |
-    Watch repositories in a registry and push images and indexes to Docker Scout (experimental)
-long: |-
-    The `docker scout watch` command watches repositories in a registry
-    and pushes images or analysis results to Docker Scout.
-usage: docker scout watch
-pname: docker scout
-plink: docker_scout.yaml
-options:
-    - option: all-images
-      value_type: bool
-      default_value: "false"
-      description: |
-        Push all images instead of only the ones pushed during the watch command is running
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: dry-run
-      value_type: bool
-      default_value: "false"
-      description: Watch images and prepare them, but do not push them
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: interval
-      value_type: int64
-      default_value: "60"
-      description: Interval in seconds between checks
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: org
-      value_type: string
-      description: Namespace of the Docker organization to which image will be pushed
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: refresh-registry
-      value_type: bool
-      default_value: "false"
-      description: |
-        Refresh the list of repositories of a registry at every run. Only with --registry.
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: registry
-      value_type: string
-      description: Registry to watch
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: repository
-      value_type: stringSlice
-      default_value: '[]'
-      description: Repository to watch
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: sbom
-      value_type: bool
-      default_value: "true"
-      description: Create and upload SBOMs
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: tag
-      value_type: stringSlice
-      default_value: '[]'
-      description: Regular expression to match tags to watch
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: workers
-      value_type: int
-      default_value: "3"
-      description: Number of concurrent workers
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: debug
-      value_type: bool
-      default_value: "false"
-      description: Debug messages
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: verbose-debug
-      value_type: bool
-      default_value: "false"
-      description: Verbose debug
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-examples: |-
-    ### Watch for new images from two repositories and push them
-
-    ```console
-    $ docker scout watch --org my-org --repository registry-1.example.com/repo-1 --repository registry-2.example.com/repo-2
-    ```
-
-    ### Only push images with a specific tag
-
-    ```console
-    $ docker scout watch --org my-org --repository registry.example.com/my-service --tag latest
-    ```
-
-    ### Watch all repositories of a registry
-
-    ```console
-    $ docker scout watch --org my-org --registry registry.example.com
-    ```
-
-    ### Push all images and not just the new ones
-
-    ```console
-    $ docker scout watch--org my-org --repository registry.example.com/my-service --all-images
-    ```
-deprecated: false
-experimental: false
-experimentalcli: true
-kubernetes: false
-swarm: false
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout.md b/_vendor/github.com/docker/scout-cli/docs/scout.md
deleted file mode 100644
index aeac72b4c6d1..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# docker scout
-
-```
-docker scout COMMAND
-```
-
-<!---MARKER_GEN_START-->
-Command line tool for Docker Scout
-
-### Subcommands
-
-| Name                                                          | Description                                                                                 |
-|:--------------------------------------------------------------|:--------------------------------------------------------------------------------------------|
-| [`attestation`](scout_attestation.md)                         | Manage attestations on image indexes                                                        |
-| [`cache`](scout_cache.md)                                     | Manage Docker Scout cache and temporary files                                               |
-| [`compare`](scout_compare.md)                                 | Compare two images and display differences (experimental)                                   |
-| [`config`](scout_config.md)                                   | Manage Docker Scout configuration                                                           |
-| [`cves`](scout_cves.md)                                       | Display CVEs identified in a software artifact                                              |
-| [`docker-cli-plugin-hooks`](scout_docker-cli-plugin-hooks.md) | runs the plugins hooks                                                                      |
-| [`enroll`](scout_enroll.md)                                   | Enroll an organization with Docker Scout                                                    |
-| [`environment`](scout_environment.md)                         | Manage environments (experimental)                                                          |
-| [`help`](scout_help.md)                                       | Display information about the available commands                                            |
-| [`integration`](scout_integration.md)                         | Commands to list, configure, and delete Docker Scout integrations                           |
-| [`policy`](scout_policy.md)                                   | Evaluate policies against an image and display the policy evaluation results (experimental) |
-| [`push`](scout_push.md)                                       | Push an image or image index to Docker Scout                                                |
-| [`quickview`](scout_quickview.md)                             | Quick overview of an image                                                                  |
-| [`recommendations`](scout_recommendations.md)                 | Display available base image updates and remediation recommendations                        |
-| [`repo`](scout_repo.md)                                       | Commands to list, enable, and disable Docker Scout on repositories                          |
-| [`sbom`](scout_sbom.md)                                       | Generate or display SBOM of an image                                                        |
-| [`stream`](scout_stream.md)                                   | Manage streams (experimental)                                                               |
-| [`version`](scout_version.md)                                 | Show Docker Scout version information                                                       |
-| [`watch`](scout_watch.md)                                     | Watch repositories in a registry and push images and indexes to Docker Scout (experimental) |
-
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_attestation.md b/_vendor/github.com/docker/scout-cli/docs/scout_attestation.md
deleted file mode 100644
index d4f6bc58277e..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_attestation.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# docker scout attestation
-
-<!---MARKER_GEN_START-->
-Manage attestations on image indexes
-
-### Aliases
-
-`docker scout attestation`, `docker scout attest`
-
-### Subcommands
-
-| Name                              | Description              |
-|:----------------------------------|:-------------------------|
-| [`add`](scout_attestation_add.md) | Add attestation to image |
-
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_attestation_add.md b/_vendor/github.com/docker/scout-cli/docs/scout_attestation_add.md
deleted file mode 100644
index 5f09c0fffda7..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_attestation_add.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# docker scout attestation add
-
-<!---MARKER_GEN_START-->
-Add attestation to image
-
-### Aliases
-
-`docker scout attestation add`, `docker scout attest add`
-
-### Options
-
-| Name               | Type          | Default | Description                             |
-|:-------------------|:--------------|:--------|:----------------------------------------|
-| `--file`           | `stringSlice` |         | File location of attestations to attach |
-| `--predicate-type` | `string`      |         | Predicate-type for attestations         |
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_cache.md b/_vendor/github.com/docker/scout-cli/docs/scout_cache.md
deleted file mode 100644
index 9bb212dd3db1..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_cache.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# docker scout cache
-
-<!---MARKER_GEN_START-->
-Manage Docker Scout cache and temporary files
-
-### Subcommands
-
-| Name                            | Description                     |
-|:--------------------------------|:--------------------------------|
-| [`df`](scout_cache_df.md)       | Show Docker Scout disk usage    |
-| [`prune`](scout_cache_prune.md) | Remove temporary or cached data |
-
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_cache_df.md b/_vendor/github.com/docker/scout-cli/docs/scout_cache_df.md
deleted file mode 100644
index 71dcf99560bf..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_cache_df.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# docker scout cache df
-
-<!---MARKER_GEN_START-->
-Show Docker Scout disk usage
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-Docker Scout uses a temporary cache storage for generating image SBOMs.
-The cache helps avoid regenerating or fetching resources unnecessarily.
-
-This `docker scout cache df` command shows the cached data on the host.
-Each cache entry is identified by the digest of the image.
-
-You can use the `docker scout cache prune` command to delete cache data at any time.
-
-## Examples
-
-### List temporary and cache files
-
-```console
-$ docker scout cache df
-Docker Scout temporary directory to generate SBOMs is located at:
-   /var/folders/dw/d6h9w2sx6rv3lzwwgrnx7t5h0000gp/T/docker-scout
-   this path can be configured using the DOCKER_SCOUT_CACHE_DIR environment variable
-
-                               Image Digest                               │ Size
-──────────────────────────────────────────────────────────────────────────┼────────
-  sha256:c41ab5c992deb4fe7e5da09f67a8804a46bd0592bfdf0b1847dde0e0889d2bff │ 21 kB
-
-Total: 21 kB
-
-
-Docker Scout cached SBOMs are located at:
-   /Users/user/.docker/scout/sbom
-
-                               Image Digest                               │ Size of SBOM
-──────────────────────────────────────────────────────────────────────────┼───────────────
-  sha256:02bb6f428431fbc2809c5d1b41eab5a68350194fb508869a33cb1af4444c9b11 │ 42 kB
-  sha256:03fc002fe4f370463a8f04d3a288cdffa861e462fc8b5be44ab62b296ad95183 │ 100 kB
-  sha256:088134dd33e4a2997480a1488a41c11abebda465da5cf7f305a0ecf8ed494329 │ 194 kB
-  sha256:0b80b2f17aff7ee5bfb135c69d0d6fe34070e89042b7aac73d1abcc79cfe6759 │ 852 kB
-  sha256:0c9e8abe31a5f17d84d5c85d3853d2f948a4f126421e89e68753591f1b6fedc5 │ 930 kB
-  sha256:0d49cae0723c8d310e413736b5e91e0c59b605ade2546f6e6ef8f1f3ddc76066 │ 510 kB
-  sha256:0ef04748d071c2e631bb3edce8f805cb5512e746b682c83fdae6d8c0b243280b │ 1.0 MB
-  sha256:13fd22925b638bb7d2131914bb8f8b0f5f582bee364aec682d9e7fe722bb486a │ 42 kB
-  sha256:174c41d4fbc7f63e1f2bb7d2f7837318050406f2f27e5073a84a84f18b48b883 │ 115 kB
-
-Total: 4 MB
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_cache_prune.md b/_vendor/github.com/docker/scout-cli/docs/scout_cache_prune.md
deleted file mode 100644
index 7292884c7dca..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_cache_prune.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# docker scout cache prune
-
-<!---MARKER_GEN_START-->
-Remove temporary or cached data
-
-### Options
-
-| Name            | Type | Default | Description                    |
-|:----------------|:-----|:--------|:-------------------------------|
-| `-f`, `--force` |      |         | Do not prompt for confirmation |
-| `--sboms`       |      |         | Prune cached SBOMs             |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout cache prune` command removes temporary data and SBOM cache.
-
-By default, `docker scout cache prune` only deletes temporary data.
-To delete temporary data and clear the SBOM cache, use the `--sboms` flag.
-
-## Examples
-
-### Delete temporary data
-
-```console
-$ docker scout cache prune
-? Are you sure to delete all temporary data? Yes
-    ✓ temporary data deleted
-```
-
-### Delete temporary _and_ cache data
-
-```console
-$ docker scout cache prune --sboms
-? Are you sure to delete all temporary data and all cached SBOMs? Yes
-    ✓ temporary data deleted
-    ✓ cached SBOMs deleted
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_compare.md b/_vendor/github.com/docker/scout-cli/docs/scout_compare.md
deleted file mode 100644
index f25aa8635501..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_compare.md
+++ /dev/null
@@ -1,110 +0,0 @@
-# docker scout compare
-
-<!---MARKER_GEN_START-->
-Compare two images and display differences (experimental)
-
-### Aliases
-
-`docker scout compare`, `docker scout diff`
-
-### Options
-
-| Name                  | Type          | Default | Description                                                                                                                                                                    |
-|:----------------------|:--------------|:--------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `-x`, `--exit-on`     | `stringSlice` |         |  Comma separated list of conditions to fail the action step if worse, options are: vulnerability, policy                                                                       |
-| `--format`            | `string`      | `text`  | Output format of the generated vulnerability report:<br>- text: default output, plain text with or without colors depending on the terminal<br>- markdown: Markdown output<br> |
-| `--hide-policies`     |               |         | Hide policy status from the output                                                                                                                                             |
-| `--ignore-base`       |               |         | Filter out CVEs introduced from base image                                                                                                                                     |
-| `--ignore-unchanged`  |               |         | Filter out unchanged packages                                                                                                                                                  |
-| `--multi-stage`       |               |         | Show packages from multi-stage Docker builds                                                                                                                                   |
-| `--only-fixed`        |               |         | Filter to fixable CVEs                                                                                                                                                         |
-| `--only-package-type` | `stringSlice` |         | Comma separated list of package types (like apk, deb, rpm, npm, pypi, golang, etc)                                                                                             |
-| `--only-policy`       | `stringSlice` |         | Comma separated list of policies to evaluate                                                                                                                                   |
-| `--only-severity`     | `stringSlice` |         | Comma separated list of severities (critical, high, medium, low, unspecified) to filter CVEs by                                                                                |
-| `--only-stage`        | `stringSlice` |         | Comma separated list of multi-stage Docker build stage names                                                                                                                   |
-| `--only-unfixed`      |               |         | Filter to unfixed CVEs                                                                                                                                                         |
-| `--org`               | `string`      |         | Namespace of the Docker organization                                                                                                                                           |
-| `-o`, `--output`      | `string`      |         | Write the report to a file                                                                                                                                                     |
-| `--platform`          | `string`      |         | Platform of image to analyze                                                                                                                                                   |
-| `--ref`               | `string`      |         | Reference to use if the provided tarball contains multiple references.<br>Can only be used with archive                                                                        |
-| `--to`                | `string`      |         | Image, directory, or archive to compare to                                                                                                                                     |
-| `--to-env`            | `string`      |         | Name of environment to compare to                                                                                                                                              |
-| `--to-latest`         |               |         | Latest image processed to compare to                                                                                                                                           |
-| `--to-ref`            | `string`      |         | Reference to use if the provided tarball contains multiple references.<br>Can only be used with archive.                                                                       |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout compare` command analyzes two images and displays a comparison.
-
-> This command is **experimental** and its behaviour might change in the future
-
-The intended use of this command is to compare two versions of the same image.
-For instance, when a new image is built and compared to the version running in production.
-
-If no image is specified, the most recently built image is used
-as a comparison target.
-
-The following artifact types are supported:
-
-- Images
-- OCI layout directories
-- Tarball archives, as created by `docker save`
-- Local directory or file
-
-By default, the tool expects an image reference, such as:
-
-- `redis`
-- `curlimages/curl:7.87.0`
-- `mcr.microsoft.com/dotnet/runtime:7.0`
-
-If the artifact you want to analyze is an OCI directory, a tarball archive, a local file or directory,
-or if you want to control from where the image will be resolved, you must prefix the reference with one of the following:
-
-- `image://` (default) use a local image, or fall back to a registry lookup
-- `local://` use an image from the local image store (don't do a registry lookup)
-- `registry://` use an image from a registry (don't use a local image)
-- `oci-dir://` use an OCI layout directory
-- `archive://` use a tarball archive, as created by `docker save`
-- `fs://` use a local directory or file
-- `sbom://` SPDX file or in-toto attestation file with SPDX predicate or `syft` json SBOM file
-
-## Examples
-
-### Compare the most recently built image to the latest tag
-
-```console
-$ docker scout compare --to namespace/repo:latest
-```
-
-### Compare local build to the same tag from the registry
-
-```console
-$ docker scout compare local://namespace/repo:latest --to registry://namespace/repo:latest
-```
-
-### Ignore base images
-
-```console
-$ docker scout compare --ignore-base --to namespace/repo:latest namespace/repo:v1.2.3-pre
-```
-
-### Generate a markdown output
-
-```console
-$ docker scout compare --format markdown --to namespace/repo:latest namespace/repo:v1.2.3-pre
-```
-
-### Only compare maven packages and only display critical vulnerabilities for maven packages
-
-```console
-$ docker scout compare --only-package-type maven --only-severity critical --to namespace/repo:latest namespace/repo:v1.2.3-pre
-```
-
-### Show all policy results for both images
-
-```console
-docker scout compare --to namespace/repo:latest namespace/repo:v1.2.3-pre
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_config.md b/_vendor/github.com/docker/scout-cli/docs/scout_config.md
deleted file mode 100644
index 1a6e8b69c9a3..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_config.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# docker scout config
-
-<!---MARKER_GEN_START-->
-Manage Docker Scout configuration
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-`docker scout config` allows you to list, get and set Docker Scout configuration.
-
-Available configuration key:
-
-- `organization`: Namespace of the Docker organization to be used by default.
-
-## Examples
-
-### List existing configuration
-
-```console
-$ docker scout config
-organization=my-org-namespace
-```
-
-### Print configuration value
-
-```console
-$ docker scout config organization
-my-org-namespace
-```
-
-### Set configuration value
-
-```console
-$ docker scout config organization my-org-namespace
-    ✓ Successfully set organization to my-org-namespace
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_cves.md b/_vendor/github.com/docker/scout-cli/docs/scout_cves.md
deleted file mode 100644
index bdb7f82921d0..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_cves.md
+++ /dev/null
@@ -1,271 +0,0 @@
-# docker scout cves
-
-```
-docker scout cves [OPTIONS] [IMAGE|DIRECTORY|ARCHIVE]
-```
-
-<!---MARKER_GEN_START-->
-Display CVEs identified in a software artifact
-
-### Options
-
-| Name                   | Type          | Default    | Description                                                                                                                                                                                                                                                                                                                                           |
-|:-----------------------|:--------------|:-----------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `--details`            |               |            | Print details on default text output                                                                                                                                                                                                                                                                                                                  |
-| `--env`                | `string`      |            | Name of environment                                                                                                                                                                                                                                                                                                                                   |
-| [`--epss`](#epss)      |               |            | Display the EPSS scores and organize the package's CVEs according to their EPSS score                                                                                                                                                                                                                                                                 |
-| `--epss-percentile`    | `float32`     | `0`        | Exclude CVEs with EPSS scores less than the specified percentile (0 to 1)                                                                                                                                                                                                                                                                             |
-| `--epss-score`         | `float32`     | `0`        | Exclude CVEs with EPSS scores less than the specified value (0 to 1)                                                                                                                                                                                                                                                                                  |
-| `-e`, `--exit-code`    |               |            | Return exit code '2' if vulnerabilities are detected                                                                                                                                                                                                                                                                                                  |
-| `--format`             | `string`      | `packages` | Output format of the generated vulnerability report:<br>- packages: default output, plain text with vulnerabilities grouped by packages<br>- sarif: json Sarif output<br>- spdx: json SPDX output<br>- gitlab: json GitLab output<br>- markdown: markdown output (including some html tags like collapsible sections)<br>- sbom: json SBOM output<br> |
-| `--ignore-base`        |               |            | Filter out CVEs introduced from base image                                                                                                                                                                                                                                                                                                            |
-| `--ignore-suppressed`  |               |            | Filter CVEs found in Scout exceptions based on the specified exception scope                                                                                                                                                                                                                                                                          |
-| `--locations`          |               |            | Print package locations including file paths and layer diff_id                                                                                                                                                                                                                                                                                        |
-| `--multi-stage`        |               |            | Show packages from multi-stage Docker builds                                                                                                                                                                                                                                                                                                          |
-| `--only-base`          |               |            | Only show CVEs introduced by the base image                                                                                                                                                                                                                                                                                                           |
-| `--only-cisa-kev`      |               |            | Filter to CVEs listed in the CISA KEV catalog                                                                                                                                                                                                                                                                                                         |
-| `--only-cve-id`        | `stringSlice` |            | Comma separated list of CVE ids (like CVE-2021-45105) to search for                                                                                                                                                                                                                                                                                   |
-| `--only-fixed`         |               |            | Filter to fixable CVEs                                                                                                                                                                                                                                                                                                                                |
-| `--only-metric`        | `stringSlice` |            | Comma separated list of CVSS metrics (like AV:N or PR:L) to filter CVEs by                                                                                                                                                                                                                                                                            |
-| `--only-package`       | `stringSlice` |            | Comma separated regular expressions to filter packages by                                                                                                                                                                                                                                                                                             |
-| `--only-package-type`  | `stringSlice` |            | Comma separated list of package types (like apk, deb, rpm, npm, pypi, golang, etc)                                                                                                                                                                                                                                                                    |
-| `--only-severity`      | `stringSlice` |            | Comma separated list of severities (critical, high, medium, low, unspecified) to filter CVEs by                                                                                                                                                                                                                                                       |
-| `--only-stage`         | `stringSlice` |            | Comma separated list of multi-stage Docker build stage names                                                                                                                                                                                                                                                                                          |
-| `--only-unfixed`       |               |            | Filter to unfixed CVEs                                                                                                                                                                                                                                                                                                                                |
-| `--only-vex-affected`  |               |            | Filter CVEs by VEX statements with status not affected                                                                                                                                                                                                                                                                                                |
-| `--only-vuln-packages` |               |            | When used with --format=only-packages ignore packages with no vulnerabilities                                                                                                                                                                                                                                                                         |
-| `--org`                | `string`      |            | Namespace of the Docker organization                                                                                                                                                                                                                                                                                                                  |
-| `-o`, `--output`       | `string`      |            | Write the report to a file                                                                                                                                                                                                                                                                                                                            |
-| `--platform`           | `string`      |            | Platform of image to analyze                                                                                                                                                                                                                                                                                                                          |
-| `--ref`                | `string`      |            | Reference to use if the provided tarball contains multiple references.<br>Can only be used with archive                                                                                                                                                                                                                                               |
-| `--vex-author`         | `stringSlice` |            | List of VEX statement authors to accept                                                                                                                                                                                                                                                                                                               |
-| `--vex-location`       | `stringSlice` |            | File location of directory or file containing VEX statements                                                                                                                                                                                                                                                                                          |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout cves` command analyzes a software artifact for vulnerabilities.
-
-If no image is specified, the most recently built image is used.
-
-The following artifact types are supported:
-
-- Images
-- OCI layout directories
-- Tarball archives, as created by `docker save`
-- Local directory or file
-
-By default, the tool expects an image reference, such as:
-
-- `redis`
-- `curlimages/curl:7.87.0`
-- `mcr.microsoft.com/dotnet/runtime:7.0`
-
-If the artifact you want to analyze is an OCI directory, a tarball archive, a local file or directory,
-or if you want to control from where the image will be resolved, you must prefix the reference with one of the following:
-
-- `image://` (default) use a local image, or fall back to a registry lookup
-- `local://` use an image from the local image store (don't do a registry lookup)
-- `registry://` use an image from a registry (don't use a local image)
-- `oci-dir://` use an OCI layout directory
-- `archive://` use a tarball archive, as created by `docker save`
-- `fs://` use a local directory or file
-- `sbom://` SPDX file or in-toto attestation file with SPDX predicate or `syft` json SBOM file
-    In case of `sbom://` prefix, if the file is not defined then it will try to read it from the standard input.
-
-## Examples
-
-### Display vulnerabilities grouped by package
-
-```console
-$ docker scout cves alpine
-Analyzing image alpine
-✓ Image stored for indexing
-✓ Indexed 18 packages
-✓ No vulnerable package detected
-```
-
-### Display vulnerabilities from a `docker save` tarball
-
-```console
-$ docker save alpine > alpine.tar
-
-$ docker scout cves archive://alpine.tar
-Analyzing archive alpine.tar
-✓ Archive read
-✓ SBOM of image already cached, 18 packages indexed
-✓ No vulnerable package detected
-```
-
-### Display vulnerabilities from an OCI directory
-
-```console
-$ skopeo copy --override-os linux docker://alpine oci:alpine
-
-$ docker scout cves oci-dir://alpine
-Analyzing OCI directory alpine
-✓ OCI directory read
-✓ Image stored for indexing
-✓ Indexed 19 packages
-✓ No vulnerable package detected
-```
-
-### Display vulnerabilities from the current directory
-
-```console
-$ docker scout cves fs://.
-```
-
-### Export vulnerabilities to a SARIF JSON file
-
-```console
-$ docker scout cves --format sarif --output alpine.sarif.json alpine
-Analyzing image alpine
-✓ SBOM of image already cached, 18 packages indexed
-✓ No vulnerable package detected
-✓ Report written to alpine.sarif.json
-```
-
-### Display markdown output
-
-The following example shows how to generate the vulnerability report as markdown.
-
-```console
-$ docker scout cves --format markdown alpine
-✓ Pulled
-✓ SBOM of image already cached, 19 packages indexed
-✗ Detected 1 vulnerable package with 3 vulnerabilities
-<h2>:mag: Vulnerabilities of <code>alpine</code></h2>
-
-<details open="true"><summary>:package: Image Reference</strong> <code>alpine</code></summary>
-<table>
-<tr><td>digest</td><td><code>sha256:e3bd82196e98898cae9fe7fbfd6e2436530485974dc4fb3b7ddb69134eda2407</code></td><tr><tr><td>vulnerabilities</td><td><img alt="critical: 0" src="https://img.shields.io/badge/critical-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/high-0-lightgrey"/> <img alt="medium: 2" src="https://img.shields.io/badge/medium-2-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/low-0-lightgrey"/> <img alt="unspecified: 1" src="https://img.shields.io/badge/unspecified-1-lightgrey"/></td></tr>
-<tr><td>platform</td><td>linux/arm64</td></tr>
-<tr><td>size</td><td>3.3 MB</td></tr>
-<tr><td>packages</td><td>19</td></tr>
-</table>
-</details></table>
-</details>
-...
-```
-
-### List all vulnerable packages of a certain type
-
-The following example shows how to generate a list of packages, only including
-packages of the specified type, and only showing packages that are vulnerable.
-
-```console
-$ docker scout cves --format only-packages --only-package-type golang --only-vuln-packages golang:1.18.0
-✓ Pulled
-✓ SBOM of image already cached, 296 packages indexed
-✗ Detected 1 vulnerable package with 40 vulnerabilities
-
-Name   Version   Type         Vulnerabilities
-───────────────────────────────────────────────────────────
-stdlib  1.18     golang     2C    29H     8M     1L
-```
-
-### <a name="epss"></a> Display EPSS score (--epss)
-
-The `--epss` flag adds [Exploit Prediction Scoring System (EPSS)](https://www.first.org/epss/)
-scores to the `docker scout cves` output. EPSS scores are estimates of the likelihood (probability)
-that a software vulnerability will be exploited in the wild in the next 30 days.
-The higher the score, the greater the probability that a vulnerability will be exploited.
-
-```console {hl_lines="13,14"}
-$ docker scout cves --epss nginx
- ✓ Provenance obtained from attestation
- ✓ SBOM obtained from attestation, 232 packages indexed
- ✓ Pulled
- ✗ Detected 23 vulnerable packages with a total of 39 vulnerabilities
-
-...
-
- ✗ HIGH CVE-2023-52425
-   https://scout.docker.com/v/CVE-2023-52425
-   Affected range  : >=2.5.0-1
-   Fixed version   : not fixed
-   EPSS Score      : 0.000510
-   EPSS Percentile : 0.173680
-```
-
-- `EPSS Score` is a floating point number between 0 and 1 representing the probability of exploitation in the wild in the next 30 days (following score publication).
-- `EPSS Percentile` is the percentile of the current score, the proportion of all scored vulnerabilities with the same or a lower EPSS score.
-
-You can use the `--epss-score` and `--epss-percentile` flags to filter the output
-of `docker scout cves` based on these scores. For example,
-to only show vulnerabilities with an EPSS score higher than 0.5:
-
-```console
-$ docker scout cves --epss --epss-score 0.5 nginx
- ✓ SBOM of image already cached, 232 packages indexed
- ✓ EPSS scores for 2024-03-01 already cached
- ✗ Detected 1 vulnerable package with 1 vulnerability
-
-...
-
- ✗ LOW CVE-2023-44487
-   https://scout.docker.com/v/CVE-2023-44487
-   Affected range  : >=1.22.1-9
-   Fixed version   : not fixed
-   EPSS Score      : 0.705850
-   EPSS Percentile : 0.979410
-```
-
-EPSS scores are updated on a daily basis.
-By default, the latest available score is displayed.
-You can use the `--epss-date` flag to manually specify a date
-in the format `yyyy-mm-dd` for fetching EPSS scores.
-
-```console
-$ docker scout cves --epss --epss-date 2024-01-02 nginx
-```
-
-### List vulnerabilities from an SPDX file
-
-The following example shows how to generate a list of vulnerabilities from an SPDX file using `syft`.
-
-```console
-$ syft -o spdx-json alpine:3.16.1 | docker scout cves sbom://
- ✔ Pulled image
- ✔ Loaded image                                                                                                                              alpine:3.16.1
- ✔ Parsed image                                                                    sha256:3d81c46cd8756ddb6db9ec36fa06a6fb71c287fb265232ba516739dc67a5f07d
- ✔ Cataloged contents                                                                     274a317d88b54f9e67799244a1250cad3fe7080f45249fa9167d1f871218d35f
-   ├── ✔ Packages                        [14 packages]
-   ├── ✔ File digests                    [75 files]
-   ├── ✔ File metadata                   [75 locations]
-   └── ✔ Executables                     [16 executables]
-    ✗ Detected 2 vulnerable packages with a total of 11 vulnerabilities
-
-
-## Overview
-
-                    │        Analyzed SBOM
-────────────────────┼──────────────────────────────
-  Target            │ <stdin>
-    digest          │  274a317d88b5
-    platform        │ linux/arm64
-    vulnerabilities │    1C     2H     8M     0L
-    packages        │ 15
-
-
-## Packages and Vulnerabilities
-
-   1C     0H     0M     0L  zlib 1.2.12-r1
-pkg:apk/alpine/zlib@1.2.12-r1?arch=aarch64&distro=alpine-3.16.1
-
-    ✗ CRITICAL CVE-2022-37434
-      https://scout.docker.com/v/CVE-2022-37434
-      Affected range : <1.2.12-r2
-      Fixed version  : 1.2.12-r2
-
-    ...
-
-11 vulnerabilities found in 2 packages
-  CRITICAL  1
-  HIGH      2
-  MEDIUM    8
-  LOW       0
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_docker-cli-plugin-hooks.md b/_vendor/github.com/docker/scout-cli/docs/scout_docker-cli-plugin-hooks.md
deleted file mode 100644
index 8fbcd0420366..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_docker-cli-plugin-hooks.md
+++ /dev/null
@@ -1,8 +0,0 @@
-# docker scout docker-cli-plugin-hooks
-
-<!---MARKER_GEN_START-->
-runs the plugins hooks
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_enroll.md b/_vendor/github.com/docker/scout-cli/docs/scout_enroll.md
deleted file mode 100644
index b60fd3471f6e..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_enroll.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# docker scout enroll
-
-<!---MARKER_GEN_START-->
-Enroll an organization with Docker Scout
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout enroll` command enrolls an organization with Docker Scout.
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_environment.md b/_vendor/github.com/docker/scout-cli/docs/scout_environment.md
deleted file mode 100644
index 4f019ff35cef..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_environment.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# docker scout environment
-
-<!---MARKER_GEN_START-->
-Manage environments (experimental)
-
-### Aliases
-
-`docker scout environment`, `docker scout env`
-
-### Options
-
-| Name             | Type     | Default | Description                          |
-|:-----------------|:---------|:--------|:-------------------------------------|
-| `--org`          | `string` |         | Namespace of the Docker organization |
-| `-o`, `--output` | `string` |         | Write the report to a file           |
-| `--platform`     | `string` |         | Platform of image to record          |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout environment` command lists the environments.
-If you pass an image reference, the image is recorded to the specified environment.
-
-Once recorded, environments can be referred to by their name. For example,
-you can refer to the `production` environment with the `docker scout compare`
-command as follows:
-
-```console
-$ docker scout compare --to-env production
-```
-
-## Examples
-
-### List existing environments
-
-```console
-$ docker scout environment
-prod
-staging
-```
-
-### List images of an environment
-
-```console
-$ docker scout environment staging
-namespace/repo:tag@sha256:9a4df4fadc9bbd44c345e473e0688c2066a6583d4741679494ba9228cfd93e1b
-namespace/other-repo:tag@sha256:0001d6ce124855b0a158569c584162097fe0ca8d72519067c2c8e3ce407c580f
-```
-
-### Record an image to an environment, for a specific platform
-
-```console
-$ docker scout environment staging namespace/repo:stage-latest --platform linux/amd64
-✓ Pulled
-✓ Successfully recorded namespace/repo:stage-latest in environment staging
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_help.md b/_vendor/github.com/docker/scout-cli/docs/scout_help.md
deleted file mode 100644
index ec152c6aaf9f..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_help.md
+++ /dev/null
@@ -1,8 +0,0 @@
-# docker scout help
-
-<!---MARKER_GEN_START-->
-Display information about the available commands
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_integration.md b/_vendor/github.com/docker/scout-cli/docs/scout_integration.md
deleted file mode 100644
index 9a2def3a0b8f..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_integration.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# docker scout integration
-
-<!---MARKER_GEN_START-->
-Commands to list, configure, and delete Docker Scout integrations
-
-### Subcommands
-
-| Name                                          | Description                                         |
-|:----------------------------------------------|:----------------------------------------------------|
-| [`configure`](scout_integration_configure.md) | Configure or update a new integration configuration |
-| [`delete`](scout_integration_delete.md)       | Delete a new integration configuration              |
-| [`list`](scout_integration_list.md)           | Integration Docker Scout                            |
-
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_integration_configure.md b/_vendor/github.com/docker/scout-cli/docs/scout_integration_configure.md
deleted file mode 100644
index 521193ae3bce..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_integration_configure.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# docker scout integration configure
-
-<!---MARKER_GEN_START-->
-Configure or update a new integration configuration
-
-### Options
-
-| Name          | Type          | Default | Description                                                  |
-|:--------------|:--------------|:--------|:-------------------------------------------------------------|
-| `--name`      | `string`      |         | Name of integration configuration to create                  |
-| `--org`       | `string`      |         | Namespace of the Docker organization                         |
-| `--parameter` | `stringSlice` |         | Integration parameters in the form of --parameter NAME=VALUE |
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_integration_delete.md b/_vendor/github.com/docker/scout-cli/docs/scout_integration_delete.md
deleted file mode 100644
index 0a68c8adcaf3..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_integration_delete.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# docker scout integration delete
-
-<!---MARKER_GEN_START-->
-Delete a new integration configuration
-
-### Options
-
-| Name     | Type     | Default | Description                                 |
-|:---------|:---------|:--------|:--------------------------------------------|
-| `--name` | `string` |         | Name of integration configuration to delete |
-| `--org`  | `string` |         | Namespace of the Docker organization        |
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_integration_list.md b/_vendor/github.com/docker/scout-cli/docs/scout_integration_list.md
deleted file mode 100644
index 67b39c59fc57..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_integration_list.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# docker scout integration list
-
-<!---MARKER_GEN_START-->
-Integration Docker Scout
-
-### Options
-
-| Name     | Type     | Default | Description                               |
-|:---------|:---------|:--------|:------------------------------------------|
-| `--name` | `string` |         | Name of integration configuration to list |
-| `--org`  | `string` |         | Namespace of the Docker organization      |
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_policy.md b/_vendor/github.com/docker/scout-cli/docs/scout_policy.md
deleted file mode 100644
index 46735c018d74..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_policy.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# docker scout policy
-
-<!---MARKER_GEN_START-->
-Evaluate policies against an image and display the policy evaluation results (experimental)
-
-### Options
-
-| Name                | Type          | Default | Description                                                 |
-|:--------------------|:--------------|:--------|:------------------------------------------------------------|
-| `-e`, `--exit-code` |               |         | Return exit code '2' if policies are not met, '0' otherwise |
-| `--only-policy`     | `stringSlice` |         | Comma separated list of policies to evaluate                |
-| `--org`             | `string`      |         | Namespace of the Docker organization                        |
-| `-o`, `--output`    | `string`      |         | Write the report to a file                                  |
-| `--platform`        | `string`      |         | Platform of image to pull policy results from               |
-| `--to-env`          | `string`      |         | Name of the environment to compare to                       |
-| `--to-latest`       |               |         | Latest image processed to compare to                        |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout policy` command evaluates policies against an image.
-The image analysis is uploaded to Docker Scout where policies get evaluated.
-
-The policy evaluation results may take a few minutes to become available.
-
-## Examples
-
-### Evaluate policies against an image and display the results
-
-```console
-$ docker scout policy dockerscoutpolicy/customers-api-service:0.0.1
-```
-
-### Evaluate policies against an image for a specific organization
-
-```console
-$ docker scout policy dockerscoutpolicy/customers-api-service:0.0.1 --org dockerscoutpolicy
-```
-
-### Evaluate policies against an image with a specific platform
-
-```console
-$ docker scout policy dockerscoutpolicy/customers-api-service:0.0.1 --platform linux/amd64
-```
-
-### Compare policy results for a repository in a specific environment
-
-```console
-$ docker scout policy dockerscoutpolicy/customers-api-service --to-env production
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_push.md b/_vendor/github.com/docker/scout-cli/docs/scout_push.md
deleted file mode 100644
index 09e3397e5c76..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_push.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# docker scout push
-
-<!---MARKER_GEN_START-->
-Push an image or image index to Docker Scout
-
-### Options
-
-| Name             | Type     | Default | Description                                                        |
-|:-----------------|:---------|:--------|:-------------------------------------------------------------------|
-| `--author`       | `string` |         | Name of the author of the image                                    |
-| `--dry-run`      |          |         | Do not push the image but process it                               |
-| `--org`          | `string` |         | Namespace of the Docker organization to which image will be pushed |
-| `-o`, `--output` | `string` |         | Write the report to a file                                         |
-| `--platform`     | `string` |         | Platform of image to be pushed                                     |
-| `--sbom`         |          |         | Create and upload SBOMs                                            |
-| `--timestamp`    | `string` |         | Timestamp of image or tag creation                                 |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout push` command lets you push an image or analysis result to Docker Scout.
-
-## Examples
-
-### Push an image to Docker Scout
-
-```console
-$ docker scout push --org my-org registry.example.com/repo:tag
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_quickview.md b/_vendor/github.com/docker/scout-cli/docs/scout_quickview.md
deleted file mode 100644
index 3bf752a0cf9b..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_quickview.md
+++ /dev/null
@@ -1,101 +0,0 @@
-# docker scout quickview
-
-<!---MARKER_GEN_START-->
-Quick overview of an image
-
-### Aliases
-
-`docker scout quickview`, `docker scout qv`
-
-### Options
-
-| Name                  | Type          | Default | Description                                                                                             |
-|:----------------------|:--------------|:--------|:--------------------------------------------------------------------------------------------------------|
-| `--env`               | `string`      |         | Name of the environment                                                                                 |
-| `--ignore-suppressed` |               |         | Filter CVEs found in Scout exceptions based on the specified exception scope                            |
-| `--latest`            |               |         | Latest indexed image                                                                                    |
-| `--only-policy`       | `stringSlice` |         | Comma separated list of policies to evaluate                                                            |
-| `--only-vex-affected` |               |         | Filter CVEs by VEX statements with status not affected                                                  |
-| `--org`               | `string`      |         | Namespace of the Docker organization                                                                    |
-| `-o`, `--output`      | `string`      |         | Write the report to a file                                                                              |
-| `--platform`          | `string`      |         | Platform of image to analyze                                                                            |
-| `--ref`               | `string`      |         | Reference to use if the provided tarball contains multiple references.<br>Can only be used with archive |
-| `--vex-author`        | `stringSlice` |         | List of VEX statement authors to accept                                                                 |
-| `--vex-location`      | `stringSlice` |         | File location of directory or file containing VEX statements                                            |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout quickview` command displays a quick overview of an image.
-It displays a summary of the vulnerabilities in the specified image
-and vulnerabilities from the base image.
-If available, it also displays base image refresh and update recommendations.
-
-If no image is specified, the most recently built image is used.
-
-The following artifact types are supported:
-
-- Images
-- OCI layout directories
-- Tarball archives, as created by `docker save`
-- Local directory or file
-
-By default, the tool expects an image reference, such as:
-
-- `redis`
-- `curlimages/curl:7.87.0`
-- `mcr.microsoft.com/dotnet/runtime:7.0`
-
-If the artifact you want to analyze is an OCI directory, a tarball archive, a local file or directory,
-or if you want to control from where the image will be resolved, you must prefix the reference with one of the following:
-
-- `image://` (default) use a local image, or fall back to a registry lookup
-- `local://` use an image from the local image store (don't do a registry lookup)
-- `registry://` use an image from a registry (don't use a local image)
-- `oci-dir://` use an OCI layout directory
-- `archive://` use a tarball archive, as created by `docker save`
-- `fs://` use a local directory or file
-- `sbom://` SPDX file or in-toto attestation file with SPDX predicate or `syft` json SBOM file
-    In case of `sbom://` prefix, if the file is not defined then it will try to read it from the standard input.
-
-## Examples
-
-### Quick overview of an image
-
-```console
-$ docker scout quickview golang:1.19.4
-    ...Pulling
-    ✓ Pulled
-    ✓ SBOM of image already cached, 278 packages indexed
-
-  Your image  golang:1.19.4                          │    5C     3H     6M    63L
-  Base image  buildpack-deps:bullseye-scm            │    5C     1H     3M    48L     6?
-  Refreshed base image  buildpack-deps:bullseye-scm  │    0C     0H     0M    42L
-                                                     │    -5     -1     -3     -6     -6
-  Updated base image  buildpack-deps:sid-scm         │    0C     0H     1M    29L
-                                                     │    -5     -1     -2    -19     -6
-```
-
-### Quick overview of the most recently built image
-
-```console
-$ docker scout qv
-```
-
-### Quick overview from an SPDX file
-
-```console
-$  syft -o spdx-json alpine:3.16.1 | docker scout quickview sbom://
- ✔ Loaded image                                                                                                                              alpine:3.16.1
- ✔ Parsed image                                                                    sha256:3d81c46cd8756ddb6db9ec36fa06a6fb71c287fb265232ba516739dc67a5f07d
- ✔ Cataloged contents                                                                     274a317d88b54f9e67799244a1250cad3fe7080f45249fa9167d1f871218d35f
-   ├── ✔ Packages                        [14 packages]
-   ├── ✔ File digests                    [75 files]
-   ├── ✔ File metadata                   [75 locations]
-   └── ✔ Executables                     [16 executables]
-
-  Target   │ <stdin>        │    1C     2H     8M     0L
-    digest │  274a317d88b5  │
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_recommendations.md b/_vendor/github.com/docker/scout-cli/docs/scout_recommendations.md
deleted file mode 100644
index f1ccdf64feeb..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_recommendations.md
+++ /dev/null
@@ -1,71 +0,0 @@
-# docker scout recommendations
-
-<!---MARKER_GEN_START-->
-Display available base image updates and remediation recommendations
-
-### Options
-
-| Name             | Type     | Default | Description                                                                                             |
-|:-----------------|:---------|:--------|:--------------------------------------------------------------------------------------------------------|
-| `--only-refresh` |          |         | Only display base image refresh recommendations                                                         |
-| `--only-update`  |          |         | Only display base image update recommendations                                                          |
-| `--org`          | `string` |         | Namespace of the Docker organization                                                                    |
-| `-o`, `--output` | `string` |         | Write the report to a file                                                                              |
-| `--platform`     | `string` |         | Platform of image to analyze                                                                            |
-| `--ref`          | `string` |         | Reference to use if the provided tarball contains multiple references.<br>Can only be used with archive |
-| `--tag`          | `string` |         | Specify tag                                                                                             |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout recommendations` command display recommendations for base images updates.
-It analyzes the image and display recommendations to refresh or update the base image.
-For each recommendation it shows a list of benefits, such as
-fewer vulnerabilities or smaller image size.
-
-If no image is specified, the most recently built image is used.
-
-The following artifact types are supported:
-
-- Images
-- OCI layout directories
-- Tarball archives, as created by `docker save`
-- Local directory or file
-
-By default, the tool expects an image reference, such as:
-
-- `redis`
-- `curlimages/curl:7.87.0`
-- `mcr.microsoft.com/dotnet/runtime:7.0`
-
-If the artifact you want to analyze is an OCI directory, a tarball archive, a local file or directory,
-or if you want to control from where the image will be resolved, you must prefix the reference with one of the following:
-
-- `image://` (default) use a local image, or fall back to a registry lookup
-- `local://` use an image from the local image store (don't do a registry lookup)
-- `registry://` use an image from a registry (don't use a local image)
-- `oci-dir://` use an OCI layout directory
-- `archive://` use a tarball archive, as created by `docker save`
-- `fs://` use a local directory or file
-
-## Examples
-
-### Display base image update recommendations
-
-```console
-$ docker scout recommendations golang:1.19.4
-```
-
-### Display base image refresh only recommendations
-
-```console
-$ docker scout recommendations --only-refresh golang:1.19.4
-```
-
-### Display base image update only recommendations
-
-```console
-$ docker scout recommendations --only-update golang:1.19.4
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_repo.md b/_vendor/github.com/docker/scout-cli/docs/scout_repo.md
deleted file mode 100644
index 1f2038ea757e..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_repo.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# docker scout repo
-
-<!---MARKER_GEN_START-->
-Commands to list, enable, and disable Docker Scout on repositories
-
-### Subcommands
-
-| Name                               | Description                    |
-|:-----------------------------------|:-------------------------------|
-| [`disable`](scout_repo_disable.md) | Disable Docker Scout           |
-| [`enable`](scout_repo_enable.md)   | Enable Docker Scout            |
-| [`list`](scout_repo_list.md)       | List Docker Scout repositories |
-
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_repo_disable.md b/_vendor/github.com/docker/scout-cli/docs/scout_repo_disable.md
deleted file mode 100644
index 24842906b813..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_repo_disable.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# docker scout repo disable
-
-<!---MARKER_GEN_START-->
-Disable Docker Scout
-
-### Options
-
-| Name            | Type     | Default | Description                                                                  |
-|:----------------|:---------|:--------|:-----------------------------------------------------------------------------|
-| `--all`         |          |         | Disable all repositories of the organization. Can not be used with --filter. |
-| `--filter`      | `string` |         | Regular expression to filter repositories by name                            |
-| `--integration` | `string` |         | Name of the integration to use for enabling an image                         |
-| `--org`         | `string` |         | Namespace of the Docker organization                                         |
-| `--registry`    | `string` |         | Container Registry                                                           |
-
-
-<!---MARKER_GEN_END-->
-
-## Examples
-
-### Disable a specific repository
-
-```console
-$ docker scout repo disable my/repository
-```
-
-### Disable all repositories of the organization
-
-```console
-$ docker scout repo disable --all
-```
-
-### Disable some repositories based on a filter
-
-```console
-$ docker scout repo disable --filter namespace/backend
-```
-
-### Disable a repository from a specific registry
-
-```console
-$ docker scout repo disable my/repository --registry 123456.dkr.ecr.us-east-1.amazonaws.com
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_repo_enable.md b/_vendor/github.com/docker/scout-cli/docs/scout_repo_enable.md
deleted file mode 100644
index 3065a68bccdd..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_repo_enable.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# docker scout repo enable
-
-<!---MARKER_GEN_START-->
-Enable Docker Scout
-
-### Options
-
-| Name            | Type     | Default | Description                                                                 |
-|:----------------|:---------|:--------|:----------------------------------------------------------------------------|
-| `--all`         |          |         | Enable all repositories of the organization. Can not be used with --filter. |
-| `--filter`      | `string` |         | Regular expression to filter repositories by name                           |
-| `--integration` | `string` |         | Name of the integration to use for enabling an image                        |
-| `--org`         | `string` |         | Namespace of the Docker organization                                        |
-| `--registry`    | `string` |         | Container Registry                                                          |
-
-
-<!---MARKER_GEN_END-->
-
-## Examples
-
-### Enable a specific repository
-
-```console
-$ docker scout repo enable my/repository
-```
-
-### Enable all repositories of the organization
-
-```console
-$ docker scout repo enable --all
-```
-
-### Enable some repositories based on a filter
-
-```console
-$ docker scout repo enable --filter namespace/backend
-```
-
-### Enable a repository from a specific registry
-
-```console
-$ docker scout repo enable my/repository --registry 123456.dkr.ecr.us-east-1.amazonaws.com
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_repo_list.md b/_vendor/github.com/docker/scout-cli/docs/scout_repo_list.md
deleted file mode 100644
index 1e2d740574e9..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_repo_list.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# docker scout repo list
-
-<!---MARKER_GEN_START-->
-List Docker Scout repositories
-
-### Options
-
-| Name              | Type     | Default | Description                                                                |
-|:------------------|:---------|:--------|:---------------------------------------------------------------------------|
-| `--filter`        | `string` |         | Regular expression to filter repositories by name                          |
-| `--only-disabled` |          |         | Filter to disabled repositories only                                       |
-| `--only-enabled`  |          |         | Filter to enabled repositories only                                        |
-| `--only-registry` | `string` |         | Filter to a specific registry only:<br>- hub.docker.com<br>- ecr (AWS ECR) |
-| `--org`           | `string` |         | Namespace of the Docker organization                                       |
-
-
-<!---MARKER_GEN_END-->
-
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_sbom.md b/_vendor/github.com/docker/scout-cli/docs/scout_sbom.md
deleted file mode 100644
index a335d5f83f2e..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_sbom.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# docker scout sbom
-
-<!---MARKER_GEN_START-->
-Generate or display SBOM of an image
-
-### Options
-
-| Name                  | Type          | Default | Description                                                                                                                                                                                         |
-|:----------------------|:--------------|:--------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `--format`            | `string`      | `json`  | Output format:<br>- list: list of packages of the image<br>- json: json representation of the SBOM<br>- spdx: spdx representation of the SBOM<br>- cyclonedx: cyclone dx representation of the SBOM |
-| `--only-package-type` | `stringSlice` |         | Comma separated list of package types (like apk, deb, rpm, npm, pypi, golang, etc)<br>Can only be used with --format list                                                                           |
-| `-o`, `--output`      | `string`      |         | Write the report to a file                                                                                                                                                                          |
-| `--platform`          | `string`      |         | Platform of image to analyze                                                                                                                                                                        |
-| `--ref`               | `string`      |         | Reference to use if the provided tarball contains multiple references.<br>Can only be used with archive                                                                                             |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout sbom` command analyzes a software artifact to generate a
-Software Bill Of Materials (SBOM).
-
-The SBOM contains a list of all packages in the image.
-You can use the `--format` flag to filter the output of the command
-to display only packages of a specific type.
-
-If no image is specified, the most recently built image is used.
-
-The following artifact types are supported:
-
-- Images
-- OCI layout directories
-- Tarball archives, as created by `docker save`
-- Local directory or file
-
-By default, the tool expects an image reference, such as:
-
-- `redis`
-- `curlimages/curl:7.87.0`
-- `mcr.microsoft.com/dotnet/runtime:7.0`
-
-If the artifact you want to analyze is an OCI directory, a tarball archive, a local file or directory,
-or if you want to control from where the image will be resolved, you must prefix the reference with one of the following:
-
-- `image://` (default) use a local image, or fall back to a registry lookup
-- `local://` use an image from the local image store (don't do a registry lookup)
-- `registry://` use an image from a registry (don't use a local image)
-- `oci-dir://` use an OCI layout directory
-- `archive://` use a tarball archive, as created by `docker save`
-- `fs://` use a local directory or file
-
-## Examples
-
-### Display the list of packages
-
-```console
-$ docker scout sbom --format list alpine
-```
-
-### Only display packages of a specific type
-
-```console
- $ docker scout sbom --format list --only-package-type apk alpine
-```
-
-### Display the full SBOM in JSON format
-
-```console
-$ docker scout sbom alpine
-```
-
-### Display the full SBOM of the most recently built image
-
-```console
-$ docker scout sbom
-```
-
-### Write SBOM to a file
-
-```console
-$ docker scout sbom --output alpine.sbom alpine
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_stream.md b/_vendor/github.com/docker/scout-cli/docs/scout_stream.md
deleted file mode 100644
index 886df3e6cf04..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_stream.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# docker scout stream
-
-<!---MARKER_GEN_START-->
-Manage streams (experimental)
-
-### Options
-
-| Name             | Type     | Default | Description                          |
-|:-----------------|:---------|:--------|:-------------------------------------|
-| `--org`          | `string` |         | Namespace of the Docker organization |
-| `-o`, `--output` | `string` |         | Write the report to a file           |
-| `--platform`     | `string` |         | Platform of image to record          |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout stream` command lists the deployment streams and records an image to it.
-
-Once recorded, streams can be referred to by their name, eg. in the `docker scout compare` command using `--to-stream`.
-
-## Examples
-
-### List existing streams
-
-```console
-$ %[1]s %[2]s
-prod-cluster-123
-stage-cluster-234
-```
-
-### List images of a stream
-
-```console
-$ %[1]s %[2]s prod-cluster-123
-namespace/repo:tag@sha256:9a4df4fadc9bbd44c345e473e0688c2066a6583d4741679494ba9228cfd93e1b
-namespace/other-repo:tag@sha256:0001d6ce124855b0a158569c584162097fe0ca8d72519067c2c8e3ce407c580f
-```
-
-### Record an image to a stream, for a specific platform
-
-```console
-$ %[1]s %[2]s stage-cluster-234 namespace/repo:stage-latest --platform linux/amd64
-✓ Pulled
-✓ Successfully recorded namespace/repo:stage-latest in stream stage-cluster-234
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_version.md b/_vendor/github.com/docker/scout-cli/docs/scout_version.md
deleted file mode 100644
index 5365123c05d8..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_version.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# docker scout version
-
-```
-docker scout version
-```
-
-<!---MARKER_GEN_START-->
-Show Docker Scout version information
-
-
-<!---MARKER_GEN_END-->
-
-## Examples
-
-```console
-$ docker scout version
-
-      ⢀⢀⢀             ⣀⣀⡤⣔⢖⣖⢽⢝
-   ⡠⡢⡣⡣⡣⡣⡣⡣⡢⡀    ⢀⣠⢴⡲⣫⡺⣜⢞⢮⡳⡵⡹⡅
-  ⡜⡜⡜⡜⡜⡜⠜⠈⠈        ⠁⠙⠮⣺⡪⡯⣺⡪⡯⣺ 
- ⢘⢜⢜⢜⢜⠜               ⠈⠪⡳⡵⣹⡪⠇ 
- ⠨⡪⡪⡪⠂    ⢀⡤⣖⢽⡹⣝⡝⣖⢤⡀    ⠘⢝⢮⡚       _____                 _   
-  ⠱⡱⠁    ⡴⡫⣞⢮⡳⣝⢮⡺⣪⡳⣝⢦    ⠘⡵⠁      / ____| Docker        | |  
-   ⠁    ⣸⢝⣕⢗⡵⣝⢮⡳⣝⢮⡺⣪⡳⣣    ⠁      | (___   ___ ___  _   _| |_ 
-        ⣗⣝⢮⡳⣝⢮⡳⣝⢮⡳⣝⢮⢮⡳            \___ \ / __/ _ \| | | | __|
-   ⢀    ⢱⡳⡵⣹⡪⡳⣝⢮⡳⣝⢮⡳⡣⡏    ⡀       ____) | (_| (_) | |_| | |_ 
-  ⢀⢾⠄    ⠫⣞⢮⡺⣝⢮⡳⣝⢮⡳⣝⠝    ⢠⢣⢂     |_____/ \___\___/ \__,_|\__|
-  ⡼⣕⢗⡄    ⠈⠓⠝⢮⡳⣝⠮⠳⠙     ⢠⢢⢣⢣  
- ⢰⡫⡮⡳⣝⢦⡀              ⢀⢔⢕⢕⢕⢕⠅ 
- ⡯⣎⢯⡺⣪⡳⣝⢖⣄⣀        ⡀⡠⡢⡣⡣⡣⡣⡣⡃  
-⢸⢝⢮⡳⣝⢮⡺⣪⡳⠕⠗⠉⠁    ⠘⠜⡜⡜⡜⡜⡜⡜⠜⠈   
-⡯⡳⠳⠝⠊⠓⠉             ⠈⠈⠈⠈      
-
-
-
-version: v1.0.9 (go1.21.3 - darwin/arm64)
-git commit: 8bf95bf60d084af341f70e8263342f71b0a3cd16
-```
diff --git a/_vendor/github.com/docker/scout-cli/docs/scout_watch.md b/_vendor/github.com/docker/scout-cli/docs/scout_watch.md
deleted file mode 100644
index 2444ce3c430a..000000000000
--- a/_vendor/github.com/docker/scout-cli/docs/scout_watch.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# docker scout watch
-
-<!---MARKER_GEN_START-->
-Watch repositories in a registry and push images and indexes to Docker Scout (experimental)
-
-### Options
-
-| Name                 | Type          | Default | Description                                                                         |
-|:---------------------|:--------------|:--------|:------------------------------------------------------------------------------------|
-| `--all-images`       |               |         | Push all images instead of only the ones pushed during the watch command is running |
-| `--dry-run`          |               |         | Watch images and prepare them, but do not push them                                 |
-| `--interval`         | `int64`       | `60`    | Interval in seconds between checks                                                  |
-| `--org`              | `string`      |         | Namespace of the Docker organization to which image will be pushed                  |
-| `--refresh-registry` |               |         | Refresh the list of repositories of a registry at every run. Only with --registry.  |
-| `--registry`         | `string`      |         | Registry to watch                                                                   |
-| `--repository`       | `stringSlice` |         | Repository to watch                                                                 |
-| `--sbom`             |               |         | Create and upload SBOMs                                                             |
-| `--tag`              | `stringSlice` |         | Regular expression to match tags to watch                                           |
-| `--workers`          | `int`         | `3`     | Number of concurrent workers                                                        |
-
-
-<!---MARKER_GEN_END-->
-
-## Description
-
-The `docker scout watch` command watches repositories in a registry
-and pushes images or analysis results to Docker Scout.
-
-## Examples
-
-### Watch for new images from two repositories and push them
-
-```console
-$ docker scout watch --org my-org --repository registry-1.example.com/repo-1 --repository registry-2.example.com/repo-2
-```
-
-### Only push images with a specific tag
-
-```console
-$ docker scout watch --org my-org --repository registry.example.com/my-service --tag latest
-```
-
-### Watch all repositories of a registry
-
-```console
-$ docker scout watch --org my-org --registry registry.example.com
-```
-
-### Push all images and not just the new ones
-
-```console
-$ docker scout watch--org my-org --repository registry.example.com/my-service --all-images
-```
diff --git a/_vendor/github.com/moby/buildkit/docs/attestations/attestation-storage.md b/_vendor/github.com/moby/buildkit/docs/attestations/attestation-storage.md
index a42fab303a5e..bcc8a5f7ec0b 100644
--- a/_vendor/github.com/moby/buildkit/docs/attestations/attestation-storage.md
+++ b/_vendor/github.com/moby/buildkit/docs/attestations/attestation-storage.md
@@ -7,12 +7,12 @@ attestations can provide valuable information from the build process,
 including, but not limited to: [SBOMs](https://en.wikipedia.org/wiki/Software_supply_chain),
 [SLSA Provenance](https://slsa.dev/provenance), build logs, etc.
 
-This document describes the current custom format used to store attestations,
-which is designed to be compatible with current registry implementations today.
-In the future, we may support exporting attestations in additional formats.
+This document describes the formats used to store attestations. BuildKit stores
+attestations as OCI artifacts when OCI media types are enabled. Set the image
+exporter option `oci-artifact=false` to use the legacy attestation image
+manifest format.
 
-Attestations are stored as manifest objects in the image index, similar in
-style to OCI artifacts.
+Attestations are stored as manifest objects in the image index.
 
 ## Properties
 
@@ -21,12 +21,18 @@ style to OCI artifacts.
 Attestation manifests are attached to the root image index object, under a
 separate [OCI image manifest](https://github.com/opencontainers/image-spec/blob/main/manifest.md).
 Each attestation manifest can contain multiple [attestation blobs](#attestation-blob),
-with all the of the attestations in a manifest applying to a single platform
+with all of the attestations in a manifest applying to a single platform
 manifest. All properties of standard OCI and Docker manifests continue to
 apply.
 
-The image `config` descriptor will point to a valid [image config](https://github.com/opencontainers/image-spec/blob/main/config.md),
-however, it will not contain attestation-specific details, and should be
+When OCI artifact storage is enabled, the manifest `artifactType` is set to
+`application/vnd.docker.attestation.manifest.v1+json`, the `subject` descriptor
+points to the target image manifest, and the `config` descriptor uses the OCI
+empty JSON descriptor.
+
+When `oci-artifact=false` is set, the image `config` descriptor will point to a
+valid [image config](https://github.com/opencontainers/image-spec/blob/main/config.md).
+The image config will not contain attestation-specific details, and should be
 ignored as it is only included for compatibility purposes.
 
 Each image layer in `layers` will contain a descriptor for a single
@@ -62,7 +68,7 @@ The contents of each layer will be a blob dependent on its `mediaType`.
 
   ```json
   {
-    "_type": "https://in-toto.io/Statement/v0.1",
+    "_type": "https://in-toto.io/Statement/v1",
     "subject": [
       {
         "name": "<NAME>",
@@ -160,10 +166,12 @@ This attestation manifest contains one attestation that is an in-toto attestatio
 {
   "mediaType": "application/vnd.oci.image.manifest.v1+json",
   "schemaVersion": 2,
+  "artifactType": "application/vnd.docker.attestation.manifest.v1+json",
   "config": {
-    "mediaType": "application/vnd.oci.image.config.v1+json",
-    "digest": "sha256:a781560066f20ec9c28f2115a95a886e5e71c7c7aa9d8fd680678498b82f3ea3",
-    "size": 123
+    "mediaType": "application/vnd.oci.empty.v1+json",
+    "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
+    "size": 2,
+    "data": "e30="
   },
   "layers": [
     {
@@ -174,22 +182,11 @@ This attestation manifest contains one attestation that is an in-toto attestatio
         "in-toto.io/predicate-type": "https://spdx.dev/Document"
       }
     }
-  ]
-}
-```
-
-#### Image config (`sha256:a781560066f20ec9c28f2115a95a886e5e71c7c7aa9d8fd680678498b82f3ea3`):
-
-```json
-{
-  "architecture": "unknown",
-  "os": "unknown",
-  "config": {},
-  "rootfs": {
-    "type": "layers",
-    "diff_ids": [
-      "sha256:133ae3f9bcc385295b66c2d83b28c25a9f294ce20954d5cf922dda860429734a"
-    ]
+  ],
+  "subject": {
+    "mediaType": "application/vnd.oci.image.manifest.v1+json",
+    "digest": "sha256:23678f31b3b3586c4fb318aecfe64a96a1f0916ba8faf9b2be2abee63fa9e827",
+    "size": 1234
   }
 }
 ```
@@ -200,7 +197,7 @@ Attestation body containing the SBOM data listing the packages used during the b
 
 ```json
 {
-  "_type": "https://in-toto.io/Statement/v0.1",
+  "_type": "https://in-toto.io/Statement/v1",
   "predicateType": "https://spdx.dev/Document",
   "subject": [
     {
diff --git a/_vendor/github.com/moby/buildkit/docs/attestations/slsa-definitions.md b/_vendor/github.com/moby/buildkit/docs/attestations/slsa-definitions.md
index 08b692df3d3b..0053e1e12d28 100644
--- a/_vendor/github.com/moby/buildkit/docs/attestations/slsa-definitions.md
+++ b/_vendor/github.com/moby/buildkit/docs/attestations/slsa-definitions.md
@@ -2,22 +2,436 @@
 title: SLSA definitions
 ---
 
-BuildKit supports the [creation of SLSA Provenance](./slsa-provenance.md) for builds that
-it runs.
+BuildKit supports the [creation of SLSA Provenance](./slsa-provenance.md) for
+builds that it runs.
 
 The provenance format generated by BuildKit is defined by the
-[SLSA Provenance format](https://slsa.dev/provenance/v0.2).
+SLSA Provenance format (supports both [v0.2](https://slsa.dev/spec/v0.2/provenance)
+and [v1](https://slsa.dev/spec/v1.1/provenance)).
 
 This page describes how BuildKit populate each field, and whether the field gets
 included when you generate attestations `mode=min` and `mode=max`.
 
-## `builder.id`
+## SLSA v1
 
-Corresponds to [SLSA `builder.id`](https://slsa.dev/provenance/v0.2#builder.id).
+### `buildDefinition.buildType`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#buildType
+* Included with `mode=min` and `mode=max`.
+
+The `buildDefinition.buildType` field is set to `https://github.com/moby/buildkit/blob/master/docs/attestations/slsa-definitions.md`
+and can be used to determine the structure of the provenance content.
+
+```json
+    "buildDefinition": {
+      "buildType": "https://github.com/moby/buildkit/blob/master/docs/attestations/slsa-definitions.md",
+      ...
+    }
+```
+
+### `buildDefinition.externalParameters.configSource`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#externalParameters
+* Included with `mode=min` and `mode=max`.
+
+Describes the config that initialized the build.
+
+```json
+    "buildDefinition": {
+      "externalParameters": {
+        "configSource": {
+          "uri": "https://github.com/moby/buildkit.git#refs/tags/v0.11.0",
+          "digest": {
+            "sha1": "4b220de5058abfd01ff619c9d2ff6b09a049bea0"
+          },
+          "path": "Dockerfile"
+        },
+        ...
+      },
+    }
+```
+
+For builds initialized from a remote context, like a Git or HTTP URL, this
+object defines the context URL and its immutable digest in the `uri` and
+`digest` fields. For builds using a local frontend, such as a Dockerfile, the
+`path` field defines the path for the frontend file that initialized the build
+(`filename` frontend option).
+
+### `buildDefinition.externalParameters.request`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#externalParameters
+* Partially included with `mode=min`.
+
+Describes build inputs passed to the build.
+
+```json
+    "buildDefinition": {
+      "externalParameters": {
+        "request": {
+          "frontend": "gateway.v0",
+          "args": {
+            "build-arg:BUILDKIT_CONTEXT_KEEP_GIT_DIR": "1",
+            "label:FOO": "bar",
+            "source": "docker/dockerfile-upstream:master",
+            "target": "release"
+          },
+          "secrets": [
+            {
+              "id": "GIT_AUTH_HEADER",
+              "optional": true
+            },
+            ...
+          ],
+          "ssh": [],
+          "locals": []
+        },
+        ...
+      },
+    }
+```
+
+The following fields are included with both `mode=min` and `mode=max`:
+
+- `locals` lists any local sources used in the build, including the build
+  context and frontend file.
+- `frontend` defines type of BuildKit frontend used for the build. Currently,
+  this can be `dockerfile.v0` or `gateway.v0`.
+- `args` defines the build arguments passed to the BuildKit frontend.
+
+  The keys inside the `args` object reflect the options as BuildKit receives
+  them. For example, `build-arg` and `label` prefixes are used for build
+  arguments and labels, and `target` key defines the target stage that was
+  built. The `source` key defines the source image for the Gateway frontend, if
+  used.
+
+The following fields are only included with `mode=max`:
+
+- `secrets` defines secrets used during the build. Note that actual secret
+  values are not included.
+- `ssh` defines the ssh forwards used during the build.
+
+### `buildDefinition.internalParameters.buildConfig`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#internalParameters
+* Only included with `mode=max`.
+
+Defines the build steps performed during the build.
+
+BuildKit internally uses LLB definition to execute the build steps. The LLB
+definition of the build steps is defined in the
+`buildDefinition.internalParameters.buildConfig.llbDefinition` field.
+
+Each LLB step is the JSON definition of the
+[LLB ProtoBuf API](https://github.com/moby/buildkit/blob/v0.10.0/solver/pb/ops.proto).
+The dependencies for a vertex in the LLB graph can be found in the `inputs`
+field for every step.
+
+```json
+    "buildDefinition": {
+      "internalParameters": {
+        "buildConfig": {
+          "llbDefinition": [
+            {
+              "id": "step0",
+              "op": {
+                "Op": {
+                  "exec": {
+                    "meta": {
+                      "args": [
+                        "/bin/sh",
+                        "-c",
+                        "go build ."
+                      ],
+                      "env": [
+                        "PATH=/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
+                        "GOPATH=/go",
+                        "GOFLAGS=-mod=vendor",
+                      ],
+                      "cwd": "/src",
+                    },
+                    "mounts": [...]
+                  }
+                },
+                "platform": {...},
+              },
+              "inputs": [
+                "step8:0",
+                "step2:0",
+              ]
+            },
+            ...
+          ]
+        },
+      }
+    }
+```
+
+### `buildDefinition.internalParameters.builderPlatform`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#internalParameters
+* Included with `mode=min` and `mode=max`.
+
+```json
+    "buildDefinition": {
+      "internalParameters": {
+        "builderPlatform": "linux/amd64"
+        ...
+      },
+    }
+```
+
+BuildKit sets the `builderPlatform` of the build machine. Note that this is not
+necessarily the platform of the build result that can be determined from the
+`in-toto` subject field.
+
+### `buildDefinition.resolvedDependencies`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#resolvedDependencies
+* Included with `mode=min` and `mode=max`.
+
+Defines all the external artifacts that were part of the build. The value
+depends on the type of artifact:
+
+- The URL of Git repositories containing source code for the image
+- HTTP URLs if you are building from a remote tarball, or that was included
+  using an `ADD` command in Dockerfile
+- Any Docker images used during the build
+
+The URLs to the Docker images will be in
+[Package URL](https://github.com/package-url/purl-spec) format.
+
+All the build materials will include the immutable checksum of the artifact.
+When building from a mutable tag, you can use the digest information to
+determine if the artifact has been updated compared to when the build ran.
+
+```json
+    "buildDefinition": {
+      "resolvedDependencies": [
+        {
+          "uri": "pkg:docker/alpine@3.17?platform=linux%2Famd64",
+          "digest": {
+            "sha256": "8914eb54f968791faf6a8638949e480fef81e697984fba772b3976835194c6d4"
+          }
+        },
+        {
+          "uri": "https://github.com/moby/buildkit.git#refs/tags/v0.11.0",
+          "digest": {
+            "sha1": "4b220de5058abfd01ff619c9d2ff6b09a049bea0"
+          }
+        },
+        ...
+      ],
+      ...
+    }
+```
+
+### `runDetails.builder.id`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#builder.id
+* Included with `mode=min` and `mode=max`.
+
+The field is set to the URL of the build, if available.
+
+```json
+    "runDetails": {
+      "builder": {
+        "id": "https://github.com/docker/buildx/actions/runs/3709599520"
+        ...
+      },
+      ...
+    }
+```
+
+> [!NOTE]
+> This value can be set using the `builder-id` attestation parameter.
+
+### `runDetails.metadata.invocationID`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#invocationId
+* Included with `mode=min` and `mode=max`.
+
+Unique identifier for the build invocation. When building a multi-platform image
+with a single build request, this value will be the shared by all the platform
+versions of the image.
+
+```json
+    "runDetails": {
+      "metadata": {
+        "invocationID": "rpv7a389uzil5lqmrgwhijwjz",
+        ...
+      },
+      ...
+    }
+```
+
+### `runDetails.metadata.startedOn`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#startedOn
+* Included with `mode=min` and `mode=max`.
+
+Timestamp when the build started.
+
+```json
+    "runDetails": {
+      "metadata": {
+        "startedOn": "2021-11-17T15:00:00Z",
+        ...
+      },
+      ...
+    }
+```
+
+### `runDetails.metadata.finishedOn`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#finishedOn
+* Included with `mode=min` and `mode=max`.
+
+Timestamp when the build finished.
+
+```json
+    "runDetails": {
+      "metadata": {
+        "finishedOn": "2021-11-17T15:01:00Z",
+        ...
+      },
+    }
+```
+
+### `runDetails.metadata.buildkit_metadata`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#extension-fields
+* Partially included with `mode=min`.
+
+This extension field defines BuildKit-specific additional metadata that is not
+part of the SLSA provenance spec.
+
+```json
+    "runDetails": {
+      "metadata": {
+        "buildkit_metadata": {
+          "source": {...},
+          "layers": {...},
+          "vcs": {...},
+        },
+        ...
+      },
+    }
+```
+
+#### `source`
+
+Only included with `mode=max`.
+
+Defines a source mapping of LLB build steps, defined in the
+`buildDefinition.internalParameters.buildConfig.llbDefinition` field, to their
+original source code (for example, Dockerfile commands). The `source.locations`
+field contains the ranges of all the Dockerfile commands ran in an LLB step.
+`source.infos` array contains the source code itself. This mapping is present
+if the BuildKit frontend provided it when creating the LLB definition.
+
+#### `layers`
+
+Only included with `mode=max`.
+
+Defines the layer mapping of LLB build step mounts defined in
+`buildDefinition.internalParameters.buildConfig.llbDefinition` to the OCI
+descriptors of equivalent layers. This mapping is present if the layer data was
+available, usually when attestation is for an image or if the build step pulled
+in image data as part of the build.
+
+#### `vcs`
 
 Included with `mode=min` and `mode=max`.
 
-The `builder.id` field is set to the URL of the build, if available.
+Defines optional metadata for the version control system used for the build. If
+a build uses a remote context from Git repository, BuildKit extracts the details
+of the version control system automatically and displays it in the
+`buildDefinition.externalParameters.configSource` field. But if the build uses
+a source from a local directory, the VCS information is lost even if the
+directory contained a Git repository. In this case, the build client can send
+additional `vcs:source` and `vcs:revision` build options and BuildKit will add
+them to the provenance attestations as extra metadata. Note that, contrary to
+the `buildDefinition.externalParameters.configSource` field, BuildKit doesn't
+verify the `vcs` values, and as such they can't be trusted and should only be
+used as a metadata hint.
+
+### `runDetails.metadata.buildkit_hermetic`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#extension-fields
+* Included with `mode=min` and `mode=max`.
+
+This extension field is set to true if the build was hermetic and did not access
+the network. In Dockerfiles, a build is hermetic if it does not use `RUN`
+commands or disables network with `--network=none` flag.
+
+```json
+    "runDetails": {
+      "metadata": {
+        "buildkit_hermetic": true,
+        ...
+      },
+    }
+```
+
+### `runDetails.metadata.buildkit_completeness`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#extension-fields
+* Included with `mode=min` and `mode=max`.
+
+This extension field defines if the provenance information is complete. It is
+similar to `metadata.completeness` field in SLSA v0.2.
+
+`buildkit_completeness.request` is true if all the build arguments are included
+in the `buildDefinition.externalParameters.request` field. When building with
+`min` mode, the build arguments are not included in the provenance information
+and request is not complete. Request is also not complete on direct LLB builds
+that did not use a frontend.
+
+`buildkit_completeness.resolvedDependencies` is true if
+`buildDefinition.resolvedDependencies` field includes all the dependencies of
+the build. When building from un-tracked source in a local directory, the
+dependencies are not complete, while when building from a remote Git repository
+all dependencies can be tracked by BuildKit and
+`buildkit_completeness.resolvedDependencies` is true.
+
+```json
+    "runDetails": {
+      "metadata": {
+        "buildkit_completeness": {
+          "request": true,
+          "resolvedDependencies": true
+        },
+        ...
+      },
+    }
+```
+
+### `runDetails.metadata.buildkit_reproducible`
+
+* Ref: https://slsa.dev/spec/v1.1/provenance#extension-fields
+* Included with `mode=min` and `mode=max`.
+
+This extension field defines if the build result is supposed to be byte-by-byte
+reproducible. It is similar to `metadata.reproducible` field in SLSA v0.2. This
+value can be set by the user with the `reproducible=true` attestation parameter. 
+
+```json
+    "runDetails": {
+      "metadata": {
+        "buildkit_reproducible": false,
+        ...
+      },
+    }
+```
+
+## SLSA v0.2
+
+### `builder.id`
+
+* Ref: https://slsa.dev/spec/v0.2/provenance#builder.id
+* Included with `mode=min` and `mode=max`.
+
+The field is set to the URL of the build, if available.
 
 ```json
     "builder": {
@@ -25,26 +439,25 @@ The `builder.id` field is set to the URL of the build, if available.
     },
 ```
 
-This value can be set using the `builder-id` attestation parameter.
-
-## `buildType`
+> [!NOTE]
+> This value can be set using the `builder-id` attestation parameter.
 
-Corresponds to [SLSA `buildType`](https://slsa.dev/provenance/v0.2#buildType).
+### `buildType`
 
-Included with `mode=min` and `mode=max`.
+* Ref: https://slsa.dev/spec/v0.2/provenance#buildType
+* Included with `mode=min` and `mode=max`.
 
-The `buildType` field is set to `https://mobyproject.org/buildkit@v1` can be
+The `buildType` field is set to `https://mobyproject.org/buildkit@v1` and can be
 used to determine the structure of the provenance content.
 
 ```json
     "buildType": "https://mobyproject.org/buildkit@v1",
 ```
 
-## `invocation.configSource`
+### `invocation.configSource`
 
-Corresponds to [SLSA `invocation.configSource`](https://slsa.dev/provenance/v0.2#invocation.configSource).
-
-Included with `mode=min` and `mode=max`.
+* Ref: https://slsa.dev/spec/v0.2/provenance#invocation.configSource
+* Included with `mode=min` and `mode=max`.
 
 Describes the config that initialized the build.
 
@@ -62,15 +475,15 @@ Describes the config that initialized the build.
 ```
 
 For builds initialized from a remote context, like a Git or HTTP URL, this
-object defines the context URL and its immutable digest in the `uri` and `digest` fields.
-For builds using a local frontend, such as a Dockerfile, the `entryPoint` field defines the path
-for the frontend file that initialized the build (`filename` frontend option).
+object defines the context URL and its immutable digest in the `uri` and
+`digest` fields. For builds using a local frontend, such as a Dockerfile, the
+`entryPoint` field defines the path for the frontend file that initialized the
+build (`filename` frontend option).
 
-## `invocation.parameters`
+### `invocation.parameters`
 
-Corresponds to [SLSA `invocation.parameters`](https://slsa.dev/provenance/v0.2#invocation.parameters).
-
-Partially included with `mode=min`.
+* Ref: https://slsa.dev/spec/v0.2/provenance#invocation.parameters
+* Partially included with `mode=min`.
 
 Describes build inputs passed to the build.
 
@@ -118,11 +531,10 @@ The following fields are only included with `mode=max`:
   values are not included.
 - `ssh` defines the ssh forwards used during the build.
 
-## `invocation.environment`
+### `invocation.environment`
 
-Corresponds to [SLSA `invocation.environment`](https://slsa.dev/provenance/v0.2#invocation.environment).
-
-Included with `mode=min` and `mode=max`.
+* Ref: https://slsa.dev/spec/v0.2/provenance#invocation.environment
+* Included with `mode=min` and `mode=max`.
 
 ```json
     "invocation": {
@@ -137,11 +549,10 @@ The only value BuildKit currently sets is the `platform` of the current build
 machine. Note that this is not necessarily the platform of the build result that
 can be determined from the `in-toto` subject field.
 
-## `materials`
-
-Corresponds to [SLSA `materials`](https://slsa.dev/provenance/v0.2#materials).
+### `materials`
 
-Included with `mode=min` and `mode=max`.
+* Ref: https://slsa.dev/spec/v0.2/provenance#materials
+* Included with `mode=min` and `mode=max`.
 
 Defines all the external artifacts that were part of the build. The value
 depends on the type of artifact:
@@ -176,11 +587,10 @@ determine if the artifact has been updated compared to when the build ran.
     ],
 ```
 
-## `buildConfig`
+### `buildConfig`
 
-Corresponds to [SLSA `buildConfig`](https://slsa.dev/provenance/v0.2#buildConfig).
-
-Only included with `mode=max`.
+* Ref: https://slsa.dev/spec/v0.2/provenance#buildConfig
+* Only included with `mode=max`.
 
 Defines the build steps performed during the build.
 
@@ -228,11 +638,10 @@ field for every step.
   },
 ```
 
-## `metadata.buildInvocationId`
+### `metadata.buildInvocationId`
 
-Corresponds to [SLSA `metadata.buildInvocationId`](https://slsa.dev/provenance/v0.2#metadata.buildIncocationId).
-
-Included with `mode=min` and `mode=max`.
+* Ref: https://slsa.dev/spec/v0.2/provenance#buildInvocationId
+* Included with `mode=min` and `mode=max`.
 
 Unique identifier for the build invocation. When building a multi-platform image
 with a single build request, this value will be the shared by all the platform
@@ -245,11 +654,10 @@ versions of the image.
     },
 ```
 
-## `metadata.buildStartedOn`
+### `metadata.buildStartedOn`
 
-Corresponds to [SLSA `metadata.buildStartedOn`](https://slsa.dev/provenance/v0.2#metadata.buildStartedOn).
-
-Included with `mode=min` and `mode=max`.
+* Ref: https://slsa.dev/spec/v0.2/provenance#buildStartedOn
+* Included with `mode=min` and `mode=max`.
 
 Timestamp when the build started.
 
@@ -260,11 +668,10 @@ Timestamp when the build started.
     },
 ```
 
-## `metadata.buildFinishedOn`
-
-Corresponds to [SLSA `metadata.buildFinishedOn`](https://slsa.dev/provenance/v0.2#metadata.buildFinishedOn).
+### `metadata.buildFinishedOn`
 
-Included with `mode=min` and `mode=max`.
+* Ref: https://slsa.dev/spec/v0.2/provenance#buildFinishedOn
+* Included with `mode=min` and `mode=max`.
 
 Timestamp when the build finished.
 
@@ -275,19 +682,18 @@ Timestamp when the build finished.
     },
 ```
 
-## `metadata.completeness`
-
-Corresponds to [SLSA `metadata.completeness`](https://slsa.dev/provenance/v0.2#metadata.completeness).
+### `metadata.completeness`
 
-Included with `mode=min` and `mode=max`.
+* Ref: https://slsa.dev/spec/v0.2/provenance#metadata.completeness
+* Included with `mode=min` and `mode=max`.
 
 Defines if the provenance information is complete.
 
 `completeness.parameters` is true if all the build arguments are included in the
-`invocation.parameters` field. When building with `min` mode, the build
-arguments are not included in the provenance information and parameters are not
-complete. Parameters are also not complete on direct LLB builds that did not use
-a frontend.
+`parameters` field. When building with `min` mode, the build arguments are not
+included in the provenance information and parameters are not complete.
+Parameters are also not complete on direct LLB builds that did not use a
+frontend.
 
 `completeness.environment` is always true for BuildKit builds.
 
@@ -308,9 +714,10 @@ is true.
     },
 ```
 
-## `metadata.reproducible`
+### `metadata.reproducible`
 
-Corresponds to [SLSA `metadata.reproducible`](https://slsa.dev/provenance/v0.2#metadata.reproducible).
+* Ref: https://slsa.dev/spec/v0.2/provenance#metadata.reproducible
+* Included with `mode=min` and `mode=max`.
 
 Defines if the build result is supposed to be byte-by-byte reproducible. This
 value can be set by the user with the `reproducible=true` attestation parameter.
@@ -322,7 +729,7 @@ value can be set by the user with the `reproducible=true` attestation parameter.
     },
 ```
 
-## `metadata.https://mobyproject.org/buildkit@v1#hermetic`
+### `metadata.https://mobyproject.org/buildkit@v1#hermetic`
 
 Included with `mode=min` and `mode=max`.
 
@@ -337,7 +744,7 @@ commands or disables network with `--network=none` flag.
     },
 ```
 
-## `metadata.https://mobyproject.org/buildkit@v1#metadata`
+### `metadata.https://mobyproject.org/buildkit@v1#metadata`
 
 Partially included with `mode=min`.
 
@@ -355,7 +762,7 @@ part of the SLSA provenance spec.
     },
 ```
 
-### `source`
+#### `source`
 
 Only included with `mode=max`.
 
@@ -366,7 +773,7 @@ the Dockerfile commands ran in an LLB step. `source.infos` array contains the
 source code itself. This mapping is present if the BuildKit frontend provided it
 when creating the LLB definition.
 
-### `layers`
+#### `layers`
 
 Only included with `mode=max`.
 
@@ -375,7 +782,7 @@ Defines the layer mapping of LLB build step mounts defined in
 mapping is present if the layer data was available, usually when attestation is
 for an image or if the build step pulled in image data as part of the build.
 
-### `vcs`
+#### `vcs`
 
 Included with `mode=min` and `mode=max`.
 
@@ -389,227 +796,3 @@ repository. In this case, the build client can send additional `vcs:source` and
 attestations as extra metadata. Note that, contrary to the
 `invocation.configSource` field, BuildKit doesn't verify the `vcs` values, and
 as such they can't be trusted and should only be used as a metadata hint.
-
-## Output
-
-To inspect the provenance that was generated and attached to a container image,
-you can use the `docker buildx imagetools` command to inspect the image in a
-registry. Inspecting the attestation displays the format described in the
-[attestation storage specification](./attestation-storage.md).
-
-For example, inspecting a simple Docker image based on `alpine:latest` results
-in a provenance attestation similar to the following, for a `mode=min` build:
-
-```json
-{
-  "_type": "https://in-toto.io/Statement/v0.1",
-  "predicateType": "https://slsa.dev/provenance/v0.2",
-  "subject": [
-    {
-      "name": "pkg:docker/<registry>/<image>@<tag/digest>?platform=<platform>",
-      "digest": {
-        "sha256": "e8275b2b76280af67e26f068e5d585eb905f8dfd2f1918b3229db98133cb4862"
-      }
-    }
-  ],
-  "predicate": {
-    "builder": {
-      "id": ""
-    },
-    "buildType": "https://mobyproject.org/buildkit@v1",
-    "materials": [
-      {
-        "uri": "pkg:docker/alpine@latest?platform=linux%2Famd64",
-        "digest": {
-          "sha256": "8914eb54f968791faf6a8638949e480fef81e697984fba772b3976835194c6d4"
-        }
-      }
-    ],
-    "invocation": {
-      "configSource": {
-        "entryPoint": "Dockerfile"
-      },
-      "parameters": {
-        "frontend": "dockerfile.v0",
-        "args": {},
-        "locals": [
-          {
-            "name": "context"
-          },
-          {
-            "name": "dockerfile"
-          }
-        ]
-      },
-      "environment": {
-        "platform": "linux/amd64"
-      }
-    },
-    "metadata": {
-      "buildInvocationID": "yirbp1aosi1vqjmi3z6bc75nb",
-      "buildStartedOn": "2022-12-08T11:48:59.466513707Z",
-      "buildFinishedOn": "2022-12-08T11:49:01.256820297Z",
-      "reproducible": false,
-      "completeness": {
-        "parameters": true,
-        "environment": true,
-        "materials": false
-      },
-      "https://mobyproject.org/buildkit@v1#metadata": {}
-    }
-  }
-}
-```
-
-For a similar build, but with `mode=max`:
-
-```json
-{
-  "_type": "https://in-toto.io/Statement/v0.1",
-  "predicateType": "https://slsa.dev/provenance/v0.2",
-  "subject": [
-    {
-      "name": "pkg:docker/<registry>/<image>@<tag/digest>?platform=<platform>",
-      "digest": {
-        "sha256": "e8275b2b76280af67e26f068e5d585eb905f8dfd2f1918b3229db98133cb4862"
-      }
-    }
-  ],
-  "predicate": {
-    "builder": {
-      "id": ""
-    },
-    "buildType": "https://mobyproject.org/buildkit@v1",
-    "materials": [
-      {
-        "uri": "pkg:docker/alpine@latest?platform=linux%2Famd64",
-        "digest": {
-          "sha256": "8914eb54f968791faf6a8638949e480fef81e697984fba772b3976835194c6d4"
-        }
-      }
-    ],
-    "invocation": {
-      "configSource": {
-        "entryPoint": "Dockerfile"
-      },
-      "parameters": {
-        "frontend": "dockerfile.v0",
-        "args": {},
-        "locals": [
-          {
-            "name": "context"
-          },
-          {
-            "name": "dockerfile"
-          }
-        ]
-      },
-      "environment": {
-        "platform": "linux/amd64"
-      }
-    },
-    "buildConfig": {
-      "llbDefinition": [
-        {
-          "id": "step0",
-          "op": {
-            "Op": {
-              "source": {
-                "identifier": "docker-image://docker.io/library/alpine:latest@sha256:8914eb54f968791faf6a8638949e480fef81e697984fba772b3976835194c6d4"
-              }
-            },
-            "platform": {
-              "Architecture": "amd64",
-              "OS": "linux"
-            },
-            "constraints": {}
-          }
-        },
-        {
-          "id": "step1",
-          "op": {
-            "Op": null
-          },
-          "inputs": ["step0:0"]
-        }
-      ]
-    },
-    "metadata": {
-      "buildInvocationID": "46ue2x93k3xj5l463dektwldw",
-      "buildStartedOn": "2022-12-08T11:50:54.953375437Z",
-      "buildFinishedOn": "2022-12-08T11:50:55.447841328Z",
-      "reproducible": false,
-      "completeness": {
-        "parameters": true,
-        "environment": true,
-        "materials": false
-      },
-      "https://mobyproject.org/buildkit@v1#metadata": {
-        "source": {
-          "locations": {
-            "step0": {
-              "locations": [
-                {
-                  "ranges": [
-                    {
-                      "start": {
-                        "line": 1
-                      },
-                      "end": {
-                        "line": 1
-                      }
-                    }
-                  ]
-                }
-              ]
-            }
-          },
-          "infos": [
-            {
-              "filename": "Dockerfile",
-              "data": "RlJPTSBhbHBpbmU6bGF0ZXN0Cg==",
-              "llbDefinition": [
-                {
-                  "id": "step0",
-                  "op": {
-                    "Op": {
-                      "source": {
-                        "identifier": "local://dockerfile",
-                        "attrs": {
-                          "local.differ": "none",
-                          "local.followpaths": "[\"Dockerfile\",\"Dockerfile.dockerignore\",\"dockerfile\"]",
-                          "local.session": "q2jnwdkas0i0iu4knchd92jaz",
-                          "local.sharedkeyhint": "dockerfile"
-                        }
-                      }
-                    },
-                    "constraints": {}
-                  }
-                },
-                {
-                  "id": "step1",
-                  "op": {
-                    "Op": null
-                  },
-                  "inputs": ["step0:0"]
-                }
-              ]
-            }
-          ]
-        },
-        "layers": {
-          "step0:0": [
-            [
-              {
-                "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
-                "digest": "sha256:c158987b05517b6f2c5913f3acef1f2182a32345a304fe357e3ace5fadcad715",
-                "size": 3370706
-              }
-            ]
-          ]
-        }
-      }
-    }
-  }
-}
-```
diff --git a/_vendor/github.com/moby/buildkit/docs/buildkitd.toml.md b/_vendor/github.com/moby/buildkit/docs/buildkitd.toml.md
index ec314b9f08ba..6f037544a693 100644
--- a/_vendor/github.com/moby/buildkit/docs/buildkitd.toml.md
+++ b/_vendor/github.com/moby/buildkit/docs/buildkitd.toml.md
@@ -13,19 +13,26 @@ The following is a complete `buildkitd.toml` configuration example.
 Note that some configuration options are only useful in edge cases.
 
 ```toml
-# debug enables additional debug logging
-debug = true
-# trace enables additional trace logging (very verbose, with potential performance impacts)
-trace = true
 # root is where all buildkit state is stored.
 root = "/var/lib/buildkit"
 # insecure-entitlements allows insecure entitlements, disabled by default.
-insecure-entitlements = [ "network.host", "security.insecure" ]
+insecure-entitlements = [ "network.host", "security.insecure", "device" ]
+# proxyNetwork enables proxy network enforcement for all builds, disabled by default.
+# It can also be enabled with buildkitd --proxy-network.
+proxyNetwork = true
+# provenanceEnvDir is the directory where extra config is loaded that is added
+# to the provenance of builds:
+# slsa v0.2: invocation.environment.*
+# slsa v1: buildDefinition.internalParameters.*
+provenanceEnvDir = "/etc/buildkit/provenance.d"
 
 [log]
   # log formatter: json or text
   format = "text"
 
+  # log level (error/warn/info/debug/trace)
+  level = "info"
+
 [dns]
   nameservers=["1.1.1.1","8.8.8.8"]
   options=["edns0"]
@@ -69,7 +76,6 @@ insecure-entitlements = [ "network.host", "security.insecure" ]
   # Whether run subprocesses in main pid namespace or not, this is useful for
   # running rootless buildkit inside a container.
   noProcessSandbox = false
-
   # gc enables/disables garbage collection
   gc = true
   # reservedSpace is the minimum amount of disk space guaranteed to be
@@ -87,7 +93,6 @@ insecure-entitlements = [ "network.host", "security.insecure" ]
   # collector will attempt to leave - however, it will never be bought below
   # reservedSpace.
   minFreeSpace = "20GB"
-
   # alternate OCI worker binary name(example 'crun'), by default either 
   # buildkit-runc or runc binary is used
   binary = ""
@@ -116,7 +121,6 @@ insecure-entitlements = [ "network.host", "security.insecure" ]
     # collector will attempt to leave - however, it will never be bought below
     # reservedSpace.
     minFreeSpace = "10GB"
-
     # keepDuration can be an integer number of seconds (e.g. 172800), or a
     # string duration (e.g. "48h")
     keepDuration = "48h"
@@ -148,7 +152,8 @@ insecure-entitlements = [ "network.host", "security.insecure" ]
   # collector will attempt to leave - however, it will never be bought below
   # reservedSpace.
   minFreeSpace = "20GB"
-
+  # limit the number of parallel build steps that can run at the same time
+  max-parallelism = 4
   # maintain a pool of reusable CNI network namespaces to amortize the overhead
   # of allocating and releasing the namespaces
   cniPoolSize = 16
@@ -176,8 +181,13 @@ insecure-entitlements = [ "network.host", "security.insecure" ]
 [registry."docker.io"]
   # mirror configuration to handle path in case a mirror registry requires a /project path rather than just a host:port
   mirrors = ["yourmirror.local:5000", "core.harbor.domain/proxy.docker.io"]
+  # Use plain HTTP to connect to the mirrors.
   http = true
+  # Use HTTPS with self-signed certificates. Do not enable this together with `http`.
   insecure = true
+  # If you use token auth with self-signed certificates,
+  # then buildctl also needs to trust the token provider CA (for example, certificates that are configured for registry)
+  # because buildctl pulls tokens directly without daemon process
   ca=["/etc/config/myca.pem"]
   [[registry."docker.io".keypair]]
     key="/etc/config/key.pem"
@@ -193,7 +203,6 @@ insecure-entitlements = [ "network.host", "security.insecure" ]
 
 [frontend."gateway.v0"]
   enabled = true
-
   # If allowedRepositories is empty, all gateway sources are allowed.
   # Otherwise, only the listed repositories are allowed as a gateway source.
   # 
@@ -206,5 +215,22 @@ insecure-entitlements = [ "network.host", "security.insecure" ]
 [system]
   # how often buildkit scans for changes in the supported emulated platforms
   platformsCacheMaxAge = "1h"
-
+  # maxRegistryConcurrency sets the maximum number of concurrent connections
+  # per registry. If unset, the default concurrency limit is used.
+  maxRegistryConcurrency = 4
+
+
+# optional signed cache configuration for GitHub Actions backend
+[ghacache.sign]
+# command that signs the payload in stdin and outputs the signature to stdout. Normally you want cosign to produce the signature bytes.
+cmd = ""
+[ghacache.verify]
+required = false
+[ghacache.verify.policy]
+timestampThreshold = 1
+tlogThreshold = 1
+# cetificate properties that need to match. Simple wildcards (*) are supported.
+certificateIssuer = ""
+subjectAlternativeName = ""
+buildSignerURI = ""
 ```
diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/reference.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/reference.md
index 0afa620e2cd2..5a366a1b90e9 100644
--- a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/reference.md
+++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/reference.md
@@ -373,10 +373,16 @@ whitespace, like `${foo}_bar`.
 The `${variable_name}` syntax also supports a few of the standard `bash`
 modifiers as specified below:
 
-- `${variable:-word}` indicates that if `variable` is set then the result
-  will be that value. If `variable` is not set then `word` will be the result.
-- `${variable:+word}` indicates that if `variable` is set then `word` will be
-  the result, otherwise the result is the empty string.
+- `${variable:-word}` indicates that if `variable` is set and non-empty then
+  the result will be that value. If `variable` is unset or empty then `word`
+  will be the result.
+- `${variable-word}` indicates that if `variable` is set (even if empty) then
+  the result will be that value. If `variable` is unset then `word` will be
+  the result.
+- `${variable:+word}` indicates that if `variable` is set and non-empty then
+  `word` will be the result, otherwise the result is the empty string.
+- `${variable+word}` indicates that if `variable` is set (even if empty) then
+  `word` will be the result, otherwise the result is the empty string.
 
 The following variable replacements are supported in a pre-release version of
 Dockerfile syntax, when using the `# syntax=docker/dockerfile-upstream:master` syntax
@@ -568,8 +574,8 @@ You can also use heredocs with the shell form to break up supported commands.
 
 ```dockerfile
 RUN <<EOF
-source $HOME/.bashrc && \
-echo $HOME
+  source $HOME/.bashrc
+  echo $HOME
 EOF
 ```
 
@@ -621,6 +627,20 @@ The image can be any valid image.
   [`COPY --from=<name>`](#copy---from),
   and [`RUN --mount=type=bind,from=<name>`](#run---mounttypebind) instructions
   to refer to the image built in this stage.
+
+  Using a previous build stage as the base for a subsequent stage is a common
+  pattern for sharing a common base environment:
+
+  ```dockerfile
+  FROM ubuntu AS base
+  RUN apt-get update && apt-get install -y shared-tooling
+
+  FROM base AS dev
+  RUN apt-get install -y dev-tooling
+
+  FROM base AS prod
+  COPY --from=build /app /app
+  ```
 - The `tag` or `digest` values are optional. If you omit either of them, the
   builder assumes a `latest` tag by default. The builder returns an error if it
   can't find the `tag` value.
@@ -689,10 +709,11 @@ EOF
 The available `[OPTIONS]` for the `RUN` instruction are:
 
 | Option                          | Minimum Dockerfile version |
-| ------------------------------- | -------------------------- |
+|---------------------------------|----------------------------|
+| [`--device`](#run---device)     | 1.14-labs                  |
 | [`--mount`](#run---mount)       | 1.2                        |
 | [`--network`](#run---network)   | 1.3                        |
-| [`--security`](#run---security) | 1.1.2-labs                 |
+| [`--security`](#run---security) | 1.20                       |
 
 ### Cache invalidation for RUN instructions
 
@@ -707,6 +728,103 @@ guide](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practi
 
 The cache for `RUN` instructions can be invalidated by [`ADD`](#add) and [`COPY`](#copy) instructions.
 
+### RUN --device
+
+> [!NOTE]
+> Not yet available in stable syntax, use [`docker/dockerfile:1-labs`](#syntax)
+> version. It also needs BuildKit 0.20.0 or later.
+
+```dockerfile
+RUN --device=name,[required]
+```
+
+`RUN --device` allows build to request [CDI devices](https://github.com/moby/buildkit/blob/master/docs/cdi.md)
+to be available to the build step.
+
+> [!WARNING]
+> The use of `--device` is protected by the `device` entitlement, which needs
+> to be enabled when starting the buildkitd daemon with
+> `--allow-insecure-entitlement device` flag or in [buildkitd config](https://github.com/moby/buildkit/blob/master/docs/buildkitd.toml.md),
+> and for a build request with [`--allow device` flag](https://docs.docker.com/engine/reference/commandline/buildx_build/#allow).
+
+The device `name` is provided by the CDI specification registered in BuildKit.
+
+In the following example, multiple devices are registered in the CDI
+specification for the `vendor1.com/device` vendor.
+
+```yaml
+cdiVersion: "0.6.0"
+kind: "vendor1.com/device"
+devices:
+  - name: foo
+    containerEdits:
+      env:
+        - FOO=injected
+  - name: bar
+    annotations:
+      org.mobyproject.buildkit.device.class: class1
+    containerEdits:
+      env:
+        - BAR=injected
+  - name: baz
+    annotations:
+      org.mobyproject.buildkit.device.class: class1
+    containerEdits:
+      env:
+        - BAZ=injected
+  - name: qux
+    annotations:
+      org.mobyproject.buildkit.device.class: class2
+    containerEdits:
+      env:
+        - QUX=injected
+annotations:
+  org.mobyproject.buildkit.device.autoallow: true
+```
+
+The device name format is flexible and accepts various patterns to support
+multiple device configurations:
+
+* `vendor1.com/device`: request the first device found for this vendor
+* `vendor1.com/device=foo`: request a specific device
+* `vendor1.com/device=*`: request all devices for this vendor
+* `class1`: request devices by `org.mobyproject.buildkit.device.class` annotation
+
+> [!NOTE]
+> Annotations are supported by the CDI specification since 0.6.0.
+
+> [!NOTE]
+> To automatically allow all devices registered in the CDI specification, you
+> can set the `org.mobyproject.buildkit.device.autoallow` annotation. You can
+> also set this annotation for a specific device.
+
+#### Example: CUDA-Powered LLaMA Inference
+
+In this example we use the `--device` flag to run `llama.cpp` inference using
+an NVIDIA GPU device through CDI:
+
+```dockerfile
+# syntax=docker/dockerfile:1-labs
+
+FROM scratch AS model
+ADD https://huggingface.co/bartowski/Llama-3.2-1B-Instruct-GGUF/resolve/main/Llama-3.2-1B-Instruct-Q4_K_M.gguf /model.gguf
+
+FROM scratch AS prompt
+COPY <<EOF prompt.txt
+Q: Generate  a list of 10 unique biggest countries by population in JSON with their estimated poulation in 1900 and 2024. Answer only newline formatted JSON with keys "country", "population_1900", "population_2024" with 10 items.
+A:
+[
+    {
+
+EOF
+
+FROM ghcr.io/ggml-org/llama.cpp:full-cuda-b5124
+RUN --device=nvidia.com/gpu=all \
+    --mount=from=model,target=/models \
+    --mount=from=prompt,target=/tmp \
+    ./llama-cli -m /models/model.gguf -no-cnv -ngl 99 -f /tmp/prompt.txt
+```
+
 ### RUN --mount
 
 ```dockerfile
@@ -735,12 +853,13 @@ The supported mount types are:
 This mount type allows binding files or directories to the build container. A
 bind mount is read-only by default.
 
-| Option                             | Description                                                                                    |
-| ---------------------------------- | ---------------------------------------------------------------------------------------------- |
-| `target`, `dst`, `destination`[^1] | Mount path.                                                                                    |
-| `source`                           | Source path in the `from`. Defaults to the root of the `from`.                                 |
-| `from`                             | Build stage, context, or image name for the root of the source. Defaults to the build context. |
-| `rw`,`readwrite`                   | Allow writes on the mount. Written data will be discarded.                                     |
+| Option                             | Description                                                                                                                                   |
+| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
+| `target`, `dst`, `destination`[^1] | Mount path.                                                                                                                                   |
+| `source`                           | Source path in the `from`. Defaults to the root of the `from`.                                                                                |
+| `from`                             | Build stage, context, or image name for the root of the source. Defaults to the build context.                                                |
+| `rw`,`readwrite`                   | Allow writes on the mount. Written data will be discarded after the `RUN` instruction completes and will not be committed to the image layer. |
+
 
 ### RUN --mount=type=cache
 
@@ -782,7 +901,7 @@ FROM ubuntu
 RUN rm -f /etc/apt/apt.conf.d/docker-clean; echo 'Binary::apt::APT::Keep-Downloaded-Packages "true";' > /etc/apt/apt.conf.d/keep-cache
 RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
   --mount=type=cache,target=/var/lib/apt,sharing=locked \
-  apt update && apt-get --no-install-recommends install -y gcc
+  apt-get update && apt-get --no-install-recommends install -y gcc
 ```
 
 Apt needs exclusive access to its data, so the caches use the option
@@ -941,9 +1060,6 @@ The command is run in the host's network environment (similar to
 
 ### RUN --security
 
-> [!NOTE]
-> Not yet available in stable syntax, use [`docker/dockerfile:1-labs`](#syntax) version.
-
 ```dockerfile
 RUN --security=<sandbox|insecure>
 ```
@@ -964,7 +1080,7 @@ Default sandbox mode can be activated via `--security=sandbox`, but that is no-o
 #### Example: check entitlements
 
 ```dockerfile
-# syntax=docker/dockerfile:1-labs
+# syntax=docker/dockerfile:1
 FROM ubuntu
 RUN --security=insecure cat /proc/self/status | grep CapEff
 ```
@@ -1049,6 +1165,13 @@ Labels included in base images (images in the `FROM` line) are inherited by
 your image. If a label already exists but with a different value, the
 most-recently-applied value overrides any previously-set value.
 
+In a multi-stage build, labels from intermediate stages are only present in
+the final image if the final stage is directly or indirectly based on them
+(via `FROM`). Labels from a stage that you only reference with
+`COPY --from` or `RUN --mount=from=` are not included in the output image.
+Labels from the base image specified in the final `FROM` instruction are
+always inherited.
+
 To view an image's labels, use the `docker image inspect` command. You can use
 the `--format` option to show just the labels;
 
@@ -1227,10 +1350,11 @@ The available `[OPTIONS]` are:
 | --------------------------------------- | -------------------------- |
 | [`--keep-git-dir`](#add---keep-git-dir) | 1.1                        |
 | [`--checksum`](#add---checksum)         | 1.6                        |
-| [`--chown`](#add---chown---chmod)       |                            |
-| [`--chmod`](#add---chown---chmod)       | 1.2                        |
+| [`--chmod`](#add---chmod)               | 1.2                        |
+| [`--chown`](#add---chown)               |                            |
 | [`--link`](#add---link)                 | 1.4                        |
-| [`--exclude`](#add---exclude)           | 1.7-labs                   |
+| [`--unpack`](#add---unpack)             | 1.17                       |
+| [`--exclude`](#add---exclude)           | 1.19                       |
 
 The `ADD` instruction copies new files or directories from `<src>` and adds
 them to the filesystem of the image at the path `<dest>`. Files and directories
@@ -1336,9 +1460,8 @@ ADD arr[[]0].txt /dest/
 
 When using a local tar archive as the source for `ADD`, and the archive is in a
 recognized compression format (`gzip`, `bzip2` or `xz`, or uncompressed), the
-archive is decompressed and extracted into the specified destination. Only
-local tar archives are extracted. If the tar archive is a remote URL, the
-archive is not extracted, but downloaded and placed at the destination.
+archive is decompressed and extracted into the specified destination. Local tar
+archives are extracted by default, see the [`ADD --unpack` flag].
 
 When a directory is extracted, it has the same behavior as `tar -x`.
 The result is the union of:
@@ -1363,6 +1486,9 @@ file. However, like any other file processed during an `ADD`, `mtime` isn't
 included in the determination of whether or not the file has changed and the
 cache should be updated.
 
+If remote file is a tar archive, the archive is not extracted by default. To
+download and extract the archive, use the [`ADD --unpack` flag].
+
 If the destination ends with a trailing slash, then the filename is inferred
 from the URL path. For example, `ADD http://example.com/foobar /` would create
 the file `/foobar`. The URL must have a nontrivial path so that an appropriate
@@ -1376,6 +1502,12 @@ If your URL files are protected using authentication, you need to use `RUN wget`
 `RUN curl` or use another tool from within the container as the `ADD` instruction
 doesn't support authentication.
 
+##### Secrets
+
+You can use the `HTTP_AUTH_HEADER_<host>` and `HTTP_AUTH_TOKEN_<host>` secrets
+to set credentials for remote sources. For more information, see
+[Build secrets](https://docs.docker.com/build/building/secrets/#http-authentication-for-add).
+
 #### Adding files from a Git repository
 
 To use a Git repository as the source for `ADD`, you can reference the
@@ -1475,24 +1607,51 @@ ADD --keep-git-dir=true https://github.com/moby/buildkit.git#v0.10.1 /buildkit
 ADD [--checksum=<hash>] <src> ... <dir>
 ```
 
-The `--checksum` flag lets you verify the checksum of a remote resource. The
-checksum is formatted as `sha256:<hash>`. SHA-256 is the only supported hash
-algorithm.
+The `--checksum` flag lets you verify the checksum of a remote Git or HTTP
+resource:
+
+- For Git sources, the checksum is the commit SHA. It can be the full commit
+  SHA or match on the prefix (1 or more characters).
+- For HTTP sources, the checksum is the SHA-256 content digest, formatted as
+  `sha256:<hash>`. SHA-256 is the only supported hash algorithm.
 
 ```dockerfile
+ADD --checksum=be1f38e https://github.com/moby/buildkit.git#v0.26.2 /
 ADD --checksum=sha256:24454f830cdb571e2c4ad15481119c43b3cafd48dd869a9b2945d1036d1dc68d https://mirrors.edge.kernel.org/pub/linux/kernel/Historic/linux-0.01.tar.gz /
 ```
 
-The `--checksum` flag only supports HTTP(S) sources.
+### ADD --chmod
 
-### ADD --chown --chmod
+See [`COPY --chmod`](#copy---chmod).
 
-See [`COPY --chown --chmod`](#copy---chown---chmod).
+### ADD --chown
+
+See [`COPY --chown`](#copy---chown).
 
 ### ADD --link
 
 See [`COPY --link`](#copy---link).
 
+### ADD --unpack
+
+```dockerfile
+ADD [--unpack=<bool>] <src> ... <dir>
+```
+
+The `--unpack` flag controls whether or not to automatically unpack tar
+archives (including compressed formats like `gzip` or `bzip2`) when adding them
+to the image. Local tar archives are unpacked by default, whereas remote tar
+archives (where `src` is a URL) are downloaded without unpacking.
+
+```dockerfile
+# syntax=docker/dockerfile:1
+FROM alpine
+# Download and unpack archive.tar.gz into /download:
+ADD --unpack=true https://example.com/archive.tar.gz /download
+# Add local tar without unpacking:
+ADD --unpack=false my-archive.tar.gz .
+```
+
 ### ADD --exclude
 
 See [`COPY --exclude`](#copy---exclude).
@@ -1512,11 +1671,11 @@ The available `[OPTIONS]` are:
 | Option                             | Minimum Dockerfile version |
 | ---------------------------------- | -------------------------- |
 | [`--from`](#copy---from)           |                            |
-| [`--chown`](#copy---chown---chmod) |                            |
-| [`--chmod`](#copy---chown---chmod) | 1.2                        |
+| [`--chmod`](#copy---chmod)         | 1.2                        |
+| [`--chown`](#copy---chown)         |                            |
 | [`--link`](#copy---link)           | 1.4                        |
-| [`--parents`](#copy---parents)     | 1.7-labs                   |
-| [`--exclude`](#copy---exclude)     | 1.7-labs                   |
+| [`--parents`](#copy---parents)     | 1.20                       |
+| [`--exclude`](#copy---exclude)     | 1.19                       |
 
 The `COPY` instruction copies new files or directories from `<src>` and adds
 them to the filesystem of the image at the path `<dest>`. Files and directories
@@ -1683,32 +1842,52 @@ COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf
 The source path of `COPY --from` is always resolved from filesystem root of the
 image or stage that you specify.
 
-### COPY --chown --chmod
+### COPY --chmod
 
-> [!NOTE]
-> Only octal notation is currently supported. Non-octal support is tracked in
-> [moby/buildkit#1951](https://github.com/moby/buildkit/issues/1951).
+```dockerfile
+COPY [--chmod=<perms>] <src> ... <dest>
+```
+
+The `--chmod` flag supports octal notation (e.g., `755`, `644`) and symbolic
+notation (e.g., `+x`, `g=u`). Symbolic notation (added in Dockerfile version 1.14)
+is useful when octal isn't flexible enough. For example, `u=rwX,go=rX` sets
+directories to 755 and files to 644, while preserving the executable bit on files
+that already have it. (Capital `X` means "executable only if it's a directory or
+already executable.")
+
+For more information about symbolic notation syntax, see the
+[chmod(1) manual](https://man.freebsd.org/cgi/man.cgi?chmod).
+
+Examples using octal notation:
+
+```dockerfile
+COPY --chmod=755 app.sh /app/
+COPY --chmod=644 file.txt /data/
+ARG MODE=440
+COPY --chmod=$MODE . .
+```
+
+Examples using symbolic notation:
+
+```dockerfile
+COPY --chmod=+x script.sh /app/
+COPY --chmod=u=rwX,go=rX . /app/
+COPY --chmod=g=u config/ /config/
+```
+
+The `--chmod` flag is not supported when building Windows containers.
+
+### COPY --chown
 
 ```dockerfile
-COPY [--chown=<user>:<group>] [--chmod=<perms> ...] <src> ... <dest>
+COPY [--chown=<user>:<group>] <src> ... <dest>
 ```
 
-The `--chown` and `--chmod` features are only supported on Dockerfiles used to build Linux containers,
-and doesn't work on Windows containers. Since user and group ownership concepts do
-not translate between Linux and Windows, the use of `/etc/passwd` and `/etc/group` for
-translating user and group names to IDs restricts this feature to only be viable for
-Linux OS-based containers.
+Sets ownership of copied files. Without this flag, files are created with UID
+and GID of 0.
 
-All files and directories copied from the build context are created with a UID and GID of `0` unless the
-optional `--chown` flag specifies a given username, groupname, or UID/GID
-combination to request specific ownership of the copied content. The
-format of the `--chown` flag allows for either username and groupname strings
-or direct integer UID and GID in any combination. Providing a username without
-groupname or a UID without GID will use the same numeric UID as the GID. If a
-username or groupname is provided, the container's root filesystem
-`/etc/passwd` and `/etc/group` files will be used to perform the translation
-from name to integer UID or GID respectively. The following examples show
-valid definitions for the `--chown` flag:
+The flag accepts usernames, group names, UIDs, or GIDs in any combination.
+If you specify only a user, the GID is set to the same numeric value as the UID.
 
 ```dockerfile
 COPY --chown=55:mygroup files* /somedir/
@@ -1718,22 +1897,12 @@ COPY --chown=10:11 files* /somedir/
 COPY --chown=myuser:mygroup --chmod=644 files* /somedir/
 ```
 
-If the container root filesystem doesn't contain either `/etc/passwd` or
-`/etc/group` files and either user or group names are used in the `--chown`
-flag, the build will fail on the `COPY` operation. Using numeric IDs requires
-no lookup and does not depend on container root filesystem content.
+When using names instead of numeric IDs, BuildKit resolves them using
+`/etc/passwd` and `/etc/group` in the container's root filesystem. If these
+files are missing or don't contain the specified names, the build fails.
+Numeric IDs don't require this lookup.
 
-With the Dockerfile syntax version 1.10.0 and later,
-the `--chmod` flag supports variable interpolation,
-which lets you define the permission bits using build arguments:
-
-```dockerfile
-# syntax=docker/dockerfile:1.10
-FROM alpine
-WORKDIR /src
-ARG MODE=440
-COPY --chmod=$MODE . .
-```
+The `--chown` flag is not supported when building Windows containers.
 
 ### COPY --link
 
@@ -1804,10 +1973,14 @@ path, using `--link` is always recommended. The performance of `--link` is
 equivalent or better than the default behavior and, it creates much better
 conditions for cache reuse.
 
-### COPY --parents
+When copying a path into a subdirectory, `--link` will always copy from the
+root of the filesystem. When copying a directory, the existing mode is
+overridden with the new mode from the copied path. If you need a specific mode
+for a directory, such as the more permissive `/tmp` directory, you may need to
+either avoid using `--link`, unroll the copy into its base components, or use
+`--chmod` to ensure the overwriting directory contains the same permissions.
 
-> [!NOTE]
-> Not yet available in stable syntax, use [`docker/dockerfile:1.7-labs`](#syntax) version.
+### COPY --parents
 
 ```dockerfile
 COPY [--parents[=<boolean>]] <src> ... <dest>
@@ -1816,7 +1989,7 @@ COPY [--parents[=<boolean>]] <src> ... <dest>
 The `--parents` flag preserves parent directories for `src` entries. This flag defaults to `false`.
 
 ```dockerfile
-# syntax=docker/dockerfile:1-labs
+# syntax=docker/dockerfile:1
 FROM scratch
 
 COPY ./x/a.txt ./y/a.txt /no_parents/
@@ -1836,7 +2009,7 @@ directories after it will be preserved. This may be especially useful copies bet
 with `--from` where the source paths need to be absolute.
 
 ```dockerfile
-# syntax=docker/dockerfile:1-labs
+# syntax=docker/dockerfile:1
 FROM scratch
 
 COPY --parents ./x/./y/*.txt /parents/
@@ -1850,6 +2023,26 @@ COPY --parents ./x/./y/*.txt /parents/
 # /parents/y/b.txt
 ```
 
+The `**` wildcard matches any number of path components, including none, and
+can be used to recursively match files across directory levels:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+FROM scratch
+
+COPY --parents ./src/**/*.txt /parents/
+
+# Build context:
+# ./src/a.txt
+# ./src/x/b.txt
+# ./src/x/y/c.txt
+#
+# Output:
+# /parents/src/a.txt
+# /parents/src/x/b.txt
+# /parents/src/x/y/c.txt
+```
+
 Note that, without the `--parents` flag specified, any filename collision will
 fail the Linux `cp` operation with an explicit error message
 (`cp: will not overwrite just-created './x/a.txt' with './y/a.txt'`), where the
@@ -1863,9 +2056,6 @@ with the `--parents` flag, the Buildkit is capable of packing multiple
 
 ### COPY --exclude
 
-> [!NOTE]
-> Not yet available in stable syntax, use [`docker/dockerfile:1.7-labs`](#syntax) version.
-
 ```dockerfile
 COPY [--exclude=<path> ...] <src> ... <dest>
 ```
@@ -1878,19 +2068,19 @@ supporting wildcards and matching using Go's
 For example, to add all files starting with "hom", excluding files with a `.txt` extension:
 
 ```dockerfile
-# syntax=docker/dockerfile:1-labs
+# syntax=docker/dockerfile:1
 FROM scratch
 
 COPY --exclude=*.txt hom* /mydir/
 ```
 
 You can specify the `--exclude` option multiple times for a `COPY` instruction.
-Multiple `--excludes` are files matching its patterns not to be copied,
-even if the files paths match the pattern specified in `<src>`.
+Files matching any of the specified `--exclude` patterns are not copied,
+even if their paths match the pattern specified in `<src>`.
 To add all files starting with "hom", excluding files with either `.txt` or `.md` extensions:
 
 ```dockerfile
-# syntax=docker/dockerfile:1-labs
+# syntax=docker/dockerfile:1
 FROM scratch
 
 COPY --exclude=*.txt --exclude=*.md hom* /mydir/
@@ -1931,8 +2121,8 @@ This allows arguments to be passed to the entry point, i.e., `docker run
 <image> -d` will pass the `-d` argument to the entry point. You can override
 the `ENTRYPOINT` instruction using the `docker run --entrypoint` flag.
 
-The shell form of `ENTRYPOINT` prevents any `CMD` command line arguments from
-being used. It also starts your `ENTRYPOINT` as a subcommand of `/bin/sh -c`,
+The shell form of `ENTRYPOINT` ignores any `CMD` or `docker run` command line
+arguments. It also starts your `ENTRYPOINT` as a subcommand of `/bin/sh -c`,
 which does not pass signals. This means that the executable will not be the
 container's `PID 1`, and will not receive Unix signals. In this case, your
 executable doesn't receive a `SIGTERM` from `docker stop <container>`.
@@ -1942,8 +2132,14 @@ Only the last `ENTRYPOINT` instruction in the Dockerfile will have an effect.
 ### Exec form ENTRYPOINT example
 
 You can use the exec form of `ENTRYPOINT` to set fairly stable default commands
-and arguments and then use either form of `CMD` to set additional defaults that
-are more likely to be changed.
+and arguments and then use `CMD` to set additional defaults that are more
+likely to be changed.
+
+When combining exec form `ENTRYPOINT` with `CMD`, use the exec form of `CMD`
+as well. Using the shell form of `CMD` causes it to be wrapped in
+`/bin/sh -c`, which means the `ENTRYPOINT` receives a shell invocation as its
+argument rather than the bare command and parameters. See
+[Understand how CMD and ENTRYPOINT interact](#understand-how-cmd-and-entrypoint-interact).
 
 ```dockerfile
 FROM ubuntu
@@ -2247,7 +2443,7 @@ USER <UID>[:<GID>]
 The `USER` instruction sets the user name (or UID) and optionally the user
 group (or GID) to use as the default user and group for the remainder of the
 current stage. The specified user is used for `RUN` instructions and at
-runtime, runs the relevant `ENTRYPOINT` and `CMD` commands.
+runtime runs the relevant `ENTRYPOINT` and `CMD` commands.
 
 > Note that when specifying a group for the user, the user will have _only_ the
 > specified group membership. Any other configured group memberships will be ignored.
@@ -2315,9 +2511,15 @@ Therefore, to avoid unintended operations in unknown directories, it's best prac
 ARG <name>[=<default value>] [<name>[=<default value>]...]
 ```
 
-The `ARG` instruction defines a variable that users can pass at build-time to
+The `ARG` instruction defines a variable that users can pass at build time to
 the builder with the `docker build` command using the `--build-arg <varname>=<value>`
-flag.
+flag. This variable can be used in subsequent instructions such as `FROM`, `ENV`,
+`WORKDIR`, and others using the `${VAR}` or `$VAR` template syntax.
+It is also passed to all subsequent `RUN` instructions as a build-time
+environment variable.
+
+Unlike `ENV`, an `ARG` variable is not embedded in the image and is not available
+in the final container.
 
 > [!WARNING]
 > It isn't recommended to use build arguments for passing secrets such as
@@ -2526,15 +2728,16 @@ RUN echo "I'm building for $TARGETPLATFORM"
 
 ### BuildKit built-in build args
 
-| Arg                             | Type   | Description                                                                                                                                                                                       |
-| ------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `BUILDKIT_CACHE_MOUNT_NS`       | String | Set optional cache ID namespace.                                                                                                                                                                  |
-| `BUILDKIT_CONTEXT_KEEP_GIT_DIR` | Bool   | Trigger Git context to keep the `.git` directory.                                                                                                                                                 |
-| `BUILDKIT_INLINE_CACHE`[^2]     | Bool   | Inline cache metadata to image config or not.                                                                                                                                                     |
-| `BUILDKIT_MULTI_PLATFORM`       | Bool   | Opt into deterministic output regardless of multi-platform output or not.                                                                                                                         |
-| `BUILDKIT_SANDBOX_HOSTNAME`     | String | Set the hostname (default `buildkitsandbox`)                                                                                                                                                      |
-| `BUILDKIT_SYNTAX`               | String | Set frontend image                                                                                                                                                                                |
-| `SOURCE_DATE_EPOCH`             | Int    | Set the Unix timestamp for created image and layers. More info from [reproducible builds](https://reproducible-builds.org/docs/source-date-epoch/). Supported since Dockerfile 1.5, BuildKit 0.11 |
+| Arg                             | Type   | Description                                                                                                                                                                                                      |
+|---------------------------------|--------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `BUILDKIT_BUILD_NAME`           | String | Override the build name shown in [`buildx history` command](https://docs.docker.com/reference/cli/docker/buildx/history/) and [Docker Desktop Builds view](https://docs.docker.com/desktop/use-desktop/builds/). |
+| `BUILDKIT_CACHE_MOUNT_NS`       | String | Set optional cache ID namespace.                                                                                                                                                                                 |
+| `BUILDKIT_CONTEXT_KEEP_GIT_DIR` | Bool   | Trigger Git context to keep the `.git` directory.                                                                                                                                                                |
+| `BUILDKIT_INLINE_CACHE`[^2]     | Bool   | Inline cache metadata to image config or not.                                                                                                                                                                    |
+| `BUILDKIT_MULTI_PLATFORM`       | Bool   | Opt into deterministic output regardless of multi-platform output or not.                                                                                                                                        |
+| `BUILDKIT_SANDBOX_HOSTNAME`     | String | Set the hostname (default `buildkitsandbox`)                                                                                                                                                                     |
+| `BUILDKIT_SYNTAX`               | String | Set frontend image. Set to `dockerfile.v0` to ignore the Dockerfile `# syntax=` directive and use the built-in frontend instead.                                                                                 |
+| `SOURCE_DATE_EPOCH`             | Int    | Set the Unix timestamp for created image and layers. More info from [reproducible builds](https://reproducible-builds.org/docs/source-date-epoch/). Supported since Dockerfile 1.5, BuildKit 0.11                |
 
 #### Example: keep `.git` dir
 
@@ -2700,6 +2903,11 @@ for instance `SIGKILL`, or an unsigned number that matches a position in the
 kernel's syscall table, for instance `9`. The default is `SIGTERM` if not
 defined.
 
+`STOPSIGNAL` applies to the signal sent by `docker stop` (and by the Docker
+daemon when stopping a container). It does not affect signals sent by keyboard
+shortcuts such as Ctrl+C, which sends `SIGINT` directly to the process
+regardless of the `STOPSIGNAL` setting.
+
 The image's default stopsignal can be overridden per container, using the
 `--stop-signal` flag on `docker run` and `docker create`.
 
@@ -2730,9 +2938,12 @@ The options that can appear before `CMD` are:
 
 The health check will first run **interval** seconds after the container is
 started, and then again **interval** seconds after each previous check completes.
+During the **start period**, health checks run at **start interval** frequency
+instead.
 
 If a single run of the check takes longer than **timeout** seconds then the check
-is considered to have failed.
+is considered to have failed. The process performing the check is abruptly stopped
+with a `SIGKILL`.
 
 It takes **retries** consecutive failures of the health check for the container
 to be considered `unhealthy`.
diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md
index 0938ace3dfe8..2060cc6db45e 100644
--- a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md
+++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md
@@ -100,12 +100,20 @@ To learn more about how to use build checks, see
       <td>FROM --platform flag should not use a constant value</td>
     </tr>
     <tr>
-      <td><a href="./copy-ignored-file/">CopyIgnoredFile (experimental)</a></td>
+      <td><a href="./copy-ignored-file/">CopyIgnoredFile</a></td>
       <td>Attempting to Copy file that is excluded by .dockerignore</td>
     </tr>
     <tr>
       <td><a href="./invalid-definition-description/">InvalidDefinitionDescription (experimental)</a></td>
       <td>Comment for build stage or argument should follow the format: `# <arg/stage name> <description>`. If this is not intended to be a description comment, add an empty line or comment between the instruction and the comment.</td>
     </tr>
+    <tr>
+      <td><a href="./expose-proto-casing/">ExposeProtoCasing</a></td>
+      <td>Protocol in EXPOSE instruction should be lowercase</td>
+    </tr>
+    <tr>
+      <td><a href="./expose-invalid-format/">ExposeInvalidFormat</a></td>
+      <td>IP address and host-port mapping should not be used in EXPOSE instruction. This will become an error in a future release</td>
+    </tr>
   </tbody>
 </table>
diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md
index 3e8e57e8d4c5..535da0be6375 100644
--- a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md
+++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/copy-ignored-file.md
@@ -6,10 +6,6 @@ aliases:
   - /go/dockerfile/rule/copy-ignored-file/
 ---
 
-> [!NOTE]
-> This check is experimental and is not enabled by default. To enable it, see
-> [Experimental checks](https://docs.docker.com/go/build-checks-experimental/).
-
 ## Output
 
 ```text
diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md
new file mode 100644
index 000000000000..9198178f3305
--- /dev/null
+++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-invalid-format.md
@@ -0,0 +1,55 @@
+---
+title: ExposeInvalidFormat
+description: >-
+  IP address and host-port mapping should not be used in EXPOSE instruction. This will become an error in a future release
+aliases:
+  - /go/dockerfile/rule/expose-invalid-format/
+---
+
+## Output
+
+```text
+EXPOSE instruction should not define an IP address or host-port mapping, found '127.0.0.1:80:80'
+```
+
+## Description
+
+The [`EXPOSE`](https://docs.docker.com/reference/dockerfile/#expose) instruction
+in a Dockerfile is used to indicate which ports the container listens on at
+runtime. It should not include an IP address or host-port mapping, as this is
+not the intended use of the `EXPOSE` instruction. Instead, it should only
+specify the port number and optionally the protocol (TCP or UDP).
+
+> [!IMPORTANT]
+> This will become an error in a future release.
+
+## Examples
+
+❌ Bad: IP address and host-port mapping used.
+
+```dockerfile
+FROM alpine
+EXPOSE 127.0.0.1:80:80
+```
+
+✅ Good: only the port number is specified.
+
+```dockerfile
+FROM alpine
+EXPOSE 80
+```
+
+❌ Bad: Host-port mapping used.
+
+```dockerfile
+FROM alpine
+EXPOSE 80:80
+```
+
+✅ Good: only the port number is specified.
+
+```dockerfile
+FROM alpine
+EXPOSE 80
+```
+
diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md
new file mode 100644
index 000000000000..cfde7fe322ec
--- /dev/null
+++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/expose-proto-casing.md
@@ -0,0 +1,37 @@
+---
+title: ExposeProtoCasing
+description: >-
+  Protocol in EXPOSE instruction should be lowercase
+aliases:
+  - /go/dockerfile/rule/expose-proto-casing/
+---
+
+## Output
+
+```text
+Defined protocol '80/TcP' in EXPOSE instruction should be lowercase
+```
+
+## Description
+
+Protocol names in the [`EXPOSE`](https://docs.docker.com/reference/dockerfile/#expose)
+instruction should be specified in lowercase to maintain consistency and
+readability. This rule checks for protocols that are not in lowercase and
+reports them.
+
+## Examples
+
+❌ Bad: protocol is not in lowercase.
+
+```dockerfile
+FROM alpine
+EXPOSE 80/TcP
+```
+
+✅ Good: protocol is in lowercase.
+
+```dockerfile
+FROM alpine
+EXPOSE 80/tcp
+```
+
diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md
index dc43b53cb736..471b0d6ea4b5 100644
--- a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md
+++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md
@@ -55,3 +55,18 @@ ENV DEPS="\
     make"
 ```
 
+> [!NOTE]
+> Be aware of leading whitespace when converting multi-line legacy syntax to
+> the modern `key=value` format. In the legacy format, leading whitespace on
+> continuation lines is included in the value. In the modern format with
+> quoted values, leading whitespace inside the quotes is also preserved. If
+> you don't want leading whitespace in the value, make sure to remove it when
+> rewriting to the new format:
+>
+> ```dockerfile
+> ENV DEPS="\
+> curl \
+> git \
+> make"
+> ```
+
diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md
index db9d1caae671..1184d089eb52 100644
--- a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md
+++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/secrets-used-in-arg-or-env.md
@@ -28,10 +28,27 @@ See [Build secrets](https://docs.docker.com/build/building/secrets/).
 
 ## Examples
 
-❌ Bad: `AWS_SECRET_ACCESS_KEY` is a secret value.
+❌ Bad: using ARG to pass AWS credentials.
 
 ```dockerfile
-FROM scratch
+ARG AWS_ACCESS_KEY_ID
 ARG AWS_SECRET_ACCESS_KEY
+RUN aws s3 cp s3://my-bucket/file .
+```
+
+✅ Good: using secret mounts with environment variables.
+
+```dockerfile
+RUN --mount=type=secret,id=aws_key_id,env=AWS_ACCESS_KEY_ID \
+    --mount=type=secret,id=aws_secret_key,env=AWS_SECRET_ACCESS_KEY \
+    aws s3 cp s3://my-bucket/file .
+```
+
+To build with these secrets:
+
+```console
+$ docker buildx build \
+    --secret id=aws_key_id,env=AWS_ACCESS_KEY_ID \
+    --secret id=aws_secret_key,env=AWS_SECRET_ACCESS_KEY .
 ```
 
diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md
index 06043ea15a09..396be3e27134 100644
--- a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md
+++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md
@@ -28,6 +28,12 @@ image built externally is prone to breaking, since working directory may change
 upstream without warning, resulting in a completely different directory
 hierarchy for your build.
 
+> [!NOTE]
+>
+> `WORKDIR` does not perform shell expansion. Paths beginning with `~` or
+> `~username` are treated as literal directory names and are not resolved to a
+> user's home directory.
+
 ## Examples
 
 ❌ Bad: this assumes that `WORKDIR` in the base image is `/`
diff --git a/_vendor/github.com/moby/moby/api/docs/CHANGELOG.md b/_vendor/github.com/moby/moby/api/docs/CHANGELOG.md
new file mode 100644
index 000000000000..b6d1ec5d5992
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/CHANGELOG.md
@@ -0,0 +1,1317 @@
+---
+title: "Engine API version history"
+description: "Documentation of changes that have been made to Engine API."
+keywords: "API, Docker, rcli, REST, documentation"
+---
+
+<!-- This file is maintained within the moby/moby GitHub
+     repository at https://github.com/moby/moby/. Make all
+     pull requests against that repo. If you see this file in
+     another repository, consider it read-only there, as it will
+     periodically be overwritten by the definitive file. Pull
+     requests which include edits to this file in other repositories
+     will be rejected.
+-->
+
+## v1.55 API changes
+
+* `GET /images/{name}/attestations` is a new endpoint that returns the in-toto
+  attestation statements attached to an image. The `platform` query parameter
+  selects the image variant (defaults to the daemon's host platform); it is
+  declared as a repeatable parameter for forward compatibility, but only one
+  value is currently accepted. The `type` query parameter may be repeated to
+  filter the returned statements by in-toto predicate type URI; if omitted,
+  all statements are returned. The `statement` query parameter (default
+  `false`) controls whether the verbatim statement body is included; when
+  omitted or `false`, each entry contains only the descriptor and predicate
+  type, and statement blobs are not read. The response is a JSON array of
+  `AttestationStatement` objects.
+* `POST /containers/{id}/update` now supports per-device blkio resource
+  settings through the `BlkioWeightDevice`, `BlkioDeviceReadBps`,
+  `BlkioDeviceWriteBps`, `BlkioDeviceReadIOps`, and `BlkioDeviceWriteIOps`
+  fields. These fields were previously present in the request schema but were
+  ignored by the daemon. Omit a field or set it to `null` to leave the current
+  per-device rules unchanged. Set it to an empty array to clear the current
+  per-device rules for that resource type.
+
+## v1.54 API changes
+
+* `GET /images/json` now supports an `identity` query parameter. When set,
+  the response includes manifest summaries and may include an `Identity` field
+  for each manifest with trusted identity and origin information.
+* `POST /networks/{id}/connect` now correctly applies the `MacAddress` field in
+  `EndpointSettings`. This field was added in API v1.44, but was previously ignored.
+
+## v1.53 API changes
+
+* `GET /info` now includes an `NRI` field. If the Node Resource Interface (NRI)
+  is enabled, this field contains information describing it.
+* `GET /events` now also supports [`application/jsonl`](https://jsonlines.org/)
+  when negotiating content-type.
+* `GET /images/{name}/json` now includes an `Identity` field with trusted
+  identity and origin information for the image.
+* Deprecated: The `POST /grpc` and `POST /session` endpoints are deprecated and
+  will be removed in a future version.
+
+## v1.52 API changes
+
+* `GET /images/{name}/get` now accepts multiple `platform` query-arguments
+  to allow selecting which platform(s) of a multi-platform image must be
+  saved.
+* `POST /images/load` now accepts multiple `platform` query-arguments
+  to allow selecting which platform(s) of a multi-platform image to load.
+* `GET /events` no longer includes the deprecated `status`, `id`, and `from`
+  fields. These fields were removed in API v1.22, but still included
+  in the response.
+* `GET /networks/{id}` now includes a `Status` field, providing statistics
+  about IPAM allocations for the subnets assigned to the network.
+* Deprecated: the Engine was automatically backfilling empty `PortBindings` lists with
+  a PortBinding with an empty HostIP and HostPort when calling `POST /containers/{id}/start`.
+  This behavior is now deprecated, and a warning is returned by `POST /containers/create`.
+  A future API version will drop empty `PortBindings` list altogether.
+* `GET /images/{name}/json` now omits the following `Config` fields when
+  not set, to closer align with the implementation of the [OCI Image Specification](https://github.com/opencontainers/image-spec/blob/v1.1.1/specs-go/v1/config.go#L23-L62)
+  `Cmd`, `Entrypoint`, `Env`, `Labels`, `OnBuild`, `User`, `Volumes`, and `WorkingDir`.
+* `GET /images/{name}/json` now omits the following fields if their value
+  is empty: `Parent`, `Comment`, `DockerVersion`, `Author`. The `Parent`
+  and `DockerVersion` fields were set by the legacy builder, and are no
+  longer set when using BuildKit. The `Author` field is set through the
+  `MAINTAINER` Dockerfile instruction, which is deprecated, and the `Comment`
+  field is option, and may not be set depending on how the image was created.
+* `GET /container/{id}/json` now omits `Config.OnBuild` if its value is empty.
+* `GET /containers/{id}/json`: the `NetworkSettings` no longer returns the deprecated
+  `Bridge`, `HairpinMode`, `LinkLocalIPv6Address`, `LinkLocalIPv6PrefixLen`,
+  `SecondaryIPAddresses`, `SecondaryIPv6Addresses`, `EndpointID`, `Gateway`,
+  `GlobalIPv6Address`, `GlobalIPv6PrefixLen`, `IPAddress`, `IPPrefixLen`,
+  `IPv6Gateway`, and `MacAddress` fields. These fields were deprecated in
+  API v1.21 (docker v1.9.0) but kept around for backward compatibility.
+* Removed the `KernelMemoryTCP` field from the `POST /containers/{id}/update` and
+  `GET /containers/{id}/json` endpoints, any value it is set to will be ignored
+  on API version `v1.52` and up. Older API versions still accept this field, but
+  may take no effect, depending on the kernel version and OCI runtime in use.
+* Removed the `KernelMemoryTCP` field from the `GET /info` endpoint.
+* `GET /events` supports content-type negotiation and can produce either `application/x-ndjson` 
+  (Newline delimited JSON object stream) or `application/json-seq` (RFC7464).
+* `POST /containers/create` no longer supports configuring a container-wide MAC address
+  via the container's `Config.MacAddress` field. A container's MAC address can now only 
+  be configured via endpoint settings when connecting to a network.
+* `GET /services` now returns `SwapBytes` and `MemorySwappiness` fields as part
+  of the `Resource` requirements.
+* `GET /services/{id}` now returns `SwapBytes` and `MemorySwappiness` fields as
+  part of the `Resource` requirements.
+* `POST /services/create` now accepts `SwapBytes` and `MemorySwappiness` fields
+  as part of the `Resource` requirements.
+* `POST /services/{id}/update` now accepts `SwapBytes` and `MemorySwappiness`
+  fields as part of the `Resource` requirements.
+* `GET /tasks` now  returns `SwapBytes` and `MemorySwappiness` fields as part
+  of the `Resource` requirements.
+* `GET /tasks/{id}` now  returns `SwapBytes` and `MemorySwappiness` fields as
+  part of the `Resource` requirements.
+* `GET /containers/{id}/stats` now returns an `os_type` field to allow platform-
+  specific handling of the stats.
+* `GET /system/df` returns `ImagesUsage`, `ContainersUsage`, `VolumesUsage`, and
+  `BuildCacheUsage` fields with brief system disk usage data for each system object type.
+  The endpoint supports the `?verbose=1` query to return verbose system disk usage information.
+* Deprecated: `GET /system/df` response fields `LayersSize`, `Images`, `Containers`,
+  `Volumes`, and `BuildCache` have been removed in favor of the-type specific usage fields.
+  API v1.52 returns both the legacy and current fields to help existing integrations
+  to transition to the new response. The legacy fields are not populated if the
+  `verbose` query parameter is used. Starting with API v1.53, the legacy fields
+  will no longer be returned.
+
+## v1.51 API changes
+
+* `GET /images/json` now sets the value of `Containers` field for all images
+  to the count of containers using the image.
+  This field was previously always -1.
+* Deprecated: The field `NetworkSettings.Bridge` returned by `GET /containers/{id}/json`
+  is deprecated and will be removed in the next API version.
+* Deprecated: The field `KernelMemoryTCP` as part of `POST /containers/{id}/update`
+  and returned by `GET /containers/{id}/json` is deprecated and will be removed
+  in the next API version.
+* Deprecated: The field `KernelMemoryTCP` as part of `GET /info` is deprecated
+  and will be removed in the next API version.
+* Deprecated: the `Parent` and `DockerVersion` fields returned by the
+  `GET /images/{name}/json` endpoint are deprecated. These fields are set by
+  the legacy builder, and are no longer set when using BuildKit. The API
+  continues returning these fields when set for informational purposes, but
+  they should not be depended on as they will be omitted once the legacy builder
+  is removed.
+* Deprecated: the `Config.DockerVersion` field returned by the `GET /plugins`
+  and `GET /images/{name}/json` endpoints is deprecated. The field is no
+  longer set, and is omitted when empty.
+
+## v1.50 API changes
+
+* `GET /info` now includes a `DiscoveredDevices` field. This is an array of
+  `DeviceInfo` objects, each providing details about a device discovered by a
+  device driver.
+  Currently only the CDI device driver is supported.
+* `DELETE /images/{name}` now supports a `platforms` query parameter. It accepts
+  an array of JSON-encoded OCI Platform objects, allowing for selecting specific
+  platforms to delete content for.
+* Deprecated: The `BridgeNfIptables` and `BridgeNfIp6tables` fields in the
+  `GET /info` response were deprecated in API v1.48, and are now omitted
+  in API v1.50.
+* Deprecated: `GET /images/{name}/json` no longer returns the following `Config`
+  fields; `Hostname`, `Domainname`, `AttachStdin`, `AttachStdout`, `AttachStderr`
+  `Tty`, `OpenStdin`, `StdinOnce`, `Image`, `NetworkDisabled` (already omitted unless set),
+  `MacAddress` (already omitted unless set), `StopTimeout` (already omitted unless set).
+  These additional fields were included in the response due to an implementation
+  detail but not part of the image's Configuration. These fields were marked
+  deprecated in API v1.46, and are now omitted. Older versions of the API still
+  return these fields, but they are always empty.
+
+## v1.49 API changes
+
+* `GET /images/{name}/json` now supports a `platform` parameter (JSON
+  encoded OCI Platform type) allowing to specify a platform of the multi-platform
+  image to inspect.
+  This option is mutually exclusive with the `manifests` option.
+* `GET /info` now returns a `FirewallBackend` containing information about
+  the daemon's firewalling configuration.
+* Deprecated: The  `AllowNondistributableArtifactsCIDRs` and `AllowNondistributableArtifactsHostnames`
+  fields in the `RegistryConfig` struct in the `GET /info` response are omitted
+  in API v1.49.
+* Deprecated: The `ContainerdCommit.Expected`, `RuncCommit.Expected`, and
+  `InitCommit.Expected` fields in the `GET /info` endpoint were deprecated
+  in API v1.48, and are now omitted in API v1.49.
+
+## v1.48 API changes
+
+* Deprecated: The "error" and "progress" fields in streaming responses for
+  endpoints that return a JSON progress response, such as `POST /images/create`,
+  `POST /images/{name}/push`, and `POST /build` are deprecated. These fields
+  were marked deprecated in API v1.4 (docker v0.6.0) and API v1.8 (docker v0.7.1)
+  respectively, but still returned. These fields will be left empty or will
+  be omitted in a future API version. Users should use the information in the
+  `errorDetail` and `progressDetail` fields instead.
+* Deprecated: The "allow-nondistributable-artifacts" daemon configuration is
+  deprecated and enabled by default. The  `AllowNondistributableArtifactsCIDRs`
+  and `AllowNondistributableArtifactsHostnames` fields in the `RegistryConfig`
+  struct in the `GET /info` response will now always be `null` and will be
+  omitted in API v1.49.
+* Deprecated: The `BridgeNfIptables` and `BridgeNfIp6tables` fields in the 
+  `GET /info` response are now always be `false` and will be omitted in API
+  v1.49. The netfilter module is now loaded on-demand, and no longer during
+  daemon startup, making these fields obsolete.
+* Deprecated: The `POST /build/prune` `keep-storage` query parameter has been
+  renamed to `reserved-space`. `keep-storage` support will be removed in API v1.52.
+* `GET /images/{name}/history` now supports a `platform` parameter (JSON
+  encoded OCI Platform type) that allows to specify a platform to show the
+  history of.
+* `POST /images/{name}/load` and `GET /images/{name}/get` now support a
+  `platform` parameter (JSON encoded OCI Platform type) that allows to specify
+  a platform to load/save. Not passing this parameter will result in
+  loading/saving the full multi-platform image.
+* `POST /containers/create` now includes a warning in the response when setting
+  the container-wide `Config.VolumeDriver` option in combination with volumes
+  defined through `Mounts` because the `VolumeDriver` option has no effect on
+  those volumes. This warning was previously generated by the CLI, but now
+  moved to the daemon so that other clients can also get this warning.
+* `POST /containers/create` now supports `Mount` of type `image` for mounting
+  an image inside a container.
+* Deprecated: The `ContainerdCommit.Expected`, `RuncCommit.Expected`, and
+  `InitCommit.Expected` fields in the `GET /info` endpoint are deprecated
+  and will be omitted in API v1.49.
+* `Sysctls` in `HostConfig` (top level `--sysctl` settings) for `eth0` are
+  no longer migrated to `DriverOpts`, as described in the changes for v1.46.
+* `GET /images/json` and `GET /images/{name}/json` responses now include
+  `Descriptor` field, which contains an OCI descriptor of the image target.
+  The new field will only be populated if the daemon provides a multi-platform
+  image store.
+  WARNING: This is experimental and may change at any time without any backward
+  compatibility.
+* `GET /images/{name}/json` response now will return the `Manifests` field
+  containing information about the sub-manifests contained in the image index.
+  This includes things like platform-specific manifests and build attestations.
+  The new field will only be populated if the request also sets the `manifests`
+  query parameter to `true`.
+  This acts the same as in the `GET /images/json` endpoint.
+  WARNING: This is experimental and may change at any time without any backward compatibility.
+* `GET /containers/{name}/json` now returns an `ImageManifestDescriptor` field
+  containing the OCI descriptor of the platform-specific image manifest of the
+  image that was used to create the container.
+  This field is only populated if the daemon provides a multi-platform image
+  store.
+* `POST /networks/create` now has an `EnableIPv4` field. Setting it to `false`
+  disables IPv4 IPAM for the network. It can only be set to `false` if the
+  daemon has experimental features enabled.
+* `GET /networks/{id}` now returns an `EnableIPv4` field showing whether the
+  network has IPv4 IPAM enabled.
+* `POST /networks/{id}/connect` and `POST /containers/create` now accept a
+  `GwPriority` field in `EndpointsConfig`. This value is used to determine which
+  network endpoint provides the default gateway for the container. The endpoint
+  with the highest priority is selected. If multiple endpoints have the same
+  priority, endpoints are sorted lexicographically by their network name, and
+  the one that sorts first is picked.
+* `GET /containers/json` now returns a `GwPriority` field in `NetworkSettings`
+  for each network endpoint.
+* API debug endpoints (`GET /debug/vars`, `GET /debug/pprof/`, `GET /debug/pprof/cmdline`,
+  `GET /debug/pprof/profile`, `GET /debug/pprof/symbol`, `GET /debug/pprof/trace`,
+  `GET /debug/pprof/{name}`) are now also accessible through the versioned-API
+  paths (`/v<API-version>/<endpoint>`).
+* `POST /build/prune` renames `keep-storage` to `reserved-space` and now supports
+  additional prune parameters `max-used-space` and `min-free-space`.
+* `GET /containers/json` now returns an `ImageManifestDescriptor` field
+  matching the same field in `/containers/{name}/json`.
+  This field is only populated if the daemon provides a multi-platform image
+  store.
+
+## v1.47 API changes
+
+* `GET /images/json` response now includes `Manifests` field, which contains
+  information about the sub-manifests included in the image index. This
+  includes things like platform-specific manifests and build attestations.
+  The new field will only be populated if the request also sets the `manifests`
+  query parameter to `true`.
+  WARNING: This is experimental and may change at any time without any backward
+  compatibility.
+* `GET /info` no longer includes warnings when `bridge-nf-call-iptables` or
+  `bridge-nf-call-ip6tables` are disabled when the daemon was started. The
+  `br_netfilter` module is now attempted to be loaded when needed, making those
+  warnings inaccurate. This change is not versioned, and affects all API versions
+  if the daemon has this patch.
+
+## v1.46 API changes
+
+* `GET /info` now includes a `Containerd` field containing information about
+  the location of the containerd API socket and containerd namespaces used
+  by the daemon to run containers and plugins.
+* `POST /containers/create` field `NetworkingConfig.EndpointsConfig.DriverOpts`,
+  and `POST /networks/{id}/connect` field `EndpointsConfig.DriverOpts`, now
+  support label `com.docker.network.endpoint.sysctls` for setting per-interface
+  sysctls. The value is a comma separated list of sysctl assignments, the
+  interface name must be "IFNAME". For example, to set
+  `net.ipv4.config.eth0.log_martians=1`, use
+  `net.ipv4.config.IFNAME.log_martians=1`. In API versions up-to 1.46, top level
+  `--sysctl` settings for `eth0` will be migrated to `DriverOpts` when possible. 
+  This automatic migration will be removed in a future release.
+* `GET /containers/json` now returns the annotations of containers.
+* `POST /images/{name}/push` now supports a `platform` parameter (JSON encoded
+  OCI Platform type) that allows selecting a specific platform manifest from
+  the multi-platform image.
+* `POST /containers/create` now takes `Options` as part of `HostConfig.Mounts.TmpfsOptions` to set options for tmpfs mounts.
+* `POST /services/create` now takes `Options` as part of `ContainerSpec.Mounts.TmpfsOptions`, to set options for tmpfs mounts.
+* `GET /events` now supports image `create` event that is emitted when a new
+  image is built regardless if it was tagged or not.
+
+#### Deprecated Config fields in `GET /images/{name}/json` response
+
+The `Config` field returned by this endpoint (used for "image inspect") returns
+additional fields that are not part of the image's configuration and not part of
+the [Docker Image Spec] and the [OCI Image Spec].
+
+These additional fields are included in the response, due to an
+implementation detail, where the [api/types.ImageInspec] type used
+for the response is using the [container.Config] type.
+
+The [container.Config] type is a superset of the image config, and while the
+image's Config is used as a _template_ for containers created from the image,
+the additional fields are set at runtime (from options passed when creating
+the container) and not taken from the image Config.
+
+These fields are never set (and always return the default value for the type),
+but are not omitted in the response when left empty. As these fields were not
+intended to be part of the image configuration response, they are deprecated,
+and will be removed from the API.
+
+The following fields are currently included in the API response, but
+are not part of the underlying image's Config, and deprecated:
+
+- `Hostname`
+- `Domainname`
+- `AttachStdin`
+- `AttachStdout`
+- `AttachStderr`
+- `Tty`
+- `OpenStdin`
+- `StdinOnce`
+- `Image`
+- `NetworkDisabled` (already omitted unless set)
+- `MacAddress` (already omitted unless set)
+- `StopTimeout` (already omitted unless set)
+
+[Docker image spec]: https://github.com/moby/docker-image-spec/blob/v1.3.1/specs-go/v1/image.go#L19-L32
+[OCI Image Spec]: https://github.com/opencontainers/image-spec/blob/v1.1.0/specs-go/v1/config.go#L24-L62
+[api/types.ImageInspec]: https://github.com/moby/moby/blob/v26.1.4/api/types/types.go#L87-L104
+[container.Config]: https://github.com/moby/moby/blob/v26.1.4/api/types/container/config.go#L47-L82
+
+* `POST /services/create` and `POST /services/{id}/update` now support OomScoreAdj
+
+## v1.45 API changes
+
+* `POST /containers/create` now supports `VolumeOptions.Subpath` which allows a
+  subpath of a named volume to be mounted.
+* `POST /images/search` will always assume a `false` value for the `is-automated`
+  field. Consequently, searching for `is-automated=true` will yield no results,
+  while `is-automated=false` will be a no-op.
+* `GET /images/{name}/json` no longer includes the `Container` and
+  `ContainerConfig` fields. To access image configuration, use `Config` field
+  instead.
+* The `Aliases` field returned in calls to `GET /containers/{name:.*}/json` no
+  longer contains the short container ID, but instead will reflect exactly the
+  values originally submitted to the `POST /containers/create` endpoint. The
+  newly introduced `DNSNames` should now be used instead when short container
+  IDs are needed.
+
+## v1.44 API changes
+
+* GET `/images/json` now accepts an `until` filter. This accepts a timestamp and
+  lists all images created before it. The `<timestamp>` can be Unix timestamps,
+  date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`)
+  computed relative to the daemon machine’s time. This change is not versioned,
+  and affects all API versions if the daemon has this patch.
+* The `VirtualSize` field in the `GET /images/{name}/json`, `GET /images/json`,
+  and `GET /system/df` responses is now omitted. Use the `Size` field instead,
+  which contains the same information.
+* Deprecated: The `is_automated` field in the `GET /images/search` response has
+  been deprecated and will always be set to false in the future because Docker
+  Hub is deprecating the `is_automated` field in its search API. The deprecation
+  is not versioned, and applies to all API versions.
+* Deprecated: The `is-automated` filter for the `GET /images/search` endpoint.
+  The `is_automated` field has been deprecated by Docker Hub's search API.
+  Consequently, searching for `is-automated=true` will yield no results. The
+  deprecation is not versioned, and applies to all API versions.
+* Read-only bind mounts are now made recursively read-only on kernel >= 5.12
+  with runtimes which support the feature.
+  `POST /containers/create`, `GET /containers/{id}/json`, and `GET /containers/json` now supports
+  `BindOptions.ReadOnlyNonRecursive` and `BindOptions.ReadOnlyForceRecursive` to customize the behavior.
+* `POST /containers/create` now accepts a `HealthConfig.StartInterval` to set the
+  interval for health checks during the start period.
+* `GET /info` now includes a `CDISpecDirs` field indicating the configured CDI
+  specifications directories. The use of the applied setting requires the daemon
+  to have experimental enabled, and for non-experimental daemons an empty list is
+  always returned.
+* `POST /networks/create` now returns a 400 if the `IPAMConfig` has invalid
+  values. Note that this change is _unversioned_ and applied to all API
+  versions on daemon that support version 1.44.
+* `POST /networks/create` with a duplicated name now fails systematically. As
+  such, the `CheckDuplicate` field is now deprecated. Note that this change is
+  _unversioned_ and applied to all API versions on daemon that support version
+  1.44.
+* `POST /containers/create` now accepts multiple `EndpointSettings` in
+  `NetworkingConfig.EndpointSettings`.
+* `POST /containers/create` and `POST /networks/{id}/connect` will now catch
+  validation errors that were previously only returned during `POST /containers/{id}/start`.
+  These endpoints will also return the full set of validation errors they find,
+  instead of returning only the first one.
+  Note that this change is _unversioned_ and applies to all API versions.
+* `POST /services/create` and `POST /services/{id}/update` now accept `Seccomp`
+  and `AppArmor` fields in the `ContainerSpec.Privileges` object. This allows
+  some configuration of Seccomp and AppArmor in Swarm services.
+* A new endpoint-specific `MacAddress` field has been added to `NetworkSettings.EndpointSettings`
+  on `POST /containers/create`, and to `EndpointConfig` on `POST /networks/{id}/connect`.
+  The container-wide `MacAddress` field in `Config`, on `POST /containers/create`, is now deprecated.
+* The field `Networks` in the `POST /services/create` and `POST /services/{id}/update`
+  requests is now deprecated. You should instead use the field `TaskTemplate.Networks`.
+* The `Container` and `ContainerConfig` fields in the `GET /images/{name}/json`
+  response are deprecated and will no longer be included in API v1.45.
+* `GET /info` now includes `status` properties in `Runtimes`.
+* A new field named `DNSNames` and containing all non-fully qualified DNS names
+  a container takes on a specific network has been added to `GET /containers/{name:.*}/json`.
+* The `Aliases` field returned in calls to `GET /containers/{name:.*}/json` in v1.44 and older
+  versions contains the short container ID. This will change in the next API version, v1.45.
+  Starting with that API version, this specific value will be removed from the `Aliases` field
+  such that this field will reflect exactly the values originally submitted to the
+  `POST /containers/create` endpoint. The newly introduced `DNSNames` should now be used instead.
+* The fields `HairpinMode`, `LinkLocalIPv6Address`, `LinkLocalIPv6PrefixLen`, `SecondaryIPAddresses`,
+  `SecondaryIPv6Addresses` available in `NetworkSettings` when calling `GET /containers/{id}/json` are
+  deprecated and will be removed in a future release. You should instead look for the default network in
+  `NetworkSettings.Networks`.
+* `GET /images/{id}/json` omits the `Created` field (previously it was `0001-01-01T00:00:00Z`)
+  if the `Created` field is missing from the image config.
+
+## v1.43 API changes
+
+* `POST /containers/create` now accepts `Annotations` as part of `HostConfig`.
+  Can be used to attach arbitrary metadata to the container, which will also be
+  passed to the runtime when the container is started.
+* `GET /images/json` no longer includes hardcoded `<none>:<none>` and
+  `<none>@<none>` in `RepoTags` and`RepoDigests` for untagged images.
+  In such cases, empty arrays will be produced instead.
+* The `VirtualSize` field in the `GET /images/{name}/json`, `GET /images/json`,
+  and `GET /system/df` responses is deprecated and will no longer be included
+  in API v1.44. Use the `Size` field instead, which contains the same information.
+* `GET /info` now includes `no-new-privileges` in the `SecurityOptions` string
+  list when this option is enabled globally. This change is not versioned, and
+  affects all API versions if the daemon has this patch.
+
+## v1.42 API changes
+
+* Removed the `BuilderSize` field on the `GET /system/df` endpoint. This field
+  was introduced in API 1.31 as part of an experimental feature, and no longer
+  used since API 1.40.
+  Use field `BuildCache` instead to track storage used by the builder component.
+* `POST /containers/{id}/stop` and `POST /containers/{id}/restart` now accept a
+  `signal` query parameter, which allows overriding the container's default stop-
+  signal.
+* `GET /images/json` now accepts query parameter `shared-size`. When set `true`,
+  images returned will include `SharedSize`, which provides the size on disk shared
+  with other images present on the system.
+* `GET /system/df` now accepts query parameter `type`. When set,
+  computes and returns data only for the specified object type.
+  The parameter can be specified multiple times to select several object types.
+  Supported values are: `container`, `image`, `volume`, `build-cache`.
+* `GET /system/df` can now be used concurrently. If a request is made while a
+  previous request is still being processed, the request will receive the result
+  of the already running calculation, once completed. Previously, an error
+  (`a disk usage operation is already running`) would be returned in this
+  situation. This change is not versioned, and affects all API versions if the
+  daemon has this patch.
+* The `POST /images/create` now supports both the operating system and architecture
+  that is passed through the `platform` query parameter when using the `fromSrc`
+  option to import an image from an archive. Previously, only the operating system
+  was used and the architecture was ignored. If no `platform` option is set, the
+  host's operating system and architecture as used as default. This change is not
+  versioned, and affects all API versions if the daemon has this patch.
+* The `POST /containers/{id}/wait` endpoint now returns a `400` status code if an
+  invalid `condition` is provided (on API 1.30 and up).
+* Removed the `KernelMemory` field from the `POST /containers/create` and
+  `POST /containers/{id}/update` endpoints, any value it is set to will be ignored
+  on API version `v1.42` and up. Older API versions still accept this field, but
+  may take no effect, depending on the kernel version and OCI runtime in use.
+* `GET /containers/{id}/json` now omits the `KernelMemory` and `KernelMemoryTCP`
+  if they are not set.
+* `GET /info` now omits the `KernelMemory` and `KernelMemoryTCP` if they are not
+  supported by the host or host's configuration (if cgroups v2 are in use).
+* `GET /_ping` and `HEAD /_ping` now return `Builder-Version` by default.
+  This header contains the default builder to use, and is a recommendation as
+  advertised by the daemon. However, it is up to the client to choose which builder
+  to use.
+
+  The default value on Linux is version "2" (BuildKit), but the daemon can be
+  configured to recommend version "1" (classic Builder). Windows does not yet
+  support BuildKit for native Windows images, and uses "1" (classic builder) as
+  a default.
+
+  This change is not versioned, and affects all API versions if the daemon has
+  this patch.
+* `GET /_ping` and `HEAD /_ping` now return a `Swarm` header, which allows a
+  client to detect if Swarm is enabled on the daemon, without having to call
+  additional endpoints.
+  This change is not versioned, and affects all API versions if the daemon has
+  this patch. Clients must consider this header "optional", and fall back to
+  using other endpoints to get this information if the header is not present.
+
+  The `Swarm` header can contain one of the following values:
+
+    - "inactive"
+    - "pending"
+    - "error"
+    - "locked"
+    - "active/worker"
+    - "active/manager"
+* `POST /containers/create` for Windows containers now accepts a new syntax in
+  `HostConfig.Resources.Devices.PathOnHost`. As well as the existing `class/<GUID>`
+  syntax, `<IDType>://<ID>` is now recognised. Support for specific `<IDType>` values
+  depends on the underlying implementation and Windows version. This change is not
+  versioned, and affects all API versions if the daemon has this patch.
+* `GET /containers/{id}/attach`, `GET /exec/{id}/start`, `GET /containers/{id}/logs`
+  `GET /services/{id}/logs` and `GET /tasks/{id}/logs` now set Content-Type header
+  to `application/vnd.docker.multiplexed-stream` when a multiplexed stdout/stderr
+  stream is sent to client, `application/vnd.docker.raw-stream` otherwise.
+* `POST /volumes/create` now accepts a new `ClusterVolumeSpec` to create a cluster
+  volume (CNI). This option can only be used if the daemon is a Swarm manager.
+  The Volume response on creation now also can contain a `ClusterVolume` field
+  with information about the created volume.
+* The `BuildCache.Parent` field, as returned by `GET /system/df` is deprecated
+  and is now omitted. API versions before v1.42 continue to include this field.
+* `GET /system/df` now includes a new `Parents` field, for "build-cache" records,
+  which contains a list of parent IDs for the build-cache record.
+* Volume information returned by `GET /volumes/{name}`, `GET /volumes` and
+  `GET /system/df` can now contain a `ClusterVolume` if the volume is a cluster
+  volume (requires the daemon to be a Swarm manager).
+* The `Volume` type, as returned by `Added new `ClusterVolume` fields
+* Added a new `PUT /volumes{name}` endpoint to update cluster volumes (CNI).
+  Cluster volumes are only supported if the daemon is a Swarm manager.
+* `GET /containers/{name}/attach/ws` endpoint now accepts `stdin`, `stdout` and
+  `stderr` query parameters to only attach to configured streams.
+
+  NOTE: These parameters were documented before in older API versions, but not
+  actually supported. API versions before v1.42 continue to ignore these parameters
+  and default to attaching to all streams. To preserve the pre-v1.42 behavior,
+  set all three query parameters (`?stdin=1,stdout=1,stderr=1`).
+* `POST /containers/create` on Linux now respects the `HostConfig.ConsoleSize` property.
+  Container is immediately created with the desired terminal size and clients no longer
+  need to set the desired size on their own.
+* `POST /containers/create` allow to set `CreateMountpoint` for host path to be
+  created if missing. This brings parity with `Binds`
+* `POST /containers/create` rejects request if BindOptions|VolumeOptions|TmpfsOptions
+  is set with a non-matching mount Type.
+* `POST /containers/{id}/exec` now accepts an optional `ConsoleSize` parameter.
+  It allows to set the console size of the executed process immediately when it's created.
+* `POST /volumes/prune` will now only prune "anonymous" volumes (volumes which were not given a name) by default. A new filter parameter `all` can be set to a truth-y value (`true`, `1`) to get the old behavior.
+
+## v1.41 API changes
+
+* `GET /events` now returns `prune` events after pruning resources have completed.
+  Prune events are returned for `container`, `network`, `volume`, `image`, and
+  `builder`, and have a `reclaimed` attribute, indicating the amount of space
+  reclaimed (in bytes).
+* `GET /info` now returns a `CgroupVersion` field, containing the cgroup version.
+* `GET /info` now returns a `DefaultAddressPools` field, containing a list of
+  custom default address pools for local networks, which can be specified in the
+  `daemon.json` file or `--default-address-pool` dockerd option.
+* `POST /services/create` and `POST /services/{id}/update` now supports `BindOptions.NonRecursive`.
+* The `ClusterStore` and `ClusterAdvertise` fields in `GET /info` are deprecated
+  and are now omitted if they contain an empty value. This change is not versioned,
+  and affects all API versions if the daemon has this patch.
+* The `filter` (singular) query parameter, which was deprecated in favor of the
+  `filters` option in Docker 1.13, has now been removed from the `GET /images/json`
+  endpoint. The parameter remains available when using API version 1.40 or below.
+* `GET /services` now returns `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
+* `GET /services/{id}` now returns `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
+* `POST /services/create` now accepts `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
+* `POST /services/{id}/update` now accepts `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
+* `GET /tasks` now  returns `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
+* `GET /tasks/{id}` now  returns `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
+* `GET /services` now returns `Pids` in `TaskTemplate.Resources.Limits`.
+* `GET /services/{id}` now returns `Pids` in `TaskTemplate.Resources.Limits`.
+* `POST /services/create` now accepts `Pids` in `TaskTemplate.Resources.Limits`.
+* `POST /services/{id}/update` now accepts `Pids` in `TaskTemplate.Resources.Limits`
+  to limit the maximum number of PIDs.
+* `GET /tasks` now  returns `Pids` in `TaskTemplate.Resources.Limits`.
+* `GET /tasks/{id}` now  returns `Pids` in `TaskTemplate.Resources.Limits`.
+* `POST /containers/create` now accepts a `platform` query parameter in the format
+  `os[/arch[/variant]]`.
+
+  When set, the daemon checks if the requested image is present in the local image
+  cache with the given OS and Architecture, and otherwise returns a `404` status.
+
+  If the option is _not_ set, the host's native OS and Architecture are used to
+  look up the image in the image cache. However, if no platform is passed and the
+  given image _does_ exist in the local image cache, but its OS or architecture
+  do not match, the container is created with the available image, and a warning
+  is added to the `Warnings` field in the response, for example;
+
+      WARNING: The requested image's platform (linux/arm64/v8) does not
+               match the detected host platform (linux/amd64) and no
+               specific platform was requested
+
+* `POST /containers/create` on Linux now accepts the `HostConfig.CgroupnsMode` property.
+  Set the property to `host` to create the container in the daemon's cgroup namespace, or
+  `private` to create the container in its own private cgroup namespace.  The per-daemon
+  default is `host`, and can be changed by using the`CgroupNamespaceMode` daemon configuration
+  parameter.
+* `GET /info` now  returns an `OSVersion` field, containing the operating system's
+  version. This change is not versioned, and affects all API versions if the daemon
+  has this patch.
+* `GET /info` no longer returns the `SystemStatus` field if it does not have a
+  value set. This change is not versioned, and affects all API versions if the
+  daemon has this patch.
+* `GET /services` now accepts query parameter `status`. When set `true`,
+  services returned will include `ServiceStatus`, which provides Desired,
+  Running, and Completed task counts for the service.
+* `GET /services` may now include `ReplicatedJob` or `GlobalJob` as the `Mode`
+  in a `ServiceSpec`.
+* `GET /services/{id}` may now include `ReplicatedJob` or `GlobalJob` as the
+  `Mode` in a `ServiceSpec`.
+* `POST /services/create` now accepts `ReplicatedJob or `GlobalJob` as the `Mode`
+  in the `ServiceSpec.
+* `POST /services/{id}/update` accepts updating the fields of the
+  `ReplicatedJob` object in the `ServiceSpec.Mode`. The service mode still
+  cannot be changed, however.
+* `GET /services` now includes `JobStatus` on Services with mode
+  `ReplicatedJob` or `GlobalJob`.
+* `GET /services/{id}` now includes `JobStatus` on Services with mode
+  `ReplicatedJob` or `GlobalJob`.
+* `GET /tasks` now includes `JobIteration` on Tasks spawned from a job-mode
+  service.
+* `GET /tasks/{id}` now includes `JobIteration` on the task if spawned from a
+  job-mode service.
+* `GET /containers/{id}/stats` now accepts a query param (`one-shot`) which, when used with `stream=false` fetches a
+  single set of stats instead of waiting for two collection cycles to have 2 CPU stats over a 1 second period.
+* The `KernelMemory` field in `HostConfig.Resources` is now deprecated.
+* The `KernelMemory` field in `Info` is now deprecated.
+* `GET /services` now returns `Ulimits` as part of `ContainerSpec`.
+* `GET /services/{id}` now returns `Ulimits` as part of `ContainerSpec`.
+* `POST /services/create` now accepts `Ulimits` as part of `ContainerSpec`.
+* `POST /services/{id}/update` now accepts `Ulimits` as part of `ContainerSpec`.
+
+## v1.40 API changes
+
+* The `/_ping` endpoint can now be accessed both using `GET` or `HEAD` requests.
+  when accessed using a `HEAD` request, all headers are returned, but the body
+  is empty (`Content-Length: 0`). This change is not versioned, and affects all
+  API versions if the daemon has this patch. Clients are recommended to try
+  using `HEAD`, but fallback to `GET` if the `HEAD` requests fails.
+* `GET /_ping` and `HEAD /_ping` now set `Cache-Control` and `Pragma` headers to
+  prevent the result from being cached. This change is not versioned, and affects
+  all API versions if the daemon has this patch.
+* `GET /services` now returns `Sysctls` as part of the `ContainerSpec`.
+* `GET /services/{id}` now returns `Sysctls` as part of the `ContainerSpec`.
+* `POST /services/create` now accepts `Sysctls` as part of the `ContainerSpec`.
+* `POST /services/{id}/update` now accepts `Sysctls` as part of the `ContainerSpec`.
+* `POST /services/create` now accepts `Config` as part of `ContainerSpec.Privileges.CredentialSpec`.
+* `POST /services/{id}/update` now accepts `Config` as part of `ContainerSpec.Privileges.CredentialSpec`.
+* `POST /services/create` now includes `Runtime` as an option in `ContainerSpec.Configs`
+* `POST /services/{id}/update` now includes `Runtime` as an option in `ContainerSpec.Configs`
+* `GET /tasks` now  returns `Sysctls` as part of the `ContainerSpec`.
+* `GET /tasks/{id}` now  returns `Sysctls` as part of the `ContainerSpec`.
+* `GET /networks` now supports a `dangling` filter type. When set to `true` (or
+  `1`), the endpoint returns all networks that are not in use by a container. When
+  set to `false` (or `0`), only networks that are in use by one or more containers
+  are returned.
+* `GET /nodes` now supports a filter type `node.label` filter to filter nodes based
+  on the node.label. The format of the label filter is `node.label=<key>`/`node.label=<key>=<value>`
+  to return those with the specified labels, or `node.label!=<key>`/`node.label!=<key>=<value>`
+  to return those without the specified labels.
+* `POST /containers/create` now accepts a `fluentd-async` option in `HostConfig.LogConfig.Config`
+  when using the Fluentd logging driver. This option deprecates the `fluentd-async-connect`
+  option, which remains functional, but will be removed in a future release. Users
+  are encouraged to use the `fluentd-async` option going forward. This change is
+  not versioned, and affects all API versions if the daemon has this patch.
+* `POST /containers/create` now accepts a `fluentd-request-ack` option in
+  `HostConfig.LogConfig.Config` when using the Fluentd logging driver. If enabled,
+  the Fluentd logging driver sends the chunk option with a unique ID. The server
+  will respond with an acknowledgement. This option improves the reliability of
+  the message transmission. This change is not versioned, and affects all API
+  versions if the daemon has this patch.
+* `POST /containers/create`, `GET /containers/{id}/json`, and `GET /containers/json` now supports
+  `BindOptions.NonRecursive`.
+* `POST /swarm/init` now accepts a `DataPathPort` property to set data path port number.
+* `GET /info` now returns information about `DataPathPort` that is currently used in swarm
+* `GET /info` now returns `PidsLimit` boolean to indicate if the host kernel has
+  PID limit support enabled.
+* `GET /info` now includes `name=rootless` in `SecurityOptions` when the daemon is running in
+  rootless mode.  This change is not versioned, and affects all API versions if the daemon has
+  this patch.
+* `GET /info` now returns `none` as `CgroupDriver` when the daemon is running in rootless mode.
+  This change is not versioned, and affects all API versions if the daemon has this patch.
+* `POST /containers/create` now accepts `DeviceRequests` as part of `HostConfig`.
+  Can be used to set Nvidia GPUs.
+* `GET /swarm` endpoint now returns DataPathPort info
+* `POST /containers/create` now takes `KernelMemoryTCP` field to set hard limit for kernel TCP buffer memory.
+* `GET /service` now  returns `MaxReplicas` as part of the `Placement`.
+* `GET /service/{id}` now  returns `MaxReplicas` as part of the `Placement`.
+* `POST /service/create` and `POST /services/(id or name)/update` now take the field `MaxReplicas`
+  as part of the service `Placement`, allowing to specify maximum replicas per node for the service.
+* `POST /containers/create` on Linux now creates a container with `HostConfig.IpcMode=private`
+  by default, if IpcMode is not explicitly specified. The per-daemon default can be changed
+  back to `shareable` by using `DefaultIpcMode` daemon configuration parameter.
+* `POST /containers/{id}/update` now accepts a `PidsLimit` field to tune a container's
+  PID limit. Set `0` or `-1` for unlimited. Leave `null` to not change the current value.
+* `POST /build` now accepts `outputs` key for configuring build outputs when using BuildKit mode.
+
+## V1.39 API changes
+
+* `GET /info` now returns an empty string, instead of `<unknown>` for `KernelVersion`
+  and `OperatingSystem` if the daemon was unable to obtain this information.
+* `GET /info` now returns information about the product license, if a license
+  has been applied to the daemon.
+* `GET /info` now returns a `Warnings` field, containing warnings and informational
+  messages about missing features, or issues related to the daemon configuration.
+* `POST /swarm/init` now accepts a `DefaultAddrPool` property to set global scope default address pool
+* `POST /swarm/init` now accepts a `SubnetSize` property to set global scope networks by giving the
+  length of the subnet masks for every such network
+* `POST /session` (added in [V1.31](#v131-api-changes) is no longer experimental.
+  This endpoint can be used to run interactive long-running protocols between the
+  client and the daemon.
+
+## V1.38 API changes
+
+* `GET /tasks` and `GET /tasks/{id}` now return a `NetworkAttachmentSpec` field,
+  containing the `ContainerID` for non-service containers connected to "attachable"
+  swarm-scoped networks.
+
+## v1.37 API changes
+
+* `POST /containers/create` and `POST /services/create` now supports exposing SCTP ports.
+* `POST /configs/create` and `POST /configs/{id}/create` now accept a `Templating` driver.
+* `GET /configs` and `GET /configs/{id}` now return the `Templating` driver of the config.
+* `POST /secrets/create` and `POST /secrets/{id}/create` now accept a `Templating` driver.
+* `GET /secrets` and `GET /secrets/{id}` now return the `Templating` driver of the secret.
+
+## v1.36 API changes
+
+* `Get /events` now return `exec_die` event when an exec process terminates.
+
+
+## v1.35 API changes
+
+* `POST /services/create` and `POST /services/(id)/update` now accepts an
+  `Isolation` field on container spec to set the Isolation technology of the
+  containers running the service (`default`, `process`, or `hyperv`). This
+  configuration is only used for Windows containers.
+* `GET /containers/(name)/logs` now supports an additional query parameter: `until`,
+  which returns log lines that occurred before the specified timestamp.
+* `POST /containers/{id}/exec` now accepts a `WorkingDir` property to set the
+  work-dir for the exec process, independent of the container's work-dir.
+* `Get /version` now returns a `Platform.Name` field, which can be used by products
+  using Moby as a foundation to return information about the platform.
+* `Get /version` now returns a `Components` field, which can be used to return
+  information about the components used. Information about the engine itself is
+  now included as a "Component" version, and contains all information from the
+  top-level `Version`, `GitCommit`, `APIVersion`, `MinAPIVersion`, `GoVersion`,
+  `Os`, `Arch`, `BuildTime`, `KernelVersion`, and `Experimental` fields. Going
+  forward, the information from the `Components` section is preferred over their
+  top-level counterparts.
+
+
+## v1.34 API changes
+
+* `POST /containers/(name)/wait?condition=removed` now also also returns
+  in case of container removal failure. A pointer to a structure named
+  `Error` added to the response JSON in order to indicate a failure.
+  If `Error` is `null`, container removal has succeeded, otherwise
+  the test of an error message indicating why container removal has failed
+  is available from `Error.Message` field.
+
+## v1.33 API changes
+
+* `GET /events` now supports filtering 4 more kinds of events: `config`, `node`,
+`secret` and `service`.
+
+## v1.32 API changes
+
+* `POST /images/create` now accepts a `platform` parameter in the form of `os[/arch[/variant]]`.
+* `POST /containers/create` now accepts additional values for the
+  `HostConfig.IpcMode` property. New values are `private`, `shareable`,
+  and `none`.
+* `DELETE /networks/{id or name}` fixed issue where a `name` equal to another
+  network's name was able to mask that `id`. If both a network with the given
+  _name_ exists, and a network with the given _id_, the network with the given
+  _id_ is now deleted. This change is not versioned, and affects all API versions
+  if the daemon has this patch.
+
+## v1.31 API changes
+
+* `DELETE /secrets/(name)` now returns status code 404 instead of 500 when the secret does not exist.
+* `POST /secrets/create` now returns status code 409 instead of 500 when creating an already existing secret.
+* `POST /secrets/create` now accepts a `Driver` struct, allowing the
+  `Name` and driver-specific `Options` to be passed to store a secrets
+  in an external secrets store. The `Driver` property can be omitted
+  if the default (internal) secrets store is used.
+* `GET /secrets/(id)` and `GET /secrets` now return a `Driver` struct,
+  containing the `Name` and driver-specific `Options` of the external
+  secrets store used to store the secret. The `Driver` property is
+  omitted if no external store is used.
+* `POST /secrets/(name)/update` now returns status code 400 instead of 500 when updating a secret's content which is not the labels.
+* `POST /nodes/(name)/update` now returns status code 400 instead of 500 when demoting last node fails.
+* `GET /networks/(id or name)` now takes an optional query parameter `scope` that will filter the network based on the scope (`local`, `swarm`, or `global`).
+* `POST /session` is a new endpoint that can be used for running interactive long-running protocols between client and
+  the daemon. This endpoint is experimental and only available if the daemon is started with experimental features
+  enabled.
+* `GET /images/(name)/get` now includes an `ImageMetadata` field which contains image metadata that is local to the engine and not part of the image config.
+* `POST /services/create` now accepts a `PluginSpec` when `TaskTemplate.Runtime` is set to `plugin`
+* `GET /events` now supports config events `create`, `update` and `remove` that are emitted when users create, update or remove a config
+* `GET /volumes/` and `GET /volumes/{name}` now return a `CreatedAt` field,
+  containing the date/time the volume was created. This field is omitted if the
+  creation date/time for the volume is unknown. For volumes with scope "global",
+  this field represents the creation date/time of the local _instance_ of the
+  volume, which may differ from instances of the same volume on different nodes.
+* `GET /system/df` now returns a `CreatedAt` field for `Volumes`. Refer to the
+  `/volumes/` endpoint for a description of this field.
+
+## v1.30 API changes
+
+* `GET /info` now returns the list of supported logging drivers, including plugins.
+* `GET /info` and `GET /swarm` now returns the cluster-wide swarm CA info if the node is in a swarm: the cluster root CA certificate, and the cluster TLS
+ leaf certificate issuer's subject and public key. It also displays the desired CA signing certificate, if any was provided as part of the spec.
+* `POST /build/` now (when not silent) produces an `Aux` message in the JSON output stream with payload `types.BuildResult` for each image produced. The final such message will reference the image resulting from the build.
+* `GET /nodes` and `GET /nodes/{id}` now returns additional information about swarm TLS info if the node is part of a swarm: the trusted root CA, and the
+ issuer's subject and public key.
+* `GET /distribution/(name)/json` is a new endpoint that returns a JSON output stream with payload `types.DistributionInspect` for an image name. It includes a descriptor with the digest, and supported platforms retrieved from directly contacting the registry.
+* `POST /swarm/update` now accepts 3 additional parameters as part of the swarm spec's CA configuration; the desired CA certificate for
+ the swarm, the desired CA key for the swarm (if not using an external certificate), and an optional parameter to force swarm to
+ generate and rotate to a new CA certificate/key pair.
+* `POST /service/create` and `POST /services/(id or name)/update` now take the field `Platforms` as part of the service `Placement`, allowing to specify platforms supported by the service.
+* `POST /containers/(name)/wait` now accepts a `condition` query parameter to indicate which state change condition to wait for. Also, response headers are now returned immediately to acknowledge that the server has registered a wait callback for the client.
+* `POST /swarm/init` now accepts a `DataPathAddr` property to set the IP-address or network interface to use for data traffic
+* `POST /swarm/join` now accepts a `DataPathAddr` property to set the IP-address or network interface to use for data traffic
+* `GET /events` now supports service, node and secret events which are emitted when users create, update and remove service, node and secret
+* `GET /events` now supports network remove event which is emitted when users remove a swarm scoped network
+* `GET /events` now supports a filter type `scope` in which supported value could be swarm and local
+* `PUT /containers/(name)/archive` now accepts a `copyUIDGID` parameter to allow copy UID/GID maps to dest file or dir.
+
+## v1.29 API changes
+
+* `DELETE /networks/(name)` now allows to remove the ingress network, the one used to provide the routing-mesh.
+* `POST /networks/create` now supports creating the ingress network, by specifying an `Ingress` boolean field. As of now this is supported only when using the overlay network driver.
+* `GET /networks/(name)` now returns an `Ingress` field showing whether the network is the ingress one.
+* `GET /networks/` now supports a `scope` filter to filter networks based on the network mode (`swarm`, `global`, or `local`).
+* `POST /containers/create`, `POST /service/create` and `POST /services/(id or name)/update` now takes the field `StartPeriod` as a part of the `HealthConfig` allowing for specification of a period during which the container should not be considered unhealthy even if health checks do not pass.
+* `GET /services/(id)` now accepts an `insertDefaults` query-parameter to merge default values into the service inspect output.
+* `POST /containers/prune`, `POST /images/prune`, `POST /volumes/prune`, and `POST /networks/prune` now support a `label` filter to filter containers, images, volumes, or networks based on the label. The format of the label filter could be `label=<key>`/`label=<key>=<value>` to remove those with the specified labels, or `label!=<key>`/`label!=<key>=<value>` to remove those without the specified labels.
+* `POST /services/create` now accepts `Privileges` as part of `ContainerSpec`. Privileges currently include
+  `CredentialSpec` and `SELinuxContext`.
+
+## v1.28 API changes
+
+* `POST /containers/create` now includes a `Consistency` field to specify the consistency level for each `Mount`, with possible values `default`, `consistent`, `cached`, or `delegated`.
+* `GET /containers/create` now takes a `DeviceCgroupRules` field in `HostConfig` allowing to set custom device cgroup rules for the created container.
+* Optional query parameter `verbose` for `GET /networks/(id or name)` will now list all services with all the tasks, including the non-local tasks on the given network.
+* `GET /containers/(id or name)/attach/ws` now returns WebSocket in binary frame format for API version >= v1.28, and returns WebSocket in text frame format for API version< v1.28, for the purpose of backward-compatibility.
+* `GET /networks` is optimised only to return list of all networks and network specific information. List of all containers attached to a specific network is removed from this API and is only available using the network specific `GET /networks/{network-id}`.
+* `GET /containers/json` now supports `publish` and `expose` filters to filter containers that expose or publish certain ports.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept the `ReadOnly` parameter, which mounts the container's root filesystem as read only.
+* `POST /build` now accepts `extrahosts` parameter to specify a host to ip mapping to use during the build.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept a `rollback` value for `FailureAction`.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept an optional `RollbackConfig` object which specifies rollback options.
+* `GET /services` now supports a `mode` filter to filter services based on the service mode (either `global` or `replicated`).
+* `POST /containers/(name)/update` now supports updating `NanoCpus` that represents CPU quota in units of 10<sup>-9</sup> CPUs.
+* `POST /plugins/{name}/disable` now accepts a `force` query-parameter to disable a plugin even if still in use.
+
+## v1.27 API changes
+
+* `GET /containers/(id or name)/stats` now includes an `online_cpus` field in both `precpu_stats` and `cpu_stats`. If this field is `nil` then for compatibility with older daemons the length of the corresponding `cpu_usage.percpu_usage` array should be used.
+
+## v1.26 API changes
+
+* `POST /plugins/(plugin name)/upgrade` upgrade a plugin.
+
+## v1.25 API changes
+
+* The API version is now required in all API calls. Instead of just requesting, for example, the URL `/containers/json`, you must now request `/v1.25/containers/json`.
+* `GET /version` now returns `MinAPIVersion`.
+* `POST /build` accepts `networkmode` parameter to specify network used during build.
+* `GET /images/(name)/json` now returns `OsVersion` if populated
+* `GET /images/(name)/json` no longer contains the `RootFS.BaseLayer` field. This
+  field was used for Windows images that used a base-image that was pre-installed
+  on the host (`RootFS.Type` `layers+base`), which is no longer supported, and
+  the `RootFS.BaseLayer` field has been removed.
+* `GET /info` now returns `Isolation`.
+* `POST /containers/create` now takes `AutoRemove` in HostConfig, to enable auto-removal of the container on daemon side when the container's process exits.
+* `GET /containers/json` and `GET /containers/(id or name)/json` now return `"removing"` as a value for the `State.Status` field if the container is being removed. Previously, "exited" was returned as status.
+* `GET /containers/json` now accepts `removing` as a valid value for the `status` filter.
+* `GET /containers/json` now supports filtering containers by `health` status.
+* `DELETE /volumes/(name)` now accepts a `force` query parameter to force removal of volumes that were already removed out of band by the volume driver plugin.
+* `POST /containers/create/` and `POST /containers/(name)/update` now validates restart policies.
+* `POST /containers/create` now validates IPAMConfig in NetworkingConfig, and returns error for invalid IPv4 and IPv6 addresses (`--ip` and `--ip6` in `docker create/run`).
+* `POST /containers/create` now takes a `Mounts` field in `HostConfig` which replaces `Binds`, `Volumes`, and `Tmpfs`. *note*: `Binds`, `Volumes`, and `Tmpfs` are still available and can be combined with `Mounts`.
+* `POST /build` now performs a preliminary validation of the `Dockerfile` before starting the build, and returns an error if the syntax is incorrect. Note that this change is _unversioned_ and applied to all API versions.
+* `POST /build` accepts `cachefrom` parameter to specify images used for build cache.
+* `GET /networks/` endpoint now correctly returns a list of *all* networks,
+  instead of the default network if a trailing slash is provided, but no `name`
+  or `id`.
+* `DELETE /containers/(name)` endpoint now returns an error of `removal of container name is already in progress` with status code of 400, when container name is in a state of removal in progress.
+* `GET /containers/json` now supports a `is-task` filter to filter
+  containers that are tasks (part of a service in swarm mode).
+* `POST /containers/create` now takes `StopTimeout` field.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept `Monitor` and `MaxFailureRatio` parameters, which control the response to failures during service updates.
+* `POST /services/(id or name)/update` now accepts a `ForceUpdate` parameter inside the `TaskTemplate`, which causes the service to be updated even if there are no changes which would ordinarily trigger an update.
+* `POST /services/create` and `POST /services/(id or name)/update` now return a `Warnings` array.
+* `GET /networks/(name)` now returns field `Created` in response to show network created time.
+* `POST /containers/(id or name)/exec` now accepts an `Env` field, which holds a list of environment variables to be set in the context of the command execution.
+* `GET /volumes`, `GET /volumes/(name)`, and `POST /volumes/create` now return the `Options` field which holds the driver specific options to use for when creating the volume.
+* `GET /exec/(id)/json` now returns `Pid`, which is the system pid for the exec'd process.
+* `POST /containers/prune` prunes stopped containers.
+* `POST /images/prune` prunes unused images.
+* `POST /volumes/prune` prunes unused volumes.
+* `POST /networks/prune` prunes unused networks.
+* Every API response now includes a `Docker-Experimental` header specifying if experimental features are enabled (value can be `true` or `false`).
+* Every API response now includes a `API-Version` header specifying the default API version of the server.
+* The `hostConfig` option now accepts the fields `CpuRealtimePeriod` and `CpuRtRuntime` to allocate cpu runtime to rt tasks when `CONFIG_RT_GROUP_SCHED` is enabled in the kernel.
+* The `SecurityOptions` field within the `GET /info` response now includes `userns` if user namespaces are enabled in the daemon.
+* `GET /nodes` and `GET /node/(id or name)` now return `Addr` as part of a node's `Status`, which is the address that that node connects to the manager from.
+* The `HostConfig` field now includes `NanoCpus` that represents CPU quota in units of 10<sup>-9</sup> CPUs.
+* `GET /info` now returns more structured information about security options.
+* The `HostConfig` field now includes `CpuCount` that represents the number of CPUs available for execution by the container. Windows daemon only.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept the `TTY` parameter, which allocate a pseudo-TTY in container.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept the `DNSConfig` parameter, which specifies DNS related configurations in resolver configuration file (resolv.conf) through `Nameservers`, `Search`, and `Options`.
+* `POST /services/create` and `POST /services/(id or name)/update` now support
+  `node.platform.arch` and `node.platform.os` constraints in the services
+  `TaskSpec.Placement.Constraints` field.
+* `GET /networks/(id or name)` now includes IP and name of all peers nodes for swarm mode overlay networks.
+* `GET /plugins` list plugins.
+* `POST /plugins/pull?name=<plugin name>` pulls a plugin.
+* `GET /plugins/(plugin name)` inspect a plugin.
+* `POST /plugins/(plugin name)/set` configure a plugin.
+* `POST /plugins/(plugin name)/enable` enable a plugin.
+* `POST /plugins/(plugin name)/disable` disable a plugin.
+* `POST /plugins/(plugin name)/push` push a plugin.
+* `POST /plugins/create?name=(plugin name)` create a plugin.
+* `DELETE /plugins/(plugin name)` delete a plugin.
+* `POST /node/(id or name)/update` now accepts both `id` or `name` to identify the node to update.
+* `GET /images/json` now support a `reference` filter.
+* `GET /secrets` returns information on the secrets.
+* `POST /secrets/create` creates a secret.
+* `DELETE /secrets/{id}` removes the secret `id`.
+* `GET /secrets/{id}` returns information on the secret `id`.
+* `POST /secrets/{id}/update` updates the secret `id`.
+* `POST /services/(id or name)/update` now accepts service name or prefix of service id as a parameter.
+* `POST /containers/create` added 2 built-in log-opts that work on all logging drivers,
+  `mode` (`blocking`|`non-blocking`), and `max-buffer-size` (e.g. `2m`) which enables a non-blocking log buffer.
+* `POST /containers/create` now takes `HostConfig.Init` field to run an init
+  inside the container that forwards signals and reaps processes.
+
+## v1.24 API changes
+
+* `POST /containers/create` now takes `StorageOpt` field.
+* `GET /info` now returns `SecurityOptions` field, showing if `apparmor`, `seccomp`, or `selinux` is supported.
+* `GET /info` no longer returns the `ExecutionDriver` property. This property was no longer used after integration
+  with ContainerD in Docker 1.11.
+* `GET /networks` now supports filtering by `label` and `driver`.
+* `GET /containers/json` now supports filtering containers by `network` name or id.
+* `POST /containers/create` now takes `IOMaximumBandwidth` and `IOMaximumIOps` fields. Windows daemon only.
+* `POST /containers/create` now returns an HTTP 400 "bad parameter" message
+  if no command is specified (instead of an HTTP 500 "server error")
+* `GET /images/search` now takes a `filters` query parameter.
+* `GET /events` now supports a `reload` event that is emitted when the daemon configuration is reloaded.
+* `GET /events` now supports filtering by daemon name or ID.
+* `GET /events` now supports a `detach` event that is emitted on detaching from container process.
+* `GET /events` now supports an `exec_detach ` event that is emitted on detaching from exec process.
+* `GET /images/json` now supports filters `since` and `before`.
+* `POST /containers/(id or name)/start` no longer accepts a `HostConfig`.
+* `POST /images/(name)/tag` no longer has a `force` query parameter.
+* `GET /images/search` now supports maximum returned search results `limit`.
+* `POST /containers/{name:.*}/copy` is now removed and errors out starting from this API version.
+* API errors are now returned as JSON instead of plain text.
+* `POST /containers/create` and `POST /containers/(id)/start` allow you to configure kernel parameters (sysctls) for use in the container.
+* `POST /containers/<container ID>/exec` and `POST /exec/<exec ID>/start`
+  no longer expects a "Container" field to be present. This property was not used
+  and is no longer sent by the docker client.
+* `POST /containers/create/` now validates the hostname (should be a valid RFC 1123 hostname).
+* `POST /containers/create/` `HostConfig.PidMode` field now accepts `container:<name|id>`,
+  to have the container join the PID namespace of an existing container.
+
+## v1.23 API changes
+
+* `GET /containers/json` returns the state of the container, one of `created`, `restarting`, `running`, `paused`, `exited` or `dead`.
+* `GET /containers/json` returns the mount points for the container.
+* `GET /networks/(name)` now returns an `Internal` field showing whether the network is internal or not.
+* `GET /networks/(name)` now returns an `EnableIPv6` field showing whether the network has ipv6 enabled or not.
+* `POST /containers/(name)/update` now supports updating container's restart policy.
+* `POST /networks/create` now supports enabling ipv6 on the network by setting the `EnableIPv6` field (doing this with a label will no longer work).
+* `GET /info` now returns `CgroupDriver` field showing what cgroup driver the daemon is using; `cgroupfs` or `systemd`.
+* `GET /info` now returns `KernelMemory` field, showing if "kernel memory limit" is supported.
+* `POST /containers/create` now takes `PidsLimit` field, if the kernel is >= 4.3 and the pids cgroup is supported.
+* `GET /containers/(id or name)/stats` now returns `pids_stats`, if the kernel is >= 4.3 and the pids cgroup is supported.
+* `POST /containers/create` now allows you to override usernamespaces remapping and use privileged options for the container.
+* `POST /containers/create` now allows specifying `nocopy` for named volumes, which disables automatic copying from the container path to the volume.
+* `POST /auth` now returns an `IdentityToken` when supported by a registry.
+* `POST /containers/create` with both `Hostname` and `Domainname` fields specified will result in the container's hostname being set to `Hostname`, rather than `Hostname.Domainname`.
+* `GET /volumes` now supports more filters, new added filters are `name` and `driver`.
+* `GET /containers/(id or name)/logs` now accepts a `details` query parameter to stream the extra attributes that were provided to the containers `LogOpts`, such as environment variables and labels, with the logs.
+* `POST /images/load` now returns progress information as a JSON stream, and has a `quiet` query parameter to suppress progress details.
+
+## v1.22 API changes
+
+* The `HostConfig.LxcConf` field has been removed, and is no longer available on
+  `POST /containers/create` and `GET /containers/(id)/json`.
+* `POST /container/(name)/update` updates the resources of a container.
+* `GET /containers/json` supports filter `isolation` on Windows.
+* `GET /containers/json` now returns the list of networks of containers.
+* `GET /info` Now returns `Architecture` and `OSType` fields, providing information
+  about the host architecture and operating system type that the daemon runs on.
+* `GET /networks/(name)` now returns a `Name` field for each container attached to the network.
+* `GET /version` now returns the `BuildTime` field in RFC3339Nano format to make it
+  consistent with other date/time values returned by the API.
+* `AuthConfig` now supports a `registrytoken` for token based authentication
+* `POST /containers/create` now has a 4M minimum value limit for `HostConfig.KernelMemory`
+* Pushes initiated with `POST /images/(name)/push` and pulls initiated with `POST /images/create`
+  will be cancelled if the HTTP connection making the API request is closed before
+  the push or pull completes.
+* `POST /containers/create` now allows you to set a read/write rate limit for a
+  device (in bytes per second or IO per second).
+* `GET /networks` now supports filtering by `name`, `id` and `type`.
+* `POST /containers/create` now allows you to set the static IPv4 and/or IPv6 address for the container.
+* `POST /networks/(id)/connect` now allows you to set the static IPv4 and/or IPv6 address for the container.
+* `GET /info` now includes the number of containers running, stopped, and paused.
+* `POST /networks/create` now supports restricting external access to the network by setting the `Internal` field.
+* `POST /networks/(id)/disconnect` now includes a `Force` option to forcefully disconnect a container from network
+* `GET /containers/(id)/json` now returns the `NetworkID` of containers.
+* `POST /networks/create` Now supports an options field in the IPAM config that provides options
+  for custom IPAM plugins.
+* `GET /networks/{network-id}` Now returns IPAM config options for custom IPAM plugins if any
+  are available.
+* `GET /networks/<network-id>` now returns subnets info for user-defined networks.
+* `GET /info` can now return a `SystemStatus` field useful for returning additional information about applications
+  that are built on top of engine.
+
+## v1.21 API changes
+
+* `GET /volumes` lists volumes from all volume drivers.
+* `POST /volumes/create` to create a volume.
+* `GET /volumes/(name)` get low-level information about a volume.
+* `DELETE /volumes/(name)` remove a volume with the specified name.
+* `VolumeDriver` was moved from `config` to `HostConfig` to make the configuration portable.
+* `GET /images/(name)/json` now returns information about an image's `RepoTags` and `RepoDigests`.
+* The `config` option now accepts the field `StopSignal`, which specifies the signal to use to kill a container.
+* `GET /containers/(id)/stats` will return networking information respectively for each interface.
+* The `HostConfig` option now includes the `DnsOptions` field to configure the container's DNS options.
+* `POST /build` now optionally takes a serialized map of build-time variables.
+* `GET /events` now includes a `timenano` field, in addition to the existing `time` field.
+* `GET /events` now supports filtering by image and container labels.
+* `GET /info` now lists engine version information and return the information of `CPUShares` and `Cpuset`.
+* `GET /containers/json` will return `ImageID` of the image used by container.
+* `POST /exec/(name)/start` will now return an HTTP 409 when the container is either stopped or paused.
+* `POST /containers/create` now takes `KernelMemory` in HostConfig to specify kernel memory limit.
+* `GET /containers/(name)/json` now accepts a `size` parameter. Setting this parameter to '1' returns container size information in the `SizeRw` and `SizeRootFs` fields.
+* `GET /containers/(name)/json` now returns a `NetworkSettings.Networks` field,
+  detailing network settings per network. This field deprecates the
+  `NetworkSettings.EndpointID`, `NetworkSettings.Gateway`, `NetworkSettings.GlobalIPv6Address`,
+  `NetworkSettings.GlobalIPv6PrefixLen` `NetworkSettings.IPAddress`, `NetworkSettings.IPPrefixLen`,
+  `NetworkSettings.IPv6Gateway`, `NetworkSettings.MacAddress` fields, which are
+  still returned for backward-compatibility, but will be removed in a future version.
+* `GET /exec/(id)/json` now returns a `NetworkSettings.Networks` field,
+  detailing networksettings per network. This field deprecates the
+  `NetworkSettings.Gateway`, `NetworkSettings.IPAddress`,
+  `NetworkSettings.IPPrefixLen`, and `NetworkSettings.MacAddress` fields, which
+  are still returned for backward-compatibility, but will be removed in a future version.
+* The `HostConfig` option now includes the `OomScoreAdj` field for adjusting the
+  badness heuristic. This heuristic selects which processes the OOM killer kills
+  under out-of-memory conditions.
+
+## v1.20 API changes
+
+* `GET /containers/(id)/archive` get an archive of filesystem content from a container.
+* `PUT /containers/(id)/archive` upload an archive of content to be extracted to
+an existing directory inside a container's filesystem.
+* `POST /containers/(id)/copy` is deprecated in favor of the above `archive`
+endpoint which can be used to download files and directories from a container.
+* The `hostConfig` option now accepts the field `GroupAdd`, which specifies a
+list of additional groups that the container process will run as.
+
+## v1.19 API changes
+
+* When the daemon detects a version mismatch with the client, usually when
+the client is newer than the daemon, an HTTP 400 is now returned instead
+of a 404.
+* `GET /containers/(id)/stats` now accepts `stream` bool to get only one set of stats and disconnect.
+* `GET /containers/(id)/logs` now accepts a `since` timestamp parameter.
+* `GET /info` The fields `Debug`, `IPv4Forwarding`, `MemoryLimit`, and
+`SwapLimit` are now returned as boolean instead of as an int. In addition, the
+end point now returns the new boolean fields `CpuCfsPeriod`, `CpuCfsQuota`, and
+`OomKillDisable`.
+* The `hostConfig` option now accepts the fields `CpuPeriod` and `CpuQuota`
+* `POST /build` accepts `cpuperiod` and `cpuquota` options
+
+## v1.18 API changes
+
+* `GET /version` now returns `Os`, `Arch` and `KernelVersion`.
+* `POST /containers/create` and `POST /containers/(id)/start`allow you to  set ulimit settings for use in the container.
+* `GET /info` now returns `SystemTime`, `HttpProxy`,`HttpsProxy` and `NoProxy`.
+* `GET /images/json` added a `RepoDigests` field to include image digest information.
+* `POST /build` can now set resource constraints for all containers created for the build.
+* `CgroupParent` can be passed in the host config to setup container cgroups under a specific cgroup.
+* `POST /build` closing the HTTP request cancels the build
+* `POST /containers/(id)/exec` includes `Warnings` field to response.
+
+### v1.17 API changes
+
+* The build supports `LABEL` command. Use this to add metadata to an image. For
+  example you could add data describing the content of an image. `LABEL
+"com.example.vendor"="ACME Incorporated"`
+* `POST /containers/(id)/attach` and `POST /exec/(id)/start`
+* The Docker client now hints potential proxies about connection hijacking using HTTP Upgrade headers.
+* `POST /containers/create` sets labels on container create describing the container.
+* `GET /containers/json` returns the labels associated with the containers (`Labels`).
+* `GET /containers/(id)/json` returns the list current execs associated with the
+  container (`ExecIDs`). This endpoint now returns the container labels
+  (`Config.Labels`).
+* `POST /containers/(id)/rename` renames a container `id` to a new name.*
+* `POST /containers/create` and `POST /containers/(id)/start` callers can pass
+  `ReadonlyRootfs` in the host config to mount the container's root filesystem as
+  read only.
+* `GET /containers/(id)/stats` returns a live stream of a container's resource usage statistics.
+* `GET /images/json` returns the labels associated with each image (`Labels`).
+
+
+### v1.16 API changes
+
+* `GET /info` returns the number of CPUs available on the machine (`NCPU`),
+  total memory available (`MemTotal`), a user-friendly name describing the running Docker daemon (`Name`), a unique ID identifying the daemon (`ID`), and
+  a list of daemon labels (`Labels`).
+* `POST /containers/create` callers can set the new container's MAC address explicitly.
+* Volumes are now initialized when the container is created.
+* `POST /containers/(id)/copy` copies data which is contained in a volume.
+
+### v1.15 API changes
+
+* `POST /containers/create` can now set a container's `HostConfig` when creating a
+  container. Previously this was only available when starting a container.
+
+### v1.14 API changes
+
+* `DELETE /containers/(id)` when using `force`, the container will be immediately killed with SIGKILL.
+* `POST /containers/(id)/start` the `HostConfig` option accepts the field `CapAdd`, which specifies a list of capabilities
+  to add, and the field `CapDrop`, which specifies a list of capabilities to drop.
+* `POST /images/create` th `fromImage` and `repo` parameters support the
+  `repo:tag` format. Consequently,  the `tag` parameter is now obsolete. Using the
+  new format and the `tag` parameter at the same time will return an error.
+
+## v1.13 API changes
+
+* `GET /containers/(name)/json`
+
+**New!**
+The `HostConfig.Links` field is now filled correctly
+
+**New!**
+`Sockets` parameter added to the `/info` endpoint listing all the sockets the
+daemon is configured to listen on.
+
+`POST /containers/(name)/start`
+`POST /containers/(name)/stop`
+
+**New!**
+`start` and `stop` will now return 304 if the container's status is not modified
+
+`POST /commit`
+
+**New!**
+Added a `pause` parameter (default `true`) to pause the container during commit
+
+## v1.12 API changes
+
+- `POST /build` now supports a `forcerm` parameter to always remove containers.
+- `GET /containers/(name)/json`,`GET /images/(name)/json`: JSON keys are now in CamelCase.
+- `GET /images/search`: Trusted builds are now Automated Builds, and the `is_trusted`
+  field was renamed to `is_automated`.
+- The `POST /images/(name)/insert` endpoint has been removed.
+
+## v1.11 API changes
+
+### What's new
+
+- Add new `GET /_ping` endpoint to check if the API server is ready to accept connections.
+- `GET /events` now supports an `until` parameter to close connection after the given timestamp.
+- `GET /containers/(id)/logs` is now the preferred method for getting container logs.
+
+## v1.10 API changes
+
+- `DELETE /images/(name)` now provides a `force` parameter to force delete of an
+  image, even if it's tagged in multiple repositories.
+- `DELETE /images/(name)` now provides a `noprune` parameter to prevent the
+  deletion of parent images.
+- `DELETE /containers/(id)` now provides a `force` parameter to force deleting
+  a container, even if it is currently running.
+
+## v1.9 API changes
+
+- `POST /build` now takes a serialized ConfigFile which it uses to resolve the
+  proper registry auth credentials for pulling the base image. Clients which
+  previously implemented the version accepting an AuthConfig object must be
+  updated.
+
+## v1.8 API changes
+
+- `POST /build` now returns build status as JSON stream. In  case of a build error,
+  it returns the exit status of the failed command.
+- `GET /containers/(id)/json` now returns the host config for the container.
+- `POST /images/create`, `POST /images/(name)/insert` and `POST /images/(name)/push`
+  now include a `progressDetail` object in the JSON. It's now possible to get the
+  current value and the total of the progress without having to parse the string.
+
+## v1.7 API changes
+
+- The `GET /images/viz` endpoint was removed. The `images --viz` output is now
+  generated in the client, using the `GET /images/json` endpoint.
+- The `GET /images/json` response now returns a single entry per image with a 
+  nested attribute indicating the repo/tags that apply to that image.
+
+Instead of:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+        "VirtualSize": 131506275,
+        "Size": 131506275,
+        "Created": 1365714795,
+        "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+        "Tag": "12.04",
+        "Repository": "ubuntu"
+      },
+      {
+        "VirtualSize": 131506275,
+        "Size": 131506275,
+        "Created": 1365714795,
+        "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+        "Tag": "latest",
+        "Repository": "ubuntu"
+      }
+    ]
+
+The returned json looks like this:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+         "RepoTags": [
+           "ubuntu:12.04",
+           "ubuntu:latest"
+         ],
+         "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+         "Created": 1365714795,
+         "Size": 131506275,
+         "VirtualSize": 131506275
+      }
+    ]
+
+## v1.6 API changes
+
+### What's new
+
+- `POST /containers/(id)/attach` now provides a multiplexed response to allow
+  splitting stderr from stdout. This is done by prefixing a header to each
+  transmission. See the `POST /containers/(id)/attach` endpoint. The WebSocket
+  attach is unchanged. Note that attach calls on the previous API version didn't
+  change. Stdout and stderr are merged.
+
+## v1.5 API changes
+
+- `POST /images/create` now accepts registry credentials via an AuthConfig object
+  sent through the `X-Registry-Auth` header.
+- `POST /images/(name)/push` now requires the `AuthConfig` object to be passed
+  through the `X-Registry-Auth` instead of the request body.
+- `GET /containers/json` changed the format of the Ports entry to a list of dicts,
+  each containing PublicPort, PrivatePort and Type describing a port mapping.
+
+## v1.4 API changes
+
+- `POST /images/create` now downloads all images in parallel when pulling a repo.
+- `GET /containers/(id)/top` now accepts `ps` args, which is used by `docker top`,
+  for example, `docker top <container_id> aux`.
+- `GET /events` now includes the image's name.
+
+## v1.3 API changes
+
+- Add `GET /containers/(id)/top` endpoint to list the processes running inside
+  the container.
+- Add `GET /events` endpoint to monitor docker's events via streaming or via polling.
+- `GET /containers/json` now provides a `size=1` option to get the size of the containers.
+- `POST /containers/<id>/start` now accepts host-specific configuration (e.g., bind
+  mounts) in the POST body for start calls.
+- `POST /build`:
+  - Simplify the upload of the build context
+  - Simply stream a tarball instead of multipart upload with 4
+    intermediary buffers
+  - Simpler, less memory usage, less disk usage and faster
+
+> **Warning**:
+> The `POST /build` improvements are not reverse-compatible. Pre 1.3 clients will
+> break on `POST /build`.
+
+## v1.2 API changes
+
+- The auth configuration is now handled by the client, and clients must send
+  authConfig as body on `POST /images/(name)/push`.
+- `GET /auth` is now deprecated.
+- `POST /auth` now only checks the configuration but doesn't store it on the server
+- `POST /images/<name>/delete` now only untags the image if it has children and
+  removes all the untagged parents if has any.
+- `POST /images/<name>/delete` now returns a JSON structure with the list of 
+  images deleted/untagged.
+
+## v1.1 API changes
+
+`POST /images/create`, `POST /images/(name)/insert`, and `POST /images/(name)/push`
+now use a JSON stream instead of HTML hijack, it looks like this:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+    
+    {"status":"Pushing..."}
+    {"status":"Pushing", "progress":"1/? (n/a)"}
+    {"error":"Invalid..."}
+    ...
+
+## v1.0 API changes
+
+Initial version (docker [v0.3.3](https://github.com/docker/docker/commit/822056094aa31c224e78cd568e02fe5458a0eecc))
diff --git a/_vendor/github.com/moby/moby/api/docs/README.md b/_vendor/github.com/moby/moby/api/docs/README.md
new file mode 100644
index 000000000000..46bf79bdbef3
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/README.md
@@ -0,0 +1,26 @@
+# API Documentation
+
+This directory contains versioned documents for each version of the API
+specification supported by this module. While this module provides support
+for older API versions, support should be considered "best-effort", especially
+for very old versions. Users are recommended to use the latest API versions,
+and only rely on older API versions for compatibility with older clients.
+
+Newer API versions tend to be backward-compatible with older versions,
+with some exceptions where features were deprecated. For an overview
+of changes for each version, refer to [CHANGELOG.md](CHANGELOG.md).
+
+The latest version of the API specification can be found [at the root directory
+of this module](../swagger.yaml) which may contain unreleased changes.
+
+For API version v1.24, documentation is only available in markdown
+format, for later versions [Swagger (OpenAPI) v2.0](https://swagger.io/specification/v2/)
+specifications can be found in this directory. The Moby project itself
+primarily uses these swagger files to produce the API documentation;
+while we attempt to make these files match the actual implementation,
+the OpenAPI 2.0 specification has limitations that prevent us from
+expressing all options provided. There may be discrepancies (for which
+we welcome contributions). If you find bugs, or discrepancies, please
+open a ticket (or pull request).
+
+
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.0.md b/_vendor/github.com/moby/moby/api/docs/v1.0.md
new file mode 100644
index 000000000000..0ae774edd023
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.0.md
@@ -0,0 +1,993 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.0"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent = "smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.0
+
+# 1. Brief introduction
+
+-   The Remote API is replacing rcli
+-   Default port in the docker daemon is 2375
+-   The API tends to be REST, but for some complex commands, like attach
+    or pull, the HTTP connection is hijacked to transport stdout stdin
+    and stderr
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0"
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0"
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "centos:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0"
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "fedora:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0"
+             }
+        ]
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Dns":null,
+             "Image":"ubuntu",
+             "Volumes":{},
+             "VolumesFrom":""
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "VolumesFrom": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {}
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/start HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/(format)`
+
+List images `format` could be json or viz (json default)
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Repository":"ubuntu",
+                     "Tag":"precise",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658
+             },
+             {
+                     "Repository":"ubuntu",
+                     "Tag":"12.04",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658
+             }
+        ]
+
+**Example request**:
+
+        GET /images/viz HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        digraph docker {
+        "d82cbacda43a" -> "074be284591f"
+        "1496068ca813" -> "08306dc45919"
+        "08306dc45919" -> "0e7893146ac2"
+        "b750fe79269d" -> "1496068ca813"
+        base -> "27cf78414709" [style=invis]
+        "f71189fff3de" -> "9a33b36209ed"
+        "27cf78414709" -> "b750fe79269d"
+        "0e7893146ac2" -> "d6434d954665"
+        "d6434d954665" -> "d82cbacda43a"
+        base -> "e9aa60c60128" [style=invis]
+        "074be284591f" -> "f71189fff3de"
+        "b750fe79269d" [label="b750fe79269d\nubuntu",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "e9aa60c60128" [label="e9aa60c60128\ncentos",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "9a33b36209ed" [label="9a33b36209ed\nfedora",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        base [style=invisible]
+        }
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by defaul
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Insert a file in an image
+
+`POST /images/(name)/insert`
+
+Insert a file from `url` in the image `name` at `path`
+
+**Example request**:
+
+        POST /images/test/insert?path=/usr&url=myurl HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+        {{ TAR STREAM }}
+
+Query Parameters:
+
+-	**url** – The url from where the file is taken
+-	**path** – The path where the file is stored
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/centos/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "parent":"27cf784147099545",
+             "created":"2013-03-23T22:24:18.818426-07:00",
+             "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "container_config":
+                     {
+                             "Hostname":"",
+                             "User":"",
+                             "Memory":0,
+                             "MemorySwap":0,
+                             "AttachStdin":false,
+                             "AttachStdout":false,
+                             "AttachStderr":false,
+                             "PortSpecs":null,
+                             "Tty":true,
+                             "OpenStdin":true,
+                             "StdinOnce":false,
+                             "Env":null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns":null,
+                             "Image":"centos",
+                             "Volumes":null,
+                             "VolumesFrom":""
+                     }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/fedora/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+    > **Example request**:
+    >
+    >     POST /images/test/push HTTP/1.1
+    >
+    > **Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com)
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Name":"cespare/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"johnfuller/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"dhrp/mongodb-sshd",
+                     "Description":""
+             }
+        ]
+
+        :query term: term to search
+        :statuscode 200: no error
+        :statuscode 500: server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **t** – repository name to be applied to the resulting image in
+        case of success
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get default username and email
+
+`GET /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        GET /auth HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "username":"hannibal",
+             "email":"hannibal@a-team.com"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration and store i
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":"hannibal",
+             "password:"xxxx",
+             "email":"hannibal@a-team.com"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "MemoryLimit":true,
+             "SwapLimit":false
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Version":"0.2.2",
+             "GitCommit":"5a2a5cc+CHANGES",
+             "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+    >
+    > **Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+            "Cmd": ["cat", "/world"],
+            "PortSpecs":["22"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+        <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it
+    - Then retry to create the container
+
+- Start the container
+
+- If you are not in detached mode:
+    - Attach to the container, using logs=1 (to have stdout and
+          stderr from the container's start) and stream=1
+
+- If in detached mode or only stdin is attached:
+    - Display the container's
+
+## 3.2 Hijacking
+
+In this first version of the API, some of the endpoints, like /attach,
+/pull or /push uses hijacking to transport stdin, stdout and stderr on
+the same socket. This might change in the future.
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.1.md b/_vendor/github.com/moby/moby/api/docs/v1.1.md
new file mode 100644
index 000000000000..6f416de5d5e2
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.1.md
@@ -0,0 +1,1005 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.1"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent = "smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.1
+
+# 1. Brief introduction
+
+-   The Remote API is replacing rcli
+-   Default port in the docker daemon is 2375
+-   The API tends to be REST, but for some complex commands, like attach
+    or pull, the HTTP connection is hijacked to transport stdout stdin
+    and stderr
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0"
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0"
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "centos:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0"
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "fedora:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0"
+             }
+        ]
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Dns":null,
+             "Image":"ubuntu",
+             "Volumes":{},
+             "VolumesFrom":""
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "VolumesFrom": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {}
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/start HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/(format)`
+
+List images `format` could be json or viz (json default)
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Repository":"ubuntu",
+                     "Tag":"precise",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658
+             },
+             {
+                     "Repository":"ubuntu",
+                     "Tag":"12.04",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658
+             }
+        ]
+
+**Example request**:
+
+        GET /images/viz HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        digraph docker {
+        "d82cbacda43a" -> "074be284591f"
+        "1496068ca813" -> "08306dc45919"
+        "08306dc45919" -> "0e7893146ac2"
+        "b750fe79269d" -> "1496068ca813"
+        base -> "27cf78414709" [style=invis]
+        "f71189fff3de" -> "9a33b36209ed"
+        "27cf78414709" -> "b750fe79269d"
+        "0e7893146ac2" -> "d6434d954665"
+        "d6434d954665" -> "d82cbacda43a"
+        base -> "e9aa60c60128" [style=invis]
+        "074be284591f" -> "f71189fff3de"
+        "b750fe79269d" [label="b750fe79269d\nubuntu",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "e9aa60c60128" [label="e9aa60c60128\ncentos",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "9a33b36209ed" [label="9a33b36209ed\nfedora",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        base [style=invisible]
+        }
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by defaul
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pulling..."}
+        {"status":"Pulling", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Insert a file in an image
+
+`POST /images/(name)/insert`
+
+Insert a file from `url` in the image `name` at `path`
+
+**Example request**:
+
+        POST /images/test/insert?path=/usr&url=myurl HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Inserting..."}
+        {"status":"Inserting", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-	**url** – The url from where the file is taken
+-	**path** – The path where the file is stored
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/centos/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "parent":"27cf784147099545",
+             "created":"2013-03-23T22:24:18.818426-07:00",
+             "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "container_config":
+                     {
+                             "Hostname":"",
+                             "User":"",
+                             "Memory":0,
+                             "MemorySwap":0,
+                             "AttachStdin":false,
+                             "AttachStdout":false,
+                             "AttachStderr":false,
+                             "PortSpecs":null,
+                             "Tty":true,
+                             "OpenStdin":true,
+                             "StdinOnce":false,
+                             "Env":null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns":null,
+                             "Image":"centos",
+                             "Volumes":null,
+                             "VolumesFrom":""
+                     }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/fedora/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+    > **Example request**:
+    >
+    >     POST /images/test/push HTTP/1.1
+    >
+    > **Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pushing..."}
+        {"status":"Pushing", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com)
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Name":"cespare/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"johnfuller/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"dhrp/mongodb-sshd",
+                     "Description":""
+             }
+        ]
+
+        :query term: term to search
+        :statuscode 200: no error
+        :statuscode 500: server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+        {{ STREAM }}
+
+Query Parameters:
+
+     
+
+-   **t** – tag to be applied to the resulting image in case of
+        success
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get default username and email
+
+`GET /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        GET /auth HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "username":"hannibal",
+             "email":"hannibal@a-team.com"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration and store i
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":"hannibal",
+             "password:"xxxx",
+             "email":"hannibal@a-team.com"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "MemoryLimit":true,
+             "SwapLimit":false
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Version":"0.2.2",
+             "GitCommit":"5a2a5cc+CHANGES",
+             "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+            "Cmd": ["cat", "/world"],
+            "PortSpecs":["22"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+        <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+Here are the steps of `docker run` :
+
+ - Create the container
+
+ - If the status code is 404, it means the image doesn't exist:
+        - Try to pull it
+        - Then retry to create the container
+
+ - Start the container
+
+ - If you are not in detached mode:
+        - Attach to the container, using logs=1 (to have stdout and
+            stderr from the container's start) and stream=1
+
+ - If in detached mode or only stdin is attached:
+        - Display the container's
+
+## 3.2 Hijacking
+
+In this version of the API, /attach uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.10.md b/_vendor/github.com/moby/moby/api/docs/v1.10.md
new file mode 100644
index 000000000000..0119a51d258e
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.10.md
@@ -0,0 +1,1354 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.10"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent = "smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.10
+
+## 1. Brief introduction
+
+ - The Remote API has replaced rcli
+ - The daemon listens on `unix:///var/run/docker.sock` but you can bind
+   Docker to another host/port or a Unix socket.
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `stdout, stdin`
+   and `stderr`
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+     
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+    Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created containers, include non-running ones.
+-   **since** – Show only containers created since Id, include non-running ones.
+-   **before** – Show only containers created before Id, include non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers sizes
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Image":"ubuntu",
+             "Volumes":{
+                     "/tmp": {}
+             },
+             "WorkingDir":"",
+             "NetworkDisabled": false,
+             "ExposedPorts":{
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Query Parameters:
+
+     
+
+-   **name** – Assign the specified name to the container. Mus
+        match `/?[a-zA-Z0-9_-]+`.
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "WorkingDir":""
+
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {},
+                     "HostConfig": {
+                         "Binds": null,
+                         "ContainerIDFile": "",
+                         "LxcConf": [],
+                         "Privileged": false,
+                         "PortBindings": {
+                            "80/tcp": [
+                                {
+                                    "HostIp": "0.0.0.0",
+                                    "HostPort": "49153"
+                                }
+                            ]
+                         },
+                         "Links": null,
+                         "PublishAllPorts": false
+                     }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id)/top`
+
+List processes running inside the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Titles": [
+                     "USER",
+                     "PID",
+                     "%CPU",
+                     "%MEM",
+                     "VSZ",
+                     "RSS",
+                     "TTY",
+                     "STAT",
+                     "START",
+                     "TIME",
+                     "COMMAND"
+                     ],
+             "Processes": [
+                     ["root","20147","0.0","0.1","18060","1864","pts/4","S","10:06","0:00","bash"],
+                     ["root","20271","0.0","0.0","4312","352","pts/4","S+","10:07","0:00","sleep","10"]
+             ]
+        }
+
+Query Parameters:
+
+     
+
+-   **ps\_args** – ps arguments to use (e.g., aux)
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id` 's filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/(id)/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds":["/tmp:/tmp"],
+             "LxcConf":[{"Key":"lxc.utsname","Value":"docker"}],
+             "PortBindings":{ "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts":false,
+             "Privileged":false,
+             "Dns": ["8.8.8.8"],
+             "VolumesFrom": ["parent", "other:ro"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain
+
+Json Parameters:
+
+     
+
+-   **hostConfig** – the container's host configuration (optional)
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters
+
+-   **signal** - Signal to send to the container: integer or string like "SIGINT".
+    When not set, SIGKILL is assumed and the call will wait for the container to exit.
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`
+](docker_remote_api_v1.9.md#create-a-container),
+    the stream is the raw data from the process PTY and client's stdin.
+    When the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1)
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns
+    the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+ `DELETE /containers/(id*)
+:   Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+-   **force** – 1/True/true or 0/False/false, Removes the container
+        even if it was running. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### 2.2 Images
+
+### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+             "RepoTags": [
+               "ubuntu:12.04",
+               "ubuntu:precise",
+               "ubuntu:latest"
+             ],
+             "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+             "Created": 1365714795,
+             "Size": 131506275,
+             "VirtualSize": 131506275
+          },
+          {
+             "RepoTags": [
+               "ubuntu:12.10",
+               "ubuntu:quantal"
+             ],
+             "ParentId": "27cf784147099545",
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Created": 1364102658,
+             "Size": 24653,
+             "VirtualSize": 180116135
+          }
+        ]
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing
+    i
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pulling..."}
+        {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+        {"error": "Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Request Headers:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Insert a file in an image
+
+`POST /images/(name)/insert`
+
+Insert a file from `url` in the image
+    `name` at `path`
+
+**Example request**:
+
+        POST /images/test/insert?path=/usr&url=myurl HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Inserting..."}
+        {"status":"Inserting", "progress":"1/? (n/a)", "progressDetail":{"current":1}}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-	**url** – The url from where the file is taken
+-	**path** – The path where the file is stored
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "parent":"27cf784147099545",
+             "created":"2013-03-23T22:24:18.818426-07:00",
+             "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "container_config":
+                     {
+                             "Hostname":"",
+                             "User":"",
+                             "Memory":0,
+                             "MemorySwap":0,
+                             "AttachStdin":false,
+                             "AttachStdout":false,
+                             "AttachStderr":false,
+                             "PortSpecs":null,
+                             "Tty":true,
+                             "OpenStdin":true,
+                             "StdinOnce":false,
+                             "Env":null,
+                             "Cmd": ["/bin/bash"]
+                             "Image":"ubuntu",
+                             "Volumes":null,
+                             "WorkingDir":""
+                     },
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pushing..."}
+        {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+        {"error": "Invalid..."}
+        ...
+
+    If you wish to push an image on to a private registry, that image must already have been tagged
+    into a repository which references that registry host name and port.  This repository name should
+    then be used in the URL. This mirrors the flow of the CLI.
+
+**Example request**:
+
+        POST /images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+Query Parameters:
+
+-   **tag** – the tag to associate with the image on the registry, optional
+
+Request Headers:
+
+-   **X-Registry-Auth** – include a base64-encoded AuthConfig object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+ `DELETE /images/(name*)
+:   Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Query Parameters:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "wma55/u1210sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "jdswinbank/sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "vgauthier/sshd",
+                    "star_count": 0
+                }
+        ...
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"stream": "Step 1..."}
+        {"stream": "..."}
+        {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+
+    The archive must include a file called `Dockerfile`
+ at its root. It may include any number of other files,
+    which will be accessible in the build context (See the [*ADD build
+    command*](../../reference/builder.md#add)).
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – git or HTTP/HTTPS URI build source
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+-   **rm** - remove intermediate containers after a successful build
+
+    Request Headers:
+
+-   **Content-type** – should be set to `"application/tar"`.
+-   **X-Registry-Config** – base64-encoded ConfigFile object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "MemoryLimit":true,
+             "SwapLimit":false,
+             "IPv4Forwarding":true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Version":"0.2.2",
+             "GitCommit":"5a2a5cc+CHANGES",
+             "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Volumes":{
+                     "/tmp": {}
+             },
+             "WorkingDir":"",
+             "NetworkDisabled": false,
+             "ExposedPorts":{
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+            Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+
+Json Parameters:
+
+
+
+-  **config** - the container's configuration
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+        <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images and tags in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository
+    specified by `name`.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/ubuntu/get
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into the docker repository.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        POST /images/load
+
+        Tarball in body
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing three files:
+
+1. `VERSION`: currently `1.0` - the file format version
+2. `json`: detailed layer information, similar to `docker inspect layer_id`
+3. `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file will contain `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, there will also be a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+Here are the steps of `docker run` :
+
+ - Create the container
+
+ - If the status code is 404, it means the image doesn't exist:
+        - Try to pull it
+        - Then retry to create the container
+
+ - Start the container
+
+ - If you are not in detached mode:
+        - Attach to the container, using logs=1 (to have stdout and
+            stderr from the container's start) and stream=1
+
+ - If in detached mode or only stdin is attached:
+        - Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.11.md b/_vendor/github.com/moby/moby/api/docs/v1.11.md
new file mode 100644
index 000000000000..903bf5d0671c
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.11.md
@@ -0,0 +1,1385 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.11"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent = "smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.11
+
+## 1. Brief introduction
+
+ - The Remote API has replaced `rcli`.
+ - The daemon listens on `unix:///var/run/docker.sock` but you can bind
+   Docker to another host/port or a Unix socket.
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `STDOUT`, `STDIN`
+   and `STDERR`.
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+     
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+    Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created containers, include non-running ones.
+-   **since** – Show only containers created since Id, include non-running ones.
+-   **before** – Show only containers created before Id, include non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers sizes
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Image":"ubuntu",
+             "Volumes":{
+                     "/tmp": {}
+             },
+             "VolumesFrom":"",
+             "WorkingDir":"",
+             "DisableNetwork": false,
+             "ExposedPorts":{
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Query Parameters:
+
+-   **name** – Assign the specified name to the container. Mus
+        match `/?[a-zA-Z0-9_-]+`.
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {},
+                     "HostConfig": {
+                         "Binds": null,
+                         "ContainerIDFile": "",
+                         "LxcConf": [],
+                         "Privileged": false,
+                         "PortBindings": {
+                            "80/tcp": [
+                                {
+                                    "HostIp": "0.0.0.0",
+                                    "HostPort": "49153"
+                                }
+                            ]
+                         },
+                         "Links": null,
+                         "PublishAllPorts": false
+                     }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id)/top`
+
+List processes running inside the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Titles": [
+                     "USER",
+                     "PID",
+                     "%CPU",
+                     "%MEM",
+                     "VSZ",
+                     "RSS",
+                     "TTY",
+                     "STAT",
+                     "START",
+                     "TIME",
+                     "COMMAND"
+                     ],
+             "Processes": [
+                     ["root","20147","0.0","0.1","18060","1864","pts/4","S","10:06","0:00","bash"],
+                     ["root","20271","0.0","0.0","4312","352","pts/4","S+","10:07","0:00","sleep","10"]
+             ]
+        }
+
+Query Parameters:
+
+-   **ps_args** – ps arguments to use (e.g., aux)
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Get container logs
+
+`GET /containers/(id)/logs`
+
+Get stdout and stderr logs from the container ``id``
+
+**Example request**:
+
+       GET /containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1 HTTP/1.1
+
+**Example response**:
+
+       HTTP/1.1 200 OK
+       Content-Type: application/vnd.docker.raw-stream
+
+       {{ STREAM }}
+
+Query Parameters:
+
+     
+
+-   **follow** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log. Default false
+-   **timestamps** – 1/True/true or 0/False/false, if logs=true, prin
+        timestamps for every log line. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/(id)/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds":["/tmp:/tmp"],
+             "LxcConf":[{"Key":"lxc.utsname","Value":"docker"}],
+             "PortBindings":{ "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts":false,
+             "Privileged":false,
+             "Dns": ["8.8.8.8"],
+             "VolumesFrom": ["parent", "other:ro"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain
+
+Json Parameters:
+
+     
+
+-   **hostConfig** – the container's host configuration (optional)
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters
+
+-   **signal** - Signal to send to the container: integer or string like "SIGINT".
+    When not set, SIGKILL is assumed and the call will wait for the container to exit.
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`
+    ](docker_remote_api_v1.9.md#create-a-container),
+    the stream is the raw data from the process PTY and client's stdin.
+    When the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1)
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+-   **force** – 1/True/true or 0/False/false, Removes the container
+        even if it was running. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+             "RepoTags": [
+               "ubuntu:12.04",
+               "ubuntu:precise",
+               "ubuntu:latest"
+             ],
+             "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+             "Created": 1365714795,
+             "Size": 131506275,
+             "VirtualSize": 131506275
+          },
+          {
+             "RepoTags": [
+               "ubuntu:12.10",
+               "ubuntu:quantal"
+             ],
+             "ParentId": "27cf784147099545",
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Created": 1364102658,
+             "Size": 24653,
+             "VirtualSize": 180116135
+          }
+        ]
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pulling..."}
+        {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+        {"error": "Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Request Headers:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "parent":"27cf784147099545",
+             "created":"2013-03-23T22:24:18.818426-07:00",
+             "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "container_config":
+                     {
+                             "Hostname":"",
+                             "User":"",
+                             "Memory":0,
+                             "MemorySwap":0,
+                             "AttachStdin":false,
+                             "AttachStdout":false,
+                             "AttachStderr":false,
+                             "PortSpecs":null,
+                             "Tty":true,
+                             "OpenStdin":true,
+                             "StdinOnce":false,
+                             "Env":null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns":null,
+                             "Image":"ubuntu",
+                             "Volumes":null,
+                             "VolumesFrom":"",
+                             "WorkingDir":""
+                     },
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pushing..."}
+        {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+        {"error": "Invalid..."}
+        ...
+
+    If you wish to push an image on to a private registry, that image must already have been tagged
+    into a repository which references that registry host name and port.  This repository name should
+    then be used in the URL. This mirrors the flow of the CLI.
+
+**Example request**:
+
+        POST /images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+Query Parameters:
+
+-   **tag** – the tag to associate with the image on the registry, optional
+
+Request Headers:
+
+-   **X-Registry-Auth** – include a base64-encoded AuthConfig object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Query Parameters:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "wma55/u1210sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "jdswinbank/sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "vgauthier/sshd",
+                    "star_count": 0
+                }
+        ...
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"stream": "Step 1..."}
+        {"stream": "..."}
+        {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+
+    The archive must include a file called `Dockerfile`
+    at its root. It may include any number of other files,
+    which will be accessible in the build context (See the [*ADD build
+    command*](../../reference/builder.md#dockerbuilder)).
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – git or HTTP/HTTPS URI build source
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+-   **rm** - remove intermediate containers after a successful build
+
+    Request Headers:
+
+-   **Content-type** – should be set to `"application/tar"`.
+-   **X-Registry-Config** – base64-encoded ConfigFile object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers": 11,
+             "Images": 16,
+             "Driver": "btrfs",
+             "ExecutionDriver": "native-0.1",
+             "KernelVersion": "3.12.0-1-amd64"
+             "Debug": false,
+             "NFd": 11,
+             "NGoroutines": 21,
+             "NEventsListener": 0,
+             "InitPath": "/usr/bin/docker",
+             "IndexServerAddress": ["https://index.docker.io/v1/"],
+             "MemoryLimit": true,
+             "SwapLimit": false,
+             "IPv4Forwarding": true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Version":"0.2.2",
+             "GitCommit":"5a2a5cc+CHANGES",
+             "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+        GET /_ping HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        OK
+
+Status Codes:
+
+-   **200** - no error
+-   **500** - server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Volumes":{
+                     "/tmp": {}
+             },
+             "WorkingDir":"",
+             "DisableNetwork": false,
+             "ExposedPorts":{
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+Json Parameters:
+
+-  **config** - the container's configuration
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+-   **until** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images and tags in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository
+specified by `name`.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/ubuntu/get
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into the docker repository.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        POST /images/load
+
+        Tarball in body
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing three files:
+
+1. `VERSION`: currently `1.0` - the file format version
+2. `json`: detailed layer information, similar to `docker inspect layer_id`
+3. `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file will contain `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, there will also be a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it
+    - Then retry to create the container
+
+- Start the container
+
+- If you are not in detached mode:
+    - Attach to the container, using logs=1 (to have stdout and
+      stderr from the container's start) and stream=1
+
+- If in detached mode or only stdin is attached:
+    - Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.12.md b/_vendor/github.com/moby/moby/api/docs/v1.12.md
new file mode 100644
index 000000000000..9272346b136e
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.12.md
@@ -0,0 +1,1450 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.12"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent = "smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.12
+
+## 1. Brief introduction
+
+ - The Remote API has replaced `rcli`.
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](../../articles/basics.md#bind-docker-to-another-hostport-or-a-unix-socket).
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `STDOUT`,
+   `STDIN` and `STDERR`.
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by defaul
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers
+        sizes
+-   **filters** – a JSON encoded value of the filters (a map[string][]string)
+        to process on the images list.
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "Domainname": "",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Image":"ubuntu",
+             "Volumes":{
+                     "/tmp": {}
+             },
+             "WorkingDir":"",
+             "NetworkDisabled": false,
+             "ExposedPorts":{
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Query Parameters:
+
+     
+
+-   **name** – Assign the specified name to the container. Mus
+        match `/?[a-zA-Z0-9_-]+`.
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {},
+                     "HostConfig": {
+                         "Binds": null,
+                         "ContainerIDFile": "",
+                         "LxcConf": [],
+                         "Privileged": false,
+                         "PortBindings": {
+                            "80/tcp": [
+                                {
+                                    "HostIp": "0.0.0.0",
+                                    "HostPort": "49153"
+                                }
+                            ]
+                         },
+                         "Links": null,
+                         "PublishAllPorts": false
+                     }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id)/top`
+
+List processes running inside the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Titles": [
+                     "USER",
+                     "PID",
+                     "%CPU",
+                     "%MEM",
+                     "VSZ",
+                     "RSS",
+                     "TTY",
+                     "STAT",
+                     "START",
+                     "TIME",
+                     "COMMAND"
+                     ],
+             "Processes": [
+                     ["root","20147","0.0","0.1","18060","1864","pts/4","S","10:06","0:00","bash"],
+                     ["root","20271","0.0","0.0","4312","352","pts/4","S+","10:07","0:00","sleep","10"]
+             ]
+        }
+
+Query Parameters:
+
+-   **ps_args** – ps arguments to use (e.g., aux)
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Get container logs
+
+`GET /containers/(id)/logs`
+
+Get stdout and stderr logs from the container ``id``
+
+**Example request**:
+
+       GET /containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1 HTTP/1.1
+
+**Example response**:
+
+       HTTP/1.1 200 OK
+       Content-Type: application/vnd.docker.raw-stream
+
+       {{ STREAM }}
+
+Query Parameters:
+
+     
+
+-   **follow** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log. Default false
+-   **timestamps** – 1/True/true or 0/False/false, if logs=true, prin
+        timestamps for every log line. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/(id)/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds":["/tmp:/tmp"],
+             "Links":["redis3:redis"],
+             "LxcConf":[{"Key":"lxc.utsname","Value":"docker"}],
+             "PortBindings":{ "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts":false,
+             "Privileged":false,
+             "Dns": ["8.8.8.8"],
+             "VolumesFrom": ["parent", "other:ro"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain
+
+Json Parameters:
+
+     
+
+-   **hostConfig** – the container's host configuration (optional)
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters
+
+-   **signal** - Signal to send to the container: integer or string like "SIGINT".
+    When not set, SIGKILL is assumed and the call will wait for the container to exit.
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Pause a container
+
+`POST /containers/(id)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Unpause a container
+
+`POST /containers/(id)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream. Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach to stdin.
+    Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+    stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+    stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`
+    ](docker_remote_api_v1.9.md#create-a-container),
+    the stream is the raw data from the process PTY and client's stdin.
+    When the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+-   **force** – 1/True/true or 0/False/false, Removes the container
+        even if it was running. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+             "RepoTags": [
+               "ubuntu:12.04",
+               "ubuntu:precise",
+               "ubuntu:latest"
+             ],
+             "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+             "Created": 1365714795,
+             "Size": 131506275,
+             "VirtualSize": 131506275
+          },
+          {
+             "RepoTags": [
+               "ubuntu:12.10",
+               "ubuntu:quantal"
+             ],
+             "ParentId": "27cf784147099545",
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Created": 1364102658,
+             "Size": 24653,
+             "VirtualSize": 180116135
+          }
+        ]
+
+
+Query Parameters:
+
+     
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a json encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   dangling=true
+-   **filter** - only return images with the specified name
+
+
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pulling..."}
+        {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+        {"error": "Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Request Headers:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Created": "2013-03-23T22:24:18.818426-07:00",
+             "Container": "3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "ContainerConfig":
+                     {
+                             "Hostname": "",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": false,
+                             "AttachStderr": false,
+                             "PortSpecs": null,
+                             "Tty": true,
+                             "OpenStdin": true,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": null,
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Parent": "27cf784147099545",
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pushing..."}
+        {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+        {"error": "Invalid..."}
+        ...
+
+    If you wish to push an image on to a private registry, that image must already have been tagged
+    into a repository which references that registry host name and port.  This repository name should
+    then be used in the URL. This mirrors the flow of the CLI.
+
+**Example request**:
+
+        POST /images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+Query Parameters:
+
+-   **tag** – the tag to associate with the image on the registry, optional
+
+Request Headers:
+
+-   **X-Registry-Auth** – include a base64-encoded AuthConfig object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Query Parameters:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "wma55/u1210sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "jdswinbank/sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "vgauthier/sshd",
+                    "star_count": 0
+                }
+        ...
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"stream": "Step 1..."}
+        {"stream": "..."}
+        {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+
+    The archive must include a file called `Dockerfile`
+    at its root. It may include any number of other files,
+    which will be accessible in the build context (See the [*ADD build
+    command*](../../reference/builder.md#dockerbuilder)).
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – git or HTTP/HTTPS URI build source
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+-   **rm** - remove intermediate containers after a successful build (default behavior)
+-   **forcerm** - always remove intermediate containers (includes rm)
+
+    Request Headers:
+
+-   **Content-type** – should be set to `"application/tar"`.
+-   **X-Registry-Config** – base64-encoded ConfigFile object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers": 11,
+             "Images": 16,
+             "Driver": "btrfs",
+             "ExecutionDriver": "native-0.1",
+             "KernelVersion": "3.12.0-1-amd64"
+             "Debug": false,
+             "NFd": 11,
+             "NGoroutines": 21,
+             "NEventsListener": 0,
+             "InitPath": "/usr/bin/docker",
+             "IndexServerAddress": ["https://index.docker.io/v1/"],
+             "MemoryLimit": true,
+             "SwapLimit": false,
+             "IPv4Forwarding": true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "ApiVersion": "1.12",
+             "Version": "0.2.2",
+             "GitCommit": "5a2a5cc+CHANGES",
+             "GoVersion": "go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+        GET /_ping HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        OK
+
+Status Codes:
+
+-   **200** - no error
+-   **500** - server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname": "",
+             "Domainname": "",
+             "User": "",
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin": false,
+             "AttachStdout": true,
+             "AttachStderr": true,
+             "PortSpecs": null,
+             "Tty": false,
+             "OpenStdin": false,
+             "StdinOnce": false,
+             "Env": null,
+             "Cmd": [
+                     "date"
+             ],
+             "Volumes": {
+                     "/tmp": {}
+             },
+             "WorkingDir": "",
+             "NetworkDisabled": false,
+             "ExposedPorts": {
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {"Id": "596069db4bf5"}
+
+Json Parameters:
+
+-  **config** - the container's configuration
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+-   **until** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images and tags in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository
+specified by `name`.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/ubuntu/get
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into the docker repository.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        POST /images/load
+
+        Tarball in body
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing three files:
+
+1. `VERSION`: currently `1.0` - the file format version
+2. `json`: detailed layer information, similar to `docker inspect layer_id`
+3. `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file will contain `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, there will also be a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it
+    - Then retry to create the container
+
+- Start the container
+
+- If you are not in detached mode:
+    - Attach to the container, using logs=1 (to have stdout and
+      stderr from the container's start) and stream=1
+
+- If in detached mode or only stdin is attached:
+    - Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.13.md b/_vendor/github.com/moby/moby/api/docs/v1.13.md
new file mode 100644
index 000000000000..a9b519d1897c
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.13.md
@@ -0,0 +1,1440 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.13"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent = "smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.13
+
+## 1. Brief introduction
+
+ - The Remote API has replaced `rcli`.
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](../../articles/basics.md#bind-docker-to-another-hostport-or-a-unix-socket).
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `STDOUT`,
+   `STDIN` and `STDERR`.
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+    Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created containers, include non-running ones.
+-   **since** – Show only containers created since Id, include non-running ones.
+-   **before** – Show only containers created before Id, include non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers sizes
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "Domainname": "",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Image":"ubuntu",
+             "Volumes":{
+                     "/tmp": {}
+             },
+             "WorkingDir":"",
+             "NetworkDisabled": false,
+             "ExposedPorts":{
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Query Parameters:
+
+     
+
+-   **name** – Assign the specified name to the container. Mus
+        match `/?[a-zA-Z0-9_-]+`.
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {},
+                     "HostConfig": {
+                         "Binds": null,
+                         "ContainerIDFile": "",
+                         "LxcConf": [],
+                         "Privileged": false,
+                         "PortBindings": {
+                            "80/tcp": [
+                                {
+                                    "HostIp": "0.0.0.0",
+                                    "HostPort": "49153"
+                                }
+                            ]
+                         },
+                         "Links": ["/name:alias"],
+                         "PublishAllPorts": false
+                     }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id)/top`
+
+List processes running inside the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Titles": [
+                     "USER",
+                     "PID",
+                     "%CPU",
+                     "%MEM",
+                     "VSZ",
+                     "RSS",
+                     "TTY",
+                     "STAT",
+                     "START",
+                     "TIME",
+                     "COMMAND"
+                     ],
+             "Processes": [
+                     ["root","20147","0.0","0.1","18060","1864","pts/4","S","10:06","0:00","bash"],
+                     ["root","20271","0.0","0.0","4312","352","pts/4","S+","10:07","0:00","sleep","10"]
+             ]
+        }
+
+Query Parameters:
+
+-   **ps_args** – ps arguments to use (e.g., aux)
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Get container logs
+
+`GET /containers/(id)/logs`
+
+Get stdout and stderr logs from the container ``id``
+
+**Example request**:
+
+       GET /containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10 HTTP/1.1
+
+**Example response**:
+
+       HTTP/1.1 200 OK
+       Content-Type: application/vnd.docker.raw-stream
+
+       {{ STREAM }}
+
+Query Parameters:
+
+-   **follow** – 1/True/true or 0/False/false, return stream. Default false
+-   **stdout** – 1/True/true or 0/False/false, show stdout log. Default false
+-   **stderr** – 1/True/true or 0/False/false, show stderr log. Default false
+-   **timestamps** – 1/True/true or 0/False/false, print timestamps for every
+    log line. Default false
+-   **tail** – Output specified number of lines at the end of logs: `all` or
+    `<number>`. Default all
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/(id)/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds":["/tmp:/tmp"],
+             "Links":["redis3:redis"],
+             "LxcConf":[{"Key":"lxc.utsname","Value":"docker"}],
+             "PortBindings":{ "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts":false,
+             "Privileged":false,
+             "Dns": ["8.8.8.8"],
+             "VolumesFrom": ["parent", "other:ro"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain
+
+Json Parameters:
+
+     
+
+-   **hostConfig** – the container's host configuration (optional)
+
+Status Codes:
+
+-   **204** – no error
+-   **304** – container already started
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **304** – container already stopped
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters
+
+-   **signal** - Signal to send to the container: integer or string like "SIGINT".
+    When not set, SIGKILL is assumed and the call will wait for the container to exit.
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Pause a container
+
+`POST /containers/(id)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Unpause a container
+
+`POST /containers/(id)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream. Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach to stdin.
+    Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+    stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+    stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`
+    ](docker_remote_api_v1.9.md#create-a-container),
+    the stream is the raw data from the process PTY and client's stdin.
+    When the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+-   **force** – 1/True/true or 0/False/false, Removes the container
+        even if it was running. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+             "RepoTags": [
+               "ubuntu:12.04",
+               "ubuntu:precise",
+               "ubuntu:latest"
+             ],
+             "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+             "Created": 1365714795,
+             "Size": 131506275,
+             "VirtualSize": 131506275
+          },
+          {
+             "RepoTags": [
+               "ubuntu:12.10",
+               "ubuntu:quantal"
+             ],
+             "ParentId": "27cf784147099545",
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Created": 1364102658,
+             "Size": 24653,
+             "VirtualSize": 180116135
+          }
+        ]
+
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a json encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   dangling=true
+-   **filter** - only return images with the specified name
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pulling it from the registry or by importing it
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pulling..."}
+        {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+        {"error": "Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Request Headers:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Created": "2013-03-23T22:24:18.818426-07:00",
+             "Container": "3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "ContainerConfig":
+                     {
+                             "Hostname": "",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": false,
+                             "AttachStderr": false,
+                             "PortSpecs": null,
+                             "Tty": true,
+                             "OpenStdin": true,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": null,
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Parent": "27cf784147099545",
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pushing..."}
+        {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+        {"error": "Invalid..."}
+        ...
+
+    If you wish to push an image on to a private registry, that image must already have been tagged
+    into a repository which references that registry host name and port.  This repository name should
+    then be used in the URL. This mirrors the flow of the CLI.
+
+**Example request**:
+
+        POST /images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+Query Parameters:
+
+-   **tag** – the tag to associate with the image on the registry, optional
+
+Request Headers:
+
+-   **X-Registry-Auth** – include a base64-encoded AuthConfig object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Query Parameters:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "wma55/u1210sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "jdswinbank/sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "vgauthier/sshd",
+                    "star_count": 0
+                }
+        ...
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"stream": "Step 1..."}
+        {"stream": "..."}
+        {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+
+    The archive must include a file called `Dockerfile`
+    at its root. It may include any number of other files,
+    which will be accessible in the build context (See the [*ADD build
+    command*](../../reference/builder.md#dockerbuilder)).
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – git or HTTP/HTTPS URI build source
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+-   **rm** - remove intermediate containers after a successful build (default behavior)
+-   **forcerm** - always remove intermediate containers (includes rm)
+
+    Request Headers:
+
+-   **Content-type** – should be set to `"application/tar"`.
+-   **X-Registry-Config** – base64-encoded ConfigFile object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers": 11,
+             "Images": 16,
+             "Driver": "btrfs",
+             "ExecutionDriver": "native-0.1",
+             "KernelVersion": "3.12.0-1-amd64"
+             "Debug": false,
+             "NFd": 11,
+             "NGoroutines": 21,
+             "NEventsListener": 0,
+             "InitPath": "/usr/bin/docker",
+             "IndexServerAddress": ["https://index.docker.io/v1/"],
+             "MemoryLimit": true,
+             "SwapLimit": false,
+             "IPv4Forwarding": true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "ApiVersion": "1.12",
+             "Version": "0.2.2",
+             "GitCommit": "5a2a5cc+CHANGES",
+             "GoVersion": "go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+        GET /_ping HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        OK
+
+Status Codes:
+
+-   **200** - no error
+-   **500** - server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname": "",
+             "Domainname": "",
+             "User": "",
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin": false,
+             "AttachStdout": true,
+             "AttachStderr": true,
+             "PortSpecs": null,
+             "Tty": false,
+             "OpenStdin": false,
+             "StdinOnce": false,
+             "Env": null,
+             "Cmd": [
+                     "date"
+             ],
+             "Volumes": {
+                     "/tmp": {}
+             },
+             "WorkingDir": "",
+             "NetworkDisabled": false,
+             "ExposedPorts": {
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {"Id": "596069db4bf5"}
+
+Json Parameters:
+
+-  **config** - the container's configuration
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+-   **until** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images and tags in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository
+specified by `name`.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/ubuntu/get
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into the docker repository.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        POST /images/load
+
+        Tarball in body
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing three files:
+
+1. `VERSION`: currently `1.0` - the file format version
+2. `json`: detailed layer information, similar to `docker inspect layer_id`
+3. `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file will contain `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, there will also be a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it
+    - Then retry to create the container
+
+- Start the container
+
+- If you are not in detached mode:
+    - Attach to the container, using logs=1 (to have stdout and
+      stderr from the container's start) and stream=1
+
+- If in detached mode or only stdin is attached:
+    - Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.14.md b/_vendor/github.com/moby/moby/api/docs/v1.14.md
new file mode 100644
index 000000000000..673ed844377b
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.14.md
@@ -0,0 +1,1469 @@
+<!--[metadata]>
++++
+title = "Remote API v1.14"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent = "engine_remoteapi"
+weight = 7
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.14
+
+## 1. Brief introduction
+
+ - The Remote API has replaced `rcli`.
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](../../quickstart.md#bind-docker-to-another-host-port-or-a-unix-socket).
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `STDOUT`,
+   `STDIN` and `STDERR`.
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+    Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created containers, include non-running ones.
+-   **since** – Show only containers created since Id, include non-running ones.
+-   **before** – Show only containers created before Id, include non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers sizes
+-   **filters** - a json encoded value of the filters (a map[string][]string) to process on the containers list. Available filters:
+  -   exited=&lt;int&gt; -- containers with exit code of &lt;int&gt;
+  -   status=(restarting|running|paused|exited)
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "Domainname": "",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env": [
+                     "FOO=bar",
+                     "BAZ=quux"
+             ],
+             "Cmd":[
+                     "date"
+             ],
+             "Image":"ubuntu",
+             "Volumes":{
+                     "/tmp": {}
+             },
+             "WorkingDir":"",
+             "NetworkDisabled": false,
+             "ExposedPorts":{
+                     "22/tcp": {}
+             },
+             "RestartPolicy": { "Name": "always" }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **RestartPolicy** – The behavior to apply when the container exits.  The
+        value is an object with a `Name` property of either `"always"` to
+        always restart or `"on-failure"` to restart only when the container
+        exit code is non-zero.  If `on-failure` is used, `MaximumRetryCount`
+        controls the number of times to retry before giving up.
+        The default is not to restart. (optional)
+        An ever increasing delay (double the previous delay, starting at 100mS)
+        is added before each restart to prevent flooding the server.
+-   **config** – the container's configuration
+
+Query Parameters:
+
+-   **name** – Assign the specified name to the container. Must match `/?[a-zA-Z0-9_-]+`.
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id or name)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {},
+                     "HostConfig": {
+                         "Binds": null,
+                         "ContainerIDFile": "",
+                         "LxcConf": [],
+                         "Privileged": false,
+                         "PortBindings": {
+                            "80/tcp": [
+                                {
+                                    "HostIp": "0.0.0.0",
+                                    "HostPort": "49153"
+                                }
+                            ]
+                         },
+                         "Links": ["/name:alias"],
+                         "PublishAllPorts": false,
+                         "CapAdd": ["NET_ADMIN"],
+                         "CapDrop": ["MKNOD"]
+                     }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id or name)/top`
+
+List processes running inside the container `id`. On Unix systems this
+is done by running the `ps` command. This endpoint is not
+supported on Windows.
+
+**Example request**:
+
+    GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Titles" : [
+         "UID", "PID", "PPID", "C", "STIME", "TTY", "TIME", "CMD"
+       ],
+       "Processes" : [
+         [
+           "root", "13642", "882", "0", "17:03", "pts/0", "00:00:00", "/bin/bash"
+         ],
+         [
+           "root", "13735", "13642", "0", "17:06", "pts/0", "00:00:00", "sleep 10"
+         ]
+       ]
+    }
+
+**Example request**:
+
+    GET /containers/4fa6e0f0c678/top?ps_args=aux HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Titles" : [
+        "USER","PID","%CPU","%MEM","VSZ","RSS","TTY","STAT","START","TIME","COMMAND"
+      ]
+      "Processes" : [
+        [
+          "root","13642","0.0","0.1","18172","3184","pts/0","Ss","17:03","0:00","/bin/bash"
+        ],
+        [
+          "root","13895","0.0","0.0","4348","692","pts/0","S+","17:15","0:00","sleep 10"
+        ]
+      ],
+    }
+
+Query Parameters:
+
+-   **ps_args** – `ps` arguments to use (e.g., `aux`), defaults to `-ef`
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Get container logs
+
+`GET /containers/(id or name)/logs`
+
+Get stdout and stderr logs from the container ``id``
+
+**Example request**:
+
+       GET /containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10 HTTP/1.1
+
+**Example response**:
+
+       HTTP/1.1 200 OK
+       Content-Type: application/vnd.docker.raw-stream
+
+       {{ STREAM }}
+
+Query Parameters:
+
+-   **follow** – 1/True/true or 0/False/false, return stream. Default false
+-   **stdout** – 1/True/true or 0/False/false, show stdout log. Default false
+-   **stderr** – 1/True/true or 0/False/false, show stderr log. Default false
+-   **timestamps** – 1/True/true or 0/False/false, print timestamps for every
+    log line. Default false
+-   **tail** – Output specified number of lines at the end of logs: `all` or
+    `<number>`. Default all
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id or name)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id or name)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id or name)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds":["/tmp:/tmp"],
+             "Links":["redis3:redis"],
+             "LxcConf":[{"Key":"lxc.utsname","Value":"docker"}],
+             "PortBindings":{ "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts":false,
+             "Privileged":false,
+             "Dns": ["8.8.8.8"],
+             "VolumesFrom": ["parent", "other:ro"],
+             "CapAdd": ["NET_ADMIN"],
+             "CapDrop": ["MKNOD"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Json Parameters:
+
+-   **hostConfig** – the container's host configuration (optional)
+
+Status Codes:
+
+-   **204** – no error
+-   **304** – container already started
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id or name)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **304** – container already stopped
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id or name)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id or name)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters
+
+-   **signal** - Signal to send to the container: integer or string like "SIGINT".
+    When not set, SIGKILL is assumed and the call will wait for the container to exit.
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Pause a container
+
+`POST /containers/(id or name)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Unpause a container
+
+`POST /containers/(id or name)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id or name)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream. Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach to stdin.
+    Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+    stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+    stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`](#create-a-container),
+    the stream is the raw data from the process PTY and client's stdin.
+    When the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1
+
+### Attach to a container (websocket)
+
+`GET /containers/(id or name)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id or name)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id or name)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+-   **force** - 1/True/true or 0/False/false, Kill then remove the container.
+        Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id or name)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+             "RepoTags": [
+               "ubuntu:12.04",
+               "ubuntu:precise",
+               "ubuntu:latest"
+             ],
+             "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+             "Created": 1365714795,
+             "Size": 131506275,
+             "VirtualSize": 131506275
+          },
+          {
+             "RepoTags": [
+               "ubuntu:12.10",
+               "ubuntu:quantal"
+             ],
+             "ParentId": "27cf784147099545",
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Created": 1364102658,
+             "Size": 24653,
+             "VirtualSize": 180116135
+          }
+        ]
+
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a json encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   dangling=true
+-   **filter** - only return images with the specified name
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pulling it from the registry or by importing it
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pulling..."}
+        {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+        {"error": "Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+
+Request Headers:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Created": "2013-03-23T22:24:18.818426-07:00",
+             "Container": "3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "ContainerConfig":
+                     {
+                             "Hostname": "",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": false,
+                             "AttachStderr": false,
+                             "PortSpecs": null,
+                             "Tty": true,
+                             "OpenStdin": true,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": null,
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Parent": "27cf784147099545",
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pushing..."}
+        {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+        {"error": "Invalid..."}
+        ...
+
+    If you wish to push an image on to a private registry, that image must already have been tagged
+    into a repository which references that registry host name and port.  This repository name should
+    then be used in the URL. This mirrors the flow of the CLI.
+
+**Example request**:
+
+        POST /images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+Query Parameters:
+
+-   **tag** – the tag to associate with the image on the registry, optional
+
+Request Headers:
+
+-   **X-Registry-Auth** – include a base64-encoded AuthConfig object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Query Parameters:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "wma55/u1210sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "jdswinbank/sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "vgauthier/sshd",
+                    "star_count": 0
+                }
+        ...
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"stream": "Step 1..."}
+        {"stream": "..."}
+        {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+
+    The archive must include a file called `Dockerfile`
+    at its root. It may include any number of other files,
+    which will be accessible in the build context (See the [*ADD build
+    command*](../../reference/builder.md#dockerbuilder)).
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – git or HTTP/HTTPS URI build source
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+-   **rm** - remove intermediate containers after a successful build (default behavior)
+-   **forcerm** - always remove intermediate containers (includes rm)
+
+    Request Headers:
+
+-   **Content-type** – should be set to `"application/tar"`.
+-   **X-Registry-Config** – base64-encoded ConfigFile object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers": 11,
+             "Images": 16,
+             "Driver": "btrfs",
+             "ExecutionDriver": "native-0.1",
+             "KernelVersion": "3.12.0-1-amd64"
+             "Debug": false,
+             "NFd": 11,
+             "NGoroutines": 21,
+             "NEventsListener": 0,
+             "InitPath": "/usr/bin/docker",
+             "IndexServerAddress": ["https://index.docker.io/v1/"],
+             "MemoryLimit": true,
+             "SwapLimit": false,
+             "IPv4Forwarding": true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "ApiVersion": "1.12",
+             "Version": "0.2.2",
+             "GitCommit": "5a2a5cc+CHANGES",
+             "GoVersion": "go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+        GET /_ping HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        OK
+
+Status Codes:
+
+-   **200** - no error
+-   **500** - server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname": "",
+             "Domainname": "",
+             "User": "",
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin": false,
+             "AttachStdout": true,
+             "AttachStderr": true,
+             "PortSpecs": null,
+             "Tty": false,
+             "OpenStdin": false,
+             "StdinOnce": false,
+             "Env": null,
+             "Cmd": [
+                     "date"
+             ],
+             "Volumes": {
+                     "/tmp": {}
+             },
+             "WorkingDir": "",
+             "NetworkDisabled": false,
+             "ExposedPorts": {
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {"Id": "596069db4bf5"}
+
+Json Parameters:
+
+-  **config** - the container's configuration
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+-   **until** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images and tags in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository
+specified by `name`.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/ubuntu/get
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into the docker repository.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        POST /images/load
+
+        Tarball in body
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing three files:
+
+1. `VERSION`: currently `1.0` - the file format version
+2. `json`: detailed layer information, similar to `docker inspect layer_id`
+3. `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file will contain `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, there will also be a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it
+    - Then retry to create the container
+
+- Start the container
+
+- If you are not in detached mode:
+    - Attach to the container, using logs=1 (to have stdout and
+      stderr from the container's start) and stream=1
+
+- If in detached mode or only stdin is attached:
+    - Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.15.md b/_vendor/github.com/moby/moby/api/docs/v1.15.md
new file mode 100644
index 000000000000..e5f3ca6348dd
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.15.md
@@ -0,0 +1,1763 @@
+<!--[metadata]>
++++
+title = "Remote API v1.15"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent = "engine_remoteapi"
+weight = 6
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.15
+
+## 1. Brief introduction
+
+ - The Remote API has replaced `rcli`.
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](../../quickstart.md#bind-docker-to-another-host-port-or-a-unix-socket).
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `STDOUT`,
+   `STDIN` and `STDERR`.
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Names":["/boring_feynman"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Names":["/coolName"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Names":["/sleepy_dog"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Names":["/running_cat"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers
+        sizes
+-   **filters** - a json encoded value of the filters (a map[string][]string) to process on the containers list. Available filters:
+  -   exited=&lt;int&gt; -- containers with exit code of &lt;int&gt;
+  -   status=(restarting|running|paused|exited)
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname": "",
+             "Domainname": "",
+             "User": "",
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin": false,
+             "AttachStdout": true,
+             "AttachStderr": true,
+             "Tty": false,
+             "OpenStdin": false,
+             "StdinOnce": false,
+             "Env": [
+                     "FOO=bar",
+                     "BAZ=quux"
+             ],
+             "Cmd": [
+                     "date"
+             ],
+             "Entrypoint": "",
+             "Image": "ubuntu",
+             "Volumes": {
+                     "/tmp": {}
+             },
+             "WorkingDir": "",
+             "NetworkDisabled": false,
+             "MacAddress": "12:34:56:78:9a:bc",
+             "ExposedPorts": {
+                     "22/tcp": {}
+             },
+             "SecurityOpt": [],
+             "HostConfig": {
+               "Binds": ["/tmp:/tmp"],
+               "Links": ["redis3:redis"],
+               "LxcConf": {"lxc.utsname":"docker"},
+               "PortBindings": { "22/tcp": [{ "HostPort": "11022" }] },
+               "PublishAllPorts": false,
+               "Privileged": false,
+               "Dns": ["8.8.8.8"],
+               "DnsSearch": [""],
+               "ExtraHosts": null,
+               "VolumesFrom": ["parent", "other:ro"],
+               "CapAdd": ["NET_ADMIN"],
+               "CapDrop": ["MKNOD"],
+               "RestartPolicy": { "Name": "", "MaximumRetryCount": 0 },
+               "NetworkMode": "bridge",
+               "Devices": []
+            }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id": "f91ddc4b01e079c4481a8340bbbeca4dbd33d6e4a10662e499f8eacbb5bf252b"
+             "Warnings": []
+        }
+
+Json Parameters:
+
+-   **Hostname** - A string value containing the desired hostname to use for the
+      container.
+-   **Domainname** - A string value containing the desired domain name to use
+      for the container.
+-   **User** - A string value containing the user to use inside the container.
+-   **Memory** - Memory limit in bytes.
+-   **MemorySwap** - Total memory limit (memory + swap); set `-1` to enable unlimited swap.
+-   **CpuShares** - An integer value containing the CPU Shares for container
+      (ie. the relative weight vs other containers).
+    **CpuSet** - String value containing the cgroups Cpuset to use.
+-   **AttachStdin** - Boolean value, attaches to stdin.
+-   **AttachStdout** - Boolean value, attaches to stdout.
+-   **AttachStderr** - Boolean value, attaches to stderr.
+-   **Tty** - Boolean value, Attach standard streams to a tty, including stdin if it is not closed.
+-   **OpenStdin** - Boolean value, opens stdin,
+-   **StdinOnce** - Boolean value, close stdin after the 1 attached client disconnects.
+-   **Env** - A list of environment variables in the form of `["VAR=value"[,"VAR2=value2"]]`
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Entrypoint** - Set the entrypoint for the container a string or an array
+      of strings
+-   **Image** - String value containing the image name to use for the container
+-   **Volumes** – An object mapping mountpoint paths (strings) inside the
+        container to empty objects.
+-   **WorkingDir** - A string value containing the working dir for commands to
+      run in.
+-   **NetworkDisabled** - Boolean value, when true disables networking for the
+      container
+-   **ExposedPorts** - An object mapping ports to an empty object in the form of:
+      `"ExposedPorts": { "<port>/<tcp|udp>: {}" }`
+-   **SecurityOpt**: A list of string values to customize labels for MLS
+      systems, such as SELinux.
+-   **HostConfig**
+  -   **Binds** – A list of volume bindings for this container.  Each volume
+          binding is a string of the form `container_path` (to create a new
+          volume for the container), `host_path:container_path` (to bind-mount
+          a host path into the container), or `host_path:container_path:ro`
+          (to make the bind-mount read-only inside the container).
+  -   **Links** - A list of links for the container.  Each link entry should be
+        in the form of "container_name:alias".
+  -   **LxcConf** - LXC specific configurations.  These configurations will only
+        work when using the `lxc` execution driver.
+  -   **PortBindings** - A map of exposed container ports and the host port they
+        should map to. It should be specified in the form
+        `{ <port>/<protocol>: [{ "HostPort": "<port>" }] }`
+        Take note that `port` is specified as a string and not an integer value.
+  -   **PublishAllPorts** - Allocates a random host port for all of a container's
+        exposed ports. Specified as a boolean value.
+  -   **Privileged** - Gives the container full access to the host.  Specified as
+        a boolean value.
+  -   **Dns** - A list of dns servers for the container to use.
+  -   **DnsSearch** - A list of DNS search domains
+  -   **ExtraHosts** - A list of hostnames/IP mappings to be added to the
+      container's `/etc/hosts` file. Specified in the form `["hostname:IP"]`.
+  -   **VolumesFrom** - A list of volumes to inherit from another container.
+        Specified in the form `<container name>[:<ro|rw>]`
+  -   **CapAdd** - A list of kernel capabilities to add to the container.
+  -   **Capdrop** - A list of kernel capabilities to drop from the container.
+  -   **RestartPolicy** – The behavior to apply when the container exits.  The
+          value is an object with a `Name` property of either `"always"` to
+          always restart or `"on-failure"` to restart only when the container
+          exit code is non-zero.  If `on-failure` is used, `MaximumRetryCount`
+          controls the number of times to retry before giving up.
+          The default is not to restart. (optional)
+          An ever increasing delay (double the previous delay, starting at 100mS)
+          is added before each restart to prevent flooding the server.
+  -   **NetworkMode** - Sets the networking mode for the container. Supported
+        values are: `bridge`, `host`, `none`, and `container:<name|id>`
+  -   **Devices** - A list of devices to add to the container specified in the
+        form
+        `{ "PathOnHost": "/dev/deviceName", "PathInContainer": "/dev/deviceName", "CgroupPermissions": "mrw"}`
+
+Query Parameters:
+
+-   **name** – Assign the specified name to the container. Must
+    match `/?[a-zA-Z0-9_-]+`.
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id or name)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {},
+                     "HostConfig": {
+                         "Binds": null,
+                         "ContainerIDFile": "",
+                         "LxcConf": [],
+                         "Privileged": false,
+                         "PortBindings": {
+                            "80/tcp": [
+                                {
+                                    "HostIp": "0.0.0.0",
+                                    "HostPort": "49153"
+                                }
+                            ]
+                         },
+                         "Links": ["/name:alias"],
+                         "PublishAllPorts": false,
+                         "CapAdd": ["NET_ADMIN"],
+                         "CapDrop": ["MKNOD"]
+                     }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id or name)/top`
+
+List processes running inside the container `id`. On Unix systems this
+is done by running the `ps` command. This endpoint is not
+supported on Windows.
+
+**Example request**:
+
+    GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Titles" : [
+         "UID", "PID", "PPID", "C", "STIME", "TTY", "TIME", "CMD"
+       ],
+       "Processes" : [
+         [
+           "root", "13642", "882", "0", "17:03", "pts/0", "00:00:00", "/bin/bash"
+         ],
+         [
+           "root", "13735", "13642", "0", "17:06", "pts/0", "00:00:00", "sleep 10"
+         ]
+       ]
+    }
+
+**Example request**:
+
+    GET /containers/4fa6e0f0c678/top?ps_args=aux HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Titles" : [
+        "USER","PID","%CPU","%MEM","VSZ","RSS","TTY","STAT","START","TIME","COMMAND"
+      ]
+      "Processes" : [
+        [
+          "root","13642","0.0","0.1","18172","3184","pts/0","Ss","17:03","0:00","/bin/bash"
+        ],
+        [
+          "root","13895","0.0","0.0","4348","692","pts/0","S+","17:15","0:00","sleep 10"
+        ]
+      ],
+    }
+
+Query Parameters:
+
+-   **ps_args** – `ps` arguments to use (e.g., `aux`), defaults to `-ef`
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Get container logs
+
+`GET /containers/(id or name)/logs`
+
+Get stdout and stderr logs from the container ``id``
+
+**Example request**:
+
+       GET /containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10 HTTP/1.1
+
+**Example response**:
+
+       HTTP/1.1 200 OK
+       Content-Type: application/vnd.docker.raw-stream
+
+       {{ STREAM }}
+
+Query Parameters:
+
+-   **follow** – 1/True/true or 0/False/false, return stream. Default false
+-   **stdout** – 1/True/true or 0/False/false, show stdout log. Default false
+-   **stderr** – 1/True/true or 0/False/false, show stderr log. Default false
+-   **timestamps** – 1/True/true or 0/False/false, print timestamps for
+        every log line. Default false
+-   **tail** – Output specified number of lines at the end of logs: `all` or `<number>`. Default all
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id or name)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id or name)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Resize a container TTY
+
+`GET /containers/(id or name)/resize?h=<height>&w=<width>`
+
+Resize the TTY of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/resize?h=40&w=80 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Length: 0
+        Content-Type: text/plain; charset=utf-8
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – No such container
+-   **500** – bad file descriptor
+
+### Start a container
+
+`POST /containers/(id or name)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds": ["/tmp:/tmp"],
+             "Links": ["redis3:redis"],
+             "LxcConf": {"lxc.utsname":"docker"},
+             "PortBindings": { "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts": false,
+             "Privileged": false,
+             "Dns": ["8.8.8.8"],
+             "DnsSearch": [""],
+             "VolumesFrom": ["parent", "other:ro"],
+             "CapAdd": ["NET_ADMIN"],
+             "CapDrop": ["MKNOD"],
+             "RestartPolicy": { "Name": "", "MaximumRetryCount": 0 },
+             "NetworkMode": "bridge",
+             "Devices": []
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Json Parameters:
+
+-   **Binds** – A list of volume bindings for this container.  Each volume
+        binding is a string of the form `container_path` (to create a new
+        volume for the container), `host_path:container_path` (to bind-mount
+        a host path into the container), or `host_path:container_path:ro`
+        (to make the bind-mount read-only inside the container).
+-   **Links** - A list of links for the container.  Each link entry should be of
+      of the form "container_name:alias".
+-   **LxcConf** - LXC specific configurations.  These configurations will only
+      work when using the `lxc` execution driver.
+-   **PortBindings** - A map of exposed container ports and the host port they
+      should map to. It should be specified in the form
+      `{ <port>/<protocol>: [{ "HostPort": "<port>" }] }`
+      Take note that `port` is specified as a string and not an integer value.
+-   **PublishAllPorts** - Allocates a random host port for all of a container's
+      exposed ports. Specified as a boolean value.
+-   **Privileged** - Gives the container full access to the host.  Specified as
+      a boolean value.
+-   **Dns** - A list of dns servers for the container to use.
+-   **DnsSearch** - A list of DNS search domains
+-   **VolumesFrom** - A list of volumes to inherit from another container.
+      Specified in the form `<container name>[:<ro|rw>]`
+-   **CapAdd** - A list of kernel capabilities to add to the container.
+-   **Capdrop** - A list of kernel capabilities to drop from the container.
+-   **RestartPolicy** – The behavior to apply when the container exits.  The
+        value is an object with a `Name` property of either `"always"` to
+        always restart or `"on-failure"` to restart only when the container
+        exit code is non-zero.  If `on-failure` is used, `MaximumRetryCount`
+        controls the number of times to retry before giving up.
+        The default is not to restart. (optional)
+        An ever increasing delay (double the previous delay, starting at 100mS)
+        is added before each restart to prevent flooding the server.
+-   **NetworkMode** - Sets the networking mode for the container. Supported
+      values are: `bridge`, `host`, `none`, and `container:<name|id>`
+-   **Devices** - A list of devices to add to the container specified in the
+      form
+      `{ "PathOnHost": "/dev/deviceName", "PathInContainer": "/dev/deviceName", "CgroupPermissions": "mrw"}`
+
+Status Codes:
+
+-   **204** – no error
+-   **304** – container already started
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id or name)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **304** – container already stopped
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id or name)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id or name)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters
+
+-   **signal** - Signal to send to the container: integer or string like "SIGINT".
+        When not set, SIGKILL is assumed and the call will waits for the container to exit.
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Pause a container
+
+`POST /containers/(id or name)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Unpause a container
+
+`POST /containers/(id or name)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id or name)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`](#create-a-container),
+    the stream is the raw data from the process PTY and client's stdin.
+    When the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1
+
+### Attach to a container (websocket)
+
+`GET /containers/(id or name)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id or name)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id or name)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+-   **force** - 1/True/true or 0/False/false, Kill then remove the container.
+        Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id or name)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+             "RepoTags": [
+               "ubuntu:12.04",
+               "ubuntu:precise",
+               "ubuntu:latest"
+             ],
+             "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+             "Created": 1365714795,
+             "Size": 131506275,
+             "VirtualSize": 131506275
+          },
+          {
+             "RepoTags": [
+               "ubuntu:12.10",
+               "ubuntu:quantal"
+             ],
+             "ParentId": "27cf784147099545",
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Created": 1364102658,
+             "Size": 24653,
+             "VirtualSize": 180116135
+          }
+        ]
+
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a json encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   dangling=true
+-   **filter** - only return images with the specified name
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pulling it from the registry or by importing it
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pulling..."}
+        {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+        {"error": "Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import.  The value may be a URL from which the image
+        can be retrieved or `-` to read the image from the request body.
+-   **repo** – repository
+-   **tag** – tag
+
+    Request Headers:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Created": "2013-03-23T22:24:18.818426-07:00",
+             "Container": "3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "ContainerConfig":
+                     {
+                             "Hostname": "",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": false,
+                             "AttachStderr": false,
+                             "PortSpecs": null,
+                             "Tty": true,
+                             "OpenStdin": true,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": null,
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Parent": "27cf784147099545",
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pushing..."}
+        {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+        {"error": "Invalid..."}
+        ...
+
+    If you wish to push an image on to a private registry, that image must already have been tagged
+    into a repository which references that registry host name and port.  This repository name should
+    then be used in the URL. This mirrors the flow of the CLI.
+
+**Example request**:
+
+        POST /images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+Query Parameters:
+
+-   **tag** – the tag to associate with the image on the registry, optional
+
+Request Headers:
+
+-   **X-Registry-Auth** – include a base64-encoded AuthConfig
+        object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Query Parameters:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "wma55/u1210sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "jdswinbank/sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "vgauthier/sshd",
+                    "star_count": 0
+                }
+        ...
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"stream": "Step 1..."}
+        {"stream": "..."}
+        {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+
+    The archive must include a file called `Dockerfile`
+    at its root. It may include any number of other files,
+    which will be accessible in the build context (See the [*ADD build
+    command*](../../reference/builder.md#dockerbuilder)).
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+        the resulting image in case of success
+-   **remote** – git or HTTP/HTTPS URI build source
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+-   **rm** - remove intermediate containers after a successful build (default behavior)
+-   **forcerm** - always remove intermediate containers (includes rm)
+
+    Request Headers:
+
+-   **Content-type** – should be set to `"application/tar"`.
+-   **X-Registry-Config** – base64-encoded ConfigFile object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers": 11,
+             "Images": 16,
+             "Driver": "btrfs",
+             "ExecutionDriver": "native-0.1",
+             "KernelVersion": "3.12.0-1-amd64"
+             "Debug": false,
+             "NFd": 11,
+             "NGoroutines": 21,
+             "NEventsListener": 0,
+             "InitPath": "/usr/bin/docker",
+             "IndexServerAddress": ["https://index.docker.io/v1/"],
+             "MemoryLimit": true,
+             "SwapLimit": false,
+             "IPv4Forwarding": true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "ApiVersion": "1.12",
+             "Version": "0.2.2",
+             "GitCommit": "5a2a5cc+CHANGES",
+             "GoVersion": "go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+        GET /_ping HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        OK
+
+Status Codes:
+
+-   **200** - no error
+-   **500** - server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname": "",
+             "Domainname": "",
+             "User": "",
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin": false,
+             "AttachStdout": true,
+             "AttachStderr": true,
+             "PortSpecs": null,
+             "Tty": false,
+             "OpenStdin": false,
+             "StdinOnce": false,
+             "Env": null,
+             "Cmd": [
+                     "date"
+             ],
+             "Volumes": {
+                     "/tmp": {}
+             },
+             "WorkingDir": "",
+             "NetworkDisabled": false,
+             "ExposedPorts": {
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {"Id": "596069db4bf5"}
+
+Json Parameters:
+
+-  **config** - the container's configuration
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+-   **until** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository specified
+by `name`.
+
+If `name` is a specific name and tag (e.g. ubuntu:latest), then only that image
+(and its parents) are returned. If `name` is an image ID, similarly only that
+image (and its parents) are returned, but with the exclusion of the
+'repositories' file in the tarball, as there were no image names referenced.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/ubuntu/get
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images.
+
+`GET /images/get`
+
+Get a tarball containing all images and metadata for one or more repositories.
+
+For each value of the `names` parameter: if it is a specific name and tag (e.g.
+ubuntu:latest), then only that image (and its parents) are returned; if it is
+an image ID, similarly only that image (and its parents) are returned and there
+would be no names referenced in the 'repositories' file for this image ID.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/get?names=myname%2Fmyapp%3Alatest&names=busybox
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into the docker repository.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        POST /images/load
+
+        Tarball in body
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing three files:
+
+1. `VERSION`: currently `1.0` - the file format version
+2. `json`: detailed layer information, similar to `docker inspect layer_id`
+3. `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file will contain `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, there will also be a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+### Exec Create
+
+`POST /containers/(id or name)/exec`
+
+Sets up an exec instance in a running container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/exec HTTP/1.1
+        Content-Type: application/json
+
+        {
+	     "AttachStdin": false,
+	     "AttachStdout": true,
+	     "AttachStderr": true,
+	     "Tty": false,
+	     "Cmd": [
+                     "date"
+             ],
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id": "f90e34656806"
+        }
+
+Json Parameters:
+
+-   **AttachStdin** - Boolean value, attaches to stdin of the exec command.
+-   **AttachStdout** - Boolean value, attaches to stdout of the exec command.
+-   **AttachStderr** - Boolean value, attaches to stderr of the exec command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY
+-   **Cmd** - Command to run specified as a string or an array of strings.
+
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+
+### Exec Start
+
+`POST /exec/(id)/start`
+
+Starts a previously set up exec instance `id`. If `detach` is true, this API
+returns after starting the `exec` command. Otherwise, this API sets up an
+interactive session with the `exec` command.
+
+**Example request**:
+
+        POST /exec/e90e34656806/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+	     "Detach": false,
+	     "Tty": false,
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Json Parameters:
+
+-   **Detach** - Detach from the exec command
+-   **Tty** - Boolean value to allocate a pseudo-TTY
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such exec instance
+
+    **Stream details**:
+    Similar to the stream behavior of `POST /containers/(id or name)/attach` API
+
+### Exec Resize
+
+`POST /exec/(id)/resize`
+
+Resizes the tty session used by the exec command `id`.
+This API is valid only if `tty` was specified as part of creating and starting the exec command.
+
+**Example request**:
+
+        POST /exec/e90e34656806/resize HTTP/1.1
+        Content-Type: plain/text
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: plain/text
+
+Query Parameters:
+
+-   **h** – height of tty session
+-   **w** – width
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such exec instance
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it
+    - Then retry to create the container
+
+- Start the container
+
+- If you are not in detached mode:
+- Attach to the container, using logs=1 (to have stdout and
+      stderr from the container's start) and stream=1
+
+- If in detached mode or only stdin is attached:
+- Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.16.md b/_vendor/github.com/moby/moby/api/docs/v1.16.md
new file mode 100644
index 000000000000..f6e768ce0c41
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.16.md
@@ -0,0 +1,1833 @@
+<!--[metadata]>
++++
+title = "Remote API v1.16"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent = "engine_remoteapi"
+weight = 5
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.16
+
+## 1. Brief introduction
+
+ - The Remote API has replaced `rcli`.
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](../../quickstart.md#bind-docker-to-another-host-port-or-a-unix-socket).
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `STDOUT`,
+   `STDIN` and `STDERR`.
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Names":["/boring_feynman"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Names":["/coolName"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Names":["/sleep_dog"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Names":["/running_cat"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers
+        sizes
+-   **filters** - a json encoded value of the filters (a map[string][]string) to process on the containers list. Available filters:
+  -   exited=&lt;int&gt; -- containers with exit code of &lt;int&gt;
+  -   status=(restarting|running|paused|exited)
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname": "",
+             "Domainname": "",
+             "User": "",
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin": false,
+             "AttachStdout": true,
+             "AttachStderr": true,
+             "Tty": false,
+             "OpenStdin": false,
+             "StdinOnce": false,
+             "Env": [
+                     "FOO=bar",
+                     "BAZ=quux"
+             ],
+             "Cmd": [
+                     "date"
+             ],
+             "Entrypoint": "",
+             "Image": "ubuntu",
+             "Volumes": {
+                     "/tmp": {}
+             },
+             "WorkingDir": "",
+             "NetworkDisabled": false,
+             "MacAddress": "12:34:56:78:9a:bc",
+             "ExposedPorts": {
+                     "22/tcp": {}
+             },
+             "SecurityOpt": [],
+             "HostConfig": {
+               "Binds": ["/tmp:/tmp"],
+               "Links": ["redis3:redis"],
+               "LxcConf": {"lxc.utsname":"docker"},
+               "PortBindings": { "22/tcp": [{ "HostPort": "11022" }] },
+               "PublishAllPorts": false,
+               "Privileged": false,
+               "Dns": ["8.8.8.8"],
+               "DnsSearch": [""],
+               "ExtraHosts": null,
+               "VolumesFrom": ["parent", "other:ro"],
+               "CapAdd": ["NET_ADMIN"],
+               "CapDrop": ["MKNOD"],
+               "RestartPolicy": { "Name": "", "MaximumRetryCount": 0 },
+               "NetworkMode": "bridge",
+               "Devices": []
+            }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **Hostname** - A string value containing the desired hostname to use for the
+      container.
+-   **Domainname** - A string value containing the desired domain name to use
+      for the container.
+-   **User** - A string value containing the user to use inside the container.
+-   **Memory** - Memory limit in bytes.
+-   **MemorySwap** - Total memory limit (memory + swap); set `-1` to enable unlimited swap.
+-   **CpuShares** - An integer value containing the CPU Shares for container
+      (ie. the relative weight vs other containers).
+    **CpuSet** - String value containing the cgroups Cpuset to use.
+-   **AttachStdin** - Boolean value, attaches to stdin.
+-   **AttachStdout** - Boolean value, attaches to stdout.
+-   **AttachStderr** - Boolean value, attaches to stderr.
+-   **Tty** - Boolean value, Attach standard streams to a tty, including stdin if it is not closed.
+-   **OpenStdin** - Boolean value, opens stdin,
+-   **StdinOnce** - Boolean value, close stdin after the 1 attached client disconnects.
+-   **Env** - A list of environment variables in the form of `["VAR=value"[,"VAR2=value2"]]`
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Entrypoint** - Set the entrypoint for the container a string or an array
+      of strings
+-   **Image** - String value containing the image name to use for the container
+-   **Volumes** – An object mapping mountpoint paths (strings) inside the
+        container to empty objects.
+-   **WorkingDir** - A string value containing the working dir for commands to
+      run in.
+-   **NetworkDisabled** - Boolean value, when true disables networking for the
+      container
+-   **ExposedPorts** - An object mapping ports to an empty object in the form of:
+      `"ExposedPorts": { "<port>/<tcp|udp>: {}" }`
+-   **SecurityOpt**: A list of string values to customize labels for MLS
+      systems, such as SELinux.
+-   **HostConfig**
+  -   **Binds** – A list of volume bindings for this container.  Each volume
+          binding is a string of the form `container_path` (to create a new
+          volume for the container), `host_path:container_path` (to bind-mount
+          a host path into the container), or `host_path:container_path:ro`
+          (to make the bind-mount read-only inside the container).
+  -   **Links** - A list of links for the container.  Each link entry should be
+        in the form of "container_name:alias".
+  -   **LxcConf** - LXC specific configurations.  These configurations will only
+        work when using the `lxc` execution driver.
+  -   **PortBindings** - A map of exposed container ports and the host port they
+        should map to. It should be specified in the form
+        `{ <port>/<protocol>: [{ "HostPort": "<port>" }] }`
+        Take note that `port` is specified as a string and not an integer value.
+  -   **PublishAllPorts** - Allocates a random host port for all of a container's
+        exposed ports. Specified as a boolean value.
+  -   **Privileged** - Gives the container full access to the host.  Specified as
+        a boolean value.
+  -   **Dns** - A list of dns servers for the container to use.
+  -   **DnsSearch** - A list of DNS search domains
+  -   **ExtraHosts** - A list of hostnames/IP mappings to be added to the
+      container's `/etc/hosts` file. Specified in the form `["hostname:IP"]`.
+  -   **VolumesFrom** - A list of volumes to inherit from another container.
+        Specified in the form `<container name>[:<ro|rw>]`
+  -   **CapAdd** - A list of kernel capabilities to add to the container.
+  -   **Capdrop** - A list of kernel capabilities to drop from the container.
+  -   **RestartPolicy** – The behavior to apply when the container exits.  The
+          value is an object with a `Name` property of either `"always"` to
+          always restart or `"on-failure"` to restart only when the container
+          exit code is non-zero.  If `on-failure` is used, `MaximumRetryCount`
+          controls the number of times to retry before giving up.
+          The default is not to restart. (optional)
+          An ever increasing delay (double the previous delay, starting at 100mS)
+          is added before each restart to prevent flooding the server.
+  -   **NetworkMode** - Sets the networking mode for the container. Supported
+        values are: `bridge`, `host`, `none`, and `container:<name|id>`
+  -   **Devices** - A list of devices to add to the container specified in the
+        form
+        `{ "PathOnHost": "/dev/deviceName", "PathInContainer": "/dev/deviceName", "CgroupPermissions": "mrw"}`
+
+Query Parameters:
+
+-   **name** – Assign the specified name to the container. Must
+    match `/?[a-zA-Z0-9_-]+`.
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id or name)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {},
+                     "HostConfig": {
+                         "Binds": null,
+                         "ContainerIDFile": "",
+                         "LxcConf": [],
+                         "Privileged": false,
+                         "PortBindings": {
+                            "80/tcp": [
+                                {
+                                    "HostIp": "0.0.0.0",
+                                    "HostPort": "49153"
+                                }
+                            ]
+                         },
+                         "Links": ["/name:alias"],
+                         "PublishAllPorts": false,
+                         "CapAdd": ["NET_ADMIN"],
+                         "CapDrop": ["MKNOD"]
+                     }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id or name)/top`
+
+List processes running inside the container `id`. On Unix systems this
+is done by running the `ps` command. This endpoint is not
+supported on Windows.
+
+**Example request**:
+
+    GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Titles" : [
+         "UID", "PID", "PPID", "C", "STIME", "TTY", "TIME", "CMD"
+       ],
+       "Processes" : [
+         [
+           "root", "13642", "882", "0", "17:03", "pts/0", "00:00:00", "/bin/bash"
+         ],
+         [
+           "root", "13735", "13642", "0", "17:06", "pts/0", "00:00:00", "sleep 10"
+         ]
+       ]
+    }
+
+**Example request**:
+
+    GET /containers/4fa6e0f0c678/top?ps_args=aux HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Titles" : [
+        "USER","PID","%CPU","%MEM","VSZ","RSS","TTY","STAT","START","TIME","COMMAND"
+      ]
+      "Processes" : [
+        [
+          "root","13642","0.0","0.1","18172","3184","pts/0","Ss","17:03","0:00","/bin/bash"
+        ],
+        [
+          "root","13895","0.0","0.0","4348","692","pts/0","S+","17:15","0:00","sleep 10"
+        ]
+      ],
+    }
+
+Query Parameters:
+
+-   **ps_args** – `ps` arguments to use (e.g., `aux`), defaults to `-ef`
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Get container logs
+
+`GET /containers/(id or name)/logs`
+
+Get stdout and stderr logs from the container ``id``
+
+**Example request**:
+
+       GET /containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10 HTTP/1.1
+
+**Example response**:
+
+       HTTP/1.1 200 OK
+       Content-Type: application/vnd.docker.raw-stream
+
+       {{ STREAM }}
+
+Query Parameters:
+
+-   **follow** – 1/True/true or 0/False/false, return stream. Default false
+-   **stdout** – 1/True/true or 0/False/false, show stdout log. Default false
+-   **stderr** – 1/True/true or 0/False/false, show stderr log. Default false
+-   **timestamps** – 1/True/true or 0/False/false, print timestamps for
+        every log line. Default false
+-   **tail** – Output specified number of lines at the end of logs: `all` or `<number>`. Default all
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id or name)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id or name)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Resize a container TTY
+
+`POST /containers/(id or name)/resize?h=<height>&w=<width>`
+
+Resize the TTY for container with  `id`. The container must be restarted for the resize to take effect.
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/resize?h=40&w=80 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Length: 0
+        Content-Type: text/plain; charset=utf-8
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – No such container
+-   **500** – Cannot resize container
+
+### Start a container
+
+`POST /containers/(id or name)/start`
+
+Start the container `id`
+
+> **Note**:
+> For backwards compatibility, this endpoint accepts a `HostConfig` as JSON-encoded request body.
+> See [create a container](#create-a-container) for details.
+
+**Example request**:
+
+        POST /containers/e90e34656806/start HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **304** – container already started
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id or name)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **304** – container already stopped
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id or name)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id or name)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters
+
+-   **signal** - Signal to send to the container: integer or string like "SIGINT".
+        When not set, SIGKILL is assumed and the call will waits for the container to exit.
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Pause a container
+
+`POST /containers/(id or name)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Unpause a container
+
+`POST /containers/(id or name)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id or name)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`
+    ](#create-a-container),
+    the stream is the raw data from the process PTY and client's stdin.
+    When the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1
+
+### Attach to a container (websocket)
+
+`GET /containers/(id or name)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id or name)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id or name)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+-   **force** - 1/True/true or 0/False/false, Kill then remove the container.
+        Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id or name)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+             "RepoTags": [
+               "ubuntu:12.04",
+               "ubuntu:precise",
+               "ubuntu:latest"
+             ],
+             "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+             "Created": 1365714795,
+             "Size": 131506275,
+             "VirtualSize": 131506275
+          },
+          {
+             "RepoTags": [
+               "ubuntu:12.10",
+               "ubuntu:quantal"
+             ],
+             "ParentId": "27cf784147099545",
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Created": 1364102658,
+             "Size": 24653,
+             "VirtualSize": 180116135
+          }
+        ]
+
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a json encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   dangling=true
+-   **filter** - only return images with the specified name
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pulling it from the registry or by importing it
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pulling..."}
+        {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+        {"error": "Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import.  The value may be a URL from which the image
+        can be retrieved or `-` to read the image from the request body.
+-   **repo** – repository
+-   **tag** – tag
+
+    Request Headers:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Created": "2013-03-23T22:24:18.818426-07:00",
+             "Container": "3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "ContainerConfig":
+                     {
+                             "Hostname": "",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": false,
+                             "AttachStderr": false,
+                             "PortSpecs": null,
+                             "Tty": true,
+                             "OpenStdin": true,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": null,
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Parent": "27cf784147099545",
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pushing..."}
+        {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+        {"error": "Invalid..."}
+        ...
+
+    If you wish to push an image on to a private registry, that image must already have been tagged
+    into a repository which references that registry host name and port.  This repository name should
+    then be used in the URL. This mirrors the flow of the CLI.
+
+**Example request**:
+
+        POST /images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+Query Parameters:
+
+-   **tag** – the tag to associate with the image on the registry, optional
+
+Request Headers:
+
+-   **X-Registry-Auth** – include a base64-encoded AuthConfig
+        object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Query Parameters:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "wma55/u1210sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "jdswinbank/sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "vgauthier/sshd",
+                    "star_count": 0
+                }
+        ...
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"stream": "Step 1..."}
+        {"stream": "..."}
+        {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+
+    The archive must include a file called `Dockerfile`
+    at its root. It may include any number of other files,
+    which will be accessible in the build context (See the [*ADD build
+    command*](../../reference/builder.md#dockerbuilder)).
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+        the resulting image in case of success
+-   **remote** – git or HTTP/HTTPS URI build source
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+-   **pull** - attempt to pull the image even if an older image exists locally
+-   **rm** - remove intermediate containers after a successful build (default behavior)
+-   **forcerm** - always remove intermediate containers (includes rm)
+
+    Request Headers:
+
+-   **Content-type** – should be set to `"application/tar"`.
+-   **X-Registry-Config** – base64-encoded ConfigFile object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Driver":"btrfs",
+             "DriverStatus": [[""]],
+             "ExecutionDriver":"native-0.1",
+             "KernelVersion":"3.12.0-1-amd64"
+             "NCPU":1,
+             "MemTotal":2099236864,
+             "Name":"prod-server-42",
+             "ID":"7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS",
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "NEventsListener":0,
+             "InitPath":"/usr/bin/docker",
+             "InitSha1":"",
+             "IndexServerAddress":["https://index.docker.io/v1/"],
+             "MemoryLimit":true,
+             "SwapLimit":false,
+             "IPv4Forwarding":true,
+             "Labels":["storage=ssd"],
+             "DockerRootDir": "/var/lib/docker",
+             "OperatingSystem": "Boot2Docker",
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "ApiVersion": "1.12",
+             "Version": "0.2.2",
+             "GitCommit": "5a2a5cc+CHANGES",
+             "GoVersion": "go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+        GET /_ping HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        OK
+
+Status Codes:
+
+-   **200** - no error
+-   **500** - server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname": "",
+             "Domainname": "",
+             "User": "",
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin": false,
+             "AttachStdout": true,
+             "AttachStderr": true,
+             "PortSpecs": null,
+             "Tty": false,
+             "OpenStdin": false,
+             "StdinOnce": false,
+             "Env": null,
+             "Cmd": [
+                     "date"
+             ],
+             "Volumes": {
+                     "/tmp": {}
+             },
+             "WorkingDir": "",
+             "NetworkDisabled": false,
+             "ExposedPorts": {
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {"Id": "596069db4bf5"}
+
+Json Parameters:
+
+-  **config** - the container's configuration
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+-   **until** – timestamp used for polling
+-   **filters** – a json encoded value of the filters (a map[string][]string) to process on the event list. Available filters:
+  -   event=&lt;string&gt; -- event to filter
+  -   image=&lt;string&gt; -- image to filter
+  -   container=&lt;string&gt; -- container to filter
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository specified
+by `name`.
+
+If `name` is a specific name and tag (e.g. ubuntu:latest), then only that image
+(and its parents) are returned. If `name` is an image ID, similarly only that
+image (and its parents) are returned, but with the exclusion of the
+'repositories' file in the tarball, as there were no image names referenced.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/ubuntu/get
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images.
+
+`GET /images/get`
+
+Get a tarball containing all images and metadata for one or more repositories.
+
+For each value of the `names` parameter: if it is a specific name and tag (e.g.
+ubuntu:latest), then only that image (and its parents) are returned; if it is
+an image ID, similarly only that image (and its parents) are returned and there
+would be no names referenced in the 'repositories' file for this image ID.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/get?names=myname%2Fmyapp%3Alatest&names=busybox
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into the docker repository.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        POST /images/load
+
+        Tarball in body
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing three files:
+
+1. `VERSION`: currently `1.0` - the file format version
+2. `json`: detailed layer information, similar to `docker inspect layer_id`
+3. `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file will contain `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, there will also be a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+### Exec Create
+
+`POST /containers/(id or name)/exec`
+
+Sets up an exec instance in a running container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/exec HTTP/1.1
+        Content-Type: application/json
+
+        {
+	     "AttachStdin": false,
+	     "AttachStdout": true,
+	     "AttachStderr": true,
+	     "Tty": false,
+	     "Cmd": [
+                     "date"
+             ],
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id": "f90e34656806"
+        }
+
+Json Parameters:
+
+-   **AttachStdin** - Boolean value, attaches to stdin of the exec command.
+-   **AttachStdout** - Boolean value, attaches to stdout of the exec command.
+-   **AttachStderr** - Boolean value, attaches to stderr of the exec command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY
+-   **Cmd** - Command to run specified as a string or an array of strings.
+
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+
+### Exec Start
+
+`POST /exec/(id)/start`
+
+Starts a previously set up exec instance `id`. If `detach` is true, this API
+returns after starting the `exec` command. Otherwise, this API sets up an
+interactive session with the `exec` command.
+
+**Example request**:
+
+        POST /exec/e90e34656806/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+	     "Detach": false,
+	     "Tty": false,
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Json Parameters:
+
+-   **Detach** - Detach from the exec command
+-   **Tty** - Boolean value to allocate a pseudo-TTY
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such exec instance
+
+    **Stream details**:
+    Similar to the stream behavior of `POST /containers/(id or name)/attach` API
+
+### Exec Resize
+
+`POST /exec/(id)/resize`
+
+Resizes the tty session used by the exec command `id`.
+This API is valid only if `tty` was specified as part of creating and starting the exec command.
+
+**Example request**:
+
+        POST /exec/e90e34656806/resize HTTP/1.1
+        Content-Type: plain/text
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: plain/text
+
+Query Parameters:
+
+-   **h** – height of tty session
+-   **w** – width
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such exec instance
+
+### Exec Inspect
+
+`GET /exec/(id)/json`
+
+Return low-level information about the exec command `id`.
+
+**Example request**:
+
+        GET /exec/11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: plain/text
+
+        {
+          "ID" : "11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39",
+          "Running" : false,
+          "ExitCode" : 2,
+          "ProcessConfig" : {
+            "privileged" : false,
+            "user" : "",
+            "tty" : false,
+            "entrypoint" : "sh",
+            "arguments" : [
+              "-c",
+              "exit 2"
+            ]
+          },
+          "OpenStdin" : false,
+          "OpenStderr" : false,
+          "OpenStdout" : false,
+          "Container" : {
+            "State" : {
+              "Running" : true,
+              "Paused" : false,
+              "Restarting" : false,
+              "OOMKilled" : false,
+              "Pid" : 3650,
+              "ExitCode" : 0,
+              "Error" : "",
+              "StartedAt" : "2014-11-17T22:26:03.717657531Z",
+              "FinishedAt" : "0001-01-01T00:00:00Z"
+            },
+            "ID" : "8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c",
+            "Created" : "2014-11-17T22:26:03.626304998Z",
+            "Path" : "date",
+            "Args" : [],
+            "Config" : {
+              "Hostname" : "8f177a186b97",
+              "Domainname" : "",
+              "User" : "",
+              "Memory" : 0,
+              "MemorySwap" : 0,
+              "CpuShares" : 0,
+              "Cpuset" : "",
+              "AttachStdin" : false,
+              "AttachStdout" : false,
+              "AttachStderr" : false,
+              "PortSpecs" : null,
+              "ExposedPorts" : null,
+              "Tty" : false,
+              "OpenStdin" : false,
+              "StdinOnce" : false,
+              "Env" : [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ],
+              "Cmd" : [
+                "date"
+              ],
+              "Image" : "ubuntu",
+              "Volumes" : null,
+              "WorkingDir" : "",
+              "Entrypoint" : null,
+              "NetworkDisabled" : false,
+              "MacAddress" : "",
+              "OnBuild" : null,
+              "SecurityOpt" : null
+            },
+            "Image" : "5506de2b643be1e6febbf3b8a240760c6843244c41e12aa2f60ccbb7153d17f5",
+            "NetworkSettings" : {
+              "IPAddress" : "172.17.0.2",
+              "IPPrefixLen" : 16,
+              "MacAddress" : "02:42:ac:11:00:02",
+              "Gateway" : "172.17.42.1",
+              "Bridge" : "docker0",
+              "PortMapping" : null,
+              "Ports" : {}
+            },
+            "ResolvConfPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/resolv.conf",
+            "HostnamePath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hostname",
+            "HostsPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hosts",
+            "Name" : "/test",
+            "Driver" : "aufs",
+            "ExecDriver" : "native-0.2",
+            "MountLabel" : "",
+            "ProcessLabel" : "",
+            "AppArmorProfile" : "",
+            "RestartCount" : 0,
+            "Volumes" : {},
+            "VolumesRW" : {}
+          }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such exec instance
+-   **500** - server error
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it
+    - Then retry to create the container
+
+- Start the container
+
+- If you are not in detached mode:
+- Attach to the container, using logs=1 (to have stdout and
+      stderr from the container's start) and stream=1
+
+- If in detached mode or only stdin is attached:
+- Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.17.md b/_vendor/github.com/moby/moby/api/docs/v1.17.md
new file mode 100644
index 000000000000..147b05f89f64
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.17.md
@@ -0,0 +1,2007 @@
+<!--[metadata]>
++++
+title = "Remote API v1.17"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent = "engine_remoteapi"
+weight = 4
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.17
+
+## 1. Brief introduction
+
+ - The Remote API has replaced `rcli`.
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](../../quickstart.md#bind-docker-to-another-host-port-or-a-unix-socket).
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `STDOUT`,
+   `STDIN` and `STDERR`.
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Names":["/boring_feynman"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Names":["/coolName"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Names":["/sleepy_dog"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Names":["/running_cat"],
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers
+        sizes
+-   **filters** - a json encoded value of the filters (a map[string][]string) to process on the containers list. Available filters:
+  -   exited=&lt;int&gt; -- containers with exit code of &lt;int&gt;
+  -   status=(restarting|running|paused|exited)
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname": "",
+             "Domainname": "",
+             "User": "",
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin": false,
+             "AttachStdout": true,
+             "AttachStderr": true,
+             "Tty": false,
+             "OpenStdin": false,
+             "StdinOnce": false,
+             "Env": [
+                     "FOO=bar",
+                     "BAZ=quux"
+             ],
+             "Cmd": [
+                     "date"
+             ],
+             "Entrypoint": "",
+             "Image": "ubuntu",
+             "Volumes": {
+                     "/tmp": {}
+             },
+             "WorkingDir": "",
+             "NetworkDisabled": false,
+             "MacAddress": "12:34:56:78:9a:bc",
+             "ExposedPorts": {
+                     "22/tcp": {}
+             },
+             "HostConfig": {
+               "Binds": ["/tmp:/tmp"],
+               "Links": ["redis3:redis"],
+               "LxcConf": {"lxc.utsname":"docker"},
+               "PortBindings": { "22/tcp": [{ "HostPort": "11022" }] },
+               "PublishAllPorts": false,
+               "Privileged": false,
+               "ReadonlyRootfs": false,
+               "Dns": ["8.8.8.8"],
+               "DnsSearch": [""],
+               "ExtraHosts": null,
+               "VolumesFrom": ["parent", "other:ro"],
+               "CapAdd": ["NET_ADMIN"],
+               "CapDrop": ["MKNOD"],
+               "RestartPolicy": { "Name": "", "MaximumRetryCount": 0 },
+               "NetworkMode": "bridge",
+               "Devices": [],
+               "SecurityOpt": []
+            }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806",
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **Hostname** - A string value containing the desired hostname to use for the
+      container.
+-   **Domainname** - A string value containing the desired domain name to use
+      for the container.
+-   **User** - A string value containing the user to use inside the container.
+-   **Memory** - Memory limit in bytes.
+-   **MemorySwap** - Total memory limit (memory + swap); set `-1` to enable unlimited swap.
+      You must use this with `memory` and make the swap value larger than `memory`.
+-   **CpuShares** - An integer value containing the CPU Shares for container
+      (ie. the relative weight vs other containers).
+    **CpuSet** - String value containing the cgroups Cpuset to use.
+-   **AttachStdin** - Boolean value, attaches to stdin.
+-   **AttachStdout** - Boolean value, attaches to stdout.
+-   **AttachStderr** - Boolean value, attaches to stderr.
+-   **Tty** - Boolean value, Attach standard streams to a tty, including stdin if it is not closed.
+-   **OpenStdin** - Boolean value, opens stdin,
+-   **StdinOnce** - Boolean value, close stdin after the 1 attached client disconnects.
+-   **Env** - A list of environment variables in the form of `["VAR=value"[,"VAR2=value2"]]`
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Entrypoint** - Set the entrypoint for the container a string or an array
+      of strings
+-   **Image** - String value containing the image name to use for the container
+-   **Volumes** – An object mapping mountpoint paths (strings) inside the
+        container to empty objects.
+-   **WorkingDir** - A string value containing the working dir for commands to
+      run in.
+-   **NetworkDisabled** - Boolean value, when true disables networking for the
+      container
+-   **ExposedPorts** - An object mapping ports to an empty object in the form of:
+      `"ExposedPorts": { "<port>/<tcp|udp>: {}" }`
+-   **HostConfig**
+  -   **Binds** – A list of volume bindings for this container.  Each volume
+          binding is a string of the form `container_path` (to create a new
+          volume for the container), `host_path:container_path` (to bind-mount
+          a host path into the container), or `host_path:container_path:ro`
+          (to make the bind-mount read-only inside the container).
+  -   **Links** - A list of links for the container.  Each link entry should be
+        in the form of "container_name:alias".
+  -   **LxcConf** - LXC specific configurations.  These configurations will only
+        work when using the `lxc` execution driver.
+  -   **PortBindings** - A map of exposed container ports and the host port they
+        should map to. It should be specified in the form
+        `{ <port>/<protocol>: [{ "HostPort": "<port>" }] }`
+        Take note that `port` is specified as a string and not an integer value.
+  -   **PublishAllPorts** - Allocates a random host port for all of a container's
+        exposed ports. Specified as a boolean value.
+  -   **Privileged** - Gives the container full access to the host.  Specified as
+        a boolean value.
+  -   **ReadonlyRootfs** - Mount the container's root filesystem as read only.
+        Specified as a boolean value.
+  -   **Dns** - A list of dns servers for the container to use.
+  -   **DnsSearch** - A list of DNS search domains
+  -   **ExtraHosts** - A list of hostnames/IP mappings to be added to the
+      container's `/etc/hosts` file. Specified in the form `["hostname:IP"]`.
+  -   **VolumesFrom** - A list of volumes to inherit from another container.
+        Specified in the form `<container name>[:<ro|rw>]`
+  -   **CapAdd** - A list of kernel capabilities to add to the container.
+  -   **Capdrop** - A list of kernel capabilities to drop from the container.
+  -   **RestartPolicy** – The behavior to apply when the container exits.  The
+          value is an object with a `Name` property of either `"always"` to
+          always restart or `"on-failure"` to restart only when the container
+          exit code is non-zero.  If `on-failure` is used, `MaximumRetryCount`
+          controls the number of times to retry before giving up.
+          The default is not to restart. (optional)
+          An ever increasing delay (double the previous delay, starting at 100mS)
+          is added before each restart to prevent flooding the server.
+  -   **NetworkMode** - Sets the networking mode for the container. Supported
+        values are: `bridge`, `host`, `none`, and `container:<name|id>`
+  -   **Devices** - A list of devices to add to the container specified in the
+        form
+        `{ "PathOnHost": "/dev/deviceName", "PathInContainer": "/dev/deviceName", "CgroupPermissions": "mrw"}`
+  -   **SecurityOpt**: A list of string values to customize labels for MLS
+        systems, such as SELinux.
+
+Query Parameters:
+
+-   **name** – Assign the specified name to the container. Must
+    match `/?[a-zA-Z0-9_-]+`.
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id or name)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+	{
+		"AppArmorProfile": "",
+		"Args": [
+			"-c",
+			"exit 9"
+		],
+		"Config": {
+			"AttachStderr": true,
+			"AttachStdin": false,
+			"AttachStdout": true,
+			"Cmd": [
+				"/bin/sh",
+				"-c",
+				"exit 9"
+			],
+			"CpuShares": 0,
+			"Cpuset": "",
+			"Domainname": "",
+			"Entrypoint": null,
+			"Env": [
+				"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+			],
+			"ExposedPorts": null,
+			"Hostname": "ba033ac44011",
+			"Image": "ubuntu",
+			"MacAddress": "",
+			"Memory": 0,
+			"MemorySwap": 0,
+			"NetworkDisabled": false,
+			"OnBuild": null,
+			"OpenStdin": false,
+			"PortSpecs": null,
+			"StdinOnce": false,
+			"Tty": false,
+			"User": "",
+			"Volumes": null,
+			"WorkingDir": ""
+		},
+		"Created": "2015-01-06T15:47:31.485331387Z",
+		"Driver": "devicemapper",
+		"ExecDriver": "native-0.2",
+		"ExecIDs": null,
+		"HostConfig": {
+			"Binds": null,
+			"CapAdd": null,
+			"CapDrop": null,
+			"ContainerIDFile": "",
+			"Devices": [],
+			"Dns": null,
+			"DnsSearch": null,
+			"ExtraHosts": null,
+			"IpcMode": "",
+			"Links": null,
+			"LxcConf": [],
+			"NetworkMode": "bridge",
+			"PortBindings": {},
+			"Privileged": false,
+			"ReadonlyRootfs": false,
+			"PublishAllPorts": false,
+			"RestartPolicy": {
+				"MaximumRetryCount": 2,
+				"Name": "on-failure"
+			},
+			"SecurityOpt": null,
+			"VolumesFrom": null
+		},
+		"HostnamePath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hostname",
+		"HostsPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hosts",
+		"Id": "ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39",
+		"Image": "04c5d3b7b0656168630d3ba35d8889bd0e9caafcaeb3004d2bfbc47e7c5d35d2",
+		"MountLabel": "",
+		"Name": "/boring_euclid",
+		"NetworkSettings": {
+			"Bridge": "",
+			"Gateway": "",
+			"IPAddress": "",
+			"IPPrefixLen": 0,
+			"MacAddress": "",
+			"PortMapping": null,
+			"Ports": null
+		},
+		"Path": "/bin/sh",
+		"ProcessLabel": "",
+		"ResolvConfPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/resolv.conf",
+		"RestartCount": 1,
+		"State": {
+			"Error": "",
+			"ExitCode": 9,
+			"FinishedAt": "2015-01-06T15:47:32.080254511Z",
+			"OOMKilled": false,
+			"Paused": false,
+			"Pid": 0,
+			"Restarting": false,
+			"Running": false,
+			"StartedAt": "2015-01-06T15:47:32.072697474Z"
+		},
+		"Volumes": {},
+		"VolumesRW": {}
+	}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id or name)/top`
+
+List processes running inside the container `id`. On Unix systems this
+is done by running the `ps` command. This endpoint is not
+supported on Windows.
+
+**Example request**:
+
+    GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Titles" : [
+         "UID", "PID", "PPID", "C", "STIME", "TTY", "TIME", "CMD"
+       ],
+       "Processes" : [
+         [
+           "root", "13642", "882", "0", "17:03", "pts/0", "00:00:00", "/bin/bash"
+         ],
+         [
+           "root", "13735", "13642", "0", "17:06", "pts/0", "00:00:00", "sleep 10"
+         ]
+       ]
+    }
+
+**Example request**:
+
+    GET /containers/4fa6e0f0c678/top?ps_args=aux HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Titles" : [
+        "USER","PID","%CPU","%MEM","VSZ","RSS","TTY","STAT","START","TIME","COMMAND"
+      ]
+      "Processes" : [
+        [
+          "root","13642","0.0","0.1","18172","3184","pts/0","Ss","17:03","0:00","/bin/bash"
+        ],
+        [
+          "root","13895","0.0","0.0","4348","692","pts/0","S+","17:15","0:00","sleep 10"
+        ]
+      ],
+    }
+
+Query Parameters:
+
+-   **ps_args** – `ps` arguments to use (e.g., `aux`), defaults to `-ef`
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Get container logs
+
+`GET /containers/(id or name)/logs`
+
+Get stdout and stderr logs from the container ``id``
+
+**Example request**:
+
+       GET /containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10 HTTP/1.1
+
+**Example response**:
+
+       HTTP/1.1 101 UPGRADED
+       Content-Type: application/vnd.docker.raw-stream
+       Connection: Upgrade
+       Upgrade: tcp
+
+       {{ STREAM }}
+
+Query Parameters:
+
+-   **follow** – 1/True/true or 0/False/false, return stream. Default false
+-   **stdout** – 1/True/true or 0/False/false, show stdout log. Default false
+-   **stderr** – 1/True/true or 0/False/false, show stderr log. Default false
+-   **timestamps** – 1/True/true or 0/False/false, print timestamps for
+        every log line. Default false
+-   **tail** – Output specified number of lines at the end of logs: `all` or `<number>`. Default all
+
+Status Codes:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id or name)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id or name)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Get container stats based on resource usage
+
+`GET /containers/(id or name)/stats`
+
+This endpoint returns a live stream of a container's resource usage statistics.
+
+**Example request**:
+
+        GET /containers/redis1/stats HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+           "read" : "2015-01-08T22:57:31.547920715Z",
+           "network" : {
+              "rx_dropped" : 0,
+              "rx_bytes" : 648,
+              "rx_errors" : 0,
+              "tx_packets" : 8,
+              "tx_dropped" : 0,
+              "rx_packets" : 8,
+              "tx_errors" : 0,
+              "tx_bytes" : 648
+           },
+           "memory_stats" : {
+              "stats" : {
+                 "total_pgmajfault" : 0,
+                 "cache" : 0,
+                 "mapped_file" : 0,
+                 "total_inactive_file" : 0,
+                 "pgpgout" : 414,
+                 "rss" : 6537216,
+                 "total_mapped_file" : 0,
+                 "writeback" : 0,
+                 "unevictable" : 0,
+                 "pgpgin" : 477,
+                 "total_unevictable" : 0,
+                 "pgmajfault" : 0,
+                 "total_rss" : 6537216,
+                 "total_rss_huge" : 6291456,
+                 "total_writeback" : 0,
+                 "total_inactive_anon" : 0,
+                 "rss_huge" : 6291456,
+                 "hierarchical_memory_limit" : 67108864,
+                 "total_pgfault" : 964,
+                 "total_active_file" : 0,
+                 "active_anon" : 6537216,
+                 "total_active_anon" : 6537216,
+                 "total_pgpgout" : 414,
+                 "total_cache" : 0,
+                 "inactive_anon" : 0,
+                 "active_file" : 0,
+                 "pgfault" : 964,
+                 "inactive_file" : 0,
+                 "total_pgpgin" : 477
+              },
+              "max_usage" : 6651904,
+              "usage" : 6537216,
+              "failcnt" : 0,
+              "limit" : 67108864
+           },
+           "blkio_stats" : {},
+           "cpu_stats" : {
+              "cpu_usage" : {
+                 "percpu_usage" : [
+                    16970827,
+                    1839451,
+                    7107380,
+                    10571290
+                 ],
+                 "usage_in_usermode" : 10000000,
+                 "total_usage" : 36488948,
+                 "usage_in_kernelmode" : 20000000
+              },
+              "system_cpu_usage" : 20091722000000000,
+              "throttling_data" : {}
+           }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Resize a container TTY
+
+`POST /containers/(id or name)/resize?h=<height>&w=<width>`
+
+Resize the TTY for container with  `id`. The container must be restarted for the resize to take effect.
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/resize?h=40&w=80 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Length: 0
+        Content-Type: text/plain; charset=utf-8
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – No such container
+-   **500** – Cannot resize container
+
+### Start a container
+
+`POST /containers/(id or name)/start`
+
+Start the container `id`
+
+> **Note**:
+> For backwards compatibility, this endpoint accepts a `HostConfig` as JSON-encoded request body.
+> See [create a container](#create-a-container) for details.
+
+**Example request**:
+
+        POST /containers/e90e34656806/start HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **304** – container already started
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id or name)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **304** – container already stopped
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id or name)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id or name)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters
+
+-   **signal** - Signal to send to the container: integer or string like "SIGINT".
+        When not set, SIGKILL is assumed and the call will waits for the container to exit.
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Rename a container
+
+`POST /containers/(id or name)/rename`
+
+Rename the container `id` to a `new_name`
+
+**Example request**:
+
+        POST /containers/e90e34656806/rename?name=new_name HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **name** – new name for the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **409** - conflict name already assigned
+-   **500** – server error
+
+### Pause a container
+
+`POST /containers/(id or name)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Unpause a container
+
+`POST /containers/(id or name)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id or name)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 101 UPGRADED
+        Content-Type: application/vnd.docker.raw-stream
+        Connection: Upgrade
+        Upgrade: tcp
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`
+    ](#create-a-container),
+    the stream is the raw data from the process PTY and client's stdin.
+    When the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1
+
+### Attach to a container (websocket)
+
+`GET /containers/(id or name)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id or name)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id or name)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+-   **force** - 1/True/true or 0/False/false, Kill then remove the container.
+        Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id or name)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+             "RepoTags": [
+               "ubuntu:12.04",
+               "ubuntu:precise",
+               "ubuntu:latest"
+             ],
+             "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+             "Created": 1365714795,
+             "Size": 131506275,
+             "VirtualSize": 131506275
+          },
+          {
+             "RepoTags": [
+               "ubuntu:12.10",
+               "ubuntu:quantal"
+             ],
+             "ParentId": "27cf784147099545",
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Created": 1364102658,
+             "Size": 24653,
+             "VirtualSize": 180116135
+          }
+        ]
+
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a json encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   dangling=true
+-   **filter** - only return images with the specified name
+
+### Build image from a Dockerfile
+
+`POST /build`
+
+Build an image from a Dockerfile
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"stream": "Step 1..."}
+        {"stream": "..."}
+        {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+The input stream must be a tar archive compressed with one of the
+following algorithms: identity (no compression), gzip, bzip2, xz.
+
+The archive must include a build instructions file, typically called
+`Dockerfile` at the root of the archive. The `dockerfile` parameter may be
+used to specify a different build instructions file by having its value be
+the path to the alternate build instructions file to use.
+
+The archive may include any number of other files,
+which will be accessible in the build context (See the [*ADD build
+command*](../../reference/builder.md#dockerbuilder)).
+
+Query Parameters:
+
+-   **dockerfile** - path within the build context to the Dockerfile
+-   **t** – repository name (and optionally a tag) to be applied to
+        the resulting image in case of success
+-   **remote** – git or HTTP/HTTPS URI build source
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+-   **pull** - attempt to pull the image even if an older image exists locally
+-   **rm** - remove intermediate containers after a successful build (default behavior)
+-   **forcerm** - always remove intermediate containers (includes rm)
+
+    Request Headers:
+
+-   **Content-type** – should be set to `"application/tar"`.
+-   **X-Registry-Config** – base64-encoded ConfigFile object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pulling it from the registry or by importing it
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pulling..."}
+        {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+        {"error": "Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import.  The value may be a URL from which the image
+        can be retrieved or `-` to read the image from the request body.
+-   **repo** – repository
+-   **tag** – tag
+
+    Request Headers:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Created": "2013-03-23T22:24:18.818426-07:00",
+             "Container": "3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "ContainerConfig":
+                     {
+                             "Hostname": "",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": false,
+                             "AttachStderr": false,
+                             "PortSpecs": null,
+                             "Tty": true,
+                             "OpenStdin": true,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": null,
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Parent": "27cf784147099545",
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pushing..."}
+        {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+        {"error": "Invalid..."}
+        ...
+
+    If you wish to push an image on to a private registry, that image must already have been tagged
+    into a repository which references that registry host name and port.  This repository name should
+    then be used in the URL. This mirrors the flow of the CLI.
+
+**Example request**:
+
+        POST /images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+Query Parameters:
+
+-   **tag** – the tag to associate with the image on the registry, optional
+
+Request Headers:
+
+-   **X-Registry-Auth** – include a base64-encoded AuthConfig
+        object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Query Parameters:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "wma55/u1210sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "jdswinbank/sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_automated": false,
+                    "name": "vgauthier/sshd",
+                    "star_count": 0
+                }
+        ...
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+## 2.3 Misc
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Driver":"btrfs",
+             "DriverStatus": [[""]],
+             "ExecutionDriver":"native-0.1",
+             "KernelVersion":"3.12.0-1-amd64"
+             "NCPU":1,
+             "MemTotal":2099236864,
+             "Name":"prod-server-42",
+             "ID":"7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS",
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "NEventsListener":0,
+             "InitPath":"/usr/bin/docker",
+             "InitSha1":"",
+             "IndexServerAddress":["https://index.docker.io/v1/"],
+             "MemoryLimit":true,
+             "SwapLimit":false,
+             "IPv4Forwarding":true,
+             "Labels":["storage=ssd"],
+             "DockerRootDir": "/var/lib/docker",
+             "OperatingSystem": "Boot2Docker",
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "ApiVersion": "1.12",
+             "Version": "0.2.2",
+             "GitCommit": "5a2a5cc+CHANGES",
+             "GoVersion": "go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+        GET /_ping HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        OK
+
+Status Codes:
+
+-   **200** - no error
+-   **500** - server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname": "",
+             "Domainname": "",
+             "User": "",
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "Cpuset": "0,1",
+             "AttachStdin": false,
+             "AttachStdout": true,
+             "AttachStderr": true,
+             "PortSpecs": null,
+             "Tty": false,
+             "OpenStdin": false,
+             "StdinOnce": false,
+             "Env": null,
+             "Cmd": [
+                     "date"
+             ],
+             "Volumes": {
+                     "/tmp": {}
+             },
+             "WorkingDir": "",
+             "NetworkDisabled": false,
+             "ExposedPorts": {
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {"Id": "596069db4bf5"}
+
+Json Parameters:
+
+-  **config** - the container's configuration
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, exec_create, exec_start, export, kill, oom, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+-   **until** – timestamp used for polling
+-   **filters** – a json encoded value of the filters (a map[string][]string) to process on the event list. Available filters:
+  -   event=&lt;string&gt; -- event to filter
+  -   image=&lt;string&gt; -- image to filter
+  -   container=&lt;string&gt; -- container to filter
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository specified
+by `name`.
+
+If `name` is a specific name and tag (e.g. ubuntu:latest), then only that image
+(and its parents) are returned. If `name` is an image ID, similarly only that
+image (and its parents) are returned, but with the exclusion of the
+'repositories' file in the tarball, as there were no image names referenced.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/ubuntu/get
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images.
+
+`GET /images/get`
+
+Get a tarball containing all images and metadata for one or more repositories.
+
+For each value of the `names` parameter: if it is a specific name and tag (e.g.
+ubuntu:latest), then only that image (and its parents) are returned; if it is
+an image ID, similarly only that image (and its parents) are returned and there
+would be no names referenced in the 'repositories' file for this image ID.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/get?names=myname%2Fmyapp%3Alatest&names=busybox
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into the docker repository.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        POST /images/load
+
+        Tarball in body
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing three files:
+
+1. `VERSION`: currently `1.0` - the file format version
+2. `json`: detailed layer information, similar to `docker inspect layer_id`
+3. `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file will contain `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, there will also be a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+### Exec Create
+
+`POST /containers/(id or name)/exec`
+
+Sets up an exec instance in a running container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/exec HTTP/1.1
+        Content-Type: application/json
+
+        {
+	     "AttachStdin": false,
+	     "AttachStdout": true,
+	     "AttachStderr": true,
+	     "Tty": false,
+	     "Cmd": [
+                     "date"
+             ],
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id": "f90e34656806"
+        }
+
+Json Parameters:
+
+-   **AttachStdin** - Boolean value, attaches to stdin of the exec command.
+-   **AttachStdout** - Boolean value, attaches to stdout of the exec command.
+-   **AttachStderr** - Boolean value, attaches to stderr of the exec command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY
+-   **Cmd** - Command to run specified as a string or an array of strings.
+
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+
+### Exec Start
+
+`POST /exec/(id)/start`
+
+Starts a previously set up exec instance `id`. If `detach` is true, this API
+returns after starting the `exec` command. Otherwise, this API sets up an
+interactive session with the `exec` command.
+
+**Example request**:
+
+        POST /exec/e90e34656806/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+	     "Detach": false,
+	     "Tty": false,
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Json Parameters:
+
+-   **Detach** - Detach from the exec command
+-   **Tty** - Boolean value to allocate a pseudo-TTY
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such exec instance
+
+    **Stream details**:
+    Similar to the stream behavior of `POST /containers/(id or name)/attach` API
+
+### Exec Resize
+
+`POST /exec/(id)/resize`
+
+Resizes the tty session used by the exec command `id`.
+This API is valid only if `tty` was specified as part of creating and starting the exec command.
+
+**Example request**:
+
+        POST /exec/e90e34656806/resize HTTP/1.1
+        Content-Type: text/plain
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: text/plain
+
+Query Parameters:
+
+-   **h** – height of tty session
+-   **w** – width
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such exec instance
+
+### Exec Inspect
+
+`GET /exec/(id)/json`
+
+Return low-level information about the exec command `id`.
+
+**Example request**:
+
+        GET /exec/11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: plain/text
+
+        {
+          "ID" : "11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39",
+          "Running" : false,
+          "ExitCode" : 2,
+          "ProcessConfig" : {
+            "privileged" : false,
+            "user" : "",
+            "tty" : false,
+            "entrypoint" : "sh",
+            "arguments" : [
+              "-c",
+              "exit 2"
+            ]
+          },
+          "OpenStdin" : false,
+          "OpenStderr" : false,
+          "OpenStdout" : false,
+          "Container" : {
+            "State" : {
+              "Running" : true,
+              "Paused" : false,
+              "Restarting" : false,
+              "OOMKilled" : false,
+              "Pid" : 3650,
+              "ExitCode" : 0,
+              "Error" : "",
+              "StartedAt" : "2014-11-17T22:26:03.717657531Z",
+              "FinishedAt" : "0001-01-01T00:00:00Z"
+            },
+            "ID" : "8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c",
+            "Created" : "2014-11-17T22:26:03.626304998Z",
+            "Path" : "date",
+            "Args" : [],
+            "Config" : {
+              "Hostname" : "8f177a186b97",
+              "Domainname" : "",
+              "User" : "",
+              "Memory" : 0,
+              "MemorySwap" : 0,
+              "CpuShares" : 0,
+              "Cpuset" : "",
+              "AttachStdin" : false,
+              "AttachStdout" : false,
+              "AttachStderr" : false,
+              "PortSpecs" : null,
+              "ExposedPorts" : null,
+              "Tty" : false,
+              "OpenStdin" : false,
+              "StdinOnce" : false,
+              "Env" : [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ],
+              "Cmd" : [
+                "date"
+              ],
+              "Image" : "ubuntu",
+              "Volumes" : null,
+              "WorkingDir" : "",
+              "Entrypoint" : null,
+              "NetworkDisabled" : false,
+              "MacAddress" : "",
+              "OnBuild" : null,
+              "SecurityOpt" : null
+            },
+            "Image" : "5506de2b643be1e6febbf3b8a240760c6843244c41e12aa2f60ccbb7153d17f5",
+            "NetworkSettings" : {
+              "IPAddress" : "172.17.0.2",
+              "IPPrefixLen" : 16,
+              "MacAddress" : "02:42:ac:11:00:02",
+              "Gateway" : "172.17.42.1",
+              "Bridge" : "docker0",
+              "PortMapping" : null,
+              "Ports" : {}
+            },
+            "ResolvConfPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/resolv.conf",
+            "HostnamePath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hostname",
+            "HostsPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hosts",
+            "Name" : "/test",
+            "Driver" : "aufs",
+            "ExecDriver" : "native-0.2",
+            "MountLabel" : "",
+            "ProcessLabel" : "",
+            "AppArmorProfile" : "",
+            "RestartCount" : 0,
+            "Volumes" : {},
+            "VolumesRW" : {}
+          }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such exec instance
+-   **500** - server error
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it
+    - Then retry to create the container
+
+- Start the container
+
+- If you are not in detached mode:
+- Attach to the container, using logs=1 (to have stdout and
+      stderr from the container's start) and stream=1
+
+- If in detached mode or only stdin is attached:
+- Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket.
+
+To hint potential proxies about connection hijacking, Docker client sends
+connection upgrade headers similarly to websocket.
+
+    Upgrade: tcp
+    Connection: Upgrade
+
+When Docker daemon detects the `Upgrade` header, it will switch its status code
+from **200 OK** to **101 UPGRADED** and resend the same headers.
+
+This might change in the future.
+
+## 3.3 CORS Requests
+
+To set cross origin requests to the remote api, please add flag "--api-enable-cors"
+when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.18.md b/_vendor/github.com/moby/moby/api/docs/v1.18.md
new file mode 100644
index 000000000000..650c562037d1
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.18.md
@@ -0,0 +1,2173 @@
+---
+title: "Engine API v1.18"
+description: "API Documentation for Docker"
+keywords: "API, Docker, rcli, REST, documentation"
+aliases:
+- /engine/reference/api/docker_remote_api_v1.18/
+- /reference/api/docker_remote_api_v1.18/
+---
+
+<!-- This file is maintained within the moby/moby GitHub
+     repository at https://github.com/moby/moby/. Make all
+     pull requests against that repo. If you see this file in
+     another repository, consider it read-only there, as it will
+     periodically be overwritten by the definitive file. Pull
+     requests which include edits to this file in other repositories
+     will be rejected.
+-->
+
+## 1. Brief introduction
+
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](https://docs.docker.com/engine/reference/commandline/dockerd/#bind-docker-to-another-host-port-or-a-unix-socket).
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `stdout`,
+   `stdin` and `stderr`.
+ - A `Content-Length` header should be present in `POST` requests to endpoints
+   that expect a body.
+ - To lock to a specific version of the API, you prefix the URL with the version
+   of the API to use. For example, `/v1.18/info`. If no version is included in
+   the URL, the maximum supported API version is used.
+ - If the API version specified in the URL is not supported by the daemon, a HTTP
+   `400 Bad Request` error message is returned.
+
+## 2. Endpoints
+
+### 2.1 Containers
+
+#### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+    GET /v1.18/containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Id": "8dfafdbc3a40",
+                 "Names":["/boring_feynman"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 1",
+                 "Created": 1367854155,
+                 "Status": "Exit 0",
+                 "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                 "Labels": {
+                         "com.example.vendor": "Acme",
+                         "com.example.license": "GPL",
+                         "com.example.version": "1.0"
+                 },
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         },
+         {
+                 "Id": "9cd87474be90",
+                 "Names":["/coolName"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 222222",
+                 "Created": 1367854155,
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         },
+         {
+                 "Id": "3176a2479c92",
+                 "Names":["/sleepy_dog"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 3333333333333333",
+                 "Created": 1367854154,
+                 "Status": "Exit 0",
+                 "Ports":[],
+                 "Labels": {},
+                 "SizeRw":12288,
+                 "SizeRootFs":0
+         },
+         {
+                 "Id": "4cb07b47f9fb",
+                 "Names":["/running_cat"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 444444444444444444444444444444444",
+                 "Created": 1367854152,
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         }
+    ]
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers
+        sizes
+-   **filters** - a JSON encoded value of the filters (a `map[string][]string`) to process on the containers list. Available filters:
+  -   `exited=<int>`; -- containers with exit code of  `<int>` ;
+  -   `status=`(`restarting`|`running`|`paused`|`exited`)
+  -   `label=key` or `label="key=value"` of a container label
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+#### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+    POST /v1.18/containers/create HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+           "Hostname": "",
+           "Domainname": "",
+           "User": "",
+           "AttachStdin": false,
+           "AttachStdout": true,
+           "AttachStderr": true,
+           "Tty": false,
+           "OpenStdin": false,
+           "StdinOnce": false,
+           "Env": [
+                   "FOO=bar",
+                   "BAZ=quux"
+           ],
+           "Cmd": [
+                   "date"
+           ],
+           "Entrypoint": null,
+           "Image": "ubuntu",
+           "Labels": {
+                   "com.example.vendor": "Acme",
+                   "com.example.license": "GPL",
+                   "com.example.version": "1.0"
+           },
+           "Volumes": {
+             "/volumes/data": {}
+           },
+           "WorkingDir": "",
+           "NetworkDisabled": false,
+           "MacAddress": "12:34:56:78:9a:bc",
+           "ExposedPorts": {
+                   "22/tcp": {}
+           },
+           "HostConfig": {
+             "Binds": ["/tmp:/tmp"],
+             "Links": ["redis3:redis"],
+             "LxcConf": {"lxc.utsname":"docker"},
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "CpusetCpus": "0,1",
+             "PidMode": "",
+             "PortBindings": { "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts": false,
+             "Privileged": false,
+             "ReadonlyRootfs": false,
+             "Dns": ["8.8.8.8"],
+             "DnsSearch": [""],
+             "ExtraHosts": null,
+             "VolumesFrom": ["parent", "other:ro"],
+             "CapAdd": ["NET_ADMIN"],
+             "CapDrop": ["MKNOD"],
+             "RestartPolicy": { "Name": "", "MaximumRetryCount": 0 },
+             "NetworkMode": "bridge",
+             "Devices": [],
+             "Ulimits": [{}],
+             "LogConfig": { "Type": "json-file", "Config": {} },
+             "SecurityOpt": [],
+             "CgroupParent": ""
+          }
+      }
+
+**Example response**:
+
+      HTTP/1.1 201 Created
+      Content-Type: application/json
+
+      {
+           "Id":"e90e34656806",
+           "Warnings":[]
+      }
+
+**JSON parameters**:
+
+-   **Hostname** - A string value containing the hostname to use for the
+      container.
+-   **Domainname** - A string value containing the domain name to use
+      for the container.
+-   **User** - A string value specifying the user inside the container.
+-   **AttachStdin** - Boolean value, attaches to `stdin`.
+-   **AttachStdout** - Boolean value, attaches to `stdout`.
+-   **AttachStderr** - Boolean value, attaches to `stderr`.
+-   **Tty** - Boolean value, Attach standard streams to a `tty`, including `stdin` if it is not closed.
+-   **OpenStdin** - Boolean value, opens `stdin`,
+-   **StdinOnce** - Boolean value, close `stdin` after the 1 attached client disconnects.
+-   **Env** - A list of environment variables in the form of `["VAR=value", ...]`
+-   **Labels** - Adds a map of labels to a container. To specify a map: `{"key":"value", ... }`
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Entrypoint** - Set the entry point for the container as a string or an array
+      of strings.
+-   **Image** - A string specifying the image name to use for the container.
+-   **Volumes** - An object mapping mount point paths (strings) inside the
+      container to empty objects.
+-   **WorkingDir** - A string specifying the working directory for commands to
+      run in.
+-   **NetworkDisabled** - Boolean value, when true disables networking for the
+      container
+-   **ExposedPorts** - An object mapping ports to an empty object in the form of:
+      `"ExposedPorts": { "<port>/<tcp|udp>: {}" }`
+-   **HostConfig**
+    -   **Binds** – A list of bind mounts for this container. Each item is a string in one of these forms:
+           + `host-src:container-dest` to bind-mount a host path into the
+             container. Both `host-src`, and `container-dest` must be an
+             _absolute_ path.
+           + `host-src:container-dest:ro` to make the bind mount read-only
+             inside the container. Both `host-src`, and `container-dest` must be
+             an _absolute_ path.
+    -   **Links** - A list of links for the container. Each link entry should be
+          in the form of `container_name:alias`.
+    -   **LxcConf** - LXC specific configurations. These configurations only
+          work when using the `lxc` execution driver.
+    -   **Memory** - Memory limit in bytes.
+    -   **MemorySwap** - Total memory limit (memory + swap); set `-1` to enable unlimited swap.
+          You must use this with `memory` and make the swap value larger than `memory`.
+    -   **CpuShares** - An integer value containing the container's CPU Shares
+          (ie. the relative weight vs other containers).
+    -   **CpusetCpus** - String value containing the `cgroups CpusetCpus` to use.
+    -   **PidMode** - Set the PID (Process) Namespace mode for the container;
+          `"container:<name|id>"`: joins another container's PID namespace
+          `"host"`: use the host's PID namespace inside the container
+    -   **PortBindings** - A map of exposed container ports and the host port they
+          should map to. A JSON object in the form
+          `{ <port>/<protocol>: [{ "HostPort": "<port>" }] }`
+          Take note that `port` is specified as a string and not an integer value.
+    -   **PublishAllPorts** - Allocates an ephemeral host port for all of a container's
+          exposed ports. Specified as a boolean value.
+
+          Ports are de-allocated when the container stops and allocated when the container starts.
+          The allocated port might be changed when restarting the container.
+
+          The port is selected from the ephemeral port range that depends on the kernel.
+          For example, on Linux the range is defined by `/proc/sys/net/ipv4/ip_local_port_range`.
+    -   **Privileged** - Gives the container full access to the host. Specified as
+          a boolean value.
+    -   **ReadonlyRootfs** - Mount the container's root filesystem as read only.
+          Specified as a boolean value.
+    -   **Dns** - A list of DNS servers for the container to use.
+    -   **DnsSearch** - A list of DNS search domains
+    -   **ExtraHosts** - A list of hostnames/IP mappings to add to the
+        container's `/etc/hosts` file. Specified in the form `["hostname:IP"]`.
+    -   **VolumesFrom** - A list of volumes to inherit from another container.
+          Specified in the form `<container name>[:<ro|rw>]`
+    -   **CapAdd** - A list of kernel capabilities to add to the container.
+    -   **Capdrop** - A list of kernel capabilities to drop from the container.
+    -   **RestartPolicy** – The behavior to apply when the container exits.  The
+            value is an object with a `Name` property of either `"always"` to
+            always restart or `"on-failure"` to restart only when the container
+            exit code is non-zero.  If `on-failure` is used, `MaximumRetryCount`
+            controls the number of times to retry before giving up.
+            The default is not to restart. (optional)
+            An ever increasing delay (double the previous delay, starting at 100mS)
+            is added before each restart to prevent flooding the server.
+    -   **NetworkMode** - Sets the networking mode for the container. Supported
+          values are: `bridge`, `host`, `none`, and `container:<name|id>`
+    -   **Devices** - A list of devices to add to the container specified as a JSON object in the
+      form
+          `{ "PathOnHost": "/dev/deviceName", "PathInContainer": "/dev/deviceName", "CgroupPermissions": "mrw"}`
+    -   **Ulimits** - A list of ulimits to set in the container, specified as
+          `{ "Name": <name>, "Soft": <soft limit>, "Hard": <hard limit> }`, for example:
+          `Ulimits: { "Name": "nofile", "Soft": 1024, "Hard": 2048 }`
+    -   **SecurityOpt**: A list of string values to customize labels for MLS
+        systems, such as SELinux.
+    -   **LogConfig** - Log configuration for the container, specified as a JSON object in the form
+          `{ "Type": "<driver_name>", "Config": {"key1": "val1"}}`.
+          Available types: `json-file`, `syslog`, `journald`, `none`.
+          `json-file` logging driver.
+    -   **CgroupParent** - Path to `cgroups` under which the container's `cgroup` is created. If the path is not absolute, the path is considered to be relative to the `cgroups` path of the init process. Cgroups are created if they do not already exist.
+
+**Query parameters**:
+
+-   **name** – Assign the specified name to the container. Must
+    match `/?[a-zA-Z0-9_-]+`.
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **406** – impossible to attach (container not running)
+-   **409** – conflict
+-   **500** – server error
+
+#### Inspect a container
+
+`GET /containers/(id or name)/json`
+
+Return low-level information on the container `id`
+
+**Example request**:
+
+      GET /v1.18/containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+	{
+		"AppArmorProfile": "",
+		"Args": [
+			"-c",
+			"exit 9"
+		],
+		"Config": {
+			"AttachStderr": true,
+			"AttachStdin": false,
+			"AttachStdout": true,
+			"Cmd": [
+				"/bin/sh",
+				"-c",
+				"exit 9"
+			],
+			"Domainname": "",
+			"Entrypoint": null,
+			"Env": [
+				"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+			],
+			"ExposedPorts": null,
+			"Hostname": "ba033ac44011",
+			"Image": "ubuntu",
+			"Labels": {
+				"com.example.vendor": "Acme",
+				"com.example.license": "GPL",
+				"com.example.version": "1.0"
+			},
+			"MacAddress": "",
+			"NetworkDisabled": false,
+			"OnBuild": null,
+			"OpenStdin": false,
+			"PortSpecs": null,
+			"StdinOnce": false,
+			"Tty": false,
+			"User": "",
+			"Volumes": null,
+			"WorkingDir": ""
+		},
+		"Created": "2015-01-06T15:47:31.485331387Z",
+		"Driver": "overlay2",
+		"ExecDriver": "native-0.2",
+		"ExecIDs": null,
+		"HostConfig": {
+			"Binds": null,
+			"CapAdd": null,
+			"CapDrop": null,
+			"ContainerIDFile": "",
+			"CpusetCpus": "",
+			"CpuShares": 0,
+			"Devices": [],
+			"Dns": null,
+			"DnsSearch": null,
+			"ExtraHosts": null,
+			"IpcMode": "",
+			"Links": null,
+			"LxcConf": [],
+			"Memory": 0,
+			"MemorySwap": 0,
+			"NetworkMode": "bridge",
+			"PidMode": "",
+			"PortBindings": {},
+			"Privileged": false,
+			"ReadonlyRootfs": false,
+			"PublishAllPorts": false,
+			"RestartPolicy": {
+				"MaximumRetryCount": 2,
+				"Name": "on-failure"
+			},
+			"LogConfig": {
+				"Config": null,
+				"Type": "json-file"
+			},
+			"SecurityOpt": null,
+			"VolumesFrom": null,
+			"Ulimits": [{}]
+		},
+		"HostnamePath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hostname",
+		"HostsPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hosts",
+		"LogPath": "/var/lib/docker/containers/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b-json.log",
+		"Id": "ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39",
+		"Image": "04c5d3b7b0656168630d3ba35d8889bd0e9caafcaeb3004d2bfbc47e7c5d35d2",
+		"MountLabel": "",
+		"Name": "/boring_euclid",
+		"NetworkSettings": {
+			"Bridge": "",
+			"Gateway": "",
+			"IPAddress": "",
+			"IPPrefixLen": 0,
+			"MacAddress": "",
+			"PortMapping": null,
+			"Ports": null
+		},
+		"Path": "/bin/sh",
+		"ProcessLabel": "",
+		"ResolvConfPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/resolv.conf",
+		"RestartCount": 1,
+		"State": {
+			"Error": "",
+			"ExitCode": 9,
+			"FinishedAt": "2015-01-06T15:47:32.080254511Z",
+			"OOMKilled": false,
+			"Paused": false,
+			"Pid": 0,
+			"Restarting": false,
+			"Running": true,
+			"StartedAt": "2015-01-06T15:47:32.072697474Z"
+		},
+		"Volumes": {},
+		"VolumesRW": {}
+	}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### List processes running inside a container
+
+`GET /containers/(id or name)/top`
+
+List processes running inside the container `id`. On Unix systems this
+is done by running the `ps` command. This endpoint is not
+supported on Windows.
+
+**Example request**:
+
+    GET /v1.18/containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Titles" : [
+         "UID", "PID", "PPID", "C", "STIME", "TTY", "TIME", "CMD"
+       ],
+       "Processes" : [
+         [
+           "root", "13642", "882", "0", "17:03", "pts/0", "00:00:00", "/bin/bash"
+         ],
+         [
+           "root", "13735", "13642", "0", "17:06", "pts/0", "00:00:00", "sleep 10"
+         ]
+       ]
+    }
+
+**Example request**:
+
+    GET /v1.18/containers/4fa6e0f0c678/top?ps_args=aux HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Titles" : [
+        "USER","PID","%CPU","%MEM","VSZ","RSS","TTY","STAT","START","TIME","COMMAND"
+      ]
+      "Processes" : [
+        [
+          "root","13642","0.0","0.1","18172","3184","pts/0","Ss","17:03","0:00","/bin/bash"
+        ],
+        [
+          "root","13895","0.0","0.0","4348","692","pts/0","S+","17:15","0:00","sleep 10"
+        ]
+      ],
+    }
+
+**Query parameters**:
+
+-   **ps_args** – `ps` arguments to use (e.g., `aux`), defaults to `-ef`
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container logs
+
+`GET /containers/(id or name)/logs`
+
+Get `stdout` and `stderr` logs from the container ``id``
+
+> **Note**:
+> This endpoint works only for containers with the `json-file` or `journald` logging drivers.
+
+**Example request**:
+
+     GET /v1.18/containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10 HTTP/1.1
+
+**Example response**:
+
+     HTTP/1.1 101 UPGRADED
+     Content-Type: application/vnd.docker.raw-stream
+     Connection: Upgrade
+     Upgrade: tcp
+
+     {% raw %}
+     {{ STREAM }}
+     {% endraw %}
+
+**Query parameters**:
+
+-   **follow** – 1/True/true or 0/False/false, return stream. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, show `stdout` log. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, show `stderr` log. Default `false`.
+-   **timestamps** – 1/True/true or 0/False/false, print timestamps for
+        every log line. Default `false`.
+-   **tail** – Output specified number of lines at the end of logs: `all` or `<number>`. Default all.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **404** – no such container
+-   **500** – server error
+
+#### Inspect changes on a container's filesystem
+
+`GET /containers/(id or name)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+    GET /v1.18/containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Path": "/dev",
+                 "Kind": 0
+         },
+         {
+                 "Path": "/dev/kmsg",
+                 "Kind": 1
+         },
+         {
+                 "Path": "/test",
+                 "Kind": 1
+         }
+    ]
+
+Values for `Kind`:
+
+- `0`: Modify
+- `1`: Add
+- `2`: Delete
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Export a container
+
+`GET /containers/(id or name)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+    GET /v1.18/containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/octet-stream
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container stats based on resource usage
+
+`GET /containers/(id or name)/stats`
+
+This endpoint returns a live stream of a container's resource usage statistics.
+
+**Example request**:
+
+    GET /v1.18/containers/redis1/stats HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Type: application/json
+
+      {
+         "read" : "2015-01-08T22:57:31.547920715Z",
+         "network" : {
+            "rx_dropped" : 0,
+            "rx_bytes" : 648,
+            "rx_errors" : 0,
+            "tx_packets" : 8,
+            "tx_dropped" : 0,
+            "rx_packets" : 8,
+            "tx_errors" : 0,
+            "tx_bytes" : 648
+         },
+         "memory_stats" : {
+            "stats" : {
+               "total_pgmajfault" : 0,
+               "cache" : 0,
+               "mapped_file" : 0,
+               "total_inactive_file" : 0,
+               "pgpgout" : 414,
+               "rss" : 6537216,
+               "total_mapped_file" : 0,
+               "writeback" : 0,
+               "unevictable" : 0,
+               "pgpgin" : 477,
+               "total_unevictable" : 0,
+               "pgmajfault" : 0,
+               "total_rss" : 6537216,
+               "total_rss_huge" : 6291456,
+               "total_writeback" : 0,
+               "total_inactive_anon" : 0,
+               "rss_huge" : 6291456,
+               "hierarchical_memory_limit" : 67108864,
+               "total_pgfault" : 964,
+               "total_active_file" : 0,
+               "active_anon" : 6537216,
+               "total_active_anon" : 6537216,
+               "total_pgpgout" : 414,
+               "total_cache" : 0,
+               "inactive_anon" : 0,
+               "active_file" : 0,
+               "pgfault" : 964,
+               "inactive_file" : 0,
+               "total_pgpgin" : 477
+            },
+            "max_usage" : 6651904,
+            "usage" : 6537216,
+            "failcnt" : 0,
+            "limit" : 67108864
+         },
+         "blkio_stats" : {},
+         "cpu_stats" : {
+            "cpu_usage" : {
+               "percpu_usage" : [
+                  16970827,
+                  1839451,
+                  7107380,
+                  10571290
+               ],
+               "usage_in_usermode" : 10000000,
+               "total_usage" : 36488948,
+               "usage_in_kernelmode" : 20000000
+            },
+            "system_cpu_usage" : 20091722000000000,
+            "throttling_data" : {}
+         }
+      }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Resize a container TTY
+
+`POST /containers/(id or name)/resize?h=<height>&w=<width>`
+
+Resize the TTY for container with  `id`. You must restart the container for the resize to take effect.
+
+**Example request**:
+
+      POST /v1.18/containers/4fa6e0f0c678/resize?h=40&w=80 HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Length: 0
+      Content-Type: text/plain; charset=utf-8
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – No such container
+-   **500** – Cannot resize container
+
+#### Start a container
+
+`POST /containers/(id or name)/start`
+
+Start the container `id`
+
+> **Note**:
+> For backwards compatibility, this endpoint accepts a `HostConfig` as JSON-encoded request body.
+> See [create a container](#create-a-container) for details.
+
+**Example request**:
+
+    POST /v1.18/containers/e90e34656806/start HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already started
+-   **404** – no such container
+-   **500** – server error
+
+#### Stop a container
+
+`POST /containers/(id or name)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+    POST /v1.18/containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already stopped
+-   **404** – no such container
+-   **500** – server error
+
+#### Restart a container
+
+`POST /containers/(id or name)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+    POST /v1.18/containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Kill a container
+
+`POST /containers/(id or name)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+    POST /v1.18/containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **signal** - Signal to send to the container: integer or string like `SIGINT`.
+        When not set, `SIGKILL` is assumed and the call waits for the container to exit.
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Rename a container
+
+`POST /containers/(id or name)/rename`
+
+Rename the container `id` to a `new_name`
+
+**Example request**:
+
+    POST /v1.18/containers/e90e34656806/rename?name=new_name HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **name** – new name for the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **409** - conflict name already assigned
+-   **500** – server error
+
+#### Pause a container
+
+`POST /containers/(id or name)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+    POST /v1.18/containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Unpause a container
+
+`POST /containers/(id or name)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+    POST /v1.18/containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Attach to a container
+
+`POST /containers/(id or name)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+    POST /v1.18/containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 101 UPGRADED
+    Content-Type: application/vnd.docker.raw-stream
+    Connection: Upgrade
+    Upgrade: tcp
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+-   **stdin** – 1/True/true or 0/False/false, if `stream=true`, attach
+        to `stdin`. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stdout` log, if `stream=true`, attach to `stdout`. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stderr` log, if `stream=true`, attach to `stderr`. Default `false`.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+**Stream details**:
+
+When using the TTY setting is enabled in
+[`POST /containers/create`
+](#create-a-container),
+the stream is the raw data from the process PTY and client's `stdin`.
+When the TTY is disabled, then the stream is multiplexed to separate
+`stdout` and `stderr`.
+
+The format is a **Header** and a **Payload** (frame).
+
+**HEADER**
+
+The header contains the information which the stream writes (`stdout` or
+`stderr`). It also contains the size of the associated frame encoded in the
+last four bytes (`uint32`).
+
+It is encoded on the first eight bytes like this:
+
+    header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+`STREAM_TYPE` can be:
+
+-   0: `stdin` (is written on `stdout`)
+-   1: `stdout`
+-   2: `stderr`
+
+`SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of
+the `uint32` size encoded as big endian.
+
+**PAYLOAD**
+
+The payload is the raw stream.
+
+**IMPLEMENTATION**
+
+The simplest way to implement the Attach protocol is the following:
+
+    1.  Read eight bytes.
+    2.  Choose `stdout` or `stderr` depending on the first byte.
+    3.  Extract the frame size from the last four bytes.
+    4.  Read the extracted size and output it on the correct output.
+    5.  Goto 1.
+
+#### Attach to a container (websocket)
+
+`GET /containers/(id or name)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+    GET /v1.18/containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+#### Wait a container
+
+`POST /containers/(id or name)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+    POST /v1.18/containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"StatusCode": 0}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Remove a container
+
+`DELETE /containers/(id or name)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.18/containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default `false`.
+-   **force** - 1/True/true or 0/False/false, Kill then remove the container.
+        Default `false`.
+-   **link** - 1/True/true or 0/False/false, Remove the specified
+        link associated to the container. Default `false`.
+
+**Status codes**:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **409** – conflict
+-   **500** – server error
+
+#### Copy files or folders from a container
+
+`POST /containers/(id or name)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+    POST /v1.18/containers/4fa6e0f0c678/copy HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Resource": "test.txt"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### 2.2 Images
+
+#### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+    GET /v1.18/images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+         "RepoTags": [
+           "ubuntu:12.04",
+           "ubuntu:precise",
+           "ubuntu:latest"
+         ],
+         "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+         "Created": 1365714795,
+         "Size": 131506275,
+         "VirtualSize": 131506275
+      },
+      {
+         "RepoTags": [
+           "ubuntu:12.10",
+           "ubuntu:quantal"
+         ],
+         "ParentId": "27cf784147099545",
+         "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+         "Created": 1364102658,
+         "Size": 24653,
+         "VirtualSize": 180116135
+      }
+    ]
+
+**Example request, with digest information**:
+
+    GET /v1.18/images/json?digests=1 HTTP/1.1
+
+**Example response, with digest information**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+        "Created": 1420064636,
+        "Id": "4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125",
+        "ParentId": "ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2",
+        "RepoDigests": [
+          "localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf"
+        ],
+        "RepoTags": [
+          "localhost:5000/test/busybox:latest",
+          "playdate:latest"
+        ],
+        "Size": 0,
+        "VirtualSize": 2429728
+      }
+    ]
+
+The response shows a single image `Id` associated with two repositories
+(`RepoTags`): `localhost:5000/test/busybox`: and `playdate`. A caller can use
+either of the `RepoTags` values `localhost:5000/test/busybox:latest` or
+`playdate:latest` to reference the image.
+
+You can also use `RepoDigests` values to reference an image. In this response,
+the array has only one reference and that is to the
+`localhost:5000/test/busybox` repository; the `playdate` repository has no
+digest. You can reference this digest using the value:
+`localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d...`
+
+See the `docker run` and `docker build` commands for examples of digest and tag
+references on the command line.
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a JSON encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   `dangling=true`
+  -   `label=key` or `label="key=value"` of an image label
+-   **filter** - only return images with the specified name
+
+#### Build image from a Dockerfile
+
+`POST /build`
+
+Build an image from a Dockerfile
+
+**Example request**:
+
+    POST /v1.18/build HTTP/1.1
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"stream": "Step 1/5..."}
+    {"stream": "..."}
+    {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+The input stream must be a `tar` archive compressed with one of the
+following algorithms: `identity` (no compression), `gzip`, `bzip2`, `xz`.
+
+The archive must include a build instructions file, typically called
+`Dockerfile` at the archive's root. The `dockerfile` parameter may be
+used to specify a different build instructions file. To do this, its value must be
+the path to the alternate build instructions file to use.
+
+The archive may include any number of other files,
+which are accessible in the build context (See the [*ADD build
+command*](https://docs.docker.com/engine/reference/builder/#add)).
+
+The Docker daemon performs a preliminary validation of the `Dockerfile` before
+starting the build, and returns an error if the syntax is incorrect. After that,
+each instruction is run one-by-one until the ID of the new image is output.
+
+The build is canceled if the client drops the connection by quitting
+or being killed.
+
+**Query parameters**:
+
+-   **dockerfile** - Path within the build context to the Dockerfile. This is
+        ignored if `remote` is specified and points to an individual filename.
+-   **t** – A name and optional tag to apply to the image in the `name:tag` format.
+        If you omit the `tag` the default `latest` value is assumed.
+-   **remote** – A Git repository URI or HTTP/HTTPS context URI. If the
+        URI points to a single text file, the file's contents are placed into
+        a file called `Dockerfile` and the image is built from that file.
+-   **q** – Suppress verbose build output.
+-   **nocache** – Do not use the cache when building the image.
+-   **pull** - Attempt to pull the image even if an older image exists locally.
+-   **rm** - Remove intermediate containers after a successful build (default behavior).
+-   **forcerm** - Always remove intermediate containers (includes `rm`).
+-   **memory** - Set memory limit for build.
+-   **memswap** - Total memory (memory + swap), `-1` to enable unlimited swap.
+-   **cpushares** - CPU shares (relative weight).
+-   **cpusetcpus** - CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+
+**Request Headers**:
+
+-   **Content-type** – Set to `"application/x-tar"`.
+-   **X-Registry-Config** – base64-encoded ConfigFile object
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Create an image
+
+`POST /images/create`
+
+Create an image either by pulling it from the registry or by importing it
+
+**Example request**:
+
+    POST /v1.18/images/create?fromImage=busybox&tag=latest HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pulling..."}
+    {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+    {"error": "Invalid..."}
+    ...
+
+When using this endpoint to pull an image from the registry, the
+`X-Registry-Auth` header can be used to include
+a base64-encoded AuthConfig object.
+
+**Query parameters**:
+
+-   **fromImage** – Name of the image to pull.
+-   **fromSrc** – Source to import.  The value may be a URL from which the image
+        can be retrieved or `-` to read the image from the request body.
+-   **repo** – Repository name.
+-   **tag** – Tag. If empty when pulling an image, this causes all tags
+        for the given image to be pulled.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** - repository does not exist or no read access
+-   **500** – server error
+
+
+
+#### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+    GET /v1.18/images/ubuntu/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Created": "2013-03-23T22:24:18.818426-07:00",
+       "Container": "3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+       "ContainerConfig": {
+          "Hostname": "",
+          "User": "",
+          "AttachStdin": false,
+          "AttachStdout": false,
+          "AttachStderr": false,
+          "Tty": true,
+          "OpenStdin": true,
+          "StdinOnce": false,
+          "Env": null,
+          "Cmd": ["/bin/bash"],
+          "Dns": null,
+          "Image": "ubuntu",
+          "Labels": {
+             "com.example.vendor": "Acme",
+             "com.example.license": "GPL",
+             "com.example.version": "1.0"
+          },
+          "Volumes": null,
+          "VolumesFrom": "",
+          "WorkingDir": ""
+       },
+       "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+       "Parent": "27cf784147099545",
+       "Size": 6824592
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+    GET /v1.18/images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+        {
+            "Id": "b750fe79269d",
+            "Created": 1364102658,
+            "CreatedBy": "/bin/bash"
+        },
+        {
+            "Id": "27cf78414709",
+            "Created": 1364068391,
+            "CreatedBy": ""
+        }
+    ]
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+    POST /v1.18/images/test/push HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pushing..."}
+    {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+    {"error": "Invalid..."}
+    ...
+
+If you wish to push an image on to a private registry, that image must already have a tag
+into a repository which references that registry `hostname` and `port`.  This repository name should
+then be used in the URL. This duplicates the command line's flow.
+
+**Example request**:
+
+    POST /v1.18/images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+**Query parameters**:
+
+-   **tag** – The tag to associate with the image on the registry. This is optional.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+    POST /v1.18/images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+
+**Query parameters**:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.18/images/test HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-type: application/json
+
+    [
+     {"Untagged": "3e2f21a89f"},
+     {"Deleted": "3e2f21a89f"},
+     {"Deleted": "53b4f83ac9"}
+    ]
+
+**Query parameters**:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+    GET /v1.18/images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+            {
+                "star_count": 12,
+                "is_official": false,
+                "name": "wma55/u1210sshd",
+                "is_automated": false,
+                "description": ""
+            },
+            {
+                "star_count": 10,
+                "is_official": false,
+                "name": "jdswinbank/sshd",
+                "is_automated": false,
+                "description": ""
+            },
+            {
+                "star_count": 18,
+                "is_official": false,
+                "name": "vgauthier/sshd",
+                "is_automated": false,
+                "description": ""
+            }
+    ...
+    ]
+
+**Query parameters**:
+
+-   **term** – term to search
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+### 2.3 Misc
+
+#### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+    POST /v1.18/auth HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "username": "hannibal",
+         "password": "xxxx",
+         "email": "hannibal@a-team.com",
+         "serveraddress": "https://index.docker.io/v1/"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+#### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+    GET /v1.18/info HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+        "Containers": 11,
+        "Debug": 0,
+        "DockerRootDir": "/var/lib/docker",
+        "Driver": "btrfs",
+        "DriverStatus": [[""]],
+        "ExecutionDriver": "native-0.1",
+        "HttpProxy": "http://test:test@localhost:8080",
+        "HttpsProxy": "https://test:test@localhost:8080",
+        "ID": "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS",
+        "IPv4Forwarding": 1,
+        "Images": 16,
+        "IndexServerAddress": "https://index.docker.io/v1/",
+        "InitPath": "/usr/bin/docker",
+        "InitSha1": "",
+        "KernelVersion": "3.12.0-1-amd64",
+        "Labels": [
+            "storage=ssd"
+        ],
+        "MemTotal": 2099236864,
+        "MemoryLimit": 1,
+        "NCPU": 1,
+        "NEventsListener": 0,
+        "NFd": 11,
+        "NGoroutines": 21,
+        "Name": "prod-server-42",
+        "NoProxy": "9.81.1.160",
+        "OperatingSystem": "Boot2Docker",
+        "RegistryConfig": {
+            "IndexConfigs": {
+                "docker.io": {
+                    "Mirrors": null,
+                    "Name": "docker.io",
+                    "Official": true,
+                    "Secure": true
+                }
+            },
+            "InsecureRegistryCIDRs": [
+                "127.0.0.0/8"
+            ]
+        },
+        "SwapLimit": 0,
+        "SystemTime": "2015-03-10T11:11:23.730591467-07:00"
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+    GET /v1.18/version HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+         "Version": "1.5.0",
+         "Os": "linux",
+         "KernelVersion": "3.18.5-tinycore64",
+         "GoVersion": "go1.4.1",
+         "GitCommit": "a8a31ef",
+         "Arch": "amd64",
+         "ApiVersion": "1.18"
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+    GET /v1.18/_ping HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: text/plain
+
+    OK
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+    POST /v1.18/commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Hostname": "",
+         "Domainname": "",
+         "User": "",
+         "AttachStdin": false,
+         "AttachStdout": true,
+         "AttachStderr": true,
+         "PortSpecs": null,
+         "Tty": false,
+         "OpenStdin": false,
+         "StdinOnce": false,
+         "Env": null,
+         "Cmd": [
+                 "date"
+         ],
+         "Volumes": {
+                 "/tmp": {}
+         },
+         "WorkingDir": "",
+         "NetworkDisabled": false,
+         "ExposedPorts": {
+                 "22/tcp": {}
+         }
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {"Id": "596069db4bf5"}
+
+**JSON parameters**:
+
+-  **config** - the container's configuration
+
+**Query parameters**:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, in real time via streaming.
+
+Docker containers report the following events:
+
+    create, destroy, die, exec_create, exec_start, export, kill, oom, pause, restart, start, stop, unpause
+
+Docker images report the following events:
+
+    untag, delete
+
+**Example request**:
+
+    GET /v1.18/events?since=1374067924
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "create", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+    {"status": "start", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+    {"status": "stop", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067966}
+    {"status": "destroy", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067970}
+
+**Query parameters**:
+
+-   **since** – Timestamp. Show all events created since timestamp and then stream
+-   **until** – Timestamp. Show events created until given timestamp and stop streaming
+-   **filters** – A json encoded value of the filters (a map[string][]string) to process on the event list. Available filters:
+  -   `container=<string>`; -- container to filter
+  -   `event=<string>`; -- event to filter
+  -   `image=<string>`; -- image to filter
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository specified
+by `name`.
+
+If `name` is a specific name and tag (e.g. ubuntu:latest), then only that image
+(and its parents) are returned. If `name` is an image ID, similarly only that
+image (and its parents) are returned, but with the exclusion of the
+'repositories' file in the tarball, as there were no image names referenced.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.18/images/ubuntu/get
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images
+
+`GET /images/get`
+
+Get a tarball containing all images and metadata for one or more repositories.
+
+For each value of the `names` parameter: if it is a specific name and tag (e.g.
+`ubuntu:latest`), then only that image (and its parents) are returned; if it is
+an image ID, similarly only that image (and its parents) are returned and there
+would be no names referenced in the 'repositories' file for this image ID.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.18/images/get?names=myname%2Fmyapp%3Alatest&names=busybox
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into a Docker repository.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    POST /v1.18/images/load
+    Content-Type: application/x-tar
+    Content-Length: 12345
+
+    Tarball in body
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing these files:
+
+- `VERSION`: currently `1.0` - the file format version
+- `json`: detailed layer information, similar to `docker inspect layer_id`
+- `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file contains `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, the tarball should also include a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+#### Exec Create
+
+`POST /containers/(id or name)/exec`
+
+Sets up an exec instance in a running container `id`
+
+**Example request**:
+
+    POST /v1.18/containers/e90e34656806/exec HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+      "AttachStdin": true,
+      "AttachStdout": true,
+      "AttachStderr": true,
+      "Cmd": ["sh"],
+      "Tty": true
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {
+         "Id": "f90e34656806",
+         "Warnings":[]
+    }
+
+**JSON parameters**:
+
+-   **AttachStdin** - Boolean value, attaches to `stdin` of the `exec` command.
+-   **AttachStdout** - Boolean value, attaches to `stdout` of the `exec` command.
+-   **AttachStderr** - Boolean value, attaches to `stderr` of the `exec` command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+-   **Cmd** - Command to run specified as a string or an array of strings.
+
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+
+#### Exec Start
+
+`POST /exec/(id)/start`
+
+Starts a previously set up `exec` instance `id`. If `detach` is true, this API
+returns after starting the `exec` command. Otherwise, this API sets up an
+interactive session with the `exec` command.
+
+**Example request**:
+
+    POST /v1.18/exec/e90e34656806/start HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+     "Detach": false,
+     "Tty": false
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/vnd.docker.raw-stream
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**JSON parameters**:
+
+-   **Detach** - Detach from the `exec` command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+
+**Stream details**:
+
+Similar to the stream behavior of `POST /containers/(id or name)/attach` API
+
+#### Exec Resize
+
+`POST /exec/(id)/resize`
+
+Resizes the `tty` session used by the `exec` command `id`.  The unit is number of characters.
+This API is valid only if `tty` was specified as part of creating and starting the `exec` command.
+
+**Example request**:
+
+    POST /v1.18/exec/e90e34656806/resize?h=40&w=80 HTTP/1.1
+    Content-Type: text/plain
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: text/plain
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such exec instance
+
+#### Exec Inspect
+
+`GET /exec/(id)/json`
+
+Return low-level information about the `exec` command `id`.
+
+**Example request**:
+
+    GET /v1.18/exec/11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: plain/text
+
+    {
+      "ID" : "11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39",
+      "Running" : false,
+      "ExitCode" : 2,
+      "ProcessConfig" : {
+        "privileged" : false,
+        "user" : "",
+        "tty" : false,
+        "entrypoint" : "sh",
+        "arguments" : [
+          "-c",
+          "exit 2"
+        ]
+      },
+      "OpenStdin" : false,
+      "OpenStderr" : false,
+      "OpenStdout" : false,
+      "Container" : {
+        "State" : {
+          "Running" : true,
+          "Paused" : false,
+          "Restarting" : false,
+          "OOMKilled" : false,
+          "Pid" : 3650,
+          "ExitCode" : 0,
+          "Error" : "",
+          "StartedAt" : "2014-11-17T22:26:03.717657531Z",
+          "FinishedAt" : "0001-01-01T00:00:00Z"
+        },
+        "ID" : "8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c",
+        "Created" : "2014-11-17T22:26:03.626304998Z",
+        "Path" : "date",
+        "Args" : [],
+        "Config" : {
+          "Hostname" : "8f177a186b97",
+          "Domainname" : "",
+          "User" : "",
+          "AttachStdin" : false,
+          "AttachStdout" : false,
+          "AttachStderr" : false,
+          "PortSpecs": null,
+          "ExposedPorts" : null,
+          "Tty" : false,
+          "OpenStdin" : false,
+          "StdinOnce" : false,
+          "Env" : [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ],
+          "Cmd" : [
+            "date"
+          ],
+          "Image" : "ubuntu",
+          "Volumes" : null,
+          "WorkingDir" : "",
+          "Entrypoint" : null,
+          "NetworkDisabled" : false,
+          "MacAddress" : "",
+          "OnBuild" : null,
+          "SecurityOpt" : null
+        },
+        "Image" : "5506de2b643be1e6febbf3b8a240760c6843244c41e12aa2f60ccbb7153d17f5",
+        "NetworkSettings" : {
+          "IPAddress" : "172.17.0.2",
+          "IPPrefixLen" : 16,
+          "MacAddress" : "02:42:ac:11:00:02",
+          "Gateway" : "172.17.42.1",
+          "Bridge" : "docker0",
+          "PortMapping" : null,
+          "Ports" : {}
+        },
+        "ResolvConfPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/resolv.conf",
+        "HostnamePath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hostname",
+        "HostsPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hosts",
+        "LogPath": "/var/lib/docker/containers/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b-json.log",
+        "Name" : "/test",
+        "Driver" : "aufs",
+        "ExecDriver" : "native-0.2",
+        "MountLabel" : "",
+        "ProcessLabel" : "",
+        "AppArmorProfile" : "",
+        "RestartCount" : 0,
+        "Volumes" : {},
+        "VolumesRW" : {}
+      }
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+-   **500** - server error
+
+## 3. Going further
+
+### 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it.
+    - Then, retry to create the container.
+
+- Start the container.
+
+- If you are not in detached mode:
+- Attach to the container, using `logs=1` (to have `stdout` and
+      `stderr` from the container's start) and `stream=1`
+
+- If in detached mode or only `stdin` is attached, display the container's id.
+
+### 3.2 Hijacking
+
+In this version of the API, `/attach`, uses hijacking to transport `stdin`,
+`stdout`, and `stderr` on the same socket.
+
+To hint potential proxies about connection hijacking, Docker client sends
+connection upgrade headers similarly to websocket.
+
+    Upgrade: tcp
+    Connection: Upgrade
+
+When Docker daemon detects the `Upgrade` header, it switches its status code
+from **200 OK** to **101 UPGRADED** and resends the same headers.
+
+This might change in the future.
+
+### 3.3 CORS Requests
+
+To set cross origin requests to the Engine API please give values to
+`--api-cors-header` when running Docker in daemon mode. Set * (asterisk) allows all,
+default or blank means CORS disabled
+
+    $ docker -d -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.19.md b/_vendor/github.com/moby/moby/api/docs/v1.19.md
new file mode 100644
index 000000000000..8523f548066d
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.19.md
@@ -0,0 +1,2253 @@
+---
+title: "Engine API v1.19"
+description: "API Documentation for Docker"
+keywords: "API, Docker, rcli, REST, documentation"
+aliases:
+- /engine/reference/api/docker_remote_api_v1.19/
+- /reference/api/docker_remote_api_v1.19/
+---
+
+<!-- This file is maintained within the moby/moby GitHub
+     repository at https://github.com/moby/moby/. Make all
+     pull requests against that repo. If you see this file in
+     another repository, consider it read-only there, as it will
+     periodically be overwritten by the definitive file. Pull
+     requests which include edits to this file in other repositories
+     will be rejected.
+-->
+
+## 1. Brief introduction
+
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](https://docs.docker.com/engine/reference/commandline/dockerd/#bind-docker-to-another-host-port-or-a-unix-socket).
+ - The API tends to be REST. However, for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `stdout`,
+   `stdin` and `stderr`.
+ - A `Content-Length` header should be present in `POST` requests to endpoints
+   that expect a body.
+ - To lock to a specific version of the API, you prefix the URL with the version
+   of the API to use. For example, `/v1.18/info`. If no version is included in
+   the URL, the maximum supported API version is used.
+ - If the API version specified in the URL is not supported by the daemon, a HTTP
+   `400 Bad Request` error message is returned.
+
+## 2. Endpoints
+
+### 2.1 Containers
+
+#### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+    GET /v1.19/containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Id": "8dfafdbc3a40",
+                 "Names":["/boring_feynman"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 1",
+                 "Created": 1367854155,
+                 "Status": "Exit 0",
+                 "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                 "Labels": {
+                         "com.example.vendor": "Acme",
+                         "com.example.license": "GPL",
+                         "com.example.version": "1.0"
+                 },
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         },
+         {
+                 "Id": "9cd87474be90",
+                 "Names":["/coolName"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 222222",
+                 "Created": 1367854155,
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         },
+         {
+                 "Id": "3176a2479c92",
+                 "Names":["/sleepy_dog"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 3333333333333333",
+                 "Created": 1367854154,
+                 "Status": "Exit 0",
+                 "Ports":[],
+                 "Labels": {},
+                 "SizeRw":12288,
+                 "SizeRootFs":0
+         },
+         {
+                 "Id": "4cb07b47f9fb",
+                 "Names":["/running_cat"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 444444444444444444444444444444444",
+                 "Created": 1367854152,
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         }
+    ]
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers
+        sizes
+-   **filters** - a JSON encoded value of the filters (a `map[string][]string`) to process on the containers list. Available filters:
+  -   `exited=<int>`; -- containers with exit code of  `<int>` ;
+  -   `status=`(`restarting`|`running`|`paused`|`exited`)
+  -   `label=key` or `label="key=value"` of a container label
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+#### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+    POST /v1.19/containers/create HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+           "Hostname": "",
+           "Domainname": "",
+           "User": "",
+           "AttachStdin": false,
+           "AttachStdout": true,
+           "AttachStderr": true,
+           "Tty": false,
+           "OpenStdin": false,
+           "StdinOnce": false,
+           "Env": [
+                   "FOO=bar",
+                   "BAZ=quux"
+           ],
+           "Cmd": [
+                   "date"
+           ],
+           "Entrypoint": null,
+           "Image": "ubuntu",
+           "Labels": {
+                   "com.example.vendor": "Acme",
+                   "com.example.license": "GPL",
+                   "com.example.version": "1.0"
+           },
+           "Volumes": {
+             "/volumes/data": {}
+           },
+           "WorkingDir": "",
+           "NetworkDisabled": false,
+           "MacAddress": "12:34:56:78:9a:bc",
+           "ExposedPorts": {
+                   "22/tcp": {}
+           },
+           "HostConfig": {
+             "Binds": ["/tmp:/tmp"],
+             "Links": ["redis3:redis"],
+             "LxcConf": {"lxc.utsname":"docker"},
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "CpuPeriod": 100000,
+             "CpuQuota": 50000,
+             "CpusetCpus": "0,1",
+             "CpusetMems": "0,1",
+             "BlkioWeight": 300,
+             "OomKillDisable": false,
+             "PidMode": "",
+             "PortBindings": { "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts": false,
+             "Privileged": false,
+             "ReadonlyRootfs": false,
+             "Dns": ["8.8.8.8"],
+             "DnsSearch": [""],
+             "ExtraHosts": null,
+             "VolumesFrom": ["parent", "other:ro"],
+             "CapAdd": ["NET_ADMIN"],
+             "CapDrop": ["MKNOD"],
+             "RestartPolicy": { "Name": "", "MaximumRetryCount": 0 },
+             "NetworkMode": "bridge",
+             "Devices": [],
+             "Ulimits": [{}],
+             "LogConfig": { "Type": "json-file", "Config": {} },
+             "SecurityOpt": [],
+             "CgroupParent": ""
+          }
+      }
+
+**Example response**:
+
+      HTTP/1.1 201 Created
+      Content-Type: application/json
+
+      {
+           "Id":"e90e34656806",
+           "Warnings":[]
+      }
+
+**JSON parameters**:
+
+-   **Hostname** - A string value containing the hostname to use for the
+      container.
+-   **Domainname** - A string value containing the domain name to use
+      for the container.
+-   **User** - A string value specifying the user inside the container.
+-   **AttachStdin** - Boolean value, attaches to `stdin`.
+-   **AttachStdout** - Boolean value, attaches to `stdout`.
+-   **AttachStderr** - Boolean value, attaches to `stderr`.
+-   **Tty** - Boolean value, Attach standard streams to a `tty`, including `stdin` if it is not closed.
+-   **OpenStdin** - Boolean value, opens `stdin`,
+-   **StdinOnce** - Boolean value, close `stdin` after the 1 attached client disconnects.
+-   **Env** - A list of environment variables in the form of `["VAR=value", ...]`
+-   **Labels** - Adds a map of labels to a container. To specify a map: `{"key":"value", ... }`
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Entrypoint** - Set the entry point for the container as a string or an array
+      of strings.
+-   **Image** - A string specifying the image name to use for the container.
+-   **Volumes** - An object mapping mount point paths (strings) inside the
+      container to empty objects.
+-   **WorkingDir** - A string specifying the working directory for commands to
+      run in.
+-   **NetworkDisabled** - Boolean value, when true disables networking for the
+      container
+-   **ExposedPorts** - An object mapping ports to an empty object in the form of:
+      `"ExposedPorts": { "<port>/<tcp|udp>: {}" }`
+-   **HostConfig**
+    -   **Binds** – A list of bind mounts for this container. Each item is a string in one of these forms:
+           + `host-src:container-dest` to bind-mount a host path into the
+             container. Both `host-src`, and `container-dest` must be an
+             _absolute_ path.
+           + `host-src:container-dest:ro` to make the bind mount read-only
+             inside the container. Both `host-src`, and `container-dest` must be
+             an _absolute_ path.
+    -   **Links** - A list of links for the container. Each link entry should be
+          in the form of `container_name:alias`.
+    -   **LxcConf** - LXC specific configurations. These configurations only
+          work when using the `lxc` execution driver.
+    -   **Memory** - Memory limit in bytes.
+    -   **MemorySwap** - Total memory limit (memory + swap); set `-1` to enable unlimited swap.
+          You must use this with `memory` and make the swap value larger than `memory`.
+    -   **CpuShares** - An integer value containing the container's CPU Shares
+          (ie. the relative weight vs other containers).
+    -   **CpuPeriod** - The length of a CPU period in microseconds.
+    -   **CpuQuota** - Microseconds of CPU time that the container can get in a CPU period.
+    -   **CpusetCpus** - String value containing the `cgroups CpusetCpus` to use.
+    -   **CpusetMems** - Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
+    -   **BlkioWeight** - Block IO weight (relative weight) accepts a weight value between 10 and 1000.
+    -   **OomKillDisable** - Boolean value, whether to disable OOM Killer for the container or not.
+    -   **PidMode** - Set the PID (Process) Namespace mode for the container;
+          `"container:<name|id>"`: joins another container's PID namespace
+          `"host"`: use the host's PID namespace inside the container
+    -   **PortBindings** - A map of exposed container ports and the host port they
+          should map to. A JSON object in the form
+          `{ <port>/<protocol>: [{ "HostPort": "<port>" }] }`
+          Take note that `port` is specified as a string and not an integer value.
+    -   **PublishAllPorts** - Allocates an ephemeral host port for all of a container's
+          exposed ports. Specified as a boolean value.
+
+          Ports are de-allocated when the container stops and allocated when the container starts.
+          The allocated port might be changed when restarting the container.
+
+          The port is selected from the ephemeral port range that depends on the kernel.
+          For example, on Linux the range is defined by `/proc/sys/net/ipv4/ip_local_port_range`.
+    -   **Privileged** - Gives the container full access to the host. Specified as
+          a boolean value.
+    -   **ReadonlyRootfs** - Mount the container's root filesystem as read only.
+          Specified as a boolean value.
+    -   **Dns** - A list of DNS servers for the container to use.
+    -   **DnsSearch** - A list of DNS search domains
+    -   **ExtraHosts** - A list of hostnames/IP mappings to add to the
+        container's `/etc/hosts` file. Specified in the form `["hostname:IP"]`.
+    -   **VolumesFrom** - A list of volumes to inherit from another container.
+          Specified in the form `<container name>[:<ro|rw>]`
+    -   **CapAdd** - A list of kernel capabilities to add to the container.
+    -   **Capdrop** - A list of kernel capabilities to drop from the container.
+    -   **RestartPolicy** – The behavior to apply when the container exits.  The
+            value is an object with a `Name` property of either `"always"` to
+            always restart or `"on-failure"` to restart only when the container
+            exit code is non-zero.  If `on-failure` is used, `MaximumRetryCount`
+            controls the number of times to retry before giving up.
+            The default is not to restart. (optional)
+            An ever increasing delay (double the previous delay, starting at 100mS)
+            is added before each restart to prevent flooding the server.
+    -   **NetworkMode** - Sets the networking mode for the container. Supported
+          values are: `bridge`, `host`, `none`, and `container:<name|id>`
+    -   **Devices** - A list of devices to add to the container specified as a JSON object in the
+      form
+          `{ "PathOnHost": "/dev/deviceName", "PathInContainer": "/dev/deviceName", "CgroupPermissions": "mrw"}`
+    -   **Ulimits** - A list of ulimits to set in the container, specified as
+          `{ "Name": <name>, "Soft": <soft limit>, "Hard": <hard limit> }`, for example:
+          `Ulimits: { "Name": "nofile", "Soft": 1024, "Hard": 2048 }`
+    -   **SecurityOpt**: A list of string values to customize labels for MLS
+        systems, such as SELinux.
+    -   **LogConfig** - Log configuration for the container, specified as a JSON object in the form
+          `{ "Type": "<driver_name>", "Config": {"key1": "val1"}}`.
+          Available types: `json-file`, `syslog`, `journald`, `none`.
+          `syslog` available options are: `address`.
+    -   **CgroupParent** - Path to `cgroups` under which the container's `cgroup` is created. If the path is not absolute, the path is considered to be relative to the `cgroups` path of the init process. Cgroups are created if they do not already exist.
+
+**Query parameters**:
+
+-   **name** – Assign the specified name to the container. Must
+    match `/?[a-zA-Z0-9_-]+`.
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **406** – impossible to attach (container not running)
+-   **409** – conflict
+-   **500** – server error
+
+#### Inspect a container
+
+`GET /containers/(id or name)/json`
+
+Return low-level information on the container `id`
+
+**Example request**:
+
+      GET /v1.19/containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+	{
+		"AppArmorProfile": "",
+		"Args": [
+			"-c",
+			"exit 9"
+		],
+		"Config": {
+			"AttachStderr": true,
+			"AttachStdin": false,
+			"AttachStdout": true,
+			"Cmd": [
+				"/bin/sh",
+				"-c",
+				"exit 9"
+			],
+			"Domainname": "",
+			"Entrypoint": null,
+			"Env": [
+				"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+			],
+			"ExposedPorts": null,
+			"Hostname": "ba033ac44011",
+			"Image": "ubuntu",
+			"Labels": {
+				"com.example.vendor": "Acme",
+				"com.example.license": "GPL",
+				"com.example.version": "1.0"
+			},
+			"MacAddress": "",
+			"NetworkDisabled": false,
+			"OnBuild": null,
+			"OpenStdin": false,
+			"PortSpecs": null,
+			"StdinOnce": false,
+			"Tty": false,
+			"User": "",
+			"Volumes": null,
+			"WorkingDir": ""
+		},
+		"Created": "2015-01-06T15:47:31.485331387Z",
+		"Driver": "overlay2",
+		"ExecDriver": "native-0.2",
+		"ExecIDs": null,
+		"HostConfig": {
+			"Binds": null,
+			"BlkioWeight": 0,
+			"CapAdd": null,
+			"CapDrop": null,
+			"ContainerIDFile": "",
+			"CpusetCpus": "",
+			"CpusetMems": "",
+			"CpuShares": 0,
+			"CpuPeriod": 100000,
+			"Devices": [],
+			"Dns": null,
+			"DnsSearch": null,
+			"ExtraHosts": null,
+			"IpcMode": "",
+			"Links": null,
+			"LxcConf": [],
+			"Memory": 0,
+			"MemorySwap": 0,
+			"OomKillDisable": false,
+			"NetworkMode": "bridge",
+			"PidMode": "",
+			"PortBindings": {},
+			"Privileged": false,
+			"ReadonlyRootfs": false,
+			"PublishAllPorts": false,
+			"RestartPolicy": {
+				"MaximumRetryCount": 2,
+				"Name": "on-failure"
+			},
+			"LogConfig": {
+				"Config": null,
+				"Type": "json-file"
+			},
+			"SecurityOpt": null,
+			"VolumesFrom": null,
+			"Ulimits": [{}]
+		},
+		"HostnamePath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hostname",
+		"HostsPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hosts",
+		"LogPath": "/var/lib/docker/containers/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b-json.log",
+		"Id": "ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39",
+		"Image": "04c5d3b7b0656168630d3ba35d8889bd0e9caafcaeb3004d2bfbc47e7c5d35d2",
+		"MountLabel": "",
+		"Name": "/boring_euclid",
+		"NetworkSettings": {
+			"Bridge": "",
+			"Gateway": "",
+			"IPAddress": "",
+			"IPPrefixLen": 0,
+			"MacAddress": "",
+			"PortMapping": null,
+			"Ports": null
+		},
+		"Path": "/bin/sh",
+		"ProcessLabel": "",
+		"ResolvConfPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/resolv.conf",
+		"RestartCount": 1,
+		"State": {
+			"Error": "",
+			"ExitCode": 9,
+			"FinishedAt": "2015-01-06T15:47:32.080254511Z",
+			"OOMKilled": false,
+			"Paused": false,
+			"Pid": 0,
+			"Restarting": false,
+			"Running": true,
+			"StartedAt": "2015-01-06T15:47:32.072697474Z"
+		},
+		"Volumes": {},
+		"VolumesRW": {}
+	}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### List processes running inside a container
+
+`GET /containers/(id or name)/top`
+
+List processes running inside the container `id`. On Unix systems this
+is done by running the `ps` command. This endpoint is not
+supported on Windows.
+
+**Example request**:
+
+    GET /v1.19/containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Titles" : [
+         "UID", "PID", "PPID", "C", "STIME", "TTY", "TIME", "CMD"
+       ],
+       "Processes" : [
+         [
+           "root", "13642", "882", "0", "17:03", "pts/0", "00:00:00", "/bin/bash"
+         ],
+         [
+           "root", "13735", "13642", "0", "17:06", "pts/0", "00:00:00", "sleep 10"
+         ]
+       ]
+    }
+
+**Example request**:
+
+    GET /v1.19/containers/4fa6e0f0c678/top?ps_args=aux HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Titles" : [
+        "USER","PID","%CPU","%MEM","VSZ","RSS","TTY","STAT","START","TIME","COMMAND"
+      ]
+      "Processes" : [
+        [
+          "root","13642","0.0","0.1","18172","3184","pts/0","Ss","17:03","0:00","/bin/bash"
+        ],
+        [
+          "root","13895","0.0","0.0","4348","692","pts/0","S+","17:15","0:00","sleep 10"
+        ]
+      ],
+    }
+
+**Query parameters**:
+
+-   **ps_args** – `ps` arguments to use (e.g., `aux`), defaults to `-ef`
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container logs
+
+`GET /containers/(id or name)/logs`
+
+Get `stdout` and `stderr` logs from the container ``id``
+
+> **Note**:
+> This endpoint works only for containers with the `json-file` or `journald` logging drivers.
+
+**Example request**:
+
+     GET /v1.19/containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10&since=1428990821 HTTP/1.1
+
+**Example response**:
+
+     HTTP/1.1 101 UPGRADED
+     Content-Type: application/vnd.docker.raw-stream
+     Connection: Upgrade
+     Upgrade: tcp
+
+     {% raw %}
+     {{ STREAM }}
+     {% endraw %}
+
+**Query parameters**:
+
+-   **follow** – 1/True/true or 0/False/false, return stream. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, show `stdout` log. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, show `stderr` log. Default `false`.
+-   **since** – UNIX timestamp (integer) to filter logs. Specifying a timestamp
+    will only output log-entries since that timestamp. Default: 0 (unfiltered)
+-   **timestamps** – 1/True/true or 0/False/false, print timestamps for
+        every log line. Default `false`.
+-   **tail** – Output specified number of lines at the end of logs: `all` or `<number>`. Default all.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **404** – no such container
+-   **500** – server error
+
+#### Inspect changes on a container's filesystem
+
+`GET /containers/(id or name)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+    GET /v1.19/containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Path": "/dev",
+                 "Kind": 0
+         },
+         {
+                 "Path": "/dev/kmsg",
+                 "Kind": 1
+         },
+         {
+                 "Path": "/test",
+                 "Kind": 1
+         }
+    ]
+
+Values for `Kind`:
+
+- `0`: Modify
+- `1`: Add
+- `2`: Delete
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Export a container
+
+`GET /containers/(id or name)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+    GET /v1.19/containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/octet-stream
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container stats based on resource usage
+
+`GET /containers/(id or name)/stats`
+
+This endpoint returns a live stream of a container's resource usage statistics.
+
+**Example request**:
+
+    GET /v1.19/containers/redis1/stats HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Type: application/json
+
+      {
+         "read" : "2015-01-08T22:57:31.547920715Z",
+         "network" : {
+            "rx_dropped" : 0,
+            "rx_bytes" : 648,
+            "rx_errors" : 0,
+            "tx_packets" : 8,
+            "tx_dropped" : 0,
+            "rx_packets" : 8,
+            "tx_errors" : 0,
+            "tx_bytes" : 648
+         },
+         "memory_stats" : {
+            "stats" : {
+               "total_pgmajfault" : 0,
+               "cache" : 0,
+               "mapped_file" : 0,
+               "total_inactive_file" : 0,
+               "pgpgout" : 414,
+               "rss" : 6537216,
+               "total_mapped_file" : 0,
+               "writeback" : 0,
+               "unevictable" : 0,
+               "pgpgin" : 477,
+               "total_unevictable" : 0,
+               "pgmajfault" : 0,
+               "total_rss" : 6537216,
+               "total_rss_huge" : 6291456,
+               "total_writeback" : 0,
+               "total_inactive_anon" : 0,
+               "rss_huge" : 6291456,
+               "hierarchical_memory_limit" : 67108864,
+               "total_pgfault" : 964,
+               "total_active_file" : 0,
+               "active_anon" : 6537216,
+               "total_active_anon" : 6537216,
+               "total_pgpgout" : 414,
+               "total_cache" : 0,
+               "inactive_anon" : 0,
+               "active_file" : 0,
+               "pgfault" : 964,
+               "inactive_file" : 0,
+               "total_pgpgin" : 477
+            },
+            "max_usage" : 6651904,
+            "usage" : 6537216,
+            "failcnt" : 0,
+            "limit" : 67108864
+         },
+         "blkio_stats" : {},
+         "cpu_stats" : {
+            "cpu_usage" : {
+               "percpu_usage" : [
+                  8646879,
+                  24472255,
+                  36438778,
+                  30657443
+               ],
+               "usage_in_usermode" : 50000000,
+               "total_usage" : 100215355,
+               "usage_in_kernelmode" : 30000000
+            },
+            "system_cpu_usage" : 739306590000000,
+            "throttling_data" : {"periods":0,"throttled_periods":0,"throttled_time":0}
+         },
+         "precpu_stats" : {
+            "cpu_usage" : {
+               "percpu_usage" : [
+                  8646879,
+                  24350896,
+                  36438778,
+                  30657443
+               ],
+               "usage_in_usermode" : 50000000,
+               "total_usage" : 100093996,
+               "usage_in_kernelmode" : 30000000
+            },
+            "system_cpu_usage" : 9492140000000,
+            "throttling_data" : {"periods":0,"throttled_periods":0,"throttled_time":0}
+         }
+      }
+
+The `precpu_stats` is the cpu statistic of *previous* read, which is used for calculating the cpu usage percent. It is not the exact copy of the `cpu_stats` field.
+
+**Query parameters**:
+
+-   **stream** – 1/True/true or 0/False/false, pull stats once then disconnect. Default `true`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Resize a container TTY
+
+`POST /containers/(id or name)/resize?h=<height>&w=<width>`
+
+Resize the TTY for container with  `id`. You must restart the container for the resize to take effect.
+
+**Example request**:
+
+      POST /v1.19/containers/4fa6e0f0c678/resize?h=40&w=80 HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Length: 0
+      Content-Type: text/plain; charset=utf-8
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – No such container
+-   **500** – Cannot resize container
+
+#### Start a container
+
+`POST /containers/(id or name)/start`
+
+Start the container `id`
+
+> **Note**:
+> For backwards compatibility, this endpoint accepts a `HostConfig` as JSON-encoded request body.
+> See [create a container](#create-a-container) for details.
+
+**Example request**:
+
+    POST /v1.19/containers/e90e34656806/start HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already started
+-   **404** – no such container
+-   **500** – server error
+
+#### Stop a container
+
+`POST /containers/(id or name)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+    POST /v1.19/containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already stopped
+-   **404** – no such container
+-   **500** – server error
+
+#### Restart a container
+
+`POST /containers/(id or name)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+    POST /v1.19/containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Kill a container
+
+`POST /containers/(id or name)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+    POST /v1.19/containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **signal** - Signal to send to the container: integer or string like `SIGINT`.
+        When not set, `SIGKILL` is assumed and the call waits for the container to exit.
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Rename a container
+
+`POST /containers/(id or name)/rename`
+
+Rename the container `id` to a `new_name`
+
+**Example request**:
+
+    POST /v1.19/containers/e90e34656806/rename?name=new_name HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **name** – new name for the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **409** - conflict name already assigned
+-   **500** – server error
+
+#### Pause a container
+
+`POST /containers/(id or name)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+    POST /v1.19/containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Unpause a container
+
+`POST /containers/(id or name)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+    POST /v1.19/containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Attach to a container
+
+`POST /containers/(id or name)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+    POST /v1.19/containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 101 UPGRADED
+    Content-Type: application/vnd.docker.raw-stream
+    Connection: Upgrade
+    Upgrade: tcp
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+-   **stdin** – 1/True/true or 0/False/false, if `stream=true`, attach
+        to `stdin`. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stdout` log, if `stream=true`, attach to `stdout`. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stderr` log, if `stream=true`, attach to `stderr`. Default `false`.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+**Stream details**:
+
+When using the TTY setting is enabled in
+[`POST /containers/create`
+](#create-a-container),
+the stream is the raw data from the process PTY and client's `stdin`.
+When the TTY is disabled, then the stream is multiplexed to separate
+`stdout` and `stderr`.
+
+The format is a **Header** and a **Payload** (frame).
+
+**HEADER**
+
+The header contains the information which the stream writes (`stdout` or
+`stderr`). It also contains the size of the associated frame encoded in the
+last four bytes (`uint32`).
+
+It is encoded on the first eight bytes like this:
+
+    header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+`STREAM_TYPE` can be:
+
+-   0: `stdin` (is written on `stdout`)
+-   1: `stdout`
+-   2: `stderr`
+
+`SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of
+the `uint32` size encoded as big endian.
+
+**PAYLOAD**
+
+The payload is the raw stream.
+
+**IMPLEMENTATION**
+
+The simplest way to implement the Attach protocol is the following:
+
+    1.  Read eight bytes.
+    2.  Choose `stdout` or `stderr` depending on the first byte.
+    3.  Extract the frame size from the last four bytes.
+    4.  Read the extracted size and output it on the correct output.
+    5.  Goto 1.
+
+#### Attach to a container (websocket)
+
+`GET /containers/(id or name)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+    GET /v1.19/containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+#### Wait a container
+
+`POST /containers/(id or name)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+    POST /v1.19/containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"StatusCode": 0}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Remove a container
+
+`DELETE /containers/(id or name)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.19/containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default `false`.
+-   **force** - 1/True/true or 0/False/false, Kill then remove the container.
+        Default `false`.
+-   **link** - 1/True/true or 0/False/false, Remove the specified
+        link associated to the container. Default `false`.
+
+**Status codes**:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **409** – conflict
+-   **500** – server error
+
+#### Copy files or folders from a container
+
+`POST /containers/(id or name)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+    POST /v1.19/containers/4fa6e0f0c678/copy HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Resource": "test.txt"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### 2.2 Images
+
+#### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+    GET /v1.19/images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+         "RepoTags": [
+           "ubuntu:12.04",
+           "ubuntu:precise",
+           "ubuntu:latest"
+         ],
+         "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+         "Created": 1365714795,
+         "Size": 131506275,
+         "VirtualSize": 131506275,
+         "Labels": {}
+      },
+      {
+         "RepoTags": [
+           "ubuntu:12.10",
+           "ubuntu:quantal"
+         ],
+         "ParentId": "27cf784147099545",
+         "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+         "Created": 1364102658,
+         "Size": 24653,
+         "VirtualSize": 180116135,
+         "Labels": {
+            "com.example.version": "v1"
+         }
+      }
+    ]
+
+**Example request, with digest information**:
+
+    GET /v1.19/images/json?digests=1 HTTP/1.1
+
+**Example response, with digest information**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+        "Created": 1420064636,
+        "Id": "4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125",
+        "ParentId": "ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2",
+        "RepoDigests": [
+          "localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf"
+        ],
+        "RepoTags": [
+          "localhost:5000/test/busybox:latest",
+          "playdate:latest"
+        ],
+        "Size": 0,
+        "VirtualSize": 2429728,
+        "Labels": {}
+      }
+    ]
+
+The response shows a single image `Id` associated with two repositories
+(`RepoTags`): `localhost:5000/test/busybox`: and `playdate`. A caller can use
+either of the `RepoTags` values `localhost:5000/test/busybox:latest` or
+`playdate:latest` to reference the image.
+
+You can also use `RepoDigests` values to reference an image. In this response,
+the array has only one reference and that is to the
+`localhost:5000/test/busybox` repository; the `playdate` repository has no
+digest. You can reference this digest using the value:
+`localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d...`
+
+See the `docker run` and `docker build` commands for examples of digest and tag
+references on the command line.
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a JSON encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   `dangling=true`
+  -   `label=key` or `label="key=value"` of an image label
+-   **filter** - only return images with the specified name
+
+#### Build image from a Dockerfile
+
+`POST /build`
+
+Build an image from a Dockerfile
+
+**Example request**:
+
+    POST /v1.19/build HTTP/1.1
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"stream": "Step 1/5..."}
+    {"stream": "..."}
+    {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+The input stream must be a `tar` archive compressed with one of the
+following algorithms: `identity` (no compression), `gzip`, `bzip2`, `xz`.
+
+The archive must include a build instructions file, typically called
+`Dockerfile` at the archive's root. The `dockerfile` parameter may be
+used to specify a different build instructions file. To do this, its value must be
+the path to the alternate build instructions file to use.
+
+The archive may include any number of other files,
+which are accessible in the build context (See the [*ADD build
+command*](https://docs.docker.com/engine/reference/builder/#add)).
+
+The Docker daemon performs a preliminary validation of the `Dockerfile` before
+starting the build, and returns an error if the syntax is incorrect. After that,
+each instruction is run one-by-one until the ID of the new image is output.
+
+The build is canceled if the client drops the connection by quitting
+or being killed.
+
+**Query parameters**:
+
+-   **dockerfile** - Path within the build context to the Dockerfile. This is
+        ignored if `remote` is specified and points to an individual filename.
+-   **t** – A name and optional tag to apply to the image in the `name:tag` format.
+        If you omit the `tag` the default `latest` value is assumed.
+-   **remote** – A Git repository URI or HTTP/HTTPS URI build source. If the
+        URI specifies a filename, the file's contents are placed into a file
+        called `Dockerfile`.
+-   **q** – Suppress verbose build output.
+-   **nocache** – Do not use the cache when building the image.
+-   **pull** - Attempt to pull the image even if an older image exists locally.
+-   **rm** - Remove intermediate containers after a successful build (default behavior).
+-   **forcerm** - Always remove intermediate containers (includes `rm`).
+-   **memory** - Set memory limit for build.
+-   **memswap** - Total memory (memory + swap), `-1` to enable unlimited swap.
+-   **cpushares** - CPU shares (relative weight).
+-   **cpusetcpus** - CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+-   **cpuperiod** - The length of a CPU period in microseconds.
+-   **cpuquota** - Microseconds of CPU time that the container can get in a CPU period.
+
+**Request Headers**:
+
+-   **Content-type** – Set to `"application/x-tar"`.
+-   **X-Registry-Config** – base64-encoded ConfigFile object
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Create an image
+
+`POST /images/create`
+
+Create an image either by pulling it from the registry or by importing it
+
+**Example request**:
+
+    POST /v1.19/images/create?fromImage=busybox&tag=latest HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pulling..."}
+    {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+    {"error": "Invalid..."}
+    ...
+
+When using this endpoint to pull an image from the registry, the
+`X-Registry-Auth` header can be used to include
+a base64-encoded AuthConfig object.
+
+**Query parameters**:
+
+-   **fromImage** – Name of the image to pull.
+-   **fromSrc** – Source to import.  The value may be a URL from which the image
+        can be retrieved or `-` to read the image from the request body.
+-   **repo** – Repository name.
+-   **tag** – Tag. If empty when pulling an image, this causes all tags
+        for the given image to be pulled.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** - repository does not exist or no read access
+-   **500** – server error
+
+
+
+#### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+    GET /v1.19/images/ubuntu/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Created": "2013-03-23T22:24:18.818426-07:00",
+       "Container": "3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+       "ContainerConfig": {
+          "Hostname": "",
+          "User": "",
+          "AttachStdin": false,
+          "AttachStdout": false,
+          "AttachStderr": false,
+          "Tty": true,
+          "OpenStdin": true,
+          "StdinOnce": false,
+          "Env": null,
+          "Cmd": ["/bin/bash"],
+          "Dns": null,
+          "Image": "ubuntu",
+          "Labels": {
+             "com.example.vendor": "Acme",
+             "com.example.license": "GPL",
+             "com.example.version": "1.0"
+          },
+          "Volumes": null,
+          "VolumesFrom": "",
+          "WorkingDir": ""
+       },
+       "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+       "Parent": "27cf784147099545",
+       "Size": 6824592
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+    GET /v1.19/images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+        {
+            "Id": "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710",
+            "Created": 1398108230,
+            "CreatedBy": "/bin/sh -c #(nop) ADD file:eb15dbd63394e063b805a3c32ca7bf0266ef64676d5a6fab4801f2e81e2a5148 in /",
+            "Tags": [
+                "ubuntu:lucid",
+                "ubuntu:10.04"
+            ],
+            "Size": 182964289,
+            "Comment": ""
+        },
+        {
+            "Id": "6cfa4d1f33fb861d4d114f43b25abd0ac737509268065cdfd69d544a59c85ab8",
+            "Created": 1398108222,
+            "CreatedBy": "/bin/sh -c #(nop) MAINTAINER Tianon Gravi <admwiggin@gmail.com> - mkimage-debootstrap.sh -i iproute,iputils-ping,ubuntu-minimal -t lucid.tar.xz lucid http://archive.ubuntu.com/ubuntu/",
+            "Tags": null,
+            "Size": 0,
+            "Comment": ""
+        },
+        {
+            "Id": "511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158",
+            "Created": 1371157430,
+            "CreatedBy": "",
+            "Tags": [
+                "scratch12:latest",
+                "scratch:latest"
+            ],
+            "Size": 0,
+            "Comment": "Imported from -"
+        }
+    ]
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+    POST /v1.19/images/test/push HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pushing..."}
+    {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+    {"error": "Invalid..."}
+    ...
+
+If you wish to push an image on to a private registry, that image must already have a tag
+into a repository which references that registry `hostname` and `port`.  This repository name should
+then be used in the URL. This duplicates the command line's flow.
+
+**Example request**:
+
+    POST /v1.19/images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+**Query parameters**:
+
+-   **tag** – The tag to associate with the image on the registry. This is optional.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+    POST /v1.19/images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+
+**Query parameters**:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.19/images/test HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-type: application/json
+
+    [
+     {"Untagged": "3e2f21a89f"},
+     {"Deleted": "3e2f21a89f"},
+     {"Deleted": "53b4f83ac9"}
+    ]
+
+**Query parameters**:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com). This API
+returns both `is_trusted` and `is_automated` images. Currently, they
+are considered identical. In the future, the `is_trusted` property will
+be deprecated and replaced by the `is_automated` property.
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+    GET /v1.19/images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+            {
+                "star_count": 12,
+                "is_official": false,
+                "name": "wma55/u1210sshd",
+                "is_trusted": false,
+                "is_automated": false,
+                "description": ""
+            },
+            {
+                "star_count": 10,
+                "is_official": false,
+                "name": "jdswinbank/sshd",
+                "is_trusted": false,
+                "is_automated": false,
+                "description": ""
+            },
+            {
+                "star_count": 18,
+                "is_official": false,
+                "name": "vgauthier/sshd",
+                "is_trusted": false,
+                "is_automated": false,
+                "description": ""
+            }
+    ...
+    ]
+
+**Query parameters**:
+
+-   **term** – term to search
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+### 2.3 Misc
+
+#### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+    POST /v1.19/auth HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "username": "hannibal",
+         "password": "xxxx",
+         "email": "hannibal@a-team.com",
+         "serveraddress": "https://index.docker.io/v1/"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+#### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+    GET /v1.19/info HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+        "Containers": 11,
+        "CpuCfsPeriod": true,
+        "CpuCfsQuota": true,
+        "Debug": false,
+        "DockerRootDir": "/var/lib/docker",
+        "Driver": "btrfs",
+        "DriverStatus": [[""]],
+        "ExecutionDriver": "native-0.1",
+        "ExperimentalBuild": false,
+        "HttpProxy": "http://test:test@localhost:8080",
+        "HttpsProxy": "https://test:test@localhost:8080",
+        "ID": "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS",
+        "IPv4Forwarding": true,
+        "Images": 16,
+        "IndexServerAddress": "https://index.docker.io/v1/",
+        "InitPath": "/usr/bin/docker",
+        "InitSha1": "",
+        "KernelVersion": "3.12.0-1-amd64",
+        "Labels": [
+            "storage=ssd"
+        ],
+        "MemTotal": 2099236864,
+        "MemoryLimit": true,
+        "NCPU": 1,
+        "NEventsListener": 0,
+        "NFd": 11,
+        "NGoroutines": 21,
+        "Name": "prod-server-42",
+        "NoProxy": "9.81.1.160",
+        "OomKillDisable": true,
+        "OperatingSystem": "Boot2Docker",
+        "RegistryConfig": {
+            "IndexConfigs": {
+                "docker.io": {
+                    "Mirrors": null,
+                    "Name": "docker.io",
+                    "Official": true,
+                    "Secure": true
+                }
+            },
+            "InsecureRegistryCIDRs": [
+                "127.0.0.0/8"
+            ]
+        },
+        "SwapLimit": false,
+        "SystemTime": "2015-03-10T11:11:23.730591467-07:00"
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+    GET /v1.19/version HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+         "Version": "1.5.0",
+         "Os": "linux",
+         "KernelVersion": "3.18.5-tinycore64",
+         "GoVersion": "go1.4.1",
+         "GitCommit": "a8a31ef",
+         "Arch": "amd64",
+         "ApiVersion": "1.19"
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+    GET /v1.19/_ping HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: text/plain
+
+    OK
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+    POST /v1.19/commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Hostname": "",
+         "Domainname": "",
+         "User": "",
+         "AttachStdin": false,
+         "AttachStdout": true,
+         "AttachStderr": true,
+         "PortSpecs": null,
+         "Tty": false,
+         "OpenStdin": false,
+         "StdinOnce": false,
+         "Env": null,
+         "Cmd": [
+                 "date"
+         ],
+         "Volumes": {
+                 "/tmp": {}
+         },
+         "Labels": {
+                 "key1": "value1",
+                 "key2": "value2"
+          },
+         "WorkingDir": "",
+         "NetworkDisabled": false,
+         "ExposedPorts": {
+                 "22/tcp": {}
+         }
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {"Id": "596069db4bf5"}
+
+**JSON parameters**:
+
+-  **config** - the container's configuration
+
+**Query parameters**:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, in real time via streaming.
+
+Docker containers report the following events:
+
+    attach, commit, copy, create, destroy, die, exec_create, exec_start, export, kill, oom, pause, rename, resize, restart, start, stop, top, unpause
+
+Docker images report the following events:
+
+    untag, delete
+
+**Example request**:
+
+    GET /v1.19/events?since=1374067924
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "create", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+    {"status": "start", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+    {"status": "stop", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067966}
+    {"status": "destroy", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067970}
+
+**Query parameters**:
+
+-   **since** – Timestamp. Show all events created since timestamp and then stream
+-   **until** – Timestamp. Show events created until given timestamp and stop streaming
+-   **filters** – A json encoded value of the filters (a map[string][]string) to process on the event list. Available filters:
+  -   `container=<string>`; -- container to filter
+  -   `event=<string>`; -- event to filter
+  -   `image=<string>`; -- image to filter
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository specified
+by `name`.
+
+If `name` is a specific name and tag (e.g. ubuntu:latest), then only that image
+(and its parents) are returned. If `name` is an image ID, similarly only that
+image (and its parents) are returned, but with the exclusion of the
+'repositories' file in the tarball, as there were no image names referenced.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.19/images/ubuntu/get
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images
+
+`GET /images/get`
+
+Get a tarball containing all images and metadata for one or more repositories.
+
+For each value of the `names` parameter: if it is a specific name and tag (e.g.
+`ubuntu:latest`), then only that image (and its parents) are returned; if it is
+an image ID, similarly only that image (and its parents) are returned and there
+would be no names referenced in the 'repositories' file for this image ID.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.19/images/get?names=myname%2Fmyapp%3Alatest&names=busybox
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into a Docker repository.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    POST /v1.19/images/load
+    Content-Type: application/x-tar
+    Content-Length: 12345
+
+    Tarball in body
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing these files:
+
+- `VERSION`: currently `1.0` - the file format version
+- `json`: detailed layer information, similar to `docker inspect layer_id`
+- `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file contains `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, the tarball should also include a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+#### Exec Create
+
+`POST /containers/(id or name)/exec`
+
+Sets up an exec instance in a running container `id`
+
+**Example request**:
+
+    POST /v1.19/containers/e90e34656806/exec HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+      "AttachStdin": true,
+      "AttachStdout": true,
+      "AttachStderr": true,
+      "Cmd": ["sh"],
+      "Tty": true,
+      "User": "123:456"
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {
+         "Id": "f90e34656806",
+         "Warnings":[]
+    }
+
+**JSON parameters**:
+
+-   **AttachStdin** - Boolean value, attaches to `stdin` of the `exec` command.
+-   **AttachStdout** - Boolean value, attaches to `stdout` of the `exec` command.
+-   **AttachStderr** - Boolean value, attaches to `stderr` of the `exec` command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **User** - A string value specifying the user, and optionally, group to run
+        the exec process inside the container. Format is one of: `"user"`,
+        `"user:group"`, `"uid"`, or `"uid:gid"`.
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+
+#### Exec Start
+
+`POST /exec/(id)/start`
+
+Starts a previously set up `exec` instance `id`. If `detach` is true, this API
+returns after starting the `exec` command. Otherwise, this API sets up an
+interactive session with the `exec` command.
+
+**Example request**:
+
+    POST /v1.19/exec/e90e34656806/start HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+     "Detach": false,
+     "Tty": false
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/vnd.docker.raw-stream
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**JSON parameters**:
+
+-   **Detach** - Detach from the `exec` command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+
+**Stream details**:
+
+Similar to the stream behavior of `POST /containers/(id or name)/attach` API
+
+#### Exec Resize
+
+`POST /exec/(id)/resize`
+
+Resizes the `tty` session used by the `exec` command `id`.  The unit is number of characters.
+This API is valid only if `tty` was specified as part of creating and starting the `exec` command.
+
+**Example request**:
+
+    POST /v1.19/exec/e90e34656806/resize?h=40&w=80 HTTP/1.1
+    Content-Type: text/plain
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: text/plain
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such exec instance
+
+#### Exec Inspect
+
+`GET /exec/(id)/json`
+
+Return low-level information about the `exec` command `id`.
+
+**Example request**:
+
+    GET /v1.19/exec/11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: plain/text
+
+    {
+      "ID" : "11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39",
+      "Running" : false,
+      "ExitCode" : 2,
+      "ProcessConfig" : {
+        "privileged" : false,
+        "user" : "",
+        "tty" : false,
+        "entrypoint" : "sh",
+        "arguments" : [
+          "-c",
+          "exit 2"
+        ]
+      },
+      "OpenStdin" : false,
+      "OpenStderr" : false,
+      "OpenStdout" : false,
+      "Container" : {
+        "State" : {
+          "Running" : true,
+          "Paused" : false,
+          "Restarting" : false,
+          "OOMKilled" : false,
+          "Pid" : 3650,
+          "ExitCode" : 0,
+          "Error" : "",
+          "StartedAt" : "2014-11-17T22:26:03.717657531Z",
+          "FinishedAt" : "0001-01-01T00:00:00Z"
+        },
+        "ID" : "8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c",
+        "Created" : "2014-11-17T22:26:03.626304998Z",
+        "Path" : "date",
+        "Args" : [],
+        "Config" : {
+          "Hostname" : "8f177a186b97",
+          "Domainname" : "",
+          "User" : "",
+          "AttachStdin" : false,
+          "AttachStdout" : false,
+          "AttachStderr" : false,
+          "PortSpecs": null,
+          "ExposedPorts" : null,
+          "Tty" : false,
+          "OpenStdin" : false,
+          "StdinOnce" : false,
+          "Env" : [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ],
+          "Cmd" : [
+            "date"
+          ],
+          "Image" : "ubuntu",
+          "Volumes" : null,
+          "WorkingDir" : "",
+          "Entrypoint" : null,
+          "NetworkDisabled" : false,
+          "MacAddress" : "",
+          "OnBuild" : null,
+          "SecurityOpt" : null
+        },
+        "Image" : "5506de2b643be1e6febbf3b8a240760c6843244c41e12aa2f60ccbb7153d17f5",
+        "NetworkSettings" : {
+          "IPAddress" : "172.17.0.2",
+          "IPPrefixLen" : 16,
+          "MacAddress" : "02:42:ac:11:00:02",
+          "Gateway" : "172.17.42.1",
+          "Bridge" : "docker0",
+          "PortMapping" : null,
+          "Ports" : {}
+        },
+        "ResolvConfPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/resolv.conf",
+        "HostnamePath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hostname",
+        "HostsPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hosts",
+        "LogPath": "/var/lib/docker/containers/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b-json.log",
+        "Name" : "/test",
+        "Driver" : "aufs",
+        "ExecDriver" : "native-0.2",
+        "MountLabel" : "",
+        "ProcessLabel" : "",
+        "AppArmorProfile" : "",
+        "RestartCount" : 0,
+        "Volumes" : {},
+        "VolumesRW" : {}
+      }
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+-   **500** - server error
+
+## 3. Going further
+
+### 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it.
+    - Then, retry to create the container.
+
+- Start the container.
+
+- If you are not in detached mode:
+- Attach to the container, using `logs=1` (to have `stdout` and
+      `stderr` from the container's start) and `stream=1`
+
+- If in detached mode or only `stdin` is attached, display the container's id.
+
+### 3.2 Hijacking
+
+In this version of the API, `/attach`, uses hijacking to transport `stdin`,
+`stdout`, and `stderr` on the same socket.
+
+To hint potential proxies about connection hijacking, Docker client sends
+connection upgrade headers similarly to websocket.
+
+    Upgrade: tcp
+    Connection: Upgrade
+
+When Docker daemon detects the `Upgrade` header, it switches its status code
+from **200 OK** to **101 UPGRADED** and resends the same headers.
+
+
+### 3.3 CORS Requests
+
+To set cross origin requests to the Engine API please give values to
+`--api-cors-header` when running Docker in daemon mode. Set * (asterisk) allows all,
+default or blank means CORS disabled
+
+    $ docker -d -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.2.md b/_vendor/github.com/moby/moby/api/docs/v1.2.md
new file mode 100644
index 000000000000..678853eae10e
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.2.md
@@ -0,0 +1,1024 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.2"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent = "smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.2
+
+# 1. Brief introduction
+
+- The Remote API is replacing rcli
+- Default port in the docker daemon is 2375
+- The API tends to be REST, but for some complex commands, like attach
+  or pull, the HTTP connection is hijacked to transport stdout stdin
+  and stderr
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "centos:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "fedora:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             }
+        ]
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Dns":null,
+             "Image":"ubuntu",
+             "Volumes":{},
+             "VolumesFrom":""
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "VolumesFrom": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {}
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/start HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/(format)`
+
+List images `format` could be json or viz (json default)
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Repository":"ubuntu",
+                     "Tag":"precise",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658,
+                     "Size":24653,
+                     "VirtualSize":180116135
+             },
+             {
+                     "Repository":"ubuntu",
+                     "Tag":"12.04",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658,
+                     "Size":24653,
+                     "VirtualSize":180116135
+             }
+        ]
+
+**Example request**:
+
+        GET /images/viz HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        digraph docker {
+        "d82cbacda43a" -> "074be284591f"
+        "1496068ca813" -> "08306dc45919"
+        "08306dc45919" -> "0e7893146ac2"
+        "b750fe79269d" -> "1496068ca813"
+        base -> "27cf78414709" [style=invis]
+        "f71189fff3de" -> "9a33b36209ed"
+        "27cf78414709" -> "b750fe79269d"
+        "0e7893146ac2" -> "d6434d954665"
+        "d6434d954665" -> "d82cbacda43a"
+        base -> "e9aa60c60128" [style=invis]
+        "074be284591f" -> "f71189fff3de"
+        "b750fe79269d" [label="b750fe79269d\nubuntu",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "e9aa60c60128" [label="e9aa60c60128\ncentos",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "9a33b36209ed" [label="9a33b36209ed\nfedora",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        base [style=invisible]
+        }
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by defaul
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pulling..."}
+        {"status":"Pulling", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Insert a file in an image
+
+`POST /images/(name)/insert`
+
+Insert a file from `url` in the image `name` at `path`
+
+**Example request**:
+
+        POST /images/test/insert?path=/usr&url=myurl HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Inserting..."}
+        {"status":"Inserting", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-	**url** – The url from where the file is taken
+-	**path** – The path where the file is stored
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/centos/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "parent":"27cf784147099545",
+             "created":"2013-03-23T22:24:18.818426-07:00",
+             "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "container_config":
+                     {
+                             "Hostname":"",
+                             "User":"",
+                             "Memory":0,
+                             "MemorySwap":0,
+                             "AttachStdin":false,
+                             "AttachStdout":false,
+                             "AttachStderr":false,
+                             "PortSpecs":null,
+                             "Tty":true,
+                             "OpenStdin":true,
+                             "StdinOnce":false,
+                             "Env":null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns":null,
+                             "Image":"centos",
+                             "Volumes":null,
+                             "VolumesFrom":""
+                     },
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/fedora/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id":"b750fe79269d",
+                     "Tag":["ubuntu:latest"],
+                     "Created":1364102658,
+                     "CreatedBy":"/bin/bash"
+             },
+             {
+                     "Id":"27cf78414709",
+                     "Created":1364068391,
+                     "CreatedBy":""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+    > **Example request**:
+    >
+    >     POST /images/test/push HTTP/1.1
+    >     {{ authConfig }}
+    >
+    > **Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pushing..."}
+        {"status":"Pushing", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com)
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Name":"cespare/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"johnfuller/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"dhrp/mongodb-sshd",
+                     "Description":""
+             }
+        ]
+
+        :query term: term to search
+        :statuscode 200: no error
+        :statuscode 500: server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **t** – repository name to be applied to the resulting image in
+        case of success
+-   **remote** – resource to fetch, as URI
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+{{ STREAM }} is the raw text output of the build command. It uses the
+HTTP Hijack method in order to stream.
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":"hannibal",
+             "password:"xxxx",
+             "email":"hannibal@a-team.com"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Status": "Login Succeeded"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **401** – unauthorized
+-   **403** – forbidden
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "MemoryLimit":true,
+             "SwapLimit":false
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Version":"0.2.2",
+             "GitCommit":"5a2a5cc+CHANGES",
+             "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+            "Cmd": ["cat", "/world"],
+            "PortSpecs":["22"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+            Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+        <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+Here are the steps of `docker run` :
+
+ - Create the container
+
+ - If the status code is 404, it means the image doesn't exist:
+        - Try to pull it
+        - Then retry to create the container
+
+ - Start the container
+
+ - If you are not in detached mode:
+        - Attach to the container, using logs=1 (to have stdout and
+            stderr from the container's start) and stream=1
+
+ - If in detached mode or only stdin is attached:
+        - Display the container's
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+> docker -d -H="[tcp://192.168.1.9:2375](tcp://192.168.1.9:2375)"
+> -api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.20.md b/_vendor/github.com/moby/moby/api/docs/v1.20.md
new file mode 100644
index 000000000000..55a099f3296c
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.20.md
@@ -0,0 +1,2408 @@
+---
+title: "Engine API v1.20"
+description: "API Documentation for Docker"
+keywords: "API, Docker, rcli, REST, documentation"
+aliases:
+- /engine/reference/api/docker_remote_api_v1.20/
+- /reference/api/docker_remote_api_v1.20/
+---
+
+<!-- This file is maintained within the moby/moby GitHub
+     repository at https://github.com/moby/moby/. Make all
+     pull requests against that repo. If you see this file in
+     another repository, consider it read-only there, as it will
+     periodically be overwritten by the definitive file. Pull
+     requests which include edits to this file in other repositories
+     will be rejected.
+-->
+
+## 1. Brief introduction
+
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](https://docs.docker.com/engine/reference/commandline/dockerd/#bind-docker-to-another-host-port-or-a-unix-socket).
+ - The API tends to be REST. However, for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `stdout`,
+   `stdin` and `stderr`.
+ - A `Content-Length` header should be present in `POST` requests to endpoints
+   that expect a body.
+ - To lock to a specific version of the API, you prefix the URL with the version
+   of the API to use. For example, `/v1.18/info`. If no version is included in
+   the URL, the maximum supported API version is used.
+ - If the API version specified in the URL is not supported by the daemon, a HTTP
+   `400 Bad Request` error message is returned.
+
+## 2. Endpoints
+
+### 2.1 Containers
+
+#### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+    GET /v1.20/containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Id": "8dfafdbc3a40",
+                 "Names":["/boring_feynman"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 1",
+                 "Created": 1367854155,
+                 "Status": "Exit 0",
+                 "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                 "Labels": {
+                         "com.example.vendor": "Acme",
+                         "com.example.license": "GPL",
+                         "com.example.version": "1.0"
+                 },
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         },
+         {
+                 "Id": "9cd87474be90",
+                 "Names":["/coolName"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 222222",
+                 "Created": 1367854155,
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         },
+         {
+                 "Id": "3176a2479c92",
+                 "Names":["/sleepy_dog"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 3333333333333333",
+                 "Created": 1367854154,
+                 "Status": "Exit 0",
+                 "Ports":[],
+                 "Labels": {},
+                 "SizeRw":12288,
+                 "SizeRootFs":0
+         },
+         {
+                 "Id": "4cb07b47f9fb",
+                 "Names":["/running_cat"],
+                 "Image": "ubuntu:latest",
+                 "Command": "echo 444444444444444444444444444444444",
+                 "Created": 1367854152,
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         }
+    ]
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers
+        sizes
+-   **filters** - a JSON encoded value of the filters (a `map[string][]string`) to process on the containers list. Available filters:
+  -   `exited=<int>`; -- containers with exit code of  `<int>` ;
+  -   `status=`(`created`|`restarting`|`running`|`paused`|`exited`)
+  -   `label=key` or `label="key=value"` of a container label
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+#### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+    POST /v1.20/containers/create HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+           "Hostname": "",
+           "Domainname": "",
+           "User": "",
+           "AttachStdin": false,
+           "AttachStdout": true,
+           "AttachStderr": true,
+           "Tty": false,
+           "OpenStdin": false,
+           "StdinOnce": false,
+           "Env": [
+                   "FOO=bar",
+                   "BAZ=quux"
+           ],
+           "Cmd": [
+                   "date"
+           ],
+           "Entrypoint": null,
+           "Image": "ubuntu",
+           "Labels": {
+                   "com.example.vendor": "Acme",
+                   "com.example.license": "GPL",
+                   "com.example.version": "1.0"
+           },
+           "Volumes": {
+             "/volumes/data": {}
+           },
+           "WorkingDir": "",
+           "NetworkDisabled": false,
+           "MacAddress": "12:34:56:78:9a:bc",
+           "ExposedPorts": {
+                   "22/tcp": {}
+           },
+           "HostConfig": {
+             "Binds": ["/tmp:/tmp"],
+             "Links": ["redis3:redis"],
+             "LxcConf": {"lxc.utsname":"docker"},
+             "Memory": 0,
+             "MemorySwap": 0,
+             "CpuShares": 512,
+             "CpuPeriod": 100000,
+             "CpuQuota": 50000,
+             "CpusetCpus": "0,1",
+             "CpusetMems": "0,1",
+             "BlkioWeight": 300,
+             "MemorySwappiness": 60,
+             "OomKillDisable": false,
+             "PidMode": "",
+             "PortBindings": { "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts": false,
+             "Privileged": false,
+             "ReadonlyRootfs": false,
+             "Dns": ["8.8.8.8"],
+             "DnsSearch": [""],
+             "ExtraHosts": null,
+             "VolumesFrom": ["parent", "other:ro"],
+             "CapAdd": ["NET_ADMIN"],
+             "CapDrop": ["MKNOD"],
+             "GroupAdd": ["newgroup"],
+             "RestartPolicy": { "Name": "", "MaximumRetryCount": 0 },
+             "NetworkMode": "bridge",
+             "Devices": [],
+             "Ulimits": [{}],
+             "LogConfig": { "Type": "json-file", "Config": {} },
+             "SecurityOpt": [],
+             "CgroupParent": ""
+          }
+      }
+
+**Example response**:
+
+      HTTP/1.1 201 Created
+      Content-Type: application/json
+
+      {
+           "Id":"e90e34656806",
+           "Warnings":[]
+      }
+
+**JSON parameters**:
+
+-   **Hostname** - A string value containing the hostname to use for the
+      container.
+-   **Domainname** - A string value containing the domain name to use
+      for the container.
+-   **User** - A string value specifying the user inside the container.
+-   **AttachStdin** - Boolean value, attaches to `stdin`.
+-   **AttachStdout** - Boolean value, attaches to `stdout`.
+-   **AttachStderr** - Boolean value, attaches to `stderr`.
+-   **Tty** - Boolean value, Attach standard streams to a `tty`, including `stdin` if it is not closed.
+-   **OpenStdin** - Boolean value, opens `stdin`,
+-   **StdinOnce** - Boolean value, close `stdin` after the 1 attached client disconnects.
+-   **Env** - A list of environment variables in the form of `["VAR=value", ...]`
+-   **Labels** - Adds a map of labels to a container. To specify a map: `{"key":"value", ... }`
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Entrypoint** - Set the entry point for the container as a string or an array
+      of strings.
+-   **Image** - A string specifying the image name to use for the container.
+-   **Volumes** - An object mapping mount point paths (strings) inside the
+      container to empty objects.
+-   **WorkingDir** - A string specifying the working directory for commands to
+      run in.
+-   **NetworkDisabled** - Boolean value, when true disables networking for the
+      container
+-   **ExposedPorts** - An object mapping ports to an empty object in the form of:
+      `"ExposedPorts": { "<port>/<tcp|udp>: {}" }`
+-   **HostConfig**
+    -   **Binds** – A list of bind mounts for this container. Each item is a string in one of these forms:
+           + `host-src:container-dest` to bind-mount a host path into the
+             container. Both `host-src`, and `container-dest` must be an
+             _absolute_ path.
+           + `host-src:container-dest:ro` to make the bind mount read-only
+             inside the container. Both `host-src`, and `container-dest` must be
+             an _absolute_ path.
+    -   **Links** - A list of links for the container. Each link entry should be
+          in the form of `container_name:alias`.
+    -   **LxcConf** - LXC specific configurations. These configurations only
+          work when using the `lxc` execution driver.
+    -   **Memory** - Memory limit in bytes.
+    -   **MemorySwap** - Total memory limit (memory + swap); set `-1` to enable unlimited swap.
+          You must use this with `memory` and make the swap value larger than `memory`.
+    -   **CpuShares** - An integer value containing the container's CPU Shares
+          (ie. the relative weight vs other containers).
+    -   **CpuPeriod** - The length of a CPU period in microseconds.
+    -   **CpuQuota** - Microseconds of CPU time that the container can get in a CPU period.
+    -   **CpusetCpus** - String value containing the `cgroups CpusetCpus` to use.
+    -   **CpusetMems** - Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
+    -   **BlkioWeight** - Block IO weight (relative weight) accepts a weight value between 10 and 1000.
+    -   **MemorySwappiness** - Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100.
+    -   **OomKillDisable** - Boolean value, whether to disable OOM Killer for the container or not.
+    -   **PidMode** - Set the PID (Process) Namespace mode for the container;
+          `"container:<name|id>"`: joins another container's PID namespace
+          `"host"`: use the host's PID namespace inside the container
+    -   **PortBindings** - A map of exposed container ports and the host port they
+          should map to. A JSON object in the form
+          `{ <port>/<protocol>: [{ "HostPort": "<port>" }] }`
+          Take note that `port` is specified as a string and not an integer value.
+    -   **PublishAllPorts** - Allocates an ephemeral host port for all of a container's
+          exposed ports. Specified as a boolean value.
+
+          Ports are de-allocated when the container stops and allocated when the container starts.
+          The allocated port might be changed when restarting the container.
+
+          The port is selected from the ephemeral port range that depends on the kernel.
+          For example, on Linux the range is defined by `/proc/sys/net/ipv4/ip_local_port_range`.
+    -   **Privileged** - Gives the container full access to the host. Specified as
+          a boolean value.
+    -   **ReadonlyRootfs** - Mount the container's root filesystem as read only.
+          Specified as a boolean value.
+    -   **Dns** - A list of DNS servers for the container to use.
+    -   **DnsSearch** - A list of DNS search domains
+    -   **ExtraHosts** - A list of hostnames/IP mappings to add to the
+        container's `/etc/hosts` file. Specified in the form `["hostname:IP"]`.
+    -   **VolumesFrom** - A list of volumes to inherit from another container.
+          Specified in the form `<container name>[:<ro|rw>]`
+    -   **CapAdd** - A list of kernel capabilities to add to the container.
+    -   **Capdrop** - A list of kernel capabilities to drop from the container.
+    -   **GroupAdd** - A list of additional groups that the container process will run as
+    -   **RestartPolicy** – The behavior to apply when the container exits.  The
+            value is an object with a `Name` property of either `"always"` to
+            always restart or `"on-failure"` to restart only when the container
+            exit code is non-zero.  If `on-failure` is used, `MaximumRetryCount`
+            controls the number of times to retry before giving up.
+            The default is not to restart. (optional)
+            An ever increasing delay (double the previous delay, starting at 100mS)
+            is added before each restart to prevent flooding the server.
+    -   **NetworkMode** - Sets the networking mode for the container. Supported
+          values are: `bridge`, `host`, `none`, and `container:<name|id>`
+    -   **Devices** - A list of devices to add to the container specified as a JSON object in the
+      form
+          `{ "PathOnHost": "/dev/deviceName", "PathInContainer": "/dev/deviceName", "CgroupPermissions": "mrw"}`
+    -   **Ulimits** - A list of ulimits to set in the container, specified as
+          `{ "Name": <name>, "Soft": <soft limit>, "Hard": <hard limit> }`, for example:
+          `Ulimits: { "Name": "nofile", "Soft": 1024, "Hard": 2048 }`
+    -   **SecurityOpt**: A list of string values to customize labels for MLS
+        systems, such as SELinux.
+    -   **LogConfig** - Log configuration for the container, specified as a JSON object in the form
+          `{ "Type": "<driver_name>", "Config": {"key1": "val1"}}`.
+          Available types: `json-file`, `syslog`, `journald`, `gelf`, `none`.
+          `json-file` logging driver.
+    -   **CgroupParent** - Path to `cgroups` under which the container's `cgroup` is created. If the path is not absolute, the path is considered to be relative to the `cgroups` path of the init process. Cgroups are created if they do not already exist.
+
+**Query parameters**:
+
+-   **name** – Assign the specified name to the container. Must
+    match `/?[a-zA-Z0-9_-]+`.
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **406** – impossible to attach (container not running)
+-   **409** – conflict
+-   **500** – server error
+
+#### Inspect a container
+
+`GET /containers/(id or name)/json`
+
+Return low-level information on the container `id`
+
+**Example request**:
+
+      GET /v1.20/containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+	{
+		"AppArmorProfile": "",
+		"Args": [
+			"-c",
+			"exit 9"
+		],
+		"Config": {
+			"AttachStderr": true,
+			"AttachStdin": false,
+			"AttachStdout": true,
+			"Cmd": [
+				"/bin/sh",
+				"-c",
+				"exit 9"
+			],
+			"Domainname": "",
+			"Entrypoint": null,
+			"Env": [
+				"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+			],
+			"ExposedPorts": null,
+			"Hostname": "ba033ac44011",
+			"Image": "ubuntu",
+			"Labels": {
+				"com.example.vendor": "Acme",
+				"com.example.license": "GPL",
+				"com.example.version": "1.0"
+			},
+			"MacAddress": "",
+			"NetworkDisabled": false,
+			"OnBuild": null,
+			"OpenStdin": false,
+			"StdinOnce": false,
+			"Tty": false,
+			"User": "",
+			"Volumes": null,
+			"WorkingDir": ""
+		},
+		"Created": "2015-01-06T15:47:31.485331387Z",
+		"Driver": "overlay2",
+		"ExecDriver": "native-0.2",
+		"ExecIDs": null,
+		"HostConfig": {
+			"Binds": null,
+			"BlkioWeight": 0,
+			"CapAdd": null,
+			"CapDrop": null,
+			"ContainerIDFile": "",
+			"CpusetCpus": "",
+			"CpusetMems": "",
+			"CpuShares": 0,
+			"CpuPeriod": 100000,
+			"Devices": [],
+			"Dns": null,
+			"DnsSearch": null,
+			"ExtraHosts": null,
+			"IpcMode": "",
+			"Links": null,
+			"LxcConf": [],
+			"Memory": 0,
+			"MemorySwap": 0,
+			"OomKillDisable": false,
+			"NetworkMode": "bridge",
+			"PidMode": "",
+			"PortBindings": {},
+			"Privileged": false,
+			"ReadonlyRootfs": false,
+			"PublishAllPorts": false,
+			"RestartPolicy": {
+				"MaximumRetryCount": 2,
+				"Name": "on-failure"
+			},
+			"LogConfig": {
+				"Config": null,
+				"Type": "json-file"
+			},
+			"SecurityOpt": null,
+			"VolumesFrom": null,
+			"Ulimits": [{}]
+		},
+		"HostnamePath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hostname",
+		"HostsPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hosts",
+		"LogPath": "/var/lib/docker/containers/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b-json.log",
+		"Id": "ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39",
+		"Image": "04c5d3b7b0656168630d3ba35d8889bd0e9caafcaeb3004d2bfbc47e7c5d35d2",
+		"MountLabel": "",
+		"Name": "/boring_euclid",
+		"NetworkSettings": {
+			"Bridge": "",
+			"Gateway": "",
+			"IPAddress": "",
+			"IPPrefixLen": 0,
+			"MacAddress": "",
+			"PortMapping": null,
+			"Ports": null
+		},
+		"Path": "/bin/sh",
+		"ProcessLabel": "",
+		"ResolvConfPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/resolv.conf",
+		"RestartCount": 1,
+		"State": {
+			"Error": "",
+			"ExitCode": 9,
+			"FinishedAt": "2015-01-06T15:47:32.080254511Z",
+			"OOMKilled": false,
+			"Paused": false,
+			"Pid": 0,
+			"Restarting": false,
+			"Running": true,
+			"StartedAt": "2015-01-06T15:47:32.072697474Z"
+		},
+		"Mounts": [
+			{
+				"Source": "/data",
+				"Destination": "/data",
+				"Mode": "ro,Z",
+				"RW": false
+			}
+		]
+	}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### List processes running inside a container
+
+`GET /containers/(id or name)/top`
+
+List processes running inside the container `id`. On Unix systems this
+is done by running the `ps` command. This endpoint is not
+supported on Windows.
+
+**Example request**:
+
+    GET /v1.20/containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Titles" : [
+         "UID", "PID", "PPID", "C", "STIME", "TTY", "TIME", "CMD"
+       ],
+       "Processes" : [
+         [
+           "root", "13642", "882", "0", "17:03", "pts/0", "00:00:00", "/bin/bash"
+         ],
+         [
+           "root", "13735", "13642", "0", "17:06", "pts/0", "00:00:00", "sleep 10"
+         ]
+       ]
+    }
+
+**Example request**:
+
+    GET /v1.20/containers/4fa6e0f0c678/top?ps_args=aux HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Titles" : [
+        "USER","PID","%CPU","%MEM","VSZ","RSS","TTY","STAT","START","TIME","COMMAND"
+      ]
+      "Processes" : [
+        [
+          "root","13642","0.0","0.1","18172","3184","pts/0","Ss","17:03","0:00","/bin/bash"
+        ],
+        [
+          "root","13895","0.0","0.0","4348","692","pts/0","S+","17:15","0:00","sleep 10"
+        ]
+      ],
+    }
+
+**Query parameters**:
+
+-   **ps_args** – `ps` arguments to use (e.g., `aux`), defaults to `-ef`
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container logs
+
+`GET /containers/(id or name)/logs`
+
+Get `stdout` and `stderr` logs from the container ``id``
+
+> **Note**:
+> This endpoint works only for containers with the `json-file` or `journald` logging drivers.
+
+**Example request**:
+
+     GET /v1.20/containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10&since=1428990821 HTTP/1.1
+
+**Example response**:
+
+     HTTP/1.1 101 UPGRADED
+     Content-Type: application/vnd.docker.raw-stream
+     Connection: Upgrade
+     Upgrade: tcp
+
+     {% raw %}
+     {{ STREAM }}
+     {% endraw %}
+
+**Query parameters**:
+
+-   **follow** – 1/True/true or 0/False/false, return stream. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, show `stdout` log. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, show `stderr` log. Default `false`.
+-   **since** – UNIX timestamp (integer) to filter logs. Specifying a timestamp
+    will only output log-entries since that timestamp. Default: 0 (unfiltered)
+-   **timestamps** – 1/True/true or 0/False/false, print timestamps for
+        every log line. Default `false`.
+-   **tail** – Output specified number of lines at the end of logs: `all` or `<number>`. Default all.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **404** – no such container
+-   **500** – server error
+
+#### Inspect changes on a container's filesystem
+
+`GET /containers/(id or name)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+    GET /v1.20/containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Path": "/dev",
+                 "Kind": 0
+         },
+         {
+                 "Path": "/dev/kmsg",
+                 "Kind": 1
+         },
+         {
+                 "Path": "/test",
+                 "Kind": 1
+         }
+    ]
+
+Values for `Kind`:
+
+- `0`: Modify
+- `1`: Add
+- `2`: Delete
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Export a container
+
+`GET /containers/(id or name)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+    GET /v1.20/containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/octet-stream
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container stats based on resource usage
+
+`GET /containers/(id or name)/stats`
+
+This endpoint returns a live stream of a container's resource usage statistics.
+
+**Example request**:
+
+    GET /v1.20/containers/redis1/stats HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Type: application/json
+
+      {
+         "read" : "2015-01-08T22:57:31.547920715Z",
+         "network" : {
+            "rx_dropped" : 0,
+            "rx_bytes" : 648,
+            "rx_errors" : 0,
+            "tx_packets" : 8,
+            "tx_dropped" : 0,
+            "rx_packets" : 8,
+            "tx_errors" : 0,
+            "tx_bytes" : 648
+         },
+         "memory_stats" : {
+            "stats" : {
+               "total_pgmajfault" : 0,
+               "cache" : 0,
+               "mapped_file" : 0,
+               "total_inactive_file" : 0,
+               "pgpgout" : 414,
+               "rss" : 6537216,
+               "total_mapped_file" : 0,
+               "writeback" : 0,
+               "unevictable" : 0,
+               "pgpgin" : 477,
+               "total_unevictable" : 0,
+               "pgmajfault" : 0,
+               "total_rss" : 6537216,
+               "total_rss_huge" : 6291456,
+               "total_writeback" : 0,
+               "total_inactive_anon" : 0,
+               "rss_huge" : 6291456,
+               "hierarchical_memory_limit" : 67108864,
+               "total_pgfault" : 964,
+               "total_active_file" : 0,
+               "active_anon" : 6537216,
+               "total_active_anon" : 6537216,
+               "total_pgpgout" : 414,
+               "total_cache" : 0,
+               "inactive_anon" : 0,
+               "active_file" : 0,
+               "pgfault" : 964,
+               "inactive_file" : 0,
+               "total_pgpgin" : 477
+            },
+            "max_usage" : 6651904,
+            "usage" : 6537216,
+            "failcnt" : 0,
+            "limit" : 67108864
+         },
+         "blkio_stats" : {},
+         "cpu_stats" : {
+            "cpu_usage" : {
+               "percpu_usage" : [
+                  8646879,
+                  24472255,
+                  36438778,
+                  30657443
+               ],
+               "usage_in_usermode" : 50000000,
+               "total_usage" : 100215355,
+               "usage_in_kernelmode" : 30000000
+            },
+            "system_cpu_usage" : 739306590000000,
+            "throttling_data" : {"periods":0,"throttled_periods":0,"throttled_time":0}
+         },
+         "precpu_stats" : {
+            "cpu_usage" : {
+               "percpu_usage" : [
+                  8646879,
+                  24350896,
+                  36438778,
+                  30657443
+               ],
+               "usage_in_usermode" : 50000000,
+               "total_usage" : 100093996,
+               "usage_in_kernelmode" : 30000000
+            },
+            "system_cpu_usage" : 9492140000000,
+            "throttling_data" : {"periods":0,"throttled_periods":0,"throttled_time":0}
+         }
+      }
+
+The `precpu_stats` is the cpu statistic of *previous* read, which is used for calculating the cpu usage percent. It is not the exact copy of the `cpu_stats` field.
+
+**Query parameters**:
+
+-   **stream** – 1/True/true or 0/False/false, pull stats once then disconnect. Default `true`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Resize a container TTY
+
+`POST /containers/(id or name)/resize?h=<height>&w=<width>`
+
+Resize the TTY for container with  `id`. You must restart the container for the resize to take effect.
+
+**Example request**:
+
+      POST /v1.20/containers/4fa6e0f0c678/resize?h=40&w=80 HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Length: 0
+      Content-Type: text/plain; charset=utf-8
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – No such container
+-   **500** – Cannot resize container
+
+#### Start a container
+
+`POST /containers/(id or name)/start`
+
+Start the container `id`
+
+> **Note**:
+> For backwards compatibility, this endpoint accepts a `HostConfig` as JSON-encoded request body.
+> See [create a container](#create-a-container) for details.
+
+**Example request**:
+
+    POST /v1.20/containers/e90e34656806/start HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already started
+-   **404** – no such container
+-   **500** – server error
+
+#### Stop a container
+
+`POST /containers/(id or name)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+    POST /v1.20/containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already stopped
+-   **404** – no such container
+-   **500** – server error
+
+#### Restart a container
+
+`POST /containers/(id or name)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+    POST /v1.20/containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Kill a container
+
+`POST /containers/(id or name)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+    POST /v1.20/containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **signal** - Signal to send to the container: integer or string like `SIGINT`.
+        When not set, `SIGKILL` is assumed and the call waits for the container to exit.
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Rename a container
+
+`POST /containers/(id or name)/rename`
+
+Rename the container `id` to a `new_name`
+
+**Example request**:
+
+    POST /v1.20/containers/e90e34656806/rename?name=new_name HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **name** – new name for the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **409** - conflict name already assigned
+-   **500** – server error
+
+#### Pause a container
+
+`POST /containers/(id or name)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+    POST /v1.20/containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Unpause a container
+
+`POST /containers/(id or name)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+    POST /v1.20/containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Attach to a container
+
+`POST /containers/(id or name)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+    POST /v1.20/containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 101 UPGRADED
+    Content-Type: application/vnd.docker.raw-stream
+    Connection: Upgrade
+    Upgrade: tcp
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+-   **stdin** – 1/True/true or 0/False/false, if `stream=true`, attach
+        to `stdin`. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stdout` log, if `stream=true`, attach to `stdout`. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stderr` log, if `stream=true`, attach to `stderr`. Default `false`.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+**Stream details**:
+
+When using the TTY setting is enabled in
+[`POST /containers/create`
+](#create-a-container),
+the stream is the raw data from the process PTY and client's `stdin`.
+When the TTY is disabled, then the stream is multiplexed to separate
+`stdout` and `stderr`.
+
+The format is a **Header** and a **Payload** (frame).
+
+**HEADER**
+
+The header contains the information which the stream writes (`stdout` or
+`stderr`). It also contains the size of the associated frame encoded in the
+last four bytes (`uint32`).
+
+It is encoded on the first eight bytes like this:
+
+    header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+`STREAM_TYPE` can be:
+
+-   0: `stdin` (is written on `stdout`)
+-   1: `stdout`
+-   2: `stderr`
+
+`SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of
+the `uint32` size encoded as big endian.
+
+**PAYLOAD**
+
+The payload is the raw stream.
+
+**IMPLEMENTATION**
+
+The simplest way to implement the Attach protocol is the following:
+
+    1.  Read eight bytes.
+    2.  Choose `stdout` or `stderr` depending on the first byte.
+    3.  Extract the frame size from the last four bytes.
+    4.  Read the extracted size and output it on the correct output.
+    5.  Goto 1.
+
+#### Attach to a container (websocket)
+
+`GET /containers/(id or name)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+    GET /v1.20/containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+#### Wait a container
+
+`POST /containers/(id or name)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+    POST /v1.20/containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"StatusCode": 0}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Remove a container
+
+`DELETE /containers/(id or name)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.20/containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default `false`.
+-   **force** - 1/True/true or 0/False/false, Kill then remove the container.
+        Default `false`.
+-   **link** - 1/True/true or 0/False/false, Remove the specified
+        link associated to the container. Default `false`.
+
+**Status codes**:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **409** – conflict
+-   **500** – server error
+
+#### Copy files or folders from a container
+
+`POST /containers/(id or name)/copy`
+
+Copy files or folders of container `id`
+
+**Deprecated** in favor of the `archive` endpoint below.
+
+**Example request**:
+
+    POST /v1.20/containers/4fa6e0f0c678/copy HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Resource": "test.txt"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Retrieving information about files and folders in a container
+
+`HEAD /containers/(id or name)/archive`
+
+See the description of the `X-Docker-Container-Path-Stat` header in the
+following section.
+
+#### Get an archive of a filesystem resource in a container
+
+`GET /containers/(id or name)/archive`
+
+Get a tar archive of a resource in the filesystem of container `id`.
+
+**Query parameters**:
+
+- **path** - resource in the container's filesystem to archive. Required.
+
+    If not an absolute path, it is relative to the container's root directory.
+    The resource specified by **path** must exist. To assert that the resource
+    is expected to be a directory, **path** should end in `/` or  `/.`
+    (assuming a path separator of `/`). If **path** ends in `/.` then this
+    indicates that only the contents of the **path** directory should be
+    copied. A symlink is always resolved to its target.
+
+    > **Note**: It is not possible to copy certain system files such as resources
+    > under `/proc`, `/sys`, `/dev`, and mounts created by the user in the
+    > container.
+
+**Example request**:
+
+    GET /v1.20/containers/8cce319429b2/archive?path=/root HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+    X-Docker-Container-Path-Stat: eyJuYW1lIjoicm9vdCIsInNpemUiOjQwOTYsIm1vZGUiOjIxNDc0ODQwOTYsIm10aW1lIjoiMjAxNC0wMi0yN1QyMDo1MToyM1oiLCJsaW5rVGFyZ2V0IjoiIn0=
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+On success, a response header `X-Docker-Container-Path-Stat` will be set to a
+base64-encoded JSON object containing some filesystem header information about
+the archived resource. The above example value would decode to the following
+JSON object (whitespace added for readability):
+
+```json
+{
+    "name": "root",
+    "size": 4096,
+    "mode": 2147484096,
+    "mtime": "2014-02-27T20:51:23Z",
+    "linkTarget": ""
+}
+```
+
+A `HEAD` request can also be made to this endpoint if only this information is
+desired.
+
+**Status codes**:
+
+- **200** - success, returns archive of copied resource
+- **400** - client error, bad parameter, details in JSON response body, one of:
+    - must specify path parameter (**path** cannot be empty)
+    - not a directory (**path** was asserted to be a directory but exists as a
+      file)
+- **404** - client error, resource not found, one of:
+    – no such container (container `id` does not exist)
+    - no such file or directory (**path** does not exist)
+- **500** - server error
+
+#### Extract an archive of files or folders to a directory in a container
+
+`PUT /containers/(id or name)/archive`
+
+Upload a tar archive to be extracted to a path in the filesystem of container
+`id`.
+
+**Query parameters**:
+
+- **path** - path to a directory in the container
+    to extract the archive's contents into. Required.
+
+    If not an absolute path, it is relative to the container's root directory.
+    The **path** resource must exist.
+- **noOverwriteDirNonDir** - If "1", "true", or "True" then it will be an error
+    if unpacking the given content would cause an existing directory to be
+    replaced with a non-directory and vice versa.
+
+**Example request**:
+
+    PUT /v1.20/containers/8cce319429b2/archive?path=/vol1 HTTP/1.1
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+- **200** – the content was extracted successfully
+- **400** - client error, bad parameter, details in JSON response body, one of:
+    - must specify path parameter (**path** cannot be empty)
+    - not a directory (**path** should be a directory but exists as a file)
+    - unable to overwrite existing directory with non-directory
+      (if **noOverwriteDirNonDir**)
+    - unable to overwrite existing non-directory with directory
+      (if **noOverwriteDirNonDir**)
+- **403** - client error, permission denied, the volume
+    or container rootfs is marked as read-only.
+- **404** - client error, resource not found, one of:
+    – no such container (container `id` does not exist)
+    - no such file or directory (**path** resource does not exist)
+- **500** – server error
+
+### 2.2 Images
+
+#### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+    GET /v1.20/images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+         "RepoTags": [
+           "ubuntu:12.04",
+           "ubuntu:precise",
+           "ubuntu:latest"
+         ],
+         "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+         "Created": 1365714795,
+         "Size": 131506275,
+         "VirtualSize": 131506275,
+         "Labels": {}
+      },
+      {
+         "RepoTags": [
+           "ubuntu:12.10",
+           "ubuntu:quantal"
+         ],
+         "ParentId": "27cf784147099545",
+         "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+         "Created": 1364102658,
+         "Size": 24653,
+         "VirtualSize": 180116135,
+         "Labels": {
+            "com.example.version": "v1"
+         }
+      }
+    ]
+
+**Example request, with digest information**:
+
+    GET /v1.20/images/json?digests=1 HTTP/1.1
+
+**Example response, with digest information**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+        "Created": 1420064636,
+        "Id": "4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125",
+        "ParentId": "ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2",
+        "RepoDigests": [
+          "localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf"
+        ],
+        "RepoTags": [
+          "localhost:5000/test/busybox:latest",
+          "playdate:latest"
+        ],
+        "Size": 0,
+        "VirtualSize": 2429728,
+        "Labels": {}
+      }
+    ]
+
+The response shows a single image `Id` associated with two repositories
+(`RepoTags`): `localhost:5000/test/busybox`: and `playdate`. A caller can use
+either of the `RepoTags` values `localhost:5000/test/busybox:latest` or
+`playdate:latest` to reference the image.
+
+You can also use `RepoDigests` values to reference an image. In this response,
+the array has only one reference and that is to the
+`localhost:5000/test/busybox` repository; the `playdate` repository has no
+digest. You can reference this digest using the value:
+`localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d...`
+
+See the `docker run` and `docker build` commands for examples of digest and tag
+references on the command line.
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a JSON encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   `dangling=true`
+  -   `label=key` or `label="key=value"` of an image label
+-   **filter** - only return images with the specified name
+
+#### Build image from a Dockerfile
+
+`POST /build`
+
+Build an image from a Dockerfile
+
+**Example request**:
+
+    POST /v1.20/build HTTP/1.1
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"stream": "Step 1/5..."}
+    {"stream": "..."}
+    {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+The input stream must be a `tar` archive compressed with one of the
+following algorithms: `identity` (no compression), `gzip`, `bzip2`, `xz`.
+
+The archive must include a build instructions file, typically called
+`Dockerfile` at the archive's root. The `dockerfile` parameter may be
+used to specify a different build instructions file. To do this, its value must be
+the path to the alternate build instructions file to use.
+
+The archive may include any number of other files,
+which are accessible in the build context (See the [*ADD build
+command*](https://docs.docker.com/engine/reference/builder/#add)).
+
+The Docker daemon performs a preliminary validation of the `Dockerfile` before
+starting the build, and returns an error if the syntax is incorrect. After that,
+each instruction is run one-by-one until the ID of the new image is output.
+
+The build is canceled if the client drops the connection by quitting
+or being killed.
+
+**Query parameters**:
+
+-   **dockerfile** - Path within the build context to the `Dockerfile`. This is
+        ignored if `remote` is specified and points to an external `Dockerfile`.
+-   **t** – A name and optional tag to apply to the image in the `name:tag` format.
+        If you omit the `tag` the default `latest` value is assumed.
+-   **remote** – A Git repository URI or HTTP/HTTPS context URI. If the
+        URI points to a single text file, the file's contents are placed into
+        a file called `Dockerfile` and the image is built from that file. If
+        the URI points to a tarball, the file is downloaded by the daemon and
+        the contents therein used as the context for the build. If the URI
+        points to a tarball and the `dockerfile` parameter is also specified,
+        there must be a file with the corresponding path inside the tarball.
+-   **q** – Suppress verbose build output.
+-   **nocache** – Do not use the cache when building the image.
+-   **pull** - Attempt to pull the image even if an older image exists locally.
+-   **rm** - Remove intermediate containers after a successful build (default behavior).
+-   **forcerm** - Always remove intermediate containers (includes `rm`).
+-   **memory** - Set memory limit for build.
+-   **memswap** - Total memory (memory + swap), `-1` to enable unlimited swap.
+-   **cpushares** - CPU shares (relative weight).
+-   **cpusetcpus** - CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+-   **cpuperiod** - The length of a CPU period in microseconds.
+-   **cpuquota** - Microseconds of CPU time that the container can get in a CPU period.
+
+**Request Headers**:
+
+-   **Content-type** – Set to `"application/x-tar"`.
+-   **X-Registry-Config** – A base64-url-safe-encoded Registry Auth Config JSON
+        object with the following structure:
+
+            {
+                "docker.example.com": {
+                    "username": "janedoe",
+                    "password": "hunter2"
+                },
+                "https://index.docker.io/v1/": {
+                    "username": "mobydock",
+                    "password": "conta1n3rize14"
+                }
+            }
+
+    This object maps the hostname of a registry to an object containing the
+    "username" and "password" for that registry. Multiple registries may
+    be specified as the build may be based on an image requiring
+    authentication to pull from any arbitrary registry. Only the registry
+    domain name (and port if not the default "443") are required. However
+    (for legacy reasons) the "official" Docker, Inc. hosted registry must
+    be specified with both a "https://" prefix and a "/v1/" suffix even
+    though Docker will prefer to use the v2 registry API.
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Create an image
+
+`POST /images/create`
+
+Create an image either by pulling it from the registry or by importing it
+
+**Example request**:
+
+    POST /v1.20/images/create?fromImage=busybox&tag=latest HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pulling..."}
+    {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+    {"error": "Invalid..."}
+    ...
+
+When using this endpoint to pull an image from the registry, the
+`X-Registry-Auth` header can be used to include
+a base64-encoded AuthConfig object.
+
+**Query parameters**:
+
+-   **fromImage** – Name of the image to pull.
+-   **fromSrc** – Source to import.  The value may be a URL from which the image
+        can be retrieved or `-` to read the image from the request body.
+-   **repo** – Repository name.
+-   **tag** – Tag. If empty when pulling an image, this causes all tags
+        for the given image to be pulled.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** - repository does not exist or no read access
+-   **500** – server error
+
+
+
+#### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+    GET /v1.20/images/ubuntu/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Created": "2013-03-23T22:24:18.818426-07:00",
+       "Container": "3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+       "ContainerConfig": {
+          "Hostname": "",
+          "User": "",
+          "AttachStdin": false,
+          "AttachStdout": false,
+          "AttachStderr": false,
+          "Tty": true,
+          "OpenStdin": true,
+          "StdinOnce": false,
+          "Env": null,
+          "Cmd": ["/bin/bash"],
+          "Dns": null,
+          "Image": "ubuntu",
+          "Labels": {
+             "com.example.vendor": "Acme",
+             "com.example.license": "GPL",
+             "com.example.version": "1.0"
+          },
+          "Volumes": null,
+          "VolumesFrom": "",
+          "WorkingDir": ""
+       },
+       "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+       "Parent": "27cf784147099545",
+       "Size": 6824592
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+    GET /v1.20/images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+        {
+            "Id": "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710",
+            "Created": 1398108230,
+            "CreatedBy": "/bin/sh -c #(nop) ADD file:eb15dbd63394e063b805a3c32ca7bf0266ef64676d5a6fab4801f2e81e2a5148 in /",
+            "Tags": [
+                "ubuntu:lucid",
+                "ubuntu:10.04"
+            ],
+            "Size": 182964289,
+            "Comment": ""
+        },
+        {
+            "Id": "6cfa4d1f33fb861d4d114f43b25abd0ac737509268065cdfd69d544a59c85ab8",
+            "Created": 1398108222,
+            "CreatedBy": "/bin/sh -c #(nop) MAINTAINER Tianon Gravi <admwiggin@gmail.com> - mkimage-debootstrap.sh -i iproute,iputils-ping,ubuntu-minimal -t lucid.tar.xz lucid http://archive.ubuntu.com/ubuntu/",
+            "Tags": null,
+            "Size": 0,
+            "Comment": ""
+        },
+        {
+            "Id": "511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158",
+            "Created": 1371157430,
+            "CreatedBy": "",
+            "Tags": [
+                "scratch12:latest",
+                "scratch:latest"
+            ],
+            "Size": 0,
+            "Comment": "Imported from -"
+        }
+    ]
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+    POST /v1.20/images/test/push HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pushing..."}
+    {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+    {"error": "Invalid..."}
+    ...
+
+If you wish to push an image on to a private registry, that image must already have a tag
+into a repository which references that registry `hostname` and `port`.  This repository name should
+then be used in the URL. This duplicates the command line's flow.
+
+**Example request**:
+
+    POST /v1.20/images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+**Query parameters**:
+
+-   **tag** – The tag to associate with the image on the registry. This is optional.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+    POST /v1.20/images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+
+**Query parameters**:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.20/images/test HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-type: application/json
+
+    [
+     {"Untagged": "3e2f21a89f"},
+     {"Deleted": "3e2f21a89f"},
+     {"Deleted": "53b4f83ac9"}
+    ]
+
+**Query parameters**:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+    GET /v1.20/images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "wma55/u1210sshd",
+                "star_count": 0
+            },
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "jdswinbank/sshd",
+                "star_count": 0
+            },
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "vgauthier/sshd",
+                "star_count": 0
+            }
+    ...
+    ]
+
+**Query parameters**:
+
+-   **term** – term to search
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+### 2.3 Misc
+
+#### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+    POST /v1.20/auth HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "username": "hannibal",
+         "password": "xxxx",
+         "email": "hannibal@a-team.com",
+         "serveraddress": "https://index.docker.io/v1/"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+#### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+    GET /v1.20/info HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+        "Containers": 11,
+        "CpuCfsPeriod": true,
+        "CpuCfsQuota": true,
+        "Debug": false,
+        "DockerRootDir": "/var/lib/docker",
+        "Driver": "btrfs",
+        "DriverStatus": [[""]],
+        "ExecutionDriver": "native-0.1",
+        "ExperimentalBuild": false,
+        "HttpProxy": "http://test:test@localhost:8080",
+        "HttpsProxy": "https://test:test@localhost:8080",
+        "ID": "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS",
+        "IPv4Forwarding": true,
+        "Images": 16,
+        "IndexServerAddress": "https://index.docker.io/v1/",
+        "InitPath": "/usr/bin/docker",
+        "InitSha1": "",
+        "KernelVersion": "3.12.0-1-amd64",
+        "Labels": [
+            "storage=ssd"
+        ],
+        "MemTotal": 2099236864,
+        "MemoryLimit": true,
+        "NCPU": 1,
+        "NEventsListener": 0,
+        "NFd": 11,
+        "NGoroutines": 21,
+        "Name": "prod-server-42",
+        "NoProxy": "9.81.1.160",
+        "OomKillDisable": true,
+        "OperatingSystem": "Boot2Docker",
+        "RegistryConfig": {
+            "IndexConfigs": {
+                "docker.io": {
+                    "Mirrors": null,
+                    "Name": "docker.io",
+                    "Official": true,
+                    "Secure": true
+                }
+            },
+            "InsecureRegistryCIDRs": [
+                "127.0.0.0/8"
+            ]
+        },
+        "SwapLimit": false,
+        "SystemTime": "2015-03-10T11:11:23.730591467-07:00"
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+    GET /v1.20/version HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+         "Version": "1.5.0",
+         "Os": "linux",
+         "KernelVersion": "3.18.5-tinycore64",
+         "GoVersion": "go1.4.1",
+         "GitCommit": "a8a31ef",
+         "Arch": "amd64",
+         "ApiVersion": "1.20",
+         "Experimental": false
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+    GET /v1.20/_ping HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: text/plain
+
+    OK
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+    POST /v1.20/commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Hostname": "",
+         "Domainname": "",
+         "User": "",
+         "AttachStdin": false,
+         "AttachStdout": true,
+         "AttachStderr": true,
+         "Tty": false,
+         "OpenStdin": false,
+         "StdinOnce": false,
+         "Env": null,
+         "Cmd": [
+                 "date"
+         ],
+         "Mounts": [
+           {
+             "Source": "/data",
+             "Destination": "/data",
+             "Mode": "ro,Z",
+             "RW": false
+           }
+         ],
+         "Labels": {
+                 "key1": "value1",
+                 "key2": "value2"
+          },
+         "WorkingDir": "",
+         "NetworkDisabled": false,
+         "ExposedPorts": {
+                 "22/tcp": {}
+         }
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {"Id": "596069db4bf5"}
+
+**JSON parameters**:
+
+-  **config** - the container's configuration
+
+**Query parameters**:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+-   **pause** – 1/True/true or 0/False/false, whether to pause the container before committing
+-   **changes** – Dockerfile instructions to apply while committing
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, in real time via streaming.
+
+Docker containers report the following events:
+
+    attach, commit, copy, create, destroy, die, exec_create, exec_start, export, kill, oom, pause, rename, resize, restart, start, stop, top, unpause
+
+Docker images report the following events:
+
+    delete, import, pull, push, tag, untag
+
+**Example request**:
+
+    GET /v1.20/events?since=1374067924
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "create", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+    {"status": "start", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067924}
+    {"status": "stop", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067966}
+    {"status": "destroy", "id": "dfdf82bd3881","from": "ubuntu:latest", "time":1374067970}
+
+**Query parameters**:
+
+-   **since** – Timestamp. Show all events created since timestamp and then stream
+-   **until** – Timestamp. Show events created until given timestamp and stop streaming
+-   **filters** – A json encoded value of the filters (a map[string][]string) to process on the event list. Available filters:
+  -   `container=<string>`; -- container to filter
+  -   `event=<string>`; -- event to filter
+  -   `image=<string>`; -- image to filter
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository specified
+by `name`.
+
+If `name` is a specific name and tag (e.g. ubuntu:latest), then only that image
+(and its parents) are returned. If `name` is an image ID, similarly only that
+image (and its parents) are returned, but with the exclusion of the
+'repositories' file in the tarball, as there were no image names referenced.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.20/images/ubuntu/get
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images
+
+`GET /images/get`
+
+Get a tarball containing all images and metadata for one or more repositories.
+
+For each value of the `names` parameter: if it is a specific name and tag (e.g.
+`ubuntu:latest`), then only that image (and its parents) are returned; if it is
+an image ID, similarly only that image (and its parents) are returned and there
+would be no names referenced in the 'repositories' file for this image ID.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.20/images/get?names=myname%2Fmyapp%3Alatest&names=busybox
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into a Docker repository.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    POST /v1.20/images/load
+    Content-Type: application/x-tar
+    Content-Length: 12345
+
+    Tarball in body
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing these files:
+
+- `VERSION`: currently `1.0` - the file format version
+- `json`: detailed layer information, similar to `docker inspect layer_id`
+- `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file contains `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, the tarball should also include a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+#### Exec Create
+
+`POST /containers/(id or name)/exec`
+
+Sets up an exec instance in a running container `id`
+
+**Example request**:
+
+    POST /v1.20/containers/e90e34656806/exec HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+      "AttachStdin": true,
+      "AttachStdout": true,
+      "AttachStderr": true,
+      "Cmd": ["sh"],
+      "Tty": true,
+      "User": "123:456"
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {
+         "Id": "f90e34656806",
+         "Warnings":[]
+    }
+
+**JSON parameters**:
+
+-   **AttachStdin** - Boolean value, attaches to `stdin` of the `exec` command.
+-   **AttachStdout** - Boolean value, attaches to `stdout` of the `exec` command.
+-   **AttachStderr** - Boolean value, attaches to `stderr` of the `exec` command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **User** - A string value specifying the user, and optionally, group to run
+        the exec process inside the container. Format is one of: `"user"`,
+        `"user:group"`, `"uid"`, or `"uid:gid"`.
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+
+#### Exec Start
+
+`POST /exec/(id)/start`
+
+Starts a previously set up `exec` instance `id`. If `detach` is true, this API
+returns after starting the `exec` command. Otherwise, this API sets up an
+interactive session with the `exec` command.
+
+**Example request**:
+
+    POST /v1.20/exec/e90e34656806/start HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+     "Detach": false,
+     "Tty": false
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/vnd.docker.raw-stream
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**JSON parameters**:
+
+-   **Detach** - Detach from the `exec` command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+
+**Stream details**:
+
+Similar to the stream behavior of `POST /containers/(id or name)/attach` API
+
+#### Exec Resize
+
+`POST /exec/(id)/resize`
+
+Resizes the `tty` session used by the `exec` command `id`.  The unit is number of characters.
+This API is valid only if `tty` was specified as part of creating and starting the `exec` command.
+
+**Example request**:
+
+    POST /v1.20/exec/e90e34656806/resize?h=40&w=80 HTTP/1.1
+    Content-Type: text/plain
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: text/plain
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such exec instance
+
+#### Exec Inspect
+
+`GET /exec/(id)/json`
+
+Return low-level information about the `exec` command `id`.
+
+**Example request**:
+
+    GET /v1.20/exec/11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: plain/text
+
+    {
+      "ID" : "11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39",
+      "Running" : false,
+      "ExitCode" : 2,
+      "ProcessConfig" : {
+        "privileged" : false,
+        "user" : "",
+        "tty" : false,
+        "entrypoint" : "sh",
+        "arguments" : [
+          "-c",
+          "exit 2"
+        ]
+      },
+      "OpenStdin" : false,
+      "OpenStderr" : false,
+      "OpenStdout" : false,
+      "Container" : {
+        "State" : {
+          "Running" : true,
+          "Paused" : false,
+          "Restarting" : false,
+          "OOMKilled" : false,
+          "Pid" : 3650,
+          "ExitCode" : 0,
+          "Error" : "",
+          "StartedAt" : "2014-11-17T22:26:03.717657531Z",
+          "FinishedAt" : "0001-01-01T00:00:00Z"
+        },
+        "ID" : "8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c",
+        "Created" : "2014-11-17T22:26:03.626304998Z",
+        "Path" : "date",
+        "Args" : [],
+        "Config" : {
+          "Hostname" : "8f177a186b97",
+          "Domainname" : "",
+          "User" : "",
+          "AttachStdin" : false,
+          "AttachStdout" : false,
+          "AttachStderr" : false,
+          "ExposedPorts" : null,
+          "Tty" : false,
+          "OpenStdin" : false,
+          "StdinOnce" : false,
+          "Env" : [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ],
+          "Cmd" : [
+            "date"
+          ],
+          "Image" : "ubuntu",
+          "Volumes" : null,
+          "WorkingDir" : "",
+          "Entrypoint" : null,
+          "NetworkDisabled" : false,
+          "MacAddress" : "",
+          "OnBuild" : null,
+          "SecurityOpt" : null
+        },
+        "Image" : "5506de2b643be1e6febbf3b8a240760c6843244c41e12aa2f60ccbb7153d17f5",
+        "NetworkSettings" : {
+          "IPAddress" : "172.17.0.2",
+          "IPPrefixLen" : 16,
+          "MacAddress" : "02:42:ac:11:00:02",
+          "Gateway" : "172.17.42.1",
+          "Bridge" : "docker0",
+          "PortMapping" : null,
+          "Ports" : {}
+        },
+        "ResolvConfPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/resolv.conf",
+        "HostnamePath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hostname",
+        "HostsPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hosts",
+        "LogPath": "/var/lib/docker/containers/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b-json.log",
+        "Name" : "/test",
+        "Driver" : "aufs",
+        "ExecDriver" : "native-0.2",
+        "MountLabel" : "",
+        "ProcessLabel" : "",
+        "AppArmorProfile" : "",
+        "RestartCount" : 0,
+        "Mounts" : []
+      }
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+-   **500** - server error
+
+## 3. Going further
+
+### 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it.
+    - Then, retry to create the container.
+
+- Start the container.
+
+- If you are not in detached mode:
+- Attach to the container, using `logs=1` (to have `stdout` and
+      `stderr` from the container's start) and `stream=1`
+
+- If in detached mode or only `stdin` is attached, display the container's id.
+
+### 3.2 Hijacking
+
+In this version of the API, `/attach`, uses hijacking to transport `stdin`,
+`stdout`, and `stderr` on the same socket.
+
+To hint potential proxies about connection hijacking, Docker client sends
+connection upgrade headers similarly to websocket.
+
+    Upgrade: tcp
+    Connection: Upgrade
+
+When Docker daemon detects the `Upgrade` header, it switches its status code
+from **200 OK** to **101 UPGRADED** and resends the same headers.
+
+
+### 3.3 CORS Requests
+
+To set cross origin requests to the Engine API please give values to
+`--api-cors-header` when running Docker in daemon mode. Set * (asterisk) allows all,
+default or blank means CORS disabled
+
+    $ dockerd -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.21.md b/_vendor/github.com/moby/moby/api/docs/v1.21.md
new file mode 100644
index 000000000000..a67fe191940e
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.21.md
@@ -0,0 +1,2997 @@
+---
+title: "Engine API v1.21"
+description: "API Documentation for Docker"
+keywords: "API, Docker, rcli, REST, documentation"
+aliases:
+- /engine/reference/api/docker_remote_api_v1.21/
+- /reference/api/docker_remote_api_v1.21/
+---
+
+<!-- This file is maintained within the moby/moby GitHub
+     repository at https://github.com/moby/moby/. Make all
+     pull requests against that repo. If you see this file in
+     another repository, consider it read-only there, as it will
+     periodically be overwritten by the definitive file. Pull
+     requests which include edits to this file in other repositories
+     will be rejected.
+-->
+
+## 1. Brief introduction
+
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](https://docs.docker.com/engine/reference/commandline/dockerd/#bind-docker-to-another-host-port-or-a-unix-socket).
+ - The API tends to be REST. However, for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `stdout`,
+   `stdin` and `stderr`.
+ - A `Content-Length` header should be present in `POST` requests to endpoints
+   that expect a body.
+ - To lock to a specific version of the API, you prefix the URL with the version
+   of the API to use. For example, `/v1.18/info`. If no version is included in
+   the URL, the maximum supported API version is used.
+ - If the API version specified in the URL is not supported by the daemon, a HTTP
+   `400 Bad Request` error message is returned.
+
+## 2. Endpoints
+
+### 2.1 Containers
+
+#### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+    GET /v1.21/containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Id": "8dfafdbc3a40",
+                 "Names":["/boring_feynman"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 1",
+                 "Created": 1367854155,
+                 "Status": "Exit 0",
+                 "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                 "Labels": {
+                         "com.example.vendor": "Acme",
+                         "com.example.license": "GPL",
+                         "com.example.version": "1.0"
+                 },
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         },
+         {
+                 "Id": "9cd87474be90",
+                 "Names":["/coolName"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 222222",
+                 "Created": 1367854155,
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         },
+         {
+                 "Id": "3176a2479c92",
+                 "Names":["/sleepy_dog"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 3333333333333333",
+                 "Created": 1367854154,
+                 "Status": "Exit 0",
+                 "Ports":[],
+                 "Labels": {},
+                 "SizeRw":12288,
+                 "SizeRootFs":0
+         },
+         {
+                 "Id": "4cb07b47f9fb",
+                 "Names":["/running_cat"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 444444444444444444444444444444444",
+                 "Created": 1367854152,
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0
+         }
+    ]
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers
+        sizes
+-   **filters** - a JSON encoded value of the filters (a `map[string][]string`) to process on the containers list. Available filters:
+  -   `exited=<int>`; -- containers with exit code of  `<int>` ;
+  -   `status=`(`created`|`restarting`|`running`|`paused`|`exited`)
+  -   `label=key` or `label="key=value"` of a container label
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+#### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+    POST /v1.21/containers/create HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+           "Hostname": "",
+           "Domainname": "",
+           "User": "",
+           "AttachStdin": false,
+           "AttachStdout": true,
+           "AttachStderr": true,
+           "Tty": false,
+           "OpenStdin": false,
+           "StdinOnce": false,
+           "Env": [
+                   "FOO=bar",
+                   "BAZ=quux"
+           ],
+           "Cmd": [
+                   "date"
+           ],
+           "Entrypoint": null,
+           "Image": "ubuntu",
+           "Labels": {
+                   "com.example.vendor": "Acme",
+                   "com.example.license": "GPL",
+                   "com.example.version": "1.0"
+           },
+           "Volumes": {
+             "/volumes/data": {}
+           },
+           "WorkingDir": "",
+           "NetworkDisabled": false,
+           "MacAddress": "12:34:56:78:9a:bc",
+           "ExposedPorts": {
+                   "22/tcp": {}
+           },
+           "StopSignal": "SIGTERM",
+           "HostConfig": {
+             "Binds": ["/tmp:/tmp"],
+             "Links": ["redis3:redis"],
+             "LxcConf": {"lxc.utsname":"docker"},
+             "Memory": 0,
+             "MemorySwap": 0,
+             "MemoryReservation": 0,
+             "KernelMemory": 0,
+             "CpuShares": 512,
+             "CpuPeriod": 100000,
+             "CpuQuota": 50000,
+             "CpusetCpus": "0,1",
+             "CpusetMems": "0,1",
+             "BlkioWeight": 300,
+             "MemorySwappiness": 60,
+             "OomKillDisable": false,
+             "PidMode": "",
+             "PortBindings": { "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts": false,
+             "Privileged": false,
+             "ReadonlyRootfs": false,
+             "Dns": ["8.8.8.8"],
+             "DnsOptions": [""],
+             "DnsSearch": [""],
+             "ExtraHosts": null,
+             "VolumesFrom": ["parent", "other:ro"],
+             "CapAdd": ["NET_ADMIN"],
+             "CapDrop": ["MKNOD"],
+             "GroupAdd": ["newgroup"],
+             "RestartPolicy": { "Name": "", "MaximumRetryCount": 0 },
+             "NetworkMode": "bridge",
+             "Devices": [],
+             "Ulimits": [{}],
+             "LogConfig": { "Type": "json-file", "Config": {} },
+             "SecurityOpt": [],
+             "CgroupParent": "",
+             "VolumeDriver": ""
+          }
+      }
+
+**Example response**:
+
+      HTTP/1.1 201 Created
+      Content-Type: application/json
+
+      {
+           "Id":"e90e34656806",
+           "Warnings":[]
+      }
+
+**JSON parameters**:
+
+-   **Hostname** - A string value containing the hostname to use for the
+      container.
+-   **Domainname** - A string value containing the domain name to use
+      for the container.
+-   **User** - A string value specifying the user inside the container.
+-   **AttachStdin** - Boolean value, attaches to `stdin`.
+-   **AttachStdout** - Boolean value, attaches to `stdout`.
+-   **AttachStderr** - Boolean value, attaches to `stderr`.
+-   **Tty** - Boolean value, Attach standard streams to a `tty`, including `stdin` if it is not closed.
+-   **OpenStdin** - Boolean value, opens `stdin`,
+-   **StdinOnce** - Boolean value, close `stdin` after the 1 attached client disconnects.
+-   **Env** - A list of environment variables in the form of `["VAR=value", ...]`
+-   **Labels** - Adds a map of labels to a container. To specify a map: `{"key":"value", ... }`
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Entrypoint** - Set the entry point for the container as a string or an array
+      of strings.
+-   **Image** - A string specifying the image name to use for the container.
+-   **Volumes** - An object mapping mount point paths (strings) inside the
+      container to empty objects.
+-   **WorkingDir** - A string specifying the working directory for commands to
+      run in.
+-   **NetworkDisabled** - Boolean value, when true disables networking for the
+      container
+-   **ExposedPorts** - An object mapping ports to an empty object in the form of:
+      `"ExposedPorts": { "<port>/<tcp|udp>: {}" }`
+-   **StopSignal** - Signal to stop a container as a string or unsigned integer. `SIGTERM` by default.
+-   **HostConfig**
+    -   **Binds** – A list of volume bindings for this container. Each volume binding is a string in one of these forms:
+           + `host-src:container-dest` to bind-mount a host path into the
+             container. Both `host-src`, and `container-dest` must be an
+             _absolute_ path.
+           + `host-src:container-dest:ro` to make the bind mount read-only
+             inside the container. Both `host-src`, and `container-dest` must be
+             an _absolute_ path.
+           + `volume-name:container-dest` to bind-mount a volume managed by a
+             volume driver into the container. `container-dest` must be an
+             _absolute_ path.
+           + `volume-name:container-dest:ro` to mount the volume read-only
+             inside the container.  `container-dest` must be an _absolute_ path.
+    -   **Links** - A list of links for the container. Each link entry should be
+          in the form of `container_name:alias`.
+    -   **LxcConf** - LXC specific configurations. These configurations only
+          work when using the `lxc` execution driver.
+    -   **Memory** - Memory limit in bytes.
+    -   **MemorySwap** - Total memory limit (memory + swap); set `-1` to enable unlimited swap.
+          You must use this with `memory` and make the swap value larger than `memory`.
+    -   **MemoryReservation** - Memory soft limit in bytes.
+    -   **KernelMemory** - Kernel memory limit in bytes.
+    -   **CpuShares** - An integer value containing the container's CPU Shares
+          (ie. the relative weight vs other containers).
+    -   **CpuPeriod** - The length of a CPU period in microseconds.
+    -   **CpuQuota** - Microseconds of CPU time that the container can get in a CPU period.
+    -   **CpusetCpus** - String value containing the `cgroups CpusetCpus` to use.
+    -   **CpusetMems** - Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
+    -   **BlkioWeight** - Block IO weight (relative weight) accepts a weight value between 10 and 1000.
+    -   **MemorySwappiness** - Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100.
+    -   **OomKillDisable** - Boolean value, whether to disable OOM Killer for the container or not.
+    -   **PidMode** - Set the PID (Process) Namespace mode for the container;
+          `"container:<name|id>"`: joins another container's PID namespace
+          `"host"`: use the host's PID namespace inside the container
+    -   **PortBindings** - A map of exposed container ports and the host port they
+          should map to. A JSON object in the form
+          `{ <port>/<protocol>: [{ "HostPort": "<port>" }] }`
+          Take note that `port` is specified as a string and not an integer value.
+    -   **PublishAllPorts** - Allocates an ephemeral host port for all of a container's
+          exposed ports. Specified as a boolean value.
+
+          Ports are de-allocated when the container stops and allocated when the container starts.
+          The allocated port might be changed when restarting the container.
+
+          The port is selected from the ephemeral port range that depends on the kernel.
+          For example, on Linux the range is defined by `/proc/sys/net/ipv4/ip_local_port_range`.
+    -   **Privileged** - Gives the container full access to the host. Specified as
+          a boolean value.
+    -   **ReadonlyRootfs** - Mount the container's root filesystem as read only.
+          Specified as a boolean value.
+    -   **Dns** - A list of DNS servers for the container to use.
+    -   **DnsOptions** - A list of DNS options
+    -   **DnsSearch** - A list of DNS search domains
+    -   **ExtraHosts** - A list of hostnames/IP mappings to add to the
+        container's `/etc/hosts` file. Specified in the form `["hostname:IP"]`.
+    -   **VolumesFrom** - A list of volumes to inherit from another container.
+          Specified in the form `<container name>[:<ro|rw>]`
+    -   **CapAdd** - A list of kernel capabilities to add to the container.
+    -   **Capdrop** - A list of kernel capabilities to drop from the container.
+    -   **GroupAdd** - A list of additional groups that the container process will run as
+    -   **RestartPolicy** – The behavior to apply when the container exits.  The
+            value is an object with a `Name` property of either `"always"` to
+            always restart, `"unless-stopped"` to restart always except when
+            user has manually stopped the container or `"on-failure"` to restart only when the container
+            exit code is non-zero.  If `on-failure` is used, `MaximumRetryCount`
+            controls the number of times to retry before giving up.
+            The default is not to restart. (optional)
+            An ever increasing delay (double the previous delay, starting at 100mS)
+            is added before each restart to prevent flooding the server.
+    -   **NetworkMode** - Sets the networking mode for the container. Supported
+          standard values are: `bridge`, `host`, `none`, and `container:<name|id>`. Any other value is taken
+          as a custom network's name to which this container should connect to.
+    -   **Devices** - A list of devices to add to the container specified as a JSON object in the
+      form
+          `{ "PathOnHost": "/dev/deviceName", "PathInContainer": "/dev/deviceName", "CgroupPermissions": "mrw"}`
+    -   **Ulimits** - A list of ulimits to set in the container, specified as
+          `{ "Name": <name>, "Soft": <soft limit>, "Hard": <hard limit> }`, for example:
+          `Ulimits: { "Name": "nofile", "Soft": 1024, "Hard": 2048 }`
+    -   **SecurityOpt**: A list of string values to customize labels for MLS
+        systems, such as SELinux.
+    -   **LogConfig** - Log configuration for the container, specified as a JSON object in the form
+          `{ "Type": "<driver_name>", "Config": {"key1": "val1"}}`.
+          Available types: `json-file`, `syslog`, `journald`, `gelf`, `awslogs`, `none`.
+          `json-file` logging driver.
+    -   **CgroupParent** - Path to `cgroups` under which the container's `cgroup` is created. If the path is not absolute, the path is considered to be relative to the `cgroups` path of the init process. Cgroups are created if they do not already exist.
+    -   **VolumeDriver** - Driver that this container users to mount volumes.
+
+**Query parameters**:
+
+-   **name** – Assign the specified name to the container. Must
+    match `/?[a-zA-Z0-9_-]+`.
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **406** – impossible to attach (container not running)
+-   **409** – conflict
+-   **500** – server error
+
+#### Inspect a container
+
+`GET /containers/(id or name)/json`
+
+Return low-level information on the container `id`
+
+**Example request**:
+
+      GET /v1.21/containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+	{
+		"AppArmorProfile": "",
+		"Args": [
+			"-c",
+			"exit 9"
+		],
+		"Config": {
+			"AttachStderr": true,
+			"AttachStdin": false,
+			"AttachStdout": true,
+			"Cmd": [
+				"/bin/sh",
+				"-c",
+				"exit 9"
+			],
+			"Domainname": "",
+			"Entrypoint": null,
+			"Env": [
+				"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+			],
+			"ExposedPorts": null,
+			"Hostname": "ba033ac44011",
+			"Image": "ubuntu",
+			"Labels": {
+				"com.example.vendor": "Acme",
+				"com.example.license": "GPL",
+				"com.example.version": "1.0"
+			},
+			"MacAddress": "",
+			"NetworkDisabled": false,
+			"OnBuild": null,
+			"OpenStdin": false,
+			"StdinOnce": false,
+			"Tty": false,
+			"User": "",
+			"Volumes": null,
+			"WorkingDir": "",
+			"StopSignal": "SIGTERM"
+		},
+		"Created": "2015-01-06T15:47:31.485331387Z",
+		"Driver": "overlay2",
+		"ExecDriver": "native-0.2",
+		"ExecIDs": null,
+		"HostConfig": {
+			"Binds": null,
+			"BlkioWeight": 0,
+			"CapAdd": null,
+			"CapDrop": null,
+			"ContainerIDFile": "",
+			"CpusetCpus": "",
+			"CpusetMems": "",
+			"CpuShares": 0,
+			"CpuPeriod": 100000,
+			"Devices": [],
+			"Dns": null,
+			"DnsOptions": null,
+			"DnsSearch": null,
+			"ExtraHosts": null,
+			"IpcMode": "",
+			"Links": null,
+			"LxcConf": [],
+			"Memory": 0,
+			"MemorySwap": 0,
+			"MemoryReservation": 0,
+			"KernelMemory": 0,
+			"OomKillDisable": false,
+			"NetworkMode": "bridge",
+			"PidMode": "",
+			"PortBindings": {},
+			"Privileged": false,
+			"ReadonlyRootfs": false,
+			"PublishAllPorts": false,
+			"RestartPolicy": {
+				"MaximumRetryCount": 2,
+				"Name": "on-failure"
+			},
+			"LogConfig": {
+				"Config": null,
+				"Type": "json-file"
+			},
+			"SecurityOpt": null,
+			"VolumesFrom": null,
+			"Ulimits": [{}],
+			"VolumeDriver": ""
+		},
+		"HostnamePath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hostname",
+		"HostsPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hosts",
+		"LogPath": "/var/lib/docker/containers/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b-json.log",
+		"Id": "ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39",
+		"Image": "04c5d3b7b0656168630d3ba35d8889bd0e9caafcaeb3004d2bfbc47e7c5d35d2",
+		"MountLabel": "",
+		"Name": "/boring_euclid",
+		"NetworkSettings": {
+			"Bridge": "",
+			"SandboxID": "",
+			"HairpinMode": false,
+			"LinkLocalIPv6Address": "",
+			"LinkLocalIPv6PrefixLen": 0,
+			"Ports": null,
+			"SandboxKey": "",
+			"SecondaryIPAddresses": null,
+			"SecondaryIPv6Addresses": null,
+			"EndpointID": "",
+			"Gateway": "",
+			"GlobalIPv6Address": "",
+			"GlobalIPv6PrefixLen": 0,
+			"IPAddress": "",
+			"IPPrefixLen": 0,
+			"IPv6Gateway": "",
+			"MacAddress": "",
+			"Networks": {
+				"bridge": {
+					"EndpointID": "7587b82f0dada3656fda26588aee72630c6fab1536d36e394b2bfbcf898c971d",
+					"Gateway": "172.17.0.1",
+					"IPAddress": "172.17.0.2",
+					"IPPrefixLen": 16,
+					"IPv6Gateway": "",
+					"GlobalIPv6Address": "",
+					"GlobalIPv6PrefixLen": 0,
+					"MacAddress": "02:42:ac:12:00:02"
+				}
+			}
+		},
+		"Path": "/bin/sh",
+		"ProcessLabel": "",
+		"ResolvConfPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/resolv.conf",
+		"RestartCount": 1,
+		"State": {
+			"Error": "",
+			"ExitCode": 9,
+			"FinishedAt": "2015-01-06T15:47:32.080254511Z",
+			"OOMKilled": false,
+			"Paused": false,
+			"Pid": 0,
+			"Restarting": false,
+			"Running": true,
+			"StartedAt": "2015-01-06T15:47:32.072697474Z",
+			"Status": "running"
+		},
+		"Mounts": [
+			{
+				"Source": "/data",
+				"Destination": "/data",
+				"Mode": "ro,Z",
+				"RW": false
+			}
+		]
+	}
+
+**Example request, with size information**:
+
+    GET /v1.21/containers/4fa6e0f0c678/json?size=1 HTTP/1.1
+
+**Example response, with size information**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+    ....
+    "SizeRw": 0,
+    "SizeRootFs": 972,
+    ....
+    }
+
+**Query parameters**:
+
+-   **size** – 1/True/true or 0/False/false, return container size information. Default is `false`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### List processes running inside a container
+
+`GET /containers/(id or name)/top`
+
+List processes running inside the container `id`. On Unix systems this
+is done by running the `ps` command. This endpoint is not
+supported on Windows.
+
+**Example request**:
+
+    GET /v1.21/containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Titles" : [
+         "UID", "PID", "PPID", "C", "STIME", "TTY", "TIME", "CMD"
+       ],
+       "Processes" : [
+         [
+           "root", "13642", "882", "0", "17:03", "pts/0", "00:00:00", "/bin/bash"
+         ],
+         [
+           "root", "13735", "13642", "0", "17:06", "pts/0", "00:00:00", "sleep 10"
+         ]
+       ]
+    }
+
+**Example request**:
+
+    GET /v1.21/containers/4fa6e0f0c678/top?ps_args=aux HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Titles" : [
+        "USER","PID","%CPU","%MEM","VSZ","RSS","TTY","STAT","START","TIME","COMMAND"
+      ]
+      "Processes" : [
+        [
+          "root","13642","0.0","0.1","18172","3184","pts/0","Ss","17:03","0:00","/bin/bash"
+        ],
+        [
+          "root","13895","0.0","0.0","4348","692","pts/0","S+","17:15","0:00","sleep 10"
+        ]
+      ],
+    }
+
+**Query parameters**:
+
+-   **ps_args** – `ps` arguments to use (e.g., `aux`), defaults to `-ef`
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container logs
+
+`GET /containers/(id or name)/logs`
+
+Get `stdout` and `stderr` logs from the container ``id``
+
+> **Note**:
+> This endpoint works only for containers with the `json-file` or `journald` logging drivers.
+
+**Example request**:
+
+     GET /v1.21/containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10&since=1428990821 HTTP/1.1
+
+**Example response**:
+
+     HTTP/1.1 101 UPGRADED
+     Content-Type: application/vnd.docker.raw-stream
+     Connection: Upgrade
+     Upgrade: tcp
+
+     {% raw %}
+     {{ STREAM }}
+     {% endraw %}
+
+**Query parameters**:
+
+-   **follow** – 1/True/true or 0/False/false, return stream. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, show `stdout` log. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, show `stderr` log. Default `false`.
+-   **since** – UNIX timestamp (integer) to filter logs. Specifying a timestamp
+    will only output log-entries since that timestamp. Default: 0 (unfiltered)
+-   **timestamps** – 1/True/true or 0/False/false, print timestamps for
+        every log line. Default `false`.
+-   **tail** – Output specified number of lines at the end of logs: `all` or `<number>`. Default all.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **404** – no such container
+-   **500** – server error
+
+#### Inspect changes on a container's filesystem
+
+`GET /containers/(id or name)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+    GET /v1.21/containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Path": "/dev",
+                 "Kind": 0
+         },
+         {
+                 "Path": "/dev/kmsg",
+                 "Kind": 1
+         },
+         {
+                 "Path": "/test",
+                 "Kind": 1
+         }
+    ]
+
+Values for `Kind`:
+
+- `0`: Modify
+- `1`: Add
+- `2`: Delete
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Export a container
+
+`GET /containers/(id or name)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+    GET /v1.21/containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/octet-stream
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container stats based on resource usage
+
+`GET /containers/(id or name)/stats`
+
+This endpoint returns a live stream of a container's resource usage statistics.
+
+**Example request**:
+
+    GET /v1.21/containers/redis1/stats HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Type: application/json
+
+      {
+         "read" : "2015-01-08T22:57:31.547920715Z",
+         "networks": {
+                 "eth0": {
+                     "rx_bytes": 5338,
+                     "rx_dropped": 0,
+                     "rx_errors": 0,
+                     "rx_packets": 36,
+                     "tx_bytes": 648,
+                     "tx_dropped": 0,
+                     "tx_errors": 0,
+                     "tx_packets": 8
+                 },
+                 "eth5": {
+                     "rx_bytes": 4641,
+                     "rx_dropped": 0,
+                     "rx_errors": 0,
+                     "rx_packets": 26,
+                     "tx_bytes": 690,
+                     "tx_dropped": 0,
+                     "tx_errors": 0,
+                     "tx_packets": 9
+                 }
+         },
+         "memory_stats" : {
+            "stats" : {
+               "total_pgmajfault" : 0,
+               "cache" : 0,
+               "mapped_file" : 0,
+               "total_inactive_file" : 0,
+               "pgpgout" : 414,
+               "rss" : 6537216,
+               "total_mapped_file" : 0,
+               "writeback" : 0,
+               "unevictable" : 0,
+               "pgpgin" : 477,
+               "total_unevictable" : 0,
+               "pgmajfault" : 0,
+               "total_rss" : 6537216,
+               "total_rss_huge" : 6291456,
+               "total_writeback" : 0,
+               "total_inactive_anon" : 0,
+               "rss_huge" : 6291456,
+               "hierarchical_memory_limit" : 67108864,
+               "total_pgfault" : 964,
+               "total_active_file" : 0,
+               "active_anon" : 6537216,
+               "total_active_anon" : 6537216,
+               "total_pgpgout" : 414,
+               "total_cache" : 0,
+               "inactive_anon" : 0,
+               "active_file" : 0,
+               "pgfault" : 964,
+               "inactive_file" : 0,
+               "total_pgpgin" : 477
+            },
+            "max_usage" : 6651904,
+            "usage" : 6537216,
+            "failcnt" : 0,
+            "limit" : 67108864
+         },
+         "blkio_stats" : {},
+         "cpu_stats" : {
+            "cpu_usage" : {
+               "percpu_usage" : [
+                  8646879,
+                  24472255,
+                  36438778,
+                  30657443
+               ],
+               "usage_in_usermode" : 50000000,
+               "total_usage" : 100215355,
+               "usage_in_kernelmode" : 30000000
+            },
+            "system_cpu_usage" : 739306590000000,
+            "throttling_data" : {"periods":0,"throttled_periods":0,"throttled_time":0}
+         },
+         "precpu_stats" : {
+            "cpu_usage" : {
+               "percpu_usage" : [
+                  8646879,
+                  24350896,
+                  36438778,
+                  30657443
+               ],
+               "usage_in_usermode" : 50000000,
+               "total_usage" : 100093996,
+               "usage_in_kernelmode" : 30000000
+            },
+            "system_cpu_usage" : 9492140000000,
+            "throttling_data" : {"periods":0,"throttled_periods":0,"throttled_time":0}
+         }
+      }
+
+The `precpu_stats` is the cpu statistic of *previous* read, which is used for calculating the cpu usage percent. It is not the exact copy of the `cpu_stats` field.
+
+**Query parameters**:
+
+-   **stream** – 1/True/true or 0/False/false, pull stats once then disconnect. Default `true`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Resize a container TTY
+
+`POST /containers/(id or name)/resize`
+
+Resize the TTY for container with  `id`. The unit is number of characters. You must restart the container for the resize to take effect.
+
+**Example request**:
+
+      POST /v1.21/containers/4fa6e0f0c678/resize?h=40&w=80 HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Length: 0
+      Content-Type: text/plain; charset=utf-8
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – No such container
+-   **500** – Cannot resize container
+
+#### Start a container
+
+`POST /containers/(id or name)/start`
+
+Start the container `id`
+
+> **Note**:
+> For backwards compatibility, this endpoint accepts a `HostConfig` as JSON-encoded request body.
+> See [create a container](#create-a-container) for details.
+
+**Example request**:
+
+    POST /v1.21/containers/e90e34656806/start HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already started
+-   **404** – no such container
+-   **500** – server error
+
+#### Stop a container
+
+`POST /containers/(id or name)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+    POST /v1.21/containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already stopped
+-   **404** – no such container
+-   **500** – server error
+
+#### Restart a container
+
+`POST /containers/(id or name)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+    POST /v1.21/containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Kill a container
+
+`POST /containers/(id or name)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+    POST /v1.21/containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **signal** - Signal to send to the container: integer or string like `SIGINT`.
+        When not set, `SIGKILL` is assumed and the call waits for the container to exit.
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Rename a container
+
+`POST /containers/(id or name)/rename`
+
+Rename the container `id` to a `new_name`
+
+**Example request**:
+
+    POST /v1.21/containers/e90e34656806/rename?name=new_name HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **name** – new name for the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **409** - conflict name already assigned
+-   **500** – server error
+
+#### Pause a container
+
+`POST /containers/(id or name)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+    POST /v1.21/containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Unpause a container
+
+`POST /containers/(id or name)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+    POST /v1.21/containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Attach to a container
+
+`POST /containers/(id or name)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+    POST /v1.21/containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 101 UPGRADED
+    Content-Type: application/vnd.docker.raw-stream
+    Connection: Upgrade
+    Upgrade: tcp
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+-   **stdin** – 1/True/true or 0/False/false, if `stream=true`, attach
+        to `stdin`. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stdout` log, if `stream=true`, attach to `stdout`. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stderr` log, if `stream=true`, attach to `stderr`. Default `false`.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+**Stream details**:
+
+When using the TTY setting is enabled in
+[`POST /containers/create`
+](#create-a-container),
+the stream is the raw data from the process PTY and client's `stdin`.
+When the TTY is disabled, then the stream is multiplexed to separate
+`stdout` and `stderr`.
+
+The format is a **Header** and a **Payload** (frame).
+
+**HEADER**
+
+The header contains the information which the stream writes (`stdout` or
+`stderr`). It also contains the size of the associated frame encoded in the
+last four bytes (`uint32`).
+
+It is encoded on the first eight bytes like this:
+
+    header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+`STREAM_TYPE` can be:
+
+-   0: `stdin` (is written on `stdout`)
+-   1: `stdout`
+-   2: `stderr`
+
+`SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of
+the `uint32` size encoded as big endian.
+
+**PAYLOAD**
+
+The payload is the raw stream.
+
+**IMPLEMENTATION**
+
+The simplest way to implement the Attach protocol is the following:
+
+    1.  Read eight bytes.
+    2.  Choose `stdout` or `stderr` depending on the first byte.
+    3.  Extract the frame size from the last four bytes.
+    4.  Read the extracted size and output it on the correct output.
+    5.  Goto 1.
+
+#### Attach to a container (websocket)
+
+`GET /containers/(id or name)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+    GET /v1.21/containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+#### Wait a container
+
+`POST /containers/(id or name)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+    POST /v1.21/containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"StatusCode": 0}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Remove a container
+
+`DELETE /containers/(id or name)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.21/containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default `false`.
+-   **force** - 1/True/true or 0/False/false, Kill then remove the container.
+        Default `false`.
+-   **link** - 1/True/true or 0/False/false, Remove the specified
+        link associated to the container. Default `false`.
+
+**Status codes**:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **409** – conflict
+-   **500** – server error
+
+#### Copy files or folders from a container
+
+`POST /containers/(id or name)/copy`
+
+Copy files or folders of container `id`
+
+**Deprecated** in favor of the `archive` endpoint below.
+
+**Example request**:
+
+    POST /v1.21/containers/4fa6e0f0c678/copy HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Resource": "test.txt"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Retrieving information about files and folders in a container
+
+`HEAD /containers/(id or name)/archive`
+
+See the description of the `X-Docker-Container-Path-Stat` header in the
+following section.
+
+#### Get an archive of a filesystem resource in a container
+
+`GET /containers/(id or name)/archive`
+
+Get a tar archive of a resource in the filesystem of container `id`.
+
+**Query parameters**:
+
+- **path** - resource in the container's filesystem to archive. Required.
+
+    If not an absolute path, it is relative to the container's root directory.
+    The resource specified by **path** must exist. To assert that the resource
+    is expected to be a directory, **path** should end in `/` or  `/.`
+    (assuming a path separator of `/`). If **path** ends in `/.` then this
+    indicates that only the contents of the **path** directory should be
+    copied. A symlink is always resolved to its target.
+
+    > **Note**: It is not possible to copy certain system files such as resources
+    > under `/proc`, `/sys`, `/dev`, and mounts created by the user in the
+    > container.
+
+**Example request**:
+
+    GET /v1.21/containers/8cce319429b2/archive?path=/root HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+    X-Docker-Container-Path-Stat: eyJuYW1lIjoicm9vdCIsInNpemUiOjQwOTYsIm1vZGUiOjIxNDc0ODQwOTYsIm10aW1lIjoiMjAxNC0wMi0yN1QyMDo1MToyM1oiLCJsaW5rVGFyZ2V0IjoiIn0=
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+On success, a response header `X-Docker-Container-Path-Stat` will be set to a
+base64-encoded JSON object containing some filesystem header information about
+the archived resource. The above example value would decode to the following
+JSON object (whitespace added for readability):
+
+```json
+{
+    "name": "root",
+    "size": 4096,
+    "mode": 2147484096,
+    "mtime": "2014-02-27T20:51:23Z",
+    "linkTarget": ""
+}
+```
+
+A `HEAD` request can also be made to this endpoint if only this information is
+desired.
+
+**Status codes**:
+
+- **200** - success, returns archive of copied resource
+- **400** - client error, bad parameter, details in JSON response body, one of:
+    - must specify path parameter (**path** cannot be empty)
+    - not a directory (**path** was asserted to be a directory but exists as a
+      file)
+- **404** - client error, resource not found, one of:
+    – no such container (container `id` does not exist)
+    - no such file or directory (**path** does not exist)
+- **500** - server error
+
+#### Extract an archive of files or folders to a directory in a container
+
+`PUT /containers/(id or name)/archive`
+
+Upload a tar archive to be extracted to a path in the filesystem of container
+`id`.
+
+**Query parameters**:
+
+- **path** - path to a directory in the container
+    to extract the archive's contents into. Required.
+
+    If not an absolute path, it is relative to the container's root directory.
+    The **path** resource must exist.
+- **noOverwriteDirNonDir** - If "1", "true", or "True" then it will be an error
+    if unpacking the given content would cause an existing directory to be
+    replaced with a non-directory and vice versa.
+
+**Example request**:
+
+    PUT /v1.21/containers/8cce319429b2/archive?path=/vol1 HTTP/1.1
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+- **200** – the content was extracted successfully
+- **400** - client error, bad parameter, details in JSON response body, one of:
+    - must specify path parameter (**path** cannot be empty)
+    - not a directory (**path** should be a directory but exists as a file)
+    - unable to overwrite existing directory with non-directory
+      (if **noOverwriteDirNonDir**)
+    - unable to overwrite existing non-directory with directory
+      (if **noOverwriteDirNonDir**)
+- **403** - client error, permission denied, the volume
+    or container rootfs is marked as read-only.
+- **404** - client error, resource not found, one of:
+    – no such container (container `id` does not exist)
+    - no such file or directory (**path** resource does not exist)
+- **500** – server error
+
+### 2.2 Images
+
+#### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+    GET /v1.21/images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+         "RepoTags": [
+           "ubuntu:12.04",
+           "ubuntu:precise",
+           "ubuntu:latest"
+         ],
+         "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+         "Created": 1365714795,
+         "Size": 131506275,
+         "VirtualSize": 131506275,
+         "Labels": {}
+      },
+      {
+         "RepoTags": [
+           "ubuntu:12.10",
+           "ubuntu:quantal"
+         ],
+         "ParentId": "27cf784147099545",
+         "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+         "Created": 1364102658,
+         "Size": 24653,
+         "VirtualSize": 180116135,
+         "Labels": {
+            "com.example.version": "v1"
+         }
+      }
+    ]
+
+**Example request, with digest information**:
+
+    GET /v1.21/images/json?digests=1 HTTP/1.1
+
+**Example response, with digest information**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+        "Created": 1420064636,
+        "Id": "4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125",
+        "ParentId": "ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2",
+        "RepoDigests": [
+          "localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf"
+        ],
+        "RepoTags": [
+          "localhost:5000/test/busybox:latest",
+          "playdate:latest"
+        ],
+        "Size": 0,
+        "VirtualSize": 2429728,
+        "Labels": {}
+      }
+    ]
+
+The response shows a single image `Id` associated with two repositories
+(`RepoTags`): `localhost:5000/test/busybox`: and `playdate`. A caller can use
+either of the `RepoTags` values `localhost:5000/test/busybox:latest` or
+`playdate:latest` to reference the image.
+
+You can also use `RepoDigests` values to reference an image. In this response,
+the array has only one reference and that is to the
+`localhost:5000/test/busybox` repository; the `playdate` repository has no
+digest. You can reference this digest using the value:
+`localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d...`
+
+See the `docker run` and `docker build` commands for examples of digest and tag
+references on the command line.
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a JSON encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   `dangling=true`
+  -   `label=key` or `label="key=value"` of an image label
+-   **filter** - only return images with the specified name
+
+#### Build image from a Dockerfile
+
+`POST /build`
+
+Build an image from a Dockerfile
+
+**Example request**:
+
+    POST /v1.21/build HTTP/1.1
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"stream": "Step 1/5..."}
+    {"stream": "..."}
+    {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+The input stream must be a `tar` archive compressed with one of the
+following algorithms: `identity` (no compression), `gzip`, `bzip2`, `xz`.
+
+The archive must include a build instructions file, typically called
+`Dockerfile` at the archive's root. The `dockerfile` parameter may be
+used to specify a different build instructions file. To do this, its value must be
+the path to the alternate build instructions file to use.
+
+The archive may include any number of other files,
+which are accessible in the build context (See the [*ADD build
+command*](https://docs.docker.com/engine/reference/builder/#add)).
+
+The Docker daemon performs a preliminary validation of the `Dockerfile` before
+starting the build, and returns an error if the syntax is incorrect. After that,
+each instruction is run one-by-one until the ID of the new image is output.
+
+The build is canceled if the client drops the connection by quitting
+or being killed.
+
+**Query parameters**:
+
+-   **dockerfile** - Path within the build context to the `Dockerfile`. This is
+        ignored if `remote` is specified and points to an external `Dockerfile`.
+-   **t** – A name and optional tag to apply to the image in the `name:tag` format.
+        If you omit the `tag` the default `latest` value is assumed.
+        You can provide one or more `t` parameters.
+-   **remote** – A Git repository URI or HTTP/HTTPS context URI. If the
+        URI points to a single text file, the file's contents are placed into
+        a file called `Dockerfile` and the image is built from that file. If
+        the URI points to a tarball, the file is downloaded by the daemon and
+        the contents therein used as the context for the build. If the URI
+        points to a tarball and the `dockerfile` parameter is also specified,
+        there must be a file with the corresponding path inside the tarball.
+-   **q** – Suppress verbose build output.
+-   **nocache** – Do not use the cache when building the image.
+-   **pull** - Attempt to pull the image even if an older image exists locally.
+-   **rm** - Remove intermediate containers after a successful build (default behavior).
+-   **forcerm** - Always remove intermediate containers (includes `rm`).
+-   **memory** - Set memory limit for build.
+-   **memswap** - Total memory (memory + swap), `-1` to enable unlimited swap.
+-   **cpushares** - CPU shares (relative weight).
+-   **cpusetcpus** - CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+-   **cpuperiod** - The length of a CPU period in microseconds.
+-   **cpuquota** - Microseconds of CPU time that the container can get in a CPU period.
+-   **buildargs** – JSON map of string pairs for build-time variables. Users pass
+        these values at build-time. Docker uses the `buildargs` as the environment
+        context for command(s) run via the Dockerfile's `RUN` instruction or for
+        variable expansion in other Dockerfile instructions. This is not meant for
+        passing secret values. [Read more about the buildargs instruction](https://docs.docker.com/engine/reference/builder/#arg)
+
+**Request Headers**:
+
+-   **Content-type** – Set to `"application/x-tar"`.
+-   **X-Registry-Config** – A base64-url-safe-encoded Registry Auth Config JSON
+        object with the following structure:
+
+            {
+                "docker.example.com": {
+                    "username": "janedoe",
+                    "password": "hunter2"
+                },
+                "https://index.docker.io/v1/": {
+                    "username": "mobydock",
+                    "password": "conta1n3rize14"
+                }
+            }
+
+    This object maps the hostname of a registry to an object containing the
+    "username" and "password" for that registry. Multiple registries may
+    be specified as the build may be based on an image requiring
+    authentication to pull from any arbitrary registry. Only the registry
+    domain name (and port if not the default "443") are required. However
+    (for legacy reasons) the "official" Docker, Inc. hosted registry must
+    be specified with both a "https://" prefix and a "/v1/" suffix even
+    though Docker will prefer to use the v2 registry API.
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Create an image
+
+`POST /images/create`
+
+Create an image either by pulling it from the registry or by importing it
+
+**Example request**:
+
+    POST /v1.21/images/create?fromImage=busybox&tag=latest HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pulling..."}
+    {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+    {"error": "Invalid..."}
+    ...
+
+When using this endpoint to pull an image from the registry, the
+`X-Registry-Auth` header can be used to include
+a base64-encoded AuthConfig object.
+
+**Query parameters**:
+
+-   **fromImage** – Name of the image to pull. The name may include a tag or
+        digest. This parameter may only be used when pulling an image.
+-   **fromSrc** – Source to import.  The value may be a URL from which the image
+        can be retrieved or `-` to read the image from the request body.
+        This parameter may only be used when importing an image.
+-   **repo** – Repository name given to an image when it is imported.
+        The repo may include a tag. This parameter may only be used when importing
+        an image.
+-   **tag** – Tag or digest. If empty when pulling an image, this causes all tags
+        for the given image to be pulled.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** - repository does not exist or no read access
+-   **500** – server error
+
+
+
+#### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+    GET /v1.21/images/example/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Id" : "85f05633ddc1c50679be2b16a0479ab6f7637f8884e0cfe0f4d20e1ebb3d6e7c",
+       "Container" : "cb91e48a60d01f1e27028b4fc6819f4f290b3cf12496c8176ec714d0d390984a",
+       "Comment" : "",
+       "Os" : "linux",
+       "Architecture" : "amd64",
+       "Parent" : "91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c",
+       "ContainerConfig" : {
+          "Tty" : false,
+          "Hostname" : "e611e15f9c9d",
+          "Volumes" : null,
+          "Domainname" : "",
+          "AttachStdout" : false,
+          "PublishService" : "",
+          "AttachStdin" : false,
+          "OpenStdin" : false,
+          "StdinOnce" : false,
+          "NetworkDisabled" : false,
+          "OnBuild" : [],
+          "Image" : "91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c",
+          "User" : "",
+          "WorkingDir" : "",
+          "Entrypoint" : null,
+          "MacAddress" : "",
+          "AttachStderr" : false,
+          "Labels" : {
+             "com.example.license" : "GPL",
+             "com.example.version" : "1.0",
+             "com.example.vendor" : "Acme"
+          },
+          "Env" : [
+             "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+          ],
+          "ExposedPorts" : null,
+          "Cmd" : [
+             "/bin/sh",
+             "-c",
+             "#(nop) LABEL com.example.vendor=Acme com.example.license=GPL com.example.version=1.0"
+          ]
+       },
+       "DockerVersion" : "1.9.0-dev",
+       "VirtualSize" : 188359297,
+       "Size" : 0,
+       "Author" : "",
+       "Created" : "2015-09-10T08:30:53.26995814Z",
+       "GraphDriver" : {
+          "Name" : "aufs",
+          "Data" : null
+       },
+       "RepoDigests" : [
+          "localhost:5000/test/busybox/example@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf"
+       ],
+       "RepoTags" : [
+          "example:1.0",
+          "example:latest",
+          "example:stable"
+       ],
+       "Config" : {
+          "Image" : "91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c",
+          "NetworkDisabled" : false,
+          "OnBuild" : [],
+          "StdinOnce" : false,
+          "PublishService" : "",
+          "AttachStdin" : false,
+          "OpenStdin" : false,
+          "Domainname" : "",
+          "AttachStdout" : false,
+          "Tty" : false,
+          "Hostname" : "e611e15f9c9d",
+          "Volumes" : null,
+          "Cmd" : [
+             "/bin/bash"
+          ],
+          "ExposedPorts" : null,
+          "Env" : [
+             "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+          ],
+          "Labels" : {
+             "com.example.vendor" : "Acme",
+             "com.example.version" : "1.0",
+             "com.example.license" : "GPL"
+          },
+          "Entrypoint" : null,
+          "MacAddress" : "",
+          "AttachStderr" : false,
+          "WorkingDir" : "",
+          "User" : ""
+       }
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+    GET /v1.21/images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+        {
+            "Id": "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710",
+            "Created": 1398108230,
+            "CreatedBy": "/bin/sh -c #(nop) ADD file:eb15dbd63394e063b805a3c32ca7bf0266ef64676d5a6fab4801f2e81e2a5148 in /",
+            "Tags": [
+                "ubuntu:lucid",
+                "ubuntu:10.04"
+            ],
+            "Size": 182964289,
+            "Comment": ""
+        },
+        {
+            "Id": "6cfa4d1f33fb861d4d114f43b25abd0ac737509268065cdfd69d544a59c85ab8",
+            "Created": 1398108222,
+            "CreatedBy": "/bin/sh -c #(nop) MAINTAINER Tianon Gravi <admwiggin@gmail.com> - mkimage-debootstrap.sh -i iproute,iputils-ping,ubuntu-minimal -t lucid.tar.xz lucid http://archive.ubuntu.com/ubuntu/",
+            "Tags": null,
+            "Size": 0,
+            "Comment": ""
+        },
+        {
+            "Id": "511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158",
+            "Created": 1371157430,
+            "CreatedBy": "",
+            "Tags": [
+                "scratch12:latest",
+                "scratch:latest"
+            ],
+            "Size": 0,
+            "Comment": "Imported from -"
+        }
+    ]
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+    POST /v1.21/images/test/push HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pushing..."}
+    {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+    {"error": "Invalid..."}
+    ...
+
+If you wish to push an image on to a private registry, that image must already have a tag
+into a repository which references that registry `hostname` and `port`.  This repository name should
+then be used in the URL. This duplicates the command line's flow.
+
+**Example request**:
+
+    POST /v1.21/images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+**Query parameters**:
+
+-   **tag** – The tag to associate with the image on the registry. This is optional.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+    POST /v1.21/images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+
+**Query parameters**:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.21/images/test HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-type: application/json
+
+    [
+     {"Untagged": "3e2f21a89f"},
+     {"Deleted": "3e2f21a89f"},
+     {"Deleted": "53b4f83ac9"}
+    ]
+
+**Query parameters**:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+    GET /v1.21/images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "wma55/u1210sshd",
+                "star_count": 0
+            },
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "jdswinbank/sshd",
+                "star_count": 0
+            },
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "vgauthier/sshd",
+                "star_count": 0
+            }
+    ...
+    ]
+
+**Query parameters**:
+
+-   **term** – term to search
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+### 2.3 Misc
+
+#### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+    POST /v1.21/auth HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "username": "hannibal",
+         "password": "xxxx",
+         "email": "hannibal@a-team.com",
+         "serveraddress": "https://index.docker.io/v1/"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+#### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+    GET /v1.21/info HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+        "ClusterStore": "etcd://localhost:2379",
+        "Containers": 11,
+        "CpuCfsPeriod": true,
+        "CpuCfsQuota": true,
+        "Debug": false,
+        "DockerRootDir": "/var/lib/docker",
+        "Driver": "btrfs",
+        "DriverStatus": [[""]],
+        "ExecutionDriver": "native-0.1",
+        "ExperimentalBuild": false,
+        "HttpProxy": "http://test:test@localhost:8080",
+        "HttpsProxy": "https://test:test@localhost:8080",
+        "ID": "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS",
+        "IPv4Forwarding": true,
+        "Images": 16,
+        "IndexServerAddress": "https://index.docker.io/v1/",
+        "InitPath": "/usr/bin/docker",
+        "InitSha1": "",
+        "KernelVersion": "3.12.0-1-amd64",
+        "Labels": [
+            "storage=ssd"
+        ],
+        "MemTotal": 2099236864,
+        "MemoryLimit": true,
+        "NCPU": 1,
+        "NEventsListener": 0,
+        "NFd": 11,
+        "NGoroutines": 21,
+        "Name": "prod-server-42",
+        "NoProxy": "9.81.1.160",
+        "OomKillDisable": true,
+        "OperatingSystem": "Boot2Docker",
+        "RegistryConfig": {
+            "IndexConfigs": {
+                "docker.io": {
+                    "Mirrors": null,
+                    "Name": "docker.io",
+                    "Official": true,
+                    "Secure": true
+                }
+            },
+            "InsecureRegistryCIDRs": [
+                "127.0.0.0/8"
+            ]
+        },
+        "ServerVersion": "1.9.0",
+        "SwapLimit": false,
+        "SystemTime": "2015-03-10T11:11:23.730591467-07:00"
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+    GET /v1.21/version HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+         "Version": "1.5.0",
+         "Os": "linux",
+         "KernelVersion": "3.18.5-tinycore64",
+         "GoVersion": "go1.4.1",
+         "GitCommit": "a8a31ef",
+         "Arch": "amd64",
+         "ApiVersion": "1.20",
+         "Experimental": false
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+    GET /v1.21/_ping HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: text/plain
+
+    OK
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+    POST /v1.21/commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Hostname": "",
+         "Domainname": "",
+         "User": "",
+         "AttachStdin": false,
+         "AttachStdout": true,
+         "AttachStderr": true,
+         "Tty": false,
+         "OpenStdin": false,
+         "StdinOnce": false,
+         "Env": null,
+         "Cmd": [
+                 "date"
+         ],
+         "Mounts": [
+           {
+             "Source": "/data",
+             "Destination": "/data",
+             "Mode": "ro,Z",
+             "RW": false
+           }
+         ],
+         "Labels": {
+                 "key1": "value1",
+                 "key2": "value2"
+          },
+         "WorkingDir": "",
+         "NetworkDisabled": false,
+         "ExposedPorts": {
+                 "22/tcp": {}
+         }
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {"Id": "596069db4bf5"}
+
+**JSON parameters**:
+
+-  **config** - the container's configuration
+
+**Query parameters**:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+-   **pause** – 1/True/true or 0/False/false, whether to pause the container before committing
+-   **changes** – Dockerfile instructions to apply while committing
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, in real time via streaming.
+
+Docker containers report the following events:
+
+    attach, commit, copy, create, destroy, die, exec_create, exec_start, export, kill, oom, pause, rename, resize, restart, start, stop, top, unpause
+
+Docker images report the following events:
+
+    delete, import, pull, push, tag, untag
+
+**Example request**:
+
+    GET /v1.21/events?since=1374067924
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status":"pull","id":"busybox:latest","time":1442421700,"timeNano":1442421700598988358}
+    {"status":"create","id":"5745704abe9caa5","from":"busybox","time":1442421716,"timeNano":1442421716853979870}
+    {"status":"attach","id":"5745704abe9caa5","from":"busybox","time":1442421716,"timeNano":1442421716894759198}
+    {"status":"start","id":"5745704abe9caa5","from":"busybox","time":1442421716,"timeNano":1442421716983607193}
+
+**Query parameters**:
+
+-   **since** – Timestamp. Show all events created since timestamp and then stream
+-   **until** – Timestamp. Show events created until given timestamp and stop streaming
+-   **filters** – A json encoded value of the filters (a map[string][]string) to process on the event list. Available filters:
+  -   `container=<string>`; -- container to filter
+  -   `event=<string>`; -- event to filter
+  -   `image=<string>`; -- image to filter
+  -   `label=<string>`; -- image and container label to filter
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository specified
+by `name`.
+
+If `name` is a specific name and tag (e.g. ubuntu:latest), then only that image
+(and its parents) are returned. If `name` is an image ID, similarly only that
+image (and its parents) are returned, but with the exclusion of the
+'repositories' file in the tarball, as there were no image names referenced.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.21/images/ubuntu/get
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images
+
+`GET /images/get`
+
+Get a tarball containing all images and metadata for one or more repositories.
+
+For each value of the `names` parameter: if it is a specific name and tag (e.g.
+`ubuntu:latest`), then only that image (and its parents) are returned; if it is
+an image ID, similarly only that image (and its parents) are returned and there
+would be no names referenced in the 'repositories' file for this image ID.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.21/images/get?names=myname%2Fmyapp%3Alatest&names=busybox
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into a Docker repository.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    POST /v1.21/images/load
+    Content-Type: application/x-tar
+    Content-Length: 12345
+
+    Tarball in body
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing these files:
+
+- `VERSION`: currently `1.0` - the file format version
+- `json`: detailed layer information, similar to `docker inspect layer_id`
+- `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file contains `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, the tarball should also include a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+#### Exec Create
+
+`POST /containers/(id or name)/exec`
+
+Sets up an exec instance in a running container `id`
+
+**Example request**:
+
+    POST /v1.21/containers/e90e34656806/exec HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+      "AttachStdin": true,
+      "AttachStdout": true,
+      "AttachStderr": true,
+      "Cmd": ["sh"],
+      "Privileged": true,
+      "Tty": true,
+      "User": "123:456"
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {
+         "Id": "f90e34656806",
+         "Warnings":[]
+    }
+
+**JSON parameters**:
+
+-   **AttachStdin** - Boolean value, attaches to `stdin` of the `exec` command.
+-   **AttachStdout** - Boolean value, attaches to `stdout` of the `exec` command.
+-   **AttachStderr** - Boolean value, attaches to `stderr` of the `exec` command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Privileged** - Boolean value, runs the exec process with extended privileges.
+-   **User** - A string value specifying the user, and optionally, group to run
+        the exec process inside the container. Format is one of: `"user"`,
+        `"user:group"`, `"uid"`, or `"uid:gid"`.
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+-   **409** - container is paused
+-   **500** - server error
+
+#### Exec Start
+
+`POST /exec/(id)/start`
+
+Starts a previously set up `exec` instance `id`. If `detach` is true, this API
+returns after starting the `exec` command. Otherwise, this API sets up an
+interactive session with the `exec` command.
+
+**Example request**:
+
+    POST /v1.21/exec/e90e34656806/start HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+     "Detach": false,
+     "Tty": false
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/vnd.docker.raw-stream
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**JSON parameters**:
+
+-   **Detach** - Detach from the `exec` command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+-   **409** - container is paused
+
+**Stream details**:
+
+Similar to the stream behavior of `POST /containers/(id or name)/attach` API
+
+#### Exec Resize
+
+`POST /exec/(id)/resize`
+
+Resizes the `tty` session used by the `exec` command `id`.  The unit is number of characters.
+This API is valid only if `tty` was specified as part of creating and starting the `exec` command.
+
+**Example request**:
+
+    POST /v1.21/exec/e90e34656806/resize?h=40&w=80 HTTP/1.1
+    Content-Type: text/plain
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: text/plain
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such exec instance
+
+#### Exec Inspect
+
+`GET /exec/(id)/json`
+
+Return low-level information about the `exec` command `id`.
+
+**Example request**:
+
+    GET /v1.21/exec/11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: plain/text
+
+    {
+      "ID" : "11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39",
+      "Running" : false,
+      "ExitCode" : 2,
+      "ProcessConfig" : {
+        "privileged" : false,
+        "user" : "",
+        "tty" : false,
+        "entrypoint" : "sh",
+        "arguments" : [
+          "-c",
+          "exit 2"
+        ]
+      },
+      "OpenStdin" : false,
+      "OpenStderr" : false,
+      "OpenStdout" : false,
+      "Container" : {
+        "State" : {
+          "Status" : "running",
+          "Running" : true,
+          "Paused" : false,
+          "Restarting" : false,
+          "OOMKilled" : false,
+          "Pid" : 3650,
+          "ExitCode" : 0,
+          "Error" : "",
+          "StartedAt" : "2014-11-17T22:26:03.717657531Z",
+          "FinishedAt" : "0001-01-01T00:00:00Z"
+        },
+        "ID" : "8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c",
+        "Created" : "2014-11-17T22:26:03.626304998Z",
+        "Path" : "date",
+        "Args" : [],
+        "Config" : {
+          "Hostname" : "8f177a186b97",
+          "Domainname" : "",
+          "User" : "",
+          "AttachStdin" : false,
+          "AttachStdout" : false,
+          "AttachStderr" : false,
+          "ExposedPorts" : null,
+          "Tty" : false,
+          "OpenStdin" : false,
+          "StdinOnce" : false,
+          "Env" : [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ],
+          "Cmd" : [
+            "date"
+          ],
+          "Image" : "ubuntu",
+          "Volumes" : null,
+          "WorkingDir" : "",
+          "Entrypoint" : null,
+          "NetworkDisabled" : false,
+          "MacAddress" : "",
+          "OnBuild" : null,
+          "SecurityOpt" : null
+        },
+        "Image" : "5506de2b643be1e6febbf3b8a240760c6843244c41e12aa2f60ccbb7153d17f5",
+        "NetworkSettings" : {
+          "Bridge": "",
+          "SandboxID": "",
+          "HairpinMode": false,
+          "LinkLocalIPv6Address": "",
+          "LinkLocalIPv6PrefixLen": 0,
+          "Ports": null,
+          "SandboxKey": "",
+          "SecondaryIPAddresses": null,
+          "SecondaryIPv6Addresses": null,
+          "EndpointID": "",
+          "Gateway": "",
+          "GlobalIPv6Address": "",
+          "GlobalIPv6PrefixLen": 0,
+          "IPAddress": "",
+          "IPPrefixLen": 0,
+          "IPv6Gateway": "",
+          "MacAddress": "",
+          "Networks": {
+            "bridge": {
+              "EndpointID": "",
+              "Gateway": "",
+              "IPAddress": "",
+              "IPPrefixLen": 0,
+              "IPv6Gateway": "",
+              "GlobalIPv6Address": "",
+              "GlobalIPv6PrefixLen": 0,
+              "MacAddress": ""
+            }
+          }
+        },
+        "ResolvConfPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/resolv.conf",
+        "HostnamePath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hostname",
+        "HostsPath" : "/var/lib/docker/containers/8f177a186b977fb451136e0fdf182abff5599a08b3c7f6ef0d36a55aaf89634c/hosts",
+        "LogPath": "/var/lib/docker/containers/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b-json.log",
+        "Name" : "/test",
+        "Driver" : "aufs",
+        "ExecDriver" : "native-0.2",
+        "MountLabel" : "",
+        "ProcessLabel" : "",
+        "AppArmorProfile" : "",
+        "RestartCount" : 0,
+        "Mounts" : []
+      }
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+-   **500** - server error
+
+### 2.4 Volumes
+
+#### List volumes
+
+`GET /volumes`
+
+**Example request**:
+
+    GET /v1.21/volumes HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Volumes": [
+        {
+          "Name": "tardis",
+          "Driver": "local",
+          "Mountpoint": "/var/lib/docker/volumes/tardis"
+        }
+      ]
+    }
+
+**Query parameters**:
+
+- **filters** - JSON encoded value of the filters (a `map[string][]string`) to process on the volumes list. There is one available filter: `dangling=true`
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Create a volume
+
+`POST /volumes/create`
+
+Create a volume
+
+**Example request**:
+
+    POST /v1.21/volumes/create HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+      "Name": "tardis"
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {
+      "Name": "tardis",
+      "Driver": "local",
+      "Mountpoint": "/var/lib/docker/volumes/tardis"
+    }
+
+**Status codes**:
+
+- **201** - no error
+- **500**  - server error
+
+**JSON parameters**:
+
+- **Name** - The new volume's name. If not specified, Docker generates a name.
+- **Driver** - Name of the volume driver to use. Defaults to `local` for the name.
+- **DriverOpts** - A mapping of driver options and values. These options are
+    passed directly to the driver and are driver specific.
+
+#### Inspect a volume
+
+`GET /volumes/(name)`
+
+Return low-level information on the volume `name`
+
+**Example request**:
+
+    GET /volumes/tardis
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Name": "tardis",
+      "Driver": "local",
+      "Mountpoint": "/var/lib/docker/volumes/tardis"
+    }
+
+**Status codes**:
+
+-   **200** - no error
+-   **404** - no such volume
+-   **500** - server error
+
+#### Remove a volume
+
+`DELETE /volumes/(name)`
+
+Instruct the driver to remove the volume (`name`).
+
+**Example request**:
+
+    DELETE /v1.21/volumes/tardis HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** - no error
+-   **404** - no such volume or volume driver
+-   **409** - volume is in use and cannot be removed
+-   **500** - server error
+
+### 2.5 Networks
+
+#### List networks
+
+`GET /networks`
+
+**Example request**:
+
+    GET /v1.21/networks HTTP/1.1
+
+**Example response**:
+
+```
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+[
+  {
+    "Name": "bridge",
+    "Id": "f2de39df4171b0dc801e8002d1d999b77256983dfc63041c0f34030aa3977566",
+    "Scope": "local",
+    "Driver": "bridge",
+    "IPAM": {
+      "Driver": "default",
+      "Config": [
+        {
+          "Subnet": "172.17.0.0/16"
+        }
+      ]
+    },
+    "Containers": {
+      "39b69226f9d79f5634485fb236a23b2fe4e96a0a94128390a7fbbcc167065867": {
+        "EndpointID": "ed2419a97c1d9954d05b46e462e7002ea552f216e9b136b80a7db8d98b442eda",
+        "MacAddress": "02:42:ac:11:00:02",
+        "IPv4Address": "172.17.0.2/16",
+        "IPv6Address": ""
+      }
+    },
+    "Options": {
+      "com.docker.network.bridge.default_bridge": "true",
+      "com.docker.network.bridge.enable_icc": "true",
+      "com.docker.network.bridge.enable_ip_masquerade": "true",
+      "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
+      "com.docker.network.bridge.name": "docker0",
+      "com.docker.network.driver.mtu": "1500"
+    }
+  },
+  {
+    "Name": "none",
+    "Id": "e086a3893b05ab69242d3c44e49483a3bbbd3a26b46baa8f61ab797c1088d794",
+    "Scope": "local",
+    "Driver": "null",
+    "IPAM": {
+      "Driver": "default",
+      "Config": []
+    },
+    "Containers": {},
+    "Options": {}
+  },
+  {
+    "Name": "host",
+    "Id": "13e871235c677f196c4e1ecebb9dc733b9b2d2ab589e30c539efeda84a24215e",
+    "Scope": "local",
+    "Driver": "host",
+    "IPAM": {
+      "Driver": "default",
+      "Config": []
+    },
+    "Containers": {},
+    "Options": {}
+  }
+]
+```
+
+**Query parameters**:
+
+- **filters** - JSON encoded value of the filters (a `map[string][]string`) to process on the networks list. Available filters: `name=[network-names]` , `id=[network-ids]`
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Inspect network
+
+`GET /networks/(id or name)`
+
+Return low-level information on the network `id`
+
+**Example request**:
+
+    GET /v1.21/networks/f2de39df4171b0dc801e8002d1d999b77256983dfc63041c0f34030aa3977566 HTTP/1.1
+
+**Example response**:
+
+```
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+{
+  "Name": "bridge",
+  "Id": "f2de39df4171b0dc801e8002d1d999b77256983dfc63041c0f34030aa3977566",
+  "Scope": "local",
+  "Driver": "bridge",
+  "IPAM": {
+    "Driver": "default",
+    "Config": [
+      {
+        "Subnet": "172.17.0.0/16"
+      }
+    ]
+  },
+  "Containers": {
+    "39b69226f9d79f5634485fb236a23b2fe4e96a0a94128390a7fbbcc167065867": {
+      "EndpointID": "ed2419a97c1d9954d05b46e462e7002ea552f216e9b136b80a7db8d98b442eda",
+      "MacAddress": "02:42:ac:11:00:02",
+      "IPv4Address": "172.17.0.2/16",
+      "IPv6Address": ""
+    }
+  },
+  "Options": {
+    "com.docker.network.bridge.default_bridge": "true",
+    "com.docker.network.bridge.enable_icc": "true",
+    "com.docker.network.bridge.enable_ip_masquerade": "true",
+    "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
+    "com.docker.network.bridge.name": "docker0",
+    "com.docker.network.driver.mtu": "1500"
+  }
+}
+```
+
+**Status codes**:
+
+-   **200** - no error
+-   **404** - network not found
+-   **500** - server error
+
+#### Create a network
+
+`POST /networks/create`
+
+Create a network
+
+**Example request**:
+
+```
+POST /v1.21/networks/create HTTP/1.1
+Content-Type: application/json
+Content-Length: 12345
+
+{
+  "Name":"isolated_nw",
+  "CheckDuplicate":true,
+  "Driver":"bridge",
+  "IPAM":{
+    "Driver": "default",
+    "Config":[
+      {
+        "Subnet":"172.20.0.0/16",
+        "IPRange":"172.20.10.0/24",
+        "Gateway":"172.20.10.11"
+      }
+    ]
+  }
+}
+```
+
+**Example response**:
+
+```
+HTTP/1.1 201 Created
+Content-Type: application/json
+
+{
+  "Id": "22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30",
+  "Warning": ""
+}
+```
+
+**Status codes**:
+
+- **201** - no error
+- **404** - plugin not found
+- **500** - server error
+
+**JSON parameters**:
+
+- **Name** - The new network's name. this is a mandatory field
+- **CheckDuplicate** - Requests daemon to check for networks with same name. Defaults to `false`.
+    Since Network is primarily keyed based on a random ID and not on the name, 
+    and network name is strictly a user-friendly alias to the network which is uniquely identified using ID, 
+    there is no guaranteed way to check for duplicates across a cluster of docker hosts. 
+    This parameter CheckDuplicate is there to provide a best effort checking of any networks 
+    which has the same name but it is not guaranteed to catch all name collisions.
+- **Driver** - Name of the network driver plugin to use. Defaults to `bridge` driver
+- **IPAM** - Optional custom IP scheme for the network
+  - **Driver** - Name of the IPAM driver to use. Defaults to `default` driver
+  - **Config** - List of IPAM configuration options, specified as a map:
+      `{"Subnet": <CIDR>, "IPRange": <CIDR>, "Gateway": <IP address>, "AuxAddress": <device_name:IP address>}`
+- **Options** - Network specific options to be used by the drivers
+
+#### Connect a container to a network
+
+`POST /networks/(id or name)/connect`
+
+Connect a container to a network
+
+**Example request**:
+
+```
+POST /v1.21/networks/22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30/connect HTTP/1.1
+Content-Type: application/json
+Content-Length: 12345
+
+{
+  "Container":"3613f73ba0e4"
+}
+```
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+- **200** - no error
+- **404** - network or container is not found
+- **500** - Internal Server Error
+
+**JSON parameters**:
+
+- **container** - container-id/name to be connected to the network
+
+#### Disconnect a container from a network
+
+`POST /networks/(id or name)/disconnect`
+
+Disconnect a container from a network
+
+**Example request**:
+
+```
+POST /v1.21/networks/22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30/disconnect HTTP/1.1
+Content-Type: application/json
+Content-Length: 12345
+
+{
+  "Container":"3613f73ba0e4"
+}
+```
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+- **200** - no error
+- **404** - network or container not found
+- **500** - Internal Server Error
+
+**JSON parameters**:
+
+- **Container** - container-id/name to be disconnected from a network
+
+#### Remove a network
+
+`DELETE /networks/(id or name)`
+
+Instruct the driver to remove the network (`id`).
+
+**Example request**:
+
+    DELETE /v1.21/networks/22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** - no error
+-   **403** - operation not supported for pre-defined networks
+-   **404** - no such network
+-   **500** - server error
+
+## 3. Going further
+
+### 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it.
+    - Then, retry to create the container.
+
+- Start the container.
+
+- If you are not in detached mode:
+- Attach to the container, using `logs=1` (to have `stdout` and
+      `stderr` from the container's start) and `stream=1`
+
+- If in detached mode or only `stdin` is attached, display the container's id.
+
+### 3.2 Hijacking
+
+In this version of the API, `/attach`, uses hijacking to transport `stdin`,
+`stdout`, and `stderr` on the same socket.
+
+To hint potential proxies about connection hijacking, Docker client sends
+connection upgrade headers similarly to websocket.
+
+    Upgrade: tcp
+    Connection: Upgrade
+
+When Docker daemon detects the `Upgrade` header, it switches its status code
+from **200 OK** to **101 UPGRADED** and resends the same headers.
+
+
+### 3.3 CORS Requests
+
+To set cross origin requests to the Engine API please give values to
+`--api-cors-header` when running Docker in daemon mode. Set * (asterisk) allows all,
+default or blank means CORS disabled
+
+    $ dockerd -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.22.md b/_vendor/github.com/moby/moby/api/docs/v1.22.md
new file mode 100644
index 000000000000..4f099624d69f
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.22.md
@@ -0,0 +1,3336 @@
+---
+title: "Engine API v1.22"
+description: "API Documentation for Docker"
+keywords: "API, Docker, rcli, REST, documentation"
+aliases:
+- /engine/reference/api/docker_remote_api_v1.22/
+- /reference/api/docker_remote_api_v1.22/
+---
+
+<!-- This file is maintained within the moby/moby GitHub
+     repository at https://github.com/moby/moby/. Make all
+     pull requests against that repo. If you see this file in
+     another repository, consider it read-only there, as it will
+     periodically be overwritten by the definitive file. Pull
+     requests which include edits to this file in other repositories
+     will be rejected.
+-->
+
+## 1. Brief introduction
+
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](https://docs.docker.com/engine/reference/commandline/dockerd/#bind-docker-to-another-host-port-or-a-unix-socket).
+ - The API tends to be REST. However, for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `stdout`,
+   `stdin` and `stderr`.
+ - A `Content-Length` header should be present in `POST` requests to endpoints
+   that expect a body.
+ - To lock to a specific version of the API, you prefix the URL with the version
+   of the API to use. For example, `/v1.18/info`. If no version is included in
+   the URL, the maximum supported API version is used.
+ - If the API version specified in the URL is not supported by the daemon, a HTTP
+   `400 Bad Request` error message is returned.
+
+## 2. Endpoints
+
+### 2.1 Containers
+
+#### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+    GET /v1.22/containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Id": "8dfafdbc3a40",
+                 "Names":["/boring_feynman"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 1",
+                 "Created": 1367854155,
+                 "Status": "Exit 0",
+                 "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                 "Labels": {
+                         "com.example.vendor": "Acme",
+                         "com.example.license": "GPL",
+                         "com.example.version": "1.0"
+                 },
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0,
+                 "HostConfig": {
+                         "NetworkMode": "default"
+                 },
+                 "NetworkSettings": {
+                         "Networks": {
+                                 "bridge": {
+                                          "IPAMConfig": null,
+                                          "Links": null,
+                                          "Aliases": null,
+                                          "NetworkID": "7ea29fc1412292a2d7bba362f9253545fecdfa8ce9a6e37dd10ba8bee7129812",
+                                          "EndpointID": "2cdc4edb1ded3631c81f57966563e5c8525b81121bb3706a9a9a3ae102711f3f",
+                                          "Gateway": "172.17.0.1",
+                                          "IPAddress": "172.17.0.2",
+                                          "IPPrefixLen": 16,
+                                          "IPv6Gateway": "",
+                                          "GlobalIPv6Address": "",
+                                          "GlobalIPv6PrefixLen": 0,
+                                          "MacAddress": "02:42:ac:11:00:02"
+                                  }
+                         }
+                 }
+         },
+         {
+                 "Id": "9cd87474be90",
+                 "Names":["/coolName"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 222222",
+                 "Created": 1367854155,
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0,
+                 "HostConfig": {
+                         "NetworkMode": "default"
+                 },
+                 "NetworkSettings": {
+                         "Networks": {
+                                 "bridge": {
+                                          "IPAMConfig": null,
+                                          "Links": null,
+                                          "Aliases": null,
+                                          "NetworkID": "7ea29fc1412292a2d7bba362f9253545fecdfa8ce9a6e37dd10ba8bee7129812",
+                                          "EndpointID": "88eaed7b37b38c2a3f0c4bc796494fdf51b270c2d22656412a2ca5d559a64d7a",
+                                          "Gateway": "172.17.0.1",
+                                          "IPAddress": "172.17.0.8",
+                                          "IPPrefixLen": 16,
+                                          "IPv6Gateway": "",
+                                          "GlobalIPv6Address": "",
+                                          "GlobalIPv6PrefixLen": 0,
+                                          "MacAddress": "02:42:ac:11:00:08"
+                                  }
+                         }
+                 }
+         },
+         {
+                 "Id": "3176a2479c92",
+                 "Names":["/sleepy_dog"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 3333333333333333",
+                 "Created": 1367854154,
+                 "Status": "Exit 0",
+                 "Ports":[],
+                 "Labels": {},
+                 "SizeRw":12288,
+                 "SizeRootFs":0,
+                 "HostConfig": {
+                         "NetworkMode": "default"
+                 },
+                 "NetworkSettings": {
+                         "Networks": {
+                                 "bridge": {
+                                          "IPAMConfig": null,
+                                          "Links": null,
+                                          "Aliases": null,
+                                          "NetworkID": "7ea29fc1412292a2d7bba362f9253545fecdfa8ce9a6e37dd10ba8bee7129812",
+                                          "EndpointID": "8b27c041c30326d59cd6e6f510d4f8d1d570a228466f956edf7815508f78e30d",
+                                          "Gateway": "172.17.0.1",
+                                          "IPAddress": "172.17.0.6",
+                                          "IPPrefixLen": 16,
+                                          "IPv6Gateway": "",
+                                          "GlobalIPv6Address": "",
+                                          "GlobalIPv6PrefixLen": 0,
+                                          "MacAddress": "02:42:ac:11:00:06"
+                                  }
+                         }
+                 }
+         },
+         {
+                 "Id": "4cb07b47f9fb",
+                 "Names":["/running_cat"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 444444444444444444444444444444444",
+                 "Created": 1367854152,
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0,
+                 "HostConfig": {
+                         "NetworkMode": "default"
+                 },
+                 "NetworkSettings": {
+                         "Networks": {
+                                 "bridge": {
+                                          "IPAMConfig": null,
+                                          "Links": null,
+                                          "Aliases": null,
+                                          "NetworkID": "7ea29fc1412292a2d7bba362f9253545fecdfa8ce9a6e37dd10ba8bee7129812",
+                                          "EndpointID": "d91c7b2f0644403d7ef3095985ea0e2370325cd2332ff3a3225c4247328e66e9",
+                                          "Gateway": "172.17.0.1",
+                                          "IPAddress": "172.17.0.5",
+                                          "IPPrefixLen": 16,
+                                          "IPv6Gateway": "",
+                                          "GlobalIPv6Address": "",
+                                          "GlobalIPv6PrefixLen": 0,
+                                          "MacAddress": "02:42:ac:11:00:05"
+                                  }
+                         }
+                 }
+         }
+    ]
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers
+        sizes
+-   **filters** - a JSON encoded value of the filters (a `map[string][]string`) to process on the containers list. Available filters:
+  -   `exited=<int>`; -- containers with exit code of  `<int>` ;
+  -   `status=`(`created`|`restarting`|`running`|`paused`|`exited`|`dead`)
+  -   `label=key` or `label="key=value"` of a container label
+  -   `isolation=`(`default`|`process`|`hyperv`)   (Windows daemon only)
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+#### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+    POST /v1.22/containers/create HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+           "Hostname": "",
+           "Domainname": "",
+           "User": "",
+           "AttachStdin": false,
+           "AttachStdout": true,
+           "AttachStderr": true,
+           "Tty": false,
+           "OpenStdin": false,
+           "StdinOnce": false,
+           "Env": [
+                   "FOO=bar",
+                   "BAZ=quux"
+           ],
+           "Cmd": [
+                   "date"
+           ],
+           "Entrypoint": null,
+           "Image": "ubuntu",
+           "Labels": {
+                   "com.example.vendor": "Acme",
+                   "com.example.license": "GPL",
+                   "com.example.version": "1.0"
+           },
+           "Volumes": {
+             "/volumes/data": {}
+           },
+           "WorkingDir": "",
+           "NetworkDisabled": false,
+           "MacAddress": "12:34:56:78:9a:bc",
+           "ExposedPorts": {
+                   "22/tcp": {}
+           },
+           "StopSignal": "SIGTERM",
+           "HostConfig": {
+             "Binds": ["/tmp:/tmp"],
+             "Tmpfs": { "/run": "rw,noexec,nosuid,size=65536k" },
+             "Links": ["redis3:redis"],
+             "Memory": 0,
+             "MemorySwap": 0,
+             "MemoryReservation": 0,
+             "KernelMemory": 0,
+             "CpuShares": 512,
+             "CpuPeriod": 100000,
+             "CpuQuota": 50000,
+             "CpusetCpus": "0,1",
+             "CpusetMems": "0,1",
+             "BlkioWeight": 300,
+             "BlkioWeightDevice": [{}],
+             "BlkioDeviceReadBps": [{}],
+             "BlkioDeviceReadIOps": [{}],
+             "BlkioDeviceWriteBps": [{}],
+             "BlkioDeviceWriteIOps": [{}],
+             "MemorySwappiness": 60,
+             "OomKillDisable": false,
+             "OomScoreAdj": 500,
+             "PidMode": "",
+             "PortBindings": { "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts": false,
+             "Privileged": false,
+             "ReadonlyRootfs": false,
+             "Dns": ["8.8.8.8"],
+             "DnsOptions": [""],
+             "DnsSearch": [""],
+             "ExtraHosts": null,
+             "VolumesFrom": ["parent", "other:ro"],
+             "CapAdd": ["NET_ADMIN"],
+             "CapDrop": ["MKNOD"],
+             "GroupAdd": ["newgroup"],
+             "RestartPolicy": { "Name": "", "MaximumRetryCount": 0 },
+             "NetworkMode": "bridge",
+             "Devices": [],
+             "Ulimits": [{}],
+             "LogConfig": { "Type": "json-file", "Config": {} },
+             "SecurityOpt": [],
+             "CgroupParent": "",
+             "VolumeDriver": "",
+             "ShmSize": 67108864
+          },
+          "NetworkingConfig": {
+              "EndpointsConfig": {
+                  "isolated_nw" : {
+                      "IPAMConfig": {
+                          "IPv4Address":"172.20.30.33",
+                          "IPv6Address":"2001:db8:abcd::3033"
+                      },
+                      "Links":["container_1", "container_2"],
+                      "Aliases":["server_x", "server_y"]
+                  }
+              }
+          }
+      }
+
+**Example response**:
+
+      HTTP/1.1 201 Created
+      Content-Type: application/json
+
+      {
+           "Id":"e90e34656806",
+           "Warnings":[]
+      }
+
+**JSON parameters**:
+
+-   **Hostname** - A string value containing the hostname to use for the
+      container.
+-   **Domainname** - A string value containing the domain name to use
+      for the container.
+-   **User** - A string value specifying the user inside the container.
+-   **AttachStdin** - Boolean value, attaches to `stdin`.
+-   **AttachStdout** - Boolean value, attaches to `stdout`.
+-   **AttachStderr** - Boolean value, attaches to `stderr`.
+-   **Tty** - Boolean value, Attach standard streams to a `tty`, including `stdin` if it is not closed.
+-   **OpenStdin** - Boolean value, opens `stdin`,
+-   **StdinOnce** - Boolean value, close `stdin` after the 1 attached client disconnects.
+-   **Env** - A list of environment variables in the form of `["VAR=value", ...]`
+-   **Labels** - Adds a map of labels to a container. To specify a map: `{"key":"value", ... }`
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Entrypoint** - Set the entry point for the container as a string or an array
+      of strings.
+-   **Image** - A string specifying the image name to use for the container.
+-   **Volumes** - An object mapping mount point paths (strings) inside the
+      container to empty objects.
+-   **WorkingDir** - A string specifying the working directory for commands to
+      run in.
+-   **NetworkDisabled** - Boolean value, when true disables networking for the
+      container
+-   **ExposedPorts** - An object mapping ports to an empty object in the form of:
+      `"ExposedPorts": { "<port>/<tcp|udp>: {}" }`
+-   **StopSignal** - Signal to stop a container as a string or unsigned integer. `SIGTERM` by default.
+-   **HostConfig**
+    -   **Binds** – A list of volume bindings for this container. Each volume binding is a string in one of these forms:
+           + `host-src:container-dest` to bind-mount a host path into the
+             container. Both `host-src`, and `container-dest` must be an
+             _absolute_ path.
+           + `host-src:container-dest:ro` to make the bind mount read-only
+             inside the container. Both `host-src`, and `container-dest` must be
+             an _absolute_ path.
+           + `volume-name:container-dest` to bind-mount a volume managed by a
+             volume driver into the container. `container-dest` must be an
+             _absolute_ path.
+           + `volume-name:container-dest:ro` to mount the volume read-only
+             inside the container.  `container-dest` must be an _absolute_ path.
+    -   **Tmpfs** – A map of container directories which should be replaced by tmpfs mounts, and their corresponding
+          mount options. A JSON object in the form `{ "/run": "rw,noexec,nosuid,size=65536k" }`.
+    -   **Links** - A list of links for the container. Each link entry should be
+          in the form of `container_name:alias`.
+    -   **Memory** - Memory limit in bytes.
+    -   **MemorySwap** - Total memory limit (memory + swap); set `-1` to enable unlimited swap.
+          You must use this with `memory` and make the swap value larger than `memory`.
+    -   **MemoryReservation** - Memory soft limit in bytes.
+    -   **KernelMemory** - Kernel memory limit in bytes.
+    -   **CpuShares** - An integer value containing the container's CPU Shares
+          (ie. the relative weight vs other containers).
+    -   **CpuPeriod** - The length of a CPU period in microseconds.
+    -   **CpuQuota** - Microseconds of CPU time that the container can get in a CPU period.
+    -   **CpusetCpus** - String value containing the `cgroups CpusetCpus` to use.
+    -   **CpusetMems** - Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
+    -   **BlkioWeight** - Block IO weight (relative weight) accepts a weight value between 10 and 1000.
+    -   **BlkioWeightDevice** - Block IO weight (relative device weight) in the form of:        `"BlkioWeightDevice": [{"Path": "device_path", "Weight": weight}]`
+    -   **BlkioDeviceReadBps** - Limit read rate (bytes per second) from a device in the form of:	`"BlkioDeviceReadBps": [{"Path": "device_path", "Rate": rate}]`, for example:
+        `"BlkioDeviceReadBps": [{"Path": "/dev/sda", "Rate": "1024"}]"`
+    -   **BlkioDeviceWriteBps** - Limit write rate (bytes per second) to a device in the form of:	`"BlkioDeviceWriteBps": [{"Path": "device_path", "Rate": rate}]`, for example:
+        `"BlkioDeviceWriteBps": [{"Path": "/dev/sda", "Rate": "1024"}]"`
+    -   **BlkioDeviceReadIOps** - Limit read rate (IO per second) from a device in the form of:	`"BlkioDeviceReadIOps": [{"Path": "device_path", "Rate": rate}]`, for example:
+        `"BlkioDeviceReadIOps": [{"Path": "/dev/sda", "Rate": "1000"}]`
+    -   **BlkioDeviceWriteIOps** - Limit write rate (IO per second) to a device in the form of:	`"BlkioDeviceWriteIOps": [{"Path": "device_path", "Rate": rate}]`, for example:
+        `"BlkioDeviceWriteIOps": [{"Path": "/dev/sda", "Rate": "1000"}]`
+    -   **MemorySwappiness** - Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100.
+    -   **OomKillDisable** - Boolean value, whether to disable OOM Killer for the container or not.
+    -   **OomScoreAdj** - An integer value containing the score given to the container in order to tune OOM killer preferences.
+    -   **PidMode** - Set the PID (Process) Namespace mode for the container;
+          `"container:<name|id>"`: joins another container's PID namespace
+          `"host"`: use the host's PID namespace inside the container
+    -   **PortBindings** - A map of exposed container ports and the host port they
+          should map to. A JSON object in the form
+          `{ <port>/<protocol>: [{ "HostPort": "<port>" }] }`
+          Take note that `port` is specified as a string and not an integer value.
+    -   **PublishAllPorts** - Allocates an ephemeral host port for all of a container's
+          exposed ports. Specified as a boolean value.
+
+          Ports are de-allocated when the container stops and allocated when the container starts.
+          The allocated port might be changed when restarting the container.
+
+          The port is selected from the ephemeral port range that depends on the kernel.
+          For example, on Linux the range is defined by `/proc/sys/net/ipv4/ip_local_port_range`.
+    -   **Privileged** - Gives the container full access to the host. Specified as
+          a boolean value.
+    -   **ReadonlyRootfs** - Mount the container's root filesystem as read only.
+          Specified as a boolean value.
+    -   **Dns** - A list of DNS servers for the container to use.
+    -   **DnsOptions** - A list of DNS options
+    -   **DnsSearch** - A list of DNS search domains
+    -   **ExtraHosts** - A list of hostnames/IP mappings to add to the
+        container's `/etc/hosts` file. Specified in the form `["hostname:IP"]`.
+    -   **VolumesFrom** - A list of volumes to inherit from another container.
+          Specified in the form `<container name>[:<ro|rw>]`
+    -   **CapAdd** - A list of kernel capabilities to add to the container.
+    -   **Capdrop** - A list of kernel capabilities to drop from the container.
+    -   **GroupAdd** - A list of additional groups that the container process will run as
+    -   **RestartPolicy** – The behavior to apply when the container exits.  The
+            value is an object with a `Name` property of either `"always"` to
+            always restart, `"unless-stopped"` to restart always except when
+            user has manually stopped the container or `"on-failure"` to restart only when the container
+            exit code is non-zero.  If `on-failure` is used, `MaximumRetryCount`
+            controls the number of times to retry before giving up.
+            The default is not to restart. (optional)
+            An ever increasing delay (double the previous delay, starting at 100mS)
+            is added before each restart to prevent flooding the server.
+    -   **NetworkMode** - Sets the networking mode for the container. Supported
+          standard values are: `bridge`, `host`, `none`, and `container:<name|id>`. Any other value is taken
+          as a custom network's name to which this container should connect to.
+    -   **Devices** - A list of devices to add to the container specified as a JSON object in the
+      form
+          `{ "PathOnHost": "/dev/deviceName", "PathInContainer": "/dev/deviceName", "CgroupPermissions": "mrw"}`
+    -   **Ulimits** - A list of ulimits to set in the container, specified as
+          `{ "Name": <name>, "Soft": <soft limit>, "Hard": <hard limit> }`, for example:
+          `Ulimits: { "Name": "nofile", "Soft": 1024, "Hard": 2048 }`
+    -   **SecurityOpt**: A list of string values to customize labels for MLS
+        systems, such as SELinux.
+    -   **LogConfig** - Log configuration for the container, specified as a JSON object in the form
+          `{ "Type": "<driver_name>", "Config": {"key1": "val1"}}`.
+          Available types: `json-file`, `syslog`, `journald`, `gelf`, `awslogs`, `splunk`, `none`.
+          `json-file` logging driver.
+    -   **CgroupParent** - Path to `cgroups` under which the container's `cgroup` is created. If the path is not absolute, the path is considered to be relative to the `cgroups` path of the init process. Cgroups are created if they do not already exist.
+    -   **VolumeDriver** - Driver that this container users to mount volumes.
+    -   **ShmSize** - Size of `/dev/shm` in bytes. The size must be greater than 0.  If omitted the system uses 64MB.
+
+**Query parameters**:
+
+-   **name** – Assign the specified name to the container. Must
+    match `/?[a-zA-Z0-9_-]+`.
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **406** – impossible to attach (container not running)
+-   **409** – conflict
+-   **500** – server error
+
+#### Inspect a container
+
+`GET /containers/(id or name)/json`
+
+Return low-level information on the container `id`
+
+**Example request**:
+
+      GET /v1.22/containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+	{
+		"AppArmorProfile": "",
+		"Args": [
+			"-c",
+			"exit 9"
+		],
+		"Config": {
+			"AttachStderr": true,
+			"AttachStdin": false,
+			"AttachStdout": true,
+			"Cmd": [
+				"/bin/sh",
+				"-c",
+				"exit 9"
+			],
+			"Domainname": "",
+			"Entrypoint": null,
+			"Env": [
+				"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+			],
+			"ExposedPorts": null,
+			"Hostname": "ba033ac44011",
+			"Image": "ubuntu",
+			"Labels": {
+				"com.example.vendor": "Acme",
+				"com.example.license": "GPL",
+				"com.example.version": "1.0"
+			},
+			"MacAddress": "",
+			"NetworkDisabled": false,
+			"OnBuild": null,
+			"OpenStdin": false,
+			"StdinOnce": false,
+			"Tty": false,
+			"User": "",
+			"Volumes": {
+				"/volumes/data": {}
+			},
+			"WorkingDir": "",
+			"StopSignal": "SIGTERM"
+		},
+		"Created": "2015-01-06T15:47:31.485331387Z",
+		"Driver": "overlay2",
+		"ExecIDs": null,
+		"HostConfig": {
+			"Binds": null,
+			"BlkioWeight": 0,
+			"BlkioWeightDevice": [{}],
+			"BlkioDeviceReadBps": [{}],
+			"BlkioDeviceWriteBps": [{}],
+			"BlkioDeviceReadIOps": [{}],
+			"BlkioDeviceWriteIOps": [{}],
+			"CapAdd": null,
+			"CapDrop": null,
+			"ContainerIDFile": "",
+			"CpusetCpus": "",
+			"CpusetMems": "",
+			"CpuShares": 0,
+			"CpuPeriod": 100000,
+			"Devices": [],
+			"Dns": null,
+			"DnsOptions": null,
+			"DnsSearch": null,
+			"ExtraHosts": null,
+			"IpcMode": "",
+			"Links": null,
+			"Memory": 0,
+			"MemorySwap": 0,
+			"MemoryReservation": 0,
+			"KernelMemory": 0,
+			"OomKillDisable": false,
+			"OomScoreAdj": 500,
+			"NetworkMode": "bridge",
+			"PidMode": "",
+			"PortBindings": {},
+			"Privileged": false,
+			"ReadonlyRootfs": false,
+			"PublishAllPorts": false,
+			"RestartPolicy": {
+				"MaximumRetryCount": 2,
+				"Name": "on-failure"
+			},
+			"LogConfig": {
+				"Config": null,
+				"Type": "json-file"
+			},
+			"SecurityOpt": null,
+			"VolumesFrom": null,
+			"Ulimits": [{}],
+			"VolumeDriver": "",
+			"ShmSize": 67108864
+		},
+		"HostnamePath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hostname",
+		"HostsPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hosts",
+		"LogPath": "/var/lib/docker/containers/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b-json.log",
+		"Id": "ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39",
+		"Image": "04c5d3b7b0656168630d3ba35d8889bd0e9caafcaeb3004d2bfbc47e7c5d35d2",
+		"MountLabel": "",
+		"Name": "/boring_euclid",
+		"NetworkSettings": {
+			"Bridge": "",
+			"SandboxID": "",
+			"HairpinMode": false,
+			"LinkLocalIPv6Address": "",
+			"LinkLocalIPv6PrefixLen": 0,
+			"Ports": null,
+			"SandboxKey": "",
+			"SecondaryIPAddresses": null,
+			"SecondaryIPv6Addresses": null,
+			"EndpointID": "",
+			"Gateway": "",
+			"GlobalIPv6Address": "",
+			"GlobalIPv6PrefixLen": 0,
+			"IPAddress": "",
+			"IPPrefixLen": 0,
+			"IPv6Gateway": "",
+			"MacAddress": "",
+			"Networks": {
+				"bridge": {
+					"NetworkID": "7ea29fc1412292a2d7bba362f9253545fecdfa8ce9a6e37dd10ba8bee7129812",
+					"EndpointID": "7587b82f0dada3656fda26588aee72630c6fab1536d36e394b2bfbcf898c971d",
+					"Gateway": "172.17.0.1",
+					"IPAddress": "172.17.0.2",
+					"IPPrefixLen": 16,
+					"IPv6Gateway": "",
+					"GlobalIPv6Address": "",
+					"GlobalIPv6PrefixLen": 0,
+					"MacAddress": "02:42:ac:12:00:02"
+				}
+			}
+		},
+		"Path": "/bin/sh",
+		"ProcessLabel": "",
+		"ResolvConfPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/resolv.conf",
+		"RestartCount": 1,
+		"State": {
+			"Error": "",
+			"ExitCode": 9,
+			"FinishedAt": "2015-01-06T15:47:32.080254511Z",
+			"OOMKilled": false,
+			"Dead": false,
+			"Paused": false,
+			"Pid": 0,
+			"Restarting": false,
+			"Running": true,
+			"StartedAt": "2015-01-06T15:47:32.072697474Z",
+			"Status": "running"
+		},
+		"Mounts": [
+			{
+				"Name": "fac362...80535",
+				"Source": "/data",
+				"Destination": "/data",
+				"Driver": "local",
+				"Mode": "ro,Z",
+				"RW": false,
+				"Propagation": ""
+			}
+		]
+	}
+
+**Example request, with size information**:
+
+    GET /v1.22/containers/4fa6e0f0c678/json?size=1 HTTP/1.1
+
+**Example response, with size information**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+    ....
+    "SizeRw": 0,
+    "SizeRootFs": 972,
+    ....
+    }
+
+**Query parameters**:
+
+-   **size** – 1/True/true or 0/False/false, return container size information. Default is `false`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### List processes running inside a container
+
+`GET /containers/(id or name)/top`
+
+List processes running inside the container `id`. On Unix systems this
+is done by running the `ps` command. This endpoint is not
+supported on Windows.
+
+**Example request**:
+
+    GET /v1.22/containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Titles" : [
+         "UID", "PID", "PPID", "C", "STIME", "TTY", "TIME", "CMD"
+       ],
+       "Processes" : [
+         [
+           "root", "13642", "882", "0", "17:03", "pts/0", "00:00:00", "/bin/bash"
+         ],
+         [
+           "root", "13735", "13642", "0", "17:06", "pts/0", "00:00:00", "sleep 10"
+         ]
+       ]
+    }
+
+**Example request**:
+
+    GET /v1.22/containers/4fa6e0f0c678/top?ps_args=aux HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Titles" : [
+        "USER","PID","%CPU","%MEM","VSZ","RSS","TTY","STAT","START","TIME","COMMAND"
+      ]
+      "Processes" : [
+        [
+          "root","13642","0.0","0.1","18172","3184","pts/0","Ss","17:03","0:00","/bin/bash"
+        ],
+        [
+          "root","13895","0.0","0.0","4348","692","pts/0","S+","17:15","0:00","sleep 10"
+        ]
+      ],
+    }
+
+**Query parameters**:
+
+-   **ps_args** – `ps` arguments to use (e.g., `aux`), defaults to `-ef`
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container logs
+
+`GET /containers/(id or name)/logs`
+
+Get `stdout` and `stderr` logs from the container ``id``
+
+> **Note**:
+> This endpoint works only for containers with the `json-file` or `journald` logging drivers.
+
+**Example request**:
+
+     GET /v1.22/containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10&since=1428990821 HTTP/1.1
+
+**Example response**:
+
+     HTTP/1.1 101 UPGRADED
+     Content-Type: application/vnd.docker.raw-stream
+     Connection: Upgrade
+     Upgrade: tcp
+
+     {% raw %}
+     {{ STREAM }}
+     {% endraw %}
+
+**Query parameters**:
+
+-   **follow** – 1/True/true or 0/False/false, return stream. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, show `stdout` log. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, show `stderr` log. Default `false`.
+-   **since** – UNIX timestamp (integer) to filter logs. Specifying a timestamp
+    will only output log-entries since that timestamp. Default: 0 (unfiltered)
+-   **timestamps** – 1/True/true or 0/False/false, print timestamps for
+        every log line. Default `false`.
+-   **tail** – Output specified number of lines at the end of logs: `all` or `<number>`. Default all.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **404** – no such container
+-   **500** – server error
+
+#### Inspect changes on a container's filesystem
+
+`GET /containers/(id or name)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+    GET /v1.22/containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Path": "/dev",
+                 "Kind": 0
+         },
+         {
+                 "Path": "/dev/kmsg",
+                 "Kind": 1
+         },
+         {
+                 "Path": "/test",
+                 "Kind": 1
+         }
+    ]
+
+Values for `Kind`:
+
+- `0`: Modify
+- `1`: Add
+- `2`: Delete
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Export a container
+
+`GET /containers/(id or name)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+    GET /v1.22/containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/octet-stream
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container stats based on resource usage
+
+`GET /containers/(id or name)/stats`
+
+This endpoint returns a live stream of a container's resource usage statistics.
+
+**Example request**:
+
+    GET /v1.22/containers/redis1/stats HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Type: application/json
+
+      {
+         "read" : "2015-01-08T22:57:31.547920715Z",
+         "networks": {
+                 "eth0": {
+                     "rx_bytes": 5338,
+                     "rx_dropped": 0,
+                     "rx_errors": 0,
+                     "rx_packets": 36,
+                     "tx_bytes": 648,
+                     "tx_dropped": 0,
+                     "tx_errors": 0,
+                     "tx_packets": 8
+                 },
+                 "eth5": {
+                     "rx_bytes": 4641,
+                     "rx_dropped": 0,
+                     "rx_errors": 0,
+                     "rx_packets": 26,
+                     "tx_bytes": 690,
+                     "tx_dropped": 0,
+                     "tx_errors": 0,
+                     "tx_packets": 9
+                 }
+         },
+         "memory_stats" : {
+            "stats" : {
+               "total_pgmajfault" : 0,
+               "cache" : 0,
+               "mapped_file" : 0,
+               "total_inactive_file" : 0,
+               "pgpgout" : 414,
+               "rss" : 6537216,
+               "total_mapped_file" : 0,
+               "writeback" : 0,
+               "unevictable" : 0,
+               "pgpgin" : 477,
+               "total_unevictable" : 0,
+               "pgmajfault" : 0,
+               "total_rss" : 6537216,
+               "total_rss_huge" : 6291456,
+               "total_writeback" : 0,
+               "total_inactive_anon" : 0,
+               "rss_huge" : 6291456,
+               "hierarchical_memory_limit" : 67108864,
+               "total_pgfault" : 964,
+               "total_active_file" : 0,
+               "active_anon" : 6537216,
+               "total_active_anon" : 6537216,
+               "total_pgpgout" : 414,
+               "total_cache" : 0,
+               "inactive_anon" : 0,
+               "active_file" : 0,
+               "pgfault" : 964,
+               "inactive_file" : 0,
+               "total_pgpgin" : 477
+            },
+            "max_usage" : 6651904,
+            "usage" : 6537216,
+            "failcnt" : 0,
+            "limit" : 67108864
+         },
+         "blkio_stats" : {},
+         "cpu_stats" : {
+            "cpu_usage" : {
+               "percpu_usage" : [
+                  8646879,
+                  24472255,
+                  36438778,
+                  30657443
+               ],
+               "usage_in_usermode" : 50000000,
+               "total_usage" : 100215355,
+               "usage_in_kernelmode" : 30000000
+            },
+            "system_cpu_usage" : 739306590000000,
+            "throttling_data" : {"periods":0,"throttled_periods":0,"throttled_time":0}
+         },
+         "precpu_stats" : {
+            "cpu_usage" : {
+               "percpu_usage" : [
+                  8646879,
+                  24350896,
+                  36438778,
+                  30657443
+               ],
+               "usage_in_usermode" : 50000000,
+               "total_usage" : 100093996,
+               "usage_in_kernelmode" : 30000000
+            },
+            "system_cpu_usage" : 9492140000000,
+            "throttling_data" : {"periods":0,"throttled_periods":0,"throttled_time":0}
+         }
+      }
+
+The `precpu_stats` is the cpu statistic of *previous* read, which is used for calculating the cpu usage percent. It is not the exact copy of the `cpu_stats` field.
+
+**Query parameters**:
+
+-   **stream** – 1/True/true or 0/False/false, pull stats once then disconnect. Default `true`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Resize a container TTY
+
+`POST /containers/(id or name)/resize`
+
+Resize the TTY for container with  `id`. The unit is number of characters. You must restart the container for the resize to take effect.
+
+**Example request**:
+
+      POST /v1.22/containers/4fa6e0f0c678/resize?h=40&w=80 HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Length: 0
+      Content-Type: text/plain; charset=utf-8
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – No such container
+-   **500** – Cannot resize container
+
+#### Start a container
+
+`POST /containers/(id or name)/start`
+
+Start the container `id`
+
+> **Note**:
+> For backwards compatibility, this endpoint accepts a `HostConfig` as JSON-encoded request body.
+> See [create a container](#create-a-container) for details.
+
+**Example request**:
+
+    POST /v1.22/containers/e90e34656806/start HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **detachKeys** – Override the key sequence for detaching a
+        container. Format is a single character `[a-Z]` or `ctrl-<value>`
+        where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already started
+-   **404** – no such container
+-   **500** – server error
+
+#### Stop a container
+
+`POST /containers/(id or name)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+    POST /v1.22/containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already stopped
+-   **404** – no such container
+-   **500** – server error
+
+#### Restart a container
+
+`POST /containers/(id or name)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+    POST /v1.22/containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Kill a container
+
+`POST /containers/(id or name)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+    POST /v1.22/containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **signal** - Signal to send to the container: integer or string like `SIGINT`.
+        When not set, `SIGKILL` is assumed and the call waits for the container to exit.
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Update a container
+
+`POST /containers/(id or name)/update`
+
+Update resource configs of one or more containers.
+
+**Example request**:
+
+       POST /v1.22/containers/e90e34656806/update HTTP/1.1
+       Content-Type: application/json
+
+       {
+         "BlkioWeight": 300,
+         "CpuShares": 512,
+         "CpuPeriod": 100000,
+         "CpuQuota": 50000,
+         "CpusetCpus": "0,1",
+         "CpusetMems": "0",
+         "Memory": 314572800,
+         "MemorySwap": 514288000,
+         "MemoryReservation": 209715200,
+         "KernelMemory": 52428800
+       }
+
+**Example response**:
+
+       HTTP/1.1 200 OK
+       Content-Type: application/json
+
+       {
+           "Warnings": []
+       }
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+#### Rename a container
+
+`POST /containers/(id or name)/rename`
+
+Rename the container `id` to a `new_name`
+
+**Example request**:
+
+    POST /v1.22/containers/e90e34656806/rename?name=new_name HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **name** – new name for the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **409** - conflict name already assigned
+-   **500** – server error
+
+#### Pause a container
+
+`POST /containers/(id or name)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+    POST /v1.22/containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Unpause a container
+
+`POST /containers/(id or name)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+    POST /v1.22/containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Attach to a container
+
+`POST /containers/(id or name)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+    POST /v1.22/containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 101 UPGRADED
+    Content-Type: application/vnd.docker.raw-stream
+    Connection: Upgrade
+    Upgrade: tcp
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **detachKeys** – Override the key sequence for detaching a
+        container. Format is a single character `[a-Z]` or `ctrl-<value>`
+        where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+-   **stdin** – 1/True/true or 0/False/false, if `stream=true`, attach
+        to `stdin`. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stdout` log, if `stream=true`, attach to `stdout`. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stderr` log, if `stream=true`, attach to `stderr`. Default `false`.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **400** – bad parameter
+-   **404** – no such container
+-   **409** - container is paused
+-   **500** – server error
+
+**Stream details**:
+
+When using the TTY setting is enabled in
+[`POST /containers/create`
+](#create-a-container),
+the stream is the raw data from the process PTY and client's `stdin`.
+When the TTY is disabled, then the stream is multiplexed to separate
+`stdout` and `stderr`.
+
+The format is a **Header** and a **Payload** (frame).
+
+**HEADER**
+
+The header contains the information which the stream writes (`stdout` or
+`stderr`). It also contains the size of the associated frame encoded in the
+last four bytes (`uint32`).
+
+It is encoded on the first eight bytes like this:
+
+    header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+`STREAM_TYPE` can be:
+
+-   0: `stdin` (is written on `stdout`)
+-   1: `stdout`
+-   2: `stderr`
+
+`SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of
+the `uint32` size encoded as big endian.
+
+**PAYLOAD**
+
+The payload is the raw stream.
+
+**IMPLEMENTATION**
+
+The simplest way to implement the Attach protocol is the following:
+
+    1.  Read eight bytes.
+    2.  Choose `stdout` or `stderr` depending on the first byte.
+    3.  Extract the frame size from the last four bytes.
+    4.  Read the extracted size and output it on the correct output.
+    5.  Goto 1.
+
+#### Attach to a container (websocket)
+
+`GET /containers/(id or name)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+    GET /v1.22/containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **detachKeys** – Override the key sequence for detaching a
+        container. Format is a single character `[a-Z]` or `ctrl-<value>`
+        where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+#### Wait a container
+
+`POST /containers/(id or name)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+    POST /v1.22/containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"StatusCode": 0}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Remove a container
+
+`DELETE /containers/(id or name)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.22/containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default `false`.
+-   **force** - 1/True/true or 0/False/false, Kill then remove the container.
+        Default `false`.
+-   **link** - 1/True/true or 0/False/false, Remove the specified
+        link associated to the container. Default `false`.
+
+**Status codes**:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **409** – conflict
+-   **500** – server error
+
+#### Copy files or folders from a container
+
+`POST /containers/(id or name)/copy`
+
+Copy files or folders of container `id`
+
+**Deprecated** in favor of the `archive` endpoint below.
+
+**Example request**:
+
+    POST /v1.22/containers/4fa6e0f0c678/copy HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Resource": "test.txt"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Retrieving information about files and folders in a container
+
+`HEAD /containers/(id or name)/archive`
+
+See the description of the `X-Docker-Container-Path-Stat` header in the
+following section.
+
+#### Get an archive of a filesystem resource in a container
+
+`GET /containers/(id or name)/archive`
+
+Get a tar archive of a resource in the filesystem of container `id`.
+
+**Query parameters**:
+
+- **path** - resource in the container's filesystem to archive. Required.
+
+    If not an absolute path, it is relative to the container's root directory.
+    The resource specified by **path** must exist. To assert that the resource
+    is expected to be a directory, **path** should end in `/` or  `/.`
+    (assuming a path separator of `/`). If **path** ends in `/.` then this
+    indicates that only the contents of the **path** directory should be
+    copied. A symlink is always resolved to its target.
+
+    > **Note**: It is not possible to copy certain system files such as resources
+    > under `/proc`, `/sys`, `/dev`, and mounts created by the user in the
+    > container.
+
+**Example request**:
+
+    GET /v1.22/containers/8cce319429b2/archive?path=/root HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+    X-Docker-Container-Path-Stat: eyJuYW1lIjoicm9vdCIsInNpemUiOjQwOTYsIm1vZGUiOjIxNDc0ODQwOTYsIm10aW1lIjoiMjAxNC0wMi0yN1QyMDo1MToyM1oiLCJsaW5rVGFyZ2V0IjoiIn0=
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+On success, a response header `X-Docker-Container-Path-Stat` will be set to a
+base64-encoded JSON object containing some filesystem header information about
+the archived resource. The above example value would decode to the following
+JSON object (whitespace added for readability):
+
+```json
+{
+    "name": "root",
+    "size": 4096,
+    "mode": 2147484096,
+    "mtime": "2014-02-27T20:51:23Z",
+    "linkTarget": ""
+}
+```
+
+A `HEAD` request can also be made to this endpoint if only this information is
+desired.
+
+**Status codes**:
+
+- **200** - success, returns archive of copied resource
+- **400** - client error, bad parameter, details in JSON response body, one of:
+    - must specify path parameter (**path** cannot be empty)
+    - not a directory (**path** was asserted to be a directory but exists as a
+      file)
+- **404** - client error, resource not found, one of:
+    – no such container (container `id` does not exist)
+    - no such file or directory (**path** does not exist)
+- **500** - server error
+
+#### Extract an archive of files or folders to a directory in a container
+
+`PUT /containers/(id or name)/archive`
+
+Upload a tar archive to be extracted to a path in the filesystem of container
+`id`.
+
+**Query parameters**:
+
+- **path** - path to a directory in the container
+    to extract the archive's contents into. Required.
+
+    If not an absolute path, it is relative to the container's root directory.
+    The **path** resource must exist.
+- **noOverwriteDirNonDir** - If "1", "true", or "True" then it will be an error
+    if unpacking the given content would cause an existing directory to be
+    replaced with a non-directory and vice versa.
+
+**Example request**:
+
+    PUT /v1.22/containers/8cce319429b2/archive?path=/vol1 HTTP/1.1
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+- **200** – the content was extracted successfully
+- **400** - client error, bad parameter, details in JSON response body, one of:
+    - must specify path parameter (**path** cannot be empty)
+    - not a directory (**path** should be a directory but exists as a file)
+    - unable to overwrite existing directory with non-directory
+      (if **noOverwriteDirNonDir**)
+    - unable to overwrite existing non-directory with directory
+      (if **noOverwriteDirNonDir**)
+- **403** - client error, permission denied, the volume
+    or container rootfs is marked as read-only.
+- **404** - client error, resource not found, one of:
+    – no such container (container `id` does not exist)
+    - no such file or directory (**path** resource does not exist)
+- **500** – server error
+
+### 2.2 Images
+
+#### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+    GET /v1.22/images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+         "RepoTags": [
+           "ubuntu:12.04",
+           "ubuntu:precise",
+           "ubuntu:latest"
+         ],
+         "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+         "Created": 1365714795,
+         "Size": 131506275,
+         "VirtualSize": 131506275,
+         "Labels": {}
+      },
+      {
+         "RepoTags": [
+           "ubuntu:12.10",
+           "ubuntu:quantal"
+         ],
+         "ParentId": "27cf784147099545",
+         "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+         "Created": 1364102658,
+         "Size": 24653,
+         "VirtualSize": 180116135,
+         "Labels": {
+            "com.example.version": "v1"
+         }
+      }
+    ]
+
+**Example request, with digest information**:
+
+    GET /v1.22/images/json?digests=1 HTTP/1.1
+
+**Example response, with digest information**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+        "Created": 1420064636,
+        "Id": "4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125",
+        "ParentId": "ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2",
+        "RepoDigests": [
+          "localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf"
+        ],
+        "RepoTags": [
+          "localhost:5000/test/busybox:latest",
+          "playdate:latest"
+        ],
+        "Size": 0,
+        "VirtualSize": 2429728,
+        "Labels": {}
+      }
+    ]
+
+The response shows a single image `Id` associated with two repositories
+(`RepoTags`): `localhost:5000/test/busybox`: and `playdate`. A caller can use
+either of the `RepoTags` values `localhost:5000/test/busybox:latest` or
+`playdate:latest` to reference the image.
+
+You can also use `RepoDigests` values to reference an image. In this response,
+the array has only one reference and that is to the
+`localhost:5000/test/busybox` repository; the `playdate` repository has no
+digest. You can reference this digest using the value:
+`localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d...`
+
+See the `docker run` and `docker build` commands for examples of digest and tag
+references on the command line.
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a JSON encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   `dangling=true`
+  -   `label=key` or `label="key=value"` of an image label
+-   **filter** - only return images with the specified name
+
+#### Build image from a Dockerfile
+
+`POST /build`
+
+Build an image from a Dockerfile
+
+**Example request**:
+
+    POST /v1.22/build HTTP/1.1
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"stream": "Step 1/5..."}
+    {"stream": "..."}
+    {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+The input stream must be a `tar` archive compressed with one of the
+following algorithms: `identity` (no compression), `gzip`, `bzip2`, `xz`.
+
+The archive must include a build instructions file, typically called
+`Dockerfile` at the archive's root. The `dockerfile` parameter may be
+used to specify a different build instructions file. To do this, its value must be
+the path to the alternate build instructions file to use.
+
+The archive may include any number of other files,
+which are accessible in the build context (See the [*ADD build
+command*](https://docs.docker.com/engine/reference/builder/#add)).
+
+The Docker daemon performs a preliminary validation of the `Dockerfile` before
+starting the build, and returns an error if the syntax is incorrect. After that,
+each instruction is run one-by-one until the ID of the new image is output.
+
+The build is canceled if the client drops the connection by quitting
+or being killed.
+
+**Query parameters**:
+
+-   **dockerfile** - Path within the build context to the `Dockerfile`. This is
+        ignored if `remote` is specified and points to an external `Dockerfile`.
+-   **t** – A name and optional tag to apply to the image in the `name:tag` format.
+        If you omit the `tag` the default `latest` value is assumed.
+        You can provide one or more `t` parameters.
+-   **remote** – A Git repository URI or HTTP/HTTPS context URI. If the
+        URI points to a single text file, the file's contents are placed into
+        a file called `Dockerfile` and the image is built from that file. If
+        the URI points to a tarball, the file is downloaded by the daemon and
+        the contents therein used as the context for the build. If the URI
+        points to a tarball and the `dockerfile` parameter is also specified,
+        there must be a file with the corresponding path inside the tarball.
+-   **q** – Suppress verbose build output.
+-   **nocache** – Do not use the cache when building the image.
+-   **pull** - Attempt to pull the image even if an older image exists locally.
+-   **rm** - Remove intermediate containers after a successful build (default behavior).
+-   **forcerm** - Always remove intermediate containers (includes `rm`).
+-   **memory** - Set memory limit for build.
+-   **memswap** - Total memory (memory + swap), `-1` to enable unlimited swap.
+-   **cpushares** - CPU shares (relative weight).
+-   **cpusetcpus** - CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+-   **cpuperiod** - The length of a CPU period in microseconds.
+-   **cpuquota** - Microseconds of CPU time that the container can get in a CPU period.
+-   **buildargs** – JSON map of string pairs for build-time variables. Users pass
+        these values at build-time. Docker uses the `buildargs` as the environment
+        context for command(s) run via the Dockerfile's `RUN` instruction or for
+        variable expansion in other Dockerfile instructions. This is not meant for
+        passing secret values. [Read more about the buildargs instruction](https://docs.docker.com/engine/reference/builder/#arg)
+-   **shmsize** - Size of `/dev/shm` in bytes. The size must be greater than 0.  If omitted the system uses 64MB.
+
+**Request Headers**:
+
+-   **Content-type** – Set to `"application/x-tar"`.
+-   **X-Registry-Config** – A base64-url-safe-encoded Registry Auth Config JSON
+        object with the following structure:
+
+            {
+                "docker.example.com": {
+                    "username": "janedoe",
+                    "password": "hunter2"
+                },
+                "https://index.docker.io/v1/": {
+                    "username": "mobydock",
+                    "password": "conta1n3rize14"
+                }
+            }
+
+    This object maps the hostname of a registry to an object containing the
+    "username" and "password" for that registry. Multiple registries may
+    be specified as the build may be based on an image requiring
+    authentication to pull from any arbitrary registry. Only the registry
+    domain name (and port if not the default "443") are required. However
+    (for legacy reasons) the "official" Docker, Inc. hosted registry must
+    be specified with both a "https://" prefix and a "/v1/" suffix even
+    though Docker will prefer to use the v2 registry API.
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Create an image
+
+`POST /images/create`
+
+Create an image either by pulling it from the registry or by importing it
+
+**Example request**:
+
+    POST /v1.22/images/create?fromImage=busybox&tag=latest HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pulling..."}
+    {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+    {"error": "Invalid..."}
+    ...
+
+When using this endpoint to pull an image from the registry, the
+`X-Registry-Auth` header can be used to include
+a base64-encoded AuthConfig object.
+
+**Query parameters**:
+
+-   **fromImage** – Name of the image to pull. The name may include a tag or
+        digest. This parameter may only be used when pulling an image.
+        The pull is cancelled if the HTTP connection is closed.
+-   **fromSrc** – Source to import.  The value may be a URL from which the image
+        can be retrieved or `-` to read the image from the request body.
+        This parameter may only be used when importing an image.
+-   **repo** – Repository name given to an image when it is imported.
+        The repo may include a tag. This parameter may only be used when importing
+        an image.
+-   **tag** – Tag or digest. If empty when pulling an image, this causes all tags
+        for the given image to be pulled.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object, containing either login information, or a token
+    - Credential based login:
+
+        ```
+    {
+            "username": "jdoe",
+            "password": "secret",
+            "email": "jdoe@acme.com"
+    }
+        ```
+
+    - Token based login:
+
+        ```
+    {
+            "registrytoken": "9cbaf023786cd7..."
+    }
+        ```
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** - repository does not exist or no read access
+-   **500** – server error
+
+
+
+#### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+    GET /v1.22/images/example/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Id" : "85f05633ddc1c50679be2b16a0479ab6f7637f8884e0cfe0f4d20e1ebb3d6e7c",
+       "Container" : "cb91e48a60d01f1e27028b4fc6819f4f290b3cf12496c8176ec714d0d390984a",
+       "Comment" : "",
+       "Os" : "linux",
+       "Architecture" : "amd64",
+       "Parent" : "91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c",
+       "ContainerConfig" : {
+          "Tty" : false,
+          "Hostname" : "e611e15f9c9d",
+          "Volumes" : null,
+          "Domainname" : "",
+          "AttachStdout" : false,
+          "PublishService" : "",
+          "AttachStdin" : false,
+          "OpenStdin" : false,
+          "StdinOnce" : false,
+          "NetworkDisabled" : false,
+          "OnBuild" : [],
+          "Image" : "91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c",
+          "User" : "",
+          "WorkingDir" : "",
+          "Entrypoint" : null,
+          "MacAddress" : "",
+          "AttachStderr" : false,
+          "Labels" : {
+             "com.example.license" : "GPL",
+             "com.example.version" : "1.0",
+             "com.example.vendor" : "Acme"
+          },
+          "Env" : [
+             "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+          ],
+          "ExposedPorts" : null,
+          "Cmd" : [
+             "/bin/sh",
+             "-c",
+             "#(nop) LABEL com.example.vendor=Acme com.example.license=GPL com.example.version=1.0"
+          ]
+       },
+       "DockerVersion" : "1.9.0-dev",
+       "VirtualSize" : 188359297,
+       "Size" : 0,
+       "Author" : "",
+       "Created" : "2015-09-10T08:30:53.26995814Z",
+       "GraphDriver" : {
+          "Name" : "aufs",
+          "Data" : null
+       },
+       "RepoDigests" : [
+          "localhost:5000/test/busybox/example@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf"
+       ],
+       "RepoTags" : [
+          "example:1.0",
+          "example:latest",
+          "example:stable"
+       ],
+       "Config" : {
+          "Image" : "91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c",
+          "NetworkDisabled" : false,
+          "OnBuild" : [],
+          "StdinOnce" : false,
+          "PublishService" : "",
+          "AttachStdin" : false,
+          "OpenStdin" : false,
+          "Domainname" : "",
+          "AttachStdout" : false,
+          "Tty" : false,
+          "Hostname" : "e611e15f9c9d",
+          "Volumes" : null,
+          "Cmd" : [
+             "/bin/bash"
+          ],
+          "ExposedPorts" : null,
+          "Env" : [
+             "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+          ],
+          "Labels" : {
+             "com.example.vendor" : "Acme",
+             "com.example.version" : "1.0",
+             "com.example.license" : "GPL"
+          },
+          "Entrypoint" : null,
+          "MacAddress" : "",
+          "AttachStderr" : false,
+          "WorkingDir" : "",
+          "User" : ""
+       }
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+    GET /v1.22/images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+        {
+            "Id": "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710",
+            "Created": 1398108230,
+            "CreatedBy": "/bin/sh -c #(nop) ADD file:eb15dbd63394e063b805a3c32ca7bf0266ef64676d5a6fab4801f2e81e2a5148 in /",
+            "Tags": [
+                "ubuntu:lucid",
+                "ubuntu:10.04"
+            ],
+            "Size": 182964289,
+            "Comment": ""
+        },
+        {
+            "Id": "6cfa4d1f33fb861d4d114f43b25abd0ac737509268065cdfd69d544a59c85ab8",
+            "Created": 1398108222,
+            "CreatedBy": "/bin/sh -c #(nop) MAINTAINER Tianon Gravi <admwiggin@gmail.com> - mkimage-debootstrap.sh -i iproute,iputils-ping,ubuntu-minimal -t lucid.tar.xz lucid http://archive.ubuntu.com/ubuntu/",
+            "Tags": null,
+            "Size": 0,
+            "Comment": ""
+        },
+        {
+            "Id": "511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158",
+            "Created": 1371157430,
+            "CreatedBy": "",
+            "Tags": [
+                "scratch12:latest",
+                "scratch:latest"
+            ],
+            "Size": 0,
+            "Comment": "Imported from -"
+        }
+    ]
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+    POST /v1.22/images/test/push HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pushing..."}
+    {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+    {"error": "Invalid..."}
+    ...
+
+If you wish to push an image on to a private registry, that image must already have a tag
+into a repository which references that registry `hostname` and `port`.  This repository name should
+then be used in the URL. This duplicates the command line's flow.
+
+The push is cancelled if the HTTP connection is closed.
+
+**Example request**:
+
+    POST /v1.22/images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+**Query parameters**:
+
+-   **tag** – The tag to associate with the image on the registry. This is optional.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object, containing either login information, or a token
+    - Credential based login:
+
+        ```
+    {
+            "username": "jdoe",
+            "password": "secret",
+            "email": "jdoe@acme.com",
+    }
+        ```
+
+    - Token based login:
+
+        ```
+    {
+            "registrytoken": "9cbaf023786cd7..."
+    }
+        ```
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+    POST /v1.22/images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+
+**Query parameters**:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.22/images/test HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-type: application/json
+
+    [
+     {"Untagged": "3e2f21a89f"},
+     {"Deleted": "3e2f21a89f"},
+     {"Deleted": "53b4f83ac9"}
+    ]
+
+**Query parameters**:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+    GET /v1.22/images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "wma55/u1210sshd",
+                "star_count": 0
+            },
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "jdswinbank/sshd",
+                "star_count": 0
+            },
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "vgauthier/sshd",
+                "star_count": 0
+            }
+    ...
+    ]
+
+**Query parameters**:
+
+-   **term** – term to search
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+### 2.3 Misc
+
+#### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+    POST /v1.22/auth HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "username": "hannibal",
+         "password": "xxxx",
+         "email": "hannibal@a-team.com",
+         "serveraddress": "https://index.docker.io/v1/"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+#### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+    GET /v1.22/info HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+        "Architecture": "x86_64",
+        "ClusterStore": "etcd://localhost:2379",
+        "Containers": 11,
+        "ContainersRunning": 7,
+        "ContainersStopped": 3,
+        "ContainersPaused": 1,
+        "CpuCfsPeriod": true,
+        "CpuCfsQuota": true,
+        "Debug": false,
+        "DockerRootDir": "/var/lib/docker",
+        "Driver": "btrfs",
+        "DriverStatus": [[""]],
+        "ExecutionDriver": "native-0.1",
+        "ExperimentalBuild": false,
+        "HttpProxy": "http://test:test@localhost:8080",
+        "HttpsProxy": "https://test:test@localhost:8080",
+        "ID": "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS",
+        "IPv4Forwarding": true,
+        "Images": 16,
+        "IndexServerAddress": "https://index.docker.io/v1/",
+        "InitPath": "/usr/bin/docker",
+        "InitSha1": "",
+        "KernelVersion": "3.12.0-1-amd64",
+        "Labels": [
+            "storage=ssd"
+        ],
+        "MemTotal": 2099236864,
+        "MemoryLimit": true,
+        "NCPU": 1,
+        "NEventsListener": 0,
+        "NFd": 11,
+        "NGoroutines": 21,
+        "Name": "prod-server-42",
+        "NoProxy": "9.81.1.160",
+        "OomKillDisable": true,
+        "OSType": "linux",
+        "OperatingSystem": "Boot2Docker",
+        "Plugins": {
+            "Volume": [
+                "local"
+            ],
+            "Network": [
+                "null",
+                "host",
+                "bridge"
+            ]
+        },
+        "RegistryConfig": {
+            "IndexConfigs": {
+                "docker.io": {
+                    "Mirrors": null,
+                    "Name": "docker.io",
+                    "Official": true,
+                    "Secure": true
+                }
+            },
+            "InsecureRegistryCIDRs": [
+                "127.0.0.0/8"
+            ]
+        },
+        "ServerVersion": "1.9.0",
+        "SwapLimit": false,
+        "SystemStatus": [["State", "Healthy"]],
+        "SystemTime": "2015-03-10T11:11:23.730591467-07:00"
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+    GET /v1.22/version HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+         "Version": "1.10.0",
+         "Os": "linux",
+         "KernelVersion": "3.19.0-23-generic",
+         "GoVersion": "go1.4.2",
+         "GitCommit": "e75da4b",
+         "Arch": "amd64",
+         "ApiVersion": "1.22",
+         "BuildTime": "2015-12-01T07:09:13.444803460+00:00",
+         "Experimental": true
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+    GET /v1.22/_ping HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: text/plain
+
+    OK
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+    POST /v1.22/commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Hostname": "",
+         "Domainname": "",
+         "User": "",
+         "AttachStdin": false,
+         "AttachStdout": true,
+         "AttachStderr": true,
+         "Tty": false,
+         "OpenStdin": false,
+         "StdinOnce": false,
+         "Env": null,
+         "Cmd": [
+                 "date"
+         ],
+         "Mounts": [
+           {
+             "Source": "/data",
+             "Destination": "/data",
+             "Mode": "ro,Z",
+             "RW": false
+           }
+         ],
+         "Labels": {
+                 "key1": "value1",
+                 "key2": "value2"
+          },
+         "WorkingDir": "",
+         "NetworkDisabled": false,
+         "ExposedPorts": {
+                 "22/tcp": {}
+         }
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {"Id": "596069db4bf5"}
+
+**JSON parameters**:
+
+-  **config** - the container's configuration
+
+**Query parameters**:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+-   **pause** – 1/True/true or 0/False/false, whether to pause the container before committing
+-   **changes** – Dockerfile instructions to apply while committing
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, in real time via streaming.
+
+Docker containers report the following events:
+
+    attach, commit, copy, create, destroy, die, exec_create, exec_start, export, kill, oom, pause, rename, resize, restart, start, stop, top, unpause, update
+
+Docker images report the following events:
+
+    delete, import, pull, push, tag, untag
+
+Docker volumes report the following events:
+
+    create, mount, unmount, destroy
+
+Docker networks report the following events:
+
+    create, connect, disconnect, destroy
+
+**Example request**:
+
+    GET /v1.22/events?since=1374067924
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+    Server: Docker/1.10.0 (linux)
+    Date: Fri, 29 Apr 2016 15:18:06 GMT
+    Transfer-Encoding: chunked
+
+    {
+      "status": "pull",
+      "id": "alpine:latest",
+      "Type": "image",
+      "Action": "pull",
+      "Actor": {
+        "ID": "alpine:latest",
+        "Attributes": {
+          "name": "alpine"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101301854122
+    }
+    {
+      "status": "create",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "create",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "image": "alpine",
+          "name": "my-container"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101381709551
+    }
+    {
+      "status": "attach",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "attach",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "image": "alpine",
+          "name": "my-container"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101383858412
+    }
+    {
+      "Type": "network",
+      "Action": "connect",
+      "Actor": {
+        "ID": "7dc8ac97d5d29ef6c31b6052f3938c1e8f2749abbd17d1bd1febf2608db1b474",
+        "Attributes": {
+          "container": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+          "name": "bridge",
+          "type": "bridge"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101394865557
+    }
+    {
+      "status": "start",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "start",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "image": "alpine",
+          "name": "my-container"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101607533796
+    }
+    {
+      "status": "resize",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "resize",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "height": "46",
+          "image": "alpine",
+          "name": "my-container",
+          "width": "204"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101610269268
+    }
+    {
+      "status": "die",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "die",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "exitCode": "0",
+          "image": "alpine",
+          "name": "my-container"
+        }
+      },
+      "time": 1461943105,
+      "timeNano": 1461943105079144137
+    }
+    {
+      "Type": "network",
+      "Action": "disconnect",
+      "Actor": {
+        "ID": "7dc8ac97d5d29ef6c31b6052f3938c1e8f2749abbd17d1bd1febf2608db1b474",
+        "Attributes": {
+          "container": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+          "name": "bridge",
+          "type": "bridge"
+        }
+      },
+      "time": 1461943105,
+      "timeNano": 1461943105230860245
+    }
+    {
+      "status": "destroy",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "destroy",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "image": "alpine",
+          "name": "my-container"
+        }
+      },
+      "time": 1461943105,
+      "timeNano": 1461943105338056026
+    }
+
+**Query parameters**:
+
+-   **since** – Timestamp. Show all events created since timestamp and then stream
+-   **until** – Timestamp. Show events created until given timestamp and stop streaming
+-   **filters** – A json encoded value of the filters (a map[string][]string) to process on the event list. Available filters:
+  -   `container=<string>`; -- container to filter
+  -   `event=<string>`; -- event to filter
+  -   `image=<string>`; -- image to filter
+  -   `label=<string>`; -- image and container label to filter
+  -   `type=<string>`; -- either `container` or `image` or `volume` or `network`
+  -   `volume=<string>`; -- volume to filter
+  -   `network=<string>`; -- network to filter
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository specified
+by `name`.
+
+If `name` is a specific name and tag (e.g. ubuntu:latest), then only that image
+(and its parents) are returned. If `name` is an image ID, similarly only that
+image (and its parents) are returned, but with the exclusion of the
+'repositories' file in the tarball, as there were no image names referenced.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.22/images/ubuntu/get
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images
+
+`GET /images/get`
+
+Get a tarball containing all images and metadata for one or more repositories.
+
+For each value of the `names` parameter: if it is a specific name and tag (e.g.
+`ubuntu:latest`), then only that image (and its parents) are returned; if it is
+an image ID, similarly only that image (and its parents) are returned and there
+would be no names referenced in the 'repositories' file for this image ID.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.22/images/get?names=myname%2Fmyapp%3Alatest&names=busybox
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into a Docker repository.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    POST /v1.22/images/load
+    Content-Type: application/x-tar
+    Content-Length: 12345
+
+    Tarball in body
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing these files:
+
+- `VERSION`: currently `1.0` - the file format version
+- `json`: detailed layer information, similar to `docker inspect layer_id`
+- `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file contains `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, the tarball should also include a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+#### Exec Create
+
+`POST /containers/(id or name)/exec`
+
+Sets up an exec instance in a running container `id`
+
+**Example request**:
+
+    POST /v1.22/containers/e90e34656806/exec HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+      "AttachStdin": true,
+      "AttachStdout": true,
+      "AttachStderr": true,
+      "Cmd": ["sh"],
+      "DetachKeys": "ctrl-p,ctrl-q",
+      "Privileged": true,
+      "Tty": true,
+      "User": "123:456"
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {
+         "Id": "f90e34656806",
+         "Warnings":[]
+    }
+
+**JSON parameters**:
+
+-   **AttachStdin** - Boolean value, attaches to `stdin` of the `exec` command.
+-   **AttachStdout** - Boolean value, attaches to `stdout` of the `exec` command.
+-   **AttachStderr** - Boolean value, attaches to `stderr` of the `exec` command.
+-   **DetachKeys** – Override the key sequence for detaching a
+        container. Format is a single character `[a-Z]` or `ctrl-<value>`
+        where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Privileged** - Boolean value, runs the exec process with extended privileges.
+-   **User** - A string value specifying the user, and optionally, group to run
+        the exec process inside the container. Format is one of: `"user"`,
+        `"user:group"`, `"uid"`, or `"uid:gid"`.
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+-   **409** - container is paused
+-   **500** - server error
+
+#### Exec Start
+
+`POST /exec/(id)/start`
+
+Starts a previously set up `exec` instance `id`. If `detach` is true, this API
+returns after starting the `exec` command. Otherwise, this API sets up an
+interactive session with the `exec` command.
+
+**Example request**:
+
+    POST /v1.22/exec/e90e34656806/start HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+     "Detach": false,
+     "Tty": false
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/vnd.docker.raw-stream
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**JSON parameters**:
+
+-   **Detach** - Detach from the `exec` command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+-   **409** - container is paused
+
+**Stream details**:
+
+Similar to the stream behavior of `POST /containers/(id or name)/attach` API
+
+#### Exec Resize
+
+`POST /exec/(id)/resize`
+
+Resizes the `tty` session used by the `exec` command `id`.  The unit is number of characters.
+This API is valid only if `tty` was specified as part of creating and starting the `exec` command.
+
+**Example request**:
+
+    POST /v1.22/exec/e90e34656806/resize?h=40&w=80 HTTP/1.1
+    Content-Type: text/plain
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: text/plain
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such exec instance
+
+#### Exec Inspect
+
+`GET /exec/(id)/json`
+
+Return low-level information about the `exec` command `id`.
+
+**Example request**:
+
+    GET /v1.22/exec/11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "CanRemove": false,
+      "ContainerID": "b53ee82b53a40c7dca428523e34f741f3abc51d9f297a14ff874bf761b995126",
+      "DetachKeys": "",
+      "ExitCode": 2,
+      "ID": "f33bbfb39f5b142420f4759b2348913bd4a8d1a6d7fd56499cb41a1bb91d7b3b",
+      "OpenStderr": true,
+      "OpenStdin": true,
+      "OpenStdout": true,
+      "ProcessConfig": {
+        "arguments": [
+          "-c",
+          "exit 2"
+        ],
+        "entrypoint": "sh",
+        "privileged": false,
+        "tty": true,
+        "user": "1000"
+      },
+      "Running": false
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+-   **500** - server error
+
+### 2.4 Volumes
+
+#### List volumes
+
+`GET /volumes`
+
+**Example request**:
+
+    GET /v1.22/volumes HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Volumes": [
+        {
+          "Name": "tardis",
+          "Driver": "local",
+          "Mountpoint": "/var/lib/docker/volumes/tardis"
+        }
+      ],
+      "Warnings": []
+    }
+
+**Query parameters**:
+
+- **filters** - JSON encoded value of the filters (a `map[string][]string`) to process on the volumes list. There is one available filter: `dangling=true`
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Create a volume
+
+`POST /volumes/create`
+
+Create a volume
+
+**Example request**:
+
+    POST /v1.22/volumes/create HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+      "Name": "tardis"
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {
+      "Name": "tardis",
+      "Driver": "local",
+      "Mountpoint": "/var/lib/docker/volumes/tardis"
+    }
+
+**Status codes**:
+
+- **201** - no error
+- **500**  - server error
+
+**JSON parameters**:
+
+- **Name** - The new volume's name. If not specified, Docker generates a name.
+- **Driver** - Name of the volume driver to use. Defaults to `local` for the name.
+- **DriverOpts** - A mapping of driver options and values. These options are
+    passed directly to the driver and are driver specific.
+
+#### Inspect a volume
+
+`GET /volumes/(name)`
+
+Return low-level information on the volume `name`
+
+**Example request**:
+
+    GET /volumes/tardis
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Name": "tardis",
+      "Driver": "local",
+      "Mountpoint": "/var/lib/docker/volumes/tardis"
+    }
+
+**Status codes**:
+
+-   **200** - no error
+-   **404** - no such volume
+-   **500** - server error
+
+#### Remove a volume
+
+`DELETE /volumes/(name)`
+
+Instruct the driver to remove the volume (`name`).
+
+**Example request**:
+
+    DELETE /v1.22/volumes/tardis HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** - no error
+-   **404** - no such volume or volume driver
+-   **409** - volume is in use and cannot be removed
+-   **500** - server error
+
+### 2.5 Networks
+
+#### List networks
+
+`GET /networks`
+
+**Example request**:
+
+    GET /v1.22/networks?filters={"type":{"custom":true}} HTTP/1.1
+
+**Example response**:
+
+```
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+[
+  {
+    "Name": "bridge",
+    "Id": "f2de39df4171b0dc801e8002d1d999b77256983dfc63041c0f34030aa3977566",
+    "Scope": "local",
+    "Driver": "bridge",
+    "IPAM": {
+      "Driver": "default",
+      "Config": [
+        {
+          "Subnet": "172.17.0.0/16"
+        }
+      ]
+    },
+    "Containers": {
+      "39b69226f9d79f5634485fb236a23b2fe4e96a0a94128390a7fbbcc167065867": {
+        "EndpointID": "ed2419a97c1d9954d05b46e462e7002ea552f216e9b136b80a7db8d98b442eda",
+        "MacAddress": "02:42:ac:11:00:02",
+        "IPv4Address": "172.17.0.2/16",
+        "IPv6Address": ""
+      }
+    },
+    "Options": {
+      "com.docker.network.bridge.default_bridge": "true",
+      "com.docker.network.bridge.enable_icc": "true",
+      "com.docker.network.bridge.enable_ip_masquerade": "true",
+      "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
+      "com.docker.network.bridge.name": "docker0",
+      "com.docker.network.driver.mtu": "1500"
+    }
+  },
+  {
+    "Name": "none",
+    "Id": "e086a3893b05ab69242d3c44e49483a3bbbd3a26b46baa8f61ab797c1088d794",
+    "Scope": "local",
+    "Driver": "null",
+    "IPAM": {
+      "Driver": "default",
+      "Config": []
+    },
+    "Containers": {},
+    "Options": {}
+  },
+  {
+    "Name": "host",
+    "Id": "13e871235c677f196c4e1ecebb9dc733b9b2d2ab589e30c539efeda84a24215e",
+    "Scope": "local",
+    "Driver": "host",
+    "IPAM": {
+      "Driver": "default",
+      "Config": []
+    },
+    "Containers": {},
+    "Options": {}
+  }
+]
+```
+
+**Query parameters**:
+
+- **filters** - JSON encoded network list filter. The filter value is one of:
+  -   `id=<network-id>` Matches all or part of a network id.
+  -   `name=<network-name>` Matches all or part of a network name.
+  -   `type=["custom"|"builtin"]` Filters networks by type. The `custom` keyword returns all user-defined networks.
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Inspect network
+
+`GET /networks/(id or name)`
+
+Return low-level information on the network `id`
+
+**Example request**:
+
+    GET /v1.22/networks/7d86d31b1478e7cca9ebed7e73aa0fdeec46c5ca29497431d3007d2d9e15ed99 HTTP/1.1
+
+**Example response**:
+
+```
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+{
+  "Name": "net01",
+  "Id": "7d86d31b1478e7cca9ebed7e73aa0fdeec46c5ca29497431d3007d2d9e15ed99",
+  "Scope": "local",
+  "Driver": "bridge",
+  "IPAM": {
+    "Driver": "default",
+    "Config": [
+      {
+        "Subnet": "172.19.0.0/16",
+        "Gateway": "172.19.0.1/16"
+      }
+    ],
+    "Options": {
+        "foo": "bar"
+    }
+  },
+  "Containers": {
+    "19a4d5d687db25203351ed79d478946f861258f018fe384f229f2efa4b23513c": {
+      "Name": "test",
+      "EndpointID": "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a",
+      "MacAddress": "02:42:ac:13:00:02",
+      "IPv4Address": "172.19.0.2/16",
+      "IPv6Address": ""
+    }
+  },
+  "Options": {
+    "com.docker.network.bridge.default_bridge": "true",
+    "com.docker.network.bridge.enable_icc": "true",
+    "com.docker.network.bridge.enable_ip_masquerade": "true",
+    "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
+    "com.docker.network.bridge.name": "docker0",
+    "com.docker.network.driver.mtu": "1500"
+  }
+}
+```
+
+**Status codes**:
+
+-   **200** - no error
+-   **404** - network not found
+-   **500** - server error
+
+#### Create a network
+
+`POST /networks/create`
+
+Create a network
+
+**Example request**:
+
+```
+POST /v1.22/networks/create HTTP/1.1
+Content-Type: application/json
+Content-Length: 12345
+
+{
+  "Name":"isolated_nw",
+  "CheckDuplicate":true,
+  "Driver":"bridge",
+  "IPAM":{
+    "Driver": "default",
+    "Config":[
+      {
+        "Subnet":"172.20.0.0/16",
+        "IPRange":"172.20.10.0/24",
+        "Gateway":"172.20.10.11"
+      },
+      {
+        "Subnet":"2001:db8:abcd::/64",
+        "Gateway":"2001:db8:abcd::1011"
+      }
+    ],
+    "Options": {
+      "foo": "bar"
+    }
+  },
+  "Internal":true
+}
+```
+
+**Example response**:
+
+```
+HTTP/1.1 201 Created
+Content-Type: application/json
+
+{
+  "Id": "22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30",
+  "Warning": ""
+}
+```
+
+**Status codes**:
+
+- **201** - no error
+- **404** - plugin not found
+- **500** - server error
+
+**JSON parameters**:
+
+- **Name** - The new network's name. this is a mandatory field
+- **CheckDuplicate** - Requests daemon to check for networks with same name. Defaults to `false`.
+    Since Network is primarily keyed based on a random ID and not on the name, 
+    and network name is strictly a user-friendly alias to the network 
+    which is uniquely identified using ID, there is no guaranteed way to check for duplicates. 
+    This parameter CheckDuplicate is there to provide a best effort checking of any networks 
+    which has the same name but it is not guaranteed to catch all name collisions.
+- **Driver** - Name of the network driver plugin to use. Defaults to `bridge` driver
+- **IPAM** - Optional custom IP scheme for the network
+  - **Driver** - Name of the IPAM driver to use. Defaults to `default` driver
+  - **Config** - List of IPAM configuration options, specified as a map:
+      `{"Subnet": <CIDR>, "IPRange": <CIDR>, "Gateway": <IP address>, "AuxAddress": <device_name:IP address>}`
+  - **Options** - Driver-specific options, specified as a map: `{"option":"value" [,"option2":"value2"]}`
+- **Options** - Network specific options to be used by the drivers
+
+#### Connect a container to a network
+
+`POST /networks/(id or name)/connect`
+
+Connect a container to a network
+
+**Example request**:
+
+```
+POST /v1.22/networks/22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30/connect HTTP/1.1
+Content-Type: application/json
+Content-Length: 12345
+
+{
+  "Container":"3613f73ba0e4",
+  "EndpointConfig": {
+    "IPAMConfig": {
+        "IPv4Address":"172.24.56.89",
+        "IPv6Address":"2001:db8::5689"
+    }
+  }
+}
+```
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+- **200** - no error
+- **404** - network or container is not found
+- **500** - Internal Server Error
+
+**JSON parameters**:
+
+- **container** - container-id/name to be connected to the network
+
+#### Disconnect a container from a network
+
+`POST /networks/(id or name)/disconnect`
+
+Disconnect a container from a network
+
+**Example request**:
+
+```
+POST /v1.22/networks/22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30/disconnect HTTP/1.1
+Content-Type: application/json
+Content-Length: 12345
+
+{
+  "Container":"3613f73ba0e4",
+  "Force":false
+}
+```
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+- **200** - no error
+- **404** - network or container not found
+- **500** - Internal Server Error
+
+**JSON parameters**:
+
+- **Container** - container-id/name to be disconnected from a network
+- **Force** - Force the container to disconnect from a network
+
+#### Remove a network
+
+`DELETE /networks/(id or name)`
+
+Instruct the driver to remove the network (`id`).
+
+**Example request**:
+
+    DELETE /v1.22/networks/22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+-   **200** - no error
+-   **403** - operation not supported for pre-defined networks
+-   **404** - no such network
+-   **500** - server error
+
+## 3. Going further
+
+### 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it.
+    - Then, retry to create the container.
+
+- Start the container.
+
+- If you are not in detached mode:
+- Attach to the container, using `logs=1` (to have `stdout` and
+      `stderr` from the container's start) and `stream=1`
+
+- If in detached mode or only `stdin` is attached, display the container's id.
+
+### 3.2 Hijacking
+
+In this version of the API, `/attach`, uses hijacking to transport `stdin`,
+`stdout`, and `stderr` on the same socket.
+
+To hint potential proxies about connection hijacking, Docker client sends
+connection upgrade headers similarly to websocket.
+
+    Upgrade: tcp
+    Connection: Upgrade
+
+When Docker daemon detects the `Upgrade` header, it switches its status code
+from **200 OK** to **101 UPGRADED** and resends the same headers.
+
+
+### 3.3 CORS Requests
+
+To set cross origin requests to the Engine API please give values to
+`--api-cors-header` when running Docker in daemon mode. Set * (asterisk) allows all,
+default or blank means CORS disabled
+
+    $ dockerd -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.23.md b/_vendor/github.com/moby/moby/api/docs/v1.23.md
new file mode 100644
index 000000000000..d191fb76e8c2
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.23.md
@@ -0,0 +1,3452 @@
+---
+title: "Engine API v1.23"
+description: "API Documentation for Docker"
+keywords: "API, Docker, rcli, REST, documentation"
+aliases:
+- /engine/reference/api/docker_remote_api_v1.23/
+- /reference/api/docker_remote_api_v1.23/
+---
+
+<!-- This file is maintained within the moby/moby GitHub
+     repository at https://github.com/moby/moby/. Make all
+     pull requests against that repo. If you see this file in
+     another repository, consider it read-only there, as it will
+     periodically be overwritten by the definitive file. Pull
+     requests which include edits to this file in other repositories
+     will be rejected.
+-->
+
+## 1. Brief introduction
+
+ - The daemon listens on `unix:///var/run/docker.sock` but you can
+   [Bind Docker to another host/port or a Unix socket](https://docs.docker.com/engine/reference/commandline/dockerd/#bind-docker-to-another-host-port-or-a-unix-socket).
+ - The API tends to be REST. However, for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `stdout`,
+   `stdin` and `stderr`.
+ - A `Content-Length` header should be present in `POST` requests to endpoints
+   that expect a body.
+ - To lock to a specific version of the API, you prefix the URL with the version
+   of the API to use. For example, `/v1.18/info`. If no version is included in
+   the URL, the maximum supported API version is used.
+ - If the API version specified in the URL is not supported by the daemon, a HTTP
+   `400 Bad Request` error message is returned.
+
+## 2. Endpoints
+
+### 2.1 Containers
+
+#### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+    GET /v1.23/containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Id": "8dfafdbc3a40",
+                 "Names":["/boring_feynman"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 1",
+                 "Created": 1367854155,
+                 "State": "exited",
+                 "Status": "Exit 0",
+                 "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                 "Labels": {
+                         "com.example.vendor": "Acme",
+                         "com.example.license": "GPL",
+                         "com.example.version": "1.0"
+                 },
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0,
+                 "HostConfig": {
+                         "NetworkMode": "default"
+                 },
+                 "NetworkSettings": {
+                         "Networks": {
+                                 "bridge": {
+                                          "IPAMConfig": null,
+                                          "Links": null,
+                                          "Aliases": null,
+                                          "NetworkID": "7ea29fc1412292a2d7bba362f9253545fecdfa8ce9a6e37dd10ba8bee7129812",
+                                          "EndpointID": "2cdc4edb1ded3631c81f57966563e5c8525b81121bb3706a9a9a3ae102711f3f",
+                                          "Gateway": "172.17.0.1",
+                                          "IPAddress": "172.17.0.2",
+                                          "IPPrefixLen": 16,
+                                          "IPv6Gateway": "",
+                                          "GlobalIPv6Address": "",
+                                          "GlobalIPv6PrefixLen": 0,
+                                          "MacAddress": "02:42:ac:11:00:02"
+                                  }
+                         }
+                 },
+                 "Mounts": [
+                         {
+                                  "Name": "fac362...80535",
+                                  "Source": "/data",
+                                  "Destination": "/data",
+                                  "Driver": "local",
+                                  "Mode": "ro,Z",
+                                  "RW": false,
+                                  "Propagation": ""
+                         }
+                 ]
+         },
+         {
+                 "Id": "9cd87474be90",
+                 "Names":["/coolName"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 222222",
+                 "Created": 1367854155,
+                 "State": "exited",
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0,
+                 "HostConfig": {
+                         "NetworkMode": "default"
+                 },
+                 "NetworkSettings": {
+                         "Networks": {
+                                 "bridge": {
+                                          "IPAMConfig": null,
+                                          "Links": null,
+                                          "Aliases": null,
+                                          "NetworkID": "7ea29fc1412292a2d7bba362f9253545fecdfa8ce9a6e37dd10ba8bee7129812",
+                                          "EndpointID": "88eaed7b37b38c2a3f0c4bc796494fdf51b270c2d22656412a2ca5d559a64d7a",
+                                          "Gateway": "172.17.0.1",
+                                          "IPAddress": "172.17.0.8",
+                                          "IPPrefixLen": 16,
+                                          "IPv6Gateway": "",
+                                          "GlobalIPv6Address": "",
+                                          "GlobalIPv6PrefixLen": 0,
+                                          "MacAddress": "02:42:ac:11:00:08"
+                                  }
+                         }
+                 },
+                 "Mounts": []
+         },
+         {
+                 "Id": "3176a2479c92",
+                 "Names":["/sleepy_dog"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 3333333333333333",
+                 "Created": 1367854154,
+                 "State": "exited",
+                 "Status": "Exit 0",
+                 "Ports":[],
+                 "Labels": {},
+                 "SizeRw":12288,
+                 "SizeRootFs":0,
+                 "HostConfig": {
+                         "NetworkMode": "default"
+                 },
+                 "NetworkSettings": {
+                         "Networks": {
+                                 "bridge": {
+                                          "IPAMConfig": null,
+                                          "Links": null,
+                                          "Aliases": null,
+                                          "NetworkID": "7ea29fc1412292a2d7bba362f9253545fecdfa8ce9a6e37dd10ba8bee7129812",
+                                          "EndpointID": "8b27c041c30326d59cd6e6f510d4f8d1d570a228466f956edf7815508f78e30d",
+                                          "Gateway": "172.17.0.1",
+                                          "IPAddress": "172.17.0.6",
+                                          "IPPrefixLen": 16,
+                                          "IPv6Gateway": "",
+                                          "GlobalIPv6Address": "",
+                                          "GlobalIPv6PrefixLen": 0,
+                                          "MacAddress": "02:42:ac:11:00:06"
+                                  }
+                         }
+                 },
+                 "Mounts": []
+         },
+         {
+                 "Id": "4cb07b47f9fb",
+                 "Names":["/running_cat"],
+                 "Image": "ubuntu:latest",
+                 "ImageID": "d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82",
+                 "Command": "echo 444444444444444444444444444444444",
+                 "Created": 1367854152,
+                 "State": "exited",
+                 "Status": "Exit 0",
+                 "Ports": [],
+                 "Labels": {},
+                 "SizeRw": 12288,
+                 "SizeRootFs": 0,
+                 "HostConfig": {
+                         "NetworkMode": "default"
+                 },
+                 "NetworkSettings": {
+                         "Networks": {
+                                 "bridge": {
+                                          "IPAMConfig": null,
+                                          "Links": null,
+                                          "Aliases": null,
+                                          "NetworkID": "7ea29fc1412292a2d7bba362f9253545fecdfa8ce9a6e37dd10ba8bee7129812",
+                                          "EndpointID": "d91c7b2f0644403d7ef3095985ea0e2370325cd2332ff3a3225c4247328e66e9",
+                                          "Gateway": "172.17.0.1",
+                                          "IPAddress": "172.17.0.5",
+                                          "IPPrefixLen": 16,
+                                          "IPv6Gateway": "",
+                                          "GlobalIPv6Address": "",
+                                          "GlobalIPv6PrefixLen": 0,
+                                          "MacAddress": "02:42:ac:11:00:05"
+                                  }
+                         }
+                 },
+                 "Mounts": []
+         }
+    ]
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created
+        containers, include non-running ones.
+-   **since** – Show only containers created since Id, include
+        non-running ones.
+-   **before** – Show only containers created before Id, include
+        non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers
+        sizes
+-   **filters** - a JSON encoded value of the filters (a `map[string][]string`) to process on the containers list. Available filters:
+  -   `exited=<int>`; -- containers with exit code of  `<int>` ;
+  -   `status=`(`created`|`restarting`|`running`|`paused`|`exited`|`dead`)
+  -   `label=key` or `label="key=value"` of a container label
+  -   `isolation=`(`default`|`process`|`hyperv`)   (Windows daemon only)
+  -   `ancestor`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+  -   `before`=(`<container id>` or `<container name>`)
+  -   `since`=(`<container id>` or `<container name>`)
+  -   `volume`=(`<volume name>` or `<mount point destination>`)
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+#### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+    POST /v1.23/containers/create HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+           "Hostname": "",
+           "Domainname": "",
+           "User": "",
+           "AttachStdin": false,
+           "AttachStdout": true,
+           "AttachStderr": true,
+           "Tty": false,
+           "OpenStdin": false,
+           "StdinOnce": false,
+           "Env": [
+                   "FOO=bar",
+                   "BAZ=quux"
+           ],
+           "Cmd": [
+                   "date"
+           ],
+           "Entrypoint": "",
+           "Image": "ubuntu",
+           "Labels": {
+                   "com.example.vendor": "Acme",
+                   "com.example.license": "GPL",
+                   "com.example.version": "1.0"
+           },
+           "Volumes": {
+             "/volumes/data": {}
+           },
+           "WorkingDir": "",
+           "NetworkDisabled": false,
+           "MacAddress": "12:34:56:78:9a:bc",
+           "ExposedPorts": {
+                   "22/tcp": {}
+           },
+           "StopSignal": "SIGTERM",
+           "HostConfig": {
+             "Binds": ["/tmp:/tmp"],
+             "Tmpfs": { "/run": "rw,noexec,nosuid,size=65536k" },
+             "Links": ["redis3:redis"],
+             "Memory": 0,
+             "MemorySwap": 0,
+             "MemoryReservation": 0,
+             "KernelMemory": 0,
+             "CpuShares": 512,
+             "CpuPeriod": 100000,
+             "CpuQuota": 50000,
+             "CpusetCpus": "0,1",
+             "CpusetMems": "0,1",
+             "BlkioWeight": 300,
+             "BlkioWeightDevice": [{}],
+             "BlkioDeviceReadBps": [{}],
+             "BlkioDeviceReadIOps": [{}],
+             "BlkioDeviceWriteBps": [{}],
+             "BlkioDeviceWriteIOps": [{}],
+             "MemorySwappiness": 60,
+             "OomKillDisable": false,
+             "OomScoreAdj": 500,
+             "PidMode": "",
+             "PidsLimit": -1,
+             "PortBindings": { "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts": false,
+             "Privileged": false,
+             "ReadonlyRootfs": false,
+             "Dns": ["8.8.8.8"],
+             "DnsOptions": [""],
+             "DnsSearch": [""],
+             "ExtraHosts": null,
+             "VolumesFrom": ["parent", "other:ro"],
+             "CapAdd": ["NET_ADMIN"],
+             "CapDrop": ["MKNOD"],
+             "GroupAdd": ["newgroup"],
+             "RestartPolicy": { "Name": "", "MaximumRetryCount": 0 },
+             "NetworkMode": "bridge",
+             "Devices": [],
+             "Ulimits": [{}],
+             "LogConfig": { "Type": "json-file", "Config": {} },
+             "SecurityOpt": [],
+             "CgroupParent": "",
+             "VolumeDriver": "",
+             "ShmSize": 67108864
+          },
+          "NetworkingConfig": {
+              "EndpointsConfig": {
+                  "isolated_nw" : {
+                      "IPAMConfig": {
+                          "IPv4Address":"172.20.30.33",
+                          "IPv6Address":"2001:db8:abcd::3033"
+                      },
+                      "Links":["container_1", "container_2"],
+                      "Aliases":["server_x", "server_y"]
+                  }
+              }
+          }
+      }
+
+**Example response**:
+
+      HTTP/1.1 201 Created
+      Content-Type: application/json
+
+      {
+           "Id":"e90e34656806",
+           "Warnings":[]
+      }
+
+**JSON parameters**:
+
+-   **Hostname** - A string value containing the hostname to use for the
+      container.
+-   **Domainname** - A string value containing the domain name to use
+      for the container.
+-   **User** - A string value specifying the user inside the container.
+-   **AttachStdin** - Boolean value, attaches to `stdin`.
+-   **AttachStdout** - Boolean value, attaches to `stdout`.
+-   **AttachStderr** - Boolean value, attaches to `stderr`.
+-   **Tty** - Boolean value, Attach standard streams to a `tty`, including `stdin` if it is not closed.
+-   **OpenStdin** - Boolean value, opens `stdin`,
+-   **StdinOnce** - Boolean value, close `stdin` after the 1 attached client disconnects.
+-   **Env** - A list of environment variables in the form of `["VAR=value", ...]`
+-   **Labels** - Adds a map of labels to a container. To specify a map: `{"key":"value", ... }`
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Entrypoint** - Set the entry point for the container as a string or an array
+      of strings.
+-   **Image** - A string specifying the image name to use for the container.
+-   **Volumes** - An object mapping mount point paths (strings) inside the
+      container to empty objects.
+-   **WorkingDir** - A string specifying the working directory for commands to
+      run in.
+-   **NetworkDisabled** - Boolean value, when true disables networking for the
+      container
+-   **ExposedPorts** - An object mapping ports to an empty object in the form of:
+      `"ExposedPorts": { "<port>/<tcp|udp>: {}" }`
+-   **StopSignal** - Signal to stop a container as a string or unsigned integer. `SIGTERM` by default.
+-   **HostConfig**
+    -   **Binds** – A list of volume bindings for this container. Each volume binding is a string in one of these forms:
+           + `host-src:container-dest` to bind-mount a host path into the
+             container. Both `host-src`, and `container-dest` must be an
+             _absolute_ path.
+           + `host-src:container-dest:ro` to make the bind mount read-only
+             inside the container. Both `host-src`, and `container-dest` must be
+             an _absolute_ path.
+           + `volume-name:container-dest` to bind-mount a volume managed by a
+             volume driver into the container. `container-dest` must be an
+             _absolute_ path.
+           + `volume-name:container-dest:ro` to mount the volume read-only
+             inside the container.  `container-dest` must be an _absolute_ path.
+    -   **Tmpfs** – A map of container directories which should be replaced by tmpfs mounts, and their corresponding
+          mount options. A JSON object in the form `{ "/run": "rw,noexec,nosuid,size=65536k" }`.
+    -   **Links** - A list of links for the container. Each link entry should be
+          in the form of `container_name:alias`.
+    -   **Memory** - Memory limit in bytes.
+    -   **MemorySwap** - Total memory limit (memory + swap); set `-1` to enable unlimited swap.
+          You must use this with `memory` and make the swap value larger than `memory`.
+    -   **MemoryReservation** - Memory soft limit in bytes.
+    -   **KernelMemory** - Kernel memory limit in bytes.
+    -   **CpuShares** - An integer value containing the container's CPU Shares
+          (ie. the relative weight vs other containers).
+    -   **CpuPeriod** - The length of a CPU period in microseconds.
+    -   **CpuQuota** - Microseconds of CPU time that the container can get in a CPU period.
+    -   **CpusetCpus** - String value containing the `cgroups CpusetCpus` to use.
+    -   **CpusetMems** - Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
+    -   **BlkioWeight** - Block IO weight (relative weight) accepts a weight value between 10 and 1000.
+    -   **BlkioWeightDevice** - Block IO weight (relative device weight) in the form of:        `"BlkioWeightDevice": [{"Path": "device_path", "Weight": weight}]`
+    -   **BlkioDeviceReadBps** - Limit read rate (bytes per second) from a device in the form of:	`"BlkioDeviceReadBps": [{"Path": "device_path", "Rate": rate}]`, for example:
+        `"BlkioDeviceReadBps": [{"Path": "/dev/sda", "Rate": "1024"}]"`
+    -   **BlkioDeviceWriteBps** - Limit write rate (bytes per second) to a device in the form of:	`"BlkioDeviceWriteBps": [{"Path": "device_path", "Rate": rate}]`, for example:
+        `"BlkioDeviceWriteBps": [{"Path": "/dev/sda", "Rate": "1024"}]"`
+    -   **BlkioDeviceReadIOps** - Limit read rate (IO per second) from a device in the form of:	`"BlkioDeviceReadIOps": [{"Path": "device_path", "Rate": rate}]`, for example:
+        `"BlkioDeviceReadIOps": [{"Path": "/dev/sda", "Rate": "1000"}]`
+    -   **BlkioDeviceWriteIOps** - Limit write rate (IO per second) to a device in the form of:	`"BlkioDeviceWriteIOps": [{"Path": "device_path", "Rate": rate}]`, for example:
+        `"BlkioDeviceWriteIOps": [{"Path": "/dev/sda", "Rate": "1000"}]`
+    -   **MemorySwappiness** - Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100.
+    -   **OomKillDisable** - Boolean value, whether to disable OOM Killer for the container or not.
+    -   **OomScoreAdj** - An integer value containing the score given to the container in order to tune OOM killer preferences.
+    -   **PidMode** - Set the PID (Process) Namespace mode for the container;
+          `"container:<name|id>"`: joins another container's PID namespace
+          `"host"`: use the host's PID namespace inside the container
+    -   **PidsLimit** - Tune a container's pids limit. Set -1 for unlimited.
+    -   **PortBindings** - A map of exposed container ports and the host port they
+          should map to. A JSON object in the form
+          `{ <port>/<protocol>: [{ "HostPort": "<port>" }] }`
+          Take note that `port` is specified as a string and not an integer value.
+    -   **PublishAllPorts** - Allocates an ephemeral host port for all of a container's
+          exposed ports. Specified as a boolean value.
+
+          Ports are de-allocated when the container stops and allocated when the container starts.
+          The allocated port might be changed when restarting the container.
+
+          The port is selected from the ephemeral port range that depends on the kernel.
+          For example, on Linux the range is defined by `/proc/sys/net/ipv4/ip_local_port_range`.
+    -   **Privileged** - Gives the container full access to the host. Specified as
+          a boolean value.
+    -   **ReadonlyRootfs** - Mount the container's root filesystem as read only.
+          Specified as a boolean value.
+    -   **Dns** - A list of DNS servers for the container to use.
+    -   **DnsOptions** - A list of DNS options
+    -   **DnsSearch** - A list of DNS search domains
+    -   **ExtraHosts** - A list of hostnames/IP mappings to add to the
+        container's `/etc/hosts` file. Specified in the form `["hostname:IP"]`.
+    -   **VolumesFrom** - A list of volumes to inherit from another container.
+          Specified in the form `<container name>[:<ro|rw>]`
+    -   **CapAdd** - A list of kernel capabilities to add to the container.
+    -   **Capdrop** - A list of kernel capabilities to drop from the container.
+    -   **GroupAdd** - A list of additional groups that the container process will run as
+    -   **RestartPolicy** – The behavior to apply when the container exits.  The
+            value is an object with a `Name` property of either `"always"` to
+            always restart, `"unless-stopped"` to restart always except when
+            user has manually stopped the container or `"on-failure"` to restart only when the container
+            exit code is non-zero.  If `on-failure` is used, `MaximumRetryCount`
+            controls the number of times to retry before giving up.
+            The default is not to restart. (optional)
+            An ever increasing delay (double the previous delay, starting at 100mS)
+            is added before each restart to prevent flooding the server.
+    -   **UsernsMode**  - Sets the usernamespace mode for the container when usernamespace remapping option is enabled.
+           supported values are: `host`.
+    -   **NetworkMode** - Sets the networking mode for the container. Supported
+          standard values are: `bridge`, `host`, `none`, and `container:<name|id>`. Any other value is taken
+          as a custom network's name to which this container should connect to.
+    -   **Devices** - A list of devices to add to the container specified as a JSON object in the
+      form
+          `{ "PathOnHost": "/dev/deviceName", "PathInContainer": "/dev/deviceName", "CgroupPermissions": "mrw"}`
+    -   **Ulimits** - A list of ulimits to set in the container, specified as
+          `{ "Name": <name>, "Soft": <soft limit>, "Hard": <hard limit> }`, for example:
+          `Ulimits: { "Name": "nofile", "Soft": 1024, "Hard": 2048 }`
+    -   **SecurityOpt**: A list of string values to customize labels for MLS
+        systems, such as SELinux.
+    -   **LogConfig** - Log configuration for the container, specified as a JSON object in the form
+          `{ "Type": "<driver_name>", "Config": {"key1": "val1"}}`.
+          Available types: `json-file`, `syslog`, `journald`, `gelf`, `fluentd`, `awslogs`, `splunk`, `etwlogs`, `none`.
+          `json-file` logging driver.
+    -   **CgroupParent** - Path to `cgroups` under which the container's `cgroup` is created. If the path is not absolute, the path is considered to be relative to the `cgroups` path of the init process. Cgroups are created if they do not already exist.
+    -   **VolumeDriver** - Driver that this container users to mount volumes.
+    -   **ShmSize** - Size of `/dev/shm` in bytes. The size must be greater than 0.  If omitted the system uses 64MB.
+
+**Query parameters**:
+
+-   **name** – Assign the specified name to the container. Must
+    match `/?[a-zA-Z0-9_-]+`.
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **406** – impossible to attach (container not running)
+-   **409** – conflict
+-   **500** – server error
+
+#### Inspect a container
+
+`GET /containers/(id or name)/json`
+
+Return low-level information on the container `id`
+
+**Example request**:
+
+      GET /v1.23/containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+	{
+		"AppArmorProfile": "",
+		"Args": [
+			"-c",
+			"exit 9"
+		],
+		"Config": {
+			"AttachStderr": true,
+			"AttachStdin": false,
+			"AttachStdout": true,
+			"Cmd": [
+				"/bin/sh",
+				"-c",
+				"exit 9"
+			],
+			"Domainname": "",
+			"Entrypoint": null,
+			"Env": [
+				"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+			],
+			"ExposedPorts": null,
+			"Hostname": "ba033ac44011",
+			"Image": "ubuntu",
+			"Labels": {
+				"com.example.vendor": "Acme",
+				"com.example.license": "GPL",
+				"com.example.version": "1.0"
+			},
+			"MacAddress": "",
+			"NetworkDisabled": false,
+			"OnBuild": null,
+			"OpenStdin": false,
+			"StdinOnce": false,
+			"Tty": false,
+			"User": "",
+			"Volumes": {
+				"/volumes/data": {}
+			},
+			"WorkingDir": "",
+			"StopSignal": "SIGTERM"
+		},
+		"Created": "2015-01-06T15:47:31.485331387Z",
+		"Driver": "overlay2",
+		"ExecIDs": null,
+		"HostConfig": {
+			"Binds": null,
+			"BlkioWeight": 0,
+			"BlkioWeightDevice": [{}],
+			"BlkioDeviceReadBps": [{}],
+			"BlkioDeviceWriteBps": [{}],
+			"BlkioDeviceReadIOps": [{}],
+			"BlkioDeviceWriteIOps": [{}],
+			"CapAdd": null,
+			"CapDrop": null,
+			"ContainerIDFile": "",
+			"CpusetCpus": "",
+			"CpusetMems": "",
+			"CpuShares": 0,
+			"CpuPeriod": 100000,
+			"Devices": [],
+			"Dns": null,
+			"DnsOptions": null,
+			"DnsSearch": null,
+			"ExtraHosts": null,
+			"IpcMode": "",
+			"Links": null,
+			"Memory": 0,
+			"MemorySwap": 0,
+			"MemoryReservation": 0,
+			"KernelMemory": 0,
+			"OomKillDisable": false,
+			"OomScoreAdj": 500,
+			"NetworkMode": "bridge",
+			"PidMode": "",
+			"PortBindings": {},
+			"Privileged": false,
+			"ReadonlyRootfs": false,
+			"PublishAllPorts": false,
+			"RestartPolicy": {
+				"MaximumRetryCount": 2,
+				"Name": "on-failure"
+			},
+			"LogConfig": {
+				"Config": null,
+				"Type": "json-file"
+			},
+			"SecurityOpt": null,
+			"VolumesFrom": null,
+			"Ulimits": [{}],
+			"VolumeDriver": "",
+			"ShmSize": 67108864
+		},
+		"HostnamePath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hostname",
+		"HostsPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/hosts",
+		"LogPath": "/var/lib/docker/containers/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b/1eb5fabf5a03807136561b3c00adcd2992b535d624d5e18b6cdc6a6844d9767b-json.log",
+		"Id": "ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39",
+		"Image": "04c5d3b7b0656168630d3ba35d8889bd0e9caafcaeb3004d2bfbc47e7c5d35d2",
+		"MountLabel": "",
+		"Name": "/boring_euclid",
+		"NetworkSettings": {
+			"Bridge": "",
+			"SandboxID": "",
+			"HairpinMode": false,
+			"LinkLocalIPv6Address": "",
+			"LinkLocalIPv6PrefixLen": 0,
+			"Ports": null,
+			"SandboxKey": "",
+			"SecondaryIPAddresses": null,
+			"SecondaryIPv6Addresses": null,
+			"EndpointID": "",
+			"Gateway": "",
+			"GlobalIPv6Address": "",
+			"GlobalIPv6PrefixLen": 0,
+			"IPAddress": "",
+			"IPPrefixLen": 0,
+			"IPv6Gateway": "",
+			"MacAddress": "",
+			"Networks": {
+				"bridge": {
+					"NetworkID": "7ea29fc1412292a2d7bba362f9253545fecdfa8ce9a6e37dd10ba8bee7129812",
+					"EndpointID": "7587b82f0dada3656fda26588aee72630c6fab1536d36e394b2bfbcf898c971d",
+					"Gateway": "172.17.0.1",
+					"IPAddress": "172.17.0.2",
+					"IPPrefixLen": 16,
+					"IPv6Gateway": "",
+					"GlobalIPv6Address": "",
+					"GlobalIPv6PrefixLen": 0,
+					"MacAddress": "02:42:ac:12:00:02"
+				}
+			}
+		},
+		"Path": "/bin/sh",
+		"ProcessLabel": "",
+		"ResolvConfPath": "/var/lib/docker/containers/ba033ac4401106a3b513bc9d639eee123ad78ca3616b921167cd74b20e25ed39/resolv.conf",
+		"RestartCount": 1,
+		"State": {
+			"Error": "",
+			"ExitCode": 9,
+			"FinishedAt": "2015-01-06T15:47:32.080254511Z",
+			"OOMKilled": false,
+			"Dead": false,
+			"Paused": false,
+			"Pid": 0,
+			"Restarting": false,
+			"Running": true,
+			"StartedAt": "2015-01-06T15:47:32.072697474Z",
+			"Status": "running"
+		},
+		"Mounts": [
+			{
+				"Name": "fac362...80535",
+				"Source": "/data",
+				"Destination": "/data",
+				"Driver": "local",
+				"Mode": "ro,Z",
+				"RW": false,
+				"Propagation": ""
+			}
+		]
+	}
+
+**Example request, with size information**:
+
+    GET /v1.23/containers/4fa6e0f0c678/json?size=1 HTTP/1.1
+
+**Example response, with size information**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+    ....
+    "SizeRw": 0,
+    "SizeRootFs": 972,
+    ....
+    }
+
+**Query parameters**:
+
+-   **size** – 1/True/true or 0/False/false, return container size information. Default is `false`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### List processes running inside a container
+
+`GET /containers/(id or name)/top`
+
+List processes running inside the container `id`. On Unix systems this
+is done by running the `ps` command. This endpoint is not
+supported on Windows.
+
+**Example request**:
+
+    GET /v1.23/containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Titles" : [
+         "UID", "PID", "PPID", "C", "STIME", "TTY", "TIME", "CMD"
+       ],
+       "Processes" : [
+         [
+           "root", "13642", "882", "0", "17:03", "pts/0", "00:00:00", "/bin/bash"
+         ],
+         [
+           "root", "13735", "13642", "0", "17:06", "pts/0", "00:00:00", "sleep 10"
+         ]
+       ]
+    }
+
+**Example request**:
+
+    GET /v1.23/containers/4fa6e0f0c678/top?ps_args=aux HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Titles" : [
+        "USER","PID","%CPU","%MEM","VSZ","RSS","TTY","STAT","START","TIME","COMMAND"
+      ]
+      "Processes" : [
+        [
+          "root","13642","0.0","0.1","18172","3184","pts/0","Ss","17:03","0:00","/bin/bash"
+        ],
+        [
+          "root","13895","0.0","0.0","4348","692","pts/0","S+","17:15","0:00","sleep 10"
+        ]
+      ],
+    }
+
+**Query parameters**:
+
+-   **ps_args** – `ps` arguments to use (e.g., `aux`), defaults to `-ef`
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container logs
+
+`GET /containers/(id or name)/logs`
+
+Get `stdout` and `stderr` logs from the container ``id``
+
+> **Note**:
+> This endpoint works only for containers with the `json-file` or `journald` logging drivers.
+
+**Example request**:
+
+     GET /v1.23/containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10&since=1428990821 HTTP/1.1
+
+**Example response**:
+
+     HTTP/1.1 101 UPGRADED
+     Content-Type: application/vnd.docker.raw-stream
+     Connection: Upgrade
+     Upgrade: tcp
+
+     {% raw %}
+     {{ STREAM }}
+     {% endraw %}
+
+**Query parameters**:
+
+-   **follow** – 1/True/true or 0/False/false, return stream. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, show `stdout` log. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, show `stderr` log. Default `false`.
+-   **since** – UNIX timestamp (integer) to filter logs. Specifying a timestamp
+    will only output log-entries since that timestamp. Default: 0 (unfiltered)
+-   **timestamps** – 1/True/true or 0/False/false, print timestamps for
+        every log line. Default `false`.
+-   **tail** – Output specified number of lines at the end of logs: `all` or `<number>`. Default all.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **404** – no such container
+-   **500** – server error
+
+#### Inspect changes on a container's filesystem
+
+`GET /containers/(id or name)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+    GET /v1.23/containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+         {
+                 "Path": "/dev",
+                 "Kind": 0
+         },
+         {
+                 "Path": "/dev/kmsg",
+                 "Kind": 1
+         },
+         {
+                 "Path": "/test",
+                 "Kind": 1
+         }
+    ]
+
+Values for `Kind`:
+
+- `0`: Modify
+- `1`: Add
+- `2`: Delete
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Export a container
+
+`GET /containers/(id or name)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+    GET /v1.23/containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/octet-stream
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Get container stats based on resource usage
+
+`GET /containers/(id or name)/stats`
+
+This endpoint returns a live stream of a container's resource usage statistics.
+
+**Example request**:
+
+    GET /v1.23/containers/redis1/stats HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Type: application/json
+
+      {
+         "read" : "2015-01-08T22:57:31.547920715Z",
+         "pids_stats": {
+            "current": 3
+         },
+         "networks": {
+                 "eth0": {
+                     "rx_bytes": 5338,
+                     "rx_dropped": 0,
+                     "rx_errors": 0,
+                     "rx_packets": 36,
+                     "tx_bytes": 648,
+                     "tx_dropped": 0,
+                     "tx_errors": 0,
+                     "tx_packets": 8
+                 },
+                 "eth5": {
+                     "rx_bytes": 4641,
+                     "rx_dropped": 0,
+                     "rx_errors": 0,
+                     "rx_packets": 26,
+                     "tx_bytes": 690,
+                     "tx_dropped": 0,
+                     "tx_errors": 0,
+                     "tx_packets": 9
+                 }
+         },
+         "memory_stats" : {
+            "stats" : {
+               "total_pgmajfault" : 0,
+               "cache" : 0,
+               "mapped_file" : 0,
+               "total_inactive_file" : 0,
+               "pgpgout" : 414,
+               "rss" : 6537216,
+               "total_mapped_file" : 0,
+               "writeback" : 0,
+               "unevictable" : 0,
+               "pgpgin" : 477,
+               "total_unevictable" : 0,
+               "pgmajfault" : 0,
+               "total_rss" : 6537216,
+               "total_rss_huge" : 6291456,
+               "total_writeback" : 0,
+               "total_inactive_anon" : 0,
+               "rss_huge" : 6291456,
+               "hierarchical_memory_limit" : 67108864,
+               "total_pgfault" : 964,
+               "total_active_file" : 0,
+               "active_anon" : 6537216,
+               "total_active_anon" : 6537216,
+               "total_pgpgout" : 414,
+               "total_cache" : 0,
+               "inactive_anon" : 0,
+               "active_file" : 0,
+               "pgfault" : 964,
+               "inactive_file" : 0,
+               "total_pgpgin" : 477
+            },
+            "max_usage" : 6651904,
+            "usage" : 6537216,
+            "failcnt" : 0,
+            "limit" : 67108864
+         },
+         "blkio_stats" : {},
+         "cpu_stats" : {
+            "cpu_usage" : {
+               "percpu_usage" : [
+                  8646879,
+                  24472255,
+                  36438778,
+                  30657443
+               ],
+               "usage_in_usermode" : 50000000,
+               "total_usage" : 100215355,
+               "usage_in_kernelmode" : 30000000
+            },
+            "system_cpu_usage" : 739306590000000,
+            "throttling_data" : {"periods":0,"throttled_periods":0,"throttled_time":0}
+         },
+         "precpu_stats" : {
+            "cpu_usage" : {
+               "percpu_usage" : [
+                  8646879,
+                  24350896,
+                  36438778,
+                  30657443
+               ],
+               "usage_in_usermode" : 50000000,
+               "total_usage" : 100093996,
+               "usage_in_kernelmode" : 30000000
+            },
+            "system_cpu_usage" : 9492140000000,
+            "throttling_data" : {"periods":0,"throttled_periods":0,"throttled_time":0}
+         }
+      }
+
+The `precpu_stats` is the cpu statistic of *previous* read, which is used for calculating the cpu usage percent. It is not the exact copy of the `cpu_stats` field.
+
+**Query parameters**:
+
+-   **stream** – 1/True/true or 0/False/false, pull stats once then disconnect. Default `true`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Resize a container TTY
+
+`POST /containers/(id or name)/resize`
+
+Resize the TTY for container with  `id`. The unit is number of characters. You must restart the container for the resize to take effect.
+
+**Example request**:
+
+      POST /v1.23/containers/4fa6e0f0c678/resize?h=40&w=80 HTTP/1.1
+
+**Example response**:
+
+      HTTP/1.1 200 OK
+      Content-Length: 0
+      Content-Type: text/plain; charset=utf-8
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – No such container
+-   **500** – Cannot resize container
+
+#### Start a container
+
+`POST /containers/(id or name)/start`
+
+Start the container `id`
+
+> **Note**:
+> For backwards compatibility, this endpoint accepts a `HostConfig` as JSON-encoded request body.
+> See [create a container](#create-a-container) for details.
+
+**Example request**:
+
+    POST /v1.23/containers/e90e34656806/start HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **detachKeys** – Override the key sequence for detaching a
+        container. Format is a single character `[a-Z]` or `ctrl-<value>`
+        where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already started
+-   **404** – no such container
+-   **500** – server error
+
+#### Stop a container
+
+`POST /containers/(id or name)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+    POST /v1.23/containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **304** – container already stopped
+-   **404** – no such container
+-   **500** – server error
+
+#### Restart a container
+
+`POST /containers/(id or name)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+    POST /v1.23/containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **t** – number of seconds to wait before killing the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Kill a container
+
+`POST /containers/(id or name)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+    POST /v1.23/containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **signal** - Signal to send to the container: integer or string like `SIGINT`.
+        When not set, `SIGKILL` is assumed and the call waits for the container to exit.
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Update a container
+
+`POST /containers/(id or name)/update`
+
+Update configuration of one or more containers.
+
+**Example request**:
+
+       POST /v1.23/containers/e90e34656806/update HTTP/1.1
+       Content-Type: application/json
+       Content-Length: 12345
+
+       {
+         "BlkioWeight": 300,
+         "CpuShares": 512,
+         "CpuPeriod": 100000,
+         "CpuQuota": 50000,
+         "CpusetCpus": "0,1",
+         "CpusetMems": "0",
+         "Memory": 314572800,
+         "MemorySwap": 514288000,
+         "MemoryReservation": 209715200,
+         "KernelMemory": 52428800,
+         "RestartPolicy": {
+           "MaximumRetryCount": 4,
+           "Name": "on-failure"
+         }
+       }
+
+**Example response**:
+
+       HTTP/1.1 200 OK
+       Content-Type: application/json
+
+       {
+           "Warnings": []
+       }
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+#### Rename a container
+
+`POST /containers/(id or name)/rename`
+
+Rename the container `id` to a `new_name`
+
+**Example request**:
+
+    POST /v1.23/containers/e90e34656806/rename?name=new_name HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **name** – new name for the container
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **409** - conflict name already assigned
+-   **500** – server error
+
+#### Pause a container
+
+`POST /containers/(id or name)/pause`
+
+Pause the container `id`
+
+**Example request**:
+
+    POST /v1.23/containers/e90e34656806/pause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Unpause a container
+
+`POST /containers/(id or name)/unpause`
+
+Unpause the container `id`
+
+**Example request**:
+
+    POST /v1.23/containers/e90e34656806/unpause HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Attach to a container
+
+`POST /containers/(id or name)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+    POST /v1.23/containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 101 UPGRADED
+    Content-Type: application/vnd.docker.raw-stream
+    Connection: Upgrade
+    Upgrade: tcp
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **detachKeys** – Override the key sequence for detaching a
+        container. Format is a single character `[a-Z]` or `ctrl-<value>`
+        where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+-   **stdin** – 1/True/true or 0/False/false, if `stream=true`, attach
+        to `stdin`. Default `false`.
+-   **stdout** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stdout` log, if `stream=true`, attach to `stdout`. Default `false`.
+-   **stderr** – 1/True/true or 0/False/false, if `logs=true`, return
+        `stderr` log, if `stream=true`, attach to `stderr`. Default `false`.
+
+**Status codes**:
+
+-   **101** – no error, hints proxy about hijacking
+-   **200** – no error, no upgrade header found
+-   **400** – bad parameter
+-   **404** – no such container
+-   **409** - container is paused
+-   **500** – server error
+
+**Stream details**:
+
+When using the TTY setting is enabled in
+[`POST /containers/create`
+](#create-a-container),
+the stream is the raw data from the process PTY and client's `stdin`.
+When the TTY is disabled, then the stream is multiplexed to separate
+`stdout` and `stderr`.
+
+The format is a **Header** and a **Payload** (frame).
+
+**HEADER**
+
+The header contains the information which the stream writes (`stdout` or
+`stderr`). It also contains the size of the associated frame encoded in the
+last four bytes (`uint32`).
+
+It is encoded on the first eight bytes like this:
+
+    header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+`STREAM_TYPE` can be:
+
+-   0: `stdin` (is written on `stdout`)
+-   1: `stdout`
+-   2: `stderr`
+
+`SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of
+the `uint32` size encoded as big endian.
+
+**PAYLOAD**
+
+The payload is the raw stream.
+
+**IMPLEMENTATION**
+
+The simplest way to implement the Attach protocol is the following:
+
+    1.  Read eight bytes.
+    2.  Choose `stdout` or `stderr` depending on the first byte.
+    3.  Extract the frame size from the last four bytes.
+    4.  Read the extracted size and output it on the correct output.
+    5.  Goto 1.
+
+#### Attach to a container (websocket)
+
+`GET /containers/(id or name)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+    GET /v1.23/containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**Query parameters**:
+
+-   **detachKeys** – Override the key sequence for detaching a
+        container. Format is a single character `[a-Z]` or `ctrl-<value>`
+        where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+-   **logs** – 1/True/true or 0/False/false, return logs. Default `false`.
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default `false`.
+
+**Status codes**:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+#### Wait a container
+
+`POST /containers/(id or name)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+    POST /v1.23/containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"StatusCode": 0}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Remove a container
+
+`DELETE /containers/(id or name)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.23/containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Query parameters**:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default `false`.
+-   **force** - 1/True/true or 0/False/false, Kill then remove the container.
+        Default `false`.
+-   **link** - 1/True/true or 0/False/false, Remove the specified
+        link associated to the container. Default `false`.
+
+**Status codes**:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **409** – conflict
+-   **500** – server error
+
+#### Copy files or folders from a container
+
+`POST /containers/(id or name)/copy`
+
+Copy files or folders of container `id`
+
+**Deprecated** in favor of the `archive` endpoint below.
+
+**Example request**:
+
+    POST /v1.23/containers/4fa6e0f0c678/copy HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Resource": "test.txt"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Retrieving information about files and folders in a container
+
+`HEAD /containers/(id or name)/archive`
+
+See the description of the `X-Docker-Container-Path-Stat` header in the
+following section.
+
+#### Get an archive of a filesystem resource in a container
+
+`GET /containers/(id or name)/archive`
+
+Get a tar archive of a resource in the filesystem of container `id`.
+
+**Query parameters**:
+
+- **path** - resource in the container's filesystem to archive. Required.
+
+    If not an absolute path, it is relative to the container's root directory.
+    The resource specified by **path** must exist. To assert that the resource
+    is expected to be a directory, **path** should end in `/` or  `/.`
+    (assuming a path separator of `/`). If **path** ends in `/.` then this
+    indicates that only the contents of the **path** directory should be
+    copied. A symlink is always resolved to its target.
+
+    > **Note**: It is not possible to copy certain system files such as resources
+    > under `/proc`, `/sys`, `/dev`, and mounts created by the user in the
+    > container.
+
+**Example request**:
+
+    GET /v1.23/containers/8cce319429b2/archive?path=/root HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+    X-Docker-Container-Path-Stat: eyJuYW1lIjoicm9vdCIsInNpemUiOjQwOTYsIm1vZGUiOjIxNDc0ODQwOTYsIm10aW1lIjoiMjAxNC0wMi0yN1QyMDo1MToyM1oiLCJsaW5rVGFyZ2V0IjoiIn0=
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+On success, a response header `X-Docker-Container-Path-Stat` will be set to a
+base64-encoded JSON object containing some filesystem header information about
+the archived resource. The above example value would decode to the following
+JSON object (whitespace added for readability):
+
+```json
+{
+    "name": "root",
+    "size": 4096,
+    "mode": 2147484096,
+    "mtime": "2014-02-27T20:51:23Z",
+    "linkTarget": ""
+}
+```
+
+A `HEAD` request can also be made to this endpoint if only this information is
+desired.
+
+**Status codes**:
+
+- **200** - success, returns archive of copied resource
+- **400** - client error, bad parameter, details in JSON response body, one of:
+    - must specify path parameter (**path** cannot be empty)
+    - not a directory (**path** was asserted to be a directory but exists as a
+      file)
+- **404** - client error, resource not found, one of:
+    – no such container (container `id` does not exist)
+    - no such file or directory (**path** does not exist)
+- **500** - server error
+
+#### Extract an archive of files or folders to a directory in a container
+
+`PUT /containers/(id or name)/archive`
+
+Upload a tar archive to be extracted to a path in the filesystem of container
+`id`.
+
+**Query parameters**:
+
+- **path** - path to a directory in the container
+    to extract the archive's contents into. Required.
+
+    If not an absolute path, it is relative to the container's root directory.
+    The **path** resource must exist.
+- **noOverwriteDirNonDir** - If "1", "true", or "True" then it will be an error
+    if unpacking the given content would cause an existing directory to be
+    replaced with a non-directory and vice versa.
+
+**Example request**:
+
+    PUT /v1.23/containers/8cce319429b2/archive?path=/vol1 HTTP/1.1
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+- **200** – the content was extracted successfully
+- **400** - client error, bad parameter, details in JSON response body, one of:
+    - must specify path parameter (**path** cannot be empty)
+    - not a directory (**path** should be a directory but exists as a file)
+    - unable to overwrite existing directory with non-directory
+      (if **noOverwriteDirNonDir**)
+    - unable to overwrite existing non-directory with directory
+      (if **noOverwriteDirNonDir**)
+- **403** - client error, permission denied, the volume
+    or container rootfs is marked as read-only.
+- **404** - client error, resource not found, one of:
+    – no such container (container `id` does not exist)
+    - no such file or directory (**path** resource does not exist)
+- **500** – server error
+
+### 2.2 Images
+
+#### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+    GET /v1.23/images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+         "RepoTags": [
+           "ubuntu:12.04",
+           "ubuntu:precise",
+           "ubuntu:latest"
+         ],
+         "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+         "Created": 1365714795,
+         "Size": 131506275,
+         "VirtualSize": 131506275,
+         "Labels": {}
+      },
+      {
+         "RepoTags": [
+           "ubuntu:12.10",
+           "ubuntu:quantal"
+         ],
+         "ParentId": "27cf784147099545",
+         "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+         "Created": 1364102658,
+         "Size": 24653,
+         "VirtualSize": 180116135,
+         "Labels": {
+            "com.example.version": "v1"
+         }
+      }
+    ]
+
+**Example request, with digest information**:
+
+    GET /v1.23/images/json?digests=1 HTTP/1.1
+
+**Example response, with digest information**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+      {
+        "Created": 1420064636,
+        "Id": "4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125",
+        "ParentId": "ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2",
+        "RepoDigests": [
+          "localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf"
+        ],
+        "RepoTags": [
+          "localhost:5000/test/busybox:latest",
+          "playdate:latest"
+        ],
+        "Size": 0,
+        "VirtualSize": 2429728,
+        "Labels": {}
+      }
+    ]
+
+The response shows a single image `Id` associated with two repositories
+(`RepoTags`): `localhost:5000/test/busybox`: and `playdate`. A caller can use
+either of the `RepoTags` values `localhost:5000/test/busybox:latest` or
+`playdate:latest` to reference the image.
+
+You can also use `RepoDigests` values to reference an image. In this response,
+the array has only one reference and that is to the
+`localhost:5000/test/busybox` repository; the `playdate` repository has no
+digest. You can reference this digest using the value:
+`localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d...`
+
+See the `docker run` and `docker build` commands for examples of digest and tag
+references on the command line.
+
+**Query parameters**:
+
+-   **all** – 1/True/true or 0/False/false, default false
+-   **filters** – a JSON encoded value of the filters (a map[string][]string) to process on the images list. Available filters:
+  -   `dangling=true`
+  -   `label=key` or `label="key=value"` of an image label
+-   **filter** - only return images with the specified name
+
+#### Build image from a Dockerfile
+
+`POST /build`
+
+Build an image from a Dockerfile
+
+**Example request**:
+
+    POST /v1.23/build HTTP/1.1
+    Content-Type: application/x-tar
+
+    {% raw %}
+    {{ TAR STREAM }}
+    {% endraw %}
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"stream": "Step 1/5..."}
+    {"stream": "..."}
+    {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+The input stream must be a `tar` archive compressed with one of the
+following algorithms: `identity` (no compression), `gzip`, `bzip2`, `xz`.
+
+The archive must include a build instructions file, typically called
+`Dockerfile` at the archive's root. The `dockerfile` parameter may be
+used to specify a different build instructions file. To do this, its value must be
+the path to the alternate build instructions file to use.
+
+The archive may include any number of other files,
+which are accessible in the build context (See the [*ADD build
+command*](https://docs.docker.com/engine/reference/builder/#add)).
+
+The Docker daemon performs a preliminary validation of the `Dockerfile` before
+starting the build, and returns an error if the syntax is incorrect. After that,
+each instruction is run one-by-one until the ID of the new image is output.
+
+The build is canceled if the client drops the connection by quitting
+or being killed.
+
+**Query parameters**:
+
+-   **dockerfile** - Path within the build context to the `Dockerfile`. This is
+        ignored if `remote` is specified and points to an external `Dockerfile`.
+-   **t** – A name and optional tag to apply to the image in the `name:tag` format.
+        If you omit the `tag` the default `latest` value is assumed.
+        You can provide one or more `t` parameters.
+-   **remote** – A Git repository URI or HTTP/HTTPS context URI. If the
+        URI points to a single text file, the file's contents are placed into
+        a file called `Dockerfile` and the image is built from that file. If
+        the URI points to a tarball, the file is downloaded by the daemon and
+        the contents therein used as the context for the build. If the URI
+        points to a tarball and the `dockerfile` parameter is also specified,
+        there must be a file with the corresponding path inside the tarball.
+-   **q** – Suppress verbose build output.
+-   **nocache** – Do not use the cache when building the image.
+-   **pull** - Attempt to pull the image even if an older image exists locally.
+-   **rm** - Remove intermediate containers after a successful build (default behavior).
+-   **forcerm** - Always remove intermediate containers (includes `rm`).
+-   **memory** - Set memory limit for build.
+-   **memswap** - Total memory (memory + swap), `-1` to enable unlimited swap.
+-   **cpushares** - CPU shares (relative weight).
+-   **cpusetcpus** - CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+-   **cpuperiod** - The length of a CPU period in microseconds.
+-   **cpuquota** - Microseconds of CPU time that the container can get in a CPU period.
+-   **buildargs** – JSON map of string pairs for build-time variables. Users pass
+        these values at build-time. Docker uses the `buildargs` as the environment
+        context for command(s) run via the Dockerfile's `RUN` instruction or for
+        variable expansion in other Dockerfile instructions. This is not meant for
+        passing secret values. [Read more about the buildargs instruction](https://docs.docker.com/engine/reference/builder/#arg)
+-   **shmsize** - Size of `/dev/shm` in bytes. The size must be greater than 0.  If omitted the system uses 64MB.
+-   **labels** – JSON map of string pairs for labels to set on the image.
+
+**Request Headers**:
+
+-   **Content-type** – Set to `"application/x-tar"`.
+-   **X-Registry-Config** – A base64-url-safe-encoded Registry Auth Config JSON
+        object with the following structure:
+
+            {
+                "docker.example.com": {
+                    "username": "janedoe",
+                    "password": "hunter2"
+                },
+                "https://index.docker.io/v1/": {
+                    "username": "mobydock",
+                    "password": "conta1n3rize14"
+                }
+            }
+
+    This object maps the hostname of a registry to an object containing the
+    "username" and "password" for that registry. Multiple registries may
+    be specified as the build may be based on an image requiring
+    authentication to pull from any arbitrary registry. Only the registry
+    domain name (and port if not the default "443") are required. However
+    (for legacy reasons) the "official" Docker, Inc. hosted registry must
+    be specified with both a "https://" prefix and a "/v1/" suffix even
+    though Docker will prefer to use the v2 registry API.
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Create an image
+
+`POST /images/create`
+
+Create an image either by pulling it from the registry or by importing it
+
+**Example request**:
+
+    POST /v1.23/images/create?fromImage=busybox&tag=latest HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pulling..."}
+    {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+    {"error": "Invalid..."}
+    ...
+
+When using this endpoint to pull an image from the registry, the
+`X-Registry-Auth` header can be used to include
+a base64-encoded AuthConfig object.
+
+**Query parameters**:
+
+-   **fromImage** – Name of the image to pull. The name may include a tag or
+        digest. This parameter may only be used when pulling an image.
+        The pull is cancelled if the HTTP connection is closed.
+-   **fromSrc** – Source to import.  The value may be a URL from which the image
+        can be retrieved or `-` to read the image from the request body.
+        This parameter may only be used when importing an image.
+-   **repo** – Repository name given to an image when it is imported.
+        The repo may include a tag. This parameter may only be used when importing
+        an image.
+-   **tag** – Tag or digest. If empty when pulling an image, this causes all tags
+        for the given image to be pulled.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object, containing either login information, or a token
+    - Credential based login:
+
+        ```
+    {
+            "username": "jdoe",
+            "password": "secret",
+            "email": "jdoe@acme.com"
+    }
+        ```
+
+    - Token based login:
+
+        ```
+    {
+            "identitytoken": "9cbaf023786cd7..."
+    }
+        ```
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** - repository does not exist or no read access
+-   **500** – server error
+
+
+
+#### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+    GET /v1.23/images/example/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+       "Id" : "sha256:85f05633ddc1c50679be2b16a0479ab6f7637f8884e0cfe0f4d20e1ebb3d6e7c",
+       "Container" : "cb91e48a60d01f1e27028b4fc6819f4f290b3cf12496c8176ec714d0d390984a",
+       "Comment" : "",
+       "Os" : "linux",
+       "Architecture" : "amd64",
+       "Parent" : "sha256:91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c",
+       "ContainerConfig" : {
+          "Tty" : false,
+          "Hostname" : "e611e15f9c9d",
+          "Volumes" : null,
+          "Domainname" : "",
+          "AttachStdout" : false,
+          "PublishService" : "",
+          "AttachStdin" : false,
+          "OpenStdin" : false,
+          "StdinOnce" : false,
+          "NetworkDisabled" : false,
+          "OnBuild" : [],
+          "Image" : "91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c",
+          "User" : "",
+          "WorkingDir" : "",
+          "Entrypoint" : null,
+          "MacAddress" : "",
+          "AttachStderr" : false,
+          "Labels" : {
+             "com.example.license" : "GPL",
+             "com.example.version" : "1.0",
+             "com.example.vendor" : "Acme"
+          },
+          "Env" : [
+             "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+          ],
+          "ExposedPorts" : null,
+          "Cmd" : [
+             "/bin/sh",
+             "-c",
+             "#(nop) LABEL com.example.vendor=Acme com.example.license=GPL com.example.version=1.0"
+          ]
+       },
+       "DockerVersion" : "1.9.0-dev",
+       "VirtualSize" : 188359297,
+       "Size" : 0,
+       "Author" : "",
+       "Created" : "2015-09-10T08:30:53.26995814Z",
+       "GraphDriver" : {
+          "Name" : "aufs",
+          "Data" : null
+       },
+       "RepoDigests" : [
+          "localhost:5000/test/busybox/example@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf"
+       ],
+       "RepoTags" : [
+          "example:1.0",
+          "example:latest",
+          "example:stable"
+       ],
+       "Config" : {
+          "Image" : "91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c",
+          "NetworkDisabled" : false,
+          "OnBuild" : [],
+          "StdinOnce" : false,
+          "PublishService" : "",
+          "AttachStdin" : false,
+          "OpenStdin" : false,
+          "Domainname" : "",
+          "AttachStdout" : false,
+          "Tty" : false,
+          "Hostname" : "e611e15f9c9d",
+          "Volumes" : null,
+          "Cmd" : [
+             "/bin/bash"
+          ],
+          "ExposedPorts" : null,
+          "Env" : [
+             "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+          ],
+          "Labels" : {
+             "com.example.vendor" : "Acme",
+             "com.example.version" : "1.0",
+             "com.example.license" : "GPL"
+          },
+          "Entrypoint" : null,
+          "MacAddress" : "",
+          "AttachStderr" : false,
+          "WorkingDir" : "",
+          "User" : ""
+       },
+       "RootFS": {
+           "Type": "layers",
+           "Layers": [
+               "sha256:1834950e52ce4d5a88a1bbd131c537f4d0e56d10ff0dd69e66be3b7dfa9df7e6",
+               "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"
+           ]
+       }
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+    GET /v1.23/images/ubuntu/history HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+        {
+            "Id": "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710",
+            "Created": 1398108230,
+            "CreatedBy": "/bin/sh -c #(nop) ADD file:eb15dbd63394e063b805a3c32ca7bf0266ef64676d5a6fab4801f2e81e2a5148 in /",
+            "Tags": [
+                "ubuntu:lucid",
+                "ubuntu:10.04"
+            ],
+            "Size": 182964289,
+            "Comment": ""
+        },
+        {
+            "Id": "6cfa4d1f33fb861d4d114f43b25abd0ac737509268065cdfd69d544a59c85ab8",
+            "Created": 1398108222,
+            "CreatedBy": "/bin/sh -c #(nop) MAINTAINER Tianon Gravi <admwiggin@gmail.com> - mkimage-debootstrap.sh -i iproute,iputils-ping,ubuntu-minimal -t lucid.tar.xz lucid http://archive.ubuntu.com/ubuntu/",
+            "Tags": null,
+            "Size": 0,
+            "Comment": ""
+        },
+        {
+            "Id": "511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158",
+            "Created": 1371157430,
+            "CreatedBy": "",
+            "Tags": [
+                "scratch12:latest",
+                "scratch:latest"
+            ],
+            "Size": 0,
+            "Comment": "Imported from -"
+        }
+    ]
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+    POST /v1.23/images/test/push HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {"status": "Pushing..."}
+    {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+    {"error": "Invalid..."}
+    ...
+
+If you wish to push an image on to a private registry, that image must already have a tag
+into a repository which references that registry `hostname` and `port`.  This repository name should
+then be used in the URL. This duplicates the command line's flow.
+
+The push is cancelled if the HTTP connection is closed.
+
+**Example request**:
+
+    POST /v1.23/images/registry.acme.com:5000/test/push HTTP/1.1
+
+
+**Query parameters**:
+
+-   **tag** – The tag to associate with the image on the registry. This is optional.
+
+**Request Headers**:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object, containing either login information, or a token
+    - Credential based login:
+
+        ```
+    {
+            "username": "jdoe",
+            "password": "secret",
+            "email": "jdoe@acme.com",
+    }
+        ```
+
+    - Identity token based login:
+
+        ```
+    {
+            "identitytoken": "9cbaf023786cd7..."
+    }
+        ```
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+#### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+    POST /v1.23/images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+
+**Query parameters**:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+**Status codes**:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+    DELETE /v1.23/images/test HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-type: application/json
+
+    [
+     {"Untagged": "3e2f21a89f"},
+     {"Deleted": "3e2f21a89f"},
+     {"Deleted": "53b4f83ac9"}
+    ]
+
+**Query parameters**:
+
+-   **force** – 1/True/true or 0/False/false, default false
+-   **noprune** – 1/True/true or 0/False/false, default false
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+#### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+    GET /v1.23/images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    [
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "wma55/u1210sshd",
+                "star_count": 0
+            },
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "jdswinbank/sshd",
+                "star_count": 0
+            },
+            {
+                "description": "",
+                "is_official": false,
+                "is_automated": false,
+                "name": "vgauthier/sshd",
+                "star_count": 0
+            }
+    ...
+    ]
+
+**Query parameters**:
+
+-   **term** – term to search
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+### 2.3 Misc
+
+#### Check auth configuration
+
+`POST /auth`
+
+Validate credentials for a registry and get identity token,
+if available, for accessing the registry without password.
+
+**Example request**:
+
+    POST /v1.23/auth HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "username": "hannibal",
+         "password": "xxxx",
+         "serveraddress": "https://index.docker.io/v1/"
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+    {
+         "Status": "Login Succeeded",
+         "IdentityToken": "9cbaf023786cd7..."
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+#### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+    GET /v1.23/info HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+        "Architecture": "x86_64",
+        "ClusterStore": "etcd://localhost:2379",
+        "CgroupDriver": "cgroupfs",
+        "Containers": 11,
+        "ContainersRunning": 7,
+        "ContainersStopped": 3,
+        "ContainersPaused": 1,
+        "CpuCfsPeriod": true,
+        "CpuCfsQuota": true,
+        "Debug": false,
+        "DockerRootDir": "/var/lib/docker",
+        "Driver": "btrfs",
+        "DriverStatus": [[""]],
+        "ExecutionDriver": "native-0.1",
+        "ExperimentalBuild": false,
+        "HttpProxy": "http://test:test@localhost:8080",
+        "HttpsProxy": "https://test:test@localhost:8080",
+        "ID": "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS",
+        "IPv4Forwarding": true,
+        "Images": 16,
+        "IndexServerAddress": "https://index.docker.io/v1/",
+        "InitPath": "/usr/bin/docker",
+        "InitSha1": "",
+        "KernelMemory": true,
+        "KernelVersion": "3.12.0-1-amd64",
+        "Labels": [
+            "storage=ssd"
+        ],
+        "MemTotal": 2099236864,
+        "MemoryLimit": true,
+        "NCPU": 1,
+        "NEventsListener": 0,
+        "NFd": 11,
+        "NGoroutines": 21,
+        "Name": "prod-server-42",
+        "NoProxy": "9.81.1.160",
+        "OomKillDisable": true,
+        "OSType": "linux",
+        "OperatingSystem": "Boot2Docker",
+        "Plugins": {
+            "Volume": [
+                "local"
+            ],
+            "Network": [
+                "null",
+                "host",
+                "bridge"
+            ]
+        },
+        "RegistryConfig": {
+            "IndexConfigs": {
+                "docker.io": {
+                    "Mirrors": null,
+                    "Name": "docker.io",
+                    "Official": true,
+                    "Secure": true
+                }
+            },
+            "InsecureRegistryCIDRs": [
+                "127.0.0.0/8"
+            ]
+        },
+        "ServerVersion": "1.9.0",
+        "SwapLimit": false,
+        "SystemStatus": [["State", "Healthy"]],
+        "SystemTime": "2015-03-10T11:11:23.730591467-07:00"
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+    GET /v1.23/version HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+         "Version": "1.11.0",
+         "Os": "linux",
+         "KernelVersion": "3.19.0-23-generic",
+         "GoVersion": "go1.4.2",
+         "GitCommit": "e75da4b",
+         "Arch": "amd64",
+         "ApiVersion": "1.23",
+         "BuildTime": "2015-12-01T07:09:13.444803460+00:00",
+         "Experimental": true
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Ping the docker server
+
+`GET /_ping`
+
+Ping the docker server
+
+**Example request**:
+
+    GET /v1.23/_ping HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: text/plain
+
+    OK
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+    POST /v1.23/commit?container=44c004db4b17&comment=message&repo=myrepo HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+         "Hostname": "",
+         "Domainname": "",
+         "User": "",
+         "AttachStdin": false,
+         "AttachStdout": true,
+         "AttachStderr": true,
+         "Tty": false,
+         "OpenStdin": false,
+         "StdinOnce": false,
+         "Env": null,
+         "Cmd": [
+                 "date"
+         ],
+         "Mounts": [
+           {
+             "Source": "/data",
+             "Destination": "/data",
+             "Mode": "ro,Z",
+             "RW": false
+           }
+         ],
+         "Labels": {
+                 "key1": "value1",
+                 "key2": "value2"
+          },
+         "WorkingDir": "",
+         "NetworkDisabled": false,
+         "ExposedPorts": {
+                 "22/tcp": {}
+         }
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {"Id": "596069db4bf5"}
+
+**JSON parameters**:
+
+-  **config** - the container's configuration
+
+**Query parameters**:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **comment** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+-   **pause** – 1/True/true or 0/False/false, whether to pause the container before committing
+-   **changes** – Dockerfile instructions to apply while committing
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+#### Monitor Docker's events
+
+`GET /events`
+
+Get container events from docker, in real time via streaming.
+
+Docker containers report the following events:
+
+    attach, commit, copy, create, destroy, die, exec_create, exec_start, export, kill, oom, pause, rename, resize, restart, start, stop, top, unpause, update
+
+Docker images report the following events:
+
+    delete, import, pull, push, tag, untag
+
+Docker volumes report the following events:
+
+    create, mount, unmount, destroy
+
+Docker networks report the following events:
+
+    create, connect, disconnect, destroy
+
+**Example request**:
+
+    GET /v1.23/events?since=1374067924
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+    Server: Docker/1.11.0 (linux)
+    Date: Fri, 29 Apr 2016 15:18:06 GMT
+    Transfer-Encoding: chunked
+
+    {
+      "status": "pull",
+      "id": "alpine:latest",
+      "Type": "image",
+      "Action": "pull",
+      "Actor": {
+        "ID": "alpine:latest",
+        "Attributes": {
+          "name": "alpine"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101301854122
+    }
+    {
+      "status": "create",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "create",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "image": "alpine",
+          "name": "my-container"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101381709551
+    }
+    {
+      "status": "attach",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "attach",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "image": "alpine",
+          "name": "my-container"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101383858412
+    }
+    {
+      "Type": "network",
+      "Action": "connect",
+      "Actor": {
+        "ID": "7dc8ac97d5d29ef6c31b6052f3938c1e8f2749abbd17d1bd1febf2608db1b474",
+        "Attributes": {
+          "container": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+          "name": "bridge",
+          "type": "bridge"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101394865557
+    }
+    {
+      "status": "start",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "start",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "image": "alpine",
+          "name": "my-container"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101607533796
+    }
+    {
+      "status": "resize",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "resize",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "height": "46",
+          "image": "alpine",
+          "name": "my-container",
+          "width": "204"
+        }
+      },
+      "time": 1461943101,
+      "timeNano": 1461943101610269268
+    }
+    {
+      "status": "die",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "die",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "exitCode": "0",
+          "image": "alpine",
+          "name": "my-container"
+        }
+      },
+      "time": 1461943105,
+      "timeNano": 1461943105079144137
+    }
+    {
+      "Type": "network",
+      "Action": "disconnect",
+      "Actor": {
+        "ID": "7dc8ac97d5d29ef6c31b6052f3938c1e8f2749abbd17d1bd1febf2608db1b474",
+        "Attributes": {
+          "container": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+          "name": "bridge",
+          "type": "bridge"
+        }
+      },
+      "time": 1461943105,
+      "timeNano": 1461943105230860245
+    }
+    {
+      "status": "destroy",
+      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+      "from": "alpine",
+      "Type": "container",
+      "Action": "destroy",
+      "Actor": {
+        "ID": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
+        "Attributes": {
+          "com.example.some-label": "some-label-value",
+          "image": "alpine",
+          "name": "my-container"
+        }
+      },
+      "time": 1461943105,
+      "timeNano": 1461943105338056026
+    }
+
+**Query parameters**:
+
+-   **since** – Timestamp. Show all events created since timestamp and then stream
+-   **until** – Timestamp. Show events created until given timestamp and stop streaming
+-   **filters** – A json encoded value of the filters (a map[string][]string) to process on the event list. Available filters:
+  -   `container=<string>`; -- container to filter
+  -   `event=<string>`; -- event to filter
+  -   `image=<string>`; -- image to filter
+  -   `label=<string>`; -- image and container label to filter
+  -   `type=<string>`; -- either `container` or `image` or `volume` or `network`
+  -   `volume=<string>`; -- volume to filter
+  -   `network=<string>`; -- network to filter
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository specified
+by `name`.
+
+If `name` is a specific name and tag (e.g. ubuntu:latest), then only that image
+(and its parents) are returned. If `name` is an image ID, similarly only that
+image (and its parents) are returned, but with the exclusion of the
+'repositories' file in the tarball, as there were no image names referenced.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.23/images/ubuntu/get
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Get a tarball containing all images
+
+`GET /images/get`
+
+Get a tarball containing all images and metadata for one or more repositories.
+
+For each value of the `names` parameter: if it is a specific name and tag (e.g.
+`ubuntu:latest`), then only that image (and its parents) are returned; if it is
+an image ID, similarly only that image (and its parents) are returned and there
+would be no names referenced in the 'repositories' file for this image ID.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    GET /v1.23/images/get?names=myname%2Fmyapp%3Alatest&names=busybox
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/x-tar
+
+    Binary data stream
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into a Docker repository.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+    POST /v1.23/images/load
+    Content-Type: application/x-tar
+    Content-Length: 12345
+
+    Tarball in body
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+    Transfer-Encoding: chunked
+
+    {"status":"Loading layer","progressDetail":{"current":32768,"total":1292800},"progress":"[=                                                 ] 32.77 kB/1.293 MB","id":"8ac8bfaff55a"}
+    {"status":"Loading layer","progressDetail":{"current":65536,"total":1292800},"progress":"[==                                                ] 65.54 kB/1.293 MB","id":"8ac8bfaff55a"}
+    {"status":"Loading layer","progressDetail":{"current":98304,"total":1292800},"progress":"[===                                               ]  98.3 kB/1.293 MB","id":"8ac8bfaff55a"}
+    {"status":"Loading layer","progressDetail":{"current":131072,"total":1292800},"progress":"[=====                                             ] 131.1 kB/1.293 MB","id":"8ac8bfaff55a"}
+    ...
+    {"stream":"Loaded image: busybox:latest\n"}
+
+**Example response**:
+
+If the "quiet" query parameter is set to `true` / `1` (`?quiet=1`), progress
+details are suppressed, and only a confirmation message is returned once the
+action completes.
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+    Transfer-Encoding: chunked
+
+    {"stream":"Loaded image: busybox:latest\n"}
+
+**Query parameters**:
+
+-   **quiet** – Boolean value, suppress progress details during load. Defaults
+      to `0` / `false` if omitted.
+
+**Status codes**:
+
+-   **200** – no error
+-   **500** – server error
+
+#### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing these files:
+
+- `VERSION`: currently `1.0` - the file format version
+- `json`: detailed layer information, similar to `docker inspect layer_id`
+- `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file contains `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, the tarball should also include a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+#### Exec Create
+
+`POST /containers/(id or name)/exec`
+
+Sets up an exec instance in a running container `id`
+
+**Example request**:
+
+    POST /v1.23/containers/e90e34656806/exec HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+      "AttachStdin": true,
+      "AttachStdout": true,
+      "AttachStderr": true,
+      "Cmd": ["sh"],
+      "DetachKeys": "ctrl-p,ctrl-q",
+      "Privileged": true,
+      "Tty": true,
+      "User": "123:456"
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {
+         "Id": "f90e34656806",
+         "Warnings":[]
+    }
+
+**JSON parameters**:
+
+-   **AttachStdin** - Boolean value, attaches to `stdin` of the `exec` command.
+-   **AttachStdout** - Boolean value, attaches to `stdout` of the `exec` command.
+-   **AttachStderr** - Boolean value, attaches to `stderr` of the `exec` command.
+-   **DetachKeys** – Override the key sequence for detaching a
+        container. Format is a single character `[a-Z]` or `ctrl-<value>`
+        where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+-   **Cmd** - Command to run specified as a string or an array of strings.
+-   **Privileged** - Boolean value, runs the exec process with extended privileges.
+-   **User** - A string value specifying the user, and optionally, group to run
+        the exec process inside the container. Format is one of: `"user"`,
+        `"user:group"`, `"uid"`, or `"uid:gid"`.
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such container
+-   **409** - container is paused
+-   **500** - server error
+
+#### Exec Start
+
+`POST /exec/(id)/start`
+
+Starts a previously set up `exec` instance `id`. If `detach` is true, this API
+returns after starting the `exec` command. Otherwise, this API sets up an
+interactive session with the `exec` command.
+
+**Example request**:
+
+    POST /v1.23/exec/e90e34656806/start HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+     "Detach": false,
+     "Tty": false
+    }
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/vnd.docker.raw-stream
+
+    {% raw %}
+    {{ STREAM }}
+    {% endraw %}
+
+**JSON parameters**:
+
+-   **Detach** - Detach from the `exec` command.
+-   **Tty** - Boolean value to allocate a pseudo-TTY.
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+-   **409** - container is paused
+
+**Stream details**:
+
+Similar to the stream behavior of `POST /containers/(id or name)/attach` API
+
+#### Exec Resize
+
+`POST /exec/(id)/resize`
+
+Resizes the `tty` session used by the `exec` command `id`.  The unit is number of characters.
+This API is valid only if `tty` was specified as part of creating and starting the `exec` command.
+
+**Example request**:
+
+    POST /v1.23/exec/e90e34656806/resize?h=40&w=80 HTTP/1.1
+    Content-Type: text/plain
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: text/plain
+
+**Query parameters**:
+
+-   **h** – height of `tty` session
+-   **w** – width
+
+**Status codes**:
+
+-   **201** – no error
+-   **404** – no such exec instance
+
+#### Exec Inspect
+
+`GET /exec/(id)/json`
+
+Return low-level information about the `exec` command `id`.
+
+**Example request**:
+
+    GET /v1.23/exec/11fb006128e8ceb3942e7c58d77750f24210e35f879dd204ac975c184b820b39/json HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "CanRemove": false,
+      "ContainerID": "b53ee82b53a40c7dca428523e34f741f3abc51d9f297a14ff874bf761b995126",
+      "DetachKeys": "",
+      "ExitCode": 2,
+      "ID": "f33bbfb39f5b142420f4759b2348913bd4a8d1a6d7fd56499cb41a1bb91d7b3b",
+      "OpenStderr": true,
+      "OpenStdin": true,
+      "OpenStdout": true,
+      "ProcessConfig": {
+        "arguments": [
+          "-c",
+          "exit 2"
+        ],
+        "entrypoint": "sh",
+        "privileged": false,
+        "tty": true,
+        "user": "1000"
+      },
+      "Running": false
+    }
+
+**Status codes**:
+
+-   **200** – no error
+-   **404** – no such exec instance
+-   **500** - server error
+
+### 2.4 Volumes
+
+#### List volumes
+
+`GET /volumes`
+
+**Example request**:
+
+    GET /v1.23/volumes HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Volumes": [
+        {
+          "Name": "tardis",
+          "Driver": "local",
+          "Mountpoint": "/var/lib/docker/volumes/tardis"
+        }
+      ],
+      "Warnings": []
+    }
+
+**Query parameters**:
+
+- **filters** - JSON encoded value of the filters (a `map[string][]string`) to process on the volumes list. There is one available filter: `dangling=true`
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Create a volume
+
+`POST /volumes/create`
+
+Create a volume
+
+**Example request**:
+
+    POST /v1.23/volumes/create HTTP/1.1
+    Content-Type: application/json
+    Content-Length: 12345
+
+    {
+      "Name": "tardis",
+      "Labels": {
+        "com.example.some-label": "some-value",
+        "com.example.some-other-label": "some-other-value"
+      }
+    }
+
+**Example response**:
+
+    HTTP/1.1 201 Created
+    Content-Type: application/json
+
+    {
+      "Name": "tardis",
+      "Driver": "local",
+      "Mountpoint": "/var/lib/docker/volumes/tardis",
+      "Labels": {
+        "com.example.some-label": "some-value",
+        "com.example.some-other-label": "some-other-value"
+      }
+    }
+
+**Status codes**:
+
+- **201** - no error
+- **500**  - server error
+
+**JSON parameters**:
+
+- **Name** - The new volume's name. If not specified, Docker generates a name.
+- **Driver** - Name of the volume driver to use. Defaults to `local` for the name.
+- **DriverOpts** - A mapping of driver options and values. These options are
+    passed directly to the driver and are driver specific.
+- **Labels** - Labels to set on the volume, specified as a map: `{"key":"value","key2":"value2"}`
+
+#### Inspect a volume
+
+`GET /volumes/(name)`
+
+Return low-level information on the volume `name`
+
+**Example request**:
+
+    GET /v1.23/volumes/tardis
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+    Content-Type: application/json
+
+    {
+      "Name": "tardis",
+      "Driver": "local",
+      "Mountpoint": "/var/lib/docker/volumes/tardis/_data",
+      "Labels": {
+          "com.example.some-label": "some-value",
+          "com.example.some-other-label": "some-other-value"
+      }
+    }
+
+**Status codes**:
+
+-   **200** - no error
+-   **404** - no such volume
+-   **500** - server error
+
+#### Remove a volume
+
+`DELETE /volumes/(name)`
+
+Instruct the driver to remove the volume (`name`).
+
+**Example request**:
+
+    DELETE /v1.23/volumes/tardis HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** - no error
+-   **404** - no such volume or volume driver
+-   **409** - volume is in use and cannot be removed
+-   **500** - server error
+
+### 3.5 Networks
+
+#### List networks
+
+`GET /networks`
+
+**Example request**:
+
+    GET /v1.23/networks?filters={"type":{"custom":true}} HTTP/1.1
+
+**Example response**:
+
+```
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+[
+  {
+    "Name": "bridge",
+    "Id": "f2de39df4171b0dc801e8002d1d999b77256983dfc63041c0f34030aa3977566",
+    "Scope": "local",
+    "Driver": "bridge",
+    "EnableIPv6": false,
+    "Internal": false,
+    "IPAM": {
+      "Driver": "default",
+      "Config": [
+        {
+          "Subnet": "172.17.0.0/16"
+        }
+      ]
+    },
+    "Containers": {
+      "39b69226f9d79f5634485fb236a23b2fe4e96a0a94128390a7fbbcc167065867": {
+        "EndpointID": "ed2419a97c1d9954d05b46e462e7002ea552f216e9b136b80a7db8d98b442eda",
+        "MacAddress": "02:42:ac:11:00:02",
+        "IPv4Address": "172.17.0.2/16",
+        "IPv6Address": ""
+      }
+    },
+    "Options": {
+      "com.docker.network.bridge.default_bridge": "true",
+      "com.docker.network.bridge.enable_icc": "true",
+      "com.docker.network.bridge.enable_ip_masquerade": "true",
+      "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
+      "com.docker.network.bridge.name": "docker0",
+      "com.docker.network.driver.mtu": "1500"
+    }
+  },
+  {
+    "Name": "none",
+    "Id": "e086a3893b05ab69242d3c44e49483a3bbbd3a26b46baa8f61ab797c1088d794",
+    "Scope": "local",
+    "Driver": "null",
+    "EnableIPv6": false,
+    "Internal": false,
+    "IPAM": {
+      "Driver": "default",
+      "Config": []
+    },
+    "Containers": {},
+    "Options": {}
+  },
+  {
+    "Name": "host",
+    "Id": "13e871235c677f196c4e1ecebb9dc733b9b2d2ab589e30c539efeda84a24215e",
+    "Scope": "local",
+    "Driver": "host",
+    "EnableIPv6": false,
+    "Internal": false,
+    "IPAM": {
+      "Driver": "default",
+      "Config": []
+    },
+    "Containers": {},
+    "Options": {}
+  }
+]
+```
+
+**Query parameters**:
+
+- **filters** - JSON encoded network list filter. The filter value is one of:
+  -   `id=<network-id>` Matches all or part of a network id.
+  -   `name=<network-name>` Matches all or part of a network name.
+  -   `type=["custom"|"builtin"]` Filters networks by type. The `custom` keyword returns all user-defined networks.
+
+**Status codes**:
+
+-   **200** - no error
+-   **500** - server error
+
+#### Inspect network
+
+`GET /networks/(id or name)`
+
+Return low-level information on the network `id`
+
+**Example request**:
+
+    GET /v1.23/networks/7d86d31b1478e7cca9ebed7e73aa0fdeec46c5ca29497431d3007d2d9e15ed99 HTTP/1.1
+
+**Example response**:
+
+```
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+{
+  "Name": "net01",
+  "Id": "7d86d31b1478e7cca9ebed7e73aa0fdeec46c5ca29497431d3007d2d9e15ed99",
+  "Scope": "local",
+  "Driver": "bridge",
+  "EnableIPv6": false,
+  "IPAM": {
+    "Driver": "default",
+    "Config": [
+      {
+        "Subnet": "172.19.0.0/16",
+        "Gateway": "172.19.0.1/16"
+      }
+    ],
+    "Options": {
+        "foo": "bar"
+    }
+  },
+  "Internal": false,
+  "Containers": {
+    "19a4d5d687db25203351ed79d478946f861258f018fe384f229f2efa4b23513c": {
+      "Name": "test",
+      "EndpointID": "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a",
+      "MacAddress": "02:42:ac:13:00:02",
+      "IPv4Address": "172.19.0.2/16",
+      "IPv6Address": ""
+    }
+  },
+  "Options": {
+    "com.docker.network.bridge.default_bridge": "true",
+    "com.docker.network.bridge.enable_icc": "true",
+    "com.docker.network.bridge.enable_ip_masquerade": "true",
+    "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
+    "com.docker.network.bridge.name": "docker0",
+    "com.docker.network.driver.mtu": "1500"
+  },
+  "Labels": {
+    "com.example.some-label": "some-value",
+    "com.example.some-other-label": "some-other-value"
+  }
+}
+```
+
+**Status codes**:
+
+-   **200** - no error
+-   **404** - network not found
+-   **500** - server error
+
+#### Create a network
+
+`POST /networks/create`
+
+Create a network
+
+**Example request**:
+
+```
+POST /v1.23/networks/create HTTP/1.1
+Content-Type: application/json
+Content-Length: 12345
+
+{
+  "Name":"isolated_nw",
+  "CheckDuplicate":true,
+  "Driver":"bridge",
+  "EnableIPv6": true,
+  "IPAM":{
+    "Driver": "default",
+    "Config":[
+      {
+        "Subnet":"172.20.0.0/16",
+        "IPRange":"172.20.10.0/24",
+        "Gateway":"172.20.10.11"
+      },
+      {
+        "Subnet":"2001:db8:abcd::/64",
+        "Gateway":"2001:db8:abcd::1011"
+      }
+    ],
+    "Options": {
+      "foo": "bar"
+    }
+  },
+  "Internal":true,
+  "Options": {
+    "com.docker.network.bridge.default_bridge": "true",
+    "com.docker.network.bridge.enable_icc": "true",
+    "com.docker.network.bridge.enable_ip_masquerade": "true",
+    "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
+    "com.docker.network.bridge.name": "docker0",
+    "com.docker.network.driver.mtu": "1500"
+  },
+  "Labels": {
+    "com.example.some-label": "some-value",
+    "com.example.some-other-label": "some-other-value"
+  }
+}
+```
+
+**Example response**:
+
+```
+HTTP/1.1 201 Created
+Content-Type: application/json
+
+{
+  "Id": "22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30",
+  "Warning": ""
+}
+```
+
+**Status codes**:
+
+- **201** - no error
+- **404** - plugin not found
+- **500** - server error
+
+**JSON parameters**:
+
+- **Name** - The new network's name. this is a mandatory field
+- **CheckDuplicate** - Requests daemon to check for networks with same name. Defaults to `false`.
+    Since Network is primarily keyed based on a random ID and not on the name, 
+    and network name is strictly a user-friendly alias to the network 
+    which is uniquely identified using ID, there is no guaranteed way to check for duplicates. 
+    This parameter CheckDuplicate is there to provide a best effort checking of any networks 
+    which has the same name but it is not guaranteed to catch all name collisions.
+- **Driver** - Name of the network driver plugin to use. Defaults to `bridge` driver
+- **Internal** - Restrict external access to the network
+- **IPAM** - Optional custom IP scheme for the network
+  - **Driver** - Name of the IPAM driver to use. Defaults to `default` driver
+  - **Config** - List of IPAM configuration options, specified as a map:
+      `{"Subnet": <CIDR>, "IPRange": <CIDR>, "Gateway": <IP address>, "AuxAddress": <device_name:IP address>}`
+  - **Options** - Driver-specific options, specified as a map: `{"option":"value" [,"option2":"value2"]}`
+- **EnableIPv6** - Enable IPv6 on the network
+- **Options** - Network specific options to be used by the drivers
+- **Labels** - Labels to set on the network, specified as a map: `{"key":"value" [,"key2":"value2"]}`
+
+#### Connect a container to a network
+
+`POST /networks/(id or name)/connect`
+
+Connect a container to a network
+
+**Example request**:
+
+```
+POST /v1.23/networks/22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30/connect HTTP/1.1
+Content-Type: application/json
+Content-Length: 12345
+
+{
+  "Container":"3613f73ba0e4",
+  "EndpointConfig": {
+    "IPAMConfig": {
+        "IPv4Address":"172.24.56.89",
+        "IPv6Address":"2001:db8::5689"
+    }
+  }
+}
+```
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+- **200** - no error
+- **404** - network or container is not found
+- **500** - Internal Server Error
+
+**JSON parameters**:
+
+- **container** - container-id/name to be connected to the network
+
+#### Disconnect a container from a network
+
+`POST /networks/(id or name)/disconnect`
+
+Disconnect a container from a network
+
+**Example request**:
+
+```
+POST /v1.23/networks/22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30/disconnect HTTP/1.1
+Content-Type: application/json
+Content-Length: 12345
+
+{
+  "Container":"3613f73ba0e4",
+  "Force":false
+}
+```
+
+**Example response**:
+
+    HTTP/1.1 200 OK
+
+**Status codes**:
+
+- **200** - no error
+- **404** - network or container not found
+- **500** - Internal Server Error
+
+**JSON parameters**:
+
+- **Container** - container-id/name to be disconnected from a network
+- **Force** - Force the container to disconnect from a network
+
+#### Remove a network
+
+`DELETE /networks/(id or name)`
+
+Instruct the driver to remove the network (`id`).
+
+**Example request**:
+
+    DELETE /v1.23/networks/22be93d5babb089c5aab8dbc369042fad48ff791584ca2da2100db837a1c7c30 HTTP/1.1
+
+**Example response**:
+
+    HTTP/1.1 204 No Content
+
+**Status codes**:
+
+-   **204** - no error
+-   **403** - operation not supported for pre-defined networks
+-   **404** - no such network
+-   **500** - server error
+
+## 3. Going further
+
+### 3.1 Inside `docker run`
+
+As an example, the `docker run` command line makes the following API calls:
+
+- Create the container
+
+- If the status code is 404, it means the image doesn't exist:
+    - Try to pull it.
+    - Then, retry to create the container.
+
+- Start the container.
+
+- If you are not in detached mode:
+- Attach to the container, using `logs=1` (to have `stdout` and
+      `stderr` from the container's start) and `stream=1`
+
+- If in detached mode or only `stdin` is attached, display the container's id.
+
+### 3.2 Hijacking
+
+In this version of the API, `/attach`, uses hijacking to transport `stdin`,
+`stdout`, and `stderr` on the same socket.
+
+To hint potential proxies about connection hijacking, Docker client sends
+connection upgrade headers similarly to websocket.
+
+    Upgrade: tcp
+    Connection: Upgrade
+
+When Docker daemon detects the `Upgrade` header, it switches its status code
+from **200 OK** to **101 UPGRADED** and resends the same headers.
+
+
+### 3.3 CORS Requests
+
+To set cross origin requests to the Engine API please give values to
+`--api-cors-header` when running Docker in daemon mode. Set * (asterisk) allows all,
+default or blank means CORS disabled
+
+    $ dockerd -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.24.md b/_vendor/github.com/moby/moby/api/docs/v1.24.md
similarity index 99%
rename from _vendor/github.com/moby/moby/docs/api/v1.24.md
rename to _vendor/github.com/moby/moby/api/docs/v1.24.md
index 45b4b3fdbb9e..2d374a4a8484 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.24.md
+++ b/_vendor/github.com/moby/moby/api/docs/v1.24.md
@@ -310,7 +310,6 @@ Create a container
              "Memory": 0,
              "MemorySwap": 0,
              "MemoryReservation": 0,
-             "KernelMemory": 0,
              "CpuPercent": 80,
              "CpuShares": 512,
              "CpuPeriod": 100000,
@@ -438,7 +437,6 @@ Create a container
     -   **MemorySwap** - Total memory limit (memory + swap); set `-1` to enable unlimited swap.
           You must use this with `memory` and make the swap value larger than `memory`.
     -   **MemoryReservation** - Memory soft limit in bytes.
-    -   **KernelMemory** - Kernel memory limit in bytes.
     -   **CpuPercent** - An integer value containing the usable percentage of the available CPUs. (Windows daemon only)
     -   **CpuShares** - An integer value containing the container's CPU Shares
           (ie. the relative weight vs other containers).
@@ -627,7 +625,6 @@ Return low-level information on the container `id`
 			"Memory": 0,
 			"MemorySwap": 0,
 			"MemoryReservation": 0,
-			"KernelMemory": 0,
 			"OomKillDisable": false,
 			"OomScoreAdj": 500,
 			"NetworkMode": "bridge",
@@ -1197,7 +1194,6 @@ Update configuration of one or more containers.
          "Memory": 314572800,
          "MemorySwap": 514288000,
          "MemoryReservation": 209715200,
-         "KernelMemory": 52428800,
          "RestartPolicy": {
            "MaximumRetryCount": 4,
            "Name": "on-failure"
@@ -1830,8 +1826,7 @@ a base64-encoded AuthConfig object.
         ```
     {
             "username": "jdoe",
-            "password": "secret",
-            "email": "jdoe@acme.com"
+            "password": "secret"
     }
         ```
 
@@ -2066,8 +2061,7 @@ The push is cancelled if the HTTP connection is closed.
         ```
     {
             "username": "jdoe",
-            "password": "secret",
-            "email": "jdoe@acme.com",
+            "password": "secret"
     }
         ```
 
@@ -2498,8 +2492,6 @@ Docker daemon report the following event:
     Transfer-Encoding: chunked
 
     {
-      "status": "pull",
-      "id": "alpine:latest",
       "Type": "image",
       "Action": "pull",
       "Actor": {
@@ -2512,9 +2504,6 @@ Docker daemon report the following event:
       "timeNano": 1461943101301854122
     }
     {
-      "status": "create",
-      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
-      "from": "alpine",
       "Type": "container",
       "Action": "create",
       "Actor": {
@@ -2529,9 +2518,6 @@ Docker daemon report the following event:
       "timeNano": 1461943101381709551
     }
     {
-      "status": "attach",
-      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
-      "from": "alpine",
       "Type": "container",
       "Action": "attach",
       "Actor": {
@@ -2560,9 +2546,6 @@ Docker daemon report the following event:
       "timeNano": 1461943101394865557
     }
     {
-      "status": "start",
-      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
-      "from": "alpine",
       "Type": "container",
       "Action": "start",
       "Actor": {
@@ -2577,9 +2560,6 @@ Docker daemon report the following event:
       "timeNano": 1461943101607533796
     }
     {
-      "status": "resize",
-      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
-      "from": "alpine",
       "Type": "container",
       "Action": "resize",
       "Actor": {
@@ -2596,9 +2576,6 @@ Docker daemon report the following event:
       "timeNano": 1461943101610269268
     }
     {
-      "status": "die",
-      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
-      "from": "alpine",
       "Type": "container",
       "Action": "die",
       "Actor": {
@@ -2628,9 +2605,6 @@ Docker daemon report the following event:
       "timeNano": 1461943105230860245
     }
     {
-      "status": "destroy",
-      "id": "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743",
-      "from": "alpine",
       "Type": "container",
       "Action": "destroy",
       "Actor": {
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.25.yaml b/_vendor/github.com/moby/moby/api/docs/v1.25.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.25.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.25.yaml
index 8a57a98d8729..aa9d190b4fb8 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.25.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.25.yaml
@@ -60,7 +60,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -130,6 +129,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -156,6 +183,20 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -167,13 +208,10 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
           - `tmpfs` a `tmpfs`.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -257,19 +295,20 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+        type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -320,7 +359,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
   RestartPolicy:
     description: |
@@ -432,10 +474,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -984,6 +1022,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -1975,6 +2017,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Networks:
         type: "array"
         items:
@@ -2712,7 +2755,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -3012,7 +3054,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 OomKillDisable: false
                 OomScoreAdj: 500
                 NetworkMode: "bridge"
@@ -3693,7 +3734,6 @@ paths:
               Memory: 314572800
               MemorySwap: 514288000
               MemoryReservation: 209715200
-              KernelMemory: 52428800
               RestartPolicy:
                 MaximumRetryCount: 4
                 Name: "on-failure"
@@ -4602,24 +4642,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              properties:
-                Id:
-                  type: "string"
-                Created:
-                  type: "integer"
-                  format: "int64"
-                CreatedBy:
-                  type: "string"
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                Comment:
-                  type: "string"
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -4712,7 +4735,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -5100,7 +5128,6 @@ paths:
               IndexServerAddress: "https://index.docker.io/v1/"
               InitPath: "/usr/bin/docker"
               InitSha1: ""
-              KernelMemory: true
               KernelVersion: "3.12.0-1-amd64"
               Labels:
                 - "storage=ssd"
@@ -6946,17 +6973,32 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.26.yaml b/_vendor/github.com/moby/moby/api/docs/v1.26.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.26.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.26.yaml
index 8de146c0733b..63b88964180c 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.26.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.26.yaml
@@ -60,7 +60,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -130,6 +129,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -156,6 +183,20 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -167,13 +208,10 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
           - `tmpfs` a `tmpfs`.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -257,19 +295,20 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+        type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -320,7 +359,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
   RestartPolicy:
     description: |
@@ -432,10 +474,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -984,6 +1022,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -1979,6 +2021,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Networks:
         type: "array"
         items:
@@ -2716,7 +2759,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -4610,24 +4652,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              properties:
-                Id:
-                  type: "string"
-                Created:
-                  type: "integer"
-                  format: "int64"
-                CreatedBy:
-                  type: "string"
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                Comment:
-                  type: "string"
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -4720,7 +4745,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -7017,17 +7047,32 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.27.yaml b/_vendor/github.com/moby/moby/api/docs/v1.27.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.27.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.27.yaml
index 3e4c1167cf5e..c8e021a33a5d 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.27.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.27.yaml
@@ -60,7 +60,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -132,6 +131,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -158,6 +185,20 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -169,13 +210,10 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
           - `tmpfs` a `tmpfs`.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -259,19 +297,20 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+        type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -322,7 +361,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
   RestartPolicy:
     description: |
@@ -434,10 +476,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -504,7 +542,9 @@ definitions:
         format: "int64"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -515,6 +555,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -989,6 +1035,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2051,6 +2101,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Networks:
         type: "array"
         items:
@@ -2775,7 +2826,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -3075,7 +3125,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 OomKillDisable: false
                 OomScoreAdj: 500
                 NetworkMode: "bridge"
@@ -4680,24 +4729,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              properties:
-                Id:
-                  type: "string"
-                Created:
-                  type: "integer"
-                  format: "int64"
-                CreatedBy:
-                  type: "string"
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                Comment:
-                  type: "string"
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -4790,7 +4822,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -7115,17 +7152,32 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.28.yaml b/_vendor/github.com/moby/moby/api/docs/v1.28.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.28.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.28.yaml
index 34ad0b839119..2f70a312cf2b 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.28.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.28.yaml
@@ -60,7 +60,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -132,6 +131,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -158,6 +185,20 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -169,13 +210,10 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
           - `tmpfs` a `tmpfs`.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -259,19 +297,20 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+        type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -322,7 +361,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
   RestartPolicy:
     description: |
@@ -440,10 +482,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -510,7 +548,9 @@ definitions:
         format: "int64"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -521,6 +561,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -1027,6 +1073,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2104,6 +2154,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Networks:
         type: "array"
         items:
@@ -2864,7 +2915,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -3164,7 +3214,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 OomKillDisable: false
                 OomScoreAdj: 500
                 NetworkMode: "bridge"
@@ -3855,7 +3904,6 @@ paths:
               Memory: 314572800
               MemorySwap: 514288000
               MemoryReservation: 209715200
-              KernelMemory: 52428800
               RestartPolicy:
                 MaximumRetryCount: 4
                 Name: "on-failure"
@@ -4781,31 +4829,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -4898,7 +4922,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -5287,7 +5316,6 @@ paths:
               IndexServerAddress: "https://index.docker.io/v1/"
               InitPath: "/usr/bin/docker"
               InitSha1: ""
-              KernelMemory: true
               KernelVersion: "3.12.0-1-amd64"
               Labels:
                 - "storage=ssd"
@@ -7265,17 +7293,32 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.29.yaml b/_vendor/github.com/moby/moby/api/docs/v1.29.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.29.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.29.yaml
index 0895a92ed223..61d3d41d2ef9 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.29.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.29.yaml
@@ -60,7 +60,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -132,6 +131,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -158,6 +185,20 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -169,13 +210,10 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
           - `tmpfs` a `tmpfs`.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -259,19 +297,20 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+        type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -325,7 +364,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
   RestartPolicy:
     description: |
@@ -443,10 +485,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -513,7 +551,9 @@ definitions:
         format: "int64"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -524,6 +564,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -1033,6 +1079,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2125,6 +2175,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Networks:
         type: "array"
         items:
@@ -2897,7 +2948,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -3197,7 +3247,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 OomKillDisable: false
                 OomScoreAdj: 500
                 NetworkMode: "bridge"
@@ -3888,7 +3937,6 @@ paths:
               Memory: 314572800
               MemorySwap: 514288000
               MemoryReservation: 209715200
-              KernelMemory: 52428800
               RestartPolicy:
                 MaximumRetryCount: 4
                 Name: "on-failure"
@@ -4814,31 +4862,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -4931,7 +4955,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -5320,7 +5349,6 @@ paths:
               IndexServerAddress: "https://index.docker.io/v1/"
               InitPath: "/usr/bin/docker"
               InitSha1: ""
-              KernelMemory: true
               KernelVersion: "3.12.0-1-amd64"
               Labels:
                 - "storage=ssd"
@@ -7306,17 +7334,32 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.3.md b/_vendor/github.com/moby/moby/api/docs/v1.3.md
new file mode 100644
index 000000000000..1e2b4b3ce4d3
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.3.md
@@ -0,0 +1,1110 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.3"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent="smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.3
+
+# 1. Brief introduction
+
+- The Remote API is replacing rcli
+- Default port in the docker daemon is 2375
+- The API tends to be REST, but for some complex commands, like attach
+  or pull, the HTTP connection is hijacked to transport stdout stdin
+  and stderr
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "centos:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "fedora:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             }
+        ]
+
+Query Parameters:
+
+     
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+    Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created containers, include non-running ones.
+-   **since** – Show only containers created since Id, include non-running ones.
+-   **before** – Show only containers created before Id, include non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers sizes
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Dns":null,
+             "Image":"ubuntu",
+             "Volumes":{},
+             "VolumesFrom":""
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "VolumesFrom": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {}
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id)/top`
+
+List processes running inside the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+              "PID":"11935",
+              "Tty":"pts/2",
+              "Time":"00:00:00",
+              "Cmd":"sh"
+             },
+             {
+              "PID":"12140",
+              "Tty":"pts/2",
+              "Time":"00:00:00",
+              "Cmd":"sleep"
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/(id)/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds":["/tmp:/tmp"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain
+
+Json Parameters:
+
+     
+
+-   **hostConfig** – the container's host configuration (optional)
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/(format)`
+
+List images `format` could be json or viz (json default)
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Repository":"ubuntu",
+                     "Tag":"precise",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658,
+                     "Size":24653,
+                     "VirtualSize":180116135
+             },
+             {
+                     "Repository":"ubuntu",
+                     "Tag":"12.04",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658,
+                     "Size":24653,
+                     "VirtualSize":180116135
+             }
+        ]
+
+**Example request**:
+
+        GET /images/viz HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        digraph docker {
+        "d82cbacda43a" -> "074be284591f"
+        "1496068ca813" -> "08306dc45919"
+        "08306dc45919" -> "0e7893146ac2"
+        "b750fe79269d" -> "1496068ca813"
+        base -> "27cf78414709" [style=invis]
+        "f71189fff3de" -> "9a33b36209ed"
+        "27cf78414709" -> "b750fe79269d"
+        "0e7893146ac2" -> "d6434d954665"
+        "d6434d954665" -> "d82cbacda43a"
+        base -> "e9aa60c60128" [style=invis]
+        "074be284591f" -> "f71189fff3de"
+        "b750fe79269d" [label="b750fe79269d\nubuntu",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "e9aa60c60128" [label="e9aa60c60128\ncentos",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "9a33b36209ed" [label="9a33b36209ed\nfedora",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        base [style=invisible]
+        }
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by defaul
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pulling..."}
+        {"status":"Pulling", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Insert a file in an image
+
+`POST /images/(name)/insert`
+
+Insert a file from `url` in the image `name` at `path`
+
+**Example request**:
+
+        POST /images/test/insert?path=/usr&url=myurl HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Inserting..."}
+        {"status":"Inserting", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-	**url** – The url from where the file is taken
+-	**path** – The path where the file is stored
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/centos/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "parent":"27cf784147099545",
+             "created":"2013-03-23T22:24:18.818426-07:00",
+             "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "container_config":
+                     {
+                             "Hostname":"",
+                             "User":"",
+                             "Memory":0,
+                             "MemorySwap":0,
+                             "AttachStdin":false,
+                             "AttachStdout":false,
+                             "AttachStderr":false,
+                             "PortSpecs":null,
+                             "Tty":true,
+                             "OpenStdin":true,
+                             "StdinOnce":false,
+                             "Env":null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns":null,
+                             "Image":"centos",
+                             "Volumes":null,
+                             "VolumesFrom":""
+                     },
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/fedora/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+    > **Example request**:
+    >
+    >     POST /images/test/push HTTP/1.1
+    >     {{ authConfig }}
+    >
+    > **Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pushing..."}
+        {"status":"Pushing", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com)
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Name":"cespare/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"johnfuller/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"dhrp/mongodb-sshd",
+                     "Description":""
+             }
+        ]
+
+        :query term: term to search
+        :statuscode 200: no error
+        :statuscode 500: server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+        {{ STREAM }}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+    The archive must include a file called Dockerfile at its root. I
+    may include any number of other files, which will be accessible in
+    the build context (See the ADD build command).
+
+    The Content-type header should be set to "application/tar".
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – build source URI (git or HTTPS/HTTP)
+-   **q** – suppress verbose build output
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":"hannibal",
+             "password:"xxxx",
+             "email":"hannibal@a-team.com"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "MemoryLimit":true,
+             "SwapLimit":false,
+             "EventsListeners":"0",
+             "LXCVersion":"0.7.5",
+             "KernelVersion":"3.8.0-19-generic"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Version":"0.2.2",
+             "GitCommit":"5a2a5cc+CHANGES",
+             "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+            "Cmd": ["cat", "/world"],
+            "PortSpecs":["22"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+            Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+        <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"create","id":"dfdf82bd3881","time":1374067924}
+        {"status":"start","id":"dfdf82bd3881","time":1374067924}
+        {"status":"stop","id":"dfdf82bd3881","time":1374067966}
+        {"status":"destroy","id":"dfdf82bd3881","time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+Here are the steps of `docker run` :
+
+ - Create the container
+
+ - If the status code is 404, it means the image doesn't exist:
+        - Try to pull it
+        - Then retry to create the container
+
+ - Start the container
+
+ - If you are not in detached mode:
+        - Attach to the container, using logs=1 (to have stdout and
+            stderr from the container's start) and stream=1
+
+ - If in detached mode or only stdin is attached:
+        - Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+> docker -d -H="192.168.1.9:2375" -api-enable-cors
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.30.yaml b/_vendor/github.com/moby/moby/api/docs/v1.30.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.30.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.30.yaml
index 8ab1764f047c..5c748faae49f 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.30.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.30.yaml
@@ -60,7 +60,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -132,6 +131,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -158,6 +185,20 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -169,13 +210,10 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
           - `tmpfs` a `tmpfs`.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -259,20 +297,20 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -326,7 +364,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
   RestartPolicy:
     description: |
@@ -445,10 +486,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -515,7 +552,9 @@ definitions:
         format: "int64"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -526,6 +565,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -1043,6 +1088,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2303,6 +2352,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Runtime:
         description: "Runtime is the type of runtime specified for the task executor."
         type: "string"
@@ -3110,7 +3160,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -5056,31 +5105,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -5173,7 +5198,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -7558,10 +7588,21 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               DataPathAddr:
                 description: |
@@ -7575,11 +7616,15 @@ paths:
 
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.31.yaml b/_vendor/github.com/moby/moby/api/docs/v1.31.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.31.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.31.yaml
index 9a5efd28de16..aa164fa7a23f 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.31.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.31.yaml
@@ -60,7 +60,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -132,6 +131,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -158,6 +185,20 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -169,13 +210,10 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
           - `tmpfs` a `tmpfs`.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -259,20 +297,20 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -326,7 +364,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
   RestartPolicy:
     description: |
@@ -445,10 +486,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -515,7 +552,9 @@ definitions:
         format: "int64"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -526,6 +565,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -1049,6 +1094,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2332,6 +2381,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Runtime:
         description: "Runtime is the type of runtime specified for the task executor."
         type: "string"
@@ -2857,11 +2907,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -2902,8 +2952,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
   Config:
@@ -3183,7 +3233,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -5150,31 +5199,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -5267,7 +5292,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -7659,10 +7689,21 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               DataPathAddr:
                 description: |
@@ -7676,11 +7717,15 @@ paths:
 
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.32.yaml b/_vendor/github.com/moby/moby/api/docs/v1.32.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.32.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.32.yaml
index 99823282e567..c3d0dc38bd49 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.32.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.32.yaml
@@ -60,7 +60,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -132,6 +131,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -158,6 +185,22 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -169,15 +212,11 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
           - `npipe` a named pipe from the host into the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -261,20 +300,23 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -328,7 +370,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -449,10 +494,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -566,7 +607,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -577,6 +620,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -1308,6 +1357,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2783,6 +2836,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Runtime:
         description: "Runtime is the type of runtime specified for the task executor."
         type: "string"
@@ -3329,11 +3383,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -3375,8 +3429,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
 
@@ -3518,10 +3572,6 @@ definitions:
         description: "Indicates if the host has memory swap limit support enabled."
         type: "boolean"
         example: true
-      KernelMemory:
-        description: "Indicates if the host has kernel memory limit support enabled."
-        type: "boolean"
-        example: true
       CpuCfsPeriod:
         description: "Indicates if CPU CFS(Completely Fair Scheduler) period is supported by the host."
         type: "boolean"
@@ -3621,10 +3671,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -4395,7 +4448,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -4703,7 +4755,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 OomKillDisable: false
                 OomScoreAdj: 500
                 NetworkMode: "bridge"
@@ -5392,7 +5443,6 @@ paths:
               Memory: 314572800
               MemorySwap: 514288000
               MemoryReservation: 209715200
-              KernelMemory: 52428800
               RestartPolicy:
                 MaximumRetryCount: 4
                 Name: "on-failure"
@@ -6361,31 +6411,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -6478,7 +6504,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -8617,10 +8648,21 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               DataPathAddr:
                 description: |
@@ -8634,11 +8676,15 @@ paths:
 
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.33.yaml b/_vendor/github.com/moby/moby/api/docs/v1.33.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.33.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.33.yaml
index 4d49c4156bd4..7e923474a2e7 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.33.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.33.yaml
@@ -60,7 +60,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -136,6 +135,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -162,6 +189,22 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -173,15 +216,11 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
           - `npipe` a named pipe from the host into the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -265,20 +304,23 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -332,7 +374,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -453,10 +498,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -570,7 +611,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -581,6 +624,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -1312,6 +1361,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2787,6 +2840,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Runtime:
         description: "Runtime is the type of runtime specified for the task executor."
         type: "string"
@@ -3333,11 +3387,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -3379,8 +3433,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
 
@@ -3522,10 +3576,6 @@ definitions:
         description: "Indicates if the host has memory swap limit support enabled."
         type: "boolean"
         example: true
-      KernelMemory:
-        description: "Indicates if the host has kernel memory limit support enabled."
-        type: "boolean"
-        example: true
       CpuCfsPeriod:
         description: "Indicates if CPU CFS(Completely Fair Scheduler) period is supported by the host."
         type: "boolean"
@@ -3625,10 +3675,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -4399,7 +4452,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -4707,7 +4759,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 OomKillDisable: false
                 OomScoreAdj: 500
                 NetworkMode: "bridge"
@@ -5396,7 +5447,6 @@ paths:
               Memory: 314572800
               MemorySwap: 514288000
               MemoryReservation: 209715200
-              KernelMemory: 52428800
               RestartPolicy:
                 MaximumRetryCount: 4
                 Name: "on-failure"
@@ -6365,31 +6415,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -6482,7 +6508,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -8625,10 +8656,21 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               DataPathAddr:
                 description: |
@@ -8642,11 +8684,15 @@ paths:
 
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.34.yaml b/_vendor/github.com/moby/moby/api/docs/v1.34.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.34.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.34.yaml
index 2d0d987fb2ba..bebaf385f840 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.34.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.34.yaml
@@ -62,7 +62,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -138,6 +137,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -164,6 +191,22 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -175,15 +218,11 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
           - `npipe` a named pipe from the host into the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -267,20 +306,23 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -334,7 +376,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -455,10 +500,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -572,7 +613,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -583,6 +626,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -1322,6 +1371,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2797,6 +2850,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Runtime:
         description: "Runtime is the type of runtime specified for the task executor."
         type: "string"
@@ -3361,11 +3415,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -3407,8 +3461,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
 
@@ -3550,10 +3604,6 @@ definitions:
         description: "Indicates if the host has memory swap limit support enabled."
         type: "boolean"
         example: true
-      KernelMemory:
-        description: "Indicates if the host has kernel memory limit support enabled."
-        type: "boolean"
-        example: true
       CpuCfsPeriod:
         description: "Indicates if CPU CFS(Completely Fair Scheduler) period is supported by the host."
         type: "boolean"
@@ -3653,10 +3703,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -4427,7 +4480,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -4735,7 +4787,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 OomKillDisable: false
                 OomScoreAdj: 500
                 NetworkMode: "bridge"
@@ -5424,7 +5475,6 @@ paths:
               Memory: 314572800
               MemorySwap: 514288000
               MemoryReservation: 209715200
-              KernelMemory: 52428800
               RestartPolicy:
                 MaximumRetryCount: 4
                 Name: "on-failure"
@@ -6405,31 +6455,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -6522,7 +6548,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -8665,10 +8696,21 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               DataPathAddr:
                 description: |
@@ -8682,11 +8724,15 @@ paths:
 
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.35.yaml b/_vendor/github.com/moby/moby/api/docs/v1.35.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.35.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.35.yaml
index e7de26d46d72..513a55ba23e0 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.35.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.35.yaml
@@ -71,7 +71,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -147,6 +146,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -173,6 +200,22 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -184,15 +227,11 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
           - `npipe` a named pipe from the host into the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -276,20 +315,23 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -344,7 +386,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -466,10 +511,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -583,7 +624,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -594,6 +637,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -1319,6 +1368,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2801,6 +2854,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Runtime:
         description: "Runtime is the type of runtime specified for the task executor."
         type: "string"
@@ -3365,11 +3419,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -3411,8 +3465,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
 
@@ -3554,10 +3608,6 @@ definitions:
         description: "Indicates if the host has memory swap limit support enabled."
         type: "boolean"
         example: true
-      KernelMemory:
-        description: "Indicates if the host has kernel memory limit support enabled."
-        type: "boolean"
-        example: true
       CpuCfsPeriod:
         description: "Indicates if CPU CFS(Completely Fair Scheduler) period is supported by the host."
         type: "boolean"
@@ -3657,10 +3707,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -4431,7 +4484,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -4739,7 +4791,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 OomKillDisable: false
                 OomScoreAdj: 500
                 NetworkMode: "bridge"
@@ -5433,7 +5484,6 @@ paths:
               Memory: 314572800
               MemorySwap: 514288000
               MemoryReservation: 209715200
-              KernelMemory: 52428800
               RestartPolicy:
                 MaximumRetryCount: 4
                 Name: "on-failure"
@@ -6414,31 +6464,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -6531,7 +6557,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -8699,10 +8730,21 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               DataPathAddr:
                 description: |
@@ -8716,11 +8758,15 @@ paths:
 
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.36.yaml b/_vendor/github.com/moby/moby/api/docs/v1.36.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.36.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.36.yaml
index d39839373f83..770489951c99 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.36.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.36.yaml
@@ -71,7 +71,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -147,6 +146,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -173,6 +200,22 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -184,15 +227,11 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
           - `npipe` a named pipe from the host into the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -276,20 +315,23 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -344,7 +386,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -583,7 +628,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -594,6 +641,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -1319,6 +1372,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2814,6 +2871,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Runtime:
         description: "Runtime is the type of runtime specified for the task executor."
         type: "string"
@@ -3378,11 +3436,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -3424,8 +3482,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
 
@@ -3670,10 +3728,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -6440,33 +6501,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -6559,7 +6594,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -8743,10 +8783,21 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               DataPathAddr:
                 description: |
@@ -8760,11 +8811,15 @@ paths:
 
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.37.yaml b/_vendor/github.com/moby/moby/api/docs/v1.37.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.37.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.37.yaml
index 014086b9d55a..93b268916dc7 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.37.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.37.yaml
@@ -71,7 +71,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -147,6 +146,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -173,6 +200,22 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -184,15 +227,11 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
           - `npipe` a named pipe from the host into the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -276,20 +315,23 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -344,7 +386,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -587,7 +632,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -598,6 +645,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -1322,6 +1375,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2817,6 +2874,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Runtime:
         description: "Runtime is the type of runtime specified for the task executor."
         type: "string"
@@ -3384,11 +3442,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -3437,8 +3495,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -3690,10 +3748,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -6483,33 +6544,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -6602,7 +6637,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -8786,10 +8826,21 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               DataPathAddr:
                 description: |
@@ -8803,11 +8854,15 @@ paths:
 
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.38.yaml b/_vendor/github.com/moby/moby/api/docs/v1.38.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.38.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.38.yaml
index 23555a87ac48..3cbf7cda747d 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.38.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.38.yaml
@@ -71,7 +71,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -147,6 +146,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -174,6 +201,22 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -185,15 +228,11 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
           - `npipe` a named pipe from the host into the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -277,20 +316,23 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -345,7 +387,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -467,10 +512,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -588,7 +629,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -599,6 +642,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -1333,6 +1382,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2871,6 +2924,7 @@ definitions:
       ForceUpdate:
         description: "A counter that triggers an update even if no relevant parameters have been changed."
         type: "integer"
+        format: "uint64"
       Runtime:
         description: "Runtime is the type of runtime specified for the task executor."
         type: "string"
@@ -3438,11 +3492,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -3491,8 +3545,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -3641,10 +3695,6 @@ definitions:
         description: "Indicates if the host has memory swap limit support enabled."
         type: "boolean"
         example: true
-      KernelMemory:
-        description: "Indicates if the host has kernel memory limit support enabled."
-        type: "boolean"
-        example: true
       CpuCfsPeriod:
         description: "Indicates if CPU CFS(Completely Fair Scheduler) period is supported by the host."
         type: "boolean"
@@ -3744,10 +3794,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -4518,7 +4571,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -4836,7 +4888,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 OomKillDisable: false
                 OomScoreAdj: 500
                 NetworkMode: "bridge"
@@ -5543,7 +5594,6 @@ paths:
               Memory: 314572800
               MemorySwap: 514288000
               MemoryReservation: 209715200
-              KernelMemory: 52428800
               RestartPolicy:
                 MaximumRetryCount: 4
                 Name: "on-failure"
@@ -6554,33 +6604,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -6673,7 +6697,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -8857,10 +8886,21 @@ paths:
             type: "object"
             properties:
               ListenAddr:
-                description: "Listen address used for inter-manager communication if the node gets promoted to manager, as well as determining the networking interface used for the VXLAN Tunnel Endpoint (VTEP)."
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
-                description: "Externally reachable address advertised to other nodes. This can either be an address/port combination in the form `192.168.1.1:4567`, or an interface followed by a port number, like `eth0:4567`. If the port number is omitted, the port number from the listen address is used. If `AdvertiseAddr` is not specified, it will be automatically detected when possible."
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
                 type: "string"
               DataPathAddr:
                 description: |
@@ -8874,11 +8914,15 @@ paths:
 
                 type: "string"
               RemoteAddrs:
-                description: "Addresses of manager nodes already participating in the swarm."
-                type: "string"
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.39.yaml b/_vendor/github.com/moby/moby/api/docs/v1.39.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.39.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.39.yaml
index 2c16eca88604..3e7504eac1b5 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.39.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.39.yaml
@@ -81,7 +81,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -173,6 +172,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -200,6 +227,22 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -211,15 +254,11 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
           - `npipe` a named pipe from the host into the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -303,20 +342,23 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -371,7 +413,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -530,11 +575,6 @@ definitions:
         description: "Disk limit (in bytes)."
         type: "integer"
         format: "int64"
-      KernelMemory:
-        description: "Kernel memory limit in bytes."
-        type: "integer"
-        format: "int64"
-        example: 209715200
       MemoryReservation:
         description: "Memory soft limit in bytes."
         type: "integer"
@@ -676,7 +716,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -687,6 +729,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -700,6 +748,10 @@ definitions:
         description: |
           The time to wait before considering the check to have hung. It should
           be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
         type: "integer"
         format: "int64"
       Retries:
@@ -2109,6 +2161,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -3913,6 +3969,7 @@ definitions:
           A counter that triggers an update even if no relevant parameters have
           been changed.
         type: "integer"
+        format: "uint64"
       Runtime:
         description: |
           Runtime is the type of runtime specified for the task executor.
@@ -4499,11 +4556,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -4554,8 +4611,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -4744,7 +4801,9 @@ definitions:
         example: "linux"
       Arch:
         description: |
-          The architecture that the daemon is running on
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
         type: "string"
         example: "amd64"
       KernelVersion:
@@ -4889,10 +4948,6 @@ definitions:
         description: "Indicates if the host has memory swap limit support enabled."
         type: "boolean"
         example: true
-      KernelMemory:
-        description: "Indicates if the host has kernel memory limit support enabled."
-        type: "boolean"
-        example: true
       CpuCfsPeriod:
         description: |
           Indicates if CPU CFS(Completely Fair Scheduler) period is supported by
@@ -4999,10 +5054,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -5823,7 +5881,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 NanoCpus: 500000
                 CpuPercent: 80
                 CpuShares: 512
@@ -6097,7 +6154,6 @@ paths:
                 Memory: 0
                 MemorySwap: 0
                 MemoryReservation: 0
-                KernelMemory: 0
                 OomKillDisable: false
                 OomScoreAdj: 500
                 NetworkMode: "bridge"
@@ -6469,7 +6525,8 @@ paths:
 
         To calculate the values shown by the `stats` command of the docker cli tool
         the following formulas can be used:
-        * used_memory = `memory_stats.usage - memory_stats.stats.cache`
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
         * available_memory = `memory_stats.limit`
         * Memory usage % = `(used_memory / available_memory) * 100.0`
         * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
@@ -6835,7 +6892,6 @@ paths:
               Memory: 314572800
               MemorySwap: 514288000
               MemoryReservation: 209715200
-              KernelMemory: 52428800
               RestartPolicy:
                 MaximumRetryCount: 4
                 Name: "on-failure"
@@ -7820,33 +7876,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -7945,7 +7975,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -10164,7 +10199,9 @@ paths:
                 description: |
                   Listen address used for inter-manager communication if the node
                   gets promoted to manager, as well as determining the networking
-                  interface used for the VXLAN Tunnel Endpoint (VTEP).
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
                 description: |
@@ -10198,6 +10235,7 @@ paths:
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.4.md b/_vendor/github.com/moby/moby/api/docs/v1.4.md
new file mode 100644
index 000000000000..6cedddf12e4f
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.4.md
@@ -0,0 +1,1153 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.4"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent="smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.4
+
+# 1. Brief introduction
+
+- The Remote API is replacing rcli
+- Default port in the docker daemon is 2375
+- The API tends to be REST, but for some complex commands, like attach
+  or pull, the HTTP connection is hijacked to transport stdout stdin
+  and stderr
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "ubuntu:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "centos:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "fedora:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports":"",
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             }
+        ]
+
+Query Parameters:
+
+     
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+    Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created containers, include non-running ones.
+-   **since** – Show only containers created since Id, include non-running ones.
+-   **before** – Show only containers created before Id, include non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers sizes
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Privileged": false,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Dns":null,
+             "Image":"ubuntu",
+             "Volumes":{},
+             "VolumesFrom":"",
+             "WorkingDir":""
+
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "ubuntu",
+                             "Volumes": {},
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {}
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **409** – conflict between containers and images
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id)/top`
+
+List processes running inside the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Titles": [
+                     "USER",
+                     "PID",
+                     "%CPU",
+                     "%MEM",
+                     "VSZ",
+                     "RSS",
+                     "TTY",
+                     "STAT",
+                     "START",
+                     "TIME",
+                     "COMMAND"
+                     ],
+             "Processes": [
+                     ["root","20147","0.0","0.1","18060","1864","pts/4","S","10:06","0:00","bash"],
+                     ["root","20271","0.0","0.0","4312","352","pts/4","S+","10:07","0:00","sleep","10"]
+             ]
+        }
+
+Query Parameters:
+
+-   **ps_args** – ps arguments to use (e.g., aux)
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/(id)/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds":["/tmp:/tmp"],
+             "LxcConf":[{"Key":"lxc.utsname","Value":"docker"}]
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain
+
+Json Parameters:
+
+     
+
+-   **hostConfig** – the container's host configuration (optional)
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/(format)`
+
+List images `format` could be json or viz (json default)
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Repository":"ubuntu",
+                     "Tag":"precise",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658,
+                     "Size":24653,
+                     "VirtualSize":180116135
+             },
+             {
+                     "Repository":"ubuntu",
+                     "Tag":"12.04",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658,
+                     "Size":24653,
+                     "VirtualSize":180116135
+             }
+        ]
+
+**Example request**:
+
+        GET /images/viz HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        digraph docker {
+        "d82cbacda43a" -> "074be284591f"
+        "1496068ca813" -> "08306dc45919"
+        "08306dc45919" -> "0e7893146ac2"
+        "b750fe79269d" -> "1496068ca813"
+        base -> "27cf78414709" [style=invis]
+        "f71189fff3de" -> "9a33b36209ed"
+        "27cf78414709" -> "b750fe79269d"
+        "0e7893146ac2" -> "d6434d954665"
+        "d6434d954665" -> "d82cbacda43a"
+        base -> "e9aa60c60128" [style=invis]
+        "074be284591f" -> "f71189fff3de"
+        "b750fe79269d" [label="b750fe79269d\nubuntu",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "e9aa60c60128" [label="e9aa60c60128\ncentos",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "9a33b36209ed" [label="9a33b36209ed\nfedora",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        base [style=invisible]
+        }
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by defaul
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pulling..."}
+        {"status":"Pulling", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Insert a file in an image
+
+`POST /images/(name)/insert`
+
+Insert a file from `url` in the image `name` at `path`
+
+**Example request**:
+
+        POST /images/test/insert?path=/usr&url=myurl HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Inserting..."}
+        {"status":"Inserting", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-	**url** – The url from where the file is taken
+-	**path** – The path where the file is stored
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/centos/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "parent":"27cf784147099545",
+             "created":"2013-03-23T22:24:18.818426-07:00",
+             "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "container_config":
+                     {
+                             "Hostname":"",
+                             "User":"",
+                             "Memory":0,
+                             "MemorySwap":0,
+                             "AttachStdin":false,
+                             "AttachStdout":false,
+                             "AttachStderr":false,
+                             "PortSpecs":null,
+                             "Tty":true,
+                             "OpenStdin":true,
+                             "StdinOnce":false,
+                             "Env":null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns":null,
+                             "Image":"centos",
+                             "Volumes":null,
+                             "VolumesFrom":"",
+                             "WorkingDir":""
+                     },
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict between containers and images
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/fedora/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+        {{ authConfig }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+    {"status":"Pushing..."} {"status":"Pushing", "progress":"1/? (n/a)"}
+    {"error":"Invalid..."} ...
+
+Status Codes:
+
+-   **200** – no error :statuscode 404: no such image :statuscode
+        500: server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com)
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Name":"cespare/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"johnfuller/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"dhrp/mongodb-sshd",
+                     "Description":""
+             }
+        ]
+
+        :query term: term to search
+        :statuscode 200: no error
+        :statuscode 500: server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+        {{ STREAM }}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+    The archive must include a file called Dockerfile at its root. I
+    may include any number of other files, which will be accessible in
+    the build context (See the ADD build command).
+
+    The Content-type header should be set to "application/tar".
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – build source URI (git or HTTPS/HTTP)
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "MemoryLimit":true,
+             "SwapLimit":false,
+             "IPv4Forwarding":true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Version":"0.2.2",
+             "GitCommit":"5a2a5cc+CHANGES",
+             "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+            "Cmd": ["cat", "/world"],
+            "PortSpecs":["22"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+            Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+        <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"create","id":"dfdf82bd3881","from":"ubuntu:latest","time":1374067924}
+        {"status":"start","id":"dfdf82bd3881","from":"ubuntu:latest","time":1374067924}
+        {"status":"stop","id":"dfdf82bd3881","from":"ubuntu:latest","time":1374067966}
+        {"status":"destroy","id":"dfdf82bd3881","from":"ubuntu:latest","time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+Here are the steps of `docker run` :
+
+ - Create the container
+
+ - If the status code is 404, it means the image doesn't exist:
+        - Try to pull it
+        - Then retry to create the container
+
+ - Start the container
+
+ - If you are not in detached mode:
+        - Attach to the container, using logs=1 (to have stdout and
+            stderr from the container's start) and stream=1
+
+ - If in detached mode or only stdin is attached:
+        - Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.40.yaml b/_vendor/github.com/moby/moby/api/docs/v1.40.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.40.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.40.yaml
index 27414904597d..1a1333be0100 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.40.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.40.yaml
@@ -81,7 +81,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -173,6 +172,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -200,6 +227,22 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -211,15 +254,11 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
           - `npipe` a named pipe from the host into the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -340,22 +379,23 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-          - `npipe` Mounts a named pipe from the host into the container. Must exist prior to creating the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -414,7 +454,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -727,7 +770,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -738,6 +783,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -751,6 +802,10 @@ definitions:
         description: |
           The time to wait before considering the check to have hung. It should
           be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
         type: "integer"
         format: "int64"
       Retries:
@@ -2169,6 +2224,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -4039,6 +4098,7 @@ definitions:
           A counter that triggers an update even if no relevant parameters have
           been changed.
         type: "integer"
+        format: "uint64"
       Runtime:
         description: |
           Runtime is the type of runtime specified for the task executor.
@@ -4623,11 +4683,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -4678,8 +4738,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -4868,7 +4928,9 @@ definitions:
         example: "linux"
       Arch:
         description: |
-          The architecture that the daemon is running on
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
         type: "string"
         example: "amd64"
       KernelVersion:
@@ -5135,10 +5197,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -6775,7 +6840,8 @@ paths:
 
         To calculate the values shown by the `stats` command of the docker cli tool
         the following formulas can be used:
-        * used_memory = `memory_stats.usage - memory_stats.stats.cache`
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
         * available_memory = `memory_stats.limit`
         * Memory usage % = `(used_memory / available_memory) * 100.0`
         * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
@@ -7948,7 +8014,18 @@ paths:
           default: ""
         - name: "outputs"
           in: "query"
-          description: "BuildKit output configuration"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
           type: "string"
           default: ""
         - name: "version"
@@ -8143,33 +8220,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -8268,7 +8319,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -10478,7 +10534,9 @@ paths:
                 description: |
                   Listen address used for inter-manager communication if the node
                   gets promoted to manager, as well as determining the networking
-                  interface used for the VXLAN Tunnel Endpoint (VTEP).
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
                 description: |
@@ -10512,6 +10570,7 @@ paths:
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.41.yaml b/_vendor/github.com/moby/moby/api/docs/v1.41.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.41.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.41.yaml
index 0554b5a719ed..fa0467b02989 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.41.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.41.yaml
@@ -81,7 +81,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -173,6 +172,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -200,6 +227,22 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -211,15 +254,11 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
           - `npipe` a named pipe from the host into the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -340,22 +379,23 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must exist prior to creating the container.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
           - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-          - `npipe` Mounts a named pipe from the host into the container. Must exist prior to creating the container.
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -414,7 +454,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -754,7 +797,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -765,6 +810,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -778,6 +829,10 @@ definitions:
         description: |
           The time to wait before considering the check to have hung. It should
           be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
         type: "integer"
         format: "int64"
       Retries:
@@ -2200,6 +2255,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -4204,6 +4263,7 @@ definitions:
           A counter that triggers an update even if no relevant parameters have
           been changed.
         type: "integer"
+        format: "uint64"
       Runtime:
         description: |
           Runtime is the type of runtime specified for the task executor.
@@ -4872,11 +4932,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -4927,8 +4987,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -5117,7 +5177,9 @@ definitions:
         example: "linux"
       Arch:
         description: |
-          The architecture that the daemon is running on
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
         type: "string"
         example: "amd64"
       KernelVersion:
@@ -5370,10 +5432,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -7057,7 +7122,8 @@ paths:
 
         To calculate the values shown by the `stats` command of the docker cli tool
         the following formulas can be used:
-        * used_memory = `memory_stats.usage - memory_stats.stats.cache`
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
         * available_memory = `memory_stats.limit`
         * Memory usage % = `(used_memory / available_memory) * 100.0`
         * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
@@ -8237,7 +8303,18 @@ paths:
           default: ""
         - name: "outputs"
           in: "query"
-          description: "BuildKit output configuration"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
           type: "string"
           default: ""
         - name: "version"
@@ -8432,33 +8509,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -8557,7 +8608,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -10777,7 +10833,9 @@ paths:
                 description: |
                   Listen address used for inter-manager communication if the node
                   gets promoted to manager, as well as determining the networking
-                  interface used for the VXLAN Tunnel Endpoint (VTEP).
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
                 description: |
@@ -10811,6 +10869,7 @@ paths:
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.42.yaml b/_vendor/github.com/moby/moby/api/docs/v1.42.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.42.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.42.yaml
index b31e84af5db0..03c12deeeaaa 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.42.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.42.yaml
@@ -81,7 +81,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -173,6 +172,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -200,6 +227,24 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -211,17 +256,12 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
+          - `cluster` a Swarm cluster volume.
           - `npipe` a named pipe from the host into the container.
-          - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -342,24 +382,25 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
-          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-          - `npipe` Mounts a named pipe from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
           - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -422,7 +463,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -756,7 +800,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -767,6 +813,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -780,6 +832,10 @@ definitions:
         description: |
           The time to wait before considering the check to have hung. It should
           be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
         type: "integer"
         format: "int64"
       Retries:
@@ -2203,6 +2259,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2616,14 +2676,6 @@ definitions:
         description: |
           Unique ID of the build cache record.
         example: "ndlpt0hhvkqcdfkputsk4cq9c"
-      Parent:
-        description: |
-          ID of the parent build cache record.
-
-          > **Deprecated**: This field is deprecated, and omitted if empty.
-        type: "string"
-        x-nullable: true
-        example: ""
       Parents:
         description: |
           List of parent build cache record IDs.
@@ -4223,6 +4275,7 @@ definitions:
           A counter that triggers an update even if no relevant parameters have
           been changed.
         type: "integer"
+        format: "uint64"
       Runtime:
         description: |
           Runtime is the type of runtime specified for the task executor.
@@ -4891,11 +4944,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -4946,8 +4999,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -5156,7 +5209,9 @@ definitions:
         example: "linux"
       Arch:
         description: |
-          The architecture that the daemon is running on
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
         type: "string"
         example: "amd64"
       KernelVersion:
@@ -5400,10 +5455,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -6333,8 +6391,11 @@ definitions:
       details, see documentation for the Topology object in the CSI
       specification.
     type: "object"
-    additionalProperties:
-      type: "string"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
 
 paths:
   /containers/json:
@@ -7276,7 +7337,8 @@ paths:
 
         To calculate the values shown by the `stats` command of the docker cli tool
         the following formulas can be used:
-        * used_memory = `memory_stats.usage - memory_stats.stats.cache`
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
         * available_memory = `memory_stats.limit`
         * Memory usage % = `(used_memory / available_memory) * 100.0`
         * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
@@ -8487,7 +8549,18 @@ paths:
           default: ""
         - name: "outputs"
           in: "query"
-          description: "BuildKit output configuration"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
           type: "string"
           default: ""
         - name: "version"
@@ -8697,33 +8770,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -8822,7 +8869,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -11155,7 +11207,9 @@ paths:
                 description: |
                   Listen address used for inter-manager communication if the node
                   gets promoted to manager, as well as determining the networking
-                  interface used for the VXLAN Tunnel Endpoint (VTEP).
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
                 description: |
@@ -11189,6 +11243,7 @@ paths:
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.43.yaml b/_vendor/github.com/moby/moby/api/docs/v1.43.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.43.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.43.yaml
index a1cdea0ea5e4..9bf5e3483584 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.43.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.43.yaml
@@ -81,7 +81,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -173,6 +172,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -200,6 +227,24 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -211,17 +256,12 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
+          - `cluster` a Swarm cluster volume.
           - `npipe` a named pipe from the host into the container.
-          - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -342,24 +382,25 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
-          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-          - `npipe` Mounts a named pipe from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
           - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -422,7 +463,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -756,7 +800,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -767,6 +813,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -780,6 +832,10 @@ definitions:
         description: |
           The time to wait before considering the check to have hung. It should
           be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
         type: "integer"
         format: "int64"
       Retries:
@@ -2234,6 +2290,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2647,14 +2707,6 @@ definitions:
         description: |
           Unique ID of the build cache record.
         example: "ndlpt0hhvkqcdfkputsk4cq9c"
-      Parent:
-        description: |
-          ID of the parent build cache record.
-
-          > **Deprecated**: This field is deprecated, and omitted if empty.
-        type: "string"
-        x-nullable: true
-        example: ""
       Parents:
         description: |
           List of parent build cache record IDs.
@@ -4254,6 +4306,7 @@ definitions:
           A counter that triggers an update even if no relevant parameters have
           been changed.
         type: "integer"
+        format: "uint64"
       Runtime:
         description: |
           Runtime is the type of runtime specified for the task executor.
@@ -4922,11 +4975,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -4977,8 +5030,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -5188,7 +5241,9 @@ definitions:
         example: "linux"
       Arch:
         description: |
-          The architecture that the daemon is running on
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
         type: "string"
         example: "amd64"
       KernelVersion:
@@ -5432,10 +5487,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -6366,8 +6424,11 @@ definitions:
       details, see documentation for the Topology object in the CSI
       specification.
     type: "object"
-    additionalProperties:
-      type: "string"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
 
 paths:
   /containers/json:
@@ -7294,7 +7355,8 @@ paths:
 
         To calculate the values shown by the `stats` command of the docker cli tool
         the following formulas can be used:
-        * used_memory = `memory_stats.usage - memory_stats.stats.cache`
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
         * available_memory = `memory_stats.limit`
         * Memory usage % = `(used_memory / available_memory) * 100.0`
         * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
@@ -8505,7 +8567,18 @@ paths:
           default: ""
         - name: "outputs"
           in: "query"
-          description: "BuildKit output configuration"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
           type: "string"
           default: ""
         - name: "version"
@@ -8715,33 +8788,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -8840,7 +8887,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -11173,7 +11225,9 @@ paths:
                 description: |
                   Listen address used for inter-manager communication if the node
                   gets promoted to manager, as well as determining the networking
-                  interface used for the VXLAN Tunnel Endpoint (VTEP).
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
                 description: |
@@ -11207,6 +11261,7 @@ paths:
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.44.yaml b/_vendor/github.com/moby/moby/api/docs/v1.44.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.44.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.44.yaml
index 8e4e6121e622..33b9d61ee6e4 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.44.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.44.yaml
@@ -81,7 +81,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -173,6 +172,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -200,6 +227,24 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -211,17 +256,12 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
+          - `cluster` a Swarm cluster volume.
           - `npipe` a named pipe from the host into the container.
-          - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -342,24 +382,25 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
-          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-          - `npipe` Mounts a named pipe from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
           - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -432,7 +473,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -766,7 +810,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -777,6 +823,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -790,6 +842,10 @@ definitions:
         description: |
           The time to wait before considering the check to have hung. It should
           be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
         type: "integer"
         format: "int64"
       Retries:
@@ -2086,14 +2142,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 1239828
       GraphDriver:
         $ref: "#/definitions/GraphDriverData"
       RootFS:
@@ -2225,14 +2273,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |-
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 172064416
       Labels:
         description: "User-defined key/value metadata."
         type: "object"
@@ -2261,6 +2301,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2674,14 +2718,6 @@ definitions:
         description: |
           Unique ID of the build cache record.
         example: "ndlpt0hhvkqcdfkputsk4cq9c"
-      Parent:
-        description: |
-          ID of the parent build cache record.
-
-          > **Deprecated**: This field is deprecated, and omitted if empty.
-        type: "string"
-        x-nullable: true
-        example: ""
       Parents:
         description: |
           List of parent build cache record IDs.
@@ -4322,6 +4358,7 @@ definitions:
           A counter that triggers an update even if no relevant parameters have
           been changed.
         type: "integer"
+        format: "uint64"
       Runtime:
         description: |
           Runtime is the type of runtime specified for the task executor.
@@ -5037,11 +5074,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -5092,8 +5129,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -5303,7 +5340,9 @@ definitions:
         example: "linux"
       Arch:
         description: |
-          The architecture that the daemon is running on
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
         type: "string"
         example: "amd64"
       KernelVersion:
@@ -5547,10 +5586,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -6521,8 +6563,11 @@ definitions:
       details, see documentation for the Topology object in the CSI
       specification.
     type: "object"
-    additionalProperties:
-      type: "string"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
 
 paths:
   /containers/json:
@@ -7450,7 +7495,8 @@ paths:
 
         To calculate the values shown by the `stats` command of the docker cli tool
         the following formulas can be used:
-        * used_memory = `memory_stats.usage - memory_stats.stats.cache`
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
         * available_memory = `memory_stats.limit`
         * Memory usage % = `(used_memory / available_memory) * 100.0`
         * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
@@ -8662,7 +8708,18 @@ paths:
           default: ""
         - name: "outputs"
           in: "query"
-          description: "BuildKit output configuration"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
           type: "string"
           default: ""
         - name: "version"
@@ -8872,33 +8929,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -8997,7 +9028,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -11339,7 +11375,9 @@ paths:
                 description: |
                   Listen address used for inter-manager communication if the node
                   gets promoted to manager, as well as determining the networking
-                  interface used for the VXLAN Tunnel Endpoint (VTEP).
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
                 description: |
@@ -11373,6 +11411,7 @@ paths:
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.45.yaml b/_vendor/github.com/moby/moby/api/docs/v1.45.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.45.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.45.yaml
index 56d346fea4ce..a13bd56b625d 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.45.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.45.yaml
@@ -81,7 +81,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -173,6 +172,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -200,6 +227,24 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -211,17 +256,12 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
+          - `cluster` a Swarm cluster volume.
           - `npipe` a named pipe from the host into the container.
-          - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -342,24 +382,25 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
-          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-          - `npipe` Mounts a named pipe from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
           - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -440,7 +481,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
 
   RestartPolicy:
@@ -774,7 +818,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -785,6 +831,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -798,6 +850,10 @@ definitions:
         description: |
           The time to wait before considering the check to have hung. It should
           be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
         type: "integer"
         format: "int64"
       Retries:
@@ -2072,14 +2128,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 1239828
       GraphDriver:
         $ref: "#/definitions/GraphDriverData"
       RootFS:
@@ -2211,14 +2259,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |-
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 172064416
       Labels:
         description: "User-defined key/value metadata."
         type: "object"
@@ -2247,6 +2287,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2660,14 +2704,6 @@ definitions:
         description: |
           Unique ID of the build cache record.
         example: "ndlpt0hhvkqcdfkputsk4cq9c"
-      Parent:
-        description: |
-          ID of the parent build cache record.
-
-          > **Deprecated**: This field is deprecated, and omitted if empty.
-        type: "string"
-        x-nullable: true
-        example: ""
       Parents:
         description: |
           List of parent build cache record IDs.
@@ -4308,6 +4344,7 @@ definitions:
           A counter that triggers an update even if no relevant parameters have
           been changed.
         type: "integer"
+        format: "uint64"
       Runtime:
         description: |
           Runtime is the type of runtime specified for the task executor.
@@ -5023,11 +5060,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -5078,8 +5115,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -5289,7 +5326,9 @@ definitions:
         example: "linux"
       Arch:
         description: |
-          The architecture that the daemon is running on
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
         type: "string"
         example: "amd64"
       KernelVersion:
@@ -5533,10 +5572,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -6507,8 +6549,11 @@ definitions:
       details, see documentation for the Topology object in the CSI
       specification.
     type: "object"
-    additionalProperties:
-      type: "string"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
 
 paths:
   /containers/json:
@@ -7436,7 +7481,8 @@ paths:
 
         To calculate the values shown by the `stats` command of the docker cli tool
         the following formulas can be used:
-        * used_memory = `memory_stats.usage - memory_stats.stats.cache`
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
         * available_memory = `memory_stats.limit`
         * Memory usage % = `(used_memory / available_memory) * 100.0`
         * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
@@ -8648,7 +8694,18 @@ paths:
           default: ""
         - name: "outputs"
           in: "query"
-          description: "BuildKit output configuration"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
           type: "string"
           default: ""
         - name: "version"
@@ -8858,33 +8915,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -8983,7 +9014,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -11319,7 +11355,9 @@ paths:
                 description: |
                   Listen address used for inter-manager communication if the node
                   gets promoted to manager, as well as determining the networking
-                  interface used for the VXLAN Tunnel Endpoint (VTEP).
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
                 description: |
@@ -11353,6 +11391,7 @@ paths:
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.46.yaml b/_vendor/github.com/moby/moby/api/docs/v1.46.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.46.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.46.yaml
index 8c4be6c3ce01..e5c24dccc6f6 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.46.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.46.yaml
@@ -81,7 +81,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -173,6 +172,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -200,6 +227,24 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -211,17 +256,12 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
+          - `cluster` a Swarm cluster volume.
           - `npipe` a named pipe from the host into the container.
-          - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -342,24 +382,25 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
-          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-          - `npipe` Mounts a named pipe from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
           - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -440,7 +481,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
           Options:
             description: |
@@ -789,7 +833,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -800,6 +846,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -813,6 +865,10 @@ definitions:
         description: |
           The time to wait before considering the check to have hung. It should
           be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
         type: "integer"
         format: "int64"
       Retries:
@@ -1385,7 +1441,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         example: ""
       Domainname:
@@ -1395,7 +1451,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         example: ""
       User:
@@ -1409,7 +1465,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1420,7 +1476,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1431,7 +1487,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1458,7 +1514,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1469,7 +1525,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1480,7 +1536,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1517,7 +1573,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         default: ""
         example: ""
@@ -1556,7 +1612,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1568,7 +1624,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "string"
         default: ""
         example: ""
@@ -1602,7 +1658,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "integer"
         default: 10
         x-nullable: true
@@ -2099,14 +2155,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 1239828
       GraphDriver:
         $ref: "#/definitions/GraphDriverData"
       RootFS:
@@ -2239,14 +2287,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |-
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 172064416
       Labels:
         description: "User-defined key/value metadata."
         type: "object"
@@ -2275,6 +2315,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2706,14 +2750,6 @@ definitions:
         description: |
           Unique ID of the build cache record.
         example: "ndlpt0hhvkqcdfkputsk4cq9c"
-      Parent:
-        description: |
-          ID of the parent build cache record.
-
-          > **Deprecated**: This field is deprecated, and omitted if empty.
-        type: "string"
-        x-nullable: true
-        example: ""
       Parents:
         description: |
           List of parent build cache record IDs.
@@ -4361,6 +4397,7 @@ definitions:
           A counter that triggers an update even if no relevant parameters have
           been changed.
         type: "integer"
+        format: "uint64"
       Runtime:
         description: |
           Runtime is the type of runtime specified for the task executor.
@@ -5082,11 +5119,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -5137,8 +5174,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -5348,7 +5385,9 @@ definitions:
         example: "linux"
       Arch:
         description: |
-          The architecture that the daemon is running on
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
         type: "string"
         example: "amd64"
       KernelVersion:
@@ -5592,10 +5631,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -6618,8 +6660,11 @@ definitions:
       details, see documentation for the Topology object in the CSI
       specification.
     type: "object"
-    additionalProperties:
-      type: "string"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
 
 paths:
   /containers/json:
@@ -7557,7 +7602,8 @@ paths:
 
         To calculate the values shown by the `stats` command of the docker cli tool
         the following formulas can be used:
-        * used_memory = `memory_stats.usage - memory_stats.stats.cache`
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
         * available_memory = `memory_stats.limit`
         * Memory usage % = `(used_memory / available_memory) * 100.0`
         * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
@@ -8769,7 +8815,18 @@ paths:
           default: ""
         - name: "outputs"
           in: "query"
-          description: "BuildKit output configuration"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
           type: "string"
           default: ""
         - name: "version"
@@ -8979,33 +9036,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -9117,7 +9148,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -11438,7 +11474,9 @@ paths:
                 description: |
                   Listen address used for inter-manager communication if the node
                   gets promoted to manager, as well as determining the networking
-                  interface used for the VXLAN Tunnel Endpoint (VTEP).
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
                 description: |
@@ -11472,6 +11510,7 @@ paths:
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.47.yaml b/_vendor/github.com/moby/moby/api/docs/v1.47.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.47.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.47.yaml
index 4eb222a05074..3e05a643b253 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.47.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.47.yaml
@@ -81,7 +81,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -173,6 +172,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -200,6 +227,24 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -211,17 +256,12 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `tmpfs` a `tmpfs`.
+          - `cluster` a Swarm cluster volume.
           - `npipe` a named pipe from the host into the container.
-          - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -342,24 +382,25 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
-          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-          - `npipe` Mounts a named pipe from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
           - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -440,7 +481,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
           Options:
             description: |
@@ -789,7 +833,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -800,6 +846,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -813,6 +865,10 @@ definitions:
         description: |
           The time to wait before considering the check to have hung. It should
           be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
         type: "integer"
         format: "int64"
       Retries:
@@ -1385,7 +1441,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         example: ""
       Domainname:
@@ -1395,7 +1451,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         example: ""
       User:
@@ -1409,7 +1465,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1420,7 +1476,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1431,7 +1487,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1458,7 +1514,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1469,7 +1525,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1480,7 +1536,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1517,7 +1573,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         default: ""
         example: ""
@@ -1556,7 +1612,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1568,7 +1624,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "string"
         default: ""
         example: ""
@@ -1602,7 +1658,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "integer"
         default: 10
         x-nullable: true
@@ -2099,14 +2155,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 1239828
       GraphDriver:
         $ref: "#/definitions/DriverData"
       RootFS:
@@ -2239,14 +2287,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |-
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 172064416
       Labels:
         description: "User-defined key/value metadata."
         type: "object"
@@ -2288,6 +2328,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2724,14 +2768,6 @@ definitions:
         description: |
           Unique ID of the build cache record.
         example: "ndlpt0hhvkqcdfkputsk4cq9c"
-      Parent:
-        description: |
-          ID of the parent build cache record.
-
-          > **Deprecated**: This field is deprecated, and omitted if empty.
-        type: "string"
-        x-nullable: true
-        example: ""
       Parents:
         description: |
           List of parent build cache record IDs.
@@ -4379,6 +4415,7 @@ definitions:
           A counter that triggers an update even if no relevant parameters have
           been changed.
         type: "integer"
+        format: "uint64"
       Runtime:
         description: |
           Runtime is the type of runtime specified for the task executor.
@@ -5100,11 +5137,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -5155,8 +5192,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -5366,7 +5403,9 @@ definitions:
         example: "linux"
       Arch:
         description: |
-          The architecture that the daemon is running on
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
         type: "string"
         example: "amd64"
       KernelVersion:
@@ -5614,10 +5653,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -6640,8 +6682,11 @@ definitions:
       details, see documentation for the Topology object in the CSI
       specification.
     type: "object"
-    additionalProperties:
-      type: "string"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
 
   ImageManifestSummary:
     x-go-name: "ManifestSummary"
@@ -7693,7 +7738,8 @@ paths:
 
         To calculate the values shown by the `stats` command of the docker cli tool
         the following formulas can be used:
-        * used_memory = `memory_stats.usage - memory_stats.stats.cache`
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
         * available_memory = `memory_stats.limit`
         * Memory usage % = `(used_memory / available_memory) * 100.0`
         * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
@@ -8910,7 +8956,18 @@ paths:
           default: ""
         - name: "outputs"
           in: "query"
-          description: "BuildKit output configuration"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
           type: "string"
           default: ""
         - name: "version"
@@ -9120,33 +9177,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -9258,7 +9289,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -11588,7 +11624,9 @@ paths:
                 description: |
                   Listen address used for inter-manager communication if the node
                   gets promoted to manager, as well as determining the networking
-                  interface used for the VXLAN Tunnel Endpoint (VTEP).
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
                 description: |
@@ -11622,6 +11660,7 @@ paths:
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.48.yaml b/_vendor/github.com/moby/moby/api/docs/v1.48.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.48.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.48.yaml
index a2901377e5b5..2b645d45117b 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.48.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.48.yaml
@@ -81,7 +81,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -173,6 +172,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -200,6 +227,26 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `image` an OCI image.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "image"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -211,19 +258,13 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `image` a docker image
-          - `tmpfs` a `tmpfs`.
+          - `cluster` a Swarm cluster volume.
+          - `image` an OCI image.
           - `npipe` a named pipe from the host into the container.
-          - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "image"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -344,26 +385,26 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
-          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `image` Mounts an image.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-          - `npipe` Mounts a named pipe from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
           - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "image"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `image` Mounts an image.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -452,7 +493,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
           Options:
             description: |
@@ -801,7 +845,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -812,6 +858,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -825,6 +877,10 @@ definitions:
         description: |
           The time to wait before considering the check to have hung. It should
           be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
         type: "integer"
         format: "int64"
       Retries:
@@ -1435,7 +1491,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         example: ""
       Domainname:
@@ -1445,7 +1501,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         example: ""
       User:
@@ -1459,7 +1515,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1470,7 +1526,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1481,7 +1537,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1508,7 +1564,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1519,7 +1575,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1530,7 +1586,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1567,7 +1623,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         default: ""
         example: ""
@@ -1606,7 +1662,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1618,7 +1674,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "string"
         default: ""
         example: ""
@@ -1652,7 +1708,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "integer"
         default: 10
         x-nullable: true
@@ -2176,14 +2232,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 1239828
       GraphDriver:
         $ref: "#/definitions/DriverData"
       RootFS:
@@ -2316,14 +2364,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |-
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 172064416
       Labels:
         description: "User-defined key/value metadata."
         type: "object"
@@ -2377,6 +2417,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2825,14 +2869,6 @@ definitions:
         description: |
           Unique ID of the build cache record.
         example: "ndlpt0hhvkqcdfkputsk4cq9c"
-      Parent:
-        description: |
-          ID of the parent build cache record.
-
-          > **Deprecated**: This field is deprecated, and omitted if empty.
-        type: "string"
-        x-nullable: true
-        example: ""
       Parents:
         description: |
           List of parent build cache record IDs.
@@ -3039,7 +3075,8 @@ definitions:
           be used. If multiple endpoints have the same priority, endpoints are
           lexicographically sorted based on their network name, and the one
           that sorts first is picked.
-        type: "number"
+        type: "integer"
+        format: "int64"
         example:
           - 10
 
@@ -4517,6 +4554,7 @@ definitions:
           A counter that triggers an update even if no relevant parameters have
           been changed.
         type: "integer"
+        format: "uint64"
       Runtime:
         description: |
           Runtime is the type of runtime specified for the task executor.
@@ -5508,11 +5546,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -5563,8 +5601,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -5988,7 +6026,7 @@ definitions:
         type: "integer"
         format: "uint64"
         x-nullable: true
-        example: 18446744073709551615
+        example: "18446744073709551615"
 
   ContainerThrottlingData:
     description: |
@@ -6046,7 +6084,11 @@ definitions:
         example: 0
       stats:
         description: |
-          All the stats exported via memory.stat. when using cgroups v2.
+          All the stats exported via memory.stat.
+
+          The fields in this object differ between cgroups v1 and v2.
+          On cgroups v1, fields such as `cache`, `rss`, `mapped_file` are available.
+          On cgroups v2, fields such as `file`, `anon`, `inactive_file` are available.
 
           This field is Linux-specific and omitted for Windows containers.
         type: "object"
@@ -6386,7 +6428,9 @@ definitions:
         example: "linux"
       Arch:
         description: |
-          The architecture that the daemon is running on
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
         type: "string"
         example: "amd64"
       KernelVersion:
@@ -6546,7 +6590,7 @@ definitions:
 
           > **Deprecated**: netfilter module is now loaded on-demand and no longer
           > during daemon startup, making this field obsolete. This field is always
-          > `false` and will be removed in a API v1.49.
+          > `false` and will be removed in a API v1.50.
         type: "boolean"
         example: false
       BridgeNfIp6tables:
@@ -6557,7 +6601,7 @@ definitions:
 
           > **Deprecated**: netfilter module is now loaded on-demand, and no longer
           > during daemon startup, making this field obsolete. This field is always
-          > `false` and will be removed in a API v1.49.
+          > `false` and will be removed in a API v1.50.
         type: "boolean"
         example: false
       Debug:
@@ -6645,10 +6689,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -7698,8 +7745,11 @@ definitions:
       details, see documentation for the Topology object in the CSI
       specification.
     type: "object"
-    additionalProperties:
-      type: "string"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
 
   ImageManifestSummary:
     x-go-name: "ManifestSummary"
@@ -8336,7 +8386,8 @@ paths:
 
         To calculate the values shown by the `stats` command of the docker cli tool
         the following formulas can be used:
-        * used_memory = `memory_stats.usage - memory_stats.stats.cache`
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
         * available_memory = `memory_stats.limit`
         * Memory usage % = `(used_memory / available_memory) * 100.0`
         * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
@@ -9454,7 +9505,18 @@ paths:
           default: ""
         - name: "outputs"
           in: "query"
-          description: "BuildKit output configuration"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
           type: "string"
           default: ""
         - name: "version"
@@ -9492,7 +9554,7 @@ paths:
             Amount of disk space in bytes to keep for cache
 
             > **Deprecated**: This parameter is deprecated and has been renamed to "reserved-space".
-            > It is kept for backward compatibility and will be removed in API v1.49.
+            > It is kept for backward compatibility and will be removed in API v1.52.
           type: "integer"
           format: "int64"
         - name: "reserved-space"
@@ -9695,33 +9757,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -9847,7 +9883,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -12206,7 +12247,9 @@ paths:
                 description: |
                   Listen address used for inter-manager communication if the node
                   gets promoted to manager, as well as determining the networking
-                  interface used for the VXLAN Tunnel Endpoint (VTEP).
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
                 description: |
@@ -12240,6 +12283,7 @@ paths:
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/docs/api/v1.49.yaml b/_vendor/github.com/moby/moby/api/docs/v1.49.yaml
similarity index 98%
rename from _vendor/github.com/moby/moby/docs/api/v1.49.yaml
rename to _vendor/github.com/moby/moby/api/docs/v1.49.yaml
index 1183aaf2b59d..f9bc354274fe 100644
--- a/_vendor/github.com/moby/moby/docs/api/v1.49.yaml
+++ b/_vendor/github.com/moby/moby/api/docs/v1.49.yaml
@@ -81,7 +81,6 @@ info:
     {
       "username": "string",
       "password": "string",
-      "email": "string",
       "serveraddress": "string"
     }
     ```
@@ -173,6 +172,34 @@ tags:
     x-displayName: "System"
 
 definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
   Port:
     type: "object"
     description: "An open port on a container"
@@ -200,6 +227,26 @@ definitions:
       PublicPort: 80
       Type: "tcp"
 
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `image` an OCI image.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "image"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
   MountPoint:
     type: "object"
     description: |
@@ -211,19 +258,13 @@ definitions:
           The mount type:
 
           - `bind` a mount of a file or directory from the host into the container.
-          - `volume` a docker volume with the given `Name`.
-          - `image` a docker image
-          - `tmpfs` a `tmpfs`.
+          - `cluster` a Swarm cluster volume.
+          - `image` an OCI image.
           - `npipe` a named pipe from the host into the container.
-          - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "image"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
         example: "volume"
       Name:
         description: |
@@ -344,26 +385,26 @@ definitions:
         description: "Container path."
         type: "string"
       Source:
-        description: "Mount source (e.g. a volume name, a host path)."
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
         type: "string"
       Type:
         description: |
           The mount type. Available types:
 
-          - `bind` Mounts a file or directory from the host into the container. Must exist prior to creating the container.
-          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
-          - `image` Mounts an image.
-          - `tmpfs` Create a tmpfs with the given options. The mount source cannot be specified for tmpfs.
-          - `npipe` Mounts a named pipe from the host into the container. Must exist prior to creating the container.
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
           - `cluster` a Swarm cluster volume
-        type: "string"
-        enum:
-          - "bind"
-          - "volume"
-          - "image"
-          - "tmpfs"
-          - "npipe"
-          - "cluster"
+          - `image` Mounts an image.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
       ReadOnly:
         description: "Whether the mount should be read-only."
         type: "boolean"
@@ -452,7 +493,10 @@ definitions:
             type: "integer"
             format: "int64"
           Mode:
-            description: "The permission mode for the tmpfs mount in an integer."
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
             type: "integer"
           Options:
             description: |
@@ -801,7 +845,9 @@ definitions:
           Value: "UUID2"
 
   HealthConfig:
-    description: "A test to perform to check that the container is healthy."
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
     type: "object"
     properties:
       Test:
@@ -812,6 +858,12 @@ definitions:
           - `["NONE"]` disable healthcheck
           - `["CMD", args...]` exec arguments directly
           - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
         type: "array"
         items:
           type: "string"
@@ -825,6 +877,10 @@ definitions:
         description: |
           The time to wait before considering the check to have hung. It should
           be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
         type: "integer"
         format: "int64"
       Retries:
@@ -1435,7 +1491,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         example: ""
       Domainname:
@@ -1445,7 +1501,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         example: ""
       User:
@@ -1459,7 +1515,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1470,7 +1526,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1481,7 +1537,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1508,7 +1564,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1519,7 +1575,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1530,7 +1586,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always false. It must not be used, and will be removed in API v1.48.
+          > always false. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1567,7 +1623,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always empty. It must not be used, and will be removed in API v1.48.
+          > always empty. It must not be used, and will be removed in API v1.50.
         type: "string"
         default: ""
         example: ""
@@ -1606,7 +1662,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "boolean"
         default: false
         example: false
@@ -1618,7 +1674,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "string"
         default: ""
         example: ""
@@ -1652,7 +1708,7 @@ definitions:
           <p><br /></p>
 
           > **Deprecated**: this field is not part of the image specification and is
-          > always omitted. It must not be used, and will be removed in API v1.48.
+          > always omitted. It must not be used, and will be removed in API v1.50.
         type: "integer"
         default: 10
         x-nullable: true
@@ -2176,14 +2232,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 1239828
       GraphDriver:
         $ref: "#/definitions/DriverData"
       RootFS:
@@ -2316,14 +2364,6 @@ definitions:
         format: "int64"
         x-nullable: false
         example: 1239828
-      VirtualSize:
-        description: |-
-          Total size of the image including all layers it is composed of.
-
-          Deprecated: this field is omitted in API v1.44, but kept for backward compatibility. Use Size instead.
-        type: "integer"
-        format: "int64"
-        example: 172064416
       Labels:
         description: "User-defined key/value metadata."
         type: "object"
@@ -2377,6 +2417,10 @@ definitions:
       password:
         type: "string"
       email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
         type: "string"
       serveraddress:
         type: "string"
@@ -2825,14 +2869,6 @@ definitions:
         description: |
           Unique ID of the build cache record.
         example: "ndlpt0hhvkqcdfkputsk4cq9c"
-      Parent:
-        description: |
-          ID of the parent build cache record.
-
-          > **Deprecated**: This field is deprecated, and omitted if empty.
-        type: "string"
-        x-nullable: true
-        example: ""
       Parents:
         description: |
           List of parent build cache record IDs.
@@ -3039,7 +3075,8 @@ definitions:
           be used. If multiple endpoints have the same priority, endpoints are
           lexicographically sorted based on their network name, and the one
           that sorts first is picked.
-        type: "number"
+        type: "integer"
+        format: "int64"
         example:
           - 10
 
@@ -4517,6 +4554,7 @@ definitions:
           A counter that triggers an update even if no relevant parameters have
           been changed.
         type: "integer"
+        format: "uint64"
       Runtime:
         description: |
           Runtime is the type of runtime specified for the task executor.
@@ -5508,11 +5546,11 @@ definitions:
           com.example.some-other-label: "some-other-value"
       Data:
         description: |
-          Data is the data to store as a secret, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           It must be empty if the Driver field is set, in which case the data is
           loaded from an external secret store. The maximum allowed size is 500KB,
-          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/api/validation#MaxSecretSize).
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
 
           This field is only used to _create_ a secret, and is not returned by
           other endpoints.
@@ -5563,8 +5601,8 @@ definitions:
           type: "string"
       Data:
         description: |
-          Data is the data to store as a config, formatted as a Base64-url-safe-encoded
-          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-5)) string.
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
           The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
         type: "string"
       Templating:
@@ -5988,7 +6026,7 @@ definitions:
         type: "integer"
         format: "uint64"
         x-nullable: true
-        example: 18446744073709551615
+        example: "18446744073709551615"
 
   ContainerThrottlingData:
     description: |
@@ -6046,7 +6084,11 @@ definitions:
         example: 0
       stats:
         description: |
-          All the stats exported via memory.stat. when using cgroups v2.
+          All the stats exported via memory.stat.
+
+          The fields in this object differ between cgroups v1 and v2.
+          On cgroups v1, fields such as `cache`, `rss`, `mapped_file` are available.
+          On cgroups v2, fields such as `file`, `anon`, `inactive_file` are available.
 
           This field is Linux-specific and omitted for Windows containers.
         type: "object"
@@ -6386,7 +6428,9 @@ definitions:
         example: "linux"
       Arch:
         description: |
-          The architecture that the daemon is running on
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
         type: "string"
         example: "amd64"
       KernelVersion:
@@ -6546,7 +6590,7 @@ definitions:
 
           > **Deprecated**: netfilter module is now loaded on-demand and no longer
           > during daemon startup, making this field obsolete. This field is always
-          > `false` and will be removed in a API v1.49.
+          > `false` and will be removed in a API v1.50.
         type: "boolean"
         example: false
       BridgeNfIp6tables:
@@ -6557,7 +6601,7 @@ definitions:
 
           > **Deprecated**: netfilter module is now loaded on-demand, and no longer
           > during daemon startup, making this field obsolete. This field is always
-          > `false` and will be removed in a API v1.49.
+          > `false` and will be removed in a API v1.50.
         type: "boolean"
         example: false
       Debug:
@@ -6645,10 +6689,13 @@ definitions:
         example: "linux"
       Architecture:
         description: |
-          Hardware architecture of the host, as returned by the Go runtime
-          (`GOARCH`).
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
 
-          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
         type: "string"
         example: "x86_64"
       NCPU:
@@ -7698,8 +7745,11 @@ definitions:
       details, see documentation for the Topology object in the CSI
       specification.
     type: "object"
-    additionalProperties:
-      type: "string"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
 
   ImageManifestSummary:
     x-go-name: "ManifestSummary"
@@ -8336,7 +8386,8 @@ paths:
 
         To calculate the values shown by the `stats` command of the docker cli tool
         the following formulas can be used:
-        * used_memory = `memory_stats.usage - memory_stats.stats.cache`
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
         * available_memory = `memory_stats.limit`
         * Memory usage % = `(used_memory / available_memory) * 100.0`
         * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
@@ -9454,7 +9505,18 @@ paths:
           default: ""
         - name: "outputs"
           in: "query"
-          description: "BuildKit output configuration"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
           type: "string"
           default: ""
         - name: "version"
@@ -9492,7 +9554,7 @@ paths:
             Amount of disk space in bytes to keep for cache
 
             > **Deprecated**: This parameter is deprecated and has been renamed to "reserved-space".
-            > It is kept for backward compatibility and will be removed in API v1.49.
+            > It is kept for backward compatibility and will be removed in API v1.52.
           type: "integer"
           format: "int64"
         - name: "reserved-space"
@@ -9678,10 +9740,31 @@ paths:
           required: true
         - name: "manifests"
           in: "query"
-          description: "Include Manifests in the image summary."
+          description: |-
+            Include Manifests in the image summary.
+
+            The `manifests` and `platform` options are mutually exclusive, and
+            an error is produced if both are set.
           type: "boolean"
           default: false
           required: false
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |-
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show inspect. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            The `platform` and `manifests` options are mutually exclusive, and
+            an error is produced if both are set.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
       tags: ["Image"]
   /images/{name}/history:
     get:
@@ -9695,33 +9778,7 @@ paths:
           schema:
             type: "array"
             items:
-              type: "object"
-              x-go-name: HistoryResponseItem
-              title: "HistoryResponseItem"
-              description: "individual image layer information in response to ImageHistory operation"
-              required: [Id, Created, CreatedBy, Tags, Size, Comment]
-              properties:
-                Id:
-                  type: "string"
-                  x-nullable: false
-                Created:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                CreatedBy:
-                  type: "string"
-                  x-nullable: false
-                Tags:
-                  type: "array"
-                  items:
-                    type: "string"
-                Size:
-                  type: "integer"
-                  format: "int64"
-                  x-nullable: false
-                Comment:
-                  type: "string"
-                  x-nullable: false
+              $ref: "#/definitions/ImageHistoryResponseItem"
           examples:
             application/json:
               - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
@@ -9847,7 +9904,12 @@ paths:
   /images/{name}/tag:
     post:
       summary: "Tag an image"
-      description: "Tag an image so that it becomes part of a repository."
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
       operationId: "ImageTag"
       responses:
         201:
@@ -12206,7 +12268,9 @@ paths:
                 description: |
                   Listen address used for inter-manager communication if the node
                   gets promoted to manager, as well as determining the networking
-                  interface used for the VXLAN Tunnel Endpoint (VTEP).
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
                 type: "string"
               AdvertiseAddr:
                 description: |
@@ -12240,6 +12304,7 @@ paths:
               JoinToken:
                 description: "Secret token for joining this swarm."
                 type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
             example:
               ListenAddr: "0.0.0.0:2377"
               AdvertiseAddr: "192.168.1.1:2377"
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.5.md b/_vendor/github.com/moby/moby/api/docs/v1.5.md
new file mode 100644
index 000000000000..76c6142c1cb3
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.5.md
@@ -0,0 +1,1159 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.5"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent="smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.5
+
+# 1. Brief introduction
+
+- The Remote API is replacing rcli
+- Default port in the docker daemon is 2375
+- The API tends to be REST, but for some complex commands, like attach
+  or pull, the HTTP connection is hijacked to transport stdout stdin
+  and stderr
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+            "Id": "8dfafdbc3a40",
+            "Image": "ubuntu:latest",
+            "Command": "echo 1",
+            "Created": 1367854155,
+            "Status": "Exit 0",
+            "Ports":[{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+            "SizeRw":12288,
+            "SizeRootFs":0
+          },
+          {
+            "Id": "9cd87474be90",
+            "Image": "ubuntu:latest",
+            "Command": "echo 222222",
+            "Created": 1367854155,
+            "Status": "Exit 0",
+            "Ports":[],
+            "SizeRw":12288,
+            "SizeRootFs":0
+          },
+          {
+            "Id": "3176a2479c92",
+            "Image": "centos:latest",
+            "Command": "echo 3333333333333333",
+            "Created": 1367854154,
+            "Status": "Exit 0",
+            "Ports":[],
+            "SizeRw":12288,
+            "SizeRootFs":0
+          },
+          {
+            "Id": "4cb07b47f9fb",
+            "Image": "fedora:latest",
+            "Command": "echo 444444444444444444444444444444444",
+            "Created": 1367854152,
+            "Status": "Exit 0",
+            "Ports":[],
+            "SizeRw":12288,
+            "SizeRootFs":0
+          }
+        ]
+
+Query Parameters:
+
+     
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+    Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created containers, include non-running ones.
+-   **since** – Show only containers created since Id, include non-running ones.
+-   **before** – Show only containers created before Id, include non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers sizes
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+          "Hostname":"",
+          "User":"",
+          "Memory":0,
+          "MemorySwap":0,
+          "AttachStdin":false,
+          "AttachStdout":true,
+          "AttachStderr":true,
+          "PortSpecs":null,
+          "Privileged": false,
+          "Tty":false,
+          "OpenStdin":false,
+          "StdinOnce":false,
+          "Env":null,
+          "Cmd":[
+            "date"
+          ],
+          "Dns":null,
+          "Image":"ubuntu",
+          "Volumes":{},
+          "VolumesFrom":"",
+          "WorkingDir":""
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+          "Id":"e90e34656806"
+          "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+          "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+          "Created": "2013-05-07T14:51:42.041847+02:00",
+          "Path": "date",
+          "Args": [],
+          "Config": {
+            "Hostname": "4fa6e0f0c678",
+            "User": "",
+            "Memory": 0,
+            "MemorySwap": 0,
+            "AttachStdin": false,
+            "AttachStdout": true,
+            "AttachStderr": true,
+            "PortSpecs": null,
+            "Tty": false,
+            "OpenStdin": false,
+            "StdinOnce": false,
+            "Env": null,
+            "Cmd": [
+              "date"
+            ],
+            "Dns": null,
+            "Image": "ubuntu",
+            "Volumes": {},
+            "VolumesFrom": "",
+            "WorkingDir":""
+          },
+          "State": {
+            "Running": false,
+            "Pid": 0,
+            "ExitCode": 0,
+            "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+            "Ghost": false
+          },
+          "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+          "NetworkSettings": {
+            "IpAddress": "",
+            "IpPrefixLen": 0,
+            "Gateway": "",
+            "Bridge": "",
+            "PortMapping": null
+          },
+          "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+          "ResolvConfPath": "/etc/resolv.conf",
+          "Volumes": {}
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id)/top`
+
+List processes running inside the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+          "Titles":[
+            "USER",
+            "PID",
+            "%CPU",
+            "%MEM",
+            "VSZ",
+            "RSS",
+            "TTY",
+            "STAT",
+            "START",
+            "TIME",
+            "COMMAND"
+          ],
+          "Processes":[
+            ["root","20147","0.0","0.1","18060","1864","pts/4","S","10:06","0:00","bash"],
+            ["root","20271","0.0","0.0","4312","352","pts/4","S+","10:07","0:00","sleep","10"]
+          ]
+        }
+
+Query Parameters:
+
+-   **ps_args** – ps arguments to use (e.g., aux)
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+            "Path":"/dev",
+            "Kind":0
+          },
+          {
+            "Path":"/dev/kmsg",
+            "Kind":1
+          },
+          {
+            "Path":"/test",
+            "Kind":1
+          }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/(id)/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+          "Binds":["/tmp:/tmp"],
+          "LxcConf":[{"Key":"lxc.utsname","Value":"docker"}]
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain
+
+Json Parameters:
+
+     
+
+-   **hostConfig** – the container's host configuration (optional)
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+          "Resource":"test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/(format)`
+
+List images `format` could be json or viz (json default)
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+            "Repository":"ubuntu",
+            "Tag":"precise",
+            "Id":"b750fe79269d",
+            "Created":1364102658,
+            "Size":24653,
+            "VirtualSize":180116135
+          },
+          {
+            "Repository":"ubuntu",
+            "Tag":"12.04",
+            "Id":"b750fe79269d",
+            "Created":1364102658,
+            "Size":24653,
+            "VirtualSize":180116135
+          }
+        ]
+
+**Example request**:
+
+        GET /images/viz HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        digraph docker {
+        "d82cbacda43a" -> "074be284591f"
+        "1496068ca813" -> "08306dc45919"
+        "08306dc45919" -> "0e7893146ac2"
+        "b750fe79269d" -> "1496068ca813"
+        base -> "27cf78414709" [style=invis]
+        "f71189fff3de" -> "9a33b36209ed"
+        "27cf78414709" -> "b750fe79269d"
+        "0e7893146ac2" -> "d6434d954665"
+        "d6434d954665" -> "d82cbacda43a"
+        base -> "e9aa60c60128" [style=invis]
+        "074be284591f" -> "f71189fff3de"
+        "b750fe79269d" [label="b750fe79269d\nubuntu",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "e9aa60c60128" [label="e9aa60c60128\ncentos",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "9a33b36209ed" [label="9a33b36209ed\nfedora",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        base [style=invisible]
+        }
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by defaul
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=ubuntu HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pulling..."}
+        {"status":"Pulling", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Insert a file in an image
+
+`POST /images/(name)/insert`
+
+Insert a file from `url` in the image `name` at `path`
+
+**Example request**:
+
+        POST /images/test/insert?path=/usr&url=myurl HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Inserting..."}
+        {"status":"Inserting", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-	**url** – The url from where the file is taken
+-	**path** – The path where the file is stored
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/centos/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+          "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+          "parent":"27cf784147099545",
+          "created":"2013-03-23T22:24:18.818426-07:00",
+          "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+          "container_config":
+            {
+              "Hostname":"",
+              "User":"",
+              "Memory":0,
+              "MemorySwap":0,
+              "AttachStdin":false,
+              "AttachStdout":false,
+              "AttachStderr":false,
+              "PortSpecs":null,
+              "Tty":true,
+              "OpenStdin":true,
+              "StdinOnce":false,
+              "Env":null,
+              "Cmd": ["/bin/bash"],
+              "Dns":null,
+              "Image":"centos",
+              "Volumes":null,
+              "VolumesFrom":"",
+              "WorkingDir":""
+            },
+          "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/fedora/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+            "Id":"b750fe79269d",
+            "Created":1364102658,
+            "CreatedBy":"/bin/bash"
+          },
+          {
+            "Id":"27cf78414709",
+            "Created":1364068391,
+            "CreatedBy":""
+          }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pushing..."}
+        {"status":"Pushing", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+    The `X-Registry-Auth` header can be used to
+    include a base64-encoded AuthConfig object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+          {"Untagged":"3e2f21a89f"},
+          {"Deleted":"3e2f21a89f"},
+          {"Deleted":"53b4f83ac9"}
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com)
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+            "Name":"cespare/sshd",
+            "Description":""
+          },
+          {
+            "Name":"johnfuller/sshd",
+            "Description":""
+          },
+          {
+            "Name":"dhrp/mongodb-sshd",
+            "Description":""
+          }
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+        {{ STREAM }}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+    The archive must include a file called Dockerfile at its root. I
+    may include any number of other files, which will be accessible in
+    the build context (See the ADD build command).
+
+    The Content-type header should be set to "application/tar".
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – build source URI (git or HTTPS/HTTP)
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+-   **rm** – remove intermediate containers after a successful build
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+          "username":"hannibal",
+          "password:"xxxx",
+          "email":"hannibal@a-team.com",
+          "serveraddress":"https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+          "Containers":11,
+          "Images":16,
+          "Debug":false,
+          "NFd": 11,
+          "NGoroutines":21,
+          "MemoryLimit":true,
+          "SwapLimit":false,
+          "IPv4Forwarding":true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+          "Version":"0.2.2",
+          "GitCommit":"5a2a5cc+CHANGES",
+          "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+            "Cmd": ["cat", "/world"],
+            "PortSpecs":["22"]
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+            Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+        <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"create","id":"dfdf82bd3881","from":"ubuntu:latest","time":1374067924}
+        {"status":"start","id":"dfdf82bd3881","from":"ubuntu:latest","time":1374067924}
+        {"status":"stop","id":"dfdf82bd3881","from":"ubuntu:latest","time":1374067966}
+        {"status":"destroy","id":"dfdf82bd3881","from":"ubuntu:latest","time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+Here are the steps of `docker run`:
+
+ - Create the container
+ - If the status code is 404, it means the image doesn't exist:
+   Try to pull it - Then retry to create the container
+ - Start the container
+ - If you are not in detached mode:
+   Attach to the container, using logs=1 (to have stdout and stderr
+   from the container's start) and stream=1
+ - If in detached mode or only stdin is attached:
+   Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.50.yaml b/_vendor/github.com/moby/moby/api/docs/v1.50.yaml
new file mode 100644
index 000000000000..062e1cd57b91
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.50.yaml
@@ -0,0 +1,13442 @@
+# A Swagger 2.0 (a.k.a. OpenAPI) definition of the Engine API.
+#
+# This is used for generating API documentation and the types used by the
+# client/server. See api/README.md for more information.
+#
+# Some style notes:
+# - This file is used by ReDoc, which allows GitHub Flavored Markdown in
+#   descriptions.
+# - There is no maximum line length, for ease of editing and pretty diffs.
+# - operationIds are in the format "NounVerb", with a singular noun.
+
+swagger: "2.0"
+schemes:
+  - "http"
+  - "https"
+produces:
+  - "application/json"
+  - "text/plain"
+consumes:
+  - "application/json"
+  - "text/plain"
+basePath: "/v1.50"
+info:
+  title: "Docker Engine API"
+  version: "1.50"
+  x-logo:
+    url: "https://docs.docker.com/assets/images/logo-docker-main.png"
+  description: |
+    The Engine API is an HTTP API served by Docker Engine. It is the API the
+    Docker client uses to communicate with the Engine, so everything the Docker
+    client can do can be done with the API.
+
+    Most of the client's commands map directly to API endpoints (e.g. `docker ps`
+    is `GET /containers/json`). The notable exception is running containers,
+    which consists of several API calls.
+
+    # Errors
+
+    The API uses standard HTTP status codes to indicate the success or failure
+    of the API call. The body of the response will be JSON in the following
+    format:
+
+    ```
+    {
+      "message": "page not found"
+    }
+    ```
+
+    # Versioning
+
+    The API is usually changed in each release, so API calls are versioned to
+    ensure that clients don't break. To lock to a specific version of the API,
+    you prefix the URL with its version, for example, call `/v1.30/info` to use
+    the v1.30 version of the `/info` endpoint. If the API version specified in
+    the URL is not supported by the daemon, a HTTP `400 Bad Request` error message
+    is returned.
+
+    If you omit the version-prefix, the current version of the API (v1.50) is used.
+    For example, calling `/info` is the same as calling `/v1.50/info`. Using the
+    API without a version-prefix is deprecated and will be removed in a future release.
+
+    Engine releases in the near future should support this version of the API,
+    so your client will continue to work even if it is talking to a newer Engine.
+
+    The API uses an open schema model, which means the server may add extra properties
+    to responses. Likewise, the server will ignore any extra query parameters and
+    request body properties. When you write clients, you need to ignore additional
+    properties in responses to ensure they do not break when talking to newer
+    daemons.
+
+
+    # Authentication
+
+    Authentication for registries is handled client side. The client has to send
+    authentication details to various endpoints that need to communicate with
+    registries, such as `POST /images/(name)/push`. These are sent as
+    `X-Registry-Auth` header as a [base64url encoded](https://tools.ietf.org/html/rfc4648#section-5)
+    (JSON) string with the following structure:
+
+    ```
+    {
+      "username": "string",
+      "password": "string",
+      "serveraddress": "string"
+    }
+    ```
+
+    The `serveraddress` is a domain/IP without a protocol. Throughout this
+    structure, double quotes are required.
+
+    If you have already got an identity token from the [`/auth` endpoint](#operation/SystemAuth),
+    you can just pass this instead of credentials:
+
+    ```
+    {
+      "identitytoken": "9cbaf023786cd7..."
+    }
+    ```
+
+# The tags on paths define the menu sections in the ReDoc documentation, so
+# the usage of tags must make sense for that:
+# - They should be singular, not plural.
+# - There should not be too many tags, or the menu becomes unwieldy. For
+#   example, it is preferable to add a path to the "System" tag instead of
+#   creating a tag with a single path in it.
+# - The order of tags in this list defines the order in the menu.
+tags:
+  # Primary objects
+  - name: "Container"
+    x-displayName: "Containers"
+    description: |
+      Create and manage containers.
+  - name: "Image"
+    x-displayName: "Images"
+  - name: "Network"
+    x-displayName: "Networks"
+    description: |
+      Networks are user-defined networks that containers can be attached to.
+      See the [networking documentation](https://docs.docker.com/network/)
+      for more information.
+  - name: "Volume"
+    x-displayName: "Volumes"
+    description: |
+      Create and manage persistent storage that can be attached to containers.
+  - name: "Exec"
+    x-displayName: "Exec"
+    description: |
+      Run new commands inside running containers. Refer to the
+      [command-line reference](https://docs.docker.com/engine/reference/commandline/exec/)
+      for more information.
+
+      To exec a command in a container, you first need to create an exec instance,
+      then start it. These two API endpoints are wrapped up in a single command-line
+      command, `docker exec`.
+
+  # Swarm things
+  - name: "Swarm"
+    x-displayName: "Swarm"
+    description: |
+      Engines can be clustered together in a swarm. Refer to the
+      [swarm mode documentation](https://docs.docker.com/engine/swarm/)
+      for more information.
+  - name: "Node"
+    x-displayName: "Nodes"
+    description: |
+      Nodes are instances of the Engine participating in a swarm. Swarm mode
+      must be enabled for these endpoints to work.
+  - name: "Service"
+    x-displayName: "Services"
+    description: |
+      Services are the definitions of tasks to run on a swarm. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Task"
+    x-displayName: "Tasks"
+    description: |
+      A task is a container running on a swarm. It is the atomic scheduling unit
+      of swarm. Swarm mode must be enabled for these endpoints to work.
+  - name: "Secret"
+    x-displayName: "Secrets"
+    description: |
+      Secrets are sensitive data that can be used by services. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Config"
+    x-displayName: "Configs"
+    description: |
+      Configs are application configurations that can be used by services. Swarm
+      mode must be enabled for these endpoints to work.
+  # System things
+  - name: "Plugin"
+    x-displayName: "Plugins"
+  - name: "System"
+    x-displayName: "System"
+
+definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
+  Port:
+    type: "object"
+    description: "An open port on a container"
+    required: [PrivatePort, Type]
+    properties:
+      IP:
+        type: "string"
+        format: "ip-address"
+        description: "Host IP address that the container's port is mapped to"
+      PrivatePort:
+        type: "integer"
+        format: "uint16"
+        x-nullable: false
+        description: "Port on the container"
+      PublicPort:
+        type: "integer"
+        format: "uint16"
+        description: "Port exposed on the host"
+      Type:
+        type: "string"
+        x-nullable: false
+        enum: ["tcp", "udp", "sctp"]
+    example:
+      PrivatePort: 8080
+      PublicPort: 80
+      Type: "tcp"
+
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `image` an OCI image.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "image"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
+  MountPoint:
+    type: "object"
+    description: |
+      MountPoint represents a mount point configuration inside the container.
+      This is used for reporting the mountpoints in use by a container.
+    properties:
+      Type:
+        description: |
+          The mount type:
+
+          - `bind` a mount of a file or directory from the host into the container.
+          - `cluster` a Swarm cluster volume.
+          - `image` an OCI image.
+          - `npipe` a named pipe from the host into the container.
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
+        example: "volume"
+      Name:
+        description: |
+          Name is the name reference to the underlying data defined by `Source`
+          e.g., the volume name.
+        type: "string"
+        example: "myvolume"
+      Source:
+        description: |
+          Source location of the mount.
+
+          For volumes, this contains the storage location of the volume (within
+          `/var/lib/docker/volumes/`). For bind-mounts, and `npipe`, this contains
+          the source (host) part of the bind-mount. For `tmpfs` mount points, this
+          field is empty.
+        type: "string"
+        example: "/var/lib/docker/volumes/myvolume/_data"
+      Destination:
+        description: |
+          Destination is the path relative to the container root (`/`) where
+          the `Source` is mounted inside the container.
+        type: "string"
+        example: "/usr/share/nginx/html/"
+      Driver:
+        description: |
+          Driver is the volume driver used to create the volume (if it is a volume).
+        type: "string"
+        example: "local"
+      Mode:
+        description: |
+          Mode is a comma separated list of options supplied by the user when
+          creating the bind/volume mount.
+
+          The default is platform-specific (`"z"` on Linux, empty on Windows).
+        type: "string"
+        example: "z"
+      RW:
+        description: |
+          Whether the mount is mounted writable (read-write).
+        type: "boolean"
+        example: true
+      Propagation:
+        description: |
+          Propagation describes how mounts are propagated from the host into the
+          mount point, and vice-versa. Refer to the [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
+          for details. This field is not used on Windows.
+        type: "string"
+        example: ""
+
+  DeviceMapping:
+    type: "object"
+    description: "A device mapping between the host and container"
+    properties:
+      PathOnHost:
+        type: "string"
+      PathInContainer:
+        type: "string"
+      CgroupPermissions:
+        type: "string"
+    example:
+      PathOnHost: "/dev/deviceName"
+      PathInContainer: "/dev/deviceName"
+      CgroupPermissions: "mrw"
+
+  DeviceRequest:
+    type: "object"
+    description: "A request for devices to be sent to device drivers"
+    properties:
+      Driver:
+        type: "string"
+        example: "nvidia"
+      Count:
+        type: "integer"
+        example: -1
+      DeviceIDs:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "0"
+          - "1"
+          - "GPU-fef8089b-4820-abfc-e83e-94318197576e"
+      Capabilities:
+        description: |
+          A list of capabilities; an OR list of AND lists of capabilities.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          # gpu AND nvidia AND compute
+          - ["gpu", "nvidia", "compute"]
+      Options:
+        description: |
+          Driver-specific options, specified as a key/value pairs. These options
+          are passed directly to the driver.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  ThrottleDevice:
+    type: "object"
+    properties:
+      Path:
+        description: "Device path"
+        type: "string"
+      Rate:
+        description: "Rate"
+        type: "integer"
+        format: "int64"
+        minimum: 0
+
+  Mount:
+    type: "object"
+    properties:
+      Target:
+        description: "Container path."
+        type: "string"
+      Source:
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
+        type: "string"
+      Type:
+        description: |
+          The mount type. Available types:
+
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `cluster` a Swarm cluster volume
+          - `image` Mounts an image.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
+      ReadOnly:
+        description: "Whether the mount should be read-only."
+        type: "boolean"
+      Consistency:
+        description: "The consistency requirement for the mount: `default`, `consistent`, `cached`, or `delegated`."
+        type: "string"
+      BindOptions:
+        description: "Optional configuration for the `bind` type."
+        type: "object"
+        properties:
+          Propagation:
+            description: "A propagation mode with the value `[r]private`, `[r]shared`, or `[r]slave`."
+            type: "string"
+            enum:
+              - "private"
+              - "rprivate"
+              - "shared"
+              - "rshared"
+              - "slave"
+              - "rslave"
+          NonRecursive:
+            description: "Disable recursive bind mount."
+            type: "boolean"
+            default: false
+          CreateMountpoint:
+            description: "Create mount point on host if missing"
+            type: "boolean"
+            default: false
+          ReadOnlyNonRecursive:
+            description: |
+               Make the mount non-recursively read-only, but still leave the mount recursive
+               (unless NonRecursive is set to `true` in conjunction).
+
+               Added in v1.44, before that version all read-only mounts were
+               non-recursive by default. To match the previous behaviour this
+               will default to `true` for clients on versions prior to v1.44.
+            type: "boolean"
+            default: false
+          ReadOnlyForceRecursive:
+            description: "Raise an error if the mount cannot be made recursively read-only."
+            type: "boolean"
+            default: false
+      VolumeOptions:
+        description: "Optional configuration for the `volume` type."
+        type: "object"
+        properties:
+          NoCopy:
+            description: "Populate volume with data from the target."
+            type: "boolean"
+            default: false
+          Labels:
+            description: "User-defined key/value metadata."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          DriverConfig:
+            description: "Map of driver specific options"
+            type: "object"
+            properties:
+              Name:
+                description: "Name of the driver to use to create the volume."
+                type: "string"
+              Options:
+                description: "key/value map of driver specific options."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+          Subpath:
+            description: "Source path inside the volume. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-volume/subdirectory"
+      ImageOptions:
+        description: "Optional configuration for the `image` type."
+        type: "object"
+        properties:
+          Subpath:
+            description: "Source path inside the image. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-image/subdirectory"
+      TmpfsOptions:
+        description: "Optional configuration for the `tmpfs` type."
+        type: "object"
+        properties:
+          SizeBytes:
+            description: "The size for the tmpfs mount in bytes."
+            type: "integer"
+            format: "int64"
+          Mode:
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
+            type: "integer"
+          Options:
+            description: |
+              The options to be passed to the tmpfs mount. An array of arrays.
+              Flag options should be provided as 1-length arrays. Other types
+              should be provided as as 2-length arrays, where the first item is
+              the key and the second the value.
+            type: "array"
+            items:
+              type: "array"
+              minItems: 1
+              maxItems: 2
+              items:
+                type: "string"
+            example:
+              [["noexec"]]
+
+  RestartPolicy:
+    description: |
+      The behavior to apply when the container exits. The default is not to
+      restart.
+
+      An ever increasing delay (double the previous delay, starting at 100ms) is
+      added before each restart to prevent flooding the server.
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        description: |
+          - Empty string means not to restart
+          - `no` Do not automatically restart
+          - `always` Always restart
+          - `unless-stopped` Restart always except when the user has manually stopped the container
+          - `on-failure` Restart only when the container exit code is non-zero
+        enum:
+          - ""
+          - "no"
+          - "always"
+          - "unless-stopped"
+          - "on-failure"
+      MaximumRetryCount:
+        type: "integer"
+        description: |
+          If `on-failure` is used, the number of times to retry before giving up.
+
+  Resources:
+    description: "A container's resources (cgroups config, ulimits, etc)"
+    type: "object"
+    properties:
+      # Applicable to all platforms
+      CpuShares:
+        description: |
+          An integer value representing this container's relative CPU weight
+          versus other containers.
+        type: "integer"
+      Memory:
+        description: "Memory limit in bytes."
+        type: "integer"
+        format: "int64"
+        default: 0
+      # Applicable to UNIX platforms
+      CgroupParent:
+        description: |
+          Path to `cgroups` under which the container's `cgroup` is created. If
+          the path is not absolute, the path is considered to be relative to the
+          `cgroups` path of the init process. Cgroups are created if they do not
+          already exist.
+        type: "string"
+      BlkioWeight:
+        description: "Block IO weight (relative weight)."
+        type: "integer"
+        minimum: 0
+        maximum: 1000
+      BlkioWeightDevice:
+        description: |
+          Block IO weight (relative device weight) in the form:
+
+          ```
+          [{"Path": "device_path", "Weight": weight}]
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Path:
+              type: "string"
+            Weight:
+              type: "integer"
+              minimum: 0
+      BlkioDeviceReadBps:
+        description: |
+          Limit read rate (bytes per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteBps:
+        description: |
+          Limit write rate (bytes per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceReadIOps:
+        description: |
+          Limit read rate (IO per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteIOps:
+        description: |
+          Limit write rate (IO per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      CpuPeriod:
+        description: "The length of a CPU period in microseconds."
+        type: "integer"
+        format: "int64"
+      CpuQuota:
+        description: |
+          Microseconds of CPU time that the container can get in a CPU period.
+        type: "integer"
+        format: "int64"
+      CpuRealtimePeriod:
+        description: |
+          The length of a CPU real-time period in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpuRealtimeRuntime:
+        description: |
+          The length of a CPU real-time runtime in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpusetCpus:
+        description: |
+          CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+        type: "string"
+        example: "0-3"
+      CpusetMems:
+        description: |
+          Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only
+          effective on NUMA systems.
+        type: "string"
+      Devices:
+        description: "A list of devices to add to the container."
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceMapping"
+      DeviceCgroupRules:
+        description: "a list of cgroup rules to apply to the container"
+        type: "array"
+        items:
+          type: "string"
+          example: "c 13:* rwm"
+      DeviceRequests:
+        description: |
+          A list of requests for devices to be sent to device drivers.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceRequest"
+      KernelMemoryTCP:
+        description: |
+          Hard limit for kernel TCP buffer memory (in bytes). Depending on the
+          OCI runtime in use, this option may be ignored. It is no longer supported
+          by the default (runc) runtime.
+
+          This field is omitted when empty.
+        type: "integer"
+        format: "int64"
+      MemoryReservation:
+        description: "Memory soft limit in bytes."
+        type: "integer"
+        format: "int64"
+      MemorySwap:
+        description: |
+          Total memory limit (memory + swap). Set as `-1` to enable unlimited
+          swap.
+        type: "integer"
+        format: "int64"
+      MemorySwappiness:
+        description: |
+          Tune a container's memory swappiness behavior. Accepts an integer
+          between 0 and 100.
+        type: "integer"
+        format: "int64"
+        minimum: 0
+        maximum: 100
+      NanoCpus:
+        description: "CPU quota in units of 10<sup>-9</sup> CPUs."
+        type: "integer"
+        format: "int64"
+      OomKillDisable:
+        description: "Disable OOM Killer for the container."
+        type: "boolean"
+      Init:
+        description: |
+          Run an init inside the container that forwards signals and reaps
+          processes. This field is omitted if empty, and the default (as
+          configured on the daemon) is used.
+        type: "boolean"
+        x-nullable: true
+      PidsLimit:
+        description: |
+          Tune a container's PIDs limit. Set `0` or `-1` for unlimited, or `null`
+          to not change.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+      Ulimits:
+        description: |
+          A list of resource limits to set in the container. For example:
+
+          ```
+          {"Name": "nofile", "Soft": 1024, "Hard": 2048}
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Name:
+              description: "Name of ulimit"
+              type: "string"
+            Soft:
+              description: "Soft limit"
+              type: "integer"
+            Hard:
+              description: "Hard limit"
+              type: "integer"
+      # Applicable to Windows
+      CpuCount:
+        description: |
+          The number of usable CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      CpuPercent:
+        description: |
+          The usable percentage of the available CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      IOMaximumIOps:
+        description: "Maximum IOps for the container system drive (Windows only)"
+        type: "integer"
+        format: "int64"
+      IOMaximumBandwidth:
+        description: |
+          Maximum IO in bytes per second for the container system drive
+          (Windows only).
+        type: "integer"
+        format: "int64"
+
+  Limit:
+    description: |
+      An object describing a limit on resources which can be requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      Pids:
+        description: |
+          Limits the maximum number of PIDs in the container. Set `0` for unlimited.
+        type: "integer"
+        format: "int64"
+        default: 0
+        example: 100
+
+  ResourceObject:
+    description: |
+      An object describing the resources which can be advertised by a node and
+      requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+
+  GenericResources:
+    description: |
+      User-defined resources can be either Integer resources (e.g, `SSD=3`) or
+      String resources (e.g, `GPU=UUID1`).
+    type: "array"
+    items:
+      type: "object"
+      properties:
+        NamedResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "string"
+        DiscreteResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "integer"
+              format: "int64"
+    example:
+      - DiscreteResourceSpec:
+          Kind: "SSD"
+          Value: 3
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID1"
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID2"
+
+  HealthConfig:
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
+    type: "object"
+    properties:
+      Test:
+        description: |
+          The test to perform. Possible values are:
+
+          - `[]` inherit healthcheck from image or parent image
+          - `["NONE"]` disable healthcheck
+          - `["CMD", args...]` exec arguments directly
+          - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
+        type: "array"
+        items:
+          type: "string"
+      Interval:
+        description: |
+          The time to wait between checks in nanoseconds. It should be 0 or at
+          least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      Timeout:
+        description: |
+          The time to wait before considering the check to have hung. It should
+          be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
+        type: "integer"
+        format: "int64"
+      Retries:
+        description: |
+          The number of consecutive failures needed to consider a container as
+          unhealthy. 0 means inherit.
+        type: "integer"
+      StartPeriod:
+        description: |
+          Start period for the container to initialize before starting
+          health-retries countdown in nanoseconds. It should be 0 or at least
+          1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      StartInterval:
+        description: |
+          The time to wait between checks in nanoseconds during the start period.
+          It should be 0 or at least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+
+  Health:
+    description: |
+      Health stores information about the container's healthcheck results.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          Status is one of `none`, `starting`, `healthy` or `unhealthy`
+
+          - "none"      Indicates there is no healthcheck
+          - "starting"  Starting indicates that the container is not yet ready
+          - "healthy"   Healthy indicates that the container is running correctly
+          - "unhealthy" Unhealthy indicates that the container has a problem
+        type: "string"
+        enum:
+          - "none"
+          - "starting"
+          - "healthy"
+          - "unhealthy"
+        example: "healthy"
+      FailingStreak:
+        description: "FailingStreak is the number of consecutive failures"
+        type: "integer"
+        example: 0
+      Log:
+        type: "array"
+        description: |
+          Log contains the last few results (oldest first)
+        items:
+          $ref: "#/definitions/HealthcheckResult"
+
+  HealthcheckResult:
+    description: |
+      HealthcheckResult stores information about a single run of a healthcheck probe
+    type: "object"
+    x-nullable: true
+    properties:
+      Start:
+        description: |
+          Date and time at which this check started in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2020-01-04T10:44:24.496525531Z"
+      End:
+        description: |
+          Date and time at which this check ended in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2020-01-04T10:45:21.364524523Z"
+      ExitCode:
+        description: |
+          ExitCode meanings:
+
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (considered unhealthy)
+          - other values: error running probe
+        type: "integer"
+        example: 0
+      Output:
+        description: "Output from last check"
+        type: "string"
+
+  HostConfig:
+    description: "Container configuration that depends on the host we are running on"
+    allOf:
+      - $ref: "#/definitions/Resources"
+      - type: "object"
+        properties:
+          # Applicable to all platforms
+          Binds:
+            type: "array"
+            description: |
+              A list of volume bindings for this container. Each volume binding
+              is a string in one of these forms:
+
+              - `host-src:container-dest[:options]` to bind-mount a host path
+                into the container. Both `host-src`, and `container-dest` must
+                be an _absolute_ path.
+              - `volume-name:container-dest[:options]` to bind-mount a volume
+                managed by a volume driver into the container. `container-dest`
+                must be an _absolute_ path.
+
+              `options` is an optional, comma-delimited list of:
+
+              - `nocopy` disables automatic copying of data from the container
+                path to the volume. The `nocopy` flag only applies to named volumes.
+              - `[ro|rw]` mounts a volume read-only or read-write, respectively.
+                If omitted or set to `rw`, volumes are mounted read-write.
+              - `[z|Z]` applies SELinux labels to allow or deny multiple containers
+                to read and write to the same volume.
+                  - `z`: a _shared_ content label is applied to the content. This
+                    label indicates that multiple containers can share the volume
+                    content, for both reading and writing.
+                  - `Z`: a _private unshared_ label is applied to the content.
+                    This label indicates that only the current container can use
+                    a private volume. Labeling systems such as SELinux require
+                    proper labels to be placed on volume content that is mounted
+                    into a container. Without a label, the security system can
+                    prevent a container's processes from using the content. By
+                    default, the labels set by the host operating system are not
+                    modified.
+              - `[[r]shared|[r]slave|[r]private]` specifies mount
+                [propagation behavior](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt).
+                This only applies to bind-mounted volumes, not internal volumes
+                or named volumes. Mount propagation requires the source mount
+                point (the location where the source directory is mounted in the
+                host operating system) to have the correct propagation properties.
+                For shared volumes, the source mount point must be set to `shared`.
+                For slave volumes, the mount must be set to either `shared` or
+                `slave`.
+            items:
+              type: "string"
+          ContainerIDFile:
+            type: "string"
+            description: "Path to a file where the container ID is written"
+            example: ""
+          LogConfig:
+            type: "object"
+            description: "The logging configuration for this container"
+            properties:
+              Type:
+                description: |-
+                  Name of the logging driver used for the container or "none"
+                  if logging is disabled.
+                type: "string"
+                enum:
+                  - "local"
+                  - "json-file"
+                  - "syslog"
+                  - "journald"
+                  - "gelf"
+                  - "fluentd"
+                  - "awslogs"
+                  - "splunk"
+                  - "etwlogs"
+                  - "none"
+              Config:
+                description: |-
+                  Driver-specific configuration options for the logging driver.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "5"
+                  "max-size": "10m"
+          NetworkMode:
+            type: "string"
+            description: |
+              Network mode to use for this container. Supported standard values
+              are: `bridge`, `host`, `none`, and `container:<name|id>`. Any
+              other value is taken as a custom network's name to which this
+              container should connect to.
+          PortBindings:
+            $ref: "#/definitions/PortMap"
+          RestartPolicy:
+            $ref: "#/definitions/RestartPolicy"
+          AutoRemove:
+            type: "boolean"
+            description: |
+              Automatically remove the container when the container's process
+              exits. This has no effect if `RestartPolicy` is set.
+          VolumeDriver:
+            type: "string"
+            description: "Driver that this container uses to mount volumes."
+          VolumesFrom:
+            type: "array"
+            description: |
+              A list of volumes to inherit from another container, specified in
+              the form `<container name>[:<ro|rw>]`.
+            items:
+              type: "string"
+          Mounts:
+            description: |
+              Specification for mounts to be added to the container.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          ConsoleSize:
+            type: "array"
+            description: |
+              Initial console size, as an `[height, width]` array.
+            x-nullable: true
+            minItems: 2
+            maxItems: 2
+            items:
+              type: "integer"
+              minimum: 0
+            example: [80, 64]
+          Annotations:
+            type: "object"
+            description: |
+              Arbitrary non-identifying metadata attached to container and
+              provided to the runtime when the container is started.
+            additionalProperties:
+              type: "string"
+
+          # Applicable to UNIX platforms
+          CapAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CapDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CgroupnsMode:
+            type: "string"
+            enum:
+              - "private"
+              - "host"
+            description: |
+              cgroup namespace mode for the container. Possible values are:
+
+              - `"private"`: the container runs in its own private cgroup namespace
+              - `"host"`: use the host system's cgroup namespace
+
+              If not specified, the daemon default is used, which can either be `"private"`
+              or `"host"`, depending on daemon version, kernel support and configuration.
+          Dns:
+            type: "array"
+            description: "A list of DNS servers for the container to use."
+            items:
+              type: "string"
+          DnsOptions:
+            type: "array"
+            description: "A list of DNS options."
+            items:
+              type: "string"
+          DnsSearch:
+            type: "array"
+            description: "A list of DNS search domains."
+            items:
+              type: "string"
+          ExtraHosts:
+            type: "array"
+            description: |
+              A list of hostnames/IP mappings to add to the container's `/etc/hosts`
+              file. Specified in the form `["hostname:IP"]`.
+            items:
+              type: "string"
+          GroupAdd:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          IpcMode:
+            type: "string"
+            description: |
+              IPC sharing mode for the container. Possible values are:
+
+              - `"none"`: own private IPC namespace, with /dev/shm not mounted
+              - `"private"`: own private IPC namespace
+              - `"shareable"`: own private IPC namespace, with a possibility to share it with other containers
+              - `"container:<name|id>"`: join another (shareable) container's IPC namespace
+              - `"host"`: use the host system's IPC namespace
+
+              If not specified, daemon default is used, which can either be `"private"`
+              or `"shareable"`, depending on daemon version and configuration.
+          Cgroup:
+            type: "string"
+            description: "Cgroup to use for the container."
+          Links:
+            type: "array"
+            description: |
+              A list of links for the container in the form `container_name:alias`.
+            items:
+              type: "string"
+          OomScoreAdj:
+            type: "integer"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 500
+          PidMode:
+            type: "string"
+            description: |
+              Set the PID (Process) Namespace mode for the container. It can be
+              either:
+
+              - `"container:<name|id>"`: joins another container's PID namespace
+              - `"host"`: use the host's PID namespace inside the container
+          Privileged:
+            type: "boolean"
+            description: |-
+              Gives the container full access to the host.
+          PublishAllPorts:
+            type: "boolean"
+            description: |
+              Allocates an ephemeral host port for all of a container's
+              exposed ports.
+
+              Ports are de-allocated when the container stops and allocated when
+              the container starts. The allocated port might be changed when
+              restarting the container.
+
+              The port is selected from the ephemeral port range that depends on
+              the kernel. For example, on Linux the range is defined by
+              `/proc/sys/net/ipv4/ip_local_port_range`.
+          ReadonlyRootfs:
+            type: "boolean"
+            description: "Mount the container's root filesystem as read only."
+          SecurityOpt:
+            type: "array"
+            description: |
+              A list of string values to customize labels for MLS systems, such
+              as SELinux.
+            items:
+              type: "string"
+          StorageOpt:
+            type: "object"
+            description: |
+              Storage driver options for this container, in the form `{"size": "120G"}`.
+            additionalProperties:
+              type: "string"
+          Tmpfs:
+            type: "object"
+            description: |
+              A map of container directories which should be replaced by tmpfs
+              mounts, and their corresponding mount options. For example:
+
+              ```
+              { "/run": "rw,noexec,nosuid,size=65536k" }
+              ```
+            additionalProperties:
+              type: "string"
+          UTSMode:
+            type: "string"
+            description: "UTS namespace to use for the container."
+          UsernsMode:
+            type: "string"
+            description: |
+              Sets the usernamespace mode for the container when usernamespace
+              remapping option is enabled.
+          ShmSize:
+            type: "integer"
+            format: "int64"
+            description: |
+              Size of `/dev/shm` in bytes. If omitted, the system uses 64MB.
+            minimum: 0
+          Sysctls:
+            type: "object"
+            x-nullable: true
+            description: |-
+              A list of kernel parameters (sysctls) to set in the container.
+
+              This field is omitted if not set.
+            additionalProperties:
+              type: "string"
+            example:
+              "net.ipv4.ip_forward": "1"
+          Runtime:
+            type: "string"
+            x-nullable: true
+            description: |-
+              Runtime to use with this container.
+          # Applicable to Windows
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the container. (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          MaskedPaths:
+            type: "array"
+            description: |
+              The list of paths to be masked inside the container (this overrides
+              the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/asound"
+              - "/proc/acpi"
+              - "/proc/kcore"
+              - "/proc/keys"
+              - "/proc/latency_stats"
+              - "/proc/timer_list"
+              - "/proc/timer_stats"
+              - "/proc/sched_debug"
+              - "/proc/scsi"
+              - "/sys/firmware"
+              - "/sys/devices/virtual/powercap"
+          ReadonlyPaths:
+            type: "array"
+            description: |
+              The list of paths to be set as read-only inside the container
+              (this overrides the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/bus"
+              - "/proc/fs"
+              - "/proc/irq"
+              - "/proc/sys"
+              - "/proc/sysrq-trigger"
+
+  ContainerConfig:
+    description: |
+      Configuration for a container that is portable between hosts.
+    type: "object"
+    properties:
+      Hostname:
+        description: |
+          The hostname to use for the container, as a valid RFC 1123 hostname.
+        type: "string"
+        example: "439f4e91bd1d"
+      Domainname:
+        description: |
+          The domain name to use for the container.
+        type: "string"
+      User:
+        description: |-
+          Commands run as this user inside the container. If omitted, commands
+          run as the user specified in the image the container was started from.
+
+          Can be either user-name or UID, and optional group-name or GID,
+          separated by a colon (`<user-name|UID>[<:group-name|GID>]`).
+        type: "string"
+        example: "123:456"
+      AttachStdin:
+        description: "Whether to attach to `stdin`."
+        type: "boolean"
+        default: false
+      AttachStdout:
+        description: "Whether to attach to `stdout`."
+        type: "boolean"
+        default: true
+      AttachStderr:
+        description: "Whether to attach to `stderr`."
+        type: "boolean"
+        default: true
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Tty:
+        description: |
+          Attach standard streams to a TTY, including `stdin` if it is not closed.
+        type: "boolean"
+        default: false
+      OpenStdin:
+        description: "Open `stdin`"
+        type: "boolean"
+        default: false
+      StdinOnce:
+        description: "Close `stdin` after one attached client disconnects"
+        type: "boolean"
+        default: false
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Image:
+        description: |
+          The name (or reference) of the image to use when creating the container,
+          or which was used when the container was created.
+        type: "string"
+        example: "example-image:1.0"
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      NetworkDisabled:
+        description: "Disable networking for the container."
+        type: "boolean"
+        x-nullable: true
+      MacAddress:
+        description: |
+          MAC address of the container.
+
+          Deprecated: this field is deprecated in API v1.44 and up. Use EndpointSettings.MacAddress instead.
+        type: "string"
+        x-nullable: true
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      StopTimeout:
+        description: "Timeout to stop a container in seconds."
+        type: "integer"
+        default: 10
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  ImageConfig:
+    description: |
+      Configuration of the image. These fields are used as defaults
+      when starting a container from the image.
+    type: "object"
+    properties:
+      User:
+        description: "The user that commands are run as inside the container."
+        type: "string"
+        example: "web:web"
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example:
+          "/app/data": {}
+          "/app/config": {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  NetworkingConfig:
+    description: |
+      NetworkingConfig represents the container's networking configuration for
+      each of its interfaces.
+      It is used for the networking configs specified in the `docker create`
+      and `docker network connect` commands.
+    type: "object"
+    properties:
+      EndpointsConfig:
+        description: |
+          A mapping of network name to endpoint configuration for that network.
+          The endpoint configuration can be left empty to connect to that
+          network with no particular endpoint configuration.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+    example:
+      # putting an example here, instead of using the example values from
+      # /definitions/EndpointSettings, because EndpointSettings contains
+      # operational data returned when inspecting a container that we don't
+      # accept here.
+      EndpointsConfig:
+        isolated_nw:
+          IPAMConfig:
+            IPv4Address: "172.20.30.33"
+            IPv6Address: "2001:db8:abcd::3033"
+            LinkLocalIPs:
+              - "169.254.34.68"
+              - "fe80::3468"
+          MacAddress: "02:42:ac:12:05:02"
+          Links:
+            - "container_1"
+            - "container_2"
+          Aliases:
+            - "server_x"
+            - "server_y"
+        database_nw: {}
+
+  NetworkSettings:
+    description: "NetworkSettings exposes the network settings in the API"
+    type: "object"
+    properties:
+      Bridge:
+        description: |
+          Name of the default bridge interface when dockerd's --bridge flag is set.
+        type: "string"
+        example: "docker0"
+      SandboxID:
+        description: SandboxID uniquely represents a container's network stack.
+        type: "string"
+        example: "9d12daf2c33f5959c8bf90aa513e4f65b561738661003029ec84830cd503a0c3"
+      HairpinMode:
+        description: |
+          Indicates if hairpin NAT should be enabled on the virtual interface.
+
+          Deprecated: This field is never set and will be removed in a future release.
+        type: "boolean"
+        example: false
+      LinkLocalIPv6Address:
+        description: |
+          IPv6 unicast address using the link-local prefix.
+
+          Deprecated: This field is never set and will be removed in a future release.
+        type: "string"
+        example: ""
+      LinkLocalIPv6PrefixLen:
+        description: |
+          Prefix length of the IPv6 unicast address.
+
+          Deprecated: This field is never set and will be removed in a future release.
+        type: "integer"
+        example: ""
+      Ports:
+        $ref: "#/definitions/PortMap"
+      SandboxKey:
+        description: SandboxKey is the full path of the netns handle
+        type: "string"
+        example: "/var/run/docker/netns/8ab54b426c38"
+
+      SecondaryIPAddresses:
+        description: "Deprecated: This field is never set and will be removed in a future release."
+        type: "array"
+        items:
+          $ref: "#/definitions/Address"
+        x-nullable: true
+
+      SecondaryIPv6Addresses:
+        description: "Deprecated: This field is never set and will be removed in a future release."
+        type: "array"
+        items:
+          $ref: "#/definitions/Address"
+        x-nullable: true
+
+      # TODO properties below are part of DefaultNetworkSettings, which is
+      # marked as deprecated since Docker 1.9 and to be removed in Docker v17.12
+      EndpointID:
+        description: |
+          EndpointID uniquely represents a service endpoint in a Sandbox.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "b88f5b905aabf2893f3cbc4ee42d1ea7980bbc0a92e2c8922b1e1795298afb0b"
+      Gateway:
+        description: |
+          Gateway address for the default "bridge" network.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "172.17.0.1"
+      GlobalIPv6Address:
+        description: |
+          Global IPv6 address for the default "bridge" network.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "2001:db8::5689"
+      GlobalIPv6PrefixLen:
+        description: |
+          Mask length of the global IPv6 address.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "integer"
+        example: 64
+      IPAddress:
+        description: |
+          IPv4 address for the default "bridge" network.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "172.17.0.4"
+      IPPrefixLen:
+        description: |
+          Mask length of the IPv4 address.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "integer"
+        example: 16
+      IPv6Gateway:
+        description: |
+          IPv6 gateway address for this network.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "2001:db8:2::100"
+      MacAddress:
+        description: |
+          MAC address for the container on the default "bridge" network.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "02:42:ac:11:00:04"
+      Networks:
+        description: |
+          Information about all networks that the container is connected to.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+
+  Address:
+    description: Address represents an IPv4 or IPv6 IP address.
+    type: "object"
+    properties:
+      Addr:
+        description: IP address.
+        type: "string"
+      PrefixLen:
+        description: Mask length of the IP address.
+        type: "integer"
+
+  PortMap:
+    description: |
+      PortMap describes the mapping of container ports to host ports, using the
+      container's port-number and protocol as key in the format `<port>/<protocol>`,
+      for example, `80/udp`.
+
+      If a container's port is mapped for multiple protocols, separate entries
+      are added to the mapping table.
+    type: "object"
+    additionalProperties:
+      type: "array"
+      x-nullable: true
+      items:
+        $ref: "#/definitions/PortBinding"
+    example:
+      "443/tcp":
+        - HostIp: "127.0.0.1"
+          HostPort: "4443"
+      "80/tcp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+        - HostIp: "0.0.0.0"
+          HostPort: "8080"
+      "80/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+      "53/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "53"
+      "2377/tcp": null
+
+  PortBinding:
+    description: |
+      PortBinding represents a binding between a host IP address and a host
+      port.
+    type: "object"
+    properties:
+      HostIp:
+        description: "Host IP address that the container's port is mapped to."
+        type: "string"
+        example: "127.0.0.1"
+      HostPort:
+        description: "Host port number that the container's port is mapped to."
+        type: "string"
+        example: "4443"
+
+  DriverData:
+    description: |
+      Information about the storage driver used to store the container's and
+      image's filesystem.
+    type: "object"
+    required: [Name, Data]
+    properties:
+      Name:
+        description: "Name of the storage driver."
+        type: "string"
+        x-nullable: false
+        example: "overlay2"
+      Data:
+        description: |
+          Low-level storage metadata, provided as key/value pairs.
+
+          This information is driver-specific, and depends on the storage-driver
+          in use, and should be used for informational purposes only.
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example: {
+          "MergedDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/merged",
+          "UpperDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/diff",
+          "WorkDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/work"
+        }
+
+  FilesystemChange:
+    description: |
+      Change in the container's filesystem.
+    type: "object"
+    required: [Path, Kind]
+    properties:
+      Path:
+        description: |
+          Path to file or directory that has changed.
+        type: "string"
+        x-nullable: false
+      Kind:
+        $ref: "#/definitions/ChangeType"
+
+  ChangeType:
+    description: |
+      Kind of change
+
+      Can be one of:
+
+      - `0`: Modified ("C")
+      - `1`: Added ("A")
+      - `2`: Deleted ("D")
+    type: "integer"
+    format: "uint8"
+    enum: [0, 1, 2]
+    x-nullable: false
+
+  ImageInspect:
+    description: |
+      Information about an image in the local image cache.
+    type: "object"
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+      Manifests:
+        description: |
+            Manifests is a list of image manifests available in this image. It
+            provides a more detailed view of the platform-specific image manifests or
+            other image-attached data like build attestations.
+
+            Only available if the daemon provides a multi-platform image store
+            and the `manifests` option is set in the inspect request.
+
+            WARNING: This is experimental and may change at any time without any backward
+            compatibility.
+        type: "array"
+        x-nullable: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Parent:
+        description: |
+          ID of the parent image.
+
+          Depending on how the image was created, this field may be empty and
+          is only set for images that were built/created locally. This field
+          is empty if the image was pulled from an image registry.
+        type: "string"
+        x-nullable: false
+        example: ""
+      Comment:
+        description: |
+          Optional message that was set when committing or importing the image.
+        type: "string"
+        x-nullable: false
+        example: ""
+      Created:
+        description: |
+          Date and time at which the image was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+          This information is only available if present in the image,
+          and omitted otherwise.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2022-02-04T21:20:12.497794809Z"
+      DockerVersion:
+        description: |
+          The version of Docker that was used to build the image.
+
+          Depending on how the image was created, this field may be empty.
+        type: "string"
+        x-nullable: false
+        example: "27.0.1"
+      Author:
+        description: |
+          Name of the author that was specified when committing the image, or as
+          specified through MAINTAINER (deprecated) in the Dockerfile.
+        type: "string"
+        x-nullable: false
+        example: ""
+      Config:
+        $ref: "#/definitions/ImageConfig"
+      Architecture:
+        description: |
+          Hardware CPU architecture that the image runs on.
+        type: "string"
+        x-nullable: false
+        example: "arm"
+      Variant:
+        description: |
+          CPU architecture variant (presently ARM-only).
+        type: "string"
+        x-nullable: true
+        example: "v7"
+      Os:
+        description: |
+          Operating System the image is built to run on.
+        type: "string"
+        x-nullable: false
+        example: "linux"
+      OsVersion:
+        description: |
+          Operating System version the image is built to run on (especially
+          for Windows).
+        type: "string"
+        example: ""
+        x-nullable: true
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      GraphDriver:
+        $ref: "#/definitions/DriverData"
+      RootFS:
+        description: |
+          Information about the image's RootFS, including the layer IDs.
+        type: "object"
+        required: [Type]
+        properties:
+          Type:
+            type: "string"
+            x-nullable: false
+            example: "layers"
+          Layers:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "sha256:1834950e52ce4d5a88a1bbd131c537f4d0e56d10ff0dd69e66be3b7dfa9df7e6"
+              - "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"
+      Metadata:
+        description: |
+          Additional metadata of the image in the local cache. This information
+          is local to the daemon, and not part of the image itself.
+        type: "object"
+        properties:
+          LastTagTime:
+            description: |
+              Date and time at which the image was last tagged in
+              [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+              This information is only available if the image was tagged locally,
+              and omitted otherwise.
+            type: "string"
+            format: "dateTime"
+            example: "2022-02-28T14:40:02.623929178Z"
+            x-nullable: true
+
+  ImageSummary:
+    type: "object"
+    x-go-name: "Summary"
+    required:
+      - Id
+      - ParentId
+      - RepoTags
+      - RepoDigests
+      - Created
+      - Size
+      - SharedSize
+      - Labels
+      - Containers
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      ParentId:
+        description: |
+          ID of the parent image.
+
+          Depending on how the image was created, this field may be empty and
+          is only set for images that were built/created locally. This field
+          is empty if the image was pulled from an image registry.
+        type: "string"
+        x-nullable: false
+        example: ""
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Created:
+        description: |
+          Date and time at which the image was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        x-nullable: false
+        example: "1644009612"
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 172064416
+      SharedSize:
+        description: |
+          Total size of image layers that are shared between this image and other
+          images.
+
+          This size is not calculated by default. `-1` indicates that the value
+          has not been set / calculated.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Containers:
+        description: |
+          Number of containers using this image. Includes both stopped and running
+          containers.
+
+          This size is not calculated by default, and depends on which API endpoint
+          is used. `-1` indicates that the value has not been set / calculated.
+        x-nullable: false
+        type: "integer"
+        example: 2
+      Manifests:
+        description: |
+          Manifests is a list of manifests available in this image.
+          It provides a more detailed view of the platform-specific image manifests
+          or other image-attached data like build attestations.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        type: "array"
+        x-nullable: false
+        x-omitempty: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+
+  AuthConfig:
+    type: "object"
+    properties:
+      username:
+        type: "string"
+      password:
+        type: "string"
+      email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
+        type: "string"
+      serveraddress:
+        type: "string"
+    example:
+      username: "hannibal"
+      password: "xxxx"
+      serveraddress: "https://index.docker.io/v1/"
+
+  ProcessConfig:
+    type: "object"
+    properties:
+      privileged:
+        type: "boolean"
+      user:
+        type: "string"
+      tty:
+        type: "boolean"
+      entrypoint:
+        type: "string"
+      arguments:
+        type: "array"
+        items:
+          type: "string"
+
+  Volume:
+    type: "object"
+    required: [Name, Driver, Mountpoint, Labels, Scope, Options]
+    properties:
+      Name:
+        type: "string"
+        description: "Name of the volume."
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        type: "string"
+        description: "Name of the volume driver used by the volume."
+        x-nullable: false
+        example: "custom"
+      Mountpoint:
+        type: "string"
+        description: "Mount path of the volume on the host."
+        x-nullable: false
+        example: "/var/lib/docker/volumes/tardis"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        description: "Date/Time the volume was created."
+        example: "2016-06-07T20:31:11.853781916Z"
+      Status:
+        type: "object"
+        description: |
+          Low-level details about the volume, provided by the volume driver.
+          Details are returned as a map with key/value pairs:
+          `{"key":"value","key2":"value2"}`.
+
+          The `Status` field is optional, and is omitted if the volume driver
+          does not support this feature.
+        additionalProperties:
+          type: "object"
+        example:
+          hello: "world"
+      Labels:
+        type: "object"
+        description: "User-defined key/value metadata."
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Scope:
+        type: "string"
+        description: |
+          The level at which the volume exists. Either `global` for cluster-wide,
+          or `local` for machine level.
+        default: "local"
+        x-nullable: false
+        enum: ["local", "global"]
+        example: "local"
+      ClusterVolume:
+        $ref: "#/definitions/ClusterVolume"
+      Options:
+        type: "object"
+        description: |
+          The driver specific options used when creating the volume.
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      UsageData:
+        type: "object"
+        x-nullable: true
+        x-go-name: "UsageData"
+        required: [Size, RefCount]
+        description: |
+          Usage details about the volume. This information is used by the
+          `GET /system/df` endpoint, and omitted in other endpoints.
+        properties:
+          Size:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              Amount of disk space used by the volume (in bytes). This information
+              is only available for volumes created with the `"local"` volume
+              driver. For volumes created with other volume drivers, this field
+              is set to `-1` ("not available")
+            x-nullable: false
+          RefCount:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              The number of containers referencing this volume. This field
+              is set to `-1` if the reference-count is not available.
+            x-nullable: false
+
+  VolumeCreateOptions:
+    description: "Volume configuration"
+    type: "object"
+    title: "VolumeConfig"
+    x-go-name: "CreateOptions"
+    properties:
+      Name:
+        description: |
+          The new volume's name. If not specified, Docker generates a name.
+        type: "string"
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        description: "Name of the volume driver to use."
+        type: "string"
+        default: "local"
+        x-nullable: false
+        example: "custom"
+      DriverOpts:
+        description: |
+          A mapping of driver options and values. These options are
+          passed directly to the driver and are driver specific.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      ClusterVolumeSpec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+
+  VolumeListResponse:
+    type: "object"
+    title: "VolumeListResponse"
+    x-go-name: "ListResponse"
+    description: "Volume list response"
+    properties:
+      Volumes:
+        type: "array"
+        description: "List of volumes"
+        items:
+          $ref: "#/definitions/Volume"
+      Warnings:
+        type: "array"
+        description: |
+          Warnings that occurred when fetching the list of volumes.
+        items:
+          type: "string"
+        example: []
+
+  Network:
+    type: "object"
+    properties:
+      Name:
+        description: |
+          Name of the network.
+        type: "string"
+        example: "my_network"
+      Id:
+        description: |
+          ID that uniquely identifies a network on a single machine.
+        type: "string"
+        example: "7d86d31b1478e7cca9ebed7e73aa0fdeec46c5ca29497431d3007d2d9e15ed99"
+      Created:
+        description: |
+          Date and time at which the network was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-10-19T04:33:30.360899459Z"
+      Scope:
+        description: |
+          The level at which the network exists (e.g. `swarm` for cluster-wide
+          or `local` for machine level)
+        type: "string"
+        example: "local"
+      Driver:
+        description: |
+          The name of the driver used to create the network (e.g. `bridge`,
+          `overlay`).
+        type: "string"
+        example: "overlay"
+      EnableIPv4:
+        description: |
+          Whether the network was created with IPv4 enabled.
+        type: "boolean"
+        example: true
+      EnableIPv6:
+        description: |
+          Whether the network was created with IPv6 enabled.
+        type: "boolean"
+        example: false
+      IPAM:
+        $ref: "#/definitions/IPAM"
+      Internal:
+        description: |
+          Whether the network is created to only allow internal networking
+          connectivity.
+        type: "boolean"
+        default: false
+        example: false
+      Attachable:
+        description: |
+          Whether a global / swarm scope network is manually attachable by regular
+          containers from workers in swarm mode.
+        type: "boolean"
+        default: false
+        example: false
+      Ingress:
+        description: |
+          Whether the network is providing the routing-mesh for the swarm cluster.
+        type: "boolean"
+        default: false
+        example: false
+      ConfigFrom:
+        $ref: "#/definitions/ConfigReference"
+      ConfigOnly:
+        description: |
+          Whether the network is a config-only network. Config-only networks are
+          placeholder networks for network configurations to be used by other
+          networks. Config-only networks cannot be used directly to run containers
+          or services.
+        type: "boolean"
+        default: false
+      Containers:
+        description: |
+          Contains endpoints attached to the network.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/NetworkContainer"
+        example:
+          19a4d5d687db25203351ed79d478946f861258f018fe384f229f2efa4b23513c:
+            Name: "test"
+            EndpointID: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+            MacAddress: "02:42:ac:13:00:02"
+            IPv4Address: "172.19.0.2/16"
+            IPv6Address: ""
+      Options:
+        description: |
+          Network-specific options uses when creating the network.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.docker.network.bridge.default_bridge: "true"
+          com.docker.network.bridge.enable_icc: "true"
+          com.docker.network.bridge.enable_ip_masquerade: "true"
+          com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+          com.docker.network.bridge.name: "docker0"
+          com.docker.network.driver.mtu: "1500"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Peers:
+        description: |
+          List of peer nodes for an overlay network. This field is only present
+          for overlay networks, and omitted for other network types.
+        type: "array"
+        items:
+          $ref: "#/definitions/PeerInfo"
+        x-nullable: true
+      # TODO: Add Services (only present when "verbose" is set).
+
+  ConfigReference:
+    description: |
+      The config-only network source to provide the configuration for
+      this network.
+    type: "object"
+    properties:
+      Network:
+        description: |
+          The name of the config-only network that provides the network's
+          configuration. The specified network must be an existing config-only
+          network. Only network names are allowed, not network IDs.
+        type: "string"
+        example: "config_only_network_01"
+
+  IPAM:
+    type: "object"
+    properties:
+      Driver:
+        description: "Name of the IPAM driver to use."
+        type: "string"
+        default: "default"
+        example: "default"
+      Config:
+        description: |
+          List of IPAM configuration options, specified as a map:
+
+          ```
+          {"Subnet": <CIDR>, "IPRange": <CIDR>, "Gateway": <IP address>, "AuxAddress": <device_name:IP address>}
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/IPAMConfig"
+      Options:
+        description: "Driver-specific options, specified as a map."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+
+  IPAMConfig:
+    type: "object"
+    properties:
+      Subnet:
+        type: "string"
+        example: "172.20.0.0/16"
+      IPRange:
+        type: "string"
+        example: "172.20.10.0/24"
+      Gateway:
+        type: "string"
+        example: "172.20.10.11"
+      AuxiliaryAddresses:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  NetworkContainer:
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        example: "container_1"
+      EndpointID:
+        type: "string"
+        example: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+      MacAddress:
+        type: "string"
+        example: "02:42:ac:13:00:02"
+      IPv4Address:
+        type: "string"
+        example: "172.19.0.2/16"
+      IPv6Address:
+        type: "string"
+        example: ""
+
+  PeerInfo:
+    description: |
+      PeerInfo represents one peer of an overlay network.
+    type: "object"
+    properties:
+      Name:
+        description:
+          ID of the peer-node in the Swarm cluster.
+        type: "string"
+        example: "6869d7c1732b"
+      IP:
+        description:
+          IP-address of the peer-node in the Swarm cluster.
+        type: "string"
+        example: "10.133.77.91"
+
+  NetworkCreateResponse:
+    description: "OK response to NetworkCreate operation"
+    type: "object"
+    title: "NetworkCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warning]
+    properties:
+      Id:
+        description: "The ID of the created network."
+        type: "string"
+        x-nullable: false
+        example: "b5c4fc71e8022147cd25de22b22173de4e3b170134117172eb595cb91b4e7e5d"
+      Warning:
+        description: "Warnings encountered when creating the container"
+        type: "string"
+        x-nullable: false
+        example: ""
+
+  BuildInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      stream:
+        type: "string"
+      error:
+        type: "string"
+        x-nullable: true
+        description: |-
+          errors encountered during the operation.
+
+
+          > **Deprecated**: This field is deprecated since API v1.4, and will be omitted in a future API version. Use the information in errorDetail instead.
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progress:
+        type: "string"
+        x-nullable: true
+        description: |-
+          Progress is a pre-formatted presentation of progressDetail.
+
+
+          > **Deprecated**: This field is deprecated since API v1.8, and will be omitted in a future API version. Use the information in progressDetail instead.
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+      aux:
+        $ref: "#/definitions/ImageID"
+
+  BuildCache:
+    type: "object"
+    description: |
+      BuildCache contains information about a build cache record.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          Unique ID of the build cache record.
+        example: "ndlpt0hhvkqcdfkputsk4cq9c"
+      Parents:
+        description: |
+          List of parent build cache record IDs.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example: ["hw53o5aio51xtltp5xjp8v7fx"]
+      Type:
+        type: "string"
+        description: |
+          Cache record type.
+        example: "regular"
+        # see https://github.com/moby/buildkit/blob/fce4a32258dc9d9664f71a4831d5de10f0670677/client/diskusage.go#L75-L84
+        enum:
+          - "internal"
+          - "frontend"
+          - "source.local"
+          - "source.git.checkout"
+          - "exec.cachemount"
+          - "regular"
+      Description:
+        type: "string"
+        description: |
+          Description of the build-step that produced the build cache.
+        example: "mount / from exec /bin/sh -c echo 'Binary::apt::APT::Keep-Downloaded-Packages \"true\";' > /etc/apt/apt.conf.d/keep-cache"
+      InUse:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is in use.
+        example: false
+      Shared:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is shared.
+        example: true
+      Size:
+        description: |
+          Amount of disk space used by the build cache (in bytes).
+        type: "integer"
+        example: 51
+      CreatedAt:
+        description: |
+          Date and time at which the build cache was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      LastUsedAt:
+        description: |
+          Date and time at which the build cache was last used in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2017-08-09T07:09:37.632105588Z"
+      UsageCount:
+        type: "integer"
+        example: 26
+
+  ImageID:
+    type: "object"
+    description: "Image ID or Digest"
+    properties:
+      ID:
+        type: "string"
+    example:
+      ID: "sha256:85f05633ddc1c50679be2b16a0479ab6f7637f8884e0cfe0f4d20e1ebb3d6e7c"
+
+  CreateImageInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      error:
+        type: "string"
+        x-nullable: true
+        description: |-
+          errors encountered during the operation.
+
+
+          > **Deprecated**: This field is deprecated since API v1.4, and will be omitted in a future API version. Use the information in errorDetail instead.
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progress:
+        type: "string"
+        x-nullable: true
+        description: |-
+          Progress is a pre-formatted presentation of progressDetail.
+
+
+          > **Deprecated**: This field is deprecated since API v1.8, and will be omitted in a future API version. Use the information in progressDetail instead.
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  PushImageInfo:
+    type: "object"
+    properties:
+      error:
+        type: "string"
+        x-nullable: true
+        description: |-
+          errors encountered during the operation.
+
+
+          > **Deprecated**: This field is deprecated since API v1.4, and will be omitted in a future API version. Use the information in errorDetail instead.
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progress:
+        type: "string"
+        x-nullable: true
+        description: |-
+          Progress is a pre-formatted presentation of progressDetail.
+
+
+          > **Deprecated**: This field is deprecated since API v1.8, and will be omitted in a future API version. Use the information in progressDetail instead.
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  DeviceInfo:
+    type: "object"
+    description: |
+      DeviceInfo represents a device that can be used by a container.
+    properties:
+      Source:
+        type: "string"
+        example: "cdi"
+        description: |
+          The origin device driver.
+      ID:
+        type: "string"
+        example: "vendor.com/gpu=0"
+        description: |
+          The unique identifier for the device within its source driver.
+          For CDI devices, this would be an FQDN like "vendor.com/gpu=0".
+
+  ErrorDetail:
+    type: "object"
+    properties:
+      code:
+        type: "integer"
+      message:
+        type: "string"
+
+  ProgressDetail:
+    type: "object"
+    properties:
+      current:
+        type: "integer"
+      total:
+        type: "integer"
+
+  ErrorResponse:
+    description: "Represents an error."
+    type: "object"
+    required: ["message"]
+    properties:
+      message:
+        description: "The error message."
+        type: "string"
+        x-nullable: false
+    example:
+      message: "Something went wrong."
+
+  IDResponse:
+    description: "Response to an API call that returns just an Id"
+    type: "object"
+    x-go-name: "IDResponse"
+    required: ["Id"]
+    properties:
+      Id:
+        description: "The id of the newly created object."
+        type: "string"
+        x-nullable: false
+
+  EndpointSettings:
+    description: "Configuration for a network endpoint."
+    type: "object"
+    properties:
+      # Configurations
+      IPAMConfig:
+        $ref: "#/definitions/EndpointIPAMConfig"
+      Links:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "container_1"
+          - "container_2"
+      MacAddress:
+        description: |
+          MAC address for the endpoint on this network. The network driver might ignore this parameter.
+        type: "string"
+        example: "02:42:ac:11:00:04"
+      Aliases:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "server_x"
+          - "server_y"
+      DriverOpts:
+        description: |
+          DriverOpts is a mapping of driver options and values. These options
+          are passed directly to the driver and are driver specific.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      GwPriority:
+        description: |
+          This property determines which endpoint will provide the default
+          gateway for a container. The endpoint with the highest priority will
+          be used. If multiple endpoints have the same priority, endpoints are
+          lexicographically sorted based on their network name, and the one
+          that sorts first is picked.
+        type: "integer"
+        format: "int64"
+        example:
+          - 10
+
+      # Operational data
+      NetworkID:
+        description: |
+          Unique ID of the network.
+        type: "string"
+        example: "08754567f1f40222263eab4102e1c733ae697e8e354aa9cd6e18d7402835292a"
+      EndpointID:
+        description: |
+          Unique ID for the service endpoint in a Sandbox.
+        type: "string"
+        example: "b88f5b905aabf2893f3cbc4ee42d1ea7980bbc0a92e2c8922b1e1795298afb0b"
+      Gateway:
+        description: |
+          Gateway address for this network.
+        type: "string"
+        example: "172.17.0.1"
+      IPAddress:
+        description: |
+          IPv4 address.
+        type: "string"
+        example: "172.17.0.4"
+      IPPrefixLen:
+        description: |
+          Mask length of the IPv4 address.
+        type: "integer"
+        example: 16
+      IPv6Gateway:
+        description: |
+          IPv6 gateway address.
+        type: "string"
+        example: "2001:db8:2::100"
+      GlobalIPv6Address:
+        description: |
+          Global IPv6 address.
+        type: "string"
+        example: "2001:db8::5689"
+      GlobalIPv6PrefixLen:
+        description: |
+          Mask length of the global IPv6 address.
+        type: "integer"
+        format: "int64"
+        example: 64
+      DNSNames:
+        description: |
+          List of all DNS names an endpoint has on a specific network. This
+          list is based on the container name, network aliases, container short
+          ID, and hostname.
+
+          These DNS names are non-fully qualified but can contain several dots.
+          You can get fully qualified DNS names by appending `.<network-name>`.
+          For instance, if container name is `my.ctr` and the network is named
+          `testnet`, `DNSNames` will contain `my.ctr` and the FQDN will be
+          `my.ctr.testnet`.
+        type: array
+        items:
+          type: string
+        example: ["foobar", "server_x", "server_y", "my.ctr"]
+
+  EndpointIPAMConfig:
+    description: |
+      EndpointIPAMConfig represents an endpoint's IPAM configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      IPv4Address:
+        type: "string"
+        example: "172.20.30.33"
+      IPv6Address:
+        type: "string"
+        example: "2001:db8:abcd::3033"
+      LinkLocalIPs:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "169.254.34.68"
+          - "fe80::3468"
+
+  PluginMount:
+    type: "object"
+    x-nullable: false
+    required: [Name, Description, Settable, Source, Destination, Type, Options]
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "some-mount"
+      Description:
+        type: "string"
+        x-nullable: false
+        example: "This is a mount that's used by the plugin."
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Source:
+        type: "string"
+        example: "/var/lib/docker/plugins/"
+      Destination:
+        type: "string"
+        x-nullable: false
+        example: "/mnt/state"
+      Type:
+        type: "string"
+        x-nullable: false
+        example: "bind"
+      Options:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "rbind"
+          - "rw"
+
+  PluginDevice:
+    type: "object"
+    required: [Name, Description, Settable, Path]
+    x-nullable: false
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+      Description:
+        type: "string"
+        x-nullable: false
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Path:
+        type: "string"
+        example: "/dev/fuse"
+
+  PluginEnv:
+    type: "object"
+    x-nullable: false
+    required: [Name, Description, Settable, Value]
+    properties:
+      Name:
+        x-nullable: false
+        type: "string"
+      Description:
+        x-nullable: false
+        type: "string"
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Value:
+        type: "string"
+
+  PluginInterfaceType:
+    type: "object"
+    x-nullable: false
+    required: [Prefix, Capability, Version]
+    properties:
+      Prefix:
+        type: "string"
+        x-nullable: false
+      Capability:
+        type: "string"
+        x-nullable: false
+      Version:
+        type: "string"
+        x-nullable: false
+
+  PluginPrivilege:
+    description: |
+      Describes a permission the user has to accept upon installing
+      the plugin.
+    type: "object"
+    x-go-name: "PluginPrivilege"
+    properties:
+      Name:
+        type: "string"
+        example: "network"
+      Description:
+        type: "string"
+      Value:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "host"
+
+  Plugin:
+    description: "A plugin for the Engine API"
+    type: "object"
+    required: [Settings, Enabled, Config, Name]
+    properties:
+      Id:
+        type: "string"
+        example: "5724e2c8652da337ab2eedd19fc6fc0ec908e4bd907c7421bf6a8dfc70c4c078"
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "tiborvass/sample-volume-plugin"
+      Enabled:
+        description:
+          True if the plugin is running. False if the plugin is not running,
+          only installed.
+        type: "boolean"
+        x-nullable: false
+        example: true
+      Settings:
+        description: "Settings that can be modified by users."
+        type: "object"
+        x-nullable: false
+        required: [Args, Devices, Env, Mounts]
+        properties:
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "DEBUG=0"
+          Args:
+            type: "array"
+            items:
+              type: "string"
+          Devices:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginDevice"
+      PluginReference:
+        description: "plugin remote reference used to push/pull the plugin"
+        type: "string"
+        x-nullable: false
+        example: "localhost:5000/tiborvass/sample-volume-plugin:latest"
+      Config:
+        description: "The config of a plugin."
+        type: "object"
+        x-nullable: false
+        required:
+          - Description
+          - Documentation
+          - Interface
+          - Entrypoint
+          - WorkDir
+          - Network
+          - Linux
+          - PidHost
+          - PropagatedMount
+          - IpcHost
+          - Mounts
+          - Env
+          - Args
+        properties:
+          DockerVersion:
+            description: "Docker Version used to create the plugin"
+            type: "string"
+            x-nullable: false
+            example: "17.06.0-ce"
+          Description:
+            type: "string"
+            x-nullable: false
+            example: "A sample volume plugin for Docker"
+          Documentation:
+            type: "string"
+            x-nullable: false
+            example: "https://docs.docker.com/engine/extend/plugins/"
+          Interface:
+            description: "The interface between Docker and the plugin"
+            x-nullable: false
+            type: "object"
+            required: [Types, Socket]
+            properties:
+              Types:
+                type: "array"
+                items:
+                  $ref: "#/definitions/PluginInterfaceType"
+                example:
+                  - "docker.volumedriver/1.0"
+              Socket:
+                type: "string"
+                x-nullable: false
+                example: "plugins.sock"
+              ProtocolScheme:
+                type: "string"
+                example: "some.protocol/v1.0"
+                description: "Protocol to use for clients connecting to the plugin."
+                enum:
+                  - ""
+                  - "moby.plugins.http/v1"
+          Entrypoint:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "/usr/bin/sample-volume-plugin"
+              - "/data"
+          WorkDir:
+            type: "string"
+            x-nullable: false
+            example: "/bin/"
+          User:
+            type: "object"
+            x-nullable: false
+            properties:
+              UID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+              GID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+          Network:
+            type: "object"
+            x-nullable: false
+            required: [Type]
+            properties:
+              Type:
+                x-nullable: false
+                type: "string"
+                example: "host"
+          Linux:
+            type: "object"
+            x-nullable: false
+            required: [Capabilities, AllowAllDevices, Devices]
+            properties:
+              Capabilities:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "CAP_SYS_ADMIN"
+                  - "CAP_SYSLOG"
+              AllowAllDevices:
+                type: "boolean"
+                x-nullable: false
+                example: false
+              Devices:
+                type: "array"
+                items:
+                  $ref: "#/definitions/PluginDevice"
+          PropagatedMount:
+            type: "string"
+            x-nullable: false
+            example: "/mnt/volumes"
+          IpcHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          PidHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginEnv"
+            example:
+              - Name: "DEBUG"
+                Description: "If set, prints debug messages"
+                Settable: null
+                Value: "0"
+          Args:
+            type: "object"
+            x-nullable: false
+            required: [Name, Description, Settable, Value]
+            properties:
+              Name:
+                x-nullable: false
+                type: "string"
+                example: "args"
+              Description:
+                x-nullable: false
+                type: "string"
+                example: "command line arguments"
+              Settable:
+                type: "array"
+                items:
+                  type: "string"
+              Value:
+                type: "array"
+                items:
+                  type: "string"
+          rootfs:
+            type: "object"
+            properties:
+              type:
+                type: "string"
+                example: "layers"
+              diff_ids:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "sha256:675532206fbf3030b8458f88d6e26d4eb1577688a25efec97154c94e8b6b4887"
+                  - "sha256:e216a057b1cb1efc11f8a268f37ef62083e70b1b38323ba252e25ac88904a7e8"
+
+  ObjectVersion:
+    description: |
+      The version number of the object such as node, service, etc. This is needed
+      to avoid conflicting writes. The client must send the version number along
+      with the modified specification when updating these objects.
+
+      This approach ensures safe concurrency and determinism in that the change
+      on the object may not be applied if the version number has changed from the
+      last read. In other words, if two update requests specify the same base
+      version, only one of the requests can succeed. As a result, two separate
+      update requests that happen at the same time will not unintentionally
+      overwrite each other.
+    type: "object"
+    properties:
+      Index:
+        type: "integer"
+        format: "uint64"
+        example: 373531
+
+  NodeSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "Name for the node."
+        type: "string"
+        example: "my-node"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Role:
+        description: "Role of the node."
+        type: "string"
+        enum:
+          - "worker"
+          - "manager"
+        example: "manager"
+      Availability:
+        description: "Availability of the node."
+        type: "string"
+        enum:
+          - "active"
+          - "pause"
+          - "drain"
+        example: "active"
+    example:
+      Availability: "active"
+      Name: "node-name"
+      Role: "manager"
+      Labels:
+        foo: "bar"
+
+  Node:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "24ifsmvkjbyhk"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the node was added to the swarm in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the node was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/NodeSpec"
+      Description:
+        $ref: "#/definitions/NodeDescription"
+      Status:
+        $ref: "#/definitions/NodeStatus"
+      ManagerStatus:
+        $ref: "#/definitions/ManagerStatus"
+
+  NodeDescription:
+    description: |
+      NodeDescription encapsulates the properties of the Node as reported by the
+      agent.
+    type: "object"
+    properties:
+      Hostname:
+        type: "string"
+        example: "bf3067039e47"
+      Platform:
+        $ref: "#/definitions/Platform"
+      Resources:
+        $ref: "#/definitions/ResourceObject"
+      Engine:
+        $ref: "#/definitions/EngineDescription"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+
+  Platform:
+    description: |
+      Platform represents the platform (Arch/OS).
+    type: "object"
+    properties:
+      Architecture:
+        description: |
+          Architecture represents the hardware architecture (for example,
+          `x86_64`).
+        type: "string"
+        example: "x86_64"
+      OS:
+        description: |
+          OS represents the Operating System (for example, `linux` or `windows`).
+        type: "string"
+        example: "linux"
+
+  EngineDescription:
+    description: "EngineDescription provides information about an engine."
+    type: "object"
+    properties:
+      EngineVersion:
+        type: "string"
+        example: "17.06.0"
+      Labels:
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+      Plugins:
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Type:
+              type: "string"
+            Name:
+              type: "string"
+        example:
+          - Type: "Log"
+            Name: "awslogs"
+          - Type: "Log"
+            Name: "fluentd"
+          - Type: "Log"
+            Name: "gcplogs"
+          - Type: "Log"
+            Name: "gelf"
+          - Type: "Log"
+            Name: "journald"
+          - Type: "Log"
+            Name: "json-file"
+          - Type: "Log"
+            Name: "splunk"
+          - Type: "Log"
+            Name: "syslog"
+          - Type: "Network"
+            Name: "bridge"
+          - Type: "Network"
+            Name: "host"
+          - Type: "Network"
+            Name: "ipvlan"
+          - Type: "Network"
+            Name: "macvlan"
+          - Type: "Network"
+            Name: "null"
+          - Type: "Network"
+            Name: "overlay"
+          - Type: "Volume"
+            Name: "local"
+          - Type: "Volume"
+            Name: "localhost:5000/vieux/sshfs:latest"
+          - Type: "Volume"
+            Name: "vieux/sshfs:latest"
+
+  TLSInfo:
+    description: |
+      Information about the issuer of leaf TLS certificates and the trusted root
+      CA certificate.
+    type: "object"
+    properties:
+      TrustRoot:
+        description: |
+          The root CA certificate(s) that are used to validate leaf TLS
+          certificates.
+        type: "string"
+      CertIssuerSubject:
+        description:
+          The base64-url-safe-encoded raw subject bytes of the issuer.
+        type: "string"
+      CertIssuerPublicKey:
+        description: |
+          The base64-url-safe-encoded raw public key bytes of the issuer.
+        type: "string"
+    example:
+      TrustRoot: |
+        -----BEGIN CERTIFICATE-----
+        MIIBajCCARCgAwIBAgIUbYqrLSOSQHoxD8CwG6Bi2PJi9c8wCgYIKoZIzj0EAwIw
+        EzERMA8GA1UEAxMIc3dhcm0tY2EwHhcNMTcwNDI0MjE0MzAwWhcNMzcwNDE5MjE0
+        MzAwWjATMREwDwYDVQQDEwhzd2FybS1jYTBZMBMGByqGSM49AgEGCCqGSM49AwEH
+        A0IABJk/VyMPYdaqDXJb/VXh5n/1Yuv7iNrxV3Qb3l06XD46seovcDWs3IZNV1lf
+        3Skyr0ofcchipoiHkXBODojJydSjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB
+        Af8EBTADAQH/MB0GA1UdDgQWBBRUXxuRcnFjDfR/RIAUQab8ZV/n4jAKBggqhkjO
+        PQQDAgNIADBFAiAy+JTe6Uc3KyLCMiqGl2GyWGQqQDEcO3/YG36x7om65AIhAJvz
+        pxv6zFeVEkAEEkqIYi0omA9+CjanB/6Bz4n1uw8H
+        -----END CERTIFICATE-----
+      CertIssuerSubject: "MBMxETAPBgNVBAMTCHN3YXJtLWNh"
+      CertIssuerPublicKey: "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmT9XIw9h1qoNclv9VeHmf/Vi6/uI2vFXdBveXTpcPjqx6i9wNazchk1XWV/dKTKvSh9xyGKmiIeRcE4OiMnJ1A=="
+
+  NodeStatus:
+    description: |
+      NodeStatus represents the status of a node.
+
+      It provides the current status of the node, as seen by the manager.
+    type: "object"
+    properties:
+      State:
+        $ref: "#/definitions/NodeState"
+      Message:
+        type: "string"
+        example: ""
+      Addr:
+        description: "IP address of the node."
+        type: "string"
+        example: "172.17.0.2"
+
+  NodeState:
+    description: "NodeState represents the state of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "down"
+      - "ready"
+      - "disconnected"
+    example: "ready"
+
+  ManagerStatus:
+    description: |
+      ManagerStatus represents the status of a manager.
+
+      It provides the current status of a node's manager component, if the node
+      is a manager.
+    x-nullable: true
+    type: "object"
+    properties:
+      Leader:
+        type: "boolean"
+        default: false
+        example: true
+      Reachability:
+        $ref: "#/definitions/Reachability"
+      Addr:
+        description: |
+          The IP address and port at which the manager is reachable.
+        type: "string"
+        example: "10.0.0.46:2377"
+
+  Reachability:
+    description: "Reachability represents the reachability of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "unreachable"
+      - "reachable"
+    example: "reachable"
+
+  SwarmSpec:
+    description: "User modifiable swarm configuration."
+    type: "object"
+    properties:
+      Name:
+        description: "Name of the swarm."
+        type: "string"
+        example: "default"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.corp.type: "production"
+          com.example.corp.department: "engineering"
+      Orchestration:
+        description: "Orchestration configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          TaskHistoryRetentionLimit:
+            description: |
+              The number of historic tasks to keep per instance or node. If
+              negative, never remove completed or failed tasks.
+            type: "integer"
+            format: "int64"
+            example: 10
+      Raft:
+        description: "Raft configuration."
+        type: "object"
+        properties:
+          SnapshotInterval:
+            description: "The number of log entries between snapshots."
+            type: "integer"
+            format: "uint64"
+            example: 10000
+          KeepOldSnapshots:
+            description: |
+              The number of snapshots to keep beyond the current snapshot.
+            type: "integer"
+            format: "uint64"
+          LogEntriesForSlowFollowers:
+            description: |
+              The number of log entries to keep around to sync up slow followers
+              after a snapshot is created.
+            type: "integer"
+            format: "uint64"
+            example: 500
+          ElectionTick:
+            description: |
+              The number of ticks that a follower will wait for a message from
+              the leader before becoming a candidate and starting an election.
+              `ElectionTick` must be greater than `HeartbeatTick`.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 3
+          HeartbeatTick:
+            description: |
+              The number of ticks between heartbeats. Every HeartbeatTick ticks,
+              the leader will send a heartbeat to the followers.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 1
+      Dispatcher:
+        description: "Dispatcher configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          HeartbeatPeriod:
+            description: |
+              The delay for an agent to send a heartbeat to the dispatcher.
+            type: "integer"
+            format: "int64"
+            example: 5000000000
+      CAConfig:
+        description: "CA configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          NodeCertExpiry:
+            description: "The duration node certificates are issued for."
+            type: "integer"
+            format: "int64"
+            example: 7776000000000000
+          ExternalCAs:
+            description: |
+              Configuration for forwarding signing requests to an external
+              certificate authority.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Protocol:
+                  description: |
+                    Protocol for communication with the external CA (currently
+                    only `cfssl` is supported).
+                  type: "string"
+                  enum:
+                    - "cfssl"
+                  default: "cfssl"
+                URL:
+                  description: |
+                    URL where certificate signing requests should be sent.
+                  type: "string"
+                Options:
+                  description: |
+                    An object with key/value pairs that are interpreted as
+                    protocol-specific options for the external CA driver.
+                  type: "object"
+                  additionalProperties:
+                    type: "string"
+                CACert:
+                  description: |
+                    The root CA certificate (in PEM format) this external CA uses
+                    to issue TLS certificates (assumed to be to the current swarm
+                    root CA certificate if not provided).
+                  type: "string"
+          SigningCACert:
+            description: |
+              The desired signing CA certificate for all swarm node TLS leaf
+              certificates, in PEM format.
+            type: "string"
+          SigningCAKey:
+            description: |
+              The desired signing CA key for all swarm node TLS leaf certificates,
+              in PEM format.
+            type: "string"
+          ForceRotate:
+            description: |
+              An integer whose purpose is to force swarm to generate a new
+              signing CA certificate and key, if none have been specified in
+              `SigningCACert` and `SigningCAKey`
+            format: "uint64"
+            type: "integer"
+      EncryptionConfig:
+        description: "Parameters related to encryption-at-rest."
+        type: "object"
+        properties:
+          AutoLockManagers:
+            description: |
+              If set, generate a key and use it to lock data stored on the
+              managers.
+            type: "boolean"
+            example: false
+      TaskDefaults:
+        description: "Defaults for creating tasks in this cluster."
+        type: "object"
+        properties:
+          LogDriver:
+            description: |
+              The log driver to use for tasks created in the orchestrator if
+              unspecified by a service.
+
+              Updating this value only affects new tasks. Existing tasks continue
+              to use their previously configured log driver until recreated.
+            type: "object"
+            properties:
+              Name:
+                description: |
+                  The log driver to use as a default for new tasks.
+                type: "string"
+                example: "json-file"
+              Options:
+                description: |
+                  Driver-specific options for the selected log driver, specified
+                  as key/value pairs.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "10"
+                  "max-size": "100m"
+
+  # The Swarm information for `GET /info`. It is the same as `GET /swarm`, but
+  # without `JoinTokens`.
+  ClusterInfo:
+    description: |
+      ClusterInfo represents information about the swarm as is returned by the
+      "/info" endpoint. Join-tokens are not included.
+    x-nullable: true
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the swarm."
+        type: "string"
+        example: "abajmipo7b4xz5ip2nrla6b11"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the swarm was initialised in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the swarm was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/SwarmSpec"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+      RootRotationInProgress:
+        description: |
+          Whether there is currently a root CA rotation in progress for the swarm
+        type: "boolean"
+        example: false
+      DataPathPort:
+        description: |
+          DataPathPort specifies the data path port number for data traffic.
+          Acceptable port range is 1024 to 49151.
+          If no port is set or is set to 0, the default port (4789) is used.
+        type: "integer"
+        format: "uint32"
+        default: 4789
+        example: 4789
+      DefaultAddrPool:
+        description: |
+          Default Address Pool specifies default subnet pools for global scope
+          networks.
+        type: "array"
+        items:
+          type: "string"
+          format: "CIDR"
+          example: ["10.10.0.0/16", "20.20.0.0/16"]
+      SubnetSize:
+        description: |
+          SubnetSize specifies the subnet size of the networks created from the
+          default subnet pool.
+        type: "integer"
+        format: "uint32"
+        maximum: 29
+        default: 24
+        example: 24
+
+  JoinTokens:
+    description: |
+      JoinTokens contains the tokens workers and managers need to join the swarm.
+    type: "object"
+    properties:
+      Worker:
+        description: |
+          The token workers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx"
+      Manager:
+        description: |
+          The token managers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+
+  Swarm:
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/ClusterInfo"
+      - type: "object"
+        properties:
+          JoinTokens:
+            $ref: "#/definitions/JoinTokens"
+
+  TaskSpec:
+    description: "User modifiable task configuration."
+    type: "object"
+    properties:
+      PluginSpec:
+        type: "object"
+        description: |
+          Plugin spec for the service.  *(Experimental release only.)*
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Name:
+            description: "The name or 'alias' to use for the plugin."
+            type: "string"
+          Remote:
+            description: "The plugin image reference to use."
+            type: "string"
+          Disabled:
+            description: "Disable the plugin once scheduled."
+            type: "boolean"
+          PluginPrivilege:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+      ContainerSpec:
+        type: "object"
+        description: |
+          Container spec for the service.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Image:
+            description: "The image name to use for the container"
+            type: "string"
+          Labels:
+            description: "User-defined key/value data."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          Command:
+            description: "The command to be run in the image."
+            type: "array"
+            items:
+              type: "string"
+          Args:
+            description: "Arguments to the command."
+            type: "array"
+            items:
+              type: "string"
+          Hostname:
+            description: |
+              The hostname to use for the container, as a valid
+              [RFC 1123](https://tools.ietf.org/html/rfc1123) hostname.
+            type: "string"
+          Env:
+            description: |
+              A list of environment variables in the form `VAR=value`.
+            type: "array"
+            items:
+              type: "string"
+          Dir:
+            description: "The working directory for commands to run in."
+            type: "string"
+          User:
+            description: "The user inside the container."
+            type: "string"
+          Groups:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          Privileges:
+            type: "object"
+            description: "Security options for the container"
+            properties:
+              CredentialSpec:
+                type: "object"
+                description: "CredentialSpec for managed service account (Windows only)"
+                properties:
+                  Config:
+                    type: "string"
+                    example: "0bt9dmxjvjiqermk6xrop3ekq"
+                    description: |
+                      Load credential spec from a Swarm Config with the given ID.
+                      The specified config must also be present in the Configs
+                      field with the Runtime property set.
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  File:
+                    type: "string"
+                    example: "spec.json"
+                    description: |
+                      Load credential spec from this file. The file is read by
+                      the daemon, and must be present in the `CredentialSpecs`
+                      subdirectory in the docker data directory, which defaults
+                      to `C:\ProgramData\Docker\` on Windows.
+
+                      For example, specifying `spec.json` loads
+                      `C:\ProgramData\Docker\CredentialSpecs\spec.json`.
+
+                      <p><br /></p>
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  Registry:
+                    type: "string"
+                    description: |
+                      Load credential spec from this value in the Windows
+                      registry. The specified registry value must be located in:
+
+                      `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs`
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+              SELinuxContext:
+                type: "object"
+                description: "SELinux labels of the container"
+                properties:
+                  Disable:
+                    type: "boolean"
+                    description: "Disable SELinux"
+                  User:
+                    type: "string"
+                    description: "SELinux user label"
+                  Role:
+                    type: "string"
+                    description: "SELinux role label"
+                  Type:
+                    type: "string"
+                    description: "SELinux type label"
+                  Level:
+                    type: "string"
+                    description: "SELinux level label"
+              Seccomp:
+                type: "object"
+                description: "Options for configuring seccomp on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "unconfined"
+                      - "custom"
+                  Profile:
+                    description: "The custom seccomp profile as a json object"
+                    type: "string"
+              AppArmor:
+                type: "object"
+                description: "Options for configuring AppArmor on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "disabled"
+              NoNewPrivileges:
+                type: "boolean"
+                description: "Configuration of the no_new_privs bit in the container"
+
+          TTY:
+            description: "Whether a pseudo-TTY should be allocated."
+            type: "boolean"
+          OpenStdin:
+            description: "Open `stdin`"
+            type: "boolean"
+          ReadOnly:
+            description: "Mount the container's root filesystem as read only."
+            type: "boolean"
+          Mounts:
+            description: |
+              Specification for mounts to be added to containers created as part
+              of the service.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          StopSignal:
+            description: "Signal to stop the container."
+            type: "string"
+          StopGracePeriod:
+            description: |
+              Amount of time to wait for the container to terminate before
+              forcefully killing it.
+            type: "integer"
+            format: "int64"
+          HealthCheck:
+            $ref: "#/definitions/HealthConfig"
+          Hosts:
+            type: "array"
+            description: |
+              A list of hostname/IP mappings to add to the container's `hosts`
+              file. The format of extra hosts is specified in the
+              [hosts(5)](http://man7.org/linux/man-pages/man5/hosts.5.html)
+              man page:
+
+                  IP_address canonical_hostname [aliases...]
+            items:
+              type: "string"
+          DNSConfig:
+            description: |
+              Specification for DNS related configurations in resolver configuration
+              file (`resolv.conf`).
+            type: "object"
+            properties:
+              Nameservers:
+                description: "The IP addresses of the name servers."
+                type: "array"
+                items:
+                  type: "string"
+              Search:
+                description: "A search list for host-name lookup."
+                type: "array"
+                items:
+                  type: "string"
+              Options:
+                description: |
+                  A list of internal resolver variables to be modified (e.g.,
+                  `debug`, `ndots:3`, etc.).
+                type: "array"
+                items:
+                  type: "string"
+          Secrets:
+            description: |
+              Secrets contains references to zero or more secrets that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                SecretID:
+                  description: |
+                    SecretID represents the ID of the specific secret that we're
+                    referencing.
+                  type: "string"
+                SecretName:
+                  description: |
+                    SecretName is the name of the secret that this references,
+                    but this is just provided for lookup/display purposes. The
+                    secret in the reference will be identified by its ID.
+                  type: "string"
+          OomScoreAdj:
+            type: "integer"
+            format: "int64"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 0
+          Configs:
+            description: |
+              Configs contains references to zero or more configs that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually exclusive
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                Runtime:
+                  description: |
+                    Runtime represents a target that is not mounted into the
+                    container but is used by the task
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually
+                    > exclusive
+                  type: "object"
+                ConfigID:
+                  description: |
+                    ConfigID represents the ID of the specific config that we're
+                    referencing.
+                  type: "string"
+                ConfigName:
+                  description: |
+                    ConfigName is the name of the config that this references,
+                    but this is just provided for lookup/display purposes. The
+                    config in the reference will be identified by its ID.
+                  type: "string"
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the containers running the service.
+              (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          Init:
+            description: |
+              Run an init inside the container that forwards signals and reaps
+              processes. This field is omitted if empty, and the default (as
+              configured on the daemon) is used.
+            type: "boolean"
+            x-nullable: true
+          Sysctls:
+            description: |
+              Set kernel namedspaced parameters (sysctls) in the container.
+              The Sysctls option on services accepts the same sysctls as the
+              are supported on containers. Note that while the same sysctls are
+              supported, no guarantees or checks are made about their
+              suitability for a clustered environment, and it's up to the user
+              to determine whether a given sysctl will work properly in a
+              Service.
+            type: "object"
+            additionalProperties:
+              type: "string"
+          # This option is not used by Windows containers
+          CapabilityAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+              - "CAP_SYS_ADMIN"
+              - "CAP_SYS_CHROOT"
+              - "CAP_SYSLOG"
+          CapabilityDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+          Ulimits:
+            description: |
+              A list of resource limits to set in the container. For example: `{"Name": "nofile", "Soft": 1024, "Hard": 2048}`"
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Name:
+                  description: "Name of ulimit"
+                  type: "string"
+                Soft:
+                  description: "Soft limit"
+                  type: "integer"
+                Hard:
+                  description: "Hard limit"
+                  type: "integer"
+      NetworkAttachmentSpec:
+        description: |
+          Read-only spec type for non-swarm containers attached to swarm overlay
+          networks.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        type: "object"
+        properties:
+          ContainerID:
+            description: "ID of the container represented by this task"
+            type: "string"
+      Resources:
+        description: |
+          Resource requirements which apply to each individual container created
+          as part of the service.
+        type: "object"
+        properties:
+          Limits:
+            description: "Define resources limits."
+            $ref: "#/definitions/Limit"
+          Reservations:
+            description: "Define resources reservation."
+            $ref: "#/definitions/ResourceObject"
+      RestartPolicy:
+        description: |
+          Specification for the restart policy which applies to containers
+          created as part of this service.
+        type: "object"
+        properties:
+          Condition:
+            description: "Condition for restart."
+            type: "string"
+            enum:
+              - "none"
+              - "on-failure"
+              - "any"
+          Delay:
+            description: "Delay between restart attempts."
+            type: "integer"
+            format: "int64"
+          MaxAttempts:
+            description: |
+              Maximum attempts to restart a given container before giving up
+              (default value is 0, which is ignored).
+            type: "integer"
+            format: "int64"
+            default: 0
+          Window:
+            description: |
+              Windows is the time window used to evaluate the restart policy
+              (default value is 0, which is unbounded).
+            type: "integer"
+            format: "int64"
+            default: 0
+      Placement:
+        type: "object"
+        properties:
+          Constraints:
+            description: |
+              An array of constraint expressions to limit the set of nodes where
+              a task can be scheduled. Constraint expressions can either use a
+              _match_ (`==`) or _exclude_ (`!=`) rule. Multiple constraints find
+              nodes that satisfy every expression (AND match). Constraints can
+              match node or Docker Engine labels as follows:
+
+              node attribute       | matches                        | example
+              ---------------------|--------------------------------|-----------------------------------------------
+              `node.id`            | Node ID                        | `node.id==2ivku8v2gvtg4`
+              `node.hostname`      | Node hostname                  | `node.hostname!=node-2`
+              `node.role`          | Node role (`manager`/`worker`) | `node.role==manager`
+              `node.platform.os`   | Node operating system          | `node.platform.os==windows`
+              `node.platform.arch` | Node architecture              | `node.platform.arch==x86_64`
+              `node.labels`        | User-defined node labels       | `node.labels.security==high`
+              `engine.labels`      | Docker Engine's labels         | `engine.labels.operatingsystem==ubuntu-24.04`
+
+              `engine.labels` apply to Docker Engine labels like operating system,
+              drivers, etc. Swarm administrators add `node.labels` for operational
+              purposes by using the [`node update endpoint`](#operation/NodeUpdate).
+
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "node.hostname!=node3.corp.example.com"
+              - "node.role!=manager"
+              - "node.labels.type==production"
+              - "node.platform.os==linux"
+              - "node.platform.arch==x86_64"
+          Preferences:
+            description: |
+              Preferences provide a way to make the scheduler aware of factors
+              such as topology. They are provided in order from highest to
+              lowest precedence.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Spread:
+                  type: "object"
+                  properties:
+                    SpreadDescriptor:
+                      description: |
+                        label descriptor, such as `engine.labels.az`.
+                      type: "string"
+            example:
+              - Spread:
+                  SpreadDescriptor: "node.labels.datacenter"
+              - Spread:
+                  SpreadDescriptor: "node.labels.rack"
+          MaxReplicas:
+            description: |
+              Maximum number of replicas for per node (default value is 0, which
+              is unlimited)
+            type: "integer"
+            format: "int64"
+            default: 0
+          Platforms:
+            description: |
+              Platforms stores all the platforms that the service's image can
+              run on. This field is used in the platform filter for scheduling.
+              If empty, then the platform filter is off, meaning there are no
+              scheduling restrictions.
+            type: "array"
+            items:
+              $ref: "#/definitions/Platform"
+      ForceUpdate:
+        description: |
+          A counter that triggers an update even if no relevant parameters have
+          been changed.
+        type: "integer"
+        format: "uint64"
+      Runtime:
+        description: |
+          Runtime is the type of runtime specified for the task executor.
+        type: "string"
+      Networks:
+        description: "Specifies which networks the service should attach to."
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+      LogDriver:
+        description: |
+          Specifies the log driver to use for tasks created from this spec. If
+          not present, the default one for the swarm will be used, finally
+          falling back to the engine default if not specified.
+        type: "object"
+        properties:
+          Name:
+            type: "string"
+          Options:
+            type: "object"
+            additionalProperties:
+              type: "string"
+
+  TaskState:
+    type: "string"
+    enum:
+      - "new"
+      - "allocated"
+      - "pending"
+      - "assigned"
+      - "accepted"
+      - "preparing"
+      - "ready"
+      - "starting"
+      - "running"
+      - "complete"
+      - "shutdown"
+      - "failed"
+      - "rejected"
+      - "remove"
+      - "orphaned"
+
+  ContainerStatus:
+    type: "object"
+    description: "represents the status of a container."
+    properties:
+      ContainerID:
+        type: "string"
+      PID:
+        type: "integer"
+      ExitCode:
+        type: "integer"
+
+  PortStatus:
+    type: "object"
+    description: "represents the port status of a task's host ports whose service has published host ports"
+    properties:
+      Ports:
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  TaskStatus:
+    type: "object"
+    description: "represents the status of a task."
+    properties:
+      Timestamp:
+        type: "string"
+        format: "dateTime"
+      State:
+        $ref: "#/definitions/TaskState"
+      Message:
+        type: "string"
+      Err:
+        type: "string"
+      ContainerStatus:
+        $ref: "#/definitions/ContainerStatus"
+      PortStatus:
+        $ref: "#/definitions/PortStatus"
+
+  Task:
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the task."
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Name:
+        description: "Name of the task."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Spec:
+        $ref: "#/definitions/TaskSpec"
+      ServiceID:
+        description: "The ID of the service this task is part of."
+        type: "string"
+      Slot:
+        type: "integer"
+      NodeID:
+        description: "The ID of the node that this task is on."
+        type: "string"
+      AssignedGenericResources:
+        $ref: "#/definitions/GenericResources"
+      Status:
+        $ref: "#/definitions/TaskStatus"
+      DesiredState:
+        $ref: "#/definitions/TaskState"
+      JobIteration:
+        description: |
+          If the Service this Task belongs to is a job-mode service, contains
+          the JobIteration of the Service this Task was created for. Absent if
+          the Task was created for a Replicated or Global Service.
+        $ref: "#/definitions/ObjectVersion"
+    example:
+      ID: "0kzzo1i0y4jz6027t0k7aezc7"
+      Version:
+        Index: 71
+      CreatedAt: "2016-06-07T21:07:31.171892745Z"
+      UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+      Spec:
+        ContainerSpec:
+          Image: "redis"
+        Resources:
+          Limits: {}
+          Reservations: {}
+        RestartPolicy:
+          Condition: "any"
+          MaxAttempts: 0
+        Placement: {}
+      ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Slot: 1
+      NodeID: "60gvrl6tm78dmak4yl7srz94v"
+      Status:
+        Timestamp: "2016-06-07T21:07:31.290032978Z"
+        State: "running"
+        Message: "started"
+        ContainerStatus:
+          ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+          PID: 677
+      DesiredState: "running"
+      NetworksAttachments:
+        - Network:
+            ID: "4qvuz4ko70xaltuqbt8956gd1"
+            Version:
+              Index: 18
+            CreatedAt: "2016-06-07T20:31:11.912919752Z"
+            UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+            Spec:
+              Name: "ingress"
+              Labels:
+                com.docker.swarm.internal: "true"
+              DriverConfiguration: {}
+              IPAMOptions:
+                Driver: {}
+                Configs:
+                  - Subnet: "10.255.0.0/16"
+                    Gateway: "10.255.0.1"
+            DriverState:
+              Name: "overlay"
+              Options:
+                com.docker.network.driver.overlay.vxlanid_list: "256"
+            IPAMOptions:
+              Driver:
+                Name: "default"
+              Configs:
+                - Subnet: "10.255.0.0/16"
+                  Gateway: "10.255.0.1"
+          Addresses:
+            - "10.255.0.10/16"
+      AssignedGenericResources:
+        - DiscreteResourceSpec:
+            Kind: "SSD"
+            Value: 3
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID1"
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID2"
+
+  ServiceSpec:
+    description: "User modifiable configuration for a service."
+    type: object
+    properties:
+      Name:
+        description: "Name of the service."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      TaskTemplate:
+        $ref: "#/definitions/TaskSpec"
+      Mode:
+        description: "Scheduling mode for the service."
+        type: "object"
+        properties:
+          Replicated:
+            type: "object"
+            properties:
+              Replicas:
+                type: "integer"
+                format: "int64"
+          Global:
+            type: "object"
+          ReplicatedJob:
+            description: |
+              The mode used for services with a finite number of tasks that run
+              to a completed state.
+            type: "object"
+            properties:
+              MaxConcurrent:
+                description: |
+                  The maximum number of replicas to run simultaneously.
+                type: "integer"
+                format: "int64"
+                default: 1
+              TotalCompletions:
+                description: |
+                  The total number of replicas desired to reach the Completed
+                  state. If unset, will default to the value of `MaxConcurrent`
+                type: "integer"
+                format: "int64"
+          GlobalJob:
+            description: |
+              The mode used for services which run a task to the completed state
+              on each valid node.
+            type: "object"
+      UpdateConfig:
+        description: "Specification for the update strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be updated in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: "Amount of time between updates, in nanoseconds."
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an updated task fails to run, or stops running
+              during the update.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+              - "rollback"
+          Monitor:
+            description: |
+              Amount of time to monitor each updated task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during an update before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling out an updated task. Either
+              the old task is shut down before the new task is started, or the
+              new task is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      RollbackConfig:
+        description: "Specification for the rollback strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be rolled back in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: |
+              Amount of time between rollback iterations, in nanoseconds.
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an rolled back task fails to run, or stops
+              running during the rollback.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+          Monitor:
+            description: |
+              Amount of time to monitor each rolled back task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during a rollback before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling back a task. Either the old
+              task is shut down before the new task is started, or the new task
+              is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      Networks:
+        description: |
+          Specifies which networks the service should attach to.
+
+          Deprecated: This field is deprecated since v1.44. The Networks field in TaskSpec should be used instead.
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+
+      EndpointSpec:
+        $ref: "#/definitions/EndpointSpec"
+
+  EndpointPortConfig:
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+      Protocol:
+        type: "string"
+        enum:
+          - "tcp"
+          - "udp"
+          - "sctp"
+      TargetPort:
+        description: "The port inside the container."
+        type: "integer"
+      PublishedPort:
+        description: "The port on the swarm hosts."
+        type: "integer"
+      PublishMode:
+        description: |
+          The mode in which port is published.
+
+          <p><br /></p>
+
+          - "ingress" makes the target port accessible on every node,
+            regardless of whether there is a task for the service running on
+            that node or not.
+          - "host" bypasses the routing mesh and publish the port directly on
+            the swarm node where that service is running.
+
+        type: "string"
+        enum:
+          - "ingress"
+          - "host"
+        default: "ingress"
+        example: "ingress"
+
+  EndpointSpec:
+    description: "Properties that can be configured to access and load balance a service."
+    type: "object"
+    properties:
+      Mode:
+        description: |
+          The mode of resolution to use for internal load balancing between tasks.
+        type: "string"
+        enum:
+          - "vip"
+          - "dnsrr"
+        default: "vip"
+      Ports:
+        description: |
+          List of exposed ports that this service is accessible on from the
+          outside. Ports can only be provided if `vip` resolution mode is used.
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  Service:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ServiceSpec"
+      Endpoint:
+        type: "object"
+        properties:
+          Spec:
+            $ref: "#/definitions/EndpointSpec"
+          Ports:
+            type: "array"
+            items:
+              $ref: "#/definitions/EndpointPortConfig"
+          VirtualIPs:
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                NetworkID:
+                  type: "string"
+                Addr:
+                  type: "string"
+      UpdateStatus:
+        description: "The status of a service update."
+        type: "object"
+        properties:
+          State:
+            type: "string"
+            enum:
+              - "updating"
+              - "paused"
+              - "completed"
+          StartedAt:
+            type: "string"
+            format: "dateTime"
+          CompletedAt:
+            type: "string"
+            format: "dateTime"
+          Message:
+            type: "string"
+      ServiceStatus:
+        description: |
+          The status of the service's tasks. Provided only when requested as
+          part of a ServiceList operation.
+        type: "object"
+        properties:
+          RunningTasks:
+            description: |
+              The number of tasks for the service currently in the Running state.
+            type: "integer"
+            format: "uint64"
+            example: 7
+          DesiredTasks:
+            description: |
+              The number of tasks for the service desired to be running.
+              For replicated services, this is the replica count from the
+              service spec. For global services, this is computed by taking
+              count of all tasks for the service with a Desired State other
+              than Shutdown.
+            type: "integer"
+            format: "uint64"
+            example: 10
+          CompletedTasks:
+            description: |
+              The number of tasks for a job that are in the Completed state.
+              This field must be cross-referenced with the service type, as the
+              value of 0 may mean the service is not in a job mode, or it may
+              mean the job-mode service has no tasks yet Completed.
+            type: "integer"
+            format: "uint64"
+      JobStatus:
+        description: |
+          The status of the service when it is in one of ReplicatedJob or
+          GlobalJob modes. Absent on Replicated and Global mode services. The
+          JobIteration is an ObjectVersion, but unlike the Service's version,
+          does not need to be sent with an update request.
+        type: "object"
+        properties:
+          JobIteration:
+            description: |
+              JobIteration is a value increased each time a Job is executed,
+              successfully or otherwise. "Executed", in this case, means the
+              job as a whole has been started, not that an individual Task has
+              been launched. A job is "Executed" when its ServiceSpec is
+              updated. JobIteration can be used to disambiguate Tasks belonging
+              to different executions of a job.  Though JobIteration will
+              increase with each subsequent execution, it may not necessarily
+              increase by 1, and so JobIteration should not be used to
+            $ref: "#/definitions/ObjectVersion"
+          LastExecution:
+            description: |
+              The last time, as observed by the server, that this job was
+              started.
+            type: "string"
+            format: "dateTime"
+    example:
+      ID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Version:
+        Index: 19
+      CreatedAt: "2016-06-07T21:05:51.880065305Z"
+      UpdatedAt: "2016-06-07T21:07:29.962229872Z"
+      Spec:
+        Name: "hopeful_cori"
+        TaskTemplate:
+          ContainerSpec:
+            Image: "redis"
+          Resources:
+            Limits: {}
+            Reservations: {}
+          RestartPolicy:
+            Condition: "any"
+            MaxAttempts: 0
+          Placement: {}
+          ForceUpdate: 0
+        Mode:
+          Replicated:
+            Replicas: 1
+        UpdateConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        RollbackConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        EndpointSpec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+      Endpoint:
+        Spec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+        Ports:
+          -
+            Protocol: "tcp"
+            TargetPort: 6379
+            PublishedPort: 30001
+        VirtualIPs:
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.2/16"
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.3/16"
+
+  ImageDeleteResponseItem:
+    type: "object"
+    x-go-name: "DeleteResponse"
+    properties:
+      Untagged:
+        description: "The image ID of an image that was untagged"
+        type: "string"
+      Deleted:
+        description: "The image ID of an image that was deleted"
+        type: "string"
+
+  ServiceCreateResponse:
+    type: "object"
+    description: |
+      contains the information returned to a client on the
+      creation of a new service.
+    properties:
+      ID:
+        description: "The ID of the created service."
+        type: "string"
+        x-nullable: false
+        example: "ak7w3gjqoa3kuz8xcpnyy0pvl"
+      Warnings:
+        description: |
+          Optional warning message.
+
+          FIXME(thaJeztah): this should have "omitempty" in the generated type.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example:
+          - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ServiceUpdateResponse:
+    type: "object"
+    properties:
+      Warnings:
+        description: "Optional warning messages"
+        type: "array"
+        items:
+          type: "string"
+    example:
+      Warnings:
+        - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ContainerInspectResponse:
+    type: "object"
+    title: "ContainerInspectResponse"
+    x-go-name: "InspectResponse"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Created:
+        description: |-
+          Date and time at which the container was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2025-02-17T17:43:39.64001363Z"
+      Path:
+        description: |-
+          The path to the command being run
+        type: "string"
+        example: "/bin/sh"
+      Args:
+        description: "The arguments to the command being run"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "-c"
+          - "exit 9"
+      State:
+        $ref: "#/definitions/ContainerState"
+      Image:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ResolvConfPath:
+        description: |-
+          Location of the `/etc/resolv.conf` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/resolv.conf"
+      HostnamePath:
+        description: |-
+          Location of the `/etc/hostname` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hostname"
+      HostsPath:
+        description: |-
+          Location of the `/etc/hosts` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hosts"
+      LogPath:
+        description: |-
+          Location of the file used to buffer the container's logs. Depending on
+          the logging-driver used for the container, this field may be omitted.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        x-nullable: true
+        example: "/var/lib/docker/containers/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59-json.log"
+      Name:
+        description: |-
+          The name associated with this container.
+
+          For historic reasons, the name may be prefixed with a forward-slash (`/`).
+        type: "string"
+        example: "/funny_chatelet"
+      RestartCount:
+        description: |-
+          Number of times the container was restarted since it was created,
+          or since daemon was started.
+        type: "integer"
+        example: 0
+      Driver:
+        description: |-
+          The storage-driver used for the container's filesystem (graph-driver
+          or snapshotter).
+        type: "string"
+        example: "overlayfs"
+      Platform:
+        description: |-
+          The platform (operating system) for which the container was created.
+
+          This field was introduced for the experimental "LCOW" (Linux Containers
+          On Windows) features, which has been removed. In most cases, this field
+          is equal to the host's operating system (`linux` or `windows`).
+        type: "string"
+        example: "linux"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        description: |-
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+      MountLabel:
+        description: |-
+          SELinux mount label set for the container.
+        type: "string"
+        example: ""
+      ProcessLabel:
+        description: |-
+          SELinux process label set for the container.
+        type: "string"
+        example: ""
+      AppArmorProfile:
+        description: |-
+          The AppArmor profile set for the container.
+        type: "string"
+        example: ""
+      ExecIDs:
+        description: |-
+          IDs of exec instances that are running in the container.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example:
+          - "b35395de42bc8abd327f9dd65d913b9ba28c74d2f0734eeeae84fa1c616a0fca"
+          - "3fc1232e5cd20c8de182ed81178503dc6437f4e7ef12b52cc5e8de020652f1c4"
+      HostConfig:
+        $ref: "#/definitions/HostConfig"
+      GraphDriver:
+        $ref: "#/definitions/DriverData"
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Mounts:
+        description: |-
+          List of mounts used by the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/MountPoint"
+      Config:
+        $ref: "#/definitions/ContainerConfig"
+      NetworkSettings:
+        $ref: "#/definitions/NetworkSettings"
+
+  ContainerSummary:
+    type: "object"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Names:
+        description: |-
+          The names associated with this container. Most containers have a single
+          name, but when using legacy "links", the container can have multiple
+          names.
+
+          For historic reasons, names are prefixed with a forward-slash (`/`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/funny_chatelet"
+      Image:
+        description: |-
+          The name or ID of the image used to create the container.
+
+          This field shows the image reference as was specified when creating the container,
+          which can be in its canonical form (e.g., `docker.io/library/ubuntu:latest`
+          or `docker.io/library/ubuntu@sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`),
+          short form (e.g., `ubuntu:latest`)), or the ID(-prefix) of the image (e.g., `72297848456d`).
+
+          The content of this field can be updated at runtime if the image used to
+          create the container is untagged, in which case the field is updated to
+          contain the the image ID (digest) it was resolved to in its canonical,
+          non-truncated form (e.g., `sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`).
+        type: "string"
+        example: "docker.io/library/ubuntu:latest"
+      ImageID:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        x-nullable: true
+        description: |
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+
+          This field is not populated in the `GET /system/df` endpoint.
+      Command:
+        description: "Command to run when starting the container"
+        type: "string"
+        example: "/bin/bash"
+      Created:
+        description: |-
+          Date and time at which the container was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        format: "int64"
+        example: "1739811096"
+      Ports:
+        description: |-
+          Port-mappings for the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/Port"
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.vendor: "Acme"
+          com.example.license: "GPL"
+          com.example.version: "1.0"
+      State:
+        description: |
+          The state of this container.
+        type: "string"
+        enum:
+          - "created"
+          - "running"
+          - "paused"
+          - "restarting"
+          - "exited"
+          - "removing"
+          - "dead"
+        example: "running"
+      Status:
+        description: |-
+          Additional human-readable status of this container (e.g. `Exit 0`)
+        type: "string"
+        example: "Up 4 days"
+      HostConfig:
+        type: "object"
+        description: |-
+          Summary of host-specific runtime information of the container. This
+          is a reduced set of information in the container's "HostConfig" as
+          available in the container "inspect" response.
+        properties:
+          NetworkMode:
+            description: |-
+              Networking mode (`host`, `none`, `container:<id>`) or name of the
+              primary network the container is using.
+
+              This field is primarily for backward compatibility. The container
+              can be connected to multiple networks for which information can be
+              found in the `NetworkSettings.Networks` field, which enumerates
+              settings per network.
+            type: "string"
+            example: "mynetwork"
+          Annotations:
+            description: |-
+              Arbitrary key-value metadata attached to the container.
+            type: "object"
+            x-nullable: true
+            additionalProperties:
+              type: "string"
+            example:
+              io.kubernetes.docker.type: "container"
+              io.kubernetes.sandbox.id: "3befe639bed0fd6afdd65fd1fa84506756f59360ec4adc270b0fdac9be22b4d3"
+      NetworkSettings:
+        description: |-
+          Summary of the container's network settings
+        type: "object"
+        properties:
+          Networks:
+            type: "object"
+            description: |-
+              Summary of network-settings for each network the container is
+              attached to.
+            additionalProperties:
+              $ref: "#/definitions/EndpointSettings"
+      Mounts:
+        type: "array"
+        description: |-
+          List of mounts used by the container.
+        items:
+          $ref: "#/definitions/MountPoint"
+
+  Driver:
+    description: "Driver represents a driver (network, logging, secrets)."
+    type: "object"
+    required: [Name]
+    properties:
+      Name:
+        description: "Name of the driver."
+        type: "string"
+        x-nullable: false
+        example: "some-driver"
+      Options:
+        description: "Key/value map of driver-specific options."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          OptionA: "value for driver-specific option A"
+          OptionB: "value for driver-specific option B"
+
+  SecretSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the secret."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Data:
+        description: |
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          It must be empty if the Driver field is set, in which case the data is
+          loaded from an external secret store. The maximum allowed size is 500KB,
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
+
+          This field is only used to _create_ a secret, and is not returned by
+          other endpoints.
+        type: "string"
+        example: ""
+      Driver:
+        description: |
+          Name of the secrets driver used to fetch the secret's value from an
+          external secret store.
+        $ref: "#/definitions/Driver"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Secret:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "blt1owaxmitz71s9v5zh81zun"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      Spec:
+        $ref: "#/definitions/SecretSpec"
+
+  ConfigSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the config."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Data:
+        description: |
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
+        type: "string"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Config:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ConfigSpec"
+
+  ContainerState:
+    description: |
+      ContainerState stores container's running state. It's part of ContainerJSONBase
+      and will be returned by the "inspect" command.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          String representation of the container state. Can be one of "created",
+          "running", "paused", "restarting", "removing", "exited", or "dead".
+        type: "string"
+        enum: ["created", "running", "paused", "restarting", "removing", "exited", "dead"]
+        example: "running"
+      Running:
+        description: |
+          Whether this container is running.
+
+          Note that a running container can be _paused_. The `Running` and `Paused`
+          booleans are not mutually exclusive:
+
+          When pausing a container (on Linux), the freezer cgroup is used to suspend
+          all processes in the container. Freezing the process requires the process to
+          be running. As a result, paused containers are both `Running` _and_ `Paused`.
+
+          Use the `Status` field instead to determine if a container's state is "running".
+        type: "boolean"
+        example: true
+      Paused:
+        description: "Whether this container is paused."
+        type: "boolean"
+        example: false
+      Restarting:
+        description: "Whether this container is restarting."
+        type: "boolean"
+        example: false
+      OOMKilled:
+        description: |
+          Whether a process within this container has been killed because it ran
+          out of memory since the container was last started.
+        type: "boolean"
+        example: false
+      Dead:
+        type: "boolean"
+        example: false
+      Pid:
+        description: "The process ID of this container"
+        type: "integer"
+        example: 1234
+      ExitCode:
+        description: "The last exit code of this container"
+        type: "integer"
+        example: 0
+      Error:
+        type: "string"
+      StartedAt:
+        description: "The time when this container was last started."
+        type: "string"
+        example: "2020-01-06T09:06:59.461876391Z"
+      FinishedAt:
+        description: "The time when this container last exited."
+        type: "string"
+        example: "2020-01-06T09:07:59.461876391Z"
+      Health:
+        $ref: "#/definitions/Health"
+
+  ContainerCreateResponse:
+    description: "OK response to ContainerCreate operation"
+    type: "object"
+    title: "ContainerCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warnings]
+    properties:
+      Id:
+        description: "The ID of the created container"
+        type: "string"
+        x-nullable: false
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Warnings:
+        description: "Warnings encountered when creating the container"
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example: []
+
+  ContainerUpdateResponse:
+    type: "object"
+    title: "ContainerUpdateResponse"
+    x-go-name: "UpdateResponse"
+    description: |-
+      Response for a successful container-update.
+    properties:
+      Warnings:
+        type: "array"
+        description: |-
+          Warnings encountered when updating the container.
+        items:
+          type: "string"
+        example: ["Published ports are discarded when using host network mode"]
+
+  ContainerStatsResponse:
+    description: |
+      Statistics sample for a container.
+    type: "object"
+    x-go-name: "StatsResponse"
+    title: "ContainerStatsResponse"
+    properties:
+      name:
+        description: "Name of the container"
+        type: "string"
+        x-nullable: true
+        example: "boring_wozniak"
+      id:
+        description: "ID of the container"
+        type: "string"
+        x-nullable: true
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      read:
+        description: |
+          Date and time at which this sample was collected.
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:22.165243637Z"
+      preread:
+        description: |
+          Date and time at which this first sample was collected. This field
+          is not propagated if the "one-shot" option is set. If the "one-shot"
+          option is set, this field may be omitted, empty, or set to a default
+          date (`0001-01-01T00:00:00Z`).
+
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:21.160452595Z"
+      pids_stats:
+        $ref: "#/definitions/ContainerPidsStats"
+      blkio_stats:
+        $ref: "#/definitions/ContainerBlkioStats"
+      num_procs:
+        description: |
+          The number of processors on the system.
+
+          This field is Windows-specific and always zero for Linux containers.
+        type: "integer"
+        format: "uint32"
+        example: 16
+      storage_stats:
+        $ref: "#/definitions/ContainerStorageStats"
+      cpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+      precpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+      memory_stats:
+        $ref: "#/definitions/ContainerMemoryStats"
+      networks:
+        description: |
+          Network statistics for the container per interface.
+
+          This field is omitted if the container has no networking enabled.
+        x-nullable: true
+        additionalProperties:
+          $ref: "#/definitions/ContainerNetworkStats"
+        example:
+          eth0:
+            rx_bytes: 5338
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 36
+            tx_bytes: 648
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 8
+          eth5:
+            rx_bytes: 4641
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 26
+            tx_bytes: 690
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 9
+
+  ContainerBlkioStats:
+    description: |
+      BlkioStats stores all IO service stats for data read and write.
+
+      This type is Linux-specific and holds many fields that are specific to cgroups v1.
+      On a cgroup v2 host, all fields other than `io_service_bytes_recursive`
+      are omitted or `null`.
+
+      This type is only populated on Linux and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStats"
+    x-nullable: true
+    properties:
+      io_service_bytes_recursive:
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_serviced_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_queue_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_service_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_wait_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_merged_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      sectors_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+    example:
+      io_service_bytes_recursive: [
+        {"major": 254, "minor": 0, "op": "read", "value": 7593984},
+        {"major": 254, "minor": 0, "op": "write", "value": 100}
+      ]
+      io_serviced_recursive: null
+      io_queue_recursive: null
+      io_service_time_recursive: null
+      io_wait_time_recursive: null
+      io_merged_recursive: null
+      io_time_recursive: null
+      sectors_recursive: null
+
+  ContainerBlkioStatEntry:
+    description: |
+      Blkio stats entry.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStatEntry"
+    x-nullable: true
+    properties:
+      major:
+        type: "integer"
+        format: "uint64"
+        example: 254
+      minor:
+        type: "integer"
+        format: "uint64"
+        example: 0
+      op:
+        type: "string"
+        example: "read"
+      value:
+        type: "integer"
+        format: "uint64"
+        example: 7593984
+
+  ContainerCPUStats:
+    description: |
+      CPU related info of the container
+    type: "object"
+    x-go-name: "CPUStats"
+    x-nullable: true
+    properties:
+      cpu_usage:
+        $ref: "#/definitions/ContainerCPUUsage"
+      system_cpu_usage:
+        description: |
+          System Usage.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      online_cpus:
+        description: |
+          Number of online CPUs.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint32"
+        x-nullable: true
+        example: 5
+      throttling_data:
+        $ref: "#/definitions/ContainerThrottlingData"
+
+  ContainerCPUUsage:
+    description: |
+      All CPU stats aggregated since container inception.
+    type: "object"
+    x-go-name: "CPUUsage"
+    x-nullable: true
+    properties:
+      total_usage:
+        description: |
+          Total CPU time consumed in nanoseconds (Linux) or 100's of nanoseconds (Windows).
+        type: "integer"
+        format: "uint64"
+        example: 29912000
+      percpu_usage:
+        description: |
+          Total CPU time (in nanoseconds) consumed per core (Linux).
+
+          This field is Linux-specific when using cgroups v1. It is omitted
+          when using cgroups v2 and Windows containers.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "integer"
+          format: "uint64"
+          example: 29912000
+
+      usage_in_kernelmode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in kernel mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 21994000
+      usage_in_usermode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in user mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 7918000
+
+  ContainerPidsStats:
+    description: |
+      PidsStats contains Linux-specific stats of a container's process-IDs (PIDs).
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "PidsStats"
+    x-nullable: true
+    properties:
+      current:
+        description: |
+          Current is the number of PIDs in the cgroup.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      limit:
+        description: |
+          Limit is the hard limit on the number of pids in the cgroup.
+          A "Limit" of 0 means that there is no limit.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: "18446744073709551615"
+
+  ContainerThrottlingData:
+    description: |
+      CPU throttling stats of the container.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "ThrottlingData"
+    x-nullable: true
+    properties:
+      periods:
+        description: |
+          Number of periods with throttling active.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_periods:
+        description: |
+          Number of periods when the container hit its throttling limit.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_time:
+        description: |
+          Aggregated time (in nanoseconds) the container was throttled for.
+        type: "integer"
+        format: "uint64"
+        example: 0
+
+  ContainerMemoryStats:
+    description: |
+      Aggregates all memory stats since container inception on Linux.
+      Windows returns stats for commit and private working set only.
+    type: "object"
+    x-go-name: "MemoryStats"
+    properties:
+      usage:
+        description: |
+          Current `res_counter` usage for memory.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      max_usage:
+        description: |
+          Maximum usage ever recorded.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      stats:
+        description: |
+          All the stats exported via memory.stat.
+
+          The fields in this object differ between cgroups v1 and v2.
+          On cgroups v1, fields such as `cache`, `rss`, `mapped_file` are available.
+          On cgroups v2, fields such as `file`, `anon`, `inactive_file` are available.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "object"
+        additionalProperties:
+          type: "integer"
+          format: "uint64"
+          x-nullable: true
+        example:
+          {
+            "active_anon": 1572864,
+            "active_file": 5115904,
+            "anon": 1572864,
+            "anon_thp": 0,
+            "file": 7626752,
+            "file_dirty": 0,
+            "file_mapped": 2723840,
+            "file_writeback": 0,
+            "inactive_anon": 0,
+            "inactive_file": 2510848,
+            "kernel_stack": 16384,
+            "pgactivate": 0,
+            "pgdeactivate": 0,
+            "pgfault": 2042,
+            "pglazyfree": 0,
+            "pglazyfreed": 0,
+            "pgmajfault": 45,
+            "pgrefill": 0,
+            "pgscan": 0,
+            "pgsteal": 0,
+            "shmem": 0,
+            "slab": 1180928,
+            "slab_reclaimable": 725576,
+            "slab_unreclaimable": 455352,
+            "sock": 0,
+            "thp_collapse_alloc": 0,
+            "thp_fault_alloc": 1,
+            "unevictable": 0,
+            "workingset_activate": 0,
+            "workingset_nodereclaim": 0,
+            "workingset_refault": 0
+          }
+      failcnt:
+        description: |
+          Number of times memory usage hits limits.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      limit:
+        description: |
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 8217579520
+      commitbytes:
+        description: |
+          Committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      commitpeakbytes:
+        description: |
+          Peak committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      privateworkingset:
+        description: |
+          Private working set.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+
+  ContainerNetworkStats:
+    description: |
+      Aggregates the network stats of one container
+    type: "object"
+    x-go-name: "NetworkStats"
+    x-nullable: true
+    properties:
+      rx_bytes:
+        description: |
+          Bytes received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 5338
+      rx_packets:
+        description: |
+          Packets received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 36
+      rx_errors:
+        description: |
+          Received errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      rx_dropped:
+        description: |
+          Incoming packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_bytes:
+        description: |
+          Bytes sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 1200
+      tx_packets:
+        description: |
+          Packets sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 12
+      tx_errors:
+        description: |
+          Sent errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_dropped:
+        description: |
+          Outgoing packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      endpoint_id:
+        description: |
+          Endpoint ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+      instance_id:
+        description: |
+          Instance ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+
+  ContainerStorageStats:
+    description: |
+      StorageStats is the disk I/O stats for read/write on Windows.
+
+      This type is Windows-specific and omitted for Linux containers.
+    type: "object"
+    x-go-name: "StorageStats"
+    x-nullable: true
+    properties:
+      read_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      read_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+
+  ContainerTopResponse:
+    type: "object"
+    x-go-name: "TopResponse"
+    title: "ContainerTopResponse"
+    description: |-
+      Container "top" response.
+    properties:
+      Titles:
+        description: "The ps column titles"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          Titles:
+            - "UID"
+            - "PID"
+            - "PPID"
+            - "C"
+            - "STIME"
+            - "TTY"
+            - "TIME"
+            - "CMD"
+      Processes:
+        description: |-
+          Each process running in the container, where each process
+          is an array of values corresponding to the titles.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          Processes:
+            -
+              - "root"
+              - "13642"
+              - "882"
+              - "0"
+              - "17:03"
+              - "pts/0"
+              - "00:00:00"
+              - "/bin/bash"
+            -
+              - "root"
+              - "13735"
+              - "13642"
+              - "0"
+              - "17:06"
+              - "pts/0"
+              - "00:00:00"
+              - "sleep 10"
+
+  ContainerWaitResponse:
+    description: "OK response to ContainerWait operation"
+    type: "object"
+    x-go-name: "WaitResponse"
+    title: "ContainerWaitResponse"
+    required: [StatusCode]
+    properties:
+      StatusCode:
+        description: "Exit code of the container"
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Error:
+        $ref: "#/definitions/ContainerWaitExitError"
+
+  ContainerWaitExitError:
+    description: "container waiting error, if any"
+    type: "object"
+    x-go-name: "WaitExitError"
+    properties:
+      Message:
+        description: "Details of an error"
+        type: "string"
+
+  SystemVersion:
+    type: "object"
+    description: |
+      Response of Engine API: GET "/version"
+    properties:
+      Platform:
+        type: "object"
+        required: [Name]
+        properties:
+          Name:
+            type: "string"
+      Components:
+        type: "array"
+        description: |
+          Information about system components
+        items:
+          type: "object"
+          x-go-name: ComponentVersion
+          required: [Name, Version]
+          properties:
+            Name:
+              description: |
+                Name of the component
+              type: "string"
+              example: "Engine"
+            Version:
+              description: |
+                Version of the component
+              type: "string"
+              x-nullable: false
+              example: "27.0.1"
+            Details:
+              description: |
+                Key/value pairs of strings with additional information about the
+                component. These values are intended for informational purposes
+                only, and their content is not defined, and not part of the API
+                specification.
+
+                These messages can be printed by the client as information to the user.
+              type: "object"
+              x-nullable: true
+      Version:
+        description: "The version of the daemon"
+        type: "string"
+        example: "27.0.1"
+      ApiVersion:
+        description: |
+          The default (and highest) API version that is supported by the daemon
+        type: "string"
+        example: "1.47"
+      MinAPIVersion:
+        description: |
+          The minimum API version that is supported by the daemon
+        type: "string"
+        example: "1.24"
+      GitCommit:
+        description: |
+          The Git commit of the source code that was used to build the daemon
+        type: "string"
+        example: "48a66213fe"
+      GoVersion:
+        description: |
+          The version Go used to compile the daemon, and the version of the Go
+          runtime in use.
+        type: "string"
+        example: "go1.22.7"
+      Os:
+        description: |
+          The operating system that the daemon is running on ("linux" or "windows")
+        type: "string"
+        example: "linux"
+      Arch:
+        description: |
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "amd64"
+      KernelVersion:
+        description: |
+          The kernel version (`uname -r`) that the daemon is running on.
+
+          This field is omitted when empty.
+        type: "string"
+        example: "6.8.0-31-generic"
+      Experimental:
+        description: |
+          Indicates if the daemon is started with experimental features enabled.
+
+          This field is omitted when empty / false.
+        type: "boolean"
+        example: true
+      BuildTime:
+        description: |
+          The date and time that the daemon was compiled.
+        type: "string"
+        example: "2020-06-22T15:49:27.000000000+00:00"
+
+  SystemInfo:
+    type: "object"
+    properties:
+      ID:
+        description: |
+          Unique identifier of the daemon.
+
+          <p><br /></p>
+
+          > **Note**: The format of the ID itself is not part of the API, and
+          > should not be considered stable.
+        type: "string"
+        example: "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS"
+      Containers:
+        description: "Total number of containers on the host."
+        type: "integer"
+        example: 14
+      ContainersRunning:
+        description: |
+          Number of containers with status `"running"`.
+        type: "integer"
+        example: 3
+      ContainersPaused:
+        description: |
+          Number of containers with status `"paused"`.
+        type: "integer"
+        example: 1
+      ContainersStopped:
+        description: |
+          Number of containers with status `"stopped"`.
+        type: "integer"
+        example: 10
+      Images:
+        description: |
+          Total number of images on the host.
+
+          Both _tagged_ and _untagged_ (dangling) images are counted.
+        type: "integer"
+        example: 508
+      Driver:
+        description: "Name of the storage driver in use."
+        type: "string"
+        example: "overlay2"
+      DriverStatus:
+        description: |
+          Information specific to the storage driver, provided as
+          "label" / "value" pairs.
+
+          This information is provided by the storage driver, and formatted
+          in a way consistent with the output of `docker info` on the command
+          line.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["Backing Filesystem", "extfs"]
+          - ["Supports d_type", "true"]
+          - ["Native Overlay Diff", "true"]
+      DockerRootDir:
+        description: |
+          Root directory of persistent Docker state.
+
+          Defaults to `/var/lib/docker` on Linux, and `C:\ProgramData\docker`
+          on Windows.
+        type: "string"
+        example: "/var/lib/docker"
+      Plugins:
+        $ref: "#/definitions/PluginsInfo"
+      MemoryLimit:
+        description: "Indicates if the host has memory limit support enabled."
+        type: "boolean"
+        example: true
+      SwapLimit:
+        description: "Indicates if the host has memory swap limit support enabled."
+        type: "boolean"
+        example: true
+      KernelMemoryTCP:
+        description: |
+          Indicates if the host has kernel memory TCP limit support enabled. This
+          field is omitted if not supported.
+
+          Kernel memory TCP limits are not supported when using cgroups v2, which
+          does not support the corresponding `memory.kmem.tcp.limit_in_bytes` cgroup.
+        type: "boolean"
+        example: true
+      CpuCfsPeriod:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) period is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CpuCfsQuota:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) quota is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CPUShares:
+        description: |
+          Indicates if CPU Shares limiting is supported by the host.
+        type: "boolean"
+        example: true
+      CPUSet:
+        description: |
+          Indicates if CPUsets (cpuset.cpus, cpuset.mems) are supported by the host.
+
+          See [cpuset(7)](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt)
+        type: "boolean"
+        example: true
+      PidsLimit:
+        description: "Indicates if the host kernel has PID limit support enabled."
+        type: "boolean"
+        example: true
+      OomKillDisable:
+        description: "Indicates if OOM killer disable is supported on the host."
+        type: "boolean"
+      IPv4Forwarding:
+        description: "Indicates IPv4 forwarding is enabled."
+        type: "boolean"
+        example: true
+      Debug:
+        description: |
+          Indicates if the daemon is running in debug-mode / with debug-level
+          logging enabled.
+        type: "boolean"
+        example: true
+      NFd:
+        description: |
+          The total number of file Descriptors in use by the daemon process.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 64
+      NGoroutines:
+        description: |
+          The  number of goroutines that currently exist.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 174
+      SystemTime:
+        description: |
+          Current system-time in [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          format with nano-seconds.
+        type: "string"
+        example: "2017-08-08T20:28:29.06202363Z"
+      LoggingDriver:
+        description: |
+          The logging driver to use as a default for new containers.
+        type: "string"
+      CgroupDriver:
+        description: |
+          The driver to use for managing cgroups.
+        type: "string"
+        enum: ["cgroupfs", "systemd", "none"]
+        default: "cgroupfs"
+        example: "cgroupfs"
+      CgroupVersion:
+        description: |
+          The version of the cgroup.
+        type: "string"
+        enum: ["1", "2"]
+        default: "1"
+        example: "1"
+      NEventsListener:
+        description: "Number of event listeners subscribed."
+        type: "integer"
+        example: 30
+      KernelVersion:
+        description: |
+          Kernel version of the host.
+
+          On Linux, this information obtained from `uname`. On Windows this
+          information is queried from the <kbd>HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\</kbd>
+          registry value, for example _"10.0 14393 (14393.1198.amd64fre.rs1_release_sec.170427-1353)"_.
+        type: "string"
+        example: "6.8.0-31-generic"
+      OperatingSystem:
+        description: |
+          Name of the host's operating system, for example: "Ubuntu 24.04 LTS"
+          or "Windows Server 2016 Datacenter"
+        type: "string"
+        example: "Ubuntu 24.04 LTS"
+      OSVersion:
+        description: |
+          Version of the host's operating system
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including its
+          > very existence, and the formatting of values, should not be considered
+          > stable, and may change without notice.
+        type: "string"
+        example: "24.04"
+      OSType:
+        description: |
+          Generic type of the operating system of the host, as returned by the
+          Go runtime (`GOOS`).
+
+          Currently returned values are "linux" and "windows". A full list of
+          possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "linux"
+      Architecture:
+        description: |
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
+
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
+        type: "string"
+        example: "x86_64"
+      NCPU:
+        description: |
+          The number of logical CPUs usable by the daemon.
+
+          The number of available CPUs is checked by querying the operating
+          system when the daemon starts. Changes to operating system CPU
+          allocation after the daemon is started are not reflected.
+        type: "integer"
+        example: 4
+      MemTotal:
+        description: |
+          Total amount of physical memory available on the host, in bytes.
+        type: "integer"
+        format: "int64"
+        example: 2095882240
+
+      IndexServerAddress:
+        description: |
+          Address / URL of the index server that is used for image search,
+          and as a default for user authentication for Docker Hub and Docker Cloud.
+        default: "https://index.docker.io/v1/"
+        type: "string"
+        example: "https://index.docker.io/v1/"
+      RegistryConfig:
+        $ref: "#/definitions/RegistryServiceConfig"
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+      HttpProxy:
+        description: |
+          HTTP-proxy configured for the daemon. This value is obtained from the
+          [`HTTP_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "http://xxxxx:xxxxx@proxy.corp.example.com:8080"
+      HttpsProxy:
+        description: |
+          HTTPS-proxy configured for the daemon. This value is obtained from the
+          [`HTTPS_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "https://xxxxx:xxxxx@proxy.corp.example.com:4443"
+      NoProxy:
+        description: |
+          Comma-separated list of domain extensions for which no proxy should be
+          used. This value is obtained from the [`NO_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html)
+          environment variable.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "*.local, 169.254/16"
+      Name:
+        description: "Hostname of the host."
+        type: "string"
+        example: "node5.corp.example.com"
+      Labels:
+        description: |
+          User-defined labels (key/value metadata) as set on the daemon.
+
+          <p><br /></p>
+
+          > **Note**: When part of a Swarm, nodes can both have _daemon_ labels,
+          > set through the daemon configuration, and _node_ labels, set from a
+          > manager node in the Swarm. Node labels are not included in this
+          > field. Node labels can be retrieved using the `/nodes/(id)` endpoint
+          > on a manager node in the Swarm.
+        type: "array"
+        items:
+          type: "string"
+        example: ["storage=ssd", "production"]
+      ExperimentalBuild:
+        description: |
+          Indicates if experimental features are enabled on the daemon.
+        type: "boolean"
+        example: true
+      ServerVersion:
+        description: |
+          Version string of the daemon.
+        type: "string"
+        example: "27.0.1"
+      Runtimes:
+        description: |
+          List of [OCI compliant](https://github.com/opencontainers/runtime-spec)
+          runtimes configured on the daemon. Keys hold the "name" used to
+          reference the runtime.
+
+          The Docker daemon relies on an OCI compliant runtime (invoked via the
+          `containerd` daemon) as its interface to the Linux kernel namespaces,
+          cgroups, and SELinux.
+
+          The default runtime is `runc`, and automatically configured. Additional
+          runtimes can be configured by the user and will be listed here.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/Runtime"
+        default:
+          runc:
+            path: "runc"
+        example:
+          runc:
+            path: "runc"
+          runc-master:
+            path: "/go/bin/runc"
+          custom:
+            path: "/usr/local/bin/my-oci-runtime"
+            runtimeArgs: ["--debug", "--systemd-cgroup=false"]
+      DefaultRuntime:
+        description: |
+          Name of the default OCI runtime that is used when starting containers.
+
+          The default can be overridden per-container at create time.
+        type: "string"
+        default: "runc"
+        example: "runc"
+      Swarm:
+        $ref: "#/definitions/SwarmInfo"
+      LiveRestoreEnabled:
+        description: |
+          Indicates if live restore is enabled.
+
+          If enabled, containers are kept running when the daemon is shutdown
+          or upon daemon start if running containers are detected.
+        type: "boolean"
+        default: false
+        example: false
+      Isolation:
+        description: |
+          Represents the isolation technology to use as a default for containers.
+          The supported values are platform-specific.
+
+          If no isolation value is specified on daemon start, on Windows client,
+          the default is `hyperv`, and on Windows server, the default is `process`.
+
+          This option is currently not used on other platforms.
+        default: "default"
+        type: "string"
+        enum:
+          - "default"
+          - "hyperv"
+          - "process"
+          - ""
+      InitBinary:
+        description: |
+          Name and, optional, path of the `docker-init` binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "docker-init"
+      ContainerdCommit:
+        $ref: "#/definitions/Commit"
+      RuncCommit:
+        $ref: "#/definitions/Commit"
+      InitCommit:
+        $ref: "#/definitions/Commit"
+      SecurityOptions:
+        description: |
+          List of security features that are enabled on the daemon, such as
+          apparmor, seccomp, SELinux, user-namespaces (userns), rootless and
+          no-new-privileges.
+
+          Additional configuration options for each security feature may
+          be present, and are included as a comma-separated list of key/value
+          pairs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "name=apparmor"
+          - "name=seccomp,profile=default"
+          - "name=selinux"
+          - "name=userns"
+          - "name=rootless"
+      ProductLicense:
+        description: |
+          Reports a summary of the product license on the daemon.
+
+          If a commercial license has been applied to the daemon, information
+          such as number of nodes, and expiration are included.
+        type: "string"
+        example: "Community Engine"
+      DefaultAddressPools:
+        description: |
+          List of custom default address pools for local networks, which can be
+          specified in the daemon.json file or dockerd option.
+
+          Example: a Base "10.10.0.0/16" with Size 24 will define the set of 256
+          10.10.[0-255].0/24 address pools.
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Base:
+              description: "The network address in CIDR format"
+              type: "string"
+              example: "10.10.0.0/16"
+            Size:
+              description: "The network pool size"
+              type: "integer"
+              example: "24"
+      FirewallBackend:
+        $ref: "#/definitions/FirewallInfo"
+      DiscoveredDevices:
+        description: |
+          List of devices discovered by device drivers.
+
+          Each device includes information about its source driver, kind, name,
+          and additional driver-specific attributes.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceInfo"
+      Warnings:
+        description: |
+          List of warnings / informational messages about missing features, or
+          issues related to the daemon configuration.
+
+          These messages can be printed by the client as information to the user.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "WARNING: No memory limit support"
+      CDISpecDirs:
+        description: |
+          List of directories where (Container Device Interface) CDI
+          specifications are located.
+
+          These specifications define vendor-specific modifications to an OCI
+          runtime specification for a container being created.
+
+          An empty list indicates that CDI device injection is disabled.
+
+          Note that since using CDI device injection requires the daemon to have
+          experimental enabled. For non-experimental daemons an empty list will
+          always be returned.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/etc/cdi"
+          - "/var/run/cdi"
+      Containerd:
+        $ref: "#/definitions/ContainerdInfo"
+
+  ContainerdInfo:
+    description: |
+      Information for connecting to the containerd instance that is used by the daemon.
+      This is included for debugging purposes only.
+    type: "object"
+    x-nullable: true
+    properties:
+      Address:
+        description: "The address of the containerd socket."
+        type: "string"
+        example: "/run/containerd/containerd.sock"
+      Namespaces:
+        description: |
+          The namespaces that the daemon uses for running containers and
+          plugins in containerd. These namespaces can be configured in the
+          daemon configuration, and are considered to be used exclusively
+          by the daemon, Tampering with the containerd instance may cause
+          unexpected behavior.
+
+          As these namespaces are considered to be exclusively accessed
+          by the daemon, it is not recommended to change these values,
+          or to change them to a value that is used by other systems,
+          such as cri-containerd.
+        type: "object"
+        properties:
+          Containers:
+            description: |
+              The default containerd namespace used for containers managed
+              by the daemon.
+
+              The default namespace for containers is "moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "moby"
+            example: "moby"
+          Plugins:
+            description: |
+              The default containerd namespace used for plugins managed by
+              the daemon.
+
+              The default namespace for plugins is "plugins.moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "plugins.moby"
+            example: "plugins.moby"
+
+  FirewallInfo:
+    description: |
+      Information about the daemon's firewalling configuration.
+
+      This field is currently only used on Linux, and omitted on other platforms.
+    type: "object"
+    x-nullable: true
+    properties:
+      Driver:
+        description: |
+          The name of the firewall backend driver.
+        type: "string"
+        example: "nftables"
+      Info:
+        description: |
+          Information about the firewall backend, provided as
+          "label" / "value" pairs.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["ReloadedAt", "2025-01-01T00:00:00Z"]
+
+  # PluginsInfo is a temp struct holding Plugins name
+  # registered with docker daemon. It is used by Info struct
+  PluginsInfo:
+    description: |
+      Available plugins per type.
+
+      <p><br /></p>
+
+      > **Note**: Only unmanaged (V1) plugins are included in this list.
+      > V1 plugins are "lazily" loaded, and are not returned in this list
+      > if there is no resource using the plugin.
+    type: "object"
+    properties:
+      Volume:
+        description: "Names of available volume-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["local"]
+      Network:
+        description: "Names of available network-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["bridge", "host", "ipvlan", "macvlan", "null", "overlay"]
+      Authorization:
+        description: "Names of available authorization plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["img-authz-plugin", "hbm"]
+      Log:
+        description: "Names of available logging-drivers, and logging-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["awslogs", "fluentd", "gcplogs", "gelf", "journald", "json-file", "splunk", "syslog"]
+
+
+  RegistryServiceConfig:
+    description: |
+      RegistryServiceConfig stores daemon registry services configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      InsecureRegistryCIDRs:
+        description: |
+          List of IP ranges of insecure registries, using the CIDR syntax
+          ([RFC 4632](https://tools.ietf.org/html/4632)). Insecure registries
+          accept un-encrypted (HTTP) and/or untrusted (HTTPS with certificates
+          from unknown CAs) communication.
+
+          By default, local registries (`::1/128` and `127.0.0.0/8`) are configured as
+          insecure. All other registries are secure. Communicating with an
+          insecure registry is not possible if the daemon assumes that registry
+          is secure.
+
+          This configuration override this behavior, insecure communication with
+          registries whose resolved IP address is within the subnet described by
+          the CIDR syntax.
+
+          Registries can also be marked insecure by hostname. Those registries
+          are listed under `IndexConfigs` and have their `Secure` field set to
+          `false`.
+
+          > **Warning**: Using this option can be useful when running a local
+          > registry, but introduces security vulnerabilities. This option
+          > should therefore ONLY be used for testing purposes. For increased
+          > security, users should add their CA to their system's list of trusted
+          > CAs instead of enabling this option.
+        type: "array"
+        items:
+          type: "string"
+        example: ["::1/128", "127.0.0.0/8"]
+      IndexConfigs:
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/IndexInfo"
+        example:
+          "127.0.0.1:5000":
+            "Name": "127.0.0.1:5000"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "[2001:db8:a0b:12f0::1]:80":
+            "Name": "[2001:db8:a0b:12f0::1]:80"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "docker.io":
+            Name: "docker.io"
+            Mirrors: ["https://hub-mirror.corp.example.com:5000/"]
+            Secure: true
+            Official: true
+          "registry.internal.corp.example.com:3000":
+            Name: "registry.internal.corp.example.com:3000"
+            Mirrors: []
+            Secure: false
+            Official: false
+      Mirrors:
+        description: |
+          List of registry URLs that act as a mirror for the official
+          (`docker.io`) registry.
+
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://[2001:db8:a0b:12f0::1]/"
+
+  IndexInfo:
+    description:
+      IndexInfo contains information about a registry.
+    type: "object"
+    x-nullable: true
+    properties:
+      Name:
+        description: |
+          Name of the registry, such as "docker.io".
+        type: "string"
+        example: "docker.io"
+      Mirrors:
+        description: |
+          List of mirrors, expressed as URIs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://registry-2.docker.io/"
+          - "https://registry-3.docker.io/"
+      Secure:
+        description: |
+          Indicates if the registry is part of the list of insecure
+          registries.
+
+          If `false`, the registry is insecure. Insecure registries accept
+          un-encrypted (HTTP) and/or untrusted (HTTPS with certificates from
+          unknown CAs) communication.
+
+          > **Warning**: Insecure registries can be useful when running a local
+          > registry. However, because its use creates security vulnerabilities
+          > it should ONLY be enabled for testing purposes. For increased
+          > security, users should add their CA to their system's list of
+          > trusted CAs instead of enabling this option.
+        type: "boolean"
+        example: true
+      Official:
+        description: |
+          Indicates whether this is an official registry (i.e., Docker Hub / docker.io)
+        type: "boolean"
+        example: true
+
+  Runtime:
+    description: |
+      Runtime describes an [OCI compliant](https://github.com/opencontainers/runtime-spec)
+      runtime.
+
+      The runtime is invoked by the daemon via the `containerd` daemon. OCI
+      runtimes act as an interface to the Linux kernel namespaces, cgroups,
+      and SELinux.
+    type: "object"
+    properties:
+      path:
+        description: |
+          Name and, optional, path, of the OCI executable binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "/usr/local/bin/my-oci-runtime"
+      runtimeArgs:
+        description: |
+          List of command-line arguments to pass to the runtime when invoked.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["--debug", "--systemd-cgroup=false"]
+      status:
+        description: |
+          Information specific to the runtime.
+
+          While this API specification does not define data provided by runtimes,
+          the following well-known properties may be provided by runtimes:
+
+          `org.opencontainers.runtime-spec.features`: features structure as defined
+          in the [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec/blob/main/features.md),
+          in a JSON string representation.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "org.opencontainers.runtime-spec.features": "{\"ociVersionMin\":\"1.0.0\",\"ociVersionMax\":\"1.1.0\",\"...\":\"...\"}"
+
+  Commit:
+    description: |
+      Commit holds the Git-commit (SHA1) that a binary was built from, as
+      reported in the version-string of external tools, such as `containerd`,
+      or `runC`.
+    type: "object"
+    properties:
+      ID:
+        description: "Actual commit ID of external tool."
+        type: "string"
+        example: "cfb82a876ecc11b5ca0977d1733adbe58599088a"
+
+  SwarmInfo:
+    description: |
+      Represents generic information about swarm.
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+        default: ""
+        example: "k67qz4598weg5unwwffg6z1m1"
+      NodeAddr:
+        description: |
+          IP address at which this node can be reached by other nodes in the
+          swarm.
+        type: "string"
+        default: ""
+        example: "10.0.0.46"
+      LocalNodeState:
+        $ref: "#/definitions/LocalNodeState"
+      ControlAvailable:
+        type: "boolean"
+        default: false
+        example: true
+      Error:
+        type: "string"
+        default: ""
+      RemoteManagers:
+        description: |
+          List of ID's and addresses of other managers in the swarm.
+        type: "array"
+        default: null
+        x-nullable: true
+        items:
+          $ref: "#/definitions/PeerNode"
+        example:
+          - NodeID: "71izy0goik036k48jg985xnds"
+            Addr: "10.0.0.158:2377"
+          - NodeID: "79y6h1o4gv8n120drcprv5nmc"
+            Addr: "10.0.0.159:2377"
+          - NodeID: "k67qz4598weg5unwwffg6z1m1"
+            Addr: "10.0.0.46:2377"
+      Nodes:
+        description: "Total number of nodes in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 4
+      Managers:
+        description: "Total number of managers in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 3
+      Cluster:
+        $ref: "#/definitions/ClusterInfo"
+
+  LocalNodeState:
+    description: "Current local status of this node."
+    type: "string"
+    default: ""
+    enum:
+      - ""
+      - "inactive"
+      - "pending"
+      - "active"
+      - "error"
+      - "locked"
+    example: "active"
+
+  PeerNode:
+    description: "Represents a peer-node in the swarm"
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+      Addr:
+        description: |
+          IP address and ports at which this node can be reached.
+        type: "string"
+
+  NetworkAttachmentConfig:
+    description: |
+      Specifies how a service should be attached to a particular network.
+    type: "object"
+    properties:
+      Target:
+        description: |
+          The target network for attachment. Must be a network name or ID.
+        type: "string"
+      Aliases:
+        description: |
+          Discoverable alternate names for the service on this network.
+        type: "array"
+        items:
+          type: "string"
+      DriverOpts:
+        description: |
+          Driver attachment options for the network target.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  EventActor:
+    description: |
+      Actor describes something that generates events, like a container, network,
+      or a volume.
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the object emitting the event"
+        type: "string"
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Attributes:
+        description: |
+          Various key/value attributes of the object, depending on its type.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-label-value"
+          image: "alpine:latest"
+          name: "my-container"
+
+  EventMessage:
+    description: |
+      EventMessage represents the information an event contains.
+    type: "object"
+    title: "SystemEventsResponse"
+    properties:
+      Type:
+        description: "The type of object emitting the event"
+        type: "string"
+        enum: ["builder", "config", "container", "daemon", "image", "network", "node", "plugin", "secret", "service", "volume"]
+        example: "container"
+      Action:
+        description: "The type of event"
+        type: "string"
+        example: "create"
+      Actor:
+        $ref: "#/definitions/EventActor"
+      scope:
+        description: |
+          Scope of the event. Engine events are `local` scope. Cluster (Swarm)
+          events are `swarm` scope.
+        type: "string"
+        enum: ["local", "swarm"]
+      time:
+        description: "Timestamp of event"
+        type: "integer"
+        format: "int64"
+        example: 1629574695
+      timeNano:
+        description: "Timestamp of event, with nanosecond accuracy"
+        type: "integer"
+        format: "int64"
+        example: 1629574695515050031
+
+  OCIDescriptor:
+    type: "object"
+    x-go-name: Descriptor
+    description: |
+      A descriptor struct containing digest, media type, and size, as defined in
+      the [OCI Content Descriptors Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/descriptor.md).
+    properties:
+      mediaType:
+        description: |
+          The media type of the object this schema refers to.
+        type: "string"
+        example: "application/vnd.oci.image.manifest.v1+json"
+      digest:
+        description: |
+          The digest of the targeted content.
+        type: "string"
+        example: "sha256:c0537ff6a5218ef531ece93d4984efc99bbf3f7497c0a7726c88e2bb7584dc96"
+      size:
+        description: |
+          The size in bytes of the blob.
+        type: "integer"
+        format: "int64"
+        example: 424
+      urls:
+        description: |-
+          List of URLs from which this object MAY be downloaded.
+        type: "array"
+        items:
+          type: "string"
+          format: "uri"
+        x-nullable: true
+      annotations:
+        description: |-
+          Arbitrary metadata relating to the targeted content.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "com.docker.official-images.bashbrew.arch": "amd64"
+          "org.opencontainers.image.base.digest": "sha256:0d0ef5c914d3ea700147da1bd050c59edb8bb12ca312f3800b29d7c8087eabd8"
+          "org.opencontainers.image.base.name": "scratch"
+          "org.opencontainers.image.created": "2025-01-27T00:00:00Z"
+          "org.opencontainers.image.revision": "9fabb4bad5138435b01857e2fe9363e2dc5f6a79"
+          "org.opencontainers.image.source": "https://git.launchpad.net/cloud-images/+oci/ubuntu-base"
+          "org.opencontainers.image.url": "https://hub.docker.com/_/ubuntu"
+          "org.opencontainers.image.version": "24.04"
+      data:
+        type: string
+        x-nullable: true
+        description: |-
+          Data is an embedding of the targeted content. This is encoded as a base64
+          string when marshalled to JSON (automatically, by encoding/json). If
+          present, Data can be used directly to avoid fetching the targeted content.
+        example: null
+      platform:
+        $ref: "#/definitions/OCIPlatform"
+      artifactType:
+        description: |-
+          ArtifactType is the IANA media type of this artifact.
+        type: "string"
+        x-nullable: true
+        example: null
+
+  OCIPlatform:
+    type: "object"
+    x-go-name: Platform
+    x-nullable: true
+    description: |
+      Describes the platform which the image in the manifest runs on, as defined
+      in the [OCI Image Index Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/image-index.md).
+    properties:
+      architecture:
+        description: |
+          The CPU architecture, for example `amd64` or `ppc64`.
+        type: "string"
+        example: "arm"
+      os:
+        description: |
+          The operating system, for example `linux` or `windows`.
+        type: "string"
+        example: "windows"
+      os.version:
+        description: |
+          Optional field specifying the operating system version, for example on
+          Windows `10.0.19041.1165`.
+        type: "string"
+        example: "10.0.19041.1165"
+      os.features:
+        description: |
+          Optional field specifying an array of strings, each listing a required
+          OS feature (for example on Windows `win32k`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "win32k"
+      variant:
+        description: |
+          Optional field specifying a variant of the CPU, for example `v7` to
+          specify ARMv7 when architecture is `arm`.
+        type: "string"
+        example: "v7"
+
+  DistributionInspect:
+    type: "object"
+    x-go-name: DistributionInspect
+    title: "DistributionInspectResponse"
+    required: [Descriptor, Platforms]
+    description: |
+      Describes the result obtained from contacting the registry to retrieve
+      image metadata.
+    properties:
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Platforms:
+        type: "array"
+        description: |
+          An array containing all platforms supported by the image.
+        items:
+          $ref: "#/definitions/OCIPlatform"
+
+  ClusterVolume:
+    type: "object"
+    description: |
+      Options and information specific to, and only present on, Swarm CSI
+      cluster volumes.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          The Swarm ID of this volume. Because cluster volumes are Swarm
+          objects, they have an ID, unlike non-cluster volumes. This ID can
+          be used to refer to the Volume instead of the name.
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+      Info:
+        type: "object"
+        description: |
+          Information about the global status of the volume.
+        properties:
+          CapacityBytes:
+            type: "integer"
+            format: "int64"
+            description: |
+              The capacity of the volume in bytes. A value of 0 indicates that
+              the capacity is unknown.
+          VolumeContext:
+            type: "object"
+            description: |
+              A map of strings to strings returned from the storage plugin when
+              the volume is created.
+            additionalProperties:
+              type: "string"
+          VolumeID:
+            type: "string"
+            description: |
+              The ID of the volume as returned by the CSI storage plugin. This
+              is distinct from the volume's ID as provided by Docker. This ID
+              is never used by the user when communicating with Docker to refer
+              to this volume. If the ID is blank, then the Volume has not been
+              successfully created in the plugin yet.
+          AccessibleTopology:
+            type: "array"
+            description: |
+              The topology this volume is actually accessible from.
+            items:
+              $ref: "#/definitions/Topology"
+      PublishStatus:
+        type: "array"
+        description: |
+          The status of the volume as it pertains to its publishing and use on
+          specific nodes
+        items:
+          type: "object"
+          properties:
+            NodeID:
+              type: "string"
+              description: |
+                The ID of the Swarm node the volume is published on.
+            State:
+              type: "string"
+              description: |
+                The published state of the volume.
+                * `pending-publish` The volume should be published to this node, but the call to the controller plugin to do so has not yet been successfully completed.
+                * `published` The volume is published successfully to the node.
+                * `pending-node-unpublish` The volume should be unpublished from the node, and the manager is awaiting confirmation from the worker that it has done so.
+                * `pending-controller-unpublish` The volume is successfully unpublished from the node, but has not yet been successfully unpublished on the controller.
+              enum:
+                - "pending-publish"
+                - "published"
+                - "pending-node-unpublish"
+                - "pending-controller-unpublish"
+            PublishContext:
+              type: "object"
+              description: |
+                A map of strings to strings returned by the CSI controller
+                plugin when a volume is published.
+              additionalProperties:
+                type: "string"
+
+  ClusterVolumeSpec:
+    type: "object"
+    description: |
+      Cluster-specific options used to create the volume.
+    properties:
+      Group:
+        type: "string"
+        description: |
+          Group defines the volume group of this volume. Volumes belonging to
+          the same group can be referred to by group name when creating
+          Services.  Referring to a volume by group instructs Swarm to treat
+          volumes in that group interchangeably for the purpose of scheduling.
+          Volumes with an empty string for a group technically all belong to
+          the same, emptystring group.
+      AccessMode:
+        type: "object"
+        description: |
+          Defines how the volume is used by tasks.
+        properties:
+          Scope:
+            type: "string"
+            description: |
+              The set of nodes this volume can be used on at one time.
+              - `single` The volume may only be scheduled to one node at a time.
+              - `multi` the volume may be scheduled to any supported number of nodes at a time.
+            default: "single"
+            enum: ["single", "multi"]
+            x-nullable: false
+          Sharing:
+            type: "string"
+            description: |
+              The number and way that different tasks can use this volume
+              at one time.
+              - `none` The volume may only be used by one task at a time.
+              - `readonly` The volume may be used by any number of tasks, but they all must mount the volume as readonly
+              - `onewriter` The volume may be used by any number of tasks, but only one may mount it as read/write.
+              - `all` The volume may have any number of readers and writers.
+            default: "none"
+            enum: ["none", "readonly", "onewriter", "all"]
+            x-nullable: false
+          MountVolume:
+            type: "object"
+            description: |
+              Options for using this volume as a Mount-type volume.
+
+                  Either MountVolume or BlockVolume, but not both, must be
+                  present.
+                properties:
+                  FsType:
+                    type: "string"
+                    description: |
+                      Specifies the filesystem type for the mount volume.
+                      Optional.
+                  MountFlags:
+                    type: "array"
+                    description: |
+                      Flags to pass when mounting the volume. Optional.
+                    items:
+                      type: "string"
+              BlockVolume:
+                type: "object"
+                description: |
+                  Options for using this volume as a Block-type volume.
+                  Intentionally empty.
+          Secrets:
+            type: "array"
+            description: |
+              Swarm Secrets that are passed to the CSI storage plugin when
+              operating on this volume.
+            items:
+              type: "object"
+              description: |
+                One cluster volume secret entry. Defines a key-value pair that
+                is passed to the plugin.
+              properties:
+                Key:
+                  type: "string"
+                  description: |
+                    Key is the name of the key of the key-value pair passed to
+                    the plugin.
+                Secret:
+                  type: "string"
+                  description: |
+                    Secret is the swarm Secret object from which to read data.
+                    This can be a Secret name or ID. The Secret data is
+                    retrieved by swarm and used as the value of the key-value
+                    pair passed to the plugin.
+          AccessibilityRequirements:
+            type: "object"
+            description: |
+              Requirements for the accessible topology of the volume. These
+              fields are optional. For an in-depth description of what these
+              fields mean, see the CSI specification.
+            properties:
+              Requisite:
+                type: "array"
+                description: |
+                  A list of required topologies, at least one of which the
+                  volume must be accessible from.
+                items:
+                  $ref: "#/definitions/Topology"
+              Preferred:
+                type: "array"
+                description: |
+                  A list of topologies that the volume should attempt to be
+                  provisioned in.
+                items:
+                  $ref: "#/definitions/Topology"
+          CapacityRange:
+            type: "object"
+            description: |
+              The desired capacity that the volume should be created with. If
+              empty, the plugin will decide the capacity.
+            properties:
+              RequiredBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must be at least this big. The value of 0
+                  indicates an unspecified minimum
+              LimitBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must not be bigger than this. The value of 0
+                  indicates an unspecified maximum.
+          Availability:
+            type: "string"
+            description: |
+              The availability of the volume for use in tasks.
+              - `active` The volume is fully available for scheduling on the cluster
+              - `pause` No new workloads should use the volume, but existing workloads are not stopped.
+              - `drain` All workloads using this volume should be stopped and rescheduled, and no new ones should be started.
+            default: "active"
+            x-nullable: false
+            enum:
+              - "active"
+              - "pause"
+              - "drain"
+
+  Topology:
+    description: |
+      A map of topological domains to topological segments. For in depth
+      details, see documentation for the Topology object in the CSI
+      specification.
+    type: "object"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  ImageManifestSummary:
+    x-go-name: "ManifestSummary"
+    description: |
+      ImageManifestSummary represents a summary of an image manifest.
+    type: "object"
+    required: ["ID", "Descriptor", "Available", "Size", "Kind"]
+    properties:
+      ID:
+        description: |
+          ID is the content-addressable ID of an image and is the same as the
+          digest of the image manifest.
+        type: "string"
+        example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Available:
+        description: Indicates whether all the child content (image config, layers) is fully available locally.
+        type: "boolean"
+        example: true
+      Size:
+        type: "object"
+        x-nullable: false
+        required: ["Content", "Total"]
+        properties:
+          Total:
+            type: "integer"
+            format: "int64"
+            example: 8213251
+            description: |
+              Total is the total size (in bytes) of all the locally present
+              data (both distributable and non-distributable) that's related to
+              this manifest and its children.
+              This equal to the sum of [Content] size AND all the sizes in the
+              [Size] struct present in the Kind-specific data struct.
+              For example, for an image kind (Kind == "image")
+              this would include the size of the image content and unpacked
+              image snapshots ([Size.Content] + [ImageData.Size.Unpacked]).
+          Content:
+            description: |
+              Content is the size (in bytes) of all the locally present
+              content in the content store (e.g. image config, layers)
+              referenced by this manifest and its children.
+              This only includes blobs in the content store.
+            type: "integer"
+            format: "int64"
+            example: 3987495
+      Kind:
+        type: "string"
+        example: "image"
+        enum:
+          - "image"
+          - "attestation"
+          - "unknown"
+        description: |
+          The kind of the manifest.
+
+          kind         | description
+          -------------|-----------------------------------------------------------
+          image        | Image manifest that can be used to start a container.
+          attestation  | Attestation manifest produced by the Buildkit builder for a specific image manifest.
+      ImageData:
+        description: |
+          The image data for the image manifest.
+          This field is only populated when Kind is "image".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["Platform", "Containers", "Size", "UnpackedSize"]
+        properties:
+          Platform:
+            $ref: "#/definitions/OCIPlatform"
+            description: |
+              OCI platform of the image. This will be the platform specified in the
+              manifest descriptor from the index/manifest list.
+              If it's not available, it will be obtained from the image config.
+          Containers:
+            description: |
+              The IDs of the containers that are using this image.
+            type: "array"
+            items:
+              type: "string"
+            example: ["ede54ee1fda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c7430", "abadbce344c096744d8d6071a90d474d28af8f1034b5ea9fb03c3f4bfc6d005e"]
+          Size:
+            type: "object"
+            x-nullable: false
+            required: ["Unpacked"]
+            properties:
+              Unpacked:
+                type: "integer"
+                format: "int64"
+                example: 3987495
+                description: |
+                  Unpacked is the size (in bytes) of the locally unpacked
+                  (uncompressed) image content that's directly usable by the containers
+                  running this image.
+                  It's independent of the distributable content - e.g.
+                  the image might still have an unpacked data that's still used by
+                  some container even when the distributable/compressed content is
+                  already gone.
+      AttestationData:
+        description: |
+          The image data for the attestation manifest.
+          This field is only populated when Kind is "attestation".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["For"]
+        properties:
+          For:
+            description: |
+              The digest of the image manifest that this attestation is for.
+            type: "string"
+            example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+
+paths:
+  /containers/json:
+    get:
+      summary: "List containers"
+      description: |
+        Returns a list of containers. For details on the format, see the
+        [inspect endpoint](#operation/ContainerInspect).
+
+        Note that it uses a different, smaller representation of a container
+        than inspecting a single container. For example, the list of linked
+        containers is not propagated .
+      operationId: "ContainerList"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: |
+            Return all containers. By default, only running containers are shown.
+          type: "boolean"
+          default: false
+        - name: "limit"
+          in: "query"
+          description: |
+            Return this number of most recently created containers, including
+            non-running ones.
+          type: "integer"
+        - name: "size"
+          in: "query"
+          description: |
+            Return the size of container as fields `SizeRw` and `SizeRootFs`.
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the container list, encoded as JSON (a
+            `map[string][]string`). For example, `{"status": ["paused"]}` will
+            only return paused containers.
+
+            Available filters:
+
+            - `ancestor`=(`<image-name>[:<tag>]`, `<image id>`, or `<image@digest>`)
+            - `before`=(`<container id>` or `<container name>`)
+            - `expose`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `exited=<int>` containers with exit code of `<int>`
+            - `health`=(`starting`|`healthy`|`unhealthy`|`none`)
+            - `id=<ID>` a container's ID
+            - `isolation=`(`default`|`process`|`hyperv`) (Windows daemon only)
+            - `is-task=`(`true`|`false`)
+            - `label=key` or `label="key=value"` of a container label
+            - `name=<name>` a container's name
+            - `network`=(`<network id>` or `<network name>`)
+            - `publish`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `since`=(`<container id>` or `<container name>`)
+            - `status=`(`created`|`restarting`|`running`|`removing`|`paused`|`exited`|`dead`)
+            - `volume`=(`<volume name>` or `<mount point destination>`)
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ContainerSummary"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/create:
+    post:
+      summary: "Create a container"
+      operationId: "ContainerCreate"
+      consumes:
+        - "application/json"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            Assign the specified name to the container. Must match
+            `/?[a-zA-Z0-9][a-zA-Z0-9_.-]+`.
+          type: "string"
+          pattern: "^/?[a-zA-Z0-9][a-zA-Z0-9_.-]+$"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format `os[/arch[/variant]]` used for image lookup.
+
+            When specified, the daemon checks if the requested image is present
+            in the local image cache with the given OS and Architecture, and
+            otherwise returns a `404` status.
+
+            If the option is not set, the host's native OS and Architecture are
+            used to look up the image in the image cache. However, if no platform
+            is passed and the given image does exist in the local image cache,
+            but its OS or architecture does not match, the container is created
+            with the available image, and a warning is added to the `Warnings`
+            field in the response, for example;
+
+                WARNING: The requested image's platform (linux/arm64/v8) does not
+                         match the detected host platform (linux/amd64) and no
+                         specific platform was requested
+
+          type: "string"
+          default: ""
+        - name: "body"
+          in: "body"
+          description: "Container to create"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ContainerConfig"
+              - type: "object"
+                properties:
+                  HostConfig:
+                    $ref: "#/definitions/HostConfig"
+                  NetworkingConfig:
+                    $ref: "#/definitions/NetworkingConfig"
+            example:
+              Hostname: ""
+              Domainname: ""
+              User: ""
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              Tty: false
+              OpenStdin: false
+              StdinOnce: false
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+              Cmd:
+                - "date"
+              Entrypoint: ""
+              Image: "ubuntu"
+              Labels:
+                com.example.vendor: "Acme"
+                com.example.license: "GPL"
+                com.example.version: "1.0"
+              Volumes:
+                /volumes/data: {}
+              WorkingDir: ""
+              NetworkDisabled: false
+              MacAddress: "12:34:56:78:9a:bc"
+              ExposedPorts:
+                22/tcp: {}
+              StopSignal: "SIGTERM"
+              StopTimeout: 10
+              HostConfig:
+                Binds:
+                  - "/tmp:/tmp"
+                Links:
+                  - "redis3:redis"
+                Memory: 0
+                MemorySwap: 0
+                MemoryReservation: 0
+                NanoCpus: 500000
+                CpuPercent: 80
+                CpuShares: 512
+                CpuPeriod: 100000
+                CpuRealtimePeriod: 1000000
+                CpuRealtimeRuntime: 10000
+                CpuQuota: 50000
+                CpusetCpus: "0,1"
+                CpusetMems: "0,1"
+                MaximumIOps: 0
+                MaximumIOBps: 0
+                BlkioWeight: 300
+                BlkioWeightDevice:
+                  - {}
+                BlkioDeviceReadBps:
+                  - {}
+                BlkioDeviceReadIOps:
+                  - {}
+                BlkioDeviceWriteBps:
+                  - {}
+                BlkioDeviceWriteIOps:
+                  - {}
+                DeviceRequests:
+                  - Driver: "nvidia"
+                    Count: -1
+                    DeviceIDs": ["0", "1", "GPU-fef8089b-4820-abfc-e83e-94318197576e"]
+                    Capabilities: [["gpu", "nvidia", "compute"]]
+                    Options:
+                      property1: "string"
+                      property2: "string"
+                MemorySwappiness: 60
+                OomKillDisable: false
+                OomScoreAdj: 500
+                PidMode: ""
+                PidsLimit: 0
+                PortBindings:
+                  22/tcp:
+                    - HostPort: "11022"
+                PublishAllPorts: false
+                Privileged: false
+                ReadonlyRootfs: false
+                Dns:
+                  - "8.8.8.8"
+                DnsOptions:
+                  - ""
+                DnsSearch:
+                  - ""
+                VolumesFrom:
+                  - "parent"
+                  - "other:ro"
+                CapAdd:
+                  - "NET_ADMIN"
+                CapDrop:
+                  - "MKNOD"
+                GroupAdd:
+                  - "newgroup"
+                RestartPolicy:
+                  Name: ""
+                  MaximumRetryCount: 0
+                AutoRemove: true
+                NetworkMode: "bridge"
+                Devices: []
+                Ulimits:
+                  - {}
+                LogConfig:
+                  Type: "json-file"
+                  Config: {}
+                SecurityOpt: []
+                StorageOpt: {}
+                CgroupParent: ""
+                VolumeDriver: ""
+                ShmSize: 67108864
+              NetworkingConfig:
+                EndpointsConfig:
+                  isolated_nw:
+                    IPAMConfig:
+                      IPv4Address: "172.20.30.33"
+                      IPv6Address: "2001:db8:abcd::3033"
+                      LinkLocalIPs:
+                        - "169.254.34.68"
+                        - "fe80::3468"
+                    Links:
+                      - "container_1"
+                      - "container_2"
+                    Aliases:
+                      - "server_x"
+                      - "server_y"
+                  database_nw: {}
+
+          required: true
+      responses:
+        201:
+          description: "Container created successfully"
+          schema:
+            $ref: "#/definitions/ContainerCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/{id}/json:
+    get:
+      summary: "Inspect a container"
+      description: "Return low-level information about a container."
+      operationId: "ContainerInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerInspectResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "size"
+          in: "query"
+          type: "boolean"
+          default: false
+          description: "Return the size of container as fields `SizeRw` and `SizeRootFs`"
+      tags: ["Container"]
+  /containers/{id}/top:
+    get:
+      summary: "List processes running inside a container"
+      description: |
+        On Unix systems, this is done by running the `ps` command. This endpoint
+        is not supported on Windows.
+      operationId: "ContainerTop"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerTopResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "ps_args"
+          in: "query"
+          description: "The arguments to pass to `ps`. For example, `aux`"
+          type: "string"
+          default: "-ef"
+      tags: ["Container"]
+  /containers/{id}/logs:
+    get:
+      summary: "Get container logs"
+      description: |
+        Get `stdout` and `stderr` logs from a container.
+
+        Note: This endpoint works only for containers with the `json-file` or
+        `journald` logging driver.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ContainerLogs"
+      responses:
+        200:
+          description: |
+            logs returned as a stream in response body.
+            For the stream format, [see the documentation for the attach endpoint](#operation/ContainerAttach).
+            Note that unlike the attach endpoint, the logs endpoint does not
+            upgrade the connection and does not set Content-Type.
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "until"
+          in: "query"
+          description: "Only return logs before this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Container"]
+  /containers/{id}/changes:
+    get:
+      summary: "Get changes on a container’s filesystem"
+      description: |
+        Returns which files in a container's filesystem have been added, deleted,
+        or modified. The `Kind` of modification can be one of:
+
+        - `0`: Modified ("C")
+        - `1`: Added ("A")
+        - `2`: Deleted ("D")
+      operationId: "ContainerChanges"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The list of changes"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/FilesystemChange"
+          examples:
+            application/json:
+              - Path: "/dev"
+                Kind: 0
+              - Path: "/dev/kmsg"
+                Kind: 1
+              - Path: "/test"
+                Kind: 1
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/export:
+    get:
+      summary: "Export a container"
+      description: "Export the contents of a container as a tarball."
+      operationId: "ContainerExport"
+      produces:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stats:
+    get:
+      summary: "Get container stats based on resource usage"
+      description: |
+        This endpoint returns a live stream of a container’s resource usage
+        statistics.
+
+        The `precpu_stats` is the CPU statistic of the *previous* read, and is
+        used to calculate the CPU usage percentage. It is not an exact copy
+        of the `cpu_stats` field.
+
+        If either `precpu_stats.online_cpus` or `cpu_stats.online_cpus` is
+        nil then for compatibility with older daemons the length of the
+        corresponding `cpu_usage.percpu_usage` array should be used.
+
+        On a cgroup v2 host, the following fields are not set
+        * `blkio_stats`: all fields other than `io_service_bytes_recursive`
+        * `cpu_stats`: `cpu_usage.percpu_usage`
+        * `memory_stats`: `max_usage` and `failcnt`
+        Also, `memory_stats.stats` fields are incompatible with cgroup v1.
+
+        To calculate the values shown by the `stats` command of the docker cli tool
+        the following formulas can be used:
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
+        * available_memory = `memory_stats.limit`
+        * Memory usage % = `(used_memory / available_memory) * 100.0`
+        * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
+        * system_cpu_delta = `cpu_stats.system_cpu_usage - precpu_stats.system_cpu_usage`
+        * number_cpus = `length(cpu_stats.cpu_usage.percpu_usage)` or `cpu_stats.online_cpus`
+        * CPU usage % = `(cpu_delta / system_cpu_delta) * number_cpus * 100.0`
+      operationId: "ContainerStats"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerStatsResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream the output. If false, the stats will be output once and then
+            it will disconnect.
+          type: "boolean"
+          default: true
+        - name: "one-shot"
+          in: "query"
+          description: |
+            Only get a single stat instead of waiting for 2 cycles. Must be used
+            with `stream=false`.
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/resize:
+    post:
+      summary: "Resize a container TTY"
+      description: "Resize the TTY for a container."
+      operationId: "ContainerResize"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "cannot resize container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/start:
+    post:
+      summary: "Start a container"
+      operationId: "ContainerStart"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already started"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container. Format is a
+            single character `[a-Z]` or `ctrl-<value>` where `<value>` is one
+            of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stop:
+    post:
+      summary: "Stop a container"
+      operationId: "ContainerStop"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already stopped"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/restart:
+    post:
+      summary: "Restart a container"
+      operationId: "ContainerRestart"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/kill:
+    post:
+      summary: "Kill a container"
+      description: |
+        Send a POSIX signal to a container, defaulting to killing to the
+        container.
+      operationId: "ContainerKill"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is not running"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "Container d37cde0fe4ad63c3a7252023b2f9800282894247d145cb5933ddf6e52cc03a28 is not running"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+          default: "SIGKILL"
+      tags: ["Container"]
+  /containers/{id}/update:
+    post:
+      summary: "Update a container"
+      description: |
+        Change various configuration options of a container without having to
+        recreate it.
+      operationId: "ContainerUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has been updated."
+          schema:
+            $ref: "#/definitions/ContainerUpdateResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "update"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/Resources"
+              - type: "object"
+                properties:
+                  RestartPolicy:
+                    $ref: "#/definitions/RestartPolicy"
+            example:
+              BlkioWeight: 300
+              CpuShares: 512
+              CpuPeriod: 100000
+              CpuQuota: 50000
+              CpuRealtimePeriod: 1000000
+              CpuRealtimeRuntime: 10000
+              CpusetCpus: "0,1"
+              CpusetMems: "0"
+              Memory: 314572800
+              MemorySwap: 514288000
+              MemoryReservation: 209715200
+              RestartPolicy:
+                MaximumRetryCount: 4
+                Name: "on-failure"
+      tags: ["Container"]
+  /containers/{id}/rename:
+    post:
+      summary: "Rename a container"
+      operationId: "ContainerRename"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "name already in use"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "name"
+          in: "query"
+          required: true
+          description: "New name for the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/pause:
+    post:
+      summary: "Pause a container"
+      description: |
+        Use the freezer cgroup to suspend all processes in a container.
+
+        Traditionally, when suspending a process the `SIGSTOP` signal is used,
+        which is observable by the process being suspended. With the freezer
+        cgroup the process is unaware, and unable to capture, that it is being
+        suspended, and subsequently resumed.
+      operationId: "ContainerPause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/unpause:
+    post:
+      summary: "Unpause a container"
+      description: "Resume a container which has been paused."
+      operationId: "ContainerUnpause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/attach:
+    post:
+      summary: "Attach to a container"
+      description: |
+        Attach to a container to read its output or send it input. You can attach
+        to the same container multiple times and you can reattach to containers
+        that have been detached.
+
+        Either the `stream` or `logs` parameter must be `true` for this endpoint
+        to do anything.
+
+        See the [documentation for the `docker attach` command](https://docs.docker.com/engine/reference/commandline/attach/)
+        for more details.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to transport `stdin`, `stdout`,
+        and `stderr` on the same socket.
+
+        This is the response from the daemon for an attach request:
+
+        ```
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        [STREAM]
+        ```
+
+        After the headers and two new lines, the TCP connection can now be used
+        for raw, bidirectional communication between the client and server.
+
+        To hint potential proxies about connection hijacking, the Docker client
+        can also optionally send connection upgrade headers.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /containers/16253994b7c4/attach?stream=1&stdout=1 HTTP/1.1
+        Upgrade: tcp
+        Connection: Upgrade
+        ```
+
+        The Docker daemon will respond with a `101 UPGRADED` response, and will
+        similarly follow with the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Content-Type: application/vnd.docker.raw-stream
+        Connection: Upgrade
+        Upgrade: tcp
+
+        [STREAM]
+        ```
+
+        ### Stream format
+
+        When the TTY setting is disabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the HTTP Content-Type header is set to application/vnd.docker.multiplexed-stream
+        and the stream over the hijacked connected is multiplexed to separate out
+        `stdout` and `stderr`. The stream consists of a series of frames, each
+        containing a header and a payload.
+
+        The header contains the information which the stream writes (`stdout` or
+        `stderr`). It also contains the size of the associated frame encoded in
+        the last four bytes (`uint32`).
+
+        It is encoded on the first eight bytes like this:
+
+        ```go
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+        ```
+
+        `STREAM_TYPE` can be:
+
+        - 0: `stdin` (is written on `stdout`)
+        - 1: `stdout`
+        - 2: `stderr`
+
+        `SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of the `uint32` size
+        encoded as big endian.
+
+        Following the header is the payload, which is the specified number of
+        bytes of `STREAM_TYPE`.
+
+        The simplest way to implement this protocol is the following:
+
+        1. Read 8 bytes.
+        2. Choose `stdout` or `stderr` depending on the first byte.
+        3. Extract the frame size from the last four bytes.
+        4. Read the extracted size and output it on the correct output.
+        5. Goto 1.
+
+        ### Stream format when using a TTY
+
+        When the TTY setting is enabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the stream is not multiplexed. The data exchanged over the hijacked
+        connection is simply the raw data from the process PTY and client's
+        `stdin`.
+
+      operationId: "ContainerAttach"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: |
+            Replay previous logs from the container.
+
+            This is useful for attaching to a container that has started and you
+            want to output everything since the container started.
+
+            If `stream` is also enabled, once all the previous output has been
+            returned, it will seamlessly transition into streaming current
+            output.
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream attached streams from the time the request was made onwards.
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/attach/ws:
+    get:
+      summary: "Attach to a container via a websocket"
+      operationId: "ContainerAttachWebsocket"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,`, or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: "Return logs"
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: "Return stream"
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/wait:
+    post:
+      summary: "Wait for a container"
+      description: "Block until a container stops, then returns the exit code."
+      operationId: "ContainerWait"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has exit."
+          schema:
+            $ref: "#/definitions/ContainerWaitResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "condition"
+          in: "query"
+          description: |
+            Wait until a container state reaches the given condition.
+
+            Defaults to `not-running` if omitted or empty.
+          type: "string"
+          enum:
+            - "not-running"
+            - "next-exit"
+            - "removed"
+          default: "not-running"
+      tags: ["Container"]
+  /containers/{id}:
+    delete:
+      summary: "Remove a container"
+      operationId: "ContainerDelete"
+      responses:
+        204:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: |
+                You cannot remove a running container: c2ada9df5af8. Stop the
+                container before attempting removal or force remove
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "v"
+          in: "query"
+          description: "Remove anonymous volumes associated with the container."
+          type: "boolean"
+          default: false
+        - name: "force"
+          in: "query"
+          description: "If the container is running, kill it before removing it."
+          type: "boolean"
+          default: false
+        - name: "link"
+          in: "query"
+          description: "Remove the specified link associated with the container."
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/archive:
+    head:
+      summary: "Get information about files in a container"
+      description: |
+        A response header `X-Docker-Container-Path-Stat` is returned, containing
+        a base64 - encoded JSON object with some filesystem header information
+        about the path.
+      operationId: "ContainerArchiveInfo"
+      responses:
+        200:
+          description: "no error"
+          headers:
+            X-Docker-Container-Path-Stat:
+              type: "string"
+              description: |
+                A base64 - encoded JSON object with some filesystem header
+                information about the path
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    get:
+      summary: "Get an archive of a filesystem resource in a container"
+      description: "Get a tar archive of a resource in the filesystem of container id."
+      operationId: "ContainerArchive"
+      produces: ["application/x-tar"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    put:
+      summary: "Extract an archive of files or folders to a directory in a container"
+      description: |
+        Upload a tar archive to be extracted to a path in the filesystem of container id.
+        `path` parameter is asserted to be a directory. If it exists as a file, 400 error
+        will be returned with message "not a directory".
+      operationId: "PutContainerArchive"
+      consumes: ["application/x-tar", "application/octet-stream"]
+      responses:
+        200:
+          description: "The content was extracted successfully"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "not a directory"
+        403:
+          description: "Permission denied, the volume or container rootfs is marked as read-only."
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such container or path does not exist inside the container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Path to a directory in the container to extract the archive’s contents into. "
+          type: "string"
+        - name: "noOverwriteDirNonDir"
+          in: "query"
+          description: |
+            If `1`, `true`, or `True` then it will be an error if unpacking the
+            given content would cause an existing directory to be replaced with
+            a non-directory and vice versa.
+          type: "string"
+        - name: "copyUIDGID"
+          in: "query"
+          description: |
+            If `1`, `true`, then it will copy UID/GID maps to the dest file or
+            dir
+          type: "string"
+        - name: "inputStream"
+          in: "body"
+          required: true
+          description: |
+            The input stream must be a tar archive compressed with one of the
+            following algorithms: `identity` (no compression), `gzip`, `bzip2`,
+            or `xz`.
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Container"]
+  /containers/prune:
+    post:
+      summary: "Delete stopped containers"
+      produces:
+        - "application/json"
+      operationId: "ContainerPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune containers created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune containers with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ContainerPruneResponse"
+            properties:
+              ContainersDeleted:
+                description: "Container IDs that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /images/json:
+    get:
+      summary: "List Images"
+      description: "Returns a list of images on the server. Note that it uses a different, smaller representation of an image than inspecting a single image."
+      operationId: "ImageList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "Summary image data for the images matching the query"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageSummary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: "Show all images. Only images from a final layer (no children) are shown by default."
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the images list.
+
+            Available filters:
+
+            - `before`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `dangling=true`
+            - `label=key` or `label="key=value"` of an image label
+            - `reference`=(`<image-name>[:<tag>]`)
+            - `since`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `until=<timestamp>`
+          type: "string"
+        - name: "shared-size"
+          in: "query"
+          description: "Compute and show shared size as a `SharedSize` field on each image."
+          type: "boolean"
+          default: false
+        - name: "digests"
+          in: "query"
+          description: "Show digest information as a `RepoDigests` field on each image."
+          type: "boolean"
+          default: false
+        - name: "manifests"
+          in: "query"
+          description: "Include `Manifests` in the image summary."
+          type: "boolean"
+          default: false
+      tags: ["Image"]
+  /build:
+    post:
+      summary: "Build an image"
+      description: |
+        Build an image from a tar archive with a `Dockerfile` in it.
+
+        The `Dockerfile` specifies how the image is built from the tar archive. It is typically in the archive's root, but can be at a different path or have a different name by specifying the `dockerfile` parameter. [See the `Dockerfile` reference for more information](https://docs.docker.com/engine/reference/builder/).
+
+        The Docker daemon performs a preliminary validation of the `Dockerfile` before starting the build, and returns an error if the syntax is incorrect. After that, each instruction is run one-by-one until the ID of the new image is output.
+
+        The build is canceled if the client drops the connection by quitting or being killed.
+      operationId: "ImageBuild"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "inputStream"
+          in: "body"
+          description: "A tar archive compressed with one of the following algorithms: identity (no compression), gzip, bzip2, xz."
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "dockerfile"
+          in: "query"
+          description: "Path within the build context to the `Dockerfile`. This is ignored if `remote` is specified and points to an external `Dockerfile`."
+          type: "string"
+          default: "Dockerfile"
+        - name: "t"
+          in: "query"
+          description: "A name and optional tag to apply to the image in the `name:tag` format. If you omit the tag the default `latest` value is assumed. You can provide several `t` parameters."
+          type: "string"
+        - name: "extrahosts"
+          in: "query"
+          description: "Extra hosts to add to /etc/hosts"
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: "A Git repository URI or HTTP/HTTPS context URI. If the URI points to a single text file, the file’s contents are placed into a file called `Dockerfile` and the image is built from that file. If the URI points to a tarball, the file is downloaded by the daemon and the contents therein used as the context for the build. If the URI points to a tarball and the `dockerfile` parameter is also specified, there must be a file with the corresponding path inside the tarball."
+          type: "string"
+        - name: "q"
+          in: "query"
+          description: "Suppress verbose build output."
+          type: "boolean"
+          default: false
+        - name: "nocache"
+          in: "query"
+          description: "Do not use the cache when building the image."
+          type: "boolean"
+          default: false
+        - name: "cachefrom"
+          in: "query"
+          description: "JSON array of images used for build cache resolution."
+          type: "string"
+        - name: "pull"
+          in: "query"
+          description: "Attempt to pull the image even if an older image exists locally."
+          type: "string"
+        - name: "rm"
+          in: "query"
+          description: "Remove intermediate containers after a successful build."
+          type: "boolean"
+          default: true
+        - name: "forcerm"
+          in: "query"
+          description: "Always remove intermediate containers, even upon failure."
+          type: "boolean"
+          default: false
+        - name: "memory"
+          in: "query"
+          description: "Set memory limit for build."
+          type: "integer"
+        - name: "memswap"
+          in: "query"
+          description: "Total memory (memory + swap). Set as `-1` to disable swap."
+          type: "integer"
+        - name: "cpushares"
+          in: "query"
+          description: "CPU shares (relative weight)."
+          type: "integer"
+        - name: "cpusetcpus"
+          in: "query"
+          description: "CPUs in which to allow execution (e.g., `0-3`, `0,1`)."
+          type: "string"
+        - name: "cpuperiod"
+          in: "query"
+          description: "The length of a CPU period in microseconds."
+          type: "integer"
+        - name: "cpuquota"
+          in: "query"
+          description: "Microseconds of CPU time that the container can get in a CPU period."
+          type: "integer"
+        - name: "buildargs"
+          in: "query"
+          description: >
+            JSON map of string pairs for build-time variables. Users pass these values at build-time. Docker
+            uses the buildargs as the environment context for commands run via the `Dockerfile` RUN
+            instruction, or for variable expansion in other `Dockerfile` instructions. This is not meant for
+            passing secret values.
+
+
+            For example, the build arg `FOO=bar` would become `{"FOO":"bar"}` in JSON. This would result in the
+            query parameter `buildargs={"FOO":"bar"}`. Note that `{"FOO":"bar"}` should be URI component encoded.
+
+
+            [Read more about the buildargs instruction.](https://docs.docker.com/engine/reference/builder/#arg)
+          type: "string"
+        - name: "shmsize"
+          in: "query"
+          description: "Size of `/dev/shm` in bytes. The size must be greater than 0. If omitted the system uses 64MB."
+          type: "integer"
+        - name: "squash"
+          in: "query"
+          description: "Squash the resulting images layers into a single layer. *(Experimental release only.)*"
+          type: "boolean"
+        - name: "labels"
+          in: "query"
+          description: "Arbitrary key/value labels to set on the image, as a JSON map of string pairs."
+          type: "string"
+        - name: "networkmode"
+          in: "query"
+          description: |
+            Sets the networking mode for the run commands during build. Supported
+            standard values are: `bridge`, `host`, `none`, and `container:<name|id>`.
+            Any other value is taken as a custom network's name or ID to which this
+            container should connect to.
+          type: "string"
+        - name: "Content-type"
+          in: "header"
+          type: "string"
+          enum:
+            - "application/x-tar"
+          default: "application/x-tar"
+        - name: "X-Registry-Config"
+          in: "header"
+          description: |
+            This is a base64-encoded JSON object with auth configurations for multiple registries that a build may refer to.
+
+            The key is a registry URL, and the value is an auth configuration object, [as described in the authentication section](#section/Authentication). For example:
+
+            ```
+            {
+              "docker.example.com": {
+                "username": "janedoe",
+                "password": "hunter2"
+              },
+              "https://index.docker.io/v1/": {
+                "username": "mobydock",
+                "password": "conta1n3rize14"
+              }
+            }
+            ```
+
+            Only the registry domain name (and port if not the default 443) are required. However, for legacy reasons, the Docker Hub registry must be specified with both a `https://` prefix and a `/v1/` suffix even though Docker will prefer to use the v2 registry API.
+          type: "string"
+        - name: "platform"
+          in: "query"
+          description: "Platform in the format os[/arch[/variant]]"
+          type: "string"
+          default: ""
+        - name: "target"
+          in: "query"
+          description: "Target build stage"
+          type: "string"
+          default: ""
+        - name: "outputs"
+          in: "query"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
+          type: "string"
+          default: ""
+        - name: "version"
+          in: "query"
+          type: "string"
+          default: "1"
+          enum: ["1", "2"]
+          description: |
+            Version of the builder backend to use.
+
+            - `1` is the first generation classic (deprecated) builder in the Docker daemon (default)
+            - `2` is [BuildKit](https://github.com/moby/buildkit)
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /build/prune:
+    post:
+      summary: "Delete builder cache"
+      produces:
+        - "application/json"
+      operationId: "BuildPrune"
+      parameters:
+        - name: "keep-storage"
+          in: "query"
+          description: |
+            Amount of disk space in bytes to keep for cache
+
+            > **Deprecated**: This parameter is deprecated and has been renamed to "reserved-space".
+            > It is kept for backward compatibility and will be removed in API v1.52.
+          type: "integer"
+          format: "int64"
+        - name: "reserved-space"
+          in: "query"
+          description: "Amount of disk space in bytes to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "max-used-space"
+          in: "query"
+          description: "Maximum amount of disk space allowed to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "min-free-space"
+          in: "query"
+          description: "Target amount of free disk space after pruning"
+          type: "integer"
+          format: "int64"
+        - name: "all"
+          in: "query"
+          type: "boolean"
+          description: "Remove all types of build cache"
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the list of build cache objects.
+
+            Available filters:
+
+            - `until=<timestamp>` remove cache older than `<timestamp>`. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon's local time.
+            - `id=<id>`
+            - `parent=<id>`
+            - `type=<string>`
+            - `description=<string>`
+            - `inuse`
+            - `shared`
+            - `private`
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "BuildPruneResponse"
+            properties:
+              CachesDeleted:
+                type: "array"
+                items:
+                  description: "ID of build cache object"
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /images/create:
+    post:
+      summary: "Create an image"
+      description: "Pull or import an image."
+      operationId: "ImageCreate"
+      consumes:
+        - "text/plain"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "repository does not exist or no read access"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "fromImage"
+          in: "query"
+          description: |
+            Name of the image to pull. If the name includes a tag or digest, specific behavior applies:
+
+            - If only `fromImage` includes a tag, that tag is used.
+            - If both `fromImage` and `tag` are provided, `tag` takes precedence.
+            - If `fromImage` includes a digest, the image is pulled by digest, and `tag` is ignored.
+            - If neither a tag nor digest is specified, all tags are pulled.
+          type: "string"
+        - name: "fromSrc"
+          in: "query"
+          description: "Source to import. The value may be a URL from which the image can be retrieved or `-` to read the image from the request body. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name given to an image when it is imported. The repo may include a tag. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag or digest. If empty when pulling an image, this causes all tags for the given image to be pulled."
+          type: "string"
+        - name: "message"
+          in: "query"
+          description: "Set commit message for imported image."
+          type: "string"
+        - name: "inputImage"
+          in: "body"
+          description: "Image content if the value `-` has been specified in fromSrc query parameter"
+          schema:
+            type: "string"
+          required: false
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "changes"
+          in: "query"
+          description: |
+            Apply `Dockerfile` instructions to the image that is created,
+            for example: `changes=ENV DEBUG=true`.
+            Note that `ENV DEBUG=true` should be URI component encoded.
+
+            Supported `Dockerfile` instructions:
+            `CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format os[/arch[/variant]].
+
+            When used in combination with the `fromImage` option, the daemon checks
+            if the given image is present in the local image cache with the given
+            OS and Architecture, and otherwise attempts to pull the image. If the
+            option is not set, the host's native OS and Architecture are used.
+            If the given image does not exist in the local image cache, the daemon
+            attempts to pull the image with the host's native OS and Architecture.
+            If the given image does exists in the local image cache, but its OS or
+            architecture does not match, a warning is produced.
+
+            When used with the `fromSrc` option to import an image from an archive,
+            this option sets the platform information for the imported image. If
+            the option is not set, the host's native OS and Architecture are used
+            for the imported image.
+          type: "string"
+          default: ""
+      tags: ["Image"]
+  /images/{name}/json:
+    get:
+      summary: "Inspect an image"
+      description: "Return low-level information about an image."
+      operationId: "ImageInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/ImageInspect"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+        - name: "manifests"
+          in: "query"
+          description: |-
+            Include Manifests in the image summary.
+
+            The `manifests` and `platform` options are mutually exclusive, and
+            an error is produced if both are set.
+          type: "boolean"
+          default: false
+          required: false
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |-
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show inspect. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            The `platform` and `manifests` options are mutually exclusive, and
+            an error is produced if both are set.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/history:
+    get:
+      summary: "Get the history of an image"
+      description: "Return parent layers of an image."
+      operationId: "ImageHistory"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "List of image layers"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageHistoryResponseItem"
+          examples:
+            application/json:
+              - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
+                Created: 1398108230
+                CreatedBy: "/bin/sh -c #(nop) ADD file:eb15dbd63394e063b805a3c32ca7bf0266ef64676d5a6fab4801f2e81e2a5148 in /"
+                Tags:
+                  - "ubuntu:lucid"
+                  - "ubuntu:10.04"
+                Size: 182964289
+                Comment: ""
+              - Id: "6cfa4d1f33fb861d4d114f43b25abd0ac737509268065cdfd69d544a59c85ab8"
+                Created: 1398108222
+                CreatedBy: "/bin/sh -c #(nop) MAINTAINER Tianon Gravi <admwiggin@gmail.com> - mkimage-debootstrap.sh -i iproute,iputils-ping,ubuntu-minimal -t lucid.tar.xz lucid http://archive.ubuntu.com/ubuntu/"
+                Tags: []
+                Size: 0
+                Comment: ""
+              - Id: "511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158"
+                Created: 1371157430
+                CreatedBy: ""
+                Tags:
+                  - "scratch12:latest"
+                  - "scratch:latest"
+                Size: 0
+                Comment: "Imported from -"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show the history for. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/push:
+    post:
+      summary: "Push an image"
+      description: |
+        Push an image to a registry.
+
+        If you wish to push an image on to a private registry, that image must
+        already have a tag which references the registry. For example,
+        `registry.example.com/myimage:latest`.
+
+        The push is cancelled if the HTTP connection is closed.
+      operationId: "ImagePush"
+      consumes:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            Name of the image to push. For example, `registry.example.com/myimage`.
+            The image must be present in the local image store with the same name.
+
+            The name should be provided without tag; if a tag is provided, it
+            is ignored. For example, `registry.example.com/myimage:latest` is
+            considered equivalent to `registry.example.com/myimage`.
+
+            Use the `tag` parameter to specify the tag to push.
+          type: "string"
+          required: true
+        - name: "tag"
+          in: "query"
+          description: |
+            Tag of the image to push. For example, `latest`. If no tag is provided,
+            all tags of the given image that are present in the local image store
+            are pushed.
+          type: "string"
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant to push.
+            If not provided, all available variants will attempt to be pushed.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to push to the registry. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+          required: true
+      tags: ["Image"]
+  /images/{name}/tag:
+    post:
+      summary: "Tag an image"
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
+      operationId: "ImageTag"
+      responses:
+        201:
+          description: "No error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID to tag."
+          type: "string"
+          required: true
+        - name: "repo"
+          in: "query"
+          description: "The repository to tag in. For example, `someuser/someimage`."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "The name of the new tag."
+          type: "string"
+      tags: ["Image"]
+  /images/{name}:
+    delete:
+      summary: "Remove an image"
+      description: |
+        Remove an image, along with any untagged parent images that were
+        referenced by that image.
+
+        Images can't be removed if they have descendant images, are being
+        used by a running container or are being used by a build.
+      operationId: "ImageDelete"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The image was deleted successfully"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageDeleteResponseItem"
+          examples:
+            application/json:
+              - Untagged: "3e2f21a89f"
+              - Deleted: "3e2f21a89f"
+              - Deleted: "53b4f83ac9"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Remove the image even if it is being used by stopped containers or has other tags"
+          type: "boolean"
+          default: false
+        - name: "noprune"
+          in: "query"
+          description: "Do not delete untagged parent images"
+          type: "boolean"
+          default: false
+        - name: "platforms"
+          in: "query"
+          description: |
+            Select platform-specific content to delete.
+            Multiple values are accepted.
+            Each platform is a OCI platform encoded as a JSON string.
+          type: "array"
+          items:
+            # This should be OCIPlatform
+            # but $ref is not supported for array in query in Swagger 2.0
+            # $ref: "#/definitions/OCIPlatform"
+            type: "string"
+      tags: ["Image"]
+  /images/search:
+    get:
+      summary: "Search images"
+      description: "Search for an image on Docker Hub."
+      operationId: "ImageSearch"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              type: "object"
+              title: "ImageSearchResponseItem"
+              properties:
+                description:
+                  type: "string"
+                is_official:
+                  type: "boolean"
+                is_automated:
+                  description: |
+                    Whether this repository has automated builds enabled.
+
+                    <p><br /></p>
+
+                    > **Deprecated**: This field is deprecated and will always be "false".
+                  type: "boolean"
+                  example: false
+                name:
+                  type: "string"
+                star_count:
+                  type: "integer"
+          examples:
+            application/json:
+              - description: "A minimal Docker image based on Alpine Linux with a complete package index and only 5 MB in size!"
+                is_official: true
+                is_automated: false
+                name: "alpine"
+                star_count: 10093
+              - description: "Busybox base image."
+                is_official: true
+                is_automated: false
+                name: "Busybox base image."
+                star_count: 3037
+              - description: "The PostgreSQL object-relational database system provides reliability and data integrity."
+                is_official: true
+                is_automated: false
+                name: "postgres"
+                star_count: 12408
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "term"
+          in: "query"
+          description: "Term to search"
+          type: "string"
+          required: true
+        - name: "limit"
+          in: "query"
+          description: "Maximum number of results to return"
+          type: "integer"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to process on the images list. Available filters:
+
+            - `is-official=(true|false)`
+            - `stars=<number>` Matches images that has at least 'number' stars.
+          type: "string"
+      tags: ["Image"]
+  /images/prune:
+    post:
+      summary: "Delete unused images"
+      produces:
+        - "application/json"
+      operationId: "ImagePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`). Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), prune only
+               unused *and* untagged images. When set to `false`
+               (or `0`), all unused images are pruned.
+            - `until=<string>` Prune images created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune images with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ImagePruneResponse"
+            properties:
+              ImagesDeleted:
+                description: "Images that were deleted"
+                type: "array"
+                items:
+                  $ref: "#/definitions/ImageDeleteResponseItem"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /auth:
+    post:
+      summary: "Check auth configuration"
+      description: |
+        Validate credentials for a registry and, if available, get an identity
+        token for accessing the registry without password.
+      operationId: "SystemAuth"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "An identity token was generated successfully."
+          schema:
+            type: "object"
+            title: "SystemAuthResponse"
+            required: [Status]
+            properties:
+              Status:
+                description: "The status of the authentication"
+                type: "string"
+                x-nullable: false
+              IdentityToken:
+                description: "An opaque token used to authenticate a user after a successful login"
+                type: "string"
+                x-nullable: false
+          examples:
+            application/json:
+              Status: "Login Succeeded"
+              IdentityToken: "9cbaf023786cd7..."
+        204:
+          description: "No error"
+        401:
+          description: "Auth error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "authConfig"
+          in: "body"
+          description: "Authentication to check"
+          schema:
+            $ref: "#/definitions/AuthConfig"
+      tags: ["System"]
+  /info:
+    get:
+      summary: "Get system information"
+      operationId: "SystemInfo"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/SystemInfo"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /version:
+    get:
+      summary: "Get version"
+      description: "Returns the version of Docker that is running and various information about the system that Docker is running on."
+      operationId: "SystemVersion"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/SystemVersion"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /_ping:
+    get:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPing"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "OK"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: |
+                Default version of docker image builder
+
+                The default on Linux is version "2" (BuildKit), but the daemon
+                can be configured to recommend version "1" (classic Builder).
+                Windows does not yet support BuildKit for native Windows images,
+                and uses "1" (classic builder) as a default.
+
+                This value is a recommendation as advertised by the daemon, and
+                it is up to the client to choose which builder to use.
+              default: "2"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          headers:
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+      tags: ["System"]
+    head:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPingHead"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "(empty)"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: "Default version of docker image builder"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /commit:
+    post:
+      summary: "Create a new image from a container"
+      operationId: "ImageCommit"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "containerConfig"
+          in: "body"
+          description: "The container configuration"
+          schema:
+            $ref: "#/definitions/ContainerConfig"
+        - name: "container"
+          in: "query"
+          description: "The ID or name of the container to commit"
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name for the created image"
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag name for the create image"
+          type: "string"
+        - name: "comment"
+          in: "query"
+          description: "Commit message"
+          type: "string"
+        - name: "author"
+          in: "query"
+          description: "Author of the image (e.g., `John Hannibal Smith <hannibal@a-team.com>`)"
+          type: "string"
+        - name: "pause"
+          in: "query"
+          description: "Whether to pause the container before committing"
+          type: "boolean"
+          default: true
+        - name: "changes"
+          in: "query"
+          description: "`Dockerfile` instructions to apply while committing"
+          type: "string"
+      tags: ["Image"]
+  /events:
+    get:
+      summary: "Monitor events"
+      description: |
+        Stream real-time events from the server.
+
+        Various objects within Docker report events when something happens to them.
+
+        Containers report these events: `attach`, `commit`, `copy`, `create`, `destroy`, `detach`, `die`, `exec_create`, `exec_detach`, `exec_start`, `exec_die`, `export`, `health_status`, `kill`, `oom`, `pause`, `rename`, `resize`, `restart`, `start`, `stop`, `top`, `unpause`, `update`, and `prune`
+
+        Images report these events: `create`, `delete`, `import`, `load`, `pull`, `push`, `save`, `tag`, `untag`, and `prune`
+
+        Volumes report these events: `create`, `mount`, `unmount`, `destroy`, and `prune`
+
+        Networks report these events: `create`, `connect`, `disconnect`, `destroy`, `update`, `remove`, and `prune`
+
+        The Docker daemon reports these events: `reload`
+
+        Services report these events: `create`, `update`, and `remove`
+
+        Nodes report these events: `create`, `update`, and `remove`
+
+        Secrets report these events: `create`, `update`, and `remove`
+
+        Configs report these events: `create`, `update`, and `remove`
+
+        The Builder reports `prune` events
+
+      operationId: "SystemEvents"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/EventMessage"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "since"
+          in: "query"
+          description: "Show events created since this timestamp then stream new events."
+          type: "string"
+        - name: "until"
+          in: "query"
+          description: "Show events created until this timestamp then stop streaming."
+          type: "string"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of filters (a `map[string][]string`) to process on the event list. Available filters:
+
+            - `config=<string>` config name or ID
+            - `container=<string>` container name or ID
+            - `daemon=<string>` daemon name or ID
+            - `event=<string>` event type
+            - `image=<string>` image name or ID
+            - `label=<string>` image or container label
+            - `network=<string>` network name or ID
+            - `node=<string>` node ID
+            - `plugin`=<string> plugin name or ID
+            - `scope`=<string> local or swarm
+            - `secret=<string>` secret name or ID
+            - `service=<string>` service name or ID
+            - `type=<string>` object to filter by, one of `container`, `image`, `volume`, `network`, `daemon`, `plugin`, `node`, `service`, `secret` or `config`
+            - `volume=<string>` volume name
+          type: "string"
+      tags: ["System"]
+  /system/df:
+    get:
+      summary: "Get data usage information"
+      operationId: "SystemDataUsage"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "SystemDataUsageResponse"
+            properties:
+              LayersSize:
+                type: "integer"
+                format: "int64"
+              Images:
+                type: "array"
+                items:
+                  $ref: "#/definitions/ImageSummary"
+              Containers:
+                type: "array"
+                items:
+                  $ref: "#/definitions/ContainerSummary"
+              Volumes:
+                type: "array"
+                items:
+                  $ref: "#/definitions/Volume"
+              BuildCache:
+                type: "array"
+                items:
+                  $ref: "#/definitions/BuildCache"
+            example:
+              LayersSize: 1092588
+              Images:
+                -
+                  Id: "sha256:2b8fd9751c4c0f5dd266fcae00707e67a2545ef34f9a29354585f93dac906749"
+                  ParentId: ""
+                  RepoTags:
+                    - "busybox:latest"
+                  RepoDigests:
+                    - "busybox@sha256:a59906e33509d14c036c8678d687bd4eec81ed7c4b8ce907b888c607f6a1e0e6"
+                  Created: 1466724217
+                  Size: 1092588
+                  SharedSize: 0
+                  Labels: {}
+                  Containers: 1
+              Containers:
+                -
+                  Id: "e575172ed11dc01bfce087fb27bee502db149e1a0fad7c296ad300bbff178148"
+                  Names:
+                    - "/top"
+                  Image: "busybox"
+                  ImageID: "sha256:2b8fd9751c4c0f5dd266fcae00707e67a2545ef34f9a29354585f93dac906749"
+                  Command: "top"
+                  Created: 1472592424
+                  Ports: []
+                  SizeRootFs: 1092588
+                  Labels: {}
+                  State: "exited"
+                  Status: "Exited (0) 56 minutes ago"
+                  HostConfig:
+                    NetworkMode: "default"
+                  NetworkSettings:
+                    Networks:
+                      bridge:
+                        IPAMConfig: null
+                        Links: null
+                        Aliases: null
+                        NetworkID: "d687bc59335f0e5c9ee8193e5612e8aee000c8c62ea170cfb99c098f95899d92"
+                        EndpointID: "8ed5115aeaad9abb174f68dcf135b49f11daf597678315231a32ca28441dec6a"
+                        Gateway: "172.18.0.1"
+                        IPAddress: "172.18.0.2"
+                        IPPrefixLen: 16
+                        IPv6Gateway: ""
+                        GlobalIPv6Address: ""
+                        GlobalIPv6PrefixLen: 0
+                        MacAddress: "02:42:ac:12:00:02"
+                  Mounts: []
+              Volumes:
+                -
+                  Name: "my-volume"
+                  Driver: "local"
+                  Mountpoint: "/var/lib/docker/volumes/my-volume/_data"
+                  Labels: null
+                  Scope: "local"
+                  Options: null
+                  UsageData:
+                    Size: 10920104
+                    RefCount: 2
+              BuildCache:
+                -
+                  ID: "hw53o5aio51xtltp5xjp8v7fx"
+                  Parents: []
+                  Type: "regular"
+                  Description: "pulled from docker.io/library/debian@sha256:234cb88d3020898631af0ccbbcca9a66ae7306ecd30c9720690858c1b007d2a0"
+                  InUse: false
+                  Shared: true
+                  Size: 0
+                  CreatedAt: "2021-06-28T13:31:01.474619385Z"
+                  LastUsedAt: "2021-07-07T22:02:32.738075951Z"
+                  UsageCount: 26
+                -
+                  ID: "ndlpt0hhvkqcdfkputsk4cq9c"
+                  Parents: ["ndlpt0hhvkqcdfkputsk4cq9c"]
+                  Type: "regular"
+                  Description: "mount / from exec /bin/sh -c echo 'Binary::apt::APT::Keep-Downloaded-Packages \"true\";' > /etc/apt/apt.conf.d/keep-cache"
+                  InUse: false
+                  Shared: true
+                  Size: 51
+                  CreatedAt: "2021-06-28T13:31:03.002625487Z"
+                  LastUsedAt: "2021-07-07T22:02:32.773909517Z"
+                  UsageCount: 26
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "type"
+          in: "query"
+          description: |
+            Object types, for which to compute and return data.
+          type: "array"
+          collectionFormat: multi
+          items:
+            type: "string"
+            enum: ["container", "image", "volume", "build-cache"]
+      tags: ["System"]
+  /images/{name}/get:
+    get:
+      summary: "Export an image"
+      description: |
+        Get a tarball containing all images and metadata for a repository.
+
+        If `name` is a specific name and tag (e.g. `ubuntu:latest`), then only that image (and its parents) are returned. If `name` is an image ID, similarly only that image (and its parents) are returned, but with the exclusion of the `repositories` file in the tarball, as there were no image names referenced.
+
+        ### Image tarball format
+
+        An image tarball contains [Content as defined in the OCI Image Layout Specification](https://github.com/opencontainers/image-spec/blob/v1.1.1/image-layout.md#content).
+
+        Additionally, includes the manifest.json file associated with a backwards compatible docker save format.
+
+        If the tarball defines a repository, the tarball should also include a `repositories` file at the root that contains a list of repository and tag names mapped to layer IDs.
+
+        ```json
+        {
+          "hello-world": {
+            "latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"
+          }
+        }
+        ```
+      operationId: "ImageGet"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON encoded OCI platform describing a platform which will be used
+            to select a platform-specific image to be saved if the image is
+            multi-platform.
+            If not provided, the full multi-platform image will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/get:
+    get:
+      summary: "Export several images"
+      description: |
+        Get a tarball containing all images and metadata for several image
+        repositories.
+
+        For each value of the `names` parameter: if it is a specific name and
+        tag (e.g. `ubuntu:latest`), then only that image (and its parents) are
+        returned; if it is an image ID, similarly only that image (and its parents)
+        are returned and there would be no names referenced in the 'repositories'
+        file for this image ID.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageGetAll"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "names"
+          in: "query"
+          description: "Image names to filter by"
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON encoded OCI platform describing a platform which will be used
+            to select a platform-specific image to be saved if the image is
+            multi-platform.
+            If not provided, the full multi-platform image will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/load:
+    post:
+      summary: "Import images"
+      description: |
+        Load a set of images and tags into a repository.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageLoad"
+      consumes:
+        - "application/x-tar"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "imagesTarball"
+          in: "body"
+          description: "Tar archive containing images"
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "quiet"
+          in: "query"
+          description: "Suppress progress details during load."
+          type: "boolean"
+          default: false
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON encoded OCI platform describing a platform which will be used
+            to select a platform-specific image to be load if the image is
+            multi-platform.
+            If not provided, the full multi-platform image will be loaded.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /containers/{id}/exec:
+    post:
+      summary: "Create an exec instance"
+      description: "Run a command inside a running container."
+      operationId: "ContainerExec"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execConfig"
+          in: "body"
+          description: "Exec configuration"
+          schema:
+            type: "object"
+            title: "ExecConfig"
+            properties:
+              AttachStdin:
+                type: "boolean"
+                description: "Attach to `stdin` of the exec command."
+              AttachStdout:
+                type: "boolean"
+                description: "Attach to `stdout` of the exec command."
+              AttachStderr:
+                type: "boolean"
+                description: "Attach to `stderr` of the exec command."
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+              DetachKeys:
+                type: "string"
+                description: |
+                  Override the key sequence for detaching a container. Format is
+                  a single character `[a-Z]` or `ctrl-<value>` where `<value>`
+                  is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+              Env:
+                description: |
+                  A list of environment variables in the form `["VAR=value", ...]`.
+                type: "array"
+                items:
+                  type: "string"
+              Cmd:
+                type: "array"
+                description: "Command to run, as a string or array of strings."
+                items:
+                  type: "string"
+              Privileged:
+                type: "boolean"
+                description: "Runs the exec process with extended privileges."
+                default: false
+              User:
+                type: "string"
+                description: |
+                  The user, and optionally, group to run the exec process inside
+                  the container. Format is one of: `user`, `user:group`, `uid`,
+                  or `uid:gid`.
+              WorkingDir:
+                type: "string"
+                description: |
+                  The working directory for the exec process inside the container.
+            example:
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              DetachKeys: "ctrl-p,ctrl-q"
+              Tty: false
+              Cmd:
+                - "date"
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+          required: true
+        - name: "id"
+          in: "path"
+          description: "ID or name of container"
+          type: "string"
+          required: true
+      tags: ["Exec"]
+  /exec/{id}/start:
+    post:
+      summary: "Start an exec instance"
+      description: |
+        Starts a previously set up exec instance. If detach is true, this endpoint
+        returns immediately after starting the command. Otherwise, it sets up an
+        interactive session with the command.
+      operationId: "ExecStart"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Container is stopped or paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execStartConfig"
+          in: "body"
+          schema:
+            type: "object"
+            title: "ExecStartConfig"
+            properties:
+              Detach:
+                type: "boolean"
+                description: "Detach from the command."
+                example: false
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+                example: true
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+  /exec/{id}/resize:
+    post:
+      summary: "Resize an exec instance"
+      description: |
+        Resize the TTY session used by an exec instance. This endpoint only works
+        if `tty` was specified as part of creating and starting the exec instance.
+      operationId: "ExecResize"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Exec"]
+  /exec/{id}/json:
+    get:
+      summary: "Inspect an exec instance"
+      description: "Return low-level information about an exec instance."
+      operationId: "ExecInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ExecInspectResponse"
+            properties:
+              CanRemove:
+                type: "boolean"
+              DetachKeys:
+                type: "string"
+              ID:
+                type: "string"
+              Running:
+                type: "boolean"
+              ExitCode:
+                type: "integer"
+              ProcessConfig:
+                $ref: "#/definitions/ProcessConfig"
+              OpenStdin:
+                type: "boolean"
+              OpenStderr:
+                type: "boolean"
+              OpenStdout:
+                type: "boolean"
+              ContainerID:
+                type: "string"
+              Pid:
+                type: "integer"
+                description: "The system process ID for the exec process."
+          examples:
+            application/json:
+              CanRemove: false
+              ContainerID: "b53ee82b53a40c7dca428523e34f741f3abc51d9f297a14ff874bf761b995126"
+              DetachKeys: ""
+              ExitCode: 2
+              ID: "f33bbfb39f5b142420f4759b2348913bd4a8d1a6d7fd56499cb41a1bb91d7b3b"
+              OpenStderr: true
+              OpenStdin: true
+              OpenStdout: true
+              ProcessConfig:
+                arguments:
+                  - "-c"
+                  - "exit 2"
+                entrypoint: "sh"
+                privileged: false
+                tty: true
+                user: "1000"
+              Running: false
+              Pid: 42000
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+
+  /volumes:
+    get:
+      summary: "List volumes"
+      operationId: "VolumeList"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "Summary volume data that matches the query"
+          schema:
+            $ref: "#/definitions/VolumeListResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to
+            process on the volumes list. Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               volumes that are not in use by a container. When set to `false`
+               (or `0`), only volumes that are in use by one or more
+               containers are returned.
+            - `driver=<volume-driver-name>` Matches volumes based on their driver.
+            - `label=<key>` or `label=<key>:<value>` Matches volumes based on
+               the presence of a `label` alone or a `label` and a value.
+            - `name=<volume-name>` Matches all or part of a volume name.
+          type: "string"
+          format: "json"
+      tags: ["Volume"]
+
+  /volumes/create:
+    post:
+      summary: "Create a volume"
+      operationId: "VolumeCreate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        201:
+          description: "The volume was created successfully"
+          schema:
+            $ref: "#/definitions/Volume"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "volumeConfig"
+          in: "body"
+          required: true
+          description: "Volume configuration"
+          schema:
+            $ref: "#/definitions/VolumeCreateOptions"
+      tags: ["Volume"]
+
+  /volumes/{name}:
+    get:
+      summary: "Inspect a volume"
+      operationId: "VolumeInspect"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/Volume"
+        404:
+          description: "No such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+      tags: ["Volume"]
+
+    put:
+      summary: |
+        "Update a volume. Valid only for Swarm cluster volumes"
+      operationId: "VolumeUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "The name or ID of the volume"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            # though the schema for is an object that contains only a
+            # ClusterVolumeSpec, wrapping the ClusterVolumeSpec in this object
+            # means that if, later on, we support things like changing the
+            # labels, we can do so without duplicating that information to the
+            # ClusterVolumeSpec.
+            type: "object"
+            description: "Volume configuration"
+            properties:
+              Spec:
+                $ref: "#/definitions/ClusterVolumeSpec"
+          description: |
+            The spec of the volume to update. Currently, only Availability may
+            change. All other fields must remain unchanged.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the volume being updated. This is required to
+            avoid conflicting writes. Found in the volume's `ClusterVolume`
+            field.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Volume"]
+
+    delete:
+      summary: "Remove a volume"
+      description: "Instruct the driver to remove the volume."
+      operationId: "VolumeDelete"
+      responses:
+        204:
+          description: "The volume was removed"
+        404:
+          description: "No such volume or volume driver"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Volume is in use and cannot be removed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: "Force the removal of the volume"
+          type: "boolean"
+          default: false
+      tags: ["Volume"]
+
+  /volumes/prune:
+    post:
+      summary: "Delete unused volumes"
+      produces:
+        - "application/json"
+      operationId: "VolumePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune volumes with (or without, in case `label!=...` is used) the specified labels.
+            - `all` (`all=true`) - Consider all (local) volumes for pruning and not just anonymous volumes.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "VolumePruneResponse"
+            properties:
+              VolumesDeleted:
+                description: "Volumes that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Volume"]
+  /networks:
+    get:
+      summary: "List networks"
+      description: |
+        Returns a list of networks. For details on the format, see the
+        [network inspect endpoint](#operation/NetworkInspect).
+
+        Note that it uses a different, smaller representation of a network than
+        inspecting a single network. For example, the list of containers attached
+        to the network is not propagated in API versions 1.28 and up.
+      operationId: "NetworkList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Network"
+          examples:
+            application/json:
+              - Name: "bridge"
+                Id: "f2de39df4171b0dc801e8002d1d999b77256983dfc63041c0f34030aa3977566"
+                Created: "2016-10-19T06:21:00.416543526Z"
+                Scope: "local"
+                Driver: "bridge"
+                EnableIPv4: true
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config:
+                    -
+                      Subnet: "172.17.0.0/16"
+                Options:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              - Name: "none"
+                Id: "e086a3893b05ab69242d3c44e49483a3bbbd3a26b46baa8f61ab797c1088d794"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "null"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+              - Name: "host"
+                Id: "13e871235c677f196c4e1ecebb9dc733b9b2d2ab589e30c539efeda84a24215e"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "host"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to process
+            on the networks list.
+
+            Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               networks that are not in use by a container. When set to `false`
+               (or `0`), only networks that are in use by one or more
+               containers are returned.
+            - `driver=<driver-name>` Matches a network's driver.
+            - `id=<network-id>` Matches all or part of a network ID.
+            - `label=<key>` or `label=<key>=<value>` of a network label.
+            - `name=<network-name>` Matches all or part of a network name.
+            - `scope=["swarm"|"global"|"local"]` Filters networks by scope (`swarm`, `global`, or `local`).
+            - `type=["custom"|"builtin"]` Filters networks by type. The `custom` keyword returns all user-defined networks.
+          type: "string"
+      tags: ["Network"]
+
+  /networks/{id}:
+    get:
+      summary: "Inspect a network"
+      operationId: "NetworkInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/Network"
+        404:
+          description: "Network not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "verbose"
+          in: "query"
+          description: "Detailed inspect output for troubleshooting"
+          type: "boolean"
+          default: false
+        - name: "scope"
+          in: "query"
+          description: "Filter the network by scope (swarm, global, or local)"
+          type: "string"
+      tags: ["Network"]
+
+    delete:
+      summary: "Remove a network"
+      operationId: "NetworkDelete"
+      responses:
+        204:
+          description: "No error"
+        403:
+          description: "operation not supported for pre-defined networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such network"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+      tags: ["Network"]
+
+  /networks/create:
+    post:
+      summary: "Create a network"
+      operationId: "NetworkCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "Network created successfully"
+          schema:
+            $ref: "#/definitions/NetworkCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: |
+            Forbidden operation. This happens when trying to create a network named after a pre-defined network,
+            or when trying to create an overlay network on a daemon which is not part of a Swarm cluster.
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "plugin not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "networkConfig"
+          in: "body"
+          description: "Network configuration"
+          required: true
+          schema:
+            type: "object"
+            title: "NetworkCreateRequest"
+            required: ["Name"]
+            properties:
+              Name:
+                description: "The network's name."
+                type: "string"
+                example: "my_network"
+              Driver:
+                description: "Name of the network driver plugin to use."
+                type: "string"
+                default: "bridge"
+                example: "bridge"
+              Scope:
+                description: |
+                  The level at which the network exists (e.g. `swarm` for cluster-wide
+                  or `local` for machine level).
+                type: "string"
+              Internal:
+                description: "Restrict external access to the network."
+                type: "boolean"
+              Attachable:
+                description: |
+                  Globally scoped network is manually attachable by regular
+                  containers from workers in swarm mode.
+                type: "boolean"
+                example: true
+              Ingress:
+                description: |
+                  Ingress network is the network which provides the routing-mesh
+                  in swarm mode.
+                type: "boolean"
+                example: false
+              ConfigOnly:
+                description: |
+                  Creates a config-only network. Config-only networks are placeholder
+                  networks for network configurations to be used by other networks.
+                  Config-only networks cannot be used directly to run containers
+                  or services.
+                type: "boolean"
+                default: false
+                example: false
+              ConfigFrom:
+                description: |
+                  Specifies the source which will provide the configuration for
+                  this network. The specified network must be an existing
+                  config-only network; see ConfigOnly.
+                $ref: "#/definitions/ConfigReference"
+              IPAM:
+                description: "Optional custom IP scheme for the network."
+                $ref: "#/definitions/IPAM"
+              EnableIPv4:
+                description: "Enable IPv4 on the network."
+                type: "boolean"
+                example: true
+              EnableIPv6:
+                description: "Enable IPv6 on the network."
+                type: "boolean"
+                example: true
+              Options:
+                description: "Network specific options to be used by the drivers."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              Labels:
+                description: "User-defined key/value metadata."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.example.some-label: "some-value"
+                  com.example.some-other-label: "some-other-value"
+      tags: ["Network"]
+
+  /networks/{id}/connect:
+    post:
+      summary: "Connect a container to a network"
+      description: "The network must be either a local-scoped network or a swarm-scoped network with the `attachable` option set. A network cannot be re-attached to a running container"
+      operationId: "NetworkConnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "Operation forbidden"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "NetworkConnectRequest"
+            properties:
+              Container:
+                type: "string"
+                description: "The ID or name of the container to connect to the network."
+              EndpointConfig:
+                $ref: "#/definitions/EndpointSettings"
+            example:
+              Container: "3613f73ba0e4"
+              EndpointConfig:
+                IPAMConfig:
+                  IPv4Address: "172.24.56.89"
+                  IPv6Address: "2001:db8::5689"
+                MacAddress: "02:42:ac:12:05:02"
+                Priority: 100
+      tags: ["Network"]
+
+  /networks/{id}/disconnect:
+    post:
+      summary: "Disconnect a container from a network"
+      operationId: "NetworkDisconnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        403:
+          description: "Operation not supported for swarm scoped networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "NetworkDisconnectRequest"
+            properties:
+              Container:
+                type: "string"
+                description: |
+                  The ID or name of the container to disconnect from the network.
+              Force:
+                type: "boolean"
+                description: |
+                  Force the container to disconnect from the network.
+      tags: ["Network"]
+  /networks/prune:
+    post:
+      summary: "Delete unused networks"
+      produces:
+        - "application/json"
+      operationId: "NetworkPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune networks created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune networks with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "NetworkPruneResponse"
+            properties:
+              NetworksDeleted:
+                description: "Networks that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Network"]
+  /plugins:
+    get:
+      summary: "List plugins"
+      operationId: "PluginList"
+      description: "Returns information about installed plugins."
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Plugin"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the plugin list.
+
+            Available filters:
+
+            - `capability=<capability name>`
+            - `enable=<true>|<false>`
+      tags: ["Plugin"]
+
+  /plugins/privileges:
+    get:
+      summary: "Get plugin privileges"
+      operationId: "GetPluginPrivileges"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags:
+        - "Plugin"
+
+  /plugins/pull:
+    post:
+      summary: "Install a plugin"
+      operationId: "PluginPull"
+      description: |
+        Pulls and installs a plugin. After the plugin is installed, it can be
+        enabled using the [`POST /plugins/{name}/enable` endpoint](#operation/PostPluginsEnable).
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference for plugin to install.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "name"
+          in: "query"
+          description: |
+            Local name for the pulled plugin.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: false
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/{name}/json:
+    get:
+      summary: "Inspect a plugin"
+      operationId: "PluginInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags: ["Plugin"]
+  /plugins/{name}:
+    delete:
+      summary: "Remove a plugin"
+      operationId: "PluginDelete"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Disable the plugin before removing. This may result in issues if the
+            plugin is in use by a container.
+          type: "boolean"
+          default: false
+      tags: ["Plugin"]
+  /plugins/{name}/enable:
+    post:
+      summary: "Enable a plugin"
+      operationId: "PluginEnable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "timeout"
+          in: "query"
+          description: "Set the HTTP client timeout (in seconds)"
+          type: "integer"
+          default: 0
+      tags: ["Plugin"]
+  /plugins/{name}/disable:
+    post:
+      summary: "Disable a plugin"
+      operationId: "PluginDisable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Force disable a plugin even if still in use.
+          required: false
+          type: "boolean"
+      tags: ["Plugin"]
+  /plugins/{name}/upgrade:
+    post:
+      summary: "Upgrade a plugin"
+      operationId: "PluginUpgrade"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference to upgrade to.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/create:
+    post:
+      summary: "Create a plugin"
+      operationId: "PluginCreate"
+      consumes:
+        - "application/x-tar"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "tarContext"
+          in: "body"
+          description: "Path to tar containing plugin rootfs and manifest"
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Plugin"]
+  /plugins/{name}/push:
+    post:
+      summary: "Push a plugin"
+      operationId: "PluginPush"
+      description: |
+        Push a plugin to the registry.
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /plugins/{name}/set:
+    post:
+      summary: "Configure a plugin"
+      operationId: "PluginSet"
+      consumes:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              type: "string"
+            example: ["DEBUG=1"]
+      responses:
+        204:
+          description: "No error"
+        404:
+          description: "Plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /nodes:
+    get:
+      summary: "List nodes"
+      operationId: "NodeList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Node"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the nodes list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `id=<node id>`
+            - `label=<engine label>`
+            - `membership=`(`accepted`|`pending`)`
+            - `name=<node name>`
+            - `node.label=<node label>`
+            - `role=`(`manager`|`worker`)`
+          type: "string"
+      tags: ["Node"]
+  /nodes/{id}:
+    get:
+      summary: "Inspect a node"
+      operationId: "NodeInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Node"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+      tags: ["Node"]
+    delete:
+      summary: "Delete a node"
+      operationId: "NodeDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Force remove a node from the swarm"
+          default: false
+          type: "boolean"
+      tags: ["Node"]
+  /nodes/{id}/update:
+    post:
+      summary: "Update a node"
+      operationId: "NodeUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID of the node"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/NodeSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the node object being updated. This is required
+            to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Node"]
+  /swarm:
+    get:
+      summary: "Inspect swarm"
+      operationId: "SwarmInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Swarm"
+        404:
+          description: "no such swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/init:
+    post:
+      summary: "Initialize a new swarm"
+      operationId: "SwarmInit"
+      produces:
+        - "application/json"
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            description: "The node ID"
+            type: "string"
+            example: "7v2t30z9blmxuhnyo6s4cpenp"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmInitRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication, as well
+                  as determining the networking interface used for the VXLAN
+                  Tunnel Endpoint (VTEP). This can either be an address/port
+                  combination in the form `192.168.1.1:4567`, or an interface
+                  followed by a port number, like `eth0:4567`. If the port number
+                  is omitted, the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other  nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+                type: "string"
+              DataPathPort:
+                description: |
+                  DataPathPort specifies the data path port number for data traffic.
+                  Acceptable port range is 1024 to 49151.
+                  if no port is set or is set to 0, default port 4789 will be used.
+                type: "integer"
+                format: "uint32"
+              DefaultAddrPool:
+                description: |
+                  Default Address Pool specifies default subnet pools for global
+                  scope networks.
+                type: "array"
+                items:
+                  type: "string"
+                  example: ["10.10.0.0/16", "20.20.0.0/16"]
+              ForceNewCluster:
+                description: "Force creation of a new swarm."
+                type: "boolean"
+              SubnetSize:
+                description: |
+                  SubnetSize specifies the subnet size of the networks created
+                  from the default subnet pool.
+                type: "integer"
+                format: "uint32"
+              Spec:
+                $ref: "#/definitions/SwarmSpec"
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathPort: 4789
+              DefaultAddrPool: ["10.10.0.0/8", "20.20.0.0/8"]
+              SubnetSize: 24
+              ForceNewCluster: false
+              Spec:
+                Orchestration: {}
+                Raft: {}
+                Dispatcher: {}
+                CAConfig: {}
+                EncryptionConfig:
+                  AutoLockManagers: false
+      tags: ["Swarm"]
+  /swarm/join:
+    post:
+      summary: "Join an existing swarm"
+      operationId: "SwarmJoin"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmJoinRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+
+                type: "string"
+              RemoteAddrs:
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
+              JoinToken:
+                description: "Secret token for joining this swarm."
+                type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathAddr: "192.168.1.1"
+              RemoteAddrs:
+                - "node1:2377"
+              JoinToken: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+      tags: ["Swarm"]
+  /swarm/leave:
+    post:
+      summary: "Leave a swarm"
+      operationId: "SwarmLeave"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "force"
+          description: |
+            Force leave swarm, even if this is the last manager or that it will
+            break the cluster.
+          in: "query"
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/update:
+    post:
+      summary: "Update a swarm"
+      operationId: "SwarmUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/SwarmSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the swarm object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+        - name: "rotateWorkerToken"
+          in: "query"
+          description: "Rotate the worker join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerToken"
+          in: "query"
+          description: "Rotate the manager join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerUnlockKey"
+          in: "query"
+          description: "Rotate the manager unlock key."
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/unlockkey:
+    get:
+      summary: "Get the unlock key"
+      operationId: "SwarmUnlockkey"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "UnlockKeyResponse"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/unlock:
+    post:
+      summary: "Unlock a locked manager"
+      operationId: "SwarmUnlock"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmUnlockRequest"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /services:
+    get:
+      summary: "List services"
+      operationId: "ServiceList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Service"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the services list.
+
+            Available filters:
+
+            - `id=<service id>`
+            - `label=<service label>`
+            - `mode=["replicated"|"global"]`
+            - `name=<service name>`
+        - name: "status"
+          in: "query"
+          type: "boolean"
+          description: |
+            Include service status, with count of running and desired tasks.
+      tags: ["Service"]
+  /services/create:
+    post:
+      summary: "Create a service"
+      operationId: "ServiceCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "network is not eligible for services"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "name conflicts with an existing service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "web"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "nginx:alpine"
+                      Mounts:
+                        -
+                          ReadOnly: true
+                          Source: "web-data"
+                          Target: "/usr/share/nginx/html"
+                          Type: "volume"
+                          VolumeOptions:
+                            DriverConfig: {}
+                            Labels:
+                              com.example.something: "something-value"
+                      Hosts: ["10.10.10.10 host1", "ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 host2"]
+                      User: "33"
+                      DNSConfig:
+                        Nameservers: ["8.8.8.8"]
+                        Search: ["example.org"]
+                        Options: ["timeout:3"]
+                      Secrets:
+                        -
+                          File:
+                            Name: "www.example.org.key"
+                            UID: "33"
+                            GID: "33"
+                            Mode: 384
+                          SecretID: "fpjqlhnwb19zds35k8wn80lq9"
+                          SecretName: "example_org_domain_key"
+                      OomScoreAdj: 0
+                    LogDriver:
+                      Name: "json-file"
+                      Options:
+                        max-file: "3"
+                        max-size: "10M"
+                    Placement: {}
+                    Resources:
+                      Limits:
+                        MemoryBytes: 104857600
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "on-failure"
+                      Delay: 10000000000
+                      MaxAttempts: 10
+                  Mode:
+                    Replicated:
+                      Replicas: 4
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Ports:
+                      -
+                        Protocol: "tcp"
+                        PublishedPort: 8080
+                        TargetPort: 80
+                  Labels:
+                    foo: "bar"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+      tags: ["Service"]
+  /services/{id}:
+    get:
+      summary: "Inspect a service"
+      operationId: "ServiceInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Service"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "insertDefaults"
+          in: "query"
+          description: "Fill empty fields with default values."
+          type: "boolean"
+          default: false
+      tags: ["Service"]
+    delete:
+      summary: "Delete a service"
+      operationId: "ServiceDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+      tags: ["Service"]
+  /services/{id}/update:
+    post:
+      summary: "Update a service"
+      operationId: "ServiceUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceUpdateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "top"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "busybox"
+                      Args:
+                        - "top"
+                      OomScoreAdj: 0
+                    Resources:
+                      Limits: {}
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "any"
+                      MaxAttempts: 0
+                    Placement: {}
+                    ForceUpdate: 0
+                  Mode:
+                    Replicated:
+                      Replicas: 1
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Mode: "vip"
+
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the service object being updated. This is
+            required to avoid conflicting writes.
+            This version number should be the value as currently set on the
+            service *before* the update. You can find the current version by
+            calling `GET /services/{id}`
+          required: true
+          type: "integer"
+        - name: "registryAuthFrom"
+          in: "query"
+          description: |
+            If the `X-Registry-Auth` header is not specified, this parameter
+            indicates where to find registry authorization credentials.
+          type: "string"
+          enum: ["spec", "previous-spec"]
+          default: "spec"
+        - name: "rollback"
+          in: "query"
+          description: |
+            Set to this parameter to `previous` to cause a server-side rollback
+            to the previous service spec. The supplied spec will be ignored in
+            this case.
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+
+      tags: ["Service"]
+  /services/{id}/logs:
+    get:
+      summary: "Get service logs"
+      description: |
+        Get `stdout` and `stderr` logs from a service. See also
+        [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ServiceLogs"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such service: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the service"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show service context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Service"]
+  /tasks:
+    get:
+      summary: "List tasks"
+      operationId: "TaskList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Task"
+            example:
+              - ID: "0kzzo1i0y4jz6027t0k7aezc7"
+                Version:
+                  Index: 71
+                CreatedAt: "2016-06-07T21:07:31.171892745Z"
+                UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:31.290032978Z"
+                  State: "running"
+                  Message: "started"
+                  ContainerStatus:
+                    ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+                    PID: 677
+                DesiredState: "running"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.10/16"
+              - ID: "1yljwbmlr8er2waf8orvqpwms"
+                Version:
+                  Index: 30
+                CreatedAt: "2016-06-07T21:07:30.019104782Z"
+                UpdatedAt: "2016-06-07T21:07:30.231958098Z"
+                Name: "hopeful_cori"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:30.202183143Z"
+                  State: "shutdown"
+                  Message: "shutdown"
+                  ContainerStatus:
+                    ContainerID: "1cf8d63d18e79668b0004a4be4c6ee58cddfad2dae29506d8781581d0688a213"
+                DesiredState: "shutdown"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.5/16"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the tasks list.
+
+            Available filters:
+
+            - `desired-state=(running | shutdown | accepted)`
+            - `id=<task id>`
+            - `label=key` or `label="key=value"`
+            - `name=<task name>`
+            - `node=<node id or name>`
+            - `service=<service name>`
+      tags: ["Task"]
+  /tasks/{id}:
+    get:
+      summary: "Inspect a task"
+      operationId: "TaskInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Task"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID of the task"
+          required: true
+          type: "string"
+      tags: ["Task"]
+  /tasks/{id}/logs:
+    get:
+      summary: "Get task logs"
+      description: |
+        Get `stdout` and `stderr` logs from a task.
+        See also [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      operationId: "TaskLogs"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such task: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID of the task"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show task context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Task"]
+  /secrets:
+    get:
+      summary: "List secrets"
+      operationId: "SecretList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Secret"
+            example:
+              - ID: "blt1owaxmitz71s9v5zh81zun"
+                Version:
+                  Index: 85
+                CreatedAt: "2017-07-20T13:55:28.678958722Z"
+                UpdatedAt: "2017-07-20T13:55:28.678958722Z"
+                Spec:
+                  Name: "mysql-passwd"
+                  Labels:
+                    some.label: "some.value"
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "app-dev.crt"
+                  Labels:
+                    foo: "bar"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the secrets list.
+
+            Available filters:
+
+            - `id=<secret id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<secret name>`
+            - `names=<secret name>`
+      tags: ["Secret"]
+  /secrets/create:
+    post:
+      summary: "Create a secret"
+      operationId: "SecretCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/SecretSpec"
+              - type: "object"
+                example:
+                  Name: "app-key.crt"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+      tags: ["Secret"]
+  /secrets/{id}:
+    get:
+      summary: "Inspect a secret"
+      operationId: "SecretInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Secret"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+                Labels:
+                  foo: "bar"
+                Driver:
+                  Name: "secret-bucket"
+                  Options:
+                    OptionA: "value for driver option A"
+                    OptionB: "value for driver option B"
+
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+    delete:
+      summary: "Delete a secret"
+      operationId: "SecretDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+  /secrets/{id}/update:
+    post:
+      summary: "Update a Secret"
+      operationId: "SecretUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such secret"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the secret"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/SecretSpec"
+          description: |
+            The spec of the secret to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [SecretInspect endpoint](#operation/SecretInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the secret object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Secret"]
+  /configs:
+    get:
+      summary: "List configs"
+      operationId: "ConfigList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Config"
+            example:
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "server.conf"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the configs list.
+
+            Available filters:
+
+            - `id=<config id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<config name>`
+            - `names=<config name>`
+      tags: ["Config"]
+  /configs/create:
+    post:
+      summary: "Create a config"
+      operationId: "ConfigCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ConfigSpec"
+              - type: "object"
+                example:
+                  Name: "server.conf"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+      tags: ["Config"]
+  /configs/{id}:
+    get:
+      summary: "Inspect a config"
+      operationId: "ConfigInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Config"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+    delete:
+      summary: "Delete a config"
+      operationId: "ConfigDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+  /configs/{id}/update:
+    post:
+      summary: "Update a Config"
+      operationId: "ConfigUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such config"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the config"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/ConfigSpec"
+          description: |
+            The spec of the config to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [ConfigInspect endpoint](#operation/ConfigInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the config object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Config"]
+  /distribution/{name}/json:
+    get:
+      summary: "Get image information from the registry"
+      description: |
+        Return image digest and platform information by contacting the registry.
+      operationId: "DistributionInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "descriptor and platform information"
+          schema:
+            $ref: "#/definitions/DistributionInspect"
+        401:
+          description: "Failed authentication or no image found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+      tags: ["Distribution"]
+  /session:
+    post:
+      summary: "Initialize interactive session"
+      description: |
+        Start a new interactive session with a server. Session allows server to
+        call back to the client for advanced capabilities.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to HTTP2 transport that allows
+        the client to expose gPRC services on that connection.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /session HTTP/1.1
+        Upgrade: h2c
+        Connection: Upgrade
+        ```
+
+        The Docker daemon responds with a `101 UPGRADED` response follow with
+        the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Connection: Upgrade
+        Upgrade: h2c
+        ```
+      operationId: "Session"
+      produces:
+        - "application/vnd.docker.raw-stream"
+      responses:
+        101:
+          description: "no error, hijacking successful"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Session"]
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.51.yaml b/_vendor/github.com/moby/moby/api/docs/v1.51.yaml
new file mode 100644
index 000000000000..94b51801d5fb
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.51.yaml
@@ -0,0 +1,13463 @@
+# A Swagger 2.0 (a.k.a. OpenAPI) definition of the Engine API.
+#
+# This is used for generating API documentation and the types used by the
+# client/server. See api/README.md for more information.
+#
+# Some style notes:
+# - This file is used by ReDoc, which allows GitHub Flavored Markdown in
+#   descriptions.
+# - There is no maximum line length, for ease of editing and pretty diffs.
+# - operationIds are in the format "NounVerb", with a singular noun.
+
+swagger: "2.0"
+schemes:
+  - "http"
+  - "https"
+produces:
+  - "application/json"
+  - "text/plain"
+consumes:
+  - "application/json"
+  - "text/plain"
+basePath: "/v1.51"
+info:
+  title: "Docker Engine API"
+  version: "1.51"
+  x-logo:
+    url: "https://docs.docker.com/assets/images/logo-docker-main.png"
+  description: |
+    The Engine API is an HTTP API served by Docker Engine. It is the API the
+    Docker client uses to communicate with the Engine, so everything the Docker
+    client can do can be done with the API.
+
+    Most of the client's commands map directly to API endpoints (e.g. `docker ps`
+    is `GET /containers/json`). The notable exception is running containers,
+    which consists of several API calls.
+
+    # Errors
+
+    The API uses standard HTTP status codes to indicate the success or failure
+    of the API call. The body of the response will be JSON in the following
+    format:
+
+    ```
+    {
+      "message": "page not found"
+    }
+    ```
+
+    # Versioning
+
+    The API is usually changed in each release, so API calls are versioned to
+    ensure that clients don't break. To lock to a specific version of the API,
+    you prefix the URL with its version, for example, call `/v1.30/info` to use
+    the v1.30 version of the `/info` endpoint. If the API version specified in
+    the URL is not supported by the daemon, a HTTP `400 Bad Request` error message
+    is returned.
+
+    If you omit the version-prefix, the current version of the API (v1.50) is used.
+    For example, calling `/info` is the same as calling `/v1.51/info`. Using the
+    API without a version-prefix is deprecated and will be removed in a future release.
+
+    Engine releases in the near future should support this version of the API,
+    so your client will continue to work even if it is talking to a newer Engine.
+
+    The API uses an open schema model, which means the server may add extra properties
+    to responses. Likewise, the server will ignore any extra query parameters and
+    request body properties. When you write clients, you need to ignore additional
+    properties in responses to ensure they do not break when talking to newer
+    daemons.
+
+
+    # Authentication
+
+    Authentication for registries is handled client side. The client has to send
+    authentication details to various endpoints that need to communicate with
+    registries, such as `POST /images/(name)/push`. These are sent as
+    `X-Registry-Auth` header as a [base64url encoded](https://tools.ietf.org/html/rfc4648#section-5)
+    (JSON) string with the following structure:
+
+    ```
+    {
+      "username": "string",
+      "password": "string",
+      "serveraddress": "string"
+    }
+    ```
+
+    The `serveraddress` is a domain/IP without a protocol. Throughout this
+    structure, double quotes are required.
+
+    If you have already got an identity token from the [`/auth` endpoint](#operation/SystemAuth),
+    you can just pass this instead of credentials:
+
+    ```
+    {
+      "identitytoken": "9cbaf023786cd7..."
+    }
+    ```
+
+# The tags on paths define the menu sections in the ReDoc documentation, so
+# the usage of tags must make sense for that:
+# - They should be singular, not plural.
+# - There should not be too many tags, or the menu becomes unwieldy. For
+#   example, it is preferable to add a path to the "System" tag instead of
+#   creating a tag with a single path in it.
+# - The order of tags in this list defines the order in the menu.
+tags:
+  # Primary objects
+  - name: "Container"
+    x-displayName: "Containers"
+    description: |
+      Create and manage containers.
+  - name: "Image"
+    x-displayName: "Images"
+  - name: "Network"
+    x-displayName: "Networks"
+    description: |
+      Networks are user-defined networks that containers can be attached to.
+      See the [networking documentation](https://docs.docker.com/network/)
+      for more information.
+  - name: "Volume"
+    x-displayName: "Volumes"
+    description: |
+      Create and manage persistent storage that can be attached to containers.
+  - name: "Exec"
+    x-displayName: "Exec"
+    description: |
+      Run new commands inside running containers. Refer to the
+      [command-line reference](https://docs.docker.com/engine/reference/commandline/exec/)
+      for more information.
+
+      To exec a command in a container, you first need to create an exec instance,
+      then start it. These two API endpoints are wrapped up in a single command-line
+      command, `docker exec`.
+
+  # Swarm things
+  - name: "Swarm"
+    x-displayName: "Swarm"
+    description: |
+      Engines can be clustered together in a swarm. Refer to the
+      [swarm mode documentation](https://docs.docker.com/engine/swarm/)
+      for more information.
+  - name: "Node"
+    x-displayName: "Nodes"
+    description: |
+      Nodes are instances of the Engine participating in a swarm. Swarm mode
+      must be enabled for these endpoints to work.
+  - name: "Service"
+    x-displayName: "Services"
+    description: |
+      Services are the definitions of tasks to run on a swarm. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Task"
+    x-displayName: "Tasks"
+    description: |
+      A task is a container running on a swarm. It is the atomic scheduling unit
+      of swarm. Swarm mode must be enabled for these endpoints to work.
+  - name: "Secret"
+    x-displayName: "Secrets"
+    description: |
+      Secrets are sensitive data that can be used by services. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Config"
+    x-displayName: "Configs"
+    description: |
+      Configs are application configurations that can be used by services. Swarm
+      mode must be enabled for these endpoints to work.
+  # System things
+  - name: "Plugin"
+    x-displayName: "Plugins"
+  - name: "System"
+    x-displayName: "System"
+
+definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
+  Port:
+    type: "object"
+    description: "An open port on a container"
+    required: [PrivatePort, Type]
+    properties:
+      IP:
+        type: "string"
+        format: "ip-address"
+        description: "Host IP address that the container's port is mapped to"
+      PrivatePort:
+        type: "integer"
+        format: "uint16"
+        x-nullable: false
+        description: "Port on the container"
+      PublicPort:
+        type: "integer"
+        format: "uint16"
+        description: "Port exposed on the host"
+      Type:
+        type: "string"
+        x-nullable: false
+        enum: ["tcp", "udp", "sctp"]
+    example:
+      PrivatePort: 8080
+      PublicPort: 80
+      Type: "tcp"
+
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `image` an OCI image.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "image"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
+  MountPoint:
+    type: "object"
+    description: |
+      MountPoint represents a mount point configuration inside the container.
+      This is used for reporting the mountpoints in use by a container.
+    properties:
+      Type:
+        description: |
+          The mount type:
+
+          - `bind` a mount of a file or directory from the host into the container.
+          - `cluster` a Swarm cluster volume.
+          - `image` an OCI image.
+          - `npipe` a named pipe from the host into the container.
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
+        example: "volume"
+      Name:
+        description: |
+          Name is the name reference to the underlying data defined by `Source`
+          e.g., the volume name.
+        type: "string"
+        example: "myvolume"
+      Source:
+        description: |
+          Source location of the mount.
+
+          For volumes, this contains the storage location of the volume (within
+          `/var/lib/docker/volumes/`). For bind-mounts, and `npipe`, this contains
+          the source (host) part of the bind-mount. For `tmpfs` mount points, this
+          field is empty.
+        type: "string"
+        example: "/var/lib/docker/volumes/myvolume/_data"
+      Destination:
+        description: |
+          Destination is the path relative to the container root (`/`) where
+          the `Source` is mounted inside the container.
+        type: "string"
+        example: "/usr/share/nginx/html/"
+      Driver:
+        description: |
+          Driver is the volume driver used to create the volume (if it is a volume).
+        type: "string"
+        example: "local"
+      Mode:
+        description: |
+          Mode is a comma separated list of options supplied by the user when
+          creating the bind/volume mount.
+
+          The default is platform-specific (`"z"` on Linux, empty on Windows).
+        type: "string"
+        example: "z"
+      RW:
+        description: |
+          Whether the mount is mounted writable (read-write).
+        type: "boolean"
+        example: true
+      Propagation:
+        description: |
+          Propagation describes how mounts are propagated from the host into the
+          mount point, and vice-versa. Refer to the [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
+          for details. This field is not used on Windows.
+        type: "string"
+        example: ""
+
+  DeviceMapping:
+    type: "object"
+    description: "A device mapping between the host and container"
+    properties:
+      PathOnHost:
+        type: "string"
+      PathInContainer:
+        type: "string"
+      CgroupPermissions:
+        type: "string"
+    example:
+      PathOnHost: "/dev/deviceName"
+      PathInContainer: "/dev/deviceName"
+      CgroupPermissions: "mrw"
+
+  DeviceRequest:
+    type: "object"
+    description: "A request for devices to be sent to device drivers"
+    properties:
+      Driver:
+        type: "string"
+        example: "nvidia"
+      Count:
+        type: "integer"
+        example: -1
+      DeviceIDs:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "0"
+          - "1"
+          - "GPU-fef8089b-4820-abfc-e83e-94318197576e"
+      Capabilities:
+        description: |
+          A list of capabilities; an OR list of AND lists of capabilities.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          # gpu AND nvidia AND compute
+          - ["gpu", "nvidia", "compute"]
+      Options:
+        description: |
+          Driver-specific options, specified as a key/value pairs. These options
+          are passed directly to the driver.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  ThrottleDevice:
+    type: "object"
+    properties:
+      Path:
+        description: "Device path"
+        type: "string"
+      Rate:
+        description: "Rate"
+        type: "integer"
+        format: "int64"
+        minimum: 0
+
+  Mount:
+    type: "object"
+    properties:
+      Target:
+        description: "Container path."
+        type: "string"
+      Source:
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
+        type: "string"
+      Type:
+        description: |
+          The mount type. Available types:
+
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `cluster` a Swarm cluster volume
+          - `image` Mounts an image.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
+      ReadOnly:
+        description: "Whether the mount should be read-only."
+        type: "boolean"
+      Consistency:
+        description: "The consistency requirement for the mount: `default`, `consistent`, `cached`, or `delegated`."
+        type: "string"
+      BindOptions:
+        description: "Optional configuration for the `bind` type."
+        type: "object"
+        properties:
+          Propagation:
+            description: "A propagation mode with the value `[r]private`, `[r]shared`, or `[r]slave`."
+            type: "string"
+            enum:
+              - "private"
+              - "rprivate"
+              - "shared"
+              - "rshared"
+              - "slave"
+              - "rslave"
+          NonRecursive:
+            description: "Disable recursive bind mount."
+            type: "boolean"
+            default: false
+          CreateMountpoint:
+            description: "Create mount point on host if missing"
+            type: "boolean"
+            default: false
+          ReadOnlyNonRecursive:
+            description: |
+               Make the mount non-recursively read-only, but still leave the mount recursive
+               (unless NonRecursive is set to `true` in conjunction).
+
+               Added in v1.44, before that version all read-only mounts were
+               non-recursive by default. To match the previous behaviour this
+               will default to `true` for clients on versions prior to v1.44.
+            type: "boolean"
+            default: false
+          ReadOnlyForceRecursive:
+            description: "Raise an error if the mount cannot be made recursively read-only."
+            type: "boolean"
+            default: false
+      VolumeOptions:
+        description: "Optional configuration for the `volume` type."
+        type: "object"
+        properties:
+          NoCopy:
+            description: "Populate volume with data from the target."
+            type: "boolean"
+            default: false
+          Labels:
+            description: "User-defined key/value metadata."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          DriverConfig:
+            description: "Map of driver specific options"
+            type: "object"
+            properties:
+              Name:
+                description: "Name of the driver to use to create the volume."
+                type: "string"
+              Options:
+                description: "key/value map of driver specific options."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+          Subpath:
+            description: "Source path inside the volume. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-volume/subdirectory"
+      ImageOptions:
+        description: "Optional configuration for the `image` type."
+        type: "object"
+        properties:
+          Subpath:
+            description: "Source path inside the image. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-image/subdirectory"
+      TmpfsOptions:
+        description: "Optional configuration for the `tmpfs` type."
+        type: "object"
+        properties:
+          SizeBytes:
+            description: "The size for the tmpfs mount in bytes."
+            type: "integer"
+            format: "int64"
+          Mode:
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
+            type: "integer"
+          Options:
+            description: |
+              The options to be passed to the tmpfs mount. An array of arrays.
+              Flag options should be provided as 1-length arrays. Other types
+              should be provided as as 2-length arrays, where the first item is
+              the key and the second the value.
+            type: "array"
+            items:
+              type: "array"
+              minItems: 1
+              maxItems: 2
+              items:
+                type: "string"
+            example:
+              [["noexec"]]
+
+  RestartPolicy:
+    description: |
+      The behavior to apply when the container exits. The default is not to
+      restart.
+
+      An ever increasing delay (double the previous delay, starting at 100ms) is
+      added before each restart to prevent flooding the server.
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        description: |
+          - Empty string means not to restart
+          - `no` Do not automatically restart
+          - `always` Always restart
+          - `unless-stopped` Restart always except when the user has manually stopped the container
+          - `on-failure` Restart only when the container exit code is non-zero
+        enum:
+          - ""
+          - "no"
+          - "always"
+          - "unless-stopped"
+          - "on-failure"
+      MaximumRetryCount:
+        type: "integer"
+        description: |
+          If `on-failure` is used, the number of times to retry before giving up.
+
+  Resources:
+    description: "A container's resources (cgroups config, ulimits, etc)"
+    type: "object"
+    properties:
+      # Applicable to all platforms
+      CpuShares:
+        description: |
+          An integer value representing this container's relative CPU weight
+          versus other containers.
+        type: "integer"
+      Memory:
+        description: "Memory limit in bytes."
+        type: "integer"
+        format: "int64"
+        default: 0
+      # Applicable to UNIX platforms
+      CgroupParent:
+        description: |
+          Path to `cgroups` under which the container's `cgroup` is created. If
+          the path is not absolute, the path is considered to be relative to the
+          `cgroups` path of the init process. Cgroups are created if they do not
+          already exist.
+        type: "string"
+      BlkioWeight:
+        description: "Block IO weight (relative weight)."
+        type: "integer"
+        minimum: 0
+        maximum: 1000
+      BlkioWeightDevice:
+        description: |
+          Block IO weight (relative device weight) in the form:
+
+          ```
+          [{"Path": "device_path", "Weight": weight}]
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Path:
+              type: "string"
+            Weight:
+              type: "integer"
+              minimum: 0
+      BlkioDeviceReadBps:
+        description: |
+          Limit read rate (bytes per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteBps:
+        description: |
+          Limit write rate (bytes per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceReadIOps:
+        description: |
+          Limit read rate (IO per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteIOps:
+        description: |
+          Limit write rate (IO per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      CpuPeriod:
+        description: "The length of a CPU period in microseconds."
+        type: "integer"
+        format: "int64"
+      CpuQuota:
+        description: |
+          Microseconds of CPU time that the container can get in a CPU period.
+        type: "integer"
+        format: "int64"
+      CpuRealtimePeriod:
+        description: |
+          The length of a CPU real-time period in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpuRealtimeRuntime:
+        description: |
+          The length of a CPU real-time runtime in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpusetCpus:
+        description: |
+          CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+        type: "string"
+        example: "0-3"
+      CpusetMems:
+        description: |
+          Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only
+          effective on NUMA systems.
+        type: "string"
+      Devices:
+        description: "A list of devices to add to the container."
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceMapping"
+      DeviceCgroupRules:
+        description: "a list of cgroup rules to apply to the container"
+        type: "array"
+        items:
+          type: "string"
+          example: "c 13:* rwm"
+      DeviceRequests:
+        description: |
+          A list of requests for devices to be sent to device drivers.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceRequest"
+      KernelMemoryTCP:
+        description: |
+          Hard limit for kernel TCP buffer memory (in bytes). Depending on the
+          OCI runtime in use, this option may be ignored. It is no longer supported
+          by the default (runc) runtime.
+
+          This field is omitted when empty.
+
+          **Deprecated**: This field is deprecated as kernel 6.12 has deprecated `memory.kmem.tcp.limit_in_bytes` field
+          for cgroups v1. This field will be removed in a future release.
+        type: "integer"
+        format: "int64"
+      MemoryReservation:
+        description: "Memory soft limit in bytes."
+        type: "integer"
+        format: "int64"
+      MemorySwap:
+        description: |
+          Total memory limit (memory + swap). Set as `-1` to enable unlimited
+          swap.
+        type: "integer"
+        format: "int64"
+      MemorySwappiness:
+        description: |
+          Tune a container's memory swappiness behavior. Accepts an integer
+          between 0 and 100.
+        type: "integer"
+        format: "int64"
+        minimum: 0
+        maximum: 100
+      NanoCpus:
+        description: "CPU quota in units of 10<sup>-9</sup> CPUs."
+        type: "integer"
+        format: "int64"
+      OomKillDisable:
+        description: "Disable OOM Killer for the container."
+        type: "boolean"
+      Init:
+        description: |
+          Run an init inside the container that forwards signals and reaps
+          processes. This field is omitted if empty, and the default (as
+          configured on the daemon) is used.
+        type: "boolean"
+        x-nullable: true
+      PidsLimit:
+        description: |
+          Tune a container's PIDs limit. Set `0` or `-1` for unlimited, or `null`
+          to not change.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+      Ulimits:
+        description: |
+          A list of resource limits to set in the container. For example:
+
+          ```
+          {"Name": "nofile", "Soft": 1024, "Hard": 2048}
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Name:
+              description: "Name of ulimit"
+              type: "string"
+            Soft:
+              description: "Soft limit"
+              type: "integer"
+            Hard:
+              description: "Hard limit"
+              type: "integer"
+      # Applicable to Windows
+      CpuCount:
+        description: |
+          The number of usable CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      CpuPercent:
+        description: |
+          The usable percentage of the available CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      IOMaximumIOps:
+        description: "Maximum IOps for the container system drive (Windows only)"
+        type: "integer"
+        format: "int64"
+      IOMaximumBandwidth:
+        description: |
+          Maximum IO in bytes per second for the container system drive
+          (Windows only).
+        type: "integer"
+        format: "int64"
+
+  Limit:
+    description: |
+      An object describing a limit on resources which can be requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      Pids:
+        description: |
+          Limits the maximum number of PIDs in the container. Set `0` for unlimited.
+        type: "integer"
+        format: "int64"
+        default: 0
+        example: 100
+
+  ResourceObject:
+    description: |
+      An object describing the resources which can be advertised by a node and
+      requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+
+  GenericResources:
+    description: |
+      User-defined resources can be either Integer resources (e.g, `SSD=3`) or
+      String resources (e.g, `GPU=UUID1`).
+    type: "array"
+    items:
+      type: "object"
+      properties:
+        NamedResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "string"
+        DiscreteResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "integer"
+              format: "int64"
+    example:
+      - DiscreteResourceSpec:
+          Kind: "SSD"
+          Value: 3
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID1"
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID2"
+
+  HealthConfig:
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
+    type: "object"
+    properties:
+      Test:
+        description: |
+          The test to perform. Possible values are:
+
+          - `[]` inherit healthcheck from image or parent image
+          - `["NONE"]` disable healthcheck
+          - `["CMD", args...]` exec arguments directly
+          - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
+        type: "array"
+        items:
+          type: "string"
+      Interval:
+        description: |
+          The time to wait between checks in nanoseconds. It should be 0 or at
+          least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      Timeout:
+        description: |
+          The time to wait before considering the check to have hung. It should
+          be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
+        type: "integer"
+        format: "int64"
+      Retries:
+        description: |
+          The number of consecutive failures needed to consider a container as
+          unhealthy. 0 means inherit.
+        type: "integer"
+      StartPeriod:
+        description: |
+          Start period for the container to initialize before starting
+          health-retries countdown in nanoseconds. It should be 0 or at least
+          1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      StartInterval:
+        description: |
+          The time to wait between checks in nanoseconds during the start period.
+          It should be 0 or at least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+
+  Health:
+    description: |
+      Health stores information about the container's healthcheck results.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          Status is one of `none`, `starting`, `healthy` or `unhealthy`
+
+          - "none"      Indicates there is no healthcheck
+          - "starting"  Starting indicates that the container is not yet ready
+          - "healthy"   Healthy indicates that the container is running correctly
+          - "unhealthy" Unhealthy indicates that the container has a problem
+        type: "string"
+        enum:
+          - "none"
+          - "starting"
+          - "healthy"
+          - "unhealthy"
+        example: "healthy"
+      FailingStreak:
+        description: "FailingStreak is the number of consecutive failures"
+        type: "integer"
+        example: 0
+      Log:
+        type: "array"
+        description: |
+          Log contains the last few results (oldest first)
+        items:
+          $ref: "#/definitions/HealthcheckResult"
+
+  HealthcheckResult:
+    description: |
+      HealthcheckResult stores information about a single run of a healthcheck probe
+    type: "object"
+    x-nullable: true
+    properties:
+      Start:
+        description: |
+          Date and time at which this check started in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2020-01-04T10:44:24.496525531Z"
+      End:
+        description: |
+          Date and time at which this check ended in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2020-01-04T10:45:21.364524523Z"
+      ExitCode:
+        description: |
+          ExitCode meanings:
+
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (considered unhealthy)
+          - other values: error running probe
+        type: "integer"
+        example: 0
+      Output:
+        description: "Output from last check"
+        type: "string"
+
+  HostConfig:
+    description: "Container configuration that depends on the host we are running on"
+    allOf:
+      - $ref: "#/definitions/Resources"
+      - type: "object"
+        properties:
+          # Applicable to all platforms
+          Binds:
+            type: "array"
+            description: |
+              A list of volume bindings for this container. Each volume binding
+              is a string in one of these forms:
+
+              - `host-src:container-dest[:options]` to bind-mount a host path
+                into the container. Both `host-src`, and `container-dest` must
+                be an _absolute_ path.
+              - `volume-name:container-dest[:options]` to bind-mount a volume
+                managed by a volume driver into the container. `container-dest`
+                must be an _absolute_ path.
+
+              `options` is an optional, comma-delimited list of:
+
+              - `nocopy` disables automatic copying of data from the container
+                path to the volume. The `nocopy` flag only applies to named volumes.
+              - `[ro|rw]` mounts a volume read-only or read-write, respectively.
+                If omitted or set to `rw`, volumes are mounted read-write.
+              - `[z|Z]` applies SELinux labels to allow or deny multiple containers
+                to read and write to the same volume.
+                  - `z`: a _shared_ content label is applied to the content. This
+                    label indicates that multiple containers can share the volume
+                    content, for both reading and writing.
+                  - `Z`: a _private unshared_ label is applied to the content.
+                    This label indicates that only the current container can use
+                    a private volume. Labeling systems such as SELinux require
+                    proper labels to be placed on volume content that is mounted
+                    into a container. Without a label, the security system can
+                    prevent a container's processes from using the content. By
+                    default, the labels set by the host operating system are not
+                    modified.
+              - `[[r]shared|[r]slave|[r]private]` specifies mount
+                [propagation behavior](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt).
+                This only applies to bind-mounted volumes, not internal volumes
+                or named volumes. Mount propagation requires the source mount
+                point (the location where the source directory is mounted in the
+                host operating system) to have the correct propagation properties.
+                For shared volumes, the source mount point must be set to `shared`.
+                For slave volumes, the mount must be set to either `shared` or
+                `slave`.
+            items:
+              type: "string"
+          ContainerIDFile:
+            type: "string"
+            description: "Path to a file where the container ID is written"
+            example: ""
+          LogConfig:
+            type: "object"
+            description: "The logging configuration for this container"
+            properties:
+              Type:
+                description: |-
+                  Name of the logging driver used for the container or "none"
+                  if logging is disabled.
+                type: "string"
+                enum:
+                  - "local"
+                  - "json-file"
+                  - "syslog"
+                  - "journald"
+                  - "gelf"
+                  - "fluentd"
+                  - "awslogs"
+                  - "splunk"
+                  - "etwlogs"
+                  - "none"
+              Config:
+                description: |-
+                  Driver-specific configuration options for the logging driver.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "5"
+                  "max-size": "10m"
+          NetworkMode:
+            type: "string"
+            description: |
+              Network mode to use for this container. Supported standard values
+              are: `bridge`, `host`, `none`, and `container:<name|id>`. Any
+              other value is taken as a custom network's name to which this
+              container should connect to.
+          PortBindings:
+            $ref: "#/definitions/PortMap"
+          RestartPolicy:
+            $ref: "#/definitions/RestartPolicy"
+          AutoRemove:
+            type: "boolean"
+            description: |
+              Automatically remove the container when the container's process
+              exits. This has no effect if `RestartPolicy` is set.
+          VolumeDriver:
+            type: "string"
+            description: "Driver that this container uses to mount volumes."
+          VolumesFrom:
+            type: "array"
+            description: |
+              A list of volumes to inherit from another container, specified in
+              the form `<container name>[:<ro|rw>]`.
+            items:
+              type: "string"
+          Mounts:
+            description: |
+              Specification for mounts to be added to the container.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          ConsoleSize:
+            type: "array"
+            description: |
+              Initial console size, as an `[height, width]` array.
+            x-nullable: true
+            minItems: 2
+            maxItems: 2
+            items:
+              type: "integer"
+              minimum: 0
+            example: [80, 64]
+          Annotations:
+            type: "object"
+            description: |
+              Arbitrary non-identifying metadata attached to container and
+              provided to the runtime when the container is started.
+            additionalProperties:
+              type: "string"
+
+          # Applicable to UNIX platforms
+          CapAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CapDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CgroupnsMode:
+            type: "string"
+            enum:
+              - "private"
+              - "host"
+            description: |
+              cgroup namespace mode for the container. Possible values are:
+
+              - `"private"`: the container runs in its own private cgroup namespace
+              - `"host"`: use the host system's cgroup namespace
+
+              If not specified, the daemon default is used, which can either be `"private"`
+              or `"host"`, depending on daemon version, kernel support and configuration.
+          Dns:
+            type: "array"
+            description: "A list of DNS servers for the container to use."
+            items:
+              type: "string"
+          DnsOptions:
+            type: "array"
+            description: "A list of DNS options."
+            items:
+              type: "string"
+          DnsSearch:
+            type: "array"
+            description: "A list of DNS search domains."
+            items:
+              type: "string"
+          ExtraHosts:
+            type: "array"
+            description: |
+              A list of hostnames/IP mappings to add to the container's `/etc/hosts`
+              file. Specified in the form `["hostname:IP"]`.
+            items:
+              type: "string"
+          GroupAdd:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          IpcMode:
+            type: "string"
+            description: |
+              IPC sharing mode for the container. Possible values are:
+
+              - `"none"`: own private IPC namespace, with /dev/shm not mounted
+              - `"private"`: own private IPC namespace
+              - `"shareable"`: own private IPC namespace, with a possibility to share it with other containers
+              - `"container:<name|id>"`: join another (shareable) container's IPC namespace
+              - `"host"`: use the host system's IPC namespace
+
+              If not specified, daemon default is used, which can either be `"private"`
+              or `"shareable"`, depending on daemon version and configuration.
+          Cgroup:
+            type: "string"
+            description: "Cgroup to use for the container."
+          Links:
+            type: "array"
+            description: |
+              A list of links for the container in the form `container_name:alias`.
+            items:
+              type: "string"
+          OomScoreAdj:
+            type: "integer"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 500
+          PidMode:
+            type: "string"
+            description: |
+              Set the PID (Process) Namespace mode for the container. It can be
+              either:
+
+              - `"container:<name|id>"`: joins another container's PID namespace
+              - `"host"`: use the host's PID namespace inside the container
+          Privileged:
+            type: "boolean"
+            description: |-
+              Gives the container full access to the host.
+          PublishAllPorts:
+            type: "boolean"
+            description: |
+              Allocates an ephemeral host port for all of a container's
+              exposed ports.
+
+              Ports are de-allocated when the container stops and allocated when
+              the container starts. The allocated port might be changed when
+              restarting the container.
+
+              The port is selected from the ephemeral port range that depends on
+              the kernel. For example, on Linux the range is defined by
+              `/proc/sys/net/ipv4/ip_local_port_range`.
+          ReadonlyRootfs:
+            type: "boolean"
+            description: "Mount the container's root filesystem as read only."
+          SecurityOpt:
+            type: "array"
+            description: |
+              A list of string values to customize labels for MLS systems, such
+              as SELinux.
+            items:
+              type: "string"
+          StorageOpt:
+            type: "object"
+            description: |
+              Storage driver options for this container, in the form `{"size": "120G"}`.
+            additionalProperties:
+              type: "string"
+          Tmpfs:
+            type: "object"
+            description: |
+              A map of container directories which should be replaced by tmpfs
+              mounts, and their corresponding mount options. For example:
+
+              ```
+              { "/run": "rw,noexec,nosuid,size=65536k" }
+              ```
+            additionalProperties:
+              type: "string"
+          UTSMode:
+            type: "string"
+            description: "UTS namespace to use for the container."
+          UsernsMode:
+            type: "string"
+            description: |
+              Sets the usernamespace mode for the container when usernamespace
+              remapping option is enabled.
+          ShmSize:
+            type: "integer"
+            format: "int64"
+            description: |
+              Size of `/dev/shm` in bytes. If omitted, the system uses 64MB.
+            minimum: 0
+          Sysctls:
+            type: "object"
+            x-nullable: true
+            description: |-
+              A list of kernel parameters (sysctls) to set in the container.
+
+              This field is omitted if not set.
+            additionalProperties:
+              type: "string"
+            example:
+              "net.ipv4.ip_forward": "1"
+          Runtime:
+            type: "string"
+            x-nullable: true
+            description: |-
+              Runtime to use with this container.
+          # Applicable to Windows
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the container. (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          MaskedPaths:
+            type: "array"
+            description: |
+              The list of paths to be masked inside the container (this overrides
+              the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/asound"
+              - "/proc/acpi"
+              - "/proc/kcore"
+              - "/proc/keys"
+              - "/proc/latency_stats"
+              - "/proc/timer_list"
+              - "/proc/timer_stats"
+              - "/proc/sched_debug"
+              - "/proc/scsi"
+              - "/sys/firmware"
+              - "/sys/devices/virtual/powercap"
+          ReadonlyPaths:
+            type: "array"
+            description: |
+              The list of paths to be set as read-only inside the container
+              (this overrides the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/bus"
+              - "/proc/fs"
+              - "/proc/irq"
+              - "/proc/sys"
+              - "/proc/sysrq-trigger"
+
+  ContainerConfig:
+    description: |
+      Configuration for a container that is portable between hosts.
+    type: "object"
+    properties:
+      Hostname:
+        description: |
+          The hostname to use for the container, as a valid RFC 1123 hostname.
+        type: "string"
+        example: "439f4e91bd1d"
+      Domainname:
+        description: |
+          The domain name to use for the container.
+        type: "string"
+      User:
+        description: |-
+          Commands run as this user inside the container. If omitted, commands
+          run as the user specified in the image the container was started from.
+
+          Can be either user-name or UID, and optional group-name or GID,
+          separated by a colon (`<user-name|UID>[<:group-name|GID>]`).
+        type: "string"
+        example: "123:456"
+      AttachStdin:
+        description: "Whether to attach to `stdin`."
+        type: "boolean"
+        default: false
+      AttachStdout:
+        description: "Whether to attach to `stdout`."
+        type: "boolean"
+        default: true
+      AttachStderr:
+        description: "Whether to attach to `stderr`."
+        type: "boolean"
+        default: true
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Tty:
+        description: |
+          Attach standard streams to a TTY, including `stdin` if it is not closed.
+        type: "boolean"
+        default: false
+      OpenStdin:
+        description: "Open `stdin`"
+        type: "boolean"
+        default: false
+      StdinOnce:
+        description: "Close `stdin` after one attached client disconnects"
+        type: "boolean"
+        default: false
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Image:
+        description: |
+          The name (or reference) of the image to use when creating the container,
+          or which was used when the container was created.
+        type: "string"
+        example: "example-image:1.0"
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      NetworkDisabled:
+        description: "Disable networking for the container."
+        type: "boolean"
+        x-nullable: true
+      MacAddress:
+        description: |
+          MAC address of the container.
+
+          Deprecated: this field is deprecated in API v1.44 and up. Use EndpointSettings.MacAddress instead.
+        type: "string"
+        x-nullable: true
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      StopTimeout:
+        description: "Timeout to stop a container in seconds."
+        type: "integer"
+        default: 10
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  ImageConfig:
+    description: |
+      Configuration of the image. These fields are used as defaults
+      when starting a container from the image.
+    type: "object"
+    properties:
+      User:
+        description: "The user that commands are run as inside the container."
+        type: "string"
+        example: "web:web"
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example:
+          "/app/data": {}
+          "/app/config": {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  NetworkingConfig:
+    description: |
+      NetworkingConfig represents the container's networking configuration for
+      each of its interfaces.
+      It is used for the networking configs specified in the `docker create`
+      and `docker network connect` commands.
+    type: "object"
+    properties:
+      EndpointsConfig:
+        description: |
+          A mapping of network name to endpoint configuration for that network.
+          The endpoint configuration can be left empty to connect to that
+          network with no particular endpoint configuration.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+    example:
+      # putting an example here, instead of using the example values from
+      # /definitions/EndpointSettings, because EndpointSettings contains
+      # operational data returned when inspecting a container that we don't
+      # accept here.
+      EndpointsConfig:
+        isolated_nw:
+          IPAMConfig:
+            IPv4Address: "172.20.30.33"
+            IPv6Address: "2001:db8:abcd::3033"
+            LinkLocalIPs:
+              - "169.254.34.68"
+              - "fe80::3468"
+          MacAddress: "02:42:ac:12:05:02"
+          Links:
+            - "container_1"
+            - "container_2"
+          Aliases:
+            - "server_x"
+            - "server_y"
+        database_nw: {}
+
+  NetworkSettings:
+    description: "NetworkSettings exposes the network settings in the API"
+    type: "object"
+    properties:
+      Bridge:
+        description: |
+          Name of the default bridge interface when dockerd's --bridge flag is set.
+
+          Deprecated: This field is only set when the daemon is started with the --bridge flag specified.
+        type: "string"
+        example: "docker0"
+      SandboxID:
+        description: SandboxID uniquely represents a container's network stack.
+        type: "string"
+        example: "9d12daf2c33f5959c8bf90aa513e4f65b561738661003029ec84830cd503a0c3"
+      HairpinMode:
+        description: |
+          Indicates if hairpin NAT should be enabled on the virtual interface.
+
+          Deprecated: This field is never set and will be removed in a future release.
+        type: "boolean"
+        example: false
+      LinkLocalIPv6Address:
+        description: |
+          IPv6 unicast address using the link-local prefix.
+
+          Deprecated: This field is never set and will be removed in a future release.
+        type: "string"
+        example: ""
+      LinkLocalIPv6PrefixLen:
+        description: |
+          Prefix length of the IPv6 unicast address.
+
+          Deprecated: This field is never set and will be removed in a future release.
+        type: "integer"
+        example: ""
+      Ports:
+        $ref: "#/definitions/PortMap"
+      SandboxKey:
+        description: SandboxKey is the full path of the netns handle
+        type: "string"
+        example: "/var/run/docker/netns/8ab54b426c38"
+
+      SecondaryIPAddresses:
+        description: "Deprecated: This field is never set and will be removed in a future release."
+        type: "array"
+        items:
+          $ref: "#/definitions/Address"
+        x-nullable: true
+
+      SecondaryIPv6Addresses:
+        description: "Deprecated: This field is never set and will be removed in a future release."
+        type: "array"
+        items:
+          $ref: "#/definitions/Address"
+        x-nullable: true
+
+      # TODO properties below are part of DefaultNetworkSettings, which is
+      # marked as deprecated since Docker 1.9 and to be removed in Docker v17.12
+      EndpointID:
+        description: |
+          EndpointID uniquely represents a service endpoint in a Sandbox.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "b88f5b905aabf2893f3cbc4ee42d1ea7980bbc0a92e2c8922b1e1795298afb0b"
+      Gateway:
+        description: |
+          Gateway address for the default "bridge" network.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "172.17.0.1"
+      GlobalIPv6Address:
+        description: |
+          Global IPv6 address for the default "bridge" network.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "2001:db8::5689"
+      GlobalIPv6PrefixLen:
+        description: |
+          Mask length of the global IPv6 address.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "integer"
+        example: 64
+      IPAddress:
+        description: |
+          IPv4 address for the default "bridge" network.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "172.17.0.4"
+      IPPrefixLen:
+        description: |
+          Mask length of the IPv4 address.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "integer"
+        example: 16
+      IPv6Gateway:
+        description: |
+          IPv6 gateway address for this network.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "2001:db8:2::100"
+      MacAddress:
+        description: |
+          MAC address for the container on the default "bridge" network.
+
+          <p><br /></p>
+
+          > **Deprecated**: This field is only propagated when attached to the
+          > default "bridge" network. Use the information from the "bridge"
+          > network inside the `Networks` map instead, which contains the same
+          > information. This field was deprecated in Docker 1.9 and is scheduled
+          > to be removed in Docker 17.12.0
+        type: "string"
+        example: "02:42:ac:11:00:04"
+      Networks:
+        description: |
+          Information about all networks that the container is connected to.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+
+  Address:
+    description: Address represents an IPv4 or IPv6 IP address.
+    type: "object"
+    properties:
+      Addr:
+        description: IP address.
+        type: "string"
+      PrefixLen:
+        description: Mask length of the IP address.
+        type: "integer"
+
+  PortMap:
+    description: |
+      PortMap describes the mapping of container ports to host ports, using the
+      container's port-number and protocol as key in the format `<port>/<protocol>`,
+      for example, `80/udp`.
+
+      If a container's port is mapped for multiple protocols, separate entries
+      are added to the mapping table.
+    type: "object"
+    additionalProperties:
+      type: "array"
+      x-nullable: true
+      items:
+        $ref: "#/definitions/PortBinding"
+    example:
+      "443/tcp":
+        - HostIp: "127.0.0.1"
+          HostPort: "4443"
+      "80/tcp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+        - HostIp: "0.0.0.0"
+          HostPort: "8080"
+      "80/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+      "53/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "53"
+      "2377/tcp": null
+
+  PortBinding:
+    description: |
+      PortBinding represents a binding between a host IP address and a host
+      port.
+    type: "object"
+    properties:
+      HostIp:
+        description: "Host IP address that the container's port is mapped to."
+        type: "string"
+        example: "127.0.0.1"
+      HostPort:
+        description: "Host port number that the container's port is mapped to."
+        type: "string"
+        example: "4443"
+
+  DriverData:
+    description: |
+      Information about the storage driver used to store the container's and
+      image's filesystem.
+    type: "object"
+    required: [Name, Data]
+    properties:
+      Name:
+        description: "Name of the storage driver."
+        type: "string"
+        x-nullable: false
+        example: "overlay2"
+      Data:
+        description: |
+          Low-level storage metadata, provided as key/value pairs.
+
+          This information is driver-specific, and depends on the storage-driver
+          in use, and should be used for informational purposes only.
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example: {
+          "MergedDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/merged",
+          "UpperDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/diff",
+          "WorkDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/work"
+        }
+
+  FilesystemChange:
+    description: |
+      Change in the container's filesystem.
+    type: "object"
+    required: [Path, Kind]
+    properties:
+      Path:
+        description: |
+          Path to file or directory that has changed.
+        type: "string"
+        x-nullable: false
+      Kind:
+        $ref: "#/definitions/ChangeType"
+
+  ChangeType:
+    description: |
+      Kind of change
+
+      Can be one of:
+
+      - `0`: Modified ("C")
+      - `1`: Added ("A")
+      - `2`: Deleted ("D")
+    type: "integer"
+    format: "uint8"
+    enum: [0, 1, 2]
+    x-nullable: false
+
+  ImageInspect:
+    description: |
+      Information about an image in the local image cache.
+    type: "object"
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+      Manifests:
+        description: |
+            Manifests is a list of image manifests available in this image. It
+            provides a more detailed view of the platform-specific image manifests or
+            other image-attached data like build attestations.
+
+            Only available if the daemon provides a multi-platform image store
+            and the `manifests` option is set in the inspect request.
+
+            WARNING: This is experimental and may change at any time without any backward
+            compatibility.
+        type: "array"
+        x-nullable: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Parent:
+        description: |
+          ID of the parent image.
+
+          Depending on how the image was created, this field may be empty and
+          is only set for images that were built/created locally. This field
+          is empty if the image was pulled from an image registry.
+
+          > **Deprecated**: This field is only set when using the deprecated
+          > legacy builder. It is included in API responses for informational
+          > purposes, but should not be depended on as it will be omitted
+          > once the legacy builder is removed.
+        type: "string"
+        x-nullable: false
+        example: ""
+      Comment:
+        description: |
+          Optional message that was set when committing or importing the image.
+        type: "string"
+        x-nullable: false
+        example: ""
+      Created:
+        description: |
+          Date and time at which the image was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+          This information is only available if present in the image,
+          and omitted otherwise.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2022-02-04T21:20:12.497794809Z"
+      DockerVersion:
+        description: |
+          The version of Docker that was used to build the image.
+
+          Depending on how the image was created, this field may be empty.
+
+          > **Deprecated**: This field is only set when using the deprecated
+          > legacy builder. It is included in API responses for informational
+          > purposes, but should not be depended on as it will be omitted
+          > once the legacy builder is removed.
+        type: "string"
+        x-nullable: false
+        example: "27.0.1"
+      Author:
+        description: |
+          Name of the author that was specified when committing the image, or as
+          specified through MAINTAINER (deprecated) in the Dockerfile.
+        type: "string"
+        x-nullable: false
+        example: ""
+      Config:
+        $ref: "#/definitions/ImageConfig"
+      Architecture:
+        description: |
+          Hardware CPU architecture that the image runs on.
+        type: "string"
+        x-nullable: false
+        example: "arm"
+      Variant:
+        description: |
+          CPU architecture variant (presently ARM-only).
+        type: "string"
+        x-nullable: true
+        example: "v7"
+      Os:
+        description: |
+          Operating System the image is built to run on.
+        type: "string"
+        x-nullable: false
+        example: "linux"
+      OsVersion:
+        description: |
+          Operating System version the image is built to run on (especially
+          for Windows).
+        type: "string"
+        example: ""
+        x-nullable: true
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      GraphDriver:
+        $ref: "#/definitions/DriverData"
+      RootFS:
+        description: |
+          Information about the image's RootFS, including the layer IDs.
+        type: "object"
+        required: [Type]
+        properties:
+          Type:
+            type: "string"
+            x-nullable: false
+            example: "layers"
+          Layers:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "sha256:1834950e52ce4d5a88a1bbd131c537f4d0e56d10ff0dd69e66be3b7dfa9df7e6"
+              - "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"
+      Metadata:
+        description: |
+          Additional metadata of the image in the local cache. This information
+          is local to the daemon, and not part of the image itself.
+        type: "object"
+        properties:
+          LastTagTime:
+            description: |
+              Date and time at which the image was last tagged in
+              [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+              This information is only available if the image was tagged locally,
+              and omitted otherwise.
+            type: "string"
+            format: "dateTime"
+            example: "2022-02-28T14:40:02.623929178Z"
+            x-nullable: true
+
+  ImageSummary:
+    type: "object"
+    x-go-name: "Summary"
+    required:
+      - Id
+      - ParentId
+      - RepoTags
+      - RepoDigests
+      - Created
+      - Size
+      - SharedSize
+      - Labels
+      - Containers
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      ParentId:
+        description: |
+          ID of the parent image.
+
+          Depending on how the image was created, this field may be empty and
+          is only set for images that were built/created locally. This field
+          is empty if the image was pulled from an image registry.
+        type: "string"
+        x-nullable: false
+        example: ""
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Created:
+        description: |
+          Date and time at which the image was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        x-nullable: false
+        example: "1644009612"
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 172064416
+      SharedSize:
+        description: |
+          Total size of image layers that are shared between this image and other
+          images.
+
+          This size is not calculated by default. `-1` indicates that the value
+          has not been set / calculated.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Containers:
+        description: |
+          Number of containers using this image. Includes both stopped and running
+          containers.
+
+          `-1` indicates that the value has not been set / calculated.
+        x-nullable: false
+        type: "integer"
+        example: 2
+      Manifests:
+        description: |
+          Manifests is a list of manifests available in this image.
+          It provides a more detailed view of the platform-specific image manifests
+          or other image-attached data like build attestations.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        type: "array"
+        x-nullable: false
+        x-omitempty: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+
+  AuthConfig:
+    type: "object"
+    properties:
+      username:
+        type: "string"
+      password:
+        type: "string"
+      email:
+        description: |
+          Email is an optional value associated with the username.
+
+          > **Deprecated**: This field is deprecated since docker 1.11 (API v1.23) and will be removed in a future release.
+        type: "string"
+      serveraddress:
+        type: "string"
+    example:
+      username: "hannibal"
+      password: "xxxx"
+      serveraddress: "https://index.docker.io/v1/"
+
+  ProcessConfig:
+    type: "object"
+    properties:
+      privileged:
+        type: "boolean"
+      user:
+        type: "string"
+      tty:
+        type: "boolean"
+      entrypoint:
+        type: "string"
+      arguments:
+        type: "array"
+        items:
+          type: "string"
+
+  Volume:
+    type: "object"
+    required: [Name, Driver, Mountpoint, Labels, Scope, Options]
+    properties:
+      Name:
+        type: "string"
+        description: "Name of the volume."
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        type: "string"
+        description: "Name of the volume driver used by the volume."
+        x-nullable: false
+        example: "custom"
+      Mountpoint:
+        type: "string"
+        description: "Mount path of the volume on the host."
+        x-nullable: false
+        example: "/var/lib/docker/volumes/tardis"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        description: "Date/Time the volume was created."
+        example: "2016-06-07T20:31:11.853781916Z"
+      Status:
+        type: "object"
+        description: |
+          Low-level details about the volume, provided by the volume driver.
+          Details are returned as a map with key/value pairs:
+          `{"key":"value","key2":"value2"}`.
+
+          The `Status` field is optional, and is omitted if the volume driver
+          does not support this feature.
+        additionalProperties:
+          type: "object"
+        example:
+          hello: "world"
+      Labels:
+        type: "object"
+        description: "User-defined key/value metadata."
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Scope:
+        type: "string"
+        description: |
+          The level at which the volume exists. Either `global` for cluster-wide,
+          or `local` for machine level.
+        default: "local"
+        x-nullable: false
+        enum: ["local", "global"]
+        example: "local"
+      ClusterVolume:
+        $ref: "#/definitions/ClusterVolume"
+      Options:
+        type: "object"
+        description: |
+          The driver specific options used when creating the volume.
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      UsageData:
+        type: "object"
+        x-nullable: true
+        x-go-name: "UsageData"
+        required: [Size, RefCount]
+        description: |
+          Usage details about the volume. This information is used by the
+          `GET /system/df` endpoint, and omitted in other endpoints.
+        properties:
+          Size:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              Amount of disk space used by the volume (in bytes). This information
+              is only available for volumes created with the `"local"` volume
+              driver. For volumes created with other volume drivers, this field
+              is set to `-1` ("not available")
+            x-nullable: false
+          RefCount:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              The number of containers referencing this volume. This field
+              is set to `-1` if the reference-count is not available.
+            x-nullable: false
+
+  VolumeCreateOptions:
+    description: "Volume configuration"
+    type: "object"
+    title: "VolumeConfig"
+    x-go-name: "CreateOptions"
+    properties:
+      Name:
+        description: |
+          The new volume's name. If not specified, Docker generates a name.
+        type: "string"
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        description: "Name of the volume driver to use."
+        type: "string"
+        default: "local"
+        x-nullable: false
+        example: "custom"
+      DriverOpts:
+        description: |
+          A mapping of driver options and values. These options are
+          passed directly to the driver and are driver specific.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      ClusterVolumeSpec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+
+  VolumeListResponse:
+    type: "object"
+    title: "VolumeListResponse"
+    x-go-name: "ListResponse"
+    description: "Volume list response"
+    properties:
+      Volumes:
+        type: "array"
+        description: "List of volumes"
+        items:
+          $ref: "#/definitions/Volume"
+      Warnings:
+        type: "array"
+        description: |
+          Warnings that occurred when fetching the list of volumes.
+        items:
+          type: "string"
+        example: []
+
+  Network:
+    type: "object"
+    properties:
+      Name:
+        description: |
+          Name of the network.
+        type: "string"
+        example: "my_network"
+      Id:
+        description: |
+          ID that uniquely identifies a network on a single machine.
+        type: "string"
+        example: "7d86d31b1478e7cca9ebed7e73aa0fdeec46c5ca29497431d3007d2d9e15ed99"
+      Created:
+        description: |
+          Date and time at which the network was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-10-19T04:33:30.360899459Z"
+      Scope:
+        description: |
+          The level at which the network exists (e.g. `swarm` for cluster-wide
+          or `local` for machine level)
+        type: "string"
+        example: "local"
+      Driver:
+        description: |
+          The name of the driver used to create the network (e.g. `bridge`,
+          `overlay`).
+        type: "string"
+        example: "overlay"
+      EnableIPv4:
+        description: |
+          Whether the network was created with IPv4 enabled.
+        type: "boolean"
+        example: true
+      EnableIPv6:
+        description: |
+          Whether the network was created with IPv6 enabled.
+        type: "boolean"
+        example: false
+      IPAM:
+        $ref: "#/definitions/IPAM"
+      Internal:
+        description: |
+          Whether the network is created to only allow internal networking
+          connectivity.
+        type: "boolean"
+        default: false
+        example: false
+      Attachable:
+        description: |
+          Whether a global / swarm scope network is manually attachable by regular
+          containers from workers in swarm mode.
+        type: "boolean"
+        default: false
+        example: false
+      Ingress:
+        description: |
+          Whether the network is providing the routing-mesh for the swarm cluster.
+        type: "boolean"
+        default: false
+        example: false
+      ConfigFrom:
+        $ref: "#/definitions/ConfigReference"
+      ConfigOnly:
+        description: |
+          Whether the network is a config-only network. Config-only networks are
+          placeholder networks for network configurations to be used by other
+          networks. Config-only networks cannot be used directly to run containers
+          or services.
+        type: "boolean"
+        default: false
+      Containers:
+        description: |
+          Contains endpoints attached to the network.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/NetworkContainer"
+        example:
+          19a4d5d687db25203351ed79d478946f861258f018fe384f229f2efa4b23513c:
+            Name: "test"
+            EndpointID: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+            MacAddress: "02:42:ac:13:00:02"
+            IPv4Address: "172.19.0.2/16"
+            IPv6Address: ""
+      Options:
+        description: |
+          Network-specific options uses when creating the network.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.docker.network.bridge.default_bridge: "true"
+          com.docker.network.bridge.enable_icc: "true"
+          com.docker.network.bridge.enable_ip_masquerade: "true"
+          com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+          com.docker.network.bridge.name: "docker0"
+          com.docker.network.driver.mtu: "1500"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Peers:
+        description: |
+          List of peer nodes for an overlay network. This field is only present
+          for overlay networks, and omitted for other network types.
+        type: "array"
+        items:
+          $ref: "#/definitions/PeerInfo"
+        x-nullable: true
+      # TODO: Add Services (only present when "verbose" is set).
+
+  ConfigReference:
+    description: |
+      The config-only network source to provide the configuration for
+      this network.
+    type: "object"
+    properties:
+      Network:
+        description: |
+          The name of the config-only network that provides the network's
+          configuration. The specified network must be an existing config-only
+          network. Only network names are allowed, not network IDs.
+        type: "string"
+        example: "config_only_network_01"
+
+  IPAM:
+    type: "object"
+    properties:
+      Driver:
+        description: "Name of the IPAM driver to use."
+        type: "string"
+        default: "default"
+        example: "default"
+      Config:
+        description: |
+          List of IPAM configuration options, specified as a map:
+
+          ```
+          {"Subnet": <CIDR>, "IPRange": <CIDR>, "Gateway": <IP address>, "AuxAddress": <device_name:IP address>}
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/IPAMConfig"
+      Options:
+        description: "Driver-specific options, specified as a map."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+
+  IPAMConfig:
+    type: "object"
+    properties:
+      Subnet:
+        type: "string"
+        example: "172.20.0.0/16"
+      IPRange:
+        type: "string"
+        example: "172.20.10.0/24"
+      Gateway:
+        type: "string"
+        example: "172.20.10.11"
+      AuxiliaryAddresses:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  NetworkContainer:
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        example: "container_1"
+      EndpointID:
+        type: "string"
+        example: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+      MacAddress:
+        type: "string"
+        example: "02:42:ac:13:00:02"
+      IPv4Address:
+        type: "string"
+        example: "172.19.0.2/16"
+      IPv6Address:
+        type: "string"
+        example: ""
+
+  PeerInfo:
+    description: |
+      PeerInfo represents one peer of an overlay network.
+    type: "object"
+    properties:
+      Name:
+        description:
+          ID of the peer-node in the Swarm cluster.
+        type: "string"
+        example: "6869d7c1732b"
+      IP:
+        description:
+          IP-address of the peer-node in the Swarm cluster.
+        type: "string"
+        example: "10.133.77.91"
+
+  NetworkCreateResponse:
+    description: "OK response to NetworkCreate operation"
+    type: "object"
+    title: "NetworkCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warning]
+    properties:
+      Id:
+        description: "The ID of the created network."
+        type: "string"
+        x-nullable: false
+        example: "b5c4fc71e8022147cd25de22b22173de4e3b170134117172eb595cb91b4e7e5d"
+      Warning:
+        description: "Warnings encountered when creating the container"
+        type: "string"
+        x-nullable: false
+        example: ""
+
+  BuildInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      stream:
+        type: "string"
+      error:
+        type: "string"
+        x-nullable: true
+        description: |-
+          errors encountered during the operation.
+
+
+          > **Deprecated**: This field is deprecated since API v1.4, and will be omitted in a future API version. Use the information in errorDetail instead.
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progress:
+        type: "string"
+        x-nullable: true
+        description: |-
+          Progress is a pre-formatted presentation of progressDetail.
+
+
+          > **Deprecated**: This field is deprecated since API v1.8, and will be omitted in a future API version. Use the information in progressDetail instead.
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+      aux:
+        $ref: "#/definitions/ImageID"
+
+  BuildCache:
+    type: "object"
+    description: |
+      BuildCache contains information about a build cache record.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          Unique ID of the build cache record.
+        example: "ndlpt0hhvkqcdfkputsk4cq9c"
+      Parents:
+        description: |
+          List of parent build cache record IDs.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example: ["hw53o5aio51xtltp5xjp8v7fx"]
+      Type:
+        type: "string"
+        description: |
+          Cache record type.
+        example: "regular"
+        # see https://github.com/moby/buildkit/blob/fce4a32258dc9d9664f71a4831d5de10f0670677/client/diskusage.go#L75-L84
+        enum:
+          - "internal"
+          - "frontend"
+          - "source.local"
+          - "source.git.checkout"
+          - "exec.cachemount"
+          - "regular"
+      Description:
+        type: "string"
+        description: |
+          Description of the build-step that produced the build cache.
+        example: "mount / from exec /bin/sh -c echo 'Binary::apt::APT::Keep-Downloaded-Packages \"true\";' > /etc/apt/apt.conf.d/keep-cache"
+      InUse:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is in use.
+        example: false
+      Shared:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is shared.
+        example: true
+      Size:
+        description: |
+          Amount of disk space used by the build cache (in bytes).
+        type: "integer"
+        example: 51
+      CreatedAt:
+        description: |
+          Date and time at which the build cache was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      LastUsedAt:
+        description: |
+          Date and time at which the build cache was last used in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2017-08-09T07:09:37.632105588Z"
+      UsageCount:
+        type: "integer"
+        example: 26
+
+  ImageID:
+    type: "object"
+    description: "Image ID or Digest"
+    properties:
+      ID:
+        type: "string"
+    example:
+      ID: "sha256:85f05633ddc1c50679be2b16a0479ab6f7637f8884e0cfe0f4d20e1ebb3d6e7c"
+
+  CreateImageInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      error:
+        type: "string"
+        x-nullable: true
+        description: |-
+          errors encountered during the operation.
+
+
+          > **Deprecated**: This field is deprecated since API v1.4, and will be omitted in a future API version. Use the information in errorDetail instead.
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progress:
+        type: "string"
+        x-nullable: true
+        description: |-
+          Progress is a pre-formatted presentation of progressDetail.
+
+
+          > **Deprecated**: This field is deprecated since API v1.8, and will be omitted in a future API version. Use the information in progressDetail instead.
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  PushImageInfo:
+    type: "object"
+    properties:
+      error:
+        type: "string"
+        x-nullable: true
+        description: |-
+          errors encountered during the operation.
+
+
+          > **Deprecated**: This field is deprecated since API v1.4, and will be omitted in a future API version. Use the information in errorDetail instead.
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progress:
+        type: "string"
+        x-nullable: true
+        description: |-
+          Progress is a pre-formatted presentation of progressDetail.
+
+
+          > **Deprecated**: This field is deprecated since API v1.8, and will be omitted in a future API version. Use the information in progressDetail instead.
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  DeviceInfo:
+    type: "object"
+    description: |
+      DeviceInfo represents a device that can be used by a container.
+    properties:
+      Source:
+        type: "string"
+        example: "cdi"
+        description: |
+          The origin device driver.
+      ID:
+        type: "string"
+        example: "vendor.com/gpu=0"
+        description: |
+          The unique identifier for the device within its source driver.
+          For CDI devices, this would be an FQDN like "vendor.com/gpu=0".
+
+  ErrorDetail:
+    type: "object"
+    properties:
+      code:
+        type: "integer"
+      message:
+        type: "string"
+
+  ProgressDetail:
+    type: "object"
+    properties:
+      current:
+        type: "integer"
+      total:
+        type: "integer"
+
+  ErrorResponse:
+    description: "Represents an error."
+    type: "object"
+    required: ["message"]
+    properties:
+      message:
+        description: "The error message."
+        type: "string"
+        x-nullable: false
+    example:
+      message: "Something went wrong."
+
+  IDResponse:
+    description: "Response to an API call that returns just an Id"
+    type: "object"
+    x-go-name: "IDResponse"
+    required: ["Id"]
+    properties:
+      Id:
+        description: "The id of the newly created object."
+        type: "string"
+        x-nullable: false
+
+  EndpointSettings:
+    description: "Configuration for a network endpoint."
+    type: "object"
+    properties:
+      # Configurations
+      IPAMConfig:
+        $ref: "#/definitions/EndpointIPAMConfig"
+      Links:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "container_1"
+          - "container_2"
+      MacAddress:
+        description: |
+          MAC address for the endpoint on this network. The network driver might ignore this parameter.
+        type: "string"
+        example: "02:42:ac:11:00:04"
+      Aliases:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "server_x"
+          - "server_y"
+      DriverOpts:
+        description: |
+          DriverOpts is a mapping of driver options and values. These options
+          are passed directly to the driver and are driver specific.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      GwPriority:
+        description: |
+          This property determines which endpoint will provide the default
+          gateway for a container. The endpoint with the highest priority will
+          be used. If multiple endpoints have the same priority, endpoints are
+          lexicographically sorted based on their network name, and the one
+          that sorts first is picked.
+        type: "integer"
+        format: "int64"
+        example:
+          - 10
+
+      # Operational data
+      NetworkID:
+        description: |
+          Unique ID of the network.
+        type: "string"
+        example: "08754567f1f40222263eab4102e1c733ae697e8e354aa9cd6e18d7402835292a"
+      EndpointID:
+        description: |
+          Unique ID for the service endpoint in a Sandbox.
+        type: "string"
+        example: "b88f5b905aabf2893f3cbc4ee42d1ea7980bbc0a92e2c8922b1e1795298afb0b"
+      Gateway:
+        description: |
+          Gateway address for this network.
+        type: "string"
+        example: "172.17.0.1"
+      IPAddress:
+        description: |
+          IPv4 address.
+        type: "string"
+        example: "172.17.0.4"
+      IPPrefixLen:
+        description: |
+          Mask length of the IPv4 address.
+        type: "integer"
+        example: 16
+      IPv6Gateway:
+        description: |
+          IPv6 gateway address.
+        type: "string"
+        example: "2001:db8:2::100"
+      GlobalIPv6Address:
+        description: |
+          Global IPv6 address.
+        type: "string"
+        example: "2001:db8::5689"
+      GlobalIPv6PrefixLen:
+        description: |
+          Mask length of the global IPv6 address.
+        type: "integer"
+        format: "int64"
+        example: 64
+      DNSNames:
+        description: |
+          List of all DNS names an endpoint has on a specific network. This
+          list is based on the container name, network aliases, container short
+          ID, and hostname.
+
+          These DNS names are non-fully qualified but can contain several dots.
+          You can get fully qualified DNS names by appending `.<network-name>`.
+          For instance, if container name is `my.ctr` and the network is named
+          `testnet`, `DNSNames` will contain `my.ctr` and the FQDN will be
+          `my.ctr.testnet`.
+        type: array
+        items:
+          type: string
+        example: ["foobar", "server_x", "server_y", "my.ctr"]
+
+  EndpointIPAMConfig:
+    description: |
+      EndpointIPAMConfig represents an endpoint's IPAM configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      IPv4Address:
+        type: "string"
+        example: "172.20.30.33"
+      IPv6Address:
+        type: "string"
+        example: "2001:db8:abcd::3033"
+      LinkLocalIPs:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "169.254.34.68"
+          - "fe80::3468"
+
+  PluginMount:
+    type: "object"
+    x-nullable: false
+    required: [Name, Description, Settable, Source, Destination, Type, Options]
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "some-mount"
+      Description:
+        type: "string"
+        x-nullable: false
+        example: "This is a mount that's used by the plugin."
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Source:
+        type: "string"
+        example: "/var/lib/docker/plugins/"
+      Destination:
+        type: "string"
+        x-nullable: false
+        example: "/mnt/state"
+      Type:
+        type: "string"
+        x-nullable: false
+        example: "bind"
+      Options:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "rbind"
+          - "rw"
+
+  PluginDevice:
+    type: "object"
+    required: [Name, Description, Settable, Path]
+    x-nullable: false
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+      Description:
+        type: "string"
+        x-nullable: false
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Path:
+        type: "string"
+        example: "/dev/fuse"
+
+  PluginEnv:
+    type: "object"
+    x-nullable: false
+    required: [Name, Description, Settable, Value]
+    properties:
+      Name:
+        x-nullable: false
+        type: "string"
+      Description:
+        x-nullable: false
+        type: "string"
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Value:
+        type: "string"
+
+  PluginInterfaceType:
+    type: "object"
+    x-nullable: false
+    required: [Prefix, Capability, Version]
+    properties:
+      Prefix:
+        type: "string"
+        x-nullable: false
+      Capability:
+        type: "string"
+        x-nullable: false
+      Version:
+        type: "string"
+        x-nullable: false
+
+  PluginPrivilege:
+    description: |
+      Describes a permission the user has to accept upon installing
+      the plugin.
+    type: "object"
+    x-go-name: "PluginPrivilege"
+    properties:
+      Name:
+        type: "string"
+        example: "network"
+      Description:
+        type: "string"
+      Value:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "host"
+
+  Plugin:
+    description: "A plugin for the Engine API"
+    type: "object"
+    required: [Settings, Enabled, Config, Name]
+    properties:
+      Id:
+        type: "string"
+        example: "5724e2c8652da337ab2eedd19fc6fc0ec908e4bd907c7421bf6a8dfc70c4c078"
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "tiborvass/sample-volume-plugin"
+      Enabled:
+        description:
+          True if the plugin is running. False if the plugin is not running,
+          only installed.
+        type: "boolean"
+        x-nullable: false
+        example: true
+      Settings:
+        description: "Settings that can be modified by users."
+        type: "object"
+        x-nullable: false
+        required: [Args, Devices, Env, Mounts]
+        properties:
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "DEBUG=0"
+          Args:
+            type: "array"
+            items:
+              type: "string"
+          Devices:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginDevice"
+      PluginReference:
+        description: "plugin remote reference used to push/pull the plugin"
+        type: "string"
+        x-nullable: false
+        example: "localhost:5000/tiborvass/sample-volume-plugin:latest"
+      Config:
+        description: "The config of a plugin."
+        type: "object"
+        x-nullable: false
+        required:
+          - Description
+          - Documentation
+          - Interface
+          - Entrypoint
+          - WorkDir
+          - Network
+          - Linux
+          - PidHost
+          - PropagatedMount
+          - IpcHost
+          - Mounts
+          - Env
+          - Args
+        properties:
+          DockerVersion:
+            description: |-
+              Docker Version used to create the plugin.
+
+              Depending on how the plugin was created, this field may be empty or omitted.
+
+              Deprecated: this field is no longer set, and will be removed in the next API version.
+            type: "string"
+            x-nullable: false
+            x-omitempty: true
+          Description:
+            type: "string"
+            x-nullable: false
+            example: "A sample volume plugin for Docker"
+          Documentation:
+            type: "string"
+            x-nullable: false
+            example: "https://docs.docker.com/engine/extend/plugins/"
+          Interface:
+            description: "The interface between Docker and the plugin"
+            x-nullable: false
+            type: "object"
+            required: [Types, Socket]
+            properties:
+              Types:
+                type: "array"
+                items:
+                  $ref: "#/definitions/PluginInterfaceType"
+                example:
+                  - "docker.volumedriver/1.0"
+              Socket:
+                type: "string"
+                x-nullable: false
+                example: "plugins.sock"
+              ProtocolScheme:
+                type: "string"
+                example: "some.protocol/v1.0"
+                description: "Protocol to use for clients connecting to the plugin."
+                enum:
+                  - ""
+                  - "moby.plugins.http/v1"
+          Entrypoint:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "/usr/bin/sample-volume-plugin"
+              - "/data"
+          WorkDir:
+            type: "string"
+            x-nullable: false
+            example: "/bin/"
+          User:
+            type: "object"
+            x-nullable: false
+            properties:
+              UID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+              GID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+          Network:
+            type: "object"
+            x-nullable: false
+            required: [Type]
+            properties:
+              Type:
+                x-nullable: false
+                type: "string"
+                example: "host"
+          Linux:
+            type: "object"
+            x-nullable: false
+            required: [Capabilities, AllowAllDevices, Devices]
+            properties:
+              Capabilities:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "CAP_SYS_ADMIN"
+                  - "CAP_SYSLOG"
+              AllowAllDevices:
+                type: "boolean"
+                x-nullable: false
+                example: false
+              Devices:
+                type: "array"
+                items:
+                  $ref: "#/definitions/PluginDevice"
+          PropagatedMount:
+            type: "string"
+            x-nullable: false
+            example: "/mnt/volumes"
+          IpcHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          PidHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginEnv"
+            example:
+              - Name: "DEBUG"
+                Description: "If set, prints debug messages"
+                Settable: null
+                Value: "0"
+          Args:
+            type: "object"
+            x-nullable: false
+            required: [Name, Description, Settable, Value]
+            properties:
+              Name:
+                x-nullable: false
+                type: "string"
+                example: "args"
+              Description:
+                x-nullable: false
+                type: "string"
+                example: "command line arguments"
+              Settable:
+                type: "array"
+                items:
+                  type: "string"
+              Value:
+                type: "array"
+                items:
+                  type: "string"
+          rootfs:
+            type: "object"
+            properties:
+              type:
+                type: "string"
+                example: "layers"
+              diff_ids:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "sha256:675532206fbf3030b8458f88d6e26d4eb1577688a25efec97154c94e8b6b4887"
+                  - "sha256:e216a057b1cb1efc11f8a268f37ef62083e70b1b38323ba252e25ac88904a7e8"
+
+  ObjectVersion:
+    description: |
+      The version number of the object such as node, service, etc. This is needed
+      to avoid conflicting writes. The client must send the version number along
+      with the modified specification when updating these objects.
+
+      This approach ensures safe concurrency and determinism in that the change
+      on the object may not be applied if the version number has changed from the
+      last read. In other words, if two update requests specify the same base
+      version, only one of the requests can succeed. As a result, two separate
+      update requests that happen at the same time will not unintentionally
+      overwrite each other.
+    type: "object"
+    properties:
+      Index:
+        type: "integer"
+        format: "uint64"
+        example: 373531
+
+  NodeSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "Name for the node."
+        type: "string"
+        example: "my-node"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Role:
+        description: "Role of the node."
+        type: "string"
+        enum:
+          - "worker"
+          - "manager"
+        example: "manager"
+      Availability:
+        description: "Availability of the node."
+        type: "string"
+        enum:
+          - "active"
+          - "pause"
+          - "drain"
+        example: "active"
+    example:
+      Availability: "active"
+      Name: "node-name"
+      Role: "manager"
+      Labels:
+        foo: "bar"
+
+  Node:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "24ifsmvkjbyhk"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the node was added to the swarm in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the node was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/NodeSpec"
+      Description:
+        $ref: "#/definitions/NodeDescription"
+      Status:
+        $ref: "#/definitions/NodeStatus"
+      ManagerStatus:
+        $ref: "#/definitions/ManagerStatus"
+
+  NodeDescription:
+    description: |
+      NodeDescription encapsulates the properties of the Node as reported by the
+      agent.
+    type: "object"
+    properties:
+      Hostname:
+        type: "string"
+        example: "bf3067039e47"
+      Platform:
+        $ref: "#/definitions/Platform"
+      Resources:
+        $ref: "#/definitions/ResourceObject"
+      Engine:
+        $ref: "#/definitions/EngineDescription"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+
+  Platform:
+    description: |
+      Platform represents the platform (Arch/OS).
+    type: "object"
+    properties:
+      Architecture:
+        description: |
+          Architecture represents the hardware architecture (for example,
+          `x86_64`).
+        type: "string"
+        example: "x86_64"
+      OS:
+        description: |
+          OS represents the Operating System (for example, `linux` or `windows`).
+        type: "string"
+        example: "linux"
+
+  EngineDescription:
+    description: "EngineDescription provides information about an engine."
+    type: "object"
+    properties:
+      EngineVersion:
+        type: "string"
+        example: "17.06.0"
+      Labels:
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+      Plugins:
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Type:
+              type: "string"
+            Name:
+              type: "string"
+        example:
+          - Type: "Log"
+            Name: "awslogs"
+          - Type: "Log"
+            Name: "fluentd"
+          - Type: "Log"
+            Name: "gcplogs"
+          - Type: "Log"
+            Name: "gelf"
+          - Type: "Log"
+            Name: "journald"
+          - Type: "Log"
+            Name: "json-file"
+          - Type: "Log"
+            Name: "splunk"
+          - Type: "Log"
+            Name: "syslog"
+          - Type: "Network"
+            Name: "bridge"
+          - Type: "Network"
+            Name: "host"
+          - Type: "Network"
+            Name: "ipvlan"
+          - Type: "Network"
+            Name: "macvlan"
+          - Type: "Network"
+            Name: "null"
+          - Type: "Network"
+            Name: "overlay"
+          - Type: "Volume"
+            Name: "local"
+          - Type: "Volume"
+            Name: "localhost:5000/vieux/sshfs:latest"
+          - Type: "Volume"
+            Name: "vieux/sshfs:latest"
+
+  TLSInfo:
+    description: |
+      Information about the issuer of leaf TLS certificates and the trusted root
+      CA certificate.
+    type: "object"
+    properties:
+      TrustRoot:
+        description: |
+          The root CA certificate(s) that are used to validate leaf TLS
+          certificates.
+        type: "string"
+      CertIssuerSubject:
+        description:
+          The base64-url-safe-encoded raw subject bytes of the issuer.
+        type: "string"
+      CertIssuerPublicKey:
+        description: |
+          The base64-url-safe-encoded raw public key bytes of the issuer.
+        type: "string"
+    example:
+      TrustRoot: |
+        -----BEGIN CERTIFICATE-----
+        MIIBajCCARCgAwIBAgIUbYqrLSOSQHoxD8CwG6Bi2PJi9c8wCgYIKoZIzj0EAwIw
+        EzERMA8GA1UEAxMIc3dhcm0tY2EwHhcNMTcwNDI0MjE0MzAwWhcNMzcwNDE5MjE0
+        MzAwWjATMREwDwYDVQQDEwhzd2FybS1jYTBZMBMGByqGSM49AgEGCCqGSM49AwEH
+        A0IABJk/VyMPYdaqDXJb/VXh5n/1Yuv7iNrxV3Qb3l06XD46seovcDWs3IZNV1lf
+        3Skyr0ofcchipoiHkXBODojJydSjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB
+        Af8EBTADAQH/MB0GA1UdDgQWBBRUXxuRcnFjDfR/RIAUQab8ZV/n4jAKBggqhkjO
+        PQQDAgNIADBFAiAy+JTe6Uc3KyLCMiqGl2GyWGQqQDEcO3/YG36x7om65AIhAJvz
+        pxv6zFeVEkAEEkqIYi0omA9+CjanB/6Bz4n1uw8H
+        -----END CERTIFICATE-----
+      CertIssuerSubject: "MBMxETAPBgNVBAMTCHN3YXJtLWNh"
+      CertIssuerPublicKey: "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmT9XIw9h1qoNclv9VeHmf/Vi6/uI2vFXdBveXTpcPjqx6i9wNazchk1XWV/dKTKvSh9xyGKmiIeRcE4OiMnJ1A=="
+
+  NodeStatus:
+    description: |
+      NodeStatus represents the status of a node.
+
+      It provides the current status of the node, as seen by the manager.
+    type: "object"
+    properties:
+      State:
+        $ref: "#/definitions/NodeState"
+      Message:
+        type: "string"
+        example: ""
+      Addr:
+        description: "IP address of the node."
+        type: "string"
+        example: "172.17.0.2"
+
+  NodeState:
+    description: "NodeState represents the state of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "down"
+      - "ready"
+      - "disconnected"
+    example: "ready"
+
+  ManagerStatus:
+    description: |
+      ManagerStatus represents the status of a manager.
+
+      It provides the current status of a node's manager component, if the node
+      is a manager.
+    x-nullable: true
+    type: "object"
+    properties:
+      Leader:
+        type: "boolean"
+        default: false
+        example: true
+      Reachability:
+        $ref: "#/definitions/Reachability"
+      Addr:
+        description: |
+          The IP address and port at which the manager is reachable.
+        type: "string"
+        example: "10.0.0.46:2377"
+
+  Reachability:
+    description: "Reachability represents the reachability of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "unreachable"
+      - "reachable"
+    example: "reachable"
+
+  SwarmSpec:
+    description: "User modifiable swarm configuration."
+    type: "object"
+    properties:
+      Name:
+        description: "Name of the swarm."
+        type: "string"
+        example: "default"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.corp.type: "production"
+          com.example.corp.department: "engineering"
+      Orchestration:
+        description: "Orchestration configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          TaskHistoryRetentionLimit:
+            description: |
+              The number of historic tasks to keep per instance or node. If
+              negative, never remove completed or failed tasks.
+            type: "integer"
+            format: "int64"
+            example: 10
+      Raft:
+        description: "Raft configuration."
+        type: "object"
+        properties:
+          SnapshotInterval:
+            description: "The number of log entries between snapshots."
+            type: "integer"
+            format: "uint64"
+            example: 10000
+          KeepOldSnapshots:
+            description: |
+              The number of snapshots to keep beyond the current snapshot.
+            type: "integer"
+            format: "uint64"
+          LogEntriesForSlowFollowers:
+            description: |
+              The number of log entries to keep around to sync up slow followers
+              after a snapshot is created.
+            type: "integer"
+            format: "uint64"
+            example: 500
+          ElectionTick:
+            description: |
+              The number of ticks that a follower will wait for a message from
+              the leader before becoming a candidate and starting an election.
+              `ElectionTick` must be greater than `HeartbeatTick`.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 3
+          HeartbeatTick:
+            description: |
+              The number of ticks between heartbeats. Every HeartbeatTick ticks,
+              the leader will send a heartbeat to the followers.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 1
+      Dispatcher:
+        description: "Dispatcher configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          HeartbeatPeriod:
+            description: |
+              The delay for an agent to send a heartbeat to the dispatcher.
+            type: "integer"
+            format: "int64"
+            example: 5000000000
+      CAConfig:
+        description: "CA configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          NodeCertExpiry:
+            description: "The duration node certificates are issued for."
+            type: "integer"
+            format: "int64"
+            example: 7776000000000000
+          ExternalCAs:
+            description: |
+              Configuration for forwarding signing requests to an external
+              certificate authority.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Protocol:
+                  description: |
+                    Protocol for communication with the external CA (currently
+                    only `cfssl` is supported).
+                  type: "string"
+                  enum:
+                    - "cfssl"
+                  default: "cfssl"
+                URL:
+                  description: |
+                    URL where certificate signing requests should be sent.
+                  type: "string"
+                Options:
+                  description: |
+                    An object with key/value pairs that are interpreted as
+                    protocol-specific options for the external CA driver.
+                  type: "object"
+                  additionalProperties:
+                    type: "string"
+                CACert:
+                  description: |
+                    The root CA certificate (in PEM format) this external CA uses
+                    to issue TLS certificates (assumed to be to the current swarm
+                    root CA certificate if not provided).
+                  type: "string"
+          SigningCACert:
+            description: |
+              The desired signing CA certificate for all swarm node TLS leaf
+              certificates, in PEM format.
+            type: "string"
+          SigningCAKey:
+            description: |
+              The desired signing CA key for all swarm node TLS leaf certificates,
+              in PEM format.
+            type: "string"
+          ForceRotate:
+            description: |
+              An integer whose purpose is to force swarm to generate a new
+              signing CA certificate and key, if none have been specified in
+              `SigningCACert` and `SigningCAKey`
+            format: "uint64"
+            type: "integer"
+      EncryptionConfig:
+        description: "Parameters related to encryption-at-rest."
+        type: "object"
+        properties:
+          AutoLockManagers:
+            description: |
+              If set, generate a key and use it to lock data stored on the
+              managers.
+            type: "boolean"
+            example: false
+      TaskDefaults:
+        description: "Defaults for creating tasks in this cluster."
+        type: "object"
+        properties:
+          LogDriver:
+            description: |
+              The log driver to use for tasks created in the orchestrator if
+              unspecified by a service.
+
+              Updating this value only affects new tasks. Existing tasks continue
+              to use their previously configured log driver until recreated.
+            type: "object"
+            properties:
+              Name:
+                description: |
+                  The log driver to use as a default for new tasks.
+                type: "string"
+                example: "json-file"
+              Options:
+                description: |
+                  Driver-specific options for the selected log driver, specified
+                  as key/value pairs.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "10"
+                  "max-size": "100m"
+
+  # The Swarm information for `GET /info`. It is the same as `GET /swarm`, but
+  # without `JoinTokens`.
+  ClusterInfo:
+    description: |
+      ClusterInfo represents information about the swarm as is returned by the
+      "/info" endpoint. Join-tokens are not included.
+    x-nullable: true
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the swarm."
+        type: "string"
+        example: "abajmipo7b4xz5ip2nrla6b11"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the swarm was initialised in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the swarm was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/SwarmSpec"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+      RootRotationInProgress:
+        description: |
+          Whether there is currently a root CA rotation in progress for the swarm
+        type: "boolean"
+        example: false
+      DataPathPort:
+        description: |
+          DataPathPort specifies the data path port number for data traffic.
+          Acceptable port range is 1024 to 49151.
+          If no port is set or is set to 0, the default port (4789) is used.
+        type: "integer"
+        format: "uint32"
+        default: 4789
+        example: 4789
+      DefaultAddrPool:
+        description: |
+          Default Address Pool specifies default subnet pools for global scope
+          networks.
+        type: "array"
+        items:
+          type: "string"
+          format: "CIDR"
+          example: ["10.10.0.0/16", "20.20.0.0/16"]
+      SubnetSize:
+        description: |
+          SubnetSize specifies the subnet size of the networks created from the
+          default subnet pool.
+        type: "integer"
+        format: "uint32"
+        maximum: 29
+        default: 24
+        example: 24
+
+  JoinTokens:
+    description: |
+      JoinTokens contains the tokens workers and managers need to join the swarm.
+    type: "object"
+    properties:
+      Worker:
+        description: |
+          The token workers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx"
+      Manager:
+        description: |
+          The token managers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+
+  Swarm:
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/ClusterInfo"
+      - type: "object"
+        properties:
+          JoinTokens:
+            $ref: "#/definitions/JoinTokens"
+
+  TaskSpec:
+    description: "User modifiable task configuration."
+    type: "object"
+    properties:
+      PluginSpec:
+        type: "object"
+        description: |
+          Plugin spec for the service.  *(Experimental release only.)*
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Name:
+            description: "The name or 'alias' to use for the plugin."
+            type: "string"
+          Remote:
+            description: "The plugin image reference to use."
+            type: "string"
+          Disabled:
+            description: "Disable the plugin once scheduled."
+            type: "boolean"
+          PluginPrivilege:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+      ContainerSpec:
+        type: "object"
+        description: |
+          Container spec for the service.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Image:
+            description: "The image name to use for the container"
+            type: "string"
+          Labels:
+            description: "User-defined key/value data."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          Command:
+            description: "The command to be run in the image."
+            type: "array"
+            items:
+              type: "string"
+          Args:
+            description: "Arguments to the command."
+            type: "array"
+            items:
+              type: "string"
+          Hostname:
+            description: |
+              The hostname to use for the container, as a valid
+              [RFC 1123](https://tools.ietf.org/html/rfc1123) hostname.
+            type: "string"
+          Env:
+            description: |
+              A list of environment variables in the form `VAR=value`.
+            type: "array"
+            items:
+              type: "string"
+          Dir:
+            description: "The working directory for commands to run in."
+            type: "string"
+          User:
+            description: "The user inside the container."
+            type: "string"
+          Groups:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          Privileges:
+            type: "object"
+            description: "Security options for the container"
+            properties:
+              CredentialSpec:
+                type: "object"
+                description: "CredentialSpec for managed service account (Windows only)"
+                properties:
+                  Config:
+                    type: "string"
+                    example: "0bt9dmxjvjiqermk6xrop3ekq"
+                    description: |
+                      Load credential spec from a Swarm Config with the given ID.
+                      The specified config must also be present in the Configs
+                      field with the Runtime property set.
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  File:
+                    type: "string"
+                    example: "spec.json"
+                    description: |
+                      Load credential spec from this file. The file is read by
+                      the daemon, and must be present in the `CredentialSpecs`
+                      subdirectory in the docker data directory, which defaults
+                      to `C:\ProgramData\Docker\` on Windows.
+
+                      For example, specifying `spec.json` loads
+                      `C:\ProgramData\Docker\CredentialSpecs\spec.json`.
+
+                      <p><br /></p>
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  Registry:
+                    type: "string"
+                    description: |
+                      Load credential spec from this value in the Windows
+                      registry. The specified registry value must be located in:
+
+                      `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs`
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+              SELinuxContext:
+                type: "object"
+                description: "SELinux labels of the container"
+                properties:
+                  Disable:
+                    type: "boolean"
+                    description: "Disable SELinux"
+                  User:
+                    type: "string"
+                    description: "SELinux user label"
+                  Role:
+                    type: "string"
+                    description: "SELinux role label"
+                  Type:
+                    type: "string"
+                    description: "SELinux type label"
+                  Level:
+                    type: "string"
+                    description: "SELinux level label"
+              Seccomp:
+                type: "object"
+                description: "Options for configuring seccomp on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "unconfined"
+                      - "custom"
+                  Profile:
+                    description: "The custom seccomp profile as a json object"
+                    type: "string"
+              AppArmor:
+                type: "object"
+                description: "Options for configuring AppArmor on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "disabled"
+              NoNewPrivileges:
+                type: "boolean"
+                description: "Configuration of the no_new_privs bit in the container"
+
+          TTY:
+            description: "Whether a pseudo-TTY should be allocated."
+            type: "boolean"
+          OpenStdin:
+            description: "Open `stdin`"
+            type: "boolean"
+          ReadOnly:
+            description: "Mount the container's root filesystem as read only."
+            type: "boolean"
+          Mounts:
+            description: |
+              Specification for mounts to be added to containers created as part
+              of the service.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          StopSignal:
+            description: "Signal to stop the container."
+            type: "string"
+          StopGracePeriod:
+            description: |
+              Amount of time to wait for the container to terminate before
+              forcefully killing it.
+            type: "integer"
+            format: "int64"
+          HealthCheck:
+            $ref: "#/definitions/HealthConfig"
+          Hosts:
+            type: "array"
+            description: |
+              A list of hostname/IP mappings to add to the container's `hosts`
+              file. The format of extra hosts is specified in the
+              [hosts(5)](http://man7.org/linux/man-pages/man5/hosts.5.html)
+              man page:
+
+                  IP_address canonical_hostname [aliases...]
+            items:
+              type: "string"
+          DNSConfig:
+            description: |
+              Specification for DNS related configurations in resolver configuration
+              file (`resolv.conf`).
+            type: "object"
+            properties:
+              Nameservers:
+                description: "The IP addresses of the name servers."
+                type: "array"
+                items:
+                  type: "string"
+              Search:
+                description: "A search list for host-name lookup."
+                type: "array"
+                items:
+                  type: "string"
+              Options:
+                description: |
+                  A list of internal resolver variables to be modified (e.g.,
+                  `debug`, `ndots:3`, etc.).
+                type: "array"
+                items:
+                  type: "string"
+          Secrets:
+            description: |
+              Secrets contains references to zero or more secrets that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                SecretID:
+                  description: |
+                    SecretID represents the ID of the specific secret that we're
+                    referencing.
+                  type: "string"
+                SecretName:
+                  description: |
+                    SecretName is the name of the secret that this references,
+                    but this is just provided for lookup/display purposes. The
+                    secret in the reference will be identified by its ID.
+                  type: "string"
+          OomScoreAdj:
+            type: "integer"
+            format: "int64"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 0
+          Configs:
+            description: |
+              Configs contains references to zero or more configs that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually exclusive
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                Runtime:
+                  description: |
+                    Runtime represents a target that is not mounted into the
+                    container but is used by the task
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually
+                    > exclusive
+                  type: "object"
+                ConfigID:
+                  description: |
+                    ConfigID represents the ID of the specific config that we're
+                    referencing.
+                  type: "string"
+                ConfigName:
+                  description: |
+                    ConfigName is the name of the config that this references,
+                    but this is just provided for lookup/display purposes. The
+                    config in the reference will be identified by its ID.
+                  type: "string"
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the containers running the service.
+              (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          Init:
+            description: |
+              Run an init inside the container that forwards signals and reaps
+              processes. This field is omitted if empty, and the default (as
+              configured on the daemon) is used.
+            type: "boolean"
+            x-nullable: true
+          Sysctls:
+            description: |
+              Set kernel namedspaced parameters (sysctls) in the container.
+              The Sysctls option on services accepts the same sysctls as the
+              are supported on containers. Note that while the same sysctls are
+              supported, no guarantees or checks are made about their
+              suitability for a clustered environment, and it's up to the user
+              to determine whether a given sysctl will work properly in a
+              Service.
+            type: "object"
+            additionalProperties:
+              type: "string"
+          # This option is not used by Windows containers
+          CapabilityAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+              - "CAP_SYS_ADMIN"
+              - "CAP_SYS_CHROOT"
+              - "CAP_SYSLOG"
+          CapabilityDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+          Ulimits:
+            description: |
+              A list of resource limits to set in the container. For example: `{"Name": "nofile", "Soft": 1024, "Hard": 2048}`"
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Name:
+                  description: "Name of ulimit"
+                  type: "string"
+                Soft:
+                  description: "Soft limit"
+                  type: "integer"
+                Hard:
+                  description: "Hard limit"
+                  type: "integer"
+      NetworkAttachmentSpec:
+        description: |
+          Read-only spec type for non-swarm containers attached to swarm overlay
+          networks.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        type: "object"
+        properties:
+          ContainerID:
+            description: "ID of the container represented by this task"
+            type: "string"
+      Resources:
+        description: |
+          Resource requirements which apply to each individual container created
+          as part of the service.
+        type: "object"
+        properties:
+          Limits:
+            description: "Define resources limits."
+            $ref: "#/definitions/Limit"
+          Reservations:
+            description: "Define resources reservation."
+            $ref: "#/definitions/ResourceObject"
+      RestartPolicy:
+        description: |
+          Specification for the restart policy which applies to containers
+          created as part of this service.
+        type: "object"
+        properties:
+          Condition:
+            description: "Condition for restart."
+            type: "string"
+            enum:
+              - "none"
+              - "on-failure"
+              - "any"
+          Delay:
+            description: "Delay between restart attempts."
+            type: "integer"
+            format: "int64"
+          MaxAttempts:
+            description: |
+              Maximum attempts to restart a given container before giving up
+              (default value is 0, which is ignored).
+            type: "integer"
+            format: "int64"
+            default: 0
+          Window:
+            description: |
+              Windows is the time window used to evaluate the restart policy
+              (default value is 0, which is unbounded).
+            type: "integer"
+            format: "int64"
+            default: 0
+      Placement:
+        type: "object"
+        properties:
+          Constraints:
+            description: |
+              An array of constraint expressions to limit the set of nodes where
+              a task can be scheduled. Constraint expressions can either use a
+              _match_ (`==`) or _exclude_ (`!=`) rule. Multiple constraints find
+              nodes that satisfy every expression (AND match). Constraints can
+              match node or Docker Engine labels as follows:
+
+              node attribute       | matches                        | example
+              ---------------------|--------------------------------|-----------------------------------------------
+              `node.id`            | Node ID                        | `node.id==2ivku8v2gvtg4`
+              `node.hostname`      | Node hostname                  | `node.hostname!=node-2`
+              `node.role`          | Node role (`manager`/`worker`) | `node.role==manager`
+              `node.platform.os`   | Node operating system          | `node.platform.os==windows`
+              `node.platform.arch` | Node architecture              | `node.platform.arch==x86_64`
+              `node.labels`        | User-defined node labels       | `node.labels.security==high`
+              `engine.labels`      | Docker Engine's labels         | `engine.labels.operatingsystem==ubuntu-24.04`
+
+              `engine.labels` apply to Docker Engine labels like operating system,
+              drivers, etc. Swarm administrators add `node.labels` for operational
+              purposes by using the [`node update endpoint`](#operation/NodeUpdate).
+
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "node.hostname!=node3.corp.example.com"
+              - "node.role!=manager"
+              - "node.labels.type==production"
+              - "node.platform.os==linux"
+              - "node.platform.arch==x86_64"
+          Preferences:
+            description: |
+              Preferences provide a way to make the scheduler aware of factors
+              such as topology. They are provided in order from highest to
+              lowest precedence.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Spread:
+                  type: "object"
+                  properties:
+                    SpreadDescriptor:
+                      description: |
+                        label descriptor, such as `engine.labels.az`.
+                      type: "string"
+            example:
+              - Spread:
+                  SpreadDescriptor: "node.labels.datacenter"
+              - Spread:
+                  SpreadDescriptor: "node.labels.rack"
+          MaxReplicas:
+            description: |
+              Maximum number of replicas for per node (default value is 0, which
+              is unlimited)
+            type: "integer"
+            format: "int64"
+            default: 0
+          Platforms:
+            description: |
+              Platforms stores all the platforms that the service's image can
+              run on. This field is used in the platform filter for scheduling.
+              If empty, then the platform filter is off, meaning there are no
+              scheduling restrictions.
+            type: "array"
+            items:
+              $ref: "#/definitions/Platform"
+      ForceUpdate:
+        description: |
+          A counter that triggers an update even if no relevant parameters have
+          been changed.
+        type: "integer"
+        format: "uint64"
+      Runtime:
+        description: |
+          Runtime is the type of runtime specified for the task executor.
+        type: "string"
+      Networks:
+        description: "Specifies which networks the service should attach to."
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+      LogDriver:
+        description: |
+          Specifies the log driver to use for tasks created from this spec. If
+          not present, the default one for the swarm will be used, finally
+          falling back to the engine default if not specified.
+        type: "object"
+        properties:
+          Name:
+            type: "string"
+          Options:
+            type: "object"
+            additionalProperties:
+              type: "string"
+
+  TaskState:
+    type: "string"
+    enum:
+      - "new"
+      - "allocated"
+      - "pending"
+      - "assigned"
+      - "accepted"
+      - "preparing"
+      - "ready"
+      - "starting"
+      - "running"
+      - "complete"
+      - "shutdown"
+      - "failed"
+      - "rejected"
+      - "remove"
+      - "orphaned"
+
+  ContainerStatus:
+    type: "object"
+    description: "represents the status of a container."
+    properties:
+      ContainerID:
+        type: "string"
+      PID:
+        type: "integer"
+      ExitCode:
+        type: "integer"
+
+  PortStatus:
+    type: "object"
+    description: "represents the port status of a task's host ports whose service has published host ports"
+    properties:
+      Ports:
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  TaskStatus:
+    type: "object"
+    description: "represents the status of a task."
+    properties:
+      Timestamp:
+        type: "string"
+        format: "dateTime"
+      State:
+        $ref: "#/definitions/TaskState"
+      Message:
+        type: "string"
+      Err:
+        type: "string"
+      ContainerStatus:
+        $ref: "#/definitions/ContainerStatus"
+      PortStatus:
+        $ref: "#/definitions/PortStatus"
+
+  Task:
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the task."
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Name:
+        description: "Name of the task."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Spec:
+        $ref: "#/definitions/TaskSpec"
+      ServiceID:
+        description: "The ID of the service this task is part of."
+        type: "string"
+      Slot:
+        type: "integer"
+      NodeID:
+        description: "The ID of the node that this task is on."
+        type: "string"
+      AssignedGenericResources:
+        $ref: "#/definitions/GenericResources"
+      Status:
+        $ref: "#/definitions/TaskStatus"
+      DesiredState:
+        $ref: "#/definitions/TaskState"
+      JobIteration:
+        description: |
+          If the Service this Task belongs to is a job-mode service, contains
+          the JobIteration of the Service this Task was created for. Absent if
+          the Task was created for a Replicated or Global Service.
+        $ref: "#/definitions/ObjectVersion"
+    example:
+      ID: "0kzzo1i0y4jz6027t0k7aezc7"
+      Version:
+        Index: 71
+      CreatedAt: "2016-06-07T21:07:31.171892745Z"
+      UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+      Spec:
+        ContainerSpec:
+          Image: "redis"
+        Resources:
+          Limits: {}
+          Reservations: {}
+        RestartPolicy:
+          Condition: "any"
+          MaxAttempts: 0
+        Placement: {}
+      ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Slot: 1
+      NodeID: "60gvrl6tm78dmak4yl7srz94v"
+      Status:
+        Timestamp: "2016-06-07T21:07:31.290032978Z"
+        State: "running"
+        Message: "started"
+        ContainerStatus:
+          ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+          PID: 677
+      DesiredState: "running"
+      NetworksAttachments:
+        - Network:
+            ID: "4qvuz4ko70xaltuqbt8956gd1"
+            Version:
+              Index: 18
+            CreatedAt: "2016-06-07T20:31:11.912919752Z"
+            UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+            Spec:
+              Name: "ingress"
+              Labels:
+                com.docker.swarm.internal: "true"
+              DriverConfiguration: {}
+              IPAMOptions:
+                Driver: {}
+                Configs:
+                  - Subnet: "10.255.0.0/16"
+                    Gateway: "10.255.0.1"
+            DriverState:
+              Name: "overlay"
+              Options:
+                com.docker.network.driver.overlay.vxlanid_list: "256"
+            IPAMOptions:
+              Driver:
+                Name: "default"
+              Configs:
+                - Subnet: "10.255.0.0/16"
+                  Gateway: "10.255.0.1"
+          Addresses:
+            - "10.255.0.10/16"
+      AssignedGenericResources:
+        - DiscreteResourceSpec:
+            Kind: "SSD"
+            Value: 3
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID1"
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID2"
+
+  ServiceSpec:
+    description: "User modifiable configuration for a service."
+    type: object
+    properties:
+      Name:
+        description: "Name of the service."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      TaskTemplate:
+        $ref: "#/definitions/TaskSpec"
+      Mode:
+        description: "Scheduling mode for the service."
+        type: "object"
+        properties:
+          Replicated:
+            type: "object"
+            properties:
+              Replicas:
+                type: "integer"
+                format: "int64"
+          Global:
+            type: "object"
+          ReplicatedJob:
+            description: |
+              The mode used for services with a finite number of tasks that run
+              to a completed state.
+            type: "object"
+            properties:
+              MaxConcurrent:
+                description: |
+                  The maximum number of replicas to run simultaneously.
+                type: "integer"
+                format: "int64"
+                default: 1
+              TotalCompletions:
+                description: |
+                  The total number of replicas desired to reach the Completed
+                  state. If unset, will default to the value of `MaxConcurrent`
+                type: "integer"
+                format: "int64"
+          GlobalJob:
+            description: |
+              The mode used for services which run a task to the completed state
+              on each valid node.
+            type: "object"
+      UpdateConfig:
+        description: "Specification for the update strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be updated in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: "Amount of time between updates, in nanoseconds."
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an updated task fails to run, or stops running
+              during the update.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+              - "rollback"
+          Monitor:
+            description: |
+              Amount of time to monitor each updated task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during an update before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling out an updated task. Either
+              the old task is shut down before the new task is started, or the
+              new task is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      RollbackConfig:
+        description: "Specification for the rollback strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be rolled back in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: |
+              Amount of time between rollback iterations, in nanoseconds.
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an rolled back task fails to run, or stops
+              running during the rollback.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+          Monitor:
+            description: |
+              Amount of time to monitor each rolled back task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during a rollback before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling back a task. Either the old
+              task is shut down before the new task is started, or the new task
+              is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      Networks:
+        description: |
+          Specifies which networks the service should attach to.
+
+          Deprecated: This field is deprecated since v1.44. The Networks field in TaskSpec should be used instead.
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+
+      EndpointSpec:
+        $ref: "#/definitions/EndpointSpec"
+
+  EndpointPortConfig:
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+      Protocol:
+        type: "string"
+        enum:
+          - "tcp"
+          - "udp"
+          - "sctp"
+      TargetPort:
+        description: "The port inside the container."
+        type: "integer"
+      PublishedPort:
+        description: "The port on the swarm hosts."
+        type: "integer"
+      PublishMode:
+        description: |
+          The mode in which port is published.
+
+          <p><br /></p>
+
+          - "ingress" makes the target port accessible on every node,
+            regardless of whether there is a task for the service running on
+            that node or not.
+          - "host" bypasses the routing mesh and publish the port directly on
+            the swarm node where that service is running.
+
+        type: "string"
+        enum:
+          - "ingress"
+          - "host"
+        default: "ingress"
+        example: "ingress"
+
+  EndpointSpec:
+    description: "Properties that can be configured to access and load balance a service."
+    type: "object"
+    properties:
+      Mode:
+        description: |
+          The mode of resolution to use for internal load balancing between tasks.
+        type: "string"
+        enum:
+          - "vip"
+          - "dnsrr"
+        default: "vip"
+      Ports:
+        description: |
+          List of exposed ports that this service is accessible on from the
+          outside. Ports can only be provided if `vip` resolution mode is used.
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  Service:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ServiceSpec"
+      Endpoint:
+        type: "object"
+        properties:
+          Spec:
+            $ref: "#/definitions/EndpointSpec"
+          Ports:
+            type: "array"
+            items:
+              $ref: "#/definitions/EndpointPortConfig"
+          VirtualIPs:
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                NetworkID:
+                  type: "string"
+                Addr:
+                  type: "string"
+      UpdateStatus:
+        description: "The status of a service update."
+        type: "object"
+        properties:
+          State:
+            type: "string"
+            enum:
+              - "updating"
+              - "paused"
+              - "completed"
+          StartedAt:
+            type: "string"
+            format: "dateTime"
+          CompletedAt:
+            type: "string"
+            format: "dateTime"
+          Message:
+            type: "string"
+      ServiceStatus:
+        description: |
+          The status of the service's tasks. Provided only when requested as
+          part of a ServiceList operation.
+        type: "object"
+        properties:
+          RunningTasks:
+            description: |
+              The number of tasks for the service currently in the Running state.
+            type: "integer"
+            format: "uint64"
+            example: 7
+          DesiredTasks:
+            description: |
+              The number of tasks for the service desired to be running.
+              For replicated services, this is the replica count from the
+              service spec. For global services, this is computed by taking
+              count of all tasks for the service with a Desired State other
+              than Shutdown.
+            type: "integer"
+            format: "uint64"
+            example: 10
+          CompletedTasks:
+            description: |
+              The number of tasks for a job that are in the Completed state.
+              This field must be cross-referenced with the service type, as the
+              value of 0 may mean the service is not in a job mode, or it may
+              mean the job-mode service has no tasks yet Completed.
+            type: "integer"
+            format: "uint64"
+      JobStatus:
+        description: |
+          The status of the service when it is in one of ReplicatedJob or
+          GlobalJob modes. Absent on Replicated and Global mode services. The
+          JobIteration is an ObjectVersion, but unlike the Service's version,
+          does not need to be sent with an update request.
+        type: "object"
+        properties:
+          JobIteration:
+            description: |
+              JobIteration is a value increased each time a Job is executed,
+              successfully or otherwise. "Executed", in this case, means the
+              job as a whole has been started, not that an individual Task has
+              been launched. A job is "Executed" when its ServiceSpec is
+              updated. JobIteration can be used to disambiguate Tasks belonging
+              to different executions of a job.  Though JobIteration will
+              increase with each subsequent execution, it may not necessarily
+              increase by 1, and so JobIteration should not be used to
+            $ref: "#/definitions/ObjectVersion"
+          LastExecution:
+            description: |
+              The last time, as observed by the server, that this job was
+              started.
+            type: "string"
+            format: "dateTime"
+    example:
+      ID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Version:
+        Index: 19
+      CreatedAt: "2016-06-07T21:05:51.880065305Z"
+      UpdatedAt: "2016-06-07T21:07:29.962229872Z"
+      Spec:
+        Name: "hopeful_cori"
+        TaskTemplate:
+          ContainerSpec:
+            Image: "redis"
+          Resources:
+            Limits: {}
+            Reservations: {}
+          RestartPolicy:
+            Condition: "any"
+            MaxAttempts: 0
+          Placement: {}
+          ForceUpdate: 0
+        Mode:
+          Replicated:
+            Replicas: 1
+        UpdateConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        RollbackConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        EndpointSpec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+      Endpoint:
+        Spec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+        Ports:
+          -
+            Protocol: "tcp"
+            TargetPort: 6379
+            PublishedPort: 30001
+        VirtualIPs:
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.2/16"
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.3/16"
+
+  ImageDeleteResponseItem:
+    type: "object"
+    x-go-name: "DeleteResponse"
+    properties:
+      Untagged:
+        description: "The image ID of an image that was untagged"
+        type: "string"
+      Deleted:
+        description: "The image ID of an image that was deleted"
+        type: "string"
+
+  ServiceCreateResponse:
+    type: "object"
+    description: |
+      contains the information returned to a client on the
+      creation of a new service.
+    properties:
+      ID:
+        description: "The ID of the created service."
+        type: "string"
+        x-nullable: false
+        example: "ak7w3gjqoa3kuz8xcpnyy0pvl"
+      Warnings:
+        description: |
+          Optional warning message.
+
+          FIXME(thaJeztah): this should have "omitempty" in the generated type.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example:
+          - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ServiceUpdateResponse:
+    type: "object"
+    properties:
+      Warnings:
+        description: "Optional warning messages"
+        type: "array"
+        items:
+          type: "string"
+    example:
+      Warnings:
+        - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ContainerInspectResponse:
+    type: "object"
+    title: "ContainerInspectResponse"
+    x-go-name: "InspectResponse"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Created:
+        description: |-
+          Date and time at which the container was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2025-02-17T17:43:39.64001363Z"
+      Path:
+        description: |-
+          The path to the command being run
+        type: "string"
+        example: "/bin/sh"
+      Args:
+        description: "The arguments to the command being run"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "-c"
+          - "exit 9"
+      State:
+        $ref: "#/definitions/ContainerState"
+      Image:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ResolvConfPath:
+        description: |-
+          Location of the `/etc/resolv.conf` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/resolv.conf"
+      HostnamePath:
+        description: |-
+          Location of the `/etc/hostname` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hostname"
+      HostsPath:
+        description: |-
+          Location of the `/etc/hosts` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hosts"
+      LogPath:
+        description: |-
+          Location of the file used to buffer the container's logs. Depending on
+          the logging-driver used for the container, this field may be omitted.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        x-nullable: true
+        example: "/var/lib/docker/containers/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59-json.log"
+      Name:
+        description: |-
+          The name associated with this container.
+
+          For historic reasons, the name may be prefixed with a forward-slash (`/`).
+        type: "string"
+        example: "/funny_chatelet"
+      RestartCount:
+        description: |-
+          Number of times the container was restarted since it was created,
+          or since daemon was started.
+        type: "integer"
+        example: 0
+      Driver:
+        description: |-
+          The storage-driver used for the container's filesystem (graph-driver
+          or snapshotter).
+        type: "string"
+        example: "overlayfs"
+      Platform:
+        description: |-
+          The platform (operating system) for which the container was created.
+
+          This field was introduced for the experimental "LCOW" (Linux Containers
+          On Windows) features, which has been removed. In most cases, this field
+          is equal to the host's operating system (`linux` or `windows`).
+        type: "string"
+        example: "linux"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        description: |-
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+      MountLabel:
+        description: |-
+          SELinux mount label set for the container.
+        type: "string"
+        example: ""
+      ProcessLabel:
+        description: |-
+          SELinux process label set for the container.
+        type: "string"
+        example: ""
+      AppArmorProfile:
+        description: |-
+          The AppArmor profile set for the container.
+        type: "string"
+        example: ""
+      ExecIDs:
+        description: |-
+          IDs of exec instances that are running in the container.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example:
+          - "b35395de42bc8abd327f9dd65d913b9ba28c74d2f0734eeeae84fa1c616a0fca"
+          - "3fc1232e5cd20c8de182ed81178503dc6437f4e7ef12b52cc5e8de020652f1c4"
+      HostConfig:
+        $ref: "#/definitions/HostConfig"
+      GraphDriver:
+        $ref: "#/definitions/DriverData"
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Mounts:
+        description: |-
+          List of mounts used by the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/MountPoint"
+      Config:
+        $ref: "#/definitions/ContainerConfig"
+      NetworkSettings:
+        $ref: "#/definitions/NetworkSettings"
+
+  ContainerSummary:
+    type: "object"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Names:
+        description: |-
+          The names associated with this container. Most containers have a single
+          name, but when using legacy "links", the container can have multiple
+          names.
+
+          For historic reasons, names are prefixed with a forward-slash (`/`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/funny_chatelet"
+      Image:
+        description: |-
+          The name or ID of the image used to create the container.
+
+          This field shows the image reference as was specified when creating the container,
+          which can be in its canonical form (e.g., `docker.io/library/ubuntu:latest`
+          or `docker.io/library/ubuntu@sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`),
+          short form (e.g., `ubuntu:latest`)), or the ID(-prefix) of the image (e.g., `72297848456d`).
+
+          The content of this field can be updated at runtime if the image used to
+          create the container is untagged, in which case the field is updated to
+          contain the the image ID (digest) it was resolved to in its canonical,
+          non-truncated form (e.g., `sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`).
+        type: "string"
+        example: "docker.io/library/ubuntu:latest"
+      ImageID:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        x-nullable: true
+        description: |
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+
+          This field is not populated in the `GET /system/df` endpoint.
+      Command:
+        description: "Command to run when starting the container"
+        type: "string"
+        example: "/bin/bash"
+      Created:
+        description: |-
+          Date and time at which the container was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        format: "int64"
+        example: "1739811096"
+      Ports:
+        description: |-
+          Port-mappings for the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/Port"
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.vendor: "Acme"
+          com.example.license: "GPL"
+          com.example.version: "1.0"
+      State:
+        description: |
+          The state of this container.
+        type: "string"
+        enum:
+          - "created"
+          - "running"
+          - "paused"
+          - "restarting"
+          - "exited"
+          - "removing"
+          - "dead"
+        example: "running"
+      Status:
+        description: |-
+          Additional human-readable status of this container (e.g. `Exit 0`)
+        type: "string"
+        example: "Up 4 days"
+      HostConfig:
+        type: "object"
+        description: |-
+          Summary of host-specific runtime information of the container. This
+          is a reduced set of information in the container's "HostConfig" as
+          available in the container "inspect" response.
+        properties:
+          NetworkMode:
+            description: |-
+              Networking mode (`host`, `none`, `container:<id>`) or name of the
+              primary network the container is using.
+
+              This field is primarily for backward compatibility. The container
+              can be connected to multiple networks for which information can be
+              found in the `NetworkSettings.Networks` field, which enumerates
+              settings per network.
+            type: "string"
+            example: "mynetwork"
+          Annotations:
+            description: |-
+              Arbitrary key-value metadata attached to the container.
+            type: "object"
+            x-nullable: true
+            additionalProperties:
+              type: "string"
+            example:
+              io.kubernetes.docker.type: "container"
+              io.kubernetes.sandbox.id: "3befe639bed0fd6afdd65fd1fa84506756f59360ec4adc270b0fdac9be22b4d3"
+      NetworkSettings:
+        description: |-
+          Summary of the container's network settings
+        type: "object"
+        properties:
+          Networks:
+            type: "object"
+            description: |-
+              Summary of network-settings for each network the container is
+              attached to.
+            additionalProperties:
+              $ref: "#/definitions/EndpointSettings"
+      Mounts:
+        type: "array"
+        description: |-
+          List of mounts used by the container.
+        items:
+          $ref: "#/definitions/MountPoint"
+
+  Driver:
+    description: "Driver represents a driver (network, logging, secrets)."
+    type: "object"
+    required: [Name]
+    properties:
+      Name:
+        description: "Name of the driver."
+        type: "string"
+        x-nullable: false
+        example: "some-driver"
+      Options:
+        description: "Key/value map of driver-specific options."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          OptionA: "value for driver-specific option A"
+          OptionB: "value for driver-specific option B"
+
+  SecretSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the secret."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Data:
+        description: |
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          It must be empty if the Driver field is set, in which case the data is
+          loaded from an external secret store. The maximum allowed size is 500KB,
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
+
+          This field is only used to _create_ a secret, and is not returned by
+          other endpoints.
+        type: "string"
+        example: ""
+      Driver:
+        description: |
+          Name of the secrets driver used to fetch the secret's value from an
+          external secret store.
+        $ref: "#/definitions/Driver"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Secret:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "blt1owaxmitz71s9v5zh81zun"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      Spec:
+        $ref: "#/definitions/SecretSpec"
+
+  ConfigSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the config."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Data:
+        description: |
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
+        type: "string"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Config:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ConfigSpec"
+
+  ContainerState:
+    description: |
+      ContainerState stores container's running state. It's part of ContainerJSONBase
+      and will be returned by the "inspect" command.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          String representation of the container state. Can be one of "created",
+          "running", "paused", "restarting", "removing", "exited", or "dead".
+        type: "string"
+        enum: ["created", "running", "paused", "restarting", "removing", "exited", "dead"]
+        example: "running"
+      Running:
+        description: |
+          Whether this container is running.
+
+          Note that a running container can be _paused_. The `Running` and `Paused`
+          booleans are not mutually exclusive:
+
+          When pausing a container (on Linux), the freezer cgroup is used to suspend
+          all processes in the container. Freezing the process requires the process to
+          be running. As a result, paused containers are both `Running` _and_ `Paused`.
+
+          Use the `Status` field instead to determine if a container's state is "running".
+        type: "boolean"
+        example: true
+      Paused:
+        description: "Whether this container is paused."
+        type: "boolean"
+        example: false
+      Restarting:
+        description: "Whether this container is restarting."
+        type: "boolean"
+        example: false
+      OOMKilled:
+        description: |
+          Whether a process within this container has been killed because it ran
+          out of memory since the container was last started.
+        type: "boolean"
+        example: false
+      Dead:
+        type: "boolean"
+        example: false
+      Pid:
+        description: "The process ID of this container"
+        type: "integer"
+        example: 1234
+      ExitCode:
+        description: "The last exit code of this container"
+        type: "integer"
+        example: 0
+      Error:
+        type: "string"
+      StartedAt:
+        description: "The time when this container was last started."
+        type: "string"
+        example: "2020-01-06T09:06:59.461876391Z"
+      FinishedAt:
+        description: "The time when this container last exited."
+        type: "string"
+        example: "2020-01-06T09:07:59.461876391Z"
+      Health:
+        $ref: "#/definitions/Health"
+
+  ContainerCreateResponse:
+    description: "OK response to ContainerCreate operation"
+    type: "object"
+    title: "ContainerCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warnings]
+    properties:
+      Id:
+        description: "The ID of the created container"
+        type: "string"
+        x-nullable: false
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Warnings:
+        description: "Warnings encountered when creating the container"
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example: []
+
+  ContainerUpdateResponse:
+    type: "object"
+    title: "ContainerUpdateResponse"
+    x-go-name: "UpdateResponse"
+    description: |-
+      Response for a successful container-update.
+    properties:
+      Warnings:
+        type: "array"
+        description: |-
+          Warnings encountered when updating the container.
+        items:
+          type: "string"
+        example: ["Published ports are discarded when using host network mode"]
+
+  ContainerStatsResponse:
+    description: |
+      Statistics sample for a container.
+    type: "object"
+    x-go-name: "StatsResponse"
+    title: "ContainerStatsResponse"
+    properties:
+      name:
+        description: "Name of the container"
+        type: "string"
+        x-nullable: true
+        example: "boring_wozniak"
+      id:
+        description: "ID of the container"
+        type: "string"
+        x-nullable: true
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      read:
+        description: |
+          Date and time at which this sample was collected.
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:22.165243637Z"
+      preread:
+        description: |
+          Date and time at which this first sample was collected. This field
+          is not propagated if the "one-shot" option is set. If the "one-shot"
+          option is set, this field may be omitted, empty, or set to a default
+          date (`0001-01-01T00:00:00Z`).
+
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:21.160452595Z"
+      pids_stats:
+        $ref: "#/definitions/ContainerPidsStats"
+      blkio_stats:
+        $ref: "#/definitions/ContainerBlkioStats"
+      num_procs:
+        description: |
+          The number of processors on the system.
+
+          This field is Windows-specific and always zero for Linux containers.
+        type: "integer"
+        format: "uint32"
+        example: 16
+      storage_stats:
+        $ref: "#/definitions/ContainerStorageStats"
+      cpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+      precpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+      memory_stats:
+        $ref: "#/definitions/ContainerMemoryStats"
+      networks:
+        description: |
+          Network statistics for the container per interface.
+
+          This field is omitted if the container has no networking enabled.
+        x-nullable: true
+        additionalProperties:
+          $ref: "#/definitions/ContainerNetworkStats"
+        example:
+          eth0:
+            rx_bytes: 5338
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 36
+            tx_bytes: 648
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 8
+          eth5:
+            rx_bytes: 4641
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 26
+            tx_bytes: 690
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 9
+
+  ContainerBlkioStats:
+    description: |
+      BlkioStats stores all IO service stats for data read and write.
+
+      This type is Linux-specific and holds many fields that are specific to cgroups v1.
+      On a cgroup v2 host, all fields other than `io_service_bytes_recursive`
+      are omitted or `null`.
+
+      This type is only populated on Linux and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStats"
+    x-nullable: true
+    properties:
+      io_service_bytes_recursive:
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_serviced_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_queue_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_service_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_wait_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_merged_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      sectors_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+    example:
+      io_service_bytes_recursive: [
+        {"major": 254, "minor": 0, "op": "read", "value": 7593984},
+        {"major": 254, "minor": 0, "op": "write", "value": 100}
+      ]
+      io_serviced_recursive: null
+      io_queue_recursive: null
+      io_service_time_recursive: null
+      io_wait_time_recursive: null
+      io_merged_recursive: null
+      io_time_recursive: null
+      sectors_recursive: null
+
+  ContainerBlkioStatEntry:
+    description: |
+      Blkio stats entry.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStatEntry"
+    x-nullable: true
+    properties:
+      major:
+        type: "integer"
+        format: "uint64"
+        example: 254
+      minor:
+        type: "integer"
+        format: "uint64"
+        example: 0
+      op:
+        type: "string"
+        example: "read"
+      value:
+        type: "integer"
+        format: "uint64"
+        example: 7593984
+
+  ContainerCPUStats:
+    description: |
+      CPU related info of the container
+    type: "object"
+    x-go-name: "CPUStats"
+    x-nullable: true
+    properties:
+      cpu_usage:
+        $ref: "#/definitions/ContainerCPUUsage"
+      system_cpu_usage:
+        description: |
+          System Usage.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      online_cpus:
+        description: |
+          Number of online CPUs.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint32"
+        x-nullable: true
+        example: 5
+      throttling_data:
+        $ref: "#/definitions/ContainerThrottlingData"
+
+  ContainerCPUUsage:
+    description: |
+      All CPU stats aggregated since container inception.
+    type: "object"
+    x-go-name: "CPUUsage"
+    x-nullable: true
+    properties:
+      total_usage:
+        description: |
+          Total CPU time consumed in nanoseconds (Linux) or 100's of nanoseconds (Windows).
+        type: "integer"
+        format: "uint64"
+        example: 29912000
+      percpu_usage:
+        description: |
+          Total CPU time (in nanoseconds) consumed per core (Linux).
+
+          This field is Linux-specific when using cgroups v1. It is omitted
+          when using cgroups v2 and Windows containers.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "integer"
+          format: "uint64"
+          example: 29912000
+
+      usage_in_kernelmode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in kernel mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 21994000
+      usage_in_usermode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in user mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 7918000
+
+  ContainerPidsStats:
+    description: |
+      PidsStats contains Linux-specific stats of a container's process-IDs (PIDs).
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "PidsStats"
+    x-nullable: true
+    properties:
+      current:
+        description: |
+          Current is the number of PIDs in the cgroup.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      limit:
+        description: |
+          Limit is the hard limit on the number of pids in the cgroup.
+          A "Limit" of 0 means that there is no limit.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: "18446744073709551615"
+
+  ContainerThrottlingData:
+    description: |
+      CPU throttling stats of the container.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "ThrottlingData"
+    x-nullable: true
+    properties:
+      periods:
+        description: |
+          Number of periods with throttling active.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_periods:
+        description: |
+          Number of periods when the container hit its throttling limit.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_time:
+        description: |
+          Aggregated time (in nanoseconds) the container was throttled for.
+        type: "integer"
+        format: "uint64"
+        example: 0
+
+  ContainerMemoryStats:
+    description: |
+      Aggregates all memory stats since container inception on Linux.
+      Windows returns stats for commit and private working set only.
+    type: "object"
+    x-go-name: "MemoryStats"
+    properties:
+      usage:
+        description: |
+          Current `res_counter` usage for memory.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      max_usage:
+        description: |
+          Maximum usage ever recorded.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      stats:
+        description: |
+          All the stats exported via memory.stat.
+
+          The fields in this object differ between cgroups v1 and v2.
+          On cgroups v1, fields such as `cache`, `rss`, `mapped_file` are available.
+          On cgroups v2, fields such as `file`, `anon`, `inactive_file` are available.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "object"
+        additionalProperties:
+          type: "integer"
+          format: "uint64"
+          x-nullable: true
+        example:
+          {
+            "active_anon": 1572864,
+            "active_file": 5115904,
+            "anon": 1572864,
+            "anon_thp": 0,
+            "file": 7626752,
+            "file_dirty": 0,
+            "file_mapped": 2723840,
+            "file_writeback": 0,
+            "inactive_anon": 0,
+            "inactive_file": 2510848,
+            "kernel_stack": 16384,
+            "pgactivate": 0,
+            "pgdeactivate": 0,
+            "pgfault": 2042,
+            "pglazyfree": 0,
+            "pglazyfreed": 0,
+            "pgmajfault": 45,
+            "pgrefill": 0,
+            "pgscan": 0,
+            "pgsteal": 0,
+            "shmem": 0,
+            "slab": 1180928,
+            "slab_reclaimable": 725576,
+            "slab_unreclaimable": 455352,
+            "sock": 0,
+            "thp_collapse_alloc": 0,
+            "thp_fault_alloc": 1,
+            "unevictable": 0,
+            "workingset_activate": 0,
+            "workingset_nodereclaim": 0,
+            "workingset_refault": 0
+          }
+      failcnt:
+        description: |
+          Number of times memory usage hits limits.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      limit:
+        description: |
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 8217579520
+      commitbytes:
+        description: |
+          Committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      commitpeakbytes:
+        description: |
+          Peak committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      privateworkingset:
+        description: |
+          Private working set.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+
+  ContainerNetworkStats:
+    description: |
+      Aggregates the network stats of one container
+    type: "object"
+    x-go-name: "NetworkStats"
+    x-nullable: true
+    properties:
+      rx_bytes:
+        description: |
+          Bytes received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 5338
+      rx_packets:
+        description: |
+          Packets received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 36
+      rx_errors:
+        description: |
+          Received errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      rx_dropped:
+        description: |
+          Incoming packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_bytes:
+        description: |
+          Bytes sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 1200
+      tx_packets:
+        description: |
+          Packets sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 12
+      tx_errors:
+        description: |
+          Sent errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_dropped:
+        description: |
+          Outgoing packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      endpoint_id:
+        description: |
+          Endpoint ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+      instance_id:
+        description: |
+          Instance ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+
+  ContainerStorageStats:
+    description: |
+      StorageStats is the disk I/O stats for read/write on Windows.
+
+      This type is Windows-specific and omitted for Linux containers.
+    type: "object"
+    x-go-name: "StorageStats"
+    x-nullable: true
+    properties:
+      read_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      read_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+
+  ContainerTopResponse:
+    type: "object"
+    x-go-name: "TopResponse"
+    title: "ContainerTopResponse"
+    description: |-
+      Container "top" response.
+    properties:
+      Titles:
+        description: "The ps column titles"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          Titles:
+            - "UID"
+            - "PID"
+            - "PPID"
+            - "C"
+            - "STIME"
+            - "TTY"
+            - "TIME"
+            - "CMD"
+      Processes:
+        description: |-
+          Each process running in the container, where each process
+          is an array of values corresponding to the titles.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          Processes:
+            -
+              - "root"
+              - "13642"
+              - "882"
+              - "0"
+              - "17:03"
+              - "pts/0"
+              - "00:00:00"
+              - "/bin/bash"
+            -
+              - "root"
+              - "13735"
+              - "13642"
+              - "0"
+              - "17:06"
+              - "pts/0"
+              - "00:00:00"
+              - "sleep 10"
+
+  ContainerWaitResponse:
+    description: "OK response to ContainerWait operation"
+    type: "object"
+    x-go-name: "WaitResponse"
+    title: "ContainerWaitResponse"
+    required: [StatusCode]
+    properties:
+      StatusCode:
+        description: "Exit code of the container"
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Error:
+        $ref: "#/definitions/ContainerWaitExitError"
+
+  ContainerWaitExitError:
+    description: "container waiting error, if any"
+    type: "object"
+    x-go-name: "WaitExitError"
+    properties:
+      Message:
+        description: "Details of an error"
+        type: "string"
+
+  SystemVersion:
+    type: "object"
+    description: |
+      Response of Engine API: GET "/version"
+    properties:
+      Platform:
+        type: "object"
+        required: [Name]
+        properties:
+          Name:
+            type: "string"
+      Components:
+        type: "array"
+        description: |
+          Information about system components
+        items:
+          type: "object"
+          x-go-name: ComponentVersion
+          required: [Name, Version]
+          properties:
+            Name:
+              description: |
+                Name of the component
+              type: "string"
+              example: "Engine"
+            Version:
+              description: |
+                Version of the component
+              type: "string"
+              x-nullable: false
+              example: "27.0.1"
+            Details:
+              description: |
+                Key/value pairs of strings with additional information about the
+                component. These values are intended for informational purposes
+                only, and their content is not defined, and not part of the API
+                specification.
+
+                These messages can be printed by the client as information to the user.
+              type: "object"
+              x-nullable: true
+      Version:
+        description: "The version of the daemon"
+        type: "string"
+        example: "27.0.1"
+      ApiVersion:
+        description: |
+          The default (and highest) API version that is supported by the daemon
+        type: "string"
+        example: "1.47"
+      MinAPIVersion:
+        description: |
+          The minimum API version that is supported by the daemon
+        type: "string"
+        example: "1.24"
+      GitCommit:
+        description: |
+          The Git commit of the source code that was used to build the daemon
+        type: "string"
+        example: "48a66213fe"
+      GoVersion:
+        description: |
+          The version Go used to compile the daemon, and the version of the Go
+          runtime in use.
+        type: "string"
+        example: "go1.22.7"
+      Os:
+        description: |
+          The operating system that the daemon is running on ("linux" or "windows")
+        type: "string"
+        example: "linux"
+      Arch:
+        description: |
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "amd64"
+      KernelVersion:
+        description: |
+          The kernel version (`uname -r`) that the daemon is running on.
+
+          This field is omitted when empty.
+        type: "string"
+        example: "6.8.0-31-generic"
+      Experimental:
+        description: |
+          Indicates if the daemon is started with experimental features enabled.
+
+          This field is omitted when empty / false.
+        type: "boolean"
+        example: true
+      BuildTime:
+        description: |
+          The date and time that the daemon was compiled.
+        type: "string"
+        example: "2020-06-22T15:49:27.000000000+00:00"
+
+  SystemInfo:
+    type: "object"
+    properties:
+      ID:
+        description: |
+          Unique identifier of the daemon.
+
+          <p><br /></p>
+
+          > **Note**: The format of the ID itself is not part of the API, and
+          > should not be considered stable.
+        type: "string"
+        example: "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS"
+      Containers:
+        description: "Total number of containers on the host."
+        type: "integer"
+        example: 14
+      ContainersRunning:
+        description: |
+          Number of containers with status `"running"`.
+        type: "integer"
+        example: 3
+      ContainersPaused:
+        description: |
+          Number of containers with status `"paused"`.
+        type: "integer"
+        example: 1
+      ContainersStopped:
+        description: |
+          Number of containers with status `"stopped"`.
+        type: "integer"
+        example: 10
+      Images:
+        description: |
+          Total number of images on the host.
+
+          Both _tagged_ and _untagged_ (dangling) images are counted.
+        type: "integer"
+        example: 508
+      Driver:
+        description: "Name of the storage driver in use."
+        type: "string"
+        example: "overlay2"
+      DriverStatus:
+        description: |
+          Information specific to the storage driver, provided as
+          "label" / "value" pairs.
+
+          This information is provided by the storage driver, and formatted
+          in a way consistent with the output of `docker info` on the command
+          line.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["Backing Filesystem", "extfs"]
+          - ["Supports d_type", "true"]
+          - ["Native Overlay Diff", "true"]
+      DockerRootDir:
+        description: |
+          Root directory of persistent Docker state.
+
+          Defaults to `/var/lib/docker` on Linux, and `C:\ProgramData\docker`
+          on Windows.
+        type: "string"
+        example: "/var/lib/docker"
+      Plugins:
+        $ref: "#/definitions/PluginsInfo"
+      MemoryLimit:
+        description: "Indicates if the host has memory limit support enabled."
+        type: "boolean"
+        example: true
+      SwapLimit:
+        description: "Indicates if the host has memory swap limit support enabled."
+        type: "boolean"
+        example: true
+      KernelMemoryTCP:
+        description: |
+          Indicates if the host has kernel memory TCP limit support enabled. This
+          field is omitted if not supported.
+
+          Kernel memory TCP limits are not supported when using cgroups v2, which
+          does not support the corresponding `memory.kmem.tcp.limit_in_bytes` cgroup.
+
+          **Deprecated**: This field is deprecated as kernel 6.12 has deprecated kernel memory TCP accounting.
+        type: "boolean"
+        example: true
+      CpuCfsPeriod:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) period is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CpuCfsQuota:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) quota is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CPUShares:
+        description: |
+          Indicates if CPU Shares limiting is supported by the host.
+        type: "boolean"
+        example: true
+      CPUSet:
+        description: |
+          Indicates if CPUsets (cpuset.cpus, cpuset.mems) are supported by the host.
+
+          See [cpuset(7)](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt)
+        type: "boolean"
+        example: true
+      PidsLimit:
+        description: "Indicates if the host kernel has PID limit support enabled."
+        type: "boolean"
+        example: true
+      OomKillDisable:
+        description: "Indicates if OOM killer disable is supported on the host."
+        type: "boolean"
+      IPv4Forwarding:
+        description: "Indicates IPv4 forwarding is enabled."
+        type: "boolean"
+        example: true
+      Debug:
+        description: |
+          Indicates if the daemon is running in debug-mode / with debug-level
+          logging enabled.
+        type: "boolean"
+        example: true
+      NFd:
+        description: |
+          The total number of file Descriptors in use by the daemon process.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 64
+      NGoroutines:
+        description: |
+          The  number of goroutines that currently exist.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 174
+      SystemTime:
+        description: |
+          Current system-time in [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          format with nano-seconds.
+        type: "string"
+        example: "2017-08-08T20:28:29.06202363Z"
+      LoggingDriver:
+        description: |
+          The logging driver to use as a default for new containers.
+        type: "string"
+      CgroupDriver:
+        description: |
+          The driver to use for managing cgroups.
+        type: "string"
+        enum: ["cgroupfs", "systemd", "none"]
+        default: "cgroupfs"
+        example: "cgroupfs"
+      CgroupVersion:
+        description: |
+          The version of the cgroup.
+        type: "string"
+        enum: ["1", "2"]
+        default: "1"
+        example: "1"
+      NEventsListener:
+        description: "Number of event listeners subscribed."
+        type: "integer"
+        example: 30
+      KernelVersion:
+        description: |
+          Kernel version of the host.
+
+          On Linux, this information obtained from `uname`. On Windows this
+          information is queried from the <kbd>HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\</kbd>
+          registry value, for example _"10.0 14393 (14393.1198.amd64fre.rs1_release_sec.170427-1353)"_.
+        type: "string"
+        example: "6.8.0-31-generic"
+      OperatingSystem:
+        description: |
+          Name of the host's operating system, for example: "Ubuntu 24.04 LTS"
+          or "Windows Server 2016 Datacenter"
+        type: "string"
+        example: "Ubuntu 24.04 LTS"
+      OSVersion:
+        description: |
+          Version of the host's operating system
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including its
+          > very existence, and the formatting of values, should not be considered
+          > stable, and may change without notice.
+        type: "string"
+        example: "24.04"
+      OSType:
+        description: |
+          Generic type of the operating system of the host, as returned by the
+          Go runtime (`GOOS`).
+
+          Currently returned values are "linux" and "windows". A full list of
+          possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "linux"
+      Architecture:
+        description: |
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
+
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
+        type: "string"
+        example: "x86_64"
+      NCPU:
+        description: |
+          The number of logical CPUs usable by the daemon.
+
+          The number of available CPUs is checked by querying the operating
+          system when the daemon starts. Changes to operating system CPU
+          allocation after the daemon is started are not reflected.
+        type: "integer"
+        example: 4
+      MemTotal:
+        description: |
+          Total amount of physical memory available on the host, in bytes.
+        type: "integer"
+        format: "int64"
+        example: 2095882240
+
+      IndexServerAddress:
+        description: |
+          Address / URL of the index server that is used for image search,
+          and as a default for user authentication for Docker Hub and Docker Cloud.
+        default: "https://index.docker.io/v1/"
+        type: "string"
+        example: "https://index.docker.io/v1/"
+      RegistryConfig:
+        $ref: "#/definitions/RegistryServiceConfig"
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+      HttpProxy:
+        description: |
+          HTTP-proxy configured for the daemon. This value is obtained from the
+          [`HTTP_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "http://xxxxx:xxxxx@proxy.corp.example.com:8080"
+      HttpsProxy:
+        description: |
+          HTTPS-proxy configured for the daemon. This value is obtained from the
+          [`HTTPS_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "https://xxxxx:xxxxx@proxy.corp.example.com:4443"
+      NoProxy:
+        description: |
+          Comma-separated list of domain extensions for which no proxy should be
+          used. This value is obtained from the [`NO_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html)
+          environment variable.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "*.local, 169.254/16"
+      Name:
+        description: "Hostname of the host."
+        type: "string"
+        example: "node5.corp.example.com"
+      Labels:
+        description: |
+          User-defined labels (key/value metadata) as set on the daemon.
+
+          <p><br /></p>
+
+          > **Note**: When part of a Swarm, nodes can both have _daemon_ labels,
+          > set through the daemon configuration, and _node_ labels, set from a
+          > manager node in the Swarm. Node labels are not included in this
+          > field. Node labels can be retrieved using the `/nodes/(id)` endpoint
+          > on a manager node in the Swarm.
+        type: "array"
+        items:
+          type: "string"
+        example: ["storage=ssd", "production"]
+      ExperimentalBuild:
+        description: |
+          Indicates if experimental features are enabled on the daemon.
+        type: "boolean"
+        example: true
+      ServerVersion:
+        description: |
+          Version string of the daemon.
+        type: "string"
+        example: "27.0.1"
+      Runtimes:
+        description: |
+          List of [OCI compliant](https://github.com/opencontainers/runtime-spec)
+          runtimes configured on the daemon. Keys hold the "name" used to
+          reference the runtime.
+
+          The Docker daemon relies on an OCI compliant runtime (invoked via the
+          `containerd` daemon) as its interface to the Linux kernel namespaces,
+          cgroups, and SELinux.
+
+          The default runtime is `runc`, and automatically configured. Additional
+          runtimes can be configured by the user and will be listed here.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/Runtime"
+        default:
+          runc:
+            path: "runc"
+        example:
+          runc:
+            path: "runc"
+          runc-master:
+            path: "/go/bin/runc"
+          custom:
+            path: "/usr/local/bin/my-oci-runtime"
+            runtimeArgs: ["--debug", "--systemd-cgroup=false"]
+      DefaultRuntime:
+        description: |
+          Name of the default OCI runtime that is used when starting containers.
+
+          The default can be overridden per-container at create time.
+        type: "string"
+        default: "runc"
+        example: "runc"
+      Swarm:
+        $ref: "#/definitions/SwarmInfo"
+      LiveRestoreEnabled:
+        description: |
+          Indicates if live restore is enabled.
+
+          If enabled, containers are kept running when the daemon is shutdown
+          or upon daemon start if running containers are detected.
+        type: "boolean"
+        default: false
+        example: false
+      Isolation:
+        description: |
+          Represents the isolation technology to use as a default for containers.
+          The supported values are platform-specific.
+
+          If no isolation value is specified on daemon start, on Windows client,
+          the default is `hyperv`, and on Windows server, the default is `process`.
+
+          This option is currently not used on other platforms.
+        default: "default"
+        type: "string"
+        enum:
+          - "default"
+          - "hyperv"
+          - "process"
+          - ""
+      InitBinary:
+        description: |
+          Name and, optional, path of the `docker-init` binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "docker-init"
+      ContainerdCommit:
+        $ref: "#/definitions/Commit"
+      RuncCommit:
+        $ref: "#/definitions/Commit"
+      InitCommit:
+        $ref: "#/definitions/Commit"
+      SecurityOptions:
+        description: |
+          List of security features that are enabled on the daemon, such as
+          apparmor, seccomp, SELinux, user-namespaces (userns), rootless and
+          no-new-privileges.
+
+          Additional configuration options for each security feature may
+          be present, and are included as a comma-separated list of key/value
+          pairs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "name=apparmor"
+          - "name=seccomp,profile=default"
+          - "name=selinux"
+          - "name=userns"
+          - "name=rootless"
+      ProductLicense:
+        description: |
+          Reports a summary of the product license on the daemon.
+
+          If a commercial license has been applied to the daemon, information
+          such as number of nodes, and expiration are included.
+        type: "string"
+        example: "Community Engine"
+      DefaultAddressPools:
+        description: |
+          List of custom default address pools for local networks, which can be
+          specified in the daemon.json file or dockerd option.
+
+          Example: a Base "10.10.0.0/16" with Size 24 will define the set of 256
+          10.10.[0-255].0/24 address pools.
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Base:
+              description: "The network address in CIDR format"
+              type: "string"
+              example: "10.10.0.0/16"
+            Size:
+              description: "The network pool size"
+              type: "integer"
+              example: "24"
+      FirewallBackend:
+        $ref: "#/definitions/FirewallInfo"
+      DiscoveredDevices:
+        description: |
+          List of devices discovered by device drivers.
+
+          Each device includes information about its source driver, kind, name,
+          and additional driver-specific attributes.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceInfo"
+      Warnings:
+        description: |
+          List of warnings / informational messages about missing features, or
+          issues related to the daemon configuration.
+
+          These messages can be printed by the client as information to the user.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "WARNING: No memory limit support"
+      CDISpecDirs:
+        description: |
+          List of directories where (Container Device Interface) CDI
+          specifications are located.
+
+          These specifications define vendor-specific modifications to an OCI
+          runtime specification for a container being created.
+
+          An empty list indicates that CDI device injection is disabled.
+
+          Note that since using CDI device injection requires the daemon to have
+          experimental enabled. For non-experimental daemons an empty list will
+          always be returned.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/etc/cdi"
+          - "/var/run/cdi"
+      Containerd:
+        $ref: "#/definitions/ContainerdInfo"
+
+  ContainerdInfo:
+    description: |
+      Information for connecting to the containerd instance that is used by the daemon.
+      This is included for debugging purposes only.
+    type: "object"
+    x-nullable: true
+    properties:
+      Address:
+        description: "The address of the containerd socket."
+        type: "string"
+        example: "/run/containerd/containerd.sock"
+      Namespaces:
+        description: |
+          The namespaces that the daemon uses for running containers and
+          plugins in containerd. These namespaces can be configured in the
+          daemon configuration, and are considered to be used exclusively
+          by the daemon, Tampering with the containerd instance may cause
+          unexpected behavior.
+
+          As these namespaces are considered to be exclusively accessed
+          by the daemon, it is not recommended to change these values,
+          or to change them to a value that is used by other systems,
+          such as cri-containerd.
+        type: "object"
+        properties:
+          Containers:
+            description: |
+              The default containerd namespace used for containers managed
+              by the daemon.
+
+              The default namespace for containers is "moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "moby"
+            example: "moby"
+          Plugins:
+            description: |
+              The default containerd namespace used for plugins managed by
+              the daemon.
+
+              The default namespace for plugins is "plugins.moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "plugins.moby"
+            example: "plugins.moby"
+
+  FirewallInfo:
+    description: |
+      Information about the daemon's firewalling configuration.
+
+      This field is currently only used on Linux, and omitted on other platforms.
+    type: "object"
+    x-nullable: true
+    properties:
+      Driver:
+        description: |
+          The name of the firewall backend driver.
+        type: "string"
+        example: "nftables"
+      Info:
+        description: |
+          Information about the firewall backend, provided as
+          "label" / "value" pairs.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["ReloadedAt", "2025-01-01T00:00:00Z"]
+
+  # PluginsInfo is a temp struct holding Plugins name
+  # registered with docker daemon. It is used by Info struct
+  PluginsInfo:
+    description: |
+      Available plugins per type.
+
+      <p><br /></p>
+
+      > **Note**: Only unmanaged (V1) plugins are included in this list.
+      > V1 plugins are "lazily" loaded, and are not returned in this list
+      > if there is no resource using the plugin.
+    type: "object"
+    properties:
+      Volume:
+        description: "Names of available volume-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["local"]
+      Network:
+        description: "Names of available network-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["bridge", "host", "ipvlan", "macvlan", "null", "overlay"]
+      Authorization:
+        description: "Names of available authorization plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["img-authz-plugin", "hbm"]
+      Log:
+        description: "Names of available logging-drivers, and logging-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["awslogs", "fluentd", "gcplogs", "gelf", "journald", "json-file", "splunk", "syslog"]
+
+
+  RegistryServiceConfig:
+    description: |
+      RegistryServiceConfig stores daemon registry services configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      InsecureRegistryCIDRs:
+        description: |
+          List of IP ranges of insecure registries, using the CIDR syntax
+          ([RFC 4632](https://tools.ietf.org/html/4632)). Insecure registries
+          accept un-encrypted (HTTP) and/or untrusted (HTTPS with certificates
+          from unknown CAs) communication.
+
+          By default, local registries (`::1/128` and `127.0.0.0/8`) are configured as
+          insecure. All other registries are secure. Communicating with an
+          insecure registry is not possible if the daemon assumes that registry
+          is secure.
+
+          This configuration override this behavior, insecure communication with
+          registries whose resolved IP address is within the subnet described by
+          the CIDR syntax.
+
+          Registries can also be marked insecure by hostname. Those registries
+          are listed under `IndexConfigs` and have their `Secure` field set to
+          `false`.
+
+          > **Warning**: Using this option can be useful when running a local
+          > registry, but introduces security vulnerabilities. This option
+          > should therefore ONLY be used for testing purposes. For increased
+          > security, users should add their CA to their system's list of trusted
+          > CAs instead of enabling this option.
+        type: "array"
+        items:
+          type: "string"
+        example: ["::1/128", "127.0.0.0/8"]
+      IndexConfigs:
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/IndexInfo"
+        example:
+          "127.0.0.1:5000":
+            "Name": "127.0.0.1:5000"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "[2001:db8:a0b:12f0::1]:80":
+            "Name": "[2001:db8:a0b:12f0::1]:80"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "docker.io":
+            Name: "docker.io"
+            Mirrors: ["https://hub-mirror.corp.example.com:5000/"]
+            Secure: true
+            Official: true
+          "registry.internal.corp.example.com:3000":
+            Name: "registry.internal.corp.example.com:3000"
+            Mirrors: []
+            Secure: false
+            Official: false
+      Mirrors:
+        description: |
+          List of registry URLs that act as a mirror for the official
+          (`docker.io`) registry.
+
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://[2001:db8:a0b:12f0::1]/"
+
+  IndexInfo:
+    description:
+      IndexInfo contains information about a registry.
+    type: "object"
+    x-nullable: true
+    properties:
+      Name:
+        description: |
+          Name of the registry, such as "docker.io".
+        type: "string"
+        example: "docker.io"
+      Mirrors:
+        description: |
+          List of mirrors, expressed as URIs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://registry-2.docker.io/"
+          - "https://registry-3.docker.io/"
+      Secure:
+        description: |
+          Indicates if the registry is part of the list of insecure
+          registries.
+
+          If `false`, the registry is insecure. Insecure registries accept
+          un-encrypted (HTTP) and/or untrusted (HTTPS with certificates from
+          unknown CAs) communication.
+
+          > **Warning**: Insecure registries can be useful when running a local
+          > registry. However, because its use creates security vulnerabilities
+          > it should ONLY be enabled for testing purposes. For increased
+          > security, users should add their CA to their system's list of
+          > trusted CAs instead of enabling this option.
+        type: "boolean"
+        example: true
+      Official:
+        description: |
+          Indicates whether this is an official registry (i.e., Docker Hub / docker.io)
+        type: "boolean"
+        example: true
+
+  Runtime:
+    description: |
+      Runtime describes an [OCI compliant](https://github.com/opencontainers/runtime-spec)
+      runtime.
+
+      The runtime is invoked by the daemon via the `containerd` daemon. OCI
+      runtimes act as an interface to the Linux kernel namespaces, cgroups,
+      and SELinux.
+    type: "object"
+    properties:
+      path:
+        description: |
+          Name and, optional, path, of the OCI executable binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "/usr/local/bin/my-oci-runtime"
+      runtimeArgs:
+        description: |
+          List of command-line arguments to pass to the runtime when invoked.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["--debug", "--systemd-cgroup=false"]
+      status:
+        description: |
+          Information specific to the runtime.
+
+          While this API specification does not define data provided by runtimes,
+          the following well-known properties may be provided by runtimes:
+
+          `org.opencontainers.runtime-spec.features`: features structure as defined
+          in the [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec/blob/main/features.md),
+          in a JSON string representation.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "org.opencontainers.runtime-spec.features": "{\"ociVersionMin\":\"1.0.0\",\"ociVersionMax\":\"1.1.0\",\"...\":\"...\"}"
+
+  Commit:
+    description: |
+      Commit holds the Git-commit (SHA1) that a binary was built from, as
+      reported in the version-string of external tools, such as `containerd`,
+      or `runC`.
+    type: "object"
+    properties:
+      ID:
+        description: "Actual commit ID of external tool."
+        type: "string"
+        example: "cfb82a876ecc11b5ca0977d1733adbe58599088a"
+
+  SwarmInfo:
+    description: |
+      Represents generic information about swarm.
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+        default: ""
+        example: "k67qz4598weg5unwwffg6z1m1"
+      NodeAddr:
+        description: |
+          IP address at which this node can be reached by other nodes in the
+          swarm.
+        type: "string"
+        default: ""
+        example: "10.0.0.46"
+      LocalNodeState:
+        $ref: "#/definitions/LocalNodeState"
+      ControlAvailable:
+        type: "boolean"
+        default: false
+        example: true
+      Error:
+        type: "string"
+        default: ""
+      RemoteManagers:
+        description: |
+          List of ID's and addresses of other managers in the swarm.
+        type: "array"
+        default: null
+        x-nullable: true
+        items:
+          $ref: "#/definitions/PeerNode"
+        example:
+          - NodeID: "71izy0goik036k48jg985xnds"
+            Addr: "10.0.0.158:2377"
+          - NodeID: "79y6h1o4gv8n120drcprv5nmc"
+            Addr: "10.0.0.159:2377"
+          - NodeID: "k67qz4598weg5unwwffg6z1m1"
+            Addr: "10.0.0.46:2377"
+      Nodes:
+        description: "Total number of nodes in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 4
+      Managers:
+        description: "Total number of managers in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 3
+      Cluster:
+        $ref: "#/definitions/ClusterInfo"
+
+  LocalNodeState:
+    description: "Current local status of this node."
+    type: "string"
+    default: ""
+    enum:
+      - ""
+      - "inactive"
+      - "pending"
+      - "active"
+      - "error"
+      - "locked"
+    example: "active"
+
+  PeerNode:
+    description: "Represents a peer-node in the swarm"
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+      Addr:
+        description: |
+          IP address and ports at which this node can be reached.
+        type: "string"
+
+  NetworkAttachmentConfig:
+    description: |
+      Specifies how a service should be attached to a particular network.
+    type: "object"
+    properties:
+      Target:
+        description: |
+          The target network for attachment. Must be a network name or ID.
+        type: "string"
+      Aliases:
+        description: |
+          Discoverable alternate names for the service on this network.
+        type: "array"
+        items:
+          type: "string"
+      DriverOpts:
+        description: |
+          Driver attachment options for the network target.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  EventActor:
+    description: |
+      Actor describes something that generates events, like a container, network,
+      or a volume.
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the object emitting the event"
+        type: "string"
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Attributes:
+        description: |
+          Various key/value attributes of the object, depending on its type.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-label-value"
+          image: "alpine:latest"
+          name: "my-container"
+
+  EventMessage:
+    description: |
+      EventMessage represents the information an event contains.
+    type: "object"
+    title: "SystemEventsResponse"
+    properties:
+      Type:
+        description: "The type of object emitting the event"
+        type: "string"
+        enum: ["builder", "config", "container", "daemon", "image", "network", "node", "plugin", "secret", "service", "volume"]
+        example: "container"
+      Action:
+        description: "The type of event"
+        type: "string"
+        example: "create"
+      Actor:
+        $ref: "#/definitions/EventActor"
+      scope:
+        description: |
+          Scope of the event. Engine events are `local` scope. Cluster (Swarm)
+          events are `swarm` scope.
+        type: "string"
+        enum: ["local", "swarm"]
+      time:
+        description: "Timestamp of event"
+        type: "integer"
+        format: "int64"
+        example: 1629574695
+      timeNano:
+        description: "Timestamp of event, with nanosecond accuracy"
+        type: "integer"
+        format: "int64"
+        example: 1629574695515050031
+
+  OCIDescriptor:
+    type: "object"
+    x-go-name: Descriptor
+    description: |
+      A descriptor struct containing digest, media type, and size, as defined in
+      the [OCI Content Descriptors Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/descriptor.md).
+    properties:
+      mediaType:
+        description: |
+          The media type of the object this schema refers to.
+        type: "string"
+        example: "application/vnd.oci.image.manifest.v1+json"
+      digest:
+        description: |
+          The digest of the targeted content.
+        type: "string"
+        example: "sha256:c0537ff6a5218ef531ece93d4984efc99bbf3f7497c0a7726c88e2bb7584dc96"
+      size:
+        description: |
+          The size in bytes of the blob.
+        type: "integer"
+        format: "int64"
+        example: 424
+      urls:
+        description: |-
+          List of URLs from which this object MAY be downloaded.
+        type: "array"
+        items:
+          type: "string"
+          format: "uri"
+        x-nullable: true
+      annotations:
+        description: |-
+          Arbitrary metadata relating to the targeted content.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "com.docker.official-images.bashbrew.arch": "amd64"
+          "org.opencontainers.image.base.digest": "sha256:0d0ef5c914d3ea700147da1bd050c59edb8bb12ca312f3800b29d7c8087eabd8"
+          "org.opencontainers.image.base.name": "scratch"
+          "org.opencontainers.image.created": "2025-01-27T00:00:00Z"
+          "org.opencontainers.image.revision": "9fabb4bad5138435b01857e2fe9363e2dc5f6a79"
+          "org.opencontainers.image.source": "https://git.launchpad.net/cloud-images/+oci/ubuntu-base"
+          "org.opencontainers.image.url": "https://hub.docker.com/_/ubuntu"
+          "org.opencontainers.image.version": "24.04"
+      data:
+        type: string
+        x-nullable: true
+        description: |-
+          Data is an embedding of the targeted content. This is encoded as a base64
+          string when marshalled to JSON (automatically, by encoding/json). If
+          present, Data can be used directly to avoid fetching the targeted content.
+        example: null
+      platform:
+        $ref: "#/definitions/OCIPlatform"
+      artifactType:
+        description: |-
+          ArtifactType is the IANA media type of this artifact.
+        type: "string"
+        x-nullable: true
+        example: null
+
+  OCIPlatform:
+    type: "object"
+    x-go-name: Platform
+    x-nullable: true
+    description: |
+      Describes the platform which the image in the manifest runs on, as defined
+      in the [OCI Image Index Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/image-index.md).
+    properties:
+      architecture:
+        description: |
+          The CPU architecture, for example `amd64` or `ppc64`.
+        type: "string"
+        example: "arm"
+      os:
+        description: |
+          The operating system, for example `linux` or `windows`.
+        type: "string"
+        example: "windows"
+      os.version:
+        description: |
+          Optional field specifying the operating system version, for example on
+          Windows `10.0.19041.1165`.
+        type: "string"
+        example: "10.0.19041.1165"
+      os.features:
+        description: |
+          Optional field specifying an array of strings, each listing a required
+          OS feature (for example on Windows `win32k`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "win32k"
+      variant:
+        description: |
+          Optional field specifying a variant of the CPU, for example `v7` to
+          specify ARMv7 when architecture is `arm`.
+        type: "string"
+        example: "v7"
+
+  DistributionInspect:
+    type: "object"
+    x-go-name: DistributionInspect
+    title: "DistributionInspectResponse"
+    required: [Descriptor, Platforms]
+    description: |
+      Describes the result obtained from contacting the registry to retrieve
+      image metadata.
+    properties:
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Platforms:
+        type: "array"
+        description: |
+          An array containing all platforms supported by the image.
+        items:
+          $ref: "#/definitions/OCIPlatform"
+
+  ClusterVolume:
+    type: "object"
+    description: |
+      Options and information specific to, and only present on, Swarm CSI
+      cluster volumes.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          The Swarm ID of this volume. Because cluster volumes are Swarm
+          objects, they have an ID, unlike non-cluster volumes. This ID can
+          be used to refer to the Volume instead of the name.
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+      Info:
+        type: "object"
+        description: |
+          Information about the global status of the volume.
+        properties:
+          CapacityBytes:
+            type: "integer"
+            format: "int64"
+            description: |
+              The capacity of the volume in bytes. A value of 0 indicates that
+              the capacity is unknown.
+          VolumeContext:
+            type: "object"
+            description: |
+              A map of strings to strings returned from the storage plugin when
+              the volume is created.
+            additionalProperties:
+              type: "string"
+          VolumeID:
+            type: "string"
+            description: |
+              The ID of the volume as returned by the CSI storage plugin. This
+              is distinct from the volume's ID as provided by Docker. This ID
+              is never used by the user when communicating with Docker to refer
+              to this volume. If the ID is blank, then the Volume has not been
+              successfully created in the plugin yet.
+          AccessibleTopology:
+            type: "array"
+            description: |
+              The topology this volume is actually accessible from.
+            items:
+              $ref: "#/definitions/Topology"
+      PublishStatus:
+        type: "array"
+        description: |
+          The status of the volume as it pertains to its publishing and use on
+          specific nodes
+        items:
+          type: "object"
+          properties:
+            NodeID:
+              type: "string"
+              description: |
+                The ID of the Swarm node the volume is published on.
+            State:
+              type: "string"
+              description: |
+                The published state of the volume.
+                * `pending-publish` The volume should be published to this node, but the call to the controller plugin to do so has not yet been successfully completed.
+                * `published` The volume is published successfully to the node.
+                * `pending-node-unpublish` The volume should be unpublished from the node, and the manager is awaiting confirmation from the worker that it has done so.
+                * `pending-controller-unpublish` The volume is successfully unpublished from the node, but has not yet been successfully unpublished on the controller.
+              enum:
+                - "pending-publish"
+                - "published"
+                - "pending-node-unpublish"
+                - "pending-controller-unpublish"
+            PublishContext:
+              type: "object"
+              description: |
+                A map of strings to strings returned by the CSI controller
+                plugin when a volume is published.
+              additionalProperties:
+                type: "string"
+
+  ClusterVolumeSpec:
+    type: "object"
+    description: |
+      Cluster-specific options used to create the volume.
+    properties:
+      Group:
+        type: "string"
+        description: |
+          Group defines the volume group of this volume. Volumes belonging to
+          the same group can be referred to by group name when creating
+          Services.  Referring to a volume by group instructs Swarm to treat
+          volumes in that group interchangeably for the purpose of scheduling.
+          Volumes with an empty string for a group technically all belong to
+          the same, emptystring group.
+      AccessMode:
+        type: "object"
+        description: |
+          Defines how the volume is used by tasks.
+        properties:
+          Scope:
+            type: "string"
+            description: |
+              The set of nodes this volume can be used on at one time.
+              - `single` The volume may only be scheduled to one node at a time.
+              - `multi` the volume may be scheduled to any supported number of nodes at a time.
+            default: "single"
+            enum: ["single", "multi"]
+            x-nullable: false
+          Sharing:
+            type: "string"
+            description: |
+              The number and way that different tasks can use this volume
+              at one time.
+              - `none` The volume may only be used by one task at a time.
+              - `readonly` The volume may be used by any number of tasks, but they all must mount the volume as readonly
+              - `onewriter` The volume may be used by any number of tasks, but only one may mount it as read/write.
+              - `all` The volume may have any number of readers and writers.
+            default: "none"
+            enum: ["none", "readonly", "onewriter", "all"]
+            x-nullable: false
+          MountVolume:
+            type: "object"
+            description: |
+              Options for using this volume as a Mount-type volume.
+
+                  Either MountVolume or BlockVolume, but not both, must be
+                  present.
+                properties:
+                  FsType:
+                    type: "string"
+                    description: |
+                      Specifies the filesystem type for the mount volume.
+                      Optional.
+                  MountFlags:
+                    type: "array"
+                    description: |
+                      Flags to pass when mounting the volume. Optional.
+                    items:
+                      type: "string"
+              BlockVolume:
+                type: "object"
+                description: |
+                  Options for using this volume as a Block-type volume.
+                  Intentionally empty.
+          Secrets:
+            type: "array"
+            description: |
+              Swarm Secrets that are passed to the CSI storage plugin when
+              operating on this volume.
+            items:
+              type: "object"
+              description: |
+                One cluster volume secret entry. Defines a key-value pair that
+                is passed to the plugin.
+              properties:
+                Key:
+                  type: "string"
+                  description: |
+                    Key is the name of the key of the key-value pair passed to
+                    the plugin.
+                Secret:
+                  type: "string"
+                  description: |
+                    Secret is the swarm Secret object from which to read data.
+                    This can be a Secret name or ID. The Secret data is
+                    retrieved by swarm and used as the value of the key-value
+                    pair passed to the plugin.
+          AccessibilityRequirements:
+            type: "object"
+            description: |
+              Requirements for the accessible topology of the volume. These
+              fields are optional. For an in-depth description of what these
+              fields mean, see the CSI specification.
+            properties:
+              Requisite:
+                type: "array"
+                description: |
+                  A list of required topologies, at least one of which the
+                  volume must be accessible from.
+                items:
+                  $ref: "#/definitions/Topology"
+              Preferred:
+                type: "array"
+                description: |
+                  A list of topologies that the volume should attempt to be
+                  provisioned in.
+                items:
+                  $ref: "#/definitions/Topology"
+          CapacityRange:
+            type: "object"
+            description: |
+              The desired capacity that the volume should be created with. If
+              empty, the plugin will decide the capacity.
+            properties:
+              RequiredBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must be at least this big. The value of 0
+                  indicates an unspecified minimum
+              LimitBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must not be bigger than this. The value of 0
+                  indicates an unspecified maximum.
+          Availability:
+            type: "string"
+            description: |
+              The availability of the volume for use in tasks.
+              - `active` The volume is fully available for scheduling on the cluster
+              - `pause` No new workloads should use the volume, but existing workloads are not stopped.
+              - `drain` All workloads using this volume should be stopped and rescheduled, and no new ones should be started.
+            default: "active"
+            x-nullable: false
+            enum:
+              - "active"
+              - "pause"
+              - "drain"
+
+  Topology:
+    description: |
+      A map of topological domains to topological segments. For in depth
+      details, see documentation for the Topology object in the CSI
+      specification.
+    type: "object"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  ImageManifestSummary:
+    x-go-name: "ManifestSummary"
+    description: |
+      ImageManifestSummary represents a summary of an image manifest.
+    type: "object"
+    required: ["ID", "Descriptor", "Available", "Size", "Kind"]
+    properties:
+      ID:
+        description: |
+          ID is the content-addressable ID of an image and is the same as the
+          digest of the image manifest.
+        type: "string"
+        example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Available:
+        description: Indicates whether all the child content (image config, layers) is fully available locally.
+        type: "boolean"
+        example: true
+      Size:
+        type: "object"
+        x-nullable: false
+        required: ["Content", "Total"]
+        properties:
+          Total:
+            type: "integer"
+            format: "int64"
+            example: 8213251
+            description: |
+              Total is the total size (in bytes) of all the locally present
+              data (both distributable and non-distributable) that's related to
+              this manifest and its children.
+              This equal to the sum of [Content] size AND all the sizes in the
+              [Size] struct present in the Kind-specific data struct.
+              For example, for an image kind (Kind == "image")
+              this would include the size of the image content and unpacked
+              image snapshots ([Size.Content] + [ImageData.Size.Unpacked]).
+          Content:
+            description: |
+              Content is the size (in bytes) of all the locally present
+              content in the content store (e.g. image config, layers)
+              referenced by this manifest and its children.
+              This only includes blobs in the content store.
+            type: "integer"
+            format: "int64"
+            example: 3987495
+      Kind:
+        type: "string"
+        example: "image"
+        enum:
+          - "image"
+          - "attestation"
+          - "unknown"
+        description: |
+          The kind of the manifest.
+
+          kind         | description
+          -------------|-----------------------------------------------------------
+          image        | Image manifest that can be used to start a container.
+          attestation  | Attestation manifest produced by the Buildkit builder for a specific image manifest.
+      ImageData:
+        description: |
+          The image data for the image manifest.
+          This field is only populated when Kind is "image".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["Platform", "Containers", "Size", "UnpackedSize"]
+        properties:
+          Platform:
+            $ref: "#/definitions/OCIPlatform"
+            description: |
+              OCI platform of the image. This will be the platform specified in the
+              manifest descriptor from the index/manifest list.
+              If it's not available, it will be obtained from the image config.
+          Containers:
+            description: |
+              The IDs of the containers that are using this image.
+            type: "array"
+            items:
+              type: "string"
+            example: ["ede54ee1fda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c7430", "abadbce344c096744d8d6071a90d474d28af8f1034b5ea9fb03c3f4bfc6d005e"]
+          Size:
+            type: "object"
+            x-nullable: false
+            required: ["Unpacked"]
+            properties:
+              Unpacked:
+                type: "integer"
+                format: "int64"
+                example: 3987495
+                description: |
+                  Unpacked is the size (in bytes) of the locally unpacked
+                  (uncompressed) image content that's directly usable by the containers
+                  running this image.
+                  It's independent of the distributable content - e.g.
+                  the image might still have an unpacked data that's still used by
+                  some container even when the distributable/compressed content is
+                  already gone.
+      AttestationData:
+        description: |
+          The image data for the attestation manifest.
+          This field is only populated when Kind is "attestation".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["For"]
+        properties:
+          For:
+            description: |
+              The digest of the image manifest that this attestation is for.
+            type: "string"
+            example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+
+paths:
+  /containers/json:
+    get:
+      summary: "List containers"
+      description: |
+        Returns a list of containers. For details on the format, see the
+        [inspect endpoint](#operation/ContainerInspect).
+
+        Note that it uses a different, smaller representation of a container
+        than inspecting a single container. For example, the list of linked
+        containers is not propagated .
+      operationId: "ContainerList"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: |
+            Return all containers. By default, only running containers are shown.
+          type: "boolean"
+          default: false
+        - name: "limit"
+          in: "query"
+          description: |
+            Return this number of most recently created containers, including
+            non-running ones.
+          type: "integer"
+        - name: "size"
+          in: "query"
+          description: |
+            Return the size of container as fields `SizeRw` and `SizeRootFs`.
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the container list, encoded as JSON (a
+            `map[string][]string`). For example, `{"status": ["paused"]}` will
+            only return paused containers.
+
+            Available filters:
+
+            - `ancestor`=(`<image-name>[:<tag>]`, `<image id>`, or `<image@digest>`)
+            - `before`=(`<container id>` or `<container name>`)
+            - `expose`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `exited=<int>` containers with exit code of `<int>`
+            - `health`=(`starting`|`healthy`|`unhealthy`|`none`)
+            - `id=<ID>` a container's ID
+            - `isolation=`(`default`|`process`|`hyperv`) (Windows daemon only)
+            - `is-task=`(`true`|`false`)
+            - `label=key` or `label="key=value"` of a container label
+            - `name=<name>` a container's name
+            - `network`=(`<network id>` or `<network name>`)
+            - `publish`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `since`=(`<container id>` or `<container name>`)
+            - `status=`(`created`|`restarting`|`running`|`removing`|`paused`|`exited`|`dead`)
+            - `volume`=(`<volume name>` or `<mount point destination>`)
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ContainerSummary"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/create:
+    post:
+      summary: "Create a container"
+      operationId: "ContainerCreate"
+      consumes:
+        - "application/json"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            Assign the specified name to the container. Must match
+            `/?[a-zA-Z0-9][a-zA-Z0-9_.-]+`.
+          type: "string"
+          pattern: "^/?[a-zA-Z0-9][a-zA-Z0-9_.-]+$"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format `os[/arch[/variant]]` used for image lookup.
+
+            When specified, the daemon checks if the requested image is present
+            in the local image cache with the given OS and Architecture, and
+            otherwise returns a `404` status.
+
+            If the option is not set, the host's native OS and Architecture are
+            used to look up the image in the image cache. However, if no platform
+            is passed and the given image does exist in the local image cache,
+            but its OS or architecture does not match, the container is created
+            with the available image, and a warning is added to the `Warnings`
+            field in the response, for example;
+
+                WARNING: The requested image's platform (linux/arm64/v8) does not
+                         match the detected host platform (linux/amd64) and no
+                         specific platform was requested
+
+          type: "string"
+          default: ""
+        - name: "body"
+          in: "body"
+          description: "Container to create"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ContainerConfig"
+              - type: "object"
+                properties:
+                  HostConfig:
+                    $ref: "#/definitions/HostConfig"
+                  NetworkingConfig:
+                    $ref: "#/definitions/NetworkingConfig"
+            example:
+              Hostname: ""
+              Domainname: ""
+              User: ""
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              Tty: false
+              OpenStdin: false
+              StdinOnce: false
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+              Cmd:
+                - "date"
+              Entrypoint: ""
+              Image: "ubuntu"
+              Labels:
+                com.example.vendor: "Acme"
+                com.example.license: "GPL"
+                com.example.version: "1.0"
+              Volumes:
+                /volumes/data: {}
+              WorkingDir: ""
+              NetworkDisabled: false
+              MacAddress: "12:34:56:78:9a:bc"
+              ExposedPorts:
+                22/tcp: {}
+              StopSignal: "SIGTERM"
+              StopTimeout: 10
+              HostConfig:
+                Binds:
+                  - "/tmp:/tmp"
+                Links:
+                  - "redis3:redis"
+                Memory: 0
+                MemorySwap: 0
+                MemoryReservation: 0
+                NanoCpus: 500000
+                CpuPercent: 80
+                CpuShares: 512
+                CpuPeriod: 100000
+                CpuRealtimePeriod: 1000000
+                CpuRealtimeRuntime: 10000
+                CpuQuota: 50000
+                CpusetCpus: "0,1"
+                CpusetMems: "0,1"
+                MaximumIOps: 0
+                MaximumIOBps: 0
+                BlkioWeight: 300
+                BlkioWeightDevice:
+                  - {}
+                BlkioDeviceReadBps:
+                  - {}
+                BlkioDeviceReadIOps:
+                  - {}
+                BlkioDeviceWriteBps:
+                  - {}
+                BlkioDeviceWriteIOps:
+                  - {}
+                DeviceRequests:
+                  - Driver: "nvidia"
+                    Count: -1
+                    DeviceIDs": ["0", "1", "GPU-fef8089b-4820-abfc-e83e-94318197576e"]
+                    Capabilities: [["gpu", "nvidia", "compute"]]
+                    Options:
+                      property1: "string"
+                      property2: "string"
+                MemorySwappiness: 60
+                OomKillDisable: false
+                OomScoreAdj: 500
+                PidMode: ""
+                PidsLimit: 0
+                PortBindings:
+                  22/tcp:
+                    - HostPort: "11022"
+                PublishAllPorts: false
+                Privileged: false
+                ReadonlyRootfs: false
+                Dns:
+                  - "8.8.8.8"
+                DnsOptions:
+                  - ""
+                DnsSearch:
+                  - ""
+                VolumesFrom:
+                  - "parent"
+                  - "other:ro"
+                CapAdd:
+                  - "NET_ADMIN"
+                CapDrop:
+                  - "MKNOD"
+                GroupAdd:
+                  - "newgroup"
+                RestartPolicy:
+                  Name: ""
+                  MaximumRetryCount: 0
+                AutoRemove: true
+                NetworkMode: "bridge"
+                Devices: []
+                Ulimits:
+                  - {}
+                LogConfig:
+                  Type: "json-file"
+                  Config: {}
+                SecurityOpt: []
+                StorageOpt: {}
+                CgroupParent: ""
+                VolumeDriver: ""
+                ShmSize: 67108864
+              NetworkingConfig:
+                EndpointsConfig:
+                  isolated_nw:
+                    IPAMConfig:
+                      IPv4Address: "172.20.30.33"
+                      IPv6Address: "2001:db8:abcd::3033"
+                      LinkLocalIPs:
+                        - "169.254.34.68"
+                        - "fe80::3468"
+                    Links:
+                      - "container_1"
+                      - "container_2"
+                    Aliases:
+                      - "server_x"
+                      - "server_y"
+                  database_nw: {}
+
+          required: true
+      responses:
+        201:
+          description: "Container created successfully"
+          schema:
+            $ref: "#/definitions/ContainerCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/{id}/json:
+    get:
+      summary: "Inspect a container"
+      description: "Return low-level information about a container."
+      operationId: "ContainerInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerInspectResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "size"
+          in: "query"
+          type: "boolean"
+          default: false
+          description: "Return the size of container as fields `SizeRw` and `SizeRootFs`"
+      tags: ["Container"]
+  /containers/{id}/top:
+    get:
+      summary: "List processes running inside a container"
+      description: |
+        On Unix systems, this is done by running the `ps` command. This endpoint
+        is not supported on Windows.
+      operationId: "ContainerTop"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerTopResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "ps_args"
+          in: "query"
+          description: "The arguments to pass to `ps`. For example, `aux`"
+          type: "string"
+          default: "-ef"
+      tags: ["Container"]
+  /containers/{id}/logs:
+    get:
+      summary: "Get container logs"
+      description: |
+        Get `stdout` and `stderr` logs from a container.
+
+        Note: This endpoint works only for containers with the `json-file` or
+        `journald` logging driver.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ContainerLogs"
+      responses:
+        200:
+          description: |
+            logs returned as a stream in response body.
+            For the stream format, [see the documentation for the attach endpoint](#operation/ContainerAttach).
+            Note that unlike the attach endpoint, the logs endpoint does not
+            upgrade the connection and does not set Content-Type.
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "until"
+          in: "query"
+          description: "Only return logs before this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Container"]
+  /containers/{id}/changes:
+    get:
+      summary: "Get changes on a container’s filesystem"
+      description: |
+        Returns which files in a container's filesystem have been added, deleted,
+        or modified. The `Kind` of modification can be one of:
+
+        - `0`: Modified ("C")
+        - `1`: Added ("A")
+        - `2`: Deleted ("D")
+      operationId: "ContainerChanges"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The list of changes"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/FilesystemChange"
+          examples:
+            application/json:
+              - Path: "/dev"
+                Kind: 0
+              - Path: "/dev/kmsg"
+                Kind: 1
+              - Path: "/test"
+                Kind: 1
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/export:
+    get:
+      summary: "Export a container"
+      description: "Export the contents of a container as a tarball."
+      operationId: "ContainerExport"
+      produces:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stats:
+    get:
+      summary: "Get container stats based on resource usage"
+      description: |
+        This endpoint returns a live stream of a container’s resource usage
+        statistics.
+
+        The `precpu_stats` is the CPU statistic of the *previous* read, and is
+        used to calculate the CPU usage percentage. It is not an exact copy
+        of the `cpu_stats` field.
+
+        If either `precpu_stats.online_cpus` or `cpu_stats.online_cpus` is
+        nil then for compatibility with older daemons the length of the
+        corresponding `cpu_usage.percpu_usage` array should be used.
+
+        On a cgroup v2 host, the following fields are not set
+        * `blkio_stats`: all fields other than `io_service_bytes_recursive`
+        * `cpu_stats`: `cpu_usage.percpu_usage`
+        * `memory_stats`: `max_usage` and `failcnt`
+        Also, `memory_stats.stats` fields are incompatible with cgroup v1.
+
+        To calculate the values shown by the `stats` command of the docker cli tool
+        the following formulas can be used:
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
+        * available_memory = `memory_stats.limit`
+        * Memory usage % = `(used_memory / available_memory) * 100.0`
+        * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
+        * system_cpu_delta = `cpu_stats.system_cpu_usage - precpu_stats.system_cpu_usage`
+        * number_cpus = `length(cpu_stats.cpu_usage.percpu_usage)` or `cpu_stats.online_cpus`
+        * CPU usage % = `(cpu_delta / system_cpu_delta) * number_cpus * 100.0`
+      operationId: "ContainerStats"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerStatsResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream the output. If false, the stats will be output once and then
+            it will disconnect.
+          type: "boolean"
+          default: true
+        - name: "one-shot"
+          in: "query"
+          description: |
+            Only get a single stat instead of waiting for 2 cycles. Must be used
+            with `stream=false`.
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/resize:
+    post:
+      summary: "Resize a container TTY"
+      description: "Resize the TTY for a container."
+      operationId: "ContainerResize"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "cannot resize container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/start:
+    post:
+      summary: "Start a container"
+      operationId: "ContainerStart"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already started"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container. Format is a
+            single character `[a-Z]` or `ctrl-<value>` where `<value>` is one
+            of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stop:
+    post:
+      summary: "Stop a container"
+      operationId: "ContainerStop"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already stopped"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/restart:
+    post:
+      summary: "Restart a container"
+      operationId: "ContainerRestart"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/kill:
+    post:
+      summary: "Kill a container"
+      description: |
+        Send a POSIX signal to a container, defaulting to killing to the
+        container.
+      operationId: "ContainerKill"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is not running"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "Container d37cde0fe4ad63c3a7252023b2f9800282894247d145cb5933ddf6e52cc03a28 is not running"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+          default: "SIGKILL"
+      tags: ["Container"]
+  /containers/{id}/update:
+    post:
+      summary: "Update a container"
+      description: |
+        Change various configuration options of a container without having to
+        recreate it.
+      operationId: "ContainerUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has been updated."
+          schema:
+            $ref: "#/definitions/ContainerUpdateResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "update"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/Resources"
+              - type: "object"
+                properties:
+                  RestartPolicy:
+                    $ref: "#/definitions/RestartPolicy"
+            example:
+              BlkioWeight: 300
+              CpuShares: 512
+              CpuPeriod: 100000
+              CpuQuota: 50000
+              CpuRealtimePeriod: 1000000
+              CpuRealtimeRuntime: 10000
+              CpusetCpus: "0,1"
+              CpusetMems: "0"
+              Memory: 314572800
+              MemorySwap: 514288000
+              MemoryReservation: 209715200
+              RestartPolicy:
+                MaximumRetryCount: 4
+                Name: "on-failure"
+      tags: ["Container"]
+  /containers/{id}/rename:
+    post:
+      summary: "Rename a container"
+      operationId: "ContainerRename"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "name already in use"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "name"
+          in: "query"
+          required: true
+          description: "New name for the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/pause:
+    post:
+      summary: "Pause a container"
+      description: |
+        Use the freezer cgroup to suspend all processes in a container.
+
+        Traditionally, when suspending a process the `SIGSTOP` signal is used,
+        which is observable by the process being suspended. With the freezer
+        cgroup the process is unaware, and unable to capture, that it is being
+        suspended, and subsequently resumed.
+      operationId: "ContainerPause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/unpause:
+    post:
+      summary: "Unpause a container"
+      description: "Resume a container which has been paused."
+      operationId: "ContainerUnpause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/attach:
+    post:
+      summary: "Attach to a container"
+      description: |
+        Attach to a container to read its output or send it input. You can attach
+        to the same container multiple times and you can reattach to containers
+        that have been detached.
+
+        Either the `stream` or `logs` parameter must be `true` for this endpoint
+        to do anything.
+
+        See the [documentation for the `docker attach` command](https://docs.docker.com/engine/reference/commandline/attach/)
+        for more details.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to transport `stdin`, `stdout`,
+        and `stderr` on the same socket.
+
+        This is the response from the daemon for an attach request:
+
+        ```
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        [STREAM]
+        ```
+
+        After the headers and two new lines, the TCP connection can now be used
+        for raw, bidirectional communication between the client and server.
+
+        To hint potential proxies about connection hijacking, the Docker client
+        can also optionally send connection upgrade headers.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /containers/16253994b7c4/attach?stream=1&stdout=1 HTTP/1.1
+        Upgrade: tcp
+        Connection: Upgrade
+        ```
+
+        The Docker daemon will respond with a `101 UPGRADED` response, and will
+        similarly follow with the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Content-Type: application/vnd.docker.raw-stream
+        Connection: Upgrade
+        Upgrade: tcp
+
+        [STREAM]
+        ```
+
+        ### Stream format
+
+        When the TTY setting is disabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the HTTP Content-Type header is set to application/vnd.docker.multiplexed-stream
+        and the stream over the hijacked connected is multiplexed to separate out
+        `stdout` and `stderr`. The stream consists of a series of frames, each
+        containing a header and a payload.
+
+        The header contains the information which the stream writes (`stdout` or
+        `stderr`). It also contains the size of the associated frame encoded in
+        the last four bytes (`uint32`).
+
+        It is encoded on the first eight bytes like this:
+
+        ```go
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+        ```
+
+        `STREAM_TYPE` can be:
+
+        - 0: `stdin` (is written on `stdout`)
+        - 1: `stdout`
+        - 2: `stderr`
+
+        `SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of the `uint32` size
+        encoded as big endian.
+
+        Following the header is the payload, which is the specified number of
+        bytes of `STREAM_TYPE`.
+
+        The simplest way to implement this protocol is the following:
+
+        1. Read 8 bytes.
+        2. Choose `stdout` or `stderr` depending on the first byte.
+        3. Extract the frame size from the last four bytes.
+        4. Read the extracted size and output it on the correct output.
+        5. Goto 1.
+
+        ### Stream format when using a TTY
+
+        When the TTY setting is enabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the stream is not multiplexed. The data exchanged over the hijacked
+        connection is simply the raw data from the process PTY and client's
+        `stdin`.
+
+      operationId: "ContainerAttach"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: |
+            Replay previous logs from the container.
+
+            This is useful for attaching to a container that has started and you
+            want to output everything since the container started.
+
+            If `stream` is also enabled, once all the previous output has been
+            returned, it will seamlessly transition into streaming current
+            output.
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream attached streams from the time the request was made onwards.
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/attach/ws:
+    get:
+      summary: "Attach to a container via a websocket"
+      operationId: "ContainerAttachWebsocket"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,`, or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: "Return logs"
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: "Return stream"
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/wait:
+    post:
+      summary: "Wait for a container"
+      description: "Block until a container stops, then returns the exit code."
+      operationId: "ContainerWait"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has exit."
+          schema:
+            $ref: "#/definitions/ContainerWaitResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "condition"
+          in: "query"
+          description: |
+            Wait until a container state reaches the given condition.
+
+            Defaults to `not-running` if omitted or empty.
+          type: "string"
+          enum:
+            - "not-running"
+            - "next-exit"
+            - "removed"
+          default: "not-running"
+      tags: ["Container"]
+  /containers/{id}:
+    delete:
+      summary: "Remove a container"
+      operationId: "ContainerDelete"
+      responses:
+        204:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: |
+                You cannot remove a running container: c2ada9df5af8. Stop the
+                container before attempting removal or force remove
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "v"
+          in: "query"
+          description: "Remove anonymous volumes associated with the container."
+          type: "boolean"
+          default: false
+        - name: "force"
+          in: "query"
+          description: "If the container is running, kill it before removing it."
+          type: "boolean"
+          default: false
+        - name: "link"
+          in: "query"
+          description: "Remove the specified link associated with the container."
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/archive:
+    head:
+      summary: "Get information about files in a container"
+      description: |
+        A response header `X-Docker-Container-Path-Stat` is returned, containing
+        a base64 - encoded JSON object with some filesystem header information
+        about the path.
+      operationId: "ContainerArchiveInfo"
+      responses:
+        200:
+          description: "no error"
+          headers:
+            X-Docker-Container-Path-Stat:
+              type: "string"
+              description: |
+                A base64 - encoded JSON object with some filesystem header
+                information about the path
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    get:
+      summary: "Get an archive of a filesystem resource in a container"
+      description: "Get a tar archive of a resource in the filesystem of container id."
+      operationId: "ContainerArchive"
+      produces: ["application/x-tar"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    put:
+      summary: "Extract an archive of files or folders to a directory in a container"
+      description: |
+        Upload a tar archive to be extracted to a path in the filesystem of container id.
+        `path` parameter is asserted to be a directory. If it exists as a file, 400 error
+        will be returned with message "not a directory".
+      operationId: "PutContainerArchive"
+      consumes: ["application/x-tar", "application/octet-stream"]
+      responses:
+        200:
+          description: "The content was extracted successfully"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "not a directory"
+        403:
+          description: "Permission denied, the volume or container rootfs is marked as read-only."
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such container or path does not exist inside the container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Path to a directory in the container to extract the archive’s contents into. "
+          type: "string"
+        - name: "noOverwriteDirNonDir"
+          in: "query"
+          description: |
+            If `1`, `true`, or `True` then it will be an error if unpacking the
+            given content would cause an existing directory to be replaced with
+            a non-directory and vice versa.
+          type: "string"
+        - name: "copyUIDGID"
+          in: "query"
+          description: |
+            If `1`, `true`, then it will copy UID/GID maps to the dest file or
+            dir
+          type: "string"
+        - name: "inputStream"
+          in: "body"
+          required: true
+          description: |
+            The input stream must be a tar archive compressed with one of the
+            following algorithms: `identity` (no compression), `gzip`, `bzip2`,
+            or `xz`.
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Container"]
+  /containers/prune:
+    post:
+      summary: "Delete stopped containers"
+      produces:
+        - "application/json"
+      operationId: "ContainerPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune containers created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune containers with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ContainerPruneResponse"
+            properties:
+              ContainersDeleted:
+                description: "Container IDs that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /images/json:
+    get:
+      summary: "List Images"
+      description: "Returns a list of images on the server. Note that it uses a different, smaller representation of an image than inspecting a single image."
+      operationId: "ImageList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "Summary image data for the images matching the query"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageSummary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: "Show all images. Only images from a final layer (no children) are shown by default."
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the images list.
+
+            Available filters:
+
+            - `before`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `dangling=true`
+            - `label=key` or `label="key=value"` of an image label
+            - `reference`=(`<image-name>[:<tag>]`)
+            - `since`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `until=<timestamp>`
+          type: "string"
+        - name: "shared-size"
+          in: "query"
+          description: "Compute and show shared size as a `SharedSize` field on each image."
+          type: "boolean"
+          default: false
+        - name: "digests"
+          in: "query"
+          description: "Show digest information as a `RepoDigests` field on each image."
+          type: "boolean"
+          default: false
+        - name: "manifests"
+          in: "query"
+          description: "Include `Manifests` in the image summary."
+          type: "boolean"
+          default: false
+      tags: ["Image"]
+  /build:
+    post:
+      summary: "Build an image"
+      description: |
+        Build an image from a tar archive with a `Dockerfile` in it.
+
+        The `Dockerfile` specifies how the image is built from the tar archive. It is typically in the archive's root, but can be at a different path or have a different name by specifying the `dockerfile` parameter. [See the `Dockerfile` reference for more information](https://docs.docker.com/engine/reference/builder/).
+
+        The Docker daemon performs a preliminary validation of the `Dockerfile` before starting the build, and returns an error if the syntax is incorrect. After that, each instruction is run one-by-one until the ID of the new image is output.
+
+        The build is canceled if the client drops the connection by quitting or being killed.
+      operationId: "ImageBuild"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "inputStream"
+          in: "body"
+          description: "A tar archive compressed with one of the following algorithms: identity (no compression), gzip, bzip2, xz."
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "dockerfile"
+          in: "query"
+          description: "Path within the build context to the `Dockerfile`. This is ignored if `remote` is specified and points to an external `Dockerfile`."
+          type: "string"
+          default: "Dockerfile"
+        - name: "t"
+          in: "query"
+          description: "A name and optional tag to apply to the image in the `name:tag` format. If you omit the tag the default `latest` value is assumed. You can provide several `t` parameters."
+          type: "string"
+        - name: "extrahosts"
+          in: "query"
+          description: "Extra hosts to add to /etc/hosts"
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: "A Git repository URI or HTTP/HTTPS context URI. If the URI points to a single text file, the file’s contents are placed into a file called `Dockerfile` and the image is built from that file. If the URI points to a tarball, the file is downloaded by the daemon and the contents therein used as the context for the build. If the URI points to a tarball and the `dockerfile` parameter is also specified, there must be a file with the corresponding path inside the tarball."
+          type: "string"
+        - name: "q"
+          in: "query"
+          description: "Suppress verbose build output."
+          type: "boolean"
+          default: false
+        - name: "nocache"
+          in: "query"
+          description: "Do not use the cache when building the image."
+          type: "boolean"
+          default: false
+        - name: "cachefrom"
+          in: "query"
+          description: "JSON array of images used for build cache resolution."
+          type: "string"
+        - name: "pull"
+          in: "query"
+          description: "Attempt to pull the image even if an older image exists locally."
+          type: "string"
+        - name: "rm"
+          in: "query"
+          description: "Remove intermediate containers after a successful build."
+          type: "boolean"
+          default: true
+        - name: "forcerm"
+          in: "query"
+          description: "Always remove intermediate containers, even upon failure."
+          type: "boolean"
+          default: false
+        - name: "memory"
+          in: "query"
+          description: "Set memory limit for build."
+          type: "integer"
+        - name: "memswap"
+          in: "query"
+          description: "Total memory (memory + swap). Set as `-1` to disable swap."
+          type: "integer"
+        - name: "cpushares"
+          in: "query"
+          description: "CPU shares (relative weight)."
+          type: "integer"
+        - name: "cpusetcpus"
+          in: "query"
+          description: "CPUs in which to allow execution (e.g., `0-3`, `0,1`)."
+          type: "string"
+        - name: "cpuperiod"
+          in: "query"
+          description: "The length of a CPU period in microseconds."
+          type: "integer"
+        - name: "cpuquota"
+          in: "query"
+          description: "Microseconds of CPU time that the container can get in a CPU period."
+          type: "integer"
+        - name: "buildargs"
+          in: "query"
+          description: >
+            JSON map of string pairs for build-time variables. Users pass these values at build-time. Docker
+            uses the buildargs as the environment context for commands run via the `Dockerfile` RUN
+            instruction, or for variable expansion in other `Dockerfile` instructions. This is not meant for
+            passing secret values.
+
+
+            For example, the build arg `FOO=bar` would become `{"FOO":"bar"}` in JSON. This would result in the
+            query parameter `buildargs={"FOO":"bar"}`. Note that `{"FOO":"bar"}` should be URI component encoded.
+
+
+            [Read more about the buildargs instruction.](https://docs.docker.com/engine/reference/builder/#arg)
+          type: "string"
+        - name: "shmsize"
+          in: "query"
+          description: "Size of `/dev/shm` in bytes. The size must be greater than 0. If omitted the system uses 64MB."
+          type: "integer"
+        - name: "squash"
+          in: "query"
+          description: "Squash the resulting images layers into a single layer. *(Experimental release only.)*"
+          type: "boolean"
+        - name: "labels"
+          in: "query"
+          description: "Arbitrary key/value labels to set on the image, as a JSON map of string pairs."
+          type: "string"
+        - name: "networkmode"
+          in: "query"
+          description: |
+            Sets the networking mode for the run commands during build. Supported
+            standard values are: `bridge`, `host`, `none`, and `container:<name|id>`.
+            Any other value is taken as a custom network's name or ID to which this
+            container should connect to.
+          type: "string"
+        - name: "Content-type"
+          in: "header"
+          type: "string"
+          enum:
+            - "application/x-tar"
+          default: "application/x-tar"
+        - name: "X-Registry-Config"
+          in: "header"
+          description: |
+            This is a base64-encoded JSON object with auth configurations for multiple registries that a build may refer to.
+
+            The key is a registry URL, and the value is an auth configuration object, [as described in the authentication section](#section/Authentication). For example:
+
+            ```
+            {
+              "docker.example.com": {
+                "username": "janedoe",
+                "password": "hunter2"
+              },
+              "https://index.docker.io/v1/": {
+                "username": "mobydock",
+                "password": "conta1n3rize14"
+              }
+            }
+            ```
+
+            Only the registry domain name (and port if not the default 443) are required. However, for legacy reasons, the Docker Hub registry must be specified with both a `https://` prefix and a `/v1/` suffix even though Docker will prefer to use the v2 registry API.
+          type: "string"
+        - name: "platform"
+          in: "query"
+          description: "Platform in the format os[/arch[/variant]]"
+          type: "string"
+          default: ""
+        - name: "target"
+          in: "query"
+          description: "Target build stage"
+          type: "string"
+          default: ""
+        - name: "outputs"
+          in: "query"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
+          type: "string"
+          default: ""
+        - name: "version"
+          in: "query"
+          type: "string"
+          default: "1"
+          enum: ["1", "2"]
+          description: |
+            Version of the builder backend to use.
+
+            - `1` is the first generation classic (deprecated) builder in the Docker daemon (default)
+            - `2` is [BuildKit](https://github.com/moby/buildkit)
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /build/prune:
+    post:
+      summary: "Delete builder cache"
+      produces:
+        - "application/json"
+      operationId: "BuildPrune"
+      parameters:
+        - name: "keep-storage"
+          in: "query"
+          description: |
+            Amount of disk space in bytes to keep for cache
+
+            > **Deprecated**: This parameter is deprecated and has been renamed to "reserved-space".
+            > It is kept for backward compatibility and will be removed in API v1.52.
+          type: "integer"
+          format: "int64"
+        - name: "reserved-space"
+          in: "query"
+          description: "Amount of disk space in bytes to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "max-used-space"
+          in: "query"
+          description: "Maximum amount of disk space allowed to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "min-free-space"
+          in: "query"
+          description: "Target amount of free disk space after pruning"
+          type: "integer"
+          format: "int64"
+        - name: "all"
+          in: "query"
+          type: "boolean"
+          description: "Remove all types of build cache"
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the list of build cache objects.
+
+            Available filters:
+
+            - `until=<timestamp>` remove cache older than `<timestamp>`. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon's local time.
+            - `id=<id>`
+            - `parent=<id>`
+            - `type=<string>`
+            - `description=<string>`
+            - `inuse`
+            - `shared`
+            - `private`
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "BuildPruneResponse"
+            properties:
+              CachesDeleted:
+                type: "array"
+                items:
+                  description: "ID of build cache object"
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /images/create:
+    post:
+      summary: "Create an image"
+      description: "Pull or import an image."
+      operationId: "ImageCreate"
+      consumes:
+        - "text/plain"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "repository does not exist or no read access"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "fromImage"
+          in: "query"
+          description: |
+            Name of the image to pull. If the name includes a tag or digest, specific behavior applies:
+
+            - If only `fromImage` includes a tag, that tag is used.
+            - If both `fromImage` and `tag` are provided, `tag` takes precedence.
+            - If `fromImage` includes a digest, the image is pulled by digest, and `tag` is ignored.
+            - If neither a tag nor digest is specified, all tags are pulled.
+          type: "string"
+        - name: "fromSrc"
+          in: "query"
+          description: "Source to import. The value may be a URL from which the image can be retrieved or `-` to read the image from the request body. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name given to an image when it is imported. The repo may include a tag. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag or digest. If empty when pulling an image, this causes all tags for the given image to be pulled."
+          type: "string"
+        - name: "message"
+          in: "query"
+          description: "Set commit message for imported image."
+          type: "string"
+        - name: "inputImage"
+          in: "body"
+          description: "Image content if the value `-` has been specified in fromSrc query parameter"
+          schema:
+            type: "string"
+          required: false
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "changes"
+          in: "query"
+          description: |
+            Apply `Dockerfile` instructions to the image that is created,
+            for example: `changes=ENV DEBUG=true`.
+            Note that `ENV DEBUG=true` should be URI component encoded.
+
+            Supported `Dockerfile` instructions:
+            `CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format os[/arch[/variant]].
+
+            When used in combination with the `fromImage` option, the daemon checks
+            if the given image is present in the local image cache with the given
+            OS and Architecture, and otherwise attempts to pull the image. If the
+            option is not set, the host's native OS and Architecture are used.
+            If the given image does not exist in the local image cache, the daemon
+            attempts to pull the image with the host's native OS and Architecture.
+            If the given image does exists in the local image cache, but its OS or
+            architecture does not match, a warning is produced.
+
+            When used with the `fromSrc` option to import an image from an archive,
+            this option sets the platform information for the imported image. If
+            the option is not set, the host's native OS and Architecture are used
+            for the imported image.
+          type: "string"
+          default: ""
+      tags: ["Image"]
+  /images/{name}/json:
+    get:
+      summary: "Inspect an image"
+      description: "Return low-level information about an image."
+      operationId: "ImageInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/ImageInspect"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+        - name: "manifests"
+          in: "query"
+          description: |-
+            Include Manifests in the image summary.
+
+            The `manifests` and `platform` options are mutually exclusive, and
+            an error is produced if both are set.
+          type: "boolean"
+          default: false
+          required: false
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |-
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show inspect. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            The `platform` and `manifests` options are mutually exclusive, and
+            an error is produced if both are set.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/history:
+    get:
+      summary: "Get the history of an image"
+      description: "Return parent layers of an image."
+      operationId: "ImageHistory"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "List of image layers"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageHistoryResponseItem"
+          examples:
+            application/json:
+              - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
+                Created: 1398108230
+                CreatedBy: "/bin/sh -c #(nop) ADD file:eb15dbd63394e063b805a3c32ca7bf0266ef64676d5a6fab4801f2e81e2a5148 in /"
+                Tags:
+                  - "ubuntu:lucid"
+                  - "ubuntu:10.04"
+                Size: 182964289
+                Comment: ""
+              - Id: "6cfa4d1f33fb861d4d114f43b25abd0ac737509268065cdfd69d544a59c85ab8"
+                Created: 1398108222
+                CreatedBy: "/bin/sh -c #(nop) MAINTAINER Tianon Gravi <admwiggin@gmail.com> - mkimage-debootstrap.sh -i iproute,iputils-ping,ubuntu-minimal -t lucid.tar.xz lucid http://archive.ubuntu.com/ubuntu/"
+                Tags: []
+                Size: 0
+                Comment: ""
+              - Id: "511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158"
+                Created: 1371157430
+                CreatedBy: ""
+                Tags:
+                  - "scratch12:latest"
+                  - "scratch:latest"
+                Size: 0
+                Comment: "Imported from -"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show the history for. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/push:
+    post:
+      summary: "Push an image"
+      description: |
+        Push an image to a registry.
+
+        If you wish to push an image on to a private registry, that image must
+        already have a tag which references the registry. For example,
+        `registry.example.com/myimage:latest`.
+
+        The push is cancelled if the HTTP connection is closed.
+      operationId: "ImagePush"
+      consumes:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            Name of the image to push. For example, `registry.example.com/myimage`.
+            The image must be present in the local image store with the same name.
+
+            The name should be provided without tag; if a tag is provided, it
+            is ignored. For example, `registry.example.com/myimage:latest` is
+            considered equivalent to `registry.example.com/myimage`.
+
+            Use the `tag` parameter to specify the tag to push.
+          type: "string"
+          required: true
+        - name: "tag"
+          in: "query"
+          description: |
+            Tag of the image to push. For example, `latest`. If no tag is provided,
+            all tags of the given image that are present in the local image store
+            are pushed.
+          type: "string"
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant to push.
+            If not provided, all available variants will attempt to be pushed.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to push to the registry. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+          required: true
+      tags: ["Image"]
+  /images/{name}/tag:
+    post:
+      summary: "Tag an image"
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
+      operationId: "ImageTag"
+      responses:
+        201:
+          description: "No error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID to tag."
+          type: "string"
+          required: true
+        - name: "repo"
+          in: "query"
+          description: "The repository to tag in. For example, `someuser/someimage`."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "The name of the new tag."
+          type: "string"
+      tags: ["Image"]
+  /images/{name}:
+    delete:
+      summary: "Remove an image"
+      description: |
+        Remove an image, along with any untagged parent images that were
+        referenced by that image.
+
+        Images can't be removed if they have descendant images, are being
+        used by a running container or are being used by a build.
+      operationId: "ImageDelete"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The image was deleted successfully"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageDeleteResponseItem"
+          examples:
+            application/json:
+              - Untagged: "3e2f21a89f"
+              - Deleted: "3e2f21a89f"
+              - Deleted: "53b4f83ac9"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Remove the image even if it is being used by stopped containers or has other tags"
+          type: "boolean"
+          default: false
+        - name: "noprune"
+          in: "query"
+          description: "Do not delete untagged parent images"
+          type: "boolean"
+          default: false
+        - name: "platforms"
+          in: "query"
+          description: |
+            Select platform-specific content to delete.
+            Multiple values are accepted.
+            Each platform is a OCI platform encoded as a JSON string.
+          type: "array"
+          items:
+            # This should be OCIPlatform
+            # but $ref is not supported for array in query in Swagger 2.0
+            # $ref: "#/definitions/OCIPlatform"
+            type: "string"
+      tags: ["Image"]
+  /images/search:
+    get:
+      summary: "Search images"
+      description: "Search for an image on Docker Hub."
+      operationId: "ImageSearch"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              type: "object"
+              title: "ImageSearchResponseItem"
+              properties:
+                description:
+                  type: "string"
+                is_official:
+                  type: "boolean"
+                is_automated:
+                  description: |
+                    Whether this repository has automated builds enabled.
+
+                    <p><br /></p>
+
+                    > **Deprecated**: This field is deprecated and will always be "false".
+                  type: "boolean"
+                  example: false
+                name:
+                  type: "string"
+                star_count:
+                  type: "integer"
+          examples:
+            application/json:
+              - description: "A minimal Docker image based on Alpine Linux with a complete package index and only 5 MB in size!"
+                is_official: true
+                is_automated: false
+                name: "alpine"
+                star_count: 10093
+              - description: "Busybox base image."
+                is_official: true
+                is_automated: false
+                name: "Busybox base image."
+                star_count: 3037
+              - description: "The PostgreSQL object-relational database system provides reliability and data integrity."
+                is_official: true
+                is_automated: false
+                name: "postgres"
+                star_count: 12408
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "term"
+          in: "query"
+          description: "Term to search"
+          type: "string"
+          required: true
+        - name: "limit"
+          in: "query"
+          description: "Maximum number of results to return"
+          type: "integer"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to process on the images list. Available filters:
+
+            - `is-official=(true|false)`
+            - `stars=<number>` Matches images that has at least 'number' stars.
+          type: "string"
+      tags: ["Image"]
+  /images/prune:
+    post:
+      summary: "Delete unused images"
+      produces:
+        - "application/json"
+      operationId: "ImagePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`). Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), prune only
+               unused *and* untagged images. When set to `false`
+               (or `0`), all unused images are pruned.
+            - `until=<string>` Prune images created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune images with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ImagePruneResponse"
+            properties:
+              ImagesDeleted:
+                description: "Images that were deleted"
+                type: "array"
+                items:
+                  $ref: "#/definitions/ImageDeleteResponseItem"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /auth:
+    post:
+      summary: "Check auth configuration"
+      description: |
+        Validate credentials for a registry and, if available, get an identity
+        token for accessing the registry without password.
+      operationId: "SystemAuth"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "An identity token was generated successfully."
+          schema:
+            type: "object"
+            title: "SystemAuthResponse"
+            required: [Status]
+            properties:
+              Status:
+                description: "The status of the authentication"
+                type: "string"
+                x-nullable: false
+              IdentityToken:
+                description: "An opaque token used to authenticate a user after a successful login"
+                type: "string"
+                x-nullable: false
+          examples:
+            application/json:
+              Status: "Login Succeeded"
+              IdentityToken: "9cbaf023786cd7..."
+        204:
+          description: "No error"
+        401:
+          description: "Auth error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "authConfig"
+          in: "body"
+          description: "Authentication to check"
+          schema:
+            $ref: "#/definitions/AuthConfig"
+      tags: ["System"]
+  /info:
+    get:
+      summary: "Get system information"
+      operationId: "SystemInfo"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/SystemInfo"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /version:
+    get:
+      summary: "Get version"
+      description: "Returns the version of Docker that is running and various information about the system that Docker is running on."
+      operationId: "SystemVersion"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/SystemVersion"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /_ping:
+    get:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPing"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "OK"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: |
+                Default version of docker image builder
+
+                The default on Linux is version "2" (BuildKit), but the daemon
+                can be configured to recommend version "1" (classic Builder).
+                Windows does not yet support BuildKit for native Windows images,
+                and uses "1" (classic builder) as a default.
+
+                This value is a recommendation as advertised by the daemon, and
+                it is up to the client to choose which builder to use.
+              default: "2"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          headers:
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+      tags: ["System"]
+    head:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPingHead"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "(empty)"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: "Default version of docker image builder"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /commit:
+    post:
+      summary: "Create a new image from a container"
+      operationId: "ImageCommit"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "containerConfig"
+          in: "body"
+          description: "The container configuration"
+          schema:
+            $ref: "#/definitions/ContainerConfig"
+        - name: "container"
+          in: "query"
+          description: "The ID or name of the container to commit"
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name for the created image"
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag name for the create image"
+          type: "string"
+        - name: "comment"
+          in: "query"
+          description: "Commit message"
+          type: "string"
+        - name: "author"
+          in: "query"
+          description: "Author of the image (e.g., `John Hannibal Smith <hannibal@a-team.com>`)"
+          type: "string"
+        - name: "pause"
+          in: "query"
+          description: "Whether to pause the container before committing"
+          type: "boolean"
+          default: true
+        - name: "changes"
+          in: "query"
+          description: "`Dockerfile` instructions to apply while committing"
+          type: "string"
+      tags: ["Image"]
+  /events:
+    get:
+      summary: "Monitor events"
+      description: |
+        Stream real-time events from the server.
+
+        Various objects within Docker report events when something happens to them.
+
+        Containers report these events: `attach`, `commit`, `copy`, `create`, `destroy`, `detach`, `die`, `exec_create`, `exec_detach`, `exec_start`, `exec_die`, `export`, `health_status`, `kill`, `oom`, `pause`, `rename`, `resize`, `restart`, `start`, `stop`, `top`, `unpause`, `update`, and `prune`
+
+        Images report these events: `create`, `delete`, `import`, `load`, `pull`, `push`, `save`, `tag`, `untag`, and `prune`
+
+        Volumes report these events: `create`, `mount`, `unmount`, `destroy`, and `prune`
+
+        Networks report these events: `create`, `connect`, `disconnect`, `destroy`, `update`, `remove`, and `prune`
+
+        The Docker daemon reports these events: `reload`
+
+        Services report these events: `create`, `update`, and `remove`
+
+        Nodes report these events: `create`, `update`, and `remove`
+
+        Secrets report these events: `create`, `update`, and `remove`
+
+        Configs report these events: `create`, `update`, and `remove`
+
+        The Builder reports `prune` events
+
+      operationId: "SystemEvents"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/EventMessage"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "since"
+          in: "query"
+          description: "Show events created since this timestamp then stream new events."
+          type: "string"
+        - name: "until"
+          in: "query"
+          description: "Show events created until this timestamp then stop streaming."
+          type: "string"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of filters (a `map[string][]string`) to process on the event list. Available filters:
+
+            - `config=<string>` config name or ID
+            - `container=<string>` container name or ID
+            - `daemon=<string>` daemon name or ID
+            - `event=<string>` event type
+            - `image=<string>` image name or ID
+            - `label=<string>` image or container label
+            - `network=<string>` network name or ID
+            - `node=<string>` node ID
+            - `plugin`=<string> plugin name or ID
+            - `scope`=<string> local or swarm
+            - `secret=<string>` secret name or ID
+            - `service=<string>` service name or ID
+            - `type=<string>` object to filter by, one of `container`, `image`, `volume`, `network`, `daemon`, `plugin`, `node`, `service`, `secret` or `config`
+            - `volume=<string>` volume name
+          type: "string"
+      tags: ["System"]
+  /system/df:
+    get:
+      summary: "Get data usage information"
+      operationId: "SystemDataUsage"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "SystemDataUsageResponse"
+            properties:
+              LayersSize:
+                type: "integer"
+                format: "int64"
+              Images:
+                type: "array"
+                items:
+                  $ref: "#/definitions/ImageSummary"
+              Containers:
+                type: "array"
+                items:
+                  $ref: "#/definitions/ContainerSummary"
+              Volumes:
+                type: "array"
+                items:
+                  $ref: "#/definitions/Volume"
+              BuildCache:
+                type: "array"
+                items:
+                  $ref: "#/definitions/BuildCache"
+            example:
+              LayersSize: 1092588
+              Images:
+                -
+                  Id: "sha256:2b8fd9751c4c0f5dd266fcae00707e67a2545ef34f9a29354585f93dac906749"
+                  ParentId: ""
+                  RepoTags:
+                    - "busybox:latest"
+                  RepoDigests:
+                    - "busybox@sha256:a59906e33509d14c036c8678d687bd4eec81ed7c4b8ce907b888c607f6a1e0e6"
+                  Created: 1466724217
+                  Size: 1092588
+                  SharedSize: 0
+                  Labels: {}
+                  Containers: 1
+              Containers:
+                -
+                  Id: "e575172ed11dc01bfce087fb27bee502db149e1a0fad7c296ad300bbff178148"
+                  Names:
+                    - "/top"
+                  Image: "busybox"
+                  ImageID: "sha256:2b8fd9751c4c0f5dd266fcae00707e67a2545ef34f9a29354585f93dac906749"
+                  Command: "top"
+                  Created: 1472592424
+                  Ports: []
+                  SizeRootFs: 1092588
+                  Labels: {}
+                  State: "exited"
+                  Status: "Exited (0) 56 minutes ago"
+                  HostConfig:
+                    NetworkMode: "default"
+                  NetworkSettings:
+                    Networks:
+                      bridge:
+                        IPAMConfig: null
+                        Links: null
+                        Aliases: null
+                        NetworkID: "d687bc59335f0e5c9ee8193e5612e8aee000c8c62ea170cfb99c098f95899d92"
+                        EndpointID: "8ed5115aeaad9abb174f68dcf135b49f11daf597678315231a32ca28441dec6a"
+                        Gateway: "172.18.0.1"
+                        IPAddress: "172.18.0.2"
+                        IPPrefixLen: 16
+                        IPv6Gateway: ""
+                        GlobalIPv6Address: ""
+                        GlobalIPv6PrefixLen: 0
+                        MacAddress: "02:42:ac:12:00:02"
+                  Mounts: []
+              Volumes:
+                -
+                  Name: "my-volume"
+                  Driver: "local"
+                  Mountpoint: "/var/lib/docker/volumes/my-volume/_data"
+                  Labels: null
+                  Scope: "local"
+                  Options: null
+                  UsageData:
+                    Size: 10920104
+                    RefCount: 2
+              BuildCache:
+                -
+                  ID: "hw53o5aio51xtltp5xjp8v7fx"
+                  Parents: []
+                  Type: "regular"
+                  Description: "pulled from docker.io/library/debian@sha256:234cb88d3020898631af0ccbbcca9a66ae7306ecd30c9720690858c1b007d2a0"
+                  InUse: false
+                  Shared: true
+                  Size: 0
+                  CreatedAt: "2021-06-28T13:31:01.474619385Z"
+                  LastUsedAt: "2021-07-07T22:02:32.738075951Z"
+                  UsageCount: 26
+                -
+                  ID: "ndlpt0hhvkqcdfkputsk4cq9c"
+                  Parents: ["ndlpt0hhvkqcdfkputsk4cq9c"]
+                  Type: "regular"
+                  Description: "mount / from exec /bin/sh -c echo 'Binary::apt::APT::Keep-Downloaded-Packages \"true\";' > /etc/apt/apt.conf.d/keep-cache"
+                  InUse: false
+                  Shared: true
+                  Size: 51
+                  CreatedAt: "2021-06-28T13:31:03.002625487Z"
+                  LastUsedAt: "2021-07-07T22:02:32.773909517Z"
+                  UsageCount: 26
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "type"
+          in: "query"
+          description: |
+            Object types, for which to compute and return data.
+          type: "array"
+          collectionFormat: multi
+          items:
+            type: "string"
+            enum: ["container", "image", "volume", "build-cache"]
+      tags: ["System"]
+  /images/{name}/get:
+    get:
+      summary: "Export an image"
+      description: |
+        Get a tarball containing all images and metadata for a repository.
+
+        If `name` is a specific name and tag (e.g. `ubuntu:latest`), then only that image (and its parents) are returned. If `name` is an image ID, similarly only that image (and its parents) are returned, but with the exclusion of the `repositories` file in the tarball, as there were no image names referenced.
+
+        ### Image tarball format
+
+        An image tarball contains [Content as defined in the OCI Image Layout Specification](https://github.com/opencontainers/image-spec/blob/v1.1.1/image-layout.md#content).
+
+        Additionally, includes the manifest.json file associated with a backwards compatible docker save format.
+
+        If the tarball defines a repository, the tarball should also include a `repositories` file at the root that contains a list of repository and tag names mapped to layer IDs.
+
+        ```json
+        {
+          "hello-world": {
+            "latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"
+          }
+        }
+        ```
+      operationId: "ImageGet"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON encoded OCI platform describing a platform which will be used
+            to select a platform-specific image to be saved if the image is
+            multi-platform.
+            If not provided, the full multi-platform image will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/get:
+    get:
+      summary: "Export several images"
+      description: |
+        Get a tarball containing all images and metadata for several image
+        repositories.
+
+        For each value of the `names` parameter: if it is a specific name and
+        tag (e.g. `ubuntu:latest`), then only that image (and its parents) are
+        returned; if it is an image ID, similarly only that image (and its parents)
+        are returned and there would be no names referenced in the 'repositories'
+        file for this image ID.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageGetAll"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "names"
+          in: "query"
+          description: "Image names to filter by"
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON encoded OCI platform describing a platform which will be used
+            to select a platform-specific image to be saved if the image is
+            multi-platform.
+            If not provided, the full multi-platform image will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/load:
+    post:
+      summary: "Import images"
+      description: |
+        Load a set of images and tags into a repository.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageLoad"
+      consumes:
+        - "application/x-tar"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "imagesTarball"
+          in: "body"
+          description: "Tar archive containing images"
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "quiet"
+          in: "query"
+          description: "Suppress progress details during load."
+          type: "boolean"
+          default: false
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON encoded OCI platform describing a platform which will be used
+            to select a platform-specific image to be load if the image is
+            multi-platform.
+            If not provided, the full multi-platform image will be loaded.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /containers/{id}/exec:
+    post:
+      summary: "Create an exec instance"
+      description: "Run a command inside a running container."
+      operationId: "ContainerExec"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execConfig"
+          in: "body"
+          description: "Exec configuration"
+          schema:
+            type: "object"
+            title: "ExecConfig"
+            properties:
+              AttachStdin:
+                type: "boolean"
+                description: "Attach to `stdin` of the exec command."
+              AttachStdout:
+                type: "boolean"
+                description: "Attach to `stdout` of the exec command."
+              AttachStderr:
+                type: "boolean"
+                description: "Attach to `stderr` of the exec command."
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+              DetachKeys:
+                type: "string"
+                description: |
+                  Override the key sequence for detaching a container. Format is
+                  a single character `[a-Z]` or `ctrl-<value>` where `<value>`
+                  is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+              Env:
+                description: |
+                  A list of environment variables in the form `["VAR=value", ...]`.
+                type: "array"
+                items:
+                  type: "string"
+              Cmd:
+                type: "array"
+                description: "Command to run, as a string or array of strings."
+                items:
+                  type: "string"
+              Privileged:
+                type: "boolean"
+                description: "Runs the exec process with extended privileges."
+                default: false
+              User:
+                type: "string"
+                description: |
+                  The user, and optionally, group to run the exec process inside
+                  the container. Format is one of: `user`, `user:group`, `uid`,
+                  or `uid:gid`.
+              WorkingDir:
+                type: "string"
+                description: |
+                  The working directory for the exec process inside the container.
+            example:
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              DetachKeys: "ctrl-p,ctrl-q"
+              Tty: false
+              Cmd:
+                - "date"
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+          required: true
+        - name: "id"
+          in: "path"
+          description: "ID or name of container"
+          type: "string"
+          required: true
+      tags: ["Exec"]
+  /exec/{id}/start:
+    post:
+      summary: "Start an exec instance"
+      description: |
+        Starts a previously set up exec instance. If detach is true, this endpoint
+        returns immediately after starting the command. Otherwise, it sets up an
+        interactive session with the command.
+      operationId: "ExecStart"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Container is stopped or paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execStartConfig"
+          in: "body"
+          schema:
+            type: "object"
+            title: "ExecStartConfig"
+            properties:
+              Detach:
+                type: "boolean"
+                description: "Detach from the command."
+                example: false
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+                example: true
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+  /exec/{id}/resize:
+    post:
+      summary: "Resize an exec instance"
+      description: |
+        Resize the TTY session used by an exec instance. This endpoint only works
+        if `tty` was specified as part of creating and starting the exec instance.
+      operationId: "ExecResize"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Exec"]
+  /exec/{id}/json:
+    get:
+      summary: "Inspect an exec instance"
+      description: "Return low-level information about an exec instance."
+      operationId: "ExecInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ExecInspectResponse"
+            properties:
+              CanRemove:
+                type: "boolean"
+              DetachKeys:
+                type: "string"
+              ID:
+                type: "string"
+              Running:
+                type: "boolean"
+              ExitCode:
+                type: "integer"
+              ProcessConfig:
+                $ref: "#/definitions/ProcessConfig"
+              OpenStdin:
+                type: "boolean"
+              OpenStderr:
+                type: "boolean"
+              OpenStdout:
+                type: "boolean"
+              ContainerID:
+                type: "string"
+              Pid:
+                type: "integer"
+                description: "The system process ID for the exec process."
+          examples:
+            application/json:
+              CanRemove: false
+              ContainerID: "b53ee82b53a40c7dca428523e34f741f3abc51d9f297a14ff874bf761b995126"
+              DetachKeys: ""
+              ExitCode: 2
+              ID: "f33bbfb39f5b142420f4759b2348913bd4a8d1a6d7fd56499cb41a1bb91d7b3b"
+              OpenStderr: true
+              OpenStdin: true
+              OpenStdout: true
+              ProcessConfig:
+                arguments:
+                  - "-c"
+                  - "exit 2"
+                entrypoint: "sh"
+                privileged: false
+                tty: true
+                user: "1000"
+              Running: false
+              Pid: 42000
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+
+  /volumes:
+    get:
+      summary: "List volumes"
+      operationId: "VolumeList"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "Summary volume data that matches the query"
+          schema:
+            $ref: "#/definitions/VolumeListResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to
+            process on the volumes list. Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               volumes that are not in use by a container. When set to `false`
+               (or `0`), only volumes that are in use by one or more
+               containers are returned.
+            - `driver=<volume-driver-name>` Matches volumes based on their driver.
+            - `label=<key>` or `label=<key>:<value>` Matches volumes based on
+               the presence of a `label` alone or a `label` and a value.
+            - `name=<volume-name>` Matches all or part of a volume name.
+          type: "string"
+          format: "json"
+      tags: ["Volume"]
+
+  /volumes/create:
+    post:
+      summary: "Create a volume"
+      operationId: "VolumeCreate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        201:
+          description: "The volume was created successfully"
+          schema:
+            $ref: "#/definitions/Volume"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "volumeConfig"
+          in: "body"
+          required: true
+          description: "Volume configuration"
+          schema:
+            $ref: "#/definitions/VolumeCreateOptions"
+      tags: ["Volume"]
+
+  /volumes/{name}:
+    get:
+      summary: "Inspect a volume"
+      operationId: "VolumeInspect"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/Volume"
+        404:
+          description: "No such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+      tags: ["Volume"]
+
+    put:
+      summary: |
+        "Update a volume. Valid only for Swarm cluster volumes"
+      operationId: "VolumeUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "The name or ID of the volume"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            # though the schema for is an object that contains only a
+            # ClusterVolumeSpec, wrapping the ClusterVolumeSpec in this object
+            # means that if, later on, we support things like changing the
+            # labels, we can do so without duplicating that information to the
+            # ClusterVolumeSpec.
+            type: "object"
+            description: "Volume configuration"
+            properties:
+              Spec:
+                $ref: "#/definitions/ClusterVolumeSpec"
+          description: |
+            The spec of the volume to update. Currently, only Availability may
+            change. All other fields must remain unchanged.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the volume being updated. This is required to
+            avoid conflicting writes. Found in the volume's `ClusterVolume`
+            field.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Volume"]
+
+    delete:
+      summary: "Remove a volume"
+      description: "Instruct the driver to remove the volume."
+      operationId: "VolumeDelete"
+      responses:
+        204:
+          description: "The volume was removed"
+        404:
+          description: "No such volume or volume driver"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Volume is in use and cannot be removed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: "Force the removal of the volume"
+          type: "boolean"
+          default: false
+      tags: ["Volume"]
+
+  /volumes/prune:
+    post:
+      summary: "Delete unused volumes"
+      produces:
+        - "application/json"
+      operationId: "VolumePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune volumes with (or without, in case `label!=...` is used) the specified labels.
+            - `all` (`all=true`) - Consider all (local) volumes for pruning and not just anonymous volumes.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "VolumePruneResponse"
+            properties:
+              VolumesDeleted:
+                description: "Volumes that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Volume"]
+  /networks:
+    get:
+      summary: "List networks"
+      description: |
+        Returns a list of networks. For details on the format, see the
+        [network inspect endpoint](#operation/NetworkInspect).
+
+        Note that it uses a different, smaller representation of a network than
+        inspecting a single network. For example, the list of containers attached
+        to the network is not propagated in API versions 1.28 and up.
+      operationId: "NetworkList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Network"
+          examples:
+            application/json:
+              - Name: "bridge"
+                Id: "f2de39df4171b0dc801e8002d1d999b77256983dfc63041c0f34030aa3977566"
+                Created: "2016-10-19T06:21:00.416543526Z"
+                Scope: "local"
+                Driver: "bridge"
+                EnableIPv4: true
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config:
+                    -
+                      Subnet: "172.17.0.0/16"
+                Options:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              - Name: "none"
+                Id: "e086a3893b05ab69242d3c44e49483a3bbbd3a26b46baa8f61ab797c1088d794"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "null"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+              - Name: "host"
+                Id: "13e871235c677f196c4e1ecebb9dc733b9b2d2ab589e30c539efeda84a24215e"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "host"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to process
+            on the networks list.
+
+            Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               networks that are not in use by a container. When set to `false`
+               (or `0`), only networks that are in use by one or more
+               containers are returned.
+            - `driver=<driver-name>` Matches a network's driver.
+            - `id=<network-id>` Matches all or part of a network ID.
+            - `label=<key>` or `label=<key>=<value>` of a network label.
+            - `name=<network-name>` Matches all or part of a network name.
+            - `scope=["swarm"|"global"|"local"]` Filters networks by scope (`swarm`, `global`, or `local`).
+            - `type=["custom"|"builtin"]` Filters networks by type. The `custom` keyword returns all user-defined networks.
+          type: "string"
+      tags: ["Network"]
+
+  /networks/{id}:
+    get:
+      summary: "Inspect a network"
+      operationId: "NetworkInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/Network"
+        404:
+          description: "Network not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "verbose"
+          in: "query"
+          description: "Detailed inspect output for troubleshooting"
+          type: "boolean"
+          default: false
+        - name: "scope"
+          in: "query"
+          description: "Filter the network by scope (swarm, global, or local)"
+          type: "string"
+      tags: ["Network"]
+
+    delete:
+      summary: "Remove a network"
+      operationId: "NetworkDelete"
+      responses:
+        204:
+          description: "No error"
+        403:
+          description: "operation not supported for pre-defined networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such network"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+      tags: ["Network"]
+
+  /networks/create:
+    post:
+      summary: "Create a network"
+      operationId: "NetworkCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "Network created successfully"
+          schema:
+            $ref: "#/definitions/NetworkCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: |
+            Forbidden operation. This happens when trying to create a network named after a pre-defined network,
+            or when trying to create an overlay network on a daemon which is not part of a Swarm cluster.
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "plugin not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "networkConfig"
+          in: "body"
+          description: "Network configuration"
+          required: true
+          schema:
+            type: "object"
+            title: "NetworkCreateRequest"
+            required: ["Name"]
+            properties:
+              Name:
+                description: "The network's name."
+                type: "string"
+                example: "my_network"
+              Driver:
+                description: "Name of the network driver plugin to use."
+                type: "string"
+                default: "bridge"
+                example: "bridge"
+              Scope:
+                description: |
+                  The level at which the network exists (e.g. `swarm` for cluster-wide
+                  or `local` for machine level).
+                type: "string"
+              Internal:
+                description: "Restrict external access to the network."
+                type: "boolean"
+              Attachable:
+                description: |
+                  Globally scoped network is manually attachable by regular
+                  containers from workers in swarm mode.
+                type: "boolean"
+                example: true
+              Ingress:
+                description: |
+                  Ingress network is the network which provides the routing-mesh
+                  in swarm mode.
+                type: "boolean"
+                example: false
+              ConfigOnly:
+                description: |
+                  Creates a config-only network. Config-only networks are placeholder
+                  networks for network configurations to be used by other networks.
+                  Config-only networks cannot be used directly to run containers
+                  or services.
+                type: "boolean"
+                default: false
+                example: false
+              ConfigFrom:
+                description: |
+                  Specifies the source which will provide the configuration for
+                  this network. The specified network must be an existing
+                  config-only network; see ConfigOnly.
+                $ref: "#/definitions/ConfigReference"
+              IPAM:
+                description: "Optional custom IP scheme for the network."
+                $ref: "#/definitions/IPAM"
+              EnableIPv4:
+                description: "Enable IPv4 on the network."
+                type: "boolean"
+                example: true
+              EnableIPv6:
+                description: "Enable IPv6 on the network."
+                type: "boolean"
+                example: true
+              Options:
+                description: "Network specific options to be used by the drivers."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              Labels:
+                description: "User-defined key/value metadata."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.example.some-label: "some-value"
+                  com.example.some-other-label: "some-other-value"
+      tags: ["Network"]
+
+  /networks/{id}/connect:
+    post:
+      summary: "Connect a container to a network"
+      description: "The network must be either a local-scoped network or a swarm-scoped network with the `attachable` option set. A network cannot be re-attached to a running container"
+      operationId: "NetworkConnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "Operation forbidden"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "NetworkConnectRequest"
+            properties:
+              Container:
+                type: "string"
+                description: "The ID or name of the container to connect to the network."
+              EndpointConfig:
+                $ref: "#/definitions/EndpointSettings"
+            example:
+              Container: "3613f73ba0e4"
+              EndpointConfig:
+                IPAMConfig:
+                  IPv4Address: "172.24.56.89"
+                  IPv6Address: "2001:db8::5689"
+                MacAddress: "02:42:ac:12:05:02"
+                Priority: 100
+      tags: ["Network"]
+
+  /networks/{id}/disconnect:
+    post:
+      summary: "Disconnect a container from a network"
+      operationId: "NetworkDisconnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        403:
+          description: "Operation not supported for swarm scoped networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "NetworkDisconnectRequest"
+            properties:
+              Container:
+                type: "string"
+                description: |
+                  The ID or name of the container to disconnect from the network.
+              Force:
+                type: "boolean"
+                description: |
+                  Force the container to disconnect from the network.
+      tags: ["Network"]
+  /networks/prune:
+    post:
+      summary: "Delete unused networks"
+      produces:
+        - "application/json"
+      operationId: "NetworkPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune networks created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune networks with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "NetworkPruneResponse"
+            properties:
+              NetworksDeleted:
+                description: "Networks that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Network"]
+  /plugins:
+    get:
+      summary: "List plugins"
+      operationId: "PluginList"
+      description: "Returns information about installed plugins."
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Plugin"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the plugin list.
+
+            Available filters:
+
+            - `capability=<capability name>`
+            - `enable=<true>|<false>`
+      tags: ["Plugin"]
+
+  /plugins/privileges:
+    get:
+      summary: "Get plugin privileges"
+      operationId: "GetPluginPrivileges"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags:
+        - "Plugin"
+
+  /plugins/pull:
+    post:
+      summary: "Install a plugin"
+      operationId: "PluginPull"
+      description: |
+        Pulls and installs a plugin. After the plugin is installed, it can be
+        enabled using the [`POST /plugins/{name}/enable` endpoint](#operation/PostPluginsEnable).
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference for plugin to install.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "name"
+          in: "query"
+          description: |
+            Local name for the pulled plugin.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: false
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/{name}/json:
+    get:
+      summary: "Inspect a plugin"
+      operationId: "PluginInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags: ["Plugin"]
+  /plugins/{name}:
+    delete:
+      summary: "Remove a plugin"
+      operationId: "PluginDelete"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Disable the plugin before removing. This may result in issues if the
+            plugin is in use by a container.
+          type: "boolean"
+          default: false
+      tags: ["Plugin"]
+  /plugins/{name}/enable:
+    post:
+      summary: "Enable a plugin"
+      operationId: "PluginEnable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "timeout"
+          in: "query"
+          description: "Set the HTTP client timeout (in seconds)"
+          type: "integer"
+          default: 0
+      tags: ["Plugin"]
+  /plugins/{name}/disable:
+    post:
+      summary: "Disable a plugin"
+      operationId: "PluginDisable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Force disable a plugin even if still in use.
+          required: false
+          type: "boolean"
+      tags: ["Plugin"]
+  /plugins/{name}/upgrade:
+    post:
+      summary: "Upgrade a plugin"
+      operationId: "PluginUpgrade"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference to upgrade to.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/create:
+    post:
+      summary: "Create a plugin"
+      operationId: "PluginCreate"
+      consumes:
+        - "application/x-tar"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "tarContext"
+          in: "body"
+          description: "Path to tar containing plugin rootfs and manifest"
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Plugin"]
+  /plugins/{name}/push:
+    post:
+      summary: "Push a plugin"
+      operationId: "PluginPush"
+      description: |
+        Push a plugin to the registry.
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /plugins/{name}/set:
+    post:
+      summary: "Configure a plugin"
+      operationId: "PluginSet"
+      consumes:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              type: "string"
+            example: ["DEBUG=1"]
+      responses:
+        204:
+          description: "No error"
+        404:
+          description: "Plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /nodes:
+    get:
+      summary: "List nodes"
+      operationId: "NodeList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Node"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the nodes list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `id=<node id>`
+            - `label=<engine label>`
+            - `membership=`(`accepted`|`pending`)`
+            - `name=<node name>`
+            - `node.label=<node label>`
+            - `role=`(`manager`|`worker`)`
+          type: "string"
+      tags: ["Node"]
+  /nodes/{id}:
+    get:
+      summary: "Inspect a node"
+      operationId: "NodeInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Node"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+      tags: ["Node"]
+    delete:
+      summary: "Delete a node"
+      operationId: "NodeDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Force remove a node from the swarm"
+          default: false
+          type: "boolean"
+      tags: ["Node"]
+  /nodes/{id}/update:
+    post:
+      summary: "Update a node"
+      operationId: "NodeUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID of the node"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/NodeSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the node object being updated. This is required
+            to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Node"]
+  /swarm:
+    get:
+      summary: "Inspect swarm"
+      operationId: "SwarmInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Swarm"
+        404:
+          description: "no such swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/init:
+    post:
+      summary: "Initialize a new swarm"
+      operationId: "SwarmInit"
+      produces:
+        - "application/json"
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            description: "The node ID"
+            type: "string"
+            example: "7v2t30z9blmxuhnyo6s4cpenp"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmInitRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication, as well
+                  as determining the networking interface used for the VXLAN
+                  Tunnel Endpoint (VTEP). This can either be an address/port
+                  combination in the form `192.168.1.1:4567`, or an interface
+                  followed by a port number, like `eth0:4567`. If the port number
+                  is omitted, the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other  nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+                type: "string"
+              DataPathPort:
+                description: |
+                  DataPathPort specifies the data path port number for data traffic.
+                  Acceptable port range is 1024 to 49151.
+                  if no port is set or is set to 0, default port 4789 will be used.
+                type: "integer"
+                format: "uint32"
+              DefaultAddrPool:
+                description: |
+                  Default Address Pool specifies default subnet pools for global
+                  scope networks.
+                type: "array"
+                items:
+                  type: "string"
+                  example: ["10.10.0.0/16", "20.20.0.0/16"]
+              ForceNewCluster:
+                description: "Force creation of a new swarm."
+                type: "boolean"
+              SubnetSize:
+                description: |
+                  SubnetSize specifies the subnet size of the networks created
+                  from the default subnet pool.
+                type: "integer"
+                format: "uint32"
+              Spec:
+                $ref: "#/definitions/SwarmSpec"
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathPort: 4789
+              DefaultAddrPool: ["10.10.0.0/8", "20.20.0.0/8"]
+              SubnetSize: 24
+              ForceNewCluster: false
+              Spec:
+                Orchestration: {}
+                Raft: {}
+                Dispatcher: {}
+                CAConfig: {}
+                EncryptionConfig:
+                  AutoLockManagers: false
+      tags: ["Swarm"]
+  /swarm/join:
+    post:
+      summary: "Join an existing swarm"
+      operationId: "SwarmJoin"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmJoinRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+
+                type: "string"
+              RemoteAddrs:
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
+              JoinToken:
+                description: "Secret token for joining this swarm."
+                type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathAddr: "192.168.1.1"
+              RemoteAddrs:
+                - "node1:2377"
+              JoinToken: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+      tags: ["Swarm"]
+  /swarm/leave:
+    post:
+      summary: "Leave a swarm"
+      operationId: "SwarmLeave"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "force"
+          description: |
+            Force leave swarm, even if this is the last manager or that it will
+            break the cluster.
+          in: "query"
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/update:
+    post:
+      summary: "Update a swarm"
+      operationId: "SwarmUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/SwarmSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the swarm object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+        - name: "rotateWorkerToken"
+          in: "query"
+          description: "Rotate the worker join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerToken"
+          in: "query"
+          description: "Rotate the manager join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerUnlockKey"
+          in: "query"
+          description: "Rotate the manager unlock key."
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/unlockkey:
+    get:
+      summary: "Get the unlock key"
+      operationId: "SwarmUnlockkey"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "UnlockKeyResponse"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/unlock:
+    post:
+      summary: "Unlock a locked manager"
+      operationId: "SwarmUnlock"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmUnlockRequest"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /services:
+    get:
+      summary: "List services"
+      operationId: "ServiceList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Service"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the services list.
+
+            Available filters:
+
+            - `id=<service id>`
+            - `label=<service label>`
+            - `mode=["replicated"|"global"]`
+            - `name=<service name>`
+        - name: "status"
+          in: "query"
+          type: "boolean"
+          description: |
+            Include service status, with count of running and desired tasks.
+      tags: ["Service"]
+  /services/create:
+    post:
+      summary: "Create a service"
+      operationId: "ServiceCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "network is not eligible for services"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "name conflicts with an existing service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "web"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "nginx:alpine"
+                      Mounts:
+                        -
+                          ReadOnly: true
+                          Source: "web-data"
+                          Target: "/usr/share/nginx/html"
+                          Type: "volume"
+                          VolumeOptions:
+                            DriverConfig: {}
+                            Labels:
+                              com.example.something: "something-value"
+                      Hosts: ["10.10.10.10 host1", "ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 host2"]
+                      User: "33"
+                      DNSConfig:
+                        Nameservers: ["8.8.8.8"]
+                        Search: ["example.org"]
+                        Options: ["timeout:3"]
+                      Secrets:
+                        -
+                          File:
+                            Name: "www.example.org.key"
+                            UID: "33"
+                            GID: "33"
+                            Mode: 384
+                          SecretID: "fpjqlhnwb19zds35k8wn80lq9"
+                          SecretName: "example_org_domain_key"
+                      OomScoreAdj: 0
+                    LogDriver:
+                      Name: "json-file"
+                      Options:
+                        max-file: "3"
+                        max-size: "10M"
+                    Placement: {}
+                    Resources:
+                      Limits:
+                        MemoryBytes: 104857600
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "on-failure"
+                      Delay: 10000000000
+                      MaxAttempts: 10
+                  Mode:
+                    Replicated:
+                      Replicas: 4
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Ports:
+                      -
+                        Protocol: "tcp"
+                        PublishedPort: 8080
+                        TargetPort: 80
+                  Labels:
+                    foo: "bar"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+      tags: ["Service"]
+  /services/{id}:
+    get:
+      summary: "Inspect a service"
+      operationId: "ServiceInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Service"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "insertDefaults"
+          in: "query"
+          description: "Fill empty fields with default values."
+          type: "boolean"
+          default: false
+      tags: ["Service"]
+    delete:
+      summary: "Delete a service"
+      operationId: "ServiceDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+      tags: ["Service"]
+  /services/{id}/update:
+    post:
+      summary: "Update a service"
+      operationId: "ServiceUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceUpdateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "top"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "busybox"
+                      Args:
+                        - "top"
+                      OomScoreAdj: 0
+                    Resources:
+                      Limits: {}
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "any"
+                      MaxAttempts: 0
+                    Placement: {}
+                    ForceUpdate: 0
+                  Mode:
+                    Replicated:
+                      Replicas: 1
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Mode: "vip"
+
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the service object being updated. This is
+            required to avoid conflicting writes.
+            This version number should be the value as currently set on the
+            service *before* the update. You can find the current version by
+            calling `GET /services/{id}`
+          required: true
+          type: "integer"
+        - name: "registryAuthFrom"
+          in: "query"
+          description: |
+            If the `X-Registry-Auth` header is not specified, this parameter
+            indicates where to find registry authorization credentials.
+          type: "string"
+          enum: ["spec", "previous-spec"]
+          default: "spec"
+        - name: "rollback"
+          in: "query"
+          description: |
+            Set to this parameter to `previous` to cause a server-side rollback
+            to the previous service spec. The supplied spec will be ignored in
+            this case.
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+
+      tags: ["Service"]
+  /services/{id}/logs:
+    get:
+      summary: "Get service logs"
+      description: |
+        Get `stdout` and `stderr` logs from a service. See also
+        [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ServiceLogs"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such service: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the service"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show service context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Service"]
+  /tasks:
+    get:
+      summary: "List tasks"
+      operationId: "TaskList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Task"
+            example:
+              - ID: "0kzzo1i0y4jz6027t0k7aezc7"
+                Version:
+                  Index: 71
+                CreatedAt: "2016-06-07T21:07:31.171892745Z"
+                UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:31.290032978Z"
+                  State: "running"
+                  Message: "started"
+                  ContainerStatus:
+                    ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+                    PID: 677
+                DesiredState: "running"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.10/16"
+              - ID: "1yljwbmlr8er2waf8orvqpwms"
+                Version:
+                  Index: 30
+                CreatedAt: "2016-06-07T21:07:30.019104782Z"
+                UpdatedAt: "2016-06-07T21:07:30.231958098Z"
+                Name: "hopeful_cori"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:30.202183143Z"
+                  State: "shutdown"
+                  Message: "shutdown"
+                  ContainerStatus:
+                    ContainerID: "1cf8d63d18e79668b0004a4be4c6ee58cddfad2dae29506d8781581d0688a213"
+                DesiredState: "shutdown"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.5/16"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the tasks list.
+
+            Available filters:
+
+            - `desired-state=(running | shutdown | accepted)`
+            - `id=<task id>`
+            - `label=key` or `label="key=value"`
+            - `name=<task name>`
+            - `node=<node id or name>`
+            - `service=<service name>`
+      tags: ["Task"]
+  /tasks/{id}:
+    get:
+      summary: "Inspect a task"
+      operationId: "TaskInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Task"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID of the task"
+          required: true
+          type: "string"
+      tags: ["Task"]
+  /tasks/{id}/logs:
+    get:
+      summary: "Get task logs"
+      description: |
+        Get `stdout` and `stderr` logs from a task.
+        See also [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      operationId: "TaskLogs"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such task: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID of the task"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show task context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Task"]
+  /secrets:
+    get:
+      summary: "List secrets"
+      operationId: "SecretList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Secret"
+            example:
+              - ID: "blt1owaxmitz71s9v5zh81zun"
+                Version:
+                  Index: 85
+                CreatedAt: "2017-07-20T13:55:28.678958722Z"
+                UpdatedAt: "2017-07-20T13:55:28.678958722Z"
+                Spec:
+                  Name: "mysql-passwd"
+                  Labels:
+                    some.label: "some.value"
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "app-dev.crt"
+                  Labels:
+                    foo: "bar"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the secrets list.
+
+            Available filters:
+
+            - `id=<secret id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<secret name>`
+            - `names=<secret name>`
+      tags: ["Secret"]
+  /secrets/create:
+    post:
+      summary: "Create a secret"
+      operationId: "SecretCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/SecretSpec"
+              - type: "object"
+                example:
+                  Name: "app-key.crt"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+      tags: ["Secret"]
+  /secrets/{id}:
+    get:
+      summary: "Inspect a secret"
+      operationId: "SecretInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Secret"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+                Labels:
+                  foo: "bar"
+                Driver:
+                  Name: "secret-bucket"
+                  Options:
+                    OptionA: "value for driver option A"
+                    OptionB: "value for driver option B"
+
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+    delete:
+      summary: "Delete a secret"
+      operationId: "SecretDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+  /secrets/{id}/update:
+    post:
+      summary: "Update a Secret"
+      operationId: "SecretUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such secret"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the secret"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/SecretSpec"
+          description: |
+            The spec of the secret to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [SecretInspect endpoint](#operation/SecretInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the secret object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Secret"]
+  /configs:
+    get:
+      summary: "List configs"
+      operationId: "ConfigList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Config"
+            example:
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "server.conf"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the configs list.
+
+            Available filters:
+
+            - `id=<config id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<config name>`
+            - `names=<config name>`
+      tags: ["Config"]
+  /configs/create:
+    post:
+      summary: "Create a config"
+      operationId: "ConfigCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ConfigSpec"
+              - type: "object"
+                example:
+                  Name: "server.conf"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+      tags: ["Config"]
+  /configs/{id}:
+    get:
+      summary: "Inspect a config"
+      operationId: "ConfigInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Config"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+    delete:
+      summary: "Delete a config"
+      operationId: "ConfigDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+  /configs/{id}/update:
+    post:
+      summary: "Update a Config"
+      operationId: "ConfigUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such config"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the config"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/ConfigSpec"
+          description: |
+            The spec of the config to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [ConfigInspect endpoint](#operation/ConfigInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the config object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Config"]
+  /distribution/{name}/json:
+    get:
+      summary: "Get image information from the registry"
+      description: |
+        Return image digest and platform information by contacting the registry.
+      operationId: "DistributionInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "descriptor and platform information"
+          schema:
+            $ref: "#/definitions/DistributionInspect"
+        401:
+          description: "Failed authentication or no image found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+      tags: ["Distribution"]
+  /session:
+    post:
+      summary: "Initialize interactive session"
+      description: |
+        Start a new interactive session with a server. Session allows server to
+        call back to the client for advanced capabilities.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to HTTP2 transport that allows
+        the client to expose gPRC services on that connection.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /session HTTP/1.1
+        Upgrade: h2c
+        Connection: Upgrade
+        ```
+
+        The Docker daemon responds with a `101 UPGRADED` response follow with
+        the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Connection: Upgrade
+        Upgrade: h2c
+        ```
+      operationId: "Session"
+      produces:
+        - "application/vnd.docker.raw-stream"
+      responses:
+        101:
+          description: "no error, hijacking successful"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Session"]
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.52.yaml b/_vendor/github.com/moby/moby/api/docs/v1.52.yaml
new file mode 100644
index 000000000000..7ca2da0dcaef
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.52.yaml
@@ -0,0 +1,13627 @@
+# A Swagger 2.0 (a.k.a. OpenAPI) definition of the Engine API.
+#
+# This is used for generating API documentation and the types used by the
+# client/server. See api/README.md for more information.
+#
+# Some style notes:
+# - This file is used by ReDoc, which allows GitHub Flavored Markdown in
+#   descriptions.
+# - There is no maximum line length, for ease of editing and pretty diffs.
+# - operationIds are in the format "NounVerb", with a singular noun.
+
+swagger: "2.0"
+schemes:
+  - "http"
+  - "https"
+produces:
+  - "application/json"
+  - "text/plain"
+consumes:
+  - "application/json"
+  - "text/plain"
+basePath: "/v1.52"
+info:
+  title: "Docker Engine API"
+  version: "1.52"
+  x-logo:
+    url: "https://docs.docker.com/assets/images/logo-docker-main.png"
+  description: |
+    The Engine API is an HTTP API served by Docker Engine. It is the API the
+    Docker client uses to communicate with the Engine, so everything the Docker
+    client can do can be done with the API.
+
+    Most of the client's commands map directly to API endpoints (e.g. `docker ps`
+    is `GET /containers/json`). The notable exception is running containers,
+    which consists of several API calls.
+
+    # Errors
+
+    The API uses standard HTTP status codes to indicate the success or failure
+    of the API call. The body of the response will be JSON in the following
+    format:
+
+    ```
+    {
+      "message": "page not found"
+    }
+    ```
+
+    # Versioning
+
+    The API is usually changed in each release, so API calls are versioned to
+    ensure that clients don't break. To lock to a specific version of the API,
+    you prefix the URL with its version, for example, call `/v1.30/info` to use
+    the v1.30 version of the `/info` endpoint. If the API version specified in
+    the URL is not supported by the daemon, a HTTP `400 Bad Request` error message
+    is returned.
+
+    If you omit the version-prefix, the current version of the API (v1.50) is used.
+    For example, calling `/info` is the same as calling `/v1.52/info`. Using the
+    API without a version-prefix is deprecated and will be removed in a future release.
+
+    Engine releases in the near future should support this version of the API,
+    so your client will continue to work even if it is talking to a newer Engine.
+
+    The API uses an open schema model, which means the server may add extra properties
+    to responses. Likewise, the server will ignore any extra query parameters and
+    request body properties. When you write clients, you need to ignore additional
+    properties in responses to ensure they do not break when talking to newer
+    daemons.
+
+
+    # Authentication
+
+    Authentication for registries is handled client side. The client has to send
+    authentication details to various endpoints that need to communicate with
+    registries, such as `POST /images/(name)/push`. These are sent as
+    `X-Registry-Auth` header as a [base64url encoded](https://tools.ietf.org/html/rfc4648#section-5)
+    (JSON) string with the following structure:
+
+    ```
+    {
+      "username": "string",
+      "password": "string",
+      "serveraddress": "string"
+    }
+    ```
+
+    The `serveraddress` is a domain/IP without a protocol. Throughout this
+    structure, double quotes are required.
+
+    If you have already got an identity token from the [`/auth` endpoint](#operation/SystemAuth),
+    you can just pass this instead of credentials:
+
+    ```
+    {
+      "identitytoken": "9cbaf023786cd7..."
+    }
+    ```
+
+# The tags on paths define the menu sections in the ReDoc documentation, so
+# the usage of tags must make sense for that:
+# - They should be singular, not plural.
+# - There should not be too many tags, or the menu becomes unwieldy. For
+#   example, it is preferable to add a path to the "System" tag instead of
+#   creating a tag with a single path in it.
+# - The order of tags in this list defines the order in the menu.
+tags:
+  # Primary objects
+  - name: "Container"
+    x-displayName: "Containers"
+    description: |
+      Create and manage containers.
+  - name: "Image"
+    x-displayName: "Images"
+  - name: "Network"
+    x-displayName: "Networks"
+    description: |
+      Networks are user-defined networks that containers can be attached to.
+      See the [networking documentation](https://docs.docker.com/network/)
+      for more information.
+  - name: "Volume"
+    x-displayName: "Volumes"
+    description: |
+      Create and manage persistent storage that can be attached to containers.
+  - name: "Exec"
+    x-displayName: "Exec"
+    description: |
+      Run new commands inside running containers. Refer to the
+      [command-line reference](https://docs.docker.com/engine/reference/commandline/exec/)
+      for more information.
+
+      To exec a command in a container, you first need to create an exec instance,
+      then start it. These two API endpoints are wrapped up in a single command-line
+      command, `docker exec`.
+
+  # Swarm things
+  - name: "Swarm"
+    x-displayName: "Swarm"
+    description: |
+      Engines can be clustered together in a swarm. Refer to the
+      [swarm mode documentation](https://docs.docker.com/engine/swarm/)
+      for more information.
+  - name: "Node"
+    x-displayName: "Nodes"
+    description: |
+      Nodes are instances of the Engine participating in a swarm. Swarm mode
+      must be enabled for these endpoints to work.
+  - name: "Service"
+    x-displayName: "Services"
+    description: |
+      Services are the definitions of tasks to run on a swarm. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Task"
+    x-displayName: "Tasks"
+    description: |
+      A task is a container running on a swarm. It is the atomic scheduling unit
+      of swarm. Swarm mode must be enabled for these endpoints to work.
+  - name: "Secret"
+    x-displayName: "Secrets"
+    description: |
+      Secrets are sensitive data that can be used by services. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Config"
+    x-displayName: "Configs"
+    description: |
+      Configs are application configurations that can be used by services. Swarm
+      mode must be enabled for these endpoints to work.
+  # System things
+  - name: "Plugin"
+    x-displayName: "Plugins"
+  - name: "System"
+    x-displayName: "System"
+
+definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
+  PortSummary:
+    type: "object"
+    description: |
+      Describes a port-mapping between the container and the host.
+    required: [PrivatePort, Type]
+    properties:
+      IP:
+        type: "string"
+        format: "ip-address"
+        description: "Host IP address that the container's port is mapped to"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      PrivatePort:
+        type: "integer"
+        format: "uint16"
+        x-nullable: false
+        description: "Port on the container"
+      PublicPort:
+        type: "integer"
+        format: "uint16"
+        description: "Port exposed on the host"
+      Type:
+        type: "string"
+        x-nullable: false
+        enum: ["tcp", "udp", "sctp"]
+    example:
+      PrivatePort: 8080
+      PublicPort: 80
+      Type: "tcp"
+
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `image` an OCI image.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "image"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
+  MountPoint:
+    type: "object"
+    description: |
+      MountPoint represents a mount point configuration inside the container.
+      This is used for reporting the mountpoints in use by a container.
+    properties:
+      Type:
+        description: |
+          The mount type:
+
+          - `bind` a mount of a file or directory from the host into the container.
+          - `cluster` a Swarm cluster volume.
+          - `image` an OCI image.
+          - `npipe` a named pipe from the host into the container.
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
+        example: "volume"
+      Name:
+        description: |
+          Name is the name reference to the underlying data defined by `Source`
+          e.g., the volume name.
+        type: "string"
+        example: "myvolume"
+      Source:
+        description: |
+          Source location of the mount.
+
+          For volumes, this contains the storage location of the volume (within
+          `/var/lib/docker/volumes/`). For bind-mounts, and `npipe`, this contains
+          the source (host) part of the bind-mount. For `tmpfs` mount points, this
+          field is empty.
+        type: "string"
+        example: "/var/lib/docker/volumes/myvolume/_data"
+      Destination:
+        description: |
+          Destination is the path relative to the container root (`/`) where
+          the `Source` is mounted inside the container.
+        type: "string"
+        example: "/usr/share/nginx/html/"
+      Driver:
+        description: |
+          Driver is the volume driver used to create the volume (if it is a volume).
+        type: "string"
+        example: "local"
+      Mode:
+        description: |
+          Mode is a comma separated list of options supplied by the user when
+          creating the bind/volume mount.
+
+          The default is platform-specific (`"z"` on Linux, empty on Windows).
+        type: "string"
+        example: "z"
+      RW:
+        description: |
+          Whether the mount is mounted writable (read-write).
+        type: "boolean"
+        example: true
+      Propagation:
+        description: |
+          Propagation describes how mounts are propagated from the host into the
+          mount point, and vice-versa. Refer to the [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
+          for details. This field is not used on Windows.
+        type: "string"
+        example: ""
+
+  DeviceMapping:
+    type: "object"
+    description: "A device mapping between the host and container"
+    properties:
+      PathOnHost:
+        type: "string"
+      PathInContainer:
+        type: "string"
+      CgroupPermissions:
+        type: "string"
+    example:
+      PathOnHost: "/dev/deviceName"
+      PathInContainer: "/dev/deviceName"
+      CgroupPermissions: "mrw"
+
+  DeviceRequest:
+    type: "object"
+    description: "A request for devices to be sent to device drivers"
+    properties:
+      Driver:
+        description: |
+          The name of the device driver to use for this request.
+
+          Note that if this is specified the capabilities are ignored when
+          selecting a device driver.
+        type: "string"
+        example: "nvidia"
+      Count:
+        type: "integer"
+        example: -1
+      DeviceIDs:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "0"
+          - "1"
+          - "GPU-fef8089b-4820-abfc-e83e-94318197576e"
+      Capabilities:
+        description: |
+          A list of capabilities; an OR list of AND lists of capabilities.
+
+          Note that if a driver is specified the capabilities have no effect on
+          selecting a driver as the driver name is used directly.
+
+          Note that if no driver is specified the capabilities are used to
+          select a driver with the required capabilities.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          # gpu AND nvidia AND compute
+          - ["gpu", "nvidia", "compute"]
+      Options:
+        description: |
+          Driver-specific options, specified as a key/value pairs. These options
+          are passed directly to the driver.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  ThrottleDevice:
+    type: "object"
+    properties:
+      Path:
+        description: "Device path"
+        type: "string"
+      Rate:
+        description: "Rate"
+        type: "integer"
+        format: "int64"
+        minimum: 0
+
+  Mount:
+    type: "object"
+    properties:
+      Target:
+        description: "Container path."
+        type: "string"
+      Source:
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
+        type: "string"
+      Type:
+        description: |
+          The mount type. Available types:
+
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `cluster` a Swarm cluster volume
+          - `image` Mounts an image.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
+      ReadOnly:
+        description: "Whether the mount should be read-only."
+        type: "boolean"
+      Consistency:
+        description: "The consistency requirement for the mount: `default`, `consistent`, `cached`, or `delegated`."
+        type: "string"
+      BindOptions:
+        description: "Optional configuration for the `bind` type."
+        type: "object"
+        properties:
+          Propagation:
+            description: "A propagation mode with the value `[r]private`, `[r]shared`, or `[r]slave`."
+            type: "string"
+            enum:
+              - "private"
+              - "rprivate"
+              - "shared"
+              - "rshared"
+              - "slave"
+              - "rslave"
+          NonRecursive:
+            description: "Disable recursive bind mount."
+            type: "boolean"
+            default: false
+          CreateMountpoint:
+            description: "Create mount point on host if missing"
+            type: "boolean"
+            default: false
+          ReadOnlyNonRecursive:
+            description: |
+               Make the mount non-recursively read-only, but still leave the mount recursive
+               (unless NonRecursive is set to `true` in conjunction).
+
+               Added in v1.44, before that version all read-only mounts were
+               non-recursive by default. To match the previous behaviour this
+               will default to `true` for clients on versions prior to v1.44.
+            type: "boolean"
+            default: false
+          ReadOnlyForceRecursive:
+            description: "Raise an error if the mount cannot be made recursively read-only."
+            type: "boolean"
+            default: false
+      VolumeOptions:
+        description: "Optional configuration for the `volume` type."
+        type: "object"
+        properties:
+          NoCopy:
+            description: "Populate volume with data from the target."
+            type: "boolean"
+            default: false
+          Labels:
+            description: "User-defined key/value metadata."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          DriverConfig:
+            description: "Map of driver specific options"
+            type: "object"
+            properties:
+              Name:
+                description: "Name of the driver to use to create the volume."
+                type: "string"
+              Options:
+                description: "key/value map of driver specific options."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+          Subpath:
+            description: "Source path inside the volume. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-volume/subdirectory"
+      ImageOptions:
+        description: "Optional configuration for the `image` type."
+        type: "object"
+        properties:
+          Subpath:
+            description: "Source path inside the image. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-image/subdirectory"
+      TmpfsOptions:
+        description: "Optional configuration for the `tmpfs` type."
+        type: "object"
+        properties:
+          SizeBytes:
+            description: "The size for the tmpfs mount in bytes."
+            type: "integer"
+            format: "int64"
+          Mode:
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
+            type: "integer"
+          Options:
+            description: |
+              The options to be passed to the tmpfs mount. An array of arrays.
+              Flag options should be provided as 1-length arrays. Other types
+              should be provided as as 2-length arrays, where the first item is
+              the key and the second the value.
+            type: "array"
+            items:
+              type: "array"
+              minItems: 1
+              maxItems: 2
+              items:
+                type: "string"
+            example:
+              [["noexec"]]
+
+  RestartPolicy:
+    description: |
+      The behavior to apply when the container exits. The default is not to
+      restart.
+
+      An ever increasing delay (double the previous delay, starting at 100ms) is
+      added before each restart to prevent flooding the server.
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        description: |
+          - Empty string means not to restart
+          - `no` Do not automatically restart
+          - `always` Always restart
+          - `unless-stopped` Restart always except when the user has manually stopped the container
+          - `on-failure` Restart only when the container exit code is non-zero
+        enum:
+          - ""
+          - "no"
+          - "always"
+          - "unless-stopped"
+          - "on-failure"
+      MaximumRetryCount:
+        type: "integer"
+        description: |
+          If `on-failure` is used, the number of times to retry before giving up.
+
+  Resources:
+    description: "A container's resources (cgroups config, ulimits, etc)"
+    type: "object"
+    properties:
+      # Applicable to all platforms
+      CpuShares:
+        description: |
+          An integer value representing this container's relative CPU weight
+          versus other containers.
+        type: "integer"
+      Memory:
+        description: "Memory limit in bytes."
+        type: "integer"
+        format: "int64"
+        default: 0
+      # Applicable to UNIX platforms
+      CgroupParent:
+        description: |
+          Path to `cgroups` under which the container's `cgroup` is created. If
+          the path is not absolute, the path is considered to be relative to the
+          `cgroups` path of the init process. Cgroups are created if they do not
+          already exist.
+        type: "string"
+      BlkioWeight:
+        description: "Block IO weight (relative weight)."
+        type: "integer"
+        minimum: 0
+        maximum: 1000
+      BlkioWeightDevice:
+        description: |
+          Block IO weight (relative device weight) in the form:
+
+          ```
+          [{"Path": "device_path", "Weight": weight}]
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Path:
+              type: "string"
+            Weight:
+              type: "integer"
+              minimum: 0
+      BlkioDeviceReadBps:
+        description: |
+          Limit read rate (bytes per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteBps:
+        description: |
+          Limit write rate (bytes per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceReadIOps:
+        description: |
+          Limit read rate (IO per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteIOps:
+        description: |
+          Limit write rate (IO per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      CpuPeriod:
+        description: "The length of a CPU period in microseconds."
+        type: "integer"
+        format: "int64"
+      CpuQuota:
+        description: |
+          Microseconds of CPU time that the container can get in a CPU period.
+        type: "integer"
+        format: "int64"
+      CpuRealtimePeriod:
+        description: |
+          The length of a CPU real-time period in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpuRealtimeRuntime:
+        description: |
+          The length of a CPU real-time runtime in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpusetCpus:
+        description: |
+          CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+        type: "string"
+        example: "0-3"
+      CpusetMems:
+        description: |
+          Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only
+          effective on NUMA systems.
+        type: "string"
+      Devices:
+        description: "A list of devices to add to the container."
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceMapping"
+      DeviceCgroupRules:
+        description: "a list of cgroup rules to apply to the container"
+        type: "array"
+        items:
+          type: "string"
+          example: "c 13:* rwm"
+      DeviceRequests:
+        description: |
+          A list of requests for devices to be sent to device drivers.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceRequest"
+      MemoryReservation:
+        description: "Memory soft limit in bytes."
+        type: "integer"
+        format: "int64"
+      MemorySwap:
+        description: |
+          Total memory limit (memory + swap). Set as `-1` to enable unlimited
+          swap.
+        type: "integer"
+        format: "int64"
+      MemorySwappiness:
+        description: |
+          Tune a container's memory swappiness behavior. Accepts an integer
+          between 0 and 100.
+        type: "integer"
+        format: "int64"
+        minimum: 0
+        maximum: 100
+      NanoCpus:
+        description: "CPU quota in units of 10<sup>-9</sup> CPUs."
+        type: "integer"
+        format: "int64"
+      OomKillDisable:
+        description: "Disable OOM Killer for the container."
+        type: "boolean"
+      Init:
+        description: |
+          Run an init inside the container that forwards signals and reaps
+          processes. This field is omitted if empty, and the default (as
+          configured on the daemon) is used.
+        type: "boolean"
+        x-nullable: true
+      PidsLimit:
+        description: |
+          Tune a container's PIDs limit. Set `0` or `-1` for unlimited, or `null`
+          to not change.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+      Ulimits:
+        description: |
+          A list of resource limits to set in the container. For example:
+
+          ```
+          {"Name": "nofile", "Soft": 1024, "Hard": 2048}
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Name:
+              description: "Name of ulimit"
+              type: "string"
+            Soft:
+              description: "Soft limit"
+              type: "integer"
+            Hard:
+              description: "Hard limit"
+              type: "integer"
+      # Applicable to Windows
+      CpuCount:
+        description: |
+          The number of usable CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      CpuPercent:
+        description: |
+          The usable percentage of the available CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      IOMaximumIOps:
+        description: "Maximum IOps for the container system drive (Windows only)"
+        type: "integer"
+        format: "int64"
+      IOMaximumBandwidth:
+        description: |
+          Maximum IO in bytes per second for the container system drive
+          (Windows only).
+        type: "integer"
+        format: "int64"
+
+  Limit:
+    description: |
+      An object describing a limit on resources which can be requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      Pids:
+        description: |
+          Limits the maximum number of PIDs in the container. Set `0` for unlimited.
+        type: "integer"
+        format: "int64"
+        default: 0
+        example: 100
+
+  ResourceObject:
+    description: |
+      An object describing the resources which can be advertised by a node and
+      requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+
+  GenericResources:
+    description: |
+      User-defined resources can be either Integer resources (e.g, `SSD=3`) or
+      String resources (e.g, `GPU=UUID1`).
+    type: "array"
+    items:
+      type: "object"
+      properties:
+        NamedResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "string"
+        DiscreteResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "integer"
+              format: "int64"
+    example:
+      - DiscreteResourceSpec:
+          Kind: "SSD"
+          Value: 3
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID1"
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID2"
+
+  HealthConfig:
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
+    type: "object"
+    properties:
+      Test:
+        description: |
+          The test to perform. Possible values are:
+
+          - `[]` inherit healthcheck from image or parent image
+          - `["NONE"]` disable healthcheck
+          - `["CMD", args...]` exec arguments directly
+          - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
+        type: "array"
+        items:
+          type: "string"
+      Interval:
+        description: |
+          The time to wait between checks in nanoseconds. It should be 0 or at
+          least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      Timeout:
+        description: |
+          The time to wait before considering the check to have hung. It should
+          be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
+        type: "integer"
+        format: "int64"
+      Retries:
+        description: |
+          The number of consecutive failures needed to consider a container as
+          unhealthy. 0 means inherit.
+        type: "integer"
+      StartPeriod:
+        description: |
+          Start period for the container to initialize before starting
+          health-retries countdown in nanoseconds. It should be 0 or at least
+          1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      StartInterval:
+        description: |
+          The time to wait between checks in nanoseconds during the start period.
+          It should be 0 or at least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+
+  Health:
+    description: |
+      Health stores information about the container's healthcheck results.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          Status is one of `none`, `starting`, `healthy` or `unhealthy`
+
+          - "none"      Indicates there is no healthcheck
+          - "starting"  Starting indicates that the container is not yet ready
+          - "healthy"   Healthy indicates that the container is running correctly
+          - "unhealthy" Unhealthy indicates that the container has a problem
+        type: "string"
+        enum:
+          - "none"
+          - "starting"
+          - "healthy"
+          - "unhealthy"
+        example: "healthy"
+      FailingStreak:
+        description: "FailingStreak is the number of consecutive failures"
+        type: "integer"
+        example: 0
+      Log:
+        type: "array"
+        description: |
+          Log contains the last few results (oldest first)
+        items:
+          $ref: "#/definitions/HealthcheckResult"
+
+  HealthcheckResult:
+    description: |
+      HealthcheckResult stores information about a single run of a healthcheck probe
+    type: "object"
+    x-nullable: true
+    properties:
+      Start:
+        description: |
+          Date and time at which this check started in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2020-01-04T10:44:24.496525531Z"
+      End:
+        description: |
+          Date and time at which this check ended in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2020-01-04T10:45:21.364524523Z"
+      ExitCode:
+        description: |
+          ExitCode meanings:
+
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (considered unhealthy)
+          - other values: error running probe
+        type: "integer"
+        example: 0
+      Output:
+        description: "Output from last check"
+        type: "string"
+
+  HostConfig:
+    description: "Container configuration that depends on the host we are running on"
+    allOf:
+      - $ref: "#/definitions/Resources"
+      - type: "object"
+        properties:
+          # Applicable to all platforms
+          Binds:
+            type: "array"
+            description: |
+              A list of volume bindings for this container. Each volume binding
+              is a string in one of these forms:
+
+              - `host-src:container-dest[:options]` to bind-mount a host path
+                into the container. Both `host-src`, and `container-dest` must
+                be an _absolute_ path.
+              - `volume-name:container-dest[:options]` to bind-mount a volume
+                managed by a volume driver into the container. `container-dest`
+                must be an _absolute_ path.
+
+              `options` is an optional, comma-delimited list of:
+
+              - `nocopy` disables automatic copying of data from the container
+                path to the volume. The `nocopy` flag only applies to named volumes.
+              - `[ro|rw]` mounts a volume read-only or read-write, respectively.
+                If omitted or set to `rw`, volumes are mounted read-write.
+              - `[z|Z]` applies SELinux labels to allow or deny multiple containers
+                to read and write to the same volume.
+                  - `z`: a _shared_ content label is applied to the content. This
+                    label indicates that multiple containers can share the volume
+                    content, for both reading and writing.
+                  - `Z`: a _private unshared_ label is applied to the content.
+                    This label indicates that only the current container can use
+                    a private volume. Labeling systems such as SELinux require
+                    proper labels to be placed on volume content that is mounted
+                    into a container. Without a label, the security system can
+                    prevent a container's processes from using the content. By
+                    default, the labels set by the host operating system are not
+                    modified.
+              - `[[r]shared|[r]slave|[r]private]` specifies mount
+                [propagation behavior](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt).
+                This only applies to bind-mounted volumes, not internal volumes
+                or named volumes. Mount propagation requires the source mount
+                point (the location where the source directory is mounted in the
+                host operating system) to have the correct propagation properties.
+                For shared volumes, the source mount point must be set to `shared`.
+                For slave volumes, the mount must be set to either `shared` or
+                `slave`.
+            items:
+              type: "string"
+          ContainerIDFile:
+            type: "string"
+            description: "Path to a file where the container ID is written"
+            example: ""
+          LogConfig:
+            type: "object"
+            description: "The logging configuration for this container"
+            properties:
+              Type:
+                description: |-
+                  Name of the logging driver used for the container or "none"
+                  if logging is disabled.
+                type: "string"
+                enum:
+                  - "local"
+                  - "json-file"
+                  - "syslog"
+                  - "journald"
+                  - "gelf"
+                  - "fluentd"
+                  - "awslogs"
+                  - "splunk"
+                  - "etwlogs"
+                  - "none"
+              Config:
+                description: |-
+                  Driver-specific configuration options for the logging driver.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "5"
+                  "max-size": "10m"
+          NetworkMode:
+            type: "string"
+            description: |
+              Network mode to use for this container. Supported standard values
+              are: `bridge`, `host`, `none`, and `container:<name|id>`. Any
+              other value is taken as a custom network's name to which this
+              container should connect to.
+          PortBindings:
+            $ref: "#/definitions/PortMap"
+          RestartPolicy:
+            $ref: "#/definitions/RestartPolicy"
+          AutoRemove:
+            type: "boolean"
+            description: |
+              Automatically remove the container when the container's process
+              exits. This has no effect if `RestartPolicy` is set.
+          VolumeDriver:
+            type: "string"
+            description: "Driver that this container uses to mount volumes."
+          VolumesFrom:
+            type: "array"
+            description: |
+              A list of volumes to inherit from another container, specified in
+              the form `<container name>[:<ro|rw>]`.
+            items:
+              type: "string"
+          Mounts:
+            description: |
+              Specification for mounts to be added to the container.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          ConsoleSize:
+            type: "array"
+            description: |
+              Initial console size, as an `[height, width]` array.
+            x-nullable: true
+            minItems: 2
+            maxItems: 2
+            items:
+              type: "integer"
+              minimum: 0
+            example: [80, 64]
+          Annotations:
+            type: "object"
+            description: |
+              Arbitrary non-identifying metadata attached to container and
+              provided to the runtime when the container is started.
+            additionalProperties:
+              type: "string"
+
+          # Applicable to UNIX platforms
+          CapAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CapDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CgroupnsMode:
+            type: "string"
+            enum:
+              - "private"
+              - "host"
+            description: |
+              cgroup namespace mode for the container. Possible values are:
+
+              - `"private"`: the container runs in its own private cgroup namespace
+              - `"host"`: use the host system's cgroup namespace
+
+              If not specified, the daemon default is used, which can either be `"private"`
+              or `"host"`, depending on daemon version, kernel support and configuration.
+          Dns:
+            type: "array"
+            description: "A list of DNS servers for the container to use."
+            items:
+              type: "string"
+              format: "ip-address"
+              x-go-type:
+                type: Addr
+                import:
+                  package: net/netip
+          DnsOptions:
+            type: "array"
+            description: "A list of DNS options."
+            items:
+              type: "string"
+          DnsSearch:
+            type: "array"
+            description: "A list of DNS search domains."
+            items:
+              type: "string"
+          ExtraHosts:
+            type: "array"
+            description: |
+              A list of hostnames/IP mappings to add to the container's `/etc/hosts`
+              file. Specified in the form `["hostname:IP"]`.
+            items:
+              type: "string"
+          GroupAdd:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          IpcMode:
+            type: "string"
+            description: |
+              IPC sharing mode for the container. Possible values are:
+
+              - `"none"`: own private IPC namespace, with /dev/shm not mounted
+              - `"private"`: own private IPC namespace
+              - `"shareable"`: own private IPC namespace, with a possibility to share it with other containers
+              - `"container:<name|id>"`: join another (shareable) container's IPC namespace
+              - `"host"`: use the host system's IPC namespace
+
+              If not specified, daemon default is used, which can either be `"private"`
+              or `"shareable"`, depending on daemon version and configuration.
+          Cgroup:
+            type: "string"
+            description: "Cgroup to use for the container."
+          Links:
+            type: "array"
+            description: |
+              A list of links for the container in the form `container_name:alias`.
+            items:
+              type: "string"
+          OomScoreAdj:
+            type: "integer"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 500
+          PidMode:
+            type: "string"
+            description: |
+              Set the PID (Process) Namespace mode for the container. It can be
+              either:
+
+              - `"container:<name|id>"`: joins another container's PID namespace
+              - `"host"`: use the host's PID namespace inside the container
+          Privileged:
+            type: "boolean"
+            description: |-
+              Gives the container full access to the host.
+          PublishAllPorts:
+            type: "boolean"
+            description: |
+              Allocates an ephemeral host port for all of a container's
+              exposed ports.
+
+              Ports are de-allocated when the container stops and allocated when
+              the container starts. The allocated port might be changed when
+              restarting the container.
+
+              The port is selected from the ephemeral port range that depends on
+              the kernel. For example, on Linux the range is defined by
+              `/proc/sys/net/ipv4/ip_local_port_range`.
+          ReadonlyRootfs:
+            type: "boolean"
+            description: "Mount the container's root filesystem as read only."
+          SecurityOpt:
+            type: "array"
+            description: |
+              A list of string values to customize labels for MLS systems, such
+              as SELinux.
+            items:
+              type: "string"
+          StorageOpt:
+            type: "object"
+            description: |
+              Storage driver options for this container, in the form `{"size": "120G"}`.
+            additionalProperties:
+              type: "string"
+          Tmpfs:
+            type: "object"
+            description: |
+              A map of container directories which should be replaced by tmpfs
+              mounts, and their corresponding mount options. For example:
+
+              ```
+              { "/run": "rw,noexec,nosuid,size=65536k" }
+              ```
+            additionalProperties:
+              type: "string"
+          UTSMode:
+            type: "string"
+            description: "UTS namespace to use for the container."
+          UsernsMode:
+            type: "string"
+            description: |
+              Sets the usernamespace mode for the container when usernamespace
+              remapping option is enabled.
+          ShmSize:
+            type: "integer"
+            format: "int64"
+            description: |
+              Size of `/dev/shm` in bytes. If omitted, the system uses 64MB.
+            minimum: 0
+          Sysctls:
+            type: "object"
+            x-nullable: true
+            description: |-
+              A list of kernel parameters (sysctls) to set in the container.
+
+              This field is omitted if not set.
+            additionalProperties:
+              type: "string"
+            example:
+              "net.ipv4.ip_forward": "1"
+          Runtime:
+            type: "string"
+            x-nullable: true
+            description: |-
+              Runtime to use with this container.
+          # Applicable to Windows
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the container. (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          MaskedPaths:
+            type: "array"
+            description: |
+              The list of paths to be masked inside the container (this overrides
+              the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/asound"
+              - "/proc/acpi"
+              - "/proc/kcore"
+              - "/proc/keys"
+              - "/proc/latency_stats"
+              - "/proc/timer_list"
+              - "/proc/timer_stats"
+              - "/proc/sched_debug"
+              - "/proc/scsi"
+              - "/sys/firmware"
+              - "/sys/devices/virtual/powercap"
+          ReadonlyPaths:
+            type: "array"
+            description: |
+              The list of paths to be set as read-only inside the container
+              (this overrides the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/bus"
+              - "/proc/fs"
+              - "/proc/irq"
+              - "/proc/sys"
+              - "/proc/sysrq-trigger"
+
+  ContainerConfig:
+    description: |
+      Configuration for a container that is portable between hosts.
+    type: "object"
+    properties:
+      Hostname:
+        description: |
+          The hostname to use for the container, as a valid RFC 1123 hostname.
+        type: "string"
+        example: "439f4e91bd1d"
+      Domainname:
+        description: |
+          The domain name to use for the container.
+        type: "string"
+      User:
+        description: |-
+          Commands run as this user inside the container. If omitted, commands
+          run as the user specified in the image the container was started from.
+
+          Can be either user-name or UID, and optional group-name or GID,
+          separated by a colon (`<user-name|UID>[<:group-name|GID>]`).
+        type: "string"
+        example: "123:456"
+      AttachStdin:
+        description: "Whether to attach to `stdin`."
+        type: "boolean"
+        default: false
+      AttachStdout:
+        description: "Whether to attach to `stdout`."
+        type: "boolean"
+        default: true
+      AttachStderr:
+        description: "Whether to attach to `stderr`."
+        type: "boolean"
+        default: true
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Tty:
+        description: |
+          Attach standard streams to a TTY, including `stdin` if it is not closed.
+        type: "boolean"
+        default: false
+      OpenStdin:
+        description: "Open `stdin`"
+        type: "boolean"
+        default: false
+      StdinOnce:
+        description: "Close `stdin` after one attached client disconnects"
+        type: "boolean"
+        default: false
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Image:
+        description: |
+          The name (or reference) of the image to use when creating the container,
+          or which was used when the container was created.
+        type: "string"
+        example: "example-image:1.0"
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      NetworkDisabled:
+        description: "Disable networking for the container."
+        type: "boolean"
+        x-nullable: true
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      StopTimeout:
+        description: "Timeout to stop a container in seconds."
+        type: "integer"
+        default: 10
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  ImageConfig:
+    description: |
+      Configuration of the image. These fields are used as defaults
+      when starting a container from the image.
+    type: "object"
+    properties:
+      User:
+        description: "The user that commands are run as inside the container."
+        type: "string"
+        example: "web:web"
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example:
+          "/app/data": {}
+          "/app/config": {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  NetworkingConfig:
+    description: |
+      NetworkingConfig represents the container's networking configuration for
+      each of its interfaces.
+      It is used for the networking configs specified in the `docker create`
+      and `docker network connect` commands.
+    type: "object"
+    properties:
+      EndpointsConfig:
+        description: |
+          A mapping of network name to endpoint configuration for that network.
+          The endpoint configuration can be left empty to connect to that
+          network with no particular endpoint configuration.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+    example:
+      # putting an example here, instead of using the example values from
+      # /definitions/EndpointSettings, because EndpointSettings contains
+      # operational data returned when inspecting a container that we don't
+      # accept here.
+      EndpointsConfig:
+        isolated_nw:
+          IPAMConfig:
+            IPv4Address: "172.20.30.33"
+            IPv6Address: "2001:db8:abcd::3033"
+            LinkLocalIPs:
+              - "169.254.34.68"
+              - "fe80::3468"
+          MacAddress: "02:42:ac:12:05:02"
+          Links:
+            - "container_1"
+            - "container_2"
+          Aliases:
+            - "server_x"
+            - "server_y"
+        database_nw: {}
+
+  NetworkSettings:
+    description: "NetworkSettings exposes the network settings in the API"
+    type: "object"
+    properties:
+      SandboxID:
+        description: SandboxID uniquely represents a container's network stack.
+        type: "string"
+        example: "9d12daf2c33f5959c8bf90aa513e4f65b561738661003029ec84830cd503a0c3"
+      SandboxKey:
+        description: SandboxKey is the full path of the netns handle
+        type: "string"
+        example: "/var/run/docker/netns/8ab54b426c38"
+      Ports:
+        $ref: "#/definitions/PortMap"
+      Networks:
+        description: |
+          Information about all networks that the container is connected to.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+
+  Address:
+    description: Address represents an IPv4 or IPv6 IP address.
+    type: "object"
+    properties:
+      Addr:
+        description: IP address.
+        type: "string"
+      PrefixLen:
+        description: Mask length of the IP address.
+        type: "integer"
+
+  PortMap:
+    description: |
+      PortMap describes the mapping of container ports to host ports, using the
+      container's port-number and protocol as key in the format `<port>/<protocol>`,
+      for example, `80/udp`.
+
+      If a container's port is mapped for multiple protocols, separate entries
+      are added to the mapping table.
+    type: "object"
+    additionalProperties:
+      type: "array"
+      x-nullable: true
+      items:
+        $ref: "#/definitions/PortBinding"
+    example:
+      "443/tcp":
+        - HostIp: "127.0.0.1"
+          HostPort: "4443"
+      "80/tcp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+        - HostIp: "0.0.0.0"
+          HostPort: "8080"
+      "80/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+      "53/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "53"
+      "2377/tcp": null
+
+  PortBinding:
+    description: |
+      PortBinding represents a binding between a host IP address and a host
+      port.
+    type: "object"
+    properties:
+      HostIp:
+        description: "Host IP address that the container's port is mapped to."
+        type: "string"
+        example: "127.0.0.1"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      HostPort:
+        description: "Host port number that the container's port is mapped to."
+        type: "string"
+        example: "4443"
+
+  DriverData:
+    description: |
+      Information about the storage driver used to store the container's and
+      image's filesystem.
+    type: "object"
+    required: [Name, Data]
+    properties:
+      Name:
+        description: "Name of the storage driver."
+        type: "string"
+        x-nullable: false
+        example: "overlay2"
+      Data:
+        description: |
+          Low-level storage metadata, provided as key/value pairs.
+
+          This information is driver-specific, and depends on the storage-driver
+          in use, and should be used for informational purposes only.
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example: {
+          "MergedDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/merged",
+          "UpperDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/diff",
+          "WorkDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/work"
+        }
+
+  Storage:
+    description: |
+      Information about the storage used by the container.
+    type: "object"
+    properties:
+      RootFS:
+        description: |
+          Information about the storage used for the container's root filesystem.
+        type: "object"
+        x-nullable: true
+        $ref: "#/definitions/RootFSStorage"
+
+  RootFSStorage:
+    description: |
+      Information about the storage used for the container's root filesystem.
+    type: "object"
+    x-go-name: RootFSStorage
+    properties:
+      Snapshot:
+        description: |
+          Information about the snapshot used for the container's root filesystem.
+        type: "object"
+        x-nullable: true
+        $ref: "#/definitions/RootFSStorageSnapshot"
+
+  RootFSStorageSnapshot:
+    description: |
+      Information about a snapshot backend of the container's root filesystem.
+    type: "object"
+    x-go-name: RootFSStorageSnapshot
+    properties:
+      Name:
+        description: "Name of the snapshotter."
+        type: "string"
+        x-nullable: false
+
+  FilesystemChange:
+    description: |
+      Change in the container's filesystem.
+    type: "object"
+    required: [Path, Kind]
+    properties:
+      Path:
+        description: |
+          Path to file or directory that has changed.
+        type: "string"
+        x-nullable: false
+      Kind:
+        $ref: "#/definitions/ChangeType"
+
+  ChangeType:
+    description: |
+      Kind of change
+
+      Can be one of:
+
+      - `0`: Modified ("C")
+      - `1`: Added ("A")
+      - `2`: Deleted ("D")
+    type: "integer"
+    format: "uint8"
+    enum: [0, 1, 2]
+    x-nullable: false
+
+  ImageInspect:
+    description: |
+      Information about an image in the local image cache.
+    type: "object"
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+      Manifests:
+        description: |
+            Manifests is a list of image manifests available in this image. It
+            provides a more detailed view of the platform-specific image manifests or
+            other image-attached data like build attestations.
+
+            Only available if the daemon provides a multi-platform image store
+            and the `manifests` option is set in the inspect request.
+
+            WARNING: This is experimental and may change at any time without any backward
+            compatibility.
+        type: "array"
+        x-nullable: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Comment:
+        description: |
+          Optional message that was set when committing or importing the image.
+        type: "string"
+        x-nullable: true
+        example: ""
+      Created:
+        description: |
+          Date and time at which the image was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+          This information is only available if present in the image,
+          and omitted otherwise.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2022-02-04T21:20:12.497794809Z"
+      Author:
+        description: |
+          Name of the author that was specified when committing the image, or as
+          specified through MAINTAINER (deprecated) in the Dockerfile.
+        type: "string"
+        x-nullable: true
+        example: ""
+      Config:
+        $ref: "#/definitions/ImageConfig"
+      Architecture:
+        description: |
+          Hardware CPU architecture that the image runs on.
+        type: "string"
+        x-nullable: false
+        example: "arm"
+      Variant:
+        description: |
+          CPU architecture variant (presently ARM-only).
+        type: "string"
+        x-nullable: true
+        example: "v7"
+      Os:
+        description: |
+          Operating System the image is built to run on.
+        type: "string"
+        x-nullable: false
+        example: "linux"
+      OsVersion:
+        description: |
+          Operating System version the image is built to run on (especially
+          for Windows).
+        type: "string"
+        example: ""
+        x-nullable: true
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      GraphDriver:
+        x-nullable: true
+        $ref: "#/definitions/DriverData"
+      RootFS:
+        description: |
+          Information about the image's RootFS, including the layer IDs.
+        type: "object"
+        required: [Type]
+        properties:
+          Type:
+            type: "string"
+            x-nullable: false
+            example: "layers"
+          Layers:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "sha256:1834950e52ce4d5a88a1bbd131c537f4d0e56d10ff0dd69e66be3b7dfa9df7e6"
+              - "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"
+      Metadata:
+        description: |
+          Additional metadata of the image in the local cache. This information
+          is local to the daemon, and not part of the image itself.
+        type: "object"
+        properties:
+          LastTagTime:
+            description: |
+              Date and time at which the image was last tagged in
+              [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+              This information is only available if the image was tagged locally,
+              and omitted otherwise.
+            type: "string"
+            format: "dateTime"
+            example: "2022-02-28T14:40:02.623929178Z"
+            x-nullable: true
+
+  ImageSummary:
+    type: "object"
+    x-go-name: "Summary"
+    required:
+      - Id
+      - ParentId
+      - RepoTags
+      - RepoDigests
+      - Created
+      - Size
+      - SharedSize
+      - Labels
+      - Containers
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      ParentId:
+        description: |
+          ID of the parent image.
+
+          Depending on how the image was created, this field may be empty and
+          is only set for images that were built/created locally. This field
+          is empty if the image was pulled from an image registry.
+        type: "string"
+        x-nullable: false
+        example: ""
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Created:
+        description: |
+          Date and time at which the image was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        x-nullable: false
+        example: "1644009612"
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 172064416
+      SharedSize:
+        description: |
+          Total size of image layers that are shared between this image and other
+          images.
+
+          This size is not calculated by default. `-1` indicates that the value
+          has not been set / calculated.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Containers:
+        description: |
+          Number of containers using this image. Includes both stopped and running
+          containers.
+
+          `-1` indicates that the value has not been set / calculated.
+        x-nullable: false
+        type: "integer"
+        example: 2
+      Manifests:
+        description: |
+          Manifests is a list of manifests available in this image.
+          It provides a more detailed view of the platform-specific image manifests
+          or other image-attached data like build attestations.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        type: "array"
+        x-nullable: false
+        x-omitempty: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+
+  ImagesDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/image"
+    description: |
+      represents system data usage for image resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active images.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all images.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing unused images.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by images.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of image summaries.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Summary
+
+  AuthConfig:
+    type: "object"
+    properties:
+      username:
+        type: "string"
+      password:
+        type: "string"
+      serveraddress:
+        type: "string"
+    example:
+      username: "hannibal"
+      password: "xxxx"
+      serveraddress: "https://index.docker.io/v1/"
+
+  AuthResponse:
+    description: |
+      An identity token was generated successfully.
+    type: "object"
+    required: [Status]
+    properties:
+      Status:
+        description: "The status of the authentication"
+        type: "string"
+        example: "Login Succeeded"
+        x-nullable: false
+      IdentityToken:
+        description: "An opaque token used to authenticate a user after a successful login"
+        type: "string"
+        example: "9cbaf023786cd7..."
+        x-nullable: false
+
+  ProcessConfig:
+    type: "object"
+    properties:
+      privileged:
+        type: "boolean"
+      user:
+        type: "string"
+      tty:
+        type: "boolean"
+      entrypoint:
+        type: "string"
+      arguments:
+        type: "array"
+        items:
+          type: "string"
+
+  Volume:
+    type: "object"
+    required: [Name, Driver, Mountpoint, Labels, Scope, Options]
+    x-nullable: false
+    properties:
+      Name:
+        type: "string"
+        description: "Name of the volume."
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        type: "string"
+        description: "Name of the volume driver used by the volume."
+        x-nullable: false
+        example: "custom"
+      Mountpoint:
+        type: "string"
+        description: "Mount path of the volume on the host."
+        x-nullable: false
+        example: "/var/lib/docker/volumes/tardis"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        description: "Date/Time the volume was created."
+        example: "2016-06-07T20:31:11.853781916Z"
+      Status:
+        type: "object"
+        description: |
+          Low-level details about the volume, provided by the volume driver.
+          Details are returned as a map with key/value pairs:
+          `{"key":"value","key2":"value2"}`.
+
+          The `Status` field is optional, and is omitted if the volume driver
+          does not support this feature.
+        additionalProperties:
+          type: "object"
+        example:
+          hello: "world"
+      Labels:
+        type: "object"
+        description: "User-defined key/value metadata."
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Scope:
+        type: "string"
+        description: |
+          The level at which the volume exists. Either `global` for cluster-wide,
+          or `local` for machine level.
+        default: "local"
+        x-nullable: false
+        enum: ["local", "global"]
+        example: "local"
+      ClusterVolume:
+        $ref: "#/definitions/ClusterVolume"
+      Options:
+        type: "object"
+        description: |
+          The driver specific options used when creating the volume.
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      UsageData:
+        type: "object"
+        x-nullable: true
+        x-go-name: "UsageData"
+        required: [Size, RefCount]
+        description: |
+          Usage details about the volume. This information is used by the
+          `GET /system/df` endpoint, and omitted in other endpoints.
+        properties:
+          Size:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              Amount of disk space used by the volume (in bytes). This information
+              is only available for volumes created with the `"local"` volume
+              driver. For volumes created with other volume drivers, this field
+              is set to `-1` ("not available")
+            x-nullable: false
+          RefCount:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              The number of containers referencing this volume. This field
+              is set to `-1` if the reference-count is not available.
+            x-nullable: false
+
+  VolumesDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/volume"
+    description: |
+      represents system data usage for volume resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active volumes.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all volumes.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive volumes.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by volumes.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of volumes.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Volume
+
+  VolumeCreateRequest:
+    description: "Volume configuration"
+    type: "object"
+    title: "VolumeConfig"
+    x-go-name: "CreateRequest"
+    properties:
+      Name:
+        description: |
+          The new volume's name. If not specified, Docker generates a name.
+        type: "string"
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        description: "Name of the volume driver to use."
+        type: "string"
+        default: "local"
+        x-nullable: false
+        example: "custom"
+      DriverOpts:
+        description: |
+          A mapping of driver options and values. These options are
+          passed directly to the driver and are driver specific.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      ClusterVolumeSpec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+
+  VolumeListResponse:
+    type: "object"
+    title: "VolumeListResponse"
+    x-go-name: "ListResponse"
+    description: "Volume list response"
+    properties:
+      Volumes:
+        type: "array"
+        description: "List of volumes"
+        items:
+          $ref: "#/definitions/Volume"
+      Warnings:
+        type: "array"
+        description: |
+          Warnings that occurred when fetching the list of volumes.
+        items:
+          type: "string"
+        example: []
+
+  Network:
+    type: "object"
+    properties:
+      Name:
+        description: |
+          Name of the network.
+        type: "string"
+        example: "my_network"
+        x-omitempty: false
+      Id:
+        description: |
+          ID that uniquely identifies a network on a single machine.
+        type: "string"
+        x-go-name: "ID"
+        x-omitempty: false
+        example: "7d86d31b1478e7cca9ebed7e73aa0fdeec46c5ca29497431d3007d2d9e15ed99"
+      Created:
+        description: |
+          Date and time at which the network was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-omitempty: false
+        x-go-type:
+          type: Time
+          import:
+            package: time
+          hints:
+            nullable: false
+        example: "2016-10-19T04:33:30.360899459Z"
+      Scope:
+        description: |
+          The level at which the network exists (e.g. `swarm` for cluster-wide
+          or `local` for machine level)
+        type: "string"
+        x-omitempty: false
+        example: "local"
+      Driver:
+        description: |
+          The name of the driver used to create the network (e.g. `bridge`,
+          `overlay`).
+        type: "string"
+        x-omitempty: false
+        example: "overlay"
+      EnableIPv4:
+        description: |
+          Whether the network was created with IPv4 enabled.
+        type: "boolean"
+        x-omitempty: false
+        example: true
+      EnableIPv6:
+        description: |
+          Whether the network was created with IPv6 enabled.
+        type: "boolean"
+        x-omitempty: false
+        example: false
+      IPAM:
+        description: |
+          The network's IP Address Management.
+        $ref: "#/definitions/IPAM"
+        x-nullable: false
+        x-omitempty: false
+      Internal:
+        description: |
+          Whether the network is created to only allow internal networking
+          connectivity.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      Attachable:
+        description: |
+          Whether a global / swarm scope network is manually attachable by regular
+          containers from workers in swarm mode.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      Ingress:
+        description: |
+          Whether the network is providing the routing-mesh for the swarm cluster.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      ConfigFrom:
+        $ref: "#/definitions/ConfigReference"
+        x-nullable: false
+        x-omitempty: false
+      ConfigOnly:
+        description: |
+          Whether the network is a config-only network. Config-only networks are
+          placeholder networks for network configurations to be used by other
+          networks. Config-only networks cannot be used directly to run containers
+          or services.
+        type: "boolean"
+        x-omitempty: false
+        x-nullable: false
+        default: false
+      Options:
+        description: |
+          Network-specific options uses when creating the network.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.docker.network.bridge.default_bridge: "true"
+          com.docker.network.bridge.enable_icc: "true"
+          com.docker.network.bridge.enable_ip_masquerade: "true"
+          com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+          com.docker.network.bridge.name: "docker0"
+          com.docker.network.driver.mtu: "1500"
+      Labels:
+        description: |
+          Metadata specific to the network being created.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Peers:
+        description: |
+          List of peer nodes for an overlay network. This field is only present
+          for overlay networks, and omitted for other network types.
+        type: "array"
+        x-omitempty: true
+        items:
+          $ref: "#/definitions/PeerInfo"
+
+  NetworkSummary:
+    description: "Network list response item"
+    x-go-name: Summary
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/Network"
+
+  NetworkInspect:
+    description: 'The body of the "get network" http response message.'
+    x-go-name: Inspect
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/Network"
+    properties:
+      Containers:
+        description: |
+          Contains endpoints attached to the network.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          $ref: "#/definitions/EndpointResource"
+        example:
+          19a4d5d687db25203351ed79d478946f861258f018fe384f229f2efa4b23513c:
+            Name: "test"
+            EndpointID: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+            MacAddress: "02:42:ac:13:00:02"
+            IPv4Address: "172.19.0.2/16"
+            IPv6Address: ""
+      Services:
+        description: |
+          List of services using the network. This field is only present for
+          swarm scope networks, and omitted for local scope networks.
+        type: "object"
+        x-omitempty: true
+        additionalProperties:
+          x-go-type:
+            type: ServiceInfo
+            hints:
+              nullable: false
+      Status:
+        description: >
+          provides runtime information about the network
+          such as the number of allocated IPs.
+        $ref: "#/definitions/NetworkStatus"
+
+  NetworkStatus:
+    description: >
+      provides runtime information about the network
+      such as the number of allocated IPs.
+    type: "object"
+    x-go-name: Status
+    properties:
+      IPAM:
+        $ref: "#/definitions/IPAMStatus"
+
+  ServiceInfo:
+    x-nullable: false
+    x-omitempty: false
+    description: >
+      represents service parameters with the list of service's tasks
+    type: "object"
+    properties:
+      VIP:
+        type: "string"
+        x-omitempty: false
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      Ports:
+        type: "array"
+        x-omitempty: false
+        items:
+          type: "string"
+      LocalLBIndex:
+        type: "integer"
+        format: "int"
+        x-omitempty: false
+        x-go-type:
+          type: int
+      Tasks:
+        type: "array"
+        x-omitempty: false
+        items:
+          $ref: "#/definitions/NetworkTaskInfo"
+
+  NetworkTaskInfo:
+    x-nullable: false
+    x-omitempty: false
+    x-go-name: Task
+    description: >
+      carries the information about one backend task
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        x-omitempty: false
+      EndpointID:
+        type: "string"
+        x-omitempty: false
+      EndpointIP:
+        type: "string"
+        x-omitempty: false
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      Info:
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+
+  ConfigReference:
+    x-nullable: false
+    x-omitempty: false
+    description: |
+      The config-only network source to provide the configuration for
+      this network.
+    type: "object"
+    properties:
+      Network:
+        description: |
+          The name of the config-only network that provides the network's
+          configuration. The specified network must be an existing config-only
+          network. Only network names are allowed, not network IDs.
+        type: "string"
+        x-omitempty: false
+        example: "config_only_network_01"
+
+  IPAM:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      Driver:
+        description: "Name of the IPAM driver to use."
+        type: "string"
+        default: "default"
+        example: "default"
+      Config:
+        description: |
+          List of IPAM configuration options, specified as a map:
+
+          ```
+          {"Subnet": <CIDR>, "IPRange": <CIDR>, "Gateway": <IP address>, "AuxAddress": <device_name:IP address>}
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/IPAMConfig"
+      Options:
+        description: "Driver-specific options, specified as a map."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+
+  IPAMConfig:
+    type: "object"
+    properties:
+      Subnet:
+        type: "string"
+        example: "172.20.0.0/16"
+      IPRange:
+        type: "string"
+        example: "172.20.10.0/24"
+      Gateway:
+        type: "string"
+        example: "172.20.10.11"
+      AuxiliaryAddresses:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  IPAMStatus:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      Subnets:
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/SubnetStatus"
+        example:
+          "172.16.0.0/16":
+            IPsInUse: 3
+            DynamicIPsAvailable: 65533
+          "2001:db8:abcd:0012::0/96":
+            IPsInUse: 5
+            DynamicIPsAvailable: 4294967291
+        x-go-type:
+          type: SubnetStatuses
+          kind: map
+
+  SubnetStatus:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      IPsInUse:
+        description: >
+          Number of IP addresses in the subnet that are in use or reserved and
+          are therefore unavailable for allocation, saturating at 2<sup>64</sup> - 1.
+        type: integer
+        format: uint64
+        x-omitempty: false
+      DynamicIPsAvailable:
+        description: >
+          Number of IP addresses within the network's IPRange for the subnet
+          that are available for allocation, saturating at 2<sup>64</sup> - 1.
+        type: integer
+        format: uint64
+        x-omitempty: false
+
+  EndpointResource:
+    type: "object"
+    description: >
+      contains network resources allocated and used for a
+      container in a network.
+    properties:
+      Name:
+        type: "string"
+        x-omitempty: false
+        example: "container_1"
+      EndpointID:
+        type: "string"
+        x-omitempty: false
+        example: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+      MacAddress:
+        type: "string"
+        x-omitempty: false
+        example: "02:42:ac:13:00:02"
+        x-go-type:
+          type: HardwareAddr
+      IPv4Address:
+        type: "string"
+        x-omitempty: false
+        example: "172.19.0.2/16"
+        x-go-type:
+          type: Prefix
+          import:
+            package: net/netip
+      IPv6Address:
+        type: "string"
+        x-omitempty: false
+        example: ""
+        x-go-type:
+          type: Prefix
+          import:
+            package: net/netip
+
+  PeerInfo:
+    description: >
+      represents one peer of an overlay network.
+    type: "object"
+    x-nullable: false
+    properties:
+      Name:
+        description:
+          ID of the peer-node in the Swarm cluster.
+        type: "string"
+        x-omitempty: false
+        example: "6869d7c1732b"
+      IP:
+        description:
+          IP-address of the peer-node in the Swarm cluster.
+        type: "string"
+        x-omitempty: false
+        example: "10.133.77.91"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+
+  NetworkCreateResponse:
+    description: "OK response to NetworkCreate operation"
+    type: "object"
+    title: "NetworkCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warning]
+    properties:
+      Id:
+        description: "The ID of the created network."
+        type: "string"
+        x-nullable: false
+        example: "b5c4fc71e8022147cd25de22b22173de4e3b170134117172eb595cb91b4e7e5d"
+      Warning:
+        description: "Warnings encountered when creating the container"
+        type: "string"
+        x-nullable: false
+        example: ""
+
+  BuildInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      stream:
+        type: "string"
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+      aux:
+        $ref: "#/definitions/ImageID"
+
+  BuildCache:
+    type: "object"
+    description: |
+      BuildCache contains information about a build cache record.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          Unique ID of the build cache record.
+        example: "ndlpt0hhvkqcdfkputsk4cq9c"
+      Parents:
+        description: |
+          List of parent build cache record IDs.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example: ["hw53o5aio51xtltp5xjp8v7fx"]
+      Type:
+        type: "string"
+        description: |
+          Cache record type.
+        example: "regular"
+        # see https://github.com/moby/buildkit/blob/fce4a32258dc9d9664f71a4831d5de10f0670677/client/diskusage.go#L75-L84
+        enum:
+          - "internal"
+          - "frontend"
+          - "source.local"
+          - "source.git.checkout"
+          - "exec.cachemount"
+          - "regular"
+      Description:
+        type: "string"
+        description: |
+          Description of the build-step that produced the build cache.
+        example: "mount / from exec /bin/sh -c echo 'Binary::apt::APT::Keep-Downloaded-Packages \"true\";' > /etc/apt/apt.conf.d/keep-cache"
+      InUse:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is in use.
+        example: false
+      Shared:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is shared.
+        example: true
+      Size:
+        description: |
+          Amount of disk space used by the build cache (in bytes).
+        type: "integer"
+        example: 51
+      CreatedAt:
+        description: |
+          Date and time at which the build cache was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      LastUsedAt:
+        description: |
+          Date and time at which the build cache was last used in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2017-08-09T07:09:37.632105588Z"
+      UsageCount:
+        type: "integer"
+        example: 26
+
+  BuildCacheDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/build"
+    description: |
+      represents system data usage for build cache resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active build cache records.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all build cache records.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive build cache records.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by build cache records.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of build cache records.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: CacheRecord
+
+  ImageID:
+    type: "object"
+    description: "Image ID or Digest"
+    properties:
+      ID:
+        type: "string"
+    example:
+      ID: "sha256:85f05633ddc1c50679be2b16a0479ab6f7637f8884e0cfe0f4d20e1ebb3d6e7c"
+
+  CreateImageInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  PushImageInfo:
+    type: "object"
+    properties:
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  DeviceInfo:
+    type: "object"
+    description: |
+      DeviceInfo represents a device that can be used by a container.
+    properties:
+      Source:
+        type: "string"
+        example: "cdi"
+        description: |
+          The origin device driver.
+      ID:
+        type: "string"
+        example: "vendor.com/gpu=0"
+        description: |
+          The unique identifier for the device within its source driver.
+          For CDI devices, this would be an FQDN like "vendor.com/gpu=0".
+
+  ErrorDetail:
+    type: "object"
+    properties:
+      code:
+        type: "integer"
+      message:
+        type: "string"
+
+  ProgressDetail:
+    type: "object"
+    properties:
+      current:
+        type: "integer"
+      total:
+        type: "integer"
+
+  ErrorResponse:
+    description: "Represents an error."
+    type: "object"
+    required: ["message"]
+    properties:
+      message:
+        description: "The error message."
+        type: "string"
+        x-nullable: false
+    example:
+      message: "Something went wrong."
+
+  IDResponse:
+    description: "Response to an API call that returns just an Id"
+    type: "object"
+    x-go-name: "IDResponse"
+    required: ["Id"]
+    properties:
+      Id:
+        description: "The id of the newly created object."
+        type: "string"
+        x-nullable: false
+
+  NetworkConnectRequest:
+    description: |
+      NetworkConnectRequest represents the data to be used to connect a container to a network.
+    type: "object"
+    x-go-name: "ConnectRequest"
+    required: ["Container"]
+    properties:
+      Container:
+        type: "string"
+        description: "The ID or name of the container to connect to the network."
+        x-nullable: false
+        example: "3613f73ba0e4"
+      EndpointConfig:
+        $ref: "#/definitions/EndpointSettings"
+        x-nullable: true
+
+  NetworkDisconnectRequest:
+    description: |
+      NetworkDisconnectRequest represents the data to be used to disconnect a container from a network.
+    type: "object"
+    x-go-name: "DisconnectRequest"
+    required: ["Container"]
+    properties:
+      Container:
+        type: "string"
+        description: "The ID or name of the container to disconnect from the network."
+        x-nullable: false
+        example: "3613f73ba0e4"
+      Force:
+        type: "boolean"
+        description: "Force the container to disconnect from the network."
+        default: false
+        x-nullable: false
+        x-omitempty: false
+        example: false
+
+  EndpointSettings:
+    description: "Configuration for a network endpoint."
+    type: "object"
+    properties:
+      # Configurations
+      IPAMConfig:
+        $ref: "#/definitions/EndpointIPAMConfig"
+      Links:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "container_1"
+          - "container_2"
+      MacAddress:
+        description: |
+          MAC address for the endpoint on this network. The network driver might ignore this parameter.
+        type: "string"
+        example: "02:42:ac:11:00:04"
+        x-go-type:
+          type: HardwareAddr
+      Aliases:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "server_x"
+          - "server_y"
+      DriverOpts:
+        description: |
+          DriverOpts is a mapping of driver options and values. These options
+          are passed directly to the driver and are driver specific.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      GwPriority:
+        description: |
+          This property determines which endpoint will provide the default
+          gateway for a container. The endpoint with the highest priority will
+          be used. If multiple endpoints have the same priority, endpoints are
+          lexicographically sorted based on their network name, and the one
+          that sorts first is picked.
+        type: "integer"
+        format: "int64"
+        example:
+          - 10
+
+      # Operational data
+      NetworkID:
+        description: |
+          Unique ID of the network.
+        type: "string"
+        example: "08754567f1f40222263eab4102e1c733ae697e8e354aa9cd6e18d7402835292a"
+      EndpointID:
+        description: |
+          Unique ID for the service endpoint in a Sandbox.
+        type: "string"
+        example: "b88f5b905aabf2893f3cbc4ee42d1ea7980bbc0a92e2c8922b1e1795298afb0b"
+      Gateway:
+        description: |
+          Gateway address for this network.
+        type: "string"
+        example: "172.17.0.1"
+      IPAddress:
+        description: |
+          IPv4 address.
+        type: "string"
+        example: "172.17.0.4"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      IPPrefixLen:
+        description: |
+          Mask length of the IPv4 address.
+        type: "integer"
+        example: 16
+      IPv6Gateway:
+        description: |
+          IPv6 gateway address.
+        type: "string"
+        example: "2001:db8:2::100"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      GlobalIPv6Address:
+        description: |
+          Global IPv6 address.
+        type: "string"
+        example: "2001:db8::5689"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      GlobalIPv6PrefixLen:
+        description: |
+          Mask length of the global IPv6 address.
+        type: "integer"
+        format: "int64"
+        example: 64
+      DNSNames:
+        description: |
+          List of all DNS names an endpoint has on a specific network. This
+          list is based on the container name, network aliases, container short
+          ID, and hostname.
+
+          These DNS names are non-fully qualified but can contain several dots.
+          You can get fully qualified DNS names by appending `.<network-name>`.
+          For instance, if container name is `my.ctr` and the network is named
+          `testnet`, `DNSNames` will contain `my.ctr` and the FQDN will be
+          `my.ctr.testnet`.
+        type: array
+        items:
+          type: string
+        example: ["foobar", "server_x", "server_y", "my.ctr"]
+
+  EndpointIPAMConfig:
+    description: |
+      EndpointIPAMConfig represents an endpoint's IPAM configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      IPv4Address:
+        type: "string"
+        example: "172.20.30.33"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      IPv6Address:
+        type: "string"
+        example: "2001:db8:abcd::3033"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      LinkLocalIPs:
+        type: "array"
+        items:
+          type: "string"
+          x-go-type:
+            type: Addr
+            import:
+              package: net/netip
+        example:
+          - "169.254.34.68"
+          - "fe80::3468"
+
+  PluginMount:
+    type: "object"
+    x-go-name: "Mount"
+    x-nullable: false
+    required: [Name, Description, Settable, Source, Destination, Type, Options]
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "some-mount"
+      Description:
+        type: "string"
+        x-nullable: false
+        example: "This is a mount that's used by the plugin."
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Source:
+        type: "string"
+        example: "/var/lib/docker/plugins/"
+      Destination:
+        type: "string"
+        x-nullable: false
+        example: "/mnt/state"
+      Type:
+        type: "string"
+        x-nullable: false
+        example: "bind"
+      Options:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "rbind"
+          - "rw"
+
+  PluginDevice:
+    type: "object"
+    x-go-name: "Device"
+    required: [Name, Description, Settable, Path]
+    x-nullable: false
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+      Description:
+        type: "string"
+        x-nullable: false
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Path:
+        type: "string"
+        example: "/dev/fuse"
+
+  PluginEnv:
+    type: "object"
+    x-go-name: "Env"
+    x-nullable: false
+    required: [Name, Description, Settable, Value]
+    properties:
+      Name:
+        x-nullable: false
+        type: "string"
+      Description:
+        x-nullable: false
+        type: "string"
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Value:
+        type: "string"
+
+  PluginPrivilege:
+    description: |
+      Describes a permission the user has to accept upon installing
+      the plugin.
+    type: "object"
+    x-go-name: "Privilege"
+    properties:
+      Name:
+        type: "string"
+        example: "network"
+      Description:
+        type: "string"
+      Value:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "host"
+
+  Plugin:
+    description: "A plugin for the Engine API"
+    type: "object"
+    x-go-name: "Plugin"
+    required: [Settings, Enabled, Config, Name]
+    properties:
+      Id:
+        type: "string"
+        example: "5724e2c8652da337ab2eedd19fc6fc0ec908e4bd907c7421bf6a8dfc70c4c078"
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "tiborvass/sample-volume-plugin"
+      Enabled:
+        description:
+          True if the plugin is running. False if the plugin is not running,
+          only installed.
+        type: "boolean"
+        x-nullable: false
+        example: true
+      Settings:
+        description: "user-configurable settings for the plugin."
+        type: "object"
+        x-go-name: "Settings"
+        x-nullable: false
+        required: [Args, Devices, Env, Mounts]
+        properties:
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "DEBUG=0"
+          Args:
+            type: "array"
+            items:
+              type: "string"
+          Devices:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginDevice"
+      PluginReference:
+        description: "plugin remote reference used to push/pull the plugin"
+        type: "string"
+        x-go-name: "PluginReference"
+        x-nullable: false
+        example: "localhost:5000/tiborvass/sample-volume-plugin:latest"
+      Config:
+        description: "The config of a plugin."
+        type: "object"
+        x-go-name: "Config"
+        x-nullable: false
+        required:
+          - Description
+          - Documentation
+          - Interface
+          - Entrypoint
+          - WorkDir
+          - Network
+          - Linux
+          - PidHost
+          - PropagatedMount
+          - IpcHost
+          - Mounts
+          - Env
+          - Args
+        properties:
+          Description:
+            type: "string"
+            x-nullable: false
+            example: "A sample volume plugin for Docker"
+          Documentation:
+            type: "string"
+            x-nullable: false
+            example: "https://docs.docker.com/engine/extend/plugins/"
+          Interface:
+            description: "The interface between Docker and the plugin"
+            x-nullable: false
+            type: "object"
+            x-go-name: "Interface"
+            required: [Types, Socket]
+            properties:
+              Types:
+                type: "array"
+                items:
+                  type: "string"
+                  x-go-type:
+                    type: "CapabilityID"
+                example:
+                  - "docker.volumedriver/1.0"
+              Socket:
+                type: "string"
+                x-nullable: false
+                example: "plugins.sock"
+              ProtocolScheme:
+                type: "string"
+                example: "some.protocol/v1.0"
+                description: "Protocol to use for clients connecting to the plugin."
+                enum:
+                  - ""
+                  - "moby.plugins.http/v1"
+          Entrypoint:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "/usr/bin/sample-volume-plugin"
+              - "/data"
+          WorkDir:
+            type: "string"
+            x-nullable: false
+            example: "/bin/"
+          User:
+            type: "object"
+            x-go-name: "User"
+            x-nullable: false
+            properties:
+              UID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+              GID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+          Network:
+            type: "object"
+            x-go-name: "NetworkConfig"
+            x-nullable: false
+            required: [Type]
+            properties:
+              Type:
+                x-nullable: false
+                type: "string"
+                example: "host"
+          Linux:
+            type: "object"
+            x-go-name: "LinuxConfig"
+            x-nullable: false
+            required: [Capabilities, AllowAllDevices, Devices]
+            properties:
+              Capabilities:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "CAP_SYS_ADMIN"
+                  - "CAP_SYSLOG"
+              AllowAllDevices:
+                type: "boolean"
+                x-nullable: false
+                example: false
+              Devices:
+                type: "array"
+                items:
+                  $ref: "#/definitions/PluginDevice"
+          PropagatedMount:
+            type: "string"
+            x-nullable: false
+            example: "/mnt/volumes"
+          IpcHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          PidHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginEnv"
+            example:
+              - Name: "DEBUG"
+                Description: "If set, prints debug messages"
+                Settable: null
+                Value: "0"
+          Args:
+            type: "object"
+            x-go-name: "Args"
+            x-nullable: false
+            required: [Name, Description, Settable, Value]
+            properties:
+              Name:
+                x-nullable: false
+                type: "string"
+                example: "args"
+              Description:
+                x-nullable: false
+                type: "string"
+                example: "command line arguments"
+              Settable:
+                type: "array"
+                items:
+                  type: "string"
+              Value:
+                type: "array"
+                items:
+                  type: "string"
+          rootfs:
+            type: "object"
+            x-go-name: "RootFS"
+            properties:
+              type:
+                type: "string"
+                example: "layers"
+              diff_ids:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "sha256:675532206fbf3030b8458f88d6e26d4eb1577688a25efec97154c94e8b6b4887"
+                  - "sha256:e216a057b1cb1efc11f8a268f37ef62083e70b1b38323ba252e25ac88904a7e8"
+
+  ObjectVersion:
+    description: |
+      The version number of the object such as node, service, etc. This is needed
+      to avoid conflicting writes. The client must send the version number along
+      with the modified specification when updating these objects.
+
+      This approach ensures safe concurrency and determinism in that the change
+      on the object may not be applied if the version number has changed from the
+      last read. In other words, if two update requests specify the same base
+      version, only one of the requests can succeed. As a result, two separate
+      update requests that happen at the same time will not unintentionally
+      overwrite each other.
+    type: "object"
+    properties:
+      Index:
+        type: "integer"
+        format: "uint64"
+        example: 373531
+
+  NodeSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "Name for the node."
+        type: "string"
+        example: "my-node"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Role:
+        description: "Role of the node."
+        type: "string"
+        enum:
+          - "worker"
+          - "manager"
+        example: "manager"
+      Availability:
+        description: "Availability of the node."
+        type: "string"
+        enum:
+          - "active"
+          - "pause"
+          - "drain"
+        example: "active"
+    example:
+      Availability: "active"
+      Name: "node-name"
+      Role: "manager"
+      Labels:
+        foo: "bar"
+
+  Node:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "24ifsmvkjbyhk"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the node was added to the swarm in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the node was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/NodeSpec"
+      Description:
+        $ref: "#/definitions/NodeDescription"
+      Status:
+        $ref: "#/definitions/NodeStatus"
+      ManagerStatus:
+        $ref: "#/definitions/ManagerStatus"
+
+  NodeDescription:
+    description: |
+      NodeDescription encapsulates the properties of the Node as reported by the
+      agent.
+    type: "object"
+    properties:
+      Hostname:
+        type: "string"
+        example: "bf3067039e47"
+      Platform:
+        $ref: "#/definitions/Platform"
+      Resources:
+        $ref: "#/definitions/ResourceObject"
+      Engine:
+        $ref: "#/definitions/EngineDescription"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+
+  Platform:
+    description: |
+      Platform represents the platform (Arch/OS).
+    type: "object"
+    properties:
+      Architecture:
+        description: |
+          Architecture represents the hardware architecture (for example,
+          `x86_64`).
+        type: "string"
+        example: "x86_64"
+      OS:
+        description: |
+          OS represents the Operating System (for example, `linux` or `windows`).
+        type: "string"
+        example: "linux"
+
+  EngineDescription:
+    description: "EngineDescription provides information about an engine."
+    type: "object"
+    properties:
+      EngineVersion:
+        type: "string"
+        example: "17.06.0"
+      Labels:
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+      Plugins:
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Type:
+              type: "string"
+            Name:
+              type: "string"
+        example:
+          - Type: "Log"
+            Name: "awslogs"
+          - Type: "Log"
+            Name: "fluentd"
+          - Type: "Log"
+            Name: "gcplogs"
+          - Type: "Log"
+            Name: "gelf"
+          - Type: "Log"
+            Name: "journald"
+          - Type: "Log"
+            Name: "json-file"
+          - Type: "Log"
+            Name: "splunk"
+          - Type: "Log"
+            Name: "syslog"
+          - Type: "Network"
+            Name: "bridge"
+          - Type: "Network"
+            Name: "host"
+          - Type: "Network"
+            Name: "ipvlan"
+          - Type: "Network"
+            Name: "macvlan"
+          - Type: "Network"
+            Name: "null"
+          - Type: "Network"
+            Name: "overlay"
+          - Type: "Volume"
+            Name: "local"
+          - Type: "Volume"
+            Name: "localhost:5000/vieux/sshfs:latest"
+          - Type: "Volume"
+            Name: "vieux/sshfs:latest"
+
+  TLSInfo:
+    description: |
+      Information about the issuer of leaf TLS certificates and the trusted root
+      CA certificate.
+    type: "object"
+    properties:
+      TrustRoot:
+        description: |
+          The root CA certificate(s) that are used to validate leaf TLS
+          certificates.
+        type: "string"
+      CertIssuerSubject:
+        description:
+          The base64-url-safe-encoded raw subject bytes of the issuer.
+        type: "string"
+      CertIssuerPublicKey:
+        description: |
+          The base64-url-safe-encoded raw public key bytes of the issuer.
+        type: "string"
+    example:
+      TrustRoot: |
+        -----BEGIN CERTIFICATE-----
+        MIIBajCCARCgAwIBAgIUbYqrLSOSQHoxD8CwG6Bi2PJi9c8wCgYIKoZIzj0EAwIw
+        EzERMA8GA1UEAxMIc3dhcm0tY2EwHhcNMTcwNDI0MjE0MzAwWhcNMzcwNDE5MjE0
+        MzAwWjATMREwDwYDVQQDEwhzd2FybS1jYTBZMBMGByqGSM49AgEGCCqGSM49AwEH
+        A0IABJk/VyMPYdaqDXJb/VXh5n/1Yuv7iNrxV3Qb3l06XD46seovcDWs3IZNV1lf
+        3Skyr0ofcchipoiHkXBODojJydSjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB
+        Af8EBTADAQH/MB0GA1UdDgQWBBRUXxuRcnFjDfR/RIAUQab8ZV/n4jAKBggqhkjO
+        PQQDAgNIADBFAiAy+JTe6Uc3KyLCMiqGl2GyWGQqQDEcO3/YG36x7om65AIhAJvz
+        pxv6zFeVEkAEEkqIYi0omA9+CjanB/6Bz4n1uw8H
+        -----END CERTIFICATE-----
+      CertIssuerSubject: "MBMxETAPBgNVBAMTCHN3YXJtLWNh"
+      CertIssuerPublicKey: "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmT9XIw9h1qoNclv9VeHmf/Vi6/uI2vFXdBveXTpcPjqx6i9wNazchk1XWV/dKTKvSh9xyGKmiIeRcE4OiMnJ1A=="
+
+  NodeStatus:
+    description: |
+      NodeStatus represents the status of a node.
+
+      It provides the current status of the node, as seen by the manager.
+    type: "object"
+    properties:
+      State:
+        $ref: "#/definitions/NodeState"
+      Message:
+        type: "string"
+        example: ""
+      Addr:
+        description: "IP address of the node."
+        type: "string"
+        example: "172.17.0.2"
+
+  NodeState:
+    description: "NodeState represents the state of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "down"
+      - "ready"
+      - "disconnected"
+    example: "ready"
+
+  ManagerStatus:
+    description: |
+      ManagerStatus represents the status of a manager.
+
+      It provides the current status of a node's manager component, if the node
+      is a manager.
+    x-nullable: true
+    type: "object"
+    properties:
+      Leader:
+        type: "boolean"
+        default: false
+        example: true
+      Reachability:
+        $ref: "#/definitions/Reachability"
+      Addr:
+        description: |
+          The IP address and port at which the manager is reachable.
+        type: "string"
+        example: "10.0.0.46:2377"
+
+  Reachability:
+    description: "Reachability represents the reachability of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "unreachable"
+      - "reachable"
+    example: "reachable"
+
+  SwarmSpec:
+    description: "User modifiable swarm configuration."
+    type: "object"
+    properties:
+      Name:
+        description: "Name of the swarm."
+        type: "string"
+        example: "default"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.corp.type: "production"
+          com.example.corp.department: "engineering"
+      Orchestration:
+        description: "Orchestration configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          TaskHistoryRetentionLimit:
+            description: |
+              The number of historic tasks to keep per instance or node. If
+              negative, never remove completed or failed tasks.
+            type: "integer"
+            format: "int64"
+            example: 10
+      Raft:
+        description: "Raft configuration."
+        type: "object"
+        properties:
+          SnapshotInterval:
+            description: "The number of log entries between snapshots."
+            type: "integer"
+            format: "uint64"
+            example: 10000
+          KeepOldSnapshots:
+            description: |
+              The number of snapshots to keep beyond the current snapshot.
+            type: "integer"
+            format: "uint64"
+          LogEntriesForSlowFollowers:
+            description: |
+              The number of log entries to keep around to sync up slow followers
+              after a snapshot is created.
+            type: "integer"
+            format: "uint64"
+            example: 500
+          ElectionTick:
+            description: |
+              The number of ticks that a follower will wait for a message from
+              the leader before becoming a candidate and starting an election.
+              `ElectionTick` must be greater than `HeartbeatTick`.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 3
+          HeartbeatTick:
+            description: |
+              The number of ticks between heartbeats. Every HeartbeatTick ticks,
+              the leader will send a heartbeat to the followers.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 1
+      Dispatcher:
+        description: "Dispatcher configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          HeartbeatPeriod:
+            description: |
+              The delay for an agent to send a heartbeat to the dispatcher.
+            type: "integer"
+            format: "int64"
+            example: 5000000000
+      CAConfig:
+        description: "CA configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          NodeCertExpiry:
+            description: "The duration node certificates are issued for."
+            type: "integer"
+            format: "int64"
+            example: 7776000000000000
+          ExternalCAs:
+            description: |
+              Configuration for forwarding signing requests to an external
+              certificate authority.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Protocol:
+                  description: |
+                    Protocol for communication with the external CA (currently
+                    only `cfssl` is supported).
+                  type: "string"
+                  enum:
+                    - "cfssl"
+                  default: "cfssl"
+                URL:
+                  description: |
+                    URL where certificate signing requests should be sent.
+                  type: "string"
+                Options:
+                  description: |
+                    An object with key/value pairs that are interpreted as
+                    protocol-specific options for the external CA driver.
+                  type: "object"
+                  additionalProperties:
+                    type: "string"
+                CACert:
+                  description: |
+                    The root CA certificate (in PEM format) this external CA uses
+                    to issue TLS certificates (assumed to be to the current swarm
+                    root CA certificate if not provided).
+                  type: "string"
+          SigningCACert:
+            description: |
+              The desired signing CA certificate for all swarm node TLS leaf
+              certificates, in PEM format.
+            type: "string"
+          SigningCAKey:
+            description: |
+              The desired signing CA key for all swarm node TLS leaf certificates,
+              in PEM format.
+            type: "string"
+          ForceRotate:
+            description: |
+              An integer whose purpose is to force swarm to generate a new
+              signing CA certificate and key, if none have been specified in
+              `SigningCACert` and `SigningCAKey`
+            format: "uint64"
+            type: "integer"
+      EncryptionConfig:
+        description: "Parameters related to encryption-at-rest."
+        type: "object"
+        properties:
+          AutoLockManagers:
+            description: |
+              If set, generate a key and use it to lock data stored on the
+              managers.
+            type: "boolean"
+            example: false
+      TaskDefaults:
+        description: "Defaults for creating tasks in this cluster."
+        type: "object"
+        properties:
+          LogDriver:
+            description: |
+              The log driver to use for tasks created in the orchestrator if
+              unspecified by a service.
+
+              Updating this value only affects new tasks. Existing tasks continue
+              to use their previously configured log driver until recreated.
+            type: "object"
+            properties:
+              Name:
+                description: |
+                  The log driver to use as a default for new tasks.
+                type: "string"
+                example: "json-file"
+              Options:
+                description: |
+                  Driver-specific options for the selected log driver, specified
+                  as key/value pairs.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "10"
+                  "max-size": "100m"
+
+  # The Swarm information for `GET /info`. It is the same as `GET /swarm`, but
+  # without `JoinTokens`.
+  ClusterInfo:
+    description: |
+      ClusterInfo represents information about the swarm as is returned by the
+      "/info" endpoint. Join-tokens are not included.
+    x-nullable: true
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the swarm."
+        type: "string"
+        example: "abajmipo7b4xz5ip2nrla6b11"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the swarm was initialised in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the swarm was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/SwarmSpec"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+      RootRotationInProgress:
+        description: |
+          Whether there is currently a root CA rotation in progress for the swarm
+        type: "boolean"
+        example: false
+      DataPathPort:
+        description: |
+          DataPathPort specifies the data path port number for data traffic.
+          Acceptable port range is 1024 to 49151.
+          If no port is set or is set to 0, the default port (4789) is used.
+        type: "integer"
+        format: "uint32"
+        default: 4789
+        example: 4789
+      DefaultAddrPool:
+        description: |
+          Default Address Pool specifies default subnet pools for global scope
+          networks.
+        type: "array"
+        items:
+          type: "string"
+          format: "CIDR"
+          example: ["10.10.0.0/16", "20.20.0.0/16"]
+      SubnetSize:
+        description: |
+          SubnetSize specifies the subnet size of the networks created from the
+          default subnet pool.
+        type: "integer"
+        format: "uint32"
+        maximum: 29
+        default: 24
+        example: 24
+
+  JoinTokens:
+    description: |
+      JoinTokens contains the tokens workers and managers need to join the swarm.
+    type: "object"
+    properties:
+      Worker:
+        description: |
+          The token workers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx"
+      Manager:
+        description: |
+          The token managers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+
+  Swarm:
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/ClusterInfo"
+      - type: "object"
+        properties:
+          JoinTokens:
+            $ref: "#/definitions/JoinTokens"
+
+  TaskSpec:
+    description: "User modifiable task configuration."
+    type: "object"
+    properties:
+      PluginSpec:
+        type: "object"
+        description: |
+          Plugin spec for the service.  *(Experimental release only.)*
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Name:
+            description: "The name or 'alias' to use for the plugin."
+            type: "string"
+          Remote:
+            description: "The plugin image reference to use."
+            type: "string"
+          Disabled:
+            description: "Disable the plugin once scheduled."
+            type: "boolean"
+          PluginPrivilege:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+      ContainerSpec:
+        type: "object"
+        description: |
+          Container spec for the service.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Image:
+            description: "The image name to use for the container"
+            type: "string"
+          Labels:
+            description: "User-defined key/value data."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          Command:
+            description: "The command to be run in the image."
+            type: "array"
+            items:
+              type: "string"
+          Args:
+            description: "Arguments to the command."
+            type: "array"
+            items:
+              type: "string"
+          Hostname:
+            description: |
+              The hostname to use for the container, as a valid
+              [RFC 1123](https://tools.ietf.org/html/rfc1123) hostname.
+            type: "string"
+          Env:
+            description: |
+              A list of environment variables in the form `VAR=value`.
+            type: "array"
+            items:
+              type: "string"
+          Dir:
+            description: "The working directory for commands to run in."
+            type: "string"
+          User:
+            description: "The user inside the container."
+            type: "string"
+          Groups:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          Privileges:
+            type: "object"
+            description: "Security options for the container"
+            properties:
+              CredentialSpec:
+                type: "object"
+                description: "CredentialSpec for managed service account (Windows only)"
+                properties:
+                  Config:
+                    type: "string"
+                    example: "0bt9dmxjvjiqermk6xrop3ekq"
+                    description: |
+                      Load credential spec from a Swarm Config with the given ID.
+                      The specified config must also be present in the Configs
+                      field with the Runtime property set.
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  File:
+                    type: "string"
+                    example: "spec.json"
+                    description: |
+                      Load credential spec from this file. The file is read by
+                      the daemon, and must be present in the `CredentialSpecs`
+                      subdirectory in the docker data directory, which defaults
+                      to `C:\ProgramData\Docker\` on Windows.
+
+                      For example, specifying `spec.json` loads
+                      `C:\ProgramData\Docker\CredentialSpecs\spec.json`.
+
+                      <p><br /></p>
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  Registry:
+                    type: "string"
+                    description: |
+                      Load credential spec from this value in the Windows
+                      registry. The specified registry value must be located in:
+
+                      `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs`
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+              SELinuxContext:
+                type: "object"
+                description: "SELinux labels of the container"
+                properties:
+                  Disable:
+                    type: "boolean"
+                    description: "Disable SELinux"
+                  User:
+                    type: "string"
+                    description: "SELinux user label"
+                  Role:
+                    type: "string"
+                    description: "SELinux role label"
+                  Type:
+                    type: "string"
+                    description: "SELinux type label"
+                  Level:
+                    type: "string"
+                    description: "SELinux level label"
+              Seccomp:
+                type: "object"
+                description: "Options for configuring seccomp on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "unconfined"
+                      - "custom"
+                  Profile:
+                    description: "The custom seccomp profile as a json object"
+                    type: "string"
+              AppArmor:
+                type: "object"
+                description: "Options for configuring AppArmor on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "disabled"
+              NoNewPrivileges:
+                type: "boolean"
+                description: "Configuration of the no_new_privs bit in the container"
+
+          TTY:
+            description: "Whether a pseudo-TTY should be allocated."
+            type: "boolean"
+          OpenStdin:
+            description: "Open `stdin`"
+            type: "boolean"
+          ReadOnly:
+            description: "Mount the container's root filesystem as read only."
+            type: "boolean"
+          Mounts:
+            description: |
+              Specification for mounts to be added to containers created as part
+              of the service.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          StopSignal:
+            description: "Signal to stop the container."
+            type: "string"
+          StopGracePeriod:
+            description: |
+              Amount of time to wait for the container to terminate before
+              forcefully killing it.
+            type: "integer"
+            format: "int64"
+          HealthCheck:
+            $ref: "#/definitions/HealthConfig"
+          Hosts:
+            type: "array"
+            description: |
+              A list of hostname/IP mappings to add to the container's `hosts`
+              file. The format of extra hosts is specified in the
+              [hosts(5)](http://man7.org/linux/man-pages/man5/hosts.5.html)
+              man page:
+
+                  IP_address canonical_hostname [aliases...]
+            items:
+              type: "string"
+          DNSConfig:
+            description: |
+              Specification for DNS related configurations in resolver configuration
+              file (`resolv.conf`).
+            type: "object"
+            properties:
+              Nameservers:
+                description: "The IP addresses of the name servers."
+                type: "array"
+                items:
+                  type: "string"
+              Search:
+                description: "A search list for host-name lookup."
+                type: "array"
+                items:
+                  type: "string"
+              Options:
+                description: |
+                  A list of internal resolver variables to be modified (e.g.,
+                  `debug`, `ndots:3`, etc.).
+                type: "array"
+                items:
+                  type: "string"
+          Secrets:
+            description: |
+              Secrets contains references to zero or more secrets that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                SecretID:
+                  description: |
+                    SecretID represents the ID of the specific secret that we're
+                    referencing.
+                  type: "string"
+                SecretName:
+                  description: |
+                    SecretName is the name of the secret that this references,
+                    but this is just provided for lookup/display purposes. The
+                    secret in the reference will be identified by its ID.
+                  type: "string"
+          OomScoreAdj:
+            type: "integer"
+            format: "int64"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 0
+          Configs:
+            description: |
+              Configs contains references to zero or more configs that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually exclusive
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                Runtime:
+                  description: |
+                    Runtime represents a target that is not mounted into the
+                    container but is used by the task
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually
+                    > exclusive
+                  type: "object"
+                ConfigID:
+                  description: |
+                    ConfigID represents the ID of the specific config that we're
+                    referencing.
+                  type: "string"
+                ConfigName:
+                  description: |
+                    ConfigName is the name of the config that this references,
+                    but this is just provided for lookup/display purposes. The
+                    config in the reference will be identified by its ID.
+                  type: "string"
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the containers running the service.
+              (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          Init:
+            description: |
+              Run an init inside the container that forwards signals and reaps
+              processes. This field is omitted if empty, and the default (as
+              configured on the daemon) is used.
+            type: "boolean"
+            x-nullable: true
+          Sysctls:
+            description: |
+              Set kernel namedspaced parameters (sysctls) in the container.
+              The Sysctls option on services accepts the same sysctls as the
+              are supported on containers. Note that while the same sysctls are
+              supported, no guarantees or checks are made about their
+              suitability for a clustered environment, and it's up to the user
+              to determine whether a given sysctl will work properly in a
+              Service.
+            type: "object"
+            additionalProperties:
+              type: "string"
+          # This option is not used by Windows containers
+          CapabilityAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+              - "CAP_SYS_ADMIN"
+              - "CAP_SYS_CHROOT"
+              - "CAP_SYSLOG"
+          CapabilityDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+          Ulimits:
+            description: |
+              A list of resource limits to set in the container. For example: `{"Name": "nofile", "Soft": 1024, "Hard": 2048}`"
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Name:
+                  description: "Name of ulimit"
+                  type: "string"
+                Soft:
+                  description: "Soft limit"
+                  type: "integer"
+                Hard:
+                  description: "Hard limit"
+                  type: "integer"
+      NetworkAttachmentSpec:
+        description: |
+          Read-only spec type for non-swarm containers attached to swarm overlay
+          networks.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        type: "object"
+        properties:
+          ContainerID:
+            description: "ID of the container represented by this task"
+            type: "string"
+      Resources:
+        description: |
+          Resource requirements which apply to each individual container created
+          as part of the service.
+        type: "object"
+        properties:
+          Limits:
+            description: "Define resources limits."
+            $ref: "#/definitions/Limit"
+          Reservations:
+            description: "Define resources reservation."
+            $ref: "#/definitions/ResourceObject"
+          SwapBytes:
+            description: |
+              Amount of swap in bytes - can only be used together with a memory limit.
+              If not specified, the default behaviour is to grant a swap space twice
+              as big as the memory limit.
+              Set to -1 to enable unlimited swap.
+            type: "integer"
+            format: "int64"
+            minimum: -1
+            x-nullable: true
+            x-omitempty: true
+          MemorySwappiness:
+            description: |
+              Tune the service's containers' memory swappiness (0 to 100).
+              If not specified, defaults to the containers' OS' default, generally 60,
+              or whatever value was predefined in the image.
+              Set to -1 to unset a previously set value.
+            type: "integer"
+            format: "int64"
+            minimum: -1
+            maximum: 100
+            x-nullable: true
+            x-omitempty: true
+      RestartPolicy:
+        description: |
+          Specification for the restart policy which applies to containers
+          created as part of this service.
+        type: "object"
+        properties:
+          Condition:
+            description: "Condition for restart."
+            type: "string"
+            enum:
+              - "none"
+              - "on-failure"
+              - "any"
+          Delay:
+            description: "Delay between restart attempts."
+            type: "integer"
+            format: "int64"
+          MaxAttempts:
+            description: |
+              Maximum attempts to restart a given container before giving up
+              (default value is 0, which is ignored).
+            type: "integer"
+            format: "int64"
+            default: 0
+          Window:
+            description: |
+              Windows is the time window used to evaluate the restart policy
+              (default value is 0, which is unbounded).
+            type: "integer"
+            format: "int64"
+            default: 0
+      Placement:
+        type: "object"
+        properties:
+          Constraints:
+            description: |
+              An array of constraint expressions to limit the set of nodes where
+              a task can be scheduled. Constraint expressions can either use a
+              _match_ (`==`) or _exclude_ (`!=`) rule. Multiple constraints find
+              nodes that satisfy every expression (AND match). Constraints can
+              match node or Docker Engine labels as follows:
+
+              node attribute       | matches                        | example
+              ---------------------|--------------------------------|-----------------------------------------------
+              `node.id`            | Node ID                        | `node.id==2ivku8v2gvtg4`
+              `node.hostname`      | Node hostname                  | `node.hostname!=node-2`
+              `node.role`          | Node role (`manager`/`worker`) | `node.role==manager`
+              `node.platform.os`   | Node operating system          | `node.platform.os==windows`
+              `node.platform.arch` | Node architecture              | `node.platform.arch==x86_64`
+              `node.labels`        | User-defined node labels       | `node.labels.security==high`
+              `engine.labels`      | Docker Engine's labels         | `engine.labels.operatingsystem==ubuntu-24.04`
+
+              `engine.labels` apply to Docker Engine labels like operating system,
+              drivers, etc. Swarm administrators add `node.labels` for operational
+              purposes by using the [`node update endpoint`](#operation/NodeUpdate).
+
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "node.hostname!=node3.corp.example.com"
+              - "node.role!=manager"
+              - "node.labels.type==production"
+              - "node.platform.os==linux"
+              - "node.platform.arch==x86_64"
+          Preferences:
+            description: |
+              Preferences provide a way to make the scheduler aware of factors
+              such as topology. They are provided in order from highest to
+              lowest precedence.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Spread:
+                  type: "object"
+                  properties:
+                    SpreadDescriptor:
+                      description: |
+                        label descriptor, such as `engine.labels.az`.
+                      type: "string"
+            example:
+              - Spread:
+                  SpreadDescriptor: "node.labels.datacenter"
+              - Spread:
+                  SpreadDescriptor: "node.labels.rack"
+          MaxReplicas:
+            description: |
+              Maximum number of replicas for per node (default value is 0, which
+              is unlimited)
+            type: "integer"
+            format: "int64"
+            default: 0
+          Platforms:
+            description: |
+              Platforms stores all the platforms that the service's image can
+              run on. This field is used in the platform filter for scheduling.
+              If empty, then the platform filter is off, meaning there are no
+              scheduling restrictions.
+            type: "array"
+            items:
+              $ref: "#/definitions/Platform"
+      ForceUpdate:
+        description: |
+          A counter that triggers an update even if no relevant parameters have
+          been changed.
+        type: "integer"
+        format: "uint64"
+      Runtime:
+        description: |
+          Runtime is the type of runtime specified for the task executor.
+        type: "string"
+      Networks:
+        description: "Specifies which networks the service should attach to."
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+      LogDriver:
+        description: |
+          Specifies the log driver to use for tasks created from this spec. If
+          not present, the default one for the swarm will be used, finally
+          falling back to the engine default if not specified.
+        type: "object"
+        properties:
+          Name:
+            type: "string"
+          Options:
+            type: "object"
+            additionalProperties:
+              type: "string"
+
+  TaskState:
+    type: "string"
+    enum:
+      - "new"
+      - "allocated"
+      - "pending"
+      - "assigned"
+      - "accepted"
+      - "preparing"
+      - "ready"
+      - "starting"
+      - "running"
+      - "complete"
+      - "shutdown"
+      - "failed"
+      - "rejected"
+      - "remove"
+      - "orphaned"
+
+  ContainerStatus:
+    type: "object"
+    description: "represents the status of a container."
+    properties:
+      ContainerID:
+        type: "string"
+      PID:
+        type: "integer"
+      ExitCode:
+        type: "integer"
+
+  PortStatus:
+    type: "object"
+    description: "represents the port status of a task's host ports whose service has published host ports"
+    properties:
+      Ports:
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  TaskStatus:
+    type: "object"
+    description: "represents the status of a task."
+    properties:
+      Timestamp:
+        type: "string"
+        format: "dateTime"
+      State:
+        $ref: "#/definitions/TaskState"
+      Message:
+        type: "string"
+      Err:
+        type: "string"
+      ContainerStatus:
+        $ref: "#/definitions/ContainerStatus"
+      PortStatus:
+        $ref: "#/definitions/PortStatus"
+
+  Task:
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the task."
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Name:
+        description: "Name of the task."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Spec:
+        $ref: "#/definitions/TaskSpec"
+      ServiceID:
+        description: "The ID of the service this task is part of."
+        type: "string"
+      Slot:
+        type: "integer"
+      NodeID:
+        description: "The ID of the node that this task is on."
+        type: "string"
+      AssignedGenericResources:
+        $ref: "#/definitions/GenericResources"
+      Status:
+        $ref: "#/definitions/TaskStatus"
+      DesiredState:
+        $ref: "#/definitions/TaskState"
+      JobIteration:
+        description: |
+          If the Service this Task belongs to is a job-mode service, contains
+          the JobIteration of the Service this Task was created for. Absent if
+          the Task was created for a Replicated or Global Service.
+        $ref: "#/definitions/ObjectVersion"
+    example:
+      ID: "0kzzo1i0y4jz6027t0k7aezc7"
+      Version:
+        Index: 71
+      CreatedAt: "2016-06-07T21:07:31.171892745Z"
+      UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+      Spec:
+        ContainerSpec:
+          Image: "redis"
+        Resources:
+          Limits: {}
+          Reservations: {}
+        RestartPolicy:
+          Condition: "any"
+          MaxAttempts: 0
+        Placement: {}
+      ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Slot: 1
+      NodeID: "60gvrl6tm78dmak4yl7srz94v"
+      Status:
+        Timestamp: "2016-06-07T21:07:31.290032978Z"
+        State: "running"
+        Message: "started"
+        ContainerStatus:
+          ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+          PID: 677
+      DesiredState: "running"
+      NetworksAttachments:
+        - Network:
+            ID: "4qvuz4ko70xaltuqbt8956gd1"
+            Version:
+              Index: 18
+            CreatedAt: "2016-06-07T20:31:11.912919752Z"
+            UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+            Spec:
+              Name: "ingress"
+              Labels:
+                com.docker.swarm.internal: "true"
+              DriverConfiguration: {}
+              IPAMOptions:
+                Driver: {}
+                Configs:
+                  - Subnet: "10.255.0.0/16"
+                    Gateway: "10.255.0.1"
+            DriverState:
+              Name: "overlay"
+              Options:
+                com.docker.network.driver.overlay.vxlanid_list: "256"
+            IPAMOptions:
+              Driver:
+                Name: "default"
+              Configs:
+                - Subnet: "10.255.0.0/16"
+                  Gateway: "10.255.0.1"
+          Addresses:
+            - "10.255.0.10/16"
+      AssignedGenericResources:
+        - DiscreteResourceSpec:
+            Kind: "SSD"
+            Value: 3
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID1"
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID2"
+
+  ServiceSpec:
+    description: "User modifiable configuration for a service."
+    type: object
+    properties:
+      Name:
+        description: "Name of the service."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      TaskTemplate:
+        $ref: "#/definitions/TaskSpec"
+      Mode:
+        description: "Scheduling mode for the service."
+        type: "object"
+        properties:
+          Replicated:
+            type: "object"
+            properties:
+              Replicas:
+                type: "integer"
+                format: "int64"
+          Global:
+            type: "object"
+          ReplicatedJob:
+            description: |
+              The mode used for services with a finite number of tasks that run
+              to a completed state.
+            type: "object"
+            properties:
+              MaxConcurrent:
+                description: |
+                  The maximum number of replicas to run simultaneously.
+                type: "integer"
+                format: "int64"
+                default: 1
+              TotalCompletions:
+                description: |
+                  The total number of replicas desired to reach the Completed
+                  state. If unset, will default to the value of `MaxConcurrent`
+                type: "integer"
+                format: "int64"
+          GlobalJob:
+            description: |
+              The mode used for services which run a task to the completed state
+              on each valid node.
+            type: "object"
+      UpdateConfig:
+        description: "Specification for the update strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be updated in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: "Amount of time between updates, in nanoseconds."
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an updated task fails to run, or stops running
+              during the update.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+              - "rollback"
+          Monitor:
+            description: |
+              Amount of time to monitor each updated task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during an update before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling out an updated task. Either
+              the old task is shut down before the new task is started, or the
+              new task is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      RollbackConfig:
+        description: "Specification for the rollback strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be rolled back in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: |
+              Amount of time between rollback iterations, in nanoseconds.
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an rolled back task fails to run, or stops
+              running during the rollback.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+          Monitor:
+            description: |
+              Amount of time to monitor each rolled back task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during a rollback before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling back a task. Either the old
+              task is shut down before the new task is started, or the new task
+              is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      Networks:
+        description: |
+          Specifies which networks the service should attach to.
+
+          Deprecated: This field is deprecated since v1.44. The Networks field in TaskSpec should be used instead.
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+
+      EndpointSpec:
+        $ref: "#/definitions/EndpointSpec"
+
+  EndpointPortConfig:
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+      Protocol:
+        type: "string"
+        enum:
+          - "tcp"
+          - "udp"
+          - "sctp"
+      TargetPort:
+        description: "The port inside the container."
+        type: "integer"
+      PublishedPort:
+        description: "The port on the swarm hosts."
+        type: "integer"
+      PublishMode:
+        description: |
+          The mode in which port is published.
+
+          <p><br /></p>
+
+          - "ingress" makes the target port accessible on every node,
+            regardless of whether there is a task for the service running on
+            that node or not.
+          - "host" bypasses the routing mesh and publish the port directly on
+            the swarm node where that service is running.
+
+        type: "string"
+        enum:
+          - "ingress"
+          - "host"
+        default: "ingress"
+        example: "ingress"
+
+  EndpointSpec:
+    description: "Properties that can be configured to access and load balance a service."
+    type: "object"
+    properties:
+      Mode:
+        description: |
+          The mode of resolution to use for internal load balancing between tasks.
+        type: "string"
+        enum:
+          - "vip"
+          - "dnsrr"
+        default: "vip"
+      Ports:
+        description: |
+          List of exposed ports that this service is accessible on from the
+          outside. Ports can only be provided if `vip` resolution mode is used.
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  Service:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ServiceSpec"
+      Endpoint:
+        type: "object"
+        properties:
+          Spec:
+            $ref: "#/definitions/EndpointSpec"
+          Ports:
+            type: "array"
+            items:
+              $ref: "#/definitions/EndpointPortConfig"
+          VirtualIPs:
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                NetworkID:
+                  type: "string"
+                Addr:
+                  type: "string"
+      UpdateStatus:
+        description: "The status of a service update."
+        type: "object"
+        properties:
+          State:
+            type: "string"
+            enum:
+              - "updating"
+              - "paused"
+              - "completed"
+          StartedAt:
+            type: "string"
+            format: "dateTime"
+          CompletedAt:
+            type: "string"
+            format: "dateTime"
+          Message:
+            type: "string"
+      ServiceStatus:
+        description: |
+          The status of the service's tasks. Provided only when requested as
+          part of a ServiceList operation.
+        type: "object"
+        properties:
+          RunningTasks:
+            description: |
+              The number of tasks for the service currently in the Running state.
+            type: "integer"
+            format: "uint64"
+            example: 7
+          DesiredTasks:
+            description: |
+              The number of tasks for the service desired to be running.
+              For replicated services, this is the replica count from the
+              service spec. For global services, this is computed by taking
+              count of all tasks for the service with a Desired State other
+              than Shutdown.
+            type: "integer"
+            format: "uint64"
+            example: 10
+          CompletedTasks:
+            description: |
+              The number of tasks for a job that are in the Completed state.
+              This field must be cross-referenced with the service type, as the
+              value of 0 may mean the service is not in a job mode, or it may
+              mean the job-mode service has no tasks yet Completed.
+            type: "integer"
+            format: "uint64"
+      JobStatus:
+        description: |
+          The status of the service when it is in one of ReplicatedJob or
+          GlobalJob modes. Absent on Replicated and Global mode services. The
+          JobIteration is an ObjectVersion, but unlike the Service's version,
+          does not need to be sent with an update request.
+        type: "object"
+        properties:
+          JobIteration:
+            description: |
+              JobIteration is a value increased each time a Job is executed,
+              successfully or otherwise. "Executed", in this case, means the
+              job as a whole has been started, not that an individual Task has
+              been launched. A job is "Executed" when its ServiceSpec is
+              updated. JobIteration can be used to disambiguate Tasks belonging
+              to different executions of a job.  Though JobIteration will
+              increase with each subsequent execution, it may not necessarily
+              increase by 1, and so JobIteration should not be used to
+            $ref: "#/definitions/ObjectVersion"
+          LastExecution:
+            description: |
+              The last time, as observed by the server, that this job was
+              started.
+            type: "string"
+            format: "dateTime"
+    example:
+      ID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Version:
+        Index: 19
+      CreatedAt: "2016-06-07T21:05:51.880065305Z"
+      UpdatedAt: "2016-06-07T21:07:29.962229872Z"
+      Spec:
+        Name: "hopeful_cori"
+        TaskTemplate:
+          ContainerSpec:
+            Image: "redis"
+          Resources:
+            Limits: {}
+            Reservations: {}
+          RestartPolicy:
+            Condition: "any"
+            MaxAttempts: 0
+          Placement: {}
+          ForceUpdate: 0
+        Mode:
+          Replicated:
+            Replicas: 1
+        UpdateConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        RollbackConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        EndpointSpec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+      Endpoint:
+        Spec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+        Ports:
+          -
+            Protocol: "tcp"
+            TargetPort: 6379
+            PublishedPort: 30001
+        VirtualIPs:
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.2/16"
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.3/16"
+
+  ImageDeleteResponseItem:
+    type: "object"
+    x-go-name: "DeleteResponse"
+    properties:
+      Untagged:
+        description: "The image ID of an image that was untagged"
+        type: "string"
+      Deleted:
+        description: "The image ID of an image that was deleted"
+        type: "string"
+
+  ServiceCreateResponse:
+    type: "object"
+    description: |
+      contains the information returned to a client on the
+      creation of a new service.
+    properties:
+      ID:
+        description: "The ID of the created service."
+        type: "string"
+        x-nullable: false
+        example: "ak7w3gjqoa3kuz8xcpnyy0pvl"
+      Warnings:
+        description: |
+          Optional warning message.
+
+          FIXME(thaJeztah): this should have "omitempty" in the generated type.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example:
+          - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ServiceUpdateResponse:
+    type: "object"
+    properties:
+      Warnings:
+        description: "Optional warning messages"
+        type: "array"
+        items:
+          type: "string"
+    example:
+      Warnings:
+        - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ContainerInspectResponse:
+    type: "object"
+    title: "ContainerInspectResponse"
+    x-go-name: "InspectResponse"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Created:
+        description: |-
+          Date and time at which the container was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2025-02-17T17:43:39.64001363Z"
+      Path:
+        description: |-
+          The path to the command being run
+        type: "string"
+        example: "/bin/sh"
+      Args:
+        description: "The arguments to the command being run"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "-c"
+          - "exit 9"
+      State:
+        $ref: "#/definitions/ContainerState"
+      Image:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ResolvConfPath:
+        description: |-
+          Location of the `/etc/resolv.conf` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/resolv.conf"
+      HostnamePath:
+        description: |-
+          Location of the `/etc/hostname` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hostname"
+      HostsPath:
+        description: |-
+          Location of the `/etc/hosts` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hosts"
+      LogPath:
+        description: |-
+          Location of the file used to buffer the container's logs. Depending on
+          the logging-driver used for the container, this field may be omitted.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        x-nullable: true
+        example: "/var/lib/docker/containers/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59-json.log"
+      Name:
+        description: |-
+          The name associated with this container.
+
+          For historic reasons, the name may be prefixed with a forward-slash (`/`).
+        type: "string"
+        example: "/funny_chatelet"
+      RestartCount:
+        description: |-
+          Number of times the container was restarted since it was created,
+          or since daemon was started.
+        type: "integer"
+        example: 0
+      Driver:
+        description: |-
+          The storage-driver used for the container's filesystem (graph-driver
+          or snapshotter).
+        type: "string"
+        example: "overlayfs"
+      Platform:
+        description: |-
+          The platform (operating system) for which the container was created.
+
+          This field was introduced for the experimental "LCOW" (Linux Containers
+          On Windows) features, which has been removed. In most cases, this field
+          is equal to the host's operating system (`linux` or `windows`).
+        type: "string"
+        example: "linux"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        description: |-
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+      MountLabel:
+        description: |-
+          SELinux mount label set for the container.
+        type: "string"
+        example: ""
+      ProcessLabel:
+        description: |-
+          SELinux process label set for the container.
+        type: "string"
+        example: ""
+      AppArmorProfile:
+        description: |-
+          The AppArmor profile set for the container.
+        type: "string"
+        example: ""
+      ExecIDs:
+        description: |-
+          IDs of exec instances that are running in the container.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example:
+          - "b35395de42bc8abd327f9dd65d913b9ba28c74d2f0734eeeae84fa1c616a0fca"
+          - "3fc1232e5cd20c8de182ed81178503dc6437f4e7ef12b52cc5e8de020652f1c4"
+      HostConfig:
+        $ref: "#/definitions/HostConfig"
+      GraphDriver:
+        $ref: "#/definitions/DriverData"
+        x-nullable: true
+      Storage:
+        $ref: "#/definitions/Storage"
+        x-nullable: true
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Mounts:
+        description: |-
+          List of mounts used by the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/MountPoint"
+      Config:
+        $ref: "#/definitions/ContainerConfig"
+      NetworkSettings:
+        $ref: "#/definitions/NetworkSettings"
+
+  ContainerSummary:
+    type: "object"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Names:
+        description: |-
+          The names associated with this container. Most containers have a single
+          name, but when using legacy "links", the container can have multiple
+          names.
+
+          For historic reasons, names are prefixed with a forward-slash (`/`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/funny_chatelet"
+      Image:
+        description: |-
+          The name or ID of the image used to create the container.
+
+          This field shows the image reference as was specified when creating the container,
+          which can be in its canonical form (e.g., `docker.io/library/ubuntu:latest`
+          or `docker.io/library/ubuntu@sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`),
+          short form (e.g., `ubuntu:latest`)), or the ID(-prefix) of the image (e.g., `72297848456d`).
+
+          The content of this field can be updated at runtime if the image used to
+          create the container is untagged, in which case the field is updated to
+          contain the the image ID (digest) it was resolved to in its canonical,
+          non-truncated form (e.g., `sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`).
+        type: "string"
+        example: "docker.io/library/ubuntu:latest"
+      ImageID:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        x-nullable: true
+        description: |
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+
+          This field is not populated in the `GET /system/df` endpoint.
+      Command:
+        description: "Command to run when starting the container"
+        type: "string"
+        example: "/bin/bash"
+      Created:
+        description: |-
+          Date and time at which the container was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        format: "int64"
+        example: "1739811096"
+      Ports:
+        description: |-
+          Port-mappings for the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/PortSummary"
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.vendor: "Acme"
+          com.example.license: "GPL"
+          com.example.version: "1.0"
+      State:
+        description: |
+          The state of this container.
+        type: "string"
+        enum:
+          - "created"
+          - "running"
+          - "paused"
+          - "restarting"
+          - "exited"
+          - "removing"
+          - "dead"
+        example: "running"
+      Status:
+        description: |-
+          Additional human-readable status of this container (e.g. `Exit 0`)
+        type: "string"
+        example: "Up 4 days"
+      HostConfig:
+        type: "object"
+        description: |-
+          Summary of host-specific runtime information of the container. This
+          is a reduced set of information in the container's "HostConfig" as
+          available in the container "inspect" response.
+        properties:
+          NetworkMode:
+            description: |-
+              Networking mode (`host`, `none`, `container:<id>`) or name of the
+              primary network the container is using.
+
+              This field is primarily for backward compatibility. The container
+              can be connected to multiple networks for which information can be
+              found in the `NetworkSettings.Networks` field, which enumerates
+              settings per network.
+            type: "string"
+            example: "mynetwork"
+          Annotations:
+            description: |-
+              Arbitrary key-value metadata attached to the container.
+            type: "object"
+            x-nullable: true
+            additionalProperties:
+              type: "string"
+            example:
+              io.kubernetes.docker.type: "container"
+              io.kubernetes.sandbox.id: "3befe639bed0fd6afdd65fd1fa84506756f59360ec4adc270b0fdac9be22b4d3"
+      NetworkSettings:
+        description: |-
+          Summary of the container's network settings
+        type: "object"
+        properties:
+          Networks:
+            type: "object"
+            description: |-
+              Summary of network-settings for each network the container is
+              attached to.
+            additionalProperties:
+              $ref: "#/definitions/EndpointSettings"
+      Mounts:
+        type: "array"
+        description: |-
+          List of mounts used by the container.
+        items:
+          $ref: "#/definitions/MountPoint"
+      Health:
+        type: "object"
+        description: |-
+          Summary of health status
+
+          Added in v1.52, before that version all container summary not include Health.
+          After this attribute introduced, it includes containers with no health checks configured,
+          or containers that are not running with none
+        properties:
+          Status:
+            type: "string"
+            description: |-
+              the health status of the container
+            enum:
+              - "none"
+              - "starting"
+              - "healthy"
+              - "unhealthy"
+            example: "healthy"
+          FailingStreak:
+            description: "FailingStreak is the number of consecutive failures"
+            type: "integer"
+            example: 0
+
+  ContainersDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/container"
+    description: |
+      represents system data usage information for container resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active containers.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all containers.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive containers.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by containers.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of container summaries.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Summary
+
+  Driver:
+    description: "Driver represents a driver (network, logging, secrets)."
+    type: "object"
+    required: [Name]
+    properties:
+      Name:
+        description: "Name of the driver."
+        type: "string"
+        x-nullable: false
+        example: "some-driver"
+      Options:
+        description: "Key/value map of driver-specific options."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          OptionA: "value for driver-specific option A"
+          OptionB: "value for driver-specific option B"
+
+  SecretSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the secret."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Data:
+        description: |
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          It must be empty if the Driver field is set, in which case the data is
+          loaded from an external secret store. The maximum allowed size is 500KB,
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
+
+          This field is only used to _create_ a secret, and is not returned by
+          other endpoints.
+        type: "string"
+        example: ""
+      Driver:
+        description: |
+          Name of the secrets driver used to fetch the secret's value from an
+          external secret store.
+        $ref: "#/definitions/Driver"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Secret:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "blt1owaxmitz71s9v5zh81zun"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      Spec:
+        $ref: "#/definitions/SecretSpec"
+
+  ConfigSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the config."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Data:
+        description: |
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
+        type: "string"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Config:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ConfigSpec"
+
+  ContainerState:
+    description: |
+      ContainerState stores container's running state. It's part of ContainerJSONBase
+      and will be returned by the "inspect" command.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          String representation of the container state. Can be one of "created",
+          "running", "paused", "restarting", "removing", "exited", or "dead".
+        type: "string"
+        enum: ["created", "running", "paused", "restarting", "removing", "exited", "dead"]
+        example: "running"
+      Running:
+        description: |
+          Whether this container is running.
+
+          Note that a running container can be _paused_. The `Running` and `Paused`
+          booleans are not mutually exclusive:
+
+          When pausing a container (on Linux), the freezer cgroup is used to suspend
+          all processes in the container. Freezing the process requires the process to
+          be running. As a result, paused containers are both `Running` _and_ `Paused`.
+
+          Use the `Status` field instead to determine if a container's state is "running".
+        type: "boolean"
+        example: true
+      Paused:
+        description: "Whether this container is paused."
+        type: "boolean"
+        example: false
+      Restarting:
+        description: "Whether this container is restarting."
+        type: "boolean"
+        example: false
+      OOMKilled:
+        description: |
+          Whether a process within this container has been killed because it ran
+          out of memory since the container was last started.
+        type: "boolean"
+        example: false
+      Dead:
+        type: "boolean"
+        example: false
+      Pid:
+        description: "The process ID of this container"
+        type: "integer"
+        example: 1234
+      ExitCode:
+        description: "The last exit code of this container"
+        type: "integer"
+        example: 0
+      Error:
+        type: "string"
+      StartedAt:
+        description: "The time when this container was last started."
+        type: "string"
+        example: "2020-01-06T09:06:59.461876391Z"
+      FinishedAt:
+        description: "The time when this container last exited."
+        type: "string"
+        example: "2020-01-06T09:07:59.461876391Z"
+      Health:
+        $ref: "#/definitions/Health"
+
+  ContainerCreateResponse:
+    description: "OK response to ContainerCreate operation"
+    type: "object"
+    title: "ContainerCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warnings]
+    properties:
+      Id:
+        description: "The ID of the created container"
+        type: "string"
+        x-nullable: false
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Warnings:
+        description: "Warnings encountered when creating the container"
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example: []
+
+  ContainerUpdateResponse:
+    type: "object"
+    title: "ContainerUpdateResponse"
+    x-go-name: "UpdateResponse"
+    description: |-
+      Response for a successful container-update.
+    properties:
+      Warnings:
+        type: "array"
+        description: |-
+          Warnings encountered when updating the container.
+        items:
+          type: "string"
+        example: ["Published ports are discarded when using host network mode"]
+
+  ContainerStatsResponse:
+    description: |
+      Statistics sample for a container.
+    type: "object"
+    x-go-name: "StatsResponse"
+    title: "ContainerStatsResponse"
+    properties:
+      id:
+        description: |
+          ID of the container for which the stats were collected.
+        type: "string"
+        x-nullable: true
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      name:
+        description: |
+          Name of the container for which the stats were collected.
+        type: "string"
+        x-nullable: true
+        example: "boring_wozniak"
+      os_type:
+        description: |
+          OSType is the OS of the container ("linux" or "windows") to allow
+          platform-specific handling of stats.
+        type: "string"
+        x-nullable: true
+        example: "linux"
+      read:
+        description: |
+          Date and time at which this sample was collected.
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:22.165243637Z"
+      cpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+      memory_stats:
+        $ref: "#/definitions/ContainerMemoryStats"
+      networks:
+        description: |
+          Network statistics for the container per interface.
+
+          This field is omitted if the container has no networking enabled.
+        x-nullable: true
+        additionalProperties:
+          $ref: "#/definitions/ContainerNetworkStats"
+        example:
+          eth0:
+            rx_bytes: 5338
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 36
+            tx_bytes: 648
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 8
+          eth5:
+            rx_bytes: 4641
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 26
+            tx_bytes: 690
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 9
+      pids_stats:
+        $ref: "#/definitions/ContainerPidsStats"
+      blkio_stats:
+        $ref: "#/definitions/ContainerBlkioStats"
+      num_procs:
+        description: |
+          The number of processors on the system.
+
+          This field is Windows-specific and always zero for Linux containers.
+        type: "integer"
+        format: "uint32"
+        example: 16
+      storage_stats:
+        $ref: "#/definitions/ContainerStorageStats"
+      preread:
+        description: |
+          Date and time at which this first sample was collected. This field
+          is not propagated if the "one-shot" option is set. If the "one-shot"
+          option is set, this field may be omitted, empty, or set to a default
+          date (`0001-01-01T00:00:00Z`).
+
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:21.160452595Z"
+      precpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+
+  ContainerBlkioStats:
+    description: |
+      BlkioStats stores all IO service stats for data read and write.
+
+      This type is Linux-specific and holds many fields that are specific to cgroups v1.
+      On a cgroup v2 host, all fields other than `io_service_bytes_recursive`
+      are omitted or `null`.
+
+      This type is only populated on Linux and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStats"
+    x-nullable: true
+    properties:
+      io_service_bytes_recursive:
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_serviced_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_queue_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_service_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_wait_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_merged_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      sectors_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+    example:
+      io_service_bytes_recursive: [
+        {"major": 254, "minor": 0, "op": "read", "value": 7593984},
+        {"major": 254, "minor": 0, "op": "write", "value": 100}
+      ]
+      io_serviced_recursive: null
+      io_queue_recursive: null
+      io_service_time_recursive: null
+      io_wait_time_recursive: null
+      io_merged_recursive: null
+      io_time_recursive: null
+      sectors_recursive: null
+
+  ContainerBlkioStatEntry:
+    description: |
+      Blkio stats entry.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStatEntry"
+    x-nullable: true
+    properties:
+      major:
+        type: "integer"
+        format: "uint64"
+        example: 254
+      minor:
+        type: "integer"
+        format: "uint64"
+        example: 0
+      op:
+        type: "string"
+        example: "read"
+      value:
+        type: "integer"
+        format: "uint64"
+        example: 7593984
+
+  ContainerCPUStats:
+    description: |
+      CPU related info of the container
+    type: "object"
+    x-go-name: "CPUStats"
+    x-nullable: true
+    properties:
+      cpu_usage:
+        $ref: "#/definitions/ContainerCPUUsage"
+      system_cpu_usage:
+        description: |
+          System Usage.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      online_cpus:
+        description: |
+          Number of online CPUs.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint32"
+        x-nullable: true
+        example: 5
+      throttling_data:
+        $ref: "#/definitions/ContainerThrottlingData"
+
+  ContainerCPUUsage:
+    description: |
+      All CPU stats aggregated since container inception.
+    type: "object"
+    x-go-name: "CPUUsage"
+    x-nullable: true
+    properties:
+      total_usage:
+        description: |
+          Total CPU time consumed in nanoseconds (Linux) or 100's of nanoseconds (Windows).
+        type: "integer"
+        format: "uint64"
+        example: 29912000
+      percpu_usage:
+        description: |
+          Total CPU time (in nanoseconds) consumed per core (Linux).
+
+          This field is Linux-specific when using cgroups v1. It is omitted
+          when using cgroups v2 and Windows containers.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "integer"
+          format: "uint64"
+          example: 29912000
+
+      usage_in_kernelmode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in kernel mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 21994000
+      usage_in_usermode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in user mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 7918000
+
+  ContainerPidsStats:
+    description: |
+      PidsStats contains Linux-specific stats of a container's process-IDs (PIDs).
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "PidsStats"
+    x-nullable: true
+    properties:
+      current:
+        description: |
+          Current is the number of PIDs in the cgroup.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      limit:
+        description: |
+          Limit is the hard limit on the number of pids in the cgroup.
+          A "Limit" of 0 means that there is no limit.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: "18446744073709551615"
+
+  ContainerThrottlingData:
+    description: |
+      CPU throttling stats of the container.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "ThrottlingData"
+    x-nullable: true
+    properties:
+      periods:
+        description: |
+          Number of periods with throttling active.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_periods:
+        description: |
+          Number of periods when the container hit its throttling limit.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_time:
+        description: |
+          Aggregated time (in nanoseconds) the container was throttled for.
+        type: "integer"
+        format: "uint64"
+        example: 0
+
+  ContainerMemoryStats:
+    description: |
+      Aggregates all memory stats since container inception on Linux.
+      Windows returns stats for commit and private working set only.
+    type: "object"
+    x-go-name: "MemoryStats"
+    properties:
+      usage:
+        description: |
+          Current `res_counter` usage for memory.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      max_usage:
+        description: |
+          Maximum usage ever recorded.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      stats:
+        description: |
+          All the stats exported via memory.stat.
+
+          The fields in this object differ between cgroups v1 and v2.
+          On cgroups v1, fields such as `cache`, `rss`, `mapped_file` are available.
+          On cgroups v2, fields such as `file`, `anon`, `inactive_file` are available.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "object"
+        additionalProperties:
+          type: "integer"
+          format: "uint64"
+          x-nullable: true
+        example:
+          {
+            "active_anon": 1572864,
+            "active_file": 5115904,
+            "anon": 1572864,
+            "anon_thp": 0,
+            "file": 7626752,
+            "file_dirty": 0,
+            "file_mapped": 2723840,
+            "file_writeback": 0,
+            "inactive_anon": 0,
+            "inactive_file": 2510848,
+            "kernel_stack": 16384,
+            "pgactivate": 0,
+            "pgdeactivate": 0,
+            "pgfault": 2042,
+            "pglazyfree": 0,
+            "pglazyfreed": 0,
+            "pgmajfault": 45,
+            "pgrefill": 0,
+            "pgscan": 0,
+            "pgsteal": 0,
+            "shmem": 0,
+            "slab": 1180928,
+            "slab_reclaimable": 725576,
+            "slab_unreclaimable": 455352,
+            "sock": 0,
+            "thp_collapse_alloc": 0,
+            "thp_fault_alloc": 1,
+            "unevictable": 0,
+            "workingset_activate": 0,
+            "workingset_nodereclaim": 0,
+            "workingset_refault": 0
+          }
+      failcnt:
+        description: |
+          Number of times memory usage hits limits.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      limit:
+        description: |
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 8217579520
+      commitbytes:
+        description: |
+          Committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      commitpeakbytes:
+        description: |
+          Peak committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      privateworkingset:
+        description: |
+          Private working set.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+
+  ContainerNetworkStats:
+    description: |
+      Aggregates the network stats of one container
+    type: "object"
+    x-go-name: "NetworkStats"
+    x-nullable: true
+    properties:
+      rx_bytes:
+        description: |
+          Bytes received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 5338
+      rx_packets:
+        description: |
+          Packets received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 36
+      rx_errors:
+        description: |
+          Received errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      rx_dropped:
+        description: |
+          Incoming packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_bytes:
+        description: |
+          Bytes sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 1200
+      tx_packets:
+        description: |
+          Packets sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 12
+      tx_errors:
+        description: |
+          Sent errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_dropped:
+        description: |
+          Outgoing packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      endpoint_id:
+        description: |
+          Endpoint ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+      instance_id:
+        description: |
+          Instance ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+
+  ContainerStorageStats:
+    description: |
+      StorageStats is the disk I/O stats for read/write on Windows.
+
+      This type is Windows-specific and omitted for Linux containers.
+    type: "object"
+    x-go-name: "StorageStats"
+    x-nullable: true
+    properties:
+      read_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      read_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+
+  ContainerTopResponse:
+    type: "object"
+    x-go-name: "TopResponse"
+    title: "ContainerTopResponse"
+    description: |-
+      Container "top" response.
+    properties:
+      Titles:
+        description: "The ps column titles"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          Titles:
+            - "UID"
+            - "PID"
+            - "PPID"
+            - "C"
+            - "STIME"
+            - "TTY"
+            - "TIME"
+            - "CMD"
+      Processes:
+        description: |-
+          Each process running in the container, where each process
+          is an array of values corresponding to the titles.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          Processes:
+            -
+              - "root"
+              - "13642"
+              - "882"
+              - "0"
+              - "17:03"
+              - "pts/0"
+              - "00:00:00"
+              - "/bin/bash"
+            -
+              - "root"
+              - "13735"
+              - "13642"
+              - "0"
+              - "17:06"
+              - "pts/0"
+              - "00:00:00"
+              - "sleep 10"
+
+  ContainerWaitResponse:
+    description: "OK response to ContainerWait operation"
+    type: "object"
+    x-go-name: "WaitResponse"
+    title: "ContainerWaitResponse"
+    required: [StatusCode]
+    properties:
+      StatusCode:
+        description: "Exit code of the container"
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Error:
+        $ref: "#/definitions/ContainerWaitExitError"
+
+  ContainerWaitExitError:
+    description: "container waiting error, if any"
+    type: "object"
+    x-go-name: "WaitExitError"
+    properties:
+      Message:
+        description: "Details of an error"
+        type: "string"
+
+  SystemVersion:
+    type: "object"
+    description: |
+      Response of Engine API: GET "/version"
+    properties:
+      Platform:
+        type: "object"
+        required: [Name]
+        properties:
+          Name:
+            type: "string"
+      Components:
+        type: "array"
+        description: |
+          Information about system components
+        items:
+          type: "object"
+          x-go-name: ComponentVersion
+          required: [Name, Version]
+          properties:
+            Name:
+              description: |
+                Name of the component
+              type: "string"
+              example: "Engine"
+            Version:
+              description: |
+                Version of the component
+              type: "string"
+              x-nullable: false
+              example: "27.0.1"
+            Details:
+              description: |
+                Key/value pairs of strings with additional information about the
+                component. These values are intended for informational purposes
+                only, and their content is not defined, and not part of the API
+                specification.
+
+                These messages can be printed by the client as information to the user.
+              type: "object"
+              x-nullable: true
+      Version:
+        description: "The version of the daemon"
+        type: "string"
+        example: "27.0.1"
+      ApiVersion:
+        description: |
+          The default (and highest) API version that is supported by the daemon
+        type: "string"
+        example: "1.47"
+      MinAPIVersion:
+        description: |
+          The minimum API version that is supported by the daemon
+        type: "string"
+        example: "1.24"
+      GitCommit:
+        description: |
+          The Git commit of the source code that was used to build the daemon
+        type: "string"
+        example: "48a66213fe"
+      GoVersion:
+        description: |
+          The version Go used to compile the daemon, and the version of the Go
+          runtime in use.
+        type: "string"
+        example: "go1.22.7"
+      Os:
+        description: |
+          The operating system that the daemon is running on ("linux" or "windows")
+        type: "string"
+        example: "linux"
+      Arch:
+        description: |
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "amd64"
+      KernelVersion:
+        description: |
+          The kernel version (`uname -r`) that the daemon is running on.
+
+          This field is omitted when empty.
+        type: "string"
+        example: "6.8.0-31-generic"
+      Experimental:
+        description: |
+          Indicates if the daemon is started with experimental features enabled.
+
+          This field is omitted when empty / false.
+        type: "boolean"
+        example: true
+      BuildTime:
+        description: |
+          The date and time that the daemon was compiled.
+        type: "string"
+        example: "2020-06-22T15:49:27.000000000+00:00"
+
+  SystemInfo:
+    type: "object"
+    properties:
+      ID:
+        description: |
+          Unique identifier of the daemon.
+
+          <p><br /></p>
+
+          > **Note**: The format of the ID itself is not part of the API, and
+          > should not be considered stable.
+        type: "string"
+        example: "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS"
+      Containers:
+        description: "Total number of containers on the host."
+        type: "integer"
+        example: 14
+      ContainersRunning:
+        description: |
+          Number of containers with status `"running"`.
+        type: "integer"
+        example: 3
+      ContainersPaused:
+        description: |
+          Number of containers with status `"paused"`.
+        type: "integer"
+        example: 1
+      ContainersStopped:
+        description: |
+          Number of containers with status `"stopped"`.
+        type: "integer"
+        example: 10
+      Images:
+        description: |
+          Total number of images on the host.
+
+          Both _tagged_ and _untagged_ (dangling) images are counted.
+        type: "integer"
+        example: 508
+      Driver:
+        description: "Name of the storage driver in use."
+        type: "string"
+        example: "overlay2"
+      DriverStatus:
+        description: |
+          Information specific to the storage driver, provided as
+          "label" / "value" pairs.
+
+          This information is provided by the storage driver, and formatted
+          in a way consistent with the output of `docker info` on the command
+          line.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["Backing Filesystem", "extfs"]
+          - ["Supports d_type", "true"]
+          - ["Native Overlay Diff", "true"]
+      DockerRootDir:
+        description: |
+          Root directory of persistent Docker state.
+
+          Defaults to `/var/lib/docker` on Linux, and `C:\ProgramData\docker`
+          on Windows.
+        type: "string"
+        example: "/var/lib/docker"
+      Plugins:
+        $ref: "#/definitions/PluginsInfo"
+      MemoryLimit:
+        description: "Indicates if the host has memory limit support enabled."
+        type: "boolean"
+        example: true
+      SwapLimit:
+        description: "Indicates if the host has memory swap limit support enabled."
+        type: "boolean"
+        example: true
+      CpuCfsPeriod:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) period is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CpuCfsQuota:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) quota is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CPUShares:
+        description: |
+          Indicates if CPU Shares limiting is supported by the host.
+        type: "boolean"
+        example: true
+      CPUSet:
+        description: |
+          Indicates if CPUsets (cpuset.cpus, cpuset.mems) are supported by the host.
+
+          See [cpuset(7)](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt)
+        type: "boolean"
+        example: true
+      PidsLimit:
+        description: "Indicates if the host kernel has PID limit support enabled."
+        type: "boolean"
+        example: true
+      OomKillDisable:
+        description: "Indicates if OOM killer disable is supported on the host."
+        type: "boolean"
+      IPv4Forwarding:
+        description: "Indicates IPv4 forwarding is enabled."
+        type: "boolean"
+        example: true
+      Debug:
+        description: |
+          Indicates if the daemon is running in debug-mode / with debug-level
+          logging enabled.
+        type: "boolean"
+        example: true
+      NFd:
+        description: |
+          The total number of file Descriptors in use by the daemon process.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 64
+      NGoroutines:
+        description: |
+          The  number of goroutines that currently exist.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 174
+      SystemTime:
+        description: |
+          Current system-time in [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          format with nano-seconds.
+        type: "string"
+        example: "2017-08-08T20:28:29.06202363Z"
+      LoggingDriver:
+        description: |
+          The logging driver to use as a default for new containers.
+        type: "string"
+      CgroupDriver:
+        description: |
+          The driver to use for managing cgroups.
+        type: "string"
+        enum: ["cgroupfs", "systemd", "none"]
+        default: "cgroupfs"
+        example: "cgroupfs"
+      CgroupVersion:
+        description: |
+          The version of the cgroup.
+        type: "string"
+        enum: ["1", "2"]
+        default: "1"
+        example: "1"
+      NEventsListener:
+        description: "Number of event listeners subscribed."
+        type: "integer"
+        example: 30
+      KernelVersion:
+        description: |
+          Kernel version of the host.
+
+          On Linux, this information obtained from `uname`. On Windows this
+          information is queried from the <kbd>HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\</kbd>
+          registry value, for example _"10.0 14393 (14393.1198.amd64fre.rs1_release_sec.170427-1353)"_.
+        type: "string"
+        example: "6.8.0-31-generic"
+      OperatingSystem:
+        description: |
+          Name of the host's operating system, for example: "Ubuntu 24.04 LTS"
+          or "Windows Server 2016 Datacenter"
+        type: "string"
+        example: "Ubuntu 24.04 LTS"
+      OSVersion:
+        description: |
+          Version of the host's operating system
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including its
+          > very existence, and the formatting of values, should not be considered
+          > stable, and may change without notice.
+        type: "string"
+        example: "24.04"
+      OSType:
+        description: |
+          Generic type of the operating system of the host, as returned by the
+          Go runtime (`GOOS`).
+
+          Currently returned values are "linux" and "windows". A full list of
+          possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "linux"
+      Architecture:
+        description: |
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
+
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
+        type: "string"
+        example: "x86_64"
+      NCPU:
+        description: |
+          The number of logical CPUs usable by the daemon.
+
+          The number of available CPUs is checked by querying the operating
+          system when the daemon starts. Changes to operating system CPU
+          allocation after the daemon is started are not reflected.
+        type: "integer"
+        example: 4
+      MemTotal:
+        description: |
+          Total amount of physical memory available on the host, in bytes.
+        type: "integer"
+        format: "int64"
+        example: 2095882240
+
+      IndexServerAddress:
+        description: |
+          Address / URL of the index server that is used for image search,
+          and as a default for user authentication for Docker Hub and Docker Cloud.
+        default: "https://index.docker.io/v1/"
+        type: "string"
+        example: "https://index.docker.io/v1/"
+      RegistryConfig:
+        $ref: "#/definitions/RegistryServiceConfig"
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+      HttpProxy:
+        description: |
+          HTTP-proxy configured for the daemon. This value is obtained from the
+          [`HTTP_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "http://xxxxx:xxxxx@proxy.corp.example.com:8080"
+      HttpsProxy:
+        description: |
+          HTTPS-proxy configured for the daemon. This value is obtained from the
+          [`HTTPS_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "https://xxxxx:xxxxx@proxy.corp.example.com:4443"
+      NoProxy:
+        description: |
+          Comma-separated list of domain extensions for which no proxy should be
+          used. This value is obtained from the [`NO_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html)
+          environment variable.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "*.local, 169.254/16"
+      Name:
+        description: "Hostname of the host."
+        type: "string"
+        example: "node5.corp.example.com"
+      Labels:
+        description: |
+          User-defined labels (key/value metadata) as set on the daemon.
+
+          <p><br /></p>
+
+          > **Note**: When part of a Swarm, nodes can both have _daemon_ labels,
+          > set through the daemon configuration, and _node_ labels, set from a
+          > manager node in the Swarm. Node labels are not included in this
+          > field. Node labels can be retrieved using the `/nodes/(id)` endpoint
+          > on a manager node in the Swarm.
+        type: "array"
+        items:
+          type: "string"
+        example: ["storage=ssd", "production"]
+      ExperimentalBuild:
+        description: |
+          Indicates if experimental features are enabled on the daemon.
+        type: "boolean"
+        example: true
+      ServerVersion:
+        description: |
+          Version string of the daemon.
+        type: "string"
+        example: "27.0.1"
+      Runtimes:
+        description: |
+          List of [OCI compliant](https://github.com/opencontainers/runtime-spec)
+          runtimes configured on the daemon. Keys hold the "name" used to
+          reference the runtime.
+
+          The Docker daemon relies on an OCI compliant runtime (invoked via the
+          `containerd` daemon) as its interface to the Linux kernel namespaces,
+          cgroups, and SELinux.
+
+          The default runtime is `runc`, and automatically configured. Additional
+          runtimes can be configured by the user and will be listed here.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/Runtime"
+        default:
+          runc:
+            path: "runc"
+        example:
+          runc:
+            path: "runc"
+          runc-master:
+            path: "/go/bin/runc"
+          custom:
+            path: "/usr/local/bin/my-oci-runtime"
+            runtimeArgs: ["--debug", "--systemd-cgroup=false"]
+      DefaultRuntime:
+        description: |
+          Name of the default OCI runtime that is used when starting containers.
+
+          The default can be overridden per-container at create time.
+        type: "string"
+        default: "runc"
+        example: "runc"
+      Swarm:
+        $ref: "#/definitions/SwarmInfo"
+      LiveRestoreEnabled:
+        description: |
+          Indicates if live restore is enabled.
+
+          If enabled, containers are kept running when the daemon is shutdown
+          or upon daemon start if running containers are detected.
+        type: "boolean"
+        default: false
+        example: false
+      Isolation:
+        description: |
+          Represents the isolation technology to use as a default for containers.
+          The supported values are platform-specific.
+
+          If no isolation value is specified on daemon start, on Windows client,
+          the default is `hyperv`, and on Windows server, the default is `process`.
+
+          This option is currently not used on other platforms.
+        default: "default"
+        type: "string"
+        enum:
+          - "default"
+          - "hyperv"
+          - "process"
+          - ""
+      InitBinary:
+        description: |
+          Name and, optional, path of the `docker-init` binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "docker-init"
+      ContainerdCommit:
+        $ref: "#/definitions/Commit"
+      RuncCommit:
+        $ref: "#/definitions/Commit"
+      InitCommit:
+        $ref: "#/definitions/Commit"
+      SecurityOptions:
+        description: |
+          List of security features that are enabled on the daemon, such as
+          apparmor, seccomp, SELinux, user-namespaces (userns), rootless and
+          no-new-privileges.
+
+          Additional configuration options for each security feature may
+          be present, and are included as a comma-separated list of key/value
+          pairs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "name=apparmor"
+          - "name=seccomp,profile=default"
+          - "name=selinux"
+          - "name=userns"
+          - "name=rootless"
+      ProductLicense:
+        description: |
+          Reports a summary of the product license on the daemon.
+
+          If a commercial license has been applied to the daemon, information
+          such as number of nodes, and expiration are included.
+        type: "string"
+        example: "Community Engine"
+      DefaultAddressPools:
+        description: |
+          List of custom default address pools for local networks, which can be
+          specified in the daemon.json file or dockerd option.
+
+          Example: a Base "10.10.0.0/16" with Size 24 will define the set of 256
+          10.10.[0-255].0/24 address pools.
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Base:
+              description: "The network address in CIDR format"
+              type: "string"
+              example: "10.10.0.0/16"
+            Size:
+              description: "The network pool size"
+              type: "integer"
+              example: "24"
+      FirewallBackend:
+        $ref: "#/definitions/FirewallInfo"
+      DiscoveredDevices:
+        description: |
+          List of devices discovered by device drivers.
+
+          Each device includes information about its source driver, kind, name,
+          and additional driver-specific attributes.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceInfo"
+      Warnings:
+        description: |
+          List of warnings / informational messages about missing features, or
+          issues related to the daemon configuration.
+
+          These messages can be printed by the client as information to the user.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "WARNING: No memory limit support"
+      CDISpecDirs:
+        description: |
+          List of directories where (Container Device Interface) CDI
+          specifications are located.
+
+          These specifications define vendor-specific modifications to an OCI
+          runtime specification for a container being created.
+
+          An empty list indicates that CDI device injection is disabled.
+
+          Note that since using CDI device injection requires the daemon to have
+          experimental enabled. For non-experimental daemons an empty list will
+          always be returned.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/etc/cdi"
+          - "/var/run/cdi"
+      Containerd:
+        $ref: "#/definitions/ContainerdInfo"
+
+  ContainerdInfo:
+    description: |
+      Information for connecting to the containerd instance that is used by the daemon.
+      This is included for debugging purposes only.
+    type: "object"
+    x-nullable: true
+    properties:
+      Address:
+        description: "The address of the containerd socket."
+        type: "string"
+        example: "/run/containerd/containerd.sock"
+      Namespaces:
+        description: |
+          The namespaces that the daemon uses for running containers and
+          plugins in containerd. These namespaces can be configured in the
+          daemon configuration, and are considered to be used exclusively
+          by the daemon, Tampering with the containerd instance may cause
+          unexpected behavior.
+
+          As these namespaces are considered to be exclusively accessed
+          by the daemon, it is not recommended to change these values,
+          or to change them to a value that is used by other systems,
+          such as cri-containerd.
+        type: "object"
+        properties:
+          Containers:
+            description: |
+              The default containerd namespace used for containers managed
+              by the daemon.
+
+              The default namespace for containers is "moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "moby"
+            example: "moby"
+          Plugins:
+            description: |
+              The default containerd namespace used for plugins managed by
+              the daemon.
+
+              The default namespace for plugins is "plugins.moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "plugins.moby"
+            example: "plugins.moby"
+
+  FirewallInfo:
+    description: |
+      Information about the daemon's firewalling configuration.
+
+      This field is currently only used on Linux, and omitted on other platforms.
+    type: "object"
+    x-nullable: true
+    properties:
+      Driver:
+        description: |
+          The name of the firewall backend driver.
+        type: "string"
+        example: "nftables"
+      Info:
+        description: |
+          Information about the firewall backend, provided as
+          "label" / "value" pairs.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["ReloadedAt", "2025-01-01T00:00:00Z"]
+
+  # PluginsInfo is a temp struct holding Plugins name
+  # registered with docker daemon. It is used by Info struct
+  PluginsInfo:
+    description: |
+      Available plugins per type.
+
+      <p><br /></p>
+
+      > **Note**: Only unmanaged (V1) plugins are included in this list.
+      > V1 plugins are "lazily" loaded, and are not returned in this list
+      > if there is no resource using the plugin.
+    type: "object"
+    properties:
+      Volume:
+        description: "Names of available volume-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["local"]
+      Network:
+        description: "Names of available network-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["bridge", "host", "ipvlan", "macvlan", "null", "overlay"]
+      Authorization:
+        description: "Names of available authorization plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["img-authz-plugin", "hbm"]
+      Log:
+        description: "Names of available logging-drivers, and logging-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["awslogs", "fluentd", "gcplogs", "gelf", "journald", "json-file", "splunk", "syslog"]
+
+
+  RegistryServiceConfig:
+    description: |
+      RegistryServiceConfig stores daemon registry services configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      InsecureRegistryCIDRs:
+        description: |
+          List of IP ranges of insecure registries, using the CIDR syntax
+          ([RFC 4632](https://tools.ietf.org/html/4632)). Insecure registries
+          accept un-encrypted (HTTP) and/or untrusted (HTTPS with certificates
+          from unknown CAs) communication.
+
+          By default, local registries (`::1/128` and `127.0.0.0/8`) are configured as
+          insecure. All other registries are secure. Communicating with an
+          insecure registry is not possible if the daemon assumes that registry
+          is secure.
+
+          This configuration override this behavior, insecure communication with
+          registries whose resolved IP address is within the subnet described by
+          the CIDR syntax.
+
+          Registries can also be marked insecure by hostname. Those registries
+          are listed under `IndexConfigs` and have their `Secure` field set to
+          `false`.
+
+          > **Warning**: Using this option can be useful when running a local
+          > registry, but introduces security vulnerabilities. This option
+          > should therefore ONLY be used for testing purposes. For increased
+          > security, users should add their CA to their system's list of trusted
+          > CAs instead of enabling this option.
+        type: "array"
+        items:
+          type: "string"
+        example: ["::1/128", "127.0.0.0/8"]
+      IndexConfigs:
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/IndexInfo"
+        example:
+          "127.0.0.1:5000":
+            "Name": "127.0.0.1:5000"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "[2001:db8:a0b:12f0::1]:80":
+            "Name": "[2001:db8:a0b:12f0::1]:80"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "docker.io":
+            Name: "docker.io"
+            Mirrors: ["https://hub-mirror.corp.example.com:5000/"]
+            Secure: true
+            Official: true
+          "registry.internal.corp.example.com:3000":
+            Name: "registry.internal.corp.example.com:3000"
+            Mirrors: []
+            Secure: false
+            Official: false
+      Mirrors:
+        description: |
+          List of registry URLs that act as a mirror for the official
+          (`docker.io`) registry.
+
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://[2001:db8:a0b:12f0::1]/"
+
+  IndexInfo:
+    description:
+      IndexInfo contains information about a registry.
+    type: "object"
+    x-nullable: true
+    properties:
+      Name:
+        description: |
+          Name of the registry, such as "docker.io".
+        type: "string"
+        example: "docker.io"
+      Mirrors:
+        description: |
+          List of mirrors, expressed as URIs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://registry-2.docker.io/"
+          - "https://registry-3.docker.io/"
+      Secure:
+        description: |
+          Indicates if the registry is part of the list of insecure
+          registries.
+
+          If `false`, the registry is insecure. Insecure registries accept
+          un-encrypted (HTTP) and/or untrusted (HTTPS with certificates from
+          unknown CAs) communication.
+
+          > **Warning**: Insecure registries can be useful when running a local
+          > registry. However, because its use creates security vulnerabilities
+          > it should ONLY be enabled for testing purposes. For increased
+          > security, users should add their CA to their system's list of
+          > trusted CAs instead of enabling this option.
+        type: "boolean"
+        example: true
+      Official:
+        description: |
+          Indicates whether this is an official registry (i.e., Docker Hub / docker.io)
+        type: "boolean"
+        example: true
+
+  Runtime:
+    description: |
+      Runtime describes an [OCI compliant](https://github.com/opencontainers/runtime-spec)
+      runtime.
+
+      The runtime is invoked by the daemon via the `containerd` daemon. OCI
+      runtimes act as an interface to the Linux kernel namespaces, cgroups,
+      and SELinux.
+    type: "object"
+    properties:
+      path:
+        description: |
+          Name and, optional, path, of the OCI executable binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "/usr/local/bin/my-oci-runtime"
+      runtimeArgs:
+        description: |
+          List of command-line arguments to pass to the runtime when invoked.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["--debug", "--systemd-cgroup=false"]
+      status:
+        description: |
+          Information specific to the runtime.
+
+          While this API specification does not define data provided by runtimes,
+          the following well-known properties may be provided by runtimes:
+
+          `org.opencontainers.runtime-spec.features`: features structure as defined
+          in the [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec/blob/main/features.md),
+          in a JSON string representation.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "org.opencontainers.runtime-spec.features": "{\"ociVersionMin\":\"1.0.0\",\"ociVersionMax\":\"1.1.0\",\"...\":\"...\"}"
+
+  Commit:
+    description: |
+      Commit holds the Git-commit (SHA1) that a binary was built from, as
+      reported in the version-string of external tools, such as `containerd`,
+      or `runC`.
+    type: "object"
+    properties:
+      ID:
+        description: "Actual commit ID of external tool."
+        type: "string"
+        example: "cfb82a876ecc11b5ca0977d1733adbe58599088a"
+
+  SwarmInfo:
+    description: |
+      Represents generic information about swarm.
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+        default: ""
+        example: "k67qz4598weg5unwwffg6z1m1"
+      NodeAddr:
+        description: |
+          IP address at which this node can be reached by other nodes in the
+          swarm.
+        type: "string"
+        default: ""
+        example: "10.0.0.46"
+      LocalNodeState:
+        $ref: "#/definitions/LocalNodeState"
+      ControlAvailable:
+        type: "boolean"
+        default: false
+        example: true
+      Error:
+        type: "string"
+        default: ""
+      RemoteManagers:
+        description: |
+          List of ID's and addresses of other managers in the swarm.
+        type: "array"
+        default: null
+        x-nullable: true
+        items:
+          $ref: "#/definitions/PeerNode"
+        example:
+          - NodeID: "71izy0goik036k48jg985xnds"
+            Addr: "10.0.0.158:2377"
+          - NodeID: "79y6h1o4gv8n120drcprv5nmc"
+            Addr: "10.0.0.159:2377"
+          - NodeID: "k67qz4598weg5unwwffg6z1m1"
+            Addr: "10.0.0.46:2377"
+      Nodes:
+        description: "Total number of nodes in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 4
+      Managers:
+        description: "Total number of managers in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 3
+      Cluster:
+        $ref: "#/definitions/ClusterInfo"
+
+  LocalNodeState:
+    description: "Current local status of this node."
+    type: "string"
+    default: ""
+    enum:
+      - ""
+      - "inactive"
+      - "pending"
+      - "active"
+      - "error"
+      - "locked"
+    example: "active"
+
+  PeerNode:
+    description: "Represents a peer-node in the swarm"
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+      Addr:
+        description: |
+          IP address and ports at which this node can be reached.
+        type: "string"
+
+  NetworkAttachmentConfig:
+    description: |
+      Specifies how a service should be attached to a particular network.
+    type: "object"
+    properties:
+      Target:
+        description: |
+          The target network for attachment. Must be a network name or ID.
+        type: "string"
+      Aliases:
+        description: |
+          Discoverable alternate names for the service on this network.
+        type: "array"
+        items:
+          type: "string"
+      DriverOpts:
+        description: |
+          Driver attachment options for the network target.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  EventActor:
+    description: |
+      Actor describes something that generates events, like a container, network,
+      or a volume.
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the object emitting the event"
+        type: "string"
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Attributes:
+        description: |
+          Various key/value attributes of the object, depending on its type.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-label-value"
+          image: "alpine:latest"
+          name: "my-container"
+
+  EventMessage:
+    description: |
+      EventMessage represents the information an event contains.
+    type: "object"
+    title: "SystemEventsResponse"
+    properties:
+      Type:
+        description: "The type of object emitting the event"
+        type: "string"
+        enum: ["builder", "config", "container", "daemon", "image", "network", "node", "plugin", "secret", "service", "volume"]
+        example: "container"
+      Action:
+        description: "The type of event"
+        type: "string"
+        example: "create"
+      Actor:
+        $ref: "#/definitions/EventActor"
+      scope:
+        description: |
+          Scope of the event. Engine events are `local` scope. Cluster (Swarm)
+          events are `swarm` scope.
+        type: "string"
+        enum: ["local", "swarm"]
+      time:
+        description: "Timestamp of event"
+        type: "integer"
+        format: "int64"
+        example: 1629574695
+      timeNano:
+        description: "Timestamp of event, with nanosecond accuracy"
+        type: "integer"
+        format: "int64"
+        example: 1629574695515050031
+
+  OCIDescriptor:
+    type: "object"
+    x-go-name: Descriptor
+    description: |
+      A descriptor struct containing digest, media type, and size, as defined in
+      the [OCI Content Descriptors Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/descriptor.md).
+    properties:
+      mediaType:
+        description: |
+          The media type of the object this schema refers to.
+        type: "string"
+        example: "application/vnd.oci.image.manifest.v1+json"
+      digest:
+        description: |
+          The digest of the targeted content.
+        type: "string"
+        example: "sha256:c0537ff6a5218ef531ece93d4984efc99bbf3f7497c0a7726c88e2bb7584dc96"
+      size:
+        description: |
+          The size in bytes of the blob.
+        type: "integer"
+        format: "int64"
+        example: 424
+      urls:
+        description: |-
+          List of URLs from which this object MAY be downloaded.
+        type: "array"
+        items:
+          type: "string"
+          format: "uri"
+        x-nullable: true
+      annotations:
+        description: |-
+          Arbitrary metadata relating to the targeted content.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "com.docker.official-images.bashbrew.arch": "amd64"
+          "org.opencontainers.image.base.digest": "sha256:0d0ef5c914d3ea700147da1bd050c59edb8bb12ca312f3800b29d7c8087eabd8"
+          "org.opencontainers.image.base.name": "scratch"
+          "org.opencontainers.image.created": "2025-01-27T00:00:00Z"
+          "org.opencontainers.image.revision": "9fabb4bad5138435b01857e2fe9363e2dc5f6a79"
+          "org.opencontainers.image.source": "https://git.launchpad.net/cloud-images/+oci/ubuntu-base"
+          "org.opencontainers.image.url": "https://hub.docker.com/_/ubuntu"
+          "org.opencontainers.image.version": "24.04"
+      data:
+        type: string
+        x-nullable: true
+        description: |-
+          Data is an embedding of the targeted content. This is encoded as a base64
+          string when marshalled to JSON (automatically, by encoding/json). If
+          present, Data can be used directly to avoid fetching the targeted content.
+        example: null
+      platform:
+        $ref: "#/definitions/OCIPlatform"
+      artifactType:
+        description: |-
+          ArtifactType is the IANA media type of this artifact.
+        type: "string"
+        x-nullable: true
+        example: null
+
+  OCIPlatform:
+    type: "object"
+    x-go-name: Platform
+    x-nullable: true
+    description: |
+      Describes the platform which the image in the manifest runs on, as defined
+      in the [OCI Image Index Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/image-index.md).
+    properties:
+      architecture:
+        description: |
+          The CPU architecture, for example `amd64` or `ppc64`.
+        type: "string"
+        example: "arm"
+      os:
+        description: |
+          The operating system, for example `linux` or `windows`.
+        type: "string"
+        example: "windows"
+      os.version:
+        description: |
+          Optional field specifying the operating system version, for example on
+          Windows `10.0.19041.1165`.
+        type: "string"
+        example: "10.0.19041.1165"
+      os.features:
+        description: |
+          Optional field specifying an array of strings, each listing a required
+          OS feature (for example on Windows `win32k`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "win32k"
+      variant:
+        description: |
+          Optional field specifying a variant of the CPU, for example `v7` to
+          specify ARMv7 when architecture is `arm`.
+        type: "string"
+        example: "v7"
+
+  DistributionInspect:
+    type: "object"
+    x-go-name: DistributionInspect
+    title: "DistributionInspectResponse"
+    required: [Descriptor, Platforms]
+    description: |
+      Describes the result obtained from contacting the registry to retrieve
+      image metadata.
+    properties:
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Platforms:
+        type: "array"
+        description: |
+          An array containing all platforms supported by the image.
+        items:
+          $ref: "#/definitions/OCIPlatform"
+
+  ClusterVolume:
+    type: "object"
+    description: |
+      Options and information specific to, and only present on, Swarm CSI
+      cluster volumes.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          The Swarm ID of this volume. Because cluster volumes are Swarm
+          objects, they have an ID, unlike non-cluster volumes. This ID can
+          be used to refer to the Volume instead of the name.
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+      Info:
+        type: "object"
+        description: |
+          Information about the global status of the volume.
+        properties:
+          CapacityBytes:
+            type: "integer"
+            format: "int64"
+            description: |
+              The capacity of the volume in bytes. A value of 0 indicates that
+              the capacity is unknown.
+          VolumeContext:
+            type: "object"
+            description: |
+              A map of strings to strings returned from the storage plugin when
+              the volume is created.
+            additionalProperties:
+              type: "string"
+          VolumeID:
+            type: "string"
+            description: |
+              The ID of the volume as returned by the CSI storage plugin. This
+              is distinct from the volume's ID as provided by Docker. This ID
+              is never used by the user when communicating with Docker to refer
+              to this volume. If the ID is blank, then the Volume has not been
+              successfully created in the plugin yet.
+          AccessibleTopology:
+            type: "array"
+            description: |
+              The topology this volume is actually accessible from.
+            items:
+              $ref: "#/definitions/Topology"
+      PublishStatus:
+        type: "array"
+        description: |
+          The status of the volume as it pertains to its publishing and use on
+          specific nodes
+        items:
+          type: "object"
+          properties:
+            NodeID:
+              type: "string"
+              description: |
+                The ID of the Swarm node the volume is published on.
+            State:
+              type: "string"
+              description: |
+                The published state of the volume.
+                * `pending-publish` The volume should be published to this node, but the call to the controller plugin to do so has not yet been successfully completed.
+                * `published` The volume is published successfully to the node.
+                * `pending-node-unpublish` The volume should be unpublished from the node, and the manager is awaiting confirmation from the worker that it has done so.
+                * `pending-controller-unpublish` The volume is successfully unpublished from the node, but has not yet been successfully unpublished on the controller.
+              enum:
+                - "pending-publish"
+                - "published"
+                - "pending-node-unpublish"
+                - "pending-controller-unpublish"
+            PublishContext:
+              type: "object"
+              description: |
+                A map of strings to strings returned by the CSI controller
+                plugin when a volume is published.
+              additionalProperties:
+                type: "string"
+
+  ClusterVolumeSpec:
+    type: "object"
+    description: |
+      Cluster-specific options used to create the volume.
+    properties:
+      Group:
+        type: "string"
+        description: |
+          Group defines the volume group of this volume. Volumes belonging to
+          the same group can be referred to by group name when creating
+          Services.  Referring to a volume by group instructs Swarm to treat
+          volumes in that group interchangeably for the purpose of scheduling.
+          Volumes with an empty string for a group technically all belong to
+          the same, emptystring group.
+      AccessMode:
+        type: "object"
+        description: |
+          Defines how the volume is used by tasks.
+        properties:
+          Scope:
+            type: "string"
+            description: |
+              The set of nodes this volume can be used on at one time.
+              - `single` The volume may only be scheduled to one node at a time.
+              - `multi` the volume may be scheduled to any supported number of nodes at a time.
+            default: "single"
+            enum: ["single", "multi"]
+            x-nullable: false
+          Sharing:
+            type: "string"
+            description: |
+              The number and way that different tasks can use this volume
+              at one time.
+              - `none` The volume may only be used by one task at a time.
+              - `readonly` The volume may be used by any number of tasks, but they all must mount the volume as readonly
+              - `onewriter` The volume may be used by any number of tasks, but only one may mount it as read/write.
+              - `all` The volume may have any number of readers and writers.
+            default: "none"
+            enum: ["none", "readonly", "onewriter", "all"]
+            x-nullable: false
+          MountVolume:
+            type: "object"
+            description: |
+              Options for using this volume as a Mount-type volume.
+
+                  Either MountVolume or BlockVolume, but not both, must be
+                  present.
+                properties:
+                  FsType:
+                    type: "string"
+                    description: |
+                      Specifies the filesystem type for the mount volume.
+                      Optional.
+                  MountFlags:
+                    type: "array"
+                    description: |
+                      Flags to pass when mounting the volume. Optional.
+                    items:
+                      type: "string"
+              BlockVolume:
+                type: "object"
+                description: |
+                  Options for using this volume as a Block-type volume.
+                  Intentionally empty.
+          Secrets:
+            type: "array"
+            description: |
+              Swarm Secrets that are passed to the CSI storage plugin when
+              operating on this volume.
+            items:
+              type: "object"
+              description: |
+                One cluster volume secret entry. Defines a key-value pair that
+                is passed to the plugin.
+              properties:
+                Key:
+                  type: "string"
+                  description: |
+                    Key is the name of the key of the key-value pair passed to
+                    the plugin.
+                Secret:
+                  type: "string"
+                  description: |
+                    Secret is the swarm Secret object from which to read data.
+                    This can be a Secret name or ID. The Secret data is
+                    retrieved by swarm and used as the value of the key-value
+                    pair passed to the plugin.
+          AccessibilityRequirements:
+            type: "object"
+            description: |
+              Requirements for the accessible topology of the volume. These
+              fields are optional. For an in-depth description of what these
+              fields mean, see the CSI specification.
+            properties:
+              Requisite:
+                type: "array"
+                description: |
+                  A list of required topologies, at least one of which the
+                  volume must be accessible from.
+                items:
+                  $ref: "#/definitions/Topology"
+              Preferred:
+                type: "array"
+                description: |
+                  A list of topologies that the volume should attempt to be
+                  provisioned in.
+                items:
+                  $ref: "#/definitions/Topology"
+          CapacityRange:
+            type: "object"
+            description: |
+              The desired capacity that the volume should be created with. If
+              empty, the plugin will decide the capacity.
+            properties:
+              RequiredBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must be at least this big. The value of 0
+                  indicates an unspecified minimum
+              LimitBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must not be bigger than this. The value of 0
+                  indicates an unspecified maximum.
+          Availability:
+            type: "string"
+            description: |
+              The availability of the volume for use in tasks.
+              - `active` The volume is fully available for scheduling on the cluster
+              - `pause` No new workloads should use the volume, but existing workloads are not stopped.
+              - `drain` All workloads using this volume should be stopped and rescheduled, and no new ones should be started.
+            default: "active"
+            x-nullable: false
+            enum:
+              - "active"
+              - "pause"
+              - "drain"
+
+  Topology:
+    description: |
+      A map of topological domains to topological segments. For in depth
+      details, see documentation for the Topology object in the CSI
+      specification.
+    type: "object"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  ImageManifestSummary:
+    x-go-name: "ManifestSummary"
+    description: |
+      ImageManifestSummary represents a summary of an image manifest.
+    type: "object"
+    required: ["ID", "Descriptor", "Available", "Size", "Kind"]
+    properties:
+      ID:
+        description: |
+          ID is the content-addressable ID of an image and is the same as the
+          digest of the image manifest.
+        type: "string"
+        example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Available:
+        description: Indicates whether all the child content (image config, layers) is fully available locally.
+        type: "boolean"
+        example: true
+      Size:
+        type: "object"
+        x-nullable: false
+        required: ["Content", "Total"]
+        properties:
+          Total:
+            type: "integer"
+            format: "int64"
+            example: 8213251
+            description: |
+              Total is the total size (in bytes) of all the locally present
+              data (both distributable and non-distributable) that's related to
+              this manifest and its children.
+              This equal to the sum of [Content] size AND all the sizes in the
+              [Size] struct present in the Kind-specific data struct.
+              For example, for an image kind (Kind == "image")
+              this would include the size of the image content and unpacked
+              image snapshots ([Size.Content] + [ImageData.Size.Unpacked]).
+          Content:
+            description: |
+              Content is the size (in bytes) of all the locally present
+              content in the content store (e.g. image config, layers)
+              referenced by this manifest and its children.
+              This only includes blobs in the content store.
+            type: "integer"
+            format: "int64"
+            example: 3987495
+      Kind:
+        type: "string"
+        example: "image"
+        enum:
+          - "image"
+          - "attestation"
+          - "unknown"
+        description: |
+          The kind of the manifest.
+
+          kind         | description
+          -------------|-----------------------------------------------------------
+          image        | Image manifest that can be used to start a container.
+          attestation  | Attestation manifest produced by the Buildkit builder for a specific image manifest.
+      ImageData:
+        description: |
+          The image data for the image manifest.
+          This field is only populated when Kind is "image".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["Platform", "Containers", "Size", "UnpackedSize"]
+        properties:
+          Platform:
+            $ref: "#/definitions/OCIPlatform"
+            description: |
+              OCI platform of the image. This will be the platform specified in the
+              manifest descriptor from the index/manifest list.
+              If it's not available, it will be obtained from the image config.
+          Containers:
+            description: |
+              The IDs of the containers that are using this image.
+            type: "array"
+            items:
+              type: "string"
+            example: ["ede54ee1fda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c7430", "abadbce344c096744d8d6071a90d474d28af8f1034b5ea9fb03c3f4bfc6d005e"]
+          Size:
+            type: "object"
+            x-nullable: false
+            required: ["Unpacked"]
+            properties:
+              Unpacked:
+                type: "integer"
+                format: "int64"
+                example: 3987495
+                description: |
+                  Unpacked is the size (in bytes) of the locally unpacked
+                  (uncompressed) image content that's directly usable by the containers
+                  running this image.
+                  It's independent of the distributable content - e.g.
+                  the image might still have an unpacked data that's still used by
+                  some container even when the distributable/compressed content is
+                  already gone.
+      AttestationData:
+        description: |
+          The image data for the attestation manifest.
+          This field is only populated when Kind is "attestation".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["For"]
+        properties:
+          For:
+            description: |
+              The digest of the image manifest that this attestation is for.
+            type: "string"
+            example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+
+paths:
+  /containers/json:
+    get:
+      summary: "List containers"
+      description: |
+        Returns a list of containers. For details on the format, see the
+        [inspect endpoint](#operation/ContainerInspect).
+
+        Note that it uses a different, smaller representation of a container
+        than inspecting a single container. For example, the list of linked
+        containers is not propagated .
+      operationId: "ContainerList"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: |
+            Return all containers. By default, only running containers are shown.
+          type: "boolean"
+          default: false
+        - name: "limit"
+          in: "query"
+          description: |
+            Return this number of most recently created containers, including
+            non-running ones.
+          type: "integer"
+        - name: "size"
+          in: "query"
+          description: |
+            Return the size of container as fields `SizeRw` and `SizeRootFs`.
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the container list, encoded as JSON (a
+            `map[string][]string`). For example, `{"status": ["paused"]}` will
+            only return paused containers.
+
+            Available filters:
+
+            - `ancestor`=(`<image-name>[:<tag>]`, `<image id>`, or `<image@digest>`)
+            - `before`=(`<container id>` or `<container name>`)
+            - `expose`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `exited=<int>` containers with exit code of `<int>`
+            - `health`=(`starting`|`healthy`|`unhealthy`|`none`)
+            - `id=<ID>` a container's ID
+            - `isolation=`(`default`|`process`|`hyperv`) (Windows daemon only)
+            - `is-task=`(`true`|`false`)
+            - `label=key` or `label="key=value"` of a container label
+            - `name=<name>` a container's name
+            - `network`=(`<network id>` or `<network name>`)
+            - `publish`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `since`=(`<container id>` or `<container name>`)
+            - `status=`(`created`|`restarting`|`running`|`removing`|`paused`|`exited`|`dead`)
+            - `volume`=(`<volume name>` or `<mount point destination>`)
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ContainerSummary"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/create:
+    post:
+      summary: "Create a container"
+      operationId: "ContainerCreate"
+      consumes:
+        - "application/json"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            Assign the specified name to the container. Must match
+            `/?[a-zA-Z0-9][a-zA-Z0-9_.-]+`.
+          type: "string"
+          pattern: "^/?[a-zA-Z0-9][a-zA-Z0-9_.-]+$"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format `os[/arch[/variant]]` used for image lookup.
+
+            When specified, the daemon checks if the requested image is present
+            in the local image cache with the given OS and Architecture, and
+            otherwise returns a `404` status.
+
+            If the option is not set, the host's native OS and Architecture are
+            used to look up the image in the image cache. However, if no platform
+            is passed and the given image does exist in the local image cache,
+            but its OS or architecture does not match, the container is created
+            with the available image, and a warning is added to the `Warnings`
+            field in the response, for example;
+
+                WARNING: The requested image's platform (linux/arm64/v8) does not
+                         match the detected host platform (linux/amd64) and no
+                         specific platform was requested
+
+          type: "string"
+          default: ""
+        - name: "body"
+          in: "body"
+          description: "Container to create"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ContainerConfig"
+              - type: "object"
+                properties:
+                  HostConfig:
+                    $ref: "#/definitions/HostConfig"
+                  NetworkingConfig:
+                    $ref: "#/definitions/NetworkingConfig"
+            example:
+              Hostname: ""
+              Domainname: ""
+              User: ""
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              Tty: false
+              OpenStdin: false
+              StdinOnce: false
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+              Cmd:
+                - "date"
+              Entrypoint: ""
+              Image: "ubuntu"
+              Labels:
+                com.example.vendor: "Acme"
+                com.example.license: "GPL"
+                com.example.version: "1.0"
+              Volumes:
+                /volumes/data: {}
+              WorkingDir: ""
+              NetworkDisabled: false
+              ExposedPorts:
+                22/tcp: {}
+              StopSignal: "SIGTERM"
+              StopTimeout: 10
+              HostConfig:
+                Binds:
+                  - "/tmp:/tmp"
+                Links:
+                  - "redis3:redis"
+                Memory: 0
+                MemorySwap: 0
+                MemoryReservation: 0
+                NanoCpus: 500000
+                CpuPercent: 80
+                CpuShares: 512
+                CpuPeriod: 100000
+                CpuRealtimePeriod: 1000000
+                CpuRealtimeRuntime: 10000
+                CpuQuota: 50000
+                CpusetCpus: "0,1"
+                CpusetMems: "0,1"
+                MaximumIOps: 0
+                MaximumIOBps: 0
+                BlkioWeight: 300
+                BlkioWeightDevice:
+                  - {}
+                BlkioDeviceReadBps:
+                  - {}
+                BlkioDeviceReadIOps:
+                  - {}
+                BlkioDeviceWriteBps:
+                  - {}
+                BlkioDeviceWriteIOps:
+                  - {}
+                DeviceRequests:
+                  - Driver: "nvidia"
+                    Count: -1
+                    DeviceIDs": ["0", "1", "GPU-fef8089b-4820-abfc-e83e-94318197576e"]
+                    Capabilities: [["gpu", "nvidia", "compute"]]
+                    Options:
+                      property1: "string"
+                      property2: "string"
+                MemorySwappiness: 60
+                OomKillDisable: false
+                OomScoreAdj: 500
+                PidMode: ""
+                PidsLimit: 0
+                PortBindings:
+                  22/tcp:
+                    - HostPort: "11022"
+                PublishAllPorts: false
+                Privileged: false
+                ReadonlyRootfs: false
+                Dns:
+                  - "8.8.8.8"
+                DnsOptions:
+                  - ""
+                DnsSearch:
+                  - ""
+                VolumesFrom:
+                  - "parent"
+                  - "other:ro"
+                CapAdd:
+                  - "NET_ADMIN"
+                CapDrop:
+                  - "MKNOD"
+                GroupAdd:
+                  - "newgroup"
+                RestartPolicy:
+                  Name: ""
+                  MaximumRetryCount: 0
+                AutoRemove: true
+                NetworkMode: "bridge"
+                Devices: []
+                Ulimits:
+                  - {}
+                LogConfig:
+                  Type: "json-file"
+                  Config: {}
+                SecurityOpt: []
+                StorageOpt: {}
+                CgroupParent: ""
+                VolumeDriver: ""
+                ShmSize: 67108864
+              NetworkingConfig:
+                EndpointsConfig:
+                  isolated_nw:
+                    IPAMConfig:
+                      IPv4Address: "172.20.30.33"
+                      IPv6Address: "2001:db8:abcd::3033"
+                      LinkLocalIPs:
+                        - "169.254.34.68"
+                        - "fe80::3468"
+                    Links:
+                      - "container_1"
+                      - "container_2"
+                    Aliases:
+                      - "server_x"
+                      - "server_y"
+                  database_nw: {}
+
+          required: true
+      responses:
+        201:
+          description: "Container created successfully"
+          schema:
+            $ref: "#/definitions/ContainerCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/{id}/json:
+    get:
+      summary: "Inspect a container"
+      description: "Return low-level information about a container."
+      operationId: "ContainerInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerInspectResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "size"
+          in: "query"
+          type: "boolean"
+          default: false
+          description: "Return the size of container as fields `SizeRw` and `SizeRootFs`"
+      tags: ["Container"]
+  /containers/{id}/top:
+    get:
+      summary: "List processes running inside a container"
+      description: |
+        On Unix systems, this is done by running the `ps` command. This endpoint
+        is not supported on Windows.
+      operationId: "ContainerTop"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerTopResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "ps_args"
+          in: "query"
+          description: "The arguments to pass to `ps`. For example, `aux`"
+          type: "string"
+          default: "-ef"
+      tags: ["Container"]
+  /containers/{id}/logs:
+    get:
+      summary: "Get container logs"
+      description: |
+        Get `stdout` and `stderr` logs from a container.
+
+        Note: This endpoint works only for containers with the `json-file` or
+        `journald` logging driver.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ContainerLogs"
+      responses:
+        200:
+          description: |
+            logs returned as a stream in response body.
+            For the stream format, [see the documentation for the attach endpoint](#operation/ContainerAttach).
+            Note that unlike the attach endpoint, the logs endpoint does not
+            upgrade the connection and does not set Content-Type.
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "until"
+          in: "query"
+          description: "Only return logs before this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Container"]
+  /containers/{id}/changes:
+    get:
+      summary: "Get changes on a container’s filesystem"
+      description: |
+        Returns which files in a container's filesystem have been added, deleted,
+        or modified. The `Kind` of modification can be one of:
+
+        - `0`: Modified ("C")
+        - `1`: Added ("A")
+        - `2`: Deleted ("D")
+      operationId: "ContainerChanges"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The list of changes"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/FilesystemChange"
+          examples:
+            application/json:
+              - Path: "/dev"
+                Kind: 0
+              - Path: "/dev/kmsg"
+                Kind: 1
+              - Path: "/test"
+                Kind: 1
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/export:
+    get:
+      summary: "Export a container"
+      description: "Export the contents of a container as a tarball."
+      operationId: "ContainerExport"
+      produces:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stats:
+    get:
+      summary: "Get container stats based on resource usage"
+      description: |
+        This endpoint returns a live stream of a container’s resource usage
+        statistics.
+
+        The `precpu_stats` is the CPU statistic of the *previous* read, and is
+        used to calculate the CPU usage percentage. It is not an exact copy
+        of the `cpu_stats` field.
+
+        If either `precpu_stats.online_cpus` or `cpu_stats.online_cpus` is
+        nil then for compatibility with older daemons the length of the
+        corresponding `cpu_usage.percpu_usage` array should be used.
+
+        On a cgroup v2 host, the following fields are not set
+        * `blkio_stats`: all fields other than `io_service_bytes_recursive`
+        * `cpu_stats`: `cpu_usage.percpu_usage`
+        * `memory_stats`: `max_usage` and `failcnt`
+        Also, `memory_stats.stats` fields are incompatible with cgroup v1.
+
+        To calculate the values shown by the `stats` command of the docker cli tool
+        the following formulas can be used:
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
+        * available_memory = `memory_stats.limit`
+        * Memory usage % = `(used_memory / available_memory) * 100.0`
+        * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
+        * system_cpu_delta = `cpu_stats.system_cpu_usage - precpu_stats.system_cpu_usage`
+        * number_cpus = `length(cpu_stats.cpu_usage.percpu_usage)` or `cpu_stats.online_cpus`
+        * CPU usage % = `(cpu_delta / system_cpu_delta) * number_cpus * 100.0`
+      operationId: "ContainerStats"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerStatsResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream the output. If false, the stats will be output once and then
+            it will disconnect.
+          type: "boolean"
+          default: true
+        - name: "one-shot"
+          in: "query"
+          description: |
+            Only get a single stat instead of waiting for 2 cycles. Must be used
+            with `stream=false`.
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/resize:
+    post:
+      summary: "Resize a container TTY"
+      description: "Resize the TTY for a container."
+      operationId: "ContainerResize"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "cannot resize container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/start:
+    post:
+      summary: "Start a container"
+      operationId: "ContainerStart"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already started"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container. Format is a
+            single character `[a-Z]` or `ctrl-<value>` where `<value>` is one
+            of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stop:
+    post:
+      summary: "Stop a container"
+      operationId: "ContainerStop"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already stopped"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/restart:
+    post:
+      summary: "Restart a container"
+      operationId: "ContainerRestart"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/kill:
+    post:
+      summary: "Kill a container"
+      description: |
+        Send a POSIX signal to a container, defaulting to killing to the
+        container.
+      operationId: "ContainerKill"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is not running"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "Container d37cde0fe4ad63c3a7252023b2f9800282894247d145cb5933ddf6e52cc03a28 is not running"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+          default: "SIGKILL"
+      tags: ["Container"]
+  /containers/{id}/update:
+    post:
+      summary: "Update a container"
+      description: |
+        Change various configuration options of a container without having to
+        recreate it.
+      operationId: "ContainerUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has been updated."
+          schema:
+            $ref: "#/definitions/ContainerUpdateResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "update"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/Resources"
+              - type: "object"
+                properties:
+                  RestartPolicy:
+                    $ref: "#/definitions/RestartPolicy"
+            example:
+              BlkioWeight: 300
+              CpuShares: 512
+              CpuPeriod: 100000
+              CpuQuota: 50000
+              CpuRealtimePeriod: 1000000
+              CpuRealtimeRuntime: 10000
+              CpusetCpus: "0,1"
+              CpusetMems: "0"
+              Memory: 314572800
+              MemorySwap: 514288000
+              MemoryReservation: 209715200
+              RestartPolicy:
+                MaximumRetryCount: 4
+                Name: "on-failure"
+      tags: ["Container"]
+  /containers/{id}/rename:
+    post:
+      summary: "Rename a container"
+      operationId: "ContainerRename"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "name already in use"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "name"
+          in: "query"
+          required: true
+          description: "New name for the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/pause:
+    post:
+      summary: "Pause a container"
+      description: |
+        Use the freezer cgroup to suspend all processes in a container.
+
+        Traditionally, when suspending a process the `SIGSTOP` signal is used,
+        which is observable by the process being suspended. With the freezer
+        cgroup the process is unaware, and unable to capture, that it is being
+        suspended, and subsequently resumed.
+      operationId: "ContainerPause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/unpause:
+    post:
+      summary: "Unpause a container"
+      description: "Resume a container which has been paused."
+      operationId: "ContainerUnpause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/attach:
+    post:
+      summary: "Attach to a container"
+      description: |
+        Attach to a container to read its output or send it input. You can attach
+        to the same container multiple times and you can reattach to containers
+        that have been detached.
+
+        Either the `stream` or `logs` parameter must be `true` for this endpoint
+        to do anything.
+
+        See the [documentation for the `docker attach` command](https://docs.docker.com/engine/reference/commandline/attach/)
+        for more details.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to transport `stdin`, `stdout`,
+        and `stderr` on the same socket.
+
+        This is the response from the daemon for an attach request:
+
+        ```
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        [STREAM]
+        ```
+
+        After the headers and two new lines, the TCP connection can now be used
+        for raw, bidirectional communication between the client and server.
+
+        To hint potential proxies about connection hijacking, the Docker client
+        can also optionally send connection upgrade headers.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /containers/16253994b7c4/attach?stream=1&stdout=1 HTTP/1.1
+        Upgrade: tcp
+        Connection: Upgrade
+        ```
+
+        The Docker daemon will respond with a `101 UPGRADED` response, and will
+        similarly follow with the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Content-Type: application/vnd.docker.raw-stream
+        Connection: Upgrade
+        Upgrade: tcp
+
+        [STREAM]
+        ```
+
+        ### Stream format
+
+        When the TTY setting is disabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the HTTP Content-Type header is set to application/vnd.docker.multiplexed-stream
+        and the stream over the hijacked connected is multiplexed to separate out
+        `stdout` and `stderr`. The stream consists of a series of frames, each
+        containing a header and a payload.
+
+        The header contains the information which the stream writes (`stdout` or
+        `stderr`). It also contains the size of the associated frame encoded in
+        the last four bytes (`uint32`).
+
+        It is encoded on the first eight bytes like this:
+
+        ```go
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+        ```
+
+        `STREAM_TYPE` can be:
+
+        - 0: `stdin` (is written on `stdout`)
+        - 1: `stdout`
+        - 2: `stderr`
+
+        `SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of the `uint32` size
+        encoded as big endian.
+
+        Following the header is the payload, which is the specified number of
+        bytes of `STREAM_TYPE`.
+
+        The simplest way to implement this protocol is the following:
+
+        1. Read 8 bytes.
+        2. Choose `stdout` or `stderr` depending on the first byte.
+        3. Extract the frame size from the last four bytes.
+        4. Read the extracted size and output it on the correct output.
+        5. Goto 1.
+
+        ### Stream format when using a TTY
+
+        When the TTY setting is enabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the stream is not multiplexed. The data exchanged over the hijacked
+        connection is simply the raw data from the process PTY and client's
+        `stdin`.
+
+      operationId: "ContainerAttach"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: |
+            Replay previous logs from the container.
+
+            This is useful for attaching to a container that has started and you
+            want to output everything since the container started.
+
+            If `stream` is also enabled, once all the previous output has been
+            returned, it will seamlessly transition into streaming current
+            output.
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream attached streams from the time the request was made onwards.
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/attach/ws:
+    get:
+      summary: "Attach to a container via a websocket"
+      operationId: "ContainerAttachWebsocket"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,`, or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: "Return logs"
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: "Return stream"
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/wait:
+    post:
+      summary: "Wait for a container"
+      description: "Block until a container stops, then returns the exit code."
+      operationId: "ContainerWait"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has exit."
+          schema:
+            $ref: "#/definitions/ContainerWaitResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "condition"
+          in: "query"
+          description: |
+            Wait until a container state reaches the given condition.
+
+            Defaults to `not-running` if omitted or empty.
+          type: "string"
+          enum:
+            - "not-running"
+            - "next-exit"
+            - "removed"
+          default: "not-running"
+      tags: ["Container"]
+  /containers/{id}:
+    delete:
+      summary: "Remove a container"
+      operationId: "ContainerDelete"
+      responses:
+        204:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: |
+                You cannot remove a running container: c2ada9df5af8. Stop the
+                container before attempting removal or force remove
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "v"
+          in: "query"
+          description: "Remove anonymous volumes associated with the container."
+          type: "boolean"
+          default: false
+        - name: "force"
+          in: "query"
+          description: "If the container is running, kill it before removing it."
+          type: "boolean"
+          default: false
+        - name: "link"
+          in: "query"
+          description: "Remove the specified link associated with the container."
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/archive:
+    head:
+      summary: "Get information about files in a container"
+      description: |
+        A response header `X-Docker-Container-Path-Stat` is returned, containing
+        a base64 - encoded JSON object with some filesystem header information
+        about the path.
+      operationId: "ContainerArchiveInfo"
+      responses:
+        200:
+          description: "no error"
+          headers:
+            X-Docker-Container-Path-Stat:
+              type: "string"
+              description: |
+                A base64 - encoded JSON object with some filesystem header
+                information about the path
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    get:
+      summary: "Get an archive of a filesystem resource in a container"
+      description: "Get a tar archive of a resource in the filesystem of container id."
+      operationId: "ContainerArchive"
+      produces: ["application/x-tar"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    put:
+      summary: "Extract an archive of files or folders to a directory in a container"
+      description: |
+        Upload a tar archive to be extracted to a path in the filesystem of container id.
+        `path` parameter is asserted to be a directory. If it exists as a file, 400 error
+        will be returned with message "not a directory".
+      operationId: "PutContainerArchive"
+      consumes: ["application/x-tar", "application/octet-stream"]
+      responses:
+        200:
+          description: "The content was extracted successfully"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "not a directory"
+        403:
+          description: "Permission denied, the volume or container rootfs is marked as read-only."
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such container or path does not exist inside the container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Path to a directory in the container to extract the archive’s contents into. "
+          type: "string"
+        - name: "noOverwriteDirNonDir"
+          in: "query"
+          description: |
+            If `1`, `true`, or `True` then it will be an error if unpacking the
+            given content would cause an existing directory to be replaced with
+            a non-directory and vice versa.
+          type: "string"
+        - name: "copyUIDGID"
+          in: "query"
+          description: |
+            If `1`, `true`, then it will copy UID/GID maps to the dest file or
+            dir
+          type: "string"
+        - name: "inputStream"
+          in: "body"
+          required: true
+          description: |
+            The input stream must be a tar archive compressed with one of the
+            following algorithms: `identity` (no compression), `gzip`, `bzip2`,
+            or `xz`.
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Container"]
+  /containers/prune:
+    post:
+      summary: "Delete stopped containers"
+      produces:
+        - "application/json"
+      operationId: "ContainerPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune containers created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune containers with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ContainerPruneResponse"
+            properties:
+              ContainersDeleted:
+                description: "Container IDs that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /images/json:
+    get:
+      summary: "List Images"
+      description: "Returns a list of images on the server. Note that it uses a different, smaller representation of an image than inspecting a single image."
+      operationId: "ImageList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "Summary image data for the images matching the query"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageSummary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: "Show all images. Only images from a final layer (no children) are shown by default."
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the images list.
+
+            Available filters:
+
+            - `before`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `dangling=true`
+            - `label=key` or `label="key=value"` of an image label
+            - `reference`=(`<image-name>[:<tag>]`)
+            - `since`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `until=<timestamp>`
+          type: "string"
+        - name: "shared-size"
+          in: "query"
+          description: "Compute and show shared size as a `SharedSize` field on each image."
+          type: "boolean"
+          default: false
+        - name: "digests"
+          in: "query"
+          description: "Show digest information as a `RepoDigests` field on each image."
+          type: "boolean"
+          default: false
+        - name: "manifests"
+          in: "query"
+          description: "Include `Manifests` in the image summary."
+          type: "boolean"
+          default: false
+      tags: ["Image"]
+  /build:
+    post:
+      summary: "Build an image"
+      description: |
+        Build an image from a tar archive with a `Dockerfile` in it.
+
+        The `Dockerfile` specifies how the image is built from the tar archive. It is typically in the archive's root, but can be at a different path or have a different name by specifying the `dockerfile` parameter. [See the `Dockerfile` reference for more information](https://docs.docker.com/engine/reference/builder/).
+
+        The Docker daemon performs a preliminary validation of the `Dockerfile` before starting the build, and returns an error if the syntax is incorrect. After that, each instruction is run one-by-one until the ID of the new image is output.
+
+        The build is canceled if the client drops the connection by quitting or being killed.
+      operationId: "ImageBuild"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "inputStream"
+          in: "body"
+          description: "A tar archive compressed with one of the following algorithms: identity (no compression), gzip, bzip2, xz."
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "dockerfile"
+          in: "query"
+          description: "Path within the build context to the `Dockerfile`. This is ignored if `remote` is specified and points to an external `Dockerfile`."
+          type: "string"
+          default: "Dockerfile"
+        - name: "t"
+          in: "query"
+          description: "A name and optional tag to apply to the image in the `name:tag` format. If you omit the tag the default `latest` value is assumed. You can provide several `t` parameters."
+          type: "string"
+        - name: "extrahosts"
+          in: "query"
+          description: "Extra hosts to add to /etc/hosts"
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: "A Git repository URI or HTTP/HTTPS context URI. If the URI points to a single text file, the file’s contents are placed into a file called `Dockerfile` and the image is built from that file. If the URI points to a tarball, the file is downloaded by the daemon and the contents therein used as the context for the build. If the URI points to a tarball and the `dockerfile` parameter is also specified, there must be a file with the corresponding path inside the tarball."
+          type: "string"
+        - name: "q"
+          in: "query"
+          description: "Suppress verbose build output."
+          type: "boolean"
+          default: false
+        - name: "nocache"
+          in: "query"
+          description: "Do not use the cache when building the image."
+          type: "boolean"
+          default: false
+        - name: "cachefrom"
+          in: "query"
+          description: "JSON array of images used for build cache resolution."
+          type: "string"
+        - name: "pull"
+          in: "query"
+          description: "Attempt to pull the image even if an older image exists locally."
+          type: "string"
+        - name: "rm"
+          in: "query"
+          description: "Remove intermediate containers after a successful build."
+          type: "boolean"
+          default: true
+        - name: "forcerm"
+          in: "query"
+          description: "Always remove intermediate containers, even upon failure."
+          type: "boolean"
+          default: false
+        - name: "memory"
+          in: "query"
+          description: "Set memory limit for build."
+          type: "integer"
+        - name: "memswap"
+          in: "query"
+          description: "Total memory (memory + swap). Set as `-1` to disable swap."
+          type: "integer"
+        - name: "cpushares"
+          in: "query"
+          description: "CPU shares (relative weight)."
+          type: "integer"
+        - name: "cpusetcpus"
+          in: "query"
+          description: "CPUs in which to allow execution (e.g., `0-3`, `0,1`)."
+          type: "string"
+        - name: "cpuperiod"
+          in: "query"
+          description: "The length of a CPU period in microseconds."
+          type: "integer"
+        - name: "cpuquota"
+          in: "query"
+          description: "Microseconds of CPU time that the container can get in a CPU period."
+          type: "integer"
+        - name: "buildargs"
+          in: "query"
+          description: >
+            JSON map of string pairs for build-time variables. Users pass these values at build-time. Docker
+            uses the buildargs as the environment context for commands run via the `Dockerfile` RUN
+            instruction, or for variable expansion in other `Dockerfile` instructions. This is not meant for
+            passing secret values.
+
+
+            For example, the build arg `FOO=bar` would become `{"FOO":"bar"}` in JSON. This would result in the
+            query parameter `buildargs={"FOO":"bar"}`. Note that `{"FOO":"bar"}` should be URI component encoded.
+
+
+            [Read more about the buildargs instruction.](https://docs.docker.com/engine/reference/builder/#arg)
+          type: "string"
+        - name: "shmsize"
+          in: "query"
+          description: "Size of `/dev/shm` in bytes. The size must be greater than 0. If omitted the system uses 64MB."
+          type: "integer"
+        - name: "squash"
+          in: "query"
+          description: "Squash the resulting images layers into a single layer. *(Experimental release only.)*"
+          type: "boolean"
+        - name: "labels"
+          in: "query"
+          description: "Arbitrary key/value labels to set on the image, as a JSON map of string pairs."
+          type: "string"
+        - name: "networkmode"
+          in: "query"
+          description: |
+            Sets the networking mode for the run commands during build. Supported
+            standard values are: `bridge`, `host`, `none`, and `container:<name|id>`.
+            Any other value is taken as a custom network's name or ID to which this
+            container should connect to.
+          type: "string"
+        - name: "Content-type"
+          in: "header"
+          type: "string"
+          enum:
+            - "application/x-tar"
+          default: "application/x-tar"
+        - name: "X-Registry-Config"
+          in: "header"
+          description: |
+            This is a base64-encoded JSON object with auth configurations for multiple registries that a build may refer to.
+
+            The key is a registry URL, and the value is an auth configuration object, [as described in the authentication section](#section/Authentication). For example:
+
+            ```
+            {
+              "docker.example.com": {
+                "username": "janedoe",
+                "password": "hunter2"
+              },
+              "https://index.docker.io/v1/": {
+                "username": "mobydock",
+                "password": "conta1n3rize14"
+              }
+            }
+            ```
+
+            Only the registry domain name (and port if not the default 443) are required. However, for legacy reasons, the Docker Hub registry must be specified with both a `https://` prefix and a `/v1/` suffix even though Docker will prefer to use the v2 registry API.
+          type: "string"
+        - name: "platform"
+          in: "query"
+          description: "Platform in the format os[/arch[/variant]]"
+          type: "string"
+          default: ""
+        - name: "target"
+          in: "query"
+          description: "Target build stage"
+          type: "string"
+          default: ""
+        - name: "outputs"
+          in: "query"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
+          type: "string"
+          default: ""
+        - name: "version"
+          in: "query"
+          type: "string"
+          default: "1"
+          enum: ["1", "2"]
+          description: |
+            Version of the builder backend to use.
+
+            - `1` is the first generation classic (deprecated) builder in the Docker daemon (default)
+            - `2` is [BuildKit](https://github.com/moby/buildkit)
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /build/prune:
+    post:
+      summary: "Delete builder cache"
+      produces:
+        - "application/json"
+      operationId: "BuildPrune"
+      parameters:
+        - name: "reserved-space"
+          in: "query"
+          description: "Amount of disk space in bytes to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "max-used-space"
+          in: "query"
+          description: "Maximum amount of disk space allowed to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "min-free-space"
+          in: "query"
+          description: "Target amount of free disk space after pruning"
+          type: "integer"
+          format: "int64"
+        - name: "all"
+          in: "query"
+          type: "boolean"
+          description: "Remove all types of build cache"
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the list of build cache objects.
+
+            Available filters:
+
+            - `until=<timestamp>` remove cache older than `<timestamp>`. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon's local time.
+            - `id=<id>`
+            - `parent=<id>`
+            - `type=<string>`
+            - `description=<string>`
+            - `inuse`
+            - `shared`
+            - `private`
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "BuildPruneResponse"
+            properties:
+              CachesDeleted:
+                type: "array"
+                items:
+                  description: "ID of build cache object"
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /images/create:
+    post:
+      summary: "Create an image"
+      description: "Pull or import an image."
+      operationId: "ImageCreate"
+      consumes:
+        - "text/plain"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "repository does not exist or no read access"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "fromImage"
+          in: "query"
+          description: |
+            Name of the image to pull. If the name includes a tag or digest, specific behavior applies:
+
+            - If only `fromImage` includes a tag, that tag is used.
+            - If both `fromImage` and `tag` are provided, `tag` takes precedence.
+            - If `fromImage` includes a digest, the image is pulled by digest, and `tag` is ignored.
+            - If neither a tag nor digest is specified, all tags are pulled.
+          type: "string"
+        - name: "fromSrc"
+          in: "query"
+          description: "Source to import. The value may be a URL from which the image can be retrieved or `-` to read the image from the request body. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name given to an image when it is imported. The repo may include a tag. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag or digest. If empty when pulling an image, this causes all tags for the given image to be pulled."
+          type: "string"
+        - name: "message"
+          in: "query"
+          description: "Set commit message for imported image."
+          type: "string"
+        - name: "inputImage"
+          in: "body"
+          description: "Image content if the value `-` has been specified in fromSrc query parameter"
+          schema:
+            type: "string"
+          required: false
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "changes"
+          in: "query"
+          description: |
+            Apply `Dockerfile` instructions to the image that is created,
+            for example: `changes=ENV DEBUG=true`.
+            Note that `ENV DEBUG=true` should be URI component encoded.
+
+            Supported `Dockerfile` instructions:
+            `CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format os[/arch[/variant]].
+
+            When used in combination with the `fromImage` option, the daemon checks
+            if the given image is present in the local image cache with the given
+            OS and Architecture, and otherwise attempts to pull the image. If the
+            option is not set, the host's native OS and Architecture are used.
+            If the given image does not exist in the local image cache, the daemon
+            attempts to pull the image with the host's native OS and Architecture.
+            If the given image does exists in the local image cache, but its OS or
+            architecture does not match, a warning is produced.
+
+            When used with the `fromSrc` option to import an image from an archive,
+            this option sets the platform information for the imported image. If
+            the option is not set, the host's native OS and Architecture are used
+            for the imported image.
+          type: "string"
+          default: ""
+      tags: ["Image"]
+  /images/{name}/json:
+    get:
+      summary: "Inspect an image"
+      description: "Return low-level information about an image."
+      operationId: "ImageInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/ImageInspect"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+        - name: "manifests"
+          in: "query"
+          description: |-
+            Include Manifests in the image summary.
+
+            The `manifests` and `platform` options are mutually exclusive, and
+            an error is produced if both are set.
+          type: "boolean"
+          default: false
+          required: false
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |-
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show inspect. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            The `platform` and `manifests` options are mutually exclusive, and
+            an error is produced if both are set.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/history:
+    get:
+      summary: "Get the history of an image"
+      description: "Return parent layers of an image."
+      operationId: "ImageHistory"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "List of image layers"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageHistoryResponseItem"
+          examples:
+            application/json:
+              - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
+                Created: 1398108230
+                CreatedBy: "/bin/sh -c #(nop) ADD file:eb15dbd63394e063b805a3c32ca7bf0266ef64676d5a6fab4801f2e81e2a5148 in /"
+                Tags:
+                  - "ubuntu:lucid"
+                  - "ubuntu:10.04"
+                Size: 182964289
+                Comment: ""
+              - Id: "6cfa4d1f33fb861d4d114f43b25abd0ac737509268065cdfd69d544a59c85ab8"
+                Created: 1398108222
+                CreatedBy: "/bin/sh -c #(nop) MAINTAINER Tianon Gravi <admwiggin@gmail.com> - mkimage-debootstrap.sh -i iproute,iputils-ping,ubuntu-minimal -t lucid.tar.xz lucid http://archive.ubuntu.com/ubuntu/"
+                Tags: []
+                Size: 0
+                Comment: ""
+              - Id: "511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158"
+                Created: 1371157430
+                CreatedBy: ""
+                Tags:
+                  - "scratch12:latest"
+                  - "scratch:latest"
+                Size: 0
+                Comment: "Imported from -"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show the history for. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/push:
+    post:
+      summary: "Push an image"
+      description: |
+        Push an image to a registry.
+
+        If you wish to push an image on to a private registry, that image must
+        already have a tag which references the registry. For example,
+        `registry.example.com/myimage:latest`.
+
+        The push is cancelled if the HTTP connection is closed.
+      operationId: "ImagePush"
+      consumes:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            Name of the image to push. For example, `registry.example.com/myimage`.
+            The image must be present in the local image store with the same name.
+
+            The name should be provided without tag; if a tag is provided, it
+            is ignored. For example, `registry.example.com/myimage:latest` is
+            considered equivalent to `registry.example.com/myimage`.
+
+            Use the `tag` parameter to specify the tag to push.
+          type: "string"
+          required: true
+        - name: "tag"
+          in: "query"
+          description: |
+            Tag of the image to push. For example, `latest`. If no tag is provided,
+            all tags of the given image that are present in the local image store
+            are pushed.
+          type: "string"
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant to push.
+            If not provided, all available variants will attempt to be pushed.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to push to the registry. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+          required: true
+      tags: ["Image"]
+  /images/{name}/tag:
+    post:
+      summary: "Tag an image"
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
+      operationId: "ImageTag"
+      responses:
+        201:
+          description: "No error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID to tag."
+          type: "string"
+          required: true
+        - name: "repo"
+          in: "query"
+          description: "The repository to tag in. For example, `someuser/someimage`."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "The name of the new tag."
+          type: "string"
+      tags: ["Image"]
+  /images/{name}:
+    delete:
+      summary: "Remove an image"
+      description: |
+        Remove an image, along with any untagged parent images that were
+        referenced by that image.
+
+        Images can't be removed if they have descendant images, are being
+        used by a running container or are being used by a build.
+      operationId: "ImageDelete"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The image was deleted successfully"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageDeleteResponseItem"
+          examples:
+            application/json:
+              - Untagged: "3e2f21a89f"
+              - Deleted: "3e2f21a89f"
+              - Deleted: "53b4f83ac9"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Remove the image even if it is being used by stopped containers or has other tags"
+          type: "boolean"
+          default: false
+        - name: "noprune"
+          in: "query"
+          description: "Do not delete untagged parent images"
+          type: "boolean"
+          default: false
+        - name: "platforms"
+          in: "query"
+          description: |
+            Select platform-specific content to delete.
+            Multiple values are accepted.
+            Each platform is a OCI platform encoded as a JSON string.
+          type: "array"
+          items:
+            # This should be OCIPlatform
+            # but $ref is not supported for array in query in Swagger 2.0
+            # $ref: "#/definitions/OCIPlatform"
+            type: "string"
+      tags: ["Image"]
+  /images/search:
+    get:
+      summary: "Search images"
+      description: "Search for an image on Docker Hub."
+      operationId: "ImageSearch"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              type: "object"
+              title: "ImageSearchResponseItem"
+              properties:
+                description:
+                  type: "string"
+                is_official:
+                  type: "boolean"
+                is_automated:
+                  description: |
+                    Whether this repository has automated builds enabled.
+
+                    <p><br /></p>
+
+                    > **Deprecated**: This field is deprecated and will always be "false".
+                  type: "boolean"
+                  example: false
+                name:
+                  type: "string"
+                star_count:
+                  type: "integer"
+          examples:
+            application/json:
+              - description: "A minimal Docker image based on Alpine Linux with a complete package index and only 5 MB in size!"
+                is_official: true
+                is_automated: false
+                name: "alpine"
+                star_count: 10093
+              - description: "Busybox base image."
+                is_official: true
+                is_automated: false
+                name: "Busybox base image."
+                star_count: 3037
+              - description: "The PostgreSQL object-relational database system provides reliability and data integrity."
+                is_official: true
+                is_automated: false
+                name: "postgres"
+                star_count: 12408
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "term"
+          in: "query"
+          description: "Term to search"
+          type: "string"
+          required: true
+        - name: "limit"
+          in: "query"
+          description: "Maximum number of results to return"
+          type: "integer"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to process on the images list. Available filters:
+
+            - `is-official=(true|false)`
+            - `stars=<number>` Matches images that has at least 'number' stars.
+          type: "string"
+      tags: ["Image"]
+  /images/prune:
+    post:
+      summary: "Delete unused images"
+      produces:
+        - "application/json"
+      operationId: "ImagePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`). Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), prune only
+               unused *and* untagged images. When set to `false`
+               (or `0`), all unused images are pruned.
+            - `until=<string>` Prune images created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune images with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ImagePruneResponse"
+            properties:
+              ImagesDeleted:
+                description: "Images that were deleted"
+                type: "array"
+                items:
+                  $ref: "#/definitions/ImageDeleteResponseItem"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /auth:
+    post:
+      summary: "Check auth configuration"
+      description: |
+        Validate credentials for a registry and, if available, get an identity
+        token for accessing the registry without password.
+      operationId: "SystemAuth"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "An identity token was generated successfully."
+          schema:
+            $ref: "#/definitions/AuthResponse"
+        204:
+          description: "No error"
+        401:
+          description: "Auth error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "authConfig"
+          in: "body"
+          description: "Authentication to check"
+          schema:
+            $ref: "#/definitions/AuthConfig"
+      tags: ["System"]
+  /info:
+    get:
+      summary: "Get system information"
+      operationId: "SystemInfo"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/SystemInfo"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /version:
+    get:
+      summary: "Get version"
+      description: "Returns the version of Docker that is running and various information about the system that Docker is running on."
+      operationId: "SystemVersion"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/SystemVersion"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /_ping:
+    get:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPing"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "OK"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: |
+                Default version of docker image builder
+
+                The default on Linux is version "2" (BuildKit), but the daemon
+                can be configured to recommend version "1" (classic Builder).
+                Windows does not yet support BuildKit for native Windows images,
+                and uses "1" (classic builder) as a default.
+
+                This value is a recommendation as advertised by the daemon, and
+                it is up to the client to choose which builder to use.
+              default: "2"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          headers:
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+      tags: ["System"]
+    head:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPingHead"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "(empty)"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: "Default version of docker image builder"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /commit:
+    post:
+      summary: "Create a new image from a container"
+      operationId: "ImageCommit"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "containerConfig"
+          in: "body"
+          description: "The container configuration"
+          schema:
+            $ref: "#/definitions/ContainerConfig"
+        - name: "container"
+          in: "query"
+          description: "The ID or name of the container to commit"
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name for the created image"
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag name for the create image"
+          type: "string"
+        - name: "comment"
+          in: "query"
+          description: "Commit message"
+          type: "string"
+        - name: "author"
+          in: "query"
+          description: "Author of the image (e.g., `John Hannibal Smith <hannibal@a-team.com>`)"
+          type: "string"
+        - name: "pause"
+          in: "query"
+          description: "Whether to pause the container before committing"
+          type: "boolean"
+          default: true
+        - name: "changes"
+          in: "query"
+          description: "`Dockerfile` instructions to apply while committing"
+          type: "string"
+      tags: ["Image"]
+  /events:
+    get:
+      summary: "Monitor events"
+      description: |
+        Stream real-time events from the server.
+
+        Various objects within Docker report events when something happens to them.
+
+        Containers report these events: `attach`, `commit`, `copy`, `create`, `destroy`, `detach`, `die`, `exec_create`, `exec_detach`, `exec_start`, `exec_die`, `export`, `health_status`, `kill`, `oom`, `pause`, `rename`, `resize`, `restart`, `start`, `stop`, `top`, `unpause`, `update`, and `prune`
+
+        Images report these events: `create`, `delete`, `import`, `load`, `pull`, `push`, `save`, `tag`, `untag`, and `prune`
+
+        Volumes report these events: `create`, `mount`, `unmount`, `destroy`, and `prune`
+
+        Networks report these events: `create`, `connect`, `disconnect`, `destroy`, `update`, `remove`, and `prune`
+
+        The Docker daemon reports these events: `reload`
+
+        Services report these events: `create`, `update`, and `remove`
+
+        Nodes report these events: `create`, `update`, and `remove`
+
+        Secrets report these events: `create`, `update`, and `remove`
+
+        Configs report these events: `create`, `update`, and `remove`
+
+        The Builder reports `prune` events
+
+      operationId: "SystemEvents"
+      produces:
+        - "application/x-ndjson"
+        - "application/json-seq"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/EventMessage"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "since"
+          in: "query"
+          description: "Show events created since this timestamp then stream new events."
+          type: "string"
+        - name: "until"
+          in: "query"
+          description: "Show events created until this timestamp then stop streaming."
+          type: "string"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of filters (a `map[string][]string`) to process on the event list. Available filters:
+
+            - `config=<string>` config name or ID
+            - `container=<string>` container name or ID
+            - `daemon=<string>` daemon name or ID
+            - `event=<string>` event type
+            - `image=<string>` image name or ID
+            - `label=<string>` image or container label
+            - `network=<string>` network name or ID
+            - `node=<string>` node ID
+            - `plugin`=<string> plugin name or ID
+            - `scope`=<string> local or swarm
+            - `secret=<string>` secret name or ID
+            - `service=<string>` service name or ID
+            - `type=<string>` object to filter by, one of `container`, `image`, `volume`, `network`, `daemon`, `plugin`, `node`, `service`, `secret` or `config`
+            - `volume=<string>` volume name
+          type: "string"
+      tags: ["System"]
+  /system/df:
+    get:
+      summary: "Get data usage information"
+      operationId: "SystemDataUsage"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "SystemDataUsageResponse"
+            properties:
+              ImageUsage:
+                $ref: "#/definitions/ImagesDiskUsage"
+              ContainerUsage:
+                $ref: "#/definitions/ContainersDiskUsage"
+              VolumeUsage:
+                $ref: "#/definitions/VolumesDiskUsage"
+              BuildCacheUsage:
+                $ref: "#/definitions/BuildCacheDiskUsage"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "type"
+          in: "query"
+          description: |
+            Object types, for which to compute and return data.
+          type: "array"
+          collectionFormat: multi
+          items:
+            type: "string"
+            enum: ["container", "image", "volume", "build-cache"]
+        - name: "verbose"
+          in: "query"
+          description: |
+            Show detailed information on space usage.
+          type: "boolean"
+          default: false
+      tags: ["System"]
+  /images/{name}/get:
+    get:
+      summary: "Export an image"
+      description: |
+        Get a tarball containing all images and metadata for a repository.
+
+        If `name` is a specific name and tag (e.g. `ubuntu:latest`), then only that image (and its parents) are returned. If `name` is an image ID, similarly only that image (and its parents) are returned, but with the exclusion of the `repositories` file in the tarball, as there were no image names referenced.
+
+        ### Image tarball format
+
+        An image tarball contains [Content as defined in the OCI Image Layout Specification](https://github.com/opencontainers/image-spec/blob/v1.1.1/image-layout.md#content).
+
+        Additionally, includes the manifest.json file associated with a backwards compatible docker save format.
+
+        If the tarball defines a repository, the tarball should also include a `repositories` file at the root that contains a list of repository and tag names mapped to layer IDs.
+
+        ```json
+        {
+          "hello-world": {
+            "latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"
+          }
+        }
+        ```
+      operationId: "ImageGet"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform describing a platform which will be used
+            to select a platform-specific image to be saved if the image is
+            multi-platform.
+            If not provided, the full multi-platform image will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/get:
+    get:
+      summary: "Export several images"
+      description: |
+        Get a tarball containing all images and metadata for several image
+        repositories.
+
+        For each value of the `names` parameter: if it is a specific name and
+        tag (e.g. `ubuntu:latest`), then only that image (and its parents) are
+        returned; if it is an image ID, similarly only that image (and its parents)
+        are returned and there would be no names referenced in the 'repositories'
+        file for this image ID.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageGetAll"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "names"
+          in: "query"
+          description: "Image names to filter by"
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform(s) which will be used to select the
+            platform-specific image(s) to be saved if the image is
+            multi-platform. If not provided, the full multi-platform image
+            will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/load:
+    post:
+      summary: "Import images"
+      description: |
+        Load a set of images and tags into a repository.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageLoad"
+      consumes:
+        - "application/x-tar"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "imagesTarball"
+          in: "body"
+          description: "Tar archive containing images"
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "quiet"
+          in: "query"
+          description: "Suppress progress details during load."
+          type: "boolean"
+          default: false
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform(s) which will be used to select the
+            platform-specific image(s) to load if the image is
+            multi-platform. If not provided, the full multi-platform image
+            will be loaded.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /containers/{id}/exec:
+    post:
+      summary: "Create an exec instance"
+      description: "Run a command inside a running container."
+      operationId: "ContainerExec"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execConfig"
+          in: "body"
+          description: "Exec configuration"
+          schema:
+            type: "object"
+            title: "ExecConfig"
+            properties:
+              AttachStdin:
+                type: "boolean"
+                description: "Attach to `stdin` of the exec command."
+              AttachStdout:
+                type: "boolean"
+                description: "Attach to `stdout` of the exec command."
+              AttachStderr:
+                type: "boolean"
+                description: "Attach to `stderr` of the exec command."
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+              DetachKeys:
+                type: "string"
+                description: |
+                  Override the key sequence for detaching a container. Format is
+                  a single character `[a-Z]` or `ctrl-<value>` where `<value>`
+                  is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+              Env:
+                description: |
+                  A list of environment variables in the form `["VAR=value", ...]`.
+                type: "array"
+                items:
+                  type: "string"
+              Cmd:
+                type: "array"
+                description: "Command to run, as a string or array of strings."
+                items:
+                  type: "string"
+              Privileged:
+                type: "boolean"
+                description: "Runs the exec process with extended privileges."
+                default: false
+              User:
+                type: "string"
+                description: |
+                  The user, and optionally, group to run the exec process inside
+                  the container. Format is one of: `user`, `user:group`, `uid`,
+                  or `uid:gid`.
+              WorkingDir:
+                type: "string"
+                description: |
+                  The working directory for the exec process inside the container.
+            example:
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              DetachKeys: "ctrl-p,ctrl-q"
+              Tty: false
+              Cmd:
+                - "date"
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+          required: true
+        - name: "id"
+          in: "path"
+          description: "ID or name of container"
+          type: "string"
+          required: true
+      tags: ["Exec"]
+  /exec/{id}/start:
+    post:
+      summary: "Start an exec instance"
+      description: |
+        Starts a previously set up exec instance. If detach is true, this endpoint
+        returns immediately after starting the command. Otherwise, it sets up an
+        interactive session with the command.
+      operationId: "ExecStart"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Container is stopped or paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execStartConfig"
+          in: "body"
+          schema:
+            type: "object"
+            title: "ExecStartConfig"
+            properties:
+              Detach:
+                type: "boolean"
+                description: "Detach from the command."
+                example: false
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+                example: true
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+  /exec/{id}/resize:
+    post:
+      summary: "Resize an exec instance"
+      description: |
+        Resize the TTY session used by an exec instance. This endpoint only works
+        if `tty` was specified as part of creating and starting the exec instance.
+      operationId: "ExecResize"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Exec"]
+  /exec/{id}/json:
+    get:
+      summary: "Inspect an exec instance"
+      description: "Return low-level information about an exec instance."
+      operationId: "ExecInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ExecInspectResponse"
+            properties:
+              CanRemove:
+                type: "boolean"
+              DetachKeys:
+                type: "string"
+              ID:
+                type: "string"
+              Running:
+                type: "boolean"
+              ExitCode:
+                type: "integer"
+              ProcessConfig:
+                $ref: "#/definitions/ProcessConfig"
+              OpenStdin:
+                type: "boolean"
+              OpenStderr:
+                type: "boolean"
+              OpenStdout:
+                type: "boolean"
+              ContainerID:
+                type: "string"
+              Pid:
+                type: "integer"
+                description: "The system process ID for the exec process."
+          examples:
+            application/json:
+              CanRemove: false
+              ContainerID: "b53ee82b53a40c7dca428523e34f741f3abc51d9f297a14ff874bf761b995126"
+              DetachKeys: ""
+              ExitCode: 2
+              ID: "f33bbfb39f5b142420f4759b2348913bd4a8d1a6d7fd56499cb41a1bb91d7b3b"
+              OpenStderr: true
+              OpenStdin: true
+              OpenStdout: true
+              ProcessConfig:
+                arguments:
+                  - "-c"
+                  - "exit 2"
+                entrypoint: "sh"
+                privileged: false
+                tty: true
+                user: "1000"
+              Running: false
+              Pid: 42000
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+
+  /volumes:
+    get:
+      summary: "List volumes"
+      operationId: "VolumeList"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "Summary volume data that matches the query"
+          schema:
+            $ref: "#/definitions/VolumeListResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to
+            process on the volumes list. Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               volumes that are not in use by a container. When set to `false`
+               (or `0`), only volumes that are in use by one or more
+               containers are returned.
+            - `driver=<volume-driver-name>` Matches volumes based on their driver.
+            - `label=<key>` or `label=<key>:<value>` Matches volumes based on
+               the presence of a `label` alone or a `label` and a value.
+            - `name=<volume-name>` Matches all or part of a volume name.
+          type: "string"
+          format: "json"
+      tags: ["Volume"]
+
+  /volumes/create:
+    post:
+      summary: "Create a volume"
+      operationId: "VolumeCreate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        201:
+          description: "The volume was created successfully"
+          schema:
+            $ref: "#/definitions/Volume"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "volumeConfig"
+          in: "body"
+          required: true
+          description: "Volume configuration"
+          schema:
+            $ref: "#/definitions/VolumeCreateRequest"
+      tags: ["Volume"]
+
+  /volumes/{name}:
+    get:
+      summary: "Inspect a volume"
+      operationId: "VolumeInspect"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/Volume"
+        404:
+          description: "No such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+      tags: ["Volume"]
+
+    put:
+      summary: |
+        "Update a volume. Valid only for Swarm cluster volumes"
+      operationId: "VolumeUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "The name or ID of the volume"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            # though the schema for is an object that contains only a
+            # ClusterVolumeSpec, wrapping the ClusterVolumeSpec in this object
+            # means that if, later on, we support things like changing the
+            # labels, we can do so without duplicating that information to the
+            # ClusterVolumeSpec.
+            type: "object"
+            description: "Volume configuration"
+            properties:
+              Spec:
+                $ref: "#/definitions/ClusterVolumeSpec"
+          description: |
+            The spec of the volume to update. Currently, only Availability may
+            change. All other fields must remain unchanged.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the volume being updated. This is required to
+            avoid conflicting writes. Found in the volume's `ClusterVolume`
+            field.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Volume"]
+
+    delete:
+      summary: "Remove a volume"
+      description: "Instruct the driver to remove the volume."
+      operationId: "VolumeDelete"
+      responses:
+        204:
+          description: "The volume was removed"
+        404:
+          description: "No such volume or volume driver"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Volume is in use and cannot be removed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: "Force the removal of the volume"
+          type: "boolean"
+          default: false
+      tags: ["Volume"]
+
+  /volumes/prune:
+    post:
+      summary: "Delete unused volumes"
+      produces:
+        - "application/json"
+      operationId: "VolumePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune volumes with (or without, in case `label!=...` is used) the specified labels.
+            - `all` (`all=true`) - Consider all (local) volumes for pruning and not just anonymous volumes.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "VolumePruneResponse"
+            properties:
+              VolumesDeleted:
+                description: "Volumes that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Volume"]
+  /networks:
+    get:
+      summary: "List networks"
+      description: |
+        Returns a list of networks. For details on the format, see the
+        [network inspect endpoint](#operation/NetworkInspect).
+
+        Note that it uses a different, smaller representation of a network than
+        inspecting a single network. For example, the list of containers attached
+        to the network is not propagated in API versions 1.28 and up.
+      operationId: "NetworkList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/NetworkSummary"
+          examples:
+            application/json:
+              - Name: "bridge"
+                Id: "f2de39df4171b0dc801e8002d1d999b77256983dfc63041c0f34030aa3977566"
+                Created: "2016-10-19T06:21:00.416543526Z"
+                Scope: "local"
+                Driver: "bridge"
+                EnableIPv4: true
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config:
+                    -
+                      Subnet: "172.17.0.0/16"
+                Options:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              - Name: "none"
+                Id: "e086a3893b05ab69242d3c44e49483a3bbbd3a26b46baa8f61ab797c1088d794"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "null"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+              - Name: "host"
+                Id: "13e871235c677f196c4e1ecebb9dc733b9b2d2ab589e30c539efeda84a24215e"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "host"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to process
+            on the networks list.
+
+            Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               networks that are not in use by a container. When set to `false`
+               (or `0`), only networks that are in use by one or more
+               containers are returned.
+            - `driver=<driver-name>` Matches a network's driver.
+            - `id=<network-id>` Matches all or part of a network ID.
+            - `label=<key>` or `label=<key>=<value>` of a network label.
+            - `name=<network-name>` Matches all or part of a network name.
+            - `scope=["swarm"|"global"|"local"]` Filters networks by scope (`swarm`, `global`, or `local`).
+            - `type=["custom"|"builtin"]` Filters networks by type. The `custom` keyword returns all user-defined networks.
+          type: "string"
+      tags: ["Network"]
+
+  /networks/{id}:
+    get:
+      summary: "Inspect a network"
+      operationId: "NetworkInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/NetworkInspect"
+        404:
+          description: "Network not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "verbose"
+          in: "query"
+          description: "Detailed inspect output for troubleshooting"
+          type: "boolean"
+          default: false
+        - name: "scope"
+          in: "query"
+          description: "Filter the network by scope (swarm, global, or local)"
+          type: "string"
+      tags: ["Network"]
+
+    delete:
+      summary: "Remove a network"
+      operationId: "NetworkDelete"
+      responses:
+        204:
+          description: "No error"
+        403:
+          description: "operation not supported for pre-defined networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such network"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+      tags: ["Network"]
+
+  /networks/create:
+    post:
+      summary: "Create a network"
+      operationId: "NetworkCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "Network created successfully"
+          schema:
+            $ref: "#/definitions/NetworkCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: |
+            Forbidden operation. This happens when trying to create a network named after a pre-defined network,
+            or when trying to create an overlay network on a daemon which is not part of a Swarm cluster.
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "plugin not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "networkConfig"
+          in: "body"
+          description: "Network configuration"
+          required: true
+          schema:
+            type: "object"
+            title: "NetworkCreateRequest"
+            required: ["Name"]
+            properties:
+              Name:
+                description: "The network's name."
+                type: "string"
+                example: "my_network"
+              Driver:
+                description: "Name of the network driver plugin to use."
+                type: "string"
+                default: "bridge"
+                example: "bridge"
+              Scope:
+                description: |
+                  The level at which the network exists (e.g. `swarm` for cluster-wide
+                  or `local` for machine level).
+                type: "string"
+              Internal:
+                description: "Restrict external access to the network."
+                type: "boolean"
+              Attachable:
+                description: |
+                  Globally scoped network is manually attachable by regular
+                  containers from workers in swarm mode.
+                type: "boolean"
+                example: true
+              Ingress:
+                description: |
+                  Ingress network is the network which provides the routing-mesh
+                  in swarm mode.
+                type: "boolean"
+                example: false
+              ConfigOnly:
+                description: |
+                  Creates a config-only network. Config-only networks are placeholder
+                  networks for network configurations to be used by other networks.
+                  Config-only networks cannot be used directly to run containers
+                  or services.
+                type: "boolean"
+                default: false
+                example: false
+              ConfigFrom:
+                description: |
+                  Specifies the source which will provide the configuration for
+                  this network. The specified network must be an existing
+                  config-only network; see ConfigOnly.
+                $ref: "#/definitions/ConfigReference"
+              IPAM:
+                description: "Optional custom IP scheme for the network."
+                $ref: "#/definitions/IPAM"
+              EnableIPv4:
+                description: "Enable IPv4 on the network."
+                type: "boolean"
+                example: true
+              EnableIPv6:
+                description: "Enable IPv6 on the network."
+                type: "boolean"
+                example: true
+              Options:
+                description: "Network specific options to be used by the drivers."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              Labels:
+                description: "User-defined key/value metadata."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.example.some-label: "some-value"
+                  com.example.some-other-label: "some-other-value"
+      tags: ["Network"]
+
+  /networks/{id}/connect:
+    post:
+      summary: "Connect a container to a network"
+      description: "The network must be either a local-scoped network or a swarm-scoped network with the `attachable` option set. A network cannot be re-attached to a running container"
+      operationId: "NetworkConnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "Operation forbidden"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/NetworkConnectRequest"
+      tags: ["Network"]
+
+  /networks/{id}/disconnect:
+    post:
+      summary: "Disconnect a container from a network"
+      operationId: "NetworkDisconnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        403:
+          description: "Operation not supported for swarm scoped networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/NetworkDisconnectRequest"
+      tags: ["Network"]
+  /networks/prune:
+    post:
+      summary: "Delete unused networks"
+      produces:
+        - "application/json"
+      operationId: "NetworkPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune networks created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune networks with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "NetworkPruneResponse"
+            properties:
+              NetworksDeleted:
+                description: "Networks that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Network"]
+  /plugins:
+    get:
+      summary: "List plugins"
+      operationId: "PluginList"
+      description: "Returns information about installed plugins."
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Plugin"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the plugin list.
+
+            Available filters:
+
+            - `capability=<capability name>`
+            - `enable=<true>|<false>`
+      tags: ["Plugin"]
+
+  /plugins/privileges:
+    get:
+      summary: "Get plugin privileges"
+      operationId: "GetPluginPrivileges"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags:
+        - "Plugin"
+
+  /plugins/pull:
+    post:
+      summary: "Install a plugin"
+      operationId: "PluginPull"
+      description: |
+        Pulls and installs a plugin. After the plugin is installed, it can be
+        enabled using the [`POST /plugins/{name}/enable` endpoint](#operation/PostPluginsEnable).
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference for plugin to install.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "name"
+          in: "query"
+          description: |
+            Local name for the pulled plugin.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: false
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/{name}/json:
+    get:
+      summary: "Inspect a plugin"
+      operationId: "PluginInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags: ["Plugin"]
+  /plugins/{name}:
+    delete:
+      summary: "Remove a plugin"
+      operationId: "PluginDelete"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Disable the plugin before removing. This may result in issues if the
+            plugin is in use by a container.
+          type: "boolean"
+          default: false
+      tags: ["Plugin"]
+  /plugins/{name}/enable:
+    post:
+      summary: "Enable a plugin"
+      operationId: "PluginEnable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "timeout"
+          in: "query"
+          description: "Set the HTTP client timeout (in seconds)"
+          type: "integer"
+          default: 0
+      tags: ["Plugin"]
+  /plugins/{name}/disable:
+    post:
+      summary: "Disable a plugin"
+      operationId: "PluginDisable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Force disable a plugin even if still in use.
+          required: false
+          type: "boolean"
+      tags: ["Plugin"]
+  /plugins/{name}/upgrade:
+    post:
+      summary: "Upgrade a plugin"
+      operationId: "PluginUpgrade"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference to upgrade to.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/create:
+    post:
+      summary: "Create a plugin"
+      operationId: "PluginCreate"
+      consumes:
+        - "application/x-tar"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "tarContext"
+          in: "body"
+          description: "Path to tar containing plugin rootfs and manifest"
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Plugin"]
+  /plugins/{name}/push:
+    post:
+      summary: "Push a plugin"
+      operationId: "PluginPush"
+      description: |
+        Push a plugin to the registry.
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /plugins/{name}/set:
+    post:
+      summary: "Configure a plugin"
+      operationId: "PluginSet"
+      consumes:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              type: "string"
+            example: ["DEBUG=1"]
+      responses:
+        204:
+          description: "No error"
+        404:
+          description: "Plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /nodes:
+    get:
+      summary: "List nodes"
+      operationId: "NodeList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Node"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the nodes list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `id=<node id>`
+            - `label=<engine label>`
+            - `membership=`(`accepted`|`pending`)`
+            - `name=<node name>`
+            - `node.label=<node label>`
+            - `role=`(`manager`|`worker`)`
+          type: "string"
+      tags: ["Node"]
+  /nodes/{id}:
+    get:
+      summary: "Inspect a node"
+      operationId: "NodeInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Node"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+      tags: ["Node"]
+    delete:
+      summary: "Delete a node"
+      operationId: "NodeDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Force remove a node from the swarm"
+          default: false
+          type: "boolean"
+      tags: ["Node"]
+  /nodes/{id}/update:
+    post:
+      summary: "Update a node"
+      operationId: "NodeUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID of the node"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/NodeSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the node object being updated. This is required
+            to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Node"]
+  /swarm:
+    get:
+      summary: "Inspect swarm"
+      operationId: "SwarmInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Swarm"
+        404:
+          description: "no such swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/init:
+    post:
+      summary: "Initialize a new swarm"
+      operationId: "SwarmInit"
+      produces:
+        - "application/json"
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            description: "The node ID"
+            type: "string"
+            example: "7v2t30z9blmxuhnyo6s4cpenp"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmInitRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication, as well
+                  as determining the networking interface used for the VXLAN
+                  Tunnel Endpoint (VTEP). This can either be an address/port
+                  combination in the form `192.168.1.1:4567`, or an interface
+                  followed by a port number, like `eth0:4567`. If the port number
+                  is omitted, the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other  nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+                type: "string"
+              DataPathPort:
+                description: |
+                  DataPathPort specifies the data path port number for data traffic.
+                  Acceptable port range is 1024 to 49151.
+                  if no port is set or is set to 0, default port 4789 will be used.
+                type: "integer"
+                format: "uint32"
+              DefaultAddrPool:
+                description: |
+                  Default Address Pool specifies default subnet pools for global
+                  scope networks.
+                type: "array"
+                items:
+                  type: "string"
+                  example: ["10.10.0.0/16", "20.20.0.0/16"]
+              ForceNewCluster:
+                description: "Force creation of a new swarm."
+                type: "boolean"
+              SubnetSize:
+                description: |
+                  SubnetSize specifies the subnet size of the networks created
+                  from the default subnet pool.
+                type: "integer"
+                format: "uint32"
+              Spec:
+                $ref: "#/definitions/SwarmSpec"
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathPort: 4789
+              DefaultAddrPool: ["10.10.0.0/8", "20.20.0.0/8"]
+              SubnetSize: 24
+              ForceNewCluster: false
+              Spec:
+                Orchestration: {}
+                Raft: {}
+                Dispatcher: {}
+                CAConfig: {}
+                EncryptionConfig:
+                  AutoLockManagers: false
+      tags: ["Swarm"]
+  /swarm/join:
+    post:
+      summary: "Join an existing swarm"
+      operationId: "SwarmJoin"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmJoinRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+
+                type: "string"
+              RemoteAddrs:
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
+              JoinToken:
+                description: "Secret token for joining this swarm."
+                type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathAddr: "192.168.1.1"
+              RemoteAddrs:
+                - "node1:2377"
+              JoinToken: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+      tags: ["Swarm"]
+  /swarm/leave:
+    post:
+      summary: "Leave a swarm"
+      operationId: "SwarmLeave"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "force"
+          description: |
+            Force leave swarm, even if this is the last manager or that it will
+            break the cluster.
+          in: "query"
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/update:
+    post:
+      summary: "Update a swarm"
+      operationId: "SwarmUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/SwarmSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the swarm object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+        - name: "rotateWorkerToken"
+          in: "query"
+          description: "Rotate the worker join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerToken"
+          in: "query"
+          description: "Rotate the manager join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerUnlockKey"
+          in: "query"
+          description: "Rotate the manager unlock key."
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/unlockkey:
+    get:
+      summary: "Get the unlock key"
+      operationId: "SwarmUnlockkey"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "UnlockKeyResponse"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/unlock:
+    post:
+      summary: "Unlock a locked manager"
+      operationId: "SwarmUnlock"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmUnlockRequest"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /services:
+    get:
+      summary: "List services"
+      operationId: "ServiceList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Service"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the services list.
+
+            Available filters:
+
+            - `id=<service id>`
+            - `label=<service label>`
+            - `mode=["replicated"|"global"]`
+            - `name=<service name>`
+        - name: "status"
+          in: "query"
+          type: "boolean"
+          description: |
+            Include service status, with count of running and desired tasks.
+      tags: ["Service"]
+  /services/create:
+    post:
+      summary: "Create a service"
+      operationId: "ServiceCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "network is not eligible for services"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "name conflicts with an existing service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "web"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "nginx:alpine"
+                      Mounts:
+                        -
+                          ReadOnly: true
+                          Source: "web-data"
+                          Target: "/usr/share/nginx/html"
+                          Type: "volume"
+                          VolumeOptions:
+                            DriverConfig: {}
+                            Labels:
+                              com.example.something: "something-value"
+                      Hosts: ["10.10.10.10 host1", "ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 host2"]
+                      User: "33"
+                      DNSConfig:
+                        Nameservers: ["8.8.8.8"]
+                        Search: ["example.org"]
+                        Options: ["timeout:3"]
+                      Secrets:
+                        -
+                          File:
+                            Name: "www.example.org.key"
+                            UID: "33"
+                            GID: "33"
+                            Mode: 384
+                          SecretID: "fpjqlhnwb19zds35k8wn80lq9"
+                          SecretName: "example_org_domain_key"
+                      OomScoreAdj: 0
+                    LogDriver:
+                      Name: "json-file"
+                      Options:
+                        max-file: "3"
+                        max-size: "10M"
+                    Placement: {}
+                    Resources:
+                      Limits:
+                        MemoryBytes: 104857600
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "on-failure"
+                      Delay: 10000000000
+                      MaxAttempts: 10
+                  Mode:
+                    Replicated:
+                      Replicas: 4
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Ports:
+                      -
+                        Protocol: "tcp"
+                        PublishedPort: 8080
+                        TargetPort: 80
+                  Labels:
+                    foo: "bar"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+      tags: ["Service"]
+  /services/{id}:
+    get:
+      summary: "Inspect a service"
+      operationId: "ServiceInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Service"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "insertDefaults"
+          in: "query"
+          description: "Fill empty fields with default values."
+          type: "boolean"
+          default: false
+      tags: ["Service"]
+    delete:
+      summary: "Delete a service"
+      operationId: "ServiceDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+      tags: ["Service"]
+  /services/{id}/update:
+    post:
+      summary: "Update a service"
+      operationId: "ServiceUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceUpdateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "top"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "busybox"
+                      Args:
+                        - "top"
+                      OomScoreAdj: 0
+                    Resources:
+                      Limits: {}
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "any"
+                      MaxAttempts: 0
+                    Placement: {}
+                    ForceUpdate: 0
+                  Mode:
+                    Replicated:
+                      Replicas: 1
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Mode: "vip"
+
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the service object being updated. This is
+            required to avoid conflicting writes.
+            This version number should be the value as currently set on the
+            service *before* the update. You can find the current version by
+            calling `GET /services/{id}`
+          required: true
+          type: "integer"
+        - name: "registryAuthFrom"
+          in: "query"
+          description: |
+            If the `X-Registry-Auth` header is not specified, this parameter
+            indicates where to find registry authorization credentials.
+          type: "string"
+          enum: ["spec", "previous-spec"]
+          default: "spec"
+        - name: "rollback"
+          in: "query"
+          description: |
+            Set to this parameter to `previous` to cause a server-side rollback
+            to the previous service spec. The supplied spec will be ignored in
+            this case.
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+
+      tags: ["Service"]
+  /services/{id}/logs:
+    get:
+      summary: "Get service logs"
+      description: |
+        Get `stdout` and `stderr` logs from a service. See also
+        [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ServiceLogs"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such service: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the service"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show service context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Service"]
+  /tasks:
+    get:
+      summary: "List tasks"
+      operationId: "TaskList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Task"
+            example:
+              - ID: "0kzzo1i0y4jz6027t0k7aezc7"
+                Version:
+                  Index: 71
+                CreatedAt: "2016-06-07T21:07:31.171892745Z"
+                UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:31.290032978Z"
+                  State: "running"
+                  Message: "started"
+                  ContainerStatus:
+                    ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+                    PID: 677
+                DesiredState: "running"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.10/16"
+              - ID: "1yljwbmlr8er2waf8orvqpwms"
+                Version:
+                  Index: 30
+                CreatedAt: "2016-06-07T21:07:30.019104782Z"
+                UpdatedAt: "2016-06-07T21:07:30.231958098Z"
+                Name: "hopeful_cori"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:30.202183143Z"
+                  State: "shutdown"
+                  Message: "shutdown"
+                  ContainerStatus:
+                    ContainerID: "1cf8d63d18e79668b0004a4be4c6ee58cddfad2dae29506d8781581d0688a213"
+                DesiredState: "shutdown"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.5/16"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the tasks list.
+
+            Available filters:
+
+            - `desired-state=(running | shutdown | accepted)`
+            - `id=<task id>`
+            - `label=key` or `label="key=value"`
+            - `name=<task name>`
+            - `node=<node id or name>`
+            - `service=<service name>`
+      tags: ["Task"]
+  /tasks/{id}:
+    get:
+      summary: "Inspect a task"
+      operationId: "TaskInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Task"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID of the task"
+          required: true
+          type: "string"
+      tags: ["Task"]
+  /tasks/{id}/logs:
+    get:
+      summary: "Get task logs"
+      description: |
+        Get `stdout` and `stderr` logs from a task.
+        See also [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      operationId: "TaskLogs"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such task: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID of the task"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show task context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Task"]
+  /secrets:
+    get:
+      summary: "List secrets"
+      operationId: "SecretList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Secret"
+            example:
+              - ID: "blt1owaxmitz71s9v5zh81zun"
+                Version:
+                  Index: 85
+                CreatedAt: "2017-07-20T13:55:28.678958722Z"
+                UpdatedAt: "2017-07-20T13:55:28.678958722Z"
+                Spec:
+                  Name: "mysql-passwd"
+                  Labels:
+                    some.label: "some.value"
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "app-dev.crt"
+                  Labels:
+                    foo: "bar"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the secrets list.
+
+            Available filters:
+
+            - `id=<secret id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<secret name>`
+            - `names=<secret name>`
+      tags: ["Secret"]
+  /secrets/create:
+    post:
+      summary: "Create a secret"
+      operationId: "SecretCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/SecretSpec"
+              - type: "object"
+                example:
+                  Name: "app-key.crt"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+      tags: ["Secret"]
+  /secrets/{id}:
+    get:
+      summary: "Inspect a secret"
+      operationId: "SecretInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Secret"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+                Labels:
+                  foo: "bar"
+                Driver:
+                  Name: "secret-bucket"
+                  Options:
+                    OptionA: "value for driver option A"
+                    OptionB: "value for driver option B"
+
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+    delete:
+      summary: "Delete a secret"
+      operationId: "SecretDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+  /secrets/{id}/update:
+    post:
+      summary: "Update a Secret"
+      operationId: "SecretUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such secret"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the secret"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/SecretSpec"
+          description: |
+            The spec of the secret to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [SecretInspect endpoint](#operation/SecretInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the secret object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Secret"]
+  /configs:
+    get:
+      summary: "List configs"
+      operationId: "ConfigList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Config"
+            example:
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "server.conf"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the configs list.
+
+            Available filters:
+
+            - `id=<config id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<config name>`
+            - `names=<config name>`
+      tags: ["Config"]
+  /configs/create:
+    post:
+      summary: "Create a config"
+      operationId: "ConfigCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ConfigSpec"
+              - type: "object"
+                example:
+                  Name: "server.conf"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+      tags: ["Config"]
+  /configs/{id}:
+    get:
+      summary: "Inspect a config"
+      operationId: "ConfigInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Config"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+    delete:
+      summary: "Delete a config"
+      operationId: "ConfigDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+  /configs/{id}/update:
+    post:
+      summary: "Update a Config"
+      operationId: "ConfigUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such config"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the config"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/ConfigSpec"
+          description: |
+            The spec of the config to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [ConfigInspect endpoint](#operation/ConfigInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the config object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Config"]
+  /distribution/{name}/json:
+    get:
+      summary: "Get image information from the registry"
+      description: |
+        Return image digest and platform information by contacting the registry.
+      operationId: "DistributionInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "descriptor and platform information"
+          schema:
+            $ref: "#/definitions/DistributionInspect"
+        401:
+          description: "Failed authentication or no image found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+      tags: ["Distribution"]
+  /session:
+    post:
+      summary: "Initialize interactive session"
+      description: |
+        Start a new interactive session with a server. Session allows server to
+        call back to the client for advanced capabilities.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to HTTP2 transport that allows
+        the client to expose gPRC services on that connection.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /session HTTP/1.1
+        Upgrade: h2c
+        Connection: Upgrade
+        ```
+
+        The Docker daemon responds with a `101 UPGRADED` response follow with
+        the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Connection: Upgrade
+        Upgrade: h2c
+        ```
+      operationId: "Session"
+      produces:
+        - "application/vnd.docker.raw-stream"
+      responses:
+        101:
+          description: "no error, hijacking successful"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Session"]
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.53.yaml b/_vendor/github.com/moby/moby/api/docs/v1.53.yaml
new file mode 100644
index 000000000000..5063850a523e
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.53.yaml
@@ -0,0 +1,13879 @@
+# A Swagger 2.0 (a.k.a. OpenAPI) definition of the Engine API.
+#
+# This is used for generating API documentation and the types used by the
+# client/server. See api/README.md for more information.
+#
+# Some style notes:
+# - This file is used by ReDoc, which allows GitHub Flavored Markdown in
+#   descriptions.
+# - There is no maximum line length, for ease of editing and pretty diffs.
+# - operationIds are in the format "NounVerb", with a singular noun.
+
+swagger: "2.0"
+schemes:
+  - "http"
+  - "https"
+produces:
+  - "application/json"
+  - "text/plain"
+consumes:
+  - "application/json"
+  - "text/plain"
+basePath: "/v1.53"
+info:
+  title: "Docker Engine API"
+  version: "1.53"
+  x-logo:
+    url: "https://docs.docker.com/assets/images/logo-docker-main.png"
+  description: |
+    The Engine API is an HTTP API served by Docker Engine. It is the API the
+    Docker client uses to communicate with the Engine, so everything the Docker
+    client can do can be done with the API.
+
+    Most of the client's commands map directly to API endpoints (e.g. `docker ps`
+    is `GET /containers/json`). The notable exception is running containers,
+    which consists of several API calls.
+
+    # Errors
+
+    The API uses standard HTTP status codes to indicate the success or failure
+    of the API call. The body of the response will be JSON in the following
+    format:
+
+    ```
+    {
+      "message": "page not found"
+    }
+    ```
+
+    # Versioning
+
+    The API is usually changed in each release, so API calls are versioned to
+    ensure that clients don't break. To lock to a specific version of the API,
+    you prefix the URL with its version, for example, call `/v1.30/info` to use
+    the v1.30 version of the `/info` endpoint. If the API version specified in
+    the URL is not supported by the daemon, a HTTP `400 Bad Request` error message
+    is returned.
+
+    If you omit the version-prefix, the current version of the API (v1.50) is used.
+    For example, calling `/info` is the same as calling `/v1.52/info`. Using the
+    API without a version-prefix is deprecated and will be removed in a future release.
+
+    Engine releases in the near future should support this version of the API,
+    so your client will continue to work even if it is talking to a newer Engine.
+
+    The API uses an open schema model, which means the server may add extra properties
+    to responses. Likewise, the server will ignore any extra query parameters and
+    request body properties. When you write clients, you need to ignore additional
+    properties in responses to ensure they do not break when talking to newer
+    daemons.
+
+
+    # Authentication
+
+    Authentication for registries is handled client side. The client has to send
+    authentication details to various endpoints that need to communicate with
+    registries, such as `POST /images/(name)/push`. These are sent as
+    `X-Registry-Auth` header as a [base64url encoded](https://tools.ietf.org/html/rfc4648#section-5)
+    (JSON) string with the following structure:
+
+    ```
+    {
+      "username": "string",
+      "password": "string",
+      "serveraddress": "string"
+    }
+    ```
+
+    The `serveraddress` is a domain/IP without a protocol. Throughout this
+    structure, double quotes are required.
+
+    If you have already got an identity token from the [`/auth` endpoint](#operation/SystemAuth),
+    you can just pass this instead of credentials:
+
+    ```
+    {
+      "identitytoken": "9cbaf023786cd7..."
+    }
+    ```
+
+# The tags on paths define the menu sections in the ReDoc documentation, so
+# the usage of tags must make sense for that:
+# - They should be singular, not plural.
+# - There should not be too many tags, or the menu becomes unwieldy. For
+#   example, it is preferable to add a path to the "System" tag instead of
+#   creating a tag with a single path in it.
+# - The order of tags in this list defines the order in the menu.
+tags:
+  # Primary objects
+  - name: "Container"
+    x-displayName: "Containers"
+    description: |
+      Create and manage containers.
+  - name: "Image"
+    x-displayName: "Images"
+  - name: "Network"
+    x-displayName: "Networks"
+    description: |
+      Networks are user-defined networks that containers can be attached to.
+      See the [networking documentation](https://docs.docker.com/network/)
+      for more information.
+  - name: "Volume"
+    x-displayName: "Volumes"
+    description: |
+      Create and manage persistent storage that can be attached to containers.
+  - name: "Exec"
+    x-displayName: "Exec"
+    description: |
+      Run new commands inside running containers. Refer to the
+      [command-line reference](https://docs.docker.com/engine/reference/commandline/exec/)
+      for more information.
+
+      To exec a command in a container, you first need to create an exec instance,
+      then start it. These two API endpoints are wrapped up in a single command-line
+      command, `docker exec`.
+
+  # Swarm things
+  - name: "Swarm"
+    x-displayName: "Swarm"
+    description: |
+      Engines can be clustered together in a swarm. Refer to the
+      [swarm mode documentation](https://docs.docker.com/engine/swarm/)
+      for more information.
+  - name: "Node"
+    x-displayName: "Nodes"
+    description: |
+      Nodes are instances of the Engine participating in a swarm. Swarm mode
+      must be enabled for these endpoints to work.
+  - name: "Service"
+    x-displayName: "Services"
+    description: |
+      Services are the definitions of tasks to run on a swarm. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Task"
+    x-displayName: "Tasks"
+    description: |
+      A task is a container running on a swarm. It is the atomic scheduling unit
+      of swarm. Swarm mode must be enabled for these endpoints to work.
+  - name: "Secret"
+    x-displayName: "Secrets"
+    description: |
+      Secrets are sensitive data that can be used by services. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Config"
+    x-displayName: "Configs"
+    description: |
+      Configs are application configurations that can be used by services. Swarm
+      mode must be enabled for these endpoints to work.
+  # System things
+  - name: "Plugin"
+    x-displayName: "Plugins"
+  - name: "System"
+    x-displayName: "System"
+
+definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
+  PortSummary:
+    type: "object"
+    description: |
+      Describes a port-mapping between the container and the host.
+    required: [PrivatePort, Type]
+    properties:
+      IP:
+        type: "string"
+        format: "ip-address"
+        description: "Host IP address that the container's port is mapped to"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      PrivatePort:
+        type: "integer"
+        format: "uint16"
+        x-nullable: false
+        description: "Port on the container"
+      PublicPort:
+        type: "integer"
+        format: "uint16"
+        description: "Port exposed on the host"
+      Type:
+        type: "string"
+        x-nullable: false
+        enum: ["tcp", "udp", "sctp"]
+    example:
+      PrivatePort: 8080
+      PublicPort: 80
+      Type: "tcp"
+
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `image` an OCI image.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "image"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
+  MountPoint:
+    type: "object"
+    description: |
+      MountPoint represents a mount point configuration inside the container.
+      This is used for reporting the mountpoints in use by a container.
+    properties:
+      Type:
+        description: |
+          The mount type:
+
+          - `bind` a mount of a file or directory from the host into the container.
+          - `cluster` a Swarm cluster volume.
+          - `image` an OCI image.
+          - `npipe` a named pipe from the host into the container.
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
+        example: "volume"
+      Name:
+        description: |
+          Name is the name reference to the underlying data defined by `Source`
+          e.g., the volume name.
+        type: "string"
+        example: "myvolume"
+      Source:
+        description: |
+          Source location of the mount.
+
+          For volumes, this contains the storage location of the volume (within
+          `/var/lib/docker/volumes/`). For bind-mounts, and `npipe`, this contains
+          the source (host) part of the bind-mount. For `tmpfs` mount points, this
+          field is empty.
+        type: "string"
+        example: "/var/lib/docker/volumes/myvolume/_data"
+      Destination:
+        description: |
+          Destination is the path relative to the container root (`/`) where
+          the `Source` is mounted inside the container.
+        type: "string"
+        example: "/usr/share/nginx/html/"
+      Driver:
+        description: |
+          Driver is the volume driver used to create the volume (if it is a volume).
+        type: "string"
+        example: "local"
+      Mode:
+        description: |
+          Mode is a comma separated list of options supplied by the user when
+          creating the bind/volume mount.
+
+          The default is platform-specific (`"z"` on Linux, empty on Windows).
+        type: "string"
+        example: "z"
+      RW:
+        description: |
+          Whether the mount is mounted writable (read-write).
+        type: "boolean"
+        example: true
+      Propagation:
+        description: |
+          Propagation describes how mounts are propagated from the host into the
+          mount point, and vice-versa. Refer to the [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
+          for details. This field is not used on Windows.
+        type: "string"
+        example: ""
+
+  DeviceMapping:
+    type: "object"
+    description: "A device mapping between the host and container"
+    properties:
+      PathOnHost:
+        type: "string"
+      PathInContainer:
+        type: "string"
+      CgroupPermissions:
+        type: "string"
+    example:
+      PathOnHost: "/dev/deviceName"
+      PathInContainer: "/dev/deviceName"
+      CgroupPermissions: "mrw"
+
+  DeviceRequest:
+    type: "object"
+    description: "A request for devices to be sent to device drivers"
+    properties:
+      Driver:
+        description: |
+          The name of the device driver to use for this request.
+
+          Note that if this is specified the capabilities are ignored when
+          selecting a device driver.
+        type: "string"
+        example: "nvidia"
+      Count:
+        type: "integer"
+        example: -1
+      DeviceIDs:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "0"
+          - "1"
+          - "GPU-fef8089b-4820-abfc-e83e-94318197576e"
+      Capabilities:
+        description: |
+          A list of capabilities; an OR list of AND lists of capabilities.
+
+          Note that if a driver is specified the capabilities have no effect on
+          selecting a driver as the driver name is used directly.
+
+          Note that if no driver is specified the capabilities are used to
+          select a driver with the required capabilities.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          # gpu AND nvidia AND compute
+          - ["gpu", "nvidia", "compute"]
+      Options:
+        description: |
+          Driver-specific options, specified as a key/value pairs. These options
+          are passed directly to the driver.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  ThrottleDevice:
+    type: "object"
+    properties:
+      Path:
+        description: "Device path"
+        type: "string"
+      Rate:
+        description: "Rate"
+        type: "integer"
+        format: "int64"
+        minimum: 0
+
+  Mount:
+    type: "object"
+    properties:
+      Target:
+        description: "Container path."
+        type: "string"
+      Source:
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
+        type: "string"
+      Type:
+        description: |
+          The mount type. Available types:
+
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `cluster` a Swarm cluster volume
+          - `image` Mounts an image.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
+      ReadOnly:
+        description: "Whether the mount should be read-only."
+        type: "boolean"
+      Consistency:
+        description: "The consistency requirement for the mount: `default`, `consistent`, `cached`, or `delegated`."
+        type: "string"
+      BindOptions:
+        description: "Optional configuration for the `bind` type."
+        type: "object"
+        properties:
+          Propagation:
+            description: "A propagation mode with the value `[r]private`, `[r]shared`, or `[r]slave`."
+            type: "string"
+            enum:
+              - "private"
+              - "rprivate"
+              - "shared"
+              - "rshared"
+              - "slave"
+              - "rslave"
+          NonRecursive:
+            description: "Disable recursive bind mount."
+            type: "boolean"
+            default: false
+          CreateMountpoint:
+            description: "Create mount point on host if missing"
+            type: "boolean"
+            default: false
+          ReadOnlyNonRecursive:
+            description: |
+              Make the mount non-recursively read-only, but still leave the mount recursive
+              (unless NonRecursive is set to `true` in conjunction).
+
+              Added in v1.44, before that version all read-only mounts were
+              non-recursive by default. To match the previous behaviour this
+              will default to `true` for clients on versions prior to v1.44.
+            type: "boolean"
+            default: false
+          ReadOnlyForceRecursive:
+            description: "Raise an error if the mount cannot be made recursively read-only."
+            type: "boolean"
+            default: false
+      VolumeOptions:
+        description: "Optional configuration for the `volume` type."
+        type: "object"
+        properties:
+          NoCopy:
+            description: "Populate volume with data from the target."
+            type: "boolean"
+            default: false
+          Labels:
+            description: "User-defined key/value metadata."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          DriverConfig:
+            description: "Map of driver specific options"
+            type: "object"
+            properties:
+              Name:
+                description: "Name of the driver to use to create the volume."
+                type: "string"
+              Options:
+                description: "key/value map of driver specific options."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+          Subpath:
+            description: "Source path inside the volume. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-volume/subdirectory"
+      ImageOptions:
+        description: "Optional configuration for the `image` type."
+        type: "object"
+        properties:
+          Subpath:
+            description: "Source path inside the image. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-image/subdirectory"
+      TmpfsOptions:
+        description: "Optional configuration for the `tmpfs` type."
+        type: "object"
+        properties:
+          SizeBytes:
+            description: "The size for the tmpfs mount in bytes."
+            type: "integer"
+            format: "int64"
+          Mode:
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
+            type: "integer"
+          Options:
+            description: |
+              The options to be passed to the tmpfs mount. An array of arrays.
+              Flag options should be provided as 1-length arrays. Other types
+              should be provided as as 2-length arrays, where the first item is
+              the key and the second the value.
+            type: "array"
+            items:
+              type: "array"
+              minItems: 1
+              maxItems: 2
+              items:
+                type: "string"
+            example:
+              [["noexec"]]
+
+  RestartPolicy:
+    description: |
+      The behavior to apply when the container exits. The default is not to
+      restart.
+
+      An ever increasing delay (double the previous delay, starting at 100ms) is
+      added before each restart to prevent flooding the server.
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        description: |
+          - Empty string means not to restart
+          - `no` Do not automatically restart
+          - `always` Always restart
+          - `unless-stopped` Restart always except when the user has manually stopped the container
+          - `on-failure` Restart only when the container exit code is non-zero
+        enum:
+          - ""
+          - "no"
+          - "always"
+          - "unless-stopped"
+          - "on-failure"
+      MaximumRetryCount:
+        type: "integer"
+        description: |
+          If `on-failure` is used, the number of times to retry before giving up.
+
+  Resources:
+    description: "A container's resources (cgroups config, ulimits, etc)"
+    type: "object"
+    properties:
+      # Applicable to all platforms
+      CpuShares:
+        description: |
+          An integer value representing this container's relative CPU weight
+          versus other containers.
+        type: "integer"
+      Memory:
+        description: "Memory limit in bytes."
+        type: "integer"
+        format: "int64"
+        default: 0
+      # Applicable to UNIX platforms
+      CgroupParent:
+        description: |
+          Path to `cgroups` under which the container's `cgroup` is created. If
+          the path is not absolute, the path is considered to be relative to the
+          `cgroups` path of the init process. Cgroups are created if they do not
+          already exist.
+        type: "string"
+      BlkioWeight:
+        description: "Block IO weight (relative weight)."
+        type: "integer"
+        minimum: 0
+        maximum: 1000
+      BlkioWeightDevice:
+        description: |
+          Block IO weight (relative device weight) in the form:
+
+          ```
+          [{"Path": "device_path", "Weight": weight}]
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Path:
+              type: "string"
+            Weight:
+              type: "integer"
+              minimum: 0
+      BlkioDeviceReadBps:
+        description: |
+          Limit read rate (bytes per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteBps:
+        description: |
+          Limit write rate (bytes per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceReadIOps:
+        description: |
+          Limit read rate (IO per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteIOps:
+        description: |
+          Limit write rate (IO per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      CpuPeriod:
+        description: "The length of a CPU period in microseconds."
+        type: "integer"
+        format: "int64"
+      CpuQuota:
+        description: |
+          Microseconds of CPU time that the container can get in a CPU period.
+        type: "integer"
+        format: "int64"
+      CpuRealtimePeriod:
+        description: |
+          The length of a CPU real-time period in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpuRealtimeRuntime:
+        description: |
+          The length of a CPU real-time runtime in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpusetCpus:
+        description: |
+          CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+        type: "string"
+        example: "0-3"
+      CpusetMems:
+        description: |
+          Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only
+          effective on NUMA systems.
+        type: "string"
+      Devices:
+        description: "A list of devices to add to the container."
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceMapping"
+      DeviceCgroupRules:
+        description: "a list of cgroup rules to apply to the container"
+        type: "array"
+        items:
+          type: "string"
+          example: "c 13:* rwm"
+      DeviceRequests:
+        description: |
+          A list of requests for devices to be sent to device drivers.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceRequest"
+      MemoryReservation:
+        description: "Memory soft limit in bytes."
+        type: "integer"
+        format: "int64"
+      MemorySwap:
+        description: |
+          Total memory limit (memory + swap). Set as `-1` to enable unlimited
+          swap.
+        type: "integer"
+        format: "int64"
+      MemorySwappiness:
+        description: |
+          Tune a container's memory swappiness behavior. Accepts an integer
+          between 0 and 100.
+        type: "integer"
+        format: "int64"
+        minimum: 0
+        maximum: 100
+      NanoCpus:
+        description: "CPU quota in units of 10<sup>-9</sup> CPUs."
+        type: "integer"
+        format: "int64"
+      OomKillDisable:
+        description: "Disable OOM Killer for the container."
+        type: "boolean"
+      Init:
+        description: |
+          Run an init inside the container that forwards signals and reaps
+          processes. This field is omitted if empty, and the default (as
+          configured on the daemon) is used.
+        type: "boolean"
+        x-nullable: true
+      PidsLimit:
+        description: |
+          Tune a container's PIDs limit. Set `0` or `-1` for unlimited, or `null`
+          to not change.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+      Ulimits:
+        description: |
+          A list of resource limits to set in the container. For example:
+
+          ```
+          {"Name": "nofile", "Soft": 1024, "Hard": 2048}
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Name:
+              description: "Name of ulimit"
+              type: "string"
+            Soft:
+              description: "Soft limit"
+              type: "integer"
+            Hard:
+              description: "Hard limit"
+              type: "integer"
+      # Applicable to Windows
+      CpuCount:
+        description: |
+          The number of usable CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      CpuPercent:
+        description: |
+          The usable percentage of the available CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      IOMaximumIOps:
+        description: "Maximum IOps for the container system drive (Windows only)"
+        type: "integer"
+        format: "int64"
+      IOMaximumBandwidth:
+        description: |
+          Maximum IO in bytes per second for the container system drive
+          (Windows only).
+        type: "integer"
+        format: "int64"
+
+  Limit:
+    description: |
+      An object describing a limit on resources which can be requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      Pids:
+        description: |
+          Limits the maximum number of PIDs in the container. Set `0` for unlimited.
+        type: "integer"
+        format: "int64"
+        default: 0
+        example: 100
+
+  ResourceObject:
+    description: |
+      An object describing the resources which can be advertised by a node and
+      requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+
+  GenericResources:
+    description: |
+      User-defined resources can be either Integer resources (e.g, `SSD=3`) or
+      String resources (e.g, `GPU=UUID1`).
+    type: "array"
+    items:
+      type: "object"
+      properties:
+        NamedResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "string"
+        DiscreteResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "integer"
+              format: "int64"
+    example:
+      - DiscreteResourceSpec:
+          Kind: "SSD"
+          Value: 3
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID1"
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID2"
+
+  HealthConfig:
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
+    type: "object"
+    properties:
+      Test:
+        description: |
+          The test to perform. Possible values are:
+
+          - `[]` inherit healthcheck from image or parent image
+          - `["NONE"]` disable healthcheck
+          - `["CMD", args...]` exec arguments directly
+          - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
+        type: "array"
+        items:
+          type: "string"
+      Interval:
+        description: |
+          The time to wait between checks in nanoseconds. It should be 0 or at
+          least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      Timeout:
+        description: |
+          The time to wait before considering the check to have hung. It should
+          be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
+        type: "integer"
+        format: "int64"
+      Retries:
+        description: |
+          The number of consecutive failures needed to consider a container as
+          unhealthy. 0 means inherit.
+        type: "integer"
+      StartPeriod:
+        description: |
+          Start period for the container to initialize before starting
+          health-retries countdown in nanoseconds. It should be 0 or at least
+          1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      StartInterval:
+        description: |
+          The time to wait between checks in nanoseconds during the start period.
+          It should be 0 or at least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+
+  Health:
+    description: |
+      Health stores information about the container's healthcheck results.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          Status is one of `none`, `starting`, `healthy` or `unhealthy`
+
+          - "none"      Indicates there is no healthcheck
+          - "starting"  Starting indicates that the container is not yet ready
+          - "healthy"   Healthy indicates that the container is running correctly
+          - "unhealthy" Unhealthy indicates that the container has a problem
+        type: "string"
+        enum:
+          - "none"
+          - "starting"
+          - "healthy"
+          - "unhealthy"
+        example: "healthy"
+      FailingStreak:
+        description: "FailingStreak is the number of consecutive failures"
+        type: "integer"
+        example: 0
+      Log:
+        type: "array"
+        description: |
+          Log contains the last few results (oldest first)
+        items:
+          $ref: "#/definitions/HealthcheckResult"
+
+  HealthcheckResult:
+    description: |
+      HealthcheckResult stores information about a single run of a healthcheck probe
+    type: "object"
+    x-nullable: true
+    properties:
+      Start:
+        description: |
+          Date and time at which this check started in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2020-01-04T10:44:24.496525531Z"
+      End:
+        description: |
+          Date and time at which this check ended in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2020-01-04T10:45:21.364524523Z"
+      ExitCode:
+        description: |
+          ExitCode meanings:
+
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (considered unhealthy)
+          - other values: error running probe
+        type: "integer"
+        example: 0
+      Output:
+        description: "Output from last check"
+        type: "string"
+
+  HostConfig:
+    description: "Container configuration that depends on the host we are running on"
+    allOf:
+      - $ref: "#/definitions/Resources"
+      - type: "object"
+        properties:
+          # Applicable to all platforms
+          Binds:
+            type: "array"
+            description: |
+              A list of volume bindings for this container. Each volume binding
+              is a string in one of these forms:
+
+              - `host-src:container-dest[:options]` to bind-mount a host path
+                into the container. Both `host-src`, and `container-dest` must
+                be an _absolute_ path.
+              - `volume-name:container-dest[:options]` to bind-mount a volume
+                managed by a volume driver into the container. `container-dest`
+                must be an _absolute_ path.
+
+              `options` is an optional, comma-delimited list of:
+
+              - `nocopy` disables automatic copying of data from the container
+                path to the volume. The `nocopy` flag only applies to named volumes.
+              - `[ro|rw]` mounts a volume read-only or read-write, respectively.
+                If omitted or set to `rw`, volumes are mounted read-write.
+              - `[z|Z]` applies SELinux labels to allow or deny multiple containers
+                to read and write to the same volume.
+                  - `z`: a _shared_ content label is applied to the content. This
+                    label indicates that multiple containers can share the volume
+                    content, for both reading and writing.
+                  - `Z`: a _private unshared_ label is applied to the content.
+                    This label indicates that only the current container can use
+                    a private volume. Labeling systems such as SELinux require
+                    proper labels to be placed on volume content that is mounted
+                    into a container. Without a label, the security system can
+                    prevent a container's processes from using the content. By
+                    default, the labels set by the host operating system are not
+                    modified.
+              - `[[r]shared|[r]slave|[r]private]` specifies mount
+                [propagation behavior](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt).
+                This only applies to bind-mounted volumes, not internal volumes
+                or named volumes. Mount propagation requires the source mount
+                point (the location where the source directory is mounted in the
+                host operating system) to have the correct propagation properties.
+                For shared volumes, the source mount point must be set to `shared`.
+                For slave volumes, the mount must be set to either `shared` or
+                `slave`.
+            items:
+              type: "string"
+          ContainerIDFile:
+            type: "string"
+            description: "Path to a file where the container ID is written"
+            example: ""
+          LogConfig:
+            type: "object"
+            description: "The logging configuration for this container"
+            properties:
+              Type:
+                description: |-
+                  Name of the logging driver used for the container or "none"
+                  if logging is disabled.
+                type: "string"
+                enum:
+                  - "local"
+                  - "json-file"
+                  - "syslog"
+                  - "journald"
+                  - "gelf"
+                  - "fluentd"
+                  - "awslogs"
+                  - "splunk"
+                  - "etwlogs"
+                  - "none"
+              Config:
+                description: |-
+                  Driver-specific configuration options for the logging driver.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "5"
+                  "max-size": "10m"
+          NetworkMode:
+            type: "string"
+            description: |
+              Network mode to use for this container. Supported standard values
+              are: `bridge`, `host`, `none`, and `container:<name|id>`. Any
+              other value is taken as a custom network's name to which this
+              container should connect to.
+          PortBindings:
+            $ref: "#/definitions/PortMap"
+          RestartPolicy:
+            $ref: "#/definitions/RestartPolicy"
+          AutoRemove:
+            type: "boolean"
+            description: |
+              Automatically remove the container when the container's process
+              exits. This has no effect if `RestartPolicy` is set.
+          VolumeDriver:
+            type: "string"
+            description: "Driver that this container uses to mount volumes."
+          VolumesFrom:
+            type: "array"
+            description: |
+              A list of volumes to inherit from another container, specified in
+              the form `<container name>[:<ro|rw>]`.
+            items:
+              type: "string"
+          Mounts:
+            description: |
+              Specification for mounts to be added to the container.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          ConsoleSize:
+            type: "array"
+            description: |
+              Initial console size, as an `[height, width]` array.
+            x-nullable: true
+            minItems: 2
+            maxItems: 2
+            items:
+              type: "integer"
+              minimum: 0
+            example: [80, 64]
+          Annotations:
+            type: "object"
+            description: |
+              Arbitrary non-identifying metadata attached to container and
+              provided to the runtime when the container is started.
+            additionalProperties:
+              type: "string"
+
+          # Applicable to UNIX platforms
+          CapAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CapDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CgroupnsMode:
+            type: "string"
+            enum:
+              - "private"
+              - "host"
+            description: |
+              cgroup namespace mode for the container. Possible values are:
+
+              - `"private"`: the container runs in its own private cgroup namespace
+              - `"host"`: use the host system's cgroup namespace
+
+              If not specified, the daemon default is used, which can either be `"private"`
+              or `"host"`, depending on daemon version, kernel support and configuration.
+          Dns:
+            type: "array"
+            description: "A list of DNS servers for the container to use."
+            items:
+              type: "string"
+              format: "ip-address"
+              x-go-type:
+                type: Addr
+                import:
+                  package: net/netip
+          DnsOptions:
+            type: "array"
+            description: "A list of DNS options."
+            items:
+              type: "string"
+          DnsSearch:
+            type: "array"
+            description: "A list of DNS search domains."
+            items:
+              type: "string"
+          ExtraHosts:
+            type: "array"
+            description: |
+              A list of hostnames/IP mappings to add to the container's `/etc/hosts`
+              file. Specified in the form `["hostname:IP"]`.
+            items:
+              type: "string"
+          GroupAdd:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          IpcMode:
+            type: "string"
+            description: |
+              IPC sharing mode for the container. Possible values are:
+
+              - `"none"`: own private IPC namespace, with /dev/shm not mounted
+              - `"private"`: own private IPC namespace
+              - `"shareable"`: own private IPC namespace, with a possibility to share it with other containers
+              - `"container:<name|id>"`: join another (shareable) container's IPC namespace
+              - `"host"`: use the host system's IPC namespace
+
+              If not specified, daemon default is used, which can either be `"private"`
+              or `"shareable"`, depending on daemon version and configuration.
+          Cgroup:
+            type: "string"
+            description: "Cgroup to use for the container."
+          Links:
+            type: "array"
+            description: |
+              A list of links for the container in the form `container_name:alias`.
+            items:
+              type: "string"
+          OomScoreAdj:
+            type: "integer"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 500
+          PidMode:
+            type: "string"
+            description: |
+              Set the PID (Process) Namespace mode for the container. It can be
+              either:
+
+              - `"container:<name|id>"`: joins another container's PID namespace
+              - `"host"`: use the host's PID namespace inside the container
+          Privileged:
+            type: "boolean"
+            description: |-
+              Gives the container full access to the host.
+          PublishAllPorts:
+            type: "boolean"
+            description: |
+              Allocates an ephemeral host port for all of a container's
+              exposed ports.
+
+              Ports are de-allocated when the container stops and allocated when
+              the container starts. The allocated port might be changed when
+              restarting the container.
+
+              The port is selected from the ephemeral port range that depends on
+              the kernel. For example, on Linux the range is defined by
+              `/proc/sys/net/ipv4/ip_local_port_range`.
+          ReadonlyRootfs:
+            type: "boolean"
+            description: "Mount the container's root filesystem as read only."
+          SecurityOpt:
+            type: "array"
+            description: |
+              A list of string values to customize labels for MLS systems, such
+              as SELinux.
+            items:
+              type: "string"
+          StorageOpt:
+            type: "object"
+            description: |
+              Storage driver options for this container, in the form `{"size": "120G"}`.
+            additionalProperties:
+              type: "string"
+          Tmpfs:
+            type: "object"
+            description: |
+              A map of container directories which should be replaced by tmpfs
+              mounts, and their corresponding mount options. For example:
+
+              ```
+              { "/run": "rw,noexec,nosuid,size=65536k" }
+              ```
+            additionalProperties:
+              type: "string"
+          UTSMode:
+            type: "string"
+            description: "UTS namespace to use for the container."
+          UsernsMode:
+            type: "string"
+            description: |
+              Sets the usernamespace mode for the container when usernamespace
+              remapping option is enabled.
+          ShmSize:
+            type: "integer"
+            format: "int64"
+            description: |
+              Size of `/dev/shm` in bytes. If omitted, the system uses 64MB.
+            minimum: 0
+          Sysctls:
+            type: "object"
+            x-nullable: true
+            description: |-
+              A list of kernel parameters (sysctls) to set in the container.
+
+              This field is omitted if not set.
+            additionalProperties:
+              type: "string"
+            example:
+              "net.ipv4.ip_forward": "1"
+          Runtime:
+            type: "string"
+            x-nullable: true
+            description: |-
+              Runtime to use with this container.
+          # Applicable to Windows
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the container. (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          MaskedPaths:
+            type: "array"
+            description: |
+              The list of paths to be masked inside the container (this overrides
+              the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/asound"
+              - "/proc/acpi"
+              - "/proc/kcore"
+              - "/proc/keys"
+              - "/proc/latency_stats"
+              - "/proc/timer_list"
+              - "/proc/timer_stats"
+              - "/proc/sched_debug"
+              - "/proc/scsi"
+              - "/sys/firmware"
+              - "/sys/devices/virtual/powercap"
+          ReadonlyPaths:
+            type: "array"
+            description: |
+              The list of paths to be set as read-only inside the container
+              (this overrides the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/bus"
+              - "/proc/fs"
+              - "/proc/irq"
+              - "/proc/sys"
+              - "/proc/sysrq-trigger"
+
+  ContainerConfig:
+    description: |
+      Configuration for a container that is portable between hosts.
+    type: "object"
+    properties:
+      Hostname:
+        description: |
+          The hostname to use for the container, as a valid RFC 1123 hostname.
+        type: "string"
+        example: "439f4e91bd1d"
+      Domainname:
+        description: |
+          The domain name to use for the container.
+        type: "string"
+      User:
+        description: |-
+          Commands run as this user inside the container. If omitted, commands
+          run as the user specified in the image the container was started from.
+
+          Can be either user-name or UID, and optional group-name or GID,
+          separated by a colon (`<user-name|UID>[<:group-name|GID>]`).
+        type: "string"
+        example: "123:456"
+      AttachStdin:
+        description: "Whether to attach to `stdin`."
+        type: "boolean"
+        default: false
+      AttachStdout:
+        description: "Whether to attach to `stdout`."
+        type: "boolean"
+        default: true
+      AttachStderr:
+        description: "Whether to attach to `stderr`."
+        type: "boolean"
+        default: true
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Tty:
+        description: |
+          Attach standard streams to a TTY, including `stdin` if it is not closed.
+        type: "boolean"
+        default: false
+      OpenStdin:
+        description: "Open `stdin`"
+        type: "boolean"
+        default: false
+      StdinOnce:
+        description: "Close `stdin` after one attached client disconnects"
+        type: "boolean"
+        default: false
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Image:
+        description: |
+          The name (or reference) of the image to use when creating the container,
+          or which was used when the container was created.
+        type: "string"
+        example: "example-image:1.0"
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      NetworkDisabled:
+        description: "Disable networking for the container."
+        type: "boolean"
+        x-nullable: true
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      StopTimeout:
+        description: "Timeout to stop a container in seconds."
+        type: "integer"
+        default: 10
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  ImageConfig:
+    description: |
+      Configuration of the image. These fields are used as defaults
+      when starting a container from the image.
+    type: "object"
+    properties:
+      User:
+        description: "The user that commands are run as inside the container."
+        type: "string"
+        example: "web:web"
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example:
+          "/app/data": {}
+          "/app/config": {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  NetworkingConfig:
+    description: |
+      NetworkingConfig represents the container's networking configuration for
+      each of its interfaces.
+      It is used for the networking configs specified in the `docker create`
+      and `docker network connect` commands.
+    type: "object"
+    properties:
+      EndpointsConfig:
+        description: |
+          A mapping of network name to endpoint configuration for that network.
+          The endpoint configuration can be left empty to connect to that
+          network with no particular endpoint configuration.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+    example:
+      # putting an example here, instead of using the example values from
+      # /definitions/EndpointSettings, because EndpointSettings contains
+      # operational data returned when inspecting a container that we don't
+      # accept here.
+      EndpointsConfig:
+        isolated_nw:
+          IPAMConfig:
+            IPv4Address: "172.20.30.33"
+            IPv6Address: "2001:db8:abcd::3033"
+            LinkLocalIPs:
+              - "169.254.34.68"
+              - "fe80::3468"
+          MacAddress: "02:42:ac:12:05:02"
+          Links:
+            - "container_1"
+            - "container_2"
+          Aliases:
+            - "server_x"
+            - "server_y"
+        database_nw: {}
+
+  NetworkSettings:
+    description: "NetworkSettings exposes the network settings in the API"
+    type: "object"
+    properties:
+      SandboxID:
+        description: SandboxID uniquely represents a container's network stack.
+        type: "string"
+        example: "9d12daf2c33f5959c8bf90aa513e4f65b561738661003029ec84830cd503a0c3"
+      SandboxKey:
+        description: SandboxKey is the full path of the netns handle
+        type: "string"
+        example: "/var/run/docker/netns/8ab54b426c38"
+      Ports:
+        $ref: "#/definitions/PortMap"
+      Networks:
+        description: |
+          Information about all networks that the container is connected to.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+
+  Address:
+    description: Address represents an IPv4 or IPv6 IP address.
+    type: "object"
+    properties:
+      Addr:
+        description: IP address.
+        type: "string"
+      PrefixLen:
+        description: Mask length of the IP address.
+        type: "integer"
+
+  PortMap:
+    description: |
+      PortMap describes the mapping of container ports to host ports, using the
+      container's port-number and protocol as key in the format `<port>/<protocol>`,
+      for example, `80/udp`.
+
+      If a container's port is mapped for multiple protocols, separate entries
+      are added to the mapping table.
+    type: "object"
+    additionalProperties:
+      type: "array"
+      x-nullable: true
+      items:
+        $ref: "#/definitions/PortBinding"
+    example:
+      "443/tcp":
+        - HostIp: "127.0.0.1"
+          HostPort: "4443"
+      "80/tcp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+        - HostIp: "0.0.0.0"
+          HostPort: "8080"
+      "80/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+      "53/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "53"
+      "2377/tcp": null
+
+  PortBinding:
+    description: |
+      PortBinding represents a binding between a host IP address and a host
+      port.
+    type: "object"
+    properties:
+      HostIp:
+        description: "Host IP address that the container's port is mapped to."
+        type: "string"
+        example: "127.0.0.1"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      HostPort:
+        description: "Host port number that the container's port is mapped to."
+        type: "string"
+        example: "4443"
+
+  DriverData:
+    description: |
+      Information about the storage driver used to store the container's and
+      image's filesystem.
+    type: "object"
+    required: [Name, Data]
+    properties:
+      Name:
+        description: "Name of the storage driver."
+        type: "string"
+        x-nullable: false
+        example: "overlay2"
+      Data:
+        description: |
+          Low-level storage metadata, provided as key/value pairs.
+
+          This information is driver-specific, and depends on the storage-driver
+          in use, and should be used for informational purposes only.
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example: {
+          "MergedDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/merged",
+          "UpperDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/diff",
+          "WorkDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/work"
+        }
+
+  Storage:
+    description: |
+      Information about the storage used by the container.
+    type: "object"
+    properties:
+      RootFS:
+        description: |
+          Information about the storage used for the container's root filesystem.
+        type: "object"
+        x-nullable: true
+        $ref: "#/definitions/RootFSStorage"
+
+  RootFSStorage:
+    description: |
+      Information about the storage used for the container's root filesystem.
+    type: "object"
+    x-go-name: RootFSStorage
+    properties:
+      Snapshot:
+        description: |
+          Information about the snapshot used for the container's root filesystem.
+        type: "object"
+        x-nullable: true
+        $ref: "#/definitions/RootFSStorageSnapshot"
+
+  RootFSStorageSnapshot:
+    description: |
+      Information about a snapshot backend of the container's root filesystem.
+    type: "object"
+    x-go-name: RootFSStorageSnapshot
+    properties:
+      Name:
+        description: "Name of the snapshotter."
+        type: "string"
+        x-nullable: false
+
+  FilesystemChange:
+    description: |
+      Change in the container's filesystem.
+    type: "object"
+    required: [Path, Kind]
+    properties:
+      Path:
+        description: |
+          Path to file or directory that has changed.
+        type: "string"
+        x-nullable: false
+      Kind:
+        $ref: "#/definitions/ChangeType"
+
+  ChangeType:
+    description: |
+      Kind of change
+
+      Can be one of:
+
+      - `0`: Modified ("C")
+      - `1`: Added ("A")
+      - `2`: Deleted ("D")
+    type: "integer"
+    format: "uint8"
+    enum: [0, 1, 2]
+    x-nullable: false
+
+  ImageInspect:
+    description: |
+      Information about an image in the local image cache.
+    type: "object"
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+      Manifests:
+        description: |
+          Manifests is a list of image manifests available in this image. It
+          provides a more detailed view of the platform-specific image manifests or
+          other image-attached data like build attestations.
+
+          Only available if the daemon provides a multi-platform image store
+          and the `manifests` option is set in the inspect request.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        type: "array"
+        x-nullable: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      Identity:
+        description: |-
+          Identity holds information about the identity and origin of the image.
+          This is trusted information verified by the daemon and cannot be modified
+          by tagging an image to a different name.
+        x-nullable: true
+        $ref: "#/definitions/Identity"
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Comment:
+        description: |
+          Optional message that was set when committing or importing the image.
+        type: "string"
+        x-nullable: true
+        example: ""
+      Created:
+        description: |
+          Date and time at which the image was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+          This information is only available if present in the image,
+          and omitted otherwise.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2022-02-04T21:20:12.497794809Z"
+      Author:
+        description: |
+          Name of the author that was specified when committing the image, or as
+          specified through MAINTAINER (deprecated) in the Dockerfile.
+        type: "string"
+        x-nullable: true
+        example: ""
+      Config:
+        $ref: "#/definitions/ImageConfig"
+      Architecture:
+        description: |
+          Hardware CPU architecture that the image runs on.
+        type: "string"
+        x-nullable: false
+        example: "arm"
+      Variant:
+        description: |
+          CPU architecture variant (presently ARM-only).
+        type: "string"
+        x-nullable: true
+        example: "v7"
+      Os:
+        description: |
+          Operating System the image is built to run on.
+        type: "string"
+        x-nullable: false
+        example: "linux"
+      OsVersion:
+        description: |
+          Operating System version the image is built to run on (especially
+          for Windows).
+        type: "string"
+        example: ""
+        x-nullable: true
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      GraphDriver:
+        x-nullable: true
+        $ref: "#/definitions/DriverData"
+      RootFS:
+        description: |
+          Information about the image's RootFS, including the layer IDs.
+        type: "object"
+        required: [Type]
+        properties:
+          Type:
+            type: "string"
+            x-nullable: false
+            example: "layers"
+          Layers:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "sha256:1834950e52ce4d5a88a1bbd131c537f4d0e56d10ff0dd69e66be3b7dfa9df7e6"
+              - "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"
+      Metadata:
+        description: |
+          Additional metadata of the image in the local cache. This information
+          is local to the daemon, and not part of the image itself.
+        type: "object"
+        properties:
+          LastTagTime:
+            description: |
+              Date and time at which the image was last tagged in
+              [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+              This information is only available if the image was tagged locally,
+              and omitted otherwise.
+            type: "string"
+            format: "dateTime"
+            example: "2022-02-28T14:40:02.623929178Z"
+            x-nullable: true
+
+  Identity:
+    description: |-
+      Identity holds information about the identity and origin of the image.
+      This is trusted information verified by the daemon and cannot be modified
+      by tagging an image to a different name.
+    type: "object"
+    properties:
+      Signature:
+        description: |-
+          Signature contains the properties of verified signatures for the image.
+        type: "array"
+        items:
+          $ref: "#/definitions/SignatureIdentity"
+      Pull:
+        description: |-
+          Pull contains remote location information if image was created via pull.
+          If image was pulled via mirror, this contains the original repository location.
+          After successful push this images also contains the pushed repository location.
+        type: "array"
+        items:
+          $ref: "#/definitions/PullIdentity"
+      Build:
+        description: |-
+          Build contains build reference information if image was created via build.
+        type: "array"
+        items:
+          $ref: "#/definitions/BuildIdentity"
+
+  BuildIdentity:
+    description: |-
+      BuildIdentity contains build reference information if image was created via build.
+    type: "object"
+    properties:
+      Ref:
+        description: |-
+          Ref is the identifier for the build request. This reference can be used to
+          look up the build details in BuildKit history API.
+        type: "string"
+      CreatedAt:
+        description: |-
+          CreatedAt is the time when the build ran.
+        type: "string"
+        format: "date-time"
+
+  PullIdentity:
+    description: |-
+      PullIdentity contains remote location information if image was created via pull.
+      If image was pulled via mirror, this contains the original repository location.
+    type: "object"
+    properties:
+      Repository:
+        description: |-
+          Repository is the remote repository location the image was pulled from.
+        type: "string"
+
+  SignatureIdentity:
+    description: |-
+      SignatureIdentity contains the properties of verified signatures for the image.
+    type: "object"
+    properties:
+      Name:
+        description: |-
+          Name is a textual description summarizing the type of signature.
+        type: "string"
+      Timestamps:
+        description: |-
+          Timestamps contains a list of verified signed timestamps for the signature.
+        type: "array"
+        items:
+          $ref: "#/definitions/SignatureTimestamp"
+      KnownSigner:
+        description: |-
+          KnownSigner is an identifier for a special signer identity that is known to the implementation.
+        $ref: "#/definitions/KnownSignerIdentity"
+      DockerReference:
+        description: |-
+          DockerReference is the Docker image reference associated with the signature.
+          This is an optional field only present in older hashedrecord signatures.
+        type: "string"
+      Signer:
+        description: |-
+          Signer contains information about the signer certificate used to sign the image.
+        $ref: "#/definitions/SignerIdentity"
+      SignatureType:
+        description: |-
+          SignatureType is the type of signature format. E.g. "bundle-v0.3" or "hashedrecord".
+        $ref: "#/definitions/SignatureType"
+      Error:
+        description: |-
+          Error contains error information if signature verification failed.
+          Other fields will be empty in this case.
+        type: "string"
+      Warnings:
+        description: |-
+          Warnings contains any warnings that occurred during signature verification.
+          For example, if there was no internet connectivity and cached trust roots were used.
+          Warning does not indicate a failed verification but may point to configuration issues.
+        type: "array"
+        items:
+          type: "string"
+
+  SignatureTimestamp:
+    description: |-
+      SignatureTimestamp contains information about a verified signed timestamp for an image signature.
+    type: "object"
+    properties:
+      Type:
+        $ref: "#/definitions/SignatureTimestampType"
+      URI:
+        type: "string"
+      Timestamp:
+        type: "string"
+        format: "date-time"
+
+  SignatureTimestampType:
+    description: |-
+      SignatureTimestampType is the type of timestamp used in the signature.
+    type: "string"
+    enum:
+      - "Tlog"
+      - "TimestampAuthority"
+
+  SignatureType:
+    description: |-
+      SignatureType is the type of signature format.
+    type: "string"
+    enum:
+      - "bundle-v0.3"
+      - "simplesigning-v1"
+
+  KnownSignerIdentity:
+    description: |-
+      KnownSignerIdentity is an identifier for a special signer identity that is known to the implementation.
+    type: "string"
+    enum:
+      - "DHI"
+
+  SignerIdentity:
+    description: |-
+      SignerIdentity contains information about the signer certificate used to sign the image.
+    type: "object"
+    properties:
+      CertificateIssuer:
+        type: "string"
+        description: |-
+          CertificateIssuer is the certificate issuer.
+      SubjectAlternativeName:
+        type: "string"
+        description: |-
+          SubjectAlternativeName is the certificate subject alternative name.
+      Issuer:
+        type: "string"
+        description: |-
+          The OIDC issuer. Should match `iss` claim of ID token or, in the case of
+          a federated login like Dex it should match the issuer URL of the
+          upstream issuer. The issuer is not set the extensions are invalid and
+          will fail to render.
+      BuildSignerURI:
+        type: "string"
+        description: |-
+          Reference to specific build instructions that are responsible for signing.
+      BuildSignerDigest:
+        type: "string"
+        description: |-
+          Immutable reference to the specific version of the build instructions that is responsible for signing.
+      RunnerEnvironment:
+        type: "string"
+        description: |-
+          Specifies whether the build took place in platform-hosted cloud infrastructure or customer/self-hosted infrastructure.
+      SourceRepositoryURI:
+        type: "string"
+        description: |-
+          Source repository URL that the build was based on.
+      SourceRepositoryDigest:
+        type: "string"
+        description: |-
+          Immutable reference to a specific version of the source code that the build was based upon.
+      SourceRepositoryRef:
+        type: "string"
+        description: |-
+          Source Repository Ref that the build run was based upon.
+      SourceRepositoryIdentifier:
+        type: "string"
+        description: |-
+          Immutable identifier for the source repository the workflow was based upon.
+      SourceRepositoryOwnerURI:
+        type: "string"
+        description: |-
+          Source repository owner URL of the owner of the source repository that the build was based on.
+      SourceRepositoryOwnerIdentifier:
+        type: "string"
+        description: |-
+          Immutable identifier for the owner of the source repository that the workflow was based upon.
+      BuildConfigURI:
+        type: "string"
+        description: |-
+          Build Config URL to the top-level/initiating build instructions.
+      BuildConfigDigest:
+        type: "string"
+        description: |-
+          Immutable reference to the specific version of the top-level/initiating build instructions.
+      BuildTrigger:
+        type: "string"
+        description: |-
+          Event or action that initiated the build.
+      RunInvocationURI:
+        type: "string"
+        description: |-
+          Run Invocation URL to uniquely identify the build execution.
+      SourceRepositoryVisibilityAtSigning:
+        type: "string"
+        description: |-
+          Source repository visibility at the time of signing the certificate.
+
+  ImageSummary:
+    type: "object"
+    x-go-name: "Summary"
+    required:
+      - Id
+      - ParentId
+      - RepoTags
+      - RepoDigests
+      - Created
+      - Size
+      - SharedSize
+      - Labels
+      - Containers
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      ParentId:
+        description: |
+          ID of the parent image.
+
+          Depending on how the image was created, this field may be empty and
+          is only set for images that were built/created locally. This field
+          is empty if the image was pulled from an image registry.
+        type: "string"
+        x-nullable: false
+        example: ""
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Created:
+        description: |
+          Date and time at which the image was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        x-nullable: false
+        example: "1644009612"
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 172064416
+      SharedSize:
+        description: |
+          Total size of image layers that are shared between this image and other
+          images.
+
+          This size is not calculated by default. `-1` indicates that the value
+          has not been set / calculated.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Containers:
+        description: |
+          Number of containers using this image. Includes both stopped and running
+          containers.
+
+          `-1` indicates that the value has not been set / calculated.
+        x-nullable: false
+        type: "integer"
+        example: 2
+      Manifests:
+        description: |
+          Manifests is a list of manifests available in this image.
+          It provides a more detailed view of the platform-specific image manifests
+          or other image-attached data like build attestations.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        type: "array"
+        x-nullable: false
+        x-omitempty: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+
+  ImagesDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/image"
+    description: |
+      represents system data usage for image resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active images.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all images.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing unused images.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by images.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of image summaries.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Summary
+
+  AuthConfig:
+    type: "object"
+    properties:
+      username:
+        type: "string"
+      password:
+        type: "string"
+      serveraddress:
+        type: "string"
+    example:
+      username: "hannibal"
+      password: "xxxx"
+      serveraddress: "https://index.docker.io/v1/"
+
+  AuthResponse:
+    description: |
+      An identity token was generated successfully.
+    type: "object"
+    required: [Status]
+    properties:
+      Status:
+        description: "The status of the authentication"
+        type: "string"
+        example: "Login Succeeded"
+        x-nullable: false
+      IdentityToken:
+        description: "An opaque token used to authenticate a user after a successful login"
+        type: "string"
+        example: "9cbaf023786cd7..."
+        x-nullable: false
+
+  ProcessConfig:
+    type: "object"
+    properties:
+      privileged:
+        type: "boolean"
+      user:
+        type: "string"
+      tty:
+        type: "boolean"
+      entrypoint:
+        type: "string"
+      arguments:
+        type: "array"
+        items:
+          type: "string"
+
+  Volume:
+    type: "object"
+    required: [Name, Driver, Mountpoint, Labels, Scope, Options]
+    x-nullable: false
+    properties:
+      Name:
+        type: "string"
+        description: "Name of the volume."
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        type: "string"
+        description: "Name of the volume driver used by the volume."
+        x-nullable: false
+        example: "custom"
+      Mountpoint:
+        type: "string"
+        description: "Mount path of the volume on the host."
+        x-nullable: false
+        example: "/var/lib/docker/volumes/tardis"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        description: "Date/Time the volume was created."
+        example: "2016-06-07T20:31:11.853781916Z"
+      Status:
+        type: "object"
+        description: |
+          Low-level details about the volume, provided by the volume driver.
+          Details are returned as a map with key/value pairs:
+          `{"key":"value","key2":"value2"}`.
+
+          The `Status` field is optional, and is omitted if the volume driver
+          does not support this feature.
+        additionalProperties:
+          type: "object"
+        example:
+          hello: "world"
+      Labels:
+        type: "object"
+        description: "User-defined key/value metadata."
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Scope:
+        type: "string"
+        description: |
+          The level at which the volume exists. Either `global` for cluster-wide,
+          or `local` for machine level.
+        default: "local"
+        x-nullable: false
+        enum: ["local", "global"]
+        example: "local"
+      ClusterVolume:
+        $ref: "#/definitions/ClusterVolume"
+      Options:
+        type: "object"
+        description: |
+          The driver specific options used when creating the volume.
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      UsageData:
+        type: "object"
+        x-nullable: true
+        x-go-name: "UsageData"
+        required: [Size, RefCount]
+        description: |
+          Usage details about the volume. This information is used by the
+          `GET /system/df` endpoint, and omitted in other endpoints.
+        properties:
+          Size:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              Amount of disk space used by the volume (in bytes). This information
+              is only available for volumes created with the `"local"` volume
+              driver. For volumes created with other volume drivers, this field
+              is set to `-1` ("not available")
+            x-nullable: false
+          RefCount:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              The number of containers referencing this volume. This field
+              is set to `-1` if the reference-count is not available.
+            x-nullable: false
+
+  VolumesDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/volume"
+    description: |
+      represents system data usage for volume resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active volumes.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all volumes.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive volumes.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by volumes.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of volumes.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Volume
+
+  VolumeCreateRequest:
+    description: "Volume configuration"
+    type: "object"
+    title: "VolumeConfig"
+    x-go-name: "CreateRequest"
+    properties:
+      Name:
+        description: |
+          The new volume's name. If not specified, Docker generates a name.
+        type: "string"
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        description: "Name of the volume driver to use."
+        type: "string"
+        default: "local"
+        x-nullable: false
+        example: "custom"
+      DriverOpts:
+        description: |
+          A mapping of driver options and values. These options are
+          passed directly to the driver and are driver specific.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      ClusterVolumeSpec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+
+  VolumeListResponse:
+    type: "object"
+    title: "VolumeListResponse"
+    x-go-name: "ListResponse"
+    description: "Volume list response"
+    properties:
+      Volumes:
+        type: "array"
+        description: "List of volumes"
+        items:
+          $ref: "#/definitions/Volume"
+      Warnings:
+        type: "array"
+        description: |
+          Warnings that occurred when fetching the list of volumes.
+        items:
+          type: "string"
+        example: []
+
+  Network:
+    type: "object"
+    properties:
+      Name:
+        description: |
+          Name of the network.
+        type: "string"
+        example: "my_network"
+        x-omitempty: false
+      Id:
+        description: |
+          ID that uniquely identifies a network on a single machine.
+        type: "string"
+        x-go-name: "ID"
+        x-omitempty: false
+        example: "7d86d31b1478e7cca9ebed7e73aa0fdeec46c5ca29497431d3007d2d9e15ed99"
+      Created:
+        description: |
+          Date and time at which the network was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-omitempty: false
+        x-go-type:
+          type: Time
+          import:
+            package: time
+          hints:
+            nullable: false
+        example: "2016-10-19T04:33:30.360899459Z"
+      Scope:
+        description: |
+          The level at which the network exists (e.g. `swarm` for cluster-wide
+          or `local` for machine level)
+        type: "string"
+        x-omitempty: false
+        example: "local"
+      Driver:
+        description: |
+          The name of the driver used to create the network (e.g. `bridge`,
+          `overlay`).
+        type: "string"
+        x-omitempty: false
+        example: "overlay"
+      EnableIPv4:
+        description: |
+          Whether the network was created with IPv4 enabled.
+        type: "boolean"
+        x-omitempty: false
+        example: true
+      EnableIPv6:
+        description: |
+          Whether the network was created with IPv6 enabled.
+        type: "boolean"
+        x-omitempty: false
+        example: false
+      IPAM:
+        description: |
+          The network's IP Address Management.
+        $ref: "#/definitions/IPAM"
+        x-nullable: false
+        x-omitempty: false
+      Internal:
+        description: |
+          Whether the network is created to only allow internal networking
+          connectivity.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      Attachable:
+        description: |
+          Whether a global / swarm scope network is manually attachable by regular
+          containers from workers in swarm mode.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      Ingress:
+        description: |
+          Whether the network is providing the routing-mesh for the swarm cluster.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      ConfigFrom:
+        $ref: "#/definitions/ConfigReference"
+        x-nullable: false
+        x-omitempty: false
+      ConfigOnly:
+        description: |
+          Whether the network is a config-only network. Config-only networks are
+          placeholder networks for network configurations to be used by other
+          networks. Config-only networks cannot be used directly to run containers
+          or services.
+        type: "boolean"
+        x-omitempty: false
+        x-nullable: false
+        default: false
+      Options:
+        description: |
+          Network-specific options uses when creating the network.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.docker.network.bridge.default_bridge: "true"
+          com.docker.network.bridge.enable_icc: "true"
+          com.docker.network.bridge.enable_ip_masquerade: "true"
+          com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+          com.docker.network.bridge.name: "docker0"
+          com.docker.network.driver.mtu: "1500"
+      Labels:
+        description: |
+          Metadata specific to the network being created.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Peers:
+        description: |
+          List of peer nodes for an overlay network. This field is only present
+          for overlay networks, and omitted for other network types.
+        type: "array"
+        x-omitempty: true
+        items:
+          $ref: "#/definitions/PeerInfo"
+
+  NetworkSummary:
+    description: "Network list response item"
+    x-go-name: Summary
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/Network"
+
+  NetworkInspect:
+    description: 'The body of the "get network" http response message.'
+    x-go-name: Inspect
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/Network"
+    properties:
+      Containers:
+        description: |
+          Contains endpoints attached to the network.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          $ref: "#/definitions/EndpointResource"
+        example:
+          19a4d5d687db25203351ed79d478946f861258f018fe384f229f2efa4b23513c:
+            Name: "test"
+            EndpointID: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+            MacAddress: "02:42:ac:13:00:02"
+            IPv4Address: "172.19.0.2/16"
+            IPv6Address: ""
+      Services:
+        description: |
+          List of services using the network. This field is only present for
+          swarm scope networks, and omitted for local scope networks.
+        type: "object"
+        x-omitempty: true
+        additionalProperties:
+          x-go-type:
+            type: ServiceInfo
+            hints:
+              nullable: false
+      Status:
+        description: >
+          provides runtime information about the network
+          such as the number of allocated IPs.
+        $ref: "#/definitions/NetworkStatus"
+
+  NetworkStatus:
+    description: >
+      provides runtime information about the network
+      such as the number of allocated IPs.
+    type: "object"
+    x-go-name: Status
+    properties:
+      IPAM:
+        $ref: "#/definitions/IPAMStatus"
+
+  ServiceInfo:
+    x-nullable: false
+    x-omitempty: false
+    description: >
+      represents service parameters with the list of service's tasks
+    type: "object"
+    properties:
+      VIP:
+        type: "string"
+        x-omitempty: false
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      Ports:
+        type: "array"
+        x-omitempty: false
+        items:
+          type: "string"
+      LocalLBIndex:
+        type: "integer"
+        format: "int"
+        x-omitempty: false
+        x-go-type:
+          type: int
+      Tasks:
+        type: "array"
+        x-omitempty: false
+        items:
+          $ref: "#/definitions/NetworkTaskInfo"
+
+  NetworkTaskInfo:
+    x-nullable: false
+    x-omitempty: false
+    x-go-name: Task
+    description: >
+      carries the information about one backend task
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        x-omitempty: false
+      EndpointID:
+        type: "string"
+        x-omitempty: false
+      EndpointIP:
+        type: "string"
+        x-omitempty: false
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      Info:
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+
+  ConfigReference:
+    x-nullable: false
+    x-omitempty: false
+    description: |
+      The config-only network source to provide the configuration for
+      this network.
+    type: "object"
+    properties:
+      Network:
+        description: |
+          The name of the config-only network that provides the network's
+          configuration. The specified network must be an existing config-only
+          network. Only network names are allowed, not network IDs.
+        type: "string"
+        x-omitempty: false
+        example: "config_only_network_01"
+
+  IPAM:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      Driver:
+        description: "Name of the IPAM driver to use."
+        type: "string"
+        default: "default"
+        example: "default"
+      Config:
+        description: |
+          List of IPAM configuration options, specified as a map:
+
+          ```
+          {"Subnet": <CIDR>, "IPRange": <CIDR>, "Gateway": <IP address>, "AuxAddress": <device_name:IP address>}
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/IPAMConfig"
+      Options:
+        description: "Driver-specific options, specified as a map."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+
+  IPAMConfig:
+    type: "object"
+    properties:
+      Subnet:
+        type: "string"
+        example: "172.20.0.0/16"
+      IPRange:
+        type: "string"
+        example: "172.20.10.0/24"
+      Gateway:
+        type: "string"
+        example: "172.20.10.11"
+      AuxiliaryAddresses:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  IPAMStatus:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      Subnets:
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/SubnetStatus"
+        example:
+          "172.16.0.0/16":
+            IPsInUse: 3
+            DynamicIPsAvailable: 65533
+          "2001:db8:abcd:0012::0/96":
+            IPsInUse: 5
+            DynamicIPsAvailable: 4294967291
+        x-go-type:
+          type: SubnetStatuses
+          kind: map
+
+  SubnetStatus:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      IPsInUse:
+        description: >
+          Number of IP addresses in the subnet that are in use or reserved and
+          are therefore unavailable for allocation, saturating at 2<sup>64</sup> - 1.
+        type: integer
+        format: uint64
+        x-omitempty: false
+      DynamicIPsAvailable:
+        description: >
+          Number of IP addresses within the network's IPRange for the subnet
+          that are available for allocation, saturating at 2<sup>64</sup> - 1.
+        type: integer
+        format: uint64
+        x-omitempty: false
+
+  EndpointResource:
+    type: "object"
+    description: >
+      contains network resources allocated and used for a
+      container in a network.
+    properties:
+      Name:
+        type: "string"
+        x-omitempty: false
+        example: "container_1"
+      EndpointID:
+        type: "string"
+        x-omitempty: false
+        example: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+      MacAddress:
+        type: "string"
+        x-omitempty: false
+        example: "02:42:ac:13:00:02"
+        x-go-type:
+          type: HardwareAddr
+      IPv4Address:
+        type: "string"
+        x-omitempty: false
+        example: "172.19.0.2/16"
+        x-go-type:
+          type: Prefix
+          import:
+            package: net/netip
+      IPv6Address:
+        type: "string"
+        x-omitempty: false
+        example: ""
+        x-go-type:
+          type: Prefix
+          import:
+            package: net/netip
+
+  PeerInfo:
+    description: >
+      represents one peer of an overlay network.
+    type: "object"
+    x-nullable: false
+    properties:
+      Name:
+        description:
+          ID of the peer-node in the Swarm cluster.
+        type: "string"
+        x-omitempty: false
+        example: "6869d7c1732b"
+      IP:
+        description:
+          IP-address of the peer-node in the Swarm cluster.
+        type: "string"
+        x-omitempty: false
+        example: "10.133.77.91"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+
+  NetworkCreateResponse:
+    description: "OK response to NetworkCreate operation"
+    type: "object"
+    title: "NetworkCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warning]
+    properties:
+      Id:
+        description: "The ID of the created network."
+        type: "string"
+        x-nullable: false
+        example: "b5c4fc71e8022147cd25de22b22173de4e3b170134117172eb595cb91b4e7e5d"
+      Warning:
+        description: "Warnings encountered when creating the container"
+        type: "string"
+        x-nullable: false
+        example: ""
+
+  BuildInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      stream:
+        type: "string"
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+      aux:
+        $ref: "#/definitions/ImageID"
+
+  BuildCache:
+    type: "object"
+    description: |
+      BuildCache contains information about a build cache record.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          Unique ID of the build cache record.
+        example: "ndlpt0hhvkqcdfkputsk4cq9c"
+      Parents:
+        description: |
+          List of parent build cache record IDs.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example: ["hw53o5aio51xtltp5xjp8v7fx"]
+      Type:
+        type: "string"
+        description: |
+          Cache record type.
+        example: "regular"
+        # see https://github.com/moby/buildkit/blob/fce4a32258dc9d9664f71a4831d5de10f0670677/client/diskusage.go#L75-L84
+        enum:
+          - "internal"
+          - "frontend"
+          - "source.local"
+          - "source.git.checkout"
+          - "exec.cachemount"
+          - "regular"
+      Description:
+        type: "string"
+        description: |
+          Description of the build-step that produced the build cache.
+        example: "mount / from exec /bin/sh -c echo 'Binary::apt::APT::Keep-Downloaded-Packages \"true\";' > /etc/apt/apt.conf.d/keep-cache"
+      InUse:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is in use.
+        example: false
+      Shared:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is shared.
+        example: true
+      Size:
+        description: |
+          Amount of disk space used by the build cache (in bytes).
+        type: "integer"
+        example: 51
+      CreatedAt:
+        description: |
+          Date and time at which the build cache was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      LastUsedAt:
+        description: |
+          Date and time at which the build cache was last used in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2017-08-09T07:09:37.632105588Z"
+      UsageCount:
+        type: "integer"
+        example: 26
+
+  BuildCacheDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/build"
+    description: |
+      represents system data usage for build cache resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active build cache records.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all build cache records.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive build cache records.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by build cache records.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of build cache records.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: CacheRecord
+
+  ImageID:
+    type: "object"
+    description: "Image ID or Digest"
+    properties:
+      ID:
+        type: "string"
+    example:
+      ID: "sha256:85f05633ddc1c50679be2b16a0479ab6f7637f8884e0cfe0f4d20e1ebb3d6e7c"
+
+  CreateImageInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  PushImageInfo:
+    type: "object"
+    properties:
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  DeviceInfo:
+    type: "object"
+    description: |
+      DeviceInfo represents a device that can be used by a container.
+    properties:
+      Source:
+        type: "string"
+        example: "cdi"
+        description: |
+          The origin device driver.
+      ID:
+        type: "string"
+        example: "vendor.com/gpu=0"
+        description: |
+          The unique identifier for the device within its source driver.
+          For CDI devices, this would be an FQDN like "vendor.com/gpu=0".
+
+  NRIInfo:
+    description: |
+      Information about the Node Resource Interface (NRI).
+
+      This field is only present if NRI is enabled.
+    type: "object"
+    x-nullable: true
+    properties:
+      Info:
+        description: |
+          Information about NRI, provided as "label" / "value" pairs.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["plugin-path", "/opt/docker/nri/plugins"]
+
+  ErrorDetail:
+    type: "object"
+    properties:
+      code:
+        type: "integer"
+      message:
+        type: "string"
+
+  ProgressDetail:
+    type: "object"
+    properties:
+      current:
+        type: "integer"
+      total:
+        type: "integer"
+
+  ErrorResponse:
+    description: "Represents an error."
+    type: "object"
+    required: ["message"]
+    properties:
+      message:
+        description: "The error message."
+        type: "string"
+        x-nullable: false
+    example:
+      message: "Something went wrong."
+
+  IDResponse:
+    description: "Response to an API call that returns just an Id"
+    type: "object"
+    x-go-name: "IDResponse"
+    required: ["Id"]
+    properties:
+      Id:
+        description: "The id of the newly created object."
+        type: "string"
+        x-nullable: false
+
+  NetworkConnectRequest:
+    description: |
+      NetworkConnectRequest represents the data to be used to connect a container to a network.
+    type: "object"
+    x-go-name: "ConnectRequest"
+    required: ["Container"]
+    properties:
+      Container:
+        type: "string"
+        description: "The ID or name of the container to connect to the network."
+        x-nullable: false
+        example: "3613f73ba0e4"
+      EndpointConfig:
+        $ref: "#/definitions/EndpointSettings"
+        x-nullable: true
+
+  NetworkDisconnectRequest:
+    description: |
+      NetworkDisconnectRequest represents the data to be used to disconnect a container from a network.
+    type: "object"
+    x-go-name: "DisconnectRequest"
+    required: ["Container"]
+    properties:
+      Container:
+        type: "string"
+        description: "The ID or name of the container to disconnect from the network."
+        x-nullable: false
+        example: "3613f73ba0e4"
+      Force:
+        type: "boolean"
+        description: "Force the container to disconnect from the network."
+        default: false
+        x-nullable: false
+        x-omitempty: false
+        example: false
+
+  EndpointSettings:
+    description: "Configuration for a network endpoint."
+    type: "object"
+    properties:
+      # Configurations
+      IPAMConfig:
+        $ref: "#/definitions/EndpointIPAMConfig"
+      Links:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "container_1"
+          - "container_2"
+      MacAddress:
+        description: |
+          MAC address for the endpoint on this network. The network driver might ignore this parameter.
+        type: "string"
+        example: "02:42:ac:11:00:04"
+        x-go-type:
+          type: HardwareAddr
+      Aliases:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "server_x"
+          - "server_y"
+      DriverOpts:
+        description: |
+          DriverOpts is a mapping of driver options and values. These options
+          are passed directly to the driver and are driver specific.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      GwPriority:
+        description: |
+          This property determines which endpoint will provide the default
+          gateway for a container. The endpoint with the highest priority will
+          be used. If multiple endpoints have the same priority, endpoints are
+          lexicographically sorted based on their network name, and the one
+          that sorts first is picked.
+        type: "integer"
+        format: "int64"
+        example:
+          - 10
+
+      # Operational data
+      NetworkID:
+        description: |
+          Unique ID of the network.
+        type: "string"
+        example: "08754567f1f40222263eab4102e1c733ae697e8e354aa9cd6e18d7402835292a"
+      EndpointID:
+        description: |
+          Unique ID for the service endpoint in a Sandbox.
+        type: "string"
+        example: "b88f5b905aabf2893f3cbc4ee42d1ea7980bbc0a92e2c8922b1e1795298afb0b"
+      Gateway:
+        description: |
+          Gateway address for this network.
+        type: "string"
+        example: "172.17.0.1"
+      IPAddress:
+        description: |
+          IPv4 address.
+        type: "string"
+        example: "172.17.0.4"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      IPPrefixLen:
+        description: |
+          Mask length of the IPv4 address.
+        type: "integer"
+        example: 16
+      IPv6Gateway:
+        description: |
+          IPv6 gateway address.
+        type: "string"
+        example: "2001:db8:2::100"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      GlobalIPv6Address:
+        description: |
+          Global IPv6 address.
+        type: "string"
+        example: "2001:db8::5689"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      GlobalIPv6PrefixLen:
+        description: |
+          Mask length of the global IPv6 address.
+        type: "integer"
+        format: "int64"
+        example: 64
+      DNSNames:
+        description: |
+          List of all DNS names an endpoint has on a specific network. This
+          list is based on the container name, network aliases, container short
+          ID, and hostname.
+
+          These DNS names are non-fully qualified but can contain several dots.
+          You can get fully qualified DNS names by appending `.<network-name>`.
+          For instance, if container name is `my.ctr` and the network is named
+          `testnet`, `DNSNames` will contain `my.ctr` and the FQDN will be
+          `my.ctr.testnet`.
+        type: array
+        items:
+          type: string
+        example: ["foobar", "server_x", "server_y", "my.ctr"]
+
+  EndpointIPAMConfig:
+    description: |
+      EndpointIPAMConfig represents an endpoint's IPAM configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      IPv4Address:
+        type: "string"
+        example: "172.20.30.33"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      IPv6Address:
+        type: "string"
+        example: "2001:db8:abcd::3033"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      LinkLocalIPs:
+        type: "array"
+        items:
+          type: "string"
+          x-go-type:
+            type: Addr
+            import:
+              package: net/netip
+        example:
+          - "169.254.34.68"
+          - "fe80::3468"
+
+  PluginMount:
+    type: "object"
+    x-go-name: "Mount"
+    x-nullable: false
+    required: [Name, Description, Settable, Source, Destination, Type, Options]
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "some-mount"
+      Description:
+        type: "string"
+        x-nullable: false
+        example: "This is a mount that's used by the plugin."
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Source:
+        type: "string"
+        example: "/var/lib/docker/plugins/"
+      Destination:
+        type: "string"
+        x-nullable: false
+        example: "/mnt/state"
+      Type:
+        type: "string"
+        x-nullable: false
+        example: "bind"
+      Options:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "rbind"
+          - "rw"
+
+  PluginDevice:
+    type: "object"
+    x-go-name: "Device"
+    required: [Name, Description, Settable, Path]
+    x-nullable: false
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+      Description:
+        type: "string"
+        x-nullable: false
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Path:
+        type: "string"
+        example: "/dev/fuse"
+
+  PluginEnv:
+    type: "object"
+    x-go-name: "Env"
+    x-nullable: false
+    required: [Name, Description, Settable, Value]
+    properties:
+      Name:
+        x-nullable: false
+        type: "string"
+      Description:
+        x-nullable: false
+        type: "string"
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Value:
+        type: "string"
+
+  PluginPrivilege:
+    description: |
+      Describes a permission the user has to accept upon installing
+      the plugin.
+    type: "object"
+    x-go-name: "Privilege"
+    properties:
+      Name:
+        type: "string"
+        example: "network"
+      Description:
+        type: "string"
+      Value:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "host"
+
+  Plugin:
+    description: "A plugin for the Engine API"
+    type: "object"
+    x-go-name: "Plugin"
+    required: [Settings, Enabled, Config, Name]
+    properties:
+      Id:
+        type: "string"
+        example: "5724e2c8652da337ab2eedd19fc6fc0ec908e4bd907c7421bf6a8dfc70c4c078"
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "tiborvass/sample-volume-plugin"
+      Enabled:
+        description:
+          True if the plugin is running. False if the plugin is not running,
+          only installed.
+        type: "boolean"
+        x-nullable: false
+        example: true
+      Settings:
+        description: "user-configurable settings for the plugin."
+        type: "object"
+        x-go-name: "Settings"
+        x-nullable: false
+        required: [Args, Devices, Env, Mounts]
+        properties:
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "DEBUG=0"
+          Args:
+            type: "array"
+            items:
+              type: "string"
+          Devices:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginDevice"
+      PluginReference:
+        description: "plugin remote reference used to push/pull the plugin"
+        type: "string"
+        x-go-name: "PluginReference"
+        x-nullable: false
+        example: "localhost:5000/tiborvass/sample-volume-plugin:latest"
+      Config:
+        description: "The config of a plugin."
+        type: "object"
+        x-go-name: "Config"
+        x-nullable: false
+        required:
+          - Description
+          - Documentation
+          - Interface
+          - Entrypoint
+          - WorkDir
+          - Network
+          - Linux
+          - PidHost
+          - PropagatedMount
+          - IpcHost
+          - Mounts
+          - Env
+          - Args
+        properties:
+          Description:
+            type: "string"
+            x-nullable: false
+            example: "A sample volume plugin for Docker"
+          Documentation:
+            type: "string"
+            x-nullable: false
+            example: "https://docs.docker.com/engine/extend/plugins/"
+          Interface:
+            description: "The interface between Docker and the plugin"
+            x-nullable: false
+            type: "object"
+            x-go-name: "Interface"
+            required: [Types, Socket]
+            properties:
+              Types:
+                type: "array"
+                items:
+                  type: "string"
+                  x-go-type:
+                    type: "CapabilityID"
+                example:
+                  - "docker.volumedriver/1.0"
+              Socket:
+                type: "string"
+                x-nullable: false
+                example: "plugins.sock"
+              ProtocolScheme:
+                type: "string"
+                example: "some.protocol/v1.0"
+                description: "Protocol to use for clients connecting to the plugin."
+                enum:
+                  - ""
+                  - "moby.plugins.http/v1"
+          Entrypoint:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "/usr/bin/sample-volume-plugin"
+              - "/data"
+          WorkDir:
+            type: "string"
+            x-nullable: false
+            example: "/bin/"
+          User:
+            type: "object"
+            x-go-name: "User"
+            x-nullable: false
+            properties:
+              UID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+              GID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+          Network:
+            type: "object"
+            x-go-name: "NetworkConfig"
+            x-nullable: false
+            required: [Type]
+            properties:
+              Type:
+                x-nullable: false
+                type: "string"
+                example: "host"
+          Linux:
+            type: "object"
+            x-go-name: "LinuxConfig"
+            x-nullable: false
+            required: [Capabilities, AllowAllDevices, Devices]
+            properties:
+              Capabilities:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "CAP_SYS_ADMIN"
+                  - "CAP_SYSLOG"
+              AllowAllDevices:
+                type: "boolean"
+                x-nullable: false
+                example: false
+              Devices:
+                type: "array"
+                items:
+                  $ref: "#/definitions/PluginDevice"
+          PropagatedMount:
+            type: "string"
+            x-nullable: false
+            example: "/mnt/volumes"
+          IpcHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          PidHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginEnv"
+            example:
+              - Name: "DEBUG"
+                Description: "If set, prints debug messages"
+                Settable: null
+                Value: "0"
+          Args:
+            type: "object"
+            x-go-name: "Args"
+            x-nullable: false
+            required: [Name, Description, Settable, Value]
+            properties:
+              Name:
+                x-nullable: false
+                type: "string"
+                example: "args"
+              Description:
+                x-nullable: false
+                type: "string"
+                example: "command line arguments"
+              Settable:
+                type: "array"
+                items:
+                  type: "string"
+              Value:
+                type: "array"
+                items:
+                  type: "string"
+          rootfs:
+            type: "object"
+            x-go-name: "RootFS"
+            properties:
+              type:
+                type: "string"
+                example: "layers"
+              diff_ids:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "sha256:675532206fbf3030b8458f88d6e26d4eb1577688a25efec97154c94e8b6b4887"
+                  - "sha256:e216a057b1cb1efc11f8a268f37ef62083e70b1b38323ba252e25ac88904a7e8"
+
+  ObjectVersion:
+    description: |
+      The version number of the object such as node, service, etc. This is needed
+      to avoid conflicting writes. The client must send the version number along
+      with the modified specification when updating these objects.
+
+      This approach ensures safe concurrency and determinism in that the change
+      on the object may not be applied if the version number has changed from the
+      last read. In other words, if two update requests specify the same base
+      version, only one of the requests can succeed. As a result, two separate
+      update requests that happen at the same time will not unintentionally
+      overwrite each other.
+    type: "object"
+    properties:
+      Index:
+        type: "integer"
+        format: "uint64"
+        example: 373531
+
+  NodeSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "Name for the node."
+        type: "string"
+        example: "my-node"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Role:
+        description: "Role of the node."
+        type: "string"
+        enum:
+          - "worker"
+          - "manager"
+        example: "manager"
+      Availability:
+        description: "Availability of the node."
+        type: "string"
+        enum:
+          - "active"
+          - "pause"
+          - "drain"
+        example: "active"
+    example:
+      Availability: "active"
+      Name: "node-name"
+      Role: "manager"
+      Labels:
+        foo: "bar"
+
+  Node:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "24ifsmvkjbyhk"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the node was added to the swarm in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the node was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/NodeSpec"
+      Description:
+        $ref: "#/definitions/NodeDescription"
+      Status:
+        $ref: "#/definitions/NodeStatus"
+      ManagerStatus:
+        $ref: "#/definitions/ManagerStatus"
+
+  NodeDescription:
+    description: |
+      NodeDescription encapsulates the properties of the Node as reported by the
+      agent.
+    type: "object"
+    properties:
+      Hostname:
+        type: "string"
+        example: "bf3067039e47"
+      Platform:
+        $ref: "#/definitions/Platform"
+      Resources:
+        $ref: "#/definitions/ResourceObject"
+      Engine:
+        $ref: "#/definitions/EngineDescription"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+
+  Platform:
+    description: |
+      Platform represents the platform (Arch/OS).
+    type: "object"
+    properties:
+      Architecture:
+        description: |
+          Architecture represents the hardware architecture (for example,
+          `x86_64`).
+        type: "string"
+        example: "x86_64"
+      OS:
+        description: |
+          OS represents the Operating System (for example, `linux` or `windows`).
+        type: "string"
+        example: "linux"
+
+  EngineDescription:
+    description: "EngineDescription provides information about an engine."
+    type: "object"
+    properties:
+      EngineVersion:
+        type: "string"
+        example: "17.06.0"
+      Labels:
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+      Plugins:
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Type:
+              type: "string"
+            Name:
+              type: "string"
+        example:
+          - Type: "Log"
+            Name: "awslogs"
+          - Type: "Log"
+            Name: "fluentd"
+          - Type: "Log"
+            Name: "gcplogs"
+          - Type: "Log"
+            Name: "gelf"
+          - Type: "Log"
+            Name: "journald"
+          - Type: "Log"
+            Name: "json-file"
+          - Type: "Log"
+            Name: "splunk"
+          - Type: "Log"
+            Name: "syslog"
+          - Type: "Network"
+            Name: "bridge"
+          - Type: "Network"
+            Name: "host"
+          - Type: "Network"
+            Name: "ipvlan"
+          - Type: "Network"
+            Name: "macvlan"
+          - Type: "Network"
+            Name: "null"
+          - Type: "Network"
+            Name: "overlay"
+          - Type: "Volume"
+            Name: "local"
+          - Type: "Volume"
+            Name: "localhost:5000/vieux/sshfs:latest"
+          - Type: "Volume"
+            Name: "vieux/sshfs:latest"
+
+  TLSInfo:
+    description: |
+      Information about the issuer of leaf TLS certificates and the trusted root
+      CA certificate.
+    type: "object"
+    properties:
+      TrustRoot:
+        description: |
+          The root CA certificate(s) that are used to validate leaf TLS
+          certificates.
+        type: "string"
+      CertIssuerSubject:
+        description:
+          The base64-url-safe-encoded raw subject bytes of the issuer.
+        type: "string"
+      CertIssuerPublicKey:
+        description: |
+          The base64-url-safe-encoded raw public key bytes of the issuer.
+        type: "string"
+    example:
+      TrustRoot: |
+        -----BEGIN CERTIFICATE-----
+        MIIBajCCARCgAwIBAgIUbYqrLSOSQHoxD8CwG6Bi2PJi9c8wCgYIKoZIzj0EAwIw
+        EzERMA8GA1UEAxMIc3dhcm0tY2EwHhcNMTcwNDI0MjE0MzAwWhcNMzcwNDE5MjE0
+        MzAwWjATMREwDwYDVQQDEwhzd2FybS1jYTBZMBMGByqGSM49AgEGCCqGSM49AwEH
+        A0IABJk/VyMPYdaqDXJb/VXh5n/1Yuv7iNrxV3Qb3l06XD46seovcDWs3IZNV1lf
+        3Skyr0ofcchipoiHkXBODojJydSjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB
+        Af8EBTADAQH/MB0GA1UdDgQWBBRUXxuRcnFjDfR/RIAUQab8ZV/n4jAKBggqhkjO
+        PQQDAgNIADBFAiAy+JTe6Uc3KyLCMiqGl2GyWGQqQDEcO3/YG36x7om65AIhAJvz
+        pxv6zFeVEkAEEkqIYi0omA9+CjanB/6Bz4n1uw8H
+        -----END CERTIFICATE-----
+      CertIssuerSubject: "MBMxETAPBgNVBAMTCHN3YXJtLWNh"
+      CertIssuerPublicKey: "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmT9XIw9h1qoNclv9VeHmf/Vi6/uI2vFXdBveXTpcPjqx6i9wNazchk1XWV/dKTKvSh9xyGKmiIeRcE4OiMnJ1A=="
+
+  NodeStatus:
+    description: |
+      NodeStatus represents the status of a node.
+
+      It provides the current status of the node, as seen by the manager.
+    type: "object"
+    properties:
+      State:
+        $ref: "#/definitions/NodeState"
+      Message:
+        type: "string"
+        example: ""
+      Addr:
+        description: "IP address of the node."
+        type: "string"
+        example: "172.17.0.2"
+
+  NodeState:
+    description: "NodeState represents the state of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "down"
+      - "ready"
+      - "disconnected"
+    example: "ready"
+
+  ManagerStatus:
+    description: |
+      ManagerStatus represents the status of a manager.
+
+      It provides the current status of a node's manager component, if the node
+      is a manager.
+    x-nullable: true
+    type: "object"
+    properties:
+      Leader:
+        type: "boolean"
+        default: false
+        example: true
+      Reachability:
+        $ref: "#/definitions/Reachability"
+      Addr:
+        description: |
+          The IP address and port at which the manager is reachable.
+        type: "string"
+        example: "10.0.0.46:2377"
+
+  Reachability:
+    description: "Reachability represents the reachability of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "unreachable"
+      - "reachable"
+    example: "reachable"
+
+  SwarmSpec:
+    description: "User modifiable swarm configuration."
+    type: "object"
+    properties:
+      Name:
+        description: "Name of the swarm."
+        type: "string"
+        example: "default"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.corp.type: "production"
+          com.example.corp.department: "engineering"
+      Orchestration:
+        description: "Orchestration configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          TaskHistoryRetentionLimit:
+            description: |
+              The number of historic tasks to keep per instance or node. If
+              negative, never remove completed or failed tasks.
+            type: "integer"
+            format: "int64"
+            example: 10
+      Raft:
+        description: "Raft configuration."
+        type: "object"
+        properties:
+          SnapshotInterval:
+            description: "The number of log entries between snapshots."
+            type: "integer"
+            format: "uint64"
+            example: 10000
+          KeepOldSnapshots:
+            description: |
+              The number of snapshots to keep beyond the current snapshot.
+            type: "integer"
+            format: "uint64"
+          LogEntriesForSlowFollowers:
+            description: |
+              The number of log entries to keep around to sync up slow followers
+              after a snapshot is created.
+            type: "integer"
+            format: "uint64"
+            example: 500
+          ElectionTick:
+            description: |
+              The number of ticks that a follower will wait for a message from
+              the leader before becoming a candidate and starting an election.
+              `ElectionTick` must be greater than `HeartbeatTick`.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 3
+          HeartbeatTick:
+            description: |
+              The number of ticks between heartbeats. Every HeartbeatTick ticks,
+              the leader will send a heartbeat to the followers.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 1
+      Dispatcher:
+        description: "Dispatcher configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          HeartbeatPeriod:
+            description: |
+              The delay for an agent to send a heartbeat to the dispatcher.
+            type: "integer"
+            format: "int64"
+            example: 5000000000
+      CAConfig:
+        description: "CA configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          NodeCertExpiry:
+            description: "The duration node certificates are issued for."
+            type: "integer"
+            format: "int64"
+            example: 7776000000000000
+          ExternalCAs:
+            description: |
+              Configuration for forwarding signing requests to an external
+              certificate authority.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Protocol:
+                  description: |
+                    Protocol for communication with the external CA (currently
+                    only `cfssl` is supported).
+                  type: "string"
+                  enum:
+                    - "cfssl"
+                  default: "cfssl"
+                URL:
+                  description: |
+                    URL where certificate signing requests should be sent.
+                  type: "string"
+                Options:
+                  description: |
+                    An object with key/value pairs that are interpreted as
+                    protocol-specific options for the external CA driver.
+                  type: "object"
+                  additionalProperties:
+                    type: "string"
+                CACert:
+                  description: |
+                    The root CA certificate (in PEM format) this external CA uses
+                    to issue TLS certificates (assumed to be to the current swarm
+                    root CA certificate if not provided).
+                  type: "string"
+          SigningCACert:
+            description: |
+              The desired signing CA certificate for all swarm node TLS leaf
+              certificates, in PEM format.
+            type: "string"
+          SigningCAKey:
+            description: |
+              The desired signing CA key for all swarm node TLS leaf certificates,
+              in PEM format.
+            type: "string"
+          ForceRotate:
+            description: |
+              An integer whose purpose is to force swarm to generate a new
+              signing CA certificate and key, if none have been specified in
+              `SigningCACert` and `SigningCAKey`
+            format: "uint64"
+            type: "integer"
+      EncryptionConfig:
+        description: "Parameters related to encryption-at-rest."
+        type: "object"
+        properties:
+          AutoLockManagers:
+            description: |
+              If set, generate a key and use it to lock data stored on the
+              managers.
+            type: "boolean"
+            example: false
+      TaskDefaults:
+        description: "Defaults for creating tasks in this cluster."
+        type: "object"
+        properties:
+          LogDriver:
+            description: |
+              The log driver to use for tasks created in the orchestrator if
+              unspecified by a service.
+
+              Updating this value only affects new tasks. Existing tasks continue
+              to use their previously configured log driver until recreated.
+            type: "object"
+            properties:
+              Name:
+                description: |
+                  The log driver to use as a default for new tasks.
+                type: "string"
+                example: "json-file"
+              Options:
+                description: |
+                  Driver-specific options for the selected log driver, specified
+                  as key/value pairs.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "10"
+                  "max-size": "100m"
+
+  # The Swarm information for `GET /info`. It is the same as `GET /swarm`, but
+  # without `JoinTokens`.
+  ClusterInfo:
+    description: |
+      ClusterInfo represents information about the swarm as is returned by the
+      "/info" endpoint. Join-tokens are not included.
+    x-nullable: true
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the swarm."
+        type: "string"
+        example: "abajmipo7b4xz5ip2nrla6b11"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the swarm was initialised in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the swarm was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/SwarmSpec"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+      RootRotationInProgress:
+        description: |
+          Whether there is currently a root CA rotation in progress for the swarm
+        type: "boolean"
+        example: false
+      DataPathPort:
+        description: |
+          DataPathPort specifies the data path port number for data traffic.
+          Acceptable port range is 1024 to 49151.
+          If no port is set or is set to 0, the default port (4789) is used.
+        type: "integer"
+        format: "uint32"
+        default: 4789
+        example: 4789
+      DefaultAddrPool:
+        description: |
+          Default Address Pool specifies default subnet pools for global scope
+          networks.
+        type: "array"
+        items:
+          type: "string"
+          format: "CIDR"
+          example: ["10.10.0.0/16", "20.20.0.0/16"]
+      SubnetSize:
+        description: |
+          SubnetSize specifies the subnet size of the networks created from the
+          default subnet pool.
+        type: "integer"
+        format: "uint32"
+        maximum: 29
+        default: 24
+        example: 24
+
+  JoinTokens:
+    description: |
+      JoinTokens contains the tokens workers and managers need to join the swarm.
+    type: "object"
+    properties:
+      Worker:
+        description: |
+          The token workers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx"
+      Manager:
+        description: |
+          The token managers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+
+  Swarm:
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/ClusterInfo"
+      - type: "object"
+        properties:
+          JoinTokens:
+            $ref: "#/definitions/JoinTokens"
+
+  TaskSpec:
+    description: "User modifiable task configuration."
+    type: "object"
+    properties:
+      PluginSpec:
+        type: "object"
+        description: |
+          Plugin spec for the service.  *(Experimental release only.)*
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Name:
+            description: "The name or 'alias' to use for the plugin."
+            type: "string"
+          Remote:
+            description: "The plugin image reference to use."
+            type: "string"
+          Disabled:
+            description: "Disable the plugin once scheduled."
+            type: "boolean"
+          PluginPrivilege:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+      ContainerSpec:
+        type: "object"
+        description: |
+          Container spec for the service.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Image:
+            description: "The image name to use for the container"
+            type: "string"
+          Labels:
+            description: "User-defined key/value data."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          Command:
+            description: "The command to be run in the image."
+            type: "array"
+            items:
+              type: "string"
+          Args:
+            description: "Arguments to the command."
+            type: "array"
+            items:
+              type: "string"
+          Hostname:
+            description: |
+              The hostname to use for the container, as a valid
+              [RFC 1123](https://tools.ietf.org/html/rfc1123) hostname.
+            type: "string"
+          Env:
+            description: |
+              A list of environment variables in the form `VAR=value`.
+            type: "array"
+            items:
+              type: "string"
+          Dir:
+            description: "The working directory for commands to run in."
+            type: "string"
+          User:
+            description: "The user inside the container."
+            type: "string"
+          Groups:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          Privileges:
+            type: "object"
+            description: "Security options for the container"
+            properties:
+              CredentialSpec:
+                type: "object"
+                description: "CredentialSpec for managed service account (Windows only)"
+                properties:
+                  Config:
+                    type: "string"
+                    example: "0bt9dmxjvjiqermk6xrop3ekq"
+                    description: |
+                      Load credential spec from a Swarm Config with the given ID.
+                      The specified config must also be present in the Configs
+                      field with the Runtime property set.
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  File:
+                    type: "string"
+                    example: "spec.json"
+                    description: |
+                      Load credential spec from this file. The file is read by
+                      the daemon, and must be present in the `CredentialSpecs`
+                      subdirectory in the docker data directory, which defaults
+                      to `C:\ProgramData\Docker\` on Windows.
+
+                      For example, specifying `spec.json` loads
+                      `C:\ProgramData\Docker\CredentialSpecs\spec.json`.
+
+                      <p><br /></p>
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  Registry:
+                    type: "string"
+                    description: |
+                      Load credential spec from this value in the Windows
+                      registry. The specified registry value must be located in:
+
+                      `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs`
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+              SELinuxContext:
+                type: "object"
+                description: "SELinux labels of the container"
+                properties:
+                  Disable:
+                    type: "boolean"
+                    description: "Disable SELinux"
+                  User:
+                    type: "string"
+                    description: "SELinux user label"
+                  Role:
+                    type: "string"
+                    description: "SELinux role label"
+                  Type:
+                    type: "string"
+                    description: "SELinux type label"
+                  Level:
+                    type: "string"
+                    description: "SELinux level label"
+              Seccomp:
+                type: "object"
+                description: "Options for configuring seccomp on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "unconfined"
+                      - "custom"
+                  Profile:
+                    description: "The custom seccomp profile as a json object"
+                    type: "string"
+              AppArmor:
+                type: "object"
+                description: "Options for configuring AppArmor on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "disabled"
+              NoNewPrivileges:
+                type: "boolean"
+                description: "Configuration of the no_new_privs bit in the container"
+
+          TTY:
+            description: "Whether a pseudo-TTY should be allocated."
+            type: "boolean"
+          OpenStdin:
+            description: "Open `stdin`"
+            type: "boolean"
+          ReadOnly:
+            description: "Mount the container's root filesystem as read only."
+            type: "boolean"
+          Mounts:
+            description: |
+              Specification for mounts to be added to containers created as part
+              of the service.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          StopSignal:
+            description: "Signal to stop the container."
+            type: "string"
+          StopGracePeriod:
+            description: |
+              Amount of time to wait for the container to terminate before
+              forcefully killing it.
+            type: "integer"
+            format: "int64"
+          HealthCheck:
+            $ref: "#/definitions/HealthConfig"
+          Hosts:
+            type: "array"
+            description: |
+              A list of hostname/IP mappings to add to the container's `hosts`
+              file. The format of extra hosts is specified in the
+              [hosts(5)](http://man7.org/linux/man-pages/man5/hosts.5.html)
+              man page:
+
+                  IP_address canonical_hostname [aliases...]
+            items:
+              type: "string"
+          DNSConfig:
+            description: |
+              Specification for DNS related configurations in resolver configuration
+              file (`resolv.conf`).
+            type: "object"
+            properties:
+              Nameservers:
+                description: "The IP addresses of the name servers."
+                type: "array"
+                items:
+                  type: "string"
+              Search:
+                description: "A search list for host-name lookup."
+                type: "array"
+                items:
+                  type: "string"
+              Options:
+                description: |
+                  A list of internal resolver variables to be modified (e.g.,
+                  `debug`, `ndots:3`, etc.).
+                type: "array"
+                items:
+                  type: "string"
+          Secrets:
+            description: |
+              Secrets contains references to zero or more secrets that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                SecretID:
+                  description: |
+                    SecretID represents the ID of the specific secret that we're
+                    referencing.
+                  type: "string"
+                SecretName:
+                  description: |
+                    SecretName is the name of the secret that this references,
+                    but this is just provided for lookup/display purposes. The
+                    secret in the reference will be identified by its ID.
+                  type: "string"
+          OomScoreAdj:
+            type: "integer"
+            format: "int64"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 0
+          Configs:
+            description: |
+              Configs contains references to zero or more configs that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually exclusive
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                Runtime:
+                  description: |
+                    Runtime represents a target that is not mounted into the
+                    container but is used by the task
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually
+                    > exclusive
+                  type: "object"
+                ConfigID:
+                  description: |
+                    ConfigID represents the ID of the specific config that we're
+                    referencing.
+                  type: "string"
+                ConfigName:
+                  description: |
+                    ConfigName is the name of the config that this references,
+                    but this is just provided for lookup/display purposes. The
+                    config in the reference will be identified by its ID.
+                  type: "string"
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the containers running the service.
+              (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          Init:
+            description: |
+              Run an init inside the container that forwards signals and reaps
+              processes. This field is omitted if empty, and the default (as
+              configured on the daemon) is used.
+            type: "boolean"
+            x-nullable: true
+          Sysctls:
+            description: |
+              Set kernel namedspaced parameters (sysctls) in the container.
+              The Sysctls option on services accepts the same sysctls as the
+              are supported on containers. Note that while the same sysctls are
+              supported, no guarantees or checks are made about their
+              suitability for a clustered environment, and it's up to the user
+              to determine whether a given sysctl will work properly in a
+              Service.
+            type: "object"
+            additionalProperties:
+              type: "string"
+          # This option is not used by Windows containers
+          CapabilityAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+              - "CAP_SYS_ADMIN"
+              - "CAP_SYS_CHROOT"
+              - "CAP_SYSLOG"
+          CapabilityDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+          Ulimits:
+            description: |
+              A list of resource limits to set in the container. For example: `{"Name": "nofile", "Soft": 1024, "Hard": 2048}`"
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Name:
+                  description: "Name of ulimit"
+                  type: "string"
+                Soft:
+                  description: "Soft limit"
+                  type: "integer"
+                Hard:
+                  description: "Hard limit"
+                  type: "integer"
+      NetworkAttachmentSpec:
+        description: |
+          Read-only spec type for non-swarm containers attached to swarm overlay
+          networks.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        type: "object"
+        properties:
+          ContainerID:
+            description: "ID of the container represented by this task"
+            type: "string"
+      Resources:
+        description: |
+          Resource requirements which apply to each individual container created
+          as part of the service.
+        type: "object"
+        properties:
+          Limits:
+            description: "Define resources limits."
+            $ref: "#/definitions/Limit"
+          Reservations:
+            description: "Define resources reservation."
+            $ref: "#/definitions/ResourceObject"
+          SwapBytes:
+            description: |
+              Amount of swap in bytes - can only be used together with a memory limit.
+              If not specified, the default behaviour is to grant a swap space twice
+              as big as the memory limit.
+              Set to -1 to enable unlimited swap.
+            type: "integer"
+            format: "int64"
+            minimum: -1
+            x-nullable: true
+            x-omitempty: true
+          MemorySwappiness:
+            description: |
+              Tune the service's containers' memory swappiness (0 to 100).
+              If not specified, defaults to the containers' OS' default, generally 60,
+              or whatever value was predefined in the image.
+              Set to -1 to unset a previously set value.
+            type: "integer"
+            format: "int64"
+            minimum: -1
+            maximum: 100
+            x-nullable: true
+            x-omitempty: true
+      RestartPolicy:
+        description: |
+          Specification for the restart policy which applies to containers
+          created as part of this service.
+        type: "object"
+        properties:
+          Condition:
+            description: "Condition for restart."
+            type: "string"
+            enum:
+              - "none"
+              - "on-failure"
+              - "any"
+          Delay:
+            description: "Delay between restart attempts."
+            type: "integer"
+            format: "int64"
+          MaxAttempts:
+            description: |
+              Maximum attempts to restart a given container before giving up
+              (default value is 0, which is ignored).
+            type: "integer"
+            format: "int64"
+            default: 0
+          Window:
+            description: |
+              Windows is the time window used to evaluate the restart policy
+              (default value is 0, which is unbounded).
+            type: "integer"
+            format: "int64"
+            default: 0
+      Placement:
+        type: "object"
+        properties:
+          Constraints:
+            description: |
+              An array of constraint expressions to limit the set of nodes where
+              a task can be scheduled. Constraint expressions can either use a
+              _match_ (`==`) or _exclude_ (`!=`) rule. Multiple constraints find
+              nodes that satisfy every expression (AND match). Constraints can
+              match node or Docker Engine labels as follows:
+
+              node attribute       | matches                        | example
+              ---------------------|--------------------------------|-----------------------------------------------
+              `node.id`            | Node ID                        | `node.id==2ivku8v2gvtg4`
+              `node.hostname`      | Node hostname                  | `node.hostname!=node-2`
+              `node.role`          | Node role (`manager`/`worker`) | `node.role==manager`
+              `node.platform.os`   | Node operating system          | `node.platform.os==windows`
+              `node.platform.arch` | Node architecture              | `node.platform.arch==x86_64`
+              `node.labels`        | User-defined node labels       | `node.labels.security==high`
+              `engine.labels`      | Docker Engine's labels         | `engine.labels.operatingsystem==ubuntu-24.04`
+
+              `engine.labels` apply to Docker Engine labels like operating system,
+              drivers, etc. Swarm administrators add `node.labels` for operational
+              purposes by using the [`node update endpoint`](#operation/NodeUpdate).
+
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "node.hostname!=node3.corp.example.com"
+              - "node.role!=manager"
+              - "node.labels.type==production"
+              - "node.platform.os==linux"
+              - "node.platform.arch==x86_64"
+          Preferences:
+            description: |
+              Preferences provide a way to make the scheduler aware of factors
+              such as topology. They are provided in order from highest to
+              lowest precedence.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Spread:
+                  type: "object"
+                  properties:
+                    SpreadDescriptor:
+                      description: |
+                        label descriptor, such as `engine.labels.az`.
+                      type: "string"
+            example:
+              - Spread:
+                  SpreadDescriptor: "node.labels.datacenter"
+              - Spread:
+                  SpreadDescriptor: "node.labels.rack"
+          MaxReplicas:
+            description: |
+              Maximum number of replicas for per node (default value is 0, which
+              is unlimited)
+            type: "integer"
+            format: "int64"
+            default: 0
+          Platforms:
+            description: |
+              Platforms stores all the platforms that the service's image can
+              run on. This field is used in the platform filter for scheduling.
+              If empty, then the platform filter is off, meaning there are no
+              scheduling restrictions.
+            type: "array"
+            items:
+              $ref: "#/definitions/Platform"
+      ForceUpdate:
+        description: |
+          A counter that triggers an update even if no relevant parameters have
+          been changed.
+        type: "integer"
+        format: "uint64"
+      Runtime:
+        description: |
+          Runtime is the type of runtime specified for the task executor.
+        type: "string"
+      Networks:
+        description: "Specifies which networks the service should attach to."
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+      LogDriver:
+        description: |
+          Specifies the log driver to use for tasks created from this spec. If
+          not present, the default one for the swarm will be used, finally
+          falling back to the engine default if not specified.
+        type: "object"
+        properties:
+          Name:
+            type: "string"
+          Options:
+            type: "object"
+            additionalProperties:
+              type: "string"
+
+  TaskState:
+    type: "string"
+    enum:
+      - "new"
+      - "allocated"
+      - "pending"
+      - "assigned"
+      - "accepted"
+      - "preparing"
+      - "ready"
+      - "starting"
+      - "running"
+      - "complete"
+      - "shutdown"
+      - "failed"
+      - "rejected"
+      - "remove"
+      - "orphaned"
+
+  ContainerStatus:
+    type: "object"
+    description: "represents the status of a container."
+    properties:
+      ContainerID:
+        type: "string"
+      PID:
+        type: "integer"
+      ExitCode:
+        type: "integer"
+
+  PortStatus:
+    type: "object"
+    description: "represents the port status of a task's host ports whose service has published host ports"
+    properties:
+      Ports:
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  TaskStatus:
+    type: "object"
+    description: "represents the status of a task."
+    properties:
+      Timestamp:
+        type: "string"
+        format: "dateTime"
+      State:
+        $ref: "#/definitions/TaskState"
+      Message:
+        type: "string"
+      Err:
+        type: "string"
+      ContainerStatus:
+        $ref: "#/definitions/ContainerStatus"
+      PortStatus:
+        $ref: "#/definitions/PortStatus"
+
+  Task:
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the task."
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Name:
+        description: "Name of the task."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Spec:
+        $ref: "#/definitions/TaskSpec"
+      ServiceID:
+        description: "The ID of the service this task is part of."
+        type: "string"
+      Slot:
+        type: "integer"
+      NodeID:
+        description: "The ID of the node that this task is on."
+        type: "string"
+      AssignedGenericResources:
+        $ref: "#/definitions/GenericResources"
+      Status:
+        $ref: "#/definitions/TaskStatus"
+      DesiredState:
+        $ref: "#/definitions/TaskState"
+      JobIteration:
+        description: |
+          If the Service this Task belongs to is a job-mode service, contains
+          the JobIteration of the Service this Task was created for. Absent if
+          the Task was created for a Replicated or Global Service.
+        $ref: "#/definitions/ObjectVersion"
+    example:
+      ID: "0kzzo1i0y4jz6027t0k7aezc7"
+      Version:
+        Index: 71
+      CreatedAt: "2016-06-07T21:07:31.171892745Z"
+      UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+      Spec:
+        ContainerSpec:
+          Image: "redis"
+        Resources:
+          Limits: {}
+          Reservations: {}
+        RestartPolicy:
+          Condition: "any"
+          MaxAttempts: 0
+        Placement: {}
+      ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Slot: 1
+      NodeID: "60gvrl6tm78dmak4yl7srz94v"
+      Status:
+        Timestamp: "2016-06-07T21:07:31.290032978Z"
+        State: "running"
+        Message: "started"
+        ContainerStatus:
+          ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+          PID: 677
+      DesiredState: "running"
+      NetworksAttachments:
+        - Network:
+            ID: "4qvuz4ko70xaltuqbt8956gd1"
+            Version:
+              Index: 18
+            CreatedAt: "2016-06-07T20:31:11.912919752Z"
+            UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+            Spec:
+              Name: "ingress"
+              Labels:
+                com.docker.swarm.internal: "true"
+              DriverConfiguration: {}
+              IPAMOptions:
+                Driver: {}
+                Configs:
+                  - Subnet: "10.255.0.0/16"
+                    Gateway: "10.255.0.1"
+            DriverState:
+              Name: "overlay"
+              Options:
+                com.docker.network.driver.overlay.vxlanid_list: "256"
+            IPAMOptions:
+              Driver:
+                Name: "default"
+              Configs:
+                - Subnet: "10.255.0.0/16"
+                  Gateway: "10.255.0.1"
+          Addresses:
+            - "10.255.0.10/16"
+      AssignedGenericResources:
+        - DiscreteResourceSpec:
+            Kind: "SSD"
+            Value: 3
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID1"
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID2"
+
+  ServiceSpec:
+    description: "User modifiable configuration for a service."
+    type: object
+    properties:
+      Name:
+        description: "Name of the service."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      TaskTemplate:
+        $ref: "#/definitions/TaskSpec"
+      Mode:
+        description: "Scheduling mode for the service."
+        type: "object"
+        properties:
+          Replicated:
+            type: "object"
+            properties:
+              Replicas:
+                type: "integer"
+                format: "int64"
+          Global:
+            type: "object"
+          ReplicatedJob:
+            description: |
+              The mode used for services with a finite number of tasks that run
+              to a completed state.
+            type: "object"
+            properties:
+              MaxConcurrent:
+                description: |
+                  The maximum number of replicas to run simultaneously.
+                type: "integer"
+                format: "int64"
+                default: 1
+              TotalCompletions:
+                description: |
+                  The total number of replicas desired to reach the Completed
+                  state. If unset, will default to the value of `MaxConcurrent`
+                type: "integer"
+                format: "int64"
+          GlobalJob:
+            description: |
+              The mode used for services which run a task to the completed state
+              on each valid node.
+            type: "object"
+      UpdateConfig:
+        description: "Specification for the update strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be updated in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: "Amount of time between updates, in nanoseconds."
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an updated task fails to run, or stops running
+              during the update.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+              - "rollback"
+          Monitor:
+            description: |
+              Amount of time to monitor each updated task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during an update before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling out an updated task. Either
+              the old task is shut down before the new task is started, or the
+              new task is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      RollbackConfig:
+        description: "Specification for the rollback strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be rolled back in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: |
+              Amount of time between rollback iterations, in nanoseconds.
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an rolled back task fails to run, or stops
+              running during the rollback.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+          Monitor:
+            description: |
+              Amount of time to monitor each rolled back task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during a rollback before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling back a task. Either the old
+              task is shut down before the new task is started, or the new task
+              is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      Networks:
+        description: |
+          Specifies which networks the service should attach to.
+
+          Deprecated: This field is deprecated since v1.44. The Networks field in TaskSpec should be used instead.
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+
+      EndpointSpec:
+        $ref: "#/definitions/EndpointSpec"
+
+  EndpointPortConfig:
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+      Protocol:
+        type: "string"
+        enum:
+          - "tcp"
+          - "udp"
+          - "sctp"
+      TargetPort:
+        description: "The port inside the container."
+        type: "integer"
+      PublishedPort:
+        description: "The port on the swarm hosts."
+        type: "integer"
+      PublishMode:
+        description: |
+          The mode in which port is published.
+
+          <p><br /></p>
+
+          - "ingress" makes the target port accessible on every node,
+            regardless of whether there is a task for the service running on
+            that node or not.
+          - "host" bypasses the routing mesh and publish the port directly on
+            the swarm node where that service is running.
+
+        type: "string"
+        enum:
+          - "ingress"
+          - "host"
+        default: "ingress"
+        example: "ingress"
+
+  EndpointSpec:
+    description: "Properties that can be configured to access and load balance a service."
+    type: "object"
+    properties:
+      Mode:
+        description: |
+          The mode of resolution to use for internal load balancing between tasks.
+        type: "string"
+        enum:
+          - "vip"
+          - "dnsrr"
+        default: "vip"
+      Ports:
+        description: |
+          List of exposed ports that this service is accessible on from the
+          outside. Ports can only be provided if `vip` resolution mode is used.
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  Service:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ServiceSpec"
+      Endpoint:
+        type: "object"
+        properties:
+          Spec:
+            $ref: "#/definitions/EndpointSpec"
+          Ports:
+            type: "array"
+            items:
+              $ref: "#/definitions/EndpointPortConfig"
+          VirtualIPs:
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                NetworkID:
+                  type: "string"
+                Addr:
+                  type: "string"
+      UpdateStatus:
+        description: "The status of a service update."
+        type: "object"
+        properties:
+          State:
+            type: "string"
+            enum:
+              - "updating"
+              - "paused"
+              - "completed"
+          StartedAt:
+            type: "string"
+            format: "dateTime"
+          CompletedAt:
+            type: "string"
+            format: "dateTime"
+          Message:
+            type: "string"
+      ServiceStatus:
+        description: |
+          The status of the service's tasks. Provided only when requested as
+          part of a ServiceList operation.
+        type: "object"
+        properties:
+          RunningTasks:
+            description: |
+              The number of tasks for the service currently in the Running state.
+            type: "integer"
+            format: "uint64"
+            example: 7
+          DesiredTasks:
+            description: |
+              The number of tasks for the service desired to be running.
+              For replicated services, this is the replica count from the
+              service spec. For global services, this is computed by taking
+              count of all tasks for the service with a Desired State other
+              than Shutdown.
+            type: "integer"
+            format: "uint64"
+            example: 10
+          CompletedTasks:
+            description: |
+              The number of tasks for a job that are in the Completed state.
+              This field must be cross-referenced with the service type, as the
+              value of 0 may mean the service is not in a job mode, or it may
+              mean the job-mode service has no tasks yet Completed.
+            type: "integer"
+            format: "uint64"
+      JobStatus:
+        description: |
+          The status of the service when it is in one of ReplicatedJob or
+          GlobalJob modes. Absent on Replicated and Global mode services. The
+          JobIteration is an ObjectVersion, but unlike the Service's version,
+          does not need to be sent with an update request.
+        type: "object"
+        properties:
+          JobIteration:
+            description: |
+              JobIteration is a value increased each time a Job is executed,
+              successfully or otherwise. "Executed", in this case, means the
+              job as a whole has been started, not that an individual Task has
+              been launched. A job is "Executed" when its ServiceSpec is
+              updated. JobIteration can be used to disambiguate Tasks belonging
+              to different executions of a job.  Though JobIteration will
+              increase with each subsequent execution, it may not necessarily
+              increase by 1, and so JobIteration should not be used to
+            $ref: "#/definitions/ObjectVersion"
+          LastExecution:
+            description: |
+              The last time, as observed by the server, that this job was
+              started.
+            type: "string"
+            format: "dateTime"
+    example:
+      ID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Version:
+        Index: 19
+      CreatedAt: "2016-06-07T21:05:51.880065305Z"
+      UpdatedAt: "2016-06-07T21:07:29.962229872Z"
+      Spec:
+        Name: "hopeful_cori"
+        TaskTemplate:
+          ContainerSpec:
+            Image: "redis"
+          Resources:
+            Limits: {}
+            Reservations: {}
+          RestartPolicy:
+            Condition: "any"
+            MaxAttempts: 0
+          Placement: {}
+          ForceUpdate: 0
+        Mode:
+          Replicated:
+            Replicas: 1
+        UpdateConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        RollbackConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        EndpointSpec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+      Endpoint:
+        Spec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+        Ports:
+          -
+            Protocol: "tcp"
+            TargetPort: 6379
+            PublishedPort: 30001
+        VirtualIPs:
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.2/16"
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.3/16"
+
+  ImageDeleteResponseItem:
+    type: "object"
+    x-go-name: "DeleteResponse"
+    properties:
+      Untagged:
+        description: "The image ID of an image that was untagged"
+        type: "string"
+      Deleted:
+        description: "The image ID of an image that was deleted"
+        type: "string"
+
+  ServiceCreateResponse:
+    type: "object"
+    description: |
+      contains the information returned to a client on the
+      creation of a new service.
+    properties:
+      ID:
+        description: "The ID of the created service."
+        type: "string"
+        x-nullable: false
+        example: "ak7w3gjqoa3kuz8xcpnyy0pvl"
+      Warnings:
+        description: |
+          Optional warning message.
+
+          FIXME(thaJeztah): this should have "omitempty" in the generated type.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example:
+          - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ServiceUpdateResponse:
+    type: "object"
+    properties:
+      Warnings:
+        description: "Optional warning messages"
+        type: "array"
+        items:
+          type: "string"
+    example:
+      Warnings:
+        - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ContainerInspectResponse:
+    type: "object"
+    title: "ContainerInspectResponse"
+    x-go-name: "InspectResponse"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Created:
+        description: |-
+          Date and time at which the container was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2025-02-17T17:43:39.64001363Z"
+      Path:
+        description: |-
+          The path to the command being run
+        type: "string"
+        example: "/bin/sh"
+      Args:
+        description: "The arguments to the command being run"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "-c"
+          - "exit 9"
+      State:
+        $ref: "#/definitions/ContainerState"
+      Image:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ResolvConfPath:
+        description: |-
+          Location of the `/etc/resolv.conf` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/resolv.conf"
+      HostnamePath:
+        description: |-
+          Location of the `/etc/hostname` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hostname"
+      HostsPath:
+        description: |-
+          Location of the `/etc/hosts` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hosts"
+      LogPath:
+        description: |-
+          Location of the file used to buffer the container's logs. Depending on
+          the logging-driver used for the container, this field may be omitted.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        x-nullable: true
+        example: "/var/lib/docker/containers/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59-json.log"
+      Name:
+        description: |-
+          The name associated with this container.
+
+          For historic reasons, the name may be prefixed with a forward-slash (`/`).
+        type: "string"
+        example: "/funny_chatelet"
+      RestartCount:
+        description: |-
+          Number of times the container was restarted since it was created,
+          or since daemon was started.
+        type: "integer"
+        example: 0
+      Driver:
+        description: |-
+          The storage-driver used for the container's filesystem (graph-driver
+          or snapshotter).
+        type: "string"
+        example: "overlayfs"
+      Platform:
+        description: |-
+          The platform (operating system) for which the container was created.
+
+          This field was introduced for the experimental "LCOW" (Linux Containers
+          On Windows) features, which has been removed. In most cases, this field
+          is equal to the host's operating system (`linux` or `windows`).
+        type: "string"
+        example: "linux"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        description: |-
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+      MountLabel:
+        description: |-
+          SELinux mount label set for the container.
+        type: "string"
+        example: ""
+      ProcessLabel:
+        description: |-
+          SELinux process label set for the container.
+        type: "string"
+        example: ""
+      AppArmorProfile:
+        description: |-
+          The AppArmor profile set for the container.
+        type: "string"
+        example: ""
+      ExecIDs:
+        description: |-
+          IDs of exec instances that are running in the container.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example:
+          - "b35395de42bc8abd327f9dd65d913b9ba28c74d2f0734eeeae84fa1c616a0fca"
+          - "3fc1232e5cd20c8de182ed81178503dc6437f4e7ef12b52cc5e8de020652f1c4"
+      HostConfig:
+        $ref: "#/definitions/HostConfig"
+      GraphDriver:
+        $ref: "#/definitions/DriverData"
+        x-nullable: true
+      Storage:
+        $ref: "#/definitions/Storage"
+        x-nullable: true
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Mounts:
+        description: |-
+          List of mounts used by the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/MountPoint"
+      Config:
+        $ref: "#/definitions/ContainerConfig"
+      NetworkSettings:
+        $ref: "#/definitions/NetworkSettings"
+
+  ContainerSummary:
+    type: "object"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Names:
+        description: |-
+          The names associated with this container. Most containers have a single
+          name, but when using legacy "links", the container can have multiple
+          names.
+
+          For historic reasons, names are prefixed with a forward-slash (`/`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/funny_chatelet"
+      Image:
+        description: |-
+          The name or ID of the image used to create the container.
+
+          This field shows the image reference as was specified when creating the container,
+          which can be in its canonical form (e.g., `docker.io/library/ubuntu:latest`
+          or `docker.io/library/ubuntu@sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`),
+          short form (e.g., `ubuntu:latest`)), or the ID(-prefix) of the image (e.g., `72297848456d`).
+
+          The content of this field can be updated at runtime if the image used to
+          create the container is untagged, in which case the field is updated to
+          contain the the image ID (digest) it was resolved to in its canonical,
+          non-truncated form (e.g., `sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`).
+        type: "string"
+        example: "docker.io/library/ubuntu:latest"
+      ImageID:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        x-nullable: true
+        description: |
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+
+          This field is not populated in the `GET /system/df` endpoint.
+      Command:
+        description: "Command to run when starting the container"
+        type: "string"
+        example: "/bin/bash"
+      Created:
+        description: |-
+          Date and time at which the container was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        format: "int64"
+        example: "1739811096"
+      Ports:
+        description: |-
+          Port-mappings for the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/PortSummary"
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.vendor: "Acme"
+          com.example.license: "GPL"
+          com.example.version: "1.0"
+      State:
+        description: |
+          The state of this container.
+        type: "string"
+        enum:
+          - "created"
+          - "running"
+          - "paused"
+          - "restarting"
+          - "exited"
+          - "removing"
+          - "dead"
+        example: "running"
+      Status:
+        description: |-
+          Additional human-readable status of this container (e.g. `Exit 0`)
+        type: "string"
+        example: "Up 4 days"
+      HostConfig:
+        type: "object"
+        description: |-
+          Summary of host-specific runtime information of the container. This
+          is a reduced set of information in the container's "HostConfig" as
+          available in the container "inspect" response.
+        properties:
+          NetworkMode:
+            description: |-
+              Networking mode (`host`, `none`, `container:<id>`) or name of the
+              primary network the container is using.
+
+              This field is primarily for backward compatibility. The container
+              can be connected to multiple networks for which information can be
+              found in the `NetworkSettings.Networks` field, which enumerates
+              settings per network.
+            type: "string"
+            example: "mynetwork"
+          Annotations:
+            description: |-
+              Arbitrary key-value metadata attached to the container.
+            type: "object"
+            x-nullable: true
+            additionalProperties:
+              type: "string"
+            example:
+              io.kubernetes.docker.type: "container"
+              io.kubernetes.sandbox.id: "3befe639bed0fd6afdd65fd1fa84506756f59360ec4adc270b0fdac9be22b4d3"
+      NetworkSettings:
+        description: |-
+          Summary of the container's network settings
+        type: "object"
+        properties:
+          Networks:
+            type: "object"
+            description: |-
+              Summary of network-settings for each network the container is
+              attached to.
+            additionalProperties:
+              $ref: "#/definitions/EndpointSettings"
+      Mounts:
+        type: "array"
+        description: |-
+          List of mounts used by the container.
+        items:
+          $ref: "#/definitions/MountPoint"
+      Health:
+        type: "object"
+        description: |-
+          Summary of health status
+
+          Added in v1.52, before that version all container summary not include Health.
+          After this attribute introduced, it includes containers with no health checks configured,
+          or containers that are not running with none
+        properties:
+          Status:
+            type: "string"
+            description: |-
+              the health status of the container
+            enum:
+              - "none"
+              - "starting"
+              - "healthy"
+              - "unhealthy"
+            example: "healthy"
+          FailingStreak:
+            description: "FailingStreak is the number of consecutive failures"
+            type: "integer"
+            example: 0
+
+  ContainersDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/container"
+    description: |
+      represents system data usage information for container resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active containers.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all containers.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive containers.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by containers.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of container summaries.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Summary
+
+  Driver:
+    description: "Driver represents a driver (network, logging, secrets)."
+    type: "object"
+    required: [Name]
+    properties:
+      Name:
+        description: "Name of the driver."
+        type: "string"
+        x-nullable: false
+        example: "some-driver"
+      Options:
+        description: "Key/value map of driver-specific options."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          OptionA: "value for driver-specific option A"
+          OptionB: "value for driver-specific option B"
+
+  SecretSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the secret."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Data:
+        description: |
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          It must be empty if the Driver field is set, in which case the data is
+          loaded from an external secret store. The maximum allowed size is 500KB,
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
+
+          This field is only used to _create_ a secret, and is not returned by
+          other endpoints.
+        type: "string"
+        example: ""
+      Driver:
+        description: |
+          Name of the secrets driver used to fetch the secret's value from an
+          external secret store.
+        $ref: "#/definitions/Driver"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Secret:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "blt1owaxmitz71s9v5zh81zun"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      Spec:
+        $ref: "#/definitions/SecretSpec"
+
+  ConfigSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the config."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Data:
+        description: |
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
+        type: "string"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Config:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ConfigSpec"
+
+  ContainerState:
+    description: |
+      ContainerState stores container's running state. It's part of ContainerJSONBase
+      and will be returned by the "inspect" command.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          String representation of the container state. Can be one of "created",
+          "running", "paused", "restarting", "removing", "exited", or "dead".
+        type: "string"
+        enum: ["created", "running", "paused", "restarting", "removing", "exited", "dead"]
+        example: "running"
+      Running:
+        description: |
+          Whether this container is running.
+
+          Note that a running container can be _paused_. The `Running` and `Paused`
+          booleans are not mutually exclusive:
+
+          When pausing a container (on Linux), the freezer cgroup is used to suspend
+          all processes in the container. Freezing the process requires the process to
+          be running. As a result, paused containers are both `Running` _and_ `Paused`.
+
+          Use the `Status` field instead to determine if a container's state is "running".
+        type: "boolean"
+        example: true
+      Paused:
+        description: "Whether this container is paused."
+        type: "boolean"
+        example: false
+      Restarting:
+        description: "Whether this container is restarting."
+        type: "boolean"
+        example: false
+      OOMKilled:
+        description: |
+          Whether a process within this container has been killed because it ran
+          out of memory since the container was last started.
+        type: "boolean"
+        example: false
+      Dead:
+        type: "boolean"
+        example: false
+      Pid:
+        description: "The process ID of this container"
+        type: "integer"
+        example: 1234
+      ExitCode:
+        description: "The last exit code of this container"
+        type: "integer"
+        example: 0
+      Error:
+        type: "string"
+      StartedAt:
+        description: "The time when this container was last started."
+        type: "string"
+        example: "2020-01-06T09:06:59.461876391Z"
+      FinishedAt:
+        description: "The time when this container last exited."
+        type: "string"
+        example: "2020-01-06T09:07:59.461876391Z"
+      Health:
+        $ref: "#/definitions/Health"
+
+  ContainerCreateResponse:
+    description: "OK response to ContainerCreate operation"
+    type: "object"
+    title: "ContainerCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warnings]
+    properties:
+      Id:
+        description: "The ID of the created container"
+        type: "string"
+        x-nullable: false
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Warnings:
+        description: "Warnings encountered when creating the container"
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example: []
+
+  ContainerUpdateResponse:
+    type: "object"
+    title: "ContainerUpdateResponse"
+    x-go-name: "UpdateResponse"
+    description: |-
+      Response for a successful container-update.
+    properties:
+      Warnings:
+        type: "array"
+        description: |-
+          Warnings encountered when updating the container.
+        items:
+          type: "string"
+        example: ["Published ports are discarded when using host network mode"]
+
+  ContainerStatsResponse:
+    description: |
+      Statistics sample for a container.
+    type: "object"
+    x-go-name: "StatsResponse"
+    title: "ContainerStatsResponse"
+    properties:
+      id:
+        description: |
+          ID of the container for which the stats were collected.
+        type: "string"
+        x-nullable: true
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      name:
+        description: |
+          Name of the container for which the stats were collected.
+        type: "string"
+        x-nullable: true
+        example: "boring_wozniak"
+      os_type:
+        description: |
+          OSType is the OS of the container ("linux" or "windows") to allow
+          platform-specific handling of stats.
+        type: "string"
+        x-nullable: true
+        example: "linux"
+      read:
+        description: |
+          Date and time at which this sample was collected.
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:22.165243637Z"
+      cpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+      memory_stats:
+        $ref: "#/definitions/ContainerMemoryStats"
+      networks:
+        description: |
+          Network statistics for the container per interface.
+
+          This field is omitted if the container has no networking enabled.
+        x-nullable: true
+        additionalProperties:
+          $ref: "#/definitions/ContainerNetworkStats"
+        example:
+          eth0:
+            rx_bytes: 5338
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 36
+            tx_bytes: 648
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 8
+          eth5:
+            rx_bytes: 4641
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 26
+            tx_bytes: 690
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 9
+      pids_stats:
+        $ref: "#/definitions/ContainerPidsStats"
+      blkio_stats:
+        $ref: "#/definitions/ContainerBlkioStats"
+      num_procs:
+        description: |
+          The number of processors on the system.
+
+          This field is Windows-specific and always zero for Linux containers.
+        type: "integer"
+        format: "uint32"
+        example: 16
+      storage_stats:
+        $ref: "#/definitions/ContainerStorageStats"
+      preread:
+        description: |
+          Date and time at which this first sample was collected. This field
+          is not propagated if the "one-shot" option is set. If the "one-shot"
+          option is set, this field may be omitted, empty, or set to a default
+          date (`0001-01-01T00:00:00Z`).
+
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:21.160452595Z"
+      precpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+
+  ContainerBlkioStats:
+    description: |
+      BlkioStats stores all IO service stats for data read and write.
+
+      This type is Linux-specific and holds many fields that are specific to cgroups v1.
+      On a cgroup v2 host, all fields other than `io_service_bytes_recursive`
+      are omitted or `null`.
+
+      This type is only populated on Linux and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStats"
+    x-nullable: true
+    properties:
+      io_service_bytes_recursive:
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_serviced_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_queue_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_service_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_wait_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_merged_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      sectors_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+    example:
+      io_service_bytes_recursive: [
+        {"major": 254, "minor": 0, "op": "read", "value": 7593984},
+        {"major": 254, "minor": 0, "op": "write", "value": 100}
+      ]
+      io_serviced_recursive: null
+      io_queue_recursive: null
+      io_service_time_recursive: null
+      io_wait_time_recursive: null
+      io_merged_recursive: null
+      io_time_recursive: null
+      sectors_recursive: null
+
+  ContainerBlkioStatEntry:
+    description: |
+      Blkio stats entry.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStatEntry"
+    x-nullable: true
+    properties:
+      major:
+        type: "integer"
+        format: "uint64"
+        example: 254
+      minor:
+        type: "integer"
+        format: "uint64"
+        example: 0
+      op:
+        type: "string"
+        example: "read"
+      value:
+        type: "integer"
+        format: "uint64"
+        example: 7593984
+
+  ContainerCPUStats:
+    description: |
+      CPU related info of the container
+    type: "object"
+    x-go-name: "CPUStats"
+    x-nullable: true
+    properties:
+      cpu_usage:
+        $ref: "#/definitions/ContainerCPUUsage"
+      system_cpu_usage:
+        description: |
+          System Usage.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      online_cpus:
+        description: |
+          Number of online CPUs.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint32"
+        x-nullable: true
+        example: 5
+      throttling_data:
+        $ref: "#/definitions/ContainerThrottlingData"
+
+  ContainerCPUUsage:
+    description: |
+      All CPU stats aggregated since container inception.
+    type: "object"
+    x-go-name: "CPUUsage"
+    x-nullable: true
+    properties:
+      total_usage:
+        description: |
+          Total CPU time consumed in nanoseconds (Linux) or 100's of nanoseconds (Windows).
+        type: "integer"
+        format: "uint64"
+        example: 29912000
+      percpu_usage:
+        description: |
+          Total CPU time (in nanoseconds) consumed per core (Linux).
+
+          This field is Linux-specific when using cgroups v1. It is omitted
+          when using cgroups v2 and Windows containers.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "integer"
+          format: "uint64"
+          example: 29912000
+
+      usage_in_kernelmode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in kernel mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 21994000
+      usage_in_usermode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in user mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 7918000
+
+  ContainerPidsStats:
+    description: |
+      PidsStats contains Linux-specific stats of a container's process-IDs (PIDs).
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "PidsStats"
+    x-nullable: true
+    properties:
+      current:
+        description: |
+          Current is the number of PIDs in the cgroup.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      limit:
+        description: |
+          Limit is the hard limit on the number of pids in the cgroup.
+          A "Limit" of 0 means that there is no limit.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: "18446744073709551615"
+
+  ContainerThrottlingData:
+    description: |
+      CPU throttling stats of the container.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "ThrottlingData"
+    x-nullable: true
+    properties:
+      periods:
+        description: |
+          Number of periods with throttling active.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_periods:
+        description: |
+          Number of periods when the container hit its throttling limit.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_time:
+        description: |
+          Aggregated time (in nanoseconds) the container was throttled for.
+        type: "integer"
+        format: "uint64"
+        example: 0
+
+  ContainerMemoryStats:
+    description: |
+      Aggregates all memory stats since container inception on Linux.
+      Windows returns stats for commit and private working set only.
+    type: "object"
+    x-go-name: "MemoryStats"
+    properties:
+      usage:
+        description: |
+          Current `res_counter` usage for memory.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      max_usage:
+        description: |
+          Maximum usage ever recorded.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      stats:
+        description: |
+          All the stats exported via memory.stat.
+
+          The fields in this object differ between cgroups v1 and v2.
+          On cgroups v1, fields such as `cache`, `rss`, `mapped_file` are available.
+          On cgroups v2, fields such as `file`, `anon`, `inactive_file` are available.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "object"
+        additionalProperties:
+          type: "integer"
+          format: "uint64"
+          x-nullable: true
+        example:
+          {
+            "active_anon": 1572864,
+            "active_file": 5115904,
+            "anon": 1572864,
+            "anon_thp": 0,
+            "file": 7626752,
+            "file_dirty": 0,
+            "file_mapped": 2723840,
+            "file_writeback": 0,
+            "inactive_anon": 0,
+            "inactive_file": 2510848,
+            "kernel_stack": 16384,
+            "pgactivate": 0,
+            "pgdeactivate": 0,
+            "pgfault": 2042,
+            "pglazyfree": 0,
+            "pglazyfreed": 0,
+            "pgmajfault": 45,
+            "pgrefill": 0,
+            "pgscan": 0,
+            "pgsteal": 0,
+            "shmem": 0,
+            "slab": 1180928,
+            "slab_reclaimable": 725576,
+            "slab_unreclaimable": 455352,
+            "sock": 0,
+            "thp_collapse_alloc": 0,
+            "thp_fault_alloc": 1,
+            "unevictable": 0,
+            "workingset_activate": 0,
+            "workingset_nodereclaim": 0,
+            "workingset_refault": 0
+          }
+      failcnt:
+        description: |
+          Number of times memory usage hits limits.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      limit:
+        description: |
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 8217579520
+      commitbytes:
+        description: |
+          Committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      commitpeakbytes:
+        description: |
+          Peak committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      privateworkingset:
+        description: |
+          Private working set.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+
+  ContainerNetworkStats:
+    description: |
+      Aggregates the network stats of one container
+    type: "object"
+    x-go-name: "NetworkStats"
+    x-nullable: true
+    properties:
+      rx_bytes:
+        description: |
+          Bytes received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 5338
+      rx_packets:
+        description: |
+          Packets received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 36
+      rx_errors:
+        description: |
+          Received errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      rx_dropped:
+        description: |
+          Incoming packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_bytes:
+        description: |
+          Bytes sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 1200
+      tx_packets:
+        description: |
+          Packets sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 12
+      tx_errors:
+        description: |
+          Sent errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_dropped:
+        description: |
+          Outgoing packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      endpoint_id:
+        description: |
+          Endpoint ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+      instance_id:
+        description: |
+          Instance ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+
+  ContainerStorageStats:
+    description: |
+      StorageStats is the disk I/O stats for read/write on Windows.
+
+      This type is Windows-specific and omitted for Linux containers.
+    type: "object"
+    x-go-name: "StorageStats"
+    x-nullable: true
+    properties:
+      read_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      read_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+
+  ContainerTopResponse:
+    type: "object"
+    x-go-name: "TopResponse"
+    title: "ContainerTopResponse"
+    description: |-
+      Container "top" response.
+    properties:
+      Titles:
+        description: "The ps column titles"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          Titles:
+            - "UID"
+            - "PID"
+            - "PPID"
+            - "C"
+            - "STIME"
+            - "TTY"
+            - "TIME"
+            - "CMD"
+      Processes:
+        description: |-
+          Each process running in the container, where each process
+          is an array of values corresponding to the titles.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          Processes:
+            -
+              - "root"
+              - "13642"
+              - "882"
+              - "0"
+              - "17:03"
+              - "pts/0"
+              - "00:00:00"
+              - "/bin/bash"
+            -
+              - "root"
+              - "13735"
+              - "13642"
+              - "0"
+              - "17:06"
+              - "pts/0"
+              - "00:00:00"
+              - "sleep 10"
+
+  ContainerWaitResponse:
+    description: "OK response to ContainerWait operation"
+    type: "object"
+    x-go-name: "WaitResponse"
+    title: "ContainerWaitResponse"
+    required: [StatusCode]
+    properties:
+      StatusCode:
+        description: "Exit code of the container"
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Error:
+        $ref: "#/definitions/ContainerWaitExitError"
+
+  ContainerWaitExitError:
+    description: "container waiting error, if any"
+    type: "object"
+    x-go-name: "WaitExitError"
+    properties:
+      Message:
+        description: "Details of an error"
+        type: "string"
+
+  SystemVersion:
+    type: "object"
+    description: |
+      Response of Engine API: GET "/version"
+    properties:
+      Platform:
+        type: "object"
+        required: [Name]
+        properties:
+          Name:
+            type: "string"
+      Components:
+        type: "array"
+        description: |
+          Information about system components
+        items:
+          type: "object"
+          x-go-name: ComponentVersion
+          required: [Name, Version]
+          properties:
+            Name:
+              description: |
+                Name of the component
+              type: "string"
+              example: "Engine"
+            Version:
+              description: |
+                Version of the component
+              type: "string"
+              x-nullable: false
+              example: "27.0.1"
+            Details:
+              description: |
+                Key/value pairs of strings with additional information about the
+                component. These values are intended for informational purposes
+                only, and their content is not defined, and not part of the API
+                specification.
+
+                These messages can be printed by the client as information to the user.
+              type: "object"
+              x-nullable: true
+      Version:
+        description: "The version of the daemon"
+        type: "string"
+        example: "27.0.1"
+      ApiVersion:
+        description: |
+          The default (and highest) API version that is supported by the daemon
+        type: "string"
+        example: "1.47"
+      MinAPIVersion:
+        description: |
+          The minimum API version that is supported by the daemon
+        type: "string"
+        example: "1.24"
+      GitCommit:
+        description: |
+          The Git commit of the source code that was used to build the daemon
+        type: "string"
+        example: "48a66213fe"
+      GoVersion:
+        description: |
+          The version Go used to compile the daemon, and the version of the Go
+          runtime in use.
+        type: "string"
+        example: "go1.22.7"
+      Os:
+        description: |
+          The operating system that the daemon is running on ("linux" or "windows")
+        type: "string"
+        example: "linux"
+      Arch:
+        description: |
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "amd64"
+      KernelVersion:
+        description: |
+          The kernel version (`uname -r`) that the daemon is running on.
+
+          This field is omitted when empty.
+        type: "string"
+        example: "6.8.0-31-generic"
+      Experimental:
+        description: |
+          Indicates if the daemon is started with experimental features enabled.
+
+          This field is omitted when empty / false.
+        type: "boolean"
+        example: true
+      BuildTime:
+        description: |
+          The date and time that the daemon was compiled.
+        type: "string"
+        example: "2020-06-22T15:49:27.000000000+00:00"
+
+  SystemInfo:
+    type: "object"
+    properties:
+      ID:
+        description: |
+          Unique identifier of the daemon.
+
+          <p><br /></p>
+
+          > **Note**: The format of the ID itself is not part of the API, and
+          > should not be considered stable.
+        type: "string"
+        example: "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS"
+      Containers:
+        description: "Total number of containers on the host."
+        type: "integer"
+        example: 14
+      ContainersRunning:
+        description: |
+          Number of containers with status `"running"`.
+        type: "integer"
+        example: 3
+      ContainersPaused:
+        description: |
+          Number of containers with status `"paused"`.
+        type: "integer"
+        example: 1
+      ContainersStopped:
+        description: |
+          Number of containers with status `"stopped"`.
+        type: "integer"
+        example: 10
+      Images:
+        description: |
+          Total number of images on the host.
+
+          Both _tagged_ and _untagged_ (dangling) images are counted.
+        type: "integer"
+        example: 508
+      Driver:
+        description: "Name of the storage driver in use."
+        type: "string"
+        example: "overlay2"
+      DriverStatus:
+        description: |
+          Information specific to the storage driver, provided as
+          "label" / "value" pairs.
+
+          This information is provided by the storage driver, and formatted
+          in a way consistent with the output of `docker info` on the command
+          line.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["Backing Filesystem", "extfs"]
+          - ["Supports d_type", "true"]
+          - ["Native Overlay Diff", "true"]
+      DockerRootDir:
+        description: |
+          Root directory of persistent Docker state.
+
+          Defaults to `/var/lib/docker` on Linux, and `C:\ProgramData\docker`
+          on Windows.
+        type: "string"
+        example: "/var/lib/docker"
+      Plugins:
+        $ref: "#/definitions/PluginsInfo"
+      MemoryLimit:
+        description: "Indicates if the host has memory limit support enabled."
+        type: "boolean"
+        example: true
+      SwapLimit:
+        description: "Indicates if the host has memory swap limit support enabled."
+        type: "boolean"
+        example: true
+      CpuCfsPeriod:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) period is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CpuCfsQuota:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) quota is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CPUShares:
+        description: |
+          Indicates if CPU Shares limiting is supported by the host.
+        type: "boolean"
+        example: true
+      CPUSet:
+        description: |
+          Indicates if CPUsets (cpuset.cpus, cpuset.mems) are supported by the host.
+
+          See [cpuset(7)](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt)
+        type: "boolean"
+        example: true
+      PidsLimit:
+        description: "Indicates if the host kernel has PID limit support enabled."
+        type: "boolean"
+        example: true
+      OomKillDisable:
+        description: "Indicates if OOM killer disable is supported on the host."
+        type: "boolean"
+      IPv4Forwarding:
+        description: "Indicates IPv4 forwarding is enabled."
+        type: "boolean"
+        example: true
+      Debug:
+        description: |
+          Indicates if the daemon is running in debug-mode / with debug-level
+          logging enabled.
+        type: "boolean"
+        example: true
+      NFd:
+        description: |
+          The total number of file Descriptors in use by the daemon process.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 64
+      NGoroutines:
+        description: |
+          The  number of goroutines that currently exist.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 174
+      SystemTime:
+        description: |
+          Current system-time in [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          format with nano-seconds.
+        type: "string"
+        example: "2017-08-08T20:28:29.06202363Z"
+      LoggingDriver:
+        description: |
+          The logging driver to use as a default for new containers.
+        type: "string"
+      CgroupDriver:
+        description: |
+          The driver to use for managing cgroups.
+        type: "string"
+        enum: ["cgroupfs", "systemd", "none"]
+        default: "cgroupfs"
+        example: "cgroupfs"
+      CgroupVersion:
+        description: |
+          The version of the cgroup.
+        type: "string"
+        enum: ["1", "2"]
+        default: "1"
+        example: "1"
+      NEventsListener:
+        description: "Number of event listeners subscribed."
+        type: "integer"
+        example: 30
+      KernelVersion:
+        description: |
+          Kernel version of the host.
+
+          On Linux, this information obtained from `uname`. On Windows this
+          information is queried from the <kbd>HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\</kbd>
+          registry value, for example _"10.0 14393 (14393.1198.amd64fre.rs1_release_sec.170427-1353)"_.
+        type: "string"
+        example: "6.8.0-31-generic"
+      OperatingSystem:
+        description: |
+          Name of the host's operating system, for example: "Ubuntu 24.04 LTS"
+          or "Windows Server 2016 Datacenter"
+        type: "string"
+        example: "Ubuntu 24.04 LTS"
+      OSVersion:
+        description: |
+          Version of the host's operating system
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including its
+          > very existence, and the formatting of values, should not be considered
+          > stable, and may change without notice.
+        type: "string"
+        example: "24.04"
+      OSType:
+        description: |
+          Generic type of the operating system of the host, as returned by the
+          Go runtime (`GOOS`).
+
+          Currently returned values are "linux" and "windows". A full list of
+          possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "linux"
+      Architecture:
+        description: |
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
+
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
+        type: "string"
+        example: "x86_64"
+      NCPU:
+        description: |
+          The number of logical CPUs usable by the daemon.
+
+          The number of available CPUs is checked by querying the operating
+          system when the daemon starts. Changes to operating system CPU
+          allocation after the daemon is started are not reflected.
+        type: "integer"
+        example: 4
+      MemTotal:
+        description: |
+          Total amount of physical memory available on the host, in bytes.
+        type: "integer"
+        format: "int64"
+        example: 2095882240
+
+      IndexServerAddress:
+        description: |
+          Address / URL of the index server that is used for image search,
+          and as a default for user authentication for Docker Hub and Docker Cloud.
+        default: "https://index.docker.io/v1/"
+        type: "string"
+        example: "https://index.docker.io/v1/"
+      RegistryConfig:
+        $ref: "#/definitions/RegistryServiceConfig"
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+      HttpProxy:
+        description: |
+          HTTP-proxy configured for the daemon. This value is obtained from the
+          [`HTTP_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "http://xxxxx:xxxxx@proxy.corp.example.com:8080"
+      HttpsProxy:
+        description: |
+          HTTPS-proxy configured for the daemon. This value is obtained from the
+          [`HTTPS_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "https://xxxxx:xxxxx@proxy.corp.example.com:4443"
+      NoProxy:
+        description: |
+          Comma-separated list of domain extensions for which no proxy should be
+          used. This value is obtained from the [`NO_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html)
+          environment variable.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "*.local, 169.254/16"
+      Name:
+        description: "Hostname of the host."
+        type: "string"
+        example: "node5.corp.example.com"
+      Labels:
+        description: |
+          User-defined labels (key/value metadata) as set on the daemon.
+
+          <p><br /></p>
+
+          > **Note**: When part of a Swarm, nodes can both have _daemon_ labels,
+          > set through the daemon configuration, and _node_ labels, set from a
+          > manager node in the Swarm. Node labels are not included in this
+          > field. Node labels can be retrieved using the `/nodes/(id)` endpoint
+          > on a manager node in the Swarm.
+        type: "array"
+        items:
+          type: "string"
+        example: ["storage=ssd", "production"]
+      ExperimentalBuild:
+        description: |
+          Indicates if experimental features are enabled on the daemon.
+        type: "boolean"
+        example: true
+      ServerVersion:
+        description: |
+          Version string of the daemon.
+        type: "string"
+        example: "27.0.1"
+      Runtimes:
+        description: |
+          List of [OCI compliant](https://github.com/opencontainers/runtime-spec)
+          runtimes configured on the daemon. Keys hold the "name" used to
+          reference the runtime.
+
+          The Docker daemon relies on an OCI compliant runtime (invoked via the
+          `containerd` daemon) as its interface to the Linux kernel namespaces,
+          cgroups, and SELinux.
+
+          The default runtime is `runc`, and automatically configured. Additional
+          runtimes can be configured by the user and will be listed here.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/Runtime"
+        default:
+          runc:
+            path: "runc"
+        example:
+          runc:
+            path: "runc"
+          runc-master:
+            path: "/go/bin/runc"
+          custom:
+            path: "/usr/local/bin/my-oci-runtime"
+            runtimeArgs: ["--debug", "--systemd-cgroup=false"]
+      DefaultRuntime:
+        description: |
+          Name of the default OCI runtime that is used when starting containers.
+
+          The default can be overridden per-container at create time.
+        type: "string"
+        default: "runc"
+        example: "runc"
+      Swarm:
+        $ref: "#/definitions/SwarmInfo"
+      LiveRestoreEnabled:
+        description: |
+          Indicates if live restore is enabled.
+
+          If enabled, containers are kept running when the daemon is shutdown
+          or upon daemon start if running containers are detected.
+        type: "boolean"
+        default: false
+        example: false
+      Isolation:
+        description: |
+          Represents the isolation technology to use as a default for containers.
+          The supported values are platform-specific.
+
+          If no isolation value is specified on daemon start, on Windows client,
+          the default is `hyperv`, and on Windows server, the default is `process`.
+
+          This option is currently not used on other platforms.
+        default: "default"
+        type: "string"
+        enum:
+          - "default"
+          - "hyperv"
+          - "process"
+          - ""
+      InitBinary:
+        description: |
+          Name and, optional, path of the `docker-init` binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "docker-init"
+      ContainerdCommit:
+        $ref: "#/definitions/Commit"
+      RuncCommit:
+        $ref: "#/definitions/Commit"
+      InitCommit:
+        $ref: "#/definitions/Commit"
+      SecurityOptions:
+        description: |
+          List of security features that are enabled on the daemon, such as
+          apparmor, seccomp, SELinux, user-namespaces (userns), rootless and
+          no-new-privileges.
+
+          Additional configuration options for each security feature may
+          be present, and are included as a comma-separated list of key/value
+          pairs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "name=apparmor"
+          - "name=seccomp,profile=default"
+          - "name=selinux"
+          - "name=userns"
+          - "name=rootless"
+      ProductLicense:
+        description: |
+          Reports a summary of the product license on the daemon.
+
+          If a commercial license has been applied to the daemon, information
+          such as number of nodes, and expiration are included.
+        type: "string"
+        example: "Community Engine"
+      DefaultAddressPools:
+        description: |
+          List of custom default address pools for local networks, which can be
+          specified in the daemon.json file or dockerd option.
+
+          Example: a Base "10.10.0.0/16" with Size 24 will define the set of 256
+          10.10.[0-255].0/24 address pools.
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Base:
+              description: "The network address in CIDR format"
+              type: "string"
+              example: "10.10.0.0/16"
+            Size:
+              description: "The network pool size"
+              type: "integer"
+              example: "24"
+      FirewallBackend:
+        $ref: "#/definitions/FirewallInfo"
+      DiscoveredDevices:
+        description: |
+          List of devices discovered by device drivers.
+
+          Each device includes information about its source driver, kind, name,
+          and additional driver-specific attributes.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceInfo"
+      NRI:
+        $ref: "#/definitions/NRIInfo"
+      Warnings:
+        description: |
+          List of warnings / informational messages about missing features, or
+          issues related to the daemon configuration.
+
+          These messages can be printed by the client as information to the user.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "WARNING: No memory limit support"
+      CDISpecDirs:
+        description: |
+          List of directories where (Container Device Interface) CDI
+          specifications are located.
+
+          These specifications define vendor-specific modifications to an OCI
+          runtime specification for a container being created.
+
+          An empty list indicates that CDI device injection is disabled.
+
+          Note that since using CDI device injection requires the daemon to have
+          experimental enabled. For non-experimental daemons an empty list will
+          always be returned.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/etc/cdi"
+          - "/var/run/cdi"
+      Containerd:
+        $ref: "#/definitions/ContainerdInfo"
+
+  ContainerdInfo:
+    description: |
+      Information for connecting to the containerd instance that is used by the daemon.
+      This is included for debugging purposes only.
+    type: "object"
+    x-nullable: true
+    properties:
+      Address:
+        description: "The address of the containerd socket."
+        type: "string"
+        example: "/run/containerd/containerd.sock"
+      Namespaces:
+        description: |
+          The namespaces that the daemon uses for running containers and
+          plugins in containerd. These namespaces can be configured in the
+          daemon configuration, and are considered to be used exclusively
+          by the daemon, Tampering with the containerd instance may cause
+          unexpected behavior.
+
+          As these namespaces are considered to be exclusively accessed
+          by the daemon, it is not recommended to change these values,
+          or to change them to a value that is used by other systems,
+          such as cri-containerd.
+        type: "object"
+        properties:
+          Containers:
+            description: |
+              The default containerd namespace used for containers managed
+              by the daemon.
+
+              The default namespace for containers is "moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "moby"
+            example: "moby"
+          Plugins:
+            description: |
+              The default containerd namespace used for plugins managed by
+              the daemon.
+
+              The default namespace for plugins is "plugins.moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "plugins.moby"
+            example: "plugins.moby"
+
+  FirewallInfo:
+    description: |
+      Information about the daemon's firewalling configuration.
+
+      This field is currently only used on Linux, and omitted on other platforms.
+    type: "object"
+    x-nullable: true
+    properties:
+      Driver:
+        description: |
+          The name of the firewall backend driver.
+        type: "string"
+        example: "nftables"
+      Info:
+        description: |
+          Information about the firewall backend, provided as
+          "label" / "value" pairs.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["ReloadedAt", "2025-01-01T00:00:00Z"]
+
+  # PluginsInfo is a temp struct holding Plugins name
+  # registered with docker daemon. It is used by Info struct
+  PluginsInfo:
+    description: |
+      Available plugins per type.
+
+      <p><br /></p>
+
+      > **Note**: Only unmanaged (V1) plugins are included in this list.
+      > V1 plugins are "lazily" loaded, and are not returned in this list
+      > if there is no resource using the plugin.
+    type: "object"
+    properties:
+      Volume:
+        description: "Names of available volume-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["local"]
+      Network:
+        description: "Names of available network-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["bridge", "host", "ipvlan", "macvlan", "null", "overlay"]
+      Authorization:
+        description: "Names of available authorization plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["img-authz-plugin", "hbm"]
+      Log:
+        description: "Names of available logging-drivers, and logging-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["awslogs", "fluentd", "gcplogs", "gelf", "journald", "json-file", "splunk", "syslog"]
+
+
+  RegistryServiceConfig:
+    description: |
+      RegistryServiceConfig stores daemon registry services configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      InsecureRegistryCIDRs:
+        description: |
+          List of IP ranges of insecure registries, using the CIDR syntax
+          ([RFC 4632](https://tools.ietf.org/html/4632)). Insecure registries
+          accept un-encrypted (HTTP) and/or untrusted (HTTPS with certificates
+          from unknown CAs) communication.
+
+          By default, local registries (`::1/128` and `127.0.0.0/8`) are configured as
+          insecure. All other registries are secure. Communicating with an
+          insecure registry is not possible if the daemon assumes that registry
+          is secure.
+
+          This configuration override this behavior, insecure communication with
+          registries whose resolved IP address is within the subnet described by
+          the CIDR syntax.
+
+          Registries can also be marked insecure by hostname. Those registries
+          are listed under `IndexConfigs` and have their `Secure` field set to
+          `false`.
+
+          > **Warning**: Using this option can be useful when running a local
+          > registry, but introduces security vulnerabilities. This option
+          > should therefore ONLY be used for testing purposes. For increased
+          > security, users should add their CA to their system's list of trusted
+          > CAs instead of enabling this option.
+        type: "array"
+        items:
+          type: "string"
+        example: ["::1/128", "127.0.0.0/8"]
+      IndexConfigs:
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/IndexInfo"
+        example:
+          "127.0.0.1:5000":
+            "Name": "127.0.0.1:5000"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "[2001:db8:a0b:12f0::1]:80":
+            "Name": "[2001:db8:a0b:12f0::1]:80"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "docker.io":
+            Name: "docker.io"
+            Mirrors: ["https://hub-mirror.corp.example.com:5000/"]
+            Secure: true
+            Official: true
+          "registry.internal.corp.example.com:3000":
+            Name: "registry.internal.corp.example.com:3000"
+            Mirrors: []
+            Secure: false
+            Official: false
+      Mirrors:
+        description: |
+          List of registry URLs that act as a mirror for the official
+          (`docker.io`) registry.
+
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://[2001:db8:a0b:12f0::1]/"
+
+  IndexInfo:
+    description:
+      IndexInfo contains information about a registry.
+    type: "object"
+    x-nullable: true
+    properties:
+      Name:
+        description: |
+          Name of the registry, such as "docker.io".
+        type: "string"
+        example: "docker.io"
+      Mirrors:
+        description: |
+          List of mirrors, expressed as URIs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://registry-2.docker.io/"
+          - "https://registry-3.docker.io/"
+      Secure:
+        description: |
+          Indicates if the registry is part of the list of insecure
+          registries.
+
+          If `false`, the registry is insecure. Insecure registries accept
+          un-encrypted (HTTP) and/or untrusted (HTTPS with certificates from
+          unknown CAs) communication.
+
+          > **Warning**: Insecure registries can be useful when running a local
+          > registry. However, because its use creates security vulnerabilities
+          > it should ONLY be enabled for testing purposes. For increased
+          > security, users should add their CA to their system's list of
+          > trusted CAs instead of enabling this option.
+        type: "boolean"
+        example: true
+      Official:
+        description: |
+          Indicates whether this is an official registry (i.e., Docker Hub / docker.io)
+        type: "boolean"
+        example: true
+
+  Runtime:
+    description: |
+      Runtime describes an [OCI compliant](https://github.com/opencontainers/runtime-spec)
+      runtime.
+
+      The runtime is invoked by the daemon via the `containerd` daemon. OCI
+      runtimes act as an interface to the Linux kernel namespaces, cgroups,
+      and SELinux.
+    type: "object"
+    properties:
+      path:
+        description: |
+          Name and, optional, path, of the OCI executable binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "/usr/local/bin/my-oci-runtime"
+      runtimeArgs:
+        description: |
+          List of command-line arguments to pass to the runtime when invoked.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["--debug", "--systemd-cgroup=false"]
+      status:
+        description: |
+          Information specific to the runtime.
+
+          While this API specification does not define data provided by runtimes,
+          the following well-known properties may be provided by runtimes:
+
+          `org.opencontainers.runtime-spec.features`: features structure as defined
+          in the [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec/blob/main/features.md),
+          in a JSON string representation.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "org.opencontainers.runtime-spec.features": "{\"ociVersionMin\":\"1.0.0\",\"ociVersionMax\":\"1.1.0\",\"...\":\"...\"}"
+
+  Commit:
+    description: |
+      Commit holds the Git-commit (SHA1) that a binary was built from, as
+      reported in the version-string of external tools, such as `containerd`,
+      or `runC`.
+    type: "object"
+    properties:
+      ID:
+        description: "Actual commit ID of external tool."
+        type: "string"
+        example: "cfb82a876ecc11b5ca0977d1733adbe58599088a"
+
+  SwarmInfo:
+    description: |
+      Represents generic information about swarm.
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+        default: ""
+        example: "k67qz4598weg5unwwffg6z1m1"
+      NodeAddr:
+        description: |
+          IP address at which this node can be reached by other nodes in the
+          swarm.
+        type: "string"
+        default: ""
+        example: "10.0.0.46"
+      LocalNodeState:
+        $ref: "#/definitions/LocalNodeState"
+      ControlAvailable:
+        type: "boolean"
+        default: false
+        example: true
+      Error:
+        type: "string"
+        default: ""
+      RemoteManagers:
+        description: |
+          List of ID's and addresses of other managers in the swarm.
+        type: "array"
+        default: null
+        x-nullable: true
+        items:
+          $ref: "#/definitions/PeerNode"
+        example:
+          - NodeID: "71izy0goik036k48jg985xnds"
+            Addr: "10.0.0.158:2377"
+          - NodeID: "79y6h1o4gv8n120drcprv5nmc"
+            Addr: "10.0.0.159:2377"
+          - NodeID: "k67qz4598weg5unwwffg6z1m1"
+            Addr: "10.0.0.46:2377"
+      Nodes:
+        description: "Total number of nodes in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 4
+      Managers:
+        description: "Total number of managers in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 3
+      Cluster:
+        $ref: "#/definitions/ClusterInfo"
+
+  LocalNodeState:
+    description: "Current local status of this node."
+    type: "string"
+    default: ""
+    enum:
+      - ""
+      - "inactive"
+      - "pending"
+      - "active"
+      - "error"
+      - "locked"
+    example: "active"
+
+  PeerNode:
+    description: "Represents a peer-node in the swarm"
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+      Addr:
+        description: |
+          IP address and ports at which this node can be reached.
+        type: "string"
+
+  NetworkAttachmentConfig:
+    description: |
+      Specifies how a service should be attached to a particular network.
+    type: "object"
+    properties:
+      Target:
+        description: |
+          The target network for attachment. Must be a network name or ID.
+        type: "string"
+      Aliases:
+        description: |
+          Discoverable alternate names for the service on this network.
+        type: "array"
+        items:
+          type: "string"
+      DriverOpts:
+        description: |
+          Driver attachment options for the network target.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  EventActor:
+    description: |
+      Actor describes something that generates events, like a container, network,
+      or a volume.
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the object emitting the event"
+        type: "string"
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Attributes:
+        description: |
+          Various key/value attributes of the object, depending on its type.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-label-value"
+          image: "alpine:latest"
+          name: "my-container"
+
+  EventMessage:
+    description: |
+      EventMessage represents the information an event contains.
+    type: "object"
+    title: "SystemEventsResponse"
+    properties:
+      Type:
+        description: "The type of object emitting the event"
+        type: "string"
+        enum: ["builder", "config", "container", "daemon", "image", "network", "node", "plugin", "secret", "service", "volume"]
+        example: "container"
+      Action:
+        description: "The type of event"
+        type: "string"
+        example: "create"
+      Actor:
+        $ref: "#/definitions/EventActor"
+      scope:
+        description: |
+          Scope of the event. Engine events are `local` scope. Cluster (Swarm)
+          events are `swarm` scope.
+        type: "string"
+        enum: ["local", "swarm"]
+      time:
+        description: "Timestamp of event"
+        type: "integer"
+        format: "int64"
+        example: 1629574695
+      timeNano:
+        description: "Timestamp of event, with nanosecond accuracy"
+        type: "integer"
+        format: "int64"
+        example: 1629574695515050031
+
+  OCIDescriptor:
+    type: "object"
+    x-go-name: Descriptor
+    description: |
+      A descriptor struct containing digest, media type, and size, as defined in
+      the [OCI Content Descriptors Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/descriptor.md).
+    properties:
+      mediaType:
+        description: |
+          The media type of the object this schema refers to.
+        type: "string"
+        example: "application/vnd.oci.image.manifest.v1+json"
+      digest:
+        description: |
+          The digest of the targeted content.
+        type: "string"
+        example: "sha256:c0537ff6a5218ef531ece93d4984efc99bbf3f7497c0a7726c88e2bb7584dc96"
+      size:
+        description: |
+          The size in bytes of the blob.
+        type: "integer"
+        format: "int64"
+        example: 424
+      urls:
+        description: |-
+          List of URLs from which this object MAY be downloaded.
+        type: "array"
+        items:
+          type: "string"
+          format: "uri"
+        x-nullable: true
+      annotations:
+        description: |-
+          Arbitrary metadata relating to the targeted content.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "com.docker.official-images.bashbrew.arch": "amd64"
+          "org.opencontainers.image.base.digest": "sha256:0d0ef5c914d3ea700147da1bd050c59edb8bb12ca312f3800b29d7c8087eabd8"
+          "org.opencontainers.image.base.name": "scratch"
+          "org.opencontainers.image.created": "2025-01-27T00:00:00Z"
+          "org.opencontainers.image.revision": "9fabb4bad5138435b01857e2fe9363e2dc5f6a79"
+          "org.opencontainers.image.source": "https://git.launchpad.net/cloud-images/+oci/ubuntu-base"
+          "org.opencontainers.image.url": "https://hub.docker.com/_/ubuntu"
+          "org.opencontainers.image.version": "24.04"
+      data:
+        type: string
+        x-nullable: true
+        description: |-
+          Data is an embedding of the targeted content. This is encoded as a base64
+          string when marshalled to JSON (automatically, by encoding/json). If
+          present, Data can be used directly to avoid fetching the targeted content.
+        example: null
+      platform:
+        $ref: "#/definitions/OCIPlatform"
+      artifactType:
+        description: |-
+          ArtifactType is the IANA media type of this artifact.
+        type: "string"
+        x-nullable: true
+        example: null
+
+  OCIPlatform:
+    type: "object"
+    x-go-name: Platform
+    x-nullable: true
+    description: |
+      Describes the platform which the image in the manifest runs on, as defined
+      in the [OCI Image Index Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/image-index.md).
+    properties:
+      architecture:
+        description: |
+          The CPU architecture, for example `amd64` or `ppc64`.
+        type: "string"
+        example: "arm"
+      os:
+        description: |
+          The operating system, for example `linux` or `windows`.
+        type: "string"
+        example: "windows"
+      os.version:
+        description: |
+          Optional field specifying the operating system version, for example on
+          Windows `10.0.19041.1165`.
+        type: "string"
+        example: "10.0.19041.1165"
+      os.features:
+        description: |
+          Optional field specifying an array of strings, each listing a required
+          OS feature (for example on Windows `win32k`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "win32k"
+      variant:
+        description: |
+          Optional field specifying a variant of the CPU, for example `v7` to
+          specify ARMv7 when architecture is `arm`.
+        type: "string"
+        example: "v7"
+
+  DistributionInspect:
+    type: "object"
+    x-go-name: DistributionInspect
+    title: "DistributionInspectResponse"
+    required: [Descriptor, Platforms]
+    description: |
+      Describes the result obtained from contacting the registry to retrieve
+      image metadata.
+    properties:
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Platforms:
+        type: "array"
+        description: |
+          An array containing all platforms supported by the image.
+        items:
+          $ref: "#/definitions/OCIPlatform"
+
+  ClusterVolume:
+    type: "object"
+    description: |
+      Options and information specific to, and only present on, Swarm CSI
+      cluster volumes.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          The Swarm ID of this volume. Because cluster volumes are Swarm
+          objects, they have an ID, unlike non-cluster volumes. This ID can
+          be used to refer to the Volume instead of the name.
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+      Info:
+        type: "object"
+        description: |
+          Information about the global status of the volume.
+        properties:
+          CapacityBytes:
+            type: "integer"
+            format: "int64"
+            description: |
+              The capacity of the volume in bytes. A value of 0 indicates that
+              the capacity is unknown.
+          VolumeContext:
+            type: "object"
+            description: |
+              A map of strings to strings returned from the storage plugin when
+              the volume is created.
+            additionalProperties:
+              type: "string"
+          VolumeID:
+            type: "string"
+            description: |
+              The ID of the volume as returned by the CSI storage plugin. This
+              is distinct from the volume's ID as provided by Docker. This ID
+              is never used by the user when communicating with Docker to refer
+              to this volume. If the ID is blank, then the Volume has not been
+              successfully created in the plugin yet.
+          AccessibleTopology:
+            type: "array"
+            description: |
+              The topology this volume is actually accessible from.
+            items:
+              $ref: "#/definitions/Topology"
+      PublishStatus:
+        type: "array"
+        description: |
+          The status of the volume as it pertains to its publishing and use on
+          specific nodes
+        items:
+          type: "object"
+          properties:
+            NodeID:
+              type: "string"
+              description: |
+                The ID of the Swarm node the volume is published on.
+            State:
+              type: "string"
+              description: |
+                The published state of the volume.
+                * `pending-publish` The volume should be published to this node, but the call to the controller plugin to do so has not yet been successfully completed.
+                * `published` The volume is published successfully to the node.
+                * `pending-node-unpublish` The volume should be unpublished from the node, and the manager is awaiting confirmation from the worker that it has done so.
+                * `pending-controller-unpublish` The volume is successfully unpublished from the node, but has not yet been successfully unpublished on the controller.
+              enum:
+                - "pending-publish"
+                - "published"
+                - "pending-node-unpublish"
+                - "pending-controller-unpublish"
+            PublishContext:
+              type: "object"
+              description: |
+                A map of strings to strings returned by the CSI controller
+                plugin when a volume is published.
+              additionalProperties:
+                type: "string"
+
+  ClusterVolumeSpec:
+    type: "object"
+    description: |
+      Cluster-specific options used to create the volume.
+    properties:
+      Group:
+        type: "string"
+        description: |
+          Group defines the volume group of this volume. Volumes belonging to
+          the same group can be referred to by group name when creating
+          Services.  Referring to a volume by group instructs Swarm to treat
+          volumes in that group interchangeably for the purpose of scheduling.
+          Volumes with an empty string for a group technically all belong to
+          the same, emptystring group.
+      AccessMode:
+        type: "object"
+        description: |
+          Defines how the volume is used by tasks.
+        properties:
+          Scope:
+            type: "string"
+            description: |
+              The set of nodes this volume can be used on at one time.
+              - `single` The volume may only be scheduled to one node at a time.
+              - `multi` the volume may be scheduled to any supported number of nodes at a time.
+            default: "single"
+            enum: ["single", "multi"]
+            x-nullable: false
+          Sharing:
+            type: "string"
+            description: |
+              The number and way that different tasks can use this volume
+              at one time.
+              - `none` The volume may only be used by one task at a time.
+              - `readonly` The volume may be used by any number of tasks, but they all must mount the volume as readonly
+              - `onewriter` The volume may be used by any number of tasks, but only one may mount it as read/write.
+              - `all` The volume may have any number of readers and writers.
+            default: "none"
+            enum: ["none", "readonly", "onewriter", "all"]
+            x-nullable: false
+          MountVolume:
+            type: "object"
+            description: |
+              Options for using this volume as a Mount-type volume.
+
+                  Either MountVolume or BlockVolume, but not both, must be
+                  present.
+                properties:
+                  FsType:
+                    type: "string"
+                    description: |
+                      Specifies the filesystem type for the mount volume.
+                      Optional.
+                  MountFlags:
+                    type: "array"
+                    description: |
+                      Flags to pass when mounting the volume. Optional.
+                    items:
+                      type: "string"
+              BlockVolume:
+                type: "object"
+                description: |
+                  Options for using this volume as a Block-type volume.
+                  Intentionally empty.
+          Secrets:
+            type: "array"
+            description: |
+              Swarm Secrets that are passed to the CSI storage plugin when
+              operating on this volume.
+            items:
+              type: "object"
+              description: |
+                One cluster volume secret entry. Defines a key-value pair that
+                is passed to the plugin.
+              properties:
+                Key:
+                  type: "string"
+                  description: |
+                    Key is the name of the key of the key-value pair passed to
+                    the plugin.
+                Secret:
+                  type: "string"
+                  description: |
+                    Secret is the swarm Secret object from which to read data.
+                    This can be a Secret name or ID. The Secret data is
+                    retrieved by swarm and used as the value of the key-value
+                    pair passed to the plugin.
+          AccessibilityRequirements:
+            type: "object"
+            description: |
+              Requirements for the accessible topology of the volume. These
+              fields are optional. For an in-depth description of what these
+              fields mean, see the CSI specification.
+            properties:
+              Requisite:
+                type: "array"
+                description: |
+                  A list of required topologies, at least one of which the
+                  volume must be accessible from.
+                items:
+                  $ref: "#/definitions/Topology"
+              Preferred:
+                type: "array"
+                description: |
+                  A list of topologies that the volume should attempt to be
+                  provisioned in.
+                items:
+                  $ref: "#/definitions/Topology"
+          CapacityRange:
+            type: "object"
+            description: |
+              The desired capacity that the volume should be created with. If
+              empty, the plugin will decide the capacity.
+            properties:
+              RequiredBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must be at least this big. The value of 0
+                  indicates an unspecified minimum
+              LimitBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must not be bigger than this. The value of 0
+                  indicates an unspecified maximum.
+          Availability:
+            type: "string"
+            description: |
+              The availability of the volume for use in tasks.
+              - `active` The volume is fully available for scheduling on the cluster
+              - `pause` No new workloads should use the volume, but existing workloads are not stopped.
+              - `drain` All workloads using this volume should be stopped and rescheduled, and no new ones should be started.
+            default: "active"
+            x-nullable: false
+            enum:
+              - "active"
+              - "pause"
+              - "drain"
+
+  Topology:
+    description: |
+      A map of topological domains to topological segments. For in depth
+      details, see documentation for the Topology object in the CSI
+      specification.
+    type: "object"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  ImageManifestSummary:
+    x-go-name: "ManifestSummary"
+    description: |
+      ImageManifestSummary represents a summary of an image manifest.
+    type: "object"
+    required: ["ID", "Descriptor", "Available", "Size", "Kind"]
+    properties:
+      ID:
+        description: |
+          ID is the content-addressable ID of an image and is the same as the
+          digest of the image manifest.
+        type: "string"
+        example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Available:
+        description: Indicates whether all the child content (image config, layers) is fully available locally.
+        type: "boolean"
+        example: true
+      Size:
+        type: "object"
+        x-nullable: false
+        required: ["Content", "Total"]
+        properties:
+          Total:
+            type: "integer"
+            format: "int64"
+            example: 8213251
+            description: |
+              Total is the total size (in bytes) of all the locally present
+              data (both distributable and non-distributable) that's related to
+              this manifest and its children.
+              This equal to the sum of [Content] size AND all the sizes in the
+              [Size] struct present in the Kind-specific data struct.
+              For example, for an image kind (Kind == "image")
+              this would include the size of the image content and unpacked
+              image snapshots ([Size.Content] + [ImageData.Size.Unpacked]).
+          Content:
+            description: |
+              Content is the size (in bytes) of all the locally present
+              content in the content store (e.g. image config, layers)
+              referenced by this manifest and its children.
+              This only includes blobs in the content store.
+            type: "integer"
+            format: "int64"
+            example: 3987495
+      Kind:
+        type: "string"
+        example: "image"
+        enum:
+          - "image"
+          - "attestation"
+          - "unknown"
+        description: |
+          The kind of the manifest.
+
+          kind         | description
+          -------------|-----------------------------------------------------------
+          image        | Image manifest that can be used to start a container.
+          attestation  | Attestation manifest produced by the Buildkit builder for a specific image manifest.
+      ImageData:
+        description: |
+          The image data for the image manifest.
+          This field is only populated when Kind is "image".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["Platform", "Containers", "Size", "UnpackedSize"]
+        properties:
+          Platform:
+            $ref: "#/definitions/OCIPlatform"
+            description: |
+              OCI platform of the image. This will be the platform specified in the
+              manifest descriptor from the index/manifest list.
+              If it's not available, it will be obtained from the image config.
+          Containers:
+            description: |
+              The IDs of the containers that are using this image.
+            type: "array"
+            items:
+              type: "string"
+            example: ["ede54ee1fda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c7430", "abadbce344c096744d8d6071a90d474d28af8f1034b5ea9fb03c3f4bfc6d005e"]
+          Size:
+            type: "object"
+            x-nullable: false
+            required: ["Unpacked"]
+            properties:
+              Unpacked:
+                type: "integer"
+                format: "int64"
+                example: 3987495
+                description: |
+                  Unpacked is the size (in bytes) of the locally unpacked
+                  (uncompressed) image content that's directly usable by the containers
+                  running this image.
+                  It's independent of the distributable content - e.g.
+                  the image might still have an unpacked data that's still used by
+                  some container even when the distributable/compressed content is
+                  already gone.
+      AttestationData:
+        description: |
+          The image data for the attestation manifest.
+          This field is only populated when Kind is "attestation".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["For"]
+        properties:
+          For:
+            description: |
+              The digest of the image manifest that this attestation is for.
+            type: "string"
+            example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+
+paths:
+  /containers/json:
+    get:
+      summary: "List containers"
+      description: |
+        Returns a list of containers. For details on the format, see the
+        [inspect endpoint](#operation/ContainerInspect).
+
+        Note that it uses a different, smaller representation of a container
+        than inspecting a single container. For example, the list of linked
+        containers is not propagated .
+      operationId: "ContainerList"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: |
+            Return all containers. By default, only running containers are shown.
+          type: "boolean"
+          default: false
+        - name: "limit"
+          in: "query"
+          description: |
+            Return this number of most recently created containers, including
+            non-running ones.
+          type: "integer"
+        - name: "size"
+          in: "query"
+          description: |
+            Return the size of container as fields `SizeRw` and `SizeRootFs`.
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the container list, encoded as JSON (a
+            `map[string][]string`). For example, `{"status": ["paused"]}` will
+            only return paused containers.
+
+            Available filters:
+
+            - `ancestor`=(`<image-name>[:<tag>]`, `<image id>`, or `<image@digest>`)
+            - `before`=(`<container id>` or `<container name>`)
+            - `expose`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `exited=<int>` containers with exit code of `<int>`
+            - `health`=(`starting`|`healthy`|`unhealthy`|`none`)
+            - `id=<ID>` a container's ID
+            - `isolation=`(`default`|`process`|`hyperv`) (Windows daemon only)
+            - `is-task=`(`true`|`false`)
+            - `label=key` or `label="key=value"` of a container label
+            - `name=<name>` a container's name
+            - `network`=(`<network id>` or `<network name>`)
+            - `publish`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `since`=(`<container id>` or `<container name>`)
+            - `status=`(`created`|`restarting`|`running`|`removing`|`paused`|`exited`|`dead`)
+            - `volume`=(`<volume name>` or `<mount point destination>`)
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ContainerSummary"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/create:
+    post:
+      summary: "Create a container"
+      operationId: "ContainerCreate"
+      consumes:
+        - "application/json"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            Assign the specified name to the container. Must match
+            `/?[a-zA-Z0-9][a-zA-Z0-9_.-]+`.
+          type: "string"
+          pattern: "^/?[a-zA-Z0-9][a-zA-Z0-9_.-]+$"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format `os[/arch[/variant]]` used for image lookup.
+
+            When specified, the daemon checks if the requested image is present
+            in the local image cache with the given OS and Architecture, and
+            otherwise returns a `404` status.
+
+            If the option is not set, the host's native OS and Architecture are
+            used to look up the image in the image cache. However, if no platform
+            is passed and the given image does exist in the local image cache,
+            but its OS or architecture does not match, the container is created
+            with the available image, and a warning is added to the `Warnings`
+            field in the response, for example;
+
+                WARNING: The requested image's platform (linux/arm64/v8) does not
+                         match the detected host platform (linux/amd64) and no
+                         specific platform was requested
+
+          type: "string"
+          default: ""
+        - name: "body"
+          in: "body"
+          description: "Container to create"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ContainerConfig"
+              - type: "object"
+                properties:
+                  HostConfig:
+                    $ref: "#/definitions/HostConfig"
+                  NetworkingConfig:
+                    $ref: "#/definitions/NetworkingConfig"
+            example:
+              Hostname: ""
+              Domainname: ""
+              User: ""
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              Tty: false
+              OpenStdin: false
+              StdinOnce: false
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+              Cmd:
+                - "date"
+              Entrypoint: ""
+              Image: "ubuntu"
+              Labels:
+                com.example.vendor: "Acme"
+                com.example.license: "GPL"
+                com.example.version: "1.0"
+              Volumes:
+                /volumes/data: {}
+              WorkingDir: ""
+              NetworkDisabled: false
+              ExposedPorts:
+                22/tcp: {}
+              StopSignal: "SIGTERM"
+              StopTimeout: 10
+              HostConfig:
+                Binds:
+                  - "/tmp:/tmp"
+                Links:
+                  - "redis3:redis"
+                Memory: 0
+                MemorySwap: 0
+                MemoryReservation: 0
+                NanoCpus: 500000
+                CpuPercent: 80
+                CpuShares: 512
+                CpuPeriod: 100000
+                CpuRealtimePeriod: 1000000
+                CpuRealtimeRuntime: 10000
+                CpuQuota: 50000
+                CpusetCpus: "0,1"
+                CpusetMems: "0,1"
+                MaximumIOps: 0
+                MaximumIOBps: 0
+                BlkioWeight: 300
+                BlkioWeightDevice:
+                  - {}
+                BlkioDeviceReadBps:
+                  - {}
+                BlkioDeviceReadIOps:
+                  - {}
+                BlkioDeviceWriteBps:
+                  - {}
+                BlkioDeviceWriteIOps:
+                  - {}
+                DeviceRequests:
+                  - Driver: "nvidia"
+                    Count: -1
+                    DeviceIDs": ["0", "1", "GPU-fef8089b-4820-abfc-e83e-94318197576e"]
+                    Capabilities: [["gpu", "nvidia", "compute"]]
+                    Options:
+                      property1: "string"
+                      property2: "string"
+                MemorySwappiness: 60
+                OomKillDisable: false
+                OomScoreAdj: 500
+                PidMode: ""
+                PidsLimit: 0
+                PortBindings:
+                  22/tcp:
+                    - HostPort: "11022"
+                PublishAllPorts: false
+                Privileged: false
+                ReadonlyRootfs: false
+                Dns:
+                  - "8.8.8.8"
+                DnsOptions:
+                  - ""
+                DnsSearch:
+                  - ""
+                VolumesFrom:
+                  - "parent"
+                  - "other:ro"
+                CapAdd:
+                  - "NET_ADMIN"
+                CapDrop:
+                  - "MKNOD"
+                GroupAdd:
+                  - "newgroup"
+                RestartPolicy:
+                  Name: ""
+                  MaximumRetryCount: 0
+                AutoRemove: true
+                NetworkMode: "bridge"
+                Devices: []
+                Ulimits:
+                  - {}
+                LogConfig:
+                  Type: "json-file"
+                  Config: {}
+                SecurityOpt: []
+                StorageOpt: {}
+                CgroupParent: ""
+                VolumeDriver: ""
+                ShmSize: 67108864
+              NetworkingConfig:
+                EndpointsConfig:
+                  isolated_nw:
+                    IPAMConfig:
+                      IPv4Address: "172.20.30.33"
+                      IPv6Address: "2001:db8:abcd::3033"
+                      LinkLocalIPs:
+                        - "169.254.34.68"
+                        - "fe80::3468"
+                    Links:
+                      - "container_1"
+                      - "container_2"
+                    Aliases:
+                      - "server_x"
+                      - "server_y"
+                  database_nw: {}
+
+          required: true
+      responses:
+        201:
+          description: "Container created successfully"
+          schema:
+            $ref: "#/definitions/ContainerCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/{id}/json:
+    get:
+      summary: "Inspect a container"
+      description: "Return low-level information about a container."
+      operationId: "ContainerInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerInspectResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "size"
+          in: "query"
+          type: "boolean"
+          default: false
+          description: "Return the size of container as fields `SizeRw` and `SizeRootFs`"
+      tags: ["Container"]
+  /containers/{id}/top:
+    get:
+      summary: "List processes running inside a container"
+      description: |
+        On Unix systems, this is done by running the `ps` command. This endpoint
+        is not supported on Windows.
+      operationId: "ContainerTop"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerTopResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "ps_args"
+          in: "query"
+          description: "The arguments to pass to `ps`. For example, `aux`"
+          type: "string"
+          default: "-ef"
+      tags: ["Container"]
+  /containers/{id}/logs:
+    get:
+      summary: "Get container logs"
+      description: |
+        Get `stdout` and `stderr` logs from a container.
+
+        Note: This endpoint works only for containers with the `json-file` or
+        `journald` logging driver.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ContainerLogs"
+      responses:
+        200:
+          description: |
+            logs returned as a stream in response body.
+            For the stream format, [see the documentation for the attach endpoint](#operation/ContainerAttach).
+            Note that unlike the attach endpoint, the logs endpoint does not
+            upgrade the connection and does not set Content-Type.
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "until"
+          in: "query"
+          description: "Only return logs before this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Container"]
+  /containers/{id}/changes:
+    get:
+      summary: "Get changes on a container’s filesystem"
+      description: |
+        Returns which files in a container's filesystem have been added, deleted,
+        or modified. The `Kind` of modification can be one of:
+
+        - `0`: Modified ("C")
+        - `1`: Added ("A")
+        - `2`: Deleted ("D")
+      operationId: "ContainerChanges"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The list of changes"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/FilesystemChange"
+          examples:
+            application/json:
+              - Path: "/dev"
+                Kind: 0
+              - Path: "/dev/kmsg"
+                Kind: 1
+              - Path: "/test"
+                Kind: 1
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/export:
+    get:
+      summary: "Export a container"
+      description: "Export the contents of a container as a tarball."
+      operationId: "ContainerExport"
+      produces:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stats:
+    get:
+      summary: "Get container stats based on resource usage"
+      description: |
+        This endpoint returns a live stream of a container’s resource usage
+        statistics.
+
+        The `precpu_stats` is the CPU statistic of the *previous* read, and is
+        used to calculate the CPU usage percentage. It is not an exact copy
+        of the `cpu_stats` field.
+
+        If either `precpu_stats.online_cpus` or `cpu_stats.online_cpus` is
+        nil then for compatibility with older daemons the length of the
+        corresponding `cpu_usage.percpu_usage` array should be used.
+
+        On a cgroup v2 host, the following fields are not set
+        * `blkio_stats`: all fields other than `io_service_bytes_recursive`
+        * `cpu_stats`: `cpu_usage.percpu_usage`
+        * `memory_stats`: `max_usage` and `failcnt`
+        Also, `memory_stats.stats` fields are incompatible with cgroup v1.
+
+        To calculate the values shown by the `stats` command of the docker cli tool
+        the following formulas can be used:
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
+        * available_memory = `memory_stats.limit`
+        * Memory usage % = `(used_memory / available_memory) * 100.0`
+        * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
+        * system_cpu_delta = `cpu_stats.system_cpu_usage - precpu_stats.system_cpu_usage`
+        * number_cpus = `length(cpu_stats.cpu_usage.percpu_usage)` or `cpu_stats.online_cpus`
+        * CPU usage % = `(cpu_delta / system_cpu_delta) * number_cpus * 100.0`
+      operationId: "ContainerStats"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerStatsResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream the output. If false, the stats will be output once and then
+            it will disconnect.
+          type: "boolean"
+          default: true
+        - name: "one-shot"
+          in: "query"
+          description: |
+            Only get a single stat instead of waiting for 2 cycles. Must be used
+            with `stream=false`.
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/resize:
+    post:
+      summary: "Resize a container TTY"
+      description: "Resize the TTY for a container."
+      operationId: "ContainerResize"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "cannot resize container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/start:
+    post:
+      summary: "Start a container"
+      operationId: "ContainerStart"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already started"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container. Format is a
+            single character `[a-Z]` or `ctrl-<value>` where `<value>` is one
+            of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stop:
+    post:
+      summary: "Stop a container"
+      operationId: "ContainerStop"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already stopped"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/restart:
+    post:
+      summary: "Restart a container"
+      operationId: "ContainerRestart"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/kill:
+    post:
+      summary: "Kill a container"
+      description: |
+        Send a POSIX signal to a container, defaulting to killing to the
+        container.
+      operationId: "ContainerKill"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is not running"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "Container d37cde0fe4ad63c3a7252023b2f9800282894247d145cb5933ddf6e52cc03a28 is not running"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+          default: "SIGKILL"
+      tags: ["Container"]
+  /containers/{id}/update:
+    post:
+      summary: "Update a container"
+      description: |
+        Change various configuration options of a container without having to
+        recreate it.
+      operationId: "ContainerUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has been updated."
+          schema:
+            $ref: "#/definitions/ContainerUpdateResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "update"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/Resources"
+              - type: "object"
+                properties:
+                  RestartPolicy:
+                    $ref: "#/definitions/RestartPolicy"
+            example:
+              BlkioWeight: 300
+              CpuShares: 512
+              CpuPeriod: 100000
+              CpuQuota: 50000
+              CpuRealtimePeriod: 1000000
+              CpuRealtimeRuntime: 10000
+              CpusetCpus: "0,1"
+              CpusetMems: "0"
+              Memory: 314572800
+              MemorySwap: 514288000
+              MemoryReservation: 209715200
+              RestartPolicy:
+                MaximumRetryCount: 4
+                Name: "on-failure"
+      tags: ["Container"]
+  /containers/{id}/rename:
+    post:
+      summary: "Rename a container"
+      operationId: "ContainerRename"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "name already in use"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "name"
+          in: "query"
+          required: true
+          description: "New name for the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/pause:
+    post:
+      summary: "Pause a container"
+      description: |
+        Use the freezer cgroup to suspend all processes in a container.
+
+        Traditionally, when suspending a process the `SIGSTOP` signal is used,
+        which is observable by the process being suspended. With the freezer
+        cgroup the process is unaware, and unable to capture, that it is being
+        suspended, and subsequently resumed.
+      operationId: "ContainerPause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/unpause:
+    post:
+      summary: "Unpause a container"
+      description: "Resume a container which has been paused."
+      operationId: "ContainerUnpause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/attach:
+    post:
+      summary: "Attach to a container"
+      description: |
+        Attach to a container to read its output or send it input. You can attach
+        to the same container multiple times and you can reattach to containers
+        that have been detached.
+
+        Either the `stream` or `logs` parameter must be `true` for this endpoint
+        to do anything.
+
+        See the [documentation for the `docker attach` command](https://docs.docker.com/engine/reference/commandline/attach/)
+        for more details.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to transport `stdin`, `stdout`,
+        and `stderr` on the same socket.
+
+        This is the response from the daemon for an attach request:
+
+        ```
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        [STREAM]
+        ```
+
+        After the headers and two new lines, the TCP connection can now be used
+        for raw, bidirectional communication between the client and server.
+
+        To hint potential proxies about connection hijacking, the Docker client
+        can also optionally send connection upgrade headers.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /containers/16253994b7c4/attach?stream=1&stdout=1 HTTP/1.1
+        Upgrade: tcp
+        Connection: Upgrade
+        ```
+
+        The Docker daemon will respond with a `101 UPGRADED` response, and will
+        similarly follow with the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Content-Type: application/vnd.docker.raw-stream
+        Connection: Upgrade
+        Upgrade: tcp
+
+        [STREAM]
+        ```
+
+        ### Stream format
+
+        When the TTY setting is disabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the HTTP Content-Type header is set to application/vnd.docker.multiplexed-stream
+        and the stream over the hijacked connected is multiplexed to separate out
+        `stdout` and `stderr`. The stream consists of a series of frames, each
+        containing a header and a payload.
+
+        The header contains the information which the stream writes (`stdout` or
+        `stderr`). It also contains the size of the associated frame encoded in
+        the last four bytes (`uint32`).
+
+        It is encoded on the first eight bytes like this:
+
+        ```go
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+        ```
+
+        `STREAM_TYPE` can be:
+
+        - 0: `stdin` (is written on `stdout`)
+        - 1: `stdout`
+        - 2: `stderr`
+
+        `SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of the `uint32` size
+        encoded as big endian.
+
+        Following the header is the payload, which is the specified number of
+        bytes of `STREAM_TYPE`.
+
+        The simplest way to implement this protocol is the following:
+
+        1. Read 8 bytes.
+        2. Choose `stdout` or `stderr` depending on the first byte.
+        3. Extract the frame size from the last four bytes.
+        4. Read the extracted size and output it on the correct output.
+        5. Goto 1.
+
+        ### Stream format when using a TTY
+
+        When the TTY setting is enabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the stream is not multiplexed. The data exchanged over the hijacked
+        connection is simply the raw data from the process PTY and client's
+        `stdin`.
+
+      operationId: "ContainerAttach"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: |
+            Replay previous logs from the container.
+
+            This is useful for attaching to a container that has started and you
+            want to output everything since the container started.
+
+            If `stream` is also enabled, once all the previous output has been
+            returned, it will seamlessly transition into streaming current
+            output.
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream attached streams from the time the request was made onwards.
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/attach/ws:
+    get:
+      summary: "Attach to a container via a websocket"
+      operationId: "ContainerAttachWebsocket"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,`, or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: "Return logs"
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: "Return stream"
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/wait:
+    post:
+      summary: "Wait for a container"
+      description: "Block until a container stops, then returns the exit code."
+      operationId: "ContainerWait"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has exit."
+          schema:
+            $ref: "#/definitions/ContainerWaitResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "condition"
+          in: "query"
+          description: |
+            Wait until a container state reaches the given condition.
+
+            Defaults to `not-running` if omitted or empty.
+          type: "string"
+          enum:
+            - "not-running"
+            - "next-exit"
+            - "removed"
+          default: "not-running"
+      tags: ["Container"]
+  /containers/{id}:
+    delete:
+      summary: "Remove a container"
+      operationId: "ContainerDelete"
+      responses:
+        204:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: |
+                You cannot remove a running container: c2ada9df5af8. Stop the
+                container before attempting removal or force remove
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "v"
+          in: "query"
+          description: "Remove anonymous volumes associated with the container."
+          type: "boolean"
+          default: false
+        - name: "force"
+          in: "query"
+          description: "If the container is running, kill it before removing it."
+          type: "boolean"
+          default: false
+        - name: "link"
+          in: "query"
+          description: "Remove the specified link associated with the container."
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/archive:
+    head:
+      summary: "Get information about files in a container"
+      description: |
+        A response header `X-Docker-Container-Path-Stat` is returned, containing
+        a base64 - encoded JSON object with some filesystem header information
+        about the path.
+      operationId: "ContainerArchiveInfo"
+      responses:
+        200:
+          description: "no error"
+          headers:
+            X-Docker-Container-Path-Stat:
+              type: "string"
+              description: |
+                A base64 - encoded JSON object with some filesystem header
+                information about the path
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    get:
+      summary: "Get an archive of a filesystem resource in a container"
+      description: "Get a tar archive of a resource in the filesystem of container id."
+      operationId: "ContainerArchive"
+      produces: ["application/x-tar"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    put:
+      summary: "Extract an archive of files or folders to a directory in a container"
+      description: |
+        Upload a tar archive to be extracted to a path in the filesystem of container id.
+        `path` parameter is asserted to be a directory. If it exists as a file, 400 error
+        will be returned with message "not a directory".
+      operationId: "PutContainerArchive"
+      consumes: ["application/x-tar", "application/octet-stream"]
+      responses:
+        200:
+          description: "The content was extracted successfully"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "not a directory"
+        403:
+          description: "Permission denied, the volume or container rootfs is marked as read-only."
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such container or path does not exist inside the container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Path to a directory in the container to extract the archive’s contents into. "
+          type: "string"
+        - name: "noOverwriteDirNonDir"
+          in: "query"
+          description: |
+            If `1`, `true`, or `True` then it will be an error if unpacking the
+            given content would cause an existing directory to be replaced with
+            a non-directory and vice versa.
+          type: "string"
+        - name: "copyUIDGID"
+          in: "query"
+          description: |
+            If `1`, `true`, then it will copy UID/GID maps to the dest file or
+            dir
+          type: "string"
+        - name: "inputStream"
+          in: "body"
+          required: true
+          description: |
+            The input stream must be a tar archive compressed with one of the
+            following algorithms: `identity` (no compression), `gzip`, `bzip2`,
+            or `xz`.
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Container"]
+  /containers/prune:
+    post:
+      summary: "Delete stopped containers"
+      produces:
+        - "application/json"
+      operationId: "ContainerPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune containers created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune containers with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ContainerPruneResponse"
+            properties:
+              ContainersDeleted:
+                description: "Container IDs that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /images/json:
+    get:
+      summary: "List Images"
+      description: "Returns a list of images on the server. Note that it uses a different, smaller representation of an image than inspecting a single image."
+      operationId: "ImageList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "Summary image data for the images matching the query"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageSummary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: "Show all images. Only images from a final layer (no children) are shown by default."
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the images list.
+
+            Available filters:
+
+            - `before`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `dangling=true`
+            - `label=key` or `label="key=value"` of an image label
+            - `reference`=(`<image-name>[:<tag>]`)
+            - `since`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `until=<timestamp>`
+          type: "string"
+        - name: "shared-size"
+          in: "query"
+          description: "Compute and show shared size as a `SharedSize` field on each image."
+          type: "boolean"
+          default: false
+        - name: "digests"
+          in: "query"
+          description: "Show digest information as a `RepoDigests` field on each image."
+          type: "boolean"
+          default: false
+        - name: "manifests"
+          in: "query"
+          description: "Include `Manifests` in the image summary."
+          type: "boolean"
+          default: false
+      tags: ["Image"]
+  /build:
+    post:
+      summary: "Build an image"
+      description: |
+        Build an image from a tar archive with a `Dockerfile` in it.
+
+        The `Dockerfile` specifies how the image is built from the tar archive. It is typically in the archive's root, but can be at a different path or have a different name by specifying the `dockerfile` parameter. [See the `Dockerfile` reference for more information](https://docs.docker.com/engine/reference/builder/).
+
+        The Docker daemon performs a preliminary validation of the `Dockerfile` before starting the build, and returns an error if the syntax is incorrect. After that, each instruction is run one-by-one until the ID of the new image is output.
+
+        The build is canceled if the client drops the connection by quitting or being killed.
+      operationId: "ImageBuild"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "inputStream"
+          in: "body"
+          description: "A tar archive compressed with one of the following algorithms: identity (no compression), gzip, bzip2, xz."
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "dockerfile"
+          in: "query"
+          description: "Path within the build context to the `Dockerfile`. This is ignored if `remote` is specified and points to an external `Dockerfile`."
+          type: "string"
+          default: "Dockerfile"
+        - name: "t"
+          in: "query"
+          description: "A name and optional tag to apply to the image in the `name:tag` format. If you omit the tag the default `latest` value is assumed. You can provide several `t` parameters."
+          type: "string"
+        - name: "extrahosts"
+          in: "query"
+          description: "Extra hosts to add to /etc/hosts"
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: "A Git repository URI or HTTP/HTTPS context URI. If the URI points to a single text file, the file’s contents are placed into a file called `Dockerfile` and the image is built from that file. If the URI points to a tarball, the file is downloaded by the daemon and the contents therein used as the context for the build. If the URI points to a tarball and the `dockerfile` parameter is also specified, there must be a file with the corresponding path inside the tarball."
+          type: "string"
+        - name: "q"
+          in: "query"
+          description: "Suppress verbose build output."
+          type: "boolean"
+          default: false
+        - name: "nocache"
+          in: "query"
+          description: "Do not use the cache when building the image."
+          type: "boolean"
+          default: false
+        - name: "cachefrom"
+          in: "query"
+          description: "JSON array of images used for build cache resolution."
+          type: "string"
+        - name: "pull"
+          in: "query"
+          description: "Attempt to pull the image even if an older image exists locally."
+          type: "string"
+        - name: "rm"
+          in: "query"
+          description: "Remove intermediate containers after a successful build."
+          type: "boolean"
+          default: true
+        - name: "forcerm"
+          in: "query"
+          description: "Always remove intermediate containers, even upon failure."
+          type: "boolean"
+          default: false
+        - name: "memory"
+          in: "query"
+          description: "Set memory limit for build."
+          type: "integer"
+        - name: "memswap"
+          in: "query"
+          description: "Total memory (memory + swap). Set as `-1` to disable swap."
+          type: "integer"
+        - name: "cpushares"
+          in: "query"
+          description: "CPU shares (relative weight)."
+          type: "integer"
+        - name: "cpusetcpus"
+          in: "query"
+          description: "CPUs in which to allow execution (e.g., `0-3`, `0,1`)."
+          type: "string"
+        - name: "cpuperiod"
+          in: "query"
+          description: "The length of a CPU period in microseconds."
+          type: "integer"
+        - name: "cpuquota"
+          in: "query"
+          description: "Microseconds of CPU time that the container can get in a CPU period."
+          type: "integer"
+        - name: "buildargs"
+          in: "query"
+          description: >
+            JSON map of string pairs for build-time variables. Users pass these values at build-time. Docker
+            uses the buildargs as the environment context for commands run via the `Dockerfile` RUN
+            instruction, or for variable expansion in other `Dockerfile` instructions. This is not meant for
+            passing secret values.
+
+
+            For example, the build arg `FOO=bar` would become `{"FOO":"bar"}` in JSON. This would result in the
+            query parameter `buildargs={"FOO":"bar"}`. Note that `{"FOO":"bar"}` should be URI component encoded.
+
+
+            [Read more about the buildargs instruction.](https://docs.docker.com/engine/reference/builder/#arg)
+          type: "string"
+        - name: "shmsize"
+          in: "query"
+          description: "Size of `/dev/shm` in bytes. The size must be greater than 0. If omitted the system uses 64MB."
+          type: "integer"
+        - name: "squash"
+          in: "query"
+          description: "Squash the resulting images layers into a single layer. *(Experimental release only.)*"
+          type: "boolean"
+        - name: "labels"
+          in: "query"
+          description: "Arbitrary key/value labels to set on the image, as a JSON map of string pairs."
+          type: "string"
+        - name: "networkmode"
+          in: "query"
+          description: |
+            Sets the networking mode for the run commands during build. Supported
+            standard values are: `bridge`, `host`, `none`, and `container:<name|id>`.
+            Any other value is taken as a custom network's name or ID to which this
+            container should connect to.
+          type: "string"
+        - name: "Content-type"
+          in: "header"
+          type: "string"
+          enum:
+            - "application/x-tar"
+          default: "application/x-tar"
+        - name: "X-Registry-Config"
+          in: "header"
+          description: |
+            This is a base64-encoded JSON object with auth configurations for multiple registries that a build may refer to.
+
+            The key is a registry URL, and the value is an auth configuration object, [as described in the authentication section](#section/Authentication). For example:
+
+            ```
+            {
+              "docker.example.com": {
+                "username": "janedoe",
+                "password": "hunter2"
+              },
+              "https://index.docker.io/v1/": {
+                "username": "mobydock",
+                "password": "conta1n3rize14"
+              }
+            }
+            ```
+
+            Only the registry domain name (and port if not the default 443) are required. However, for legacy reasons, the Docker Hub registry must be specified with both a `https://` prefix and a `/v1/` suffix even though Docker will prefer to use the v2 registry API.
+          type: "string"
+        - name: "platform"
+          in: "query"
+          description: "Platform in the format os[/arch[/variant]]"
+          type: "string"
+          default: ""
+        - name: "target"
+          in: "query"
+          description: "Target build stage"
+          type: "string"
+          default: ""
+        - name: "outputs"
+          in: "query"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
+          type: "string"
+          default: ""
+        - name: "version"
+          in: "query"
+          type: "string"
+          default: "1"
+          enum: ["1", "2"]
+          description: |
+            Version of the builder backend to use.
+
+            - `1` is the first generation classic (deprecated) builder in the Docker daemon (default)
+            - `2` is [BuildKit](https://github.com/moby/buildkit)
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /build/prune:
+    post:
+      summary: "Delete builder cache"
+      produces:
+        - "application/json"
+      operationId: "BuildPrune"
+      parameters:
+        - name: "reserved-space"
+          in: "query"
+          description: "Amount of disk space in bytes to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "max-used-space"
+          in: "query"
+          description: "Maximum amount of disk space allowed to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "min-free-space"
+          in: "query"
+          description: "Target amount of free disk space after pruning"
+          type: "integer"
+          format: "int64"
+        - name: "all"
+          in: "query"
+          type: "boolean"
+          description: "Remove all types of build cache"
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the list of build cache objects.
+
+            Available filters:
+
+            - `until=<timestamp>` remove cache older than `<timestamp>`. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon's local time.
+            - `id=<id>`
+            - `parent=<id>`
+            - `type=<string>`
+            - `description=<string>`
+            - `inuse`
+            - `shared`
+            - `private`
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "BuildPruneResponse"
+            properties:
+              CachesDeleted:
+                type: "array"
+                items:
+                  description: "ID of build cache object"
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /images/create:
+    post:
+      summary: "Create an image"
+      description: "Pull or import an image."
+      operationId: "ImageCreate"
+      consumes:
+        - "text/plain"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "repository does not exist or no read access"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "fromImage"
+          in: "query"
+          description: |
+            Name of the image to pull. If the name includes a tag or digest, specific behavior applies:
+
+            - If only `fromImage` includes a tag, that tag is used.
+            - If both `fromImage` and `tag` are provided, `tag` takes precedence.
+            - If `fromImage` includes a digest, the image is pulled by digest, and `tag` is ignored.
+            - If neither a tag nor digest is specified, all tags are pulled.
+          type: "string"
+        - name: "fromSrc"
+          in: "query"
+          description: "Source to import. The value may be a URL from which the image can be retrieved or `-` to read the image from the request body. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name given to an image when it is imported. The repo may include a tag. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag or digest. If empty when pulling an image, this causes all tags for the given image to be pulled."
+          type: "string"
+        - name: "message"
+          in: "query"
+          description: "Set commit message for imported image."
+          type: "string"
+        - name: "inputImage"
+          in: "body"
+          description: "Image content if the value `-` has been specified in fromSrc query parameter"
+          schema:
+            type: "string"
+          required: false
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "changes"
+          in: "query"
+          description: |
+            Apply `Dockerfile` instructions to the image that is created,
+            for example: `changes=ENV DEBUG=true`.
+            Note that `ENV DEBUG=true` should be URI component encoded.
+
+            Supported `Dockerfile` instructions:
+            `CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format os[/arch[/variant]].
+
+            When used in combination with the `fromImage` option, the daemon checks
+            if the given image is present in the local image cache with the given
+            OS and Architecture, and otherwise attempts to pull the image. If the
+            option is not set, the host's native OS and Architecture are used.
+            If the given image does not exist in the local image cache, the daemon
+            attempts to pull the image with the host's native OS and Architecture.
+            If the given image does exists in the local image cache, but its OS or
+            architecture does not match, a warning is produced.
+
+            When used with the `fromSrc` option to import an image from an archive,
+            this option sets the platform information for the imported image. If
+            the option is not set, the host's native OS and Architecture are used
+            for the imported image.
+          type: "string"
+          default: ""
+      tags: ["Image"]
+  /images/{name}/json:
+    get:
+      summary: "Inspect an image"
+      description: "Return low-level information about an image."
+      operationId: "ImageInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/ImageInspect"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+        - name: "manifests"
+          in: "query"
+          description: |-
+            Include Manifests in the image summary.
+
+            The `manifests` and `platform` options are mutually exclusive, and
+            an error is produced if both are set.
+          type: "boolean"
+          default: false
+          required: false
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |-
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show inspect. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            The `platform` and `manifests` options are mutually exclusive, and
+            an error is produced if both are set.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/history:
+    get:
+      summary: "Get the history of an image"
+      description: "Return parent layers of an image."
+      operationId: "ImageHistory"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "List of image layers"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageHistoryResponseItem"
+          examples:
+            application/json:
+              - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
+                Created: 1398108230
+                CreatedBy: "/bin/sh -c #(nop) ADD file:eb15dbd63394e063b805a3c32ca7bf0266ef64676d5a6fab4801f2e81e2a5148 in /"
+                Tags:
+                  - "ubuntu:lucid"
+                  - "ubuntu:10.04"
+                Size: 182964289
+                Comment: ""
+              - Id: "6cfa4d1f33fb861d4d114f43b25abd0ac737509268065cdfd69d544a59c85ab8"
+                Created: 1398108222
+                CreatedBy: "/bin/sh -c #(nop) MAINTAINER Tianon Gravi <admwiggin@gmail.com> - mkimage-debootstrap.sh -i iproute,iputils-ping,ubuntu-minimal -t lucid.tar.xz lucid http://archive.ubuntu.com/ubuntu/"
+                Tags: []
+                Size: 0
+                Comment: ""
+              - Id: "511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158"
+                Created: 1371157430
+                CreatedBy: ""
+                Tags:
+                  - "scratch12:latest"
+                  - "scratch:latest"
+                Size: 0
+                Comment: "Imported from -"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show the history for. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/push:
+    post:
+      summary: "Push an image"
+      description: |
+        Push an image to a registry.
+
+        If you wish to push an image on to a private registry, that image must
+        already have a tag which references the registry. For example,
+        `registry.example.com/myimage:latest`.
+
+        The push is cancelled if the HTTP connection is closed.
+      operationId: "ImagePush"
+      consumes:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            Name of the image to push. For example, `registry.example.com/myimage`.
+            The image must be present in the local image store with the same name.
+
+            The name should be provided without tag; if a tag is provided, it
+            is ignored. For example, `registry.example.com/myimage:latest` is
+            considered equivalent to `registry.example.com/myimage`.
+
+            Use the `tag` parameter to specify the tag to push.
+          type: "string"
+          required: true
+        - name: "tag"
+          in: "query"
+          description: |
+            Tag of the image to push. For example, `latest`. If no tag is provided,
+            all tags of the given image that are present in the local image store
+            are pushed.
+          type: "string"
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant to push.
+            If not provided, all available variants will attempt to be pushed.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to push to the registry. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+          required: true
+      tags: ["Image"]
+  /images/{name}/tag:
+    post:
+      summary: "Tag an image"
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
+      operationId: "ImageTag"
+      responses:
+        201:
+          description: "No error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID to tag."
+          type: "string"
+          required: true
+        - name: "repo"
+          in: "query"
+          description: "The repository to tag in. For example, `someuser/someimage`."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "The name of the new tag."
+          type: "string"
+      tags: ["Image"]
+  /images/{name}:
+    delete:
+      summary: "Remove an image"
+      description: |
+        Remove an image, along with any untagged parent images that were
+        referenced by that image.
+
+        Images can't be removed if they have descendant images, are being
+        used by a running container or are being used by a build.
+      operationId: "ImageDelete"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The image was deleted successfully"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageDeleteResponseItem"
+          examples:
+            application/json:
+              - Untagged: "3e2f21a89f"
+              - Deleted: "3e2f21a89f"
+              - Deleted: "53b4f83ac9"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Remove the image even if it is being used by stopped containers or has other tags"
+          type: "boolean"
+          default: false
+        - name: "noprune"
+          in: "query"
+          description: "Do not delete untagged parent images"
+          type: "boolean"
+          default: false
+        - name: "platforms"
+          in: "query"
+          description: |
+            Select platform-specific content to delete.
+            Multiple values are accepted.
+            Each platform is a OCI platform encoded as a JSON string.
+          type: "array"
+          items:
+            # This should be OCIPlatform
+            # but $ref is not supported for array in query in Swagger 2.0
+            # $ref: "#/definitions/OCIPlatform"
+            type: "string"
+      tags: ["Image"]
+  /images/search:
+    get:
+      summary: "Search images"
+      description: "Search for an image on Docker Hub."
+      operationId: "ImageSearch"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              type: "object"
+              title: "ImageSearchResponseItem"
+              properties:
+                description:
+                  type: "string"
+                is_official:
+                  type: "boolean"
+                is_automated:
+                  description: |
+                    Whether this repository has automated builds enabled.
+
+                    <p><br /></p>
+
+                    > **Deprecated**: This field is deprecated and will always be "false".
+                  type: "boolean"
+                  example: false
+                name:
+                  type: "string"
+                star_count:
+                  type: "integer"
+          examples:
+            application/json:
+              - description: "A minimal Docker image based on Alpine Linux with a complete package index and only 5 MB in size!"
+                is_official: true
+                is_automated: false
+                name: "alpine"
+                star_count: 10093
+              - description: "Busybox base image."
+                is_official: true
+                is_automated: false
+                name: "Busybox base image."
+                star_count: 3037
+              - description: "The PostgreSQL object-relational database system provides reliability and data integrity."
+                is_official: true
+                is_automated: false
+                name: "postgres"
+                star_count: 12408
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "term"
+          in: "query"
+          description: "Term to search"
+          type: "string"
+          required: true
+        - name: "limit"
+          in: "query"
+          description: "Maximum number of results to return"
+          type: "integer"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to process on the images list. Available filters:
+
+            - `is-official=(true|false)`
+            - `stars=<number>` Matches images that has at least 'number' stars.
+          type: "string"
+      tags: ["Image"]
+  /images/prune:
+    post:
+      summary: "Delete unused images"
+      produces:
+        - "application/json"
+      operationId: "ImagePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`). Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), prune only
+               unused *and* untagged images. When set to `false`
+               (or `0`), all unused images are pruned.
+            - `until=<string>` Prune images created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune images with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ImagePruneResponse"
+            properties:
+              ImagesDeleted:
+                description: "Images that were deleted"
+                type: "array"
+                items:
+                  $ref: "#/definitions/ImageDeleteResponseItem"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /auth:
+    post:
+      summary: "Check auth configuration"
+      description: |
+        Validate credentials for a registry and, if available, get an identity
+        token for accessing the registry without password.
+      operationId: "SystemAuth"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "An identity token was generated successfully."
+          schema:
+            $ref: "#/definitions/AuthResponse"
+        204:
+          description: "No error"
+        401:
+          description: "Auth error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "authConfig"
+          in: "body"
+          description: "Authentication to check"
+          schema:
+            $ref: "#/definitions/AuthConfig"
+      tags: ["System"]
+  /info:
+    get:
+      summary: "Get system information"
+      operationId: "SystemInfo"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/SystemInfo"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /version:
+    get:
+      summary: "Get version"
+      description: "Returns the version of Docker that is running and various information about the system that Docker is running on."
+      operationId: "SystemVersion"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/SystemVersion"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /_ping:
+    get:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPing"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "OK"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: |
+                Default version of docker image builder
+
+                The default on Linux is version "2" (BuildKit), but the daemon
+                can be configured to recommend version "1" (classic Builder).
+                Windows does not yet support BuildKit for native Windows images,
+                and uses "1" (classic builder) as a default.
+
+                This value is a recommendation as advertised by the daemon, and
+                it is up to the client to choose which builder to use.
+              default: "2"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          headers:
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+      tags: ["System"]
+    head:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPingHead"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "(empty)"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: "Default version of docker image builder"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /commit:
+    post:
+      summary: "Create a new image from a container"
+      operationId: "ImageCommit"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "containerConfig"
+          in: "body"
+          description: "The container configuration"
+          schema:
+            $ref: "#/definitions/ContainerConfig"
+        - name: "container"
+          in: "query"
+          description: "The ID or name of the container to commit"
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name for the created image"
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag name for the create image"
+          type: "string"
+        - name: "comment"
+          in: "query"
+          description: "Commit message"
+          type: "string"
+        - name: "author"
+          in: "query"
+          description: "Author of the image (e.g., `John Hannibal Smith <hannibal@a-team.com>`)"
+          type: "string"
+        - name: "pause"
+          in: "query"
+          description: "Whether to pause the container before committing"
+          type: "boolean"
+          default: true
+        - name: "changes"
+          in: "query"
+          description: "`Dockerfile` instructions to apply while committing"
+          type: "string"
+      tags: ["Image"]
+  /events:
+    get:
+      summary: "Monitor events"
+      description: |
+        Stream real-time events from the server.
+
+        Various objects within Docker report events when something happens to them.
+
+        Containers report these events: `attach`, `commit`, `copy`, `create`, `destroy`, `detach`, `die`, `exec_create`, `exec_detach`, `exec_start`, `exec_die`, `export`, `health_status`, `kill`, `oom`, `pause`, `rename`, `resize`, `restart`, `start`, `stop`, `top`, `unpause`, `update`, and `prune`
+
+        Images report these events: `create`, `delete`, `import`, `load`, `pull`, `push`, `save`, `tag`, `untag`, and `prune`
+
+        Volumes report these events: `create`, `mount`, `unmount`, `destroy`, and `prune`
+
+        Networks report these events: `create`, `connect`, `disconnect`, `destroy`, `update`, `remove`, and `prune`
+
+        The Docker daemon reports these events: `reload`
+
+        Services report these events: `create`, `update`, and `remove`
+
+        Nodes report these events: `create`, `update`, and `remove`
+
+        Secrets report these events: `create`, `update`, and `remove`
+
+        Configs report these events: `create`, `update`, and `remove`
+
+        The Builder reports `prune` events
+
+      operationId: "SystemEvents"
+      produces:
+        - "application/jsonl"
+        - "application/x-ndjson"
+        - "application/json-seq"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/EventMessage"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "since"
+          in: "query"
+          description: "Show events created since this timestamp then stream new events."
+          type: "string"
+        - name: "until"
+          in: "query"
+          description: "Show events created until this timestamp then stop streaming."
+          type: "string"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of filters (a `map[string][]string`) to process on the event list. Available filters:
+
+            - `config=<string>` config name or ID
+            - `container=<string>` container name or ID
+            - `daemon=<string>` daemon name or ID
+            - `event=<string>` event type
+            - `image=<string>` image name or ID
+            - `label=<string>` image or container label
+            - `network=<string>` network name or ID
+            - `node=<string>` node ID
+            - `plugin`=<string> plugin name or ID
+            - `scope`=<string> local or swarm
+            - `secret=<string>` secret name or ID
+            - `service=<string>` service name or ID
+            - `type=<string>` object to filter by, one of `container`, `image`, `volume`, `network`, `daemon`, `plugin`, `node`, `service`, `secret` or `config`
+            - `volume=<string>` volume name
+          type: "string"
+      tags: ["System"]
+  /system/df:
+    get:
+      summary: "Get data usage information"
+      operationId: "SystemDataUsage"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "SystemDataUsageResponse"
+            properties:
+              ImageUsage:
+                $ref: "#/definitions/ImagesDiskUsage"
+              ContainerUsage:
+                $ref: "#/definitions/ContainersDiskUsage"
+              VolumeUsage:
+                $ref: "#/definitions/VolumesDiskUsage"
+              BuildCacheUsage:
+                $ref: "#/definitions/BuildCacheDiskUsage"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "type"
+          in: "query"
+          description: |
+            Object types, for which to compute and return data.
+          type: "array"
+          collectionFormat: multi
+          items:
+            type: "string"
+            enum: ["container", "image", "volume", "build-cache"]
+        - name: "verbose"
+          in: "query"
+          description: |
+            Show detailed information on space usage.
+          type: "boolean"
+          default: false
+      tags: ["System"]
+  /images/{name}/get:
+    get:
+      summary: "Export an image"
+      description: |
+        Get a tarball containing all images and metadata for a repository.
+
+        If `name` is a specific name and tag (e.g. `ubuntu:latest`), then only that image (and its parents) are returned. If `name` is an image ID, similarly only that image (and its parents) are returned, but with the exclusion of the `repositories` file in the tarball, as there were no image names referenced.
+
+        ### Image tarball format
+
+        An image tarball contains [Content as defined in the OCI Image Layout Specification](https://github.com/opencontainers/image-spec/blob/v1.1.1/image-layout.md#content).
+
+        Additionally, includes the manifest.json file associated with a backwards compatible docker save format.
+
+        If the tarball defines a repository, the tarball should also include a `repositories` file at the root that contains a list of repository and tag names mapped to layer IDs.
+
+        ```json
+        {
+          "hello-world": {
+            "latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"
+          }
+        }
+        ```
+      operationId: "ImageGet"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform describing a platform which will be used
+            to select a platform-specific image to be saved if the image is
+            multi-platform.
+            If not provided, the full multi-platform image will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/get:
+    get:
+      summary: "Export several images"
+      description: |
+        Get a tarball containing all images and metadata for several image
+        repositories.
+
+        For each value of the `names` parameter: if it is a specific name and
+        tag (e.g. `ubuntu:latest`), then only that image (and its parents) are
+        returned; if it is an image ID, similarly only that image (and its parents)
+        are returned and there would be no names referenced in the 'repositories'
+        file for this image ID.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageGetAll"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "names"
+          in: "query"
+          description: "Image names to filter by"
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform(s) which will be used to select the
+            platform-specific image(s) to be saved if the image is
+            multi-platform. If not provided, the full multi-platform image
+            will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/load:
+    post:
+      summary: "Import images"
+      description: |
+        Load a set of images and tags into a repository.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageLoad"
+      consumes:
+        - "application/x-tar"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "imagesTarball"
+          in: "body"
+          description: "Tar archive containing images"
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "quiet"
+          in: "query"
+          description: "Suppress progress details during load."
+          type: "boolean"
+          default: false
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform(s) which will be used to select the
+            platform-specific image(s) to load if the image is
+            multi-platform. If not provided, the full multi-platform image
+            will be loaded.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /containers/{id}/exec:
+    post:
+      summary: "Create an exec instance"
+      description: "Run a command inside a running container."
+      operationId: "ContainerExec"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execConfig"
+          in: "body"
+          description: "Exec configuration"
+          schema:
+            type: "object"
+            title: "ExecConfig"
+            properties:
+              AttachStdin:
+                type: "boolean"
+                description: "Attach to `stdin` of the exec command."
+              AttachStdout:
+                type: "boolean"
+                description: "Attach to `stdout` of the exec command."
+              AttachStderr:
+                type: "boolean"
+                description: "Attach to `stderr` of the exec command."
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+              DetachKeys:
+                type: "string"
+                description: |
+                  Override the key sequence for detaching a container. Format is
+                  a single character `[a-Z]` or `ctrl-<value>` where `<value>`
+                  is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+              Env:
+                description: |
+                  A list of environment variables in the form `["VAR=value", ...]`.
+                type: "array"
+                items:
+                  type: "string"
+              Cmd:
+                type: "array"
+                description: "Command to run, as a string or array of strings."
+                items:
+                  type: "string"
+              Privileged:
+                type: "boolean"
+                description: "Runs the exec process with extended privileges."
+                default: false
+              User:
+                type: "string"
+                description: |
+                  The user, and optionally, group to run the exec process inside
+                  the container. Format is one of: `user`, `user:group`, `uid`,
+                  or `uid:gid`.
+              WorkingDir:
+                type: "string"
+                description: |
+                  The working directory for the exec process inside the container.
+            example:
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              DetachKeys: "ctrl-p,ctrl-q"
+              Tty: false
+              Cmd:
+                - "date"
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+          required: true
+        - name: "id"
+          in: "path"
+          description: "ID or name of container"
+          type: "string"
+          required: true
+      tags: ["Exec"]
+  /exec/{id}/start:
+    post:
+      summary: "Start an exec instance"
+      description: |
+        Starts a previously set up exec instance. If detach is true, this endpoint
+        returns immediately after starting the command. Otherwise, it sets up an
+        interactive session with the command.
+      operationId: "ExecStart"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Container is stopped or paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execStartConfig"
+          in: "body"
+          schema:
+            type: "object"
+            title: "ExecStartConfig"
+            properties:
+              Detach:
+                type: "boolean"
+                description: "Detach from the command."
+                example: false
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+                example: true
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+  /exec/{id}/resize:
+    post:
+      summary: "Resize an exec instance"
+      description: |
+        Resize the TTY session used by an exec instance. This endpoint only works
+        if `tty` was specified as part of creating and starting the exec instance.
+      operationId: "ExecResize"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Exec"]
+  /exec/{id}/json:
+    get:
+      summary: "Inspect an exec instance"
+      description: "Return low-level information about an exec instance."
+      operationId: "ExecInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ExecInspectResponse"
+            properties:
+              CanRemove:
+                type: "boolean"
+              DetachKeys:
+                type: "string"
+              ID:
+                type: "string"
+              Running:
+                type: "boolean"
+              ExitCode:
+                type: "integer"
+              ProcessConfig:
+                $ref: "#/definitions/ProcessConfig"
+              OpenStdin:
+                type: "boolean"
+              OpenStderr:
+                type: "boolean"
+              OpenStdout:
+                type: "boolean"
+              ContainerID:
+                type: "string"
+              Pid:
+                type: "integer"
+                description: "The system process ID for the exec process."
+          examples:
+            application/json:
+              CanRemove: false
+              ContainerID: "b53ee82b53a40c7dca428523e34f741f3abc51d9f297a14ff874bf761b995126"
+              DetachKeys: ""
+              ExitCode: 2
+              ID: "f33bbfb39f5b142420f4759b2348913bd4a8d1a6d7fd56499cb41a1bb91d7b3b"
+              OpenStderr: true
+              OpenStdin: true
+              OpenStdout: true
+              ProcessConfig:
+                arguments:
+                  - "-c"
+                  - "exit 2"
+                entrypoint: "sh"
+                privileged: false
+                tty: true
+                user: "1000"
+              Running: false
+              Pid: 42000
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+
+  /volumes:
+    get:
+      summary: "List volumes"
+      operationId: "VolumeList"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "Summary volume data that matches the query"
+          schema:
+            $ref: "#/definitions/VolumeListResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to
+            process on the volumes list. Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               volumes that are not in use by a container. When set to `false`
+               (or `0`), only volumes that are in use by one or more
+               containers are returned.
+            - `driver=<volume-driver-name>` Matches volumes based on their driver.
+            - `label=<key>` or `label=<key>:<value>` Matches volumes based on
+               the presence of a `label` alone or a `label` and a value.
+            - `name=<volume-name>` Matches all or part of a volume name.
+          type: "string"
+          format: "json"
+      tags: ["Volume"]
+
+  /volumes/create:
+    post:
+      summary: "Create a volume"
+      operationId: "VolumeCreate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        201:
+          description: "The volume was created successfully"
+          schema:
+            $ref: "#/definitions/Volume"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "volumeConfig"
+          in: "body"
+          required: true
+          description: "Volume configuration"
+          schema:
+            $ref: "#/definitions/VolumeCreateRequest"
+      tags: ["Volume"]
+
+  /volumes/{name}:
+    get:
+      summary: "Inspect a volume"
+      operationId: "VolumeInspect"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/Volume"
+        404:
+          description: "No such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+      tags: ["Volume"]
+
+    put:
+      summary: |
+        "Update a volume. Valid only for Swarm cluster volumes"
+      operationId: "VolumeUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "The name or ID of the volume"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            # though the schema for is an object that contains only a
+            # ClusterVolumeSpec, wrapping the ClusterVolumeSpec in this object
+            # means that if, later on, we support things like changing the
+            # labels, we can do so without duplicating that information to the
+            # ClusterVolumeSpec.
+            type: "object"
+            description: "Volume configuration"
+            properties:
+              Spec:
+                $ref: "#/definitions/ClusterVolumeSpec"
+          description: |
+            The spec of the volume to update. Currently, only Availability may
+            change. All other fields must remain unchanged.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the volume being updated. This is required to
+            avoid conflicting writes. Found in the volume's `ClusterVolume`
+            field.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Volume"]
+
+    delete:
+      summary: "Remove a volume"
+      description: "Instruct the driver to remove the volume."
+      operationId: "VolumeDelete"
+      responses:
+        204:
+          description: "The volume was removed"
+        404:
+          description: "No such volume or volume driver"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Volume is in use and cannot be removed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: "Force the removal of the volume"
+          type: "boolean"
+          default: false
+      tags: ["Volume"]
+
+  /volumes/prune:
+    post:
+      summary: "Delete unused volumes"
+      produces:
+        - "application/json"
+      operationId: "VolumePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune volumes with (or without, in case `label!=...` is used) the specified labels.
+            - `all` (`all=true`) - Consider all (local) volumes for pruning and not just anonymous volumes.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "VolumePruneResponse"
+            properties:
+              VolumesDeleted:
+                description: "Volumes that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Volume"]
+  /networks:
+    get:
+      summary: "List networks"
+      description: |
+        Returns a list of networks. For details on the format, see the
+        [network inspect endpoint](#operation/NetworkInspect).
+
+        Note that it uses a different, smaller representation of a network than
+        inspecting a single network. For example, the list of containers attached
+        to the network is not propagated in API versions 1.28 and up.
+      operationId: "NetworkList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/NetworkSummary"
+          examples:
+            application/json:
+              - Name: "bridge"
+                Id: "f2de39df4171b0dc801e8002d1d999b77256983dfc63041c0f34030aa3977566"
+                Created: "2016-10-19T06:21:00.416543526Z"
+                Scope: "local"
+                Driver: "bridge"
+                EnableIPv4: true
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config:
+                    -
+                      Subnet: "172.17.0.0/16"
+                Options:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              - Name: "none"
+                Id: "e086a3893b05ab69242d3c44e49483a3bbbd3a26b46baa8f61ab797c1088d794"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "null"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+              - Name: "host"
+                Id: "13e871235c677f196c4e1ecebb9dc733b9b2d2ab589e30c539efeda84a24215e"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "host"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to process
+            on the networks list.
+
+            Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               networks that are not in use by a container. When set to `false`
+               (or `0`), only networks that are in use by one or more
+               containers are returned.
+            - `driver=<driver-name>` Matches a network's driver.
+            - `id=<network-id>` Matches all or part of a network ID.
+            - `label=<key>` or `label=<key>=<value>` of a network label.
+            - `name=<network-name>` Matches all or part of a network name.
+            - `scope=["swarm"|"global"|"local"]` Filters networks by scope (`swarm`, `global`, or `local`).
+            - `type=["custom"|"builtin"]` Filters networks by type. The `custom` keyword returns all user-defined networks.
+          type: "string"
+      tags: ["Network"]
+
+  /networks/{id}:
+    get:
+      summary: "Inspect a network"
+      operationId: "NetworkInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/NetworkInspect"
+        404:
+          description: "Network not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "verbose"
+          in: "query"
+          description: "Detailed inspect output for troubleshooting"
+          type: "boolean"
+          default: false
+        - name: "scope"
+          in: "query"
+          description: "Filter the network by scope (swarm, global, or local)"
+          type: "string"
+      tags: ["Network"]
+
+    delete:
+      summary: "Remove a network"
+      operationId: "NetworkDelete"
+      responses:
+        204:
+          description: "No error"
+        403:
+          description: "operation not supported for pre-defined networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such network"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+      tags: ["Network"]
+
+  /networks/create:
+    post:
+      summary: "Create a network"
+      operationId: "NetworkCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "Network created successfully"
+          schema:
+            $ref: "#/definitions/NetworkCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: |
+            Forbidden operation. This happens when trying to create a network named after a pre-defined network,
+            or when trying to create an overlay network on a daemon which is not part of a Swarm cluster.
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "plugin not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "networkConfig"
+          in: "body"
+          description: "Network configuration"
+          required: true
+          schema:
+            type: "object"
+            title: "NetworkCreateRequest"
+            required: ["Name"]
+            properties:
+              Name:
+                description: "The network's name."
+                type: "string"
+                example: "my_network"
+              Driver:
+                description: "Name of the network driver plugin to use."
+                type: "string"
+                default: "bridge"
+                example: "bridge"
+              Scope:
+                description: |
+                  The level at which the network exists (e.g. `swarm` for cluster-wide
+                  or `local` for machine level).
+                type: "string"
+              Internal:
+                description: "Restrict external access to the network."
+                type: "boolean"
+              Attachable:
+                description: |
+                  Globally scoped network is manually attachable by regular
+                  containers from workers in swarm mode.
+                type: "boolean"
+                example: true
+              Ingress:
+                description: |
+                  Ingress network is the network which provides the routing-mesh
+                  in swarm mode.
+                type: "boolean"
+                example: false
+              ConfigOnly:
+                description: |
+                  Creates a config-only network. Config-only networks are placeholder
+                  networks for network configurations to be used by other networks.
+                  Config-only networks cannot be used directly to run containers
+                  or services.
+                type: "boolean"
+                default: false
+                example: false
+              ConfigFrom:
+                description: |
+                  Specifies the source which will provide the configuration for
+                  this network. The specified network must be an existing
+                  config-only network; see ConfigOnly.
+                $ref: "#/definitions/ConfigReference"
+              IPAM:
+                description: "Optional custom IP scheme for the network."
+                $ref: "#/definitions/IPAM"
+              EnableIPv4:
+                description: "Enable IPv4 on the network."
+                type: "boolean"
+                example: true
+              EnableIPv6:
+                description: "Enable IPv6 on the network."
+                type: "boolean"
+                example: true
+              Options:
+                description: "Network specific options to be used by the drivers."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              Labels:
+                description: "User-defined key/value metadata."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.example.some-label: "some-value"
+                  com.example.some-other-label: "some-other-value"
+      tags: ["Network"]
+
+  /networks/{id}/connect:
+    post:
+      summary: "Connect a container to a network"
+      description: "The network must be either a local-scoped network or a swarm-scoped network with the `attachable` option set. A network cannot be re-attached to a running container"
+      operationId: "NetworkConnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "Operation forbidden"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/NetworkConnectRequest"
+      tags: ["Network"]
+
+  /networks/{id}/disconnect:
+    post:
+      summary: "Disconnect a container from a network"
+      operationId: "NetworkDisconnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        403:
+          description: "Operation not supported for swarm scoped networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/NetworkDisconnectRequest"
+      tags: ["Network"]
+  /networks/prune:
+    post:
+      summary: "Delete unused networks"
+      produces:
+        - "application/json"
+      operationId: "NetworkPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune networks created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune networks with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "NetworkPruneResponse"
+            properties:
+              NetworksDeleted:
+                description: "Networks that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Network"]
+  /plugins:
+    get:
+      summary: "List plugins"
+      operationId: "PluginList"
+      description: "Returns information about installed plugins."
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Plugin"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the plugin list.
+
+            Available filters:
+
+            - `capability=<capability name>`
+            - `enable=<true>|<false>`
+      tags: ["Plugin"]
+
+  /plugins/privileges:
+    get:
+      summary: "Get plugin privileges"
+      operationId: "GetPluginPrivileges"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags:
+        - "Plugin"
+
+  /plugins/pull:
+    post:
+      summary: "Install a plugin"
+      operationId: "PluginPull"
+      description: |
+        Pulls and installs a plugin. After the plugin is installed, it can be
+        enabled using the [`POST /plugins/{name}/enable` endpoint](#operation/PostPluginsEnable).
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference for plugin to install.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "name"
+          in: "query"
+          description: |
+            Local name for the pulled plugin.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: false
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/{name}/json:
+    get:
+      summary: "Inspect a plugin"
+      operationId: "PluginInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags: ["Plugin"]
+  /plugins/{name}:
+    delete:
+      summary: "Remove a plugin"
+      operationId: "PluginDelete"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Disable the plugin before removing. This may result in issues if the
+            plugin is in use by a container.
+          type: "boolean"
+          default: false
+      tags: ["Plugin"]
+  /plugins/{name}/enable:
+    post:
+      summary: "Enable a plugin"
+      operationId: "PluginEnable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "timeout"
+          in: "query"
+          description: "Set the HTTP client timeout (in seconds)"
+          type: "integer"
+          default: 0
+      tags: ["Plugin"]
+  /plugins/{name}/disable:
+    post:
+      summary: "Disable a plugin"
+      operationId: "PluginDisable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Force disable a plugin even if still in use.
+          required: false
+          type: "boolean"
+      tags: ["Plugin"]
+  /plugins/{name}/upgrade:
+    post:
+      summary: "Upgrade a plugin"
+      operationId: "PluginUpgrade"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference to upgrade to.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/create:
+    post:
+      summary: "Create a plugin"
+      operationId: "PluginCreate"
+      consumes:
+        - "application/x-tar"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "tarContext"
+          in: "body"
+          description: "Path to tar containing plugin rootfs and manifest"
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Plugin"]
+  /plugins/{name}/push:
+    post:
+      summary: "Push a plugin"
+      operationId: "PluginPush"
+      description: |
+        Push a plugin to the registry.
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /plugins/{name}/set:
+    post:
+      summary: "Configure a plugin"
+      operationId: "PluginSet"
+      consumes:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              type: "string"
+            example: ["DEBUG=1"]
+      responses:
+        204:
+          description: "No error"
+        404:
+          description: "Plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /nodes:
+    get:
+      summary: "List nodes"
+      operationId: "NodeList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Node"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the nodes list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `id=<node id>`
+            - `label=<engine label>`
+            - `membership=`(`accepted`|`pending`)`
+            - `name=<node name>`
+            - `node.label=<node label>`
+            - `role=`(`manager`|`worker`)`
+          type: "string"
+      tags: ["Node"]
+  /nodes/{id}:
+    get:
+      summary: "Inspect a node"
+      operationId: "NodeInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Node"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+      tags: ["Node"]
+    delete:
+      summary: "Delete a node"
+      operationId: "NodeDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Force remove a node from the swarm"
+          default: false
+          type: "boolean"
+      tags: ["Node"]
+  /nodes/{id}/update:
+    post:
+      summary: "Update a node"
+      operationId: "NodeUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID of the node"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/NodeSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the node object being updated. This is required
+            to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Node"]
+  /swarm:
+    get:
+      summary: "Inspect swarm"
+      operationId: "SwarmInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Swarm"
+        404:
+          description: "no such swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/init:
+    post:
+      summary: "Initialize a new swarm"
+      operationId: "SwarmInit"
+      produces:
+        - "application/json"
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            description: "The node ID"
+            type: "string"
+            example: "7v2t30z9blmxuhnyo6s4cpenp"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmInitRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication, as well
+                  as determining the networking interface used for the VXLAN
+                  Tunnel Endpoint (VTEP). This can either be an address/port
+                  combination in the form `192.168.1.1:4567`, or an interface
+                  followed by a port number, like `eth0:4567`. If the port number
+                  is omitted, the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other  nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+                type: "string"
+              DataPathPort:
+                description: |
+                  DataPathPort specifies the data path port number for data traffic.
+                  Acceptable port range is 1024 to 49151.
+                  if no port is set or is set to 0, default port 4789 will be used.
+                type: "integer"
+                format: "uint32"
+              DefaultAddrPool:
+                description: |
+                  Default Address Pool specifies default subnet pools for global
+                  scope networks.
+                type: "array"
+                items:
+                  type: "string"
+                  example: ["10.10.0.0/16", "20.20.0.0/16"]
+              ForceNewCluster:
+                description: "Force creation of a new swarm."
+                type: "boolean"
+              SubnetSize:
+                description: |
+                  SubnetSize specifies the subnet size of the networks created
+                  from the default subnet pool.
+                type: "integer"
+                format: "uint32"
+              Spec:
+                $ref: "#/definitions/SwarmSpec"
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathPort: 4789
+              DefaultAddrPool: ["10.10.0.0/8", "20.20.0.0/8"]
+              SubnetSize: 24
+              ForceNewCluster: false
+              Spec:
+                Orchestration: {}
+                Raft: {}
+                Dispatcher: {}
+                CAConfig: {}
+                EncryptionConfig:
+                  AutoLockManagers: false
+      tags: ["Swarm"]
+  /swarm/join:
+    post:
+      summary: "Join an existing swarm"
+      operationId: "SwarmJoin"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmJoinRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+
+                type: "string"
+              RemoteAddrs:
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
+              JoinToken:
+                description: "Secret token for joining this swarm."
+                type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathAddr: "192.168.1.1"
+              RemoteAddrs:
+                - "node1:2377"
+              JoinToken: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+      tags: ["Swarm"]
+  /swarm/leave:
+    post:
+      summary: "Leave a swarm"
+      operationId: "SwarmLeave"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "force"
+          description: |
+            Force leave swarm, even if this is the last manager or that it will
+            break the cluster.
+          in: "query"
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/update:
+    post:
+      summary: "Update a swarm"
+      operationId: "SwarmUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/SwarmSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the swarm object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+        - name: "rotateWorkerToken"
+          in: "query"
+          description: "Rotate the worker join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerToken"
+          in: "query"
+          description: "Rotate the manager join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerUnlockKey"
+          in: "query"
+          description: "Rotate the manager unlock key."
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/unlockkey:
+    get:
+      summary: "Get the unlock key"
+      operationId: "SwarmUnlockkey"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "UnlockKeyResponse"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/unlock:
+    post:
+      summary: "Unlock a locked manager"
+      operationId: "SwarmUnlock"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmUnlockRequest"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /services:
+    get:
+      summary: "List services"
+      operationId: "ServiceList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Service"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the services list.
+
+            Available filters:
+
+            - `id=<service id>`
+            - `label=<service label>`
+            - `mode=["replicated"|"global"]`
+            - `name=<service name>`
+        - name: "status"
+          in: "query"
+          type: "boolean"
+          description: |
+            Include service status, with count of running and desired tasks.
+      tags: ["Service"]
+  /services/create:
+    post:
+      summary: "Create a service"
+      operationId: "ServiceCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "network is not eligible for services"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "name conflicts with an existing service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "web"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "nginx:alpine"
+                      Mounts:
+                        -
+                          ReadOnly: true
+                          Source: "web-data"
+                          Target: "/usr/share/nginx/html"
+                          Type: "volume"
+                          VolumeOptions:
+                            DriverConfig: {}
+                            Labels:
+                              com.example.something: "something-value"
+                      Hosts: ["10.10.10.10 host1", "ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 host2"]
+                      User: "33"
+                      DNSConfig:
+                        Nameservers: ["8.8.8.8"]
+                        Search: ["example.org"]
+                        Options: ["timeout:3"]
+                      Secrets:
+                        -
+                          File:
+                            Name: "www.example.org.key"
+                            UID: "33"
+                            GID: "33"
+                            Mode: 384
+                          SecretID: "fpjqlhnwb19zds35k8wn80lq9"
+                          SecretName: "example_org_domain_key"
+                      OomScoreAdj: 0
+                    LogDriver:
+                      Name: "json-file"
+                      Options:
+                        max-file: "3"
+                        max-size: "10M"
+                    Placement: {}
+                    Resources:
+                      Limits:
+                        MemoryBytes: 104857600
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "on-failure"
+                      Delay: 10000000000
+                      MaxAttempts: 10
+                  Mode:
+                    Replicated:
+                      Replicas: 4
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Ports:
+                      -
+                        Protocol: "tcp"
+                        PublishedPort: 8080
+                        TargetPort: 80
+                  Labels:
+                    foo: "bar"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+      tags: ["Service"]
+  /services/{id}:
+    get:
+      summary: "Inspect a service"
+      operationId: "ServiceInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Service"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "insertDefaults"
+          in: "query"
+          description: "Fill empty fields with default values."
+          type: "boolean"
+          default: false
+      tags: ["Service"]
+    delete:
+      summary: "Delete a service"
+      operationId: "ServiceDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+      tags: ["Service"]
+  /services/{id}/update:
+    post:
+      summary: "Update a service"
+      operationId: "ServiceUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceUpdateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "top"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "busybox"
+                      Args:
+                        - "top"
+                      OomScoreAdj: 0
+                    Resources:
+                      Limits: {}
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "any"
+                      MaxAttempts: 0
+                    Placement: {}
+                    ForceUpdate: 0
+                  Mode:
+                    Replicated:
+                      Replicas: 1
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Mode: "vip"
+
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the service object being updated. This is
+            required to avoid conflicting writes.
+            This version number should be the value as currently set on the
+            service *before* the update. You can find the current version by
+            calling `GET /services/{id}`
+          required: true
+          type: "integer"
+        - name: "registryAuthFrom"
+          in: "query"
+          description: |
+            If the `X-Registry-Auth` header is not specified, this parameter
+            indicates where to find registry authorization credentials.
+          type: "string"
+          enum: ["spec", "previous-spec"]
+          default: "spec"
+        - name: "rollback"
+          in: "query"
+          description: |
+            Set to this parameter to `previous` to cause a server-side rollback
+            to the previous service spec. The supplied spec will be ignored in
+            this case.
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+
+      tags: ["Service"]
+  /services/{id}/logs:
+    get:
+      summary: "Get service logs"
+      description: |
+        Get `stdout` and `stderr` logs from a service. See also
+        [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ServiceLogs"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such service: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the service"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show service context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Service"]
+  /tasks:
+    get:
+      summary: "List tasks"
+      operationId: "TaskList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Task"
+            example:
+              - ID: "0kzzo1i0y4jz6027t0k7aezc7"
+                Version:
+                  Index: 71
+                CreatedAt: "2016-06-07T21:07:31.171892745Z"
+                UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:31.290032978Z"
+                  State: "running"
+                  Message: "started"
+                  ContainerStatus:
+                    ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+                    PID: 677
+                DesiredState: "running"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.10/16"
+              - ID: "1yljwbmlr8er2waf8orvqpwms"
+                Version:
+                  Index: 30
+                CreatedAt: "2016-06-07T21:07:30.019104782Z"
+                UpdatedAt: "2016-06-07T21:07:30.231958098Z"
+                Name: "hopeful_cori"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:30.202183143Z"
+                  State: "shutdown"
+                  Message: "shutdown"
+                  ContainerStatus:
+                    ContainerID: "1cf8d63d18e79668b0004a4be4c6ee58cddfad2dae29506d8781581d0688a213"
+                DesiredState: "shutdown"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.5/16"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the tasks list.
+
+            Available filters:
+
+            - `desired-state=(running | shutdown | accepted)`
+            - `id=<task id>`
+            - `label=key` or `label="key=value"`
+            - `name=<task name>`
+            - `node=<node id or name>`
+            - `service=<service name>`
+      tags: ["Task"]
+  /tasks/{id}:
+    get:
+      summary: "Inspect a task"
+      operationId: "TaskInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Task"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID of the task"
+          required: true
+          type: "string"
+      tags: ["Task"]
+  /tasks/{id}/logs:
+    get:
+      summary: "Get task logs"
+      description: |
+        Get `stdout` and `stderr` logs from a task.
+        See also [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      operationId: "TaskLogs"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such task: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID of the task"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show task context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Task"]
+  /secrets:
+    get:
+      summary: "List secrets"
+      operationId: "SecretList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Secret"
+            example:
+              - ID: "blt1owaxmitz71s9v5zh81zun"
+                Version:
+                  Index: 85
+                CreatedAt: "2017-07-20T13:55:28.678958722Z"
+                UpdatedAt: "2017-07-20T13:55:28.678958722Z"
+                Spec:
+                  Name: "mysql-passwd"
+                  Labels:
+                    some.label: "some.value"
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "app-dev.crt"
+                  Labels:
+                    foo: "bar"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the secrets list.
+
+            Available filters:
+
+            - `id=<secret id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<secret name>`
+            - `names=<secret name>`
+      tags: ["Secret"]
+  /secrets/create:
+    post:
+      summary: "Create a secret"
+      operationId: "SecretCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/SecretSpec"
+              - type: "object"
+                example:
+                  Name: "app-key.crt"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+      tags: ["Secret"]
+  /secrets/{id}:
+    get:
+      summary: "Inspect a secret"
+      operationId: "SecretInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Secret"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+                Labels:
+                  foo: "bar"
+                Driver:
+                  Name: "secret-bucket"
+                  Options:
+                    OptionA: "value for driver option A"
+                    OptionB: "value for driver option B"
+
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+    delete:
+      summary: "Delete a secret"
+      operationId: "SecretDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+  /secrets/{id}/update:
+    post:
+      summary: "Update a Secret"
+      operationId: "SecretUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such secret"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the secret"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/SecretSpec"
+          description: |
+            The spec of the secret to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [SecretInspect endpoint](#operation/SecretInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the secret object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Secret"]
+  /configs:
+    get:
+      summary: "List configs"
+      operationId: "ConfigList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Config"
+            example:
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "server.conf"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the configs list.
+
+            Available filters:
+
+            - `id=<config id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<config name>`
+            - `names=<config name>`
+      tags: ["Config"]
+  /configs/create:
+    post:
+      summary: "Create a config"
+      operationId: "ConfigCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ConfigSpec"
+              - type: "object"
+                example:
+                  Name: "server.conf"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+      tags: ["Config"]
+  /configs/{id}:
+    get:
+      summary: "Inspect a config"
+      operationId: "ConfigInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Config"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+    delete:
+      summary: "Delete a config"
+      operationId: "ConfigDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+  /configs/{id}/update:
+    post:
+      summary: "Update a Config"
+      operationId: "ConfigUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such config"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the config"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/ConfigSpec"
+          description: |
+            The spec of the config to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [ConfigInspect endpoint](#operation/ConfigInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the config object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Config"]
+  /distribution/{name}/json:
+    get:
+      summary: "Get image information from the registry"
+      description: |
+        Return image digest and platform information by contacting the registry.
+      operationId: "DistributionInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "descriptor and platform information"
+          schema:
+            $ref: "#/definitions/DistributionInspect"
+        401:
+          description: "Failed authentication or no image found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+      tags: ["Distribution"]
+  /session:
+    post:
+      summary: "Initialize interactive session"
+      description: |
+        Start a new interactive session with a server. Session allows server to
+        call back to the client for advanced capabilities.
+
+        > **Deprecated**: This endpoint is deprecated and will be removed in a future version.
+        > Server should support gRPC directly on the listening socket.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to HTTP2 transport that allows
+        the client to expose gPRC services on that connection.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /session HTTP/1.1
+        Upgrade: h2c
+        Connection: Upgrade
+        ```
+
+        The Docker daemon responds with a `101 UPGRADED` response follow with
+        the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Connection: Upgrade
+        Upgrade: h2c
+        ```
+      operationId: "Session"
+      produces:
+        - "application/vnd.docker.raw-stream"
+      responses:
+        101:
+          description: "no error, hijacking successful"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Session"]
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.54.yaml b/_vendor/github.com/moby/moby/api/docs/v1.54.yaml
new file mode 100644
index 000000000000..f4cb282fa3f6
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.54.yaml
@@ -0,0 +1,13891 @@
+# A Swagger 2.0 (a.k.a. OpenAPI) definition of the Engine API.
+#
+# This is used for generating API documentation and the types used by the
+# client/server. See api/README.md for more information.
+#
+# Some style notes:
+# - This file is used by ReDoc, which allows GitHub Flavored Markdown in
+#   descriptions.
+# - There is no maximum line length, for ease of editing and pretty diffs.
+# - operationIds are in the format "NounVerb", with a singular noun.
+
+swagger: "2.0"
+schemes:
+  - "http"
+  - "https"
+produces:
+  - "application/json"
+  - "text/plain"
+consumes:
+  - "application/json"
+  - "text/plain"
+basePath: "/v1.54"
+info:
+  title: "Docker Engine API"
+  version: "1.54"
+  x-logo:
+    url: "https://docs.docker.com/assets/images/logo-docker-main.png"
+  description: |
+    The Engine API is an HTTP API served by Docker Engine. It is the API the
+    Docker client uses to communicate with the Engine, so everything the Docker
+    client can do can be done with the API.
+
+    Most of the client's commands map directly to API endpoints (e.g. `docker ps`
+    is `GET /containers/json`). The notable exception is running containers,
+    which consists of several API calls.
+
+    # Errors
+
+    The API uses standard HTTP status codes to indicate the success or failure
+    of the API call. The body of the response will be JSON in the following
+    format:
+
+    ```
+    {
+      "message": "page not found"
+    }
+    ```
+
+    # Versioning
+
+    The API is usually changed in each release, so API calls are versioned to
+    ensure that clients don't break. To lock to a specific version of the API,
+    you prefix the URL with its version, for example, call `/v1.30/info` to use
+    the v1.30 version of the `/info` endpoint. If the API version specified in
+    the URL is not supported by the daemon, a HTTP `400 Bad Request` error message
+    is returned.
+
+    If you omit the version-prefix, the current version of the API (v1.50) is used.
+    For example, calling `/info` is the same as calling `/v1.52/info`. Using the
+    API without a version-prefix is deprecated and will be removed in a future release.
+
+    Engine releases in the near future should support this version of the API,
+    so your client will continue to work even if it is talking to a newer Engine.
+
+    The API uses an open schema model, which means the server may add extra properties
+    to responses. Likewise, the server will ignore any extra query parameters and
+    request body properties. When you write clients, you need to ignore additional
+    properties in responses to ensure they do not break when talking to newer
+    daemons.
+
+
+    # Authentication
+
+    Authentication for registries is handled client side. The client has to send
+    authentication details to various endpoints that need to communicate with
+    registries, such as `POST /images/(name)/push`. These are sent as
+    `X-Registry-Auth` header as a [base64url encoded](https://tools.ietf.org/html/rfc4648#section-5)
+    (JSON) string with the following structure:
+
+    ```
+    {
+      "username": "string",
+      "password": "string",
+      "serveraddress": "string"
+    }
+    ```
+
+    The `serveraddress` is a domain/IP without a protocol. Throughout this
+    structure, double quotes are required.
+
+    If you have already got an identity token from the [`/auth` endpoint](#operation/SystemAuth),
+    you can just pass this instead of credentials:
+
+    ```
+    {
+      "identitytoken": "9cbaf023786cd7..."
+    }
+    ```
+
+# The tags on paths define the menu sections in the ReDoc documentation, so
+# the usage of tags must make sense for that:
+# - They should be singular, not plural.
+# - There should not be too many tags, or the menu becomes unwieldy. For
+#   example, it is preferable to add a path to the "System" tag instead of
+#   creating a tag with a single path in it.
+# - The order of tags in this list defines the order in the menu.
+tags:
+  # Primary objects
+  - name: "Container"
+    x-displayName: "Containers"
+    description: |
+      Create and manage containers.
+  - name: "Image"
+    x-displayName: "Images"
+  - name: "Network"
+    x-displayName: "Networks"
+    description: |
+      Networks are user-defined networks that containers can be attached to.
+      See the [networking documentation](https://docs.docker.com/network/)
+      for more information.
+  - name: "Volume"
+    x-displayName: "Volumes"
+    description: |
+      Create and manage persistent storage that can be attached to containers.
+  - name: "Exec"
+    x-displayName: "Exec"
+    description: |
+      Run new commands inside running containers. Refer to the
+      [command-line reference](https://docs.docker.com/engine/reference/commandline/exec/)
+      for more information.
+
+      To exec a command in a container, you first need to create an exec instance,
+      then start it. These two API endpoints are wrapped up in a single command-line
+      command, `docker exec`.
+
+  # Swarm things
+  - name: "Swarm"
+    x-displayName: "Swarm"
+    description: |
+      Engines can be clustered together in a swarm. Refer to the
+      [swarm mode documentation](https://docs.docker.com/engine/swarm/)
+      for more information.
+  - name: "Node"
+    x-displayName: "Nodes"
+    description: |
+      Nodes are instances of the Engine participating in a swarm. Swarm mode
+      must be enabled for these endpoints to work.
+  - name: "Service"
+    x-displayName: "Services"
+    description: |
+      Services are the definitions of tasks to run on a swarm. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Task"
+    x-displayName: "Tasks"
+    description: |
+      A task is a container running on a swarm. It is the atomic scheduling unit
+      of swarm. Swarm mode must be enabled for these endpoints to work.
+  - name: "Secret"
+    x-displayName: "Secrets"
+    description: |
+      Secrets are sensitive data that can be used by services. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Config"
+    x-displayName: "Configs"
+    description: |
+      Configs are application configurations that can be used by services. Swarm
+      mode must be enabled for these endpoints to work.
+  # System things
+  - name: "Plugin"
+    x-displayName: "Plugins"
+  - name: "System"
+    x-displayName: "System"
+
+definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
+  PortSummary:
+    type: "object"
+    description: |
+      Describes a port-mapping between the container and the host.
+    required: [PrivatePort, Type]
+    properties:
+      IP:
+        type: "string"
+        format: "ip-address"
+        description: "Host IP address that the container's port is mapped to"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      PrivatePort:
+        type: "integer"
+        format: "uint16"
+        x-nullable: false
+        description: "Port on the container"
+      PublicPort:
+        type: "integer"
+        format: "uint16"
+        description: "Port exposed on the host"
+      Type:
+        type: "string"
+        x-nullable: false
+        enum: ["tcp", "udp", "sctp"]
+    example:
+      PrivatePort: 8080
+      PublicPort: 80
+      Type: "tcp"
+
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `image` an OCI image.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "image"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
+  MountPoint:
+    type: "object"
+    description: |
+      MountPoint represents a mount point configuration inside the container.
+      This is used for reporting the mountpoints in use by a container.
+    properties:
+      Type:
+        description: |
+          The mount type:
+
+          - `bind` a mount of a file or directory from the host into the container.
+          - `cluster` a Swarm cluster volume.
+          - `image` an OCI image.
+          - `npipe` a named pipe from the host into the container.
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
+        example: "volume"
+      Name:
+        description: |
+          Name is the name reference to the underlying data defined by `Source`
+          e.g., the volume name.
+        type: "string"
+        example: "myvolume"
+      Source:
+        description: |
+          Source location of the mount.
+
+          For volumes, this contains the storage location of the volume (within
+          `/var/lib/docker/volumes/`). For bind-mounts, and `npipe`, this contains
+          the source (host) part of the bind-mount. For `tmpfs` mount points, this
+          field is empty.
+        type: "string"
+        example: "/var/lib/docker/volumes/myvolume/_data"
+      Destination:
+        description: |
+          Destination is the path relative to the container root (`/`) where
+          the `Source` is mounted inside the container.
+        type: "string"
+        example: "/usr/share/nginx/html/"
+      Driver:
+        description: |
+          Driver is the volume driver used to create the volume (if it is a volume).
+        type: "string"
+        example: "local"
+      Mode:
+        description: |
+          Mode is a comma separated list of options supplied by the user when
+          creating the bind/volume mount.
+
+          The default is platform-specific (`"z"` on Linux, empty on Windows).
+        type: "string"
+        example: "z"
+      RW:
+        description: |
+          Whether the mount is mounted writable (read-write).
+        type: "boolean"
+        example: true
+      Propagation:
+        description: |
+          Propagation describes how mounts are propagated from the host into the
+          mount point, and vice-versa. Refer to the [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
+          for details. This field is not used on Windows.
+        type: "string"
+        example: ""
+
+  DeviceMapping:
+    type: "object"
+    description: "A device mapping between the host and container"
+    properties:
+      PathOnHost:
+        type: "string"
+      PathInContainer:
+        type: "string"
+      CgroupPermissions:
+        type: "string"
+    example:
+      PathOnHost: "/dev/deviceName"
+      PathInContainer: "/dev/deviceName"
+      CgroupPermissions: "mrw"
+
+  DeviceRequest:
+    type: "object"
+    description: "A request for devices to be sent to device drivers"
+    properties:
+      Driver:
+        description: |
+          The name of the device driver to use for this request.
+
+          Note that if this is specified the capabilities are ignored when
+          selecting a device driver.
+        type: "string"
+        example: "nvidia"
+      Count:
+        type: "integer"
+        example: -1
+      DeviceIDs:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "0"
+          - "1"
+          - "GPU-fef8089b-4820-abfc-e83e-94318197576e"
+      Capabilities:
+        description: |
+          A list of capabilities; an OR list of AND lists of capabilities.
+
+          Note that if a driver is specified the capabilities have no effect on
+          selecting a driver as the driver name is used directly.
+
+          Note that if no driver is specified the capabilities are used to
+          select a driver with the required capabilities.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          # gpu AND nvidia AND compute
+          - ["gpu", "nvidia", "compute"]
+      Options:
+        description: |
+          Driver-specific options, specified as a key/value pairs. These options
+          are passed directly to the driver.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  ThrottleDevice:
+    type: "object"
+    properties:
+      Path:
+        description: "Device path"
+        type: "string"
+      Rate:
+        description: "Rate"
+        type: "integer"
+        format: "int64"
+        minimum: 0
+
+  Mount:
+    type: "object"
+    properties:
+      Target:
+        description: "Container path."
+        type: "string"
+      Source:
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
+        type: "string"
+      Type:
+        description: |
+          The mount type. Available types:
+
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `cluster` a Swarm cluster volume
+          - `image` Mounts an image.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
+      ReadOnly:
+        description: "Whether the mount should be read-only."
+        type: "boolean"
+      Consistency:
+        description: "The consistency requirement for the mount: `default`, `consistent`, `cached`, or `delegated`."
+        type: "string"
+      BindOptions:
+        description: "Optional configuration for the `bind` type."
+        type: "object"
+        properties:
+          Propagation:
+            description: "A propagation mode with the value `[r]private`, `[r]shared`, or `[r]slave`."
+            type: "string"
+            enum:
+              - "private"
+              - "rprivate"
+              - "shared"
+              - "rshared"
+              - "slave"
+              - "rslave"
+          NonRecursive:
+            description: "Disable recursive bind mount."
+            type: "boolean"
+            default: false
+          CreateMountpoint:
+            description: "Create mount point on host if missing"
+            type: "boolean"
+            default: false
+          ReadOnlyNonRecursive:
+            description: |
+              Make the mount non-recursively read-only, but still leave the mount recursive
+              (unless NonRecursive is set to `true` in conjunction).
+
+              Added in v1.44, before that version all read-only mounts were
+              non-recursive by default. To match the previous behaviour this
+              will default to `true` for clients on versions prior to v1.44.
+            type: "boolean"
+            default: false
+          ReadOnlyForceRecursive:
+            description: "Raise an error if the mount cannot be made recursively read-only."
+            type: "boolean"
+            default: false
+      VolumeOptions:
+        description: "Optional configuration for the `volume` type."
+        type: "object"
+        properties:
+          NoCopy:
+            description: "Populate volume with data from the target."
+            type: "boolean"
+            default: false
+          Labels:
+            description: "User-defined key/value metadata."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          DriverConfig:
+            description: "Map of driver specific options"
+            type: "object"
+            properties:
+              Name:
+                description: "Name of the driver to use to create the volume."
+                type: "string"
+              Options:
+                description: "key/value map of driver specific options."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+          Subpath:
+            description: "Source path inside the volume. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-volume/subdirectory"
+      ImageOptions:
+        description: "Optional configuration for the `image` type."
+        type: "object"
+        properties:
+          Subpath:
+            description: "Source path inside the image. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-image/subdirectory"
+      TmpfsOptions:
+        description: "Optional configuration for the `tmpfs` type."
+        type: "object"
+        properties:
+          SizeBytes:
+            description: "The size for the tmpfs mount in bytes."
+            type: "integer"
+            format: "int64"
+          Mode:
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
+            type: "integer"
+          Options:
+            description: |
+              The options to be passed to the tmpfs mount. An array of arrays.
+              Flag options should be provided as 1-length arrays. Other types
+              should be provided as as 2-length arrays, where the first item is
+              the key and the second the value.
+            type: "array"
+            items:
+              type: "array"
+              minItems: 1
+              maxItems: 2
+              items:
+                type: "string"
+            example:
+              [["noexec"]]
+
+  RestartPolicy:
+    description: |
+      The behavior to apply when the container exits. The default is not to
+      restart.
+
+      An ever increasing delay (double the previous delay, starting at 100ms) is
+      added before each restart to prevent flooding the server.
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        description: |
+          - Empty string means not to restart
+          - `no` Do not automatically restart
+          - `always` Always restart
+          - `unless-stopped` Restart always except when the user has manually stopped the container
+          - `on-failure` Restart only when the container exit code is non-zero
+        enum:
+          - ""
+          - "no"
+          - "always"
+          - "unless-stopped"
+          - "on-failure"
+      MaximumRetryCount:
+        type: "integer"
+        description: |
+          If `on-failure` is used, the number of times to retry before giving up.
+
+  Resources:
+    description: "A container's resources (cgroups config, ulimits, etc)"
+    type: "object"
+    properties:
+      # Applicable to all platforms
+      CpuShares:
+        description: |
+          An integer value representing this container's relative CPU weight
+          versus other containers.
+        type: "integer"
+      Memory:
+        description: "Memory limit in bytes."
+        type: "integer"
+        format: "int64"
+        default: 0
+      # Applicable to UNIX platforms
+      CgroupParent:
+        description: |
+          Path to `cgroups` under which the container's `cgroup` is created. If
+          the path is not absolute, the path is considered to be relative to the
+          `cgroups` path of the init process. Cgroups are created if they do not
+          already exist.
+        type: "string"
+      BlkioWeight:
+        description: "Block IO weight (relative weight)."
+        type: "integer"
+        minimum: 0
+        maximum: 1000
+      BlkioWeightDevice:
+        description: |
+          Block IO weight (relative device weight) in the form:
+
+          ```
+          [{"Path": "device_path", "Weight": weight}]
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Path:
+              type: "string"
+            Weight:
+              type: "integer"
+              minimum: 0
+      BlkioDeviceReadBps:
+        description: |
+          Limit read rate (bytes per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteBps:
+        description: |
+          Limit write rate (bytes per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceReadIOps:
+        description: |
+          Limit read rate (IO per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteIOps:
+        description: |
+          Limit write rate (IO per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      CpuPeriod:
+        description: "The length of a CPU period in microseconds."
+        type: "integer"
+        format: "int64"
+      CpuQuota:
+        description: |
+          Microseconds of CPU time that the container can get in a CPU period.
+        type: "integer"
+        format: "int64"
+      CpuRealtimePeriod:
+        description: |
+          The length of a CPU real-time period in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpuRealtimeRuntime:
+        description: |
+          The length of a CPU real-time runtime in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpusetCpus:
+        description: |
+          CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+        type: "string"
+        example: "0-3"
+      CpusetMems:
+        description: |
+          Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only
+          effective on NUMA systems.
+        type: "string"
+      Devices:
+        description: "A list of devices to add to the container."
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceMapping"
+      DeviceCgroupRules:
+        description: "a list of cgroup rules to apply to the container"
+        type: "array"
+        items:
+          type: "string"
+          example: "c 13:* rwm"
+      DeviceRequests:
+        description: |
+          A list of requests for devices to be sent to device drivers.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceRequest"
+      MemoryReservation:
+        description: "Memory soft limit in bytes."
+        type: "integer"
+        format: "int64"
+      MemorySwap:
+        description: |
+          Total memory limit (memory + swap). Set as `-1` to enable unlimited
+          swap.
+        type: "integer"
+        format: "int64"
+      MemorySwappiness:
+        description: |
+          Tune a container's memory swappiness behavior. Accepts an integer
+          between 0 and 100.
+        type: "integer"
+        format: "int64"
+        minimum: 0
+        maximum: 100
+      NanoCpus:
+        description: "CPU quota in units of 10<sup>-9</sup> CPUs."
+        type: "integer"
+        format: "int64"
+      OomKillDisable:
+        description: "Disable OOM Killer for the container."
+        type: "boolean"
+      Init:
+        description: |
+          Run an init inside the container that forwards signals and reaps
+          processes. This field is omitted if empty, and the default (as
+          configured on the daemon) is used.
+        type: "boolean"
+        x-nullable: true
+      PidsLimit:
+        description: |
+          Tune a container's PIDs limit. Set `0` or `-1` for unlimited, or `null`
+          to not change.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+      Ulimits:
+        description: |
+          A list of resource limits to set in the container. For example:
+
+          ```
+          {"Name": "nofile", "Soft": 1024, "Hard": 2048}
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Name:
+              description: "Name of ulimit"
+              type: "string"
+            Soft:
+              description: "Soft limit"
+              type: "integer"
+            Hard:
+              description: "Hard limit"
+              type: "integer"
+      # Applicable to Windows
+      CpuCount:
+        description: |
+          The number of usable CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      CpuPercent:
+        description: |
+          The usable percentage of the available CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      IOMaximumIOps:
+        description: "Maximum IOps for the container system drive (Windows only)"
+        type: "integer"
+        format: "int64"
+      IOMaximumBandwidth:
+        description: |
+          Maximum IO in bytes per second for the container system drive
+          (Windows only).
+        type: "integer"
+        format: "int64"
+
+  Limit:
+    description: |
+      An object describing a limit on resources which can be requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      Pids:
+        description: |
+          Limits the maximum number of PIDs in the container. Set `0` for unlimited.
+        type: "integer"
+        format: "int64"
+        default: 0
+        example: 100
+
+  ResourceObject:
+    description: |
+      An object describing the resources which can be advertised by a node and
+      requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+
+  GenericResources:
+    description: |
+      User-defined resources can be either Integer resources (e.g, `SSD=3`) or
+      String resources (e.g, `GPU=UUID1`).
+    type: "array"
+    items:
+      type: "object"
+      properties:
+        NamedResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "string"
+        DiscreteResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "integer"
+              format: "int64"
+    example:
+      - DiscreteResourceSpec:
+          Kind: "SSD"
+          Value: 3
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID1"
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID2"
+
+  HealthConfig:
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
+    type: "object"
+    properties:
+      Test:
+        description: |
+          The test to perform. Possible values are:
+
+          - `[]` inherit healthcheck from image or parent image
+          - `["NONE"]` disable healthcheck
+          - `["CMD", args...]` exec arguments directly
+          - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
+        type: "array"
+        items:
+          type: "string"
+      Interval:
+        description: |
+          The time to wait between checks in nanoseconds. It should be 0 or at
+          least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      Timeout:
+        description: |
+          The time to wait before considering the check to have hung. It should
+          be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
+        type: "integer"
+        format: "int64"
+      Retries:
+        description: |
+          The number of consecutive failures needed to consider a container as
+          unhealthy. 0 means inherit.
+        type: "integer"
+      StartPeriod:
+        description: |
+          Start period for the container to initialize before starting
+          health-retries countdown in nanoseconds. It should be 0 or at least
+          1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      StartInterval:
+        description: |
+          The time to wait between checks in nanoseconds during the start period.
+          It should be 0 or at least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+
+  Health:
+    description: |
+      Health stores information about the container's healthcheck results.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          Status is one of `none`, `starting`, `healthy` or `unhealthy`
+
+          - "none"      Indicates there is no healthcheck
+          - "starting"  Starting indicates that the container is not yet ready
+          - "healthy"   Healthy indicates that the container is running correctly
+          - "unhealthy" Unhealthy indicates that the container has a problem
+        type: "string"
+        enum:
+          - "none"
+          - "starting"
+          - "healthy"
+          - "unhealthy"
+        example: "healthy"
+      FailingStreak:
+        description: "FailingStreak is the number of consecutive failures"
+        type: "integer"
+        example: 0
+      Log:
+        type: "array"
+        description: |
+          Log contains the last few results (oldest first)
+        items:
+          $ref: "#/definitions/HealthcheckResult"
+
+  HealthcheckResult:
+    description: |
+      HealthcheckResult stores information about a single run of a healthcheck probe
+    type: "object"
+    x-nullable: true
+    properties:
+      Start:
+        description: |
+          Date and time at which this check started in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2020-01-04T10:44:24.496525531Z"
+      End:
+        description: |
+          Date and time at which this check ended in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2020-01-04T10:45:21.364524523Z"
+      ExitCode:
+        description: |
+          ExitCode meanings:
+
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (considered unhealthy)
+          - other values: error running probe
+        type: "integer"
+        example: 0
+      Output:
+        description: "Output from last check"
+        type: "string"
+
+  HostConfig:
+    description: "Container configuration that depends on the host we are running on"
+    allOf:
+      - $ref: "#/definitions/Resources"
+      - type: "object"
+        properties:
+          # Applicable to all platforms
+          Binds:
+            type: "array"
+            description: |
+              A list of volume bindings for this container. Each volume binding
+              is a string in one of these forms:
+
+              - `host-src:container-dest[:options]` to bind-mount a host path
+                into the container. Both `host-src`, and `container-dest` must
+                be an _absolute_ path.
+              - `volume-name:container-dest[:options]` to bind-mount a volume
+                managed by a volume driver into the container. `container-dest`
+                must be an _absolute_ path.
+
+              `options` is an optional, comma-delimited list of:
+
+              - `nocopy` disables automatic copying of data from the container
+                path to the volume. The `nocopy` flag only applies to named volumes.
+              - `[ro|rw]` mounts a volume read-only or read-write, respectively.
+                If omitted or set to `rw`, volumes are mounted read-write.
+              - `[z|Z]` applies SELinux labels to allow or deny multiple containers
+                to read and write to the same volume.
+                  - `z`: a _shared_ content label is applied to the content. This
+                    label indicates that multiple containers can share the volume
+                    content, for both reading and writing.
+                  - `Z`: a _private unshared_ label is applied to the content.
+                    This label indicates that only the current container can use
+                    a private volume. Labeling systems such as SELinux require
+                    proper labels to be placed on volume content that is mounted
+                    into a container. Without a label, the security system can
+                    prevent a container's processes from using the content. By
+                    default, the labels set by the host operating system are not
+                    modified.
+              - `[[r]shared|[r]slave|[r]private]` specifies mount
+                [propagation behavior](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt).
+                This only applies to bind-mounted volumes, not internal volumes
+                or named volumes. Mount propagation requires the source mount
+                point (the location where the source directory is mounted in the
+                host operating system) to have the correct propagation properties.
+                For shared volumes, the source mount point must be set to `shared`.
+                For slave volumes, the mount must be set to either `shared` or
+                `slave`.
+            items:
+              type: "string"
+          ContainerIDFile:
+            type: "string"
+            description: "Path to a file where the container ID is written"
+            example: ""
+          LogConfig:
+            type: "object"
+            description: "The logging configuration for this container"
+            properties:
+              Type:
+                description: |-
+                  Name of the logging driver used for the container or "none"
+                  if logging is disabled.
+                type: "string"
+                enum:
+                  - "local"
+                  - "json-file"
+                  - "syslog"
+                  - "journald"
+                  - "gelf"
+                  - "fluentd"
+                  - "awslogs"
+                  - "splunk"
+                  - "etwlogs"
+                  - "none"
+              Config:
+                description: |-
+                  Driver-specific configuration options for the logging driver.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "5"
+                  "max-size": "10m"
+          NetworkMode:
+            type: "string"
+            description: |
+              Network mode to use for this container. Supported standard values
+              are: `bridge`, `host`, `none`, and `container:<name|id>`. Any
+              other value is taken as a custom network's name to which this
+              container should connect to.
+          PortBindings:
+            $ref: "#/definitions/PortMap"
+          RestartPolicy:
+            $ref: "#/definitions/RestartPolicy"
+          AutoRemove:
+            type: "boolean"
+            description: |
+              Automatically remove the container when the container's process
+              exits. This has no effect if `RestartPolicy` is set.
+          VolumeDriver:
+            type: "string"
+            description: "Driver that this container uses to mount volumes."
+          VolumesFrom:
+            type: "array"
+            description: |
+              A list of volumes to inherit from another container, specified in
+              the form `<container name>[:<ro|rw>]`.
+            items:
+              type: "string"
+          Mounts:
+            description: |
+              Specification for mounts to be added to the container.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          ConsoleSize:
+            type: "array"
+            description: |
+              Initial console size, as an `[height, width]` array.
+            x-nullable: true
+            minItems: 2
+            maxItems: 2
+            items:
+              type: "integer"
+              minimum: 0
+            example: [80, 64]
+          Annotations:
+            type: "object"
+            description: |
+              Arbitrary non-identifying metadata attached to container and
+              provided to the runtime when the container is started.
+            additionalProperties:
+              type: "string"
+
+          # Applicable to UNIX platforms
+          CapAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CapDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CgroupnsMode:
+            type: "string"
+            enum:
+              - "private"
+              - "host"
+            description: |
+              cgroup namespace mode for the container. Possible values are:
+
+              - `"private"`: the container runs in its own private cgroup namespace
+              - `"host"`: use the host system's cgroup namespace
+
+              If not specified, the daemon default is used, which can either be `"private"`
+              or `"host"`, depending on daemon version, kernel support and configuration.
+          Dns:
+            type: "array"
+            description: "A list of DNS servers for the container to use."
+            items:
+              type: "string"
+              format: "ip-address"
+              x-go-type:
+                type: Addr
+                import:
+                  package: net/netip
+          DnsOptions:
+            type: "array"
+            description: "A list of DNS options."
+            items:
+              type: "string"
+          DnsSearch:
+            type: "array"
+            description: "A list of DNS search domains."
+            items:
+              type: "string"
+          ExtraHosts:
+            type: "array"
+            description: |
+              A list of hostnames/IP mappings to add to the container's `/etc/hosts`
+              file. Specified in the form `["hostname:IP"]`.
+            items:
+              type: "string"
+          GroupAdd:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          IpcMode:
+            type: "string"
+            description: |
+              IPC sharing mode for the container. Possible values are:
+
+              - `"none"`: own private IPC namespace, with /dev/shm not mounted
+              - `"private"`: own private IPC namespace
+              - `"shareable"`: own private IPC namespace, with a possibility to share it with other containers
+              - `"container:<name|id>"`: join another (shareable) container's IPC namespace
+              - `"host"`: use the host system's IPC namespace
+
+              If not specified, daemon default is used, which can either be `"private"`
+              or `"shareable"`, depending on daemon version and configuration.
+          Cgroup:
+            type: "string"
+            description: "Cgroup to use for the container."
+          Links:
+            type: "array"
+            description: |
+              A list of links for the container in the form `container_name:alias`.
+            items:
+              type: "string"
+          OomScoreAdj:
+            type: "integer"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 500
+          PidMode:
+            type: "string"
+            description: |
+              Set the PID (Process) Namespace mode for the container. It can be
+              either:
+
+              - `"container:<name|id>"`: joins another container's PID namespace
+              - `"host"`: use the host's PID namespace inside the container
+          Privileged:
+            type: "boolean"
+            description: |-
+              Gives the container full access to the host.
+          PublishAllPorts:
+            type: "boolean"
+            description: |
+              Allocates an ephemeral host port for all of a container's
+              exposed ports.
+
+              Ports are de-allocated when the container stops and allocated when
+              the container starts. The allocated port might be changed when
+              restarting the container.
+
+              The port is selected from the ephemeral port range that depends on
+              the kernel. For example, on Linux the range is defined by
+              `/proc/sys/net/ipv4/ip_local_port_range`.
+          ReadonlyRootfs:
+            type: "boolean"
+            description: "Mount the container's root filesystem as read only."
+          SecurityOpt:
+            type: "array"
+            description: |
+              A list of string values to customize labels for MLS systems, such
+              as SELinux.
+            items:
+              type: "string"
+          StorageOpt:
+            type: "object"
+            description: |
+              Storage driver options for this container, in the form `{"size": "120G"}`.
+            additionalProperties:
+              type: "string"
+          Tmpfs:
+            type: "object"
+            description: |
+              A map of container directories which should be replaced by tmpfs
+              mounts, and their corresponding mount options. For example:
+
+              ```
+              { "/run": "rw,noexec,nosuid,size=65536k" }
+              ```
+            additionalProperties:
+              type: "string"
+          UTSMode:
+            type: "string"
+            description: "UTS namespace to use for the container."
+          UsernsMode:
+            type: "string"
+            description: |
+              Sets the usernamespace mode for the container when usernamespace
+              remapping option is enabled.
+          ShmSize:
+            type: "integer"
+            format: "int64"
+            description: |
+              Size of `/dev/shm` in bytes. If omitted, the system uses 64MB.
+            minimum: 0
+          Sysctls:
+            type: "object"
+            x-nullable: true
+            description: |-
+              A list of kernel parameters (sysctls) to set in the container.
+
+              This field is omitted if not set.
+            additionalProperties:
+              type: "string"
+            example:
+              "net.ipv4.ip_forward": "1"
+          Runtime:
+            type: "string"
+            x-nullable: true
+            description: |-
+              Runtime to use with this container.
+          # Applicable to Windows
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the container. (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          MaskedPaths:
+            type: "array"
+            description: |
+              The list of paths to be masked inside the container (this overrides
+              the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/asound"
+              - "/proc/acpi"
+              - "/proc/kcore"
+              - "/proc/keys"
+              - "/proc/latency_stats"
+              - "/proc/timer_list"
+              - "/proc/timer_stats"
+              - "/proc/sched_debug"
+              - "/proc/scsi"
+              - "/sys/firmware"
+              - "/sys/devices/virtual/powercap"
+          ReadonlyPaths:
+            type: "array"
+            description: |
+              The list of paths to be set as read-only inside the container
+              (this overrides the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/bus"
+              - "/proc/fs"
+              - "/proc/irq"
+              - "/proc/sys"
+              - "/proc/sysrq-trigger"
+
+  ContainerConfig:
+    description: |
+      Configuration for a container that is portable between hosts.
+    type: "object"
+    properties:
+      Hostname:
+        description: |
+          The hostname to use for the container, as a valid RFC 1123 hostname.
+        type: "string"
+        example: "439f4e91bd1d"
+      Domainname:
+        description: |
+          The domain name to use for the container.
+        type: "string"
+      User:
+        description: |-
+          Commands run as this user inside the container. If omitted, commands
+          run as the user specified in the image the container was started from.
+
+          Can be either user-name or UID, and optional group-name or GID,
+          separated by a colon (`<user-name|UID>[<:group-name|GID>]`).
+        type: "string"
+        example: "123:456"
+      AttachStdin:
+        description: "Whether to attach to `stdin`."
+        type: "boolean"
+        default: false
+      AttachStdout:
+        description: "Whether to attach to `stdout`."
+        type: "boolean"
+        default: true
+      AttachStderr:
+        description: "Whether to attach to `stderr`."
+        type: "boolean"
+        default: true
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Tty:
+        description: |
+          Attach standard streams to a TTY, including `stdin` if it is not closed.
+        type: "boolean"
+        default: false
+      OpenStdin:
+        description: "Open `stdin`"
+        type: "boolean"
+        default: false
+      StdinOnce:
+        description: "Close `stdin` after one attached client disconnects"
+        type: "boolean"
+        default: false
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Image:
+        description: |
+          The name (or reference) of the image to use when creating the container,
+          or which was used when the container was created.
+        type: "string"
+        example: "example-image:1.0"
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      NetworkDisabled:
+        description: "Disable networking for the container."
+        type: "boolean"
+        x-nullable: true
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      StopTimeout:
+        description: "Timeout to stop a container in seconds."
+        type: "integer"
+        default: 10
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  ImageConfig:
+    description: |
+      Configuration of the image. These fields are used as defaults
+      when starting a container from the image.
+    type: "object"
+    properties:
+      User:
+        description: "The user that commands are run as inside the container."
+        type: "string"
+        example: "web:web"
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example:
+          "/app/data": {}
+          "/app/config": {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  NetworkingConfig:
+    description: |
+      NetworkingConfig represents the container's networking configuration for
+      each of its interfaces.
+      It is used for the networking configs specified in the `docker create`
+      and `docker network connect` commands.
+    type: "object"
+    properties:
+      EndpointsConfig:
+        description: |
+          A mapping of network name to endpoint configuration for that network.
+          The endpoint configuration can be left empty to connect to that
+          network with no particular endpoint configuration.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+    example:
+      # putting an example here, instead of using the example values from
+      # /definitions/EndpointSettings, because EndpointSettings contains
+      # operational data returned when inspecting a container that we don't
+      # accept here.
+      EndpointsConfig:
+        isolated_nw:
+          IPAMConfig:
+            IPv4Address: "172.20.30.33"
+            IPv6Address: "2001:db8:abcd::3033"
+            LinkLocalIPs:
+              - "169.254.34.68"
+              - "fe80::3468"
+          MacAddress: "02:42:ac:12:05:02"
+          Links:
+            - "container_1"
+            - "container_2"
+          Aliases:
+            - "server_x"
+            - "server_y"
+        database_nw: {}
+
+  NetworkSettings:
+    description: "NetworkSettings exposes the network settings in the API"
+    type: "object"
+    properties:
+      SandboxID:
+        description: SandboxID uniquely represents a container's network stack.
+        type: "string"
+        example: "9d12daf2c33f5959c8bf90aa513e4f65b561738661003029ec84830cd503a0c3"
+      SandboxKey:
+        description: SandboxKey is the full path of the netns handle
+        type: "string"
+        example: "/var/run/docker/netns/8ab54b426c38"
+      Ports:
+        $ref: "#/definitions/PortMap"
+      Networks:
+        description: |
+          Information about all networks that the container is connected to.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+
+  Address:
+    description: Address represents an IPv4 or IPv6 IP address.
+    type: "object"
+    properties:
+      Addr:
+        description: IP address.
+        type: "string"
+      PrefixLen:
+        description: Mask length of the IP address.
+        type: "integer"
+
+  PortMap:
+    description: |
+      PortMap describes the mapping of container ports to host ports, using the
+      container's port-number and protocol as key in the format `<port>/<protocol>`,
+      for example, `80/udp`.
+
+      If a container's port is mapped for multiple protocols, separate entries
+      are added to the mapping table.
+    type: "object"
+    additionalProperties:
+      type: "array"
+      x-nullable: true
+      items:
+        $ref: "#/definitions/PortBinding"
+    example:
+      "443/tcp":
+        - HostIp: "127.0.0.1"
+          HostPort: "4443"
+      "80/tcp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+        - HostIp: "0.0.0.0"
+          HostPort: "8080"
+      "80/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+      "53/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "53"
+      "2377/tcp": null
+
+  PortBinding:
+    description: |
+      PortBinding represents a binding between a host IP address and a host
+      port.
+    type: "object"
+    properties:
+      HostIp:
+        description: "Host IP address that the container's port is mapped to."
+        type: "string"
+        example: "127.0.0.1"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      HostPort:
+        description: "Host port number that the container's port is mapped to."
+        type: "string"
+        example: "4443"
+
+  DriverData:
+    description: |
+      Information about the storage driver used to store the container's and
+      image's filesystem.
+    type: "object"
+    required: [Name, Data]
+    properties:
+      Name:
+        description: "Name of the storage driver."
+        type: "string"
+        x-nullable: false
+        example: "overlay2"
+      Data:
+        description: |
+          Low-level storage metadata, provided as key/value pairs.
+
+          This information is driver-specific, and depends on the storage-driver
+          in use, and should be used for informational purposes only.
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example: {
+          "MergedDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/merged",
+          "UpperDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/diff",
+          "WorkDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/work"
+        }
+
+  Storage:
+    description: |
+      Information about the storage used by the container.
+    type: "object"
+    properties:
+      RootFS:
+        description: |
+          Information about the storage used for the container's root filesystem.
+        type: "object"
+        x-nullable: true
+        $ref: "#/definitions/RootFSStorage"
+
+  RootFSStorage:
+    description: |
+      Information about the storage used for the container's root filesystem.
+    type: "object"
+    x-go-name: RootFSStorage
+    properties:
+      Snapshot:
+        description: |
+          Information about the snapshot used for the container's root filesystem.
+        type: "object"
+        x-nullable: true
+        $ref: "#/definitions/RootFSStorageSnapshot"
+
+  RootFSStorageSnapshot:
+    description: |
+      Information about a snapshot backend of the container's root filesystem.
+    type: "object"
+    x-go-name: RootFSStorageSnapshot
+    properties:
+      Name:
+        description: "Name of the snapshotter."
+        type: "string"
+        x-nullable: false
+
+  FilesystemChange:
+    description: |
+      Change in the container's filesystem.
+    type: "object"
+    required: [Path, Kind]
+    properties:
+      Path:
+        description: |
+          Path to file or directory that has changed.
+        type: "string"
+        x-nullable: false
+      Kind:
+        $ref: "#/definitions/ChangeType"
+
+  ChangeType:
+    description: |
+      Kind of change
+
+      Can be one of:
+
+      - `0`: Modified ("C")
+      - `1`: Added ("A")
+      - `2`: Deleted ("D")
+    type: "integer"
+    format: "uint8"
+    enum: [0, 1, 2]
+    x-nullable: false
+
+  ImageInspect:
+    description: |
+      Information about an image in the local image cache.
+    type: "object"
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+      Manifests:
+        description: |
+          Manifests is a list of image manifests available in this image. It
+          provides a more detailed view of the platform-specific image manifests or
+          other image-attached data like build attestations.
+
+          Only available if the daemon provides a multi-platform image store
+          and the `manifests` option is set in the inspect request.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        type: "array"
+        x-nullable: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      Identity:
+        description: |-
+          Identity holds information about the identity and origin of the image.
+          This is trusted information verified by the daemon and cannot be modified
+          by tagging an image to a different name.
+        x-nullable: true
+        $ref: "#/definitions/Identity"
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Comment:
+        description: |
+          Optional message that was set when committing or importing the image.
+        type: "string"
+        x-nullable: true
+        example: ""
+      Created:
+        description: |
+          Date and time at which the image was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+          This information is only available if present in the image,
+          and omitted otherwise.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2022-02-04T21:20:12.497794809Z"
+      Author:
+        description: |
+          Name of the author that was specified when committing the image, or as
+          specified through MAINTAINER (deprecated) in the Dockerfile.
+        type: "string"
+        x-nullable: true
+        example: ""
+      Config:
+        $ref: "#/definitions/ImageConfig"
+      Architecture:
+        description: |
+          Hardware CPU architecture that the image runs on.
+        type: "string"
+        x-nullable: false
+        example: "arm"
+      Variant:
+        description: |
+          CPU architecture variant (presently ARM-only).
+        type: "string"
+        x-nullable: true
+        example: "v7"
+      Os:
+        description: |
+          Operating System the image is built to run on.
+        type: "string"
+        x-nullable: false
+        example: "linux"
+      OsVersion:
+        description: |
+          Operating System version the image is built to run on (especially
+          for Windows).
+        type: "string"
+        example: ""
+        x-nullable: true
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      GraphDriver:
+        x-nullable: true
+        $ref: "#/definitions/DriverData"
+      RootFS:
+        description: |
+          Information about the image's RootFS, including the layer IDs.
+        type: "object"
+        required: [Type]
+        properties:
+          Type:
+            type: "string"
+            x-nullable: false
+            example: "layers"
+          Layers:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "sha256:1834950e52ce4d5a88a1bbd131c537f4d0e56d10ff0dd69e66be3b7dfa9df7e6"
+              - "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"
+      Metadata:
+        description: |
+          Additional metadata of the image in the local cache. This information
+          is local to the daemon, and not part of the image itself.
+        type: "object"
+        properties:
+          LastTagTime:
+            description: |
+              Date and time at which the image was last tagged in
+              [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+              This information is only available if the image was tagged locally,
+              and omitted otherwise.
+            type: "string"
+            format: "dateTime"
+            example: "2022-02-28T14:40:02.623929178Z"
+            x-nullable: true
+
+  Identity:
+    description: |-
+      Identity holds information about the identity and origin of the image.
+      This is trusted information verified by the daemon and cannot be modified
+      by tagging an image to a different name.
+    type: "object"
+    properties:
+      Signature:
+        description: |-
+          Signature contains the properties of verified signatures for the image.
+        type: "array"
+        items:
+          $ref: "#/definitions/SignatureIdentity"
+      Pull:
+        description: |-
+          Pull contains remote location information if image was created via pull.
+          If image was pulled via mirror, this contains the original repository location.
+          After successful push this images also contains the pushed repository location.
+        type: "array"
+        items:
+          $ref: "#/definitions/PullIdentity"
+      Build:
+        description: |-
+          Build contains build reference information if image was created via build.
+        type: "array"
+        items:
+          $ref: "#/definitions/BuildIdentity"
+
+  BuildIdentity:
+    description: |-
+      BuildIdentity contains build reference information if image was created via build.
+    type: "object"
+    properties:
+      Ref:
+        description: |-
+          Ref is the identifier for the build request. This reference can be used to
+          look up the build details in BuildKit history API.
+        type: "string"
+      CreatedAt:
+        description: |-
+          CreatedAt is the time when the build ran.
+        type: "string"
+        format: "date-time"
+
+  PullIdentity:
+    description: |-
+      PullIdentity contains remote location information if image was created via pull.
+      If image was pulled via mirror, this contains the original repository location.
+    type: "object"
+    properties:
+      Repository:
+        description: |-
+          Repository is the remote repository location the image was pulled from.
+        type: "string"
+
+  SignatureIdentity:
+    description: |-
+      SignatureIdentity contains the properties of verified signatures for the image.
+    type: "object"
+    properties:
+      Name:
+        description: |-
+          Name is a textual description summarizing the type of signature.
+        type: "string"
+      Timestamps:
+        description: |-
+          Timestamps contains a list of verified signed timestamps for the signature.
+        type: "array"
+        items:
+          $ref: "#/definitions/SignatureTimestamp"
+      KnownSigner:
+        description: |-
+          KnownSigner is an identifier for a special signer identity that is known to the implementation.
+        $ref: "#/definitions/KnownSignerIdentity"
+      DockerReference:
+        description: |-
+          DockerReference is the Docker image reference associated with the signature.
+          This is an optional field only present in older hashedrecord signatures.
+        type: "string"
+      Signer:
+        description: |-
+          Signer contains information about the signer certificate used to sign the image.
+        $ref: "#/definitions/SignerIdentity"
+      SignatureType:
+        description: |-
+          SignatureType is the type of signature format. E.g. "bundle-v0.3" or "hashedrecord".
+        $ref: "#/definitions/SignatureType"
+      Error:
+        description: |-
+          Error contains error information if signature verification failed.
+          Other fields will be empty in this case.
+        type: "string"
+      Warnings:
+        description: |-
+          Warnings contains any warnings that occurred during signature verification.
+          For example, if there was no internet connectivity and cached trust roots were used.
+          Warning does not indicate a failed verification but may point to configuration issues.
+        type: "array"
+        items:
+          type: "string"
+
+  SignatureTimestamp:
+    description: |-
+      SignatureTimestamp contains information about a verified signed timestamp for an image signature.
+    type: "object"
+    properties:
+      Type:
+        $ref: "#/definitions/SignatureTimestampType"
+      URI:
+        type: "string"
+      Timestamp:
+        type: "string"
+        format: "date-time"
+
+  SignatureTimestampType:
+    description: |-
+      SignatureTimestampType is the type of timestamp used in the signature.
+    type: "string"
+    enum:
+      - "Tlog"
+      - "TimestampAuthority"
+
+  SignatureType:
+    description: |-
+      SignatureType is the type of signature format.
+    type: "string"
+    enum:
+      - "bundle-v0.3"
+      - "simplesigning-v1"
+
+  KnownSignerIdentity:
+    description: |-
+      KnownSignerIdentity is an identifier for a special signer identity that is known to the implementation.
+    type: "string"
+    enum:
+      - "DHI"
+
+  SignerIdentity:
+    description: |-
+      SignerIdentity contains information about the signer certificate used to sign the image.
+    type: "object"
+    properties:
+      CertificateIssuer:
+        type: "string"
+        description: |-
+          CertificateIssuer is the certificate issuer.
+      SubjectAlternativeName:
+        type: "string"
+        description: |-
+          SubjectAlternativeName is the certificate subject alternative name.
+      Issuer:
+        type: "string"
+        description: |-
+          The OIDC issuer. Should match `iss` claim of ID token or, in the case of
+          a federated login like Dex it should match the issuer URL of the
+          upstream issuer. The issuer is not set the extensions are invalid and
+          will fail to render.
+      BuildSignerURI:
+        type: "string"
+        description: |-
+          Reference to specific build instructions that are responsible for signing.
+      BuildSignerDigest:
+        type: "string"
+        description: |-
+          Immutable reference to the specific version of the build instructions that is responsible for signing.
+      RunnerEnvironment:
+        type: "string"
+        description: |-
+          Specifies whether the build took place in platform-hosted cloud infrastructure or customer/self-hosted infrastructure.
+      SourceRepositoryURI:
+        type: "string"
+        description: |-
+          Source repository URL that the build was based on.
+      SourceRepositoryDigest:
+        type: "string"
+        description: |-
+          Immutable reference to a specific version of the source code that the build was based upon.
+      SourceRepositoryRef:
+        type: "string"
+        description: |-
+          Source Repository Ref that the build run was based upon.
+      SourceRepositoryIdentifier:
+        type: "string"
+        description: |-
+          Immutable identifier for the source repository the workflow was based upon.
+      SourceRepositoryOwnerURI:
+        type: "string"
+        description: |-
+          Source repository owner URL of the owner of the source repository that the build was based on.
+      SourceRepositoryOwnerIdentifier:
+        type: "string"
+        description: |-
+          Immutable identifier for the owner of the source repository that the workflow was based upon.
+      BuildConfigURI:
+        type: "string"
+        description: |-
+          Build Config URL to the top-level/initiating build instructions.
+      BuildConfigDigest:
+        type: "string"
+        description: |-
+          Immutable reference to the specific version of the top-level/initiating build instructions.
+      BuildTrigger:
+        type: "string"
+        description: |-
+          Event or action that initiated the build.
+      RunInvocationURI:
+        type: "string"
+        description: |-
+          Run Invocation URL to uniquely identify the build execution.
+      SourceRepositoryVisibilityAtSigning:
+        type: "string"
+        description: |-
+          Source repository visibility at the time of signing the certificate.
+
+  ImageSummary:
+    type: "object"
+    x-go-name: "Summary"
+    required:
+      - Id
+      - ParentId
+      - RepoTags
+      - RepoDigests
+      - Created
+      - Size
+      - SharedSize
+      - Labels
+      - Containers
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      ParentId:
+        description: |
+          ID of the parent image.
+
+          Depending on how the image was created, this field may be empty and
+          is only set for images that were built/created locally. This field
+          is empty if the image was pulled from an image registry.
+        type: "string"
+        x-nullable: false
+        example: ""
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Created:
+        description: |
+          Date and time at which the image was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        x-nullable: false
+        example: "1644009612"
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 172064416
+      SharedSize:
+        description: |
+          Total size of image layers that are shared between this image and other
+          images.
+
+          This size is not calculated by default. `-1` indicates that the value
+          has not been set / calculated.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Containers:
+        description: |
+          Number of containers using this image. Includes both stopped and running
+          containers.
+
+          `-1` indicates that the value has not been set / calculated.
+        x-nullable: false
+        type: "integer"
+        example: 2
+      Manifests:
+        description: |
+          Manifests is a list of manifests available in this image.
+          It provides a more detailed view of the platform-specific image manifests
+          or other image-attached data like build attestations.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        type: "array"
+        x-nullable: false
+        x-omitempty: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+
+  ImagesDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/image"
+    description: |
+      represents system data usage for image resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active images.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all images.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing unused images.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by images.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of image summaries.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Summary
+
+  AuthConfig:
+    type: "object"
+    properties:
+      username:
+        type: "string"
+      password:
+        type: "string"
+      serveraddress:
+        type: "string"
+    example:
+      username: "hannibal"
+      password: "xxxx"
+      serveraddress: "https://index.docker.io/v1/"
+
+  AuthResponse:
+    description: |
+      An identity token was generated successfully.
+    type: "object"
+    required: [Status]
+    properties:
+      Status:
+        description: "The status of the authentication"
+        type: "string"
+        example: "Login Succeeded"
+        x-nullable: false
+      IdentityToken:
+        description: "An opaque token used to authenticate a user after a successful login"
+        type: "string"
+        example: "9cbaf023786cd7..."
+        x-nullable: false
+
+  ProcessConfig:
+    type: "object"
+    properties:
+      privileged:
+        type: "boolean"
+      user:
+        type: "string"
+      tty:
+        type: "boolean"
+      entrypoint:
+        type: "string"
+      arguments:
+        type: "array"
+        items:
+          type: "string"
+
+  Volume:
+    type: "object"
+    required: [Name, Driver, Mountpoint, Labels, Scope, Options]
+    x-nullable: false
+    properties:
+      Name:
+        type: "string"
+        description: "Name of the volume."
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        type: "string"
+        description: "Name of the volume driver used by the volume."
+        x-nullable: false
+        example: "custom"
+      Mountpoint:
+        type: "string"
+        description: "Mount path of the volume on the host."
+        x-nullable: false
+        example: "/var/lib/docker/volumes/tardis"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        description: "Date/Time the volume was created."
+        example: "2016-06-07T20:31:11.853781916Z"
+      Status:
+        type: "object"
+        description: |
+          Low-level details about the volume, provided by the volume driver.
+          Details are returned as a map with key/value pairs:
+          `{"key":"value","key2":"value2"}`.
+
+          The `Status` field is optional, and is omitted if the volume driver
+          does not support this feature.
+        additionalProperties:
+          type: "object"
+        example:
+          hello: "world"
+      Labels:
+        type: "object"
+        description: "User-defined key/value metadata."
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Scope:
+        type: "string"
+        description: |
+          The level at which the volume exists. Either `global` for cluster-wide,
+          or `local` for machine level.
+        default: "local"
+        x-nullable: false
+        enum: ["local", "global"]
+        example: "local"
+      ClusterVolume:
+        $ref: "#/definitions/ClusterVolume"
+      Options:
+        type: "object"
+        description: |
+          The driver specific options used when creating the volume.
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      UsageData:
+        type: "object"
+        x-nullable: true
+        x-go-name: "UsageData"
+        required: [Size, RefCount]
+        description: |
+          Usage details about the volume. This information is used by the
+          `GET /system/df` endpoint, and omitted in other endpoints.
+        properties:
+          Size:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              Amount of disk space used by the volume (in bytes). This information
+              is only available for volumes created with the `"local"` volume
+              driver. For volumes created with other volume drivers, this field
+              is set to `-1` ("not available")
+            x-nullable: false
+          RefCount:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              The number of containers referencing this volume. This field
+              is set to `-1` if the reference-count is not available.
+            x-nullable: false
+
+  VolumesDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/volume"
+    description: |
+      represents system data usage for volume resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active volumes.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all volumes.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive volumes.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by volumes.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of volumes.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Volume
+
+  VolumeCreateRequest:
+    description: "Volume configuration"
+    type: "object"
+    title: "VolumeConfig"
+    x-go-name: "CreateRequest"
+    properties:
+      Name:
+        description: |
+          The new volume's name. If not specified, Docker generates a name.
+        type: "string"
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        description: "Name of the volume driver to use."
+        type: "string"
+        default: "local"
+        x-nullable: false
+        example: "custom"
+      DriverOpts:
+        description: |
+          A mapping of driver options and values. These options are
+          passed directly to the driver and are driver specific.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      ClusterVolumeSpec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+
+  VolumeListResponse:
+    type: "object"
+    title: "VolumeListResponse"
+    x-go-name: "ListResponse"
+    description: "Volume list response"
+    properties:
+      Volumes:
+        type: "array"
+        description: "List of volumes"
+        items:
+          $ref: "#/definitions/Volume"
+      Warnings:
+        type: "array"
+        description: |
+          Warnings that occurred when fetching the list of volumes.
+        items:
+          type: "string"
+        example: []
+
+  Network:
+    type: "object"
+    properties:
+      Name:
+        description: |
+          Name of the network.
+        type: "string"
+        example: "my_network"
+        x-omitempty: false
+      Id:
+        description: |
+          ID that uniquely identifies a network on a single machine.
+        type: "string"
+        x-go-name: "ID"
+        x-omitempty: false
+        example: "7d86d31b1478e7cca9ebed7e73aa0fdeec46c5ca29497431d3007d2d9e15ed99"
+      Created:
+        description: |
+          Date and time at which the network was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-omitempty: false
+        x-go-type:
+          type: Time
+          import:
+            package: time
+          hints:
+            nullable: false
+        example: "2016-10-19T04:33:30.360899459Z"
+      Scope:
+        description: |
+          The level at which the network exists (e.g. `swarm` for cluster-wide
+          or `local` for machine level)
+        type: "string"
+        x-omitempty: false
+        example: "local"
+      Driver:
+        description: |
+          The name of the driver used to create the network (e.g. `bridge`,
+          `overlay`).
+        type: "string"
+        x-omitempty: false
+        example: "overlay"
+      EnableIPv4:
+        description: |
+          Whether the network was created with IPv4 enabled.
+        type: "boolean"
+        x-omitempty: false
+        example: true
+      EnableIPv6:
+        description: |
+          Whether the network was created with IPv6 enabled.
+        type: "boolean"
+        x-omitempty: false
+        example: false
+      IPAM:
+        description: |
+          The network's IP Address Management.
+        $ref: "#/definitions/IPAM"
+        x-nullable: false
+        x-omitempty: false
+      Internal:
+        description: |
+          Whether the network is created to only allow internal networking
+          connectivity.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      Attachable:
+        description: |
+          Whether a global / swarm scope network is manually attachable by regular
+          containers from workers in swarm mode.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      Ingress:
+        description: |
+          Whether the network is providing the routing-mesh for the swarm cluster.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      ConfigFrom:
+        $ref: "#/definitions/ConfigReference"
+        x-nullable: false
+        x-omitempty: false
+      ConfigOnly:
+        description: |
+          Whether the network is a config-only network. Config-only networks are
+          placeholder networks for network configurations to be used by other
+          networks. Config-only networks cannot be used directly to run containers
+          or services.
+        type: "boolean"
+        x-omitempty: false
+        x-nullable: false
+        default: false
+      Options:
+        description: |
+          Network-specific options uses when creating the network.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.docker.network.bridge.default_bridge: "true"
+          com.docker.network.bridge.enable_icc: "true"
+          com.docker.network.bridge.enable_ip_masquerade: "true"
+          com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+          com.docker.network.bridge.name: "docker0"
+          com.docker.network.driver.mtu: "1500"
+      Labels:
+        description: |
+          Metadata specific to the network being created.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Peers:
+        description: |
+          List of peer nodes for an overlay network. This field is only present
+          for overlay networks, and omitted for other network types.
+        type: "array"
+        x-omitempty: true
+        items:
+          $ref: "#/definitions/PeerInfo"
+
+  NetworkSummary:
+    description: "Network list response item"
+    x-go-name: Summary
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/Network"
+
+  NetworkInspect:
+    description: 'The body of the "get network" http response message.'
+    x-go-name: Inspect
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/Network"
+    properties:
+      Containers:
+        description: |
+          Contains endpoints attached to the network.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          $ref: "#/definitions/EndpointResource"
+        example:
+          19a4d5d687db25203351ed79d478946f861258f018fe384f229f2efa4b23513c:
+            Name: "test"
+            EndpointID: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+            MacAddress: "02:42:ac:13:00:02"
+            IPv4Address: "172.19.0.2/16"
+            IPv6Address: ""
+      Services:
+        description: |
+          List of services using the network. This field is only present for
+          swarm scope networks, and omitted for local scope networks.
+        type: "object"
+        x-omitempty: true
+        additionalProperties:
+          x-go-type:
+            type: ServiceInfo
+            hints:
+              nullable: false
+      Status:
+        description: >
+          provides runtime information about the network
+          such as the number of allocated IPs.
+        $ref: "#/definitions/NetworkStatus"
+
+  NetworkStatus:
+    description: >
+      provides runtime information about the network
+      such as the number of allocated IPs.
+    type: "object"
+    x-go-name: Status
+    properties:
+      IPAM:
+        $ref: "#/definitions/IPAMStatus"
+
+  ServiceInfo:
+    x-nullable: false
+    x-omitempty: false
+    description: >
+      represents service parameters with the list of service's tasks
+    type: "object"
+    properties:
+      VIP:
+        type: "string"
+        x-omitempty: false
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      Ports:
+        type: "array"
+        x-omitempty: false
+        items:
+          type: "string"
+      LocalLBIndex:
+        type: "integer"
+        format: "int"
+        x-omitempty: false
+        x-go-type:
+          type: int
+      Tasks:
+        type: "array"
+        x-omitempty: false
+        items:
+          $ref: "#/definitions/NetworkTaskInfo"
+
+  NetworkTaskInfo:
+    x-nullable: false
+    x-omitempty: false
+    x-go-name: Task
+    description: >
+      carries the information about one backend task
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        x-omitempty: false
+      EndpointID:
+        type: "string"
+        x-omitempty: false
+      EndpointIP:
+        type: "string"
+        x-omitempty: false
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      Info:
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+
+  ConfigReference:
+    x-nullable: false
+    x-omitempty: false
+    description: |
+      The config-only network source to provide the configuration for
+      this network.
+    type: "object"
+    properties:
+      Network:
+        description: |
+          The name of the config-only network that provides the network's
+          configuration. The specified network must be an existing config-only
+          network. Only network names are allowed, not network IDs.
+        type: "string"
+        x-omitempty: false
+        example: "config_only_network_01"
+
+  IPAM:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      Driver:
+        description: "Name of the IPAM driver to use."
+        type: "string"
+        default: "default"
+        example: "default"
+      Config:
+        description: |
+          List of IPAM configuration options, specified as a map:
+
+          ```
+          {"Subnet": <CIDR>, "IPRange": <CIDR>, "Gateway": <IP address>, "AuxAddress": <device_name:IP address>}
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/IPAMConfig"
+      Options:
+        description: "Driver-specific options, specified as a map."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+
+  IPAMConfig:
+    type: "object"
+    properties:
+      Subnet:
+        type: "string"
+        example: "172.20.0.0/16"
+      IPRange:
+        type: "string"
+        example: "172.20.10.0/24"
+      Gateway:
+        type: "string"
+        example: "172.20.10.11"
+      AuxiliaryAddresses:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  IPAMStatus:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      Subnets:
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/SubnetStatus"
+        example:
+          "172.16.0.0/16":
+            IPsInUse: 3
+            DynamicIPsAvailable: 65533
+          "2001:db8:abcd:0012::0/96":
+            IPsInUse: 5
+            DynamicIPsAvailable: 4294967291
+        x-go-type:
+          type: SubnetStatuses
+          kind: map
+
+  SubnetStatus:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      IPsInUse:
+        description: >
+          Number of IP addresses in the subnet that are in use or reserved and
+          are therefore unavailable for allocation, saturating at 2<sup>64</sup> - 1.
+        type: integer
+        format: uint64
+        x-omitempty: false
+      DynamicIPsAvailable:
+        description: >
+          Number of IP addresses within the network's IPRange for the subnet
+          that are available for allocation, saturating at 2<sup>64</sup> - 1.
+        type: integer
+        format: uint64
+        x-omitempty: false
+
+  EndpointResource:
+    type: "object"
+    description: >
+      contains network resources allocated and used for a
+      container in a network.
+    properties:
+      Name:
+        type: "string"
+        x-omitempty: false
+        example: "container_1"
+      EndpointID:
+        type: "string"
+        x-omitempty: false
+        example: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+      MacAddress:
+        type: "string"
+        x-omitempty: false
+        example: "02:42:ac:13:00:02"
+        x-go-type:
+          type: HardwareAddr
+      IPv4Address:
+        type: "string"
+        x-omitempty: false
+        example: "172.19.0.2/16"
+        x-go-type:
+          type: Prefix
+          import:
+            package: net/netip
+      IPv6Address:
+        type: "string"
+        x-omitempty: false
+        example: ""
+        x-go-type:
+          type: Prefix
+          import:
+            package: net/netip
+
+  PeerInfo:
+    description: >
+      represents one peer of an overlay network.
+    type: "object"
+    x-nullable: false
+    properties:
+      Name:
+        description:
+          ID of the peer-node in the Swarm cluster.
+        type: "string"
+        x-omitempty: false
+        example: "6869d7c1732b"
+      IP:
+        description:
+          IP-address of the peer-node in the Swarm cluster.
+        type: "string"
+        x-omitempty: false
+        example: "10.133.77.91"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+
+  NetworkCreateResponse:
+    description: "OK response to NetworkCreate operation"
+    type: "object"
+    title: "NetworkCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warning]
+    properties:
+      Id:
+        description: "The ID of the created network."
+        type: "string"
+        x-nullable: false
+        example: "b5c4fc71e8022147cd25de22b22173de4e3b170134117172eb595cb91b4e7e5d"
+      Warning:
+        description: "Warnings encountered when creating the container"
+        type: "string"
+        x-nullable: false
+        example: ""
+
+  BuildInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      stream:
+        type: "string"
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+      aux:
+        $ref: "#/definitions/ImageID"
+
+  BuildCache:
+    type: "object"
+    description: |
+      BuildCache contains information about a build cache record.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          Unique ID of the build cache record.
+        example: "ndlpt0hhvkqcdfkputsk4cq9c"
+      Parents:
+        description: |
+          List of parent build cache record IDs.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example: ["hw53o5aio51xtltp5xjp8v7fx"]
+      Type:
+        type: "string"
+        description: |
+          Cache record type.
+        example: "regular"
+        # see https://github.com/moby/buildkit/blob/fce4a32258dc9d9664f71a4831d5de10f0670677/client/diskusage.go#L75-L84
+        enum:
+          - "internal"
+          - "frontend"
+          - "source.local"
+          - "source.git.checkout"
+          - "exec.cachemount"
+          - "regular"
+      Description:
+        type: "string"
+        description: |
+          Description of the build-step that produced the build cache.
+        example: "mount / from exec /bin/sh -c echo 'Binary::apt::APT::Keep-Downloaded-Packages \"true\";' > /etc/apt/apt.conf.d/keep-cache"
+      InUse:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is in use.
+        example: false
+      Shared:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is shared.
+        example: true
+      Size:
+        description: |
+          Amount of disk space used by the build cache (in bytes).
+        type: "integer"
+        example: 51
+      CreatedAt:
+        description: |
+          Date and time at which the build cache was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      LastUsedAt:
+        description: |
+          Date and time at which the build cache was last used in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2017-08-09T07:09:37.632105588Z"
+      UsageCount:
+        type: "integer"
+        example: 26
+
+  BuildCacheDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/build"
+    description: |
+      represents system data usage for build cache resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active build cache records.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all build cache records.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive build cache records.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by build cache records.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of build cache records.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: CacheRecord
+
+  ImageID:
+    type: "object"
+    description: "Image ID or Digest"
+    properties:
+      ID:
+        type: "string"
+    example:
+      ID: "sha256:85f05633ddc1c50679be2b16a0479ab6f7637f8884e0cfe0f4d20e1ebb3d6e7c"
+
+  CreateImageInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  PushImageInfo:
+    type: "object"
+    properties:
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  DeviceInfo:
+    type: "object"
+    description: |
+      DeviceInfo represents a device that can be used by a container.
+    properties:
+      Source:
+        type: "string"
+        example: "cdi"
+        description: |
+          The origin device driver.
+      ID:
+        type: "string"
+        example: "vendor.com/gpu=0"
+        description: |
+          The unique identifier for the device within its source driver.
+          For CDI devices, this would be an FQDN like "vendor.com/gpu=0".
+
+  NRIInfo:
+    description: |
+      Information about the Node Resource Interface (NRI).
+
+      This field is only present if NRI is enabled.
+    type: "object"
+    x-nullable: true
+    properties:
+      Info:
+        description: |
+          Information about NRI, provided as "label" / "value" pairs.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["plugin-path", "/opt/docker/nri/plugins"]
+
+  ErrorDetail:
+    type: "object"
+    properties:
+      code:
+        type: "integer"
+      message:
+        type: "string"
+
+  ProgressDetail:
+    type: "object"
+    properties:
+      current:
+        type: "integer"
+      total:
+        type: "integer"
+
+  ErrorResponse:
+    description: "Represents an error."
+    type: "object"
+    required: ["message"]
+    properties:
+      message:
+        description: "The error message."
+        type: "string"
+        x-nullable: false
+    example:
+      message: "Something went wrong."
+
+  IDResponse:
+    description: "Response to an API call that returns just an Id"
+    type: "object"
+    x-go-name: "IDResponse"
+    required: ["Id"]
+    properties:
+      Id:
+        description: "The id of the newly created object."
+        type: "string"
+        x-nullable: false
+
+  NetworkConnectRequest:
+    description: |
+      NetworkConnectRequest represents the data to be used to connect a container to a network.
+    type: "object"
+    x-go-name: "ConnectRequest"
+    required: ["Container"]
+    properties:
+      Container:
+        type: "string"
+        description: "The ID or name of the container to connect to the network."
+        x-nullable: false
+        example: "3613f73ba0e4"
+      EndpointConfig:
+        $ref: "#/definitions/EndpointSettings"
+        x-nullable: true
+
+  NetworkDisconnectRequest:
+    description: |
+      NetworkDisconnectRequest represents the data to be used to disconnect a container from a network.
+    type: "object"
+    x-go-name: "DisconnectRequest"
+    required: ["Container"]
+    properties:
+      Container:
+        type: "string"
+        description: "The ID or name of the container to disconnect from the network."
+        x-nullable: false
+        example: "3613f73ba0e4"
+      Force:
+        type: "boolean"
+        description: "Force the container to disconnect from the network."
+        default: false
+        x-nullable: false
+        x-omitempty: false
+        example: false
+
+  EndpointSettings:
+    description: "Configuration for a network endpoint."
+    type: "object"
+    properties:
+      # Configurations
+      IPAMConfig:
+        $ref: "#/definitions/EndpointIPAMConfig"
+      Links:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "container_1"
+          - "container_2"
+      MacAddress:
+        description: |
+          MAC address for the endpoint on this network. The network driver might ignore this parameter.
+        type: "string"
+        example: "02:42:ac:11:00:04"
+        x-go-type:
+          type: HardwareAddr
+      Aliases:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "server_x"
+          - "server_y"
+      DriverOpts:
+        description: |
+          DriverOpts is a mapping of driver options and values. These options
+          are passed directly to the driver and are driver specific.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      GwPriority:
+        description: |
+          This property determines which endpoint will provide the default
+          gateway for a container. The endpoint with the highest priority will
+          be used. If multiple endpoints have the same priority, endpoints are
+          lexicographically sorted based on their network name, and the one
+          that sorts first is picked.
+        type: "integer"
+        format: "int64"
+        example:
+          - 10
+
+      # Operational data
+      NetworkID:
+        description: |
+          Unique ID of the network.
+        type: "string"
+        example: "08754567f1f40222263eab4102e1c733ae697e8e354aa9cd6e18d7402835292a"
+      EndpointID:
+        description: |
+          Unique ID for the service endpoint in a Sandbox.
+        type: "string"
+        example: "b88f5b905aabf2893f3cbc4ee42d1ea7980bbc0a92e2c8922b1e1795298afb0b"
+      Gateway:
+        description: |
+          Gateway address for this network.
+        type: "string"
+        example: "172.17.0.1"
+      IPAddress:
+        description: |
+          IPv4 address.
+        type: "string"
+        example: "172.17.0.4"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      IPPrefixLen:
+        description: |
+          Mask length of the IPv4 address.
+        type: "integer"
+        example: 16
+      IPv6Gateway:
+        description: |
+          IPv6 gateway address.
+        type: "string"
+        example: "2001:db8:2::100"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      GlobalIPv6Address:
+        description: |
+          Global IPv6 address.
+        type: "string"
+        example: "2001:db8::5689"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      GlobalIPv6PrefixLen:
+        description: |
+          Mask length of the global IPv6 address.
+        type: "integer"
+        format: "int64"
+        example: 64
+      DNSNames:
+        description: |
+          List of all DNS names an endpoint has on a specific network. This
+          list is based on the container name, network aliases, container short
+          ID, and hostname.
+
+          These DNS names are non-fully qualified but can contain several dots.
+          You can get fully qualified DNS names by appending `.<network-name>`.
+          For instance, if container name is `my.ctr` and the network is named
+          `testnet`, `DNSNames` will contain `my.ctr` and the FQDN will be
+          `my.ctr.testnet`.
+        type: array
+        items:
+          type: string
+        example: ["foobar", "server_x", "server_y", "my.ctr"]
+
+  EndpointIPAMConfig:
+    description: |
+      EndpointIPAMConfig represents an endpoint's IPAM configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      IPv4Address:
+        type: "string"
+        example: "172.20.30.33"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      IPv6Address:
+        type: "string"
+        example: "2001:db8:abcd::3033"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      LinkLocalIPs:
+        type: "array"
+        items:
+          type: "string"
+          x-go-type:
+            type: Addr
+            import:
+              package: net/netip
+        example:
+          - "169.254.34.68"
+          - "fe80::3468"
+
+  PluginMount:
+    type: "object"
+    x-go-name: "Mount"
+    x-nullable: false
+    required: [Name, Description, Settable, Source, Destination, Type, Options]
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "some-mount"
+      Description:
+        type: "string"
+        x-nullable: false
+        example: "This is a mount that's used by the plugin."
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Source:
+        type: "string"
+        example: "/var/lib/docker/plugins/"
+      Destination:
+        type: "string"
+        x-nullable: false
+        example: "/mnt/state"
+      Type:
+        type: "string"
+        x-nullable: false
+        example: "bind"
+      Options:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "rbind"
+          - "rw"
+
+  PluginDevice:
+    type: "object"
+    x-go-name: "Device"
+    required: [Name, Description, Settable, Path]
+    x-nullable: false
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+      Description:
+        type: "string"
+        x-nullable: false
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Path:
+        type: "string"
+        example: "/dev/fuse"
+
+  PluginEnv:
+    type: "object"
+    x-go-name: "Env"
+    x-nullable: false
+    required: [Name, Description, Settable, Value]
+    properties:
+      Name:
+        x-nullable: false
+        type: "string"
+      Description:
+        x-nullable: false
+        type: "string"
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Value:
+        type: "string"
+
+  PluginPrivilege:
+    description: |
+      Describes a permission the user has to accept upon installing
+      the plugin.
+    type: "object"
+    x-go-name: "Privilege"
+    properties:
+      Name:
+        type: "string"
+        example: "network"
+      Description:
+        type: "string"
+      Value:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "host"
+
+  Plugin:
+    description: "A plugin for the Engine API"
+    type: "object"
+    x-go-name: "Plugin"
+    required: [Settings, Enabled, Config, Name]
+    properties:
+      Id:
+        type: "string"
+        example: "5724e2c8652da337ab2eedd19fc6fc0ec908e4bd907c7421bf6a8dfc70c4c078"
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "tiborvass/sample-volume-plugin"
+      Enabled:
+        description:
+          True if the plugin is running. False if the plugin is not running,
+          only installed.
+        type: "boolean"
+        x-nullable: false
+        example: true
+      Settings:
+        description: "user-configurable settings for the plugin."
+        type: "object"
+        x-go-name: "Settings"
+        x-nullable: false
+        required: [Args, Devices, Env, Mounts]
+        properties:
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "DEBUG=0"
+          Args:
+            type: "array"
+            items:
+              type: "string"
+          Devices:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginDevice"
+      PluginReference:
+        description: "plugin remote reference used to push/pull the plugin"
+        type: "string"
+        x-go-name: "PluginReference"
+        x-nullable: false
+        example: "localhost:5000/tiborvass/sample-volume-plugin:latest"
+      Config:
+        description: "The config of a plugin."
+        type: "object"
+        x-go-name: "Config"
+        x-nullable: false
+        required:
+          - Description
+          - Documentation
+          - Interface
+          - Entrypoint
+          - WorkDir
+          - Network
+          - Linux
+          - PidHost
+          - PropagatedMount
+          - IpcHost
+          - Mounts
+          - Env
+          - Args
+        properties:
+          Description:
+            type: "string"
+            x-nullable: false
+            example: "A sample volume plugin for Docker"
+          Documentation:
+            type: "string"
+            x-nullable: false
+            example: "https://docs.docker.com/engine/extend/plugins/"
+          Interface:
+            description: "The interface between Docker and the plugin"
+            x-nullable: false
+            type: "object"
+            x-go-name: "Interface"
+            required: [Types, Socket]
+            properties:
+              Types:
+                type: "array"
+                items:
+                  type: "string"
+                  x-go-type:
+                    type: "CapabilityID"
+                example:
+                  - "docker.volumedriver/1.0"
+              Socket:
+                type: "string"
+                x-nullable: false
+                example: "plugins.sock"
+              ProtocolScheme:
+                type: "string"
+                example: "some.protocol/v1.0"
+                description: "Protocol to use for clients connecting to the plugin."
+                enum:
+                  - ""
+                  - "moby.plugins.http/v1"
+          Entrypoint:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "/usr/bin/sample-volume-plugin"
+              - "/data"
+          WorkDir:
+            type: "string"
+            x-nullable: false
+            example: "/bin/"
+          User:
+            type: "object"
+            x-go-name: "User"
+            x-nullable: false
+            properties:
+              UID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+              GID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+          Network:
+            type: "object"
+            x-go-name: "NetworkConfig"
+            x-nullable: false
+            required: [Type]
+            properties:
+              Type:
+                x-nullable: false
+                type: "string"
+                example: "host"
+          Linux:
+            type: "object"
+            x-go-name: "LinuxConfig"
+            x-nullable: false
+            required: [Capabilities, AllowAllDevices, Devices]
+            properties:
+              Capabilities:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "CAP_SYS_ADMIN"
+                  - "CAP_SYSLOG"
+              AllowAllDevices:
+                type: "boolean"
+                x-nullable: false
+                example: false
+              Devices:
+                type: "array"
+                items:
+                  $ref: "#/definitions/PluginDevice"
+          PropagatedMount:
+            type: "string"
+            x-nullable: false
+            example: "/mnt/volumes"
+          IpcHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          PidHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginEnv"
+            example:
+              - Name: "DEBUG"
+                Description: "If set, prints debug messages"
+                Settable: null
+                Value: "0"
+          Args:
+            type: "object"
+            x-go-name: "Args"
+            x-nullable: false
+            required: [Name, Description, Settable, Value]
+            properties:
+              Name:
+                x-nullable: false
+                type: "string"
+                example: "args"
+              Description:
+                x-nullable: false
+                type: "string"
+                example: "command line arguments"
+              Settable:
+                type: "array"
+                items:
+                  type: "string"
+              Value:
+                type: "array"
+                items:
+                  type: "string"
+          rootfs:
+            type: "object"
+            x-go-name: "RootFS"
+            properties:
+              type:
+                type: "string"
+                example: "layers"
+              diff_ids:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "sha256:675532206fbf3030b8458f88d6e26d4eb1577688a25efec97154c94e8b6b4887"
+                  - "sha256:e216a057b1cb1efc11f8a268f37ef62083e70b1b38323ba252e25ac88904a7e8"
+
+  ObjectVersion:
+    description: |
+      The version number of the object such as node, service, etc. This is needed
+      to avoid conflicting writes. The client must send the version number along
+      with the modified specification when updating these objects.
+
+      This approach ensures safe concurrency and determinism in that the change
+      on the object may not be applied if the version number has changed from the
+      last read. In other words, if two update requests specify the same base
+      version, only one of the requests can succeed. As a result, two separate
+      update requests that happen at the same time will not unintentionally
+      overwrite each other.
+    type: "object"
+    properties:
+      Index:
+        type: "integer"
+        format: "uint64"
+        example: 373531
+
+  NodeSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "Name for the node."
+        type: "string"
+        example: "my-node"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Role:
+        description: "Role of the node."
+        type: "string"
+        enum:
+          - "worker"
+          - "manager"
+        example: "manager"
+      Availability:
+        description: "Availability of the node."
+        type: "string"
+        enum:
+          - "active"
+          - "pause"
+          - "drain"
+        example: "active"
+    example:
+      Availability: "active"
+      Name: "node-name"
+      Role: "manager"
+      Labels:
+        foo: "bar"
+
+  Node:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "24ifsmvkjbyhk"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the node was added to the swarm in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the node was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/NodeSpec"
+      Description:
+        $ref: "#/definitions/NodeDescription"
+      Status:
+        $ref: "#/definitions/NodeStatus"
+      ManagerStatus:
+        $ref: "#/definitions/ManagerStatus"
+
+  NodeDescription:
+    description: |
+      NodeDescription encapsulates the properties of the Node as reported by the
+      agent.
+    type: "object"
+    properties:
+      Hostname:
+        type: "string"
+        example: "bf3067039e47"
+      Platform:
+        $ref: "#/definitions/Platform"
+      Resources:
+        $ref: "#/definitions/ResourceObject"
+      Engine:
+        $ref: "#/definitions/EngineDescription"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+
+  Platform:
+    description: |
+      Platform represents the platform (Arch/OS).
+    type: "object"
+    properties:
+      Architecture:
+        description: |
+          Architecture represents the hardware architecture (for example,
+          `x86_64`).
+        type: "string"
+        example: "x86_64"
+      OS:
+        description: |
+          OS represents the Operating System (for example, `linux` or `windows`).
+        type: "string"
+        example: "linux"
+
+  EngineDescription:
+    description: "EngineDescription provides information about an engine."
+    type: "object"
+    properties:
+      EngineVersion:
+        type: "string"
+        example: "17.06.0"
+      Labels:
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+      Plugins:
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Type:
+              type: "string"
+            Name:
+              type: "string"
+        example:
+          - Type: "Log"
+            Name: "awslogs"
+          - Type: "Log"
+            Name: "fluentd"
+          - Type: "Log"
+            Name: "gcplogs"
+          - Type: "Log"
+            Name: "gelf"
+          - Type: "Log"
+            Name: "journald"
+          - Type: "Log"
+            Name: "json-file"
+          - Type: "Log"
+            Name: "splunk"
+          - Type: "Log"
+            Name: "syslog"
+          - Type: "Network"
+            Name: "bridge"
+          - Type: "Network"
+            Name: "host"
+          - Type: "Network"
+            Name: "ipvlan"
+          - Type: "Network"
+            Name: "macvlan"
+          - Type: "Network"
+            Name: "null"
+          - Type: "Network"
+            Name: "overlay"
+          - Type: "Volume"
+            Name: "local"
+          - Type: "Volume"
+            Name: "localhost:5000/vieux/sshfs:latest"
+          - Type: "Volume"
+            Name: "vieux/sshfs:latest"
+
+  TLSInfo:
+    description: |
+      Information about the issuer of leaf TLS certificates and the trusted root
+      CA certificate.
+    type: "object"
+    properties:
+      TrustRoot:
+        description: |
+          The root CA certificate(s) that are used to validate leaf TLS
+          certificates.
+        type: "string"
+      CertIssuerSubject:
+        description:
+          The base64-url-safe-encoded raw subject bytes of the issuer.
+        type: "string"
+      CertIssuerPublicKey:
+        description: |
+          The base64-url-safe-encoded raw public key bytes of the issuer.
+        type: "string"
+    example:
+      TrustRoot: |
+        -----BEGIN CERTIFICATE-----
+        MIIBajCCARCgAwIBAgIUbYqrLSOSQHoxD8CwG6Bi2PJi9c8wCgYIKoZIzj0EAwIw
+        EzERMA8GA1UEAxMIc3dhcm0tY2EwHhcNMTcwNDI0MjE0MzAwWhcNMzcwNDE5MjE0
+        MzAwWjATMREwDwYDVQQDEwhzd2FybS1jYTBZMBMGByqGSM49AgEGCCqGSM49AwEH
+        A0IABJk/VyMPYdaqDXJb/VXh5n/1Yuv7iNrxV3Qb3l06XD46seovcDWs3IZNV1lf
+        3Skyr0ofcchipoiHkXBODojJydSjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB
+        Af8EBTADAQH/MB0GA1UdDgQWBBRUXxuRcnFjDfR/RIAUQab8ZV/n4jAKBggqhkjO
+        PQQDAgNIADBFAiAy+JTe6Uc3KyLCMiqGl2GyWGQqQDEcO3/YG36x7om65AIhAJvz
+        pxv6zFeVEkAEEkqIYi0omA9+CjanB/6Bz4n1uw8H
+        -----END CERTIFICATE-----
+      CertIssuerSubject: "MBMxETAPBgNVBAMTCHN3YXJtLWNh"
+      CertIssuerPublicKey: "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmT9XIw9h1qoNclv9VeHmf/Vi6/uI2vFXdBveXTpcPjqx6i9wNazchk1XWV/dKTKvSh9xyGKmiIeRcE4OiMnJ1A=="
+
+  NodeStatus:
+    description: |
+      NodeStatus represents the status of a node.
+
+      It provides the current status of the node, as seen by the manager.
+    type: "object"
+    properties:
+      State:
+        $ref: "#/definitions/NodeState"
+      Message:
+        type: "string"
+        example: ""
+      Addr:
+        description: "IP address of the node."
+        type: "string"
+        example: "172.17.0.2"
+
+  NodeState:
+    description: "NodeState represents the state of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "down"
+      - "ready"
+      - "disconnected"
+    example: "ready"
+
+  ManagerStatus:
+    description: |
+      ManagerStatus represents the status of a manager.
+
+      It provides the current status of a node's manager component, if the node
+      is a manager.
+    x-nullable: true
+    type: "object"
+    properties:
+      Leader:
+        type: "boolean"
+        default: false
+        example: true
+      Reachability:
+        $ref: "#/definitions/Reachability"
+      Addr:
+        description: |
+          The IP address and port at which the manager is reachable.
+        type: "string"
+        example: "10.0.0.46:2377"
+
+  Reachability:
+    description: "Reachability represents the reachability of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "unreachable"
+      - "reachable"
+    example: "reachable"
+
+  SwarmSpec:
+    description: "User modifiable swarm configuration."
+    type: "object"
+    properties:
+      Name:
+        description: "Name of the swarm."
+        type: "string"
+        example: "default"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.corp.type: "production"
+          com.example.corp.department: "engineering"
+      Orchestration:
+        description: "Orchestration configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          TaskHistoryRetentionLimit:
+            description: |
+              The number of historic tasks to keep per instance or node. If
+              negative, never remove completed or failed tasks.
+            type: "integer"
+            format: "int64"
+            example: 10
+      Raft:
+        description: "Raft configuration."
+        type: "object"
+        properties:
+          SnapshotInterval:
+            description: "The number of log entries between snapshots."
+            type: "integer"
+            format: "uint64"
+            example: 10000
+          KeepOldSnapshots:
+            description: |
+              The number of snapshots to keep beyond the current snapshot.
+            type: "integer"
+            format: "uint64"
+          LogEntriesForSlowFollowers:
+            description: |
+              The number of log entries to keep around to sync up slow followers
+              after a snapshot is created.
+            type: "integer"
+            format: "uint64"
+            example: 500
+          ElectionTick:
+            description: |
+              The number of ticks that a follower will wait for a message from
+              the leader before becoming a candidate and starting an election.
+              `ElectionTick` must be greater than `HeartbeatTick`.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 3
+          HeartbeatTick:
+            description: |
+              The number of ticks between heartbeats. Every HeartbeatTick ticks,
+              the leader will send a heartbeat to the followers.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 1
+      Dispatcher:
+        description: "Dispatcher configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          HeartbeatPeriod:
+            description: |
+              The delay for an agent to send a heartbeat to the dispatcher.
+            type: "integer"
+            format: "int64"
+            example: 5000000000
+      CAConfig:
+        description: "CA configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          NodeCertExpiry:
+            description: "The duration node certificates are issued for."
+            type: "integer"
+            format: "int64"
+            example: 7776000000000000
+          ExternalCAs:
+            description: |
+              Configuration for forwarding signing requests to an external
+              certificate authority.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Protocol:
+                  description: |
+                    Protocol for communication with the external CA (currently
+                    only `cfssl` is supported).
+                  type: "string"
+                  enum:
+                    - "cfssl"
+                  default: "cfssl"
+                URL:
+                  description: |
+                    URL where certificate signing requests should be sent.
+                  type: "string"
+                Options:
+                  description: |
+                    An object with key/value pairs that are interpreted as
+                    protocol-specific options for the external CA driver.
+                  type: "object"
+                  additionalProperties:
+                    type: "string"
+                CACert:
+                  description: |
+                    The root CA certificate (in PEM format) this external CA uses
+                    to issue TLS certificates (assumed to be to the current swarm
+                    root CA certificate if not provided).
+                  type: "string"
+          SigningCACert:
+            description: |
+              The desired signing CA certificate for all swarm node TLS leaf
+              certificates, in PEM format.
+            type: "string"
+          SigningCAKey:
+            description: |
+              The desired signing CA key for all swarm node TLS leaf certificates,
+              in PEM format.
+            type: "string"
+          ForceRotate:
+            description: |
+              An integer whose purpose is to force swarm to generate a new
+              signing CA certificate and key, if none have been specified in
+              `SigningCACert` and `SigningCAKey`
+            format: "uint64"
+            type: "integer"
+      EncryptionConfig:
+        description: "Parameters related to encryption-at-rest."
+        type: "object"
+        properties:
+          AutoLockManagers:
+            description: |
+              If set, generate a key and use it to lock data stored on the
+              managers.
+            type: "boolean"
+            example: false
+      TaskDefaults:
+        description: "Defaults for creating tasks in this cluster."
+        type: "object"
+        properties:
+          LogDriver:
+            description: |
+              The log driver to use for tasks created in the orchestrator if
+              unspecified by a service.
+
+              Updating this value only affects new tasks. Existing tasks continue
+              to use their previously configured log driver until recreated.
+            type: "object"
+            properties:
+              Name:
+                description: |
+                  The log driver to use as a default for new tasks.
+                type: "string"
+                example: "json-file"
+              Options:
+                description: |
+                  Driver-specific options for the selected log driver, specified
+                  as key/value pairs.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "10"
+                  "max-size": "100m"
+
+  # The Swarm information for `GET /info`. It is the same as `GET /swarm`, but
+  # without `JoinTokens`.
+  ClusterInfo:
+    description: |
+      ClusterInfo represents information about the swarm as is returned by the
+      "/info" endpoint. Join-tokens are not included.
+    x-nullable: true
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the swarm."
+        type: "string"
+        example: "abajmipo7b4xz5ip2nrla6b11"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the swarm was initialised in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the swarm was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/SwarmSpec"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+      RootRotationInProgress:
+        description: |
+          Whether there is currently a root CA rotation in progress for the swarm
+        type: "boolean"
+        example: false
+      DataPathPort:
+        description: |
+          DataPathPort specifies the data path port number for data traffic.
+          Acceptable port range is 1024 to 49151.
+          If no port is set or is set to 0, the default port (4789) is used.
+        type: "integer"
+        format: "uint32"
+        default: 4789
+        example: 4789
+      DefaultAddrPool:
+        description: |
+          Default Address Pool specifies default subnet pools for global scope
+          networks.
+        type: "array"
+        items:
+          type: "string"
+          format: "CIDR"
+          example: ["10.10.0.0/16", "20.20.0.0/16"]
+      SubnetSize:
+        description: |
+          SubnetSize specifies the subnet size of the networks created from the
+          default subnet pool.
+        type: "integer"
+        format: "uint32"
+        maximum: 29
+        default: 24
+        example: 24
+
+  JoinTokens:
+    description: |
+      JoinTokens contains the tokens workers and managers need to join the swarm.
+    type: "object"
+    properties:
+      Worker:
+        description: |
+          The token workers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx"
+      Manager:
+        description: |
+          The token managers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+
+  Swarm:
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/ClusterInfo"
+      - type: "object"
+        properties:
+          JoinTokens:
+            $ref: "#/definitions/JoinTokens"
+
+  TaskSpec:
+    description: "User modifiable task configuration."
+    type: "object"
+    properties:
+      PluginSpec:
+        type: "object"
+        description: |
+          Plugin spec for the service.  *(Experimental release only.)*
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Name:
+            description: "The name or 'alias' to use for the plugin."
+            type: "string"
+          Remote:
+            description: "The plugin image reference to use."
+            type: "string"
+          Disabled:
+            description: "Disable the plugin once scheduled."
+            type: "boolean"
+          PluginPrivilege:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+      ContainerSpec:
+        type: "object"
+        description: |
+          Container spec for the service.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Image:
+            description: "The image name to use for the container"
+            type: "string"
+          Labels:
+            description: "User-defined key/value data."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          Command:
+            description: "The command to be run in the image."
+            type: "array"
+            items:
+              type: "string"
+          Args:
+            description: "Arguments to the command."
+            type: "array"
+            items:
+              type: "string"
+          Hostname:
+            description: |
+              The hostname to use for the container, as a valid
+              [RFC 1123](https://tools.ietf.org/html/rfc1123) hostname.
+            type: "string"
+          Env:
+            description: |
+              A list of environment variables in the form `VAR=value`.
+            type: "array"
+            items:
+              type: "string"
+          Dir:
+            description: "The working directory for commands to run in."
+            type: "string"
+          User:
+            description: "The user inside the container."
+            type: "string"
+          Groups:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          Privileges:
+            type: "object"
+            description: "Security options for the container"
+            properties:
+              CredentialSpec:
+                type: "object"
+                description: "CredentialSpec for managed service account (Windows only)"
+                properties:
+                  Config:
+                    type: "string"
+                    example: "0bt9dmxjvjiqermk6xrop3ekq"
+                    description: |
+                      Load credential spec from a Swarm Config with the given ID.
+                      The specified config must also be present in the Configs
+                      field with the Runtime property set.
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  File:
+                    type: "string"
+                    example: "spec.json"
+                    description: |
+                      Load credential spec from this file. The file is read by
+                      the daemon, and must be present in the `CredentialSpecs`
+                      subdirectory in the docker data directory, which defaults
+                      to `C:\ProgramData\Docker\` on Windows.
+
+                      For example, specifying `spec.json` loads
+                      `C:\ProgramData\Docker\CredentialSpecs\spec.json`.
+
+                      <p><br /></p>
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  Registry:
+                    type: "string"
+                    description: |
+                      Load credential spec from this value in the Windows
+                      registry. The specified registry value must be located in:
+
+                      `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs`
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+              SELinuxContext:
+                type: "object"
+                description: "SELinux labels of the container"
+                properties:
+                  Disable:
+                    type: "boolean"
+                    description: "Disable SELinux"
+                  User:
+                    type: "string"
+                    description: "SELinux user label"
+                  Role:
+                    type: "string"
+                    description: "SELinux role label"
+                  Type:
+                    type: "string"
+                    description: "SELinux type label"
+                  Level:
+                    type: "string"
+                    description: "SELinux level label"
+              Seccomp:
+                type: "object"
+                description: "Options for configuring seccomp on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "unconfined"
+                      - "custom"
+                  Profile:
+                    description: "The custom seccomp profile as a json object"
+                    type: "string"
+              AppArmor:
+                type: "object"
+                description: "Options for configuring AppArmor on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "disabled"
+              NoNewPrivileges:
+                type: "boolean"
+                description: "Configuration of the no_new_privs bit in the container"
+
+          TTY:
+            description: "Whether a pseudo-TTY should be allocated."
+            type: "boolean"
+          OpenStdin:
+            description: "Open `stdin`"
+            type: "boolean"
+          ReadOnly:
+            description: "Mount the container's root filesystem as read only."
+            type: "boolean"
+          Mounts:
+            description: |
+              Specification for mounts to be added to containers created as part
+              of the service.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          StopSignal:
+            description: "Signal to stop the container."
+            type: "string"
+          StopGracePeriod:
+            description: |
+              Amount of time to wait for the container to terminate before
+              forcefully killing it.
+            type: "integer"
+            format: "int64"
+          HealthCheck:
+            $ref: "#/definitions/HealthConfig"
+          Hosts:
+            type: "array"
+            description: |
+              A list of hostname/IP mappings to add to the container's `hosts`
+              file. The format of extra hosts is specified in the
+              [hosts(5)](http://man7.org/linux/man-pages/man5/hosts.5.html)
+              man page:
+
+                  IP_address canonical_hostname [aliases...]
+            items:
+              type: "string"
+          DNSConfig:
+            description: |
+              Specification for DNS related configurations in resolver configuration
+              file (`resolv.conf`).
+            type: "object"
+            properties:
+              Nameservers:
+                description: "The IP addresses of the name servers."
+                type: "array"
+                items:
+                  type: "string"
+              Search:
+                description: "A search list for host-name lookup."
+                type: "array"
+                items:
+                  type: "string"
+              Options:
+                description: |
+                  A list of internal resolver variables to be modified (e.g.,
+                  `debug`, `ndots:3`, etc.).
+                type: "array"
+                items:
+                  type: "string"
+          Secrets:
+            description: |
+              Secrets contains references to zero or more secrets that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                SecretID:
+                  description: |
+                    SecretID represents the ID of the specific secret that we're
+                    referencing.
+                  type: "string"
+                SecretName:
+                  description: |
+                    SecretName is the name of the secret that this references,
+                    but this is just provided for lookup/display purposes. The
+                    secret in the reference will be identified by its ID.
+                  type: "string"
+          OomScoreAdj:
+            type: "integer"
+            format: "int64"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 0
+          Configs:
+            description: |
+              Configs contains references to zero or more configs that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually exclusive
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                Runtime:
+                  description: |
+                    Runtime represents a target that is not mounted into the
+                    container but is used by the task
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually
+                    > exclusive
+                  type: "object"
+                ConfigID:
+                  description: |
+                    ConfigID represents the ID of the specific config that we're
+                    referencing.
+                  type: "string"
+                ConfigName:
+                  description: |
+                    ConfigName is the name of the config that this references,
+                    but this is just provided for lookup/display purposes. The
+                    config in the reference will be identified by its ID.
+                  type: "string"
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the containers running the service.
+              (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          Init:
+            description: |
+              Run an init inside the container that forwards signals and reaps
+              processes. This field is omitted if empty, and the default (as
+              configured on the daemon) is used.
+            type: "boolean"
+            x-nullable: true
+          Sysctls:
+            description: |
+              Set kernel namedspaced parameters (sysctls) in the container.
+              The Sysctls option on services accepts the same sysctls as the
+              are supported on containers. Note that while the same sysctls are
+              supported, no guarantees or checks are made about their
+              suitability for a clustered environment, and it's up to the user
+              to determine whether a given sysctl will work properly in a
+              Service.
+            type: "object"
+            additionalProperties:
+              type: "string"
+          # This option is not used by Windows containers
+          CapabilityAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+              - "CAP_SYS_ADMIN"
+              - "CAP_SYS_CHROOT"
+              - "CAP_SYSLOG"
+          CapabilityDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+          Ulimits:
+            description: |
+              A list of resource limits to set in the container. For example: `{"Name": "nofile", "Soft": 1024, "Hard": 2048}`"
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Name:
+                  description: "Name of ulimit"
+                  type: "string"
+                Soft:
+                  description: "Soft limit"
+                  type: "integer"
+                Hard:
+                  description: "Hard limit"
+                  type: "integer"
+      NetworkAttachmentSpec:
+        description: |
+          Read-only spec type for non-swarm containers attached to swarm overlay
+          networks.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        type: "object"
+        properties:
+          ContainerID:
+            description: "ID of the container represented by this task"
+            type: "string"
+      Resources:
+        description: |
+          Resource requirements which apply to each individual container created
+          as part of the service.
+        type: "object"
+        properties:
+          Limits:
+            description: "Define resources limits."
+            $ref: "#/definitions/Limit"
+          Reservations:
+            description: "Define resources reservation."
+            $ref: "#/definitions/ResourceObject"
+          SwapBytes:
+            description: |
+              Amount of swap in bytes - can only be used together with a memory limit.
+              If not specified, the default behaviour is to grant a swap space twice
+              as big as the memory limit.
+              Set to -1 to enable unlimited swap.
+            type: "integer"
+            format: "int64"
+            minimum: -1
+            x-nullable: true
+            x-omitempty: true
+          MemorySwappiness:
+            description: |
+              Tune the service's containers' memory swappiness (0 to 100).
+              If not specified, defaults to the containers' OS' default, generally 60,
+              or whatever value was predefined in the image.
+              Set to -1 to unset a previously set value.
+            type: "integer"
+            format: "int64"
+            minimum: -1
+            maximum: 100
+            x-nullable: true
+            x-omitempty: true
+      RestartPolicy:
+        description: |
+          Specification for the restart policy which applies to containers
+          created as part of this service.
+        type: "object"
+        properties:
+          Condition:
+            description: "Condition for restart."
+            type: "string"
+            enum:
+              - "none"
+              - "on-failure"
+              - "any"
+          Delay:
+            description: "Delay between restart attempts."
+            type: "integer"
+            format: "int64"
+          MaxAttempts:
+            description: |
+              Maximum attempts to restart a given container before giving up
+              (default value is 0, which is ignored).
+            type: "integer"
+            format: "int64"
+            default: 0
+          Window:
+            description: |
+              Windows is the time window used to evaluate the restart policy
+              (default value is 0, which is unbounded).
+            type: "integer"
+            format: "int64"
+            default: 0
+      Placement:
+        type: "object"
+        properties:
+          Constraints:
+            description: |
+              An array of constraint expressions to limit the set of nodes where
+              a task can be scheduled. Constraint expressions can either use a
+              _match_ (`==`) or _exclude_ (`!=`) rule. Multiple constraints find
+              nodes that satisfy every expression (AND match). Constraints can
+              match node or Docker Engine labels as follows:
+
+              node attribute       | matches                        | example
+              ---------------------|--------------------------------|-----------------------------------------------
+              `node.id`            | Node ID                        | `node.id==2ivku8v2gvtg4`
+              `node.hostname`      | Node hostname                  | `node.hostname!=node-2`
+              `node.role`          | Node role (`manager`/`worker`) | `node.role==manager`
+              `node.platform.os`   | Node operating system          | `node.platform.os==windows`
+              `node.platform.arch` | Node architecture              | `node.platform.arch==x86_64`
+              `node.labels`        | User-defined node labels       | `node.labels.security==high`
+              `engine.labels`      | Docker Engine's labels         | `engine.labels.operatingsystem==ubuntu-24.04`
+
+              `engine.labels` apply to Docker Engine labels like operating system,
+              drivers, etc. Swarm administrators add `node.labels` for operational
+              purposes by using the [`node update endpoint`](#operation/NodeUpdate).
+
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "node.hostname!=node3.corp.example.com"
+              - "node.role!=manager"
+              - "node.labels.type==production"
+              - "node.platform.os==linux"
+              - "node.platform.arch==x86_64"
+          Preferences:
+            description: |
+              Preferences provide a way to make the scheduler aware of factors
+              such as topology. They are provided in order from highest to
+              lowest precedence.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Spread:
+                  type: "object"
+                  properties:
+                    SpreadDescriptor:
+                      description: |
+                        label descriptor, such as `engine.labels.az`.
+                      type: "string"
+            example:
+              - Spread:
+                  SpreadDescriptor: "node.labels.datacenter"
+              - Spread:
+                  SpreadDescriptor: "node.labels.rack"
+          MaxReplicas:
+            description: |
+              Maximum number of replicas for per node (default value is 0, which
+              is unlimited)
+            type: "integer"
+            format: "int64"
+            default: 0
+          Platforms:
+            description: |
+              Platforms stores all the platforms that the service's image can
+              run on. This field is used in the platform filter for scheduling.
+              If empty, then the platform filter is off, meaning there are no
+              scheduling restrictions.
+            type: "array"
+            items:
+              $ref: "#/definitions/Platform"
+      ForceUpdate:
+        description: |
+          A counter that triggers an update even if no relevant parameters have
+          been changed.
+        type: "integer"
+        format: "uint64"
+      Runtime:
+        description: |
+          Runtime is the type of runtime specified for the task executor.
+        type: "string"
+      Networks:
+        description: "Specifies which networks the service should attach to."
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+      LogDriver:
+        description: |
+          Specifies the log driver to use for tasks created from this spec. If
+          not present, the default one for the swarm will be used, finally
+          falling back to the engine default if not specified.
+        type: "object"
+        properties:
+          Name:
+            type: "string"
+          Options:
+            type: "object"
+            additionalProperties:
+              type: "string"
+
+  TaskState:
+    type: "string"
+    enum:
+      - "new"
+      - "allocated"
+      - "pending"
+      - "assigned"
+      - "accepted"
+      - "preparing"
+      - "ready"
+      - "starting"
+      - "running"
+      - "complete"
+      - "shutdown"
+      - "failed"
+      - "rejected"
+      - "remove"
+      - "orphaned"
+
+  ContainerStatus:
+    type: "object"
+    description: "represents the status of a container."
+    properties:
+      ContainerID:
+        type: "string"
+      PID:
+        type: "integer"
+      ExitCode:
+        type: "integer"
+
+  PortStatus:
+    type: "object"
+    description: "represents the port status of a task's host ports whose service has published host ports"
+    properties:
+      Ports:
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  TaskStatus:
+    type: "object"
+    description: "represents the status of a task."
+    properties:
+      Timestamp:
+        type: "string"
+        format: "dateTime"
+      State:
+        $ref: "#/definitions/TaskState"
+      Message:
+        type: "string"
+      Err:
+        type: "string"
+      ContainerStatus:
+        $ref: "#/definitions/ContainerStatus"
+      PortStatus:
+        $ref: "#/definitions/PortStatus"
+
+  Task:
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the task."
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Name:
+        description: "Name of the task."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Spec:
+        $ref: "#/definitions/TaskSpec"
+      ServiceID:
+        description: "The ID of the service this task is part of."
+        type: "string"
+      Slot:
+        type: "integer"
+      NodeID:
+        description: "The ID of the node that this task is on."
+        type: "string"
+      AssignedGenericResources:
+        $ref: "#/definitions/GenericResources"
+      Status:
+        $ref: "#/definitions/TaskStatus"
+      DesiredState:
+        $ref: "#/definitions/TaskState"
+      JobIteration:
+        description: |
+          If the Service this Task belongs to is a job-mode service, contains
+          the JobIteration of the Service this Task was created for. Absent if
+          the Task was created for a Replicated or Global Service.
+        $ref: "#/definitions/ObjectVersion"
+    example:
+      ID: "0kzzo1i0y4jz6027t0k7aezc7"
+      Version:
+        Index: 71
+      CreatedAt: "2016-06-07T21:07:31.171892745Z"
+      UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+      Spec:
+        ContainerSpec:
+          Image: "redis"
+        Resources:
+          Limits: {}
+          Reservations: {}
+        RestartPolicy:
+          Condition: "any"
+          MaxAttempts: 0
+        Placement: {}
+      ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Slot: 1
+      NodeID: "60gvrl6tm78dmak4yl7srz94v"
+      Status:
+        Timestamp: "2016-06-07T21:07:31.290032978Z"
+        State: "running"
+        Message: "started"
+        ContainerStatus:
+          ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+          PID: 677
+      DesiredState: "running"
+      NetworksAttachments:
+        - Network:
+            ID: "4qvuz4ko70xaltuqbt8956gd1"
+            Version:
+              Index: 18
+            CreatedAt: "2016-06-07T20:31:11.912919752Z"
+            UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+            Spec:
+              Name: "ingress"
+              Labels:
+                com.docker.swarm.internal: "true"
+              DriverConfiguration: {}
+              IPAMOptions:
+                Driver: {}
+                Configs:
+                  - Subnet: "10.255.0.0/16"
+                    Gateway: "10.255.0.1"
+            DriverState:
+              Name: "overlay"
+              Options:
+                com.docker.network.driver.overlay.vxlanid_list: "256"
+            IPAMOptions:
+              Driver:
+                Name: "default"
+              Configs:
+                - Subnet: "10.255.0.0/16"
+                  Gateway: "10.255.0.1"
+          Addresses:
+            - "10.255.0.10/16"
+      AssignedGenericResources:
+        - DiscreteResourceSpec:
+            Kind: "SSD"
+            Value: 3
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID1"
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID2"
+
+  ServiceSpec:
+    description: "User modifiable configuration for a service."
+    type: object
+    properties:
+      Name:
+        description: "Name of the service."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      TaskTemplate:
+        $ref: "#/definitions/TaskSpec"
+      Mode:
+        description: "Scheduling mode for the service."
+        type: "object"
+        properties:
+          Replicated:
+            type: "object"
+            properties:
+              Replicas:
+                type: "integer"
+                format: "int64"
+          Global:
+            type: "object"
+          ReplicatedJob:
+            description: |
+              The mode used for services with a finite number of tasks that run
+              to a completed state.
+            type: "object"
+            properties:
+              MaxConcurrent:
+                description: |
+                  The maximum number of replicas to run simultaneously.
+                type: "integer"
+                format: "int64"
+                default: 1
+              TotalCompletions:
+                description: |
+                  The total number of replicas desired to reach the Completed
+                  state. If unset, will default to the value of `MaxConcurrent`
+                type: "integer"
+                format: "int64"
+          GlobalJob:
+            description: |
+              The mode used for services which run a task to the completed state
+              on each valid node.
+            type: "object"
+      UpdateConfig:
+        description: "Specification for the update strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be updated in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: "Amount of time between updates, in nanoseconds."
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an updated task fails to run, or stops running
+              during the update.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+              - "rollback"
+          Monitor:
+            description: |
+              Amount of time to monitor each updated task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during an update before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling out an updated task. Either
+              the old task is shut down before the new task is started, or the
+              new task is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      RollbackConfig:
+        description: "Specification for the rollback strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be rolled back in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: |
+              Amount of time between rollback iterations, in nanoseconds.
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an rolled back task fails to run, or stops
+              running during the rollback.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+          Monitor:
+            description: |
+              Amount of time to monitor each rolled back task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during a rollback before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling back a task. Either the old
+              task is shut down before the new task is started, or the new task
+              is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      Networks:
+        description: |
+          Specifies which networks the service should attach to.
+
+          Deprecated: This field is deprecated since v1.44. The Networks field in TaskSpec should be used instead.
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+
+      EndpointSpec:
+        $ref: "#/definitions/EndpointSpec"
+
+  EndpointPortConfig:
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+      Protocol:
+        type: "string"
+        enum:
+          - "tcp"
+          - "udp"
+          - "sctp"
+      TargetPort:
+        description: "The port inside the container."
+        type: "integer"
+      PublishedPort:
+        description: "The port on the swarm hosts."
+        type: "integer"
+      PublishMode:
+        description: |
+          The mode in which port is published.
+
+          <p><br /></p>
+
+          - "ingress" makes the target port accessible on every node,
+            regardless of whether there is a task for the service running on
+            that node or not.
+          - "host" bypasses the routing mesh and publish the port directly on
+            the swarm node where that service is running.
+
+        type: "string"
+        enum:
+          - "ingress"
+          - "host"
+        default: "ingress"
+        example: "ingress"
+
+  EndpointSpec:
+    description: "Properties that can be configured to access and load balance a service."
+    type: "object"
+    properties:
+      Mode:
+        description: |
+          The mode of resolution to use for internal load balancing between tasks.
+        type: "string"
+        enum:
+          - "vip"
+          - "dnsrr"
+        default: "vip"
+      Ports:
+        description: |
+          List of exposed ports that this service is accessible on from the
+          outside. Ports can only be provided if `vip` resolution mode is used.
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  Service:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ServiceSpec"
+      Endpoint:
+        type: "object"
+        properties:
+          Spec:
+            $ref: "#/definitions/EndpointSpec"
+          Ports:
+            type: "array"
+            items:
+              $ref: "#/definitions/EndpointPortConfig"
+          VirtualIPs:
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                NetworkID:
+                  type: "string"
+                Addr:
+                  type: "string"
+      UpdateStatus:
+        description: "The status of a service update."
+        type: "object"
+        properties:
+          State:
+            type: "string"
+            enum:
+              - "updating"
+              - "paused"
+              - "completed"
+          StartedAt:
+            type: "string"
+            format: "dateTime"
+          CompletedAt:
+            type: "string"
+            format: "dateTime"
+          Message:
+            type: "string"
+      ServiceStatus:
+        description: |
+          The status of the service's tasks. Provided only when requested as
+          part of a ServiceList operation.
+        type: "object"
+        properties:
+          RunningTasks:
+            description: |
+              The number of tasks for the service currently in the Running state.
+            type: "integer"
+            format: "uint64"
+            example: 7
+          DesiredTasks:
+            description: |
+              The number of tasks for the service desired to be running.
+              For replicated services, this is the replica count from the
+              service spec. For global services, this is computed by taking
+              count of all tasks for the service with a Desired State other
+              than Shutdown.
+            type: "integer"
+            format: "uint64"
+            example: 10
+          CompletedTasks:
+            description: |
+              The number of tasks for a job that are in the Completed state.
+              This field must be cross-referenced with the service type, as the
+              value of 0 may mean the service is not in a job mode, or it may
+              mean the job-mode service has no tasks yet Completed.
+            type: "integer"
+            format: "uint64"
+      JobStatus:
+        description: |
+          The status of the service when it is in one of ReplicatedJob or
+          GlobalJob modes. Absent on Replicated and Global mode services. The
+          JobIteration is an ObjectVersion, but unlike the Service's version,
+          does not need to be sent with an update request.
+        type: "object"
+        properties:
+          JobIteration:
+            description: |
+              JobIteration is a value increased each time a Job is executed,
+              successfully or otherwise. "Executed", in this case, means the
+              job as a whole has been started, not that an individual Task has
+              been launched. A job is "Executed" when its ServiceSpec is
+              updated. JobIteration can be used to disambiguate Tasks belonging
+              to different executions of a job.  Though JobIteration will
+              increase with each subsequent execution, it may not necessarily
+              increase by 1, and so JobIteration should not be used to
+            $ref: "#/definitions/ObjectVersion"
+          LastExecution:
+            description: |
+              The last time, as observed by the server, that this job was
+              started.
+            type: "string"
+            format: "dateTime"
+    example:
+      ID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Version:
+        Index: 19
+      CreatedAt: "2016-06-07T21:05:51.880065305Z"
+      UpdatedAt: "2016-06-07T21:07:29.962229872Z"
+      Spec:
+        Name: "hopeful_cori"
+        TaskTemplate:
+          ContainerSpec:
+            Image: "redis"
+          Resources:
+            Limits: {}
+            Reservations: {}
+          RestartPolicy:
+            Condition: "any"
+            MaxAttempts: 0
+          Placement: {}
+          ForceUpdate: 0
+        Mode:
+          Replicated:
+            Replicas: 1
+        UpdateConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        RollbackConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        EndpointSpec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+      Endpoint:
+        Spec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+        Ports:
+          -
+            Protocol: "tcp"
+            TargetPort: 6379
+            PublishedPort: 30001
+        VirtualIPs:
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.2/16"
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.3/16"
+
+  ImageDeleteResponseItem:
+    type: "object"
+    x-go-name: "DeleteResponse"
+    properties:
+      Untagged:
+        description: "The image ID of an image that was untagged"
+        type: "string"
+      Deleted:
+        description: "The image ID of an image that was deleted"
+        type: "string"
+
+  ServiceCreateResponse:
+    type: "object"
+    description: |
+      contains the information returned to a client on the
+      creation of a new service.
+    properties:
+      ID:
+        description: "The ID of the created service."
+        type: "string"
+        x-nullable: false
+        example: "ak7w3gjqoa3kuz8xcpnyy0pvl"
+      Warnings:
+        description: |
+          Optional warning message.
+
+          FIXME(thaJeztah): this should have "omitempty" in the generated type.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example:
+          - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ServiceUpdateResponse:
+    type: "object"
+    properties:
+      Warnings:
+        description: "Optional warning messages"
+        type: "array"
+        items:
+          type: "string"
+    example:
+      Warnings:
+        - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ContainerInspectResponse:
+    type: "object"
+    title: "ContainerInspectResponse"
+    x-go-name: "InspectResponse"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Created:
+        description: |-
+          Date and time at which the container was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2025-02-17T17:43:39.64001363Z"
+      Path:
+        description: |-
+          The path to the command being run
+        type: "string"
+        example: "/bin/sh"
+      Args:
+        description: "The arguments to the command being run"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "-c"
+          - "exit 9"
+      State:
+        $ref: "#/definitions/ContainerState"
+      Image:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ResolvConfPath:
+        description: |-
+          Location of the `/etc/resolv.conf` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/resolv.conf"
+      HostnamePath:
+        description: |-
+          Location of the `/etc/hostname` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hostname"
+      HostsPath:
+        description: |-
+          Location of the `/etc/hosts` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hosts"
+      LogPath:
+        description: |-
+          Location of the file used to buffer the container's logs. Depending on
+          the logging-driver used for the container, this field may be omitted.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        x-nullable: true
+        example: "/var/lib/docker/containers/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59-json.log"
+      Name:
+        description: |-
+          The name associated with this container.
+
+          For historic reasons, the name may be prefixed with a forward-slash (`/`).
+        type: "string"
+        example: "/funny_chatelet"
+      RestartCount:
+        description: |-
+          Number of times the container was restarted since it was created,
+          or since daemon was started.
+        type: "integer"
+        example: 0
+      Driver:
+        description: |-
+          The storage-driver used for the container's filesystem (graph-driver
+          or snapshotter).
+        type: "string"
+        example: "overlayfs"
+      Platform:
+        description: |-
+          The platform (operating system) for which the container was created.
+
+          This field was introduced for the experimental "LCOW" (Linux Containers
+          On Windows) features, which has been removed. In most cases, this field
+          is equal to the host's operating system (`linux` or `windows`).
+        type: "string"
+        example: "linux"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        description: |-
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+      MountLabel:
+        description: |-
+          SELinux mount label set for the container.
+        type: "string"
+        example: ""
+      ProcessLabel:
+        description: |-
+          SELinux process label set for the container.
+        type: "string"
+        example: ""
+      AppArmorProfile:
+        description: |-
+          The AppArmor profile set for the container.
+        type: "string"
+        example: ""
+      ExecIDs:
+        description: |-
+          IDs of exec instances that are running in the container.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example:
+          - "b35395de42bc8abd327f9dd65d913b9ba28c74d2f0734eeeae84fa1c616a0fca"
+          - "3fc1232e5cd20c8de182ed81178503dc6437f4e7ef12b52cc5e8de020652f1c4"
+      HostConfig:
+        $ref: "#/definitions/HostConfig"
+      GraphDriver:
+        $ref: "#/definitions/DriverData"
+        x-nullable: true
+      Storage:
+        $ref: "#/definitions/Storage"
+        x-nullable: true
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Mounts:
+        description: |-
+          List of mounts used by the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/MountPoint"
+      Config:
+        $ref: "#/definitions/ContainerConfig"
+      NetworkSettings:
+        $ref: "#/definitions/NetworkSettings"
+
+  ContainerSummary:
+    type: "object"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Names:
+        description: |-
+          The names associated with this container. Most containers have a single
+          name, but when using legacy "links", the container can have multiple
+          names.
+
+          For historic reasons, names are prefixed with a forward-slash (`/`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/funny_chatelet"
+      Image:
+        description: |-
+          The name or ID of the image used to create the container.
+
+          This field shows the image reference as was specified when creating the container,
+          which can be in its canonical form (e.g., `docker.io/library/ubuntu:latest`
+          or `docker.io/library/ubuntu@sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`),
+          short form (e.g., `ubuntu:latest`)), or the ID(-prefix) of the image (e.g., `72297848456d`).
+
+          The content of this field can be updated at runtime if the image used to
+          create the container is untagged, in which case the field is updated to
+          contain the the image ID (digest) it was resolved to in its canonical,
+          non-truncated form (e.g., `sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`).
+        type: "string"
+        example: "docker.io/library/ubuntu:latest"
+      ImageID:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        x-nullable: true
+        description: |
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+
+          This field is not populated in the `GET /system/df` endpoint.
+      Command:
+        description: "Command to run when starting the container"
+        type: "string"
+        example: "/bin/bash"
+      Created:
+        description: |-
+          Date and time at which the container was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        format: "int64"
+        example: "1739811096"
+      Ports:
+        description: |-
+          Port-mappings for the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/PortSummary"
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.vendor: "Acme"
+          com.example.license: "GPL"
+          com.example.version: "1.0"
+      State:
+        description: |
+          The state of this container.
+        type: "string"
+        enum:
+          - "created"
+          - "running"
+          - "paused"
+          - "restarting"
+          - "exited"
+          - "removing"
+          - "dead"
+        example: "running"
+      Status:
+        description: |-
+          Additional human-readable status of this container (e.g. `Exit 0`)
+        type: "string"
+        example: "Up 4 days"
+      HostConfig:
+        type: "object"
+        description: |-
+          Summary of host-specific runtime information of the container. This
+          is a reduced set of information in the container's "HostConfig" as
+          available in the container "inspect" response.
+        properties:
+          NetworkMode:
+            description: |-
+              Networking mode (`host`, `none`, `container:<id>`) or name of the
+              primary network the container is using.
+
+              This field is primarily for backward compatibility. The container
+              can be connected to multiple networks for which information can be
+              found in the `NetworkSettings.Networks` field, which enumerates
+              settings per network.
+            type: "string"
+            example: "mynetwork"
+          Annotations:
+            description: |-
+              Arbitrary key-value metadata attached to the container.
+            type: "object"
+            x-nullable: true
+            additionalProperties:
+              type: "string"
+            example:
+              io.kubernetes.docker.type: "container"
+              io.kubernetes.sandbox.id: "3befe639bed0fd6afdd65fd1fa84506756f59360ec4adc270b0fdac9be22b4d3"
+      NetworkSettings:
+        description: |-
+          Summary of the container's network settings
+        type: "object"
+        properties:
+          Networks:
+            type: "object"
+            description: |-
+              Summary of network-settings for each network the container is
+              attached to.
+            additionalProperties:
+              $ref: "#/definitions/EndpointSettings"
+      Mounts:
+        type: "array"
+        description: |-
+          List of mounts used by the container.
+        items:
+          $ref: "#/definitions/MountPoint"
+      Health:
+        type: "object"
+        description: |-
+          Summary of health status
+
+          Added in v1.52, before that version all container summary not include Health.
+          After this attribute introduced, it includes containers with no health checks configured,
+          or containers that are not running with none
+        properties:
+          Status:
+            type: "string"
+            description: |-
+              the health status of the container
+            enum:
+              - "none"
+              - "starting"
+              - "healthy"
+              - "unhealthy"
+            example: "healthy"
+          FailingStreak:
+            description: "FailingStreak is the number of consecutive failures"
+            type: "integer"
+            example: 0
+
+  ContainersDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/container"
+    description: |
+      represents system data usage information for container resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active containers.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all containers.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive containers.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by containers.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of container summaries.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Summary
+
+  Driver:
+    description: "Driver represents a driver (network, logging, secrets)."
+    type: "object"
+    required: [Name]
+    properties:
+      Name:
+        description: "Name of the driver."
+        type: "string"
+        x-nullable: false
+        example: "some-driver"
+      Options:
+        description: "Key/value map of driver-specific options."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          OptionA: "value for driver-specific option A"
+          OptionB: "value for driver-specific option B"
+
+  SecretSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the secret."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Data:
+        description: |
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          It must be empty if the Driver field is set, in which case the data is
+          loaded from an external secret store. The maximum allowed size is 500KB,
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
+
+          This field is only used to _create_ a secret, and is not returned by
+          other endpoints.
+        type: "string"
+        example: ""
+      Driver:
+        description: |
+          Name of the secrets driver used to fetch the secret's value from an
+          external secret store.
+        $ref: "#/definitions/Driver"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Secret:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "blt1owaxmitz71s9v5zh81zun"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      Spec:
+        $ref: "#/definitions/SecretSpec"
+
+  ConfigSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the config."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Data:
+        description: |
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
+        type: "string"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Config:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ConfigSpec"
+
+  ContainerState:
+    description: |
+      ContainerState stores container's running state. It's part of ContainerJSONBase
+      and will be returned by the "inspect" command.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          String representation of the container state. Can be one of "created",
+          "running", "paused", "restarting", "removing", "exited", or "dead".
+        type: "string"
+        enum: ["created", "running", "paused", "restarting", "removing", "exited", "dead"]
+        example: "running"
+      Running:
+        description: |
+          Whether this container is running.
+
+          Note that a running container can be _paused_. The `Running` and `Paused`
+          booleans are not mutually exclusive:
+
+          When pausing a container (on Linux), the freezer cgroup is used to suspend
+          all processes in the container. Freezing the process requires the process to
+          be running. As a result, paused containers are both `Running` _and_ `Paused`.
+
+          Use the `Status` field instead to determine if a container's state is "running".
+        type: "boolean"
+        example: true
+      Paused:
+        description: "Whether this container is paused."
+        type: "boolean"
+        example: false
+      Restarting:
+        description: "Whether this container is restarting."
+        type: "boolean"
+        example: false
+      OOMKilled:
+        description: |
+          Whether a process within this container has been killed because it ran
+          out of memory since the container was last started.
+        type: "boolean"
+        example: false
+      Dead:
+        type: "boolean"
+        example: false
+      Pid:
+        description: "The process ID of this container"
+        type: "integer"
+        example: 1234
+      ExitCode:
+        description: "The last exit code of this container"
+        type: "integer"
+        example: 0
+      Error:
+        type: "string"
+      StartedAt:
+        description: "The time when this container was last started."
+        type: "string"
+        example: "2020-01-06T09:06:59.461876391Z"
+      FinishedAt:
+        description: "The time when this container last exited."
+        type: "string"
+        example: "2020-01-06T09:07:59.461876391Z"
+      Health:
+        $ref: "#/definitions/Health"
+
+  ContainerCreateResponse:
+    description: "OK response to ContainerCreate operation"
+    type: "object"
+    title: "ContainerCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warnings]
+    properties:
+      Id:
+        description: "The ID of the created container"
+        type: "string"
+        x-nullable: false
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Warnings:
+        description: "Warnings encountered when creating the container"
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example: []
+
+  ContainerUpdateResponse:
+    type: "object"
+    title: "ContainerUpdateResponse"
+    x-go-name: "UpdateResponse"
+    description: |-
+      Response for a successful container-update.
+    properties:
+      Warnings:
+        type: "array"
+        description: |-
+          Warnings encountered when updating the container.
+        items:
+          type: "string"
+        example: ["Published ports are discarded when using host network mode"]
+
+  ContainerStatsResponse:
+    description: |
+      Statistics sample for a container.
+    type: "object"
+    x-go-name: "StatsResponse"
+    title: "ContainerStatsResponse"
+    properties:
+      id:
+        description: |
+          ID of the container for which the stats were collected.
+        type: "string"
+        x-nullable: true
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      name:
+        description: |
+          Name of the container for which the stats were collected.
+        type: "string"
+        x-nullable: true
+        example: "boring_wozniak"
+      os_type:
+        description: |
+          OSType is the OS of the container ("linux" or "windows") to allow
+          platform-specific handling of stats.
+        type: "string"
+        x-nullable: true
+        example: "linux"
+      read:
+        description: |
+          Date and time at which this sample was collected.
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:22.165243637Z"
+      cpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+      memory_stats:
+        $ref: "#/definitions/ContainerMemoryStats"
+      networks:
+        description: |
+          Network statistics for the container per interface.
+
+          This field is omitted if the container has no networking enabled.
+        x-nullable: true
+        additionalProperties:
+          $ref: "#/definitions/ContainerNetworkStats"
+        example:
+          eth0:
+            rx_bytes: 5338
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 36
+            tx_bytes: 648
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 8
+          eth5:
+            rx_bytes: 4641
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 26
+            tx_bytes: 690
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 9
+      pids_stats:
+        $ref: "#/definitions/ContainerPidsStats"
+      blkio_stats:
+        $ref: "#/definitions/ContainerBlkioStats"
+      num_procs:
+        description: |
+          The number of processors on the system.
+
+          This field is Windows-specific and always zero for Linux containers.
+        type: "integer"
+        format: "uint32"
+        example: 16
+      storage_stats:
+        $ref: "#/definitions/ContainerStorageStats"
+      preread:
+        description: |
+          Date and time at which this first sample was collected. This field
+          is not propagated if the "one-shot" option is set. If the "one-shot"
+          option is set, this field may be omitted, empty, or set to a default
+          date (`0001-01-01T00:00:00Z`).
+
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:21.160452595Z"
+      precpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+
+  ContainerBlkioStats:
+    description: |
+      BlkioStats stores all IO service stats for data read and write.
+
+      This type is Linux-specific and holds many fields that are specific to cgroups v1.
+      On a cgroup v2 host, all fields other than `io_service_bytes_recursive`
+      are omitted or `null`.
+
+      This type is only populated on Linux and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStats"
+    x-nullable: true
+    properties:
+      io_service_bytes_recursive:
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_serviced_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_queue_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_service_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_wait_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_merged_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      sectors_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+    example:
+      io_service_bytes_recursive: [
+        {"major": 254, "minor": 0, "op": "read", "value": 7593984},
+        {"major": 254, "minor": 0, "op": "write", "value": 100}
+      ]
+      io_serviced_recursive: null
+      io_queue_recursive: null
+      io_service_time_recursive: null
+      io_wait_time_recursive: null
+      io_merged_recursive: null
+      io_time_recursive: null
+      sectors_recursive: null
+
+  ContainerBlkioStatEntry:
+    description: |
+      Blkio stats entry.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStatEntry"
+    x-nullable: true
+    properties:
+      major:
+        type: "integer"
+        format: "uint64"
+        example: 254
+      minor:
+        type: "integer"
+        format: "uint64"
+        example: 0
+      op:
+        type: "string"
+        example: "read"
+      value:
+        type: "integer"
+        format: "uint64"
+        example: 7593984
+
+  ContainerCPUStats:
+    description: |
+      CPU related info of the container
+    type: "object"
+    x-go-name: "CPUStats"
+    x-nullable: true
+    properties:
+      cpu_usage:
+        $ref: "#/definitions/ContainerCPUUsage"
+      system_cpu_usage:
+        description: |
+          System Usage.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      online_cpus:
+        description: |
+          Number of online CPUs.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint32"
+        x-nullable: true
+        example: 5
+      throttling_data:
+        $ref: "#/definitions/ContainerThrottlingData"
+
+  ContainerCPUUsage:
+    description: |
+      All CPU stats aggregated since container inception.
+    type: "object"
+    x-go-name: "CPUUsage"
+    x-nullable: true
+    properties:
+      total_usage:
+        description: |
+          Total CPU time consumed in nanoseconds (Linux) or 100's of nanoseconds (Windows).
+        type: "integer"
+        format: "uint64"
+        example: 29912000
+      percpu_usage:
+        description: |
+          Total CPU time (in nanoseconds) consumed per core (Linux).
+
+          This field is Linux-specific when using cgroups v1. It is omitted
+          when using cgroups v2 and Windows containers.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "integer"
+          format: "uint64"
+          example: 29912000
+
+      usage_in_kernelmode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in kernel mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 21994000
+      usage_in_usermode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in user mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 7918000
+
+  ContainerPidsStats:
+    description: |
+      PidsStats contains Linux-specific stats of a container's process-IDs (PIDs).
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "PidsStats"
+    x-nullable: true
+    properties:
+      current:
+        description: |
+          Current is the number of PIDs in the cgroup.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      limit:
+        description: |
+          Limit is the hard limit on the number of pids in the cgroup.
+          A "Limit" of 0 means that there is no limit.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: "18446744073709551615"
+
+  ContainerThrottlingData:
+    description: |
+      CPU throttling stats of the container.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "ThrottlingData"
+    x-nullable: true
+    properties:
+      periods:
+        description: |
+          Number of periods with throttling active.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_periods:
+        description: |
+          Number of periods when the container hit its throttling limit.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_time:
+        description: |
+          Aggregated time (in nanoseconds) the container was throttled for.
+        type: "integer"
+        format: "uint64"
+        example: 0
+
+  ContainerMemoryStats:
+    description: |
+      Aggregates all memory stats since container inception on Linux.
+      Windows returns stats for commit and private working set only.
+    type: "object"
+    x-go-name: "MemoryStats"
+    properties:
+      usage:
+        description: |
+          Current `res_counter` usage for memory.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      max_usage:
+        description: |
+          Maximum usage ever recorded.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      stats:
+        description: |
+          All the stats exported via memory.stat.
+
+          The fields in this object differ between cgroups v1 and v2.
+          On cgroups v1, fields such as `cache`, `rss`, `mapped_file` are available.
+          On cgroups v2, fields such as `file`, `anon`, `inactive_file` are available.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "object"
+        additionalProperties:
+          type: "integer"
+          format: "uint64"
+          x-nullable: true
+        example:
+          {
+            "active_anon": 1572864,
+            "active_file": 5115904,
+            "anon": 1572864,
+            "anon_thp": 0,
+            "file": 7626752,
+            "file_dirty": 0,
+            "file_mapped": 2723840,
+            "file_writeback": 0,
+            "inactive_anon": 0,
+            "inactive_file": 2510848,
+            "kernel_stack": 16384,
+            "pgactivate": 0,
+            "pgdeactivate": 0,
+            "pgfault": 2042,
+            "pglazyfree": 0,
+            "pglazyfreed": 0,
+            "pgmajfault": 45,
+            "pgrefill": 0,
+            "pgscan": 0,
+            "pgsteal": 0,
+            "shmem": 0,
+            "slab": 1180928,
+            "slab_reclaimable": 725576,
+            "slab_unreclaimable": 455352,
+            "sock": 0,
+            "thp_collapse_alloc": 0,
+            "thp_fault_alloc": 1,
+            "unevictable": 0,
+            "workingset_activate": 0,
+            "workingset_nodereclaim": 0,
+            "workingset_refault": 0
+          }
+      failcnt:
+        description: |
+          Number of times memory usage hits limits.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      limit:
+        description: |
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 8217579520
+      commitbytes:
+        description: |
+          Committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      commitpeakbytes:
+        description: |
+          Peak committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      privateworkingset:
+        description: |
+          Private working set.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+
+  ContainerNetworkStats:
+    description: |
+      Aggregates the network stats of one container
+    type: "object"
+    x-go-name: "NetworkStats"
+    x-nullable: true
+    properties:
+      rx_bytes:
+        description: |
+          Bytes received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 5338
+      rx_packets:
+        description: |
+          Packets received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 36
+      rx_errors:
+        description: |
+          Received errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      rx_dropped:
+        description: |
+          Incoming packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_bytes:
+        description: |
+          Bytes sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 1200
+      tx_packets:
+        description: |
+          Packets sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 12
+      tx_errors:
+        description: |
+          Sent errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_dropped:
+        description: |
+          Outgoing packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      endpoint_id:
+        description: |
+          Endpoint ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+      instance_id:
+        description: |
+          Instance ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+
+  ContainerStorageStats:
+    description: |
+      StorageStats is the disk I/O stats for read/write on Windows.
+
+      This type is Windows-specific and omitted for Linux containers.
+    type: "object"
+    x-go-name: "StorageStats"
+    x-nullable: true
+    properties:
+      read_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      read_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+
+  ContainerTopResponse:
+    type: "object"
+    x-go-name: "TopResponse"
+    title: "ContainerTopResponse"
+    description: |-
+      Container "top" response.
+    properties:
+      Titles:
+        description: "The ps column titles"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          Titles:
+            - "UID"
+            - "PID"
+            - "PPID"
+            - "C"
+            - "STIME"
+            - "TTY"
+            - "TIME"
+            - "CMD"
+      Processes:
+        description: |-
+          Each process running in the container, where each process
+          is an array of values corresponding to the titles.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          Processes:
+            -
+              - "root"
+              - "13642"
+              - "882"
+              - "0"
+              - "17:03"
+              - "pts/0"
+              - "00:00:00"
+              - "/bin/bash"
+            -
+              - "root"
+              - "13735"
+              - "13642"
+              - "0"
+              - "17:06"
+              - "pts/0"
+              - "00:00:00"
+              - "sleep 10"
+
+  ContainerWaitResponse:
+    description: "OK response to ContainerWait operation"
+    type: "object"
+    x-go-name: "WaitResponse"
+    title: "ContainerWaitResponse"
+    required: [StatusCode]
+    properties:
+      StatusCode:
+        description: "Exit code of the container"
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Error:
+        $ref: "#/definitions/ContainerWaitExitError"
+
+  ContainerWaitExitError:
+    description: "container waiting error, if any"
+    type: "object"
+    x-go-name: "WaitExitError"
+    properties:
+      Message:
+        description: "Details of an error"
+        type: "string"
+
+  SystemVersion:
+    type: "object"
+    description: |
+      Response of Engine API: GET "/version"
+    properties:
+      Platform:
+        type: "object"
+        required: [Name]
+        properties:
+          Name:
+            type: "string"
+      Components:
+        type: "array"
+        description: |
+          Information about system components
+        items:
+          type: "object"
+          x-go-name: ComponentVersion
+          required: [Name, Version]
+          properties:
+            Name:
+              description: |
+                Name of the component
+              type: "string"
+              example: "Engine"
+            Version:
+              description: |
+                Version of the component
+              type: "string"
+              x-nullable: false
+              example: "27.0.1"
+            Details:
+              description: |
+                Key/value pairs of strings with additional information about the
+                component. These values are intended for informational purposes
+                only, and their content is not defined, and not part of the API
+                specification.
+
+                These messages can be printed by the client as information to the user.
+              type: "object"
+              x-nullable: true
+      Version:
+        description: "The version of the daemon"
+        type: "string"
+        example: "27.0.1"
+      ApiVersion:
+        description: |
+          The default (and highest) API version that is supported by the daemon
+        type: "string"
+        example: "1.47"
+      MinAPIVersion:
+        description: |
+          The minimum API version that is supported by the daemon
+        type: "string"
+        example: "1.24"
+      GitCommit:
+        description: |
+          The Git commit of the source code that was used to build the daemon
+        type: "string"
+        example: "48a66213fe"
+      GoVersion:
+        description: |
+          The version Go used to compile the daemon, and the version of the Go
+          runtime in use.
+        type: "string"
+        example: "go1.22.7"
+      Os:
+        description: |
+          The operating system that the daemon is running on ("linux" or "windows")
+        type: "string"
+        example: "linux"
+      Arch:
+        description: |
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "amd64"
+      KernelVersion:
+        description: |
+          The kernel version (`uname -r`) that the daemon is running on.
+
+          This field is omitted when empty.
+        type: "string"
+        example: "6.8.0-31-generic"
+      Experimental:
+        description: |
+          Indicates if the daemon is started with experimental features enabled.
+
+          This field is omitted when empty / false.
+        type: "boolean"
+        example: true
+      BuildTime:
+        description: |
+          The date and time that the daemon was compiled.
+        type: "string"
+        example: "2020-06-22T15:49:27.000000000+00:00"
+
+  SystemInfo:
+    type: "object"
+    properties:
+      ID:
+        description: |
+          Unique identifier of the daemon.
+
+          <p><br /></p>
+
+          > **Note**: The format of the ID itself is not part of the API, and
+          > should not be considered stable.
+        type: "string"
+        example: "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS"
+      Containers:
+        description: "Total number of containers on the host."
+        type: "integer"
+        example: 14
+      ContainersRunning:
+        description: |
+          Number of containers with status `"running"`.
+        type: "integer"
+        example: 3
+      ContainersPaused:
+        description: |
+          Number of containers with status `"paused"`.
+        type: "integer"
+        example: 1
+      ContainersStopped:
+        description: |
+          Number of containers with status `"stopped"`.
+        type: "integer"
+        example: 10
+      Images:
+        description: |
+          Total number of images on the host.
+
+          Both _tagged_ and _untagged_ (dangling) images are counted.
+        type: "integer"
+        example: 508
+      Driver:
+        description: "Name of the storage driver in use."
+        type: "string"
+        example: "overlay2"
+      DriverStatus:
+        description: |
+          Information specific to the storage driver, provided as
+          "label" / "value" pairs.
+
+          This information is provided by the storage driver, and formatted
+          in a way consistent with the output of `docker info` on the command
+          line.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["Backing Filesystem", "extfs"]
+          - ["Supports d_type", "true"]
+          - ["Native Overlay Diff", "true"]
+      DockerRootDir:
+        description: |
+          Root directory of persistent Docker state.
+
+          Defaults to `/var/lib/docker` on Linux, and `C:\ProgramData\docker`
+          on Windows.
+        type: "string"
+        example: "/var/lib/docker"
+      Plugins:
+        $ref: "#/definitions/PluginsInfo"
+      MemoryLimit:
+        description: "Indicates if the host has memory limit support enabled."
+        type: "boolean"
+        example: true
+      SwapLimit:
+        description: "Indicates if the host has memory swap limit support enabled."
+        type: "boolean"
+        example: true
+      CpuCfsPeriod:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) period is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CpuCfsQuota:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) quota is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CPUShares:
+        description: |
+          Indicates if CPU Shares limiting is supported by the host.
+        type: "boolean"
+        example: true
+      CPUSet:
+        description: |
+          Indicates if CPUsets (cpuset.cpus, cpuset.mems) are supported by the host.
+
+          See [cpuset(7)](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt)
+        type: "boolean"
+        example: true
+      PidsLimit:
+        description: "Indicates if the host kernel has PID limit support enabled."
+        type: "boolean"
+        example: true
+      OomKillDisable:
+        description: "Indicates if OOM killer disable is supported on the host."
+        type: "boolean"
+      IPv4Forwarding:
+        description: "Indicates IPv4 forwarding is enabled."
+        type: "boolean"
+        example: true
+      Debug:
+        description: |
+          Indicates if the daemon is running in debug-mode / with debug-level
+          logging enabled.
+        type: "boolean"
+        example: true
+      NFd:
+        description: |
+          The total number of file Descriptors in use by the daemon process.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 64
+      NGoroutines:
+        description: |
+          The  number of goroutines that currently exist.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 174
+      SystemTime:
+        description: |
+          Current system-time in [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          format with nano-seconds.
+        type: "string"
+        example: "2017-08-08T20:28:29.06202363Z"
+      LoggingDriver:
+        description: |
+          The logging driver to use as a default for new containers.
+        type: "string"
+      CgroupDriver:
+        description: |
+          The driver to use for managing cgroups.
+        type: "string"
+        enum: ["cgroupfs", "systemd", "none"]
+        default: "cgroupfs"
+        example: "cgroupfs"
+      CgroupVersion:
+        description: |
+          The version of the cgroup.
+        type: "string"
+        enum: ["1", "2"]
+        default: "1"
+        example: "1"
+      NEventsListener:
+        description: "Number of event listeners subscribed."
+        type: "integer"
+        example: 30
+      KernelVersion:
+        description: |
+          Kernel version of the host.
+
+          On Linux, this information obtained from `uname`. On Windows this
+          information is queried from the <kbd>HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\</kbd>
+          registry value, for example _"10.0 14393 (14393.1198.amd64fre.rs1_release_sec.170427-1353)"_.
+        type: "string"
+        example: "6.8.0-31-generic"
+      OperatingSystem:
+        description: |
+          Name of the host's operating system, for example: "Ubuntu 24.04 LTS"
+          or "Windows Server 2016 Datacenter"
+        type: "string"
+        example: "Ubuntu 24.04 LTS"
+      OSVersion:
+        description: |
+          Version of the host's operating system
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including its
+          > very existence, and the formatting of values, should not be considered
+          > stable, and may change without notice.
+        type: "string"
+        example: "24.04"
+      OSType:
+        description: |
+          Generic type of the operating system of the host, as returned by the
+          Go runtime (`GOOS`).
+
+          Currently returned values are "linux" and "windows". A full list of
+          possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "linux"
+      Architecture:
+        description: |
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
+
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
+        type: "string"
+        example: "x86_64"
+      NCPU:
+        description: |
+          The number of logical CPUs usable by the daemon.
+
+          The number of available CPUs is checked by querying the operating
+          system when the daemon starts. Changes to operating system CPU
+          allocation after the daemon is started are not reflected.
+        type: "integer"
+        example: 4
+      MemTotal:
+        description: |
+          Total amount of physical memory available on the host, in bytes.
+        type: "integer"
+        format: "int64"
+        example: 2095882240
+
+      IndexServerAddress:
+        description: |
+          Address / URL of the index server that is used for image search,
+          and as a default for user authentication for Docker Hub and Docker Cloud.
+        default: "https://index.docker.io/v1/"
+        type: "string"
+        example: "https://index.docker.io/v1/"
+      RegistryConfig:
+        $ref: "#/definitions/RegistryServiceConfig"
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+      HttpProxy:
+        description: |
+          HTTP-proxy configured for the daemon. This value is obtained from the
+          [`HTTP_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "http://xxxxx:xxxxx@proxy.corp.example.com:8080"
+      HttpsProxy:
+        description: |
+          HTTPS-proxy configured for the daemon. This value is obtained from the
+          [`HTTPS_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "https://xxxxx:xxxxx@proxy.corp.example.com:4443"
+      NoProxy:
+        description: |
+          Comma-separated list of domain extensions for which no proxy should be
+          used. This value is obtained from the [`NO_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html)
+          environment variable.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "*.local, 169.254/16"
+      Name:
+        description: "Hostname of the host."
+        type: "string"
+        example: "node5.corp.example.com"
+      Labels:
+        description: |
+          User-defined labels (key/value metadata) as set on the daemon.
+
+          <p><br /></p>
+
+          > **Note**: When part of a Swarm, nodes can both have _daemon_ labels,
+          > set through the daemon configuration, and _node_ labels, set from a
+          > manager node in the Swarm. Node labels are not included in this
+          > field. Node labels can be retrieved using the `/nodes/(id)` endpoint
+          > on a manager node in the Swarm.
+        type: "array"
+        items:
+          type: "string"
+        example: ["storage=ssd", "production"]
+      ExperimentalBuild:
+        description: |
+          Indicates if experimental features are enabled on the daemon.
+        type: "boolean"
+        example: true
+      ServerVersion:
+        description: |
+          Version string of the daemon.
+        type: "string"
+        example: "27.0.1"
+      Runtimes:
+        description: |
+          List of [OCI compliant](https://github.com/opencontainers/runtime-spec)
+          runtimes configured on the daemon. Keys hold the "name" used to
+          reference the runtime.
+
+          The Docker daemon relies on an OCI compliant runtime (invoked via the
+          `containerd` daemon) as its interface to the Linux kernel namespaces,
+          cgroups, and SELinux.
+
+          The default runtime is `runc`, and automatically configured. Additional
+          runtimes can be configured by the user and will be listed here.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/Runtime"
+        default:
+          runc:
+            path: "runc"
+        example:
+          runc:
+            path: "runc"
+          runc-master:
+            path: "/go/bin/runc"
+          custom:
+            path: "/usr/local/bin/my-oci-runtime"
+            runtimeArgs: ["--debug", "--systemd-cgroup=false"]
+      DefaultRuntime:
+        description: |
+          Name of the default OCI runtime that is used when starting containers.
+
+          The default can be overridden per-container at create time.
+        type: "string"
+        default: "runc"
+        example: "runc"
+      Swarm:
+        $ref: "#/definitions/SwarmInfo"
+      LiveRestoreEnabled:
+        description: |
+          Indicates if live restore is enabled.
+
+          If enabled, containers are kept running when the daemon is shutdown
+          or upon daemon start if running containers are detected.
+        type: "boolean"
+        default: false
+        example: false
+      Isolation:
+        description: |
+          Represents the isolation technology to use as a default for containers.
+          The supported values are platform-specific.
+
+          If no isolation value is specified on daemon start, on Windows client,
+          the default is `hyperv`, and on Windows server, the default is `process`.
+
+          This option is currently not used on other platforms.
+        default: "default"
+        type: "string"
+        enum:
+          - "default"
+          - "hyperv"
+          - "process"
+          - ""
+      InitBinary:
+        description: |
+          Name and, optional, path of the `docker-init` binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "docker-init"
+      ContainerdCommit:
+        $ref: "#/definitions/Commit"
+      RuncCommit:
+        $ref: "#/definitions/Commit"
+      InitCommit:
+        $ref: "#/definitions/Commit"
+      SecurityOptions:
+        description: |
+          List of security features that are enabled on the daemon, such as
+          apparmor, seccomp, SELinux, user-namespaces (userns), rootless and
+          no-new-privileges.
+
+          Additional configuration options for each security feature may
+          be present, and are included as a comma-separated list of key/value
+          pairs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "name=apparmor"
+          - "name=seccomp,profile=default"
+          - "name=selinux"
+          - "name=userns"
+          - "name=rootless"
+      ProductLicense:
+        description: |
+          Reports a summary of the product license on the daemon.
+
+          If a commercial license has been applied to the daemon, information
+          such as number of nodes, and expiration are included.
+        type: "string"
+        example: "Community Engine"
+      DefaultAddressPools:
+        description: |
+          List of custom default address pools for local networks, which can be
+          specified in the daemon.json file or dockerd option.
+
+          Example: a Base "10.10.0.0/16" with Size 24 will define the set of 256
+          10.10.[0-255].0/24 address pools.
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Base:
+              description: "The network address in CIDR format"
+              type: "string"
+              example: "10.10.0.0/16"
+            Size:
+              description: "The network pool size"
+              type: "integer"
+              example: "24"
+      FirewallBackend:
+        $ref: "#/definitions/FirewallInfo"
+      DiscoveredDevices:
+        description: |
+          List of devices discovered by device drivers.
+
+          Each device includes information about its source driver, kind, name,
+          and additional driver-specific attributes.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceInfo"
+      NRI:
+        $ref: "#/definitions/NRIInfo"
+      Warnings:
+        description: |
+          List of warnings / informational messages about missing features, or
+          issues related to the daemon configuration.
+
+          These messages can be printed by the client as information to the user.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "WARNING: No memory limit support"
+      CDISpecDirs:
+        description: |
+          List of directories where (Container Device Interface) CDI
+          specifications are located.
+
+          These specifications define vendor-specific modifications to an OCI
+          runtime specification for a container being created.
+
+          An empty list indicates that CDI device injection is disabled.
+
+          Note that since using CDI device injection requires the daemon to have
+          experimental enabled. For non-experimental daemons an empty list will
+          always be returned.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/etc/cdi"
+          - "/var/run/cdi"
+      Containerd:
+        $ref: "#/definitions/ContainerdInfo"
+
+  ContainerdInfo:
+    description: |
+      Information for connecting to the containerd instance that is used by the daemon.
+      This is included for debugging purposes only.
+    type: "object"
+    x-nullable: true
+    properties:
+      Address:
+        description: "The address of the containerd socket."
+        type: "string"
+        example: "/run/containerd/containerd.sock"
+      Namespaces:
+        description: |
+          The namespaces that the daemon uses for running containers and
+          plugins in containerd. These namespaces can be configured in the
+          daemon configuration, and are considered to be used exclusively
+          by the daemon, Tampering with the containerd instance may cause
+          unexpected behavior.
+
+          As these namespaces are considered to be exclusively accessed
+          by the daemon, it is not recommended to change these values,
+          or to change them to a value that is used by other systems,
+          such as cri-containerd.
+        type: "object"
+        properties:
+          Containers:
+            description: |
+              The default containerd namespace used for containers managed
+              by the daemon.
+
+              The default namespace for containers is "moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "moby"
+            example: "moby"
+          Plugins:
+            description: |
+              The default containerd namespace used for plugins managed by
+              the daemon.
+
+              The default namespace for plugins is "plugins.moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "plugins.moby"
+            example: "plugins.moby"
+
+  FirewallInfo:
+    description: |
+      Information about the daemon's firewalling configuration.
+
+      This field is currently only used on Linux, and omitted on other platforms.
+    type: "object"
+    x-nullable: true
+    properties:
+      Driver:
+        description: |
+          The name of the firewall backend driver.
+        type: "string"
+        example: "nftables"
+      Info:
+        description: |
+          Information about the firewall backend, provided as
+          "label" / "value" pairs.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["ReloadedAt", "2025-01-01T00:00:00Z"]
+
+  # PluginsInfo is a temp struct holding Plugins name
+  # registered with docker daemon. It is used by Info struct
+  PluginsInfo:
+    description: |
+      Available plugins per type.
+
+      <p><br /></p>
+
+      > **Note**: Only unmanaged (V1) plugins are included in this list.
+      > V1 plugins are "lazily" loaded, and are not returned in this list
+      > if there is no resource using the plugin.
+    type: "object"
+    properties:
+      Volume:
+        description: "Names of available volume-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["local"]
+      Network:
+        description: "Names of available network-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["bridge", "host", "ipvlan", "macvlan", "null", "overlay"]
+      Authorization:
+        description: "Names of available authorization plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["img-authz-plugin", "hbm"]
+      Log:
+        description: "Names of available logging-drivers, and logging-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["awslogs", "fluentd", "gcplogs", "gelf", "journald", "json-file", "splunk", "syslog"]
+
+
+  RegistryServiceConfig:
+    description: |
+      RegistryServiceConfig stores daemon registry services configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      InsecureRegistryCIDRs:
+        description: |
+          List of IP ranges of insecure registries, using the CIDR syntax
+          ([RFC 4632](https://tools.ietf.org/html/4632)). Insecure registries
+          accept un-encrypted (HTTP) and/or untrusted (HTTPS with certificates
+          from unknown CAs) communication.
+
+          By default, local registries (`::1/128` and `127.0.0.0/8`) are configured as
+          insecure. All other registries are secure. Communicating with an
+          insecure registry is not possible if the daemon assumes that registry
+          is secure.
+
+          This configuration override this behavior, insecure communication with
+          registries whose resolved IP address is within the subnet described by
+          the CIDR syntax.
+
+          Registries can also be marked insecure by hostname. Those registries
+          are listed under `IndexConfigs` and have their `Secure` field set to
+          `false`.
+
+          > **Warning**: Using this option can be useful when running a local
+          > registry, but introduces security vulnerabilities. This option
+          > should therefore ONLY be used for testing purposes. For increased
+          > security, users should add their CA to their system's list of trusted
+          > CAs instead of enabling this option.
+        type: "array"
+        items:
+          type: "string"
+        example: ["::1/128", "127.0.0.0/8"]
+      IndexConfigs:
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/IndexInfo"
+        example:
+          "127.0.0.1:5000":
+            "Name": "127.0.0.1:5000"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "[2001:db8:a0b:12f0::1]:80":
+            "Name": "[2001:db8:a0b:12f0::1]:80"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "docker.io":
+            Name: "docker.io"
+            Mirrors: ["https://hub-mirror.corp.example.com:5000/"]
+            Secure: true
+            Official: true
+          "registry.internal.corp.example.com:3000":
+            Name: "registry.internal.corp.example.com:3000"
+            Mirrors: []
+            Secure: false
+            Official: false
+      Mirrors:
+        description: |
+          List of registry URLs that act as a mirror for the official
+          (`docker.io`) registry.
+
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://[2001:db8:a0b:12f0::1]/"
+
+  IndexInfo:
+    description:
+      IndexInfo contains information about a registry.
+    type: "object"
+    x-nullable: true
+    properties:
+      Name:
+        description: |
+          Name of the registry, such as "docker.io".
+        type: "string"
+        example: "docker.io"
+      Mirrors:
+        description: |
+          List of mirrors, expressed as URIs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://registry-2.docker.io/"
+          - "https://registry-3.docker.io/"
+      Secure:
+        description: |
+          Indicates if the registry is part of the list of insecure
+          registries.
+
+          If `false`, the registry is insecure. Insecure registries accept
+          un-encrypted (HTTP) and/or untrusted (HTTPS with certificates from
+          unknown CAs) communication.
+
+          > **Warning**: Insecure registries can be useful when running a local
+          > registry. However, because its use creates security vulnerabilities
+          > it should ONLY be enabled for testing purposes. For increased
+          > security, users should add their CA to their system's list of
+          > trusted CAs instead of enabling this option.
+        type: "boolean"
+        example: true
+      Official:
+        description: |
+          Indicates whether this is an official registry (i.e., Docker Hub / docker.io)
+        type: "boolean"
+        example: true
+
+  Runtime:
+    description: |
+      Runtime describes an [OCI compliant](https://github.com/opencontainers/runtime-spec)
+      runtime.
+
+      The runtime is invoked by the daemon via the `containerd` daemon. OCI
+      runtimes act as an interface to the Linux kernel namespaces, cgroups,
+      and SELinux.
+    type: "object"
+    properties:
+      path:
+        description: |
+          Name and, optional, path, of the OCI executable binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "/usr/local/bin/my-oci-runtime"
+      runtimeArgs:
+        description: |
+          List of command-line arguments to pass to the runtime when invoked.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["--debug", "--systemd-cgroup=false"]
+      status:
+        description: |
+          Information specific to the runtime.
+
+          While this API specification does not define data provided by runtimes,
+          the following well-known properties may be provided by runtimes:
+
+          `org.opencontainers.runtime-spec.features`: features structure as defined
+          in the [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec/blob/main/features.md),
+          in a JSON string representation.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "org.opencontainers.runtime-spec.features": "{\"ociVersionMin\":\"1.0.0\",\"ociVersionMax\":\"1.1.0\",\"...\":\"...\"}"
+
+  Commit:
+    description: |
+      Commit holds the Git-commit (SHA1) that a binary was built from, as
+      reported in the version-string of external tools, such as `containerd`,
+      or `runC`.
+    type: "object"
+    properties:
+      ID:
+        description: "Actual commit ID of external tool."
+        type: "string"
+        example: "cfb82a876ecc11b5ca0977d1733adbe58599088a"
+
+  SwarmInfo:
+    description: |
+      Represents generic information about swarm.
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+        default: ""
+        example: "k67qz4598weg5unwwffg6z1m1"
+      NodeAddr:
+        description: |
+          IP address at which this node can be reached by other nodes in the
+          swarm.
+        type: "string"
+        default: ""
+        example: "10.0.0.46"
+      LocalNodeState:
+        $ref: "#/definitions/LocalNodeState"
+      ControlAvailable:
+        type: "boolean"
+        default: false
+        example: true
+      Error:
+        type: "string"
+        default: ""
+      RemoteManagers:
+        description: |
+          List of ID's and addresses of other managers in the swarm.
+        type: "array"
+        default: null
+        x-nullable: true
+        items:
+          $ref: "#/definitions/PeerNode"
+        example:
+          - NodeID: "71izy0goik036k48jg985xnds"
+            Addr: "10.0.0.158:2377"
+          - NodeID: "79y6h1o4gv8n120drcprv5nmc"
+            Addr: "10.0.0.159:2377"
+          - NodeID: "k67qz4598weg5unwwffg6z1m1"
+            Addr: "10.0.0.46:2377"
+      Nodes:
+        description: "Total number of nodes in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 4
+      Managers:
+        description: "Total number of managers in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 3
+      Cluster:
+        $ref: "#/definitions/ClusterInfo"
+
+  LocalNodeState:
+    description: "Current local status of this node."
+    type: "string"
+    default: ""
+    enum:
+      - ""
+      - "inactive"
+      - "pending"
+      - "active"
+      - "error"
+      - "locked"
+    example: "active"
+
+  PeerNode:
+    description: "Represents a peer-node in the swarm"
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+      Addr:
+        description: |
+          IP address and ports at which this node can be reached.
+        type: "string"
+
+  NetworkAttachmentConfig:
+    description: |
+      Specifies how a service should be attached to a particular network.
+    type: "object"
+    properties:
+      Target:
+        description: |
+          The target network for attachment. Must be a network name or ID.
+        type: "string"
+      Aliases:
+        description: |
+          Discoverable alternate names for the service on this network.
+        type: "array"
+        items:
+          type: "string"
+      DriverOpts:
+        description: |
+          Driver attachment options for the network target.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  EventActor:
+    description: |
+      Actor describes something that generates events, like a container, network,
+      or a volume.
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the object emitting the event"
+        type: "string"
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Attributes:
+        description: |
+          Various key/value attributes of the object, depending on its type.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-label-value"
+          image: "alpine:latest"
+          name: "my-container"
+
+  EventMessage:
+    description: |
+      EventMessage represents the information an event contains.
+    type: "object"
+    title: "SystemEventsResponse"
+    properties:
+      Type:
+        description: "The type of object emitting the event"
+        type: "string"
+        enum: ["builder", "config", "container", "daemon", "image", "network", "node", "plugin", "secret", "service", "volume"]
+        example: "container"
+      Action:
+        description: "The type of event"
+        type: "string"
+        example: "create"
+      Actor:
+        $ref: "#/definitions/EventActor"
+      scope:
+        description: |
+          Scope of the event. Engine events are `local` scope. Cluster (Swarm)
+          events are `swarm` scope.
+        type: "string"
+        enum: ["local", "swarm"]
+      time:
+        description: "Timestamp of event"
+        type: "integer"
+        format: "int64"
+        example: 1629574695
+      timeNano:
+        description: "Timestamp of event, with nanosecond accuracy"
+        type: "integer"
+        format: "int64"
+        example: 1629574695515050031
+
+  OCIDescriptor:
+    type: "object"
+    x-go-name: Descriptor
+    description: |
+      A descriptor struct containing digest, media type, and size, as defined in
+      the [OCI Content Descriptors Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/descriptor.md).
+    properties:
+      mediaType:
+        description: |
+          The media type of the object this schema refers to.
+        type: "string"
+        example: "application/vnd.oci.image.manifest.v1+json"
+      digest:
+        description: |
+          The digest of the targeted content.
+        type: "string"
+        example: "sha256:c0537ff6a5218ef531ece93d4984efc99bbf3f7497c0a7726c88e2bb7584dc96"
+      size:
+        description: |
+          The size in bytes of the blob.
+        type: "integer"
+        format: "int64"
+        example: 424
+      urls:
+        description: |-
+          List of URLs from which this object MAY be downloaded.
+        type: "array"
+        items:
+          type: "string"
+          format: "uri"
+        x-nullable: true
+      annotations:
+        description: |-
+          Arbitrary metadata relating to the targeted content.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "com.docker.official-images.bashbrew.arch": "amd64"
+          "org.opencontainers.image.base.digest": "sha256:0d0ef5c914d3ea700147da1bd050c59edb8bb12ca312f3800b29d7c8087eabd8"
+          "org.opencontainers.image.base.name": "scratch"
+          "org.opencontainers.image.created": "2025-01-27T00:00:00Z"
+          "org.opencontainers.image.revision": "9fabb4bad5138435b01857e2fe9363e2dc5f6a79"
+          "org.opencontainers.image.source": "https://git.launchpad.net/cloud-images/+oci/ubuntu-base"
+          "org.opencontainers.image.url": "https://hub.docker.com/_/ubuntu"
+          "org.opencontainers.image.version": "24.04"
+      data:
+        type: string
+        x-nullable: true
+        description: |-
+          Data is an embedding of the targeted content. This is encoded as a base64
+          string when marshalled to JSON (automatically, by encoding/json). If
+          present, Data can be used directly to avoid fetching the targeted content.
+        example: null
+      platform:
+        $ref: "#/definitions/OCIPlatform"
+      artifactType:
+        description: |-
+          ArtifactType is the IANA media type of this artifact.
+        type: "string"
+        x-nullable: true
+        example: null
+
+  OCIPlatform:
+    type: "object"
+    x-go-name: Platform
+    x-nullable: true
+    description: |
+      Describes the platform which the image in the manifest runs on, as defined
+      in the [OCI Image Index Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/image-index.md).
+    properties:
+      architecture:
+        description: |
+          The CPU architecture, for example `amd64` or `ppc64`.
+        type: "string"
+        example: "arm"
+      os:
+        description: |
+          The operating system, for example `linux` or `windows`.
+        type: "string"
+        example: "windows"
+      os.version:
+        description: |
+          Optional field specifying the operating system version, for example on
+          Windows `10.0.19041.1165`.
+        type: "string"
+        example: "10.0.19041.1165"
+      os.features:
+        description: |
+          Optional field specifying an array of strings, each listing a required
+          OS feature (for example on Windows `win32k`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "win32k"
+      variant:
+        description: |
+          Optional field specifying a variant of the CPU, for example `v7` to
+          specify ARMv7 when architecture is `arm`.
+        type: "string"
+        example: "v7"
+
+  DistributionInspect:
+    type: "object"
+    x-go-name: DistributionInspect
+    title: "DistributionInspectResponse"
+    required: [Descriptor, Platforms]
+    description: |
+      Describes the result obtained from contacting the registry to retrieve
+      image metadata.
+    properties:
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Platforms:
+        type: "array"
+        description: |
+          An array containing all platforms supported by the image.
+        items:
+          $ref: "#/definitions/OCIPlatform"
+
+  ClusterVolume:
+    type: "object"
+    description: |
+      Options and information specific to, and only present on, Swarm CSI
+      cluster volumes.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          The Swarm ID of this volume. Because cluster volumes are Swarm
+          objects, they have an ID, unlike non-cluster volumes. This ID can
+          be used to refer to the Volume instead of the name.
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+      Info:
+        type: "object"
+        description: |
+          Information about the global status of the volume.
+        properties:
+          CapacityBytes:
+            type: "integer"
+            format: "int64"
+            description: |
+              The capacity of the volume in bytes. A value of 0 indicates that
+              the capacity is unknown.
+          VolumeContext:
+            type: "object"
+            description: |
+              A map of strings to strings returned from the storage plugin when
+              the volume is created.
+            additionalProperties:
+              type: "string"
+          VolumeID:
+            type: "string"
+            description: |
+              The ID of the volume as returned by the CSI storage plugin. This
+              is distinct from the volume's ID as provided by Docker. This ID
+              is never used by the user when communicating with Docker to refer
+              to this volume. If the ID is blank, then the Volume has not been
+              successfully created in the plugin yet.
+          AccessibleTopology:
+            type: "array"
+            description: |
+              The topology this volume is actually accessible from.
+            items:
+              $ref: "#/definitions/Topology"
+      PublishStatus:
+        type: "array"
+        description: |
+          The status of the volume as it pertains to its publishing and use on
+          specific nodes
+        items:
+          type: "object"
+          properties:
+            NodeID:
+              type: "string"
+              description: |
+                The ID of the Swarm node the volume is published on.
+            State:
+              type: "string"
+              description: |
+                The published state of the volume.
+                * `pending-publish` The volume should be published to this node, but the call to the controller plugin to do so has not yet been successfully completed.
+                * `published` The volume is published successfully to the node.
+                * `pending-node-unpublish` The volume should be unpublished from the node, and the manager is awaiting confirmation from the worker that it has done so.
+                * `pending-controller-unpublish` The volume is successfully unpublished from the node, but has not yet been successfully unpublished on the controller.
+              enum:
+                - "pending-publish"
+                - "published"
+                - "pending-node-unpublish"
+                - "pending-controller-unpublish"
+            PublishContext:
+              type: "object"
+              description: |
+                A map of strings to strings returned by the CSI controller
+                plugin when a volume is published.
+              additionalProperties:
+                type: "string"
+
+  ClusterVolumeSpec:
+    type: "object"
+    description: |
+      Cluster-specific options used to create the volume.
+    properties:
+      Group:
+        type: "string"
+        description: |
+          Group defines the volume group of this volume. Volumes belonging to
+          the same group can be referred to by group name when creating
+          Services.  Referring to a volume by group instructs Swarm to treat
+          volumes in that group interchangeably for the purpose of scheduling.
+          Volumes with an empty string for a group technically all belong to
+          the same, emptystring group.
+      AccessMode:
+        type: "object"
+        description: |
+          Defines how the volume is used by tasks.
+        properties:
+          Scope:
+            type: "string"
+            description: |
+              The set of nodes this volume can be used on at one time.
+              - `single` The volume may only be scheduled to one node at a time.
+              - `multi` the volume may be scheduled to any supported number of nodes at a time.
+            default: "single"
+            enum: ["single", "multi"]
+            x-nullable: false
+          Sharing:
+            type: "string"
+            description: |
+              The number and way that different tasks can use this volume
+              at one time.
+              - `none` The volume may only be used by one task at a time.
+              - `readonly` The volume may be used by any number of tasks, but they all must mount the volume as readonly
+              - `onewriter` The volume may be used by any number of tasks, but only one may mount it as read/write.
+              - `all` The volume may have any number of readers and writers.
+            default: "none"
+            enum: ["none", "readonly", "onewriter", "all"]
+            x-nullable: false
+          MountVolume:
+            type: "object"
+            description: |
+              Options for using this volume as a Mount-type volume.
+
+                  Either MountVolume or BlockVolume, but not both, must be
+                  present.
+                properties:
+                  FsType:
+                    type: "string"
+                    description: |
+                      Specifies the filesystem type for the mount volume.
+                      Optional.
+                  MountFlags:
+                    type: "array"
+                    description: |
+                      Flags to pass when mounting the volume. Optional.
+                    items:
+                      type: "string"
+              BlockVolume:
+                type: "object"
+                description: |
+                  Options for using this volume as a Block-type volume.
+                  Intentionally empty.
+          Secrets:
+            type: "array"
+            description: |
+              Swarm Secrets that are passed to the CSI storage plugin when
+              operating on this volume.
+            items:
+              type: "object"
+              description: |
+                One cluster volume secret entry. Defines a key-value pair that
+                is passed to the plugin.
+              properties:
+                Key:
+                  type: "string"
+                  description: |
+                    Key is the name of the key of the key-value pair passed to
+                    the plugin.
+                Secret:
+                  type: "string"
+                  description: |
+                    Secret is the swarm Secret object from which to read data.
+                    This can be a Secret name or ID. The Secret data is
+                    retrieved by swarm and used as the value of the key-value
+                    pair passed to the plugin.
+          AccessibilityRequirements:
+            type: "object"
+            description: |
+              Requirements for the accessible topology of the volume. These
+              fields are optional. For an in-depth description of what these
+              fields mean, see the CSI specification.
+            properties:
+              Requisite:
+                type: "array"
+                description: |
+                  A list of required topologies, at least one of which the
+                  volume must be accessible from.
+                items:
+                  $ref: "#/definitions/Topology"
+              Preferred:
+                type: "array"
+                description: |
+                  A list of topologies that the volume should attempt to be
+                  provisioned in.
+                items:
+                  $ref: "#/definitions/Topology"
+          CapacityRange:
+            type: "object"
+            description: |
+              The desired capacity that the volume should be created with. If
+              empty, the plugin will decide the capacity.
+            properties:
+              RequiredBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must be at least this big. The value of 0
+                  indicates an unspecified minimum
+              LimitBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must not be bigger than this. The value of 0
+                  indicates an unspecified maximum.
+          Availability:
+            type: "string"
+            description: |
+              The availability of the volume for use in tasks.
+              - `active` The volume is fully available for scheduling on the cluster
+              - `pause` No new workloads should use the volume, but existing workloads are not stopped.
+              - `drain` All workloads using this volume should be stopped and rescheduled, and no new ones should be started.
+            default: "active"
+            x-nullable: false
+            enum:
+              - "active"
+              - "pause"
+              - "drain"
+
+  Topology:
+    description: |
+      A map of topological domains to topological segments. For in depth
+      details, see documentation for the Topology object in the CSI
+      specification.
+    type: "object"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  ImageManifestSummary:
+    x-go-name: "ManifestSummary"
+    description: |
+      ImageManifestSummary represents a summary of an image manifest.
+    type: "object"
+    required: ["ID", "Descriptor", "Available", "Size", "Kind"]
+    properties:
+      ID:
+        description: |
+          ID is the content-addressable ID of an image and is the same as the
+          digest of the image manifest.
+        type: "string"
+        example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Available:
+        description: Indicates whether all the child content (image config, layers) is fully available locally.
+        type: "boolean"
+        example: true
+      Size:
+        type: "object"
+        x-nullable: false
+        required: ["Content", "Total"]
+        properties:
+          Total:
+            type: "integer"
+            format: "int64"
+            example: 8213251
+            description: |
+              Total is the total size (in bytes) of all the locally present
+              data (both distributable and non-distributable) that's related to
+              this manifest and its children.
+              This equal to the sum of [Content] size AND all the sizes in the
+              [Size] struct present in the Kind-specific data struct.
+              For example, for an image kind (Kind == "image")
+              this would include the size of the image content and unpacked
+              image snapshots ([Size.Content] + [ImageData.Size.Unpacked]).
+          Content:
+            description: |
+              Content is the size (in bytes) of all the locally present
+              content in the content store (e.g. image config, layers)
+              referenced by this manifest and its children.
+              This only includes blobs in the content store.
+            type: "integer"
+            format: "int64"
+            example: 3987495
+      Kind:
+        type: "string"
+        example: "image"
+        enum:
+          - "image"
+          - "attestation"
+          - "unknown"
+        description: |
+          The kind of the manifest.
+
+          kind         | description
+          -------------|-----------------------------------------------------------
+          image        | Image manifest that can be used to start a container.
+          attestation  | Attestation manifest produced by the Buildkit builder for a specific image manifest.
+      ImageData:
+        description: |
+          The image data for the image manifest.
+          This field is only populated when Kind is "image".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["Platform", "Containers", "Size", "UnpackedSize"]
+        properties:
+          Platform:
+            $ref: "#/definitions/OCIPlatform"
+            description: |
+              OCI platform of the image. This will be the platform specified in the
+              manifest descriptor from the index/manifest list.
+              If it's not available, it will be obtained from the image config.
+          Identity:
+            description: |
+              Identity holds information about the identity and origin of this image.
+              For image list responses, this can duplicate Build/Pull fields across
+              image manifests, because those parts are image-level metadata.
+            x-nullable: true
+            $ref: "#/definitions/Identity"
+          Containers:
+            description: |
+              The IDs of the containers that are using this image.
+            type: "array"
+            items:
+              type: "string"
+            example: ["ede54ee1fda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c7430", "abadbce344c096744d8d6071a90d474d28af8f1034b5ea9fb03c3f4bfc6d005e"]
+          Size:
+            type: "object"
+            x-nullable: false
+            required: ["Unpacked"]
+            properties:
+              Unpacked:
+                type: "integer"
+                format: "int64"
+                example: 3987495
+                description: |
+                  Unpacked is the size (in bytes) of the locally unpacked
+                  (uncompressed) image content that's directly usable by the containers
+                  running this image.
+                  It's independent of the distributable content - e.g.
+                  the image might still have an unpacked data that's still used by
+                  some container even when the distributable/compressed content is
+                  already gone.
+      AttestationData:
+        description: |
+          The image data for the attestation manifest.
+          This field is only populated when Kind is "attestation".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["For"]
+        properties:
+          For:
+            description: |
+              The digest of the image manifest that this attestation is for.
+            type: "string"
+            example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+
+paths:
+  /containers/json:
+    get:
+      summary: "List containers"
+      description: |
+        Returns a list of containers. For details on the format, see the
+        [inspect endpoint](#operation/ContainerInspect).
+
+        Note that it uses a different, smaller representation of a container
+        than inspecting a single container. For example, the list of linked
+        containers is not propagated .
+      operationId: "ContainerList"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: |
+            Return all containers. By default, only running containers are shown.
+          type: "boolean"
+          default: false
+        - name: "limit"
+          in: "query"
+          description: |
+            Return this number of most recently created containers, including
+            non-running ones.
+          type: "integer"
+        - name: "size"
+          in: "query"
+          description: |
+            Return the size of container as fields `SizeRw` and `SizeRootFs`.
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the container list, encoded as JSON (a
+            `map[string][]string`). For example, `{"status": ["paused"]}` will
+            only return paused containers.
+
+            Available filters:
+
+            - `ancestor`=(`<image-name>[:<tag>]`, `<image id>`, or `<image@digest>`)
+            - `before`=(`<container id>` or `<container name>`)
+            - `expose`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `exited=<int>` containers with exit code of `<int>`
+            - `health`=(`starting`|`healthy`|`unhealthy`|`none`)
+            - `id=<ID>` a container's ID
+            - `isolation=`(`default`|`process`|`hyperv`) (Windows daemon only)
+            - `is-task=`(`true`|`false`)
+            - `label=key` or `label="key=value"` of a container label
+            - `name=<name>` a container's name
+            - `network`=(`<network id>` or `<network name>`)
+            - `publish`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `since`=(`<container id>` or `<container name>`)
+            - `status=`(`created`|`restarting`|`running`|`removing`|`paused`|`exited`|`dead`)
+            - `volume`=(`<volume name>` or `<mount point destination>`)
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ContainerSummary"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/create:
+    post:
+      summary: "Create a container"
+      operationId: "ContainerCreate"
+      consumes:
+        - "application/json"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            Assign the specified name to the container. Must match
+            `/?[a-zA-Z0-9][a-zA-Z0-9_.-]+`.
+          type: "string"
+          pattern: "^/?[a-zA-Z0-9][a-zA-Z0-9_.-]+$"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format `os[/arch[/variant]]` used for image lookup.
+
+            When specified, the daemon checks if the requested image is present
+            in the local image cache with the given OS and Architecture, and
+            otherwise returns a `404` status.
+
+            If the option is not set, the host's native OS and Architecture are
+            used to look up the image in the image cache. However, if no platform
+            is passed and the given image does exist in the local image cache,
+            but its OS or architecture does not match, the container is created
+            with the available image, and a warning is added to the `Warnings`
+            field in the response, for example;
+
+                WARNING: The requested image's platform (linux/arm64/v8) does not
+                         match the detected host platform (linux/amd64) and no
+                         specific platform was requested
+
+          type: "string"
+          default: ""
+        - name: "body"
+          in: "body"
+          description: "Container to create"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ContainerConfig"
+              - type: "object"
+                properties:
+                  HostConfig:
+                    $ref: "#/definitions/HostConfig"
+                  NetworkingConfig:
+                    $ref: "#/definitions/NetworkingConfig"
+            example:
+              Hostname: ""
+              Domainname: ""
+              User: ""
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              Tty: false
+              OpenStdin: false
+              StdinOnce: false
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+              Cmd:
+                - "date"
+              Entrypoint: ""
+              Image: "ubuntu"
+              Labels:
+                com.example.vendor: "Acme"
+                com.example.license: "GPL"
+                com.example.version: "1.0"
+              Volumes:
+                /volumes/data: {}
+              WorkingDir: ""
+              NetworkDisabled: false
+              ExposedPorts:
+                22/tcp: {}
+              StopSignal: "SIGTERM"
+              StopTimeout: 10
+              HostConfig:
+                Binds:
+                  - "/tmp:/tmp"
+                Links:
+                  - "redis3:redis"
+                Memory: 0
+                MemorySwap: 0
+                MemoryReservation: 0
+                NanoCpus: 500000
+                CpuPercent: 80
+                CpuShares: 512
+                CpuPeriod: 100000
+                CpuRealtimePeriod: 1000000
+                CpuRealtimeRuntime: 10000
+                CpuQuota: 50000
+                CpusetCpus: "0,1"
+                CpusetMems: "0,1"
+                MaximumIOps: 0
+                MaximumIOBps: 0
+                BlkioWeight: 300
+                BlkioWeightDevice:
+                  - {}
+                BlkioDeviceReadBps:
+                  - {}
+                BlkioDeviceReadIOps:
+                  - {}
+                BlkioDeviceWriteBps:
+                  - {}
+                BlkioDeviceWriteIOps:
+                  - {}
+                DeviceRequests:
+                  - Driver: "nvidia"
+                    Count: -1
+                    DeviceIDs": ["0", "1", "GPU-fef8089b-4820-abfc-e83e-94318197576e"]
+                    Capabilities: [["gpu", "nvidia", "compute"]]
+                    Options:
+                      property1: "string"
+                      property2: "string"
+                MemorySwappiness: 60
+                OomKillDisable: false
+                OomScoreAdj: 500
+                PidMode: ""
+                PidsLimit: 0
+                PortBindings:
+                  22/tcp:
+                    - HostPort: "11022"
+                PublishAllPorts: false
+                Privileged: false
+                ReadonlyRootfs: false
+                Dns:
+                  - "8.8.8.8"
+                DnsOptions:
+                  - ""
+                DnsSearch:
+                  - ""
+                VolumesFrom:
+                  - "parent"
+                  - "other:ro"
+                CapAdd:
+                  - "NET_ADMIN"
+                CapDrop:
+                  - "MKNOD"
+                GroupAdd:
+                  - "newgroup"
+                RestartPolicy:
+                  Name: ""
+                  MaximumRetryCount: 0
+                AutoRemove: true
+                NetworkMode: "bridge"
+                Devices: []
+                Ulimits:
+                  - {}
+                LogConfig:
+                  Type: "json-file"
+                  Config: {}
+                SecurityOpt: []
+                StorageOpt: {}
+                CgroupParent: ""
+                VolumeDriver: ""
+                ShmSize: 67108864
+              NetworkingConfig:
+                EndpointsConfig:
+                  isolated_nw:
+                    IPAMConfig:
+                      IPv4Address: "172.20.30.33"
+                      IPv6Address: "2001:db8:abcd::3033"
+                      LinkLocalIPs:
+                        - "169.254.34.68"
+                        - "fe80::3468"
+                    Links:
+                      - "container_1"
+                      - "container_2"
+                    Aliases:
+                      - "server_x"
+                      - "server_y"
+                  database_nw: {}
+
+          required: true
+      responses:
+        201:
+          description: "Container created successfully"
+          schema:
+            $ref: "#/definitions/ContainerCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/{id}/json:
+    get:
+      summary: "Inspect a container"
+      description: "Return low-level information about a container."
+      operationId: "ContainerInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerInspectResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "size"
+          in: "query"
+          type: "boolean"
+          default: false
+          description: "Return the size of container as fields `SizeRw` and `SizeRootFs`"
+      tags: ["Container"]
+  /containers/{id}/top:
+    get:
+      summary: "List processes running inside a container"
+      description: |
+        On Unix systems, this is done by running the `ps` command. This endpoint
+        is not supported on Windows.
+      operationId: "ContainerTop"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerTopResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "ps_args"
+          in: "query"
+          description: "The arguments to pass to `ps`. For example, `aux`"
+          type: "string"
+          default: "-ef"
+      tags: ["Container"]
+  /containers/{id}/logs:
+    get:
+      summary: "Get container logs"
+      description: |
+        Get `stdout` and `stderr` logs from a container.
+
+        Note: This endpoint works only for containers with the `json-file` or
+        `journald` logging driver.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ContainerLogs"
+      responses:
+        200:
+          description: |
+            logs returned as a stream in response body.
+            For the stream format, [see the documentation for the attach endpoint](#operation/ContainerAttach).
+            Note that unlike the attach endpoint, the logs endpoint does not
+            upgrade the connection and does not set Content-Type.
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "until"
+          in: "query"
+          description: "Only return logs before this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Container"]
+  /containers/{id}/changes:
+    get:
+      summary: "Get changes on a container’s filesystem"
+      description: |
+        Returns which files in a container's filesystem have been added, deleted,
+        or modified. The `Kind` of modification can be one of:
+
+        - `0`: Modified ("C")
+        - `1`: Added ("A")
+        - `2`: Deleted ("D")
+      operationId: "ContainerChanges"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The list of changes"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/FilesystemChange"
+          examples:
+            application/json:
+              - Path: "/dev"
+                Kind: 0
+              - Path: "/dev/kmsg"
+                Kind: 1
+              - Path: "/test"
+                Kind: 1
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/export:
+    get:
+      summary: "Export a container"
+      description: "Export the contents of a container as a tarball."
+      operationId: "ContainerExport"
+      produces:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stats:
+    get:
+      summary: "Get container stats based on resource usage"
+      description: |
+        This endpoint returns a live stream of a container’s resource usage
+        statistics.
+
+        The `precpu_stats` is the CPU statistic of the *previous* read, and is
+        used to calculate the CPU usage percentage. It is not an exact copy
+        of the `cpu_stats` field.
+
+        If either `precpu_stats.online_cpus` or `cpu_stats.online_cpus` is
+        nil then for compatibility with older daemons the length of the
+        corresponding `cpu_usage.percpu_usage` array should be used.
+
+        On a cgroup v2 host, the following fields are not set
+        * `blkio_stats`: all fields other than `io_service_bytes_recursive`
+        * `cpu_stats`: `cpu_usage.percpu_usage`
+        * `memory_stats`: `max_usage` and `failcnt`
+        Also, `memory_stats.stats` fields are incompatible with cgroup v1.
+
+        To calculate the values shown by the `stats` command of the docker cli tool
+        the following formulas can be used:
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
+        * available_memory = `memory_stats.limit`
+        * Memory usage % = `(used_memory / available_memory) * 100.0`
+        * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
+        * system_cpu_delta = `cpu_stats.system_cpu_usage - precpu_stats.system_cpu_usage`
+        * number_cpus = `length(cpu_stats.cpu_usage.percpu_usage)` or `cpu_stats.online_cpus`
+        * CPU usage % = `(cpu_delta / system_cpu_delta) * number_cpus * 100.0`
+      operationId: "ContainerStats"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerStatsResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream the output. If false, the stats will be output once and then
+            it will disconnect.
+          type: "boolean"
+          default: true
+        - name: "one-shot"
+          in: "query"
+          description: |
+            Only get a single stat instead of waiting for 2 cycles. Must be used
+            with `stream=false`.
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/resize:
+    post:
+      summary: "Resize a container TTY"
+      description: "Resize the TTY for a container."
+      operationId: "ContainerResize"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "cannot resize container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/start:
+    post:
+      summary: "Start a container"
+      operationId: "ContainerStart"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already started"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container. Format is a
+            single character `[a-Z]` or `ctrl-<value>` where `<value>` is one
+            of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stop:
+    post:
+      summary: "Stop a container"
+      operationId: "ContainerStop"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already stopped"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/restart:
+    post:
+      summary: "Restart a container"
+      operationId: "ContainerRestart"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/kill:
+    post:
+      summary: "Kill a container"
+      description: |
+        Send a POSIX signal to a container, defaulting to killing to the
+        container.
+      operationId: "ContainerKill"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is not running"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "Container d37cde0fe4ad63c3a7252023b2f9800282894247d145cb5933ddf6e52cc03a28 is not running"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+          default: "SIGKILL"
+      tags: ["Container"]
+  /containers/{id}/update:
+    post:
+      summary: "Update a container"
+      description: |
+        Change various configuration options of a container without having to
+        recreate it.
+      operationId: "ContainerUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has been updated."
+          schema:
+            $ref: "#/definitions/ContainerUpdateResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "update"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/Resources"
+              - type: "object"
+                properties:
+                  RestartPolicy:
+                    $ref: "#/definitions/RestartPolicy"
+            example:
+              BlkioWeight: 300
+              CpuShares: 512
+              CpuPeriod: 100000
+              CpuQuota: 50000
+              CpuRealtimePeriod: 1000000
+              CpuRealtimeRuntime: 10000
+              CpusetCpus: "0,1"
+              CpusetMems: "0"
+              Memory: 314572800
+              MemorySwap: 514288000
+              MemoryReservation: 209715200
+              RestartPolicy:
+                MaximumRetryCount: 4
+                Name: "on-failure"
+      tags: ["Container"]
+  /containers/{id}/rename:
+    post:
+      summary: "Rename a container"
+      operationId: "ContainerRename"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "name already in use"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "name"
+          in: "query"
+          required: true
+          description: "New name for the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/pause:
+    post:
+      summary: "Pause a container"
+      description: |
+        Use the freezer cgroup to suspend all processes in a container.
+
+        Traditionally, when suspending a process the `SIGSTOP` signal is used,
+        which is observable by the process being suspended. With the freezer
+        cgroup the process is unaware, and unable to capture, that it is being
+        suspended, and subsequently resumed.
+      operationId: "ContainerPause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/unpause:
+    post:
+      summary: "Unpause a container"
+      description: "Resume a container which has been paused."
+      operationId: "ContainerUnpause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/attach:
+    post:
+      summary: "Attach to a container"
+      description: |
+        Attach to a container to read its output or send it input. You can attach
+        to the same container multiple times and you can reattach to containers
+        that have been detached.
+
+        Either the `stream` or `logs` parameter must be `true` for this endpoint
+        to do anything.
+
+        See the [documentation for the `docker attach` command](https://docs.docker.com/engine/reference/commandline/attach/)
+        for more details.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to transport `stdin`, `stdout`,
+        and `stderr` on the same socket.
+
+        This is the response from the daemon for an attach request:
+
+        ```
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        [STREAM]
+        ```
+
+        After the headers and two new lines, the TCP connection can now be used
+        for raw, bidirectional communication between the client and server.
+
+        To hint potential proxies about connection hijacking, the Docker client
+        can also optionally send connection upgrade headers.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /containers/16253994b7c4/attach?stream=1&stdout=1 HTTP/1.1
+        Upgrade: tcp
+        Connection: Upgrade
+        ```
+
+        The Docker daemon will respond with a `101 UPGRADED` response, and will
+        similarly follow with the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Content-Type: application/vnd.docker.raw-stream
+        Connection: Upgrade
+        Upgrade: tcp
+
+        [STREAM]
+        ```
+
+        ### Stream format
+
+        When the TTY setting is disabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the HTTP Content-Type header is set to application/vnd.docker.multiplexed-stream
+        and the stream over the hijacked connected is multiplexed to separate out
+        `stdout` and `stderr`. The stream consists of a series of frames, each
+        containing a header and a payload.
+
+        The header contains the information which the stream writes (`stdout` or
+        `stderr`). It also contains the size of the associated frame encoded in
+        the last four bytes (`uint32`).
+
+        It is encoded on the first eight bytes like this:
+
+        ```go
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+        ```
+
+        `STREAM_TYPE` can be:
+
+        - 0: `stdin` (is written on `stdout`)
+        - 1: `stdout`
+        - 2: `stderr`
+
+        `SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of the `uint32` size
+        encoded as big endian.
+
+        Following the header is the payload, which is the specified number of
+        bytes of `STREAM_TYPE`.
+
+        The simplest way to implement this protocol is the following:
+
+        1. Read 8 bytes.
+        2. Choose `stdout` or `stderr` depending on the first byte.
+        3. Extract the frame size from the last four bytes.
+        4. Read the extracted size and output it on the correct output.
+        5. Goto 1.
+
+        ### Stream format when using a TTY
+
+        When the TTY setting is enabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the stream is not multiplexed. The data exchanged over the hijacked
+        connection is simply the raw data from the process PTY and client's
+        `stdin`.
+
+      operationId: "ContainerAttach"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: |
+            Replay previous logs from the container.
+
+            This is useful for attaching to a container that has started and you
+            want to output everything since the container started.
+
+            If `stream` is also enabled, once all the previous output has been
+            returned, it will seamlessly transition into streaming current
+            output.
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream attached streams from the time the request was made onwards.
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/attach/ws:
+    get:
+      summary: "Attach to a container via a websocket"
+      operationId: "ContainerAttachWebsocket"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,`, or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: "Return logs"
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: "Return stream"
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/wait:
+    post:
+      summary: "Wait for a container"
+      description: "Block until a container stops, then returns the exit code."
+      operationId: "ContainerWait"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has exit."
+          schema:
+            $ref: "#/definitions/ContainerWaitResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "condition"
+          in: "query"
+          description: |
+            Wait until a container state reaches the given condition.
+
+            Defaults to `not-running` if omitted or empty.
+          type: "string"
+          enum:
+            - "not-running"
+            - "next-exit"
+            - "removed"
+          default: "not-running"
+      tags: ["Container"]
+  /containers/{id}:
+    delete:
+      summary: "Remove a container"
+      operationId: "ContainerDelete"
+      responses:
+        204:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: |
+                You cannot remove a running container: c2ada9df5af8. Stop the
+                container before attempting removal or force remove
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "v"
+          in: "query"
+          description: "Remove anonymous volumes associated with the container."
+          type: "boolean"
+          default: false
+        - name: "force"
+          in: "query"
+          description: "If the container is running, kill it before removing it."
+          type: "boolean"
+          default: false
+        - name: "link"
+          in: "query"
+          description: "Remove the specified link associated with the container."
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/archive:
+    head:
+      summary: "Get information about files in a container"
+      description: |
+        A response header `X-Docker-Container-Path-Stat` is returned, containing
+        a base64 - encoded JSON object with some filesystem header information
+        about the path.
+      operationId: "ContainerArchiveInfo"
+      responses:
+        200:
+          description: "no error"
+          headers:
+            X-Docker-Container-Path-Stat:
+              type: "string"
+              description: |
+                A base64 - encoded JSON object with some filesystem header
+                information about the path
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    get:
+      summary: "Get an archive of a filesystem resource in a container"
+      description: "Get a tar archive of a resource in the filesystem of container id."
+      operationId: "ContainerArchive"
+      produces: ["application/x-tar"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    put:
+      summary: "Extract an archive of files or folders to a directory in a container"
+      description: |
+        Upload a tar archive to be extracted to a path in the filesystem of container id.
+        `path` parameter is asserted to be a directory. If it exists as a file, 400 error
+        will be returned with message "not a directory".
+      operationId: "PutContainerArchive"
+      consumes: ["application/x-tar", "application/octet-stream"]
+      responses:
+        200:
+          description: "The content was extracted successfully"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "not a directory"
+        403:
+          description: "Permission denied, the volume or container rootfs is marked as read-only."
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such container or path does not exist inside the container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Path to a directory in the container to extract the archive’s contents into. "
+          type: "string"
+        - name: "noOverwriteDirNonDir"
+          in: "query"
+          description: |
+            If `1`, `true`, or `True` then it will be an error if unpacking the
+            given content would cause an existing directory to be replaced with
+            a non-directory and vice versa.
+          type: "string"
+        - name: "copyUIDGID"
+          in: "query"
+          description: |
+            If `1`, `true`, then it will copy UID/GID maps to the dest file or
+            dir
+          type: "string"
+        - name: "inputStream"
+          in: "body"
+          required: true
+          description: |
+            The input stream must be a tar archive compressed with one of the
+            following algorithms: `identity` (no compression), `gzip`, `bzip2`,
+            or `xz`.
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Container"]
+  /containers/prune:
+    post:
+      summary: "Delete stopped containers"
+      produces:
+        - "application/json"
+      operationId: "ContainerPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune containers created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune containers with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ContainerPruneResponse"
+            properties:
+              ContainersDeleted:
+                description: "Container IDs that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /images/json:
+    get:
+      summary: "List Images"
+      description: "Returns a list of images on the server. Note that it uses a different, smaller representation of an image than inspecting a single image."
+      operationId: "ImageList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "Summary image data for the images matching the query"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageSummary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: "Show all images. Only images from a final layer (no children) are shown by default."
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the images list.
+
+            Available filters:
+
+            - `before`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `dangling=true`
+            - `label=key` or `label="key=value"` of an image label
+            - `reference`=(`<image-name>[:<tag>]`)
+            - `since`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `until=<timestamp>`
+          type: "string"
+        - name: "shared-size"
+          in: "query"
+          description: "Compute and show shared size as a `SharedSize` field on each image."
+          type: "boolean"
+          default: false
+        - name: "digests"
+          in: "query"
+          description: "Show digest information as a `RepoDigests` field on each image."
+          type: "boolean"
+          default: false
+        - name: "manifests"
+          in: "query"
+          description: "Include `Manifests` in the image summary."
+          type: "boolean"
+          default: false
+        - name: "identity"
+          in: "query"
+          description: "Include `Identity` in each manifest summary. Requires `manifests=1`."
+          type: "boolean"
+          default: false
+      tags: ["Image"]
+  /build:
+    post:
+      summary: "Build an image"
+      description: |
+        Build an image from a tar archive with a `Dockerfile` in it.
+
+        The `Dockerfile` specifies how the image is built from the tar archive. It is typically in the archive's root, but can be at a different path or have a different name by specifying the `dockerfile` parameter. [See the `Dockerfile` reference for more information](https://docs.docker.com/engine/reference/builder/).
+
+        The Docker daemon performs a preliminary validation of the `Dockerfile` before starting the build, and returns an error if the syntax is incorrect. After that, each instruction is run one-by-one until the ID of the new image is output.
+
+        The build is canceled if the client drops the connection by quitting or being killed.
+      operationId: "ImageBuild"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "inputStream"
+          in: "body"
+          description: "A tar archive compressed with one of the following algorithms: identity (no compression), gzip, bzip2, xz."
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "dockerfile"
+          in: "query"
+          description: "Path within the build context to the `Dockerfile`. This is ignored if `remote` is specified and points to an external `Dockerfile`."
+          type: "string"
+          default: "Dockerfile"
+        - name: "t"
+          in: "query"
+          description: "A name and optional tag to apply to the image in the `name:tag` format. If you omit the tag the default `latest` value is assumed. You can provide several `t` parameters."
+          type: "string"
+        - name: "extrahosts"
+          in: "query"
+          description: "Extra hosts to add to /etc/hosts"
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: "A Git repository URI or HTTP/HTTPS context URI. If the URI points to a single text file, the file’s contents are placed into a file called `Dockerfile` and the image is built from that file. If the URI points to a tarball, the file is downloaded by the daemon and the contents therein used as the context for the build. If the URI points to a tarball and the `dockerfile` parameter is also specified, there must be a file with the corresponding path inside the tarball."
+          type: "string"
+        - name: "q"
+          in: "query"
+          description: "Suppress verbose build output."
+          type: "boolean"
+          default: false
+        - name: "nocache"
+          in: "query"
+          description: "Do not use the cache when building the image."
+          type: "boolean"
+          default: false
+        - name: "cachefrom"
+          in: "query"
+          description: "JSON array of images used for build cache resolution."
+          type: "string"
+        - name: "pull"
+          in: "query"
+          description: "Attempt to pull the image even if an older image exists locally."
+          type: "string"
+        - name: "rm"
+          in: "query"
+          description: "Remove intermediate containers after a successful build."
+          type: "boolean"
+          default: true
+        - name: "forcerm"
+          in: "query"
+          description: "Always remove intermediate containers, even upon failure."
+          type: "boolean"
+          default: false
+        - name: "memory"
+          in: "query"
+          description: "Set memory limit for build."
+          type: "integer"
+        - name: "memswap"
+          in: "query"
+          description: "Total memory (memory + swap). Set as `-1` to disable swap."
+          type: "integer"
+        - name: "cpushares"
+          in: "query"
+          description: "CPU shares (relative weight)."
+          type: "integer"
+        - name: "cpusetcpus"
+          in: "query"
+          description: "CPUs in which to allow execution (e.g., `0-3`, `0,1`)."
+          type: "string"
+        - name: "cpuperiod"
+          in: "query"
+          description: "The length of a CPU period in microseconds."
+          type: "integer"
+        - name: "cpuquota"
+          in: "query"
+          description: "Microseconds of CPU time that the container can get in a CPU period."
+          type: "integer"
+        - name: "buildargs"
+          in: "query"
+          description: >
+            JSON map of string pairs for build-time variables. Users pass these values at build-time. Docker
+            uses the buildargs as the environment context for commands run via the `Dockerfile` RUN
+            instruction, or for variable expansion in other `Dockerfile` instructions. This is not meant for
+            passing secret values.
+
+
+            For example, the build arg `FOO=bar` would become `{"FOO":"bar"}` in JSON. This would result in the
+            query parameter `buildargs={"FOO":"bar"}`. Note that `{"FOO":"bar"}` should be URI component encoded.
+
+
+            [Read more about the buildargs instruction.](https://docs.docker.com/engine/reference/builder/#arg)
+          type: "string"
+        - name: "shmsize"
+          in: "query"
+          description: "Size of `/dev/shm` in bytes. The size must be greater than 0. If omitted the system uses 64MB."
+          type: "integer"
+        - name: "squash"
+          in: "query"
+          description: "Squash the resulting images layers into a single layer. *(Experimental release only.)*"
+          type: "boolean"
+        - name: "labels"
+          in: "query"
+          description: "Arbitrary key/value labels to set on the image, as a JSON map of string pairs."
+          type: "string"
+        - name: "networkmode"
+          in: "query"
+          description: |
+            Sets the networking mode for the run commands during build. Supported
+            standard values are: `bridge`, `host`, `none`, and `container:<name|id>`.
+            Any other value is taken as a custom network's name or ID to which this
+            container should connect to.
+          type: "string"
+        - name: "Content-type"
+          in: "header"
+          type: "string"
+          enum:
+            - "application/x-tar"
+          default: "application/x-tar"
+        - name: "X-Registry-Config"
+          in: "header"
+          description: |
+            This is a base64-encoded JSON object with auth configurations for multiple registries that a build may refer to.
+
+            The key is a registry URL, and the value is an auth configuration object, [as described in the authentication section](#section/Authentication). For example:
+
+            ```
+            {
+              "docker.example.com": {
+                "username": "janedoe",
+                "password": "hunter2"
+              },
+              "https://index.docker.io/v1/": {
+                "username": "mobydock",
+                "password": "conta1n3rize14"
+              }
+            }
+            ```
+
+            Only the registry domain name (and port if not the default 443) are required. However, for legacy reasons, the Docker Hub registry must be specified with both a `https://` prefix and a `/v1/` suffix even though Docker will prefer to use the v2 registry API.
+          type: "string"
+        - name: "platform"
+          in: "query"
+          description: "Platform in the format os[/arch[/variant]]"
+          type: "string"
+          default: ""
+        - name: "target"
+          in: "query"
+          description: "Target build stage"
+          type: "string"
+          default: ""
+        - name: "outputs"
+          in: "query"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
+          type: "string"
+          default: ""
+        - name: "version"
+          in: "query"
+          type: "string"
+          default: "1"
+          enum: ["1", "2"]
+          description: |
+            Version of the builder backend to use.
+
+            - `1` is the first generation classic (deprecated) builder in the Docker daemon (default)
+            - `2` is [BuildKit](https://github.com/moby/buildkit)
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /build/prune:
+    post:
+      summary: "Delete builder cache"
+      produces:
+        - "application/json"
+      operationId: "BuildPrune"
+      parameters:
+        - name: "reserved-space"
+          in: "query"
+          description: "Amount of disk space in bytes to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "max-used-space"
+          in: "query"
+          description: "Maximum amount of disk space allowed to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "min-free-space"
+          in: "query"
+          description: "Target amount of free disk space after pruning"
+          type: "integer"
+          format: "int64"
+        - name: "all"
+          in: "query"
+          type: "boolean"
+          description: "Remove all types of build cache"
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the list of build cache objects.
+
+            Available filters:
+
+            - `until=<timestamp>` remove cache older than `<timestamp>`. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon's local time.
+            - `id=<id>`
+            - `parent=<id>`
+            - `type=<string>`
+            - `description=<string>`
+            - `inuse`
+            - `shared`
+            - `private`
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "BuildPruneResponse"
+            properties:
+              CachesDeleted:
+                type: "array"
+                items:
+                  description: "ID of build cache object"
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /images/create:
+    post:
+      summary: "Create an image"
+      description: "Pull or import an image."
+      operationId: "ImageCreate"
+      consumes:
+        - "text/plain"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "repository does not exist or no read access"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "fromImage"
+          in: "query"
+          description: |
+            Name of the image to pull. If the name includes a tag or digest, specific behavior applies:
+
+            - If only `fromImage` includes a tag, that tag is used.
+            - If both `fromImage` and `tag` are provided, `tag` takes precedence.
+            - If `fromImage` includes a digest, the image is pulled by digest, and `tag` is ignored.
+            - If neither a tag nor digest is specified, all tags are pulled.
+          type: "string"
+        - name: "fromSrc"
+          in: "query"
+          description: "Source to import. The value may be a URL from which the image can be retrieved or `-` to read the image from the request body. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name given to an image when it is imported. The repo may include a tag. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag or digest. If empty when pulling an image, this causes all tags for the given image to be pulled."
+          type: "string"
+        - name: "message"
+          in: "query"
+          description: "Set commit message for imported image."
+          type: "string"
+        - name: "inputImage"
+          in: "body"
+          description: "Image content if the value `-` has been specified in fromSrc query parameter"
+          schema:
+            type: "string"
+          required: false
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "changes"
+          in: "query"
+          description: |
+            Apply `Dockerfile` instructions to the image that is created,
+            for example: `changes=ENV DEBUG=true`.
+            Note that `ENV DEBUG=true` should be URI component encoded.
+
+            Supported `Dockerfile` instructions:
+            `CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format os[/arch[/variant]].
+
+            When used in combination with the `fromImage` option, the daemon checks
+            if the given image is present in the local image cache with the given
+            OS and Architecture, and otherwise attempts to pull the image. If the
+            option is not set, the host's native OS and Architecture are used.
+            If the given image does not exist in the local image cache, the daemon
+            attempts to pull the image with the host's native OS and Architecture.
+            If the given image does exists in the local image cache, but its OS or
+            architecture does not match, a warning is produced.
+
+            When used with the `fromSrc` option to import an image from an archive,
+            this option sets the platform information for the imported image. If
+            the option is not set, the host's native OS and Architecture are used
+            for the imported image.
+          type: "string"
+          default: ""
+      tags: ["Image"]
+  /images/{name}/json:
+    get:
+      summary: "Inspect an image"
+      description: "Return low-level information about an image."
+      operationId: "ImageInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/ImageInspect"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+        - name: "manifests"
+          in: "query"
+          description: |-
+            Include Manifests in the image summary.
+
+            The `manifests` and `platform` options are mutually exclusive, and
+            an error is produced if both are set.
+          type: "boolean"
+          default: false
+          required: false
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |-
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show inspect. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            The `platform` and `manifests` options are mutually exclusive, and
+            an error is produced if both are set.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/history:
+    get:
+      summary: "Get the history of an image"
+      description: "Return parent layers of an image."
+      operationId: "ImageHistory"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "List of image layers"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageHistoryResponseItem"
+          examples:
+            application/json:
+              - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
+                Created: 1398108230
+                CreatedBy: "/bin/sh -c #(nop) ADD file:eb15dbd63394e063b805a3c32ca7bf0266ef64676d5a6fab4801f2e81e2a5148 in /"
+                Tags:
+                  - "ubuntu:lucid"
+                  - "ubuntu:10.04"
+                Size: 182964289
+                Comment: ""
+              - Id: "6cfa4d1f33fb861d4d114f43b25abd0ac737509268065cdfd69d544a59c85ab8"
+                Created: 1398108222
+                CreatedBy: "/bin/sh -c #(nop) MAINTAINER Tianon Gravi <admwiggin@gmail.com> - mkimage-debootstrap.sh -i iproute,iputils-ping,ubuntu-minimal -t lucid.tar.xz lucid http://archive.ubuntu.com/ubuntu/"
+                Tags: []
+                Size: 0
+                Comment: ""
+              - Id: "511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158"
+                Created: 1371157430
+                CreatedBy: ""
+                Tags:
+                  - "scratch12:latest"
+                  - "scratch:latest"
+                Size: 0
+                Comment: "Imported from -"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show the history for. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/push:
+    post:
+      summary: "Push an image"
+      description: |
+        Push an image to a registry.
+
+        If you wish to push an image on to a private registry, that image must
+        already have a tag which references the registry. For example,
+        `registry.example.com/myimage:latest`.
+
+        The push is cancelled if the HTTP connection is closed.
+      operationId: "ImagePush"
+      consumes:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            Name of the image to push. For example, `registry.example.com/myimage`.
+            The image must be present in the local image store with the same name.
+
+            The name should be provided without tag; if a tag is provided, it
+            is ignored. For example, `registry.example.com/myimage:latest` is
+            considered equivalent to `registry.example.com/myimage`.
+
+            Use the `tag` parameter to specify the tag to push.
+          type: "string"
+          required: true
+        - name: "tag"
+          in: "query"
+          description: |
+            Tag of the image to push. For example, `latest`. If no tag is provided,
+            all tags of the given image that are present in the local image store
+            are pushed.
+          type: "string"
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant to push.
+            If not provided, all available variants will attempt to be pushed.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to push to the registry. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+          required: true
+      tags: ["Image"]
+  /images/{name}/tag:
+    post:
+      summary: "Tag an image"
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
+      operationId: "ImageTag"
+      responses:
+        201:
+          description: "No error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID to tag."
+          type: "string"
+          required: true
+        - name: "repo"
+          in: "query"
+          description: "The repository to tag in. For example, `someuser/someimage`."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "The name of the new tag."
+          type: "string"
+      tags: ["Image"]
+  /images/{name}:
+    delete:
+      summary: "Remove an image"
+      description: |
+        Remove an image, along with any untagged parent images that were
+        referenced by that image.
+
+        Images can't be removed if they have descendant images, are being
+        used by a running container or are being used by a build.
+      operationId: "ImageDelete"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The image was deleted successfully"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageDeleteResponseItem"
+          examples:
+            application/json:
+              - Untagged: "3e2f21a89f"
+              - Deleted: "3e2f21a89f"
+              - Deleted: "53b4f83ac9"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Remove the image even if it is being used by stopped containers or has other tags"
+          type: "boolean"
+          default: false
+        - name: "noprune"
+          in: "query"
+          description: "Do not delete untagged parent images"
+          type: "boolean"
+          default: false
+        - name: "platforms"
+          in: "query"
+          description: |
+            Select platform-specific content to delete.
+            Multiple values are accepted.
+            Each platform is a OCI platform encoded as a JSON string.
+          type: "array"
+          items:
+            # This should be OCIPlatform
+            # but $ref is not supported for array in query in Swagger 2.0
+            # $ref: "#/definitions/OCIPlatform"
+            type: "string"
+      tags: ["Image"]
+  /images/search:
+    get:
+      summary: "Search images"
+      description: "Search for an image on Docker Hub."
+      operationId: "ImageSearch"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              type: "object"
+              title: "ImageSearchResponseItem"
+              properties:
+                description:
+                  type: "string"
+                is_official:
+                  type: "boolean"
+                is_automated:
+                  description: |
+                    Whether this repository has automated builds enabled.
+
+                    <p><br /></p>
+
+                    > **Deprecated**: This field is deprecated and will always be "false".
+                  type: "boolean"
+                  example: false
+                name:
+                  type: "string"
+                star_count:
+                  type: "integer"
+          examples:
+            application/json:
+              - description: "A minimal Docker image based on Alpine Linux with a complete package index and only 5 MB in size!"
+                is_official: true
+                is_automated: false
+                name: "alpine"
+                star_count: 10093
+              - description: "Busybox base image."
+                is_official: true
+                is_automated: false
+                name: "Busybox base image."
+                star_count: 3037
+              - description: "The PostgreSQL object-relational database system provides reliability and data integrity."
+                is_official: true
+                is_automated: false
+                name: "postgres"
+                star_count: 12408
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "term"
+          in: "query"
+          description: "Term to search"
+          type: "string"
+          required: true
+        - name: "limit"
+          in: "query"
+          description: "Maximum number of results to return"
+          type: "integer"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to process on the images list. Available filters:
+
+            - `is-official=(true|false)`
+            - `stars=<number>` Matches images that has at least 'number' stars.
+          type: "string"
+      tags: ["Image"]
+  /images/prune:
+    post:
+      summary: "Delete unused images"
+      produces:
+        - "application/json"
+      operationId: "ImagePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`). Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), prune only
+               unused *and* untagged images. When set to `false`
+               (or `0`), all unused images are pruned.
+            - `until=<string>` Prune images created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune images with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ImagePruneResponse"
+            properties:
+              ImagesDeleted:
+                description: "Images that were deleted"
+                type: "array"
+                items:
+                  $ref: "#/definitions/ImageDeleteResponseItem"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /auth:
+    post:
+      summary: "Check auth configuration"
+      description: |
+        Validate credentials for a registry and, if available, get an identity
+        token for accessing the registry without password.
+      operationId: "SystemAuth"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "An identity token was generated successfully."
+          schema:
+            $ref: "#/definitions/AuthResponse"
+        204:
+          description: "No error"
+        401:
+          description: "Auth error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "authConfig"
+          in: "body"
+          description: "Authentication to check"
+          schema:
+            $ref: "#/definitions/AuthConfig"
+      tags: ["System"]
+  /info:
+    get:
+      summary: "Get system information"
+      operationId: "SystemInfo"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/SystemInfo"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /version:
+    get:
+      summary: "Get version"
+      description: "Returns the version of Docker that is running and various information about the system that Docker is running on."
+      operationId: "SystemVersion"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/SystemVersion"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /_ping:
+    get:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPing"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "OK"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: |
+                Default version of docker image builder
+
+                The default on Linux is version "2" (BuildKit), but the daemon
+                can be configured to recommend version "1" (classic Builder).
+                Windows does not yet support BuildKit for native Windows images,
+                and uses "1" (classic builder) as a default.
+
+                This value is a recommendation as advertised by the daemon, and
+                it is up to the client to choose which builder to use.
+              default: "2"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          headers:
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+      tags: ["System"]
+    head:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPingHead"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "(empty)"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: "Default version of docker image builder"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /commit:
+    post:
+      summary: "Create a new image from a container"
+      operationId: "ImageCommit"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "containerConfig"
+          in: "body"
+          description: "The container configuration"
+          schema:
+            $ref: "#/definitions/ContainerConfig"
+        - name: "container"
+          in: "query"
+          description: "The ID or name of the container to commit"
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name for the created image"
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag name for the create image"
+          type: "string"
+        - name: "comment"
+          in: "query"
+          description: "Commit message"
+          type: "string"
+        - name: "author"
+          in: "query"
+          description: "Author of the image (e.g., `John Hannibal Smith <hannibal@a-team.com>`)"
+          type: "string"
+        - name: "pause"
+          in: "query"
+          description: "Whether to pause the container before committing"
+          type: "boolean"
+          default: true
+        - name: "changes"
+          in: "query"
+          description: "`Dockerfile` instructions to apply while committing"
+          type: "string"
+      tags: ["Image"]
+  /events:
+    get:
+      summary: "Monitor events"
+      description: |
+        Stream real-time events from the server.
+
+        Various objects within Docker report events when something happens to them.
+
+        Containers report these events: `attach`, `commit`, `copy`, `create`, `destroy`, `detach`, `die`, `exec_create`, `exec_detach`, `exec_start`, `exec_die`, `export`, `health_status`, `kill`, `oom`, `pause`, `rename`, `resize`, `restart`, `start`, `stop`, `top`, `unpause`, `update`, and `prune`
+
+        Images report these events: `create`, `delete`, `import`, `load`, `pull`, `push`, `save`, `tag`, `untag`, and `prune`
+
+        Volumes report these events: `create`, `mount`, `unmount`, `destroy`, and `prune`
+
+        Networks report these events: `create`, `connect`, `disconnect`, `destroy`, `update`, `remove`, and `prune`
+
+        The Docker daemon reports these events: `reload`
+
+        Services report these events: `create`, `update`, and `remove`
+
+        Nodes report these events: `create`, `update`, and `remove`
+
+        Secrets report these events: `create`, `update`, and `remove`
+
+        Configs report these events: `create`, `update`, and `remove`
+
+        The Builder reports `prune` events
+
+      operationId: "SystemEvents"
+      produces:
+        - "application/jsonl"
+        - "application/x-ndjson"
+        - "application/json-seq"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/EventMessage"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "since"
+          in: "query"
+          description: "Show events created since this timestamp then stream new events."
+          type: "string"
+        - name: "until"
+          in: "query"
+          description: "Show events created until this timestamp then stop streaming."
+          type: "string"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of filters (a `map[string][]string`) to process on the event list. Available filters:
+
+            - `config=<string>` config name or ID
+            - `container=<string>` container name or ID
+            - `daemon=<string>` daemon name or ID
+            - `event=<string>` event type
+            - `image=<string>` image name or ID
+            - `label=<string>` image or container label
+            - `network=<string>` network name or ID
+            - `node=<string>` node ID
+            - `plugin`=<string> plugin name or ID
+            - `scope`=<string> local or swarm
+            - `secret=<string>` secret name or ID
+            - `service=<string>` service name or ID
+            - `type=<string>` object to filter by, one of `container`, `image`, `volume`, `network`, `daemon`, `plugin`, `node`, `service`, `secret` or `config`
+            - `volume=<string>` volume name
+          type: "string"
+      tags: ["System"]
+  /system/df:
+    get:
+      summary: "Get data usage information"
+      operationId: "SystemDataUsage"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "SystemDataUsageResponse"
+            properties:
+              ImageUsage:
+                $ref: "#/definitions/ImagesDiskUsage"
+              ContainerUsage:
+                $ref: "#/definitions/ContainersDiskUsage"
+              VolumeUsage:
+                $ref: "#/definitions/VolumesDiskUsage"
+              BuildCacheUsage:
+                $ref: "#/definitions/BuildCacheDiskUsage"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "type"
+          in: "query"
+          description: |
+            Object types, for which to compute and return data.
+          type: "array"
+          collectionFormat: multi
+          items:
+            type: "string"
+            enum: ["container", "image", "volume", "build-cache"]
+        - name: "verbose"
+          in: "query"
+          description: |
+            Show detailed information on space usage.
+          type: "boolean"
+          default: false
+      tags: ["System"]
+  /images/{name}/get:
+    get:
+      summary: "Export an image"
+      description: |
+        Get a tarball containing all images and metadata for a repository.
+
+        If `name` is a specific name and tag (e.g. `ubuntu:latest`), then only that image (and its parents) are returned. If `name` is an image ID, similarly only that image (and its parents) are returned, but with the exclusion of the `repositories` file in the tarball, as there were no image names referenced.
+
+        ### Image tarball format
+
+        An image tarball contains [Content as defined in the OCI Image Layout Specification](https://github.com/opencontainers/image-spec/blob/v1.1.1/image-layout.md#content).
+
+        Additionally, includes the manifest.json file associated with a backwards compatible docker save format.
+
+        If the tarball defines a repository, the tarball should also include a `repositories` file at the root that contains a list of repository and tag names mapped to layer IDs.
+
+        ```json
+        {
+          "hello-world": {
+            "latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"
+          }
+        }
+        ```
+      operationId: "ImageGet"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform describing a platform which will be used
+            to select a platform-specific image to be saved if the image is
+            multi-platform.
+            If not provided, the full multi-platform image will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/get:
+    get:
+      summary: "Export several images"
+      description: |
+        Get a tarball containing all images and metadata for several image
+        repositories.
+
+        For each value of the `names` parameter: if it is a specific name and
+        tag (e.g. `ubuntu:latest`), then only that image (and its parents) are
+        returned; if it is an image ID, similarly only that image (and its parents)
+        are returned and there would be no names referenced in the 'repositories'
+        file for this image ID.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageGetAll"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "names"
+          in: "query"
+          description: "Image names to filter by"
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform(s) which will be used to select the
+            platform-specific image(s) to be saved if the image is
+            multi-platform. If not provided, the full multi-platform image
+            will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/load:
+    post:
+      summary: "Import images"
+      description: |
+        Load a set of images and tags into a repository.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageLoad"
+      consumes:
+        - "application/x-tar"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "imagesTarball"
+          in: "body"
+          description: "Tar archive containing images"
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "quiet"
+          in: "query"
+          description: "Suppress progress details during load."
+          type: "boolean"
+          default: false
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform(s) which will be used to select the
+            platform-specific image(s) to load if the image is
+            multi-platform. If not provided, the full multi-platform image
+            will be loaded.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /containers/{id}/exec:
+    post:
+      summary: "Create an exec instance"
+      description: "Run a command inside a running container."
+      operationId: "ContainerExec"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execConfig"
+          in: "body"
+          description: "Exec configuration"
+          schema:
+            type: "object"
+            title: "ExecConfig"
+            properties:
+              AttachStdin:
+                type: "boolean"
+                description: "Attach to `stdin` of the exec command."
+              AttachStdout:
+                type: "boolean"
+                description: "Attach to `stdout` of the exec command."
+              AttachStderr:
+                type: "boolean"
+                description: "Attach to `stderr` of the exec command."
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+              DetachKeys:
+                type: "string"
+                description: |
+                  Override the key sequence for detaching a container. Format is
+                  a single character `[a-Z]` or `ctrl-<value>` where `<value>`
+                  is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+              Env:
+                description: |
+                  A list of environment variables in the form `["VAR=value", ...]`.
+                type: "array"
+                items:
+                  type: "string"
+              Cmd:
+                type: "array"
+                description: "Command to run, as a string or array of strings."
+                items:
+                  type: "string"
+              Privileged:
+                type: "boolean"
+                description: "Runs the exec process with extended privileges."
+                default: false
+              User:
+                type: "string"
+                description: |
+                  The user, and optionally, group to run the exec process inside
+                  the container. Format is one of: `user`, `user:group`, `uid`,
+                  or `uid:gid`.
+              WorkingDir:
+                type: "string"
+                description: |
+                  The working directory for the exec process inside the container.
+            example:
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              DetachKeys: "ctrl-p,ctrl-q"
+              Tty: false
+              Cmd:
+                - "date"
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+          required: true
+        - name: "id"
+          in: "path"
+          description: "ID or name of container"
+          type: "string"
+          required: true
+      tags: ["Exec"]
+  /exec/{id}/start:
+    post:
+      summary: "Start an exec instance"
+      description: |
+        Starts a previously set up exec instance. If detach is true, this endpoint
+        returns immediately after starting the command. Otherwise, it sets up an
+        interactive session with the command.
+      operationId: "ExecStart"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Container is stopped or paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execStartConfig"
+          in: "body"
+          schema:
+            type: "object"
+            title: "ExecStartConfig"
+            properties:
+              Detach:
+                type: "boolean"
+                description: "Detach from the command."
+                example: false
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+                example: true
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+  /exec/{id}/resize:
+    post:
+      summary: "Resize an exec instance"
+      description: |
+        Resize the TTY session used by an exec instance. This endpoint only works
+        if `tty` was specified as part of creating and starting the exec instance.
+      operationId: "ExecResize"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Exec"]
+  /exec/{id}/json:
+    get:
+      summary: "Inspect an exec instance"
+      description: "Return low-level information about an exec instance."
+      operationId: "ExecInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ExecInspectResponse"
+            properties:
+              CanRemove:
+                type: "boolean"
+              DetachKeys:
+                type: "string"
+              ID:
+                type: "string"
+              Running:
+                type: "boolean"
+              ExitCode:
+                type: "integer"
+              ProcessConfig:
+                $ref: "#/definitions/ProcessConfig"
+              OpenStdin:
+                type: "boolean"
+              OpenStderr:
+                type: "boolean"
+              OpenStdout:
+                type: "boolean"
+              ContainerID:
+                type: "string"
+              Pid:
+                type: "integer"
+                description: "The system process ID for the exec process."
+          examples:
+            application/json:
+              CanRemove: false
+              ContainerID: "b53ee82b53a40c7dca428523e34f741f3abc51d9f297a14ff874bf761b995126"
+              DetachKeys: ""
+              ExitCode: 2
+              ID: "f33bbfb39f5b142420f4759b2348913bd4a8d1a6d7fd56499cb41a1bb91d7b3b"
+              OpenStderr: true
+              OpenStdin: true
+              OpenStdout: true
+              ProcessConfig:
+                arguments:
+                  - "-c"
+                  - "exit 2"
+                entrypoint: "sh"
+                privileged: false
+                tty: true
+                user: "1000"
+              Running: false
+              Pid: 42000
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+
+  /volumes:
+    get:
+      summary: "List volumes"
+      operationId: "VolumeList"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "Summary volume data that matches the query"
+          schema:
+            $ref: "#/definitions/VolumeListResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to
+            process on the volumes list. Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               volumes that are not in use by a container. When set to `false`
+               (or `0`), only volumes that are in use by one or more
+               containers are returned.
+            - `driver=<volume-driver-name>` Matches volumes based on their driver.
+            - `label=<key>` or `label=<key>:<value>` Matches volumes based on
+               the presence of a `label` alone or a `label` and a value.
+            - `name=<volume-name>` Matches all or part of a volume name.
+          type: "string"
+          format: "json"
+      tags: ["Volume"]
+
+  /volumes/create:
+    post:
+      summary: "Create a volume"
+      operationId: "VolumeCreate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        201:
+          description: "The volume was created successfully"
+          schema:
+            $ref: "#/definitions/Volume"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "volumeConfig"
+          in: "body"
+          required: true
+          description: "Volume configuration"
+          schema:
+            $ref: "#/definitions/VolumeCreateRequest"
+      tags: ["Volume"]
+
+  /volumes/{name}:
+    get:
+      summary: "Inspect a volume"
+      operationId: "VolumeInspect"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/Volume"
+        404:
+          description: "No such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+      tags: ["Volume"]
+
+    put:
+      summary: |
+        "Update a volume. Valid only for Swarm cluster volumes"
+      operationId: "VolumeUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "The name or ID of the volume"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            # though the schema for is an object that contains only a
+            # ClusterVolumeSpec, wrapping the ClusterVolumeSpec in this object
+            # means that if, later on, we support things like changing the
+            # labels, we can do so without duplicating that information to the
+            # ClusterVolumeSpec.
+            type: "object"
+            description: "Volume configuration"
+            properties:
+              Spec:
+                $ref: "#/definitions/ClusterVolumeSpec"
+          description: |
+            The spec of the volume to update. Currently, only Availability may
+            change. All other fields must remain unchanged.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the volume being updated. This is required to
+            avoid conflicting writes. Found in the volume's `ClusterVolume`
+            field.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Volume"]
+
+    delete:
+      summary: "Remove a volume"
+      description: "Instruct the driver to remove the volume."
+      operationId: "VolumeDelete"
+      responses:
+        204:
+          description: "The volume was removed"
+        404:
+          description: "No such volume or volume driver"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Volume is in use and cannot be removed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: "Force the removal of the volume"
+          type: "boolean"
+          default: false
+      tags: ["Volume"]
+
+  /volumes/prune:
+    post:
+      summary: "Delete unused volumes"
+      produces:
+        - "application/json"
+      operationId: "VolumePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune volumes with (or without, in case `label!=...` is used) the specified labels.
+            - `all` (`all=true`) - Consider all (local) volumes for pruning and not just anonymous volumes.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "VolumePruneResponse"
+            properties:
+              VolumesDeleted:
+                description: "Volumes that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Volume"]
+  /networks:
+    get:
+      summary: "List networks"
+      description: |
+        Returns a list of networks. For details on the format, see the
+        [network inspect endpoint](#operation/NetworkInspect).
+
+        Note that it uses a different, smaller representation of a network than
+        inspecting a single network. For example, the list of containers attached
+        to the network is not propagated in API versions 1.28 and up.
+      operationId: "NetworkList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/NetworkSummary"
+          examples:
+            application/json:
+              - Name: "bridge"
+                Id: "f2de39df4171b0dc801e8002d1d999b77256983dfc63041c0f34030aa3977566"
+                Created: "2016-10-19T06:21:00.416543526Z"
+                Scope: "local"
+                Driver: "bridge"
+                EnableIPv4: true
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config:
+                    -
+                      Subnet: "172.17.0.0/16"
+                Options:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              - Name: "none"
+                Id: "e086a3893b05ab69242d3c44e49483a3bbbd3a26b46baa8f61ab797c1088d794"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "null"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+              - Name: "host"
+                Id: "13e871235c677f196c4e1ecebb9dc733b9b2d2ab589e30c539efeda84a24215e"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "host"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to process
+            on the networks list.
+
+            Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               networks that are not in use by a container. When set to `false`
+               (or `0`), only networks that are in use by one or more
+               containers are returned.
+            - `driver=<driver-name>` Matches a network's driver.
+            - `id=<network-id>` Matches all or part of a network ID.
+            - `label=<key>` or `label=<key>=<value>` of a network label.
+            - `name=<network-name>` Matches all or part of a network name.
+            - `scope=["swarm"|"global"|"local"]` Filters networks by scope (`swarm`, `global`, or `local`).
+            - `type=["custom"|"builtin"]` Filters networks by type. The `custom` keyword returns all user-defined networks.
+          type: "string"
+      tags: ["Network"]
+
+  /networks/{id}:
+    get:
+      summary: "Inspect a network"
+      operationId: "NetworkInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/NetworkInspect"
+        404:
+          description: "Network not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "verbose"
+          in: "query"
+          description: "Detailed inspect output for troubleshooting"
+          type: "boolean"
+          default: false
+        - name: "scope"
+          in: "query"
+          description: "Filter the network by scope (swarm, global, or local)"
+          type: "string"
+      tags: ["Network"]
+
+    delete:
+      summary: "Remove a network"
+      operationId: "NetworkDelete"
+      responses:
+        204:
+          description: "No error"
+        403:
+          description: "operation not supported for pre-defined networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such network"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+      tags: ["Network"]
+
+  /networks/create:
+    post:
+      summary: "Create a network"
+      operationId: "NetworkCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "Network created successfully"
+          schema:
+            $ref: "#/definitions/NetworkCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: |
+            Forbidden operation. This happens when trying to create a network named after a pre-defined network,
+            or when trying to create an overlay network on a daemon which is not part of a Swarm cluster.
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "plugin not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "networkConfig"
+          in: "body"
+          description: "Network configuration"
+          required: true
+          schema:
+            type: "object"
+            title: "NetworkCreateRequest"
+            required: ["Name"]
+            properties:
+              Name:
+                description: "The network's name."
+                type: "string"
+                example: "my_network"
+              Driver:
+                description: "Name of the network driver plugin to use."
+                type: "string"
+                default: "bridge"
+                example: "bridge"
+              Scope:
+                description: |
+                  The level at which the network exists (e.g. `swarm` for cluster-wide
+                  or `local` for machine level).
+                type: "string"
+              Internal:
+                description: "Restrict external access to the network."
+                type: "boolean"
+              Attachable:
+                description: |
+                  Globally scoped network is manually attachable by regular
+                  containers from workers in swarm mode.
+                type: "boolean"
+                example: true
+              Ingress:
+                description: |
+                  Ingress network is the network which provides the routing-mesh
+                  in swarm mode.
+                type: "boolean"
+                example: false
+              ConfigOnly:
+                description: |
+                  Creates a config-only network. Config-only networks are placeholder
+                  networks for network configurations to be used by other networks.
+                  Config-only networks cannot be used directly to run containers
+                  or services.
+                type: "boolean"
+                default: false
+                example: false
+              ConfigFrom:
+                description: |
+                  Specifies the source which will provide the configuration for
+                  this network. The specified network must be an existing
+                  config-only network; see ConfigOnly.
+                $ref: "#/definitions/ConfigReference"
+              IPAM:
+                description: "Optional custom IP scheme for the network."
+                $ref: "#/definitions/IPAM"
+              EnableIPv4:
+                description: "Enable IPv4 on the network."
+                type: "boolean"
+                example: true
+              EnableIPv6:
+                description: "Enable IPv6 on the network."
+                type: "boolean"
+                example: true
+              Options:
+                description: "Network specific options to be used by the drivers."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              Labels:
+                description: "User-defined key/value metadata."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.example.some-label: "some-value"
+                  com.example.some-other-label: "some-other-value"
+      tags: ["Network"]
+
+  /networks/{id}/connect:
+    post:
+      summary: "Connect a container to a network"
+      description: "The network must be either a local-scoped network or a swarm-scoped network with the `attachable` option set. A network cannot be re-attached to a running container"
+      operationId: "NetworkConnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "Operation forbidden"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/NetworkConnectRequest"
+      tags: ["Network"]
+
+  /networks/{id}/disconnect:
+    post:
+      summary: "Disconnect a container from a network"
+      operationId: "NetworkDisconnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        403:
+          description: "Operation not supported for swarm scoped networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/NetworkDisconnectRequest"
+      tags: ["Network"]
+  /networks/prune:
+    post:
+      summary: "Delete unused networks"
+      produces:
+        - "application/json"
+      operationId: "NetworkPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune networks created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune networks with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "NetworkPruneResponse"
+            properties:
+              NetworksDeleted:
+                description: "Networks that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Network"]
+  /plugins:
+    get:
+      summary: "List plugins"
+      operationId: "PluginList"
+      description: "Returns information about installed plugins."
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Plugin"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the plugin list.
+
+            Available filters:
+
+            - `capability=<capability name>`
+            - `enable=<true>|<false>`
+      tags: ["Plugin"]
+
+  /plugins/privileges:
+    get:
+      summary: "Get plugin privileges"
+      operationId: "GetPluginPrivileges"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags:
+        - "Plugin"
+
+  /plugins/pull:
+    post:
+      summary: "Install a plugin"
+      operationId: "PluginPull"
+      description: |
+        Pulls and installs a plugin. After the plugin is installed, it can be
+        enabled using the [`POST /plugins/{name}/enable` endpoint](#operation/PostPluginsEnable).
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference for plugin to install.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "name"
+          in: "query"
+          description: |
+            Local name for the pulled plugin.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: false
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/{name}/json:
+    get:
+      summary: "Inspect a plugin"
+      operationId: "PluginInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags: ["Plugin"]
+  /plugins/{name}:
+    delete:
+      summary: "Remove a plugin"
+      operationId: "PluginDelete"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Disable the plugin before removing. This may result in issues if the
+            plugin is in use by a container.
+          type: "boolean"
+          default: false
+      tags: ["Plugin"]
+  /plugins/{name}/enable:
+    post:
+      summary: "Enable a plugin"
+      operationId: "PluginEnable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "timeout"
+          in: "query"
+          description: "Set the HTTP client timeout (in seconds)"
+          type: "integer"
+          default: 0
+      tags: ["Plugin"]
+  /plugins/{name}/disable:
+    post:
+      summary: "Disable a plugin"
+      operationId: "PluginDisable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Force disable a plugin even if still in use.
+          required: false
+          type: "boolean"
+      tags: ["Plugin"]
+  /plugins/{name}/upgrade:
+    post:
+      summary: "Upgrade a plugin"
+      operationId: "PluginUpgrade"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference to upgrade to.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/create:
+    post:
+      summary: "Create a plugin"
+      operationId: "PluginCreate"
+      consumes:
+        - "application/x-tar"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "tarContext"
+          in: "body"
+          description: "Path to tar containing plugin rootfs and manifest"
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Plugin"]
+  /plugins/{name}/push:
+    post:
+      summary: "Push a plugin"
+      operationId: "PluginPush"
+      description: |
+        Push a plugin to the registry.
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /plugins/{name}/set:
+    post:
+      summary: "Configure a plugin"
+      operationId: "PluginSet"
+      consumes:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              type: "string"
+            example: ["DEBUG=1"]
+      responses:
+        204:
+          description: "No error"
+        404:
+          description: "Plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /nodes:
+    get:
+      summary: "List nodes"
+      operationId: "NodeList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Node"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the nodes list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `id=<node id>`
+            - `label=<engine label>`
+            - `membership=`(`accepted`|`pending`)`
+            - `name=<node name>`
+            - `node.label=<node label>`
+            - `role=`(`manager`|`worker`)`
+          type: "string"
+      tags: ["Node"]
+  /nodes/{id}:
+    get:
+      summary: "Inspect a node"
+      operationId: "NodeInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Node"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+      tags: ["Node"]
+    delete:
+      summary: "Delete a node"
+      operationId: "NodeDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Force remove a node from the swarm"
+          default: false
+          type: "boolean"
+      tags: ["Node"]
+  /nodes/{id}/update:
+    post:
+      summary: "Update a node"
+      operationId: "NodeUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID of the node"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/NodeSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the node object being updated. This is required
+            to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Node"]
+  /swarm:
+    get:
+      summary: "Inspect swarm"
+      operationId: "SwarmInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Swarm"
+        404:
+          description: "no such swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/init:
+    post:
+      summary: "Initialize a new swarm"
+      operationId: "SwarmInit"
+      produces:
+        - "application/json"
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            description: "The node ID"
+            type: "string"
+            example: "7v2t30z9blmxuhnyo6s4cpenp"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmInitRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication, as well
+                  as determining the networking interface used for the VXLAN
+                  Tunnel Endpoint (VTEP). This can either be an address/port
+                  combination in the form `192.168.1.1:4567`, or an interface
+                  followed by a port number, like `eth0:4567`. If the port number
+                  is omitted, the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other  nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+                type: "string"
+              DataPathPort:
+                description: |
+                  DataPathPort specifies the data path port number for data traffic.
+                  Acceptable port range is 1024 to 49151.
+                  if no port is set or is set to 0, default port 4789 will be used.
+                type: "integer"
+                format: "uint32"
+              DefaultAddrPool:
+                description: |
+                  Default Address Pool specifies default subnet pools for global
+                  scope networks.
+                type: "array"
+                items:
+                  type: "string"
+                  example: ["10.10.0.0/16", "20.20.0.0/16"]
+              ForceNewCluster:
+                description: "Force creation of a new swarm."
+                type: "boolean"
+              SubnetSize:
+                description: |
+                  SubnetSize specifies the subnet size of the networks created
+                  from the default subnet pool.
+                type: "integer"
+                format: "uint32"
+              Spec:
+                $ref: "#/definitions/SwarmSpec"
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathPort: 4789
+              DefaultAddrPool: ["10.10.0.0/8", "20.20.0.0/8"]
+              SubnetSize: 24
+              ForceNewCluster: false
+              Spec:
+                Orchestration: {}
+                Raft: {}
+                Dispatcher: {}
+                CAConfig: {}
+                EncryptionConfig:
+                  AutoLockManagers: false
+      tags: ["Swarm"]
+  /swarm/join:
+    post:
+      summary: "Join an existing swarm"
+      operationId: "SwarmJoin"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmJoinRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+
+                type: "string"
+              RemoteAddrs:
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
+              JoinToken:
+                description: "Secret token for joining this swarm."
+                type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathAddr: "192.168.1.1"
+              RemoteAddrs:
+                - "node1:2377"
+              JoinToken: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+      tags: ["Swarm"]
+  /swarm/leave:
+    post:
+      summary: "Leave a swarm"
+      operationId: "SwarmLeave"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "force"
+          description: |
+            Force leave swarm, even if this is the last manager or that it will
+            break the cluster.
+          in: "query"
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/update:
+    post:
+      summary: "Update a swarm"
+      operationId: "SwarmUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/SwarmSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the swarm object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+        - name: "rotateWorkerToken"
+          in: "query"
+          description: "Rotate the worker join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerToken"
+          in: "query"
+          description: "Rotate the manager join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerUnlockKey"
+          in: "query"
+          description: "Rotate the manager unlock key."
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/unlockkey:
+    get:
+      summary: "Get the unlock key"
+      operationId: "SwarmUnlockkey"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "UnlockKeyResponse"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/unlock:
+    post:
+      summary: "Unlock a locked manager"
+      operationId: "SwarmUnlock"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmUnlockRequest"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /services:
+    get:
+      summary: "List services"
+      operationId: "ServiceList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Service"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the services list.
+
+            Available filters:
+
+            - `id=<service id>`
+            - `label=<service label>`
+            - `mode=["replicated"|"global"]`
+            - `name=<service name>`
+        - name: "status"
+          in: "query"
+          type: "boolean"
+          description: |
+            Include service status, with count of running and desired tasks.
+      tags: ["Service"]
+  /services/create:
+    post:
+      summary: "Create a service"
+      operationId: "ServiceCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "network is not eligible for services"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "name conflicts with an existing service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "web"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "nginx:alpine"
+                      Mounts:
+                        -
+                          ReadOnly: true
+                          Source: "web-data"
+                          Target: "/usr/share/nginx/html"
+                          Type: "volume"
+                          VolumeOptions:
+                            DriverConfig: {}
+                            Labels:
+                              com.example.something: "something-value"
+                      Hosts: ["10.10.10.10 host1", "ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 host2"]
+                      User: "33"
+                      DNSConfig:
+                        Nameservers: ["8.8.8.8"]
+                        Search: ["example.org"]
+                        Options: ["timeout:3"]
+                      Secrets:
+                        -
+                          File:
+                            Name: "www.example.org.key"
+                            UID: "33"
+                            GID: "33"
+                            Mode: 384
+                          SecretID: "fpjqlhnwb19zds35k8wn80lq9"
+                          SecretName: "example_org_domain_key"
+                      OomScoreAdj: 0
+                    LogDriver:
+                      Name: "json-file"
+                      Options:
+                        max-file: "3"
+                        max-size: "10M"
+                    Placement: {}
+                    Resources:
+                      Limits:
+                        MemoryBytes: 104857600
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "on-failure"
+                      Delay: 10000000000
+                      MaxAttempts: 10
+                  Mode:
+                    Replicated:
+                      Replicas: 4
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Ports:
+                      -
+                        Protocol: "tcp"
+                        PublishedPort: 8080
+                        TargetPort: 80
+                  Labels:
+                    foo: "bar"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+      tags: ["Service"]
+  /services/{id}:
+    get:
+      summary: "Inspect a service"
+      operationId: "ServiceInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Service"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "insertDefaults"
+          in: "query"
+          description: "Fill empty fields with default values."
+          type: "boolean"
+          default: false
+      tags: ["Service"]
+    delete:
+      summary: "Delete a service"
+      operationId: "ServiceDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+      tags: ["Service"]
+  /services/{id}/update:
+    post:
+      summary: "Update a service"
+      operationId: "ServiceUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceUpdateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "top"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "busybox"
+                      Args:
+                        - "top"
+                      OomScoreAdj: 0
+                    Resources:
+                      Limits: {}
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "any"
+                      MaxAttempts: 0
+                    Placement: {}
+                    ForceUpdate: 0
+                  Mode:
+                    Replicated:
+                      Replicas: 1
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Mode: "vip"
+
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the service object being updated. This is
+            required to avoid conflicting writes.
+            This version number should be the value as currently set on the
+            service *before* the update. You can find the current version by
+            calling `GET /services/{id}`
+          required: true
+          type: "integer"
+        - name: "registryAuthFrom"
+          in: "query"
+          description: |
+            If the `X-Registry-Auth` header is not specified, this parameter
+            indicates where to find registry authorization credentials.
+          type: "string"
+          enum: ["spec", "previous-spec"]
+          default: "spec"
+        - name: "rollback"
+          in: "query"
+          description: |
+            Set to this parameter to `previous` to cause a server-side rollback
+            to the previous service spec. The supplied spec will be ignored in
+            this case.
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+
+      tags: ["Service"]
+  /services/{id}/logs:
+    get:
+      summary: "Get service logs"
+      description: |
+        Get `stdout` and `stderr` logs from a service. See also
+        [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ServiceLogs"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such service: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the service"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show service context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Service"]
+  /tasks:
+    get:
+      summary: "List tasks"
+      operationId: "TaskList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Task"
+            example:
+              - ID: "0kzzo1i0y4jz6027t0k7aezc7"
+                Version:
+                  Index: 71
+                CreatedAt: "2016-06-07T21:07:31.171892745Z"
+                UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:31.290032978Z"
+                  State: "running"
+                  Message: "started"
+                  ContainerStatus:
+                    ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+                    PID: 677
+                DesiredState: "running"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.10/16"
+              - ID: "1yljwbmlr8er2waf8orvqpwms"
+                Version:
+                  Index: 30
+                CreatedAt: "2016-06-07T21:07:30.019104782Z"
+                UpdatedAt: "2016-06-07T21:07:30.231958098Z"
+                Name: "hopeful_cori"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:30.202183143Z"
+                  State: "shutdown"
+                  Message: "shutdown"
+                  ContainerStatus:
+                    ContainerID: "1cf8d63d18e79668b0004a4be4c6ee58cddfad2dae29506d8781581d0688a213"
+                DesiredState: "shutdown"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.5/16"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the tasks list.
+
+            Available filters:
+
+            - `desired-state=(running | shutdown | accepted)`
+            - `id=<task id>`
+            - `label=key` or `label="key=value"`
+            - `name=<task name>`
+            - `node=<node id or name>`
+            - `service=<service name>`
+      tags: ["Task"]
+  /tasks/{id}:
+    get:
+      summary: "Inspect a task"
+      operationId: "TaskInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Task"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID of the task"
+          required: true
+          type: "string"
+      tags: ["Task"]
+  /tasks/{id}/logs:
+    get:
+      summary: "Get task logs"
+      description: |
+        Get `stdout` and `stderr` logs from a task.
+        See also [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      operationId: "TaskLogs"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such task: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID of the task"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show task context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Task"]
+  /secrets:
+    get:
+      summary: "List secrets"
+      operationId: "SecretList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Secret"
+            example:
+              - ID: "blt1owaxmitz71s9v5zh81zun"
+                Version:
+                  Index: 85
+                CreatedAt: "2017-07-20T13:55:28.678958722Z"
+                UpdatedAt: "2017-07-20T13:55:28.678958722Z"
+                Spec:
+                  Name: "mysql-passwd"
+                  Labels:
+                    some.label: "some.value"
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "app-dev.crt"
+                  Labels:
+                    foo: "bar"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the secrets list.
+
+            Available filters:
+
+            - `id=<secret id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<secret name>`
+            - `names=<secret name>`
+      tags: ["Secret"]
+  /secrets/create:
+    post:
+      summary: "Create a secret"
+      operationId: "SecretCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/SecretSpec"
+              - type: "object"
+                example:
+                  Name: "app-key.crt"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+      tags: ["Secret"]
+  /secrets/{id}:
+    get:
+      summary: "Inspect a secret"
+      operationId: "SecretInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Secret"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+                Labels:
+                  foo: "bar"
+                Driver:
+                  Name: "secret-bucket"
+                  Options:
+                    OptionA: "value for driver option A"
+                    OptionB: "value for driver option B"
+
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+    delete:
+      summary: "Delete a secret"
+      operationId: "SecretDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+  /secrets/{id}/update:
+    post:
+      summary: "Update a Secret"
+      operationId: "SecretUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such secret"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the secret"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/SecretSpec"
+          description: |
+            The spec of the secret to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [SecretInspect endpoint](#operation/SecretInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the secret object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Secret"]
+  /configs:
+    get:
+      summary: "List configs"
+      operationId: "ConfigList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Config"
+            example:
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "server.conf"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the configs list.
+
+            Available filters:
+
+            - `id=<config id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<config name>`
+            - `names=<config name>`
+      tags: ["Config"]
+  /configs/create:
+    post:
+      summary: "Create a config"
+      operationId: "ConfigCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ConfigSpec"
+              - type: "object"
+                example:
+                  Name: "server.conf"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+      tags: ["Config"]
+  /configs/{id}:
+    get:
+      summary: "Inspect a config"
+      operationId: "ConfigInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Config"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+    delete:
+      summary: "Delete a config"
+      operationId: "ConfigDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+  /configs/{id}/update:
+    post:
+      summary: "Update a Config"
+      operationId: "ConfigUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such config"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the config"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/ConfigSpec"
+          description: |
+            The spec of the config to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [ConfigInspect endpoint](#operation/ConfigInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the config object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Config"]
+  /distribution/{name}/json:
+    get:
+      summary: "Get image information from the registry"
+      description: |
+        Return image digest and platform information by contacting the registry.
+      operationId: "DistributionInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "descriptor and platform information"
+          schema:
+            $ref: "#/definitions/DistributionInspect"
+        401:
+          description: "Failed authentication or no image found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+      tags: ["Distribution"]
+  /session:
+    post:
+      summary: "Initialize interactive session"
+      description: |
+        Start a new interactive session with a server. Session allows server to
+        call back to the client for advanced capabilities.
+
+        > **Deprecated**: This endpoint is deprecated and will be removed in a future version.
+        > Server should support gRPC directly on the listening socket.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to HTTP2 transport that allows
+        the client to expose gPRC services on that connection.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /session HTTP/1.1
+        Upgrade: h2c
+        Connection: Upgrade
+        ```
+
+        The Docker daemon responds with a `101 UPGRADED` response follow with
+        the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Connection: Upgrade
+        Upgrade: h2c
+        ```
+      operationId: "Session"
+      produces:
+        - "application/vnd.docker.raw-stream"
+      responses:
+        101:
+          description: "no error, hijacking successful"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Session"]
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.55.yaml b/_vendor/github.com/moby/moby/api/docs/v1.55.yaml
new file mode 100644
index 000000000000..72cf3de4d80b
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.55.yaml
@@ -0,0 +1,13998 @@
+# A Swagger 2.0 (a.k.a. OpenAPI) definition of the Engine API.
+#
+# This is used for generating API documentation and the types used by the
+# client/server. See api/README.md for more information.
+#
+# Some style notes:
+# - This file is used by ReDoc, which allows GitHub Flavored Markdown in
+#   descriptions.
+# - There is no maximum line length, for ease of editing and pretty diffs.
+# - operationIds are in the format "NounVerb", with a singular noun.
+
+swagger: "2.0"
+schemes:
+  - "http"
+  - "https"
+produces:
+  - "application/json"
+  - "text/plain"
+consumes:
+  - "application/json"
+  - "text/plain"
+basePath: "/v1.55"
+info:
+  title: "Docker Engine API"
+  version: "1.55"
+  x-logo:
+    url: "https://docs.docker.com/assets/images/logo-docker-main.png"
+  description: |
+    The Engine API is an HTTP API served by Docker Engine. It is the API the
+    Docker client uses to communicate with the Engine, so everything the Docker
+    client can do can be done with the API.
+
+    Most of the client's commands map directly to API endpoints (e.g. `docker ps`
+    is `GET /containers/json`). The notable exception is running containers,
+    which consists of several API calls.
+
+    # Errors
+
+    The API uses standard HTTP status codes to indicate the success or failure
+    of the API call. The body of the response will be JSON in the following
+    format:
+
+    ```
+    {
+      "message": "page not found"
+    }
+    ```
+
+    # Versioning
+
+    The API is usually changed in each release, so API calls are versioned to
+    ensure that clients don't break. To lock to a specific version of the API,
+    you prefix the URL with its version, for example, call `/v1.30/info` to use
+    the v1.30 version of the `/info` endpoint. If the API version specified in
+    the URL is not supported by the daemon, a HTTP `400 Bad Request` error message
+    is returned.
+
+    If you omit the version-prefix, the current version of the API is used.
+    For example, calling `/info` is the same as calling `/v1.55/info`. Using the
+    API without a version-prefix is deprecated and will be removed in a future release.
+
+    Engine releases in the near future should support this version of the API,
+    so your client will continue to work even if it is talking to a newer Engine.
+
+    The API uses an open schema model, which means the server may add extra properties
+    to responses. Likewise, the server will ignore any extra query parameters and
+    request body properties. When you write clients, you need to ignore additional
+    properties in responses to ensure they do not break when talking to newer
+    daemons.
+
+
+    # Authentication
+
+    Authentication for registries is handled client side. The client has to send
+    authentication details to various endpoints that need to communicate with
+    registries, such as `POST /images/(name)/push`. These are sent as
+    `X-Registry-Auth` header as a [base64url encoded](https://tools.ietf.org/html/rfc4648#section-5)
+    (JSON) string with the following structure:
+
+    ```
+    {
+      "username": "string",
+      "password": "string",
+      "serveraddress": "string"
+    }
+    ```
+
+    The `serveraddress` is a domain/IP without a protocol. Throughout this
+    structure, double quotes are required.
+
+    If you have already got an identity token from the [`/auth` endpoint](#operation/SystemAuth),
+    you can just pass this instead of credentials:
+
+    ```
+    {
+      "identitytoken": "9cbaf023786cd7..."
+    }
+    ```
+
+# The tags on paths define the menu sections in the ReDoc documentation, so
+# the usage of tags must make sense for that:
+# - They should be singular, not plural.
+# - There should not be too many tags, or the menu becomes unwieldy. For
+#   example, it is preferable to add a path to the "System" tag instead of
+#   creating a tag with a single path in it.
+# - The order of tags in this list defines the order in the menu.
+tags:
+  # Primary objects
+  - name: "Container"
+    x-displayName: "Containers"
+    description: |
+      Create and manage containers.
+  - name: "Image"
+    x-displayName: "Images"
+  - name: "Network"
+    x-displayName: "Networks"
+    description: |
+      Networks are user-defined networks that containers can be attached to.
+      See the [networking documentation](https://docs.docker.com/network/)
+      for more information.
+  - name: "Volume"
+    x-displayName: "Volumes"
+    description: |
+      Create and manage persistent storage that can be attached to containers.
+  - name: "Exec"
+    x-displayName: "Exec"
+    description: |
+      Run new commands inside running containers. Refer to the
+      [command-line reference](https://docs.docker.com/engine/reference/commandline/exec/)
+      for more information.
+
+      To exec a command in a container, you first need to create an exec instance,
+      then start it. These two API endpoints are wrapped up in a single command-line
+      command, `docker exec`.
+
+  # Swarm things
+  - name: "Swarm"
+    x-displayName: "Swarm"
+    description: |
+      Engines can be clustered together in a swarm. Refer to the
+      [swarm mode documentation](https://docs.docker.com/engine/swarm/)
+      for more information.
+  - name: "Node"
+    x-displayName: "Nodes"
+    description: |
+      Nodes are instances of the Engine participating in a swarm. Swarm mode
+      must be enabled for these endpoints to work.
+  - name: "Service"
+    x-displayName: "Services"
+    description: |
+      Services are the definitions of tasks to run on a swarm. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Task"
+    x-displayName: "Tasks"
+    description: |
+      A task is a container running on a swarm. It is the atomic scheduling unit
+      of swarm. Swarm mode must be enabled for these endpoints to work.
+  - name: "Secret"
+    x-displayName: "Secrets"
+    description: |
+      Secrets are sensitive data that can be used by services. Swarm mode must
+      be enabled for these endpoints to work.
+  - name: "Config"
+    x-displayName: "Configs"
+    description: |
+      Configs are application configurations that can be used by services. Swarm
+      mode must be enabled for these endpoints to work.
+  # System things
+  - name: "Plugin"
+    x-displayName: "Plugins"
+  - name: "System"
+    x-displayName: "System"
+
+definitions:
+  ImageHistoryResponseItem:
+    type: "object"
+    x-go-name: HistoryResponseItem
+    title: "HistoryResponseItem"
+    description: "individual image layer information in response to ImageHistory operation"
+    required: [Id, Created, CreatedBy, Tags, Size, Comment]
+    properties:
+      Id:
+        type: "string"
+        x-nullable: false
+      Created:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      CreatedBy:
+        type: "string"
+        x-nullable: false
+      Tags:
+        type: "array"
+        items:
+          type: "string"
+      Size:
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Comment:
+        type: "string"
+        x-nullable: false
+  PortSummary:
+    type: "object"
+    description: |
+      Describes a port-mapping between the container and the host.
+    required: [PrivatePort, Type]
+    properties:
+      IP:
+        type: "string"
+        format: "ip-address"
+        description: "Host IP address that the container's port is mapped to"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      PrivatePort:
+        type: "integer"
+        format: "uint16"
+        x-nullable: false
+        description: "Port on the container"
+      PublicPort:
+        type: "integer"
+        format: "uint16"
+        description: "Port exposed on the host"
+      Type:
+        type: "string"
+        x-nullable: false
+        enum: ["tcp", "udp", "sctp"]
+    example:
+      PrivatePort: 8080
+      PublicPort: 80
+      Type: "tcp"
+
+  MountType:
+    description: |-
+      The mount type. Available types:
+
+      - `bind` a mount of a file or directory from the host into the container.
+      - `cluster` a Swarm cluster volume.
+      - `image` an OCI image.
+      - `npipe` a named pipe from the host into the container.
+      - `tmpfs` a `tmpfs`.
+      - `volume` a docker volume with the given `Name`.
+    type: "string"
+    enum:
+      - "bind"
+      - "cluster"
+      - "image"
+      - "npipe"
+      - "tmpfs"
+      - "volume"
+    example: "volume"
+
+  MountPoint:
+    type: "object"
+    description: |
+      MountPoint represents a mount point configuration inside the container.
+      This is used for reporting the mountpoints in use by a container.
+    properties:
+      Type:
+        description: |
+          The mount type:
+
+          - `bind` a mount of a file or directory from the host into the container.
+          - `cluster` a Swarm cluster volume.
+          - `image` an OCI image.
+          - `npipe` a named pipe from the host into the container.
+          - `tmpfs` a `tmpfs`.
+          - `volume` a docker volume with the given `Name`.
+        allOf:
+          - $ref: "#/definitions/MountType"
+        example: "volume"
+      Name:
+        description: |
+          Name is the name reference to the underlying data defined by `Source`
+          e.g., the volume name.
+        type: "string"
+        example: "myvolume"
+      Source:
+        description: |
+          Source location of the mount.
+
+          For volumes, this contains the storage location of the volume (within
+          `/var/lib/docker/volumes/`). For bind-mounts, and `npipe`, this contains
+          the source (host) part of the bind-mount. For `tmpfs` mount points, this
+          field is empty.
+        type: "string"
+        example: "/var/lib/docker/volumes/myvolume/_data"
+      Destination:
+        description: |
+          Destination is the path relative to the container root (`/`) where
+          the `Source` is mounted inside the container.
+        type: "string"
+        example: "/usr/share/nginx/html/"
+      Driver:
+        description: |
+          Driver is the volume driver used to create the volume (if it is a volume).
+        type: "string"
+        example: "local"
+      Mode:
+        description: |
+          Mode is a comma separated list of options supplied by the user when
+          creating the bind/volume mount.
+
+          The default is platform-specific (`"z"` on Linux, empty on Windows).
+        type: "string"
+        example: "z"
+      RW:
+        description: |
+          Whether the mount is mounted writable (read-write).
+        type: "boolean"
+        example: true
+      Propagation:
+        description: |
+          Propagation describes how mounts are propagated from the host into the
+          mount point, and vice-versa. Refer to the [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
+          for details. This field is not used on Windows.
+        type: "string"
+        example: ""
+
+  DeviceMapping:
+    type: "object"
+    description: "A device mapping between the host and container"
+    properties:
+      PathOnHost:
+        type: "string"
+      PathInContainer:
+        type: "string"
+      CgroupPermissions:
+        type: "string"
+    example:
+      PathOnHost: "/dev/deviceName"
+      PathInContainer: "/dev/deviceName"
+      CgroupPermissions: "mrw"
+
+  DeviceRequest:
+    type: "object"
+    description: "A request for devices to be sent to device drivers"
+    properties:
+      Driver:
+        description: |
+          The name of the device driver to use for this request.
+
+          Note that if this is specified the capabilities are ignored when
+          selecting a device driver.
+        type: "string"
+        example: "nvidia"
+      Count:
+        type: "integer"
+        example: -1
+      DeviceIDs:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "0"
+          - "1"
+          - "GPU-fef8089b-4820-abfc-e83e-94318197576e"
+      Capabilities:
+        description: |
+          A list of capabilities; an OR list of AND lists of capabilities.
+
+          Note that if a driver is specified the capabilities have no effect on
+          selecting a driver as the driver name is used directly.
+
+          Note that if no driver is specified the capabilities are used to
+          select a driver with the required capabilities.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          # gpu AND nvidia AND compute
+          - ["gpu", "nvidia", "compute"]
+      Options:
+        description: |
+          Driver-specific options, specified as a key/value pairs. These options
+          are passed directly to the driver.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  ThrottleDevice:
+    type: "object"
+    properties:
+      Path:
+        description: "Device path"
+        type: "string"
+      Rate:
+        description: "Rate"
+        type: "integer"
+        format: "int64"
+        minimum: 0
+
+  Mount:
+    type: "object"
+    properties:
+      Target:
+        description: "Container path."
+        type: "string"
+      Source:
+        description: |-
+          Mount source (e.g. a volume name, a host path). The source cannot be
+          specified when using `Type=tmpfs`. For `Type=bind`, the source path
+          must either exist, or the `CreateMountpoint` must be set to `true` to
+          create the source path on the host if missing.
+
+          For `Type=npipe`, the pipe must exist prior to creating the container.
+        type: "string"
+      Type:
+        description: |
+          The mount type. Available types:
+
+          - `bind` Mounts a file or directory from the host into the container. The `Source` must exist prior to creating the container.
+          - `cluster` a Swarm cluster volume
+          - `image` Mounts an image.
+          - `npipe` Mounts a named pipe from the host into the container. The `Source` must exist prior to creating the container.
+          - `tmpfs` Create a tmpfs with the given options. The mount `Source` cannot be specified for tmpfs.
+          - `volume` Creates a volume with the given name and options (or uses a pre-existing volume with the same name and options). These are **not** removed when the container is removed.
+        allOf:
+          - $ref: "#/definitions/MountType"
+      ReadOnly:
+        description: "Whether the mount should be read-only."
+        type: "boolean"
+      Consistency:
+        description: "The consistency requirement for the mount: `default`, `consistent`, `cached`, or `delegated`."
+        type: "string"
+      BindOptions:
+        description: "Optional configuration for the `bind` type."
+        type: "object"
+        properties:
+          Propagation:
+            description: "A propagation mode with the value `[r]private`, `[r]shared`, or `[r]slave`."
+            type: "string"
+            enum:
+              - "private"
+              - "rprivate"
+              - "shared"
+              - "rshared"
+              - "slave"
+              - "rslave"
+          NonRecursive:
+            description: "Disable recursive bind mount."
+            type: "boolean"
+            default: false
+          CreateMountpoint:
+            description: "Create mount point on host if missing"
+            type: "boolean"
+            default: false
+          ReadOnlyNonRecursive:
+            description: |
+              Make the mount non-recursively read-only, but still leave the mount recursive
+              (unless NonRecursive is set to `true` in conjunction).
+
+              Added in v1.44, before that version all read-only mounts were
+              non-recursive by default. To match the previous behaviour this
+              will default to `true` for clients on versions prior to v1.44.
+            type: "boolean"
+            default: false
+          ReadOnlyForceRecursive:
+            description: "Raise an error if the mount cannot be made recursively read-only."
+            type: "boolean"
+            default: false
+      VolumeOptions:
+        description: "Optional configuration for the `volume` type."
+        type: "object"
+        properties:
+          NoCopy:
+            description: "Populate volume with data from the target."
+            type: "boolean"
+            default: false
+          Labels:
+            description: "User-defined key/value metadata."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          DriverConfig:
+            description: "Map of driver specific options"
+            type: "object"
+            properties:
+              Name:
+                description: "Name of the driver to use to create the volume."
+                type: "string"
+              Options:
+                description: "key/value map of driver specific options."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+          Subpath:
+            description: "Source path inside the volume. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-volume/subdirectory"
+      ImageOptions:
+        description: "Optional configuration for the `image` type."
+        type: "object"
+        properties:
+          Subpath:
+            description: "Source path inside the image. Must be relative without any back traversals."
+            type: "string"
+            example: "dir-inside-image/subdirectory"
+      TmpfsOptions:
+        description: "Optional configuration for the `tmpfs` type."
+        type: "object"
+        properties:
+          SizeBytes:
+            description: "The size for the tmpfs mount in bytes."
+            type: "integer"
+            format: "int64"
+          Mode:
+            description: |
+              The permission mode for the tmpfs mount in an integer.
+              The value must not be in octal format (e.g. 755) but rather
+              the decimal representation of the octal value (e.g. 493).
+            type: "integer"
+          Options:
+            description: |
+              The options to be passed to the tmpfs mount. An array of arrays.
+              Flag options should be provided as 1-length arrays. Other types
+              should be provided as as 2-length arrays, where the first item is
+              the key and the second the value.
+            type: "array"
+            items:
+              type: "array"
+              minItems: 1
+              maxItems: 2
+              items:
+                type: "string"
+            example:
+              [["noexec"]]
+
+  RestartPolicy:
+    description: |
+      The behavior to apply when the container exits. The default is not to
+      restart.
+
+      An ever increasing delay (double the previous delay, starting at 100ms) is
+      added before each restart to prevent flooding the server.
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        description: |
+          - Empty string means not to restart
+          - `no` Do not automatically restart
+          - `always` Always restart
+          - `unless-stopped` Restart always except when the user has manually stopped the container
+          - `on-failure` Restart only when the container exit code is non-zero
+        enum:
+          - ""
+          - "no"
+          - "always"
+          - "unless-stopped"
+          - "on-failure"
+      MaximumRetryCount:
+        type: "integer"
+        description: |
+          If `on-failure` is used, the number of times to retry before giving up.
+
+  Resources:
+    description: "A container's resources (cgroups config, ulimits, etc)"
+    type: "object"
+    properties:
+      # Applicable to all platforms
+      CpuShares:
+        description: |
+          An integer value representing this container's relative CPU weight
+          versus other containers.
+        type: "integer"
+      Memory:
+        description: "Memory limit in bytes."
+        type: "integer"
+        format: "int64"
+        default: 0
+      # Applicable to UNIX platforms
+      CgroupParent:
+        description: |
+          Path to `cgroups` under which the container's `cgroup` is created. If
+          the path is not absolute, the path is considered to be relative to the
+          `cgroups` path of the init process. Cgroups are created if they do not
+          already exist.
+        type: "string"
+      BlkioWeight:
+        description: "Block IO weight (relative weight)."
+        type: "integer"
+        minimum: 0
+        maximum: 1000
+      BlkioWeightDevice:
+        description: |
+          Block IO weight (relative device weight) in the form:
+
+          ```
+          [{"Path": "device_path", "Weight": weight}]
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Path:
+              type: "string"
+            Weight:
+              type: "integer"
+              minimum: 0
+      BlkioDeviceReadBps:
+        description: |
+          Limit read rate (bytes per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteBps:
+        description: |
+          Limit write rate (bytes per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceReadIOps:
+        description: |
+          Limit read rate (IO per second) from a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      BlkioDeviceWriteIOps:
+        description: |
+          Limit write rate (IO per second) to a device, in the form:
+
+          ```
+          [{"Path": "device_path", "Rate": rate}]
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/ThrottleDevice"
+      CpuPeriod:
+        description: "The length of a CPU period in microseconds."
+        type: "integer"
+        format: "int64"
+      CpuQuota:
+        description: |
+          Microseconds of CPU time that the container can get in a CPU period.
+        type: "integer"
+        format: "int64"
+      CpuRealtimePeriod:
+        description: |
+          The length of a CPU real-time period in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpuRealtimeRuntime:
+        description: |
+          The length of a CPU real-time runtime in microseconds. Set to 0 to
+          allocate no time allocated to real-time tasks.
+        type: "integer"
+        format: "int64"
+      CpusetCpus:
+        description: |
+          CPUs in which to allow execution (e.g., `0-3`, `0,1`).
+        type: "string"
+        example: "0-3"
+      CpusetMems:
+        description: |
+          Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only
+          effective on NUMA systems.
+        type: "string"
+      Devices:
+        description: "A list of devices to add to the container."
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceMapping"
+      DeviceCgroupRules:
+        description: "a list of cgroup rules to apply to the container"
+        type: "array"
+        items:
+          type: "string"
+          example: "c 13:* rwm"
+      DeviceRequests:
+        description: |
+          A list of requests for devices to be sent to device drivers.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceRequest"
+      MemoryReservation:
+        description: "Memory soft limit in bytes."
+        type: "integer"
+        format: "int64"
+      MemorySwap:
+        description: |
+          Total memory limit (memory + swap). Set as `-1` to enable unlimited
+          swap.
+        type: "integer"
+        format: "int64"
+      MemorySwappiness:
+        description: |
+          Tune a container's memory swappiness behavior. Accepts an integer
+          between 0 and 100.
+        type: "integer"
+        format: "int64"
+        minimum: 0
+        maximum: 100
+      NanoCpus:
+        description: "CPU quota in units of 10<sup>-9</sup> CPUs."
+        type: "integer"
+        format: "int64"
+      OomKillDisable:
+        description: "Disable OOM Killer for the container."
+        type: "boolean"
+      Init:
+        description: |
+          Run an init inside the container that forwards signals and reaps
+          processes. This field is omitted if empty, and the default (as
+          configured on the daemon) is used.
+        type: "boolean"
+        x-nullable: true
+      PidsLimit:
+        description: |
+          Tune a container's PIDs limit. Set `0` or `-1` for unlimited, or `null`
+          to not change.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+      Ulimits:
+        description: |
+          A list of resource limits to set in the container. For example:
+
+          ```
+          {"Name": "nofile", "Soft": 1024, "Hard": 2048}
+          ```
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Name:
+              description: "Name of ulimit"
+              type: "string"
+            Soft:
+              description: "Soft limit"
+              type: "integer"
+            Hard:
+              description: "Hard limit"
+              type: "integer"
+      # Applicable to Windows
+      CpuCount:
+        description: |
+          The number of usable CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      CpuPercent:
+        description: |
+          The usable percentage of the available CPUs (Windows only).
+
+          On Windows Server containers, the processor resource controls are
+          mutually exclusive. The order of precedence is `CPUCount` first, then
+          `CPUShares`, and `CPUPercent` last.
+        type: "integer"
+        format: "int64"
+      IOMaximumIOps:
+        description: "Maximum IOps for the container system drive (Windows only)"
+        type: "integer"
+        format: "int64"
+      IOMaximumBandwidth:
+        description: |
+          Maximum IO in bytes per second for the container system drive
+          (Windows only).
+        type: "integer"
+        format: "int64"
+
+  Limit:
+    description: |
+      An object describing a limit on resources which can be requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      Pids:
+        description: |
+          Limits the maximum number of PIDs in the container. Set `0` for unlimited.
+        type: "integer"
+        format: "int64"
+        default: 0
+        example: 100
+
+  ResourceObject:
+    description: |
+      An object describing the resources which can be advertised by a node and
+      requested by a task.
+    type: "object"
+    properties:
+      NanoCPUs:
+        type: "integer"
+        format: "int64"
+        example: 4000000000
+      MemoryBytes:
+        type: "integer"
+        format: "int64"
+        example: 8272408576
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+
+  GenericResources:
+    description: |
+      User-defined resources can be either Integer resources (e.g, `SSD=3`) or
+      String resources (e.g, `GPU=UUID1`).
+    type: "array"
+    items:
+      type: "object"
+      properties:
+        NamedResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "string"
+        DiscreteResourceSpec:
+          type: "object"
+          properties:
+            Kind:
+              type: "string"
+            Value:
+              type: "integer"
+              format: "int64"
+    example:
+      - DiscreteResourceSpec:
+          Kind: "SSD"
+          Value: 3
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID1"
+      - NamedResourceSpec:
+          Kind: "GPU"
+          Value: "UUID2"
+
+  HealthConfig:
+    description: |
+      A test to perform to check that the container is healthy.
+      Healthcheck commands should be side-effect free.
+    type: "object"
+    properties:
+      Test:
+        description: |
+          The test to perform. Possible values are:
+
+          - `[]` inherit healthcheck from image or parent image
+          - `["NONE"]` disable healthcheck
+          - `["CMD", args...]` exec arguments directly
+          - `["CMD-SHELL", command]` run command with system's default shell
+
+          A non-zero exit code indicates a failed healthcheck:
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (treated as unhealthy)
+          - other values: error running probe
+        type: "array"
+        items:
+          type: "string"
+      Interval:
+        description: |
+          The time to wait between checks in nanoseconds. It should be 0 or at
+          least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      Timeout:
+        description: |
+          The time to wait before considering the check to have hung. It should
+          be 0 or at least 1000000 (1 ms). 0 means inherit.
+
+          If the health check command does not complete within this timeout,
+          the check is considered failed and the health check process is
+          forcibly terminated without a graceful shutdown.
+        type: "integer"
+        format: "int64"
+      Retries:
+        description: |
+          The number of consecutive failures needed to consider a container as
+          unhealthy. 0 means inherit.
+        type: "integer"
+      StartPeriod:
+        description: |
+          Start period for the container to initialize before starting
+          health-retries countdown in nanoseconds. It should be 0 or at least
+          1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+      StartInterval:
+        description: |
+          The time to wait between checks in nanoseconds during the start period.
+          It should be 0 or at least 1000000 (1 ms). 0 means inherit.
+        type: "integer"
+        format: "int64"
+
+  Health:
+    description: |
+      Health stores information about the container's healthcheck results.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          Status is one of `none`, `starting`, `healthy` or `unhealthy`
+
+          - "none"      Indicates there is no healthcheck
+          - "starting"  Starting indicates that the container is not yet ready
+          - "healthy"   Healthy indicates that the container is running correctly
+          - "unhealthy" Unhealthy indicates that the container has a problem
+        type: "string"
+        enum:
+          - "none"
+          - "starting"
+          - "healthy"
+          - "unhealthy"
+        example: "healthy"
+      FailingStreak:
+        description: "FailingStreak is the number of consecutive failures"
+        type: "integer"
+        example: 0
+      Log:
+        type: "array"
+        description: |
+          Log contains the last few results (oldest first)
+        items:
+          $ref: "#/definitions/HealthcheckResult"
+
+  HealthcheckResult:
+    description: |
+      HealthcheckResult stores information about a single run of a healthcheck probe
+    type: "object"
+    x-nullable: true
+    properties:
+      Start:
+        description: |
+          Date and time at which this check started in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2020-01-04T10:44:24.496525531Z"
+      End:
+        description: |
+          Date and time at which this check ended in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2020-01-04T10:45:21.364524523Z"
+      ExitCode:
+        description: |
+          ExitCode meanings:
+
+          - `0` healthy
+          - `1` unhealthy
+          - `2` reserved (considered unhealthy)
+          - other values: error running probe
+        type: "integer"
+        example: 0
+      Output:
+        description: "Output from last check"
+        type: "string"
+
+  HostConfig:
+    description: "Container configuration that depends on the host we are running on"
+    allOf:
+      - $ref: "#/definitions/Resources"
+      - type: "object"
+        properties:
+          # Applicable to all platforms
+          Binds:
+            type: "array"
+            description: |
+              A list of volume bindings for this container. Each volume binding
+              is a string in one of these forms:
+
+              - `host-src:container-dest[:options]` to bind-mount a host path
+                into the container. Both `host-src`, and `container-dest` must
+                be an _absolute_ path.
+              - `volume-name:container-dest[:options]` to bind-mount a volume
+                managed by a volume driver into the container. `container-dest`
+                must be an _absolute_ path.
+
+              `options` is an optional, comma-delimited list of:
+
+              - `nocopy` disables automatic copying of data from the container
+                path to the volume. The `nocopy` flag only applies to named volumes.
+              - `[ro|rw]` mounts a volume read-only or read-write, respectively.
+                If omitted or set to `rw`, volumes are mounted read-write.
+              - `[z|Z]` applies SELinux labels to allow or deny multiple containers
+                to read and write to the same volume.
+                  - `z`: a _shared_ content label is applied to the content. This
+                    label indicates that multiple containers can share the volume
+                    content, for both reading and writing.
+                  - `Z`: a _private unshared_ label is applied to the content.
+                    This label indicates that only the current container can use
+                    a private volume. Labeling systems such as SELinux require
+                    proper labels to be placed on volume content that is mounted
+                    into a container. Without a label, the security system can
+                    prevent a container's processes from using the content. By
+                    default, the labels set by the host operating system are not
+                    modified.
+              - `[[r]shared|[r]slave|[r]private]` specifies mount
+                [propagation behavior](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt).
+                This only applies to bind-mounted volumes, not internal volumes
+                or named volumes. Mount propagation requires the source mount
+                point (the location where the source directory is mounted in the
+                host operating system) to have the correct propagation properties.
+                For shared volumes, the source mount point must be set to `shared`.
+                For slave volumes, the mount must be set to either `shared` or
+                `slave`.
+            items:
+              type: "string"
+          ContainerIDFile:
+            type: "string"
+            description: "Path to a file where the container ID is written"
+            example: ""
+          LogConfig:
+            type: "object"
+            description: "The logging configuration for this container"
+            properties:
+              Type:
+                description: |-
+                  Name of the logging driver used for the container or "none"
+                  if logging is disabled.
+                type: "string"
+                enum:
+                  - "local"
+                  - "json-file"
+                  - "syslog"
+                  - "journald"
+                  - "gelf"
+                  - "fluentd"
+                  - "awslogs"
+                  - "splunk"
+                  - "etwlogs"
+                  - "none"
+              Config:
+                description: |-
+                  Driver-specific configuration options for the logging driver.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "5"
+                  "max-size": "10m"
+          NetworkMode:
+            type: "string"
+            description: |
+              Network mode to use for this container. Supported standard values
+              are: `bridge`, `host`, `none`, and `container:<name|id>`. Any
+              other value is taken as a custom network's name to which this
+              container should connect to.
+          PortBindings:
+            $ref: "#/definitions/PortMap"
+          RestartPolicy:
+            $ref: "#/definitions/RestartPolicy"
+          AutoRemove:
+            type: "boolean"
+            description: |
+              Automatically remove the container when the container's process
+              exits. This has no effect if `RestartPolicy` is set.
+          VolumeDriver:
+            type: "string"
+            description: "Driver that this container uses to mount volumes."
+          VolumesFrom:
+            type: "array"
+            description: |
+              A list of volumes to inherit from another container, specified in
+              the form `<container name>[:<ro|rw>]`.
+            items:
+              type: "string"
+          Mounts:
+            description: |
+              Specification for mounts to be added to the container.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          ConsoleSize:
+            type: "array"
+            description: |
+              Initial console size, as an `[height, width]` array.
+            x-nullable: true
+            minItems: 2
+            maxItems: 2
+            items:
+              type: "integer"
+              minimum: 0
+            example: [80, 64]
+          Annotations:
+            type: "object"
+            description: |
+              Arbitrary non-identifying metadata attached to container and
+              provided to the runtime when the container is started.
+            additionalProperties:
+              type: "string"
+
+          # Applicable to UNIX platforms
+          CapAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CapDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the container. Conflicts
+              with option 'Capabilities'.
+            items:
+              type: "string"
+          CgroupnsMode:
+            type: "string"
+            enum:
+              - "private"
+              - "host"
+            description: |
+              cgroup namespace mode for the container. Possible values are:
+
+              - `"private"`: the container runs in its own private cgroup namespace
+              - `"host"`: use the host system's cgroup namespace
+
+              If not specified, the daemon default is used, which can either be `"private"`
+              or `"host"`, depending on daemon version, kernel support and configuration.
+          Dns:
+            type: "array"
+            description: "A list of DNS servers for the container to use."
+            items:
+              type: "string"
+              format: "ip-address"
+              x-go-type:
+                type: Addr
+                import:
+                  package: net/netip
+          DnsOptions:
+            type: "array"
+            description: "A list of DNS options."
+            items:
+              type: "string"
+          DnsSearch:
+            type: "array"
+            description: "A list of DNS search domains."
+            items:
+              type: "string"
+          ExtraHosts:
+            type: "array"
+            description: |
+              A list of hostnames/IP mappings to add to the container's `/etc/hosts`
+              file. Specified in the form `["hostname:IP"]`.
+            items:
+              type: "string"
+          GroupAdd:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          IpcMode:
+            type: "string"
+            description: |
+              IPC sharing mode for the container. Possible values are:
+
+              - `"none"`: own private IPC namespace, with /dev/shm not mounted
+              - `"private"`: own private IPC namespace
+              - `"shareable"`: own private IPC namespace, with a possibility to share it with other containers
+              - `"container:<name|id>"`: join another (shareable) container's IPC namespace
+              - `"host"`: use the host system's IPC namespace
+
+              If not specified, daemon default is used, which can either be `"private"`
+              or `"shareable"`, depending on daemon version and configuration.
+          Cgroup:
+            type: "string"
+            description: "Cgroup to use for the container."
+          Links:
+            type: "array"
+            description: |
+              A list of links for the container in the form `container_name:alias`.
+            items:
+              type: "string"
+          OomScoreAdj:
+            type: "integer"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 500
+          PidMode:
+            type: "string"
+            description: |
+              Set the PID (Process) Namespace mode for the container. It can be
+              either:
+
+              - `"container:<name|id>"`: joins another container's PID namespace
+              - `"host"`: use the host's PID namespace inside the container
+          Privileged:
+            type: "boolean"
+            description: |-
+              Gives the container full access to the host.
+          PublishAllPorts:
+            type: "boolean"
+            description: |
+              Allocates an ephemeral host port for all of a container's
+              exposed ports.
+
+              Ports are de-allocated when the container stops and allocated when
+              the container starts. The allocated port might be changed when
+              restarting the container.
+
+              The port is selected from the ephemeral port range that depends on
+              the kernel. For example, on Linux the range is defined by
+              `/proc/sys/net/ipv4/ip_local_port_range`.
+          ReadonlyRootfs:
+            type: "boolean"
+            description: "Mount the container's root filesystem as read only."
+          SecurityOpt:
+            type: "array"
+            description: |
+              A list of string values to customize labels for MLS systems, such
+              as SELinux.
+            items:
+              type: "string"
+          StorageOpt:
+            type: "object"
+            description: |
+              Storage driver options for this container, in the form `{"size": "120G"}`.
+            additionalProperties:
+              type: "string"
+          Tmpfs:
+            type: "object"
+            description: |
+              A map of container directories which should be replaced by tmpfs
+              mounts, and their corresponding mount options. For example:
+
+              ```
+              { "/run": "rw,noexec,nosuid,size=65536k" }
+              ```
+            additionalProperties:
+              type: "string"
+          UTSMode:
+            type: "string"
+            description: "UTS namespace to use for the container."
+          UsernsMode:
+            type: "string"
+            description: |
+              Sets the usernamespace mode for the container when usernamespace
+              remapping option is enabled.
+          ShmSize:
+            type: "integer"
+            format: "int64"
+            description: |
+              Size of `/dev/shm` in bytes. If omitted, the system uses 64MB.
+            minimum: 0
+          Sysctls:
+            type: "object"
+            x-nullable: true
+            description: |-
+              A list of kernel parameters (sysctls) to set in the container.
+
+              This field is omitted if not set.
+            additionalProperties:
+              type: "string"
+            example:
+              "net.ipv4.ip_forward": "1"
+          Runtime:
+            type: "string"
+            x-nullable: true
+            description: |-
+              Runtime to use with this container.
+          # Applicable to Windows
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the container. (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          MaskedPaths:
+            type: "array"
+            description: |
+              The list of paths to be masked inside the container (this overrides
+              the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/asound"
+              - "/proc/acpi"
+              - "/proc/kcore"
+              - "/proc/keys"
+              - "/proc/latency_stats"
+              - "/proc/timer_list"
+              - "/proc/timer_stats"
+              - "/proc/sched_debug"
+              - "/proc/scsi"
+              - "/sys/firmware"
+              - "/sys/devices/virtual/powercap"
+          ReadonlyPaths:
+            type: "array"
+            description: |
+              The list of paths to be set as read-only inside the container
+              (this overrides the default set of paths).
+            items:
+              type: "string"
+            example:
+              - "/proc/bus"
+              - "/proc/fs"
+              - "/proc/irq"
+              - "/proc/sys"
+              - "/proc/sysrq-trigger"
+
+  ContainerConfig:
+    description: |
+      Configuration for a container that is portable between hosts.
+    type: "object"
+    properties:
+      Hostname:
+        description: |
+          The hostname to use for the container, as a valid RFC 1123 hostname.
+        type: "string"
+        example: "439f4e91bd1d"
+      Domainname:
+        description: |
+          The domain name to use for the container.
+        type: "string"
+      User:
+        description: |-
+          Commands run as this user inside the container. If omitted, commands
+          run as the user specified in the image the container was started from.
+
+          Can be either user-name or UID, and optional group-name or GID,
+          separated by a colon (`<user-name|UID>[<:group-name|GID>]`).
+        type: "string"
+        example: "123:456"
+      AttachStdin:
+        description: "Whether to attach to `stdin`."
+        type: "boolean"
+        default: false
+      AttachStdout:
+        description: "Whether to attach to `stdout`."
+        type: "boolean"
+        default: true
+      AttachStderr:
+        description: "Whether to attach to `stderr`."
+        type: "boolean"
+        default: true
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Tty:
+        description: |
+          Attach standard streams to a TTY, including `stdin` if it is not closed.
+        type: "boolean"
+        default: false
+      OpenStdin:
+        description: "Open `stdin`"
+        type: "boolean"
+        default: false
+      StdinOnce:
+        description: "Close `stdin` after one attached client disconnects"
+        type: "boolean"
+        default: false
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Image:
+        description: |
+          The name (or reference) of the image to use when creating the container,
+          or which was used when the container was created.
+        type: "string"
+        example: "example-image:1.0"
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      NetworkDisabled:
+        description: "Disable networking for the container."
+        type: "boolean"
+        x-nullable: true
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      StopTimeout:
+        description: "Timeout to stop a container in seconds."
+        type: "integer"
+        default: 10
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  ImageConfig:
+    description: |
+      Configuration of the image. These fields are used as defaults
+      when starting a container from the image.
+    type: "object"
+    properties:
+      User:
+        description: "The user that commands are run as inside the container."
+        type: "string"
+        example: "web:web"
+      ExposedPorts:
+        description: |
+          An object mapping ports to an empty object in the form:
+
+          `{"<port>/<tcp|udp|sctp>": {}}`
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example: {
+          "80/tcp": {},
+          "443/tcp": {}
+        }
+      Env:
+        description: |
+          A list of environment variables to set inside the container in the
+          form `["VAR=value", ...]`. A variable without `=` is removed from the
+          environment, rather than to have an empty value.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+      Cmd:
+        description: |
+          Command to run specified as a string or an array of strings.
+        type: "array"
+        items:
+          type: "string"
+        example: ["/bin/sh"]
+      Healthcheck:
+        $ref: "#/definitions/HealthConfig"
+      ArgsEscaped:
+        description: "Command is already escaped (Windows only)"
+        type: "boolean"
+        default: false
+        example: false
+        x-nullable: true
+      Volumes:
+        description: |
+          An object mapping mount point paths inside the container to empty
+          objects.
+        type: "object"
+        additionalProperties:
+          type: "object"
+          enum:
+            - {}
+          default: {}
+        example:
+          "/app/data": {}
+          "/app/config": {}
+      WorkingDir:
+        description: "The working directory for commands to run in."
+        type: "string"
+        example: "/public/"
+      Entrypoint:
+        description: |
+          The entry point for the container as a string or an array of strings.
+
+          If the array consists of exactly one empty string (`[""]`) then the
+          entry point is reset to system default (i.e., the entry point used by
+          docker when there is no `ENTRYPOINT` instruction in the `Dockerfile`).
+        type: "array"
+        items:
+          type: "string"
+        example: []
+      OnBuild:
+        description: |
+          `ONBUILD` metadata that were defined in the image's `Dockerfile`.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: []
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      StopSignal:
+        description: |
+          Signal to stop a container as a string or unsigned integer.
+        type: "string"
+        example: "SIGTERM"
+        x-nullable: true
+      Shell:
+        description: |
+          Shell for when `RUN`, `CMD`, and `ENTRYPOINT` uses a shell.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["/bin/sh", "-c"]
+
+  NetworkingConfig:
+    description: |
+      NetworkingConfig represents the container's networking configuration for
+      each of its interfaces.
+      It is used for the networking configs specified in the `docker create`
+      and `docker network connect` commands.
+    type: "object"
+    properties:
+      EndpointsConfig:
+        description: |
+          A mapping of network name to endpoint configuration for that network.
+          The endpoint configuration can be left empty to connect to that
+          network with no particular endpoint configuration.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+    example:
+      # putting an example here, instead of using the example values from
+      # /definitions/EndpointSettings, because EndpointSettings contains
+      # operational data returned when inspecting a container that we don't
+      # accept here.
+      EndpointsConfig:
+        isolated_nw:
+          IPAMConfig:
+            IPv4Address: "172.20.30.33"
+            IPv6Address: "2001:db8:abcd::3033"
+            LinkLocalIPs:
+              - "169.254.34.68"
+              - "fe80::3468"
+          MacAddress: "02:42:ac:12:05:02"
+          Links:
+            - "container_1"
+            - "container_2"
+          Aliases:
+            - "server_x"
+            - "server_y"
+        database_nw: {}
+
+  NetworkSettings:
+    description: "NetworkSettings exposes the network settings in the API"
+    type: "object"
+    properties:
+      SandboxID:
+        description: SandboxID uniquely represents a container's network stack.
+        type: "string"
+        example: "9d12daf2c33f5959c8bf90aa513e4f65b561738661003029ec84830cd503a0c3"
+      SandboxKey:
+        description: SandboxKey is the full path of the netns handle
+        type: "string"
+        example: "/var/run/docker/netns/8ab54b426c38"
+      Ports:
+        $ref: "#/definitions/PortMap"
+      Networks:
+        description: |
+          Information about all networks that the container is connected to.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/EndpointSettings"
+
+  Address:
+    description: Address represents an IPv4 or IPv6 IP address.
+    type: "object"
+    properties:
+      Addr:
+        description: IP address.
+        type: "string"
+      PrefixLen:
+        description: Mask length of the IP address.
+        type: "integer"
+
+  PortMap:
+    description: |
+      PortMap describes the mapping of container ports to host ports, using the
+      container's port-number and protocol as key in the format `<port>/<protocol>`,
+      for example, `80/udp`.
+
+      If a container's port is mapped for multiple protocols, separate entries
+      are added to the mapping table.
+    type: "object"
+    additionalProperties:
+      type: "array"
+      x-nullable: true
+      items:
+        $ref: "#/definitions/PortBinding"
+    example:
+      "443/tcp":
+        - HostIp: "127.0.0.1"
+          HostPort: "4443"
+      "80/tcp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+        - HostIp: "0.0.0.0"
+          HostPort: "8080"
+      "80/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "80"
+      "53/udp":
+        - HostIp: "0.0.0.0"
+          HostPort: "53"
+      "2377/tcp": null
+
+  PortBinding:
+    description: |
+      PortBinding represents a binding between a host IP address and a host
+      port.
+    type: "object"
+    properties:
+      HostIp:
+        description: "Host IP address that the container's port is mapped to."
+        type: "string"
+        example: "127.0.0.1"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      HostPort:
+        description: "Host port number that the container's port is mapped to."
+        type: "string"
+        example: "4443"
+
+  DriverData:
+    description: |
+      Information about the storage driver used to store the container's and
+      image's filesystem.
+    type: "object"
+    required: [Name, Data]
+    properties:
+      Name:
+        description: "Name of the storage driver."
+        type: "string"
+        x-nullable: false
+        example: "overlay2"
+      Data:
+        description: |
+          Low-level storage metadata, provided as key/value pairs.
+
+          This information is driver-specific, and depends on the storage-driver
+          in use, and should be used for informational purposes only.
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example: {
+          "MergedDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/merged",
+          "UpperDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/diff",
+          "WorkDir": "/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/work"
+        }
+
+  Storage:
+    description: |
+      Information about the storage used by the container.
+    type: "object"
+    properties:
+      RootFS:
+        description: |
+          Information about the storage used for the container's root filesystem.
+        type: "object"
+        x-nullable: true
+        $ref: "#/definitions/RootFSStorage"
+
+  RootFSStorage:
+    description: |
+      Information about the storage used for the container's root filesystem.
+    type: "object"
+    x-go-name: RootFSStorage
+    properties:
+      Snapshot:
+        description: |
+          Information about the snapshot used for the container's root filesystem.
+        type: "object"
+        x-nullable: true
+        $ref: "#/definitions/RootFSStorageSnapshot"
+
+  RootFSStorageSnapshot:
+    description: |
+      Information about a snapshot backend of the container's root filesystem.
+    type: "object"
+    x-go-name: RootFSStorageSnapshot
+    properties:
+      Name:
+        description: "Name of the snapshotter."
+        type: "string"
+        x-nullable: false
+
+  FilesystemChange:
+    description: |
+      Change in the container's filesystem.
+    type: "object"
+    required: [Path, Kind]
+    properties:
+      Path:
+        description: |
+          Path to file or directory that has changed.
+        type: "string"
+        x-nullable: false
+      Kind:
+        $ref: "#/definitions/ChangeType"
+
+  ChangeType:
+    description: |
+      Kind of change
+
+      Can be one of:
+
+      - `0`: Modified ("C")
+      - `1`: Added ("A")
+      - `2`: Deleted ("D")
+    type: "integer"
+    format: "uint8"
+    enum: [0, 1, 2]
+    x-nullable: false
+
+  ImageInspect:
+    description: |
+      Information about an image in the local image cache.
+    type: "object"
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+      Manifests:
+        description: |
+          Manifests is a list of image manifests available in this image. It
+          provides a more detailed view of the platform-specific image manifests or
+          other image-attached data like build attestations.
+
+          Only available if the daemon provides a multi-platform image store
+          and the `manifests` option is set in the inspect request.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        type: "array"
+        x-nullable: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      Identity:
+        description: |-
+          Identity holds information about the identity and origin of the image.
+          This is trusted information verified by the daemon and cannot be modified
+          by tagging an image to a different name.
+        x-nullable: true
+        $ref: "#/definitions/Identity"
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Comment:
+        description: |
+          Optional message that was set when committing or importing the image.
+        type: "string"
+        x-nullable: true
+        example: ""
+      Created:
+        description: |
+          Date and time at which the image was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+          This information is only available if present in the image,
+          and omitted otherwise.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2022-02-04T21:20:12.497794809Z"
+      Author:
+        description: |
+          Name of the author that was specified when committing the image, or as
+          specified through MAINTAINER (deprecated) in the Dockerfile.
+        type: "string"
+        x-nullable: true
+        example: ""
+      Config:
+        $ref: "#/definitions/ImageConfig"
+      Architecture:
+        description: |
+          Hardware CPU architecture that the image runs on.
+        type: "string"
+        x-nullable: false
+        example: "arm"
+      Variant:
+        description: |
+          CPU architecture variant (presently ARM-only).
+        type: "string"
+        x-nullable: true
+        example: "v7"
+      Os:
+        description: |
+          Operating System the image is built to run on.
+        type: "string"
+        x-nullable: false
+        example: "linux"
+      OsVersion:
+        description: |
+          Operating System version the image is built to run on (especially
+          for Windows).
+        type: "string"
+        example: ""
+        x-nullable: true
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      GraphDriver:
+        x-nullable: true
+        $ref: "#/definitions/DriverData"
+      RootFS:
+        description: |
+          Information about the image's RootFS, including the layer IDs.
+        type: "object"
+        required: [Type]
+        properties:
+          Type:
+            type: "string"
+            x-nullable: false
+            example: "layers"
+          Layers:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "sha256:1834950e52ce4d5a88a1bbd131c537f4d0e56d10ff0dd69e66be3b7dfa9df7e6"
+              - "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"
+      Metadata:
+        description: |
+          Additional metadata of the image in the local cache. This information
+          is local to the daemon, and not part of the image itself.
+        type: "object"
+        properties:
+          LastTagTime:
+            description: |
+              Date and time at which the image was last tagged in
+              [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+
+              This information is only available if the image was tagged locally,
+              and omitted otherwise.
+            type: "string"
+            format: "dateTime"
+            example: "2022-02-28T14:40:02.623929178Z"
+            x-nullable: true
+
+  Identity:
+    description: |-
+      Identity holds information about the identity and origin of the image.
+      This is trusted information verified by the daemon and cannot be modified
+      by tagging an image to a different name.
+    type: "object"
+    properties:
+      Signature:
+        description: |-
+          Signature contains the properties of verified signatures for the image.
+        type: "array"
+        items:
+          $ref: "#/definitions/SignatureIdentity"
+      Pull:
+        description: |-
+          Pull contains remote location information if image was created via pull.
+          If image was pulled via mirror, this contains the original repository location.
+          After successful push this images also contains the pushed repository location.
+        type: "array"
+        items:
+          $ref: "#/definitions/PullIdentity"
+      Build:
+        description: |-
+          Build contains build reference information if image was created via build.
+        type: "array"
+        items:
+          $ref: "#/definitions/BuildIdentity"
+
+  BuildIdentity:
+    description: |-
+      BuildIdentity contains build reference information if image was created via build.
+    type: "object"
+    properties:
+      Ref:
+        description: |-
+          Ref is the identifier for the build request. This reference can be used to
+          look up the build details in BuildKit history API.
+        type: "string"
+      CreatedAt:
+        description: |-
+          CreatedAt is the time when the build ran.
+        type: "string"
+        format: "date-time"
+
+  PullIdentity:
+    description: |-
+      PullIdentity contains remote location information if image was created via pull.
+      If image was pulled via mirror, this contains the original repository location.
+    type: "object"
+    properties:
+      Repository:
+        description: |-
+          Repository is the remote repository location the image was pulled from.
+        type: "string"
+
+  SignatureIdentity:
+    description: |-
+      SignatureIdentity contains the properties of verified signatures for the image.
+    type: "object"
+    properties:
+      Name:
+        description: |-
+          Name is a textual description summarizing the type of signature.
+        type: "string"
+      Timestamps:
+        description: |-
+          Timestamps contains a list of verified signed timestamps for the signature.
+        type: "array"
+        items:
+          $ref: "#/definitions/SignatureTimestamp"
+      KnownSigner:
+        description: |-
+          KnownSigner is an identifier for a special signer identity that is known to the implementation.
+        $ref: "#/definitions/KnownSignerIdentity"
+      DockerReference:
+        description: |-
+          DockerReference is the Docker image reference associated with the signature.
+          This is an optional field only present in older hashedrecord signatures.
+        type: "string"
+      Signer:
+        description: |-
+          Signer contains information about the signer certificate used to sign the image.
+        $ref: "#/definitions/SignerIdentity"
+      SignatureType:
+        description: |-
+          SignatureType is the type of signature format. E.g. "bundle-v0.3" or "hashedrecord".
+        $ref: "#/definitions/SignatureType"
+      Error:
+        description: |-
+          Error contains error information if signature verification failed.
+          Other fields will be empty in this case.
+        type: "string"
+      Warnings:
+        description: |-
+          Warnings contains any warnings that occurred during signature verification.
+          For example, if there was no internet connectivity and cached trust roots were used.
+          Warning does not indicate a failed verification but may point to configuration issues.
+        type: "array"
+        items:
+          type: "string"
+
+  SignatureTimestamp:
+    description: |-
+      SignatureTimestamp contains information about a verified signed timestamp for an image signature.
+    type: "object"
+    properties:
+      Type:
+        $ref: "#/definitions/SignatureTimestampType"
+      URI:
+        type: "string"
+      Timestamp:
+        type: "string"
+        format: "date-time"
+
+  SignatureTimestampType:
+    description: |-
+      SignatureTimestampType is the type of timestamp used in the signature.
+    type: "string"
+    enum:
+      - "Tlog"
+      - "TimestampAuthority"
+
+  SignatureType:
+    description: |-
+      SignatureType is the type of signature format.
+    type: "string"
+    enum:
+      - "bundle-v0.3"
+      - "simplesigning-v1"
+
+  KnownSignerIdentity:
+    description: |-
+      KnownSignerIdentity is an identifier for a special signer identity that is known to the implementation.
+    type: "string"
+    enum:
+      - "DHI"
+
+  SignerIdentity:
+    description: |-
+      SignerIdentity contains information about the signer certificate used to sign the image.
+    type: "object"
+    properties:
+      CertificateIssuer:
+        type: "string"
+        description: |-
+          CertificateIssuer is the certificate issuer.
+      SubjectAlternativeName:
+        type: "string"
+        description: |-
+          SubjectAlternativeName is the certificate subject alternative name.
+      Issuer:
+        type: "string"
+        description: |-
+          The OIDC issuer. Should match `iss` claim of ID token or, in the case of
+          a federated login like Dex it should match the issuer URL of the
+          upstream issuer. The issuer is not set the extensions are invalid and
+          will fail to render.
+      BuildSignerURI:
+        type: "string"
+        description: |-
+          Reference to specific build instructions that are responsible for signing.
+      BuildSignerDigest:
+        type: "string"
+        description: |-
+          Immutable reference to the specific version of the build instructions that is responsible for signing.
+      RunnerEnvironment:
+        type: "string"
+        description: |-
+          Specifies whether the build took place in platform-hosted cloud infrastructure or customer/self-hosted infrastructure.
+      SourceRepositoryURI:
+        type: "string"
+        description: |-
+          Source repository URL that the build was based on.
+      SourceRepositoryDigest:
+        type: "string"
+        description: |-
+          Immutable reference to a specific version of the source code that the build was based upon.
+      SourceRepositoryRef:
+        type: "string"
+        description: |-
+          Source Repository Ref that the build run was based upon.
+      SourceRepositoryIdentifier:
+        type: "string"
+        description: |-
+          Immutable identifier for the source repository the workflow was based upon.
+      SourceRepositoryOwnerURI:
+        type: "string"
+        description: |-
+          Source repository owner URL of the owner of the source repository that the build was based on.
+      SourceRepositoryOwnerIdentifier:
+        type: "string"
+        description: |-
+          Immutable identifier for the owner of the source repository that the workflow was based upon.
+      BuildConfigURI:
+        type: "string"
+        description: |-
+          Build Config URL to the top-level/initiating build instructions.
+      BuildConfigDigest:
+        type: "string"
+        description: |-
+          Immutable reference to the specific version of the top-level/initiating build instructions.
+      BuildTrigger:
+        type: "string"
+        description: |-
+          Event or action that initiated the build.
+      RunInvocationURI:
+        type: "string"
+        description: |-
+          Run Invocation URL to uniquely identify the build execution.
+      SourceRepositoryVisibilityAtSigning:
+        type: "string"
+        description: |-
+          Source repository visibility at the time of signing the certificate.
+
+  ImageSummary:
+    type: "object"
+    x-go-name: "Summary"
+    required:
+      - Id
+      - ParentId
+      - RepoTags
+      - RepoDigests
+      - Created
+      - Size
+      - SharedSize
+      - Labels
+      - Containers
+    properties:
+      Id:
+        description: |
+          ID is the content-addressable ID of an image.
+
+          This identifier is a content-addressable digest calculated from the
+          image's configuration (which includes the digests of layers used by
+          the image).
+
+          Note that this digest differs from the `RepoDigests` below, which
+          holds digests of image manifests that reference the image.
+        type: "string"
+        x-nullable: false
+        example: "sha256:ec3f0931a6e6b6855d76b2d7b0be30e81860baccd891b2e243280bf1cd8ad710"
+      ParentId:
+        description: |
+          ID of the parent image.
+
+          Depending on how the image was created, this field may be empty and
+          is only set for images that were built/created locally. This field
+          is empty if the image was pulled from an image registry.
+        type: "string"
+        x-nullable: false
+        example: ""
+      RepoTags:
+        description: |
+          List of image names/tags in the local image cache that reference this
+          image.
+
+          Multiple image tags can refer to the same image, and this list may be
+          empty if no tags reference the image, in which case the image is
+          "untagged", in which case it can still be referenced by its ID.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example:1.0"
+          - "example:latest"
+          - "example:stable"
+          - "internal.registry.example.com:5000/example:1.0"
+      RepoDigests:
+        description: |
+          List of content-addressable digests of locally available image manifests
+          that the image is referenced from. Multiple manifests can refer to the
+          same image.
+
+          These digests are usually only available if the image was either pulled
+          from a registry, or if the image was pushed to a registry, which is when
+          the manifest is generated and its digest calculated.
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example:
+          - "example@sha256:afcc7f1ac1b49db317a7196c902e61c6c3c4607d63599ee1a82d702d249a0ccb"
+          - "internal.registry.example.com:5000/example@sha256:b69959407d21e8a062e0416bf13405bb2b71ed7a84dde4158ebafacfa06f5578"
+      Created:
+        description: |
+          Date and time at which the image was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        x-nullable: false
+        example: "1644009612"
+      Size:
+        description: |
+          Total size of the image including all layers it is composed of.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 172064416
+      SharedSize:
+        description: |
+          Total size of image layers that are shared between this image and other
+          images.
+
+          This size is not calculated by default. `-1` indicates that the value
+          has not been set / calculated.
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+        example: 1239828
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Containers:
+        description: |
+          Number of containers using this image. Includes both stopped and running
+          containers.
+
+          `-1` indicates that the value has not been set / calculated.
+        x-nullable: false
+        type: "integer"
+        example: 2
+      Manifests:
+        description: |
+          Manifests is a list of manifests available in this image.
+          It provides a more detailed view of the platform-specific image manifests
+          or other image-attached data like build attestations.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        type: "array"
+        x-nullable: false
+        x-omitempty: true
+        items:
+          $ref: "#/definitions/ImageManifestSummary"
+      Descriptor:
+        description: |
+          Descriptor is an OCI descriptor of the image target.
+          In case of a multi-platform image, this descriptor points to the OCI index
+          or a manifest list.
+
+          This field is only present if the daemon provides a multi-platform image store.
+
+          WARNING: This is experimental and may change at any time without any backward
+          compatibility.
+        x-nullable: true
+        $ref: "#/definitions/OCIDescriptor"
+
+  ImagesDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/image"
+    description: |
+      represents system data usage for image resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active images.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all images.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing unused images.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by images.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of image summaries.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Summary
+
+  AuthConfig:
+    type: "object"
+    properties:
+      username:
+        type: "string"
+      password:
+        type: "string"
+      serveraddress:
+        type: "string"
+    example:
+      username: "hannibal"
+      password: "xxxx"
+      serveraddress: "https://index.docker.io/v1/"
+
+  AuthResponse:
+    description: |
+      An identity token was generated successfully.
+    type: "object"
+    required: [Status]
+    properties:
+      Status:
+        description: "The status of the authentication"
+        type: "string"
+        example: "Login Succeeded"
+        x-nullable: false
+      IdentityToken:
+        description: "An opaque token used to authenticate a user after a successful login"
+        type: "string"
+        example: "9cbaf023786cd7..."
+        x-nullable: false
+
+  ProcessConfig:
+    type: "object"
+    properties:
+      privileged:
+        type: "boolean"
+      user:
+        type: "string"
+      tty:
+        type: "boolean"
+      entrypoint:
+        type: "string"
+      arguments:
+        type: "array"
+        items:
+          type: "string"
+
+  Volume:
+    type: "object"
+    required: [Name, Driver, Mountpoint, Labels, Scope, Options]
+    x-nullable: false
+    properties:
+      Name:
+        type: "string"
+        description: "Name of the volume."
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        type: "string"
+        description: "Name of the volume driver used by the volume."
+        x-nullable: false
+        example: "custom"
+      Mountpoint:
+        type: "string"
+        description: "Mount path of the volume on the host."
+        x-nullable: false
+        example: "/var/lib/docker/volumes/tardis"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        description: "Date/Time the volume was created."
+        example: "2016-06-07T20:31:11.853781916Z"
+      Status:
+        type: "object"
+        description: |
+          Low-level details about the volume, provided by the volume driver.
+          Details are returned as a map with key/value pairs:
+          `{"key":"value","key2":"value2"}`.
+
+          The `Status` field is optional, and is omitted if the volume driver
+          does not support this feature.
+        additionalProperties:
+          type: "object"
+        example:
+          hello: "world"
+      Labels:
+        type: "object"
+        description: "User-defined key/value metadata."
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Scope:
+        type: "string"
+        description: |
+          The level at which the volume exists. Either `global` for cluster-wide,
+          or `local` for machine level.
+        default: "local"
+        x-nullable: false
+        enum: ["local", "global"]
+        example: "local"
+      ClusterVolume:
+        $ref: "#/definitions/ClusterVolume"
+      Options:
+        type: "object"
+        description: |
+          The driver specific options used when creating the volume.
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      UsageData:
+        type: "object"
+        x-nullable: true
+        x-go-name: "UsageData"
+        required: [Size, RefCount]
+        description: |
+          Usage details about the volume. This information is used by the
+          `GET /system/df` endpoint, and omitted in other endpoints.
+        properties:
+          Size:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              Amount of disk space used by the volume (in bytes). This information
+              is only available for volumes created with the `"local"` volume
+              driver. For volumes created with other volume drivers, this field
+              is set to `-1` ("not available")
+            x-nullable: false
+          RefCount:
+            type: "integer"
+            format: "int64"
+            default: -1
+            description: |
+              The number of containers referencing this volume. This field
+              is set to `-1` if the reference-count is not available.
+            x-nullable: false
+
+  VolumesDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/volume"
+    description: |
+      represents system data usage for volume resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active volumes.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all volumes.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive volumes.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by volumes.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of volumes.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Volume
+
+  VolumeCreateRequest:
+    description: "Volume configuration"
+    type: "object"
+    title: "VolumeConfig"
+    x-go-name: "CreateRequest"
+    properties:
+      Name:
+        description: |
+          The new volume's name. If not specified, Docker generates a name.
+        type: "string"
+        x-nullable: false
+        example: "tardis"
+      Driver:
+        description: "Name of the volume driver to use."
+        type: "string"
+        default: "local"
+        x-nullable: false
+        example: "custom"
+      DriverOpts:
+        description: |
+          A mapping of driver options and values. These options are
+          passed directly to the driver and are driver specific.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          device: "tmpfs"
+          o: "size=100m,uid=1000"
+          type: "tmpfs"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      ClusterVolumeSpec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+
+  VolumeListResponse:
+    type: "object"
+    title: "VolumeListResponse"
+    x-go-name: "ListResponse"
+    description: "Volume list response"
+    properties:
+      Volumes:
+        type: "array"
+        description: "List of volumes"
+        items:
+          $ref: "#/definitions/Volume"
+      Warnings:
+        type: "array"
+        description: |
+          Warnings that occurred when fetching the list of volumes.
+        items:
+          type: "string"
+        example: []
+
+  Network:
+    type: "object"
+    properties:
+      Name:
+        description: |
+          Name of the network.
+        type: "string"
+        example: "my_network"
+        x-omitempty: false
+      Id:
+        description: |
+          ID that uniquely identifies a network on a single machine.
+        type: "string"
+        x-go-name: "ID"
+        x-omitempty: false
+        example: "7d86d31b1478e7cca9ebed7e73aa0fdeec46c5ca29497431d3007d2d9e15ed99"
+      Created:
+        description: |
+          Date and time at which the network was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-omitempty: false
+        x-go-type:
+          type: Time
+          import:
+            package: time
+          hints:
+            nullable: false
+        example: "2016-10-19T04:33:30.360899459Z"
+      Scope:
+        description: |
+          The level at which the network exists (e.g. `swarm` for cluster-wide
+          or `local` for machine level)
+        type: "string"
+        x-omitempty: false
+        example: "local"
+      Driver:
+        description: |
+          The name of the driver used to create the network (e.g. `bridge`,
+          `overlay`).
+        type: "string"
+        x-omitempty: false
+        example: "overlay"
+      EnableIPv4:
+        description: |
+          Whether the network was created with IPv4 enabled.
+        type: "boolean"
+        x-omitempty: false
+        example: true
+      EnableIPv6:
+        description: |
+          Whether the network was created with IPv6 enabled.
+        type: "boolean"
+        x-omitempty: false
+        example: false
+      IPAM:
+        description: |
+          The network's IP Address Management.
+        $ref: "#/definitions/IPAM"
+        x-nullable: false
+        x-omitempty: false
+      Internal:
+        description: |
+          Whether the network is created to only allow internal networking
+          connectivity.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      Attachable:
+        description: |
+          Whether a global / swarm scope network is manually attachable by regular
+          containers from workers in swarm mode.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      Ingress:
+        description: |
+          Whether the network is providing the routing-mesh for the swarm cluster.
+        type: "boolean"
+        x-nullable: false
+        x-omitempty: false
+        default: false
+        example: false
+      ConfigFrom:
+        $ref: "#/definitions/ConfigReference"
+        x-nullable: false
+        x-omitempty: false
+      ConfigOnly:
+        description: |
+          Whether the network is a config-only network. Config-only networks are
+          placeholder networks for network configurations to be used by other
+          networks. Config-only networks cannot be used directly to run containers
+          or services.
+        type: "boolean"
+        x-omitempty: false
+        x-nullable: false
+        default: false
+      Options:
+        description: |
+          Network-specific options uses when creating the network.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.docker.network.bridge.default_bridge: "true"
+          com.docker.network.bridge.enable_icc: "true"
+          com.docker.network.bridge.enable_ip_masquerade: "true"
+          com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+          com.docker.network.bridge.name: "docker0"
+          com.docker.network.driver.mtu: "1500"
+      Labels:
+        description: |
+          Metadata specific to the network being created.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Peers:
+        description: |
+          List of peer nodes for an overlay network. This field is only present
+          for overlay networks, and omitted for other network types.
+        type: "array"
+        x-omitempty: true
+        items:
+          $ref: "#/definitions/PeerInfo"
+
+  NetworkSummary:
+    description: "Network list response item"
+    x-go-name: Summary
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/Network"
+
+  NetworkInspect:
+    description: 'The body of the "get network" http response message.'
+    x-go-name: Inspect
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/Network"
+    properties:
+      Containers:
+        description: |
+          Contains endpoints attached to the network.
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          $ref: "#/definitions/EndpointResource"
+        example:
+          19a4d5d687db25203351ed79d478946f861258f018fe384f229f2efa4b23513c:
+            Name: "test"
+            EndpointID: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+            MacAddress: "02:42:ac:13:00:02"
+            IPv4Address: "172.19.0.2/16"
+            IPv6Address: ""
+      Services:
+        description: |
+          List of services using the network. This field is only present for
+          swarm scope networks, and omitted for local scope networks.
+        type: "object"
+        x-omitempty: true
+        additionalProperties:
+          x-go-type:
+            type: ServiceInfo
+            hints:
+              nullable: false
+      Status:
+        description: >
+          provides runtime information about the network
+          such as the number of allocated IPs.
+        $ref: "#/definitions/NetworkStatus"
+
+  NetworkStatus:
+    description: >
+      provides runtime information about the network
+      such as the number of allocated IPs.
+    type: "object"
+    x-go-name: Status
+    properties:
+      IPAM:
+        $ref: "#/definitions/IPAMStatus"
+
+  ServiceInfo:
+    x-nullable: false
+    x-omitempty: false
+    description: >
+      represents service parameters with the list of service's tasks
+    type: "object"
+    properties:
+      VIP:
+        type: "string"
+        x-omitempty: false
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      Ports:
+        type: "array"
+        x-omitempty: false
+        items:
+          type: "string"
+      LocalLBIndex:
+        type: "integer"
+        format: "int"
+        x-omitempty: false
+        x-go-type:
+          type: int
+      Tasks:
+        type: "array"
+        x-omitempty: false
+        items:
+          $ref: "#/definitions/NetworkTaskInfo"
+
+  NetworkTaskInfo:
+    x-nullable: false
+    x-omitempty: false
+    x-go-name: Task
+    description: >
+      carries the information about one backend task
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+        x-omitempty: false
+      EndpointID:
+        type: "string"
+        x-omitempty: false
+      EndpointIP:
+        type: "string"
+        x-omitempty: false
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      Info:
+        type: "object"
+        x-omitempty: false
+        additionalProperties:
+          type: "string"
+
+  ConfigReference:
+    x-nullable: false
+    x-omitempty: false
+    description: |
+      The config-only network source to provide the configuration for
+      this network.
+    type: "object"
+    properties:
+      Network:
+        description: |
+          The name of the config-only network that provides the network's
+          configuration. The specified network must be an existing config-only
+          network. Only network names are allowed, not network IDs.
+        type: "string"
+        x-omitempty: false
+        example: "config_only_network_01"
+
+  IPAM:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      Driver:
+        description: "Name of the IPAM driver to use."
+        type: "string"
+        default: "default"
+        example: "default"
+      Config:
+        description: |
+          List of IPAM configuration options, specified as a map:
+
+          ```
+          {"Subnet": <CIDR>, "IPRange": <CIDR>, "Gateway": <IP address>, "AuxAddress": <device_name:IP address>}
+          ```
+        type: "array"
+        items:
+          $ref: "#/definitions/IPAMConfig"
+      Options:
+        description: "Driver-specific options, specified as a map."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+
+  IPAMConfig:
+    type: "object"
+    properties:
+      Subnet:
+        type: "string"
+        example: "172.20.0.0/16"
+      IPRange:
+        type: "string"
+        example: "172.20.10.0/24"
+      Gateway:
+        type: "string"
+        example: "172.20.10.11"
+      AuxiliaryAddresses:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  IPAMStatus:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      Subnets:
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/SubnetStatus"
+        example:
+          "172.16.0.0/16":
+            IPsInUse: 3
+            DynamicIPsAvailable: 65533
+          "2001:db8:abcd:0012::0/96":
+            IPsInUse: 5
+            DynamicIPsAvailable: 4294967291
+        x-go-type:
+          type: SubnetStatuses
+          kind: map
+
+  SubnetStatus:
+    type: "object"
+    x-nullable: false
+    x-omitempty: false
+    properties:
+      IPsInUse:
+        description: >
+          Number of IP addresses in the subnet that are in use or reserved and
+          are therefore unavailable for allocation, saturating at 2<sup>64</sup> - 1.
+        type: integer
+        format: uint64
+        x-omitempty: false
+      DynamicIPsAvailable:
+        description: >
+          Number of IP addresses within the network's IPRange for the subnet
+          that are available for allocation, saturating at 2<sup>64</sup> - 1.
+        type: integer
+        format: uint64
+        x-omitempty: false
+
+  EndpointResource:
+    type: "object"
+    description: >
+      contains network resources allocated and used for a
+      container in a network.
+    properties:
+      Name:
+        type: "string"
+        x-omitempty: false
+        example: "container_1"
+      EndpointID:
+        type: "string"
+        x-omitempty: false
+        example: "628cadb8bcb92de107b2a1e516cbffe463e321f548feb37697cce00ad694f21a"
+      MacAddress:
+        type: "string"
+        x-omitempty: false
+        example: "02:42:ac:13:00:02"
+        x-go-type:
+          type: HardwareAddr
+      IPv4Address:
+        type: "string"
+        x-omitempty: false
+        example: "172.19.0.2/16"
+        x-go-type:
+          type: Prefix
+          import:
+            package: net/netip
+      IPv6Address:
+        type: "string"
+        x-omitempty: false
+        example: ""
+        x-go-type:
+          type: Prefix
+          import:
+            package: net/netip
+
+  PeerInfo:
+    description: >
+      represents one peer of an overlay network.
+    type: "object"
+    x-nullable: false
+    properties:
+      Name:
+        description:
+          ID of the peer-node in the Swarm cluster.
+        type: "string"
+        x-omitempty: false
+        example: "6869d7c1732b"
+      IP:
+        description:
+          IP-address of the peer-node in the Swarm cluster.
+        type: "string"
+        x-omitempty: false
+        example: "10.133.77.91"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+
+  NetworkCreateResponse:
+    description: "OK response to NetworkCreate operation"
+    type: "object"
+    title: "NetworkCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warning]
+    properties:
+      Id:
+        description: "The ID of the created network."
+        type: "string"
+        x-nullable: false
+        example: "b5c4fc71e8022147cd25de22b22173de4e3b170134117172eb595cb91b4e7e5d"
+      Warning:
+        description: "Warnings encountered when creating the container"
+        type: "string"
+        x-nullable: false
+        example: ""
+
+  BuildInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      stream:
+        type: "string"
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+      aux:
+        $ref: "#/definitions/ImageID"
+
+  BuildCache:
+    type: "object"
+    description: |
+      BuildCache contains information about a build cache record.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          Unique ID of the build cache record.
+        example: "ndlpt0hhvkqcdfkputsk4cq9c"
+      Parents:
+        description: |
+          List of parent build cache record IDs.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example: ["hw53o5aio51xtltp5xjp8v7fx"]
+      Type:
+        type: "string"
+        description: |
+          Cache record type.
+        example: "regular"
+        # see https://github.com/moby/buildkit/blob/fce4a32258dc9d9664f71a4831d5de10f0670677/client/diskusage.go#L75-L84
+        enum:
+          - "internal"
+          - "frontend"
+          - "source.local"
+          - "source.git.checkout"
+          - "exec.cachemount"
+          - "regular"
+      Description:
+        type: "string"
+        description: |
+          Description of the build-step that produced the build cache.
+        example: "mount / from exec /bin/sh -c echo 'Binary::apt::APT::Keep-Downloaded-Packages \"true\";' > /etc/apt/apt.conf.d/keep-cache"
+      InUse:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is in use.
+        example: false
+      Shared:
+        type: "boolean"
+        description: |
+          Indicates if the build cache is shared.
+        example: true
+      Size:
+        description: |
+          Amount of disk space used by the build cache (in bytes).
+        type: "integer"
+        example: 51
+      CreatedAt:
+        description: |
+          Date and time at which the build cache was created in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      LastUsedAt:
+        description: |
+          Date and time at which the build cache was last used in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2017-08-09T07:09:37.632105588Z"
+      UsageCount:
+        type: "integer"
+        example: 26
+
+  BuildCacheDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/build"
+    description: |
+      represents system data usage for build cache resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active build cache records.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all build cache records.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive build cache records.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by build cache records.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of build cache records.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: CacheRecord
+
+  ImageID:
+    type: "object"
+    description: "Image ID or Digest"
+    properties:
+      ID:
+        type: "string"
+    example:
+      ID: "sha256:85f05633ddc1c50679be2b16a0479ab6f7637f8884e0cfe0f4d20e1ebb3d6e7c"
+
+  CreateImageInfo:
+    type: "object"
+    properties:
+      id:
+        type: "string"
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  PushImageInfo:
+    type: "object"
+    properties:
+      errorDetail:
+        $ref: "#/definitions/ErrorDetail"
+      status:
+        type: "string"
+      progressDetail:
+        $ref: "#/definitions/ProgressDetail"
+
+  DeviceInfo:
+    type: "object"
+    description: |
+      DeviceInfo represents a device that can be used by a container.
+    properties:
+      Source:
+        type: "string"
+        example: "cdi"
+        description: |
+          The origin device driver.
+      ID:
+        type: "string"
+        example: "vendor.com/gpu=0"
+        description: |
+          The unique identifier for the device within its source driver.
+          For CDI devices, this would be an FQDN like "vendor.com/gpu=0".
+
+  NRIInfo:
+    description: |
+      Information about the Node Resource Interface (NRI).
+
+      This field is only present if NRI is enabled.
+    type: "object"
+    x-nullable: true
+    properties:
+      Info:
+        description: |
+          Information about NRI, provided as "label" / "value" pairs.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["plugin-path", "/opt/docker/nri/plugins"]
+
+  ErrorDetail:
+    type: "object"
+    properties:
+      code:
+        type: "integer"
+      message:
+        type: "string"
+
+  ProgressDetail:
+    type: "object"
+    properties:
+      current:
+        type: "integer"
+      total:
+        type: "integer"
+
+  ErrorResponse:
+    description: "Represents an error."
+    type: "object"
+    required: ["message"]
+    properties:
+      message:
+        description: "The error message."
+        type: "string"
+        x-nullable: false
+    example:
+      message: "Something went wrong."
+
+  IDResponse:
+    description: "Response to an API call that returns just an Id"
+    type: "object"
+    x-go-name: "IDResponse"
+    required: ["Id"]
+    properties:
+      Id:
+        description: "The id of the newly created object."
+        type: "string"
+        x-nullable: false
+
+  NetworkConnectRequest:
+    description: |
+      NetworkConnectRequest represents the data to be used to connect a container to a network.
+    type: "object"
+    x-go-name: "ConnectRequest"
+    required: ["Container"]
+    properties:
+      Container:
+        type: "string"
+        description: "The ID or name of the container to connect to the network."
+        x-nullable: false
+        example: "3613f73ba0e4"
+      EndpointConfig:
+        $ref: "#/definitions/EndpointSettings"
+        x-nullable: true
+
+  NetworkDisconnectRequest:
+    description: |
+      NetworkDisconnectRequest represents the data to be used to disconnect a container from a network.
+    type: "object"
+    x-go-name: "DisconnectRequest"
+    required: ["Container"]
+    properties:
+      Container:
+        type: "string"
+        description: "The ID or name of the container to disconnect from the network."
+        x-nullable: false
+        example: "3613f73ba0e4"
+      Force:
+        type: "boolean"
+        description: "Force the container to disconnect from the network."
+        default: false
+        x-nullable: false
+        x-omitempty: false
+        example: false
+
+  EndpointSettings:
+    description: "Configuration for a network endpoint."
+    type: "object"
+    properties:
+      # Configurations
+      IPAMConfig:
+        $ref: "#/definitions/EndpointIPAMConfig"
+      Links:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "container_1"
+          - "container_2"
+      MacAddress:
+        description: |
+          MAC address for the endpoint on this network. The network driver might ignore this parameter.
+        type: "string"
+        example: "02:42:ac:11:00:04"
+        x-go-type:
+          type: HardwareAddr
+      Aliases:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "server_x"
+          - "server_y"
+      DriverOpts:
+        description: |
+          DriverOpts is a mapping of driver options and values. These options
+          are passed directly to the driver and are driver specific.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      GwPriority:
+        description: |
+          This property determines which endpoint will provide the default
+          gateway for a container. The endpoint with the highest priority will
+          be used. If multiple endpoints have the same priority, endpoints are
+          lexicographically sorted based on their network name, and the one
+          that sorts first is picked.
+        type: "integer"
+        format: "int64"
+        example:
+          - 10
+
+      # Operational data
+      NetworkID:
+        description: |
+          Unique ID of the network.
+        type: "string"
+        example: "08754567f1f40222263eab4102e1c733ae697e8e354aa9cd6e18d7402835292a"
+      EndpointID:
+        description: |
+          Unique ID for the service endpoint in a Sandbox.
+        type: "string"
+        example: "b88f5b905aabf2893f3cbc4ee42d1ea7980bbc0a92e2c8922b1e1795298afb0b"
+      Gateway:
+        description: |
+          Gateway address for this network.
+        type: "string"
+        example: "172.17.0.1"
+      IPAddress:
+        description: |
+          IPv4 address.
+        type: "string"
+        example: "172.17.0.4"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      IPPrefixLen:
+        description: |
+          Mask length of the IPv4 address.
+        type: "integer"
+        example: 16
+      IPv6Gateway:
+        description: |
+          IPv6 gateway address.
+        type: "string"
+        example: "2001:db8:2::100"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      GlobalIPv6Address:
+        description: |
+          Global IPv6 address.
+        type: "string"
+        example: "2001:db8::5689"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      GlobalIPv6PrefixLen:
+        description: |
+          Mask length of the global IPv6 address.
+        type: "integer"
+        format: "int64"
+        example: 64
+      DNSNames:
+        description: |
+          List of all DNS names an endpoint has on a specific network. This
+          list is based on the container name, network aliases, container short
+          ID, and hostname.
+
+          These DNS names are non-fully qualified but can contain several dots.
+          You can get fully qualified DNS names by appending `.<network-name>`.
+          For instance, if container name is `my.ctr` and the network is named
+          `testnet`, `DNSNames` will contain `my.ctr` and the FQDN will be
+          `my.ctr.testnet`.
+        type: array
+        items:
+          type: string
+        example: ["foobar", "server_x", "server_y", "my.ctr"]
+
+  EndpointIPAMConfig:
+    description: |
+      EndpointIPAMConfig represents an endpoint's IPAM configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      IPv4Address:
+        type: "string"
+        example: "172.20.30.33"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      IPv6Address:
+        type: "string"
+        example: "2001:db8:abcd::3033"
+        x-go-type:
+          type: Addr
+          import:
+            package: net/netip
+      LinkLocalIPs:
+        type: "array"
+        items:
+          type: "string"
+          x-go-type:
+            type: Addr
+            import:
+              package: net/netip
+        example:
+          - "169.254.34.68"
+          - "fe80::3468"
+
+  PluginMount:
+    type: "object"
+    x-go-name: "Mount"
+    x-nullable: false
+    required: [Name, Description, Settable, Source, Destination, Type, Options]
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "some-mount"
+      Description:
+        type: "string"
+        x-nullable: false
+        example: "This is a mount that's used by the plugin."
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Source:
+        type: "string"
+        example: "/var/lib/docker/plugins/"
+      Destination:
+        type: "string"
+        x-nullable: false
+        example: "/mnt/state"
+      Type:
+        type: "string"
+        x-nullable: false
+        example: "bind"
+      Options:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "rbind"
+          - "rw"
+
+  PluginDevice:
+    type: "object"
+    x-go-name: "Device"
+    required: [Name, Description, Settable, Path]
+    x-nullable: false
+    properties:
+      Name:
+        type: "string"
+        x-nullable: false
+      Description:
+        type: "string"
+        x-nullable: false
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Path:
+        type: "string"
+        example: "/dev/fuse"
+
+  PluginEnv:
+    type: "object"
+    x-go-name: "Env"
+    x-nullable: false
+    required: [Name, Description, Settable, Value]
+    properties:
+      Name:
+        x-nullable: false
+        type: "string"
+      Description:
+        x-nullable: false
+        type: "string"
+      Settable:
+        type: "array"
+        items:
+          type: "string"
+      Value:
+        type: "string"
+
+  PluginPrivilege:
+    description: |
+      Describes a permission the user has to accept upon installing
+      the plugin.
+    type: "object"
+    x-go-name: "Privilege"
+    properties:
+      Name:
+        type: "string"
+        example: "network"
+      Description:
+        type: "string"
+      Value:
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "host"
+
+  Plugin:
+    description: "A plugin for the Engine API"
+    type: "object"
+    x-go-name: "Plugin"
+    required: [Settings, Enabled, Config, Name]
+    properties:
+      Id:
+        type: "string"
+        example: "5724e2c8652da337ab2eedd19fc6fc0ec908e4bd907c7421bf6a8dfc70c4c078"
+      Name:
+        type: "string"
+        x-nullable: false
+        example: "tiborvass/sample-volume-plugin"
+      Enabled:
+        description:
+          True if the plugin is running. False if the plugin is not running,
+          only installed.
+        type: "boolean"
+        x-nullable: false
+        example: true
+      Settings:
+        description: "user-configurable settings for the plugin."
+        type: "object"
+        x-go-name: "Settings"
+        x-nullable: false
+        required: [Args, Devices, Env, Mounts]
+        properties:
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "DEBUG=0"
+          Args:
+            type: "array"
+            items:
+              type: "string"
+          Devices:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginDevice"
+      PluginReference:
+        description: "plugin remote reference used to push/pull the plugin"
+        type: "string"
+        x-go-name: "PluginReference"
+        x-nullable: false
+        example: "localhost:5000/tiborvass/sample-volume-plugin:latest"
+      Config:
+        description: "The config of a plugin."
+        type: "object"
+        x-go-name: "Config"
+        x-nullable: false
+        required:
+          - Description
+          - Documentation
+          - Interface
+          - Entrypoint
+          - WorkDir
+          - Network
+          - Linux
+          - PidHost
+          - PropagatedMount
+          - IpcHost
+          - Mounts
+          - Env
+          - Args
+        properties:
+          Description:
+            type: "string"
+            x-nullable: false
+            example: "A sample volume plugin for Docker"
+          Documentation:
+            type: "string"
+            x-nullable: false
+            example: "https://docs.docker.com/engine/extend/plugins/"
+          Interface:
+            description: "The interface between Docker and the plugin"
+            x-nullable: false
+            type: "object"
+            x-go-name: "Interface"
+            required: [Types, Socket]
+            properties:
+              Types:
+                type: "array"
+                items:
+                  type: "string"
+                  x-go-type:
+                    type: "CapabilityID"
+                example:
+                  - "docker.volumedriver/1.0"
+              Socket:
+                type: "string"
+                x-nullable: false
+                example: "plugins.sock"
+              ProtocolScheme:
+                type: "string"
+                example: "some.protocol/v1.0"
+                description: "Protocol to use for clients connecting to the plugin."
+                enum:
+                  - ""
+                  - "moby.plugins.http/v1"
+          Entrypoint:
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "/usr/bin/sample-volume-plugin"
+              - "/data"
+          WorkDir:
+            type: "string"
+            x-nullable: false
+            example: "/bin/"
+          User:
+            type: "object"
+            x-go-name: "User"
+            x-nullable: false
+            properties:
+              UID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+              GID:
+                type: "integer"
+                format: "uint32"
+                example: 1000
+          Network:
+            type: "object"
+            x-go-name: "NetworkConfig"
+            x-nullable: false
+            required: [Type]
+            properties:
+              Type:
+                x-nullable: false
+                type: "string"
+                example: "host"
+          Linux:
+            type: "object"
+            x-go-name: "LinuxConfig"
+            x-nullable: false
+            required: [Capabilities, AllowAllDevices, Devices]
+            properties:
+              Capabilities:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "CAP_SYS_ADMIN"
+                  - "CAP_SYSLOG"
+              AllowAllDevices:
+                type: "boolean"
+                x-nullable: false
+                example: false
+              Devices:
+                type: "array"
+                items:
+                  $ref: "#/definitions/PluginDevice"
+          PropagatedMount:
+            type: "string"
+            x-nullable: false
+            example: "/mnt/volumes"
+          IpcHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          PidHost:
+            type: "boolean"
+            x-nullable: false
+            example: false
+          Mounts:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginMount"
+          Env:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginEnv"
+            example:
+              - Name: "DEBUG"
+                Description: "If set, prints debug messages"
+                Settable: null
+                Value: "0"
+          Args:
+            type: "object"
+            x-go-name: "Args"
+            x-nullable: false
+            required: [Name, Description, Settable, Value]
+            properties:
+              Name:
+                x-nullable: false
+                type: "string"
+                example: "args"
+              Description:
+                x-nullable: false
+                type: "string"
+                example: "command line arguments"
+              Settable:
+                type: "array"
+                items:
+                  type: "string"
+              Value:
+                type: "array"
+                items:
+                  type: "string"
+          rootfs:
+            type: "object"
+            x-go-name: "RootFS"
+            properties:
+              type:
+                type: "string"
+                example: "layers"
+              diff_ids:
+                type: "array"
+                items:
+                  type: "string"
+                example:
+                  - "sha256:675532206fbf3030b8458f88d6e26d4eb1577688a25efec97154c94e8b6b4887"
+                  - "sha256:e216a057b1cb1efc11f8a268f37ef62083e70b1b38323ba252e25ac88904a7e8"
+
+  ObjectVersion:
+    description: |
+      The version number of the object such as node, service, etc. This is needed
+      to avoid conflicting writes. The client must send the version number along
+      with the modified specification when updating these objects.
+
+      This approach ensures safe concurrency and determinism in that the change
+      on the object may not be applied if the version number has changed from the
+      last read. In other words, if two update requests specify the same base
+      version, only one of the requests can succeed. As a result, two separate
+      update requests that happen at the same time will not unintentionally
+      overwrite each other.
+    type: "object"
+    properties:
+      Index:
+        type: "integer"
+        format: "uint64"
+        example: 373531
+
+  NodeSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "Name for the node."
+        type: "string"
+        example: "my-node"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Role:
+        description: "Role of the node."
+        type: "string"
+        enum:
+          - "worker"
+          - "manager"
+        example: "manager"
+      Availability:
+        description: "Availability of the node."
+        type: "string"
+        enum:
+          - "active"
+          - "pause"
+          - "drain"
+        example: "active"
+    example:
+      Availability: "active"
+      Name: "node-name"
+      Role: "manager"
+      Labels:
+        foo: "bar"
+
+  Node:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "24ifsmvkjbyhk"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the node was added to the swarm in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the node was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/NodeSpec"
+      Description:
+        $ref: "#/definitions/NodeDescription"
+      Status:
+        $ref: "#/definitions/NodeStatus"
+      ManagerStatus:
+        $ref: "#/definitions/ManagerStatus"
+
+  NodeDescription:
+    description: |
+      NodeDescription encapsulates the properties of the Node as reported by the
+      agent.
+    type: "object"
+    properties:
+      Hostname:
+        type: "string"
+        example: "bf3067039e47"
+      Platform:
+        $ref: "#/definitions/Platform"
+      Resources:
+        $ref: "#/definitions/ResourceObject"
+      Engine:
+        $ref: "#/definitions/EngineDescription"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+
+  Platform:
+    description: |
+      Platform represents the platform (Arch/OS).
+    type: "object"
+    properties:
+      Architecture:
+        description: |
+          Architecture represents the hardware architecture (for example,
+          `x86_64`).
+        type: "string"
+        example: "x86_64"
+      OS:
+        description: |
+          OS represents the Operating System (for example, `linux` or `windows`).
+        type: "string"
+        example: "linux"
+
+  EngineDescription:
+    description: "EngineDescription provides information about an engine."
+    type: "object"
+    properties:
+      EngineVersion:
+        type: "string"
+        example: "17.06.0"
+      Labels:
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          foo: "bar"
+      Plugins:
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Type:
+              type: "string"
+            Name:
+              type: "string"
+        example:
+          - Type: "Log"
+            Name: "awslogs"
+          - Type: "Log"
+            Name: "fluentd"
+          - Type: "Log"
+            Name: "gcplogs"
+          - Type: "Log"
+            Name: "gelf"
+          - Type: "Log"
+            Name: "journald"
+          - Type: "Log"
+            Name: "json-file"
+          - Type: "Log"
+            Name: "splunk"
+          - Type: "Log"
+            Name: "syslog"
+          - Type: "Network"
+            Name: "bridge"
+          - Type: "Network"
+            Name: "host"
+          - Type: "Network"
+            Name: "ipvlan"
+          - Type: "Network"
+            Name: "macvlan"
+          - Type: "Network"
+            Name: "null"
+          - Type: "Network"
+            Name: "overlay"
+          - Type: "Volume"
+            Name: "local"
+          - Type: "Volume"
+            Name: "localhost:5000/vieux/sshfs:latest"
+          - Type: "Volume"
+            Name: "vieux/sshfs:latest"
+
+  TLSInfo:
+    description: |
+      Information about the issuer of leaf TLS certificates and the trusted root
+      CA certificate.
+    type: "object"
+    properties:
+      TrustRoot:
+        description: |
+          The root CA certificate(s) that are used to validate leaf TLS
+          certificates.
+        type: "string"
+      CertIssuerSubject:
+        description:
+          The base64-url-safe-encoded raw subject bytes of the issuer.
+        type: "string"
+      CertIssuerPublicKey:
+        description: |
+          The base64-url-safe-encoded raw public key bytes of the issuer.
+        type: "string"
+    example:
+      TrustRoot: |
+        -----BEGIN CERTIFICATE-----
+        MIIBajCCARCgAwIBAgIUbYqrLSOSQHoxD8CwG6Bi2PJi9c8wCgYIKoZIzj0EAwIw
+        EzERMA8GA1UEAxMIc3dhcm0tY2EwHhcNMTcwNDI0MjE0MzAwWhcNMzcwNDE5MjE0
+        MzAwWjATMREwDwYDVQQDEwhzd2FybS1jYTBZMBMGByqGSM49AgEGCCqGSM49AwEH
+        A0IABJk/VyMPYdaqDXJb/VXh5n/1Yuv7iNrxV3Qb3l06XD46seovcDWs3IZNV1lf
+        3Skyr0ofcchipoiHkXBODojJydSjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB
+        Af8EBTADAQH/MB0GA1UdDgQWBBRUXxuRcnFjDfR/RIAUQab8ZV/n4jAKBggqhkjO
+        PQQDAgNIADBFAiAy+JTe6Uc3KyLCMiqGl2GyWGQqQDEcO3/YG36x7om65AIhAJvz
+        pxv6zFeVEkAEEkqIYi0omA9+CjanB/6Bz4n1uw8H
+        -----END CERTIFICATE-----
+      CertIssuerSubject: "MBMxETAPBgNVBAMTCHN3YXJtLWNh"
+      CertIssuerPublicKey: "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmT9XIw9h1qoNclv9VeHmf/Vi6/uI2vFXdBveXTpcPjqx6i9wNazchk1XWV/dKTKvSh9xyGKmiIeRcE4OiMnJ1A=="
+
+  NodeStatus:
+    description: |
+      NodeStatus represents the status of a node.
+
+      It provides the current status of the node, as seen by the manager.
+    type: "object"
+    properties:
+      State:
+        $ref: "#/definitions/NodeState"
+      Message:
+        type: "string"
+        example: ""
+      Addr:
+        description: "IP address of the node."
+        type: "string"
+        example: "172.17.0.2"
+
+  NodeState:
+    description: "NodeState represents the state of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "down"
+      - "ready"
+      - "disconnected"
+    example: "ready"
+
+  ManagerStatus:
+    description: |
+      ManagerStatus represents the status of a manager.
+
+      It provides the current status of a node's manager component, if the node
+      is a manager.
+    x-nullable: true
+    type: "object"
+    properties:
+      Leader:
+        type: "boolean"
+        default: false
+        example: true
+      Reachability:
+        $ref: "#/definitions/Reachability"
+      Addr:
+        description: |
+          The IP address and port at which the manager is reachable.
+        type: "string"
+        example: "10.0.0.46:2377"
+
+  Reachability:
+    description: "Reachability represents the reachability of a node."
+    type: "string"
+    enum:
+      - "unknown"
+      - "unreachable"
+      - "reachable"
+    example: "reachable"
+
+  SwarmSpec:
+    description: "User modifiable swarm configuration."
+    type: "object"
+    properties:
+      Name:
+        description: "Name of the swarm."
+        type: "string"
+        example: "default"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.corp.type: "production"
+          com.example.corp.department: "engineering"
+      Orchestration:
+        description: "Orchestration configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          TaskHistoryRetentionLimit:
+            description: |
+              The number of historic tasks to keep per instance or node. If
+              negative, never remove completed or failed tasks.
+            type: "integer"
+            format: "int64"
+            example: 10
+      Raft:
+        description: "Raft configuration."
+        type: "object"
+        properties:
+          SnapshotInterval:
+            description: "The number of log entries between snapshots."
+            type: "integer"
+            format: "uint64"
+            example: 10000
+          KeepOldSnapshots:
+            description: |
+              The number of snapshots to keep beyond the current snapshot.
+            type: "integer"
+            format: "uint64"
+          LogEntriesForSlowFollowers:
+            description: |
+              The number of log entries to keep around to sync up slow followers
+              after a snapshot is created.
+            type: "integer"
+            format: "uint64"
+            example: 500
+          ElectionTick:
+            description: |
+              The number of ticks that a follower will wait for a message from
+              the leader before becoming a candidate and starting an election.
+              `ElectionTick` must be greater than `HeartbeatTick`.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 3
+          HeartbeatTick:
+            description: |
+              The number of ticks between heartbeats. Every HeartbeatTick ticks,
+              the leader will send a heartbeat to the followers.
+
+              A tick currently defaults to one second, so these translate
+              directly to seconds currently, but this is NOT guaranteed.
+            type: "integer"
+            example: 1
+      Dispatcher:
+        description: "Dispatcher configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          HeartbeatPeriod:
+            description: |
+              The delay for an agent to send a heartbeat to the dispatcher.
+            type: "integer"
+            format: "int64"
+            example: 5000000000
+      CAConfig:
+        description: "CA configuration."
+        type: "object"
+        x-nullable: true
+        properties:
+          NodeCertExpiry:
+            description: "The duration node certificates are issued for."
+            type: "integer"
+            format: "int64"
+            example: 7776000000000000
+          ExternalCAs:
+            description: |
+              Configuration for forwarding signing requests to an external
+              certificate authority.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Protocol:
+                  description: |
+                    Protocol for communication with the external CA (currently
+                    only `cfssl` is supported).
+                  type: "string"
+                  enum:
+                    - "cfssl"
+                  default: "cfssl"
+                URL:
+                  description: |
+                    URL where certificate signing requests should be sent.
+                  type: "string"
+                Options:
+                  description: |
+                    An object with key/value pairs that are interpreted as
+                    protocol-specific options for the external CA driver.
+                  type: "object"
+                  additionalProperties:
+                    type: "string"
+                CACert:
+                  description: |
+                    The root CA certificate (in PEM format) this external CA uses
+                    to issue TLS certificates (assumed to be to the current swarm
+                    root CA certificate if not provided).
+                  type: "string"
+          SigningCACert:
+            description: |
+              The desired signing CA certificate for all swarm node TLS leaf
+              certificates, in PEM format.
+            type: "string"
+          SigningCAKey:
+            description: |
+              The desired signing CA key for all swarm node TLS leaf certificates,
+              in PEM format.
+            type: "string"
+          ForceRotate:
+            description: |
+              An integer whose purpose is to force swarm to generate a new
+              signing CA certificate and key, if none have been specified in
+              `SigningCACert` and `SigningCAKey`
+            format: "uint64"
+            type: "integer"
+      EncryptionConfig:
+        description: "Parameters related to encryption-at-rest."
+        type: "object"
+        properties:
+          AutoLockManagers:
+            description: |
+              If set, generate a key and use it to lock data stored on the
+              managers.
+            type: "boolean"
+            example: false
+      TaskDefaults:
+        description: "Defaults for creating tasks in this cluster."
+        type: "object"
+        properties:
+          LogDriver:
+            description: |
+              The log driver to use for tasks created in the orchestrator if
+              unspecified by a service.
+
+              Updating this value only affects new tasks. Existing tasks continue
+              to use their previously configured log driver until recreated.
+            type: "object"
+            properties:
+              Name:
+                description: |
+                  The log driver to use as a default for new tasks.
+                type: "string"
+                example: "json-file"
+              Options:
+                description: |
+                  Driver-specific options for the selected log driver, specified
+                  as key/value pairs.
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  "max-file": "10"
+                  "max-size": "100m"
+
+  # The Swarm information for `GET /info`. It is the same as `GET /swarm`, but
+  # without `JoinTokens`.
+  ClusterInfo:
+    description: |
+      ClusterInfo represents information about the swarm as is returned by the
+      "/info" endpoint. Join-tokens are not included.
+    x-nullable: true
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the swarm."
+        type: "string"
+        example: "abajmipo7b4xz5ip2nrla6b11"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        description: |
+          Date and time at which the swarm was initialised in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2016-08-18T10:44:24.496525531Z"
+      UpdatedAt:
+        description: |
+          Date and time at which the swarm was last updated in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        example: "2017-08-09T07:09:37.632105588Z"
+      Spec:
+        $ref: "#/definitions/SwarmSpec"
+      TLSInfo:
+        $ref: "#/definitions/TLSInfo"
+      RootRotationInProgress:
+        description: |
+          Whether there is currently a root CA rotation in progress for the swarm
+        type: "boolean"
+        example: false
+      DataPathPort:
+        description: |
+          DataPathPort specifies the data path port number for data traffic.
+          Acceptable port range is 1024 to 49151.
+          If no port is set or is set to 0, the default port (4789) is used.
+        type: "integer"
+        format: "uint32"
+        default: 4789
+        example: 4789
+      DefaultAddrPool:
+        description: |
+          Default Address Pool specifies default subnet pools for global scope
+          networks.
+        type: "array"
+        items:
+          type: "string"
+          format: "CIDR"
+          example: ["10.10.0.0/16", "20.20.0.0/16"]
+      SubnetSize:
+        description: |
+          SubnetSize specifies the subnet size of the networks created from the
+          default subnet pool.
+        type: "integer"
+        format: "uint32"
+        maximum: 29
+        default: 24
+        example: 24
+
+  JoinTokens:
+    description: |
+      JoinTokens contains the tokens workers and managers need to join the swarm.
+    type: "object"
+    properties:
+      Worker:
+        description: |
+          The token workers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx"
+      Manager:
+        description: |
+          The token managers can use to join the swarm.
+        type: "string"
+        example: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+
+  Swarm:
+    type: "object"
+    allOf:
+      - $ref: "#/definitions/ClusterInfo"
+      - type: "object"
+        properties:
+          JoinTokens:
+            $ref: "#/definitions/JoinTokens"
+
+  TaskSpec:
+    description: "User modifiable task configuration."
+    type: "object"
+    properties:
+      PluginSpec:
+        type: "object"
+        description: |
+          Plugin spec for the service.  *(Experimental release only.)*
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Name:
+            description: "The name or 'alias' to use for the plugin."
+            type: "string"
+          Remote:
+            description: "The plugin image reference to use."
+            type: "string"
+          Disabled:
+            description: "Disable the plugin once scheduled."
+            type: "boolean"
+          PluginPrivilege:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+      ContainerSpec:
+        type: "object"
+        description: |
+          Container spec for the service.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        properties:
+          Image:
+            description: "The image name to use for the container"
+            type: "string"
+          Labels:
+            description: "User-defined key/value data."
+            type: "object"
+            additionalProperties:
+              type: "string"
+          Command:
+            description: "The command to be run in the image."
+            type: "array"
+            items:
+              type: "string"
+          Args:
+            description: "Arguments to the command."
+            type: "array"
+            items:
+              type: "string"
+          Hostname:
+            description: |
+              The hostname to use for the container, as a valid
+              [RFC 1123](https://tools.ietf.org/html/rfc1123) hostname.
+            type: "string"
+          Env:
+            description: |
+              A list of environment variables in the form `VAR=value`.
+            type: "array"
+            items:
+              type: "string"
+          Dir:
+            description: "The working directory for commands to run in."
+            type: "string"
+          User:
+            description: "The user inside the container."
+            type: "string"
+          Groups:
+            type: "array"
+            description: |
+              A list of additional groups that the container process will run as.
+            items:
+              type: "string"
+          Privileges:
+            type: "object"
+            description: "Security options for the container"
+            properties:
+              CredentialSpec:
+                type: "object"
+                description: "CredentialSpec for managed service account (Windows only)"
+                properties:
+                  Config:
+                    type: "string"
+                    example: "0bt9dmxjvjiqermk6xrop3ekq"
+                    description: |
+                      Load credential spec from a Swarm Config with the given ID.
+                      The specified config must also be present in the Configs
+                      field with the Runtime property set.
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  File:
+                    type: "string"
+                    example: "spec.json"
+                    description: |
+                      Load credential spec from this file. The file is read by
+                      the daemon, and must be present in the `CredentialSpecs`
+                      subdirectory in the docker data directory, which defaults
+                      to `C:\ProgramData\Docker\` on Windows.
+
+                      For example, specifying `spec.json` loads
+                      `C:\ProgramData\Docker\CredentialSpecs\spec.json`.
+
+                      <p><br /></p>
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+                  Registry:
+                    type: "string"
+                    description: |
+                      Load credential spec from this value in the Windows
+                      registry. The specified registry value must be located in:
+
+                      `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs`
+
+                      <p><br /></p>
+
+
+                      > **Note**: `CredentialSpec.File`, `CredentialSpec.Registry`,
+                      > and `CredentialSpec.Config` are mutually exclusive.
+              SELinuxContext:
+                type: "object"
+                description: "SELinux labels of the container"
+                properties:
+                  Disable:
+                    type: "boolean"
+                    description: "Disable SELinux"
+                  User:
+                    type: "string"
+                    description: "SELinux user label"
+                  Role:
+                    type: "string"
+                    description: "SELinux role label"
+                  Type:
+                    type: "string"
+                    description: "SELinux type label"
+                  Level:
+                    type: "string"
+                    description: "SELinux level label"
+              Seccomp:
+                type: "object"
+                description: "Options for configuring seccomp on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "unconfined"
+                      - "custom"
+                  Profile:
+                    description: "The custom seccomp profile as a json object"
+                    type: "string"
+              AppArmor:
+                type: "object"
+                description: "Options for configuring AppArmor on the container"
+                properties:
+                  Mode:
+                    type: "string"
+                    enum:
+                      - "default"
+                      - "disabled"
+              NoNewPrivileges:
+                type: "boolean"
+                description: "Configuration of the no_new_privs bit in the container"
+
+          TTY:
+            description: "Whether a pseudo-TTY should be allocated."
+            type: "boolean"
+          OpenStdin:
+            description: "Open `stdin`"
+            type: "boolean"
+          ReadOnly:
+            description: "Mount the container's root filesystem as read only."
+            type: "boolean"
+          Mounts:
+            description: |
+              Specification for mounts to be added to containers created as part
+              of the service.
+            type: "array"
+            items:
+              $ref: "#/definitions/Mount"
+          StopSignal:
+            description: "Signal to stop the container."
+            type: "string"
+          StopGracePeriod:
+            description: |
+              Amount of time to wait for the container to terminate before
+              forcefully killing it.
+            type: "integer"
+            format: "int64"
+          HealthCheck:
+            $ref: "#/definitions/HealthConfig"
+          Hosts:
+            type: "array"
+            description: |
+              A list of hostname/IP mappings to add to the container's `hosts`
+              file. The format of extra hosts is specified in the
+              [hosts(5)](http://man7.org/linux/man-pages/man5/hosts.5.html)
+              man page:
+
+                  IP_address canonical_hostname [aliases...]
+            items:
+              type: "string"
+          DNSConfig:
+            description: |
+              Specification for DNS related configurations in resolver configuration
+              file (`resolv.conf`).
+            type: "object"
+            properties:
+              Nameservers:
+                description: "The IP addresses of the name servers."
+                type: "array"
+                items:
+                  type: "string"
+              Search:
+                description: "A search list for host-name lookup."
+                type: "array"
+                items:
+                  type: "string"
+              Options:
+                description: |
+                  A list of internal resolver variables to be modified (e.g.,
+                  `debug`, `ndots:3`, etc.).
+                type: "array"
+                items:
+                  type: "string"
+          Secrets:
+            description: |
+              Secrets contains references to zero or more secrets that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                SecretID:
+                  description: |
+                    SecretID represents the ID of the specific secret that we're
+                    referencing.
+                  type: "string"
+                SecretName:
+                  description: |
+                    SecretName is the name of the secret that this references,
+                    but this is just provided for lookup/display purposes. The
+                    secret in the reference will be identified by its ID.
+                  type: "string"
+          OomScoreAdj:
+            type: "integer"
+            format: "int64"
+            description: |
+              An integer value containing the score given to the container in
+              order to tune OOM killer preferences.
+            example: 0
+          Configs:
+            description: |
+              Configs contains references to zero or more configs that will be
+              exposed to the service.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                File:
+                  description: |
+                    File represents a specific target that is backed by a file.
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually exclusive
+                  type: "object"
+                  properties:
+                    Name:
+                      description: |
+                        Name represents the final filename in the filesystem.
+                      type: "string"
+                    UID:
+                      description: "UID represents the file UID."
+                      type: "string"
+                    GID:
+                      description: "GID represents the file GID."
+                      type: "string"
+                    Mode:
+                      description: "Mode represents the FileMode of the file."
+                      type: "integer"
+                      format: "uint32"
+                Runtime:
+                  description: |
+                    Runtime represents a target that is not mounted into the
+                    container but is used by the task
+
+                    <p><br /><p>
+
+                    > **Note**: `Configs.File` and `Configs.Runtime` are mutually
+                    > exclusive
+                  type: "object"
+                ConfigID:
+                  description: |
+                    ConfigID represents the ID of the specific config that we're
+                    referencing.
+                  type: "string"
+                ConfigName:
+                  description: |
+                    ConfigName is the name of the config that this references,
+                    but this is just provided for lookup/display purposes. The
+                    config in the reference will be identified by its ID.
+                  type: "string"
+          Isolation:
+            type: "string"
+            description: |
+              Isolation technology of the containers running the service.
+              (Windows only)
+            enum:
+              - "default"
+              - "process"
+              - "hyperv"
+              - ""
+          Init:
+            description: |
+              Run an init inside the container that forwards signals and reaps
+              processes. This field is omitted if empty, and the default (as
+              configured on the daemon) is used.
+            type: "boolean"
+            x-nullable: true
+          Sysctls:
+            description: |
+              Set kernel namedspaced parameters (sysctls) in the container.
+              The Sysctls option on services accepts the same sysctls as the
+              are supported on containers. Note that while the same sysctls are
+              supported, no guarantees or checks are made about their
+              suitability for a clustered environment, and it's up to the user
+              to determine whether a given sysctl will work properly in a
+              Service.
+            type: "object"
+            additionalProperties:
+              type: "string"
+          # This option is not used by Windows containers
+          CapabilityAdd:
+            type: "array"
+            description: |
+              A list of kernel capabilities to add to the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+              - "CAP_SYS_ADMIN"
+              - "CAP_SYS_CHROOT"
+              - "CAP_SYSLOG"
+          CapabilityDrop:
+            type: "array"
+            description: |
+              A list of kernel capabilities to drop from the default set
+              for the container.
+            items:
+              type: "string"
+            example:
+              - "CAP_NET_RAW"
+          Ulimits:
+            description: |
+              A list of resource limits to set in the container. For example: `{"Name": "nofile", "Soft": 1024, "Hard": 2048}`"
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Name:
+                  description: "Name of ulimit"
+                  type: "string"
+                Soft:
+                  description: "Soft limit"
+                  type: "integer"
+                Hard:
+                  description: "Hard limit"
+                  type: "integer"
+      NetworkAttachmentSpec:
+        description: |
+          Read-only spec type for non-swarm containers attached to swarm overlay
+          networks.
+
+          <p><br /></p>
+
+          > **Note**: ContainerSpec, NetworkAttachmentSpec, and PluginSpec are
+          > mutually exclusive. PluginSpec is only used when the Runtime field
+          > is set to `plugin`. NetworkAttachmentSpec is used when the Runtime
+          > field is set to `attachment`.
+        type: "object"
+        properties:
+          ContainerID:
+            description: "ID of the container represented by this task"
+            type: "string"
+      Resources:
+        description: |
+          Resource requirements which apply to each individual container created
+          as part of the service.
+        type: "object"
+        properties:
+          Limits:
+            description: "Define resources limits."
+            $ref: "#/definitions/Limit"
+          Reservations:
+            description: "Define resources reservation."
+            $ref: "#/definitions/ResourceObject"
+          SwapBytes:
+            description: |
+              Amount of swap in bytes - can only be used together with a memory limit.
+              If not specified, the default behaviour is to grant a swap space twice
+              as big as the memory limit.
+              Set to -1 to enable unlimited swap.
+            type: "integer"
+            format: "int64"
+            minimum: -1
+            x-nullable: true
+            x-omitempty: true
+          MemorySwappiness:
+            description: |
+              Tune the service's containers' memory swappiness (0 to 100).
+              If not specified, defaults to the containers' OS' default, generally 60,
+              or whatever value was predefined in the image.
+              Set to -1 to unset a previously set value.
+            type: "integer"
+            format: "int64"
+            minimum: -1
+            maximum: 100
+            x-nullable: true
+            x-omitempty: true
+      RestartPolicy:
+        description: |
+          Specification for the restart policy which applies to containers
+          created as part of this service.
+        type: "object"
+        properties:
+          Condition:
+            description: "Condition for restart."
+            type: "string"
+            enum:
+              - "none"
+              - "on-failure"
+              - "any"
+          Delay:
+            description: "Delay between restart attempts."
+            type: "integer"
+            format: "int64"
+          MaxAttempts:
+            description: |
+              Maximum attempts to restart a given container before giving up
+              (default value is 0, which is ignored).
+            type: "integer"
+            format: "int64"
+            default: 0
+          Window:
+            description: |
+              Windows is the time window used to evaluate the restart policy
+              (default value is 0, which is unbounded).
+            type: "integer"
+            format: "int64"
+            default: 0
+      Placement:
+        type: "object"
+        properties:
+          Constraints:
+            description: |
+              An array of constraint expressions to limit the set of nodes where
+              a task can be scheduled. Constraint expressions can either use a
+              _match_ (`==`) or _exclude_ (`!=`) rule. Multiple constraints find
+              nodes that satisfy every expression (AND match). Constraints can
+              match node or Docker Engine labels as follows:
+
+              node attribute       | matches                        | example
+              ---------------------|--------------------------------|-----------------------------------------------
+              `node.id`            | Node ID                        | `node.id==2ivku8v2gvtg4`
+              `node.hostname`      | Node hostname                  | `node.hostname!=node-2`
+              `node.role`          | Node role (`manager`/`worker`) | `node.role==manager`
+              `node.platform.os`   | Node operating system          | `node.platform.os==windows`
+              `node.platform.arch` | Node architecture              | `node.platform.arch==x86_64`
+              `node.labels`        | User-defined node labels       | `node.labels.security==high`
+              `engine.labels`      | Docker Engine's labels         | `engine.labels.operatingsystem==ubuntu-24.04`
+
+              `engine.labels` apply to Docker Engine labels like operating system,
+              drivers, etc. Swarm administrators add `node.labels` for operational
+              purposes by using the [`node update endpoint`](#operation/NodeUpdate).
+
+            type: "array"
+            items:
+              type: "string"
+            example:
+              - "node.hostname!=node3.corp.example.com"
+              - "node.role!=manager"
+              - "node.labels.type==production"
+              - "node.platform.os==linux"
+              - "node.platform.arch==x86_64"
+          Preferences:
+            description: |
+              Preferences provide a way to make the scheduler aware of factors
+              such as topology. They are provided in order from highest to
+              lowest precedence.
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                Spread:
+                  type: "object"
+                  properties:
+                    SpreadDescriptor:
+                      description: |
+                        label descriptor, such as `engine.labels.az`.
+                      type: "string"
+            example:
+              - Spread:
+                  SpreadDescriptor: "node.labels.datacenter"
+              - Spread:
+                  SpreadDescriptor: "node.labels.rack"
+          MaxReplicas:
+            description: |
+              Maximum number of replicas for per node (default value is 0, which
+              is unlimited)
+            type: "integer"
+            format: "int64"
+            default: 0
+          Platforms:
+            description: |
+              Platforms stores all the platforms that the service's image can
+              run on. This field is used in the platform filter for scheduling.
+              If empty, then the platform filter is off, meaning there are no
+              scheduling restrictions.
+            type: "array"
+            items:
+              $ref: "#/definitions/Platform"
+      ForceUpdate:
+        description: |
+          A counter that triggers an update even if no relevant parameters have
+          been changed.
+        type: "integer"
+        format: "uint64"
+      Runtime:
+        description: |
+          Runtime is the type of runtime specified for the task executor.
+        type: "string"
+      Networks:
+        description: "Specifies which networks the service should attach to."
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+      LogDriver:
+        description: |
+          Specifies the log driver to use for tasks created from this spec. If
+          not present, the default one for the swarm will be used, finally
+          falling back to the engine default if not specified.
+        type: "object"
+        properties:
+          Name:
+            type: "string"
+          Options:
+            type: "object"
+            additionalProperties:
+              type: "string"
+
+  TaskState:
+    type: "string"
+    enum:
+      - "new"
+      - "allocated"
+      - "pending"
+      - "assigned"
+      - "accepted"
+      - "preparing"
+      - "ready"
+      - "starting"
+      - "running"
+      - "complete"
+      - "shutdown"
+      - "failed"
+      - "rejected"
+      - "remove"
+      - "orphaned"
+
+  ContainerStatus:
+    type: "object"
+    description: "represents the status of a container."
+    properties:
+      ContainerID:
+        type: "string"
+      PID:
+        type: "integer"
+      ExitCode:
+        type: "integer"
+
+  PortStatus:
+    type: "object"
+    description: "represents the port status of a task's host ports whose service has published host ports"
+    properties:
+      Ports:
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  TaskStatus:
+    type: "object"
+    description: "represents the status of a task."
+    properties:
+      Timestamp:
+        type: "string"
+        format: "dateTime"
+      State:
+        $ref: "#/definitions/TaskState"
+      Message:
+        type: "string"
+      Err:
+        type: "string"
+      ContainerStatus:
+        $ref: "#/definitions/ContainerStatus"
+      PortStatus:
+        $ref: "#/definitions/PortStatus"
+
+  Task:
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the task."
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Name:
+        description: "Name of the task."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Spec:
+        $ref: "#/definitions/TaskSpec"
+      ServiceID:
+        description: "The ID of the service this task is part of."
+        type: "string"
+      Slot:
+        type: "integer"
+      NodeID:
+        description: "The ID of the node that this task is on."
+        type: "string"
+      AssignedGenericResources:
+        $ref: "#/definitions/GenericResources"
+      Status:
+        $ref: "#/definitions/TaskStatus"
+      DesiredState:
+        $ref: "#/definitions/TaskState"
+      JobIteration:
+        description: |
+          If the Service this Task belongs to is a job-mode service, contains
+          the JobIteration of the Service this Task was created for. Absent if
+          the Task was created for a Replicated or Global Service.
+        $ref: "#/definitions/ObjectVersion"
+    example:
+      ID: "0kzzo1i0y4jz6027t0k7aezc7"
+      Version:
+        Index: 71
+      CreatedAt: "2016-06-07T21:07:31.171892745Z"
+      UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+      Spec:
+        ContainerSpec:
+          Image: "redis"
+        Resources:
+          Limits: {}
+          Reservations: {}
+        RestartPolicy:
+          Condition: "any"
+          MaxAttempts: 0
+        Placement: {}
+      ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Slot: 1
+      NodeID: "60gvrl6tm78dmak4yl7srz94v"
+      Status:
+        Timestamp: "2016-06-07T21:07:31.290032978Z"
+        State: "running"
+        Message: "started"
+        ContainerStatus:
+          ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+          PID: 677
+      DesiredState: "running"
+      NetworksAttachments:
+        - Network:
+            ID: "4qvuz4ko70xaltuqbt8956gd1"
+            Version:
+              Index: 18
+            CreatedAt: "2016-06-07T20:31:11.912919752Z"
+            UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+            Spec:
+              Name: "ingress"
+              Labels:
+                com.docker.swarm.internal: "true"
+              DriverConfiguration: {}
+              IPAMOptions:
+                Driver: {}
+                Configs:
+                  - Subnet: "10.255.0.0/16"
+                    Gateway: "10.255.0.1"
+            DriverState:
+              Name: "overlay"
+              Options:
+                com.docker.network.driver.overlay.vxlanid_list: "256"
+            IPAMOptions:
+              Driver:
+                Name: "default"
+              Configs:
+                - Subnet: "10.255.0.0/16"
+                  Gateway: "10.255.0.1"
+          Addresses:
+            - "10.255.0.10/16"
+      AssignedGenericResources:
+        - DiscreteResourceSpec:
+            Kind: "SSD"
+            Value: 3
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID1"
+        - NamedResourceSpec:
+            Kind: "GPU"
+            Value: "UUID2"
+
+  ServiceSpec:
+    description: "User modifiable configuration for a service."
+    type: object
+    properties:
+      Name:
+        description: "Name of the service."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      TaskTemplate:
+        $ref: "#/definitions/TaskSpec"
+      Mode:
+        description: "Scheduling mode for the service."
+        type: "object"
+        properties:
+          Replicated:
+            type: "object"
+            properties:
+              Replicas:
+                type: "integer"
+                format: "int64"
+          Global:
+            type: "object"
+          ReplicatedJob:
+            description: |
+              The mode used for services with a finite number of tasks that run
+              to a completed state.
+            type: "object"
+            properties:
+              MaxConcurrent:
+                description: |
+                  The maximum number of replicas to run simultaneously.
+                type: "integer"
+                format: "int64"
+                default: 1
+              TotalCompletions:
+                description: |
+                  The total number of replicas desired to reach the Completed
+                  state. If unset, will default to the value of `MaxConcurrent`
+                type: "integer"
+                format: "int64"
+          GlobalJob:
+            description: |
+              The mode used for services which run a task to the completed state
+              on each valid node.
+            type: "object"
+      UpdateConfig:
+        description: "Specification for the update strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be updated in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: "Amount of time between updates, in nanoseconds."
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an updated task fails to run, or stops running
+              during the update.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+              - "rollback"
+          Monitor:
+            description: |
+              Amount of time to monitor each updated task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during an update before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling out an updated task. Either
+              the old task is shut down before the new task is started, or the
+              new task is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      RollbackConfig:
+        description: "Specification for the rollback strategy of the service."
+        type: "object"
+        properties:
+          Parallelism:
+            description: |
+              Maximum number of tasks to be rolled back in one iteration (0 means
+              unlimited parallelism).
+            type: "integer"
+            format: "int64"
+          Delay:
+            description: |
+              Amount of time between rollback iterations, in nanoseconds.
+            type: "integer"
+            format: "int64"
+          FailureAction:
+            description: |
+              Action to take if an rolled back task fails to run, or stops
+              running during the rollback.
+            type: "string"
+            enum:
+              - "continue"
+              - "pause"
+          Monitor:
+            description: |
+              Amount of time to monitor each rolled back task for failures, in
+              nanoseconds.
+            type: "integer"
+            format: "int64"
+          MaxFailureRatio:
+            description: |
+              The fraction of tasks that may fail during a rollback before the
+              failure action is invoked, specified as a floating point number
+              between 0 and 1.
+            type: "number"
+            default: 0
+          Order:
+            description: |
+              The order of operations when rolling back a task. Either the old
+              task is shut down before the new task is started, or the new task
+              is started before the old task is shut down.
+            type: "string"
+            enum:
+              - "stop-first"
+              - "start-first"
+      Networks:
+        description: |
+          Specifies which networks the service should attach to.
+
+          Deprecated: This field is deprecated since v1.44. The Networks field in TaskSpec should be used instead.
+        type: "array"
+        items:
+          $ref: "#/definitions/NetworkAttachmentConfig"
+
+      EndpointSpec:
+        $ref: "#/definitions/EndpointSpec"
+
+  EndpointPortConfig:
+    type: "object"
+    properties:
+      Name:
+        type: "string"
+      Protocol:
+        type: "string"
+        enum:
+          - "tcp"
+          - "udp"
+          - "sctp"
+      TargetPort:
+        description: "The port inside the container."
+        type: "integer"
+      PublishedPort:
+        description: "The port on the swarm hosts."
+        type: "integer"
+      PublishMode:
+        description: |
+          The mode in which port is published.
+
+          <p><br /></p>
+
+          - "ingress" makes the target port accessible on every node,
+            regardless of whether there is a task for the service running on
+            that node or not.
+          - "host" bypasses the routing mesh and publish the port directly on
+            the swarm node where that service is running.
+
+        type: "string"
+        enum:
+          - "ingress"
+          - "host"
+        default: "ingress"
+        example: "ingress"
+
+  EndpointSpec:
+    description: "Properties that can be configured to access and load balance a service."
+    type: "object"
+    properties:
+      Mode:
+        description: |
+          The mode of resolution to use for internal load balancing between tasks.
+        type: "string"
+        enum:
+          - "vip"
+          - "dnsrr"
+        default: "vip"
+      Ports:
+        description: |
+          List of exposed ports that this service is accessible on from the
+          outside. Ports can only be provided if `vip` resolution mode is used.
+        type: "array"
+        items:
+          $ref: "#/definitions/EndpointPortConfig"
+
+  Service:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ServiceSpec"
+      Endpoint:
+        type: "object"
+        properties:
+          Spec:
+            $ref: "#/definitions/EndpointSpec"
+          Ports:
+            type: "array"
+            items:
+              $ref: "#/definitions/EndpointPortConfig"
+          VirtualIPs:
+            type: "array"
+            items:
+              type: "object"
+              properties:
+                NetworkID:
+                  type: "string"
+                Addr:
+                  type: "string"
+      UpdateStatus:
+        description: "The status of a service update."
+        type: "object"
+        properties:
+          State:
+            type: "string"
+            enum:
+              - "updating"
+              - "paused"
+              - "completed"
+          StartedAt:
+            type: "string"
+            format: "dateTime"
+          CompletedAt:
+            type: "string"
+            format: "dateTime"
+          Message:
+            type: "string"
+      ServiceStatus:
+        description: |
+          The status of the service's tasks. Provided only when requested as
+          part of a ServiceList operation.
+        type: "object"
+        properties:
+          RunningTasks:
+            description: |
+              The number of tasks for the service currently in the Running state.
+            type: "integer"
+            format: "uint64"
+            example: 7
+          DesiredTasks:
+            description: |
+              The number of tasks for the service desired to be running.
+              For replicated services, this is the replica count from the
+              service spec. For global services, this is computed by taking
+              count of all tasks for the service with a Desired State other
+              than Shutdown.
+            type: "integer"
+            format: "uint64"
+            example: 10
+          CompletedTasks:
+            description: |
+              The number of tasks for a job that are in the Completed state.
+              This field must be cross-referenced with the service type, as the
+              value of 0 may mean the service is not in a job mode, or it may
+              mean the job-mode service has no tasks yet Completed.
+            type: "integer"
+            format: "uint64"
+      JobStatus:
+        description: |
+          The status of the service when it is in one of ReplicatedJob or
+          GlobalJob modes. Absent on Replicated and Global mode services. The
+          JobIteration is an ObjectVersion, but unlike the Service's version,
+          does not need to be sent with an update request.
+        type: "object"
+        properties:
+          JobIteration:
+            description: |
+              JobIteration is a value increased each time a Job is executed,
+              successfully or otherwise. "Executed", in this case, means the
+              job as a whole has been started, not that an individual Task has
+              been launched. A job is "Executed" when its ServiceSpec is
+              updated. JobIteration can be used to disambiguate Tasks belonging
+              to different executions of a job.  Though JobIteration will
+              increase with each subsequent execution, it may not necessarily
+              increase by 1, and so JobIteration should not be used to
+            $ref: "#/definitions/ObjectVersion"
+          LastExecution:
+            description: |
+              The last time, as observed by the server, that this job was
+              started.
+            type: "string"
+            format: "dateTime"
+    example:
+      ID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+      Version:
+        Index: 19
+      CreatedAt: "2016-06-07T21:05:51.880065305Z"
+      UpdatedAt: "2016-06-07T21:07:29.962229872Z"
+      Spec:
+        Name: "hopeful_cori"
+        TaskTemplate:
+          ContainerSpec:
+            Image: "redis"
+          Resources:
+            Limits: {}
+            Reservations: {}
+          RestartPolicy:
+            Condition: "any"
+            MaxAttempts: 0
+          Placement: {}
+          ForceUpdate: 0
+        Mode:
+          Replicated:
+            Replicas: 1
+        UpdateConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        RollbackConfig:
+          Parallelism: 1
+          Delay: 1000000000
+          FailureAction: "pause"
+          Monitor: 15000000000
+          MaxFailureRatio: 0.15
+        EndpointSpec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+      Endpoint:
+        Spec:
+          Mode: "vip"
+          Ports:
+            -
+              Protocol: "tcp"
+              TargetPort: 6379
+              PublishedPort: 30001
+        Ports:
+          -
+            Protocol: "tcp"
+            TargetPort: 6379
+            PublishedPort: 30001
+        VirtualIPs:
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.2/16"
+          -
+            NetworkID: "4qvuz4ko70xaltuqbt8956gd1"
+            Addr: "10.255.0.3/16"
+
+  ImageDeleteResponseItem:
+    type: "object"
+    x-go-name: "DeleteResponse"
+    properties:
+      Untagged:
+        description: "The image ID of an image that was untagged"
+        type: "string"
+      Deleted:
+        description: "The image ID of an image that was deleted"
+        type: "string"
+
+  ServiceCreateResponse:
+    type: "object"
+    description: |
+      contains the information returned to a client on the
+      creation of a new service.
+    properties:
+      ID:
+        description: "The ID of the created service."
+        type: "string"
+        x-nullable: false
+        example: "ak7w3gjqoa3kuz8xcpnyy0pvl"
+      Warnings:
+        description: |
+          Optional warning message.
+
+          FIXME(thaJeztah): this should have "omitempty" in the generated type.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example:
+          - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ServiceUpdateResponse:
+    type: "object"
+    properties:
+      Warnings:
+        description: "Optional warning messages"
+        type: "array"
+        items:
+          type: "string"
+    example:
+      Warnings:
+        - "unable to pin image doesnotexist:latest to digest: image library/doesnotexist:latest not found"
+
+  ContainerInspectResponse:
+    type: "object"
+    title: "ContainerInspectResponse"
+    x-go-name: "InspectResponse"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Created:
+        description: |-
+          Date and time at which the container was created, formatted in
+          [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format with nano-seconds.
+        type: "string"
+        format: "dateTime"
+        x-nullable: true
+        example: "2025-02-17T17:43:39.64001363Z"
+      Path:
+        description: |-
+          The path to the command being run
+        type: "string"
+        example: "/bin/sh"
+      Args:
+        description: "The arguments to the command being run"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "-c"
+          - "exit 9"
+      State:
+        $ref: "#/definitions/ContainerState"
+      Image:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ResolvConfPath:
+        description: |-
+          Location of the `/etc/resolv.conf` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/resolv.conf"
+      HostnamePath:
+        description: |-
+          Location of the `/etc/hostname` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hostname"
+      HostsPath:
+        description: |-
+          Location of the `/etc/hosts` generated for the container on the
+          host.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        example: "/var/lib/docker/containers/aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf/hosts"
+      LogPath:
+        description: |-
+          Location of the file used to buffer the container's logs. Depending on
+          the logging-driver used for the container, this field may be omitted.
+
+          This file is managed through the docker daemon, and should not be
+          accessed or modified by other tools.
+        type: "string"
+        x-nullable: true
+        example: "/var/lib/docker/containers/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59/5b7c7e2b992aa426584ce6c47452756066be0e503a08b4516a433a54d2f69e59-json.log"
+      Name:
+        description: |-
+          The name associated with this container.
+
+          For historic reasons, the name may be prefixed with a forward-slash (`/`).
+        type: "string"
+        example: "/funny_chatelet"
+      RestartCount:
+        description: |-
+          Number of times the container was restarted since it was created,
+          or since daemon was started.
+        type: "integer"
+        example: 0
+      Driver:
+        description: |-
+          The storage-driver used for the container's filesystem (graph-driver
+          or snapshotter).
+        type: "string"
+        example: "overlayfs"
+      Platform:
+        description: |-
+          The platform (operating system) for which the container was created.
+
+          This field was introduced for the experimental "LCOW" (Linux Containers
+          On Windows) features, which has been removed. In most cases, this field
+          is equal to the host's operating system (`linux` or `windows`).
+        type: "string"
+        example: "linux"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        description: |-
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+      MountLabel:
+        description: |-
+          SELinux mount label set for the container.
+        type: "string"
+        example: ""
+      ProcessLabel:
+        description: |-
+          SELinux process label set for the container.
+        type: "string"
+        example: ""
+      AppArmorProfile:
+        description: |-
+          The AppArmor profile set for the container.
+        type: "string"
+        example: ""
+      ExecIDs:
+        description: |-
+          IDs of exec instances that are running in the container.
+        type: "array"
+        items:
+          type: "string"
+        x-nullable: true
+        example:
+          - "b35395de42bc8abd327f9dd65d913b9ba28c74d2f0734eeeae84fa1c616a0fca"
+          - "3fc1232e5cd20c8de182ed81178503dc6437f4e7ef12b52cc5e8de020652f1c4"
+      HostConfig:
+        $ref: "#/definitions/HostConfig"
+      GraphDriver:
+        $ref: "#/definitions/DriverData"
+        x-nullable: true
+      Storage:
+        $ref: "#/definitions/Storage"
+        x-nullable: true
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Mounts:
+        description: |-
+          List of mounts used by the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/MountPoint"
+      Config:
+        $ref: "#/definitions/ContainerConfig"
+      NetworkSettings:
+        $ref: "#/definitions/NetworkSettings"
+
+  ContainerSummary:
+    type: "object"
+    properties:
+      Id:
+        description: |-
+          The ID of this container as a 128-bit (64-character) hexadecimal string (32 bytes).
+        type: "string"
+        x-go-name: "ID"
+        minLength: 64
+        maxLength: 64
+        pattern: "^[0-9a-fA-F]{64}$"
+        example: "aa86eacfb3b3ed4cd362c1e88fc89a53908ad05fb3a4103bca3f9b28292d14bf"
+      Names:
+        description: |-
+          The names associated with this container. Most containers have a single
+          name, but when using legacy "links", the container can have multiple
+          names.
+
+          For historic reasons, names are prefixed with a forward-slash (`/`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/funny_chatelet"
+      Image:
+        description: |-
+          The name or ID of the image used to create the container.
+
+          This field shows the image reference as was specified when creating the container,
+          which can be in its canonical form (e.g., `docker.io/library/ubuntu:latest`
+          or `docker.io/library/ubuntu@sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`),
+          short form (e.g., `ubuntu:latest`)), or the ID(-prefix) of the image (e.g., `72297848456d`).
+
+          The content of this field can be updated at runtime if the image used to
+          create the container is untagged, in which case the field is updated to
+          contain the the image ID (digest) it was resolved to in its canonical,
+          non-truncated form (e.g., `sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782`).
+        type: "string"
+        example: "docker.io/library/ubuntu:latest"
+      ImageID:
+        description: |-
+          The ID (digest) of the image that this container was created from.
+        type: "string"
+        example: "sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
+      ImageManifestDescriptor:
+        $ref: "#/definitions/OCIDescriptor"
+        x-nullable: true
+        description: |
+          OCI descriptor of the platform-specific manifest of the image
+          the container was created from.
+
+          Note: Only available if the daemon provides a multi-platform
+          image store.
+
+          This field is not populated in the `GET /system/df` endpoint.
+      Command:
+        description: "Command to run when starting the container"
+        type: "string"
+        example: "/bin/bash"
+      Created:
+        description: |-
+          Date and time at which the container was created as a Unix timestamp
+          (number of seconds since EPOCH).
+        type: "integer"
+        format: "int64"
+        example: "1739811096"
+      Ports:
+        description: |-
+          Port-mappings for the container.
+        type: "array"
+        items:
+          $ref: "#/definitions/PortSummary"
+      SizeRw:
+        description: |-
+          The size of files that have been created or changed by this container.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "122880"
+      SizeRootFs:
+        description: |-
+          The total size of all files in the read-only layers from the image
+          that the container uses. These layers can be shared between containers.
+
+          This field is omitted by default, and only set when size is requested
+          in the API request.
+        type: "integer"
+        format: "int64"
+        x-nullable: true
+        example: "1653948416"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.vendor: "Acme"
+          com.example.license: "GPL"
+          com.example.version: "1.0"
+      State:
+        description: |
+          The state of this container.
+        type: "string"
+        enum:
+          - "created"
+          - "running"
+          - "paused"
+          - "restarting"
+          - "exited"
+          - "removing"
+          - "dead"
+        example: "running"
+      Status:
+        description: |-
+          Additional human-readable status of this container (e.g. `Exit 0`)
+        type: "string"
+        example: "Up 4 days"
+      HostConfig:
+        type: "object"
+        description: |-
+          Summary of host-specific runtime information of the container. This
+          is a reduced set of information in the container's "HostConfig" as
+          available in the container "inspect" response.
+        properties:
+          NetworkMode:
+            description: |-
+              Networking mode (`host`, `none`, `container:<id>`) or name of the
+              primary network the container is using.
+
+              This field is primarily for backward compatibility. The container
+              can be connected to multiple networks for which information can be
+              found in the `NetworkSettings.Networks` field, which enumerates
+              settings per network.
+            type: "string"
+            example: "mynetwork"
+          Annotations:
+            description: |-
+              Arbitrary key-value metadata attached to the container.
+            type: "object"
+            x-nullable: true
+            additionalProperties:
+              type: "string"
+            example:
+              io.kubernetes.docker.type: "container"
+              io.kubernetes.sandbox.id: "3befe639bed0fd6afdd65fd1fa84506756f59360ec4adc270b0fdac9be22b4d3"
+      NetworkSettings:
+        description: |-
+          Summary of the container's network settings
+        type: "object"
+        properties:
+          Networks:
+            type: "object"
+            description: |-
+              Summary of network-settings for each network the container is
+              attached to.
+            additionalProperties:
+              $ref: "#/definitions/EndpointSettings"
+      Mounts:
+        type: "array"
+        description: |-
+          List of mounts used by the container.
+        items:
+          $ref: "#/definitions/MountPoint"
+      Health:
+        type: "object"
+        description: |-
+          Summary of health status
+
+          Added in v1.52, before that version all container summary not include Health.
+          After this attribute introduced, it includes containers with no health checks configured,
+          or containers that are not running with none
+        properties:
+          Status:
+            type: "string"
+            description: |-
+              the health status of the container
+            enum:
+              - "none"
+              - "starting"
+              - "healthy"
+              - "unhealthy"
+            example: "healthy"
+          FailingStreak:
+            description: "FailingStreak is the number of consecutive failures"
+            type: "integer"
+            example: 0
+
+  ContainersDiskUsage:
+    type: "object"
+    x-go-name: "DiskUsage"
+    x-go-package: "github.com/moby/moby/api/types/container"
+    description: |
+      represents system data usage information for container resources.
+    properties:
+      ActiveCount:
+        description: |
+          Count of active containers.
+        type: "integer"
+        format: "int64"
+        example: 1
+      TotalCount:
+        description: |
+          Count of all containers.
+        type: "integer"
+        format: "int64"
+        example: 4
+      Reclaimable:
+        description: |
+          Disk space that can be reclaimed by removing inactive containers.
+        type: "integer"
+        format: "int64"
+        example: 12345678
+      TotalSize:
+        description: |
+          Disk space in use by containers.
+        type: "integer"
+        format: "int64"
+        example: 98765432
+      Items:
+        description: |
+          List of container summaries.
+        type: "array"
+        x-omitempty: true
+        items:
+          x-go-type:
+            type: Summary
+
+  Driver:
+    description: "Driver represents a driver (network, logging, secrets)."
+    type: "object"
+    required: [Name]
+    properties:
+      Name:
+        description: "Name of the driver."
+        type: "string"
+        x-nullable: false
+        example: "some-driver"
+      Options:
+        description: "Key/value map of driver-specific options."
+        type: "object"
+        x-nullable: false
+        additionalProperties:
+          type: "string"
+        example:
+          OptionA: "value for driver-specific option A"
+          OptionB: "value for driver-specific option B"
+
+  SecretSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the secret."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-value"
+          com.example.some-other-label: "some-other-value"
+      Data:
+        description: |
+          Data is the data to store as a secret, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          It must be empty if the Driver field is set, in which case the data is
+          loaded from an external secret store. The maximum allowed size is 500KB,
+          as defined in [MaxSecretSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0/api/validation#MaxSecretSize).
+
+          This field is only used to _create_ a secret, and is not returned by
+          other endpoints.
+        type: "string"
+        example: ""
+      Driver:
+        description: |
+          Name of the secrets driver used to fetch the secret's value from an
+          external secret store.
+        $ref: "#/definitions/Driver"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Secret:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+        example: "blt1owaxmitz71s9v5zh81zun"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+        example: "2017-07-20T13:55:28.678958722Z"
+      Spec:
+        $ref: "#/definitions/SecretSpec"
+
+  ConfigSpec:
+    type: "object"
+    properties:
+      Name:
+        description: "User-defined name of the config."
+        type: "string"
+      Labels:
+        description: "User-defined key/value metadata."
+        type: "object"
+        additionalProperties:
+          type: "string"
+      Data:
+        description: |
+          Data is the data to store as a config, formatted as a standard base64-encoded
+          ([RFC 4648](https://tools.ietf.org/html/rfc4648#section-4)) string.
+          The maximum allowed size is 1000KB, as defined in [MaxConfigSize](https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize).
+        type: "string"
+      Templating:
+        description: |
+          Templating driver, if applicable
+
+          Templating controls whether and how to evaluate the config payload as
+          a template. If no driver is set, no templating is used.
+        $ref: "#/definitions/Driver"
+
+  Config:
+    type: "object"
+    properties:
+      ID:
+        type: "string"
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ConfigSpec"
+
+  ContainerState:
+    description: |
+      ContainerState stores container's running state. It's part of ContainerJSONBase
+      and will be returned by the "inspect" command.
+    type: "object"
+    x-nullable: true
+    properties:
+      Status:
+        description: |
+          String representation of the container state. Can be one of "created",
+          "running", "paused", "restarting", "removing", "exited", or "dead".
+        type: "string"
+        enum: ["created", "running", "paused", "restarting", "removing", "exited", "dead"]
+        example: "running"
+      Running:
+        description: |
+          Whether this container is running.
+
+          Note that a running container can be _paused_. The `Running` and `Paused`
+          booleans are not mutually exclusive:
+
+          When pausing a container (on Linux), the freezer cgroup is used to suspend
+          all processes in the container. Freezing the process requires the process to
+          be running. As a result, paused containers are both `Running` _and_ `Paused`.
+
+          Use the `Status` field instead to determine if a container's state is "running".
+        type: "boolean"
+        example: true
+      Paused:
+        description: "Whether this container is paused."
+        type: "boolean"
+        example: false
+      Restarting:
+        description: "Whether this container is restarting."
+        type: "boolean"
+        example: false
+      OOMKilled:
+        description: |
+          Whether a process within this container has been killed because it ran
+          out of memory since the container was last started.
+        type: "boolean"
+        example: false
+      Dead:
+        type: "boolean"
+        example: false
+      Pid:
+        description: "The process ID of this container"
+        type: "integer"
+        example: 1234
+      ExitCode:
+        description: "The last exit code of this container"
+        type: "integer"
+        example: 0
+      Error:
+        type: "string"
+      StartedAt:
+        description: "The time when this container was last started."
+        type: "string"
+        example: "2020-01-06T09:06:59.461876391Z"
+      FinishedAt:
+        description: "The time when this container last exited."
+        type: "string"
+        example: "2020-01-06T09:07:59.461876391Z"
+      Health:
+        $ref: "#/definitions/Health"
+
+  ContainerCreateResponse:
+    description: "OK response to ContainerCreate operation"
+    type: "object"
+    title: "ContainerCreateResponse"
+    x-go-name: "CreateResponse"
+    required: [Id, Warnings]
+    properties:
+      Id:
+        description: "The ID of the created container"
+        type: "string"
+        x-nullable: false
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Warnings:
+        description: "Warnings encountered when creating the container"
+        type: "array"
+        x-nullable: false
+        items:
+          type: "string"
+        example: []
+
+  ContainerUpdateResponse:
+    type: "object"
+    title: "ContainerUpdateResponse"
+    x-go-name: "UpdateResponse"
+    description: |-
+      Response for a successful container-update.
+    properties:
+      Warnings:
+        type: "array"
+        description: |-
+          Warnings encountered when updating the container.
+        items:
+          type: "string"
+        example: ["Published ports are discarded when using host network mode"]
+
+  ContainerStatsResponse:
+    description: |
+      Statistics sample for a container.
+    type: "object"
+    x-go-name: "StatsResponse"
+    title: "ContainerStatsResponse"
+    properties:
+      id:
+        description: |
+          ID of the container for which the stats were collected.
+        type: "string"
+        x-nullable: true
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      name:
+        description: |
+          Name of the container for which the stats were collected.
+        type: "string"
+        x-nullable: true
+        example: "boring_wozniak"
+      os_type:
+        description: |
+          OSType is the OS of the container ("linux" or "windows") to allow
+          platform-specific handling of stats.
+        type: "string"
+        x-nullable: true
+        example: "linux"
+      read:
+        description: |
+          Date and time at which this sample was collected.
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:22.165243637Z"
+      cpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+      memory_stats:
+        $ref: "#/definitions/ContainerMemoryStats"
+      networks:
+        description: |
+          Network statistics for the container per interface.
+
+          This field is omitted if the container has no networking enabled.
+        x-nullable: true
+        additionalProperties:
+          $ref: "#/definitions/ContainerNetworkStats"
+        example:
+          eth0:
+            rx_bytes: 5338
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 36
+            tx_bytes: 648
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 8
+          eth5:
+            rx_bytes: 4641
+            rx_dropped: 0
+            rx_errors: 0
+            rx_packets: 26
+            tx_bytes: 690
+            tx_dropped: 0
+            tx_errors: 0
+            tx_packets: 9
+      pids_stats:
+        $ref: "#/definitions/ContainerPidsStats"
+      blkio_stats:
+        $ref: "#/definitions/ContainerBlkioStats"
+      num_procs:
+        description: |
+          The number of processors on the system.
+
+          This field is Windows-specific and always zero for Linux containers.
+        type: "integer"
+        format: "uint32"
+        example: 16
+      storage_stats:
+        $ref: "#/definitions/ContainerStorageStats"
+      preread:
+        description: |
+          Date and time at which this first sample was collected. This field
+          is not propagated if the "one-shot" option is set. If the "one-shot"
+          option is set, this field may be omitted, empty, or set to a default
+          date (`0001-01-01T00:00:00Z`).
+
+          The value is formatted as [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          with nano-seconds.
+        type: "string"
+        format: "date-time"
+        example: "2025-01-16T13:55:21.160452595Z"
+      precpu_stats:
+        $ref: "#/definitions/ContainerCPUStats"
+
+  ContainerBlkioStats:
+    description: |
+      BlkioStats stores all IO service stats for data read and write.
+
+      This type is Linux-specific and holds many fields that are specific to cgroups v1.
+      On a cgroup v2 host, all fields other than `io_service_bytes_recursive`
+      are omitted or `null`.
+
+      This type is only populated on Linux and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStats"
+    x-nullable: true
+    properties:
+      io_service_bytes_recursive:
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_serviced_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_queue_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_service_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_wait_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_merged_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      io_time_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+      sectors_recursive:
+        description: |
+          This field is only available when using Linux containers with
+          cgroups v1. It is omitted or `null` when using cgroups v2.
+        x-nullable: true
+        type: "array"
+        items:
+          $ref: "#/definitions/ContainerBlkioStatEntry"
+    example:
+      io_service_bytes_recursive: [
+        {"major": 254, "minor": 0, "op": "read", "value": 7593984},
+        {"major": 254, "minor": 0, "op": "write", "value": 100}
+      ]
+      io_serviced_recursive: null
+      io_queue_recursive: null
+      io_service_time_recursive: null
+      io_wait_time_recursive: null
+      io_merged_recursive: null
+      io_time_recursive: null
+      sectors_recursive: null
+
+  ContainerBlkioStatEntry:
+    description: |
+      Blkio stats entry.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "BlkioStatEntry"
+    x-nullable: true
+    properties:
+      major:
+        type: "integer"
+        format: "uint64"
+        example: 254
+      minor:
+        type: "integer"
+        format: "uint64"
+        example: 0
+      op:
+        type: "string"
+        example: "read"
+      value:
+        type: "integer"
+        format: "uint64"
+        example: 7593984
+
+  ContainerCPUStats:
+    description: |
+      CPU related info of the container
+    type: "object"
+    x-go-name: "CPUStats"
+    x-nullable: true
+    properties:
+      cpu_usage:
+        $ref: "#/definitions/ContainerCPUUsage"
+      system_cpu_usage:
+        description: |
+          System Usage.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      online_cpus:
+        description: |
+          Number of online CPUs.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint32"
+        x-nullable: true
+        example: 5
+      throttling_data:
+        $ref: "#/definitions/ContainerThrottlingData"
+
+  ContainerCPUUsage:
+    description: |
+      All CPU stats aggregated since container inception.
+    type: "object"
+    x-go-name: "CPUUsage"
+    x-nullable: true
+    properties:
+      total_usage:
+        description: |
+          Total CPU time consumed in nanoseconds (Linux) or 100's of nanoseconds (Windows).
+        type: "integer"
+        format: "uint64"
+        example: 29912000
+      percpu_usage:
+        description: |
+          Total CPU time (in nanoseconds) consumed per core (Linux).
+
+          This field is Linux-specific when using cgroups v1. It is omitted
+          when using cgroups v2 and Windows containers.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "integer"
+          format: "uint64"
+          example: 29912000
+
+      usage_in_kernelmode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in kernel mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 21994000
+      usage_in_usermode:
+        description: |
+          Time (in nanoseconds) spent by tasks of the cgroup in user mode (Linux),
+          or time spent (in 100's of nanoseconds) by all container processes in
+          kernel mode (Windows).
+
+          Not populated for Windows containers using Hyper-V isolation.
+        type: "integer"
+        format: "uint64"
+        example: 7918000
+
+  ContainerPidsStats:
+    description: |
+      PidsStats contains Linux-specific stats of a container's process-IDs (PIDs).
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "PidsStats"
+    x-nullable: true
+    properties:
+      current:
+        description: |
+          Current is the number of PIDs in the cgroup.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 5
+      limit:
+        description: |
+          Limit is the hard limit on the number of pids in the cgroup.
+          A "Limit" of 0 means that there is no limit.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: "18446744073709551615"
+
+  ContainerThrottlingData:
+    description: |
+      CPU throttling stats of the container.
+
+      This type is Linux-specific and omitted for Windows containers.
+    type: "object"
+    x-go-name: "ThrottlingData"
+    x-nullable: true
+    properties:
+      periods:
+        description: |
+          Number of periods with throttling active.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_periods:
+        description: |
+          Number of periods when the container hit its throttling limit.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      throttled_time:
+        description: |
+          Aggregated time (in nanoseconds) the container was throttled for.
+        type: "integer"
+        format: "uint64"
+        example: 0
+
+  ContainerMemoryStats:
+    description: |
+      Aggregates all memory stats since container inception on Linux.
+      Windows returns stats for commit and private working set only.
+    type: "object"
+    x-go-name: "MemoryStats"
+    properties:
+      usage:
+        description: |
+          Current `res_counter` usage for memory.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      max_usage:
+        description: |
+          Maximum usage ever recorded.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      stats:
+        description: |
+          All the stats exported via memory.stat.
+
+          The fields in this object differ between cgroups v1 and v2.
+          On cgroups v1, fields such as `cache`, `rss`, `mapped_file` are available.
+          On cgroups v2, fields such as `file`, `anon`, `inactive_file` are available.
+
+          This field is Linux-specific and omitted for Windows containers.
+        type: "object"
+        additionalProperties:
+          type: "integer"
+          format: "uint64"
+          x-nullable: true
+        example:
+          {
+            "active_anon": 1572864,
+            "active_file": 5115904,
+            "anon": 1572864,
+            "anon_thp": 0,
+            "file": 7626752,
+            "file_dirty": 0,
+            "file_mapped": 2723840,
+            "file_writeback": 0,
+            "inactive_anon": 0,
+            "inactive_file": 2510848,
+            "kernel_stack": 16384,
+            "pgactivate": 0,
+            "pgdeactivate": 0,
+            "pgfault": 2042,
+            "pglazyfree": 0,
+            "pglazyfreed": 0,
+            "pgmajfault": 45,
+            "pgrefill": 0,
+            "pgscan": 0,
+            "pgsteal": 0,
+            "shmem": 0,
+            "slab": 1180928,
+            "slab_reclaimable": 725576,
+            "slab_unreclaimable": 455352,
+            "sock": 0,
+            "thp_collapse_alloc": 0,
+            "thp_fault_alloc": 1,
+            "unevictable": 0,
+            "workingset_activate": 0,
+            "workingset_nodereclaim": 0,
+            "workingset_refault": 0
+          }
+      failcnt:
+        description: |
+          Number of times memory usage hits limits.
+
+          This field is Linux-specific and only supported on cgroups v1.
+          It is omitted when using cgroups v2 and for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      limit:
+        description: |
+          This field is Linux-specific and omitted for Windows containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 8217579520
+      commitbytes:
+        description: |
+          Committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      commitpeakbytes:
+        description: |
+          Peak committed bytes.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+      privateworkingset:
+        description: |
+          Private working set.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 0
+
+  ContainerNetworkStats:
+    description: |
+      Aggregates the network stats of one container
+    type: "object"
+    x-go-name: "NetworkStats"
+    x-nullable: true
+    properties:
+      rx_bytes:
+        description: |
+          Bytes received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 5338
+      rx_packets:
+        description: |
+          Packets received. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 36
+      rx_errors:
+        description: |
+          Received errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      rx_dropped:
+        description: |
+          Incoming packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_bytes:
+        description: |
+          Bytes sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 1200
+      tx_packets:
+        description: |
+          Packets sent. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 12
+      tx_errors:
+        description: |
+          Sent errors. Not used on Windows.
+
+          This field is Linux-specific and always zero for Windows containers.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      tx_dropped:
+        description: |
+          Outgoing packets dropped. Windows and Linux.
+        type: "integer"
+        format: "uint64"
+        example: 0
+      endpoint_id:
+        description: |
+          Endpoint ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+      instance_id:
+        description: |
+          Instance ID. Not used on Linux.
+
+          This field is Windows-specific and omitted for Linux containers.
+        type: "string"
+        x-nullable: true
+
+  ContainerStorageStats:
+    description: |
+      StorageStats is the disk I/O stats for read/write on Windows.
+
+      This type is Windows-specific and omitted for Linux containers.
+    type: "object"
+    x-go-name: "StorageStats"
+    x-nullable: true
+    properties:
+      read_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      read_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_count_normalized:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+      write_size_bytes:
+        type: "integer"
+        format: "uint64"
+        x-nullable: true
+        example: 7593984
+
+  ContainerTopResponse:
+    type: "object"
+    x-go-name: "TopResponse"
+    title: "ContainerTopResponse"
+    description: |-
+      Container "top" response.
+    properties:
+      Titles:
+        description: "The ps column titles"
+        type: "array"
+        items:
+          type: "string"
+        example:
+          Titles:
+            - "UID"
+            - "PID"
+            - "PPID"
+            - "C"
+            - "STIME"
+            - "TTY"
+            - "TIME"
+            - "CMD"
+      Processes:
+        description: |-
+          Each process running in the container, where each process
+          is an array of values corresponding to the titles.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          Processes:
+            -
+              - "root"
+              - "13642"
+              - "882"
+              - "0"
+              - "17:03"
+              - "pts/0"
+              - "00:00:00"
+              - "/bin/bash"
+            -
+              - "root"
+              - "13735"
+              - "13642"
+              - "0"
+              - "17:06"
+              - "pts/0"
+              - "00:00:00"
+              - "sleep 10"
+
+  ContainerWaitResponse:
+    description: "OK response to ContainerWait operation"
+    type: "object"
+    x-go-name: "WaitResponse"
+    title: "ContainerWaitResponse"
+    required: [StatusCode]
+    properties:
+      StatusCode:
+        description: "Exit code of the container"
+        type: "integer"
+        format: "int64"
+        x-nullable: false
+      Error:
+        $ref: "#/definitions/ContainerWaitExitError"
+
+  ContainerWaitExitError:
+    description: "container waiting error, if any"
+    type: "object"
+    x-go-name: "WaitExitError"
+    properties:
+      Message:
+        description: "Details of an error"
+        type: "string"
+
+  SystemVersion:
+    type: "object"
+    description: |
+      Response of Engine API: GET "/version"
+    properties:
+      Platform:
+        type: "object"
+        required: [Name]
+        properties:
+          Name:
+            type: "string"
+      Components:
+        type: "array"
+        description: |
+          Information about system components
+        items:
+          type: "object"
+          x-go-name: ComponentVersion
+          required: [Name, Version]
+          properties:
+            Name:
+              description: |
+                Name of the component
+              type: "string"
+              example: "Engine"
+            Version:
+              description: |
+                Version of the component
+              type: "string"
+              x-nullable: false
+              example: "27.0.1"
+            Details:
+              description: |
+                Key/value pairs of strings with additional information about the
+                component. These values are intended for informational purposes
+                only, and their content is not defined, and not part of the API
+                specification.
+
+                These messages can be printed by the client as information to the user.
+              type: "object"
+              x-nullable: true
+      Version:
+        description: "The version of the daemon"
+        type: "string"
+        example: "27.0.1"
+      ApiVersion:
+        description: |
+          The default (and highest) API version that is supported by the daemon
+        type: "string"
+        example: "1.47"
+      MinAPIVersion:
+        description: |
+          The minimum API version that is supported by the daemon
+        type: "string"
+        example: "1.24"
+      GitCommit:
+        description: |
+          The Git commit of the source code that was used to build the daemon
+        type: "string"
+        example: "48a66213fe"
+      GoVersion:
+        description: |
+          The version Go used to compile the daemon, and the version of the Go
+          runtime in use.
+        type: "string"
+        example: "go1.22.7"
+      Os:
+        description: |
+          The operating system that the daemon is running on ("linux" or "windows")
+        type: "string"
+        example: "linux"
+      Arch:
+        description: |
+          Architecture of the daemon, as returned by the Go runtime (`GOARCH`).
+
+          A full list of possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "amd64"
+      KernelVersion:
+        description: |
+          The kernel version (`uname -r`) that the daemon is running on.
+
+          This field is omitted when empty.
+        type: "string"
+        example: "6.8.0-31-generic"
+      Experimental:
+        description: |
+          Indicates if the daemon is started with experimental features enabled.
+
+          This field is omitted when empty / false.
+        type: "boolean"
+        example: true
+      BuildTime:
+        description: |
+          The date and time that the daemon was compiled.
+        type: "string"
+        example: "2020-06-22T15:49:27.000000000+00:00"
+
+  SystemInfo:
+    type: "object"
+    properties:
+      ID:
+        description: |
+          Unique identifier of the daemon.
+
+          <p><br /></p>
+
+          > **Note**: The format of the ID itself is not part of the API, and
+          > should not be considered stable.
+        type: "string"
+        example: "7TRN:IPZB:QYBB:VPBQ:UMPP:KARE:6ZNR:XE6T:7EWV:PKF4:ZOJD:TPYS"
+      Containers:
+        description: "Total number of containers on the host."
+        type: "integer"
+        example: 14
+      ContainersRunning:
+        description: |
+          Number of containers with status `"running"`.
+        type: "integer"
+        example: 3
+      ContainersPaused:
+        description: |
+          Number of containers with status `"paused"`.
+        type: "integer"
+        example: 1
+      ContainersStopped:
+        description: |
+          Number of containers with status `"stopped"`.
+        type: "integer"
+        example: 10
+      Images:
+        description: |
+          Total number of images on the host.
+
+          Both _tagged_ and _untagged_ (dangling) images are counted.
+        type: "integer"
+        example: 508
+      Driver:
+        description: "Name of the storage driver in use."
+        type: "string"
+        example: "overlay2"
+      DriverStatus:
+        description: |
+          Information specific to the storage driver, provided as
+          "label" / "value" pairs.
+
+          This information is provided by the storage driver, and formatted
+          in a way consistent with the output of `docker info` on the command
+          line.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["Backing Filesystem", "extfs"]
+          - ["Supports d_type", "true"]
+          - ["Native Overlay Diff", "true"]
+      DockerRootDir:
+        description: |
+          Root directory of persistent Docker state.
+
+          Defaults to `/var/lib/docker` on Linux, and `C:\ProgramData\docker`
+          on Windows.
+        type: "string"
+        example: "/var/lib/docker"
+      Plugins:
+        $ref: "#/definitions/PluginsInfo"
+      MemoryLimit:
+        description: "Indicates if the host has memory limit support enabled."
+        type: "boolean"
+        example: true
+      SwapLimit:
+        description: "Indicates if the host has memory swap limit support enabled."
+        type: "boolean"
+        example: true
+      CpuCfsPeriod:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) period is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CpuCfsQuota:
+        description: |
+          Indicates if CPU CFS(Completely Fair Scheduler) quota is supported by
+          the host.
+        type: "boolean"
+        example: true
+      CPUShares:
+        description: |
+          Indicates if CPU Shares limiting is supported by the host.
+        type: "boolean"
+        example: true
+      CPUSet:
+        description: |
+          Indicates if CPUsets (cpuset.cpus, cpuset.mems) are supported by the host.
+
+          See [cpuset(7)](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt)
+        type: "boolean"
+        example: true
+      PidsLimit:
+        description: "Indicates if the host kernel has PID limit support enabled."
+        type: "boolean"
+        example: true
+      OomKillDisable:
+        description: "Indicates if OOM killer disable is supported on the host."
+        type: "boolean"
+      IPv4Forwarding:
+        description: "Indicates IPv4 forwarding is enabled."
+        type: "boolean"
+        example: true
+      Debug:
+        description: |
+          Indicates if the daemon is running in debug-mode / with debug-level
+          logging enabled.
+        type: "boolean"
+        example: true
+      NFd:
+        description: |
+          The total number of file Descriptors in use by the daemon process.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 64
+      NGoroutines:
+        description: |
+          The  number of goroutines that currently exist.
+
+          This information is only returned if debug-mode is enabled.
+        type: "integer"
+        example: 174
+      SystemTime:
+        description: |
+          Current system-time in [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)
+          format with nano-seconds.
+        type: "string"
+        example: "2017-08-08T20:28:29.06202363Z"
+      LoggingDriver:
+        description: |
+          The logging driver to use as a default for new containers.
+        type: "string"
+      CgroupDriver:
+        description: |
+          The driver to use for managing cgroups.
+        type: "string"
+        enum: ["cgroupfs", "systemd", "none"]
+        default: "cgroupfs"
+        example: "cgroupfs"
+      CgroupVersion:
+        description: |
+          The version of the cgroup.
+        type: "string"
+        enum: ["1", "2"]
+        default: "1"
+        example: "1"
+      NEventsListener:
+        description: "Number of event listeners subscribed."
+        type: "integer"
+        example: 30
+      KernelVersion:
+        description: |
+          Kernel version of the host.
+
+          On Linux, this information obtained from `uname`. On Windows this
+          information is queried from the <kbd>HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\</kbd>
+          registry value, for example _"10.0 14393 (14393.1198.amd64fre.rs1_release_sec.170427-1353)"_.
+        type: "string"
+        example: "6.8.0-31-generic"
+      OperatingSystem:
+        description: |
+          Name of the host's operating system, for example: "Ubuntu 24.04 LTS"
+          or "Windows Server 2016 Datacenter"
+        type: "string"
+        example: "Ubuntu 24.04 LTS"
+      OSVersion:
+        description: |
+          Version of the host's operating system
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including its
+          > very existence, and the formatting of values, should not be considered
+          > stable, and may change without notice.
+        type: "string"
+        example: "24.04"
+      OSType:
+        description: |
+          Generic type of the operating system of the host, as returned by the
+          Go runtime (`GOOS`).
+
+          Currently returned values are "linux" and "windows". A full list of
+          possible values can be found in the [Go documentation](https://go.dev/doc/install/source#environment).
+        type: "string"
+        example: "linux"
+      Architecture:
+        description: |
+          Hardware architecture of the host, as returned by the operating system.
+          This is equivalent to the output of `uname -m` on Linux.
+
+          Unlike `Arch` (from `/version`), this reports the machine's native
+          architecture, which can differ from the Go runtime architecture when
+          running a binary compiled for a different architecture (for example,
+          a 32-bit binary running on 64-bit hardware).
+        type: "string"
+        example: "x86_64"
+      NCPU:
+        description: |
+          The number of logical CPUs usable by the daemon.
+
+          The number of available CPUs is checked by querying the operating
+          system when the daemon starts. Changes to operating system CPU
+          allocation after the daemon is started are not reflected.
+        type: "integer"
+        example: 4
+      MemTotal:
+        description: |
+          Total amount of physical memory available on the host, in bytes.
+        type: "integer"
+        format: "int64"
+        example: 2095882240
+
+      IndexServerAddress:
+        description: |
+          Address / URL of the index server that is used for image search,
+          and as a default for user authentication for Docker Hub and Docker Cloud.
+        default: "https://index.docker.io/v1/"
+        type: "string"
+        example: "https://index.docker.io/v1/"
+      RegistryConfig:
+        $ref: "#/definitions/RegistryServiceConfig"
+      GenericResources:
+        $ref: "#/definitions/GenericResources"
+      HttpProxy:
+        description: |
+          HTTP-proxy configured for the daemon. This value is obtained from the
+          [`HTTP_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "http://xxxxx:xxxxx@proxy.corp.example.com:8080"
+      HttpsProxy:
+        description: |
+          HTTPS-proxy configured for the daemon. This value is obtained from the
+          [`HTTPS_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html) environment variable.
+          Credentials ([user info component](https://tools.ietf.org/html/rfc3986#section-3.2.1)) in the proxy URL
+          are masked in the API response.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "https://xxxxx:xxxxx@proxy.corp.example.com:4443"
+      NoProxy:
+        description: |
+          Comma-separated list of domain extensions for which no proxy should be
+          used. This value is obtained from the [`NO_PROXY`](https://www.gnu.org/software/wget/manual/html_node/Proxies.html)
+          environment variable.
+
+          Containers do not automatically inherit this configuration.
+        type: "string"
+        example: "*.local, 169.254/16"
+      Name:
+        description: "Hostname of the host."
+        type: "string"
+        example: "node5.corp.example.com"
+      Labels:
+        description: |
+          User-defined labels (key/value metadata) as set on the daemon.
+
+          <p><br /></p>
+
+          > **Note**: When part of a Swarm, nodes can both have _daemon_ labels,
+          > set through the daemon configuration, and _node_ labels, set from a
+          > manager node in the Swarm. Node labels are not included in this
+          > field. Node labels can be retrieved using the `/nodes/(id)` endpoint
+          > on a manager node in the Swarm.
+        type: "array"
+        items:
+          type: "string"
+        example: ["storage=ssd", "production"]
+      ExperimentalBuild:
+        description: |
+          Indicates if experimental features are enabled on the daemon.
+        type: "boolean"
+        example: true
+      ServerVersion:
+        description: |
+          Version string of the daemon.
+        type: "string"
+        example: "27.0.1"
+      Runtimes:
+        description: |
+          List of [OCI compliant](https://github.com/opencontainers/runtime-spec)
+          runtimes configured on the daemon. Keys hold the "name" used to
+          reference the runtime.
+
+          The Docker daemon relies on an OCI compliant runtime (invoked via the
+          `containerd` daemon) as its interface to the Linux kernel namespaces,
+          cgroups, and SELinux.
+
+          The default runtime is `runc`, and automatically configured. Additional
+          runtimes can be configured by the user and will be listed here.
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/Runtime"
+        default:
+          runc:
+            path: "runc"
+        example:
+          runc:
+            path: "runc"
+          runc-master:
+            path: "/go/bin/runc"
+          custom:
+            path: "/usr/local/bin/my-oci-runtime"
+            runtimeArgs: ["--debug", "--systemd-cgroup=false"]
+      DefaultRuntime:
+        description: |
+          Name of the default OCI runtime that is used when starting containers.
+
+          The default can be overridden per-container at create time.
+        type: "string"
+        default: "runc"
+        example: "runc"
+      Swarm:
+        $ref: "#/definitions/SwarmInfo"
+      LiveRestoreEnabled:
+        description: |
+          Indicates if live restore is enabled.
+
+          If enabled, containers are kept running when the daemon is shutdown
+          or upon daemon start if running containers are detected.
+        type: "boolean"
+        default: false
+        example: false
+      Isolation:
+        description: |
+          Represents the isolation technology to use as a default for containers.
+          The supported values are platform-specific.
+
+          If no isolation value is specified on daemon start, on Windows client,
+          the default is `hyperv`, and on Windows server, the default is `process`.
+
+          This option is currently not used on other platforms.
+        default: "default"
+        type: "string"
+        enum:
+          - "default"
+          - "hyperv"
+          - "process"
+          - ""
+      InitBinary:
+        description: |
+          Name and, optional, path of the `docker-init` binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "docker-init"
+      ContainerdCommit:
+        $ref: "#/definitions/Commit"
+      RuncCommit:
+        $ref: "#/definitions/Commit"
+      InitCommit:
+        $ref: "#/definitions/Commit"
+      SecurityOptions:
+        description: |
+          List of security features that are enabled on the daemon, such as
+          apparmor, seccomp, SELinux, user-namespaces (userns), rootless and
+          no-new-privileges.
+
+          Additional configuration options for each security feature may
+          be present, and are included as a comma-separated list of key/value
+          pairs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "name=apparmor"
+          - "name=seccomp,profile=default"
+          - "name=selinux"
+          - "name=userns"
+          - "name=rootless"
+      ProductLicense:
+        description: |
+          Reports a summary of the product license on the daemon.
+
+          If a commercial license has been applied to the daemon, information
+          such as number of nodes, and expiration are included.
+        type: "string"
+        example: "Community Engine"
+      DefaultAddressPools:
+        description: |
+          List of custom default address pools for local networks, which can be
+          specified in the daemon.json file or dockerd option.
+
+          Example: a Base "10.10.0.0/16" with Size 24 will define the set of 256
+          10.10.[0-255].0/24 address pools.
+        type: "array"
+        items:
+          type: "object"
+          properties:
+            Base:
+              description: "The network address in CIDR format"
+              type: "string"
+              example: "10.10.0.0/16"
+            Size:
+              description: "The network pool size"
+              type: "integer"
+              example: "24"
+      FirewallBackend:
+        $ref: "#/definitions/FirewallInfo"
+      DiscoveredDevices:
+        description: |
+          List of devices discovered by device drivers.
+
+          Each device includes information about its source driver, kind, name,
+          and additional driver-specific attributes.
+        type: "array"
+        items:
+          $ref: "#/definitions/DeviceInfo"
+      NRI:
+        $ref: "#/definitions/NRIInfo"
+      Warnings:
+        description: |
+          List of warnings / informational messages about missing features, or
+          issues related to the daemon configuration.
+
+          These messages can be printed by the client as information to the user.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "WARNING: No memory limit support"
+      CDISpecDirs:
+        description: |
+          List of directories where (Container Device Interface) CDI
+          specifications are located.
+
+          These specifications define vendor-specific modifications to an OCI
+          runtime specification for a container being created.
+
+          An empty list indicates that CDI device injection is disabled.
+
+          Note that since using CDI device injection requires the daemon to have
+          experimental enabled. For non-experimental daemons an empty list will
+          always be returned.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "/etc/cdi"
+          - "/var/run/cdi"
+      Containerd:
+        $ref: "#/definitions/ContainerdInfo"
+
+  ContainerdInfo:
+    description: |
+      Information for connecting to the containerd instance that is used by the daemon.
+      This is included for debugging purposes only.
+    type: "object"
+    x-nullable: true
+    properties:
+      Address:
+        description: "The address of the containerd socket."
+        type: "string"
+        example: "/run/containerd/containerd.sock"
+      Namespaces:
+        description: |
+          The namespaces that the daemon uses for running containers and
+          plugins in containerd. These namespaces can be configured in the
+          daemon configuration, and are considered to be used exclusively
+          by the daemon, Tampering with the containerd instance may cause
+          unexpected behavior.
+
+          As these namespaces are considered to be exclusively accessed
+          by the daemon, it is not recommended to change these values,
+          or to change them to a value that is used by other systems,
+          such as cri-containerd.
+        type: "object"
+        properties:
+          Containers:
+            description: |
+              The default containerd namespace used for containers managed
+              by the daemon.
+
+              The default namespace for containers is "moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "moby"
+            example: "moby"
+          Plugins:
+            description: |
+              The default containerd namespace used for plugins managed by
+              the daemon.
+
+              The default namespace for plugins is "plugins.moby", but will be
+              suffixed with the `<uid>.<gid>` of the remapped `root` if
+              user-namespaces are enabled and the containerd image-store
+              is used.
+            type: "string"
+            default: "plugins.moby"
+            example: "plugins.moby"
+
+  FirewallInfo:
+    description: |
+      Information about the daemon's firewalling configuration.
+
+      This field is currently only used on Linux, and omitted on other platforms.
+    type: "object"
+    x-nullable: true
+    properties:
+      Driver:
+        description: |
+          The name of the firewall backend driver.
+        type: "string"
+        example: "nftables"
+      Info:
+        description: |
+          Information about the firewall backend, provided as
+          "label" / "value" pairs.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "array"
+        items:
+          type: "array"
+          items:
+            type: "string"
+        example:
+          - ["ReloadedAt", "2025-01-01T00:00:00Z"]
+
+  # PluginsInfo is a temp struct holding Plugins name
+  # registered with docker daemon. It is used by Info struct
+  PluginsInfo:
+    description: |
+      Available plugins per type.
+
+      <p><br /></p>
+
+      > **Note**: Only unmanaged (V1) plugins are included in this list.
+      > V1 plugins are "lazily" loaded, and are not returned in this list
+      > if there is no resource using the plugin.
+    type: "object"
+    properties:
+      Volume:
+        description: "Names of available volume-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["local"]
+      Network:
+        description: "Names of available network-drivers, and network-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["bridge", "host", "ipvlan", "macvlan", "null", "overlay"]
+      Authorization:
+        description: "Names of available authorization plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["img-authz-plugin", "hbm"]
+      Log:
+        description: "Names of available logging-drivers, and logging-driver plugins."
+        type: "array"
+        items:
+          type: "string"
+        example: ["awslogs", "fluentd", "gcplogs", "gelf", "journald", "json-file", "splunk", "syslog"]
+
+
+  RegistryServiceConfig:
+    description: |
+      RegistryServiceConfig stores daemon registry services configuration.
+    type: "object"
+    x-nullable: true
+    properties:
+      InsecureRegistryCIDRs:
+        description: |
+          List of IP ranges of insecure registries, using the CIDR syntax
+          ([RFC 4632](https://tools.ietf.org/html/4632)). Insecure registries
+          accept un-encrypted (HTTP) and/or untrusted (HTTPS with certificates
+          from unknown CAs) communication.
+
+          By default, local registries (`::1/128` and `127.0.0.0/8`) are configured as
+          insecure. All other registries are secure. Communicating with an
+          insecure registry is not possible if the daemon assumes that registry
+          is secure.
+
+          This configuration override this behavior, insecure communication with
+          registries whose resolved IP address is within the subnet described by
+          the CIDR syntax.
+
+          Registries can also be marked insecure by hostname. Those registries
+          are listed under `IndexConfigs` and have their `Secure` field set to
+          `false`.
+
+          > **Warning**: Using this option can be useful when running a local
+          > registry, but introduces security vulnerabilities. This option
+          > should therefore ONLY be used for testing purposes. For increased
+          > security, users should add their CA to their system's list of trusted
+          > CAs instead of enabling this option.
+        type: "array"
+        items:
+          type: "string"
+        example: ["::1/128", "127.0.0.0/8"]
+      IndexConfigs:
+        type: "object"
+        additionalProperties:
+          $ref: "#/definitions/IndexInfo"
+        example:
+          "127.0.0.1:5000":
+            "Name": "127.0.0.1:5000"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "[2001:db8:a0b:12f0::1]:80":
+            "Name": "[2001:db8:a0b:12f0::1]:80"
+            "Mirrors": []
+            "Secure": false
+            "Official": false
+          "docker.io":
+            Name: "docker.io"
+            Mirrors: ["https://hub-mirror.corp.example.com:5000/"]
+            Secure: true
+            Official: true
+          "registry.internal.corp.example.com:3000":
+            Name: "registry.internal.corp.example.com:3000"
+            Mirrors: []
+            Secure: false
+            Official: false
+      Mirrors:
+        description: |
+          List of registry URLs that act as a mirror for the official
+          (`docker.io`) registry.
+
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://[2001:db8:a0b:12f0::1]/"
+
+  IndexInfo:
+    description:
+      IndexInfo contains information about a registry.
+    type: "object"
+    x-nullable: true
+    properties:
+      Name:
+        description: |
+          Name of the registry, such as "docker.io".
+        type: "string"
+        example: "docker.io"
+      Mirrors:
+        description: |
+          List of mirrors, expressed as URIs.
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "https://hub-mirror.corp.example.com:5000/"
+          - "https://registry-2.docker.io/"
+          - "https://registry-3.docker.io/"
+      Secure:
+        description: |
+          Indicates if the registry is part of the list of insecure
+          registries.
+
+          If `false`, the registry is insecure. Insecure registries accept
+          un-encrypted (HTTP) and/or untrusted (HTTPS with certificates from
+          unknown CAs) communication.
+
+          > **Warning**: Insecure registries can be useful when running a local
+          > registry. However, because its use creates security vulnerabilities
+          > it should ONLY be enabled for testing purposes. For increased
+          > security, users should add their CA to their system's list of
+          > trusted CAs instead of enabling this option.
+        type: "boolean"
+        example: true
+      Official:
+        description: |
+          Indicates whether this is an official registry (i.e., Docker Hub / docker.io)
+        type: "boolean"
+        example: true
+
+  Runtime:
+    description: |
+      Runtime describes an [OCI compliant](https://github.com/opencontainers/runtime-spec)
+      runtime.
+
+      The runtime is invoked by the daemon via the `containerd` daemon. OCI
+      runtimes act as an interface to the Linux kernel namespaces, cgroups,
+      and SELinux.
+    type: "object"
+    properties:
+      path:
+        description: |
+          Name and, optional, path, of the OCI executable binary.
+
+          If the path is omitted, the daemon searches the host's `$PATH` for the
+          binary and uses the first result.
+        type: "string"
+        example: "/usr/local/bin/my-oci-runtime"
+      runtimeArgs:
+        description: |
+          List of command-line arguments to pass to the runtime when invoked.
+        type: "array"
+        x-nullable: true
+        items:
+          type: "string"
+        example: ["--debug", "--systemd-cgroup=false"]
+      status:
+        description: |
+          Information specific to the runtime.
+
+          While this API specification does not define data provided by runtimes,
+          the following well-known properties may be provided by runtimes:
+
+          `org.opencontainers.runtime-spec.features`: features structure as defined
+          in the [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec/blob/main/features.md),
+          in a JSON string representation.
+
+          <p><br /></p>
+
+          > **Note**: The information returned in this field, including the
+          > formatting of values and labels, should not be considered stable,
+          > and may change without notice.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "org.opencontainers.runtime-spec.features": "{\"ociVersionMin\":\"1.0.0\",\"ociVersionMax\":\"1.1.0\",\"...\":\"...\"}"
+
+  Commit:
+    description: |
+      Commit holds the Git-commit (SHA1) that a binary was built from, as
+      reported in the version-string of external tools, such as `containerd`,
+      or `runC`.
+    type: "object"
+    properties:
+      ID:
+        description: "Actual commit ID of external tool."
+        type: "string"
+        example: "cfb82a876ecc11b5ca0977d1733adbe58599088a"
+
+  SwarmInfo:
+    description: |
+      Represents generic information about swarm.
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+        default: ""
+        example: "k67qz4598weg5unwwffg6z1m1"
+      NodeAddr:
+        description: |
+          IP address at which this node can be reached by other nodes in the
+          swarm.
+        type: "string"
+        default: ""
+        example: "10.0.0.46"
+      LocalNodeState:
+        $ref: "#/definitions/LocalNodeState"
+      ControlAvailable:
+        type: "boolean"
+        default: false
+        example: true
+      Error:
+        type: "string"
+        default: ""
+      RemoteManagers:
+        description: |
+          List of ID's and addresses of other managers in the swarm.
+        type: "array"
+        default: null
+        x-nullable: true
+        items:
+          $ref: "#/definitions/PeerNode"
+        example:
+          - NodeID: "71izy0goik036k48jg985xnds"
+            Addr: "10.0.0.158:2377"
+          - NodeID: "79y6h1o4gv8n120drcprv5nmc"
+            Addr: "10.0.0.159:2377"
+          - NodeID: "k67qz4598weg5unwwffg6z1m1"
+            Addr: "10.0.0.46:2377"
+      Nodes:
+        description: "Total number of nodes in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 4
+      Managers:
+        description: "Total number of managers in the swarm."
+        type: "integer"
+        x-nullable: true
+        example: 3
+      Cluster:
+        $ref: "#/definitions/ClusterInfo"
+
+  LocalNodeState:
+    description: "Current local status of this node."
+    type: "string"
+    default: ""
+    enum:
+      - ""
+      - "inactive"
+      - "pending"
+      - "active"
+      - "error"
+      - "locked"
+    example: "active"
+
+  PeerNode:
+    description: "Represents a peer-node in the swarm"
+    type: "object"
+    properties:
+      NodeID:
+        description: "Unique identifier of for this node in the swarm."
+        type: "string"
+      Addr:
+        description: |
+          IP address and ports at which this node can be reached.
+        type: "string"
+
+  NetworkAttachmentConfig:
+    description: |
+      Specifies how a service should be attached to a particular network.
+    type: "object"
+    properties:
+      Target:
+        description: |
+          The target network for attachment. Must be a network name or ID.
+        type: "string"
+      Aliases:
+        description: |
+          Discoverable alternate names for the service on this network.
+        type: "array"
+        items:
+          type: "string"
+      DriverOpts:
+        description: |
+          Driver attachment options for the network target.
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  EventActor:
+    description: |
+      Actor describes something that generates events, like a container, network,
+      or a volume.
+    type: "object"
+    properties:
+      ID:
+        description: "The ID of the object emitting the event"
+        type: "string"
+        example: "ede54ee1afda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c743"
+      Attributes:
+        description: |
+          Various key/value attributes of the object, depending on its type.
+        type: "object"
+        additionalProperties:
+          type: "string"
+        example:
+          com.example.some-label: "some-label-value"
+          image: "alpine:latest"
+          name: "my-container"
+
+  EventMessage:
+    description: |
+      EventMessage represents the information an event contains.
+    type: "object"
+    title: "SystemEventsResponse"
+    properties:
+      Type:
+        description: "The type of object emitting the event"
+        type: "string"
+        enum: ["builder", "config", "container", "daemon", "image", "network", "node", "plugin", "secret", "service", "volume"]
+        example: "container"
+      Action:
+        description: "The type of event"
+        type: "string"
+        example: "create"
+      Actor:
+        $ref: "#/definitions/EventActor"
+      scope:
+        description: |
+          Scope of the event. Engine events are `local` scope. Cluster (Swarm)
+          events are `swarm` scope.
+        type: "string"
+        enum: ["local", "swarm"]
+      time:
+        description: "Timestamp of event"
+        type: "integer"
+        format: "int64"
+        example: 1629574695
+      timeNano:
+        description: "Timestamp of event, with nanosecond accuracy"
+        type: "integer"
+        format: "int64"
+        example: 1629574695515050031
+
+  OCIDescriptor:
+    type: "object"
+    x-go-name: Descriptor
+    description: |
+      A descriptor struct containing digest, media type, and size, as defined in
+      the [OCI Content Descriptors Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/descriptor.md).
+    properties:
+      mediaType:
+        description: |
+          The media type of the object this schema refers to.
+        type: "string"
+        example: "application/vnd.oci.image.manifest.v1+json"
+      digest:
+        description: |
+          The digest of the targeted content.
+        type: "string"
+        example: "sha256:c0537ff6a5218ef531ece93d4984efc99bbf3f7497c0a7726c88e2bb7584dc96"
+      size:
+        description: |
+          The size in bytes of the blob.
+        type: "integer"
+        format: "int64"
+        example: 424
+      urls:
+        description: |-
+          List of URLs from which this object MAY be downloaded.
+        type: "array"
+        items:
+          type: "string"
+          format: "uri"
+        x-nullable: true
+      annotations:
+        description: |-
+          Arbitrary metadata relating to the targeted content.
+        type: "object"
+        x-nullable: true
+        additionalProperties:
+          type: "string"
+        example:
+          "com.docker.official-images.bashbrew.arch": "amd64"
+          "org.opencontainers.image.base.digest": "sha256:0d0ef5c914d3ea700147da1bd050c59edb8bb12ca312f3800b29d7c8087eabd8"
+          "org.opencontainers.image.base.name": "scratch"
+          "org.opencontainers.image.created": "2025-01-27T00:00:00Z"
+          "org.opencontainers.image.revision": "9fabb4bad5138435b01857e2fe9363e2dc5f6a79"
+          "org.opencontainers.image.source": "https://git.launchpad.net/cloud-images/+oci/ubuntu-base"
+          "org.opencontainers.image.url": "https://hub.docker.com/_/ubuntu"
+          "org.opencontainers.image.version": "24.04"
+      data:
+        type: string
+        x-nullable: true
+        description: |-
+          Data is an embedding of the targeted content. This is encoded as a base64
+          string when marshalled to JSON (automatically, by encoding/json). If
+          present, Data can be used directly to avoid fetching the targeted content.
+        example: null
+      platform:
+        $ref: "#/definitions/OCIPlatform"
+      artifactType:
+        description: |-
+          ArtifactType is the IANA media type of this artifact.
+        type: "string"
+        x-nullable: true
+        example: null
+
+  OCIPlatform:
+    type: "object"
+    x-go-name: Platform
+    x-nullable: true
+    description: |
+      Describes the platform which the image in the manifest runs on, as defined
+      in the [OCI Image Index Specification](https://github.com/opencontainers/image-spec/blob/v1.0.1/image-index.md).
+    properties:
+      architecture:
+        description: |
+          The CPU architecture, for example `amd64` or `ppc64`.
+        type: "string"
+        example: "arm"
+      os:
+        description: |
+          The operating system, for example `linux` or `windows`.
+        type: "string"
+        example: "windows"
+      os.version:
+        description: |
+          Optional field specifying the operating system version, for example on
+          Windows `10.0.19041.1165`.
+        type: "string"
+        example: "10.0.19041.1165"
+      os.features:
+        description: |
+          Optional field specifying an array of strings, each listing a required
+          OS feature (for example on Windows `win32k`).
+        type: "array"
+        items:
+          type: "string"
+        example:
+          - "win32k"
+      variant:
+        description: |
+          Optional field specifying a variant of the CPU, for example `v7` to
+          specify ARMv7 when architecture is `arm`.
+        type: "string"
+        example: "v7"
+
+  DistributionInspect:
+    type: "object"
+    x-go-name: DistributionInspect
+    title: "DistributionInspectResponse"
+    required: [Descriptor, Platforms]
+    description: |
+      Describes the result obtained from contacting the registry to retrieve
+      image metadata.
+    properties:
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Platforms:
+        type: "array"
+        description: |
+          An array containing all platforms supported by the image.
+        items:
+          $ref: "#/definitions/OCIPlatform"
+
+  ClusterVolume:
+    type: "object"
+    description: |
+      Options and information specific to, and only present on, Swarm CSI
+      cluster volumes.
+    properties:
+      ID:
+        type: "string"
+        description: |
+          The Swarm ID of this volume. Because cluster volumes are Swarm
+          objects, they have an ID, unlike non-cluster volumes. This ID can
+          be used to refer to the Volume instead of the name.
+      Version:
+        $ref: "#/definitions/ObjectVersion"
+      CreatedAt:
+        type: "string"
+        format: "dateTime"
+      UpdatedAt:
+        type: "string"
+        format: "dateTime"
+      Spec:
+        $ref: "#/definitions/ClusterVolumeSpec"
+      Info:
+        type: "object"
+        description: |
+          Information about the global status of the volume.
+        properties:
+          CapacityBytes:
+            type: "integer"
+            format: "int64"
+            description: |
+              The capacity of the volume in bytes. A value of 0 indicates that
+              the capacity is unknown.
+          VolumeContext:
+            type: "object"
+            description: |
+              A map of strings to strings returned from the storage plugin when
+              the volume is created.
+            additionalProperties:
+              type: "string"
+          VolumeID:
+            type: "string"
+            description: |
+              The ID of the volume as returned by the CSI storage plugin. This
+              is distinct from the volume's ID as provided by Docker. This ID
+              is never used by the user when communicating with Docker to refer
+              to this volume. If the ID is blank, then the Volume has not been
+              successfully created in the plugin yet.
+          AccessibleTopology:
+            type: "array"
+            description: |
+              The topology this volume is actually accessible from.
+            items:
+              $ref: "#/definitions/Topology"
+      PublishStatus:
+        type: "array"
+        description: |
+          The status of the volume as it pertains to its publishing and use on
+          specific nodes
+        items:
+          type: "object"
+          properties:
+            NodeID:
+              type: "string"
+              description: |
+                The ID of the Swarm node the volume is published on.
+            State:
+              type: "string"
+              description: |
+                The published state of the volume.
+                * `pending-publish` The volume should be published to this node, but the call to the controller plugin to do so has not yet been successfully completed.
+                * `published` The volume is published successfully to the node.
+                * `pending-node-unpublish` The volume should be unpublished from the node, and the manager is awaiting confirmation from the worker that it has done so.
+                * `pending-controller-unpublish` The volume is successfully unpublished from the node, but has not yet been successfully unpublished on the controller.
+              enum:
+                - "pending-publish"
+                - "published"
+                - "pending-node-unpublish"
+                - "pending-controller-unpublish"
+            PublishContext:
+              type: "object"
+              description: |
+                A map of strings to strings returned by the CSI controller
+                plugin when a volume is published.
+              additionalProperties:
+                type: "string"
+
+  ClusterVolumeSpec:
+    type: "object"
+    description: |
+      Cluster-specific options used to create the volume.
+    properties:
+      Group:
+        type: "string"
+        description: |
+          Group defines the volume group of this volume. Volumes belonging to
+          the same group can be referred to by group name when creating
+          Services.  Referring to a volume by group instructs Swarm to treat
+          volumes in that group interchangeably for the purpose of scheduling.
+          Volumes with an empty string for a group technically all belong to
+          the same, emptystring group.
+      AccessMode:
+        type: "object"
+        description: |
+          Defines how the volume is used by tasks.
+        properties:
+          Scope:
+            type: "string"
+            description: |
+              The set of nodes this volume can be used on at one time.
+              - `single` The volume may only be scheduled to one node at a time.
+              - `multi` the volume may be scheduled to any supported number of nodes at a time.
+            default: "single"
+            enum: ["single", "multi"]
+            x-nullable: false
+          Sharing:
+            type: "string"
+            description: |
+              The number and way that different tasks can use this volume
+              at one time.
+              - `none` The volume may only be used by one task at a time.
+              - `readonly` The volume may be used by any number of tasks, but they all must mount the volume as readonly
+              - `onewriter` The volume may be used by any number of tasks, but only one may mount it as read/write.
+              - `all` The volume may have any number of readers and writers.
+            default: "none"
+            enum: ["none", "readonly", "onewriter", "all"]
+            x-nullable: false
+          MountVolume:
+            type: "object"
+            description: |
+              Options for using this volume as a Mount-type volume.
+
+                  Either MountVolume or BlockVolume, but not both, must be
+                  present.
+                properties:
+                  FsType:
+                    type: "string"
+                    description: |
+                      Specifies the filesystem type for the mount volume.
+                      Optional.
+                  MountFlags:
+                    type: "array"
+                    description: |
+                      Flags to pass when mounting the volume. Optional.
+                    items:
+                      type: "string"
+              BlockVolume:
+                type: "object"
+                description: |
+                  Options for using this volume as a Block-type volume.
+                  Intentionally empty.
+          Secrets:
+            type: "array"
+            description: |
+              Swarm Secrets that are passed to the CSI storage plugin when
+              operating on this volume.
+            items:
+              type: "object"
+              description: |
+                One cluster volume secret entry. Defines a key-value pair that
+                is passed to the plugin.
+              properties:
+                Key:
+                  type: "string"
+                  description: |
+                    Key is the name of the key of the key-value pair passed to
+                    the plugin.
+                Secret:
+                  type: "string"
+                  description: |
+                    Secret is the swarm Secret object from which to read data.
+                    This can be a Secret name or ID. The Secret data is
+                    retrieved by swarm and used as the value of the key-value
+                    pair passed to the plugin.
+          AccessibilityRequirements:
+            type: "object"
+            description: |
+              Requirements for the accessible topology of the volume. These
+              fields are optional. For an in-depth description of what these
+              fields mean, see the CSI specification.
+            properties:
+              Requisite:
+                type: "array"
+                description: |
+                  A list of required topologies, at least one of which the
+                  volume must be accessible from.
+                items:
+                  $ref: "#/definitions/Topology"
+              Preferred:
+                type: "array"
+                description: |
+                  A list of topologies that the volume should attempt to be
+                  provisioned in.
+                items:
+                  $ref: "#/definitions/Topology"
+          CapacityRange:
+            type: "object"
+            description: |
+              The desired capacity that the volume should be created with. If
+              empty, the plugin will decide the capacity.
+            properties:
+              RequiredBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must be at least this big. The value of 0
+                  indicates an unspecified minimum
+              LimitBytes:
+                type: "integer"
+                format: "int64"
+                description: |
+                  The volume must not be bigger than this. The value of 0
+                  indicates an unspecified maximum.
+          Availability:
+            type: "string"
+            description: |
+              The availability of the volume for use in tasks.
+              - `active` The volume is fully available for scheduling on the cluster
+              - `pause` No new workloads should use the volume, but existing workloads are not stopped.
+              - `drain` All workloads using this volume should be stopped and rescheduled, and no new ones should be started.
+            default: "active"
+            x-nullable: false
+            enum:
+              - "active"
+              - "pause"
+              - "drain"
+
+  Topology:
+    description: |
+      A map of topological domains to topological segments. For in depth
+      details, see documentation for the Topology object in the CSI
+      specification.
+    type: "object"
+    properties:
+      Segments:
+        type: "object"
+        additionalProperties:
+          type: "string"
+
+  AttestationStatement:
+    x-go-name: "AttestationStatement"
+    description: |
+      AttestationStatement is a single in-toto statement attached to an image.
+    type: "object"
+    required: ["Descriptor", "PredicateType"]
+    properties:
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      PredicateType:
+        description: The in-toto predicate type URI of this statement.
+        type: "string"
+        example: "https://slsa.dev/provenance/v0.2"
+      Statement:
+        description: |
+          The verbatim in-toto statement JSON. Only included when the caller
+          opts in via the `statement=true` query parameter; otherwise absent.
+        type: "object"
+        x-nullable: true
+  ImageManifestSummary:
+    x-go-name: "ManifestSummary"
+    description: |
+      ImageManifestSummary represents a summary of an image manifest.
+    type: "object"
+    required: ["ID", "Descriptor", "Available", "Size", "Kind"]
+    properties:
+      ID:
+        description: |
+          ID is the content-addressable ID of an image and is the same as the
+          digest of the image manifest.
+        type: "string"
+        example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+      Descriptor:
+        $ref: "#/definitions/OCIDescriptor"
+      Available:
+        description: Indicates whether all the child content (image config, layers) is fully available locally.
+        type: "boolean"
+        example: true
+      Size:
+        type: "object"
+        x-nullable: false
+        required: ["Content", "Total"]
+        properties:
+          Total:
+            type: "integer"
+            format: "int64"
+            example: 8213251
+            description: |
+              Total is the total size (in bytes) of all the locally present
+              data (both distributable and non-distributable) that's related to
+              this manifest and its children.
+              This equal to the sum of [Content] size AND all the sizes in the
+              [Size] struct present in the Kind-specific data struct.
+              For example, for an image kind (Kind == "image")
+              this would include the size of the image content and unpacked
+              image snapshots ([Size.Content] + [ImageData.Size.Unpacked]).
+          Content:
+            description: |
+              Content is the size (in bytes) of all the locally present
+              content in the content store (e.g. image config, layers)
+              referenced by this manifest and its children.
+              This only includes blobs in the content store.
+            type: "integer"
+            format: "int64"
+            example: 3987495
+      Kind:
+        type: "string"
+        example: "image"
+        enum:
+          - "image"
+          - "attestation"
+          - "unknown"
+        description: |
+          The kind of the manifest.
+
+          kind         | description
+          -------------|-----------------------------------------------------------
+          image        | Image manifest that can be used to start a container.
+          attestation  | Attestation manifest produced by the Buildkit builder for a specific image manifest.
+      ImageData:
+        description: |
+          The image data for the image manifest.
+          This field is only populated when Kind is "image".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["Platform", "Containers", "Size", "UnpackedSize"]
+        properties:
+          Platform:
+            $ref: "#/definitions/OCIPlatform"
+            description: |
+              OCI platform of the image. This will be the platform specified in the
+              manifest descriptor from the index/manifest list.
+              If it's not available, it will be obtained from the image config.
+          Identity:
+            description: |
+              Identity holds information about the identity and origin of this image.
+              For image list responses, this can duplicate Build/Pull fields across
+              image manifests, because those parts are image-level metadata.
+            x-nullable: true
+            $ref: "#/definitions/Identity"
+          Containers:
+            description: |
+              The IDs of the containers that are using this image.
+            type: "array"
+            items:
+              type: "string"
+            example: ["ede54ee1fda366ab42f824e8a5ffd195155d853ceaec74a927f249ea270c7430", "abadbce344c096744d8d6071a90d474d28af8f1034b5ea9fb03c3f4bfc6d005e"]
+          Size:
+            type: "object"
+            x-nullable: false
+            required: ["Unpacked"]
+            properties:
+              Unpacked:
+                type: "integer"
+                format: "int64"
+                example: 3987495
+                description: |
+                  Unpacked is the size (in bytes) of the locally unpacked
+                  (uncompressed) image content that's directly usable by the containers
+                  running this image.
+                  It's independent of the distributable content - e.g.
+                  the image might still have an unpacked data that's still used by
+                  some container even when the distributable/compressed content is
+                  already gone.
+      AttestationData:
+        description: |
+          The image data for the attestation manifest.
+          This field is only populated when Kind is "attestation".
+        type: "object"
+        x-nullable: true
+        x-omitempty: true
+        required: ["For"]
+        properties:
+          For:
+            description: |
+              The digest of the image manifest that this attestation is for.
+            type: "string"
+            example: "sha256:95869fbcf224d947ace8d61d0e931d49e31bb7fc67fffbbe9c3198c33aa8e93f"
+
+paths:
+  /containers/json:
+    get:
+      summary: "List containers"
+      description: |
+        Returns a list of containers. For details on the format, see the
+        [inspect endpoint](#operation/ContainerInspect).
+
+        Note that it uses a different, smaller representation of a container
+        than inspecting a single container. For example, the list of linked
+        containers is not propagated .
+      operationId: "ContainerList"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: |
+            Return all containers. By default, only running containers are shown.
+          type: "boolean"
+          default: false
+        - name: "limit"
+          in: "query"
+          description: |
+            Return this number of most recently created containers, including
+            non-running ones.
+          type: "integer"
+        - name: "size"
+          in: "query"
+          description: |
+            Return the size of container as fields `SizeRw` and `SizeRootFs`.
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the container list, encoded as JSON (a
+            `map[string][]string`). For example, `{"status": ["paused"]}` will
+            only return paused containers.
+
+            Available filters:
+
+            - `ancestor`=(`<image-name>[:<tag>]`, `<image id>`, or `<image@digest>`)
+            - `before`=(`<container id>` or `<container name>`)
+            - `expose`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `exited=<int>` containers with exit code of `<int>`
+            - `health`=(`starting`|`healthy`|`unhealthy`|`none`)
+            - `id=<ID>` a container's ID
+            - `isolation=`(`default`|`process`|`hyperv`) (Windows daemon only)
+            - `is-task=`(`true`|`false`)
+            - `label=key` or `label="key=value"` of a container label
+            - `name=<name>` a container's name
+            - `network`=(`<network id>` or `<network name>`)
+            - `publish`=(`<port>[/<proto>]`|`<startport-endport>/[<proto>]`)
+            - `since`=(`<container id>` or `<container name>`)
+            - `status=`(`created`|`restarting`|`running`|`removing`|`paused`|`exited`|`dead`)
+            - `volume`=(`<volume name>` or `<mount point destination>`)
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ContainerSummary"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/create:
+    post:
+      summary: "Create a container"
+      operationId: "ContainerCreate"
+      consumes:
+        - "application/json"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            Assign the specified name to the container. Must match
+            `/?[a-zA-Z0-9][a-zA-Z0-9_.-]+`.
+          type: "string"
+          pattern: "^/?[a-zA-Z0-9][a-zA-Z0-9_.-]+$"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format `os[/arch[/variant]]` used for image lookup.
+
+            When specified, the daemon checks if the requested image is present
+            in the local image cache with the given OS and Architecture, and
+            otherwise returns a `404` status.
+
+            If the option is not set, the host's native OS and Architecture are
+            used to look up the image in the image cache. However, if no platform
+            is passed and the given image does exist in the local image cache,
+            but its OS or architecture does not match, the container is created
+            with the available image, and a warning is added to the `Warnings`
+            field in the response, for example;
+
+                WARNING: The requested image's platform (linux/arm64/v8) does not
+                         match the detected host platform (linux/amd64) and no
+                         specific platform was requested
+
+          type: "string"
+          default: ""
+        - name: "body"
+          in: "body"
+          description: "Container to create"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ContainerConfig"
+              - type: "object"
+                properties:
+                  HostConfig:
+                    $ref: "#/definitions/HostConfig"
+                  NetworkingConfig:
+                    $ref: "#/definitions/NetworkingConfig"
+            example:
+              Hostname: ""
+              Domainname: ""
+              User: ""
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              Tty: false
+              OpenStdin: false
+              StdinOnce: false
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+              Cmd:
+                - "date"
+              Entrypoint: ""
+              Image: "ubuntu"
+              Labels:
+                com.example.vendor: "Acme"
+                com.example.license: "GPL"
+                com.example.version: "1.0"
+              Volumes:
+                /volumes/data: {}
+              WorkingDir: ""
+              NetworkDisabled: false
+              ExposedPorts:
+                22/tcp: {}
+              StopSignal: "SIGTERM"
+              StopTimeout: 10
+              HostConfig:
+                Binds:
+                  - "/tmp:/tmp"
+                Links:
+                  - "redis3:redis"
+                Memory: 0
+                MemorySwap: 0
+                MemoryReservation: 0
+                NanoCpus: 500000
+                CpuPercent: 80
+                CpuShares: 512
+                CpuPeriod: 100000
+                CpuRealtimePeriod: 1000000
+                CpuRealtimeRuntime: 10000
+                CpuQuota: 50000
+                CpusetCpus: "0,1"
+                CpusetMems: "0,1"
+                MaximumIOps: 0
+                MaximumIOBps: 0
+                BlkioWeight: 300
+                BlkioWeightDevice:
+                  - {}
+                BlkioDeviceReadBps:
+                  - {}
+                BlkioDeviceReadIOps:
+                  - {}
+                BlkioDeviceWriteBps:
+                  - {}
+                BlkioDeviceWriteIOps:
+                  - {}
+                DeviceRequests:
+                  - Driver: "nvidia"
+                    Count: -1
+                    DeviceIDs": ["0", "1", "GPU-fef8089b-4820-abfc-e83e-94318197576e"]
+                    Capabilities: [["gpu", "nvidia", "compute"]]
+                    Options:
+                      property1: "string"
+                      property2: "string"
+                MemorySwappiness: 60
+                OomKillDisable: false
+                OomScoreAdj: 500
+                PidMode: ""
+                PidsLimit: 0
+                PortBindings:
+                  22/tcp:
+                    - HostPort: "11022"
+                PublishAllPorts: false
+                Privileged: false
+                ReadonlyRootfs: false
+                Dns:
+                  - "8.8.8.8"
+                DnsOptions:
+                  - ""
+                DnsSearch:
+                  - ""
+                VolumesFrom:
+                  - "parent"
+                  - "other:ro"
+                CapAdd:
+                  - "NET_ADMIN"
+                CapDrop:
+                  - "MKNOD"
+                GroupAdd:
+                  - "newgroup"
+                RestartPolicy:
+                  Name: ""
+                  MaximumRetryCount: 0
+                AutoRemove: true
+                NetworkMode: "bridge"
+                Devices: []
+                Ulimits:
+                  - {}
+                LogConfig:
+                  Type: "json-file"
+                  Config: {}
+                SecurityOpt: []
+                StorageOpt: {}
+                CgroupParent: ""
+                VolumeDriver: ""
+                ShmSize: 67108864
+              NetworkingConfig:
+                EndpointsConfig:
+                  isolated_nw:
+                    IPAMConfig:
+                      IPv4Address: "172.20.30.33"
+                      IPv6Address: "2001:db8:abcd::3033"
+                      LinkLocalIPs:
+                        - "169.254.34.68"
+                        - "fe80::3468"
+                    Links:
+                      - "container_1"
+                      - "container_2"
+                    Aliases:
+                      - "server_x"
+                      - "server_y"
+                  database_nw: {}
+
+          required: true
+      responses:
+        201:
+          description: "Container created successfully"
+          schema:
+            $ref: "#/definitions/ContainerCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /containers/{id}/json:
+    get:
+      summary: "Inspect a container"
+      description: "Return low-level information about a container."
+      operationId: "ContainerInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerInspectResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "size"
+          in: "query"
+          type: "boolean"
+          default: false
+          description: "Return the size of container as fields `SizeRw` and `SizeRootFs`"
+      tags: ["Container"]
+  /containers/{id}/top:
+    get:
+      summary: "List processes running inside a container"
+      description: |
+        On Unix systems, this is done by running the `ps` command. This endpoint
+        is not supported on Windows.
+      operationId: "ContainerTop"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerTopResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "ps_args"
+          in: "query"
+          description: "The arguments to pass to `ps`. For example, `aux`"
+          type: "string"
+          default: "-ef"
+      tags: ["Container"]
+  /containers/{id}/logs:
+    get:
+      summary: "Get container logs"
+      description: |
+        Get `stdout` and `stderr` logs from a container.
+
+        Note: This endpoint works only for containers with the `json-file` or
+        `journald` logging driver.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ContainerLogs"
+      responses:
+        200:
+          description: |
+            logs returned as a stream in response body.
+            For the stream format, [see the documentation for the attach endpoint](#operation/ContainerAttach).
+            Note that unlike the attach endpoint, the logs endpoint does not
+            upgrade the connection and does not set Content-Type.
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "until"
+          in: "query"
+          description: "Only return logs before this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Container"]
+  /containers/{id}/changes:
+    get:
+      summary: "Get changes on a container’s filesystem"
+      description: |
+        Returns which files in a container's filesystem have been added, deleted,
+        or modified. The `Kind` of modification can be one of:
+
+        - `0`: Modified ("C")
+        - `1`: Added ("A")
+        - `2`: Deleted ("D")
+      operationId: "ContainerChanges"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The list of changes"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/FilesystemChange"
+          examples:
+            application/json:
+              - Path: "/dev"
+                Kind: 0
+              - Path: "/dev/kmsg"
+                Kind: 1
+              - Path: "/test"
+                Kind: 1
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/export:
+    get:
+      summary: "Export a container"
+      description: "Export the contents of a container as a tarball."
+      operationId: "ContainerExport"
+      produces:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stats:
+    get:
+      summary: "Get container stats based on resource usage"
+      description: |
+        This endpoint returns a live stream of a container’s resource usage
+        statistics.
+
+        The `precpu_stats` is the CPU statistic of the *previous* read, and is
+        used to calculate the CPU usage percentage. It is not an exact copy
+        of the `cpu_stats` field.
+
+        If either `precpu_stats.online_cpus` or `cpu_stats.online_cpus` is
+        nil then for compatibility with older daemons the length of the
+        corresponding `cpu_usage.percpu_usage` array should be used.
+
+        On a cgroup v2 host, the following fields are not set
+        * `blkio_stats`: all fields other than `io_service_bytes_recursive`
+        * `cpu_stats`: `cpu_usage.percpu_usage`
+        * `memory_stats`: `max_usage` and `failcnt`
+        Also, `memory_stats.stats` fields are incompatible with cgroup v1.
+
+        To calculate the values shown by the `stats` command of the docker cli tool
+        the following formulas can be used:
+        * used_memory = `memory_stats.usage - memory_stats.stats.cache` (cgroups v1)
+        * used_memory = `memory_stats.usage - memory_stats.stats.inactive_file` (cgroups v2)
+        * available_memory = `memory_stats.limit`
+        * Memory usage % = `(used_memory / available_memory) * 100.0`
+        * cpu_delta = `cpu_stats.cpu_usage.total_usage - precpu_stats.cpu_usage.total_usage`
+        * system_cpu_delta = `cpu_stats.system_cpu_usage - precpu_stats.system_cpu_usage`
+        * number_cpus = `length(cpu_stats.cpu_usage.percpu_usage)` or `cpu_stats.online_cpus`
+        * CPU usage % = `(cpu_delta / system_cpu_delta) * number_cpus * 100.0`
+      operationId: "ContainerStats"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ContainerStatsResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream the output. If false, the stats will be output once and then
+            it will disconnect.
+          type: "boolean"
+          default: true
+        - name: "one-shot"
+          in: "query"
+          description: |
+            Only get a single stat instead of waiting for 2 cycles. Must be used
+            with `stream=false`.
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/resize:
+    post:
+      summary: "Resize a container TTY"
+      description: "Resize the TTY for a container."
+      operationId: "ContainerResize"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "cannot resize container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/start:
+    post:
+      summary: "Start a container"
+      operationId: "ContainerStart"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already started"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container. Format is a
+            single character `[a-Z]` or `ctrl-<value>` where `<value>` is one
+            of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/stop:
+    post:
+      summary: "Stop a container"
+      operationId: "ContainerStop"
+      responses:
+        204:
+          description: "no error"
+        304:
+          description: "container already stopped"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/restart:
+    post:
+      summary: "Restart a container"
+      operationId: "ContainerRestart"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+        - name: "t"
+          in: "query"
+          description: "Number of seconds to wait before killing the container"
+          type: "integer"
+      tags: ["Container"]
+  /containers/{id}/kill:
+    post:
+      summary: "Kill a container"
+      description: |
+        Send a POSIX signal to a container, defaulting to killing to the
+        container.
+      operationId: "ContainerKill"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is not running"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "Container d37cde0fe4ad63c3a7252023b2f9800282894247d145cb5933ddf6e52cc03a28 is not running"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "signal"
+          in: "query"
+          description: |
+            Signal to send to the container as an integer or string (e.g. `SIGINT`).
+          type: "string"
+          default: "SIGKILL"
+      tags: ["Container"]
+  /containers/{id}/update:
+    post:
+      summary: "Update a container"
+      description: |
+        Change various configuration options of a container without having to
+        recreate it.
+      operationId: "ContainerUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has been updated."
+          schema:
+            $ref: "#/definitions/ContainerUpdateResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "update"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/Resources"
+              - type: "object"
+                properties:
+                  RestartPolicy:
+                    $ref: "#/definitions/RestartPolicy"
+            example:
+              BlkioWeight: 300
+              CpuShares: 512
+              CpuPeriod: 100000
+              CpuQuota: 50000
+              CpuRealtimePeriod: 1000000
+              CpuRealtimeRuntime: 10000
+              CpusetCpus: "0,1"
+              CpusetMems: "0"
+              Memory: 314572800
+              MemorySwap: 514288000
+              MemoryReservation: 209715200
+              RestartPolicy:
+                MaximumRetryCount: 4
+                Name: "on-failure"
+      tags: ["Container"]
+  /containers/{id}/rename:
+    post:
+      summary: "Rename a container"
+      operationId: "ContainerRename"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "name already in use"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "name"
+          in: "query"
+          required: true
+          description: "New name for the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/pause:
+    post:
+      summary: "Pause a container"
+      description: |
+        Use the freezer cgroup to suspend all processes in a container.
+
+        Traditionally, when suspending a process the `SIGSTOP` signal is used,
+        which is observable by the process being suspended. With the freezer
+        cgroup the process is unaware, and unable to capture, that it is being
+        suspended, and subsequently resumed.
+      operationId: "ContainerPause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/unpause:
+    post:
+      summary: "Unpause a container"
+      description: "Resume a container which has been paused."
+      operationId: "ContainerUnpause"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+      tags: ["Container"]
+  /containers/{id}/attach:
+    post:
+      summary: "Attach to a container"
+      description: |
+        Attach to a container to read its output or send it input. You can attach
+        to the same container multiple times and you can reattach to containers
+        that have been detached.
+
+        Either the `stream` or `logs` parameter must be `true` for this endpoint
+        to do anything.
+
+        See the [documentation for the `docker attach` command](https://docs.docker.com/engine/reference/commandline/attach/)
+        for more details.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to transport `stdin`, `stdout`,
+        and `stderr` on the same socket.
+
+        This is the response from the daemon for an attach request:
+
+        ```
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        [STREAM]
+        ```
+
+        After the headers and two new lines, the TCP connection can now be used
+        for raw, bidirectional communication between the client and server.
+
+        To hint potential proxies about connection hijacking, the Docker client
+        can also optionally send connection upgrade headers.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /containers/16253994b7c4/attach?stream=1&stdout=1 HTTP/1.1
+        Upgrade: tcp
+        Connection: Upgrade
+        ```
+
+        The Docker daemon will respond with a `101 UPGRADED` response, and will
+        similarly follow with the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Content-Type: application/vnd.docker.raw-stream
+        Connection: Upgrade
+        Upgrade: tcp
+
+        [STREAM]
+        ```
+
+        ### Stream format
+
+        When the TTY setting is disabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the HTTP Content-Type header is set to application/vnd.docker.multiplexed-stream
+        and the stream over the hijacked connected is multiplexed to separate out
+        `stdout` and `stderr`. The stream consists of a series of frames, each
+        containing a header and a payload.
+
+        The header contains the information which the stream writes (`stdout` or
+        `stderr`). It also contains the size of the associated frame encoded in
+        the last four bytes (`uint32`).
+
+        It is encoded on the first eight bytes like this:
+
+        ```go
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+        ```
+
+        `STREAM_TYPE` can be:
+
+        - 0: `stdin` (is written on `stdout`)
+        - 1: `stdout`
+        - 2: `stderr`
+
+        `SIZE1, SIZE2, SIZE3, SIZE4` are the four bytes of the `uint32` size
+        encoded as big endian.
+
+        Following the header is the payload, which is the specified number of
+        bytes of `STREAM_TYPE`.
+
+        The simplest way to implement this protocol is the following:
+
+        1. Read 8 bytes.
+        2. Choose `stdout` or `stderr` depending on the first byte.
+        3. Extract the frame size from the last four bytes.
+        4. Read the extracted size and output it on the correct output.
+        5. Goto 1.
+
+        ### Stream format when using a TTY
+
+        When the TTY setting is enabled in [`POST /containers/create`](#operation/ContainerCreate),
+        the stream is not multiplexed. The data exchanged over the hijacked
+        connection is simply the raw data from the process PTY and client's
+        `stdin`.
+
+      operationId: "ContainerAttach"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,` or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: |
+            Replay previous logs from the container.
+
+            This is useful for attaching to a container that has started and you
+            want to output everything since the container started.
+
+            If `stream` is also enabled, once all the previous output has been
+            returned, it will seamlessly transition into streaming current
+            output.
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: |
+            Stream attached streams from the time the request was made onwards.
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/attach/ws:
+    get:
+      summary: "Attach to a container via a websocket"
+      operationId: "ContainerAttachWebsocket"
+      responses:
+        101:
+          description: "no error, hints proxy about hijacking"
+        200:
+          description: "no error, no upgrade header found"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "detachKeys"
+          in: "query"
+          description: |
+            Override the key sequence for detaching a container.Format is a single
+            character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`,
+            `@`, `^`, `[`, `,`, or `_`.
+          type: "string"
+        - name: "logs"
+          in: "query"
+          description: "Return logs"
+          type: "boolean"
+          default: false
+        - name: "stream"
+          in: "query"
+          description: "Return stream"
+          type: "boolean"
+          default: false
+        - name: "stdin"
+          in: "query"
+          description: "Attach to `stdin`"
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Attach to `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Attach to `stderr`"
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/wait:
+    post:
+      summary: "Wait for a container"
+      description: "Block until a container stops, then returns the exit code."
+      operationId: "ContainerWait"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The container has exit."
+          schema:
+            $ref: "#/definitions/ContainerWaitResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "condition"
+          in: "query"
+          description: |
+            Wait until a container state reaches the given condition.
+
+            Defaults to `not-running` if omitted or empty.
+          type: "string"
+          enum:
+            - "not-running"
+            - "next-exit"
+            - "removed"
+          default: "not-running"
+      tags: ["Container"]
+  /containers/{id}:
+    delete:
+      summary: "Remove a container"
+      operationId: "ContainerDelete"
+      responses:
+        204:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: |
+                You cannot remove a running container: c2ada9df5af8. Stop the
+                container before attempting removal or force remove
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "v"
+          in: "query"
+          description: "Remove anonymous volumes associated with the container."
+          type: "boolean"
+          default: false
+        - name: "force"
+          in: "query"
+          description: "If the container is running, kill it before removing it."
+          type: "boolean"
+          default: false
+        - name: "link"
+          in: "query"
+          description: "Remove the specified link associated with the container."
+          type: "boolean"
+          default: false
+      tags: ["Container"]
+  /containers/{id}/archive:
+    head:
+      summary: "Get information about files in a container"
+      description: |
+        A response header `X-Docker-Container-Path-Stat` is returned, containing
+        a base64 - encoded JSON object with some filesystem header information
+        about the path.
+      operationId: "ContainerArchiveInfo"
+      responses:
+        200:
+          description: "no error"
+          headers:
+            X-Docker-Container-Path-Stat:
+              type: "string"
+              description: |
+                A base64 - encoded JSON object with some filesystem header
+                information about the path
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    get:
+      summary: "Get an archive of a filesystem resource in a container"
+      description: "Get a tar archive of a resource in the filesystem of container id."
+      operationId: "ContainerArchive"
+      produces: ["application/x-tar"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Container or path does not exist"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Resource in the container’s filesystem to archive."
+          type: "string"
+      tags: ["Container"]
+    put:
+      summary: "Extract an archive of files or folders to a directory in a container"
+      description: |
+        Upload a tar archive to be extracted to a path in the filesystem of container id.
+        `path` parameter is asserted to be a directory. If it exists as a file, 400 error
+        will be returned with message "not a directory".
+      operationId: "PutContainerArchive"
+      consumes: ["application/x-tar", "application/octet-stream"]
+      responses:
+        200:
+          description: "The content was extracted successfully"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "not a directory"
+        403:
+          description: "Permission denied, the volume or container rootfs is marked as read-only."
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such container or path does not exist inside the container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the container"
+          type: "string"
+        - name: "path"
+          in: "query"
+          required: true
+          description: "Path to a directory in the container to extract the archive’s contents into. "
+          type: "string"
+        - name: "noOverwriteDirNonDir"
+          in: "query"
+          description: |
+            If `1`, `true`, or `True` then it will be an error if unpacking the
+            given content would cause an existing directory to be replaced with
+            a non-directory and vice versa.
+          type: "string"
+        - name: "copyUIDGID"
+          in: "query"
+          description: |
+            If `1`, `true`, then it will copy UID/GID maps to the dest file or
+            dir
+          type: "string"
+        - name: "inputStream"
+          in: "body"
+          required: true
+          description: |
+            The input stream must be a tar archive compressed with one of the
+            following algorithms: `identity` (no compression), `gzip`, `bzip2`,
+            or `xz`.
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Container"]
+  /containers/prune:
+    post:
+      summary: "Delete stopped containers"
+      produces:
+        - "application/json"
+      operationId: "ContainerPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune containers created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune containers with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ContainerPruneResponse"
+            properties:
+              ContainersDeleted:
+                description: "Container IDs that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Container"]
+  /images/json:
+    get:
+      summary: "List Images"
+      description: "Returns a list of images on the server. Note that it uses a different, smaller representation of an image than inspecting a single image."
+      operationId: "ImageList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "Summary image data for the images matching the query"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageSummary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "all"
+          in: "query"
+          description: "Show all images. Only images from a final layer (no children) are shown by default."
+          type: "boolean"
+          default: false
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the images list.
+
+            Available filters:
+
+            - `before`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `dangling=true`
+            - `label=key` or `label="key=value"` of an image label
+            - `reference`=(`<image-name>[:<tag>]`)
+            - `since`=(`<image-name>[:<tag>]`,  `<image id>` or `<image@digest>`)
+            - `until=<timestamp>`
+          type: "string"
+        - name: "shared-size"
+          in: "query"
+          description: "Compute and show shared size as a `SharedSize` field on each image."
+          type: "boolean"
+          default: false
+        - name: "digests"
+          in: "query"
+          description: "Show digest information as a `RepoDigests` field on each image."
+          type: "boolean"
+          default: false
+        - name: "manifests"
+          in: "query"
+          description: "Include `Manifests` in the image summary."
+          type: "boolean"
+          default: false
+        - name: "identity"
+          in: "query"
+          description: "Include `Identity` in each manifest summary. Requires `manifests=1`."
+          type: "boolean"
+          default: false
+      tags: ["Image"]
+  /build:
+    post:
+      summary: "Build an image"
+      description: |
+        Build an image from a tar archive with a `Dockerfile` in it.
+
+        The `Dockerfile` specifies how the image is built from the tar archive. It is typically in the archive's root, but can be at a different path or have a different name by specifying the `dockerfile` parameter. [See the `Dockerfile` reference for more information](https://docs.docker.com/engine/reference/builder/).
+
+        The Docker daemon performs a preliminary validation of the `Dockerfile` before starting the build, and returns an error if the syntax is incorrect. After that, each instruction is run one-by-one until the ID of the new image is output.
+
+        The build is canceled if the client drops the connection by quitting or being killed.
+      operationId: "ImageBuild"
+      consumes:
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "inputStream"
+          in: "body"
+          description: "A tar archive compressed with one of the following algorithms: identity (no compression), gzip, bzip2, xz."
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "dockerfile"
+          in: "query"
+          description: "Path within the build context to the `Dockerfile`. This is ignored if `remote` is specified and points to an external `Dockerfile`."
+          type: "string"
+          default: "Dockerfile"
+        - name: "t"
+          in: "query"
+          description: "A name and optional tag to apply to the image in the `name:tag` format. If you omit the tag the default `latest` value is assumed. You can provide several `t` parameters."
+          type: "string"
+        - name: "extrahosts"
+          in: "query"
+          description: "Extra hosts to add to /etc/hosts"
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: "A Git repository URI or HTTP/HTTPS context URI. If the URI points to a single text file, the file’s contents are placed into a file called `Dockerfile` and the image is built from that file. If the URI points to a tarball, the file is downloaded by the daemon and the contents therein used as the context for the build. If the URI points to a tarball and the `dockerfile` parameter is also specified, there must be a file with the corresponding path inside the tarball."
+          type: "string"
+        - name: "q"
+          in: "query"
+          description: "Suppress verbose build output."
+          type: "boolean"
+          default: false
+        - name: "nocache"
+          in: "query"
+          description: "Do not use the cache when building the image."
+          type: "boolean"
+          default: false
+        - name: "cachefrom"
+          in: "query"
+          description: "JSON array of images used for build cache resolution."
+          type: "string"
+        - name: "pull"
+          in: "query"
+          description: "Attempt to pull the image even if an older image exists locally."
+          type: "string"
+        - name: "rm"
+          in: "query"
+          description: "Remove intermediate containers after a successful build."
+          type: "boolean"
+          default: true
+        - name: "forcerm"
+          in: "query"
+          description: "Always remove intermediate containers, even upon failure."
+          type: "boolean"
+          default: false
+        - name: "memory"
+          in: "query"
+          description: "Set memory limit for build."
+          type: "integer"
+        - name: "memswap"
+          in: "query"
+          description: "Total memory (memory + swap). Set as `-1` to disable swap."
+          type: "integer"
+        - name: "cpushares"
+          in: "query"
+          description: "CPU shares (relative weight)."
+          type: "integer"
+        - name: "cpusetcpus"
+          in: "query"
+          description: "CPUs in which to allow execution (e.g., `0-3`, `0,1`)."
+          type: "string"
+        - name: "cpuperiod"
+          in: "query"
+          description: "The length of a CPU period in microseconds."
+          type: "integer"
+        - name: "cpuquota"
+          in: "query"
+          description: "Microseconds of CPU time that the container can get in a CPU period."
+          type: "integer"
+        - name: "buildargs"
+          in: "query"
+          description: >
+            JSON map of string pairs for build-time variables. Users pass these values at build-time. Docker
+            uses the buildargs as the environment context for commands run via the `Dockerfile` RUN
+            instruction, or for variable expansion in other `Dockerfile` instructions. This is not meant for
+            passing secret values.
+
+
+            For example, the build arg `FOO=bar` would become `{"FOO":"bar"}` in JSON. This would result in the
+            query parameter `buildargs={"FOO":"bar"}`. Note that `{"FOO":"bar"}` should be URI component encoded.
+
+
+            [Read more about the buildargs instruction.](https://docs.docker.com/engine/reference/builder/#arg)
+          type: "string"
+        - name: "shmsize"
+          in: "query"
+          description: "Size of `/dev/shm` in bytes. The size must be greater than 0. If omitted the system uses 64MB."
+          type: "integer"
+        - name: "squash"
+          in: "query"
+          description: "Squash the resulting images layers into a single layer. *(Experimental release only.)*"
+          type: "boolean"
+        - name: "labels"
+          in: "query"
+          description: "Arbitrary key/value labels to set on the image, as a JSON map of string pairs."
+          type: "string"
+        - name: "networkmode"
+          in: "query"
+          description: |
+            Sets the networking mode for the run commands during build. Supported
+            standard values are: `bridge`, `host`, `none`, and `container:<name|id>`.
+            Any other value is taken as a custom network's name or ID to which this
+            container should connect to.
+          type: "string"
+        - name: "Content-type"
+          in: "header"
+          type: "string"
+          enum:
+            - "application/x-tar"
+          default: "application/x-tar"
+        - name: "X-Registry-Config"
+          in: "header"
+          description: |
+            This is a base64-encoded JSON object with auth configurations for multiple registries that a build may refer to.
+
+            The key is a registry URL, and the value is an auth configuration object, [as described in the authentication section](#section/Authentication). For example:
+
+            ```
+            {
+              "docker.example.com": {
+                "username": "janedoe",
+                "password": "hunter2"
+              },
+              "https://index.docker.io/v1/": {
+                "username": "mobydock",
+                "password": "conta1n3rize14"
+              }
+            }
+            ```
+
+            Only the registry domain name (and port if not the default 443) are required. However, for legacy reasons, the Docker Hub registry must be specified with both a `https://` prefix and a `/v1/` suffix even though Docker will prefer to use the v2 registry API.
+          type: "string"
+        - name: "platform"
+          in: "query"
+          description: "Platform in the format os[/arch[/variant]]"
+          type: "string"
+          default: ""
+        - name: "target"
+          in: "query"
+          description: "Target build stage"
+          type: "string"
+          default: ""
+        - name: "outputs"
+          in: "query"
+          description: |
+            BuildKit output configuration in the format of a stringified JSON array of objects.
+            Each object must have two top-level properties: `Type` and `Attrs`.
+            The `Type` property must be set to 'moby'.
+            The `Attrs` property is a map of attributes for the BuildKit output configuration.
+            See https://docs.docker.com/build/exporters/oci-docker/ for more information.
+
+            Example:
+
+            ```
+            [{"Type":"moby","Attrs":{"type":"image","force-compression":"true","compression":"zstd"}}]
+            ```
+          type: "string"
+          default: ""
+        - name: "version"
+          in: "query"
+          type: "string"
+          default: "1"
+          enum: ["1", "2"]
+          description: |
+            Version of the builder backend to use.
+
+            - `1` is the first generation classic (deprecated) builder in the Docker daemon (default)
+            - `2` is [BuildKit](https://github.com/moby/buildkit)
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /build/prune:
+    post:
+      summary: "Delete builder cache"
+      produces:
+        - "application/json"
+      operationId: "BuildPrune"
+      parameters:
+        - name: "reserved-space"
+          in: "query"
+          description: "Amount of disk space in bytes to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "max-used-space"
+          in: "query"
+          description: "Maximum amount of disk space allowed to keep for cache"
+          type: "integer"
+          format: "int64"
+        - name: "min-free-space"
+          in: "query"
+          description: "Target amount of free disk space after pruning"
+          type: "integer"
+          format: "int64"
+        - name: "all"
+          in: "query"
+          type: "boolean"
+          description: "Remove all types of build cache"
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the list of build cache objects.
+
+            Available filters:
+
+            - `until=<timestamp>` remove cache older than `<timestamp>`. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon's local time.
+            - `id=<id>`
+            - `parent=<id>`
+            - `type=<string>`
+            - `description=<string>`
+            - `inuse`
+            - `shared`
+            - `private`
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "BuildPruneResponse"
+            properties:
+              CachesDeleted:
+                type: "array"
+                items:
+                  description: "ID of build cache object"
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /images/create:
+    post:
+      summary: "Create an image"
+      description: "Pull or import an image."
+      operationId: "ImageCreate"
+      consumes:
+        - "text/plain"
+        - "application/octet-stream"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "repository does not exist or no read access"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "fromImage"
+          in: "query"
+          description: |
+            Name of the image to pull. If the name includes a tag or digest, specific behavior applies:
+
+            - If only `fromImage` includes a tag, that tag is used.
+            - If both `fromImage` and `tag` are provided, `tag` takes precedence.
+            - If `fromImage` includes a digest, the image is pulled by digest, and `tag` is ignored.
+            - If neither a tag nor digest is specified, all tags are pulled.
+          type: "string"
+        - name: "fromSrc"
+          in: "query"
+          description: "Source to import. The value may be a URL from which the image can be retrieved or `-` to read the image from the request body. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name given to an image when it is imported. The repo may include a tag. This parameter may only be used when importing an image."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag or digest. If empty when pulling an image, this causes all tags for the given image to be pulled."
+          type: "string"
+        - name: "message"
+          in: "query"
+          description: "Set commit message for imported image."
+          type: "string"
+        - name: "inputImage"
+          in: "body"
+          description: "Image content if the value `-` has been specified in fromSrc query parameter"
+          schema:
+            type: "string"
+          required: false
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "changes"
+          in: "query"
+          description: |
+            Apply `Dockerfile` instructions to the image that is created,
+            for example: `changes=ENV DEBUG=true`.
+            Note that `ENV DEBUG=true` should be URI component encoded.
+
+            Supported `Dockerfile` instructions:
+            `CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          in: "query"
+          description: |
+            Platform in the format os[/arch[/variant]].
+
+            When used in combination with the `fromImage` option, the daemon checks
+            if the given image is present in the local image cache with the given
+            OS and Architecture, and otherwise attempts to pull the image. If the
+            option is not set, the host's native OS and Architecture are used.
+            If the given image does not exist in the local image cache, the daemon
+            attempts to pull the image with the host's native OS and Architecture.
+            If the given image does exists in the local image cache, but its OS or
+            architecture does not match, a warning is produced.
+
+            When used with the `fromSrc` option to import an image from an archive,
+            this option sets the platform information for the imported image. If
+            the option is not set, the host's native OS and Architecture are used
+            for the imported image.
+          type: "string"
+          default: ""
+      tags: ["Image"]
+  /images/{name}/json:
+    get:
+      summary: "Inspect an image"
+      description: "Return low-level information about an image."
+      operationId: "ImageInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/ImageInspect"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+        - name: "manifests"
+          in: "query"
+          description: |-
+            Include Manifests in the image summary.
+
+            The `manifests` and `platform` options are mutually exclusive, and
+            an error is produced if both are set.
+          type: "boolean"
+          default: false
+          required: false
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |-
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show inspect. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            The `platform` and `manifests` options are mutually exclusive, and
+            an error is produced if both are set.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/attestations:
+    get:
+      summary: "Get attestation statements for an image"
+      description: |
+        Return the in-toto attestation statements attached to the image for the
+        given platform. The daemon locates the attestation manifest(s) that
+        reference the matching platform image manifest, reads their statement
+        layers, and returns the verbatim statement JSON together with layer
+        metadata.
+
+        If the image has no attestations an empty array is returned.
+      operationId: "ImageAttestations"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/AttestationStatement"
+        400:
+          description: "Bad parameter (e.g. malformed `platform` value)"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such image, or no manifest found for the requested platform"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        501:
+          description: |
+            The daemon's image backend does not support attestations. This
+            is returned by the legacy (graphdriver) image store, which does
+            not preserve OCI image indexes.
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |-
+            JSON-encoded OCI platform to select the image variant whose
+            attestations to return.
+            If omitted, the daemon's default (host) platform is used.
+
+            Only one platform value is currently accepted; passing more than
+            one returns an error. The parameter is declared as an array so the
+            wire shape can accept multiple values in the future without an
+            API version bump.
+
+            Example: `{"os": "linux", "architecture": "amd64"}`
+          required: false
+        - name: "type"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |-
+            In-toto predicate type URI to filter returned statements. May be
+            repeated to accept any of several predicate types. If omitted, all
+            statements are returned.
+
+            Example: `type=https://slsa.dev/provenance/v0.2&type=https://spdx.dev/Document`
+          required: false
+        - name: "statement"
+          type: "boolean"
+          in: "query"
+          description: |-
+            Include the verbatim in-toto statement body in each returned
+            entry. Defaults to false; when omitted or false, only the
+            descriptor and predicate type are returned and statement blobs
+            are not read.
+          default: false
+          required: false
+      tags: ["Image"]
+  /images/{name}/history:
+    get:
+      summary: "Get the history of an image"
+      description: "Return parent layers of an image."
+      operationId: "ImageHistory"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "List of image layers"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageHistoryResponseItem"
+          examples:
+            application/json:
+              - Id: "3db9c44f45209632d6050b35958829c3a2aa256d81b9a7be45b362ff85c54710"
+                Created: 1398108230
+                CreatedBy: "/bin/sh -c #(nop) ADD file:eb15dbd63394e063b805a3c32ca7bf0266ef64676d5a6fab4801f2e81e2a5148 in /"
+                Tags:
+                  - "ubuntu:lucid"
+                  - "ubuntu:10.04"
+                Size: 182964289
+                Comment: ""
+              - Id: "6cfa4d1f33fb861d4d114f43b25abd0ac737509268065cdfd69d544a59c85ab8"
+                Created: 1398108222
+                CreatedBy: "/bin/sh -c #(nop) MAINTAINER Tianon Gravi <admwiggin@gmail.com> - mkimage-debootstrap.sh -i iproute,iputils-ping,ubuntu-minimal -t lucid.tar.xz lucid http://archive.ubuntu.com/ubuntu/"
+                Tags: []
+                Size: 0
+                Comment: ""
+              - Id: "511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158"
+                Created: 1371157430
+                CreatedBy: ""
+                Tags:
+                  - "scratch12:latest"
+                  - "scratch:latest"
+                Size: 0
+                Comment: "Imported from -"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant.
+            If omitted, it defaults to any locally available platform,
+            prioritizing the daemon's host platform.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to show the history for. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/{name}/push:
+    post:
+      summary: "Push an image"
+      description: |
+        Push an image to a registry.
+
+        If you wish to push an image on to a private registry, that image must
+        already have a tag which references the registry. For example,
+        `registry.example.com/myimage:latest`.
+
+        The push is cancelled if the HTTP connection is closed.
+      operationId: "ImagePush"
+      consumes:
+        - "application/octet-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            Name of the image to push. For example, `registry.example.com/myimage`.
+            The image must be present in the local image store with the same name.
+
+            The name should be provided without tag; if a tag is provided, it
+            is ignored. For example, `registry.example.com/myimage:latest` is
+            considered equivalent to `registry.example.com/myimage`.
+
+            Use the `tag` parameter to specify the tag to push.
+          type: "string"
+          required: true
+        - name: "tag"
+          in: "query"
+          description: |
+            Tag of the image to push. For example, `latest`. If no tag is provided,
+            all tags of the given image that are present in the local image store
+            are pushed.
+          type: "string"
+        - name: "platform"
+          type: "string"
+          in: "query"
+          description: |
+            JSON-encoded OCI platform to select the platform-variant to push.
+            If not provided, all available variants will attempt to be pushed.
+
+            If the daemon provides a multi-platform image store, this selects
+            the platform-variant to push to the registry. If the image is
+            a single-platform image, or if the multi-platform image does not
+            provide a variant matching the given platform, an error is returned.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+          required: true
+      tags: ["Image"]
+  /images/{name}/tag:
+    post:
+      summary: "Tag an image"
+      description: |
+        Create a tag that refers to a source image.
+
+        This creates an additional reference (tag) to the source image. The tag
+        can include a different repository name and/or tag. If the repository
+        or tag already exists, it will be overwritten.
+      operationId: "ImageTag"
+      responses:
+        201:
+          description: "No error"
+        400:
+          description: "Bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID to tag."
+          type: "string"
+          required: true
+        - name: "repo"
+          in: "query"
+          description: "The repository to tag in. For example, `someuser/someimage`."
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "The name of the new tag."
+          type: "string"
+      tags: ["Image"]
+  /images/{name}:
+    delete:
+      summary: "Remove an image"
+      description: |
+        Remove an image, along with any untagged parent images that were
+        referenced by that image.
+
+        Images can't be removed if they have descendant images, are being
+        used by a running container or are being used by a build.
+      operationId: "ImageDelete"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "The image was deleted successfully"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/ImageDeleteResponseItem"
+          examples:
+            application/json:
+              - Untagged: "3e2f21a89f"
+              - Deleted: "3e2f21a89f"
+              - Deleted: "53b4f83ac9"
+        404:
+          description: "No such image"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Conflict"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Remove the image even if it is being used by stopped containers or has other tags"
+          type: "boolean"
+          default: false
+        - name: "noprune"
+          in: "query"
+          description: "Do not delete untagged parent images"
+          type: "boolean"
+          default: false
+        - name: "platforms"
+          in: "query"
+          description: |
+            Select platform-specific content to delete.
+            Multiple values are accepted.
+            Each platform is a OCI platform encoded as a JSON string.
+          type: "array"
+          items:
+            # This should be OCIPlatform
+            # but $ref is not supported for array in query in Swagger 2.0
+            # $ref: "#/definitions/OCIPlatform"
+            type: "string"
+      tags: ["Image"]
+  /images/search:
+    get:
+      summary: "Search images"
+      description: "Search for an image on Docker Hub."
+      operationId: "ImageSearch"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              type: "object"
+              title: "ImageSearchResponseItem"
+              properties:
+                description:
+                  type: "string"
+                is_official:
+                  type: "boolean"
+                is_automated:
+                  description: |
+                    Whether this repository has automated builds enabled.
+
+                    <p><br /></p>
+
+                    > **Deprecated**: This field is deprecated and will always be "false".
+                  type: "boolean"
+                  example: false
+                name:
+                  type: "string"
+                star_count:
+                  type: "integer"
+          examples:
+            application/json:
+              - description: "A minimal Docker image based on Alpine Linux with a complete package index and only 5 MB in size!"
+                is_official: true
+                is_automated: false
+                name: "alpine"
+                star_count: 10093
+              - description: "Busybox base image."
+                is_official: true
+                is_automated: false
+                name: "Busybox base image."
+                star_count: 3037
+              - description: "The PostgreSQL object-relational database system provides reliability and data integrity."
+                is_official: true
+                is_automated: false
+                name: "postgres"
+                star_count: 12408
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "term"
+          in: "query"
+          description: "Term to search"
+          type: "string"
+          required: true
+        - name: "limit"
+          in: "query"
+          description: "Maximum number of results to return"
+          type: "integer"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to process on the images list. Available filters:
+
+            - `is-official=(true|false)`
+            - `stars=<number>` Matches images that has at least 'number' stars.
+          type: "string"
+      tags: ["Image"]
+  /images/prune:
+    post:
+      summary: "Delete unused images"
+      produces:
+        - "application/json"
+      operationId: "ImagePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`). Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), prune only
+               unused *and* untagged images. When set to `false`
+               (or `0`), all unused images are pruned.
+            - `until=<string>` Prune images created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune images with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ImagePruneResponse"
+            properties:
+              ImagesDeleted:
+                description: "Images that were deleted"
+                type: "array"
+                items:
+                  $ref: "#/definitions/ImageDeleteResponseItem"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Image"]
+  /auth:
+    post:
+      summary: "Check auth configuration"
+      description: |
+        Validate credentials for a registry and, if available, get an identity
+        token for accessing the registry without password.
+      operationId: "SystemAuth"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "An identity token was generated successfully."
+          schema:
+            $ref: "#/definitions/AuthResponse"
+        204:
+          description: "No error"
+        401:
+          description: "Auth error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "authConfig"
+          in: "body"
+          description: "Authentication to check"
+          schema:
+            $ref: "#/definitions/AuthConfig"
+      tags: ["System"]
+  /info:
+    get:
+      summary: "Get system information"
+      operationId: "SystemInfo"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/SystemInfo"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /version:
+    get:
+      summary: "Get version"
+      description: "Returns the version of Docker that is running and various information about the system that Docker is running on."
+      operationId: "SystemVersion"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/SystemVersion"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /_ping:
+    get:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPing"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "OK"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: |
+                Default version of docker image builder
+
+                The default on Linux is version "2" (BuildKit), but the daemon
+                can be configured to recommend version "1" (classic Builder).
+                Windows does not yet support BuildKit for native Windows images,
+                and uses "1" (classic builder) as a default.
+
+                This value is a recommendation as advertised by the daemon, and
+                it is up to the client to choose which builder to use.
+              default: "2"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          headers:
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+      tags: ["System"]
+    head:
+      summary: "Ping"
+      description: "This is a dummy endpoint you can use to test if the server is accessible."
+      operationId: "SystemPingHead"
+      produces: ["text/plain"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            example: "(empty)"
+          headers:
+            Api-Version:
+              type: "string"
+              description: "Max API Version the server supports"
+            Builder-Version:
+              type: "string"
+              description: "Default version of docker image builder"
+            Docker-Experimental:
+              type: "boolean"
+              description: "If the server is running with experimental mode enabled"
+            Swarm:
+              type: "string"
+              enum: ["inactive", "pending", "error", "locked", "active/worker", "active/manager"]
+              description: |
+                Contains information about Swarm status of the daemon,
+                and if the daemon is acting as a manager or worker node.
+              default: "inactive"
+            Cache-Control:
+              type: "string"
+              default: "no-cache, no-store, must-revalidate"
+            Pragma:
+              type: "string"
+              default: "no-cache"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["System"]
+  /commit:
+    post:
+      summary: "Create a new image from a container"
+      operationId: "ImageCommit"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "containerConfig"
+          in: "body"
+          description: "The container configuration"
+          schema:
+            $ref: "#/definitions/ContainerConfig"
+        - name: "container"
+          in: "query"
+          description: "The ID or name of the container to commit"
+          type: "string"
+        - name: "repo"
+          in: "query"
+          description: "Repository name for the created image"
+          type: "string"
+        - name: "tag"
+          in: "query"
+          description: "Tag name for the create image"
+          type: "string"
+        - name: "comment"
+          in: "query"
+          description: "Commit message"
+          type: "string"
+        - name: "author"
+          in: "query"
+          description: "Author of the image (e.g., `John Hannibal Smith <hannibal@a-team.com>`)"
+          type: "string"
+        - name: "pause"
+          in: "query"
+          description: "Whether to pause the container before committing"
+          type: "boolean"
+          default: true
+        - name: "changes"
+          in: "query"
+          description: "`Dockerfile` instructions to apply while committing"
+          type: "string"
+      tags: ["Image"]
+  /events:
+    get:
+      summary: "Monitor events"
+      description: |
+        Stream real-time events from the server.
+
+        Various objects within Docker report events when something happens to them.
+
+        Containers report these events: `attach`, `commit`, `copy`, `create`, `destroy`, `detach`, `die`, `exec_create`, `exec_detach`, `exec_start`, `exec_die`, `export`, `health_status`, `kill`, `oom`, `pause`, `rename`, `resize`, `restart`, `start`, `stop`, `top`, `unpause`, `update`, and `prune`
+
+        Images report these events: `create`, `delete`, `import`, `load`, `pull`, `push`, `save`, `tag`, `untag`, and `prune`
+
+        Volumes report these events: `create`, `mount`, `unmount`, `destroy`, and `prune`
+
+        Networks report these events: `create`, `connect`, `disconnect`, `destroy`, `update`, `remove`, and `prune`
+
+        The Docker daemon reports these events: `reload`
+
+        Services report these events: `create`, `update`, and `remove`
+
+        Nodes report these events: `create`, `update`, and `remove`
+
+        Secrets report these events: `create`, `update`, and `remove`
+
+        Configs report these events: `create`, `update`, and `remove`
+
+        The Builder reports `prune` events
+
+      operationId: "SystemEvents"
+      produces:
+        - "application/jsonl"
+        - "application/x-ndjson"
+        - "application/json-seq"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/EventMessage"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "since"
+          in: "query"
+          description: "Show events created since this timestamp then stream new events."
+          type: "string"
+        - name: "until"
+          in: "query"
+          description: "Show events created until this timestamp then stop streaming."
+          type: "string"
+        - name: "filters"
+          in: "query"
+          description: |
+            A JSON encoded value of filters (a `map[string][]string`) to process on the event list. Available filters:
+
+            - `config=<string>` config name or ID
+            - `container=<string>` container name or ID
+            - `daemon=<string>` daemon name or ID
+            - `event=<string>` event type
+            - `image=<string>` image name or ID
+            - `label=<string>` image or container label
+            - `network=<string>` network name or ID
+            - `node=<string>` node ID
+            - `plugin`=<string> plugin name or ID
+            - `scope`=<string> local or swarm
+            - `secret=<string>` secret name or ID
+            - `service=<string>` service name or ID
+            - `type=<string>` object to filter by, one of `container`, `image`, `volume`, `network`, `daemon`, `plugin`, `node`, `service`, `secret` or `config`
+            - `volume=<string>` volume name
+          type: "string"
+      tags: ["System"]
+  /system/df:
+    get:
+      summary: "Get data usage information"
+      operationId: "SystemDataUsage"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "SystemDataUsageResponse"
+            properties:
+              ImageUsage:
+                $ref: "#/definitions/ImagesDiskUsage"
+              ContainerUsage:
+                $ref: "#/definitions/ContainersDiskUsage"
+              VolumeUsage:
+                $ref: "#/definitions/VolumesDiskUsage"
+              BuildCacheUsage:
+                $ref: "#/definitions/BuildCacheDiskUsage"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "type"
+          in: "query"
+          description: |
+            Object types, for which to compute and return data.
+          type: "array"
+          collectionFormat: multi
+          items:
+            type: "string"
+            enum: ["container", "image", "volume", "build-cache"]
+        - name: "verbose"
+          in: "query"
+          description: |
+            Show detailed information on space usage.
+          type: "boolean"
+          default: false
+      tags: ["System"]
+  /images/{name}/get:
+    get:
+      summary: "Export an image"
+      description: |
+        Get a tarball containing all images and metadata for a repository.
+
+        If `name` is a specific name and tag (e.g. `ubuntu:latest`), then only that image (and its parents) are returned. If `name` is an image ID, similarly only that image (and its parents) are returned, but with the exclusion of the `repositories` file in the tarball, as there were no image names referenced.
+
+        ### Image tarball format
+
+        An image tarball contains [Content as defined in the OCI Image Layout Specification](https://github.com/opencontainers/image-spec/blob/v1.1.1/image-layout.md#content).
+
+        Additionally, includes the manifest.json file associated with a backwards compatible docker save format.
+
+        If the tarball defines a repository, the tarball should also include a `repositories` file at the root that contains a list of repository and tag names mapped to layer IDs.
+
+        ```json
+        {
+          "hello-world": {
+            "latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"
+          }
+        }
+        ```
+      operationId: "ImageGet"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or ID"
+          type: "string"
+          required: true
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform describing a platform which will be used
+            to select a platform-specific image to be saved if the image is
+            multi-platform.
+            If not provided, the full multi-platform image will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/get:
+    get:
+      summary: "Export several images"
+      description: |
+        Get a tarball containing all images and metadata for several image
+        repositories.
+
+        For each value of the `names` parameter: if it is a specific name and
+        tag (e.g. `ubuntu:latest`), then only that image (and its parents) are
+        returned; if it is an image ID, similarly only that image (and its parents)
+        are returned and there would be no names referenced in the 'repositories'
+        file for this image ID.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageGetAll"
+      produces:
+        - "application/x-tar"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "string"
+            format: "binary"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "names"
+          in: "query"
+          description: "Image names to filter by"
+          type: "array"
+          items:
+            type: "string"
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform(s) which will be used to select the
+            platform-specific image(s) to be saved if the image is
+            multi-platform. If not provided, the full multi-platform image
+            will be saved.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /images/load:
+    post:
+      summary: "Import images"
+      description: |
+        Load a set of images and tags into a repository.
+
+        For details on the format, see the [export image endpoint](#operation/ImageGet).
+      operationId: "ImageLoad"
+      consumes:
+        - "application/x-tar"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "imagesTarball"
+          in: "body"
+          description: "Tar archive containing images"
+          schema:
+            type: "string"
+            format: "binary"
+        - name: "quiet"
+          in: "query"
+          description: "Suppress progress details during load."
+          type: "boolean"
+          default: false
+        - name: "platform"
+          type: "array"
+          items:
+            type: "string"
+          collectionFormat: "multi"
+          in: "query"
+          description: |
+            JSON encoded OCI platform(s) which will be used to select the
+            platform-specific image(s) to load if the image is
+            multi-platform. If not provided, the full multi-platform image
+            will be loaded.
+
+            Example: `{"os": "linux", "architecture": "arm", "variant": "v5"}`
+      tags: ["Image"]
+  /containers/{id}/exec:
+    post:
+      summary: "Create an exec instance"
+      description: "Run a command inside a running container."
+      operationId: "ContainerExec"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        404:
+          description: "no such container"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such container: c2ada9df5af8"
+        409:
+          description: "container is paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execConfig"
+          in: "body"
+          description: "Exec configuration"
+          schema:
+            type: "object"
+            title: "ExecConfig"
+            properties:
+              AttachStdin:
+                type: "boolean"
+                description: "Attach to `stdin` of the exec command."
+              AttachStdout:
+                type: "boolean"
+                description: "Attach to `stdout` of the exec command."
+              AttachStderr:
+                type: "boolean"
+                description: "Attach to `stderr` of the exec command."
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+              DetachKeys:
+                type: "string"
+                description: |
+                  Override the key sequence for detaching a container. Format is
+                  a single character `[a-Z]` or `ctrl-<value>` where `<value>`
+                  is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+              Env:
+                description: |
+                  A list of environment variables in the form `["VAR=value", ...]`.
+                type: "array"
+                items:
+                  type: "string"
+              Cmd:
+                type: "array"
+                description: "Command to run, as a string or array of strings."
+                items:
+                  type: "string"
+              Privileged:
+                type: "boolean"
+                description: "Runs the exec process with extended privileges."
+                default: false
+              User:
+                type: "string"
+                description: |
+                  The user, and optionally, group to run the exec process inside
+                  the container. Format is one of: `user`, `user:group`, `uid`,
+                  or `uid:gid`.
+              WorkingDir:
+                type: "string"
+                description: |
+                  The working directory for the exec process inside the container.
+            example:
+              AttachStdin: false
+              AttachStdout: true
+              AttachStderr: true
+              DetachKeys: "ctrl-p,ctrl-q"
+              Tty: false
+              Cmd:
+                - "date"
+              Env:
+                - "FOO=bar"
+                - "BAZ=quux"
+          required: true
+        - name: "id"
+          in: "path"
+          description: "ID or name of container"
+          type: "string"
+          required: true
+      tags: ["Exec"]
+  /exec/{id}/start:
+    post:
+      summary: "Start an exec instance"
+      description: |
+        Starts a previously set up exec instance. If detach is true, this endpoint
+        returns immediately after starting the command. Otherwise, it sets up an
+        interactive session with the command.
+      operationId: "ExecStart"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "No error"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Container is stopped or paused"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "execStartConfig"
+          in: "body"
+          schema:
+            type: "object"
+            title: "ExecStartConfig"
+            properties:
+              Detach:
+                type: "boolean"
+                description: "Detach from the command."
+                example: false
+              Tty:
+                type: "boolean"
+                description: "Allocate a pseudo-TTY."
+                example: true
+              ConsoleSize:
+                type: "array"
+                description: "Initial console size, as an `[height, width]` array."
+                x-nullable: true
+                minItems: 2
+                maxItems: 2
+                items:
+                  type: "integer"
+                  minimum: 0
+                example: [80, 64]
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+  /exec/{id}/resize:
+    post:
+      summary: "Resize an exec instance"
+      description: |
+        Resize the TTY session used by an exec instance. This endpoint only works
+        if `tty` was specified as part of creating and starting the exec instance.
+      operationId: "ExecResize"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+        - name: "h"
+          in: "query"
+          required: true
+          description: "Height of the TTY session in characters"
+          type: "integer"
+        - name: "w"
+          in: "query"
+          required: true
+          description: "Width of the TTY session in characters"
+          type: "integer"
+      tags: ["Exec"]
+  /exec/{id}/json:
+    get:
+      summary: "Inspect an exec instance"
+      description: "Return low-level information about an exec instance."
+      operationId: "ExecInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "ExecInspectResponse"
+            properties:
+              CanRemove:
+                type: "boolean"
+              DetachKeys:
+                type: "string"
+              ID:
+                type: "string"
+              Running:
+                type: "boolean"
+              ExitCode:
+                type: "integer"
+              ProcessConfig:
+                $ref: "#/definitions/ProcessConfig"
+              OpenStdin:
+                type: "boolean"
+              OpenStderr:
+                type: "boolean"
+              OpenStdout:
+                type: "boolean"
+              ContainerID:
+                type: "string"
+              Pid:
+                type: "integer"
+                description: "The system process ID for the exec process."
+          examples:
+            application/json:
+              CanRemove: false
+              ContainerID: "b53ee82b53a40c7dca428523e34f741f3abc51d9f297a14ff874bf761b995126"
+              DetachKeys: ""
+              ExitCode: 2
+              ID: "f33bbfb39f5b142420f4759b2348913bd4a8d1a6d7fd56499cb41a1bb91d7b3b"
+              OpenStderr: true
+              OpenStdin: true
+              OpenStdout: true
+              ProcessConfig:
+                arguments:
+                  - "-c"
+                  - "exit 2"
+                entrypoint: "sh"
+                privileged: false
+                tty: true
+                user: "1000"
+              Running: false
+              Pid: 42000
+        404:
+          description: "No such exec instance"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Exec instance ID"
+          required: true
+          type: "string"
+      tags: ["Exec"]
+
+  /volumes:
+    get:
+      summary: "List volumes"
+      operationId: "VolumeList"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "Summary volume data that matches the query"
+          schema:
+            $ref: "#/definitions/VolumeListResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to
+            process on the volumes list. Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               volumes that are not in use by a container. When set to `false`
+               (or `0`), only volumes that are in use by one or more
+               containers are returned.
+            - `driver=<volume-driver-name>` Matches volumes based on their driver.
+            - `label=<key>` or `label=<key>:<value>` Matches volumes based on
+               the presence of a `label` alone or a `label` and a value.
+            - `name=<volume-name>` Matches all or part of a volume name.
+          type: "string"
+          format: "json"
+      tags: ["Volume"]
+
+  /volumes/create:
+    post:
+      summary: "Create a volume"
+      operationId: "VolumeCreate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        201:
+          description: "The volume was created successfully"
+          schema:
+            $ref: "#/definitions/Volume"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "volumeConfig"
+          in: "body"
+          required: true
+          description: "Volume configuration"
+          schema:
+            $ref: "#/definitions/VolumeCreateRequest"
+      tags: ["Volume"]
+
+  /volumes/{name}:
+    get:
+      summary: "Inspect a volume"
+      operationId: "VolumeInspect"
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/Volume"
+        404:
+          description: "No such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+      tags: ["Volume"]
+
+    put:
+      summary: |
+        "Update a volume. Valid only for Swarm cluster volumes"
+      operationId: "VolumeUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such volume"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "The name or ID of the volume"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            # though the schema for is an object that contains only a
+            # ClusterVolumeSpec, wrapping the ClusterVolumeSpec in this object
+            # means that if, later on, we support things like changing the
+            # labels, we can do so without duplicating that information to the
+            # ClusterVolumeSpec.
+            type: "object"
+            description: "Volume configuration"
+            properties:
+              Spec:
+                $ref: "#/definitions/ClusterVolumeSpec"
+          description: |
+            The spec of the volume to update. Currently, only Availability may
+            change. All other fields must remain unchanged.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the volume being updated. This is required to
+            avoid conflicting writes. Found in the volume's `ClusterVolume`
+            field.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Volume"]
+
+    delete:
+      summary: "Remove a volume"
+      description: "Instruct the driver to remove the volume."
+      operationId: "VolumeDelete"
+      responses:
+        204:
+          description: "The volume was removed"
+        404:
+          description: "No such volume or volume driver"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "Volume is in use and cannot be removed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          required: true
+          description: "Volume name or ID"
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: "Force the removal of the volume"
+          type: "boolean"
+          default: false
+      tags: ["Volume"]
+
+  /volumes/prune:
+    post:
+      summary: "Delete unused volumes"
+      produces:
+        - "application/json"
+      operationId: "VolumePrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune volumes with (or without, in case `label!=...` is used) the specified labels.
+            - `all` (`all=true`) - Consider all (local) volumes for pruning and not just anonymous volumes.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "VolumePruneResponse"
+            properties:
+              VolumesDeleted:
+                description: "Volumes that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+              SpaceReclaimed:
+                description: "Disk space reclaimed in bytes"
+                type: "integer"
+                format: "int64"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Volume"]
+  /networks:
+    get:
+      summary: "List networks"
+      description: |
+        Returns a list of networks. For details on the format, see the
+        [network inspect endpoint](#operation/NetworkInspect).
+
+        Note that it uses a different, smaller representation of a network than
+        inspecting a single network. For example, the list of containers attached
+        to the network is not propagated in API versions 1.28 and up.
+      operationId: "NetworkList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/NetworkSummary"
+          examples:
+            application/json:
+              - Name: "bridge"
+                Id: "f2de39df4171b0dc801e8002d1d999b77256983dfc63041c0f34030aa3977566"
+                Created: "2016-10-19T06:21:00.416543526Z"
+                Scope: "local"
+                Driver: "bridge"
+                EnableIPv4: true
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config:
+                    -
+                      Subnet: "172.17.0.0/16"
+                Options:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              - Name: "none"
+                Id: "e086a3893b05ab69242d3c44e49483a3bbbd3a26b46baa8f61ab797c1088d794"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "null"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+              - Name: "host"
+                Id: "13e871235c677f196c4e1ecebb9dc733b9b2d2ab589e30c539efeda84a24215e"
+                Created: "0001-01-01T00:00:00Z"
+                Scope: "local"
+                Driver: "host"
+                EnableIPv4: false
+                EnableIPv6: false
+                Internal: false
+                Attachable: false
+                Ingress: false
+                IPAM:
+                  Driver: "default"
+                  Config: []
+                Containers: {}
+                Options: {}
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            JSON encoded value of the filters (a `map[string][]string`) to process
+            on the networks list.
+
+            Available filters:
+
+            - `dangling=<boolean>` When set to `true` (or `1`), returns all
+               networks that are not in use by a container. When set to `false`
+               (or `0`), only networks that are in use by one or more
+               containers are returned.
+            - `driver=<driver-name>` Matches a network's driver.
+            - `id=<network-id>` Matches all or part of a network ID.
+            - `label=<key>` or `label=<key>=<value>` of a network label.
+            - `name=<network-name>` Matches all or part of a network name.
+            - `scope=["swarm"|"global"|"local"]` Filters networks by scope (`swarm`, `global`, or `local`).
+            - `type=["custom"|"builtin"]` Filters networks by type. The `custom` keyword returns all user-defined networks.
+          type: "string"
+      tags: ["Network"]
+
+  /networks/{id}:
+    get:
+      summary: "Inspect a network"
+      operationId: "NetworkInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            $ref: "#/definitions/NetworkInspect"
+        404:
+          description: "Network not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "verbose"
+          in: "query"
+          description: "Detailed inspect output for troubleshooting"
+          type: "boolean"
+          default: false
+        - name: "scope"
+          in: "query"
+          description: "Filter the network by scope (swarm, global, or local)"
+          type: "string"
+      tags: ["Network"]
+
+    delete:
+      summary: "Remove a network"
+      operationId: "NetworkDelete"
+      responses:
+        204:
+          description: "No error"
+        403:
+          description: "operation not supported for pre-defined networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such network"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+      tags: ["Network"]
+
+  /networks/create:
+    post:
+      summary: "Create a network"
+      operationId: "NetworkCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "Network created successfully"
+          schema:
+            $ref: "#/definitions/NetworkCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: |
+            Forbidden operation. This happens when trying to create a network named after a pre-defined network,
+            or when trying to create an overlay network on a daemon which is not part of a Swarm cluster.
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "plugin not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "networkConfig"
+          in: "body"
+          description: "Network configuration"
+          required: true
+          schema:
+            type: "object"
+            title: "NetworkCreateRequest"
+            required: ["Name"]
+            properties:
+              Name:
+                description: "The network's name."
+                type: "string"
+                example: "my_network"
+              Driver:
+                description: "Name of the network driver plugin to use."
+                type: "string"
+                default: "bridge"
+                example: "bridge"
+              Scope:
+                description: |
+                  The level at which the network exists (e.g. `swarm` for cluster-wide
+                  or `local` for machine level).
+                type: "string"
+              Internal:
+                description: "Restrict external access to the network."
+                type: "boolean"
+              Attachable:
+                description: |
+                  Globally scoped network is manually attachable by regular
+                  containers from workers in swarm mode.
+                type: "boolean"
+                example: true
+              Ingress:
+                description: |
+                  Ingress network is the network which provides the routing-mesh
+                  in swarm mode.
+                type: "boolean"
+                example: false
+              ConfigOnly:
+                description: |
+                  Creates a config-only network. Config-only networks are placeholder
+                  networks for network configurations to be used by other networks.
+                  Config-only networks cannot be used directly to run containers
+                  or services.
+                type: "boolean"
+                default: false
+                example: false
+              ConfigFrom:
+                description: |
+                  Specifies the source which will provide the configuration for
+                  this network. The specified network must be an existing
+                  config-only network; see ConfigOnly.
+                $ref: "#/definitions/ConfigReference"
+              IPAM:
+                description: "Optional custom IP scheme for the network."
+                $ref: "#/definitions/IPAM"
+              EnableIPv4:
+                description: "Enable IPv4 on the network."
+                type: "boolean"
+                example: true
+              EnableIPv6:
+                description: "Enable IPv6 on the network."
+                type: "boolean"
+                example: true
+              Options:
+                description: "Network specific options to be used by the drivers."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.docker.network.bridge.default_bridge: "true"
+                  com.docker.network.bridge.enable_icc: "true"
+                  com.docker.network.bridge.enable_ip_masquerade: "true"
+                  com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
+                  com.docker.network.bridge.name: "docker0"
+                  com.docker.network.driver.mtu: "1500"
+              Labels:
+                description: "User-defined key/value metadata."
+                type: "object"
+                additionalProperties:
+                  type: "string"
+                example:
+                  com.example.some-label: "some-value"
+                  com.example.some-other-label: "some-other-value"
+      tags: ["Network"]
+
+  /networks/{id}/connect:
+    post:
+      summary: "Connect a container to a network"
+      description: "The network must be either a local-scoped network or a swarm-scoped network with the `attachable` option set. A network cannot be re-attached to a running container"
+      operationId: "NetworkConnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "Operation forbidden"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/NetworkConnectRequest"
+      tags: ["Network"]
+
+  /networks/{id}/disconnect:
+    post:
+      summary: "Disconnect a container from a network"
+      operationId: "NetworkDisconnect"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "No error"
+        403:
+          description: "Operation not supported for swarm scoped networks"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "Network or container not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "Network ID or name"
+          required: true
+          type: "string"
+        - name: "container"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/NetworkDisconnectRequest"
+      tags: ["Network"]
+  /networks/prune:
+    post:
+      summary: "Delete unused networks"
+      produces:
+        - "application/json"
+      operationId: "NetworkPrune"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the prune list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `until=<timestamp>` Prune networks created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
+            - `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune networks with (or without, in case `label!=...` is used) the specified labels.
+          type: "string"
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "object"
+            title: "NetworkPruneResponse"
+            properties:
+              NetworksDeleted:
+                description: "Networks that were deleted"
+                type: "array"
+                items:
+                  type: "string"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Network"]
+  /plugins:
+    get:
+      summary: "List plugins"
+      operationId: "PluginList"
+      description: "Returns information about installed plugins."
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "No error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Plugin"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the plugin list.
+
+            Available filters:
+
+            - `capability=<capability name>`
+            - `enable=<true>|<false>`
+      tags: ["Plugin"]
+
+  /plugins/privileges:
+    get:
+      summary: "Get plugin privileges"
+      operationId: "GetPluginPrivileges"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags:
+        - "Plugin"
+
+  /plugins/pull:
+    post:
+      summary: "Install a plugin"
+      operationId: "PluginPull"
+      description: |
+        Pulls and installs a plugin. After the plugin is installed, it can be
+        enabled using the [`POST /plugins/{name}/enable` endpoint](#operation/PostPluginsEnable).
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference for plugin to install.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "name"
+          in: "query"
+          description: |
+            Local name for the pulled plugin.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: false
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/{name}/json:
+    get:
+      summary: "Inspect a plugin"
+      operationId: "PluginInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      tags: ["Plugin"]
+  /plugins/{name}:
+    delete:
+      summary: "Remove a plugin"
+      operationId: "PluginDelete"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Plugin"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Disable the plugin before removing. This may result in issues if the
+            plugin is in use by a container.
+          type: "boolean"
+          default: false
+      tags: ["Plugin"]
+  /plugins/{name}/enable:
+    post:
+      summary: "Enable a plugin"
+      operationId: "PluginEnable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "timeout"
+          in: "query"
+          description: "Set the HTTP client timeout (in seconds)"
+          type: "integer"
+          default: 0
+      tags: ["Plugin"]
+  /plugins/{name}/disable:
+    post:
+      summary: "Disable a plugin"
+      operationId: "PluginDisable"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin is not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "force"
+          in: "query"
+          description: |
+            Force disable a plugin even if still in use.
+          required: false
+          type: "boolean"
+      tags: ["Plugin"]
+  /plugins/{name}/upgrade:
+    post:
+      summary: "Upgrade a plugin"
+      operationId: "PluginUpgrade"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "remote"
+          in: "query"
+          description: |
+            Remote reference to upgrade to.
+
+            The `:latest` tag is optional, and is used as the default if omitted.
+          required: true
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration to use when pulling a plugin
+            from a registry.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/PluginPrivilege"
+            example:
+              - Name: "network"
+                Description: ""
+                Value:
+                  - "host"
+              - Name: "mount"
+                Description: ""
+                Value:
+                  - "/data"
+              - Name: "device"
+                Description: ""
+                Value:
+                  - "/dev/cpu_dma_latency"
+      tags: ["Plugin"]
+  /plugins/create:
+    post:
+      summary: "Create a plugin"
+      operationId: "PluginCreate"
+      consumes:
+        - "application/x-tar"
+      responses:
+        204:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "query"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "tarContext"
+          in: "body"
+          description: "Path to tar containing plugin rootfs and manifest"
+          schema:
+            type: "string"
+            format: "binary"
+      tags: ["Plugin"]
+  /plugins/{name}/push:
+    post:
+      summary: "Push a plugin"
+      operationId: "PluginPush"
+      description: |
+        Push a plugin to the registry.
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /plugins/{name}/set:
+    post:
+      summary: "Configure a plugin"
+      operationId: "PluginSet"
+      consumes:
+        - "application/json"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: |
+            The name of the plugin. The `:latest` tag is optional, and is the
+            default if omitted.
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          schema:
+            type: "array"
+            items:
+              type: "string"
+            example: ["DEBUG=1"]
+      responses:
+        204:
+          description: "No error"
+        404:
+          description: "Plugin not installed"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Plugin"]
+  /nodes:
+    get:
+      summary: "List nodes"
+      operationId: "NodeList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Node"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          description: |
+            Filters to process on the nodes list, encoded as JSON (a `map[string][]string`).
+
+            Available filters:
+            - `id=<node id>`
+            - `label=<engine label>`
+            - `membership=`(`accepted`|`pending`)`
+            - `name=<node name>`
+            - `node.label=<node label>`
+            - `role=`(`manager`|`worker`)`
+          type: "string"
+      tags: ["Node"]
+  /nodes/{id}:
+    get:
+      summary: "Inspect a node"
+      operationId: "NodeInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Node"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+      tags: ["Node"]
+    delete:
+      summary: "Delete a node"
+      operationId: "NodeDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the node"
+          type: "string"
+          required: true
+        - name: "force"
+          in: "query"
+          description: "Force remove a node from the swarm"
+          default: false
+          type: "boolean"
+      tags: ["Node"]
+  /nodes/{id}/update:
+    post:
+      summary: "Update a node"
+      operationId: "NodeUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such node"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID of the node"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/NodeSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the node object being updated. This is required
+            to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Node"]
+  /swarm:
+    get:
+      summary: "Inspect swarm"
+      operationId: "SwarmInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Swarm"
+        404:
+          description: "no such swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/init:
+    post:
+      summary: "Initialize a new swarm"
+      operationId: "SwarmInit"
+      produces:
+        - "application/json"
+        - "text/plain"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            description: "The node ID"
+            type: "string"
+            example: "7v2t30z9blmxuhnyo6s4cpenp"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmInitRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication, as well
+                  as determining the networking interface used for the VXLAN
+                  Tunnel Endpoint (VTEP). This can either be an address/port
+                  combination in the form `192.168.1.1:4567`, or an interface
+                  followed by a port number, like `eth0:4567`. If the port number
+                  is omitted, the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other  nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+                type: "string"
+              DataPathPort:
+                description: |
+                  DataPathPort specifies the data path port number for data traffic.
+                  Acceptable port range is 1024 to 49151.
+                  if no port is set or is set to 0, default port 4789 will be used.
+                type: "integer"
+                format: "uint32"
+              DefaultAddrPool:
+                description: |
+                  Default Address Pool specifies default subnet pools for global
+                  scope networks.
+                type: "array"
+                items:
+                  type: "string"
+                  example: ["10.10.0.0/16", "20.20.0.0/16"]
+              ForceNewCluster:
+                description: "Force creation of a new swarm."
+                type: "boolean"
+              SubnetSize:
+                description: |
+                  SubnetSize specifies the subnet size of the networks created
+                  from the default subnet pool.
+                type: "integer"
+                format: "uint32"
+              Spec:
+                $ref: "#/definitions/SwarmSpec"
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathPort: 4789
+              DefaultAddrPool: ["10.10.0.0/8", "20.20.0.0/8"]
+              SubnetSize: 24
+              ForceNewCluster: false
+              Spec:
+                Orchestration: {}
+                Raft: {}
+                Dispatcher: {}
+                CAConfig: {}
+                EncryptionConfig:
+                  AutoLockManagers: false
+      tags: ["Swarm"]
+  /swarm/join:
+    post:
+      summary: "Join an existing swarm"
+      operationId: "SwarmJoin"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is already part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmJoinRequest"
+            properties:
+              ListenAddr:
+                description: |
+                  Listen address used for inter-manager communication if the node
+                  gets promoted to manager, as well as determining the networking
+                  interface used for the VXLAN Tunnel Endpoint (VTEP). This is
+                  required for joining a swarm. If the port number is omitted,
+                  the default swarm listening port is used.
+                type: "string"
+              AdvertiseAddr:
+                description: |
+                  Externally reachable address advertised to other nodes. This
+                  can either be an address/port combination in the form
+                  `192.168.1.1:4567`, or an interface followed by a port number,
+                  like `eth0:4567`. If the port number is omitted, the port
+                  number from the listen address is used. If `AdvertiseAddr` is
+                  not specified, it will be automatically detected when possible.
+                type: "string"
+              DataPathAddr:
+                description: |
+                  Address or interface to use for data path traffic (format:
+                  `<ip|interface>`), for example,  `192.168.1.1`, or an interface,
+                  like `eth0`. If `DataPathAddr` is unspecified, the same address
+                  as `AdvertiseAddr` is used.
+
+                  The `DataPathAddr` specifies the address that global scope
+                  network drivers will publish towards other nodes in order to
+                  reach the containers running on this node. Using this parameter
+                  it is possible to separate the container data traffic from the
+                  management traffic of the cluster.
+
+                type: "string"
+              RemoteAddrs:
+                description: |
+                  Addresses of manager nodes already participating in the swarm.
+                type: "array"
+                items:
+                  type: "string"
+              JoinToken:
+                description: "Secret token for joining this swarm."
+                type: "string"
+            required: [ListenAddr, RemoteAddrs, JoinToken]
+            example:
+              ListenAddr: "0.0.0.0:2377"
+              AdvertiseAddr: "192.168.1.1:2377"
+              DataPathAddr: "192.168.1.1"
+              RemoteAddrs:
+                - "node1:2377"
+              JoinToken: "SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2"
+      tags: ["Swarm"]
+  /swarm/leave:
+    post:
+      summary: "Leave a swarm"
+      operationId: "SwarmLeave"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "force"
+          description: |
+            Force leave swarm, even if this is the last manager or that it will
+            break the cluster.
+          in: "query"
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/update:
+    post:
+      summary: "Update a swarm"
+      operationId: "SwarmUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            $ref: "#/definitions/SwarmSpec"
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the swarm object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+        - name: "rotateWorkerToken"
+          in: "query"
+          description: "Rotate the worker join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerToken"
+          in: "query"
+          description: "Rotate the manager join token."
+          type: "boolean"
+          default: false
+        - name: "rotateManagerUnlockKey"
+          in: "query"
+          description: "Rotate the manager unlock key."
+          type: "boolean"
+          default: false
+      tags: ["Swarm"]
+  /swarm/unlockkey:
+    get:
+      summary: "Get the unlock key"
+      operationId: "SwarmUnlockkey"
+      consumes:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "object"
+            title: "UnlockKeyResponse"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /swarm/unlock:
+    post:
+      summary: "Unlock a locked manager"
+      operationId: "SwarmUnlock"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            type: "object"
+            title: "SwarmUnlockRequest"
+            properties:
+              UnlockKey:
+                description: "The swarm's unlock key."
+                type: "string"
+            example:
+              UnlockKey: "SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8"
+      responses:
+        200:
+          description: "no error"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Swarm"]
+  /services:
+    get:
+      summary: "List services"
+      operationId: "ServiceList"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Service"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the services list.
+
+            Available filters:
+
+            - `id=<service id>`
+            - `label=<service label>`
+            - `mode=["replicated"|"global"]`
+            - `name=<service name>`
+        - name: "status"
+          in: "query"
+          type: "boolean"
+          description: |
+            Include service status, with count of running and desired tasks.
+      tags: ["Service"]
+  /services/create:
+    post:
+      summary: "Create a service"
+      operationId: "ServiceCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceCreateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        403:
+          description: "network is not eligible for services"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        409:
+          description: "name conflicts with an existing service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "web"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "nginx:alpine"
+                      Mounts:
+                        -
+                          ReadOnly: true
+                          Source: "web-data"
+                          Target: "/usr/share/nginx/html"
+                          Type: "volume"
+                          VolumeOptions:
+                            DriverConfig: {}
+                            Labels:
+                              com.example.something: "something-value"
+                      Hosts: ["10.10.10.10 host1", "ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 host2"]
+                      User: "33"
+                      DNSConfig:
+                        Nameservers: ["8.8.8.8"]
+                        Search: ["example.org"]
+                        Options: ["timeout:3"]
+                      Secrets:
+                        -
+                          File:
+                            Name: "www.example.org.key"
+                            UID: "33"
+                            GID: "33"
+                            Mode: 384
+                          SecretID: "fpjqlhnwb19zds35k8wn80lq9"
+                          SecretName: "example_org_domain_key"
+                      OomScoreAdj: 0
+                    LogDriver:
+                      Name: "json-file"
+                      Options:
+                        max-file: "3"
+                        max-size: "10M"
+                    Placement: {}
+                    Resources:
+                      Limits:
+                        MemoryBytes: 104857600
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "on-failure"
+                      Delay: 10000000000
+                      MaxAttempts: 10
+                  Mode:
+                    Replicated:
+                      Replicas: 4
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Ports:
+                      -
+                        Protocol: "tcp"
+                        PublishedPort: 8080
+                        TargetPort: 80
+                  Labels:
+                    foo: "bar"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+      tags: ["Service"]
+  /services/{id}:
+    get:
+      summary: "Inspect a service"
+      operationId: "ServiceInspect"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Service"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "insertDefaults"
+          in: "query"
+          description: "Fill empty fields with default values."
+          type: "boolean"
+          default: false
+      tags: ["Service"]
+    delete:
+      summary: "Delete a service"
+      operationId: "ServiceDelete"
+      responses:
+        200:
+          description: "no error"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+      tags: ["Service"]
+  /services/{id}/update:
+    post:
+      summary: "Update a service"
+      operationId: "ServiceUpdate"
+      consumes: ["application/json"]
+      produces: ["application/json"]
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/ServiceUpdateResponse"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID or name of service."
+          required: true
+          type: "string"
+        - name: "body"
+          in: "body"
+          required: true
+          schema:
+            allOf:
+              - $ref: "#/definitions/ServiceSpec"
+              - type: "object"
+                example:
+                  Name: "top"
+                  TaskTemplate:
+                    ContainerSpec:
+                      Image: "busybox"
+                      Args:
+                        - "top"
+                      OomScoreAdj: 0
+                    Resources:
+                      Limits: {}
+                      Reservations: {}
+                    RestartPolicy:
+                      Condition: "any"
+                      MaxAttempts: 0
+                    Placement: {}
+                    ForceUpdate: 0
+                  Mode:
+                    Replicated:
+                      Replicas: 1
+                  UpdateConfig:
+                    Parallelism: 2
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  RollbackConfig:
+                    Parallelism: 1
+                    Delay: 1000000000
+                    FailureAction: "pause"
+                    Monitor: 15000000000
+                    MaxFailureRatio: 0.15
+                  EndpointSpec:
+                    Mode: "vip"
+
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the service object being updated. This is
+            required to avoid conflicting writes.
+            This version number should be the value as currently set on the
+            service *before* the update. You can find the current version by
+            calling `GET /services/{id}`
+          required: true
+          type: "integer"
+        - name: "registryAuthFrom"
+          in: "query"
+          description: |
+            If the `X-Registry-Auth` header is not specified, this parameter
+            indicates where to find registry authorization credentials.
+          type: "string"
+          enum: ["spec", "previous-spec"]
+          default: "spec"
+        - name: "rollback"
+          in: "query"
+          description: |
+            Set to this parameter to `previous` to cause a server-side rollback
+            to the previous service spec. The supplied spec will be ignored in
+            this case.
+          type: "string"
+        - name: "X-Registry-Auth"
+          in: "header"
+          description: |
+            A base64url-encoded auth configuration for pulling from private
+            registries.
+
+            Refer to the [authentication section](#section/Authentication) for
+            details.
+          type: "string"
+
+      tags: ["Service"]
+  /services/{id}/logs:
+    get:
+      summary: "Get service logs"
+      description: |
+        Get `stdout` and `stderr` logs from a service. See also
+        [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      operationId: "ServiceLogs"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such service"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such service: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID or name of the service"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show service context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Service"]
+  /tasks:
+    get:
+      summary: "List tasks"
+      operationId: "TaskList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Task"
+            example:
+              - ID: "0kzzo1i0y4jz6027t0k7aezc7"
+                Version:
+                  Index: 71
+                CreatedAt: "2016-06-07T21:07:31.171892745Z"
+                UpdatedAt: "2016-06-07T21:07:31.376370513Z"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:31.290032978Z"
+                  State: "running"
+                  Message: "started"
+                  ContainerStatus:
+                    ContainerID: "e5d62702a1b48d01c3e02ca1e0212a250801fa8d67caca0b6f35919ebc12f035"
+                    PID: 677
+                DesiredState: "running"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.10/16"
+              - ID: "1yljwbmlr8er2waf8orvqpwms"
+                Version:
+                  Index: 30
+                CreatedAt: "2016-06-07T21:07:30.019104782Z"
+                UpdatedAt: "2016-06-07T21:07:30.231958098Z"
+                Name: "hopeful_cori"
+                Spec:
+                  ContainerSpec:
+                    Image: "redis"
+                  Resources:
+                    Limits: {}
+                    Reservations: {}
+                  RestartPolicy:
+                    Condition: "any"
+                    MaxAttempts: 0
+                  Placement: {}
+                ServiceID: "9mnpnzenvg8p8tdbtq4wvbkcz"
+                Slot: 1
+                NodeID: "60gvrl6tm78dmak4yl7srz94v"
+                Status:
+                  Timestamp: "2016-06-07T21:07:30.202183143Z"
+                  State: "shutdown"
+                  Message: "shutdown"
+                  ContainerStatus:
+                    ContainerID: "1cf8d63d18e79668b0004a4be4c6ee58cddfad2dae29506d8781581d0688a213"
+                DesiredState: "shutdown"
+                NetworksAttachments:
+                  - Network:
+                      ID: "4qvuz4ko70xaltuqbt8956gd1"
+                      Version:
+                        Index: 18
+                      CreatedAt: "2016-06-07T20:31:11.912919752Z"
+                      UpdatedAt: "2016-06-07T21:07:29.955277358Z"
+                      Spec:
+                        Name: "ingress"
+                        Labels:
+                          com.docker.swarm.internal: "true"
+                        DriverConfiguration: {}
+                        IPAMOptions:
+                          Driver: {}
+                          Configs:
+                            - Subnet: "10.255.0.0/16"
+                              Gateway: "10.255.0.1"
+                      DriverState:
+                        Name: "overlay"
+                        Options:
+                          com.docker.network.driver.overlay.vxlanid_list: "256"
+                      IPAMOptions:
+                        Driver:
+                          Name: "default"
+                        Configs:
+                          - Subnet: "10.255.0.0/16"
+                            Gateway: "10.255.0.1"
+                    Addresses:
+                      - "10.255.0.5/16"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the tasks list.
+
+            Available filters:
+
+            - `desired-state=(running | shutdown | accepted)`
+            - `id=<task id>`
+            - `label=key` or `label="key=value"`
+            - `name=<task name>`
+            - `node=<node id or name>`
+            - `service=<service name>`
+      tags: ["Task"]
+  /tasks/{id}:
+    get:
+      summary: "Inspect a task"
+      operationId: "TaskInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Task"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "ID of the task"
+          required: true
+          type: "string"
+      tags: ["Task"]
+  /tasks/{id}/logs:
+    get:
+      summary: "Get task logs"
+      description: |
+        Get `stdout` and `stderr` logs from a task.
+        See also [`/containers/{id}/logs`](#operation/ContainerLogs).
+
+        **Note**: This endpoint works only for services with the `local`,
+        `json-file` or `journald` logging drivers.
+      operationId: "TaskLogs"
+      produces:
+        - "application/vnd.docker.raw-stream"
+        - "application/vnd.docker.multiplexed-stream"
+      responses:
+        200:
+          description: "logs returned as a stream in response body"
+          schema:
+            type: "string"
+            format: "binary"
+        404:
+          description: "no such task"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such task: c2ada9df5af8"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          description: "ID of the task"
+          type: "string"
+        - name: "details"
+          in: "query"
+          description: "Show task context and extra details provided to logs."
+          type: "boolean"
+          default: false
+        - name: "follow"
+          in: "query"
+          description: "Keep connection after returning logs."
+          type: "boolean"
+          default: false
+        - name: "stdout"
+          in: "query"
+          description: "Return logs from `stdout`"
+          type: "boolean"
+          default: false
+        - name: "stderr"
+          in: "query"
+          description: "Return logs from `stderr`"
+          type: "boolean"
+          default: false
+        - name: "since"
+          in: "query"
+          description: "Only return logs since this time, as a UNIX timestamp"
+          type: "integer"
+          default: 0
+        - name: "timestamps"
+          in: "query"
+          description: "Add timestamps to every log line"
+          type: "boolean"
+          default: false
+        - name: "tail"
+          in: "query"
+          description: |
+            Only return this number of log lines from the end of the logs.
+            Specify as an integer or `all` to output all log lines.
+          type: "string"
+          default: "all"
+      tags: ["Task"]
+  /secrets:
+    get:
+      summary: "List secrets"
+      operationId: "SecretList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Secret"
+            example:
+              - ID: "blt1owaxmitz71s9v5zh81zun"
+                Version:
+                  Index: 85
+                CreatedAt: "2017-07-20T13:55:28.678958722Z"
+                UpdatedAt: "2017-07-20T13:55:28.678958722Z"
+                Spec:
+                  Name: "mysql-passwd"
+                  Labels:
+                    some.label: "some.value"
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "app-dev.crt"
+                  Labels:
+                    foo: "bar"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the secrets list.
+
+            Available filters:
+
+            - `id=<secret id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<secret name>`
+            - `names=<secret name>`
+      tags: ["Secret"]
+  /secrets/create:
+    post:
+      summary: "Create a secret"
+      operationId: "SecretCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/SecretSpec"
+              - type: "object"
+                example:
+                  Name: "app-key.crt"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+                  Driver:
+                    Name: "secret-bucket"
+                    Options:
+                      OptionA: "value for driver option A"
+                      OptionB: "value for driver option B"
+      tags: ["Secret"]
+  /secrets/{id}:
+    get:
+      summary: "Inspect a secret"
+      operationId: "SecretInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Secret"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+                Labels:
+                  foo: "bar"
+                Driver:
+                  Name: "secret-bucket"
+                  Options:
+                    OptionA: "value for driver option A"
+                    OptionB: "value for driver option B"
+
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+    delete:
+      summary: "Delete a secret"
+      operationId: "SecretDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "secret not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the secret"
+      tags: ["Secret"]
+  /secrets/{id}/update:
+    post:
+      summary: "Update a Secret"
+      operationId: "SecretUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such secret"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the secret"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/SecretSpec"
+          description: |
+            The spec of the secret to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [SecretInspect endpoint](#operation/SecretInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the secret object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Secret"]
+  /configs:
+    get:
+      summary: "List configs"
+      operationId: "ConfigList"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            type: "array"
+            items:
+              $ref: "#/definitions/Config"
+            example:
+              - ID: "ktnbjxoalbkvbvedmg1urrz8h"
+                Version:
+                  Index: 11
+                CreatedAt: "2016-11-05T01:20:17.327670065Z"
+                UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+                Spec:
+                  Name: "server.conf"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "filters"
+          in: "query"
+          type: "string"
+          description: |
+            A JSON encoded value of the filters (a `map[string][]string`) to
+            process on the configs list.
+
+            Available filters:
+
+            - `id=<config id>`
+            - `label=<key> or label=<key>=value`
+            - `name=<config name>`
+            - `names=<config name>`
+      tags: ["Config"]
+  /configs/create:
+    post:
+      summary: "Create a config"
+      operationId: "ConfigCreate"
+      consumes:
+        - "application/json"
+      produces:
+        - "application/json"
+      responses:
+        201:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/IDResponse"
+        409:
+          description: "name conflicts with an existing object"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "body"
+          in: "body"
+          schema:
+            allOf:
+              - $ref: "#/definitions/ConfigSpec"
+              - type: "object"
+                example:
+                  Name: "server.conf"
+                  Labels:
+                    foo: "bar"
+                  Data: "VEhJUyBJUyBOT1QgQSBSRUFMIENFUlRJRklDQVRFCg=="
+      tags: ["Config"]
+  /configs/{id}:
+    get:
+      summary: "Inspect a config"
+      operationId: "ConfigInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "no error"
+          schema:
+            $ref: "#/definitions/Config"
+          examples:
+            application/json:
+              ID: "ktnbjxoalbkvbvedmg1urrz8h"
+              Version:
+                Index: 11
+              CreatedAt: "2016-11-05T01:20:17.327670065Z"
+              UpdatedAt: "2016-11-05T01:20:17.327670065Z"
+              Spec:
+                Name: "app-dev.crt"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+    delete:
+      summary: "Delete a config"
+      operationId: "ConfigDelete"
+      produces:
+        - "application/json"
+      responses:
+        204:
+          description: "no error"
+        404:
+          description: "config not found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          required: true
+          type: "string"
+          description: "ID of the config"
+      tags: ["Config"]
+  /configs/{id}/update:
+    post:
+      summary: "Update a Config"
+      operationId: "ConfigUpdate"
+      responses:
+        200:
+          description: "no error"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        404:
+          description: "no such config"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        503:
+          description: "node is not part of a swarm"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "id"
+          in: "path"
+          description: "The ID or name of the config"
+          type: "string"
+          required: true
+        - name: "body"
+          in: "body"
+          schema:
+            $ref: "#/definitions/ConfigSpec"
+          description: |
+            The spec of the config to update. Currently, only the Labels field
+            can be updated. All other fields must remain unchanged from the
+            [ConfigInspect endpoint](#operation/ConfigInspect) response values.
+        - name: "version"
+          in: "query"
+          description: |
+            The version number of the config object being updated. This is
+            required to avoid conflicting writes.
+          type: "integer"
+          format: "int64"
+          required: true
+      tags: ["Config"]
+  /distribution/{name}/json:
+    get:
+      summary: "Get image information from the registry"
+      description: |
+        Return image digest and platform information by contacting the registry.
+      operationId: "DistributionInspect"
+      produces:
+        - "application/json"
+      responses:
+        200:
+          description: "descriptor and platform information"
+          schema:
+            $ref: "#/definitions/DistributionInspect"
+        401:
+          description: "Failed authentication or no image found"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+          examples:
+            application/json:
+              message: "No such image: someimage (tag: latest)"
+        500:
+          description: "Server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      parameters:
+        - name: "name"
+          in: "path"
+          description: "Image name or id"
+          type: "string"
+          required: true
+      tags: ["Distribution"]
+  /session:
+    post:
+      summary: "Initialize interactive session"
+      description: |
+        Start a new interactive session with a server. Session allows server to
+        call back to the client for advanced capabilities.
+
+        > **Deprecated**: This endpoint is deprecated and will be removed in a future version.
+        > Server should support gRPC directly on the listening socket.
+
+        ### Hijacking
+
+        This endpoint hijacks the HTTP connection to HTTP2 transport that allows
+        the client to expose gPRC services on that connection.
+
+        For example, the client sends this request to upgrade the connection:
+
+        ```
+        POST /session HTTP/1.1
+        Upgrade: h2c
+        Connection: Upgrade
+        ```
+
+        The Docker daemon responds with a `101 UPGRADED` response follow with
+        the raw stream:
+
+        ```
+        HTTP/1.1 101 UPGRADED
+        Connection: Upgrade
+        Upgrade: h2c
+        ```
+      operationId: "Session"
+      produces:
+        - "application/vnd.docker.raw-stream"
+      responses:
+        101:
+          description: "no error, hijacking successful"
+        400:
+          description: "bad parameter"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+        500:
+          description: "server error"
+          schema:
+            $ref: "#/definitions/ErrorResponse"
+      tags: ["Session"]
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.6.md b/_vendor/github.com/moby/moby/api/docs/v1.6.md
new file mode 100644
index 000000000000..dd9c6ded9e4d
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.6.md
@@ -0,0 +1,1261 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.6"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent="smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.6
+
+# 1. Brief introduction
+
+ - The Remote API has replaced rcli
+ - The daemon listens on `unix:///var/run/docker.sock` but you can bind
+   Docker to another host/port or a Unix socket.
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `stdout, stdin`
+   and `stderr`
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "base:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "base:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "base:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "base:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+     
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+    Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created containers, include non-running ones.
+-   **since** – Show only containers created since Id, include non-running ones.
+-   **before** – Show only containers created before Id, include non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers sizes
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "ExposedPorts":{},
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Dns":null,
+             "Image":"base",
+             "Volumes":{},
+             "VolumesFrom":"",
+             "WorkingDir":""
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Query Parameters:
+
+     
+
+-   **name** – container name to use
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+    **More Complex Example request, in 2 steps.** **First, use create to
+    expose a Private Port, which can be bound back to a Public Port a
+    startup**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Cmd":[
+                     "/usr/sbin/sshd","-D"
+             ],
+             "Image":"image-with-sshd",
+             "ExposedPorts":{"22/tcp":{}}
+             }
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+    **Second, start (using the ID returned above) the image we just
+    created, mapping the ssh port 22 to something on the host**:
+
+        POST /containers/e90e34656806/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "PortBindings": { "22/tcp": [{ "HostPort": "11022" }]}
+             }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain; charset=utf-8
+        Content-Length: 0
+
+    **Now you can ssh into your new container on port 11022.**
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "ExposedPorts": {},
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "base",
+                             "Volumes": {},
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {}
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id)/top`
+
+List processes running inside the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Titles": [
+                     "USER",
+                     "PID",
+                     "%CPU",
+                     "%MEM",
+                     "VSZ",
+                     "RSS",
+                     "TTY",
+                     "STAT",
+                     "START",
+                     "TIME",
+                     "COMMAND"
+                     ],
+             "Processes": [
+                     ["root","20147","0.0","0.1","18060","1864","pts/4","S","10:06","0:00","bash"],
+                     ["root","20271","0.0","0.0","4312","352","pts/4","S+","10:07","0:00","sleep","10"]
+             ]
+        }
+
+Query Parameters:
+
+-   **ps_args** – ps arguments to use (e.g., aux)
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/(id)/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds":["/tmp:/tmp"],
+             "LxcConf":[{"Key":"lxc.utsname","Value":"docker"}],
+             "ContainerIDFile": "",
+             "Privileged": false,
+             "PortBindings": {"22/tcp": [{HostIp:"", HostPort:""}]},
+             "Links": [],
+             "PublishAllPorts": false
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain
+
+Json Parameters:
+
+     
+
+-   **hostConfig** – the container's host configuration (optional)
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+     
+
+-   **signal** – Signal to send to the container (integer). When no
+        set, SIGKILL is assumed and the call will waits for the
+        container to exit.
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`
+    ](docker_remote_api_v1.9.md#create-a-container),
+    the stream is the raw data from the process PTY and client's stdin.
+    When the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1)
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/(format)`
+
+List images `format` could be json or viz (json default)
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Repository":"base",
+                     "Tag":"ubuntu-12.10",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658,
+                     "Size":24653,
+                     "VirtualSize":180116135
+             },
+             {
+                     "Repository":"base",
+                     "Tag":"ubuntu-quantal",
+                     "Id":"b750fe79269d",
+                     "Created":1364102658,
+                     "Size":24653,
+                     "VirtualSize":180116135
+             }
+        ]
+
+**Example request**:
+
+        GET /images/viz HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+        digraph docker {
+        "d82cbacda43a" -> "074be284591f"
+        "1496068ca813" -> "08306dc45919"
+        "08306dc45919" -> "0e7893146ac2"
+        "b750fe79269d" -> "1496068ca813"
+        base -> "27cf78414709" [style=invis]
+        "f71189fff3de" -> "9a33b36209ed"
+        "27cf78414709" -> "b750fe79269d"
+        "0e7893146ac2" -> "d6434d954665"
+        "d6434d954665" -> "d82cbacda43a"
+        base -> "e9aa60c60128" [style=invis]
+        "074be284591f" -> "f71189fff3de"
+        "b750fe79269d" [label="b750fe79269d\nbase",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "e9aa60c60128" [label="e9aa60c60128\nbase2",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        "9a33b36209ed" [label="9a33b36209ed\ntest",shape=box,fillcolor="paleturquoise",style="filled,rounded"];
+        base [style=invisible]
+        }
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+        Only running containers are shown by defaul
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=base HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pulling..."}
+        {"status":"Pulling", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Insert a file in an image
+
+`POST /images/(name)/insert`
+
+Insert a file from `url` in the image `name` at `path`
+
+**Example request**:
+
+        POST /images/test/insert?path=/usr&url=myurl HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Inserting..."}
+        {"status":"Inserting", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-	**url** – The url from where the file is taken
+-	**path** – The path where the file is stored
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/base/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "parent":"27cf784147099545",
+             "created":"2013-03-23T22:24:18.818426-07:00",
+             "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "container_config":
+                     {
+                             "Hostname":"",
+                             "User":"",
+                             "Memory":0,
+                             "MemorySwap":0,
+                             "AttachStdin":false,
+                             "AttachStdout":false,
+                             "AttachStderr":false,
+                             "ExposedPorts":{},
+                             "Tty":true,
+                             "OpenStdin":true,
+                             "StdinOnce":false,
+                             "Env":null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns":null,
+                             "Image":"base",
+                             "Volumes":null,
+                             "VolumesFrom":"",
+                             "WorkingDir":""
+                     },
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/base/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+    {"status":"Pushing..."} {"status":"Pushing", "progress":"1/? (n/a)"}
+    {"error":"Invalid..."} ...
+
+    > The `X-Registry-Auth` header can be used to
+    > include a base64-encoded AuthConfig object.
+
+Status Codes:
+
+-   **200** – no error :statuscode 404: no such image :statuscode
+        500: server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com)
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Name":"cespare/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"johnfuller/sshd",
+                     "Description":""
+             },
+             {
+                     "Name":"dhrp/mongodb-sshd",
+                     "Description":""
+             }
+        ]
+
+        :query term: term to search
+        :statuscode 200: no error
+        :statuscode 500: server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+        {{ STREAM }}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+    The archive must include a file called Dockerfile at its root. I
+    may include any number of other files, which will be accessible in
+    the build context (See the ADD build command).
+
+    The Content-type header should be set to "application/tar".
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – build source URI (git or HTTPS/HTTP)
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "MemoryLimit":true,
+             "SwapLimit":false,
+             "IPv4Forwarding":true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Version":"0.2.2",
+             "GitCommit":"5a2a5cc+CHANGES",
+             "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+            "Cmd": ["cat", "/world"],
+            "ExposedPorts":{"22/tcp":{}}
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+            Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+        <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "base:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "base:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "base:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "base:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+Here are the steps of `docker run` :
+
+-   Create the container
+
+-   If the status code is 404, it means the image doesn't exist:
+        -   Try to pull it
+        -   Then retry to create the container
+
+-   Start the container
+
+-   If you are not in detached mode:
+        -   Attach to the container, using logs=1 (to have stdout and
+            stderr from the container's start) and stream=1
+
+-   If in detached mode or only stdin is attached:
+        -   Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.7.md b/_vendor/github.com/moby/moby/api/docs/v1.7.md
new file mode 100644
index 000000000000..8a7334266786
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.7.md
@@ -0,0 +1,1249 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.7"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent="smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.7
+
+# 1. Brief introduction
+
+ - The Remote API has replaced rcli
+ - The daemon listens on `unix:///var/run/docker.sock` but you can bind
+   Docker to another host/port or a Unix socket.
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `stdout, stdin`
+   and `stderr`
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "base:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "base:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "base:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "base:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+    Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created containers, include non-running ones.
+-   **since** – Show only containers created since Id, include non-running ones.
+-   **before** – Show only containers created before Id, include non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers sizes
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Dns":null,
+             "Image":"base",
+             "Volumes":{
+                     "/tmp": {}
+             },
+             "VolumesFrom":"",
+             "WorkingDir":"",
+             "ExposedPorts":{
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+-   **config** – the container's configuration
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "base",
+                             "Volumes": {},
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {}
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id)/top`
+
+List processes running inside the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Titles": [
+                     "USER",
+                     "PID",
+                     "%CPU",
+                     "%MEM",
+                     "VSZ",
+                     "RSS",
+                     "TTY",
+                     "STAT",
+                     "START",
+                     "TIME",
+                     "COMMAND"
+                     ],
+             "Processes": [
+                     ["root","20147","0.0","0.1","18060","1864","pts/4","S","10:06","0:00","bash"],
+                     ["root","20271","0.0","0.0","4312","352","pts/4","S+","10:07","0:00","sleep","10"]
+             ]
+        }
+
+Query Parameters:
+
+-   **ps_args** – ps arguments to use (e.g., aux)
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/(id)/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds":["/tmp:/tmp"],
+             "LxcConf":[{"Key":"lxc.utsname","Value":"docker"}],
+             "PortBindings":{ "22/tcp": [{ "HostPort": "11022" }] },
+             "Privileged":false,
+             "PublishAllPorts":false
+        }
+
+    Binds need to reference Volumes that were defined during container
+    creation.
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain
+
+Json Parameters:
+
+-   **hostConfig** – the container's host configuration (optional)
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`
+    ](docker_remote_api_v1.7.md#create-a-container),
+    the stream is the raw data from the process PTY and client's stdin.
+    When the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1)
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+             "RepoTags": [
+               "ubuntu:12.04",
+               "ubuntu:precise",
+               "ubuntu:latest"
+             ],
+             "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+             "Created": 1365714795,
+             "Size": 131506275,
+             "VirtualSize": 131506275
+          },
+          {
+             "RepoTags": [
+               "ubuntu:12.10",
+               "ubuntu:quantal"
+             ],
+             "ParentId": "27cf784147099545",
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Created": 1364102658,
+             "Size": 24653,
+             "VirtualSize": 180116135
+          }
+        ]
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=base HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pulling..."}
+        {"status":"Pulling", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Request Headers:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Insert a file in an image
+
+`POST /images/(name)/insert`
+
+Insert a file from `url` in the image `name` at `path`
+
+**Example request**:
+
+        POST /images/test/insert?path=/usr&url=myurl HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Inserting..."}
+        {"status":"Inserting", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-	**url** – The url from where the file is taken
+-	**path** – The path where the file is stored
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/base/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "parent":"27cf784147099545",
+             "created":"2013-03-23T22:24:18.818426-07:00",
+             "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "container_config":
+                     {
+                             "Hostname":"",
+                             "User":"",
+                             "Memory":0,
+                             "MemorySwap":0,
+                             "AttachStdin":false,
+                             "AttachStdout":false,
+                             "AttachStderr":false,
+                             "PortSpecs":null,
+                             "Tty":true,
+                             "OpenStdin":true,
+                             "StdinOnce":false,
+                             "Env":null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns":null,
+                             "Image":"base",
+                             "Volumes":null,
+                             "VolumesFrom":"",
+                             "WorkingDir":""
+                     },
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/base/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Pushing..."}
+        {"status":"Pushing", "progress":"1/? (n/a)"}
+        {"error":"Invalid..."}
+        ...
+
+    Request Headers:
+
+     
+
+-   **X-Registry-Auth** – include a base64-encoded AuthConfig
+        object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "wma55/u1210sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "jdswinbank/sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "vgauthier/sshd",
+                    "star_count": 0
+                }
+        ...
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {{ STREAM }}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+
+    The archive must include a file called `Dockerfile`
+    at its root. It may include any number of other files,
+    which will be accessible in the build context (See the [*ADD build
+    command*](../../reference/builder.md#dockerbuilder)).
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – build source URI (git or HTTPS/HTTP)
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+
+    Request Headers:
+
+     
+
+-   **Content-type** – should be set to
+        `"application/tar"`.
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "MemoryLimit":true,
+             "SwapLimit":false,
+             "IPv4Forwarding":true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Version":"0.2.2",
+             "GitCommit":"5a2a5cc+CHANGES",
+             "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+            Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+        <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+-   **run** – config automatically applied when the image is run.
+        (ex: {"Cmd": ["cat", "/world"], "PortSpecs":["22"]})
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "base:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "base:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "base:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "base:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images and tags in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository
+specified by `name`.
+
+**Example request**
+
+               GET /images/ubuntu/get
+
+**Example response**:
+
+           .. sourcecode:: http
+
+              HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+            :statuscode 200: no error
+            :statuscode 500: server error
+
+### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into the docker repository.
+
+**Example request**
+
+            POST /images/load
+
+          Tarball in body
+
+        **Example response**:
+
+        .. sourcecode:: http
+
+           HTTP/1.1 200 OK
+
+         :statuscode 200: no error
+         :statuscode 500: server error
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+Here are the steps of `docker run` :
+
+-   Create the container
+
+-   If the status code is 404, it means the image doesn't exist:
+        -   Try to pull it
+        -   Then retry to create the container
+
+-   Start the container
+
+-   If you are not in detached mode:
+        -   Attach to the container, using logs=1 (to have stdout and
+            stderr from the container's start) and stream=1
+
+-   If in detached mode or only stdin is attached:
+        -   Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.8.md b/_vendor/github.com/moby/moby/api/docs/v1.8.md
new file mode 100644
index 000000000000..62324df8e167
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.8.md
@@ -0,0 +1,1325 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.8"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent="smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.8
+
+# 1. Brief introduction
+
+ - The Remote API has replaced rcli
+ - The daemon listens on `unix:///var/run/docker.sock` but you can bind
+   Docker to another host/port or a Unix socket.
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `stdout, stdin`
+   and `stderr`
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "base:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "base:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "base:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "base:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+     
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+    Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created containers, include non-running ones.
+-   **since** – Show only containers created since Id, include non-running ones.
+-   **before** – Show only containers created before Id, include non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers sizes
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "CpuShares":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Dns":null,
+             "Image":"base",
+             "Volumes":{
+                     "/tmp": {}
+             },
+             "VolumesFrom":"",
+             "WorkingDir":"",
+             "ExposedPorts":{
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+     
+
+-   **Hostname** – Container host name
+-   **User** – Username or UID
+-   **Memory** – Memory Limit in bytes
+-   **CpuShares** – CPU shares (relative weight)
+-   **AttachStdin** – 1/True/true or 0/False/false, attach to
+        standard input. Default false
+-   **AttachStdout** – 1/True/true or 0/False/false, attach to
+        standard output. Default false
+-   **AttachStderr** – 1/True/true or 0/False/false, attach to
+        standard error. Default false
+-   **Tty** – 1/True/true or 0/False/false, allocate a pseudo-tty.
+        Default false
+-   **OpenStdin** – 1/True/true or 0/False/false, keep stdin open
+        even if not attached. Default false
+
+Query Parameters:
+
+     
+
+-   **name** – Assign the specified name to the container. Mus
+        match `/?[a-zA-Z0-9_-]+`.
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "base",
+                             "Volumes": {},
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {},
+                     "HostConfig": {
+                         "Binds": null,
+                         "ContainerIDFile": "",
+                         "LxcConf": [],
+                         "Privileged": false,
+                         "PortBindings": {
+                            "80/tcp": [
+                                {
+                                    "HostIp": "0.0.0.0",
+                                    "HostPort": "49153"
+                                }
+                            ]
+                         },
+                         "Links": null,
+                         "PublishAllPorts": false
+                     }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id)/top`
+
+List processes running inside the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Titles": [
+                     "USER",
+                     "PID",
+                     "%CPU",
+                     "%MEM",
+                     "VSZ",
+                     "RSS",
+                     "TTY",
+                     "STAT",
+                     "START",
+                     "TIME",
+                     "COMMAND"
+                     ],
+             "Processes": [
+                     ["root","20147","0.0","0.1","18060","1864","pts/4","S","10:06","0:00","bash"],
+                     ["root","20271","0.0","0.0","4312","352","pts/4","S+","10:07","0:00","sleep","10"]
+             ]
+        }
+
+Query Parameters:
+
+-   **ps_args** – ps arguments to use (e.g., aux)
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/(id)/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds":["/tmp:/tmp"],
+             "LxcConf":[{"Key":"lxc.utsname","Value":"docker"}],
+             "PortBindings":{ "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts":false,
+             "Privileged":false
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain
+
+Json Parameters:
+
+     
+
+-   **Binds** – Create a bind mount to a directory or file with
+        [host-path]:[container-path]:[rw|ro]. If a directory
+        "container-path" is missing, then docker creates a new volume.
+-   **LxcConf** – Map of custom lxc options
+-   **PortBindings** – Expose ports from the container, optionally
+        publishing them via the HostPort flag
+-   **PublishAllPorts** – 1/True/true or 0/False/false, publish all
+        exposed ports to the host interfaces. Default false
+-   **Privileged** – 1/True/true or 0/False/false, give extended
+        privileges to this container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`
+    ](docker_remote_api_v1.9.md#create-a-container),
+    the stream is the raw data from the process PTY and client's stdin.
+    When the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1)
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List Images
+
+`GET /images/json`
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+             "RepoTags": [
+               "ubuntu:12.04",
+               "ubuntu:precise",
+               "ubuntu:latest"
+             ],
+             "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+             "Created": 1365714795,
+             "Size": 131506275,
+             "VirtualSize": 131506275
+          },
+          {
+             "RepoTags": [
+               "ubuntu:12.10",
+               "ubuntu:quantal"
+             ],
+             "ParentId": "27cf784147099545",
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Created": 1364102658,
+             "Size": 24653,
+             "VirtualSize": 180116135
+          }
+        ]
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=base HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pulling..."}
+        {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+        {"error": "Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Request Headers:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Insert a file in an image
+
+`POST /images/(name)/insert`
+
+Insert a file from `url` in the image `name` at `path`
+
+**Example request**:
+
+        POST /images/test/insert?path=/usr&url=myurl HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Inserting..."}
+        {"status":"Inserting", "progress":"1/? (n/a)", "progressDetail":{"current":1}}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-	**url** – The url from where the file is taken
+-	**path** – The path where the file is stored
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/base/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "parent":"27cf784147099545",
+             "created":"2013-03-23T22:24:18.818426-07:00",
+             "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "container_config":
+                     {
+                             "Hostname":"",
+                             "User":"",
+                             "Memory":0,
+                             "MemorySwap":0,
+                             "AttachStdin":false,
+                             "AttachStdout":false,
+                             "AttachStderr":false,
+                             "PortSpecs":null,
+                             "Tty":true,
+                             "OpenStdin":true,
+                             "StdinOnce":false,
+                             "Env":null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns":null,
+                             "Image":"base",
+                             "Volumes":null,
+                             "VolumesFrom":"",
+                             "WorkingDir":""
+                     },
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/base/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pushing..."}
+        {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+        {"error": "Invalid..."}
+        ...
+
+    Request Headers:
+
+     
+
+-   **X-Registry-Auth** – include a base64-encoded AuthConfig
+        object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name)`
+
+Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "wma55/u1210sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "jdswinbank/sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "vgauthier/sshd",
+                    "star_count": 0
+                }
+        ...
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile via stdin
+
+`POST /build`
+
+Build an image from Dockerfile via stdin
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"stream": "Step 1..."}
+        {"stream": "..."}
+        {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+
+    The archive must include a file called `Dockerfile`
+    at its root. It may include any number of other files,
+    which will be accessible in the build context (See the [*ADD build
+    command*](../../reference/builder.md#dockerbuilder)).
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – build source URI (git or HTTPS/HTTP)
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+
+    Request Headers:
+
+     
+
+-   **Content-type** – should be set to
+        `"application/tar"`.
+-   **X-Registry-Auth** – base64-encoded AuthConfig objec
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "MemoryLimit":true,
+             "SwapLimit":false,
+             "IPv4Forwarding":true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Version":"0.2.2",
+             "GitCommit":"5a2a5cc+CHANGES",
+             "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+            Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+        <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+-   **run** – config automatically applied when the image is run.
+        (ex: {"Cmd": ["cat", "/world"], "PortSpecs":["22"]})
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get events from docker, either in real time via streaming,
+or via polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "base:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "base:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "base:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "base:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images and tags in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository
+specified by `name`.
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/ubuntu/get
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into the docker repository.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        POST /images/load
+
+        Tarball in body
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing three files:
+
+1. `VERSION`: currently `1.0` - the file format version
+2. `json`: detailed layer information, similar to `docker inspect layer_id`
+3. `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file will contain `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, there will also be a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+Here are the steps of `docker run`:
+
+ - Create the container
+
+ - If the status code is 404, it means the image doesn't exist:
+        - Try to pull it
+        - Then retry to create the container
+
+ - Start the container
+
+ - If you are not in detached mode:
+        - Attach to the container, using logs=1 (to have stdout and
+            stderr from the container's start) and stream=1
+
+ - If in detached mode or only stdin is attached:
+        - Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS Requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/api/docs/v1.9.md b/_vendor/github.com/moby/moby/api/docs/v1.9.md
new file mode 100644
index 000000000000..ae18deb4c6f1
--- /dev/null
+++ b/_vendor/github.com/moby/moby/api/docs/v1.9.md
@@ -0,0 +1,1358 @@
+<!--[metadata]>
++++
+draft = true
+title = "Remote API v1.9"
+description = "API Documentation for Docker"
+keywords = ["API, Docker, rcli, REST,  documentation"]
+[menu.main]
+parent="smn_remoteapi"
++++
+<![end-metadata]-->
+
+# Docker Remote API v1.9
+
+# 1. Brief introduction
+
+ - The Remote API has replaced rcli
+ - The daemon listens on `unix:///var/run/docker.sock` but you can bind
+   Docker to another host/port or a Unix socket.
+ - The API tends to be REST, but for some complex commands, like `attach`
+   or `pull`, the HTTP connection is hijacked to transport `stdout, stdin`
+   and `stderr`
+
+# 2. Endpoints
+
+## 2.1 Containers
+
+### List containers
+
+`GET /containers/json`
+
+List containers.
+
+**Example request**:
+
+        GET /containers/json?all=1&before=8dfafdbc3a40&size=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "8dfafdbc3a40",
+                     "Image": "base:latest",
+                     "Command": "echo 1",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [{"PrivatePort": 2222, "PublicPort": 3333, "Type": "tcp"}],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "9cd87474be90",
+                     "Image": "base:latest",
+                     "Command": "echo 222222",
+                     "Created": 1367854155,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             },
+             {
+                     "Id": "3176a2479c92",
+                     "Image": "base:latest",
+                     "Command": "echo 3333333333333333",
+                     "Created": 1367854154,
+                     "Status": "Exit 0",
+                     "Ports":[],
+                     "SizeRw":12288,
+                     "SizeRootFs":0
+             },
+             {
+                     "Id": "4cb07b47f9fb",
+                     "Image": "base:latest",
+                     "Command": "echo 444444444444444444444444444444444",
+                     "Created": 1367854152,
+                     "Status": "Exit 0",
+                     "Ports": [],
+                     "SizeRw": 12288,
+                     "SizeRootFs": 0
+             }
+        ]
+
+Query Parameters:
+
+     
+
+-   **all** – 1/True/true or 0/False/false, Show all containers.
+    Only running containers are shown by default (i.e., this defaults to false)
+-   **limit** – Show `limit` last created containers, include non-running ones.
+-   **since** – Show only containers created since Id, include non-running ones.
+-   **before** – Show only containers created before Id, include non-running ones.
+-   **size** – 1/True/true or 0/False/false, Show the containers sizes
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **500** – server error
+
+### Create a container
+
+`POST /containers/create`
+
+Create a container
+
+**Example request**:
+
+        POST /containers/create HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "CpuShares":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Dns":null,
+             "Image":"base",
+             "Volumes":{
+                     "/tmp": {}
+             },
+             "VolumesFrom":"",
+             "WorkingDir":"",
+             "ExposedPorts":{
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/json
+
+        {
+             "Id":"e90e34656806"
+             "Warnings":[]
+        }
+
+Json Parameters:
+
+     
+
+-   **Hostname** – Container host name
+-   **User** – Username or UID
+-   **Memory** – Memory Limit in bytes
+-   **CpuShares** – CPU shares (relative weight)
+-   **AttachStdin** – 1/True/true or 0/False/false, attach to
+        standard input. Default false
+-   **AttachStdout** – 1/True/true or 0/False/false, attach to
+        standard output. Default false
+-   **AttachStderr** – 1/True/true or 0/False/false, attach to
+        standard error. Default false
+-   **Tty** – 1/True/true or 0/False/false, allocate a pseudo-tty.
+        Default false
+-   **OpenStdin** – 1/True/true or 0/False/false, keep stdin open
+        even if not attached. Default false
+
+Query Parameters:
+
+     
+
+-   **name** – Assign the specified name to the container. Mus
+        match `/?[a-zA-Z0-9_-]+`.
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **406** – impossible to attach (container not running)
+-   **500** – server error
+
+### Inspect a container
+
+`GET /containers/(id)/json`
+
+Return low-level information on the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+                     "Id": "4fa6e0f0c6786287e131c3852c58a2e01cc697a68231826813597e4994f1d6e2",
+                     "Created": "2013-05-07T14:51:42.041847+02:00",
+                     "Path": "date",
+                     "Args": [],
+                     "Config": {
+                             "Hostname": "4fa6e0f0c678",
+                             "User": "",
+                             "Memory": 0,
+                             "MemorySwap": 0,
+                             "AttachStdin": false,
+                             "AttachStdout": true,
+                             "AttachStderr": true,
+                             "PortSpecs": null,
+                             "Tty": false,
+                             "OpenStdin": false,
+                             "StdinOnce": false,
+                             "Env": null,
+                             "Cmd": [
+                                     "date"
+                             ],
+                             "Dns": null,
+                             "Image": "base",
+                             "Volumes": {},
+                             "VolumesFrom": "",
+                             "WorkingDir": ""
+                     },
+                     "State": {
+                             "Running": false,
+                             "Pid": 0,
+                             "ExitCode": 0,
+                             "StartedAt": "2013-05-07T14:51:42.087658+02:01360",
+                             "Ghost": false
+                     },
+                     "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+                     "NetworkSettings": {
+                             "IpAddress": "",
+                             "IpPrefixLen": 0,
+                             "Gateway": "",
+                             "Bridge": "",
+                             "PortMapping": null
+                     },
+                     "SysInitPath": "/home/kitty/go/src/github.com/docker/docker/bin/docker",
+                     "ResolvConfPath": "/etc/resolv.conf",
+                     "Volumes": {},
+                     "HostConfig": {
+                         "Binds": null,
+                         "ContainerIDFile": "",
+                         "LxcConf": [],
+                         "Privileged": false,
+                         "PortBindings": {
+                            "80/tcp": [
+                                {
+                                    "HostIp": "0.0.0.0",
+                                    "HostPort": "49153"
+                                }
+                            ]
+                         },
+                         "Links": null,
+                         "PublishAllPorts": false
+                     }
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### List processes running inside a container
+
+`GET /containers/(id)/top`
+
+List processes running inside the container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/top HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Titles": [
+                     "USER",
+                     "PID",
+                     "%CPU",
+                     "%MEM",
+                     "VSZ",
+                     "RSS",
+                     "TTY",
+                     "STAT",
+                     "START",
+                     "TIME",
+                     "COMMAND"
+                     ],
+             "Processes": [
+                     ["root","20147","0.0","0.1","18060","1864","pts/4","S","10:06","0:00","bash"],
+                     ["root","20271","0.0","0.0","4312","352","pts/4","S+","10:07","0:00","sleep","10"]
+             ]
+        }
+
+Query Parameters:
+
+-   **ps_args** – ps arguments to use (e.g., aux)
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Inspect changes on a container's filesystem
+
+`GET /containers/(id)/changes`
+
+Inspect changes on container `id`'s filesystem
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/changes HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Path": "/dev",
+                     "Kind": 0
+             },
+             {
+                     "Path": "/dev/kmsg",
+                     "Kind": 1
+             },
+             {
+                     "Path": "/test",
+                     "Kind": 1
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Export a container
+
+`GET /containers/(id)/export`
+
+Export the contents of container `id`
+
+**Example request**:
+
+        GET /containers/4fa6e0f0c678/export HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Start a container
+
+`POST /containers/(id)/start`
+
+Start the container `id`
+
+**Example request**:
+
+        POST /containers/(id)/start HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Binds":["/tmp:/tmp"],
+             "LxcConf":[{"Key":"lxc.utsname","Value":"docker"}],
+             "PortBindings":{ "22/tcp": [{ "HostPort": "11022" }] },
+             "PublishAllPorts":false,
+             "Privileged":false
+        }
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+        Content-Type: text/plain
+
+Json Parameters:
+
+     
+
+-   **Binds** – Create a bind mount to a directory or file with
+        [host-path]:[container-path]:[rw|ro]. If a directory
+        "container-path" is missing, then docker creates a new volume.
+-   **LxcConf** – Map of custom lxc options
+-   **PortBindings** – Expose ports from the container, optionally
+        publishing them via the HostPort flag
+-   **PublishAllPorts** – 1/True/true or 0/False/false, publish all
+        exposed ports to the host interfaces. Default false
+-   **Privileged** – 1/True/true or 0/False/false, give extended
+        privileges to this container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Stop a container
+
+`POST /containers/(id)/stop`
+
+Stop the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/stop?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 OK
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Restart a container
+
+`POST /containers/(id)/restart`
+
+Restart the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/restart?t=5 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **t** – number of seconds to wait before killing the container
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Kill a container
+
+`POST /containers/(id)/kill`
+
+Kill the container `id`
+
+**Example request**:
+
+        POST /containers/e90e34656806/kill HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters
+
+-   **signal** - Signal to send to the container: integer or string like "SIGINT".
+    When not set, SIGKILL is assumed and the call will wait for the container to exit.
+
+Status Codes:
+
+-   **204** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Attach to a container
+
+`POST /containers/(id)/attach`
+
+Attach to the container `id`
+
+**Example request**:
+
+        POST /containers/16253994b7c4/attach?logs=1&stream=0&stdout=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/vnd.docker.raw-stream
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Defaul
+        false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+    **Stream details**:
+
+    When using the TTY setting is enabled in
+    [`POST /containers/create`](#create-a-container), the
+    stream is the raw data from the process PTY and client's stdin. When
+    the TTY is disabled, then the stream is multiplexed to separate
+    stdout and stderr.
+
+    The format is a **Header** and a **Payload** (frame).
+
+    **HEADER**
+
+    The header will contain the information on which stream write the
+    stream (stdout or stderr). It also contain the size of the
+    associated frame encoded on the last 4 bytes (uint32).
+
+    It is encoded on the first 8 bytes like this:
+
+        header := [8]byte{STREAM_TYPE, 0, 0, 0, SIZE1, SIZE2, SIZE3, SIZE4}
+
+    `STREAM_TYPE` can be:
+
+-   0: stdin (will be written on stdout)
+-   1: stdout
+-   2: stderr
+
+    `SIZE1, SIZE2, SIZE3, SIZE4` are the 4 bytes of
+    the uint32 size encoded as big endian.
+
+    **PAYLOAD**
+
+    The payload is the raw stream.
+
+    **IMPLEMENTATION**
+
+    The simplest way to implement the Attach protocol is the following:
+
+    1.  Read 8 bytes
+    2.  chose stdout or stderr depending on the first byte
+    3.  Extract the frame size from the last 4 bytes
+    4.  Read the extracted size and output it on the correct output
+    5.  Goto 1)
+
+### Attach to a container (websocket)
+
+`GET /containers/(id)/attach/ws`
+
+Attach to the container `id` via websocket
+
+Implements websocket protocol handshake according to [RFC 6455](http://tools.ietf.org/html/rfc6455)
+
+**Example request**
+
+        GET /containers/e90e34656806/attach/ws?logs=0&stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
+
+**Example response**
+
+        {{ STREAM }}
+
+Query Parameters:
+
+-   **logs** – 1/True/true or 0/False/false, return logs. Default false
+-   **stream** – 1/True/true or 0/False/false, return stream.
+        Default false
+-   **stdin** – 1/True/true or 0/False/false, if stream=true, attach
+        to stdin. Default false
+-   **stdout** – 1/True/true or 0/False/false, if logs=true, return
+        stdout log, if stream=true, attach to stdout. Default false
+-   **stderr** – 1/True/true or 0/False/false, if logs=true, return
+        stderr log, if stream=true, attach to stderr. Default false
+
+Status Codes:
+
+-   **200** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Wait a container
+
+`POST /containers/(id)/wait`
+
+Block until container `id` stops, then returns the exit code
+
+**Example request**:
+
+        POST /containers/16253994b7c4/wait HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"StatusCode": 0}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Remove a container
+
+`DELETE /containers/(id)`
+
+Remove the container `id` from the filesystem
+
+**Example request**:
+
+        DELETE /containers/16253994b7c4?v=1 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 204 No Content
+
+Query Parameters:
+
+-   **v** – 1/True/true or 0/False/false, Remove the volumes
+        associated to the container. Default false
+
+Status Codes:
+
+-   **204** – no error
+-   **400** – bad parameter
+-   **404** – no such container
+-   **500** – server error
+
+### Copy files or folders from a container
+
+`POST /containers/(id)/copy`
+
+Copy files or folders of container `id`
+
+**Example request**:
+
+        POST /containers/4fa6e0f0c678/copy HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Resource": "test.txt"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/octet-stream
+
+        {{ TAR STREAM }}
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such container
+-   **500** – server error
+
+## 2.2 Images
+
+### List images
+
+`GET /images/json`
+
+**Example request**:
+
+        GET /images/json?all=0 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+          {
+             "RepoTags": [
+               "ubuntu:12.04",
+               "ubuntu:precise",
+               "ubuntu:latest"
+             ],
+             "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
+             "Created": 1365714795,
+             "Size": 131506275,
+             "VirtualSize": 131506275
+          },
+          {
+             "RepoTags": [
+               "ubuntu:12.10",
+               "ubuntu:quantal"
+             ],
+             "ParentId": "27cf784147099545",
+             "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "Created": 1364102658,
+             "Size": 24653,
+             "VirtualSize": 180116135
+          }
+        ]
+
+### Create an image
+
+`POST /images/create`
+
+Create an image, either by pull it from the registry or by importing i
+
+**Example request**:
+
+        POST /images/create?fromImage=base HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pulling..."}
+        {"status": "Pulling", "progress": "1 B/ 100 B", "progressDetail": {"current": 1, "total": 100}}
+        {"error": "Invalid..."}
+        ...
+
+    When using this endpoint to pull an image from the registry, the
+    `X-Registry-Auth` header can be used to include
+    a base64-encoded AuthConfig object.
+
+Query Parameters:
+
+-   **fromImage** – name of the image to pull
+-   **fromSrc** – source to import, - means stdin
+-   **repo** – repository
+-   **tag** – tag
+-   **registry** – the registry to pull from
+
+Request Headers:
+
+-   **X-Registry-Auth** – base64-encoded AuthConfig object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Insert a file in an image
+
+`POST /images/(name)/insert`
+
+Insert a file from `url` in the image `name` at `path`
+
+**Example request**:
+
+        POST /images/test/insert?path=/usr&url=myurl HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status":"Inserting..."}
+        {"status":"Inserting", "progress":"1/? (n/a)", "progressDetail":{"current":1}}
+        {"error":"Invalid..."}
+        ...
+
+Query Parameters:
+
+-	**url** – The url from where the file is taken
+-	**path** – The path where the file is stored
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Inspect an image
+
+`GET /images/(name)/json`
+
+Return low-level information on the image `name`
+
+**Example request**:
+
+        GET /images/base/json HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "id":"b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
+             "parent":"27cf784147099545",
+             "created":"2013-03-23T22:24:18.818426-07:00",
+             "container":"3d67245a8d72ecf13f33dffac9f79dcdf70f75acb84d308770391510e0c23ad0",
+             "container_config":
+                     {
+                             "Hostname":"",
+                             "User":"",
+                             "Memory":0,
+                             "MemorySwap":0,
+                             "AttachStdin":false,
+                             "AttachStdout":false,
+                             "AttachStderr":false,
+                             "PortSpecs":null,
+                             "Tty":true,
+                             "OpenStdin":true,
+                             "StdinOnce":false,
+                             "Env":null,
+                             "Cmd": ["/bin/bash"],
+                             "Dns":null,
+                             "Image":"base",
+                             "Volumes":null,
+                             "VolumesFrom":"",
+                             "WorkingDir":""
+                     },
+             "Size": 6824592
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Get the history of an image
+
+`GET /images/(name)/history`
+
+Return the history of the image `name`
+
+**Example request**:
+
+        GET /images/base/history HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+             {
+                     "Id": "b750fe79269d",
+                     "Created": 1364102658,
+                     "CreatedBy": "/bin/bash"
+             },
+             {
+                     "Id": "27cf78414709",
+                     "Created": 1364068391,
+                     "CreatedBy": ""
+             }
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Push an image on the registry
+
+`POST /images/(name)/push`
+
+Push the image `name` on the registry
+
+**Example request**:
+
+        POST /images/test/push HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "Pushing..."}
+        {"status": "Pushing", "progress": "1/? (n/a)", "progressDetail": {"current": 1}}}
+        {"error": "Invalid..."}
+        ...
+
+    Request Headers:
+
+     
+
+-   **X-Registry-Auth** – include a base64-encoded AuthConfig
+        object.
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **500** – server error
+
+### Tag an image into a repository
+
+`POST /images/(name)/tag`
+
+Tag the image `name` into a repository
+
+**Example request**:
+
+        POST /images/test/tag?repo=myrepo&force=0&tag=v42 HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 201 OK
+
+Query Parameters:
+
+-   **repo** – The repository to tag in
+-   **force** – 1/True/true or 0/False/false, default false
+-   **tag** - The new tag name
+
+Status Codes:
+
+-   **201** – no error
+-   **400** – bad parameter
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Remove an image
+
+`DELETE /images/(name*)
+:   Remove the image `name` from the filesystem
+
+**Example request**:
+
+        DELETE /images/test HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-type: application/json
+
+        [
+         {"Untagged": "3e2f21a89f"},
+         {"Deleted": "3e2f21a89f"},
+         {"Deleted": "53b4f83ac9"}
+        ]
+
+Status Codes:
+
+-   **200** – no error
+-   **404** – no such image
+-   **409** – conflict
+-   **500** – server error
+
+### Search images
+
+`GET /images/search`
+
+Search for an image on [Docker Hub](https://hub.docker.com).
+
+> **Note**:
+> The response keys have changed from API v1.6 to reflect the JSON
+> sent by the registry server to the docker daemon's request.
+
+**Example request**:
+
+        GET /images/search?term=sshd HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        [
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "wma55/u1210sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "jdswinbank/sshd",
+                    "star_count": 0
+                },
+                {
+                    "description": "",
+                    "is_official": false,
+                    "is_trusted": false,
+                    "name": "vgauthier/sshd",
+                    "star_count": 0
+                }
+        ...
+        ]
+
+Query Parameters:
+
+-   **term** – term to search
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+## 2.3 Misc
+
+### Build an image from Dockerfile
+
+`POST /build`
+
+Build an image from Dockerfile using a POST body.
+
+**Example request**:
+
+        POST /build HTTP/1.1
+
+        {{ TAR STREAM }}
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"stream": "Step 1..."}
+        {"stream": "..."}
+        {"error": "Error...", "errorDetail": {"code": 123, "message": "Error..."}}
+
+    The stream must be a tar archive compressed with one of the
+    following algorithms: identity (no compression), gzip, bzip2, xz.
+
+    The archive must include a file called `Dockerfile`
+ at its root. It may include any number of other files,
+    which will be accessible in the build context (See the [*ADD build
+    command*](../../reference/builder.md#add)).
+
+Query Parameters:
+
+-   **t** – repository name (and optionally a tag) to be applied to
+    the resulting image in case of success
+-   **remote** – build source URI (git or HTTPS/HTTP)
+-   **q** – suppress verbose build output
+-   **nocache** – do not use the cache when building the image
+-   **rm** – Remove intermediate containers after a successful build
+
+    Request Headers:
+
+-   **Content-type** – should be set to `"application/tar"`.
+-   **X-Registry-Config** – base64-encoded ConfigFile object
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Check auth configuration
+
+`POST /auth`
+
+Get the default username and email
+
+**Example request**:
+
+        POST /auth HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "username":" hannibal",
+             "password: "xxxx",
+             "email": "hannibal@a-team.com",
+             "serveraddress": "https://index.docker.io/v1/"
+        }
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: text/plain
+
+Status Codes:
+
+-   **200** – no error
+-   **204** – no error
+-   **500** – server error
+
+### Display system-wide information
+
+`GET /info`
+
+Display system-wide information
+
+**Example request**:
+
+        GET /info HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Containers":11,
+             "Images":16,
+             "Debug":false,
+             "NFd": 11,
+             "NGoroutines":21,
+             "MemoryLimit":true,
+             "SwapLimit":false,
+             "IPv4Forwarding":true
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Show the Docker version information
+
+`GET /version`
+
+Show the docker version information
+
+**Example request**:
+
+        GET /version HTTP/1.1
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {
+             "Version":"0.2.2",
+             "GitCommit":"5a2a5cc+CHANGES",
+             "GoVersion":"go1.0.3"
+        }
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Create a new image from a container's changes
+
+`POST /commit`
+
+Create a new image from a container's changes
+
+**Example request**:
+
+        POST /commit?container=44c004db4b17&m=message&repo=myrepo HTTP/1.1
+        Content-Type: application/json
+
+        {
+             "Hostname":"",
+             "User":"",
+             "Memory":0,
+             "MemorySwap":0,
+             "AttachStdin":false,
+             "AttachStdout":true,
+             "AttachStderr":true,
+             "PortSpecs":null,
+             "Tty":false,
+             "OpenStdin":false,
+             "StdinOnce":false,
+             "Env":null,
+             "Cmd":[
+                     "date"
+             ],
+             "Volumes":{
+                     "/tmp": {}
+             },
+             "WorkingDir":"",
+             "DisableNetwork": false,
+             "ExposedPorts":{
+                     "22/tcp": {}
+             }
+        }
+
+**Example response**:
+
+        HTTP/1.1 201 Created
+        Content-Type: application/vnd.docker.raw-stream
+
+        {"Id": "596069db4bf5"}
+
+Json Parameters:
+
+-  **config** - the container's configuration
+
+Query Parameters:
+
+-   **container** – source container
+-   **repo** – repository
+-   **tag** – tag
+-   **m** – commit message
+-   **author** – author (e.g., "John Hannibal Smith
+    <[hannibal@a-team.com](mailto:hannibal%40a-team.com)>")
+
+Status Codes:
+
+-   **201** – no error
+-   **404** – no such container
+-   **500** – server error
+
+### Monitor Docker's events
+
+`GET /events`
+
+Get events from docker, either in real time via streaming, or via
+polling (using since).
+
+Docker containers will report the following events:
+
+    create, destroy, die, export, kill, pause, restart, start, stop, unpause
+
+and Docker images will report:
+
+    untag, delete
+
+**Example request**:
+
+        GET /events?since=1374067924
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/json
+
+        {"status": "create", "id": "dfdf82bd3881","from": "base:latest", "time":1374067924}
+        {"status": "start", "id": "dfdf82bd3881","from": "base:latest", "time":1374067924}
+        {"status": "stop", "id": "dfdf82bd3881","from": "base:latest", "time":1374067966}
+        {"status": "destroy", "id": "dfdf82bd3881","from": "base:latest", "time":1374067970}
+
+Query Parameters:
+
+-   **since** – timestamp used for polling
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Get a tarball containing all images and tags in a repository
+
+`GET /images/(name)/get`
+
+Get a tarball containing all images and metadata for the repository specified by `name`.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        GET /images/ubuntu/get
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+        Content-Type: application/x-tar
+
+        Binary data stream
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Load a tarball with a set of images and tags into docker
+
+`POST /images/load`
+
+Load a set of images and tags into the docker repository.
+
+See the [image tarball format](#image-tarball-format) for more details.
+
+**Example request**
+
+        POST /images/load
+
+        Tarball in body
+
+**Example response**:
+
+        HTTP/1.1 200 OK
+
+Status Codes:
+
+-   **200** – no error
+-   **500** – server error
+
+### Image tarball format
+
+An image tarball contains one directory per image layer (named using its long ID),
+each containing three files:
+
+1. `VERSION`: currently `1.0` - the file format version
+2. `json`: detailed layer information, similar to `docker inspect layer_id`
+3. `layer.tar`: A tarfile containing the filesystem changes in this layer
+
+The `layer.tar` file will contain `aufs` style `.wh..wh.aufs` files and directories
+for storing attribute changes and deletions.
+
+If the tarball defines a repository, there will also be a `repositories` file at
+the root that contains a list of repository and tag names mapped to layer IDs.
+
+```
+{"hello-world":
+    {"latest": "565a9d68a73f6706862bfe8409a7f659776d4d60a8d096eb4a3cbce6999cc2a1"}
+}
+```
+
+# 3. Going further
+
+## 3.1 Inside `docker run`
+
+Here are the steps of `docker run` :
+
+ - Create the container
+
+ - If the status code is 404, it means the image doesn't exist:
+
+- Try to pull it
+-   Then retry to create the container
+
+ - Start the container
+
+ - If you are not in detached mode:
+
+- Attach to the container, using logs=1 (to have stdout and
+- stderr from the container's start) and stream=1
+
+ - If in detached mode or only stdin is attached:
+
+- Display the container's id
+
+## 3.2 Hijacking
+
+In this version of the API, /attach, uses hijacking to transport stdin,
+stdout and stderr on the same socket. This might change in the future.
+
+## 3.3 CORS requests
+
+To enable cross origin requests to the remote api add the flag
+"--api-enable-cors" when running docker in daemon mode.
+
+    $ docker -d -H="192.168.1.9:2375" --api-enable-cors
diff --git a/_vendor/github.com/moby/moby/docs/api/version-history.md b/_vendor/github.com/moby/moby/docs/api/version-history.md
deleted file mode 100644
index 3184e42d7372..000000000000
--- a/_vendor/github.com/moby/moby/docs/api/version-history.md
+++ /dev/null
@@ -1,991 +0,0 @@
----
-title: "Engine API version history"
-description: "Documentation of changes that have been made to Engine API."
-keywords: "API, Docker, rcli, REST, documentation"
----
-
-<!-- This file is maintained within the moby/moby GitHub
-     repository at https://github.com/moby/moby/. Make all
-     pull requests against that repo. If you see this file in
-     another repository, consider it read-only there, as it will
-     periodically be overwritten by the definitive file. Pull
-     requests which include edits to this file in other repositories
-     will be rejected.
--->
-
-## v1.49 API changes
-
-[Docker Engine API v1.49](https://docs.docker.com/reference/api/engine/version/v1.49/) documentation
-
-* `GET /images/{name}/json` now supports a `platform` parameter (JSON
-  encoded OCI Platform type) allowing to specify a platform of the multi-platform
-  image to inspect.
-  This option is mutually exclusive with the `manifests` option.
-* `GET /info` now returns a `FirewallBackend` containing information about
-  the daemon's firewalling configuration.
-* Deprecated: The  `AllowNondistributableArtifactsCIDRs` and `AllowNondistributableArtifactsHostnames`
-  fields in the `RegistryConfig` struct in the `GET /info` response are omitted
-  in API v1.49.
-* Deprecated: The `ContainerdCommit.Expected`, `RuncCommit.Expected`, and
-  `InitCommit.Expected` fields in the `GET /info` endpoint were deprecated
-  in API v1.48, and are now omitted in API v1.49.
-
-## v1.48 API changes
-
-[Docker Engine API v1.48](https://docs.docker.com/reference/api/engine/version/v1.48/) documentation
-
-* Deprecated: The "error" and "progress" fields in streaming responses for
-  endpoints that return a JSON progress response, such as `POST /images/create`,
-  `POST /images/{name}/push`, and `POST /build` are deprecated. These fields
-  were marked deprecated in API v1.4 (docker v0.6.0) and API v1.8 (docker v0.7.1)
-  respectively, but still returned. These fields will be left empty or will
-  be omitted in a future API version. Users should use the information in the
-  `errorDetail` and `progressDetail` fields instead.
-* Deprecated: The "allow-nondistributable-artifacts" daemon configuration is
-  deprecated and enabled by default. The  `AllowNondistributableArtifactsCIDRs`
-  and `AllowNondistributableArtifactsHostnames` fields in the `RegistryConfig`
-  struct in the `GET /info` response will now always be `null` and will be
-  omitted in API v1.49.
-* Deprecated: The `BridgeNfIptables` and `BridgeNfIp6tables` fields in the 
-  `GET /info` response are now always be `false` and will be omitted in API
-  v1.49. The netfilter module is now loaded on-demand, and no longer during
-  daemon startup, making these fields obsolete.
-* `GET /images/{name}/history` now supports a `platform` parameter (JSON
-  encoded OCI Platform type) that allows to specify a platform to show the
-  history of.
-* `POST /images/{name}/load` and `GET /images/{name}/get` now support a
-  `platform` parameter (JSON encoded OCI Platform type) that allows to specify
-  a platform to load/save. Not passing this parameter will result in
-  loading/saving the full multi-platform image.
-* `POST /containers/create` now includes a warning in the response when setting
-  the container-wide `Config.VolumeDriver` option in combination with volumes
-  defined through `Mounts` because the `VolumeDriver` option has no effect on
-  those volumes. This warning was previously generated by the CLI, but now
-  moved to the daemon so that other clients can also get this warning.
-* `POST /containers/create` now supports `Mount` of type `image` for mounting
-  an image inside a container.
-* Deprecated: The `ContainerdCommit.Expected`, `RuncCommit.Expected`, and
-  `InitCommit.Expected` fields in the `GET /info` endpoint are deprecated
-  and will be omitted in API v1.49.
-* `Sysctls` in `HostConfig` (top level `--sysctl` settings) for `eth0` are
-  no longer migrated to `DriverOpts`, as described in the changes for v1.46.
-* `GET /images/json` and `GET /images/{name}/json` responses now include
-  `Descriptor` field, which contains an OCI descriptor of the image target.
-  The new field will only be populated if the daemon provides a multi-platform
-  image store.
-  WARNING: This is experimental and may change at any time without any backward
-  compatibility.
-* `GET /images/{name}/json` response now will return the `Manifests` field
-  containing information about the sub-manifests contained in the image index.
-  This includes things like platform-specific manifests and build attestations.
-  The new field will only be populated if the request also sets the `manifests`
-  query parameter to `true`.
-  This acts the same as in the `GET /images/json` endpoint.
-  WARNING: This is experimental and may change at any time without any backward compatibility.
-* `GET /containers/{name}/json` now returns an `ImageManifestDescriptor` field
-  containing the OCI descriptor of the platform-specific image manifest of the
-  image that was used to create the container.
-  This field is only populated if the daemon provides a multi-platform image
-  store.
-* `POST /networks/create` now has an `EnableIPv4` field. Setting it to `false`
-  disables IPv4 IPAM for the network. It can only be set to `false` if the
-  daemon has experimental features enabled.
-* `GET /networks/{id}` now returns an `EnableIPv4` field showing whether the
-  network has IPv4 IPAM enabled.
-* `POST /networks/{id}/connect` and `POST /containers/create` now accept a
-  `GwPriority` field in `EndpointsConfig`. This value is used to determine which
-  network endpoint provides the default gateway for the container. The endpoint
-  with the highest priority is selected. If multiple endpoints have the same
-  priority, endpoints are sorted lexicographically by their network name, and
-  the one that sorts first is picked.
-* `GET /containers/json` now returns a `GwPriority` field in `NetworkSettings`
-  for each network endpoint.
-* API debug endpoints (`GET /debug/vars`, `GET /debug/pprof/`, `GET /debug/pprof/cmdline`,
-  `GET /debug/pprof/profile`, `GET /debug/pprof/symbol`, `GET /debug/pprof/trace`,
-  `GET /debug/pprof/{name}`) are now also accessible through the versioned-API
-  paths (`/v<API-version>/<endpoint>`).
-* `POST /build/prune` renames `keep-bytes` to `reserved-space` and now supports
-  additional prune parameters `max-used-space` and `min-free-space`.
-* `GET /containers/json` now returns an `ImageManifestDescriptor` field
-  matching the same field in `/containers/{name}/json`.
-  This field is only populated if the daemon provides a multi-platform image
-  store.
-
-## v1.47 API changes
-
-[Docker Engine API v1.47](https://docs.docker.com/reference/api/engine/version/v1.47/) documentation
-
-* `GET /images/json` response now includes `Manifests` field, which contains
-  information about the sub-manifests included in the image index. This
-  includes things like platform-specific manifests and build attestations.
-  The new field will only be populated if the request also sets the `manifests`
-  query parameter to `true`.
-  WARNING: This is experimental and may change at any time without any backward
-  compatibility.
-* `GET /info` no longer includes warnings when `bridge-nf-call-iptables` or
-  `bridge-nf-call-ip6tables` are disabled when the daemon was started. The
-  `br_netfilter` module is now attempted to be loaded when needed, making those
-  warnings inaccurate. This change is not versioned, and affects all API versions
-  if the daemon has this patch.
-
-## v1.46 API changes
-
-[Docker Engine API v1.46](https://docs.docker.com/reference/api/engine/version/v1.46/) documentation
-
-* `GET /info` now includes a `Containerd` field containing information about
-  the location of the containerd API socket and containerd namespaces used
-  by the daemon to run containers and plugins.
-* `POST /containers/create` field `NetworkingConfig.EndpointsConfig.DriverOpts`,
-  and `POST /networks/{id}/connect` field `EndpointsConfig.DriverOpts`, now
-  support label `com.docker.network.endpoint.sysctls` for setting per-interface
-  sysctls. The value is a comma separated list of sysctl assignments, the
-  interface name must be "IFNAME". For example, to set
-  `net.ipv4.config.eth0.log_martians=1`, use
-  `net.ipv4.config.IFNAME.log_martians=1`. In API versions up-to 1.46, top level
-  `--sysctl` settings for `eth0` will be migrated to `DriverOpts` when possible. 
-  This automatic migration will be removed in a future release.
-* `GET /containers/json` now returns the annotations of containers.
-* `POST /images/{name}/push` now supports a `platform` parameter (JSON encoded
-  OCI Platform type) that allows selecting a specific platform manifest from
-  the multi-platform image.
-* `POST /containers/create` now takes `Options` as part of `HostConfig.Mounts.TmpfsOptions` to set options for tmpfs mounts.
-* `POST /services/create` now takes `Options` as part of `ContainerSpec.Mounts.TmpfsOptions`, to set options for tmpfs mounts.
-* `GET /events` now supports image `create` event that is emitted when a new
-  image is built regardless if it was tagged or not.
-
-### Deprecated Config fields in `GET /images/{name}/json` response
-
-The `Config` field returned by this endpoint (used for "image inspect") returns
-additional fields that are not part of the image's configuration and not part of
-the [Docker Image Spec] and the [OCI Image Spec].
-
-These additional fields are included in the response, due to an
-implementation detail, where the [api/types.ImageInspec] type used
-for the response is using the [container.Config] type.
-
-The [container.Config] type is a superset of the image config, and while the
-image's Config is used as a _template_ for containers created from the image,
-the additional fields are set at runtime (from options passed when creating
-the container) and not taken from the image Config.
-
-These fields are never set (and always return the default value for the type),
-but are not omitted in the response when left empty. As these fields were not
-intended to be part of the image configuration response, they are deprecated,
-and will be removed from the API.
-
-The following fields are currently included in the API response, but
-are not part of the underlying image's Config, and deprecated:
-
-- `Hostname`
-- `Domainname`
-- `AttachStdin`
-- `AttachStdout`
-- `AttachStderr`
-- `Tty`
-- `OpenStdin`
-- `StdinOnce`
-- `Image`
-- `NetworkDisabled` (already omitted unless set)
-- `MacAddress` (already omitted unless set)
-- `StopTimeout` (already omitted unless set)
-
-[Docker image spec]: https://github.com/moby/docker-image-spec/blob/v1.3.1/specs-go/v1/image.go#L19-L32
-[OCI Image Spec]: https://github.com/opencontainers/image-spec/blob/v1.1.0/specs-go/v1/config.go#L24-L62
-[api/types.ImageInspec]: https://github.com/moby/moby/blob/v26.1.4/api/types/types.go#L87-L104
-[container.Config]: https://github.com/moby/moby/blob/v26.1.4/api/types/container/config.go#L47-L82
-
-* `POST /services/create` and `POST /services/{id}/update` now support OomScoreAdj
-
-## v1.45 API changes
-
-[Docker Engine API v1.45](https://docs.docker.com/reference/api/engine/version/v1.45/) documentation
-
-* `POST /containers/create` now supports `VolumeOptions.Subpath` which allows a
-  subpath of a named volume to be mounted.
-* `POST /images/search` will always assume a `false` value for the `is-automated`
-  field. Consequently, searching for `is-automated=true` will yield no results,
-  while `is-automated=false` will be a no-op.
-* `GET /images/{name}/json` no longer includes the `Container` and
-  `ContainerConfig` fields. To access image configuration, use `Config` field
-  instead.
-* The `Aliases` field returned in calls to `GET /containers/{name:.*}/json` no
-  longer contains the short container ID, but instead will reflect exactly the
-  values originally submitted to the `POST /containers/create` endpoint. The
-  newly introduced `DNSNames` should now be used instead when short container
-  IDs are needed.
-
-## v1.44 API changes
-
-[Docker Engine API v1.44](https://docs.docker.com/reference/api/engine/version/v1.44/) documentation
-
-* GET `/images/json` now accepts an `until` filter. This accepts a timestamp and
-  lists all images created before it. The `<timestamp>` can be Unix timestamps,
-  date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`)
-  computed relative to the daemon machine’s time. This change is not versioned,
-  and affects all API versions if the daemon has this patch.
-* The `VirtualSize` field in the `GET /images/{name}/json`, `GET /images/json`,
-  and `GET /system/df` responses is now omitted. Use the `Size` field instead,
-  which contains the same information.
-* Deprecated: The `is_automated` field in the `GET /images/search` response has
-  been deprecated and will always be set to false in the future because Docker
-  Hub is deprecating the `is_automated` field in its search API. The deprecation
-  is not versioned, and applies to all API versions.
-* Deprecated: The `is-automated` filter for the `GET /images/search` endpoint.
-  The `is_automated` field has been deprecated by Docker Hub's search API.
-  Consequently, searching for `is-automated=true` will yield no results. The
-  deprecation is not versioned, and applies to all API versions.
-* Read-only bind mounts are now made recursively read-only on kernel >= 5.12
-  with runtimes which support the feature.
-  `POST /containers/create`, `GET /containers/{id}/json`, and `GET /containers/json` now supports
-  `BindOptions.ReadOnlyNonRecursive` and `BindOptions.ReadOnlyForceRecursive` to customize the behavior.
-* `POST /containers/create` now accepts a `HealthConfig.StartInterval` to set the
-  interval for health checks during the start period.
-* `GET /info` now includes a `CDISpecDirs` field indicating the configured CDI
-  specifications directories. The use of the applied setting requires the daemon
-  to have experimental enabled, and for non-experimental daemons an empty list is
-  always returned.
-* `POST /networks/create` now returns a 400 if the `IPAMConfig` has invalid
-  values. Note that this change is _unversioned_ and applied to all API
-  versions on daemon that support version 1.44.
-* `POST /networks/create` with a duplicated name now fails systematically. As
-  such, the `CheckDuplicate` field is now deprecated. Note that this change is
-  _unversioned_ and applied to all API versions on daemon that support version
-  1.44.
-* `POST /containers/create` now accepts multiple `EndpointSettings` in
-  `NetworkingConfig.EndpointSettings`.
-* `POST /containers/create` and `POST /networks/{id}/connect` will now catch
-  validation errors that were previously only returned during `POST /containers/{id}/start`.
-  These endpoints will also return the full set of validation errors they find,
-  instead of returning only the first one.
-  Note that this change is _unversioned_ and applies to all API versions.
-* `POST /services/create` and `POST /services/{id}/update` now accept `Seccomp`
-  and `AppArmor` fields in the `ContainerSpec.Privileges` object. This allows
-  some configuration of Seccomp and AppArmor in Swarm services.
-* A new endpoint-specific `MacAddress` field has been added to `NetworkSettings.EndpointSettings`
-  on `POST /containers/create`, and to `EndpointConfig` on `POST /networks/{id}/connect`.
-  The container-wide `MacAddress` field in `Config`, on `POST /containers/create`, is now deprecated.
-* The field `Networks` in the `POST /services/create` and `POST /services/{id}/update`
-  requests is now deprecated. You should instead use the field `TaskTemplate.Networks`.
-* The `Container` and `ContainerConfig` fields in the `GET /images/{name}/json`
-  response are deprecated and will no longer be included in API v1.45.
-* `GET /info` now includes `status` properties in `Runtimes`.
-* A new field named `DNSNames` and containing all non-fully qualified DNS names
-  a container takes on a specific network has been added to `GET /containers/{name:.*}/json`.
-* The `Aliases` field returned in calls to `GET /containers/{name:.*}/json` in v1.44 and older
-  versions contains the short container ID. This will change in the next API version, v1.45.
-  Starting with that API version, this specific value will be removed from the `Aliases` field
-  such that this field will reflect exactly the values originally submitted to the
-  `POST /containers/create` endpoint. The newly introduced `DNSNames` should now be used instead.
-* The fields `HairpinMode`, `LinkLocalIPv6Address`, `LinkLocalIPv6PrefixLen`, `SecondaryIPAddresses`,
-  `SecondaryIPv6Addresses` available in `NetworkSettings` when calling `GET /containers/{id}/json` are
-  deprecated and will be removed in a future release. You should instead look for the default network in
-  `NetworkSettings.Networks`.
-* `GET /images/{id}/json` omits the `Created` field (previously it was `0001-01-01T00:00:00Z`)
-  if the `Created` field is missing from the image config.
-
-## v1.43 API changes
-
-[Docker Engine API v1.43](https://docs.docker.com/reference/api/engine/version/v1.43/) documentation
-
-* `POST /containers/create` now accepts `Annotations` as part of `HostConfig`.
-  Can be used to attach arbitrary metadata to the container, which will also be
-  passed to the runtime when the container is started.
-* `GET /images/json` no longer includes hardcoded `<none>:<none>` and
-  `<none>@<none>` in `RepoTags` and`RepoDigests` for untagged images.
-  In such cases, empty arrays will be produced instead.
-* The `VirtualSize` field in the `GET /images/{name}/json`, `GET /images/json`,
-  and `GET /system/df` responses is deprecated and will no longer be included
-  in API v1.44. Use the `Size` field instead, which contains the same information.
-* `GET /info` now includes `no-new-privileges` in the `SecurityOptions` string
-  list when this option is enabled globally. This change is not versioned, and
-  affects all API versions if the daemon has this patch.
-
-## v1.42 API changes
-
-[Docker Engine API v1.42](https://docs.docker.com/reference/api/engine/version/v1.42/) documentation
-
-* Removed the `BuilderSize` field on the `GET /system/df` endpoint. This field
-  was introduced in API 1.31 as part of an experimental feature, and no longer
-  used since API 1.40.
-  Use field `BuildCache` instead to track storage used by the builder component.
-* `POST /containers/{id}/stop` and `POST /containers/{id}/restart` now accept a
-  `signal` query parameter, which allows overriding the container's default stop-
-  signal.
-* `GET /images/json` now accepts query parameter `shared-size`. When set `true`,
-  images returned will include `SharedSize`, which provides the size on disk shared
-  with other images present on the system.
-* `GET /system/df` now accepts query parameter `type`. When set,
-  computes and returns data only for the specified object type.
-  The parameter can be specified multiple times to select several object types.
-  Supported values are: `container`, `image`, `volume`, `build-cache`.
-* `GET /system/df` can now be used concurrently. If a request is made while a
-  previous request is still being processed, the request will receive the result
-  of the already running calculation, once completed. Previously, an error
-  (`a disk usage operation is already running`) would be returned in this
-  situation. This change is not versioned, and affects all API versions if the
-  daemon has this patch.
-* The `POST /images/create` now supports both the operating system and architecture
-  that is passed through the `platform` query parameter when using the `fromSrc`
-  option to import an image from an archive. Previously, only the operating system
-  was used and the architecture was ignored. If no `platform` option is set, the
-  host's operating system and architecture as used as default. This change is not
-  versioned, and affects all API versions if the daemon has this patch.
-* The `POST /containers/{id}/wait` endpoint now returns a `400` status code if an
-  invalid `condition` is provided (on API 1.30 and up).
-* Removed the `KernelMemory` field from the `POST /containers/create` and
-  `POST /containers/{id}/update` endpoints, any value it is set to will be ignored
-  on API version `v1.42` and up. Older API versions still accept this field, but
-  may take no effect, depending on the kernel version and OCI runtime in use.
-* `GET /containers/{id}/json` now omits the `KernelMemory` and `KernelMemoryTCP`
-  if they are not set.
-* `GET /info` now omits the `KernelMemory` and `KernelMemoryTCP` if they are not
-  supported by the host or host's configuration (if cgroups v2 are in use).
-* `GET /_ping` and `HEAD /_ping` now return `Builder-Version` by default.
-  This header contains the default builder to use, and is a recommendation as
-  advertised by the daemon. However, it is up to the client to choose which builder
-  to use.
-
-  The default value on Linux is version "2" (BuildKit), but the daemon can be
-  configured to recommend version "1" (classic Builder). Windows does not yet
-  support BuildKit for native Windows images, and uses "1" (classic builder) as
-  a default.
-
-  This change is not versioned, and affects all API versions if the daemon has
-  this patch.
-* `GET /_ping` and `HEAD /_ping` now return a `Swarm` header, which allows a
-  client to detect if Swarm is enabled on the daemon, without having to call
-  additional endpoints.
-  This change is not versioned, and affects all API versions if the daemon has
-  this patch. Clients must consider this header "optional", and fall back to
-  using other endpoints to get this information if the header is not present.
-
-  The `Swarm` header can contain one of the following values:
-
-    - "inactive"
-    - "pending"
-    - "error"
-    - "locked"
-    - "active/worker"
-    - "active/manager"
-* `POST /containers/create` for Windows containers now accepts a new syntax in
-  `HostConfig.Resources.Devices.PathOnHost`. As well as the existing `class/<GUID>`
-  syntax, `<IDType>://<ID>` is now recognised. Support for specific `<IDType>` values
-  depends on the underlying implementation and Windows version. This change is not
-  versioned, and affects all API versions if the daemon has this patch.
-* `GET /containers/{id}/attach`, `GET /exec/{id}/start`, `GET /containers/{id}/logs`
-  `GET /services/{id}/logs` and `GET /tasks/{id}/logs` now set Content-Type header
-  to `application/vnd.docker.multiplexed-stream` when a multiplexed stdout/stderr
-  stream is sent to client, `application/vnd.docker.raw-stream` otherwise.
-* `POST /volumes/create` now accepts a new `ClusterVolumeSpec` to create a cluster
-  volume (CNI). This option can only be used if the daemon is a Swarm manager.
-  The Volume response on creation now also can contain a `ClusterVolume` field
-  with information about the created volume.
-* The `BuildCache.Parent` field, as returned by `GET /system/df` is deprecated
-  and is now omitted. API versions before v1.42 continue to include this field.
-* `GET /system/df` now includes a new `Parents` field, for "build-cache" records,
-  which contains a list of parent IDs for the build-cache record.
-* Volume information returned by `GET /volumes/{name}`, `GET /volumes` and
-  `GET /system/df` can now contain a `ClusterVolume` if the volume is a cluster
-  volume (requires the daemon to be a Swarm manager).
-* The `Volume` type, as returned by `Added new `ClusterVolume` fields
-* Added a new `PUT /volumes{name}` endpoint to update cluster volumes (CNI).
-  Cluster volumes are only supported if the daemon is a Swarm manager.
-* `GET /containers/{name}/attach/ws` endpoint now accepts `stdin`, `stdout` and
-  `stderr` query parameters to only attach to configured streams.
-
-  NOTE: These parameters were documented before in older API versions, but not
-  actually supported. API versions before v1.42 continue to ignore these parameters
-  and default to attaching to all streams. To preserve the pre-v1.42 behavior,
-  set all three query parameters (`?stdin=1,stdout=1,stderr=1`).
-* `POST /containers/create` on Linux now respects the `HostConfig.ConsoleSize` property.
-  Container is immediately created with the desired terminal size and clients no longer
-  need to set the desired size on their own.
-* `POST /containers/create` allow to set `CreateMountpoint` for host path to be
-  created if missing. This brings parity with `Binds`
-* `POST /containers/create` rejects request if BindOptions|VolumeOptions|TmpfsOptions
-  is set with a non-matching mount Type.
-* `POST /containers/{id}/exec` now accepts an optional `ConsoleSize` parameter.
-  It allows to set the console size of the executed process immediately when it's created.
-* `POST /volumes/prune` will now only prune "anonymous" volumes (volumes which were not given a name) by default. A new filter parameter `all` can be set to a truth-y value (`true`, `1`) to get the old behavior.
-
-## v1.41 API changes
-
-[Docker Engine API v1.41](https://docs.docker.com/reference/api/engine/version/v1.41/) documentation
-
-* `GET /events` now returns `prune` events after pruning resources have completed.
-  Prune events are returned for `container`, `network`, `volume`, `image`, and
-  `builder`, and have a `reclaimed` attribute, indicating the amount of space
-  reclaimed (in bytes).
-* `GET /info` now returns a `CgroupVersion` field, containing the cgroup version.
-* `GET /info` now returns a `DefaultAddressPools` field, containing a list of
-  custom default address pools for local networks, which can be specified in the
-  `daemon.json` file or `--default-address-pool` dockerd option.
-* `POST /services/create` and `POST /services/{id}/update` now supports `BindOptions.NonRecursive`.
-* The `ClusterStore` and `ClusterAdvertise` fields in `GET /info` are deprecated
-  and are now omitted if they contain an empty value. This change is not versioned,
-  and affects all API versions if the daemon has this patch.
-* The `filter` (singular) query parameter, which was deprecated in favor of the
-  `filters` option in Docker 1.13, has now been removed from the `GET /images/json`
-  endpoint. The parameter remains available when using API version 1.40 or below.
-* `GET /services` now returns `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
-* `GET /services/{id}` now returns `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
-* `POST /services/create` now accepts `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
-* `POST /services/{id}/update` now accepts `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
-* `GET /tasks` now  returns `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
-* `GET /tasks/{id}` now  returns `CapAdd` and `CapDrop` as part of the `ContainerSpec`.
-* `GET /services` now returns `Pids` in `TaskTemplate.Resources.Limits`.
-* `GET /services/{id}` now returns `Pids` in `TaskTemplate.Resources.Limits`.
-* `POST /services/create` now accepts `Pids` in `TaskTemplate.Resources.Limits`.
-* `POST /services/{id}/update` now accepts `Pids` in `TaskTemplate.Resources.Limits`
-  to limit the maximum number of PIDs.
-* `GET /tasks` now  returns `Pids` in `TaskTemplate.Resources.Limits`.
-* `GET /tasks/{id}` now  returns `Pids` in `TaskTemplate.Resources.Limits`.
-* `POST /containers/create` now accepts a `platform` query parameter in the format
-  `os[/arch[/variant]]`.
-
-  When set, the daemon checks if the requested image is present in the local image
-  cache with the given OS and Architecture, and otherwise returns a `404` status.
-
-  If the option is _not_ set, the host's native OS and Architecture are used to
-  look up the image in the image cache. However, if no platform is passed and the
-  given image _does_ exist in the local image cache, but its OS or architecture
-  do not match, the container is created with the available image, and a warning
-  is added to the `Warnings` field in the response, for example;
-
-      WARNING: The requested image's platform (linux/arm64/v8) does not
-               match the detected host platform (linux/amd64) and no
-               specific platform was requested
-
-* `POST /containers/create` on Linux now accepts the `HostConfig.CgroupnsMode` property.
-  Set the property to `host` to create the container in the daemon's cgroup namespace, or
-  `private` to create the container in its own private cgroup namespace.  The per-daemon
-  default is `host`, and can be changed by using the`CgroupNamespaceMode` daemon configuration
-  parameter.
-* `GET /info` now  returns an `OSVersion` field, containing the operating system's
-  version. This change is not versioned, and affects all API versions if the daemon
-  has this patch.
-* `GET /info` no longer returns the `SystemStatus` field if it does not have a
-  value set. This change is not versioned, and affects all API versions if the
-  daemon has this patch.
-* `GET /services` now accepts query parameter `status`. When set `true`,
-  services returned will include `ServiceStatus`, which provides Desired,
-  Running, and Completed task counts for the service.
-* `GET /services` may now include `ReplicatedJob` or `GlobalJob` as the `Mode`
-  in a `ServiceSpec`.
-* `GET /services/{id}` may now include `ReplicatedJob` or `GlobalJob` as the
-  `Mode` in a `ServiceSpec`.
-* `POST /services/create` now accepts `ReplicatedJob or `GlobalJob` as the `Mode`
-  in the `ServiceSpec.
-* `POST /services/{id}/update` accepts updating the fields of the
-  `ReplicatedJob` object in the `ServiceSpec.Mode`. The service mode still
-  cannot be changed, however.
-* `GET /services` now includes `JobStatus` on Services with mode
-  `ReplicatedJob` or `GlobalJob`.
-* `GET /services/{id}` now includes `JobStatus` on Services with mode
-  `ReplicatedJob` or `GlobalJob`.
-* `GET /tasks` now includes `JobIteration` on Tasks spawned from a job-mode
-  service.
-* `GET /tasks/{id}` now includes `JobIteration` on the task if spawned from a
-  job-mode service.
-* `GET /containers/{id}/stats` now accepts a query param (`one-shot`) which, when used with `stream=false` fetches a
-  single set of stats instead of waiting for two collection cycles to have 2 CPU stats over a 1 second period.
-* The `KernelMemory` field in `HostConfig.Resources` is now deprecated.
-* The `KernelMemory` field in `Info` is now deprecated.
-* `GET /services` now returns `Ulimits` as part of `ContainerSpec`.
-* `GET /services/{id}` now returns `Ulimits` as part of `ContainerSpec`.
-* `POST /services/create` now accepts `Ulimits` as part of `ContainerSpec`.
-* `POST /services/{id}/update` now accepts `Ulimits` as part of `ContainerSpec`.
-
-## v1.40 API changes
-
-[Docker Engine API v1.40](https://docs.docker.com/reference/api/engine/version/v1.40/) documentation
-
-* The `/_ping` endpoint can now be accessed both using `GET` or `HEAD` requests.
-  when accessed using a `HEAD` request, all headers are returned, but the body
-  is empty (`Content-Length: 0`). This change is not versioned, and affects all
-  API versions if the daemon has this patch. Clients are recommended to try
-  using `HEAD`, but fallback to `GET` if the `HEAD` requests fails.
-* `GET /_ping` and `HEAD /_ping` now set `Cache-Control` and `Pragma` headers to
-  prevent the result from being cached. This change is not versioned, and affects
-  all API versions if the daemon has this patch.
-* `GET /services` now returns `Sysctls` as part of the `ContainerSpec`.
-* `GET /services/{id}` now returns `Sysctls` as part of the `ContainerSpec`.
-* `POST /services/create` now accepts `Sysctls` as part of the `ContainerSpec`.
-* `POST /services/{id}/update` now accepts `Sysctls` as part of the `ContainerSpec`.
-* `POST /services/create` now accepts `Config` as part of `ContainerSpec.Privileges.CredentialSpec`.
-* `POST /services/{id}/update` now accepts `Config` as part of `ContainerSpec.Privileges.CredentialSpec`.
-* `POST /services/create` now includes `Runtime` as an option in `ContainerSpec.Configs`
-* `POST /services/{id}/update` now includes `Runtime` as an option in `ContainerSpec.Configs`
-* `GET /tasks` now  returns `Sysctls` as part of the `ContainerSpec`.
-* `GET /tasks/{id}` now  returns `Sysctls` as part of the `ContainerSpec`.
-* `GET /networks` now supports a `dangling` filter type. When set to `true` (or
-  `1`), the endpoint returns all networks that are not in use by a container. When
-  set to `false` (or `0`), only networks that are in use by one or more containers
-  are returned.
-* `GET /nodes` now supports a filter type `node.label` filter to filter nodes based
-  on the node.label. The format of the label filter is `node.label=<key>`/`node.label=<key>=<value>`
-  to return those with the specified labels, or `node.label!=<key>`/`node.label!=<key>=<value>`
-  to return those without the specified labels.
-* `POST /containers/create` now accepts a `fluentd-async` option in `HostConfig.LogConfig.Config`
-  when using the Fluentd logging driver. This option deprecates the `fluentd-async-connect`
-  option, which remains functional, but will be removed in a future release. Users
-  are encouraged to use the `fluentd-async` option going forward. This change is
-  not versioned, and affects all API versions if the daemon has this patch.
-* `POST /containers/create` now accepts a `fluentd-request-ack` option in
-  `HostConfig.LogConfig.Config` when using the Fluentd logging driver. If enabled,
-  the Fluentd logging driver sends the chunk option with a unique ID. The server
-  will respond with an acknowledgement. This option improves the reliability of
-  the message transmission. This change is not versioned, and affects all API
-  versions if the daemon has this patch.
-* `POST /containers/create`, `GET /containers/{id}/json`, and `GET /containers/json` now supports
-  `BindOptions.NonRecursive`.
-* `POST /swarm/init` now accepts a `DataPathPort` property to set data path port number.
-* `GET /info` now returns information about `DataPathPort` that is currently used in swarm
-* `GET /info` now returns `PidsLimit` boolean to indicate if the host kernel has
-  PID limit support enabled.
-* `GET /info` now includes `name=rootless` in `SecurityOptions` when the daemon is running in
-  rootless mode.  This change is not versioned, and affects all API versions if the daemon has
-  this patch.
-* `GET /info` now returns `none` as `CgroupDriver` when the daemon is running in rootless mode.
-  This change is not versioned, and affects all API versions if the daemon has this patch.
-* `POST /containers/create` now accepts `DeviceRequests` as part of `HostConfig`.
-  Can be used to set Nvidia GPUs.
-* `GET /swarm` endpoint now returns DataPathPort info
-* `POST /containers/create` now takes `KernelMemoryTCP` field to set hard limit for kernel TCP buffer memory.
-* `GET /service` now  returns `MaxReplicas` as part of the `Placement`.
-* `GET /service/{id}` now  returns `MaxReplicas` as part of the `Placement`.
-* `POST /service/create` and `POST /services/(id or name)/update` now take the field `MaxReplicas`
-  as part of the service `Placement`, allowing to specify maximum replicas per node for the service.
-* `POST /containers/create` on Linux now creates a container with `HostConfig.IpcMode=private`
-  by default, if IpcMode is not explicitly specified. The per-daemon default can be changed
-  back to `shareable` by using `DefaultIpcMode` daemon configuration parameter.
-* `POST /containers/{id}/update` now accepts a `PidsLimit` field to tune a container's
-  PID limit. Set `0` or `-1` for unlimited. Leave `null` to not change the current value.
-* `POST /build` now accepts `outputs` key for configuring build outputs when using BuildKit mode.
-
-## V1.39 API changes
-
-[Docker Engine API v1.39](https://docs.docker.com/reference/api/engine/version/v1.39/) documentation
-
-* `GET /info` now returns an empty string, instead of `<unknown>` for `KernelVersion`
-  and `OperatingSystem` if the daemon was unable to obtain this information.
-* `GET /info` now returns information about the product license, if a license
-  has been applied to the daemon.
-* `GET /info` now returns a `Warnings` field, containing warnings and informational
-  messages about missing features, or issues related to the daemon configuration.
-* `POST /swarm/init` now accepts a `DefaultAddrPool` property to set global scope default address pool
-* `POST /swarm/init` now accepts a `SubnetSize` property to set global scope networks by giving the
-  length of the subnet masks for every such network
-* `POST /session` (added in [V1.31](#v131-api-changes) is no longer experimental.
-  This endpoint can be used to run interactive long-running protocols between the
-  client and the daemon.
-
-## V1.38 API changes
-
-[Docker Engine API v1.38](https://docs.docker.com/reference/api/engine/version/v1.38/) documentation
-
-
-* `GET /tasks` and `GET /tasks/{id}` now return a `NetworkAttachmentSpec` field,
-  containing the `ContainerID` for non-service containers connected to "attachable"
-  swarm-scoped networks.
-
-## v1.37 API changes
-
-[Docker Engine API v1.37](https://docs.docker.com/reference/api/engine/version/v1.37/) documentation
-
-* `POST /containers/create` and `POST /services/create` now supports exposing SCTP ports.
-* `POST /configs/create` and `POST /configs/{id}/create` now accept a `Templating` driver.
-* `GET /configs` and `GET /configs/{id}` now return the `Templating` driver of the config.
-* `POST /secrets/create` and `POST /secrets/{id}/create` now accept a `Templating` driver.
-* `GET /secrets` and `GET /secrets/{id}` now return the `Templating` driver of the secret.
-
-## v1.36 API changes
-
-[Docker Engine API v1.36](https://docs.docker.com/reference/api/engine/version/v1.36/) documentation
-
-* `Get /events` now return `exec_die` event when an exec process terminates.
-
-
-## v1.35 API changes
-
-[Docker Engine API v1.35](https://docs.docker.com/reference/api/engine/version/v1.35/) documentation
-
-* `POST /services/create` and `POST /services/(id)/update` now accepts an
-  `Isolation` field on container spec to set the Isolation technology of the
-  containers running the service (`default`, `process`, or `hyperv`). This
-  configuration is only used for Windows containers.
-* `GET /containers/(name)/logs` now supports an additional query parameter: `until`,
-  which returns log lines that occurred before the specified timestamp.
-* `POST /containers/{id}/exec` now accepts a `WorkingDir` property to set the
-  work-dir for the exec process, independent of the container's work-dir.
-* `Get /version` now returns a `Platform.Name` field, which can be used by products
-  using Moby as a foundation to return information about the platform.
-* `Get /version` now returns a `Components` field, which can be used to return
-  information about the components used. Information about the engine itself is
-  now included as a "Component" version, and contains all information from the
-  top-level `Version`, `GitCommit`, `APIVersion`, `MinAPIVersion`, `GoVersion`,
-  `Os`, `Arch`, `BuildTime`, `KernelVersion`, and `Experimental` fields. Going
-  forward, the information from the `Components` section is preferred over their
-  top-level counterparts.
-
-
-## v1.34 API changes
-
-[Docker Engine API v1.34](https://docs.docker.com/reference/api/engine/version/v1.34/) documentation
-
-* `POST /containers/(name)/wait?condition=removed` now also also returns
-  in case of container removal failure. A pointer to a structure named
-  `Error` added to the response JSON in order to indicate a failure.
-  If `Error` is `null`, container removal has succeeded, otherwise
-  the test of an error message indicating why container removal has failed
-  is available from `Error.Message` field.
-
-## v1.33 API changes
-
-[Docker Engine API v1.33](https://docs.docker.com/reference/api/engine/version/v1.33/) documentation
-
-* `GET /events` now supports filtering 4 more kinds of events: `config`, `node`,
-`secret` and `service`.
-
-## v1.32 API changes
-
-[Docker Engine API v1.32](https://docs.docker.com/reference/api/engine/version/v1.32/) documentation
-
-* `POST /images/create` now accepts a `platform` parameter in the form of `os[/arch[/variant]]`.
-* `POST /containers/create` now accepts additional values for the
-  `HostConfig.IpcMode` property. New values are `private`, `shareable`,
-  and `none`.
-* `DELETE /networks/{id or name}` fixed issue where a `name` equal to another
-  network's name was able to mask that `id`. If both a network with the given
-  _name_ exists, and a network with the given _id_, the network with the given
-  _id_ is now deleted. This change is not versioned, and affects all API versions
-  if the daemon has this patch.
-
-## v1.31 API changes
-
-[Docker Engine API v1.31](https://docs.docker.com/reference/api/engine/version/v1.31/) documentation
-
-* `DELETE /secrets/(name)` now returns status code 404 instead of 500 when the secret does not exist.
-* `POST /secrets/create` now returns status code 409 instead of 500 when creating an already existing secret.
-* `POST /secrets/create` now accepts a `Driver` struct, allowing the
-  `Name` and driver-specific `Options` to be passed to store a secrets
-  in an external secrets store. The `Driver` property can be omitted
-  if the default (internal) secrets store is used.
-* `GET /secrets/(id)` and `GET /secrets` now return a `Driver` struct,
-  containing the `Name` and driver-specific `Options` of the external
-  secrets store used to store the secret. The `Driver` property is
-  omitted if no external store is used.
-* `POST /secrets/(name)/update` now returns status code 400 instead of 500 when updating a secret's content which is not the labels.
-* `POST /nodes/(name)/update` now returns status code 400 instead of 500 when demoting last node fails.
-* `GET /networks/(id or name)` now takes an optional query parameter `scope` that will filter the network based on the scope (`local`, `swarm`, or `global`).
-* `POST /session` is a new endpoint that can be used for running interactive long-running protocols between client and
-  the daemon. This endpoint is experimental and only available if the daemon is started with experimental features
-  enabled.
-* `GET /images/(name)/get` now includes an `ImageMetadata` field which contains image metadata that is local to the engine and not part of the image config.
-* `POST /services/create` now accepts a `PluginSpec` when `TaskTemplate.Runtime` is set to `plugin`
-* `GET /events` now supports config events `create`, `update` and `remove` that are emitted when users create, update or remove a config
-* `GET /volumes/` and `GET /volumes/{name}` now return a `CreatedAt` field,
-  containing the date/time the volume was created. This field is omitted if the
-  creation date/time for the volume is unknown. For volumes with scope "global",
-  this field represents the creation date/time of the local _instance_ of the
-  volume, which may differ from instances of the same volume on different nodes.
-* `GET /system/df` now returns a `CreatedAt` field for `Volumes`. Refer to the
-  `/volumes/` endpoint for a description of this field.
-
-## v1.30 API changes
-
-[Docker Engine API v1.30](https://docs.docker.com/reference/api/engine/version/v1.30/) documentation
-
-* `GET /info` now returns the list of supported logging drivers, including plugins.
-* `GET /info` and `GET /swarm` now returns the cluster-wide swarm CA info if the node is in a swarm: the cluster root CA certificate, and the cluster TLS
- leaf certificate issuer's subject and public key. It also displays the desired CA signing certificate, if any was provided as part of the spec.
-* `POST /build/` now (when not silent) produces an `Aux` message in the JSON output stream with payload `types.BuildResult` for each image produced. The final such message will reference the image resulting from the build.
-* `GET /nodes` and `GET /nodes/{id}` now returns additional information about swarm TLS info if the node is part of a swarm: the trusted root CA, and the
- issuer's subject and public key.
-* `GET /distribution/(name)/json` is a new endpoint that returns a JSON output stream with payload `types.DistributionInspect` for an image name. It includes a descriptor with the digest, and supported platforms retrieved from directly contacting the registry.
-* `POST /swarm/update` now accepts 3 additional parameters as part of the swarm spec's CA configuration; the desired CA certificate for
- the swarm, the desired CA key for the swarm (if not using an external certificate), and an optional parameter to force swarm to
- generate and rotate to a new CA certificate/key pair.
-* `POST /service/create` and `POST /services/(id or name)/update` now take the field `Platforms` as part of the service `Placement`, allowing to specify platforms supported by the service.
-* `POST /containers/(name)/wait` now accepts a `condition` query parameter to indicate which state change condition to wait for. Also, response headers are now returned immediately to acknowledge that the server has registered a wait callback for the client.
-* `POST /swarm/init` now accepts a `DataPathAddr` property to set the IP-address or network interface to use for data traffic
-* `POST /swarm/join` now accepts a `DataPathAddr` property to set the IP-address or network interface to use for data traffic
-* `GET /events` now supports service, node and secret events which are emitted when users create, update and remove service, node and secret
-* `GET /events` now supports network remove event which is emitted when users remove a swarm scoped network
-* `GET /events` now supports a filter type `scope` in which supported value could be swarm and local
-* `PUT /containers/(name)/archive` now accepts a `copyUIDGID` parameter to allow copy UID/GID maps to dest file or dir.
-
-## v1.29 API changes
-
-[Docker Engine API v1.29](https://docs.docker.com/reference/api/engine/version/v1.29/) documentation
-
-* `DELETE /networks/(name)` now allows to remove the ingress network, the one used to provide the routing-mesh.
-* `POST /networks/create` now supports creating the ingress network, by specifying an `Ingress` boolean field. As of now this is supported only when using the overlay network driver.
-* `GET /networks/(name)` now returns an `Ingress` field showing whether the network is the ingress one.
-* `GET /networks/` now supports a `scope` filter to filter networks based on the network mode (`swarm`, `global`, or `local`).
-* `POST /containers/create`, `POST /service/create` and `POST /services/(id or name)/update` now takes the field `StartPeriod` as a part of the `HealthConfig` allowing for specification of a period during which the container should not be considered unhealthy even if health checks do not pass.
-* `GET /services/(id)` now accepts an `insertDefaults` query-parameter to merge default values into the service inspect output.
-* `POST /containers/prune`, `POST /images/prune`, `POST /volumes/prune`, and `POST /networks/prune` now support a `label` filter to filter containers, images, volumes, or networks based on the label. The format of the label filter could be `label=<key>`/`label=<key>=<value>` to remove those with the specified labels, or `label!=<key>`/`label!=<key>=<value>` to remove those without the specified labels.
-* `POST /services/create` now accepts `Privileges` as part of `ContainerSpec`. Privileges currently include
-  `CredentialSpec` and `SELinuxContext`.
-
-## v1.28 API changes
-
-[Docker Engine API v1.28](https://docs.docker.com/reference/api/engine/version/v1.28/) documentation
-
-* `POST /containers/create` now includes a `Consistency` field to specify the consistency level for each `Mount`, with possible values `default`, `consistent`, `cached`, or `delegated`.
-* `GET /containers/create` now takes a `DeviceCgroupRules` field in `HostConfig` allowing to set custom device cgroup rules for the created container.
-* Optional query parameter `verbose` for `GET /networks/(id or name)` will now list all services with all the tasks, including the non-local tasks on the given network.
-* `GET /containers/(id or name)/attach/ws` now returns WebSocket in binary frame format for API version >= v1.28, and returns WebSocket in text frame format for API version< v1.28, for the purpose of backward-compatibility.
-* `GET /networks` is optimised only to return list of all networks and network specific information. List of all containers attached to a specific network is removed from this API and is only available using the network specific `GET /networks/{network-id}`.
-* `GET /containers/json` now supports `publish` and `expose` filters to filter containers that expose or publish certain ports.
-* `POST /services/create` and `POST /services/(id or name)/update` now accept the `ReadOnly` parameter, which mounts the container's root filesystem as read only.
-* `POST /build` now accepts `extrahosts` parameter to specify a host to ip mapping to use during the build.
-* `POST /services/create` and `POST /services/(id or name)/update` now accept a `rollback` value for `FailureAction`.
-* `POST /services/create` and `POST /services/(id or name)/update` now accept an optional `RollbackConfig` object which specifies rollback options.
-* `GET /services` now supports a `mode` filter to filter services based on the service mode (either `global` or `replicated`).
-* `POST /containers/(name)/update` now supports updating `NanoCpus` that represents CPU quota in units of 10<sup>-9</sup> CPUs.
-* `POST /plugins/{name}/disable` now accepts a `force` query-parameter to disable a plugin even if still in use.
-
-## v1.27 API changes
-
-[Docker Engine API v1.27](https://docs.docker.com/reference/api/engine/version/v1.27/) documentation
-
-* `GET /containers/(id or name)/stats` now includes an `online_cpus` field in both `precpu_stats` and `cpu_stats`. If this field is `nil` then for compatibility with older daemons the length of the corresponding `cpu_usage.percpu_usage` array should be used.
-
-## v1.26 API changes
-
-[Docker Engine API v1.26](https://docs.docker.com/reference/api/engine/version/v1.26/) documentation
-
-* `POST /plugins/(plugin name)/upgrade` upgrade a plugin.
-
-## v1.25 API changes
-
-[Docker Engine API v1.25](https://docs.docker.com/reference/api/engine/version/v1.25/) documentation
-
-* The API version is now required in all API calls. Instead of just requesting, for example, the URL `/containers/json`, you must now request `/v1.25/containers/json`.
-* `GET /version` now returns `MinAPIVersion`.
-* `POST /build` accepts `networkmode` parameter to specify network used during build.
-* `GET /images/(name)/json` now returns `OsVersion` if populated
-* `GET /images/(name)/json` no longer contains the `RootFS.BaseLayer` field. This
-  field was used for Windows images that used a base-image that was pre-installed
-  on the host (`RootFS.Type` `layers+base`), which is no longer supported, and
-  the `RootFS.BaseLayer` field has been removed.
-* `GET /info` now returns `Isolation`.
-* `POST /containers/create` now takes `AutoRemove` in HostConfig, to enable auto-removal of the container on daemon side when the container's process exits.
-* `GET /containers/json` and `GET /containers/(id or name)/json` now return `"removing"` as a value for the `State.Status` field if the container is being removed. Previously, "exited" was returned as status.
-* `GET /containers/json` now accepts `removing` as a valid value for the `status` filter.
-* `GET /containers/json` now supports filtering containers by `health` status.
-* `DELETE /volumes/(name)` now accepts a `force` query parameter to force removal of volumes that were already removed out of band by the volume driver plugin.
-* `POST /containers/create/` and `POST /containers/(name)/update` now validates restart policies.
-* `POST /containers/create` now validates IPAMConfig in NetworkingConfig, and returns error for invalid IPv4 and IPv6 addresses (`--ip` and `--ip6` in `docker create/run`).
-* `POST /containers/create` now takes a `Mounts` field in `HostConfig` which replaces `Binds`, `Volumes`, and `Tmpfs`. *note*: `Binds`, `Volumes`, and `Tmpfs` are still available and can be combined with `Mounts`.
-* `POST /build` now performs a preliminary validation of the `Dockerfile` before starting the build, and returns an error if the syntax is incorrect. Note that this change is _unversioned_ and applied to all API versions.
-* `POST /build` accepts `cachefrom` parameter to specify images used for build cache.
-* `GET /networks/` endpoint now correctly returns a list of *all* networks,
-  instead of the default network if a trailing slash is provided, but no `name`
-  or `id`.
-* `DELETE /containers/(name)` endpoint now returns an error of `removal of container name is already in progress` with status code of 400, when container name is in a state of removal in progress.
-* `GET /containers/json` now supports a `is-task` filter to filter
-  containers that are tasks (part of a service in swarm mode).
-* `POST /containers/create` now takes `StopTimeout` field.
-* `POST /services/create` and `POST /services/(id or name)/update` now accept `Monitor` and `MaxFailureRatio` parameters, which control the response to failures during service updates.
-* `POST /services/(id or name)/update` now accepts a `ForceUpdate` parameter inside the `TaskTemplate`, which causes the service to be updated even if there are no changes which would ordinarily trigger an update.
-* `POST /services/create` and `POST /services/(id or name)/update` now return a `Warnings` array.
-* `GET /networks/(name)` now returns field `Created` in response to show network created time.
-* `POST /containers/(id or name)/exec` now accepts an `Env` field, which holds a list of environment variables to be set in the context of the command execution.
-* `GET /volumes`, `GET /volumes/(name)`, and `POST /volumes/create` now return the `Options` field which holds the driver specific options to use for when creating the volume.
-* `GET /exec/(id)/json` now returns `Pid`, which is the system pid for the exec'd process.
-* `POST /containers/prune` prunes stopped containers.
-* `POST /images/prune` prunes unused images.
-* `POST /volumes/prune` prunes unused volumes.
-* `POST /networks/prune` prunes unused networks.
-* Every API response now includes a `Docker-Experimental` header specifying if experimental features are enabled (value can be `true` or `false`).
-* Every API response now includes a `API-Version` header specifying the default API version of the server.
-* The `hostConfig` option now accepts the fields `CpuRealtimePeriod` and `CpuRtRuntime` to allocate cpu runtime to rt tasks when `CONFIG_RT_GROUP_SCHED` is enabled in the kernel.
-* The `SecurityOptions` field within the `GET /info` response now includes `userns` if user namespaces are enabled in the daemon.
-* `GET /nodes` and `GET /node/(id or name)` now return `Addr` as part of a node's `Status`, which is the address that that node connects to the manager from.
-* The `HostConfig` field now includes `NanoCpus` that represents CPU quota in units of 10<sup>-9</sup> CPUs.
-* `GET /info` now returns more structured information about security options.
-* The `HostConfig` field now includes `CpuCount` that represents the number of CPUs available for execution by the container. Windows daemon only.
-* `POST /services/create` and `POST /services/(id or name)/update` now accept the `TTY` parameter, which allocate a pseudo-TTY in container.
-* `POST /services/create` and `POST /services/(id or name)/update` now accept the `DNSConfig` parameter, which specifies DNS related configurations in resolver configuration file (resolv.conf) through `Nameservers`, `Search`, and `Options`.
-* `POST /services/create` and `POST /services/(id or name)/update` now support
-  `node.platform.arch` and `node.platform.os` constraints in the services
-  `TaskSpec.Placement.Constraints` field.
-* `GET /networks/(id or name)` now includes IP and name of all peers nodes for swarm mode overlay networks.
-* `GET /plugins` list plugins.
-* `POST /plugins/pull?name=<plugin name>` pulls a plugin.
-* `GET /plugins/(plugin name)` inspect a plugin.
-* `POST /plugins/(plugin name)/set` configure a plugin.
-* `POST /plugins/(plugin name)/enable` enable a plugin.
-* `POST /plugins/(plugin name)/disable` disable a plugin.
-* `POST /plugins/(plugin name)/push` push a plugin.
-* `POST /plugins/create?name=(plugin name)` create a plugin.
-* `DELETE /plugins/(plugin name)` delete a plugin.
-* `POST /node/(id or name)/update` now accepts both `id` or `name` to identify the node to update.
-* `GET /images/json` now support a `reference` filter.
-* `GET /secrets` returns information on the secrets.
-* `POST /secrets/create` creates a secret.
-* `DELETE /secrets/{id}` removes the secret `id`.
-* `GET /secrets/{id}` returns information on the secret `id`.
-* `POST /secrets/{id}/update` updates the secret `id`.
-* `POST /services/(id or name)/update` now accepts service name or prefix of service id as a parameter.
-* `POST /containers/create` added 2 built-in log-opts that work on all logging drivers,
-  `mode` (`blocking`|`non-blocking`), and `max-buffer-size` (e.g. `2m`) which enables a non-blocking log buffer.
-* `POST /containers/create` now takes `HostConfig.Init` field to run an init
-  inside the container that forwards signals and reaps processes.
-
-## v1.24 API changes
-
-[Docker Engine API v1.24](v1.24.md) documentation
-
-* `POST /containers/create` now takes `StorageOpt` field.
-* `GET /info` now returns `SecurityOptions` field, showing if `apparmor`, `seccomp`, or `selinux` is supported.
-* `GET /info` no longer returns the `ExecutionDriver` property. This property was no longer used after integration
-  with ContainerD in Docker 1.11.
-* `GET /networks` now supports filtering by `label` and `driver`.
-* `GET /containers/json` now supports filtering containers by `network` name or id.
-* `POST /containers/create` now takes `IOMaximumBandwidth` and `IOMaximumIOps` fields. Windows daemon only.
-* `POST /containers/create` now returns an HTTP 400 "bad parameter" message
-  if no command is specified (instead of an HTTP 500 "server error")
-* `GET /images/search` now takes a `filters` query parameter.
-* `GET /events` now supports a `reload` event that is emitted when the daemon configuration is reloaded.
-* `GET /events` now supports filtering by daemon name or ID.
-* `GET /events` now supports a `detach` event that is emitted on detaching from container process.
-* `GET /events` now supports an `exec_detach ` event that is emitted on detaching from exec process.
-* `GET /images/json` now supports filters `since` and `before`.
-* `POST /containers/(id or name)/start` no longer accepts a `HostConfig`.
-* `POST /images/(name)/tag` no longer has a `force` query parameter.
-* `GET /images/search` now supports maximum returned search results `limit`.
-* `POST /containers/{name:.*}/copy` is now removed and errors out starting from this API version.
-* API errors are now returned as JSON instead of plain text.
-* `POST /containers/create` and `POST /containers/(id)/start` allow you to configure kernel parameters (sysctls) for use in the container.
-* `POST /containers/<container ID>/exec` and `POST /exec/<exec ID>/start`
-  no longer expects a "Container" field to be present. This property was not used
-  and is no longer sent by the docker client.
-* `POST /containers/create/` now validates the hostname (should be a valid RFC 1123 hostname).
-* `POST /containers/create/` `HostConfig.PidMode` field now accepts `container:<name|id>`,
-  to have the container join the PID namespace of an existing container.
-
-## v1.23 API changes
-
-* `GET /containers/json` returns the state of the container, one of `created`, `restarting`, `running`, `paused`, `exited` or `dead`.
-* `GET /containers/json` returns the mount points for the container.
-* `GET /networks/(name)` now returns an `Internal` field showing whether the network is internal or not.
-* `GET /networks/(name)` now returns an `EnableIPv6` field showing whether the network has ipv6 enabled or not.
-* `POST /containers/(name)/update` now supports updating container's restart policy.
-* `POST /networks/create` now supports enabling ipv6 on the network by setting the `EnableIPv6` field (doing this with a label will no longer work).
-* `GET /info` now returns `CgroupDriver` field showing what cgroup driver the daemon is using; `cgroupfs` or `systemd`.
-* `GET /info` now returns `KernelMemory` field, showing if "kernel memory limit" is supported.
-* `POST /containers/create` now takes `PidsLimit` field, if the kernel is >= 4.3 and the pids cgroup is supported.
-* `GET /containers/(id or name)/stats` now returns `pids_stats`, if the kernel is >= 4.3 and the pids cgroup is supported.
-* `POST /containers/create` now allows you to override usernamespaces remapping and use privileged options for the container.
-* `POST /containers/create` now allows specifying `nocopy` for named volumes, which disables automatic copying from the container path to the volume.
-* `POST /auth` now returns an `IdentityToken` when supported by a registry.
-* `POST /containers/create` with both `Hostname` and `Domainname` fields specified will result in the container's hostname being set to `Hostname`, rather than `Hostname.Domainname`.
-* `GET /volumes` now supports more filters, new added filters are `name` and `driver`.
-* `GET /containers/(id or name)/logs` now accepts a `details` query parameter to stream the extra attributes that were provided to the containers `LogOpts`, such as environment variables and labels, with the logs.
-* `POST /images/load` now returns progress information as a JSON stream, and has a `quiet` query parameter to suppress progress details.
-
-## v1.22 API changes
-
-* The `HostConfig.LxcConf` field has been removed, and is no longer available on
-  `POST /containers/create` and `GET /containers/(id)/json`.
-* `POST /container/(name)/update` updates the resources of a container.
-* `GET /containers/json` supports filter `isolation` on Windows.
-* `GET /containers/json` now returns the list of networks of containers.
-* `GET /info` Now returns `Architecture` and `OSType` fields, providing information
-  about the host architecture and operating system type that the daemon runs on.
-* `GET /networks/(name)` now returns a `Name` field for each container attached to the network.
-* `GET /version` now returns the `BuildTime` field in RFC3339Nano format to make it
-  consistent with other date/time values returned by the API.
-* `AuthConfig` now supports a `registrytoken` for token based authentication
-* `POST /containers/create` now has a 4M minimum value limit for `HostConfig.KernelMemory`
-* Pushes initiated with `POST /images/(name)/push` and pulls initiated with `POST /images/create`
-  will be cancelled if the HTTP connection making the API request is closed before
-  the push or pull completes.
-* `POST /containers/create` now allows you to set a read/write rate limit for a
-  device (in bytes per second or IO per second).
-* `GET /networks` now supports filtering by `name`, `id` and `type`.
-* `POST /containers/create` now allows you to set the static IPv4 and/or IPv6 address for the container.
-* `POST /networks/(id)/connect` now allows you to set the static IPv4 and/or IPv6 address for the container.
-* `GET /info` now includes the number of containers running, stopped, and paused.
-* `POST /networks/create` now supports restricting external access to the network by setting the `Internal` field.
-* `POST /networks/(id)/disconnect` now includes a `Force` option to forcefully disconnect a container from network
-* `GET /containers/(id)/json` now returns the `NetworkID` of containers.
-* `POST /networks/create` Now supports an options field in the IPAM config that provides options
-  for custom IPAM plugins.
-* `GET /networks/{network-id}` Now returns IPAM config options for custom IPAM plugins if any
-  are available.
-* `GET /networks/<network-id>` now returns subnets info for user-defined networks.
-* `GET /info` can now return a `SystemStatus` field useful for returning additional information about applications
-  that are built on top of engine.
-
-## v1.21 API changes
-
-* `GET /volumes` lists volumes from all volume drivers.
-* `POST /volumes/create` to create a volume.
-* `GET /volumes/(name)` get low-level information about a volume.
-* `DELETE /volumes/(name)` remove a volume with the specified name.
-* `VolumeDriver` was moved from `config` to `HostConfig` to make the configuration portable.
-* `GET /images/(name)/json` now returns information about an image's `RepoTags` and `RepoDigests`.
-* The `config` option now accepts the field `StopSignal`, which specifies the signal to use to kill a container.
-* `GET /containers/(id)/stats` will return networking information respectively for each interface.
-* The `HostConfig` option now includes the `DnsOptions` field to configure the container's DNS options.
-* `POST /build` now optionally takes a serialized map of build-time variables.
-* `GET /events` now includes a `timenano` field, in addition to the existing `time` field.
-* `GET /events` now supports filtering by image and container labels.
-* `GET /info` now lists engine version information and return the information of `CPUShares` and `Cpuset`.
-* `GET /containers/json` will return `ImageID` of the image used by container.
-* `POST /exec/(name)/start` will now return an HTTP 409 when the container is either stopped or paused.
-* `POST /containers/create` now takes `KernelMemory` in HostConfig to specify kernel memory limit.
-* `GET /containers/(name)/json` now accepts a `size` parameter. Setting this parameter to '1' returns container size information in the `SizeRw` and `SizeRootFs` fields.
-* `GET /containers/(name)/json` now returns a `NetworkSettings.Networks` field,
-  detailing network settings per network. This field deprecates the
-  `NetworkSettings.Gateway`, `NetworkSettings.IPAddress`,
-  `NetworkSettings.IPPrefixLen`, and `NetworkSettings.MacAddress` fields, which
-  are still returned for backward-compatibility, but will be removed in a future version.
-* `GET /exec/(id)/json` now returns a `NetworkSettings.Networks` field,
-  detailing networksettings per network. This field deprecates the
-  `NetworkSettings.Gateway`, `NetworkSettings.IPAddress`,
-  `NetworkSettings.IPPrefixLen`, and `NetworkSettings.MacAddress` fields, which
-  are still returned for backward-compatibility, but will be removed in a future version.
-* The `HostConfig` option now includes the `OomScoreAdj` field for adjusting the
-  badness heuristic. This heuristic selects which processes the OOM killer kills
-  under out-of-memory conditions.
-
-## v1.20 API changes
-
-* `GET /containers/(id)/archive` get an archive of filesystem content from a container.
-* `PUT /containers/(id)/archive` upload an archive of content to be extracted to
-an existing directory inside a container's filesystem.
-* `POST /containers/(id)/copy` is deprecated in favor of the above `archive`
-endpoint which can be used to download files and directories from a container.
-* The `hostConfig` option now accepts the field `GroupAdd`, which specifies a
-list of additional groups that the container process will run as.
-
-## v1.19 API changes
-
-* When the daemon detects a version mismatch with the client, usually when
-the client is newer than the daemon, an HTTP 400 is now returned instead
-of a 404.
-* `GET /containers/(id)/stats` now accepts `stream` bool to get only one set of stats and disconnect.
-* `GET /containers/(id)/logs` now accepts a `since` timestamp parameter.
-* `GET /info` The fields `Debug`, `IPv4Forwarding`, `MemoryLimit`, and
-`SwapLimit` are now returned as boolean instead of as an int. In addition, the
-end point now returns the new boolean fields `CpuCfsPeriod`, `CpuCfsQuota`, and
-`OomKillDisable`.
-* The `hostConfig` option now accepts the fields `CpuPeriod` and `CpuQuota`
-* `POST /build` accepts `cpuperiod` and `cpuquota` options
-
-## v1.18 API changes
-
-* `GET /version` now returns `Os`, `Arch` and `KernelVersion`.
-* `POST /containers/create` and `POST /containers/(id)/start`allow you to  set ulimit settings for use in the container.
-* `GET /info` now returns `SystemTime`, `HttpProxy`,`HttpsProxy` and `NoProxy`.
-* `GET /images/json` added a `RepoDigests` field to include image digest information.
-* `POST /build` can now set resource constraints for all containers created for the build.
-* `CgroupParent` can be passed in the host config to setup container cgroups under a specific cgroup.
-* `POST /build` closing the HTTP request cancels the build
-* `POST /containers/(id)/exec` includes `Warnings` field to response.
diff --git a/_vendor/modules.txt b/_vendor/modules.txt
index ca334bf0d1a8..1ac92137fbbf 100644
--- a/_vendor/modules.txt
+++ b/_vendor/modules.txt
@@ -1,6 +1,7 @@
-# github.com/moby/moby v28.1.0-rc.2+incompatible
-# github.com/moby/buildkit v0.21.0
-# github.com/docker/buildx v0.23.0
-# github.com/docker/cli v28.1.0+incompatible
-# github.com/docker/compose/v2 v2.35.1
-# github.com/docker/scout-cli v1.15.0
+# github.com/moby/moby/api v1.55.0
+# github.com/moby/buildkit v0.32.2
+# github.com/docker/buildx v0.36.1
+# github.com/docker/cli v29.7.2+incompatible
+# github.com/docker/compose/v5 v5.5.0
+# github.com/docker/model-runner v1.1.36
+# github.com/docker/docker-agent v1.126.0
diff --git a/assets/css/code.css b/assets/css/code.css
deleted file mode 100644
index fa4bb4bd34b6..000000000000
--- a/assets/css/code.css
+++ /dev/null
@@ -1,81 +0,0 @@
-@layer components {
-  .prose {
-    .highlight,
-    :not(pre) > code {
-      font-size: 0.875em;
-      border: 1px solid;
-      border-radius: theme("spacing.1");
-      background: theme("colors.white");
-      border-color: theme("colors.gray.light.300");
-      .dark & {
-        background: theme("colors.gray.dark.200");
-        border-color: theme("colors.gray.dark.300");
-      }
-    }
-
-    :not(pre) > code {
-      background: theme("colors.gray.light.200");
-      display: inline-block;
-      margin: 0;
-      font-weight: 400;
-      overflow-wrap: anywhere;
-      padding: 0 4px;
-    }
-
-    table:not(.lntable) code {
-      overflow-wrap: unset;
-      white-space: nowrap;
-    }
-
-    /* Indented code blocks */
-    pre:not(.chroma) {
-      @apply my-4 overflow-x-auto p-3;
-      font-size: 0.875em;
-      border: 1px solid;
-      border-radius: theme("spacing.1");
-      background: theme("colors.white");
-      border-color: theme("colors.gray.light.300");
-      .dark & {
-        background: theme("colors.gray.dark.200");
-        border-color: theme("colors.gray.dark.300");
-      }
-    }
-
-    .highlight {
-      @apply my-4 overflow-x-auto p-3;
-
-      /* LineTableTD */
-      .lntd {
-        vertical-align: top;
-        padding: 0;
-        margin: 0;
-        font-weight: 400;
-        padding: 0 4px;
-        &:first-child {
-          width: 0;
-        }
-      }
-
-      /* LineTableTD */
-      .lntd {
-        vertical-align: top;
-        padding: 0;
-        margin: 0;
-        border: 0;
-      }
-      /* LineTable */
-      .lntable {
-        display: table;
-        width: 100%;
-        border-spacing: 0;
-        padding: 0;
-        margin: 0;
-        border: 0;
-        /* LineNumberColumnHighlight */
-        .lntd:first-child .hl {
-          display: block;
-        }
-      }
-    }
-  }
-}
diff --git a/assets/css/components.css b/assets/css/components.css
new file mode 100644
index 000000000000..a0f711f2dd8d
--- /dev/null
+++ b/assets/css/components.css
@@ -0,0 +1,130 @@
+@layer components {
+  .card {
+    @apply mt-2 mb-2 flex flex-col gap-2 rounded-sm border border-gray-200 p-3;
+    @apply dark:border-gray-700 dark:bg-gray-900;
+    @apply transition-shadow duration-200;
+    &:hover,
+    &:focus {
+      @apply border-gray-300 dark:border-gray-600;
+    }
+  }
+  .card-link:hover {
+    @apply !no-underline;
+  }
+  .card-header {
+    @apply mb-2 flex items-center gap-2;
+    @apply text-gray-700 dark:text-gray-100;
+  }
+  .card-icon {
+    @apply text-gray-700 dark:text-gray-100;
+  }
+  .card-img,
+  .card-img svg {
+    @apply m-0 flex max-h-5 min-h-5 max-w-5 min-w-5 items-center justify-center fill-current;
+  }
+  .card-title {
+    @apply font-semibold;
+  }
+  .card-link {
+    @apply block text-inherit no-underline hover:underline;
+  }
+  .card-description {
+    @apply text-gray-600;
+    @apply dark:text-gray-300;
+  }
+
+  .admonition {
+    @apply relative mb-4 flex w-full flex-col items-start gap-3 rounded-sm px-6 py-4;
+    @apply bg-gray-50 dark:bg-gray-900;
+  }
+  .admonition-header {
+    @apply flex flex-wrap items-center gap-2;
+  }
+  .admonition-title {
+    @apply font-semibold;
+  }
+  .admonition-content {
+    @apply w-full min-w-0 flex-1 flex-wrap overflow-x-auto break-words;
+    color: var(--tw-prose-body);
+  }
+  .admonition-note {
+    @apply border-blue-400 bg-blue-50 text-blue-900;
+    @apply dark:border-blue-600 dark:bg-blue-950 dark:text-blue-100;
+  }
+  .admonition-tip {
+    @apply border-green-400 bg-green-100 text-green-900;
+    @apply dark:border-green-600 dark:bg-green-950 dark:text-green-100;
+  }
+  .admonition-warning {
+    @apply border-yellow-400 bg-yellow-50 text-yellow-900;
+    @apply dark:border-yellow-600 dark:bg-yellow-950 dark:text-yellow-100;
+  }
+  .admonition-danger {
+    @apply border-red-400 bg-red-50 text-red-900;
+    @apply dark:border-red-600 dark:bg-red-950 dark:text-red-100;
+  }
+  .admonition-important {
+    @apply border-purple-400 bg-purple-50 text-purple-900;
+    @apply dark:border-purple-600 dark:bg-purple-950 dark:text-purple-100;
+  }
+  .admonition-icon {
+    @apply flex-shrink-0;
+    width: 24px;
+    height: 24px;
+    min-width: 24px;
+    min-height: 24px;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+  }
+  .admonition p{
+    margin-bottom: 1em;
+  }
+  .admonition ul{
+    @apply list-disc pl-5 mb-1;
+  }
+
+  .download-links {
+    @apply my-0  text-gray-600 dark:text-gray-400 rounded-sm border-1 border-gray-100 bg-gray-100/10 px-2 py-1;
+    @apply dark:border-gray-800 dark:bg-gray-900;
+    font-size: 86%;
+  }
+
+  .download-links a {
+    @apply link;
+  }
+
+  .download-links-subcontainer {
+    @apply flex flex-row gap-2 justify-between;
+    ul{
+      @apply m-0 p-0 list-none;
+      li{
+        @apply p-0 m-0;
+      }
+    }
+  }
+
+  .card-image {
+    @apply h-12 w-12 overflow-hidden;
+  }
+
+  .button {
+     @apply my-2 mr-2 inline-block rounded-sm bg-blue-500 p-1 px-3 text-white hover:bg-blue-600 dark:bg-blue-500 hover:dark:bg-blue-400;
+  }
+
+  .summary-bar {
+    @apply my-1 mt-4 flex flex-col rounded-sm border-1 border-gray-100 bg-gray-50 p-4 dark:border-gray-800 dark:bg-gray-900;
+  }
+
+  .tabs {
+    @apply bg-blue/2 rounded-sm p-2;
+  }
+  .tablist {
+    @apply mb-1 border-b border-gray-100 dark:border-gray-800;
+  }
+
+  .tab-item {
+    @apply inline-block rounded-t-sm px-3 py-2 hover:bg-gray-100 dark:hover:bg-gray-900;
+    @apply dark:text-gray-200;
+  }
+}
\ No newline at end of file
diff --git a/assets/css/global.css b/assets/css/global.css
index fa6742830e81..ba29b4dc6d16 100644
--- a/assets/css/global.css
+++ b/assets/css/global.css
@@ -1,89 +1,110 @@
 /* global styles */
 
-@layer base {
-  [x-cloak=""] {
+[x-cloak=""] {
+  display: none !important;
+}
+/* alpine cloak for small screens only */
+[x-cloak="sm"] {
+  @media (width <= 768px) {
     display: none !important;
   }
-  /* alpine cloak for small screens only */
-  [x-cloak="sm"] {
-    @media (width <= 768px) {
-      display: none !important;
-    }
-  }
+}
+/* Theme toggle icon visibility — driven by data-theme-preference on <html>,
+   set synchronously by theme.js before first paint. x-show handles updates
+   after Alpine initialises; these rules cover the pre-Alpine window. */
+:root[data-theme-preference="light"] .theme-icon-moon,
+:root[data-theme-preference="light"] .theme-icon-auto,
+:root[data-theme-preference="dark"] .theme-icon-sun,
+:root[data-theme-preference="dark"] .theme-icon-auto,
+:root[data-theme-preference="auto"] .theme-icon-sun,
+:root[data-theme-preference="auto"] .theme-icon-moon {
+  display: none;
+}
 
-  :root {
-    -webkit-font-smoothing: antialiased;
-    -moz-osx-font-smoothing: grayscale;
+:root {
+  -webkit-font-smoothing: antialiased;
+  -moz-osx-font-smoothing: grayscale;
 
-    scrollbar-color: theme(colors.gray.light.400) theme(colors.black / 0.05);
-    &.dark {
-      scrollbar-color: theme(colors.gray.dark.800) theme(colors.white / 0.10);
-    }
+  scrollbar-color: var(--color-gray-400) rgba(0, 0, 0, 0.05);
+  &.dark {
+    scrollbar-color: var(--color-gray-700) rgba(255, 255, 255, 0.1);
   }
+}
 
-  mark {
-    @apply bg-transparent font-bold text-blue-light dark:text-blue-dark;
-  }
+mark {
+  @apply bg-transparent font-bold text-blue-500 dark:text-blue-400;
+}
 
-  /* Hide the clear (X) button for search inputs */
-  /* Chrome, Safari, Edge, and Opera */
-  input[type="search"]::-webkit-search-cancel-button {
-    -webkit-appearance: none;
-    appearance: none;
-  }
-  
-  /* Firefox */
-  input[type="search"]::-moz-search-cancel-button {
-    display: none;
-  }
-  
-  /* Internet Explorer and Edge (legacy) */
-  input[type="search"]::-ms-clear {
-    display: none;
-  }
+/* Hide the clear (X) button for search inputs */
+/* Chrome, Safari, Edge, and Opera */
+input[type="search"]::-webkit-search-cancel-button {
+  -webkit-appearance: none;
+  appearance: none;
 }
 
-/* utility classes */
+/* Firefox */
+input[type="search"]::-moz-search-cancel-button {
+  display: none;
+}
 
-@layer utilities {
-  .link {
-    @apply text-blue-light underline underline-offset-2 dark:text-blue-dark;
+/* Internet Explorer and Edge (legacy) */
+input[type="search"]::-ms-clear {
+  display: none;
+}
+.prose {
+  hr {
+    @apply mt-8 mb-4;
   }
-
-  .invertible {
-    @apply dark:hue-rotate-180 dark:invert dark:filter;
+  :where(h1):not(:where([class~="not-prose"], [class~="not-prose"] *)) {
+    font-weight: 500 !important;
+    font-size: 180% !important;
+    margin-bottom: 0.4em !important;
   }
-
-  .bg-pattern-blue {
-    background-color: theme(colors.white / 50%);
-    background-image: url('/assets/images/bg-pattern-blue.webp');
-    background-blend-mode: overlay;
-    background-size: cover;
-    background-repeat: none;
-    .dark & {
-      background-color: theme(colors.black / 70%);
+  > h2 {
+    @apply mt-7! mb-3!;
+    font-size: 160% !important;
+    a {
+      @apply hover:no-underline!;
     }
   }
-
-  .bg-pattern-purple {
-    background-color: theme(colors.white / 50%);
-    background-image: url('/assets/images/bg-pattern-purple.webp');
-    background-blend-mode: overlay;
-    background-size: cover;
-    background-repeat: none;
-    .dark & {
-      background-color: theme(colors.black / 70%);
+  > h3 {
+    font-size: 130% !important;
+    a {
+      @apply hover:no-underline!;
     }
   }
-
-  .bg-pattern-verde {
-    background-color: theme(colors.white / 50%);
-    background-image: url('/assets/images/bg-pattern-verde.webp');
-    background-blend-mode: overlay;
-    background-size: cover;
-    background-repeat: none;
-    .dark & {
-      background-color: theme(colors.black / 70%);
+  > h4 {
+    a {
+      @apply hover:no-underline!;
+    }
+  }
+  > h5 {
+    a {
+      @apply hover:no-underline!;
     }
   }
+  ol {
+    list-style-type: decimal;
+  }
+
+  ol ol {
+    list-style-type: lower-alpha;
+  }
+
+  ol ol ol {
+    list-style-type: lower-roman;
+  }
+}
+.navbar-group:first-of-type {
+  margin-top: 0.2rem !important;
+}
+
+#search-page-results {
+  mark:where(.dark, .dark *) {
+    color: var(--color-blue-400);
+  }
+}
+
+code {
+  font-size: 0.9em;
 }
diff --git a/assets/css/icons.css b/assets/css/icons.css
deleted file mode 100644
index 08428273b262..000000000000
--- a/assets/css/icons.css
+++ /dev/null
@@ -1,29 +0,0 @@
-@layer utilities {
-  .icon-svg {
-    svg {
-      font-size: 24px;
-      width: 1em;
-      height: 1em;
-      display: inline-block;
-      fill: currentColor;
-    }
-  }
-
-  .icon-xs {
-    svg {
-      font-size: 12px;
-    }
-  }
-
-  .icon-sm {
-    svg {
-      font-size: 16px;
-    }
-  }
-
-  .icon-lg {
-    svg {
-      font-size: 32px;
-    }
-  }
-}
diff --git a/assets/css/lists.css b/assets/css/lists.css
deleted file mode 100644
index 249f71f4f2a3..000000000000
--- a/assets/css/lists.css
+++ /dev/null
@@ -1,12 +0,0 @@
-.prose ol {
-    list-style-type: decimal;
-}
-
-.prose ol ol {
-    list-style-type: lower-alpha;
-}
-
-.prose ol ol ol {
-    list-style-type: lower-roman;
-}
-
diff --git a/assets/css/pagefind.css b/assets/css/pagefind.css
new file mode 100644
index 000000000000..a6619c3b104a
--- /dev/null
+++ b/assets/css/pagefind.css
@@ -0,0 +1,25 @@
+/* Pagefind Component UI Customizations */
+
+/* Dark mode variables for modal */
+.dark pagefind-modal {
+  --pf-text: var(--color-gray-100);
+  --pf-text-secondary: var(--color-gray-300);
+  --pf-text-muted: var(--color-gray-400);
+  --pf-background: var(--color-gray-900);
+  --pf-border: var(--color-gray-700);
+  --pf-border-focus: var(--color-blue-400);
+  --pf-hover: var(--color-gray-800);
+}
+
+/* Highlight marks in results */
+pagefind-results mark {
+  background-color: var(--color-yellow-200);
+  color: inherit;
+  padding: 0 0.125rem;
+  border-radius: 0.125rem;
+}
+
+.dark pagefind-results mark {
+  background-color: rgba(255, 204, 72, 0.3);
+  color: white;
+}
diff --git a/assets/css/style.css b/assets/css/style.css
new file mode 100644
index 000000000000..f63fc6f5aec2
--- /dev/null
+++ b/assets/css/style.css
@@ -0,0 +1,47 @@
+/* Main CSS entry point */
+@import "tailwindcss";
+@plugin "@tailwindcss/typography";
+@source "hugo_stats.json";
+
+@font-face {
+  font-family: "Roboto Flex";
+  src: url("/assets/fonts/RobotoFlex.woff2") format("woff2");
+  font-weight: 100 1000; /* Range of weights Roboto Flex supports */
+  font-stretch: 100%; /* Range of width Roboto Flex supports */
+  font-style: oblique 0deg 10deg; /* Range of oblique angle Roboto Flex supports */
+  font-display: fallback;
+}
+
+/* Roboto Mono */
+@font-face {
+  font-family: "Roboto Mono";
+  src: url("/assets/fonts/RobotoMono-Regular.woff2") format("woff2");
+  font-weight: 100 700; /* Define the range of weight the variable font supports */
+  font-style: normal;
+  font-display: fallback;
+}
+
+/* Roboto Mono Italic */
+@font-face {
+  font-family: "Roboto Mono";
+  src: url("/assets/fonts/RobotoMono-Italic.woff2") format("woff2");
+  font-weight: 100 700; /* Define the range of weight the variable font supports */
+  font-style: italic;
+  font-display: fallback;
+}
+
+@layer theme {
+  @import "theme.css";
+}
+
+@layer base {
+  @import "global.css";
+}
+@import "utilities.css";
+@import "pagefind.css";
+@import "syntax-dark.css";
+@import "syntax-light.css";
+@import "components.css";
+@import "highlight-github-dark.css";
+
+@variant dark (&:where(.dark, .dark *));
diff --git a/assets/css/styles.css b/assets/css/styles.css
deleted file mode 100644
index 377c07bcc22a..000000000000
--- a/assets/css/styles.css
+++ /dev/null
@@ -1,16 +0,0 @@
-/* see also: tailwind.config.js */
-
-@import "tailwindcss/base";
-@import "/assets/css/global";
-@import "/assets/css/typography";
-@import "/assets/css/hack";
-
-@import "tailwindcss/components";
-@import "/assets/css/code";
-@import "/assets/css/toc";
-
-@import "tailwindcss/utilities";
-@import "/assets/css/syntax-light";
-@import "/assets/css/syntax-dark";
-@import "/assets/css/icons";
-@import "/assets/css/lists";
diff --git a/assets/css/syntax-dark.css b/assets/css/syntax-dark.css
index ff24a1954882..e66c18186f6f 100644
--- a/assets/css/syntax-dark.css
+++ b/assets/css/syntax-dark.css
@@ -1,343 +1,337 @@
-@layer utilities {
-  .syntax-dark {
-    /* Other */
-    .x {
-      color: theme("colors.white");
-    }
-    /* Error */
-    .err {
-      color: theme("colors.red.dark.500");
-    }
-    /* CodeLine */
-    .cl {
-    }
-    /* LineHighlight */
-    .hl {
-      min-width: fit-content;
-      background-color: theme("colors.gray.dark.300");
-    }
-    .lntd:first-child .hl,
-    & > .chroma > code > .hl {
-      margin-left: -4px;
-      border-left: 4px solid theme("colors.gray.dark.400");
-    }
-    /* LineNumbersTable */
-    .lnt {
-      white-space: pre;
-      user-select: none;
-      margin-right: 0.4em;
-      padding: 0 0.4em 0 0.4em;
-      color: theme("colors.gray.dark.400");
-    }
-    /* LineNumbers */
-    .ln {
-      white-space: pre;
-      user-select: none;
-      margin-right: 0.4em;
-      padding: 0 0.4em 0 0.4em;
-      color: theme("colors.gray.dark.400");
-    }
-    /* Line */
-    .line {
-      display: flex;
-    }
-    /* Keyword */
-    .k {
-      color: theme("colors.amber.dark.700");
-    }
-    /* KeywordConstant */
-    .kc {
-      color: theme("colors.violet.dark.700");
-    }
-    /* KeywordDeclaration */
-    .kd {
-      color: theme("colors.amber.dark.700");
-    }
-    /* KeywordNamespace */
-    .kn {
-      color: theme("colors.amber.dark.700");
-    }
-    /* KeywordPseudo */
-    .kp {
-      color: theme("colors.amber.dark.700");
-    }
-    /* KeywordReserved */
-    .kr {
-      color: theme("colors.amber.dark.700");
-    }
-    /* KeywordType */
-    .kt {
-      color: theme("colors.amber.dark.700");
-    }
-    /* Name */
-    .n {
-      color: theme("colors.violet.dark.700");
-    }
-    /* NameAttribute */
-    .na {
-      color: theme("colors.amber.dark.700");
-    }
-    /* NameBuiltin */
-    .nb {
-      color: theme("colors.amber.dark.700");
-    }
-    /* NameBuiltinPseudo */
-    .bp {
-      color: theme("colors.violet.dark.700");
-    }
-    /* NameClass */
-    .nc {
-      color: theme("colors.white");
-    }
-    /* NameConstant */
-    .no {
-      color: theme("colors.white");
-    }
-    /* NameDecorator */
-    .nd {
-      color: theme("colors.violet.dark.700");
-    }
-    /* NameEntity */
-    .ni {
-      color: theme("colors.amber.dark.700");
-    }
-    /* NameException */
-    .ne {
-      color: theme("colors.red.dark.700");
-    }
-    /* NameFunction */
-    .nf {
-      color: theme("colors.blue.dark.600");
-    }
-    /* NameFunctionMagic */
-    .fm {
-      color: theme("colors.blue.dark.600");
-    }
-    /* NameLabel */
-    .nl {
-      color: theme("colors.amber.dark.500");
-    }
-    /* NameNamespace */
-    .nn {
-      color: theme("colors.white");
-    }
-    /* NameOther */
-    .nx {
-      color: theme("colors.white");
-    }
-    /* NameProperty */
-    .py {
-      color: theme("colors.white");
-    }
-    /* NameTag */
-    .nt {
-      color: theme("colors.green.dark.600");
-    }
-    /* NameVariable */
-    .nv {
-      color: theme("colors.white");
-    }
-    /* NameVariableClass */
-    .vc {
-      color: theme("colors.violet.dark.600");
-    }
-    /* NameVariableGlobal */
-    .vg {
-      color: theme("colors.violet.dark.600");
-    }
-    /* NameVariableInstance */
-    .vi {
-      color: theme("colors.violet.dark.600");
-    }
-    /* NameVariableMagic */
-    .vm {
-      color: theme("colors.violet.dark.600");
-    }
-    /* Literal */
-    .l {
-      color: theme("colors.white");
-    }
-    /* LiteralDate */
-    .ld {
-      color: theme("colors.green.dark.600");
-    }
-    /* LiteralString */
-    .s {
-      color: theme("colors.white");
-    }
-    /* LiteralStringAffix */
-    .sa {
-      color: theme("colors.green.dark.600");
-    }
-    /* LiteralStringBacktick */
-    .sb {
-      color: theme("colors.green.dark.600");
-    }
-    /* LiteralStringChar */
-    .sc {
-      color: theme("colors.green.dark.600");
-    }
-    /* LiteralStringDelimiter */
-    .dl {
-      color: theme("colors.green.dark.600");
-    }
-    /* LiteralStringDoc */
-    .sd {
-      color: theme("colors.green.dark.600");
-    }
-    /* LiteralStringDouble */
-    .s2 {
-      color: theme("colors.green.dark.600");
-    }
-    /* LiteralStringEscape */
-    .se {
-      color: theme("colors.white");
-    }
-    /* LiteralStringHeredoc */
-    .sh {
-      color: theme("colors.green.dark.600");
-    }
-    /* LiteralStringInterpol */
-    .si {
-      color: theme("colors.green.dark.600");
-    }
-    /* LiteralStringOther */
-    .sx {
-      color: theme("colors.green.dark.600");
-    }
-    /* LiteralStringRegex */
-    .sr {
-      color: theme("colors.blue.dark.500");
-    }
-    /* LiteralStringSingle */
-    .s1 {
-      color: theme("colors.green.dark.600");
-    }
-    /* LiteralStringSymbol */
-    .ss {
-      color: theme("colors.blue.dark.600");
-    }
-    /* LiteralNumber */
-    .m {
-      color: theme("colors.blue.dark.600");
-    }
-    /* LiteralNumberBin */
-    .mb {
-      color: theme("colors.blue.dark.600");
-    }
-    /* LiteralNumberFloat */
-    .mf {
-      color: theme("colors.blue.dark.600");
-    }
-    /* LiteralNumberHex */
-    .mh {
-      color: theme("colors.blue.dark.600");
-    }
-    /* LiteralNumberInteger */
-    .mi {
-      color: theme("colors.blue.dark.600");
-    }
-    /* LiteralNumberIntegerLong */
-    .il {
-      color: theme("colors.blue.dark.600");
-    }
-    /* LiteralNumberOct */
-    .mo {
-      color: theme("colors.blue.dark.600");
-    }
-    /* Operator */
-    .o {
-      color: theme("colors.blue.dark.700");
-    }
-    /* OperatorWord */
-    .ow {
-      color: theme("colors.amber.dark.700");
-    }
-    /* Punctuation */
-    .p {
-      color: theme("colors.gray.dark.500");
-    }
-    /* Comment */
-    .c {
-      color: theme("colors.gray.dark.500");
-    }
-    /* CommentHashbang */
-    .ch {
-      color: theme("colors.gray.dark.500");
-    }
-    /* CommentMultiline */
-    .cm {
-      color: theme("colors.gray.dark.500");
-    }
-    /* CommentSingle */
-    .c1 {
-      color: theme("colors.gray.dark.500");
-    }
-    /* CommentSpecial */
-    .cs {
-      color: theme("colors.gray.dark.500");
-    }
-    /* CommentPreproc */
-    .cp {
-      color: theme("colors.gray.dark.500");
-    }
-    /* CommentPreprocFile */
-    .cpf {
-      color: theme("colors.gray.dark.500");
-    }
-    /* Generic */
-    .g {
-      color: theme("colors.white");
-    }
-    /* GenericDeleted */
-    .gd {
-      color: theme("colors.red.dark.500");
-    }
-    /* GenericEmph */
-    .ge {
-      color: theme("colors.white");
-    }
-    /* GenericError */
-    .gr {
-      color: theme("colors.red.dark.500");
-    }
-    /* GenericHeading */
-    .gh {
-      color: theme("colors.gray.dark.600");
-    }
-    /* GenericInserted */
-    .gi {
-      color: theme("colors.green.dark.500");
-    }
-    /* GenericOutput */
-    .go {
-      color: theme("colors.white");
-    }
-    /* GenericPrompt */
-    .gp {
-      user-select: none;
-      color: theme("colors.green.dark.400");
-    }
-    /* GenericStrong */
-    .gs {
-      color: theme("colors.white");
-    }
-    /* GenericSubheading */
-    .gu {
-      color: theme("colors.gray.dark.600");
-    }
-    /* GenericTraceback */
-    .gt {
-      color: theme("colors.red.dark.500");
-    }
-    /* GenericUnderline */
-    .gl {
-      color: theme("colors.white");
-      text-decoration: underline;
-    }
-    /* TextWhitespace */
-    .w {
-      color: theme("colors.gray.dark.100");
-    }
+@utility syntax-dark {
+  /* Other */
+  .x {
+    color: var(--color-white-main);
+  }
+  /* Error */
+  .err {
+    color: var(--color-red-500);
+  }
+  /* CodeLine */
+  .cl {
+    color: var(--color-gray-200);
+  }
+  /* LineHighlight */
+  .hl {
+    min-width: fit-content;
+    background-color: var(--color-gray-800);
+  }
+  /* LineNumbersTable */
+  .lnt {
+    white-space: pre;
+    user-select: none;
+    margin-right: 0.4em;
+    padding: 0 0.4em 0 0.4em;
+    color: var(--color-gray-300);
+  }
+  /* LineNumbers */
+  .ln {
+    white-space: pre;
+    user-select: none;
+    margin-right: 0.4em;
+    padding: 0 0.4em 0 0.4em;
+    color: var(--color-gray-900);
+  }
+  /* Line */
+  .line {
+    display: flex;
+  }
+  /* Keyword */
+  .k {
+    color: var(--color-yellow-700);
+  }
+  /* KeywordConstant */
+  .kc {
+    color: var(--color-violet-300);
+  }
+  /* KeywordDeclaration */
+  .kd {
+    color: var(--color-yellow-700);
+  }
+  /* KeywordNamespace */
+  .kn {
+    color: var(--color-yellow-700);
+  }
+  /* KeywordPseudo */
+  .kp {
+    color: var(--color-yellow-700);
+  }
+  /* KeywordReserved */
+  .kr {
+    color: var(--color-yellow-700);
+  }
+  /* KeywordType */
+  .kt {
+    color: var(--color-yellow-700);
+  }
+  /* Name */
+  .n {
+    color: var(--color-violet-300);
+  }
+  /* NameAttribute */
+  .na {
+    color: var(--color-yellow-700);
+  }
+  /* NameBuiltin */
+  .nb {
+    color: var(--color-yellow-700);
+  }
+  /* NameBuiltinPseudo */
+  .bp {
+    color: var(--color-violet-300);
+  }
+  /* NameClass */
+  .nc {
+    color: var(--color-white-main);
+  }
+  /* NameConstant */
+  .no {
+    color: var(--color-white-main);
+  }
+  /* NameDecorator */
+  .nd {
+    color: var(--color-violet-300);
+  }
+  /* NameEntity */
+  .ni {
+    color: var(--color-yellow-700);
+  }
+  /* NameException */
+  .ne {
+    color: var(--color-red-700);
+  }
+  /* NameFunction */
+  .nf {
+    color: var(--color-blue-400);
+  }
+  /* NameFunctionMagic */
+  .fm {
+    color: var(--color-blue-400);
+  }
+  /* NameLabel */
+  .nl {
+    color: var(--color-yellow-500);
+  }
+  /* NameNamespace */
+  .nn {
+    color: var(--color-white-main);
+  }
+  /* NameOther */
+  .nx {
+    color: var(--color-white-main);
+  }
+  /* NameProperty */
+  .py {
+    color: var(--color-violet-300);
+  }
+  /* NameTag */
+  .nt {
+    color: var(--color-green-300);
+  }
+  /* NameVariable */
+  .nv {
+    color: var(--color-green-500);
+  }
+  /* NameVariableClass */
+  .vc {
+    color: var(--color-violet-600);
+  }
+  /* NameVariableGlobal */
+  .vg {
+    color: var(--color-violet-600);
+  }
+  /* NameVariableInstance */
+  .vi {
+    color: var(--color-violet-600);
+  }
+  /* NameVariableMagic */
+  .vm {
+    color: var(--color-violet-600);
+  }
+  /* Literal */
+  .l {
+    color: var(--color-white-main);
+  }
+  /* LiteralDate */
+  .ld {
+    color: var(--color-green-600);
+  }
+  /* LiteralString */
+  .s {
+    color: var(--color-white-main);
+  }
+  /* LiteralStringAffix */
+  .sa {
+    color: var(--color-green-600);
+  }
+  /* LiteralStringBacktick */
+  .sb {
+    color: var(--color-green-600);
+  }
+  /* LiteralStringChar */
+  .sc {
+    color: var(--color-green-600);
+  }
+  /* LiteralStringDelimiter */
+  .dl {
+    color: var(--color-green-600);
+  }
+  /* LiteralStringDoc */
+  .sd {
+    color: var(--color-green-600);
+  }
+  /* LiteralStringDouble */
+  .s2 {
+    color: var(--color-green-600);
+  }
+  /* LiteralStringEscape */
+  .se {
+    color: var(--color-white-main);
+  }
+  /* LiteralStringHeredoc */
+  .sh {
+    color: var(--color-green-600);
+  }
+  /* LiteralStringInterpol */
+  .si {
+    color: var(--color-green-600);
+  }
+  /* LiteralStringOther */
+  .sx {
+    color: var(--color-green-600);
+  }
+  /* LiteralStringRegex */
+  .sr {
+    color: var(--color-blue-400);
+  }
+  /* LiteralStringSingle */
+  .s1 {
+    color: var(--color-green-600);
+  }
+  /* LiteralStringSymbol */
+  .ss {
+    color: var(--color-blue-400);
+  }
+  /* LiteralNumber */
+  .m {
+    color: var(--color-blue-400);
+  }
+  /* LiteralNumberBin */
+  .mb {
+    color: var(--color-blue-400);
+  }
+  /* LiteralNumberFloat */
+  .mf {
+    color: var(--color-blue-400);
+  }
+  /* LiteralNumberHex */
+  .mh {
+    color: var(--color-blue-400);
+  }
+  /* LiteralNumberInteger */
+  .mi {
+    color: var(--color-blue-400);
+  }
+  /* LiteralNumberIntegerLong */
+  .il {
+    color: var(--color-blue-400);
+  }
+  /* LiteralNumberOct */
+  .mo {
+    color: var(--color-blue-400);
+  }
+  /* Operator */
+  .o {
+    color: var(--color-blue-200);
+  }
+  /* OperatorWord */
+  .ow {
+    color: var(--color-yellow-700);
+  }
+  /* Punctuation */
+  .p {
+    color: var(--color-gray-500);
+  }
+  /* Comment */
+  .c {
+    color: var(--color-gray-500);
+  }
+  /* CommentHashbang */
+  .ch {
+    color: var(--color-gray-500);
+  }
+  /* CommentMultiline */
+  .cm {
+    color: var(--color-gray-500);
+  }
+  /* CommentSingle */
+  .c1 {
+    color: var(--color-gray-500);
+  }
+  /* CommentSpecial */
+  .cs {
+    color: var(--color-gray-500);
+  }
+  /* CommentPreproc */
+  .cp {
+    color: var(--color-gray-500);
+  }
+  /* CommentPreprocFile */
+  .cpf {
+    color: var(--color-gray-500);
+  }
+  /* Generic */
+  .g {
+    color: var(--color-white-main);
+  }
+  /* GenericDeleted */
+  .gd {
+    color: var(--color-red-500);
+  }
+  /* GenericEmph */
+  .ge {
+    color: var(--color-white-main);
+  }
+  /* GenericError */
+  .gr {
+    color: var(--color-red-500);
+  }
+  /* GenericHeading */
+  .gh {
+    color: var(--color-gray-600);
+  }
+  /* GenericInserted */
+  .gi {
+    color: var(--color-green-500);
+  }
+  /* GenericOutput */
+  .go {
+    color: var(--color-white-main);
+  }
+  /* GenericPrompt */
+  .gp {
+    user-select: none;
+    color: var(--color-green-500);
+  }
+  /* GenericStrong */
+  .gs {
+    color: var(--color-white-main);
+  }
+  /* GenericSubheading */
+  .gu {
+    color: var(--color-gray-600);
+  }
+  /* GenericTraceback */
+  .gt {
+    color: var(--color-red-500);
+  }
+  /* GenericUnderline */
+  .gl {
+    color: var(--color-white-main);
+    text-decoration: underline;
+  }
+  /* TextWhitespace */
+  .w {
+    color: var(--color-gray-100);
   }
 }
diff --git a/assets/css/syntax-light.css b/assets/css/syntax-light.css
index ba0bb789f853..e9c3151d14fe 100644
--- a/assets/css/syntax-light.css
+++ b/assets/css/syntax-light.css
@@ -1,343 +1,337 @@
-@layer utilities {
-  .syntax-light {
-    /* Other */
-    .x {
-      color: theme("colors.black");
-    }
-    /* Error */
-    .err {
-      color: theme("colors.red.light.500");
-    }
-    /* CodeLine */
-    .cl {
-    }
-    /* LineHighlight */
-    .hl {
-      min-width: fit-content;
-      background-color: theme("colors.blue.light.100");
-    }
-    .lntd:first-child .hl,
-    & > .chroma > code > .hl {
-      margin-left: -4px;
-      border-left: 4px solid theme("colors.blue.light.300");
-    }
-    /* LineNumbersTable */
-    .lnt {
-      white-space: pre;
-      user-select: none;
-      margin-right: 0.4em;
-      padding: 0 0.4em 0 0.4em;
-      color: theme("colors.gray.light.400");
-    }
-    /* LineNumbers */
-    .ln {
-      white-space: pre;
-      user-select: none;
-      margin-right: 0.4em;
-      padding: 0 0.4em 0 0.4em;
-      color: theme("colors.gray.light.400");
-    }
-    /* Line */
-    .line {
-      display: flex;
-    }
-    /* Keyword */
-    .k {
-      color: theme("colors.amber.light.500");
-    }
-    /* KeywordConstant */
-    .kc {
-      color: theme("colors.violet.light.400");
-    }
-    /* KeywordDeclaration */
-    .kd {
-      color: theme("colors.amber.light.500");
-    }
-    /* KeywordNamespace */
-    .kn {
-      color: theme("colors.amber.light.500");
-    }
-    /* KeywordPseudo */
-    .kp {
-      color: theme("colors.amber.light.500");
-    }
-    /* KeywordReserved */
-    .kr {
-      color: theme("colors.amber.light.500");
-    }
-    /* KeywordType */
-    .kt {
-      color: theme("colors.amber.light.500");
-    }
-    /* Name */
-    .n {
-      color: theme("colors.violet.light.400");
-    }
-    /* NameAttribute */
-    .na {
-      color: theme("colors.amber.light.500");
-    }
-    /* NameBuiltin */
-    .nb {
-      color: theme("colors.amber.light.500");
-    }
-    /* NameBuiltinPseudo */
-    .bp {
-      color: theme("colors.violet.light.400");
-    }
-    /* NameClass */
-    .nc {
-      color: theme("colors.black");
-    }
-    /* NameConstant */
-    .no {
-      color: theme("colors.black");
-    }
-    /* NameDecorator */
-    .nd {
-      color: theme("colors.violet.light.400");
-    }
-    /* NameEntity */
-    .ni {
-      color: theme("colors.amber.light.500");
-    }
-    /* NameException */
-    .ne {
-      color: theme("colors.red.light.700");
-    }
-    /* NameFunction */
-    .nf {
-      color: theme("colors.blue.light.600");
-    }
-    /* NameFunctionMagic */
-    .fm {
-      color: theme("colors.blue.light.600");
-    }
-    /* NameLabel */
-    .nl {
-      color: theme("colors.amber.light.700");
-    }
-    /* NameNamespace */
-    .nn {
-      color: theme("colors.black");
-    }
-    /* NameOther */
-    .nx {
-      color: theme("colors.black");
-    }
-    /* NameProperty */
-    .py {
-      color: theme("colors.black");
-    }
-    /* NameTag */
-    .nt {
-      color: theme("colors.green.light.600");
-    }
-    /* NameVariable */
-    .nv {
-      color: theme("colors.black");
-    }
-    /* NameVariableClass */
-    .vc {
-      color: theme("colors.violet.light.600");
-    }
-    /* NameVariableGlobal */
-    .vg {
-      color: theme("colors.violet.light.600");
-    }
-    /* NameVariableInstance */
-    .vi {
-      color: theme("colors.violet.light.600");
-    }
-    /* NameVariableMagic */
-    .vm {
-      color: theme("colors.violet.light.600");
-    }
-    /* Literal */
-    .l {
-      color: theme("colors.black");
-    }
-    /* LiteralDate */
-    .ld {
-      color: theme("colors.black");
-    }
-    /* LiteralString */
-    .s {
-      color: theme("colors.black");
-    }
-    /* LiteralStringAffix */
-    .sa {
-      color: theme("colors.green.light.600");
-    }
-    /* LiteralStringBacktick */
-    .sb {
-      color: theme("colors.green.light.600");
-    }
-    /* LiteralStringChar */
-    .sc {
-      color: theme("colors.green.light.600");
-    }
-    /* LiteralStringDelimiter */
-    .dl {
-      color: theme("colors.green.light.600");
-    }
-    /* LiteralStringDoc */
-    .sd {
-      color: #8f5902;
-    }
-    /* LiteralStringDouble */
-    .s2 {
-      color: theme("colors.green.light.600");
-    }
-    /* LiteralStringEscape */
-    .se {
-      color: theme("colors.black");
-    }
-    /* LiteralStringHeredoc */
-    .sh {
-      color: theme("colors.green.light.600");
-    }
-    /* LiteralStringInterpol */
-    .si {
-      color: theme("colors.green.light.600");
-    }
-    /* LiteralStringOther */
-    .sx {
-      color: theme("colors.green.light.600");
-    }
-    /* LiteralStringRegex */
-    .sr {
-      color: theme("colors.blue.light.500");
-    }
-    /* LiteralStringSingle */
-    .s1 {
-      color: theme("colors.green.light.600");
-    }
-    /* LiteralStringSymbol */
-    .ss {
-      color: theme("colors.green.light.600");
-    }
-    /* LiteralNumber */
-    .m {
-      color: theme("colors.blue.light.600");
-    }
-    /* LiteralNumberBin */
-    .mb {
-      color: theme("colors.blue.light.600");
-    }
-    /* LiteralNumberFloat */
-    .mf {
-      color: theme("colors.blue.light.600");
-    }
-    /* LiteralNumberHex */
-    .mh {
-      color: theme("colors.blue.light.600");
-    }
-    /* LiteralNumberInteger */
-    .mi {
-      color: theme("colors.blue.light.600");
-    }
-    /* LiteralNumberIntegerLong */
-    .il {
-      color: theme("colors.blue.light.600");
-    }
-    /* LiteralNumberOct */
-    .mo {
-      color: theme("colors.blue.light.600");
-    }
-    /* Operator */
-    .o {
-      color: theme("colors.blue.light.400");
-    }
-    /* OperatorWord */
-    .ow {
-      color: theme("colors.amber.light.500");
-    }
-    /* Punctuation */
-    .p {
-      color: theme("colors.gray.light.400");
-    }
-    /* Comment */
-    .c {
-      color: theme("colors.gray.light.400");
-    }
-    /* CommentHashbang */
-    .ch {
-      color: theme("colors.gray.light.400");
-    }
-    /* CommentMultiline */
-    .cm {
-      color: theme("colors.gray.light.400");
-    }
-    /* CommentSingle */
-    .c1 {
-      color: theme("colors.gray.light.400");
-    }
-    /* CommentSpecial */
-    .cs {
-      color: theme("colors.gray.light.400");
-    }
-    /* CommentPreproc */
-    .cp {
-      color: theme("colors.gray.light.400");
-    }
-    /* CommentPreprocFile */
-    .cpf {
-      color: theme("colors.gray.light.400");
-    }
-    /* Generic */
-    .g {
-      color: theme("colors.black");
-    }
-    /* GenericDeleted */
-    .gd {
-      color: theme("colors.red.light.500");
-    }
-    /* GenericEmph */
-    .ge {
-      color: theme("colors.black");
-    }
-    /* GenericError */
-    .gr {
-      color: theme("colors.red.light.500");
-    }
-    /* GenericHeading */
-    .gh {
-      color: theme("colors.gray.light.600");
-    }
-    /* GenericInserted */
-    .gi {
-      color: theme("colors.green.light.500");
-    }
-    /* GenericOutput */
-    .go {
-      color: theme("colors.black");
-    }
-    /* GenericPrompt */
-    .gp {
-      user-select: none;
-      color: theme("colors.green.light.400");
-    }
-    /* GenericStrong */
-    .gs {
-      color: theme("colors.black");
-    }
-    /* GenericSubheading */
-    .gu {
-      color: theme("colors.gray.light.600");
-    }
-    /* GenericTraceback */
-    .gt {
-      color: theme("colors.red.light.500");
-    }
-    /* GenericUnderline */
-    .gl {
-      color: theme("colors.black");
-      text-decoration: underline;
-    }
-    /* TextWhitespace */
-    .w {
-      color: theme("colors.gray.light.100");
-    }
+@utility syntax-light {
+  /* Other */
+  .x {
+    color: var(--color-black-main);
+  }
+  /* Error */
+  .err {
+    color: var(--color-red-500);
+  }
+  /* CodeLine */
+  .cl {
+    color: var(--color-gray-700);
+  }
+  /* LineHighlight */
+  .hl {
+    min-width: fit-content;
+    background-color: var(--color-gray-100);
+  }
+  /* LineNumbersTable */
+  .lnt {
+    white-space: pre;
+    user-select: none;
+    margin-right: 0.4em;
+    padding: 0 0.4em 0 0.4em;
+    color: var(--color-gray-400);
+  }
+  /* LineNumbers */
+  .ln {
+    white-space: pre;
+    user-select: none;
+    margin-right: 0.4em;
+    padding: 0 0.4em 0 0.4em;
+    color: var(--color-gray-400);
+  }
+  /* Line */
+  .line {
+    display: flex;
+  }
+  /* Keyword */
+  .k {
+    color: var(--color-yellow-700);
+  }
+  /* KeywordConstant */
+  .kc {
+    color: var(--color-violet-400);
+  }
+  /* KeywordDeclaration */
+  .kd {
+    color: var(--color-yellow-700);
+  }
+  /* KeywordNamespace */
+  .kn {
+    color: var(--color-yellow-700);
+  }
+  /* KeywordPseudo */
+  .kp {
+    color: var(--color-yellow-700);
+  }
+  /* KeywordReserved */
+  .kr {
+    color: var(--color-yellow-700);
+  }
+  /* KeywordType */
+  .kt {
+    color: var(--color-yellow-700);
+  }
+  /* Name */
+  .n {
+    color: var(--color-violet-400);
+  }
+  /* NameAttribute */
+  .na {
+    color: var(--color-yellow-700);
+  }
+  /* NameBuiltin */
+  .nb {
+    color: var(--color-yellow-800);
+  }
+  /* NameBuiltinPseudo */
+  .bp {
+    color: var(--color-violet-400);
+  }
+  /* NameClass */
+  .nc {
+    color: var(--color-black-main);
+  }
+  /* NameConstant */
+  .no {
+    color: var(--color-black-main);
+  }
+  /* NameDecorator */
+  .nd {
+    color: var(--color-violet-400);
+  }
+  /* NameEntity */
+  .ni {
+    color: var(--color-yellow-700);
+  }
+  /* NameException */
+  .ne {
+    color: var(--color-red-700);
+  }
+  /* NameFunction */
+  .nf {
+    color: var(--color-blue-500);
+  }
+  /* NameFunctionMagic */
+  .fm {
+    color: var(--color-blue-500);
+  }
+  /* NameLabel */
+  .nl {
+    color: var(--color-yellow-700);
+  }
+  /* NameNamespace */
+  .nn {
+    color: var(--color-black-main);
+  }
+  /* NameOther */
+  .nx {
+    color: var(--color-black-main);
+  }
+  /* NameProperty */
+  .py {
+    color: var(--color-black-main);
+  }
+  /* NameTag */
+  .nt {
+    color: var(--color-blue-400);
+  }
+  /* NameVariable */
+  .nv {
+    color: var(--color-black-main);
+  }
+  /* NameVariableClass */
+  .vc {
+    color: var(--color-violet-600);
+  }
+  /* NameVariableGlobal */
+  .vg {
+    color: var(--color-violet-600);
+  }
+  /* NameVariableInstance */
+  .vi {
+    color: var(--color-violet-600);
+  }
+  /* NameVariableMagic */
+  .vm {
+    color: var(--color-violet-600);
+  }
+  /* Literal */
+  .l {
+    color: var(--color-black-main);
+  }
+  /* LiteralDate */
+  .ld {
+    color: var(--color-black-main);
+  }
+  /* LiteralString */
+  .s {
+    color: var(--color-black-main);
+  }
+  /* LiteralStringAffix */
+  .sa {
+    color: var(--color-green-700);
+  }
+  /* LiteralStringBacktick */
+  .sb {
+    color: var(--color-green-700);
+  }
+  /* LiteralStringChar */
+  .sc {
+    color: var(--color-green-700);
+  }
+  /* LiteralStringDelimiter */
+  .dl {
+    color: var(--color-green-700);
+  }
+  /* LiteralStringDoc */
+  .sd {
+    color: #8f5902;
+  }
+  /* LiteralStringDouble */
+  .s2 {
+    color: var(--color-green-700);
+  }
+  /* LiteralStringEscape */
+  .se {
+    color: var(--color-black-main);
+  }
+  /* LiteralStringHeredoc */
+  .sh {
+    color: var(--color-green-700);
+  }
+  /* LiteralStringInterpol */
+  .si {
+    color: var(--color-green-700);
+  }
+  /* LiteralStringOther */
+  .sx {
+    color: var(--color-green-700);
+  }
+  /* LiteralStringRegex */
+  .sr {
+    color: var(--color-blue-500);
+  }
+  /* LiteralStringSingle */
+  .s1 {
+    color: var(--color-green-700);
+  }
+  /* LiteralStringSymbol */
+  .ss {
+    color: var(--color-green-700);
+  }
+  /* LiteralNumber */
+  .m {
+    color: var(--color-blue-500);
+  }
+  /* LiteralNumberBin */
+  .mb {
+    color: var(--color-blue-500);
+  }
+  /* LiteralNumberFloat */
+  .mf {
+    color: var(--color-blue-500);
+  }
+  /* LiteralNumberHex */
+  .mh {
+    color: var(--color-blue-500);
+  }
+  /* LiteralNumberInteger */
+  .mi {
+    color: var(--color-blue-500);
+  }
+  /* LiteralNumberIntegerLong */
+  .il {
+    color: var(--color-blue-500);
+  }
+  /* LiteralNumberOct */
+  .mo {
+    color: var(--color-blue-500);
+  }
+  /* Operator */
+  .o {
+    color: var(--color-blue-400);
+  }
+  /* OperatorWord */
+  .ow {
+    color: var(--color-yellow-700);
+  }
+  /* Punctuation */
+  .p {
+    color: var(--color-gray-400);
+  }
+  /* Comment */
+  .c {
+    color: var(--color-gray-400);
+  }
+  /* CommentHashbang */
+  .ch {
+    color: var(--color-gray-400);
+  }
+  /* CommentMultiline */
+  .cm {
+    color: var(--color-gray-400);
+  }
+  /* CommentSingle */
+  .c1 {
+    color: var(--color-gray-400);
+  }
+  /* CommentSpecial */
+  .cs {
+    color: var(--color-gray-400);
+  }
+  /* CommentPreproc */
+  .cp {
+    color: var(--color-gray-400);
+  }
+  /* CommentPreprocFile */
+  .cpf {
+    color: var(--color-gray-400);
+  }
+  /* Generic */
+  .g {
+    color: var(--color-black-main);
+  }
+  /* GenericDeleted */
+  .gd {
+    color: var(--color-red-500);
+  }
+  /* GenericEmph */
+  .ge {
+    color: var(--color-black-main);
+  }
+  /* GenericError */
+  .gr {
+    color: var(--color-red-500);
+  }
+  /* GenericHeading */
+  .gh {
+    color: var(--color-gray-600);
+  }
+  /* GenericInserted */
+  .gi {
+    color: var(--color-green-500);
+  }
+  /* GenericOutput */
+  .go {
+    color: var(--color-black-main);
+  }
+  /* GenericPrompt */
+  .gp {
+    user-select: none;
+    color: var(--color-green-400);
+  }
+  /* GenericStrong */
+  .gs {
+    color: var(--color-black-main);
+  }
+  /* GenericSubheading */
+  .gu {
+    color: var(--color-gray-600);
+  }
+  /* GenericTraceback */
+  .gt {
+    color: var(--color-red-500);
+  }
+  /* GenericUnderline */
+  .gl {
+    color: var(--color-black-main);
+    text-decoration: underline;
+  }
+  /* TextWhitespace */
+  .w {
+    color: var(--color-gray-100);
   }
 }
diff --git a/assets/css/theme.css b/assets/css/theme.css
new file mode 100644
index 000000000000..4d6ecf1c5dfa
--- /dev/null
+++ b/assets/css/theme.css
@@ -0,0 +1,207 @@
+@theme inline {
+  --font-sans: "roboto flex", sans-serif;
+  --font-mono: "roboto flex mono", ui-monospace, SFMono-Regular, monospace;
+  --default-font-family: var(--font-sans);
+
+  --text-xs: 0.7143rem;
+  --text-xs--letter-spacing: 0.015em;
+  --text-xs--font-weight: 500;
+  --text-sm: 0.851rem;
+  --text-base: 14px;
+  --text-lg: 1.1429rem;
+  --text-lg--line-height: 1.75;
+  --text-xl: 1.2857rem;
+  --text-xl--letter-spacing: -0.015em;
+  --text-xl--font-weight: 500;
+  --text-2xl: 1.5rem;
+  --text-2xl--letter-spacing: -0.015em;
+  --text-2xl--font-weight: 500;
+  --text-3xl: 2rem;
+  --text-3xl--font-weight: 500;
+  --text-4xl: 2.5rem;
+  --text-4xl--letter-spacing: -0.015em;
+  --text-4xl--font-weight: 500;
+
+  --color-background-light: #f9f9fa;
+  --color-background-dark: #10151b;
+  --color-primary-blue: var(--color-blue);
+
+  --color-divider-light: hsla(0, 0%, 0%, 0.1);
+  --color-divider-dark: hsla(0, 0%, 100%, 0.05);
+
+  --card-bg-dark: #1d262d;
+  --card-border-dark: #516980;
+  --card-bg-dark: var(--color-gray-900);
+  --card-border-dark: var(--color-gray-700);
+
+  --color-navbar-bg: var(--color-background-light);
+  --color-navbar-bg-dark: var(--color-background-dark);
+  --color-navbar-text: var(--color-gray-700);
+  --color-navbar-text-dark: var(--tw-prose-body);
+  --color-navbar-border-color-light: var(--tw-prose-inverse-body);
+  --navbar-font-size: 0.92rem;
+  --navbar-group-font-title-size: 1rem;
+  --color-navbar-text-dark: var(--color-gray-200);
+  --color-navbar-group-text-dark: var(--tw-prose-body);
+
+  --color-blue: var(--color-blue-400);
+  --color-blue-100: rgba(217, 229, 252, 1);
+  --color-blue-200: rgba(170, 196, 248, 1);
+  --color-blue-300: rgba(123, 164, 244, 1);
+  --color-blue-400: rgba(75, 131, 241, 1);
+  --color-blue-50: rgba(246, 248, 254, 1);
+  --color-blue-500: rgba(37, 96, 255, 1);
+  --color-blue-600: rgba(13, 77, 242, 1);
+  --color-blue-700: rgba(0, 61, 181, 1);
+  --color-blue-800: rgba(0, 41, 120, 1);
+  --color-blue-900: rgba(0, 29, 86, 1);
+  --color-blue-950: rgba(0, 21, 60, 1);
+  --color-blue-focus: rgba(37, 96, 255, 0.24);
+  --color-blue-focusvisible: rgba(37, 96, 255, 0.32);
+  --color-blue-hover: rgba(37, 96, 255, 0.12);
+  --color-blue-outlinedborder: rgba(37, 96, 255, 0.56);
+  --color-blue-selected: rgba(37, 96, 255, 0.16);
+
+  --color-gray: var(--color-gray-600);
+  --color-gray-100: rgba(231, 234, 239, 1);
+  --color-gray-200: rgba(200, 207, 218, 1);
+  --color-gray-300: rgba(169, 180, 198, 1);
+  --color-gray-400: rgba(139, 153, 178, 1);
+  --color-gray-50: rgba(249, 250, 251, 1);
+  --color-gray-500: rgba(108, 126, 157, 1);
+  --color-gray-600: rgba(86, 101, 129, 1);
+  --color-gray-700: rgba(67, 76, 95, 1);
+  --color-gray-800: rgba(44, 51, 63, 1);
+  --color-gray-900: rgba(30, 33, 41, 1);
+  --color-gray-950: rgb(18, 21, 31);
+  --color-gray-focus: rgba(108, 126, 157, 0.24);
+  --color-gray-focusvisible: rgba(108, 126, 157, 0.32);
+  --color-gray-hover: rgba(108, 126, 157, 0.12);
+  --color-gray-outlinedborder: rgba(108, 126, 157, 0.56);
+  --color-gray-selected: rgba(108, 126, 157, 0.16);
+
+  --color-green-100: rgba(235, 249, 238, 1);
+  --color-green-200: rgba(208, 241, 215, 1);
+  --color-green-300: rgba(169, 229, 189, 1);
+  --color-green-400: rgba(129, 217, 162, 1);
+  --color-green-50: rgba(245, 252, 247, 1);
+  --color-green-500: rgba(90, 206, 140, 1);
+  --color-green-600: rgba(56, 189, 125, 1);
+  --color-green-700: rgba(45, 149, 104, 1);
+  --color-green-800: rgba(33, 110, 75, 1);
+  --color-green-900: rgba(23, 75, 50, 1);
+  --color-green-950: rgba(17, 55, 26, 1);
+  --color-green-focus: rgba(56, 189, 125, 0.24);
+  --color-green-focusvisible: rgba(56, 189, 125, 0.32);
+  --color-green-hover: rgba(56, 189, 125, 0.12);
+  --color-green-outlinedborder: rgba(56, 189, 125, 0.56);
+  --color-green-selected: rgba(56, 189, 125, 0.16);
+
+  --color-orange-100: rgba(255, 233, 217, 1);
+  --color-orange-200: rgba(255, 216, 187, 1);
+  --color-orange-300: rgba(255, 196, 153, 1);
+  --color-orange-400: rgba(255, 169, 107, 1);
+  --color-orange-50: rgba(255, 249, 245, 1);
+  --color-orange-500: rgba(255, 135, 49, 1);
+  --color-orange-600: rgba(255, 107, 0, 1);
+  --color-orange-700: rgba(218, 92, 0, 1);
+  --color-orange-800: rgba(173, 72, 0, 1);
+  --color-orange-900: rgba(137, 58, 1, 1);
+  --color-orange-950: rgba(94, 40, 0, 1);
+  --color-orange-focus: rgba(255, 107, 0, 0.24);
+  --color-orange-focusvisible: rgba(255, 107, 0, 0.32);
+  --color-orange-hover: rgba(255, 107, 0, 0.12);
+  --color-orange-outlinedborder: rgba(255, 107, 0, 0.56);
+  --color-orange-selected: rgba(255, 107, 0, 0.16);
+
+  --color-pink-100: rgba(255, 230, 251, 1);
+  --color-pink-200: rgba(255, 201, 246, 1);
+  --color-pink-300: rgba(255, 166, 240, 1);
+  --color-pink-400: rgba(252, 113, 220, 1);
+  --color-pink-50: rgba(255, 247, 254, 1);
+  --color-pink-500: rgba(237, 73, 199, 1);
+  --color-pink-600: rgba(201, 24, 171, 1);
+  --color-pink-700: rgba(171, 0, 137, 1);
+  --color-pink-800: rgba(131, 0, 105, 1);
+  --color-pink-900: rgba(109, 0, 81, 1);
+  --color-pink-950: rgba(85, 0, 51, 1);
+  --color-pink-focus: rgba(201, 24, 171, 0.24);
+  --color-pink-focusvisible: rgba(201, 24, 171, 0.32);
+  --color-pink-hover: rgba(201, 24, 171, 0.12);
+  --color-pink-outlinedborder: rgba(201, 24, 171, 0.56);
+  --color-pink-selected: rgba(201, 24, 171, 0.16);
+
+  --color-red-100: rgba(255, 223, 223, 1);
+  --color-red-200: rgba(255, 194, 194, 1);
+  --color-red-300: rgba(255, 168, 168, 1);
+  --color-red-400: rgba(255, 117, 117, 1);
+  --color-red-50: rgba(255, 245, 245, 1);
+  --color-red-500: rgba(255, 87, 87, 1);
+  --color-red-600: rgba(244, 47, 57, 1);
+  --color-red-700: rgba(228, 12, 44, 1);
+  --color-red-800: rgba(179, 9, 9, 1);
+  --color-red-900: rgba(137, 0, 0, 1);
+  --color-red-950: rgba(110, 0, 0, 1);
+  --color-red-focus: rgba(244, 47, 57, 0.24);
+  --color-red-focusvisible: rgba(244, 47, 57, 0.32);
+  --color-red-hover: rgba(244, 47, 57, 0.12);
+  --color-red-outlinedborder: rgba(244, 47, 57, 0.56);
+  --color-red-selected: rgba(244, 47, 57, 0.16);
+
+  --color-teal-100: rgba(223, 246, 246, 1);
+  --color-teal-200: rgba(195, 240, 241, 1);
+  --color-teal-300: rgba(160, 229, 232, 1);
+  --color-teal-400: rgba(106, 220, 222, 1);
+  --color-teal-50: rgba(243, 252, 252, 1);
+  --color-teal-500: rgba(47, 208, 210, 1);
+  --color-teal-600: rgba(27, 189, 191, 1);
+  --color-teal-700: rgba(44, 158, 160, 1);
+  --color-teal-800: rgba(24, 116, 115, 1);
+  --color-teal-900: rgba(18, 85, 85, 1);
+  --color-teal-950: rgba(9, 61, 61, 1);
+  --color-teal-focus: rgba(27, 189, 191, 0.24);
+  --color-teal-focusvisible: rgba(27, 189, 191, 0.32);
+  --color-teal-hover: rgba(27, 189, 191, 0.12);
+  --color-teal-outlinedborder: rgba(27, 189, 191, 0.56);
+  --color-teal-selected: rgba(27, 189, 191, 0.16);
+
+  --color-violet: var(--color-violet-500);
+  --color-violet-100: rgba(239, 224, 255, 1);
+  --color-violet-200: rgba(211, 183, 255, 1);
+  --color-violet-300: rgba(174, 130, 255, 1);
+  --color-violet-400: rgba(152, 96, 255, 1);
+  --color-violet-50: rgba(252, 249, 255, 1);
+  --color-violet-500: rgba(125, 46, 255, 1);
+  --color-violet-600: rgba(109, 0, 235, 1);
+  --color-violet-700: rgba(87, 0, 187, 1);
+  --color-violet-800: rgba(69, 0, 147, 1);
+  --color-violet-900: rgba(55, 0, 118, 1);
+  --color-violet-950: rgba(37, 0, 80, 1);
+  --color-violet-focus: rgba(125, 46, 255, 0.24);
+  --color-violet-focusvisible: rgba(125, 46, 255, 0.32);
+  --color-violet-hover: rgba(125, 46, 255, 0.12);
+  --color-violet-outlinedborder: rgba(125, 46, 255, 0.56);
+  --color-violet-selected: rgba(125, 46, 255, 0.16);
+
+  --color-white-main: rgba(255, 255, 255, 1);
+  --color-yellow-100: rgba(255, 245, 219, 1);
+  --color-yellow-200: rgba(255, 241, 204, 1);
+  --color-yellow-300: rgba(255, 232, 173, 1);
+  --color-yellow-400: rgba(255, 218, 122, 1);
+  --color-yellow-50: rgba(255, 251, 240, 1);
+  --color-yellow-500: rgba(255, 204, 72, 1);
+  --color-yellow-600: rgba(248, 182, 15, 1);
+  --color-yellow-700: rgba(235, 156, 0, 1);
+  --color-yellow-800: rgba(184, 110, 0, 1);
+  --color-yellow-900: rgba(133, 73, 0, 1);
+  --color-yellow-950: rgba(100, 55, 0, 1);
+  --color-yellow-focus: rgba(235, 156, 0, 0.24);
+  --color-yellow-focusvisible: rgba(235, 156, 0, 0.32);
+  --color-yellow-hover: rgba(235, 156, 0, 0.12);
+  --color-yellow-outlinedborder: rgba(235, 156, 0, 0.56);
+  --color-yellow-selected: rgba(235, 156, 0, 0.16);
+
+  --topnav-button-bg: #4878f3;
+  --tw-prose-code-bg: var(--color-gray-100);
+  --tw-prose-code-bg-dark: var(--color-gray-800);
+}
diff --git a/assets/css/toc.css b/assets/css/toc.css
deleted file mode 100644
index 91ff92d7cd99..000000000000
--- a/assets/css/toc.css
+++ /dev/null
@@ -1,14 +0,0 @@
-@layer components {
-  #TableOfContents {
-    .toc a {
-      @apply block max-w-full truncate py-1 pl-2 hover:font-medium hover:no-underline;
-      &[aria-current="true"],
-      &:hover {
-        @apply border-l-2 border-l-gray-light bg-gradient-to-r from-gray-light-100 font-medium text-black dark:border-l-gray-dark dark:from-gray-dark-200 dark:text-white;
-      }
-      &:not([aria-current="true"]) {
-        @apply text-gray-light-600 hover:text-black dark:text-gray-dark-700 dark:hover:text-white;
-      }
-    }
-  }
-}
diff --git a/assets/css/typography.css b/assets/css/typography.css
deleted file mode 100644
index 008e7af70494..000000000000
--- a/assets/css/typography.css
+++ /dev/null
@@ -1,77 +0,0 @@
-@layer base {
-
-  /*
-   * Font faces for Roboto Flex and Roboto Mono.
-   *
-   * - https://fonts.google.com/specimen/Roboto+Flex
-   * - https://fonts.google.com/specimen/Roboto+Mono
-   *
-   * The TTF fonts have been compressed to woff2,
-   * preserving the latin character subset.
-   *
-   * */
-
-  /* Roboto Flex */
-  @font-face {
-    font-family: 'Roboto Flex';
-    src: url('/assets/fonts/RobotoFlex.woff2') format('woff2');
-    font-weight: 100 1000; /* Range of weights Roboto Flex supports */
-    font-stretch: 100%; /* Range of width Roboto Flex supports */
-    font-style: oblique 0deg 10deg; /* Range of oblique angle Roboto Flex supports */
-    font-display: fallback;
-  }
-
-  /* Roboto Mono */
-  @font-face {
-    font-family: 'Roboto Mono';
-    src: url('/assets/fonts/RobotoMono-Regular.woff2') format('woff2');
-    font-weight: 100 700; /* Define the range of weight the variable font supports */
-    font-style: normal;
-    font-display: fallback;
-  }
-
-  /* Roboto Mono Italic */
-  @font-face {
-    font-family: 'Roboto Mono';
-    src: url('/assets/fonts/RobotoMono-Italic.woff2') format('woff2');
-    font-weight: 100 700; /* Define the range of weight the variable font supports */
-    font-style: italic;
-    font-display: fallback;
-  }
-
-  .prose {
-    li {
-      @apply my-2;
-      > :last-child,
-      > :first-child {
-        margin: 0;
-      }
-    }
-    a {
-      font-weight: 400;
-    }
-    hr {
-      @apply mb-4 mt-8;
-    }
-    h1 {
-      @apply my-4 text-4xl;
-      line-height: 1.167;
-    }
-    h2 {
-      @apply mb-4 mt-8 text-3xl;
-      line-height: 1.2;
-    }
-    h3 {
-      @apply text-2xl;
-      line-height: 1.167;
-    }
-    h4 {
-      @apply text-xl;
-      line-height: 1.235;
-    }
-    h5 {
-      @apply text-lg;
-      line-height: 1.75;
-    }
-  }
-}
diff --git a/assets/css/utilities.css b/assets/css/utilities.css
new file mode 100644
index 000000000000..819af1bf9880
--- /dev/null
+++ b/assets/css/utilities.css
@@ -0,0 +1,367 @@
+@utility icon-xs {
+  svg {
+    font-size: 12px;
+  }
+}
+
+@utility icon-sm {
+  svg {
+    font-size: 16px;
+  }
+}
+
+@utility icon-md {
+  svg {
+    font-size: 24px;
+  }
+}
+
+@utility icon-lg {
+  svg {
+    font-size: 32px;
+  }
+}
+
+@utility text-primary-blue {
+  color: var(--color-primary-blue);
+}
+
+@utility link {
+  @apply text-blue no-underline dark:text-blue-400;
+  font-weight: inherit;
+  &:hover {
+    @apply underline underline-offset-3;
+  }
+}
+
+@utility invertible {
+  @apply dark:hue-rotate-180 dark:invert dark:filter;
+}
+
+@utility bg-background-toc {
+  background-color: var(--color-navbar-bg);
+  .dark & {
+    background-color: var(--color-navbar-bg-dark);
+  }
+}
+
+@utility icon-svg {
+  svg {
+    font-size: 24px;
+    width: 1em;
+    height: 1em;
+    display: inline-block;
+    fill: currentColor;
+  }
+}
+
+@utility icon-xs {
+  svg {
+    font-size: 12px;
+  }
+}
+
+@utility icon-sm {
+  svg {
+    font-size: 16px;
+  }
+}
+
+@utility icon-lg {
+  svg {
+    font-size: 32px;
+  }
+}
+
+@utility navbar-font {
+  font-size: var(--navbar-font-size);
+  color: var(--color-navbar-text);
+  .dark & {
+    color: var(--color-navbar-text-dark);
+  }
+}
+
+@utility navbar-entry-margin {
+  @apply px-2 py-1;
+}
+
+@utility navbar-group {
+  @apply mt-5;
+}
+
+@utility navbar-entry-background-current {
+  @apply bg-gray-100 dark:bg-gray-900;
+}
+@utility navbar-group-font-title {
+  font-size: var(--color-navbar-group-font-title-size);
+  @apply pb-1.5 font-semibold uppercase;
+  color: var(--color-navbar-text);
+  .dark & {
+    color: var(--color-navbar-text-dark);
+  }
+}
+
+@utility prose {
+  table:not(.lntable) code {
+    overflow-wrap: unset;
+    white-space: nowrap;
+  }
+
+  /* code in `inline code` style */
+  :where(code):not(:where([class~="not-prose"], [class~="not-prose"] *)),
+  a > code {
+    font-size: 0.875em;
+    font-weight: 400 !important;
+    border: 1px solid !important;
+    border-radius: 0.25rem;
+    border: none !important;
+    padding: 4px !important;
+    background: var(--tw-prose-code-bg) !important;
+    .dark & {
+      background: var(--tw-prose-code-bg-dark) !important;
+    }
+    &::before,
+    &::after {
+      content: none !important;
+    }
+  }
+
+  /* code blocks with unrecognized languages*/
+  pre:not(.chroma) {
+    @apply overflow-x-auto p-3;
+    background: var(--tw-prose-code-bg);
+    color: var(--color-gray-700);
+    .dark & {
+      background: var(--tw-prose-code-bg-dark);
+      color: var(--color-gray-200);
+    }
+  }
+
+  .highlight {
+    @apply my-0 overflow-x-auto p-2;
+
+    /* LineTableTD */
+    .lntd {
+      vertical-align: top;
+      padding: 0;
+      margin: 0;
+      font-weight: 400;
+      padding: 0 4px;
+      &:first-child {
+        width: 0;
+      }
+    }
+
+    /* LineTableTD */
+    .lntd {
+      vertical-align: top;
+      padding: 0;
+      margin: 0;
+      border: 0;
+    }
+    /* LineTable */
+    .lntable {
+      display: table;
+      width: 100%;
+      border-spacing: 0;
+      padding: 0;
+      margin: 0;
+      border: 0;
+      /* LineNumberColumnHighlight */
+      .lntd:first-child .hl {
+        display: block;
+      }
+    }
+  }
+}
+
+@utility section-card {
+  @apply flex h-full flex-col gap-2 rounded-sm border p-4 drop-shadow-xs hover:drop-shadow-lg;
+  @apply text-gray dark:text-gray-200;
+  @apply border-gray-100 bg-gray-50 hover:border-gray-200 dark:border-gray-600 dark:bg-gray-900 hover:dark:border-gray-500;
+}
+
+@utility section-card-text {
+  @apply leading-snug text-gray-800 dark:text-gray-200;
+}
+@utility section-card-title {
+  @apply text-xl font-semibold text-gray-900 dark:text-gray-100;
+}
+
+@utility sub-button {
+  @apply flex w-full items-center gap-2 rounded-sm px-2 py-2 text-left text-gray-600 transition-colors hover:bg-gray-50 dark:text-gray-100 dark:hover:bg-gray-800;
+}
+
+@utility dropdown-base {
+  @apply rounded-sm border border-gray-300 bg-white text-gray-600 dark:border-gray-300 dark:bg-gray-900 dark:text-gray-100;
+}
+
+@utility toc {
+  a {
+    @apply block max-w-full truncate py-1 pl-2 hover:font-medium hover:no-underline;
+    &[aria-current="true"],
+    &:hover {
+      @apply border-l-2 border-x-gray-200 bg-gradient-to-r from-gray-50 font-medium text-black dark:border-l-gray-300 dark:from-gray-900 dark:text-white;
+    }
+    &:not([aria-current="true"]) {
+      @apply text-gray-600 hover:text-black dark:text-gray-100 dark:hover:text-white;
+    }
+  }
+}
+@utility scrollbar-hover {
+  /* Firefox: hide the thumb until hover */
+  scrollbar-width: thin;
+  scrollbar-color: transparent transparent;
+  &:hover {
+    scrollbar-color: var(--color-gray-400) transparent;
+  }
+  .dark &:hover {
+    scrollbar-color: var(--color-gray-600) transparent;
+  }
+  /* WebKit: reserve the track, reveal the thumb only on hover */
+  &::-webkit-scrollbar {
+    width: 8px;
+    height: 8px;
+  }
+  &::-webkit-scrollbar-thumb {
+    border-radius: 9999px;
+    background-color: transparent;
+  }
+  &:hover::-webkit-scrollbar-thumb {
+    background-color: var(--color-gray-400);
+  }
+  .dark &:hover::-webkit-scrollbar-thumb {
+    background-color: var(--color-gray-600);
+  }
+}
+
+@utility chip {
+  @apply border-divider-light dark:border-divider-dark inline-flex items-center gap-1 rounded-full border bg-gray-100 px-2 text-sm text-gray-800 select-none dark:bg-gray-700 dark:text-gray-200;
+}
+
+@utility pagination-link {
+  @apply flex items-center justify-center rounded-sm p-2;
+}
+
+@utility breadcrumbs {
+  /* Absolute size so breadcrumbs render identically inside and outside prose */
+  font-size: calc(var(--text-base) * 0.9);
+}
+
+/* Guides landing: collapse section spacing into a flat list while filtering.
+   Grouped spacing is the static default; this only applies once the page is
+   being filtered, so it never affects first paint (no layout jank). */
+.guides-flat > section {
+  border-top-width: 0 !important;
+  padding-top: 0 !important;
+  padding-bottom: 0 !important;
+}
+
+@utility topbar-button {
+  @apply min-h-10 max-w-40 rounded-md border-1 border-blue-300 bg-(--topnav-button-bg) px-2 text-center font-semibold text-white;
+  @apply inline-flex items-center justify-center gap-1.5 transition-colors hover:border-blue-300 hover:bg-blue-400;
+  svg {
+    font-size: 19px;
+  }
+}
+@utility topbar-button-clear {
+  @apply min-h-9 px-0 text-center font-semibold text-white/95 transition-colors hover:text-white/85;
+  svg {
+    font-size: 19px;
+  }
+}
+
+.footer {
+  @apply ml-auto hidden flex-row justify-between gap-6 px-4 pt-6 pb-2 md:flex;
+  @apply border-t border-gray-200 bg-gray-100 dark:border-gray-700 dark:bg-gray-900;
+  @apply text-gray-600 dark:text-gray-400;
+  a:hover {
+    @apply underline underline-offset-4;
+  }
+}
+
+.social {
+  @apply flex min-w-20 flex-wrap items-center gap-1;
+}
+
+.links {
+  @apply flex items-center gap-3;
+}
+
+.links a {
+  @apply inline-flex min-w-15 truncate whitespace-normal;
+}
+
+.secondaryLinks {
+  @apply flex items-center;
+  a,
+  button {
+    @apply whitespace-normal md:truncate;
+  }
+}
+
+.secondaryLinks > *:not(:last-child)::after {
+  content: "|";
+  @apply mx-1 text-gray-400;
+}
+
+.ot-sdk-show-settings {
+  @apply !text-gray-600 hover:!text-gray-800 dark:!text-gray-400 dark:hover:!text-gray-200;
+  @apply !m-0 !min-w-15 !truncate !border-none !p-0 !text-sm;
+}
+#ot-sdk-btn.ot-sdk-show-settings:hover,
+#ot-sdk-btn.optanon-show-settings:hover {
+  @apply !text-gray-600 underline decoration-1 underline-offset-4 hover:!bg-transparent dark:!text-gray-400;
+}
+
+@keyframes reflection {
+  0% {
+    transform: translateX(-100%);
+  }
+  18% {
+    transform: translateX(100%);
+  }
+  100% {
+    transform: translateX(100%);
+  }
+}
+
+@utility shimmer {
+  position: relative;
+  overflow: hidden;
+
+  & > * {
+    position: relative;
+    z-index: 2;
+  }
+
+  &::after {
+    content: '';
+    position: absolute;
+    top: 0;
+    left: 0;
+    width: 100%;
+    height: 100%;
+    background: linear-gradient(
+      110deg,
+      transparent 0%,
+      transparent 43%,
+      rgba(123, 164, 244, 0.25) 49%,
+      rgba(170, 196, 248, 0.45) 50%,
+      rgba(123, 164, 244, 0.25) 51%,
+      transparent 57%,
+      transparent 100%
+    );
+    transform: translateX(-100%);
+    pointer-events: none;
+    z-index: 1;
+
+    @media (prefers-reduced-motion: no-preference) {
+      animation: reflection 3s ease-in-out 3s forwards;
+    }
+  }
+
+  &:hover {
+    @apply bg-blue-800 border-blue-400;
+  }
+}
diff --git a/assets/favicons/docs.ico b/assets/favicons/docs.ico
deleted file mode 100644
index 7925783d50cd..000000000000
Binary files a/assets/favicons/docs.ico and /dev/null differ
diff --git a/assets/favicons/docs@2x.ico b/assets/favicons/docs@2x.ico
deleted file mode 100644
index 523925f7bd7c..000000000000
Binary files a/assets/favicons/docs@2x.ico and /dev/null differ
diff --git a/assets/icons/AppleMac.svg b/assets/icons/AppleMac.svg
new file mode 100644
index 000000000000..b218d8cdcafd
--- /dev/null
+++ b/assets/icons/AppleMac.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="blue" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0_26_122" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="0" y="0" width="24" height="24">
+<path d="M17.9549 21.7542C16.8041 22.871 15.5344 22.6969 14.3241 22.1703C13.0373 21.6331 11.861 21.5991 10.5021 22.1703C8.80981 22.9007 7.91165 22.6884 6.89246 21.7542C1.13826 15.8301 1.98759 6.80604 8.52741 6.46631C10.1135 6.55125 11.224 7.34324 12.1583 7.40906C13.5469 7.12666 14.8761 6.31768 16.3625 6.42385C18.1482 6.56823 19.4837 7.27317 20.3755 8.54079C16.7022 10.749 17.5728 15.5902 20.9467 16.9491C20.2715 18.7221 19.4052 20.4738 17.9528 21.769L17.9549 21.7542ZM12.0309 6.40261C11.8589 3.76971 13.9928 1.60393 16.4474 1.3916C16.785 4.42794 13.6871 6.69988 12.0309 6.40261Z" fill="currentColor"/>
+</mask>
+<g mask="url(#mask0_26_122)">
+<rect width="24" height="24" fill="currentColor" fill-opacity="0.9"/>
+</g>
+</svg>
diff --git a/static/assets/icons/Compose.svg b/assets/icons/Compose.svg
similarity index 100%
rename from static/assets/icons/Compose.svg
rename to assets/icons/Compose.svg
diff --git a/assets/icons/Linux.svg b/assets/icons/Linux.svg
new file mode 100644
index 000000000000..55554f63b637
--- /dev/null
+++ b/assets/icons/Linux.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0_26_113" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="3" y="1" width="18" height="22">
+<path d="M19.0689 16.3388C19.2698 16.4219 19.443 16.5636 19.5674 16.7466C19.6791 16.9182 19.7575 17.1255 19.8067 17.3685C19.8333 17.5113 19.8652 17.6431 19.8998 17.7667C19.9649 17.9982 20.0631 18.2185 20.1909 18.4202C20.2534 18.5204 20.3372 18.6303 20.4409 18.7525C20.53 18.8527 20.6097 18.9817 20.6802 19.1383C20.7451 19.2791 20.7801 19.4326 20.7826 19.5886C20.7877 19.7385 20.7442 19.8859 20.6589 20.0074C20.5722 20.1253 20.4665 20.227 20.3465 20.308C20.187 20.422 20.0208 20.5222 19.8479 20.6087C19.6751 20.6938 19.5023 20.7831 19.3295 20.8764C19.071 21.0036 18.8241 21.1543 18.5916 21.3268C18.3842 21.4847 18.1755 21.6837 17.9681 21.9281C17.7263 22.2078 17.4464 22.4497 17.1372 22.6462C16.9793 22.7497 16.8078 22.8292 16.628 22.8823C16.4552 22.9318 16.2824 22.9647 16.1095 22.9785C15.708 22.9785 15.3757 22.9071 15.1124 22.7643C14.8492 22.6215 14.6205 22.3606 14.4264 21.9817C14.3706 21.8732 14.3161 21.8059 14.2603 21.7771C14.174 21.7394 14.0833 21.714 13.9904 21.7016L12.9388 21.6165C12.5931 21.589 12.2408 21.5739 11.8805 21.5739C11.5813 21.5743 11.2826 21.5991 10.9872 21.648C10.6827 21.6988 10.3809 21.7593 10.0831 21.8307C10.022 21.8444 9.95949 21.8993 9.897 21.9913C9.81921 22.1029 9.73201 22.2072 9.63643 22.303C9.50692 22.4303 9.35599 22.5322 9.19106 22.6036C8.95605 22.6984 8.70552 22.7455 8.45322 22.7423C8.22455 22.7423 7.97861 22.7176 7.71537 22.6682C7.46911 22.6239 7.23097 22.5406 7.00944 22.421C6.6098 22.2099 6.18325 22.0583 5.74247 21.9707C5.32635 21.8924 4.88763 21.8197 4.42365 21.7565C4.26987 21.7358 4.11722 21.707 3.96632 21.67C3.82692 21.6375 3.69562 21.5753 3.58078 21.4874C3.4754 21.4069 3.38753 21.3045 3.32287 21.1867C3.25197 21.0367 3.21601 20.8717 3.21784 20.7048C3.21784 20.4824 3.24576 20.2682 3.3016 20.0609C3.35743 19.855 3.38801 19.6353 3.39466 19.4074C3.39466 19.2495 3.38402 19.0957 3.36408 18.9461C3.34209 18.7858 3.32789 18.6245 3.32154 18.4628C3.32154 18.0989 3.40529 17.8312 3.57147 17.6582C3.73766 17.4866 3.97962 17.3507 4.29868 17.2504C4.44043 17.2061 4.57392 17.1374 4.69353 17.0472C4.80325 16.9618 4.90719 16.8686 5.00462 16.7685C5.10354 16.6659 5.19383 16.5547 5.2745 16.4363C5.35826 16.3141 5.45132 16.1919 5.55502 16.0711C5.5757 16.0436 5.58693 16.0098 5.58692 15.975C5.58692 15.8885 5.58293 15.8061 5.57629 15.7278L5.55502 15.4697C5.55502 14.9837 5.62814 14.4949 5.77305 14.0006C5.91928 13.5064 6.1094 13.0258 6.34471 12.5521C6.57966 12.0813 6.84342 11.6264 7.1344 11.1902C7.42422 10.7549 7.71271 10.3499 7.99589 9.97783C8.38052 9.48054 8.68572 8.92294 8.89991 8.32616C9.09933 7.755 9.20436 7.13167 9.21101 6.45892C9.21101 6.17472 9.19771 5.89189 9.16979 5.61317C9.1419 5.32805 9.12814 5.04164 9.12858 4.75507C9.12858 4.18254 9.19106 3.66768 9.3147 3.21048C9.43967 2.75191 9.63377 2.35924 9.897 2.02973C10.1602 1.70022 10.5032 1.45446 10.9247 1.2897C11.3488 1.12495 11.854 1.0357 12.4416 1.02197C13.1422 1.02197 13.6992 1.16476 14.1154 1.45171C14.5301 1.73729 14.8492 2.11211 15.0699 2.57754C15.2919 3.04161 15.4342 3.56059 15.4953 4.13311C15.5591 4.70427 15.5937 5.28366 15.6003 5.86992V6.05252C15.6003 6.34634 15.603 6.6072 15.611 6.83511C15.6234 7.29848 15.7255 7.75459 15.9114 8.1765C16.0085 8.39755 16.1534 8.63782 16.3475 8.89456C16.6799 9.34627 17.0202 9.80072 17.3659 10.2579C17.7115 10.7151 18.0266 11.1874 18.3098 11.6721C18.5943 12.1595 18.8269 12.6675 19.0064 13.1961C19.1872 13.726 19.2803 14.2972 19.2869 14.9123C19.2887 15.3972 19.2151 15.8779 19.0689 16.3388ZM10.3557 5.16284C10.4514 5.16284 10.5312 5.18755 10.595 5.23698C10.6598 5.29087 10.7098 5.36142 10.7399 5.44155C10.7732 5.52401 10.7973 5.61016 10.8117 5.6983C10.825 5.78479 10.8329 5.87404 10.8329 5.9674C10.8351 6.02637 10.8242 6.08507 10.801 6.13902C10.7783 6.1846 10.7466 6.22481 10.708 6.25709L10.583 6.36419C10.5384 6.40315 10.4971 6.44586 10.4594 6.49187C10.4095 6.57203 10.3415 6.63847 10.2613 6.68546C10.1789 6.73482 10.0991 6.78843 10.022 6.8461C9.94833 6.90128 9.87898 6.96233 9.81458 7.0287C9.78239 7.06454 9.75755 7.10673 9.74155 7.15274C9.72556 7.19875 9.71874 7.24763 9.72152 7.29643C9.72152 7.36096 9.75209 7.4145 9.81458 7.45707C9.9696 7.5579 10.0926 7.7035 10.1682 7.87582C10.2373 8.04058 10.3145 8.20121 10.3969 8.35911C10.4793 8.51562 10.587 8.64743 10.7186 8.75589C10.8502 8.86298 11.055 8.91653 11.3302 8.91653H11.394C11.6705 8.9028 11.9337 8.82729 12.1837 8.69136C12.4323 8.55544 12.6822 8.41265 12.9308 8.26163C12.9741 8.23648 13.0195 8.21535 13.0664 8.19847C13.1147 8.18068 13.16 8.1552 13.2007 8.12296L13.9585 7.51199C13.9717 7.46596 13.9823 7.41921 13.9904 7.37194C13.9985 7.32175 14.0056 7.2714 14.0117 7.22092C14.014 7.15266 13.9954 7.08538 13.9585 7.0287C13.9245 6.9789 13.8827 6.93528 13.8348 6.89964C13.7817 6.86222 13.7214 6.83694 13.658 6.8255C13.5947 6.81237 13.5324 6.794 13.4719 6.77058C13.3062 6.7354 13.1478 6.67034 13.0039 6.57837C12.8611 6.48678 12.7074 6.41478 12.5466 6.36419C12.52 6.35595 12.4987 6.33535 12.4841 6.29966C12.4683 6.25738 12.4545 6.2143 12.4429 6.1706C12.4292 6.12533 12.4256 6.07747 12.4323 6.03055C12.4398 5.9946 12.4361 5.95708 12.4216 5.92346C12.4216 5.83834 12.4283 5.7491 12.4429 5.65573C12.4573 5.56122 12.4888 5.47037 12.536 5.38801C12.5765 5.31173 12.6333 5.24599 12.7021 5.19579C12.7841 5.14639 12.8771 5.11989 12.972 5.1189C13.1874 5.1189 13.3429 5.20128 13.44 5.36604C13.537 5.5308 13.5889 5.70928 13.5955 5.9015C13.5973 5.98693 13.5795 6.07159 13.5437 6.14863C13.5082 6.22192 13.49 6.30284 13.4905 6.38478C13.4905 6.44244 13.5091 6.48089 13.5437 6.50286C13.5856 6.52656 13.6317 6.54105 13.6793 6.54542C13.8388 6.54542 13.9412 6.50697 13.9904 6.42872C14.0463 6.3197 14.0747 6.19785 14.0728 6.07449C14.0728 5.90973 14.0595 5.72713 14.0329 5.52668C14.0066 5.33274 13.95 5.14449 13.8654 4.96925C13.7879 4.80468 13.6784 4.65838 13.5437 4.53951C13.3994 4.42114 13.2186 4.36067 13.0345 4.36927C12.6756 4.36927 12.415 4.46125 12.2554 4.64798C12.0959 4.83333 12.0135 5.11204 12.0068 5.48411C12.0068 5.59121 12.0135 5.6983 12.0268 5.80539C12.0401 5.91385 12.0481 6.02094 12.0481 6.12804C12.0481 6.16373 12.0441 6.18158 12.0374 6.18158C12.0159 6.17674 11.9949 6.16937 11.9749 6.15961C11.9335 6.14227 11.8923 6.12442 11.8513 6.10607C11.8005 6.08391 11.748 6.066 11.6944 6.05252C11.6061 6.03035 11.5143 6.02662 11.4245 6.04154C11.3694 6.04876 11.3139 6.05243 11.2584 6.05252C11.1613 6.05252 11.1121 6.03467 11.1121 5.99898C11.1121 5.89189 11.1068 5.75596 11.0922 5.59121C11.0789 5.42645 11.0443 5.26169 10.9885 5.09694C10.9421 4.95035 10.8719 4.81294 10.7811 4.69054C10.6973 4.58345 10.5737 4.52578 10.4075 4.51892C10.2959 4.51626 10.1876 4.55861 10.1057 4.63699C10.0204 4.71853 9.94695 4.81241 9.8877 4.91571C9.82399 5.02725 9.78495 5.15196 9.77336 5.28091C9.76221 5.39564 9.74847 5.51009 9.73215 5.62416C9.73749 5.81358 9.76882 6.00125 9.82521 6.18158C9.85978 6.29554 9.89833 6.39576 9.93955 6.48226C9.98076 6.56738 10.0299 6.60995 10.0858 6.60995C10.119 6.60995 10.1656 6.58523 10.2201 6.53581C10.2759 6.48501 10.3038 6.4397 10.3038 6.39576C10.3038 6.3738 10.2932 6.36007 10.2719 6.3532C10.2518 6.34605 10.2307 6.34234 10.2094 6.34222C10.1616 6.34222 10.119 6.3175 10.0845 6.2667C10.0488 6.21407 10.021 6.15622 10.002 6.09508C9.98021 6.02768 9.95938 5.95994 9.93955 5.89189C9.89814 5.70664 9.92417 5.51215 10.0127 5.34544C10.0751 5.23012 10.1895 5.1697 10.3557 5.16284ZM8.09028 21.8636C8.25646 21.8636 8.41998 21.8499 8.57952 21.8197C8.73745 21.7916 8.88893 21.7334 9.02621 21.648C9.15786 21.5694 9.2656 21.4543 9.3373 21.3158C9.41294 21.1549 9.45549 20.9796 9.46227 20.8009C9.46228 20.6732 9.44115 20.5465 9.39979 20.4261C9.35755 20.3033 9.29797 20.1877 9.22297 20.0829C9.14092 19.9486 9.05078 19.8197 8.95309 19.6971C8.85536 19.574 8.76522 19.4447 8.68321 19.3099C8.55392 19.1136 8.4254 18.9169 8.29767 18.7195C8.17403 18.5273 8.04907 18.3241 7.92543 18.1085C7.81611 17.9259 7.71193 17.74 7.61301 17.5511C7.51136 17.3583 7.39299 17.1754 7.25937 17.0047C7.17499 16.8959 7.07761 16.7985 6.96955 16.715C6.85854 16.6288 6.72285 16.5834 6.58401 16.5859C6.43917 16.5837 6.29878 16.6376 6.19049 16.7369C6.06673 16.8483 5.95201 16.97 5.84749 17.1008C5.72491 17.2492 5.59301 17.389 5.45265 17.5195C5.30641 17.6555 5.12029 17.7626 4.89162 17.8408C4.73688 17.8837 4.59453 17.9647 4.47683 18.077C4.37978 18.1772 4.33059 18.331 4.33059 18.5383C4.33059 18.6811 4.34123 18.8239 4.3625 18.9666C4.38244 19.1094 4.39706 19.2536 4.40371 19.3964C4.40371 19.5886 4.37712 19.7712 4.31996 19.9428C4.26633 20.1051 4.23849 20.2752 4.23753 20.4467C4.23753 20.6403 4.304 20.7762 4.43429 20.8545C4.56723 20.9341 4.7148 20.9877 4.88098 21.0151C5.08971 21.0522 5.28647 21.0796 5.47392 21.1016C5.66004 21.1236 5.84351 21.1565 6.02431 21.1977C6.20379 21.2417 6.38326 21.287 6.56407 21.3378C6.74354 21.3872 6.93499 21.4668 7.13573 21.5739C7.17562 21.5945 7.23943 21.6206 7.32186 21.648L7.60237 21.7442C7.70607 21.7812 7.80312 21.8101 7.89352 21.8307C7.95786 21.8485 8.02378 21.8595 8.09028 21.8636ZM11.8925 20.5758C12.0866 20.5758 12.294 20.5552 12.516 20.5112C12.968 20.4238 13.4052 20.2683 13.8136 20.0499C14.0037 19.9498 14.1844 19.8317 14.3533 19.6971C14.3701 19.6775 14.3844 19.6558 14.3959 19.6325C14.4091 19.605 14.4194 19.5759 14.4264 19.546V19.5351C14.4677 19.3785 14.5022 19.2055 14.5301 19.0202C14.5589 18.8314 14.5833 18.6418 14.6033 18.4518C14.6234 18.2618 14.6477 18.0722 14.6764 17.8834C14.703 17.698 14.7282 17.5154 14.7482 17.3369C14.7761 17.1447 14.8107 16.958 14.8519 16.7795C14.8944 16.601 14.9489 16.4322 15.018 16.2743C15.0864 16.1188 15.1814 15.9774 15.2986 15.8569C15.4349 15.7212 15.5888 15.6057 15.7559 15.5136V15.4917L15.7453 15.4601C15.7476 15.3873 15.7692 15.3165 15.8077 15.2555C15.8543 15.1767 15.9063 15.1015 15.9633 15.0304C16.0186 14.9581 16.0857 14.8964 16.1614 14.8477C16.2306 14.8049 16.3036 14.769 16.3794 14.7407C16.3375 14.5681 16.2923 14.3965 16.2438 14.2258C16.1957 14.0559 16.154 13.8842 16.1188 13.7109C16.0848 13.4917 16.0436 13.2737 15.9952 13.0574C15.9567 12.8896 15.9078 12.7245 15.849 12.5631C15.7894 12.4059 15.7089 12.258 15.6097 12.1238C15.5073 11.981 15.3783 11.808 15.2268 11.6089C15.1689 11.5421 15.1164 11.4705 15.0699 11.3947C15.0338 11.3096 15.0131 11.2184 15.0087 11.1256C14.9922 11.0318 14.9713 10.9388 14.9463 10.8469C14.8529 10.4992 14.7455 10.1557 14.6245 9.8172C14.5607 9.63646 14.4842 9.46072 14.3959 9.29135C14.3252 9.15573 14.249 9.02334 14.1672 8.89456C14.0981 8.78747 14.0249 8.73393 13.9492 8.73393C13.783 8.73393 13.5849 8.80257 13.3562 8.9385C13.1289 9.07442 12.8856 9.22408 12.6304 9.38883C12.3738 9.55359 12.1252 9.70736 11.8819 9.85015C11.6399 9.99294 11.4219 10.0602 11.2278 10.0533C11.0206 10.0532 10.8195 9.9817 10.6561 9.85015C10.4801 9.71161 10.3195 9.55319 10.1775 9.37785C10.0326 9.19936 9.91163 9.04559 9.81458 8.91653C9.71753 8.78747 9.64574 8.71608 9.59655 8.70235C9.54204 8.70235 9.51013 8.74491 9.50349 8.83003C9.49608 8.92641 9.49254 9.02305 9.49285 9.11973V9.30233C9.49285 9.34627 9.4862 9.37373 9.47158 9.38883C9.3958 9.55359 9.31205 9.71422 9.22297 9.87074C9.13257 10.0286 9.0435 10.1893 8.95309 10.354C8.77401 10.6706 8.67396 11.0283 8.66194 11.3947C8.66194 11.5018 8.66859 11.6089 8.68321 11.716C8.69651 11.8231 8.73107 11.9274 8.78691 12.0277L8.76564 12.0689C8.71227 12.1454 8.65314 12.2175 8.58882 12.2844C8.52332 12.3533 8.46454 12.4288 8.41334 12.5096C8.15904 12.8975 7.97566 13.3303 7.87225 13.7864C7.76855 14.2436 7.71271 14.7091 7.70607 15.18C7.70607 15.3022 7.71404 15.4244 7.72734 15.5452C7.74063 15.6674 7.74861 15.7882 7.74861 15.9104C7.7482 15.95 7.74465 15.9895 7.73797 16.0285C7.73129 16.0675 7.72774 16.107 7.72734 16.1466C7.87512 16.1638 8.01729 16.2149 8.14346 16.2962C8.30299 16.3896 8.47582 16.5077 8.66194 16.6505C8.84807 16.7932 9.02621 16.958 9.19239 17.1447C9.35858 17.3301 9.51678 17.5113 9.66967 17.6912C9.82255 17.8696 9.9329 18.0481 10.002 18.2266C10.0712 18.4051 10.1164 18.552 10.1363 18.666C10.1399 18.749 10.127 18.8319 10.0984 18.9095C10.0698 18.9872 10.0262 19.0581 9.97012 19.1177C9.8509 19.2378 9.70996 19.3325 9.55533 19.3964C9.67366 19.6106 9.81857 19.7932 9.99139 19.9428C10.1642 20.0939 10.3517 20.2147 10.5524 20.308C10.7532 20.4014 10.9712 20.4687 11.2065 20.5112C11.4418 20.5552 11.6718 20.5758 11.8925 20.5758ZM16.0577 22.0998C16.2026 22.0998 16.3448 22.0778 16.4831 22.0352C16.6926 21.9732 16.892 21.8793 17.0747 21.7565C17.2555 21.6343 17.4204 21.4847 17.5733 21.3048C17.9344 20.8745 18.3763 20.5242 18.8721 20.2751L19.2151 20.1144C19.3328 20.0615 19.4469 20.0005 19.5568 19.9318C19.6361 19.8799 19.7097 19.8192 19.7762 19.7506C19.8096 19.7172 19.8361 19.677 19.8539 19.6327C19.8717 19.5883 19.8806 19.5406 19.8799 19.4925C19.8799 19.4373 19.8691 19.3826 19.8479 19.3319C19.8231 19.2747 19.7919 19.2208 19.7549 19.1712C19.6601 19.035 19.5701 18.8953 19.485 18.7525C19.408 18.6225 19.3418 18.4861 19.2869 18.3447L19.1207 17.9163C19.0608 17.7591 19.0119 17.5976 18.9745 17.433C18.9601 17.3822 18.9356 17.335 18.9027 17.2944C18.8359 17.1912 18.7446 17.1074 18.6376 17.0509C18.5305 16.9944 18.4113 16.9672 18.2912 16.9717C18.1672 16.9713 18.0452 17.0044 17.9375 17.0678L17.5839 17.2724C17.4608 17.3429 17.3362 17.4107 17.2103 17.4756C17.0878 17.5392 16.9526 17.5722 16.8155 17.5717C16.6929 17.5772 16.5721 17.54 16.4725 17.466C16.3769 17.3876 16.2989 17.2888 16.2438 17.1763C16.1847 17.0618 16.1327 16.9434 16.0883 16.8221L15.9633 16.4678C15.9091 16.5597 15.8468 16.6461 15.7772 16.726C15.706 16.8078 15.6497 16.9022 15.611 17.0047C15.5206 17.2189 15.4647 17.4578 15.4448 17.7227C15.4102 18.1374 15.365 18.541 15.3092 18.9351C15.2523 19.3368 15.1588 19.7322 15.03 20.1158C14.9933 20.2385 14.9653 20.3638 14.9463 20.4906C14.9256 20.6221 14.9114 20.7545 14.9037 20.8874C14.9037 21.2375 15.0087 21.5272 15.2161 21.7565C15.4235 21.9844 15.704 22.0998 16.0577 22.0998Z" fill="currentColor"/>
+</mask>
+<g mask="url(#mask0_26_113)">
+<rect width="24" height="24" fill="currentColor" fill-opacity="0.9"/>
+</g>
+</svg>
diff --git a/static/assets/icons/Scout.svg b/assets/icons/Scout.svg
similarity index 100%
rename from static/assets/icons/Scout.svg
rename to assets/icons/Scout.svg
diff --git a/static/assets/icons/Testcontainers.svg b/assets/icons/Testcontainers.svg
similarity index 100%
rename from static/assets/icons/Testcontainers.svg
rename to assets/icons/Testcontainers.svg
diff --git a/static/assets/icons/Whale.svg b/assets/icons/Whale.svg
similarity index 100%
rename from static/assets/icons/Whale.svg
rename to assets/icons/Whale.svg
diff --git a/assets/icons/Windows.svg b/assets/icons/Windows.svg
new file mode 100644
index 000000000000..7244da36d971
--- /dev/null
+++ b/assets/icons/Windows.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0_26_117" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="0" y="0" width="24" height="24">
+<path d="M2.8584 11.5731H10.2447V4.31147L2.8584 5.34754V11.5731ZM2.8584 18.6499L10.2447 19.682V12.503H2.8584V18.6499ZM11.0617 4.19737V11.5731H20.89V2.82031L11.0591 4.19737H11.0617ZM11.0617 19.7961L20.89 21.1732V12.5043H11.0591V19.7961H11.0617Z" fill="currentColor"/>
+</mask>
+<g mask="url(#mask0_26_117)">
+<rect width="24" height="24" fill="currentColor" fill-opacity="0.9"/>
+</g>
+</svg>
diff --git a/assets/icons/cagent.svg b/assets/icons/cagent.svg
new file mode 100644
index 000000000000..669a0e7b3fb7
--- /dev/null
+++ b/assets/icons/cagent.svg
@@ -0,0 +1,14 @@
+<svg width="825" height="824" viewBox="0 0 825 824" fill="none" xmlns="http://www.w3.org/2000/svg">
+<rect x="0.883789" width="824" height="824" rx="158" fill="#080B0F"/>
+<mask id="path-2-inside-1_52_117" fill="white">
+<path d="M277.566 426.88C338.755 427.655 388.119 477.498 388.119 538.871L388.11 540.318C387.335 601.507 337.492 650.871 276.119 650.871L274.672 650.862C213.965 650.094 164.897 601.026 164.128 540.318L164.119 538.871C164.119 477.015 214.263 426.871 276.119 426.871L277.566 426.88ZM551.096 426.862C612.285 427.637 661.648 477.481 661.648 538.854L661.64 540.301C660.865 601.489 611.021 650.853 549.648 650.854L548.201 650.845C487.012 650.07 437.649 600.226 437.648 538.854C437.648 476.998 487.793 426.854 549.648 426.854L551.096 426.862ZM276.119 476.871C241.877 476.871 214.119 504.629 214.119 538.871C214.119 573.113 241.877 600.871 276.119 600.871C310.361 600.871 338.119 573.113 338.119 538.871C338.119 504.629 310.361 476.871 276.119 476.871ZM549.648 476.854C515.407 476.854 487.648 504.612 487.648 538.854C487.649 573.095 515.407 600.854 549.648 600.854C583.89 600.853 611.648 573.095 611.648 538.854C611.648 504.612 583.89 476.854 549.648 476.854ZM412.569 188C474.425 188 524.569 238.144 524.569 300C524.569 361.856 474.425 412 412.569 412C350.713 412 300.569 361.856 300.569 300C300.569 238.144 350.713 188 412.569 188ZM412.569 238C378.328 238 350.569 265.758 350.569 300C350.569 334.242 378.328 362 412.569 362C446.811 362 474.569 334.241 474.569 300C474.569 265.759 446.811 238 412.569 238Z"/>
+</mask>
+<path d="M277.566 426.88C338.755 427.655 388.119 477.498 388.119 538.871L388.11 540.318C387.335 601.507 337.492 650.871 276.119 650.871L274.672 650.862C213.965 650.094 164.897 601.026 164.128 540.318L164.119 538.871C164.119 477.015 214.263 426.871 276.119 426.871L277.566 426.88ZM551.096 426.862C612.285 427.637 661.648 477.481 661.648 538.854L661.64 540.301C660.865 601.489 611.021 650.853 549.648 650.854L548.201 650.845C487.012 650.07 437.649 600.226 437.648 538.854C437.648 476.998 487.793 426.854 549.648 426.854L551.096 426.862ZM276.119 476.871C241.877 476.871 214.119 504.629 214.119 538.871C214.119 573.113 241.877 600.871 276.119 600.871C310.361 600.871 338.119 573.113 338.119 538.871C338.119 504.629 310.361 476.871 276.119 476.871ZM549.648 476.854C515.407 476.854 487.648 504.612 487.648 538.854C487.649 573.095 515.407 600.854 549.648 600.854C583.89 600.853 611.648 573.095 611.648 538.854C611.648 504.612 583.89 476.854 549.648 476.854ZM412.569 188C474.425 188 524.569 238.144 524.569 300C524.569 361.856 474.425 412 412.569 412C350.713 412 300.569 361.856 300.569 300C300.569 238.144 350.713 188 412.569 188ZM412.569 238C378.328 238 350.569 265.758 350.569 300C350.569 334.242 378.328 362 412.569 362C446.811 362 474.569 334.241 474.569 300C474.569 265.759 446.811 238 412.569 238Z" fill="url(#paint0_radial_52_117)"/>
+<path d="M277.566 426.88L277.883 401.882L277.801 401.881L277.718 401.88L277.566 426.88ZM388.119 538.871L413.119 539.023L413.119 538.947V538.871H388.119ZM388.11 540.318L413.108 540.635L413.109 540.553L413.11 540.47L388.11 540.318ZM276.119 650.871L275.967 675.871L276.043 675.871H276.119V650.871ZM274.672 650.862L274.355 675.86L274.438 675.861L274.52 675.862L274.672 650.862ZM164.128 540.318L139.128 540.47L139.129 540.553L139.13 540.635L164.128 540.318ZM164.119 538.871H139.119V538.947L139.12 539.023L164.119 538.871ZM276.119 426.871L276.271 401.872L276.195 401.871H276.119V426.871ZM551.096 426.862L551.412 401.864L551.33 401.863L551.248 401.863L551.096 426.862ZM661.648 538.854L686.648 539.005L686.648 538.929V538.854H661.648ZM661.64 540.301L686.638 540.617L686.639 540.535L686.639 540.453L661.64 540.301ZM549.648 650.854L549.497 675.853L549.573 675.854H549.648L549.648 650.854ZM548.201 650.845L547.885 675.843L547.967 675.844L548.049 675.844L548.201 650.845ZM437.648 538.854H412.648V538.854L437.648 538.854ZM549.648 426.854L549.8 401.854L549.724 401.854H549.648V426.854ZM276.119 476.871V451.871V476.871ZM214.119 538.871H189.119H214.119ZM276.119 600.871V625.871V600.871ZM338.119 538.871H363.119H338.119ZM549.648 476.854L549.648 451.854H549.648V476.854ZM487.648 538.854L462.648 538.853V538.854L487.648 538.854ZM549.648 600.854V625.854H549.648L549.648 600.854ZM611.648 538.854L636.648 538.854V538.853L611.648 538.854ZM412.569 188L412.569 163H412.569V188ZM524.569 300H549.569V300L524.569 300ZM412.569 412V437H412.569L412.569 412ZM300.569 300L275.569 300V300H300.569ZM412.569 238L412.57 213H412.569V238ZM350.569 300L325.569 300V300H350.569ZM412.569 362V387H412.57L412.569 362ZM474.569 300H499.569V300L474.569 300ZM277.566 426.88L277.25 451.878C324.773 452.48 363.119 491.199 363.119 538.871H388.119H413.119C413.119 463.797 352.737 402.83 277.883 401.882L277.566 426.88ZM388.119 538.871L363.12 538.719L363.111 540.167L388.11 540.318L413.11 540.47L413.119 539.023L388.119 538.871ZM388.11 540.318L363.112 540.002C362.511 587.525 323.791 625.871 276.119 625.871V650.871V675.871C351.193 675.871 412.16 615.489 413.108 540.635L388.11 540.318ZM276.119 650.871L276.271 625.872L274.824 625.863L274.672 650.862L274.52 675.862L275.967 675.871L276.119 650.871ZM274.672 650.862L274.988 625.864C227.841 625.267 189.723 587.15 189.126 540.002L164.128 540.318L139.13 540.635C140.07 614.902 200.089 674.92 274.355 675.86L274.672 650.862ZM164.128 540.318L189.127 540.167L189.119 538.719L164.119 538.871L139.12 539.023L139.128 540.47L164.128 540.318ZM164.119 538.871H189.119C189.119 490.822 228.07 451.871 276.119 451.871V426.871V401.871C200.456 401.871 139.119 463.208 139.119 538.871H164.119ZM276.119 426.871L275.967 451.871L277.415 451.879L277.566 426.88L277.718 401.88L276.271 401.872L276.119 426.871ZM551.096 426.862L550.779 451.86C598.303 452.462 636.648 491.182 636.648 538.854H661.648H686.648C686.648 463.78 626.266 402.812 551.412 401.864L551.096 426.862ZM661.648 538.854L636.649 538.702L636.64 540.149L661.64 540.301L686.639 540.453L686.648 539.005L661.648 538.854ZM661.64 540.301L636.642 539.984C636.04 587.508 597.32 625.853 549.648 625.854L549.648 650.854L549.648 675.854C624.722 675.853 685.689 615.471 686.638 540.617L661.64 540.301ZM549.648 650.854L549.8 625.854L548.353 625.845L548.201 650.845L548.049 675.844L549.497 675.853L549.648 650.854ZM548.201 650.845L548.518 625.847C500.994 625.245 462.649 586.525 462.648 538.853L437.648 538.854L412.648 538.854C412.649 613.927 473.031 674.895 547.885 675.843L548.201 650.845ZM437.648 538.854H462.648C462.648 490.805 501.6 451.854 549.648 451.854V426.854V401.854C473.985 401.854 412.648 463.191 412.648 538.854H437.648ZM549.648 426.854L549.497 451.853L550.944 451.862L551.096 426.862L551.248 401.863L549.8 401.854L549.648 426.854ZM276.119 476.871V451.871C228.07 451.871 189.119 490.822 189.119 538.871H214.119H239.119C239.119 518.437 255.685 501.871 276.119 501.871V476.871ZM214.119 538.871H189.119C189.119 586.92 228.07 625.871 276.119 625.871V600.871V575.871C255.685 575.871 239.119 559.306 239.119 538.871H214.119ZM276.119 600.871V625.871C324.168 625.871 363.119 586.92 363.119 538.871H338.119H313.119C313.119 559.306 296.554 575.871 276.119 575.871V600.871ZM338.119 538.871H363.119C363.119 490.822 324.168 451.871 276.119 451.871V476.871V501.871C296.554 501.871 313.119 518.437 313.119 538.871H338.119ZM549.648 476.854V451.854C501.6 451.854 462.648 490.805 462.648 538.853L487.648 538.854L512.648 538.854C512.648 518.419 529.214 501.854 549.648 501.854V476.854ZM487.648 538.854L462.648 538.854C462.649 586.902 501.6 625.854 549.648 625.854V600.854V575.854C529.214 575.854 512.649 559.288 512.648 538.853L487.648 538.854ZM549.648 600.854L549.648 625.854C597.697 625.853 636.648 586.902 636.648 538.854L611.648 538.854L586.648 538.853C586.648 559.288 570.083 575.853 549.648 575.854L549.648 600.854ZM611.648 538.854L636.648 538.853C636.648 490.805 597.697 451.854 549.648 451.854L549.648 476.854L549.648 501.854C570.083 501.854 586.648 518.419 586.648 538.854L611.648 538.854ZM412.569 188L412.569 213C460.618 213 499.569 251.952 499.569 300L524.569 300L549.569 300C549.569 224.337 488.232 163 412.569 163L412.569 188ZM524.569 300H499.569C499.569 348.049 460.618 387 412.569 387L412.569 412L412.569 437C488.232 437 549.569 375.663 549.569 300H524.569ZM412.569 412V387C364.521 387 325.569 348.049 325.569 300H300.569H275.569C275.569 375.663 336.906 437 412.569 437V412ZM300.569 300L325.569 300C325.569 251.951 364.521 213 412.569 213V188V163C336.906 163 275.569 224.337 275.569 300L300.569 300ZM412.569 238V213C364.521 213 325.569 251.951 325.569 300L350.569 300L375.569 300C375.569 279.565 392.135 263 412.569 263V238ZM350.569 300H325.569C325.569 348.049 364.521 387 412.569 387V362V337C392.135 337 375.569 320.435 375.569 300H350.569ZM412.569 362L412.57 387C460.618 387 499.569 348.049 499.569 300H474.569H449.569C449.569 320.434 433.004 337 412.569 337L412.569 362ZM474.569 300L499.569 300C499.569 251.951 460.618 213 412.57 213L412.569 238L412.569 263C433.004 263 449.569 279.566 449.569 300L474.569 300Z" fill="white" mask="url(#path-2-inside-1_52_117)"/>
+<defs>
+<radialGradient id="paint0_radial_52_117" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="translate(412.884 198.029) rotate(90) scale(807.954 883.425)">
+<stop stop-color="#B53CFD"/>
+<stop offset="1" stop-color="#1D2736"/>
+</radialGradient>
+</defs>
+</svg>
diff --git a/assets/icons/claude.svg b/assets/icons/claude.svg
new file mode 100644
index 000000000000..e29f32825727
--- /dev/null
+++ b/assets/icons/claude.svg
@@ -0,0 +1 @@
+<svg fill="currentColor" fill-rule="evenodd" height="1em" style="flex:none;line-height:1" viewBox="0 0 24 24" width="1em" xmlns="http://www.w3.org/2000/svg"><title>Claude</title><path d="M4.709 15.955l4.72-2.647.08-.23-.08-.128H9.2l-.79-.048-2.698-.073-2.339-.097-2.266-.122-.571-.121L0 11.784l.055-.352.48-.321.686.06 1.52.103 2.278.158 1.652.097 2.449.255h.389l.055-.157-.134-.098-.103-.097-2.358-1.596-2.552-1.688-1.336-.972-.724-.491-.364-.462-.158-1.008.656-.722.881.06.225.061.893.686 1.908 1.476 2.491 1.833.365.304.145-.103.019-.073-.164-.274-1.355-2.446-1.446-2.49-.644-1.032-.17-.619a2.97 2.97 0 01-.104-.729L6.283.134 6.696 0l.996.134.42.364.62 1.414 1.002 2.229 1.555 3.03.456.898.243.832.091.255h.158V9.01l.128-1.706.237-2.095.23-2.695.08-.76.376-.91.747-.492.584.28.48.685-.067.444-.286 1.851-.559 2.903-.364 1.942h.212l.243-.242.985-1.306 1.652-2.064.73-.82.85-.904.547-.431h1.033l.76 1.129-.34 1.166-1.064 1.347-.881 1.142-1.264 1.7-.79 1.36.073.11.188-.02 2.856-.606 1.543-.28 1.841-.315.833.388.091.395-.328.807-1.969.486-2.309.462-3.439.813-.042.03.049.061 1.549.146.662.036h1.622l3.02.225.79.522.474.638-.079.485-1.215.62-1.64-.389-3.829-.91-1.312-.329h-.182v.11l1.093 1.068 2.006 1.81 2.509 2.33.127.578-.322.455-.34-.049-2.205-1.657-.851-.747-1.926-1.62h-.128v.17l.444.649 2.345 3.521.122 1.08-.17.353-.608.213-.668-.122-1.374-1.925-1.415-2.167-1.143-1.943-.14.08-.674 7.254-.316.37-.729.28-.607-.461-.322-.747.322-1.476.389-1.924.315-1.53.286-1.9.17-.632-.012-.042-.14.018-1.434 1.967-2.18 2.945-1.726 1.845-.414.164-.717-.37.067-.662.401-.589 2.388-3.036 1.44-1.882.93-1.086-.006-.158h-.055L4.132 18.56l-1.13.146-.487-.456.061-.746.231-.243 1.908-1.312-.006.006z"></path></svg>
\ No newline at end of file
diff --git a/assets/icons/dhi.svg b/assets/icons/dhi.svg
new file mode 100644
index 000000000000..91d515440056
--- /dev/null
+++ b/assets/icons/dhi.svg
@@ -0,0 +1,13 @@
+<svg 
+  class="w-5 h-5"
+  viewBox="0 0 24 24"
+  fill="none"
+  stroke="currentColor"
+  stroke-width="2"
+  stroke-linecap="round"
+  stroke-linejoin="round"
+  xmlns="http://www.w3.org/2000/svg"
+  focusable="false"
+  aria-hidden="true"
+>
+<path d="M18.1639 21.6147V18.6147M18.1639 18.6147V15.6147M18.1639 18.6147H15.1639M18.1639 18.6147H21.1639M19.8692 13.3281C19.9541 12.8974 20 12.4544 20 11.9999V7.21747C20 6.41796 20 6.0182 19.8692 5.67457C19.7537 5.37101 19.566 5.10015 19.3223 4.8854C19.0465 4.64231 18.6722 4.50195 17.9236 4.22122L12.5618 2.21054C12.3539 2.13258 12.25 2.0936 12.143 2.07815C12.0482 2.06444 11.9518 2.06444 11.857 2.07815C11.75 2.0936 11.6461 2.13258 11.4382 2.21054L6.0764 4.22122C5.3278 4.50195 4.9535 4.64231 4.67766 4.8854C4.43398 5.10015 4.24627 5.37101 4.13076 5.67457C4 6.0182 4 6.41796 4 7.21747V11.9999C4 16.9083 9.35396 20.4783 11.302 21.6147C11.5234 21.7439 11.6341 21.8085 11.7903 21.842C11.9116 21.868 12.0884 21.868 12.2097 21.842C12.3659 21.8085 12.4766 21.7439 12.698 21.6147C12.986 21.4467 13.3484 21.2255 13.757 20.9547M14.517 9.70865C14.517 10.4365 14.2081 11.0922 13.7143 11.5517C13.5354 11.7181 13.446 11.8013 13.4126 11.8658C13.3774 11.9337 13.3672 11.9737 13.3656 12.0501C13.364 12.1227 13.3936 12.2115 13.4528 12.3891L14.2225 14.6983C14.322 14.9966 14.3717 15.1458 14.3419 15.2645C14.3158 15.3684 14.2509 15.4584 14.1606 15.516C14.0574 15.5818 13.9002 15.5818 13.5858 15.5818H10.4142C10.0998 15.5818 9.94255 15.5818 9.83936 15.516C9.74903 15.4584 9.68416 15.3684 9.65807 15.2645C9.62826 15.1458 9.67797 14.9966 9.7774 14.6983L10.5472 12.3891C10.6063 12.2115 10.6359 12.1227 10.6344 12.0501C10.6328 11.9737 10.6226 11.9337 10.5874 11.8658C10.5539 11.8013 10.4645 11.7181 10.2857 11.5517C9.79182 11.0922 9.48291 10.4365 9.48291 9.70865C9.48291 8.31852 10.6098 7.19159 12 7.19159C13.3901 7.19159 14.517 8.31852 14.517 9.70865Z" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg>
\ No newline at end of file
diff --git a/assets/icons/facebook.svg b/assets/icons/facebook.svg
new file mode 100644
index 000000000000..e3e31d89316d
--- /dev/null
+++ b/assets/icons/facebook.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0_230_146" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="2" y="2" width="20" height="20">
+<path d="M18 2C20.2091 2 22 3.79086 22 6V18C22 20.2091 20.2091 22 18 22H6C3.79086 22 2 20.2091 2 18V6C2 3.79086 3.79086 2 6 2H18ZM13.625 4.85742C11.5908 4.85753 10.2617 6.09028 10.2617 8.32227V10.2842H8V12.8584H10.2617V19.082C10.715 19.1532 11.18 19.1904 11.6533 19.1904C12.1264 19.1904 12.5908 19.1531 13.0439 19.082V12.8584H15.1191L15.5146 10.2842H13.0439V8.61328C13.0441 7.9091 13.39 7.22266 14.4961 7.22266H15.6191V5.03125C15.6191 5.03125 14.5994 4.85742 13.625 4.85742Z" fill="#6C7E9D"/>
+</mask>
+<g mask="url(#mask0_230_146)">
+<rect width="24" height="24" fill="#4B83F1"/>
+</g>
+</svg>
diff --git a/static/assets/icons/go.svg b/assets/icons/go.svg
similarity index 100%
rename from static/assets/icons/go.svg
rename to assets/icons/go.svg
diff --git a/assets/icons/gordon-happy.svg b/assets/icons/gordon-happy.svg
new file mode 100644
index 000000000000..072740635b66
--- /dev/null
+++ b/assets/icons/gordon-happy.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path fill-rule="evenodd" clip-rule="evenodd" d="M9.45806 6.98145C11.5069 6.88872 13.4159 6.87248 15.4336 6.94824C16.455 6.9866 16.8836 7.00573 17.3682 7.11914C19.2852 7.56782 20.9855 9.33327 21.3624 11.2656C21.4571 11.7521 21.46 12.2718 21.46 13.4941C21.46 14.9264 21.4566 15.5405 21.3575 16.0371C20.9383 18.1365 19.2977 19.7781 17.1983 20.1973C16.7016 20.2964 16.0878 20.2998 14.6553 20.2998H10.0811C8.71799 20.2998 8.13354 20.2968 7.66021 20.207C5.52066 19.801 3.84742 18.1268 3.44146 15.9873C3.35176 15.5141 3.34869 14.9297 3.34869 13.5674C3.34869 12.3454 3.35173 11.824 3.43658 11.3633C3.80589 9.3592 5.46871 7.61849 7.45415 7.15918C7.91165 7.0534 8.37143 7.03063 9.45806 6.98145ZM17.3516 8.40332C14.4842 7.70661 11.4527 7.75081 8.43853 8.29297C7.43795 8.47297 6.93663 8.56368 6.43755 8.88184C6.0328 9.14005 5.61786 9.59152 5.39458 10.0166C5.01948 10.7313 5.01331 11.6205 4.94439 12.4062C4.80742 13.8649 4.73843 14.595 4.97271 15.0908C5.1886 15.5473 5.5117 15.8616 5.97369 16.0654C6.4755 16.2867 7.25812 16.1923 8.82232 16.0039C11.6796 15.6597 13.9776 15.7223 16.5342 16.0283C17.8763 16.189 18.5479 16.269 19.0274 16.0732C19.4599 15.8964 19.7926 15.6018 20.0196 15.1934C20.2708 14.7405 20.2715 14.0947 20.2715 12.8057C20.2715 11.9806 20.3631 11.0803 20.0352 10.3037C19.8562 9.88029 19.4279 9.33546 19.0586 9.06152C18.5706 8.69964 18.1638 8.60067 17.3516 8.40332Z" fill="currentColor"/>
+<path d="M2.86333 10.7393C2.79805 10.9707 2.7531 11.2053 2.7149 11.4424C2.64844 11.9339 2.64849 12.5225 2.64849 13.5674L2.65044 14.4492C2.65537 15.2237 2.67513 15.7025 2.75396 16.1182C2.82942 16.4813 2.92441 16.8374 3.05962 17.1836C3.05835 17.1803 3.05698 17.1771 3.05572 17.1738C1.93813 17.1766 1.02699 16.2761 1.01861 15.1572L1.00005 12.6875C0.992369 11.6362 1.8232 10.7782 2.86333 10.7393Z" fill="currentColor"/>
+<path d="M21.8536 10.4102C23.1521 10.6254 24.0736 11.8198 23.9278 13.1475L23.7588 14.6836C23.6379 15.7836 22.8507 16.646 21.8438 16.9199C21.9017 16.7485 21.9536 16.5736 21.9961 16.3955C22.1373 15.7443 22.1538 15.0859 22.1583 14.4209L22.1602 13.4941C22.1602 12.2987 22.1605 11.7 22.0499 11.1318C22.0023 10.8879 21.9358 10.6469 21.8536 10.4102Z" fill="currentColor"/>
+<path d="M13.5411 6.2041C13.2066 6.20089 12.873 6.20049 12.5391 6.20215C12.5873 5.59323 12.6651 5.08294 12.7676 4.63965C12.1906 4.29963 11.8018 3.67326 11.8018 2.95508C11.8021 1.87531 12.678 1.00005 13.7579 1C14.8377 1.00001 15.7127 1.87528 15.7129 2.95508C15.7129 4.04353 14.8176 4.92299 13.7325 4.90918C13.6498 5.27685 13.5841 5.70041 13.5411 6.2041Z" fill="currentColor"/>
+<path d="M8 12C8.33333 11.3334 9.5 11 10.5 12" stroke="currentColor" stroke-linecap="round"/>
+<path d="M16.5 12C16.1667 11.3334 15 11 14 12" stroke="currentColor" stroke-linecap="round"/>
+</svg>
diff --git a/assets/icons/gordon.svg b/assets/icons/gordon.svg
new file mode 100644
index 000000000000..91442d6a36a5
--- /dev/null
+++ b/assets/icons/gordon.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+  <path d="M15.1329 9.83887C16.0755 9.95803 16.7429 10.8191 16.6241 11.7617L16.4786 12.915C16.3541 13.8995 15.5254 14.689 14.5411 14.5635C13.5522 14.4372 12.9407 13.4627 13.0655 12.4736L13.21 11.3311C13.3291 10.3882 14.19 9.71983 15.1329 9.83887Z" fill="currentColor"/>
+  <path d="M8.7813 9.75293C9.72891 9.82425 10.4393 10.6501 10.3682 11.5977L10.2784 12.7939C10.2035 13.7885 9.41068 14.6231 8.41607 14.5498C7.42582 14.4766 6.77123 13.5361 6.84576 12.5459L6.93658 11.3398C7.0079 10.3922 7.83369 9.68175 8.7813 9.75293Z" fill="currentColor"/>
+  <path d="M9.45806 6.98145C11.5069 6.88872 13.4159 6.87248 15.4336 6.94824C16.455 6.9866 16.8836 7.00573 17.3682 7.11914C19.2852 7.56782 20.9855 9.33327 21.3624 11.2656C21.4571 11.7521 21.46 12.2718 21.46 13.4941C21.46 14.9264 21.4566 15.5405 21.3575 16.0371C20.9383 18.1365 19.2977 19.7781 17.1983 20.1973C16.7016 20.2964 16.0878 20.2998 14.6553 20.2998H10.0811C8.71799 20.2998 8.13354 20.2968 7.66021 20.207C5.52066 19.801 3.84742 18.1268 3.44146 15.9873C3.35176 15.5141 3.34869 14.9297 3.34869 13.5674C3.34869 12.3454 3.35173 11.824 3.43658 11.3633C3.80589 9.3592 5.46871 7.61849 7.45415 7.15918C7.91165 7.0534 8.37143 7.03063 9.45806 6.98145ZM17.3516 8.40332C14.4842 7.70661 11.4527 7.75081 8.43853 8.29297C7.43795 8.47297 6.93663 8.56368 6.43755 8.88184C6.0328 9.14005 5.61786 9.59152 5.39458 10.0166C5.01948 10.7313 5.01331 11.6205 4.94439 12.4062C4.80742 13.8649 4.73843 14.595 4.97271 15.0908C5.1886 15.5473 5.5117 15.8616 5.97369 16.0654C6.4755 16.2867 7.25812 16.1923 8.82232 16.0039C11.6796 15.6597 13.9776 15.7223 16.5342 16.0283C17.8763 16.189 18.5479 16.269 19.0274 16.0732C19.4599 15.8964 19.7926 15.6018 20.0196 15.1934C20.2708 14.7405 20.2715 14.0947 20.2715 12.8057C20.2715 11.9806 20.3631 11.0803 20.0352 10.3037C19.8562 9.88029 19.4279 9.33546 19.0586 9.06152C18.5706 8.69964 18.1638 8.60067 17.3516 8.40332Z" fill="currentColor"/>
+  <path d="M2.86333 10.7393C2.79805 10.9707 2.7531 11.2053 2.7149 11.4424C2.64844 11.9339 2.64849 12.5225 2.64849 13.5674L2.65044 14.4492C2.65537 15.2237 2.67513 15.7025 2.75396 16.1182C2.82942 16.4813 2.92441 16.8374 3.05962 17.1836C3.05835 17.1803 3.05698 17.1771 3.05572 17.1738C1.93813 17.1766 1.02699 16.2761 1.01861 15.1572L1.00005 12.6875C0.992369 11.6362 1.8232 10.7782 2.86333 10.7393Z" fill="currentColor"/>
+  <path d="M21.8536 10.4102C23.1521 10.6254 24.0736 11.8198 23.9278 13.1475L23.7588 14.6836C23.6379 15.7836 22.8507 16.646 21.8438 16.9199C21.9017 16.7485 21.9536 16.5736 21.9961 16.3955C22.1373 15.7443 22.1538 15.0859 22.1583 14.4209L22.1602 13.4941C22.1602 12.2987 22.1605 11.7 22.0499 11.1318C22.0023 10.8879 21.9358 10.6469 21.8536 10.4102Z" fill="currentColor"/>
+  <path d="M13.5411 6.2041C13.2066 6.20089 12.873 6.20049 12.5391 6.20215C12.5873 5.59323 12.6651 5.08294 12.7676 4.63965C12.1906 4.29963 11.8018 3.67326 11.8018 2.95508C11.8021 1.87531 12.678 1.00005 13.7579 1C14.8377 1.00001 15.7127 1.87528 15.7129 2.95508C15.7129 4.04353 14.8176 4.92299 13.7325 4.90918C13.6498 5.27685 13.5841 5.70041 13.5411 6.2041Z" fill="currentColor"/>
+</svg>
diff --git a/assets/icons/headset.svg b/assets/icons/headset.svg
new file mode 100644
index 000000000000..700d4c546086
--- /dev/null
+++ b/assets/icons/headset.svg
@@ -0,0 +1,3 @@
+<svg width="10" height="12" viewBox="0 0 10 12" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path stroke="currentColor" stroke-width="0.5"  d="M8.55237 2.00563C8.09228 1.53094 7.54504 1.15362 6.94199 0.895266C6.33893 0.636909 5.69191 0.50259 5.03796 0.5H4.99998C3.6739 0.5 2.40214 1.03807 1.46446 1.99585C0.526782 2.95362 0 4.25264 0 5.60714V8.35714C0 8.66972 0.121565 8.96949 0.337953 9.19052C0.55434 9.41154 0.847824 9.53571 1.15384 9.53571H1.92307C2.22909 9.53571 2.52257 9.41154 2.73896 9.19052C2.95535 8.96949 3.07691 8.66972 3.07691 8.35714V6.39286C3.07691 6.08028 2.95535 5.78051 2.73896 5.55948C2.52257 5.33846 2.22909 5.21429 1.92307 5.21429H0.786536C0.86071 4.39515 1.16194 3.61457 1.65491 2.96405C2.14788 2.31353 2.81218 1.82002 3.56994 1.54135C4.3277 1.26268 5.14752 1.21041 5.93333 1.39066C6.71913 1.57091 7.43835 1.97621 8.0067 2.55906C8.70136 3.27225 9.12864 4.21204 9.21391 5.21429H8.07689C7.77088 5.21429 7.47739 5.33846 7.261 5.55948C7.04462 5.78051 6.92305 6.08028 6.92305 6.39286V8.35714C6.92305 8.66972 7.04462 8.96949 7.261 9.19052C7.47739 9.41154 7.77088 9.53571 8.07689 9.53571H9.23074C9.23074 9.84829 9.10917 10.1481 8.89278 10.3691C8.6764 10.5901 8.38291 10.7143 8.07689 10.7143H5.3846C5.28259 10.7143 5.18476 10.7557 5.11263 10.8294C5.0405 10.903 4.99998 11.003 4.99998 11.1071C4.99998 11.2113 5.0405 11.3113 5.11263 11.3849C5.18476 11.4586 5.28259 11.5 5.3846 11.5H8.07689C8.58692 11.5 9.07606 11.293 9.43671 10.9247C9.79736 10.5563 9.99996 10.0567 9.99996 9.53571V5.60714C10.0025 4.93908 9.87589 4.27707 9.62749 3.65906C9.37908 3.04104 9.01373 2.47917 8.55237 2.00563ZM1.92307 6C2.02508 6 2.1229 6.04139 2.19503 6.11506C2.26716 6.18874 2.30768 6.28866 2.30768 6.39286V8.35714C2.30768 8.46133 2.26716 8.56126 2.19503 8.63494C2.1229 8.70861 2.02508 8.75 1.92307 8.75H1.15384C1.05184 8.75 0.954008 8.70861 0.881879 8.63494C0.80975 8.56126 0.769228 8.46133 0.769228 8.35714V6H1.92307ZM8.07689 8.75C7.97489 8.75 7.87706 8.70861 7.80493 8.63494C7.7328 8.56126 7.69228 8.46133 7.69228 8.35714V6.39286C7.69228 6.28866 7.7328 6.18874 7.80493 6.11506C7.87706 6.04139 7.97489 6 8.07689 6H9.23074V8.75H8.07689Z"/>
+</svg>
diff --git a/assets/icons/instagram.svg b/assets/icons/instagram.svg
new file mode 100644
index 000000000000..d0acf82f83c5
--- /dev/null
+++ b/assets/icons/instagram.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0_230_156" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="2" y="2" width="20" height="20">
+<path fill-rule="evenodd" clip-rule="evenodd" d="M6 2C3.79086 2 2 3.79086 2 6V18C2 20.2091 3.79086 22 6 22H18C20.2091 22 22 20.2091 22 18V6C22 3.79086 20.2091 2 18 2H6ZM7.82824 6.03828C8.21814 5.8855 8.66433 5.78086 9.31759 5.75002C9.97247 5.7186 10.1815 5.71145 11.8485 5.70826C13.5159 5.70508 13.725 5.71144 14.3798 5.7405C15.0333 5.76874 15.4797 5.87179 15.8704 6.02297C16.2746 6.17873 16.6175 6.3884 16.9593 6.72877C17.3011 7.06953 17.5115 7.41129 17.6693 7.81491C17.8218 8.20521 17.9265 8.65101 17.9575 9.30467C17.9885 9.95935 17.9961 10.1682 17.9993 11.8354C18.0025 13.5024 17.9957 13.7117 17.9671 14.367C17.9386 15.0201 17.8358 15.4666 17.6846 15.8572C17.5284 16.2614 17.3192 16.6043 16.9788 16.9461C16.6384 17.288 16.2963 17.4983 15.8927 17.6563C15.5024 17.8086 15.0566 17.9133 14.4033 17.9445C13.7485 17.9755 13.5394 17.9829 11.8718 17.9861C10.205 17.9893 9.99592 17.9829 9.34107 17.954C8.6876 17.9254 8.241 17.8226 7.85052 17.6716C7.4463 17.5152 7.10336 17.3061 6.76161 16.9656C6.41965 16.625 6.209 16.283 6.05146 15.8794C5.89868 15.4893 5.79443 15.0433 5.7632 14.3903C5.73198 13.7352 5.72462 13.5259 5.72144 11.8589C5.71825 10.1917 5.72482 9.98282 5.75345 9.32794C5.78231 8.67426 5.88475 8.22786 6.03594 7.83697C6.19209 7.43295 6.40137 7.0902 6.74212 6.74824C7.08248 6.40649 7.42461 6.19563 7.82824 6.03828ZM8.24897 16.6401C8.4656 16.7235 8.79065 16.8229 9.38922 16.849C10.0369 16.877 10.2309 16.8832 11.8698 16.88C13.5093 16.877 13.7033 16.8701 14.3508 16.8396C14.9488 16.8112 15.2738 16.7105 15.4898 16.6262C15.7765 16.5142 15.9806 16.3803 16.195 16.1657C16.4095 15.9502 16.5422 15.7455 16.6532 15.4589C16.7367 15.2421 16.836 14.9168 16.862 14.3182C16.8905 13.6709 16.8964 13.4768 16.8932 11.8374C16.8903 10.1985 16.8833 10.0043 16.8525 9.35679C16.8242 8.75862 16.7238 8.43356 16.6392 8.21773C16.5272 7.93069 16.3938 7.72698 16.1785 7.51233C15.9633 7.29769 15.7586 7.16541 15.4715 7.0544C15.2553 6.97066 14.9299 6.87159 14.3317 6.84553C13.684 6.81708 13.4898 6.81131 11.8505 6.8145C10.2116 6.81768 10.0176 6.82425 9.37011 6.85489C8.77175 6.88333 8.4471 6.98379 8.23068 7.06834C7.94421 7.18033 7.74012 7.31341 7.52548 7.52885C7.31123 7.74429 7.17856 7.94858 7.06756 8.23584C6.98441 8.45228 6.88435 8.77772 6.85869 9.37589C6.83043 10.0236 6.82448 10.2178 6.82764 11.8567C6.83064 13.4961 6.83759 13.6902 6.86804 14.3373C6.89609 14.9359 6.99733 15.2606 7.08148 15.4772C7.19348 15.7634 7.32696 15.9676 7.54199 16.1822C7.75743 16.396 7.96213 16.5291 8.24897 16.6401ZM15.1324 9.30031C14.7258 9.3011 14.3952 8.97188 14.3944 8.56527C14.3936 8.15867 14.7228 7.82804 15.1296 7.82725C15.5364 7.82645 15.867 8.15587 15.8678 8.56247C15.8684 8.96909 15.5392 9.29951 15.1324 9.30031ZM11.8662 14.9994C10.1254 15.0027 8.71128 13.5943 8.7079 11.8531C8.70451 10.1123 10.1133 8.69794 11.8541 8.69455C13.5953 8.69117 15.0096 10.1004 15.013 11.841C15.0164 13.5822 13.6072 14.996 11.8662 14.9994ZM11.8563 9.80079C10.7264 9.80278 9.81172 10.7208 9.81371 11.8509C9.8159 12.9812 10.7341 13.8957 11.864 13.8935C12.9943 13.8913 13.909 12.9735 13.9068 11.8432C13.9046 10.7129 12.9864 9.7986 11.8563 9.80079Z" fill="#6C7E9D"/>
+</mask>
+<g mask="url(#mask0_230_156)">
+<rect width="24" height="24" fill="#4B83F1"/>
+</g>
+</svg>
diff --git a/static/assets/icons/java.svg b/assets/icons/java.svg
similarity index 100%
rename from static/assets/icons/java.svg
rename to assets/icons/java.svg
diff --git a/assets/icons/linkedin.svg b/assets/icons/linkedin.svg
new file mode 100644
index 000000000000..997fa8bb51fc
--- /dev/null
+++ b/assets/icons/linkedin.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0_230_168" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="2" y="2" width="20" height="20">
+<path d="M18 2C20.2091 2 22 3.79086 22 6V18C22 20.2091 20.2091 22 18 22H6C3.79086 22 2 20.2091 2 18V6C2 3.79086 3.79086 2 6 2H18ZM15.0762 8.78418C13.7764 8.78418 12.9253 9.62482 12.6807 10.1172H12.6494V9.00879H10.2266V17.0137H12.7461V12.6738C12.7461 11.5169 13.4782 10.9531 14.2266 10.9531C14.9329 10.9532 15.4823 11.3514 15.4824 12.6406V17.0137H18.001V12.0625C18.001 9.61838 16.4821 8.7842 15.0762 8.78418ZM6.19238 9.00293V17.0068H8.71191V9.00293H6.19238ZM7.45215 5C6.65026 5.00021 6.00023 5.64761 6 6.44629C6 7.24516 6.65011 7.89335 7.45215 7.89355C8.25436 7.89355 8.90527 7.24529 8.90527 6.44629C8.90504 5.64749 8.25422 5 7.45215 5Z" fill="#6C7E9D"/>
+</mask>
+<g mask="url(#mask0_230_168)">
+<rect width="24" height="24" fill="#4B83F1"/>
+</g>
+</svg>
diff --git a/static/assets/images/logo-build-cloud.svg b/assets/icons/logo-build-cloud.svg
similarity index 100%
rename from static/assets/images/logo-build-cloud.svg
rename to assets/icons/logo-build-cloud.svg
diff --git a/assets/icons/models.svg b/assets/icons/models.svg
new file mode 100644
index 000000000000..581f3621afb2
--- /dev/null
+++ b/assets/icons/models.svg
@@ -0,0 +1,3 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path d="M12.3789 1.38416L12.5771 1.41443L12.6992 1.4447C12.9805 1.52555 13.2292 1.67314 13.4209 1.77966L20.6152 5.77673C20.8173 5.88899 21.0876 6.02945 21.3135 6.23767L21.4072 6.33142L21.541 6.49255C21.6242 6.6047 21.6952 6.72575 21.7529 6.85291L21.8301 7.04919L21.8662 7.17615C21.9179 7.38938 21.9281 7.60588 21.9297 7.79626V16.1166C21.9278 16.3451 21.9137 16.6114 21.8301 16.8646C21.742 17.1311 21.5974 17.376 21.4072 17.5824C21.1664 17.8436 20.8461 18.0078 20.6152 18.1361L13.4209 22.1332C13.2019 22.2549 12.9087 22.4302 12.5771 22.4984C12.3151 22.5523 12.0443 22.5523 11.7822 22.4984C11.4507 22.4302 11.1575 22.2549 10.9385 22.1332L3.74414 18.1361C3.51314 18.0078 3.19206 17.8438 2.95117 17.5824C2.76113 17.3761 2.61736 17.1309 2.5293 16.8646C2.44572 16.6115 2.43154 16.345 2.42969 16.1166V7.79626C2.43155 7.5679 2.44578 7.30219 2.5293 7.04919L2.60547 6.85291C2.69195 6.66223 2.80873 6.48608 2.95117 6.33142L3.04492 6.23767C3.27093 6.02909 3.54188 5.8891 3.74414 5.77673L10.9385 1.77966C11.1575 1.65796 11.4507 1.48266 11.7822 1.41443L11.9805 1.38416C12.1128 1.37073 12.2465 1.37073 12.3789 1.38416ZM11.9102 3.52869L4.71582 7.52478C4.56631 7.60784 4.48715 7.65162 4.43262 7.68591C4.42916 7.75018 4.42969 7.84066 4.42969 8.01111V15.9017C4.42969 16.0712 4.42922 16.1617 4.43262 16.226C4.48715 16.2603 4.56602 16.3048 4.71582 16.3881L11.9102 20.3851C12.0498 20.4627 12.1244 20.503 12.1787 20.5297C12.2332 20.503 12.3081 20.4635 12.4492 20.3851L19.6436 16.3881C19.7924 16.3053 19.8703 16.2602 19.9248 16.226C19.9282 16.1617 19.9297 16.0713 19.9297 15.9017V8.01111C19.9297 7.84058 19.9283 7.75018 19.9248 7.68591C19.8703 7.65175 19.7918 7.60713 19.6436 7.52478L12.4492 3.52869C12.3077 3.45007 12.2332 3.40889 12.1787 3.3822C12.1243 3.40891 12.0506 3.45068 11.9102 3.52869ZM12.0898 6.46912C12.4686 6.46912 12.8159 6.6831 12.9854 7.02185L13.7852 8.62048C14.0726 9.19534 14.1606 9.36327 14.2686 9.5033C14.3763 9.64312 14.5018 9.76853 14.6416 9.87634C14.7816 9.98425 14.9496 10.0733 15.5244 10.3607L17.123 11.1595C17.4617 11.3289 17.6757 11.6755 17.6758 12.0541C17.6758 12.4328 17.4617 12.7792 17.123 12.9486L15.5244 13.7484C14.95 14.0356 14.7816 14.124 14.6416 14.2318C14.5018 14.3396 14.3763 14.4651 14.2686 14.6049C14.1606 14.7449 14.0724 14.9131 13.7852 15.4877L12.9854 17.0863C12.816 17.425 12.4695 17.6389 12.0908 17.639H12.0898C11.9007 17.6389 11.7195 17.5853 11.5645 17.4896C11.5236 17.4644 11.4851 17.4356 11.4482 17.4047C11.3449 17.3182 11.2577 17.2111 11.1953 17.0863L10.3965 15.4877C10.2527 15.2001 10.1586 15.0145 10.0869 14.8832C10.0153 14.7519 9.96606 14.6748 9.91211 14.6049C9.80434 14.4652 9.67881 14.3395 9.53906 14.2318C9.39914 14.1241 9.2304 14.0355 8.65625 13.7484L7.05762 12.9486C6.97289 12.9062 6.89582 12.8527 6.82812 12.7904C6.76049 12.7282 6.7022 12.657 6.6543 12.5795C6.55871 12.4245 6.50488 12.2432 6.50488 12.0541C6.50489 12.0066 6.5081 11.9596 6.51465 11.9135C6.54733 11.6836 6.65918 11.4732 6.82812 11.3177C6.89582 11.2554 6.9729 11.202 7.05762 11.1595L8.65625 10.3607C9.0871 10.1453 9.28956 10.0414 9.42285 9.9574C9.46737 9.92934 9.50401 9.90334 9.53906 9.87634C9.67886 9.76856 9.80432 9.64308 9.91211 9.5033C9.96608 9.43328 10.0153 9.35629 10.0869 9.22498C10.1586 9.09367 10.2527 8.90803 10.3965 8.62048L11.1953 7.02185L11.2666 6.90076C11.359 6.76687 11.4818 6.65875 11.623 6.58435C11.6583 6.56574 11.6951 6.54984 11.7324 6.53552C11.8073 6.50689 11.8859 6.48698 11.9668 6.47693C12.0073 6.47189 12.0484 6.46915 12.0898 6.46912Z" fill="currentColor"/>
+</svg>
diff --git a/assets/icons/moon.svg b/assets/icons/moon.svg
new file mode 100644
index 000000000000..0bc248ff5148
--- /dev/null
+++ b/assets/icons/moon.svg
@@ -0,0 +1,8 @@
+<svg width="1em" height="1em" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+  <!-- moon icon using path, stroke currentColor -->
+  <path d="M22 15.8442C20.6866 16.4382 19.2286 16.7688 17.6935 16.7688C11.9153 16.7688 7.23116 12.0847 7.23116 6.30654C7.23116 4.77135 7.5618 3.3134 8.15577 2C4.52576 3.64163 2 7.2947 2 11.5377C2 17.3159 6.68414 22 12.4623 22C16.7053 22 20.3584 19.4742 22 15.8442Z"
+    stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" fill="none"/>
+</svg>
+<rect width="24" height="24" fill="currentColor" fill-opacity="1"/>
+</g>
+</svg>
diff --git a/assets/icons/openai.svg b/assets/icons/openai.svg
new file mode 100644
index 000000000000..50d94d6c1085
--- /dev/null
+++ b/assets/icons/openai.svg
@@ -0,0 +1 @@
+<svg fill="currentColor" fill-rule="evenodd" height="1em" style="flex:none;line-height:1" viewBox="0 0 24 24" width="1em" xmlns="http://www.w3.org/2000/svg"><title>OpenAI</title><path d="M21.55 10.004a5.416 5.416 0 00-.478-4.501c-1.217-2.09-3.662-3.166-6.05-2.66A5.59 5.59 0 0010.831 1C8.39.995 6.224 2.546 5.473 4.838A5.553 5.553 0 001.76 7.496a5.487 5.487 0 00.691 6.5 5.416 5.416 0 00.477 4.502c1.217 2.09 3.662 3.165 6.05 2.66A5.586 5.586 0 0013.168 23c2.443.006 4.61-1.546 5.361-3.84a5.553 5.553 0 003.715-2.66 5.488 5.488 0 00-.693-6.497v.001zm-8.381 11.558a4.199 4.199 0 01-2.675-.954c.034-.018.093-.05.132-.074l4.44-2.53a.71.71 0 00.364-.623v-6.176l1.877 1.069c.02.01.033.029.036.05v5.115c-.003 2.274-1.87 4.118-4.174 4.123zM4.192 17.78a4.059 4.059 0 01-.498-2.763c.032.02.09.055.131.078l4.44 2.53c.225.13.504.13.73 0l5.42-3.088v2.138a.068.068 0 01-.027.057L9.9 19.288c-1.999 1.136-4.552.46-5.707-1.51h-.001zM3.023 8.216A4.15 4.15 0 015.198 6.41l-.002.151v5.06a.711.711 0 00.364.624l5.42 3.087-1.876 1.07a.067.067 0 01-.063.005l-4.489-2.559c-1.995-1.14-2.679-3.658-1.53-5.63h.001zm15.417 3.54l-5.42-3.088L14.896 7.6a.067.067 0 01.063-.006l4.489 2.557c1.998 1.14 2.683 3.662 1.529 5.633a4.163 4.163 0 01-2.174 1.807V12.38a.71.71 0 00-.363-.623zm1.867-2.773a6.04 6.04 0 00-.132-.078l-4.44-2.53a.731.731 0 00-.729 0l-5.42 3.088V7.325a.068.068 0 01.027-.057L14.1 4.713c2-1.137 4.555-.46 5.707 1.513.487.833.664 1.809.499 2.757h.001zm-11.741 3.81l-1.877-1.068a.065.065 0 01-.036-.051V6.559c.001-2.277 1.873-4.122 4.181-4.12.976 0 1.92.338 2.671.954-.034.018-.092.05-.131.073l-4.44 2.53a.71.71 0 00-.365.623l-.003 6.173v.002zm1.02-2.168L12 9.25l2.414 1.375v2.75L12 14.75l-2.415-1.375v-2.75z"></path></svg>
\ No newline at end of file
diff --git a/assets/icons/sun.svg b/assets/icons/sun.svg
new file mode 100644
index 000000000000..5eb18a1d1d7b
--- /dev/null
+++ b/assets/icons/sun.svg
@@ -0,0 +1,8 @@
+<svg width="1em" height="1em" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+  <!-- sun icon using path, stroke currentColor -->
+  <path d="M12 2V4M12 20V22M4 12H2M6.31412 6.31412L4.8999 4.8999M17.6859 6.31412L19.1001 4.8999M6.31412 17.69L4.8999 19.1042M17.6859 17.69L19.1001 19.1042M22 12H20M17 12C17 14.7614 14.7614 17 12 17C9.23858 17 7 14.7614 7 12C7 9.23858 9.23858 7 12 7C14.7614 7 17 9.23858 17 12Z"
+    stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" fill="none"/>
+</svg>
+<rect width="24" height="24" fill="currentColor" fill-opacity="1"/>
+</g>
+</svg>
diff --git a/assets/icons/system.svg b/assets/icons/system.svg
new file mode 100644
index 000000000000..d25f42526783
--- /dev/null
+++ b/assets/icons/system.svg
@@ -0,0 +1,4 @@
+<svg viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+  <path fill="none" d="M19 17.4598C17.8179 17.9944 16.5058 18.292 15.1241 18.292C9.92376 18.292 5.70804 14.0762 5.70804 8.87588C5.70804 7.49422 6.00562 6.18206 6.5402 5C3.27319 6.47747 1 9.76523 1 13.5839C1 18.7843 5.21572 23 10.4161 23C14.2348 23 17.5225 20.7268 19 17.4598Z" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
+  <path fill="none" d="M19.4888 4.61889L18.1877 5.91996M12.9834 3.7265L12.9834 1.8865M20.3809 11.124L22.2209 11.124M9.73068 7.87158C11.5271 6.07516 14.4397 6.07516 16.2361 7.87158C18.0325 9.66799 18.0325 12.5805 16.2361 14.377" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
diff --git a/assets/icons/toolkit.svg b/assets/icons/toolkit.svg
new file mode 100644
index 000000000000..ef4c016dc5c0
--- /dev/null
+++ b/assets/icons/toolkit.svg
@@ -0,0 +1,7 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path d="M14.1604 16.8125C14.3454 16.4613 14.8724 16.4613 15.0575 16.8125C15.1827 17.0508 15.2459 17.1704 15.3296 17.2737C15.4038 17.3652 15.49 17.4472 15.5863 17.5178C15.6948 17.5974 15.8201 17.6576 16.0707 17.7768C16.4403 17.9527 16.4403 18.454 16.0707 18.6299C15.8201 18.7491 15.6948 18.8093 15.5863 18.8889C15.49 18.9595 15.4038 19.0415 15.3296 19.133C15.2459 19.2363 15.1827 19.3551 15.0575 19.5933C14.8725 19.9451 14.3453 19.9451 14.1604 19.5933C14.0351 19.3551 13.9719 19.2363 13.8882 19.133C13.814 19.0415 13.7278 18.9595 13.6315 18.8889C13.523 18.8093 13.3977 18.7491 13.1471 18.6299C12.7774 18.454 12.7775 17.9527 13.1471 17.7768C13.3977 17.6576 13.523 17.5974 13.6315 17.5178C13.7278 17.4472 13.814 17.3652 13.8882 17.2737C13.9719 17.1704 14.0351 17.0508 14.1604 16.8125Z" fill="currentColor"/>
+<path fill-rule="evenodd" clip-rule="evenodd" d="M5.93855 11.9528C6.18684 11.7089 6.58915 11.7089 6.83747 11.9528L9.10245 14.1805C9.34736 14.4214 9.34724 14.8242 9.10245 15.0652L5.7662 18.3473L5.60021 18.496C4.7982 19.1516 3.64836 19.2319 2.82725 18.5792L2.65672 18.4278C1.83844 17.6224 1.78233 16.2321 2.50252 15.3495L2.65672 15.1807L5.93855 11.9528ZM3.85044 16.3094C3.61193 16.544 3.61271 17.0649 3.85044 17.299L3.9221 17.3568C3.99403 17.404 4.06853 17.4204 4.14887 17.4172C4.27136 17.4121 4.4317 17.3561 4.57248 17.2177L7.21028 14.6224L6.38755 13.8139L3.85044 16.3094Z" fill="currentColor"/>
+<path d="M18.508 14.7449C18.693 14.3936 19.22 14.3936 19.4051 14.7449C19.5304 14.9832 19.5936 15.1028 19.6772 15.206C19.7514 15.2976 19.8377 15.3796 19.9339 15.4502C20.0425 15.5297 20.168 15.5892 20.4183 15.7083C20.7882 15.8842 20.7882 16.3864 20.4183 16.5623C20.1679 16.6814 20.0425 16.7409 19.9339 16.8204C19.8376 16.891 19.7515 16.9738 19.6772 17.0654C19.5936 17.1686 19.5303 17.2875 19.4051 17.5257C19.2202 17.8774 18.6929 17.8774 18.508 17.5257C18.3828 17.2874 18.3195 17.1686 18.2359 17.0654C18.1616 16.9738 18.0755 16.891 17.9792 16.8204C17.8707 16.7409 17.7451 16.6813 17.4948 16.5623C17.1251 16.3863 17.125 15.8841 17.4948 15.7083C17.7453 15.5891 17.8706 15.5297 17.9792 15.4502C18.0754 15.3796 18.1617 15.2976 18.2359 15.206C18.3196 15.1028 18.3827 14.9832 18.508 14.7449Z" fill="currentColor"/>
+<path fill-rule="evenodd" clip-rule="evenodd" d="M7.53683 4.30615C8.19308 4.17877 8.90012 4.10059 9.56507 4.16702C10.2334 4.23384 10.9066 4.45295 11.4264 4.96415L14.4461 7.93477C14.7509 8.23479 14.5896 8.6711 14.5241 9.03377C14.9209 9.07759 15.5454 9.01593 15.853 9.31815L17.4658 10.9045C17.6126 11.049 17.6788 11.2555 17.6426 11.4567L17.4249 12.6607L17.4005 12.7534C17.3693 12.8432 17.3177 12.9254 17.249 12.9932L15.3269 14.884L15.2534 14.9462C15.1753 15.0024 15.0847 15.0405 14.9885 15.0573L13.7649 15.2708L13.6878 15.2795C13.5343 15.2877 13.3826 15.2414 13.2614 15.1483L13.2034 15.0975L11.5897 13.5103C11.4029 13.3261 11.4006 13.0743 11.3729 12.8322L10.9012 13.2959C10.6528 13.5399 10.2506 13.54 10.0023 13.2959L7.73729 11.0682C7.43105 10.7667 7.54835 10.3692 7.81893 10.103L7.97041 8.8754L6.9055 8.72577C6.80325 8.71138 6.70638 8.67262 6.6234 8.61377L6.54539 8.54902L4.14343 6.18565C3.79161 5.83906 3.97995 5.22677 4.46817 5.1304C5.3554 4.90181 6.24072 4.59734 7.14678 4.38927L7.53683 4.30615ZM9.39272 5.7709C9.07191 5.73885 8.69879 5.75781 8.2888 5.8164L7.8661 5.88727C7.43972 5.97006 7.00368 6.0878 6.52543 6.2259L7.4942 7.1779L8.2117 7.2794L8.37588 7.3109C9.18373 7.50483 9.73066 8.25226 9.63038 9.06615L9.47889 10.2938C9.47241 10.3462 9.46246 10.3983 9.45077 10.4495L10.4839 11.4663C10.9068 11.2103 11.4341 11.1464 11.9189 11.3079C12.5185 11.5079 12.947 12.0182 13.0292 12.623L14.0107 13.5882L14.3635 13.5269L15.8312 12.0832L15.9056 11.6737L14.8869 10.6709C14.8569 10.6693 14.8222 10.6665 14.7817 10.6648C14.7283 10.6625 14.6555 10.6599 14.5858 10.656L14.3336 10.6359C13.8765 10.5853 13.4609 10.3551 13.1852 9.99978C12.9097 9.64421 12.7979 9.19376 12.8768 8.7564L12.8868 8.7039L10.2327 6.0929C10.0903 5.95302 9.87595 5.84351 9.5433 5.79015L9.39272 5.7709Z" fill="currentColor"/>
+<path d="M18.7184 6.60652C18.9958 6.07886 19.7872 6.07886 20.0646 6.60652C20.2524 6.96391 20.3463 7.14291 20.4718 7.29777C20.5832 7.43517 20.7129 7.55849 20.8573 7.6644C21.0201 7.78372 21.2084 7.87255 21.5839 8.05115C22.1387 8.31498 22.1387 9.06832 21.5839 9.33215C21.2082 9.51082 21.0202 9.6004 20.8573 9.71977C20.7129 9.82568 20.5832 9.94902 20.4718 10.0864C20.3464 10.2412 20.2524 10.4204 20.0646 10.7777C19.7871 11.3049 18.9959 11.3049 18.7184 10.7777C18.5306 10.4204 18.4366 10.2412 18.3112 10.0864C18.1998 9.94903 18.0701 9.82568 17.9257 9.71977C17.7628 9.60041 17.5748 9.51082 17.1991 9.33215C16.6443 9.06832 16.6443 8.31498 17.1991 8.05115C17.5746 7.87254 17.7629 7.78373 17.9257 7.6644C18.0701 7.55848 18.1998 7.43517 18.3112 7.29777C18.4367 7.14291 18.5306 6.96392 18.7184 6.60652Z" fill="currentColor"/>
+</svg>
diff --git a/assets/icons/twitter.svg b/assets/icons/twitter.svg
new file mode 100644
index 000000000000..67893368f732
--- /dev/null
+++ b/assets/icons/twitter.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0_230_151" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="2" y="2" width="20" height="20">
+<path d="M18 2C20.2091 2 22 3.79086 22 6V18C22 20.2091 20.2091 22 18 22H6C3.79086 22 2 20.2091 2 18V6C2 3.79086 3.79086 2 6 2H18ZM10.9209 12.7061L7 17.2637H7.88574L11.3145 13.2783L14.0527 17.2637H17.043L12.9766 11.3457L16.7158 7H15.8301L12.583 10.7734L9.99023 7H7L10.9209 12.7061ZM12.1172 11.3154L12.5146 11.8838L15.8301 16.627H14.4697L11.7637 12.7568L11.3662 12.1885L8.20508 7.66699H9.56641L12.1172 11.3154Z" fill="#6C7E9D"/>
+</mask>
+<g mask="url(#mask0_230_151)">
+<rect width="24" height="24" fill="#4B83F1"/>
+</g>
+</svg>
diff --git a/assets/icons/youtube.svg b/assets/icons/youtube.svg
new file mode 100644
index 000000000000..86a34ce77f0b
--- /dev/null
+++ b/assets/icons/youtube.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0_230_161" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="2" y="2" width="20" height="20">
+<path d="M18 2C20.2091 2 22 3.79086 22 6V18C22 20.2091 20.2091 22 18 22H6C3.79086 22 2 20.2091 2 18V6C2 3.79086 3.79086 2 6 2H18ZM11.9355 7.72754C11.9019 7.72754 8.13938 7.7287 7.19727 7.98242C6.67567 8.12299 6.26429 8.53652 6.125 9.06152C5.87349 10.0064 5.87111 11.9686 5.87109 12C5.87111 12.0315 5.87342 13.9947 6.125 14.9395C6.26446 15.4641 6.67588 15.878 7.19727 16.0186C8.14047 16.2722 11.9019 16.2734 11.9355 16.2734C11.9792 16.2734 15.7348 16.2721 16.6748 16.0186C17.1961 15.8779 17.6077 15.4641 17.7471 14.9395C17.9986 13.9953 18 12.0314 18 12C18 11.9686 17.9985 10.0065 17.7471 9.06152C17.6079 8.5367 17.1961 8.12318 16.6748 7.98242C15.7348 7.72891 11.9792 7.72755 11.9355 7.72754ZM13.8652 12L10.6953 13.8037V10.1973L13.8652 12Z" fill="#6C7E9D"/>
+</mask>
+<g mask="url(#mask0_230_161)">
+<rect width="24" height="24" fill="#4B83F1"/>
+</g>
+</svg>
diff --git a/assets/images/FacebookCircle.svg b/assets/images/FacebookCircle.svg
deleted file mode 100644
index d6ad69f938e4..000000000000
--- a/assets/images/FacebookCircle.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><path fill-rule="evenodd" clip-rule="evenodd" d="M13.54 24c5.948-.736 10.552-5.807 10.552-11.954C24.092 5.393 18.699 0 12.046 0S0 5.393 0 12.046c0 5.842 4.158 10.712 9.677 11.813v-8.374H6.538v-3.573h3.139V9.188c0-3.098 1.845-4.81 4.669-4.81 1.352 0 2.767.242 2.767.242v3.042h-1.559c-1.536 0-2.014.953-2.014 1.93v2.32h3.428l-.548 3.573h-2.88V24Z"/></svg>
\ No newline at end of file
diff --git a/assets/images/InstagramCircle.svg b/assets/images/InstagramCircle.svg
deleted file mode 100644
index 7021c0c0f5ec..000000000000
--- a/assets/images/InstagramCircle.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><path fill-rule="evenodd" clip-rule="evenodd" d="M12 24c6.627 0 12-5.373 12-12S18.627 0 12 0 0 5.373 0 12s5.373 12 12 12ZM6.984 4.774c.485-.19 1.04-.32 1.853-.359.814-.039 1.074-.048 3.148-.052 2.075-.004 2.335.004 3.15.04.812.035 1.368.164 1.853.352.503.193.93.454 1.355.878.425.424.687.849.883 1.35.19.486.32 1.041.359 1.854.038.815.048 1.074.052 3.148.004 2.074-.005 2.335-.04 3.15-.036.812-.164 1.368-.352 1.854a3.737 3.737 0 0 1-.878 1.354 3.746 3.746 0 0 1-1.35.884c-.486.19-1.04.32-1.853.358-.815.039-1.075.048-3.15.052-2.073.004-2.333-.004-3.148-.04-.813-.036-1.369-.163-1.854-.351a3.746 3.746 0 0 1-1.355-.878 3.74 3.74 0 0 1-.883-1.352c-.19-.485-.32-1.04-.359-1.852-.039-.815-.048-1.075-.052-3.15-.004-2.073.004-2.333.04-3.148.036-.813.163-1.368.351-1.855.195-.502.455-.929.879-1.354a3.736 3.736 0 0 1 1.35-.883Zm.523 13.189c.27.103.674.227 1.419.26.806.034 1.047.042 3.086.038 2.04-.004 2.28-.012 3.086-.05.744-.036 1.148-.16 1.417-.266.357-.14.61-.306.877-.573.267-.268.432-.522.57-.879.104-.27.228-.674.26-1.419.035-.805.043-1.047.039-3.086-.004-2.039-.012-2.28-.05-3.086-.036-.744-.16-1.149-.266-1.417a2.366 2.366 0 0 0-.573-.878 2.364 2.364 0 0 0-.88-.57c-.269-.103-.674-.227-1.418-.26-.805-.034-1.047-.042-3.086-.038-2.04.004-2.28.012-3.086.05-.744.036-1.148.16-1.417.266a2.38 2.38 0 0 0-.878.573 2.37 2.37 0 0 0-.57.88c-.103.269-.227.674-.26 1.418-.034.805-.042 1.047-.038 3.086.004 2.04.013 2.28.05 3.086.035.744.161 1.148.266 1.418.14.356.305.61.573.877.268.266.522.431.88.57Zm8.563-9.131a.917.917 0 1 1-.003-1.833.917.917 0 0 1 .003 1.833Zm-4.063 7.09a3.921 3.921 0 1 1-.015-7.843 3.921 3.921 0 0 1 .015 7.842Zm-.012-6.468a2.546 2.546 0 1 0 .01 5.092 2.546 2.546 0 0 0-.01-5.092Z"/></svg>
\ No newline at end of file
diff --git a/assets/images/LinkedinCircle.svg b/assets/images/LinkedinCircle.svg
deleted file mode 100644
index a1d860f7f596..000000000000
--- a/assets/images/LinkedinCircle.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><path fill-rule="evenodd" clip-rule="evenodd" d="M12 24c6.627 0 12-5.373 12-12S18.627 0 12 0 0 5.373 0 12s5.373 12 12 12ZM8.176 9.66H5.174v9.035h3.002V9.66Zm-3.18-2.795c0-.885.671-1.56 1.699-1.56 1.027 0 1.66.675 1.679 1.56 0 .867-.652 1.562-1.7 1.562h-.018c-1.008 0-1.66-.695-1.66-1.562Zm7.845 4.074c.398-.614 1.112-1.49 2.706-1.49 1.976 0 3.457 1.29 3.457 4.065v5.18h-3.002v-4.833c0-1.214-.435-2.043-1.522-2.043-.829 0-1.323.559-1.54 1.098-.08.194-.099.463-.099.733v5.046H9.838s.04-8.187 0-9.035h3.003v1.28Z"/></svg>
\ No newline at end of file
diff --git a/assets/images/TwitterCircle.svg b/assets/images/TwitterCircle.svg
deleted file mode 100644
index 9eac86eefebb..000000000000
--- a/assets/images/TwitterCircle.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 29 29"><g id="Layer_2" data-name="Layer 2"><g id="Layer_1-2" data-name="Layer 1"><path d="M14.62 13.41l-3.3-4.62H9.56l4.09 5.72.51.72 3.51 4.91h1.76l-4.29-6.01-.52-.72z"/><path d="M14.5 0A14.5 14.5 0 1029 14.5 14.5 14.5 0 0014.5 0zm2.63 20.94l-3.55-5.05-4.43 5.05H8l5.07-5.77L8 7.94h3.87l3.36 4.78 4.2-4.78h1.15l-4.84 5.51L21 20.94z"/></g></g></svg>
diff --git a/assets/images/YoutubeCircle.svg b/assets/images/YoutubeCircle.svg
deleted file mode 100644
index 23678de57f95..000000000000
--- a/assets/images/YoutubeCircle.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><path fill-rule="evenodd" clip-rule="evenodd" d="M12 24c6.627 0 12-5.373 12-12S18.627 0 12 0 0 5.373 0 12s5.373 12 12 12Zm7.543-15.79a1.971 1.971 0 0 0-1.392-1.39C16.923 6.49 12 6.49 12 6.49s-4.924 0-6.152.33a1.972 1.972 0 0 0-1.391 1.39c-.33 1.229-.33 3.79-.33 3.79s0 2.562.33 3.79c.18.677.714 1.21 1.391 1.391 1.228.329 6.151.329 6.151.329s4.923 0 6.15-.329a1.972 1.972 0 0 0 1.393-1.392c.329-1.227.329-3.789.329-3.789s0-2.561-.33-3.79Zm-9.117 6.151L14.516 12l-4.09-2.361v4.722Z"/></svg>
\ No newline at end of file
diff --git a/assets/images/ai-stars.svg b/assets/images/ai-stars.svg
deleted file mode 100644
index b7c6a9085c00..000000000000
--- a/assets/images/ai-stars.svg
+++ /dev/null
@@ -1,14 +0,0 @@
-<svg width="16" height="16" viewBox="0 0 24 25" fill="none" xmlns="http://www.w3.org/2000/svg">
-<mask id="mask0_225_286" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="1" y="1" width="22" height="23">
-<path d="M18.5 8.646V3.646M5.5 21.646V16.646M16 6.146H21M3 19.146H8M6.5 2.646L5.71554 4.21491C5.45005 4.74589 5.31731 5.01138 5.13997 5.24144C4.98261 5.44559 4.79959 5.6286 4.59545 5.78597C4.36538 5.9633 4.0999 6.09605 3.56892 6.36154L2 7.146L3.56892 7.93045C4.0999 8.19594 4.36538 8.32869 4.59545 8.50603C4.79959 8.66339 4.98261 8.8464 5.13997 9.05055C5.31731 9.28061 5.45005 9.5461 5.71554 10.0771L6.5 11.646L7.28446 10.0771C7.54995 9.5461 7.68269 9.28061 7.86003 9.05055C8.01739 8.8464 8.20041 8.66339 8.40455 8.50603C8.63462 8.32869 8.9001 8.19594 9.43108 7.93045L11 7.146L9.43108 6.36154C8.9001 6.09605 8.63462 5.9633 8.40455 5.78597C8.20041 5.6286 8.01739 5.44559 7.86003 5.24144C7.68269 5.01138 7.54995 4.74589 7.28446 4.21491L6.5 2.646ZM17 12.646L16.0489 14.5482C15.7834 15.0792 15.6506 15.3447 15.4733 15.5748C15.3159 15.7789 15.1329 15.9619 14.9288 16.1193C14.6987 16.2966 14.4332 16.4294 13.9023 16.6949L12 17.646L13.9023 18.5971C14.4332 18.8626 14.6987 18.9954 14.9288 19.1727C15.1329 19.3301 15.3159 19.5131 15.4733 19.7172C15.6506 19.9473 15.7834 20.2128 16.0489 20.7437L17 22.646L17.9511 20.7437C18.2166 20.2128 18.3494 19.9473 18.5267 19.7172C18.6841 19.5131 18.8671 19.3301 19.0712 19.1727C19.3013 18.9954 19.5668 18.8626 20.0977 18.5971L22 17.646L20.0977 16.6949C19.5668 16.4294 19.3013 16.2966 19.0712 16.1193C18.8671 15.9619 18.6841 15.7789 18.5267 15.5748C18.3494 15.3447 18.2166 15.0792 17.9511 14.5482L17 12.646Z" stroke="#677285" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
-</mask>
-<g mask="url(#mask0_225_286)">
-<rect y="0.799316" width="24" height="24" fill="url(#paint0_linear_225_286)"/>
-</g>
-<defs>
-<linearGradient id="paint0_linear_225_286" x1="0" y1="24.7993" x2="24" y2="0.799316" gradientUnits="userSpaceOnUse">
-<stop stop-color="#FBB552"/>
-<stop offset="1" stop-color="#E950E2"/>
-</linearGradient>
-</defs>
-</svg>
diff --git a/static/assets/images/logo-icon-white.svg b/assets/images/ask-ai-logo.svg
similarity index 100%
rename from static/assets/images/logo-icon-white.svg
rename to assets/images/ask-ai-logo.svg
diff --git a/assets/images/gordon-logo.svg b/assets/images/gordon-logo.svg
new file mode 100644
index 000000000000..d19e48fa61c7
--- /dev/null
+++ b/assets/images/gordon-logo.svg
@@ -0,0 +1 @@
+<svg width="92" height="20" viewBox="0 0 92 20" version="1.1" xmlns="http://www.w3.org/2000/svg"><path d="M20.474,6.892L20.813,7.12C20.813,7.12 20.608,7.547 20.587,7.576C19.699,9.293 17.884,9.181 17.196,9.17C15.107,14.413 11.672,16.582 7.664,16.578C5.036,16.576 3.279,15.721 2.116,14.556C1.928,14.367 1.755,14.171 1.597,13.969C0.166,12.136 -0.022,9.885 0.002,8.715L7.997,8.715C13.176,8.715 14.345,8.882 15.614,8.145C15.276,7.735 15.101,7.169 15.049,6.665C14.983,5.848 15.17,4.948 15.614,4.274L15.84,3.932L16.179,4.16C17.095,4.874 17.596,5.693 17.648,6.665C18.623,6.402 19.964,6.549 20.474,6.892ZM5.22,5.684L5.22,7.934L2.972,7.934L2.972,5.684L5.22,5.684ZM8.125,5.684L8.125,7.934L5.876,7.934L5.876,5.684L8.125,5.684ZM11.03,5.684L11.03,7.934L8.781,7.934L8.781,5.684L11.03,5.684ZM13.934,5.684L13.934,7.934L11.686,7.934L11.686,5.684L13.934,5.684ZM2.315,5.684L2.315,7.934L0.067,7.934L0.067,5.684L2.315,5.684ZM5.22,2.842L5.22,5.092L2.972,5.092L2.972,2.842L5.22,2.842ZM8.125,2.842L8.125,5.092L5.876,5.092L5.876,2.842L8.125,2.842ZM11.03,2.842L11.03,5.092L8.781,5.092L8.781,2.842L11.03,2.842ZM11.03,0L11.03,2.25L8.781,2.25L8.781,0L11.03,0ZM34.107,13.496C33.741,14.148 33.264,14.674 32.676,15.074C32.002,15.52 31.226,15.742 30.348,15.742C29.394,15.742 28.548,15.52 27.811,15.074C27.086,14.616 26.513,13.992 26.094,13.203C25.674,12.401 25.464,11.485 25.464,10.454C25.464,9.41 25.687,8.493 26.132,7.704C26.59,6.902 27.213,6.279 28.002,5.833C28.79,5.375 29.699,5.146 30.73,5.146C31.747,5.146 32.65,5.375 33.439,5.833C34.227,6.279 34.844,6.902 35.289,7.704C35.747,8.493 35.976,9.41 35.976,10.454L35.976,14.578C35.976,15.583 35.754,16.493 35.308,17.308C34.863,18.135 34.24,18.791 33.439,19.274C32.65,19.758 31.734,20 30.692,20C29.789,20 28.943,19.822 28.154,19.465C27.366,19.109 26.698,18.587 26.151,17.9C25.986,17.683 25.922,17.461 25.96,17.232C26.011,17.002 26.138,16.818 26.342,16.678C26.571,16.525 26.806,16.474 27.048,16.525C27.302,16.576 27.505,16.703 27.658,16.907C28.002,17.34 28.434,17.677 28.955,17.919C29.477,18.161 30.068,18.282 30.73,18.282C31.34,18.282 31.9,18.135 32.409,17.842C32.93,17.55 33.343,17.117 33.649,16.544C33.954,15.971 34.107,15.271 34.107,14.444L34.107,13.496ZM30.73,14.024C31.391,14.024 31.976,13.871 32.485,13.566C32.994,13.26 33.388,12.84 33.668,12.306C33.96,11.771 34.107,11.154 34.107,10.454C34.107,9.753 33.96,9.136 33.668,8.602C33.388,8.054 32.994,7.628 32.485,7.322C31.976,7.017 31.391,6.864 30.73,6.864C30.068,6.864 29.483,7.017 28.974,7.322C28.466,7.628 28.065,8.054 27.773,8.602C27.48,9.136 27.334,9.753 27.334,10.454C27.334,11.154 27.48,11.771 27.773,12.306C28.065,12.84 28.466,13.26 28.974,13.566C29.483,13.871 30.068,14.024 30.73,14.024ZM51.92,9.136L51.92,14.711C51.92,15.017 51.837,15.252 51.672,15.418C51.519,15.583 51.284,15.666 50.966,15.666C50.661,15.666 50.425,15.59 50.26,15.437C50.095,15.271 50.012,15.029 50.012,14.711L50.012,6.177C50.012,5.871 50.095,5.636 50.26,5.47C50.425,5.305 50.661,5.222 50.966,5.222C51.284,5.222 51.519,5.305 51.672,5.47C51.837,5.623 51.92,5.858 51.92,6.177L51.92,6.529C52.232,6.177 52.6,5.881 53.026,5.642C53.662,5.286 54.362,5.108 55.125,5.108C55.888,5.108 56.454,5.235 56.823,5.489C57.204,5.731 57.351,6.024 57.262,6.368C57.223,6.546 57.147,6.686 57.033,6.788C56.931,6.877 56.81,6.934 56.67,6.96C56.53,6.985 56.378,6.979 56.212,6.94C55.398,6.775 54.667,6.762 54.018,6.902C53.37,7.042 52.855,7.303 52.473,7.685C52.104,8.067 51.92,8.551 51.92,9.136ZM84.159,9.327L84.159,14.711C84.159,14.991 84.07,15.227 83.892,15.418C83.714,15.596 83.479,15.685 83.186,15.685C82.906,15.685 82.671,15.596 82.48,15.418C82.302,15.227 82.213,14.991 82.213,14.711L82.213,6.196C82.213,5.903 82.302,5.668 82.48,5.489C82.671,5.311 82.906,5.222 83.186,5.222C83.479,5.222 83.714,5.311 83.892,5.489C84.07,5.668 84.159,5.903 84.159,6.196L84.159,6.399C84.442,6.12 84.767,5.88 85.132,5.68C85.806,5.311 86.563,5.127 87.402,5.127C88.28,5.127 89.062,5.318 89.749,5.699C90.449,6.069 90.996,6.616 91.389,7.341C91.797,8.067 92,8.958 92,10.014L92,14.711C92,14.991 91.905,15.227 91.714,15.418C91.536,15.596 91.307,15.685 91.027,15.685C90.748,15.685 90.512,15.596 90.321,15.418C90.143,15.227 90.054,14.991 90.054,14.711L90.054,10.014C90.054,9.289 89.92,8.697 89.653,8.239C89.386,7.781 89.024,7.443 88.566,7.227C88.121,6.998 87.606,6.883 87.021,6.883C86.487,6.883 86.003,6.991 85.571,7.208C85.138,7.424 84.795,7.717 84.541,8.086C84.286,8.442 84.159,8.856 84.159,9.327ZM42.737,15.742C41.706,15.742 40.797,15.52 40.008,15.074C39.22,14.616 38.597,13.992 38.139,13.203C37.694,12.401 37.471,11.485 37.471,10.454C37.471,9.41 37.694,8.493 38.139,7.704C38.597,6.902 39.22,6.279 40.008,5.833C40.797,5.375 41.706,5.146 42.737,5.146C43.754,5.146 44.657,5.375 45.446,5.833C46.234,6.279 46.851,6.902 47.296,7.704C47.754,8.493 47.983,9.41 47.983,10.454C47.983,11.485 47.76,12.401 47.315,13.203C46.87,13.992 46.253,14.616 45.465,15.074C44.676,15.52 43.767,15.742 42.737,15.742ZM42.737,14.024C43.398,14.024 43.983,13.871 44.492,13.566C45,13.26 45.395,12.84 45.675,12.306C45.967,11.771 46.113,11.154 46.113,10.454C46.113,9.753 45.967,9.136 45.675,8.602C45.395,8.054 45,7.628 44.492,7.322C43.983,7.017 43.398,6.864 42.737,6.864C42.075,6.864 41.49,7.017 40.981,7.322C40.473,7.628 40.072,8.054 39.779,8.602C39.487,9.136 39.341,9.753 39.341,10.454C39.341,11.154 39.487,11.771 39.779,12.306C40.072,12.84 40.473,13.26 40.981,13.566C41.49,13.871 42.075,14.024 42.737,14.024ZM62.391,15.742C61.398,15.742 60.502,15.513 59.701,15.055C58.912,14.584 58.282,13.948 57.812,13.146C57.354,12.344 57.125,11.44 57.125,10.434C57.125,9.429 57.335,8.532 57.755,7.742C58.187,6.94 58.772,6.31 59.51,5.852C60.247,5.381 61.08,5.146 62.009,5.146C62.759,5.146 63.453,5.305 64.089,5.623C64.724,5.929 65.259,6.349 65.691,6.883L65.691,1.728C65.691,1.435 65.78,1.2 65.958,1.022C66.149,0.843 66.384,0.754 66.664,0.754C66.957,0.754 67.192,0.843 67.37,1.022C67.548,1.2 67.637,1.435 67.637,1.728L67.637,10.434C67.637,11.44 67.402,12.344 66.931,13.146C66.473,13.948 65.85,14.584 65.061,15.055C64.273,15.513 63.383,15.742 62.391,15.742ZM62.391,14.024C63.039,14.024 63.618,13.871 64.127,13.566C64.635,13.248 65.036,12.815 65.329,12.267C65.621,11.72 65.767,11.109 65.767,10.434C65.767,9.747 65.621,9.136 65.329,8.602C65.036,8.067 64.635,7.647 64.127,7.341C63.618,7.023 63.039,6.864 62.391,6.864C61.755,6.864 61.176,7.023 60.654,7.341C60.146,7.647 59.739,8.067 59.433,8.602C59.141,9.136 58.995,9.747 58.995,10.434C58.995,11.109 59.141,11.72 59.433,12.267C59.739,12.815 60.146,13.248 60.654,13.566C61.176,13.871 61.755,14.024 62.391,14.024ZM74.938,15.742C73.907,15.742 72.998,15.52 72.209,15.074C71.421,14.616 70.798,13.992 70.34,13.203C69.895,12.401 69.672,11.485 69.672,10.454C69.672,9.41 69.895,8.493 70.34,7.704C70.798,6.902 71.421,6.279 72.209,5.833C72.998,5.375 73.907,5.146 74.938,5.146C75.955,5.146 76.858,5.375 77.647,5.833C78.435,6.279 79.052,6.902 79.497,7.704C79.955,8.493 80.184,9.41 80.184,10.454C80.184,11.485 79.962,12.401 79.516,13.203C79.071,13.992 78.454,14.616 77.666,15.074C76.877,15.52 75.968,15.742 74.938,15.742ZM74.938,14.024C75.599,14.024 76.184,13.871 76.693,13.566C77.202,13.26 77.596,12.84 77.876,12.306C78.168,11.771 78.314,11.154 78.314,10.454C78.314,9.753 78.168,9.136 77.876,8.602C77.596,8.054 77.202,7.628 76.693,7.322C76.184,7.017 75.599,6.864 74.938,6.864C74.276,6.864 73.691,7.017 73.182,7.322C72.674,7.628 72.273,8.054 71.981,8.602C71.688,9.136 71.542,9.753 71.542,10.454C71.542,11.154 71.688,11.771 71.981,12.306C72.273,12.84 72.674,13.26 73.182,13.566C73.691,13.871 74.276,14.024 74.938,14.024Z" fill="white"/></svg>
\ No newline at end of file
diff --git a/assets/images/gordon-robot.svg b/assets/images/gordon-robot.svg
new file mode 100644
index 000000000000..9b315eadebaf
--- /dev/null
+++ b/assets/images/gordon-robot.svg
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"><svg width="100%" height="100%" viewBox="0 0 1980 1834" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;"><circle cx="870.362" cy="1073.44" r="679.563" style="fill:none;stroke:url(#_Linear1);stroke-width:16.67px;stroke-dasharray:33.33,33.33;"/><circle cx="907.129" cy="1073.44" r="863.329" style="fill:none;stroke:url(#_Linear2);stroke-width:16.67px;stroke-dasharray:33.33,33.33;"/><circle cx="907.129" cy="1073.44" r="1061.3" style="fill:none;stroke:url(#_Linear3);stroke-width:16.67px;stroke-dasharray:33.33,33.33;"/><path d="M321.913,809.612C318.358,813.746 309.521,811.021 291.846,805.583C254.446,794.067 225.63,783.517 209.043,758.088C191.187,757.925 173.093,757.029 154.266,755.35C80.028,748.733 27.871,682.146 27.871,607.613C27.871,526.117 90.165,456.933 171.633,454.746C201.17,453.95 229.028,453.992 257.254,454.767C338.688,457.017 401.079,526.225 401.079,607.692C401.079,673.5 360.313,733.196 299.629,750.742C301.375,760.392 305.542,769.85 311.317,779.933C320.796,796.488 325.538,804.763 322.288,809.142C322.167,809.308 322.05,809.454 321.913,809.612Z" style="fill:url(#_Linear4);fill-rule:nonzero;"/><path d="M401.079,607.692C401.079,673.5 360.313,733.196 299.629,750.742C301.375,760.392 305.542,769.85 311.317,779.933C320.796,796.488 325.538,804.763 322.288,809.142C322.167,809.308 322.05,809.454 321.913,809.612C318.358,813.746 309.521,811.021 291.846,805.583C254.446,794.067 225.63,783.517 209.043,758.088C191.187,757.925 173.093,757.029 154.266,755.35C80.028,748.733 27.871,682.146 27.871,607.613C27.871,526.117 90.165,456.933 171.633,454.746C201.17,453.95 229.028,453.992 257.254,454.767C338.688,457.017 401.079,526.225 401.079,607.692ZM396.871,603.979C395.008,526.217 334.904,461.079 257.137,458.933C228.989,458.158 201.203,458.121 171.743,458.913C92.716,461.033 32.038,528.188 32.038,607.613C32.038,680.346 82.887,744.804 154.637,751.2C173.357,752.871 191.339,753.758 209.08,753.921L211.314,753.942L212.535,755.813C228.179,779.796 255.454,790.017 293.071,801.6C302.029,804.354 308.35,806.292 312.883,807.079C317.733,807.921 318.604,807.071 318.754,806.892C318.825,806.813 318.879,806.742 318.942,806.658C319.067,806.487 319.7,805.417 317.729,800.717C315.892,796.325 312.5,790.388 307.7,782.008C301.817,771.729 297.396,761.796 295.525,751.483L294.858,747.783L298.471,746.738C357.158,729.771 396.913,671.879 396.913,607.692L396.871,603.979Z" style="fill:#bdd6ed;fill-rule:nonzero;"/><path d="M256.838,579.196C256.838,573.825 256.738,572.796 256.45,572.042C256.108,571.146 255.554,570.346 254.838,569.713C254.233,569.179 253.302,568.729 248.274,566.842L215.694,554.621C215.047,554.379 214.714,554.258 214.473,554.179C214.233,554.258 213.9,554.383 213.256,554.621L180.676,566.842C175.651,568.725 174.723,569.179 174.117,569.713C173.398,570.35 172.842,571.146 172.501,572.042C172.214,572.796 172.115,573.825 172.115,579.196L172.115,608.254C172.115,620.842 179.004,632.242 188.118,641.738C197.162,651.158 207.702,657.967 213.383,661.279C213.73,661.483 213.98,661.629 214.196,661.75C214.313,661.817 214.405,661.863 214.473,661.9C214.542,661.863 214.635,661.817 214.754,661.75C214.97,661.629 215.22,661.483 215.568,661.279C221.248,657.967 231.788,651.158 240.832,641.738C249.946,632.242 256.833,620.842 256.838,608.254L256.838,579.196ZM231.323,585.608C233.763,583.167 237.72,583.167 240.161,585.608C242.602,588.05 242.602,592.004 240.161,594.446L212.817,621.792C210.376,624.229 206.42,624.229 203.979,621.792L191.829,609.638C189.388,607.196 189.388,603.238 191.829,600.796C194.27,598.358 198.226,598.358 200.667,600.796L208.398,608.529L231.323,585.608ZM269.338,608.254C269.333,625.496 259.958,639.858 249.849,650.392C239.668,660.996 228.023,668.488 221.867,672.079C220.718,672.75 219.165,673.717 217.061,674.171C215.46,674.513 213.49,674.513 211.889,674.171C209.785,673.717 208.232,672.75 207.084,672.079C200.927,668.488 189.282,660.996 179.101,650.392C168.99,639.858 159.615,625.496 159.615,608.254L159.615,579.196C159.615,574.85 159.518,571.021 160.819,567.6C161.882,564.804 163.607,562.313 165.848,560.338C168.594,557.917 172.216,556.663 176.285,555.133L208.866,542.921C209.878,542.542 211.239,541.992 212.711,541.779L213.594,541.688C214.182,541.646 214.772,541.646 215.36,541.688L216.239,541.779L217.318,541.996C218.369,542.258 219.325,542.633 220.084,542.921L252.665,555.133C256.733,556.663 260.354,557.917 263.1,560.338C265.346,562.313 267.071,564.804 268.133,567.6C269.438,571.021 269.338,574.85 269.338,579.196L269.338,608.254Z" style="fill:#bdd6ed;fill-rule:nonzero;"/><path d="M1200.02,91.656C1240.21,88.063 1278.54,87.963 1320.52,91.705C1394.75,98.324 1446.91,164.91 1446.91,239.443C1446.91,319.07 1387.44,386.928 1308.73,392.038C1294.42,428.708 1262.3,440.921 1218.3,454.467C1200.63,459.904 1191.8,462.625 1188.24,458.492C1188.1,458.338 1187.99,458.192 1187.86,458.025C1184.61,453.646 1189.35,445.367 1198.83,428.817C1206.12,416.088 1210.86,404.357 1211.38,391.973C1132.98,386.512 1073.7,318.762 1073.7,239.361C1073.7,164.916 1125.87,98.287 1200.02,91.656Z" style="fill:url(#_Linear5);fill-rule:nonzero;"/><path d="M1073.7,239.361C1073.7,164.916 1125.87,98.287 1200.02,91.656C1240.21,88.063 1278.54,87.963 1320.52,91.705C1394.75,98.324 1446.91,164.91 1446.91,239.443C1446.91,319.07 1387.44,386.928 1308.73,392.038C1294.42,428.708 1262.3,440.921 1218.3,454.467C1200.63,459.904 1191.8,462.625 1188.24,458.492C1188.1,458.338 1187.99,458.192 1187.86,458.025C1184.61,453.646 1189.35,445.367 1198.83,428.817C1206.12,416.088 1210.86,404.357 1211.38,391.973C1132.98,386.511 1073.7,318.762 1073.7,239.361ZM1077.87,239.361C1077.87,316.736 1135.61,382.52 1211.67,387.819L1215.72,388.099L1215.55,392.148C1214.98,405.501 1209.88,417.921 1202.45,430.888C1197.65,439.271 1194.25,445.208 1192.42,449.6C1190.44,454.325 1191.09,455.383 1191.21,455.542C1191.27,455.629 1191.33,455.696 1191.4,455.775C1191.55,455.954 1192.42,456.808 1197.27,455.967C1201.8,455.179 1208.12,453.238 1217.08,450.479C1261.29,436.871 1291.36,425.096 1304.84,390.525L1305.81,388.055L1308.46,387.88C1384.82,382.921 1442.75,317.043 1442.75,239.443C1442.75,166.71 1391.9,102.253 1320.15,95.856C1278.42,92.135 1240.34,92.235 1200.39,95.807C1128.73,102.215 1077.87,166.715 1077.87,239.361Z" style="fill:#bdd6ed;fill-rule:nonzero;"/><path d="M1258.44,183.917C1259.68,183.727 1260.94,183.727 1262.17,183.917L1262.79,184.027L1263.55,184.218C1265.31,184.723 1266.87,185.644 1268.06,186.309L1313.03,211.289C1314.48,212.091 1316.48,213.119 1317.98,214.752C1319.17,216.042 1320.07,217.575 1320.62,219.24C1321.15,220.821 1321.23,222.483 1321.25,223.911L1321.25,275.913C1321.23,277.342 1321.15,279.005 1320.62,280.588C1320.07,282.254 1319.17,283.782 1317.98,285.073C1316.48,286.706 1314.48,287.733 1313.03,288.535L1268.06,313.519C1266.7,314.28 1264.86,315.375 1262.79,315.802C1261.15,316.138 1259.46,316.138 1257.83,315.802C1255.75,315.375 1253.92,314.28 1252.55,313.519L1207.59,288.535C1206.14,287.733 1204.14,286.706 1202.63,285.073C1201.45,283.783 1200.54,282.253 1199.99,280.588C1199.47,279.005 1199.38,277.341 1199.37,275.913L1199.37,223.911C1199.38,222.483 1199.47,220.821 1199.99,219.24C1200.54,217.574 1201.45,216.042 1202.63,214.752C1204.14,213.118 1206.14,212.091 1207.59,211.289L1252.55,186.309C1253.92,185.549 1255.75,184.453 1257.83,184.027L1258.44,183.917ZM1211.87,274.574C1211.87,275.635 1211.88,276.199 1211.9,276.601C1212.23,276.815 1212.73,277.092 1213.66,277.61L1254.06,300.05L1254.06,253.59L1211.87,230.149L1211.87,274.574ZM1266.56,253.59L1266.56,300.05L1306.96,277.61C1307.89,277.093 1308.38,276.815 1308.72,276.601C1308.74,276.199 1308.75,275.636 1308.75,274.574L1308.75,230.149L1266.56,253.59ZM1279.63,254.372C1283.08,254.373 1285.88,257.171 1285.88,260.622L1285.88,278.598C1285.88,282.05 1283.08,284.848 1279.63,284.848C1276.18,284.848 1273.38,282.05 1273.38,278.598L1273.38,260.622C1273.38,257.17 1276.18,254.372 1279.63,254.372ZM1296.53,245.383C1299.98,245.384 1302.78,248.182 1302.78,251.633L1302.78,269.61C1302.78,273.061 1299.98,275.859 1296.53,275.86C1293.08,275.86 1290.28,273.062 1290.28,269.61L1290.28,251.633C1290.28,248.182 1293.08,245.383 1296.53,245.383ZM1258.62,197.235L1218.49,219.529L1260.31,242.763L1302.12,219.529L1261.99,197.235C1261.11,196.746 1260.65,196.49 1260.31,196.323C1259.97,196.49 1259.5,196.745 1258.62,197.235Z" style="fill:#bdd6ed;fill-rule:nonzero;"/><path d="M1526.08,1405.89C1529.64,1401.76 1538.47,1404.48 1556.15,1409.92C1593.55,1421.43 1622.36,1431.98 1638.95,1457.41C1656.81,1457.57 1674.9,1458.48 1693.73,1460.15C1767.97,1466.77 1820.12,1533.36 1820.12,1607.89C1820.12,1689.39 1757.83,1758.57 1676.36,1760.76C1646.83,1761.55 1618.97,1761.51 1590.74,1760.73C1509.31,1758.49 1446.91,1689.27 1446.91,1607.81C1446.91,1542 1487.68,1482.3 1548.37,1464.76C1546.62,1455.11 1542.45,1445.65 1536.67,1435.56C1527.2,1419.01 1522.46,1410.73 1525.71,1406.35C1525.83,1406.19 1525.95,1406.05 1526.08,1405.89Z" style="fill:url(#_Linear6);fill-rule:nonzero;"/><path d="M1446.91,1607.81C1446.91,1542 1487.68,1482.3 1548.37,1464.76C1546.83,1456.32 1543.45,1448.02 1538.76,1439.32L1536.67,1435.56C1527.49,1419.53 1522.76,1411.26 1525.43,1406.78L1525.71,1406.35L1526.08,1405.89C1529.64,1401.76 1538.47,1404.48 1556.15,1409.92C1593.55,1421.43 1622.36,1431.98 1638.95,1457.41C1656.81,1457.57 1674.9,1458.48 1693.73,1460.15C1767.97,1466.77 1820.12,1533.35 1820.12,1607.89L1820.08,1611.7C1818.17,1691.53 1756.56,1758.6 1676.36,1760.76L1665.36,1761.02C1643.5,1761.46 1622.44,1761.43 1601.31,1760.99L1590.74,1760.73C1510.58,1758.52 1448.87,1691.42 1446.96,1611.62L1446.91,1607.81ZM1451.08,1607.81C1451.08,1687.2 1511.85,1754.39 1590.85,1756.57C1619,1757.34 1646.79,1757.38 1676.25,1756.59C1755.28,1754.47 1815.95,1687.32 1815.95,1607.89C1815.95,1535.16 1765.11,1470.7 1693.36,1464.3C1674.63,1462.63 1656.65,1461.74 1638.91,1461.58L1636.68,1461.55L1635.46,1459.68C1619.81,1435.7 1592.54,1425.48 1554.92,1413.9C1545.96,1411.15 1539.65,1409.21 1535.11,1408.42C1530.26,1407.58 1529.39,1408.43 1529.24,1408.61L1529.05,1408.84C1528.93,1409 1528.29,1410.07 1530.26,1414.78C1532.1,1419.17 1535.49,1425.11 1540.29,1433.49C1546.18,1443.77 1550.6,1453.7 1552.47,1464.02L1553.13,1467.72L1549.52,1468.77C1490.84,1485.73 1451.08,1543.62 1451.08,1607.81Z" style="fill:#bdd6ed;fill-rule:nonzero;"/><path d="M1691.49,1643.16C1694.58,1641.61 1698.33,1642.87 1699.88,1645.95C1701.42,1649.04 1700.17,1652.8 1697.08,1654.34L1638.49,1683.63C1638.02,1683.87 1636.71,1684.58 1635.23,1684.86C1634.1,1685.08 1632.93,1685.08 1631.8,1684.86C1630.33,1684.58 1629.02,1683.87 1628.55,1683.63L1569.96,1654.34C1566.87,1652.8 1565.62,1649.04 1567.16,1645.95C1568.71,1642.87 1572.46,1641.61 1575.55,1643.16L1633.52,1672.14L1691.49,1643.16ZM1691.49,1612.78C1694.58,1611.23 1698.33,1612.48 1699.88,1615.57C1701.42,1618.66 1700.17,1622.41 1697.08,1623.95L1638.49,1653.25C1638.02,1653.49 1636.71,1654.2 1635.23,1654.48C1634.1,1654.69 1632.93,1654.7 1631.8,1654.48C1630.33,1654.2 1629.02,1653.49 1628.55,1653.25L1569.96,1623.95C1566.87,1622.41 1565.62,1618.66 1567.16,1615.57C1568.71,1612.48 1572.46,1611.23 1575.55,1612.78L1633.52,1641.76L1691.49,1612.78ZM1634.38,1551.75L1635.23,1551.87L1635.78,1551.99C1637.02,1552.32 1638.08,1552.89 1638.49,1553.1L1697.08,1582.4C1699.2,1583.45 1700.53,1585.62 1700.53,1587.99C1700.53,1590.35 1699.2,1592.51 1697.08,1593.57L1638.49,1622.87C1638.02,1623.1 1636.71,1623.82 1635.23,1624.1C1634.1,1624.31 1632.93,1624.31 1631.8,1624.1C1630.33,1623.82 1629.02,1623.1 1628.55,1622.87L1569.96,1593.57C1567.84,1592.51 1566.5,1590.35 1566.5,1587.99C1566.5,1585.62 1567.84,1583.45 1569.96,1582.4L1628.55,1553.1C1629.02,1552.86 1630.33,1552.15 1631.8,1551.87L1632.66,1551.75C1633.23,1551.7 1633.8,1551.7 1634.38,1551.75ZM1586.73,1587.98L1633.52,1611.38L1680.3,1587.98L1633.52,1564.59L1586.73,1587.98Z" style="fill:#bdd6ed;fill-rule:nonzero;"/><g><path d="M532.942,1323.77L639.083,1243.65C655.642,1231.16 670.842,1216.3 681,1197.84C761.229,1052 565.646,1044.42 385.079,1173.08C350.508,1200.75 334.892,1233.13 331.296,1265.74C320.038,1367.83 453.913,1383.41 532.942,1323.77Z" style="fill:#fffdfe;fill-rule:nonzero;"/></g><path d="M532.942,1323.77L639.083,1243.65C655.642,1231.16 670.842,1216.3 681,1197.84C761.229,1052 565.646,1044.42 385.079,1173.08C350.508,1200.75 334.892,1233.13 331.296,1265.74C320.038,1367.83 453.913,1383.41 532.942,1323.77Z" style="fill:none;fill-rule:nonzero;stroke:#305b8e;stroke-width:16.67px;"/><path d="M690.625,1142.86C687.721,1173.17 674.408,1212.09 615.342,1249.95C615.342,1249.95 551.204,1301.32 511.879,1326.94C472.554,1352.56 452.238,1359.19 371.233,1346.88C508.554,1300.25 577.475,1260.57 690.625,1142.86Z" style="fill:url(#_Linear7);fill-rule:nonzero;"/><g><path d="M110.219,873.917C106.891,876.013 105.289,880.258 106.38,884.104L125.805,952.446C126.388,954.496 127.684,956.208 129.43,957.233L149.835,969.208C153.454,971.333 158.56,972.404 160.502,976.304L257.946,1172.08C260.029,1176.27 264.992,1177.67 268.942,1175.18L285.163,1164.96C289.113,1162.48 290.513,1157.08 288.271,1153L183.376,961.917C181.283,958.104 182.985,952.8 183.18,948.296C183.183,948.229 183.185,948.163 183.187,948.096L183.723,923.2C183.772,920.95 182.994,918.804 181.56,917.221L134.916,865.754C132.407,862.988 128.393,862.471 125.169,864.5L110.219,873.917Z" style="fill:#c8d5e8;"/></g><g><path d="M222.248,1204.58C228.299,1216.13 242.138,1219.88 253.134,1212.96L322.028,1169.57C333.024,1162.65 337.039,1147.65 330.988,1136.11C324.937,1124.56 311.098,1120.81 300.102,1127.73L231.208,1171.12C220.212,1178.04 216.197,1193.04 222.248,1204.58Z" style="fill:#4079bd;"/></g><path d="M224.01,1203.47C229.527,1214 242.146,1217.42 252.172,1211.11L321.055,1167.73C331.081,1161.42 334.742,1147.75 329.225,1137.22C323.708,1126.69 311.089,1123.27 301.063,1129.58L232.18,1172.96C222.154,1179.27 218.494,1192.94 224.01,1203.47Z" style="fill:none;stroke:#305b8e;stroke-width:4.33px;"/><path d="M307.446,1147.42L243.029,1187.99C242.048,1188.61 241.689,1189.94 242.227,1190.97C242.765,1192 243.998,1192.33 244.978,1191.71L309.392,1151.15C310.375,1150.53 310.733,1149.2 310.196,1148.17C309.658,1147.14 308.425,1146.81 307.446,1147.42Z" style="fill:none;fill-rule:nonzero;stroke:#305b8e;stroke-width:4.17px;"/><g><path d="M424.988,1409C449.117,1393.4 456.883,1359.8 441.988,1335.45L350.546,1185.92C341.442,1171.04 322.838,1166.73 307.996,1176.08L269.25,1200.48C254.421,1209.81 248.408,1229.58 255.496,1245.72L326.921,1408.33C338.725,1435.2 369.833,1444.64 394.375,1428.78L424.988,1409Z" style="fill:#4079bd;fill-rule:nonzero;"/></g><path d="M424,1407.16C447.121,1392.23 454.567,1360.02 440.292,1336.68L348.85,1187.15C340.313,1173.2 322.879,1169.17 308.963,1177.92L270.217,1202.32C256.313,1211.08 250.677,1229.61 257.321,1244.74L328.742,1407.35C340.054,1433.1 369.867,1442.14 393.388,1426.95L424,1407.16Z" style="fill:none;fill-rule:nonzero;stroke:#305b8e;stroke-width:4.17px;"/><path d="M326.738,1196.15C324.933,1197.44 324.371,1200.01 325.492,1201.9L421.446,1364.38C422.563,1366.27 424.933,1366.77 426.742,1365.48C428.546,1364.2 429.108,1361.63 427.988,1359.74L332.033,1197.26C330.917,1195.37 328.546,1194.88 326.738,1196.15Z" style="fill:#305b8e;fill-rule:nonzero;"/><path d="M308.408,1207.57C306.571,1208.8 305.946,1211.35 307.013,1213.28L398.754,1378.65C399.821,1380.58 402.175,1381.15 404.017,1379.92C405.854,1378.7 406.479,1376.14 405.413,1374.22L313.675,1208.83C312.604,1206.91 310.25,1206.34 308.408,1207.57Z" style="fill:#305b8e;fill-rule:nonzero;"/><path d="M292.671,1217.52C290.767,1218.62 290.004,1221.12 290.967,1223.12L373.517,1394.22C374.479,1396.21 376.8,1396.93 378.7,1395.83C380.604,1394.73 381.367,1392.22 380.408,1390.23L297.854,1219.12C296.896,1217.13 294.575,1216.41 292.671,1217.52Z" style="fill:#305b8e;fill-rule:nonzero;"/><path d="M277.088,1227.78C275.129,1228.75 274.229,1231.21 275.079,1233.26L348.146,1409.47C348.996,1411.52 351.275,1412.39 353.233,1411.41C355.196,1410.44 356.092,1407.98 355.242,1405.93L282.175,1229.73C281.325,1227.67 279.046,1226.8 277.088,1227.78Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M371.308,1168.74C362.454,1159.89 348.854,1159.67 337.792,1166.15C321.617,1175.61 315.154,1196.95 323.358,1213.8L347.392,1263.15C355.038,1278.85 373.446,1284.42 388.513,1275.61C400.442,1268.63 407.204,1254.33 404.388,1240.53C397.325,1205.94 388.283,1185.7 371.308,1168.74Z" style="fill:#fffdfe;fill-rule:nonzero;"/></g><path d="M322.008,1214.58C322.908,1214.06 323.808,1213.53 324.708,1213C327.304,1217.55 329.875,1222.12 332.417,1226.7C338.725,1238.08 344.846,1249.58 350.783,1261.17C353.967,1267.4 359.367,1272.09 365.692,1274.2C372.487,1276.53 380.25,1275.69 386.7,1271.89C396.846,1266.19 403.1,1253.16 400.638,1241.56C395.504,1215.23 387.404,1189.17 369.158,1171.17C361.742,1163.27 348.854,1162.78 338.929,1168.49C328.758,1174.04 321.75,1185.99 321.638,1198.22C321.546,1203.34 322.604,1208.43 324.708,1213C323.808,1213.53 322.908,1214.06 322.008,1214.58C319.496,1209.7 318.083,1204.12 317.963,1198.4C317.542,1184.77 324.983,1170.71 336.65,1163.81C347.867,1156.81 363.571,1156.48 373.458,1166.31C393.417,1184.85 402.671,1212.88 408.138,1239.5C411.563,1254.76 403.446,1271.88 390.321,1279.33C381.979,1284.3 371.792,1285.44 362.963,1282.41C354.738,1279.67 347.746,1273.3 344.004,1265.14C338.517,1253.28 333.217,1241.3 328.1,1229.23C326.042,1224.36 324.008,1219.48 322.008,1214.58ZM324.708,1213L322.008,1214.58L324.708,1213Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M261.563,1307.93C255.938,1321.39 255.65,1336.86 260.117,1350.53C265.138,1365.88 282.138,1371.78 294.921,1362.61L340.05,1330.21C342.075,1328.76 343.954,1327.08 345.658,1325.2L347.263,1323.43C355.45,1314.39 358.238,1301.17 354.417,1289.48C348.704,1272.01 330.433,1263.81 314.592,1271.59C272.383,1292.32 266.6,1295.88 261.563,1307.93Z" style="fill:#fffdfe;fill-rule:nonzero;"/><path d="M262.925,1308.57C262.017,1308.15 261.108,1307.72 260.204,1307.3C261.829,1302.15 265.138,1297 269.246,1293.51C283.088,1282.25 298.213,1275.43 313.05,1267.69C316.325,1266.04 319.846,1264.97 323.417,1264.53C338.329,1262.51 353.421,1272.66 358.104,1287.96C362.413,1300.86 359.033,1316.44 349.871,1326.22C349.333,1326.8 348.796,1327.39 348.258,1327.98C346.354,1330.05 344.25,1331.9 342,1333.49C326.871,1344.15 311.721,1354.76 296.542,1365.33C282.854,1375.57 262.417,1367.92 257.921,1351.43C255.117,1342.33 254.325,1332.49 255.721,1322.96C256.513,1317.55 258.013,1312.25 260.204,1307.3C261.108,1307.72 262.017,1308.15 262.925,1308.57C261.058,1313.31 259.863,1318.33 259.325,1323.4C258.371,1332.32 259.454,1341.39 262.317,1349.62C266.517,1362.96 283.004,1368.12 293.3,1359.88C308.208,1348.85 323.146,1337.87 338.104,1326.94C339.896,1325.62 341.558,1324.11 343.058,1322.42C343.592,1321.83 344.121,1321.24 344.65,1320.64C351.671,1312.91 354.108,1300.87 350.725,1290.99C347.046,1279.28 335.454,1271.61 324.088,1273.15C321.367,1273.48 318.683,1274.27 316.138,1275.49C301.288,1282.86 285.488,1288.94 272.029,1297.66C268.1,1300.38 265.138,1303.9 262.925,1308.57ZM260.204,1307.3L262.925,1308.57L260.204,1307.3Z" style="fill:#305b8e;fill-rule:nonzero;"/></g><g><path d="M328.104,1422.74C314.513,1423.53 301.25,1418.05 291.317,1408.42C280.158,1397.6 281.575,1378.06 294.225,1368.35L338.15,1334.6C340.146,1333.07 342.288,1331.77 344.529,1330.73L346.363,1329.87C357.2,1324.82 369.55,1326.86 378.067,1335.12C390.737,1347.4 390.817,1369.05 378.246,1382.4C345.317,1417.39 340.05,1422.05 328.104,1422.74Z" style="fill:#fffdfe;fill-rule:nonzero;"/><path d="M328.079,1421.12C328.096,1422.2 328.113,1423.28 328.133,1424.36C333.104,1424.6 338.708,1423.07 343.175,1420.15C357.7,1410.26 369.013,1397.53 380.975,1385.4C383.738,1382.51 386.071,1379.12 387.813,1375.42C394.829,1361 391.813,1342.22 380.75,1331.92C371.388,1322.73 356.817,1320.42 344.988,1326.19C344.379,1326.48 343.767,1326.77 343.158,1327.06C340.675,1328.24 338.304,1329.7 336.1,1331.42C321.546,1342.8 307.017,1354.23 292.513,1365.69C278.629,1375.94 277.4,1399.63 289.717,1410.33C296.417,1416.58 304.521,1421.06 313.204,1423.17C318.071,1424.35 323.121,1424.77 328.133,1424.36C328.113,1423.28 328.096,1422.2 328.079,1421.12C323.367,1421.28 318.679,1420.65 314.196,1419.34C306.2,1417.01 298.867,1412.52 292.921,1406.51C283.167,1397.28 285.017,1378.52 295.933,1371C310.717,1359.97 325.471,1348.9 340.2,1337.78C341.988,1336.44 343.9,1335.3 345.896,1334.39C346.513,1334.11 347.125,1333.83 347.738,1333.55C357.025,1329.21 368.242,1331.17 375.383,1338.31C383.833,1346.3 386.05,1360.7 380.696,1371.73C379.363,1374.55 377.613,1377.15 375.517,1379.42C363.871,1391.71 352.946,1405.39 340.688,1415.81C336.925,1418.83 332.85,1420.59 328.079,1421.12ZM328.133,1424.36L328.079,1421.12L328.133,1424.36Z" style="fill:#305b8e;fill-rule:nonzero;"/></g><path d="M711.713,1458.08C747.688,1455.87 809.992,1457.75 856.742,1478.58C909.054,1501.89 925.242,1553.07 923.642,1598.85C922.838,1621.83 917.596,1644.07 909.825,1661.91C902.333,1679.11 891.771,1693.83 879.096,1699.86C854.104,1714.53 811.375,1725.48 766.158,1725.55C720.675,1725.62 671.125,1714.7 633.692,1683.8L633.125,1683.34L632.646,1682.78C620.563,1668.67 613.888,1650.15 610.879,1630.65C607.863,1611.08 608.446,1589.94 611.367,1569.93C614.288,1549.91 619.596,1530.72 626.258,1514.99C632.767,1499.62 641.092,1486.32 650.754,1479.54C655.996,1475.87 662.242,1470.65 671.433,1466.54C680.825,1462.33 693.125,1459.23 711.713,1458.08Z" style="fill:url(#_Radial8);fill-rule:nonzero;stroke:#305b8e;stroke-width:16.67px;"/><path d="M550.533,1464.24C551.946,1455.97 559.367,1450 567.758,1450.07C635.583,1450.63 900.433,1446.95 994.996,1446.65C1003.64,1446.62 1010.85,1453.31 1011.57,1461.98C1018.13,1541.24 1007.27,1582.92 956.592,1621.83C874.358,1667.99 709.946,1715.16 591.271,1606.42C543.983,1549.31 536.979,1543.53 550.533,1464.24Z" style="fill:url(#_Linear9);fill-rule:nonzero;"/><path d="M1014.68,1461.79C1012.6,1461.92 1010.53,1462.04 1008.46,1462.17C1009.4,1482.19 1009.65,1502.23 1007.37,1521.69C1004,1560.69 983.213,1593.91 951.979,1615.83L952.842,1615.27C918.225,1633.89 880.642,1647.6 842.083,1656.11C757.542,1675.72 661.567,1661.99 596.492,1600.65L597.263,1601.46C580.925,1581.12 561.433,1561.8 554.704,1539.63C548.379,1517.2 553.783,1490.91 557.592,1465.61C558.208,1461 562.942,1457.03 567.854,1457.12C698.6,1456.35 829.108,1453.02 959.742,1450.65C971.6,1450.44 983.279,1450.23 995.083,1450.06C1001.67,1449.79 1007.95,1455.39 1008.46,1462.17C1010.53,1462.04 1012.6,1461.92 1014.68,1461.79C1014.21,1451.86 1004.96,1443.05 994.913,1443.24C983.087,1443.14 971.392,1443.09 959.521,1443.05C828.817,1442.58 697.983,1443.74 567.663,1443.01C556.204,1442.76 545.433,1451.2 543.475,1462.88C539.546,1488.57 532.813,1514.81 540.217,1543.57C549.146,1572.13 569.283,1590.81 585.283,1611.39C585.425,1611.56 585.883,1612.05 586.054,1612.2C654.992,1678.23 758.267,1692.99 845.963,1672.44C886.15,1663.56 924.833,1648.82 960.338,1628.4C960.521,1628.29 961.038,1627.95 961.204,1627.83C993.846,1604.01 1016.48,1563.66 1017.31,1522.81C1018.55,1502.28 1017,1481.92 1014.68,1461.79ZM1008.46,1462.17L1014.68,1461.79L1008.46,1462.17Z" style="fill:#305b8e;fill-rule:nonzero;"/><path d="M745.538,1527C740.633,1557.98 737.717,1625.03 741.246,1661.91" style="fill:none;fill-rule:nonzero;stroke:#305b8e;stroke-width:12.5px;stroke-linecap:round;stroke-linejoin:round;"/><g><path d="M548.904,1070.6C575.879,1050.68 597.433,1027.44 679.425,1021.02C760.938,1014.64 899.75,1017.39 1001.85,1063.7C1220,1162.66 1137.72,1510.59 1045.03,1555.85C940.4,1621.43 680.963,1662.25 519.333,1539.18C509.462,1531.67 500.604,1522.83 493.942,1512.37C413.825,1386.58 480.413,1121.2 548.904,1070.6Z" style="fill:#fffdfe;fill-rule:nonzero;"/></g><path d="M1003.16,1060.86C1002.29,1062.76 1001.41,1064.65 1000.54,1066.55C1031.83,1081.42 1059.32,1103.21 1080.05,1130.31C1160.86,1242.29 1145.26,1406.23 1073.42,1519.02C1064.4,1531.17 1053.67,1542.33 1041.42,1548.38C1041.26,1548.45 1040.8,1548.71 1040.64,1548.81C883.521,1632.04 670.767,1638.91 523.963,1533.14C514.633,1526.08 506.367,1517.84 500.271,1508.32C432.171,1375.84 459.5,1189.83 552.313,1075.23C588.004,1042.72 632.654,1029.28 679.779,1026.07C753.496,1020.3 828.404,1022.66 901.042,1036.42C935.179,1043.05 968.879,1052.48 1000.54,1066.55C1001.41,1064.65 1002.29,1062.76 1003.16,1060.86C971.125,1046.11 937.067,1036.12 902.596,1028.98C829.217,1014.15 753.779,1010.92 679.071,1015.97C631.821,1018.24 580.971,1033.68 545.5,1065.98C443.871,1190.52 416.587,1371.57 487.617,1516.42C494.829,1527.81 504.363,1537.31 514.704,1545.22C669,1656.25 883.754,1649.96 1049.42,1562.89L1048.64,1563.32C1064.96,1555.15 1076.77,1542.22 1086.8,1528.85C1163.6,1407.7 1176.04,1239.71 1087.9,1124.05C1065.33,1096.4 1035.83,1074.81 1003.16,1060.86ZM1000.54,1066.55L1003.16,1060.86L1000.54,1066.55Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M553.263,1068.57C580.233,1048.64 601.792,1025.41 683.779,1018.99C765.292,1012.6 904.104,1015.36 1006.2,1061.67C1224.35,1160.63 1142.08,1508.55 1049.38,1553.81C944.758,1619.4 685.317,1660.22 523.688,1537.15C513.817,1529.63 504.963,1520.8 498.3,1510.34C418.179,1384.54 484.771,1119.17 553.263,1068.57Z" style="fill:#fffdfe;fill-rule:nonzero;"/></g><path d="M1007.52,1058.83C1006.64,1060.72 1005.77,1062.62 1004.89,1064.52C1036.18,1079.39 1063.68,1101.18 1084.4,1128.28C1165.22,1240.25 1149.61,1404.19 1077.78,1516.98C1068.75,1529.13 1058.03,1540.3 1045.78,1546.34C1045.62,1546.42 1045.15,1546.68 1045,1546.78C887.875,1630 675.121,1636.88 528.317,1531.11C518.987,1524.05 510.721,1515.8 504.625,1506.29C436.525,1373.8 463.854,1187.8 556.667,1073.2C592.358,1040.69 637.008,1027.25 684.133,1024.04C757.85,1018.27 832.758,1020.62 905.4,1034.39C939.533,1041.01 973.233,1050.45 1004.89,1064.52C1005.77,1062.62 1006.64,1060.72 1007.52,1058.83C975.479,1044.08 941.421,1034.08 906.95,1026.95C833.571,1012.11 758.138,1008.88 683.425,1013.94C636.179,1016.2 585.325,1031.65 549.854,1063.95C448.229,1188.49 420.942,1369.53 491.971,1514.39C499.183,1525.78 508.717,1535.27 519.058,1543.18C673.354,1654.22 888.108,1647.92 1053.77,1560.85L1053,1561.29C1069.32,1553.11 1081.12,1540.18 1091.15,1526.82C1167.96,1405.67 1180.39,1237.67 1092.26,1122.02C1069.68,1094.37 1040.19,1072.78 1007.52,1058.83ZM1004.89,1064.52L1007.52,1058.83L1004.89,1064.52Z" style="fill:#305b8e;fill-rule:nonzero;"/><path d="M692.979,1019.3C765.613,1013.84 838.913,1016.48 910.108,1030.47C943.775,1037.25 977.008,1046.86 1008.2,1061.17C1040.03,1074.69 1068.63,1095.75 1090.4,1122.74C1175.15,1235.67 1161.9,1398.98 1087.38,1518.62C1077.32,1532.32 1065.48,1545.7 1048.87,1554.19L1049.65,1553.75C888.133,1640.3 678.533,1647.98 529.338,1540.35C519.05,1532.47 509.596,1522.98 502.529,1511.57C435.292,1370.48 462.133,1194.95 560.529,1071.77C561.829,1070.14 563.258,1068.61 564.821,1067.23C599.333,1036.8 647.892,1021.77 692.979,1019.3ZM835.213,1064.23C778.088,1052.75 719.204,1050.69 660.888,1055.44C624.088,1057.53 584.196,1071.07 556.663,1096.42C555.138,1097.82 553.763,1099.38 552.513,1101.03C471.867,1207.6 450.933,1352.36 502.158,1473.85C508.75,1485.72 518.075,1495.58 528.354,1503.65C557.925,1525.67 590.608,1541.82 625.013,1552.55C661.75,1564 689.333,1512.34 673.233,1477.53C649.667,1426.6 633.429,1366.16 634.213,1315.26C644.533,1196.34 703.846,1172.16 763.813,1171.25C823.225,1170.35 855.529,1146.28 974.604,1439.06C976.592,1443.93 982.288,1447.3 987.571,1447.74C993.817,1448.25 999.142,1444.92 1001.58,1439.11C1041.94,1342.9 1043.8,1228.63 983.671,1143.46C966.138,1120.5 942.783,1102.26 916.433,1090.65C890.729,1078.25 863.163,1069.98 835.213,1064.23Z" style="fill:url(#_Radial10);"/><g><path d="M909.479,1280.3L1026.22,1291.01C1047.53,1290.79 1031.97,1290.95 1045.44,1290.81C1065.7,1290.59 1079.57,1279.31 1108.49,1269.14" style="fill:none;fill-rule:nonzero;stroke:url(#_Linear11);stroke-width:5px;stroke-linecap:round;"/></g><g><path d="M612.588,1234.83L499.438,1201.98C479.567,1193.84 494.079,1199.78 481.513,1194.64" style="fill:none;fill-rule:nonzero;stroke:url(#_Linear12);stroke-width:5px;stroke-linecap:round;"/></g><g><path d="M870.908,1497.86C901.233,1519.2 930.704,1541.44 964.071,1556.8C982.642,1565.35 1020.74,1566.05 1052.24,1558.58" style="fill:none;fill-rule:nonzero;stroke:url(#_Linear13);stroke-width:5px;stroke-linecap:round;"/></g><g><path d="M594.667,1457.69C561.217,1472.99 524.829,1489.38 488.171,1482.04" style="fill:none;fill-rule:nonzero;stroke:url(#_Linear14);stroke-width:5px;stroke-linecap:round;"/></g><path d="M1007.52,1058.83C1006.64,1060.72 1005.77,1062.62 1004.89,1064.52C1036.18,1079.39 1063.68,1101.18 1084.4,1128.28C1165.22,1240.25 1149.61,1404.19 1077.78,1516.98C1068.75,1529.13 1058.03,1540.3 1045.78,1546.34C1045.62,1546.42 1045.15,1546.68 1045,1546.78C887.875,1630 675.121,1636.88 528.317,1531.11C518.987,1524.05 510.721,1515.8 504.625,1506.29C436.525,1373.8 463.854,1187.8 556.667,1073.2C592.358,1040.69 637.008,1027.25 684.133,1024.04C757.85,1018.27 832.758,1020.62 905.4,1034.39C939.533,1041.01 973.233,1050.45 1004.89,1064.52C1005.77,1062.62 1006.64,1060.72 1007.52,1058.83C975.479,1044.08 941.421,1034.08 906.95,1026.95C833.571,1012.11 758.138,1008.88 683.425,1013.94C636.179,1016.2 585.325,1031.65 549.854,1063.95C448.229,1188.49 420.942,1369.53 491.971,1514.39C499.183,1525.78 508.717,1535.27 519.058,1543.18C673.354,1654.22 888.108,1647.92 1053.77,1560.85L1053,1561.29C1069.32,1553.11 1081.12,1540.18 1091.15,1526.82C1167.96,1405.67 1180.39,1237.67 1092.26,1122.02C1069.68,1094.37 1040.19,1072.78 1007.52,1058.83ZM1004.89,1064.52L1007.52,1058.83L1004.89,1064.52Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M742.366,1155.75C821.264,1154.47 884.212,1219.58 882.848,1301.06C881.483,1382.54 816.32,1449.73 737.422,1451.01C658.524,1452.29 595.576,1387.17 596.941,1305.69C598.305,1224.21 663.468,1157.02 742.366,1155.75Z" style="fill:#c8d5e8;"/><path d="M742.021,1176.56C808.8,1175.48 863.183,1230.7 862,1301.4C860.817,1372.1 804.554,1429.1 737.775,1430.18C670.992,1431.27 616.604,1376.05 617.792,1305.35C618.975,1234.65 675.237,1177.65 742.021,1176.56Z" style="fill:none;fill-rule:nonzero;stroke:#c8d5e8;stroke-width:41.67px;"/></g><g><path d="M753.592,1187.42C812.992,1186.45 863.112,1238.35 861.963,1307.04C860.813,1375.73 808.929,1429.27 749.529,1430.23C690.133,1431.2 640.017,1379.3 641.167,1310.62C642.317,1241.93 694.196,1188.38 753.592,1187.42Z" style="fill:none;fill-rule:nonzero;stroke:url(#_Radial15);stroke-width:41.67px;"/></g><path d="M753.171,1212.84C801.838,1212.05 840.858,1254.22 839.971,1307.39C839.079,1360.57 798.625,1404.02 749.958,1404.81C701.288,1405.6 662.267,1363.43 663.154,1310.26C664.046,1257.09 704.5,1213.63 753.171,1212.84Z" style="fill:url(#_Radial16);fill-rule:nonzero;stroke:#305b8e;stroke-width:4.17px;"/><g><path d="M796.404,1311.29C794.575,1309.2 789.038,1307.29 784.65,1307.66C785.367,1303 784.038,1298.66 780.85,1294.44L779.633,1293.05L778.342,1294.47C775.808,1297.27 774.146,1301.37 773.633,1305.31C773.367,1307.74 773.563,1310.59 774.592,1312.84C768.504,1315.19 763.708,1313.34 741.763,1308.66L707.888,1301.44C706.654,1306.97 705.271,1317.82 709.554,1327.81C710.029,1328.91 710.575,1330 711.188,1331.06C714.988,1337.65 721.604,1343.29 732.738,1345.67C749.725,1349.32 766.379,1342.13 780.313,1319.14C783.213,1319.81 790.796,1321.98 796.221,1314.64C796.342,1314.52 797.621,1312.68 797.621,1312.68L796.408,1311.29L796.404,1311.29ZM732.929,1291.78L723.404,1289.74L721.225,1300.42L730.75,1302.45L732.929,1291.78ZM745.238,1294.4L735.713,1292.37L733.533,1303.05L743.058,1305.08L745.238,1294.4ZM757.55,1297.03L748.021,1294.99L745.842,1305.67L755.371,1307.7L757.55,1297.03ZM769.858,1299.65L760.329,1297.62L758.15,1308.3L767.679,1310.33L769.858,1299.65ZM720.617,1289.15L711.096,1287.12L708.917,1297.8L718.442,1299.83L720.621,1289.15L720.617,1289.15ZM735.679,1278.29L726.154,1276.25L723.975,1286.93L733.5,1288.96L735.679,1278.29ZM747.992,1280.91L738.463,1278.88L736.283,1289.56L745.808,1291.59L747.992,1280.91ZM760.3,1283.54L750.771,1281.5L748.592,1292.18L758.121,1294.21L760.3,1283.54ZM763.05,1270.05L753.525,1268.02L751.346,1278.7L760.871,1280.73L763.05,1270.05Z" style="fill:url(#_Linear17);fill-rule:nonzero;"/></g><path d="M944.288,572.213L801.783,563.375C803.629,533.608 829.254,510.975 859.021,512.821L893.733,514.975C923.5,516.821 946.133,542.446 944.288,572.213Z" style="fill:url(#_Radial18);fill-rule:nonzero;"/><path d="M944.096,575.329C944.225,573.25 944.354,571.171 944.483,569.092C938.75,568.042 933.013,567.058 927.271,566.146C904.304,562.496 881.271,559.954 858.167,558.521C839.546,557.367 820.917,556.292 802.283,555.296L809.858,563.875C810.525,539.479 833.5,518.125 858.596,519.617C870.183,520.087 881.775,520.521 893.367,520.929C913.504,521.258 932.908,535.783 938.929,555.979C940.517,561.121 941.279,566.546 941.171,572.017C943.25,572.146 945.329,572.275 947.408,572.404C948.021,566.308 947.65,560.079 946.267,554.029C941.175,530.333 919.246,510.833 894.104,509.021C882.55,507.992 870.996,506.992 859.442,506.025C827.208,502.563 795.204,529.767 793.704,562.875C793.463,567.446 796.708,571.208 801.283,571.45C819.896,572.767 838.513,574 857.138,575.154C880.238,576.588 903.413,576.913 926.65,576.125C932.463,575.929 938.275,575.667 944.096,575.329ZM944.483,569.092L944.096,575.329C945.858,575.229 947.367,574.171 947.408,572.404L941.171,572.017L944.483,569.092Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M951.967,273.405C975.85,293.435 978.978,329.086 958.948,352.969C938.917,376.852 903.266,379.98 879.383,359.95C855.5,339.92 852.372,304.268 872.402,280.385C892.433,256.502 928.084,253.375 951.967,273.405Z" style="fill:#fffdfe;"/></g><path d="M961.342,354.977C959.742,353.638 958.146,352.3 956.55,350.961C952.421,354.809 947.829,357.955 942.967,360.339C923.442,370.011 900.092,366.707 884.737,353.565C864.729,337.585 861.521,305.112 878.342,285.368C894.175,264.876 927.363,260.882 948.096,278.016C965,290.954 972.267,315.545 964.537,336.403C962.675,341.598 959.975,346.52 956.55,350.961C958.146,352.3 959.742,353.638 961.342,354.977C965.529,350.344 969.013,345.024 971.575,339.247C982.208,316.146 975.925,285.963 955.833,268.793C931.408,246.144 888.167,248.854 866.458,275.402C843.496,300.817 846.992,344.773 874.025,366.335C894.758,384.381 927.704,384.88 948.271,368.818C953.442,364.931 957.863,360.209 961.342,354.977ZM956.55,350.961L961.342,354.977L956.55,350.961Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M889.442,365.77C891.179,360.415 896.604,357.185 902.154,358.131C909.267,359.344 913.479,366.758 911.067,373.555C896.233,415.289 891.35,445.296 890.971,492.804C890.913,499.95 884.504,505.433 877.454,504.229C871.808,503.267 867.729,498.275 867.954,492.554C869.925,441.75 874.8,410.89 889.442,365.77Z" style="fill:#fffdfe;fill-rule:nonzero;"/></g><path d="M914.008,374.602C912.046,373.904 910.083,373.206 908.121,372.509C905.65,377.391 903.313,382.344 901.133,387.389C892.363,407.508 886.567,429.338 884.546,451.379C883.229,465.213 882.8,479.004 882.783,492.738C882.896,494.8 880.804,496.7 878.804,496.338C877.146,496.154 875.721,494.579 875.754,492.858C876.379,450.054 881.442,408.293 893.787,367.182C894.521,364.039 897.933,361.585 901.492,362.034C902.396,362.134 903.267,362.388 904.079,362.797C907.342,364.367 909.317,368.67 908.121,372.509C910.083,373.206 912.046,373.904 914.008,374.602C916.654,368.239 914.138,360.025 907.9,356.235C906.35,355.268 904.613,354.587 902.821,354.229C895.671,352.642 887.533,357.049 885.092,364.36C869.563,404.836 861.9,449.017 860.15,492.25C859.538,501.617 866.8,510.65 876.108,512.121C887.617,514.483 899.346,504.517 899.154,492.871C899.363,479.442 899.883,466.125 901.138,452.967C903.075,432.008 906.3,411.412 910.671,390.403C911.746,385.153 912.867,379.89 914.008,374.602ZM908.121,372.509L914.008,374.602L908.121,372.509Z" style="fill:#305b8e;fill-rule:nonzero;"/><path d="M901.579,510.371C881.654,502.208 868.083,502.867 845.367,510.3C845.675,498.908 855.154,489.921 866.546,490.225L881.192,490.617C892.083,490.908 900.942,499.492 901.579,510.371Z" style="fill:#305b8e;fill-rule:nonzero;"/><path d="M844.396,507.329C845.046,509.308 845.692,511.288 846.342,513.271C848.692,513.229 850.996,513.171 853.25,513.096C862.35,512.783 870.488,512.4 878.133,512.917C884.85,513.329 891.604,515.183 898.525,517.821C904.604,520.467 909.858,516.525 909.617,509.9C908.817,495.292 895.35,483.254 881.375,483.796C876.483,483.933 871.596,484.108 866.704,484.317C855.592,484.471 845.725,492.475 843.092,502.329C842.358,504.925 842.083,507.604 842.246,510.217C844.329,510.271 846.408,510.329 848.492,510.383C848.775,508.458 849.363,506.633 850.208,504.975C853.383,498.658 860.304,495.271 866.388,496.133C871.258,496.604 876.133,497.038 881.008,497.438C888.112,498.1 893.554,504.383 893.542,510.838L904.629,502.921C896.933,499.554 888.304,496.842 879.196,496.288C868.696,495.588 858.767,498.783 850.483,503.488C848.392,504.667 846.371,505.954 844.396,507.329ZM846.342,513.271L844.396,507.329L848.492,510.383L842.246,510.217C841.938,512.583 843.954,513.342 846.342,513.271Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M514.066,700.583C491.1,703.301 472.307,750.598 472.126,806.137C471.945,861.675 490.445,904.559 513.412,901.841C536.378,899.123 555.171,851.826 555.352,796.287C555.532,740.749 537.033,697.865 514.066,700.583Z" style="fill:url(#_Radial19);"/></g><path d="M472.125,806.138C472.658,813.833 473.521,821.442 474.746,828.913C477.208,843.808 481.008,858.4 487.046,871.421C492.742,883.908 502.917,897.529 513.429,895.633C526.517,892.867 535.629,870.842 540.171,853.467C544.971,835.046 546.908,816.025 546.996,797.275C547.029,778.533 545.213,759.954 540.533,742.658C536.1,726.342 527.121,706.458 514.046,706.792C503.533,707.383 493.263,723.425 487.483,737.271C481.354,751.733 477.458,767.233 474.896,782.725C473.621,790.492 472.708,798.308 472.125,806.138C471.592,798.442 471.45,790.646 471.738,782.792C472.342,767.117 474.488,751.088 479.533,735.2C485.063,720.342 491.267,699.95 514.083,694.375C542.721,694.517 548.921,719.458 555.604,736.608C561.475,755.446 563.729,775.263 563.704,795.3C563.596,815.342 561.213,835.708 555.217,855.954C548.417,874.696 542.05,901.125 513.388,908.05C490.592,907.875 484.513,888.933 479.075,875.375C474.129,860.671 472.087,845.138 471.583,829.592C471.35,821.8 471.542,813.967 472.125,806.138Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M512.896,731.033C520.258,626.625 602.558,541.767 707.179,538.754C837.254,535.017 936.95,542.983 1042.1,561.225C1144.65,579.017 1213.29,674.746 1205.97,778.571L1199.6,868.879C1191.8,979.446 1100.27,1066.36 989.463,1063.5C885.042,1060.81 792.45,1054.3 687.442,1042.16C577.308,1029.43 498.825,930.542 506.625,819.95L512.896,731.033Z" style="fill:#fffdfe;fill-rule:nonzero;"/></g><path d="M995.046,552.892C1008.43,554.767 1021.79,556.829 1035.11,559.067C1095.65,568.633 1147.2,610.338 1176.37,663.963C1196.93,701.038 1202.64,737.696 1199.58,779.917C1197.44,810.017 1200.89,857.358 1198.74,887.458C1193.37,998.038 1063.93,1071.78 987.808,1069.74C886.683,1067.04 790.217,1060.86 689.808,1048.75C630.288,1037.85 596.658,1014.87 569.292,991.575C608.258,969.867 634.854,980.492 682.646,984.963C792.55,995.242 866.175,990.438 959.208,993.275C1070.99,999.321 1139.94,963.283 1145.3,852.496C1146.65,833.467 1145.58,772.838 1146.94,753.808C1150.1,710.246 1140.08,665.775 1118.16,627.908C1098.41,593.163 1030.77,570.833 995.046,552.892Z" style="fill:#e6f1fd;fill-rule:nonzero;"/><path d="M707.088,535.633C707.146,537.717 707.204,539.796 707.267,541.879C741.396,541.592 775.513,541.983 809.521,543.325C887.217,546.258 964.421,554.892 1040.78,568.829C1096.54,578.492 1145.85,615.329 1172.85,664.829C1191.83,699.058 1200.48,738.892 1197.69,777.988C1195.58,808.092 1193.48,838.196 1191.38,868.3C1186.58,970.683 1092.93,1060.52 989.658,1055.79C888.913,1053.56 788.388,1046.73 688.221,1035.4C584.763,1026.22 502.954,923.896 512.038,820.329C513.979,790.679 515.913,761.029 517.842,731.379C521.621,667.213 557.175,605.242 612.142,571.071C640.504,553.208 673.629,543.013 707.267,541.879C707.204,539.796 707.146,537.717 707.088,535.633C672.363,536.329 637.85,546.425 608.15,564.613C550.592,599.388 512.65,663.517 507.95,730.683C505.696,760.313 503.45,789.938 501.212,819.567C490.471,928.35 575.917,1038.2 686.658,1048.92C787.067,1061.04 888.133,1068.51 989.263,1071.22C1100.83,1076.84 1202.44,980.038 1207.81,869.458C1209.96,839.358 1212.11,809.254 1214.25,779.154C1217.31,736.933 1207.99,693.838 1187.43,656.763C1158.26,603.137 1103.97,563.188 1043.42,553.621C966.225,540.637 887.942,533.733 809.75,533.329C775.517,533.092 741.267,533.954 707.088,535.633ZM707.267,541.879L707.088,535.633L707.267,541.879Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M595.762,763.104C599.178,706.048 642.865,660.162 697.797,657.986C811.919,653.462 898.079,657.959 1001.38,676.244C1054.98,685.733 1091.63,736.827 1088.26,793.261C1084.2,861.024 1024.75,909.734 959.997,901.137C878.793,890.351 804.471,885.266 708.686,885.496C644.18,885.655 591.756,830.064 595.762,763.104Z" style="fill:url(#_Linear20);fill-rule:nonzero;"/><path d="M699.338,657.538C811.863,653.25 897.046,657.517 999.142,674.892C1056.22,684.604 1094.92,736.829 1091.36,794.096C1087.07,863.117 1024.17,912.388 956.054,903.692C876.692,893.558 804.075,888.775 710.367,888.992C642.425,889.15 586.908,832.817 591.154,764.592C594.763,706.608 640.975,659.763 699.338,657.538Z" style="fill:none;fill-rule:nonzero;stroke:#305b8e;stroke-width:16.67px;"/></g><path d="M733.274,720.113C763.408,718.355 789.3,741.393 791.058,771.528C792.816,801.662 769.777,827.555 739.643,829.312C709.509,831.07 683.616,808.032 681.859,777.897C680.101,747.763 703.139,721.87 733.274,720.113Z" style="fill:url(#_Radial21);stroke:#305b8e;stroke-width:4.17px;"/><path d="M950.353,730.079C980.487,728.322 1006.38,751.36 1008.14,781.495C1009.89,811.629 986.857,837.521 956.722,839.279C926.588,841.037 900.695,817.998 898.938,787.864C897.18,757.729 920.218,731.837 950.353,730.079Z" style="fill:url(#_Radial22);stroke:#305b8e;stroke-width:4.17px;"/><g><path d="M1228.78,731.863C1261.66,734.426 1284.81,781.931 1280.45,837.881C1276.09,893.831 1245.85,937.174 1212.98,934.612C1180.1,932.049 1156.95,884.544 1161.31,828.594C1165.67,772.644 1195.9,729.301 1228.78,731.863Z" style="fill:url(#_Radial23);"/></g><path d="M1280.45,837.879C1279.23,846.417 1277.41,854.817 1274.99,862.983C1265.89,894.125 1243.84,930.708 1213.46,928.379C1176.28,920.542 1166.65,867.675 1169.62,829.242C1172.65,790.808 1190.35,740.075 1228.3,738.092C1258.67,740.496 1274.78,780.058 1278.95,812.229C1280.07,820.675 1280.56,829.254 1280.45,837.879C1281.67,829.342 1282.25,820.683 1282.1,811.996C1280.88,779.367 1272.16,734.138 1229.27,725.629C1173.88,727.596 1157.24,786.338 1153,827.946C1150.74,869.708 1158.08,930.317 1212.49,940.842C1256.19,939.083 1271.8,895.75 1278.08,863.704C1279.56,855.146 1280.33,846.504 1280.45,837.879Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M1291.34,840.858C1288.33,876.471 1270.16,904.004 1250.77,902.363C1231.38,900.721 1218.11,870.525 1221.12,834.913C1224.14,799.304 1242.3,771.767 1261.69,773.408C1281.08,775.05 1294.35,805.25 1291.34,840.858Z" style="fill:url(#_Linear24);fill-rule:nonzero;"/></g><path d="M1044.54,1287.5L1082.17,1293.75C1082.17,1293.75 1125.01,1285.7 1132.04,1333.33C1139.06,1380.97 1149.57,1412.51 1111.2,1487.5C1102.07,1390.17 1063.29,1331.25 1044.54,1287.5Z" style="fill:url(#_Linear25);fill-rule:nonzero;"/><path d="M1239.62,1209.18L1141.05,1127.84C1112.57,1104.33 1072.41,1090.6 1054.59,1122.95C1023.05,1180.21 1020.66,1304.48 1141.26,1398.41C1184.76,1432.28 1225.27,1433.2 1259.51,1417.91C1342.44,1380.86 1309.68,1267 1239.62,1209.18Z" style="fill:#fffdfe;fill-rule:nonzero;stroke:#305b8e;stroke-width:16.67px;"/><path d="M1285.96,1372.73C1243.55,1391.98 1102.5,1386.6 1044.72,1198.64C1042.96,1333.9 1160.99,1400.5 1165.72,1403.6C1207.99,1431.26 1269.44,1420.82 1285.96,1372.73Z" style="fill:url(#_Linear26);fill-rule:nonzero;"/><g><path d="M1512.5,927.425C1515.58,929.867 1516.72,934.254 1515.25,937.971L1489.38,1003.57C1488.58,1005.59 1487.1,1007.18 1485.23,1008.01L1463.81,1017.53C1459.97,1019.24 1454.81,1019.76 1452.46,1023.47L1336.77,1206.64C1334.27,1210.6 1329.21,1211.46 1325.55,1208.55L1310.3,1196.42C1306.64,1193.52 1305.82,1187.98 1308.46,1184.15L1431.1,1006.51C1433.59,1002.9 1432.42,997.371 1432.7,992.825C1432.7,992.775 1432.7,992.729 1432.71,992.683L1434.58,967.917C1434.75,965.629 1435.75,963.533 1437.37,962.092L1488.65,916.4C1491.42,913.929 1495.44,913.854 1498.41,916.217L1512.5,927.425Z" style="fill:#c8d5e8;"/></g><g><path d="M1369.09,1243.16C1361.96,1253.94 1347.99,1256.19 1337.91,1248.17L1272.91,1196.5C1262.84,1188.49 1260.44,1173.23 1267.58,1162.45C1274.71,1151.67 1288.68,1149.43 1298.76,1157.44L1363.75,1209.12C1373.83,1217.13 1376.22,1232.39 1369.09,1243.16Z" style="fill:#4079bd;"/></g><path d="M1367.45,1241.87C1360.96,1251.69 1348.23,1253.73 1339.05,1246.43L1274.07,1194.77C1264.88,1187.46 1262.71,1173.57 1269.2,1163.75C1275.7,1153.93 1288.43,1151.88 1297.61,1159.18L1362.59,1210.85C1371.77,1218.15 1373.95,1232.05 1367.45,1241.87Z" style="fill:none;stroke:#305b8e;stroke-width:4.34px;"/><path d="M1289.83,1176.41L1350.08,1224.32C1350.97,1225.03 1351.18,1226.37 1350.55,1227.32C1349.92,1228.27 1348.69,1228.47 1347.8,1227.76L1287.55,1179.85C1286.65,1179.14 1286.44,1177.8 1287.07,1176.85C1287.7,1175.9 1288.93,1175.7 1289.83,1176.41Z" style="fill:none;fill-rule:nonzero;stroke:#305b8e;stroke-width:4.15px;"/><g><path d="M1147.4,1422.62C1125.1,1404.47 1120.92,1370.08 1138.24,1347.39L1243.17,1209.9C1253.74,1196.05 1272.61,1193.77 1286.33,1204.67L1323.01,1233.84C1336.71,1244.73 1340.62,1265.07 1331.95,1280.4L1245.58,1433.15C1231.11,1458.74 1199.28,1464.85 1176.6,1446.38L1147.4,1422.62Z" style="fill:#4079bd;fill-rule:nonzero;"/></g><path d="M1148.56,1420.89C1127.2,1403.5 1123.19,1370.55 1139.79,1348.8L1244.72,1211.32C1254.63,1198.33 1272.32,1196.19 1285.18,1206.41L1321.86,1235.57C1334.71,1245.79 1338.37,1264.85 1330.24,1279.23L1243.87,1431.98C1230,1456.5 1199.5,1462.36 1177.76,1444.66L1148.56,1420.89Z" style="fill:none;fill-rule:nonzero;stroke:#305b8e;stroke-width:4.17px;"/><path d="M1266,1222.65C1267.67,1224.14 1267.96,1226.79 1266.64,1228.57L1155.61,1378.88C1154.29,1380.67 1151.87,1380.9 1150.2,1379.42C1148.53,1377.94 1148.23,1375.29 1149.55,1373.5L1260.58,1223.2C1261.9,1221.41 1264.33,1221.17 1266,1222.65Z" style="fill:#305b8e;fill-rule:nonzero;"/><path d="M1283.12,1236.13C1284.83,1237.57 1285.19,1240.2 1283.92,1242.03L1176.8,1395.71C1175.53,1397.53 1173.11,1397.85 1171.4,1396.42C1169.69,1394.98 1169.33,1392.35 1170.6,1390.53L1277.73,1236.84C1278.99,1235.02 1281.41,1234.7 1283.12,1236.13Z" style="fill:#305b8e;fill-rule:nonzero;"/><path d="M1297.81,1247.85C1299.6,1249.17 1300.1,1251.78 1298.92,1253.68L1200.38,1414.11C1199.21,1416.02 1196.82,1416.49 1195.03,1415.17C1193.25,1413.85 1192.75,1411.25 1193.92,1409.34L1292.46,1248.91C1293.63,1247.01 1296.03,1246.53 1297.81,1247.85Z" style="fill:#305b8e;fill-rule:nonzero;"/><path d="M1312.31,1259.87C1314.17,1261.07 1314.81,1263.64 1313.75,1265.62L1224.13,1432.22C1223.07,1434.2 1220.7,1434.83 1218.85,1433.63C1217,1432.43 1216.36,1429.85 1217.42,1427.88L1307.03,1261.28C1308.1,1259.3 1310.46,1258.67 1312.31,1259.87Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M1224.18,1190.35C1233.94,1182.46 1247.49,1183.78 1257.83,1191.48C1273.04,1202.8 1277.28,1225.05 1267.3,1241.17L1239.31,1286.36C1230.02,1301.37 1211,1304.99 1196.84,1294.45C1185.67,1286.14 1180.39,1271.05 1184.59,1257.48C1194.9,1224.17 1205.8,1205.18 1224.18,1190.35Z" style="fill:#fffdfe;fill-rule:nonzero;"/></g><path d="M1268.55,1242.1C1267.71,1241.48 1266.88,1240.86 1266.04,1240.24C1263.01,1244.48 1260,1248.75 1257.03,1253.03C1249.92,1263.25 1242.98,1273.58 1236.19,1284.03C1232.14,1290.28 1225.82,1294.53 1218.88,1295.76C1212.08,1297.02 1204.82,1295.27 1199.02,1290.93C1189.49,1284.08 1184.57,1270.31 1188.2,1258.9C1195.81,1233.5 1206.36,1208.71 1226.06,1193.03C1234.29,1185.93 1247.16,1186.89 1256.45,1193.7C1266.13,1200.47 1271.91,1213.42 1270.65,1225.88C1270.17,1230.97 1268.59,1235.92 1266.04,1240.24C1266.88,1240.86 1267.71,1241.48 1268.55,1242.1C1271.53,1237.53 1273.52,1232.14 1274.26,1226.48C1276.22,1212.69 1270.25,1197.54 1259.21,1189.25C1248.78,1181.02 1233.2,1178.9 1222.3,1187.67C1200.84,1203.73 1188.95,1230.4 1180.98,1256.06C1176.03,1271.04 1182.38,1289.07 1194.66,1297.97C1202.13,1303.61 1211.64,1305.94 1220.44,1304.3C1229.44,1302.72 1237.63,1296.89 1242.44,1288.68C1248.79,1277.91 1254.99,1267.02 1261.03,1256.01C1263.57,1251.4 1266.07,1246.76 1268.55,1242.1ZM1266.04,1240.24L1268.55,1242.1L1266.04,1240.24Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M1320.1,1341.67C1324.27,1355.53 1323.1,1370.82 1317.34,1383.87C1310.88,1398.53 1293.54,1402.62 1281.94,1392.21L1239.77,1354.38C1237.92,1352.72 1236.24,1350.86 1234.75,1348.82L1233.01,1346.45C1225.91,1336.74 1224.51,1323.47 1229.41,1312.36C1236.78,1295.64 1255.68,1289.43 1270.45,1298.86C1311.05,1324.77 1316.24,1328.83 1320.1,1341.67Z" style="fill:#fffdfe;fill-rule:nonzero;"/></g><path d="M1318.68,1342.17C1319.63,1341.84 1320.57,1341.51 1321.52,1341.18C1320.42,1335.88 1317.75,1330.36 1314.05,1326.39C1301.26,1313.32 1286.63,1304.7 1272.41,1295.14C1269.64,1293.34 1266.63,1291.98 1263.5,1291.14C1248.77,1286.95 1232.18,1295.42 1225.9,1310.48C1220.4,1322.75 1222.15,1338.41 1230.14,1348.96C1230.72,1349.75 1231.3,1350.53 1231.89,1351.32C1233.55,1353.57 1235.44,1355.62 1237.49,1357.43C1251.65,1369.91 1265.83,1382.35 1280.05,1394.74C1292.44,1406.3 1313.36,1400.83 1319.42,1384.99C1323.06,1376.35 1324.79,1366.78 1324.38,1357.31C1324.15,1351.82 1323.19,1346.35 1321.52,1341.18C1320.57,1341.51 1319.63,1341.84 1318.68,1342.17C1320.05,1347.11 1320.74,1352.25 1320.76,1357.38C1320.8,1366.21 1318.86,1374.98 1315.26,1382.75C1309.81,1395.49 1293.07,1398.89 1283.83,1389.68C1269.93,1376.85 1256,1364.07 1242.04,1351.32C1240.41,1349.83 1238.92,1348.15 1237.61,1346.33C1237.04,1345.53 1236.47,1344.73 1235.89,1343.94C1229.81,1335.64 1228.63,1323.6 1232.91,1314.25C1237.8,1302.78 1250.49,1296.41 1261.67,1299.59C1264.05,1300.23 1266.35,1301.24 1268.49,1302.58C1282.75,1311.8 1298.15,1319.76 1310.82,1330.2C1314.42,1333.37 1316.95,1337.26 1318.68,1342.17ZM1321.52,1341.18L1318.68,1342.17L1321.52,1341.18Z" style="fill:#305b8e;fill-rule:nonzero;"/><g><path d="M1243.02,1447.86C1256.29,1450.11 1269.9,1446.26 1280.7,1437.85C1292.82,1428.41 1293.48,1408.92 1282.06,1398L1241.23,1358.96C1239.42,1357.23 1237.45,1355.71 1235.35,1354.43L1233.18,1353.1C1223.12,1346.97 1210.84,1347.62 1201.63,1354.8C1187.83,1365.55 1185.5,1387.04 1196.54,1401.56C1226.35,1440.76 1230.98,1445.81 1243.02,1447.86Z" style="fill:#fffdfe;fill-rule:nonzero;"/></g><path d="M1243.23,1446.25C1243.09,1447.32 1242.95,1448.4 1242.82,1449.47C1237.87,1449.15 1232.45,1447.11 1228.28,1443.74C1214.53,1432.14 1204.4,1417.92 1193.53,1404.27C1191.3,1401.39 1189.48,1398.13 1188.16,1394.65C1182.17,1379.44 1187.02,1360.49 1199.33,1351.32C1209.48,1343.3 1223.98,1342.63 1234.94,1349.59C1235.66,1350.03 1236.38,1350.48 1237.1,1350.93C1239.42,1352.37 1241.6,1354.08 1243.6,1356.01C1257.1,1369.15 1270.58,1382.33 1284.02,1395.55C1296.62,1407.14 1295.32,1430.72 1282.07,1439.92C1274.86,1445.33 1266.48,1448.8 1257.8,1449.92C1252.83,1450.57 1247.76,1450.43 1242.82,1449.47C1242.95,1448.4 1243.09,1447.32 1243.23,1446.25C1247.89,1446.92 1252.62,1446.82 1257.23,1446C1265.26,1444.59 1272.89,1441.01 1279.32,1435.78C1289.89,1427.75 1290.04,1409.01 1280.1,1400.45C1266.33,1387.65 1252.59,1374.8 1238.88,1361.92C1237.25,1360.39 1235.48,1359.05 1233.6,1357.93C1232.88,1357.49 1232.15,1357.06 1231.42,1356.62C1222.82,1351.36 1211.67,1352.06 1203.94,1358.28C1194.56,1365.39 1190.96,1379.89 1195.51,1391.47C1196.51,1394.12 1197.88,1396.6 1199.55,1398.85C1210.12,1412.61 1219.78,1427.76 1231.17,1439.65C1234.61,1443.05 1238.52,1445.18 1243.23,1446.25ZM1242.82,1449.47L1243.23,1446.25L1242.82,1449.47Z" style="fill:#305b8e;fill-rule:nonzero;"/><defs><linearGradient id="_Linear1" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-1593.52,787.45,-787.45,-1593.52,2393.93,513.938)"><stop offset="0" style="stop-color:#90bcfb;stop-opacity:1"/><stop offset="1" style="stop-color:#90bcfb;stop-opacity:0"/></linearGradient><linearGradient id="_Linear2" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-1609.52,738.04,-738.04,-1609.52,2837.71,364.468)"><stop offset="0" style="stop-color:#90bcfb;stop-opacity:1"/><stop offset="1" style="stop-color:#90bcfb;stop-opacity:0"/></linearGradient><linearGradient id="_Linear3" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-1975.05,905.66,-905.66,-1975.05,3276.17,203.453)"><stop offset="0" style="stop-color:#90bcfb;stop-opacity:1"/><stop offset="1" style="stop-color:#90bcfb;stop-opacity:0"/></linearGradient><linearGradient id="_Linear4" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(2.65989e-14,-434.393,434.393,2.65989e-14,141.559,729.146)"><stop offset="0" style="stop-color:#f8f9ff;stop-opacity:1"/><stop offset="1" style="stop-color:#edf5ff;stop-opacity:1"/></linearGradient><linearGradient id="_Linear5" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(2.72189e-14,444.519,-444.519,2.72189e-14,1333.23,111.494)"><stop offset="0" style="stop-color:#f8f9ff;stop-opacity:1"/><stop offset="1" style="stop-color:#edf5ff;stop-opacity:1"/></linearGradient><linearGradient id="_Linear6" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(2.65991e-14,434.396,-434.396,2.65991e-14,1706.43,1486.35)"><stop offset="0" style="stop-color:#f8f9ff;stop-opacity:1"/><stop offset="1" style="stop-color:#edf5ff;stop-opacity:1"/></linearGradient><linearGradient id="_Linear7" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-28.05,-23.0875,23.0875,-28.05,522.204,1269.06)"><stop offset="0" style="stop-color:#fffdfe;stop-opacity:1"/><stop offset="1" style="stop-color:#b9d9f4;stop-opacity:1"/></linearGradient><radialGradient id="_Radial8" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-90.1721,-153.758,178.9,-70.5713,842.879,1691.75)"><stop offset="0" style="stop-color:#e3f2fd;stop-opacity:1"/><stop offset="0.05" style="stop-color:#e3f2fd;stop-opacity:1"/><stop offset="0.41" style="stop-color:#bbdefb;stop-opacity:1"/><stop offset="0.79" style="stop-color:#90caf9;stop-opacity:1"/><stop offset="1" style="stop-color:#2196f3;stop-opacity:1"/></radialGradient><linearGradient id="_Linear9" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(21.3375,261.221,-261.221,21.3375,748.104,1412.63)"><stop offset="0" style="stop-color:#203b64;stop-opacity:1"/><stop offset="1" style="stop-color:#4372b2;stop-opacity:1"/></linearGradient><radialGradient id="_Radial10" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="matrix(218.725,383.149,-433.533,193.941,782.179,1250.54)"><stop offset="0" style="stop-color:#f6fbff;stop-opacity:1"/><stop offset="0.06" style="stop-color:#f6fbff;stop-opacity:1"/><stop offset="0.13" style="stop-color:#fff;stop-opacity:1"/><stop offset="0.2" style="stop-color:#edf6fd;stop-opacity:1"/><stop offset="1" style="stop-color:#95c4ed;stop-opacity:1"/></radialGradient><linearGradient id="_Linear11" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(1.075,21.8792,-21.8792,1.075,992.071,1270.09)"><stop offset="0" style="stop-color:#203b64;stop-opacity:1"/><stop offset="1" style="stop-color:#4372b2;stop-opacity:1"/></linearGradient><linearGradient id="_Linear12" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-5.34167,11.8917,-11.8917,-5.34167,560.021,1213.11)"><stop offset="0" style="stop-color:#203b64;stop-opacity:1"/><stop offset="1" style="stop-color:#4372b2;stop-opacity:1"/></linearGradient><linearGradient id="_Linear13" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-13.125,34.4667,-34.4667,-13.125,950.738,1511.33)"><stop offset="0" style="stop-color:#203b64;stop-opacity:1"/><stop offset="1" style="stop-color:#4372b2;stop-opacity:1"/></linearGradient><linearGradient id="_Linear14" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(0.604167,19.0958,-19.0958,0.604167,550.133,1461.63)"><stop offset="0" style="stop-color:#203b64;stop-opacity:1"/><stop offset="1" style="stop-color:#4372b2;stop-opacity:1"/></linearGradient><radialGradient id="_Radial15" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="matrix(486.021,311.524,-303.734,537.271,682.596,1252.9)"><stop offset="0" style="stop-color:#fff;stop-opacity:1"/><stop offset="1" style="stop-color:#d0dff0;stop-opacity:1"/></radialGradient><radialGradient id="_Radial16" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-392.095,-386.632,369.973,-437.921,868.325,1434.1)"><stop offset="0" style="stop-color:#2196f3;stop-opacity:1"/><stop offset="0.16" style="stop-color:#2196f3;stop-opacity:1"/><stop offset="0.55" style="stop-color:#90caf9;stop-opacity:1"/><stop offset="0.59" style="stop-color:#bbdefb;stop-opacity:1"/><stop offset="0.95" style="stop-color:#e3f2fd;stop-opacity:1"/><stop offset="1" style="stop-color:#e3f2fd;stop-opacity:1"/></radialGradient><linearGradient id="_Linear17" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(234.804,243.417,-243.417,234.804,698.117,1246.45)"><stop offset="0" style="stop-color:#fff;stop-opacity:1"/><stop offset="0.07" style="stop-color:#fff;stop-opacity:1"/><stop offset="1" style="stop-color:#69e7fc;stop-opacity:1"/></linearGradient><radialGradient id="_Radial18" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-49.9088,-36.2205,88.4721,-14.2387,880.746,547.296)"><stop offset="0" style="stop-color:#f6fbff;stop-opacity:1"/><stop offset="0.06" style="stop-color:#f6fbff;stop-opacity:1"/><stop offset="0.13" style="stop-color:#fff;stop-opacity:1"/><stop offset="0.2" style="stop-color:#edf6fd;stop-opacity:1"/><stop offset="1" style="stop-color:#95c4ed;stop-opacity:1"/></radialGradient><radialGradient id="_Radial19" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-30.7434,126.817,50.7188,67.344,517.558,778.171)"><stop offset="0" style="stop-color:#f6fbff;stop-opacity:1"/><stop offset="0.06" style="stop-color:#f6fbff;stop-opacity:1"/><stop offset="0.13" style="stop-color:#fff;stop-opacity:1"/><stop offset="0.2" style="stop-color:#edf6fd;stop-opacity:1"/><stop offset="1" style="stop-color:#95c4ed;stop-opacity:1"/></radialGradient><linearGradient id="_Linear20" x1="0" y1="0" x2="1" y2="-0.00902707" gradientUnits="userSpaceOnUse" gradientTransform="matrix(27.1204,251.722,-242.034,28.206,807.361,652.27)"><stop offset="0" style="stop-color:#203b64;stop-opacity:1"/><stop offset="1" style="stop-color:#4372b2;stop-opacity:1"/></linearGradient><radialGradient id="_Radial21" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-41.8121,-64.0879,64.0879,-41.8121,770.275,815.095)"><stop offset="0" style="stop-color:#e3f2fd;stop-opacity:1"/><stop offset="0.05" style="stop-color:#e3f2fd;stop-opacity:1"/><stop offset="0.41" style="stop-color:#bbdefb;stop-opacity:1"/><stop offset="0.79" style="stop-color:#90caf9;stop-opacity:1"/><stop offset="1" style="stop-color:#2196f3;stop-opacity:1"/></radialGradient><radialGradient id="_Radial22" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-41.8121,-64.0879,64.0879,-41.8121,987.355,825.062)"><stop offset="0" style="stop-color:#e3f2fd;stop-opacity:1"/><stop offset="0.05" style="stop-color:#e3f2fd;stop-opacity:1"/><stop offset="0.41" style="stop-color:#bbdefb;stop-opacity:1"/><stop offset="0.79" style="stop-color:#90caf9;stop-opacity:1"/><stop offset="1" style="stop-color:#2196f3;stop-opacity:1"/></radialGradient><radialGradient id="_Radial23" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="matrix(33.7576,127.524,-78.7056,68.2324,1217.29,810.051)"><stop offset="0" style="stop-color:#f6fbff;stop-opacity:1"/><stop offset="0.06" style="stop-color:#f6fbff;stop-opacity:1"/><stop offset="0.13" style="stop-color:#fff;stop-opacity:1"/><stop offset="0.2" style="stop-color:#edf6fd;stop-opacity:1"/><stop offset="1" style="stop-color:#95c4ed;stop-opacity:1"/></radialGradient><linearGradient id="_Linear24" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(54.4792,98.0958,-98.0958,54.4792,1255.85,771.192)"><stop offset="0" style="stop-color:#203b64;stop-opacity:1"/><stop offset="1" style="stop-color:#4372b2;stop-opacity:1"/></linearGradient><linearGradient id="_Linear25" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(77.4042,233.946,-233.946,77.4042,1069.15,1247.22)"><stop offset="0" style="stop-color:#305b8e;stop-opacity:1"/><stop offset="1" style="stop-color:#305b8e;stop-opacity:0.2"/></linearGradient><linearGradient id="_Linear26" x1="0" y1="0" x2="1" y2="0" gradientUnits="userSpaceOnUse" gradientTransform="matrix(-56.25,54.1667,-54.1667,-56.25,1150.79,1320.83)"><stop offset="0" style="stop-color:#fffdfe;stop-opacity:1"/><stop offset="1" style="stop-color:#b9d9f4;stop-opacity:1"/></linearGradient></defs></svg>
\ No newline at end of file
diff --git a/assets/images/guides/dhi-examples-go.webp b/assets/images/guides/dhi-examples-go.webp
new file mode 100644
index 000000000000..3f5a440739e8
Binary files /dev/null and b/assets/images/guides/dhi-examples-go.webp differ
diff --git a/assets/images/guides/dhi-examples-nodejs.webp b/assets/images/guides/dhi-examples-nodejs.webp
new file mode 100644
index 000000000000..e7627866afc6
Binary files /dev/null and b/assets/images/guides/dhi-examples-nodejs.webp differ
diff --git a/assets/images/guides/dhi-examples-python.webp b/assets/images/guides/dhi-examples-python.webp
new file mode 100644
index 000000000000..4326509bc114
Binary files /dev/null and b/assets/images/guides/dhi-examples-python.webp differ
diff --git a/assets/images/guides/dhi-migrate-doi.webp b/assets/images/guides/dhi-migrate-doi.webp
new file mode 100644
index 000000000000..1157dababe46
Binary files /dev/null and b/assets/images/guides/dhi-migrate-doi.webp differ
diff --git a/assets/images/guides/dhi-migrate-wolfi.webp b/assets/images/guides/dhi-migrate-wolfi.webp
new file mode 100644
index 000000000000..b6a0dd0c63f5
Binary files /dev/null and b/assets/images/guides/dhi-migrate-wolfi.webp differ
diff --git a/assets/images/guides/ros2.jpg b/assets/images/guides/ros2.jpg
new file mode 100644
index 000000000000..98d697619ef9
Binary files /dev/null and b/assets/images/guides/ros2.jpg differ
diff --git a/assets/images/search-ai.svg b/assets/images/search-ai.svg
deleted file mode 100644
index a898a28113ce..000000000000
--- a/assets/images/search-ai.svg
+++ /dev/null
@@ -1,9 +0,0 @@
-<svg width="25" height="25" viewBox="0 0 25 25" fill="none" xmlns="http://www.w3.org/2000/svg">
-<mask id="mask0_200_9677" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="2" y="0" width="21" height="23">
-<path d="M21.2461 21.4956L16.8961 17.1456M19.2461 11.4956C19.2461 15.9139 15.6644 19.4956 11.2461 19.4956C6.82782 19.4956 3.24609 15.9139 3.24609 11.4956C3.24609 7.07733 6.82782 3.49561 11.2461 3.49561" stroke="#677285" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
-<path d="M16.7461 1.84082L17.5306 3.40974C17.796 3.94072 17.9288 4.2062 18.1061 4.43627C18.2635 4.64041 18.4465 4.82343 18.6506 4.98079C18.8807 5.15813 19.1462 5.29087 19.6772 5.55636L21.2461 6.34082L19.6772 7.12528C19.1462 7.39077 18.8807 7.52351 18.6506 7.70085C18.4465 7.85821 18.2635 8.04123 18.1061 8.24537C17.9288 8.47544 17.796 8.74093 17.5306 9.2719L16.7461 10.8408L15.9616 9.2719C15.6961 8.74092 15.5634 8.47544 15.3861 8.24537C15.2287 8.04123 15.0457 7.85821 14.8415 7.70085C14.6115 7.52351 14.346 7.39077 13.815 7.12528L12.2461 6.34082L13.815 5.55636C14.346 5.29087 14.6115 5.15813 14.8415 4.98079C15.0457 4.82343 15.2287 4.64041 15.3861 4.43627C15.5634 4.2062 15.6961 3.94072 15.9616 3.40974L16.7461 1.84082Z" stroke="#677285" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
-</mask>
-<g mask="url(#mask0_200_9677)">
-<rect x="0.426636" y="0.495605" width="24" height="24" fill="white"/>
-</g>
-</svg>
diff --git a/assets/js/mermaid.js b/assets/js/mermaid.js
new file mode 100644
index 000000000000..ae8f7a9b1f10
--- /dev/null
+++ b/assets/js/mermaid.js
@@ -0,0 +1,19 @@
+import mermaid from 'mermaid'
+
+const isDark = () => document.documentElement.classList.contains('dark')
+
+mermaid.initialize({
+  startOnLoad: false,
+  securityLevel: 'strict',
+  theme: isDark() ? 'dark' : 'default',
+})
+
+const render = () => {
+  mermaid.run({ querySelector: 'pre.mermaid' })
+}
+
+if (document.readyState === 'loading') {
+  document.addEventListener('DOMContentLoaded', render)
+} else {
+  render()
+}
diff --git a/assets/js/src/alpine.js b/assets/js/src/alpine.js
index cdcdfeb93055..c314dc641cd9 100644
--- a/assets/js/src/alpine.js
+++ b/assets/js/src/alpine.js
@@ -2,12 +2,110 @@ import Alpine from 'alpinejs'
 import collapse from '@alpinejs/collapse'
 import persist from '@alpinejs/persist'
 import focus from '@alpinejs/focus'
- 
+import { marked } from 'marked'
+import hljs from 'highlight.js/lib/core'
+// Import languages relevant to Docker docs
+import bash from 'highlight.js/lib/languages/bash'
+import dockerfile from 'highlight.js/lib/languages/dockerfile'
+import yaml from 'highlight.js/lib/languages/yaml'
+import json from 'highlight.js/lib/languages/json'
+import javascript from 'highlight.js/lib/languages/javascript'
+import python from 'highlight.js/lib/languages/python'
+import go from 'highlight.js/lib/languages/go'
+
 window.Alpine = Alpine
 
 Alpine.plugin(collapse)
 Alpine.plugin(persist)
 Alpine.plugin(focus)
+
+// Register highlight.js languages
+hljs.registerLanguage('bash', bash)
+hljs.registerLanguage('sh', bash)
+hljs.registerLanguage('shell', bash)
+hljs.registerLanguage('console', bash)
+hljs.registerLanguage('dockerfile', dockerfile)
+hljs.registerLanguage('yaml', yaml)
+hljs.registerLanguage('yml', yaml)
+hljs.registerLanguage('json', json)
+hljs.registerLanguage('javascript', javascript)
+hljs.registerLanguage('js', javascript)
+hljs.registerLanguage('python', python)
+hljs.registerLanguage('py', python)
+hljs.registerLanguage('go', go)
+hljs.registerLanguage('golang', go)
+
+// Configure marked to escape HTML in text tokens only (not code blocks)
+marked.use({
+  walkTokens(token) {
+    // Escape HTML in text and HTML tokens, preserve code blocks
+    if (token.type === 'text' || token.type === 'html') {
+      const text = token.text || token.raw
+      const escaped = text
+        .replace(/&/g, '&amp;')
+        .replace(/</g, '&lt;')
+        .replace(/>/g, '&gt;')
+      if (token.text) token.text = escaped
+      if (token.raw) token.raw = escaped
+    }
+  }
+})
+
+// Add $markdown magic for rendering markdown with syntax highlighting
+Alpine.magic('markdown', () => {
+  return (content) => {
+    if (!content) return ''
+    const html = marked(content)
+
+    // Parse and highlight code blocks
+    const div = document.createElement('div')
+    div.innerHTML = html
+
+    // Handle code blocks (pre > code)
+    div.querySelectorAll('pre').forEach((pre) => {
+      // Add not-prose to prevent Tailwind Typography styling
+      pre.classList.add('not-prose')
+      const code = pre.querySelector('code')
+      if (code) {
+        // Preserve the original text with newlines
+        const codeText = code.textContent
+
+        // Clear and set as plain text first to preserve structure
+        code.textContent = codeText
+
+        // Now apply highlight.js which will work with the text nodes
+        hljs.highlightElement(code)
+      }
+    })
+
+    // Handle inline code elements (not in pre blocks)
+    div.querySelectorAll('code:not(pre code)').forEach((code) => {
+      code.classList.add('not-prose')
+    })
+
+    return div.innerHTML
+  }
+})
+
+// Stores
 Alpine.store("showSidebar", false)
+Alpine.store('gordon', {
+  isOpen: false,
+  query: '',
+  autoSubmit: false,
+  toggle() {
+    this.isOpen = !this.isOpen
+  },
+  open(query, autoSubmit = false) {
+    this.isOpen = true
+    if (query) {
+      this.query = query
+      this.autoSubmit = autoSubmit
+    }
+  },
+  close() {
+    this.isOpen = false
+  }
+})
 
 Alpine.start()
diff --git a/assets/js/src/marlin.js b/assets/js/src/marlin.js
new file mode 100644
index 000000000000..62a51abaea84
--- /dev/null
+++ b/assets/js/src/marlin.js
@@ -0,0 +1,18 @@
+import { Marlin, Environment } from "@docker/marlin-sdk-web-public";
+
+const config = window.__marlinConfig;
+
+if (config && config.apiKey && config.endpoint) {
+  const environment =
+    config.environment === "staging" ? Environment.STAGING : Environment.PROD;
+  try {
+    window.marlin = new Marlin({
+      endpoint: config.endpoint,
+      apiKey: config.apiKey,
+      site: "docs",
+      environment,
+    });
+  } catch (err) {
+    console.warn("Marlin SDK init failed:", err);
+  }
+}
diff --git a/assets/js/theme.js b/assets/js/theme.js
index 95faa9a8f3a2..27852bd5c02f 100644
--- a/assets/js/theme.js
+++ b/assets/js/theme.js
@@ -1,20 +1,10 @@
-// return 'light' or 'dark' depending on localStorage (pref) or system setting
-function getThemePreference() {
-  const theme = localStorage.getItem("theme-preference");
-  if (theme) return theme;
-  else
-    return window.matchMedia("(prefers-color-scheme: dark)").matches
+// update root class based on os setting or localstorage
+const storedTheme = localStorage.getItem("theme-preference");
+const prefersDark = window.matchMedia("(prefers-color-scheme: dark)").matches;
+document.firstElementChild.className =
+  storedTheme === "dark" || storedTheme === "light"
+    ? storedTheme
+    : prefersDark
       ? "dark"
       : "light";
-}
-
-// update root class based on os setting or localstorage
-const preference = getThemePreference();
-document.firstElementChild.className = preference === "dark" ? "dark" : "light";
-localStorage.setItem("theme-preference", preference);
-
-// set innertext for the theme switch button
-// window.addEventListener("DOMContentLoaded", () => {
-//   const themeSwitchButton = document.querySelector("#theme-switch");
-//   themeSwitchButton.textContent = `${preference}_mode`;
-// });
+document.firstElementChild.dataset.themePreference = storedTheme || "auto";
diff --git a/content/_index.md b/content/_index.md
index 7c7a6e3641aa..3c9e13e3044d 100644
--- a/content/_index.md
+++ b/content/_index.md
@@ -2,137 +2,26 @@
 title: Home
 description: Docker Documentation is the official Docker library of resources, manuals, and guides to help you containerize applications.
 keywords: Docker, documentation, manual, guide, reference, api, samples
-grid:
-  - title: Docker Desktop
-    icon: computer
-    description: |
-      Manage containers, applications, and images directly from your machine.
-    links:
-      - text: "Overview"
-        url: "/desktop/"
-      - text: "Explore Docker Desktop"
-        url: "/desktop/use-desktop/"
-      - text: "Release notes"
-        url: "/desktop/release-notes/"
-  - title: Docker Engine
-    icon: developer_board
-    description: |
-      The definitive open source container client and runtime.
-    links:
-      - text: "Overview"
-        url: "/engine/"
-      - text: "Install"
-        url: "/engine/install/"
-      - text: "Release notes"
-        url: "/engine/release-notes/"
-  - title: Docker Build
-    icon: build
-    description: |
-      Package, test, and ship your applications.
-    links:
-      - text: "Overview"
-        url: "/build/"
-      - text: "Packaging your software"
-        url: "/build/building/packaging/"
-      - text: "Release notes"
-        url: "/build/release-notes/"
-  - title: Docker Build Cloud
-    icon: cloud
-    description: |
-      Run your builds in the cloud.
-    links:
-      - text: "Overview"
-        url: "/build-cloud/"
-      - text: "Setup"
-        url: "/build-cloud/setup/"
-      - text: "Release notes"
-        url: "/build-cloud/release-notes/"
-  - title: Docker Compose
-    icon: polyline
-    description: |
-      Define and run multi-container applications with Docker.
-    links:
-      - text: "Overview"
-        url: "/compose/"
-      - text: "Try Docker Compose"
-        url: "/compose/gettingstarted/"
-      - text: "Release notes"
-        url: "/compose/releases/release-notes/"
-  - title: Docker Hub
-    icon: device_hub
-    description: |
-      Find and share container images and other artifacts.
-    links:
-      - text: "Overview"
-        url: "/docker-hub/"
-      - text: "Create an account"
-        url: "/accounts/create-account/"
-      - text: "Create a repository"
-        url: "/docker-hub/repos/create/"
-  - title: Docker Scout
-    icon: query_stats
-    description: |
-      Strengthen your software supply chain with Docker Scout.
-    links:
-      - text: "Overview"
-        url: "/scout/"
-      - text: "Quickstart"
-        url: "/scout/quickstart/"
-      - text: "Image analysis"
-        url: "/scout/image-analysis/"
-  - title: Subscription
-    icon: card_membership
-    description: |
-      Licensing for commercial use of Docker components.
-    links:
-      - text: "Overview"
-        url: "/subscription/"
-      - text: "Subscriptions and features"
-        url: "/subscription/details/"
-      - text: "Change subscription"
-        url: "/subscription/change/"
-  - title: Billing
-    icon: payments
-    description: |
-      Manage your billing and payment settings for your subscription.
-    links:
-      - text: "Overview"
-        url: "/billing/"
-      - text: "Update payment method"
-        url: "/billing/payment-method/"
-      - text: "View billing history"
-        url: "/billing/history/"
-  - title: Administration
-    icon: admin_panel_settings
-    description: |
-      Manage company and organization users, permissions, and more.
-    links:
-      - text: "Overview"
-        url: "/admin/company/"
-      - text: "Organization administration"
-        url: "/admin/organization/"
-      - text: "Company administration"
-        url: "/admin/company/"
-  - title: Security
-    icon: shield
-    description: |
-      Security guardrails for both administrators and developers.
-    links:
-      - text: "Overview"
-        url: "/security/"
-      - text: "SSO"
-        url: "/security/for-admins/single-sign-on/"
-      - text: "SCIM"
-        url: "/security/for-admins/provisioning/scim/"
-  - title: Testcontainers Cloud
-    icon: cloud
-    description: |
-      Testcontainers Cloud lets you run heavy test workloads remotely.
-    links:
-      - text: "Overview"
-        url: "https://testcontainers.com/cloud/docs/"
-      - text: "Getting started"
-        url: "https://testcontainers.com/cloud/docs/#getting-started"
-      - text: "TCC for CI"
-        url: "https://testcontainers.com/cloud/docs/#tcc-for-ci"
+aliases:
+  - /search/
 ---
+
+Docker Documentation helps you learn Docker, install Docker products, and find
+reference material for everyday development and operations tasks.
+
+## Browse docs by area
+
+- [Get started](/get-started/): Learn Docker basics and core concepts.
+- [Guides](/guides/): Follow task-focused walkthroughs for common workflows.
+- [Manuals](/manuals/): Install, configure, and use Docker products.
+- [Reference](/reference/): Browse CLI, API, and file format documentation.
+
+{{< whats-new >}}
+
+## Common questions
+
+- [How do I get started with Docker?](/get-started/docker-overview/)
+- [Can I run my AI agent in a sandbox?](/ai/sandboxes/get-started/)
+- [What is a container?](/get-started/docker-concepts/the-basics/what-is-a-container/)
+- [What are Docker Hardened Images?](/dhi/)
+- [Why should I use Docker Compose?](/compose/)
diff --git a/content/bot-detection.md b/content/bot-detection.md
new file mode 100644
index 000000000000..3be15b77050d
--- /dev/null
+++ b/content/bot-detection.md
@@ -0,0 +1,9 @@
+---
+title: Automated traffic detection
+description: This page supports automated traffic detection for Docker documentation.
+keywords: bot detection, automated traffic, Docker documentation
+sitemap: false
+layout: wide
+---
+
+This page is used to identify automated traffic.
diff --git a/content/contribute/_index.md b/content/contribute/_index.md
deleted file mode 100644
index 3801814cd10b..000000000000
--- a/content/contribute/_index.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: Contribute to Docker's docs
-linkTitle: Contribute
-weight: 10
-toc_max: 1
-aliases:
-- /opensource/
-- /contribute/overview/
-- /contribute/contribute-guide/
-grid:
-- title: Grammar and style
-  description: Explore Docker's grammar and style guide
-  icon: menu_book
-  link: /contribute/style/grammar
-- title: Formatting
-  description: Format your content to match the rest of our documentation.
-  icon: newspaper
-  link: /contribute/style/formatting
-- title: Recommended word list
-  description: Choose the right words for your content.
-  icon: checklist
-  link: /contribute/style/recommended-words
-- title: Source file conventions
-  description: Guidelines for creating a new page.
-  icon: note_add
-  link: /contribute/file-conventions
-- title: Terminology
-  description: Explore commonly used Docker terms.
-  icon: spellcheck
-  link: /contribute/style/terminology
-- title: Voice and tone
-  description: Learn about how we use voice and tone in our writing.
-  icon: voice_selection
-  link: /contribute/style/voice-tone
----
-
-We value documentation contributions from the Docker community. We'd like to
-make it as easy as possible for you to contribute to the Docker documentation.
-
-Find the contribution guidelines in
-[CONTRIBUTING.md](https://github.com/docker/docs/blob/main/CONTRIBUTING.md) in
-the `docker/docs` GitHub repository. Use the following links to review our
-style guide and instructions on how to use our page templates and components.
-
-{{< grid >}}
-
-### Additional resources
-
-See also:
-
-- A section of useful components you can add to your documentation.
-- Information on Docker's [tone and voice](style/voice-tone.md).
-- A [writing checklist](checklist.md) to help you when you're contributing to Docker's documentation.
diff --git a/content/contribute/checklist.md b/content/contribute/checklist.md
deleted file mode 100644
index e9e8af6feade..000000000000
--- a/content/contribute/checklist.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: Writing checklist
-description: A helpful writing checklist when creating documentation
-keywords: checklist, documentation, style guide, contribute
-weight: 60
----
-
-Use this checklist to communicate in a way that is clear, helpful, and consistent with the rest of Docker Docs.
-
-##### Used active voice
-
-Active voice is specific and removes ambiguity.
-
-In active voice, the subject of the sentence (the customer or the system) does the action.
-
-Sentences that use active voice are easier to read. Active voice makes it clear who has done what and to whom. Plus, active voice keeps sentences direct and more concise.
-
-Helping verbs such as is, was, or would may indicate that you're writing in passive voice. And, if you can add the phrase 'by zombies' after the verb, you're writing in the passive voice.
-
-|Correct| Incorrect|
-|:--|:--|
-|Increase productivity with Docker Desktop.| Productivity can be increased (by zombies) with Docker Desktop.|
-|If you remove items from a grid, charts automatically refresh to display the change. | If items are removed (by zombies) from a grid, charts automatically refresh to display the change.|
-
-##### Written clear sentences that get to the point
-
-Write short, concise sentences. Punchy sentences are faster to read and easier to understand.
-
-##### Used subheadings and bulleted lists to break up the page
-
-This helps find the information they need quickly and easily.
-
-For more information, see the [formatting](style/formatting.md#headings-and-subheadings) page, or see the [components](components/lists.md) for examples.
-
-##### Started the title of your page with a verb
-
-For example, 'Install Docker Desktop'.
-
-##### Checked that the left-hand table of contents title in docs.docker.com, matches the title displayed on the page
-
-##### Checked for broken links and images
-
-Use relative links to link to other pages or images within the GitHub repository.
-
-For more information, see the [formatting](style/formatting.md#links) page, or see the [components](components/links.md) for examples.
-
-##### Checked that any redirects you may have added, work
-
-For information on how to add redirects, see [Source file conventions](file-conventions.md#front-matter).
-
-##### Used bold on any UI elements you refer to in your content
-
-##### Completed a final spelling, punctuation, and grammar check
-
-For more in-depth information on our Style Guide, explore the [grammar](style/grammar.md) or [formatting](style/formatting.md) guides.
diff --git a/content/contribute/components/_index.md b/content/contribute/components/_index.md
deleted file mode 100644
index 3c3ff89b1a68..000000000000
--- a/content/contribute/components/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-build:
-  render: never
-title: Useful components
-weight: 50
----
\ No newline at end of file
diff --git a/content/contribute/components/accordions.md b/content/contribute/components/accordions.md
deleted file mode 100644
index c88cf9bdaebd..000000000000
--- a/content/contribute/components/accordions.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-description: components and formatting examples used in Docker's docs
-title: Accordions
-toc_max: 3
----
-
-## Example
-
-{{< accordion title="Accordion example" >}}
-
-```console
-$ docker run hello-world
-```
-
-{{< /accordion >}}
-
-## Markup
-
-````markdown
-{{</* accordion title="Accordion example" */>}}
-
-```console
-$ docker run hello-world
-```
-
-{{</* /accordion */>}}
-````
diff --git a/content/contribute/components/badges.md b/content/contribute/components/badges.md
deleted file mode 100644
index db1cedf36c2f..000000000000
--- a/content/contribute/components/badges.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-description: components and formatting examples used in Docker's docs
-title: Badges
-toc_max: 3
----
-
-### Examples
-
-{{< badge color=blue text="blue badge" >}}
-{{< badge color=amber text="amber badge" >}}
-{{< badge color=red text="red badge" >}}
-{{< badge color=green text="green badge" >}}
-{{< badge color=violet text="violet badge" >}}
-
-You can also make a badge a link.
-
-[{{< badge color="blue" text="badge with a link" >}}](../_index.md)
-
-### Usage guidelines
-
-We use badges to indicate new content and product content in various stages of the release lifecycle: 
-
-- The violet badge to highlight new early access or experimental content 
-- The blue badge to highlight beta content 
-- The green badge to highlight new content that is either GA or not product-related content, such as guides/learning paths
-
-Best practice is to use this badge for no longer than 2 months post release of the feature.
-
-### Markup
-
-```go
-{{</* badge color=amber text="amber badge" */>}}
-[{{</* badge color="blue" text="badge with a link" */>}}](../overview.md)
-```
diff --git a/content/contribute/components/buttons.md b/content/contribute/components/buttons.md
deleted file mode 100644
index 7e7aed3fdb6f..000000000000
--- a/content/contribute/components/buttons.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-description: components and formatting examples used in Docker's docs
-title: Buttons
-toc_max: 3
----
-
-### Examples
-
-{{< button url="https://example.com/" text="hello" >}}
-
-### Markup
-
-```go
-{{</* button url="https://example.com/" text="hello" */>}}
-```
diff --git a/content/contribute/components/call-outs.md b/content/contribute/components/call-outs.md
deleted file mode 100644
index 231e896d2b2e..000000000000
--- a/content/contribute/components/call-outs.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-description: components and formatting examples used in Docker's docs
-title: Callouts
-toc_max: 3
----
-
-We support these broad categories of callouts:
-
-- Alerts: Note, Tip, Important, Warning, Caution
-
-We also support summary bars, which represent a feature's required subscription, version, or Adminstrator role.
-To add a summary bar:
-
-Add the feature name to the `/data/summary.yaml` file. Use the following attributes:
-
-| Attribute      | Description                                            | Possible values                                         |
-|----------------|--------------------------------------------------------|---------------------------------------------------------|
-| `subscription` | Notes the subscription required to use the feature     | All, Personal, Pro, Team, Business                      |
-| `availability` | Notes what product development stage the feature is in | Experimental, Beta, Early Access, GA, Retired           |
-| `requires`     | Notes what minimum version is required for the feature | No specific value, use a string to describe the version and link to relevant release notes |
-| `for`          | Notes if the feature is intended for IT Administrators | Administrators                                          |
-
-Then, add the `summary-bar` shortcode on the page you want to add the summary bar to. Note, the feature name is case sensitive. The icons that appear in the summary bar are automatically rendered.
-
-## Examples
-
-{{< summary-bar feature_name="PKG installer" >}}
-
-> [!NOTE]
->
-> Note the way the `get_hit_count` function is written. This basic retry
-> loop lets us attempt our request multiple times if the redis service is
-> not available. This is useful at startup while the application comes
-> online, but also makes our application more resilient if the Redis
-> service needs to be restarted anytime during the app's lifetime. In a
-> cluster, this also helps handling momentary connection drops between
-> nodes.
-
-> [!TIP]
->
-> For a smaller base image, use `alpine`.
-
-> [!IMPORTANT]
->
-> Treat access tokens like your password and keep them secret. Store your
-> tokens securely (for example, in a credential manager).
-
-> [!WARNING]
->
-> Removing Volumes
->
-> By default, named volumes in your compose file are NOT removed when running
-> `docker compose down`. If you want to remove the volumes, you will need to add
-> the `--volumes` flag.
->
-> The Docker Desktop Dashboard does not remove volumes when you delete the app stack.
-
-> [!CAUTION]
->
-> Here be dragons.
-
-For both of the following callouts, consult [the Docker release lifecycle](/release-lifecycle) for more information on when to use them.
-
-## Formatting
-
-```md
-{{</* summary-bar feature_name="PKG installer" */>}}
-```
-
-```html
-> [!NOTE]
->
-> Note the way the `get_hit_count` function is written. This basic retry
-> loop lets us attempt our request multiple times if the redis service is
-> not available. This is useful at startup while the application comes
-> online, but also makes our application more resilient if the Redis
-> service needs to be restarted anytime during the app's lifetime. In a
-> cluster, this also helps handling momentary connection drops between
-> nodes.
-
-> [!TIP]
->
-> For a smaller base image, use `alpine`.
-
-> [!IMPORTANT]
->
-> Treat access tokens like your password and keep them secret. Store your
-> tokens securely (for example, in a credential manager).
-
-> [!WARNING]
->
-> Removing Volumes
->
-> By default, named volumes in your compose file are NOT removed when running
-> `docker compose down`. If you want to remove the volumes, you will need to add
-> the `--volumes` flag.
->
-> The Docker Desktop Dashboard does not remove volumes when you delete the app stack.
-
-> [!CAUTION]
->
-> Here be dragons.
-```
\ No newline at end of file
diff --git a/content/contribute/components/cards.md b/content/contribute/components/cards.md
deleted file mode 100644
index 0dc0f009cffb..000000000000
--- a/content/contribute/components/cards.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-description: components and formatting examples used in Docker's docs
-title: Cards
-toc_max: 3
-grid:
-- title: Docker Desktop
-  description: Docker on your Desktop.
-  icon: install_desktop
-  link: /desktop/
-- title: Docker Engine
-  description: Vrrrrooooommm
-  icon: developer_board
-  link: /engine/
-- title: Docker Build
-  description: Clang bang
-  icon: build
-  link: /build/
-- title: Docker Compose
-  description: Figgy!
-  icon: account_tree
-  link: /compose/
-- title: Docker Hub
-  description: so much content, oh wow
-  icon: hub
-  link: /docker-hub/
----
-
-Cards can be added to a page using the `card` shortcode.
-The parameters for this shortcode are:
-
-| Parameter   | Description                                                          |
-| ----------- | -------------------------------------------------------------------- |
-| title       | The title of the card                                                |
-| icon        | The icon slug of the card                                            |
-| image       | Use a custom image instead of an icon (mutually exclusive with icon) |
-| link        | (Optional) The link target of the card, when clicked                 |
-| description | A description text, in Markdown                                      |
-
-> [!NOTE]
->
-> There's a known limitation with the Markdown description of cards,
-> in that they can't contain relative links, pointing to other .md documents.
-> Such links won't render correctly. Instead, use an absolute link to the URL
-> path of the page that you want to link to.
->
-> For example, instead of linking to `../install/linux.md`, write:
-> `/engine/install/linux/`.
-
-## Example
-
-{{< card
-  title="Get your Docker on"
-  icon=favorite
-  link=https://docs.docker.com/
-  description="Build, share, and run your apps with Docker" >}}
-
-## Markup
-
-```go
-{{</* card
-  title="Get your Docker on"
-  icon=favorite
-  link=https://docs.docker.com/
-  description="Build, share, and run your apps with Docker"
-*/>}}
-```
-
-### Grid
-
-There's also a built-in `grid` shortcode that generates a... well, grid... of cards.
-The grid size is 3x3 on large screens, 2x2 on medium, and single column on small.
-
-{{< grid >}}
-
-Grid is a separate shortcode from `card`, but it implements the same component under the hood.
-The markup you use to insert a grid is slightly unconventional. The grid shortcode takes no arguments.
-All it does is let you specify where on a page you want your grid to appear.
-
-```go
-{{</* grid */>}}
-```
-
-The data for the grid is defined in the front matter of the page, under the `grid` key, as follows:
-
-```yaml
-# front matter section of a page
-title: some page
-grid:
-  - title: "Docker Engine"
-    description: Vrrrrooooommm
-    icon: "developer_board"
-    link: "/engine/"
-  - title: "Docker Build"
-    description: Clang bang
-    icon: "build"
-    link: "/build/"
-```
diff --git a/content/contribute/components/code-blocks.md b/content/contribute/components/code-blocks.md
deleted file mode 100644
index 7df04769a2b2..000000000000
--- a/content/contribute/components/code-blocks.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-description: components and formatting examples used in Docker's docs
-title: Code blocks
-toc_max: 3
----
-
-Rouge provides lots of different code block "hints". If you leave off the hint,
-it tries to guess and sometimes gets it wrong. These are just a few hints that
-we use often.
-
-## Variables
-
-If your example contains a placeholder value that's subject to change,
-use the format `<[A-Z_]+>` for the placeholder value: `<MY_VARIABLE>`
-
-```none
-export name=<MY_NAME>
-```
-
-This syntax is reserved for variable names, and will cause the variable to
-be rendered in a special color and font style.
-
-## Highlight lines
-
-```text {hl_lines=[7,8]}
-incoming := map[string]interface{}{
-    "asdf": 1,
-    "qwer": []interface{}{},
-    "zxcv": []interface{}{
-        map[string]interface{}{},
-        true,
-        int(1e9),
-        "tyui",
-    },
-}    
-```
-
-````markdown
-```go {hl_lines=[7,8]}
-incoming := map[string]interface{}{
-    "asdf": 1,
-    "qwer": []interface{}{},
-    "zxcv": []interface{}{
-        map[string]interface{}{},
-        true,
-        int(1e9),
-        "tyui",
-    },
-}   
-```
-````
-
-## Collapsible code blocks
-
-```dockerfile {collapse=true}
-# syntax=docker/dockerfile:1
-
-ARG GO_VERSION="1.21"
-
-FROM golang:${GO_VERSION}-alpine AS base
-ENV CGO_ENABLED=0
-ENV GOPRIVATE="github.com/foo/*"
-RUN apk add --no-cache file git rsync openssh-client
-RUN mkdir -p -m 0700 ~/.ssh && ssh-keyscan github.com >> ~/.ssh/known_hosts
-WORKDIR /src
-
-FROM base AS vendor
-# this step configure git and checks the ssh key is loaded
-RUN --mount=type=ssh <<EOT
-  set -e
-  echo "Setting Git SSH protocol"
-  git config --global url."git@github.com:".insteadOf "https://github.com/"
-  (
-    set +e
-    ssh -T git@github.com
-    if [ ! "$?" = "1" ]; then
-      echo "No GitHub SSH key loaded exiting..."
-      exit 1
-    fi
-  )
-EOT
-# this one download go modules
-RUN --mount=type=bind,target=. \
-    --mount=type=cache,target=/go/pkg/mod \
-    --mount=type=ssh \
-    go mod download -x
-
-FROM vendor AS build
-RUN --mount=type=bind,target=. \
-    --mount=type=cache,target=/go/pkg/mod \
-    --mount=type=cache,target=/root/.cache \
-    go build ...
-```
-
-## Bash
-
-Use the `bash` language code block when you want to show a Bash script:
-
-```bash
-#!/usr/bin/bash
-echo "deb https://download.docker.com/linux/ubuntu noble stable" | sudo tee /etc/apt/sources.list.d/docker.list
-```
-
-If you want to show an interactive shell, use `console` instead.
-In cases where you use `console`, make sure to add a dollar character
-for the user sign:
-
-```console
-$ echo "deb https://download.docker.com/linux/ubuntu noble stable" | sudo tee /etc/apt/sources.list.d/docker.list
-```
-
-## Go
-
-```go
-incoming := map[string]interface{}{
-    "asdf": 1,
-    "qwer": []interface{}{},
-    "zxcv": []interface{}{
-        map[string]interface{}{},
-        true,
-        int(1e9),
-        "tyui",
-    },
-}
-```
-
-## PowerShell
-
-```powershell
-Install-Module DockerMsftProvider -Force
-Install-Package Docker -ProviderName DockerMsftProvider -Force
-[System.Environment]::SetEnvironmentVariable("DOCKER_FIPS", "1", "Machine")
-Expand-Archive docker-18.09.1.zip -DestinationPath $Env:ProgramFiles -Force
-```
-
-## Python
-
-```python
-return html.format(name=os.getenv('NAME', "world"), hostname=socket.gethostname(), visits=visits)
-```
-
-## Ruby
-
-```ruby
-docker_service 'default' do
-  action [:create, :start]
-end
-```
-
-## JSON
-
-```json
-"server": {
-  "http_addr": ":4443",
-  "tls_key_file": "./fixtures/notary-server.key",
-  "tls_cert_file": "./fixtures/notary-server.crt"
-}
-```
-
-#### HTML
-
-```html
-<!DOCTYPE html>
-<html>
-<head>
-<title>Welcome to nginx!</title>
-</head>
-</html>
-```
-
-## Markdown
-
-```markdown
-# Hello
-```
-
-If you want to include a triple-fenced code block inside your code block,
-you can wrap your block in a quadruple-fenced code block:
-
-`````markdown
-````markdown
-# Hello
-
-```go
-log.Println("did something")
-```
-````
-`````
-
-## ini
-
-```ini
-[supervisord]
-nodaemon=true
-
-[program:sshd]
-command=/usr/sbin/sshd -D
-```
-
-## Dockerfile
-
-```dockerfile
-# syntax=docker/dockerfile:1
-
-FROM ubuntu
-
-RUN apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys B97B0AFCAA1A47F044F244A07FCC7D46ACCC4CF8
-
-RUN echo "deb http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main" > /etc/apt/sources.list.d/pgdg.list
-
-RUN apt-get update && apt-get install -y python-software-properties software-properties-common postgresql-9.3 postgresql-client-9.3 postgresql-contrib-9.3
-
-# Note: The official Debian and Ubuntu images automatically ``apt-get clean``
-# after each ``apt-get``
-
-USER postgres
-
-RUN    /etc/init.d/postgresql start &&\
-    psql --command "CREATE USER docker WITH SUPERUSER PASSWORD 'docker';" &&\
-    createdb -O docker docker
-
-RUN echo "host all  all    0.0.0.0/0  md5" >> /etc/postgresql/9.3/main/pg_hba.conf
-
-RUN echo "listen_addresses='*'" >> /etc/postgresql/9.3/main/postgresql.conf
-
-EXPOSE 5432
-
-VOLUME  ["/etc/postgresql", "/var/log/postgresql", "/var/lib/postgresql"]
-
-CMD ["/usr/lib/postgresql/9.3/bin/postgres", "-D", "/var/lib/postgresql/9.3/main", "-c", "config_file=/etc/postgresql/9.3/main/postgresql.conf"]
-```
-
-## YAML
-
-```yaml
-authorizedkeys:
-  image: dockercloud/authorizedkeys
-  deployment_strategy: every_node
-  autodestroy: always
-  environment:
-    - AUTHORIZED_KEYS=ssh-rsa AAAAB3Nsomelongsshkeystringhereu9UzQbVKy9o00NqXa5jkmZ9Yd0BJBjFmb3WwUR8sJWZVTPFL
-  volumes:
-    /root:/user:rw
-```
diff --git a/content/contribute/components/icons.md b/content/contribute/components/icons.md
deleted file mode 100644
index b89533075d26..000000000000
--- a/content/contribute/components/icons.md
+++ /dev/null
@@ -1,151 +0,0 @@
----
-description: Icons used across docs
-title: Icons
-grid:
-  - title: "Install"
-    icon: "download"
-    description: Icon name = download
-  - title: "FAQs"
-    icon: "help"
-    description: Icon name = help
-  - title: "Onboarding/quickstarts"
-    icon: "explore"
-    description: Icon name = explore
-  - title: "Release notes"
-    icon: "note_add"
-    description: Icon name = note_add
-  - title: "Feedback"
-    icon: "sms"
-    description: Icon name = sms
-  - title: "Multi-platform/arch"
-    icon: "content_copy"
-    description: Icon name = content_copy
-  - title: "Rootless/ECI"
-    icon: "security"
-    description: Icon name = security
-  - title: "Settings management"
-    icon: "shield_lock"
-    description: Icon name = shield_lock
-  - title: "Processes"
-    icon: "checklist"
-    description: Icon name = checklist
-  - title: "Networking"
-    icon: "network_node"
-    description: Icon name = network_node
-  - title: "Exploring a feature"
-    icon: "feature_search"
-    description: Icon name = feature_search
-  - title: "Company"
-    icon: "apartment"
-    description: Icon name = apartment
-  - title: "Organization"
-    icon: "store"
-    description: Icon name = store
-  - title: "Additional resources"
-    icon: "category"
-    description: Icon name = category
-  - title: "Designing"
-    icon: "design_services"
-    description: Icon name = design_services
-  - title: "Publishing"
-    icon: "publish"
-    description: Icon name = publish
-  - title: "Interacting"
-    icon: "multiple_stop"
-    description: Icon name = multiple_stop
-  - title: "Storage"
-    icon: "database"
-    description: Icon name = database
-  - title: "logs"
-    icon: "text_snippet"
-    description: Icon name = text_snippet
-  - title: "Prune/cut"
-    icon: "content_cut"
-    description: Icon name = content_cut
-  - title: "Configure"
-    icon: "tune"
-    description: Icon name = tune
-  - title: "Deprecated"
-    icon: "folder_delete"
-    description: Icon name = folder_delete
-  - title: "RAM"
-    icon: "home_storage"
-    description: Icon name = home_storage
-  - title: "IAM"
-    icon: "photo_library"
-    description: Icon name = photo_library
-  - title: "Packaging"
-    icon: "inventory_2"
-    description: Icon name = inventory_2
-  - title: "Multi-stage"
-    icon: "stairs"
-    description: Icon name = stairs
-  - title: "Architecture"
-    icon: "construction"
-    description: Icon name = construction
-  - title: "Build drivers"
-    icon: "engineering"
-    description: Icon name = engineering
-  - title: "Export"
-    icon: "output"
-    description: Icon name = output
-  - title: "Cache"
-    icon: "cycle"
-    description: Icon name = cycle
-  - title: "Bake"
-    icon: "cake"
-    description: Icon name = cake
-  - title: "Docker ID"
-    icon: "fingerprint"
-    description: Icon name = fingerprint
-  - title: "Repository"
-    icon: "inbox"
-    description: Icon name = inbox
-  - title: "Access tokens"
-    icon: "password"
-    description: Icon name = password
-  - title: "official images"
-    icon: "verified"
-    description: Icon name = verified
-  - title: "Hardened Docker Desktop"
-    icon: "lock"
-    description: Icon name = lock
-  - title: "Sign in"
-    icon: "passkey"
-    description: Icon name = passkey
-  - title: "SSO and SCIM"
-    icon: "key"
-    description: Icon name = key
-  - title: "2FA"
-    icon: "phonelink_lock"
-    description: Icon name = phonelink_lock 
-  - title: "Add/update payment method"
-    icon: "credit_score"
-    description: Icon name = credit_score 
-  - title: "Update billing info"
-    icon: "contract_edit"
-    description: Icon name = contract_edit 
-  - title: "Billing history"
-    icon: "payments"
-    description: Icon name = payments
-  - title: "Upgrade"
-    icon: "upgrade"
-    description: Icon name = upgrade
-  - title: "Add/manage more seats/users"
-    icon: "group_add"
-    description: Icon name = group_add 
-  - title: "Domains"
-    icon: "domain_verification"
-    description: Icon name = domain_verification 
-  - title: Company owner
-    description: Icon name = supervised_user_circle
-    icon: supervised_user_circle
-  - title: "General settings"
-    icon: "settings"
-    description: Icon name = settings
----
-
-Below is an inventory of the icons we use to represent different topics or features across docs. To be used with the [cards component](cards.md).
-
-{{< grid >}}
-
diff --git a/content/contribute/components/images.md b/content/contribute/components/images.md
deleted file mode 100644
index 305334c283e1..000000000000
--- a/content/contribute/components/images.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-description: components and formatting examples used in Docker's docs
-title: Images
-toc_max: 3
----
-
-## Example
-
-- A small image: ![a small image](/assets/images/footer_moby_icon.png)
-
-- Large images occupy the full width of the reading column by default:
-
-  ![a pretty wide image](/assets/images/banner_image_24512.png)
-
-- Image size can be set using query parameters: `?h=<height>&w=<width>`
-
-  ![a pretty wide image](/assets/images/banner_image_24512.png?w=100&h=50)
-
-- Image with a border, also set with a query parameter: `?border=true`
-
-  ![a small image](/assets/images/footer_moby_icon.png?border=true)
-
-
-## HTML and Markdown
-
-```markdown
-- A small image: ![a small image](/assets/images/footer_moby_icon.png)
-
-- Large images occupy the full width of the reading column by default:
-
-  ![a pretty wide image](/assets/images/banner_image_24512.png)
-
-- Image size can be set using query parameters: `?h=<height>&w=<width>`
-
-  ![a pretty wide image](/assets/images/banner_image_24512.png?w=100&h=50)
-
-- Image with a border, also set with a query parameter: `?border=true`
-
-  ![a small image](/assets/images/footer_moby_icon.png?border=true)
-```
diff --git a/content/contribute/components/links.md b/content/contribute/components/links.md
deleted file mode 100644
index 97f47fbd4fc9..000000000000
--- a/content/contribute/components/links.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-description: components and formatting examples used in Docker's docs
-title: Links
-toc_max: 3
----
-
-## Examples
-
-- [External links](https://docker.com) open in a new tab
-- [Internal links](links.md) open in the same tab
-
-You can use relative links, using source filenames,
-or you can use absolute links for pages as they appear on the final site.
-
-#### Links to auto-generated content
-
-When you link to heading IDs in auto-generated pages, such as CLI reference content,
-you won't get any help from your editor in resolving the anchor names. That's
-because the pages are generated at build-time and your editor or LSP doesn't know
-about them in advance.
-
-## Syntax
-
-```md
-[External links](https://docker.com)
-[Internal links](links.md)
-```
diff --git a/content/contribute/components/lists.md b/content/contribute/components/lists.md
deleted file mode 100644
index 551b47af889b..000000000000
--- a/content/contribute/components/lists.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-description: components and formatting examples used in Docker's docs
-title: Lists
-toc_max: 3
----
-
-## Examples
-
-Use dashes (`-`) or asterisks (`*`) for bullet points.
-
-- Bullet list item 1
-- Bullet list item 2
-- Bullet list item 3
-
-1.  Numbered list item 1. Two spaces between the period and the first letter
-    helps with alignment.
-
-2.  Numbered list item 2. Let's put a note in it.
-
-    > [!NOTE]: We did it!
-
-3.  Numbered list item 3 with a code block in it. You need the blank line before
-    the code block happens.
-
-    ```bash
-    $ docker run hello-world
-    ```
-
-4.  Numbered list item 4 with a bullet list inside it and a numbered list
-    inside that.
-
-    - Sub-item 1
-    - Sub-item 2
-
-      1.  Sub-sub-item 1
-      2.  Sub-sub-item-2 with a table inside it because we like to party!
-          Indentation is super important.
-
-          | Header 1 | Header 2 |
-          | -------- | -------- |
-          | Thing 1  | Thing 2  |
-          | Thing 3  | Thing 4  |
-
-## Markdown
-
-````md
-- Bullet list item 1
-- Bullet list item 2
-- Bullet list item 3
-
-1.  Numbered list item 1. Two spaces between the period and the first letter
-    helps with alignment.
-
-2.  Numbered list item 2. Let's put a note in it.
-
-    > [!NOTE]: We did it!
-
-3.  Numbered list item 3 with a code block in it. You need the blank line before
-    the code block happens.
-
-    ```bash
-    $ docker run hello-world
-    ```
-
-4.  Numbered list item 4 with a bullet list inside it and a numbered list
-    inside that.
-
-    - Sub-item 1
-    - Sub-item 2
-
-      1.  Sub-sub-item 1
-      2.  Sub-sub-item-2 with a table inside it.
-          Indentation is super important.
-
-          | Header 1 | Header 2 |
-          | -------- | -------- |
-          | Thing 1  | Thing 2  |
-          | Thing 3  | Thing 4  |
-````
diff --git a/content/contribute/components/tables.md b/content/contribute/components/tables.md
deleted file mode 100644
index 1631bafb2bb4..000000000000
--- a/content/contribute/components/tables.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-description: components and formatting examples used in Docker's docs
-title: Tables
-toc_max: 3
----
-
-## Example
-
-### Basic table
-
-| Permission level                                                         | Access                                                        |
-| :----------------------------------------------------------------------- | :------------------------------------------------------------ |
-| **Bold** or _italic_ within a table cell. Next cell is empty on purpose. |                                                               |
-|                                                                          | Previous cell is empty. A `--flag` in mono text.              |
-| Read                                                                     | Pull                                                          |
-| Read/Write                                                               | Pull, push                                                    |
-| Admin                                                                    | All of the above, plus update description, create, and delete |
-
-### Feature-support table
-
-| Platform   | x86_64 / amd64 |
-| :--------- | :------------: |
-| Ubuntu     |       ✅       |
-| Debian     |       ✅       |
-| Fedora     |                |
-| Arch (btw) |       ✅       |
-
-## Markdown
-
-### Basic table
-
-```md
-| Permission level                                                         | Access                                                        |
-| :----------------------------------------------------------------------- | :------------------------------------------------------------ |
-| **Bold** or _italic_ within a table cell. Next cell is empty on purpose. |                                                               |
-|                                                                          | Previous cell is empty. A `--flag` in mono text.              |
-| Read                                                                     | Pull                                                          |
-| Read/Write                                                               | Pull, push                                                    |
-| Admin                                                                    | All of the above, plus update description, create, and delete |
-```
-
-The alignment of the cells in the source doesn't really matter. The ending pipe
-character is optional (unless the last cell is supposed to be empty).
-
-### Feature-support table
-
-```md
-| Platform   | x86_64 / amd64 |
-| :--------- | :------------: |
-| Ubuntu     |       ✅       |
-| Debian     |       ✅       |
-| Fedora     |                |
-| Arch (btw) |       ✅       |
-```
diff --git a/content/contribute/components/tabs.md b/content/contribute/components/tabs.md
deleted file mode 100644
index ceca66e690ee..000000000000
--- a/content/contribute/components/tabs.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-description: components and formatting examples used in Docker's docs
-title: Tabs
-toc_max: 3
----
-
-The tabs component consists of two shortcodes:
-
-- `{{</* tabs */>}}`
-- `{{</* tab name="name of the tab" */>}}`
-
-The `{{</* tabs */>}}` shortcode is a parent, component, wrapping a number of `tabs`.
-Each `{{</* tab */>}}` is given a name using the `name` attribute.
-
-You can optionally specify a `group` attribute for the `tabs` wrapper to indicate
-that a tab section should belong to a group of tabs. See [Groups](#groups).
-
-## Example
-
-{{< tabs >}}
-{{< tab name="JavaScript">}}
-
-```js
-console.log("hello world")
-```
-
-{{< /tab >}}
-{{< tab name="Go">}}
-
-```go
-fmt.Println("hello world")
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Markup
-
-````markdown
-{{</* tabs */>}}
-{{</* tab name="JavaScript" */>}}
-
-```js
-console.log("hello world")
-```
-
-{{</* /tab */>}}
-{{</* tab name="Go" */>}}
-
-```go
-fmt.Println("hello world")
-```
-
-{{</* /tab */>}}
-{{</* /tabs */>}}
-````
-
-## Groups
-
-You can optionally specify a tab group on the `tabs` shortcode.
-Doing so will synchronize the tab selection for all of the tabs that belong to the same group.
-
-### Tab group example
-
-The following example shows two tab sections belonging to the same group.
-
-{{< tabs group="code" >}}
-{{< tab name="JavaScript">}}
-
-```js
-console.log("hello world")
-```
-
-{{< /tab >}}
-{{< tab name="Go">}}
-
-```go
-fmt.Println("hello world")
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-{{< tabs group="code" >}}
-{{< tab name="JavaScript">}}
-
-```js
-const res = await fetch("/users/1")
-```
-
-{{< /tab >}}
-{{< tab name="Go">}}
-
-```go
-resp, err := http.Get("/users/1")
-```
-
-{{< /tab >}}
-{{< /tabs >}}
diff --git a/content/contribute/components/videos.md b/content/contribute/components/videos.md
deleted file mode 100644
index 3e2f1bcec558..000000000000
--- a/content/contribute/components/videos.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-description: Learn about guidelines and best practices for videos in docs, and how to add a video component.
-title: Videos
-toc_max: 3
----
-
-## Video guidelines
-
-Videos are used rarely in Docker's documentation. When used, video should complement written text and not be the sole format of documentation. Videos can take longer to produce and be more difficult to maintain than written text or even screenshots, so consider the following before adding video:
-
-- Can you demonstrate a clear customer need for using video?
-- Does the video offer new content, rather than directly reading or re-purposing official documentation?
-- If the video contains user interfaces that may change regularly, do you have a maintenance plan to keep the video fresh?
-- Does the [voice and tone](../style/voice-tone.md) of the video align with the rest of the documentation?
-- Have you considered other options, such as screenshots or clarifying existing documentation?
-- Is the quality of the video similar to the rest of Docker's documentation?
-- Can the video be linked or embedded from the site?
-
-If all of the above criteria are met, you can reference the following best practices before creating a video to add to Docker documentation.
-
-### Best practices
-
-- Determine the audience for your video. Will the video be a broad overview for beginners, or will it be a deep dive into a technical process designed for an advanced user?
-- Videos should be less than 5 minutes long. Keep in mind how long the video needs to be to properly explain the topic, and if the video needs to be longer than 5 minutes, consider text, diagrams, or screenshots instead. These are easier for a user to scan for relevant information.
-- Videos should adhere to the same standards for accessibility as the rest of the documentation.
-- Ensure the quality of your video by writing a script (if there's narration), making sure multiple browsers and URLs aren't visible, blurring or cropping out any sensitive information, and using smooth transitions between different browsers or screens.
-
-Videos are not hosted in the Docker documentation repository. To add a video, you can use a [link](./links.md) to hosted content, or embed using an [iframe](#iframe).
-
-
-## iframe
-
-To embed a video on a docs page, use an `<iframe>` element:
-
-```html
-<iframe
-  class="border-0 w-full aspect-video mb-8"
-  allow="fullscreen"
-  title=""
-  src=""
-  ></iframe>
-```
-
-## asciinema
-
-`asciinema` is a command line tool for recording terminal sessions. The
-recordings can be embedded on the documentation site. These are similar to
-`console` code blocks, but since they're playable and scrubbable videos, they
-add another level of usefulness over static codeblocks in some cases. Text in
-an `asciinema` "video" can also be copied, which makes them more useful.
-
-Consider using an `asciinema` recording if:
-
-- The input/output of the terminal commands are too long for a static example
-  (you could also consider truncating the output)
-- The steps you want to show are easily demonstrated in a few commands
-- Where the it's useful to see both inputs and outputs of commands
-
-To create an `asciinema` recording and add it to docs:
-
-1. [Install](https://docs.asciinema.org/getting-started/) the `asciinema` CLI
-2. Run `asciinema auth` to configure your client and create an account
-3. Start a new recording with `asciinema rec`
-4. Run the commands for your demo and stop the recording with `<C-d>` or `exit`
-5. Upload the recording to <asciinema.org>
-6. Embed the player with a `<script>` tag using the **Share** button on <asciinema.org>
diff --git a/content/contribute/file-conventions.md b/content/contribute/file-conventions.md
deleted file mode 100644
index c2166ca2bf88..000000000000
--- a/content/contribute/file-conventions.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: Source file conventions
-description: How new .md files should be formatted
-keywords: source file, contribute, style guide
-weight: 30
----
-
-## File name
-
-When you create a new .md file for new content, make sure: 
-- File names are as short as possible
-- Try to keep the file name to one word or two words
-- Use a dash to separate words. For example:
-  - `add-seats.md`  and `remove-seats.md`.
-  - `multiplatform-images` preferred to `multi-platform-images`.
-
-## Front matter
-
-The front matter of a given page is in a section at the top of the Markdown
-file that starts and ends with three hyphens. It includes YAML content. The
-following keys are supported. The title, description, and keywords are required.
-
-| Key             | Required | Description                                                                                                                                                                                                    |
-|-----------------|----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| title           | yes      | The page title. This is added to the HTML output as a `<h1>` level header.                                                                                                                                     |
-| description     | yes      | A sentence that describes the page contents. This is added to the HTML metadata. It’s not rendered on the page.                                                                                                |
-| keywords        | yes      | A comma-separated list of keywords. These are added to the HTML metadata.                                                                                                                                      |
-| aliases         | no       | A YAML list of pages which should redirect to the current page. At build time, each page listed here is created as an HTML stub containing a 302 redirect to this page.                                        |
-| notoc           | no       | Either `true` or `false`. If `true`, no in-page TOC is generated for the HTML output of this page. Defaults to `false`. Appropriate for some landing pages that have no in-page headings.                      |
-| toc_min         | no       | Ignored if `notoc` is set to `true`. The minimum heading level included in the in-page TOC. Defaults to `2`, to show `<h2>` headings as the minimum.                                                           |
-| toc_max         | no       | Ignored if `notoc` is set to `false`. The maximum heading level included in the in-page TOC. Defaults to `3`, to show `<h3>` headings. Set to the same as `toc_min` to only show `toc_min` level of headings.  |
-| sitemap         | no       | Exclude the page from indexing by search engines. When set to `false`, the page is excluded from `sitemap.xml`, and a `<meta name="robots" content="noindex"/>` header is added to the page.                   |
-| sidebar.reverse | no       | This parameter for section pages changes the sort order of the pages in that section. Pages that would normally appear at the top, by weight or by title, will instead appear near the bottom, and vice versa. |
-| sidebar.goto    | no       | Set this to change the URL that the sidebar should point to for this entry. See [pageless sidebar entries](#pageless-sidebar-entries).                                                                         |
-| sidebar.badge   | no       | Set this to add a badge to the sidebar entry for this page. This param option consists of two fields: `badge.text` and `badge.color`.                                                                          |
-
-Here's an example of a valid (but contrived) page metadata. The order of
-the metadata elements in the front matter isn't important.
-
-```liquid
----
-description: Instructions for installing Docker Engine on Ubuntu
-keywords: requirements, apt, installation, ubuntu, install, uninstall, upgrade, update
-title: Install Docker Engine on Ubuntu
-aliases:
-- /ee/docker-ee/ubuntu/
-- /engine/installation/linux/docker-ce/ubuntu/
-- /engine/installation/linux/docker-ee/ubuntu/
-- /engine/installation/linux/ubuntu/
-- /engine/installation/linux/ubuntulinux/
-- /engine/installation/ubuntulinux/
-- /install/linux/docker-ce/ubuntu/
-- /install/linux/docker-ee/ubuntu/
-- /install/linux/ubuntu/
-- /installation/ubuntulinux/
-toc_max: 4
----
-```
-
-## Body
-
-The body of the page (with the exception of keywords) starts after the front matter.
-
-### Text length
-
-Splitting long lines (preferably up to 80 characters) can make it easier to provide feedback on small chunks of text.
-
-## Pageless sidebar entries
-
-If you want to add an entry to the sidebar, but you want the link to point somewhere else, you can use the `sidebar.goto` parameter.
-This is useful in combination with `build.render` set to `always`, which creates a pageless entry in the sidebar that links to another page.
-
-```md
----
-title: Dummy sidebar link
-build:
-  render: never
-sidebar:
-  goto: /some/other/page/
-weight: 30
----
-```
diff --git a/content/contribute/guides.md b/content/contribute/guides.md
deleted file mode 100644
index fc364d676457..000000000000
--- a/content/contribute/guides.md
+++ /dev/null
@@ -1,257 +0,0 @@
----
-title: Guidelines for writing Docker usage guides
-linkTitle: Write a Docker guide
-description: Learn how to write guides for learning about Docker, with Docker.
----
-
-<!-- vale Docker.We = NO -->
-
-This guide provides instructions and best practices for writing tutorial-style
-usage guides that help users achieve specific goals using Docker. These guides
-will be featured in the [guides section](/guides/_index.md) of the website,
-alongside our product manuals and reference materials.
-
-Our documentation is written in Markdown, with YAML front matter for metadata.
-We use [Hugo](https://gohugo.io) to build the website. For more information
-about how to write content for Docker docs, refer to our
-[CONTRIBUTING.md](https://github.com/docker/docs/tree/main/CONTRIBUTING.md).
-
-## Purpose of the guides
-
-Our usage guides aim to:
-
-- Educate users on how to leverage Docker in various contexts.
-- Provide practical, hands-on experience through step-by-step tutorials.
-- Help users achieve specific goals relevant to their interests or projects.
-
-## Audience
-
-- Experience levels: From beginners to advanced users.
-- Roles: Developers, system administrators, DevOps engineers, and more.
-- Technologies: Various programming languages and frameworks.
-
-## Metadata for guides
-
-Each guide must include a metadata section at the beginning of the document.
-This metadata helps users discover and filter guides based on their interests
-and needs.
-
-### Example metadata format
-
-```yaml
----
-title: Deploy a machine learning model with Docker
-linkTitle: Docker for ML deployment
-description: Learn how to containerize and deploy a machine learning model using Docker.
-summary: |
-  This guide walks you through the steps to containerize a machine learning
-  model and deploy it using Docker, enabling scalable and portable AI
-  solutions.
-tags: [machine-learning, deployment]
-languages: [python]
-params:
-  time: 30 minutes
----
-```
-
-### Metadata fields
-
-- `title` (required): The main title of the guide in sentence case.
-- `linkTitle` (optional): A shorter title used in navigation menus.
-- `description` (required): A concise description for SEO purposes.
-- `summary` (required): A brief overview of the guide's content.
-- `languages` \* (optional): List of programming languages used.
-- `tags` \* (optional): Domains or subject areas covered.
-- `params`
-  - `time` (optional): Estimated reading or completion time.
-
-\* Do apply at least one of the `languages` or `tags` taxonomies. The values
-are used to associate the page with the filter options on the guides landing
-page.
-
-## Document structure
-
-Our guides emphasize learning by doing. Depending on the type of guide, the
-structure may vary to best suit the content and provide a smooth learning
-experience.
-
-All guides live directly under the `content/guides/` directory in the Docker
-docs repository. Guides can either be a single page or multiple pages. In the
-case of multi-page guides, every page is a step in a sequential workflow.
-
-If you're creating a single-page guide, create a single markdown file in the
-guides directory:
-
-```bash
-# Create the file
-touch content/guides/my-docker-guide.md
-# or if you have Hugo installed:
-hugo new content/guides/my-docker-guide.md
-```
-
-To create a multi-page guide, create a directory where each page is a markdown
-file, with an `_index.md` file representing the introduction to the guide.
-
-```bash
-# Create the index page for the guide
-mkdir content/guides/my-docker-guide.md
-touch content/guides/my-docker-guide/_index.md
-# or if you have Hugo installed:
-hugo new content/guides/my-docker-guide/_index.md
-```
-
-Then create the pages for the guide under `content/guides/<dir>/<page>.md` as
-needed. The [metadata](#metadata-for-guides) lives on the `_index.md` page (you
-don't need to assign metadata to individual pages).
-
-### Guides for specific frameworks or languages
-
-For guides that demonstrate how to use Docker with a particular framework or
-programming language, consider the following outline:
-
-1. **Introduction**
-   - Briefly introduce the framework or language in the context of Docker.
-   - Explain what the user will achieve by the end of the guide.
-   - List required software, tools, and knowledge.
-2. **Development setup**
-   - Guide the user through setting up a development environment.
-   - Include instructions on writing or obtaining sample code.
-   - Show how to run containers for local development.
-3. **Building the application**
-   - Explain how to create a Dockerfile tailored to the application.
-   - Provide step-by-step instructions for building the Docker image.
-   - If applicable, show how to test the application using Docker.
-4. **Deploying with Docker**
-   - Show how to run the application in a Docker container.
-   - Discuss configuration options and best practices.
-5. **Best practices and conclusions**
-   - Offer tips for optimizing Docker usage with the framework or language.
-   - Summarize key takeaways, suggest next steps, and further reading.
-
-### Use-case guides
-
-For guides focused on accomplishing a specific goal or use case with Docker
-(e.g., deploying a machine learning model), use a flexible outline that ensures
-a logical flow.
-
-The following outline is an example. The structure should be adjusted to best
-fit the content and ensure a clear, logical progression. Depending on the
-subject matter of your use-case guide, the exact structure will vary.
-
-1. **Introduction**
-   - Describe the problem or goal.
-   - Explain the benefits of using Docker in this context.
-2. **Prerequisites**
-   - List required tools, technologies, and prior knowledge.
-3. **Setup**
-   - Provide instructions for setting up the environment.
-   - Include any necessary configuration steps.
-4. **Implementation**
-   - Walk through the process step by step.
-   - Use code snippets and explanations to illustrate key points.
-5. **Running or deploying the application**
-   - Guide the user on how to execute or deploy the solution.
-   - Discuss any verification steps to ensure success.
-6. **Conclusion**
-   - Recap what was achieved.
-   - Suggest further reading or advanced topics.
-
-## Example code
-
-If you create an example repository with source code to accompany your guide,
-we strongly encourage you to publish that repository under the
-[dockersamples](https://github.com/dockersamples) organization on GitHub.
-Publishing your source code under this organization, rather than your personal
-account, ensures that the source code remains accessible to the maintainers of
-the documentation site after publishing. In the event of a bug or an issue in
-the guide, the documentation team can more easily update the guide and its
-corresponding example repository.
-
-Hosting the examples in the official samples namespace also helps secure trust
-with users who are reading the guide.
-
-### Publish a repository under `dockersamples`
-
-To publish your repository under the `dockersamples` organization, use the
-[dockersamples template](https://github.com/dockersamples/sample-app-template)
-to initiate a sample repository under your personal namespace. When you've
-finished drafting your content and opened your pull request for the
-documentation, we can transfer the repository to the dockersamples
-organization.
-
-## Writing style
-
-Use [sentence case](/contribute/style/formatting.md#capitalization) for all
-headings and titles. This means only the first word and proper nouns are
-capitalized.
-
-### Voice and tone
-
-- **Clarity and conciseness**: Use simple language and short sentences to convey information effectively.
-- **Active voice**: Write in the active voice to engage the reader (e.g., "Run the command" instead of "The command should be run").
-- **Consistency**: Maintain a consistent tone and terminology throughout the guide.
-
-For detailed guidelines, refer to our [voice and tone documentation](/contribute/style/voice-tone.md).
-
-### Formatting conventions
-
-- **Headings**: Use H2 for main sections and H3 for subsections, following sentence case.
-- **Code examples**: Provide complete, working code snippets with syntax highlighting.
-- **Lists and steps**: Use numbered lists for sequential steps and bullet points for non-sequential information.
-- **Emphasis**: Use bold for UI elements (e.g., **Button**), and italics for emphasis.
-- **Links**: Use descriptive link text (e.g., [Install Docker](/get-started/get-docker.md)).
-
-For more details, see our [content formatting guidelines](/contribute/style/formatting.md)
-and [grammar and style rules](/contribute/style/grammar.md).
-
-## Best practices
-
-- **Test all instructions**
-  - Ensure all code and commands work as expected.
-  - Verify that the guide can be followed successfully from start to finish.
-- **Relevance**
-  - Focus on real-world applications and scenarios.
-  - Keep the content up-to-date with the latest Docker versions.
-- **Troubleshooting tips**
-  - Anticipate common issues and provide solutions or references.
-- **Visual aids**
-  - Include screenshots or diagrams where they enhance understanding.
-  - Add captions and alt text for accessibility.
-- **Third-party tools**
-  - Avoid requiring the user to install third-party tools or modify their local development environment.
-  - Prefer using containerized tools and methods where applicable (e.g. `docker exec`).
-  - Some tools are reasonable to assume as installed or prerequisites for guides, such as Node.js and npm. Use your better judgement.
-
-## Additional resources
-
-- **Existing guides**
-  - Refer to [Docker Guides](/guides/_index.md) for examples and inspiration.
-- **Style guides**
-  - [Voice and tone](/contribute/style/voice-tone.md)
-  - [Content formatting](/contribute/style/formatting.md)
-  - [Grammar and style](/contribute/style/grammar.md)
-
-## Submission process
-
-- **Proposal**
-  - Raise an issue on the [Docker documentation GitHub repository](https://github.com/docker/docs)
-    with a request to add a new guide.
-  - Once the proposal has been accepted, start writing your guide by forking
-    the repository and creating a branch for your work.
-
-    > [!NOTE]
-    > Avoid contributing from the `main` branch of your fork, since it makes it
-    > more difficult for maintainers to help you fix any issues that may arise.
-
-- **Review**
-  - Proofread your guide for grammar, clarity, and adherence to the guidelines.
-  - Once your draft is ready, raise a pull request, with a reference to the
-    original issue.
-  - The Docker documentation team and subject matter experts will review your
-    submission and provide feedback on the pull request directly.
-- **Publishing**
-  - Your guide will be published on the Docker documentation website when the
-    reviewers have approved and merged your pull request.
-
-Thank you for contributing to the Docker community. Your expertise helps users
-worldwide harness the power of Docker.
diff --git a/content/contribute/style/_index.md b/content/contribute/style/_index.md
deleted file mode 100644
index 92afe3cb3be3..000000000000
--- a/content/contribute/style/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-build:
-  render: never
-title: Style guide
-weight: 20
----
\ No newline at end of file
diff --git a/content/contribute/style/formatting.md b/content/contribute/style/formatting.md
deleted file mode 100644
index 5cc5e1d3f021..000000000000
--- a/content/contribute/style/formatting.md
+++ /dev/null
@@ -1,177 +0,0 @@
----
-title: Formatting guide
-description: Formatting guidelines for technical documentation
-keywords: formatting, style guide, contribute
-toc_max: 2
-weight: 20
----
-
-## Headings and subheadings
-
-Readers pay fractionally more attention to headings, bulleted lists, and links, so it's important to ensure the first two to three words in those items "front load" information as much as possible.
-
-### Best practice
-
-- Headings and subheadings should let the reader know what they will find on the page.
-- They should describe succinctly and accurately what the content is about.
-- Headings should be short (no more than eight words), to the point and written in plain, active language.
-- You should avoid puns, teasers, and cultural references.
-- Skip leading articles (a, the, etc.)
-
-## Page title
-
-Page titles should be action orientated. For example: - _Enable SCIM_ - _Install Docker Desktop_
-
-### Best practice
-
-- Make sure the title of your page and the table of contents (TOC) entry matches.
-- If you want to use a ‘:’ in a page title in the table of contents (\_toc.yaml), you must wrap the entire title in “” to avoid breaking the build.
-- If you add a new entry to the TOC file, make sure it ends in a trailing slash (/). If you don't, the page won't show the side navigation.
-
-## Images
-
-Images, including screenshots, can help a reader better understand a concept. However, you should use them sparingly as they tend to go out-of-date.
-
-### Best practice
-
-- When you take screenshots:
-  - Don’t use lorem ipsum text. Try to replicate how someone would use the feature in a real-world scenario, and use realistic text.
-  - Capture only the relevant UI. Don’t include unnecessary white space or areas of the UI that don’t help illustrate the point.
-  - Keep it small. If you don’t need to show the full width of the screen, don’t.
-  - Review how the image renders on the page. Make sure the image isn’t blurry or overwhelming.
-  - Be consistent. Coordinate screenshots with the other screenshots already on a documentation page for a consistent reading experience.
-  - To keep the Git repository light, compress the images (losslessly). Be sure to compress the images before adding them to the repository. Compressing images after adding them to the repository actually worsens the impact on the Git repository (however, it still optimizes the bandwidth during browsing).
-  - Don't forget to remove images from the repository that are no longer used.
-
-For information on how to add images to your content, see [Useful component and formatting examples](../components/images.md).
-
-## Links
-
-Be careful not to create too many links, especially within body copy. Excess links can be distracting or send readers away from the current page.
-
-When people follow links, they can often lose their train of thought and fail to return to the original page, despite not having absorbed all the information it contains.
-
-The best links offer readers another way to scan information.
-
-### Best practice
-
-- Use plain language that doesn't mislead or promise too much.
-- Be short and descriptive (around five words is best).
-- Allow people to predict (with a fair degree of confidence) what they will get if they select a link. Mirror the heading text on the destination page in links whenever possible.
-- Front-load user-and-action-oriented terms at the beginning of the link (Download our app).
-- Avoid generic calls to action (such as click here, find out more).
-- Don't include any end punctuation when you hyperlink text (for example, periods, question marks, or exclamation points).
-- Don't make link text italics or bold, unless it would be so as normal body copy.
-
-For information on how to add links to your content, see [Useful component and formatting examples](../components/links.md).
-
-## Code and code samples
-
-Format the following as code: Docker commands, instructions, and filenames (package names).
-
-To apply inline code style, wrap the text in a single backtick (`).
-
-For information on how to add code blocks to your content, see [Useful component and formatting examples](../components/code-blocks.md).
-
-### Best practice for commands
-
-- Command prompt and shell:
-  - For a non-privileged shell, prefix commands in code blocks with the $ prompt symbol.
-  - For a privileged shell, prefix commands in code blocks with the # prompt symbol.
-  - For a remote shell, add the context of the remote machine and exclude the path. For example, `user@host $`.
-  - Specify the Windows shell (Command Prompt, PowerShell, or Git Bash), when you add any Windows-specific command. It's not necessary to include a command for each Windows shell.
-  - Use tabs when you add commands for multiple operating systems or shells. For information on how to add tabs to your content, see [Tabs](../components/tabs.md).
-- Commands that users will copy and run:
-  - Add a single command per code block if a command produces output or requires the user to verify the results.
-  - Add command output to a separate code block from the command.
-- Commands that users won't copy and run:
-  - Use POSIX-compatible syntax. It's not necessary to include Windows syntax.
-  - Wrap optional arguments in square brackets ( [ ] ).
-  - Use pipes ( \| ) between mutually exclusive arguments.
-  - Use three dots ( ... ) after repeated arguments.
-
-### Best practice for code
-
-- Indent code blocks by 3 spaces when you nest a code block under a list item.
-- Use three dots ( ... ) when you omit code.
-
-## Callouts
-
-Use callouts to emphasize selected information on a page.
-
-### Best practice
-
-- Format the word Warning, Important, or Note in bold. Don't bold the content within the callout.
-- It's good practice to avoid placing a lot of text callouts on one page. They can create a cluttered appearance if used to excess, and you'll diminish their impact.
-
-| Text callout | Use case scenario                                                                                                                                                                   | Color or callout box |
-| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- |
-| Warning      | Use a Warning tag to signal to the reader where actions may cause damage to hardware or software loss of data.                                                                      | Red                  |
-|              | ✅ Example: Warning: When you use the docker login command, your credentials are stored in your home directory in .docker/config.json. The password is base64-encoded in this file. |                      |
-| Important    | Use an Important tag to signal to the reader where actions may cause issues of a lower magnitude.                                                                                   | Yellow               |
-|              | ✅ Example: Update to the Docker Desktop terms                                                                                                                                      |                      |
-| Note         | Use the Note tag for information that may not apply to all readers, or if the information is tangential to a topic.                                                                 | Blue                 |
-|              | ✅ Example: Deleting a repository deletes all the images it contains and its build settings. This action cannot be undone.                                                          |                      |
-
-For information on how to add callouts to your content, see [Useful component and formatting examples](../components/call-outs.md).
-
-## Navigation
-
-When documenting how to navigate through the Docker Desktop or Docker Hub UI:
-
-- Always use location, then action. For example:
-  _From the **Visibility** drop-down list (location), select Public (action)._
-- Be brief and specific. For example:
-  Do: _Select **Save**._
-  Don't: _Select **Save** for the changes to take effect._
-- If a step must include a reason, start the step with it. This helps the user scan more quickly.
-  Do: _To view the changes, in the merge request, select the link._
-  Don't: _Select the link in the merge request to view the changes_
-
-## Optional steps
-
-If a step is optional, start the step with the word Optional followed by a period.
-
-For example:
-
-_1. Optional. Enter a description for the job._
-
-## Placeholder text
-
-You might want to provide a command or configuration that uses specific values.
-
-In these cases, use < and > to call out where a reader must replace text with their own value. For example:
-
-`docker extension install <name-of-your-extension>`
-
-## Tables
-
-Use tables to describe complex information in a straightforward manner.
-
-Note that in many cases, an unordered list is enough to describe a list of items with a single, simple description per item. But, if you have data that’s best described by a matrix, tables are the best choice.
-
-### Best practice
-
-- Use sentence case for table headings.
-- To keep tables accessible and scannable, tables shouldn't have any empty cells. If there is no otherwise meaningful value for a cell, consider entering N/A for ‘not applicable’ or None.
-
-For information on how to add tables to your content, see [Useful component and formatting examples](../components/tables.md).
-
-## Referring to file types
-
-When you're discussing a file type, use the formal name of the type. Don't use the filename extension to refer generically to the file type.
-
-    | Correct | Incorrect |
-    | --- | --- |
-    | a PNG file | a .png file |
-    | a Bash file | an .sh file |
-
-## Referring to units
-
-When you're referring to units of measurement, use the abbreviated form in all caps, with a space between the value and the unit. For example:
-
-    | Correct | Incorrect |
-    | --- | --- |
-    | 10 GB | 10GB |
-    | 10 GB | 10 gb |
-    | 10 GB | 10 gigabytes |
diff --git a/content/contribute/style/grammar.md b/content/contribute/style/grammar.md
deleted file mode 100644
index 4e0bcb5368fd..000000000000
--- a/content/contribute/style/grammar.md
+++ /dev/null
@@ -1,175 +0,0 @@
----
-title: Grammar and style
-description: Grammar and style guidelines for technical documentation
-keywords: grammar, style, contribute
-toc_max: 2
-weight: 10
----
-
-Docker documentation should always be written in US English with US grammar. 
-
-## Acronyms and initialisms
-
-An acronym is an abbreviation you would speak as a word, for example, ROM (for read only memory). Other examples include radar and scuba, which started out as acronyms but are now considered words in their own right.
-
-An initialism is a type of acronym that comprises a group of initial letters used as an abbreviation for a name or expression. If you were using the acronym in a spoken conversation, you would enunciate each letter: H-T-M-L for Hypertext Markup Language.
-
-### Best practice
-
-- Spell out lesser-known acronyms or initialisms on first use, then follow with the acronym or initialism in parentheses. After this, throughout the rest of your page or document, use the acronym or initialism alone.
-> ‘You can use single sign-on (SSO) to sign in to Notion. You may need to ask your administrator to enable SSO.’
-- Where the acronym or initialism is more commonly used than the full phrase, for example, URL, HTML, you don't need to follow this spell-it-out rule.
-- Use all caps for acronyms of file types (a JPEG file).
-- Don't use apostrophes for plural acronyms. ✅URLs ❌URL’S
-- Avoid using an acronym for the first time in a title or heading. If the first use of the acronym is in a title or heading, introduce the acronym (in parentheses, following the spelled-out term) in the first body text that follows.
-
-## Bold and italics
-
-Unless you're referring to UI text or user-defined text, you shouldn't add emphasis to text. Clear, front-loaded wording makes the subject of a sentence clear.
-
-### Best practice
-
-- Don't use bold to refer to a feature name.
-- Use italics sparingly, as this type of formatting can be difficult to read in digital experiences.
-Notable exceptions are titles of articles, blog posts, or specification documents.
-
-## Capitalization
-
-Use sentence case for just about everything. Sentence case means capitalizing only the first word, as you would in a standard sentence.
-
-The following content elements should use sentence case:
-
-- Titles of webinars and events
-- Headings and subheadings in all content types
-- Calls to action
-- Headers in boxed text
-- Column and row headers in tables
-- Links
-- Sentences (of course)
-- Anything in the UI including navigation labels, buttons, headings
-
-### Best practice
-
-- As a general rule, it's best to avoid the use of ALL CAPITALS in most content types. They are more difficult to scan and take up more space. While all caps can convey emphasis, they can also give the impression of shouting.
-- If a company name is all lowercase or all uppercase letters, follow their style, even at the beginning of sentences: DISH and bluecrux. When in doubt, check the company's website.
-- Use title case for Docker solutions: Docker Extensions, Docker Hub.
-- Capitalize a job title if it immediately precedes a name (Chief Executive Officer Scott Johnston).
-- Don't capitalize a job title that follows a name or is a generic reference (Scott Johnston, chief executive officer of Docker).
-- Capitalize department names when you refer to the name of a department, but use lower case if you are talking about the field of work and not the actual department.
-- When referring to specific user interface text, like a button label or menu item, use the same capitalization that’s displayed in the user interface. 
-
-## Contractions
-
-A contraction results from letters being left out from the original word or phrase, such as you're for you are or it's for it is.
-
-Following our conversational approach, it's acceptable to use contractions in almost all content types. Just don't get carried away. Too many contractions in a sentence can make it difficult to read.
-
-### Best practice
-
-- Stay consistent - don't switch between contractions and their spelled-out equivalents in body copy or UI text.
-- Avoid negative contractions (can't, don't, wouldn't, and shouldn't) whenever possible. Try to rewrite your sentence to align with our helpful approach that puts the focus on solutions, not problems.
-- Never contract a noun with is, does, has, or was as this can make it look like the noun is possessive. Your container is ready. Your container’s ready.
-
-## Dangling modifiers
-
-Avoid [dangling modifiers](https://en.wikipedia.org/wiki/Dangling_modifier), where the subject of a clause's verb is unclear:
-
-- ❌ After enabling auto-log-out, your users are logged out.
-- ✅ When you enable auto-log-out, your users are logged out.
-
-## Dates
-
-You should use the U.S. format of month day, year format for dates: June 26, 2021.
-
-When possible, use the month's full name (October 1, 2022). If there are space constraints, use 3-letter abbreviations followed by a period (Oct. 1. 2022).
-
-## Decimals and fractions
-
-In all UI content and technical documentation, use decimals instead of fractions.
-
-### Best practice
-
-- Always carry decimals to at least the hundredth place (33.76).
-- In tables, align decimals on the decimal point.
-- Add a zero before the decimal point for decimal fractions less than one (0.5 cm).
-
-## Lists
-
-Lists are a great way to break down complex ideas and make them easier to read and scan.
-
-### Best practice
-
-- Bulleted lists should contain relatively few words or short phrases. For most content types, limit the number of items in a list to five.
-- Don’t add commas (,) or semicolons (;) to the ends of list items.
-- Some content types may use bulleted lists that contain 10 items, but it's preferable to break longer lists into several lists, each with its own subheading or introduction.
-- Never create a bulleted list with only one bullet, and never use a dash to indicate a bulleted list.
-- If your list items are fragments, capitalize the list items for ease of scanning but don't use terminal punctuation. 
-Example:
-    
-    I went to the shops to buy:
-    
-    - Milk
-    - Flour
-    - Eggs
-- Make sure all your list items are parallel. This means you should structure each list item in the same way. They should all be fragments, or they should all be complete sentences. If you start one list item with a verb, then start every list item with a verb.
-- Every item in your list should start with a capital letter unless they’re parameters or commands.
-- Nested sequential lists are labeled with lowercase letters. For example:
-    1. Top level
-    2. Top level
-        1. Child step
-        2. Child step
-
-## Numbers
-
-When you work with numbers in content, the best practices include:
-
-- Spell out the numbers one to nine, except in units of measure such as 4 MB.
-- Represent numbers with two or more digits as numerals (10, 625, 773,925).
-- Recast a sentence, rather than begin it with a number (unless it's a year).
-- When you cite numbers in an example, write them out as they appear in any accompanying screenshots.
-- Write numbers out as they appear on the platform when you cite them in an example.
-- To refer to large numbers in abstract (such as thousands, millions, and billions), use a combination of words and numbers. Don't abbreviate numeric signifiers.
-- Avoid using commas in numbers because they can represent decimals in different cultures. For numbers that are five digits or more, use a space to separate.
-    
-    
-    | Correct | Incorrect |
-    | --- | --- |
-    | 1000 | 1,000 |
-    | 14 586 | 14,586 |
-    | 1 390 680 | 1,390,680 |
-
-### Versions
-
-When writing version numbers for release notes, use the following example:
-
-- version 4.8.2
-- v1.0
-- Docker Hub API v2
-
-## Punctuation
-
-### Colons and semicolons
-
-- Use colons to: introduce a list inline in a sentence; introduce a bulleted or numbered list; and provide an explanation.
-- Don't use semicolons. Use two sentences instead.
-
-### Commas
-
-- Use the serial or Oxford comma - a comma before the coordinating conjunction (and, or) in a list of three or more things.
-- If a series contains more than three items or the items are long, consider a bulleted list to improve readability.
-
-### Dashes and hyphens
-
-- Use the em dash (-) sparingly when you want the reader to pause, to create parenthetical statements, or to emphasize specific words or phrases. Always put a space on either side of the em dash.
-- Use an en dash (-) to indicate spans of numbers, dates, or time.
-- Use a hyphen to join two or more words to form compound adjectives that precede a noun. The purpose of joining words to form a compound adjective is to differentiate the meaning from the adjectives used separately (for example, ‘up-to-date documentation’ ‘lump-sum payment’, and ‘well-stocked cupboard’. You can also use a hyphen to:
-    - Avoid awkward doubling of vowels. For example ‘semi-independence*’,* or ‘re-elect’.
-    - Prevent misreading of certain words. For example ‘Re-collect’ means to collect again; without a hyphen the word recollect has a different meaning.
-
-### Exclamation marks
-
-Avoid the use of exclamation marks.
-
-### Parentheses
-
-Don't use parentheses in technical documentation. They can reduce the readability of a sentence.
diff --git a/content/contribute/style/recommended-words.md b/content/contribute/style/recommended-words.md
deleted file mode 100644
index ae4db752d256..000000000000
--- a/content/contribute/style/recommended-words.md
+++ /dev/null
@@ -1,182 +0,0 @@
----
-title: Recommended word list
-description: Recommended word list for Technical documentation
-keywords: recommended word list, style guide, contribute
-weight: 30
----
-
-To help ensure consistency across documentation, the Technical Writing team recommends these wording choices.
-
-#### & (ampersand)
-
-Don't use `&` instead of `and` in headings, text, navigation, UI copy, or tables of contents.
-
-#### above
-
-Try to avoid using `above` when referring to an example or table in a documentation page. If required, use `previous` instead.
-
-For example:
-
-_In the previous example, the dog had fleas._
-
-#### account name
-
-Don't use. Instead, use `username`.
-
-#### admin
-
-Write out `administrator` on first use. Use `admin` if it's the name of a UI label or other element.
-
-#### allows
-
-Don't use. Instead, use `lets`.
-
-#### as of this writing
-
-Avoid because the writing itself implies this phrase. The phrase can also prematurely share product or feature strategy or inappropriately imply that a product or feature might change.
-
-#### below
-
-Try to avoid `below` when referring to an example or table on a documentation page. If required, use `following` instead.
-
-For example:
-
-_In the following example, the dog had fleas._
-
-#### checkbox
-
-Use one word for `checkbox`. Don't use `check box`.
-
-You select (not check or enable) and clear (not deselect or disable) checkboxes.
-
-#### click
-
-Don't use `click`. Instead, use `select` with buttons, links, menu items, and lists.
-
-Select applies to more devices, while click is more specific to a mouse.
-
-#### currently
-
-Don't use `currently` when talking about the product or its features. The documentation describes the product as it is today.
-
-#### disable
-
-Don't use `disable`. Implies that disability is a less-desired or negative state.
-
-Instead, use `turn off` or `toggle off`.
-
-There are times with more technical features when the development team uses `disable`, and in these cases, it's OK to use the term.
-
-#### earlier
-
-Use `earlier` when talking about version numbers.
-
-Use:
-
-_In Docker Desktop 4.1 and earlier._
-
-Instead of:
-
-_In Docker Desktop 4.1 and lower._
-
-#### easy, easily
-
-What might be easy for you might not be easy for others. Try eliminating this word from the sentence because usually the same meaning can be conveyed without it.
-
-<!-- markdownlint-disable no-trailing-punctuation -->
-
-#### e.g.
-
-<!-- markdownlint-enable no-trailing-punctuation -->
-
-Don't use. Instead, use phrases like `for example` or `such as`.
-
-#### enable
-
-Don't use `enable`. Implies that disability is a less-desired or negative state.
-
-Instead, use `turn on` or `toggle on`.
-
-There are times with more technical features when the development team uses `enable`, and in these cases, it's OK to use the term.
-
-#### execute
-
-Avoid where possible. Use `run` instead.
-
-#### later
-
-Use `later` when talking about version numbers.
-
-Use:
-
-_In Docker Desktop 4.1 and later._
-
-Instead of:
-
-_In Docker Desktop 4.1 and higher…_ or _In Docker Desktop 4.1 and above…_
-
-#### please
-
-Don't use `please` in the normal course of explaining how to use a product, even if you're explaining a difficult task. Also don't use the phrase `please note`.
-
-#### register
-
-Use `sign up` instead of register when talking about creating an account.
-
-#### repo
-
-Don't use. Instead, use `repository`.
-
-#### respectively
-
-Avoid `respectively` and be more precise instead.
-
-#### scroll
-
-Avoid. Use a verb phrase such as _move through_ or _navigate to_ instead, if the context is clear.
-
-#### sign in
-
-Use `sign in` instead of `sign on`, `signon`, `log on`, `logon`, or `log in`, `login`. If the user interface uses different words, use those.
-
-Use `sign in to` instead of `sign into`.
-
-#### sign up
-
-Use `sign up` or `create account` instead of `register` when talking about creating an account.
-
-#### tab versus view
-
-Use `view` when referring to a major section in a UI. Use `tab` when referring to a sub-section in the UI. 
-
-For example, in Docker Desktop, the **Images** view and the **Local** tab.
-
-#### toggle
-
-You turn on or turn off a toggle. For example:
-
-_Turn on the dark mode toggle._
-
-#### upgrade
-
-Use `upgrade` when describing a higher subscription tier
-
-#### vs
-
-Don't use `vs` or `vs.` as an abbreviation for versus; instead, use the unabbreviated `versus`.
-
-#### we
-
-Try to avoid `we` and focus instead on how the user can carry out something in Docker.
-
-Use:
-
-_Use widgets when you have work you want to organize._
-
-Instead of:
-
-_We created a feature for you to add widgets._
-
-#### wish
-
-Don't use. Use `want` instead.
diff --git a/content/contribute/style/terminology.md b/content/contribute/style/terminology.md
deleted file mode 100644
index 6af94fd57271..000000000000
--- a/content/contribute/style/terminology.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: Docker terminology
-description: Docker specific terminology and definitions
-keywords: terminology, style guide, contribute
----
-
-#### `compose.yaml`
-
-The current designation for the Compose file, as it's a file, format as code.
-
-#### Compose plugin
-
-The compose plugin as an add-on (for Docker CLI) that can be enabled/disabled.
-
-#### Digest
-
-A long string that’s automatically created every time you push an image. You can pull an image by Digest or by Tag.
-
-#### Docker Compose
-
-Use when we talk about the application, or all the functionality associated with the application.
-
-#### `docker compose`
-
-Use code formatting for referring to the commands in text and command usage examples/code samples.
-
-#### Docker Compose CLI
-
-Use when referring to family of Compose commands as offered from the Docker CLI.
-
-#### K8s
-
-Don't use. Use `Kubernetes` instead.
-
-#### Multi-platform
-
-(broad meaning) Mac vs Linux vs Microsoft but also pair of platform architecture such as in Linux/amd64 and Linux/arm64; (narrow meaning) Windows/Linux/macOS.
-
-#### Multi-architecture / multi-arch
-
-To use when referring specifically to CPU architecture or something that is hardware-architecture-based. Avoid using it as meaning the same as multi-platform.
-
-#### Member
-
-A user of Docker Hub that is a part of an organization
-
-#### Namespace
-
-Organization or User name. Every image needs a namespace to live under.
-
-#### Node
-
-A node is a physical or virtual machine running an instance of the Docker Engine in swarm mode.
-Manager nodes perform swarm management and orchestration duties. By default manager nodes are also worker nodes.
-Worker nodes invoke tasks.
-
-#### Registry
-
-Online storage for Docker images.
-
-#### Repository
-
-Lets users share container images with their team, customers, or Docker community.
diff --git a/content/contribute/style/voice-tone.md b/content/contribute/style/voice-tone.md
deleted file mode 100644
index 850e60d9a08a..000000000000
--- a/content/contribute/style/voice-tone.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-title: Voice and tone
-description: Docker's voice and tone
-keywords: style guide, voice, tone, content standards
----
-
-## Voice
-
-At Docker, we've been the customer. We're developers developing for developers. We speak with experience and knowledge and without arrogance or ego. We want to inform and empower people without being confusing or pushy. 
-
-We're not afraid to use a bit of cheeky humor to lighten the conversation (and because we don't take ourselves too seriously) but we're always respectful. We communicate with clarity, empathy, and wit; everything we say should inform and encourage.
-
-We align our tone of voice and content with our virtues. The most important principles we follow when we write are the 4Cs:
-
-1. **Correct**
-2. **Concise**
-3. **Complete**
-4. **Clear**
-
-We ensure the information is accurate, succinct, thorough, and easy to understand. We keep sentences as simple as possible, but include enough detail for the user to complete the intended task.
-
-All of this means that when we write documentation and UI copy:
-
-1. **We are honest.** We give you all the facts and we don't use misdirection or make ambiguous statements. We don't always have all the answers, but we're doing our best to make life better for developers and we'll tell you how it's going. 
-2. **We are concise.** We understand the industry of complex and detailed messaging our users live in because we come from the same world. Docker doesn't bulk up our communication with fluffy words or complex metaphors. We're clear and to the point. 
-3. **We are relaxed.** Our demeanor is casual but not lazy, smart but not arrogant, and focused but not cold. Our voice should be welcoming and warm. 
-4. **We are inclusive.** Developers are developers no matter how much code they've written. Every person is as much a part of our community as the next. We are accepting of all developers from all industries and experience levels. 
-
-## Tone
-
-Docker's tone is usually informal, but we believe it's always more important to be clear over comical. We're relaxed, but we're not inappropriate or unprofessional. 
-
-### Friendly tone
-
-Use a tone that's natural, friendly, and respectful without being overly colloquial or full of jargon. Write to inform and empower developers without being confusing or pushy. It’s OK to use contractions as long as the sentence doesn’t become too slangy or informal.
-
-**Avoid overdoing politeness.** It is good to be friendly and polite, but using ‘please’ in technical documentation or UI copy might be overdoing the politeness.
-
-### Positive language
-
-Use positive language. Instead of highlighting the limitations and what the users cannot do, emphasize the positive outcomes.
-
-For example, **instead of**:
-
-“*Features such as Single Sign-on (SSO), Image Access Management, Registry Access Management are not available in Docker Team subscription.”*
-
-**Use**:
-
-“*Features such as Single Sign-on (SSO), Image Access Management, Registry Access Management are  available in Docker Business subscription*.”
diff --git a/content/contribute/ui.md b/content/contribute/ui.md
deleted file mode 100644
index d2b72144ed7e..000000000000
--- a/content/contribute/ui.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: UI elements in content
-description: How to refer and interact with UI content
-keywords: ui, contribute, style guide
-weight: 40
----
-
-This page contains information on how to write technical content that involves a user interface (UI).
-
-## Format names of UI elements
-
-Always bold UI elements when referring to them by name.
-
-This includes names for buttons, menus, dialogs, windows, list items, or any other feature on the page that has a visible name.
-
-Don't make an official feature name or product name bold, except when it directly refers to an element on the page that uses the name, such as a window title or button name.
-
-In most cases, follow the capitalization as it appears on the page. However, if labels are inconsistent or they're all uppercase, use sentence case.
-
-## Focus on the task
-
-When practical, state instructions in terms of what the user should accomplish, rather than focusing on the widgets and gestures. By avoiding reference to UI elements, you help the user understand the purpose of an instruction, and it can help future-proof procedures.
-
-|Correct     |Incorrect    |
-|:-----------|:------------|
-|Expand the **Advanced options** section | Select the zippy to expand the **Advanced options** section|
-
-
-## Refer to UI elements
-
-Don't use UI elements as if they were English verbs or nouns.
-
-|Correct     |Incorrect    |
-|:-----------|:------------|
-|In the **Name** field, enter an account name. | **Name** the account.|
-|To save the settings, select **Save**.| **Save** the settings.|
-
-## Prepositions
-
-When documenting the UI, use the following prepositions. 
-
-|Preposition   |UI element   |  Example |
-|:-----------|:------------|:-----------|
-|in          | dialogs <br>fields <br>lists <br>menus <br>panes <br>windows <br>| In the **Alert** dialog, select **OK**. <br> In the **Name** field, enter `wsfc-1`. <br> In the **Item** list, select **Desktop**. <br>In the **File** menu, click **Tools**.<br> In the **Metrics** pane, select **New**. <br>In the **Task** window, select **Start**. |
-| on         |pages <br>tabs <br>toolbars | On the **Create an instance** page, select **Add**. <br> On the **Edit** tab, select **Save**.<br> On the **Dashboard toolbar**, select **Edit**.<br>|
diff --git a/content/get-started/_index.md b/content/get-started/_index.md
index c4ffafafcd1d..0937e55b7576 100644
--- a/content/get-started/_index.md
+++ b/content/get-started/_index.md
@@ -4,32 +4,30 @@ keywords: Docker, get started
 description: Get started with Docker
 layout: wide
 params:
-  icon: download
+  icon: arrow-down-tray
   notoc: true
   get-started:
   - title: Get Docker
     description: Choose the best installation path for your setup.
     link: /get-started/get-docker/
-    icon: download
+    icon: arrow-down-tray
   - title: What is Docker?
     description: Learn about the Docker platform.
     link: /get-started/docker-overview/
-    icon: summarize
+    icon: document-text
   get-started2:
   - title: Introduction
     description: Get started with the basics and the benefits of containerizing your applications.
     link: /get-started/introduction/
-    icon: rocket
+    icon: rocket-launch
   - title: Docker concepts
     description: Gain a better understanding of foundational Docker concepts.
     link: /get-started/docker-concepts/the-basics/what-is-a-container/
-    icon: foundation
-  - title: Docker workshop
-    description: Get guided through a 45-minute workshop to learn about Docker.
-    link: /get-started/workshop/
-    icon: desk
+    icon: home
 aliases:
-  - /get-started/what-is-a-container
+  - /engine/get-started/
+  - /engine/tutorials/usingdocker/
+  - /guides/getting-started/get-docker-desktop/
 ---
 
 If you're new to Docker, this section guides you through the essential resources to get started.
diff --git a/content/get-started/docker-concepts/building-images/_index.md b/content/get-started/docker-concepts/building-images/_index.md
index a999122c4dcc..05d8c60789b9 100644
--- a/content/get-started/docker-concepts/building-images/_index.md
+++ b/content/get-started/docker-concepts/building-images/_index.md
@@ -13,9 +13,9 @@ summary: |
   deep dive into the secrets of images, how they are built and best practices.
 layout: series
 params:
-  skill: Beginner
+  proficiencyLevel: Beginner
   time: 25 minutes
-  prereq: None
+  prerequisites: None
 ---
 
 ## About this series
diff --git a/content/get-started/docker-concepts/building-images/build-tag-and-publish-an-image.md b/content/get-started/docker-concepts/building-images/build-tag-and-publish-an-image.md
index 820ac10f5267..b34d56d5fc8f 100644
--- a/content/get-started/docker-concepts/building-images/build-tag-and-publish-an-image.md
+++ b/content/get-started/docker-concepts/building-images/build-tag-and-publish-an-image.md
@@ -221,9 +221,9 @@ Now that you have an image built, it's time to push the image to a registry.
 To learn more about building, tagging, and publishing images, visit the following resources:
 
 * [What is a build context?](/build/concepts/context/#what-is-a-build-context)
-* [docker build reference](/engine/reference/commandline/image_build/)
-* [docker image tag reference](/engine/reference/commandline/image_tag/)
-* [docker push reference](/engine/reference/commandline/image_push/)
+* [docker build reference](/reference/cli/docker/buildx/build/)
+* [docker image tag reference](/reference/cli/docker/image/tag/)
+* [docker push reference](/reference/cli/docker/image/push/)
 * [What is a registry?](/get-started/docker-concepts/the-basics/what-is-a-registry/)
 
 ## Next steps
diff --git a/content/get-started/docker-concepts/building-images/images/multi-stage-builds-spring-initializer.webp b/content/get-started/docker-concepts/building-images/images/multi-stage-builds-spring-initializer.webp
index 8a741e1b2ec7..6f5f3723f422 100644
Binary files a/content/get-started/docker-concepts/building-images/images/multi-stage-builds-spring-initializer.webp and b/content/get-started/docker-concepts/building-images/images/multi-stage-builds-spring-initializer.webp differ
diff --git a/content/get-started/docker-concepts/building-images/multi-stage-builds.md b/content/get-started/docker-concepts/building-images/multi-stage-builds.md
index c6336879c21d..6bdabe73c55e 100644
--- a/content/get-started/docker-concepts/building-images/multi-stage-builds.md
+++ b/content/get-started/docker-concepts/building-images/multi-stage-builds.md
@@ -58,13 +58,13 @@ In this hands-on guide, you'll unlock the power of multi-stage builds to create
 1. [Download and install](https://www.docker.com/products/docker-desktop/) Docker Desktop.
 
 
-2. Open this [pre-initialized project](https://start.spring.io/#!type=maven-project&language=java&platformVersion=3.4.0-M3&packaging=jar&jvmVersion=21&groupId=com.example&artifactId=spring-boot-docker&name=spring-boot-docker&description=Demo%20project%20for%20Spring%20Boot&packageName=com.example.spring-boot-docker&dependencies=web) to generate a ZIP file. Here’s how that looks:
+2. Open this [pre-initialized project](https://start.spring.io/#!type=maven-project&language=java&platformVersion=4.0.1&packaging=jar&configurationFileFormat=properties&jvmVersion=21&groupId=com.example&artifactId=spring-boot-docker&name=spring-boot-docker&description=Demo%20project%20for%20Spring%20Boot&packageName=com.example.spring-boot-docker&dependencies=web) to generate a ZIP file. Here’s how that looks:
 
 
     ![A screenshot of Spring Initializr tool selected with Java 21, Spring Web and Spring Boot 3.4.0](images/multi-stage-builds-spring-initializer.webp?border=true)
 
 
-    [Spring Initializr](https://start.spring.io/) is a quickstart generator for Spring projects. It provides an extensible API to generate JVM-based projects with implementations for several common concepts — like basic language generation for Java, Kotlin, and Groovy. 
+    [Spring Initializr](https://start.spring.io/) is a quickstart generator for Spring projects. It provides an extensible API to generate JVM-based projects with implementations for several common concepts — like basic language generation for Java, Kotlin, Groovy, and Maven. 
 
     Select **Generate** to create and download the zip file for this project.
 
@@ -152,7 +152,7 @@ Now that you have the project, you’re ready to create the `Dockerfile`.
  2. In the `Dockerfile`, define your base image by adding the following line:
 
      ```dockerfile
-     FROM eclipse-temurin:21.0.2_13-jdk-jammy
+     FROM eclipse-temurin:21.0.8_9-jdk-jammy
      ```
 
  3. Now, define the working directory by using the `WORKDIR` instruction. This will specify where future commands will run and the directory files will be copied inside the container image.
@@ -190,7 +190,7 @@ Now that you have the project, you’re ready to create the `Dockerfile`.
     And with that, you should have the following Dockerfile:
 
     ```dockerfile 
-    FROM eclipse-temurin:21.0.2_13-jdk-jammy
+    FROM eclipse-temurin:21.0.8_9-jdk-jammy
     WORKDIR /app
     COPY .mvn/ .mvn
     COPY mvnw pom.xml ./
@@ -268,7 +268,7 @@ Now that you have the project, you’re ready to create the `Dockerfile`.
 1. Consider the following Dockerfile:
 
     ```dockerfile
-    FROM eclipse-temurin:21.0.2_13-jdk-jammy AS builder
+    FROM eclipse-temurin:21.0.8_9-jdk-jammy AS builder
     WORKDIR /opt/app
     COPY .mvn/ .mvn
     COPY mvnw pom.xml ./
@@ -276,7 +276,7 @@ Now that you have the project, you’re ready to create the `Dockerfile`.
     COPY ./src ./src
     RUN ./mvnw clean install
 
-    FROM eclipse-temurin:21.0.2_13-jre-jammy AS final
+    FROM eclipse-temurin:21.0.8_9-jre-jammy AS final
     WORKDIR /opt/app
     EXPOSE 8080
     COPY --from=builder /opt/app/target/*.jar /opt/app/*.jar
@@ -287,7 +287,7 @@ Now that you have the project, you’re ready to create the `Dockerfile`.
 
     - The first stage remains the same as the previous Dockerfile, providing a Java Development Kit (JDK) environment for building the application. This stage is given the name of builder.
 
-    - The second stage is a new stage named `final`. It uses a slimmer `eclipse-temurin:21.0.2_13-jre-jammy` image, containing just the Java Runtime Environment (JRE) needed to run the application. This image provides a Java Runtime Environment (JRE) which is enough for running the compiled application (JAR file). 
+    - The second stage is a new stage named `final`. It uses a slimmer `eclipse-temurin:21.0.8_9-jre-jammy` image, containing just the Java Runtime Environment (JRE) needed to run the application. This image provides a Java Runtime Environment (JRE) which is enough for running the compiled application (JAR file). 
 
     
    > For production use, it's highly recommended that you produce a custom JRE-like runtime using jlink. JRE images are available for all versions of Eclipse Temurin, but `jlink` allows you to create a minimal runtime containing only the necessary Java modules for your application. This can significantly reduce the size and improve the security of your final image. [Refer to this page](https://hub.docker.com/_/eclipse-temurin) for more information.
@@ -333,4 +333,3 @@ Now that you have the project, you’re ready to create the `Dockerfile`.
 * [Dockerfile best practices](/develop/develop-images/dockerfile_best-practices/)
 * [Base images](/build/building/base-images/)
 * [Spring Boot Docker](https://spring.io/guides/topicals/spring-boot-docker)
-
diff --git a/content/get-started/docker-concepts/building-images/understanding-image-layers.md b/content/get-started/docker-concepts/building-images/understanding-image-layers.md
index 104e43b09844..13fc0b35710f 100644
--- a/content/get-started/docker-concepts/building-images/understanding-image-layers.md
+++ b/content/get-started/docker-concepts/building-images/understanding-image-layers.md
@@ -103,13 +103,13 @@ In this first step, you will create your own base image that you will then use f
 
     ```console
     IMAGE          CREATED          CREATED BY                                      SIZE      COMMENT
-    d5c1fca2cdc4   10 seconds ago   /bin/bash                                       126MB     Add node
-    2b7cc08dcdbb   5 weeks ago      /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B
-    <missing>      5 weeks ago      /bin/sh -c #(nop) ADD file:07cdbabf782942af0…   69.2MB
-    <missing>      5 weeks ago      /bin/sh -c #(nop)  LABEL org.opencontainers.…   0B
-    <missing>      5 weeks ago      /bin/sh -c #(nop)  LABEL org.opencontainers.…   0B
-    <missing>      5 weeks ago      /bin/sh -c #(nop)  ARG LAUNCHPAD_BUILD_ARCH     0B
-    <missing>      5 weeks ago      /bin/sh -c #(nop)  ARG RELEASE                  0B
+    9e274734bb25   10 seconds ago   /bin/bash                                       157MB     Add node
+    cd1dba651b30   7 days ago       /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B
+    <missing>      7 days ago       /bin/sh -c #(nop) ADD file:6089c6bede9eca8ec…   110MB
+    <missing>      7 days ago       /bin/sh -c #(nop)  LABEL org.opencontainers.…   0B
+    <missing>      7 days ago       /bin/sh -c #(nop)  LABEL org.opencontainers.…   0B
+    <missing>      7 days ago       /bin/sh -c #(nop)  ARG LAUNCHPAD_BUILD_ARCH     0B
+    <missing>      7 days ago       /bin/sh -c #(nop)  ARG RELEASE                  0B
     ```
 
     Note the “Add node” comment on the top line. This layer contains the Node.js install you just made.
diff --git a/content/get-started/docker-concepts/building-images/using-the-build-cache.md b/content/get-started/docker-concepts/building-images/using-the-build-cache.md
index bbe9a3282211..2a00042bce7a 100644
--- a/content/get-started/docker-concepts/building-images/using-the-build-cache.md
+++ b/content/get-started/docker-concepts/building-images/using-the-build-cache.md
@@ -22,7 +22,7 @@ Consider the following Dockerfile that you created for the [getting-started](./w
 
 
 ```dockerfile
-FROM node:20-alpine
+FROM node:22-alpine
 WORKDIR /app
 COPY . .
 RUN yarn install --production
@@ -69,7 +69,7 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
 
 
     ```dockerfile
-    FROM node:20-alpine
+    FROM node:22-alpine
     WORKDIR /app
     COPY . .
     RUN yarn install --production
@@ -121,20 +121,23 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
 
 
     <table>
-      <tr>
-       <td>Steps
-       </td>
-       <td>Description
-       </td>
-       <td>Time Taken(1st Run)
-       </td>
-       <td>Time Taken (2nd Run)
-       </td>
-      </tr>
+      <thead>
+        <tr>
+          <th>Steps
+          </th>
+          <th>Description
+          </th>
+          <th>Time Taken (1st Run)
+          </th>
+          <th>Time Taken (2nd Run)
+          </th>
+        </tr>
+      </thead>
+      <tbody>
       <tr>
        <td>1
        </td>
-       <td>Load build definition from Dockerfile
+       <td><code>Load build definition from Dockerfile</code>
        </td>
        <td>0.0 seconds
        </td>
@@ -144,7 +147,7 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
       <tr>
        <td>2
        </td>
-       <td>Load metadata for docker.io/library/node:20-alpine
+       <td><code>Load metadata for docker.io/library/node:22-alpine</code>
        </td>
        <td>2.7 seconds
        </td>
@@ -154,7 +157,7 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
       <tr>
        <td>3
        </td>
-       <td>Load .dockerignore
+       <td><code>Load .dockerignore</code>
        </td>
        <td>0.0 seconds
        </td>
@@ -164,7 +167,7 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
       <tr>
        <td>4
        </td>
-       <td>Load build context
+       <td><code>Load build context</code>
     <p>
     (Context size: 4.60MB)
        </td>
@@ -176,7 +179,7 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
       <tr>
        <td>5
        </td>
-       <td>Set the working directory (WORKDIR)
+       <td><code>Set the working directory (WORKDIR)</code>
        </td>
        <td>0.1 seconds
        </td>
@@ -186,7 +189,7 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
       <tr>
        <td>6
        </td>
-       <td>Copy the local code into the container
+       <td><code>Copy the local code into the container</code>
        </td>
        <td>0.0 seconds
        </td>
@@ -196,7 +199,7 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
       <tr>
        <td>7
        </td>
-       <td>Run yarn install --production
+       <td><code>Run yarn install --production</code>
        </td>
        <td>10.0 seconds
        </td>
@@ -206,7 +209,7 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
       <tr>
        <td>8
        </td>
-       <td>Exporting layers
+       <td><code>Exporting layers</code>
        </td>
        <td>2.2 seconds
        </td>
@@ -216,13 +219,14 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
       <tr>
        <td>9
        </td>
-       <td>Exporting the final image
+       <td><code>Exporting the final image</code>
        </td>
        <td>3.0 seconds
        </td>
        <td>0.0 seconds
        </td>
      </tr>
+     </tbody>
     </table>
 
 
@@ -233,7 +237,7 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
 6. Update the Dockerfile to copy in the `package.json` file first, install dependencies, and then copy everything else in.
 
      ```dockerfile
-     FROM node:20-alpine
+     FROM node:22-alpine
      WORKDIR /app
      COPY package.json yarn.lock ./
      RUN yarn install --production 
@@ -262,10 +266,10 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
     => => transferring dockerfile: 175B                                                               0.0s
     => [internal] load .dockerignore                                                                  0.0s
     => => transferring context: 2B                                                                    0.0s
-    => [internal] load metadata for docker.io/library/node:21-alpine                                  0.0s
+    => [internal] load metadata for docker.io/library/node:22-alpine                                  0.0s
     => [internal] load build context                                                                  0.8s
     => => transferring context: 53.37MB                                                               0.8s
-    => [1/5] FROM docker.io/library/node:21-alpine                                                    0.0s
+    => [1/5] FROM docker.io/library/node:22-alpine                                                    0.0s
     => CACHED [2/5] WORKDIR /app                                                                      0.0s
     => [3/5] COPY package.json yarn.lock ./                                                           0.2s
     => [4/5] RUN yarn install --production                                                           14.0s
@@ -295,10 +299,10 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti
     => => transferring dockerfile: 37B                                                                0.0s
     => [internal] load .dockerignore                                                                  0.0s
     => => transferring context: 2B                                                                    0.0s
-    => [internal] load metadata for docker.io/library/node:21-alpine                                  0.0s 
+    => [internal] load metadata for docker.io/library/node:22-alpine                                  0.0s 
     => [internal] load build context                                                                  0.2s
     => => transferring context: 450.43kB                                                              0.2s
-    => [1/5] FROM docker.io/library/node:21-alpine                                                    0.0s
+    => [1/5] FROM docker.io/library/node:22-alpine                                                    0.0s
     => CACHED [2/5] WORKDIR /app                                                                      0.0s
     => CACHED [3/5] COPY package.json yarn.lock ./                                                    0.0s
     => CACHED [4/5] RUN yarn install --production                                                     0.0s
diff --git a/content/get-started/docker-concepts/building-images/writing-a-dockerfile.md b/content/get-started/docker-concepts/building-images/writing-a-dockerfile.md
index 38920c467493..0135769e7749 100644
--- a/content/get-started/docker-concepts/building-images/writing-a-dockerfile.md
+++ b/content/get-started/docker-concepts/building-images/writing-a-dockerfile.md
@@ -22,7 +22,7 @@ A Dockerfile is a text-based document that's used to create a container image. I
 As an example, the following Dockerfile would produce a ready-to-run Python application:
 
 ```dockerfile
-FROM python:3.12
+FROM python:3.13
 WORKDIR /usr/local/app
 
 # Install the application dependencies
@@ -31,7 +31,7 @@ RUN pip install --no-cache-dir -r requirements.txt
 
 # Copy in the source code
 COPY src ./src
-EXPOSE 5000
+EXPOSE 8080
 
 # Setup an app user so the container doesn't run as the root user
 RUN useradd app
@@ -69,7 +69,9 @@ In this quick hands-on guide, you'll write a Dockerfile that builds a simple Nod
 
 ### Set up
 
-[Download this ZIP file](https://github.com/docker/getting-started-todo-app/raw/build-image-from-scratch/app.zip) and extract the contents into a directory on your machine.
+[Download this ZIP file](https://github.com/docker/getting-started-todo-app/archive/refs/heads/build-image-from-scratch.zip) and extract the contents into a directory on your machine.
+
+If you'd rather not download a ZIP file, clone the https://github.com/docker/getting-started-todo-app project and checkout the `build-image-from-scratch` branch.
 
 ### Creating the Dockerfile
 
@@ -77,38 +79,49 @@ Now that you have the project, you’re ready to create the `Dockerfile`.
 
 1. [Download and install](https://www.docker.com/products/docker-desktop/) Docker Desktop.
 
-2. Create a file named `Dockerfile` in the same folder as the file `package.json`.
+2. Examine the project.
+
+   Explore the contents of `getting-started-todo-app/app/`. You'll notice that a
+   `Dockerfile` already exists. It is a simple text file that you can open in
+   any text or code editor.
+
+3. Delete the existing `Dockerfile`.
+
+   For this exercise, you'll pretend you're starting from scratch and will
+   create a new `Dockerfile`.
+
+4. Create a file named `Dockerfile` in the `getting-started-todo-app/app/` folder.
 
     > **Dockerfile file extensions**
     >
     > It's important to note that the `Dockerfile` has _no_ file extension. Some editors
     > will automatically add an extension to the file (or complain it doesn't have one).
 
-3. In the `Dockerfile`, define your base image by adding the following line:
+5. In the `Dockerfile`, define your base image by adding the following line:
 
     ```dockerfile
-    FROM node:20-alpine
+    FROM node:22-alpine
     ```
 
-4. Now, define the working directory by using the `WORKDIR` instruction. This will specify where future commands will run and the directory files will be copied inside the container image.
+6. Now, define the working directory by using the `WORKDIR` instruction. This will specify where future commands will run and the directory files will be copied inside the container image.
 
     ```dockerfile
     WORKDIR /app
     ```
 
-5. Copy all of the files from your project on your machine into the container image by using the `COPY` instruction:
+7. Copy all of the files from your project on your machine into the container image by using the `COPY` instruction:
 
     ```dockerfile
     COPY . .
     ```
 
-6. Install the app's dependencies by using the `yarn` CLI and package manager. To do so, run a command using the `RUN` instruction:
+8. Install the app's dependencies by using the `yarn` CLI and package manager. To do so, run a command using the `RUN` instruction:
 
     ```dockerfile
     RUN yarn install --production
     ```
 
-7. Finally, specify the default command to run by using the `CMD` instruction:
+9. Finally, specify the default command to run by using the `CMD` instruction:
 
     ```dockerfile
     CMD ["node", "./src/index.js"]
@@ -117,7 +130,7 @@ Now that you have the project, you’re ready to create the `Dockerfile`.
 
 
     ```dockerfile
-    FROM node:20-alpine
+    FROM node:22-alpine
     WORKDIR /app
     COPY . .
     RUN yarn install --production
@@ -134,13 +147,6 @@ Now that you have the project, you’re ready to create the `Dockerfile`.
 > build cache, run as a non-root user, and multi-stage builds.
 
 
-> **Containerize new projects quickly with `docker init`**
->
-> The `docker init` command will analyze your project and quickly create 
-> a Dockerfile, a `compose.yaml`, and a `.dockerignore`, helping you get
-> up and going. Since you're learning about Dockerfiles specifically here, 
-> you won't use it now. But, [learn more about it here](/engine/reference/commandline/init/).
-
 ## Additional resources
 
 To learn more about writing a Dockerfile, visit the following resources:
@@ -148,7 +154,7 @@ To learn more about writing a Dockerfile, visit the following resources:
 * [Dockerfile reference](/reference/dockerfile/)
 * [Dockerfile best practices](/develop/develop-images/dockerfile_best-practices/)
 * [Base images](/build/building/base-images/)
-* [Getting started with Docker Init](/reference/cli/docker/init/)
+* [Gordon](/ai/gordon/) — Docker's AI assistant can generate a Dockerfile for your project. Ask Gordon to analyze your code and suggest a Dockerfile optimized for your language and framework.
 
 ## Next steps
 
diff --git a/content/get-started/docker-concepts/running-containers/images/delete-containers.webp b/content/get-started/docker-concepts/running-containers/images/delete-containers.webp
index 39d948250ffd..50ab05f7f6ba 100644
Binary files a/content/get-started/docker-concepts/running-containers/images/delete-containers.webp and b/content/get-started/docker-concepts/running-containers/images/delete-containers.webp differ
diff --git a/content/get-started/docker-concepts/running-containers/images/delete-the-container.webp b/content/get-started/docker-concepts/running-containers/images/delete-the-container.webp
deleted file mode 100644
index 475d82a5764a..000000000000
Binary files a/content/get-started/docker-concepts/running-containers/images/delete-the-container.webp and /dev/null differ
diff --git a/content/get-started/docker-concepts/running-containers/images/exec-into-postgres-container.webp b/content/get-started/docker-concepts/running-containers/images/exec-into-postgres-container.webp
index e077732e9666..27a99a161b5d 100644
Binary files a/content/get-started/docker-concepts/running-containers/images/exec-into-postgres-container.webp and b/content/get-started/docker-concepts/running-containers/images/exec-into-postgres-container.webp differ
diff --git a/content/get-started/docker-concepts/running-containers/images/list-containers.webp b/content/get-started/docker-concepts/running-containers/images/list-containers.webp
index 6b8d745bf7ad..326ec76e1a26 100644
Binary files a/content/get-started/docker-concepts/running-containers/images/list-containers.webp and b/content/get-started/docker-concepts/running-containers/images/list-containers.webp differ
diff --git a/content/get-started/docker-concepts/running-containers/images/published-ports.webp b/content/get-started/docker-concepts/running-containers/images/published-ports.webp
index 44d902443830..26482c9f259b 100644
Binary files a/content/get-started/docker-concepts/running-containers/images/published-ports.webp and b/content/get-started/docker-concepts/running-containers/images/published-ports.webp differ
diff --git a/content/get-started/docker-concepts/running-containers/images/running-postgres-containers.webp b/content/get-started/docker-concepts/running-containers/images/running-postgres-containers.webp
index 4103e6c7ad0c..90d859dc093a 100644
Binary files a/content/get-started/docker-concepts/running-containers/images/running-postgres-containers.webp and b/content/get-started/docker-concepts/running-containers/images/running-postgres-containers.webp differ
diff --git a/content/get-started/docker-concepts/running-containers/multi-container-applications.md b/content/get-started/docker-concepts/running-containers/multi-container-applications.md
index 061a7333ed1f..6acf2b266393 100644
--- a/content/get-started/docker-concepts/running-containers/multi-container-applications.md
+++ b/content/get-started/docker-concepts/running-containers/multi-container-applications.md
@@ -196,12 +196,12 @@ Navigate to the root of the project directory. Inside this directory, you'll fin
 
 
     ```console
-    Running 5/5
-    ✔ Network nginx-nodejs-redis_default    Created                                                0.0s
-    ✔ Container nginx-nodejs-redis-web1-1   Started                                                0.1s
-    ✔ Container nginx-nodejs-redis-redis-1  Started                                                0.1s
-    ✔ Container nginx-nodejs-redis-web2-1   Started                                                0.1s
-    ✔ Container nginx-nodejs-redis-nginx-1  Started
+     ✔ Network nginx-node-redis_default   Created                                                                                                   0.0s
+     ✔ Container nginx-node-redis-web2-1  Created                                                                                                   0.1s
+     ✔ Container nginx-node-redis-web1-1  Created                                                                                                   0.1s
+     ✔ Container nginx-node-redis-redis-1 Created                                                                                                   0.1s
+     ✔ Container nginx-node-redis-nginx-1 Created   
+ 
     ```
 
 2. If you look at the Docker Desktop Dashboard, you can see the containers and dive deeper into their configuration.
diff --git a/content/get-started/docker-concepts/running-containers/overriding-container-defaults.md b/content/get-started/docker-concepts/running-containers/overriding-container-defaults.md
index cd441ca3d2a8..7e28e811473f 100644
--- a/content/get-started/docker-concepts/running-containers/overriding-container-defaults.md
+++ b/content/get-started/docker-concepts/running-containers/overriding-container-defaults.md
@@ -152,7 +152,7 @@ Sometimes, you might need to override the default commands (`CMD`) or entry poin
     ```yaml
     services:
       postgres:
-        image: postgres
+        image: postgres:18
         entrypoint: ["docker-entrypoint.sh", "postgres"]
         command: ["-h", "localhost", "-p", "5432"]
         environment:
diff --git a/content/get-started/docker-concepts/running-containers/persisting-container-data.md b/content/get-started/docker-concepts/running-containers/persisting-container-data.md
index bf75cb33e2cf..ba9e6f011910 100644
--- a/content/get-started/docker-concepts/running-containers/persisting-container-data.md
+++ b/content/get-started/docker-concepts/running-containers/persisting-container-data.md
@@ -53,7 +53,7 @@ Volumes have their own lifecycle beyond that of containers and can grow quite la
 
 ## Try it out
 
-In this guide, you’ll practice creating and using volumes to persist data created by a Postgres container. When the database runs, it stores files into the `/var/lib/postgresql/data` directory. By attaching the volume here, you will be able to restart the container multiple times while keeping the data.
+In this guide, you'll practice creating and using volumes to persist data created by a Postgres container. When the database runs, it stores files into the `/var/lib/postgresql` directory. By attaching the volume here, you will be able to restart the container multiple times while keeping the data.
 
 ### Use volumes
 
@@ -62,7 +62,7 @@ In this guide, you’ll practice creating and using volumes to persist data crea
 2. Start a container using the [Postgres image](https://hub.docker.com/_/postgres) with the following command:
 
     ```console
-    $ docker run --name=db -e POSTGRES_PASSWORD=secret -d -v postgres_data:/var/lib/postgresql/data postgres
+    $ docker run --name=db -e POSTGRES_PASSWORD=secret -d -v postgres_data:/var/lib/postgresql postgres:18
     ```
 
     This will start the database in the background, configure it with a password, and attach a volume to the directory PostgreSQL will persist the database files.
@@ -115,7 +115,7 @@ In this guide, you’ll practice creating and using volumes to persist data crea
 8. Start a new container by running the following command, attaching the same volume with the persisted data:
 
     ```console
-    $ docker run --name=new-db -d -v postgres_data:/var/lib/postgresql/data postgres 
+    $ docker run --name=new-db -d -v postgres_data:/var/lib/postgresql postgres:18
     ```
 
     You might have noticed that the `POSTGRES_PASSWORD` environment variable has been omitted. That’s because that variable is only used when bootstrapping a new database.
@@ -128,13 +128,13 @@ In this guide, you’ll practice creating and using volumes to persist data crea
 
 ### View volume contents
 
-The Docker Desktop Dashboard provides the ability to view the contents of any volume, as well as the ability to export, import, and clone volumes.
+The Docker Desktop Dashboard provides the ability to view the contents of any volume, as well as the ability to export, import, empty, delete and clone volumes.
 
 1. Open the Docker Desktop Dashboard and navigate to the **Volumes** view. In this view, you should see the **postgres_data** volume.
 
 2. Select the **postgres_data** volume’s name.
 
-3. The **Data** tab shows the contents of the volume and provides the ability to navigate the files. Double-clicking on a file will let you see the contents and make changes.
+3. The **Stored Data** tab shows the contents of the volume and provides the ability to navigate the files. The **Container in-use** tab displays the name of the container using the volume, the image name, the port number used by the container, and the target. A target is a path inside a container that gives access to the files in the volume. The **Exports** tab lets you export the volume. Double-clicking on a file will let you see the contents and make changes.
 
 4. Right-click on any file to save it or delete it.
 
diff --git a/content/get-started/docker-concepts/running-containers/publishing-ports.md b/content/get-started/docker-concepts/running-containers/publishing-ports.md
index d2766459fbf3..9f611e412754 100644
--- a/content/get-started/docker-concepts/running-containers/publishing-ports.md
+++ b/content/get-started/docker-concepts/running-containers/publishing-ports.md
@@ -38,6 +38,32 @@ Now, any traffic sent to port `8080` on your host machine will be forwarded to p
 >
 > When a port is published, it's published to all network interfaces by default. This means any traffic that reaches your machine can access the published application. Be mindful of publishing databases or any sensitive information. [Learn more about published ports here](/engine/network/#published-ports).
 
+
+### Publishing on a specific host IP
+
+By default, published ports listen on all host interfaces (`0.0.0.0` / `::`). You can
+bind to a single address by putting the IP first in the publish string:
+
+```console
+$ docker run -d -p 127.0.0.1:8080:80 nginx
+```
+
+The full form is `HOST_IP:HOST_PORT:CONTAINER_PORT`.
+
+- `HOST_IP`: Optional. The host address to bind. Use `127.0.0.1` to keep the port
+  local to the machine, or a specific interface IP so only that NIC accepts traffic.
+- `HOST_PORT` / `CONTAINER_PORT`: Same meaning as in `HOST_PORT:CONTAINER_PORT`.
+
+In Compose, the same extended form works under `ports`:
+
+```yaml
+services:
+  app:
+    image: docker/welcome-to-docker
+    ports:
+      - "127.0.0.1:8080:80"
+```
+
 ### Publishing to ephemeral ports
 
 At times, you may want to simply publish the port but don’t care which host port is used. In these cases, you can let Docker pick the port for you. To do so, simply omit the `HOST_PORT` configuration. 
diff --git a/content/get-started/docker-concepts/running-containers/sharing-local-files.md b/content/get-started/docker-concepts/running-containers/sharing-local-files.md
index 9600eba47231..043be8b8c9a8 100644
--- a/content/get-started/docker-concepts/running-containers/sharing-local-files.md
+++ b/content/get-started/docker-concepts/running-containers/sharing-local-files.md
@@ -38,7 +38,7 @@ Here's a way to use `docker run` to start a container using a bind mount and map
 $ docker run -v /HOST/PATH:/CONTAINER/PATH -it nginx
 ```
 
-The `--mount` flag offers more advanced features and granular control, making it suitable for complex mount scenarios or production deployments. If you use `--mount` to bind-mount a file or directory that doesn't yet exist on the Docker host, the `docker run` command doesn't automatically create it for you but generates an error.
+The `--mount` flag offers more advanced features and granular control, making it suitable for complex mount scenarios or production deployments. By default, if you use `--mount` to bind-mount a file or directory that doesn't yet exist on the Docker host, the `docker run` command doesn't automatically create it for you but generates an error.
 
 ```console
 $ docker run --mount type=bind,source=/HOST/PATH,target=/CONTAINER/PATH,readonly nginx
@@ -162,12 +162,12 @@ Using a bind mount, you can map the configuration file on your host computer to
 1. You can view the mounted files inside a container by selecting the container's **Files** tab and then selecting a file inside the `/usr/local/apache2/htdocs/` directory. Then, select **Open file editor**.
 
 
-   ![A screenshot of Docker Desktop Dashboard showing the mounted files inside the a container](images/mounted-files.webp?border=true)
+   ![A screenshot of Docker Desktop Dashboard showing the mounted files inside the container](images/mounted-files.webp?border=true)
 
 2. Delete the file on the host and verify the file is also deleted in the container. You will find that the files no longer exist under **Files** in the Docker Desktop Dashboard.
 
 
-   ![A screenshot of Docker Desktop Dashboard showing the deleted files inside the a container](images/deleted-files.webp?border=true)
+   ![A screenshot of Docker Desktop Dashboard showing the deleted files inside the container](images/deleted-files.webp?border=true)
 
 
 3. Recreate the HTML file on the host system and see that file re-appears under the **Files** tab under **Containers** on the Docker Desktop Dashboard. By now, you will be able to access the site too.
@@ -182,10 +182,7 @@ The container continues to run until you stop it.
 
 2. Locate the container you'd like to stop.
 
-3. Select the **Delete** action in the Actions column.
-
-![A screenshot of Docker Desktop Dashboard showing how to delete the container](images/delete-the-container.webp?border=true)
-
+3. Select the **Stop** action in the Actions column.
 
 ## Additional resources
 
diff --git a/content/get-started/docker-concepts/the-basics/images/click-image.webp b/content/get-started/docker-concepts/the-basics/images/click-image.webp
index 96fe90c26ba5..9627015d62f6 100644
Binary files a/content/get-started/docker-concepts/the-basics/images/click-image.webp and b/content/get-started/docker-concepts/the-basics/images/click-image.webp differ
diff --git a/content/get-started/docker-concepts/the-basics/images/image-layers.webp b/content/get-started/docker-concepts/the-basics/images/image-layers.webp
index 58595377ad5c..bfd99e17d166 100644
Binary files a/content/get-started/docker-concepts/the-basics/images/image-layers.webp and b/content/get-started/docker-concepts/the-basics/images/image-layers.webp differ
diff --git a/content/get-started/docker-concepts/the-basics/images/pulled-image.webp b/content/get-started/docker-concepts/the-basics/images/pulled-image.webp
index 1f98341e69ca..cd7bb5d58dcb 100644
Binary files a/content/get-started/docker-concepts/the-basics/images/pulled-image.webp and b/content/get-started/docker-concepts/the-basics/images/pulled-image.webp differ
diff --git a/content/get-started/docker-concepts/the-basics/images/search-image.webp b/content/get-started/docker-concepts/the-basics/images/search-image.webp
index e78b54b28760..afac5d787264 100644
Binary files a/content/get-started/docker-concepts/the-basics/images/search-image.webp and b/content/get-started/docker-concepts/the-basics/images/search-image.webp differ
diff --git a/content/get-started/docker-concepts/the-basics/images/select-image.webp b/content/get-started/docker-concepts/the-basics/images/select-image.webp
index 3576d1241988..15a20a2261e6 100644
Binary files a/content/get-started/docker-concepts/the-basics/images/select-image.webp and b/content/get-started/docker-concepts/the-basics/images/select-image.webp differ
diff --git a/content/get-started/docker-concepts/the-basics/images/todo-list-containers.webp b/content/get-started/docker-concepts/the-basics/images/todo-list-containers.webp
index 608189d94613..28a45a990632 100644
Binary files a/content/get-started/docker-concepts/the-basics/images/todo-list-containers.webp and b/content/get-started/docker-concepts/the-basics/images/todo-list-containers.webp differ
diff --git a/content/get-started/docker-concepts/the-basics/images/todo-list-delete.webp b/content/get-started/docker-concepts/the-basics/images/todo-list-delete.webp
index 78852fb74663..872e45ca7c7e 100644
Binary files a/content/get-started/docker-concepts/the-basics/images/todo-list-delete.webp and b/content/get-started/docker-concepts/the-basics/images/todo-list-delete.webp differ
diff --git a/content/get-started/docker-concepts/the-basics/what-is-a-container.md b/content/get-started/docker-concepts/the-basics/what-is-a-container.md
index 89af955717ed..8279e3387e65 100644
--- a/content/get-started/docker-concepts/the-basics/what-is-a-container.md
+++ b/content/get-started/docker-concepts/the-basics/what-is-a-container.md
@@ -8,6 +8,7 @@ aliases:
 - /guides/walkthroughs/run-a-container/
 - /guides/walkthroughs/
 - /get-started/run-your-own-container/
+- /get-started/what-is-a-container/
 - /guides/docker-concepts/the-basics/what-is-a-container/
 ---
 
@@ -28,7 +29,7 @@ What is a container? Simply put, containers are isolated processes for each of y
 Here's what makes them awesome. Containers are:
 
 - Self-contained. Each container has everything it needs to function with no reliance on any pre-installed dependencies on the host machine.
-- Isolated. Since containers are run in isolation, they have minimal influence on the host and other containers, increasing the security of your applications.
+- Isolated. Since containers run in isolation, they have minimal influence on the host and other containers, increasing the security of your applications.
 - Independent. Each container is independently managed. Deleting one container won't affect any others.
 - Portable. Containers can run anywhere! The container that runs on your development machine will work the same way in a data center or anywhere in the cloud!
 
@@ -56,7 +57,7 @@ Use the following instructions to run a container.
 
 2. Specify `welcome-to-docker` in the search input and then select the **Pull** button.
 
-    ![A screenshot of the Docker Desktop Dashboard showing the search result for welcome-to-docker Docker image ](images/search-the-docker-image.webp?border=true&w=1000&h=700)
+    ![A screenshot of the Docker Desktop Dashboard showing the search result for welcome-to-docker Docker image](images/search-the-docker-image.webp?border=true&w=1000&h=700)
 
 3. Once the image is successfully pulled, select the **Run** button.
 
@@ -82,9 +83,9 @@ This container runs a web server that displays a simple website. When working wi
 
 ### Access the frontend
 
-When you launched the container, you exposed one of the container's ports onto your machine. Think of this as creating configuration to let you to connect through the isolated environment of the container. 
+When you launched the container, you exposed one of the container's ports onto your machine. Think of this as creating configuration to let you connect through the isolated environment of the container. 
 
-For this container, the frontend is accessible on port `8080`. To open the website, select the link in the **Port(s)** column of your container or visit [http://localhost:8080](https://localhost:8080) in your browser.
+For this container, the frontend is accessible on port `8080`. To open the website, select the link in the **Port(s)** column of your container or visit [http://localhost:8080](http://localhost:8080) in your browser.
 
 ![Screenshot of the landing page coming from the running container](images/access-the-frontend.webp?border)
 
diff --git a/content/get-started/docker-concepts/the-basics/what-is-a-registry.md b/content/get-started/docker-concepts/the-basics/what-is-a-registry.md
index f8731fdb5633..118d987778d0 100644
--- a/content/get-started/docker-concepts/the-basics/what-is-a-registry.md
+++ b/content/get-started/docker-concepts/the-basics/what-is-a-registry.md
@@ -4,22 +4,22 @@ weight: 30
 keywords: concepts, build, images, container, docker desktop
 description: What is a registry? This Docker Concept will explain what a registry is, explore their interoperability, and have you interact with registries.
 aliases:
-- /guides/walkthroughs/run-hub-images/
-- /guides/walkthroughs/publish-your-image/
-- /guides/docker-concepts/the-basics/what-is-a-registry/
+  - /guides/walkthroughs/run-hub-images/
+  - /guides/walkthroughs/publish-your-image/
+  - /guides/docker-concepts/the-basics/what-is-a-registry/
 ---
 
 {{< youtube-embed 2WDl10Wv5rs >}}
 
 ## Explanation
 
-Now that you know what a container image is and how it works, you might wonder - where do you store these images? 
+Now that you know what a container image is and how it works, you might wonder - where do you store these images?
 
 Well, you can store your container images on your computer system, but what if you want to share them with your friends or use them on another machine? That's where the image registry comes in.
 
-An image registry is a centralized location for storing and sharing your container images. It can be either public or private. [Docker Hub](https://hub.docker.com) is a public registry that anyone can use and is the default registry. 
+An image registry is a centralized location for storing and sharing your container images. It can be either public or private. [Docker Hub](https://hub.docker.com) is a public registry that anyone can use and is the default registry.
 
-While Docker Hub is a popular option, there are many other available container registries available today, including [Amazon Elastic Container Registry(ECR)](https://aws.amazon.com/ecr/), [Azure Container Registry (ACR)](https://azure.microsoft.com/en-in/products/container-registry), and [Google Container Registry (GCR)](https://cloud.google.com/artifact-registry). You can even run your private registry on your local system or inside your organization. For example, Harbor, JFrog Artifactory, GitLab Container registry etc.
+While Docker Hub is a popular option, there are many other available container registries available today, including [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/), [Azure Container Registry (ACR)](https://azure.microsoft.com/en-in/products/container-registry), and [Google Container Registry (GCR)](https://cloud.google.com/artifact-registry). You can even run your private registry on your local system or inside your organization. For example, Harbor, JFrog Artifactory, GitLab Container registry etc.
 
 ### Registry vs. repository
 
@@ -29,32 +29,24 @@ A _registry_ is a centralized location that stores and manages container images,
 
 The following diagram shows the relationship between a registry, repositories, and images.
 
-```goat {class="text-sm"}
-+---------------------------------------+
-|               Registry                |
-|---------------------------------------|
-|                                       |
-|    +-----------------------------+    |
-|    |        Repository A         |    |
-|    |-----------------------------|    |
-|    |   Image: project-a:v1.0     |    |
-|    |   Image: project-a:v2.0     |    |
-|    +-----------------------------+    |
-|                                       |
-|    +-----------------------------+    |
-|    |        Repository B         |    |
-|    |-----------------------------|    |
-|    |   Image: project-b:v1.0     |    |
-|    |   Image: project-b:v1.1     |    |
-|    |   Image: project-b:v2.0     |    |
-|    +-----------------------------+    |
-|                                       |
-+---------------------------------------+
+```mermaid
+flowchart TB
+  subgraph Registry
+    subgraph A["Repository A"]
+      A1["project-a:v1.0"]
+      A2["project-a:v2.0"]
+    end
+    subgraph B["Repository B"]
+      B1["project-b:v1.0"]
+      B2["project-b:v1.1"]
+      B3["project-b:v2.0"]
+    end
+  end
 ```
 
-> [!NOTE]
+> [!TIP]
 >
-> You can create one private repository and unlimited public repositories using the free version of Docker Hub. For more information, visit the [Docker Hub subscription page](https://www.docker.com/pricing/).
+> A Docker Personal plan gives you one private repository and unlimited public repositories. To get unlimited private repositories, upgrade to the [Docker Team plan](https://www.docker.com/pricing?ref=Docs&refAction=DocsConceptsRegistry).
 
 ## Try it out
 
@@ -62,11 +54,11 @@ In this hands-on, you will learn how to build and push a Docker image to the Doc
 
 ### Sign up for a free Docker account
 
-1. If you haven't created one yet, head over to the [Docker Hub](https://hub.docker.com) page to sign up for a new Docker account.
+1. If you haven't created one yet, head over to the [Docker Hub](https://hub.docker.com) page to sign up for a new Docker account. Be sure to finish the verification steps sent to your email.
 
-    ![Screenshot of the official Docker Hub page showing the Sign up page](images/dockerhub-signup.webp?border)
+   ![Screenshot of the official Docker Hub page showing the Sign up page](images/dockerhub-signup.webp?border)
 
-    You can use your Google or GitHub account to authenticate.
+   You can use your Google or GitHub account to authenticate.
 
 ### Create your first repository
 
@@ -74,9 +66,9 @@ In this hands-on, you will learn how to build and push a Docker image to the Doc
 2. Select the **Create repository** button in the top-right corner.
 3. Select your namespace (most likely your username) and enter `docker-quickstart` as the repository name.
 
-    ![Screenshot of the Docker Hub page that shows how to create a public repository](images/create-hub-repository.webp?border)
+   ![Screenshot of the Docker Hub page that shows how to create a public repository](images/create-hub-repository.webp?border)
 
-4. Set the visibility to **Public**. 
+4. Set the visibility to **Public**.
 5. Select the **Create** button to create the repository.
 
 That's it. You've successfully created your first repository. 🎉
@@ -96,62 +88,62 @@ Don't worry about the specifics of the Dockerfile, as you'll learn about that in
 
 1. Clone the GitHub repository using the following command:
 
-    ```console
-    git clone https://github.com/dockersamples/helloworld-demo-node
-    ```
+   ```console
+   git clone https://github.com/dockersamples/helloworld-demo-node
+   ```
 
 2. Navigate into the newly created directory.
 
-    ```console
-    cd helloworld-demo-node
-    ```
+   ```console
+   cd helloworld-demo-node
+   ```
 
 3. Run the following command to build a Docker image, swapping out `YOUR_DOCKER_USERNAME` with your username.
 
-    ```console
-    docker build -t <YOUR_DOCKER_USERNAME>/docker-quickstart .
-    ```
+   ```console
+   docker build -t <YOUR_DOCKER_USERNAME>/docker-quickstart .
+   ```
 
-    > [!NOTE]
-    >
-    > Make sure you include the dot (.) at the end of the `docker build` command. This tells Docker where to find the Dockerfile.
+   > [!NOTE]
+   >
+   > Make sure you include the dot (.) at the end of the `docker build` command. This tells Docker where to find the Dockerfile.
 
 4. Run the following command to list the newly created Docker image:
 
-    ```console
-    docker images
-    ```
+   ```console
+   docker images
+   ```
 
-    You will see output like the following:
+   You will see output like the following:
 
-    ```console
-    REPOSITORY                                 TAG       IMAGE ID       CREATED         SIZE
-    <YOUR_DOCKER_USERNAME>/docker-quickstart   latest    476de364f70e   2 minutes ago   170MB
-    ```
+   ```console
+   REPOSITORY                                 TAG       IMAGE ID       CREATED         SIZE
+   <YOUR_DOCKER_USERNAME>/docker-quickstart   latest    476de364f70e   2 minutes ago   170MB
+   ```
 
 5. Start a container to test the image by running the following command (swap out the username with your own username):
 
-    ```console
-    docker run -d -p 8080:8080 <YOUR_DOCKER_USERNAME>/docker-quickstart 
-    ```
+   ```console
+   docker run -d -p 8080:8080 <YOUR_DOCKER_USERNAME>/docker-quickstart
+   ```
 
-    You can verify if the container is working by visiting [http://localhost:8080](http://localhost:8080) with your browser.
+   You can verify if the container is working by visiting [http://localhost:8080](http://localhost:8080) with your browser.
 
-6. Use the [`docker tag`](/reference/cli/docker/image/tag/) command to tag the Docker image. Docker tags allow you to label and version your images. 
+6. Use the [`docker tag`](/reference/cli/docker/image/tag/) command to tag the Docker image. Docker tags allow you to label and version your images.
 
-    ```console 
-    docker tag <YOUR_DOCKER_USERNAME>/docker-quickstart <YOUR_DOCKER_USERNAME>/docker-quickstart:1.0 
-    ```
+   ```console
+   docker tag <YOUR_DOCKER_USERNAME>/docker-quickstart <YOUR_DOCKER_USERNAME>/docker-quickstart:1.0
+   ```
 
 7. Finally, it's time to push the newly built image to your Docker Hub repository by using the [`docker push`](/reference/cli/docker/image/push/) command:
 
-    ```console 
-    docker push <YOUR_DOCKER_USERNAME>/docker-quickstart:1.0
-    ```
+   ```console
+   docker push <YOUR_DOCKER_USERNAME>/docker-quickstart:1.0
+   ```
 
 8. Open [Docker Hub](https://hub.docker.com) and navigate to your repository. Navigate to the **Tags** section and see your newly pushed image.
 
-    ![Screenshot of the Docker Hub page that displays the newly added image tag](images/dockerhub-tags.webp?border=true) 
+   ![Screenshot of the Docker Hub page that displays the newly added image tag](images/dockerhub-tags.webp?border=true)
 
 In this walkthrough, you signed up for a Docker account, created your first Docker Hub repository, and built, tagged, and pushed a container image to your Docker Hub repository.
 
diff --git a/content/get-started/docker-concepts/the-basics/what-is-an-image.md b/content/get-started/docker-concepts/the-basics/what-is-an-image.md
index c3702a4c5fe2..b29870f68fc9 100644
--- a/content/get-started/docker-concepts/the-basics/what-is-an-image.md
+++ b/content/get-started/docker-concepts/the-basics/what-is-an-image.md
@@ -12,7 +12,7 @@ aliases:
 
 ## Explanation
 
-Seeing a [container](./what-is-a-container.md) is an isolated process, where does it get its files and configuration? How do you share those environments?
+Seeing as a [container](./what-is-a-container.md) is an isolated process, where does it get its files and configuration? How do you share those environments?
 
 That's where container images come in. A container image is a standardized package that includes all of the files, binaries, libraries, and configurations to run a container.
 
@@ -32,11 +32,12 @@ These two principles let you to extend or add to existing images. For example, i
 
 Docker Hub provides a variety of Docker-supported and endorsed images known as Docker Trusted Content. These provide fully managed services or great starters for your own images. These include:
 
-- [Docker Official Images](https://hub.docker.com/search?q=&type=image&image_filter=official) - a curated set of Docker repositories, serve as the starting point for the majority of users, and are some of the most secure on Docker Hub
-- [Docker Verified Publishers](https://hub.docker.com/search?q=&image_filter=store) - high-quality images from commercial publishers verified by Docker
-- [Docker-Sponsored Open Source](https://hub.docker.com/search?q=&image_filter=open_source) - images published and maintained by open-source projects sponsored by Docker through Docker's open source program
+- [Docker Official Images](https://hub.docker.com/search?badges=official) - a curated set of Docker repositories, serve as the starting point for the majority of users, and are some of the most secure on Docker Hub
+- [Docker Hardened Images](https://hub.docker.com/hardened-images/catalog) - minimal, secure, production-ready images with near-zero CVEs, designed to reduce attack surface and simplify compliance. Free and open source under Apache 2.0
+- [Docker Verified Publishers](https://hub.docker.com/search?badges=verified_publisher) - high-quality images from commercial publishers verified by Docker
+- [Docker-Sponsored Open Source](https://hub.docker.com/search?badges=open_source) - images published and maintained by open-source projects sponsored by Docker through Docker's open source program
 
-For example, [Redis](https://hub.docker.com/_/redis) and [Memcached](https://hub.docker.com/_/memcached) are a few popular ready-to-go Docker Official Images. You can download these images and have these services up and running in a matter of seconds. There are also base images, like the [Node.js](https://hub.docker.com/_/node) Docker image, that you can use as a starting point and add your own files and configurations.
+For example, [Redis](https://hub.docker.com/_/redis) and [Memcached](https://hub.docker.com/_/memcached) are a few popular ready-to-go Docker Official Images. You can download these images and have these services up and running in a matter of seconds. There are also base images, like the [Node.js](https://hub.docker.com/_/node) Docker image, that you can use as a starting point and add your own files and configurations. For production workloads requiring enhanced security, Docker Hardened Images offer minimal variants of popular images like Node.js, Python, and Go.
 
 ## Try it out
 
@@ -83,7 +84,7 @@ Follow the instructions to search and pull a Docker image using CLI to view its
 
 ### Search for and download an image
 
-1. Open a terminal and search for images using the [`docker search`](/reference/cli/docker/search.md) command:
+1. Open a terminal and search for images using the [`docker search`](/reference/cli/docker/search/) command:
 
    ```console
    docker search docker/welcome-to-docker
@@ -98,7 +99,7 @@ Follow the instructions to search and pull a Docker image using CLI to view its
 
    This output shows you information about relevant images available on Docker Hub.
 
-2. Pull the image using the [`docker pull`](/reference/cli/docker/image/pull.md) command.
+2. Pull the image using the [`docker pull`](/reference/cli/docker/image/pull/) command.
 
    ```console
    docker pull docker/welcome-to-docker
@@ -126,7 +127,7 @@ Follow the instructions to search and pull a Docker image using CLI to view its
 
 ### Learn about the image
 
-1. List your downloaded images using the [`docker image ls`](/reference/cli/docker/image/ls.md) command:
+1. List your downloaded images using the [`docker image ls`](/reference/cli/docker/image/ls/) command:
 
    ```console
    docker image ls
@@ -145,7 +146,7 @@ Follow the instructions to search and pull a Docker image using CLI to view its
    >
    > The image size represented here reflects the uncompressed size of the image, not the download size of the layers.
 
-2. List the image's layers using the [`docker image history`](/reference/cli/docker/image/history.md) command:
+2. List the image's layers using the [`docker image history`](/reference/cli/docker/image/history/) command:
 
    ```console
    docker image history docker/welcome-to-docker
diff --git a/content/get-started/docker-concepts/the-basics/what-is-docker-compose.md b/content/get-started/docker-concepts/the-basics/what-is-docker-compose.md
index 90b1db134f2b..02d8b3434aa1 100644
--- a/content/get-started/docker-concepts/the-basics/what-is-docker-compose.md
+++ b/content/get-started/docker-concepts/the-basics/what-is-docker-compose.md
@@ -81,7 +81,7 @@ Follow the instructions to run the to-do list app on your system.
 
     If this feels overwhelming, don't worry! You'll get there!
 
-5. With everything now up and running, you can open [http://localhost:3000](http://localhost:3000) in your browser to see the site. Feel free to add items to the list, check them off, and remove them.
+5. With everything now up and running, you can open [http://localhost:3000](http://localhost:3000) in your browser to see the site. Note that the application may take 10-15 seconds to fully start. If the page doesn't load right away, wait a moment and refresh. Feel free to add items to the list, check them off, and remove them.
 
     ![A screenshot of a webpage showing the todo-list application running on port 3000](images/todo-list-app.webp?border=true&w=950&h=400)
 
@@ -138,5 +138,5 @@ This page was a brief introduction to Compose. In the following resources, you c
 
 
 * [Overview of Docker Compose](/compose/)
-* [Overview of Docker Compose CLI](/compose/reference/)
+* [Overview of Docker Compose CLI](/reference/cli/docker/compose/)
 * [How Compose works](/compose/intro/compose-application-model/)
diff --git a/content/get-started/docker-overview.md b/content/get-started/docker-overview.md
index 137ad7d20339..fe8b9cbb3178 100644
--- a/content/get-started/docker-overview.md
+++ b/content/get-started/docker-overview.md
@@ -26,7 +26,7 @@ significantly reduce the delay between writing code and running it in production
 ## The Docker platform
 
 Docker provides the ability to package and run an application in a loosely isolated
-environment called a container. The isolation and security lets you run many
+environment called a container. The isolation and security let you run many
 containers simultaneously on a given host. Containers are lightweight and contain
 everything needed to run the application, so you don't need to rely on what's
 installed on the host. You can share containers while you work,
@@ -107,7 +107,7 @@ Docker API. The Docker client can communicate with more than one daemon.
 
 ### Docker Desktop
 
-Docker Desktop is an easy-to-install application for your Mac, Windows or Linux environment that enables you to build and share containerized applications and microservices. Docker Desktop includes the Docker daemon (`dockerd`), the Docker client (`docker`), Docker Compose, Docker Content Trust, Kubernetes, and Credential Helper. For more information, see [Docker Desktop](/manuals/desktop/_index.md).
+Docker Desktop is an easy-to-install application for your Mac, Windows, or Linux environment that enables you to build and share containerized applications and microservices. Docker Desktop includes the Docker daemon (`dockerd`), the Docker client (`docker`), Docker Compose, Docker Content Trust, Kubernetes, and Credential Helper. For more information, see [Docker Desktop](/manuals/desktop/_index.md).
 
 ### Docker registries
 
@@ -128,8 +128,8 @@ of those objects.
 
 An image is a read-only template with instructions for creating a Docker
 container. Often, an image is based on another image, with some additional
-customization. For example, you may build an image which is based on the `ubuntu`
-image, but installs the Apache web server and your application, as well as the
+customization. For example, you may build an image that is based on the Ubuntu image 
+but includes the Apache web server and your application, as well as the
 configuration details needed to make your application run.
 
 You might create your own images or you might only use those created by others
diff --git a/content/get-started/get-docker.md b/content/get-started/get-docker.md
index 17217e7654fc..9c02b598165f 100644
--- a/content/get-started/get-docker.md
+++ b/content/get-started/get-docker.md
@@ -10,6 +10,8 @@ aliases:
  - /install/overview/
  - /installation/
  - /get-docker/
+ - /desktop/install/
+ - /desktop/setup/install/
 ---
 
 Docker is an open platform for developing, shipping, and running applications.
@@ -29,29 +31,27 @@ section and choose the best installation path for you.
 >
 > Commercial use of Docker Desktop in larger enterprises (more than 250
 > employees OR more than $10 million USD in annual revenue) requires a [paid
-> subscription](https://www.docker.com/pricing/).
+> subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsGetDocker).
 
+<div class="not-prose">
 {{< card
   title="Docker Desktop for Mac"
   description="A native application using the macOS sandbox security model that delivers all Docker tools to your Mac."
   link="/desktop/setup/install/mac-install/"
-  icon="/assets/images/apple_48.svg" >}}
-
-<br>
+  icon="/icons/AppleMac.svg" >}}
 
 {{< card
   title="Docker Desktop for Windows"
   description="A native Windows application that delivers all Docker tools to your Windows computer."
   link="/desktop/setup/install/windows-install/"
-  icon="/assets/images/windows_48.svg" >}}
-
-<br>
+  icon="/icons/Windows.svg" >}}
 
 {{< card
   title="Docker Desktop for Linux"
   description="A native Linux application that delivers all Docker tools to your Linux computer."
   link="/desktop/setup/install/linux/"
-  icon="/assets/images/linux_48.svg" >}}
+  icon="/icons/Linux.svg" >}}
+</div>
 
 > [!NOTE]
 >
diff --git a/content/get-started/introduction/_index.md b/content/get-started/introduction/_index.md
index e7362a868b5f..9434676e0ad2 100644
--- a/content/get-started/introduction/_index.md
+++ b/content/get-started/introduction/_index.md
@@ -12,11 +12,46 @@ summary: |
   commands, image creation, and container orchestration.
 layout: series
 params:
-  skill: Beginner
+  proficiencyLevel: Beginner
   time: 15 minutes
-  prereq: None
+  prerequisites: None
 aliases:
   - /guides/getting-started/
+  - /guides/get-started/
+  - /get-started/hands-on-overview/
+  - /guides/workshop/
+  - /get-started/workshop/
+  - /get-started/part2/
+  - /get-started/02_our_app/
+  - /guides/workshop/02_our_app/
+  - /guides/walkthroughs/containerize-your-app/
+  - /get-started/workshop/02_our_app/
+  - /get-started/03_updating_app/
+  - /guides/workshop/03_updating_app/
+  - /get-started/workshop/03_updating_app/
+  - /get-started/part3/
+  - /get-started/04_sharing_app/
+  - /guides/workshop/04_sharing_app/
+  - /get-started/workshop/04_sharing_app/
+  - /get-started/05_persisting_data/
+  - /guides/workshop/05_persisting_data/
+  - /get-started/workshop/05_persisting_data/
+  - /guides/walkthroughs/access-local-folder/
+  - /get-started/06_bind_mounts/
+  - /guides/workshop/06_bind_mounts/
+  - /get-started/workshop/06_bind_mounts/
+  - /get-started/07_multi_container/
+  - /guides/workshop/07_multi_container/
+  - /get-started/workshop/07_multi_container/
+  - /get-started/08_using_compose/
+  - /guides/workshop/08_using_compose/
+  - /get-started/workshop/08_using_compose/
+  - /get-started/09_image_best/
+  - /guides/workshop/09_image_best/
+  - /get-started/workshop/09_image_best/
+  - /get-started/11_what_next/
+  - /guides/workshop/10_what_next/
+  - /get-started/workshop/10_what_next/
 ---
 
 ## About this series
diff --git a/content/get-started/introduction/build-and-push-first-image.md b/content/get-started/introduction/build-and-push-first-image.md
index 0e9774036d0c..35974b839990 100644
--- a/content/get-started/introduction/build-and-push-first-image.md
+++ b/content/get-started/introduction/build-and-push-first-image.md
@@ -33,6 +33,11 @@ If you’re new to container images, think of them as a standardized package tha
 
 To share your Docker images, you need a place to store them. This is where registries come in. While there are many registries, Docker Hub is the default and go-to registry for images. Docker Hub provides both a place for you to store your own images and to find images from others to either run or use as the bases for your own images.
 
+When choosing base images, Docker Hub offers two categories of trusted, Docker-maintained images:
+
+- [Docker Official Images (DOI)](/manuals/docker-hub/image-library/trusted-content.md#docker-official-images) – Curated images for popular software, following best practices and regularly updated.
+- [Docker Hardened Images (DHI)](/manuals/dhi/_index.md) – Minimal, secure, production-ready images with near-zero CVEs, designed to reduce attack surface and simplify compliance. DHI images are free and open source under Apache 2.0.
+
 In [Develop with containers](develop-with-containers.md), you used the following images that came from Docker Hub, each of which are [Docker Official Images](/manuals/docker-hub/image-library/trusted-content.md#docker-official-images):
 
 - [node](https://hub.docker.com/_/node) - provides a Node environment and is used as the base of your development efforts. This image is also used as the base for the final application image.
@@ -40,7 +45,11 @@ In [Develop with containers](develop-with-containers.md), you used the following
 - [phpmyadmin](https://hub.docker.com/_/phpmyadmin) - provides phpMyAdmin, a web-based interface to the MySQL database
 - [traefik](https://hub.docker.com/_/traefik) - provides Traefik, a modern HTTP reverse proxy and load balancer that routes requests to the appropriate container based on routing rules
 
-Explore the full catalog of [Docker Official Images](https://hub.docker.com/search?image_filter=official&q=), [Docker Verified Publishers](https://hub.docker.com/search?q=&image_filter=store), and [Docker Sponsored Open Source Software](https://hub.docker.com/search?q=&image_filter=open_source) images to see more of what there is to run and build on.
+Explore the full catalog of trusted content on Docker Hub:
+- [Docker Official Images](https://hub.docker.com/search?badges=official) – Curated images for popular software
+- [Docker Hardened Images](https://hub.docker.com/hardened-images/catalog) – Security-hardened, minimal production images (also available at [dhi.io](https://dhi.io))
+- [Docker Verified Publishers](https://hub.docker.com/search?badges=verified_publisher) – Images from verified software vendors
+- [Docker Sponsored Open Source](https://hub.docker.com/search?badges=open_source) – Images from sponsored OSS projects
 
 ## Try it out
 
diff --git a/content/get-started/introduction/develop-with-containers.md b/content/get-started/introduction/develop-with-containers.md
index a4fa425515f7..f3fd5d8f4dd6 100644
--- a/content/get-started/introduction/develop-with-containers.md
+++ b/content/get-started/introduction/develop-with-containers.md
@@ -9,7 +9,7 @@ summary: |
   seamless integration and testing.
 weight: 2
 aliases:
- - /guides/getting-started/develop-with-containers/
+  - /guides/getting-started/develop-with-containers/
 ---
 
 {{< youtube-embed D0SDBrS3t9I >}}
@@ -26,25 +26,23 @@ Now that you have Docker Desktop installed, you are ready to do some application
 
 In this hands-on guide, you'll learn how to develop with containers.
 
-
 ## Start the project
 
 1. To get started, either clone or [download the project as a ZIP file](https://github.com/docker/getting-started-todo-app/archive/refs/heads/main.zip) to your local machine.
 
-    ```console
-    $ git clone https://github.com/docker/getting-started-todo-app
-    ```
+   ```console
+   $ git clone https://github.com/docker/getting-started-todo-app
+   ```
 
-    And after the project is cloned, navigate into the new directory created by the clone:
+   And after the project is cloned, navigate into the new directory created by the clone:
 
-    ```console
-    $ cd getting-started-todo-app
-    ```
+   ```console
+   $ cd getting-started-todo-app
+   ```
 
 2. Once you have the project, start the development environment using Docker Compose.
 
-
-    To start the project using the CLI, run the following command:
+   To start the project using the CLI, run the following command:
 
    ```console
    $ docker compose watch
@@ -52,11 +50,9 @@ In this hands-on guide, you'll learn how to develop with containers.
 
    You will see an output that shows container images being pulled down, containers starting, and more. Don't worry if you don't understand it all at this point. But, within a moment or two, things should stabilize and finish.
 
-
 3. Open your browser to [http://localhost](http://localhost) to see the application up and running. It may take a few minutes for the app to run. The app is a simple to-do application, so feel free to add an item or two, mark some as done, or even delete an item.
 
-    ![Screenshot of the getting started to-do app after its first launch](images/develop-getting-started-app-first-launch.webp)
-
+   ![Screenshot of the getting started to-do app after its first launch](images/develop-getting-started-app-first-launch.webp)
 
 ### What's in the environment?
 
@@ -70,7 +66,6 @@ Now that the environment is up and running, what's actually in it? At a high-lev
 
 With this environment, you as the developer don’t need to install or configure any services, populate a database schema, configure database credentials, or anything. You only need Docker Desktop. The rest just works.
 
-
 ## Make changes to the app
 
 With this environment up and running, you’re ready to make a few changes to the application and see how Docker helps provide a fast feedback loop.
@@ -79,77 +74,78 @@ With this environment up and running, you’re ready to make a few changes to th
 
 The greeting at the top of the page is populated by an API call at `/api/greeting`. Currently, it always returns "Hello world!". You’ll now modify it to return one of three randomized messages (that you'll get to choose).
 
-1. Open the `backend/src/routes/getGreeting.js` file in a text editor. This file provides the handler for the API endpoint.
+1. Open the `backend/src/routes/getGreeting.js` file in a text editor on
+   your local machine (in the cloned project directory). This file provides
+   the handler for the API endpoint. Your changes will automatically sync to
+   the running container.
 
 2. Modify the variable at the top to an array of greetings. Feel free to use the following modifications or customize it to your own liking. Also, update the endpoint to send a random greeting from this list.
 
-    ```js {linenos=table,hl_lines=["1-5",9],linenostart=1}
-    const GREETINGS = [
-        "Whalecome!",
-        "All hands on deck!",
-        "Charting the course ahead!",
-    ];
-
-    module.exports = async (req, res) => {
-        res.send({
-            greeting: GREETINGS[ Math.floor( Math.random() * GREETINGS.length )],
-        });
-    };
-    ```
+   ```js {linenos=table,hl_lines=["1-5",9],linenostart=1}
+   const GREETINGS = [
+     "Whalecome!",
+     "All hands on deck!",
+     "Charting the course ahead!",
+   ];
+
+   module.exports = async (req, res) => {
+     res.send({
+       greeting: GREETINGS[Math.floor(Math.random() * GREETINGS.length)],
+     });
+   };
+   ```
 
 3. If you haven't done so yet, save the file. If you refresh your browser, you should see a new greeting. If you keep refreshing, you should see all of the messages appear.
 
-    ![Screenshot of the to-do app with a new greeting](images/develop-app-with-greetings.webp)
-
+   ![Screenshot of the to-do app with a new greeting](images/develop-app-with-greetings.webp)
 
 ### Change the placeholder text
 
 When you look at the app, you'll see the placeholder text is simply "New Item". You’ll now make that a little more descriptive and fun. You’ll also make a few changes to the styling of the app too.
 
-1. Open the `client/src/components/AddNewItemForm.jsx` file. This provides the component to add a new item to the to-do list.
+1. Open the `client/src/components/AddNewItemForm.jsx` file in your local
+   project directory. This provides the component to add a new item to the
+   to-do list.
 
 2. Modify the `placeholder` attribute of the `Form.Control` element to whatever you'd like to display.
 
-    ```js {linenos=table,hl_lines=[5],linenostart=33}
-    <Form.Control
-        value={newItem}
-        onChange={(e) => setNewItem(e.target.value)}
-        type="text"
-        placeholder="What do you need to do?"
-        aria-label="New item"
-    />
-    ```
+   ```js {linenos=table,hl_lines=[5],linenostart=33}
+   <Form.Control
+     value={newItem}
+     onChange={(e) => setNewItem(e.target.value)}
+     type="text"
+     placeholder="What do you need to do?"
+     aria-label="New item"
+   />
+   ```
 
 3. Save the file and go back to your browser. You should see the change already hot-reloaded into your browser. If you don't like it, feel free to tweak it until it looks just right.
 
 ![Screenshot of the to-do app with an updated placeholder in the add item text field"](images/develop-app-with-updated-placeholder.webp)
 
-
 ### Change the background color
 
 Before you consider the application finalized, you need to make the colors better.
 
-1. Open the `client/src/index.scss` file.
+1. Open the `client/src/index.scss` file in your local project directory.
 
 2. Adjust the `background-color` attribute to any color you'd like. The provided snippet is a soft blue to go along with Docker's nautical theme.
 
-    If you're using an IDE, you can pick a color using the integrated color pickers. Otherwise, feel free to use an online [Color Picker](https://www.w3schools.com/colors/colors_picker.asp).
-
-    ```css {linenos=table,hl_lines=2,linenostart=3}
-    body {
-        background-color: #99bbff;
-        margin-top: 50px;
-        font-family: 'Lato';
-    }
-    ```
-
-    Each save should let you see the change immediately in the browser. Keep adjusting it until it's the perfect setup for you.
+   If you're using an IDE, you can pick a color using the integrated color pickers. Otherwise, feel free to use an online [Color Picker](https://www.w3schools.com/colors/colors_picker.asp).
 
+   ```css {linenos=table,hl_lines=2,linenostart=3}
+   body {
+     background-color: #99bbff;
+     margin-top: 50px;
+     font-family: "Lato";
+   }
+   ```
 
-    ![Screenshot of the to-do app with a new placeholder and background color"](images/develop-app-with-updated-client.webp)
+   Each save should let you see the change immediately in the browser. Keep adjusting it until it's the perfect setup for you.
 
-And with that, you're done. Congrats on updating your website. 
+   ![Screenshot of the to-do app with a new placeholder and background color"](images/develop-app-with-updated-client.webp)
 
+And with that, you're done. Congrats on updating your website.
 
 ## Recap
 
@@ -157,7 +153,11 @@ Before you move on, take a moment and reflect on what happened here. Within a fe
 
 - Start a complete development project with zero installation effort. The containerized environment provided the development environment, ensuring you have everything you need. You didn't have to install Node, MySQL, or any of the other dependencies directly on your machine. All you needed was Docker Desktop and a code editor.
 
-- Make changes and see them immediately. This was made possible because 1) the processes running in each container are watching and responding to file changes and 2) the files are shared with the containerized environment.
+- Make changes and see them immediately. This was made possible because
+  1. the processes running in each container are watching and responding to
+     file changes and 2) the files in your local project directory are shared
+     with the containerized environment, so edits you make locally are
+     automatically synced to the containers.
 
 Docker Desktop enables all of this and so much more. Once you start thinking with containers, you can create almost any environment and easily share it with your team.
 
@@ -166,4 +166,3 @@ Docker Desktop enables all of this and so much more. Once you start thinking wit
 Now that the application has been updated, you’re ready to learn about packaging it as a container image and pushing it to a registry, specifically Docker Hub.
 
 {{< button text="Build and push your first image" url="build-and-push-first-image" >}}
-
diff --git a/content/get-started/introduction/get-docker-desktop.md b/content/get-started/introduction/get-docker-desktop.md
index 123c0ef1cefe..f310736e82c7 100644
--- a/content/get-started/introduction/get-docker-desktop.md
+++ b/content/get-started/introduction/get-docker-desktop.md
@@ -24,26 +24,24 @@ This guide will walk you through the installation process, enabling you to exper
 > **Docker Desktop terms**
 >
 > Commercial use of Docker Desktop in larger enterprises (more than 250
-> employees OR more than $10 million USD in annual revenue) requires a [paid subscription](https://www.docker.com/pricing/?_gl=1*1nyypal*_ga*MTYxMTUxMzkzOS4xNjgzNTM0MTcw*_ga_XJWPQMJYHQ*MTcxNjk4MzU4Mi4xMjE2LjEuMTcxNjk4MzkzNS4xNy4wLjA.).
+> employees OR more than $10 million USD in annual revenue) requires a [paid subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsGetDockerDesktop).
 
+<div class="not-prose">
 {{< card
   title="Docker Desktop for Mac"
   description="[Download (Apple Silicon)](https://desktop.docker.com/mac/main/arm64/Docker.dmg?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-mac-arm64) | [Download (Intel)](https://desktop.docker.com/mac/main/amd64/Docker.dmg?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-mac-amd64) | [Install instructions](/desktop/setup/install/mac-install)"
-  icon="/assets/images/apple_48.svg" >}}
-
-<br>
+  icon="/icons/AppleMac.svg" >}}
 
 {{< card
   title="Docker Desktop for Windows"
   description="[Download](https://desktop.docker.com/win/main/amd64/Docker%20Desktop%20Installer.exe?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-windows) | [Install instructions](/desktop/setup/install/windows-install)"
-  icon="/assets/images/windows_48.svg" >}}
-
-<br>
+  icon="/icons/Windows.svg" >}}
 
 {{< card
   title="Docker Desktop for Linux"
   description="[Install instructions](/desktop/setup/install/linux/)"
-  icon="/assets/images/linux_48.svg" >}}
+  icon="/icons/Linux.svg" >}}
+</div>
 
 Once it's installed, complete the setup process and you're all set to run a Docker container.
 
@@ -94,4 +92,3 @@ Docker Desktop simplifies container management for developers by streamlining th
 Now that you have Docker Desktop installed and ran your first container, it's time to start developing with containers.
 
 {{< button text="Develop with containers" url="develop-with-containers" >}}
-
diff --git a/content/get-started/introduction/images/exec-into-docker-container.webp b/content/get-started/introduction/images/exec-into-docker-container.webp
index 5b9368b90497..3da6ac9f3e57 100644
Binary files a/content/get-started/introduction/images/exec-into-docker-container.webp and b/content/get-started/introduction/images/exec-into-docker-container.webp differ
diff --git a/content/get-started/introduction/images/inspecting-container.webp b/content/get-started/introduction/images/inspecting-container.webp
index 889c34d2f328..5c2da7f9423e 100644
Binary files a/content/get-started/introduction/images/inspecting-container.webp and b/content/get-started/introduction/images/inspecting-container.webp differ
diff --git a/content/get-started/introduction/whats-next.md b/content/get-started/introduction/whats-next.md
index 5948ca3a0315..57f061009fc4 100644
--- a/content/get-started/introduction/whats-next.md
+++ b/content/get-started/introduction/whats-next.md
@@ -1,7 +1,7 @@
 ---
 title: What's next 
 keywords: concepts, build, images, container, docker desktop
-description: Explore step-by-step guides to hep you understand core Docker concepts, building images, and running containers.
+description: Explore step-by-step guides to help you understand core Docker concepts, building images, and running containers.
 aliases:
  - /guides/getting-started/whats-next/
 summary: |
diff --git a/content/get-started/resources.md b/content/get-started/resources.md
index 985458384d69..c77be4bf2451 100644
--- a/content/get-started/resources.md
+++ b/content/get-started/resources.md
@@ -9,37 +9,15 @@ Docker and the broader community of Docker experts have put together many differ
 
 ## Docker Training
 
-Expand your knowledge on all things Docker with [basic to advanced trainings from Docker experts](https://www.docker.com/resources/trainings/). 
-
-You can find recorded content at your own convenience, or register for a live session to participate in Q&A.
-
-## Hosted labs
-
-These self-paced and hands-on workshops use a free, hosted environment ([Play with Kubernetes](https://labs.play-with-k8s.com/)) that doesn't require any installation. Follow along and learn more about Kubernetes.
-
-* [Kubernetes Workshop](https://training.play-with-kubernetes.com/kubernetes-workshop/)
-
-\* Labs are free but require registration with a Docker ID.
-
-## Self-guided tutorials
-
-Created by experts in the Docker community, these free tutorials provide guided step-by-step workflows for working with the Docker platform.
-
-* **Integrating Docker with Your IDE**
-    * [Java Development: Eclipse](https://training.play-with-docker.com/java-debugging-eclipse/)
-    * [Java Development: IntelliJ](https://training.play-with-docker.com/java-debugging-intellij/)
-    * [Java Development: Netbeans](https://training.play-with-docker.com/java-debugging-netbeans/)
-    * [Live Debugging Node.js with Docker and Visual Studio Code](https://training.play-with-docker.com/nodejs-live-debugging/)
-
-* **Windows Containers**
-    * [Windows Container Setup](https://training.play-with-docker.com/windows-containers-setup/)
-    * [Windows Container Basics](https://training.play-with-docker.com/windows-containers-basics/)
-    * [Windows Containers Multi-Container Applications](https://training.play-with-docker.com/windows-containers-multicontainer/)
+Learn Docker and containerization fundamentals through self-paced, [hands-on training courses](/get-started/introduction) created by Docker experts.
 
 ## Books
 
 If books are your preferred learning style, check out these written by the [Docker Captains](https://www.docker.com/community/captains). Docker Captain is a distinction that Docker awards to select members of the community that are both experts in their field and are committed to sharing their Docker knowledge with others.
 
+* [Operational AI with Docker](https://www.amazon.com/Operational-AI-Docker-services-Kubernetes/dp/1807301095),  Ajeet Singh Raina & Harsh Manvar, April 2026
+* [Docker and Kubernetes Security](https://www.dockersecurity.io/), Mohammad-Ali A'râbi, October 2025. Get 50% discount on PDF version with the code `AHOYCAPTAIN` on [buy.DockerSecurity.io](https://buy.dockersecurity.io/).
+* [Docker for React.js Developers](https://www.dockerfrontend.com/), Kristiyan Velkov. Learn Docker from a front-end perspective with practical, production-ready examples for modern React.js applications. Get **30% off** with the code `DOCKER30` at [www.dockerfrontend.com](https://www.dockerfrontend.com/) or [www.kristiyanvelkov.com](https://www.kristiyanvelkov.com)
 * [Learn Docker in a Month of Lunches](https://www.manning.com/books/learn-docker-in-a-month-of-lunches), Elton Stoneman. Use the code `stonemanpc` for a 40% discount.
 * [Docker on Windows: From 101 to Production with Docker on Windows](https://www.amazon.com/Docker-Windows-Elton-Stoneman-ebook/dp/B0711Y4J9K/), Elton Stoneman
 * [Learn Kubernetes in a Month of Lunches](https://www.manning.com/books/learn-kubernetes-in-a-month-of-lunches), Elton Stoneman. Use the code `stonemanpc` for a 40% discount.
@@ -62,18 +40,7 @@ A number of Docker Captains have also created video courses on Docker and Kubern
 * [Elton Stoneman](https://docker4.net/udemy): Docker for .NET Apps - on Linux and Windows. Includes the discount code `644ABCBC33F474541885`.
 * [Nick Janetakis](https://nickjanetakis.com/courses/) Dive into Docker, Docker for DevOps
 * [Nigel Poulton](https://nigelpoulton.com/video-courses): Kubernetes 101, Getting Started with Kubernetes, Docker and Kubernetes: The Big Picture, Kubernetes Deep Dive, Docker Deep Dive
-* [Arun Gupta](https://www.lynda.com/Docker-tutorials/Docker-Java-developers/576584-2.html): Docker for Java Developers
 * [Ajeet Singh Raina](https://collabnix.com/): Docker and Kubernetes Labs
 * \[French\] [Luc Juggery](https://www.udemy.com/user/lucjuggery/): Introduction to Kubernetes, The Docker Platform
 
 \* Many of the courses are fee-based
-
-## Community-translated docs
-
-> [!NOTE]
->
-> The following section contains a subset of Docker docs that are translated by community
-> members. This is not an officially translated version of Docker docs and it may not be up to date.
-> You must use the community-translated docs at your own discretion.
-
-- [Subset of Docker docs in Japanese](https://docs.docker.jp/index.html) translated by Docker Captain [Masahito Zembutsu](https://github.com/zembutsu).
diff --git a/content/get-started/workshop/02_our_app.md b/content/get-started/workshop/02_our_app.md
deleted file mode 100644
index 563871f9c233..000000000000
--- a/content/get-started/workshop/02_our_app.md
+++ /dev/null
@@ -1,167 +0,0 @@
----
-title: Containerize an application
-weight: 20
-linkTitle: "Part 1: Containerize an application"
-keywords: |
-  dockerfile example, Containerize an application, run docker file, running
-  docker file, how to run dockerfile, example dockerfile, how to create a docker container,
-  create dockerfile, simple dockerfile, creating containers
-description: |
-  Follow this step-by-step guide to learn how to create and run a containerized
-  application using Docker
-aliases:
-  - /get-started/part2/
-  - /get-started/02_our_app/
-  - /guides/workshop/02_our_app/
-  - /guides/walkthroughs/containerize-your-app/
----
-
-For the rest of this guide, you'll be working with a simple todo
-list manager that runs on Node.js. If you're not familiar with Node.js,
-don't worry. This guide doesn't require any prior experience with JavaScript.
-
-## Prerequisites
-
-- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
-- You have installed a [Git client](https://git-scm.com/downloads).
-- You have an IDE or a text editor to edit files. Docker recommends using [Visual Studio Code](https://code.visualstudio.com/).
-
-## Get the app
-
-Before you can run the application, you need to get the application source code onto your machine.
-
-1. Clone the [getting-started-app repository](https://github.com/docker/getting-started-app/tree/main) using the following command:
-
-   ```console
-   $ git clone https://github.com/docker/getting-started-app.git
-   ```
-
-2. View the contents of the cloned repository. You should see the following files and sub-directories.
-
-   ```text
-   ├── getting-started-app/
-   │ ├── .dockerignore
-   │ ├── package.json
-   │ ├── README.md
-   │ ├── spec/
-   │ ├── src/
-   │ └── yarn.lock
-   ```
-
-## Build the app's image
-
-To build the image, you'll need to use a Dockerfile. A Dockerfile is simply a text-based file with no file extension that contains a script of instructions. Docker uses this script to build a container image.
-
-1. In the `getting-started-app` directory, the same location as the
-   `package.json` file, create a file named `Dockerfile` with the following contents:
-
-   ```dockerfile
-   # syntax=docker/dockerfile:1
-
-   FROM node:lts-alpine
-   WORKDIR /app
-   COPY . .
-   RUN yarn install --production
-   CMD ["node", "src/index.js"]
-   EXPOSE 3000
-   ```
-
-   This Dockerfile starts off with a `node:lts-alpine` base image, a
-   light-weight Linux image that comes with Node.js and the Yarn package
-   manager pre-installed. It copies all of the source code into the image,
-   installs the necessary dependencies, and starts the application.
-
-2. Build the image using the following commands:
-
-   In the terminal, make sure you're in the `getting-started-app` directory. Replace `/path/to/getting-started-app` with the path to your `getting-started-app` directory.
-
-   ```console
-   $ cd /path/to/getting-started-app
-   ```
-
-   Build the image.
-
-   ```console
-   $ docker build -t getting-started .
-   ```
-
-   The `docker build` command uses the Dockerfile to build a new image. You might have noticed that Docker downloaded a lot of "layers". This is because you instructed the builder that you wanted to start from the `node:lts-alpine` image. But, since you didn't have that on your machine, Docker needed to download the image.
-
-   After Docker downloaded the image, the instructions from the Dockerfile copied in your application and used `yarn` to install your application's dependencies. The `CMD` directive specifies the default command to run when starting a container from this image.
-
-   Finally, the `-t` flag tags your image. Think of this as a human-readable name for the final image. Since you named the image `getting-started`, you can refer to that image when you run a container.
-
-   The `.` at the end of the `docker build` command tells Docker that it should look for the `Dockerfile` in the current directory.
-
-## Start an app container
-
-Now that you have an image, you can run the application in a container using the `docker run` command.
-
-1. Run your container using the `docker run` command and specify the name of the image you just created:
-
-   ```console
-   $ docker run -d -p 127.0.0.1:3000:3000 getting-started
-   ```
-
-   The `-d` flag (short for `--detach`) runs the container in the background.
-   This means that Docker starts your container and returns you to the terminal
-   prompt. Also, it does not display logs in the terminal.
-
-   The `-p` flag (short for `--publish`) creates a port mapping between the
-   host and the container. The `-p` flag takes a string value in the format of
-   `HOST:CONTAINER`, where `HOST` is the address on the host, and `CONTAINER`
-   is the port on the container. The command publishes the container's port
-   3000 to `127.0.0.1:3000` (`localhost:3000`) on the host. Without the port
-   mapping, you wouldn't be able to access the application from the host.
-
-2. After a few seconds, open your web browser to [http://localhost:3000](http://localhost:3000).
-   You should see your app.
-
-   ![Empty todo list](images/todo-list-empty.webp)
-
-3. Add an item or two and see that it works as you expect. You can mark items as complete and remove them. Your frontend is successfully storing items in the backend.
-
-At this point, you have a running todo list manager with a few items.
-
-If you take a quick look at your containers, you should see at least one container running that's using the `getting-started` image and on port `3000`. To see your containers, you can use the CLI or Docker Desktop's graphical interface.
-
-{{< tabs >}}
-{{< tab name="CLI" >}}
-
-Run the `docker ps` command in a terminal to list your containers.
-
-```console
-$ docker ps
-```
-
-Output similar to the following should appear.
-
-```console
-CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                      NAMES
-df784548666d        getting-started     "docker-entrypoint.s…"   2 minutes ago       Up 2 minutes        127.0.0.1:3000->3000/tcp   priceless_mcclintock
-```
-
-{{< /tab >}}
-{{< tab name="Docker Desktop" >}}
-
-In Docker Desktop, select the **Containers** tab to see a list of your containers.
-
-![Docker Desktop with get-started container running](images/dashboard-two-containers.webp)
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Summary
-
-In this section, you learned the basics about creating a Dockerfile to build an image. Once you built an image, you started a container and saw the running app.
-
-Related information:
-
-- [Dockerfile reference](/reference/dockerfile/)
-- [docker CLI reference](/reference/cli/docker/)
-
-## Next steps
-
-Next, you're going to make a modification to your app and learn how to update your running application with a new image. Along the way, you'll learn a few other useful commands.
-
-{{< button text="Update the application" url="03_updating_app.md" >}}
diff --git a/content/get-started/workshop/03_updating_app.md b/content/get-started/workshop/03_updating_app.md
deleted file mode 100644
index 50bce7e01332..000000000000
--- a/content/get-started/workshop/03_updating_app.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Update the application
-weight: 30
-linkTitle: "Part 2: Update the application"
-keywords: get started, setup, orientation, quickstart, intro, concepts, containers,
-  docker desktop
-description: Making changes to your application
-aliases:
- - /get-started/03_updating_app/
- - /guides/workshop/03_updating_app/
----
-
-In [part 1](./02_our_app.md), you containerized a todo application. In this part, you'll update the application and image. You'll also learn how to stop and remove a container.
-
-## Update the source code
-
-In the following steps, you'll change the "empty text" when you don't have any todo list items to "You have no todo items yet! Add one above!"
-
-
-1. In the `src/static/js/app.js` file, update line 56 to use the new empty text.
-
-   ```diff
-   - <p className="text-center">No items yet! Add one above!</p>
-   + <p className="text-center">You have no todo items yet! Add one above!</p>
-   ```
-
-2. Build your updated version of the image, using the `docker build` command.
-
-   ```console
-   $ docker build -t getting-started .
-   ```
-
-3. Start a new container using the updated code.
-
-   ```console
-   $ docker run -dp 127.0.0.1:3000:3000 getting-started
-   ```
-
-You probably saw an error like this:
-
-```console
-docker: Error response from daemon: driver failed programming external connectivity on endpoint laughing_burnell 
-(bb242b2ca4d67eba76e79474fb36bb5125708ebdabd7f45c8eaf16caaabde9dd): Bind for 127.0.0.1:3000 failed: port is already allocated.
-```
-
-The error occurred because you aren't able to start the new container while your old container is still running. The reason is that the old container is already using the host's port 3000 and only one process on the machine (containers included) can listen to a specific port. To fix this, you need to remove the old container.
-
-## Remove the old container
-
-To remove a container, you first need to stop it. Once it has stopped, you can remove it. You can remove the old container using the CLI or Docker Desktop's graphical interface. Choose the option that you're most comfortable with.
-
-{{< tabs >}}
-{{< tab name="CLI" >}}
-
-### Remove a container using the CLI
-
-1. Get the ID of the container by using the `docker ps` command.
-
-   ```console
-   $ docker ps
-   ```
-
-2. Use the `docker stop` command to stop the container. Replace `<the-container-id>` with the ID from `docker ps`.
-
-   ```console
-   $ docker stop <the-container-id>
-   ```
-
-3. Once the container has stopped, you can remove it by using the `docker rm` command.
-
-   ```console
-   $ docker rm <the-container-id>
-   ```
-
-> [!NOTE]
->
-> You can stop and remove a container in a single command by adding the `force` flag to the `docker rm` command. For example: `docker rm -f <the-container-id>`
-
-{{< /tab >}}
-{{< tab name="Docker Desktop" >}}
-
-### Remove a container using Docker Desktop
-
-1. Open Docker Desktop to the **Containers** view.
-2. Select the trash can icon under the **Actions** column for the container that you want to delete.
-3. In the confirmation dialog, select **Delete forever**.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Start the updated app container
-
-1. Now, start your updated app using the `docker run` command.
-
-   ```console
-   $ docker run -dp 127.0.0.1:3000:3000 getting-started
-   ```
-
-2. Refresh your browser on [http://localhost:3000](http://localhost:3000) and you should see your updated help text.
-
-## Summary
-
-In this section, you learned how to update and rebuild a container, as well as how to stop and remove a container.
-
-Related information:
- - [docker CLI reference](/reference/cli/docker/)
-
-## Next steps
-
-Next, you'll learn how to share images with others.
-
-{{< button text="Share the application" url="04_sharing_app.md" >}}
diff --git a/content/get-started/workshop/04_sharing_app.md b/content/get-started/workshop/04_sharing_app.md
deleted file mode 100644
index 5ba3b09f065f..000000000000
--- a/content/get-started/workshop/04_sharing_app.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: Share the application
-weight: 40
-linkTitle: "Part 3: Share the application"
-keywords: get started, setup, orientation, quickstart, intro, concepts, containers,
-  docker desktop, docker hub, sharing
-description: Sharing your image you built for your example application so you can
-  run it else where and other developers can use it
-aliases:
- - /get-started/part3/
- - /get-started/04_sharing_app/
- - /guides/workshop/04_sharing_app/
----
-
-Now that you've built an image, you can share it. To share Docker images, you have to use a Docker
-registry. The default registry is Docker Hub and is where all of the images you've used have come from.
-
-> **Docker ID**
->
-> A Docker ID lets you access Docker Hub, which is the world's largest library and community for container images. Create a [Docker ID](https://hub.docker.com/signup) for free if you don't have one.
-
-## Create a repository
-
-To push an image, you first need to create a repository on Docker Hub.
-
-1. [Sign up](https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade) or Sign in to [Docker Hub](https://hub.docker.com).
-
-2. Select the **Create Repository** button.
-
-3. For the repository name, use `getting-started`. Make sure the **Visibility** is **Public**.
-
-4. Select **Create**.
-
-In the following image, you can see an example Docker command from Docker Hub. This command will push to this repository.
-
-![Docker command with push example](images/push-command.webp)
-
-
-## Push the image
-
-1. In the command line, run the `docker push` command that you see on Docker
-   Hub. Note that your command will have your Docker ID, not "docker". For example, `docker push YOUR-USER-NAME/getting-started`.
-
-   ```console
-   $ docker push docker/getting-started
-   The push refers to repository [docker.io/docker/getting-started]
-   An image does not exist locally with the tag: docker/getting-started
-   ```
-
-    Why did it fail? The push command was looking for an image named `docker/getting-started`, but
-    didn't find one. If you run `docker image ls`, you won't see one either.
-
-    To fix this, you need to tag your existing image you've built to give it another name.
-
-2. Sign in to Docker Hub using the command `docker login -u YOUR-USER-NAME`.
-
-3. Use the `docker tag` command to give the `getting-started` image a new name. Replace `YOUR-USER-NAME` with your Docker ID.
-
-   ```console
-   $ docker tag getting-started YOUR-USER-NAME/getting-started
-   ```
-
-4. Now run the `docker push` command again. If you're copying the value from
-   Docker Hub, you can drop the `tagname` part, as you didn't add a tag to the
-   image name. If you don't specify a tag, Docker uses a tag called `latest`.
-
-   ```console
-   $ docker push YOUR-USER-NAME/getting-started
-   ```
-
-## Run the image on a new instance
-
-Now that your image has been built and pushed into a registry, try running your app on a brand
-new instance that has never seen this container image. To do this, you will use Play with Docker.
-
-> [!NOTE]
->
-> Play with Docker uses the amd64 platform. If you are using an ARM based Mac with Apple silicon, you will need to rebuild the image to be compatible with Play with Docker and push the new image to your repository.
->
-> To build an image for the amd64 platform, use the `--platform` flag.
-> ```console
-> $ docker build --platform linux/amd64 -t YOUR-USER-NAME/getting-started .
-> ```
->
-> Docker buildx also supports building multi-platform images. To learn more, see [Multi-platform images](/manuals/build/building/multi-platform.md).
-
-
-1. Open your browser to [Play with Docker](https://labs.play-with-docker.com/).
-
-2. Select **Login** and then select **docker** from the drop-down list.
-
-3. Sign in with your Docker Hub account and then select **Start**.
-
-4. Select the **ADD NEW INSTANCE** option on the left side bar. If you don't see it, make your browser a little wider. After a few seconds, a terminal window opens in your browser.
-
-    ![Play with Docker add new instance](images/pwd-add-new-instance.webp)
-
-5. In the terminal, start your freshly pushed app.
-
-   ```console
-   $ docker run -dp 0.0.0.0:3000:3000 YOUR-USER-NAME/getting-started
-   ```
-
-    You should see the image get pulled down and eventually start up.
-
-    > [!TIP]
-    >
-    > You may have noticed that this command binds the port mapping to a
-    > different IP address. Previous `docker run` commands published ports to
-    > `127.0.0.1:3000` on the host. This time, you're using `0.0.0.0`.
-    >
-    > Binding to `127.0.0.1` only exposes a container's ports to the loopback
-    > interface. Binding to `0.0.0.0`, however, exposes the container's port
-    > on all interfaces of the host, making it available to the outside world.
-    >
-    > For more information about how port mapping works, see
-    > [Networking](/manuals/engine/network/_index.md#published-ports).
-
-6. Select the 3000 badge when it appears.
-
-   If the 3000 badge doesn't appear, you can select **Open Port** and specify `3000`.
-
-## Summary
-
-In this section, you learned how to share your images by pushing them to a
-registry. You then went to a brand new instance and were able to run the freshly
-pushed image. This is quite common in CI pipelines, where the pipeline will
-create the image and push it to a registry and then the production environment
-can use the latest version of the image.
-
-Related information:
-
- - [docker CLI reference](/reference/cli/docker/)
- - [Multi-platform images](/manuals/build/building/multi-platform.md)
- - [Docker Hub overview](/manuals/docker-hub/_index.md)
-
-## Next steps
-
-In the next section, you'll learn how to persist data in your containerized application.
-
-{{< button text="Persist the DB" url="05_persisting_data.md" >}}
diff --git a/content/get-started/workshop/05_persisting_data.md b/content/get-started/workshop/05_persisting_data.md
deleted file mode 100644
index 43501ce516c7..000000000000
--- a/content/get-started/workshop/05_persisting_data.md
+++ /dev/null
@@ -1,210 +0,0 @@
----
-title: Persist the DB
-weight: 50
-linkTitle: "Part 4: Persist the DB"
-keywords: get started, setup, orientation, quickstart, intro, concepts, containers,
-  docker desktop
-description: Making your DB persistent in your application
-aliases:
- - /get-started/05_persisting_data/
- - /guides/workshop/05_persisting_data/
----
-
-In case you didn't notice, your todo list is empty every single time
-you launch the container. Why is this? In this part, you'll dive into how the container is working.
-
-## The container's filesystem
-
-When a container runs, it uses the various layers from an image for its filesystem.
-Each container also gets its own "scratch space" to create/update/remove files. Any
-changes won't be seen in another container, even if they're using the same image.
-
-### See this in practice
-
-To see this in action, you're going to start two containers. In one container,
-you'll create a file. In the other container, you'll check whether that same
-file exists.
-
-1. Start an Alpine container and create a new file in it.
-
-    ```console
-    $ docker run --rm alpine touch greeting.txt
-    ```
-
-    > [!TIP]
-    > Any commands you specify after the image name (in this case, `alpine`)
-    > are executed inside the container. In this case, the command `touch
-    > greeting.txt` puts a file named `greeting.txt` on the container's filesystem.
-
-2. Run a new Alpine container and use the `stat` command to check whether the file exists.
-   
-   ```console
-   $ docker run --rm alpine stat greeting.txt
-   ```
-
-   You should see output similar to the following that indicates the file does not exist in the new container.
-
-   ```console
-   stat: can't stat 'greeting.txt': No such file or directory
-   ```
-
-The `greeting.txt` file created by the first container did not exist in the
-second container. That is because the writeable "top layer" of each container
-is isolated. Even though both containers shared the same underlying layers that
-make up the base image, the writable layer is unique to each container.
-
-## Container volumes
-
-With the previous experiment, you saw that each container starts from the image definition each time it starts. 
-While containers can create, update, and delete files, those changes are lost when you remove the container 
-and Docker isolates all changes to that container. With volumes, you can change all of this.
-
-[Volumes](/manuals/engine/storage/volumes.md) provide the ability to connect specific filesystem paths of 
-the container back to the host machine. If you mount a directory in the container, changes in that
-directory are also seen on the host machine. If you mount that same directory across container restarts, you'd see
-the same files.
-
-There are two main types of volumes. You'll eventually use both, but you'll start with volume mounts.
-
-## Persist the todo data
-
-By default, the todo app stores its data in a SQLite database at
-`/etc/todos/todo.db` in the container's filesystem. If you're not familiar with SQLite, no worries! It's simply a relational database that stores all the data in a single file. While this isn't the best for large-scale applications,
-it works for small demos. You'll learn how to switch this to a different database engine later.
-
-With the database being a single file, if you can persist that file on the host and make it available to the
-next container, it should be able to pick up where the last one left off. By creating a volume and attaching
-(often called "mounting") it to the directory where you stored the data, you can persist the data. As your container 
-writes to the `todo.db` file, it will persist the data to the host in the volume.
-
-As mentioned, you're going to use a volume mount. Think of a volume mount as an opaque bucket of data. 
-Docker fully manages the volume, including the storage location on disk. You only need to remember the
-name of the volume.
-
-### Create a volume and start the container
-
-You can create the volume and start the container using the CLI or Docker Desktop's graphical interface.
-
-{{< tabs >}}
-{{< tab name="CLI" >}}
-
-1. Create a volume by using the `docker volume create` command.
-
-   ```console
-   $ docker volume create todo-db
-   ```
-
-2. Stop and remove the todo app container once again with `docker rm -f <id>`,
-   as it is still running without using the persistent volume.
-
-3. Start the todo app container, but add the `--mount` option to specify a
-   volume mount. Give the volume a name, and mount it to `/etc/todos` in the
-   container, which captures all files created at the path.
-
-   ```console
-   $ docker run -dp 127.0.0.1:3000:3000 --mount type=volume,src=todo-db,target=/etc/todos getting-started
-   ```
-
-   > [!NOTE]
-   >
-   > If you're using Git Bash, you must use different syntax for this command.
-   >
-   > ```console
-   > $ docker run -dp 127.0.0.1:3000:3000 --mount type=volume,src=todo-db,target=//etc/todos getting-started
-   > ```
-   >
-   > For more details about Git Bash's syntax differences, see
-   > [Working with Git Bash](/desktop/troubleshoot-and-support/troubleshoot/topics/#docker-commands-failing-in-git-bash).
-
-
-{{< /tab >}}
-{{< tab name="Docker Desktop" >}}
-
-To create a volume:
-
-1. Select **Volumes** in Docker Desktop.
-2. In **Volumes**, select **Create**.
-3. Specify `todo-db` as the volume name, and then select **Create**.
-
-To stop and remove the app container:
-
-1. Select **Containers** in Docker Desktop.
-2. Select **Delete** in the **Actions** column for the container.
-
-To start the todo app container with the volume mounted:
-
-1. Select the search box at the top of Docker Desktop.
-2. In the search window, select the **Images** tab.
-3. In the search box, specify the image name, `getting-started`.
-
-   > [!TIP]
-   >
-   >  Use the search filter to filter images and only show **Local images**.
-
-4. Select your image and then select **Run**.
-5. Select **Optional settings**.
-6. In **Host port**, specify the port, for example, `3000`.
-7. In **Host path**, specify the name of the volume, `todo-db`.
-8. In **Container path**, specify `/etc/todos`.
-9. Select **Run**.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Verify that the data persists
-
-1. Once the container starts up, open the app and add a few items to your todo list.
-
-    ![Items added to todo list](images/items-added.webp)
-    
-
-2. Stop and remove the container for the todo app. Use Docker Desktop or `docker ps` to get the ID and then `docker rm -f <id>` to remove it.
-
-3. Start a new container using the previous steps.
-
-4. Open the app. You should see your items still in your list.
-
-5. Go ahead and remove the container when you're done checking out your list.
-
-You've now learned how to persist data.
-
-## Dive into the volume
-
-A lot of people frequently ask "Where is Docker storing my data when I use a volume?" If you want to know, 
-you can use the `docker volume inspect` command.
-
-```console
-$ docker volume inspect todo-db
-```
-You should see output like the following:
-```console
-[
-    {
-        "CreatedAt": "2019-09-26T02:18:36Z",
-        "Driver": "local",
-        "Labels": {},
-        "Mountpoint": "/var/lib/docker/volumes/todo-db/_data",
-        "Name": "todo-db",
-        "Options": {},
-        "Scope": "local"
-    }
-]
-```
-
-The `Mountpoint` is the actual location of the data on the disk. Note that on most machines, you will
-need to have root access to access this directory from the host.
-
-## Summary
-
-In this section, you learned how to persist container data.
-
-Related information:
-
- - [docker CLI reference](/reference/cli/docker/)
- - [Volumes](/manuals/engine/storage/volumes.md)
-
-## Next steps
-
-Next, you'll learn how you can develop your app more efficiently using bind mounts.
-
-{{< button text="Use bind mounts" url="06_bind_mounts.md" >}}
diff --git a/content/get-started/workshop/06_bind_mounts.md b/content/get-started/workshop/06_bind_mounts.md
deleted file mode 100644
index 4bb41053f7e5..000000000000
--- a/content/get-started/workshop/06_bind_mounts.md
+++ /dev/null
@@ -1,451 +0,0 @@
----
-title: Use bind mounts
-weight: 60
-linkTitle: "Part 5: Use bind mounts"
-keywords: 'get started, setup, orientation, quickstart, intro, concepts, containers, docker desktop'
-description: Using bind mounts in our application
-aliases:
- - /guides/walkthroughs/access-local-folder/
- - /get-started/06_bind_mounts/
- - /guides/workshop/06_bind_mounts/
----
-
-In [part 4](./05_persisting_data.md), you used a volume mount to persist the
-data in your database. A volume mount is a great choice when you need somewhere
-persistent to store your application data.
-
-A bind mount is another type of mount, which lets you share a directory from the
-host's filesystem into the container. When working on an application, you can
-use a bind mount to mount source code into the container. The container sees the
-changes you make to the code immediately, as soon as you save a file. This means
-that you can run processes in the container that watch for filesystem changes
-and respond to them.
-
-In this chapter, you'll see how you can use bind mounts and a tool called
-[nodemon](https://npmjs.com/package/nodemon) to watch for file changes, and then restart the application
-automatically. There are equivalent tools in most other languages and
-frameworks.
-
-## Quick volume type comparisons
-
-The following are examples of a named volume and a bind mount using `--mount`:
-
-- Named volume: `type=volume,src=my-volume,target=/usr/local/data`
-- Bind mount: `type=bind,src=/path/to/data,target=/usr/local/data`
-
-The following table outlines the main differences between volume mounts and bind
-mounts.
-
-|                                              | Named volumes                                      | Bind mounts                                          |
-| -------------------------------------------- | -------------------------------------------------- | ---------------------------------------------------- |
-| Host location                                | Docker chooses                                     | You decide                                           |
-| Populates new volume with container contents | Yes                                                | No                                                   |
-| Supports Volume Drivers                      | Yes                                                | No                                                   |
-
-## Trying out bind mounts
-
-Before looking at how you can use bind mounts for developing your application,
-you can run a quick experiment to get a practical understanding of how bind mounts
-work.
-
-1. Verify that your `getting-started-app` directory is in a directory defined in
-Docker Desktop's file sharing setting. This setting defines which parts of your
-filesystem you can share with containers. For details about accessing the setting, see [File sharing](/manuals/desktop/settings-and-maintenance/settings.md#file-sharing).
-
-    > [!NOTE]
-    > The **File sharing** tab is only available in Hyper-V mode, because the files are automatically shared in WSL 2 mode and Windows container mode.
-
-2. Open a terminal and change directory to the `getting-started-app`
-   directory.
-
-3. Run the following command to start `bash` in an `ubuntu` container with a
-   bind mount.
-
-   {{< tabs >}}
-   {{< tab name="Mac / Linux" >}}
-
-   ```console
-   $ docker run -it --mount type=bind,src="$(pwd)",target=/src ubuntu bash
-   ```
-   
-   {{< /tab >}}
-   {{< tab name="Command Prompt" >}}
-
-   ```console
-   $ docker run -it --mount "type=bind,src=%cd%,target=/src" ubuntu bash
-   ```
-   
-   {{< /tab >}}
-   {{< tab name="Git Bash" >}}
-
-   ```console
-   $ docker run -it --mount type=bind,src="/$(pwd)",target=/src ubuntu bash
-   ```
-   
-   {{< /tab >}}
-   {{< tab name="PowerShell" >}}
-
-   ```console
-   $ docker run -it --mount "type=bind,src=$($pwd),target=/src" ubuntu bash
-   ```
-   
-   {{< /tab >}}
-   {{< /tabs >}}
-   
-   The `--mount type=bind` option tells Docker to create a bind mount, where `src` is the
-   current working directory on your host machine (`getting-started-app`), and
-   `target` is where that directory should appear inside the container (`/src`).
-
-4. After running the command, Docker starts an interactive `bash` session in the
-   root directory of the container's filesystem.
-
-   ```console
-   root@ac1237fad8db:/# pwd
-   /
-   root@ac1237fad8db:/# ls
-   bin   dev  home  media  opt   root  sbin  srv  tmp  var
-   boot  etc  lib   mnt    proc  run   src   sys  usr
-   ```
-
-5. Change directory to the `src` directory.
-
-   This is the directory that you mounted when starting the container. Listing
-   the contents of this directory displays the same files as in the
-   `getting-started-app` directory on your host machine.
-
-   ```console
-   root@ac1237fad8db:/# cd src
-   root@ac1237fad8db:/src# ls
-   Dockerfile  node_modules  package.json  spec  src  yarn.lock
-   ```
-
-6. Create a new file named `myfile.txt`.
-
-   ```console
-   root@ac1237fad8db:/src# touch myfile.txt
-   root@ac1237fad8db:/src# ls
-   Dockerfile  myfile.txt  node_modules  package.json  spec  src  yarn.lock
-   ```
-
-7. Open the `getting-started-app` directory on the host and observe that the
-   `myfile.txt` file is in the directory.
-
-   ```text
-   ├── getting-started-app/
-   │ ├── Dockerfile
-   │ ├── myfile.txt
-   │ ├── node_modules/
-   │ ├── package.json
-   │ ├── spec/
-   │ ├── src/
-   │ └── yarn.lock
-   ```
-
-8. From the host, delete the `myfile.txt` file.
-9. In the container, list the contents of the `app` directory once more. Observe that the file is now gone.
-
-   ```console
-   root@ac1237fad8db:/src# ls
-   Dockerfile  node_modules  package.json  spec  src  yarn.lock
-   ```
-
-10. Stop the interactive container session with `Ctrl` + `D`.
-
-That's all for a brief introduction to bind mounts. This procedure
-demonstrated how files are shared between the host and the container, and how
-changes are immediately reflected on both sides. Now you can use
-bind mounts to develop software.
-
-## Development containers
-
-Using bind mounts is common for local development setups. The advantage is that the development machine doesn’t need to have all of the build tools and environments installed. With a single docker run command, Docker pulls dependencies and tools.
-
-### Run your app in a development container
-
-The following steps describe how to run a development container with a bind
-mount that does the following:
-
-- Mount your source code into the container
-- Install all dependencies
-- Start `nodemon` to watch for filesystem changes
-
-You can use the CLI or Docker Desktop to run your container with a bind mount.
-
-{{< tabs >}}
-{{< tab name="Mac / Linux CLI" >}}
-
-1. Make sure you don't have any `getting-started` containers currently running.
-
-2. Run the following command from the `getting-started-app` directory.
-
-   ```console
-   $ docker run -dp 127.0.0.1:3000:3000 \
-       -w /app --mount type=bind,src="$(pwd)",target=/app \
-       node:18-alpine \
-       sh -c "yarn install && yarn run dev"
-   ```
-
-   The following is a breakdown of the command:
-   - `-dp 127.0.0.1:3000:3000` - same as before. Run in detached (background) mode and
-     create a port mapping
-   - `-w /app` - sets the "working directory" or the current directory that the
-     command will run from
-   - `--mount type=bind,src="$(pwd)",target=/app` - bind mount the current
-     directory from the host into the `/app` directory in the container
-   - `node:18-alpine` - the image to use. Note that this is the base image for
-     your app from the Dockerfile
-   - `sh -c "yarn install && yarn run dev"` - the command. You're starting a
-     shell using `sh` (alpine doesn't have `bash`) and running `yarn install` to
-     install packages and then running `yarn run dev` to start the development
-     server. If you look in the `package.json`, you'll see that the `dev` script
-     starts `nodemon`.
-
-3. You can watch the logs using `docker logs <container-id>`. You'll know you're
-   ready to go when you see this:
-
-   ```console
-   $ docker logs -f <container-id>
-   nodemon -L src/index.js
-   [nodemon] 2.0.20
-   [nodemon] to restart at any time, enter `rs`
-   [nodemon] watching path(s): *.*
-   [nodemon] watching extensions: js,mjs,json
-   [nodemon] starting `node src/index.js`
-   Using sqlite database at /etc/todos/todo.db
-   Listening on port 3000
-   ```
-
-   When you're done watching the logs, exit out by hitting `Ctrl`+`C`.
-
-{{< /tab >}}
-{{< tab name="PowerShell CLI" >}}
-
-1. Make sure you don't have any `getting-started` containers currently running.
-
-2. Run the following command from the `getting-started-app` directory.
-
-   ```powershell
-   $ docker run -dp 127.0.0.1:3000:3000 `
-       -w /app --mount "type=bind,src=$pwd,target=/app" `
-       node:18-alpine `
-       sh -c "yarn install && yarn run dev"
-   ```
-
-   The following is a breakdown of the command:
-   - `-dp 127.0.0.1:3000:3000` - same as before. Run in detached (background) mode and
-     create a port mapping
-   - `-w /app` - sets the "working directory" or the current directory that the
-     command will run from
-   - `--mount "type=bind,src=$pwd,target=/app"` - bind mount the current
-     directory from the host into the `/app` directory in the container
-   - `node:18-alpine` - the image to use. Note that this is the base image for
-     your app from the Dockerfile
-   - `sh -c "yarn install && yarn run dev"` - the command. You're starting a
-     shell using `sh` (alpine doesn't have `bash`) and running `yarn install` to
-     install packages and then running `yarn run dev` to start the development
-     server. If you look in the `package.json`, you'll see that the `dev` script
-     starts `nodemon`.
-
-3. You can watch the logs using `docker logs <container-id>`. You'll know you're
-   ready to go when you see this:
-
-   ```console
-   $ docker logs -f <container-id>
-   nodemon -L src/index.js
-   [nodemon] 2.0.20
-   [nodemon] to restart at any time, enter `rs`
-   [nodemon] watching path(s): *.*
-   [nodemon] watching extensions: js,mjs,json
-   [nodemon] starting `node src/index.js`
-   Using sqlite database at /etc/todos/todo.db
-   Listening on port 3000
-   ```
-
-   When you're done watching the logs, exit out by hitting `Ctrl`+`C`.
-
-{{< /tab >}}
-{{< tab name="Command Prompt CLI" >}}
-
-1. Make sure you don't have any `getting-started` containers currently running.
-
-2. Run the following command from the `getting-started-app` directory.
-
-   ```console
-   $ docker run -dp 127.0.0.1:3000:3000 ^
-       -w /app --mount "type=bind,src=%cd%,target=/app" ^
-       node:18-alpine ^
-       sh -c "yarn install && yarn run dev"
-   ```
-
-   The following is a breakdown of the command:
-   - `-dp 127.0.0.1:3000:3000` - same as before. Run in detached (background) mode and
-     create a port mapping
-   - `-w /app` - sets the "working directory" or the current directory that the
-     command will run from
-   - `--mount "type=bind,src=%cd%,target=/app"` - bind mount the current
-     directory from the host into the `/app` directory in the container
-   - `node:18-alpine` - the image to use. Note that this is the base image for
-     your app from the Dockerfile
-   - `sh -c "yarn install && yarn run dev"` - the command. You're starting a
-     shell using `sh` (alpine doesn't have `bash`) and running `yarn install` to
-     install packages and then running `yarn run dev` to start the development
-     server. If you look in the `package.json`, you'll see that the `dev` script
-     starts `nodemon`.
-
-3. You can watch the logs using `docker logs <container-id>`. You'll know you're
-   ready to go when you see this:
-
-   ```console
-   $ docker logs -f <container-id>
-   nodemon -L src/index.js
-   [nodemon] 2.0.20
-   [nodemon] to restart at any time, enter `rs`
-   [nodemon] watching path(s): *.*
-   [nodemon] watching extensions: js,mjs,json
-   [nodemon] starting `node src/index.js`
-   Using sqlite database at /etc/todos/todo.db
-   Listening on port 3000
-   ```
-
-   When you're done watching the logs, exit out by hitting `Ctrl`+`C`.
-
-{{< /tab >}}
-{{< tab name="Git Bash CLI" >}}
-
-1. Make sure you don't have any `getting-started` containers currently running.
-
-2. Run the following command from the `getting-started-app` directory.
-
-   ```console
-   $ docker run -dp 127.0.0.1:3000:3000 \
-       -w //app --mount type=bind,src="/$(pwd)",target=/app \
-       node:18-alpine \
-       sh -c "yarn install && yarn run dev"
-   ```
-
-   The following is a breakdown of the command:
-   - `-dp 127.0.0.1:3000:3000` - same as before. Run in detached (background) mode and
-     create a port mapping
-   - `-w //app` - sets the "working directory" or the current directory that the
-     command will run from
-   - `--mount type=bind,src="/$(pwd)",target=/app` - bind mount the current
-     directory from the host into the `/app` directory in the container
-   - `node:18-alpine` - the image to use. Note that this is the base image for
-     your app from the Dockerfile
-   - `sh -c "yarn install && yarn run dev"` - the command. You're starting a
-     shell using `sh` (alpine doesn't have `bash`) and running `yarn install` to
-     install packages and then running `yarn run dev` to start the development
-     server. If you look in the `package.json`, you'll see that the `dev` script
-     starts `nodemon`.
-
-3. You can watch the logs using `docker logs <container-id>`. You'll know you're
-   ready to go when you see this:
-
-   ```console
-   $ docker logs -f <container-id>
-   nodemon -L src/index.js
-   [nodemon] 2.0.20
-   [nodemon] to restart at any time, enter `rs`
-   [nodemon] watching path(s): *.*
-   [nodemon] watching extensions: js,mjs,json
-   [nodemon] starting `node src/index.js`
-   Using sqlite database at /etc/todos/todo.db
-   Listening on port 3000
-   ```
-
-   When you're done watching the logs, exit out by hitting `Ctrl`+`C`.
-
-{{< /tab >}}
-{{< tab name="Docker Desktop" >}}
-
-Make sure you don't have any `getting-started` containers currently running.
-
-Run the image with a bind mount.
-
-1. Select the search box at the top of Docker Desktop.
-2. In the search window, select the **Images** tab.
-3. In the search box, specify the container name, `getting-started`.
-
-   > [!TIP]
-   >
-   >  Use the search filter to filter images and only show **Local images**.
-
-4. Select your image and then select **Run**.
-5. Select **Optional settings**.
-6. In **Host path**, specify the path to the `getting-started-app` directory on your host machine.
-7. In **Container path**, specify `/app`.
-8. Select **Run**.
-
-You can watch the container logs using Docker Desktop.
-
-1. Select **Containers** in Docker Desktop.
-2. Select your container name.
-
-You'll know you're ready to go when you see this:
-
-```console
-nodemon -L src/index.js
-[nodemon] 2.0.20
-[nodemon] to restart at any time, enter `rs`
-[nodemon] watching path(s): *.*
-[nodemon] watching extensions: js,mjs,json
-[nodemon] starting `node src/index.js`
-Using sqlite database at /etc/todos/todo.db
-Listening on port 3000
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Develop your app with the development container
-
-Update your app on your host machine and see the changes reflected in the container.
-
-1. In the `src/static/js/app.js` file, on line
-   109, change the "Add Item" button to simply say "Add":
-
-   ```diff
-   - {submitting ? 'Adding...' : 'Add Item'}
-   + {submitting ? 'Adding...' : 'Add'}
-   ```
-
-   Save the file.
-
-2. Refresh the page in your web browser, and you should see the change reflected
-   almost immediately because of the bind mount. Nodemon detects the change and
-   restarts the server. It might take a few seconds for the Node server to
-   restart. If you get an error, try refreshing after a few seconds.
-
-   ![Screenshot of updated label for Add button](images/updated-add-button.webp)
-
-3. Feel free to make any other changes you'd like to make. Each time you make a
-   change and save a file, the change is reflected in the container because of
-   the bind mount. When Nodemon detects a change, it restarts the app inside the
-   container automatically. When you're done, stop the container and build your
-   new image using:
-
-   ```console
-   $ docker build -t getting-started .
-   ```
-
-## Summary
-
-At this point, you can persist your database and see changes in your app as you develop without rebuilding the image.
-
-In addition to volume mounts and bind mounts, Docker also supports other mount
-types and storage drivers for handling more complex and specialized use cases.
-
-Related information:
-
- - [docker CLI reference](/reference/cli/docker/)
- - [Manage data in Docker](https://docs.docker.com/storage/)
-
-## Next steps
-
-In order to prepare your app for production, you need to migrate your database
-from working in SQLite to something that can scale a little better. For
-simplicity, you'll keep using a relational database and switch your application
-to use MySQL. But, how should you run MySQL? How do you allow the containers to
-talk to each other? You'll learn about that in the next section.
-
-{{< button text="Multi container apps" url="07_multi_container.md" >}}
diff --git a/content/get-started/workshop/07_multi_container.md b/content/get-started/workshop/07_multi_container.md
deleted file mode 100644
index aab577adeb3a..000000000000
--- a/content/get-started/workshop/07_multi_container.md
+++ /dev/null
@@ -1,329 +0,0 @@
----
-title: Multi container apps
-weight: 70
-linkTitle: "Part 6: Multi-container apps"
-keywords: get started, setup, orientation, quickstart, intro, concepts, containers,
-  docker desktop
-description: Using more than one container in your application
-aliases:
- - /get-started/07_multi_container/
- - /guides/workshop/07_multi_container/
----
-
-Up to this point, you've been working with single container apps. But, now you will add MySQL to the
-application stack. The following question often arises - "Where will MySQL run? Install it in the same
-container or run it separately?" In general, each container should do one thing and do it well. The following are a few reasons to run the container separately:
-
-- There's a good chance you'd have to scale APIs and front-ends differently than databases.
-- Separate containers let you version and update versions in isolation.
-- While you may use a container for the database locally, you may want to use a managed service
-  for the database in production. You don't want to ship your database engine with your app then.
-- Running multiple processes will require a process manager (the container only starts one process), which adds complexity to container startup/shutdown.
-
-And there are more reasons. So, like the following diagram, it's best to run your app in multiple containers.
-
-![Todo App connected to MySQL container](images/multi-container.webp?w=350h=250)
-
-
-## Container networking
-
-Remember that containers, by default, run in isolation and don't know anything about other processes
-or containers on the same machine. So, how do you allow one container to talk to another? The answer is
-networking. If you place the two containers on the same network, they can talk to each other.
-
-## Start MySQL
-
-There are two ways to put a container on a network:
- - Assign the network when starting the container.
- - Connect an already running container to a network.
-
-In the following steps, you'll create the network first and then attach the MySQL container at startup.
-
-1. Create the network.
-
-   ```console
-   $ docker network create todo-app
-   ```
-
-2. Start a MySQL container and attach it to the network. You're also going to define a few environment variables that the
-   database will use to initialize the database. To learn more about the MySQL environment variables, see the "Environment Variables" section in the [MySQL Docker Hub listing](https://hub.docker.com/_/mysql/).
-
-   {{< tabs >}}
-   {{< tab name="Mac / Linux / Git Bash" >}}
-   
-   ```console
-   $ docker run -d \
-       --network todo-app --network-alias mysql \
-       -v todo-mysql-data:/var/lib/mysql \
-       -e MYSQL_ROOT_PASSWORD=secret \
-       -e MYSQL_DATABASE=todos \
-       mysql:8.0
-   ```
-
-   {{< /tab >}}
-   {{< tab name="PowerShell" >}}
-
-   ```powershell
-   $ docker run -d `
-       --network todo-app --network-alias mysql `
-       -v todo-mysql-data:/var/lib/mysql `
-       -e MYSQL_ROOT_PASSWORD=secret `
-       -e MYSQL_DATABASE=todos `
-       mysql:8.0
-   ```
-   
-   {{< /tab >}}
-   {{< tab name="Command Prompt" >}}
-
-   ```console
-   $ docker run -d ^
-       --network todo-app --network-alias mysql ^
-       -v todo-mysql-data:/var/lib/mysql ^
-       -e MYSQL_ROOT_PASSWORD=secret ^
-       -e MYSQL_DATABASE=todos ^
-       mysql:8.0
-   ```
-   
-   {{< /tab >}}
-   {{< /tabs >}}
-   
-   In the previous command, you can see the `--network-alias` flag. In a later section, you'll learn more about this flag.
-
-   > [!TIP]
-   >
-   > You'll notice a volume named `todo-mysql-data` in the above command that is mounted at `/var/lib/mysql`, which is where MySQL stores its data. However, you never ran a `docker volume create` command. Docker recognizes you want to use a named volume and creates one automatically for you.
-
-3. To confirm you have the database up and running, connect to the database and verify that it connects.
-
-   ```console
-   $ docker exec -it <mysql-container-id> mysql -u root -p
-   ```
-
-   When the password prompt comes up, type in `secret`. In the MySQL shell, list the databases and verify
-   you see the `todos` database.
-
-   ```console
-   mysql> SHOW DATABASES;
-   ```
-
-   You should see output that looks like this:
-
-   ```plaintext
-   +--------------------+
-   | Database           |
-   +--------------------+
-   | information_schema |
-   | mysql              |
-   | performance_schema |
-   | sys                |
-   | todos              |
-   +--------------------+
-   5 rows in set (0.00 sec)
-   ```
-
-4. Exit the MySQL shell to return to the shell on your machine.
-
-   ```console
-   mysql> exit
-   ```
-
-   You now have a `todos` database and it's ready for you to use.
-
-## Connect to MySQL
-
-Now that you know MySQL is up and running, you can use it. But, how do you use it? If you run
-another container on the same network, how do you find the container? Remember that each container has its own IP address.
-
-To answer the questions above and better understand container networking, you're going to make use of the [nicolaka/netshoot](https://github.com/nicolaka/netshoot) container,
-which ships with a lot of tools that are useful for troubleshooting or debugging networking issues.
-
-1. Start a new container using the nicolaka/netshoot image. Make sure to connect it to the same network.
-
-   ```console
-   $ docker run -it --network todo-app nicolaka/netshoot
-   ```
-
-2. Inside the container, you're going to use the `dig` command, which is a useful DNS tool. You're going to look up
-   the IP address for the hostname `mysql`.
-
-   ```console
-   $ dig mysql
-   ```
-
-   You should get output like the following.
-
-   ```text
-   ; <<>> DiG 9.18.8 <<>> mysql
-   ;; global options: +cmd
-   ;; Got answer:
-   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32162
-   ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
-
-   ;; QUESTION SECTION:
-   ;mysql.				IN	A
-
-   ;; ANSWER SECTION:
-   mysql.			600	IN	A	172.23.0.2
-
-   ;; Query time: 0 msec
-   ;; SERVER: 127.0.0.11#53(127.0.0.11)
-   ;; WHEN: Tue Oct 01 23:47:24 UTC 2019
-   ;; MSG SIZE  rcvd: 44
-   ```
-
-   In the "ANSWER SECTION", you will see an `A` record for `mysql` that resolves to `172.23.0.2`
-   (your IP address will most likely have a different value). While `mysql` isn't normally a valid hostname,
-   Docker was able to resolve it to the IP address of the container that had that network alias. Remember, you used the
-   `--network-alias` earlier.
-
-   What this means is that your app only simply needs to connect to a host named `mysql` and it'll talk to the
-   database.
-
-## Run your app with MySQL
-
-The todo app supports the setting of a few environment variables to specify MySQL connection settings. They are:
-
-- `MYSQL_HOST` - the hostname for the running MySQL server
-- `MYSQL_USER` - the username to use for the connection
-- `MYSQL_PASSWORD` - the password to use for the connection
-- `MYSQL_DB` - the database to use once connected
-
-> [!NOTE]
->
-> While using env vars to set connection settings is generally accepted for development, it's highly discouraged
-> when running applications in production. Diogo Monica, a former lead of security at Docker,
-> [wrote a fantastic blog post](https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/)
-> explaining why.
->
-> A more secure mechanism is to use the secret support provided by your container orchestration framework. In most cases,
-> these secrets are mounted as files in the running container. You'll see many apps (including the MySQL image and the todo app)
-> also support env vars with a `_FILE` suffix to point to a file containing the variable.
->
-> As an example, setting the `MYSQL_PASSWORD_FILE` var will cause the app to use the contents of the referenced file
-> as the connection password. Docker doesn't do anything to support these env vars. Your app will need to know to look for
-> the variable and get the file contents.
-
-You can now start your dev-ready container.
-
-1. Specify each of the previous environment variables, as well as connect the container to your app network. Make sure that you are in the `getting-started-app` directory when you run this command.
-
-   {{< tabs >}}
-   {{< tab name="Mac / Linux" >}}
-
-   ```console
-   $ docker run -dp 127.0.0.1:3000:3000 \
-     -w /app -v "$(pwd):/app" \
-     --network todo-app \
-     -e MYSQL_HOST=mysql \
-     -e MYSQL_USER=root \
-     -e MYSQL_PASSWORD=secret \
-     -e MYSQL_DB=todos \
-     node:18-alpine \
-     sh -c "yarn install && yarn run dev"
-   ```
-   
-   {{< /tab >}}
-   {{< tab name="PowerShell" >}}
-   In Windows, run this command in PowerShell.
-
-   ```powershell
-   $ docker run -dp 127.0.0.1:3000:3000 `
-     -w /app -v "$(pwd):/app" `
-     --network todo-app `
-     -e MYSQL_HOST=mysql `
-     -e MYSQL_USER=root `
-     -e MYSQL_PASSWORD=secret `
-     -e MYSQL_DB=todos `
-     node:18-alpine `
-     sh -c "yarn install && yarn run dev"
-   ```
-
-   {{< /tab >}}
-   {{< tab name="Command Prompt" >}}
-   In Windows, run this command in Command Prompt.
-
-   ```console
-   $ docker run -dp 127.0.0.1:3000:3000 ^
-     -w /app -v "%cd%:/app" ^
-     --network todo-app ^
-     -e MYSQL_HOST=mysql ^
-     -e MYSQL_USER=root ^
-     -e MYSQL_PASSWORD=secret ^
-     -e MYSQL_DB=todos ^
-     node:18-alpine ^
-     sh -c "yarn install && yarn run dev"
-   ```
-
-   {{< /tab >}}
-   {{< tab name="Git Bash" >}}
-
-   ```console
-   $ docker run -dp 127.0.0.1:3000:3000 \
-     -w //app -v "/$(pwd):/app" \
-     --network todo-app \
-     -e MYSQL_HOST=mysql \
-     -e MYSQL_USER=root \
-     -e MYSQL_PASSWORD=secret \
-     -e MYSQL_DB=todos \
-     node:18-alpine \
-     sh -c "yarn install && yarn run dev"
-   ```
-   
-   {{< /tab >}}
-   {{< /tabs >}}
-
-2. If you look at the logs for the container (`docker logs -f <container-id>`), you should see a message similar to the following, which indicates it's
-   using the mysql database.
-
-   ```console
-   $ nodemon src/index.js
-   [nodemon] 2.0.20
-   [nodemon] to restart at any time, enter `rs`
-   [nodemon] watching dir(s): *.*
-   [nodemon] starting `node src/index.js`
-   Connected to mysql db at host mysql
-   Listening on port 3000
-   ```
-
-3. Open the app in your browser and add a few items to your todo list.
-
-4. Connect to the mysql database and prove that the items are being written to the database. Remember, the password
-   is `secret`.
-
-   ```console
-   $ docker exec -it <mysql-container-id> mysql -p todos
-   ```
-
-   And in the mysql shell, run the following:
-
-   ```console
-   mysql> select * from todo_items;
-   +--------------------------------------+--------------------+-----------+
-   | id                                   | name               | completed |
-   +--------------------------------------+--------------------+-----------+
-   | c906ff08-60e6-44e6-8f49-ed56a0853e85 | Do amazing things! |         0 |
-   | 2912a79e-8486-4bc3-a4c5-460793a575ab | Be awesome!        |         0 |
-   +--------------------------------------+--------------------+-----------+
-   ```
-
-   Your table will look different because it has your items. But, you should see them stored there.
-
-## Summary
-
-At this point, you have an application that now stores its data in an external database running in a separate
-container. You learned a little bit about container networking and service discovery using DNS.
-
-Related information:
- - [docker CLI reference](/reference/cli/docker/)
- - [Networking overview](/manuals/engine/network/_index.md)
-
-## Next steps
-
-There's a good chance you are starting to feel a little overwhelmed with everything you need to do to start up
-this application. You have to create a network, start containers, specify all of the environment variables, expose
-ports, and more. That's a lot to remember and it's certainly making things harder to pass along to someone else.
-
-In the next section, you'll learn about Docker Compose. With Docker Compose, you can share your application stacks in a
-much easier way and let others spin them up with a single, simple command.
-
-{{< button text="Use Docker Compose" url="08_using_compose.md" >}}
diff --git a/content/get-started/workshop/08_using_compose.md b/content/get-started/workshop/08_using_compose.md
deleted file mode 100644
index c23e76a7cb19..000000000000
--- a/content/get-started/workshop/08_using_compose.md
+++ /dev/null
@@ -1,292 +0,0 @@
----
-title: Use Docker Compose
-weight: 80
-linkTitle: "Part 7: Use Docker Compose"
-keywords: get started, setup, orientation, quickstart, intro, concepts, containers,
-  docker desktop
-description: Using Docker Compose for multi-container applications
-aliases:
- - /get-started/08_using_compose/
- - /guides/workshop/08_using_compose/
----
-
-[Docker Compose](/manuals/compose/_index.md) is a tool that helps you define and
-share multi-container applications. With Compose, you can create a YAML file to define the services
-and with a single command, you can spin everything up or tear it all down.
-
-The big advantage of using Compose is you can define your application stack in a file, keep it at the root of
-your project repository (it's now version controlled), and easily enable someone else to contribute to your project.
-Someone would only need to clone your repository and start the app using Compose. In fact, you might see quite a few projects
-on GitHub/GitLab doing exactly this now.
-
-## Create the Compose file
-
-In the `getting-started-app` directory, create a file named `compose.yaml`.
-
-```text
-├── getting-started-app/
-│ ├── Dockerfile
-│ ├── compose.yaml
-│ ├── node_modules/
-│ ├── package.json
-│ ├── spec/
-│ ├── src/
-│ └── yarn.lock
-```
-
-## Define the app service
-
-In [part 6](./07_multi_container.md), you used the following command to start the application service.
-
-```console
-$ docker run -dp 127.0.0.1:3000:3000 \
-  -w /app -v "$(pwd):/app" \
-  --network todo-app \
-  -e MYSQL_HOST=mysql \
-  -e MYSQL_USER=root \
-  -e MYSQL_PASSWORD=secret \
-  -e MYSQL_DB=todos \
-  node:18-alpine \
-  sh -c "yarn install && yarn run dev"
-```
-
-You'll now define this service in the `compose.yaml` file.
-
-1. Open `compose.yaml` in a text or code editor, and start by defining the name and image of the first service (or container) you want to run as part of your application.
-   The name will automatically become a network alias, which will be useful when defining your MySQL service.
-
-   ```yaml
-   services:
-     app:
-       image: node:18-alpine
-   ```
-
-2. Typically, you will see `command` close to the `image` definition, although there is no requirement on ordering. Add the `command` to your `compose.yaml` file.
-
-   ```yaml
-   services:
-     app:
-       image: node:18-alpine
-       command: sh -c "yarn install && yarn run dev"
-   ```
-
-3. Now migrate the `-p 127.0.0.1:3000:3000` part of the command by defining the `ports` for the service.
-
-   ```yaml
-   services:
-     app:
-       image: node:18-alpine
-       command: sh -c "yarn install && yarn run dev"
-       ports:
-         - 127.0.0.1:3000:3000
-   ```
-
-4. Next, migrate both the working directory (`-w /app`) and the volume mapping
-   (`-v "$(pwd):/app"`) by using the `working_dir` and `volumes` definitions.
-
-    One advantage of Docker Compose volume definitions is you can use relative paths from the current directory.
-
-   ```yaml
-   services:
-     app:
-       image: node:18-alpine
-       command: sh -c "yarn install && yarn run dev"
-       ports:
-         - 127.0.0.1:3000:3000
-       working_dir: /app
-       volumes:
-         - ./:/app
-   ```
-
-5. Finally, you need to migrate the environment variable definitions using the `environment` key.
-
-   ```yaml
-   services:
-     app:
-       image: node:18-alpine
-       command: sh -c "yarn install && yarn run dev"
-       ports:
-         - 127.0.0.1:3000:3000
-       working_dir: /app
-       volumes:
-         - ./:/app
-       environment:
-         MYSQL_HOST: mysql
-         MYSQL_USER: root
-         MYSQL_PASSWORD: secret
-         MYSQL_DB: todos
-   ```
-
-### Define the MySQL service
-
-Now, it's time to define the MySQL service. The command that you used for that container was the following:
-
-```console
-$ docker run -d \
-  --network todo-app --network-alias mysql \
-  -v todo-mysql-data:/var/lib/mysql \
-  -e MYSQL_ROOT_PASSWORD=secret \
-  -e MYSQL_DATABASE=todos \
-  mysql:8.0
-```
-
-1. First define the new service and name it `mysql` so it automatically gets the network alias. Also specify the image to use as well.
-
-   ```yaml
-
-   services:
-     app:
-       # The app service definition
-     mysql:
-       image: mysql:8.0
-   ```
-
-2. Next, define the volume mapping. When you ran the container with `docker
-   run`, Docker created the named volume automatically. However, that doesn't
-   happen when running with Compose. You need to define the volume in the
-   top-level `volumes:` section and then specify the mountpoint in the service
-   config. By simply providing only the volume name, the default options are
-   used.
-
-   ```yaml
-   services:
-     app:
-       # The app service definition
-     mysql:
-       image: mysql:8.0
-       volumes:
-         - todo-mysql-data:/var/lib/mysql
-
-   volumes:
-     todo-mysql-data:
-   ```
-
-3. Finally, you need to specify the environment variables.
-
-   ```yaml
-   services:
-     app:
-       # The app service definition
-     mysql:
-       image: mysql:8.0
-       volumes:
-         - todo-mysql-data:/var/lib/mysql
-       environment:
-         MYSQL_ROOT_PASSWORD: secret
-         MYSQL_DATABASE: todos
-
-   volumes:
-     todo-mysql-data:
-   ```
-
-At this point, your complete `compose.yaml` should look like this:
-
-
-```yaml
-services:
-  app:
-    image: node:18-alpine
-    command: sh -c "yarn install && yarn run dev"
-    ports:
-      - 127.0.0.1:3000:3000
-    working_dir: /app
-    volumes:
-      - ./:/app
-    environment:
-      MYSQL_HOST: mysql
-      MYSQL_USER: root
-      MYSQL_PASSWORD: secret
-      MYSQL_DB: todos
-
-  mysql:
-    image: mysql:8.0
-    volumes:
-      - todo-mysql-data:/var/lib/mysql
-    environment:
-      MYSQL_ROOT_PASSWORD: secret
-      MYSQL_DATABASE: todos
-
-volumes:
-  todo-mysql-data:
-```
-
-## Run the application stack
-
-Now that you have your `compose.yaml` file, you can start your application.
-
-1. Make sure no other copies of the containers are running first. Use `docker ps` to list the containers and `docker rm -f <ids>` to remove them.
-
-2. Start up the application stack using the `docker compose up` command. Add the
-   `-d` flag to run everything in the background.
-
-   ```console
-   $ docker compose up -d
-   ```
-
-    When you run the previous command, you should see output like the following:
-
-   ```plaintext
-   Creating network "app_default" with the default driver
-   Creating volume "app_todo-mysql-data" with default driver
-   Creating app_app_1   ... done
-   Creating app_mysql_1 ... done
-   ```
-
-    You'll notice that Docker Compose created the volume as well as a network. By default, Docker Compose automatically creates a network specifically for the application stack (which is why you didn't define one in the Compose file).
-
-3. Look at the logs using the `docker compose logs -f` command. You'll see the logs from each of the services interleaved
-    into a single stream. This is incredibly useful when you want to watch for timing-related issues. The `-f` flag follows the
-    log, so will give you live output as it's generated.
-
-    If you have run the command already, you'll see output that looks like this:
-
-    ```plaintext
-    mysql_1  | 2019-10-03T03:07:16.083639Z 0 [Note] mysqld: ready for connections.
-    mysql_1  | Version: '8.0.31'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
-    app_1    | Connected to mysql db at host mysql
-    app_1    | Listening on port 3000
-    ```
-
-    The service name is displayed at the beginning of the line (often colored) to help distinguish messages. If you want to
-    view the logs for a specific service, you can add the service name to the end of the logs command (for example,
-    `docker compose logs -f app`).
-
-4. At this point, you should be able to open your app in your browser on [http://localhost:3000](http://localhost:3000) and see it running.
-
-## See the app stack in Docker Desktop Dashboard
-
-If you look at the Docker Desktop Dashboard, you'll see that there is a group named **getting-started-app**. This is the project name from Docker
-Compose and used to group the containers together. By default, the project name is simply the name of the directory that the
-`compose.yaml` was located in.
-
-If you expand the stack, you'll see the two containers you defined in the Compose file. The names are also a little
-more descriptive, as they follow the pattern of `<service-name>-<replica-number>`. So, it's very easy to
-quickly see what container is your app and which container is the mysql database.
-
-## Tear it all down
-
-When you're ready to tear it all down, simply run `docker compose down` or hit the trash can on the Docker Desktop Dashboard
-for the entire app. The containers will stop and the network will be removed.
-
-> [!WARNING]
->
-> By default, named volumes in your compose file are not removed when you run `docker compose down`. If you want to
->remove the volumes, you need to add the `--volumes` flag.
->
-> The Docker Desktop Dashboard does not remove volumes when you delete the app stack.
-
-## Summary
-
-In this section, you learned about Docker Compose and how it helps you simplify
-the way you define and share multi-service applications.
-
-Related information:
- - [Compose overview](/manuals/compose/_index.md)
- - [Compose file reference](/reference/compose-file/_index.md)
- - [Compose CLI reference](/reference/cli/docker/compose/_index.md)
-
-## Next steps
-
-Next, you'll learn about a few best practices you can use to improve your Dockerfile.
-
-{{< button text="Image-building best practices" url="09_image_best.md" >}}
diff --git a/content/get-started/workshop/09_image_best.md b/content/get-started/workshop/09_image_best.md
deleted file mode 100644
index a84842d75f12..000000000000
--- a/content/get-started/workshop/09_image_best.md
+++ /dev/null
@@ -1,212 +0,0 @@
----
-title: Image-building best practices
-weight: 90
-linkTitle: "Part 8: Image-building best practices"
-keywords: get started, setup, orientation, quickstart, intro, concepts, containers,
-  docker desktop
-description: Tips for building images for your application
-aliases:
- - /get-started/09_image_best/
- - /guides/workshop/09_image_best/
----
-
-## Image layering
-
-Using the `docker image history` command, you can see the command that was used
-to create each layer within an image.
-
-1. Use the `docker image history` command to see the layers in the `getting-started` image you
-   created.
-
-    ```console
-    $ docker image history getting-started
-    ```
-
-    You should get output that looks something like the following.
-
-    ```plaintext
-    IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
-    a78a40cbf866        18 seconds ago      /bin/sh -c #(nop)  CMD ["node" "src/index.j…    0B                  
-    f1d1808565d6        19 seconds ago      /bin/sh -c yarn install --production            85.4MB              
-    a2c054d14948        36 seconds ago      /bin/sh -c #(nop) COPY dir:5dc710ad87c789593…   198kB               
-    9577ae713121        37 seconds ago      /bin/sh -c #(nop) WORKDIR /app                  0B                  
-    b95baba1cfdb        13 days ago         /bin/sh -c #(nop)  CMD ["node"]                 0B                  
-    <missing>           13 days ago         /bin/sh -c #(nop)  ENTRYPOINT ["docker-entry…   0B                  
-    <missing>           13 days ago         /bin/sh -c #(nop) COPY file:238737301d473041…   116B                
-    <missing>           13 days ago         /bin/sh -c apk add --no-cache --virtual .bui…   5.35MB              
-    <missing>           13 days ago         /bin/sh -c #(nop)  ENV YARN_VERSION=1.21.1      0B                  
-    <missing>           13 days ago         /bin/sh -c addgroup -g 1000 node     && addu…   74.3MB              
-    <missing>           13 days ago         /bin/sh -c #(nop)  ENV NODE_VERSION=12.14.1     0B                  
-    <missing>           13 days ago         /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B                  
-    <missing>           13 days ago         /bin/sh -c #(nop) ADD file:e69d441d729412d24…   5.59MB   
-    ```
-
-    Each of the lines represents a layer in the image. The display here shows the base at the bottom with
-    the newest layer at the top. Using this, you can also quickly see the size of each layer, helping 
-    diagnose large images.
-
-2. You'll notice that several of the lines are truncated. If you add the `--no-trunc` flag, you'll get the
-   full output.
-
-    ```console
-    $ docker image history --no-trunc getting-started
-    ```
-
-## Layer caching
-
-Now that you've seen the layering in action, there's an important lesson to learn to help decrease build
-times for your container images. Once a layer changes, all downstream layers have to be recreated as well.
-
-Look at the following Dockerfile you created for the getting started app.
-
-```dockerfile
-# syntax=docker/dockerfile:1
-FROM node:lts-alpine
-WORKDIR /app
-COPY . .
-RUN yarn install --production
-CMD ["node", "src/index.js"]
-```
-
-Going back to the image history output, you see that each command in the Dockerfile becomes a new layer in the image.
-You might remember that when you made a change to the image, the yarn dependencies had to be reinstalled. It doesn't make much sense to ship around the same dependencies every time you build.
-
-To fix it, you need to restructure your Dockerfile to help support the caching
-of the dependencies. For Node-based applications, those dependencies are defined
-in the `package.json` file. You can copy only that file in first, install the
-dependencies, and then copy in everything else. Then, you only recreate the yarn
-dependencies if there was a change to the `package.json`.
-
-1. Update the Dockerfile to copy in the `package.json` first, install dependencies, and then copy everything else in.
-
-   ```dockerfile
-   # syntax=docker/dockerfile:1
-   FROM node:lts-alpine
-   WORKDIR /app
-   COPY package.json yarn.lock ./
-   RUN yarn install --production
-   COPY . .
-   CMD ["node", "src/index.js"]
-   ```
-
-2. Build a new image using `docker build`.
-
-    ```console
-    $ docker build -t getting-started .
-    ```
-
-    You should see output like the following.
-
-    ```plaintext
-    [+] Building 16.1s (10/10) FINISHED
-    => [internal] load build definition from Dockerfile
-    => => transferring dockerfile: 175B
-    => [internal] load .dockerignore
-    => => transferring context: 2B
-    => [internal] load metadata for docker.io/library/node:lts-alpine
-    => [internal] load build context
-    => => transferring context: 53.37MB
-    => [1/5] FROM docker.io/library/node:lts-alpine
-    => CACHED [2/5] WORKDIR /app
-    => [3/5] COPY package.json yarn.lock ./
-    => [4/5] RUN yarn install --production
-    => [5/5] COPY . .
-    => exporting to image
-    => => exporting layers
-    => => writing image     sha256:d6f819013566c54c50124ed94d5e66c452325327217f4f04399b45f94e37d25
-    => => naming to docker.io/library/getting-started
-    ```
-
-3. Now, make a change to the `src/static/index.html` file. For example, change the `<title>` to "The Awesome Todo App".
-
-4. Build the Docker image now using `docker build -t getting-started .` again. This time, your output should look a little different.
-
-    ```plaintext
-    [+] Building 1.2s (10/10) FINISHED
-    => [internal] load build definition from Dockerfile
-    => => transferring dockerfile: 37B
-    => [internal] load .dockerignore
-    => => transferring context: 2B
-    => [internal] load metadata for docker.io/library/node:lts-alpine
-    => [internal] load build context
-    => => transferring context: 450.43kB
-    => [1/5] FROM docker.io/library/node:lts-alpine
-    => CACHED [2/5] WORKDIR /app
-    => CACHED [3/5] COPY package.json yarn.lock ./
-    => CACHED [4/5] RUN yarn install --production
-    => [5/5] COPY . .
-    => exporting to image
-    => => exporting layers
-    => => writing image     sha256:91790c87bcb096a83c2bd4eb512bc8b134c757cda0bdee4038187f98148e2eda
-    => => naming to docker.io/library/getting-started
-    ```
-
-    First off, you should notice that the build was much faster. And, you'll see
-    that several steps are using previously cached layers. Pushing and pulling
-    this image and updates to it will be much faster as well. 
-
-## Multi-stage builds
-
-Multi-stage builds are an incredibly powerful
-tool to help use multiple stages to create an image. There are several advantages for them:
-
-- Separate build-time dependencies from runtime dependencies
-- Reduce overall image size by shipping only what your app needs to run
-
-### Maven/Tomcat example
-
-When building Java-based applications, you need a JDK to compile the source code to Java bytecode. However,
-that JDK isn't needed in production. Also, you might be using tools like Maven or Gradle to help build the app.
-Those also aren't needed in your final image. Multi-stage builds help.
-
-```dockerfile
-# syntax=docker/dockerfile:1
-FROM maven AS build
-WORKDIR /app
-COPY . .
-RUN mvn package
-
-FROM tomcat
-COPY --from=build /app/target/file.war /usr/local/tomcat/webapps 
-```
-
-In this example, you use one stage (called `build`) to perform the actual Java build using Maven. In the second
-stage (starting at `FROM tomcat`), you copy in files from the `build` stage. The final image is only the last stage
-being created, which can be overridden using the `--target` flag.
-
-### React example
-
-When building React applications, you need a Node environment to compile the JS code (typically JSX), SASS stylesheets,
-and more into static HTML, JS, and CSS. If you aren't doing server-side rendering, you don't even need a Node environment
-for your production build. You can ship the static resources in a static nginx container.
-
-```dockerfile
-# syntax=docker/dockerfile:1
-FROM node:lts AS build
-WORKDIR /app
-COPY package* yarn.lock ./
-RUN yarn install
-COPY public ./public
-COPY src ./src
-RUN yarn run build
-
-FROM nginx:alpine
-COPY --from=build /app/build /usr/share/nginx/html
-```
-
-In the previous Dockerfile example, it uses the `node:lts` image to perform the build (maximizing layer caching) and then copies the output
-into an nginx container.
-
-## Summary
-
-In this section, you learned a few image building best practices, including layer caching and multi-stage builds.
-
-Related information:
- - [Dockerfile reference](/reference/dockerfile/)
- - [Dockerfile best practices](/manuals/build/building/best-practices.md)
-
-## Next steps
-
-In the next section, you'll learn about additional resources you can use to continue learning about containers.
-
-{{< button text="What next" url="10_what_next.md" >}}
diff --git a/content/get-started/workshop/10_what_next.md b/content/get-started/workshop/10_what_next.md
deleted file mode 100644
index 35ea9ea80e75..000000000000
--- a/content/get-started/workshop/10_what_next.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: What next after the Docker workshop
-weight: 100
-linkTitle: "Part 9: What next"
-keywords: get started, setup, orientation, quickstart, intro, concepts, containers,
-  docker desktop
-description: Making sure you have more ideas of what you could do next with your application
-aliases:
- - /get-started/11_what_next/
- - /guides/workshop/10_what_next/
----
-
-Although you're done with the workshop, there's still a lot more to learn about containers.
-
-Here are a few other areas to look at next.
-
-## Container orchestration
-
-Running containers in production is tough. You don't want to log into a machine and simply run a
-`docker run` or `docker compose up`. Why not? Well, what happens if the containers die? How do you
-scale across several machines? Container orchestration solves this problem. Tools like Kubernetes,
-Swarm, Nomad, and ECS all help solve this problem, all in slightly different ways.
-
-The general idea is that you have managers who receive the expected state. This state might be
-"I want to run two instances of my web app and expose port 80." The managers then look at all of the
-machines in the cluster and delegate work to worker nodes. The managers watch for changes (such as
-a container quitting) and then work to make the actual state reflect the expected state.
-
-## Cloud Native Computing Foundation projects
-
-The CNCF is a vendor-neutral home for various open-source projects, including Kubernetes, Prometheus, 
-Envoy, Linkerd, NATS, and more. You can view the [graduated and incubated projects here](https://www.cncf.io/projects/)
-and the entire [CNCF Landscape here](https://landscape.cncf.io/). There are a lot of projects to help
-solve problems around monitoring, logging, security, image registries, messaging, and more.
-
-## Getting started video workshop
-
-Docker recommends watching the video workshop from DockerCon 2022. Watch the entire video or use the following links to open the video at a particular section.
-
-* [Docker overview and installation](https://youtu.be/gAGEar5HQoU)
-* [Pull, run, and explore containers](https://youtu.be/gAGEar5HQoU?t=1400)
-* [Build a container image](https://youtu.be/gAGEar5HQoU?t=3185)
-* [Containerize an app](https://youtu.be/gAGEar5HQoU?t=4683)
-* [Connect a DB and set up a bind mount](https://youtu.be/gAGEar5HQoU?t=6305)
-* [Deploy a container to the cloud](https://youtu.be/gAGEar5HQoU?t=8280)
-
-<iframe src="https://www.youtube-nocookie.com/embed/gAGEar5HQoU" style="max-width: 100%; aspect-ratio: 16 / 9;" width="560" height="auto" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
-
-## Creating a container from scratch
-
-If you'd like to see how containers are built from scratch, Liz Rice from Aqua Security has a fantastic talk in which she creates a container from scratch in Go. While the talk does not go into networking, using images for the filesystem, and other advanced topics, it gives a deep dive into how things are working.
-
-<iframe src="https://www.youtube-nocookie.com/embed/8fi7uSYlOdc" style="max-width: 100%; aspect-ratio: 16 / 9;" width="560" height="auto" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
diff --git a/content/get-started/workshop/_index.md b/content/get-started/workshop/_index.md
deleted file mode 100644
index cc6a0beff925..000000000000
--- a/content/get-started/workshop/_index.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-title: Overview of the Docker workshop
-linkTitle: Docker workshop
-keywords: docker basics, how to start a docker container, container settings, setup
-  docker, how to setup docker, setting up docker, docker container guide, how to get
-  started with docker
-description: Get started with the Docker basics in this workshop, You'll
-  learn about containers, images, and how to containerize your first application.
-aliases:
-- /guides/get-started/
-- /get-started/hands-on-overview/
-- /guides/workshop/
----
-
-This 45-minute workshop contains step-by-step instructions on how to get started with Docker. This workshop shows you how to:
-
-- Build and run an image as a container.
-- Share images using Docker Hub.
-- Deploy Docker applications using multiple containers with a database.
-- Run applications using Docker Compose.
-
-> [!NOTE]
->
-> For a quick introduction to Docker and the benefits of containerizing your
-> applications, see [Getting started](/get-started/introduction/_index.md).
-
-## What is a container?
-
-A container is a sandboxed process running on a host machine that is isolated from all other processes running on that host machine. That isolation leverages [kernel namespaces and cgroups](https://medium.com/@saschagrunert/demystifying-containers-part-i-kernel-space-2c53d6979504),
-features that have been in Linux for a long time. Docker makes these capabilities approachable and easy to use. To summarize, a container:
-
-- Is a runnable instance of an image. You can create, start, stop, move, or delete a container using the Docker API or CLI.
-- Can be run on local machines, virtual machines, or deployed to the cloud.
-- Is portable (and can be run on any OS).
-- Is isolated from other containers and runs its own software, binaries, configurations, etc.
-
-If you're familiar with `chroot`, then think of a container as an extended version of `chroot`. The filesystem comes from the image. However, a container adds additional isolation not available when using chroot.
-
-## What is an image?
-
-A running container uses an isolated filesystem. This isolated filesystem is provided by an image, and the image must contain everything needed to run an application - all dependencies, configurations, scripts, binaries, etc. The image also contains other configurations for the container, such as environment variables, a default command to run, and other metadata.
-
-## Next steps
-
-In this section, you learned about containers and images.
-
-Next, you'll containerize a simple application and get hands-on with the concepts.
-
-{{< button text="Containerize an application" url="02_our_app.md" >}}
diff --git a/content/get-started/workshop/images/dashboard-two-containers.webp b/content/get-started/workshop/images/dashboard-two-containers.webp
deleted file mode 100644
index 5e657ca56dad..000000000000
Binary files a/content/get-started/workshop/images/dashboard-two-containers.webp and /dev/null differ
diff --git a/content/get-started/workshop/images/items-added.webp b/content/get-started/workshop/images/items-added.webp
deleted file mode 100644
index 10c0d347b4ea..000000000000
Binary files a/content/get-started/workshop/images/items-added.webp and /dev/null differ
diff --git a/content/get-started/workshop/images/multi-container.webp b/content/get-started/workshop/images/multi-container.webp
deleted file mode 100644
index e8b5b9ea776f..000000000000
Binary files a/content/get-started/workshop/images/multi-container.webp and /dev/null differ
diff --git a/content/get-started/workshop/images/push-command.webp b/content/get-started/workshop/images/push-command.webp
deleted file mode 100644
index 0d2b25a25ba8..000000000000
Binary files a/content/get-started/workshop/images/push-command.webp and /dev/null differ
diff --git a/content/get-started/workshop/images/pwd-add-new-instance.webp b/content/get-started/workshop/images/pwd-add-new-instance.webp
deleted file mode 100644
index cfb827ead2b2..000000000000
Binary files a/content/get-started/workshop/images/pwd-add-new-instance.webp and /dev/null differ
diff --git a/content/get-started/workshop/images/todo-list-empty.webp b/content/get-started/workshop/images/todo-list-empty.webp
deleted file mode 100644
index c4956bc64e32..000000000000
Binary files a/content/get-started/workshop/images/todo-list-empty.webp and /dev/null differ
diff --git a/content/get-started/workshop/images/updated-add-button.webp b/content/get-started/workshop/images/updated-add-button.webp
deleted file mode 100644
index 9003a52a8c66..000000000000
Binary files a/content/get-started/workshop/images/updated-add-button.webp and /dev/null differ
diff --git a/content/guides/_index.md b/content/guides/_index.md
index 1aed59cd077d..9c4a04caaf0d 100644
--- a/content/guides/_index.md
+++ b/content/guides/_index.md
@@ -1,20 +1,25 @@
 ---
 title: Docker guides
 linkTitle: Guides
-description: Explore the Docker guides
+description: Step-by-step tutorials, organized by what you're trying to do.
+keywords: docker, guides, tutorials, learning paths, getting started
 params:
-  icon: developer_guide
+  icon: book-open
 layout: landing
 aliases:
   - /guides/language/
   - /language/
+  - /guides/dhi-from-doi/
+  - /guides/dhi-from-wolfi/
+  - /guides/dhi-go-example/
+  - /guides/dhi-nodejs-example/
+  - /guides/dhi-python-example/
+  - /guides/lab-docker-for-ai-redirect/
   - /learning-paths/
 ---
 
-Explore our collection of guides to learn how Docker can optimize your
-development workflows and how to use it with specific languages, frameworks, or
-technologies.
+Explore guides to learn how Docker can optimize your development workflows and
+how to use it with specific languages, frameworks, or technologies.
 
 Can't find the guide you're looking for? Open an issue on the
-[docker/docs](https://github.com/docker/docs/issues/new) repository to let us
-know.
+[docker/docs](https://github.com/docker/docs/issues/new) repository.
diff --git a/content/guides/admin-set-up.md b/content/guides/admin-set-up.md
new file mode 100644
index 000000000000..4978217bb01c
--- /dev/null
+++ b/content/guides/admin-set-up.md
@@ -0,0 +1,330 @@
+---
+title: Set up your company for success with Docker
+linkTitle: Admin set up
+summary: Get the most out of Docker by streamlining workflows, standardizing development environments, and ensuring smooth deployments across your company.
+description: Learn how to onboard your company and take advantage of all of the Docker products and features.
+keywords: admin, onboarding, deployment, organization setup, docker business, rollout
+aliases:
+  - /guides/admin-set-up/comms-and-info-gathering/
+  - /guides/admin-set-up/deploy/
+  - /guides/admin-set-up/finalize-plans-and-setup/
+  - /guides/admin-set-up/testing/
+params:
+  tags: [admin]
+  time: 20 minutes
+  image:
+---
+
+
+Docker's tools provide a scalable, secure platform that empowers your
+developers to create, ship, and run applications faster. As an administrator,
+you can streamline workflows, standardize development environments, and ensure
+smooth deployments across your organization.
+
+By configuring Docker products to suit your company's needs, you can optimize
+performance, simplify user management, and maintain control over resources.
+This guide helps you set up and configure Docker products to maximize
+productivity and success for your team while meeting compliance and security
+policies.
+
+## Who’s this for?
+
+- Administrators responsible for managing Docker environments within their
+  organization
+- IT leaders looking to streamline development and deployment workflows
+- Teams aiming to standardize application environments across multiple users
+- Organizations seeking to optimize their use of Docker products for greater
+  scalability and efficiency
+- Organizations with a
+  [Docker Business subscription](https://www.docker.com/pricing?ref=DocsGuides&refAction=DocsGuidesCTAClicked)
+
+## What you’ll learn
+
+- Why signing into your company's Docker organization provides access to usage
+  data and enhanced functionality
+- How to standardize Docker Desktop versions and settings to create a consistent
+  baseline for all users, while allowing flexibility for advanced developers
+- Strategies for implementing Docker's security configurations to meet company
+  IT and software development security requirements without hindering developer productivity
+
+## Features covered
+
+This guide covers the following Docker features:
+
+- [Organizations](/manuals/admin/organization/_index.md): The core structure
+  for managing your Docker environment, grouping users, teams, and image
+  repositories. Your organization was created with your subscription and is
+  managed by one or more owners. Users signed into the organization are
+  assigned seats based on the purchased subscription.
+- [Enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md):
+  By default, Docker Desktop doesn't require sign-in. You can configure
+  settings to enforce this and ensure your developers sign in to your
+  Docker organization.
+- [SSO](/manuals/enterprise/security/single-sign-on/_index.md): Without SSO,
+  user management in a Docker organization is manual. Setting
+  up an SSO connection between your identity provider and Docker ensures
+  compliance with your security policy and automates user provisioning. Adding
+  SCIM further automates user provisioning and de-provisioning.
+- General and security settings: Configuring key settings ensures smooth
+  onboarding and usage of Docker products within your environment. You can also
+  enable security features based on your company's specific security needs.
+
+## Who needs to be involved
+
+- Docker organization owner: Must be involved in the process and is required
+  for several key steps
+- DNS team: Needed during the SSO setup to verify the company domain
+- MDM team: Responsible for distributing Docker-specific configuration files to
+  developer machines
+- Identity Provider team: Required for configuring the identity provider and
+  establishing the SSO connection during setup
+- Development lead: A development lead with knowledge of Docker configurations
+  to help establish a baseline for developer settings
+- IT team: An IT representative familiar with company desktop policies to
+  assist with aligning Docker configuration to those policies
+- Infosec: A security team member with knowledge of company development
+  security policies to help configure security features
+- Docker testers: A small group of developers to test the new settings and
+  configurations before full deployment
+
+## Tools integration
+
+This guide covers integration with:
+
+- Okta
+- Entra ID SAML 2.0
+- Azure Connect (OIDC)
+- MDM solutions like Intune
+
+## Communication and information gathering
+
+### Communicate with your developers and IT teams
+
+Before rolling out Docker Desktop across your organization, coordinate with key stakeholders to ensure a smooth transition.
+
+#### Notify Docker Desktop users
+
+You may already have Docker Desktop users within your company. Some steps in
+this onboarding process may affect how they interact with the platform.
+
+Communicate early with users to inform them that:
+
+- They'll be upgraded to a supported version of Docker Desktop as part of the subscription onboarding
+- Settings will be reviewed and optimized for productivity
+- They'll need to sign in to the company's Docker organization using their
+  business email to access subscription benefits
+
+#### Engage with your MDM team
+
+Device management solutions, such as Intune and Jamf, are commonly used for
+software distribution across enterprises. These tools are typically managed by a dedicated MDM team.
+
+Engage with this team early in the process to:
+
+- Understand their requirements and lead time for deploying changes
+- Coordinate the distribution of configuration files
+
+Several setup steps in this guide require JSON files, registry keys, or .plist
+files to be distributed to developer machines. Use MDM tools to deploy these configuration files and ensure their integrity.
+
+### Identify Docker organizations
+
+Some companies may have more than one
+[Docker organization](/manuals/admin/organization/_index.md) created. These
+organizations may have been created for specific purposes, or may not be
+needed anymore.
+
+If you suspect your company has multiple Docker organizations:
+
+- Survey your teams to see if they have their own organizations
+- Contact your Docker Support to get a list of organizations with users whose
+  emails match your domain name
+
+### Gather requirements
+
+[Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md) lets you preset numerous configuration parameters for Docker Desktop.
+
+Work with the following stakeholders to establish your company's baseline
+configuration:
+
+- Docker organization owner
+- Development lead
+- Information security representative
+
+Review these areas together:
+
+- Security features and
+  [enforcing sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md)
+  for Docker Desktop users
+- Additional Docker products included in your subscriptions
+
+To view the parameters that can be preset, see [Configure Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md#step-two-configure-the-settings-you-want-to-lock-in).
+
+### Optional: Meet with the Docker Implementation team
+
+The Docker Implementation team can help you set up your organization,
+configure SSO, enforce sign-in, and configure Docker Desktop.
+
+To schedule a meeting, email successteam@docker.com.
+
+## Finalize plans and begin setup
+
+### Send finalized settings files to the MDM team
+
+After reaching an agreement with the relevant teams about your baseline and
+security configurations as outlined in the previous section, configure Settings Management either via [Docker Home](/manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console.md) or with an
+[`admin-settings.json` file](/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md).
+
+Once the file is ready, collaborate with your MDM team to deploy your chosen
+settings, along with your chosen method for [enforcing sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md).
+
+> [!IMPORTANT]
+>
+> Test this first with a small number of Docker Desktop developers to verify the functionality works as expected before deploying more widely.
+
+### Manage your organizations
+
+If you have more than one organization, consider either [consolidating them
+into one organization](/manuals/admin/organization/setup/orgs.md) or creating a
+[Docker company](/manuals/admin/company/_index.md) to manage multiple
+organizations.
+
+### Begin setup
+
+#### Set up single sign-on and domain verification
+
+Single sign-on (SSO) lets developers authenticate using their identity
+providers (IdPs) to access Docker. SSO is available for a whole company and all associated organizations, or an individual organization that has a Docker
+Business subscription. For more information, see the
+[documentation](/manuals/enterprise/security/single-sign-on/_index.md).
+
+You can also enable [SCIM](/manuals/enterprise/security/provisioning/scim/_index.md)
+for further automation of provisioning and deprovisioning of users.
+
+#### Set up Docker product entitlements included in the subscription
+
+[Docker Build Cloud](/manuals/build-cloud/_index.md) significantly reduces
+build times, both locally and in CI, by providing a dedicated remote builder
+and shared cache. Powered by the cloud, developer time and local resources are
+freed up so your team can focus on more important things, like innovation.
+To get started, [set up a cloud builder](https://app.docker.com/build/).
+
+[Docker Scout](manuals/scout/_index.md) is a solution for proactively enhancing
+your software supply chain security. By analyzing your images, Docker Scout
+compiles an inventory of components, also known as a Software Bill of Materials
+(SBOM). The SBOM is matched against a continuously updated vulnerability
+database to pinpoint security weaknesses. To get started, see
+[Quickstart](/manuals/scout/quickstart.md).
+
+[Testcontainers Cloud](https://testcontainers.com/cloud/docs/) allows
+developers to run containers in the cloud, removing the need to run heavy
+containers on your local machine.
+
+[Docker Hardened Images](/manuals/dhi/_index.md) are minimal, secure, and production-ready container base and application images maintained by Docker.
+Designed to reduce vulnerabilities and simplify compliance, DHIs integrate
+easily into your existing Docker-based workflows with little to no retooling
+required.
+
+#### Ensure you're running a supported version of Docker Desktop
+
+> [!WARNING]
+>
+> This step could affect the experience for users on older versions of Docker
+> Desktop.
+
+Existing users may be running outdated or unsupported versions of
+Docker Desktop. All users should update to a supported version. Docker Desktop
+versions released within the past 6 months from the latest release are supported.
+
+Use an MDM solution to manage the version of Docker Desktop for users. Users
+may also get Docker Desktop directly from Docker or through a company software
+portal.
+
+## Testing
+
+### SSO and SCIM testing
+
+Test SSO and SCIM by signing in to Docker Desktop or Docker Hub with the email
+address linked to a Docker account that is part of the verified domain.
+Developers who sign in using their Docker usernames remain unaffected by the
+SSO and SCIM setup.
+
+> [!IMPORTANT]
+>
+> Some users may need CLI based logins to Docker Hub, and for this they will
+> need a [personal access token (PAT)](/manuals/security/access-tokens.md).
+
+### Test Registry Access Management and Image Access Management
+
+> [!WARNING]
+>
+> Communicate with your users before proceeding, as this step will impact all
+> existing users signing into your Docker organization.
+
+If you plan to use [Registry Access Management (RAM)](/manuals/enterprise/security/hardened-desktop/registry-access-management.md) and/or [Image Access Management (IAM)](/manuals/enterprise/security/hardened-desktop/image-access-management.md):
+
+1. Ensure your test developer signs in to Docker Desktop using their
+   organization credentials
+2. Have them attempt to pull an unauthorized image or one from a disallowed
+   registry via the Docker CLI
+3. Verify they receive an error message indicating that the registry is
+   restricted by the organization
+
+### Deploy settings and enforce sign in to test group
+
+Deploy the Docker settings and enforce sign-in for a small group of test users
+via MDM. Have this group test their development workflows with containers on
+Docker Desktop and Docker Hub to ensure all settings and the sign-in enforcement
+function as expected.
+
+### Test Docker Build Cloud capabilities
+
+Have one of your Docker Desktop testers [connect to the cloud builder you created and use it to build](/manuals/build-cloud/usage.md).
+
+### Test Testcontainers Cloud
+
+Have a test developer [connect to Testcontainers Cloud](https://testcontainers.com/cloud/docs/#getting-started) and run a container in
+the cloud to verify the setup is working correctly.
+
+### Verify Docker Scout monitoring of repositories
+
+Check the [Docker Scout dashboard](https://scout.docker.com/) to confirm that
+data is being properly received for the repositories where Docker Scout has
+been enabled.
+
+### Verify access to Docker Hardened Images
+
+Have a test developer attempt to [pull a Docker Hardened Image](/manuals/dhi/get-started.md) to confirm that
+the team has proper access and can integrate these images into their workflows.
+
+## Deploy your Docker setup
+
+> [!WARNING]
+>
+> Communicate with your users before proceeding, and confirm that your IT and
+> MDM teams are prepared to handle any unexpected issues, as these steps will
+> affect all existing users signing into your Docker organization.
+
+### Enforce SSO
+
+Enforcing SSO means that anyone who has a Docker profile with an email address
+that matches your verified domain must sign in using your SSO connection. Make
+sure the Identity provider groups associated with your SSO connection cover all
+the developer groups that you want to have access to the Docker subscription.
+
+For instructions on how to enforce SSO, see [Enforce SSO](/manuals/enterprise/security/single-sign-on/connect.md).
+
+### Deploy configuration settings and enforce sign-in to users
+
+Have the MDM team deploy the configuration files for Docker to all users.
+
+### Next steps
+
+Congratulations, you've successfully completed the admin implementation process
+for Docker.
+
+To continue optimizing your Docker environment:
+
+- Review your [organization's usage data](/manuals/admin/insights.md) to track adoption
+- Monitor [Docker Scout findings](/manuals/scout/explore/analysis.md) for security insights
+- Explore [additional security features](/manuals/enterprise/security/_index.md) to enhance your configuration
diff --git a/content/guides/admin-set-up/_index.md b/content/guides/admin-set-up/_index.md
deleted file mode 100644
index 556c512a7c14..000000000000
--- a/content/guides/admin-set-up/_index.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: Set up your company for success with Docker
-linkTitle: Admin set up 
-summary: Get the most out of Docker by streamlining workflows, standardizing development environments, and ensuring smooth deployments across your company.
-description: Learn how to onboard your company and take advantage of all of the Docker products and features.
-tags: [admin]
-params:
-  featured: true
-  time: 20 minutes
-  image: 
-  resource_links:
-    - title: Overview of Administration in Docker
-      url: /admin/
-    - title: Single sign-on
-      url: /security/for-admins/single-sign-on/
-    - title: Enforce sign-in
-      url: /security/for-admins/enforce-sign-in/
-    - title: Roles and permissions
-      url: /security/for-admins/roles-and-permissions/
-    - title: Settings Management
-      url: /security/for-admins/hardened-desktop/settings-management/
-    - title: Registry Access Management
-      url: /security/for-admins/hardened-desktop/registry-access-management/
-    - title: Image Access Management
-      url: /security/for-admins/hardened-desktop/image-access-management/
-    - title: Docker subscription information
-      url: /subscription/details/
----
-
-Docker's tools provide a scalable, secure platform that empowers your developers to create, ship, and run applications faster. As an administrator, you have the ability to streamline workflows, standardize development environments, and ensure smooth deployments across your organization.
-
-By configuring Docker products to suit your company’s needs, you can optimize performance, simplify user management, and maintain control over resources. This guide will help you set up and configure Docker products to maximize productivity and success for your team whilst meeting compliance and security policies
-
-## Who’s this for?
-
-- Administrators responsible for managing Docker environments within their organization
-- IT leaders looking to streamline development and deployment workflows
-- Teams aiming to standardize application environments across multiple users
-- Organizations seeking to optimize their use of Docker products for greater scalability and efficiency
-- Organizations with [Docker Business subscriptions](https://www.docker.com/pricing/).
-
-## What you’ll learn
-
-- The importance of signing in to the company's Docker organization for access to usage data and enhanced functionality.
-- How to standardize Docker Desktop versions and settings to create a consistent baseline for all users, while allowing flexibility for advanced developers.
-- Strategies for implementing Docker’s security configurations to meet company IT and software development security requirements without hindering developer productivity.
-
-## Features covered
-
-- Organizations. These are the core structure for managing your Docker environment, grouping users, teams, and image repositories. Your organization was created with your subscription and is managed by one or more Owners. Users signed into the organization are assigned seats based on the purchased subscription.
-- Enforce sign-in. By default, Docker Desktop does not require sign-in. However, you can configure settings to enforce this and ensure your developers sign in to your Docker organization.
-- SSO. Without SSO, user management in a Docker organization is manual. Setting up an SSO connection between your identity provider and Docker ensures compliance with your security policy and automates user provisioning. Adding SCIM further automates user provisioning and de-provisioning.
-- General and security settings. Configuring key settings will ensure smooth onboarding and usage of Docker products within your environment. Additionally, you can enable security features based on your company's specific security needs.
-
-## Who needs to be involved?
-
-- Docker organization owner: A Docker organization owner must be involved in the process and will be required for several key steps.
-- DNS team: The DNS team is needed during the SSO setup to verify the company domain.
-- MDM team: Responsible for distributing Docker-specific configuration files to developer machines.
-- Identity Provider team: Required for configuring the identity provider and establishing the SSO connection during setup.
-- Development lead: A development lead with knowledge of Docker configurations to help establish a baseline for developer settings.
-- IT team: An IT representative familiar with company desktop policies to assist with aligning Docker configuration to those policies.
-- Infosec: A security team member with knowledge of company development security policies to help configure security features.
-- Docker testers: A small group of developers to test the new settings and configurations before full deployment.
-
-## Tools integration
-
-Okta, Entra ID SAML 2.0, Azure Connect (OIDC), MDM solutions like Intune
diff --git a/content/guides/admin-set-up/comms-and-info-gathering.md b/content/guides/admin-set-up/comms-and-info-gathering.md
deleted file mode 100644
index 1ad54fb855c0..000000000000
--- a/content/guides/admin-set-up/comms-and-info-gathering.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Communication and information gathering
-description: Gather your company's requirements from key stakeholders and communicate to your developers.
-weight: 10
----
-
-## Step one: Communicate with your developers and IT teams
-
-### Docker user communication
-
-You may already have Docker Desktop users within your company, and some steps in this process may affect how they interact with the platform. It's highly recommended to communicate early with users, informing them that as part of the subscription onboarding, they will be upgraded to a supported version of Docker Desktop. 
-
-Additionally, communicate that settings will be reviewed to optimize productivity, and users will be required to sign in to the company’s Docker organization using their business email to fully utilize the subscription benefits.
-
-### MDM team communication
-
-Device management solutions, such as Intune and Jamf, are commonly used for software distribution across enterprises, typically managed by a dedicated MDM team. It is recommended that you engage with this team early in the process to understand their requirements and the lead time for deploying changes.
-
-Several key setup steps in this guide require the use of JSON files, registry keys, or .plist files that need to be distributed to developer machines. It’s a best practice to use MDM tools for deploying these configuration files and ensuring their integrity is preserved.
-
-## Step two: Identify Docker organizations
-
-Some companies may have more than one [Docker organization](/manuals/admin/organization/_index.md) created. These organizations may have been created for specific purposes, or may not be needed anymore. If you suspect your company has more than one Docker organization, it's recommended you survey your teams to see if they have their own organizations. You can also contact your Docker Customer Success representative to get a list of organizations with users whose emails match your domain name.
-
-## Step three: Gather requirements
-
-Through [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md), Docker provides numerous configuration parameters that can be preset. The Docker organization owner, development lead, and infosec representative should review these settings to establish the company’s baseline configuration, including security features and [enforcing sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) for Docker Desktop users. Additionally, they should decide whether to take advantage of other Docker products, such as [Docker Scout](/manuals/scout/_index.md), which is included in the subscription.
-
-To view the parameters that can be preset, see [Configure Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/configure-json-file.md#step-two-configure-the-settings-you-want-to-lock-in).
-
-## Optional step four: Meet with the Docker Implementation team
-
-The Docker Implementation team can help you step through setting up your organization, configuring SSO, enforcing sign-in, and configuring Docker. You can reach out to set up a meeting by emailing successteam@docker.com.
diff --git a/content/guides/admin-set-up/deploy.md b/content/guides/admin-set-up/deploy.md
deleted file mode 100644
index ab91d9f4e568..000000000000
--- a/content/guides/admin-set-up/deploy.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Deploy 
-description: Deploy your Docker setup across your company.
-weight: 40
----
-
-> [!WARNING]
-> Ensure you communicate with your users before proceeding, and confirm that your IT and MDM teams are prepared to handle any unexpected issues, as these steps will affect all existing users signing into your Docker organization.
-
-## Step one: Enforce SSO
-
-Enforcing SSO means that anyone who has a Docker profile with an email address that matches your verified domain must sign in using your SSO connection. Make sure the Identity provider groups associated with your SSO connection cover all the developer groups that you want to have access to the Docker subscription.
-
-## Step two: Deploy configuration settings and enforce sign-in to users
-
-Have the MDM team deploy the configuration files for Docker to all users.  
-
-Congratulations, you have successfully completed the admin implementation process for Docker. 
diff --git a/content/guides/admin-set-up/finalize-plans-and-setup.md b/content/guides/admin-set-up/finalize-plans-and-setup.md
deleted file mode 100644
index b810d3dfbc06..000000000000
--- a/content/guides/admin-set-up/finalize-plans-and-setup.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: Finalize plans and begin setup
-description: Collaborate with your MDM team to distribute configurations and set up SSO and Docker product trials.
-weight: 20
----
-
-## Step one: Send finalized settings files to the MDM team 
-
-After reaching an agreement with the relevant teams about your baseline and security configurations as outlined in module one, configure Settings Management using either the [Docker Admin Console](/manuals/security/for-admins/hardened-desktop/settings-management/configure-admin-console.md) or an [`admin-settings.json` file](/manuals/security/for-admins/hardened-desktop/settings-management/configure-json-file.md).
-
-Once the file is ready, collaborate with your MDM team to deploy your chosen settings, along with your chosen method for [enforcing sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md).
-
-> [!IMPORTANT]
->
-> It’s highly recommended that you test this first with a small number of Docker Desktop developers to verify the functionality works as expected before deploying more widely.
-
-## Step two: Manage your organizations
-
-If you have more than one organization, it’s recommended that you either consolidate them into one organization or create a [Docker company](/manuals/admin/company/_index.md) to manage multiple organizations. Work with the Docker Customer Success and Implementation teams to make this happen.
-
-## Step three: Begin setup
-
-### Set up single sign-on SSO domain verification
-
-Single sign-on (SSO) lets developers authenticate using their identity providers (IdPs) to access Docker. SSO is available for a whole company, and all associated organizations, or an individual organization that has a Docker Business subscription. For more information, see the [documentation](/manuals/security/for-admins/single-sign-on/_index.md).
-
-You can also enable [SCIM](/manuals/security/for-admins/provisioning/scim.md) for further automation of provisioning and deprovisioning of users.
-
-### Set up Docker product entitlements included in the subscription
-
-[Docker Build Cloud](/manuals/build-cloud/_index.md) significantly reduces build times, both locally and in CI, by providing a dedicated remote builder and shared cache. Powered by the cloud, developer time and local resources are freed up so your team can focus on more important things, like innovation. To get started, [set up a cloud builder](https://app.docker.com/build/). 
-
-[Docker Scout](manuals/scout/_index.md) is a solution for proactively enhancing your software supply chain security. By analyzing your images, Docker Scout compiles an inventory of components, also known as a Software Bill of Materials (SBOM). The SBOM is matched against a continuously updated vulnerability database to pinpoint security weaknesses. To get started, see [Quickstart](/manuals/scout/quickstart.md).
-
-### Ensure you're running a supported version of Docker Desktop
-
-> [!WARNING]
->
-> This step could affect the experience for users on older versions of Docker Desktop.  
-
-Existing users may be running outdated or unsupported versions of Docker Desktop. It is highly recommended that all users update to a supported version. Docker Desktop versions released within the past 6 months from the latest release are supported.
-
-It's recommended that you use a MDM solution to manage the version of Docker Desktop for users. Users may also get Docker Desktop directly from Docker or through a company software portal.  
diff --git a/content/guides/admin-set-up/testing.md b/content/guides/admin-set-up/testing.md
deleted file mode 100644
index 9ee6306764e9..000000000000
--- a/content/guides/admin-set-up/testing.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: Testing
-description: Test your Docker setup.
-weight: 30
----
-
-## SSO and SCIM testing
-
-You can test SSO and SCIM by signing in to Docker Desktop or Docker Hub with the email address linked to a Docker account that is part of the verified domain. Developers who sign in using their Docker usernames will remain unaffected by the SSO and/or SCIM setup. 
-
-> [!IMPORTANT] 
->
-> Some users may need CLI based logins to Docker Hub, and for this they will need a [personal access token (PAT)](/manuals/security/for-developers/access-tokens.md).
-
-## Test RAM and IAM
-
-> [!WARNING]
-> Be sure to communicate with your users before proceeding, as this step will impact all existing users signing into your Docker organization
-
-If you plan to use [Registry Access Management (RAM)](/manuals/security/for-admins/hardened-desktop/registry-access-management.md) and/or [Image Access Management (IAM)](/manuals/security/for-admins/hardened-desktop/image-access-management.md), ensure your test developer signs in to Docker Desktop using their organization credentials. Once authenticated, have them attempt to pull an unauthorized image or one from a disallowed registry via the Docker CLI. They should receive an error message indicating that the registry is restricted by the organization.
-
-## Deploy settings and enforce sign in to test group
-
-Deploy the Docker settings and enforce sign-in for a small group of test users via MDM. Have this group test their development workflows with containers on Docker Desktop and Docker Hub to ensure all settings and the sign-in enforcement function as expected.
-
-## Test Docker Build Cloud capabilities
-
-Have one of your Docker Desktop testers [connect to the cloud builder you created and use it to build](/manuals/build-cloud/usage.md). 
-
-## Verify Docker Scout monitoring of repositories
-
-Check the [Docker Scout dashboard](https://scout.docker.com/) to confirm that data is being properly received for the repositories where Docker Scout has been enabled.
diff --git a/content/guides/admin-user-management.md b/content/guides/admin-user-management.md
new file mode 100644
index 000000000000..84ff0adb7545
--- /dev/null
+++ b/content/guides/admin-user-management.md
@@ -0,0 +1,198 @@
+---
+title: Mastering user and access management
+summary: Simplify user access while ensuring security and efficiency in Docker.
+description: A guide for managing roles, provisioning users, and optimizing Docker access with tools like SSO and activity logs.
+keywords: admin, user management, roles, permissions, sso, provisioning, access control
+aliases:
+  - /guides/admin-user-management/audit-and-monitor/
+  - /guides/admin-user-management/onboard/
+  - /guides/admin-user-management/setup/
+params:
+  tags: [admin]
+  featured: false
+  time: 20 minutes
+  image:
+---
+
+
+Managing roles and permissions is key to securing your Docker environment while enabling easy collaboration and operational efficiency. This guide walks IT administrators through the essentials of user and access management, offering strategies for assigning roles, provisioning users, and using tools like activity logs and Insights to monitor and optimize Docker usage.
+
+## Who's this for?
+
+- IT teams tasked with configuring and maintaining secure user access
+- Security professionals focused on enforcing secure access practices
+- Project managers overseeing team collaboration and resource management
+
+## What you'll learn
+
+- How to assess and manage Docker user access and align accounts with organizational needs
+- When to use team configurations for scalable access control
+- How to automate and streamline user provisioning with SSO, SCIM, and JIT
+- How to get the most out of Docker's monitoring tools
+
+## Tools integration
+
+This guide covers integration with:
+
+- Okta
+- Entra ID SAML 2.0
+- Azure Connect (OIDC)
+
+## Setting up roles and permissions in Docker
+
+With the right configurations, you can ensure your developers have easy access to necessary resources while preventing unauthorized access. This page guides you through identifying Docker users so you can allocate subscription seats efficiently within your Docker organization, and assigning roles to align with your organization's structure.
+
+### Identify your Docker users and accounts
+
+Before setting up roles and permissions, it's important to have a clear understanding of who in your organization requires Docker access. Focus on gathering a comprehensive view of active users, their roles within projects, and how they interact with Docker resources. This process can be supported by tools like device management software or manual assessments. Encourage all users to update their Docker accounts to use organizational email addresses, ensuring seamless integration with your subscription.
+
+For steps on how you can do this, see [step 1 of onboarding your organization](/manuals/admin/organization/setup/onboard.md).
+
+### Assign roles strategically
+
+When you invite members to join your Docker organization, you assign them a role.
+
+Docker's predefined roles offer flexibility for various organizational needs. Assigning roles effectively ensures a balance of accessibility and security.
+
+- Member: Non-administrative role. Members can view other members that are in the same organization.
+- Editor: Partial administrative access to the organization. Editors can create, edit, and delete repositories. They can also edit an existing team's access permissions.
+- Owner: Full organization administrative access. Owners can manage organization repositories, teams, members, settings, and billing.
+
+For more information, see [Roles and permissions](/manuals/enterprise/security/roles-and-permissions.md).
+
+#### Enhance with teams
+
+Teams in Docker provide a structured way to manage member access and they provide an additional level of permissions. They simplify permission management and enable consistent application of policies.
+
+- Organize users into teams aligned with projects, departments, or functional roles. This approach helps streamline resource allocation and ensures clarity in access control.
+- Assign permissions at the team level rather than individually. For instance, a development team might have "Read & Write" access to certain repositories, while a QA team has "Read-only" access.
+- As teams grow or responsibilities shift, you can easily update permissions or add new members, maintaining consistency without reconfiguring individual settings.
+
+For more information, see [Create and manage a team](/manuals/admin/organization/manage/manage-a-team.md).
+
+#### Example scenarios
+
+- Development teams: Assign the member role to developers, granting access to the repositories needed for coding and testing.
+- Team leads: Assign the editor role to team leads for resource management and repository control within their teams.
+- Organizational oversight: Restrict the organization owner or company owner roles to a select few trusted individuals responsible for billing and security settings.
+
+#### Best practices
+
+- Apply the principle of least privilege. Assign users only the minimum permissions necessary for their roles.
+- Conduct regular reviews of role assignments to ensure they align with evolving team structures and organizational responsibilities.
+
+## Onboarding and managing roles and permissions in Docker
+
+This page guides you through onboarding owners and members, and using tools like SSO and SCIM to future-proof onboarding going forward.
+
+### Invite owners
+
+When you create a Docker organization, you automatically become its sole owner. While optional, adding additional owners can significantly ease the process of onboarding and managing your organization by distributing administrative responsibilities. It also ensures continuity and prevents blockers if the primary owner is unavailable.
+
+For detailed information on owners, see [Roles and permissions](/manuals/enterprise/security/roles-and-permissions.md).
+
+### Invite members and assign roles
+
+Members are granted controlled access to resources and enjoy enhanced organizational benefits. When you invite members to join your Docker organization, you immediately assign them a role.
+
+#### Benefits of inviting members
+
+- Enhanced visibility: Gain insights into user activity, making it easier to monitor access and enforce security policies.
+- Streamlined collaboration: Help members collaborate effectively by granting access to shared resources and repositories.
+- Improved resource management: Organize and track users within your organization, ensuring optimal allocation of resources.
+- Access to enhanced features: Members benefit from organization-wide perks, such as increased pull limits and access to premium Docker features.
+- Security control: Apply and enforce security settings at an organizational level, reducing risks associated with unmanaged accounts.
+
+For detailed information, see [Manage organization members](/manuals/admin/organization/manage/members.md).
+
+### Future-proof user management
+
+A robust, future-proof approach to user management combines automated provisioning, centralized authentication, and dynamic access control. Implementing these practices ensures a scalable, secure, and efficient environment.
+
+#### Secure user authentication with single sign-on (SSO)
+
+Integrating Docker with your identity provider streamlines user access and enhances security.
+
+SSO:
+
+- Simplifies sign in, as users sign in with their organizational credentials.
+- Reduces password-related vulnerabilities.
+- Simplifies onboarding as it works seamlessly with SCIM and group mapping for automated provisioning.
+
+For more information, see the [SSO documentation](/manuals/enterprise/security/single-sign-on/_index.md).
+
+#### Automate onboarding with SCIM and JIT provisioning
+
+Streamline user provisioning and role management with [SCIM](/manuals/enterprise/security/provisioning/scim/_index.md) and [Just-in-Time (JIT) provisioning](/manuals/enterprise/security/provisioning/just-in-time.md).
+
+With SCIM you can:
+
+- Sync users and roles automatically with your identity provider.
+- Automate adding, updating, or removing users based on directory changes.
+
+With JIT provisioning you can:
+
+- Automatically add users upon first sign in based on [group mapping](#simplify-access-with-group-mapping).
+- Reduce overhead by eliminating pre-invite steps.
+
+#### Simplify access with group mapping
+
+Group mapping automates permissions management by linking identity provider groups to Docker roles and teams.
+
+It also:
+
+- Reduces manual errors in role assignments.
+- Ensures consistent access control policies.
+- Help you scale permissions as teams grow or change.
+
+For more information on how it works, see [Group mapping](/manuals/enterprise/security/provisioning/scim/group-mapping.md).
+
+## Monitoring and insights
+
+Activity logs and Insights are useful tools for user and access management in Docker. They provide visibility into user actions, team workflows, and organizational trends, helping enhance security, ensure compliance, and boost productivity.
+
+### Activity logs
+
+Activity logs track events at the organization and repository levels, offering a clear view of activities like repository changes, team updates, and billing adjustments.
+
+Activity logs are available for Docker Team or Docker Business plans, with data retained for three months.
+
+#### Key features
+
+- Change tracking: View what changed, who made the change, and when.
+- Comprehensive reporting: Monitor critical events such as repository creation, deletion, privacy changes, and role assignments.
+
+#### Example scenarios
+
+- Audit trail for security: A repository’s privacy settings were updated unexpectedly. The activity logs reveal which user made the change and when, helping administrators address potential security risks.
+- Team collaboration review: Logs show which team members pushed updates to a critical repository, ensuring accountability during a development sprint.
+- Billing adjustments: Track who added or removed subscription seats to maintain budgetary control and compliance.
+
+For more information, see [Activity logs](/manuals/admin/activity-logs.md).
+
+### Insights
+
+Insights provide data-driven views of Docker usage to improve team productivity and resource allocation.
+
+#### Key benefits
+
+- Standardized environments: Ensure consistent configurations and enforce best practices across teams.
+- Improved visibility: Monitor metrics like Docker Desktop usage, builds, and container activity to understand team workflows and engagement.
+- Optimized resources: Track license usage and feature adoption to maximize the value of your Docker subscription.
+
+#### Example scenarios
+
+- Usage trends: Identify underutilized licenses or resources, allowing reallocation to more active teams.
+- Build efficiency: Track average build times and success rates to pinpoint bottlenecks in development processes.
+- Container utilization: Analyze container activity across departments to ensure proper resource distribution and cost efficiency.
+
+For more information, see [Insights](/manuals/admin/insights.md).
+
+### Next steps
+
+Now that you've mastered user and access management in Docker, you can:
+
+- Review your [activity logs](/manuals/admin/activity-logs.md) regularly to maintain security awareness
+- Check your [Insights dashboard](/manuals/admin/insights.md) to identify opportunities for optimization
+- Explore [advanced security features](/manuals/enterprise/security/_index.md) to further enhance your Docker environment
+- Share best practices with your team to ensure consistent adoption of security policies
diff --git a/content/guides/admin-user-management/_index.md b/content/guides/admin-user-management/_index.md
deleted file mode 100644
index 746eaed94ed6..000000000000
--- a/content/guides/admin-user-management/_index.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: Mastering user and access management
-summary: Simplify user access while ensuring security and efficiency in Docker.
-description: A guide for managing roles, provisioning users, and optimizing Docker access with tools like SSO and activity logs.
-tags: [admin]
-params:
-  featured: true
-  time: 20 minutes
-  image: 
-  resource_links:
-    - title: Overview of Administration in Docker
-      url: /admin/
-    - title: Single sign-on
-      url: /security/for-admins/single-sign-on/
-    - title: Onboard your organization
-      url: /admin/organization/onboard/
-    - title: Roles and permissions
-      url: /security/for-admins/roles-and-permissions/
-    - title: Insights
-      url: /admin/organization/insights/
-    - title: Activity logs
-      url: /admin/organization/activity-logs/
----
-
-Managing roles and permissions is key to securing your Docker environment while enabling easy collaboration and operational efficiency. This guide walks IT administrators through the essentials of user and access management, offering strategies for assigning roles, provisioning users, and using tools like Activity logs and Insights to monitor and optimize Docker usage.
-
-## Who's this for?
-
-- IT teams: Tasked with configuring and maintaining secure user access.
-- Security professionals: Focused on enforcing secure access practices.
-- Project managers: Overseeing team collaboration and resource management.
-
-## What you'll learn
-
-- How to assess and manage Docker user access and align accounts with organizational needs.
-- When to use team configurations for scalable access control.
-- How to automate and streamline user provisioning with SSO, SCIM, and JIT.
-- How to get the most out of Docker's monitoring tools.
-
-## Tools integration 
-
-Okta, Entra ID SAML 2.0, Azure Connect (OIDC)
diff --git a/content/guides/admin-user-management/audit-and-monitor.md b/content/guides/admin-user-management/audit-and-monitor.md
deleted file mode 100644
index 905dd7fbaabd..000000000000
--- a/content/guides/admin-user-management/audit-and-monitor.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: Monitoring and insights
-description: Track user actions, team workflows, and organizational trends with Activity logs and Insights to enhance security and productivity in Docker.
-keywords: organizational insights, user management, access control, security, monitoring, admins
-weight: 30
----
-
-Activity logs and Insights are useful tools for user and access management in Docker. They provide visibility into user actions, team workflows, and organizational trends, helping enhance security, ensure compliance, and boost productivity.
-
-## Activity logs
-
-Activity logs track events at the organization and repository levels, offering a clear view of activities like repository changes, team updates, and billing adjustments.
-
-It is available for Docker Team or Docker Business plans, with data retained for three months.
-
-### Key features
-
- - Change tracking: View what changed, who made the change, and when.
-
- - Comprehensive reporting: Monitor critical events such as repository creation, deletion, privacy changes, and role assignments.
-
-### Example scenarios
-
- - Audit trail for security: A repository’s privacy settings were updated unexpectedly. The activity logs reveal which user made the change and when, helping administrators address potential security risks.
-
- - Team collaboration review: Logs show which team members pushed updates to a critical repository, ensuring accountability during a development sprint.
-
- - Billing adjustments: Track who added or removed subscription seats to maintain budgetary control and compliance.
-
-For more information, see [Activity logs](/manuals/admin/organization/activity-logs.md).
-
-## Insights
-
-Insights provide data-driven views of Docker usage to improve team productivity and resource allocation.
-
-### Key benefits
-
- - Standardized environments: Ensure consistent configurations and enforce best practices across teams.
-
- - Improved visibility: Monitor metrics like Docker Desktop usage, builds, and container activity to understand team workflows and engagement.
-
- - Optimized resources: Track license usage and feature adoption to maximize the value of your Docker subscription.
-
-### Example scenarios
-
- - Usage trends: Identify underutilized licenses or resources, allowing reallocation to more active teams.
-
- - Build efficiency: Track average build times and success rates to pinpoint bottlenecks in development processes.
-
- - Container utilization: Analyze container activity across departments to ensure proper resource distribution and cost efficiency.
-
- For more information, see [Insights](/manuals/admin/organization/insights.md).
diff --git a/content/guides/admin-user-management/onboard.md b/content/guides/admin-user-management/onboard.md
deleted file mode 100644
index 674d10933484..000000000000
--- a/content/guides/admin-user-management/onboard.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: Onboarding and managing roles and permissions in Docker
-description: Learn how to manage roles, invite members, and implement scalable access control in Docker for secure and efficient collaboration.
-keywords: sso, scim, jit, invite members, docker hub, docker admin console, onboarding, security
-weight: 20
----
-
-This page guides you through onboarding owners and members, and using tools like SSO and SCIM to future-proof onboarding going forward.
-
-## Step 1: Invite owners
-
-When you create a Docker organization, you automatically become its sole owner. While optional, adding additional owners can significantly ease the process of onboarding and managing your organization by distributing administrative responsibilities. It also ensures continuity and does not cause a blocker if the primary owner is unavailable.
-
-For detailed information on owners, see [Roles and permissions](/manuals/security/for-admins/roles-and-permissions.md).
-
-## Step 2: Invite members and assign roles
-
-Members are granted controlled access to resources and enjoy enhanced organizational benefits. When you invite members to join you Docker organization, you immediately assign them a role.
-
-### Benefits of inviting members
-
- - Enhanced visibility: Gain insights into user activity, making it easier to monitor access and enforce security policies.
-
- - Streamlined collaboration: Help members collaborate effectively by granting access to shared resources and repositories.
-
- - Improved resource management: Organize and track users within your organization, ensuring optimal allocation of resources.
-
- - Access to enhanced features: Members benefit from organization-wide perks, such as increased pull limits and access to premium Docker features.
-
- - Security control: Apply and enforce security settings at an organizational level, reducing risks associated with unmanaged accounts.
-
-For detailed information, see [Manage organization members](/manuals/admin/organization/members.md).
-
-## Step 3: Future-proof user management
-
-A robust, future-proof approach to user management combines automated provisioning, centralized authentication, and dynamic access control. Implementing these practices ensures a scalable, secure, and efficient environment.
-
-### Secure user authentication with single sign-on (SSO)
-
-Integrating Docker with your identity provider streamlines user access and enhances security.
-
-SSO: 
-
- - Simplifies sign in, as users sign in with their organizational credentials.
-
- - Reduces password-related vulnerabilities.
-
- - Simplifies onboarding as it works seamlessly with SCIM and group mapping for automated provisioning.
-
-[SSO documentation](/manuals/security/for-admins/single-sign-on/_index.md).
-
-### Automate onboarding with SCIM and JIT provisioning
-
-Streamline user provisioning and role management with [SCIM](/manuals/security/for-admins/provisioning/scim.md) and [Just-in-Time (JIT) provisioning](/manuals/security/for-admins/provisioning/just-in-time.md).
-
-With SCIM you can:
-
- - Sync users and roles automatically with your identity provider.
-
- - Automate adding, updating, or removing users based on directory changes.
-
-With JIT provisioning you can:
-
- - Automatically add users upon first sign in based on [group mapping](#simplify-access-with-group-mapping).
-
- - Reduce overhead by eliminating pre-invite steps.
-
-### Simplify access with group mapping
-
-Group mapping automates permissions management by linking identity provider groups to Docker roles and teams.
-
-It also:
-
- - Reduces manual errors in role assignments.
-
- - Ensures consistent access control policies.
-
- - Help you scale permissions as teams grow or change.
-
-For more information on how it works, see [Group mapping](/manuals/security/for-admins/provisioning/group-mapping.md).
diff --git a/content/guides/admin-user-management/setup.md b/content/guides/admin-user-management/setup.md
deleted file mode 100644
index 3bec55731ee1..000000000000
--- a/content/guides/admin-user-management/setup.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: Setting up roles and permissions in Docker
-description: A guide to securely managing access and collaboration in Docker through roles and teams.
-keywords: Docker roles, permissions management, access control, IT administration, team collaboration, least privilege, security, Docker teams, role-based access
-weight: 10
----
-
-With the right configurations, you can ensure your developers have easy access to necessary resources while preventing unauthorized access. This page guides you through identifying Docker users, so you can allocate subscription seats efficiently within your Docker organization, and assigning roles to align with your organization's structure. 
-
-## Step 1: Identify your Docker users and accounts
-
-Before setting up roles and permissions, it’s important to have a clear understanding of who in your organization requires Docker access. Focus on gathering a comprehensive view of active users, their roles within projects, and how they interact with Docker resources. This process can be supported by tools like device management software or manual assessments. Encourage all users to update their Docker accounts to use organizational email addresses, ensuring seamless integration with your subscription.
-
-For steps on how you can do this, see [step 1 of onboarding your organization](/manuals/admin/organization/onboard.md).
-
-## Step 2: Assign roles strategically
-
-When you invite members to join you Docker organization, you assign them a role. 
-
-Docker’s predefined roles offer flexibility for various organizational needs. Assigning roles effectively ensures a balance of accessibility and security.
-
-- Member: Non-administrative role. Members can view other members that are in the same organization.
-- Editor: Partial administrative access to the organization. Editors can create, edit, and delete repositories. They can also edit an existing team's access permissions.
-- Organization owner: Full organization administrative access. Organization owners can manage organization repositories, teams, members, settings, and billing.
-- Company owner: In addition to the permissions of an organization owner, company owners can configure settings for their associated organizations.
-
-For more information, see [Roles and permissions](/manuals/security/for-admins/roles-and-permissions.md).
-
-### Enhancing with teams
-
-Teams in Docker provide a structured way to manage member access and they provide an additional level of permissions. They simplify permission management and enable consistent application of policies.
-
-- Organize users into teams aligned with projects, departments, or functional roles. This approach helps streamline resource allocation and ensures clarity in access control.
-
-- Assign permissions at the team level rather than individually. For instance, a development team might have "Read & Write" access to certain repositories, while a QA team has "Read-only" access.
-
-- As teams grow or responsibilities shift, you can easily update permissions or add new members, maintaining consistency without reconfiguring individual settings.
-
-For more information, see [Create and manage a team](/manuals/admin/organization/manage-a-team.md).
-
-### Example scenarios
-
-- Development teams: Assign the member role to developers, granting access to the repositories needed for coding and testing.
-
-- Team leads: Assign the editor role to team leads for resource management and repository control within their teams.
-
-- Organizational oversight: Restrict the organization owner or company owner roles to a select few trusted individuals responsible for billing and security settings.
-
-### Best practices
-
-- Apply the principle of least privilege. Assign users only the minimum permissions necessary for their roles.
-
-- Plan to conduct regulars reviews of role assignments to ensure they align with evolving team structures and organizational responsibilities.
diff --git a/content/guides/agentic-ai.md b/content/guides/agentic-ai.md
new file mode 100644
index 000000000000..26141201e775
--- /dev/null
+++ b/content/guides/agentic-ai.md
@@ -0,0 +1,349 @@
+---
+title: Build and run agentic AI applications with Docker
+linktitle: Agentic AI applications
+keywords: AI, Docker, Model Runner, MCP Toolkit, AI agents, application development
+summary: |
+  Learn how to create AI agent applications using Docker Model Runner, and MCP Toolkit.
+params:
+  tags: [ai]
+  time: 30 minutes
+---
+
+> [!TIP]
+>
+> This guide uses the familiar Docker Compose workflow to orchestrate agentic AI
+> applications. For a smoother development experience, check out
+> [Docker Agent](../manuals/ai/docker-agent/_index.md), a purpose-built agent runtime that
+> simplifies running and managing AI agents.
+
+## Introduction
+
+Agentic applications are transforming how software gets built. These apps don't
+just respond, they decide, plan, and act. They're powered by models,
+orchestrated by agents, and integrated with APIs, tools, and services in real
+time.
+
+All these new agentic applications, no matter what they do, share a common
+architecture. It's a new kind of stack, built from three core components:
+
+- Models: These are your GPTs, CodeLlamas, Mistrals. They're doing the
+  reasoning, writing, and planning. They're the engine behind the intelligence.
+
+- Agent: This is where the logic lives. Agents take a goal, break it down, and
+  figure out how to get it done. They orchestrate everything. They talk to the
+  UI, the tools, the model, and the gateway.
+
+- MCP gateway: This is what links your agents to the outside world, including
+  APIs, tools, and services. It provides a standard way for agents to call
+  capabilities via the Model Context Protocol (MCP).
+
+Docker makes this AI-powered stack simpler, faster, and more secure by unifying
+models, and tool gateways into a developer-friendly workflow that uses Docker
+Compose.
+
+![A diagram of the agentic stack](./images/agentic-ai-diagram.webp)
+
+This guide walks you through the core components of agentic development and
+shows how Docker ties them all together with the following tools:
+
+- [Docker Model Runner](../manuals/ai/model-runner/_index.md) lets you run LLMs
+  locally with simple command and OpenAI-compatible APIs.
+- [Docker MCP Catalog and
+  Toolkit](../manuals/ai/mcp-catalog-and-toolkit/_index.md) helps you discover
+  and securely run external tools, like APIs and databases, using the Model
+  Context Protocol (MCP).
+- [Docker MCP Gateway](../manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md) lets you orchestrate and manage MCP servers.
+- [Docker Compose](/manuals/ai/compose/models-and-compose.md) is the tool that ties it all
+  together, letting you define and run multi-container applications with a
+  single file.
+
+For this guide, you'll use the same Compose workflow you're already familiar
+with. Then, you'll dig into the Compose file, Dockerfile, and app to see how it
+all works together.
+
+## Prerequisites
+
+To follow this guide, you need to:
+
+- [Install Docker Desktop 4.43 or later](../get-started/get-docker.md)
+- [Enable Docker Model Runner](/manuals/ai/model-runner.md#enable-dmr-in-docker-desktop)
+- At least the following hardware specifications:
+  - VRAM: 3.5 GB
+  - Storage: 2.31 GB
+
+## Step 1: Clone the sample application
+
+You'll use an existing sample application that demonstrates how to connect a
+model to an external tool using Docker's AI features.
+
+```console
+$ git clone https://github.com/docker/compose-for-agents.git
+$ cd compose-for-agents/adk/
+```
+
+## Step 2: Run the application locally
+
+Your machine must meet the necessary hardware requirements to run the
+entire application stack locally using Docker Compose. This lets you test the
+application end-to-end, including the model and MCP gateway, without needing to
+run in the cloud. This particular example uses the [Gemma 3 4B
+model](https://hub.docker.com/r/ai/gemma3) with a context size of `10000`.
+
+Hardware requirements:
+
+- VRAM: 3.5 GB
+- Storage: 2.31 GB
+
+If your machine exceeds those requirements, consider running the application with a larger
+context size or a larger model to improve the agents performance. You can easily
+update model and context size in the `compose.yaml` file.
+
+To run the application locally, follow these steps:
+
+1. In the `adk/` directory of the cloned repository, run the following command in a
+   terminal to build and run the application:
+
+   ```console
+   $ docker compose up
+   ```
+
+   The first time you run this command, Docker pulls the
+   model from Docker Hub, which may take some time.
+
+2. Visit [http://localhost:8080](http://localhost:8080). Enter a correct or
+   incorrect fact in the prompt and hit enter. An agent searches DuckDuckGo to
+   verify it and another agent revises the output.
+
+   ![Screenshot of the application](./images/agentic-ai-app.png)
+
+3. Press ctrl-c in the terminal to stop the application when you're done.
+
+## Step 3: Review the application environment
+
+You can find the `compose.yaml` file in the `adk/` directory. Open it in a text
+editor to see how the services are defined.
+
+```yaml {collapse=true,title=compose.yaml}
+services:
+  adk:
+    build:
+      context: .
+    ports:
+      # expose port for web interface
+      - "8080:8080"
+    environment:
+      # point adk at the MCP gateway
+      - MCPGATEWAY_ENDPOINT=http://mcp-gateway:8811/sse
+    depends_on:
+      - mcp-gateway
+    models:
+      gemma3:
+        endpoint_var: MODEL_RUNNER_URL
+        model_var: MODEL_RUNNER_MODEL
+
+  mcp-gateway:
+    # mcp-gateway secures your MCP servers
+    image: docker/mcp-gateway:latest
+    use_api_socket: true
+    command:
+      - --transport=sse
+      # add any MCP servers you want to use
+      - --servers=duckduckgo
+
+models:
+  gemma3:
+    # pre-pull the model when starting Docker Model Runner
+    model: ai/gemma3:4B-Q4_0
+    context_size: 10000 # 3.5 GB VRAM
+    # increase context size to handle search results
+    # context_size: 131000 # 7.6 GB VRAM
+```
+
+The app consists of three main components:
+
+- The `adk` service, which is the web application that runs the agentic AI
+  application. This service talks to the MCP gateway and model.
+- The `mcp-gateway` service, which is the MCP gateway that connects the app
+  to external tools and services.
+- The `models` block, which defines the model to use with the application.
+
+When you examine the `compose.yaml` file, you'll notice two notable elements for the model:
+
+- A service‑level `models` block in the `adk` service
+- A top-level `models` block
+
+These two blocks together let Docker Compose automatically start and connect
+your ADK web app to the specified LLM.
+
+> [!TIP]
+>
+> Looking for more models to use? Check out the [Docker AI Model
+> Catalog](https://hub.docker.com/catalogs/models/).
+
+When examining the `compose.yaml` file, you'll notice the gateway service is a
+Docker-maintained image,
+[`docker/mcp-gateway:latest`](https://hub.docker.com/r/docker/agents_gateway).
+This image is Docker's open source [MCP
+Gateway](https://github.com/docker/docker-mcp/) that enables your application to
+connect to MCP servers, which expose tools that models can call. In this
+example, it uses the [`duckduckgo` MCP
+server](https://hub.docker.com/mcp/server/duckduckgo/overview) to perform web
+searches.
+
+> [!TIP]
+>
+> Looking for more MCP servers to use? Check out the [Docker MCP
+> Catalog](https://hub.docker.com/catalogs/mcp/).
+
+With only a few lines of instructions in a Compose file, you're able to run and
+connect all the necessary services of an agentic AI application.
+
+In addition to the Compose file, the Dockerfile and the
+`entrypoint.sh` script it creates, play a role in wiring up the AI stack at build and
+runtime. You can find the `Dockerfile` in the `adk/` directory. Open it in a
+text editor.
+
+```dockerfile {collapse=true,title=Dockerfile}
+# Use Python 3.11 slim image as base
+FROM python:3.13-slim
+ENV PYTHONUNBUFFERED=1
+
+RUN pip install uv
+
+WORKDIR /app
+# Install system dependencies
+COPY pyproject.toml uv.lock ./
+RUN --mount=type=cache,target=/root/.cache/uv \
+    UV_COMPILE_BYTECODE=1 UV_LINK_MODE=copy \
+    uv pip install --system .
+# Copy application code
+COPY agents/ ./agents/
+RUN python -m compileall -q .
+
+COPY <<EOF /entrypoint.sh
+#!/bin/sh
+set -e
+
+if test -f /run/secrets/openai-api-key; then
+    export OPENAI_API_KEY=$(cat /run/secrets/openai-api-key)
+fi
+
+if test -n "\${OPENAI_API_KEY}"; then
+    echo "Using OpenAI with \${OPENAI_MODEL_NAME}"
+else
+    echo "Using Docker Model Runner with \${MODEL_RUNNER_MODEL}"
+    export OPENAI_BASE_URL=\${MODEL_RUNNER_URL}
+    export OPENAI_MODEL_NAME=openai/\${MODEL_RUNNER_MODEL}
+    export OPENAI_API_KEY=cannot_be_empty
+fi
+exec adk web --host 0.0.0.0 --port 8080 --log_level DEBUG
+EOF
+RUN chmod +x /entrypoint.sh
+
+# Create non-root user
+RUN useradd --create-home --shell /bin/bash app \
+    && chown -R app:app /app
+USER app
+
+ENTRYPOINT [ "/entrypoint.sh" ]
+```
+
+The `entrypoint.sh` has five key environment variables:
+
+- `MODEL_RUNNER_URL`: Injected by Compose (via the service-level `models:`
+  block) to point at your Docker Model Runner HTTP endpoint.
+
+- `MODEL_RUNNER_MODEL`: Injected by Compose to select which model to launch in
+  Model Runner.
+
+- `OPENAI_API_KEY`: If you define an `openai-api-key` secret in your Compose
+  file, Compose will mount it at `/run/secrets/openai-api-key`. The entrypoint
+  script reads that file and exports it as `OPENAI_API_KEY`, causing the app to
+  use hosted OpenAI instead of Model Runner.
+
+- `OPENAI_BASE_URL`: When no real key is present, this is set to
+  `MODEL_RUNNER_URL` so the ADK's OpenAI-compatible client sends requests to
+  Docker Model Runner.
+
+- `OPENAI_MODEL_NAME`: When falling back to Model Runner, the model is prefixed
+  with `openai/` so the client picks up the right model alias.
+
+Together, these variables let the same ADK web server code seamlessly target either:
+
+- Hosted OpenAI: if you supply `OPENAI_API_KEY` (and optionally `OPENAI_MODEL_NAME`)
+- Model Runner: by remapping `MODEL_RUNNER_URL` and `MODEL_RUNNER_MODEL` into the OpenAI client’s expected variables
+
+## Step 4: Review the application
+
+The `adk` web application is an agent implementation that connects to the MCP
+gateway and a model through environment variables and API calls. It uses the
+[ADK (Agent Development Kit)](https://github.com/google/adk-python) to define a
+root agent named Auditor, which coordinates two sub-agents, Critic and Reviser,
+to verify and refine model-generated answers.
+
+The three agents are:
+
+- Critic: Verifies factual claims using the toolset, such as DuckDuckGo.
+- Reviser: Edits answers based on the verification verdicts provided by the Critic.
+- Auditor: A higher-level agent that sequences the
+  Critic and Reviser. It acts as the entry point, evaluating LLM-generated
+  answers, verifying them, and refining the final output.
+
+All of the application's behavior is defined in Python under the `agents/`
+directory. Here's a breakdown of the notable files:
+
+- `agents/agent.py`: Defines the Auditor, a SequentialAgent that chains together
+  the Critic and Reviser agents. This agent is the main entry point of the
+  application and is responsible for auditing LLM-generated content using
+  real-world verification tools.
+
+- `agents/sub_agents/critic/agent.py`: Defines the Critic agent. It loads the
+  language model (via Docker Model Runner), sets the agent’s name and behavior,
+  and connects to MCP tools (like DuckDuckGo).
+
+- `agents/sub_agents/critic/prompt.py`: Contains the Critic prompt, which
+  instructs the agent to extract and verify claims using external tools.
+
+- `agents/sub_agents/critic/tools.py`: Defines the MCP toolset configuration,
+  including parsing `mcp/` strings, creating tool connections, and handling MCP
+  gateway communication.
+
+- `agents/sub_agents/reviser/agent.py`: Defines the Reviser agent, which takes
+  the Critic’s findings and minimally rewrites the original answer. It also
+  includes callbacks to clean up the LLM output and ensure it's in the right
+  format.
+
+- `agents/sub_agents/reviser/prompt.py`: Contains the Reviser prompt, which
+  instructs the agent to revise the answer text based on the verified claim
+  verdicts.
+
+The MCP gateway is configured via the `MCPGATEWAY_ENDPOINT` environment
+variable. In this case, `http://mcp-gateway:8811/sse`. This allows the app to
+use Server-Sent Events (SSE) to communicate with the MCP gateway container,
+which itself brokers access to external tool services like DuckDuckGo.
+
+## Summary
+
+Agent-based AI applications are emerging as a powerful new software
+architecture. In this guide, you explored a modular, chain-of-thought system
+where an Auditor agent coordinates the work of a Critic and a Reviser to
+fact-check and refine model-generated answers. This architecture shows how to
+combine local model inference with external tool integrations in a structured,
+modular way.
+
+You also saw how Docker simplifies this process by providing a suite of tools
+that support agentic AI development:
+
+- [Docker Model Runner](../manuals/ai/model-runner/_index.md): Run and serve
+  open-source models locally via OpenAI-compatible APIs.
+- [Docker MCP Catalog and
+  Toolkit](../manuals/ai/mcp-catalog-and-toolkit/_index.md): Launch and manage
+  tool integrations that follow the Model Context Protocol (MCP) standard.
+- [Docker MCP Gateway](../manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md): Orchestrate and manage
+  MCP servers to connect agents to external tools and services.
+- [Docker Compose](/manuals/ai/compose/models-and-compose.md): Define and run
+  multi-container agentic AI applications with a single file, using the same
+  workflow.
+
+With these tools, you can develop and test agentic AI applications efficiently,
+using the same consistent workflow throughout.
diff --git a/content/guides/angular.md b/content/guides/angular.md
new file mode 100644
index 000000000000..df8b2109ca51
--- /dev/null
+++ b/content/guides/angular.md
@@ -0,0 +1,805 @@
+---
+title: Angular language-specific guide
+linkTitle: Angular
+description: Containerize and develop Angular apps using Docker
+keywords: getting started, angular, docker, language, Dockerfile
+summary: |
+  This guide explains how to containerize Angular applications using Docker.
+aliases:
+  - /guides/angular/configure-github-actions/
+  - /guides/angular/containerize/
+  - /guides/angular/deploy/
+  - /guides/angular/develop/
+  - /guides/angular/run-tests/
+params:
+  tags: [languages]
+  time: 20 minutes
+---
+
+The Angular language-specific guide shows you how to containerize an Angular application using Docker, following best practices for creating efficient, production-ready containers.
+
+[Angular](https://angular.dev/) is a robust and widely adopted framework for building dynamic, enterprise-grade web applications. However, managing dependencies, environments, and deployments can become complex as applications scale. Docker streamlines these challenges by offering a consistent, isolated environment for development and production.
+
+> **Acknowledgment**
+>
+> Docker extends its sincere gratitude to [Kristiyan Velkov](https://www.linkedin.com/in/kristiyan-velkov-763130b3/) for authoring this guide. As a Docker Captain and experienced Front-end engineer, his expertise in Docker, DevOps, and modern web development has made this resource essential for the community, helping developers navigate and optimize their Docker workflows.
+
+---
+
+## What will you learn?
+
+In this guide, you will learn how to:
+
+- Containerize and run an Angular application using Docker.
+- Set up a local development environment for Angular inside a container.
+- Run tests for your Angular application within a Docker container.
+
+You'll start by containerizing an existing Angular application and work your way up to production-level deployments.
+
+---
+
+## Prerequisites
+
+Before you begin, ensure you have a working knowledge of:
+
+- Basic understanding of [TypeScript](https://www.typescriptlang.org/) and [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript).
+- Familiarity with [Node.js](https://nodejs.org/en) and [npm](https://docs.npmjs.com/about-npm) for managing dependencies and running scripts.
+- Familiarity with [Angular](https://angular.io/) fundamentals.
+- Understanding of core Docker concepts such as images, containers, and Dockerfiles. If you're new to Docker, start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
+
+Once you've completed the Angular getting started modules, you’ll be fully prepared to containerize your own Angular application using the detailed examples and best practices outlined in this guide.
+
+## Containerize an Angular Application
+
+### Prerequisites
+
+Before you begin, make sure the following tools are installed and available on your system:
+
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
+- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
+
+> **New to Docker?**  
+> Start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide to get familiar with key concepts like images, containers, and Dockerfiles.
+
+---
+
+### Overview
+
+This guide walks you through the complete process of containerizing an Angular application with Docker. You’ll learn how to create a production-ready Docker image using best practices that improve performance, security, scalability, and deployment efficiency.
+
+By the end of this guide, you will:
+
+- Containerize an Angular application using Docker.
+- Create and optimize a Dockerfile for production builds.
+- Use multi-stage builds to minimize image size.
+- Serve the application efficiently with a custom Nginx configuration.
+- Build secure and maintainable Docker images by following best practices.
+
+---
+
+### Get the sample application
+
+Clone the sample application to use with this guide. Open a terminal, navigate to the directory where you want to work, and run the following command
+to clone the git repository:
+
+```console
+$ git clone https://github.com/kristiyan-velkov/docker-angular-sample
+```
+
+---
+
+### Build the Docker image
+
+Angular is a front-end framework that compiles into static assets, so the Dockerfile uses a multi-stage build: one stage compiles the app with Node.js, and a second minimal stage serves the static output with Nginx.
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for your project. Ask Gordon to create a Dockerfile, Compose file, and `.dockerignore` tailored to your application.
+
+#### Step 1: Create the Dockerfile
+
+Before creating a Dockerfile, you need to choose a base image. You can either use the [Node.js Official Image](https://hub.docker.com/_/node) or a Docker Hardened Image (DHI) from the [Hardened Image catalog](https://hub.docker.com/hardened-images/catalog).
+
+Choosing DHI offers the advantage of a production-ready image that is lightweight and secure. For more information, see [Docker Hardened Images](https://docs.docker.com/dhi/).
+
+> [!IMPORTANT]
+> This guide uses a stable Node.js LTS image tag that is considered secure when the guide is written. Because new releases and security patches are published regularly, the tag shown here may no longer be the safest option when you follow the guide. Always review the latest available image tags and select a secure, up-to-date version before building or deploying your application.
+>
+> Official Node.js Docker Images: https://hub.docker.com/_/node
+
+{{< tabs >}}
+{{< tab name="Using Docker Hardened Images" >}}
+Docker Hardened Images (DHIs) are available for Node.js in the [Docker Hardened Images catalog](https://hub.docker.com/hardened-images/catalog/dhi/node). Docker Hardened Images are freely available to everyone with no subscription required. You can pull and use them like any other Docker image after signing in to the DHI registry. For more information, see the [DHI quickstart](/dhi/get-started/) guide.
+
+1. Sign in to the DHI registry:
+
+   ```console
+   $ docker login dhi.io
+   ```
+
+2. Pull the Node.js DHI (check the catalog for available versions):
+   ```console
+   $ docker pull dhi.io/node:24-alpine3.22-dev
+   ```
+
+In the following Dockerfile, the `FROM` instruction uses `dhi.io/node:24-alpine3.22-dev` as the base image.
+
+```dockerfile
+# =========================================
+# Stage 1: Build the Angular Application
+# =========================================
+
+# Use a lightweight DHI Node.js image for building
+FROM dhi.io/node:24-alpine3.22-dev AS builder
+
+# Set the working directory inside the container
+WORKDIR /app
+
+# Copy package-related files first to leverage Docker's caching mechanism
+COPY package.json package-lock.json* ./
+
+# Install project dependencies using npm ci (ensures a clean, reproducible install)
+RUN --mount=type=cache,target=/root/.npm npm ci
+
+# Copy the rest of the application source code into the container
+COPY . .
+
+# Build the Angular application
+RUN npm run build
+
+# =========================================
+# Stage 2: Prepare Nginx to Serve Static Files
+# =========================================
+
+FROM dhi.io/nginx:1.28.0-alpine3.21-dev AS runner
+
+# Copy custom Nginx config
+COPY nginx.conf /etc/nginx/nginx.conf
+
+# Copy the static build output from the build stage to Nginx's default HTML serving directory
+COPY --chown=nginx:nginx --from=builder /app/dist/*/browser /usr/share/nginx/html
+
+# Use a non-root user for security best practices
+USER nginx
+
+# Expose port 8080 to allow HTTP traffic
+# Note: The default Nginx container now listens on port 8080 instead of 80
+EXPOSE 8080
+
+# Start Nginx directly with custom config
+ENTRYPOINT ["nginx", "-c", "/etc/nginx/nginx.conf"]
+CMD ["-g", "daemon off;"]
+```
+
+{{< /tab >}}
+{{< tab name="Using the Docker Official Image" >}}
+
+Create a file named `Dockerfile` with the following contents:
+
+```dockerfile
+# =========================================
+# Stage 1: Build the Angular Application
+# =========================================
+ARG NODE_VERSION=24.12.0-alpine
+ARG NGINX_VERSION=alpine3.22
+
+# Use a lightweight Node.js image for building (customizable via ARG)
+FROM node:${NODE_VERSION} AS builder
+
+# Set the working directory inside the container
+WORKDIR /app
+
+# Copy package-related files first to leverage Docker's caching mechanism
+COPY package.json *package-lock.json* ./
+
+# Install project dependencies using npm ci (ensures a clean, reproducible install)
+RUN --mount=type=cache,target=/root/.npm npm ci
+
+# Copy the rest of the application source code into the container
+COPY . .
+
+# Build the Angular application
+RUN npm run build
+
+# =========================================
+# Stage 2: Prepare Nginx to Serve Static Files
+# =========================================
+
+FROM nginxinc/nginx-unprivileged:${NGINX_VERSION} AS runner
+
+# Copy custom Nginx config
+COPY nginx.conf /etc/nginx/nginx.conf
+
+# Copy the static build output from the build stage to Nginx's default HTML serving directory
+COPY --chown=nginx:nginx --from=builder /app/dist/*/browser /usr/share/nginx/html
+
+# Use a built-in non-root user for security best practices
+USER nginx
+
+# Expose port 8080 to allow HTTP traffic
+# Note: The default Nginx container now listens on port 8080 instead of 80
+EXPOSE 8080
+
+# Start Nginx directly with custom config
+ENTRYPOINT ["nginx", "-c", "/etc/nginx/nginx.conf"]
+CMD ["-g", "daemon off;"]
+```
+
+> [!NOTE]
+> We are using nginx-unprivileged instead of the standard Nginx image to follow security best practices.
+> Running as a non-root user in the final image:
+>
+> - Reduces the attack surface
+> - Aligns with Docker’s recommendations for container hardening
+> - Helps comply with stricter security policies in production environments
+
+{{< /tab >}}
+{{< /tabs >}}
+
+#### Step 2: Create the compose.yaml file
+
+Create a file named `compose.yaml` with the following contents:
+
+```yaml {collapse=true,title=compose.yaml}
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 8080:8080
+```
+
+#### Step 3: Create the .dockerignore file
+
+The `.dockerignore` file tells Docker which files and folders to exclude when building the image.
+
+> [!NOTE]
+> This helps:
+>
+> - Reduce image size
+> - Speed up the build process
+> - Prevent sensitive or unnecessary files (like `.env`, `.git`, or `node_modules`) from being added to the final image.
+>
+> To learn more, visit the [.dockerignore reference](/reference/dockerfile.md#dockerignore-file).
+
+Create a file named `.dockerignore` with the following contents:
+
+```dockerignore
+# ================================
+# Node and build output
+# ================================
+node_modules
+dist
+out-tsc
+.angular
+.cache
+.tmp
+
+# ================================
+# Testing & Coverage
+# ================================
+coverage
+jest
+cypress
+cypress/screenshots
+cypress/videos
+reports
+playwright-report
+.vite
+.vitepress
+
+# ================================
+# Environment & log files
+# ================================
+*.env*
+!*.env.production
+*.log
+*.tsbuildinfo
+
+# ================================
+# IDE & OS-specific files
+# ================================
+.vscode
+.idea
+.DS_Store
+Thumbs.db
+*.swp
+
+# ================================
+# Version control & CI files
+# ================================
+.git
+.gitignore
+
+# ================================
+# Docker & local orchestration
+# ================================
+Dockerfile
+Dockerfile.*
+.dockerignore
+docker-compose.yml
+docker-compose*.yml
+
+# ================================
+# Miscellaneous
+# ================================
+*.bak
+*.old
+*.tmp
+```
+
+#### Step 4: Create the `nginx.conf` file
+
+To serve your Angular application efficiently inside the container, you’ll configure Nginx with a custom setup. This configuration is optimized for performance, browser caching, gzip compression, and support for client-side routing.
+
+Create a file named `nginx.conf` in the root of your project directory, and add the following content:
+
+> [!NOTE]
+> To learn more about configuring Nginx, see the [official Nginx documentation](https://nginx.org/en/docs/).
+
+```nginx
+worker_processes auto;
+
+pid /tmp/nginx.pid;
+
+events {
+    worker_connections 1024;
+}
+
+http {
+    include       /etc/nginx/mime.types;
+    default_type  application/octet-stream;
+
+    client_body_temp_path /tmp/client_temp;
+    proxy_temp_path       /tmp/proxy_temp_path;
+    fastcgi_temp_path     /tmp/fastcgi_temp;
+    uwsgi_temp_path       /tmp/uwsgi_temp;
+    scgi_temp_path        /tmp/scgi_temp;
+
+    # Logging
+    access_log off;
+    error_log  /dev/stderr warn;
+
+    # Performance
+    sendfile        on;
+    tcp_nopush      on;
+    tcp_nodelay     on;
+    keepalive_timeout  65;
+    keepalive_requests 1000;
+
+    # Compression
+    gzip on;
+    gzip_vary on;
+    gzip_proxied any;
+    gzip_min_length 256;
+    gzip_comp_level 6;
+    gzip_types
+        text/plain
+        text/css
+        text/xml
+        text/javascript
+        application/javascript
+        application/x-javascript
+        application/json
+        application/xml
+        application/xml+rss
+        font/ttf
+        font/otf
+        image/svg+xml;
+
+    server {
+        listen       8080;
+        server_name  localhost;
+
+        root /usr/share/nginx/html;
+        index index.html;
+
+        # Angular Routing
+        location / {
+            try_files $uri $uri/ /index.html;
+        }
+
+        # Static Assets Caching
+        location ~* \.(?:ico|css|js|gif|jpe?g|png|woff2?|eot|ttf|svg|map)$ {
+            expires 1y;
+            access_log off;
+            add_header Cache-Control "public, immutable";
+        }
+
+        # Optional: Explicit asset route
+        location /assets/ {
+            expires 1y;
+            add_header Cache-Control "public, immutable";
+        }
+    }
+}
+```
+
+#### Step 5: Build the Angular application image
+
+With your custom configuration in place, you're now ready to build the Docker image for your Angular application.
+
+The updated setup includes:
+
+- The updated setup includes a clean, production-ready Nginx configuration tailored specifically for Angular.
+- Efficient multi-stage Docker build, ensuring a small and secure final image.
+
+After completing the previous steps, your project directory should now contain the following files:
+
+```text
+├── docker-angular-sample/
+│ ├── Dockerfile
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ └── nginx.conf
+```
+
+Now that your Dockerfile is configured, you can build the Docker image for your Angular application.
+
+> [!NOTE]
+> The `docker build` command packages your application into an image using the instructions in the Dockerfile. It includes all necessary files from the current directory (called the [build context](/build/concepts/context/#what-is-a-build-context)).
+
+Run the following command from the root of your project:
+
+```console
+$ docker build --tag docker-angular-sample .
+```
+
+What this command does:
+
+- Uses the Dockerfile in the current directory (.)
+- Packages the application and its dependencies into a Docker image
+- Tags the image as docker-angular-sample so you can reference it later
+
+#### Step 6: View local images
+
+After building your Docker image, you can check which images are available on your local machine using either the Docker CLI or [Docker Desktop](/manuals/desktop/use-desktop/images.md). Since you're already working in the terminal, let's use the Docker CLI.
+
+To list all locally available Docker images, run the following command:
+
+```console
+$ docker images
+```
+
+Example Output:
+
+```shell
+REPOSITORY                TAG               IMAGE ID       CREATED         SIZE
+docker-angular-sample     latest            34e66bdb9d40   14 seconds ago   76.4MB
+```
+
+This output provides key details about your images:
+
+- **Repository** – The name assigned to the image.
+- **Tag** – A version label that helps identify different builds (e.g., latest).
+- **Image ID** – A unique identifier for the image.
+- **Created** – The timestamp indicating when the image was built.
+- **Size** – The total disk space used by the image.
+
+If the build was successful, you should see `docker-angular-sample` image listed.
+
+---
+
+### Run the containerized application
+
+In the previous step, you created a Dockerfile for your Angular application and built a Docker image using the docker build command. Now it’s time to run that image in a container and verify that your application works as expected.
+
+Inside the `docker-angular-sample` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple Angular web application.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `docker-angular-sample` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see your Angular application running in the browser.
+
+To confirm that the container is running, use `docker ps` command:
+
+```console
+$ docker ps
+```
+
+This will list all active containers along with their ports, names, and status. Look for a container exposing port 8080.
+
+Example Output:
+
+```shell
+CONTAINER ID   IMAGE                          COMMAND                  CREATED             STATUS             PORTS                    NAMES
+eb13026806d1   docker-angular-sample-server   "nginx -c /etc/nginx…"   About a minute ago  Up About a minute  0.0.0.0:8080->8080/tcp   docker-angular-sample-server-1
+```
+
+To stop the application, run:
+
+```console
+$ docker compose down
+```
+
+> [!NOTE]
+> For more information about Compose commands, see the [Compose CLI
+> reference](/reference/cli/docker/compose/).
+
+---
+
+## Use containers for Angular development
+
+### Prerequisites
+
+Complete [Containerize Angular application](#containerize-an-angular-application).
+
+---
+
+### Overview
+
+In this section, you'll learn how to set up both production and development environments for your containerized Angular application using Docker Compose. This setup allows you to serve a static production build via Nginx and to develop efficiently inside containers using a live-reloading dev server with Compose Watch.
+
+You’ll learn how to:
+
+- Configure separate containers for production and development
+- Enable automatic file syncing using Compose Watch in development
+- Debug and live-preview your changes in real-time without manual rebuilds
+
+---
+
+### Automatically update services (development mode)
+
+Use Compose Watch to automatically sync source file changes into your containerized development environment. This provides a seamless, efficient development experience without restarting or rebuilding containers manually.
+
+### Step 1: Create a development Dockerfile
+
+Create a file named `Dockerfile.dev` in your project root with the following content:
+
+```dockerfile
+# =========================================
+# Stage 1: Development - Angular Application
+# =========================================
+
+# Define the Node.js version to use (Alpine for a small footprint)
+ARG NODE_VERSION=24.12.0-alpine
+
+# Set the base image for development
+FROM node:${NODE_VERSION} AS dev
+
+# Set environment variable to indicate development mode
+ENV NODE_ENV=development
+
+# Set the working directory inside the container
+WORKDIR /app
+
+# Copy only the dependency files first to optimize Docker caching
+COPY package.json package-lock.json* ./
+
+# Install dependencies using npm with caching to speed up subsequent builds
+RUN --mount=type=cache,target=/root/.npm npm install
+
+# Copy all application source files into the container
+COPY . .
+
+# Expose the port Angular uses for the dev server (default is 4200)
+EXPOSE 4200
+
+# Start the Angular dev server and bind it to all network interfaces
+CMD ["npm", "start", "--", "--host=0.0.0.0"]
+
+```
+
+This file sets up a lightweight development environment for your Angular application using the dev server.
+
+#### Step 2: Update your `compose.yaml` file
+
+Open your `compose.yaml` file and define two services: one for production (`angular-prod`) and one for development (`angular-dev`).
+
+Here’s an example configuration for an Angular application:
+
+```yaml
+services:
+  angular-prod:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: docker-angular-sample
+    ports:
+      - "8080:8080"
+
+  angular-dev:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    ports:
+      - "4200:4200"
+    develop:
+      watch:
+        - action: sync
+          path: .
+          target: /app
+```
+
+- The `angular-prod` service builds and serves your static production app using Nginx.
+- The `angular-dev` service runs your Angular development server with live reload and hot module replacement.
+- `watch` triggers file sync with Compose Watch.
+
+> [!NOTE]
+> For more details, see the official guide: [Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
+
+After completing the previous steps, your project directory should now contain the following files:
+
+```text
+├── docker-angular-sample/
+│ ├── Dockerfile
+│ ├── Dockerfile.dev
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ └── nginx.conf
+```
+
+#### Step 4: Start Compose Watch
+
+Run the following command from the project root to start the container in watch mode
+
+```console
+$ docker compose watch angular-dev
+```
+
+#### Step 5: Test Compose Watch with Angular
+
+To verify that Compose Watch is working correctly:
+
+1. Open the `src/app/app.component.html` file in your text editor.
+
+2. Locate the following line:
+
+   ```html
+   <h1>Docker Angular Sample Application</h1>
+   ```
+
+3. Change it to:
+
+   ```html
+   <h1>Hello from Docker Compose Watch</h1>
+   ```
+
+4. Save the file.
+
+5. Open your browser at [http://localhost:4200](http://localhost:4200).
+
+You should see the updated text appear instantly, without needing to rebuild the container manually. This confirms that file watching and automatic synchronization are working as expected.
+
+---
+
+## Run Angular tests in a container
+
+### Prerequisites
+
+Complete all the previous sections of this guide, starting with [Containerize Angular application](#containerize-an-angular-application).
+
+### Overview
+
+Testing is a critical part of the development process. In this section, you'll learn how to:
+
+- Run Jasmine unit tests using the Angular CLI inside a Docker container.
+- Use Docker Compose to isolate your test environment.
+- Ensure consistency between local and container-based testing.
+
+The `docker-angular-sample` project comes pre-configured with Jasmine, so you can get started quickly without extra setup.
+
+---
+
+### Run tests during development
+
+The `docker-angular-sample` application includes a sample test file at the following location:
+
+```console
+$ src/app/app.component.spec.ts
+```
+
+This test uses Jasmine to validate the AppComponent logic.
+
+#### Step 1: Update compose.yaml
+
+Add a new service named `angular-test` to your `compose.yaml` file. This service allows you to run your test suite in an isolated, containerized environment.
+
+```yaml {hl_lines="22-26",linenos=true}
+services:
+  angular-dev:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    ports:
+      - "5173:5173"
+    develop:
+      watch:
+        - action: sync
+          path: .
+          target: /app
+
+  angular-prod:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: docker-angular-sample
+    ports:
+      - "8080:8080"
+
+  angular-test:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    command: ["npm", "run", "test"]
+```
+
+The angular-test service reuses the same `Dockerfile.dev` used for [development](#use-containers-for-angular-development) and overrides the default command to run tests with `npm run test`. This setup ensures a consistent test environment that matches your local development configuration.
+
+After completing the previous steps, your project directory should contain the following files:
+
+```text
+├── docker-angular-sample/
+│ ├── Dockerfile
+│ ├── Dockerfile.dev
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ └── nginx.conf
+```
+
+#### Step 2: Run the tests
+
+To execute your test suite inside the container, run the following command from your project root:
+
+```console
+$ docker compose run --rm angular-test
+```
+
+This command will:
+
+- Start the `angular-test` service defined in your `compose.yaml` file.
+- Execute the `npm run test` script using the same environment as development.
+- Automatically removes the container after tests complete, using the [`docker compose run --rm`](/reference/cli/docker/compose/run/) command.
+
+You should see output similar to the following:
+
+```shell
+Test Suites: 1 passed, 1 total
+Tests:       3 passed, 3 total
+Snapshots:   0 total
+Time:        1.529 s
+```
+
+> [!NOTE]
+> For more information about Compose commands, see the [Compose CLI
+> reference](/reference/cli/docker/compose/).
+
+---
+
+### Summary
+
+In this section, you learned how to run unit tests for your Angular application inside a Docker container using Jasmine and Docker Compose.
+
+What you accomplished:
+
+- Created a `angular-test` service in `compose.yaml` to isolate test execution.
+- Reused the development `Dockerfile.dev` to ensure consistency between dev and test environments.
+- Ran tests inside the container using `docker compose run --rm angular-test`.
+- Ensured reliable, repeatable testing across environments without depending on your local machine setup.
+
+---
+
+### Related resources
+
+Explore official references and best practices to sharpen your Docker testing workflow:
+
+- [Dockerfile reference](/reference/dockerfile/) – Understand all Dockerfile instructions and syntax.
+- [Best practices for writing Dockerfiles](/develop/develop-images/dockerfile_best-practices/) – Write efficient, maintainable, and secure Dockerfiles.
+- [Compose file reference](/compose/compose-file/) – Learn the full syntax and options available for configuring services in `compose.yaml`.
+- [`docker compose run` CLI reference](/reference/cli/docker/compose/run/) – Run one-off commands in a service container.
diff --git a/content/guides/azure-pipelines.md b/content/guides/azure-pipelines.md
new file mode 100644
index 000000000000..098cfd319f01
--- /dev/null
+++ b/content/guides/azure-pipelines.md
@@ -0,0 +1,312 @@
+---
+title: Introduction to Azure Pipelines with Docker
+linkTitle: Azure Pipelines and Docker
+summary: |
+  Learn how to automate Docker image build and push using Azure Pipelines.
+keywords: azure pipelines, azure devops, ci/cd, docker hub, build and push, automation
+params:
+  tags: [cicd]
+  time: 10 minutes
+---
+
+> This guide is a community contribution. Docker would like to thank [Kristiyan Velkov](https://www.linkedin.com/in/kristiyan-velkov-763130b3/) for his valuable contribution.
+
+## Prerequisites
+
+Before you begin, ensure you have the following requirements:
+
+- A [Docker Hub account](https://hub.docker.com) with a generated access token.
+- An active [Azure DevOps project](https://dev.azure.com/) with a connected [Git repository](https://learn.microsoft.com/en-us/azure/devops/repos/git/?view=azure-devops).
+- A project that includes a valid [`Dockerfile`](https://docs.docker.com/engine/reference/builder/) at its root or appropriate build context.
+
+## Overview
+
+This guide walks you through building and pushing Docker images using [Azure Pipelines](https://azure.microsoft.com/en-us/products/devops/pipelines), enabling a streamlined and secure CI workflow for containerized applications. You’ll learn how to:
+
+- Configure Docker authentication securely.
+- Set up an automated pipeline to build and push images.
+
+## Set up Azure DevOps to work with Docker Hub
+
+### Step 1: Configure a Docker Hub service connection
+
+To securely authenticate with Docker Hub using Azure Pipelines:
+
+1. Navigate to **Project Settings > Service Connections** in your Azure DevOps project.
+2. Select **New service connection > Docker Registry**.
+3. Choose **Docker Hub** and provide your Docker Hub credentials or access token.
+4. Give the service connection a recognizable name, such as `my-docker-registry`.
+5. Grant access only to the specific pipeline(s) that require it for improved security and least privilege.
+
+> [!IMPORTANT]
+>
+> Avoid selecting the option to grant access to all pipelines unless absolutely necessary. Always apply the principle of least privilege.
+
+### Step 2: Create your pipeline
+
+Add the following `azure-pipelines.yml` file to the root of your repository:
+
+```yaml
+# Trigger pipeline on commits to the main branch
+trigger:
+  - main
+
+# Trigger pipeline on pull requests targeting the main branch
+pr:
+  - main
+
+# Define variables for reuse across the pipeline
+variables:
+  imageName: 'docker.io/$(dockerUsername)/my-image'
+  buildTag: '$(Build.BuildId)'
+  latestTag: 'latest'
+
+stages:
+  - stage: BuildAndPush
+    displayName: Build and Push Docker Image
+    jobs:
+      - job: DockerJob
+        displayName: Build and Push
+        pool:
+          vmImage: ubuntu-latest
+          demands:
+            - docker
+        steps:
+          - checkout: self
+            displayName: Checkout Code
+
+          - task: Docker@2
+            displayName: Docker Login
+            inputs:
+              command: login
+              containerRegistry: 'my-docker-registry'  # Service connection name
+
+          - task: Docker@2
+            displayName: Build Docker Image
+            inputs:
+              command: build
+              repository: $(imageName)
+              tags: |
+                $(buildTag)
+                $(latestTag)
+              dockerfile: './Dockerfile'
+              arguments: |
+                --sbom=true
+                --attest type=provenance
+                --cache-from $(imageName):latest
+            env:
+              DOCKER_BUILDKIT: 1
+
+          - task: Docker@2
+            displayName: Push Docker Image
+            condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
+            inputs:
+              command: push
+              repository: $(imageName)
+              tags: |
+                $(buildTag)
+                $(latestTag)
+
+          # Optional: logout for self-hosted agents
+          - script: docker logout
+            displayName: Docker Logout (Self-hosted only)
+            condition: ne(variables['Agent.OS'], 'Windows_NT')
+```
+
+## What this pipeline does
+
+This pipeline automates the Docker image build and deployment process for the main branch. It ensures a secure and efficient workflow with best practices like caching, tagging, and conditional cleanup. Here's what it does:
+
+- Triggers on commits and pull requests targeting the `main` branch.
+- Authenticates securely with Docker Hub using an Azure DevOps service connection.
+- Builds and tags the Docker image using Docker BuildKit for caching.
+- Pushes both buildId and latest tags to Docker Hub.
+- Logs out from Docker if running on a self-hosted Linux agent.
+
+
+## How the pipeline works
+
+### Step 1: Define pipeline triggers 
+
+```yaml
+trigger:
+  - main
+
+pr:
+  - main
+```
+
+This pipeline is triggered automatically on:
+- Commits pushed to the `main` branch
+- Pull requests targeting `main` main branch
+
+> [!TIP]
+> Learn more: [Define pipeline triggers in Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops)
+
+### Step 2: Define common variables
+
+```yaml
+variables:
+  imageName: 'docker.io/$(dockerUsername)/my-image'
+  buildTag: '$(Build.BuildId)'
+  latestTag: 'latest'
+```
+
+These variables ensure consistent naming, versioning, and reuse throughout the pipeline steps:
+
+- `imageName`: your image path on Docker Hub
+- `buildTag`: a unique tag for each pipeline run
+- `latestTag`: a stable alias for your most recent image
+
+> [!IMPORTANT]
+>
+> The variable `dockerUsername` is not set automatically.  
+> Set it securely in your Azure DevOps pipeline variables:  
+>   1. Go to **Pipelines > Edit > Variables**  
+>   2. Add `dockerUsername` with your Docker Hub username  
+>
+> Learn more: [Define and use variables in Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch)
+ 
+### Step 3: Define pipeline stages and jobs
+
+```yaml
+stages:
+  - stage: BuildAndPush
+    displayName: Build and Push Docker Image
+```
+
+This stage executes only if the source branch is `main`.
+
+> [!TIP]
+>
+> Learn more: [Stage conditions in Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/stages?view=azure-devops&tabs=yaml)
+
+
+### Step 4: Job configuration
+
+```yaml
+jobs:
+  - job: DockerJob
+  displayName: Build and Push
+  pool:
+    vmImage: ubuntu-latest
+    demands:
+      - docker
+```
+
+This job utilizes the latest Ubuntu VM image with Docker support, provided by Microsoft-hosted agents. It can be replaced with a custom pool for self-hosted agents if necessary.
+
+> [!TIP]
+>
+> Learn more: [Specify a pool in your pipeline](https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/pools-queues?view=azure-devops&tabs=yaml%2Cbrowser)
+
+#### Step 4.1: Checkout code
+
+```yaml
+steps:
+  - checkout: self
+    displayName: Checkout Code
+```
+
+This step pulls your repository code into the build agent, so the pipeline can access the Dockerfile and application files.
+
+> [!TIP]
+>
+> Learn more: [checkout step documentation](https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/steps-checkout?view=azure-pipelines)
+
+#### Step 4.2: Authenticate to Docker Hub
+
+```yaml
+- task: Docker@2
+  displayName: Docker Login
+  inputs:
+    command: login
+    containerRegistry: 'my-docker-registry'  # Replace with your service connection name
+```
+
+Uses a pre-configured Azure DevOps Docker registry service connection to authenticate securely without exposing credentials directly.
+
+> [!TIP]
+>
+> Learn more: [Use service connections for Docker Hub](https://learn.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops#docker-hub-or-others)
+
+#### Step 4.3: Build the Docker image
+
+```yaml
+ - task: Docker@2
+    displayName: Build Docker Image
+    inputs:
+      command: build
+      repository: $(imageName)
+      tags: |
+          $(buildTag)
+          $(latestTag)
+      dockerfile: './Dockerfile'
+      arguments: |
+          --sbom=true
+          --attest type=provenance
+          --cache-from $(imageName):latest
+    env:
+      DOCKER_BUILDKIT: 1
+```
+
+This builds the image with:
+
+- Two tags: one with the unique Build ID and one as latest
+- Docker BuildKit enabled for faster builds and efficient layer caching
+- Cache pull from the most recent pushed latest image
+- Software Bill of Materials (SBOM) for supply chain transparency
+- Provenance attestation to verify how and where the image was built
+
+> [!TIP]
+>
+> Learn more: 
+> - [Docker task for Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/docker-v2?view=azure-pipelines&tabs=yaml)
+> - [Docker SBOM Attestations](/manuals/build/metadata/attestations/slsa-provenance.md)
+
+#### Step 4.4: Push the Docker image
+
+```yaml
+- task: Docker@2
+  displayName: Push Docker Image
+  condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
+  inputs:
+      command: push
+      repository: $(imageName)
+      tags: |
+        $(buildTag)
+        $(latestTag)
+```
+
+By applying this condition, the pipeline builds the Docker image on every run to ensure early detection of issues, but only pushes the image to the registry when changes are merged into the main branch—keeping your Docker Hub clean and focused
+
+This uploads both tags to Docker Hub:
+- `$(buildTag)` ensures traceability per run.
+- `latest` is used for most recent image references.
+
+#### Step 4.5  Logout of Docker (self-hosted agents)
+
+```yaml
+- script: docker logout
+  displayName: Docker Logout (Self-hosted only)
+  condition: ne(variables['Agent.OS'], 'Windows_NT')
+```
+
+Executes docker logout at the end of the pipeline on Linux-based self-hosted agents to proactively clean up credentials and enhance security posture.
+
+## Summary
+
+With this Azure Pipelines CI setup, you get:
+
+- Secure Docker authentication using a built-in service connection.
+- Automated image building and tagging triggered by code changes.
+- Efficient builds leveraging Docker BuildKit cache.
+- Safe cleanup with logout on persistent agents.
+- Build images that meet modern software supply chain requirements with SBOM and attestation
+
+## Learn more
+
+- [Azure Pipelines Documentation](https://learn.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops): Comprehensive guide to configuring and managing CI/CD pipelines in Azure DevOps.
+- [Docker Task for Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/docker): Detailed reference for using the Docker task in Azure Pipelines to build and push images.
+- [Docker Buildx Bake](/manuals/build/bake/_index.md): Explore Docker's advanced build tool for complex, multi-stage, and multi-platform build setups. See also the [Mastering Buildx Bake Guide](/guides/bake/) for practical examples and best practices.
+- [Docker Build Cloud](/guides/docker-build-cloud/_index.md): Learn about Docker's managed build service for faster, scalable, and multi-platform image builds in the cloud.
diff --git a/content/guides/bake.md b/content/guides/bake.md
new file mode 100644
index 000000000000..9f70755bfa61
--- /dev/null
+++ b/content/guides/bake.md
@@ -0,0 +1,515 @@
+---
+title: Mastering multi-platform builds, testing, and more with Docker Buildx Bake
+linkTitle: Mastering Docker Buildx Bake
+description: >
+  Learn how to manage simple and complex build configurations with Buildx Bake.
+summary: >
+  Learn to automate Docker builds and testing with declarative configurations using Buildx Bake.
+keywords: bake, buildx, multi-platform, build configuration, hcl, automation
+params:
+  tags: [cicd]
+  time: 30 minutes
+  image: /images/guides/bake.webp
+---
+
+This guide demonstrates how to simplify and automate the process of building
+images, testing, and generating build artifacts using Docker Buildx Bake. By
+defining build configurations in a declarative `docker-bake.hcl` file, you can
+eliminate manual scripts and enable efficient workflows for complex builds,
+testing, and artifact generation.
+
+## Assumptions
+
+This guide assumes that you're familiar with:
+
+- Docker
+- [Buildx](/manuals/build/concepts/overview.md#buildx)
+- [BuildKit](/manuals/build/concepts/overview.md#buildkit)
+- [Multi-stage builds](/manuals/build/building/multi-stage.md)
+- [Multi-platform builds](/manuals/build/building/multi-platform.md)
+
+## Prerequisites
+
+- You have a recent version of Docker installed on your machine.
+- You have Git installed for cloning repositories.
+- You're using the [containerd](/manuals/desktop/features/containerd.md) image store.
+
+## Introduction
+
+This guide uses an example project to demonstrate how Docker Buildx Bake can
+streamline your build and test workflows. The repository includes both a
+Dockerfile and a `docker-bake.hcl` file, giving you a ready-to-use setup to try
+out Bake commands.
+
+Start by cloning the example repository:
+
+```bash
+git clone https://github.com/dvdksn/bakeme.git
+cd bakeme
+```
+
+The Bake file, `docker-bake.hcl`, defines the build targets in a declarative
+syntax, using targets and groups, allowing you to manage complex builds
+efficiently.
+
+Here's what the Bake file looks like out-of-the-box:
+
+```hcl
+target "default" {
+  target = "image"
+  tags = [
+    "bakeme:latest",
+  ]
+  attest = [
+    "type=provenance,mode=max",
+    "type=sbom",
+  ]
+  platforms = [
+    "linux/amd64",
+    "linux/arm64",
+    "linux/riscv64",
+  ]
+}
+```
+
+The `target` keyword defines a build target for Bake. The `default` target
+defines the target to build when no specific target is specified on the command
+line. Here's a quick summary of the options for the `default` target:
+
+- `target`: The target build stage in the Dockerfile.
+- `tags`: Tags to assign to the image.
+- `attest`: [Attestations](/manuals/build/metadata/attestations/_index.md) to attach to the image.
+
+  > [!TIP]
+  > The attestations provide metadata such as build provenance, which tracks
+  > the source of the image's build, and an SBOM (Software Bill of Materials),
+  > useful for security audits and compliance.
+
+- `platforms`: Platform variants to build.
+
+To execute this build, run the following command in the root of the
+repository:
+
+```console
+$ docker buildx bake
+```
+
+With Bake, you avoid long, hard-to-remember command-line incantations,
+simplifying build configuration management by replacing manual, error-prone
+scripts with a structured configuration file.
+
+For contrast, here's what this build command would look like without Bake:
+
+```console
+$ docker buildx build \
+  --target=image \
+  --tag=bakeme:latest \
+  --provenance=true \
+  --sbom=true \
+  --platform=linux/amd64,linux/arm64,linux/riscv64 \
+  .
+```
+
+## Testing and linting
+
+Bake isn't just for defining build configurations and running builds. You can
+also use Bake to run your tests, effectively using BuildKit as a task runner.
+Running your tests in containers is great for ensuring reproducible results.
+This section shows how to add two types of tests:
+
+- Unit testing with `go test`.
+- Linting for style violations with `golangci-lint`.
+
+In Test-Driven Development (TDD) fashion, start by adding a new `test` target
+to the Bake file:
+
+```hcl
+target "test" {
+  target = "test"
+  output = ["type=cacheonly"]
+}
+```
+
+> [!TIP]
+> Using `type=cacheonly` ensures that the build output is effectively
+> discarded; the layers are saved to BuildKit's cache, but Buildx will not
+> attempt to load the result to the Docker Engine's image store.
+>
+> For test runs, you don't need to export the build output — only the test
+> execution matters.
+
+To execute this Bake target, run `docker buildx bake test`. At this time,
+you'll receive an error indicating that the `test` stage does not exist in the
+Dockerfile.
+
+```console
+$ docker buildx bake test
+[+] Building 1.2s (6/6) FINISHED
+ => [internal] load local bake definitions
+...
+ERROR: failed to solve: target stage "test" could not be found
+```
+
+To satisfy this target, add the corresponding Dockerfile target. The `test`
+stage here is based on the same base stage as the build stage.
+
+```dockerfile
+FROM base AS test
+RUN --mount=target=. \
+    --mount=type=cache,target=/go/pkg/mod \
+    go test .
+```
+
+> [!TIP]
+> The [`--mount=type=cache` directive](/manuals/build/cache/optimize.md#use-cache-mounts)
+> caches Go modules between builds, improving build performance by avoiding the
+> need to re-download dependencies. This shared cache ensures that the same
+> dependency set is available across build, test, and other stages.
+
+Now, running the `test` target with Bake will evaluate the unit tests for this
+project. If you want to verify that it works, you can make an arbitrary change
+to `main_test.go` to cause the test to fail.
+
+Next, to enable linting, add another target to the Bake file, named `lint`:
+
+```hcl
+target "lint" {
+  target = "lint"
+  output = ["type=cacheonly"]
+}
+```
+
+And in the Dockerfile, add the build stage. This stage will use the official
+`golangci-lint` image on Docker Hub.
+
+> [!TIP]
+> Because this stage relies on executing an external dependency, it's generally
+> a good idea to define the version you want to use as a build argument. This
+> lets you manage version upgrades in the future by collocating
+> dependency versions to the beginning of the Dockerfile.
+
+```dockerfile {hl_lines=[2,"6-8"]}
+ARG GO_VERSION="1.23"
+ARG GOLANGCI_LINT_VERSION="1.61"
+
+#...
+
+FROM golangci/golangci-lint:v${GOLANGCI_LINT_VERSION}-alpine AS lint
+RUN --mount=target=.,rw \
+    golangci-lint run
+```
+
+Lastly, to enable running both tests simultaneously, you can use the `groups`
+construct in the Bake file. A group can specify multiple targets to run with a
+single invocation.
+
+```hcl
+group "validate" {
+  targets = ["test", "lint"]
+}
+```
+
+Now, running both tests is as simple as:
+
+```console
+$ docker buildx bake validate
+```
+
+## Building variants
+
+Sometimes you need to build more than one version of a program. The following
+example uses Bake to build separate "release" and "debug" variants of the
+program, using [matrices](/manuals/build/bake/matrices.md). Using matrices lets
+you run parallel builds with different configurations, saving time and ensuring
+consistency.
+
+A matrix expands a single build into multiple builds, each representing a
+unique combination of matrix parameters. This means you can orchestrate Bake
+into building both the production and development build of your program in
+parallel, with minimal configuration changes.
+
+The example project for this guide is set up to use a build-time option to
+conditionally enable debug logging and tracing capabilities.
+
+- If you compile the program with `go build -tags="debug"`, the additional
+  logging and tracing capabilities are enabled (development mode).
+- If you build without the `debug` tag, the program is compiled with a default
+  logger (production mode).
+
+Update the Bake file by adding a matrix attribute which defines the variable
+combinations to build:
+
+```diff {title="docker-bake.hcl"}
+ target "default" {
++  matrix = {
++    mode = ["release", "debug"]
++  }
++  name = "image-${mode}"
+   target = "image"
+```
+
+The `matrix` attribute defines the variants to build ("release" and "debug").
+The `name` attribute defines how the matrix gets expanded into multiple
+distinct build targets. In this case, the matrix attribute expands the build
+into two workflows: `image-release` and `image-debug`, each using different
+configuration parameters.
+
+Next, define a build argument named `BUILD_TAGS` which takes the value of the
+matrix variable.
+
+```diff {title="docker-bake.hcl"}
+   target = "image"
++  args = {
++    BUILD_TAGS = mode
++  }
+   tags = [
+```
+
+You'll also want to change how the image tags are assigned to these builds.
+As written, both matrix paths would generate the same image tag names, and
+overwrite each other. Update the `tags` attribute use a conditional operator to
+set the tag depending on the matrix variable value.
+
+```diff {title="docker-bake.hcl"}
+   tags = [
+-    "bakeme:latest",
++    mode == "release" ? "bakeme:latest" : "bakeme:dev"
+   ]
+```
+
+- If `mode` is `release`, the tag name is `bakeme:latest`
+- If `mode` is `debug`, the tag name is `bakeme:dev`
+
+Finally, update the Dockerfile to consume the `BUILD_TAGS` argument during the
+compilation stage. When the `-tags="${BUILD_TAGS}"` option evaluates to
+`-tags="debug"`, the compiler uses the `configureLogging` function in the
+[`debug.go`](https://github.com/dvdksn/bakeme/blob/75c8a41e613829293c4bd3fc3b4f0c573f458f42/debug.go#L1)
+file.
+
+```diff {title=Dockerfile}
+ # build compiles the program
+ FROM base AS build
+-ARG TARGETOS TARGETARCH
++ARG TARGETOS TARGETARCH BUILD_TAGS
+ ENV GOOS=$TARGETOS
+ ENV GOARCH=$TARGETARCH
+ RUN --mount=target=. \
+        --mount=type=cache,target=/go/pkg/mod \
+-       go build -o "/usr/bin/bakeme" .
++       go build -tags="${BUILD_TAGS}" -o "/usr/bin/bakeme" .
+```
+
+That's all. With these changes, your `docker buildx bake` command now builds
+two multi-platform image variants. You can introspect the canonical build
+configuration that Bake generates using the `docker buildx bake --print`
+command. Running this command shows that Bake will run a `default` group with
+two targets with different build arguments and image tags.
+
+```json {collapse=true}
+{
+  "group": {
+    "default": {
+      "targets": ["image-release", "image-debug"]
+    }
+  },
+  "target": {
+    "image-debug": {
+      "attest": ["type=provenance,mode=max", "type=sbom"],
+      "context": ".",
+      "dockerfile": "Dockerfile",
+      "args": {
+        "BUILD_TAGS": "debug"
+      },
+      "tags": ["bakeme:dev"],
+      "target": "image",
+      "platforms": ["linux/amd64", "linux/arm64", "linux/riscv64"]
+    },
+    "image-release": {
+      "attest": ["type=provenance,mode=max", "type=sbom"],
+      "context": ".",
+      "dockerfile": "Dockerfile",
+      "args": {
+        "BUILD_TAGS": "release"
+      },
+      "tags": ["bakeme:latest"],
+      "target": "image",
+      "platforms": ["linux/amd64", "linux/arm64", "linux/riscv64"]
+    }
+  }
+}
+```
+
+Factoring in all of the platform variants as well, this means that the build
+configuration generates 6 different images.
+
+```console
+$ docker buildx bake
+$ docker image ls --tree
+
+IMAGE                   ID             DISK USAGE   CONTENT SIZE   USED
+bakeme:dev              f7cb5c08beac       49.3MB         28.9MB
+├─ linux/riscv64        0eae8ba0367a       9.18MB         9.18MB
+├─ linux/arm64          56561051c49a         30MB         9.89MB
+└─ linux/amd64          e8ca65079c1f        9.8MB          9.8MB
+
+bakeme:latest           20065d2c4d22       44.4MB         25.9MB
+├─ linux/riscv64        7cc82872695f       8.21MB         8.21MB
+├─ linux/arm64          e42220c2b7a3       27.1MB         8.93MB
+└─ linux/amd64          af5b2dd64fde       8.78MB         8.78MB
+```
+
+## Exporting build artifacts
+
+Exporting build artifacts like binaries can be useful for deploying to
+environments without Docker or Kubernetes. For example, if your programs are
+meant to be run on a user's local machine.
+
+> [!TIP]
+> The techniques discussed in this section can be applied not only to build
+> output like binaries, but to any type of artifacts, such as test reports.
+
+With programming languages like Go and Rust where the compiled binaries are
+usually portable, creating alternate build targets for exporting only the
+binary is trivial. All you need to do is add an empty stage in the Dockerfile
+containing nothing but the binary that you want to export.
+
+First, let's add a quick way to build a binary for your local platform and
+export it to `./build/local` on the local filesystem.
+
+In the `docker-bake.hcl` file, create a new `bin` target. In this stage, set
+the `output` attribute to a local filesystem path. Buildx automatically detects
+that the output looks like a filepath, and exports the results to the specified
+path using the [local exporter](/manuals/build/exporters/local-tar.md).
+
+```hcl
+target "bin" {
+  target = "bin"
+  output = ["build/bin"]
+  platforms = ["local"]
+}
+```
+
+Notice that this stage specifies a `local` platform. By default, if `platforms`
+is unspecified, builds target the OS and architecture of the BuildKit host. If
+you're using Docker Desktop, this often means builds target `linux/amd64` or
+`linux/arm64`, even if your local machine is macOS or Windows, because Docker
+runs in a Linux VM. Using the `local` platform forces the target platform to
+match your local environment.
+
+Next, add the `bin` stage to the Dockerfile which copies the compiled binary
+from the build stage.
+
+```dockerfile
+FROM scratch AS bin
+COPY --from=build "/usr/bin/bakeme" /
+```
+
+Now you can export your local platform version of the binary with `docker
+buildx bake bin`. For example, on macOS, this build target generates an
+executable in the [Mach-O format](https://en.wikipedia.org/wiki/Mach-O) — the
+standard executable format for macOS.
+
+```console
+$ docker buildx bake bin
+$ file ./build/bin/bakeme
+./build/bin/bakeme: Mach-O 64-bit executable arm64
+```
+
+Next, let's add a target to build all of the platform variants of the program.
+To do this, you can [inherit](/manuals/build/bake/inheritance.md) the `bin`
+target that you just created, and extend it by adding the desired platforms.
+
+```hcl
+target "bin-cross" {
+  inherits = ["bin"]
+  platforms = [
+    "linux/amd64",
+    "linux/arm64",
+    "linux/riscv64",
+  ]
+}
+```
+
+Now, building the `bin-cross` target creates binaries for all platforms.
+Subdirectories are automatically created for each variant.
+
+```console
+$ docker buildx bake bin-cross
+$ tree build/
+build/
+└── bin
+    ├── bakeme
+    ├── linux_amd64
+    │   └── bakeme
+    ├── linux_arm64
+    │   └── bakeme
+    └── linux_riscv64
+        └── bakeme
+
+5 directories, 4 files
+```
+
+To also generate "release" and "debug" variants, you can use a matrix just like
+you did with the default target. When using a matrix, you also need to
+differentiate the output directory based on the matrix value, otherwise the
+binary gets written to the same location for each matrix run.
+
+```hcl
+target "bin-all" {
+  inherits = ["bin-cross"]
+  matrix = {
+    mode = ["release", "debug"]
+  }
+  name = "bin-${mode}"
+  args = {
+    BUILD_TAGS = mode
+  }
+  output = ["build/bin/${mode}"]
+}
+```
+
+```console
+$ rm -r ./build/
+$ docker buildx bake bin-all
+$ tree build/
+build/
+└── bin
+    ├── debug
+    │   ├── linux_amd64
+    │   │   └── bakeme
+    │   ├── linux_arm64
+    │   │   └── bakeme
+    │   └── linux_riscv64
+    │       └── bakeme
+    └── release
+        ├── linux_amd64
+        │   └── bakeme
+        ├── linux_arm64
+        │   └── bakeme
+        └── linux_riscv64
+            └── bakeme
+
+10 directories, 6 files
+```
+
+## Conclusion
+
+Docker Buildx Bake streamlines complex build workflows, enabling efficient
+multi-platform builds, testing, and artifact export. By integrating Buildx Bake
+into your projects, you can simplify your Docker builds, make your build
+configuration portable, and wrangle complex configurations.
+
+Experiment with different configurations and extend your Bake files to suit
+your project's needs. You might consider integrating Bake into your CI/CD
+pipelines to automate builds, testing, and artifact deployment. The flexibility
+and power of Buildx Bake can significantly improve your development and
+deployment processes.
+
+### Further reading
+
+For more information about how to use Bake, check out these resources:
+
+- [Bake documentation](/manuals/build/bake/_index.md)
+- [Matrix targets](/manuals/build/bake/matrices.md)
+- [Bake file reference](/manuals/build/bake/reference.md)
+- [Bake GitHub Action](https://github.com/docker/bake-action)
diff --git a/content/guides/bake/index.md b/content/guides/bake/index.md
deleted file mode 100644
index c099ec1c528e..000000000000
--- a/content/guides/bake/index.md
+++ /dev/null
@@ -1,516 +0,0 @@
----
-title: Mastering multi-platform builds, testing, and more with Docker Buildx Bake
-linkTitle: Mastering Docker Buildx Bake
-description: >
-  Learn how to manage simple and complex build configurations with Buildx Bake.
-summary: >
-  Learn to automate Docker builds and testing with declarative configurations using Buildx Bake.
-tags: [devops]
-languages: [go]
-params:
-  time: 30 minutes
-  featured: true
-  image: /images/guides/bake.webp
----
-
-This guide demonstrates how to simplify and automate the process of building
-images, testing, and generating build artifacts using Docker Buildx Bake. By
-defining build configurations in a declarative `docker-bake.hcl` file, you can
-eliminate manual scripts and enable efficient workflows for complex builds,
-testing, and artifact generation.
-
-## Assumptions
-
-This guide assumes that you're familiar with:
-
-- Docker
-- [Buildx](/manuals/build/concepts/overview.md#buildx)
-- [BuildKit](/manuals/build/concepts/overview.md#buildkit)
-- [Multi-stage builds](/manuals/build/building/multi-stage.md)
-- [Multi-platform builds](/manuals/build/building/multi-platform.md)
-
-## Prerequisites
-
-- You have a recent version of Docker installed on your machine.
-- You have Git installed for cloning repositories.
-- You're using the [containerd](/manuals/desktop/features/containerd.md) image store.
-
-## Introduction
-
-This guide uses an example project to demonstrate how Docker Buildx Bake can
-streamline your build and test workflows. The repository includes both a
-Dockerfile and a `docker-bake.hcl` file, giving you a ready-to-use setup to try
-out Bake commands.
-
-Start by cloning the example repository:
-
-```bash
-git clone https://github.com/dvdksn/bakeme.git
-cd bakeme
-```
-
-The Bake file, `docker-bake.hcl`, defines the build targets in a declarative
-syntax, using targets and groups, allowing you to manage complex builds
-efficiently.
-
-Here's what the Bake file looks like out-of-the-box:
-
-```hcl
-target "default" {
-  target = "image"
-  tags = [
-    "bakeme:latest",
-  ]
-  attest = [
-    "type=provenance,mode=max",
-    "type=sbom",
-  ]
-  platforms = [
-    "linux/amd64",
-    "linux/arm64",
-    "linux/riscv64",
-  ]
-}
-```
-
-The `target` keyword defines a build target for Bake. The `default` target
-defines the target to build when no specific target is specified on the command
-line. Here's a quick summary of the options for the `default` target:
-
-- `target`: The target build stage in the Dockerfile.
-- `tags`: Tags to assign to the image.
-- `attest`: [Attestations](/manuals/build/metadata/attestations/_index.md) to attach to the image.
-
-  > [!TIP]
-  > The attestations provide metadata such as build provenance, which tracks
-  > the source of the image's build, and an SBOM (Software Bill of Materials),
-  > useful for security audits and compliance.
-
-- `platforms`: Platform variants to build.
-
-To execute this build, simply run the following command in the root of the
-repository:
-
-```console
-$ docker buildx bake
-```
-
-With Bake, you avoid long, hard-to-remember command-line incantations,
-simplifying build configuration management by replacing manual, error-prone
-scripts with a structured configuration file.
-
-For contrast, here's what this build command would look like without Bake:
-
-```console
-$ docker buildx build \
-  --target=image \
-  --tag=bakeme:latest \
-  --provenance=true \
-  --sbom=true \
-  --platform=linux/amd64,linux/arm64,linux/riscv64 \
-  .
-```
-
-## Testing and linting
-
-Bake isn't just for defining build configurations and running builds. You can
-also use Bake to run your tests, effectively using BuildKit as a task runner.
-Running your tests in containers is great for ensuring reproducible results.
-This section shows how to add two types of tests:
-
-- Unit testing with `go test`.
-- Linting for style violations with `golangci-lint`.
-
-In Test-Driven Development (TDD) fashion, start by adding a new `test` target
-to the Bake file:
-
-```hcl
-target "test" {
-  target = "test"
-  output = ["type=cacheonly"]
-}
-```
-
-> [!TIP]
-> Using `type=cacheonly` ensures that the build output is effectively
-> discarded; the layers are saved to BuildKit's cache, but Buildx will not
-> attempt to load the result to the Docker Engine's image store.
->
-> For test runs, you don't need to export the build output — only the test
-> execution matters.
-
-To execute this Bake target, run `docker buildx bake test`. At this time,
-you'll receive an error indicating that the `test` stage does not exist in the
-Dockerfile.
-
-```console
-$ docker buildx bake test
-[+] Building 1.2s (6/6) FINISHED
- => [internal] load local bake definitions
-...
-ERROR: failed to solve: target stage "test" could not be found
-```
-
-To satisfy this target, add the corresponding Dockerfile target. The `test`
-stage here is based on the same base stage as the build stage.
-
-```dockerfile
-FROM base AS test
-RUN --mount=target=. \
-    --mount=type=cache,target=/go/pkg/mod \
-    go test .
-```
-
-> [!TIP]
-> The [`--mount=type=cache` directive](/manuals/build/cache/optimize.md#use-cache-mounts)
-> caches Go modules between builds, improving build performance by avoiding the
-> need to re-download dependencies. This shared cache ensures that the same
-> dependency set is available across build, test, and other stages.
-
-Now, running the `test` target with Bake will evaluate the unit tests for this
-project. If you want to verify that it works, you can make an arbitrary change
-to `main_test.go` to cause the test to fail.
-
-Next, to enable linting, add another target to the Bake file, named `lint`:
-
-```hcl
-target "lint" {
-  target = "lint"
-  output = ["type=cacheonly"]
-}
-```
-
-And in the Dockerfile, add the build stage. This stage will use the official
-`golangci-lint` image on Docker Hub.
-
-> [!TIP]
-> Because this stage relies on executing an external dependency, it's generally
-> a good idea to define the version you want to use as a build argument. This
-> lets you more easily manage version upgrades in the future by collocating
-> dependency versions to the beginning of the Dockerfile.
-
-```dockerfile {hl_lines=[2,"6-8"]}
-ARG GO_VERSION="1.23"
-ARG GOLANGCI_LINT_VERSION="1.61"
-
-#...
-
-FROM golangci/golangci-lint:v${GOLANGCI_LINT_VERSION}-alpine AS lint
-RUN --mount=target=.,rw \
-    golangci-lint run
-```
-
-Lastly, to enable running both tests simultaneously, you can use the `groups`
-construct in the Bake file. A group can specify multiple targets to run with a
-single invocation.
-
-```hcl
-group "validate" {
-  targets = ["test", "lint"]
-}
-```
-
-Now, running both tests is as simple as:
-
-```console
-$ docker buildx bake validate
-```
-
-## Building variants
-
-Sometimes you need to build more than one version of a program. The following
-example uses Bake to build separate "release" and "debug" variants of the
-program, using [matrices](/manuals/build/bake/matrices.md). Using matrices lets
-you run parallel builds with different configurations, saving time and ensuring
-consistency.
-
-A matrix expands a single build into multiple builds, each representing a
-unique combination of matrix parameters. This means you can orchestrate Bake
-into building both the production and development build of your program in
-parallel, with minimal configuration changes.
-
-The example project for this guide is set up to use a build-time option to
-conditionally enable debug logging and tracing capabilities.
-
-- If you compile the program with `go build -tags="debug"`, the additional
-  logging and tracing capabilities are enabled (development mode).
-- If you build without the `debug` tag, the program is compiled with a default
-  logger (production mode).
-
-Update the Bake file by adding a matrix attribute which defines the variable
-combinations to build:
-
-```diff {title="docker-bake.hcl"}
- target "default" {
-+  matrix = {
-+    mode = ["release", "debug"]
-+  }
-+  name = "image-${mode}"
-   target = "image"
-```
-
-The `matrix` attribute defines the variants to build ("release" and "debug").
-The `name` attribute defines how the matrix gets expanded into multiple
-distinct build targets. In this case, the matrix attribute expands the build
-into two workflows: `image-release` and `image-debug`, each using different
-configuration parameters.
-
-Next, define a build argument named `BUILD_TAGS` which takes the value of the
-matrix variable.
-
-```diff {title="docker-bake.hcl"}
-   target = "image"
-+  args = {
-+    BUILD_TAGS = mode
-+  }
-   tags = [
-```
-
-You'll also want to change how the image tags are assigned to these builds.
-Currently, both matrix paths would generate the same image tag names, and
-overwrite each other. Update the `tags` attribute use a conditional operator to
-set the tag depending on the matrix variable value.
-
-```diff {title="docker-bake.hcl"}
-   tags = [
--    "bakeme:latest",
-+    mode == "release" ? "bakeme:latest" : "bakeme:dev"
-   ]
-```
-
-- If `mode` is `release`, the tag name is `bakeme:latest`
-- If `mode` is `debug`, the tag name is `bakeme:dev`
-
-Finally, update the Dockerfile to consume the `BUILD_TAGS` argument during the
-compilation stage. When the `-tags="${BUILD_TAGS}"` option evaluates to
-`-tags="debug"`, the compiler uses the `configureLogging` function in the
-[`debug.go`](https://github.com/dvdksn/bakeme/blob/75c8a41e613829293c4bd3fc3b4f0c573f458f42/debug.go#L1)
-file.
-
-```diff {title=Dockerfile}
- # build compiles the program
- FROM base AS build
--ARG TARGETOS TARGETARCH
-+ARG TARGETOS TARGETARCH BUILD_TAGS
- ENV GOOS=$TARGETOS
- ENV GOARCH=$TARGETARCH
- RUN --mount=target=. \
-        --mount=type=cache,target=/go/pkg/mod \
--       go build -o "/usr/bin/bakeme" .
-+       go build -tags="${BUILD_TAGS}" -o "/usr/bin/bakeme" .
-```
-
-That's all. With these changes, your `docker buildx bake` command now builds
-two multi-platform image variants. You can introspect the canonical build
-configuration that Bake generates using the `docker buildx bake --print`
-command. Running this command shows that Bake will run a `default` group with
-two targets with different build arguments and image tags.
-
-```json {collapse=true}
-{
-  "group": {
-    "default": {
-      "targets": ["image-release", "image-debug"]
-    }
-  },
-  "target": {
-    "image-debug": {
-      "attest": ["type=provenance,mode=max", "type=sbom"],
-      "context": ".",
-      "dockerfile": "Dockerfile",
-      "args": {
-        "BUILD_TAGS": "debug"
-      },
-      "tags": ["bakeme:dev"],
-      "target": "image",
-      "platforms": ["linux/amd64", "linux/arm64", "linux/riscv64"]
-    },
-    "image-release": {
-      "attest": ["type=provenance,mode=max", "type=sbom"],
-      "context": ".",
-      "dockerfile": "Dockerfile",
-      "args": {
-        "BUILD_TAGS": "release"
-      },
-      "tags": ["bakeme:latest"],
-      "target": "image",
-      "platforms": ["linux/amd64", "linux/arm64", "linux/riscv64"]
-    }
-  }
-}
-```
-
-Factoring in all of the platform variants as well, this means that the build
-configuration generates 6 different images.
-
-```console
-$ docker buildx bake
-$ docker image ls --tree
-
-IMAGE                   ID             DISK USAGE   CONTENT SIZE   USED
-bakeme:dev              f7cb5c08beac       49.3MB         28.9MB
-├─ linux/riscv64        0eae8ba0367a       9.18MB         9.18MB
-├─ linux/arm64          56561051c49a         30MB         9.89MB
-└─ linux/amd64          e8ca65079c1f        9.8MB          9.8MB
-
-bakeme:latest           20065d2c4d22       44.4MB         25.9MB
-├─ linux/riscv64        7cc82872695f       8.21MB         8.21MB
-├─ linux/arm64          e42220c2b7a3       27.1MB         8.93MB
-└─ linux/amd64          af5b2dd64fde       8.78MB         8.78MB
-```
-
-## Exporting build artifacts
-
-Exporting build artifacts like binaries can be useful for deploying to
-environments without Docker or Kubernetes. For example, if your programs are
-meant to be run on a user's local machine.
-
-> [!TIP]
-> The techniques discussed in this section can be applied not only to build
-> output like binaries, but to any type of artifacts, such as test reports.
-
-With programming languages like Go and Rust where the compiled binaries are
-usually portable, creating alternate build targets for exporting only the
-binary is trivial. All you need to do is add an empty stage in the Dockerfile
-containing nothing but the binary that you want to export.
-
-First, let's add a quick way to build a binary for your local platform and
-export it to `./build/local` on the local filesystem.
-
-In the `docker-bake.hcl` file, create a new `bin` target. In this stage, set
-the `output` attribute to a local filesystem path. Buildx automatically detects
-that the output looks like a filepath, and exports the results to the specified
-path using the [local exporter](/manuals/build/exporters/local-tar.md).
-
-```hcl
-target "bin" {
-  target = "bin"
-  output = ["build/bin"]
-  platforms = ["local"]
-}
-```
-
-Notice that this stage specifies a `local` platform. By default, if `platforms`
-is unspecified, builds target the OS and architecture of the BuildKit host. If
-you're using Docker Desktop, this often means builds target `linux/amd64` or
-`linux/arm64`, even if your local machine is macOS or Windows, because Docker
-runs in a Linux VM. Using the `local` platform forces the target platform to
-match your local environment.
-
-Next, add the `bin` stage to the Dockerfile which copies the compiled binary
-from the build stage.
-
-```dockerfile
-FROM scratch AS bin
-COPY --from=build "/usr/bin/bakeme" /
-```
-
-Now you can export your local platform version of the binary with `docker
-buildx bake bin`. For example, on macOS, this build target generates an
-executable in the [Mach-O format](https://en.wikipedia.org/wiki/Mach-O) — the
-standard executable format for macOS.
-
-```console
-$ docker buildx bake bin
-$ file ./build/bin/bakeme
-./build/bin/bakeme: Mach-O 64-bit executable arm64
-```
-
-Next, let's add a target to build all of the platform variants of the program.
-To do this, you can [inherit](/manuals/build/bake/inheritance.md) the `bin`
-target that you just created, and extend it by adding the desired platforms.
-
-```hcl
-target "bin-cross" {
-  inherits = ["bin"]
-  platforms = [
-    "linux/amd64",
-    "linux/arm64",
-    "linux/riscv64",
-  ]
-}
-```
-
-Now, building the `bin-cross` target creates binaries for all platforms.
-Subdirectories are automatically created for each variant.
-
-```console
-$ docker buildx bake bin-cross
-$ tree build/
-build/
-└── bin
-    ├── bakeme
-    ├── linux_amd64
-    │   └── bakeme
-    ├── linux_arm64
-    │   └── bakeme
-    └── linux_riscv64
-        └── bakeme
-
-5 directories, 4 files
-```
-
-To also generate "release" and "debug" variants, you can use a matrix just like
-you did with the default target. When using a matrix, you also need to
-differentiate the output directory based on the matrix value, otherwise the
-binary gets written to the same location for each matrix run.
-
-```hcl
-target "bin-all" {
-  inherits = ["bin-cross"]
-  matrix = {
-    mode = ["release", "debug"]
-  }
-  name = "bin-${mode}"
-  args = {
-    BUILD_TAGS = mode
-  }
-  output = ["build/bin/${mode}"]
-}
-```
-
-```console
-$ rm -r ./build/
-$ docker buildx bake bin-all
-$ tree build/
-build/
-└── bin
-    ├── debug
-    │   ├── linux_amd64
-    │   │   └── bakeme
-    │   ├── linux_arm64
-    │   │   └── bakeme
-    │   └── linux_riscv64
-    │       └── bakeme
-    └── release
-        ├── linux_amd64
-        │   └── bakeme
-        ├── linux_arm64
-        │   └── bakeme
-        └── linux_riscv64
-            └── bakeme
-
-10 directories, 6 files
-```
-
-## Conclusion
-
-Docker Buildx Bake streamlines complex build workflows, enabling efficient
-multi-platform builds, testing, and artifact export. By integrating Buildx Bake
-into your projects, you can simplify your Docker builds, make your build
-configuration portable, and wrangle complex configurations more easily.
-
-Experiment with different configurations and extend your Bake files to suit
-your project's needs. You might consider integrating Bake into your CI/CD
-pipelines to automate builds, testing, and artifact deployment. The flexibility
-and power of Buildx Bake can significantly improve your development and
-deployment processes.
-
-### Further reading
-
-For more information about how to use Bake, check out these resources:
-
-- [Bake documentation](/manuals/build/bake/_index.md)
-- [Matrix targets](/manuals/build/bake/matrices.md)
-- [Bake file reference](/manuals/build/bake/reference.md)
-- [Bake GitHub Action](https://github.com/docker/bake-action)
diff --git a/content/guides/bun.md b/content/guides/bun.md
new file mode 100644
index 000000000000..29c1d21ced0f
--- /dev/null
+++ b/content/guides/bun.md
@@ -0,0 +1,251 @@
+---
+description: Containerize and develop Bun applications using Docker.
+keywords: getting started, bun
+title: Bun language-specific guide
+summary: |
+  Learn how to containerize JavaScript applications with the Bun runtime.
+linkTitle: Bun
+aliases:
+  - /guides/bun/configure-ci-cd/
+  - /guides/bun/containerize/
+  - /guides/bun/deploy/
+  - /guides/bun/develop/
+params:
+  tags: [languages]
+  time: 10 minutes
+---
+
+The Bun getting started guide teaches you how to create a containerized Bun application using Docker.
+
+> **Acknowledgment**
+>
+> Docker would like to thank [Pradumna Saraf](https://twitter.com/pradumna_saraf) for his contribution to this guide.
+
+## What will you learn?
+
+- Containerize and run a Bun application using Docker
+- Set up a local environment to develop a Bun application using containers
+
+## Prerequisites
+
+- Basic understanding of JavaScript is assumed.
+- You must have familiarity with Docker concepts like containers, images, and Dockerfiles. If you are new to Docker, you can start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
+
+After completing the Bun getting started modules, you should be able to containerize your own Bun application based on the examples and instructions provided in this guide.
+
+Start by containerizing an existing Bun application.
+
+## Containerize a Bun application
+
+### Prerequisites
+
+- You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
+
+### Overview
+
+For a long time, Node.js has been the de-facto runtime for server-side
+JavaScript applications. Recent years have seen a rise in new alternative
+runtimes in the ecosystem, including [Bun website](https://bun.sh/). Like
+Node.js, Bun is a JavaScript runtime. Bun is a comparatively lightweight
+runtime that is designed to be fast and efficient.
+
+Why develop Bun applications with Docker? Having multiple runtimes to choose
+from is great. But as the number of runtimes increases, it becomes challenging
+to manage the different runtimes and their dependencies consistently across
+environments. This is where Docker comes in. Creating and destroying containers
+on demand is a great way to manage the different runtimes and their
+dependencies. Also, as it's fairly a new runtime, getting a consistent
+development environment for Bun can be challenging. Docker can help you set up
+a consistent development environment for Bun.
+
+### Get the sample application
+
+Clone the sample application to use with this guide. Open a terminal, change
+directory to a directory that you want to work in, and run the following
+command to clone the repository:
+
+```console
+$ git clone https://github.com/dockersamples/bun-docker.git && cd bun-docker
+```
+
+You should now have the following contents in your `bun-docker` directory.
+
+```text
+├── bun-docker/
+│ ├── compose.yml
+│ ├── Dockerfile
+│ ├── LICENSE
+│ ├── server.js
+│ └── README.md
+```
+
+### Create a Dockerfile
+
+Before creating a Dockerfile, you need to choose a base image. You can either use the [Bun Docker Official Image](https://hub.docker.com/r/oven/bun) or a Docker Hardened Image (DHI) from the [Hardened Image catalog](https://hub.docker.com/hardened-images/catalog).
+
+Choosing DHI offers the advantage of a production-ready image that is lightweight and secure. For more information, see [Docker Hardened Images](https://docs.docker.com/dhi/).
+
+{{< tabs >}}
+{{< tab name="Using Docker Hardened Images" >}}
+
+Docker Hardened Images (DHIs) are available for Bun in the [Docker Hardened Images catalog](https://hub.docker.com/hardened-images/catalog/dhi/bun). You can pull DHIs directly from the `dhi.io` registry.
+
+1. Sign in to the DHI registry:
+
+   ```console
+   $ docker login dhi.io
+   ```
+
+2. Pull the Bun DHI as `dhi.io/bun:1`. The tag (`1`) in this example refers to the version to the latest 1.x version of Bun.
+
+   ```console
+   $ docker pull dhi.io/bun:1
+   ```
+
+For other available versions, refer to the [catalog](https://hub.docker.com/hardened-images/catalog/dhi/bun).
+
+```dockerfile
+# Use the DHI Bun image as the base image
+FROM dhi.io/bun:1
+
+# Set the working directory in the container
+WORKDIR /app
+
+# Copy the current directory contents into the container at /app
+COPY . .
+
+# Expose the port on which the API will listen
+EXPOSE 3000
+
+# Run the server when the container launches
+CMD ["bun", "server.js"]
+```
+
+{{< /tab >}}
+{{< tab name="Using the official image" >}}
+
+Using the Docker Official Image is straightforward. In the following Dockerfile, you'll notice that the `FROM` instruction uses `oven/bun` as the base image.
+
+You can find the image on [Docker Hub](https://hub.docker.com/r/oven/bun). This is the Docker Official Image for Bun created by Oven, the company behind Bun, and it's available on Docker Hub.
+
+```dockerfile
+# Use the official Bun image
+FROM oven/bun:latest
+
+# Set the working directory in the container
+WORKDIR /app
+
+# Copy the current directory contents into the container at /app
+COPY . .
+
+# Expose the port on which the API will listen
+EXPOSE 3000
+
+# Run the server when the container launches
+CMD ["bun", "server.js"]
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+In addition to specifying the base image, the Dockerfile also:
+
+- Sets the working directory in the container to `/app`.
+- Copies the content of the current directory to the `/app` directory in the container.
+- Exposes port 3000, where the API is listening for requests.
+- And finally, starts the server when the container launches with the command `bun server.js`.
+
+### Run the application
+
+Inside the `bun-docker` directory, run the following command in a terminal.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:3000](http://localhost:3000). You will see a message `{"Status" : "OK"}` in the browser.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `bun-docker` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:3000](http://localhost:3000).
+
+In the terminal, run the following command to stop the application.
+
+```console
+$ docker compose down
+```
+
+## Use containers for Bun development
+
+### Prerequisites
+
+Complete [Containerize a Bun application](#containerize-a-bun-application).
+
+### Overview
+
+In this section, you'll learn how to set up a development environment for your containerized application. This includes:
+
+- Configuring Compose to automatically update your running Compose services as you edit and save your code
+
+### Get the sample application
+
+Clone the sample application to use with this guide. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
+
+```console
+$ git clone https://github.com/dockersamples/bun-docker.git && cd bun-docker
+```
+
+### Automatically update services
+
+Use Compose Watch to automatically update your running Compose services as you
+edit and save your code. For more details about Compose Watch, see [Use Compose
+Watch](/manuals/compose/how-tos/file-watch.md).
+
+Open your `compose.yml` file in an IDE or text editor and then add the Compose Watch instructions. The following example shows how to add Compose Watch to your `compose.yml` file.
+
+```yaml {hl_lines="9-12",linenos=true}
+services:
+  server:
+    image: bun-server
+    build:
+      context: .
+      dockerfile: Dockerfile
+    ports:
+      - "3000:3000"
+    develop:
+      watch:
+        - action: rebuild
+          path: .
+```
+
+Run the following command to run your application with Compose Watch.
+
+```console
+$ docker compose watch
+```
+
+Now, if you modify your `server.js` you will see the changes in real time without re-building the image.
+
+To test it out, open the `server.js` file in your favorite text editor and change the message from `{"Status" : "OK"}` to `{"Status" : "Updated"}`. Save the file and refresh your browser at `http://localhost:3000`. You should see the updated message.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Summary
+
+In this section, you also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
+
+Related information:
+
+- [Compose file reference](/reference/compose-file/)
+- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
+- [Multi-stage builds](/manuals/build/building/multi-stage.md)
diff --git a/content/guides/bun/_index.md b/content/guides/bun/_index.md
deleted file mode 100644
index 3c304a9cbf37..000000000000
--- a/content/guides/bun/_index.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-description: Containerize and develop Bun applications using Docker.
-keywords: getting started, bun
-title: Bun language-specific guide
-summary: |
-  Learn how to containerize JavaScript applications with the Bun runtime.
-linkTitle: Bun
-languages: [js]
-params:
-  time: 10 minutes
----
-
-The Bun getting started guide teaches you how to create a containerized Bun application using Docker. In this guide, you'll learn how to:
-
-> **Acknowledgment**
->
-> Docker would like to thank [Pradumna Saraf](https://twitter.com/pradumna_saraf) for his contribution to this guide.
-
-## What will you learn?
-
-* Containerize and run a Bun application using Docker
-* Set up a local environment to develop a Bun application using containers
-* Configure a CI/CD pipeline for a containerized Bun application using GitHub Actions
-* Deploy your containerized application locally to Kubernetes to test and debug your deployment
-
-## Prerequisites
-
-- Basic understanding of JavaScript is assumed.
-- You must have familiarity with Docker concepts like containers, images, and Dockerfiles. If you are new to Docker, you can start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
-
-After completing the Bun getting started modules, you should be able to containerize your own Bun application based on the examples and instructions provided in this guide.
-
-Start by containerizing an existing Bun application.
diff --git a/content/guides/bun/configure-ci-cd.md b/content/guides/bun/configure-ci-cd.md
deleted file mode 100644
index 4135bd968969..000000000000
--- a/content/guides/bun/configure-ci-cd.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-title: Configure CI/CD for your Bun application
-linkTitle: Configure CI/CD
-weight: 40
-keywords: ci/cd, github actions, bun, shiny
-description: Learn how to configure CI/CD using GitHub Actions for your Bun application.
-aliases:
-- /language/bun/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a Bun application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-## Overview
-
-In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps:
-
-1. Create a new repository on GitHub.
-2. Define the GitHub Actions workflow.
-3. Run the workflow.
-
-## Step one: Create the repository
-
-Create a GitHub repository, configure the Docker Hub credentials, and push your source code.
-
-1. [Create a new repository](https://github.com/new) on GitHub.
-
-2. Open the repository **Settings**, and go to **Secrets and variables** >
-   **Actions**.
-
-3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-4. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token)for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-5. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-6. In your local repository on your machine, run the following command to change
-   the origin to the repository you just created. Make sure you change
-   `your-username` to your GitHub username and `your-repository` to the name of
-   the repository you created.
-
-   ```console
-   $ git remote set-url origin https://github.com/your-username/your-repository.git
-   ```
-
-7. Run the following commands to stage, commit, and push your local repository to GitHub.
-
-   ```console
-   $ git add -A
-   $ git commit -m "my commit"
-   $ git push -u origin main
-   ```
-
-## Step two: Set up the workflow
-
-Set up your GitHub Actions workflow for building, testing, and pushing the image
-to Docker Hub.
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-
-2. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub actions workflow file in
-   your repository, under `.github/workflows/main.yml` by default.
-
-3. In the editor window, copy and paste the following YAML configuration and commit the changes.
-
-   ```yaml
-   name: ci
-
-   on:
-     push:
-       branches:
-         - main
-
-   jobs:
-     build:
-       runs-on: ubuntu-latest
-       steps:
-         - name: Login to Docker Hub
-           uses: docker/login-action@v3
-           with:
-             username: ${{ vars.DOCKER_USERNAME }}
-             password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-         - name: Set up Docker Buildx
-           uses: docker/setup-buildx-action@v3
-
-         - name: Build and push
-           uses: docker/build-push-action@v6
-           with:
-             platforms: linux/amd64,linux/arm64
-             push: true
-             tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-   ```
-
-   For more information about the YAML syntax for `docker/build-push-action`,
-   refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
-## Step three: Run the workflow
-
-Save the workflow file and run the job.
-
-1. Select **Commit changes...** and push the changes to the `main` branch.
-
-   After pushing the commit, the workflow starts automatically.
-
-2. Go to the **Actions** tab. It displays the workflow.
-
-   Selecting the workflow shows you the breakdown of all the steps.
-
-3. When the workflow is complete, go to your
-   [repositories on Docker Hub](https://hub.docker.com/repositories).
-
-   If you see the new repository in that list, it means the GitHub Actions
-   successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your Bun application.
-
-Related information:
-
-- [Introduction to GitHub Actions](/guides/gha.md)
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md)
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-Next, learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/bun/containerize.md b/content/guides/bun/containerize.md
deleted file mode 100644
index 536f9f080d67..000000000000
--- a/content/guides/bun/containerize.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: Containerize a Bun application
-linkTitle: Containerize your app
-weight: 10
-keywords: bun, containerize, initialize
-description: Learn how to containerize a Bun application.
-aliases:
-  - /language/bun/containerize/
----
-
-## Prerequisites
-
-* You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
-
-## Overview
-
-For a long time, Node.js has been the de-facto runtime for server-side
-JavaScript applications. Recent years have seen a rise in new alternative
-runtimes in the ecosystem, including [Bun website](https://bun.sh/). Like
-Node.js, Bun is a JavaScript runtime. Bun is a comparatively lightweight
-runtime that is designed to be fast and efficient.
-
-Why develop Bun applications with Docker? Having multiple runtimes to choose
-from is great. But as the number of runtimes increases, it becomes challenging
-to manage the different runtimes and their dependencies consistently across
-environments. This is where Docker comes in. Creating and destroying containers
-on demand is a great way to manage the different runtimes and their
-dependencies. Also, as it's fairly a new runtime, getting a consistent
-development environment for Bun can be challenging. Docker can help you set up
-a consistent development environment for Bun.
-
-## Get the sample application
-
-Clone the sample application to use with this guide. Open a terminal, change
-directory to a directory that you want to work in, and run the following
-command to clone the repository:
-
-```console
-$ git clone https://github.com/dockersamples/bun-docker.git && cd bun-docker
-```
-
-You should now have the following contents in your `bun-docker` directory.
-
-```text
-├── bun-docker/
-│ ├── compose.yml
-│ ├── Dockerfile
-│ ├── LICENSE
-│ ├── server.js
-│ └── README.md
-```
-
-In the Dockerfile, you'll notice that the `FROM` instruction uses `oven/bun`
-as the base image. This is the official image for Bun created by Oven, the
-company behind Bun. This image is [available on the Docker Hub](https://hub.docker.com/r/oven/bun).
-
-```dockerfile
-# Use the Bun image as the base image
-FROM oven/bun:latest
-
-# Set the working directory in the container
-WORKDIR /app
-
-# Copy the current directory contents into the container at /app
-COPY . .
-
-# Expose the port on which the API will listen
-EXPOSE 3000
-
-# Run the server when the container launches
-CMD ["bun", "server.js"]
-```
-
-Aside from specifying `oven/bun` as the base image, this Dockerfile also:
-
-- Sets the working directory in the container to `/app`
-- Copies the contents of the current directory to the `/app` directory in the container
-- Exposes port 3000, where the API is listening for requests
-- And finally, starts the server when the container launches with the command `bun server.js`.
-
-## Run the application
-
-Inside the `bun-docker` directory, run the following command in a terminal.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:3000](http://localhost:3000). You will see a message `{"Status" : "OK"}` in the browser.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-### Run the application in the background
-
-You can run the application detached from the terminal by adding the `-d`
-option. Inside the `bun-docker` directory, run the following command
-in a terminal.
-
-```console
-$ docker compose up --build -d
-```
-
-Open a browser and view the application at [http://localhost:3000](http://localhost:3000).
-
-
-In the terminal, run the following command to stop the application.
-
-```console
-$ docker compose down
-```
-
-## Summary
-
-In this section, you learned how you can containerize and run your Bun
-application using Docker.
-
-Related information:
-
- - [Dockerfile reference](/reference/dockerfile.md)
- - [.dockerignore file](/reference/dockerfile.md#dockerignore-file)
- - [Docker Compose overview](/manuals/compose/_index.md)
- - [Compose file reference](/reference/compose-file/_index.md)
-
-## Next steps
-
-In the next section, you'll learn how you can develop your application using
-containers.
diff --git a/content/guides/bun/deploy.md b/content/guides/bun/deploy.md
deleted file mode 100644
index 7a8690941ef2..000000000000
--- a/content/guides/bun/deploy.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: Test your Bun deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, kubernetes, bun
-description: Learn how to develop locally using Kubernetes
-aliases:
-- /language/bun/deploy/
----
-
-## Prerequisites
-
-- Complete all the previous sections of this guide, starting with [Containerize a Bun application](containerize.md).
-- [Turn on Kubernetes](/manuals//desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This allows you to test and debug your workloads on Kubernetes locally before deploying.
-
-## Create a Kubernetes YAML file
-
-In your `bun-docker` directory, create a file named
-`docker-kubernetes.yml`. Open the file in an IDE or text editor and add
-the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker
-username and the name of the repository that you created in [Configure CI/CD for
-your Bun application](configure-ci-cd.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: docker-bun-demo
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: bun-api
-  template:
-    metadata:
-      labels:
-        app: bun-api
-    spec:
-      containers:
-       - name: bun-api
-         image: DOCKER_USERNAME/REPO_NAME
-         imagePullPolicy: Always
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: service-entrypoint
-  namespace: default
-spec:
-  type: NodePort
-  selector:
-    app: bun-api
-  ports:
-  - port: 3000
-    targetPort: 3000
-    nodePort: 30001
-```
-
-In this Kubernetes YAML file, there are two objects, separated by the `---`:
-
- - A Deployment, describing a scalable group of identical pods. In this case,
-   you'll get just one replica, or copy of your pod. That pod, which is
-   described under `template`, has just one container in it. The
-    container is created from the image built by GitHub Actions in [Configure CI/CD for
-    your Bun application](configure-ci-cd.md).
- - A NodePort service, which will route traffic from port 30001 on your host to
-   port 3000 inside the pods it routes to, allowing you to reach your app
-   from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to `bun-docker` and deploy your application to
-   Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-kubernetes.yml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```text
-   deployment.apps/docker-bun-demo created
-   service/service-entrypoint created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```shell
-   NAME                 READY   UP-TO-DATE   AVAILABLE    AGE
-   docker-bun-demo       1/1     1            1           10s
-   ```
-
-   This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```shell
-   NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
-   kubernetes           ClusterIP   10.96.0.1        <none>        443/TCP          88m
-   service-entrypoint   NodePort    10.105.145.223   <none>        3000:30001/TCP   83s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP.
-
-3. In a browser, visit the following address. You should see the message `{"Status" : "OK"}`.
-
-   ```console
-   http://localhost:30001/
-   ```
-
-4. Run the following command to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-kubernetes.yml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your Bun application to a fully-featured Kubernetes environment on your development machine. 
-
-Related information:
-   - [Kubernetes documentation](https://kubernetes.io/docs/home/)
-   - [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-   - [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/bun/develop.md b/content/guides/bun/develop.md
deleted file mode 100644
index 7de9bd63ed7e..000000000000
--- a/content/guides/bun/develop.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: Use containers for Bun development
-linkTitle: Develop your app
-weight: 20
-keywords: bun, local, development
-description: Learn how to develop your Bun application locally.
-aliases:
-- /language/bun/develop/
----
-
-## Prerequisites
-
-Complete [Containerize a Bun application](containerize.md).
-
-## Overview
-
-In this section, you'll learn how to set up a development environment for your containerized application. This includes:
-
-- Configuring Compose to automatically update your running Compose services as you edit and save your code
-
-## Get the sample application
-
-Clone the sample application to use with this guide. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
-
-```console
-$ git clone https://github.com/dockersamples/bun-docker.git && cd bun-docker
-```
-
-## Automatically update services
-
-Use Compose Watch to automatically update your running Compose services as you
-edit and save your code. For more details about Compose Watch, see [Use Compose
-Watch](/manuals/compose/how-tos/file-watch.md).
-
-Open your `compose.yml` file in an IDE or text editor and then add the Compose Watch instructions. The following example shows how to add Compose Watch to your `compose.yml` file.
-
-```yaml {hl_lines="9-12",linenos=true}
-services:
-  server:
-    image: bun-server
-    build:
-      context: .
-      dockerfile: Dockerfile
-    ports:
-      - "3000:3000"
-    develop:
-      watch:
-        - action: rebuild
-          path: .
-```
-
-Run the following command to run your application with Compose Watch.
-
-```console
-$ docker compose watch
-```
-
-Now, if you modify your `server.js` you will see the changes in real time without re-building the image.
-
-To test it out, open the `server.js` file in your favorite text editor and change the message from `{"Status" : "OK"}` to `{"Status" : "Updated"}`. Save the file and refresh your browser at `http://localhost:3000`. You should see the updated message.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Summary
-
-In this section, you also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
-
-Related information:
- - [Compose file reference](/reference/compose-file/)
- - [Compose file watch](/manuals/compose/how-tos/file-watch.md)
- - [Multi-stage builds](/manuals/build/building/multi-stage.md)
-
-## Next steps
-
-In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions.
diff --git a/content/guides/claude-code-model-runner.md b/content/guides/claude-code-model-runner.md
new file mode 100644
index 000000000000..8ac867e70ea4
--- /dev/null
+++ b/content/guides/claude-code-model-runner.md
@@ -0,0 +1,160 @@
+---
+title: Use Claude Code with Docker Model Runner
+description: Configure Claude Code to use Docker Model Runner so you can code with local models.
+summary: |
+  Connect Claude Code to Docker Model Runner with the Anthropic-compatible API,
+  package `gpt-oss` with a larger context window, and inspect requests.
+keywords: ai, claude code, docker model runner, anthropic, local models, coding assistant
+params:
+  tags: [ai]
+  time: 10 minutes
+---
+
+This guide shows how to run Claude Code with Docker Model Runner as the backend
+model provider. You'll point Claude Code at the local Anthropic-compatible API,
+run a coding model, and package `gpt-oss` with a larger context window for
+longer repository prompts.
+
+> **Acknowledgment**
+>
+> Docker would like to thank [Pradumna Saraf](https://twitter.com/pradumna_saraf) for his contribution to this guide.
+
+In this guide, you'll learn how to:
+
+- Pull a coding model and start Claude Code with Docker Model Runner
+- Make the endpoint configuration persistent
+- Verify the local API endpoint and inspect requests
+- Package `gpt-oss` with a larger context window for longer prompts
+
+## Prerequisites
+
+Before you start, make sure you have:
+
+- [Docker Desktop](../get-started/get-docker.md) or Docker Engine installed
+- [Docker Model Runner enabled](../manuals/ai/model-runner/get-started.md#enable-docker-model-runner)
+- [Claude Code installed](https://code.claude.com/docs/en/quickstart)
+
+If you use Docker Desktop, turn on TCP access in **Settings** > **AI**, or run:
+
+```console
+$ docker desktop enable model-runner --tcp 12434
+```
+
+## Step 1: Pull a coding model
+
+Pull a model before you start Claude Code:
+
+```console
+$ docker model pull ai/devstral-small-2
+```
+
+You can also use `ai/qwen3-coder` if you want another coding-focused model with
+a large context window.
+
+## Step 2: Start Claude Code with Docker Model Runner
+
+Set `ANTHROPIC_BASE_URL` to your local Docker Model Runner endpoint when you run
+Claude Code.
+
+On macOS or Linux:
+
+```console
+$ ANTHROPIC_BASE_URL=http://localhost:12434 claude --model ai/devstral-small-2
+```
+
+On Windows PowerShell:
+
+```powershell
+$env:ANTHROPIC_BASE_URL="http://localhost:12434"
+claude --model ai/devstral-small-2
+```
+
+Claude Code now sends requests to Docker Model Runner instead of Anthropic's
+hosted API.
+
+## Step 3: Troubleshoot your first launch
+
+If Claude Code can't connect, check Docker Model Runner status:
+
+```console
+$ docker model status
+```
+
+If Claude Code can't find the model, list local models:
+
+```console
+$ docker model ls
+```
+
+If the model is missing, pull it first. If needed, use the fully qualified
+model name, such as `ai/devstral-small-2`.
+
+## Step 4: Make the endpoint persistent
+
+To avoid setting the environment variable each time, add it to your shell
+profile:
+
+```bash {title="~/.bashrc or ~/.zshrc"}
+export ANTHROPIC_BASE_URL=http://localhost:12434
+```
+
+On Windows PowerShell, add it to your PowerShell profile:
+
+```powershell {title="$PROFILE"}
+$env:ANTHROPIC_BASE_URL = "http://localhost:12434"
+```
+
+After you reload your shell, you can run Claude Code with only the model flag:
+
+```console
+$ claude --model ai/devstral-small-2
+```
+
+## Step 5: Verify the API endpoint
+
+Send a test request to confirm the Anthropic-compatible API is reachable:
+
+```console
+$ curl http://localhost:12434/v1/messages \
+  -H "Content-Type: application/json" \
+  -d '{
+    "model": "ai/devstral-small-2",
+    "max_tokens": 32,
+    "messages": [{"role": "user", "content": "Say hello"}]
+  }'
+```
+
+For more details about the request format, see the
+[Anthropic-compatible API reference](../manuals/ai/model-runner/api-reference.md#anthropic-compatible-api).
+
+## Step 6: Inspect Claude Code requests
+
+To inspect the requests Claude Code sends to Docker Model Runner, run:
+
+```console
+$ docker model requests --model ai/devstral-small-2 | jq .
+```
+
+This helps you debug prompts, context usage, and compatibility issues.
+
+## Step 7: Package `gpt-oss` with a larger context window
+
+`ai/gpt-oss` defaults to a smaller context window than coding-focused models. If
+you want to use it for repository-scale prompts, package a larger variant:
+
+```console
+$ docker model pull ai/gpt-oss
+$ docker model package --from ai/gpt-oss --context-size 32000 gpt-oss:32k
+```
+
+Then run Claude Code with the packaged model:
+
+```console
+$ ANTHROPIC_BASE_URL=http://localhost:12434 claude --model gpt-oss:32k
+```
+
+## Learn more
+
+- [Docker Model Runner overview](../manuals/ai/model-runner/_index.md)
+- [Docker Model Runner API reference](../manuals/ai/model-runner/api-reference.md)
+- [IDE and tool integrations](../manuals/ai/model-runner/ide-integrations.md)
diff --git a/content/guides/claude-code-sandbox-model-runner.md b/content/guides/claude-code-sandbox-model-runner.md
new file mode 100644
index 000000000000..88e6d56c1bf7
--- /dev/null
+++ b/content/guides/claude-code-sandbox-model-runner.md
@@ -0,0 +1,210 @@
+---
+title: Run Claude Code in a Docker Sandbox with Docker Model Runner
+description: Run Claude Code inside an isolated Docker Sandbox and route requests to Docker Model Runner so the agent uses local models on your host.
+summary: |
+  Combine Docker Sandboxes with Docker Model Runner to run Claude Code in an
+  isolated microVM that talks to a local model on your host through the
+  Anthropic-compatible API.
+keywords: ai, claude code, docker model runner, docker sandboxes, sbx, anthropic, local models, coding assistant
+params:
+  tags: [ai]
+  time: 15 minutes
+---
+
+This guide shows how to run Claude Code inside a Docker Sandbox with Docker
+Model Runner as the backend model provider. You'll keep the agent isolated
+from your host in a microVM, point it at a local model on your machine, and
+keep all model traffic on-device.
+
+> **Acknowledgment**
+>
+> Docker would like to thank [Pradumna Saraf](https://twitter.com/pradumna_saraf) for his contribution to this guide.
+
+In this guide, you'll learn how to:
+
+- Pull a coding model and start Docker Model Runner with TCP enabled
+- Allow the sandbox to reach Docker Model Runner on your host
+- Create a Claude Code sandbox and set the local endpoint persistently
+- Launch Claude Code with a local model and verify the connection
+- Package `gpt-oss` with a larger context window for longer prompts
+
+## How the pieces fit together
+
+Three components cooperate at runtime:
+
+- **Docker Model Runner** runs on your host and serves an
+  Anthropic-compatible API at `http://localhost:12434`.
+- **The Docker Sandbox** runs Claude Code inside an isolated microVM. The
+  microVM has its own network and can't reach your host's `localhost`
+  directly.
+- **The sandbox proxy** sits on your host and brokers every outbound
+  request from the sandbox. It enforces network policy and translates the
+  special hostname `host.docker.internal` to `localhost`.
+
+Claude Code inside the sandbox sends requests to
+`http://host.docker.internal:12434`. The proxy rewrites the destination to
+`localhost:12434`, which Docker Model Runner answers. No model traffic
+leaves your machine.
+
+## Prerequisites
+
+Before you start, make sure you have:
+
+- [Docker Desktop](../get-started/get-docker.md) or Docker Engine installed
+- [Docker Model Runner enabled](../manuals/ai/model-runner/get-started.md#enable-docker-model-runner)
+- [Docker Sandboxes (`sbx`) version 0.39.0 or later installed and signed in](../manuals/ai/sandboxes/install.md)
+
+If you use Docker Desktop, turn on TCP access in **Settings** > **AI**, or
+run:
+
+```console
+$ docker desktop enable model-runner --tcp 12434
+```
+
+## Step 1: Pull a coding model
+
+Pull a model on your host before you create the sandbox:
+
+```console
+$ docker model pull ai/devstral-small-2
+```
+
+You can also use `ai/qwen3-coder` if you want another coding-focused model
+with a large context window.
+
+## Step 2: Allow the sandbox to reach Docker Model Runner
+
+Sandboxes are network-isolated by default, so you need a policy rule before
+the sandbox can reach Docker Model Runner.
+
+The rule is matched against the destination the proxy forwards to, not the
+hostname the sandbox uses. Because the proxy rewrites
+`host.docker.internal` to `localhost` before forwarding, the rule allows
+`localhost:12434` even though Claude Code will use `host.docker.internal`
+in its requests:
+
+```console
+$ sbx policy allow network localhost:12434
+```
+
+For background on host access from sandboxes, see
+[Accessing host services from a sandbox](../manuals/ai/sandboxes/workflows/development.md#accessing-host-services-from-a-sandbox).
+
+## Step 3: Create a Claude Code sandbox
+
+From your project directory, create a sandbox without launching the agent. Set
+`ANTHROPIC_BASE_URL` so Claude Code uses Docker Model Runner whenever the
+sandbox starts:
+
+```console
+$ cd ~/my-project
+$ sbx create --name claude-dmr \
+  -e ANTHROPIC_BASE_URL=http://host.docker.internal:12434 \
+  claude .
+```
+
+`sbx run` would also work, but it launches Claude Code immediately. Creating
+the sandbox first lets you confirm the variable and test connectivity before
+the agent starts.
+
+You don't need to set an Anthropic API key or run `sbx secret set
+anthropic`. Docker Model Runner doesn't authenticate the local endpoint,
+and the sandbox proxy only injects credentials for requests bound for
+`api.anthropic.com`. See
+[Credentials](../manuals/ai/sandboxes/configuration/credentials.md) for the full
+list of services the proxy authenticates. For more ways to set variables, see
+[Set environment variables](../manuals/ai/sandboxes/usage.md#set-environment-variables).
+
+To confirm the variable is set, open a shell in the sandbox:
+
+```console
+$ sbx exec -it claude-dmr bash
+$ echo $ANTHROPIC_BASE_URL
+http://host.docker.internal:12434
+```
+
+## Step 4: Verify connectivity to Docker Model Runner
+
+Still inside the sandbox shell, send a test request to the host endpoint:
+
+```console
+$ curl http://host.docker.internal:12434/v1/messages \
+  -H "Content-Type: application/json" \
+  -d '{
+    "model": "ai/devstral-small-2",
+    "max_tokens": 32,
+    "messages": [{"role": "user", "content": "Say hello"}]
+  }'
+```
+
+A successful response confirms the policy rule and base URL are correct.
+Type `exit` to leave the shell. For more details about the request format,
+see the
+[Anthropic-compatible API reference](../manuals/ai/model-runner/api-reference.md#anthropic-compatible-api).
+
+## Step 5: Launch Claude Code with the local model
+
+Run Claude Code in the sandbox and pass the model flag through to the agent:
+
+```console
+$ sbx run claude-dmr -- --model ai/devstral-small-2
+```
+
+Everything after `--` is forwarded to the Claude Code CLI.
+`ANTHROPIC_BASE_URL` is stored with the sandbox and available to every session,
+so Claude Code routes requests to Docker Model Runner on your host instead of
+`api.anthropic.com`.
+
+## Step 6: Inspect Claude Code requests
+
+To inspect the requests Claude Code sends, run on your host:
+
+```console
+$ docker model requests --model ai/devstral-small-2 | jq .
+```
+
+This helps you debug prompts, context usage, and compatibility issues
+without attaching to the sandbox.
+
+## Step 7: Package `gpt-oss` with a larger context window
+
+`ai/gpt-oss` defaults to a smaller context window than coding-focused
+models. To use it for repository-scale prompts, package a larger variant on
+the host:
+
+```console
+$ docker model pull ai/gpt-oss
+$ docker model package --from ai/gpt-oss --context-size 32000 gpt-oss:32k
+```
+
+Then point Claude Code at the packaged model the next time you run the
+sandbox:
+
+```console
+$ sbx run claude-dmr -- --model gpt-oss:32k
+```
+
+## Clean up
+
+Sandboxes persist after Claude Code exits. To stop the sandbox without
+deleting it:
+
+```console
+$ sbx stop claude-dmr
+```
+
+To remove the sandbox and everything inside:
+
+```console
+$ sbx rm claude-dmr
+```
+
+Files in your workspace are unaffected.
+
+## Learn more
+
+- [Use Claude Code with Docker Model Runner](claude-code-model-runner.md)
+- [Get started with Docker Sandboxes](../manuals/ai/sandboxes/get-started.md)
+- [Claude Code in Docker Sandboxes](../manuals/ai/sandboxes/agents/claude-code.md)
+- [Docker Model Runner overview](../manuals/ai/model-runner/_index.md)
+- [Docker Model Runner API reference](../manuals/ai/model-runner/api-reference.md)
diff --git a/content/guides/compose-bake.md b/content/guides/compose-bake.md
new file mode 100644
index 000000000000..cad2cdfc1566
--- /dev/null
+++ b/content/guides/compose-bake.md
@@ -0,0 +1,402 @@
+---
+title: Building Compose projects with Bake
+description: Learn how to build Docker Compose projects with Docker Buildx Bake
+summary: |
+  This guide demonstrates how you can use Bake to build production-grade images for Docker Compose projects.
+keywords: docker compose, bake, buildx, multi-service, production builds, build configuration
+params:
+  tags: [cicd]
+  time: 20 minutes
+---
+
+This guide explores how you can use Bake to build images for Docker Compose
+projects with multiple services.
+
+[Docker Buildx Bake](/manuals/build/bake/_index.md) is a build orchestration
+tool that enables declarative configuration for your builds, much like Docker
+Compose does for defining runtime stacks. For projects where Docker Compose is
+used to spin up services for local development, Bake offers a way of seamlessly
+extending the project with a production-ready build configuration.
+
+## Prerequisites
+
+This guide assumes that you're familiar with
+
+- Docker Compose
+- [Multi-stage builds](/manuals/build/building/multi-stage.md)
+- [Multi-platform builds](/manuals/build/building/multi-platform.md)
+
+## Orientation
+
+This guide will use the
+[dvdksn/example-voting-app](https://github.com/dvdksn/example-voting-app)
+repository as an example of a monorepo using Docker Compose that can be
+extended with Bake.
+
+```console
+$ git clone https://github.com/dvdksn/example-voting-app.git
+$ cd example-voting-app
+```
+
+This repository uses Docker Compose to define the runtime configurations for
+running the application, in the `compose.yaml` file. This app consists of the
+following services:
+
+| Service  | Description                                                            |
+| -------- | ---------------------------------------------------------------------- |
+| `vote`   | A front-end web app in Python which lets you vote between two options. |
+| `result` | A Node.js web app which shows the results of the voting in real time.  |
+| `worker` | A .NET worker which consumes votes and stores them in the database.    |
+| `db`     | A Postgres database backed by a Docker volume.                         |
+| `redis`  | A Redis instance which collects new votes.                             |
+| `seed`   | A utility container that seeds the database with mock data.            |
+
+The `vote`, `result`, and `worker` services are built from code in this
+repository, whereas `db` and `redis` use pre-existing Postgres and Redis images
+from Docker Hub. The `seed` service is a utility that invokes requests against
+the front-end service to populate the database, for testing purposes.
+
+## Build with Compose
+
+When you spin up a Docker Compose project, any services that define the `build`
+property are automatically built before the service is started. Here's the
+build configuration for the `vote` service in the example repository:
+
+```yaml {title="compose.yaml"}
+services:
+  vote:
+    build:
+      context: ./vote # Build context
+      target: dev # Dockerfile stage
+```
+
+The `vote`, `result`, and `worker` services all have a build configuration
+specified. Running `docker compose up` will trigger a build of these services.
+
+Did you know that you can also use Compose just to build the service images?
+The `docker compose build` command lets you invoke a build using the build
+configuration specified in the Compose file. For example, to build the `vote`
+service with this configuration, run:
+
+```console
+$ docker compose build vote
+```
+
+Omit the service name to build all services at once:
+
+```console
+$ docker compose build
+```
+
+The `docker compose build` command is useful when you only need to build images
+without running services.
+
+The Compose file format supports a number of properties for defining your
+build's configuration. For example, to specify the tag name for the images, set
+the `image` property on the service.
+
+```yaml
+services:
+  vote:
+    image: username/vote
+    build:
+      context: ./vote
+      target: dev
+    #...
+
+  result:
+    image: username/result
+    build:
+      context: ./result
+    #...
+
+  worker:
+    image: username/worker
+    build:
+      context: ./worker
+    #...
+```
+
+Running `docker compose build` creates three service images with fully
+qualified image names that you can push to Docker Hub.
+
+The `build` property supports a [wide range](/reference/compose-file/build.md)
+of options for configuring builds. However, building production-grade images
+are often different from images used in local development. To avoid cluttering
+your Compose file with build configurations that might not be desirable for
+local builds, consider separating the production builds from the local builds
+by using Bake to build images for release. This approach separates concerns:
+using Compose for local development and Bake for production-ready builds, while
+still reusing service definitions and fundamental build configurations.
+
+## Build with Bake
+
+Like Compose, Bake parses the build definition for a project from a
+configuration file. Bake supports HashiCorp Configuration Language (HCL), JSON,
+and the Docker Compose YAML format. When you use Bake with multiple files, it
+will find and merge all of the applicable configuration files into one unified
+build configuration. The build options defined in your Compose file are
+extended, or in some cases overridden, by options specified in the Bake file.
+
+The following section explores how you can use Bake to extend the build options
+defined in your Compose file for production.
+
+### View the build configuration
+
+Bake automatically creates a build configuration from the `build` properties of
+your services. Use the `--print` flag for Bake to view the build configuration
+for a given Compose file. This flag evaluates the build configuration and
+outputs the build definition in JSON format.
+
+```console
+$ docker buildx bake --print
+```
+
+The JSON-formatted output shows the group that would be executed, and all the
+targets of that group. A group is a collection of builds, and a target
+represents a single build.
+
+```json
+{
+  "group": {
+    "default": {
+      "targets": [
+        "vote",
+        "result",
+        "worker",
+        "seed"
+      ]
+    }
+  },
+  "target": {
+    "result": {
+      "context": "result",
+      "dockerfile": "Dockerfile",
+    },
+    "seed": {
+      "context": "seed-data",
+      "dockerfile": "Dockerfile",
+    },
+    "vote": {
+      "context": "vote",
+      "dockerfile": "Dockerfile",
+      "target": "dev",
+    },
+    "worker": {
+      "context": "worker",
+      "dockerfile": "Dockerfile",
+    }
+  }
+}
+```
+
+As you can see, Bake has created a `default` group that includes four targets:
+
+- `seed`
+- `vote`
+- `result`
+- `worker`
+
+This group is created automatically from your Compose file; it includes all of
+your services containing a build configuration. To build this group of services
+with Bake, run:
+
+```console
+$ docker buildx bake
+```
+
+### Customize the build group
+
+Start by redefining the default build group that Bake executes. The current
+default group includes a `seed` target — a Compose service used solely to
+populate the database with mock data. Since this target doesn't produce a
+production image, it doesn't need to be included in the build group.
+
+To customize the build configuration that Bake uses, create a new file at the
+root of the repository, alongside your `compose.yaml` file, named
+`docker-bake.hcl`.
+
+```console
+$ touch docker-bake.hcl
+```
+
+Open the Bake file and add the following configuration:
+
+```hcl {title=docker-bake.hcl}
+group "default" {
+  targets = ["vote", "result", "worker"]
+}
+```
+
+Save the file and print your Bake definition again.
+
+```console
+$ docker buildx bake --print
+```
+
+The JSON output shows that the `default` group only includes the targets you
+care about.
+
+```json
+{
+  "group": {
+    "default": {
+      "targets": ["vote", "result", "worker"]
+    }
+  },
+  "target": {
+    "result": {
+      "context": "result",
+      "dockerfile": "Dockerfile",
+      "tags": ["username/result"]
+    },
+    "vote": {
+      "context": "vote",
+      "dockerfile": "Dockerfile",
+      "tags": ["username/vote"],
+      "target": "dev"
+    },
+    "worker": {
+      "context": "worker",
+      "dockerfile": "Dockerfile",
+      "tags": ["username/worker"]
+    }
+  }
+}
+```
+
+Here, the build configuration for each target (context, tags, etc.) is picked
+up from the `compose.yaml` file. The group is defined by the `docker-bake.hcl`
+file.
+
+### Customize targets
+
+The Compose file currently defines the `dev` stage as the build target for the
+`vote` service. That's appropriate for the image that you would run in local
+development, because the `dev` stage includes additional development
+dependencies and configurations. For the production image, however, you'll want
+to target the `final` image instead.
+
+To modify the target stage used by the `vote` service, add the following
+configuration to the Bake file:
+
+```hcl
+target "vote" {
+  target = "final"
+}
+```
+
+This overrides the `target` property specified in the Compose file with a
+different value when you run the build with Bake. The other build options in
+the Compose file (tag, context) remain unmodified. You can verify by inspecting
+the build configuration for the `vote` target with `docker buildx bake --print
+vote`:
+
+```json
+{
+  "group": {
+    "default": {
+      "targets": ["vote"]
+    }
+  },
+  "target": {
+    "vote": {
+      "context": "vote",
+      "dockerfile": "Dockerfile",
+      "tags": ["username/vote"],
+      "target": "final"
+    }
+  }
+}
+```
+
+### Additional build features
+
+Production-grade builds often have different characteristics from development
+builds. Here are a few examples of things you might want to add for production
+images.
+
+Multi-platform
+: For local development, you only need to build images for your local platform,
+since those images are just going to run on your machine. But for images that
+are pushed to a registry, it's often a good idea to build for multiple
+platforms, arm64 and amd64 in particular.
+
+Attestations
+: [Attestations](/manuals/build/metadata/attestations/_index.md) are manifests
+attached to the image that describe how the image was created and what
+components it contains. Attaching attestations to your images helps ensure that
+your images follow software supply chain best practices.
+
+Annotations
+: [Annotations](/manuals/build/metadata/annotations.md) provide descriptive
+metadata for images. Use annotations to record arbitrary information and attach
+it to your image, which helps consumers and tools understand the origin,
+contents, and how to use the image.
+
+> [!TIP]
+> Why not just define these additional build options in the Compose file
+> directly?
+>
+> The `build` property in the Compose file format does not support all build
+> features. Additionally, some features, like multi-platform builds, can
+> drastically increase the time it takes to build a service. For local
+> development, you're better off keeping your build step simple and fast,
+> saving the bells and whistles for release builds.
+
+To add these properties to the images you build with Bake, update the Bake file
+as follows:
+
+```hcl
+group "default" {
+  targets = ["vote", "result", "worker"]
+}
+
+target "_common" {
+  annotations = ["org.opencontainers.image.authors=username"]
+  platforms = ["linux/amd64", "linux/arm64"]
+  attest = [
+    "type=provenance,mode=max",
+    "type=sbom"
+  ]
+}
+
+target "vote" {
+  inherits = ["_common"]
+  target = "final"
+}
+
+target "result" {
+  inherits = ["_common"]
+}
+
+target "worker" {
+  inherits = ["_common"]
+}
+```
+
+This defines a new `_common` target that defines reusable build configuration
+for adding multi-platform support, annotations, and attestations to your
+images. The reusable target is inherited by the build targets.
+
+With these changes, building the project with Bake produces three sets of
+multi-platform images for the `linux/amd64` and `linux/arm64` architectures.
+Each image is decorated with an author annotation, and both SBOM and provenance
+attestation records.
+
+## Conclusions
+
+The pattern demonstrated in this guide provides a useful approach for managing
+production-ready Docker images in projects using Docker Compose. Using Bake
+gives you access to all the powerful features of Buildx and BuildKit, and also
+helps separate your development and build configuration in a reasonable way.
+
+### Further reading
+
+For more information about how to use Bake, check out these resources:
+
+- [Bake documentation](/manuals/build/bake/_index.md)
+- [Building with Bake from a Compose file](/manuals/build/bake/compose-file.md)
+- [Bake file reference](/manuals/build/bake/reference.md)
+- [Mastering multi-platform builds, testing, and more with Docker Buildx Bake](/guides/bake/)
+- [Bake GitHub Action](https://github.com/docker/bake-action)
diff --git a/content/guides/compose-bake/index.md b/content/guides/compose-bake/index.md
deleted file mode 100644
index c6f4d312366c..000000000000
--- a/content/guides/compose-bake/index.md
+++ /dev/null
@@ -1,402 +0,0 @@
----
-title: Building Compose projects with Bake
-description: Learn how to build Docker Compose projects with Docker Buildx Bake
-summary: |
-  This guide demonstrates how you can use Bake to build production-grade images for Docker Compose projects.
-languages: []
-tags: [devops]
-params:
-  time: 20 minutes
----
-
-This guide explores how you can use Bake to build images for Docker Compose
-projects with multiple services.
-
-[Docker Buildx Bake](/manuals/build/bake/_index.md) is a build orchestration
-tool that enables declarative configuration for your builds, much like Docker
-Compose does for defining runtime stacks. For projects where Docker Compose is
-used to spin up services for local development, Bake offers a way of seamlessly
-extending the project with a production-ready build configuration.
-
-## Prerequisites
-
-This guide assumes that you're familiar with
-
-- Docker Compose
-- [Multi-stage builds](/manuals/build/building/multi-stage.md)
-- [Multi-platform builds](/manuals/build/building/multi-platform.md)
-
-## Orientation
-
-This guide will use the
-[dvdksn/example-voting-app](https://github.com/dvdksn/example-voting-app)
-repository as an example of a monorepo using Docker Compose that can be
-extended with Bake.
-
-```console
-$ git clone https://github.com/dvdksn/example-voting-app.git
-$ cd example-voting-app
-```
-
-This repository uses Docker Compose to define the runtime configurations for
-running the application, in the `compose.yaml` file. This app consists of the
-following services:
-
-| Service  | Description                                                            |
-| -------- | ---------------------------------------------------------------------- |
-| `vote`   | A front-end web app in Python which lets you vote between two options. |
-| `result` | A Node.js web app which shows the results of the voting in real time.  |
-| `worker` | A .NET worker which consumes votes and stores them in the database.    |
-| `db`     | A Postgres database backed by a Docker volume.                         |
-| `redis`  | A Redis instance which collects new votes.                             |
-| `seed`   | A utility container that seeds the database with mock data.            |
-
-The `vote`, `result`, and `worker` services are built from code in this
-repository, whereas `db` and `redis` use pre-existing Postgres and Redis images
-from Docker Hub. The `seed` service is a utility that invokes requests against
-the front-end service to populate the database, for testing purposes.
-
-## Build with Compose
-
-When you spin up a Docker Compose project, any services that define the `build`
-property are automatically built before the service is started. Here's the
-build configuration for the `vote` service in the example repository:
-
-```yaml {title="compose.yaml"}
-services:
-  vote:
-    build:
-      context: ./vote # Build context
-      target: dev # Dockerfile stage
-```
-
-The `vote`, `result`, and `worker` services all have a build configuration
-specified. Running `docker compose up` will trigger a build of these services.
-
-Did you know that you can also use Compose just to build the service images?
-The `docker compose build` command lets you invoke a build using the build
-configuration specified in the Compose file. For example, to build the `vote`
-service with this configuration, run:
-
-```console
-$ docker compose build vote
-```
-
-Omit the service name to build all services at once:
-
-```console
-$ docker compose build
-```
-
-The `docker compose build` command is useful when you only need to build images
-without running services.
-
-The Compose file format supports a number of properties for defining your
-build's configuration. For example, to specify the tag name for the images, set
-the `image` property on the service.
-
-```yaml
-services:
-  vote:
-    image: username/vote
-    build:
-      context: ./vote
-      target: dev
-    #...
-
-  result:
-    image: username/result
-    build:
-      context: ./result
-    #...
-
-  worker:
-    image: username/worker
-    build:
-      context: ./worker
-    #...
-```
-
-Running `docker compose build` creates three service images with fully
-qualified image names that you can push to Docker Hub.
-
-The `build` property supports a [wide range](/reference/compose-file/build.md)
-of options for configuring builds. However, building production-grade images
-are often different from images used in local development. To avoid cluttering
-your Compose file with build configurations that might not be desirable for
-local builds, consider separating the production builds from the local builds
-by using Bake to build images for release. This approach separates concerns:
-using Compose for local development and Bake for production-ready builds, while
-still reusing service definitions and fundamental build configurations.
-
-## Build with Bake
-
-Like Compose, Bake parses the build definition for a project from a
-configuration file. Bake supports HashiCorp Configuration Language (HCL), JSON,
-and the Docker Compose YAML format. When you use Bake with multiple files, it
-will find and merge all of the applicable configuration files into one unified
-build configuration. The build options defined in your Compose file are
-extended, or in some cases overridden, by options specified in the Bake file.
-
-The following section explores how you can use Bake to extend the build options
-defined in your Compose file for production.
-
-### View the build configuration
-
-Bake automatically creates a build configuration from the `build` properties of
-your services. Use the `--print` flag for Bake to view the build configuration
-for a given Compose file. This flag evaluates the build configuration and
-outputs the build definition in JSON format.
-
-```console
-$ docker buildx bake --print
-```
-
-The JSON-formatted output shows the group that would be executed, and all the
-targets of that group. A group is a collection of builds, and a target
-represents a single build.
-
-```json
-{
-  "group": {
-    "default": {
-      "targets": [
-        "vote",
-        "result",
-        "worker",
-        "seed"
-      ]
-    }
-  },
-  "target": {
-    "result": {
-      "context": "result",
-      "dockerfile": "Dockerfile",
-    },
-    "seed": {
-      "context": "seed-data",
-      "dockerfile": "Dockerfile",
-    },
-    "vote": {
-      "context": "vote",
-      "dockerfile": "Dockerfile",
-      "target": "dev",
-    },
-    "worker": {
-      "context": "worker",
-      "dockerfile": "Dockerfile",
-    }
-  }
-}
-```
-
-As you can see, Bake has created a `default` group that includes four targets:
-
-- `seed`
-- `vote`
-- `result`
-- `worker`
-
-This group is created automatically from your Compose file; it includes all of
-your services containing a build configuration. To build this group of services
-with Bake, run:
-
-```console
-$ docker buildx bake
-```
-
-### Customize the build group
-
-Start by redefining the default build group that Bake executes. The current
-default group includes a `seed` target — a Compose service used solely to
-populate the database with mock data. Since this target doesn't produce a
-production image, it doesn’t need to be included in the build group.
-
-To customize the build configuration that Bake uses, create a new file at the
-root of the repository, alongside your `compose.yaml` file, named
-`docker-bake.hcl`.
-
-```console
-$ touch docker-bake.hcl
-```
-
-Open the Bake file and add the following configuration:
-
-```hcl {title=docker-bake.hcl}
-group "default" {
-  targets = ["vote", "result", "worker"]
-}
-```
-
-Save the file and print your Bake definition again.
-
-```console
-$ docker buildx bake --print
-```
-
-The JSON output shows that the `default` group only includes the targets you
-care about.
-
-```json
-{
-  "group": {
-    "default": {
-      "targets": ["vote", "result", "worker"]
-    }
-  },
-  "target": {
-    "result": {
-      "context": "result",
-      "dockerfile": "Dockerfile",
-      "tags": ["username/result"]
-    },
-    "vote": {
-      "context": "vote",
-      "dockerfile": "Dockerfile",
-      "tags": ["username/vote"],
-      "target": "dev"
-    },
-    "worker": {
-      "context": "worker",
-      "dockerfile": "Dockerfile",
-      "tags": ["username/worker"]
-    }
-  }
-}
-```
-
-Here, the build configuration for each target (context, tags, etc.) is picked
-up from the `compose.yaml` file. The group is defined by the `docker-bake.hcl`
-file.
-
-### Customize targets
-
-The Compose file currently defines the `dev` stage as the build target for the
-`vote` service. That's appropriate for the image that you would run in local
-development, because the `dev` stage includes additional development
-dependencies and configurations. For the production image, however, you'll want
-to target the `final` image instead.
-
-To modify the target stage used by the `vote` service, add the following
-configuration to the Bake file:
-
-```hcl
-target "vote" {
-  target = "final"
-}
-```
-
-This overrides the `target` property specified in the Compose file with a
-different value when you run the build with Bake. The other build options in
-the Compose file (tag, context) remain unmodified. You can verify by inspecting
-the build configuration for the `vote` target with `docker buildx bake --print
-vote`:
-
-```json
-{
-  "group": {
-    "default": {
-      "targets": ["vote"]
-    }
-  },
-  "target": {
-    "vote": {
-      "context": "vote",
-      "dockerfile": "Dockerfile",
-      "tags": ["username/vote"],
-      "target": "final"
-    }
-  }
-}
-```
-
-### Additional build features
-
-Production-grade builds often have different characteristics from development
-builds. Here are a few examples of things you might want to add for production
-images.
-
-Multi-platform
-: For local development, you only need to build images for your local platform,
-since those images are just going to run on your machine. But for images that
-are pushed to a registry, it's often a good idea to build for multiple
-platforms, arm64 and amd64 in particular.
-
-Attestations
-: [Attestations](/manuals/build/metadata/attestations/_index.md) are manifests
-attached to the image that describe how the image was created and what
-components it contains. Attaching attestations to your images helps ensure that
-your images follow software supply chain best practices.
-
-Annotations
-: [Annotations](/manuals/build/metadata/annotations.md) provide descriptive
-metadata for images. Use annotations to record arbitrary information and attach
-it to your image, which helps consumers and tools understand the origin,
-contents, and how to use the image.
-
-> [!TIP]
-> Why not just define these additional build options in the Compose file
-> directly?
->
-> The `build` property in the Compose file format does not support all build
-> features. Additionally, some features, like multi-platform builds, can
-> drastically increase the time it takes to build a service. For local
-> development, you're better off keeping your build step simple and fast,
-> saving the bells and whistles for release builds.
-
-To add these properties to the images you build with Bake, update the Bake file
-as follows:
-
-```hcl
-group "default" {
-  targets = ["vote", "result", "worker"]
-}
-
-target "_common" {
-  annotations = ["org.opencontainers.image.authors=username"]
-  platforms = ["linux/amd64", "linux/arm64"]
-  attest = [
-    "type=provenance,mode=max",
-    "type=sbom"
-  ]
-}
-
-target "vote" {
-  inherits = ["_common"]
-  target = "final"
-}
-
-target "result" {
-  inherits = ["_common"]
-}
-
-target "worker" {
-  inherits = ["_common"]
-}
-```
-
-This defines a new `_common` target that defines reusable build configuration
-for adding multi-platform support, annotations, and attestations to your
-images. The reusable target is inherited by the build targets.
-
-With these changes, building the project with Bake produces three sets of
-multi-platform images for the `linux/amd64` and `linux/arm64` architectures.
-Each image is decorated with an author annotation, and both SBOM and provenance
-attestation records.
-
-## Conclusions
-
-The pattern demonstrated in this guide provides a useful approach for managing
-production-ready Docker images in projects using Docker Compose. Using Bake
-gives you access to all the powerful features of Buildx and BuildKit, and also
-helps separate your development and build configuration in a reasonable way.
-
-### Further reading
-
-For more information about how to use Bake, check out these resources:
-
-- [Bake documentation](/manuals/build/bake/_index.md)
-- [Building with Bake from a Compose file](/manuals/build/bake/compose-file.md)
-- [Bake file reference](/manuals/build/bake/reference.md)
-- [Mastering multi-platform builds, testing, and more with Docker Buildx Bake](/guides/bake/index.md)
-- [Bake GitHub Action](https://github.com/docker/bake-action)
diff --git a/content/guides/container-supported-development.md b/content/guides/container-supported-development.md
index 5a2f142f9237..a5239165a053 100644
--- a/content/guides/container-supported-development.md
+++ b/content/guides/container-supported-development.md
@@ -1,12 +1,13 @@
 ---
 title: "Faster development and testing with container-supported development"
-linkTitle: Container-supported development
+linkTitle: Container-supported dev
 summary: |
   Containers don't have to be just for your app. Learn how to run your app's dependent services and other debugging tools to enhance your development environment.
 description: |
   Use containers in your local development loop to develop and test faster… even if your main app isn't running in containers.
-tags: [app-dev]
+keywords: containers, local development, dependent services, testing, debugging, development environment
 params:
+  tags: [cicd]
   image: images/learning-paths/container-supported-development.png
   time: 20 minutes
   resource_links: []
@@ -32,7 +33,6 @@ And best of all, you can have these benefits regardless of whether the main app
 - Developers that want to make it easier to visualize what's going on in their databases, queues, etc.
 - Teams that want to reduce the complexity of setting up their development environment without impacting the development of the app itself
 
-
 ## Tools integration
 
 Works well with Docker Compose and Testcontainers.
@@ -69,7 +69,7 @@ This demo will demonstrate how using WireMock can make it easy to develop and te
 
 ### Demo: developing the cloud locally
 
-When developing apps, it's often easier to outsource aspects of the application to cloud services, such as Amazon S3. However, connecting to those services in local development introduces IAM policies, networking constraints, and provisioning complications. While these requirements are important in a production setting, they complicate development environments significantly. 
+When developing apps, it's often easier to outsource aspects of the application to cloud services, such as Amazon S3. However, connecting to those services in local development introduces IAM policies, networking constraints, and provisioning complications. While these requirements are important in a production setting, they complicate development environments significantly.
 
 With container-supported development, you can run local instances of these services during development and testing, removing the need for complex setups. In this demo, you'll see how LocalStack makes it easy to develop and test applications entirely from the developer's workstation.
 
diff --git a/content/guides/cpp.md b/content/guides/cpp.md
new file mode 100644
index 000000000000..bb0d2e3b2c83
--- /dev/null
+++ b/content/guides/cpp.md
@@ -0,0 +1,276 @@
+---
+title: C++ language-specific guide
+linkTitle: C++
+description: Containerize and develop C++ applications using Docker.
+keywords: getting started, c++
+summary: |
+  This guide explains how to containerize C++ applications using Docker.
+aliases:
+  - /language/cpp/
+  - /guides/language/cpp/
+  - /language/cpp/containerize/
+  - /language/cpp/develop/
+  - /language/cpp/configure-ci-cd/
+  - /language/cpp/deploy/
+  - /guides/cpp/configure-ci-cd/
+  - /guides/cpp/containerize/
+  - /guides/cpp/deploy/
+  - /guides/cpp/develop/
+  - /guides/cpp/multistage/
+  - /guides/cpp/security/
+params:
+  tags: [languages]
+  time: 20 minutes
+---
+
+The C++ getting started guide teaches you how to create a containerized C++ application using Docker. In this guide, you'll learn how to:
+
+> **Acknowledgment**
+>
+> Docker would like to thank [Pradumna Saraf](https://twitter.com/pradumna_saraf) and [Mohammad-Ali A'râbi](https://twitter.com/MohammadAliEN) for their contribution to this guide.
+
+- Containerize and run a C++ application using a multi-stage Docker build
+- Build and run a C++ application using Docker Compose
+- Set up a local environment to develop a C++ application using containers
+
+After completing the C++ getting started modules, you should be able to containerize your own C++ application based on the examples and instructions provided in this guide.
+
+Start by containerizing an existing C++ application.
+
+## Create a multi-stage build for your C++ application
+
+### Prerequisites
+
+- You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
+
+### Overview
+
+This section walks you through creating a multi-stage Docker build for a C++ application.
+A multi-stage build is a Docker feature that allows you to use different base images for different stages of the build process,
+so you can optimize the size of your final image and separate build dependencies from runtime dependencies.
+
+The standard practice for compiled languages like C++ is to have a build stage that compiles the code and a runtime stage that runs the compiled binary,
+because the build dependencies are not needed at runtime.
+
+### Get the sample application
+
+Let's use a simple C++ application that prints `Hello, World!` to the terminal. To do so, clone the sample repository to use with this guide:
+
+```bash
+$ git clone https://github.com/dockersamples/c-plus-plus-docker.git
+```
+
+The example for this section is under the `hello` directory in the repository. Get inside it and take a look at the files:
+
+```bash
+$ cd c-plus-plus-docker/hello
+$ ls
+```
+
+You should see the following files:
+
+```text
+Dockerfile  hello.cpp
+```
+
+### Check the Dockerfile
+
+Open the `Dockerfile` in an IDE or text editor. The `Dockerfile` contains the instructions for building the Docker image.
+
+```Dockerfile
+# Stage 1: Build stage
+FROM ubuntu:latest AS build
+
+# Install build-essential for compiling C++ code
+RUN apt-get update && apt-get install -y build-essential
+
+# Set the working directory
+WORKDIR /app
+
+# Copy the source code into the container
+COPY hello.cpp .
+
+# Compile the C++ code statically to ensure it doesn't depend on runtime libraries
+RUN g++ -o hello hello.cpp -static
+
+# Stage 2: Runtime stage
+FROM scratch
+
+# Copy the static binary from the build stage
+COPY --from=build /app/hello /hello
+
+# Command to run the binary
+CMD ["/hello"]
+```
+
+The `Dockerfile` has two stages:
+
+1. **Build stage**: This stage uses the `ubuntu:latest` image to compile the C++ code and create a static binary.
+2. **Runtime stage**: This stage uses the `scratch` image, which is an empty image, to copy the static binary from the build stage and run it.
+
+### Build the Docker image
+
+To build the Docker image, run the following command in the `hello` directory:
+
+```bash
+$ docker build -t hello .
+```
+
+The `-t` flag tags the image with the name `hello`.
+
+### Run the Docker container
+
+To run the Docker container, use the following command:
+
+```bash
+$ docker run hello
+```
+
+You should see the output `Hello, World!` in the terminal.
+
+Because the final image uses an empty `scratch` base, it contains only the
+static binary and none of the build dependencies or usual OS tools. For
+example, you can't run a simple `ls` command in the container:
+
+```bash
+$ docker run hello ls
+```
+
+The absence of a shell and other tools keeps the image small and reduces its
+attack surface.
+
+## Containerize a C++ application
+
+### Prerequisites
+
+- You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
+
+### Overview
+
+This section walks you through containerizing and running a C++ application, using Docker Compose.
+
+### Get the sample application
+
+We're using the same sample repository that you used in the previous sections of this guide. If you haven't already cloned the repository, clone it now:
+
+```console
+$ git clone https://github.com/dockersamples/c-plus-plus-docker.git
+```
+
+You should now have the following contents in your `c-plus-plus-docker` (root)
+directory.
+
+```text
+├── c-plus-plus-docker/
+│ ├── compose.yml
+│ ├── Dockerfile
+│ ├── LICENSE
+│ ├── ok_api.cpp
+│ └── README.md
+
+```
+
+To learn more about the files in the repository, see the following:
+
+- [Dockerfile](/reference/dockerfile.md)
+- [.dockerignore](/reference/dockerfile.md#dockerignore-file)
+- [compose.yml](/reference/compose-file/_index.md)
+
+### Run the application
+
+Inside the `c-plus-plus-docker` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You will see a message `{"Status" : "OK"}` in the browser.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `c-plus-plus-docker` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080).
+
+In the terminal, run the following command to stop the application.
+
+```console
+$ docker compose down
+```
+
+For more information about Compose commands, see the [Compose CLI
+reference](/reference/cli/docker/compose/).
+
+## Use containers for C++ development
+
+### Prerequisites
+
+Complete [Containerize a C++ application](#containerize-a-c-application).
+
+### Overview
+
+In this section, you'll learn how to set up a development environment for your containerized application. This includes:
+
+- Configuring Compose to automatically update your running Compose services as you edit and save your code
+
+### Get the sample application
+
+Clone the sample application to use with this guide. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
+
+```console
+$ git clone https://github.com/dockersamples/c-plus-plus-docker.git && cd c-plus-plus-docker
+```
+
+### Automatically update services
+
+Use Compose Watch to automatically update your running Compose services as you
+edit and save your code. For more details about Compose Watch, see [Use Compose
+Watch](/manuals/compose/how-tos/file-watch.md).
+
+Open your `compose.yml` file in an IDE or text editor and then add the Compose Watch instructions. The following example shows how to add Compose Watch to your `compose.yml` file.
+
+```yaml {hl_lines="11-14",linenos=true}
+services:
+  ok-api:
+    image: ok-api
+    build:
+      context: .
+      dockerfile: Dockerfile
+    ports:
+      - "8080:8080"
+    develop:
+      watch:
+        - action: rebuild
+          path: .
+```
+
+Run the following command to run your application with Compose Watch.
+
+```console
+$ docker compose watch
+```
+
+Now, if you modify your `ok_api.cpp` you will see the changes in real time without re-building the image.
+
+To test it out, open the `ok_api.cpp` file in your favorite text editor and change the message from `{"Status" : "OK"}` to `{"Status" : "Updated"}`. Save the file and refresh your browser at [http://localhost:8080](http://localhost:8080). You should see the updated message.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Summary
+
+In this section, you also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
+
+Related information:
+
+- [Compose file reference](/reference/compose-file/)
+- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
+- [Multi-stage builds](/manuals/build/building/multi-stage.md)
diff --git a/content/guides/cpp/_index.md b/content/guides/cpp/_index.md
deleted file mode 100644
index 85f317765e3c..000000000000
--- a/content/guides/cpp/_index.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: C++ language-specific guide
-linkTitle: C++
-description: Containerize and develop C++ applications using Docker.
-keywords: getting started, c++
-summary: |
-  This guide explains how to containerize C++ applications using Docker.
-toc_min: 1
-toc_max: 2
-aliases:
-  - /language/cpp/
-  - /guides/language/cpp/
-languages: [cpp]
-params:
-  time: 20 minutes
----
-
-The C++ getting started guide teaches you how to create a containerized C++ application using Docker. In this guide, you'll learn how to:
-
-> **Acknowledgment**
->
-> Docker would like to thank [Pradumna Saraf](https://twitter.com/pradumna_saraf) and [Mohammad-Ali A'râbi](https://twitter.com/MohammadAliEN) for their contribution to this guide.
-
-- Containerize and run a C++ application using a multi-stage Docker build
-- Build and run a C++ application using Docker Compose
-- Set up a local environment to develop a C++ application using containers
-- Configure a CI/CD pipeline for a containerized C++ application using GitHub Actions
-- Deploy your containerized application locally to Kubernetes to test and debug your deployment
-- Use BuildKit to generate SBOM attestations during the build process
-
-After completing the C++ getting started modules, you should be able to containerize your own C++ application based on the examples and instructions provided in this guide.
-
-Start by containerizing an existing C++ application.
diff --git a/content/guides/cpp/configure-ci-cd.md b/content/guides/cpp/configure-ci-cd.md
deleted file mode 100644
index f16d54b8b006..000000000000
--- a/content/guides/cpp/configure-ci-cd.md
+++ /dev/null
@@ -1,133 +0,0 @@
----
-title: Configure CI/CD for your C++ application
-linkTitle: Configure CI/CD
-weight: 40
-keywords: ci/cd, github actions, c++, shiny
-description: Learn how to configure CI/CD using GitHub Actions for your C++ application.
-aliases:
-  - /language/cpp/configure-ci-cd/
-  - /guides/language/cpp/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a C++ application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-## Overview
-
-In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps:
-
-1. Create a new repository on GitHub.
-2. Define the GitHub Actions workflow.
-3. Run the workflow.
-
-## Step one: Create the repository
-
-Create a GitHub repository, configure the Docker Hub credentials, and push your source code.
-
-1. [Create a new repository](https://github.com/new) on GitHub.
-
-2. Open the repository **Settings**, and go to **Secrets and variables** >
-   **Actions**.
-
-3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-4. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-5. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-6. In your local repository on your machine, run the following command to change
-   the origin to the repository you just created. Make sure you change
-   `your-username` to your GitHub username and `your-repository` to the name of
-   the repository you created.
-
-   ```console
-   $ git remote set-url origin https://github.com/your-username/your-repository.git
-   ```
-
-7. Run the following commands to stage, commit, and push your local repository to GitHub.
-
-   ```console
-   $ git add -A
-   $ git commit -m "my commit"
-   $ git push -u origin main
-   ```
-
-## Step two: Set up the workflow
-
-Set up your GitHub Actions workflow for building, testing, and pushing the image
-to Docker Hub.
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-
-2. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub actions workflow file in
-   your repository, under `.github/workflows/main.yml` by default.
-
-3. In the editor window, copy and paste the following YAML configuration and commit the changes.
-
-   ```yaml
-   name: ci
-
-   on:
-     push:
-       branches:
-         - main
-
-   jobs:
-     build:
-       runs-on: ubuntu-latest
-       steps:
-         - name: Login to Docker Hub
-           uses: docker/login-action@v3
-           with:
-             username: ${{ vars.DOCKER_USERNAME }}
-             password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-         - name: Set up Docker Buildx
-           uses: docker/setup-buildx-action@v3
-
-         - name: Build and push
-           uses: docker/build-push-action@v6
-           with:
-             platforms: linux/amd64,linux/arm64
-             push: true
-             tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-   ```
-
-   For more information about the YAML syntax for `docker/build-push-action`,
-   refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
-## Step three: Run the workflow
-
-Save the workflow file and run the job.
-
-1. Select **Commit changes...** and push the changes to the `main` branch.
-
-   After pushing the commit, the workflow starts automatically.
-
-2. Go to the **Actions** tab. It displays the workflow.
-
-   Selecting the workflow shows you the breakdown of all the steps.
-
-3. When the workflow is complete, go to your
-   [repositories on Docker Hub](https://hub.docker.com/repositories).
-
-   If you see the new repository in that list, it means the GitHub Actions
-   successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your C++ application.
-
-Related information:
-
-- [Introduction to GitHub Actions](/guides/gha.md)
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md)
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-Next, learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/cpp/containerize.md b/content/guides/cpp/containerize.md
deleted file mode 100644
index 96c19430b883..000000000000
--- a/content/guides/cpp/containerize.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: Containerize a C++ application
-linkTitle: Build and run a C++ application using Docker Compose
-weight: 10
-keywords: C++, containerize, initialize
-description: Learn how to use Docker Compose to build and run a C++ application.
-aliases:
-  - /language/cpp/containerize/
-  - /guides/language/cpp/containerize/
----
-
-## Prerequisites
-
-- You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
-
-## Overview
-
-This section walks you through containerizing and running a C++ application, using Docker Compose.
-
-## Get the sample application
-
-We're using the same sample repository that you used in the previous sections of this guide. If you haven't already cloned the repository, clone it now:
-
-```console
-$ git clone https://github.com/dockersamples/c-plus-plus-docker.git
-```
-
-You should now have the following contents in your `c-plus-plus-docker` (root)
-directory.
-
-```text
-├── c-plus-plus-docker/
-│ ├── compose.yml
-│ ├── Dockerfile
-│ ├── LICENSE
-│ ├── ok_api.cpp
-│ └── README.md
-
-```
-
-To learn more about the files in the repository, see the following:
-
-- [Dockerfile](/reference/dockerfile.md)
-- [.dockerignore](/reference/dockerfile.md#dockerignore-file)
-- [compose.yml](/reference/compose-file/_index.md)
-
-## Run the application
-
-Inside the `c-plus-plus-docker` directory, run the following command in a
-terminal.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You will see a message `{"Status" : "OK"}` in the browser.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-### Run the application in the background
-
-You can run the application detached from the terminal by adding the `-d`
-option. Inside the `c-plus-plus-docker` directory, run the following command
-in a terminal.
-
-```console
-$ docker compose up --build -d
-```
-
-Open a browser and view the application at [http://localhost:8080](http://localhost:8080).
-
-In the terminal, run the following command to stop the application.
-
-```console
-$ docker compose down
-```
-
-For more information about Compose commands, see the [Compose CLI
-reference](/reference/cli/docker/compose/_index.md).
-
-## Summary
-
-In this section, you learned how you can containerize and run your C++
-application using Docker.
-
-Related information:
-
-- [Docker Compose overview](/manuals/compose/_index.md)
-
-## Next steps
-
-In the next section, you'll learn how you can develop your application using
-containers.
diff --git a/content/guides/cpp/deploy.md b/content/guides/cpp/deploy.md
deleted file mode 100644
index e023bdd5b12e..000000000000
--- a/content/guides/cpp/deploy.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title: Test your C++ deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, kubernetes, c++
-description: Learn how to develop locally using Kubernetes
-aliases:
-  - /language/cpp/deploy/
-  - /guides/language/cpp/deploy/
----
-
-## Prerequisites
-
-- Complete all the previous sections of this guide, starting with [Containerize a C++ application](containerize.md).
-- [Turn on Kubernetes](/manuals/desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This allows you to test and debug your workloads on Kubernetes locally before deploying.
-
-## Create a Kubernetes YAML file
-
-In your `c-plus-plus-docker` directory, create a file named
-`docker-kubernetes.yml`. Open the file in an IDE or text editor and add
-the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker
-username and the name of the repository that you created in [Configure CI/CD for
-your C++ application](configure-ci-cd.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: docker-c-plus-plus-demo
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      service: ok-api
-  template:
-    metadata:
-      labels:
-        service: ok-api
-    spec:
-      containers:
-        - name: ok-api-service
-          image: DOCKER_USERNAME/REPO_NAME
-          imagePullPolicy: Always
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: service-entrypoint
-  namespace: default
-spec:
-  type: NodePort
-  selector:
-    service: ok-api
-  ports:
-    - port: 8080
-      targetPort: 8080
-      nodePort: 30001
-```
-
-In this Kubernetes YAML file, there are two objects, separated by the `---`:
-
-- A Deployment, describing a scalable group of identical pods. In this case,
-  you'll get just one replica, or copy of your pod. That pod, which is
-  described under `template`, has just one container in it. The
-  container is created from the image built by GitHub Actions in [Configure CI/CD for
-  your C++ application](configure-ci-cd.md).
-- A NodePort service, which will route traffic from port 30001 on your host to
-  port 8080 inside the pods it routes to, allowing you to reach your app
-  from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to `c-plus-plus-docker` and deploy your application to
-   Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-kubernetes.yml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```text
-   deployment.apps/docker-c-plus-plus-demo created
-   service/service-entrypoint created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```shell
-   NAME                     READY   UP-TO-DATE   AVAILABLE    AGE
-   docker-c-plus-plus-demo   1/1     1            1           10s
-   ```
-
-   This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```shell
-   NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
-   kubernetes           ClusterIP   10.96.0.1        <none>        443/TCP          88m
-   service-entrypoint   NodePort    10.105.145.223   <none>        8080:30001/TCP   83s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP.
-
-3. In a browser, visit the following address. You should see the message `{"Status" : "OK"}`.
-
-   ```console
-   http://localhost:30001/
-   ```
-
-4. Run the following command to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-kubernetes.yml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your C++ application to a fully-featured Kubernetes environment on your development machine.
-
-Related information:
-
-- [Kubernetes documentation](https://kubernetes.io/docs/home/)
-- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-- [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/cpp/develop.md b/content/guides/cpp/develop.md
deleted file mode 100644
index 016eac56cefa..000000000000
--- a/content/guides/cpp/develop.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: Use containers for C++ development
-linkTitle: Develop your app
-weight: 20
-keywords: C++, local, development
-description: Learn how to develop your C++ application locally.
-aliases:
-  - /language/cpp/develop/
-  - /guides/language/cpp/develop/
----
-
-## Prerequisites
-
-Complete [Containerize a C++ application](containerize.md).
-
-## Overview
-
-In this section, you'll learn how to set up a development environment for your containerized application. This includes:
-
-- Configuring Compose to automatically update your running Compose services as you edit and save your code
-
-## Get the sample application
-
-Clone the sample application to use with this guide. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
-
-```console
-$ git clone https://github.com/dockersamples/c-plus-plus-docker.git && cd c-plus-plus-docker
-```
-
-## Automatically update services
-
-Use Compose Watch to automatically update your running Compose services as you
-edit and save your code. For more details about Compose Watch, see [Use Compose
-Watch](/manuals/compose/how-tos/file-watch.md).
-
-Open your `compose.yml` file in an IDE or text editor and then add the Compose Watch instructions. The following example shows how to add Compose Watch to your `compose.yml` file.
-
-```yaml {hl_lines="11-14",linenos=true}
-services:
-  ok-api:
-    image: ok-api
-    build:
-      context: .
-      dockerfile: Dockerfile
-    ports:
-      - "8080:8080"
-    develop:
-      watch:
-        - action: rebuild
-          path: .
-```
-
-Run the following command to run your application with Compose Watch.
-
-```console
-$ docker compose watch
-```
-
-Now, if you modify your `ok_api.cpp` you will see the changes in real time without re-building the image.
-
-To test it out, open the `ok_api.cpp` file in your favorite text editor and change the message from `{"Status" : "OK"}` to `{"Status" : "Updated"}`. Save the file and refresh your browser at [http://localhost:8080](http://localhost:8080). You should see the updated message.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Summary
-
-In this section, you also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
-
-Related information:
-
-- [Compose file reference](/reference/compose-file/)
-- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
-- [Multi-stage builds](/manuals/build/building/multi-stage.md)
-
-## Next steps
-
-In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions.
diff --git a/content/guides/cpp/multistage.md b/content/guides/cpp/multistage.md
deleted file mode 100644
index 0dbd3e35f58b..000000000000
--- a/content/guides/cpp/multistage.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Create a multi-stage build for your C++ application
-linkTitle: Containerize your app using a multi-stage build
-weight: 5
-keywords: C++, containerize, multi-stage
-description: Learn how to create a multi-stage build for a C++ application.
-aliases:
-- /language/cpp/multistage/
-- /guides/language/cpp/multistage/
----
-
-## Prerequisites
-
-- You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
-
-## Overview
-
-This section walks you through creating a multi-stage Docker build for a C++ application.
-A multi-stage build is a Docker feature that allows you to use different base images for different stages of the build process,
-so you can optimize the size of your final image and separate build dependencies from runtime dependencies.
-
-The standard practice for compiled languages like C++ is to have a build stage that compiles the code and a runtime stage that runs the compiled binary,
-because the build dependencies are not needed at runtime.
-
-## Get the sample application
-
-Let's use a simple C++ application that prints `Hello, World!` to the terminal. To do so, clone the sample repository to use with this guide:
-
-```bash
-$ git clone https://github.com/dockersamples/c-plus-plus-docker.git
-```
-
-The example for this section is under the `hello` directory in the repository. Get inside it and take a look at the files:
-
-```bash
-$ cd c-plus-plus-docker/hello
-$ ls
-```
-
-You should see the following files:
-
-```text
-Dockerfile  hello.cpp
-```
-
-## Check the Dockerfile
-
-Open the `Dockerfile` in an IDE or text editor. The `Dockerfile` contains the instructions for building the Docker image.
-
-```Dockerfile
-# Stage 1: Build stage
-FROM ubuntu:latest AS build
-
-# Install build-essential for compiling C++ code
-RUN apt-get update && apt-get install -y build-essential
-
-# Set the working directory
-WORKDIR /app
-
-# Copy the source code into the container
-COPY hello.cpp .
-
-# Compile the C++ code statically to ensure it doesn't depend on runtime libraries
-RUN g++ -o hello hello.cpp -static
-
-# Stage 2: Runtime stage
-FROM scratch
-
-# Copy the static binary from the build stage
-COPY --from=build /app/hello /hello
-
-# Command to run the binary
-CMD ["/hello"]
-```
-
-The `Dockerfile` has two stages:
-
-1. **Build stage**: This stage uses the `ubuntu:latest` image to compile the C++ code and create a static binary.
-2. **Runtime stage**: This stage uses the `scratch` image, which is an empty image, to copy the static binary from the build stage and run it.
-
-## Build the Docker image
-
-To build the Docker image, run the following command in the `hello` directory:
-
-```bash
-$ docker build -t hello .
-```
-
-The `-t` flag tags the image with the name `hello`.
-
-## Run the Docker container
-
-To run the Docker container, use the following command:
-
-```bash
-$ docker run hello
-```
-
-You should see the output `Hello, World!` in the terminal.
-
-## Summary
-
-In this section, you learned how to create a multi-stage build for a C++ application. Multi-stage builds help you optimize the size of your final image and separate build dependencies from runtime dependencies.
-In this example, the final image only contains the static binary and doesn't include any build dependencies.
-
-As the image has an empty base, the usual OS tools are also absent. So, for example, you can't run a simple `ls` command in the container:
-
-```bash
-$ docker run hello ls
-```
-
-This makes the image very lightweight and secure.
diff --git a/content/guides/cpp/security.md b/content/guides/cpp/security.md
deleted file mode 100644
index 733c23c9a82b..000000000000
--- a/content/guides/cpp/security.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: Supply-chain security for C++ Docker images
-linkTitle: Supply-chain security
-weight: 60
-keywords: C++, security, multi-stage
-description: Learn how to extract SBOMs from C++ Docker images.
-aliases:
-- /language/cpp/security/
-- /guides/language/cpp/security/
----
-
-## Prerequisites
-
-- You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
-- You have a Docker Desktop installed, with containerd enabled for pulling and storing images (it's a checkbox in **Settings** > **General**). Otherwise, if you use Docker Engine:
-  - You have the [Docker SBOM CLI plugin](https://github.com/docker/sbom-cli-plugin) installed. To install it on Docker Engine, use the following command:
-
-    ```bash
-    $ curl -sSfL https://raw.githubusercontent.com/docker/sbom-cli-plugin/main/install.sh | sh -s --
-    ```
-
-  - You have the [Docker Scout CLI plugin](https://docs.docker.com/scout/install/) installed. To install it on Docker Engine, use the following command:
-
-    ```bash
-    $ curl -sSfL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh | sh -s --
-    ```
-    
-  - You have [containerd enabled](https://docs.docker.com/engine/storage/containerd/) for Docker Engine.
-
-## Overview
-
-This section walks you through extracting Software Bill of Materials (SBOMs) from a C++ Docker image using the Docker SBOM CLI plugin. SBOMs provide a detailed list of all the components in a software package, including their versions and licenses. You can use SBOMs to track the provenance of your software and ensure that it complies with your organization's security and licensing policies.
-
-## Generate an SBOM
-
-Here we will use the Docker image that we built in the [Create a multi-stage build for your C++ application](/guides/language/cpp/multistage/) guide. If you haven't already built the image, follow the steps in that guide to build the image.
-The image is named `hello`. To generate an SBOM for the `hello` image, run the following command:
-
-```bash
-$ docker sbom hello
-```
-
-The command will say "No packages discovered". This is because the final image is a scratch image and doesn't have any packages.
-Let's try again with Docker Scout:
-
-```bash
-$ docker scout sbom --format=list hello
-```
-
-This command will tell you the same thing.
-
-## Generate an SBOM attestation
-
-The SBOM can be generated during the build process and "attached" to the image. This is called an SBOM attestation.
-To generate an SBOM attestation for the `hello` image, first let's change the Dockerfile:
-
-```Dockerfile
-ARG BUILDKIT_SBOM_SCAN_STAGE=true
-
-FROM ubuntu:latest AS build
-
-RUN apt-get update && apt-get install -y build-essential
-
-WORKDIR /app
-
-COPY hello.cpp .
-
-RUN g++ -o hello hello.cpp -static
-
-# --------------------
-FROM scratch
-
-COPY --from=build /app/hello /hello
-
-CMD ["/hello"]
-```
-
-The first line `ARG BUILDKIT_SBOM_SCAN_STAGE=true` enables SBOM scanning in the build stage.
-Now, build the image with the following command:
-
-```bash
-$ docker buildx build --sbom=true -t hello:sbom .
-```
-
-This command will build the image and generate an SBOM attestation. You can verify that the SBOM is attached to the image by running the following command:
-
-```bash
-$ docker scout sbom --format=list hello:sbom
-```
-
-Note that the normal `docker sbom` command will not load the SBOM attestation.
-
-## Summary
-
-In this section, you learned how to generate SBOM attestation for a C++ Docker image during the build process.
-The normal image scanners will not be able to generate SBOMs from scratch images.
\ No newline at end of file
diff --git a/content/guides/databases.md b/content/guides/databases.md
index 2ed465343d30..8bbcbdefe043 100644
--- a/content/guides/databases.md
+++ b/content/guides/databases.md
@@ -4,10 +4,10 @@ keywords: database, mysql
 title: Use containerized databases
 summary: |
   Learn how to effectively run and manage databases as containers.
-tags: [databases]
 aliases:
   - /guides/use-case/databases/
 params:
+  tags: [databases]
   time: 20 minutes
 ---
 
@@ -68,7 +68,7 @@ In this command:
 - `mysql:latest` specifies that you want to use the latest version of the MySQL
   image.
 
-To verify that you container is running, run `docker ps` in a terminal
+To verify that your container is running, run `docker ps` in a terminal
 
 {{< /tab >}}
 {{< tab name="GUI" >}}
@@ -236,7 +236,7 @@ To run a container using the GUI:
 
 6. Select `Run`.
 7. In the **Containers** view, verify that the port is mapped under the
-   **Port(s)** column. You should see **3307:3306** for the **my-mysql**
+   **Port(s)** column. You should see `3307:3306` for the `my-mysql`
    container.
 
 {{< /tab >}}
@@ -256,7 +256,7 @@ the same Docker network.
 Before you begin, you must remove any containers you previously ran for this
 guide. To stop and remove a container, either:
 
-- In a terminal, run `docker remove --force my-mysql` to remove the container
+- In a terminal, run `docker rm --force my-mysql` to remove the container
   named `my-mysql`.
 - Or, in the Docker Desktop Dashboard, select the **Delete** icon next to your
   container in the **Containers** view.
@@ -311,7 +311,7 @@ CLI or the Docker Desktop GUI.
 Before you begin, you must remove any containers you previously ran for this
 guide. To stop and remove a container, either:
 
-- In a terminal, run `docker remove --force my-mysql` to remove the container
+- In a terminal, run `docker rm --force my-mysql` to remove the container
   named `my-mysql`.
 - Or, in the Docker Desktop Dashboard, select the **Delete** icon next to your
   container in the **Containers** view.
@@ -352,7 +352,7 @@ data persists:
    be lost when removing the container.
 
    ```console
-   $ docker remove --force my-mysql
+   $ docker rm --force my-mysql
    ```
 
 4. Start a new container with the volume attached. This time, you don't need to
@@ -486,7 +486,7 @@ run a custom MySQL image that includes a table initialization script.
 Before you begin, you must remove any containers you previously ran for this
 guide. To stop and remove a container, either:
 
-- In a terminal, run `docker remove --force my-mysql` to remove the container
+- In a terminal, run `docker rm --force my-mysql` to remove the container
   named `my-mysql`.
 - Or, in the Docker Desktop Dashboard, select the **Delete** icon next to your
   container in the **Containers** view.
diff --git a/content/guides/deno.md b/content/guides/deno.md
new file mode 100644
index 000000000000..929d600472a6
--- /dev/null
+++ b/content/guides/deno.md
@@ -0,0 +1,273 @@
+---
+description: Containerize and develop Deno applications using Docker.
+keywords: getting started, deno
+title: Deno language-specific guide
+summary: |
+  Learn how to containerize JavaScript applications with the Deno runtime using Docker.
+linkTitle: Deno
+aliases:
+  - /guides/deno/configure-ci-cd/
+  - /guides/deno/containerize/
+  - /guides/deno/deploy/
+  - /guides/deno/develop/
+params:
+  tags: [languages]
+  time: 10 minutes
+---
+
+The Deno getting started guide teaches you how to create a containerized Deno application using Docker.
+
+> **Acknowledgment**
+>
+> Docker would like to thank [Pradumna Saraf](https://twitter.com/pradumna_saraf) for his contribution to this guide.
+
+## What will you learn?
+
+- Containerize and run a Deno application using Docker
+- Set up a local environment to develop a Deno application using containers
+- Use Docker Compose to run the application.
+
+## Prerequisites
+
+- Basic understanding of JavaScript is assumed.
+- You must have familiarity with Docker concepts like containers, images, and Dockerfiles. If you are new to Docker, you can start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
+
+After completing the Deno getting started modules, you should be able to containerize your own Deno application based on the examples and instructions provided in this guide.
+
+Start by containerizing an existing Deno application.
+
+## Containerize a Deno application
+
+### Prerequisites
+
+- You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
+
+### Overview
+
+For a long time, Node.js has been the go-to runtime for server-side JavaScript applications. However, recent years have introduced new alternative runtimes, including [Deno](https://deno.land/). Like Node.js, Deno is a JavaScript and TypeScript runtime, but it takes a fresh approach with modern security features, a built-in standard library, and native support for TypeScript.
+
+Why develop Deno applications with Docker? Having a choice of runtimes is exciting, but managing multiple runtimes and their dependencies consistently across environments can be tricky. This is where Docker proves invaluable. Using containers to create and destroy environments on demand simplifies runtime management and ensures consistency. Additionally, as Deno continues to grow and evolve, Docker helps establish a reliable and reproducible development environment, minimizing setup challenges and streamlining the workflow.
+
+### Get the sample application
+
+Clone the sample application to use with this guide. Open a terminal, change
+directory to a directory that you want to work in, and run the following
+command to clone the repository:
+
+```console
+$ git clone https://github.com/dockersamples/docker-deno.git && cd docker-deno
+```
+
+You should now have the following contents in your `deno-docker` directory.
+
+```text
+├── deno-docker/
+│ ├── compose.yml
+│ ├── Dockerfile
+│ ├── LICENSE
+│ ├── server.ts
+│ └── README.md
+```
+
+### Understand the sample application
+
+The sample application is a simple Deno application that uses the Oak framework to create a simple API that returns a JSON response. The application listens on port 8000 and returns a message `{"Status" : "OK"}` when you access the application in a browser.
+
+```typescript
+// server.ts
+import { Application, Router } from "https://deno.land/x/oak@v12.0.0/mod.ts";
+
+const app = new Application();
+const router = new Router();
+
+// Define a route that returns JSON
+router.get("/", (context) => {
+  context.response.body = { Status: "OK" };
+  context.response.type = "application/json";
+});
+
+app.use(router.routes());
+app.use(router.allowedMethods());
+
+console.log("Server running on http://localhost:8000");
+await app.listen({ port: 8000 });
+```
+
+### Create a Dockerfile
+
+Before creating a Dockerfile, you need to choose a base image. You can either use the [Deno Docker Official Image](https://hub.docker.com/r/denoland/deno) or a Docker Hardened Image (DHI) from the [Hardened Image catalog](https://hub.docker.com/hardened-images/catalog).
+
+Choosing DHI offers the advantage of a production-ready image that is lightweight and secure. For more information, see [Docker Hardened Images](https://docs.docker.com/dhi/).
+
+{{< tabs >}}
+{{< tab name="Using Docker Hardened Images" >}}
+
+Docker Hardened Images (DHIs) are available for Deno in the [Docker Hardened Images catalog](https://hub.docker.com/hardened-images/catalog/dhi/deno). You can pull DHIs directly from the `dhi.io` registry.
+
+1. Sign in to the DHI registry:
+
+   ```console
+   $ docker login dhi.io
+   ```
+
+2. Pull the Deno DHI as `dhi.io/deno:2`. The tag (`2`) in this example refers to the version to the latest 2.x version of Deno.
+
+   ```console
+   $ docker pull dhi.io/deno:2
+   ```
+
+For other available versions, refer to the [catalog](https://hub.docker.com/hardened-images/catalog/dhi/deno).
+
+```dockerfile
+# Use the DHI Deno image as the base image
+FROM dhi.io/deno:2
+
+# Set the working directory
+WORKDIR /app
+
+# Copy server code into the container
+COPY server.ts .
+
+# Set permissions (optional but recommended for security)
+USER deno
+
+# Expose port 8000
+EXPOSE 8000
+
+# Run the Deno server
+CMD ["run", "--allow-net", "server.ts"]
+```
+
+{{< /tab >}}
+{{< tab name="Using the official image" >}}
+
+Using the Docker Official Image is straightforward. In the following Dockerfile, you'll notice that the `FROM` instruction uses `denoland/deno:latest` as the base image.
+
+This is the official image for Deno. This image is [available on the Docker Hub](https://hub.docker.com/r/denoland/deno).
+
+```dockerfile
+# Use the official Deno image
+FROM denoland/deno:latest
+
+# Set the working directory
+WORKDIR /app
+
+# Copy server code into the container
+COPY server.ts .
+
+# Set permissions (optional but recommended for security)
+USER deno
+
+# Expose port 8000
+EXPOSE 8000
+
+# Run the Deno server
+CMD ["run", "--allow-net", "server.ts"]
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+In addition to specifying the base image, the Dockerfile also:
+
+- Sets the working directory in the container to `/app`.
+- Copies `server.ts` into the container.
+- Sets the user to `deno` to run the application as a non-root user.
+- Exposes port 8000 to allow traffic to the application.
+- Runs the Deno server using the `CMD` instruction.
+- Uses the `--allow-net` flag to allow network access to the application. The `server.ts` file uses the Oak framework to create a simple API that listens on port 8000.
+
+### Run the application
+
+Make sure you are in the `deno-docker` directory. Run the following command in a terminal to build and run the application.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:8000](http://localhost:8000). You will see a message `{"Status" : "OK"}` in the browser.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `deno-docker` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:8000](http://localhost:8000).
+
+In the terminal, run the following command to stop the application.
+
+```console
+$ docker compose down
+```
+
+## Use containers for Deno development
+
+### Prerequisites
+
+Complete [Containerize a Deno application](#containerize-a-deno-application).
+
+### Overview
+
+In this section, you'll learn how to set up a development environment for your containerized application. This includes:
+
+- Configuring Compose to automatically update your running Compose services as you edit and save your code
+
+### Get the sample application
+
+Clone the sample application to use with this guide. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
+
+```console
+$ git clone https://github.com/dockersamples/docker-deno.git && cd docker-deno
+```
+
+### Automatically update services
+
+Use Compose Watch to automatically update your running Compose services as you
+edit and save your code. For more details about Compose Watch, see [Use Compose
+Watch](/manuals/compose/how-tos/file-watch.md).
+
+Open your `compose.yml` file in an IDE or text editor and then add the Compose Watch instructions. The following example shows how to add Compose Watch to your `compose.yml` file.
+
+```yaml {hl_lines="9-12",linenos=true}
+services:
+  server:
+    image: deno-server
+    build:
+      context: .
+      dockerfile: Dockerfile
+    ports:
+      - "8000:8000"
+    develop:
+      watch:
+        - action: rebuild
+          path: .
+```
+
+Run the following command to run your application with Compose Watch.
+
+```console
+$ docker compose watch
+```
+
+Now, if you modify your `server.ts` you will see the changes in real time without re-building the image.
+
+To test it out, open the `server.ts` file in your favorite text editor and change the message from `{"Status" : "OK"}` to `{"Status" : "Updated"}`. Save the file and refresh your browser at `http://localhost:8000`. You should see the updated message.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Summary
+
+In this section, you also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
+
+Related information:
+
+- [Compose file reference](/reference/compose-file/)
+- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
+- [Multi-stage builds](/manuals/build/building/multi-stage.md)
diff --git a/content/guides/deno/_index.md b/content/guides/deno/_index.md
deleted file mode 100644
index a864479ed9a0..000000000000
--- a/content/guides/deno/_index.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-description: Containerize and develop Deno applications using Docker.
-keywords: getting started, deno
-title: Deno language-specific guide
-summary: |
-  Learn how to containerize JavaScript applications with the Deno runtime using Docker.
-linkTitle: Deno
-languages: [js]
-params:
-  time: 10 minutes
----
-
-The Deno getting started guide teaches you how to create a containerized Deno application using Docker. In this guide, you'll learn how to:
-
-> **Acknowledgment**
->
-> Docker would like to thank [Pradumna Saraf](https://twitter.com/pradumna_saraf) for his contribution to this guide.
-
-## What will you learn?
-
-* Containerize and run a Deno application using Docker
-* Set up a local environment to develop a Deno application using containers
-* Use Docker Compose to run the application.
-* Configure a CI/CD pipeline for a containerized Deno application using GitHub Actions
-* Deploy your containerized application locally to Kubernetes to test and debug your deployment
-
-## Prerequisites
-
-- Basic understanding of JavaScript is assumed.
-- You must have familiarity with Docker concepts like containers, images, and Dockerfiles. If you are new to Docker, you can start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
-
-After completing the Deno getting started modules, you should be able to containerize your own Deno application based on the examples and instructions provided in this guide.
-
-Start by containerizing an existing Deno application.
diff --git a/content/guides/deno/configure-ci-cd.md b/content/guides/deno/configure-ci-cd.md
deleted file mode 100644
index d6d824a70cd1..000000000000
--- a/content/guides/deno/configure-ci-cd.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-title: Configure CI/CD for your Deno application
-linkTitle: Configure CI/CD
-weight: 40
-keywords: ci/cd, github actions, deno, shiny
-description: Learn how to configure CI/CD using GitHub Actions for your Deno application.
-aliases:
-- /language/deno/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a Deno application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-## Overview
-
-In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps:
-
-1. Create a new repository on GitHub.
-2. Define the GitHub Actions workflow.
-3. Run the workflow.
-
-## Step one: Create the repository
-
-Create a GitHub repository, configure the Docker Hub credentials, and push your source code.
-
-1. [Create a new repository](https://github.com/new) on GitHub.
-
-2. Open the repository **Settings**, and go to **Secrets and variables** >
-   **Actions**.
-
-3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-4. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token)for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-5. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-6. In your local repository on your machine, run the following command to change
-   the origin to the repository you just created. Make sure you change
-   `your-username` to your GitHub username and `your-repository` to the name of
-   the repository you created.
-
-   ```console
-   $ git remote set-url origin https://github.com/your-username/your-repository.git
-   ```
-
-7. Run the following commands to stage, commit, and push your local repository to GitHub.
-
-   ```console
-   $ git add -A
-   $ git commit -m "my commit"
-   $ git push -u origin main
-   ```
-
-## Step two: Set up the workflow
-
-Set up your GitHub Actions workflow for building and pushing the image
-to Docker Hub.
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-
-2. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub actions workflow file in
-   your repository, under `.github/workflows/main.yml` by default.
-
-3. In the editor window, copy and paste the following YAML configuration and commit the changes.
-
-   ```yaml
-   name: ci
-   
-   on:
-     push:
-       branches:
-         - main
-   
-   jobs:
-     build:
-       runs-on: ubuntu-latest
-       steps:
-         -
-           name: Login to Docker Hub
-           uses: docker/login-action@v3
-           with:
-             username: ${{ vars.DOCKER_USERNAME }}
-             password: ${{ secrets.DOCKERHUB_TOKEN }}
-         -
-           name: Set up Docker Buildx
-           uses: docker/setup-buildx-action@v3
-         -
-           name: Build and push
-           uses: docker/build-push-action@v6
-           with:
-             platforms: linux/amd64,linux/arm64
-             push: true
-             tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-   ```
-
-   For more information about the YAML syntax for `docker/build-push-action`,
-   refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
-## Step three: Run the workflow
-
-Save the workflow file and run the job.
-
-1. Select **Commit changes...** and push the changes to the `main` branch.
-
-   After pushing the commit, the workflow starts automatically.
-
-2. Go to the **Actions** tab. It displays the workflow.
-
-   Selecting the workflow shows you the breakdown of all the steps.
-
-3. When the workflow is complete, go to your
-   [repositories on Docker Hub](https://hub.docker.com/repositories).
-
-   If you see the new repository in that list, it means the GitHub Actions
-   successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your Deno application.
-
-Related information:
- - [Introduction to GitHub Actions](/manuals/build/ci/github-actions/_index.md)
- - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-Next, learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/deno/containerize.md b/content/guides/deno/containerize.md
deleted file mode 100644
index 70175896df43..000000000000
--- a/content/guides/deno/containerize.md
+++ /dev/null
@@ -1,146 +0,0 @@
----
-title: Containerize a Deno application
-linkTitle: Containerize your app
-weight: 10
-keywords: deno, containerize, initialize
-description: Learn how to containerize a Deno application.
-aliases:
-  - /language/deno/containerize/
----
-
-## Prerequisites
-
-* You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
-
-## Overview
-
-For a long time, Node.js has been the go-to runtime for server-side JavaScript applications. However, recent years have introduced new alternative runtimes, including [Deno](https://deno.land/). Like Node.js, Deno is a JavaScript and TypeScript runtime, but it takes a fresh approach with modern security features, a built-in standard library, and native support for TypeScript.
-
-Why develop Deno applications with Docker? Having a choice of runtimes is exciting, but managing multiple runtimes and their dependencies consistently across environments can be tricky. This is where Docker proves invaluable. Using containers to create and destroy environments on demand simplifies runtime management and ensures consistency. Additionally, as Deno continues to grow and evolve, Docker helps establish a reliable and reproducible development environment, minimizing setup challenges and streamlining the workflow.
-
-## Get the sample application
-
-Clone the sample application to use with this guide. Open a terminal, change
-directory to a directory that you want to work in, and run the following
-command to clone the repository:
-
-```console
-$ git clone https://github.com/dockersamples/docker-deno.git && cd docker-deno
-```
-
-You should now have the following contents in your `deno-docker` directory.
-
-```text
-├── deno-docker/
-│ ├── compose.yml
-│ ├── Dockerfile
-│ ├── LICENSE
-│ ├── server.ts
-│ └── README.md
-```
-
-## Understand the sample application
-
-The sample application is a simple Deno application that uses the Oak framework to create a simple API that returns a JSON response. The application listens on port 8000 and returns a message `{"Status" : "OK"}` when you access the application in a browser.
-
-```typescript
-// server.ts
-import { Application, Router } from "https://deno.land/x/oak@v12.0.0/mod.ts";
-
-const app = new Application();
-const router = new Router();
-
-// Define a route that returns JSON
-router.get("/", (context) => {
-  context.response.body = { Status: "OK" };
-  context.response.type = "application/json";
-});
-
-app.use(router.routes());
-app.use(router.allowedMethods());
-
-console.log("Server running on http://localhost:8000");
-await app.listen({ port: 8000 });
-```
-
-## Create a Dockerfile
-
-In the Dockerfile, you'll notice that the `FROM` instruction uses `denoland/deno:latest`
-as the base image. This is the official image for Deno. This image is [available on the Docker Hub](https://hub.docker.com/r/denoland/deno).
-
-```dockerfile
-# Use the official Deno image
-FROM denoland/deno:latest
-
-# Set the working directory
-WORKDIR /app
-
-# Copy server code into the container
-COPY server.ts .
-
-# Set permissions (optional but recommended for security)
-USER deno
-
-# Expose port 8000
-EXPOSE 8000
-
-# Run the Deno server
-CMD ["run", "--allow-net", "server.ts"]
-```
-
-Aside from specifying `denoland/deno:latest` as the base image, the Dockerfile:
-
-- Sets the working directory in the container to `/app`.
-- Copies `server.ts` into the container.
-- Sets the user to `deno` to run the application as a non-root user.
-- Exposes port 8000 to allow traffic to the application.
-- Runs the Deno server using the `CMD` instruction.
-- Uses the `--allow-net` flag to allow network access to the application. The `server.ts` file uses the Oak framework to create a simple API that listens on port 8000.
-
-## Run the application
-
-Make sure you are in the `deno-docker` directory. Run the following command in a terminal to build and run the application.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:8000](http://localhost:8000). You will see a message `{"Status" : "OK"}` in the browser.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-### Run the application in the background
-
-You can run the application detached from the terminal by adding the `-d`
-option. Inside the `deno-docker` directory, run the following command
-in a terminal.
-
-```console
-$ docker compose up --build -d
-```
-
-Open a browser and view the application at [http://localhost:8000](http://localhost:8000).
-
-
-In the terminal, run the following command to stop the application.
-
-```console
-$ docker compose down
-```
-
-## Summary
-
-In this section, you learned how you can containerize and run your Deno
-application using Docker.
-
-Related information:
-
- - [Dockerfile reference](/reference/dockerfile.md)
- - [.dockerignore file](/reference/dockerfile.md#dockerignore-file)
- - [Docker Compose overview](/manuals/compose/_index.md)
- - [Compose file reference](/reference/compose-file/_index.md)
-
-## Next steps
-
-In the next section, you'll learn how you can develop your application using
-containers.
diff --git a/content/guides/deno/deploy.md b/content/guides/deno/deploy.md
deleted file mode 100644
index 447d7f4a85f7..000000000000
--- a/content/guides/deno/deploy.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: Test your Deno deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, kubernetes, deno
-description: Learn how to develop locally using Kubernetes
-aliases:
-- /language/deno/deploy/
----
-
-## Prerequisites
-
-- Complete all the previous sections of this guide, starting with [Containerize a Deno application](containerize.md).
-- [Turn on Kubernetes](/manuals//desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This allows you to test and debug your workloads on Kubernetes locally before deploying.
-
-## Create a Kubernetes YAML file
-
-In your `deno-docker` directory, create a file named
-`docker-kubernetes.yml`. Open the file in an IDE or text editor and add
-the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker
-username and the name of the repository that you created in [Configure CI/CD for
-your Deno application](configure-ci-cd.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: docker-deno-demo
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: deno-api
-  template:
-    metadata:
-      labels:
-        app: deno-api
-    spec:
-      containers:
-       - name: deno-api
-         image: DOCKER_USERNAME/REPO_NAME
-         imagePullPolicy: Always
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: service-entrypoint
-  namespace: default
-spec:
-  type: NodePort
-  selector:
-    app: deno-api
-  ports:
-  - port: 8000
-    targetPort: 8000
-    nodePort: 30001
-```
-
-In this Kubernetes YAML file, there are two objects, separated by the `---`:
-
- - A Deployment, describing a scalable group of identical pods. In this case,
-   you'll get just one replica, or copy of your pod. That pod, which is
-   described under `template`, has just one container in it. The
-    container is created from the image built by GitHub Actions in [Configure CI/CD for
-    your Deno application](configure-ci-cd.md).
- - A NodePort service, which will route traffic from port 30001 on your host to
-   port 8000 inside the pods it routes to, allowing you to reach your app
-   from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to `deno-docker` and deploy your application to
-   Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-kubernetes.yml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```text
-   deployment.apps/docker-deno-demo created
-   service/service-entrypoint created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```shell
-   NAME                 READY   UP-TO-DATE   AVAILABLE    AGE
-   docker-deno-demo       1/1     1            1           10s
-   ```
-
-   This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```shell
-   NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
-   kubernetes           ClusterIP   10.96.0.1        <none>        443/TCP          88m
-   service-entrypoint   NodePort    10.105.145.223   <none>        8000:30001/TCP   83s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP.
-
-3. In a browser, visit the following address. You should see the message `{"Status" : "OK"}`.
-
-   ```console
-   http://localhost:30001/
-   ```
-
-4. Run the following command to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-kubernetes.yml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your Deno application to a fully-featured Kubernetes environment on your development machine. 
-
-Related information:
-   - [Kubernetes documentation](https://kubernetes.io/docs/home/)
-   - [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-   - [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/deno/develop.md b/content/guides/deno/develop.md
deleted file mode 100644
index d717823b634d..000000000000
--- a/content/guides/deno/develop.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: Use containers for Deno development
-linkTitle: Develop your app
-weight: 20
-keywords: deno, local, development
-description: Learn how to develop your Deno application locally.
-aliases:
-- /language/deno/develop/
----
-
-## Prerequisites
-
-Complete [Containerize a Deno application](containerize.md).
-
-## Overview
-
-In this section, you'll learn how to set up a development environment for your containerized application. This includes:
-
-- Configuring Compose to automatically update your running Compose services as you edit and save your code
-
-## Get the sample application
-
-Clone the sample application to use with this guide. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
-
-```console
-$ git clone https://github.com/dockersamples/docker-deno.git && cd docker-deno
-```
-
-## Automatically update services
-
-Use Compose Watch to automatically update your running Compose services as you
-edit and save your code. For more details about Compose Watch, see [Use Compose
-Watch](/manuals/compose/how-tos/file-watch.md).
-
-Open your `compose.yml` file in an IDE or text editor and then add the Compose Watch instructions. The following example shows how to add Compose Watch to your `compose.yml` file.
-
-```yaml {hl_lines="9-12",linenos=true}
-services:
-  server:
-    image: deno-server
-    build:
-      context: .
-      dockerfile: Dockerfile
-    ports:
-      - "8000:8000"
-    develop:
-      watch:
-        - action: rebuild
-          path: .
-```
-
-Run the following command to run your application with Compose Watch.
-
-```console
-$ docker compose watch
-```
-
-Now, if you modify your `server.ts` you will see the changes in real time without re-building the image.
-
-To test it out, open the `server.ts` file in your favorite text editor and change the message from `{"Status" : "OK"}` to `{"Status" : "Updated"}`. Save the file and refresh your browser at `http://localhost:8000`. You should see the updated message.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Summary
-
-In this section, you also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
-
-Related information:
- - [Compose file reference](/reference/compose-file/)
- - [Compose file watch](/manuals/compose/how-tos/file-watch.md)
- - [Multi-stage builds](/manuals/build/building/multi-stage.md)
-
-## Next steps
-
-In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions.
diff --git a/content/guides/dex.md b/content/guides/dex.md
index 605d6bacc17f..b8c6b3a2f504 100644
--- a/content/guides/dex.md
+++ b/content/guides/dex.md
@@ -4,9 +4,8 @@ description: &desc Mocking OAuth services in testing with Dex
 keywords: Dex, container-supported development
 linktitle: Mocking OAuth services with Dex
 summary: *desc
-tags: [app-dev, distributed-systems]
-languages: []
 params:
+  tags: [testing]
   time: 10 minutes
 ---
 
@@ -27,7 +26,7 @@ The official [Docker image for Dex](https://hub.docker.com/r/dexidp/dex/) provid
 
 [Docker Compose](/compose/): Recommended for managing multi-container Docker applications.
 
-### Setting Up Dex with Docker
+### Setting up Dex with Docker
 
 Begin by creating a directory for your Dex project:
 
@@ -87,7 +86,7 @@ or use CLI tools like [htpasswd](https://httpd.apache.org/docs/2.4/programs/htpa
 
 With Docker Compose configured, start Dex:
 ```yaml
-# docker-compose.yaml
+# compose.yaml
 
 services:
   dex:
diff --git a/content/guides/dhi-backstage.md b/content/guides/dhi-backstage.md
new file mode 100644
index 000000000000..7100da786a95
--- /dev/null
+++ b/content/guides/dhi-backstage.md
@@ -0,0 +1,490 @@
+---
+title: Secure a Backstage application with Docker Hardened Images
+description: Secure a Backstage developer portal using Docker Hardened Images, covering native module compilation, Socket Firewall protection, and distroless runtime images.
+summary: Learn how to secure a Backstage developer portal using Docker Hardened Images (DHI), handle native module compilation with better-sqlite3, add Socket Firewall protection during dependency installation, and produce a distroless runtime image using DHI customizations.
+keywords: docker hardened images, dhi, backstage, CNCF, developer portal, node.js, native modules, sqlite, better-sqlite3, distroless, socket firewall, dhictl, multi-stage build
+params:
+  tags: [security]
+  proficiencyLevel: Intermediate
+  time: 45 minutes
+  prerequisites:
+    - Docker Desktop or Docker Engine with BuildKit enabled
+    - A Docker Hub account authenticated with docker login and docker login dhi.io
+    - A Backstage project created with @backstage/create-app
+    - Basic familiarity with multi-stage Dockerfiles and Node.js native modules
+---
+
+This guide shows how to secure a Backstage application using Docker Hardened Images (DHI). Backstage is a CNCF open source developer portal used by thousands of organizations to manage their software catalogs, templates, and developer tooling.
+
+By the end of this guide, you'll have a Backstage container image that is distroless, runs as a non-root user by default, and has dramatically fewer CVEs than the standard `node:24-trixie-slim` base image while still supporting the native module compilation that Backstage requires.
+
+## Prerequisites
+
+- Docker Desktop or Docker Engine with BuildKit enabled
+- A Docker Hub account authenticated with `docker login` and `docker login dhi.io`
+- A Backstage project created with `@backstage/create-app`
+
+## Why Backstage needs customization
+
+The DHI migration examples cover applications where you can swap the base image and everything works. Backstage is different. It uses `better-sqlite3` and other packages that compile native Node.js modules at install time, which means the build stage needs `g++`, `make`, `python3`, and `sqlite-dev` — none of which are in the base `dhi.io/node` image. The runtime image only needs the shared library (`sqlite-libs`) that the compiled native module links against.
+
+This is a common pattern. Any Node.js application that depends on native addons (such as `bcrypt`, `sharp`, `sqlite3`, or `node-canvas`) faces the same challenge. The approach in this guide applies to all of them.
+
+## Step 1: Examine the original Dockerfile
+
+The official Backstage documentation recommends a multi-stage Dockerfile using `node:24-trixie-slim` (Debian). A typical setup looks like this:
+
+```dockerfile
+# Stage 1 - Create yarn install skeleton layer
+FROM node:24-trixie-slim AS packages
+WORKDIR /app
+COPY backstage.json package.json yarn.lock ./
+COPY .yarn ./.yarn
+COPY .yarnrc.yml ./
+COPY packages packages
+COPY plugins plugins
+RUN find packages \! -name "package.json" -mindepth 2 -maxdepth 2 \
+    -exec rm -rf {} \+
+
+# Stage 2 - Install dependencies and build packages
+FROM node:24-trixie-slim AS build
+ENV PYTHON=/usr/bin/python3
+RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
+    --mount=type=cache,target=/var/lib/apt,sharing=locked \
+    apt-get update && \
+    apt-get install -y --no-install-recommends python3 g++ build-essential && \
+    rm -rf /var/lib/apt/lists/*
+RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
+    --mount=type=cache,target=/var/lib/apt,sharing=locked \
+    apt-get update && \
+    apt-get install -y --no-install-recommends libsqlite3-dev && \
+    rm -rf /var/lib/apt/lists/*
+USER node
+WORKDIR /app
+COPY --from=packages --chown=node:node /app .
+RUN --mount=type=cache,target=/home/node/.cache/yarn,sharing=locked,uid=1000,gid=1000 \
+    yarn install --immutable
+COPY --chown=node:node . .
+RUN yarn tsc
+RUN yarn --cwd packages/backend build
+RUN mkdir packages/backend/dist/skeleton packages/backend/dist/bundle \
+    && tar xzf packages/backend/dist/skeleton.tar.gz \
+       -C packages/backend/dist/skeleton \
+    && tar xzf packages/backend/dist/bundle.tar.gz \
+       -C packages/backend/dist/bundle
+
+# Stage 3 - Build the actual backend image
+FROM node:24-trixie-slim
+ENV PYTHON=/usr/bin/python3
+RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
+    --mount=type=cache,target=/var/lib/apt,sharing=locked \
+    apt-get update && \
+    apt-get install -y --no-install-recommends python3 g++ build-essential && \
+    rm -rf /var/lib/apt/lists/*
+RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
+    --mount=type=cache,target=/var/lib/apt,sharing=locked \
+    apt-get update && \
+    apt-get install -y --no-install-recommends libsqlite3-dev && \
+    rm -rf /var/lib/apt/lists/*
+USER node
+WORKDIR /app
+COPY --from=build --chown=node:node /app/.yarn ./.yarn
+COPY --from=build --chown=node:node /app/.yarnrc.yml ./
+COPY --from=build --chown=node:node /app/backstage.json ./
+COPY --from=build --chown=node:node /app/yarn.lock \
+     /app/package.json \
+     /app/packages/backend/dist/skeleton/ ./
+RUN --mount=type=cache,target=/home/node/.cache/yarn,sharing=locked,uid=1000,gid=1000 \
+    yarn workspaces focus --all --production
+COPY --from=build --chown=node:node /app/packages/backend/dist/bundle/ ./
+CMD ["node", "packages/backend", "--config", "app-config.yaml"]
+```
+
+Run this image and inspect what's available inside the container:
+
+```console
+docker build -t backstage:init .
+docker run -d \
+    -e APP_CONFIG_backend_database_client='better-sqlite3' \
+    -e APP_CONFIG_backend_database_connection=':memory:' \
+    -e APP_CONFIG_auth_providers_guest_dangerouslyAllowOutsideDevelopment='true' \
+    -p 7007:7007 \
+    -u 1000 \
+    --cap-drop=ALL \
+    --read-only \
+    --tmpfs /tmp \
+    backstage:init
+```
+
+This works, but the runtime container has a shell, a package manager, and yarn. None of these are needed to run Backstage. Run `docker exec` to see what's accessible inside:
+
+```console
+docker exec -it <container-id> sh
+$ cat /etc/shells
+# /etc/shells: valid login shells
+/bin/sh
+/usr/bin/sh
+/bin/bash
+/usr/bin/bash
+/bin/rbash
+/usr/bin/rbash
+/usr/bin/dash
+$ yarn --version
+4.12.0
+$ dpkg --version
+dpkg version 1.22.11 (arm64).
+$ whoami
+node
+$ id
+uid=1000(node) gid=1000(node) groups=1000(node)
+```
+
+The `node:24-trixie-slim` image ships with three shells (`dash`, `bash`, and `rbash`), a package manager (`dpkg`), and `yarn`. Each of these tools increases the attack surface. An attacker who gains access to this container could use them for lateral movement across your infrastructure.
+
+## Step 2: Switch the build stages to DHI
+
+Replace all three stages with DHI equivalents. DHI Node.js images are available in both 
+Alpine and Debian variants. This guide uses the Alpine variant (`dhi.io/node:24-alpine3.23`) 
+because it produces a smaller image. If you need to stay on Debian for compatibility reasons, 
+use `dhi.io/node:24-bookworm` and keep `apt-get` instead of `apk`.
+
+```dockerfile
+# Stage 1: prepare packages
+FROM --platform=$BUILDPLATFORM dhi.io/node:24-alpine3.23-dev AS packages
+WORKDIR /app
+COPY backstage.json package.json yarn.lock ./
+COPY .yarn ./.yarn
+COPY .yarnrc.yml ./
+COPY packages packages
+COPY plugins plugins
+RUN find packages \! -name "package.json" -mindepth 2 -maxdepth 2 \
+    -exec rm -rf {} \+
+
+# Stage 2: build the application
+FROM --platform=$BUILDPLATFORM dhi.io/node:24-alpine3.23-dev AS build
+ENV PYTHON=/usr/bin/python3
+RUN apk add --no-cache g++ make python3 sqlite-dev && \
+    rm -rf /var/lib/apk/lists/*
+WORKDIR /app
+COPY --from=packages --chown=node:node /app .
+RUN --mount=type=cache,target=/home/node/.cache/yarn,sharing=locked,uid=1000,gid=1000 \
+    yarn install --immutable
+COPY --chown=node:node . .
+RUN yarn tsc
+RUN yarn --cwd packages/backend build
+RUN mkdir packages/backend/dist/skeleton packages/backend/dist/bundle \
+    && tar xzf packages/backend/dist/skeleton.tar.gz \
+       -C packages/backend/dist/skeleton \
+    && tar xzf packages/backend/dist/bundle.tar.gz \
+       -C packages/backend/dist/bundle
+
+# Final Stage: create the runtime image
+FROM dhi.io/node:24-alpine3.23-dev
+ENV PYTHON=/usr/bin/python3
+RUN apk add --no-cache g++ make python3 sqlite-dev && \
+    rm -rf /var/lib/apk/lists/*
+WORKDIR /app
+COPY --from=build --chown=node:node /app/.yarn ./.yarn
+COPY --from=build --chown=node:node /app/.yarnrc.yml ./
+COPY --from=build --chown=node:node /app/backstage.json ./
+COPY --from=build --chown=node:node /app/yarn.lock \
+     /app/package.json \
+     /app/packages/backend/dist/skeleton/ ./
+RUN --mount=type=cache,target=/home/node/.cache/yarn,sharing=locked,uid=1000,gid=1000 \
+    yarn workspaces focus --all --production \
+    && rm -rf "$(yarn cache clean)"
+COPY --from=build --chown=node:node /app/packages/backend/dist/bundle/ ./
+CMD ["node", "packages/backend", "--config", "app-config.yaml"]
+```
+
+Build and tag this version:
+
+```console
+docker build -t backstage:dhi-dev .
+```
+
+> [!NOTE]
+>
+> The `-dev` variant includes a shell and package manager, which is why `apk add` works. Backstage requires `python3` and native build tools in the runtime image because `yarn workspaces focus --all --production` recompiles native modules during the production install. This is specific to Backstage's build process — most Node.js applications can use the standard (non-dev) DHI runtime variant without additional packages.
+
+The DHI images come with attestations that the original `node:24-trixie-slim` images don't have. Check what's attached:
+
+```console
+docker scout attest list dhi.io/node:24-alpine3.23
+```
+
+DHI images ship with 15 attestations including CycloneDX SBOM, SLSA provenance, OpenVEX, Scout health reports, secret scans, virus/malware reports, and an SLSA verification summary.
+
+## Step 3: Add Socket Firewall protection
+
+DHI provides `-sfw` (Socket Firewall) variants for Node.js images. Socket Firewall intercepts `npm` and `yarn` commands during the build to detect and block malicious packages before they execute install scripts.
+
+To enable Socket Firewall, change the `-dev` tags to `-sfw-dev` in all three stages. The SFW version of the Dockerfile:
+
+```dockerfile
+# Stage 1: prepare packages
+FROM --platform=$BUILDPLATFORM dhi.io/node:24-alpine3.23-sfw-dev AS packages
+WORKDIR /app
+COPY backstage.json package.json yarn.lock ./
+COPY .yarn ./.yarn
+COPY .yarnrc.yml ./
+COPY packages packages
+COPY plugins plugins
+RUN find packages \! -name "package.json" -mindepth 2 -maxdepth 2 \
+    -exec rm -rf {} \+
+
+# Stage 2: build the packages
+FROM --platform=$BUILDPLATFORM dhi.io/node:24-alpine3.23-sfw-dev AS build-packages
+ENV PYTHON=/usr/bin/python3
+RUN apk add --no-cache g++ make python3 sqlite-dev && \
+    rm -rf /var/lib/apk/lists/*
+WORKDIR /app
+COPY --from=packages --chown=node:node /app .
+RUN --mount=type=cache,target=/home/node/.cache/yarn,sharing=locked,uid=1000,gid=1000 \
+    yarn install --immutable
+COPY --chown=node:node . .
+RUN yarn tsc
+RUN yarn --cwd packages/backend build
+RUN mkdir packages/backend/dist/skeleton packages/backend/dist/bundle \
+    && tar xzf packages/backend/dist/skeleton.tar.gz \
+       -C packages/backend/dist/skeleton \
+    && tar xzf packages/backend/dist/bundle.tar.gz \
+       -C packages/backend/dist/bundle
+
+# Final Stage: create the runtime image
+FROM dhi.io/node:24-alpine3.23-sfw-dev
+ENV PYTHON=/usr/bin/python3
+RUN apk add --no-cache g++ make python3 sqlite-dev && \
+    rm -rf /var/lib/apk/lists/*
+WORKDIR /app
+COPY --from=build-packages --chown=node:node /app/.yarn ./.yarn
+COPY --from=build-packages --chown=node:node /app/.yarnrc.yml ./
+COPY --from=build-packages --chown=node:node /app/backstage.json ./
+COPY --from=build-packages --chown=node:node /app/yarn.lock \
+     /app/package.json \
+     /app/packages/backend/dist/skeleton/ ./
+RUN --mount=type=cache,target=/home/node/.cache/yarn,sharing=locked,uid=1000,gid=1000 \
+    yarn workspaces focus --all --production \
+    && rm -rf "$(yarn cache clean)"
+COPY --from=build-packages --chown=node:node /app/packages/backend/dist/bundle/ ./
+CMD ["node", "packages/backend", "--config", "app-config.yaml"]
+```
+
+Build this version:
+
+```console
+docker build -t backstage:dhi-sfw-dev .
+```
+
+When you build, you'll see Socket Firewall messages in the build output: `Protected by Socket Firewall` for any `yarn` and `npm` commands executed in the Dockerfile or in the running containers.
+
+> [!TIP]
+>
+> The `-sfw-dev` variant is larger (1.9 GB versus 1.72 GB) because Socket Firewall adds monitoring tooling. The security benefit during `yarn install` outweighs the size increase.
+
+## Step 4: Remove the shell and the package manager with DHI customizations
+
+The previous steps still use the `-dev` or `-sfw-dev` variant as the runtime image, which includes a shell and package manager. DHI customizations let you start from the base (non-dev) image — which has no shell and no package manager — and add only the runtime libraries and language runtimes your application needs.
+
+> [!IMPORTANT]
+>
+> When creating a customization, only add what your application needs at runtime:
+>
+> - **System packages** - add shared libraries (such as `sqlite-libs`) and
+>   language runtimes from the DHI catalog (such as `python-3.14`).
+>   Do not add build tools (such as `g++`, `make`, or `python3` from Alpine).
+> - **Build tools** - keep these in the `-dev` build stage only. Never add them
+>   to the runtime customization.
+>
+> Language runtimes installed from the DHI hardened package feed are patched and
+> tracked in the image SBOM, which is why they are acceptable as system packages.
+> Build tools from Alpine or Debian package feeds are not hardened and should
+> never appear in the runtime image.
+
+For Backstage, the runtime image needs:
+
+- **sqlite-libs** - the shared library that the compiled `better-sqlite3` native module links against (added as a system package).
+- **Python** - if your Backstage plugins or configuration require Python at runtime. Added as the `python-3.14` system package from the DHI catalog. Unlike `python3` installed via `apk`, this package is patched by Docker and tracked in the image SBOM.
+
+Docker will continuously build with SLSA Level 3 compliance and patch these customized images within the guaranteed SLA for CVE patching.
+
+To create the customization, use one of the following methods.
+
+{{< tabs >}}
+{{< tab name="Docker Hub UI" >}}
+
+After you mirror the Node.js DHI repository to your organization's namespace:
+
+1. Open the mirrored Node.js repository in Docker Hub.
+2. Select **Customize** and choose the `node:24-alpine3.23` tag.
+3. Under **Packages**, add `sqlite-libs` and `python-3.14`.
+4. Create the customization.
+
+For more information, see [Customize an image](/dhi/how-to/customize/).
+
+{{< /tab >}}
+{{< tab name="dhictl CLI" >}}
+
+`dhictl` is Docker's command-line tool for managing Docker Hardened Images. It lets you browse the DHI catalog, mirror images, and create customizations directly from your terminal. You can integrate `dhictl` into CI/CD pipelines and infrastructure-as-code workflows. You can install `dhictl` as a standalone binary or as a Docker CLI plugin (`docker dhi`); for installation instructions, see [Use the DHI CLI](/dhi/how-to/cli/).
+
+Rather than writing the customization YAML by hand, use `dhictl` to scaffold a starting point:
+
+```console
+dhictl customization prepare --org YOUR_ORG node 24-alpine3.23 \
+    --destination YOUR_ORG/dhi-node \
+    --name "backstage" \
+    --tag-suffix "_backstage" \
+    --output node-backstage.yaml
+```
+
+Edit the generated file to add the runtime libraries:
+
+```yaml
+name: backstage
+
+source: dhi/node
+tag_definition_id: node/alpine-3.23/24
+
+destination: YOUR_ORG/dhi-node
+tag_suffix: _backstage
+
+platforms:
+  - linux/amd64
+  - linux/arm64
+
+contents:
+  packages:
+    - sqlite-libs
+    - python-3.14
+
+accounts:
+  root: true
+  runs-as: node
+  users:
+    - name: node
+      uid: 1000
+  groups:
+    - name: node
+      gid: 1000
+
+```
+
+Then create the customization:
+
+```console
+dhictl customization create --org YOUR_ORG node-backstage.yaml
+```
+
+Monitor the build progress using the customization ID from the create output.
+To look up the ID, run:
+
+```console
+dhictl customization list --org YOUR_ORG
+```
+
+Then monitor the build:
+
+```console
+dhictl customization build list <customization-id> --org YOUR_ORG
+```
+
+Docker builds the customized image on its secure infrastructure and publishes it as `YOUR_ORG/dhi-node:24-alpine3.23_backstage`.
+
+> [!NOTE]
+>
+> If your Backstage configuration does not require Python at runtime, you can omit the `python-3.14` from the packages list. The `sqlite-libs` package alone is sufficient to run Backstage with `better-sqlite3`.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Update the Dockerfile
+
+Update only the final stage of your Dockerfile to use the customized image:
+
+```dockerfile
+# Final Stage: create the runtime image
+FROM YOUR_ORG/dhi-node:24-alpine3.23_backstage
+WORKDIR /app
+COPY --from=build --chown=node:node /app/node_modules ./node_modules
+COPY --from=build --chown=node:node /app/packages/backend/dist/bundle/ ./
+CMD ["node", "packages/backend", "--config", "app-config.yaml"]
+```
+
+Build this version:
+
+```console
+docker build -t backstage:dhi .
+```
+
+Since the customization includes only runtime libraries and OCI artifacts — no build tools, no package manager, no shell — the resulting image is distroless:
+
+```console
+docker run --rm YOUR_ORG/dhi-node:24-alpine3.23_backstage sh -c "echo hello"
+docker: Error response from daemon: ... exec: "sh": executable file not found in $PATH
+```
+
+With the Enterprise customization:
+
+- The runtime image is distroless — no shell, no package manager.
+- Docker automatically rebuilds your customized image when the base Node.js image or any of its packages receive a security patch.
+- The full chain of trust is maintained, including SLSA Build Level 3 provenance.
+- Both the Node.js and Python runtimes are tracked in the image SBOM.
+
+Confirm the container no longer has shell access:
+
+```console
+docker exec -it <container-id> sh
+OCI runtime exec failed: exec failed: unable to start container process: ...
+```
+
+Use [Docker Debug](/dhi/how-to/troubleshoot/#general-debugging) if you need to troubleshoot a running distroless container.
+
+> [!NOTE]
+>
+> If your organization requires FIPS/STIG compliant images, that's also an option in DHI Enterprise.
+
+## Step 5: Verify the results
+
+Compare the DHI-based image against the original using Docker Scout:
+
+```console
+docker scout compare backstage:dhi \
+    --to backstage:init \
+    --platform linux/amd64 \
+    --ignore-unchanged
+```
+
+A typical comparison across the approaches shows results similar to the following:
+
+| Metric | Original | DHI -dev | DHI -sfw-dev | Enterprise |
+|--------|----------|----------|--------------|------------|
+| Disk usage | 1.61 GB | 1.72 GB | 1.9 GB | 1.49 GB |
+| Content size | 268 MB | 288 MB | 328 MB | 247 MB |
+| Shell in runtime | Yes | Yes | Yes | No |
+| Package manager | Yes | Yes | Yes | No |
+| Non-root default | No | No | No | Yes |
+| Socket Firewall | No | No | Yes (build) | Yes (build) / No (runtime) |
+| SLSA provenance | No | Base only | Base only | Full (Level 3) |
+
+> [!NOTE]
+>
+> The `-sfw-dev` variant is larger because Socket Firewall adds monitoring tooling to the image. The additional size is in the build stages, and the security benefit during `yarn install` outweighs the size increase.
+
+For a more thorough assessment, scan with multiple tools:
+
+```console
+trivy image backstage:dhi
+grype backstage:dhi
+docker scout quickview backstage:dhi
+```
+
+Different scanners detect different issues. Running all three gives you the most complete view of your security posture.
+
+## What's next
+
+- [Customize an image](/dhi/how-to/customize/) — complete reference on the Enterprise customization UI.
+- [Create and build a DHI](/dhi/how-to/build/) — learn how to write a DHI definition file, build images locally.
+- [Use the DHI CLI](/dhi/how-to/cli/) — manage DHI images, mirrors, and customizations from the command line.
+- [Migrate to DHI](/dhi/migration/) — for applications that work with standard DHI images without additional packages.
+- [Compare images](/dhi/how-to/search-evaluate/#compare-and-evaluate-images) — evaluate security improvements between your original and hardened images.
+- [Docker Debug](/dhi/how-to/troubleshoot/#general-debugging) — troubleshoot distroless containers that have no shell.
diff --git a/content/guides/dhi-openshift.md b/content/guides/dhi-openshift.md
new file mode 100644
index 000000000000..c588f81d00a0
--- /dev/null
+++ b/content/guides/dhi-openshift.md
@@ -0,0 +1,625 @@
+---
+title: Use Docker Hardened Images with Red Hat OpenShift
+description: Deploy Docker Hardened Images on Red Hat OpenShift Container Platform, covering Security Context Constraints, arbitrary user ID assignment, file permissions, and best practices.
+summary: Learn how to deploy Docker Hardened Images (DHI) on Red Hat OpenShift, configure Security Context Constraints, handle arbitrary user ID assignment, and set file permissions for both runtime and development image variants.
+keywords: docker hardened images, dhi, openshift, OCP, SCC, security context constraints, non-root, distroless, containers, red hat
+params:
+  tags: [security]
+  proficiencyLevel: Intermediate
+  time: 30 minutes
+  prerequisites:
+    - An OpenShift cluster (version 4.11 or later recommended)
+    - The oc CLI authenticated to your cluster
+    - A Docker Hub account with access to Docker Hardened Images
+    - Familiarity with OpenShift Security Context Constraints (SCCs)
+---
+
+Docker Hardened Images (DHI) can be deployed on Red Hat OpenShift Container
+Platform, but OpenShift’s security model differs from standard Kubernetes in
+ways that require specific configuration. Because OpenShift runs containers
+with an arbitrarily assigned user ID rather than the image’s default, you must
+adjust file ownership and group permissions in your Dockerfiles to ensure
+writable paths remain accessible.
+
+This guide explains how to deploy Docker Hardened Images in OpenShift
+environments, covering Security Context Constraints (SCCs), arbitrary user ID
+assignment, file permission requirements, and best practices for both runtime
+and development image variants.
+
+## How OpenShift security differs from Kubernetes
+
+OpenShift extends Kubernetes with Security Context Constraints (SCCs), which
+control what actions a pod can perform and what resources it can access. While
+vanilla Kubernetes uses Pod Security Standards (PSS) for similar purposes, SCCs
+are more granular and enforced by default.
+
+The key differences that affect DHI deployments:
+
+**Arbitrary user IDs.** By default, OpenShift runs containers using an
+arbitrarily assigned user ID (UID) from a range allocated to each project. The
+default `restricted-v2` SCC (introduced in OpenShift 4.11) uses the
+`MustRunAsRange` strategy, which overrides the `USER` directive in the container
+image with a UID from the project’s allocated range (typically starting higher than
+1000000000). This means even though a DHI image specifies a non-root user
+(UID 65532), OpenShift will run the container as a different, unpredictable UID.
+
+**Root group requirement.** OpenShift assigns the arbitrary UID to the root
+group (GID 0). The container process always runs with `gid=0(root)`. Any
+directories or files that the process needs to write to must be owned by the
+root group (GID 0) with group read/write permissions. This is documented in the
+[Red Hat guidelines for creating images](https://docs.openshift.com/container-platform/4.14/openshift_images/create-images.html#use-uid_create-images).
+
+> [!IMPORTANT]
+> 
+> DHI images set file ownership to `nonroot:nonroot` (65532:65532) by default.
+> Because the OpenShift arbitrary UID is NOT in the `nonroot` group (65532), it
+> cannot write to those files — even though the pod is admitted by the SCC and
+> the container starts. You must change group ownership to GID 0 for any
+> writable path. This is the most common source of permission errors when
+> deploying DHI on OpenShift.
+
+**Capability restrictions.** The `restricted-v2` SCC drops all Linux
+capabilities by default and enforces `allowPrivilegeEscalation: false`,
+`runAsNonRoot: true`, and a `seccompProfile` of type `RuntimeDefault`. DHI
+runtime images already satisfy these constraints because they run as a non-root
+user and don’t require elevated capabilities.
+
+## Pull DHI images into OpenShift
+
+Before deploying, create an image pull secret so your OpenShift cluster can
+authenticate to the DHI registry or your mirrored repository on Docker Hub.
+
+### Create an image pull secret
+
+```console
+oc create secret docker-registry dhi-pull-secret \
+    --docker-server=docker.io \
+    --docker-username=<your-docker-username> \
+    --docker-password=<your-docker-access-token> \
+    --docker-email=<your-email>
+```
+
+If you’re pulling directly from `dhi.io` instead of a mirrored repository, set
+`--docker-server=dhi.io`.
+
+### Link the secret to a service account
+
+Link the pull secret to the `default` service account in your project so that
+all deployments can pull DHI images automatically:
+
+```console
+oc secrets link default dhi-pull-secret --for=pull
+```
+
+To use the secret with a specific service account instead:
+
+```console
+oc secrets link <service-account-name> dhi-pull-secret --for=pull
+```
+
+## Build OpenShift-compatible images from DHI
+
+DHI runtime images are distroless — they contain no shell, no package manager,
+and no `RUN`-capable environment. This means you **cannot use `RUN` commands in
+the runtime stage** of your Dockerfile. All file permission adjustments for
+OpenShift must happen in the `-dev` build stage, and the results must be copied
+into the runtime stage using `COPY --chown`.
+
+The core pattern for OpenShift compatibility:
+
+1. Use a DHI `-dev` variant as the build stage (it has a shell).
+1. Build your application and set GID 0 ownership in the build stage.
+1. Copy the results into the DHI runtime image using `COPY --chown=<UID>:0`.
+
+### Example: Nginx for OpenShift
+
+```dockerfile
+# Build stage — has a shell, can run commands
+FROM YOUR_ORG/dhi-nginx:1.29-alpine3.23-dev AS build
+
+# Copy custom config and set root group ownership
+COPY nginx.conf /tmp/nginx.conf
+COPY default.conf /tmp/default.conf
+
+# Prepare writable directories with GID 0
+# (Nginx needs to write to cache, logs, and PID file locations)
+RUN mkdir -p /tmp/nginx-cache /tmp/nginx-run && \
+    chgrp -R 0 /tmp/nginx-cache /tmp/nginx-run && \
+    chmod -R g=u /tmp/nginx-cache /tmp/nginx-run
+
+# Runtime stage — distroless, NO shell, NO RUN commands
+FROM YOUR_ORG/dhi-nginx:1.29-alpine3.23
+
+COPY --from=build --chown=65532:0 /tmp/nginx.conf /etc/nginx/nginx.conf
+COPY --from=build --chown=65532:0 /tmp/default.conf /etc/nginx/conf.d/default.conf
+COPY --from=build --chown=65532:0 /tmp/nginx-cache /var/cache/nginx
+COPY --from=build --chown=65532:0 /tmp/nginx-run /var/run
+```
+
+> [!IMPORTANT]
+> 
+> Always use `--chown=<UID>:0` (user:root-group) when copying files into the
+> runtime stage. This ensures the arbitrary UID that OpenShift assigns can
+> access the files through root group membership. Never use `RUN` in the runtime
+> stage — distroless DHI images have no shell.
+
+> [!NOTE]
+> 
+> The UID for DHI images varies by image. Most use 65532 (`nonroot`), but some
+> (like the Node.js image) may use a different UID. Verify with:
+> `docker inspect dhi.io/<image>:<tag> --format '{{.Config.User}}'`
+
+Deploy to OpenShift:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-dhi
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: nginx-dhi
+  template:
+    metadata:
+      labels:
+        app: nginx-dhi
+    spec:
+      containers:
+        - name: nginx
+          image: YOUR_ORG/dhi-nginx:1.29-alpine3.23
+          ports:
+            - containerPort: 8080
+          securityContext:
+            allowPrivilegeEscalation: false
+            runAsNonRoot: true
+            seccompProfile:
+              type: RuntimeDefault
+            capabilities:
+              drop:
+                - ALL
+      imagePullSecrets:
+        - name: dhi-pull-secret
+```
+
+DHI Nginx listens on port 8080 by default (not 80), which is compatible with
+the non-root requirement. No SCC changes are needed.
+
+### Example: Node.js application for OpenShift
+
+```dockerfile
+# Build stage — dev variant has shell and npm
+FROM YOUR_ORG/dhi-node:24-alpine3.23-dev AS build
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci
+COPY . .
+RUN npm run build
+
+# Set GID 0 on everything the runtime needs to write
+RUN chgrp -R 0 /app/dist /app/node_modules && \
+    chmod -R g=u /app/dist /app/node_modules
+
+# Runtime stage — distroless, NO shell
+FROM YOUR_ORG/dhi-node:24-alpine3.23
+WORKDIR /app
+COPY --from=build --chown=65532:0 /app/dist ./dist
+COPY --from=build --chown=65532:0 /app/node_modules ./node_modules
+CMD ["node", "dist/index.js"]
+```
+
+Deploy:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: node-app
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      app: node-app
+  template:
+    metadata:
+      labels:
+        app: node-app
+    spec:
+      containers:
+        - name: app
+          image: YOUR_ORG/dhi-node-app:latest
+          ports:
+            - containerPort: 3000
+          securityContext:
+            allowPrivilegeEscalation: false
+            runAsNonRoot: true
+            seccompProfile:
+              type: RuntimeDefault
+            capabilities:
+              drop:
+                - ALL
+      imagePullSecrets:
+        - name: dhi-pull-secret
+```
+
+## Handle arbitrary user IDs
+
+OpenShift’s `restricted-v2` SCC assigns a random UID to the container process.
+This UID won’t exist in `/etc/passwd` inside the image, but the container will
+still run — the process just won’t have a username associated with it.
+
+This can cause issues with applications that:
+
+- Look up the current user’s home directory or username
+- Write to directories owned by a specific UID
+- Check `/etc/passwd` for the running user
+
+### Add a `passwd` entry for the arbitrary UID
+
+Some applications (notably those using certain Python or Java libraries) require
+a valid `/etc/passwd` entry for the running user. You can handle this with a
+wrapper entrypoint script.
+
+Because this pattern requires a shell, it only works with DHI `-dev` variants or
+with a DHI Enterprise customized image that includes a shell. Prepare the image
+in the build stage:
+
+```dockerfile
+FROM YOUR_ORG/dhi-python:3.13-alpine3.23-dev AS build
+# ... build your application ...
+
+# Make /etc/passwd group-writable so the entrypoint can append to it
+RUN chgrp 0 /etc/passwd && chmod g=u /etc/passwd
+
+# Create the entrypoint wrapper
+RUN printf '#!/bin/sh\n\
+if ! whoami > /dev/null 2>&1; then\n\
+  if [ -w /etc/passwd ]; then\n\
+    echo "${USER_NAME:-appuser}:x:$(id -u):0:dynamic user:/tmp:/sbin/nologin" >> /etc/passwd\n\
+  fi\n\
+fi\n\
+exec "$@"\n' > /entrypoint.sh && chmod +x /entrypoint.sh
+
+# This pattern requires a -dev variant as runtime (has shell)
+FROM YOUR_ORG/dhi-python:3.13-alpine3.23-dev
+COPY --from=build --chown=65532:0 /app ./app
+COPY --from=build --chown=65532:0 /entrypoint.sh /entrypoint.sh
+COPY --from=build --chown=65532:0 /etc/passwd /etc/passwd
+USER 65532
+ENTRYPOINT ["/entrypoint.sh"]
+CMD ["python", "app/main.py"]
+```
+
+> [!NOTE]
+> 
+> For distroless runtime images (no shell), the passwd-injection pattern is not
+> possible. Instead, use the `nonroot` SCC (described in the following section) to run with the
+> image’s built-in UID so the existing `/etc/passwd` entry matches the running
+> process. Alternatively, OpenShift 4.x automatically injects the arbitrary UID
+> into `/etc/passwd` in most cases, which resolves this for many applications.
+
+## Use the non-root SCC for fixed UIDs
+
+If your application requires running as the specific UID defined in the image
+(typically 65532 for DHI), you can use the `nonroot` SCC instead of the default
+`restricted-v2`. The `nonroot` SCC uses the `MustRunAsNonRoot` strategy, which
+allows any non-zero UID.
+
+> [!IMPORTANT]
+> 
+> For the `nonroot` SCC to work, the image’s `USER` directive must specify a
+> **numeric** UID (for example, `65532`), not a username string like `nonroot`.
+> OpenShift cannot verify that a username maps to a non-zero UID. Verify your
+> DHI image with:
+> `docker inspect YOUR_ORG/dhi-node:24-alpine3.23 --format '{{.Config.User}}'`
+> If the output is a string rather than a number, set `runAsUser` explicitly in
+> the pod spec.
+
+Create a service account and grant it the `nonroot` SCC:
+
+```console
+oc create serviceaccount dhi-nonroot
+oc adm policy add-scc-to-user nonroot -z dhi-nonroot
+```
+
+Reference the service account in your deployment:
+
+```yaml
+spec:
+  template:
+    spec:
+      serviceAccountName: dhi-nonroot
+      containers:
+        - name: app
+          image: YOUR_ORG/dhi-node:24-alpine3.23
+          securityContext:
+            runAsUser: 65532
+            runAsNonRoot: true
+            allowPrivilegeEscalation: false
+            seccompProfile:
+              type: RuntimeDefault
+            capabilities:
+              drop:
+                - ALL
+```
+
+Verify the SCC assignment after deployment:
+
+```console
+oc get pod <pod-name> -o jsonpath='{.metadata.annotations.openshift\.io/scc}'
+```
+
+This should return `nonroot`.
+
+When using the `nonroot` SCC with a fixed UID, the process runs as 65532
+(matching the image’s file ownership), so the GID 0 adjustments are not strictly
+required for paths already owned by 65532. However, applying `chown <UID>:0` is
+still recommended for portability across both `restricted-v2` and `nonroot` SCCs.
+
+## Use DHI dev variants in OpenShift
+
+DHI `-dev` variants include a shell, package manager, and development tools.
+They run as root (UID 0) by default, which conflicts with OpenShift’s
+`restricted-v2` SCC. There are three approaches:
+
+### Option 1: Use dev variants only in build stages (recommended)
+
+Use `-dev` variants only in Dockerfile build stages and never deploy them
+directly to OpenShift:
+
+```dockerfile
+FROM YOUR_ORG/dhi-node:24-alpine3.23-dev AS build
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci
+COPY . .
+RUN npm run build
+
+# Set root group ownership for OpenShift compatibility
+RUN chgrp -R 0 /app/dist /app/node_modules && \
+    chmod -R g=u /app/dist /app/node_modules
+
+FROM YOUR_ORG/dhi-node:24-alpine3.23
+WORKDIR /app
+COPY --from=build --chown=65532:0 /app/dist ./dist
+COPY --from=build --chown=65532:0 /app/node_modules ./node_modules
+CMD ["node", "dist/index.js"]
+```
+
+The final runtime image is non-root and distroless, fully compatible with
+`restricted-v2`.
+
+### Option 2: Grant the `anyuid` SCC for debugging
+
+If you need to run a `-dev` variant directly in OpenShift for debugging, grant
+the `anyuid` SCC to a dedicated service account:
+
+```console
+oc create serviceaccount dhi-debug
+oc adm policy add-scc-to-user anyuid -z dhi-debug
+```
+
+Then reference it in your pod:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: dhi-debug
+spec:
+  serviceAccountName: dhi-debug
+  containers:
+    - name: debug
+      image: YOUR_ORG/dhi-node:24-alpine3.23-dev
+      command: ["sleep", "infinity"]
+  imagePullSecrets:
+    - name: dhi-pull-secret
+```
+
+> [!IMPORTANT]
+> 
+> The `anyuid` SCC allows running as any UID including root. Only use this for
+> temporary debugging — never in production workloads.
+
+### Option 3: Use `oc debug` or ephemeral containers
+
+For distroless runtime images with no shell, use OpenShift-native debugging
+tools instead of `docker debug` (which only works with Docker Engine, not with
+CRI-O on OpenShift).
+
+Use `oc debug` to create a copy of a pod with a debug shell:
+
+```console
+# Create a debug pod based on a deployment
+oc debug deployment/nginx-dhi
+
+# Override the image to use a -dev variant with a shell
+oc debug deployment/nginx-dhi --image=YOUR_ORG/dhi-node:24-alpine3.23-dev
+```
+
+Use ephemeral containers (OpenShift 4.12+ / Kubernetes 1.25+):
+
+```console
+kubectl debug -it <pod-name> --image=YOUR_ORG/dhi-node:24-alpine3.23-dev \
+    --target=app -- sh
+```
+
+This attaches a temporary debug container to a running pod without restarting
+it, sharing the pod’s process namespace.
+
+> [!NOTE]
+> 
+> `docker debug` is a Docker Desktop/CLI feature for local development. It is
+> not available on OpenShift clusters, which use CRI-O as their container
+> runtime.
+
+## Deploy DHI Helm charts on OpenShift
+
+DHI provides pre-configured Helm charts for popular applications. When deploying
+these charts on OpenShift, you may need to adjust security context settings.
+
+### Inspect chart values first
+
+Before installing, check what security context values the chart exposes:
+
+```console
+helm registry login dhi.io
+
+helm show values oci://dhi.io/<chart-name> --version <version> | grep -A 20 securityContext
+```
+
+The available value paths vary by chart, so always check `values.yaml` before
+setting overrides.
+
+### Install with OpenShift overrides
+
+The following example shows a typical installation pattern. Adjust the `--set`
+paths based on what `helm show values` returns for your specific chart:
+
+```console
+helm install my-release oci://dhi.io/<chart-name> \
+    --version <version> \
+    --set "imagePullSecrets[0].name=dhi-pull-secret" \
+    -f openshift-values.yaml
+```
+
+Create an `openshift-values.yaml` with security context overrides appropriate
+for your chart:
+
+```yaml
+# Example — adjust keys based on `helm show values` output
+podSecurityContext:
+  runAsNonRoot: true
+  seccompProfile:
+    type: RuntimeDefault
+
+securityContext:
+  allowPrivilegeEscalation: false
+  capabilities:
+    drop:
+      - ALL
+```
+
+> [!NOTE]
+> 
+> DHI Helm chart value paths are not standardized across charts. For example,
+> one chart may use `image.imagePullSecrets`, while another uses
+> `global.imagePullSecrets`. Always consult the specific chart’s documentation
+> or `values.yaml`.
+
+## Verify your deployment
+
+After deploying a DHI image to OpenShift, verify the security configuration.
+
+### Check the assigned SCC
+
+```console
+oc get pods -o 'custom-columns=NAME:.metadata.name,SCC:.metadata.annotations.openshift\.io/scc'
+```
+
+Runtime DHI images should show `restricted-v2` (or `nonroot` if you configured
+it).
+
+### Check the running UID
+
+```console
+oc exec <pod-name> -- id
+```
+
+With the `restricted-v2` SCC, you should see output like:
+
+```text
+uid=1000650000 gid=0(root) groups=0(root),1000650000
+```
+
+The UID is from the project’s allocated range, and the primary GID is always 0
+(root group). With the `nonroot` SCC and `runAsUser: 65532`, you would see
+`uid=65532`.
+
+### Confirm the image is distroless
+
+```console
+oc exec <pod-name> -- sh -c "echo hello"
+```
+
+For runtime (non-dev) DHI images, this command should fail with an error
+indicating that `sh` was not found in `$PATH`. The exact error format varies
+between CRI-O versions.
+
+### Scan the deployed image
+
+Use Docker Scout to verify the security posture of the deployed image (run this
+from your local machine, not on the cluster):
+
+```console
+docker scout cves YOUR_ORG/dhi-nginx:1.29-alpine3.23
+docker scout quickview YOUR_ORG/dhi-nginx:1.29-alpine3.23
+```
+
+## Common issues and solutions
+
+**Pod fails to start with “container has runAsNonRoot and image has group or
+user ID set to root.”** This happens when deploying a DHI `-dev` variant with
+the default `restricted-v2` SCC. Either use the runtime variant instead, or
+grant the `anyuid` SCC to the service account.
+
+**Application cannot write to a directory.** The arbitrary UID assigned by
+OpenShift doesn’t have write permissions. This is the most common issue with DHI
+on OpenShift. All writable paths must be owned by GID 0 with group write
+permissions. Fix this in the build stage:
+`chgrp -R 0 /path && chmod -R g=u /path`, then `COPY --chown=<UID>:0` into the
+runtime stage.
+
+**Application fails with “user not found” or “no matching entries in passwd
+file.”** Some applications require a valid `/etc/passwd` entry. OpenShift 4.x
+automatically injects the arbitrary UID into `/etc/passwd` in most cases. If
+your application still fails, use the passwd-injection pattern (requires a `-dev`
+variant) or use the `nonroot` SCC to run with the image’s built-in UID.
+
+**Pod fails to bind to port 80 or 443.** Ports lower than 1024 require root
+privileges. DHI images use unprivileged ports by default (for example, Nginx
+uses 8080). Configure your OpenShift Service to map the external port to the
+container’s unprivileged port:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx-dhi
+spec:
+  ports:
+    - port: 80
+      targetPort: 8080
+  selector:
+    app: nginx-dhi
+```
+
+**ImagePullBackOff with “unauthorized: authentication required.”** Verify the
+pull secret is correctly configured and linked to the service account. Check
+with `oc get secret dhi-pull-secret` and `oc describe sa default`.
+
+**Dockerfile build fails with “exec: not found” in runtime stage.** You are
+using `RUN` in a distroless runtime stage. DHI runtime images have no shell, so
+`RUN` commands cannot execute. Move all `RUN` commands to the `-dev` build stage
+and use `COPY --chown` to transfer results.
+
+## DHI and OpenShift compatibility summary
+
+|Feature                      |DHI runtime                      |DHI `-dev`          |DHI with Enterprise customization|
+|-----------------------------|---------------------------------|--------------------|---------------------------------|
+|Default SCC (`restricted-v2`)|Yes, with GID 0 permissions      |Requires `anyuid`   |Yes, with GID 0 permissions      |
+|Non-root by default          |Yes (UID 65532)                  |No (root)           |Yes (configurable UID)           |
+|Arbitrary UID support        |Yes, with `chown <UID>:0`        |Yes                 |Yes, with `chown <UID>:0`        |
+|Distroless (no shell)        |Yes — no `RUN` in Dockerfile     |No                  |Yes — no `RUN` in Dockerfile     |
+|Unprivileged ports           |Yes (higher than 1024)                 |Configurable        |Yes (higher than 1024)                 |
+|SLSA Build Level 3           |Yes                              |Yes                 |Yes                              |
+|Debug on cluster             |`oc debug` / ephemeral containers|`oc exec` with shell|`oc debug` / ephemeral containers|
+
+## What’s next
+
+- [Use an image in Kubernetes](/dhi/how-to/k8s/) — general DHI Kubernetes deployment guide.
+- [Customize an image](/dhi/how-to/customize/) — add packages to DHI images using Enterprise customization.
+- [Debug a container](/dhi/how-to/troubleshoot/#general-debugging) — troubleshoot distroless containers with Docker Debug (local development).
+- [Managing SCCs](https://docs.openshift.com/container-platform/4.14/authentication/managing-security-context-constraints.html) — Red Hat’s reference documentation on Security Context Constraints.
+- [Creating images for OpenShift](https://docs.openshift.com/container-platform/4.14/openshift_images/create-images.html) — Red Hat’s guidelines for building OpenShift-compatible container images.
diff --git a/content/guides/dhi-vex-walkthrough.md b/content/guides/dhi-vex-walkthrough.md
new file mode 100644
index 000000000000..89ceed00b706
--- /dev/null
+++ b/content/guides/dhi-vex-walkthrough.md
@@ -0,0 +1,375 @@
+---
+title: Explore VEX statements in Docker Hardened Images
+description: |
+  Scan a Docker Hardened Image with and without VEX and audit every CVE suppression
+  and its justification.
+summary: >
+  Scan a Docker Hardened Image with and without VEX and audit every suppression
+  and its justification.
+keywords: vex, openvex, not_affected, under_investigation, affected, cve, docker scout, dhi, vulnerability
+weight: 1
+params:
+  tags: [security]
+  featured: true
+  proficiencyLevel: Intermediate
+  time: 25 minutes
+---
+
+Standard vulnerability scanners report CVEs against packages present in an
+image. With Docker Hardened Images, those packages are there by design, but each
+reported CVE has a VEX statement explaining whether it is exploitable in this
+specific product configuration. This guide walks through scanning a Docker
+Hardened Image with and without VEX and auditing the justification behind every
+suppression.
+
+## Prerequisites
+
+- [Docker Desktop](https://www.docker.com/products/docker-desktop/), authenticated
+  to `dhi.io`. Sign in with `docker login dhi.io`. Docker Desktop includes
+  Docker Scout, which fetches the VEX attestation.
+- A vulnerability scanner. This guide shows examples for Docker Scout,
+  [Trivy](https://trivy.dev/), and [Grype](https://github.com/anchore/grype).
+  Trivy and Grype can also run as Docker containers with no installation needed.
+- `jq` (optional), for filtering the VEX file.
+
+## Expose daemon for Windows users
+
+The `-v /var/run/docker.sock:/var/run/docker.sock` socket mount used in the
+containerized scanner commands throughout this guide does not work on Docker
+Desktop for Windows. To use containerized scanners on Windows, go to
+**Settings > General** in Docker Desktop and turn on **Expose daemon on
+tcp://localhost:2375 without TLS**. Then replace
+`-v /var/run/docker.sock:/var/run/docker.sock` with
+`-e DOCKER_HOST=tcp://host.docker.internal:2375` in every containerized
+scanner command.
+
+> [!WARNING]
+>
+> Exposing the daemon on TCP without TLS makes your system vulnerable to
+> remote code execution attacks. Turn off the setting when you are done
+> testing.
+
+## Step 1: Scan without VEX
+
+Sign in to the Docker Hardened Images registry:
+
+```console
+$ docker login dhi.io
+```
+
+Then pull the image:
+
+```console
+$ docker pull dhi.io/python:3.13
+```
+
+Then scan without VEX to see the raw CVE count. Docker Scout automatically
+applies VEX on Docker Hardened Images. To see the unfiltered CVE baseline,
+use Trivy or Grype.
+
+{{< tabs >}}
+{{< tab name="Trivy" >}}
+
+```console
+$ trivy image --scanners vuln dhi.io/python:3.13
+```
+
+If Trivy isn't installed, run it in a container:
+
+```console
+$ docker run --rm \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  aquasec/trivy:latest image --scanners vuln dhi.io/python:3.13
+```
+
+Example output:
+
+```plaintext
+Total: 30 (UNKNOWN: 0, LOW: 15, MEDIUM: 11, HIGH: 4, CRITICAL: 0)
+```
+
+{{< /tab >}}
+{{< tab name="Grype" >}}
+
+```console
+$ grype dhi.io/python:3.13
+```
+
+If Grype isn't installed, run it in a container:
+
+```console
+$ docker run --rm \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  anchore/grype:latest docker:dhi.io/python:3.13
+```
+
+Example output:
+
+```plaintext
+NAME          INSTALLED              FIXED IN     TYPE  VULNERABILITY       SEVERITY
+libc6         2.41-12+deb13u2                     deb   CVE-2018-20796      Negligible
+libc6         2.41-12+deb13u2        (won't fix)  deb   CVE-2026-4437       High
+libc6         2.41-12+deb13u2        (won't fix)  deb   CVE-2026-5450       Critical
+...
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+The output lists CVEs across `libc6`, `libncursesw6`, `libsqlite3-0`, `libuuid1`,
+`zlib1g`, and others, all runtime dependencies that Python needs to function.
+These packages are present by design.
+
+A scan result like this doesn't mean every reported CVE requires patching. It means
+these CVEs have been reported against packages present in the image. Whether any of
+those CVEs are actually exploitable in this configuration is a separate
+question, and that's exactly what VEX answers.
+
+## Step 2: Fetch the VEX attestation
+
+Export the VEX attestation to a local file:
+
+```console
+$ docker scout vex get registry://dhi.io/python:3.13 --output python-vex.json
+```
+
+The `registry://` prefix tells Scout to fetch the attestation from the registry
+rather than the local image store. Because you pulled the image in Step 1, it
+already exists locally, and without this prefix Scout would find no attestation
+there.
+
+This fetches a signed OpenVEX document from `registry.scout.docker.com`,
+Docker's supply chain metadata registry for all Docker Hardened Images. The
+document records Docker's exploitability assessment for every CVE found in the
+image's SBOM.
+
+> [!NOTE]
+>
+> Docker Scout fetches this file automatically when scanning. You only need to
+> download it explicitly for scanners that don't natively integrate it, or to
+> run the `jq` queries in Steps 5 and 6.
+
+## Step 3: Scan with VEX applied
+
+{{< tabs >}}
+{{< tab name="Docker Scout" >}}
+
+Docker Scout automatically fetches and applies the VEX attestation with no local
+file needed:
+
+```console
+$ docker scout cves dhi.io/python:3.13
+```
+
+Example output:
+
+```plaintext
+    ✓ SBOM obtained from attestation, 47 packages indexed
+    ✓ Provenance obtained from attestation
+    ✓ VEX statements obtained from attestation
+    ✓ No vulnerable package detected
+```
+
+{{< /tab >}}
+{{< tab name="Trivy" >}}
+
+Pass the VEX file with the `--vex` flag:
+
+```console
+$ trivy image --scanners vuln --vex python-vex.json dhi.io/python:3.13
+```
+
+If Trivy isn't installed, run it in a container:
+
+```console
+$ docker run --rm \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  -v "$(pwd)/python-vex.json:/tmp/vex.json" \
+  aquasec/trivy:latest image --scanners vuln --vex /tmp/vex.json dhi.io/python:3.13
+```
+
+Example output:
+
+```plaintext
+Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
+
+Some vulnerabilities have been ignored/suppressed. Use the '--show-suppressed' flag to display them.
+```
+
+{{< /tab >}}
+{{< tab name="Grype" >}}
+
+Pass the VEX file with the `--vex` flag:
+
+```console
+$ grype dhi.io/python:3.13 --vex python-vex.json
+```
+
+If Grype isn't installed, run it in a container:
+
+```console
+$ docker run --rm \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  -v "$(pwd)/python-vex.json:/tmp/vex.json" \
+  anchore/grype:latest docker:dhi.io/python:3.13 --vex /tmp/vex.json
+```
+
+Example output:
+
+```plaintext
+No vulnerabilities found
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Same image, same packages, same CVE database. The only difference is context.
+The scanner matched each CVE against the VEX file and suppressed every one that
+Docker assessed as not exploitable.
+
+The packages are still there. Check the SBOM and you will see `libc6`,
+`libsqlite3-0`, and every other package from Step 1. Zero CVEs does not mean
+the packages were removed. It means each reported CVE has a documented reason
+why it does not apply to this product configuration.
+
+VEX is an open standard: the attestation travels with the image and any
+compliant scanner reads the same reasoning.
+
+## Step 4: Inspect every suppression and its justification
+
+Docker Scout and Grype suppress VEX-matched CVEs but do not surface the
+justification code in their output. Use Trivy's `--show-suppressed` flag to see
+every suppressed CVE alongside its per-CVE justification code.
+
+```console
+$ trivy image --scanners vuln --vex python-vex.json --show-suppressed dhi.io/python:3.13
+```
+
+If Trivy isn't installed, run it in a container:
+
+```console
+$ docker run --rm \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  -v "$(pwd)/python-vex.json:/tmp/vex.json" \
+  aquasec/trivy:latest image --scanners vuln --vex /tmp/vex.json --show-suppressed dhi.io/python:3.13
+```
+
+Example output:
+
+```plaintext
+Suppressed Vulnerabilities (Total: 28)
+======================================
+┌──────────────┬──────────────────┬──────────┬──────────────┬───────────────────────────────────────────────────┐
+│   Library    │  Vulnerability   │ Severity │    Status    │                     Statement                     │
+├──────────────┼──────────────────┼──────────┼──────────────┼───────────────────────────────────────────────────┤
+│ libc6        │ CVE-2010-4756    │ LOW      │ not_affected │ vulnerable_code_cannot_be_controlled_by_adversary │
+│ libsqlite3-0 │ CVE-2025-70873   │ LOW      │ not_affected │ vulnerable_code_not_present                       │
+│ ...          │ ...              │ ...      │ ...          │ ...                                               │
+└──────────────┴──────────────────┴──────────┴──────────────┴───────────────────────────────────────────────────┘
+```
+
+The `Statement` column shows the machine-readable justification code from the
+VEX file.
+
+The justification codes have precise meanings:
+
+- `vulnerable_code_cannot_be_controlled_by_adversary`: the vulnerable code
+  path exists in the package, but an attacker cannot trigger it in this
+  configuration.
+- `vulnerable_code_not_present`: the vulnerable code was not compiled into
+  this build or is otherwise absent.
+- `inline_mitigations_already_exist`: Docker has applied a backport or patch
+  that addresses the CVE in this image.
+
+For the full list of justification codes, see [VEX status
+reference](/manuals/dhi/explore/security-concepts/vex.md#not_affected-justification-codes).
+
+Every suppression is documented, auditable, and verifiable with any VEX-enabled
+scanner.
+
+## Step 5: Read Docker's reasoning for a specific CVE
+
+The justification codes are machine-readable; the `status_notes` field in the
+VEX file contains Docker's human-readable reasoning. Use `jq` to look up a
+specific CVE:
+
+```console
+$ jq '.statements[] | select(.vulnerability.name == "CVE-2010-4756") | {status, justification, status_notes}' python-vex.json
+```
+
+Example output:
+
+```json
+{
+  "status": "not_affected",
+  "justification": "vulnerable_code_cannot_be_controlled_by_adversary",
+  "status_notes": "Standard POSIX behavior in glibc. Applications using glob need to impose limits themselves. Requires authenticated access and is considered unimportant by Debian."
+}
+```
+
+The `status_notes` field explains Docker's reasoning in plain language. For
+CVE-2010-4756, the glob behavior described by the CVE is standard POSIX
+behavior, requires authenticated access, and is classified as unimportant by
+the Debian security team.
+
+Each statement also lists the affected products as Package URLs (PURLs), for
+example `pkg:deb/debian/glibc@2.41-12%2Bdeb13u2?os_distro=trixie&os_name=debian&os_version=13`.
+Trivy matched this statement to `libc6` in the image's SBOM by comparing that
+PURL against the packages recorded in the SBOM.
+
+> [!IMPORTANT]
+>
+> PURL matching is strict. Scanners must match VEX statements to packages
+> using the full PURL string, including the `os_name`, `os_version`, and
+> `os_distro` qualifiers. Matching on package name alone risks applying a
+> suppression from one OS version to a different version where the CVE *is*
+> exploitable.
+
+## Step 6: Filter VEX statements by status
+
+Once you have `python-vex.json`, use `jq` to query it directly.
+
+Count statements by status:
+
+```console
+$ jq '[.statements[].status] | group_by(.) | map({status: .[0], count: length})' python-vex.json
+```
+
+List all CVEs under active investigation:
+
+```console
+$ jq '[.statements[] | select(.status == "under_investigation") | {cve: .vulnerability.name, products: [.products[]."@id"]}]' python-vex.json
+```
+
+List any CVEs with `affected` status:
+
+```console
+$ jq '[.statements[] | select(.status == "affected") | {cve: .vulnerability.name, action: .action_statement}]' python-vex.json
+```
+
+The `affected` query returns an empty array for the current `dhi.io/python:3.13`
+image, which is the expected result for an actively maintained tag. To see `affected`
+entries across all DHI Python versions, query the full VEX feed:
+
+```console
+$ curl -s https://raw.githubusercontent.com/docker-hardened-images/advisories/main/vex/python/dhi-python.vex.json \
+  | jq '[.statements[] | select(.status == "affected") | {cve: .vulnerability.name, action: .action_statement}]'
+```
+
+For status definitions and justification codes, see the [VEX status
+reference](/manuals/dhi/explore/security-concepts/vex.md#vex-status-reference).
+
+## What's next
+
+- Scan with other tools: Learn how to apply DHI VEX statements with Trivy
+  (VEX Hub) and Grype in [Scan Docker Hardened
+  Images](/manuals/dhi/how-to/scan.md).
+- Write your own VEX for child images: If you build on top of a DHI and
+  want to suppress CVEs in packages you add, see [Create an exception using
+  VEX](/manuals/scout/how-tos/create-exceptions-vex.md).
+- VEX status reference: For status definitions, justification codes, and
+  why DHI does not use `fixed`, see [Vulnerability Exploitability eXchange
+  (VEX)](/manuals/dhi/explore/security-concepts/vex.md#vex-status-reference).
+- Browse the VEX feed directly: The raw VEX data is published at
+  [github.com/docker-hardened-images/advisories](https://github.com/docker-hardened-images/advisories/tree/main/vex),
+  organized by image name.
diff --git a/content/guides/django.md b/content/guides/django.md
new file mode 100644
index 000000000000..837de854dc68
--- /dev/null
+++ b/content/guides/django.md
@@ -0,0 +1,432 @@
+---
+title: Containerize a Django application
+linkTitle: Django
+description: Learn how to containerize a Django application using Docker.
+keywords: python, django, containerize, initialize, gunicorn, compose watch, uv
+summary: |
+  This guide shows how to containerize a Django application using Docker.
+  You'll scaffold the project with uv, create a production-ready Dockerfile
+  using a Docker Hardened Image, then add a development stage and Compose Watch
+  for fast iteration.
+params:
+  tags: [security]
+  time: 25 minutes
+---
+
+## Prerequisites
+
+- You have installed the latest version of [Docker
+  Desktop](/get-started/get-docker.md).
+- You have [uv](https://docs.astral.sh/uv/) installed, or you can use Docker to
+  scaffold the project without a local Python or uv installation.
+
+> [!TIP]
+>
+> If you're new to Docker, start with the [Docker
+> basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide
+> to get familiar with key concepts like images, containers, and Dockerfiles.
+
+---
+
+## Overview
+
+This guide walks you through containerizing a Django application with Docker. By
+the end, you will:
+
+- Initialize a Django project using uv, either locally or inside a Docker
+  Hardened Image container.
+- Create a production-ready Dockerfile using [Docker Hardened Images
+  (DHI)](/dhi/).
+- Add a `development` stage to your Dockerfile and configure Compose Watch for
+  automatic code syncing.
+
+---
+
+## Create the Django project
+
+You can bootstrap the project with a local uv installation, or entirely inside a
+container using the same DHI image the Dockerfile uses, with no local Python
+required.
+
+{{< tabs >}} {{< tab name="Local (uv)" >}}
+
+1. Initialize the project pinned to Python 3.14, then navigate into it:
+
+   ```console
+   $ uv init --python 3.14 django-docker
+   $ cd django-docker
+   ```
+
+2. Add Django and Gunicorn, then scaffold the Django project:
+
+   ```console
+   $ uv add django gunicorn
+   $ uv run django-admin startproject myapp .
+   ```
+
+{{< /tab >}} {{< tab name="Container (DHI)" >}}
+
+The DHI dev image already has Python 3.14, so the bootstrapped project will
+match the Dockerfile exactly.
+
+1. Create the project directory and navigate into it:
+
+   ```console
+   $ mkdir django-docker && cd django-docker
+   ```
+
+2. Initialize the project, add dependencies, and scaffold. All in one container
+   run:
+
+   ```console
+   $ docker run --rm -v $PWD:$PWD -w $PWD \
+     -e UV_LINK_MODE=copy \
+     dhi.io/python:3.14-alpine3.23-dev \
+     sh -c "pip install --quiet --root-user-action=ignore uv && uv init --name django-docker --python 3.14 . && uv add django gunicorn && uv run django-admin startproject myapp ."
+   ```
+
+   > [!NOTE]
+   >
+   > The previous command uses Mac/Linux shell syntax. On Windows, adjust
+   > the path: PowerShell uses `${PWD}`, Command Prompt uses `%cd%`, Git Bash
+   > requires `MSYS_NO_PATHCONV=1` with `$(pwd -W)`.
+
+{{< /tab >}} {{< /tabs >}}
+
+Your directory should now contain the following files:
+
+```text
+├── .python-version
+├── main.py
+├── manage.py
+├── myapp/
+│ ├── __init__.py
+│ ├── asgi.py
+│ ├── settings.py
+│ ├── urls.py
+│ └── wsgi.py
+├── pyproject.toml
+├── uv.lock
+└── README.md
+```
+
+---
+
+## Create a production Dockerfile
+
+Docker Hardened Images are production-ready base images maintained by Docker
+that minimize attack surface. For more details, see [Docker Hardened
+Images](/dhi/).
+
+1. Sign in to the DHI registry:
+
+   ```console
+   $ docker login dhi.io
+   ```
+
+2. Create a `.dockerignore` file to exclude local artifacts from the build
+   context:
+
+   ```text {title=".dockerignore"}
+   .venv/
+   __pycache__/
+   *.pyc
+   .git/
+   ```
+
+3. Create a `Dockerfile` with the following contents:
+
+   ```dockerfile {title="Dockerfile"}
+   # syntax=docker/dockerfile:1
+
+   # Build stage: the -dev image includes tools needed to install packages.
+   FROM dhi.io/python:3.14-alpine3.23-dev AS builder
+
+   # Prevent Python from writing .pyc files to disk.
+   ENV PYTHONDONTWRITEBYTECODE=1
+   # Prevent Python from buffering stdout/stderr so logs appear immediately.
+   ENV PYTHONUNBUFFERED=1
+
+   RUN pip install --quiet --root-user-action=ignore uv
+   # Use copy mode since the cache and build filesystem are on different volumes.
+   ENV UV_LINK_MODE=copy
+
+   WORKDIR /app
+
+   # Install dependencies into a virtual environment using cache and bind mounts
+   # so neither uv nor the lock files need to be copied into the image.
+   RUN --mount=type=cache,target=/root/.cache/uv \
+       --mount=type=bind,source=uv.lock,target=uv.lock \
+       --mount=type=bind,source=pyproject.toml,target=pyproject.toml \
+       uv sync --frozen --no-install-project
+
+   # Runtime stage: minimal DHI image with no shell or package manager,
+   # already runs as the nonroot user.
+   FROM dhi.io/python:3.14-alpine3.23
+
+   # Prevent Python from buffering stdout/stderr so logs appear immediately.
+   ENV PYTHONUNBUFFERED=1
+   # Activate the virtual environment copied from the build stage.
+   ENV PATH="/app/.venv/bin:$PATH"
+
+   WORKDIR /app
+
+   # Copy the pre-built virtual environment and application source code.
+   COPY --from=builder /app/.venv /app/.venv
+   COPY . .
+
+   EXPOSE 8000
+
+   # Run Gunicorn as the production WSGI server.
+   CMD ["gunicorn", "myapp.wsgi:application", "--bind", "0.0.0.0:8000"]
+   ```
+
+4. Create a `compose.yaml` file:
+
+   ```yaml {title="compose.yaml"}
+   services:
+     web:
+       build: .
+       ports:
+         - "8000:8000"
+   ```
+
+### Run the application
+
+From the `django-docker` directory, run:
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and navigate to [http://localhost:8000](http://localhost:8000).
+You should see the Django welcome page.
+
+Press `ctrl`+`c` to stop the application.
+
+---
+
+## Set up a development environment
+
+The production setup uses Gunicorn and requires a full image rebuild to pick up
+code changes. For development, you can add a `development` stage to your
+Dockerfile that uses Django's built-in server, and configure Compose Watch to
+automatically sync code changes into the running container without a rebuild.
+
+### Update the Dockerfile
+
+Replace your `Dockerfile` with a multi-stage version that adds a `development`
+stage alongside `production`:
+
+```dockerfile {title="Dockerfile"}
+# syntax=docker/dockerfile:1
+
+# Build stage: the -dev image includes tools needed to install packages.
+FROM dhi.io/python:3.14-alpine3.23-dev AS builder
+
+# Prevent Python from writing .pyc files to disk.
+ENV PYTHONDONTWRITEBYTECODE=1
+# Prevent Python from buffering stdout/stderr so logs appear immediately.
+ENV PYTHONUNBUFFERED=1
+
+RUN pip install --quiet --root-user-action=ignore uv
+# Use copy mode since the cache and build filesystem are on different volumes.
+ENV UV_LINK_MODE=copy
+
+WORKDIR /app
+
+# Install dependencies into a virtual environment using cache and bind mounts
+# so neither uv nor the lock files need to be copied into the image.
+RUN --mount=type=cache,target=/root/.cache/uv \
+    --mount=type=bind,source=uv.lock,target=uv.lock \
+    --mount=type=bind,source=pyproject.toml,target=pyproject.toml \
+    uv sync --frozen --no-install-project
+
+# The development stage inherits the -dev image and virtual environment from
+# the builder. Django's built-in server reloads when Compose Watch syncs files.
+FROM builder AS development
+
+ENV PATH="/app/.venv/bin:$PATH"
+
+COPY . .
+EXPOSE 8000
+CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]
+
+# The production stage uses the minimal runtime image, which has no shell,
+# no package manager, and already runs as the nonroot user.
+FROM dhi.io/python:3.14-alpine3.23 AS production
+
+# Prevent Python from buffering stdout/stderr so logs appear immediately.
+ENV PYTHONUNBUFFERED=1
+# Activate the virtual environment copied from the build stage.
+ENV PATH="/app/.venv/bin:$PATH"
+
+WORKDIR /app
+
+# Copy only the pre-built virtual environment and application source code.
+COPY --from=builder /app/.venv /app/.venv
+COPY . .
+
+EXPOSE 8000
+
+# Run Gunicorn as the production WSGI server.
+CMD ["gunicorn", "myapp.wsgi:application", "--bind", "0.0.0.0:8000"]
+```
+
+### Update the Compose file
+
+Replace your `compose.yaml` with the following. It targets the `development`
+stage, adds a PostgreSQL database, and configures Compose Watch:
+
+```yaml {title="compose.yaml"}
+services:
+  web:
+    build:
+      context: .
+      # Build the development stage from the multi-stage Dockerfile.
+      target: development
+    ports:
+      - "8000:8000"
+    environment:
+      # Enable Django's verbose debug error pages (the dev server always auto-reloads).
+      - DEBUG=1
+      # Database connection settings passed to Django via environment variables.
+      - POSTGRES_DB=myapp
+      - POSTGRES_USER=postgres
+      - POSTGRES_PASSWORD=password
+      - POSTGRES_HOST=db
+      - POSTGRES_PORT=5432
+    # Wait for the database to pass its healthcheck before starting the web service.
+    depends_on:
+      db:
+        condition: service_healthy
+    develop:
+      watch:
+        # Sync source file changes directly into the container so Django's
+        # dev server can reload them without a full image rebuild.
+        - action: sync
+          path: .
+          target: /app
+          ignore:
+            - __pycache__/
+            - "*.pyc"
+            - .git/
+            - .venv/
+        # Rebuild the image when dependencies change.
+        - action: rebuild
+          path: pyproject.toml
+        - action: rebuild
+          path: uv.lock
+  db:
+    image: dhi.io/postgres:18
+    restart: always
+    volumes:
+      # Persist database data across container restarts.
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=myapp
+      - POSTGRES_USER=postgres
+      - POSTGRES_PASSWORD=password
+    # Expose the port only to other services on the Compose network,
+    # not to the host machine.
+    expose:
+      - 5432
+    # Only report healthy once PostgreSQL is ready to accept connections,
+    # so the web service doesn't start before the database is available.
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+```
+
+The `sync` action pushes file changes directly into the running container so
+Django's dev server reloads them automatically. A change to `pyproject.toml` or
+`uv.lock` triggers a full image rebuild instead.
+
+> [!NOTE]
+>
+> To learn more about Compose Watch, see [Use Compose
+> Watch](/manuals/compose/how-tos/file-watch.md).
+
+### Add the PostgreSQL driver
+
+Add the `psycopg` adapter to your project:
+
+{{< tabs >}} {{< tab name="Local (uv)" >}}
+
+```console
+$ uv add 'psycopg[binary]'
+```
+
+{{< /tab >}} {{< tab name="Container (DHI)" >}}
+
+```console
+$ docker run --rm -v $PWD:$PWD -w $PWD \
+  -e UV_LINK_MODE=copy \
+  dhi.io/python:3.14-alpine3.23-dev \
+  sh -c "pip install --quiet --root-user-action=ignore uv && uv add 'psycopg[binary]'"
+```
+
+{{< /tab >}} {{< /tabs >}}
+
+Then update `myapp/settings.py` to read `DEBUG` and `DATABASES` from environment
+variables:
+
+```python {title="myapp/settings.py"}
+import os
+
+DEBUG = os.environ.get('DEBUG', '0') == '1'
+
+DATABASES = {
+    "default": {
+        "ENGINE": "django.db.backends.postgresql",
+        "NAME": os.environ.get("POSTGRES_DB", "myapp"),
+        "USER": os.environ.get("POSTGRES_USER", "postgres"),
+        "PASSWORD": os.environ.get("POSTGRES_PASSWORD", "password"),
+        "HOST": os.environ.get("POSTGRES_HOST", "localhost"),
+        "PORT": os.environ.get("POSTGRES_PORT", "5432"),
+    }
+}
+```
+
+### Run with Compose Watch
+
+Start the development stack:
+
+```console
+$ docker compose watch
+```
+
+Open a browser and navigate to [http://localhost:8000](http://localhost:8000).
+
+Try editing a file, for example add a view to `myapp/views.py`. Compose Watch
+syncs the change into the container and Django's dev server reloads
+automatically. If you update `pyproject.toml` or `uv.lock`, Compose Watch
+triggers a full image rebuild.
+
+Press `ctrl`+`c` to stop.
+
+---
+
+## Summary
+
+In this guide, you:
+
+- Bootstrapped a Django project using uv, with options for both local and
+  containerized setup.
+- Created a production-ready Dockerfile using Docker Hardened Images and uv for
+  dependency management.
+- Added a `development` stage to the `Dockerfile` and configured Compose Watch
+  for fast iterative development with a PostgreSQL database.
+
+Related information:
+
+- [Dockerfile reference](/reference/dockerfile.md)
+- [Compose file reference](/reference/compose-file/_index.md)
+- [Use Compose Watch](/manuals/compose/how-tos/file-watch.md)
+- [Docker Hardened Images](/dhi/)
+- [Multi-stage builds](/manuals/build/building/multi-stage.md)
+- [uv documentation](https://docs.astral.sh/uv/)
diff --git a/content/guides/docker-build-cloud.md b/content/guides/docker-build-cloud.md
new file mode 100644
index 000000000000..211f5fbfe8c7
--- /dev/null
+++ b/content/guides/docker-build-cloud.md
@@ -0,0 +1,173 @@
+---
+title: "Docker Build Cloud: Reclaim your time with fast, multi-architecture builds"
+linkTitle: Docker Build Cloud
+description: |
+  Learn how to build and deploy Docker images to the cloud with Docker Build
+  Cloud.
+summary: |
+  Build applications up to 39x faster using cloud-based resources, shared team
+  cache, and native multi-architecture support.
+keywords: docker build cloud, cloud builds, multi-architecture, shared cache, ci/cd, build performance
+aliases:
+  - /learning-paths/docker-build-cloud/
+  - /guides/docker-build-cloud/ci/
+  - /guides/docker-build-cloud/common-questions/
+  - /guides/docker-build-cloud/dev/
+  - /guides/docker-build-cloud/why/
+params:
+  tags: [cicd]
+  image: images/learning-paths/build-cloud.png
+  time: 10 minutes
+---
+
+
+<!-- vale Vale.Spelling = NO -->
+
+98% of developers spend up to an hour every day waiting for builds to finish
+([Incredibuild: 2022 Big Dev Build Times](https://www.incredibuild.com/survey-report-2022)).
+Heavy, complex builds can become a major roadblock for development teams,
+slowing down both local development and CI/CD pipelines.
+
+<!-- vale Vale.Spelling = YES -->
+
+Docker Build Cloud speeds up image build times to improve developer
+productivity, reduce frustrations, and help you shorten the release cycle.
+
+## Who’s this for?
+
+- Anyone who wants to tackle common causes of slow image builds: limited local
+  resources, slow emulation, and lack of build collaboration across a team.
+- Developers working on older machines who want to build faster.
+- Development teams working on the same repository who want to cut wait times
+  with a shared cache.
+- Developers performing multi-architecture builds who don’t want to spend hours
+  configuring and rebuilding for emulators.
+
+## What you’ll learn
+
+- Building container images faster locally and in CI
+- Accelerating builds for multi-platform images
+- Reusing pre-built images to expedite workflows
+
+## Tools integration
+
+Works well with Docker Compose, GitHub Actions, and other CI solutions
+
+<div id="dbc-lp-survey-anchor"></div>
+
+## Why Docker Build Cloud?
+
+Docker Build Cloud is a service that lets you build container images faster,
+both locally and in CI. Builds run on cloud infrastructure optimally
+dimensioned for your workloads, with no configuration required. The service
+uses a remote build cache, ensuring fast builds anywhere and for all team
+members.
+
+Docker Build Cloud provides several benefits over local builds:
+
+- Improved build speed
+- Shared build cache
+- Native multi-platform builds
+
+There’s no need to worry about managing builders or infrastructure — simply
+connect to your builders and start building. Each cloud builder provisioned to
+an organization is completely isolated to a single Amazon EC2 instance, with a
+dedicated EBS volume for build cache and encryption in transit. That means
+there are no shared processes or data between cloud builders.
+
+{{< youtube-embed "8AqKhEO2PQA" >}}
+
+<div id="dbc-lp-survey-anchor"></div>
+
+## Demo: set up and use Docker Build Cloud in development
+
+With Docker Build Cloud, you can easily shift the build workload from local machines
+to the cloud, helping you achieve faster build times, especially for multi-platform builds.
+
+In this demo, you'll see:
+
+- How to setup the builder locally
+- How to use Docker Build Cloud with Docker Compose
+- How the image cache speeds up builds for others on your team
+
+{{< youtube-embed "oPGq2AP5OtQ" >}}
+
+<div id="dbc-lp-survey-anchor"></div>
+
+## Demo: Using Docker Build Cloud in CI
+
+Docker Build Cloud can significantly decrease the time it takes for your CI builds
+take to run, saving you time and money.
+
+Since the builds run remotely, your CI runner can still use the Docker tooling CLI
+without needing elevated permissions, making your builds more secure by default.
+
+In this demo, you will see:
+
+- How to integrate Docker Build Cloud into a variety of CI platforms
+- How to use Docker Build Cloud in GitHub Actions to build multi-architecture images
+- Speed differences between a workflow using Docker Build Cloud and a workflow running natively
+- How to use Docker Build Cloud in a GitLab Pipeline
+
+{{< youtube-embed "wvLdInoVBGg" >}}
+
+<div id="dbc-lp-survey-anchor"></div>
+
+## Common challenges and questions
+
+#### Is Docker Build Cloud a standalone product or a part of Docker Desktop?
+
+Docker Build Cloud is a service that can be used both with Docker Desktop and
+standalone. It lets you build your container images faster, both locally and in
+CI, with builds running on cloud infrastructure. The service uses a remote
+build cache, ensuring fast builds anywhere and for all team members.
+
+When used with Docker Desktop, the [Builds view](/desktop/use-desktop/builds/)
+works with Docker Build Cloud out-of-the-box. It shows information about your
+builds and those initiated by your team members using the same builder,
+enabling collaborative troubleshooting.
+
+To use Docker Build Cloud without Docker Desktop, you must
+[download and install](/build-cloud/setup/#use-docker-build-cloud-without-docker-desktop)
+a version of Buildx with support for Docker Build Cloud (the `cloud` driver).
+If you plan on building with Docker Build Cloud using the `docker compose
+build` command, you also need a version of Docker Compose that supports Docker
+Build Cloud.
+
+#### How does Docker Build Cloud work with Docker Compose?
+
+Docker Compose works out of the box with Docker Build Cloud. Install the Docker
+Build Cloud-compatible client (buildx) and it works with both commands.
+
+#### How many minutes are included in Docker Build Cloud Team plans?
+
+Pricing details for Docker Build Cloud can be found on the [pricing page](https://www.docker.com/pricing?ref=Docs&refAction=DocsGuidesBuildCloudFaq).
+
+#### I’m a Docker personal user. Can I try Docker Build Cloud?
+
+Docker subscribers (Pro, Team, Business) receive a set number of minutes each
+month, shared across the account, to use Build Cloud.
+
+If you do not have a Docker subscription, you may sign up for a free Personal
+account and start a trial of Docker Build Cloud. Personal accounts are limited to a
+single user.
+
+For teams to receive the shared cache benefit, they must either be on a Docker
+Team or Docker Business subscription.
+
+#### Does Docker Build Cloud support CI platforms? Does it work with GitHub Actions?
+
+Yes, Docker Build Cloud can be used with various CI platforms including GitHub
+Actions, CircleCI, Jenkins, and others. It can speed up your build pipelines,
+which means less time spent waiting and context switching.
+
+Docker Build Cloud can be used with GitHub Actions to automate your build,
+test, and deployment pipeline. Docker provides a set of official GitHub Actions
+that you can use in your workflows.
+
+Using GitHub Actions with Docker Build Cloud is straightforward. With a
+one-line change in your GitHub Actions configuration, everything else stays the
+same. You don't need to create new pipelines. Learn more in the [CI
+documentation](/build-cloud/ci/) for Docker Build Cloud.
+
+<div id="dbc-lp-survey-anchor"></div>
diff --git a/content/guides/docker-build-cloud/_index.md b/content/guides/docker-build-cloud/_index.md
deleted file mode 100644
index 9d5aae132e96..000000000000
--- a/content/guides/docker-build-cloud/_index.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: "Docker Build Cloud: Reclaim your time with fast, multi-architecture builds"
-linkTitle: Docker Build Cloud
-description: |
-  Learn how to build and deploy Docker images to the cloud with Docker Build
-  Cloud.
-summary: |
-  Build applications up to 39x faster using cloud-based resources, shared team
-  cache, and native multi-architecture support.
-tags: [product-demo]
-aliases:
-  - /learning-paths/docker-build-cloud/
-params:
-  featured: true
-  image: images/learning-paths/build-cloud.png
-  time: 10 minutes
-  resource_links:
-    - title: Product page
-      url: https://www.docker.com/products/build-cloud/
-    - title: Docker Build Cloud overview
-      url: /build-cloud/
-    - title: Subscriptions and features
-      url: /subscription/details/
-    - title: Using Docker Build Cloud
-      url: /build-cloud/usage/
----
-
-<!-- vale Vale.Spelling = NO -->
-
-98% of developers spend up to an hour every day waiting for builds to finish
-([Incredibuild: 2022 Big Dev Build Times](https://www.incredibuild.com/survey-report-2022)).
-Heavy, complex builds can become a major roadblock for development teams,
-slowing down both local development and CI/CD pipelines.
-
-<!-- vale Vale.Spelling = YES -->
-
-Docker Build Cloud speeds up image build times to improve developer
-productivity, reduce frustrations, and help you shorten the release cycle.
-
-## Who’s this for?
-
-- Anyone who wants to tackle common causes of slow image builds: limited local
-  resources, slow emulation, and lack of build collaboration across a team.
-- Developers working on older machines who want to build faster.
-- Development teams working on the same repository who want to cut wait times
-  with a shared cache.
-- Developers performing multi-architecture builds who don’t want to spend hours
-  configuring and rebuilding for emulators.
-
-## What you’ll learn
-
-- Building container images faster locally and in CI
-- Accelerating builds for multi-platform images
-- Reusing pre-built images to expedite workflows
-
-## Tools integration
-
-Works well with Docker Compose, GitHub Actions, and other CI solutions
-
-<div id="dbc-lp-survey-anchor"></div>
diff --git a/content/guides/docker-build-cloud/ci.md b/content/guides/docker-build-cloud/ci.md
deleted file mode 100644
index 37aa6afc608f..000000000000
--- a/content/guides/docker-build-cloud/ci.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: "Demo: Using Docker Build Cloud in CI"
-description: Learn how to use Docker Build Cloud to build your app faster in CI.
-weight: 30
----
-
-Docker Build Cloud can significantly decrease the time it takes for your CI builds
-take to run, saving you time and money. 
-
-Since the builds run remotely, your CI runner can still use the Docker tooling CLI
-without needing elevated permissions, making your builds more secure by default.
-
-In this demo, you will see:
-
-- How to integrate Docker Build Cloud into a variety of CI platforms
-- How to use Docker Build Cloud in GitHub Actions to build multi-architecture images
-- Speed differences between a workflow using Docker Build Cloud and a workflow running natively
-- How to use Docker Build Cloud in a GitLab Pipeline
-
-{{< youtube-embed "wvLdInoVBGg" >}}
-
-<div id="dbc-lp-survey-anchor"></div>
diff --git a/content/guides/docker-build-cloud/common-questions.md b/content/guides/docker-build-cloud/common-questions.md
deleted file mode 100644
index c397987620bb..000000000000
--- a/content/guides/docker-build-cloud/common-questions.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Common challenges and questions
-description: Explore common challenges and questions related to Docker Build Cloud.
-weight: 40
----
-
-### Is Docker Build Cloud a standalone product or a part of Docker Desktop?
-
-Docker Build Cloud is a service that can be used both with Docker Desktop and
-standalone. It lets you build your container images faster, both locally and in
-CI, with builds running on cloud infrastructure. The service uses a remote
-build cache, ensuring fast builds anywhere and for all team members.
-
-When used with Docker Desktop, the [Builds view](/desktop/use-desktop/builds/)
-works with Docker Build Cloud out-of-the-box. It shows information about your
-builds and those initiated by your team members using the same builder,
-enabling collaborative troubleshooting.
-
-To use Docker Build Cloud without Docker Desktop, you must
-[download and install](/build-cloud/setup/#use-docker-build-cloud-without-docker-desktop)
-a version of Buildx with support for Docker Build Cloud (the `cloud` driver).
-If you plan on building with Docker Build Cloud using the `docker compose
-build` command, you also need a version of Docker Compose that supports Docker
-Build Cloud.
-
-### How does Docker Build Cloud work with Docker Compose?
-
-Docker Compose works out of the box with Docker Build Cloud. Install the Docker
-Build Cloud-compatible client (buildx) and it works with both commands.
-
-### How many minutes are included in Docker Build Cloud Team plans?
-
-Pricing details for Docker Build Cloud can be found on the [pricing page](https://www.docker.com/pricing/).
-
-### I’m a Docker personal user. Can I try Docker Build Cloud?
-
-Docker subscribers (Pro, Team, Business) receive a set number of minutes each
-month, shared across the account, to use Build Cloud.
-
-If you do not have a Docker subscription, you may sign up for a free Personal
-account and start a trial of Docker Build Cloud. Personal accounts are limited to a
-single user.
-
-For teams to receive the shared cache benefit, they must either be on a Docker
-Team or Docker Business plan.
-
-### Does Docker Build Cloud support CI platforms? Does it work with GitHub Actions?
-
-Yes, Docker Build Cloud can be used with various CI platforms including GitHub
-Actions, CircleCI, Jenkins, and others. It can speed up your build pipelines,
-which means less time spent waiting and context switching.
-
-Docker Build Cloud can be used with GitHub Actions to automate your build,
-test, and deployment pipeline. Docker provides a set of official GitHub Actions
-that you can use in your workflows.
-
-Using GitHub Actions with Docker Build Cloud is straightforward. With a
-one-line change in your GitHub Actions configuration, everything else stays the
-same. You don't need to create new pipelines. Learn more in the [CI
-documentation](/build-cloud/ci/) for Docker Build Cloud.
-
-<div id="dbc-lp-survey-anchor"></div>
diff --git a/content/guides/docker-build-cloud/dev.md b/content/guides/docker-build-cloud/dev.md
deleted file mode 100644
index 6cf1e53f943f..000000000000
--- a/content/guides/docker-build-cloud/dev.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: "Demo: set up and use Docker Build Cloud in development"
-description: Learn how to use Docker Build Cloud for local builds.
-weight: 20
----
-
-With Docker Build Cloud, you can easily shift the build workload from local machines
-to the cloud, helping you achieve faster build times, especially for multi-platform builds.
-
-In this demo, you'll see:
-
-- How to setup the builder locally
-- How to use Docker Build Cloud with Docker Compose
-- How the image cache speeds up builds for others on your team
-
-{{< youtube-embed "oPGq2AP5OtQ" >}}
-
-<div id="dbc-lp-survey-anchor"></div>
diff --git a/content/guides/docker-build-cloud/why.md b/content/guides/docker-build-cloud/why.md
deleted file mode 100644
index a7f41dc2eabb..000000000000
--- a/content/guides/docker-build-cloud/why.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Why Docker Build Cloud?
-description: Learn how Docker Build Cloud makes your builds faster.
-weight: 10
----
-
-Docker Build Cloud is a service that lets you build container images faster,
-both locally and in CI. Builds run on cloud infrastructure optimally
-dimensioned for your workloads, with no configuration required. The service
-uses a remote build cache, ensuring fast builds anywhere and for all team
-members.
-
-Docker Build Cloud provides several benefits over local builds:
-
-- Improved build speed
-- Shared build cache
-- Native multi-platform builds
-
-There’s no need to worry about managing builders or infrastructure — simply
-connect to your builders and start building. Each cloud builder provisioned to
-an organization is completely isolated to a single Amazon EC2 instance, with a
-dedicated EBS volume for build cache and encryption in transit. That means
-there are no shared processes or data between cloud builders.
-
-{{< youtube-embed "8AqKhEO2PQA" >}}
-
-<div id="dbc-lp-survey-anchor"></div>
diff --git a/content/guides/docker-compose.md b/content/guides/docker-compose.md
new file mode 100644
index 000000000000..c0d330db034e
--- /dev/null
+++ b/content/guides/docker-compose.md
@@ -0,0 +1,160 @@
+---
+title: Defining and running multi-container applications with Docker Compose
+linkTitle: Docker Compose
+summary: |
+  Simplify the process of defining, configuring, and running multi-container
+  Docker applications.
+description: Learn how to use Docker Compose to define and run multi-container Docker applications.
+keywords: docker compose, multi-container, compose file, services, orchestration, yaml
+aliases:
+  - /learning-paths/docker-compose/
+  - /guides/docker-compose/common-questions/
+  - /guides/docker-compose/setup/
+  - /guides/docker-compose/why/
+params:
+  tags: [cicd]
+  image: images/learning-paths/compose.png
+  time: 10 minutes
+---
+
+
+Developers face challenges with multi-container Docker applications, including
+complex configuration, dependency management, and maintaining consistent
+environments. Networking, resource allocation, data persistence, logging, and
+monitoring add to the difficulty. Security concerns and troubleshooting issues
+further complicate the process, requiring effective tools and practices for
+efficient management.
+
+Docker Compose solves the problem of managing multi-container Docker
+applications by providing a simple way to define, configure, and run all the
+containers needed for an application using a single YAML file. This approach
+helps developers to easily set up, share, and maintain consistent development,
+testing, and production environments, ensuring that complex applications can be
+deployed with all their dependencies and services properly configured and
+orchestrated.
+
+## What you’ll learn
+
+- What Docker Compose is and what it does
+- How to define services
+- Use cases for Docker Compose
+- How things would be different without Docker Compose
+
+## Who’s this for?
+
+- Developers and DevOps engineers who need to define, manage, and orchestrate
+  multi-container Docker applications efficiently across multiple environments.
+- Development teams that want to increase productivity by streamlining
+  development workflows and reducing setup time.
+
+## Tools integration
+
+Works well with Docker CLI, CI/CD tools, and container orchestration tools.
+
+<div id="compose-lp-survey-anchor"></div>
+
+## Why Docker Compose?
+
+Docker Compose is an essential tool for defining and running multi-container
+Docker applications. Docker Compose simplifies the Docker experience, making it
+easier for developers to create, manage, and deploy applications by using YAML
+files to configure application services.
+
+Docker Compose provides several benefits:
+
+- Lets you define multi-container applications in a single YAML file.
+- Ensures consistent environments across development, testing, and production.
+- Manages the startup and linking of multiple containers effortlessly.
+- Streamlines development workflows and reduces setup time.
+- Ensures that each service runs in its own container, avoiding conflicts.
+
+{{< youtube-embed 2EqarOM2V4U >}}
+
+<div id="compose-lp-survey-anchor"></div>
+
+## Demo: set up and use Docker Compose
+
+This Docker Compose demo shows how to orchestrate a multi-container application
+environment, streamlining development and deployment processes.
+
+- Compare Docker Compose to the `docker run` command
+- Configure a multi-container web app using a Compose file
+- Run a multi-container web app using one command
+
+{{< youtube-embed P5RBKmOLPH4 >}}
+
+<div id="compose-lp-survey-anchor"></div>
+
+## Common challenges and questions
+
+<!-- vale Docker.HeadingLength = NO -->
+
+#### Do I need to maintain a separate Compose file for my development, testing, and staging environments?
+
+You don't necessarily need to maintain entirely separate Compose files for your
+development, testing, and staging environments. You can define all your
+services in a single Compose file (`compose.yaml`). You can use profiles to
+group service configurations specific to each environment (`dev`, `test`,
+`staging`).
+
+When you need to spin up an environment, you can activate the corresponding
+profiles. For example, to set up the development environment:
+
+```console
+$ docker compose --profile dev up
+```
+
+This command starts only the services associated with the `dev` profile,
+leaving the rest inactive.
+
+For more information on using profiles, see [Using profiles with
+Compose](/compose/how-tos/profiles/).
+
+#### How can I enforce the database service to start up before the frontend service?
+
+Docker Compose ensures services start in a specific order by using the
+`depends_on` property. This tells Compose to start the database service before
+even attempting to launch the frontend service. This is crucial since
+applications often rely on databases being ready for connections.
+
+However, `depends_on` only guarantees the order, not that the database is fully
+initialized. For a more robust approach, especially if your application relies
+on a prepared database (e.g., after migrations), consider [health
+checks](/reference/compose-file/services.md#healthcheck). Here, you can
+configure the frontend to wait until the database passes its health check
+before starting. This ensures the database is not only up but also ready to
+handle requests.
+
+For more information on setting the startup order of your services, see
+[Control startup and shutdown order in Compose](/compose/how-tos/startup-order/).
+
+#### Can I use Compose to build a Docker image?
+
+Yes, you can use Docker Compose to build Docker images. Docker Compose is a
+tool for defining and running multi-container applications. Even if your
+application isn't a multi-container application, Docker Compose can make it
+easier to run by defining all the `docker run` options in a file.
+
+To use Compose, you need a `compose.yaml` file. In this file, you can specify
+the build context and Dockerfile for each service. When you run the command
+`docker compose up --build`, Docker Compose will build the images for each
+service and then start the containers.
+
+For more information on building Docker images using Compose, see the [Compose
+Build Specification](/compose/compose-file/build/).
+
+#### What is the difference between Docker Compose and Dockerfile?
+
+A Dockerfile provides instructions to build a container image while a Compose
+file defines your running containers. Quite often, a Compose file references a
+Dockerfile to build an image to use for a particular service.
+
+#### What is the difference between the `docker compose up` and `docker compose run` commands?
+
+The `docker compose up` command creates and starts all your services. It's
+perfect for launching your development environment or running the entire
+application. The `docker compose run` command focuses on individual services.
+It starts a specified service along with its dependencies, allowing you to run
+tests or perform one-off tasks within that container.
+
+<div id="compose-lp-survey-anchor"></div>
diff --git a/content/guides/docker-compose/_index.md b/content/guides/docker-compose/_index.md
deleted file mode 100644
index 2763f12c4310..000000000000
--- a/content/guides/docker-compose/_index.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Defining and running multi-container applications with Docker Compose
-linkTitle: Docker Compose
-summary: |
-  Simplify the process of defining, configuring, and running multi-container
-  Docker applications.
-description: Learn how to use Docker Compose to define and run multi-container Docker applications.
-tags: [product-demo]
-aliases:
-  - /learning-paths/docker-compose/
-params:
-  image: images/learning-paths/compose.png
-  time: 10 minutes
-  resource_links:
-    - title: Overview of Docker Compose CLI
-      url: /compose/reference/
-    - title: Overview of Docker Compose
-      url: /compose/
-    - title: How Compose works
-      url: /compose/intro/compose-application-model/
-    - title: Using profiles with Compose
-      url: /compose/how-tos/profiles/
-    - title: Control startup and shutdown order with Compose
-      url: /compose/how-tos/startup-order/
-    - title: Compose Build Specification
-      url: /compose/compose-file/build/
----
-
-Developers face challenges with multi-container Docker applications, including
-complex configuration, dependency management, and maintaining consistent
-environments. Networking, resource allocation, data persistence, logging, and
-monitoring add to the difficulty. Security concerns and troubleshooting issues
-further complicate the process, requiring effective tools and practices for
-efficient management.
-
-Docker Compose solves the problem of managing multi-container Docker
-applications by providing a simple way to define, configure, and run all the
-containers needed for an application using a single YAML file. This approach
-helps developers to easily set up, share, and maintain consistent development,
-testing, and production environments, ensuring that complex applications can be
-deployed with all their dependencies and services properly configured and
-orchestrated.
-
-## What you’ll learn
-
-- What Docker Compose is and what it does
-- How to define services
-- Use cases for Docker Compose
-- How things would be different without Docker Compose
-
-## Who’s this for?
-
-- Developers and DevOps engineers who need to define, manage, and orchestrate
-  multi-container Docker applications efficiently across multiple environments.
-- Development teams that want to increase productivity by streamlining
-  development workflows and reducing setup time.
-
-## Tools integration
-
-Works well with Docker CLI, CI/CD tools, and container orchestration tools.
-
-<div id="compose-lp-survey-anchor"></div>
diff --git a/content/guides/docker-compose/common-questions.md b/content/guides/docker-compose/common-questions.md
deleted file mode 100644
index 64b6320929a1..000000000000
--- a/content/guides/docker-compose/common-questions.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: Common challenges and questions
-description: Explore common challenges and questions related to Docker Compose.
-weight: 30
----
-
-<!-- vale Docker.HeadingLength = NO -->
-
-### Do I need to maintain a separate Compose file for my development, testing, and staging environments?
-
-You don't necessarily need to maintain entirely separate Compose files for your
-development, testing, and staging environments. You can define all your
-services in a single Compose file (`compose.yaml`). You can use profiles to
-group service configurations specific to each environment (`dev`, `test`,
-`staging`).
-
-When you need to spin up an environment, you can activate the corresponding
-profiles. For example, to set up the development environment:
-
-```console
-$ docker compose --profile dev up
-```
-
-This command starts only the services associated with the `dev` profile,
-leaving the rest inactive.
-
-For more information on using profiles, see [Using profiles with
-Compose](/compose/how-tos/profiles/).
-
-### How can I enforce the database service to start up before the frontend service?
-
-Docker Compose ensures services start in a specific order by using the
-`depends_on` property. This tells Compose to start the database service before
-even attempting to launch the frontend service. This is crucial since
-applications often rely on databases being ready for connections.
-
-However, `depends_on` only guarantees the order, not that the database is fully
-initialized. For a more robust approach, especially if your application relies
-on a prepared database (e.g., after migrations), consider [health
-checks](/reference/compose-file/services.md#healthcheck). Here, you can
-configure the frontend to wait until the database passes its health check
-before starting. This ensures the database is not only up but also ready to
-handle requests.
-
-For more information on setting the startup order of your services, see
-[Control startup and shutdown order in Compose](/compose/how-tos/startup-order/).
-
-### Can I use Compose to build a Docker image?
-
-Yes, you can use Docker Compose to build Docker images. Docker Compose is a
-tool for defining and running multi-container applications. Even if your
-application isn't a multi-container application, Docker Compose can make it
-easier to run by defining all the `docker run` options in a file.
-
-To use Compose, you need a `compose.yaml` file. In this file, you can specify
-the build context and Dockerfile for each service. When you run the command
-`docker compose up --build`, Docker Compose will build the images for each
-service and then start the containers.
-
-For more information on building Docker images using Compose, see the [Compose
-Build Specification](/compose/compose-file/build/).
-
-### What is the difference between Docker Compose and Dockerfile?
-
-A Dockerfile provides instructions to build a container image while a Compose
-file defines your running containers. Quite often, a Compose file references a
-Dockerfile to build an image to use for a particular service.
-
-### What is the difference between the `docker compose up` and `docker compose run` commands?
-
-The `docker compose up` command creates and starts all your services. It's
-perfect for launching your development environment or running the entire
-application. The `docker compose run` command focuses on individual services.
-It starts a specified service along with its dependencies, allowing you to run
-tests or perform one-off tasks within that container.
-
-<div id="compose-lp-survey-anchor"></div>
diff --git a/content/guides/docker-compose/setup.md b/content/guides/docker-compose/setup.md
deleted file mode 100644
index 0481cd84b251..000000000000
--- a/content/guides/docker-compose/setup.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: "Demo: set up and use Docker Compose"
-description: Learn how to get started with Docker Compose.
-weight: 20
----
-
-This Docker Compose demo shows how to orchestrate a multi-container application
-environment, streamlining development and deployment processes.
-
-- Compare Docker Compose to the `docker run` command
-- Configure a multi-container web app using a Compose file
-- Run a multi-container web app using one command
-
-{{< youtube-embed P5RBKmOLPH4 >}}
-
-<div id="compose-lp-survey-anchor"></div>
diff --git a/content/guides/docker-compose/why.md b/content/guides/docker-compose/why.md
deleted file mode 100644
index a89b667bfacd..000000000000
--- a/content/guides/docker-compose/why.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Why Docker Compose?
-description: Learn how Docker Compose can help you simplify app development.
-weight: 10
----
-
-Docker Compose is an essential tool for defining and running multi-container
-Docker applications. Docker Compose simplifies the Docker experience, making it
-easier for developers to create, manage, and deploy applications by using YAML
-files to configure application services.
-
-Docker Compose provides several benefits:
-
-- Lets you define multi-container applications in a single YAML file.
-- Ensures consistent environments across development, testing, and production.
-- Manages the startup and linking of multiple containers effortlessly.
-- Streamlines development workflows and reduces setup time.
-- Ensures that each service runs in its own container, avoiding conflicts.
-
-{{< youtube-embed 2EqarOM2V4U >}}
-
-<div id="compose-lp-survey-anchor"></div>
diff --git a/content/guides/docker-scout.md b/content/guides/docker-scout.md
new file mode 100644
index 000000000000..04fc6a06dba2
--- /dev/null
+++ b/content/guides/docker-scout.md
@@ -0,0 +1,325 @@
+---
+title: Securing your software supply chain with Docker Scout
+linkTitle: Docker Scout
+summary: |
+  Enhance container security by automating vulnerability detection and
+  remediation.
+description: |
+  Learn how to use Docker Scout to enhance container security by automating
+  vulnerability detection and remediation, ensuring compliance, and protecting
+  your development workflow.
+keywords: docker scout, container security, vulnerability scanning, sbom, supply chain, remediation
+aliases:
+  - /learning-paths/docker-scout/
+  - /scout/concepts/s3c/
+  - /scout/concepts/sbom/
+  - /guides/docker-scout/attestations/
+  - /guides/docker-scout/common-questions/
+  - /guides/docker-scout/demo/
+  - /guides/docker-scout/remediation/
+  - /guides/docker-scout/s3c/
+  - /guides/docker-scout/sbom/
+  - /guides/docker-scout/why/
+params:
+  tags: [security]
+  image: images/learning-paths/scout.png
+  time: 20 minutes
+---
+
+
+When container images are insecure, significant risks can arise. Around 60% of
+organizations have reported experiencing at least one security breach or
+vulnerability incident within a year, [resulting in operational
+disruption][CSA]. These incidents often result in considerable downtime, with
+44% of affected companies experiencing over an hour of downtime per event. The
+financial impact is substantial, with [the average data breach cost reaching
+$4.45 million][IBM]. This highlights the critical importance of maintaining
+robust container security measures.
+
+Docker Scout enhances container security by providing automated vulnerability
+detection and remediation, addressing insecure container images, and ensuring
+compliance with security standards.
+
+[CSA]: https://cloudsecurityalliance.org/blog/2023/09/21/2023-global-cloud-threat-report-cloud-attacks-are-lightning-fast
+[IBM]: https://www.ibm.com/reports/data-breach
+
+## What you'll learn
+
+- Define Secure Software Supply Chain (SSSC)
+- Review SBOMs and how to use them
+- Detect and monitor vulnerabilities
+
+## Tools integration
+
+Works well with Docker Desktop, GitHub Actions, Jenkins, Kubernetes, and
+other CI solutions.
+
+## Who’s this for?
+
+- DevOps engineers who need to integrate automated security checks into CI/CD
+  pipelines to enhance the security and efficiency of their workflows.
+- Developers who want to use Docker Scout to identify and remediate
+  vulnerabilities early in the development process, ensuring the production of
+  secure container images.
+- Security professionals who must enforce security compliance, conduct
+  vulnerability assessments, and ensure the overall security of containerized
+  applications.
+
+<div id="scout-lp-survey-anchor"></div>
+
+## Why Docker Scout?
+
+{{< youtube-embed "-omsQ7Uqyc4" >}}
+
+Organizations face significant challenges from data breaches,
+including financial losses, operational disruptions, and long-term damage to
+brand reputation and customer trust. Docker Scout addresses critical problems
+such as identifying insecure container images, preventing security breaches,
+and reducing the risk of operational downtime due to vulnerabilities.
+
+Docker Scout provides several benefits:
+
+- Secure and trusted content
+- A system of record for your Software Development Lifecycle (SDLC)
+- Continuous security posture improvement
+
+Docker Scout offers automated vulnerability detection and remediation, helping
+organizations identify and fix security issues in container images early in the
+development process. It also integrates with popular development tools like
+Docker Desktop and GitHub Actions, providing seamless security management and
+compliance checks within existing workflows.
+
+<div id="scout-lp-survey-anchor"></div>
+
+## Docker Scout demo
+
+{{< youtube-embed "TkLwJ0p46W8" >}}
+
+Docker Scout has powerful features for enhancing containerized application
+security and ensuring a robust software supply chain.
+
+- Define vulnerability remediation
+- Discuss why remediation is essential to maintain the security and integrity
+  of containerized applications
+- Discuss common vulnerabilities
+- Implement remediation techniques: updating base images, applying patches,
+  removing unnecessary packages
+- Verify and validate remediation efforts using Docker Scout
+
+<div id="scout-lp-survey-anchor"></div>
+
+## Software supply chain security
+
+{{< youtube-embed YzNK6E7APv0 >}}
+
+The term "software supply chain" refers to the end-to-end process of developing
+and delivering software, from the development to deployment and maintenance.
+Software supply chain security, or "S3C" for short, is the practice for
+protecting the components and processes of the supply chain.
+
+S3C is a fundamental change in how organizations approach software security.
+Traditionally in the software industry, security and compliance has been mostly
+an afterthought, left to the software delivery or release phase. With S3C,
+security is integrated into the entire software development lifecycle, from the
+inner loop of development and testing, to the outer loop of shipping and
+monitoring.
+
+Following industry best practices for software supply chain conduct is
+important because it helps organizations protect their software from security
+threats, compliance risks, and other vulnerabilities. Implementing a software
+supply chain security framework improves visibility, collaboration, and
+traceability of a project across stakeholders. This helps organizations detect,
+respond to, and remediate threats more effectively.
+
+### Securing the software supply chain
+
+Building a secure software supply chain involves several key steps, such as:
+
+- Identify the software components and dependencies you use to build and run
+  your applications.
+- Automate security testing throughout the software development lifecycle.
+- Monitor your software supply chain for security threats.
+- Implement security policies that govern how software is built, and the
+  components it contains.
+
+Managing the software supply chain is a complex task, especially in the modern
+day where software is built using multiple components from different sources.
+Organizations need to have a clear understanding of the software components
+they use, and the security risks associated with them.
+
+### How Docker Scout is different
+
+Docker Scout is a platform designed to help organizations secure their software
+supply chain. It provides tools and services for identifying and managing
+software assets and policies, and automated remediation of security threats.
+
+Unlike traditional security tools that focus on scheduled, point-in-time scans
+at specific stages in the software development lifecycle, Docker Scout uses a
+modern event-driven model that spans the entire software supply chain. This
+means that when a new vulnerability affecting your images is disclosed, your
+updated risk assessment is available within seconds, and earlier in the
+development process.
+
+Docker Scout works by analyzing the composition of your images to create a
+Software Bill of Materials (SBOM). The SBOM is cross-referenced against the
+security advisories to identify CVEs that affect your images. Docker Scout
+integrates with [over 20 different security
+advisories](/manuals/scout/deep-dive/advisory-db-sources.md), and updates its
+vulnerability database in real-time. This ensures that your security posture is
+represented using the latest available information.
+
+<div id="scout-lp-survey-anchor"></div>
+
+## Software Bill of Materials
+
+{{< youtube-embed PbS4y7C7h4A >}}
+
+A Bill of Materials (BOM) is a list of materials, parts, and the quantities of
+each needed to manufacture a product. For example, a BOM for a computer might
+list the motherboard, CPU, RAM, power supply, storage devices, case, and other
+components, along with the quantities of each that are needed to build the
+computer.
+
+A Software Bill of Materials (SBOM) is a list of all the components that make
+up a piece of software. This includes open source and third-party components,
+as well as any custom code that has been written for the software. An SBOM is
+similar to a BOM for a physical product, but for software.
+
+In the context of software supply chain security, SBOMs can help with
+identifying and mitigating security and compliance risks in software. By
+knowing exactly what components are used in a piece of software, you can
+quickly identify and patch vulnerabilities in your components, or determine if
+a component is licensed in a way that is incompatible with your project.
+
+### Contents of an SBOM
+
+An SBOM typically includes the following information:
+
+- The name of the software, such as the name of a library or framework, that
+  the SBOM describes.
+- The version of the software.
+- The license under which the software is distributed.
+- A list of other components that the software depends on.
+
+### How Docker Scout uses SBOMs
+
+Docker Scout uses SBOMs to determine the components that are used in a Docker
+image. When you analyze an image, Docker Scout will either use the SBOM that is
+attached to the image as an attestation, or it will generate an SBOM on the fly
+by analyzing the contents of the image.
+
+The SBOM is cross-referenced with the [advisory database](/manuals/scout/deep-dive/advisory-db-sources.md)
+to determine if any of the components in the image have known vulnerabilities.
+
+<div id="scout-lp-survey-anchor"></div>
+
+## Attestations
+
+{{< youtube-embed qOzcycbTs4o >}}
+
+[Build attestations](/manuals/build/metadata/attestations/_index.md) give you
+detailed information about how an image was built and what it contains. These
+attestations, generated by BuildKit during build-time, attach to the final
+image as metadata, allowing you to inspect an image to see its origin, creator,
+and contents. This information helps you make informed decisions about the
+security and impact of the image on your supply chain.
+
+Docker Scout uses these attestations to evaluate the image's security and
+supply chain posture, and to provide remediation recommendations for issues. If
+issues are detected, such as missing or outdated attestations, Docker Scout can
+guide you on how to add or update them, ensuring compliance and improving
+visibility into the image's security status.
+
+There are two key types of attestations:
+
+- SBOM, which lists the software artifacts within the image.
+- Provenance, which details how the image was built.
+
+You can create attestations by using `docker buildx build` with the
+`--provenance` and `--sbom` flags. Attestations attach to the image index,
+allowing you to inspect them without pulling the entire image. Docker Scout
+leverages this metadata to give you more precise recommendations and better
+control over your image's security.
+
+<div id="scout-lp-survey-anchor"></div>
+
+## Remediation
+
+{{< youtube-embed jM9zLBf8M-8 >}}
+
+Docker Scout's [remediation feature](/manuals/scout/policy/dashboard.md)
+helps you address supply chain and security issues by offering tailored
+recommendations based on policy evaluations. These recommendations guide you in
+improving policy compliance or enhancing image metadata, allowing Docker Scout
+to perform more accurate evaluations in the future.
+
+You can use this feature to ensure that your base images are up-to-date and
+that your supply chain attestations are complete. When a violation occurs,
+Docker Scout provides recommended fixes, such as updating your base image or
+adding missing attestations. If there isn’t enough information to determine
+compliance, Docker Scout suggests actions to help resolve the issue.
+
+In the Docker Scout Dashboard, you can view and act on these recommendations by
+reviewing violations or compliance uncertainties. With integrations like
+GitHub, you can even automate updates, directly fixing issues from the
+dashboard.
+
+<div id="scout-lp-survey-anchor"></div>
+
+## Common challenges and questions
+
+<!-- vale Docker.HeadingLength = NO -->
+
+#### How is Docker Scout different from other security tools?
+
+Docker Scout takes a broader approach to container security compared to
+third-party security tools. Third-party security tools, if they offer
+remediation guidance at all, miss the mark on their limited scope of
+application security posture within the software supply chain, and often
+limited guidance when it comes to suggested fixes. Such tools have either
+limitations on runtime monitoring or no runtime protection at all. When they do
+offer runtime monitoring, it’s limited in its adherence to key policies.
+Third-party security tools offer a limited scope of policy evaluation for
+Docker-specific builds. By focusing on the entire software supply chain,
+providing actionable guidance, and offering comprehensive runtime protection
+with strong policy enforcement, Docker Scout goes beyond just identifying
+vulnerabilities in your containers. It helps you build secure applications from
+the ground up.
+
+#### Can I use Docker Scout with external registries other than Docker Hub?
+
+You can use Scout with registries other than Docker Hub. Integrating Docker Scout
+with third-party container registries enables Docker Scout to run image
+analysis on those repositories so that you can get insights into the
+composition of those images even if they aren't hosted on Docker Hub.
+
+The following container registry integrations are available:
+
+- Artifactory
+- Amazon Elastic Container Registry
+- Azure Container Registry
+
+Learn more about configuring Scout with your registries in [Integrating Docker Scout with third-party registries](/scout/integrations/#container-registries).
+
+#### Does Docker Scout CLI come by default with Docker Desktop?
+
+Yes, the Docker Scout CLI plugin comes pre-installed with Docker Desktop.
+
+#### Is it possible to run `docker scout` commands on a Linux system without Docker Desktop?
+
+If you run Docker Engine without Docker Desktop, Docker Scout doesn't come
+pre-installed, but you can [install it as a standalone binary](/scout/install/).
+
+#### How is Docker Scout using an SBOM?
+
+An SBOM, or software bill of materials, is a list of ingredients that make up
+software components. [Docker Scout uses SBOMs](/scout/concepts/sbom/) to
+determine the components that are used in a Docker image. When you analyze an
+image, Docker Scout will either use the SBOM that is attached to the image (as
+an attestation), or generate an SBOM on the fly by analyzing the contents of
+the image.
+
+The SBOM is cross-referenced with the advisory database to determine if any of
+the components in the image have known vulnerabilities.
+
+<div id="scout-lp-survey-anchor"></div>
diff --git a/content/guides/docker-scout/_index.md b/content/guides/docker-scout/_index.md
deleted file mode 100644
index eaa39f527aed..000000000000
--- a/content/guides/docker-scout/_index.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Securing your software supply chain with Docker Scout
-linkTitle: Docker Scout
-summary: |
-  Enhance container security by automating vulnerability detection and
-  remediation.
-description: |
-  Learn how to use Docker Scout to enhance container security by automating
-  vulnerability detection and remediation, ensuring compliance, and protecting
-  your development workflow.
-tags: [product-demo]
-aliases:
-  - /learning-paths/docker-scout/
-params:
-  featured: true
-  image: images/learning-paths/scout.png
-  time: 20 minutes
-  resource_links:
-    - title: Docker Scout overview
-      url: /scout/
-    - title: Docker Scout quickstart
-      url: /scout/quickstart/
-    - title: Install Docker Scout
-      url: /scout/install/
----
-
-When container images are insecure, significant risks can arise. Around 60% of
-organizations have reported experiencing at least one security breach or
-vulnerability incident within a year, [resulting in operational
-disruption][CSA]. These incidents often result in considerable downtime, with
-44% of affected companies experiencing over an hour of downtime per event. The
-financial impact is substantial, with [the average data breach cost reaching
-$4.45 million][IBM]. This highlights the critical importance of maintaining
-robust container security measures.
-
-Docker Scout enhances container security by providing automated vulnerability
-detection and remediation, addressing insecure container images, and ensuring
-compliance with security standards.
-
-[CSA]: https://cloudsecurityalliance.org/blog/2023/09/21/2023-global-cloud-threat-report-cloud-attacks-are-lightning-fast
-[IBM]: https://www.ibm.com/reports/data-breach
-
-## What you'll learn
-
-- Define Secure Software Supply Chain (SSSC)
-- Review SBOMs and how to use them
-- Detect and monitor vulnerabilities
-
-## Tools integration
-
-Works well with Docker Desktop, GitHub Actions, Jenkins, Kubernetes, and
-other CI solutions.
-
-## Who’s this for?
-
-- DevOps engineers who need to integrate automated security checks into CI/CD
-  pipelines to enhance the security and efficiency of their workflows.
-- Developers who want to use Docker Scout to identify and remediate
-  vulnerabilities early in the development process, ensuring the production of
-  secure container images.
-- Security professionals who must enforce security compliance, conduct
-  vulnerability assessments, and ensure the overall security of containerized
-  applications.
-
-<div id="scout-lp-survey-anchor"></div>
diff --git a/content/guides/docker-scout/attestations.md b/content/guides/docker-scout/attestations.md
deleted file mode 100644
index fb060e703363..000000000000
--- a/content/guides/docker-scout/attestations.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Attestations
-keywords: build, attestations, sbom, provenance, metadata
-description: |
-  Introduction to SBOM and provenance attestations with Docker Build,
-  what they are, and why they exist
-weight: 50
----
-
-{{< youtube-embed qOzcycbTs4o >}}
-
-[Build attestations](/manuals/build/metadata/attestations/_index.md) give you
-detailed information about how an image was built and what it contains. These
-attestations, generated by BuildKit during build-time, attach to the final
-image as metadata, allowing you to inspect an image to see its origin, creator,
-and contents. This information helps you make informed decisions about the
-security and impact of the image on your supply chain.
-
-Docker Scout uses these attestations to evaluate the image's security and
-supply chain posture, and to provide remediation recommendations for issues. If
-issues are detected, such as missing or outdated attestations, Docker Scout can
-guide you on how to add or update them, ensuring compliance and improving
-visibility into the image's security status.
-
-There are two key types of attestations:
-
-- SBOM, which lists the software artifacts within the image.
-- Provenance, which details how the image was built.
-
-You can create attestations by using `docker buildx build` with the
-`--provenance` and `--sbom` flags. Attestations attach to the image index,
-allowing you to inspect them without pulling the entire image. Docker Scout
-leverages this metadata to give you more precise recommendations and better
-control over your image's security.
-
-<div id="scout-lp-survey-anchor"></div>
diff --git a/content/guides/docker-scout/common-questions.md b/content/guides/docker-scout/common-questions.md
deleted file mode 100644
index 21537ed80e4c..000000000000
--- a/content/guides/docker-scout/common-questions.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Common challenges and questions
-description: Explore common challenges and questions related to Docker Scout.
----
-
-<!-- vale Docker.HeadingLength = NO -->
-
-### How is Docker Scout different from other security tools?
-
-Docker Scout takes a broader approach to container security compared to
-third-party security tools. Third-party security tools, if they offer
-remediation guidance at all, miss the mark on their limited scope of
-application security posture within the software supply chain, and often
-limited guidance when it comes to suggested fixes. Such tools have either
-limitations on runtime monitoring or no runtime protection at all. When they do
-offer runtime monitoring, it’s limited in its adherence to key policies.
-Third-party security tools offer a limited scope of policy evaluation for
-Docker-specific builds. By focusing on the entire software supply chain,
-providing actionable guidance, and offering comprehensive runtime protection
-with strong policy enforcement, Docker Scout goes beyond just identifying
-vulnerabilities in your containers. It helps you build secure applications from
-the ground up.
-
-### Can I use Docker Scout with external registries other than Docker Hub?
-
-You can use Scout with registries other than Docker Hub. Integrating Docker Scout
-with third-party container registries enables Docker Scout to run image
-analysis on those repositories so that you can get insights into the
-composition of those images even if they aren't hosted on Docker Hub.
-
-The following container registry integrations are available:
-
-- Artifactory
-- Amazon Elastic Container Registry
-- Azure Container Registry
-
-Learn more about configuring Scout with your registries in [Integrating Docker Scout with third-party registries](/scout/integrations/#container-registries).
-
-### Does Docker Scout CLI come by default with Docker Desktop?
-
-Yes, the Docker Scout CLI plugin comes pre-installed with Docker Desktop.
-
-### Is it possible to run `docker scout` commands on a Linux system without Docker Desktop?
-
-If you run Docker Engine without Docker Desktop, Docker Scout doesn't come
-pre-installed, but you can [install it as a standalone binary](/scout/install/).
-
-### How is Docker Scout using an SBOM?
-
-An SBOM, or software bill of materials, is a list of ingredients that make up
-software components. [Docker Scout uses SBOMs](/scout/concepts/sbom/) to
-determine the components that are used in a Docker image. When you analyze an
-image, Docker Scout will either use the SBOM that is attached to the image (as
-an attestation), or generate an SBOM on the fly by analyzing the contents of
-the image.
-
-The SBOM is cross-referenced with the advisory database to determine if any of
-the components in the image have known vulnerabilities.
-
-<div id="scout-lp-survey-anchor"></div>
diff --git a/content/guides/docker-scout/demo.md b/content/guides/docker-scout/demo.md
deleted file mode 100644
index e1d07406698f..000000000000
--- a/content/guides/docker-scout/demo.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Docker Scout demo
-linkTitle: Demo
-description: Learn about Docker Scout's powerful features for enhanced supply chain security.
-weight: 20
----
-
-{{< youtube-embed "TkLwJ0p46W8" >}}
-
-Docker Scout has powerful features for enhancing containerized application
-security and ensuring a robust software supply chain.
-
-- Define vulnerability remediation
-- Discuss why remediation is essential to maintain the security and integrity
-  of containerized applications
-- Discuss common vulnerabilities
-- Implement remediation techniques: updating base images, applying patches,
-  removing unnecessary packages
-- Verify and validate remediation efforts using Docker Scout
-
-<div id="scout-lp-survey-anchor"></div>
diff --git a/content/guides/docker-scout/remediation.md b/content/guides/docker-scout/remediation.md
deleted file mode 100644
index e485c9cd3cf6..000000000000
--- a/content/guides/docker-scout/remediation.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Remediation
-description: Learn how Docker Scout can help you improve your software quality automatically, using remediation
-keywords: scout, supply chain, security, remediation, automation
-weight: 60
----
-
-{{< youtube-embed jM9zLBf8M-8 >}}
-
-Docker Scout's [remediation feature](/manuals/scout/policy/remediation.md)
-helps you address supply chain and security issues by offering tailored
-recommendations based on policy evaluations. These recommendations guide you in
-improving policy compliance or enhancing image metadata, allowing Docker Scout
-to perform more accurate evaluations in the future.
-
-You can use this feature to ensure that your base images are up-to-date and
-that your supply chain attestations are complete. When a violation occurs,
-Docker Scout provides recommended fixes, such as updating your base image or
-adding missing attestations. If there isn’t enough information to determine
-compliance, Docker Scout suggests actions to help resolve the issue.
-
-In the Docker Scout Dashboard, you can view and act on these recommendations by
-reviewing violations or compliance uncertainties. With integrations like
-GitHub, you can even automate updates, directly fixing issues from the
-dashboard.
-
-<div id="scout-lp-survey-anchor"></div>
diff --git a/content/guides/docker-scout/s3c.md b/content/guides/docker-scout/s3c.md
deleted file mode 100644
index df6eac67a7f2..000000000000
--- a/content/guides/docker-scout/s3c.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: Software supply chain security
-description: Learn about software supply chain security (S3C), what it means, and why it is important.
-keywords: docker scout, secure, software, supply, chain, security, sssc, sscs, s3c
-aliases:
-  - /scout/concepts/s3c/
-weight: 30
----
-
-{{< youtube-embed YzNK6E7APv0 >}}
-
-The term "software supply chain" refers to the end-to-end process of developing
-and delivering software, from the development to deployment and maintenance.
-Software supply chain security, or "S3C" for short, is the practice for
-protecting the components and processes of the supply chain.
-
-S3C is a fundamental change in how organizations approach software security.
-Traditionally in the software industry, security and compliance has been mostly
-an afterthought, left to the software delivery or release phase. With S3C,
-security is integrated into the entire software development lifecycle, from the
-inner loop of development and testing, to the outer loop of shipping and
-monitoring.
-
-Following industry best practices for software supply chain conduct is
-important because it helps organizations protect their software from security
-threats, compliance risks, and other vulnerabilities. Implementing a software
-supply chain security framework improves visibility, collaboration, and
-traceability of a project across stakeholders. This helps organizations detect,
-respond to, and remediate threats more effectively.
-
-## Securing the software supply chain
-
-Building a secure software supply chain involves several key steps, such as:
-
-- Identify the software components and dependencies you use to build and run
-  your applications.
-- Automate security testing throughout the software development lifecycle.
-- Monitor your software supply chain for security threats.
-- Implement security policies that govern how software is built, and the
-  components it contains.
-
-Managing the software supply chain is a complex task, especially in the modern
-day where software is built using multiple components from different sources.
-Organizations need to have a clear understanding of the software components
-they use, and the security risks associated with them.
-
-## How Docker Scout is different
-
-Docker Scout is a platform designed to help organizations secure their software
-supply chain. It provides tools and services for identifying and managing
-software assets and policies, and automated remediation of security threats.
-
-Unlike traditional security tools that focus on scheduled, point-in-time scans
-at specific stages in the software development lifecycle, Docker Scout uses a
-modern event-driven model that spans the entire software supply chain. This
-means that when a new vulnerability affecting your images is disclosed, your
-updated risk assessment is available within seconds, and earlier in the
-development process.
-
-Docker Scout works by analyzing the composition of your images to create a
-Software Bill of Materials (SBOM). The SBOM is cross-referenced against the
-security advisories to identify CVEs that affect your images. Docker Scout
-integrates with [over 20 different security
-advisories](/manuals/scout/deep-dive/advisory-db-sources.md), and updates its
-vulnerability database in real-time. This ensures that your security posture is
-represented using the latest available information.
-
-<div id="scout-lp-survey-anchor"></div>
diff --git a/content/guides/docker-scout/sbom.md b/content/guides/docker-scout/sbom.md
deleted file mode 100644
index c7c6e2fa8a3a..000000000000
--- a/content/guides/docker-scout/sbom.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-title: Software Bill of Materials
-description: Learn about Software Bill of Materials (SBOM) and how Docker Scout uses it.
-keywords: scout, sbom, software bill of materials, analysis, composition
-aliases:
-  - /scout/concepts/sbom/
-weight: 40
----
-
-{{< youtube-embed PbS4y7C7h4A >}}
-
-A Bill of Materials (BOM) is a list of materials, parts, and the quantities of
-each needed to manufacture a product. For example, a BOM for a computer might
-list the motherboard, CPU, RAM, power supply, storage devices, case, and other
-components, along with the quantities of each that are needed to build the
-computer.
-
-A Software Bill of Materials (SBOM) is a list of all the components that make
-up a piece of software. This includes open source and third-party components,
-as well as any custom code that has been written for the software. An SBOM is
-similar to a BOM for a physical product, but for software.
-
-In the context of software supply chain security, SBOMs can help with
-identifying and mitigating security and compliance risks in software. By
-knowing exactly what components are used in a piece of software, you can
-quickly identify and patch vulnerabilities in your components, or determine if
-a component is licensed in a way that is incompatible with your project.
-
-## Contents of an SBOM
-
-An SBOM typically includes the following information:
-
-- The name of the software, such as the name of a library or framework, that
-  the SBOM describes.
-- The version of the software.
-- The license under which the software is distributed.
-- A list of other components that the software depends on.
-
-## How Docker Scout uses SBOMs
-
-Docker Scout uses SBOMs to determine the components that are used in a Docker
-image. When you analyze an image, Docker Scout will either use the SBOM that is
-attached to the image as an attestation, or it will generate an SBOM on the fly
-by analyzing the contents of the image.
-
-The SBOM is cross-referenced with the [advisory database](/manuals/scout/deep-dive/advisory-db-sources.md)
-to determine if any of the components in the image have known vulnerabilities.
-
-<div id="scout-lp-survey-anchor"></div>
diff --git a/content/guides/docker-scout/why.md b/content/guides/docker-scout/why.md
deleted file mode 100644
index 3c63052fcb0a..000000000000
--- a/content/guides/docker-scout/why.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Why Docker Scout?
-description: Learn how Docker Scout can help you secure your supply chain.
-weight: 10
----
-
-{{< youtube-embed "-omsQ7Uqyc4" >}}
-
-Organizations face significant challenges from data breaches,
-including financial losses, operational disruptions, and long-term damage to
-brand reputation and customer trust. Docker Scout addresses critical problems
-such as identifying insecure container images, preventing security breaches,
-and reducing the risk of operational downtime due to vulnerabilities.
-
-Docker Scout provides several benefits:
-
-- Secure and trusted content
-- A system of record for your Software Development Lifecycle (SDLC)
-- Continuous security posture improvement
-
-Docker Scout offers automated vulnerability detection and remediation, helping
-organizations identify and fix security issues in container images early in the
-development process. It also integrates with popular development tools like
-Docker Desktop and GitHub Actions, providing seamless security management and
-compliance checks within existing workflows.
-
-<div id="scout-lp-survey-anchor"></div>
diff --git a/content/guides/dotnet.md b/content/guides/dotnet.md
new file mode 100644
index 000000000000..e663e8d8f65a
--- /dev/null
+++ b/content/guides/dotnet.md
@@ -0,0 +1,915 @@
+---
+title: .NET language-specific guide
+linkTitle: C# (.NET)
+description: Containerize and develop .NET apps using Docker
+summary: |
+  Learn how to containerize .NET applications using Docker.
+keywords: getting started, .net
+aliases:
+  - /language/dotnet/
+  - /guides/language/dotnet/
+  - /language/dotnet/develop/
+  - /language/dotnet/run-tests/
+  - /language/dotnet/configure-ci-cd/
+  - /language/dotnet/deploy/
+  - /guides/dotnet/configure-ci-cd/
+  - /guides/dotnet/containerize/
+  - /guides/dotnet/deploy/
+  - /guides/dotnet/develop/
+  - /guides/dotnet/run-tests/
+params:
+  tags: [languages]
+  time: 20 minutes
+  toc_min: 1
+  toc_max: 2
+---
+
+The .NET getting started guide teaches you how to create a containerized .NET application using Docker. In this guide, you'll learn how to:
+
+- Containerize and run a .NET application
+- Set up a local environment to develop a .NET application using containers
+- Run tests for a .NET application using containers
+
+After completing the .NET getting started modules, you should be able to containerize your own .NET application based on the examples and instructions provided in this guide.
+
+Start by containerizing an existing .NET application.
+
+## Containerize a .NET application
+
+### Prerequisites
+
+- You have installed the latest version of [Docker
+  Desktop](/get-started/get-docker.md).
+- You have a [git client](https://git-scm.com/downloads). The examples in this
+  section use a command-line based git client, but you can use any client.
+
+### Overview
+
+This section walks you through containerizing and running a .NET
+application.
+
+### Get the sample applications
+
+In this guide, you will use a pre-built .NET application. The application is
+similar to the application built in the Docker Blog article, [Building a
+Multi-Container .NET App Using Docker
+Desktop](https://www.docker.com/blog/building-multi-container-net-app-using-docker-desktop/).
+
+Open a terminal, change directory to a directory that you want to work in, and
+run the following command to clone the repository.
+
+```console
+$ git clone https://github.com/docker/docker-dotnet-sample
+```
+
+### Create Docker assets
+
+Now that you have an application, you can create the necessary Docker assets to containerize it. You can choose between using the official .NET images or Docker Hardened Images (DHI).
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for your project. Ask Gordon to create a Dockerfile, Compose file, and `.dockerignore` tailored to your application.
+
+> [Docker Hardened Images (DHIs)](https://docs.docker.com/dhi/) are minimal, secure, and production-ready container base and application images maintained by Docker. DHI images are recommended for better security—they are designed to reduce vulnerabilities and simplify compliance.
+
+{{< tabs >}}
+{{< tab name="Using Docker Hardened Images" >}}
+
+Docker Hardened Images (DHIs) for .NET are available in the [Docker Hardened Images catalog](https://hub.docker.com/hardened-images/catalog/dhi/aspnetcore). Docker Hardened Images are freely available to everyone with no subscription required. You can pull and use them like any other Docker image after signing in to the DHI registry. For more information, see the [DHI quickstart](/dhi/get-started/) guide.
+
+1. Sign in to the DHI registry:
+
+   ```console
+   $ docker login dhi.io
+   ```
+
+2. Pull the .NET SDK DHI (check the catalog for available versions):
+
+   ```console
+   $ docker pull dhi.io/dotnet:10-sdk
+   ```
+
+3. Pull the ASP.NET Core runtime DHI (check the catalog for available versions):
+   ```console
+   $ docker pull dhi.io/aspnetcore:10
+   ```
+
+Create the following files in your `docker-dotnet-sample` directory.
+
+```dockerfile {collapse=true,title=Dockerfile}
+# syntax=docker/dockerfile:1
+
+FROM --platform=$BUILDPLATFORM dhi.io/dotnet:10-sdk AS build
+ARG TARGETARCH
+COPY . /source
+WORKDIR /source/src
+RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages \
+    dotnet publish -a ${TARGETARCH/amd64/x64} --use-current-runtime --self-contained false -o /app
+
+FROM dhi.io/aspnetcore:10 AS final
+WORKDIR /app
+COPY --from=build /app .
+ENTRYPOINT ["dotnet", "myWebApp.dll"]
+```
+
+> [!NOTE]
+>
+> DHI runtime images already run as a non-root user (`nonroot`, UID 65532), so there's no need to create a user or specify `USER` in your Dockerfile. This reduces the attack surface and simplifies your configuration.
+
+```yaml {collapse=true,title=compose.yaml}
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Docker Compose reference guide at
+# https://docs.docker.com/go/compose-spec-reference/
+
+# Here the instructions define your application as a service called "server".
+# This service is built from the Dockerfile in the current directory.
+# You can add other services your application may depend on here, such as a
+# database or a cache. For examples, see the Awesome Compose repository:
+# https://github.com/docker/awesome-compose
+services:
+  server:
+    build:
+      context: .
+      target: final
+    ports:
+      - 8080:8080
+
+# The commented out section below is an example of how to define a PostgreSQL
+# database that your application can use. `depends_on` tells Docker Compose to
+# start the database before your application. The `db-data` volume persists the
+# database data between container restarts. The `db-password` secret is used
+# to set the database password. You must create `db/password.txt` and add
+# a password of your choosing to it before running `docker compose up`.
+#     depends_on:
+#       db:
+#         condition: service_healthy
+#   db:
+#     image: postgres
+#     restart: always
+#     user: postgres
+#     secrets:
+#       - db-password
+#     volumes:
+#       - db-data:/var/lib/postgresql/data
+#     environment:
+#       - POSTGRES_DB=example
+#       - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+#     expose:
+#       - 5432
+#     healthcheck:
+#       test: [ "CMD", "pg_isready" ]
+#       interval: 10s
+#       timeout: 5s
+#       retries: 5
+# volumes:
+#   db-data:
+# secrets:
+#   db-password:
+#     file: db/password.txt
+```
+
+```text {collapse=true,title=".dockerignore"}
+# Include any files or directories that you don't want to be copied to your
+# container here (e.g., local build artifacts, temporary files, etc.).
+#
+# For more help, visit the .dockerignore file reference guide at
+# https://docs.docker.com/go/build-context-dockerignore/
+
+**/.classpath
+**/.dockerignore
+**/.env
+**/.git
+**/.gitignore
+**/.project
+**/.settings
+**/.toolstarget
+**/.vs
+**/.vscode
+**/*.*proj.user
+**/*.dbmdl
+**/*.jfm
+**/bin
+**/charts
+**/docker-compose*
+**/compose.y*ml
+**/Dockerfile*
+**/node_modules
+**/npm-debug.log
+**/obj
+**/secrets.dev.yaml
+**/values.dev.yaml
+LICENSE
+README.md
+```
+
+{{< /tab >}}
+{{< tab name="Using the official .NET 10 image" >}}
+
+Create the following files in your `docker-dotnet-sample` directory.
+
+```dockerfile {collapse=true,title=Dockerfile}
+# syntax=docker/dockerfile:1
+
+FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0-alpine AS build
+ARG TARGETARCH
+COPY . /source
+WORKDIR /source/src
+RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages \
+    dotnet publish -a ${TARGETARCH/amd64/x64} --use-current-runtime --self-contained false -o /app
+
+FROM mcr.microsoft.com/dotnet/aspnet:10.0-alpine AS final
+WORKDIR /app
+COPY --from=build /app .
+ARG UID=10001
+RUN adduser \
+    --disabled-password \
+    --gecos "" \
+    --home "/nonexistent" \
+    --shell "/sbin/nologin" \
+    --no-create-home \
+    --uid "${UID}" \
+    appuser
+USER appuser
+ENTRYPOINT ["dotnet", "myWebApp.dll"]
+```
+
+```yaml {collapse=true,title=compose.yaml}
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Docker Compose reference guide at
+# https://docs.docker.com/go/compose-spec-reference/
+
+# Here the instructions define your application as a service called "server".
+# This service is built from the Dockerfile in the current directory.
+# You can add other services your application may depend on here, such as a
+# database or a cache. For examples, see the Awesome Compose repository:
+# https://github.com/docker/awesome-compose
+services:
+  server:
+    build:
+      context: .
+      target: final
+    ports:
+      - 8080:8080
+
+# The commented out section below is an example of how to define a PostgreSQL
+# database that your application can use. `depends_on` tells Docker Compose to
+# start the database before your application. The `db-data` volume persists the
+# database data between container restarts. The `db-password` secret is used
+# to set the database password. You must create `db/password.txt` and add
+# a password of your choosing to it before running `docker compose up`.
+#     depends_on:
+#       db:
+#         condition: service_healthy
+#   db:
+#     image: postgres
+#     restart: always
+#     user: postgres
+#     secrets:
+#       - db-password
+#     volumes:
+#       - db-data:/var/lib/postgresql/data
+#     environment:
+#       - POSTGRES_DB=example
+#       - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+#     expose:
+#       - 5432
+#     healthcheck:
+#       test: [ "CMD", "pg_isready" ]
+#       interval: 10s
+#       timeout: 5s
+#       retries: 5
+# volumes:
+#   db-data:
+# secrets:
+#   db-password:
+#     file: db/password.txt
+```
+
+```text {collapse=true,title=".dockerignore"}
+# Include any files or directories that you don't want to be copied to your
+# container here (e.g., local build artifacts, temporary files, etc.).
+#
+# For more help, visit the .dockerignore file reference guide at
+# https://docs.docker.com/go/build-context-dockerignore/
+
+**/.classpath
+**/.dockerignore
+**/.env
+**/.git
+**/.gitignore
+**/.project
+**/.settings
+**/.toolstarget
+**/.vs
+**/.vscode
+**/*.*proj.user
+**/*.dbmdl
+**/*.jfm
+**/bin
+**/charts
+**/docker-compose*
+**/compose.y*ml
+**/Dockerfile*
+**/node_modules
+**/npm-debug.log
+**/obj
+**/secrets.dev.yaml
+**/values.dev.yaml
+LICENSE
+README.md
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+You should now have the following contents in your `docker-dotnet-sample`
+directory.
+
+```text
+├── docker-dotnet-sample/
+│ ├── .git/
+│ ├── src/
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ ├── Dockerfile
+│ └── README.md
+```
+
+To learn more about the files, see the following:
+
+- [Dockerfile](/reference/dockerfile.md)
+- [.dockerignore](/reference/dockerfile.md#dockerignore-file)
+- [compose.yaml](/reference/compose-file/_index.md)
+
+### Run the application
+
+Inside the `docker-dotnet-sample` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple web application.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `docker-dotnet-sample` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple web application.
+
+In the terminal, run the following command to stop the application.
+
+```console
+$ docker compose down
+```
+
+For more information about Compose commands, see the [Compose CLI
+reference](/reference/cli/docker/compose/).
+
+## Use containers for .NET development
+
+### Prerequisites
+
+Complete [Containerize a .NET application](#containerize-a-net-application).
+
+### Overview
+
+In this section, you'll learn how to set up a development environment for your containerized application. This includes:
+
+- Adding a local database and persisting data
+- Configuring Compose to automatically update your running Compose services as you edit and save your code
+- Creating a development container that contains the .NET Core SDK tools and dependencies
+
+### Update the application
+
+This section uses a different branch of the `docker-dotnet-sample` repository
+that contains an updated .NET application. The updated application is on the
+`add-db` branch of the repository you cloned in [Containerize a .NET
+application](#containerize-a-net-application).
+
+To get the updated code, you need to checkout the `add-db` branch. For the changes you made in [Containerize a .NET application](#containerize-a-net-application), for this section, you can stash them. In a terminal, run the following commands in the `docker-dotnet-sample` directory.
+
+1. Stash any previous changes.
+
+   ```console
+   $ git stash -u
+   ```
+
+2. Check out the new branch with the updated application.
+
+   ```console
+   $ git checkout add-db
+   ```
+
+In the `add-db` branch, only the .NET application has been updated. None of the Docker assets have been updated yet.
+
+You should now have the following in your `docker-dotnet-sample` directory.
+
+```text
+├── docker-dotnet-sample/
+│ ├── .git/
+│ ├── src/
+│ │ ├── Data/
+│ │ ├── Models/
+│ │ ├── Pages/
+│ │ ├── Properties/
+│ │ ├── wwwroot/
+│ │ ├── appsettings.Development.json
+│ │ ├── appsettings.json
+│ │ ├── myWebApp.csproj
+│ │ └── Program.cs
+│ ├── tests/
+│ │ ├── tests.csproj
+│ │ ├── UnitTest1.cs
+│ │ └── Usings.cs
+│ ├── .dockerignore
+│ ├── .gitignore
+│ ├── compose.yaml
+│ ├── Dockerfile
+│ └── README.md
+```
+
+### Add a local database and persist data
+
+You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service and a volume to persist data.
+
+Open the `compose.yaml` file in an IDE or text editor. You'll notice it
+already contains commented-out instructions for a PostgreSQL database and volume.
+
+Open `docker-dotnet-sample/src/appsettings.json` in an IDE or text editor. You'll
+notice the connection string with all the database information. The
+`compose.yaml` already contains this information, but it's commented out.
+Uncomment the database instructions in the `compose.yaml` file.
+
+The following is the updated `compose.yaml` file.
+
+```yaml {hl_lines="8-33"}
+services:
+  server:
+    build:
+      context: .
+      target: final
+    ports:
+      - 8080:8080
+    depends_on:
+      db:
+        condition: service_healthy
+  db:
+    image: postgres:18
+    restart: always
+    user: postgres
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    expose:
+      - 5432
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+> [!NOTE]
+>
+> To learn more about the instructions in the Compose file, see [Compose file
+> reference](/reference/compose-file/).
+
+Before you run the application using Compose, notice that this Compose file uses
+`secrets` and specifies a `password.txt` file to hold the database's password.
+You must create this file as it's not included in the source repository.
+
+In the `docker-dotnet-sample` directory, create a new directory named `db` and
+inside that directory create a file named `password.txt`. Open `password.txt` in an IDE or text editor and add the following password. The password must be on a single line, with no additional lines in the file.
+
+```text
+example
+```
+
+Save and close the `password.txt` file.
+
+You should now have the following in your `docker-dotnet-sample` directory.
+
+```text
+├── docker-dotnet-sample/
+│ ├── .git/
+│ ├── db/
+│ │ └── password.txt
+│ ├── src/
+│ ├── tests/
+│ ├── .dockerignore
+│ ├── .gitignore
+│ ├── compose.yaml
+│ ├── Dockerfile
+│ └── README.md
+```
+
+Run the following command to start your application.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple web application with the text `Student name is`.
+
+The application doesn't display a name because the database is empty. For this application, you need to access the database and then add records.
+
+### Add records to the database
+
+For the sample application, you must access the database directly to create sample records.
+
+You can run commands inside the database container using the `docker exec`
+command. Before running that command, you must get the ID of the database
+container. Open a new terminal window and run the following command to list all
+your running containers.
+
+```console
+$ docker container ls
+```
+
+You should see output like the following.
+
+```console
+CONTAINER ID   IMAGE                         COMMAND                  CREATED              STATUS                        PORTS                    NAMES
+cb36e310aa7e   docker-dotnet-sample-server   "dotnet myWebApp.dll"    About a minute ago   Up About a minute             0.0.0.0:8080->8080/tcp   docker-dotnet-sample-server-1
+39fdcf0aff7b   postgres:18                   "docker-entrypoint.s…"   About a minute ago   Up About a minute (healthy)   5432/tcp                 docker-dotnet-sample-db-1
+```
+
+In the previous example, the container ID is `39fdcf0aff7b`. Run the following command to connect to the postgres database in the container. Replace the container ID with your own container ID.
+
+```console
+$ docker exec -it 39fdcf0aff7b psql -d example -U postgres
+```
+
+And finally, insert a record into the database.
+
+```console
+example=# INSERT INTO "Students" ("ID", "LastName", "FirstMidName", "EnrollmentDate") VALUES (DEFAULT, 'Whale', 'Moby', '2013-03-20');
+```
+
+You should see output like the following.
+
+```console
+INSERT 0 1
+```
+
+Close the database connection and exit the container shell by running `exit`.
+
+```console
+example=# exit
+```
+
+### Verify that data persists in the database
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple web application with the text `Student name is Moby Whale`.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+In the terminal, run `docker compose rm` to remove your containers and then run `docker compose up` to run your application again.
+
+```console
+$ docker compose rm
+$ docker compose up --build
+```
+
+Refresh [http://localhost:8080](http://localhost:8080) in your browser and verify that the student name persisted, even after the containers were removed and ran again.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Automatically update services
+
+Use Compose Watch to automatically update your running Compose services as you edit and save your code. For more details about Compose Watch, see [Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
+
+Open your `compose.yaml` file in an IDE or text editor and then add the Compose Watch instructions. The following is the updated `compose.yaml` file.
+
+```yaml {hl_lines="11-14"}
+services:
+  server:
+    build:
+      context: .
+      target: final
+    ports:
+      - 8080:8080
+    depends_on:
+      db:
+        condition: service_healthy
+    develop:
+      watch:
+        - action: rebuild
+          path: .
+  db:
+    image: postgres:18
+    restart: always
+    user: postgres
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    expose:
+      - 5432
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+Run the following command to run your application with Compose Watch.
+
+```console
+$ docker compose watch
+```
+
+Open a browser and verify that the application is running at [http://localhost:8080](http://localhost:8080).
+
+Any changes to the application's source files on your local machine will now be
+immediately reflected in the running container.
+
+Open `docker-dotnet-sample/src/Pages/Index.cshtml` in an IDE or text editor and update the student name text on line 13 from `Student name is` to `Student name:`.
+
+```diff
+-    <p>Student name is @Model.StudentName</p>
++    <p>Student name: @Model.StudentName</p>
+```
+
+Save the changes to `Index.cshtml` and then wait a few seconds for the application to rebuild. Refresh [http://localhost:8080](http://localhost:8080) in your browser and verify that the updated text appears.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Create a development container
+
+At this point, when you run your containerized application, it's using the .NET runtime image. While this small image is good for production, it lacks the SDK tools and dependencies you may need when developing. Also, during development, you may not need to run `dotnet publish`. You can use multi-stage builds to build stages for both development and production in the same Dockerfile. For more details, see [Multi-stage builds](/manuals/build/building/multi-stage.md).
+
+Add a new development stage to your Dockerfile and update your `compose.yaml` file to use this stage for local development.
+
+The following is the updated Dockerfile.
+
+{{< tabs >}}
+{{< tab name="Using Docker Hardened Images" >}}
+
+```Dockerfile {hl_lines="10-13"}
+# syntax=docker/dockerfile:1
+
+FROM --platform=$BUILDPLATFORM dhi.io/dotnet:10-sdk AS build
+ARG TARGETARCH
+COPY . /source
+WORKDIR /source/src
+RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages \
+    dotnet publish -a ${TARGETARCH/amd64/x64} --use-current-runtime --self-contained false -o /app
+
+FROM dhi.io/dotnet:10-sdk AS development
+COPY . /source
+WORKDIR /source/src
+CMD dotnet run --no-launch-profile
+
+FROM dhi.io/aspnetcore:10 AS final
+WORKDIR /app
+COPY --from=build /app .
+ENTRYPOINT ["dotnet", "myWebApp.dll"]
+```
+
+{{< /tab >}}
+{{< tab name="Using the official .NET 10 image" >}}
+
+```Dockerfile {hl_lines="10-13"}
+# syntax=docker/dockerfile:1
+
+FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0-alpine AS build
+ARG TARGETARCH
+COPY . /source
+WORKDIR /source/src
+RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages \
+    dotnet publish -a ${TARGETARCH/amd64/x64} --use-current-runtime --self-contained false -o /app
+
+FROM mcr.microsoft.com/dotnet/sdk:10.0-alpine AS development
+COPY . /source
+WORKDIR /source/src
+CMD dotnet run --no-launch-profile
+
+FROM mcr.microsoft.com/dotnet/aspnet:10.0-alpine AS final
+WORKDIR /app
+COPY --from=build /app .
+ARG UID=10001
+RUN adduser \
+    --disabled-password \
+    --gecos "" \
+    --home "/nonexistent" \
+    --shell "/sbin/nologin" \
+    --no-create-home \
+    --uid "${UID}" \
+    appuser
+USER appuser
+ENTRYPOINT ["dotnet", "myWebApp.dll"]
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+The following is the updated `compose.yaml` file.
+
+```yaml {hl_lines=[5,15,16]}
+services:
+  server:
+    build:
+      context: .
+      target: development
+    ports:
+      - 8080:8080
+    depends_on:
+      db:
+        condition: service_healthy
+    develop:
+      watch:
+        - action: rebuild
+          path: .
+    environment:
+      - ASPNETCORE_ENVIRONMENT=Development
+  db:
+    image: postgres:18
+    restart: always
+    user: postgres
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    expose:
+      - 5432
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+Your containerized application will now use the SDK image (either `dhi.io/dotnet:10-sdk` for DHI or `mcr.microsoft.com/dotnet/sdk:10.0-alpine` for official images), which includes development tools like `dotnet test`. Continue to the next section to learn how you can run `dotnet test`.
+
+## Run .NET tests in a container
+
+### Prerequisites
+
+Complete all the previous sections of this guide, starting with [Containerize a .NET application](#containerize-a-net-application).
+
+### Overview
+
+Testing is an essential part of modern software development. Testing can mean a
+lot of things to different development teams. There are unit tests, integration
+tests and end-to-end testing. In this guide you take a look at running your unit
+tests in Docker when developing and when building.
+
+### Run tests when developing locally
+
+The sample application already has an xUnit test inside the `tests` directory. When developing locally, you can use Compose to run your tests.
+
+Run the following command in the `docker-dotnet-sample` directory to run the tests inside a container.
+
+```console
+$ docker compose run --build --rm server dotnet test /source/tests
+```
+
+You should see output that contains the following.
+
+```console
+Starting test execution, please wait...
+A total of 1 test files matched the specified pattern.
+
+Passed!  - Failed:     0, Passed:     1, Skipped:     0, Total:     1, Duration: < 1 ms - /source/tests/bin/Debug/net10.0/tests.dll (net10.0)
+```
+
+To learn more about the command, see [docker compose run](/reference/cli/docker/compose/run/).
+
+### Run tests when building
+
+To run your tests when building, you need to update your Dockerfile. You can create a new test stage that runs the tests, or run the tests in the existing build stage. For this guide, update the Dockerfile to run the tests in the build stage.
+
+The following is the updated Dockerfile.
+
+{{< tabs >}}
+{{< tab name="Using Docker Hardened Images" >}}
+
+```dockerfile {hl_lines="9"}
+# syntax=docker/dockerfile:1
+
+FROM --platform=$BUILDPLATFORM dhi.io/dotnet:10-sdk AS build
+ARG TARGETARCH
+COPY . /source
+WORKDIR /source/src
+RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages \
+    dotnet publish -a ${TARGETARCH/amd64/x64} --use-current-runtime --self-contained false -o /app
+RUN dotnet test /source/tests
+
+FROM dhi.io/dotnet:10-sdk AS development
+COPY . /source
+WORKDIR /source/src
+CMD dotnet run --no-launch-profile
+
+FROM dhi.io/aspnetcore:10 AS final
+WORKDIR /app
+COPY --from=build /app .
+ENTRYPOINT ["dotnet", "myWebApp.dll"]
+```
+
+{{< /tab >}}
+{{< tab name="Using the official .NET 10 image" >}}
+
+```dockerfile {hl_lines="9"}
+# syntax=docker/dockerfile:1
+
+FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0-alpine AS build
+ARG TARGETARCH
+COPY . /source
+WORKDIR /source/src
+RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages \
+    dotnet publish -a ${TARGETARCH/amd64/x64} --use-current-runtime --self-contained false -o /app
+RUN dotnet test /source/tests
+
+FROM mcr.microsoft.com/dotnet/sdk:10.0-alpine AS development
+COPY . /source
+WORKDIR /source/src
+CMD dotnet run --no-launch-profile
+
+FROM mcr.microsoft.com/dotnet/aspnet:10.0-alpine AS final
+WORKDIR /app
+COPY --from=build /app .
+ARG UID=10001
+RUN adduser \
+    --disabled-password \
+    --gecos "" \
+    --home "/nonexistent" \
+    --shell "/sbin/nologin" \
+    --no-create-home \
+    --uid "${UID}" \
+    appuser
+USER appuser
+ENTRYPOINT ["dotnet", "myWebApp.dll"]
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Run the following command to build an image using the build stage as the target and view the test results. Include `--progress=plain` to view the build output, `--no-cache` to ensure the tests always run, and `--target build` to target the build stage.
+
+```console
+$ docker build -t dotnet-docker-image-test --progress=plain --no-cache --target build .
+```
+
+You should see output containing the following.
+
+```console
+#11 [build 5/5] RUN dotnet test /source/tests
+#11 1.564   Determining projects to restore...
+#11 3.421   Restored /source/src/myWebApp.csproj (in 1.02 sec).
+#11 19.42   Restored /source/tests/tests.csproj (in 17.05 sec).
+#11 27.91   myWebApp -> /source/src/bin/Debug/net10.0/myWebApp.dll
+#11 28.47   tests -> /source/tests/bin/Debug/net10.0/tests.dll
+#11 28.49 Test run for /source/tests/bin/Debug/net10.0/tests.dll (.NETCoreApp,Version=v10.0)
+#11 28.67 Microsoft (R) Test Execution Command Line Tool Version 17.3.3 (x64)
+#11 28.67 Copyright (c) Microsoft Corporation.  All rights reserved.
+#11 28.68
+#11 28.97 Starting test execution, please wait...
+#11 29.03 A total of 1 test files matched the specified pattern.
+#11 32.07
+#11 32.08 Passed!  - Failed:     0, Passed:     1, Skipped:     0, Total:     1, Duration: < 1 ms - /source/tests/bin/Debug/net10.0/tests.dll (net10.0)
+#11 DONE 32.2s
+```
+
+### Summary
+
+In this section, you learned how to run tests when developing locally using Compose and how to run tests when building your image.
+
+Related information:
+
+- [docker compose run](/reference/cli/docker/compose/run/)
diff --git a/content/guides/dotnet/_index.md b/content/guides/dotnet/_index.md
deleted file mode 100644
index 849c17f2b636..000000000000
--- a/content/guides/dotnet/_index.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: .NET language-specific guide
-linkTitle: C# (.NET)
-description: Containerize and develop .NET apps using Docker
-summary: |
-  Learn how to containerize .NET applications using Docker.
-keywords: getting started, .net
-aliases:
-  - /language/dotnet/
-  - /guides/language/dotnet/
-languages: [c-sharp]
-params:
-  time: 20 minutes
-  toc_min: 1
-  toc_max: 2
----
-
-The .NET getting started guide teaches you how to create a containerized .NET application using Docker. In this guide, you'll learn how to:
-
-- Containerize and run a .NET application
-- Set up a local environment to develop a .NET application using containers
-- Run tests for a .NET application using containers
-- Configure a CI/CD pipeline for a containerized .NET application using GitHub Actions
-- Deploy your containerized application locally to Kubernetes to test and debug your deployment
-
-After completing the .NET getting started modules, you should be able to containerize your own .NET application based on the examples and instructions provided in this guide.
-
-Start by containerizing an existing .NET application.
diff --git a/content/guides/dotnet/configure-ci-cd.md b/content/guides/dotnet/configure-ci-cd.md
deleted file mode 100644
index ec5f7343bb33..000000000000
--- a/content/guides/dotnet/configure-ci-cd.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-title: Configure CI/CD for your .NET application
-linkTitle: Configure CI/CD
-weight: 40
-keywords: .net, CI/CD
-description: Learn how to Configure CI/CD for your .NET application
-aliases:
-  - /language/dotnet/configure-ci-cd/
-  - /guides/language/dotnet/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a .NET application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-## Overview
-
-In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps:
-
-1. Create a new repository on GitHub.
-2. Define the GitHub Actions workflow.
-3. Run the workflow.
-
-## Step one: Create the repository
-
-Create a GitHub repository, configure the Docker Hub credentials, and push your source code.
-
-1. [Create a new repository](https://github.com/new) on GitHub.
-
-2. Open the repository **Settings**, and go to **Secrets and variables** >
-   **Actions**.
-
-3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-4. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-5. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-6. In your local repository on your machine, run the following command to change
-   the origin to the repository you just created. Make sure you change
-   `your-username` to your GitHub username and `your-repository` to the name of
-   the repository you created.
-
-   ```console
-   $ git remote set-url origin https://github.com/your-username/your-repository.git
-   ```
-
-7. In your local repository on your machine, run the following command to rename
-   the branch to main.
-
-   ```console
-   $ git branch -M main
-   ```
-
-8. Run the following commands to stage, commit, and then push your local
-   repository to GitHub.
-
-   ```console
-   $ git add -A
-   $ git commit -m "my first commit"
-   $ git push -u origin main
-   ```
-
-## Step two: Set up the workflow
-
-Set up your GitHub Actions workflow for building, testing, and pushing the image
-to Docker Hub.
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-
-2. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub actions workflow file in
-   your repository, under `.github/workflows/main.yml` by default.
-
-3. In the editor window, copy and paste the following YAML configuration.
-
-   ```yaml
-   name: ci
-
-   on:
-     push:
-       branches:
-         - main
-
-   jobs:
-     build:
-       runs-on: ubuntu-latest
-       steps:
-         - name: Login to Docker Hub
-           uses: docker/login-action@v3
-           with:
-             username: ${{ vars.DOCKER_USERNAME }}
-             password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-         - name: Set up Docker Buildx
-           uses: docker/setup-buildx-action@v3
-
-         - name: Build and test
-           uses: docker/build-push-action@v6
-           with:
-             target: build
-             load: true
-
-         - name: Build and push
-           uses: docker/build-push-action@v6
-           with:
-             platforms: linux/amd64,linux/arm64
-             push: true
-             target: final
-             tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-   ```
-
-   For more information about the YAML syntax for `docker/build-push-action`,
-   refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
-## Step three: Run the workflow
-
-Save the workflow file and run the job.
-
-1. Select **Commit changes...** and push the changes to the `main` branch.
-
-   After pushing the commit, the workflow starts automatically.
-
-2. Go to the **Actions** tab. It displays the workflow.
-
-   Selecting the workflow shows you the breakdown of all the steps.
-
-3. When the workflow is complete, go to your
-   [repositories on Docker Hub](https://hub.docker.com/repositories).
-
-   If you see the new repository in that list, it means the GitHub Actions
-   successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your application.
-
-Related information:
-
-- [Introduction to GitHub Actions](/guides/gha.md)
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md)
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-Next, learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/dotnet/containerize.md b/content/guides/dotnet/containerize.md
deleted file mode 100644
index 146874ca9d8c..000000000000
--- a/content/guides/dotnet/containerize.md
+++ /dev/null
@@ -1,133 +0,0 @@
----
-title: Containerize a .NET application
-linkTitle: Containerize your app
-weight: 10
-keywords: .net, containerize, initialize
-description: Learn how to containerize an ASP.NET application.
-aliases:
-- /language/dotnet/build-images/
-- /language/dotnet/run-containers/
-- /language/dotnet/containerize/
-- /guides/language/dotnet/containerize/
----
-
-## Prerequisites
-
-* You have installed the latest version of [Docker
-  Desktop](/get-started/get-docker.md).
-* You have a [git client](https://git-scm.com/downloads). The examples in this
-  section use a command-line based git client, but you can use any client.
-
-## Overview
-
-This section walks you through containerizing and running a .NET
-application.
-
-## Get the sample applications
-
-In this guide, you will use a pre-built .NET application. The application is
-similar to the application built in the Docker Blog article, [Building a
-Multi-Container .NET App Using Docker
-Desktop](https://www.docker.com/blog/building-multi-container-net-app-using-docker-desktop/).
-
-Open a terminal, change directory to a directory that you want to work in, and
-run the following command to clone the repository.
-
-```console
-$ git clone https://github.com/docker/docker-dotnet-sample
-```
-
-## Initialize Docker assets
-
-Now that you have an application, you can use `docker init` to create the
-necessary Docker assets to containerize your application. Inside the
-`docker-dotnet-sample` directory, run the `docker init` command in a terminal.
-`docker init` provides some default configuration, but you'll need to answer a
-few questions about your application. Refer to the following example to answer
-the prompts from `docker init` and use the same answers for your prompts.
-
-```console
-$ docker init
-Welcome to the Docker Init CLI!
-
-This utility will walk you through creating the following files with sensible defaults for your project:
-  - .dockerignore
-  - Dockerfile
-  - compose.yaml
-  - README.Docker.md
-
-Let's get started!
-
-? What application platform does your project use? ASP.NET Core
-? What's the name of your solution's main project? myWebApp
-? What version of .NET do you want to use? 8.0
-? What local port do you want to use to access your server? 8080
-```
-
-You should now have the following contents in your `docker-dotnet-sample`
-directory.
-
-```text
-├── docker-dotnet-sample/
-│ ├── .git/
-│ ├── src/
-│ ├── .dockerignore
-│ ├── compose.yaml
-│ ├── Dockerfile
-│ ├── README.Docker.md
-│ └── README.md
-```
-
-To learn more about the files that `docker init` added, see the following:
- - [Dockerfile](/reference/dockerfile.md)
- - [.dockerignore](/reference/dockerfile.md#dockerignore-file)
- - [compose.yaml](/reference/compose-file/_index.md)
-
-## Run the application
-
-Inside the `docker-dotnet-sample` directory, run the following command in a
-terminal.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple web application.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-### Run the application in the background
-
-You can run the application detached from the terminal by adding the `-d`
-option. Inside the `docker-dotnet-sample` directory, run the following command
-in a terminal.
-
-```console
-$ docker compose up --build -d
-```
-
-Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple web application.
-
-In the terminal, run the following command to stop the application.
-
-```console
-$ docker compose down
-```
-
-For more information about Compose commands, see the [Compose CLI
-reference](/reference/cli/docker/compose/_index.md).
-
-## Summary
-
-In this section, you learned how you can containerize and run your .NET
-application using Docker.
-
-Related information:
- - [Dockerfile reference](/reference/dockerfile.md)
- - [.dockerignore file reference](/reference/dockerfile.md#dockerignore-file)
- - [Docker Compose overview](/manuals/compose/_index.md)
-
-## Next steps
-
-In the next section, you'll learn how you can develop your application using
-Docker containers.
diff --git a/content/guides/dotnet/deploy.md b/content/guides/dotnet/deploy.md
deleted file mode 100644
index 837917a0baba..000000000000
--- a/content/guides/dotnet/deploy.md
+++ /dev/null
@@ -1,224 +0,0 @@
----
-title: Test your .NET deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, .net, local, development
-description: Learn how to deploy your application
-aliases:
-  - /language/dotnet/deploy/
-  - /guides/language/dotnet/deploy/
----
-
-## Prerequisites
-
-- Complete all the previous sections of this guide, starting with [Containerize
-  a .NET application](containerize.md).
-- [Turn on Kubernetes](/manuals/desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker
-  Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your
-application to a fully-featured Kubernetes environment on your development
-machine. This allows you to test and debug your workloads on Kubernetes locally
-before deploying.
-
-## Create a Kubernetes YAML file
-
-In your `docker-dotnet-sample` directory, create a file named
-`docker-dotnet-kubernetes.yaml`. Open the file in an IDE or text editor and add
-the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker
-username and the name of the repository that you created in [Configure CI/CD for
-your .NET application](configure-ci-cd.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  labels:
-    service: server
-  name: server
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      service: server
-  strategy: {}
-  template:
-    metadata:
-      labels:
-        service: server
-    spec:
-      initContainers:
-        - name: wait-for-db
-          image: busybox:1.28
-          command:
-            [
-              "sh",
-              "-c",
-              'until nc -zv db 5432; do echo "waiting for db"; sleep 2; done;',
-            ]
-      containers:
-        - image: DOCKER_USERNAME/REPO_NAME
-          name: server
-          imagePullPolicy: Always
-          ports:
-            - containerPort: 8080
-              hostPort: 8080
-              protocol: TCP
-          resources: {}
-      restartPolicy: Always
-status: {}
----
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  labels:
-    service: db
-  name: db
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      service: db
-  strategy:
-    type: Recreate
-  template:
-    metadata:
-      labels:
-        service: db
-    spec:
-      containers:
-        - env:
-            - name: POSTGRES_DB
-              value: example
-            - name: POSTGRES_PASSWORD
-              value: example
-          image: postgres
-          name: db
-          ports:
-            - containerPort: 5432
-              protocol: TCP
-          resources: {}
-      restartPolicy: Always
-status: {}
----
-apiVersion: v1
-kind: Service
-metadata:
-  labels:
-    service: server
-  name: server
-  namespace: default
-spec:
-  type: NodePort
-  ports:
-    - name: "8080"
-      port: 8080
-      targetPort: 8080
-      nodePort: 30001
-  selector:
-    service: server
-status:
-  loadBalancer: {}
----
-apiVersion: v1
-kind: Service
-metadata:
-  labels:
-    service: db
-  name: db
-  namespace: default
-spec:
-  ports:
-    - name: "5432"
-      port: 5432
-      targetPort: 5432
-  selector:
-    service: db
-status:
-  loadBalancer: {}
-```
-
-In this Kubernetes YAML file, there are four objects, separated by the `---`. In addition to a Service and Deployment for the database, the other two objects are:
-
-- A Deployment, describing a scalable group of identical pods. In this case,
-  you'll get just one replica, or copy of your pod. That pod, which is
-  described under `template`, has just one container in it. The container is
-  created from the image built by GitHub Actions in [Configure CI/CD for your
-  .NET application](configure-ci-cd.md).
-- A NodePort service, which will route traffic from port 30001 on your host to
-  port 8080 inside the pods it routes to, allowing you to reach your app
-  from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to the `docker-dotnet-sample` directory
-   and deploy your application to Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-dotnet-kubernetes.yaml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```shell
-   deployment.apps/db created
-   service/db created
-   deployment.apps/server created
-   service/server created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```shell
-   NAME     READY   UP-TO-DATE   AVAILABLE   AGE
-   db       1/1     1            1           76s
-   server   1/1     1            1           76s
-   ```
-
-   This indicates all of the pods are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```shell
-   NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
-   db           ClusterIP   10.96.156.90    <none>        5432/TCP         2m8s
-   kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP          164m
-   server       NodePort    10.102.94.225   <none>        8080:30001/TCP   2m8s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `server` service and `db` service. The `server` service is accepting traffic on port 30001/TCP.
-
-3. Open a browser and visit your app at `localhost:30001`. You should see your
-   application.
-
-4. Run the following command to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-dotnet-kubernetes.yaml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine.
-
-Related information:
-
-- [Kubernetes documentation](https://kubernetes.io/docs/home/)
-- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-- [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/dotnet/develop.md b/content/guides/dotnet/develop.md
deleted file mode 100644
index d5bea5491fd1..000000000000
--- a/content/guides/dotnet/develop.md
+++ /dev/null
@@ -1,397 +0,0 @@
----
-title: Use containers for .NET development
-linkTitle: Develop your app
-weight: 20
-keywords: .net, development
-description: Learn how to develop your .NET application locally using containers.
-aliases:
-  - /language/dotnet/develop/
-  - /guides/language/dotnet/develop/
----
-
-## Prerequisites
-
-Complete [Containerize a .NET application](containerize.md).
-
-## Overview
-
-In this section, you'll learn how to set up a development environment for your containerized application. This includes:
-
-- Adding a local database and persisting data
-- Configuring Compose to automatically update your running Compose services as you edit and save your code
-- Creating a development container that contains the .NET Core SDK tools and dependencies
-
-## Update the application
-
-This section uses a different branch of the `docker-dotnet-sample` repository
-that contains an updated .NET application. The updated application is on the
-`add-db` branch of the repository you cloned in [Containerize a .NET
-application](containerize.md).
-
-To get the updated code, you need to checkout the `add-db` branch. For the changes you made in [Containerize a .NET application](containerize.md), for this section, you can stash them. In a terminal, run the following commands in the `docker-dotnet-sample` directory.
-
-1. Stash any previous changes.
-
-   ```console
-   $ git stash -u
-   ```
-
-2. Check out the new branch with the updated application.
-
-   ```console
-   $ git checkout add-db
-   ```
-
-In the `add-db` branch, only the .NET application has been updated. None of the Docker assets have been updated yet.
-
-You should now have the following in your `docker-dotnet-sample` directory.
-
-```text
-├── docker-dotnet-sample/
-│ ├── .git/
-│ ├── src/
-│ │ ├── Data/
-│ │ ├── Models/
-│ │ ├── Pages/
-│ │ ├── Properties/
-│ │ ├── wwwroot/
-│ │ ├── appsettings.Development.json
-│ │ ├── appsettings.json
-│ │ ├── myWebApp.csproj
-│ │ └── Program.cs
-│ ├── tests/
-│ │ ├── tests.csproj
-│ │ ├── UnitTest1.cs
-│ │ └── Usings.cs
-│ ├── .dockerignore
-│ ├── .gitignore
-│ ├── compose.yaml
-│ ├── Dockerfile
-│ ├── README.Docker.md
-│ └── README.md
-```
-
-## Add a local database and persist data
-
-You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service and a volume to persist data.
-
-Open the `compose.yaml` file in an IDE or text editor. You'll notice it
-already contains commented-out instructions for a PostgreSQL database and volume.
-
-Open `docker-dotnet-sample/src/appsettings.json` in an IDE or text editor. You'll
-notice the connection string with all the database information. The
-`compose.yaml` already contains this information, but it's commented out.
-Uncomment the database instructions in the `compose.yaml` file.
-
-The following is the updated `compose.yaml` file.
-
-```yaml {hl_lines="8-33"}
-services:
-  server:
-    build:
-      context: .
-      target: final
-    ports:
-      - 8080:8080
-    depends_on:
-      db:
-        condition: service_healthy
-  db:
-    image: postgres
-    restart: always
-    user: postgres
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=example
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    expose:
-      - 5432
-    healthcheck:
-      test: ["CMD", "pg_isready"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-> [!NOTE]
->
-> To learn more about the instructions in the Compose file, see [Compose file
-> reference](/reference/compose-file/).
-
-Before you run the application using Compose, notice that this Compose file uses
-`secrets` and specifies a `password.txt` file to hold the database's password.
-You must create this file as it's not included in the source repository.
-
-In the `docker-dotnet-sample` directory, create a new directory named `db` and
-inside that directory create a file named `password.txt`. Open `password.txt` in an IDE or text editor and add the following password. The password must be on a single line, with no additional lines in the file.
-
-```text
-example
-```
-
-Save and close the `password.txt` file.
-
-You should now have the following in your `docker-dotnet-sample` directory.
-
-```text
-├── docker-dotnet-sample/
-│ ├── .git/
-│ ├── db/
-│ │ └── password.txt
-│ ├── src/
-│ ├── tests/
-│ ├── .dockerignore
-│ ├── .gitignore
-│ ├── compose.yaml
-│ ├── Dockerfile
-│ ├── README.Docker.md
-│ └── README.md
-```
-
-Run the following command to start your application.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple web application with the text `Student name is`.
-
-The application doesn't display a name because the database is empty. For this application, you need to access the database and then add records.
-
-## Add records to the database
-
-For the sample application, you must access the database directly to create sample records.
-
-You can run commands inside the database container using the `docker exec`
-command. Before running that command, you must get the ID of the database
-container. Open a new terminal window and run the following command to list all
-your running containers.
-
-```console
-$ docker container ls
-```
-
-You should see output like the following.
-
-```console
-CONTAINER ID   IMAGE                  COMMAND                  CREATED              STATUS                        PORTS                    NAMES
-cb36e310aa7e   docker-dotnet-server   "dotnet myWebApp.dll"    About a minute ago   Up About a minute             0.0.0.0:8080->8080/tcp   docker-dotnet-server-1
-39fdcf0aff7b   postgres               "docker-entrypoint.s…"   About a minute ago   Up About a minute (healthy)   5432/tcp                 docker-dotnet-db-1
-```
-
-In the previous example, the container ID is `39fdcf0aff7b`. Run the following command to connect to the postgres database in the container. Replace the container ID with your own container ID.
-
-```console
-$ docker exec -it 39fdcf0aff7b psql -d example -U postgres
-```
-
-And finally, insert a record into the database.
-
-```console
-example=# INSERT INTO "Students" ("ID", "LastName", "FirstMidName", "EnrollmentDate") VALUES (DEFAULT, 'Whale', 'Moby', '2013-03-20');
-```
-
-You should see output like the following.
-
-```console
-INSERT 0 1
-```
-
-Close the database connection and exit the container shell by running `exit`.
-
-```console
-example=# exit
-```
-
-## Verify that data persists in the database
-
-Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple web application with the text `Student name is Whale Moby`.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-In the terminal, run `docker compose rm` to remove your containers and then run `docker compose up` to run your application again.
-
-```console
-$ docker compose rm
-$ docker compose up --build
-```
-
-Refresh [http://localhost:8080](http://localhost:8080) in your browser and verify that the student name persisted, even after the containers were removed and ran again.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Automatically update services
-
-Use Compose Watch to automatically update your running Compose services as you edit and save your code. For more details about Compose Watch, see [Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
-
-Open your `compose.yaml` file in an IDE or text editor and then add the Compose Watch instructions. The following is the updated `compose.yaml` file.
-
-```yaml {hl_lines="11-14"}
-services:
-  server:
-    build:
-      context: .
-      target: final
-    ports:
-      - 8080:8080
-    depends_on:
-      db:
-        condition: service_healthy
-    develop:
-      watch:
-        - action: rebuild
-          path: .
-  db:
-    image: postgres
-    restart: always
-    user: postgres
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=example
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    expose:
-      - 5432
-    healthcheck:
-      test: ["CMD", "pg_isready"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-Run the following command to run your application with Compose Watch.
-
-```console
-$ docker compose watch
-```
-
-Open a browser and verify that the application is running at [http://localhost:8080](http://localhost:8080).
-
-Any changes to the application's source files on your local machine will now be
-immediately reflected in the running container.
-
-Open `docker-dotnet-sample/src/Pages/Index.cshtml` in an IDE or text editor and update the student name text on line 13 from `Student name is` to `Student name:`.
-
-```diff
--    <p>Student Name is @Model.StudentName</p>
-+    <p>Student name: @Model.StudentName</p>
-```
-
-Save the changes to `Index.cshmtl` and then wait a few seconds for the application to rebuild. Refresh [http://localhost:8080](http://localhost:8080) in your browser and verify that the updated text appears.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Create a development container
-
-At this point, when you run your containerized application, it's using the .NET runtime image. While this small image is good for production, it lacks the SDK tools and dependencies you may need when developing. Also, during development, you may not need to run `dotnet publish`. You can use multi-stage builds to build stages for both development and production in the same Dockerfile. For more details, see [Multi-stage builds](/manuals/build/building/multi-stage.md).
-
-Add a new development stage to your Dockerfile and update your `compose.yaml` file to use this stage for local development.
-
-The following is the updated Dockerfile.
-
-```Dockerfile {hl_lines="10-13"}
-# syntax=docker/dockerfile:1
-
-FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS build
-ARG TARGETARCH
-COPY . /source
-WORKDIR /source/src
-RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages \
-    dotnet publish -a ${TARGETARCH/amd64/x64} --use-current-runtime --self-contained false -o /app
-
-FROM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS development
-COPY . /source
-WORKDIR /source/src
-CMD dotnet run --no-launch-profile
-
-FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS final
-WORKDIR /app
-COPY --from=build /app .
-ARG UID=10001
-RUN adduser \
-    --disabled-password \
-    --gecos "" \
-    --home "/nonexistent" \
-    --shell "/sbin/nologin" \
-    --no-create-home \
-    --uid "${UID}" \
-    appuser
-USER appuser
-ENTRYPOINT ["dotnet", "myWebApp.dll"]
-```
-
-The following is the updated `compose.yaml` file.
-
-```yaml {hl_lines=[5,15,16]}
-services:
-  server:
-    build:
-      context: .
-      target: development
-    ports:
-      - 8080:8080
-    depends_on:
-      db:
-        condition: service_healthy
-    develop:
-      watch:
-        - action: rebuild
-          path: .
-    environment:
-      - ASPNETCORE_ENVIRONMENT=Development
-  db:
-    image: postgres
-    restart: always
-    user: postgres
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=example
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    expose:
-      - 5432
-    healthcheck:
-      test: ["CMD", "pg_isready"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-Your containerized application will now use the `mcr.microsoft.com/dotnet/sdk:8.0-alpine` image, which includes development tools like `dotnet test`. Continue to the next section to learn how you can run `dotnet test`.
-
-## Summary
-
-In this section, you took a look at setting up your Compose file to add a local
-database and persist data. You also learned how to use Compose Watch to automatically rebuild and run your container when you update your code. And finally, you learned how to create a development container that contains the SDK tools and dependencies needed for development.
-
-Related information:
-
-- [Compose file reference](/reference/compose-file/)
-- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
-- [Multi-stage builds](/manuals/build/building/multi-stage.md)
-
-## Next steps
-
-In the next section, you'll learn how to run unit tests using Docker.
diff --git a/content/guides/dotnet/run-tests.md b/content/guides/dotnet/run-tests.md
deleted file mode 100644
index 1e404c345965..000000000000
--- a/content/guides/dotnet/run-tests.md
+++ /dev/null
@@ -1,118 +0,0 @@
----
-title: Run .NET tests in a container
-linkTitle: Run your tests
-weight: 30
-keywords: .NET, test
-description: Learn how to run your .NET tests in a container.
-aliases:
-  - /language/dotnet/run-tests/
-  - /guides/language/dotnet/run-tests/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a .NET application](containerize.md).
-
-## Overview
-
-Testing is an essential part of modern software development. Testing can mean a
-lot of things to different development teams. There are unit tests, integration
-tests and end-to-end testing. In this guide you take a look at running your unit
-tests in Docker when developing and when building.
-
-## Run tests when developing locally
-
-The sample application already has an xUnit test inside the `tests` directory. When developing locally, you can use Compose to run your tests.
-
-Run the following command in the `docker-dotnet-sample` directory to run the tests inside a container.
-
-```console
-$ docker compose run --build --rm server dotnet test /source/tests
-```
-
-You should see output that contains the following.
-
-```console
-Starting test execution, please wait...
-A total of 1 test files matched the specified pattern.
-
-Passed!  - Failed:     0, Passed:     1, Skipped:     0, Total:     1, Duration: < 1 ms - /source/tests/bin/Debug/net8.0/tests.dll (net8.0)
-```
-
-To learn more about the command, see [docker compose run](/reference/cli/docker/compose/run/).
-
-## Run tests when building
-
-To run your tests when building, you need to update your Dockerfile. You can create a new test stage that runs the tests, or run the tests in the existing build stage. For this guide, update the Dockerfile to run the tests in the build stage.
-
-The following is the updated Dockerfile.
-
-```dockerfile {hl_lines="9"}
-# syntax=docker/dockerfile:1
-
-FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS build
-ARG TARGETARCH
-COPY . /source
-WORKDIR /source/src
-RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages \
-    dotnet publish -a ${TARGETARCH/amd64/x64} --use-current-runtime --self-contained false -o /app
-RUN dotnet test /source/tests
-
-FROM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS development
-COPY . /source
-WORKDIR /source/src
-CMD dotnet run --no-launch-profile
-
-FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS final
-WORKDIR /app
-COPY --from=build /app .
-ARG UID=10001
-RUN adduser \
-    --disabled-password \
-    --gecos "" \
-    --home "/nonexistent" \
-    --shell "/sbin/nologin" \
-    --no-create-home \
-    --uid "${UID}" \
-    appuser
-USER appuser
-ENTRYPOINT ["dotnet", "myWebApp.dll"]
-```
-
-Run the following command to build an image using the build stage as the target and view the test results. Include `--progress=plain` to view the build output, `--no-cache` to ensure the tests always run, and `--target build` to target the build stage.
-
-```console
-$ docker build -t dotnet-docker-image-test --progress=plain --no-cache --target build .
-```
-
-You should see output containing the following.
-
-```console
-#11 [build 5/5] RUN dotnet test /source/tests
-#11 1.564   Determining projects to restore...
-#11 3.421   Restored /source/src/myWebApp.csproj (in 1.02 sec).
-#11 19.42   Restored /source/tests/tests.csproj (in 17.05 sec).
-#11 27.91   myWebApp -> /source/src/bin/Debug/net8.0/myWebApp.dll
-#11 28.47   tests -> /source/tests/bin/Debug/net8.0/tests.dll
-#11 28.49 Test run for /source/tests/bin/Debug/net8.0/tests.dll (.NETCoreApp,Version=v8.0)
-#11 28.67 Microsoft (R) Test Execution Command Line Tool Version 17.3.3 (x64)
-#11 28.67 Copyright (c) Microsoft Corporation.  All rights reserved.
-#11 28.68
-#11 28.97 Starting test execution, please wait...
-#11 29.03 A total of 1 test files matched the specified pattern.
-#11 32.07
-#11 32.08 Passed!  - Failed:     0, Passed:     1, Skipped:     0, Total:     1, Duration: < 1 ms - /source/tests/bin/Debug/net8.0/tests.dll (net8.0)
-#11 DONE 32.2s
-```
-
-## Summary
-
-In this section, you learned how to run tests when developing locally using Compose and how to run tests when building your image.
-
-Related information:
-
-- [docker compose run](/reference/cli/docker/compose/run/)
-
-## Next steps
-
-Next, you’ll learn how to set up a CI/CD pipeline using GitHub Actions.
diff --git a/content/guides/frameworks/laravel/_index.md b/content/guides/frameworks/laravel/_index.md
deleted file mode 100644
index 6e7bd293b8bb..000000000000
--- a/content/guides/frameworks/laravel/_index.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-title: Develop and Deploy Laravel applications with Docker Compose
-linkTitle: Laravel applications with Docker Compose
-summary: Learn how to efficiently set up Laravel development and production environments using Docker Compose.
-description: A guide on using Docker Compose to manage Laravel applications for development and production, covering container configurations and service management.
-tags: [frameworks]
-languages: [php]
-aliases:
-  - /frameworks/laravel/
-params:
-  time: 30 minutes
-  resource_links:
-    - title: Laravel
-      url: https://laravel.com/
-    - title: Docker Compose
-      url: /compose/
-    - title: Use Compose in production
-      url: /compose/how-tos/production/
-    - title: Repository with examples
-      url: https://github.com/dockersamples/laravel-docker-examples
----
-
-Laravel is a popular PHP framework that allows developers to build web applications quickly and effectively. Docker Compose simplifies the management of development and production environments by defining essential services, like PHP, a web server, and a database, in a single YAML file. This guide provides a streamlined approach to setting up a robust Laravel environment using Docker Compose, focusing on simplicity and efficiency.
-
-> **Acknowledgment**
->
-> Docker would like to thank [Sergei Shitikov](https://github.com/rw4lll) for
-> his contribution to this guide.
-
-The demonstrated examples can be found in [this GitHub repository](https://github.com/dockersamples/laravel-docker-examples). Docker Compose offers a straightforward approach to connecting multiple containers for Laravel, though similar setups can also be achieved using tools like Docker Swarm, Kubernetes, or individual Docker containers.
-
-This guide is intended for educational purposes, helping developers adapt and optimize configurations for their specific use cases. Additionally, there are existing tools that support Laravel in containers:
-
-- [Laravel Sail](https://laravel.com/docs/11.x/sail): An official package for easily starting Laravel in Docker.
-- [Laradock](https://github.com/laradock/laradock): A community project that helps run Laravel applications in Docker.
-
-## What you’ll learn
-
-- How to use Docker Compose to set up a Laravel development and production environment.
-- Defining services that make Laravel development easier, including PHP-FPM, Nginx, and database containers.
-- Best practices for managing Laravel environments using containerization.
-
-## Who’s this for?
-
-- Developers who work with Laravel and want to streamline environment management.
-- DevOps engineers seeking efficient ways to manage and deploy Laravel applications.
diff --git a/content/guides/frameworks/laravel/common-questions.md b/content/guides/frameworks/laravel/common-questions.md
deleted file mode 100644
index 1bad5f87d9e3..000000000000
--- a/content/guides/frameworks/laravel/common-questions.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Common Questions on Using Laravel with Docker
-description: Find answers to common questions about setting up and managing Laravel environments with Docker Compose, including troubleshooting and best practices.
-weight: 40
----
-
-<!-- vale Docker.HeadingLength = NO -->
-
-## 1. Why should I use Docker Compose for Laravel?
-
-Docker Compose is a powerful tool for managing multi-container environments, particularly in development due to its simplicity. With Docker Compose, you can define and connect all necessary services for Laravel, such as PHP, Nginx, and databases, in a single configuration (`compose.*.yaml`). This setup ensures consistency across development, testing, and production environments, streamlining onboarding and reducing discrepancies between local and server setups.
-
-While Docker Compose is a great choice for development, tools like **Docker Swarm** or **Kubernetes** offer advanced scaling and orchestration features, which may be beneficial for complex production deployments.
-
-## 2. How do I debug my Laravel application with Docker Compose?
-
-To debug your Laravel application in a Docker environment, use **Xdebug**. In the development setup, Xdebug is installed in the `php-fpm` container to enable debugging. Ensure Xdebug is enabled in your `compose.dev.yaml` file by setting the environment variable `XDEBUG_ENABLED=true` and configuring your IDE (e.g., Visual Studio Code or PHPStorm) to connect to the remote container for debugging.
-
-## 3. Can I use Docker Compose with databases other than PostgreSQL?
-
-Yes, Docker Compose supports various database services for Laravel. While PostgreSQL is used in the examples, you can easily substitute **MySQL**, **MariaDB**, or even **SQLite**. Update the `compose.*.yaml` file to specify the required Docker image and adjust your `.env` file to reflect the new database configuration.
-
-## 4. How can I persist data in development and production?
-
-In both development and production, Docker volumes are used to persist data. For instance, in the `compose.*.yaml` file, the `postgres-data-*` volume stores PostgreSQL data, ensuring that data is retained even if the container restarts. You can also define named volumes for other services where data persistence is essential.
-
-## 5. What is the difference between development and production Docker configurations?
-
-In a development environment, Docker configurations include tools that streamline coding and debugging, such as Xdebug for debugging, and volume mounts to enable real-time code updates without requiring image rebuilds.
-
-In production, the configuration is optimized for performance, security, and efficiency. This setup uses multi-stage builds to keep the image lightweight and includes only essential tools, packages, and libraries.
-
-It’s recommended to use `alpine`-based images in production for smaller image sizes, enhancing deployment speed and security.
-
-Additionally, consider using [Docker Scout](/manuals/scout/_index.md) to detect and analyze vulnerabilities, especially in production environments.
-
-For additional information about using Docker Compose in production, see [this guide](/compose/how-tos/production/).
diff --git a/content/guides/frameworks/laravel/development-setup.md b/content/guides/frameworks/laravel/development-setup.md
deleted file mode 100644
index ffa427c139b3..000000000000
--- a/content/guides/frameworks/laravel/development-setup.md
+++ /dev/null
@@ -1,327 +0,0 @@
----
-title: Laravel Development Setup with Docker Compose
-description: Set up a Laravel development environment using Docker Compose.
-weight: 30
----
-
-This guide demonstrates how to configure a **development** environment for a Laravel application using Docker and Docker Compose. It builds **on top of** the production image for PHP-FPM and then adds developer-focused features—like Xdebug—to streamline debugging. By basing the development container on a known production image, you keep both environments closely aligned.
-
-This setup includes PHP-FPM, Nginx, and PostgreSQL services (although you can easily swap PostgreSQL for another database, like MySQL or MariaDB). Everything runs in containers, so you can develop in isolation without altering your host system.
-
-> [!NOTE]
-> To experiment with a ready-to-run configuration, download the [Laravel Docker Examples](https://github.com/dockersamples/laravel-docker-examples) repository. It contains pre-configured setups for both development and production.
-
-## Project structure
-
-```plaintext
-my-laravel-app/
-├── app/
-├── bootstrap/
-├── config/
-├── database/
-├── public/
-├── docker/
-│   ├── common/
-│   │   └── php-fpm/
-│   │       └── Dockerfile
-│   ├── development/
-│   │   ├── php-fpm/
-│   │   │   └── entrypoint.sh
-│   │   ├── workspace/
-│   │   │   └── Dockerfile
-│   │   └── nginx
-│   │       ├── Dockerfile
-│   │       └── nginx.conf
-│   └── production/
-├── compose.dev.yaml
-├── compose.prod.yaml
-├── .dockerignore
-├── .env
-├── vendor/
-├── ...
-```
-
-This layout represents a typical Laravel project, with Docker configurations stored in a unified `docker` directory. You’ll find **two** Compose files — `compose.dev.yaml` (for development) and `compose.prod.yaml` (for production) — to keep your environments separate and manageable.
-
-The environment includes a `workspace` service, a sidecar container for tasks like building front-end assets, running Artisan commands, and other CLI tools your project may require. While this extra container may seem unusual, it’s a familiar pattern in solutions like **Laravel Sail** and **Laradock**. It also includes **Xdebug** to aid in debugging.
-
-## Create a Dockerfile for PHP-FPM
-
-This Dockerfile **extends** the production image by installing Xdebug and adjusting user permissions to ease local development. That way, your development environment stays consistent with production while still offering extra debug features and improved file mounting.
-
-```dockerfile
-# Builds a dev-only layer on top of the production image
-FROM production AS development
-
-# Use ARGs to define environment variables passed from the Docker build command or Docker Compose.
-ARG XDEBUG_ENABLED=true
-ARG XDEBUG_MODE=develop,coverage,debug,profile
-ARG XDEBUG_HOST=host.docker.internal
-ARG XDEBUG_IDE_KEY=DOCKER
-ARG XDEBUG_LOG=/dev/stdout
-ARG XDEBUG_LOG_LEVEL=0
-
-USER root
-
-# Configure Xdebug if enabled
-RUN if [ "${XDEBUG_ENABLED}" = "true" ]; then \
-    pecl install xdebug && \
-    docker-php-ext-enable xdebug && \
-    echo "xdebug.mode=${XDEBUG_MODE}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
-    echo "xdebug.idekey=${XDEBUG_IDE_KEY}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
-    echo "xdebug.log=${XDEBUG_LOG}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
-    echo "xdebug.log_level=${XDEBUG_LOG_LEVEL}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
-    echo "xdebug.client_host=${XDEBUG_HOST}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini ; \
-    echo "xdebug.start_with_request=yes" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini ; \
-fi
-
-# Add ARGs for syncing permissions
-ARG UID=1000
-ARG GID=1000
-
-# Create a new user with the specified UID and GID, reusing an existing group if GID exists
-RUN if getent group ${GID}; then \
-      group_name=$(getent group ${GID} | cut -d: -f1); \
-      useradd -m -u ${UID} -g ${GID} -s /bin/bash www; \
-    else \
-      groupadd -g ${GID} www && \
-      useradd -m -u ${UID} -g www -s /bin/bash www; \
-      group_name=www; \
-    fi
-
-# Dynamically update php-fpm to use the new user and group
-RUN sed -i "s/user = www-data/user = www/g" /usr/local/etc/php-fpm.d/www.conf && \
-    sed -i "s/group = www-data/group = $group_name/g" /usr/local/etc/php-fpm.d/www.conf
-
-
-# Set the working directory
-WORKDIR /var/www
-
-# Copy the entrypoint script
-COPY ./docker/development/php-fpm/entrypoint.sh /usr/local/bin/entrypoint.sh
-RUN chmod +x /usr/local/bin/entrypoint.sh
-
-# Switch back to the non-privileged user to run the application
-USER www-data
-
-# Change the default command to run the entrypoint script
-ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]
-
-# Expose port 9000 and start php-fpm server
-EXPOSE 9000
-CMD ["php-fpm"]
-```
-
-## Create a Dockerfile for Workspace
-
-A workspace container provides a dedicated shell for asset compilation, Artisan/Composer commands, and other CLI tasks. This approach follows patterns from Laravel Sail and Laradock, consolidating all development tools into one container for convenience.
-
-```dockerfile
-# docker/development/workspace/Dockerfile
-# Use the official PHP CLI image as the base
-FROM php:8.3-cli
-
-# Set environment variables for user and group ID
-ARG UID=1000
-ARG GID=1000
-ARG NODE_VERSION=22.0.0
-
-# Install system dependencies and build libraries
-RUN apt-get update && apt-get install -y --no-install-recommends \
-    curl \
-    unzip \
-    libpq-dev \
-    libonig-dev \
-    libssl-dev \
-    libxml2-dev \
-    libcurl4-openssl-dev \
-    libicu-dev \
-    libzip-dev \
-    && docker-php-ext-install -j$(nproc) \
-    pdo_mysql \
-    pdo_pgsql \
-    pgsql \
-    opcache \
-    intl \
-    zip \
-    bcmath \
-    soap \
-    && pecl install redis xdebug \
-    && docker-php-ext-enable redis xdebug\
-    && curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \
-    && apt-get autoremove -y && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
-
-# Use ARG to define environment variables passed from the Docker build command or Docker Compose.
-ARG XDEBUG_ENABLED
-ARG XDEBUG_MODE
-ARG XDEBUG_HOST
-ARG XDEBUG_IDE_KEY
-ARG XDEBUG_LOG
-ARG XDEBUG_LOG_LEVEL
-
-# Configure Xdebug if enabled
-RUN if [ "${XDEBUG_ENABLED}" = "true" ]; then \
-    docker-php-ext-enable xdebug && \
-    echo "xdebug.mode=${XDEBUG_MODE}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
-    echo "xdebug.idekey=${XDEBUG_IDE_KEY}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
-    echo "xdebug.log=${XDEBUG_LOG}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
-    echo "xdebug.log_level=${XDEBUG_LOG_LEVEL}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
-    echo "xdebug.client_host=${XDEBUG_HOST}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini ; \
-    echo "xdebug.start_with_request=yes" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini ; \
-fi
-
-# If the group already exists, use it; otherwise, create the 'www' group
-RUN if getent group ${GID}; then \
-      useradd -m -u ${UID} -g ${GID} -s /bin/bash www; \
-    else \
-      groupadd -g ${GID} www && \
-      useradd -m -u ${UID} -g www -s /bin/bash www; \
-    fi && \
-    usermod -aG sudo www && \
-    echo 'www ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
-
-# Switch to the non-root user to install NVM and Node.js
-USER www
-
-# Install NVM (Node Version Manager) as the www user
-RUN export NVM_DIR="$HOME/.nvm" && \
-    curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.0/install.sh | bash && \
-    [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" && \
-    nvm install ${NODE_VERSION} && \
-    nvm alias default ${NODE_VERSION} && \
-    nvm use default
-
-# Ensure NVM is available for all future shells
-RUN echo 'export NVM_DIR="$HOME/.nvm"' >> /home/www/.bashrc && \
-    echo '[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"' >> /home/www/.bashrc && \
-    echo '[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"' >> /home/www/.bashrc
-
-# Set the working directory
-WORKDIR /var/www
-
-# Override the entrypoint to avoid the default php entrypoint
-ENTRYPOINT []
-
-# Default command to keep the container running
-CMD ["bash"]
-```
-
-> [!NOTE]
-> If you prefer a **one-service-per-container** approach, simply omit the workspace container and run separate containers for each task. For example, you could use a dedicated `php-cli` container for your PHP scripts, and a `node` container to handle the asset building.
-
-## Create a Docker Compose Configuration for development
-
-Here's the `compose.yaml` file to set up the development environment:
-
-```yaml
-services:
-  web:
-    image: nginx:latest # Using the default Nginx image with custom configuration.
-    volumes:
-      # Mount the application code for live updates
-      - ./:/var/www
-      # Mount the Nginx configuration file
-      - ./docker/development/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
-    ports:
-      # Map port 80 inside the container to the port specified by 'NGINX_PORT' on the host machine
-      - "80:80"
-    environment:
-      - NGINX_HOST=localhost
-    networks:
-      - laravel-development
-    depends_on:
-      php-fpm:
-        condition: service_started # Wait for php-fpm to start
-
-  php-fpm:
-    # For the php-fpm service, we will use our common PHP-FPM Dockerfile with the development target
-    build:
-      context: .
-      dockerfile: ./docker/common/php-fpm/Dockerfile
-      target: development
-      args:
-        UID: ${UID:-1000}
-        GID: ${GID:-1000}
-        XDEBUG_ENABLED: ${XDEBUG_ENABLED:-true}
-        XDEBUG_MODE: develop,coverage,debug,profile
-        XDEBUG_HOST: ${XDEBUG_HOST:-host.docker.internal}
-        XDEBUG_IDE_KEY: ${XDEBUG_IDE_KEY:-DOCKER}
-        XDEBUG_LOG: /dev/stdout
-        XDEBUG_LOG_LEVEL: 0
-    env_file:
-      # Load the environment variables from the Laravel application
-      - .env
-    user: "${UID:-1000}:${GID:-1000}"
-    volumes:
-      # Mount the application code for live updates
-      - ./:/var/www
-    networks:
-      - laravel-development
-    depends_on:
-      postgres:
-        condition: service_started # Wait for postgres to start
-
-  workspace:
-    # For the workspace service, we will also create a custom image to install and setup all the necessary stuff.
-    build:
-      context: .
-      dockerfile: ./docker/development/workspace/Dockerfile
-      args:
-        UID: ${UID:-1000}
-        GID: ${GID:-1000}
-        XDEBUG_ENABLED: ${XDEBUG_ENABLED:-true}
-        XDEBUG_MODE: develop,coverage,debug,profile
-        XDEBUG_HOST: ${XDEBUG_HOST:-host.docker.internal}
-        XDEBUG_IDE_KEY: ${XDEBUG_IDE_KEY:-DOCKER}
-        XDEBUG_LOG: /dev/stdout
-        XDEBUG_LOG_LEVEL: 0
-    tty: true # Enables an interactive terminal
-    stdin_open: true # Keeps standard input open for 'docker exec'
-    env_file:
-      - .env
-    volumes:
-      - ./:/var/www
-    networks:
-      - laravel-development
-
-  postgres:
-    image: postgres:16
-    ports:
-      - "${POSTGRES_PORT:-5432}:5432"
-    environment:
-      - POSTGRES_DB=app
-      - POSTGRES_USER=laravel
-      - POSTGRES_PASSWORD=secret
-    volumes:
-      - postgres-data-development:/var/lib/postgresql/data
-    networks:
-      - laravel-development
-
-  redis:
-    image: redis:alpine
-    networks:
-      - laravel-development
-
-networks:
-  laravel-development:
-
-volumes:
-  postgres-data-development:
-```
-
-> [!NOTE]
-> Ensure you have an `.env` file at the root of your Laravel project with the necessary configurations. You can use the `.env.example` file as a template.
-
-## Run your development environment
-
-To start the development environment, use:
-
-```console
-$ docker compose -f compose.dev.yaml up --build -d
-```
-
-Run this command to build and start the development environment in detached mode. When the containers finish initializing, visit [http://localhost/](http://localhost/) to see your Laravel app in action.
-
-## Summary
-
-By building on top of the production image and adding debug tools like Xdebug, you create a Laravel development workflow that closely mirrors production. The optional workspace container simplifies tasks like asset building and running Artisan commands. If you prefer a separate container for every service (e.g., a dedicated `php-cli` and `node` container), you can skip the workspace approach. Either way, Docker Compose provides an efficient, consistent way to develop your Laravel project.
diff --git a/content/guides/frameworks/laravel/prerequisites.md b/content/guides/frameworks/laravel/prerequisites.md
deleted file mode 100644
index 4ea2dec3d5a7..000000000000
--- a/content/guides/frameworks/laravel/prerequisites.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Prerequisites for Setting Up Laravel with Docker Compose
-description: Ensure you have the required tools and knowledge before setting up Laravel with Docker Compose.
-weight: 10
----
-
-Before you begin setting up Laravel with Docker Compose, make sure you meet the following prerequisites:
-
-## Docker and Docker Compose
-
-You need Docker and Docker Compose installed on your system. Docker allows you to containerize applications, and Docker Compose helps you manage multi-container applications.
-
-- Docker: Make sure Docker is installed and running on your machine. Refer to the [Docker installation guide](/get-docker/) to install Docker.
-- Docker Compose: Docker Compose is included with Docker Desktop, but you can also follow the [Docker Compose installation guide](/compose/install/) if needed.
-
-## Basic understanding of Docker and containers
-
-A fundamental understanding of Docker and how containers work will be helpful. If you're new to Docker, consider reviewing the [Docker Overview](/get-started/overview/) to familiarize yourself with containerization concepts.
-
-## Basic knowledge of Laravel
-
-This guide assumes you have a basic understanding of Laravel and PHP. Familiarity with Laravel’s command-line tools, such as [Artisan](https://laravel.com/docs/11.x/artisan), and its project structure is important for following the instructions.
-
-- Laravel CLI: You should be comfortable using Laravel’s command-line tool (`artisan`).
-- Laravel Project Structure: Familiarize yourself with Laravel’s folder structure (`app`, `config`, `routes`, `tests`, etc.).
diff --git a/content/guides/frameworks/laravel/production-setup.md b/content/guides/frameworks/laravel/production-setup.md
deleted file mode 100644
index 61f99009b63e..000000000000
--- a/content/guides/frameworks/laravel/production-setup.md
+++ /dev/null
@@ -1,443 +0,0 @@
----
-title: Laravel Production Setup with Docker Compose
-description: Set up a production-ready environment for Laravel using Docker Compose.
-weight: 20
----
-
-This guide demonstrates how to set up a production-ready Laravel environment using Docker and Docker Compose. This configuration is designed for streamlined, scalable, and secure Laravel application deployments.
-
-> [!NOTE]
-> To experiment with a ready-to-run configuration, download the [Laravel Docker Examples](https://github.com/dockersamples/laravel-docker-examples) repository. It contains pre-configured setups for both development and production.
-
-## Project structure
-
-```plaintext
-my-laravel-app/
-├── app/
-├── bootstrap/
-├── config/
-├── database/
-├── public/
-├── docker/
-│   ├── common/
-│   │   └── php-fpm/
-│   │       └── Dockerfile
-│   ├── development/
-│   ├── production/
-│   │   ├── php-fpm/
-│   │   │   └── entrypoint.sh
-│   │   └── nginx
-│   │       ├── Dockerfile
-│   │       └── nginx.conf
-├── compose.dev.yaml
-├── compose.prod.yaml
-├── .dockerignore
-├── .env
-├── vendor/
-├── ...
-```
-
-This layout represents a typical Laravel project, with Docker configurations stored in a unified `docker` directory. You’ll find **two** Compose files — `compose.dev.yaml` (for development) and `compose.prod.yaml` (for production) — to keep your environments separate and manageable.
-
-## Create a Dockerfile for PHP-FPM (production)
-
-For production, the `php-fpm` Dockerfile creates an optimized image with only the PHP extensions and libraries your application needs. As demonstrated in the [GitHub example](https://github.com/dockersamples/laravel-docker-examples), a single Dockerfile with multi-stage builds maintains consistency and reduces duplication between development and production. The following snippet shows only the production-related stages:
-
-```dockerfile
-# Stage 1: Build environment and Composer dependencies
-FROM php:8.3-fpm AS builder
-
-# Install system dependencies and PHP extensions for Laravel with MySQL/PostgreSQL support.
-# Dependencies in this stage are only required for building the final image.
-# Node.js and asset building are handled in the Nginx stage, not here.
-RUN apt-get update && apt-get install -y --no-install-recommends \
-    curl \
-    unzip \
-    libpq-dev \
-    libonig-dev \
-    libssl-dev \
-    libxml2-dev \
-    libcurl4-openssl-dev \
-    libicu-dev \
-    libzip-dev \
-    && docker-php-ext-install -j$(nproc) \
-    pdo_mysql \
-    pdo_pgsql \
-    pgsql \
-    opcache \
-    intl \
-    zip \
-    bcmath \
-    soap \
-    && pecl install redis \
-    && docker-php-ext-enable redis \
-    && apt-get autoremove -y && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
-
-# Set the working directory inside the container
-WORKDIR /var/www
-
-# Copy the entire Laravel application code into the container
-# -----------------------------------------------------------
-# In Laravel, `composer install` may trigger scripts
-# needing access to application code.
-# For example, the `post-autoload-dump` event might execute
-# Artisan commands like `php artisan package:discover`. If the
-# application code (including the `artisan` file) is not
-# present, these commands will fail, leading to build errors.
-#
-# By copying the entire application code before running
-# `composer install`, we ensure that all necessary files are
-# available, allowing these scripts to run successfully.
-# In other cases, it would be possible to copy composer files
-# first, to leverage Docker's layer caching mechanism.
-# -----------------------------------------------------------
-COPY . /var/www
-
-# Install Composer and dependencies
-RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \
-    && composer install --no-dev --optimize-autoloader --no-interaction --no-progress --prefer-dist
-
-# Stage 2: Production environment
-FROM php:8.3-fpm
-
-# Install only runtime libraries needed in production
-# libfcgi-bin and procps are required for the php-fpm-healthcheck script
-RUN apt-get update && apt-get install -y --no-install-recommends \
-    libpq-dev \
-    libicu-dev \
-    libzip-dev \
-    libfcgi-bin \
-    procps \
-    && apt-get autoremove -y && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
-
-# Download and install php-fpm health check script
-RUN curl -o /usr/local/bin/php-fpm-healthcheck \
-    https://raw.githubusercontent.com/renatomefi/php-fpm-healthcheck/master/php-fpm-healthcheck \
-    && chmod +x /usr/local/bin/php-fpm-healthcheck
-
-# Copy the initialization script
-COPY ./docker/php-fpm/entrypoint.sh /usr/local/bin/entrypoint.sh
-RUN chmod +x /usr/local/bin/entrypoint.sh
-
-# Copy the initial storage structure
-COPY ./storage /var/www/storage-init
-
-# Copy PHP extensions and libraries from the builder stage
-COPY --from=builder /usr/local/lib/php/extensions/ /usr/local/lib/php/extensions/
-COPY --from=builder /usr/local/etc/php/conf.d/ /usr/local/etc/php/conf.d/
-COPY --from=builder /usr/local/bin/docker-php-ext-* /usr/local/bin/
-
-# Use the recommended production PHP configuration
-# -----------------------------------------------------------
-# PHP provides development and production configurations.
-# Here, we replace the default php.ini with the production
-# version to apply settings optimized for performance and
-# security in a live environment.
-# -----------------------------------------------------------
-RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
-
-# Enable PHP-FPM status page by modifying zz-docker.conf with sed
-RUN sed -i '/\[www\]/a pm.status_path = /status' /usr/local/etc/php-fpm.d/zz-docker.conf
-# Update the variables_order to include E (for ENV)
-#RUN sed -i 's/variables_order = "GPCS"/variables_order = "EGPCS"/' "$PHP_INI_DIR/php.ini"
-
-# Copy the application code and dependencies from the build stage
-COPY --from=builder /var/www /var/www
-
-# Set working directory
-WORKDIR /var/www
-
-# Ensure correct permissions
-RUN chown -R www-data:www-data /var/www
-
-# Switch to the non-privileged user to run the application
-USER www-data
-
-# Change the default command to run the entrypoint script
-ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]
-
-# Expose port 9000 and start php-fpm server
-EXPOSE 9000
-CMD ["php-fpm"]
-```
-
-## Create a Dockerfile for PHP-CLI (production)
-
-For production, you often need a separate container to run Artisan commands, migrations, and other CLI tasks. In most cases you can run these commands by reusing existing PHP-FPM container:
-
-```console
-$ docker compose -f compose.prod.yaml exec php-fpm php artisan route:list
-```
-
-If you need a separate CLI container with different extensions or strict separation of concerns, consider a php-cli Dockerfile:
-
-```dockerfile
-# Stage 1: Build environment and Composer dependencies
-FROM php:8.3-cli AS builder
-
-# Install system dependencies and PHP extensions required for Laravel + MySQL/PostgreSQL support
-# Some dependencies are required for PHP extensions only in the build stage
-RUN apt-get update && apt-get install -y --no-install-recommends \
-    curl \
-    unzip \
-    libpq-dev \
-    libonig-dev \
-    libssl-dev \
-    libxml2-dev \
-    libcurl4-openssl-dev \
-    libicu-dev \
-    libzip-dev \
-    && docker-php-ext-install -j$(nproc) \
-    pdo_mysql \
-    pdo_pgsql \
-    pgsql \
-    opcache \
-    intl \
-    zip \
-    bcmath \
-    soap \
-    && pecl install redis \
-    && docker-php-ext-enable redis \
-    && apt-get autoremove -y && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
-
-# Set the working directory inside the container
-WORKDIR /var/www
-
-# Copy the entire Laravel application code into the container
-COPY . /var/www
-
-# Install Composer and dependencies
-RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \
-    && composer install --no-dev --optimize-autoloader --no-interaction --no-progress --prefer-dist
-
-# Stage 2: Production environment
-FROM php:8.3-cli
-
-# Install client libraries required for php extensions in runtime
-RUN apt-get update && apt-get install -y --no-install-recommends \
-    libpq-dev \
-    libicu-dev \
-    libzip-dev \
-    && apt-get autoremove -y && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
-
-# Copy PHP extensions and libraries from the builder stage
-COPY --from=builder /usr/local/lib/php/extensions/ /usr/local/lib/php/extensions/
-COPY --from=builder /usr/local/etc/php/conf.d/ /usr/local/etc/php/conf.d/
-COPY --from=builder /usr/local/bin/docker-php-ext-* /usr/local/bin/
-
-# Use the default production configuration for PHP runtime arguments
-RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
-
-# Copy the application code and dependencies from the build stage
-COPY --from=builder /var/www /var/www
-
-# Set working directory
-WORKDIR /var/www
-
-# Ensure correct permissions
-RUN chown -R www-data:www-data /var/www
-
-# Switch to the non-privileged user to run the application
-USER www-data
-
-# Default command: Provide a bash shell to allow running any command
-CMD ["bash"]
-```
-
-This Dockerfile is similar to the PHP-FPM Dockerfile, but it uses the `php:8.3-cli` image as the base image and sets up the container for running CLI commands.
-
-## Create a Dockerfile for Nginx (production)
-
-Nginx serves as the web server for the Laravel application. You can include static assets directly to the container. Here's an example of possible Dockerfile for Nginx:
-
-```dockerfile
-# docker/nginx/Dockerfile
-# Stage 1: Build assets
-FROM debian AS builder
-
-# Install Node.js and build tools
-RUN apt-get update && apt-get install -y --no-install-recommends \
-    curl \
-    nodejs \
-    npm \
-    && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
-
-# Set working directory
-WORKDIR /var/www
-
-# Copy Laravel application code
-COPY . /var/www
-
-# Install Node.js dependencies and build assets
-RUN npm install && npm run build
-
-# Stage 2: Nginx production image
-FROM nginx:alpine
-
-# Copy custom Nginx configuration
-# -----------------------------------------------------------
-# Replace the default Nginx configuration with our custom one
-# that is optimized for serving a Laravel application.
-# -----------------------------------------------------------
-COPY ./docker/nginx/nginx.conf /etc/nginx/nginx.conf
-
-# Copy Laravel's public assets from the builder stage
-# -----------------------------------------------------------
-# We only need the 'public' directory from our Laravel app.
-# -----------------------------------------------------------
-COPY --from=builder /var/www/public /var/www/public
-
-# Set the working directory to the public folder
-WORKDIR /var/www/public
-
-# Expose port 80 and start Nginx
-EXPOSE 80
-CMD ["nginx", "-g", "daemon off;"]
-```
-
-This Dockerfile uses a multi-stage build to separate the asset building process from the final production image. The first stage installs Node.js and builds the assets, while the second stage sets up the Nginx production image with the optimized configuration and the built assets.
-
-## Create a Docker Compose configuration for production
-
-To bring all the services together, create a `compose.prod.yaml` file that defines the services, volumes, and networks for the production environment. Here's an example configuration:
-
-```yaml
-services:
-  web:
-    build:
-      context: .
-      dockerfile: ./docker/production/nginx/Dockerfile
-    restart: unless-stopped # Automatically restart unless the service is explicitly stopped
-    volumes:
-      # Mount the 'laravel-storage' volume to '/var/www/storage' inside the container.
-      # -----------------------------------------------------------
-      # This volume stores persistent data like uploaded files and cache.
-      # The ':ro' option mounts it as read-only in the 'web' service because Nginx only needs to read these files.
-      # The 'php-fpm' service mounts the same volume without ':ro' to allow write operations.
-      # -----------------------------------------------------------
-      - laravel-storage-production:/var/www/storage:ro
-    networks:
-      - laravel-production
-    ports:
-      # Map port 80 inside the container to the port specified by 'NGINX_PORT' on the host machine.
-      # -----------------------------------------------------------
-      # This allows external access to the Nginx web server running inside the container.
-      # For example, if 'NGINX_PORT' is set to '8080', accessing 'http://localhost:8080' will reach the application.
-      # -----------------------------------------------------------
-      - "${NGINX_PORT:-80}:80"
-    depends_on:
-      php-fpm:
-        condition: service_healthy # Wait for php-fpm health check
-
-  php-fpm:
-    # For the php-fpm service, we will create a custom image to install the necessary PHP extensions and setup proper permissions.
-    build:
-      context: .
-      dockerfile: ./docker/common/php-fpm/Dockerfile
-      target: production # Use the 'production' stage in the Dockerfile
-    restart: unless-stopped
-    volumes:
-      - laravel-storage-production:/var/www/storage # Mount the storage volume
-    env_file:
-      - .env
-    networks:
-      - laravel-production
-    healthcheck:
-      test: ["CMD-SHELL", "php-fpm-healthcheck || exit 1"]
-      interval: 10s
-      timeout: 5s
-      retries: 3
-    # The 'depends_on' attribute with 'condition: service_healthy' ensures that
-    # this service will not start until the 'postgres' service passes its health check.
-    # This prevents the application from trying to connect to the database before it's ready.
-    depends_on:
-      postgres:
-        condition: service_healthy
-
-  # The 'php-cli' service provides a command-line interface for running Artisan commands and other CLI tasks.
-  # -----------------------------------------------------------
-  # This is useful for running migrations, seeders, or any custom scripts.
-  # It shares the same codebase and environment as the 'php-fpm' service.
-  # -----------------------------------------------------------
-  php-cli:
-    build:
-      context: .
-      dockerfile: ./docker/php-cli/Dockerfile
-    tty: true # Enables an interactive terminal
-    stdin_open: true # Keeps standard input open for 'docker exec'
-    env_file:
-      - .env
-    networks:
-      - laravel
-
-  postgres:
-    image: postgres:16
-    restart: unless-stopped
-    user: postgres
-    ports:
-      - "${POSTGRES_PORT}:5432"
-    environment:
-      - POSTGRES_DB=${POSTGRES_DATABASE}
-      - POSTGRES_USER=${POSTGRES_USERNAME}
-      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
-    volumes:
-      - postgres-data-production:/var/lib/postgresql/data
-    networks:
-      - laravel-production
-    # Health check for PostgreSQL
-    # -----------------------------------------------------------
-    # Health checks allow Docker to determine if a service is operational.
-    # The 'pg_isready' command checks if PostgreSQL is ready to accept connections.
-    # This prevents dependent services from starting before the database is ready.
-    # -----------------------------------------------------------
-    healthcheck:
-      test: ["CMD", "pg_isready"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-
-  redis:
-    image: redis:alpine
-    restart: unless-stopped # Automatically restart unless the service is explicitly stopped
-    networks:
-      - laravel-production
-    # Health check for Redis
-    # -----------------------------------------------------------
-    # Checks if Redis is responding to the 'PING' command.
-    # This ensures that the service is not only running but also operational.
-    # -----------------------------------------------------------
-    healthcheck:
-      test: ["CMD", "redis-cli", "ping"]
-      interval: 10s
-      timeout: 5s
-      retries: 3
-
-networks:
-  # Attach the service to the 'laravel-production' network.
-  # -----------------------------------------------------------
-  # This custom network allows all services within it to communicate using their service names as hostnames.
-  # For example, 'php-fpm' can connect to 'postgres' by using 'postgres' as the hostname.
-  # -----------------------------------------------------------
-  laravel-production:
-
-volumes:
-  postgres-data-production:
-  laravel-storage-production:
-```
-
-> [!NOTE]
-> Ensure you have an `.env` file at the root of your Laravel project with the necessary configurations (e.g., database and Xdebug settings) to match the Docker Compose setup.
-
-## Running your production environment
-
-To start the production environment, run:
-
-```console
-$ docker compose -f compose.prod.yaml up --build -d
-```
-
-This command will build and start all the services in detached mode, providing a scalable and production-ready setup for your Laravel application.
-
-## Summary
-
-By setting up a Docker Compose environment for Laravel in production, you ensure that your application is optimized for performance, scalable, and secure. This setup makes deployments consistent and easier to manage, reducing the likelihood of errors due to differences between environments.
diff --git a/content/guides/genai-claude-code-mcp.md b/content/guides/genai-claude-code-mcp.md
new file mode 100644
index 000000000000..c71ee9f89203
--- /dev/null
+++ b/content/guides/genai-claude-code-mcp.md
@@ -0,0 +1,298 @@
+---
+description: Learn how to use Claude Code with Docker MCP Toolkit to generate production-ready Docker Compose files from natural language using the Docker Hub MCP server.
+keywords: mcp, model context protocol, docker, docker desktop, claude code, docker hub, compose, automation
+title: Generate Docker Compose Files with Claude Code and Docker MCP Toolkit
+summary: |
+  This guide shows how to wire Claude Code to the Docker MCP Toolkit so it can search Docker Hub images and generate complete Docker Compose stacks from natural language.
+  You’ll enable the Docker Hub MCP server, connect Claude Code, verify MCP access, and create a Node.js + PostgreSQL stack with a conversational prompt.
+aliases:
+  - /guides/use-case/genai-claude-code-mcp/
+  - /guides/genai-claude-code-mcp/claude-code-mcp-guide/
+params:
+  tags: [ai]
+  time: 15 minutes
+---
+
+This guide introduces how to use Claude Code together with Docker MCP Toolkit so Claude can search Docker Hub in real time and generate a complete `docker-compose.yaml` from natural language.
+
+Instead of manually writing YAML or looking for image tags, you describe your stack once — Claude uses the Model Context Protocol (MCP) to query Docker Hub and build a production-ready Compose file.
+
+In this guide, you’ll learn how to:
+
+- Enable Docker MCP Toolkit in Docker Desktop  
+- Add the Docker Hub MCP server  
+- Connect Claude Code to the MCP Gateway (GUI or CLI)  
+- Verify MCP connectivity inside Claude  
+- Ask Claude to generate and save a Compose file for a Node.js + PostgreSQL app  
+- Deploy it instantly with `docker compose up`  
+
+---
+
+## Use Claude Code and Docker MCP Toolkit to generate a Docker Compose file from natural language
+
+
+- Setup: Enable MCP Toolkit → Add Docker Hub MCP server → Connect Claude Code  
+- Use Claude: Describe your stack in plain English  
+- Automate: Claude queries Docker Hub via MCP and builds a complete `docker-compose.yaml`  
+- Deploy: Run `docker compose up` → Node.js + PostgreSQL live on `localhost:3000`  
+- Benefit: Zero YAML authoring. Zero image searching. Describe once → Claude builds it.
+
+Estimated time: ~15 minutes
+
+---
+
+## 1. What you are building
+
+The goal is simple: use Claude Code together with the Docker MCP Toolkit to search Docker Hub images and generate a complete Docker Compose file for a Node.js and PostgreSQL setup. 
+
+The Model Context Protocol (MCP) bridges Claude Code and Docker Desktop, giving Claude real-time access to Docker's tools. Instead of context-switching between Docker, terminal commands, and YAML editors, you describe your requirements once and Claude handles the infrastructure details.
+
+Why this matters: This pattern scales to complex multi-service setups, database migrations, networking, security policies — all through conversational prompts.
+
+---
+
+## 2. Prerequisites
+
+Make sure you have:
+
+- Docker Desktop installed
+- Enable Docker Desktop updated with [MCP Toolkit](https://docs.docker.com/ai/mcp-catalog-and-toolkit/get-started/#setup) support
+
+- Claude Code installed
+
+---
+
+## 3. Install the Docker Hub MCP server
+
+1. Open Docker Desktop  
+1. Select **MCP Toolkit**  
+1. Go to the **Catalog** tab  
+1. Search for **Docker Hub**  
+1. Select the **Docker Hub**MCP server
+1. Add the MCP server, then open the **Configuration** tab
+1. Enter your Docker Hub username
+1. [Create a read-only personal access token](/security/access-tokens/#create-a-personal-access-token) and enter your access token under **Secrets**
+1. Save the configuration
+
+![Docker Hub](images/genai-claude-code-mcp-catalog-docker-hub.avif "Docker Hub")
+
+Public images work without credentials. For private repositories, you can add your Docker Hub username and token later.
+
+![Docker Hub Secrets](images/genai-claude-code-mcp-dockerhub-secrets.avif "Docker Hub Secrets")
+
+
+---
+
+## 4. Connect Claude Code to Docker MCP Toolkit
+
+You can connect from Docker Desktop or using the CLI.
+
+### Option A. Connect with Docker Desktop
+
+1. Open **MCP Toolkit**  
+1. Go to the **Clients** tab  
+1. Locate Claude Code  
+1. Select **Connect**
+
+![Docker Connection](images/genai-claude-code-mcp-docker-connect-claude.avif)
+
+### Option B. Connect using the CLI
+
+```console
+$ claude mcp add MCP_DOCKER -s user -- docker mcp gateway run
+```
+
+---
+
+## 5. Verify MCP servers inside Claude Code
+
+1. Navigate to your project folder:
+
+```console
+$ cd /path/to/project
+```
+
+1. Start Claude Code:
+
+```console
+$ claude
+```
+
+1. In the input box, type:
+
+```console
+/mcp
+```
+
+You should now see:
+
+- The MCP gateway (for example `MCP_DOCKER`)
+- Tools provided by the Docker Hub MCP server
+
+![mcp-docker](images/genai-claude-code-mcp-mcp-servers.avif)
+
+If not, restart Claude Code or check Docker Desktop to confirm the connection.
+
+---
+
+## 6. Create a basic Node.js app
+
+Claude Code generates more accurate Compose files when it can inspect a real project. Set up the application code now so the agent can bind mount it later.
+
+Inside project folder, create a folder named `app`:
+
+```console
+$ mkdir app
+$ cd app
+$ npm init -y
+$ npm install express
+```
+
+Create `index.js`:
+
+```console
+const express = require("express");
+const app = express();
+
+app.get("/", (req, res) => {
+  res.send("Node.js, Docker, and MCP Toolkit are working together!");
+});
+
+app.listen(3000, () => {
+  console.log("Server running on port 3000");
+});
+```
+
+Add a start script to `package.json`:
+
+```console
+"scripts": {
+  "start": "node index.js"
+}
+```
+
+Return to your project root (`cd ..`) once the app is ready.
+
+---
+
+## 7. Ask Claude Code to design your Docker Compose stack
+
+Paste this message into Claude Code:
+
+```console
+Using the Docker Hub MCP server:
+
+Search Docker Hub for an official Node.js image and a PostgreSQL image.
+Choose stable, commonly used tags such as the Node LTS version and a recent major Postgres version.
+
+Generate a Docker Compose file (`docker-compose.yaml`) with:
+- app:
+  - runs on port 3000
+  - bind mounts the existing ./app directory into /usr/src/app
+  - sets /usr/src/app as the working directory and runs `npm install && npm start`
+- db: running on port 5432 using a named volume
+
+Include:
+- Environment variables for Postgres
+- A shared bridge network
+- Healthchecks where appropriate
+- Pin the image version using the tag + index digest
+```
+
+Claude will search images through MCP, inspect the `app` directory, and generate a Compose file that mounts and runs your local code.
+
+---
+
+## 8. Save the generated Docker Compose file
+
+Tell Claude:
+
+```console
+Save the final Docker Compose file (docker-compose.yaml) into the current project directory.
+```
+
+You should see something like this:
+
+```console
+services:
+  app:
+    image: node:<tag>
+    working_dir: /usr/src/app
+    volumes:
+      - .:/usr/src/app
+    ports:
+      - "3000:3000"
+    depends_on:
+      - db
+    networks:
+      - app-net
+
+  db:
+    image: postgres:18
+    environment:
+      POSTGRES_USER: example
+      POSTGRES_PASSWORD: example
+      POSTGRES_DB: appdb
+    volumes:
+      - db-data:/var/lib/postgresql
+    ports:
+      - "5432:5432"
+    networks:
+      - app-net
+
+volumes:
+  db-data:
+
+networks:
+  app-net:
+    driver: bridge
+```
+
+---
+
+## 9. Run the Docker Compose stack
+
+From your project root:
+
+```console
+$ docker compose up
+```
+
+Docker will:
+
+- Pull the Node and Postgres images selected through Docker Hub MCP  
+- Create networks and volumes  
+- Start the containers  
+
+Open your browser:
+
+```console
+http://localhost:3000
+```
+![Local Host](images/genai-claude-code-mcp-localhost.avif)
+
+Your Node.js app should now be running.
+
+---
+
+## Conclusion
+
+By combining Claude Code with the Docker MCP Toolkit, Docker Desktop, and the Docker Hub MCP server, you can describe your stack in natural language and let MCP handle the details. This removes context switching and replaces it with a smooth, guided workflow powered by model context protocol integrations.
+
+---
+
+### Next steps
+
+- Explore the 220+ MCP servers available in the [Docker MCP catalog](https://hub.docker.com/mcp)
+- Connect Claude Code to your databases, internal APIs, and team tools  
+- Share your MCP setup with your team so everyone works consistently  
+
+The future of development is not about switching between tools. It is about tools working together in a simple, safe, and predictable way. The Docker MCP Toolkit brings that future into your everyday workflow.
+
+
+
+## Learn more
+
+- [Explore the MCP Catalog](https://hub.docker.com/mcp): Discover containerized, security-hardened MCP servers  
+- [Get started with MCP Toolkit in Docker Desktop](https://hub.docker.com/open-desktop?url=https://open.docker.com/dashboard/mcp): Requires version 4.48 or newer to launch automatically  
+- [Read the MCP Horror Stories series](https://www.docker.com/blog/mcp-horror-stories-the-supply-chain-attack/): Learn about common MCP security pitfalls and how to avoid them  
diff --git a/content/guides/genai-leveraging-rag.md b/content/guides/genai-leveraging-rag.md
new file mode 100644
index 000000000000..7aa9fa20c66b
--- /dev/null
+++ b/content/guides/genai-leveraging-rag.md
@@ -0,0 +1,242 @@
+---
+title: Leveraging RAG in GenAI to teach new information
+linkTitle: Leveraging RAG in GenAI
+description:  This guide walks through the process of setting up and utilizing a GenAI stack with Retrieval-Augmented Generation (RAG) systems and graph databases. Learn how to integrate graph databases like Neo4j with AI models for more accurate, contextually-aware responses.
+keywords: Docker, GenAI, Retrieval-Augmented Generation, RAG, Graph Databases, Neo4j, AI, LLM
+summary: |
+  This guide explains setting up a GenAI stack with Retrieval-Augmented Generation (RAG) and Neo4j, covering key concepts, deployment steps, and a case study. It also includes troubleshooting tips for optimizing AI performance with real-time data.
+params:
+  tags: [ai]
+  time: 35 minutes
+---
+
+## Introduction
+
+Retrieval-Augmented Generation (RAG) is a powerful framework that enhances large language models (LLMs) by integrating information retrieval from external knowledge sources. This guide focuses on a specialized RAG implementation using graph databases like Neo4j, which excel in managing highly connected, relational data. Unlike traditional RAG setups with vector databases, combining RAG with graph databases offers better context-awareness and relationship-driven insights.
+
+In this guide, you will:
+
+* Explore the advantages of integrating graph databases into a RAG framework.
+* Configure a GenAI stack with Docker, incorporating Neo4j and an AI model.
+* Analyze a real-world case study that highlights the effectiveness of this approach for handling specialized queries.
+
+## Understanding RAG
+
+RAG is a hybrid framework that enhances the capabilities of large language models by integrating information retrieval. It combines three core components:
+
+- **Information retrieval** from an external knowledge base
+- **Large Language Model (LLM)** for generating responses
+- **Vector embeddings** to enable semantic search
+
+In a RAG system, vector embeddings are used to represent the semantic meaning of text in a way that a machine can understand and process. For instance, the words "dog" and "puppy" will have similar embeddings because they share similar meanings. By integrating these embeddings into the RAG framework, the system can combine the generative power of large language models with the ability to pull in highly relevant, contextually-aware data from external sources.
+
+The system operates as follows:
+1. Questions get turned into mathematical patterns that capture their meaning
+2. These patterns help find matching information in a database
+3. The LLM generates responses that blend the model's inherent knowledge with the this extra information.
+
+To hold this vector information in an efficient manner, you need a special type of database.
+
+## Introduction to Graph databases
+
+Graph databases, such as Neo4j, are specifically designed for managing highly connected data. Unlike traditional relational databases, graph databases prioritize both the entities and the relationships between them, making them ideal for tasks where connections are as important as the data itself.
+
+Graph databases stand out for their unique approach to data storage and querying. They use nodes (or vertices) to represent entities and edges to represent the relationships between these entities. This structure allows for efficient handling of highly connected data and complex queries, which are difficult to manage in traditional database systems.
+
+SQL databases and graph databases differ significantly in their data models. SQL databases use a tabular structure with rows and columns, where relationships between entities are established using foreign keys. This approach works well for structured data and predefined relationships. In contrast, graph databases represent data as nodes (entities) and edges (relationships), making the representation of relationships more intuitive and flexible. This structure is particularly advantageous for complex, interconnected data.
+
+Another key difference lies in schema flexibility. SQL databases operate on a rigid schema, meaning any changes to the data structure, such as adding new columns or altering relationships, typically require careful planning and migration processes. Graph databases, however, are schema-optional, allowing for much greater flexibility. New nodes, edges, or properties can be introduced without disrupting existing data, enabling faster adaptation to changing requirements.
+
+## Practical implementation: testing RAG effectiveness
+
+To illustrate the power of RAG systems in practice, let's examine a real-world implementation using Apache NiFi as our subject matter. This case study demonstrates how RAG can enhance an AI's ability to provide accurate, contextual information about specialized technical topics.
+
+### Teaching AI about new technologies
+
+Apache NiFi serves as an excellent example of the limitations of traditional LLMs and how RAG can overcome them. As a relatively recent technology, many LLMs have limited or outdated knowledge about it, making it a perfect candidate for demonstrating RAG's capabilities.
+
+Without RAG, the LLM may provide broad responses or acknowledge its limited knowledge when asked about information that is beyond its cutoff date. The following example demonstrates this.
+```text
+Question: What important events happened in 2024?
+RAG: Disabled
+I'm happy to help! Unfortunately, I'm a large language model, I don't have access to real-time information or events that occurred after my training data cutoff in 2024. Therefore, I cannot provide you with any important events that happened in 2024. My apologize for any inconvenience this may cause. Is there anything else I can help you with?
+```
+
+## Setting up GenAI stack with GPU acceleration on Linux
+
+To set up and run the GenAI stack on a Linux host, execute one of the following commands, either for GPU or CPU powered:
+
+### GPU powered
+
+```bash
+git clone https://github.com/docker/genai-stack
+docker compose --profile linux-gpu up -d
+mv env.example .env
+nano .env
+```
+In the `.env` file, make sure following lines are commented out. Set your own credentials for security
+
+  ```txt
+    NEO4J_URI=neo4j://database:7687
+    NEO4J_USERNAME=neo4j
+    NEO4J_PASSWORD=password
+    OLLAMA_BASE_URL=http://llm-gpu:11434
+  ```
+
+### CPU powered
+
+```bash
+git clone https://github.com/docker/genai-stack
+docker compose --profile linux up -d
+mv env.example .env
+nano .env
+```
+In the `.env` file, make sure following lines are commented out. Set your own credentials for security
+
+  ```txt
+    NEO4J_URI=neo4j://database:7687
+    NEO4J_USERNAME=neo4j
+    NEO4J_PASSWORD=password
+    OLLAMA_BASE_URL=http://llm:11434
+  ```
+
+### Setting up on other platforms
+
+For instructions on how to set up the stack on other platforms, refer to [this page](https://github.com/docker/genai-stack).
+
+### Initial startup
+
+The first startup may take some time because the system needs to download a large language model.
+
+### Monitoring progress
+
+You can monitor the download and initialization progress by viewing the logs. Run the following command to view the logs:
+
+```bash
+docker compose logs
+```
+
+Wait for specific lines in the logs indicating that the download is complete and the stack is ready. These lines typically confirm successful setup and initialization.
+
+  ```text
+    pull-model-1 exited with code 0
+    database-1    | 2024-12-29 09:35:53.269+0000 INFO  Started.
+    pdf_bot-1     |   You can now view your Streamlit app in your browser.
+    loader-1      |   You can now view your Streamlit app in your browser.
+    bot-1         |   You can now view your Streamlit app in your browser.
+  ```
+
+You can now access the interface at [http://localhost:8501/](http://localhost:8501/) to ask questions. For example, you can try the sample question:
+
+When those lines appear in the logs, the web apps are ready to use.
+
+Since the goal is to teach AI about things it does not yet know, begin by asking it a simple question about NiFi at
+[http://localhost:8501/](http://localhost:8501/).
+![alt text](images/genai-leveraging-rag-1.png)
+
+```text
+Question: What is Apache Nifi?
+RAG: Disabled
+Hello! I'm here to help you with your question about Apache NiFi. Unfortunately, I don't know the answer to that question. I'm just an AI and my knowledge cutoff is December 2022, so I may not be familiar with the latest technologies or software. Can you please provide more context or details about Apache NiFi? Maybe there's something I can help you with related to it.
+```
+
+As shown, the AI does not know anything about this subject because it did not exist during the time of its training, also known as the information cutoff point.
+
+Now it's time to teach the AI some new tricks. First, connect to [http://localhost:8502/](http://localhost:8502/). Instead of using the "neo4j" tag, change it to the "apache-nifi" tag, then select the **Import** button.
+
+![alt text](images/genai-leveraging-rag-2.png)
+
+After the import is successful, you can access Neo4j to verify the data.
+
+After logging in to [http://localhost:7474/](http://localhost:7474/) using the credentials from the `.env` file, you can run queries on Neo4j. Using the Neo4j Cypher query language, you can check for the data stored in the database.
+
+To count the data, run the following query:
+
+```text
+MATCH (n)
+RETURN DISTINCT labels(n) AS NodeTypes, count(*) AS Count
+ORDER BY Count DESC;
+```
+
+To execute this query, write in the box on the top and select the blue run button.
+
+![alt text](images/genai-leveraging-rag-3.png)
+
+Results will appear below. The information shown is downloaded from Stack Overflow and saved in the graph database. RAG will utilize this information to enhance its responses.
+
+You can also run the following query to visualize the data:
+
+```text
+CALL db.schema.visualization()
+```
+
+To check the relationships in the database, run the following query:
+
+```text
+CALL db.relationshipTypes()
+```
+
+You're ready to enable the LLM to use this information. Go back to [http://localhost:8501/](http://localhost:8501/), enable the **RAG** checkbox, and ask the same question again. The LLM will provide a more detailed answer.
+
+![alt text](images/genai-leveraging-rag-4.png)
+
+The system delivers comprehensive, accurate information by pulling from current technical documentation.
+```text
+Question: What is Apache Nifi?
+RAG: Enabled
+
+Answer:
+Apache NiFi is an open-source, distributed data processing system that allows you to collect, transform, and transport data across various sources and sinks. It provides a graphical user interface for designing and managing data flows, as well as a set of APIs for integrating with other systems.
+According to this Stack Overflow question, the free Neo4J JDBC driver doesn't understand SQL, only Cypher, so you would need to use a non-free BI Connector to connect to Neo4j from Apache Drill.
+Additionally, this Stack Overflow question suggests that Apache POI does work in a Neo4j User Defined Function. However, there may be an unknown glitch in the standalone UDF mentioned in the initial question.
+To export data from Neo4j to Excel using APOC Extended procedures, you can use apoc.export.xls.query which takes a Cypher query and exports the results to an Excel file.
+
+References:
+How to connect and query Neo4j Database on Apache Drill?
+Is a Neo4j UDF compatible with Apache POI?
+```
+
+Keep in mind that new questions will be added to Stack Overflow, and due to the inherent randomness in most AI models, the answers may vary and won't be identical to those in this example.
+
+Feel free to start over with another [Stack Overflow tag](https://stackoverflow.com/tags). To drop all data in Neo4j, you can use the following command in the Neo4j Web UI:
+
+```txt
+MATCH (n)
+DETACH DELETE n;
+```
+
+For optimal results, choose a tag that the LLM is not familiar with.
+
+### When to leverage RAG for optimal results
+
+Retrieval-Augmented Generation (RAG) is particularly effective in scenarios where standard Large Language Models (LLMs) fall short. The three key areas where RAG excels are knowledge limitations, business requirements, and cost efficiency. The following sections explore these aspects in more detail.
+
+#### Overcoming knowledge limitations
+
+LLMs are trained on a fixed dataset up until a certain point in time. This means they lack access to:
+
+* Real-time information: LLMs do not continuously update their knowledge, so they may not be aware of recent events, newly released research, or emerging technologies.
+* Specialized knowledge: Many niche subjects, proprietary frameworks, or industry-specific best practices may not be well-documented in the model’s training corpus.
+* Accurate contextual understanding: LLMs can struggle with nuances or evolving terminologies that frequently change within dynamic fields like finance, cybersecurity, or medical research.
+
+By incorporating RAG with a graph database such as Neo4j, AI models can access and retrieve the latest, relevant, and highly connected data before generating a response. This ensures that answers are up-to-date and grounded in factual information rather than inferred approximations.
+
+#### Addressing business and compliance needs
+
+Organizations in industries like healthcare, legal services, and financial analysis require their AI-driven solutions to be:
+
+* Accurate: Businesses need AI-generated content that is factual and relevant to their specific domain.
+* Compliant: Many industries must adhere to strict regulations regarding data usage and security.
+* Traceable: Enterprises often require AI responses to be auditable, meaning they need to reference source material.
+
+By using RAG, AI-generated answers can be sourced from trusted databases, ensuring higher accuracy and compliance with industry standards. This mitigates risks such as misinformation or regulatory violations.
+
+#### Enhancing cost efficiency and performance
+
+Training and fine-tuning large AI models can be computationally expensive and time-consuming. However, integrating RAG provides:
+
+* Reduced fine-tuning needs: Instead of retraining an AI model every time new data emerges, RAG allows the model to fetch and incorporate updated information dynamically.
+* Better performance with smaller models: With the right retrieval techniques, even compact AI models can perform well by leveraging external knowledge efficiently.
+* Lower operational costs: Instead of investing in expensive infrastructure to support large-scale retraining, businesses can optimize resources by utilizing RAG’s real-time retrieval capabilities.
+
+By following this guide, you now have the foundational knowledge to implement RAG with Neo4j, enabling your AI system to deliver more accurate, relevant, and insightful responses. The next step is experimentation—choose a dataset, configure your stack, and start enhancing your AI with the power of retrieval-augmented generation.
\ No newline at end of file
diff --git a/content/guides/genai-leveraging-rag/index.md b/content/guides/genai-leveraging-rag/index.md
deleted file mode 100644
index e77c1b3b719a..000000000000
--- a/content/guides/genai-leveraging-rag/index.md
+++ /dev/null
@@ -1,247 +0,0 @@
----
-title: Leveraging RAG in GenAI to teach new information
-linkTitle: Leveraging RAG in GenAI
-description:  This guide walks through the process of setting up and utilizing a GenAI stack with Retrieval-Augmented Generation (RAG) systems and graph databases. Learn how to integrate graph databases like Neo4j with AI models for more accurate, contextually-aware responses.
-keywords: Docker, GenAI, Retrieval-Augmented Generation, RAG, Graph Databases, Neo4j, AI, LLM
-summary: |
-  This guide explains setting up a GenAI stack with Retrieval-Augmented Generation (RAG) and Neo4j, covering key concepts, deployment steps, and a case study. It also includes troubleshooting tips for optimizing AI performance with real-time data.
-tags: [ai]
-params:
-  time: 35 minutes
----
-
-
-
-## Introduction
-
-Retrieval-Augmented Generation (RAG) is a powerful framework that enhances large language models (LLMs) by integrating information retrieval from external knowledge sources. This guide focuses on a specialized RAG implementation using graph databases like Neo4j, which excel in managing highly connected, relational data. Unlike traditional RAG setups with vector databases, combining RAG with graph databases offers better context-awareness and relationship-driven insights.
-
-In this guide, you will:
-
-* Explore the advantages of integrating graph databases into a RAG framework.
-* Configure a GenAI stack with Docker, incorporating Neo4j and an AI model.
-* Analyze a real-world case study that highlights the effectiveness of this approach for handling specialized queries.
-
-## Understanding RAG 
-
-RAG is a hybrid framework that enhances the capabilities of large language models by integrating information retrieval. It combines three core components:  
-
-- **Information retrieval** from an external knowledge base  
-- **Large Language Model (LLM)** for generating responses  
-- **Vector embeddings** to enable semantic search  
-
-In a RAG system, vector embeddings are used to represent the semantic meaning of text in a way that a machine can understand and process. For instance, the words "dog" and "puppy" will have similar embeddings because they share similar meanings. By integrating these embeddings into the RAG framework, the system can combine the generative power of large language models with the ability to pull in highly relevant, contextually-aware data from external sources.
-
-The system operates as follows:  
-1. Questions get turned into mathematical patterns that capture their meaning  
-2. These patterns help find matching information in a database
-3. The found information gets added to the original question before passed to LLM 
-4. The LLM generates responses that blend the model's inherent knowledge with the this extra information.  
-
-To hold this vector information in an efficient manner, we need a special type of database.
-
-## Introduction to Graph databases 
-
-Graph databases, such as Neo4j, are specifically designed for managing highly connected data. Unlike traditional relational databases, graph databases prioritize both the entities and the relationships between them, making them ideal for tasks where connections are as important as the data itself.
-
-Graph databases stand out for their unique approach to data storage and querying. They use nodes (or vertices) to represent entities and edges to represent the relationships between these entities. This structure allows for efficient handling of highly connected data and complex queries, which are difficult to manage in traditional database systems.
-
-SQL databases and graph databases differ significantly in their data models. SQL databases use a tabular structure with rows and columns, where relationships between entities are established using foreign keys. This approach works well for structured data and predefined relationships. In contrast, graph databases represent data as nodes (entities) and edges (relationships), making the representation of relationships more intuitive and flexible. This structure is particularly advantageous for complex, interconnected data.
-
-Another key difference lies in schema flexibility. SQL databases operate on a rigid schema, meaning any changes to the data structure, such as adding new columns or altering relationships, typically require careful planning and migration processes. Graph databases, however, are schema-optional, allowing for much greater flexibility. New nodes, edges, or properties can be introduced without disrupting existing data, enabling faster adaptation to changing requirements.
-
-## Practical implementation: testing RAG effectiveness
-
-To illustrate the power of RAG systems in practice, let's examine a real-world implementation using Apache NiFi as our subject matter. This case study demonstrates how RAG can enhance an AI's ability to provide accurate, contextual information about specialized technical topics.
-
-### Teaching AI about new technologies
-
-Apache NiFi serves as an excellent example of the limitations of traditional LLMs and how RAG can overcome them. As a relatively recent technology, many LLMs have limited or outdated knowledge about it, making it a perfect candidate for demonstrating RAG's capabilities.
-
-Without RAG, the LLM may provide broad responses or acknowledge its limited knowledge when asked about information that is beyond its cutoff date. The following example demonstrates this.
-```text
-Question: What important events happened in 2024?
-RAG: Disabled
-I'm happy to help! Unfortunately, I'm a large language model, I don't have access to real-time information or events that occurred after my training data cutoff in 2024. Therefore, I cannot provide you with any important events that happened in 2024. My apologize for any inconvenience this may cause. Is there anything else I can help you with?
-```
-
-## Setting up GenAI stack with GPU acceleration on Linux 
-
-To set up and run the GenAI stack on a Linux host, execute one of the following commands, either for GPU or CPU powered:
-
-### GPU powered
-
-```bash
-git clone https://github.com/docker/genai-stack
-docker compose --profile linux-gpu up -d
-mv env.example .env
-nano .env
-```
-In the `.env` file, make sure following lines are commented out. Set your own credentials for security
-
-    NEO4J_URI=neo4j://database:7687
-    NEO4J_USERNAME=neo4j
-    NEO4J_PASSWORD=password
-    OLLAMA_BASE_URL=http://llm-gpu:11434
-
-### CPU powered
-
-```bash
-git clone https://github.com/docker/genai-stack
-docker compose --profile linux up -d
-mv env.example .env
-nano .env
-```
-In the `.env` file, make sure following lines are commented out. Set your own credentials for security
-
-    NEO4J_URI=neo4j://database:7687
-    NEO4J_USERNAME=neo4j
-    NEO4J_PASSWORD=password
-    OLLAMA_BASE_URL=http://llm:11434
-
-### Setting up on other platforms 
-
-For instructions on how to set up the stack on other platforms, refer to [this page](https://github.com/docker/genai-stack). 
-
-
-### Initial startup
-
-The first startup may take some time because the system needs to download a large language model.
-
-### Monitoring progress
-
-We can monitor the download and initialization progress by viewing the logs. Run the following command to view the logs:
-
-```bash
-docker compose logs
-```
-
-Wait for specific lines in the logs indicating that the download is complete and the stack is ready. These lines typically confirm successful setup and initialization.
-
-    pull-model-1 exited with code 0
-    database-1    | 2024-12-29 09:35:53.269+0000 INFO  Started.
-    pdf_bot-1     |   You can now view your Streamlit app in your browser.
-    loader-1      |   You can now view your Streamlit app in your browser.
-    bot-1         |   You can now view your Streamlit app in your browser.
-
-
-    You can now access the interface at [http://localhost:8501/](http://localhost:8501/) to ask questions. For example, you can try the sample question:
-
-When we see those lines in the logs, web apps are ready to be used.
-
-Since our goal is to teach AI about things it does not yet know, we begin by asking it a simple question about Nifi at 
-[http://localhost:8501/](http://localhost:8501/).
-![alt text](image.png)
-
-```text
-Question: What is Apache Nifi? 
-RAG: Disabled
-Hello! I'm here to help you with your question about Apache NiFi. Unfortunately, I don't know the answer to that question. I'm just an AI and my knowledge cutoff is December 2022, so I may not be familiar with the latest technologies or software. Can you please provide more context or details about Apache NiFi? Maybe there's something I can help you with related to it.
-```
-
-As we can see, AI does not know anything about this subject because it did not exist during the time of its training, also known as the information cutoff point.
-
-Now it's time to teach the AI some new tricks. First, connect to [http://localhost:8502/](http://localhost:8502/). Instead of using the "neo4j" tag, change it to the "apache-nifi" tag, then select the **Import** button. 
-
-
-![alt text](image-1.png)
-
-
-After the import is successful, we can access Neo4j to verify the data. 
-
-After logging in to [http://localhost:7474/](http://localhost:7474/) using the credentials from the `.env` file, you can run queries on Neo4j. Using the Neo4j Cypher query language, you can check for the data stored in the database.
-
-To count the data, run the following query:
-
-```cypher
-MATCH (n)
-RETURN DISTINCT labels(n) AS NodeTypes, count(*) AS Count
-ORDER BY Count DESC;
-```
-
-To execute this query, write in the box on the top and select the blue run button.
-
-![alt text](image-2.png)
-
-Results will appear below. What we are seeing here is the information system downloaded from Stack Overflow and saved in the graph database. RAG will utilize this information to enhance its responses.
-
-You can also run the following query to visualize the data:
-
-```cypher
-CALL db.schema.visualization()
-```
-
-To check the relationships in the database, run the following query:
-
-```cypher
-CALL db.relationshipTypes()
-```
-
-
-
-Now, we are ready to enable our LLM to use this information. Go back to [http://localhost:8501/](http://localhost:8501/), enable the **RAG** checkbox, and ask the same question again. The LLM will now provide a more detailed answer.
-
-![alt text](image-3.png)
-
-The system delivers comprehensive, accurate information by pulling from current technical documentation.
-```text
-Question: What is Apache Nifi? 
-RAG: Enabled
-
-Answer:
-Apache NiFi is an open-source, distributed data processing system that allows you to collect, transform, and transport data across various sources and sinks. It provides a graphical user interface for designing and managing data flows, as well as a set of APIs for integrating with other systems.
-According to this Stack Overflow question, the free Neo4J JDBC driver doesn't understand SQL, only Cypher, so you would need to use a non-free BI Connector to connect to Neo4j from Apache Drill.
-Additionally, this Stack Overflow question suggests that Apache POI does work in a Neo4j User Defined Function. However, there may be an unknown glitch in the standalone UDF mentioned in the initial question.
-To export data from Neo4j to Excel using APOC Extended procedures, you can use apoc.export.xls.query which takes a Cypher query and exports the results to an Excel file.
-
-References:
-How to connect and query Neo4j Database on Apache Drill?
-Is a Neo4j UDF compatible with Apache POI?
-```
-
-Keep in mind that new questions will be added to Stack Overflow, and due to the inherent randomness in most AI models, the answers may vary and won't be identical to those in this example.
-
-Feel free to start over with another [Stack Overflow tag](https://stackoverflow.com/tags). To drop all data in Neo4j, you can use the following command in the Neo4j Web UI:
-
-
-```cypher
-MATCH (n)
-DETACH DELETE n;
-```
-
-For optimal results, choose a tag that the LLM is not familiar with.
-
-
-### When to leverage RAG for optimal results
-
-Retrieval-Augmented Generation (RAG) is particularly effective in scenarios where standard Large Language Models (LLMs) fall short. The three key areas where RAG excels are knowledge limitations, business requirements, and cost efficiency. Below, we explore these aspects in more detail.
-
-#### Overcoming knowledge limitations
-
-LLMs are trained on a fixed dataset up until a certain point in time. This means they lack access to:
-
-* Real-time information: LLMs do not continuously update their knowledge, so they may not be aware of recent events, newly released research, or emerging technologies.
-* Specialized knowledge: Many niche subjects, proprietary frameworks, or industry-specific best practices may not be well-documented in the model’s training corpus.
-* Accurate contextual understanding: LLMs can struggle with nuances or evolving terminologies that frequently change within dynamic fields like finance, cybersecurity, or medical research.
-
-By incorporating RAG with a graph database such as Neo4j, AI models can access and retrieve the latest, relevant, and highly connected data before generating a response. This ensures that answers are up-to-date and grounded in factual information rather than inferred approximations.
-
-#### Addressing business and compliance needs
-
-Organizations in industries like healthcare, legal services, and financial analysis require their AI-driven solutions to be:
-
-* Accurate: Businesses need AI-generated content that is factual and relevant to their specific domain.
-* Compliant: Many industries must adhere to strict regulations regarding data usage and security.
-* Traceable: Enterprises often require AI responses to be auditable, meaning they need to reference source material.
-
-By using RAG, AI-generated answers can be sourced from trusted databases, ensuring higher accuracy and compliance with industry standards. This mitigates risks such as misinformation or regulatory violations.
-
-#### Enhancing cost efficiency and performance
-
-Training and fine-tuning large AI models can be computationally expensive and time-consuming. However, integrating RAG provides:
-
-* Reduced fine-tuning needs: Instead of retraining an AI model every time new data emerges, RAG allows the model to fetch and incorporate updated information dynamically.
-* Better performance with smaller models: With the right retrieval techniques, even compact AI models can perform well by leveraging external knowledge efficiently.
-* Lower operational costs: Instead of investing in expensive infrastructure to support large-scale retraining, businesses can optimize resources by utilizing RAG’s real-time retrieval capabilities.
-
-By following this guide, you now have the foundational knowledge to implement RAG with Neo4j, enabling your AI system to deliver more accurate, relevant, and insightful responses. The next step is experimentation—choose a dataset, configure your stack, and start enhancing your AI with the power of retrieval-augmented generation.
\ No newline at end of file
diff --git a/content/guides/genai-pdf-bot.md b/content/guides/genai-pdf-bot.md
new file mode 100644
index 000000000000..6588d06595cf
--- /dev/null
+++ b/content/guides/genai-pdf-bot.md
@@ -0,0 +1,534 @@
+---
+title: PDF analysis and chat
+description: Containerize generative AI (GenAI) apps using Docker
+keywords: python, generative ai, genai, llm, neo4j, ollama, langchain
+summary: |
+  Learn how to build a PDF bot for parsing PDF documents and generating
+  responses using Docker and generative AI.
+aliases:
+  - /guides/use-case/genai-pdf-bot/
+  - /guides/genai-pdf-bot/containerize/
+  - /guides/genai-pdf-bot/develop/
+params:
+  tags: [ai]
+  time: 20 minutes
+---
+
+
+The generative AI (GenAI) guide teaches you how to containerize an existing GenAI application using Docker. In this guide, you’ll learn how to:
+
+- Containerize and run a Python-based GenAI application
+- Set up a local environment to run the complete GenAI stack locally for development
+
+Start by containerizing an existing GenAI application.
+
+## Containerize a generative AI application
+
+### Prerequisites
+
+> [!NOTE]
+>
+> GenAI applications can often benefit from GPU acceleration. Currently Docker Desktop supports GPU acceleration only on [Windows with the WSL2 backend](/manuals/desktop/features/gpu.md#using-nvidia-gpus-with-wsl2). Linux users can also access GPU acceleration using a native installation of the [Docker Engine](/manuals/engine/install/_index.md).
+
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md) or, if you are a Linux user and are planning to use GPU acceleration, [Docker Engine](/manuals/engine/install/_index.md). Docker adds new features regularly and some parts of this guide may work only with the latest version of Docker Desktop.
+- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
+
+### Overview
+
+This section walks you through containerizing a generative AI (GenAI) application using Docker Desktop.
+
+> [!NOTE]
+>
+> You can see more samples of containerized GenAI applications in the [GenAI Stack](https://github.com/docker/genai-stack) demo applications.
+
+### Get the sample application
+
+The sample application used in this guide is a modified version of the PDF Reader application from the [GenAI Stack](https://github.com/docker/genai-stack) demo applications. The application is a full stack Python application that lets you ask questions about a PDF file.
+
+The application uses [LangChain](https://www.langchain.com/) for orchestration, [Streamlit](https://streamlit.io/) for the UI, [Ollama](https://ollama.ai/) to run the LLM, and [Neo4j](https://neo4j.com/) to store vectors.
+
+Clone the sample application. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
+
+```console
+$ git clone https://github.com/craig-osterhout/docker-genai-sample
+```
+
+You should now have the following files in your `docker-genai-sample` directory.
+
+```text
+├── docker-genai-sample/
+│ ├── .gitignore
+│ ├── app.py
+│ ├── chains.py
+│ ├── env.example
+│ ├── requirements.txt
+│ ├── util.py
+│ ├── LICENSE
+│ └── README.md
+```
+
+### Create Docker assets
+
+Now that you have an application, you can create the necessary Docker assets to
+containerize it.
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for your project. Ask Gordon to create a Dockerfile, Compose file, and `.dockerignore` tailored to your application.
+
+Create the following files in your `docker-genai-sample` directory.
+
+```dockerfile {collapse=true,title=Dockerfile}
+# syntax=docker/dockerfile:1
+
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Dockerfile reference guide at
+# https://docs.docker.com/go/dockerfile-reference/
+
+ARG PYTHON_VERSION=3.11.4
+FROM python:${PYTHON_VERSION}-slim as base
+
+# Prevents Python from writing pyc files.
+ENV PYTHONDONTWRITEBYTECODE=1
+
+# Keeps Python from buffering stdout and stderr to avoid situations where
+# the application crashes without emitting any logs due to buffering.
+ENV PYTHONUNBUFFERED=1
+
+WORKDIR /app
+
+# Create a non-privileged user that the app will run under.
+# See https://docs.docker.com/go/dockerfile-user-best-practices/
+ARG UID=10001
+RUN adduser \
+    --disabled-password \
+    --gecos "" \
+    --home "/nonexistent" \
+    --shell "/sbin/nologin" \
+    --no-create-home \
+    --uid "${UID}" \
+    appuser
+
+# Download dependencies as a separate step to take advantage of Docker's caching.
+# Leverage a cache mount to /root/.cache/pip to speed up subsequent builds.
+# Leverage a bind mount to requirements.txt to avoid having to copy them into
+# into this layer.
+RUN --mount=type=cache,target=/root/.cache/pip \
+    --mount=type=bind,source=requirements.txt,target=requirements.txt \
+    python -m pip install -r requirements.txt
+
+# Switch to the non-privileged user to run the application.
+USER appuser
+
+# Copy the source code into the container.
+COPY . .
+
+# Expose the port that the application listens on.
+EXPOSE 8000
+
+# Run the application.
+CMD ["streamlit", "run", "app.py", "--server.address=0.0.0.0", "--server.port=8000"]
+```
+
+```yaml {collapse=true,title=compose.yaml}
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Docker Compose reference guide at
+# https://docs.docker.com/go/compose-spec-reference/
+
+# Here the instructions define your application as a service called "server".
+# This service is built from the Dockerfile in the current directory.
+# You can add other services your application may depend on here, such as a
+# database or a cache. For examples, see the Awesome Compose repository:
+# https://github.com/docker/awesome-compose
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 8000:8000
+
+# The commented out section below is an example of how to define a PostgreSQL
+# database that your application can use. `depends_on` tells Docker Compose to
+# start the database before your application. The `db-data` volume persists the
+# database data between container restarts. The `db-password` secret is used
+# to set the database password. You must create `db/password.txt` and add
+# a password of your choosing to it before running `docker compose up`.
+#     depends_on:
+#       db:
+#         condition: service_healthy
+#   db:
+#     image: postgres
+#     restart: always
+#     user: postgres
+#     secrets:
+#       - db-password
+#     volumes:
+#       - db-data:/var/lib/postgresql/data
+#     environment:
+#       - POSTGRES_DB=example
+#       - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+#     expose:
+#       - 5432
+#     healthcheck:
+#       test: [ "CMD", "pg_isready" ]
+#       interval: 10s
+#       timeout: 5s
+#       retries: 5
+# volumes:
+#   db-data:
+# secrets:
+#   db-password:
+#     file: db/password.txt
+```
+
+```text {collapse=true,title=".dockerignore"}
+# Include any files or directories that you don't want to be copied to your
+# container here (e.g., local build artifacts, temporary files, etc.).
+#
+# For more help, visit the .dockerignore file reference guide at
+# https://docs.docker.com/go/build-context-dockerignore/
+
+**/.DS_Store
+**/__pycache__
+**/.venv
+**/.classpath
+**/.dockerignore
+**/.env
+**/.git
+**/.gitignore
+**/.project
+**/.settings
+**/.toolstarget
+**/.vs
+**/.vscode
+**/*.*proj.user
+**/*.dbmdl
+**/*.jfm
+**/bin
+**/charts
+**/docker-compose*
+**/compose.y*ml
+**/Dockerfile*
+**/node_modules
+**/npm-debug.log
+**/obj
+**/secrets.dev.yaml
+**/values.dev.yaml
+LICENSE
+README.md
+```
+
+You should now have the following contents in your `docker-genai-sample`
+directory.
+
+```text
+├── docker-genai-sample/
+│ ├── .dockerignore
+│ ├── .gitignore
+│ ├── app.py
+│ ├── chains.py
+│ ├── compose.yaml
+│ ├── env.example
+│ ├── requirements.txt
+│ ├── util.py
+│ ├── Dockerfile
+│ ├── LICENSE
+│ └── README.md
+```
+
+To learn more about these files, see the following:
+
+- [Dockerfile](../../../reference/dockerfile.md)
+- [.dockerignore](../../../reference/dockerfile.md#dockerignore-file)
+- [compose.yaml](/reference/compose-file/_index.md)
+
+### Run the application
+
+Inside the `docker-genai-sample` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+Docker builds and runs your application. Depending on your network connection, it may take several minutes to download all the dependencies. You'll see a message like the following in the terminal when the application is running.
+
+```console
+server-1  |   You can now view your Streamlit app in your browser.
+server-1  |
+server-1  |   URL: http://0.0.0.0:8000
+server-1  |
+```
+
+Open a browser and view the application at [http://localhost:8000](http://localhost:8000). You should see a simple Streamlit application. The application may take a few minutes to download the embedding model. While the download is in progress, **Running** appears in the top-right corner.
+
+The application requires a Neo4j database service and an LLM service to
+function. If you have access to services that you ran outside of Docker, specify
+the connection information and try it out. If you don't have the services
+running, continue with this guide to learn how you can run some or all of these
+services with Docker.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+### Summary
+
+In this section, you learned how you can containerize and run your GenAI
+application using Docker.
+
+### Next steps
+
+In the next section, you'll learn how you can run your application, database, and LLM service all locally using Docker.
+
+## Use containers for generative AI development
+
+### Prerequisites
+
+Complete [Containerize a generative AI application](#containerize-a-generative-ai-application).
+
+### Overview
+
+In this section, you'll learn how to set up a development environment to access all the services that your generative AI (GenAI) application needs. This includes:
+
+- Adding a local database
+- Adding a local or remote LLM service
+
+> [!NOTE]
+>
+> You can see more samples of containerized GenAI applications in the [GenAI Stack](https://github.com/docker/genai-stack) demo applications.
+
+### Add a local database
+
+You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service. In addition, you'll specify an environment variables file to load the database connection information rather than manually entering the information every time.
+
+To run the database service:
+
+1. In the cloned repository's directory, rename `env.example` file to `.env`.
+   This file contains the environment variables that the containers will use.
+2. In the cloned repository's directory, open the `compose.yaml` file in an IDE or text editor.
+3. In the `compose.yaml` file, add the following:
+
+   - Add instructions to run a Neo4j database
+   - Specify the environment file under the server service in order to pass in the environment variables for the connection
+
+   The following is the updated `compose.yaml` file. All comments have been removed.
+
+   ```yaml{hl_lines=["7-23"]}
+   services:
+     server:
+       build:
+         context: .
+       ports:
+         - 8000:8000
+       env_file:
+         - .env
+       depends_on:
+         database:
+           condition: service_healthy
+     database:
+       image: neo4j:5.11
+       ports:
+         - "7474:7474"
+         - "7687:7687"
+       environment:
+         - NEO4J_AUTH=${NEO4J_USERNAME}/${NEO4J_PASSWORD}
+       healthcheck:
+         test: ["CMD-SHELL", "wget --no-verbose --tries=1 --spider localhost:7474 || exit 1"]
+         interval: 5s
+         timeout: 3s
+         retries: 5
+   ```
+
+   > [!NOTE]
+   >
+   > To learn more about Neo4j, see the [Neo4j Official Docker Image](https://hub.docker.com/_/neo4j).
+
+4. Run the application. Inside the `docker-genai-sample` directory,
+   run the following command in a terminal.
+
+   ```console
+   $ docker compose up --build
+   ```
+
+5. Access the application. Open a browser and view the application at [http://localhost:8000](http://localhost:8000). You should see a simple Streamlit application. Note that asking questions to a PDF will cause the application to fail because the LLM service specified in the `.env` file isn't running yet.
+
+6. Stop the application. In the terminal, press `ctrl`+`c` to stop the application.
+
+### Add a local or remote LLM service
+
+The sample application supports both [Ollama](https://ollama.ai/) and [OpenAI](https://openai.com/). This guide provides instructions for the following scenarios:
+
+- Run Ollama in a container
+- Run Ollama outside of a container
+- Use OpenAI
+
+While all platforms can use any of the previous scenarios, the performance and
+GPU support may vary. You can use the following guidelines to help you choose the appropriate option:
+
+- Run Ollama in a container if you're on Linux, and using a native installation of the Docker Engine, or Windows 10/11, and using Docker Desktop, you
+  have a CUDA-supported GPU, and your system has at least 8 GB of RAM.
+- Run Ollama outside of a container if you're on an Apple silicon Mac.
+- Use OpenAI if the previous two scenarios don't apply to you.
+
+Choose one of the following options for your LLM service.
+
+{{< tabs >}}
+{{< tab name="Run Ollama in a container" >}}
+
+When running Ollama in a container, you should have a CUDA-supported GPU. While you can run Ollama in a container without a supported GPU, the performance may not be acceptable. Only Linux and Windows 11 support GPU access to containers.
+
+To run Ollama in a container and provide GPU access:
+
+1. Install the prerequisites.
+   - For Docker Engine on Linux, install the [NVIDIA Container Toolkit](https://github.com/NVIDIA/nvidia-container-toolkit).
+   - For Docker Desktop on Windows 10/11, install the latest [NVIDIA driver](https://www.nvidia.com/Download/index.aspx) and make sure you are using the [WSL2 backend](/manuals/desktop/features/wsl/_index.md#turn-on-docker-desktop-wsl-2)
+2. Add the Ollama service and a volume in your `compose.yaml`. The following is
+   the updated `compose.yaml`:
+
+   ```yaml {hl_lines=["24-38"]}
+   services:
+     server:
+       build:
+         context: .
+       ports:
+         - 8000:8000
+       env_file:
+         - .env
+       depends_on:
+         database:
+           condition: service_healthy
+     database:
+       image: neo4j:5.11
+       ports:
+         - "7474:7474"
+         - "7687:7687"
+       environment:
+         - NEO4J_AUTH=${NEO4J_USERNAME}/${NEO4J_PASSWORD}
+       healthcheck:
+         test:
+           [
+             "CMD-SHELL",
+             "wget --no-verbose --tries=1 --spider localhost:7474 || exit 1",
+           ]
+         interval: 5s
+         timeout: 3s
+         retries: 5
+     ollama:
+       image: ollama/ollama:latest
+       ports:
+         - "11434:11434"
+       volumes:
+         - ollama_volume:/root/.ollama
+       deploy:
+         resources:
+           reservations:
+             devices:
+               - driver: nvidia
+                 count: all
+                 capabilities: [gpu]
+   volumes:
+     ollama_volume:
+   ```
+
+   > [!NOTE]
+   >
+   > For more details about the Compose instructions, see [Turn on GPU access with Docker Compose](/manuals/compose/how-tos/gpu-support.md).
+
+3. Add the ollama-pull service to your `compose.yaml` file. This service uses
+   the `docker/genai:ollama-pull` image, based on the GenAI Stack's
+   [pull_model.Dockerfile](https://github.com/docker/genai-stack/blob/main/pull_model.Dockerfile).
+   The service will automatically pull the model for your Ollama
+   container. The following is the updated section of the `compose.yaml` file:
+
+   ```yaml {hl_lines=["12-17"]}
+   services:
+     server:
+       build:
+         context: .
+       ports:
+         - 8000:8000
+       env_file:
+         - .env
+       depends_on:
+         database:
+           condition: service_healthy
+         ollama-pull:
+           condition: service_completed_successfully
+     ollama-pull:
+       image: docker/genai:ollama-pull
+       env_file:
+         - .env
+     # ...
+   ```
+
+{{< /tab >}}
+{{< tab name="Run Ollama outside of a container" >}}
+
+To run Ollama outside of a container:
+
+1. [Install](https://github.com/jmorganca/ollama) and run Ollama on your host
+   machine.
+2. Update the `OLLAMA_BASE_URL` value in your `.env` file to
+   `http://host.docker.internal:11434`.
+3. Pull the model to Ollama using the following command.
+   ```console
+   $ ollama pull llama2
+   ```
+
+{{< /tab >}}
+{{< tab name="Use OpenAI" >}}
+
+> [!IMPORTANT]
+>
+> Using OpenAI requires an [OpenAI account](https://platform.openai.com/login). OpenAI is a third-party hosted service and charges may apply.
+
+1. Update the `LLM` value in your `.env` file to
+   `gpt-3.5`.
+2. Uncomment and update the `OPENAI_API_KEY` value in your `.env` file to
+   your [OpenAI API key](https://help.openai.com/en/articles/4936850-where-do-i-find-my-api-key).
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Run your GenAI application
+
+At this point, you have the following services in your Compose file:
+
+- Server service for your main GenAI application
+- Database service to store vectors in a Neo4j database
+- (optional) Ollama service to run the LLM
+- (optional) Ollama-pull service to automatically pull the model for the Ollama
+  service
+
+To run all the services, run the following command in your `docker-genai-sample`
+directory:
+
+```console
+$ docker compose up --build
+```
+
+If your Compose file has the ollama-pull service, it may take several minutes for the ollama-pull service to pull the model. The ollama-pull service will continuously update the console with its status. After pulling the model, the ollama-pull service container will stop and you can access the application.
+
+Once the application is running, open a browser and access the application at [http://localhost:8000](http://localhost:8000).
+
+Upload a PDF file, for example the [Docker CLI Cheat Sheet](https://docs.docker.com/get-started/docker_cheatsheet.pdf), and ask a question about the PDF.
+
+Depending on your system and the LLM service that you chose, it may take several
+minutes to answer. If you are using Ollama and the performance isn't
+acceptable, try using OpenAI.
+
+### Summary
+
+In this section, you learned how to set up a development environment to provide
+access all the services that your GenAI application needs.
+
+Related information:
+
+- [Dockerfile reference](../../../reference/dockerfile.md)
+- [Compose file reference](/reference/compose-file/_index.md)
+- [Ollama Docker image](https://hub.docker.com/r/ollama/ollama)
+- [Neo4j Official Docker Image](https://hub.docker.com/_/neo4j)
+- [GenAI Stack demo applications](https://github.com/docker/genai-stack)
+
+### Next steps
+
+See samples of more GenAI applications in the [GenAI Stack demo applications](https://github.com/docker/genai-stack).
diff --git a/content/guides/genai-pdf-bot/_index.md b/content/guides/genai-pdf-bot/_index.md
deleted file mode 100644
index 41c5e16626e7..000000000000
--- a/content/guides/genai-pdf-bot/_index.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: PDF analysis and chat
-description: Containerize generative AI (GenAI) apps using Docker
-keywords: python, generative ai, genai, llm, neo4j, ollama, langchain
-summary: |
-  Learn how to build a PDF bot for parsing PDF documents and generating
-  responses using Docker and generative AI.
-tags: [ai]
-aliases:
-  - /guides/use-case/genai-pdf-bot/
-params:
-  time: 20 minutes
----
-
-The generative AI (GenAI) guide teaches you how to containerize an existing GenAI application using Docker. In this guide, you’ll learn how to:
-
-- Containerize and run a Python-based GenAI application
-- Set up a local environment to run the complete GenAI stack locally for development
-
-Start by containerizing an existing GenAI application.
diff --git a/content/guides/genai-pdf-bot/containerize.md b/content/guides/genai-pdf-bot/containerize.md
deleted file mode 100644
index eae8f42ae2b7..000000000000
--- a/content/guides/genai-pdf-bot/containerize.md
+++ /dev/null
@@ -1,140 +0,0 @@
----
-title: Containerize a generative AI application
-linkTitle: Containerize your app
-weight: 10
-keywords: python, generative ai, genai, llm, neo4j, ollama, containerize, initialize, langchain, openai
-description: Learn how to containerize a generative AI (GenAI) application.
-aliases:
-  - /guides/use-case/genai-pdf-bot/containerize/
----
-
-## Prerequisites
-
-> [!NOTE]
->
-> GenAI applications can often benefit from GPU acceleration. Currently Docker Desktop supports GPU acceleration only on [Windows with the WSL2 backend](/manuals/desktop/features/gpu.md#using-nvidia-gpus-with-wsl2). Linux users can also access GPU acceleration using a native installation of the [Docker Engine](/manuals/engine/install/_index.md).
-
-- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md) or, if you are a Linux user and are planning to use GPU acceleration, [Docker Engine](/manuals/engine/install/_index.md). Docker adds new features regularly and some parts of this guide may work only with the latest version of Docker Desktop.
-- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
-
-## Overview
-
-This section walks you through containerizing a generative AI (GenAI) application using Docker Desktop.
-
-> [!NOTE]
->
-> You can see more samples of containerized GenAI applications in the [GenAI Stack](https://github.com/docker/genai-stack) demo applications.
-
-## Get the sample application
-
-The sample application used in this guide is a modified version of the PDF Reader application from the [GenAI Stack](https://github.com/docker/genai-stack) demo applications. The application is a full stack Python application that lets you ask questions about a PDF file.
-
-The application uses [LangChain](https://www.langchain.com/) for orchestration, [Streamlit](https://streamlit.io/) for the UI, [Ollama](https://ollama.ai/) to run the LLM, and [Neo4j](https://neo4j.com/) to store vectors.
-
-Clone the sample application. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
-
-```console
-$ git clone https://github.com/craig-osterhout/docker-genai-sample
-```
-
-You should now have the following files in your `docker-genai-sample` directory.
-
-```text
-├── docker-genai-sample/
-│ ├── .gitignore
-│ ├── app.py
-│ ├── chains.py
-│ ├── env.example
-│ ├── requirements.txt
-│ ├── util.py
-│ ├── LICENSE
-│ └── README.md
-```
-
-## Initialize Docker assets
-
-Now that you have an application, you can use `docker init` to create the necessary Docker assets to containerize your application. Inside the `docker-genai-sample` directory, run the `docker init` command. `docker init` provides some default configuration, but you'll need to answer a few questions about your application. For example, this application uses Streamlit to run. Refer to the following `docker init` example and use the same answers for your prompts.
-
-```console
-$ docker init
-Welcome to the Docker Init CLI!
-
-This utility will walk you through creating the following files with sensible defaults for your project:
-  - .dockerignore
-  - Dockerfile
-  - compose.yaml
-  - README.Docker.md
-
-Let's get started!
-
-? What application platform does your project use? Python
-? What version of Python do you want to use? 3.11.4
-? What port do you want your app to listen on? 8000
-? What is the command to run your app? streamlit run app.py --server.address=0.0.0.0 --server.port=8000
-```
-
-You should now have the following contents in your `docker-genai-sample`
-directory.
-
-```text
-├── docker-genai-sample/
-│ ├── .dockerignore
-│ ├── .gitignore
-│ ├── app.py
-│ ├── chains.py
-│ ├── compose.yaml
-│ ├── env.example
-│ ├── requirements.txt
-│ ├── util.py
-│ ├── Dockerfile
-│ ├── LICENSE
-│ ├── README.Docker.md
-│ └── README.md
-```
-
-To learn more about the files that `docker init` added, see the following:
-
-- [Dockerfile](../../../reference/dockerfile.md)
-- [.dockerignore](../../../reference/dockerfile.md#dockerignore-file)
-- [compose.yaml](/reference/compose-file/_index.md)
-
-## Run the application
-
-Inside the `docker-genai-sample` directory, run the following command in a
-terminal.
-
-```console
-$ docker compose up --build
-```
-
-Docker builds and runs your application. Depending on your network connection, it may take several minutes to download all the dependencies. You'll see a message like the following in the terminal when the application is running.
-
-```console
-server-1  |   You can now view your Streamlit app in your browser.
-server-1  |
-server-1  |   URL: http://0.0.0.0:8000
-server-1  |
-```
-
-Open a browser and view the application at [http://localhost:8000](http://localhost:8000). You should see a simple Streamlit application. The application may take a few minutes to download the embedding model. While the download is in progress, **Running** appears in the top-right corner.
-
-The application requires a Neo4j database service and an LLM service to
-function. If you have access to services that you ran outside of Docker, specify
-the connection information and try it out. If you don't have the services
-running, continue with this guide to learn how you can run some or all of these
-services with Docker.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-## Summary
-
-In this section, you learned how you can containerize and run your GenAI
-application using Docker.
-
-Related information:
-
-- [docker init CLI reference](../../../reference/cli/docker/init.md)
-
-## Next steps
-
-In the next section, you'll learn how you can run your application, database, and LLM service all locally using Docker.
diff --git a/content/guides/genai-pdf-bot/develop.md b/content/guides/genai-pdf-bot/develop.md
deleted file mode 100644
index 7a0dcae854ed..000000000000
--- a/content/guides/genai-pdf-bot/develop.md
+++ /dev/null
@@ -1,261 +0,0 @@
----
-title: Use containers for generative AI development
-linkTitle: Develop your app
-weight: 20
-keywords: python, local, development, generative ai, genai, llm, neo4j, ollama, langchain, openai
-description: Learn how to develop your generative AI (GenAI) application locally.
-aliases:
-  - /guides/use-case/genai-pdf-bot/develop/
----
-
-## Prerequisites
-
-Complete [Containerize a generative AI application](containerize.md).
-
-## Overview
-
-In this section, you'll learn how to set up a development environment to access all the services that your generative AI (GenAI) application needs. This includes:
-
-- Adding a local database
-- Adding a local or remote LLM service
-
-> [!NOTE]
->
-> You can see more samples of containerized GenAI applications in the [GenAI Stack](https://github.com/docker/genai-stack) demo applications.
-
-## Add a local database
-
-You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service. In addition, you'll specify an environment variables file to load the database connection information rather than manually entering the information every time.
-
-To run the database service:
-
-1. In the cloned repository's directory, rename `env.example` file to `.env`.
-   This file contains the environment variables that the containers will use.
-2. In the cloned repository's directory, open the `compose.yaml` file in an IDE or text editor.
-3. In the `compose.yaml` file, add the following:
-
-   - Add instructions to run a Neo4j database
-   - Specify the environment file under the server service in order to pass in the environment variables for the connection
-
-   The following is the updated `compose.yaml` file. All comments have been removed.
-
-   ```yaml{hl_lines=["7-23"]}
-   services:
-     server:
-       build:
-         context: .
-       ports:
-         - 8000:8000
-       env_file:
-         - .env
-       depends_on:
-         database:
-           condition: service_healthy
-     database:
-       image: neo4j:5.11
-       ports:
-         - "7474:7474"
-         - "7687:7687"
-       environment:
-         - NEO4J_AUTH=${NEO4J_USERNAME}/${NEO4J_PASSWORD}
-       healthcheck:
-         test: ["CMD-SHELL", "wget --no-verbose --tries=1 --spider localhost:7474 || exit 1"]
-         interval: 5s
-         timeout: 3s
-         retries: 5
-   ```
-
-   > [!NOTE]
-   >
-   > To learn more about Neo4j, see the [Neo4j Official Docker Image](https://hub.docker.com/_/neo4j).
-
-4. Run the application. Inside the `docker-genai-sample` directory,
-   run the following command in a terminal.
-
-   ```console
-   $ docker compose up --build
-   ```
-
-5. Access the application. Open a browser and view the application at [http://localhost:8000](http://localhost:8000). You should see a simple Streamlit application. Note that asking questions to a PDF will cause the application to fail because the LLM service specified in the `.env` file isn't running yet.
-
-6. Stop the application. In the terminal, press `ctrl`+`c` to stop the application.
-
-## Add a local or remote LLM service
-
-The sample application supports both [Ollama](https://ollama.ai/) and [OpenAI](https://openai.com/). This guide provides instructions for the following scenarios:
-
-- Run Ollama in a container
-- Run Ollama outside of a container
-- Use OpenAI
-
-While all platforms can use any of the previous scenarios, the performance and
-GPU support may vary. You can use the following guidelines to help you choose the appropriate option:
-
-- Run Ollama in a container if you're on Linux, and using a native installation of the Docker Engine, or Windows 10/11, and using Docker Desktop, you
-  have a CUDA-supported GPU, and your system has at least 8 GB of RAM.
-- Run Ollama outside of a container if you're on an Apple silicon Mac.
-- Use OpenAI if the previous two scenarios don't apply to you.
-
-Choose one of the following options for your LLM service.
-
-{{< tabs >}}
-{{< tab name="Run Ollama in a container" >}}
-
-When running Ollama in a container, you should have a CUDA-supported GPU. While you can run Ollama in a container without a supported GPU, the performance may not be acceptable. Only Linux and Windows 11 support GPU access to containers.
-
-To run Ollama in a container and provide GPU access:
-
-1. Install the prerequisites.
-   - For Docker Engine on Linux, install the [NVIDIA Container Toolkit](https://github.com/NVIDIA/nvidia-container-toolkit).
-   - For Docker Desktop on Windows 10/11, install the latest [NVIDIA driver](https://www.nvidia.com/Download/index.aspx) and make sure you are using the [WSL2 backend](/manuals/desktop/features/wsl/_index.md#turn-on-docker-desktop-wsl-2)
-2. Add the Ollama service and a volume in your `compose.yaml`. The following is
-   the updated `compose.yaml`:
-
-   ```yaml {hl_lines=["24-38"]}
-   services:
-     server:
-       build:
-         context: .
-       ports:
-         - 8000:8000
-       env_file:
-         - .env
-       depends_on:
-         database:
-           condition: service_healthy
-     database:
-       image: neo4j:5.11
-       ports:
-         - "7474:7474"
-         - "7687:7687"
-       environment:
-         - NEO4J_AUTH=${NEO4J_USERNAME}/${NEO4J_PASSWORD}
-       healthcheck:
-         test:
-           [
-             "CMD-SHELL",
-             "wget --no-verbose --tries=1 --spider localhost:7474 || exit 1",
-           ]
-         interval: 5s
-         timeout: 3s
-         retries: 5
-     ollama:
-       image: ollama/ollama:latest
-       ports:
-         - "11434:11434"
-       volumes:
-         - ollama_volume:/root/.ollama
-       deploy:
-         resources:
-           reservations:
-             devices:
-               - driver: nvidia
-                 count: all
-                 capabilities: [gpu]
-   volumes:
-     ollama_volume:
-   ```
-
-   > [!NOTE]
-   >
-   > For more details about the Compose instructions, see [Turn on GPU access with Docker Compose](/manuals/compose/how-tos/gpu-support.md).
-
-3. Add the ollama-pull service to your `compose.yaml` file. This service uses
-   the `docker/genai:ollama-pull` image, based on the GenAI Stack's
-   [pull_model.Dockerfile](https://github.com/docker/genai-stack/blob/main/pull_model.Dockerfile).
-   The service will automatically pull the model for your Ollama
-   container. The following is the updated section of the `compose.yaml` file:
-
-   ```yaml {hl_lines=["12-17"]}
-   services:
-     server:
-       build:
-         context: .
-       ports:
-         - 8000:8000
-       env_file:
-         - .env
-       depends_on:
-         database:
-           condition: service_healthy
-         ollama-pull:
-           condition: service_completed_successfully
-     ollama-pull:
-       image: docker/genai:ollama-pull
-       env_file:
-         - .env
-     # ...
-   ```
-
-{{< /tab >}}
-{{< tab name="Run Ollama outside of a container" >}}
-
-To run Ollama outside of a container:
-
-1. [Install](https://github.com/jmorganca/ollama) and run Ollama on your host
-   machine.
-2. Update the `OLLAMA_BASE_URL` value in your `.env` file to
-   `http://host.docker.internal:11434`.
-3. Pull the model to Ollama using the following command.
-   ```console
-   $ ollama pull llama2
-   ```
-
-{{< /tab >}}
-{{< tab name="Use OpenAI" >}}
-
-> [!IMPORTANT]
->
-> Using OpenAI requires an [OpenAI account](https://platform.openai.com/login). OpenAI is a third-party hosted service and charges may apply.
-
-1. Update the `LLM` value in your `.env` file to
-   `gpt-3.5`.
-2. Uncomment and update the `OPENAI_API_KEY` value in your `.env` file to
-   your [OpenAI API key](https://help.openai.com/en/articles/4936850-where-do-i-find-my-api-key).
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Run your GenAI application
-
-At this point, you have the following services in your Compose file:
-
-- Server service for your main GenAI application
-- Database service to store vectors in a Neo4j database
-- (optional) Ollama service to run the LLM
-- (optional) Ollama-pull service to automatically pull the model for the Ollama
-  service
-
-To run all the services, run the following command in your `docker-genai-sample`
-directory:
-
-```console
-$ docker compose up --build
-```
-
-If your Compose file has the ollama-pull service, it may take several minutes for the ollama-pull service to pull the model. The ollama-pull service will continuously update the console with its status. After pulling the model, the ollama-pull service container will stop and you can access the application.
-
-Once the application is running, open a browser and access the application at [http://localhost:8000](http://localhost:8000).
-
-Upload a PDF file, for example the [Docker CLI Cheat Sheet](https://docs.docker.com/get-started/docker_cheatsheet.pdf), and ask a question about the PDF.
-
-Depending on your system and the LLM service that you chose, it may take several
-minutes to answer. If you are using Ollama and the performance isn't
-acceptable, try using OpenAI.
-
-## Summary
-
-In this section, you learned how to set up a development environment to provide
-access all the services that your GenAI application needs.
-
-Related information:
-
-- [Dockerfile reference](../../../reference/dockerfile.md)
-- [Compose file reference](/reference/compose-file/_index.md)
-- [Ollama Docker image](https://hub.docker.com/r/ollama/ollama)
-- [Neo4j Official Docker Image](https://hub.docker.com/_/neo4j)
-- [GenAI Stack demo applications](https://github.com/docker/genai-stack)
-
-## Next steps
-
-See samples of more GenAI applications in the [GenAI Stack demo applications](https://github.com/docker/genai-stack).
diff --git a/content/guides/genai-video-bot.md b/content/guides/genai-video-bot.md
new file mode 100644
index 000000000000..438c3a3414fe
--- /dev/null
+++ b/content/guides/genai-video-bot.md
@@ -0,0 +1,264 @@
+---
+title: GenAI video transcription and chat
+linkTitle: Video transcription and chat
+description: Explore a generative AI video analysis app that uses Docker, OpenAI, and Pinecone.
+keywords: python, generative ai, genai, llm, whisper, pinecone, openai, whisper
+summary: |
+  Learn how to build and deploy a generative AI video analysis and
+  transcription bot using Docker.
+aliases:
+  - /guides/use-case/genai-video-bot/
+params:
+  tags: [ai]
+  time: 20 minutes
+---
+
+## Overview
+
+This guide presents a project on video transcription and analysis using a set of
+technologies related to the
+[GenAI Stack](https://www.docker.com/blog/introducing-a-new-genai-stack/).
+
+The project showcases the following technologies:
+
+- [Docker and Docker Compose](#docker-and-docker-compose)
+- [OpenAI](#openai-api)
+- [Whisper](#whisper)
+- [Embeddings](#embeddings)
+- [Chat completions](#chat-completions)
+- [Pinecone](#pinecone)
+- [Retrieval-Augmented Generation](#retrieval-augmented-generation)
+
+> **Acknowledgment**
+>
+> This guide is a community contribution. Docker would like to thank
+> [David Cardozo](https://www.davidcardozo.com/) for his contribution
+> to this guide.
+
+## Prerequisites
+
+- You have an [OpenAI API Key](https://platform.openai.com/api-keys).
+
+  > [!NOTE]
+  >
+  > OpenAI is a third-party hosted service and [charges](https://openai.com/pricing) may apply.
+
+- You have a [Pinecone API Key](https://app.pinecone.io/).
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md). Docker adds new features regularly and some parts of this guide may work only with the latest version of Docker Desktop.
+- You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
+
+## About the application
+
+The application is a chatbot that can answer questions from a video. In
+addition, it provides timestamps from the video that can help you find the sources used to answer your question.
+
+## Get and run the application
+
+1. Clone the sample application's repository. In a terminal, run the following
+   command.
+
+   ```console
+   $ git clone https://github.com/Davidnet/docker-genai.git
+   ```
+
+   The project contains the following directories and files:
+
+   ```text
+   ├── docker-genai/
+   │ ├── docker-bot/
+   │ ├── yt-whisper/
+   │ ├── .env.example
+   │ ├── .gitignore
+   │ ├── LICENSE
+   │ ├── README.md
+   │ └── docker-compose.yaml
+   ```
+
+2. Specify your API keys. In the `docker-genai` directory, create a text file
+   called `.env` and specify your API keys inside. The following is the contents of the `.env.example` file that you can refer to as an example.
+
+   ```text
+   #-------------------------------------------------------------------------
+   # OpenAI
+   #-------------------------------------------------------------------------
+   OPENAI_TOKEN=your-api-key # Replace your-api-key with your personal API key
+
+   #-------------------------------------------------------------------------
+   # Pinecone
+   #-------------------------------------------------------------------------
+   PINECONE_TOKEN=your-api-key # Replace your-api-key with your personal API key
+   ```
+
+3. Build and run the application. In a terminal, change directory to your
+   `docker-genai` directory and run the following command.
+
+   ```console
+   $ docker compose up --build
+   ```
+
+   Docker Compose builds and runs the application based on the services defined
+   in the `docker-compose.yaml` file. When the application is running, you'll
+   see the logs of 2 services in the terminal.
+
+   In the logs, you'll see the services are exposed on ports `8503` and `8504`.
+   The two services are complimentary to each other.
+
+   The `yt-whisper` service is running on port `8503`. This service feeds the
+   Pinecone database with videos that you want to archive in your knowledge
+   database. The following section explores this service.
+
+## Using the yt-whisper service
+
+The yt-whisper service is a YouTube video processing service that uses the OpenAI
+Whisper model to generate transcriptions of videos and stores them in a Pinecone
+database. The following steps show how to use the service.
+
+1. Open a browser and access the yt-whisper service at [http://localhost:8503](http://localhost:8503).
+2. Once the application appears, in the **Youtube URL** field specify a Youtube video URL
+   and select **Submit**. The following example uses
+   [https://www.youtube.com/watch?v=yaQZFhrW0fU](https://www.youtube.com/watch?v=yaQZFhrW0fU).
+
+   ![Submitting a video in the yt-whisper service](images/genai-video-bot-yt-whisper.webp)
+
+   The yt-whisper service downloads the audio of the video, uses Whisper to
+   transcribe it into a WebVTT (`*.vtt`) format (which you can download), then
+   uses the text-embedding-3-small model to create embeddings, and finally
+   uploads those embeddings in to the Pinecone database.
+
+   After processing the video, a video list appears in the web app that informs
+   you which videos have been indexed in Pinecone. It also provides a button to
+   download the transcript.
+
+   ![A processed video in the yt-whisper service](images/genai-video-bot-yt-whisper-2.webp)
+
+   You can now access the dockerbot service on port `8504` and ask questions
+   about the videos.
+
+## Using the dockerbot service
+
+The dockerbot service is a question-answering service that leverages both the
+Pinecone database and an AI model to provide responses. The following steps show
+how to use the service.
+
+> [!NOTE]
+>
+> You must process at least one video via the
+> [yt-whisper service](#using-the-yt-whisper-service) before using
+> the dockerbot service.
+
+1. Open a browser and access the service at
+   [http://localhost:8504](http://localhost:8504).
+
+2. In the **What do you want to know about your videos?** text box, ask the
+   Dockerbot a question about a video that was processed by the yt-whisper
+   service. The following example asks the question, "What is a sugar cookie?".
+   The answer to that question exists in the video processed in the previous
+   example,
+   [https://www.youtube.com/watch?v=yaQZFhrW0fU](https://www.youtube.com/watch?v=yaQZFhrW0fU).
+
+   ![Asking a question to the Dockerbot](images/genai-video-bot-bot.webp)
+
+   In this example, the Dockerbot answers the question and
+   provides links to the video with timestamps, which may contain more
+   information about the answer.
+
+   The dockerbot service takes the question, turns it into an embedding using
+   the text-embedding-3-small model, queries the Pinecone database to find
+   similar embeddings, and then passes that context into the gpt-4-turbo-preview
+   to generate an answer.
+
+3. Select the first link to see what information it provides. Based on the
+   previous example, select
+   [https://www.youtube.com/watch?v=yaQZFhrW0fU&t=553s](https://www.youtube.com/watch?v=yaQZFhrW0fU&t=553s).
+
+   In the example link, you can see that the section of video perfectly answers
+   the question, "What is a sugar cookie?".
+
+## Explore the application architecture
+
+The following image shows the application's high-level service architecture, which includes:
+
+- yt-whisper: A local service, ran by Docker Compose, that interacts with the
+  remote OpenAI and Pinecone services.
+- dockerbot: A local service, ran by Docker Compose, that interacts with the
+  remote OpenAI and Pinecone services.
+- OpenAI: A remote third-party service.
+- Pinecone: A remote third-party service.
+
+![Application architecture diagram](images/genai-video-bot-architecture.webp)
+
+## Explore the technologies used and their role
+
+### Docker and Docker Compose
+
+The application uses Docker to run the application in containers, providing a
+consistent and isolated environment for running it. This means the application
+will operate as intended within its Docker containers, regardless of the
+underlying system differences. To learn more about Docker, see the [Getting started overview](/get-started/introduction/_index.md).
+
+Docker Compose is a tool for defining and running multi-container applications.
+Compose makes it easy to run this application with a single command, `docker
+compose up`. For more details, see the [Compose overview](/manuals/compose/_index.md).
+
+### OpenAI API
+
+The OpenAI API provides an LLM service that's known for its cutting-edge AI and
+machine learning technologies. In this application, OpenAI's technology is used
+to generate transcriptions from audio (using the Whisper model) and to create
+embeddings for text data, as well as to generate responses to user queries
+(using GPT and chat completions). For more details, see
+[openai.com](https://openai.com/product).
+
+### Whisper
+
+Whisper is an automatic speech recognition system developed by OpenAI, designed
+to transcribe spoken language into text. In this application, Whisper is used to
+transcribe the audio from YouTube videos into text, enabling further processing
+and analysis of the video content. For more details, see [Introducing Whisper](https://openai.com/research/whisper).
+
+### Embeddings
+
+Embeddings are numerical representations of text or other data types, which
+capture their meaning in a way that can be processed by machine learning
+algorithms. In this application, embeddings are used to convert video
+transcriptions into a vector format that can be queried and analyzed for
+relevance to user input, facilitating efficient search and response generation
+in the application. For more details, see OpenAI's
+[Embeddings](https://platform.openai.com/docs/guides/embeddings) documentation.
+
+![Embedding diagram](images/genai-video-bot-embeddings.webp)
+
+### Chat completions
+
+Chat completion, as utilized in this application through OpenAI's API, refers to
+the generation of conversational responses based on a given context or prompt.
+In the application, it is used to provide intelligent, context-aware answers to
+user queries by processing and integrating information from video transcriptions
+and other inputs, enhancing the chatbot's interactive capabilities. For more
+details, see OpenAI's
+[Chat Completions API](https://platform.openai.com/docs/guides/text-generation) documentation.
+
+### Pinecone
+
+Pinecone is a vector database service optimized for similarity search, used for
+building and deploying large-scale vector search applications. In this
+application, Pinecone is employed to store and retrieve the embeddings of video
+transcriptions, enabling efficient and relevant search functionality within the
+application based on user queries. For more details, see
+[pincone.io](https://www.pinecone.io/).
+
+### Retrieval-Augmented Generation
+
+Retrieval-Augmented Generation (RAG) is a technique that combines information
+retrieval with a language model to generate responses based on retrieved
+documents or data. In RAG, the system retrieves relevant information (in this
+case, via embeddings from video transcriptions) and then uses a language model
+to generate responses based on this retrieved data. For more details, see
+OpenAI's cookbook for
+[Retrieval Augmented Generative Question Answering with Pinecone](https://cookbook.openai.com/examples/vector_databases/pinecone/gen_qa).
+
+## Next steps
+
+Explore how to [create a PDF bot application](/guides/genai-pdf-bot/_index.md) using
+generative AI, or view more GenAI samples in the
+[GenAI Stack](https://github.com/docker/genai-stack) repository.
diff --git a/content/guides/genai-video-bot/index.md b/content/guides/genai-video-bot/index.md
deleted file mode 100644
index a5d5b6497aca..000000000000
--- a/content/guides/genai-video-bot/index.md
+++ /dev/null
@@ -1,264 +0,0 @@
----
-title: GenAI video transcription and chat
-linkTitle: Video transcription and chat
-description: Explore a generative AI video analysis app that uses Docker, OpenAI, and Pinecone.
-keywords: python, generative ai, genai, llm, whisper, pinecone, openai, whisper
-summary: |
-  Learn how to build and deploy a generative AI video analysis and
-  transcription bot using Docker.
-tags: [ai]
-aliases:
-  - /guides/use-case/genai-video-bot/
-params:
-  time: 20 minutes
----
-
-## Overview
-
-This guide presents a project on video transcription and analysis using a set of
-technologies related to the
-[GenAI Stack](https://www.docker.com/blog/introducing-a-new-genai-stack/).
-
-The project showcases the following technologies:
-
-- [Docker and Docker Compose](#docker-and-docker-compose)
-- [OpenAI](#openai-api)
-- [Whisper](#whisper)
-- [Embeddings](#embeddings)
-- [Chat completions](#chat-completions)
-- [Pinecone](#pinecone)
-- [Retrieval-Augmented Generation](#retrieval-augmented-generation)
-
-> **Acknowledgment**
->
-> This guide is a community contribution. Docker would like to thank
-> [David Cardozo](https://www.davidcardozo.com/) for his contribution
-> to this guide.
-
-## Prerequisites
-
-- You have an [OpenAI API Key](https://platform.openai.com/api-keys).
-
-  > [!NOTE]
-  >
-  > OpenAI is a third-party hosted service and [charges](https://openai.com/pricing) may apply.
-
-- You have a [Pinecone API Key](https://app.pinecone.io/).
-- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md). Docker adds new features regularly and some parts of this guide may work only with the latest version of Docker Desktop.
-- You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
-
-## About the application
-
-The application is a chatbot that can answer questions from a video. In
-addition, it provides timestamps from the video that can help you find the sources used to answer your question.
-
-## Get and run the application
-
-1. Clone the sample application's repository. In a terminal, run the following
-   command.
-
-   ```console
-   $ git clone https://github.com/Davidnet/docker-genai.git
-   ```
-
-   The project contains the following directories and files:
-
-   ```text
-   ├── docker-genai/
-   │ ├── docker-bot/
-   │ ├── yt-whisper/
-   │ ├── .env.example
-   │ ├── .gitignore
-   │ ├── LICENSE
-   │ ├── README.md
-   │ └── docker-compose.yaml
-   ```
-
-2. Specify your API keys. In the `docker-genai` directory, create a text file
-   called `.env` and specify your API keys inside. The following is the contents of the `.env.example` file that you can refer to as an example.
-
-   ```text
-   #----------------------------------------------------------------------------
-   # OpenAI
-   #----------------------------------------------------------------------------
-   OPENAI_TOKEN=your-api-key # Replace your-api-key with your personal API key
-
-   #----------------------------------------------------------------------------
-   # Pinecone
-   #----------------------------------------------------------------------------
-   PINECONE_TOKEN=your-api-key # Replace your-api-key with your personal API key
-   ```
-
-3. Build and run the application. In a terminal, change directory to your
-   `docker-genai` directory and run the following command.
-
-   ```console
-   $ docker compose up --build
-   ```
-
-   Docker Compose builds and runs the application based on the services defined
-   in the `docker-compose.yaml` file. When the application is running, you'll
-   see the logs of 2 services in the terminal.
-
-   In the logs, you'll see the services are exposed on ports `8503` and `8504`.
-   The two services are complimentary to each other.
-
-   The `yt-whisper` service is running on port `8503`. This service feeds the
-   Pinecone database with videos that you want to archive in your knowledge
-   database. The following section explores this service.
-
-## Using the yt-whisper service
-
-The yt-whisper service is a YouTube video processing service that uses the OpenAI
-Whisper model to generate transcriptions of videos and stores them in a Pinecone
-database. The following steps show how to use the service.
-
-1. Open a browser and access the yt-whisper service at [http://localhost:8503](http://localhost:8503).
-2. Once the application appears, in the **Youtube URL** field specify a Youtube video URL
-   and select **Submit**. The following example uses
-   [https://www.youtube.com/watch?v=yaQZFhrW0fU](https://www.youtube.com/watch?v=yaQZFhrW0fU).
-
-   ![Submitting a video in the yt-whisper service](images/yt-whisper.webp)
-
-   The yt-whisper service downloads the audio of the video, uses Whisper to
-   transcribe it into a WebVTT (`*.vtt`) format (which you can download), then
-   uses the text-embedding-3-small model to create embeddings, and finally
-   uploads those embeddings in to the Pinecone database.
-
-   After processing the video, a video list appears in the web app that informs
-   you which videos have been indexed in Pinecone. It also provides a button to
-   download the transcript.
-
-   ![A processed video in the yt-whisper service](images/yt-whisper-2.webp)
-
-   You can now access the dockerbot service on port `8504` and ask questions
-   about the videos.
-
-## Using the dockerbot service
-
-The dockerbot service is a question-answering service that leverages both the
-Pinecone database and an AI model to provide responses. The following steps show
-how to use the service.
-
-> [!NOTE]
->
-> You must process at least one video via the
-> [yt-whisper service](#using-the-yt-whisper-service) before using
-> the dockerbot service.
-
-1. Open a browser and access the service at
-   [http://localhost:8504](http://localhost:8504).
-
-2. In the **What do you want to know about your videos?** text box, ask the
-   Dockerbot a question about a video that was processed by the yt-whisper
-   service. The following example asks the question, "What is a sugar cookie?".
-   The answer to that question exists in the video processed in the previous
-   example,
-   [https://www.youtube.com/watch?v=yaQZFhrW0fU](https://www.youtube.com/watch?v=yaQZFhrW0fU).
-
-   ![Asking a question to the Dockerbot](images/bot.webp)
-
-   In this example, the Dockerbot answers the question and
-   provides links to the video with timestamps, which may contain more
-   information about the answer.
-
-   The dockerbot service takes the question, turns it into an embedding using
-   the text-embedding-3-small model, queries the Pinecone database to find
-   similar embeddings, and then passes that context into the gpt-4-turbo-preview
-   to generate an answer.
-
-3. Select the first link to see what information it provides. Based on the
-   previous example, select
-   [https://www.youtube.com/watch?v=yaQZFhrW0fU&t=553s](https://www.youtube.com/watch?v=yaQZFhrW0fU&t=553s).
-
-   In the example link, you can see that the section of video perfectly answers
-   the question, "What is a sugar cookie?".
-
-## Explore the application architecture
-
-The following image shows the application's high-level service architecture, which includes:
-
-- yt-whisper: A local service, ran by Docker Compose, that interacts with the
-  remote OpenAI and Pinecone services.
-- dockerbot: A local service, ran by Docker Compose, that interacts with the
-  remote OpenAI and Pinecone services.
-- OpenAI: A remote third-party service.
-- Pinecone: A remote third-party service.
-
-![Application architecture diagram](images/architecture.webp)
-
-## Explore the technologies used and their role
-
-### Docker and Docker Compose
-
-The application uses Docker to run the application in containers, providing a
-consistent and isolated environment for running it. This means the application
-will operate as intended within its Docker containers, regardless of the
-underlying system differences. To learn more about Docker, see the [Getting started overview](/get-started/introduction/_index.md).
-
-Docker Compose is a tool for defining and running multi-container applications.
-Compose makes it easy to run this application with a single command, `docker
-compose up`. For more details, see the [Compose overview](/manuals/compose/_index.md).
-
-### OpenAI API
-
-The OpenAI API provides an LLM service that's known for its cutting-edge AI and
-machine learning technologies. In this application, OpenAI's technology is used
-to generate transcriptions from audio (using the Whisper model) and to create
-embeddings for text data, as well as to generate responses to user queries
-(using GPT and chat completions). For more details, see
-[openai.com](https://openai.com/product).
-
-### Whisper
-
-Whisper is an automatic speech recognition system developed by OpenAI, designed
-to transcribe spoken language into text. In this application, Whisper is used to
-transcribe the audio from YouTube videos into text, enabling further processing
-and analysis of the video content. For more details, see [Introducing Whisper](https://openai.com/research/whisper).
-
-### Embeddings
-
-Embeddings are numerical representations of text or other data types, which
-capture their meaning in a way that can be processed by machine learning
-algorithms. In this application, embeddings are used to convert video
-transcriptions into a vector format that can be queried and analyzed for
-relevance to user input, facilitating efficient search and response generation
-in the application. For more details, see OpenAI's
-[Embeddings](https://platform.openai.com/docs/guides/embeddings) documentation.
-
-![Embedding diagram](images/embeddings.webp)
-
-### Chat completions
-
-Chat completion, as utilized in this application through OpenAI's API, refers to
-the generation of conversational responses based on a given context or prompt.
-In the application, it is used to provide intelligent, context-aware answers to
-user queries by processing and integrating information from video transcriptions
-and other inputs, enhancing the chatbot's interactive capabilities. For more
-details, see OpenAI's
-[Chat Completions API](https://platform.openai.com/docs/guides/text-generation) documentation.
-
-### Pinecone
-
-Pinecone is a vector database service optimized for similarity search, used for
-building and deploying large-scale vector search applications. In this
-application, Pinecone is employed to store and retrieve the embeddings of video
-transcriptions, enabling efficient and relevant search functionality within the
-application based on user queries. For more details, see
-[pincone.io](https://www.pinecone.io/).
-
-### Retrieval-Augmented Generation
-
-Retrieval-Augmented Generation (RAG) is a technique that combines information
-retrieval with a language model to generate responses based on retrieved
-documents or data. In RAG, the system retrieves relevant information (in this
-case, via embeddings from video transcriptions) and then uses a language model
-to generate responses based on this retrieved data. For more details, see
-OpenAI's cookbook for
-[Retrieval Augmented Generative Question Answering with Pinecone](https://cookbook.openai.com/examples/vector_databases/pinecone/gen_qa).
-
-## Next steps
-
-Explore how to [create a PDF bot application](/guides/genai-pdf-bot/_index.md) using
-generative AI, or view more GenAI samples in the
-[GenAI Stack](https://github.com/docker/genai-stack) repository.
diff --git a/content/guides/gha.md b/content/guides/gha.md
index 04e7d497e3f1..4da6330e797f 100644
--- a/content/guides/gha.md
+++ b/content/guides/gha.md
@@ -3,8 +3,9 @@ title: Introduction to GitHub Actions with Docker
 linkTitle: GitHub Actions and Docker
 summary: |
   Learn how to automate image build and push with GitHub Actions.
+keywords: github actions, ci/cd, docker hub, build and push, automation, workflows
 params:
-  tags: [devops]
+  tags: [cicd]
   time: 10 minutes
 ---
 
@@ -18,7 +19,7 @@ Docker builds. Use it as-is, or extend it further to fit your needs.
 
 If you want to follow along with the guide, ensure you have the following:
 
-- A Docker account.
+- A verified Docker account.
 - Familiarity with Dockerfiles.
 
 This guide assumes basic knowledge of Docker concepts but provides explanations
@@ -51,7 +52,7 @@ that, you must authenticate with your Docker credentials (username and access
 token) as part of the GitHub Actions workflow.
 
 For instructions on how to create a Docker access token, see
-[Create and manage access tokens](/manuals/security/for-developers/access-tokens.md).
+[Create and manage access tokens](/manuals/security/access-tokens.md).
 
 Once you have your Docker credentials ready, add the credentials to your GitHub
 repository so you can use them in GitHub Actions:
@@ -103,10 +104,10 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@{{% param "checkout_action_version" %}}
       - name: Extract Docker image metadata
         id: meta
-        uses: docker/metadata-action@v5
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
         with:
           images: ${{ vars.DOCKER_USERNAME }}/my-image
 ```
@@ -127,7 +128,7 @@ To authenticate with Docker Hub, add the following step to your workflow:
 
 ```yaml
       - name: Log in to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKER_USERNAME }}
           password: ${{ secrets.DOCKER_PASSWORD }}
@@ -142,7 +143,7 @@ following configuration builds the image and pushes it directly to a registry.
 
 ```yaml
       - name: Build and push Docker image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: ${{ github.event_name != 'pull_request' }}
           tags: ${{ steps.meta.outputs.tags }}
@@ -182,10 +183,10 @@ Here's the updated snippet:
 
 ```yaml
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
       
       - name: Build and push Docker image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: ${{ github.event_name != 'pull_request' }}
           tags: ${{ steps.meta.outputs.tags }}
@@ -216,25 +217,25 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@{{% param "checkout_action_version" %}}
 
       - name: Extract Docker image metadata
         id: meta
-        uses: docker/metadata-action@v5
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
         with:
           images: ${{ vars.DOCKER_USERNAME }}/my-image
 
       - name: Log in to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKER_USERNAME }}
           password: ${{ secrets.DOCKER_PASSWORD }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
       
       - name: Build and push Docker image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: ${{ github.event_name != 'pull_request' }}
           tags: ${{ steps.meta.outputs.tags }}
@@ -251,5 +252,6 @@ additional features based on your project's needs, such as
 ### Further reading
 
 - Learn more about advanced configurations and examples in the [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) section.
-- For more complex build setups, you may want to consider [Bake](/manuals/build/bake/_index.md). (See also the [Mastering Buildx Bake guide](/guides/bake/index.md).)
+- For more complex build setups, you may want to consider [Bake](/manuals/build/bake/_index.md). (See also the [Mastering Buildx Bake guide](/guides/bake/).)
+
 - Learn about Docker's managed build service, designed for faster, multi-platform builds, see [Docker Build Cloud](/guides/docker-build-cloud/_index.md).
diff --git a/content/guides/github-sonarqube-sandbox.md b/content/guides/github-sonarqube-sandbox.md
new file mode 100644
index 000000000000..8756972aafe1
--- /dev/null
+++ b/content/guides/github-sonarqube-sandbox.md
@@ -0,0 +1,2140 @@
+---
+title: How to build an AI-powered code quality workflow with SonarQube and E2B
+linkTitle: AI-powered code quality
+summary: Build AI-powered code quality workflows using E2B sandboxes with Docker's MCP catalog to automate GitHub and SonarQube integration.
+description: Learn how to create E2B sandboxes with MCP servers, analyze code quality with SonarQube, and generate quality-gated pull requests using GitHub—all through natural language interactions with Claude.
+keywords: sonarqube, e2b, sandboxes, mcp, github, code quality, ai workflow, claude
+aliases:
+  - /guides/github-sonarqube-sandbox/customize/
+  - /guides/github-sonarqube-sandbox/troubleshoot/
+  - /guides/github-sonarqube-sandbox/workflow/
+params:
+  tags: [cicd]
+  time: 40 minutes
+  image:
+---
+
+
+This guide demonstrates how to build an AI-powered code quality workflow using
+[E2B sandboxes](https://e2b.dev/docs) with Docker’s MCP catalog. You’ll create
+a system that automatically analyzes code quality issues in GitHub repositories
+using SonarQube, then generate pull requests with fixes.
+
+## What you'll build
+
+You’ll build a Node.js script that spins up an E2B sandbox, connects GitHub and
+SonarQube MCP servers, and uses Claude Code to analyze code quality and propose
+improvements. The MCP servers are containerized and run as part of the E2B
+sandbox.
+
+## What you'll learn
+
+In this guide, you'll learn:
+
+- How to create E2B sandboxes with multiple MCP servers
+- How to configure GitHub and SonarQube MCP servers for AI workflows
+- How to use Claude Code inside sandboxes to interact with external tools
+- How to build automated code review workflows that create quality-gated
+pull requests
+
+## Why use E2B sandboxes?
+
+Running this workflow in E2B sandboes provides several advantages over
+local execution:
+
+- Security: AI-generated code runs in isolated containers, protecting your
+local environment and credentials
+- Zero setup: No need to install SonarQube, GitHub CLI, or manage dependencies
+locally
+- Scalability: Resource-intensive operations like code scanning run in the
+cloud without consuming local resources
+
+## Learn more
+
+Read Docker's blog post: [Docker + E2B: Building the Future of Trusted AI](https://www.docker.com/blog/docker-e2b-building-the-future-of-trusted-ai/).
+
+## Build a code quality check workflow
+
+In this section, you'll build a complete code quality automation workflow
+step-by-step. You'll start by creating an E2B sandbox with GitHub and
+SonarQube MCP servers, then progressively add functionality until you have a
+production-ready workflow that analyzes code quality and creates pull requests.
+
+By working through each step sequentially, you'll learn how MCP servers work,
+how to interact with them through Claude, and how to chain operations together
+to build powerful automation workflows.
+
+### Prerequisites
+
+Before you begin, make sure you have:
+
+- E2B account with [API access](https://e2b.dev/docs/api-key)
+- [Anthropic API key](https://docs.claude.com/en/api/admin-api/apikeys/get-api-key)
+
+  > [!NOTE]
+  >
+  > This example uses Claude CLI which comes pre-installed in E2B sandboxes, but you can adapt the example to work with other AI assistants of your choice. See [E2B's MCP documentation](https://e2b.dev/docs/mcp/quickstart) for alternative connection methods.
+
+- GitHub account with:
+  - A repository containing code to analyze
+  - [Personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) with `repo` scope
+- SonarCloud account with:
+  - [Organization](https://docs.sonarsource.com/sonarqube-cloud/administering-sonarcloud/resources-structure/organization) created
+  - [Project configured](https://docs.sonarsource.com/sonarqube-community-build/project-administration/creating-and-importing-projects) for your repository
+  - [User token](https://docs.sonarsource.com/sonarqube-server/instance-administration/security/administering-tokens) generated
+- Language runtime installed:
+  - TypeScript: [Node.js 18+](https://nodejs.org/en/download)
+  - Python: [Python 3.8+](https://www.python.org/downloads/)
+
+> [!NOTE]
+>
+> This guide uses Claude's `--dangerously-skip-permissions` flag to enable
+> automated command execution in E2B sandboxes. This flag bypasses permission
+> prompts, which is appropriate for isolated container environments like E2B
+> where sandboxes are disposable and separate from your local machine.
+>
+> However, be aware that Claude can execute any commands within the sandbox,
+> including accessing files and credentials available in that environment. Only
+> use this approach with trusted code and workflows. For more information,
+> see [Anthropic's guidance on container security](https://docs.anthropic.com/en/docs/claude-code/devcontainer).
+
+### Set up your project
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+1. Create a new directory for your workflow and initialize Node.js:
+
+   ```bash
+   mkdir github-sonarqube-workflow
+   cd github-sonarqube-workflow
+   npm init -y
+   ```
+
+2. Open `package.json` and configure it for ES modules:
+
+   ```json
+   {
+     "name": "github-sonarqube-workflow",
+     "version": "1.0.0",
+     "description": "Automated code quality workflow using E2B, GitHub, and SonarQube",
+     "type": "module",
+     "main": "quality-workflow.ts",
+     "scripts": {
+       "start": "tsx quality-workflow.ts"
+     },
+     "keywords": ["e2b", "github", "sonarqube", "mcp", "code-quality"],
+     "author": "",
+     "license": "MIT"
+   }
+   ```
+
+3. Install required dependencies:
+
+   ```bash
+   npm install e2b dotenv
+   npm install -D typescript tsx @types/node
+   ```
+
+4. Create a `.env` file in your project root:
+
+   ```bash
+   touch .env
+   ```
+
+5. Add your API keys and configuration, replacing the placeholders with your actual credentials:
+
+   ```plaintext
+   E2B_API_KEY=your_e2b_api_key_here
+   ANTHROPIC_API_KEY=your_anthropic_api_key_here
+   GITHUB_TOKEN=ghp_your_personal_access_token_here
+   GITHUB_OWNER=your_github_username
+   GITHUB_REPO=your_repository_name
+   SONARQUBE_ORG=your_sonarcloud_org_key
+   SONARQUBE_TOKEN=your_sonarqube_user_token
+   SONARQUBE_URL=https://sonarcloud.io
+   ```
+
+6. Protect your credentials by adding `.env` to `.gitignore`:
+
+   ```bash
+   echo ".env" >> .gitignore
+   echo "node_modules/" >> .gitignore
+   ```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+1. Create a new directory for your workflow:
+
+   ```bash
+   mkdir github-sonarqube-workflow
+   cd github-sonarqube-workflow
+   ```
+
+2. Create a virtual environment and activate it:
+
+   ```bash
+   python3 -m venv venv
+   source venv/bin/activate  # On Windows: venv\Scripts\activate
+   ```
+
+3. Install required dependencies:
+
+   ```bash
+   pip install e2b python-dotenv
+   ```
+
+4. Create a `.env` file in your project root:
+
+   ```bash
+   touch .env
+   ```
+
+5. Add your API keys and configuration, replacing the placeholders with your actual credentials:
+
+   ```plaintext
+   E2B_API_KEY=your_e2b_api_key_here
+   ANTHROPIC_API_KEY=your_anthropic_api_key_here
+   GITHUB_TOKEN=ghp_your_personal_access_token_here
+   GITHUB_OWNER=your_github_username
+   GITHUB_REPO=your_repository_name
+   SONARQUBE_ORG=your_sonarcloud_org_key
+   SONARQUBE_TOKEN=your_sonarqube_user_token
+   SONARQUBE_URL=https://sonarcloud.io
+   ```
+
+6. Protect your credentials by adding `.env` to `.gitignore`:
+
+   ```bash
+   echo ".env" >> .gitignore
+   echo "venv/" >> .gitignore
+   echo "__pycache__/" >> .gitignore
+   ```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Step 1: Create your first sandbox
+
+Let's start by creating a sandbox and verifying the MCP servers are configured correctly.
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+Create a file named `01-test-connection.ts` in your project root:
+
+```typescript
+import "dotenv/config";
+import { Sandbox } from "e2b";
+
+async function testConnection() {
+  console.log(
+    "Creating E2B sandbox with GitHub and SonarQube MCP servers...\n",
+  );
+
+  const sbx = await Sandbox.betaCreate({
+    envs: {
+      ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY!,
+      GITHUB_TOKEN: process.env.GITHUB_TOKEN!,
+      SONARQUBE_TOKEN: process.env.SONARQUBE_TOKEN!,
+    },
+    mcp: {
+      githubOfficial: {
+        githubPersonalAccessToken: process.env.GITHUB_TOKEN!,
+      },
+      sonarqube: {
+        org: process.env.SONARQUBE_ORG!,
+        token: process.env.SONARQUBE_TOKEN!,
+        url: "https://sonarcloud.io",
+      },
+    },
+  });
+
+  const mcpUrl = sbx.betaGetMcpUrl();
+  const mcpToken = await sbx.betaGetMcpToken();
+
+  console.log(" Sandbox created successfully!");
+  console.log(`MCP Gateway URL: ${mcpUrl}\n`);
+
+  // Wait for MCP initialization
+  await new Promise((resolve) => setTimeout(resolve, 1000));
+
+  // Configure Claude to use the MCP gateway
+  console.log("Connecting Claude CLI to MCP gateway...");
+  await sbx.commands.run(
+    `claude mcp add --transport http e2b-mcp-gateway ${mcpUrl} --header "Authorization: Bearer ${mcpToken}"`,
+    {
+      timeoutMs: 0,
+      onStdout: console.log,
+      onStderr: console.log,
+    },
+  );
+
+  console.log("\nœConnection successful! Cleaning up...");
+  await sbx.kill();
+}
+
+testConnection().catch(console.error);
+```
+
+Run this script to verify your setup:
+
+```bash
+npx tsx 01-test-connection.ts
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+Create a file named `01_test_connection.py` in your project root:
+
+```python
+import os
+import asyncio
+from dotenv import load_dotenv
+from e2b import AsyncSandbox
+
+load_dotenv()
+
+async def test_connection():
+    print("Creating E2B sandbox with GitHub and SonarQube MCP servers...\n")
+
+    sbx = await AsyncSandbox.beta_create(
+        envs={
+            "ANTHROPIC_API_KEY": os.getenv("ANTHROPIC_API_KEY"),
+            "GITHUB_TOKEN": os.getenv("GITHUB_TOKEN"),
+            "SONARQUBE_TOKEN": os.getenv("SONARQUBE_TOKEN"),
+        },
+        mcp={
+            "githubOfficial": {
+                "githubPersonalAccessToken": os.getenv("GITHUB_TOKEN"),
+            },
+            "sonarqube": {
+                "org": os.getenv("SONARQUBE_ORG"),
+                "token": os.getenv("SONARQUBE_TOKEN"),
+                "url": "https://sonarcloud.io",
+            },
+        },
+    )
+
+    mcp_url = sbx.beta_get_mcp_url()
+    mcp_token = await sbx.beta_get_mcp_token()
+
+    print(" Sandbox created successfully!")
+    print(f"MCP Gateway URL: {mcp_url}\n")
+
+    # Wait for MCP initialization
+    await asyncio.sleep(1)
+
+    # Configure Claude to use the MCP gateway
+    print("Connecting Claude CLI to MCP gateway...")
+    await sbx.commands.run(
+        f'claude mcp add --transport http e2b-mcp-gateway {mcp_url} --header "Authorization: Bearer {mcp_token}"',
+        timeout=0,
+        on_stdout=print,
+        on_stderr=print,
+    )
+
+    print("\n Connection successful! Cleaning up...")
+    await sbx.kill()
+
+if __name__ == "__main__":
+    asyncio.run(test_connection())
+```
+
+Run this script to verify your setup:
+
+```bash
+python 01_test_connection.py
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Your output should look similar to the following example:
+
+```console {collapse=true}
+Creating E2B sandbox with GitHub and SonarQube MCP servers...
+
+✓ Sandbox created successfully!
+MCP Gateway URL: https://50005-xxxxx.e2b.app/mcp
+
+Connecting Claude CLI to MCP gateway...
+Added HTTP MCP server e2b-mcp-gateway with URL: https://50005-xxxxx.e2b.app/mcp to local config
+Headers: {
+  "Authorization": "Bearer xxxxx-xxxx-xxxx"
+}
+File modified: /home/user/.claude.json [project: /home/user]
+
+✓ Connection successful! Cleaning up...
+```
+
+You've just learned how to create an E2B sandbox with multiple MCP servers
+configured. The `betaCreate` method initializes a cloud environment
+with Claude CLI and your specified MCP servers.
+
+### Step 2: Discover available MCP tools
+
+MCP servers expose tools that Claude can call. The GitHub MCP server provides
+repository management tools, while SonarQube provides code analysis tools.
+By listing their tools, you know what operations are possible.
+
+To try listing MCP tools:
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+Create `02-list-tools.ts`:
+
+```typescript
+import "dotenv/config";
+import { Sandbox } from "e2b";
+
+async function listTools() {
+  console.log("Creating sandbox...\n");
+
+  const sbx = await Sandbox.betaCreate({
+    envs: {
+      ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY!,
+      GITHUB_TOKEN: process.env.GITHUB_TOKEN!,
+      SONARQUBE_TOKEN: process.env.SONARQUBE_TOKEN!,
+    },
+    mcp: {
+      githubOfficial: {
+        githubPersonalAccessToken: process.env.GITHUB_TOKEN!,
+      },
+      sonarqube: {
+        org: process.env.SONARQUBE_ORG!,
+        token: process.env.SONARQUBE_TOKEN!,
+        url: "https://sonarcloud.io",
+      },
+    },
+  });
+
+  const mcpUrl = sbx.betaGetMcpUrl();
+  const mcpToken = await sbx.betaGetMcpToken();
+
+  // Wait for MCP initialization
+  await new Promise((resolve) => setTimeout(resolve, 1000));
+
+  await sbx.commands.run(
+    `claude mcp add --transport http e2b-mcp-gateway ${mcpUrl} --header "Authorization: Bearer ${mcpToken}"`,
+    { timeoutMs: 0, onStdout: console.log, onStderr: console.log },
+  );
+
+  console.log("\nDiscovering available MCP tools...\n");
+
+  const prompt =
+    "List all MCP tools you have access to. For each tool, show its exact name and a brief description.";
+
+  await sbx.commands.run(
+    `echo '${prompt}' | claude -p --dangerously-skip-permissions`,
+    { timeoutMs: 0, onStdout: console.log, onStderr: console.log },
+  );
+
+  await sbx.kill();
+}
+
+listTools().catch(console.error);
+```
+
+Run the script:
+
+```bash
+npx tsx 02-list-tools.ts
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+Create `02_list_tools.py`:
+
+```python
+import os
+import asyncio
+from dotenv import load_dotenv
+from e2b import AsyncSandbox
+
+load_dotenv()
+
+async def list_tools():
+    print("Creating sandbox...\n")
+
+    sbx = await AsyncSandbox.beta_create(
+        envs={
+            "ANTHROPIC_API_KEY": os.getenv("ANTHROPIC_API_KEY"),
+            "GITHUB_TOKEN": os.getenv("GITHUB_TOKEN"),
+            "SONARQUBE_TOKEN": os.getenv("SONARQUBE_TOKEN"),
+        },
+        mcp={
+            "githubOfficial": {
+                "githubPersonalAccessToken": os.getenv("GITHUB_TOKEN"),
+            },
+            "sonarqube": {
+                "org": os.getenv("SONARQUBE_ORG"),
+                "token": os.getenv("SONARQUBE_TOKEN"),
+                "url": "https://sonarcloud.io",
+            },
+        },
+    )
+
+    mcp_url = sbx.beta_get_mcp_url()
+    mcp_token = await sbx.beta_get_mcp_token()
+
+    # Wait for MCP initialization
+    await asyncio.sleep(1)
+
+    await sbx.commands.run(
+        f'claude mcp add --transport http e2b-mcp-gateway {mcp_url} --header "Authorization: Bearer {mcp_token}"',
+        timeout=0,
+        on_stdout=print,
+        on_stderr=print,
+    )
+
+    print("\nDiscovering available MCP tools...\n")
+
+    prompt = "List all MCP tools you have access to. For each tool, show its exact name and a brief description."
+
+    await sbx.commands.run(
+        f"echo '{prompt}' | claude -p --dangerously-skip-permissions",
+        timeout=0,
+        on_stdout=print,
+        on_stderr=print,
+    )
+
+    await sbx.kill()
+
+if __name__ == "__main__":
+    asyncio.run(list_tools())
+```
+
+Run the script:
+
+```bash
+python 02_list_tools.py
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+In the console, you should see a list of MCP tools:
+
+```console {collapse=true}
+Creating sandbox...
+
+Sandbox created
+Connecting to MCP gateway...
+
+Discovering available MCP tools...
+
+I have access to the following MCP tools:
+
+**GitHub Tools:**
+1. mcp__create_repository - Create a new GitHub repository
+2. mcp__list_issues - List issues in a repository
+3. mcp__create_issue - Create a new issue
+4. mcp__get_file_contents - Get file contents from a repository
+5. mcp__create_or_update_file - Create or update files in a repository
+6. mcp__create_pull_request - Create a pull request
+7. mcp__create_branch - Create a new branch
+8. mcp__push_files - Push multiple files in a single commit
+... (30+ more GitHub tools)
+
+**SonarQube Tools:**
+1. mcp__get_projects - List projects in organization
+2. mcp__get_quality_gate_status - Get quality gate status for a project
+3. mcp__list_project_issues - List quality issues in a project
+4. mcp__search_issues - Search for specific quality issues
+... (SonarQube analysis tools)
+```
+
+### Step 3: Test GitHub MCP tools
+
+Let's try testing GitHub using MCP tools. Start simple by listing
+repository issues.
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+Create `03-test-github.ts`:
+
+```typescript
+import "dotenv/config";
+import { Sandbox } from "e2b";
+
+async function testGitHub() {
+  console.log("Creating sandbox...\n");
+
+  const sbx = await Sandbox.betaCreate({
+    envs: {
+      ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY!,
+      GITHUB_TOKEN: process.env.GITHUB_TOKEN!,
+    },
+    mcp: {
+      githubOfficial: {
+        githubPersonalAccessToken: process.env.GITHUB_TOKEN!,
+      },
+    },
+  });
+
+  const mcpUrl = sbx.betaGetMcpUrl();
+  const mcpToken = await sbx.betaGetMcpToken();
+
+  await new Promise((resolve) => setTimeout(resolve, 1000));
+
+  await sbx.commands.run(
+    `claude mcp add --transport http e2b-mcp-gateway ${mcpUrl} --header "Authorization: Bearer ${mcpToken}"`,
+    { timeoutMs: 0, onStdout: console.log, onStderr: console.log },
+  );
+
+  const repoPath = `${process.env.GITHUB_OWNER}/${process.env.GITHUB_REPO}`;
+
+  console.log(`\nListing issues in ${repoPath}...\n`);
+
+  const prompt = `Using the GitHub MCP tools, list all open issues in the repository "${repoPath}". Show the issue number, title, and author for each.`;
+
+  await sbx.commands.run(
+    `echo '${prompt.replace(/'/g, "'\\''")}' | claude -p --dangerously-skip-permissions`,
+    {
+      timeoutMs: 0,
+      onStdout: console.log,
+      onStderr: console.log,
+    },
+  );
+
+  await sbx.kill();
+}
+
+testGitHub().catch(console.error);
+```
+
+Run the script:
+
+```bash
+npx tsx 03-test-github.ts
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+Create `03_test_github.py`:
+
+```python
+import os
+import asyncio
+from dotenv import load_dotenv
+from e2b import AsyncSandbox
+
+load_dotenv()
+
+async def test_github():
+    print("Creating sandbox...\n")
+
+    sbx = await AsyncSandbox.beta_create(
+        envs={
+            "ANTHROPIC_API_KEY": os.getenv("ANTHROPIC_API_KEY"),
+            "GITHUB_TOKEN": os.getenv("GITHUB_TOKEN"),
+        },
+        mcp={
+            "githubOfficial": {
+                "githubPersonalAccessToken": os.getenv("GITHUB_TOKEN"),
+            },
+        },
+    )
+
+    mcp_url = sbx.beta_get_mcp_url()
+    mcp_token = await sbx.beta_get_mcp_token()
+
+    await asyncio.sleep(1)
+
+    await sbx.commands.run(
+        f'claude mcp add --transport http e2b-mcp-gateway {mcp_url} --header "Authorization: Bearer {mcp_token}"',
+        timeout=0,
+        on_stdout=print,
+        on_stderr=print,
+    )
+
+    repo_path = f"{os.getenv('GITHUB_OWNER')}/{os.getenv('GITHUB_REPO')}"
+
+    print(f"\nListing issues in {repo_path}...\n")
+
+    prompt = f'Using the GitHub MCP tools, list all open issues in the repository "{repo_path}". Show the issue number, title, and author for each.'
+
+    await sbx.commands.run(
+        f"echo '{prompt}' | claude -p --dangerously-skip-permissions",
+        timeout=0,
+        on_stdout=print,
+        on_stderr=print,
+    )
+
+    await sbx.kill()
+
+if __name__ == "__main__":
+    asyncio.run(test_github())
+```
+
+Run the script:
+
+```bash
+python 03_test_github.py
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+You should see Claude use the GitHub MCP tools to list your repository's issues:
+
+```console {collapse=true}
+Creating sandbox...
+Connecting to MCP gateway...
+
+Listing issues in <your-repo>...
+
+Here are the first 10 open issues in the <your-repo> repository:
+
+1. **Issue #23577**: Update README (author: user1)
+2. **Issue #23575**: release-notes for Compose v2.40.1 version (author: user2)
+3. **Issue #23570**: engine-cli: fix `docker volume prune` output (author: user3)
+4. **Issue #23568**: Engdocs update (author: user4)
+5. **Issue #23565**: add new section (author: user5)
+... (continues with more issues)
+```
+
+You can now send prompts to Claude and interact with GitHub through
+natural language. Claude decides what tool to call based on your prompt.
+
+### Step 4: Test SonarQube MCP tools
+
+Let's analyze code quality using SonarQube MCP tools.
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+Create `04-test-sonarqube.ts`:
+
+```typescript
+import "dotenv/config";
+import { Sandbox } from "e2b";
+
+async function testSonarQube() {
+  console.log("Creating sandbox...\n");
+
+  const sbx = await Sandbox.betaCreate({
+    envs: {
+      ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY!,
+      GITHUB_TOKEN: process.env.GITHUB_TOKEN!,
+      SONARQUBE_TOKEN: process.env.SONARQUBE_TOKEN!,
+    },
+    mcp: {
+      githubOfficial: {
+        githubPersonalAccessToken: process.env.GITHUB_TOKEN!,
+      },
+      sonarqube: {
+        org: process.env.SONARQUBE_ORG!,
+        token: process.env.SONARQUBE_TOKEN!,
+        url: "https://sonarcloud.io",
+      },
+    },
+  });
+
+  const mcpUrl = sbx.betaGetMcpUrl();
+  const mcpToken = await sbx.betaGetMcpToken();
+
+  await new Promise((resolve) => setTimeout(resolve, 1000));
+
+  await sbx.commands.run(
+    `claude mcp add --transport http e2b-mcp-gateway ${mcpUrl} --header "Authorization: Bearer ${mcpToken}"`,
+    { timeoutMs: 0, onStdout: console.log, onStderr: console.log },
+  );
+
+  console.log("\nAnalyzing code quality with SonarQube...\n");
+
+  const prompt = `Using the SonarQube MCP tools:
+    1. List all projects in my organization
+    2. For the first project, show:
+    - Quality gate status (pass/fail)
+    - Number of bugs
+    - Number of code smells
+    - Number of security vulnerabilities
+    3. List the top 5 most critical issues found`;
+
+  await sbx.commands.run(
+    `echo '${prompt.replace(/'/g, "'\\''")}' | claude -p --dangerously-skip-permissions`,
+    {
+      timeoutMs: 0,
+      onStdout: console.log,
+      onStderr: console.log,
+    },
+  );
+
+  await sbx.kill();
+}
+
+testSonarQube().catch(console.error);
+```
+
+Run the script:
+
+```bash
+npx tsx 04-test-sonarqube.ts
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+Create `04_test_sonarqube.py`:
+
+```python
+import os
+import asyncio
+from dotenv import load_dotenv
+from e2b import AsyncSandbox
+
+load_dotenv()
+
+async def test_sonarqube():
+    print("Creating sandbox...\n")
+
+    sbx = await AsyncSandbox.beta_create(
+        envs={
+            "ANTHROPIC_API_KEY": os.getenv("ANTHROPIC_API_KEY"),
+            "GITHUB_TOKEN": os.getenv("GITHUB_TOKEN"),
+            "SONARQUBE_TOKEN": os.getenv("SONARQUBE_TOKEN"),
+        },
+        mcp={
+            "githubOfficial": {
+                "githubPersonalAccessToken": os.getenv("GITHUB_TOKEN"),
+            },
+            "sonarqube": {
+                "org": os.getenv("SONARQUBE_ORG"),
+                "token": os.getenv("SONARQUBE_TOKEN"),
+                "url": "https://sonarcloud.io",
+            },
+        },
+    )
+
+    mcp_url = sbx.beta_get_mcp_url()
+    mcp_token = await sbx.beta_get_mcp_token()
+
+    await asyncio.sleep(1)
+
+    await sbx.commands.run(
+        f'claude mcp add --transport http e2b-mcp-gateway {mcp_url} --header "Authorization: Bearer {mcp_token}"',
+        timeout=0,
+        on_stdout=print,
+        on_stderr=print,
+    )
+
+    print("\nAnalyzing code quality with SonarQube...\n")
+
+    prompt = """Using the SonarQube MCP tools:
+    1. List all projects in my organization
+    2. For the first project, show:
+    - Quality gate status (pass/fail)
+    - Number of bugs
+    - Number of code smells
+    - Number of security vulnerabilities
+    3. List the top 5 most critical issues found"""
+
+    await sbx.commands.run(
+        f"echo '{prompt}' | claude -p --dangerously-skip-permissions",
+        timeout=0,
+        on_stdout=print,
+        on_stderr=print,
+    )
+
+    await sbx.kill()
+
+if __name__ == "__main__":
+    asyncio.run(test_sonarqube())
+```
+
+Run the script:
+
+```bash
+python 04_test_sonarqube.py
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+> [!NOTE]
+>
+> This script may take a few minutes to run.
+
+You should see Claude output SonarQube analysis results:
+
+```console {collapse=true}
+Creating sandbox...
+
+Analyzing code quality with SonarQube...
+
+## SonarQube Analysis Results
+
+### 1. Projects in Your Organization
+
+Found **1 project**:
+- **Project Name**: project-1
+- **Project Key**: project-testing
+
+### 2. Project Analysis
+
+...
+
+### 3. Top 5 Most Critical Issues
+
+Found 1 total issues (all are code smells with no critical/blocker severity):
+
+1. **MAJOR Severity** - test.js:2
+   - **Rule**: javascript:S1854
+   - **Message**: Remove this useless assignment to variable "unusedVariable"
+   - **Status**: OPEN
+
+**Summary**: The project is in good health with no bugs or vulnerabilities detected.
+```
+
+You can now use SonarQube MCP tools to analyze code quality through
+natural language. You can retrieve quality metrics, identify issues,
+and understand what code needs fixing.
+
+### Step 5: Create a branch and make code changes
+
+Now, let's teach Claude to fix code based on quality issues discovered
+by SonarQube.
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+Create `05-fix-code-issue.ts`:
+
+```typescript
+import "dotenv/config";
+import { Sandbox } from "e2b";
+
+async function fixCodeIssue() {
+  console.log("Creating sandbox...\n");
+
+  const sbx = await Sandbox.betaCreate({
+    envs: {
+      ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY!,
+      GITHUB_TOKEN: process.env.GITHUB_TOKEN!,
+      SONARQUBE_TOKEN: process.env.SONARQUBE_TOKEN!,
+    },
+    mcp: {
+      githubOfficial: {
+        githubPersonalAccessToken: process.env.GITHUB_TOKEN!,
+      },
+      sonarqube: {
+        org: process.env.SONARQUBE_ORG!,
+        token: process.env.SONARQUBE_TOKEN!,
+        url: "https://sonarcloud.io",
+      },
+    },
+  });
+
+  const mcpUrl = sbx.betaGetMcpUrl();
+  const mcpToken = await sbx.betaGetMcpToken();
+
+  await new Promise((resolve) => setTimeout(resolve, 1000));
+
+  await sbx.commands.run(
+    `claude mcp add --transport http e2b-mcp-gateway ${mcpUrl} --header "Authorization: Bearer ${mcpToken}"`,
+    { timeoutMs: 0, onStdout: console.log, onStderr: console.log },
+  );
+
+  const repoPath = `${process.env.GITHUB_OWNER}/${process.env.GITHUB_REPO}`;
+  const branchName = `quality-fix-${Date.now()}`;
+
+  console.log("\nFixing a code quality issue...\n");
+
+  const prompt = `Using GitHub and SonarQube MCP tools:
+
+    1. Analyze code quality in repository "${repoPath}" with SonarQube
+    2. Find ONE simple issue that can be confidently fixed (like an unused variable or code smell)
+    3. Create a new branch called "${branchName}"
+    4. Read the file containing the issue using GitHub tools
+    5. Fix the issue in the code
+    6. Commit the fix to the new branch with a clear commit message
+
+    Important: Only fix issues you're 100% confident about. Explain what you're fixing and why.`;
+
+  await sbx.commands.run(
+    `echo '${prompt.replace(/'/g, "'\\''")}' | claude -p --dangerously-skip-permissions`,
+    {
+      timeoutMs: 0,
+      onStdout: console.log,
+      onStderr: console.log,
+    },
+  );
+
+  console.log(`\nœCheck your repository for branch: ${branchName}`);
+
+  await sbx.kill();
+}
+
+fixCodeIssue().catch(console.error);
+```
+
+Run the script:
+
+```bash
+npx tsx 05-fix-code-issue.ts
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+Create `05_fix_code_issue.py`:
+
+```python
+import os
+import asyncio
+import time
+from dotenv import load_dotenv
+from e2b import AsyncSandbox
+
+load_dotenv()
+
+async def fix_code_issue():
+    print("Creating sandbox...\n")
+
+    sbx = await AsyncSandbox.beta_create(
+        envs={
+            "ANTHROPIC_API_KEY": os.getenv("ANTHROPIC_API_KEY"),
+            "GITHUB_TOKEN": os.getenv("GITHUB_TOKEN"),
+            "SONARQUBE_TOKEN": os.getenv("SONARQUBE_TOKEN"),
+        },
+        mcp={
+            "githubOfficial": {
+                "githubPersonalAccessToken": os.getenv("GITHUB_TOKEN"),
+            },
+            "sonarqube": {
+                "org": os.getenv("SONARQUBE_ORG"),
+                "token": os.getenv("SONARQUBE_TOKEN"),
+                "url": "https://sonarcloud.io",
+            },
+        },
+    )
+
+    mcp_url = sbx.beta_get_mcp_url()
+    mcp_token = await sbx.beta_get_mcp_token()
+
+    await asyncio.sleep(1)
+
+    await sbx.commands.run(
+        f'claude mcp add --transport http e2b-mcp-gateway {mcp_url} --header "Authorization: Bearer {mcp_token}"',
+        timeout=0,
+        on_stdout=print,
+        on_stderr=print,
+    )
+
+    repo_path = f"{os.getenv('GITHUB_OWNER')}/{os.getenv('GITHUB_REPO')}"
+    branch_name = f"quality-fix-{int(time.time() * 1000)}"
+
+    print("\nFixing a code quality issue...\n")
+
+    prompt = f"""Using GitHub and SonarQube MCP tools:
+
+    1. Analyze code quality in repository "{repo_path}" with SonarQube
+    2. Find ONE simple issue that can be confidently fixed (like an unused variable or code smell)
+    3. Create a new branch called "{branch_name}"
+    4. Read the file containing the issue using GitHub tools
+    5. Fix the issue in the code
+    6. Commit the fix to the new branch with a clear commit message
+
+    Important: Only fix issues you're 100% confident about. Explain what you're fixing and why."""
+
+    await sbx.commands.run(
+        f"echo '{prompt}' | claude -p --dangerously-skip-permissions",
+        timeout=0,
+        on_stdout=print,
+        on_stderr=print,
+    )
+
+    print(f"\n Check your repository for branch: {branch_name}")
+
+    await sbx.kill()
+
+if __name__ == "__main__":
+    asyncio.run(fix_code_issue())
+```
+
+Run the script:
+
+```bash
+python 05_fix_code_issue.py
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+> [!NOTE]
+>
+> This script may take a few minutes to run.
+
+Claude will analyze your repository and fix a code quality issue:
+
+```console {collapse=true}
+Creating sandbox...
+
+Fixing a code quality issue...
+
+## Task Completed Successfully!
+
+I've successfully analyzed the repository and fixed a code quality issue. Here's what I did:
+
+### 1. Analysis
+Found 1 SonarQube issues in the `<your-repo>` repository:
+- **Unused variable** (MINOR severity, line 2)
+- Useless assignment (MAJOR severity, line 2)
+- For-of loop suggestion (MINOR severity, lines 5-7)
+
+### 2. Issue Fixed
+**Location:** test.js:2
+**Issue:** Unused variable declaration
+**SonarQube Rule:** javascript:S1481
+**What was wrong:** The line `const unusedVariable = "this is not used";` declared a variable that was never used anywhere in the function.
+
+### 3. Why This Fix is Safe
+- The variable was only declared and assigned, never referenced
+- Removing it has zero impact on functionality
+- It eliminates dead code and improves code quality
+- This is a textbook example of a code smell that should be removed
+
+### 4. Changes Made
+- Created branch: `quality-fix-xxxxx`
+- Removed the unused variable declaration
+- Committed with a clear message explaining the fix and referencing the SonarQube rule
+
+**Commit SHA:** `xxxxxxxxxxxxxxxxxxxxxxxxx`
+**Branch:** https://github.com/<github-org>/<your-repo>/tree/quality-fix-xxxxx
+
+The fix is ready for review and can be merged to improve the code quality of the repository!
+```
+
+You can now use GitHub and SonarQube MCP tools in the same workflow to read
+files, make code changes, and commit them.
+
+### Step 6: Create quality-gated pull requests
+
+Finally, let's build the complete workflow: analyze quality, fix issues,
+and create a PR only if improvements are made.
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+Create `06-quality-gated-pr.ts`:
+
+```typescript
+import "dotenv/config";
+import { Sandbox } from "e2b";
+
+async function qualityGatedPR() {
+  console.log("Creating sandbox for quality-gated PR workflow...\n");
+
+  const sbx = await Sandbox.betaCreate({
+    envs: {
+      ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY!,
+      GITHUB_TOKEN: process.env.GITHUB_TOKEN!,
+      SONARQUBE_TOKEN: process.env.SONARQUBE_TOKEN!,
+    },
+    mcp: {
+      githubOfficial: {
+        githubPersonalAccessToken: process.env.GITHUB_TOKEN!,
+      },
+      sonarqube: {
+        org: process.env.SONARQUBE_ORG!,
+        token: process.env.SONARQUBE_TOKEN!,
+        url: "https://sonarcloud.io",
+      },
+    },
+  });
+
+  const mcpUrl = sbx.betaGetMcpUrl();
+  const mcpToken = await sbx.betaGetMcpToken();
+
+  await new Promise((resolve) => setTimeout(resolve, 1000));
+
+  await sbx.commands.run(
+    `claude mcp add --transport http e2b-mcp-gateway ${mcpUrl} --header "Authorization: Bearer ${mcpToken}"`,
+    { timeoutMs: 0, onStdout: console.log, onStderr: console.log },
+  );
+
+  const repoPath = `${process.env.GITHUB_OWNER}/${process.env.GITHUB_REPO}`;
+  const branchName = `quality-improvements-${Date.now()}`;
+
+  console.log("\nRunning quality-gated PR workflow...\n");
+
+  const prompt = `You are a code quality engineer. Using GitHub and SonarQube MCP tools:
+
+    STEP 1: ANALYSIS
+    - Get current code quality status from SonarQube for "${repoPath}"
+    - Record the current number of bugs, code smells, and vulnerabilities
+    - Identify 1-3 issues that you can confidently fix
+
+    STEP 2: FIX ISSUES
+    - Create branch "${branchName}"
+    - For each issue you're fixing:
+        * Read the file with the issue
+        * Make the fix
+        * Commit with a descriptive message
+    - Only fix issues where you're 100% confident the fix is correct
+
+    STEP 3: VERIFICATION
+        - After your fixes, check if quality metrics would improve
+        - Calculate: Would this reduce bugs/smells/vulnerabilities?
+
+    STEP 4: QUALITY GATE
+        - Only proceed if your changes improve quality
+        - If quality would not improve, explain why and stop
+
+    STEP 5: CREATE PR (only if quality gate passes)
+        - Create a pull request from "${branchName}" to main
+        - Title: "Quality improvements: [describe what you fixed]"
+        - Description should include:
+            * What issues you fixed
+            * Before/after quality metrics
+            * Why these fixes improve code quality
+        - Add a comment with detailed SonarQube analysis
+
+    Be thorough and explain your decisions at each step.`;
+
+  await sbx.commands.run(
+    `echo '${prompt.replace(/'/g, "'\\''")}' | claude -p --dangerously-skip-permissions`,
+    {
+      timeoutMs: 0,
+      onStdout: console.log,
+      onStderr: console.log,
+    },
+  );
+
+  console.log(`\n Workflow complete! Check ${repoPath} for new pull request.`);
+
+  await sbx.kill();
+}
+
+qualityGatedPR().catch(console.error);
+```
+
+Run the script:
+
+```bash
+npx tsx 06-quality-gated-pr.ts
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+Create `06_quality_gated_pr.py`:
+
+```python
+import os
+import asyncio
+import time
+from dotenv import load_dotenv
+from e2b import AsyncSandbox
+
+load_dotenv()
+
+async def quality_gated_pr():
+    print("Creating sandbox for quality-gated PR workflow...\n")
+
+    sbx = await AsyncSandbox.beta_create(
+        envs={
+            "ANTHROPIC_API_KEY": os.getenv("ANTHROPIC_API_KEY"),
+            "GITHUB_TOKEN": os.getenv("GITHUB_TOKEN"),
+            "SONARQUBE_TOKEN": os.getenv("SONARQUBE_TOKEN"),
+        },
+        mcp={
+            "githubOfficial": {
+                "githubPersonalAccessToken": os.getenv("GITHUB_TOKEN"),
+            },
+            "sonarqube": {
+                "org": os.getenv("SONARQUBE_ORG"),
+                "token": os.getenv("SONARQUBE_TOKEN"),
+                "url": "https://sonarcloud.io",
+            },
+        },
+    )
+
+    mcp_url = sbx.beta_get_mcp_url()
+    mcp_token = await sbx.beta_get_mcp_token()
+
+    await asyncio.sleep(1)
+
+    await sbx.commands.run(
+        f'claude mcp add --transport http e2b-mcp-gateway {mcp_url} --header "Authorization: Bearer {mcp_token}"',
+        timeout=0,
+        on_stdout=print,
+        on_stderr=print,
+    )
+
+    repo_path = f"{os.getenv('GITHUB_OWNER')}/{os.getenv('GITHUB_REPO')}"
+    branch_name = f"quality-improvements-{int(time.time() * 1000)}"
+
+    print("\nRunning quality-gated PR workflow...\n")
+
+    prompt = f"""You are a code quality engineer. Using GitHub and SonarQube MCP tools:
+
+    STEP 1: ANALYSIS
+    - Get current code quality status from SonarQube for "{repo_path}"
+    - Record the current number of bugs, code smells, and vulnerabilities
+    - Identify 1-3 issues that you can confidently fix
+
+    STEP 2: FIX ISSUES
+    - Create branch "{branch_name}"
+    - For each issue you are fixing:
+        Read the file with the issue
+        Make the fix
+        Commit with a descriptive message
+    - Only fix issues where you are 100 percent confident the fix is correct
+
+    STEP 3: VERIFICATION
+        - After your fixes, check if quality metrics would improve
+        - Calculate: Would this reduce bugs/smells/vulnerabilities?
+
+    STEP 4: QUALITY GATE
+        - Only proceed if your changes improve quality
+        - If quality would not improve, explain why and stop
+
+    STEP 5: CREATE PR (only if quality gate passes)
+        - Create a pull request from "{branch_name}" to main
+        - Title: "Quality improvements: [describe what you fixed]"
+        - Description should include:
+            What issues you fixed
+            Before/after quality metrics
+            Why these fixes improve code quality
+        - Add a comment with detailed SonarQube analysis
+
+    Be thorough and explain your decisions at each step."""
+
+    await sbx.commands.run(
+        f"echo '{prompt.replace(chr(39), chr(39) + chr(92) + chr(39) + chr(39))}' | claude -p --dangerously-skip-permissions",
+        timeout=0,
+        on_stdout=print,
+        on_stderr=print,
+    )
+
+    print(f"\n Workflow complete! Check {repo_path} for new pull request.")
+
+    await sbx.kill()
+
+if __name__ == "__main__":
+    asyncio.run(quality_gated_pr())
+```
+
+Run the script:
+
+```bash
+python 06_quality_gated_pr.py
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+> [!NOTE]
+>
+> This script may take a few minutes to run.
+
+Claude will run the entire workflow, creating a quality improvement
+and opening a PR in GitHub:
+
+```console {collapse=true}
+Creating sandbox for quality-gated PR workflow...
+
+Running quality-gated PR workflow...
+
+## Complete - Code Quality Improvement Successfully Executed
+
+### Summary of Work Completed
+
+**Pull Request Created:** https://github.com/<github-org>/<your-repo>/pull/1
+
+---
+
+### STEP 1: ANALYSIS
+
+**Current State:**
+- **Bugs:** 0
+- **Vulnerabilities:** 0
+- **Code Smells:** 1
+- **Lines of Code:** 12
+- **All Ratings:** A (Reliability, Security, Maintainability)
+
+**Issues Identified (all in test.js):**
+1. xxxxxxxxx - Unused variable declaration (MINOR)
+
+---
+
+### STEP 2: FIX ISSUES
+
+**Branch Created:** `quality-improvements-xxxxxxxx`
+
+**Changes Made:**
+1. **Removed unused variable** (line 2) - Eliminated dead code that served no purpose
+2. **Modernized loop pattern** (lines 5-7) - Converted `for (let i = 0; i < items.length; i++)` to `for (const item of items)`
+
+**Commit:** xxxxxxxxxx
+
+---
+
+### STEP 3: VERIFICATION
+
+**Expected Impact:**
+- Code Smells: 1 → 0 (100% reduction)
+- Bugs: 0 → 0 (maintained)
+- Vulnerabilities: 0 → 0 (maintained)
+- All quality ratings maintained at A
+
+---
+
+### STEP 4: QUALITY GATE PASSED
+
+**Decision Criteria Met:**
+- ✅ Reduces code smells by 100%
+- ✅ No new bugs or vulnerabilities introduced
+- ✅ Code is more readable and maintainable
+- ✅ Follows modern JavaScript best practices
+- ✅ All fixes are low-risk refactorings with no behavioral changes
+
+---
+
+### STEP 5: CREATE PR
+
+**Pull Request Details:**
+- **Number:** #1
+- **Title:** Quality improvements: Remove unused variable and modernize for loop
+- **Branch:** quality-improvements-xxxxxxxx → main
+- **URL:** https://github.com/<github-org)/<your-repo>/pull/1
+
+**PR Includes:**
+- Comprehensive description with before/after metrics
+- Detailed SonarQube analysis comment with issue breakdown
+- Code comparison showing improvements
+- Quality metrics table
+
+The pull request is now ready for review and merge!
+```
+
+You've now built a complete, multi-step workflow with conditional logic.
+Claude analyzes quality with SonarQube, makes fixes using GitHub tools,
+verifies improvements, and only creates a PR if quality actually improves.
+
+### Step 7: Add error handling
+
+Production workflows need error handling. Let's make the workflow more robust.
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+Create `07-robust-workflow.ts`:
+
+```typescript
+import "dotenv/config";
+import { Sandbox } from "e2b";
+
+async function robustWorkflow() {
+  let sbx: Sandbox | undefined;
+
+  try {
+    console.log("Creating sandbox...\n");
+
+    sbx = await Sandbox.betaCreate({
+      envs: {
+        ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY!,
+        GITHUB_TOKEN: process.env.GITHUB_TOKEN!,
+        SONARQUBE_TOKEN: process.env.SONARQUBE_TOKEN!,
+      },
+      mcp: {
+        githubOfficial: {
+          githubPersonalAccessToken: process.env.GITHUB_TOKEN!,
+        },
+        sonarqube: {
+          org: process.env.SONARQUBE_ORG!,
+          token: process.env.SONARQUBE_TOKEN!,
+          url: "https://sonarcloud.io",
+        },
+      },
+    });
+
+    const mcpUrl = sbx.betaGetMcpUrl();
+    const mcpToken = await sbx.betaGetMcpToken();
+
+    await new Promise((resolve) => setTimeout(resolve, 1000));
+
+    await sbx.commands.run(
+      `claude mcp add --transport http e2b-mcp-gateway ${mcpUrl} --header "Authorization: Bearer ${mcpToken}"`,
+      { timeoutMs: 0, onStdout: console.log, onStderr: console.log },
+    );
+
+    const repoPath = `${process.env.GITHUB_OWNER}/${process.env.GITHUB_REPO}`;
+
+    console.log("\nRunning workflow with error handling...\n");
+
+    const prompt = `Run a quality improvement workflow for "${repoPath}".
+
+    ERROR HANDLING RULES:
+    1. If SonarQube is unreachable, explain the error and stop gracefully
+    2. If GitHub API fails, retry once, then explain and stop
+    3. If no fixable issues are found, explain why and exit (this is not an error)
+    4. If file modifications fail, explain which file and why
+    5. At each step, check for errors before proceeding
+
+    Run the workflow and handle any errors you encounter professionally.`;
+
+    await sbx.commands.run(
+      `echo '${prompt.replace(/'/g, "'\\''")}' | claude -p --dangerously-skip-permissions`,
+      {
+        timeoutMs: 0,
+        onStdout: console.log,
+        onStderr: console.log,
+      },
+    );
+
+    console.log("\n Workflow completed");
+  } catch (error) {
+    const err = error as Error;
+    console.error("\n Workflow failed:", err.message);
+
+    if (err.message.includes("403")) {
+      console.error("\n Check your E2B account has MCP gateway access");
+    } else if (err.message.includes("401")) {
+      console.error("\n Check your API tokens are valid");
+    } else if (err.message.includes("Credit balance")) {
+      console.error("\n Check your Anthropic API credit balance");
+    }
+
+    process.exit(1);
+  } finally {
+    if (sbx) {
+      console.log("\n Cleaning up sandbox...");
+      await sbx.kill();
+    }
+  }
+}
+
+robustWorkflow().catch(console.error);
+```
+
+Run the script:
+
+```bash
+npx tsx 07-robust-workflow.ts
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+Create `07_robust_workflow.py`:
+
+```python
+import os
+import asyncio
+import sys
+from dotenv import load_dotenv
+from e2b import AsyncSandbox
+
+load_dotenv()
+
+async def robust_workflow():
+    sbx = None
+
+    try:
+        print("Creating sandbox...\n")
+
+        sbx = await AsyncSandbox.beta_create(
+            envs={
+                "ANTHROPIC_API_KEY": os.getenv("ANTHROPIC_API_KEY"),
+                "GITHUB_TOKEN": os.getenv("GITHUB_TOKEN"),
+                "SONARQUBE_TOKEN": os.getenv("SONARQUBE_TOKEN"),
+            },
+            mcp={
+                "githubOfficial": {
+                    "githubPersonalAccessToken": os.getenv("GITHUB_TOKEN"),
+                },
+                "sonarqube": {
+                    "org": os.getenv("SONARQUBE_ORG"),
+                    "token": os.getenv("SONARQUBE_TOKEN"),
+                    "url": "https://sonarcloud.io",
+                },
+            },
+        )
+
+        mcp_url = sbx.beta_get_mcp_url()
+        mcp_token = await sbx.beta_get_mcp_token()
+
+        await asyncio.sleep(1)
+
+        await sbx.commands.run(
+            f'claude mcp add --transport http e2b-mcp-gateway {mcp_url} --header "Authorization: Bearer {mcp_token}"',
+            timeout=0,  # Fixed: was timeout_ms
+            on_stdout=print,
+            on_stderr=print,
+        )
+
+        repo_path = f"{os.getenv('GITHUB_OWNER')}/{os.getenv('GITHUB_REPO')}"
+
+        print("\nRunning workflow with error handling...\n")
+
+        prompt = f"""Run a quality improvement workflow for "{repo_path}".
+
+        ERROR HANDLING RULES:
+        1. If SonarQube is unreachable, explain the error and stop gracefully
+        2. If GitHub API fails, retry once, then explain and stop
+        3. If no fixable issues are found, explain why and exit (this is not an error)
+        4. If file modifications fail, explain which file and why
+        5. At each step, check for errors before proceeding
+
+        Run the workflow and handle any errors you encounter professionally."""
+
+        await sbx.commands.run(
+            f"echo '{prompt}' | claude -p --dangerously-skip-permissions",
+            timeout=0,
+            on_stdout=print,
+            on_stderr=print,
+        )
+
+        print("\n Workflow completed")
+
+    except Exception as error:
+        print(f"\n✗ Workflow failed: {str(error)}")
+
+        error_msg = str(error)
+        if "403" in error_msg:
+            print("\n Check your E2B account has MCP gateway access")
+        elif "401" in error_msg:
+            print("\n Check your API tokens are valid")
+        elif "Credit balance" in error_msg:
+            print("\n Check your Anthropic API credit balance")
+
+        sys.exit(1)
+
+    finally:
+        if sbx:
+            print("\n Cleaning up sandbox...")
+            await sbx.kill()
+
+if __name__ == "__main__":
+    asyncio.run(robust_workflow())
+```
+
+Run the script:
+
+```bash
+python 07_robust_workflow.py
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Claude will run the entire workflow, and if it encounters an error, respond
+with robust error messaging.
+
+### Next steps
+
+In the next section, you'll customize your workflow for your needs.
+
+## Customize a code quality check workflow
+
+Now that you understand the basics of automating code quality workflows with
+GitHub and SonarQube in E2B sandboxes, you can customize the workflow
+for your needs.
+
+### Focus on specific quality issues
+
+Modify the prompt to prioritize certain issue types:
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+```typescript
+const prompt = `Using SonarQube and GitHub MCP tools:
+
+Focus only on:
+- Security vulnerabilities (CRITICAL priority)
+- Bugs (HIGH priority)
+- Skip code smells for this iteration
+
+Analyze "${repoPath}" and fix the highest priority issues first.`;
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+```python
+prompt = f"""Using SonarQube and GitHub MCP tools:
+
+Focus only on:
+- Security vulnerabilities (CRITICAL priority)
+- Bugs (HIGH priority)
+- Skip code smells for this iteration
+
+Analyze "{repo_path}" and fix the highest priority issues first."""
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Integrate with CI/CD
+
+Add this workflow to GitHub Actions to run automatically on pull requests:
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+```yaml
+name: Automated quality checks
+on:
+  pull_request:
+    types: [opened, synchronize]
+
+jobs:
+  quality:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@{{% param "checkout_action_version" %}}
+      - uses: actions/setup-node@v5
+        with:
+          node-version: "24"
+      - run: npm install
+      - run: npx tsx 06-quality-gated-pr.ts
+        env:
+          E2B_API_KEY: ${{ secrets.E2B_API_KEY }}
+          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          SONARQUBE_TOKEN: ${{ secrets.SONARQUBE_TOKEN }}
+          GITHUB_OWNER: ${{ github.repository_owner }}
+          GITHUB_REPO: ${{ github.event.repository.name }}
+          SONARQUBE_ORG: your-org-key
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+```yaml
+name: Automated quality checks
+on:
+  pull_request:
+    types: [opened, synchronize]
+
+jobs:
+  quality:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@{{% param "checkout_action_version" %}}
+      - uses: actions/setup-python@v6
+        with:
+          python-version: "3.14"
+      - run: pip install e2b python-dotenv
+      - run: python 06_quality_gated_pr.py
+        env:
+          E2B_API_KEY: ${{ secrets.E2B_API_KEY }}
+          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          SONARQUBE_TOKEN: ${{ secrets.SONARQUBE_TOKEN }}
+          GITHUB_OWNER: ${{ github.repository_owner }}
+          GITHUB_REPO: ${{ github.event.repository.name }}
+          SONARQUBE_ORG: your-org-key
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Filter by file patterns
+
+Target specific parts of your codebase:
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+```typescript
+const prompt = `Analyze code quality but only consider:
+- Files in src/**/*.js
+- Exclude test files (*.test.js, *.spec.js)
+- Exclude build artifacts in dist/
+
+Focus on production code only.`;
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+```python
+prompt = """Analyze code quality but only consider:
+- Files in src/**/*.js
+- Exclude test files (*.test.js, *.spec.js)
+- Exclude build artifacts in dist/
+
+Focus on production code only."""
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Set quality thresholds
+
+Define when PRs should be created:
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+```typescript
+const prompt = `Quality gate thresholds:
+- Only create PR if:
+  * Bug count decreases by at least 1
+  * No new security vulnerabilities introduced
+  * Code coverage does not decrease
+  * Technical debt reduces by at least 15 minutes
+
+If changes do not meet these thresholds, explain why and skip PR creation.`;
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+```python
+prompt = """Quality gate thresholds:
+- Only create PR if:
+  * Bug count decreases by at least 1
+  * No new security vulnerabilities introduced
+  * Code coverage does not decrease
+  * Technical debt reduces by at least 15 minutes
+
+If changes do not meet these thresholds, explain why and skip PR creation."""
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Next steps
+
+Learn how to troubleshoot common issues.
+
+## Troubleshoot code quality workflows
+
+This page covers common issues you might encounter when building code quality
+workflows with E2B sandboxes and MCP servers, along with their solutions.
+
+If you're experiencing problems not covered here, check the
+[E2B documentation](https://e2b.dev/docs).
+
+### MCP tools not available
+
+Issue: Claude reports `I don't have any MCP tools available`.
+
+Solution:
+
+1.  Verify you're using the authorization header:
+
+    ```plaintext
+    --header "Authorization: Bearer ${mcpToken}"
+    ```
+
+2.  Check you're waiting for MCP initialization.
+
+    ```typescript
+    // typescript
+    await new Promise((resolve) => setTimeout(resolve, 1000));
+    ```
+
+    ```python
+    # python
+    await asyncio.sleep(1)
+    ```
+
+3.  Ensure credentials are in both `envs` and `mcp` configuration:
+
+    ```typescript
+    // typescript
+    const sbx = await Sandbox.betaCreate({
+      envs: {
+        ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY!,
+        GITHUB_TOKEN: process.env.GITHUB_TOKEN!,
+        SONARQUBE_TOKEN: process.env.SONARQUBE_TOKEN!,
+      },
+      mcp: {
+        githubOfficial: {
+          githubPersonalAccessToken: process.env.GITHUB_TOKEN!,
+        },
+        sonarqube: {
+          org: process.env.SONARQUBE_ORG!,
+          token: process.env.SONARQUBE_TOKEN!,
+          url: "https://sonarcloud.io",
+        },
+      },
+    });
+    ```
+
+    ```python
+    # python
+    sbx = await AsyncSandbox.beta_create(
+        envs={
+            "ANTHROPIC_API_KEY": os.getenv("ANTHROPIC_API_KEY"),
+            "GITHUB_TOKEN": os.getenv("GITHUB_TOKEN"),
+            "SONARQUBE_TOKEN": os.getenv("SONARQUBE_TOKEN"),
+        },
+        mcp={
+            "githubOfficial": {
+                "githubPersonalAccessToken": os.getenv("GITHUB_TOKEN"),
+            },
+            "sonarqube": {
+                "org": os.getenv("SONARQUBE_ORG"),
+                "token": os.getenv("SONARQUBE_TOKEN"),
+                "url": "https://sonarcloud.io",
+            },
+        },
+    )
+    ```
+
+4.  Verify your API tokens are valid and have proper scopes.
+
+### GitHub tools work but SonarQube doesn't
+
+Issue: GitHub MCP tools load but SonarQube tools don't appear.
+
+Solution: SonarQube MCP server requires GitHub to be configured simultaneously.
+Always include both servers in your sandbox configuration, even if you're only
+testing one.
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+```typescript
+// Include both servers even if only using one
+const sbx = await Sandbox.betaCreate({
+  envs: {
+    ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY!,
+    GITHUB_TOKEN: process.env.GITHUB_TOKEN!,
+    SONARQUBE_TOKEN: process.env.SONARQUBE_TOKEN!,
+  },
+  mcp: {
+    githubOfficial: {
+      githubPersonalAccessToken: process.env.GITHUB_TOKEN!,
+    },
+    sonarqube: {
+      org: process.env.SONARQUBE_ORG!,
+      token: process.env.SONARQUBE_TOKEN!,
+      url: "https://sonarcloud.io",
+    },
+  },
+});
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+```python
+# Include both servers even if only using one
+sbx = await AsyncSandbox.beta_create(
+    envs={
+        "ANTHROPIC_API_KEY": os.getenv("ANTHROPIC_API_KEY"),
+        "GITHUB_TOKEN": os.getenv("GITHUB_TOKEN"),
+        "SONARQUBE_TOKEN": os.getenv("SONARQUBE_TOKEN"),
+    },
+    mcp={
+        "githubOfficial": {
+            "githubPersonalAccessToken": os.getenv("GITHUB_TOKEN"),
+        },
+        "sonarqube": {
+            "org": os.getenv("SONARQUBE_ORG"),
+            "token": os.getenv("SONARQUBE_TOKEN"),
+            "url": "https://sonarcloud.io",
+        },
+    },
+)
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Claude can't access private repositories
+
+Issue: "I don't have access to that repository".
+
+Solution:
+
+1. Verify your GitHub token has `repo` scope (not just `public_repo`).
+2. Test with a public repository first.
+3. Ensure the repository owner and name are correct in your `.env`:
+
+   {{< tabs group="language" >}}
+   {{< tab name="TypeScript" >}}
+
+   ```plaintext
+   GITHUB_OWNER=your_github_username
+   GITHUB_REPO=your_repository_name
+   ```
+
+   {{< /tab >}}
+   {{< tab name="Python" >}}
+
+   ```plaintext
+   GITHUB_OWNER=your_github_username
+   GITHUB_REPO=your_repository_name
+   ```
+
+   {{< /tab >}}
+   {{< /tabs >}}
+
+### Workflow times out or runs too long
+
+Issue: Workflow doesn't complete or Claude credits run out.
+
+Solutions:
+
+1. Use `timeoutMs: 0` (TypeScript) or `timeout_ms=0` (Python) for complex workflows to allow unlimited time:
+
+   {{< tabs group="language" >}}
+   {{< tab name="TypeScript" >}}
+
+   ```typescript
+   await sbx.commands.run(
+     `echo '${prompt}' | claude -p --dangerously-skip-permissions`,
+     {
+       timeoutMs: 0, // No timeout
+       onStdout: console.log,
+       onStderr: console.log,
+     },
+   );
+   ```
+
+   {{< /tab >}}
+   {{< tab name="Python" >}}
+
+   ```python
+   await sbx.commands.run(
+       f"echo '{prompt}' | claude -p --dangerously-skip-permissions",
+       timeout_ms=0,  # No timeout
+       on_stdout=print,
+       on_stderr=print,
+   )
+   ```
+
+   {{< /tab >}}
+   {{< /tabs >}}
+
+2. Break complex workflows into smaller, focused tasks.
+3. Monitor your Anthropic API credit usage.
+4. Add checkpoints in prompts: "After each step, show progress before continuing".
+
+### Sandbox cleanup errors
+
+Issue: Sandboxes aren't being cleaned up properly, leading to resource exhaustion.
+
+Solution: Always use proper error handling with cleanup in the `finally` block:
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+```typescript
+async function robustWorkflow() {
+  let sbx: Sandbox | undefined;
+
+  try {
+    sbx = await Sandbox.betaCreate({
+      // ... configuration
+    });
+
+    // ... workflow logic
+  } catch (error) {
+    console.error("Workflow failed:", error);
+    process.exit(1);
+  } finally {
+    if (sbx) {
+      console.log("Cleaning up sandbox...");
+      await sbx.kill();
+    }
+  }
+}
+```
+
+{{< /tab >}}
+{{< tab name="Python" >}}
+
+```python
+async def robust_workflow():
+    sbx = None
+
+    try:
+        sbx = await AsyncSandbox.beta_create(
+            # ... configuration
+        )
+
+        # ... workflow logic
+
+    except Exception as error:
+        print(f"Workflow failed: {error}")
+        sys.exit(1)
+    finally:
+        if sbx:
+            print("Cleaning up sandbox...")
+            await sbx.kill()
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Environment variable not loading
+
+Issue: Script fails with "undefined" or "None" for environment variables.
+
+Solution:
+
+{{< tabs group="language" >}}
+{{< tab name="TypeScript" >}}
+
+1. Ensure `dotenv` is loaded at the top of your file:
+
+   ```typescript
+   import "dotenv/config";
+   ```
+
+2. Verify the `.env` file is in the same directory as your script.
+
+3. Check variable names match exactly (case-sensitive):
+
+   ```typescript
+   // .env file
+   GITHUB_TOKEN = ghp_xxxxx;
+
+   // In code
+   process.env.GITHUB_TOKEN; // Correct
+   process.env.github_token; // Wrong - case doesn't match
+   ```
+
+   {{< /tab >}}
+   {{< tab name="Python" >}}
+   1. Ensure `dotenv` is loaded at the top of your file:
+
+      ```python
+      from dotenv import load_dotenv
+      load_dotenv()
+      ```
+
+   2. Verify the `.env` file is in the same directory as your script.
+
+   3. Check variable names match exactly (case-sensitive):
+
+      ```python
+      # .env file
+      GITHUB_TOKEN=ghp_xxxxx
+
+      # In code
+      os.getenv("GITHUB_TOKEN")  # Correct
+      os.getenv("github_token")  # Wrong - case doesn't match
+      ```
+
+   {{< /tab >}}
+   {{< /tabs >}}
+
+### SonarQube returns empty results
+
+Issue: SonarQube analysis returns no projects or issues.
+
+Solution:
+
+1. Verify your SonarCloud organization key is correct.
+2. Ensure you have at least one project configured in SonarCloud.
+3. Check that your SonarQube token has the necessary permissions.
+4. Confirm your project has been analyzed at least once in SonarCloud.
diff --git a/content/guides/go-prometheus-monitoring.md b/content/guides/go-prometheus-monitoring.md
new file mode 100644
index 000000000000..78e506a5085b
--- /dev/null
+++ b/content/guides/go-prometheus-monitoring.md
@@ -0,0 +1,629 @@
+---
+description: Containerize a Golang application and monitor it with Prometheus and Grafana.
+keywords: golang, prometheus, grafana, monitoring, containerize
+title: Monitor a Golang application with Prometheus and Grafana
+summary: |
+  Learn how to containerize a Golang application and monitor it with Prometheus and Grafana.
+linkTitle: Prometheus and Grafana
+aliases:
+  - /guides/go-prometheus-monitoring/application/
+  - /guides/go-prometheus-monitoring/compose/
+  - /guides/go-prometheus-monitoring/containerize/
+  - /guides/go-prometheus-monitoring/develop/
+params:
+  tags: [cicd]
+  time: 45 minutes
+---
+
+
+The guide teaches you how to containerize a Golang application and monitor it with Prometheus and Grafana. 
+
+> **Acknowledgment**
+>
+> Docker would like to thank [Pradumna Saraf](https://twitter.com/pradumna_saraf) for his contribution to this guide.
+
+## Overview
+
+To make sure your application is working as intended, monitoring is important. One of the most popular monitoring tools is Prometheus. Prometheus is an open-source monitoring and alerting toolkit that is designed for reliability and scalability. It collects metrics from monitored targets by scraping metrics HTTP endpoints on these targets. To visualize the metrics, you can use Grafana. Grafana is an open-source platform for monitoring and observability that allows you to query, visualize, alert on, and understand your metrics no matter where they are stored.
+
+In this guide, you will be creating a Golang server with some endpoints to simulate a real-world application. Then you will expose metrics from the server using Prometheus. Finally, you will visualize the metrics using Grafana. You will containerize the Golang application, and using the Docker Compose file, you will connect all the services: Golang, Prometheus, and Grafana.
+
+## What will you learn?
+
+* Create a Golang application with custom Prometheus metrics.
+* Containerize a Golang application.
+* Use Docker Compose to run multiple services and connect them together to monitor a Golang application with Prometheus and Grafana.
+* Visualize the metrics using Grafana dashboards.
+
+## Prerequisites
+
+- A good understanding of Golang is assumed.
+- You must me familiar with Prometheus and creating dashboards in Grafana.
+- You must have familiarity with Docker concepts like containers, images, and Dockerfiles. If you are new to Docker, you can start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
+
+## Next steps
+
+You will create a Golang server and expose metrics using Prometheus.
+
+## Building the application
+
+### Prerequisites
+
+* You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
+
+You will be creating a Golang server with some endpoints to simulate a real-world application. Then you will expose metrics from the server using Prometheus.
+
+### Getting the sample application
+
+Clone the sample application to use with this guide. Open a terminal, change
+directory to a directory that you want to work in, and run the following
+command to clone the repository:
+
+```console
+$ git clone https://github.com/dockersamples/go-prometheus-monitoring.git 
+```
+
+Once you cloned you will see the following content structure inside `go-prometheus-monitoring` directory,
+
+```text
+go-prometheus-monitoring
+├── CONTRIBUTING.md
+├── Docker
+│   ├── grafana.yml
+│   └── prometheus.yml
+├── dashboard.json
+├── Dockerfile
+├── LICENSE
+├── README.md
+├── compose.yaml
+├── go.mod
+├── go.sum
+└── main.go
+```
+
+- **main.go** - The entry point of the application.
+- **go.mod and go.sum** - Go module files.
+- **Dockerfile** - Dockerfile used to build the app.
+- **Docker/** - Contains the Docker Compose configuration files for Grafana and Prometheus.
+- **compose.yaml** - Compose file to launch everything (Golang app, Prometheus, and Grafana).
+- **dashboard.json** - Grafana dashboard configuration file.
+- **Dockerfile** - Dockerfile used to build the Golang app.
+- **compose.yaml** - Docker Compose file to launch everything (Golang app, Prometheus, and Grafana).
+- Other files are for licensing and documentation purposes.
+
+### Understanding the application
+
+The following is the complete logic of the application you will find in `main.go`.
+
+```go
+package main
+
+import (
+	"strconv"
+
+	"github.com/gin-gonic/gin"
+	"github.com/prometheus/client_golang/prometheus"
+	"github.com/prometheus/client_golang/prometheus/promhttp"
+)
+
+// Define metrics
+var (
+	HttpRequestTotal = prometheus.NewCounterVec(prometheus.CounterOpts{
+		Name: "api_http_request_total",
+		Help: "Total number of requests processed by the API",
+	}, []string{"path", "status"})
+
+	HttpRequestErrorTotal = prometheus.NewCounterVec(prometheus.CounterOpts{
+		Name: "api_http_request_error_total",
+		Help: "Total number of errors returned by the API",
+	}, []string{"path", "status"})
+)
+
+// Custom registry (without default Go metrics)
+var customRegistry = prometheus.NewRegistry()
+
+// Register metrics with custom registry
+func init() {
+	customRegistry.MustRegister(HttpRequestTotal, HttpRequestErrorTotal)
+}
+
+func main() {
+	router := gin.Default()
+
+	// Register /metrics before middleware
+	router.GET("/metrics", PrometheusHandler())
+	
+	router.Use(RequestMetricsMiddleware())
+	router.GET("/health", func(c *gin.Context) {
+		c.JSON(200, gin.H{
+			"message": "Up and running!",
+		})
+	})
+	router.GET("/v1/users", func(c *gin.Context) {
+		c.JSON(200, gin.H{
+			"message": "Hello from /v1/users",
+		})
+	})
+
+	router.Run(":8000")
+}
+
+// Custom metrics handler with custom registry
+func PrometheusHandler() gin.HandlerFunc {
+	h := promhttp.HandlerFor(customRegistry, promhttp.HandlerOpts{})
+	return func(c *gin.Context) {
+		h.ServeHTTP(c.Writer, c.Request)
+	}
+}
+
+// Middleware to record incoming requests metrics
+func RequestMetricsMiddleware() gin.HandlerFunc {
+	return func(c *gin.Context) {
+		path := c.Request.URL.Path
+		c.Next()
+		status := c.Writer.Status()
+		if status < 400 {
+			HttpRequestTotal.WithLabelValues(path, strconv.Itoa(status)).Inc()
+		} else {
+			HttpRequestErrorTotal.WithLabelValues(path, strconv.Itoa(status)).Inc()
+		}
+	}
+}
+```
+
+In this part of the code, you have imported the required packages `gin`, `prometheus`, and `promhttp`. Then you have defined a couple of variables, `HttpRequestTotal` and `HttpRequestErrorTotal` are Prometheus counter metrics, and `customRegistry` is a custom registry that will be used to register these metrics. The name of the metric is a string that you can use to identify the metric. The help string is a string that will be shown when you query the `/metrics` endpoint to understand the metric. The reason you are using the custom registry is so avoid the default Go metrics that are registered by default by the Prometheus client. Then using the `init` function you are registering the metrics with the custom registry. 
+
+```go
+import (
+	"strconv"
+
+	"github.com/gin-gonic/gin"
+	"github.com/prometheus/client_golang/prometheus"
+	"github.com/prometheus/client_golang/prometheus/promhttp"
+)
+
+// Define metrics
+var (
+	HttpRequestTotal = prometheus.NewCounterVec(prometheus.CounterOpts{
+		Name: "api_http_request_total",
+		Help: "Total number of requests processed by the API",
+	}, []string{"path", "status"})
+
+	HttpRequestErrorTotal = prometheus.NewCounterVec(prometheus.CounterOpts{
+		Name: "api_http_request_error_total",
+		Help: "Total number of errors returned by the API",
+	}, []string{"path", "status"})
+)
+
+// Custom registry (without default Go metrics)
+var customRegistry = prometheus.NewRegistry()
+
+// Register metrics with custom registry
+func init() {
+	customRegistry.MustRegister(HttpRequestTotal, HttpRequestErrorTotal)
+}
+```
+
+In the `main` function, you have created a new instance of the `gin` framework and created three routes. You can see the health endpoint that is on path `/health` that will return a JSON with `{"message": "Up and running!"}` and the `/v1/users` endpoint that will return a JSON with `{"message": "Hello from /v1/users"}`. The third route is for the `/metrics` endpoint that will return the metrics in the Prometheus format. Then you have `RequestMetricsMiddleware` middleware, it will be called for every request made to the API. It will record the incoming requests metrics like status codes and paths. Finally, you are running the gin application on port 8000.
+
+```golang
+func main() {
+	router := gin.Default()
+
+	// Register /metrics before middleware
+	router.GET("/metrics", PrometheusHandler())
+	
+	router.Use(RequestMetricsMiddleware())
+	router.GET("/health", func(c *gin.Context) {
+		c.JSON(200, gin.H{
+			"message": "Up and running!",
+		})
+	})
+	router.GET("/v1/users", func(c *gin.Context) {
+		c.JSON(200, gin.H{
+			"message": "Hello from /v1/users",
+		})
+	})
+
+	router.Run(":8000")
+}
+```
+
+Now comes the middleware function `RequestMetricsMiddleware`. This function is called for every request made to the API. It increments the `HttpRequestTotal` counter (different counter for different paths and status codes) if the status code is less than or equal to 400. If the status code is greater than 400, it increments the `HttpRequestErrorTotal` counter (different counter for different paths and status codes). The `PrometheusHandler` function is the custom handler that will be called for the `/metrics` endpoint. It will return the metrics in the Prometheus format.
+
+```golang
+// Custom metrics handler with custom registry
+func PrometheusHandler() gin.HandlerFunc {
+	h := promhttp.HandlerFor(customRegistry, promhttp.HandlerOpts{})
+	return func(c *gin.Context) {
+		h.ServeHTTP(c.Writer, c.Request)
+	}
+}
+
+// Middleware to record incoming requests metrics
+func RequestMetricsMiddleware() gin.HandlerFunc {
+	return func(c *gin.Context) {
+		path := c.Request.URL.Path
+		c.Next()
+		status := c.Writer.Status()
+		if status < 400 {
+			HttpRequestTotal.WithLabelValues(path, strconv.Itoa(status)).Inc()
+		} else {
+			HttpRequestErrorTotal.WithLabelValues(path, strconv.Itoa(status)).Inc()
+		}
+	}
+}
+```
+
+That's it, this was the complete gist of the application. Now it's time to run and test if the app is registering metrics correctly.
+
+### Running the application
+
+Make sure you are still inside `go-prometheus-monitoring` directory in the terminal, and run the following command. Install the dependencies by running `go mod tidy` and then build and run the application by running `go run main.go`. Then visit `http://localhost:8000/health` or `http://localhost:8000/v1/users`. You should see the output `{"message": "Up and running!"}` or `{"message": "Hello from /v1/users"}`. If you are able to see this then your app is successfully up and running. 
+
+
+Now, check your application's metrics by accessing the `/metrics` endpoint. 
+Open `http://localhost:8000/metrics` in your browser. You should see similar output to the following.
+
+```sh
+# HELP api_http_request_error_total Total number of errors returned by the API
+# TYPE api_http_request_error_total counter
+api_http_request_error_total{path="/",status="404"} 1
+api_http_request_error_total{path="//v1/users",status="404"} 1
+api_http_request_error_total{path="/favicon.ico",status="404"} 1
+# HELP api_http_request_total Total number of requests processed by the API
+# TYPE api_http_request_total counter
+api_http_request_total{path="/health",status="200"} 2
+api_http_request_total{path="/v1/users",status="200"} 1
+```
+
+In the terminal, press `ctrl` + `c` to stop the application.
+
+> [!Note]
+> If you don't want to run the application locally, and want to run it in a Docker container, skip to next page where you create a Dockerfile and containerize the application.
+
+### Summary
+
+In this section, you learned how to create a Golang app to register metrics with Prometheus. By implementing middleware functions, you were able to increment the counters based on the request path and status codes.
+
+### Next steps
+
+In the next section, you'll learn how to containerize your application.
+
+## Containerize a Golang application
+
+Containerization helps you bundle the application and its dependencies into a single package called a container. This package can run on any platform without worrying about the environment. In this section, you will learn how to containerize a Golang application using Docker.
+
+To containerize a Golang application, you first need to create a Dockerfile. The Dockerfile contains instructions to build and run the application in a container. Also, when creating a Dockerfile, you can follow different sets of best practices to optimize the image size and make it more secure.
+
+### Creating a Dockerfile
+
+Create a new file named `Dockerfile` in the root directory of your Golang application. The Dockerfile contains instructions to build and run the application in a container.
+
+The following is a Dockerfile for a Golang application. You will also find this file in the `go-prometheus-monitoring` directory.
+
+```dockerfile
+# Use the official Golang image as the base
+FROM golang:1.24-alpine AS builder
+
+# Set environment variables
+ENV CGO_ENABLED=0 \
+    GOOS=linux \
+    GOARCH=amd64
+
+# Set working directory inside the container
+WORKDIR /build
+
+# Copy go.mod and go.sum files for dependency installation
+COPY go.mod go.sum ./
+
+# Download dependencies
+RUN go mod download
+
+# Copy the entire application source
+COPY . .
+
+# Build the Go binary
+RUN go build -o /app .
+
+# Final lightweight stage
+FROM alpine:3.21 AS final
+
+# Copy the compiled binary from the builder stage
+COPY --from=builder /app /bin/app
+
+# Expose the application's port
+EXPOSE 8000
+
+# Run the application
+CMD ["bin/app"]
+```
+
+### Understanding the Dockerfile
+
+The Dockerfile consists of two stages:
+
+1. **Build stage**: This stage uses the official Golang image as the base and sets the necessary environment variables. It also sets the working directory inside the container, copies the `go.mod` and `go.sum` files for dependency installation, downloads the dependencies, copies the entire application source, and builds the Go binary.
+
+    You use the `golang:1.24-alpine` image as the base image for the build stage. The `CGO_ENABLED=0` environment variable disables CGO, which is useful for building static binaries. You also set the `GOOS` and `GOARCH` environment variables to `linux` and `amd64`, respectively, to build the binary for the Linux platform.
+
+2. **Final stage**: This stage uses the official Alpine image as the base and copies the compiled binary from the build stage. It also exposes the application's port and runs the application.
+
+    You use the `alpine:3.21` image as the base image for the final stage. You copy the compiled binary from the build stage to the final image. You expose the application's port using the `EXPOSE` instruction and run the application using the `CMD` instruction.
+
+    Apart from the multi-stage build, the Dockerfile also follows best practices such as using the official images, setting the working directory, and copying only the necessary files to the final image. You can further optimize the Dockerfile by other best practices.
+
+### Build the Docker image and run the application
+
+One you have the Dockerfile, you can build the Docker image and run the application in a container.
+
+To build the Docker image, run the following command in the terminal:
+
+```console
+$ docker build -t go-api:latest .
+```
+
+After building the image, you can run the application in a container using the following command:
+
+```console
+$ docker run -p 8000:8000 go-api:latest
+```
+
+The application will start running inside the container, and you can access it at `http://localhost:8000`. You can also check the running containers using the `docker ps` command.
+
+```console
+$ docker ps
+```
+
+### Summary
+
+In this section, you learned how to containerize a Golang application using a Dockerfile. You created a multi-stage Dockerfile to build and run the application in a container. You also learned about best practices to optimize the Docker image size and make it more secure.
+
+Related information:
+
+ - [Dockerfile reference](/reference/dockerfile.md)
+ - [.dockerignore file](/reference/dockerfile.md#dockerignore-file)
+
+### Next steps
+
+In the next section, you will learn how to use Docker Compose to connect and run multiple services together to monitor a Golang application with Prometheus and Grafana.
+
+## Connecting services with Docker Compose
+
+Now that you have containerized the Golang application, you will use Docker Compose to connect your services together. You will connect the Golang application, Prometheus, and Grafana services together to monitor the Golang application with Prometheus and Grafana.
+
+### Creating a Docker Compose file
+
+Create a new file named `compose.yml` in the root directory of your Golang application. The Docker Compose file contains instructions to run multiple services and connect them together.
+
+Here is a Docker Compose file for a project that uses Golang, Prometheus, and Grafana. You will also find this file in the `go-prometheus-monitoring` directory.
+
+```yaml
+services:
+  api:
+    container_name: go-api
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: go-api:latest
+    ports:
+      - 8000:8000
+    networks:
+      - go-network
+    healthcheck:
+      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
+      interval: 30s
+      timeout: 10s
+      retries: 5
+    develop:
+      watch:
+        - path: .
+          action: rebuild
+      
+  prometheus:
+    container_name: prometheus
+    image: prom/prometheus:v2.55.0
+    volumes:
+      - ./Docker/prometheus.yml:/etc/prometheus/prometheus.yml
+    ports:
+      - 9090:9090
+    networks:
+      - go-network
+  
+  grafana:
+    container_name: grafana
+    image: grafana/grafana:11.3.0
+    volumes:
+      - ./Docker/grafana.yml:/etc/grafana/provisioning/datasources/datasource.yaml
+      - grafana-data:/var/lib/grafana
+    ports:
+      - 3000:3000
+    networks:
+      - go-network
+    environment:
+      - GF_SECURITY_ADMIN_USER=admin
+      - GF_SECURITY_ADMIN_PASSWORD=password
+
+volumes:
+  grafana-data:
+
+networks:
+  go-network:
+    driver: bridge
+```
+
+### Understanding the Docker Compose file
+
+The Docker Compose file consists of three services:
+
+- **Golang application service**: This service builds the Golang application using the Dockerfile and runs it in a container. It exposes the application's port `8000` and connects to the `go-network` network. It also defines a health check to monitor the application's health. You have also used `healthcheck` to monitor the health of the application. The health check runs every 30 seconds and retries 5 times if the health check fails. The health check uses the `curl` command to check the `/health` endpoint of the application. Apart from the health check, you have also added a `develop` section to watch the changes in the application's source code and rebuild the application using the Docker Compose Watch feature.
+
+- **Prometheus service**: This service runs the Prometheus server in a container. It uses the official Prometheus image `prom/prometheus:v2.55.0`. It exposes the Prometheus server on port `9090` and connects to the `go-network` network. You have also mounted the `prometheus.yml` file from the `Docker` directory which is present in the root directory of your project. The `prometheus.yml` file contains the Prometheus configuration to scrape the metrics from the Golang application. This is how you connect the Prometheus server to the Golang application.
+
+    ```yaml
+    global:
+      scrape_interval: 10s
+      evaluation_interval: 10s
+
+    scrape_configs:
+      - job_name: myapp
+        static_configs:
+          - targets: ["api:8000"]
+    ```
+
+    In the `prometheus.yml` file, you have defined a job named `myapp` to scrape the metrics from the Golang application. The `targets` field specifies the target to scrape the metrics from. In this case, the target is the Golang application running on port `8000`. The `api` is the service name of the Golang application in the Docker Compose file. The Prometheus server will scrape the metrics from the Golang application every 10 seconds.
+
+- **Grafana service**: This service runs the Grafana server in a container. It uses the official Grafana image `grafana/grafana:11.3.0`. It exposes the Grafana server on port `3000` and connects to the `go-network` network. You have also mounted the `grafana.yml` file from the `Docker` directory which is present in the root directory of your project. The `grafana.yml` file contains the Grafana configuration to add the Prometheus data source. This is how you connect the Grafana server to the Prometheus server. In the environment variables, you have set the Grafana admin user and password, which will be used to log in to the Grafana dashboard.
+
+    ```yaml
+    apiVersion: 1
+    datasources:
+    - name: Prometheus (Main)
+      type: prometheus
+      url: http://prometheus:9090
+      isDefault: true
+    ```
+      
+    In the `grafana.yml` file, you have defined a Prometheus data source named `Prometheus (Main)`. The `type` field specifies the type of the data source, which is `prometheus`. The `url` field specifies the URL of the Prometheus server to fetch the metrics from. In this case, the URL is `http://prometheus:9090`. `prometheus` is the service name of the Prometheus server in the Docker Compose file. The `isDefault` field specifies whether the data source is the default data source in Grafana.
+
+Apart from the services, the Docker Compose file also defines a volume named `grafana-data` to persist the Grafana data and a network named `go-network` to connect the services together. You have created a custom network `go-network` to connect the services together. The `driver: bridge` field specifies the network driver to use for the network.
+
+### Building and running the services
+
+Now that you have the Docker Compose file, you can build the services and run them together using Docker Compose.
+
+To build and run the services, run the following command in the terminal:
+
+```console
+$ docker compose up
+```
+
+The `docker compose up` command builds the services defined in the Docker Compose file and runs them together. You will see the similar output in the terminal:
+
+```console
+ ✔ Network go-prometheus-monitoring_go-network  Created                                                           0.0s 
+ ✔ Container grafana                            Created                                                           0.3s 
+ ✔ Container go-api                             Created                                                           0.2s 
+ ✔ Container prometheus                         Created                                                           0.3s 
+Attaching to go-api, grafana, prometheus
+go-api      | [GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.
+go-api      | 
+go-api      | [GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
+go-api      |  - using env:     export GIN_MODE=release
+go-api      |  - using code:    gin.SetMode(gin.ReleaseMode)
+go-api      | 
+go-api      | [GIN-debug] GET    /metrics                  --> main.PrometheusHandler.func1 (3 handlers)
+go-api      | [GIN-debug] GET    /health                   --> main.main.func1 (4 handlers)
+go-api      | [GIN-debug] GET    /v1/users                 --> main.main.func2 (4 handlers)
+go-api      | [GIN-debug] [WARNING] You trusted all proxies, this is NOT safe. We recommend you to set a value.
+go-api      | Please check https://pkg.go.dev/github.com/gin-gonic/gin#readme-don-t-trust-all-proxies for details.
+go-api      | [GIN-debug] Listening and serving HTTP on :8000
+prometheus  | ts=2025-03-15T05:57:06.676Z caller=main.go:627 level=info msg="No time or size retention was set so using the default time retention" duration=15d
+prometheus  | ts=2025-03-15T05:57:06.678Z caller=main.go:671 level=info msg="Starting Prometheus Server" mode=server version="(version=2.55.0, branch=HEAD, revision=91d80252c3e528728b0f88d254dd720f6be07cb8)"
+grafana     | logger=settings t=2025-03-15T05:57:06.865335506Z level=info msg="Config overridden from command line" arg="default.log.mode=console"
+grafana     | logger=settings t=2025-03-15T05:57:06.865337131Z level=info msg="Config overridden from Environment variable" var="GF_PATHS_DATA=/var/lib/grafana"
+grafana     | logger=ngalert.state.manager t=2025-03-15T05:57:07.088956839Z level=info msg="State
+.
+.
+grafana     | logger=plugin.angulardetectorsprovider.dynamic t=2025-03-15T05:57:07.530317298Z level=info msg="Patterns update finished" duration=440.489125ms
+```
+
+The services will start running, and you can access the Golang application at `http://localhost:8000`, Prometheus at `http://localhost:9090/health`, and Grafana at `http://localhost:3000`. You can also check the running containers using the `docker ps` command.
+
+```console
+$ docker ps
+```
+
+### Summary
+
+In this section, you learned how to connect services together using Docker Compose. You created a Docker Compose file to run multiple services together and connect them using networks. You also learned how to build and run the services using Docker Compose.
+
+Related information:
+
+ - [Docker Compose overview](/manuals/compose/_index.md)
+ - [Compose file reference](/reference/compose-file/_index.md)
+
+Next, you will learn how to develop the Golang application with Docker Compose and monitor it with Prometheus and Grafana.
+
+### Next steps
+
+In the next section, you will learn how to develop the Golang application with Docker. You will also learn how to use Docker Compose Watch to rebuild the image whenever you make changes to the code. Lastly, you will test the application and visualize the metrics in Grafana using Prometheus as the data source.
+
+## Developing your application
+
+In the last section, you saw how using Docker Compose, you can connect your services together. In this section, you will learn how to develop the Golang application with Docker. You will also see how to use Docker Compose Watch to rebuild the image whenever you make changes to the code. Lastly, you will test the application and visualize the metrics in Grafana using Prometheus as the data source.
+
+### Developing the application
+
+Now, if you make any changes to your Golang application locally, it needs to reflect in the container, right? To do that, one approach is use the `--build` flag in Docker Compose after making changes in the code. This will rebuild all the services which have the `build` instruction in the `compose.yml` file, in your case, the `api` service (Golang application).
+
+```console
+docker compose up --build
+```
+
+But, this is not the best approach. This is not efficient. Every time you make a change in the code, you need to rebuild manually. This is not is not a good flow for development. 
+
+The better approach is to use Docker Compose Watch. In the `compose.yml` file, under the service `api`, you have added the `develop` section. So, it's more like a hot reloading. Whenever you make changes to code (defined in `path`), it will rebuild the image (or restart depending on the action). This is how you can use it:
+
+```yaml {hl_lines="17-20",linenos=true}
+services:
+  api:
+    container_name: go-api
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: go-api:latest
+    ports:
+      - 8000:8000
+    networks:
+      - go-network
+    healthcheck:
+      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
+      interval: 30s
+      timeout: 10s
+      retries: 5
+    develop:
+      watch:
+        - path: .
+          action: rebuild
+```
+
+Once you have added the `develop` section in the `compose.yml` file, you can use the following command to start the development server:
+
+```console
+$ docker compose watch
+```
+
+Now, if you modify your `main.go` or any other file in the project, the `api` service will be rebuilt automatically. You will see the following output in the terminal:
+
+```bash
+Rebuilding service(s) ["api"] after changes were detected...
+[+] Building 8.1s (15/15) FINISHED                                                                                                        docker:desktop-linux
+ => [api internal] load build definition from Dockerfile                                                                                                  0.0s
+ => => transferring dockerfile: 704B                                                                                                                      0.0s
+ => [api internal] load metadata for docker.io/library/alpine:3.17                                                                                        1.1s
+  .                             
+ => => exporting manifest list sha256:89ebc86fd51e27c1da440dc20858ff55fe42211a1930c2d51bbdce09f430c7f1                                                    0.0s
+ => => naming to docker.io/library/go-api:latest                                                                                                          0.0s
+ => => unpacking to docker.io/library/go-api:latest                                                                                                       0.0s
+ => [api] resolving provenance for metadata file                                                                                                          0.0s
+service(s) ["api"] successfully built
+```
+
+### Testing the application
+
+Now that you have your application running, head over to the Grafana dashboard to visualize the metrics you are registering. Open your browser and navigate to `http://localhost:3000`. You will be greeted with the Grafana login page. The login credentials are the ones provided in Compose file. 
+
+Once you are logged in, you can create a new dashboard. While creating dashboard you will notice that is default data source is `Prometheus`. This is because you have already configured the data source in the `grafana.yml` file.
+
+![The optional settings screen with the options specified.](../images/grafana-dash.png)
+
+You can use different panels to visualize the metrics. This guide doesn't go into details of Grafana. You can refer to the [Grafana documentation](https://grafana.com/docs/grafana/latest/) for more information. There is a Bar Gauge panel to visualize the total number of requests from different endpoints. You used the `api_http_request_total` and `api_http_request_error_total` metrics to get the data.
+
+![The optional settings screen with the options specified.](../images/grafana-panel.png)
+
+You created this panel to visualize the total number of requests from different endpoints to compare the successful and failed requests. For all the good requests, the bar will be green, and for all the failed requests, the bar will be red. Plus it will also show the from which endpoint the request is coming, either it's a successful request or a failed request. If you want to use this panel, you can import the `dashboard.json` file from the repository you cloned.
+
+### Summary
+
+You've come to the end of this guide. You learned how to develop the Golang application with Docker. You also saw how to use Docker Compose Watch to rebuild the image whenever you make changes to the code. Lastly, you tested the application and visualized the metrics in Grafana using Prometheus as the data source.
\ No newline at end of file
diff --git a/content/guides/go-prometheus-monitoring/_index.md b/content/guides/go-prometheus-monitoring/_index.md
deleted file mode 100644
index 99f49630f800..000000000000
--- a/content/guides/go-prometheus-monitoring/_index.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-description: Containerize a Golang application and monitor it with Prometheus and Grafana.
-keywords: golang, prometheus, grafana, monitoring, containerize
-title: Monitor a Golang application with Prometheus and Grafana
-summary: |
-  Learn how to containerize a Golang application and monitor it with Prometheus and Grafana.
-linkTitle: Monitor with Prometheus and Grafana
-languages: [go]
-params:
-  time: 45 minutes
----
-
-The guide teaches you how to containerize a Golang application and monitor it with Prometheus and Grafana. 
-
-> **Acknowledgment**
->
-> Docker would like to thank [Pradumna Saraf](https://twitter.com/pradumna_saraf) for his contribution to this guide.
-
-## Overview
-
-To make sure your application is working as intended, monitoring is important. One of the most popular monitoring tools is Prometheus. Prometheus is an open-source monitoring and alerting toolkit that is designed for reliability and scalability. It collects metrics from monitored targets by scraping metrics HTTP endpoints on these targets. To visualize the metrics, you can use Grafana. Grafana is an open-source platform for monitoring and observability that allows you to query, visualize, alert on, and understand your metrics no matter where they are stored.
-
-In this guide, you will be creating a Golang server with some endpoints to simulate a real-world application. Then you will expose metrics from the server using Prometheus. Finally, you will visualize the metrics using Grafana. You will containerize the Golang application, and using the Docker Compose file, you will connect all the services: Golang, Prometheus, and Grafana.
-
-## What will you learn?
-
-* Create a Golang application with custom Prometheus metrics.
-* Containerize a Golang application.
-* Use Docker Compose to run multiple services and connect them together to monitor a Golang application with Prometheus and Grafana.
-* Visualize the metrics using Grafana dashboards.
-
-## Prerequisites
-
-- A good understanding of Golang is assumed.
-- You must me familiar with Prometheus and creating dashboards in Grafana.
-- You must have familiarity with Docker concepts like containers, images, and Dockerfiles. If you are new to Docker, you can start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
-
-## Next steps
-
-You will create a Golang server and expose metrics using Prometheus.
diff --git a/content/guides/go-prometheus-monitoring/application.md b/content/guides/go-prometheus-monitoring/application.md
deleted file mode 100644
index 9845b9e127e1..000000000000
--- a/content/guides/go-prometheus-monitoring/application.md
+++ /dev/null
@@ -1,250 +0,0 @@
----
-title: Building the application
-linkTitle: Understand the application
-weight: 10 #
-keywords: go, golang, prometheus, grafana, containerize, monitor
-description: Learn how to create a Golang server to register metrics with Prometheus.
----
-
-## Prerequisites
-
-* You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client.
-
-You will be creating a Golang server with some endpoints to simulate a real-world application. Then you will expose metrics from the server using Prometheus.
-
-## Getting the sample application
-
-Clone the sample application to use with this guide. Open a terminal, change
-directory to a directory that you want to work in, and run the following
-command to clone the repository:
-
-```console
-$ git clone https://github.com/dockersamples/go-prometheus-monitoring.git 
-```
-
-Once you cloned you will see the following content structure inside `go-prometheus-monitoring` directory,
-
-```text
-go-prometheus-monitoring
-├── CONTRIBUTING.md
-├── Docker
-│   ├── grafana.yml
-│   └── prometheus.yml
-├── dashboard.json
-├── Dockerfile
-├── LICENSE
-├── README.md
-├── compose.yaml
-├── go.mod
-├── go.sum
-└── main.go
-```
-
-- **main.go** - The entry point of the application.
-- **go.mod and go.sum** - Go module files.
-- **Dockerfile** - Dockerfile used to build the app.
-- **Docker/** - Contains the Docker Compose configuration files for Grafana and Prometheus.
-- **compose.yaml** - Compose file to launch everything (Golang app, Prometheus, and Grafana).
-- **dashboard.json** - Grafana dashboard configuration file.
-- **Dockerfile** - Dockerfile used to build the Golang app.
-- **compose.yaml** - Docker Compose file to launch everything (Golang app, Prometheus, and Grafana).
-- Other files are for licensing and documentation purposes.
-
-## Understanding the application
-
-The following is the complete logic of the application you will find in `main.go`.
-
-```go
-package main
-
-import (
-	"strconv"
-
-	"github.com/gin-gonic/gin"
-	"github.com/prometheus/client_golang/prometheus"
-	"github.com/prometheus/client_golang/prometheus/promhttp"
-)
-
-// Define metrics
-var (
-	HttpRequestTotal = prometheus.NewCounterVec(prometheus.CounterOpts{
-		Name: "api_http_request_total",
-		Help: "Total number of requests processed by the API",
-	}, []string{"path", "status"})
-
-	HttpRequestErrorTotal = prometheus.NewCounterVec(prometheus.CounterOpts{
-		Name: "api_http_request_error_total",
-		Help: "Total number of errors returned by the API",
-	}, []string{"path", "status"})
-)
-
-// Custom registry (without default Go metrics)
-var customRegistry = prometheus.NewRegistry()
-
-// Register metrics with custom registry
-func init() {
-	customRegistry.MustRegister(HttpRequestTotal, HttpRequestErrorTotal)
-}
-
-func main() {
-	router := gin.Default()
-
-	// Register /metrics before middleware
-	router.GET("/metrics", PrometheusHandler())
-	
-	router.Use(RequestMetricsMiddleware())
-	router.GET("/health", func(c *gin.Context) {
-		c.JSON(200, gin.H{
-			"message": "Up and running!",
-		})
-	})
-	router.GET("/v1/users", func(c *gin.Context) {
-		c.JSON(200, gin.H{
-			"message": "Hello from /v1/users",
-		})
-	})
-
-	router.Run(":8000")
-}
-
-// Custom metrics handler with custom registry
-func PrometheusHandler() gin.HandlerFunc {
-	h := promhttp.HandlerFor(customRegistry, promhttp.HandlerOpts{})
-	return func(c *gin.Context) {
-		h.ServeHTTP(c.Writer, c.Request)
-	}
-}
-
-// Middleware to record incoming requests metrics
-func RequestMetricsMiddleware() gin.HandlerFunc {
-	return func(c *gin.Context) {
-		path := c.Request.URL.Path
-		c.Next()
-		status := c.Writer.Status()
-		if status < 400 {
-			HttpRequestTotal.WithLabelValues(path, strconv.Itoa(status)).Inc()
-		} else {
-			HttpRequestErrorTotal.WithLabelValues(path, strconv.Itoa(status)).Inc()
-		}
-	}
-}
-```
-
-In this part of the code, you have imported the required packages `gin`, `prometheus`, and `promhttp`. Then you have defined a couple of variables, `HttpRequestTotal` and `HttpRequestErrorTotal` are Prometheus counter metrics, and `customRegistry` is a custom registry that will be used to register these metrics. The name of the metric is a string that you can use to identify the metric. The help string is a string that will be shown when you query the `/metrics` endpoint to understand the metric. The reason you are using the custom registry is so avoid the default Go metrics that are registered by default by the Prometheus client. Then using the `init` function you are registering the metrics with the custom registry. 
-
-```go
-import (
-	"strconv"
-
-	"github.com/gin-gonic/gin"
-	"github.com/prometheus/client_golang/prometheus"
-	"github.com/prometheus/client_golang/prometheus/promhttp"
-)
-
-// Define metrics
-var (
-	HttpRequestTotal = prometheus.NewCounterVec(prometheus.CounterOpts{
-		Name: "api_http_request_total",
-		Help: "Total number of requests processed by the API",
-	}, []string{"path", "status"})
-
-	HttpRequestErrorTotal = prometheus.NewCounterVec(prometheus.CounterOpts{
-		Name: "api_http_request_error_total",
-		Help: "Total number of errors returned by the API",
-	}, []string{"path", "status"})
-)
-
-// Custom registry (without default Go metrics)
-var customRegistry = prometheus.NewRegistry()
-
-// Register metrics with custom registry
-func init() {
-	customRegistry.MustRegister(HttpRequestTotal, HttpRequestErrorTotal)
-}
-```
-
-In the `main` function, you have created a new instance of the `gin` framework and created three routes. You can see the health endpoint that is on path `/health` that will return a JSON with `{"message": "Up and running!"}` and the `/v1/users` endpoint that will return a JSON with `{"message": "Hello from /v1/users"}`. The third route is for the `/metrics` endpoint that will return the metrics in the Prometheus format. Then you have `RequestMetricsMiddleware` middleware, it will be called for every request made to the API. It will record the incoming requests metrics like status codes and paths. Finally, you are running the gin application on port 8000.
-
-```golang
-func main() {
-	router := gin.Default()
-
-	// Register /metrics before middleware
-	router.GET("/metrics", PrometheusHandler())
-	
-	router.Use(RequestMetricsMiddleware())
-	router.GET("/health", func(c *gin.Context) {
-		c.JSON(200, gin.H{
-			"message": "Up and running!",
-		})
-	})
-	router.GET("/v1/users", func(c *gin.Context) {
-		c.JSON(200, gin.H{
-			"message": "Hello from /v1/users",
-		})
-	})
-
-	router.Run(":8000")
-}
-```
-
-Now comes the middleware function `RequestMetricsMiddleware`. This function is called for every request made to the API. It increments the `HttpRequestTotal` counter (different counter for different paths and status codes) if the status code is less than or equal to 400. If the status code is greater than 400, it increments the `HttpRequestErrorTotal` counter (different counter for different paths and status codes). The `PrometheusHandler` function is the custom handler that will be called for the `/metrics` endpoint. It will return the metrics in the Prometheus format.
-
-```golang
-// Custom metrics handler with custom registry
-func PrometheusHandler() gin.HandlerFunc {
-	h := promhttp.HandlerFor(customRegistry, promhttp.HandlerOpts{})
-	return func(c *gin.Context) {
-		h.ServeHTTP(c.Writer, c.Request)
-	}
-}
-
-// Middleware to record incoming requests metrics
-func RequestMetricsMiddleware() gin.HandlerFunc {
-	return func(c *gin.Context) {
-		path := c.Request.URL.Path
-		c.Next()
-		status := c.Writer.Status()
-		if status < 400 {
-			HttpRequestTotal.WithLabelValues(path, strconv.Itoa(status)).Inc()
-		} else {
-			HttpRequestErrorTotal.WithLabelValues(path, strconv.Itoa(status)).Inc()
-		}
-	}
-}
-```
-
-That's it, this was the complete gist of the application. Now it's time to run and test if the app is registering metrics correctly.
-
-## Running the application
-
-Make sure you are still inside `go-prometheus-monitoring` directory in the terminal, and run the following command. Install the dependencies by running `go mod tidy` and then build and run the application by running `go run main.go`. Then visit `http://localhost:8000/health` or `http://localhost:8000/v1/users`. You should see the output `{"message": "Up and running!"}` or `{"message": "Hello from /v1/users"}`. If you are able to see this then your app is successfully up and running. 
-
-
-Now, check your application's metrics by accessing the `/metrics` endpoint. 
-Open `http://localhost:8000/metrics` in your browser. You should see similar output to the following.
-
-```sh
-# HELP api_http_request_error_total Total number of errors returned by the API
-# TYPE api_http_request_error_total counter
-api_http_request_error_total{path="/",status="404"} 1
-api_http_request_error_total{path="//v1/users",status="404"} 1
-api_http_request_error_total{path="/favicon.ico",status="404"} 1
-# HELP api_http_request_total Total number of requests processed by the API
-# TYPE api_http_request_total counter
-api_http_request_total{path="/health",status="200"} 2
-api_http_request_total{path="/v1/users",status="200"} 1
-```
-
-In the terminal, press `ctrl` + `c` to stop the application.
-
-> [!Note]
-> If you don't want to run the application locally, and want to run it in a Docker container, skip to next page where you create a Dockerfile and containerize the application.
-
-## Summary
-
-In this section, you learned how to create a Golang app to register metrics with Prometheus. By implementing middleware functions, you were able to increment the counters based on the request path and status codes.
-
-## Next steps
-
-In the next section, you'll learn how to containerize your application.
diff --git a/content/guides/go-prometheus-monitoring/compose.md b/content/guides/go-prometheus-monitoring/compose.md
deleted file mode 100644
index dd9763bcd117..000000000000
--- a/content/guides/go-prometheus-monitoring/compose.md
+++ /dev/null
@@ -1,166 +0,0 @@
----
-title: Connecting services with Docker Compose
-linkTitle: Connecting services with Docker Compose
-weight: 30 #
-keywords: go, golang, prometheus, grafana, containerize, monitor
-description: Learn how to connect services with Docker Compose to monitor a Golang application with Prometheus and Grafana.
----
-
-Now that you have containerized the Golang application, you will use Docker Compose to connect your services together. You will connect the Golang application, Prometheus, and Grafana services together to monitor the Golang application with Prometheus and Grafana.
-
-## Creating a Docker Compose file
-
-Create a new file named `compose.yml` in the root directory of your Golang application. The Docker Compose file contains instructions to run multiple services and connect them together.
-
-Here is a Docker Compose file for a project that uses Golang, Prometheus, and Grafana. You will also find this file in the `go-prometheus-monitoring` directory.
-
-```yaml
-services:
-  api:
-    container_name: go-api
-    build:
-      context: .
-      dockerfile: Dockerfile
-    image: go-api:latest
-    ports:
-      - 8000:8000
-    networks:
-      - go-network
-    healthcheck:
-      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
-      interval: 30s
-      timeout: 10s
-      retries: 5
-    develop:
-      watch:
-        - path: .
-          action: rebuild
-      
-  prometheus:
-    container_name: prometheus
-    image: prom/prometheus:v2.55.0
-    volumes:
-      - ./Docker/prometheus.yml:/etc/prometheus/prometheus.yml
-    ports:
-      - 9090:9090
-    networks:
-      - go-network
-  
-  grafana:
-    container_name: grafana
-    image: grafana/grafana:11.3.0
-    volumes:
-      - ./Docker/grafana.yml:/etc/grafana/provisioning/datasources/datasource.yaml
-      - grafana-data:/var/lib/grafana
-    ports:
-      - 3000:3000
-    networks:
-      - go-network
-    environment:
-      - GF_SECURITY_ADMIN_USER=admin
-      - GF_SECURITY_ADMIN_PASSWORD=password
-
-volumes:
-  grafana-data:
-
-networks:
-  go-network:
-    driver: bridge
-```
-
-## Understanding the Docker Compose file
-
-The Docker Compose file consists of three services:
-
-- **Golang application service**: This service builds the Golang application using the Dockerfile and runs it in a container. It exposes the application's port `8000` and connects to the `go-network` network. It also defines a health check to monitor the application's health. You have also used `healthcheck` to monitor the health of the application. The health check runs every 30 seconds and retries 5 times if the health check fails. The health check uses the `curl` command to check the `/health` endpoint of the application. Apart from the health check, you have also added a `develop` section to watch the changes in the application's source code and rebuild the application using the Docker Compose Watch feature.
-
-- **Prometheus service**: This service runs the Prometheus server in a container. It uses the official Prometheus image `prom/prometheus:v2.55.0`. It exposes the Prometheus server on port `9090` and connects to the `go-network` network. You have also mounted the `prometheus.yml` file from the `Docker` directory which is present in the root directory of your project. The `prometheus.yml` file contains the Prometheus configuration to scrape the metrics from the Golang application. This is how you connect the Prometheus server to the Golang application.
-
-    ```yaml
-    global:
-      scrape_interval: 10s
-      evaluation_interval: 10s
-
-    scrape_configs:
-      - job_name: myapp
-        static_configs:
-          - targets: ["api:8000"]
-    ```
-
-    In the `prometheus.yml` file, you have defined a job named `myapp` to scrape the metrics from the Golang application. The `targets` field specifies the target to scrape the metrics from. In this case, the target is the Golang application running on port `8000`. The `api` is the service name of the Golang application in the Docker Compose file. The Prometheus server will scrape the metrics from the Golang application every 10 seconds.
-
-- **Grafana service**: This service runs the Grafana server in a container. It uses the official Grafana image `grafana/grafana:11.3.0`. It exposes the Grafana server on port `3000` and connects to the `go-network` network. You have also mounted the `grafana.yml` file from the `Docker` directory which is present in the root directory of your project. The `grafana.yml` file contains the Grafana configuration to add the Prometheus data source. This is how you connect the Grafana server to the Prometheus server. In the environment variables, you have set the Grafana admin user and password, which will be used to log in to the Grafana dashboard.
-
-    ```yaml
-    apiVersion: 1
-    datasources:
-    - name: Prometheus (Main)
-      type: prometheus
-      url: http://prometheus:9090
-      isDefault: true
-    ```
-      
-    In the `grafana.yml` file, you have defined a Prometheus data source named `Prometheus (Main)`. The `type` field specifies the type of the data source, which is `prometheus`. The `url` field specifies the URL of the Prometheus server to fetch the metrics from. In this case, the URL is `http://prometheus:9090`. `prometheus` is the service name of the Prometheus server in the Docker Compose file. The `isDefault` field specifies whether the data source is the default data source in Grafana.
-
-Apart from the services, the Docker Compose file also defines a volume named `grafana-data` to persist the Grafana data and a network named `go-network` to connect the services together. You have created a custom network `go-network` to connect the services together. The `driver: bridge` field specifies the network driver to use for the network.
-
-## Building and running the services
-
-Now that you have the Docker Compose file, you can build the services and run them together using Docker Compose.
-
-To build and run the services, run the following command in the terminal:
-
-```console
-$ docker compose up
-```
-
-The `docker compose up` command builds the services defined in the Docker Compose file and runs them together. You will see the similar output in the terminal:
-
-```console
- ✔ Network go-prometheus-monitoring_go-network  Created                                                           0.0s 
- ✔ Container grafana                            Created                                                           0.3s 
- ✔ Container go-api                             Created                                                           0.2s 
- ✔ Container prometheus                         Created                                                           0.3s 
-Attaching to go-api, grafana, prometheus
-go-api      | [GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.
-go-api      | 
-go-api      | [GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
-go-api      |  - using env:     export GIN_MODE=release
-go-api      |  - using code:    gin.SetMode(gin.ReleaseMode)
-go-api      | 
-go-api      | [GIN-debug] GET    /metrics                  --> main.PrometheusHandler.func1 (3 handlers)
-go-api      | [GIN-debug] GET    /health                   --> main.main.func1 (4 handlers)
-go-api      | [GIN-debug] GET    /v1/users                 --> main.main.func2 (4 handlers)
-go-api      | [GIN-debug] [WARNING] You trusted all proxies, this is NOT safe. We recommend you to set a value.
-go-api      | Please check https://pkg.go.dev/github.com/gin-gonic/gin#readme-don-t-trust-all-proxies for details.
-go-api      | [GIN-debug] Listening and serving HTTP on :8000
-prometheus  | ts=2025-03-15T05:57:06.676Z caller=main.go:627 level=info msg="No time or size retention was set so using the default time retention" duration=15d
-prometheus  | ts=2025-03-15T05:57:06.678Z caller=main.go:671 level=info msg="Starting Prometheus Server" mode=server version="(version=2.55.0, branch=HEAD, revision=91d80252c3e528728b0f88d254dd720f6be07cb8)"
-grafana     | logger=settings t=2025-03-15T05:57:06.865335506Z level=info msg="Config overridden from command line" arg="default.log.mode=console"
-grafana     | logger=settings t=2025-03-15T05:57:06.865337131Z level=info msg="Config overridden from Environment variable" var="GF_PATHS_DATA=/var/lib/grafana"
-grafana     | logger=ngalert.state.manager t=2025-03-15T05:57:07.088956839Z level=info msg="State
-.
-.
-grafana     | logger=plugin.angulardetectorsprovider.dynamic t=2025-03-15T05:57:07.530317298Z level=info msg="Patterns update finished" duration=440.489125ms
-```
-
-The services will start running, and you can access the Golang application at `http://localhost:8000`, Prometheus at `http://localhost:9090/health`, and Grafana at `http://localhost:3000`. You can also check the running containers using the `docker ps` command.
-
-```console
-$ docker ps
-```
-
-## Summary
-
-In this section, you learned how to connect services together using Docker Compose. You created a Docker Compose file to run multiple services together and connect them using networks. You also learned how to build and run the services using Docker Compose.
-
-Related information:
-
- - [Docker Compose overview](/manuals/compose/_index.md)
- - [Compose file reference](/reference/compose-file/_index.md)
-
-Next, you will learn how to develop the Golang application with Docker Compose and monitor it with Prometheus and Grafana.
-
-## Next steps
-
-In the next section, you will learn how to develop the Golang application with Docker. You will also learn how to use Docker Compose Watch to rebuild the image whenever you make changes to the code. Lastly, you will test the application and visualize the metrics in Grafana using Prometheus as the data source.
\ No newline at end of file
diff --git a/content/guides/go-prometheus-monitoring/containerize.md b/content/guides/go-prometheus-monitoring/containerize.md
deleted file mode 100644
index a0a1a7401c2e..000000000000
--- a/content/guides/go-prometheus-monitoring/containerize.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-title: Containerize a Golang application
-linkTitle: Containerize your app
-weight: 20
-keywords: go, golang, containerize, initialize
-description: Learn how to containerize a Golang application.
----
-
-Containerization helps you bundle the application and its dependencies into a single package called a container. This package can run on any platform without worrying about the environment. In this section, you will learn how to containerize a Golang application using Docker.
-
-To containerize a Golang application, you first need to create a Dockerfile. The Dockerfile contains instructions to build and run the application in a container. Also, when creating a Dockerfile, you can follow different sets of best practices to optimize the image size and make it more secure.
-
-## Creating a Dockerfile
-
-Create a new file named `Dockerfile` in the root directory of your Golang application. The Dockerfile contains instructions to build and run the application in a container.
-
-The following is a Dockerfile for a Golang application. You will also find this file in the `go-prometheus-monitoring` directory.
-
-```dockerfile
-# Use the official Golang image as the base
-FROM golang:1.24-alpine AS builder
-
-# Set environment variables
-ENV CGO_ENABLED=0 \
-    GOOS=linux \
-    GOARCH=amd64
-
-# Set working directory inside the container
-WORKDIR /build
-
-# Copy go.mod and go.sum files for dependency installation
-COPY go.mod go.sum ./
-
-# Download dependencies
-RUN go mod download
-
-# Copy the entire application source
-COPY . .
-
-# Build the Go binary
-RUN go build -o /app .
-
-# Final lightweight stage
-FROM alpine:3.17 AS final
-
-# Copy the compiled binary from the builder stage
-COPY --from=builder /app /bin/app
-
-# Expose the application's port
-EXPOSE 8000
-
-# Run the application
-CMD ["bin/app"]
-```
-
-## Understanding the Dockerfile
-
-The Dockerfile consists of two stages:
-
-1. **Build stage**: This stage uses the official Golang image as the base and sets the necessary environment variables. It also sets the working directory inside the container, copies the `go.mod` and `go.sum` files for dependency installation, downloads the dependencies, copies the entire application source, and builds the Go binary.
-
-    You use the `golang:1.24-alpine` image as the base image for the build stage. The `CGO_ENABLED=0` environment variable disables CGO, which is useful for building static binaries. You also set the `GOOS` and `GOARCH` environment variables to `linux` and `amd64`, respectively, to build the binary for the Linux platform.
-
-2. **Final stage**: This stage uses the official Alpine image as the base and copies the compiled binary from the build stage. It also exposes the application's port and runs the application.
-
-    You use the `alpine:3.17` image as the base image for the final stage. You copy the compiled binary from the build stage to the final image. You expose the application's port using the `EXPOSE` instruction and run the application using the `CMD` instruction.
-
-    Apart from the multi-stage build, the Dockerfile also follows best practices such as using the official images, setting the working directory, and copying only the necessary files to the final image. You can further optimize the Dockerfile by other best practices.
-
-## Build the Docker image and run the application
-
-One you have the Dockerfile, you can build the Docker image and run the application in a container.
-
-To build the Docker image, run the following command in the terminal:
-
-```console
-$ docker build -t go-api:latest .
-```
-
-After building the image, you can run the application in a container using the following command:
-
-```console
-$ docker run -p 8000:8000 go-api:latest
-```
-
-The application will start running inside the container, and you can access it at `http://localhost:8000`. You can also check the running containers using the `docker ps` command.
-
-```console
-$ docker ps
-```
-
-## Summary
-
-In this section, you learned how to containerize a Golang application using a Dockerfile. You created a multi-stage Dockerfile to build and run the application in a container. You also learned about best practices to optimize the Docker image size and make it more secure.
-
-Related information:
-
- - [Dockerfile reference](/reference/dockerfile.md)
- - [.dockerignore file](/reference/dockerfile.md#dockerignore-file)
-
-## Next steps
-
-In the next section, you will learn how to use Docker Compose to connect and run multiple services together to monitor a Golang application with Prometheus and Grafana.
diff --git a/content/guides/go-prometheus-monitoring/develop.md b/content/guides/go-prometheus-monitoring/develop.md
deleted file mode 100644
index 7cf147604f5d..000000000000
--- a/content/guides/go-prometheus-monitoring/develop.md
+++ /dev/null
@@ -1,84 +0,0 @@
----
-title: Developing your application
-linkTitle: Develop your app
-weight: 40
-keywords: go, golang, containerize, initialize
-description: Learn how to develop the Golang application with Docker.
----
-
-In the last section, you saw how using Docker Compose, you can connect your services together. In this section, you will learn how to develop the Golang application with Docker. You will also see how to use Docker Compose Watch to rebuild the image whenever you make changes to the code. Lastly, you will test the application and visualize the metrics in Grafana using Prometheus as the data source.
-
-## Developing the application
-
-Now, if you make any changes to your Golang application locally, it needs to reflect in the container, right? To do that, one approach is use the `--build` flag in Docker Compose after making changes in the code. This will rebuild all the services which have the `build` instruction in the `compose.yml` file, in your case, the `api` service (Golang application).
-
-```console
-docker compose up --build
-```
-
-But, this is not the best approach. This is not efficient. Every time you make a change in the code, you need to rebuild manually. This is not is not a good flow for development. 
-
-The better approach is to use Docker Compose Watch. In the `compose.yml` file, under the service `api`, you have added the `develop` section. So, it's more like a hot reloading. Whenever you make changes to code (defined in `path`), it will rebuild the image (or restart depending on the action). This is how you can use it:
-
-```yaml {hl_lines="17-20",linenos=true}
-services:
-  api:
-    container_name: go-api
-    build:
-      context: .
-      dockerfile: Dockerfile
-    image: go-api:latest
-    ports:
-      - 8000:8000
-    networks:
-      - go-network
-    healthcheck:
-      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
-      interval: 30s
-      timeout: 10s
-      retries: 5
-    develop:
-      watch:
-        - path: .
-          action: rebuild
-```
-
-Once you have added the `develop` section in the `compose.yml` file, you can use the following command to start the development server:
-
-```console
-$ docker compose watch
-```
-
-Now, if you modify your `main.go` or any other file in the project, the `api` service will be rebuilt automatically. You will see the following output in the terminal:
-
-```bash
-Rebuilding service(s) ["api"] after changes were detected...
-[+] Building 8.1s (15/15) FINISHED                                                                                                        docker:desktop-linux
- => [api internal] load build definition from Dockerfile                                                                                                  0.0s
- => => transferring dockerfile: 704B                                                                                                                      0.0s
- => [api internal] load metadata for docker.io/library/alpine:3.17                                                                                        1.1s
-  .                             
- => => exporting manifest list sha256:89ebc86fd51e27c1da440dc20858ff55fe42211a1930c2d51bbdce09f430c7f1                                                    0.0s
- => => naming to docker.io/library/go-api:latest                                                                                                          0.0s
- => => unpacking to docker.io/library/go-api:latest                                                                                                       0.0s
- => [api] resolving provenance for metadata file                                                                                                          0.0s
-service(s) ["api"] successfully built
-```
-
-## Testing the application
-
-Now that you have your application running, head over to the Grafana dashboard to visualize the metrics you are registering. Open your browser and navigate to `http://localhost:3000`. You will be greeted with the Grafana login page. The login credentials are the ones provided in Compose file. 
-
-Once you are logged in, you can create a new dashboard. While creating dashboard you will notice that is default data source is `Prometheus`. This is because you have already configured the data source in the `grafana.yml` file.
-
-![The optional settings screen with the options specified.](../images/grafana-dash.png)
-
-You can use different panels to visualize the metrics. This guide doesn't go into details of Grafana. You can refer to the [Grafana documentation](https://grafana.com/docs/grafana/latest/) for more information. There is a Bar Gauge panel to visualize the total number of requests from different endpoints. You used the `api_http_request_total` and `api_http_request_error_total` metrics to get the data.
-
-![The optional settings screen with the options specified.](../images/grafana-panel.png)
-
-You created this panel to visualize the total number of requests from different endpoints to compare the successful and failed requests. For all the good requests, the bar will be green, and for all the failed requests, the bar will be red. Plus it will also show the from which endpoint the request is coming, either it's a successful request or a failed request. If you want to use this panel, you can import the `dashboard.json` file from the repository you cloned.
-
-## Summary
-
-You've come to the end of this guide. You learned how to develop the Golang application with Docker. You also saw how to use Docker Compose Watch to rebuild the image whenever you make changes to the code. Lastly, you tested the application and visualized the metrics in Grafana using Prometheus as the data source.
\ No newline at end of file
diff --git a/content/guides/golang.md b/content/guides/golang.md
new file mode 100644
index 000000000000..2a39f00f33b5
--- /dev/null
+++ b/content/guides/golang.md
@@ -0,0 +1,1542 @@
+---
+title: Go language-specific guide
+linkTitle: Go
+description: Containerize Go apps using Docker
+keywords: docker, getting started, go, golang, language, dockerfile
+summary: |
+  This guide teaches you how to containerize Go applications using Docker.
+aliases:
+  - /language/golang/
+  - /guides/language/golang/
+  - /get-started/golang/build-images/
+  - /language/golang/build-images/
+  - /get-started/golang/run-containers/
+  - /language/golang/run-containers/
+  - /get-started/golang/develop/
+  - /language/golang/develop/
+  - /get-started/golang/run-tests/
+  - /language/golang/run-tests/
+  - /language/golang/configure-ci-cd/
+  - /language/golang/deploy/
+  - /guides/golang/build-images/
+  - /guides/golang/configure-ci-cd/
+  - /guides/golang/deploy/
+  - /guides/golang/develop/
+  - /guides/golang/run-containers/
+  - /guides/golang/run-tests/
+params:
+  tags: [languages]
+  time: 30 minutes
+---
+
+This guide will show you how to create, test, and deploy containerized Go applications using Docker.
+
+> **Acknowledgment**
+>
+> Docker would like to thank [Oliver Frolovs](https://www.linkedin.com/in/ofr/) for his contribution to this guide.
+
+## What will you learn?
+
+In this guide, you’ll learn how to:
+
+- Create a `Dockerfile` which contains the instructions for building a container image for a program written in Go.
+- Run the image as a container in your local Docker instance and manage the container's lifecycle.
+- Use multi-stage builds for building small images efficiently while keeping your Dockerfiles easy to read and maintain.
+- Use Docker Compose to orchestrate running of multiple related containers together in a development environment.
+
+## Prerequisites
+
+Some basic understanding of Go and its toolchain is assumed. This isn't a Go tutorial. If you are new to the : languages:,
+the [Go website](https://golang.org/) is a great place to explore,
+so _go_ (pun intended) check it out!
+
+You also must know some basic [Docker concepts](/get-started/docker-concepts/the-basics/what-is-a-container.md) as well as to
+be at least vaguely familiar with the [Dockerfile format](/manuals/build/concepts/dockerfile.md).
+
+Your Docker set-up must have BuildKit enabled. BuildKit is enabled by default for all users on [Docker Desktop](/manuals/desktop/_index.md).
+If you have installed Docker Desktop, you don’t have to manually enable BuildKit. If you are running Docker on Linux,
+please check out BuildKit [getting started](/manuals/build/buildkit/_index.md#getting-started) page.
+
+Some familiarity with the command line is also expected.
+
+## What's next?
+
+The aim of this guide is to provide enough examples and instructions for you to containerize your own Go application and deploy it into the Cloud.
+
+Start by building your first Go image.
+
+## Build your Go image
+
+### Overview
+
+In this section you're going to build a container image. The image includes
+everything you need to run your application – the compiled application binary
+file, the runtime, the libraries, and all other resources required by your
+application.
+
+### Required software
+
+To complete this tutorial, you need the following:
+
+- Docker running locally. Follow the [instructions to download and install Docker](/manuals/desktop/_index.md).
+- An IDE or a text editor to edit files. [Visual Studio Code](https://code.visualstudio.com/) is a free and popular choice but you can use anything you feel comfortable with.
+- A Git client. This guide uses a command-line based `git` client, but you are free to use whatever works for you.
+- A command-line terminal application. The examples shown in this module are from the Linux shell, but they should work in PowerShell, Windows Command Prompt, or OS X Terminal with minimal, if any, modifications.
+
+### Meet the example application
+
+The example application is a caricature of a microservice. It is purposefully trivial to keep focus on learning the basics of containerization for Go applications.
+
+The application offers two HTTP endpoints:
+
+- It responds with a string containing a heart symbol (`<3`) to requests to `/`.
+- It responds with `{"Status" : "OK"}` JSON to a request to `/health`.
+
+It responds with HTTP error 404 to any other request.
+
+The application listens on a TCP port defined by the value of environment variable `PORT`. The default value is `8080`.
+
+The application is stateless.
+
+The complete source code for the application is on GitHub: [github.com/docker/docker-gs-ping](https://github.com/docker/docker-gs-ping). You are encouraged to fork it and experiment with it as much as you like.
+
+To continue, clone the application repository to your local machine:
+
+```console
+$ git clone https://github.com/docker/docker-gs-ping
+```
+
+The application's `main.go` file is straightforward, if you are familiar with Go:
+
+```go
+package main
+
+import (
+	"net/http"
+	"os"
+
+	"github.com/labstack/echo/v4"
+	"github.com/labstack/echo/v4/middleware"
+)
+
+func main() {
+
+	e := echo.New()
+
+	e.Use(middleware.Logger())
+	e.Use(middleware.Recover())
+
+	e.GET("/", func(c echo.Context) error {
+		return c.HTML(http.StatusOK, "Hello, Docker! <3")
+	})
+
+	e.GET("/health", func(c echo.Context) error {
+		return c.JSON(http.StatusOK, struct{ Status string }{Status: "OK"})
+	})
+
+	httpPort := os.Getenv("PORT")
+	if httpPort == "" {
+		httpPort = "8080"
+	}
+
+	e.Logger.Fatal(e.Start(":" + httpPort))
+}
+
+// Simple implementation of an integer minimum
+// Adapted from: https://gobyexample.com/testing-and-benchmarking
+func IntMin(a, b int) int {
+	if a < b {
+		return a
+	}
+	return b
+}
+```
+
+### Create a Dockerfile for the application
+
+To build a container image with Docker, a `Dockerfile` with build instructions is required.
+
+Begin your `Dockerfile` with the (optional) parser directive line that instructs BuildKit to
+interpret your file according to the grammar rules for the specified version of the syntax.
+
+You then tell Docker what base image you would like to use for your application:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+FROM golang:1.19
+```
+
+Docker images can be inherited from other images. Therefore, instead of creating
+your own base image from scratch, you can use the official Go image that already
+has all necessary tools and libraries to compile and run a Go application.
+
+> [!NOTE]
+>
+> If you are curious about creating your own base images, you can check out the following section of this guide: [creating base images](/manuals/build/building/base-images.md#create-a-base-image).
+> Note, however, that this isn't necessary to continue with your task at hand.
+
+Now that you have defined the base image for your upcoming container image, you
+can begin building on top of it.
+
+To make things easier when running the rest of your commands, create a directory
+inside the image that you're building. This also instructs Docker to use this
+directory as the default destination for all subsequent commands. This way you
+don't have to type out full file paths in the `Dockerfile`, the relative paths
+will be based on this directory.
+
+```dockerfile
+WORKDIR /app
+```
+
+Usually the very first thing you do once you’ve downloaded a project written in
+Go is to install the modules necessary to compile it. Note, that the base image
+has the toolchain already, but your source code isn't in it yet.
+
+So before you can run `go mod download` inside your image, you need to get your
+`go.mod` and `go.sum` files copied into it. Use the `COPY` command to do this.
+
+In its simplest form, the `COPY` command takes two parameters. The first
+parameter tells Docker what files you want to copy into the image. The last
+parameter tells Docker where you want that file to be copied to.
+
+Copy the `go.mod` and `go.sum` file into your project directory `/app` which,
+owing to your use of `WORKDIR`, is the current directory (`./`) inside the
+image. Unlike some modern shells that appear to be indifferent to the use of
+trailing slash (`/`), and can figure out what the user meant (most of the time),
+Docker's `COPY` command is quite sensitive in its interpretation of the trailing
+slash.
+
+```dockerfile
+COPY go.mod go.sum ./
+```
+
+> [!NOTE]
+>
+> If you'd like to familiarize yourself with the trailing slash treatment by the
+> `COPY` command, see [Dockerfile
+> reference](/reference/dockerfile.md#copy). This trailing slash can
+> cause issues in more ways than you can imagine.
+
+Now that you have the module files inside the Docker image that you are
+building, you can use the `RUN` command to run the command `go mod download`
+there as well. This works exactly the same as if you were running `go` locally
+on your machine, but this time these Go modules will be installed into a
+directory inside the image.
+
+```dockerfile
+RUN go mod download
+```
+
+At this point, you have a Go toolchain version 1.19.x and all your Go
+dependencies installed inside the image.
+
+The next thing you need to do is to copy your source code into the image. You’ll
+use the `COPY` command just like you did with your module files before.
+
+```dockerfile
+COPY *.go ./
+```
+
+This `COPY` command uses a wildcard to copy all files with `.go` extension
+located in the current directory on the host (the directory where the `Dockerfile`
+is located) into the current directory inside the image.
+
+`COPY *.go ./` only matches `.go` files in that one directory. Packages
+under `pkg/` or other subdirectories are left out, so `go build` then
+fails to find them. For a multi-package module, copy the module root
+instead (`COPY . .`) and use a `.dockerignore` file to keep the context
+small.
+
+Now, to compile your application, use the familiar `RUN` command:
+
+```dockerfile
+RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping
+```
+
+This should be familiar. The result of that command will be a static application
+binary named `docker-gs-ping` and located in the root of the filesystem of the
+image that you are building. You could have put the binary into any other place
+you desire inside that image, the root directory has no special meaning in this
+regard. It's convenient to use it to keep the file paths short for improved
+readability.
+
+Now, all that is left to do is to tell Docker what command to run when your
+image is used to start a container.
+
+You do this with the `CMD` command:
+
+```dockerfile
+CMD ["/docker-gs-ping"]
+```
+
+Here's the complete `Dockerfile`:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+FROM golang:1.19
+
+# Set destination for COPY
+WORKDIR /app
+
+# Download Go modules
+COPY go.mod go.sum ./
+RUN go mod download
+
+# Copy the source code. Note the slash at the end, as explained in
+# https://docs.docker.com/reference/dockerfile/#copy
+COPY *.go ./
+
+# Build
+RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping
+
+# Optional:
+# To bind to a TCP port, runtime parameters must be supplied to the docker command.
+# But we can document in the Dockerfile what ports
+# the application is going to listen on by default.
+# https://docs.docker.com/reference/dockerfile/#expose
+EXPOSE 8080
+
+# Run
+CMD ["/docker-gs-ping"]
+```
+
+The `Dockerfile` may also contain comments. They always begin with a `#` symbol,
+and must be at the beginning of a line. Comments are there for your convenience
+to allow documenting your `Dockerfile`.
+
+There is also a concept of Dockerfile directives, such as the `syntax` directive
+you added. The directives must always be at the very top of the `Dockerfile`, so
+when adding comments, make sure that the comments follow after any directives
+that you may have used:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+# A sample microservice in Go packaged into a container image.
+
+FROM golang:1.19
+
+# ...
+```
+
+### Build the image
+
+Now that you've created your `Dockerfile`, build an image from it. The `docker
+build` command creates Docker images from the `Dockerfile` and a context. A
+build context is the set of files located in the specified path or URL. The
+Docker build process can access any of the files located in the context.
+
+The build command optionally takes a `--tag` flag. This flag is used to label
+the image with a string value, which is easy for humans to read and recognize.
+If you don't pass a `--tag`, Docker will use `latest` as the default value.
+
+Build your first Docker image.
+
+```console
+$ docker build --tag docker-gs-ping .
+```
+
+The build process will print some diagnostic messages as it goes through the build steps.
+The following is an example of what these messages may look like.
+
+```console
+[+] Building 2.2s (15/15) FINISHED
+ => [internal] load build definition from Dockerfile                                                                                       0.0s
+ => => transferring dockerfile: 701B                                                                                                       0.0s
+ => [internal] load .dockerignore                                                                                                          0.0s
+ => => transferring context: 2B                                                                                                            0.0s
+ => resolve image config for docker.io/docker/dockerfile:1                                                                                 1.1s
+ => CACHED docker-image://docker.io/docker/dockerfile:1@sha256:39b85bbfa7536a5feceb7372a0817649ecb2724562a38360f4d6a7782a409b14            0.0s
+ => [internal] load build definition from Dockerfile                                                                                       0.0s
+ => [internal] load .dockerignore                                                                                                          0.0s
+ => [internal] load metadata for docker.io/library/golang:1.19                                                                             0.7s
+ => [1/6] FROM docker.io/library/golang:1.19@sha256:5d947843dde82ba1df5ac1b2ebb70b203d106f0423bf5183df3dc96f6bc5a705                       0.0s
+ => [internal] load build context                                                                                                          0.0s
+ => => transferring context: 6.08kB                                                                                                        0.0s
+ => CACHED [2/6] WORKDIR /app                                                                                                              0.0s
+ => CACHED [3/6] COPY go.mod go.sum ./                                                                                                     0.0s
+ => CACHED [4/6] RUN go mod download                                                                                                       0.0s
+ => CACHED [5/6] COPY *.go ./                                                                                                              0.0s
+ => CACHED [6/6] RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping                                                                  0.0s
+ => exporting to image                                                                                                                     0.0s
+ => => exporting layers                                                                                                                    0.0s
+ => => writing image sha256:ede8ff889a0d9bc33f7a8da0673763c887a258eb53837dd52445cdca7b7df7e3                                               0.0s
+ => => naming to docker.io/library/docker-gs-ping                                                                                          0.0s
+```
+
+Your exact output will vary, but provided there aren't any errors, you should
+see the word `FINISHED` in the first line of output. This means Docker has
+successfully built your image named `docker-gs-ping`.
+
+### View local images
+
+To see the list of images you have on your local machine, you have two options.
+One is to use the CLI and the other is to use [Docker
+Desktop](/manuals/desktop/_index.md). Since you're working in the
+terminal, take a look at listing images with the CLI.
+
+To list images, run the `docker image ls`command (or the `docker images` shorthand):
+
+```console
+$ docker image ls
+
+REPOSITORY                       TAG       IMAGE ID       CREATED         SIZE
+docker-gs-ping                   latest    7f153fbcc0a8   2 minutes ago   1.11GB
+...
+```
+
+Your exact output may vary, but you should see the `docker-gs-ping` image with
+the `latest` tag. Because you didn't specify a custom tag when you built your
+image, Docker assumed that the tag would be `latest`, which is a special value.
+
+### Tag images
+
+An image name is made up of slash-separated name components. Name components may
+contain lowercase letters, digits, and separators. A separator is defined as a
+period, one or two underscores, or one or more dashes. A name component may not
+start or end with a separator.
+
+An image is made up of a manifest and a list of layers. In simple terms, a tag
+points to a combination of these artifacts. You can have multiple tags for the
+image and, in fact, most images have multiple tags. Create a second tag
+for the image you built and take a look at its layers.
+
+Use the `docker image tag` (or `docker tag` shorthand) command to create a new
+tag for your image. This command takes two arguments; the first argument is the
+source image, and the second is the new tag to create. The following command
+creates a new `docker-gs-ping:v1.0` tag for the `docker-gs-ping:latest` you
+built:
+
+```console
+$ docker image tag docker-gs-ping:latest docker-gs-ping:v1.0
+```
+
+The Docker `tag` command creates a new tag for the image. It doesn't create a
+new image. The tag points to the same image and is another way to reference
+the image.
+
+Now run the `docker image ls` command again to see the updated list of local
+images:
+
+```console
+$ docker image ls
+
+REPOSITORY                       TAG       IMAGE ID       CREATED         SIZE
+docker-gs-ping                   latest    7f153fbcc0a8   6 minutes ago   1.11GB
+docker-gs-ping                   v1.0      7f153fbcc0a8   6 minutes ago   1.11GB
+...
+```
+
+You can see that you have two images that start with `docker-gs-ping`. You know
+they're the same image because if you look at the `IMAGE ID` column, you can
+see that the values are the same for the two images. This value is a unique
+identifier Docker uses internally to identify the image.
+
+Remove the tag that you just created. To do this, you’ll use the
+`docker image rm` command, or the shorthand `docker rmi` (which stands for
+"remove image"):
+
+```console
+$ docker image rm docker-gs-ping:v1.0
+Untagged: docker-gs-ping:v1.0
+```
+
+Notice that the response from Docker tells you that the image hasn't been
+removed but only untagged.
+
+Verify this by running the following command:
+
+```console
+$ docker image ls
+```
+
+You will see that the tag `v1.0` is no longer in the list of images kept by your Docker instance.
+
+```text
+REPOSITORY                       TAG       IMAGE ID       CREATED         SIZE
+docker-gs-ping                   latest    7f153fbcc0a8   7 minutes ago   1.11GB
+...
+```
+
+The tag `v1.0` has been removed but you still have the `docker-gs-ping:latest`
+tag available on your machine, so the image is there.
+
+### Multi-stage builds
+
+You may have noticed that your `docker-gs-ping` image weighs in at over a
+gigabyte, which is a lot for a tiny compiled Go application. You may also be
+wondering what happened to the full suite of Go tools, including the compiler,
+after you had built your image.
+
+The answer is that the full toolchain is still there, in the container image.
+Not only this is inconvenient because of the large file size, but it may also
+present a security risk when the container is deployed.
+
+These two issues can be solved by using [multi-stage builds](/manuals/build/building/multi-stage.md).
+
+In a nutshell, a multi-stage build can carry over the artifacts from one build stage into another,
+and every build stage can be instantiated from a different base image.
+
+Thus, in the following example, you are going to use a full-scale official Go
+image to build your application. Then you'll copy the application binary into
+another image whose base is very lean and doesn't include the Go toolchain or
+other optional components.
+
+The `Dockerfile.multistage` in the sample application's repository has the
+following content:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+# Build the application from source
+FROM golang:1.19 AS build-stage
+
+WORKDIR /app
+
+COPY go.mod go.sum ./
+RUN go mod download
+
+COPY *.go ./
+
+RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping
+
+# Run the tests in the container
+FROM build-stage AS run-test-stage
+RUN go test -v ./...
+
+# Deploy the application binary into a lean image
+FROM gcr.io/distroless/base-debian11 AS build-release-stage
+
+WORKDIR /
+
+COPY --from=build-stage /docker-gs-ping /docker-gs-ping
+
+EXPOSE 8080
+
+USER nonroot:nonroot
+
+ENTRYPOINT ["/docker-gs-ping"]
+```
+
+Since you have two Dockerfiles now, you have to tell Docker what Dockerfile
+you'd like to use to build the image. Tag the new image with `multistage`. This
+tag (like any other, apart from `latest`) has no special meaning for Docker,
+it's something you chose.
+
+```console
+$ docker build -t docker-gs-ping:multistage -f Dockerfile.multistage .
+```
+
+Comparing the sizes of `docker-gs-ping:multistage` and `docker-gs-ping:latest`
+you see a few orders-of-magnitude difference.
+
+```console
+$ docker image ls
+REPOSITORY       TAG          IMAGE ID       CREATED              SIZE
+docker-gs-ping   multistage   e3fdde09f172   About a minute ago   28.1MB
+docker-gs-ping   latest       336a3f164d0f   About an hour ago    1.11GB
+```
+
+This is so because the ["distroless"](https://github.com/GoogleContainerTools/distroless)
+base image that you have used in the second stage of the build is very barebones and is designed for lean deployments of static binaries.
+
+There's much more to multi-stage builds, including the possibility of multi-architecture builds,
+so feel free to check out [multi-stage builds](/manuals/build/building/multi-stage.md). This is, however, not essential for your progress here.
+
+## Run your Go image as a container
+
+### Prerequisites
+
+Work through the steps to containerize a Go application in [Build your Go image](#build-your-go-image).
+
+### Overview
+
+In the previous module you created a `Dockerfile` for your example application and then you created your Docker image using the command `docker build`. Now that you have the image, you can run that image and see if your application is running correctly.
+
+A container is a normal operating system process except that this process is isolated and has its own file system, its own networking, and its own isolated process tree separate from the host.
+
+To run an image inside of a container, you use the `docker run` command. It requires one parameter and that's the image name. Start your image and make sure it's running correctly. Run the following command in your terminal.
+
+```console
+$ docker run docker-gs-ping
+```
+
+```text
+   ____    __
+  / __/___/ /  ___
+ / _// __/ _ \/ _ \
+/___/\__/_//_/\___/ v4.10.2
+High performance, minimalist Go web framework
+https://echo.labstack.com
+____________________________________O/_______
+                                    O\
+⇨ http server started on [::]:8080
+```
+
+When you run this command, you’ll notice that you weren't returned to the command prompt. This is because your application is a REST server and will run in a loop waiting for incoming requests without returning control back to the OS until you stop the container.
+
+Make a GET request to the server using the curl command.
+
+```console
+$ curl http://localhost:8080/
+curl: (7) Failed to connect to localhost port 8080: Connection refused
+```
+
+Your curl command failed because the connection to your server was refused.
+Meaning that you weren't able to connect to localhost on port 8080. This is
+expected because your container is running in isolation which includes
+networking. Stop the container and restart with port 8080 published on your
+local network.
+
+To stop the container, press ctrl-c. This will return you to the terminal prompt.
+
+To publish a port for your container, you’ll use the `--publish` flag (`-p` for short) on the `docker run` command. The format of the `--publish` command is `[host_port]:[container_port]`. So if you wanted to expose port `8080` inside the container to port `3000` outside the container, you would pass `3000:8080` to the `--publish` flag.
+
+Start the container and expose port `8080` to port `8080` on the host.
+
+```console
+$ docker run --publish 8080:8080 docker-gs-ping
+```
+
+Now, rerun the curl command.
+
+```console
+$ curl http://localhost:8080/
+Hello, Docker! <3
+```
+
+Success! You were able to connect to the application running inside of your container on port 8080. Switch back to the terminal where your container is running and you should see the `GET` request logged to the console.
+
+Press `ctrl-c` to stop the container.
+
+### Run in detached mode
+
+This is great so far, but your sample application is a web server and you
+shouldn't have to have your terminal connected to the container. Docker can run
+your container in detached mode in the background. To do this, you can use the
+`--detach` or `-d` for short. Docker will start your container the same as
+before but this time will detach from the container and return you to the
+terminal prompt.
+
+```console
+$ docker run -d -p 8080:8080 docker-gs-ping
+d75e61fcad1e0c0eca69a3f767be6ba28a66625ce4dc42201a8a323e8313c14e
+```
+
+Docker started your container in the background and printed the container ID on the terminal.
+
+Again, make sure that your container is running. Run the same `curl` command:
+
+```console
+$ curl http://localhost:8080/
+Hello, Docker! <3
+```
+
+### List containers
+
+Since you ran your container in the background, how do you know if your container is running or what other containers are running on your machine? Well, to see a list of containers running on your machine, run `docker ps`. This is similar to how the ps command is used to see a list of processes on a Linux machine.
+
+```console
+$ docker ps
+
+CONTAINER ID   IMAGE            COMMAND             CREATED          STATUS          PORTS                    NAMES
+d75e61fcad1e   docker-gs-ping   "/docker-gs-ping"   41 seconds ago   Up 40 seconds   0.0.0.0:8080->8080/tcp   inspiring_ishizaka
+```
+
+The `ps` command tells you a bunch of stuff about your running containers. You can see the container ID, the image running inside the container, the command that was used to start the container, when it was created, the status, ports that are exposed, and the names of the container.
+
+You are probably wondering where the name of your container is coming from. Since you didn’t provide a name for the container when you started it, Docker generated a random name. You'll fix this in a minute but first you need to stop the container. To stop the container, run the `docker stop` command, passing the container's name or ID.
+
+```console
+$ docker stop inspiring_ishizaka
+inspiring_ishizaka
+```
+
+Now rerun the `docker ps` command to see a list of running containers.
+
+```console
+$ docker ps
+
+CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
+```
+
+### Stop, start, and name containers
+
+Docker containers can be started, stopped and restarted. When you stop a container, it's not removed but the status is changed to stopped and the process inside of the container is stopped. When you ran the `docker ps` command, the default output is to only show running containers. If you pass the `--all` or `-a` for short, you will see all containers on your system, including stopped containers and running containers.
+
+```console
+$ docker ps --all
+
+CONTAINER ID   IMAGE            COMMAND                  CREATED              STATUS                      PORTS     NAMES
+d75e61fcad1e   docker-gs-ping   "/docker-gs-ping"        About a minute ago   Exited (2) 23 seconds ago             inspiring_ishizaka
+f65dbbb9a548   docker-gs-ping   "/docker-gs-ping"        3 minutes ago        Exited (2) 2 minutes ago              wizardly_joliot
+aade1bf3d330   docker-gs-ping   "/docker-gs-ping"        3 minutes ago        Exited (2) 3 minutes ago              magical_carson
+52d5ce3c15f0   docker-gs-ping   "/docker-gs-ping"        9 minutes ago        Exited (2) 3 minutes ago              gifted_mestorf
+```
+
+If you’ve been following along, you should see several containers listed. These are containers that you started and stopped but haven't removed yet.
+
+Restart the container that you have just stopped. Locate the name of the container and replace the name of the container in the following `restart` command:
+
+```console
+$ docker restart inspiring_ishizaka
+```
+
+Now, list all the containers again using the `ps` command:
+
+```console
+$ docker ps -a
+
+CONTAINER ID   IMAGE            COMMAND                  CREATED          STATUS                     PORTS                    NAMES
+d75e61fcad1e   docker-gs-ping   "/docker-gs-ping"        2 minutes ago    Up 5 seconds               0.0.0.0:8080->8080/tcp   inspiring_ishizaka
+f65dbbb9a548   docker-gs-ping   "/docker-gs-ping"        4 minutes ago    Exited (2) 2 minutes ago                            wizardly_joliot
+aade1bf3d330   docker-gs-ping   "/docker-gs-ping"        4 minutes ago    Exited (2) 4 minutes ago                            magical_carson
+52d5ce3c15f0   docker-gs-ping   "/docker-gs-ping"        10 minutes ago   Exited (2) 4 minutes ago                            gifted_mestorf
+```
+
+Notice that the container you just restarted has been started in detached mode and has port `8080` exposed. Also, note that the status of the container is `Up X seconds`. When you restart a container, it will be started with the same flags or commands that it was originally started with.
+
+Stop and remove all of your containers and take a look at fixing the random naming issue.
+
+Stop the container you just started. Find the name of your running container and replace the name in the following command with the name of the container on your system:
+
+```console
+$ docker stop inspiring_ishizaka
+inspiring_ishizaka
+```
+
+Now that all of your containers are stopped, remove them. When a container is removed, it's no longer running nor is it in the stopped state. Instead, the process inside the container is terminated and the metadata for the container is removed.
+
+To remove a container, run the `docker rm` command passing the container name. You can pass multiple container names to the command in one command.
+
+Again, make sure you replace the containers names in the following command with the container names from your system:
+
+```console
+$ docker rm inspiring_ishizaka wizardly_joliot magical_carson gifted_mestorf
+
+inspiring_ishizaka
+wizardly_joliot
+magical_carson
+gifted_mestorf
+```
+
+Run the `docker ps --all` command again to verify that all containers are gone.
+
+Now, address the pesky random name issue. Standard practice is to name your containers for the simple reason that it's easier to identify what's running in the container and what application or service it's associated with. Just like good naming conventions for variables in your code makes it simpler to read. So goes naming your containers.
+
+To name a container, you must pass the `--name` flag to the `run` command:
+
+```console
+$ docker run -d -p 8080:8080 --name rest-server docker-gs-ping
+3bbc6a3102ea368c8b966e1878a5ea9b1fc61187afaac1276c41db22e4b7f48f
+```
+
+```console
+$ docker ps
+
+CONTAINER ID   IMAGE            COMMAND             CREATED          STATUS          PORTS                    NAMES
+3bbc6a3102ea   docker-gs-ping   "/docker-gs-ping"   25 seconds ago   Up 24 seconds   0.0.0.0:8080->8080/tcp   rest-server
+```
+
+Now, you can easily identify your container based on the name.
+
+## Use containers for Go development
+
+### Prerequisites
+
+Work through the steps of the [run your image as a container](#run-your-go-image-as-a-container) module to learn how to manage the lifecycle of your containers.
+
+### Introduction
+
+In this module, you'll take a look at running a database engine in a container and connecting it to the extended version of the example application. You are going to see some options for keeping persistent data and for wiring up the containers to talk to one another. Finally, you'll learn how to use Docker Compose to manage such multi-container local development environments effectively.
+
+### Local database and containers
+
+The database engine you are going to use is called [CockroachDB](https://www.cockroachlabs.com/product/). It is a modern, Cloud-native, distributed SQL database.
+
+Instead of compiling CockroachDB from the source code or using the operating system's native package manager to install CockroachDB, you are going to use the [Docker image for CockroachDB](https://hub.docker.com/r/cockroachdb/cockroach) and run it in a container.
+
+CockroachDB is compatible with PostgreSQL to a significant extent, and shares many conventions with the latter, particularly the default names for the environment variables. So, if you are familiar with Postgres, don't be surprised if you see some familiar environment variable names. The Go modules that work with Postgres, such as [pgx](https://pkg.go.dev/github.com/jackc/pgx), [pq](https://pkg.go.dev/github.com/lib/pq), [GORM](https://gorm.io/index.html), and [upper/db](https://upper.io/v4/) also work with CockroachDB.
+
+For more information on the relation between Go and CockroachDB, refer to the [CockroachDB documentation](https://www.cockroachlabs.com/docs/v20.2/build-a-go-app-with-cockroachdb.html), although this isn't necessary to continue with the present guide.
+
+#### Storage
+
+The point of a database is to have a persistent store of data. [Volumes](/manuals/engine/storage/volumes.md) are the preferred mechanism for persisting data generated by and used by Docker containers. Thus, before you start CockroachDB, create the volume for it.
+
+To create a managed volume, run :
+
+```console
+$ docker volume create roach
+roach
+```
+
+You can view the list of all managed volumes in your Docker instance with the following command:
+
+```console
+$ docker volume list
+DRIVER    VOLUME NAME
+local     roach
+```
+
+#### Networking
+
+The example application and the database engine are going to talk to one another over the network. There are different kinds of network configuration possible, and you're going to use what's called a user-defined bridge network. It is going to provide you with a DNS lookup service so that you can refer to your database engine container by its hostname.
+
+The following command creates a new bridge network named `mynet`:
+
+```console
+$ docker network create -d bridge mynet
+51344edd6430b5acd121822cacc99f8bc39be63dd125a3b3cd517b6485ab7709
+```
+
+As it was the case with the managed volumes, there is a command to list all networks set up in your Docker instance:
+
+```console
+$ docker network list
+NETWORK ID     NAME          DRIVER    SCOPE
+0ac2b1819fa4   bridge        bridge    local
+51344edd6430   mynet         bridge    local
+daed20bbecce   host          host      local
+6aee44f40a39   none          null      local
+```
+
+Your bridge network `mynet` has been created successfully. The other three networks, named `bridge`, `host`, and `none` are the default networks and they had been created by the Docker itself. While it's not relevant to this guide, you can learn more about Docker networking in the [networking overview](/manuals/engine/network/_index.md) section.
+
+#### Choose good names for volumes and networks
+
+As the saying goes, there are only two hard things in Computer Science: cache invalidation and naming things. And off-by-one errors.
+
+When choosing a name for a network or a managed volume, it's best to choose a name that's indicative of the intended purpose. This guide aims for brevity, so it used short, generic names.
+
+#### Start the database engine
+
+Now that the housekeeping chores are done, you can run CockroachDB in a container and attach it to the volume and network you had just created. When you run the following command, Docker will pull the image from Docker Hub and run it for you locally:
+
+```console
+$ docker run -d \
+  --name roach \
+  --hostname db \
+  --network mynet \
+  -p 26257:26257 \
+  -p 8080:8080 \
+  -v roach:/cockroach/cockroach-data \
+  cockroachdb/cockroach:latest-v25.4 start-single-node \
+  --insecure
+
+# ... output omitted ...
+```
+
+Notice a clever use of the tag `latest-v25.4` to make sure that you're pulling the latest patch version of 25.4. The diversity of available tags depend on the image maintainer. Here, your intent was to have the latest patched version of CockroachDB while not straying too far away from the known working version as the time goes by. To see the tags available for the CockroachDB image, you can go to the [CockroachDB page on Docker Hub](https://hub.docker.com/r/cockroachdb/cockroach/tags).
+
+#### Configure the database engine
+
+Now that the database engine is live, there is some configuration to do before your application can begin using it. Fortunately, it's not a lot. You must:
+
+1. Create a blank database.
+2. Register a new user account with the database engine.
+3. Grant that new user access rights to the database.
+
+You can do that with the help of CockroachDB built-in SQL shell. To start the SQL shell in the same container where the database engine is running, type:
+
+```console
+$ docker exec -it roach ./cockroach sql --insecure
+```
+
+1. In the SQL shell, create the database that the example application is going to use:
+
+   ```sql
+   CREATE DATABASE mydb;
+   ```
+
+2. Register a new SQL user account with the database engine. Use the username `totoro`.
+
+   ```sql
+   CREATE USER totoro;
+   ```
+
+3. Give the new user the necessary permissions:
+
+   ```sql
+   GRANT ALL ON DATABASE mydb TO totoro;
+   ```
+
+4. Type `quit` to exit the shell.
+
+The following is an example of interaction with the SQL shell.
+
+```console
+$ sudo docker exec -it roach ./cockroach sql --insecure
+#
+# Welcome to the CockroachDB SQL shell.
+# All statements must be terminated by a semicolon.
+# To exit, type: \q.
+#
+# Server version: CockroachDB CCL v20.1.15 (x86_64-unknown-linux-gnu, built 2021/04/26 16:11:58, go1.13.9) (same version as client)
+# Cluster ID: 7f43a490-ccd6-4c2a-9534-21f393ca80ce
+#
+# Enter \? for a brief introduction.
+#
+root@:26257/defaultdb> CREATE DATABASE mydb;
+CREATE DATABASE
+
+Time: 22.985478ms
+
+root@:26257/defaultdb> CREATE USER totoro;
+CREATE ROLE
+
+Time: 13.921659ms
+
+root@:26257/defaultdb> GRANT ALL ON DATABASE mydb TO totoro;
+GRANT
+
+Time: 14.217559ms
+
+root@:26257/defaultdb> quit
+oliver@hki:~$
+```
+
+#### Meet the example application
+
+Now that you have started and configured the database engine, you can switch your attention to the application.
+
+The example application for this module is an extended version of `docker-gs-ping` application you've used in the previous modules. You have two options:
+
+- You can update your local copy of `docker-gs-ping` to match the new extended version presented in this chapter; or
+- You can clone the [docker/docker-gs-ping-dev](https://github.com/docker/docker-gs-ping-dev) repository. This latter approach is recommended.
+
+To checkout the example application, run:
+
+```console
+$ git clone https://github.com/docker/docker-gs-ping-dev.git
+# ... output omitted ...
+```
+
+The application's `main.go` now includes database initialization code, as well as the code to implement a new business requirement:
+
+- An HTTP `POST` request to `/send` containing a `{ "value" : string }` JSON must save the value to the database.
+
+You also have an update for another business requirement. The requirement was:
+
+- The application responds with a text message containing a heart symbol ("`<3`") on requests to `/`.
+
+And now it's going to be:
+
+- The application responds with the string containing the count of messages stored in the database, enclosed in the parentheses.
+
+  Example output: `Hello, Docker! (7)`
+
+The full source code listing of `main.go` follows.
+
+```go
+package main
+
+import (
+	"context"
+	"database/sql"
+	"fmt"
+	"log"
+	"net/http"
+	"os"
+
+	"github.com/cenkalti/backoff/v4"
+	"github.com/cockroachdb/cockroach-go/v2/crdb"
+	"github.com/labstack/echo/v4"
+	"github.com/labstack/echo/v4/middleware"
+)
+
+func main() {
+
+	e := echo.New()
+
+	e.Use(middleware.Logger())
+	e.Use(middleware.Recover())
+
+	db, err := initStore()
+	if err != nil {
+		log.Fatalf("failed to initialize the store: %s", err)
+	}
+	defer db.Close()
+
+	e.GET("/", func(c echo.Context) error {
+		return rootHandler(db, c)
+	})
+
+	e.GET("/ping", func(c echo.Context) error {
+		return c.JSON(http.StatusOK, struct{ Status string }{Status: "OK"})
+	})
+
+	e.POST("/send", func(c echo.Context) error {
+		return sendHandler(db, c)
+	})
+
+	httpPort := os.Getenv("HTTP_PORT")
+	if httpPort == "" {
+		httpPort = "8080"
+	}
+
+	e.Logger.Fatal(e.Start(":" + httpPort))
+}
+
+type Message struct {
+	Value string `json:"value"`
+}
+
+func initStore() (*sql.DB, error) {
+
+	pgConnString := fmt.Sprintf("host=%s port=%s dbname=%s user=%s password=%s sslmode=disable",
+		os.Getenv("PGHOST"),
+		os.Getenv("PGPORT"),
+		os.Getenv("PGDATABASE"),
+		os.Getenv("PGUSER"),
+		os.Getenv("PGPASSWORD"),
+	)
+
+	var (
+		db  *sql.DB
+		err error
+	)
+	openDB := func() error {
+		db, err = sql.Open("postgres", pgConnString)
+		return err
+	}
+
+	err = backoff.Retry(openDB, backoff.NewExponentialBackOff())
+	if err != nil {
+		return nil, err
+	}
+
+	if _, err := db.Exec(
+		"CREATE TABLE IF NOT EXISTS message (value TEXT PRIMARY KEY)"); err != nil {
+		return nil, err
+	}
+
+	return db, nil
+}
+
+func rootHandler(db *sql.DB, c echo.Context) error {
+	r, err := countRecords(db)
+	if err != nil {
+		return c.HTML(http.StatusInternalServerError, err.Error())
+	}
+	return c.HTML(http.StatusOK, fmt.Sprintf("Hello, Docker! (%d)\n", r))
+}
+
+func sendHandler(db *sql.DB, c echo.Context) error {
+
+	m := &Message{}
+
+	if err := c.Bind(m); err != nil {
+		return c.JSON(http.StatusInternalServerError, err)
+	}
+
+	err := crdb.ExecuteTx(context.Background(), db, nil,
+		func(tx *sql.Tx) error {
+			_, err := tx.Exec(
+				"INSERT INTO message (value) VALUES ($1) ON CONFLICT (value) DO UPDATE SET value = excluded.value",
+				m.Value,
+			)
+			if err != nil {
+				return c.JSON(http.StatusInternalServerError, err)
+			}
+			return nil
+		})
+
+	if err != nil {
+		return c.JSON(http.StatusInternalServerError, err)
+	}
+
+	return c.JSON(http.StatusOK, m)
+}
+
+func countRecords(db *sql.DB) (int, error) {
+
+	rows, err := db.Query("SELECT COUNT(*) FROM message")
+	if err != nil {
+		return 0, err
+	}
+	defer rows.Close()
+
+	count := 0
+	for rows.Next() {
+		if err := rows.Scan(&count); err != nil {
+			return 0, err
+		}
+		rows.Close()
+	}
+
+	return count, nil
+}
+```
+
+The repository also includes the `Dockerfile`, which is almost exactly the same as the multi-stage `Dockerfile` introduced in the previous modules. It uses the official Docker Go image to build the application and then builds the final image by placing the compiled binary into the much slimmer, distroless image.
+
+Regardless of whether you had updated the old example application, or checked out the new one, this new Docker image has to be built to reflect the changes to the application source code.
+
+#### Build the application
+
+You can build the image with the familiar `build` command:
+
+```console
+$ docker build --tag docker-gs-ping-roach .
+```
+
+#### Run the application
+
+Now, run your container. This time you'll need to set some environment variables so that your application knows how to access the database. For now, you’ll do this right in the `docker run` command. Later you'll see a more convenient method with Docker Compose.
+
+> [!NOTE]
+>
+> Since you're running your CockroachDB cluster in insecure mode, the value for the password can be anything.
+>
+> In production, don't run in insecure mode.
+
+```console
+$ docker run -it --rm -d \
+  --network mynet \
+  --name rest-server \
+  -p 80:8080 \
+  -e PGUSER=totoro \
+  -e PGPASSWORD=myfriend \
+  -e PGHOST=db \
+  -e PGPORT=26257 \
+  -e PGDATABASE=mydb \
+  docker-gs-ping-roach
+```
+
+There are a few points to note about this command.
+
+- You map container port `8080` to host port `80` this time. Thus, for `GET` requests you can get away with literally `curl localhost`:
+
+  ```console
+  $ curl localhost
+  Hello, Docker! (0)
+  ```
+
+  Or, if you prefer, a proper URL would work just as well:
+
+  ```console
+  $ curl http://localhost/
+  Hello, Docker! (0)
+  ```
+
+- The total number of stored messages is `0` for now. This is fine, because you haven't posted anything to your application yet.
+- You refer to the database container by its hostname, which is `db`. This is why you had `--hostname db` when you started the database container.
+
+- The actual password doesn't matter, but it must be set to something to avoid confusing the example application.
+- The container you've just run is named `rest-server`. These names are useful for managing the container lifecycle:
+
+  ```console
+  # Don't do this just yet, it's only an example:
+  $ docker container rm --force rest-server
+  ```
+
+#### Test the application
+
+In the previous section, you've already tested querying your application with `GET` and it returned zero for the stored message counter. Now, post some messages to it:
+
+```console
+$ curl --request POST \
+  --url http://localhost/send \
+  --header 'content-type: application/json' \
+  --data '{"value": "Hello, Docker!"}'
+```
+
+The application responds with the contents of the message, which means it has been saved in the database:
+
+```json
+{ "value": "Hello, Docker!" }
+```
+
+Send another message:
+
+```console
+$ curl --request POST \
+  --url http://localhost/send \
+  --header 'content-type: application/json' \
+  --data '{"value": "Hello, Oliver!"}'
+```
+
+And again, you get the value of the message back:
+
+```json
+{ "value": "Hello, Oliver!" }
+```
+
+Run curl and see what the message counter says:
+
+```console
+$ curl localhost
+Hello, Docker! (2)
+```
+
+In this example, you sent two messages and the database kept them. Or has it? Stop and remove all your containers, but not the volumes, and try again.
+
+First, stop the containers:
+
+```console
+$ docker container stop rest-server roach
+rest-server
+roach
+```
+
+Then, remove them:
+
+```console
+$ docker container rm rest-server roach
+rest-server
+roach
+```
+
+Verify that they're gone:
+
+```console
+$ docker container list --all
+CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
+```
+
+And start them again, database first:
+
+```console
+$ docker run -d \
+  --name roach \
+  --hostname db \
+  --network mynet \
+  -p 26257:26257 \
+  -p 8080:8080 \
+  -v roach:/cockroach/cockroach-data \
+  cockroachdb/cockroach:latest-v25.4 start-single-node \
+  --insecure
+```
+
+And the service next:
+
+```console
+$ docker run -it --rm -d \
+  --network mynet \
+  --name rest-server \
+  -p 80:8080 \
+  -e PGUSER=totoro \
+  -e PGPASSWORD=myfriend \
+  -e PGHOST=db \
+  -e PGPORT=26257 \
+  -e PGDATABASE=mydb \
+  docker-gs-ping-roach
+```
+
+Lastly, query your service:
+
+```console
+$ curl localhost
+Hello, Docker! (2)
+```
+
+Great! The count of records from the database is correct although you haven't only stopped the containers, but you've also removed them before starting new instances. The difference is in the managed volume for CockroachDB, which you reused. The new CockroachDB container has read the database files from the disk, just as it normally would if it were running outside the container.
+
+#### Wind down everything
+
+Remember, that you're running CockroachDB in insecure mode. Now that you've built and tested your application, it's time to wind everything down before moving on. You can list the containers that you are running with the `list` command:
+
+```console
+$ docker container list
+```
+
+Now that you know the container IDs, you can use `docker container stop` and `docker container rm`, as demonstrated in the previous modules.
+
+Stop the CockroachDB and `docker-gs-ping-roach` containers before moving on.
+
+### Better productivity with Docker Compose
+
+At this point, you might be wondering if there is a way to avoid having to deal with long lists of arguments to the `docker` command. The toy example you used in this series requires five environment variables to define the connection to the database. A real application might need many, many more. Then there is also a question of dependencies. Ideally, you want to make sure that the database is started before your application is run. And spinning up the database instance may require another Docker command with many options. But there is a better way to orchestrate these deployments for local development purposes.
+
+In this section, you'll create a Docker Compose file to start your `docker-gs-ping-roach` application and CockroachDB database engine with a single command.
+
+#### Configure Docker Compose
+
+In your application's directory, create a new text file named `compose.yaml` with the following content.
+
+```yaml
+services:
+  docker-gs-ping-roach:
+    depends_on:
+      - roach
+    build:
+      context: .
+    container_name: rest-server
+    hostname: rest-server
+    networks:
+      - mynet
+    ports:
+      - 80:8080
+    environment:
+      - PGUSER=${PGUSER:-totoro}
+      - PGPASSWORD=${PGPASSWORD:?database password not set}
+      - PGHOST=${PGHOST:-db}
+      - PGPORT=${PGPORT:-26257}
+      - PGDATABASE=${PGDATABASE:-mydb}
+    deploy:
+      restart_policy:
+        condition: on-failure
+  roach:
+    image: cockroachdb/cockroach:latest-v25.4
+    container_name: roach
+    hostname: db
+    networks:
+      - mynet
+    ports:
+      - 26257:26257
+      - 8080:8080
+    volumes:
+      - roach:/cockroach/cockroach-data
+    command: start-single-node --insecure
+
+volumes:
+  roach:
+
+networks:
+  mynet:
+    driver: bridge
+```
+
+This Docker Compose configuration is super convenient as you don't have to type all the parameters to pass to the `docker run` command. You can declaratively do that in the Docker Compose file. The [Docker Compose documentation pages](/manuals/compose/_index.md) are quite extensive and include a full reference for the Docker Compose file format.
+
+#### The `.env` file
+
+Docker Compose will automatically read environment variables from a `.env` file if it's available. Since your Compose file requires `PGPASSWORD` to be set, add the following content to the `.env` file:
+
+```bash
+PGPASSWORD=whatever
+```
+
+The exact value doesn't really matter for this example, because you run CockroachDB in insecure mode. Make sure you set the variable to some value to avoid getting an error.
+
+#### Merging Compose files
+
+The filename `compose.yaml` is the default filename which `docker compose` command recognizes if no `-f` flag is provided. This means you can have multiple Docker Compose files if your environment has such requirements. Furthermore, Docker Compose files are composable, so multiple files can be specified on the command line to merge parts of the configuration together. The following list shows a few examples of scenarios where such a feature would be useful:
+
+- Using a bind mount for the source code for local development but not when running the CI tests;
+- Switching between using a pre-built image for the frontend for some API application vs creating a bind mount for source code;
+- Adding additional services for integration testing;
+- And many more...
+
+You aren't going to cover any of these advanced use cases here.
+
+#### Variable substitution in Docker Compose
+
+One of the really cool features of Docker Compose is [variable substitution](/reference/compose-file/interpolation.md). You can see some examples in the Compose file, `environment` section. By means of an example:
+
+- `PGUSER=${PGUSER:-totoro}` means that inside the container, the environment variable `PGUSER` shall be set to the same value as it has on the host machine where Docker Compose is run. If there is no environment variable with this name on the host machine, the variable inside the container gets the default value of `totoro`.
+- `PGPASSWORD=${PGPASSWORD:?database password not set}` means that if the environment variable `PGPASSWORD` isn't set on the host, Docker Compose will display an error. This is OK, because you don't want to hard-code default values for the password. You set the password value in the `.env` file, which is local to your machine. It is always a good idea to add `.env` to `.gitignore` to prevent the secrets being checked into the version control.
+
+Other ways of dealing with undefined or empty values exist, as documented in the [variable substitution](/reference/compose-file/interpolation.md) section of the Docker documentation.
+
+#### Validating Docker Compose configuration
+
+Before you apply changes made to a Compose configuration file, there is an opportunity to validate the content of the configuration file with the following command:
+
+```console
+$ docker compose config
+```
+
+When this command is run, Docker Compose reads the file `compose.yaml`, parses it into a data structure in memory, validates where possible, and prints back the reconstruction of that configuration file from its internal representation. If this isn't possible due to errors, Docker prints an error message instead.
+
+#### Build and run the application using Docker Compose
+
+Start your application and confirm that it's running.
+
+```console
+$ docker compose up --build
+```
+
+You passed the `--build` flag so Docker will compile your image and then start it.
+
+> [!NOTE]
+>
+> Docker Compose is a useful tool, but it has its own quirks. For example, no rebuild is triggered on the update to the source code unless the `--build` flag is provided. It is a very common pitfall to edit one's source code, and forget to use the `--build` flag when running `docker compose up`.
+
+Since your set-up is now run by Docker Compose, it has assigned it a project name, so you get a new volume for your CockroachDB instance. This means that your application will fail to connect to the database, because the database doesn't exist in this new volume. The terminal displays an authentication error for the database:
+
+```text
+# ... omitted output ...
+rest-server             | 2021/05/10 00:54:25 failed to initialise the store: pq: password authentication failed for user totoro
+roach                   | *
+roach                   | * INFO: Replication was disabled for this cluster.
+roach                   | * When/if adding nodes in the future, update zone configurations to increase the replication factor.
+roach                   | *
+roach                   | CockroachDB node starting at 2021-05-10 00:54:26.398177 +0000 UTC (took 3.0s)
+roach                   | build:               CCL v20.1.15 @ 2021/04/26 16:11:58 (go1.13.9)
+roach                   | webui:               http://db:8080
+roach                   | sql:                 postgresql://root@db:26257?sslmode=disable
+roach                   | RPC client flags:    /cockroach/cockroach <client cmd> --host=db:26257 --insecure
+roach                   | logs:                /cockroach/cockroach-data/logs
+roach                   | temp dir:            /cockroach/cockroach-data/cockroach-temp349434348
+roach                   | external I/O path:   /cockroach/cockroach-data/extern
+roach                   | store[0]:            path=/cockroach/cockroach-data
+roach                   | storage engine:      rocksdb
+roach                   | status:              initialized new cluster
+roach                   | clusterID:           b7b1cb93-558f-4058-b77e-8a4ddb329a88
+roach                   | nodeID:              1
+rest-server exited with code 0
+rest-server             | 2021/05/10 00:54:25 failed to initialise the store: pq: password authentication failed for user totoro
+rest-server             | 2021/05/10 00:54:26 failed to initialise the store: pq: password authentication failed for user totoro
+rest-server             | 2021/05/10 00:54:29 failed to initialise the store: pq: password authentication failed for user totoro
+rest-server             | 2021/05/10 00:54:25 failed to initialise the store: pq: password authentication failed for user totoro
+rest-server             | 2021/05/10 00:54:26 failed to initialise the store: pq: password authentication failed for user totoro
+rest-server             | 2021/05/10 00:54:29 failed to initialise the store: pq: password authentication failed for user totoro
+rest-server exited with code 1
+# ... omitted output ...
+```
+
+Because of the way you set up your deployment using `restart_policy`, the failing container is being restarted every 20 seconds. So, in order to fix the problem, you need to log in to the database engine and create the user. You've done it before in [Configure the database engine](#configure-the-database-engine).
+
+This isn't a big deal. All you have to do is to connect to CockroachDB instance and run the three SQL commands to create the database and the user, as described in [Configure the database engine](#configure-the-database-engine).
+
+So, log in to the database engine from another terminal:
+
+```console
+$ docker exec -it roach ./cockroach sql --insecure
+```
+
+And run the same commands as before to create the database `mydb`, the user `totoro`, and to grant that user necessary permissions. Once you do that (and the example application container is automatically restarts), the `rest-service` stops failing and restarting and the console goes quiet.
+
+It would have been possible to connect the volume that you had previously used, but for the purposes of this example it's more trouble than it's worth and it also provided an opportunity to show how to introduce resilience into your deployment via the `restart_policy` Compose file feature.
+
+#### Testing the application
+
+Now, test your API endpoint. In the new terminal, run the following command:
+
+```console
+$ curl http://localhost/
+```
+
+You should receive the following response:
+
+```json
+Hello, Docker! (0)
+```
+
+#### Shutting down
+
+To stop the containers started by Docker Compose, press `ctrl+c` in the terminal where you ran `docker compose up`. To remove those containers after they've been stopped, run `docker compose down`.
+
+#### Detached mode
+
+You can run containers started by the `docker compose` command in detached mode, just as you would with the `docker` command, by using the `-d` flag.
+
+To start the stack, defined by the Compose file in detached mode, run:
+
+```console
+$ docker compose up --build -d
+```
+
+Then, you can use `docker compose stop` to stop the containers and `docker compose down` to remove them.
+
+### Further exploration
+
+You can run `docker compose` to see what other commands are available.
+
+### Wrap up
+
+There are some tangential, yet interesting points that were purposefully not covered in this chapter. For the more adventurous reader, this section offers some pointers for further study.
+
+#### Persistent storage
+
+A managed volume isn't the only way to provide your container with persistent storage. It is highly recommended to get acquainted with available storage options and their use cases, covered in [Manage data in Docker](/manuals/engine/storage/_index.md).
+
+#### CockroachDB clusters
+
+You ran a single instance of CockroachDB, which was enough for this example. But, it's possible to run a CockroachDB cluster, which is made of multiple instances of CockroachDB, each instance running in its own container. Since CockroachDB engine is distributed by design, it would have taken surprisingly little change to your procedure to run a cluster with multiple nodes.
+
+Such distributed set-up offers interesting possibilities, such as applying Chaos Engineering techniques to simulate parts of the cluster failing and evaluating your application's ability to cope with such failures.
+
+If you are interested in experimenting with CockroachDB clusters, check out:
+
+- [Start a CockroachDB Cluster in Docker](https://www.cockroachlabs.com/docs/v20.2/start-a-local-cluster-in-docker-mac.html) article; and
+- Documentation for Docker Compose keywords [`deploy`](/reference/compose-file/legacy-versions.md) and [`replicas`](/reference/compose-file/legacy-versions.md).
+
+#### Other databases
+
+Since you didn't run a cluster of CockroachDB instances, you might be wondering whether you could have used a non-distributed database engine. The answer is 'yes', and if you were to pick a more traditional SQL database, such as [PostgreSQL](https://www.postgresql.org/), the process described in this chapter would have been very similar.
+
+## Run your tests using Go test
+
+### Prerequisites
+
+Complete the [Build your Go image](#build-your-go-image) section of this guide.
+
+### Overview
+
+Testing is an essential part of modern software development. Testing can mean a
+lot of things to different development teams. There are unit tests, integration
+tests and end-to-end testing. In this guide you take a look at running your unit
+tests in Docker when building.
+
+For this section, use the `docker-gs-ping` project that you cloned in [Build
+your Go image](#build-your-go-image).
+
+### Run tests when building
+
+To run your tests when building, you need to add a test stage to the
+`Dockerfile.multistage`. The `Dockerfile.multistage` in the sample application's
+repository already has the following content:
+
+```dockerfile {hl_lines="15-17"}
+# syntax=docker/dockerfile:1
+
+# Build the application from source
+FROM golang:1.19 AS build-stage
+
+WORKDIR /app
+
+COPY go.mod go.sum ./
+RUN go mod download
+
+COPY *.go ./
+
+RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping
+
+# Run the tests in the container
+FROM build-stage AS run-test-stage
+RUN go test -v ./...
+
+# Deploy the application binary into a lean image
+FROM gcr.io/distroless/base-debian11 AS build-release-stage
+
+WORKDIR /
+
+COPY --from=build-stage /docker-gs-ping /docker-gs-ping
+
+EXPOSE 8080
+
+USER nonroot:nonroot
+
+ENTRYPOINT ["/docker-gs-ping"]
+```
+
+Run the following command to build an image using the `run-test-stage` stage as the target and view the test results. Include `--progress plain` to view the build output, `--no-cache` to ensure the tests always run, and `--target run-test-stage` to target the test stage.
+
+```console
+$ docker build -f Dockerfile.multistage -t docker-gs-ping-test --progress plain --no-cache --target run-test-stage .
+```
+
+You should see output containing the following.
+
+```text
+#13 [run-test-stage 1/1] RUN go test -v ./...
+#13 4.915 === RUN   TestIntMinBasic
+#13 4.915 --- PASS: TestIntMinBasic (0.00s)
+#13 4.915 === RUN   TestIntMinTableDriven
+#13 4.915 === RUN   TestIntMinTableDriven/0,1
+#13 4.915 === RUN   TestIntMinTableDriven/1,0
+#13 4.915 === RUN   TestIntMinTableDriven/2,-2
+#13 4.915 === RUN   TestIntMinTableDriven/0,-1
+#13 4.915 === RUN   TestIntMinTableDriven/-1,0
+#13 4.915 --- PASS: TestIntMinTableDriven (0.00s)
+#13 4.915     --- PASS: TestIntMinTableDriven/0,1 (0.00s)
+#13 4.915     --- PASS: TestIntMinTableDriven/1,0 (0.00s)
+#13 4.915     --- PASS: TestIntMinTableDriven/2,-2 (0.00s)
+#13 4.915     --- PASS: TestIntMinTableDriven/0,-1 (0.00s)
+#13 4.915     --- PASS: TestIntMinTableDriven/-1,0 (0.00s)
+#13 4.915 PASS
+```
diff --git a/content/guides/golang/_index.md b/content/guides/golang/_index.md
deleted file mode 100644
index 7d63660706a7..000000000000
--- a/content/guides/golang/_index.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Go language-specific guide
-linkTitle: Go
-description: Containerize Go apps using Docker
-keywords: docker, getting started, go, golang, language, dockerfile
-summary: |
-  This guide teaches you how to containerize Go applications using Docker.
-toc_min: 1
-toc_max: 2
-aliases:
-  - /language/golang/
-  - /guides/language/golang/
-languages: [go]
-params:
-  time: 30 minutes
----
-
-This guide will show you how to create, test, and deploy containerized Go applications using Docker.
-
-> **Acknowledgment**
->
-> Docker would like to thank [Oliver Frolovs](https://www.linkedin.com/in/ofr/) for his contribution to this guide.
-
-## What will you learn?
-
-In this guide, you’ll learn how to:
-
-- Create a `Dockerfile` which contains the instructions for building a container image for a program written in Go.
-- Run the image as a container in your local Docker instance and manage the container's lifecycle.
-- Use multi-stage builds for building small images efficiently while keeping your Dockerfiles easy to read and maintain.
-- Use Docker Compose to orchestrate running of multiple related containers together in a development environment.
-- Configure a CI/CD pipeline for your application using [GitHub Actions](https://docs.github.com/en/actions)
-- Deploy your containerized Go application.
-
-## Prerequisites
-
-Some basic understanding of Go and its toolchain is assumed. This isn't a Go tutorial. If you are new to the : languages:,
-the [Go website](https://golang.org/) is a great place to explore,
-so _go_ (pun intended) check it out!
-
-You also must know some basic [Docker concepts](/get-started/docker-concepts/the-basics/what-is-a-container.md) as well as to
-be at least vaguely familiar with the [Dockerfile format](/manuals/build/concepts/dockerfile.md).
-
-Your Docker set-up must have BuildKit enabled. BuildKit is enabled by default for all users on [Docker Desktop](/manuals/desktop/_index.md).
-If you have installed Docker Desktop, you don’t have to manually enable BuildKit. If you are running Docker on Linux,
-please check out BuildKit [getting started](/manuals/build/buildkit/_index.md#getting-started) page.
-
-Some familiarity with the command line is also expected.
-
-## What's next?
-
-The aim of this guide is to provide enough examples and instructions for you to containerize your own Go application and deploy it into the Cloud.
-
-Start by building your first Go image.
diff --git a/content/guides/golang/build-images.md b/content/guides/golang/build-images.md
deleted file mode 100644
index 68696baf2bc7..000000000000
--- a/content/guides/golang/build-images.md
+++ /dev/null
@@ -1,489 +0,0 @@
----
-title: Build your Go image
-linkTitle: Build images
-weight: 5
-keywords: containers, images, go, golang, dockerfiles, coding, build, push, run
-description: Learn how to build your first Docker image by writing a Dockerfile
-aliases:
-  - /get-started/golang/build-images/
-  - /language/golang/build-images/
-  - /guides/language/golang/build-images/
----
-
-## Overview
-
-In this section you're going to build a container image. The image includes
-everything you need to run your application – the compiled application binary
-file, the runtime, the libraries, and all other resources required by your
-application.
-
-## Required software
-
-To complete this tutorial, you need the following:
-
-- Docker running locally. Follow the [instructions to download and install Docker](/manuals/desktop/_index.md).
-- An IDE or a text editor to edit files. [Visual Studio Code](https://code.visualstudio.com/) is a free and popular choice but you can use anything you feel comfortable with.
-- A Git client. This guide uses a command-line based `git` client, but you are free to use whatever works for you.
-- A command-line terminal application. The examples shown in this module are from the Linux shell, but they should work in PowerShell, Windows Command Prompt, or OS X Terminal with minimal, if any, modifications.
-
-## Meet the example application
-
-The example application is a caricature of a microservice. It is purposefully trivial to keep focus on learning the basics of containerization for Go applications.
-
-The application offers two HTTP endpoints:
-
-- It responds with a string containing a heart symbol (`<3`) to requests to `/`.
-- It responds with `{"Status" : "OK"}` JSON to a request to `/health`.
-
-It responds with HTTP error 404 to any other request.
-
-The application listens on a TCP port defined by the value of environment variable `PORT`. The default value is `8080`.
-
-The application is stateless.
-
-The complete source code for the application is on GitHub: [github.com/docker/docker-gs-ping](https://github.com/docker/docker-gs-ping). You are encouraged to fork it and experiment with it as much as you like.
-
-To continue, clone the application repository to your local machine:
-
-```console
-$ git clone https://github.com/docker/docker-gs-ping
-```
-
-The application's `main.go` file is straightforward, if you are familiar with Go:
-
-```go
-package main
-
-import (
-	"net/http"
-	"os"
-
-	"github.com/labstack/echo/v4"
-	"github.com/labstack/echo/v4/middleware"
-)
-
-func main() {
-
-	e := echo.New()
-
-	e.Use(middleware.Logger())
-	e.Use(middleware.Recover())
-
-	e.GET("/", func(c echo.Context) error {
-		return c.HTML(http.StatusOK, "Hello, Docker! <3")
-	})
-
-	e.GET("/health", func(c echo.Context) error {
-		return c.JSON(http.StatusOK, struct{ Status string }{Status: "OK"})
-	})
-
-	httpPort := os.Getenv("PORT")
-	if httpPort == "" {
-		httpPort = "8080"
-	}
-
-	e.Logger.Fatal(e.Start(":" + httpPort))
-}
-
-// Simple implementation of an integer minimum
-// Adapted from: https://gobyexample.com/testing-and-benchmarking
-func IntMin(a, b int) int {
-	if a < b {
-		return a
-	}
-	return b
-}
-```
-
-## Create a Dockerfile for the application
-
-To build a container image with Docker, a `Dockerfile` with build instructions is required.
-
-Begin your `Dockerfile` with the (optional) parser directive line that instructs BuildKit to
-interpret your file according to the grammar rules for the specified version of the syntax.
-
-You then tell Docker what base image you would like to use for your application:
-
-```dockerfile
-# syntax=docker/dockerfile:1
-
-FROM golang:1.19
-```
-
-Docker images can be inherited from other images. Therefore, instead of creating
-your own base image from scratch, you can use the official Go image that already
-has all necessary tools and libraries to compile and run a Go application.
-
-> [!NOTE]
->
-> If you are curious about creating your own base images, you can check out the following section of this guide: [creating base images](/manuals/build/building/base-images.md#create-a-base-image).
-> Note, however, that this isn't necessary to continue with your task at hand.
-
-Now that you have defined the base image for your upcoming container image, you
-can begin building on top of it.
-
-To make things easier when running the rest of your commands, create a directory
-inside the image that you're building. This also instructs Docker to use this
-directory as the default destination for all subsequent commands. This way you
-don't have to type out full file paths in the `Dockerfile`, the relative paths
-will be based on this directory.
-
-```dockerfile
-WORKDIR /app
-```
-
-Usually the very first thing you do once you’ve downloaded a project written in
-Go is to install the modules necessary to compile it. Note, that the base image
-has the toolchain already, but your source code isn't in it yet.
-
-So before you can run `go mod download` inside your image, you need to get your
-`go.mod` and `go.sum` files copied into it. Use the `COPY` command to do this.
-
-In its simplest form, the `COPY` command takes two parameters. The first
-parameter tells Docker what files you want to copy into the image. The last
-parameter tells Docker where you want that file to be copied to.
-
-Copy the `go.mod` and `go.sum` file into your project directory `/app` which,
-owing to your use of `WORKDIR`, is the current directory (`./`) inside the
-image. Unlike some modern shells that appear to be indifferent to the use of
-trailing slash (`/`), and can figure out what the user meant (most of the time),
-Docker's `COPY` command is quite sensitive in its interpretation of the trailing
-slash.
-
-```dockerfile
-COPY go.mod go.sum ./
-```
-
-> [!NOTE]
->
-> If you'd like to familiarize yourself with the trailing slash treatment by the
-> `COPY` command, see [Dockerfile
-> reference](/reference/dockerfile.md#copy). This trailing slash can
-> cause issues in more ways than you can imagine.
-
-Now that you have the module files inside the Docker image that you are
-building, you can use the `RUN` command to run the command `go mod download`
-there as well. This works exactly the same as if you were running `go` locally
-on your machine, but this time these Go modules will be installed into a
-directory inside the image.
-
-```dockerfile
-RUN go mod download
-```
-
-At this point, you have a Go toolchain version 1.19.x and all your Go
-dependencies installed inside the image.
-
-The next thing you need to do is to copy your source code into the image. You’ll
-use the `COPY` command just like you did with your module files before.
-
-```dockerfile
-COPY *.go ./
-```
-
-This `COPY` command uses a wildcard to copy all files with `.go` extension
-located in the current directory on the host (the directory where the `Dockerfile`
-is located) into the current directory inside the image.
-
-Now, to compile your application, use the familiar `RUN` command:
-
-```dockerfile
-RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping
-```
-
-This should be familiar. The result of that command will be a static application
-binary named `docker-gs-ping` and located in the root of the filesystem of the
-image that you are building. You could have put the binary into any other place
-you desire inside that image, the root directory has no special meaning in this
-regard. It's just convenient to use it to keep the file paths short for improved
-readability.
-
-Now, all that is left to do is to tell Docker what command to run when your
-image is used to start a container.
-
-You do this with the `CMD` command:
-
-```dockerfile
-CMD ["/docker-gs-ping"]
-```
-
-Here's the complete `Dockerfile`:
-
-```dockerfile
-# syntax=docker/dockerfile:1
-
-FROM golang:1.19
-
-# Set destination for COPY
-WORKDIR /app
-
-# Download Go modules
-COPY go.mod go.sum ./
-RUN go mod download
-
-# Copy the source code. Note the slash at the end, as explained in
-# https://docs.docker.com/reference/dockerfile/#copy
-COPY *.go ./
-
-# Build
-RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping
-
-# Optional:
-# To bind to a TCP port, runtime parameters must be supplied to the docker command.
-# But we can document in the Dockerfile what ports
-# the application is going to listen on by default.
-# https://docs.docker.com/reference/dockerfile/#expose
-EXPOSE 8080
-
-# Run
-CMD ["/docker-gs-ping"]
-```
-
-The `Dockerfile` may also contain comments. They always begin with a `#` symbol,
-and must be at the beginning of a line. Comments are there for your convenience
-to allow documenting your `Dockerfile`.
-
-There is also a concept of Dockerfile directives, such as the `syntax` directive
-you added. The directives must always be at the very top of the `Dockerfile`, so
-when adding comments, make sure that the comments follow after any directives
-that you may have used:
-
-```dockerfile
-# syntax=docker/dockerfile:1
-# A sample microservice in Go packaged into a container image.
-
-FROM golang:1.19
-
-# ...
-```
-
-## Build the image
-
-Now that you've created your `Dockerfile`, build an image from it. The `docker
-build` command creates Docker images from the `Dockerfile` and a context. A
-build context is the set of files located in the specified path or URL. The
-Docker build process can access any of the files located in the context.
-
-The build command optionally takes a `--tag` flag. This flag is used to label
-the image with a string value, which is easy for humans to read and recognize.
-If you don't pass a `--tag`, Docker will use `latest` as the default value.
-
-Build your first Docker image.
-
-```console
-$ docker build --tag docker-gs-ping .
-```
-
-The build process will print some diagnostic messages as it goes through the build steps.
-The following is just an example of what these messages may look like.
-
-```console
-[+] Building 2.2s (15/15) FINISHED
- => [internal] load build definition from Dockerfile                                                                                       0.0s
- => => transferring dockerfile: 701B                                                                                                       0.0s
- => [internal] load .dockerignore                                                                                                          0.0s
- => => transferring context: 2B                                                                                                            0.0s
- => resolve image config for docker.io/docker/dockerfile:1                                                                                 1.1s
- => CACHED docker-image://docker.io/docker/dockerfile:1@sha256:39b85bbfa7536a5feceb7372a0817649ecb2724562a38360f4d6a7782a409b14            0.0s
- => [internal] load build definition from Dockerfile                                                                                       0.0s
- => [internal] load .dockerignore                                                                                                          0.0s
- => [internal] load metadata for docker.io/library/golang:1.19                                                                             0.7s
- => [1/6] FROM docker.io/library/golang:1.19@sha256:5d947843dde82ba1df5ac1b2ebb70b203d106f0423bf5183df3dc96f6bc5a705                       0.0s
- => [internal] load build context                                                                                                          0.0s
- => => transferring context: 6.08kB                                                                                                        0.0s
- => CACHED [2/6] WORKDIR /app                                                                                                              0.0s
- => CACHED [3/6] COPY go.mod go.sum ./                                                                                                     0.0s
- => CACHED [4/6] RUN go mod download                                                                                                       0.0s
- => CACHED [5/6] COPY *.go ./                                                                                                              0.0s
- => CACHED [6/6] RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping                                                                  0.0s
- => exporting to image                                                                                                                     0.0s
- => => exporting layers                                                                                                                    0.0s
- => => writing image sha256:ede8ff889a0d9bc33f7a8da0673763c887a258eb53837dd52445cdca7b7df7e3                                               0.0s
- => => naming to docker.io/library/docker-gs-ping                                                                                          0.0s
-```
-
-Your exact output will vary, but provided there aren't any errors, you should
-see the word `FINISHED` in the first line of output. This means Docker has
-successfully built your image named `docker-gs-ping`.
-
-## View local images
-
-To see the list of images you have on your local machine, you have two options.
-One is to use the CLI and the other is to use [Docker
-Desktop](/manuals/desktop/_index.md). Since you're currently working in the
-terminal, take a look at listing images with the CLI.
-
-To list images, run the `docker image ls`command (or the `docker images` shorthand):
-
-```console
-$ docker image ls
-
-REPOSITORY                       TAG       IMAGE ID       CREATED         SIZE
-docker-gs-ping                   latest    7f153fbcc0a8   2 minutes ago   1.11GB
-...
-```
-
-Your exact output may vary, but you should see the `docker-gs-ping` image with
-the `latest` tag. Because you didn't specify a custom tag when you built your
-image, Docker assumed that the tag would be `latest`, which is a special value.
-
-## Tag images
-
-An image name is made up of slash-separated name components. Name components may
-contain lowercase letters, digits, and separators. A separator is defined as a
-period, one or two underscores, or one or more dashes. A name component may not
-start or end with a separator.
-
-An image is made up of a manifest and a list of layers. In simple terms, a tag
-points to a combination of these artifacts. You can have multiple tags for the
-image and, in fact, most images have multiple tags. Create a second tag
-for the image you built and take a look at its layers.
-
-Use the `docker image tag` (or `docker tag` shorthand) command to create a new
-tag for your image. This command takes two arguments; the first argument is the
-source image, and the second is the new tag to create. The following command
-creates a new `docker-gs-ping:v1.0` tag for the `docker-gs-ping:latest` you
-built:
-
-```console
-$ docker image tag docker-gs-ping:latest docker-gs-ping:v1.0
-```
-
-The Docker `tag` command creates a new tag for the image. It doesn't create a
-new image. The tag points to the same image and is just another way to reference
-the image.
-
-Now run the `docker image ls` command again to see the updated list of local
-images:
-
-```console
-$ docker image ls
-
-REPOSITORY                       TAG       IMAGE ID       CREATED         SIZE
-docker-gs-ping                   latest    7f153fbcc0a8   6 minutes ago   1.11GB
-docker-gs-ping                   v1.0      7f153fbcc0a8   6 minutes ago   1.11GB
-...
-```
-
-You can see that you have two images that start with `docker-gs-ping`. You know
-they're the same image because if you look at the `IMAGE ID` column, you can
-see that the values are the same for the two images. This value is a unique
-identifier Docker uses internally to identify the image.
-
-Remove the tag that you just created. To do this, you’ll use the
-`docker image rm` command, or the shorthand `docker rmi` (which stands for
-"remove image"):
-
-```console
-$ docker image rm docker-gs-ping:v1.0
-Untagged: docker-gs-ping:v1.0
-```
-
-Notice that the response from Docker tells you that the image hasn't been
-removed but only untagged.
-
-Verify this by running the following command:
-
-```console
-$ docker image ls
-```
-
-You will see that the tag `v1.0` is no longer in the list of images kept by your Docker instance.
-
-```text
-REPOSITORY                       TAG       IMAGE ID       CREATED         SIZE
-docker-gs-ping                   latest    7f153fbcc0a8   7 minutes ago   1.11GB
-...
-```
-
-The tag `v1.0` has been removed but you still have the `docker-gs-ping:latest`
-tag available on your machine, so the image is there.
-
-## Multi-stage builds
-
-You may have noticed that your `docker-gs-ping` image weighs in at over a
-gigabyte, which is a lot for a tiny compiled Go application. You may also be
-wondering what happened to the full suite of Go tools, including the compiler,
-after you had built your image.
-
-The answer is that the full toolchain is still there, in the container image.
-Not only this is inconvenient because of the large file size, but it may also
-present a security risk when the container is deployed.
-
-These two issues can be solved by using [multi-stage builds](/manuals/build/building/multi-stage.md).
-
-In a nutshell, a multi-stage build can carry over the artifacts from one build stage into another,
-and every build stage can be instantiated from a different base image.
-
-Thus, in the following example, you are going to use a full-scale official Go
-image to build your application. Then you'll copy the application binary into
-another image whose base is very lean and doesn't include the Go toolchain or
-other optional components.
-
-The `Dockerfile.multistage` in the sample application's repository has the
-following content:
-
-```dockerfile
-# syntax=docker/dockerfile:1
-
-# Build the application from source
-FROM golang:1.19 AS build-stage
-
-WORKDIR /app
-
-COPY go.mod go.sum ./
-RUN go mod download
-
-COPY *.go ./
-
-RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping
-
-# Run the tests in the container
-FROM build-stage AS run-test-stage
-RUN go test -v ./...
-
-# Deploy the application binary into a lean image
-FROM gcr.io/distroless/base-debian11 AS build-release-stage
-
-WORKDIR /
-
-COPY --from=build-stage /docker-gs-ping /docker-gs-ping
-
-EXPOSE 8080
-
-USER nonroot:nonroot
-
-ENTRYPOINT ["/docker-gs-ping"]
-```
-
-Since you have two Dockerfiles now, you have to tell Docker what Dockerfile
-you'd like to use to build the image. Tag the new image with `multistage`. This
-tag (like any other, apart from `latest`) has no special meaning for Docker,
-it's just something you chose.
-
-```console
-$ docker build -t docker-gs-ping:multistage -f Dockerfile.multistage .
-```
-
-Comparing the sizes of `docker-gs-ping:multistage` and `docker-gs-ping:latest`
-you see a few orders-of-magnitude difference.
-
-```console
-$ docker image ls
-REPOSITORY       TAG          IMAGE ID       CREATED              SIZE
-docker-gs-ping   multistage   e3fdde09f172   About a minute ago   28.1MB
-docker-gs-ping   latest       336a3f164d0f   About an hour ago    1.11GB
-```
-
-This is so because the ["distroless"](https://github.com/GoogleContainerTools/distroless)
-base image that you have used in the second stage of the build is very barebones and is designed for lean deployments of static binaries.
-
-There's much more to multi-stage builds, including the possibility of multi-architecture builds,
-so feel free to check out [multi-stage builds](/manuals/build/building/multi-stage.md). This is, however, not essential for your progress here.
-
-## Next steps
-
-In this module, you met your example application and built and container image
-for it.
-
-In the next module, you’ll take a look at how to run your image as a container.
diff --git a/content/guides/golang/configure-ci-cd.md b/content/guides/golang/configure-ci-cd.md
deleted file mode 100644
index 2bfe44c85dbd..000000000000
--- a/content/guides/golang/configure-ci-cd.md
+++ /dev/null
@@ -1,133 +0,0 @@
----
-title: Configure CI/CD for your Go application
-linkTitle: Configure CI/CD
-weight: 40
-keywords: go, CI/CD, local, development
-description: Learn how to Configure CI/CD for your Go application
-aliases:
-  - /language/golang/configure-ci-cd/
-  - /guides/language/golang/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete the previous sections of this guide, starting with [Build your Go image](build-images.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-## Overview
-
-In this section, you'll learn how to set up and use GitHub Actions to build and push your Docker image to Docker Hub. You will complete the following steps:
-
-1. Create a new repository on GitHub.
-2. Define the GitHub Actions workflow.
-3. Run the workflow.
-
-## Step one: Create the repository
-
-Create a GitHub repository, configure the Docker Hub credentials, and push your source code.
-
-1. [Create a new repository](https://github.com/new) on GitHub.
-
-2. Open the repository **Settings**, and go to **Secrets and variables** >
-   **Actions**.
-
-3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-4. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-5. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-6. In your local repository on your machine, run the following command to change
-   the origin to the repository you just created. Make sure you change
-   `your-username` to your GitHub username and `your-repository` to the name of
-   the repository you created.
-
-   ```console
-   $ git remote set-url origin https://github.com/your-username/your-repository.git
-   ```
-
-7. Run the following commands to stage, commit, and push your local repository to GitHub.
-
-   ```console
-   $ git add -A
-   $ git commit -m "my commit"
-   $ git push -u origin main
-   ```
-
-## Step two: Set up the workflow
-
-Set up your GitHub Actions workflow for building, testing, and pushing the image
-to Docker Hub.
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-
-2. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub actions workflow file in
-   your repository, under `.github/workflows/main.yml` by default.
-
-3. In the editor window, copy and paste the following YAML configuration and commit the changes.
-
-   ```yaml
-   name: ci
-
-   on:
-     push:
-       branches:
-         - main
-
-   jobs:
-     build:
-       runs-on: ubuntu-latest
-       steps:
-         - name: Login to Docker Hub
-           uses: docker/login-action@v3
-           with:
-             username: ${{ vars.DOCKER_USERNAME }}
-             password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-         - name: Set up Docker Buildx
-           uses: docker/setup-buildx-action@v3
-
-         - name: Build and push
-           uses: docker/build-push-action@v6
-           with:
-             platforms: linux/amd64,linux/arm64
-             push: true
-             tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-   ```
-
-   For more information about the YAML syntax for `docker/build-push-action`,
-   refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
-## Step three: Run the workflow
-
-Save the workflow file and run the job.
-
-1. Select **Commit changes...** and push the changes to the `main` branch.
-
-   After pushing the commit, the workflow starts automatically.
-
-2. Go to the **Actions** tab. It displays the workflow.
-
-   Selecting the workflow shows you the breakdown of all the steps.
-
-3. When the workflow is complete, go to your
-   [repositories on Docker Hub](https://hub.docker.com/repositories).
-
-   If you see the new repository in that list, it means the GitHub Actions
-   successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your application.
-
-Related information:
-
-- [Introduction to GitHub Actions](/guides/gha.md)
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md)
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-Next, learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/golang/deploy.md b/content/guides/golang/deploy.md
deleted file mode 100644
index 0b47f0ebc9c8..000000000000
--- a/content/guides/golang/deploy.md
+++ /dev/null
@@ -1,249 +0,0 @@
----
-title: Test your Go deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, go, local, development
-description: Learn how to deploy your Go application
-aliases:
-  - /language/golang/deploy/
-  - /guides/language/golang/deploy/
----
-
-## Prerequisites
-
-- Complete all the previous sections of this guide, starting with [Build
-  your Go image](build-images.md).
-- [Turn on Kubernetes](/manuals/desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker
-  Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your
-application to a fully-featured Kubernetes environment on your development
-machine. This allows you to test and debug your workloads on Kubernetes locally
-before deploying.
-
-## Create a Kubernetes YAML file
-
-In your project directory, create a file named
-`docker-go-kubernetes.yaml`. Open the file in an IDE or text editor and add
-the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker
-username and the name of the repository that you created in [Configure CI/CD for
-your Go application](configure-ci-cd.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  labels:
-    service: server
-  name: server
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      service: server
-  strategy: {}
-  template:
-    metadata:
-      labels:
-        service: server
-    spec:
-      initContainers:
-        - name: wait-for-db
-          image: busybox:1.28
-          command:
-            [
-              "sh",
-              "-c",
-              'until nc -zv db 5432; do echo "waiting for db"; sleep 2; done;',
-            ]
-      containers:
-        - env:
-            - name: PGDATABASE
-              value: mydb
-            - name: PGPASSWORD
-              value: whatever
-            - name: PGHOST
-              value: db
-            - name: PGPORT
-              value: "5432"
-            - name: PGUSER
-              value: postgres
-          image: DOCKER_USERNAME/REPO_NAME
-          name: server
-          imagePullPolicy: Always
-          ports:
-            - containerPort: 8080
-              hostPort: 8080
-              protocol: TCP
-          resources: {}
-      restartPolicy: Always
-status: {}
----
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  labels:
-    service: db
-  name: db
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      service: db
-  strategy:
-    type: Recreate
-  template:
-    metadata:
-      labels:
-        service: db
-    spec:
-      containers:
-        - env:
-            - name: POSTGRES_DB
-              value: mydb
-            - name: POSTGRES_PASSWORD
-              value: whatever
-            - name: POSTGRES_USER
-              value: postgres
-          image: postgres
-          name: db
-          ports:
-            - containerPort: 5432
-              protocol: TCP
-          resources: {}
-      restartPolicy: Always
-status: {}
----
-apiVersion: v1
-kind: Service
-metadata:
-  labels:
-    service: server
-  name: server
-  namespace: default
-spec:
-  type: NodePort
-  ports:
-    - name: "8080"
-      port: 8080
-      targetPort: 8080
-      nodePort: 30001
-  selector:
-    service: server
-status:
-  loadBalancer: {}
----
-apiVersion: v1
-kind: Service
-metadata:
-  labels:
-    service: db
-  name: db
-  namespace: default
-spec:
-  ports:
-    - name: "5432"
-      port: 5432
-      targetPort: 5432
-  selector:
-    service: db
-status:
-  loadBalancer: {}
-```
-
-In this Kubernetes YAML file, there are four objects, separated by the `---`. In addition to a Service and Deployment for the database, the other two objects are:
-
-- A Deployment, describing a scalable group of identical pods. In this case,
-  you'll get just one replica, or copy of your pod. That pod, which is
-  described under `template`, has just one container in it. The container is
-  created from the image built by GitHub Actions in [Configure CI/CD for your
-  Go application](configure-ci-cd.md).
-- A NodePort service, which will route traffic from port 30001 on your host to
-  port 8080 inside the pods it routes to, allowing you to reach your app
-  from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to the project directory
-   and deploy your application to Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-go-kubernetes.yaml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```shell
-   deployment.apps/db created
-   service/db created
-   deployment.apps/server created
-   service/server created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```shell
-   NAME     READY   UP-TO-DATE   AVAILABLE   AGE
-   db       1/1     1            1           76s
-   server   1/1     1            1           76s
-   ```
-
-   This indicates all of the pods are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```shell
-   NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
-   db           ClusterIP   10.96.156.90    <none>        5432/TCP         2m8s
-   kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP          164m
-   server       NodePort    10.102.94.225   <none>        8080:30001/TCP   2m8s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `server` service and `db` service. The `server` service is accepting traffic on port 30001/TCP.
-
-3. Open a terminal and curl your application to verify that it's working.
-
-   ```console
-   $ curl --request POST \
-     --url http://localhost:30001/send \
-     --header 'content-type: application/json' \
-     --data '{"value": "Hello, Oliver!"}'
-   ```
-
-   You should get the following message back.
-
-   ```json
-   { "value": "Hello, Oliver!" }
-   ```
-
-4. Run the following command to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-go-kubernetes.yaml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine.
-
-Related information:
-
-- [Kubernetes documentation](https://kubernetes.io/docs/home/)
-- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-- [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/golang/develop.md b/content/guides/golang/develop.md
deleted file mode 100644
index c76a693f776f..000000000000
--- a/content/guides/golang/develop.md
+++ /dev/null
@@ -1,735 +0,0 @@
----
-title: Use containers for Go development
-linkTitle: Develop your app
-weight: 20
-keywords: get started, go, golang, local, development
-description: Learn how to develop your application locally.
-aliases:
-  - /get-started/golang/develop/
-  - /language/golang/develop/
-  - /guides/language/golang/develop/
----
-
-## Prerequisites
-
-Work through the steps of the [run your image as a container](run-containers.md) module to learn how to manage the lifecycle of your containers.
-
-## Introduction
-
-In this module, you'll take a look at running a database engine in a container and connecting it to the extended version of the example application. You are going to see some options for keeping persistent data and for wiring up the containers to talk to one another. Finally, you'll learn how to use Docker Compose to manage such multi-container local development environments effectively.
-
-## Local database and containers
-
-The database engine you are going to use is called [CockroachDB](https://www.cockroachlabs.com/product/). It is a modern, Cloud-native, distributed SQL database.
-
-Instead of compiling CockroachDB from the source code or using the operating system's native package manager to install CockroachDB, you are going to use the [Docker image for CockroachDB](https://hub.docker.com/r/cockroachdb/cockroach) and run it in a container.
-
-CockroachDB is compatible with PostgreSQL to a significant extent, and shares many conventions with the latter, particularly the default names for the environment variables. So, if you are familiar with Postgres, don't be surprised if you see some familiar environment variables names. The Go modules that work with Postgres, such as [pgx](https://pkg.go.dev/github.com/jackc/pgx), [pq](https://pkg.go.dev/github.com/lib/pq), [GORM](https://gorm.io/index.html), and [upper/db](https://upper.io/v4/) also work with CockroachDB.
-
-For more information on the relation between Go and CockroachDB, refer to the [CockroachDB documentation](https://www.cockroachlabs.com/docs/v20.2/build-a-go-app-with-cockroachdb.html), although this isn't necessary to continue with the present guide.
-
-### Storage
-
-The point of a database is to have a persistent store of data. [Volumes](/manuals/engine/storage/volumes.md) are the preferred mechanism for persisting data generated by and used by Docker containers. Thus, before you start CockroachDB, create the volume for it.
-
-To create a managed volume, run :
-
-```console
-$ docker volume create roach
-roach
-```
-
-You can view the list of all managed volumes in your Docker instance with the following command:
-
-```console
-$ docker volume list
-DRIVER    VOLUME NAME
-local     roach
-```
-
-### Networking
-
-The example application and the database engine are going to talk to one another over the network. There are different kinds of network configuration possible, and you're going to use what's called a user-defined bridge network. It is going to provide you with a DNS lookup service so that you can refer to your database engine container by its hostname.
-
-The following command creates a new bridge network named `mynet`:
-
-```console
-$ docker network create -d bridge mynet
-51344edd6430b5acd121822cacc99f8bc39be63dd125a3b3cd517b6485ab7709
-```
-
-As it was the case with the managed volumes, there is a command to list all networks set up in your Docker instance:
-
-```console
-$ docker network list
-NETWORK ID     NAME          DRIVER    SCOPE
-0ac2b1819fa4   bridge        bridge    local
-51344edd6430   mynet         bridge    local
-daed20bbecce   host          host      local
-6aee44f40a39   none          null      local
-```
-
-Your bridge network `mynet` has been created successfully. The other three networks, named `bridge`, `host`, and `none` are the default networks and they had been created by the Docker itself. While it's not relevant to this guide, you can learn more about Docker networking in the [networking overview](/manuals/engine/network/_index.md) section.
-
-### Choose good names for volumes and networks
-
-As the saying goes, there are only two hard things in Computer Science: cache invalidation and naming things. And off-by-one errors.
-
-When choosing a name for a network or a managed volume, it's best to choose a name that's indicative of the intended purpose. This guide aims for brevity, so it used short, generic names.
-
-### Start the database engine
-
-Now that the housekeeping chores are done, you can run CockroachDB in a container and attach it to the volume and network you had just created. When you run the following command, Docker will pull the image from Docker Hub and run it for you locally:
-
-```console
-$ docker run -d \
-  --name roach \
-  --hostname db \
-  --network mynet \
-  -p 26257:26257 \
-  -p 8080:8080 \
-  -v roach:/cockroach/cockroach-data \
-  cockroachdb/cockroach:latest-v20.1 start-single-node \
-  --insecure
-
-# ... output omitted ...
-```
-
-Notice a clever use of the tag `latest-v20.1` to make sure that you're pulling the latest patch version of 20.1. The diversity of available tags depend on the image maintainer. Here, your intent was to have the latest patched version of CockroachDB while not straying too far away from the known working version as the time goes by. To see the tags available for the CockroachDB image, you can go to the [CockroachDB page on Docker Hub](https://hub.docker.com/r/cockroachdb/cockroach/tags).
-
-### Configure the database engine
-
-Now that the database engine is live, there is some configuration to do before your application can begin using it. Fortunately, it's not a lot. You must:
-
-1. Create a blank database.
-2. Register a new user account with the database engine.
-3. Grant that new user access rights to the database.
-
-You can do that with the help of CockroachDB built-in SQL shell. To start the SQL shell in the same container where the database engine is running, type:
-
-```console
-$ docker exec -it roach ./cockroach sql --insecure
-```
-
-1. In the SQL shell, create the database that the example application is going to use:
-
-   ```sql
-   CREATE DATABASE mydb;
-   ```
-
-2. Register a new SQL user account with the database engine. Use the username `totoro`.
-
-   ```sql
-   CREATE USER totoro;
-   ```
-
-3. Give the new user the necessary permissions:
-
-   ```sql
-   GRANT ALL ON DATABASE mydb TO totoro;
-   ```
-
-4. Type `quit` to exit the shell.
-
-The following is an example of interaction with the SQL shell.
-
-```console
-$ sudo docker exec -it roach ./cockroach sql --insecure
-#
-# Welcome to the CockroachDB SQL shell.
-# All statements must be terminated by a semicolon.
-# To exit, type: \q.
-#
-# Server version: CockroachDB CCL v20.1.15 (x86_64-unknown-linux-gnu, built 2021/04/26 16:11:58, go1.13.9) (same version as client)
-# Cluster ID: 7f43a490-ccd6-4c2a-9534-21f393ca80ce
-#
-# Enter \? for a brief introduction.
-#
-root@:26257/defaultdb> CREATE DATABASE mydb;
-CREATE DATABASE
-
-Time: 22.985478ms
-
-root@:26257/defaultdb> CREATE USER totoro;
-CREATE ROLE
-
-Time: 13.921659ms
-
-root@:26257/defaultdb> GRANT ALL ON DATABASE mydb TO totoro;
-GRANT
-
-Time: 14.217559ms
-
-root@:26257/defaultdb> quit
-oliver@hki:~$
-```
-
-### Meet the example application
-
-Now that you have started and configured the database engine, you can switch your attention to the application.
-
-The example application for this module is an extended version of `docker-gs-ping` application you've used in the previous modules. You have two options:
-
-- You can update your local copy of `docker-gs-ping` to match the new extended version presented in this chapter; or
-- You can clone the [docker/docker-gs-ping-dev](https://github.com/docker/docker-gs-ping-dev) repository. This latter approach is recommended.
-
-To checkout the example application, run:
-
-```console
-$ git clone https://github.com/docker/docker-gs-ping-dev.git
-# ... output omitted ...
-```
-
-The application's `main.go` now includes database initialization code, as well as the code to implement a new business requirement:
-
-- An HTTP `POST` request to `/send` containing a `{ "value" : string }` JSON must save the value to the database.
-
-You also have an update for another business requirement. The requirement was:
-
-- The application responds with a text message containing a heart symbol ("`<3`") on requests to `/`.
-
-And now it's going to be:
-
-- The application responds with the string containing the count of messages stored in the database, enclosed in the parentheses.
-
-  Example output: `Hello, Docker! (7)`
-
-The full source code listing of `main.go` follows.
-
-```go
-package main
-
-import (
-	"context"
-	"database/sql"
-	"fmt"
-	"log"
-	"net/http"
-	"os"
-
-	"github.com/cenkalti/backoff/v4"
-	"github.com/cockroachdb/cockroach-go/v2/crdb"
-	"github.com/labstack/echo/v4"
-	"github.com/labstack/echo/v4/middleware"
-)
-
-func main() {
-
-	e := echo.New()
-
-	e.Use(middleware.Logger())
-	e.Use(middleware.Recover())
-
-	db, err := initStore()
-	if err != nil {
-		log.Fatalf("failed to initialize the store: %s", err)
-	}
-	defer db.Close()
-
-	e.GET("/", func(c echo.Context) error {
-		return rootHandler(db, c)
-	})
-
-	e.GET("/ping", func(c echo.Context) error {
-		return c.JSON(http.StatusOK, struct{ Status string }{Status: "OK"})
-	})
-
-	e.POST("/send", func(c echo.Context) error {
-		return sendHandler(db, c)
-	})
-
-	httpPort := os.Getenv("HTTP_PORT")
-	if httpPort == "" {
-		httpPort = "8080"
-	}
-
-	e.Logger.Fatal(e.Start(":" + httpPort))
-}
-
-type Message struct {
-	Value string `json:"value"`
-}
-
-func initStore() (*sql.DB, error) {
-
-	pgConnString := fmt.Sprintf("host=%s port=%s dbname=%s user=%s password=%s sslmode=disable",
-		os.Getenv("PGHOST"),
-		os.Getenv("PGPORT"),
-		os.Getenv("PGDATABASE"),
-		os.Getenv("PGUSER"),
-		os.Getenv("PGPASSWORD"),
-	)
-
-	var (
-		db  *sql.DB
-		err error
-	)
-	openDB := func() error {
-		db, err = sql.Open("postgres", pgConnString)
-		return err
-	}
-
-	err = backoff.Retry(openDB, backoff.NewExponentialBackOff())
-	if err != nil {
-		return nil, err
-	}
-
-	if _, err := db.Exec(
-		"CREATE TABLE IF NOT EXISTS message (value TEXT PRIMARY KEY)"); err != nil {
-		return nil, err
-	}
-
-	return db, nil
-}
-
-func rootHandler(db *sql.DB, c echo.Context) error {
-	r, err := countRecords(db)
-	if err != nil {
-		return c.HTML(http.StatusInternalServerError, err.Error())
-	}
-	return c.HTML(http.StatusOK, fmt.Sprintf("Hello, Docker! (%d)\n", r))
-}
-
-func sendHandler(db *sql.DB, c echo.Context) error {
-
-	m := &Message{}
-
-	if err := c.Bind(m); err != nil {
-		return c.JSON(http.StatusInternalServerError, err)
-	}
-
-	err := crdb.ExecuteTx(context.Background(), db, nil,
-		func(tx *sql.Tx) error {
-			_, err := tx.Exec(
-				"INSERT INTO message (value) VALUES ($1) ON CONFLICT (value) DO UPDATE SET value = excluded.value",
-				m.Value,
-			)
-			if err != nil {
-				return c.JSON(http.StatusInternalServerError, err)
-			}
-			return nil
-		})
-
-	if err != nil {
-		return c.JSON(http.StatusInternalServerError, err)
-	}
-
-	return c.JSON(http.StatusOK, m)
-}
-
-func countRecords(db *sql.DB) (int, error) {
-
-	rows, err := db.Query("SELECT COUNT(*) FROM message")
-	if err != nil {
-		return 0, err
-	}
-	defer rows.Close()
-
-	count := 0
-	for rows.Next() {
-		if err := rows.Scan(&count); err != nil {
-			return 0, err
-		}
-		rows.Close()
-	}
-
-	return count, nil
-}
-```
-
-The repository also includes the `Dockerfile`, which is almost exactly the same as the multi-stage `Dockerfile` introduced in the previous modules. It uses the official Docker Go image to build the application and then builds the final image by placing the compiled binary into the much slimmer, distroless image.
-
-Regardless of whether you had updated the old example application, or checked out the new one, this new Docker image has to be built to reflect the changes to the application source code.
-
-### Build the application
-
-You can build the image with the familiar `build` command:
-
-```console
-$ docker build --tag docker-gs-ping-roach .
-```
-
-### Run the application
-
-Now, run your container. This time you'll need to set some environment variables so that your application knows how to access the database. For now, you’ll do this right in the `docker run` command. Later you'll see a more convenient method with Docker Compose.
-
-> [!NOTE]
->
-> Since you're running your CockroachDB cluster in insecure mode, the value for the password can be anything.
->
-> In production, don't run in insecure mode.
-
-```console
-$ docker run -it --rm -d \
-  --network mynet \
-  --name rest-server \
-  -p 80:8080 \
-  -e PGUSER=totoro \
-  -e PGPASSWORD=myfriend \
-  -e PGHOST=db \
-  -e PGPORT=26257 \
-  -e PGDATABASE=mydb \
-  docker-gs-ping-roach
-```
-
-There are a few points to note about this command.
-
-- You map container port `8080` to host port `80` this time. Thus, for `GET` requests you can get away with literally `curl localhost`:
-
-  ```console
-  $ curl localhost
-  Hello, Docker! (0)
-  ```
-
-  Or, if you prefer, a proper URL would work just as well:
-
-  ```console
-  $ curl http://localhost/
-  Hello, Docker! (0)
-  ```
-
-- The total number of stored messages is `0` for now. This is fine, because you haven't posted anything to your application yet.
-- You refer to the database container by its hostname, which is `db`. This is why you had `--hostname db` when you started the database container.
-
-- The actual password doesn't matter, but it must be set to something to avoid confusing the example application.
-- The container you've just run is named `rest-server`. These names are useful for managing the container lifecycle:
-
-  ```console
-  # Don't do this just yet, it's only an example:
-  $ docker container rm --force rest-server
-  ```
-
-### Test the application
-
-In the previous section, you've already tested querying your application with `GET` and it returned zero for the stored message counter. Now, post some messages to it:
-
-```console
-$ curl --request POST \
-  --url http://localhost/send \
-  --header 'content-type: application/json' \
-  --data '{"value": "Hello, Docker!"}'
-```
-
-The application responds with the contents of the message, which means it has been saved in the database:
-
-```json
-{ "value": "Hello, Docker!" }
-```
-
-Send another message:
-
-```console
-$ curl --request POST \
-  --url http://localhost/send \
-  --header 'content-type: application/json' \
-  --data '{"value": "Hello, Oliver!"}'
-```
-
-And again, you get the value of the message back:
-
-```json
-{ "value": "Hello, Oliver!" }
-```
-
-Run curl and see what the message counter says:
-
-```console
-$ curl localhost
-Hello, Docker! (2)
-```
-
-In this example, you sent two messages and the database kept them. Or has it? Stop and remove all your containers, but not the volumes, and try again.
-
-First, stop the containers:
-
-```console
-$ docker container stop rest-server roach
-rest-server
-roach
-```
-
-Then, remove them:
-
-```console
-$ docker container rm rest-server roach
-rest-server
-roach
-```
-
-Verify that they're gone:
-
-```console
-$ docker container list --all
-CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
-```
-
-And start them again, database first:
-
-```console
-$ docker run -d \
-  --name roach \
-  --hostname db \
-  --network mynet \
-  -p 26257:26257 \
-  -p 8080:8080 \
-  -v roach:/cockroach/cockroach-data \
-  cockroachdb/cockroach:latest-v20.1 start-single-node \
-  --insecure
-```
-
-And the service next:
-
-```console
-$ docker run -it --rm -d \
-  --network mynet \
-  --name rest-server \
-  -p 80:8080 \
-  -e PGUSER=totoro \
-  -e PGPASSWORD=myfriend \
-  -e PGHOST=db \
-  -e PGPORT=26257 \
-  -e PGDATABASE=mydb \
-  docker-gs-ping-roach
-```
-
-Lastly, query your service:
-
-```console
-$ curl localhost
-Hello, Docker! (2)
-```
-
-Great! The count of records from the database is correct although you haven't only stopped the containers, but you've also removed them before starting new instances. The difference is in the managed volume for CockroachDB, which you reused. The new CockroachDB container has read the database files from the disk, just as it normally would if it were running outside the container.
-
-### Wind down everything
-
-Remember, that you're running CockroachDB in insecure mode. Now that you've built and tested your application, it's time to wind everything down before moving on. You can list the containers that you are running with the `list` command:
-
-```console
-$ docker container list
-```
-
-Now that you know the container IDs, you can use `docker container stop` and `docker container rm`, as demonstrated in the previous modules.
-
-Stop the CockroachDB and `docker-gs-ping-roach` containers before moving on.
-
-## Better productivity with Docker Compose
-
-At this point, you might be wondering if there is a way to avoid having to deal with long lists of arguments to the `docker` command. The toy example you used in this series requires five environment variables to define the connection to the database. A real application might need many, many more. Then there is also a question of dependencies. Ideally, you want to make sure that the database is started before your application is run. And spinning up the database instance may require another Docker command with many options. But there is a better way to orchestrate these deployments for local development purposes.
-
-In this section, you'll create a Docker Compose file to start your `docker-gs-ping-roach` application and CockroachDB database engine with a single command.
-
-### Configure Docker Compose
-
-In your application's directory, create a new text file named `compose.yaml` with the following content.
-
-```yaml
-version: "3.8"
-
-services:
-  docker-gs-ping-roach:
-    depends_on:
-      - roach
-    build:
-      context: .
-    container_name: rest-server
-    hostname: rest-server
-    networks:
-      - mynet
-    ports:
-      - 80:8080
-    environment:
-      - PGUSER=${PGUSER:-totoro}
-      - PGPASSWORD=${PGPASSWORD:?database password not set}
-      - PGHOST=${PGHOST:-db}
-      - PGPORT=${PGPORT:-26257}
-      - PGDATABASE=${PGDATABASE:-mydb}
-    deploy:
-      restart_policy:
-        condition: on-failure
-  roach:
-    image: cockroachdb/cockroach:latest-v20.1
-    container_name: roach
-    hostname: db
-    networks:
-      - mynet
-    ports:
-      - 26257:26257
-      - 8080:8080
-    volumes:
-      - roach:/cockroach/cockroach-data
-    command: start-single-node --insecure
-
-volumes:
-  roach:
-
-networks:
-  mynet:
-    driver: bridge
-```
-
-This Docker Compose configuration is super convenient as you don't have to type all the parameters to pass to the `docker run` command. You can declaratively do that in the Docker Compose file. The [Docker Compose documentation pages](/manuals/compose/_index.md) are quite extensive and include a full reference for the Docker Compose file format.
-
-### The `.env` file
-
-Docker Compose will automatically read environment variables from a `.env` file if it's available. Since your Compose file requires `PGPASSWORD` to be set, add the following content to the `.env` file:
-
-```bash
-PGPASSWORD=whatever
-```
-
-The exact value doesn't really matter for this example, because you run CockroachDB in insecure mode. Make sure you set the variable to some value to avoid getting an error.
-
-### Merging Compose files
-
-The file name `compose.yaml` is the default file name which `docker compose` command recognizes if no `-f` flag is provided. This means you can have multiple Docker Compose files if your environment has such requirements. Furthermore, Docker Compose files are... composable (pun intended), so multiple files can be specified on the command line to merge parts of the configuration together. The following list is just a few examples of scenarios where such a feature would be very useful:
-
-- Using a bind mount for the source code for local development but not when running the CI tests;
-- Switching between using a pre-built image for the frontend for some API application vs creating a bind mount for source code;
-- Adding additional services for integration testing;
-- And many more...
-
-You aren't going to cover any of these advanced use cases here.
-
-### Variable substitution in Docker Compose
-
-One of the really cool features of Docker Compose is [variable substitution](/reference/compose-file/interpolation.md). You can see some examples in the Compose file, `environment` section. By means of an example:
-
-- `PGUSER=${PGUSER:-totoro}` means that inside the container, the environment variable `PGUSER` shall be set to the same value as it has on the host machine where Docker Compose is run. If there is no environment variable with this name on the host machine, the variable inside the container gets the default value of `totoro`.
-- `PGPASSWORD=${PGPASSWORD:?database password not set}` means that if the environment variable `PGPASSWORD` isn't set on the host, Docker Compose will display an error. This is OK, because you don't want to hard-code default values for the password. You set the password value in the `.env` file, which is local to your machine. It is always a good idea to add `.env` to `.gitignore` to prevent the secrets being checked into the version control.
-
-Other ways of dealing with undefined or empty values exist, as documented in the [variable substitution](/reference/compose-file/interpolation.md) section of the Docker documentation.
-
-### Validating Docker Compose configuration
-
-Before you apply changes made to a Compose configuration file, there is an opportunity to validate the content of the configuration file with the following command:
-
-```console
-$ docker compose config
-```
-
-When this command is run, Docker Compose reads the file `compose.yaml`, parses it into a data structure in memory, validates where possible, and prints back the reconstruction of that configuration file from its internal representation. If this isn't possible due to errors, Docker prints an error message instead.
-
-### Build and run the application using Docker Compose
-
-Start your application and confirm that it's running.
-
-```console
-$ docker compose up --build
-```
-
-You passed the `--build` flag so Docker will compile your image and then start it.
-
-> [!NOTE]
->
-> Docker Compose is a useful tool, but it has its own quirks. For example, no rebuild is triggered on the update to the source code unless the `--build` flag is provided. It is a very common pitfall to edit one's source code, and forget to use the `--build` flag when running `docker compose up`.
-
-Since your set-up is now run by Docker Compose, it has assigned it a project name, so you get a new volume for your CockroachDB instance. This means that your application will fail to connect to the database, because the database doesn't exist in this new volume. The terminal displays an authentication error for the database:
-
-```text
-# ... omitted output ...
-rest-server             | 2021/05/10 00:54:25 failed to initialise the store: pq: password authentication failed for user totoro
-roach                   | *
-roach                   | * INFO: Replication was disabled for this cluster.
-roach                   | * When/if adding nodes in the future, update zone configurations to increase the replication factor.
-roach                   | *
-roach                   | CockroachDB node starting at 2021-05-10 00:54:26.398177 +0000 UTC (took 3.0s)
-roach                   | build:               CCL v20.1.15 @ 2021/04/26 16:11:58 (go1.13.9)
-roach                   | webui:               http://db:8080
-roach                   | sql:                 postgresql://root@db:26257?sslmode=disable
-roach                   | RPC client flags:    /cockroach/cockroach <client cmd> --host=db:26257 --insecure
-roach                   | logs:                /cockroach/cockroach-data/logs
-roach                   | temp dir:            /cockroach/cockroach-data/cockroach-temp349434348
-roach                   | external I/O path:   /cockroach/cockroach-data/extern
-roach                   | store[0]:            path=/cockroach/cockroach-data
-roach                   | storage engine:      rocksdb
-roach                   | status:              initialized new cluster
-roach                   | clusterID:           b7b1cb93-558f-4058-b77e-8a4ddb329a88
-roach                   | nodeID:              1
-rest-server exited with code 0
-rest-server             | 2021/05/10 00:54:25 failed to initialise the store: pq: password authentication failed for user totoro
-rest-server             | 2021/05/10 00:54:26 failed to initialise the store: pq: password authentication failed for user totoro
-rest-server             | 2021/05/10 00:54:29 failed to initialise the store: pq: password authentication failed for user totoro
-rest-server             | 2021/05/10 00:54:25 failed to initialise the store: pq: password authentication failed for user totoro
-rest-server             | 2021/05/10 00:54:26 failed to initialise the store: pq: password authentication failed for user totoro
-rest-server             | 2021/05/10 00:54:29 failed to initialise the store: pq: password authentication failed for user totoro
-rest-server exited with code 1
-# ... omitted output ...
-```
-
-Because of the way you set up your deployment using `restart_policy`, the failing container is being restarted every 20 seconds. So, in order to fix the problem, you need to log in to the database engine and create the user. You've done it before in [Configure the database engine](#configure-the-database-engine).
-
-This isn't a big deal. All you have to do is to connect to CockroachDB instance and run the three SQL commands to create the database and the user, as described in [Configure the database engine](#configure-the-database-engine).
-
-So, log in to the database engine from another terminal:
-
-```console
-$ docker exec -it roach ./cockroach sql --insecure
-```
-
-And run the same commands as before to create the database `mydb`, the user `totoro`, and to grant that user necessary permissions. Once you do that (and the example application container is automatically restarts), the `rest-service` stops failing and restarting and the console goes quiet.
-
-It would have been possible to connect the volume that you had previously used, but for the purposes of this example it's more trouble than it's worth and it also provided an opportunity to show how to introduce resilience into your deployment via the `restart_policy` Compose file feature.
-
-### Testing the application
-
-Now, test your API endpoint. In the new terminal, run the following command:
-
-```console
-$ curl http://localhost/
-```
-
-You should receive the following response:
-
-```json
-Hello, Docker! (0)
-```
-
-### Shutting down
-
-To stop the containers started by Docker Compose, press `ctrl+c` in the terminal where you ran `docker compose up`. To remove those containers after they've been stopped, run `docker compose down`.
-
-### Detached mode
-
-You can run containers started by the `docker compose` command in detached mode, just as you would with the `docker` command, by using the `-d` flag.
-
-To start the stack, defined by the Compose file in detached mode, run:
-
-```console
-$ docker compose up --build -d
-```
-
-Then, you can use `docker compose stop` to stop the containers and `docker compose down` to remove them.
-
-## Further exploration
-
-You can run `docker compose` to see what other commands are available.
-
-## Wrap up
-
-There are some tangential, yet interesting points that were purposefully not covered in this chapter. For the more adventurous reader, this section offers some pointers for further study.
-
-### Persistent storage
-
-A managed volume isn't the only way to provide your container with persistent storage. It is highly recommended to get acquainted with available storage options and their use cases, covered in [Manage data in Docker](/manuals/engine/storage/_index.md).
-
-### CockroachDB clusters
-
-You ran a single instance of CockroachDB, which was enough for this example. But, it's possible to run a CockroachDB cluster, which is made of multiple instances of CockroachDB, each instance running in its own container. Since CockroachDB engine is distributed by design, it would have taken surprisingly little change to your procedure to run a cluster with multiple nodes.
-
-Such distributed set-up offers interesting possibilities, such as applying Chaos Engineering techniques to simulate parts of the cluster failing and evaluating your application's ability to cope with such failures.
-
-If you are interested in experimenting with CockroachDB clusters, check out:
-
-- [Start a CockroachDB Cluster in Docker](https://www.cockroachlabs.com/docs/v20.2/start-a-local-cluster-in-docker-mac.html) article; and
-- Documentation for Docker Compose keywords [`deploy`](/reference/compose-file/legacy-versions.md) and [`replicas`](/reference/compose-file/legacy-versions.md).
-
-### Other databases
-
-Since you didn't run a cluster of CockroachDB instances, you might be wondering whether you could have used a non-distributed database engine. The answer is 'yes', and if you were to pick a more traditional SQL database, such as [PostgreSQL](https://www.postgresql.org/), the process described in this chapter would have been very similar.
-
-## Next steps
-
-In this module, you set up a containerized development environment with your application and the database engine running in different containers. You also wrote a Docker Compose file which links the two containers together and provides for easy starting up and tearing down of the development environment.
-
-In the next module, you'll take a look at one possible approach to running functional tests in Docker.
diff --git a/content/guides/golang/run-containers.md b/content/guides/golang/run-containers.md
deleted file mode 100644
index 34e87c648915..000000000000
--- a/content/guides/golang/run-containers.md
+++ /dev/null
@@ -1,210 +0,0 @@
----
-title: Run your Go image as a container
-linkTitle: Run containers
-weight: 10
-keywords: get started, go, golang, run, container
-description: Learn how to run the image as a container.
-aliases:
-  - /get-started/golang/run-containers/
-  - /language/golang/run-containers/
-  - /guides/language/golang/run-containers/
----
-
-## Prerequisites
-
-Work through the steps to containerize a Go application in [Build your Go image](build-images.md).
-
-## Overview
-
-In the previous module you created a `Dockerfile` for your example application and then you created your Docker image using the command `docker build`. Now that you have the image, you can run that image and see if your application is running correctly.
-
-A container is a normal operating system process except that this process is isolated and has its own file system, its own networking, and its own isolated process tree separate from the host.
-
-To run an image inside of a container, you use the `docker run` command. It requires one parameter and that's the image name. Start your image and make sure it's running correctly. Run the following command in your terminal.
-
-```console
-$ docker run docker-gs-ping
-```
-
-```text
-   ____    __
-  / __/___/ /  ___
- / _// __/ _ \/ _ \
-/___/\__/_//_/\___/ v4.10.2
-High performance, minimalist Go web framework
-https://echo.labstack.com
-____________________________________O/_______
-                                    O\
-⇨ http server started on [::]:8080
-```
-
-When you run this command, you’ll notice that you weren't returned to the command prompt. This is because your application is a REST server and will run in a loop waiting for incoming requests without returning control back to the OS until you stop the container.
-
-Make a GET request to the server using the curl command.
-
-```console
-$ curl http://localhost:8080/
-curl: (7) Failed to connect to localhost port 8080: Connection refused
-```
-
-Your curl command failed because the connection to your server was refused.
-Meaning that you weren't able to connect to localhost on port 8080. This is
-expected because your container is running in isolation which includes
-networking. Stop the container and restart with port 8080 published on your
-local network.
-
-To stop the container, press ctrl-c. This will return you to the terminal prompt.
-
-To publish a port for your container, you’ll use the `--publish` flag (`-p` for short) on the `docker run` command. The format of the `--publish` command is `[host_port]:[container_port]`. So if you wanted to expose port `8080` inside the container to port `3000` outside the container, you would pass `3000:8080` to the `--publish` flag.
-
-Start the container and expose port `8080` to port `8080` on the host.
-
-```console
-$ docker run --publish 8080:8080 docker-gs-ping
-```
-
-Now, rerun the curl command.
-
-```console
-$ curl http://localhost:8080/
-Hello, Docker! <3
-```
-
-Success! You were able to connect to the application running inside of your container on port 8080. Switch back to the terminal where your container is running and you should see the `GET` request logged to the console.
-
-Press `ctrl-c` to stop the container.
-
-## Run in detached mode
-
-This is great so far, but your sample application is a web server and you
-shouldn't have to have your terminal connected to the container. Docker can run
-your container in detached mode in the background. To do this, you can use the
-`--detach` or `-d` for short. Docker will start your container the same as
-before but this time will detach from the container and return you to the
-terminal prompt.
-
-```console
-$ docker run -d -p 8080:8080 docker-gs-ping
-d75e61fcad1e0c0eca69a3f767be6ba28a66625ce4dc42201a8a323e8313c14e
-```
-
-Docker started your container in the background and printed the container ID on the terminal.
-
-Again, make sure that your container is running. Run the same `curl` command:
-
-```console
-$ curl http://localhost:8080/
-Hello, Docker! <3
-```
-
-## List containers
-
-Since you ran your container in the background, how do you know if your container is running or what other containers are running on your machine? Well, to see a list of containers running on your machine, run `docker ps`. This is similar to how the ps command is used to see a list of processes on a Linux machine.
-
-```console
-$ docker ps
-
-CONTAINER ID   IMAGE            COMMAND             CREATED          STATUS          PORTS                    NAMES
-d75e61fcad1e   docker-gs-ping   "/docker-gs-ping"   41 seconds ago   Up 40 seconds   0.0.0.0:8080->8080/tcp   inspiring_ishizaka
-```
-
-The `ps` command tells you a bunch of stuff about your running containers. You can see the container ID, the image running inside the container, the command that was used to start the container, when it was created, the status, ports that are exposed, and the names of the container.
-
-You are probably wondering where the name of your container is coming from. Since you didn’t provide a name for the container when you started it, Docker generated a random name. You'll fix this in a minute but first you need to stop the container. To stop the container, run the `docker stop` command, passing the container's name or ID.
-
-```console
-$ docker stop inspiring_ishizaka
-inspiring_ishizaka
-```
-
-Now rerun the `docker ps` command to see a list of running containers.
-
-```console
-$ docker ps
-
-CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
-```
-
-## Stop, start, and name containers
-
-Docker containers can be started, stopped and restarted. When you stop a container, it's not removed but the status is changed to stopped and the process inside of the container is stopped. When you ran the `docker ps` command, the default output is to only show running containers. If you pass the `--all` or `-a` for short, you will see all containers on your system, including stopped containers and running containers.
-
-```console
-$ docker ps --all
-
-CONTAINER ID   IMAGE            COMMAND                  CREATED              STATUS                      PORTS     NAMES
-d75e61fcad1e   docker-gs-ping   "/docker-gs-ping"        About a minute ago   Exited (2) 23 seconds ago             inspiring_ishizaka
-f65dbbb9a548   docker-gs-ping   "/docker-gs-ping"        3 minutes ago        Exited (2) 2 minutes ago              wizardly_joliot
-aade1bf3d330   docker-gs-ping   "/docker-gs-ping"        3 minutes ago        Exited (2) 3 minutes ago              magical_carson
-52d5ce3c15f0   docker-gs-ping   "/docker-gs-ping"        9 minutes ago        Exited (2) 3 minutes ago              gifted_mestorf
-```
-
-If you’ve been following along, you should see several containers listed. These are containers that you started and stopped but haven't removed yet.
-
-Restart the container that you have just stopped. Locate the name of the container and replace the name of the container in the following `restart` command:
-
-```console
-$ docker restart inspiring_ishizaka
-```
-
-Now, list all the containers again using the `ps` command:
-
-```console
-$ docker ps -a
-
-CONTAINER ID   IMAGE            COMMAND                  CREATED          STATUS                     PORTS                    NAMES
-d75e61fcad1e   docker-gs-ping   "/docker-gs-ping"        2 minutes ago    Up 5 seconds               0.0.0.0:8080->8080/tcp   inspiring_ishizaka
-f65dbbb9a548   docker-gs-ping   "/docker-gs-ping"        4 minutes ago    Exited (2) 2 minutes ago                            wizardly_joliot
-aade1bf3d330   docker-gs-ping   "/docker-gs-ping"        4 minutes ago    Exited (2) 4 minutes ago                            magical_carson
-52d5ce3c15f0   docker-gs-ping   "/docker-gs-ping"        10 minutes ago   Exited (2) 4 minutes ago                            gifted_mestorf
-```
-
-Notice that the container you just restarted has been started in detached mode and has port `8080` exposed. Also, note that the status of the container is `Up X seconds`. When you restart a container, it will be started with the same flags or commands that it was originally started with.
-
-Stop and remove all of your containers and take a look at fixing the random naming issue.
-
-Stop the container you just started. Find the name of your running container and replace the name in the following command with the name of the container on your system:
-
-```console
-$ docker stop inspiring_ishizaka
-inspiring_ishizaka
-```
-
-Now that all of your containers are stopped, remove them. When a container is removed, it's no longer running nor is it in the stopped state. Instead, the process inside the container is terminated and the metadata for the container is removed.
-
-To remove a container, run the `docker rm` command passing the container name. You can pass multiple container names to the command in one command.
-
-Again, make sure you replace the containers names in the following command with the container names from your system:
-
-```console
-$ docker rm inspiring_ishizaka wizardly_joliot magical_carson gifted_mestorf
-
-inspiring_ishizaka
-wizardly_joliot
-magical_carson
-gifted_mestorf
-```
-
-Run the `docker ps --all` command again to verify that all containers are gone.
-
-Now, address the pesky random name issue. Standard practice is to name your containers for the simple reason that it's easier to identify what's running in the container and what application or service it's associated with. Just like good naming conventions for variables in your code makes it simpler to read. So goes naming your containers.
-
-To name a container, you must pass the `--name` flag to the `run` command:
-
-```console
-$ docker run -d -p 8080:8080 --name rest-server docker-gs-ping
-3bbc6a3102ea368c8b966e1878a5ea9b1fc61187afaac1276c41db22e4b7f48f
-```
-
-```console
-$ docker ps
-
-CONTAINER ID   IMAGE            COMMAND             CREATED          STATUS          PORTS                    NAMES
-3bbc6a3102ea   docker-gs-ping   "/docker-gs-ping"   25 seconds ago   Up 24 seconds   0.0.0.0:8080->8080/tcp   rest-server
-```
-
-Now, you can easily identify your container based on the name.
-
-## Next steps
-
-In this module, you learned how to run containers and publish ports. You also learned to manage the lifecycle of containers. You then learned the importance of naming your containers so that they're more easily identifiable. In the next module, you’ll learn how to run a database in a container and connect it to your application.
diff --git a/content/guides/golang/run-tests.md b/content/guides/golang/run-tests.md
deleted file mode 100644
index b4b435fd62e2..000000000000
--- a/content/guides/golang/run-tests.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: Run your tests using Go test
-linkTitle: Run your tests
-weight: 30
-keywords: build, go, golang, test
-description: How to build and run your Go tests in a container
-aliases:
-  - /get-started/golang/run-tests/
-  - /language/golang/run-tests/
-  - /guides/language/golang/run-tests/
----
-
-## Prerequisites
-
-Complete the [Build your Go image](build-images.md) section of this guide.
-
-## Overview
-
-Testing is an essential part of modern software development. Testing can mean a
-lot of things to different development teams. There are unit tests, integration
-tests and end-to-end testing. In this guide you take a look at running your unit
-tests in Docker when building.
-
-For this section, use the `docker-gs-ping` project that you cloned in [Build
-your Go image](build-images.md).
-
-## Run tests when building
-
-To run your tests when building, you need to add a test stage to the
-`Dockerfile.multistage`. The `Dockerfile.multistage` in the sample application's
-repository already has the following content:
-
-```dockerfile {hl_lines="15-17"}
-# syntax=docker/dockerfile:1
-
-# Build the application from source
-FROM golang:1.19 AS build-stage
-
-WORKDIR /app
-
-COPY go.mod go.sum ./
-RUN go mod download
-
-COPY *.go ./
-
-RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping
-
-# Run the tests in the container
-FROM build-stage AS run-test-stage
-RUN go test -v ./...
-
-# Deploy the application binary into a lean image
-FROM gcr.io/distroless/base-debian11 AS build-release-stage
-
-WORKDIR /
-
-COPY --from=build-stage /docker-gs-ping /docker-gs-ping
-
-EXPOSE 8080
-
-USER nonroot:nonroot
-
-ENTRYPOINT ["/docker-gs-ping"]
-```
-
-Run the following command to build an image using the `run-test-stage` stage as the target and view the test results. Include `--progress plain` to view the build output, `--no-cache` to ensure the tests always run, and `--target run-test-stage` to target the test stage.
-
-```console
-$ docker build -f Dockerfile.multistage -t docker-gs-ping-test --progress plain --no-cache --target run-test-stage .
-```
-
-You should see output containing the following.
-
-```text
-#13 [run-test-stage 1/1] RUN go test -v ./...
-#13 4.915 === RUN   TestIntMinBasic
-#13 4.915 --- PASS: TestIntMinBasic (0.00s)
-#13 4.915 === RUN   TestIntMinTableDriven
-#13 4.915 === RUN   TestIntMinTableDriven/0,1
-#13 4.915 === RUN   TestIntMinTableDriven/1,0
-#13 4.915 === RUN   TestIntMinTableDriven/2,-2
-#13 4.915 === RUN   TestIntMinTableDriven/0,-1
-#13 4.915 === RUN   TestIntMinTableDriven/-1,0
-#13 4.915 --- PASS: TestIntMinTableDriven (0.00s)
-#13 4.915     --- PASS: TestIntMinTableDriven/0,1 (0.00s)
-#13 4.915     --- PASS: TestIntMinTableDriven/1,0 (0.00s)
-#13 4.915     --- PASS: TestIntMinTableDriven/2,-2 (0.00s)
-#13 4.915     --- PASS: TestIntMinTableDriven/0,-1 (0.00s)
-#13 4.915     --- PASS: TestIntMinTableDriven/-1,0 (0.00s)
-#13 4.915 PASS
-```
-
-## Next steps
-
-In this section, you learned how to run tests when building your image. Next,
-you’ll learn how to set up a CI/CD pipeline using GitHub Actions.
diff --git a/content/guides/grafana-mcp-server-gemini.md b/content/guides/grafana-mcp-server-gemini.md
new file mode 100644
index 000000000000..c11c32e3c55c
--- /dev/null
+++ b/content/guides/grafana-mcp-server-gemini.md
@@ -0,0 +1,120 @@
+---
+description: Integrate Gemini CLI with Grafana via Docker MCP Toolkit for natural language observability.
+keywords: mcp, grafana, docker, gemini, devops
+title: Connect Gemini to Grafana via MCP
+summary: |
+  Learn how to leverage the Model Context Protocol (MCP) to interact with Grafana dashboards and datasources directly from your terminal.
+params:
+  tags: [ai]
+  proficiencyLevel: Intermediate
+  time: 15 minutes
+---
+
+This guide shows how to connect Gemini CLI to a Grafana instance using the **Docker MCP Toolkit**.
+
+## Prerequisites
+
+- **Gemini CLI** installed and authenticated.
+- **Docker Desktop** with the **MCP Toolkit** extension enabled.
+- An active **Grafana** instance.
+
+## Step 1: Provision Grafana access
+
+The MCP server requires a **Service Account Token** to interact with the Grafana API. Service Account Tokens are preferred over personal API keys because they can be revoked independently without affecting user access, and permissions can be scoped more narrowly.
+
+1. Navigate to **Administration > Users and access > Service accounts** in your Grafana dashboard.
+2. Create a new Service Account (e.g., `gemini-mcp-connector`).
+3. Assign the **Viewer** role (or **Editor** if you require alert management capabilities).
+4. Generate a new token. Copy the token immediately — you won't be able to view it again.
+
+
+## Step 2: Configure the MCP server
+
+The Docker MCP Toolkit provides a pre-configured Grafana catalog item. This connects the LLM to the Grafana API.
+
+1. Open the **MCP Toolkit** in Docker Desktop.
+2. Locate **Grafana** in the Catalog and add it to your active servers.
+3. In the **Configuration** view, define the following:
+
+- **Grafana URL:** The endpoint or URL of your instance.
+- **Service Account Token:** The token generated in the previous step.
+
+## Step 3: Integrate Gemini CLI
+
+To register the Docker MCP gateway within Gemini, update your global configuration file located at `~/.gemini/settings.json`.
+
+Ensure the `mcpServers` object includes the following entry:
+
+```json
+{
+  "mcpServers": {
+    "MCP_DOCKER": {
+      "command": "docker",
+      "args": ["mcp", "gateway", "run"]
+    }
+  }
+}
+```
+
+## Step 4: Validate the setup
+
+Restart your Gemini CLI session to load the new configuration. Verify the status of the MCP tools by running:
+
+```bash
+> /mcp list
+
+```
+
+A successful connection will show `MCP_DOCKER` as **Ready**, exposing dozens tools for data fetching, dashboard searching, and alert inspection.
+
+## Use Cases
+
+### Data source Discovery
+
+_List all Prometheus and Loki data sources._
+
+![List data sources; permission prompt](images/gemini-grafana-list-datasources.webp)
+
+![List data sources; result](images/list-datasources-result.webp)
+
+### Logs Inspection
+
+Gemini performs intent parsing and translates the user's request into a precise LogQL query: `{device_name="edge-device-01"} |= "nginx"`. Once the system identifies Loki as the active datasource, the AI autonomously constructs this command to bridge the gap between human intent and complex syntax. This query targets specific Kubernetes pod logs, extracting raw OpenTelemetry (OTel) data—including pod UIDs, container metadata, and system labels—which Gemini then uses to identify the root cause of the issue within the containerized environment.
+
+![Filter logs based on loki labels](images/mcp-docker-grafana-loki-1.webp)
+
+
+![Gemini gets the Grafana's logs from MCP docker](images/mcp-docker-grafana-loki-2.webp)
+
+In the final step, Gemini performs reasoning over the raw telemetry. After filtering through hundreds of lines to confirm the existence of Nginx logs, Gemini extracts a specific node_filesystem_device_error buried within the stream. By surfacing this critical event, it alerts the DevOps engineer to a volume mounting issue on the edge node, transforming raw data into an actionable incident report.
+
+![Gemini gives an overall about the findings](images/mcp-docker-grafana-loki-3.webp)
+
+### Dashboard Navigation
+
+_How many dashboards do we have?_
+
+![How many dashboards do we have?](images/mcp-grafana-dashboards.webp)
+
+_Tell me the summary of X dashboard_
+
+![Summary of X dashboard](images/mcp-grafana-summary-dashboard.webp)
+
+### Other scenarios
+
+Imagine you get a page that an application is slow. You could:
+
+1.  Use `list_alert_rules` to see which alert is firing.
+2.  Use `search_dashboards` to find the relevant application dashboard.
+3.  Use `get_panel_image` on a key panel to see the performance spike visually.
+4.  Use `query_loki_logs` to search for "error" or "timeout" messages during the time of the spike.
+5.  If you find the root cause, use create_incident to start the formal response and `add_activity_to_incident` to log your findings.
+
+## Next steps
+
+- Learn about [Advanced LogQL queries](https://grafana.com/docs/loki/latest/query/log_queries/)
+- Set up [Team-wide MCP configurations](https://modelcontextprotocol.io/docs/develop/connect-local-servers)
+- Explore [Grafana alerting with MCP](https://github.com/grafana/mcp-grafana)
+- Get help in the [Docker Community Forums](https://forums.docker.com)
+
+Need help setting up your Docker MCP environment or customizing your Gemini prompts? Visit the [Docker Community Forums](https://forums.docker.com) or see the [Get Started Guide](https://docs.docker.com/ai/mcp-catalog-and-toolkit/get-started/).
diff --git a/content/guides/images/agentic-ai-app.png b/content/guides/images/agentic-ai-app.png
new file mode 100644
index 000000000000..2cde645ffb9a
Binary files /dev/null and b/content/guides/images/agentic-ai-app.png differ
diff --git a/content/guides/images/agentic-ai-diagram.webp b/content/guides/images/agentic-ai-diagram.webp
new file mode 100644
index 000000000000..bc89353fb41f
Binary files /dev/null and b/content/guides/images/agentic-ai-diagram.webp differ
diff --git a/content/guides/images/gemini-grafana-list-datasources.webp b/content/guides/images/gemini-grafana-list-datasources.webp
new file mode 100644
index 000000000000..c87aed0d8af0
Binary files /dev/null and b/content/guides/images/gemini-grafana-list-datasources.webp differ
diff --git a/content/guides/images/genai-claude-code-mcp-catalog-docker-hub.avif b/content/guides/images/genai-claude-code-mcp-catalog-docker-hub.avif
new file mode 100644
index 000000000000..22398f6f59cb
Binary files /dev/null and b/content/guides/images/genai-claude-code-mcp-catalog-docker-hub.avif differ
diff --git a/content/guides/images/genai-claude-code-mcp-docker-connect-claude.avif b/content/guides/images/genai-claude-code-mcp-docker-connect-claude.avif
new file mode 100644
index 000000000000..692b0e8badb0
Binary files /dev/null and b/content/guides/images/genai-claude-code-mcp-docker-connect-claude.avif differ
diff --git a/content/guides/images/genai-claude-code-mcp-dockerhub-secrets.avif b/content/guides/images/genai-claude-code-mcp-dockerhub-secrets.avif
new file mode 100644
index 000000000000..94e3894b2004
Binary files /dev/null and b/content/guides/images/genai-claude-code-mcp-dockerhub-secrets.avif differ
diff --git a/content/guides/images/genai-claude-code-mcp-localhost.avif b/content/guides/images/genai-claude-code-mcp-localhost.avif
new file mode 100644
index 000000000000..057f854c1fcd
Binary files /dev/null and b/content/guides/images/genai-claude-code-mcp-localhost.avif differ
diff --git a/content/guides/images/genai-claude-code-mcp-mcp-servers.avif b/content/guides/images/genai-claude-code-mcp-mcp-servers.avif
new file mode 100644
index 000000000000..71f64840f687
Binary files /dev/null and b/content/guides/images/genai-claude-code-mcp-mcp-servers.avif differ
diff --git a/content/guides/genai-leveraging-rag/image.png b/content/guides/images/genai-leveraging-rag-1.png
similarity index 100%
rename from content/guides/genai-leveraging-rag/image.png
rename to content/guides/images/genai-leveraging-rag-1.png
diff --git a/content/guides/genai-leveraging-rag/image-1.png b/content/guides/images/genai-leveraging-rag-2.png
similarity index 100%
rename from content/guides/genai-leveraging-rag/image-1.png
rename to content/guides/images/genai-leveraging-rag-2.png
diff --git a/content/guides/genai-leveraging-rag/image-2.png b/content/guides/images/genai-leveraging-rag-3.png
similarity index 100%
rename from content/guides/genai-leveraging-rag/image-2.png
rename to content/guides/images/genai-leveraging-rag-3.png
diff --git a/content/guides/genai-leveraging-rag/image-3.png b/content/guides/images/genai-leveraging-rag-4.png
similarity index 100%
rename from content/guides/genai-leveraging-rag/image-3.png
rename to content/guides/images/genai-leveraging-rag-4.png
diff --git a/content/guides/genai-video-bot/images/architecture.webp b/content/guides/images/genai-video-bot-architecture.webp
similarity index 100%
rename from content/guides/genai-video-bot/images/architecture.webp
rename to content/guides/images/genai-video-bot-architecture.webp
diff --git a/content/guides/genai-video-bot/images/bot.webp b/content/guides/images/genai-video-bot-bot.webp
similarity index 100%
rename from content/guides/genai-video-bot/images/bot.webp
rename to content/guides/images/genai-video-bot-bot.webp
diff --git a/content/guides/genai-video-bot/images/embeddings.webp b/content/guides/images/genai-video-bot-embeddings.webp
similarity index 100%
rename from content/guides/genai-video-bot/images/embeddings.webp
rename to content/guides/images/genai-video-bot-embeddings.webp
diff --git a/content/guides/genai-video-bot/images/yt-whisper-2.webp b/content/guides/images/genai-video-bot-yt-whisper-2.webp
similarity index 100%
rename from content/guides/genai-video-bot/images/yt-whisper-2.webp
rename to content/guides/images/genai-video-bot-yt-whisper-2.webp
diff --git a/content/guides/genai-video-bot/images/yt-whisper.webp b/content/guides/images/genai-video-bot-yt-whisper.webp
similarity index 100%
rename from content/guides/genai-video-bot/images/yt-whisper.webp
rename to content/guides/images/genai-video-bot-yt-whisper.webp
diff --git a/content/guides/java/images/compose-logs.webp b/content/guides/images/java-compose-logs.webp
similarity index 100%
rename from content/guides/java/images/compose-logs.webp
rename to content/guides/images/java-compose-logs.webp
diff --git a/content/guides/java/images/connect-debugger.webp b/content/guides/images/java-connect-debugger.webp
similarity index 100%
rename from content/guides/java/images/connect-debugger.webp
rename to content/guides/images/java-connect-debugger.webp
diff --git a/content/guides/java/images/debug-menu.webp b/content/guides/images/java-debug-menu.webp
similarity index 100%
rename from content/guides/java/images/debug-menu.webp
rename to content/guides/images/java-debug-menu.webp
diff --git a/content/guides/java/images/debugger-breakpoint.webp b/content/guides/images/java-debugger-breakpoint.webp
similarity index 100%
rename from content/guides/java/images/debugger-breakpoint.webp
rename to content/guides/images/java-debugger-breakpoint.webp
diff --git a/content/guides/images/list-datasources-result.webp b/content/guides/images/list-datasources-result.webp
new file mode 100644
index 000000000000..965301351c1f
Binary files /dev/null and b/content/guides/images/list-datasources-result.webp differ
diff --git a/content/guides/images/mcp-docker-grafana-loki-1.webp b/content/guides/images/mcp-docker-grafana-loki-1.webp
new file mode 100644
index 000000000000..db4c3c30097a
Binary files /dev/null and b/content/guides/images/mcp-docker-grafana-loki-1.webp differ
diff --git a/content/guides/images/mcp-docker-grafana-loki-2.webp b/content/guides/images/mcp-docker-grafana-loki-2.webp
new file mode 100644
index 000000000000..ddc7cc4005c9
Binary files /dev/null and b/content/guides/images/mcp-docker-grafana-loki-2.webp differ
diff --git a/content/guides/images/mcp-docker-grafana-loki-3.webp b/content/guides/images/mcp-docker-grafana-loki-3.webp
new file mode 100644
index 000000000000..55172ee86dc9
Binary files /dev/null and b/content/guides/images/mcp-docker-grafana-loki-3.webp differ
diff --git a/content/guides/images/mcp-grafana-dashboards.webp b/content/guides/images/mcp-grafana-dashboards.webp
new file mode 100644
index 000000000000..90e570957cb4
Binary files /dev/null and b/content/guides/images/mcp-grafana-dashboards.webp differ
diff --git a/content/guides/images/mcp-grafana-summary-dashboard.webp b/content/guides/images/mcp-grafana-summary-dashboard.webp
new file mode 100644
index 000000000000..d616267076fb
Binary files /dev/null and b/content/guides/images/mcp-grafana-summary-dashboard.webp differ
diff --git a/content/guides/java.md b/content/guides/java.md
new file mode 100644
index 000000000000..b2958a107410
--- /dev/null
+++ b/content/guides/java.md
@@ -0,0 +1,796 @@
+---
+title: Java language-specific guide
+linkTitle: Java
+keywords: java, getting started
+description: Containerize Java apps using Docker
+summary: |
+  This guide demonstrates how to containerize Java applications using Docker.
+aliases:
+  - /language/java/
+  - /guides/language/java/
+  - /language/java/build-images/
+  - /language/java/run-containers/
+  - /language/java/containerize/
+  - /language/java/develop/
+  - /language/java/run-tests/
+  - /language/java/configure-ci-cd/
+  - /language/java/deploy/
+  - /guides/java/configure-ci-cd/
+  - /guides/java/containerize/
+  - /guides/java/deploy/
+  - /guides/java/develop/
+  - /guides/java/run-tests/
+params:
+  tags: [languages]
+  time: 20 minutes
+---
+
+The Java getting started guide teaches you how to create a containerized Spring Boot application using Docker. In this module, you’ll learn how to:
+
+- Containerize and run a Spring Boot application with Maven
+- Set up a local development environment to connect a database to the container, configure a debugger, and use Compose Watch for live reload
+- Run your unit tests inside a container
+
+After completing the Java getting started modules, you should be able to containerize your own Java application based on the examples and instructions provided in this guide.
+
+Get started containerizing your first Java app.
+
+## Containerize a Java application
+
+### Prerequisites
+
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
+  Docker adds new features regularly and some parts of this guide may
+  work only with the latest version of Docker Desktop.
+
+* You have a [Git client](https://git-scm.com/downloads). The examples in this
+  section use a command-line based Git client, but you can use any client.
+
+### Overview
+
+This section walks you through containerizing and running a Java
+application.
+
+### Get the sample applications
+
+Clone the sample application that you'll be using to your local development machine. Run the following command in a terminal to clone the repository.
+
+```console
+$ git clone https://github.com/spring-projects/spring-petclinic.git
+```
+
+The sample application is a Spring Boot application built using Maven. For more details, see `readme.md` in the repository.
+
+### Create Docker assets
+
+Now that you have an application, you can create the necessary Docker assets to
+containerize your application.
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for your project. Ask Gordon to create a Dockerfile, Compose file, and `.dockerignore` tailored to your application.
+
+Create a file named `Dockerfile` with the following contents.
+
+```dockerfile {collapse=true,title=Dockerfile}
+# syntax=docker/dockerfile:1
+
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Dockerfile reference guide at
+# https://docs.docker.com/go/dockerfile-reference/
+
+################################################################################
+
+# Create a stage for resolving and downloading dependencies.
+FROM eclipse-temurin:21-jdk-jammy as deps
+
+WORKDIR /build
+
+# Copy the mvnw wrapper with executable permissions.
+COPY --chmod=0755 mvnw mvnw
+COPY .mvn/ .mvn/
+
+# Download dependencies as a separate step to take advantage of Docker's caching.
+# Leverage a cache mount to /root/.m2 so that subsequent builds don't have to
+# re-download packages.
+RUN --mount=type=bind,source=pom.xml,target=pom.xml \
+    --mount=type=cache,target=/root/.m2 ./mvnw dependency:go-offline -DskipTests
+
+################################################################################
+
+# Create a stage for building the application based on the stage with downloaded dependencies.
+# This Dockerfile is optimized for Java applications that output an uber jar, which includes
+# all the dependencies needed to run your app inside a JVM. If your app doesn't output an uber
+# jar and instead relies on an application server like Apache Tomcat, you'll need to update this
+# stage with the correct filename of your package and update the base image of the "final" stage
+# use the relevant app server, e.g., using tomcat (https://hub.docker.com/_/tomcat/) as a base image.
+FROM deps as package
+
+WORKDIR /build
+
+COPY ./src src/
+RUN --mount=type=bind,source=pom.xml,target=pom.xml \
+    --mount=type=cache,target=/root/.m2 \
+    ./mvnw package -DskipTests && \
+    mv target/$(./mvnw help:evaluate -Dexpression=project.artifactId -q -DforceStdout)-$(./mvnw help:evaluate -Dexpression=project.version -q -DforceStdout).jar target/app.jar
+
+################################################################################
+
+# Create a stage for extracting the application into separate layers.
+# Take advantage of Spring Boot's layer tools and Docker's caching by extracting
+# the packaged application into separate layers that can be copied into the final stage.
+# See Spring's docs for reference:
+# https://docs.spring.io/spring-boot/docs/current/reference/html/container-images.html
+FROM package as extract
+
+WORKDIR /build
+
+RUN java -Djarmode=layertools -jar target/app.jar extract --destination target/extracted
+
+################################################################################
+
+# Create a new stage for running the application that contains the minimal
+# runtime dependencies for the application. This often uses a different base
+# image from the install or build stage where the necessary files are copied
+# from the install stage.
+#
+# The example below uses eclipse-turmin's JRE image as the foundation for running the app.
+# By specifying the "17-jre-jammy" tag, it will also use whatever happens to be the
+# most recent version of that tag when you build your Dockerfile.
+# If reproducibility is important, consider using a specific digest SHA, like
+# eclipse-temurin@sha256:99cede493dfd88720b610eb8077c8688d3cca50003d76d1d539b0efc8cca72b4.
+FROM eclipse-temurin:21-jre-jammy AS final
+
+# Create a non-privileged user that the app will run under.
+# See https://docs.docker.com/go/dockerfile-user-best-practices/
+ARG UID=10001
+RUN adduser \
+    --disabled-password \
+    --gecos "" \
+    --home "/nonexistent" \
+    --shell "/sbin/nologin" \
+    --no-create-home \
+    --uid "${UID}" \
+    appuser
+USER appuser
+
+# Copy the executable from the "package" stage.
+COPY --from=extract build/target/extracted/dependencies/ ./
+COPY --from=extract build/target/extracted/spring-boot-loader/ ./
+COPY --from=extract build/target/extracted/snapshot-dependencies/ ./
+COPY --from=extract build/target/extracted/application/ ./
+
+EXPOSE 8080
+
+ENTRYPOINT [ "java", "org.springframework.boot.loader.launch.JarLauncher" ]
+```
+
+> [!NOTE]
+> The sample repository includes a `docker-compose.yml` file. The following instructions use the preferred `compose.yaml` filename — both are supported by Docker Compose.
+
+Create a file named `compose.yaml` with the following contents.
+
+```yaml {collapse=true,title=compose.yaml}
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Docker Compose reference guide at
+# https://docs.docker.com/go/compose-spec-reference/
+
+# Here the instructions define your application as a service called "server".
+# This service is built from the Dockerfile in the current directory.
+# You can add other services your application may depend on here, such as a
+# database or a cache. For examples, see the Awesome Compose repository:
+# https://github.com/docker/awesome-compose
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 8080:8080
+# The commented out section below is an example of how to define a PostgreSQL
+# database that your application can use. `depends_on` tells Docker Compose to
+# start the database before your application. The `db-data` volume persists the
+# database data between container restarts. The `db-password` secret is used
+# to set the database password. You must create `db/password.txt` and add
+# a password of your choosing to it before running `docker compose up`.
+#     depends_on:
+#       db:
+#         condition: service_healthy
+#   db:
+#     image: postgres:18
+#     restart: always
+#     user: postgres
+#     secrets:
+#       - db-password
+#     volumes:
+#       - db-data:/var/lib/postgresql
+#     environment:
+#       - POSTGRES_DB=example
+#       - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+#     expose:
+#       - 5432
+#     healthcheck:
+#       test: [ "CMD", "pg_isready" ]
+#       interval: 10s
+#       timeout: 5s
+#       retries: 5
+# volumes:
+#   db-data:
+# secrets:
+#   db-password:
+#     file: db/password.txt
+```
+
+Create a file named `.dockerignore` with the following contents.
+
+```text {collapse=true,title=".dockerignore"}
+# Include any files or directories that you don't want to be copied to your
+# container here (e.g., local build artifacts, temporary files, etc.).
+#
+# For more help, visit the .dockerignore file reference guide at
+# https://docs.docker.com/go/build-context-dockerignore/
+
+**/.classpath
+**/.dockerignore
+**/.env
+**/.git
+**/.gitignore
+**/.project
+**/.settings
+**/.toolstarget
+**/.vs
+**/.vscode
+**/.next
+**/.cache
+**/*.*proj.user
+**/*.dbmdl
+**/*.jfm
+**/charts
+**/docker-compose*
+**/compose.y*ml
+**/target
+**/Dockerfile*
+**/node_modules
+**/npm-debug.log
+**/obj
+**/secrets.dev.yaml
+**/values.dev.yaml
+**/vendor
+LICENSE
+README.md
+```
+
+You should now have the following three files in your `spring-petclinic`
+directory.
+
+- [Dockerfile](/reference/dockerfile/)
+- [.dockerignore](/reference/dockerfile/#dockerignore-file)
+- [compose.yaml](/reference/compose-file/_index.md)
+
+### Run the application
+
+Inside the `spring-petclinic` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+The first time you build and run the app, Docker downloads dependencies and builds the app. It may take several minutes depending on your network connection.
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple app for a pet clinic.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `spring-petclinic` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple app for a pet clinic.
+
+In the terminal, run the following command to stop the application.
+
+```console
+$ docker compose down
+```
+
+For more information about Compose commands, see the
+[Compose CLI reference](/reference/cli/docker/compose/).
+
+## Use containers for Java development
+
+### Prerequisites
+
+Work through the steps to containerize your application in [Containerize your app](#containerize-a-java-application).
+
+### Overview
+
+In this section, you’ll walk through setting up a local development environment
+for the application you containerized in the previous section. This includes:
+
+- Adding a local database and persisting data
+- Creating a development container to connect a debugger
+- Configuring Compose to automatically update your running Compose services as
+  you edit and save your code
+
+### Add a local database and persist data
+
+You can use containers to set up local services, like a database. In this section, you'll update the `docker-compose.yaml` file to define a database service and a volume to persist data. Also, this particular application uses a system property to define the database type, so you'll need to update the `Dockerfile` to pass in the system property when starting the app.
+
+In the cloned repository's directory, open the `docker-compose.yaml` file in an IDE or text editor. Your Compose file has an example database service, but it'll require a few changes for your unique app.
+
+In the `docker-compose.yaml` file, you need to do the following:
+
+- Uncomment all of the database instructions. You'll now use a database service
+  instead of local storage for the data.
+- Remove the top-level `secrets` element as well as the element inside the `db`
+  service. This example uses the environment variable for the password rather than secrets.
+- Remove the `user` element from the `db` service. This example specifies the
+  user in the environment variable.
+- Update the database environment variables. These are defined by the Postgres
+  image. For more details, see the
+  [Postgres Official Docker Image](https://hub.docker.com/_/postgres).
+- Update the healthcheck test for the `db` service and specify the user. By
+  default, the healthcheck uses the root user instead of the `petclinic` user
+  you defined.
+- Add the database URL as an environment variable in the `server` service. This
+  overrides the default value defined in
+  `spring-petclinic/src/main/resources/application-postgres.properties`.
+
+The following is the updated `docker-compose.yaml` file. All comments have been removed.
+
+```yaml {hl_lines="7-29"}
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 8080:8080
+    depends_on:
+      db:
+        condition: service_healthy
+    environment:
+      - POSTGRES_URL=jdbc:postgresql://db:5432/petclinic
+  db:
+    image: postgres:18
+    restart: always
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=petclinic
+      - POSTGRES_USER=petclinic
+      - POSTGRES_PASSWORD=petclinic
+    ports:
+      - 5432:5432
+    healthcheck:
+      test: ["CMD", "pg_isready", "-U", "petclinic"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+```
+
+Open the `Dockerfile` in an IDE or text editor. In the `ENTRYPOINT` instruction,
+update the instruction to pass in the system property as specified in the
+`spring-petclinic/src/resources/db/postgres/petclinic_db_setup_postgres.txt`
+file.
+
+```diff
+- ENTRYPOINT [ "java", "org.springframework.boot.loader.launch.JarLauncher" ]
++ ENTRYPOINT [ "java", "-Dspring.profiles.active=postgres", "org.springframework.boot.loader.launch.JarLauncher" ]
+```
+
+Save and close all the files.
+
+Now, run the following `docker compose up` command to start your application.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple app for a pet clinic. Browse around the application. Navigate to **Veterinarians** and verify that the application is connected to the database by being able to list veterinarians.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+### Dockerfile for development
+
+The Dockerfile you have now is great for a small, secure production image with
+only the components necessary to run the application. When developing, you may
+want a different image that has a different environment.
+
+For example, in the development image you may want to set up the image to start
+the application so that you can connect a debugger to the running Java process.
+
+Rather than managing multiple Dockerfiles, you can add a new stage. Your
+Dockerfile can then produce a final image which is ready for production as well
+as a development image.
+
+Replace the contents of your Dockerfile with the following.
+
+```dockerfile {hl_lines="22-29"}
+# syntax=docker/dockerfile:1
+
+FROM eclipse-temurin:21-jdk-jammy as deps
+WORKDIR /build
+COPY --chmod=0755 mvnw mvnw
+COPY .mvn/ .mvn/
+RUN --mount=type=bind,source=pom.xml,target=pom.xml \
+    --mount=type=cache,target=/root/.m2 ./mvnw dependency:go-offline -DskipTests
+
+FROM deps as package
+WORKDIR /build
+COPY ./src src/
+RUN --mount=type=bind,source=pom.xml,target=pom.xml \
+    --mount=type=cache,target=/root/.m2 \
+    ./mvnw package -DskipTests && \
+    mv target/$(./mvnw help:evaluate -Dexpression=project.artifactId -q -DforceStdout)-$(./mvnw help:evaluate -Dexpression=project.version -q -DforceStdout).jar target/app.jar
+
+FROM package as extract
+WORKDIR /build
+RUN java -Djarmode=layertools -jar target/app.jar extract --destination target/extracted
+
+FROM extract as development
+WORKDIR /build
+RUN cp -r /build/target/extracted/dependencies/. ./
+RUN cp -r /build/target/extracted/spring-boot-loader/. ./
+RUN cp -r /build/target/extracted/snapshot-dependencies/. ./
+RUN cp -r /build/target/extracted/application/. ./
+ENV JAVA_TOOL_OPTIONS -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000
+CMD [ "java", "-Dspring.profiles.active=postgres", "org.springframework.boot.loader.launch.JarLauncher" ]
+
+FROM eclipse-temurin:21-jre-jammy AS final
+ARG UID=10001
+RUN adduser \
+    --disabled-password \
+    --gecos "" \
+    --home "/nonexistent" \
+    --shell "/sbin/nologin" \
+    --no-create-home \
+    --uid "${UID}" \
+    appuser
+USER appuser
+COPY --from=extract build/target/extracted/dependencies/ ./
+COPY --from=extract build/target/extracted/spring-boot-loader/ ./
+COPY --from=extract build/target/extracted/snapshot-dependencies/ ./
+COPY --from=extract build/target/extracted/application/ ./
+EXPOSE 8080
+ENTRYPOINT [ "java", "-Dspring.profiles.active=postgres", "org.springframework.boot.loader.launch.JarLauncher" ]
+```
+
+Save and close the `Dockerfile`.
+
+In the `Dockerfile` you added a new stage labeled `development` based on the `extract` stage. In this stage, you copy the extracted files to a common directory, then run a command to start the application. In the command, you expose port 8000 and declare the debug configuration for the JVM so that you can attach a debugger.
+
+### Use Compose to develop locally
+
+The current Compose file doesn't start your development container. To do that, you must update your Compose file to target the development stage. Also, update the port mapping of the server service to provide access for the debugger.
+
+Open the `docker-compose.yaml` and add the following instructions into the file.
+
+```yaml {hl_lines=["5","8"]}
+services:
+  server:
+    build:
+      context: .
+      target: development
+    ports:
+      - 8080:8080
+      - 8000:8000
+    depends_on:
+      db:
+        condition: service_healthy
+    environment:
+      - POSTGRES_URL=jdbc:postgresql://db:5432/petclinic
+  db:
+    image: postgres:18
+    restart: always
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=petclinic
+      - POSTGRES_USER=petclinic
+      - POSTGRES_PASSWORD=petclinic
+    ports:
+      - 5432:5432
+    healthcheck:
+      test: ["CMD", "pg_isready", "-U", "petclinic"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+```
+
+Now, start your application and to confirm that it's running.
+
+```console
+$ docker compose up --build
+```
+
+Finally, test your API endpoint. Run the following curl command:
+
+```console
+$ curl  --request GET \
+  --url http://localhost:8080/vets \
+  --header 'content-type: application/json'
+```
+
+You should receive the following response:
+
+```json
+{
+  "vetList": [
+    {
+      "id": 1,
+      "firstName": "James",
+      "lastName": "Carter",
+      "specialties": [],
+      "nrOfSpecialties": 0,
+      "new": false
+    },
+    {
+      "id": 2,
+      "firstName": "Helen",
+      "lastName": "Leary",
+      "specialties": [{ "id": 1, "name": "radiology", "new": false }],
+      "nrOfSpecialties": 1,
+      "new": false
+    },
+    {
+      "id": 3,
+      "firstName": "Linda",
+      "lastName": "Douglas",
+      "specialties": [
+        { "id": 3, "name": "dentistry", "new": false },
+        { "id": 2, "name": "surgery", "new": false }
+      ],
+      "nrOfSpecialties": 2,
+      "new": false
+    },
+    {
+      "id": 4,
+      "firstName": "Rafael",
+      "lastName": "Ortega",
+      "specialties": [{ "id": 2, "name": "surgery", "new": false }],
+      "nrOfSpecialties": 1,
+      "new": false
+    },
+    {
+      "id": 5,
+      "firstName": "Henry",
+      "lastName": "Stevens",
+      "specialties": [{ "id": 1, "name": "radiology", "new": false }],
+      "nrOfSpecialties": 1,
+      "new": false
+    },
+    {
+      "id": 6,
+      "firstName": "Sharon",
+      "lastName": "Jenkins",
+      "specialties": [],
+      "nrOfSpecialties": 0,
+      "new": false
+    }
+  ]
+}
+```
+
+### Connect a Debugger
+
+You’ll use the debugger that comes with the IntelliJ IDEA. You can use the community version of this IDE. Open your project in IntelliJ IDEA, go to the **Run** menu, and then **Edit Configuration**. Add a new Remote JVM Debug configuration similar to the following:
+
+![Java Connect a Debugger](images/java-connect-debugger.webp)
+
+Set a breakpoint.
+
+Open `src/main/java/org/springframework/samples/petclinic/vet/VetController.java` and add a breakpoint inside the `showResourcesVetList` function.
+
+To start your debug session, select the **Run** menu and then **Debug _NameOfYourConfiguration_**.
+
+![Debug menu](images/java-debug-menu.webp?w=300)
+
+You should now see the connection in the logs of your Compose application.
+
+![Compose log file](images/java-compose-logs.webp)
+
+You can now call the server endpoint.
+
+```console
+$ curl --request GET --url http://localhost:8080/vets
+```
+
+You should have seen the code break on the marked line and now you are able to use the debugger just like you would normally. You can also inspect and watch variables, set conditional breakpoints, view stack traces and a do bunch of other stuff.
+
+![Debugger code breakpoint](images/java-debugger-breakpoint.webp)
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Automatically update services
+
+Use Compose Watch to automatically update your running Compose services as you
+edit and save your code. For more details about Compose Watch, see
+[Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
+
+Open your `docker-compose.yaml` file in an IDE or text editor and then add the
+Compose Watch instructions. The following is the updated `docker-compose.yaml`
+file.
+
+```yaml {hl_lines="14-17"}
+services:
+  server:
+    build:
+      context: .
+      target: development
+    ports:
+      - 8080:8080
+      - 8000:8000
+    depends_on:
+      db:
+        condition: service_healthy
+    environment:
+      - POSTGRES_URL=jdbc:postgresql://db:5432/petclinic
+    develop:
+      watch:
+        - action: rebuild
+          path: .
+  db:
+    image: postgres:18
+    restart: always
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=petclinic
+      - POSTGRES_USER=petclinic
+      - POSTGRES_PASSWORD=petclinic
+    ports:
+      - 5432:5432
+    healthcheck:
+      test: ["CMD", "pg_isready", "-U", "petclinic"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+```
+
+Run the following command to run your application with Compose Watch.
+
+```console
+$ docker compose watch
+```
+
+Open a web browser and view the application at [http://localhost:8080](http://localhost:8080). You should see the Spring Pet Clinic home page.
+
+Any changes to the application's source files on your local machine will now be automatically reflected in the running container.
+
+Open `spring-petclinic/src/main/resources/templates/fragments/layout.html` in an IDE or text editor and update the `Home` navigation string by adding an exclamation mark.
+
+```diff
+-   <li th:replace="~{::menuItem ('/','home','home page','home','Home')}">
++   <li th:replace="~{::menuItem ('/','home','home page','home','Home!')}">
+
+```
+
+Save the changes to `layout.html` and then you can continue developing while the container automatically rebuilds.
+
+After the container is rebuilt and running, refresh [http://localhost:8080](http://localhost:8080) and then verify that **Home!** now appears in the menu.
+
+Press `ctrl+c` in the terminal to stop Compose Watch.
+
+## Run your Java tests
+
+### Prerequisites
+
+Complete all the previous sections of this guide, starting with [Containerize a Java application](#containerize-a-java-application).
+
+### Overview
+
+Testing is an essential part of modern software development. Testing can mean a lot of things to different development teams. There are unit tests, integration tests and end-to-end testing. In this guide you'll take a look at running your unit tests in Docker.
+
+#### Multi-stage Dockerfile for testing
+
+In the following example, you'll pull the testing commands into your Dockerfile.
+Replace the contents of your Dockerfile with the following.
+
+```dockerfile {hl_lines="3-19"}
+# syntax=docker/dockerfile:1
+
+FROM eclipse-temurin:21-jdk-jammy as base
+WORKDIR /build
+COPY --chmod=0755 mvnw mvnw
+COPY .mvn/ .mvn/
+
+FROM base as test
+WORKDIR /build
+COPY ./src src/
+RUN --mount=type=bind,source=pom.xml,target=pom.xml \
+    --mount=type=cache,target=/root/.m2 \
+    ./mvnw test
+
+FROM base as deps
+WORKDIR /build
+RUN --mount=type=bind,source=pom.xml,target=pom.xml \
+    --mount=type=cache,target=/root/.m2 \
+    ./mvnw dependency:go-offline -DskipTests
+
+FROM deps as package
+WORKDIR /build
+COPY ./src src/
+RUN --mount=type=bind,source=pom.xml,target=pom.xml \
+    --mount=type=cache,target=/root/.m2 \
+    ./mvnw package -DskipTests && \
+    mv target/$(./mvnw help:evaluate -Dexpression=project.artifactId -q -DforceStdout)-$(./mvnw help:evaluate -Dexpression=project.version -q -DforceStdout).jar target/app.jar
+
+FROM package as extract
+WORKDIR /build
+RUN java -Djarmode=layertools -jar target/app.jar extract --destination target/extracted
+
+FROM extract as development
+WORKDIR /build
+RUN cp -r /build/target/extracted/dependencies/. ./
+RUN cp -r /build/target/extracted/spring-boot-loader/. ./
+RUN cp -r /build/target/extracted/snapshot-dependencies/. ./
+RUN cp -r /build/target/extracted/application/. ./
+ENV JAVA_TOOL_OPTIONS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000"
+CMD [ "java", "-Dspring.profiles.active=postgres", "org.springframework.boot.loader.launch.JarLauncher" ]
+
+FROM eclipse-temurin:21-jre-jammy AS final
+ARG UID=10001
+RUN adduser \
+    --disabled-password \
+    --gecos "" \
+    --home "/nonexistent" \
+    --shell "/sbin/nologin" \
+    --no-create-home \
+    --uid "${UID}" \
+    appuser
+USER appuser
+COPY --from=extract build/target/extracted/dependencies/ ./
+COPY --from=extract build/target/extracted/spring-boot-loader/ ./
+COPY --from=extract build/target/extracted/snapshot-dependencies/ ./
+COPY --from=extract build/target/extracted/application/ ./
+EXPOSE 8080
+ENTRYPOINT [ "java", "-Dspring.profiles.active=postgres", "org.springframework.boot.loader.launch.JarLauncher" ]
+```
+
+First, you added a new base stage. In the base stage, you added common instructions that both the test and deps stage will need.
+
+Next, you added a new test stage labeled `test` based on the base stage. In this
+stage you copied in the necessary source files and then specified `RUN` to run
+`./mvnw test`. Instead of using `CMD`, you used `RUN` to run the tests. The
+reason is that the `CMD` instruction runs when the container runs, and the `RUN`
+instruction runs when the image is being built. When using `RUN`, the build will
+fail if the tests fail.
+
+Finally, you updated the deps stage to be based on the base stage and removed
+the instructions that are now in the base stage.
+
+Run the following command to build a new image using the test stage as the target and view the test results. Include `--progress=plain` to view the build output, `--no-cache` to ensure the tests always run, and `--target test` to target the test stage.
+
+Now, build your image and run your tests. You'll run the `docker build` command and add the `--target test` flag so that you specifically run the test build stage.
+
+```console
+$ docker build -t java-docker-image-test --progress=plain --no-cache --target=test .
+```
+
+You should see output containing the following
+
+```console
+...
+
+#15 101.3 [WARNING] Tests run: 45, Failures: 0, Errors: 0, Skipped: 2
+#15 101.3 [INFO]
+#15 101.3 [INFO] ------------------------------------------------------------------------
+#15 101.3 [INFO] BUILD SUCCESS
+#15 101.3 [INFO] ------------------------------------------------------------------------
+#15 101.3 [INFO] Total time:  01:39 min
+#15 101.3 [INFO] Finished at: 2024-02-01T23:24:48Z
+#15 101.3 [INFO] ------------------------------------------------------------------------
+#15 DONE 101.4s
+```
diff --git a/content/guides/java/_index.md b/content/guides/java/_index.md
deleted file mode 100644
index b605ffd48457..000000000000
--- a/content/guides/java/_index.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Java language-specific guide
-linkTitle: Java
-keywords: java, getting started
-description: Containerize Java apps using Docker
-summary: |
-  This guide demonstrates how to containerize Java applications using Docker.
-toc_min: 1
-toc_max: 2
-aliases:
-  - /language/java/
-  - /guides/language/java/
-languages: [java]
-params:
-  time: 20 minutes
----
-
-The Java getting started guide teaches you how to create a containerized Spring Boot application using Docker. In this module, you’ll learn how to:
-
-- Containerize and run a Spring Boot application with Maven
-- Set up a local development environment to connect a database to the container, configure a debugger, and use Compose Watch for live reload
-- Run your unit tests inside a container
-- Configure a CI/CD pipeline for your application using GitHub Actions
-- Deploy your containerized application locally to Kubernetes to test and debug your deployment
-
-After completing the Java getting started modules, you should be able to containerize your own Java application based on the examples and instructions provided in this guide.
-
-Get started containerizing your first Java app.
diff --git a/content/guides/java/configure-ci-cd.md b/content/guides/java/configure-ci-cd.md
deleted file mode 100644
index 560c130c1086..000000000000
--- a/content/guides/java/configure-ci-cd.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title: Configure CI/CD for your Java application
-linkTitle: Configure CI/CD
-weight: 40
-keywords: java, CI/CD, local, development
-description: Learn how to Configure CI/CD for your Java application
-aliases:
-  - /language/java/configure-ci-cd/
-  - /guides/language/java/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete the previous sections of this guide, starting with [Containerize your app](containerize.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-## Overview
-
-In this section, you'll learn how to set up and use GitHub Actions to build and push your Docker image to Docker Hub. You will complete the following steps:
-
-1. Create a new repository on GitHub.
-2. Define the GitHub Actions workflow.
-3. Run the workflow.
-
-## Step one: Create the repository
-
-Create a GitHub repository, configure the Docker Hub credentials, and push your source code.
-
-1. [Create a new repository](https://github.com/new) on GitHub.
-
-2. Open the repository **Settings**, and go to **Secrets and variables** >
-   **Actions**.
-
-3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-4. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-5. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-6. In your local repository on your machine, run the following command to change
-   the origin to the repository you just created. Make sure you change
-   `your-username` to your GitHub username and `your-repository` to the name of
-   the repository you created.
-
-   ```console
-   $ git remote set-url origin https://github.com/your-username/your-repository.git
-   ```
-
-7. Run the following commands to stage, commit, and push your local repository to GitHub.
-
-   ```console
-   $ git add -A
-   $ git commit -m "my commit"
-   $ git push -u origin main
-   ```
-
-## Step two: Set up the workflow
-
-Set up your GitHub Actions workflow for building, testing, and pushing the image
-to Docker Hub.
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-   The project already has the `maven-build` workflow to build and test your Java application with Maven. If you want, you can optionally disable this workflow because you won't use it in this guide. You'll create a new, alternate workflow to build, test, and push your image.
-
-2. Select **New workflow**.
-
-3. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub actions workflow file in
-   your repository, under `.github/workflows/main.yml` by default.
-
-4. In the editor window, copy and paste the following YAML configuration.
-
-   ```yaml
-   name: ci
-
-   on:
-     push:
-       branches:
-         - main
-
-   jobs:
-     build:
-       runs-on: ubuntu-latest
-       steps:
-         - name: Login to Docker Hub
-           uses: docker/login-action@v3
-           with:
-             username: ${{ vars.DOCKER_USERNAME }}
-             password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-         - name: Set up Docker Buildx
-           uses: docker/setup-buildx-action@v3
-
-         - name: Build and test
-           uses: docker/build-push-action@v6
-           with:
-             target: test
-             load: true
-
-         - name: Build and push
-           uses: docker/build-push-action@v6
-           with:
-             platforms: linux/amd64,linux/arm64
-             push: true
-             target: final
-             tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-   ```
-
-   For more information about the YAML syntax for `docker/build-push-action`,
-   refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
-## Step three: Run the workflow
-
-Save the workflow file and run the job.
-
-1. Select **Commit changes...** and push the changes to the `main` branch.
-
-   After pushing the commit, the workflow starts automatically.
-
-2. Go to the **Actions** tab. It displays the workflow.
-
-   Selecting the workflow shows you the breakdown of all the steps.
-
-3. When the workflow is complete, go to your
-   [repositories on Docker Hub](https://hub.docker.com/repositories).
-
-   If you see the new repository in that list, it means the GitHub Actions
-   successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your application.
-
-Related information:
-
-- [Introduction to GitHub Actions](/guides/gha.md)
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md)
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-Next, learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/java/containerize.md b/content/guides/java/containerize.md
deleted file mode 100644
index b3cbfff03783..000000000000
--- a/content/guides/java/containerize.md
+++ /dev/null
@@ -1,334 +0,0 @@
----
-title: Containerize a Java application
-linkTitle: Containerize your app
-weight: 10
-keywords: java, containerize, initialize, maven, build
-description: Learn how to containerize a Java application.
-aliases:
-  - /language/java/build-images/
-  - /language/java/run-containers/
-  - /language/java/containerize/
-  - /guides/language/java/containerize/
----
-
-## Prerequisites
-
-- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
-  Docker adds new features regularly and some parts of this guide may
-  work only with the latest version of Docker Desktop.
-
-* You have a [Git client](https://git-scm.com/downloads). The examples in this
-  section use a command-line based Git client, but you can use any client.
-
-## Overview
-
-This section walks you through containerizing and running a Java
-application.
-
-## Get the sample applications
-
-Clone the sample application that you'll be using to your local development machine. Run the following command in a terminal to clone the repository.
-
-```console
-$ git clone https://github.com/spring-projects/spring-petclinic.git
-```
-
-The sample application is a Spring Boot application built using Maven. For more details, see `readme.md` in the repository.
-
-## Initialize Docker assets
-
-Now that you have an application, you can create the necessary Docker assets to
-containerize your application. You can use Docker Desktop's built-in Docker Init
-feature to help streamline the process, or you can manually create the assets.
-
-{{< tabs >}}
-{{< tab name="Use Docker Init" >}}
-
-Inside the `spring-petclinic` directory, run the `docker init` command. `docker
-init` provides some default configuration, but you'll need to answer a few
-questions about your application. Refer to the following example to answer the
-prompts from `docker init` and use the same answers for your prompts.
-
-The sample application already contains Docker assets. You'll be prompted to overwrite the existing Docker assets. To continue with this guide, select `y` to overwrite them.
-
-```console
-$ docker init
-Welcome to the Docker Init CLI!
-
-This utility will walk you through creating the following files with sensible defaults for your project:
-  - .dockerignore
-  - Dockerfile
-  - compose.yaml
-  - README.Docker.md
-
-Let's get started!
-
-WARNING: The following Docker files already exist in this directory:
-  - docker-compose.yml
-? Do you want to overwrite them? Yes
-? What application platform does your project use? Java
-? What's the relative directory (with a leading .) for your app? ./src
-? What version of Java do you want to use? 21
-? What port does your server listen on? 8080
-```
-
-In the previous example, notice the `WARNING`. `docker-compose.yaml` already
-exists, so `docker init` overwrites that file rather than creating a new
-`compose.yaml` file. This prevents having multiple Compose files in the
-directory. Both names are supported, but Compose prefers the canonical
-`compose.yaml`.
-
-{{< /tab >}}
-{{< tab name="Manually create assets" >}}
-
-If you don't have Docker Desktop installed or prefer creating the assets
-manually, you can create the following files in your project directory.
-
-Create a file named `Dockerfile` with the following contents.
-
-```dockerfile {collapse=true,title=Dockerfile}
-# syntax=docker/dockerfile:1
-
-# Comments are provided throughout this file to help you get started.
-# If you need more help, visit the Dockerfile reference guide at
-# https://docs.docker.com/go/dockerfile-reference/
-
-# Want to help us make this template better? Share your feedback here: https://forms.gle/ybq9Krt8jtBL3iCk7
-
-################################################################################
-
-# Create a stage for resolving and downloading dependencies.
-FROM eclipse-temurin:21-jdk-jammy as deps
-
-WORKDIR /build
-
-# Copy the mvnw wrapper with executable permissions.
-COPY --chmod=0755 mvnw mvnw
-COPY .mvn/ .mvn/
-
-# Download dependencies as a separate step to take advantage of Docker's caching.
-# Leverage a cache mount to /root/.m2 so that subsequent builds don't have to
-# re-download packages.
-RUN --mount=type=bind,source=pom.xml,target=pom.xml \
-    --mount=type=cache,target=/root/.m2 ./mvnw dependency:go-offline -DskipTests
-
-################################################################################
-
-# Create a stage for building the application based on the stage with downloaded dependencies.
-# This Dockerfile is optimized for Java applications that output an uber jar, which includes
-# all the dependencies needed to run your app inside a JVM. If your app doesn't output an uber
-# jar and instead relies on an application server like Apache Tomcat, you'll need to update this
-# stage with the correct filename of your package and update the base image of the "final" stage
-# use the relevant app server, e.g., using tomcat (https://hub.docker.com/_/tomcat/) as a base image.
-FROM deps as package
-
-WORKDIR /build
-
-COPY ./src src/
-RUN --mount=type=bind,source=pom.xml,target=pom.xml \
-    --mount=type=cache,target=/root/.m2 \
-    ./mvnw package -DskipTests && \
-    mv target/$(./mvnw help:evaluate -Dexpression=project.artifactId -q -DforceStdout)-$(./mvnw help:evaluate -Dexpression=project.version -q -DforceStdout).jar target/app.jar
-
-################################################################################
-
-# Create a stage for extracting the application into separate layers.
-# Take advantage of Spring Boot's layer tools and Docker's caching by extracting
-# the packaged application into separate layers that can be copied into the final stage.
-# See Spring's docs for reference:
-# https://docs.spring.io/spring-boot/docs/current/reference/html/container-images.html
-FROM package as extract
-
-WORKDIR /build
-
-RUN java -Djarmode=layertools -jar target/app.jar extract --destination target/extracted
-
-################################################################################
-
-# Create a new stage for running the application that contains the minimal
-# runtime dependencies for the application. This often uses a different base
-# image from the install or build stage where the necessary files are copied
-# from the install stage.
-#
-# The example below uses eclipse-turmin's JRE image as the foundation for running the app.
-# By specifying the "17-jre-jammy" tag, it will also use whatever happens to be the
-# most recent version of that tag when you build your Dockerfile.
-# If reproducibility is important, consider using a specific digest SHA, like
-# eclipse-temurin@sha256:99cede493dfd88720b610eb8077c8688d3cca50003d76d1d539b0efc8cca72b4.
-FROM eclipse-temurin:21-jre-jammy AS final
-
-# Create a non-privileged user that the app will run under.
-# See https://docs.docker.com/go/dockerfile-user-best-practices/
-ARG UID=10001
-RUN adduser \
-    --disabled-password \
-    --gecos "" \
-    --home "/nonexistent" \
-    --shell "/sbin/nologin" \
-    --no-create-home \
-    --uid "${UID}" \
-    appuser
-USER appuser
-
-# Copy the executable from the "package" stage.
-COPY --from=extract build/target/extracted/dependencies/ ./
-COPY --from=extract build/target/extracted/spring-boot-loader/ ./
-COPY --from=extract build/target/extracted/snapshot-dependencies/ ./
-COPY --from=extract build/target/extracted/application/ ./
-
-EXPOSE 8080
-
-ENTRYPOINT [ "java", "org.springframework.boot.loader.launch.JarLauncher" ]
-```
-
-The sample already contains a Compose file. Overwrite this file to follow along with the guide. Update the`docker-compose.yaml` with the following contents.
-
-```yaml {collapse=true,title=docker-compose.yaml}
-# Comments are provided throughout this file to help you get started.
-# If you need more help, visit the Docker Compose reference guide at
-# https://docs.docker.com/go/compose-spec-reference/
-
-# Here the instructions define your application as a service called "server".
-# This service is built from the Dockerfile in the current directory.
-# You can add other services your application may depend on here, such as a
-# database or a cache. For examples, see the Awesome Compose repository:
-# https://github.com/docker/awesome-compose
-services:
-  server:
-    build:
-      context: .
-    ports:
-      - 8080:8080
-# The commented out section below is an example of how to define a PostgreSQL
-# database that your application can use. `depends_on` tells Docker Compose to
-# start the database before your application. The `db-data` volume persists the
-# database data between container restarts. The `db-password` secret is used
-# to set the database password. You must create `db/password.txt` and add
-# a password of your choosing to it before running `docker compose up`.
-#     depends_on:
-#       db:
-#         condition: service_healthy
-#   db:
-#     image: postgres
-#     restart: always
-#     user: postgres
-#     secrets:
-#       - db-password
-#     volumes:
-#       - db-data:/var/lib/postgresql/data
-#     environment:
-#       - POSTGRES_DB=example
-#       - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-#     expose:
-#       - 5432
-#     healthcheck:
-#       test: [ "CMD", "pg_isready" ]
-#       interval: 10s
-#       timeout: 5s
-#       retries: 5
-# volumes:
-#   db-data:
-# secrets:
-#   db-password:
-#     file: db/password.txt
-
-```
-
-Create a file named `.dockerignore` with the following contents.
-
-```text {collapse=true,title=".dockerignore"}
-# Include any files or directories that you don't want to be copied to your
-# container here (e.g., local build artifacts, temporary files, etc.).
-#
-# For more help, visit the .dockerignore file reference guide at
-# https://docs.docker.com/go/build-context-dockerignore/
-
-**/.classpath
-**/.dockerignore
-**/.env
-**/.git
-**/.gitignore
-**/.project
-**/.settings
-**/.toolstarget
-**/.vs
-**/.vscode
-**/.next
-**/.cache
-**/*.*proj.user
-**/*.dbmdl
-**/*.jfm
-**/charts
-**/docker-compose*
-**/compose.y*ml
-**/target
-**/Dockerfile*
-**/node_modules
-**/npm-debug.log
-**/obj
-**/secrets.dev.yaml
-**/values.dev.yaml
-**/vendor
-LICENSE
-README.md
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-You should now have the following three files in your `spring-petclinic`
-directory.
-
-- [Dockerfile](/reference/dockerfile/)
-- [.dockerignore](/reference/dockerfile/#dockerignore-file)
-- [docker-compose.yaml](/reference/compose-file/_index.md)
-
-## Run the application
-
-Inside the `spring-petclinic` directory, run the following command in a
-terminal.
-
-```console
-$ docker compose up --build
-```
-
-The first time you build and run the app, Docker downloads dependencies and builds the app. It may take several minutes depending on your network connection.
-
-Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple app for a pet clinic.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-### Run the application in the background
-
-You can run the application detached from the terminal by adding the `-d`
-option. Inside the `spring-petclinic` directory, run the following command
-in a terminal.
-
-```console
-$ docker compose up --build -d
-```
-
-Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple app for a pet clinic.
-
-In the terminal, run the following command to stop the application.
-
-```console
-$ docker compose down
-```
-
-For more information about Compose commands, see the
-[Compose CLI reference](/reference/cli/docker/compose/_index.md).
-
-## Summary
-
-In this section, you learned how you can containerize and run a Java
-application using Docker.
-
-Related information:
-
-- [docker init reference](/reference/cli/docker/init/)
-
-## Next steps
-
-In the next section, you'll learn how you can develop your application using
-Docker containers.
diff --git a/content/guides/java/deploy.md b/content/guides/java/deploy.md
deleted file mode 100644
index 092998d20b8d..000000000000
--- a/content/guides/java/deploy.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-title: Test your Java deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, kubernetes, java
-description: Learn how to develop locally using Kubernetes
-aliases:
-  - /language/java/deploy/
-  - /guides/language/java/deploy/
----
-
-## Prerequisites
-
-- Complete all the previous sections of this guide, starting with [Containerize your app](containerize.md).
-- [Turn on Kubernetes](/manuals/desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your
-application to a fully-featured Kubernetes environment on your development
-machine. This lets you test and debug your workloads on Kubernetes locally
-before deploying.
-
-## Create a Kubernetes YAML file
-
-In your `spring-petclinic` directory, create a file named
-`docker-java-kubernetes.yaml`. Open the file in an IDE or text editor and add
-the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker
-username and the name of the repository that you created in [Configure CI/CD for
-your Java application](configure-ci-cd.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: docker-java-demo
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      service: server
-  template:
-    metadata:
-      labels:
-        service: server
-    spec:
-      containers:
-        - name: server-service
-          image: DOCKER_USERNAME/REPO_NAME
-          imagePullPolicy: Always
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: service-entrypoint
-  namespace: default
-spec:
-  type: NodePort
-  selector:
-    service: server
-  ports:
-    - port: 8080
-      targetPort: 8080
-      nodePort: 30001
-```
-
-In this Kubernetes YAML file, there are two objects, separated by the `---`:
-
-- A Deployment, describing a scalable group of identical pods. In this case,
-  you'll get just one replica, or copy of your pod. That pod, which is
-  described under `template`, has just one container in it. The
-  container is created from the image built by GitHub Actions in [Configure CI/CD for
-  your Java application](configure-ci-cd.md).
-- A NodePort service, which will route traffic from port 30001 on your host to
-  port 8080 inside the pods it routes to, allowing you to reach your app
-  from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to `spring-petclinic` and deploy your application to
-   Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-java-kubernetes.yaml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```shell
-   deployment.apps/docker-java-demo created
-   service/service-entrypoint created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```shell
-   NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
-   docker-java-demo     1/1     1            1           15s
-   ```
-
-   This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```shell
-   NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
-   kubernetes           ClusterIP   10.96.0.1       <none>        443/TCP          23h
-   service-entrypoint   NodePort    10.99.128.230   <none>        8080:30001/TCP   75s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP.
-
-3. In a terminal, curl the service. Note that a database wasn't deployed in
-   this example.
-
-   ```console
-   $ curl --request GET \
-     --url http://localhost:30001/actuator/health \
-     --header 'content-type: application/json'
-   ```
-
-   You should get output like the following.
-
-   ```console
-   {"status":"UP","groups":["liveness","readiness"]}
-   ```
-
-4. Run the following command to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-java-kubernetes.yaml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine.
-
-Related information:
-
-- [Kubernetes documentation](https://kubernetes.io/docs/home/)
-- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-- [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/java/develop.md b/content/guides/java/develop.md
deleted file mode 100644
index e3cee724fe9f..000000000000
--- a/content/guides/java/develop.md
+++ /dev/null
@@ -1,403 +0,0 @@
----
-title: Use containers for Java development
-linkTitle: Develop your app
-weight: 20
-keywords: Java, local, development, run,
-description: Learn how to develop your application locally.
-aliases:
-  - /language/java/develop/
-  - /guides/language/java/develop/
----
-
-## Prerequisites
-
-Work through the steps to containerize your application in [Containerize your app](containerize.md).
-
-## Overview
-
-In this section, you’ll walk through setting up a local development environment
-for the application you containerized in the previous section. This includes:
-
-- Adding a local database and persisting data
-- Creating a development container to connect a debugger
-- Configuring Compose to automatically update your running Compose services as
-  you edit and save your code
-
-## Add a local database and persist data
-
-You can use containers to set up local services, like a database. In this section, you'll update the `docker-compose.yaml` file to define a database service and a volume to persist data. Also, this particular application uses a system property to define the database type, so you'll need to update the `Dockerfile` to pass in the system property when starting the app.
-
-In the cloned repository's directory, open the `docker-compose.yaml` file in an IDE or text editor. Your Compose file has an example database service, but it'll require a few changes for your unique app.
-
-In the `docker-compose.yaml` file, you need to do the following:
-
-- Uncomment all of the database instructions. You'll now use a database service
-  instead of local storage for the data.
-- Remove the top-level `secrets` element as well as the element inside the `db`
-  service. This example uses the environment variable for the password rather than secrets.
-- Remove the `user` element from the `db` service. This example specifies the
-  user in the environment variable.
-- Update the database environment variables. These are defined by the Postgres
-  image. For more details, see the
-  [Postgres Official Docker Image](https://hub.docker.com/_/postgres).
-- Update the healthcheck test for the `db` service and specify the user. By
-  default, the healthcheck uses the root user instead of the `petclinic` user
-  you defined.
-- Add the database URL as an environment variable in the `server` service. This
-  overrides the default value defined in
-  `spring-petclinic/src/main/resources/application-postgres.properties`.
-
-The following is the updated `docker-compose.yaml` file. All comments have been removed.
-
-```yaml {hl_lines="7-29"}
-services:
-  server:
-    build:
-      context: .
-    ports:
-      - 8080:8080
-    depends_on:
-      db:
-        condition: service_healthy
-    environment:
-      - POSTGRES_URL=jdbc:postgresql://db:5432/petclinic
-  db:
-    image: postgres
-    restart: always
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=petclinic
-      - POSTGRES_USER=petclinic
-      - POSTGRES_PASSWORD=petclinic
-    ports:
-      - 5432:5432
-    healthcheck:
-      test: ["CMD", "pg_isready", "-U", "petclinic"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-```
-
-Open the `Dockerfile` in an IDE or text editor. In the `ENTRYPOINT` instruction,
-update the instruction to pass in the system property as specified in the
-`spring-petclinic/src/resources/db/postgres/petclinic_db_setup_postgres.txt`
-file.
-
-```diff
-- ENTRYPOINT [ "java", "org.springframework.boot.loader.launch.JarLauncher" ]
-+ ENTRYPOINT [ "java", "-Dspring.profiles.active=postgres", "org.springframework.boot.loader.launch.JarLauncher" ]
-```
-
-Save and close all the files.
-
-Now, run the following `docker compose up` command to start your application.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple app for a pet clinic. Browse around the application. Navigate to **Veterinarians** and verify that the application is connected to the database by being able to list veterinarians.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-## Dockerfile for development
-
-The Dockerfile you have now is great for a small, secure production image with
-only the components necessary to run the application. When developing, you may
-want a different image that has a different environment.
-
-For example, in the development image you may want to set up the image to start
-the application so that you can connect a debugger to the running Java process.
-
-Rather than managing multiple Dockerfiles, you can add a new stage. Your
-Dockerfile can then produce a final image which is ready for production as well
-as a development image.
-
-Replace the contents of your Dockerfile with the following.
-
-```dockerfile {hl_lines="22-29"}
-# syntax=docker/dockerfile:1
-
-FROM eclipse-temurin:21-jdk-jammy as deps
-WORKDIR /build
-COPY --chmod=0755 mvnw mvnw
-COPY .mvn/ .mvn/
-RUN --mount=type=bind,source=pom.xml,target=pom.xml \
-    --mount=type=cache,target=/root/.m2 ./mvnw dependency:go-offline -DskipTests
-
-FROM deps as package
-WORKDIR /build
-COPY ./src src/
-RUN --mount=type=bind,source=pom.xml,target=pom.xml \
-    --mount=type=cache,target=/root/.m2 \
-    ./mvnw package -DskipTests && \
-    mv target/$(./mvnw help:evaluate -Dexpression=project.artifactId -q -DforceStdout)-$(./mvnw help:evaluate -Dexpression=project.version -q -DforceStdout).jar target/app.jar
-
-FROM package as extract
-WORKDIR /build
-RUN java -Djarmode=layertools -jar target/app.jar extract --destination target/extracted
-
-FROM extract as development
-WORKDIR /build
-RUN cp -r /build/target/extracted/dependencies/. ./
-RUN cp -r /build/target/extracted/spring-boot-loader/. ./
-RUN cp -r /build/target/extracted/snapshot-dependencies/. ./
-RUN cp -r /build/target/extracted/application/. ./
-ENV JAVA_TOOL_OPTIONS -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000
-CMD [ "java", "-Dspring.profiles.active=postgres", "org.springframework.boot.loader.launch.JarLauncher" ]
-
-FROM eclipse-temurin:21-jre-jammy AS final
-ARG UID=10001
-RUN adduser \
-    --disabled-password \
-    --gecos "" \
-    --home "/nonexistent" \
-    --shell "/sbin/nologin" \
-    --no-create-home \
-    --uid "${UID}" \
-    appuser
-USER appuser
-COPY --from=extract build/target/extracted/dependencies/ ./
-COPY --from=extract build/target/extracted/spring-boot-loader/ ./
-COPY --from=extract build/target/extracted/snapshot-dependencies/ ./
-COPY --from=extract build/target/extracted/application/ ./
-EXPOSE 8080
-ENTRYPOINT [ "java", "-Dspring.profiles.active=postgres", "org.springframework.boot.loader.launch.JarLauncher" ]
-```
-
-Save and close the `Dockerfile`.
-
-In the `Dockerfile` you added a new stage labeled `development` based on the `extract` stage. In this stage, you copy the extracted files to a common directory, then run a command to start the application. In the command, you expose port 8000 and declare the debug configuration for the JVM so that you can attach a debugger.
-
-## Use Compose to develop locally
-
-The current Compose file doesn't start your development container. To do that, you must update your Compose file to target the development stage. Also, update the port mapping of the server service to provide access for the debugger.
-
-Open the `docker-compose.yaml` and add the following instructions into the file.
-
-```yaml {hl_lines=["5","8"]}
-services:
-  server:
-    build:
-      context: .
-      target: development
-    ports:
-      - 8080:8080
-      - 8000:8000
-    depends_on:
-      db:
-        condition: service_healthy
-    environment:
-      - POSTGRES_URL=jdbc:postgresql://db:5432/petclinic
-  db:
-    image: postgres
-    restart: always
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=petclinic
-      - POSTGRES_USER=petclinic
-      - POSTGRES_PASSWORD=petclinic
-    ports:
-      - 5432:5432
-    healthcheck:
-      test: ["CMD", "pg_isready", "-U", "petclinic"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-```
-
-Now, start your application and to confirm that it's running.
-
-```console
-$ docker compose up --build
-```
-
-Finally, test your API endpoint. Run the following curl command:
-
-```console
-$ curl  --request GET \
-  --url http://localhost:8080/vets \
-  --header 'content-type: application/json'
-```
-
-You should receive the following response:
-
-```json
-{
-  "vetList": [
-    {
-      "id": 1,
-      "firstName": "James",
-      "lastName": "Carter",
-      "specialties": [],
-      "nrOfSpecialties": 0,
-      "new": false
-    },
-    {
-      "id": 2,
-      "firstName": "Helen",
-      "lastName": "Leary",
-      "specialties": [{ "id": 1, "name": "radiology", "new": false }],
-      "nrOfSpecialties": 1,
-      "new": false
-    },
-    {
-      "id": 3,
-      "firstName": "Linda",
-      "lastName": "Douglas",
-      "specialties": [
-        { "id": 3, "name": "dentistry", "new": false },
-        { "id": 2, "name": "surgery", "new": false }
-      ],
-      "nrOfSpecialties": 2,
-      "new": false
-    },
-    {
-      "id": 4,
-      "firstName": "Rafael",
-      "lastName": "Ortega",
-      "specialties": [{ "id": 2, "name": "surgery", "new": false }],
-      "nrOfSpecialties": 1,
-      "new": false
-    },
-    {
-      "id": 5,
-      "firstName": "Henry",
-      "lastName": "Stevens",
-      "specialties": [{ "id": 1, "name": "radiology", "new": false }],
-      "nrOfSpecialties": 1,
-      "new": false
-    },
-    {
-      "id": 6,
-      "firstName": "Sharon",
-      "lastName": "Jenkins",
-      "specialties": [],
-      "nrOfSpecialties": 0,
-      "new": false
-    }
-  ]
-}
-```
-
-## Connect a Debugger
-
-You’ll use the debugger that comes with the IntelliJ IDEA. You can use the community version of this IDE. Open your project in IntelliJ IDEA, go to the **Run** menu, and then **Edit Configuration**. Add a new Remote JVM Debug configuration similar to the following:
-
-![Java Connect a Debugger](images/connect-debugger.webp)
-
-Set a breakpoint.
-
-Open `src/main/java/org/springframework/samples/petclinic/vet/VetController.java` and add a breakpoint inside the `showResourcesVetList` function.
-
-To start your debug session, select the **Run** menu and then **Debug _NameOfYourConfiguration_**.
-
-![Debug menu](images/debug-menu.webp?w=300)
-
-You should now see the connection in the logs of your Compose application.
-
-![Compose log file ](images/compose-logs.webp)
-
-You can now call the server endpoint.
-
-```console
-$ curl --request GET --url http://localhost:8080/vets
-```
-
-You should have seen the code break on the marked line and now you are able to use the debugger just like you would normally. You can also inspect and watch variables, set conditional breakpoints, view stack traces and a do bunch of other stuff.
-
-![Debugger code breakpoint](images/debugger-breakpoint.webp)
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Automatically update services
-
-Use Compose Watch to automatically update your running Compose services as you
-edit and save your code. For more details about Compose Watch, see
-[Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
-
-Open your `docker-compose.yaml` file in an IDE or text editor and then add the
-Compose Watch instructions. The following is the updated `docker-compose.yaml`
-file.
-
-```yaml {hl_lines="14-17"}
-services:
-  server:
-    build:
-      context: .
-      target: development
-    ports:
-      - 8080:8080
-      - 8000:8000
-    depends_on:
-      db:
-        condition: service_healthy
-    environment:
-      - POSTGRES_URL=jdbc:postgresql://db:5432/petclinic
-    develop:
-      watch:
-        - action: rebuild
-          path: .
-  db:
-    image: postgres
-    restart: always
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=petclinic
-      - POSTGRES_USER=petclinic
-      - POSTGRES_PASSWORD=petclinic
-    ports:
-      - 5432:5432
-    healthcheck:
-      test: ["CMD", "pg_isready", "-U", "petclinic"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-```
-
-Run the following command to run your application with Compose Watch.
-
-```console
-$ docker compose watch
-```
-
-Open a web browser and view the application at [http://localhost:8080](http://localhost:8080). You should see the Spring Pet Clinic home page.
-
-Any changes to the application's source files on your local machine will now be automatically reflected in the running container.
-
-Open `spring-petclinic/src/main/resources/templates/fragments/layout.html` in an IDE or text editor and update the `Home` navigation string by adding an exclamation mark.
-
-```diff
--   <li th:replace="~{::menuItem ('/','home','home page','home','Home')}">
-+   <li th:replace="~{::menuItem ('/','home','home page','home','Home!')}">
-
-```
-
-Save the changes to `layout.html` and then you can continue developing while the container automatically rebuilds.
-
-After the container is rebuilt and running, refresh [http://localhost:8080](http://localhost:8080) and then verify that **Home!** now appears in the menu.
-
-Press `ctrl+c` in the terminal to stop Compose Watch.
-
-## Summary
-
-In this section, you took a look at running a database locally and persisting the data. You also created a development image that contains the JDK and lets you attach a debugger. Finally, you set up your Compose file to expose the debugging port and configured Compose Watch to live reload your changes.
-
-Related information:
-
-- [Compose file reference](/reference/compose-file/)
-- [Compose Watch](/manuals/compose/how-tos/file-watch.md)
-- [Dockerfile reference](/reference/dockerfile/)
-
-## Next steps
-
-In the next section, you’ll take a look at how to run unit tests in Docker.
diff --git a/content/guides/java/run-tests.md b/content/guides/java/run-tests.md
deleted file mode 100644
index c88025ad82b6..000000000000
--- a/content/guides/java/run-tests.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-title: Run your Java tests
-linkTitle: Run your tests
-weight: 30
-keywords: Java, build, test
-description: How to build and run your Java tests
-aliases:
-  - /language/java/run-tests/
-  - /guides/language/java/run-tests/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a Java application](containerize.md).
-
-## Overview
-
-Testing is an essential part of modern software development. Testing can mean a lot of things to different development teams. There are unit tests, integration tests and end-to-end testing. In this guide you'll take a look at running your unit tests in Docker.
-
-### Multi-stage Dockerfile for testing
-
-In the following example, you'll pull the testing commands into your Dockerfile.
-Replace the contents of your Dockerfile with the following.
-
-```dockerfile {hl_lines="3-19"}
-# syntax=docker/dockerfile:1
-
-FROM eclipse-temurin:21-jdk-jammy as base
-WORKDIR /build
-COPY --chmod=0755 mvnw mvnw
-COPY .mvn/ .mvn/
-
-FROM base as test
-WORKDIR /build
-COPY ./src src/
-RUN --mount=type=bind,source=pom.xml,target=pom.xml \
-    --mount=type=cache,target=/root/.m2 \
-    ./mvnw test
-
-FROM base as deps
-WORKDIR /build
-RUN --mount=type=bind,source=pom.xml,target=pom.xml \
-    --mount=type=cache,target=/root/.m2 \
-    ./mvnw dependency:go-offline -DskipTests
-
-FROM deps as package
-WORKDIR /build
-COPY ./src src/
-RUN --mount=type=bind,source=pom.xml,target=pom.xml \
-    --mount=type=cache,target=/root/.m2 \
-    ./mvnw package -DskipTests && \
-    mv target/$(./mvnw help:evaluate -Dexpression=project.artifactId -q -DforceStdout)-$(./mvnw help:evaluate -Dexpression=project.version -q -DforceStdout).jar target/app.jar
-
-FROM package as extract
-WORKDIR /build
-RUN java -Djarmode=layertools -jar target/app.jar extract --destination target/extracted
-
-FROM extract as development
-WORKDIR /build
-RUN cp -r /build/target/extracted/dependencies/. ./
-RUN cp -r /build/target/extracted/spring-boot-loader/. ./
-RUN cp -r /build/target/extracted/snapshot-dependencies/. ./
-RUN cp -r /build/target/extracted/application/. ./
-ENV JAVA_TOOL_OPTIONS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000"
-CMD [ "java", "-Dspring.profiles.active=postgres", "org.springframework.boot.loader.launch.JarLauncher" ]
-
-FROM eclipse-temurin:21-jre-jammy AS final
-ARG UID=10001
-RUN adduser \
-    --disabled-password \
-    --gecos "" \
-    --home "/nonexistent" \
-    --shell "/sbin/nologin" \
-    --no-create-home \
-    --uid "${UID}" \
-    appuser
-USER appuser
-COPY --from=extract build/target/extracted/dependencies/ ./
-COPY --from=extract build/target/extracted/spring-boot-loader/ ./
-COPY --from=extract build/target/extracted/snapshot-dependencies/ ./
-COPY --from=extract build/target/extracted/application/ ./
-EXPOSE 8080
-ENTRYPOINT [ "java", "-Dspring.profiles.active=postgres", "org.springframework.boot.loader.launch.JarLauncher" ]
-```
-
-First, you added a new base stage. In the base stage, you added common instructions that both the test and deps stage will need.
-
-Next, you added a new test stage labeled `test` based on the base stage. In this
-stage you copied in the necessary source files and then specified `RUN` to run
-`./mvnw test`. Instead of using `CMD`, you used `RUN` to run the tests. The
-reason is that the `CMD` instruction runs when the container runs, and the `RUN`
-instruction runs when the image is being built. When using `RUN`, the build will
-fail if the tests fail.
-
-Finally, you updated the deps stage to be based on the base stage and removed
-the instructions that are now in the base stage.
-
-Run the following command to build a new image using the test stage as the target and view the test results. Include `--progress=plain` to view the build output, `--no-cache` to ensure the tests always run, and `--target test` to target the test stage.
-
-Now, build your image and run your tests. You'll run the `docker build` command and add the `--target test` flag so that you specifically run the test build stage.
-
-```console
-$ docker build -t java-docker-image-test --progress=plain --no-cache --target=test .
-```
-
-You should see output containing the following
-
-```console
-...
-
-#15 101.3 [WARNING] Tests run: 45, Failures: 0, Errors: 0, Skipped: 2
-#15 101.3 [INFO]
-#15 101.3 [INFO] ------------------------------------------------------------------------
-#15 101.3 [INFO] BUILD SUCCESS
-#15 101.3 [INFO] ------------------------------------------------------------------------
-#15 101.3 [INFO] Total time:  01:39 min
-#15 101.3 [INFO] Finished at: 2024-02-01T23:24:48Z
-#15 101.3 [INFO] ------------------------------------------------------------------------
-#15 DONE 101.4s
-```
-
-## Next steps
-
-In the next section, you’ll take a look at how to set up a CI/CD pipeline using
-GitHub Actions.
diff --git a/content/guides/jupyter.md b/content/guides/jupyter.md
index 9697b3556dbd..699f2186a6d2 100644
--- a/content/guides/jupyter.md
+++ b/content/guides/jupyter.md
@@ -5,11 +5,10 @@ title: Data science with JupyterLab
 toc_max: 2
 summary: |
   Use Docker to run Jupyter notebooks.
-tags: [data-science]
-languages: [python]
 aliases:
   - /guides/use-case/jupyter/
 params:
+  tags: [ai]
   time: 20 minutes
 ---
 
@@ -352,7 +351,7 @@ To share your image and data, you'll use [Docker Hub](https://hub.docker.com/).
 
 ### Share your image
 
-1. [Sign up](https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade) or sign in to [Docker Hub](https://hub.docker.com).
+1. [Sign up](https://www.docker.com/pricing?ref=Docs&refAction=DocsGuidesJupyter) or sign in to [Docker Hub](https://hub.docker.com).
 
 2. Rename your image so that Docker knows which repository to push it to. Open a
    terminal and run the following `docker tag` command. Replace `YOUR-USER-NAME`
diff --git a/content/guides/kafka.md b/content/guides/kafka.md
index 78153a04f7ed..17b3dee95e2e 100644
--- a/content/guides/kafka.md
+++ b/content/guides/kafka.md
@@ -5,11 +5,10 @@ title: Developing event-driven applications with Kafka and Docker
 linktitle: Event-driven apps with Kafka
 summary: |
   This guide explains how to run Apache Kafka in Docker containers.
-tags: [distributed-systems]
-languages: [js]
 aliases:
   - /guides/use-case/kafka/
 params:
+  tags: [deployment]
   time: 20 minutes
 ---
 
diff --git a/content/guides/kube-deploy.md b/content/guides/kube-deploy.md
deleted file mode 100644
index c4b535385365..000000000000
--- a/content/guides/kube-deploy.md
+++ /dev/null
@@ -1,142 +0,0 @@
----
-title: Deploy to Kubernetes
-keywords: kubernetes, pods, deployments, kubernetes services
-description: Learn how to describe and deploy a simple application on Kubernetes.
-aliases:
-  - /get-started/kube-deploy/
-  - /guides/deployment-orchestration/kube-deploy/
-summary: |
-  Learn how to deploy and orchestrate Docker containers using Kubernetes.
-tags: [deploy]
-params:
-  time: 10 minutes
----
-
-## Prerequisites
-
-- Download and install Docker Desktop as described in [Get Docker](/get-started/get-docker.md).
-- Work through containerizing an application in [Part 2](02_our_app.md).
-- Make sure that Kubernetes is turned on in Docker Desktop:
-  If Kubernetes isn't running, follow the instructions in [Orchestration](orchestration.md) to finish setting it up.
-
-## Introduction
-
-Now that you've demonstrated that the individual components of your application run as stand-alone containers, it's time to arrange for them to be managed by an orchestrator like Kubernetes. Kubernetes provides many tools for scaling, networking, securing and maintaining your containerized applications, above and beyond the abilities of containers themselves.
-
-In order to validate that your containerized application works well on Kubernetes, you'll use Docker Desktop's built in Kubernetes environment right on your development machine to deploy your application, before handing it off to run on a full Kubernetes cluster in production. The Kubernetes environment created by Docker Desktop is _fully featured_, meaning it has all the Kubernetes features your app will enjoy on a real cluster, accessible from the convenience of your development machine.
-
-## Describing apps using Kubernetes YAML
-
-All containers in Kubernetes are scheduled as pods, which are groups of co-located containers that share some resources. Furthermore, in a realistic application you almost never create individual pods. Instead, most of your workloads are scheduled as deployments, which are scalable groups of pods maintained automatically by Kubernetes. Lastly, all Kubernetes objects can and should be described in manifests called Kubernetes YAML files. These YAML files describe all the components and configurations of your Kubernetes app, and can be used to create and destroy your app in any Kubernetes environment.
-
-You already wrote a basic Kubernetes YAML file in the Orchestration overview part of this tutorial. Now, you can write a slightly more sophisticated YAML file to run and manage your Todo app, the container `getting-started` image created in [Part 2](02_our_app.md) of the Quickstart tutorial. Place the following in a file called `bb.yaml`:
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: bb-demo
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      bb: web
-  template:
-    metadata:
-      labels:
-        bb: web
-    spec:
-      containers:
-        - name: bb-site
-          image: getting-started
-          imagePullPolicy: Never
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: bb-entrypoint
-  namespace: default
-spec:
-  type: NodePort
-  selector:
-    bb: web
-  ports:
-    - port: 3000
-      targetPort: 3000
-      nodePort: 30001
-```
-
-In this Kubernetes YAML file, there are two objects, separated by the `---`:
-
-- A `Deployment`, describing a scalable group of identical pods. In this case, you'll get just one `replica`, or copy of your pod, and that pod (which is described under the `template:` key) has just one container in it, based off of your `getting-started` image from the previous step in this tutorial.
-- A `NodePort` service, which will route traffic from port 30001 on your host to port 3000 inside the pods it routes to, allowing you to reach your Todo app from the network.
-
-Also, notice that while Kubernetes YAML can appear long and complicated at first, it almost always follows the same pattern:
-
-- The `apiVersion`, which indicates the Kubernetes API that parses this object
-- The `kind` indicating what sort of object this is
-- Some `metadata` applying things like names to your objects
-- The `spec` specifying all the parameters and configurations of your object.
-
-## Deploy and check your application
-
-1. In a terminal, navigate to where you created `bb.yaml` and deploy your application to Kubernetes:
-
-   ```console
-   $ kubectl apply -f bb.yaml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully:
-
-   ```shell
-   deployment.apps/bb-demo created
-   service/bb-entrypoint created
-   ```
-
-2. Make sure everything worked by listing your deployments:
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   if all is well, your deployment should be listed as follows:
-
-   ```shell
-   NAME      READY   UP-TO-DATE   AVAILABLE   AGE
-   bb-demo   1/1     1            1           40s
-   ```
-
-   This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services:
-
-   ```console
-   $ kubectl get services
-
-   NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
-   bb-entrypoint   NodePort    10.106.145.116   <none>        3000:30001/TCP   53s
-   kubernetes      ClusterIP   10.96.0.1        <none>        443/TCP          138d
-   ```
-
-   In addition to the default `kubernetes` service, we see our `bb-entrypoint` service, accepting traffic on port 30001/TCP.
-
-3. Open a browser and visit your Todo app at `localhost:30001`. You should see your Todo application, the same as when you ran it as a stand-alone container in [Part 2](02_our_app.md) of the tutorial.
-
-4. Once satisfied, tear down your application:
-
-   ```console
-   $ kubectl delete -f bb.yaml
-   ```
-
-## Conclusion
-
-At this point, you have successfully used Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. You can now add other components to your app and taking advantage of all the features and power of Kubernetes, right on your own machine.
-
-In addition to deploying to Kubernetes, you have also described your application as a Kubernetes YAML file. This simple text file contains everything you need to create your application in a running state. You can check it in to version control and share it with your colleagues. This let you distribute your applications to other clusters (like the testing and production clusters that probably come after your development environments).
-
-## Kubernetes references
-
-Further documentation for all new Kubernetes objects used in this article are available here:
-
-- [Kubernetes Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/)
-- [Kubernetes Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
-- [Kubernetes Services](https://kubernetes.io/docs/concepts/services-networking/service/)
diff --git a/content/guides/lab-agentic-apps.md b/content/guides/lab-agentic-apps.md
new file mode 100644
index 000000000000..19bc988a8c51
--- /dev/null
+++ b/content/guides/lab-agentic-apps.md
@@ -0,0 +1,50 @@
+---
+title: "Lab: Building Agentic Apps with Docker"
+linkTitle: "Lab: Building Agentic Apps"
+description: |
+  Build agentic applications with Docker Model Runner, MCP Gateway, and Compose
+  in this hands-on interactive lab.
+summary: |
+  Hands-on lab: Build agentic apps with Docker Model Runner, MCP Gateway, and
+  Compose. Learn about models, tools, and agentic frameworks.
+keywords: AI, Docker, Model Runner, MCP Gateway, agentic apps, lab, labspace
+aliases:
+  - /labs/docker-for-ai/agentic-apps/
+params:
+  tags: [labs]
+  time: 20 minutes
+---
+
+Get up and running with building agentic applications using Compose, Docker
+Model Runner, and the Docker MCP Gateway. This hands-on lab takes you from
+understanding AI models to building complete agentic applications.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-agentic-apps-with-docker" model-download="true" >}}
+
+## What you'll learn
+
+This lab covers three core areas of agentic application development:
+
+**Models**: What models are, how to interact with them, configuring Docker
+Model Runner in Compose, and writing code that connects to the Model Runner
+
+**Tools**: Understanding tools and how they work, how MCP (Model Context
+Protocol) fits in, configuring the Docker MCP Gateway, and connecting to the
+MCP Gateway in code
+
+**Code**: What agentic frameworks are, defining models and tools in a Compose
+file, and configuring your app to use those models and tools
+
+## Modules
+
+| # | Module | Description |
+|---|--------|-------------|
+| 1 | Introduction | Overview of agentic applications and the Docker AI stack |
+| 2 | Understanding Model Interactions | Learn how to interact with AI models |
+| 3 | The Docker Model Runner | Configure and use Docker Model Runner with Compose |
+| 4 | Understanding Tools and MCP | Deep dive into tools, tool calling, and MCP |
+| 5 | The Docker MCP Gateway | Set up and configure the MCP Gateway |
+| 6 | Putting It All Together | Build a complete agentic application |
+| 7 | Conclusion | Summary and next steps |
diff --git a/content/guides/lab-ai-fundamentals.md b/content/guides/lab-ai-fundamentals.md
new file mode 100644
index 000000000000..5ee8718201ad
--- /dev/null
+++ b/content/guides/lab-ai-fundamentals.md
@@ -0,0 +1,45 @@
+---
+title: "Lab: AI Fundamentals for Developers"
+linkTitle: "Lab: AI Fundamentals"
+description: |
+  Learn the core concepts of AI development — models, prompt engineering, tool
+  calling, and RAG — through hands-on exercises in a live environment.
+summary: |
+  Hands-on lab: Learn the four core pillars of AI application development.
+  Work with the Chat Completions API, prompt engineering, tool calling, and RAG
+  through interactive exercises.
+keywords: AI, Docker, Model Runner, prompt engineering, RAG, tool calling, lab, labspace
+aliases:
+  - /labs/docker-for-ai/ai-fundamentals/
+params:
+  tags: [labs]
+  time: 45 minutes
+---
+
+Get hands-on with the four core pillars of AI application development: models,
+prompt engineering, tool calling, and RAG. This lab runs entirely on your
+machine using Docker Model Runner — no API key or cloud account required.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-ai-fundamentals" model-download="true" >}}
+
+## What you'll learn
+
+By the end of this Labspace, you will have completed the following:
+
+- Understand the Chat Completions API and how to structure messages for a model
+- Use prompt engineering techniques including system prompts, few-shot examples, and structured output
+- Implement tool calling and the agentic loop in code
+- Build a RAG pipeline that grounds model responses in your own data
+
+## Modules
+
+| #   | Module                               | Description                                                       |
+| --- | ------------------------------------ | ----------------------------------------------------------------- |
+| 1   | Welcome & Setup                      | Introduction to the lab and verifying your environment            |
+| 2   | Talking to Models                    | Chat Completions API, message roles, and stateless model behavior |
+| 3   | Prompt Engineering                   | System prompts, few-shot examples, and structured output          |
+| 4   | Tool Calling                         | Tool definitions, the agentic loop, and executing tools in code   |
+| 5   | Retrieval Augmented Generation (RAG) | Retrieve, augment, and generate with your own knowledge base      |
+| 6   | Wrap-up                              | Summary of concepts and next steps                                |
diff --git a/content/guides/lab-attestation-basics.md b/content/guides/lab-attestation-basics.md
new file mode 100644
index 000000000000..4153c114ac08
--- /dev/null
+++ b/content/guides/lab-attestation-basics.md
@@ -0,0 +1,47 @@
+---
+title: "Lab: Container Image Attestations"
+linkTitle: "Lab: Image attestations"
+description: |
+  Learn to attach SBOMs, build provenance, image signatures, and VEX
+  statements to container images for a verifiable software supply chain.
+summary: |
+  Hands-on lab: Add supply chain metadata to a container image. Generate
+  SBOMs and SLSA provenance with BuildKit, sign images with Cosign, and
+  attach OpenVEX statements to declare vulnerability exploitability status.
+keywords: Docker, supply chain, SBOM, provenance, SLSA, Cosign, VEX, attestations, security, lab, labspace
+params:
+  tags: [labs]
+  time: 45 minutes
+---
+
+Prove where your container images came from and that they haven't been
+tampered with. This lab walks through generating SBOMs and SLSA build
+provenance with BuildKit, signing images with Cosign, and writing VEX
+statements to declare which CVEs affect your image — the techniques used
+to meet supply chain security requirements like NIST SSDF and EO 14028.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-attestation-basics" >}}
+
+## What you'll learn
+
+By the end of this Labspace, you will have completed the following:
+
+- Generate and inspect an SPDX SBOM attached to a container image with `--sbom=true`
+- Generate SLSA build provenance with `--provenance=mode=max` and understand how multi-stage builds are fully recorded
+- Install Cosign and use key-based signing to sign and verify a container image
+- Write an OpenVEX statement to declare CVE exploitability status and attach it as a signed attestation
+- Understand how SBOMs, provenance, signatures, and VEX complement each other in a complete supply chain story
+
+## Modules
+
+| #   | Module                            | Description                                                                          |
+| --- | --------------------------------- | ------------------------------------------------------------------------------------ |
+| 1   | Introduction                      | Overview of supply chain attestations and the sample Go app                          |
+| 2   | Software Bill of Materials (SBOM) | Build with `--sbom=true`, inspect SPDX contents, and understand scanner integration  |
+| 3   | Build Provenance                  | Generate SLSA provenance and explore how multi-stage builds are recorded             |
+| 4   | Signing Images with Cosign        | Generate a key pair, sign the image, verify the signature, and learn keyless signing |
+| 5   | VEX Statements                    | Scan for CVEs, write an OpenVEX document, and attach it as a signed attestation      |
+| 6   | Bringing It All Together          | Run the complete build-sign-attest workflow and see the full supply chain picture    |
+| 7   | Recap                             | Summary of skills and next steps for policy enforcement and higher SLSA levels       |
diff --git a/content/guides/lab-building-images.md b/content/guides/lab-building-images.md
new file mode 100644
index 000000000000..424d5df7a274
--- /dev/null
+++ b/content/guides/lab-building-images.md
@@ -0,0 +1,47 @@
+---
+title: "Lab: Building Container Images"
+linkTitle: "Lab: Building Container Images"
+description: |
+  Learn to build production-grade container images using Dockerfile best
+  practices — layer caching, multi-stage builds, non-root users, base image
+  selection, and secure build-time secret handling.
+summary: |
+  Hands-on lab: Transform a basic Dockerfile into a production-ready image.
+  Master layer caching, multi-stage builds, .dockerignore, non-root users,
+  base image selection, and build secrets.
+keywords: Docker, Dockerfile, images, multi-stage builds, layer caching, build secrets, lab, labspace
+params:
+  tags: [labs]
+  time: 45 minutes
+---
+
+Take a working but naïve Dockerfile and progressively improve it into a
+production-grade image. Each section introduces one technique, applied to
+a real Python Flask app, so you can see the impact directly.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-building-images" >}}
+
+## What you'll learn
+
+By the end of this Labspace, you will have completed the following:
+
+- Read an image's layer history and understand the layer cleanup pitfall
+- Restructure a Dockerfile for fast, cache-efficient incremental builds
+- Write a `.dockerignore` file and run containers as a non-root user
+- Use multi-stage builds to run tests as a build gate and dramatically reduce image size
+- Choose the right base image for production, including Docker Hardened Images
+- Inject secrets safely at build time using `--mount=type=secret`
+
+## Modules
+
+| #   | Module                     | Description                                                            |
+| --- | -------------------------- | ---------------------------------------------------------------------- |
+| 1   | Welcome & Your First Build | Explore the sample app and build the initial image                     |
+| 2   | Understanding Image Layers | Inspect layers with `docker history` and see the layer cleanup pitfall |
+| 3   | Dockerfile Best Practices  | Fix cache ordering, add `.dockerignore`, and switch to a non-root user |
+| 4   | Multi-Stage Builds         | Run tests as a build gate and use a slim base for the production stage |
+| 5   | Choosing a Base Image      | Compare slim, Alpine, and Docker Hardened Images                       |
+| 6   | Build Secrets              | Show why `ARG` leaks secrets and use `--mount=type=secret` safely      |
+| 7   | Wrap-up                    | Review the complete best-practices checklist and next steps            |
diff --git a/content/guides/lab-compose-quickstart.md b/content/guides/lab-compose-quickstart.md
new file mode 100644
index 000000000000..97d821d91a0f
--- /dev/null
+++ b/content/guides/lab-compose-quickstart.md
@@ -0,0 +1,48 @@
+---
+title: "Lab: Docker Compose Quickstart"
+linkTitle: "Lab: Docker Compose Quickstart"
+description: |
+  Build a multi-container Flask and Redis application from scratch using Docker
+  Compose. Learn health checks, watch mode, named volumes, and multi-file
+  configurations.
+summary: |
+  Hands-on lab: Define and run a multi-container app with Docker Compose.
+  Progress from a bare compose.yaml through health checks, live development
+  with watch mode, data persistence, and modular Compose file composition.
+keywords: Docker, Compose, multi-container, Flask, Redis, watch mode, volumes, lab, labspace
+params:
+  tags: [labs]
+  time: 45 minutes
+---
+
+Build a Python Flask and Redis hit-counter app using Docker Compose, starting
+from a bare `compose.yaml` and progressively adding production-quality
+features at each step.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-compose-quickstart" >}}
+
+## What you'll learn
+
+By the end of this Labspace, you will have completed the following:
+
+- Define a multi-service application in a `compose.yaml` file and manage it with Compose commands
+- Control service startup order using health checks and `depends_on` conditions
+- Iterate on code without manual rebuilds using Compose watch mode
+- Persist data across container restarts with named volumes
+- Modularize a stack across multiple files using the `include` directive
+- Use `config`, `logs`, and `exec` to inspect and debug a running stack
+
+## Modules
+
+| #   | Module                           | Description                                                           |
+| --- | -------------------------------- | --------------------------------------------------------------------- |
+| 1   | Introduction                     | Tour the starter app and verify the environment                       |
+| 2   | Defining Services                | Write the first `compose.yaml` and bring up the Flask and Redis stack |
+| 3   | Health Checks & Startup Order    | Add a Redis healthcheck and `depends_on` to eliminate race conditions |
+| 4   | Live Development with Watch Mode | Configure watch mode to sync code changes without manual rebuilds     |
+| 5   | Persistence & Debugging          | Add a named volume so Redis data survives `docker compose down`       |
+| 6   | Using Multiple Compose Files     | Extract Redis into `infra.yaml` and compose files with `include`      |
+| 7   | Additional Commands              | Use `config`, `logs -f`, and `exec` to inspect the running stack      |
+| 8   | Recap                            | Review what was built and explore next steps                          |
diff --git a/content/guides/lab-container-getting-started.md b/content/guides/lab-container-getting-started.md
new file mode 100644
index 000000000000..3e8ad4ad83b9
--- /dev/null
+++ b/content/guides/lab-container-getting-started.md
@@ -0,0 +1,42 @@
+---
+title: "Lab: Getting Started with Docker"
+linkTitle: "Lab: Docker basics"
+description: |
+  Learn Docker fundamentals by running containers, exploring the container
+  lifecycle, and packaging a real Node.js app into your own custom image.
+summary: |
+  Hands-on lab: Run your first containers, write a Dockerfile, build a custom
+  image from a Node.js app, and optionally push it to Docker Hub.
+keywords: Docker, containers, Dockerfile, images, getting started, lab, labspace
+params:
+  tags: [labs]
+  time: 30 minutes
+---
+
+Start from zero and learn Docker's core building blocks. You'll run pre-built
+containers, write a `Dockerfile` to package a Node.js app, build your own
+image, and see container immutability and isolation in action.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-container-getting-started" >}}
+
+## What you'll learn
+
+By the end of this Labspace, you will have completed the following:
+
+- Understand what containers are and how they differ from virtual machines
+- Run containers in the background, inspect their logs and filesystem, and manage their lifecycle
+- Write a `Dockerfile` to package an application, using layer caching for fast rebuilds
+- Build a custom image with `docker build` and run it as a container
+- Optionally publish your image to Docker Hub
+
+## Modules
+
+| #   | Module                    | Description                                                                    |
+| --- | ------------------------- | ------------------------------------------------------------------------------ |
+| 1   | Welcome to Docker         | Introduction to containers and running your first `hello-world` container      |
+| 2   | Running Containers        | Launch Nginx, inspect logs and internals, and manage the container lifecycle   |
+| 3   | Building Your First Image | Write a `Dockerfile` and build a custom image from a Node.js app               |
+| 4   | Running Your App          | Run your image, explore container isolation, and optionally push to Docker Hub |
+| 5   | Wrap-up                   | Summary of key concepts and next steps                                         |
diff --git a/content/guides/lab-container-supported-development.md b/content/guides/lab-container-supported-development.md
new file mode 100644
index 000000000000..1915b40a888e
--- /dev/null
+++ b/content/guides/lab-container-supported-development.md
@@ -0,0 +1,45 @@
+---
+title: "Lab: Container-Supported Development"
+linkTitle: "Lab: Container-supported dev"
+description: |
+  Learn to use containers for local development by running a PostgreSQL
+  database, defining a Compose file, and adding a pgAdmin dev tool — no local
+  installations required.
+summary: |
+  Hands-on lab: Run dependent services in containers during local development.
+  Start a PostgreSQL database, write a compose.yaml, and add a database
+  visualizer — all without installing anything on the host.
+keywords: Docker, Compose, local development, PostgreSQL, pgAdmin, containers, lab, labspace
+params:
+  tags: [labs]
+  time: 30 minutes
+---
+
+Use containers to run the services your app depends on — databases, caches,
+message queues — without installing anything locally. This lab walks through
+running PostgreSQL in a container, writing a `compose.yaml` your whole team
+can share, and adding a pgAdmin visualizer to the dev stack.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-container-supported-development" >}}
+
+## What you'll learn
+
+By the end of this Labspace, you will have completed the following:
+
+- Run a PostgreSQL database in a container with no local installation
+- Use bind mounts to seed a database with schema and initial data at startup
+- Write a `compose.yaml` that codifies the entire dev stack for the team
+- Add a pgAdmin container to visualize and inspect the database
+- Understand how containerized dev stacks reduce onboarding time and environment drift
+
+## Modules
+
+| #   | Module                           | Description                                                                     |
+| --- | -------------------------------- | ------------------------------------------------------------------------------- |
+| 1   | Introduction                     | Meet the sample app and understand the container-supported development approach |
+| 2   | Running a Containerized Database | Start PostgreSQL, connect the app, and seed the database using bind mounts      |
+| 3   | Making Life Easier with Compose  | Replace `docker run` commands with a shared `compose.yaml`                      |
+| 4   | Adding Dev Tools                 | Add pgAdmin to the Compose stack for database visualization                     |
+| 5   | Recap                            | Review key takeaways and explore related guides                                 |
diff --git a/content/guides/lab-containerized-sdlc.md b/content/guides/lab-containerized-sdlc.md
new file mode 100644
index 000000000000..4acd08027520
--- /dev/null
+++ b/content/guides/lab-containerized-sdlc.md
@@ -0,0 +1,47 @@
+---
+title: "Lab: The Containerized SDLC"
+linkTitle: "Lab: The Containerized SDLC"
+description: |
+  Build a Node.js API and containerize every stage of the software development
+  lifecycle — local development, integration testing, CI/CD, and Kubernetes
+  deployment.
+summary: |
+  Hands-on lab: Take a Node.js app from source to live Kubernetes deployment
+  using Docker Compose, Testcontainers, Gitea Actions CI/CD, and kubectl —
+  with containers at every stage of the SDLC.
+keywords: Docker, Compose, Testcontainers, Kubernetes, CI/CD, SDLC, lab, labspace
+params:
+  tags: [labs]
+  time: 60 minutes
+---
+
+Build a real Node.js API, then apply containers at every stage of the software
+development lifecycle. You'll write a Compose file for local development,
+integration tests using Testcontainers, a CI/CD pipeline, and Kubernetes
+manifests — using the same container image throughout.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-containerized-sdlc" browserUrl="http://dockerlabs.xyz" >}}
+
+## What you'll learn
+
+By the end of this Labspace, you will have completed the following:
+
+- Set up a containerized local development environment with Docker Compose and Compose Watch
+- Write integration tests that spin up a real database using Testcontainers
+- Build a CI/CD pipeline that tests, builds, and pushes a container image automatically
+- Write Kubernetes manifests and deploy a live application to a k3s cluster
+- Configure the pipeline to cause an automatic deployment on every push to `main`
+
+## Modules
+
+| #   | Module                                    | Description                                                              |
+| --- | ----------------------------------------- | ------------------------------------------------------------------------ |
+| 1   | Introduction: Meet the App                | Tour the TaskFlow API and understand the SDLC journey ahead              |
+| 2   | Local Dev with Docker Compose             | Write a `compose.yaml` to provision a local database and visualizer      |
+| 3   | Containerizing Your Dev Environment       | Add the app to Compose with hot-reloading via Compose Watch              |
+| 4   | Integration Testing with Testcontainers   | Write self-contained tests that start a real PostgreSQL container        |
+| 5   | Continuous Integration with Gitea Actions | Build a pipeline that tests, builds, and pushes a container image        |
+| 6   | Deploying to Kubernetes                   | Write manifests and deploy to a live k3s cluster with automated rollouts |
+| 7   | The Containerized SDLC: A Recap           | Review the portability, consistency, and reproducibility gains           |
diff --git a/content/guides/lab-creating-ai-product-reviewer.md b/content/guides/lab-creating-ai-product-reviewer.md
new file mode 100644
index 000000000000..bb295c1119d0
--- /dev/null
+++ b/content/guides/lab-creating-ai-product-reviewer.md
@@ -0,0 +1,50 @@
+---
+title: "Lab: Building an AI Product Reviewer"
+linkTitle: "Lab: AI product reviewer"
+description: |
+  Build a complete AI-powered feedback analysis pipeline — sentiment analysis,
+  semantic clustering with embeddings, and response generation — all running
+  locally via Docker Model Runner. No API keys required.
+summary: |
+  Hands-on lab: Build an AI pipeline that classifies product reviews by
+  sentiment, clusters them by topic using embeddings, extracts actionable
+  features, and generates context-aware responses — all running locally.
+keywords: AI, Docker, Model Runner, sentiment analysis, embeddings, RAG, lab, labspace
+aliases:
+  - /labs/docker-for-ai/creating-ai-product-reviewer/
+params:
+  tags: [labs]
+  time: 60 minutes
+---
+
+Build a complete feedback analysis pipeline for a fictional AI product called
+Jarvis. You'll write Node.js code that runs local LLMs and embedding models via
+Docker Model Runner — no API keys, no cloud subscriptions, no data leaving your
+machine.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-creating-ai-product-reviewer" >}}
+
+## What you'll learn
+
+By the end of this Labspace, you will have completed the following:
+
+- Run LLMs locally via Docker Model Runner's OpenAI-compatible API
+- Connect a Node.js app to Docker Model Runner using the OpenAI SDK and the Compose `models:` integration
+- Perform sentiment analysis using low-temperature LLM classification
+- Use embeddings and cosine similarity to cluster semantically related feedback
+- Extract structured data from an LLM using `response_format: { type: 'json_object' }`
+- Generate context-aware responses to reviews informed by extracted product features
+
+## Modules
+
+| #   | Module                              | Description                                                                        |
+| --- | ----------------------------------- | ---------------------------------------------------------------------------------- |
+| 1   | Introduction                        | Overview of the pipeline and Docker Model Runner setup                             |
+| 2   | Project Setup & Docker Model Runner | Explore the starter project and wire up Compose model integration                  |
+| 3   | Generating Synthetic Feedback       | Use the LLM to generate realistic product reviews as test data                     |
+| 4   | Sentiment Analysis                  | Classify reviews as positive, negative, or neutral with low-temperature generation |
+| 5   | Embeddings & Semantic Clustering    | Group related reviews using vector embeddings and cosine similarity                |
+| 6   | Features & Responses                | Extract actionable features and generate context-aware review responses            |
+| 7   | Wrap-up                             | Summary of techniques and ideas for extending the pipeline                         |
diff --git a/content/guides/lab-dhi-node.md b/content/guides/lab-dhi-node.md
new file mode 100644
index 000000000000..9d1a1f51c274
--- /dev/null
+++ b/content/guides/lab-dhi-node.md
@@ -0,0 +1,45 @@
+---
+title: "Lab: Migrating a Node App to Docker Hardened Images"
+linkTitle: "Lab: Migrating to DHI (Node)"
+description: |
+  Migrate a Node.js application from a standard base image to Docker Hardened
+  Images. Use Docker Scout to analyze CVEs, compare images, and inspect
+  supply chain attestations.
+summary: |
+  Hands-on lab: Replace a Node.js base image with a Docker Hardened Image.
+  Analyze CVEs with Docker Scout, rewrite the Dockerfile to use multi-stage
+  builds with DHI, and explore SBOMs, VEX, and compliance attestations.
+keywords: Docker, Hardened Images, DHI, Node.js, Docker Scout, CVE, security, SBOM, lab, labspace
+params:
+  tags: [labs]
+  time: 30 minutes
+---
+
+Migrate a Node.js application from a standard `node:24-trixie-slim` base image
+to a Docker Hardened Image. You'll measure the before-and-after impact on CVE
+count, image size, and policy compliance using Docker Scout, then explore the
+supply chain attestations DHI ships with every image.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-dhi-node" >}}
+
+## What you'll learn
+
+By the end of this Labspace, you will have completed the following:
+
+- Analyze a Node.js container image with Docker Scout to identify CVE and policy failures
+- Rewrite a Dockerfile to use a multi-stage build with DHI dev and runtime variants
+- Compare image size and vulnerability counts before and after the migration
+- Inspect supply chain attestations included with Docker Hardened Images (SBOMs, SLSA, VEX)
+- Export VEX documents for integration with external scanners such as Grype or Trivy
+
+## Modules
+
+| #   | Module                                   | Description                                                                     |
+| --- | ---------------------------------------- | ------------------------------------------------------------------------------- |
+| 1   | Introduction                             | Overview of Docker Hardened Images and their security benefits                  |
+| 2   | Setup                                    | Perform setup tasks required for the lab.                                       |
+| 3   | Analyzing the Starting Image             | Build the app, scan it with Docker Scout, and review failing policies           |
+| 4   | Migrating to DHI                         | Rewrite the Dockerfile with multi-stage DHI build and compare results           |
+| 5   | DHI Attestations and Scanner Integration | Inspect SBOMs, FIPS attestations, STIG scans, and export VEX for external tools |
diff --git a/content/guides/lab-docker-agent.md b/content/guides/lab-docker-agent.md
new file mode 100644
index 000000000000..6e21c6111d66
--- /dev/null
+++ b/content/guides/lab-docker-agent.md
@@ -0,0 +1,47 @@
+---
+title: "Lab: Getting Started with Docker Agent"
+linkTitle: "Lab: Docker Agent"
+description: |
+  Build intelligent multi-agent teams with Docker Agent and Docker in this hands-on
+  interactive lab.
+summary: |
+  Hands-on lab: Create, share, and orchestrate intelligent AI agents using
+  Docker Agent, MCP Toolkit, and Docker.
+keywords: AI, Docker, docker agent, agents, multi-agent, MCP Toolkit, lab, labspace
+aliases:
+  - /labs/docker-for-ai/cagent/
+  - /guides/lab-cagent/
+params:
+  tags: [labs]
+  time: 20 minutes
+---
+
+This lab walks you through building intelligent agents with Docker Agent. You'll learn beginner
+agent concepts, then build sophisticated multi-agent teams that handle complex
+real-world tasks. Learn how to create, share, and orchestrate AI agents with
+Docker.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-cagent" >}}
+
+## What you'll learn
+
+- Create simple agents with Docker Agent
+- Use built-in generic agentic tools for common tasks
+- Integrate MCP servers from the MCP Toolkit
+- Share agents using the Docker Registry
+- Build multi-agent systems for complex workflows
+- Use Docker Model Runner with Docker Agent (preview)
+
+## Modules
+
+| # | Module | Description |
+|---|--------|-------------|
+| 1 | Introduction | Overview of Docker Agent and intelligent agent concepts |
+| 2 | Getting Started | Create your first agent with Docker Agent |
+| 3 | Using Built-in Tools | Leverage the generic agentic tools in Docker Agent |
+| 4 | Using MCP | Integrate MCP servers from the MCP Toolkit |
+| 5 | Sharing Agents | Package and share agents via Docker Registry |
+| 6 | Introduction to Sub-agents | Build multi-agent systems with sub-agent orchestration |
+| 7 | Conclusion | Summary and next steps |
diff --git a/content/guides/lab-mcp-gateway.md b/content/guides/lab-mcp-gateway.md
new file mode 100644
index 000000000000..4d2b97720702
--- /dev/null
+++ b/content/guides/lab-mcp-gateway.md
@@ -0,0 +1,45 @@
+---
+title: "Lab: Docker MCP Gateway"
+linkTitle: "Lab: Docker MCP Gateway"
+description: |
+  Run containerized MCP servers safely and securely with the Docker MCP Gateway
+  in this hands-on interactive lab.
+summary: |
+  Hands-on lab: Configure, secure, and connect MCP servers to your agentic
+  applications using the Docker MCP Gateway.
+keywords: AI, Docker, MCP, MCP Gateway, MCP servers, lab, labspace
+aliases:
+  - /labs/docker-for-ai/mcp-gateway/
+params:
+  tags: [labs]
+  time: 20 minutes
+---
+
+This lab provides a comprehensive, hands-on overview of the Docker MCP Gateway,
+which lets you run containerized MCP servers safely and securely. Learn
+how to configure, secure, and connect MCP servers to your agentic applications.
+
+## Launch the lab
+
+{{< labspace-launch image="dockersamples/labspace-mcp-gateway" >}}
+
+## What you'll learn
+
+- Learn about the Docker MCP Gateway and its architecture
+- Run the MCP Gateway with a simple MCP server
+- Inject secrets securely into MCP servers
+- Filter tools to reduce noise and save tokens
+- Connect the MCP Gateway to your application using popular agentic frameworks
+- Configure and use custom MCP servers
+
+## Modules
+
+| # | Module | Description |
+|---|--------|-------------|
+| 1 | Introduction | Overview of the MCP Gateway and why it matters |
+| 2 | Adding a Simple MCP Server | Get started with a basic MCP server configuration |
+| 3 | Adding a Complex MCP Server | Configure MCP servers with secrets and advanced options |
+| 4 | Filtering Available Tools | Reduce noise and save tokens by filtering tool availability |
+| 5 | Connecting MCP Gateway to Your App | Integrate the MCP Gateway with agentic frameworks |
+| 6 | Using a Custom MCP Server | Build and run your own custom MCP server |
+| 7 | Conclusion | Summary and next steps |
diff --git a/content/guides/language-translation.md b/content/guides/language-translation.md
index 751230ce4ade..5e569c2f8fa7 100644
--- a/content/guides/language-translation.md
+++ b/content/guides/language-translation.md
@@ -6,11 +6,10 @@ description: Learn how to build and run a language translation application using
 summary: |
   This guide demonstrates how to use Docker to deploy language translation
   models for NLP tasks.
-tags: [ai]
-languages: [python]
 aliases:
   - /guides/use-case/nlp/language-translation/
 params:
+  tags: [ai]
   time: 20 minutes
 ---
 
diff --git a/content/guides/laravel.md b/content/guides/laravel.md
new file mode 100644
index 000000000000..1361b0f46d2f
--- /dev/null
+++ b/content/guides/laravel.md
@@ -0,0 +1,863 @@
+---
+title: Develop and Deploy Laravel applications with Docker Compose
+linkTitle: Laravel
+summary: Learn how to efficiently set up Laravel development and production environments using Docker Compose.
+description: A guide on using Docker Compose to manage Laravel applications for development and production, covering container configurations and service management.
+keywords: laravel, php, docker compose, web framework, development, production
+aliases:
+  - /frameworks/laravel/
+  - /guides/frameworks/laravel/
+  - /guides/frameworks/laravel/common-questions/
+  - /guides/frameworks/laravel/development-setup/
+  - /guides/frameworks/laravel/prerequisites/
+  - /guides/frameworks/laravel/production-setup/
+params:
+  tags: [languages]
+  time: 30 minutes
+---
+
+
+Laravel is a popular PHP framework that allows developers to build web applications quickly and effectively. Docker Compose simplifies the management of development and production environments by defining essential services, like PHP, a web server, and a database, in a single YAML file. This guide provides a streamlined approach to setting up a robust Laravel environment using Docker Compose, focusing on simplicity and efficiency.
+
+> **Acknowledgment**
+>
+> Docker would like to thank [Sergei Shitikov](https://github.com/rw4lll) for
+> his contribution to this guide.
+
+The demonstrated examples can be found in [this GitHub repository](https://github.com/dockersamples/laravel-docker-examples). Docker Compose offers a straightforward approach to connecting multiple containers for Laravel, though similar setups can also be achieved using tools like Docker Swarm, Kubernetes, or individual Docker containers.
+
+This guide is intended for educational purposes, helping developers adapt and optimize configurations for their specific use cases. Additionally, there are existing tools that support Laravel in containers:
+
+- [Laravel Sail](https://laravel.com/docs/12.x/sail): An official package for easily starting Laravel in Docker.
+- [Laradock](https://github.com/laradock/laradock): A community project that helps run Laravel applications in Docker.
+
+## What you’ll learn
+
+- How to use Docker Compose to set up a Laravel development and production environment.
+- Defining services that make Laravel development easier, including PHP-FPM, Nginx, and database containers.
+- Best practices for managing Laravel environments using containerization.
+
+## Who’s this for?
+
+- Developers who work with Laravel and want to streamline environment management.
+- DevOps engineers seeking efficient ways to manage and deploy Laravel applications.
+
+## Prerequisites for Setting Up Laravel with Docker Compose
+
+Before you begin setting up Laravel with Docker Compose, make sure you meet the following prerequisites:
+
+### Docker and Docker Compose
+
+You need Docker and Docker Compose installed on your system. Docker allows you to containerize applications, and Docker Compose helps you manage multi-container applications.
+
+- Docker: Make sure Docker is installed and running on your machine. Refer to the [Docker installation guide](/get-docker/) to install Docker.
+- Docker Compose: Docker Compose is included with Docker Desktop, but you can also follow the [Docker Compose installation guide](/compose/install/) if needed.
+
+### Basic understanding of Docker and containers
+
+A fundamental understanding of Docker and how containers work will be helpful. If you're new to Docker, consider reviewing the [Docker Overview](/get-started/overview/) to familiarize yourself with containerization concepts.
+
+### Basic knowledge of Laravel
+
+This guide assumes you have a basic understanding of Laravel and PHP. Familiarity with Laravel’s command-line tools, such as [Artisan](https://laravel.com/docs/12.x/artisan), and its project structure is important for following the instructions.
+
+- Laravel CLI: You should be comfortable using Laravel’s command-line tool (`artisan`).
+- Laravel Project Structure: Familiarize yourself with Laravel’s folder structure (`app`, `config`, `routes`, `tests`, etc.).
+
+## Laravel Production Setup with Docker Compose
+
+This guide demonstrates how to set up a production-ready Laravel environment using Docker and Docker Compose. This configuration is designed for streamlined, scalable, and secure Laravel application deployments.
+
+> [!NOTE]
+> To experiment with a ready-to-run configuration, download the [Laravel Docker Examples](https://github.com/dockersamples/laravel-docker-examples) repository. It contains pre-configured setups for both development and production.
+
+### Project structure
+
+```plaintext
+my-laravel-app/
+├── app/
+├── bootstrap/
+├── config/
+├── database/
+├── public/
+├── docker/
+│   ├── common/
+│   │   └── php-fpm/
+│   │       ├── Dockerfile
+│   │       └── conf.d/
+│   │           └── 20-status-path.conf
+│   ├── development/
+│   ├── production/
+│   │   ├── php-fpm/
+│   │   │   └── entrypoint.sh
+│   │   └── nginx
+│   │       ├── Dockerfile
+│   │       └── nginx.conf
+├── compose.dev.yaml
+├── compose.prod.yaml
+├── .dockerignore
+├── .env
+├── vendor/
+├── ...
+```
+
+This layout represents a typical Laravel project, with Docker configurations stored in a unified `docker` directory. You’ll find **two** Compose files — `compose.dev.yaml` (for development) and `compose.prod.yaml` (for production) — to keep your environments separate and manageable.
+
+### Create a Dockerfile for PHP-FPM (production)
+
+For production, the `php-fpm` Dockerfile creates an optimized image with only the PHP extensions and libraries your application needs. As demonstrated in the [GitHub example](https://github.com/dockersamples/laravel-docker-examples), a single Dockerfile with multi-stage builds maintains consistency and reduces duplication between development and production. The following snippet shows only the production-related stages:
+
+```dockerfile
+# Stage 1: Build environment and Composer dependencies
+FROM php:8.5-fpm AS builder
+
+# Install system dependencies and PHP extensions for Laravel with MySQL/PostgreSQL support.
+# Dependencies in this stage are only required for building the final image.
+# Node.js and asset building are handled in the Nginx stage, not here.
+RUN apt-get update && apt-get install -y --no-install-recommends \
+    curl \
+    unzip \
+    libpq-dev \
+    libonig-dev \
+    libssl-dev \
+    libxml2-dev \
+    libcurl4-openssl-dev \
+    libicu-dev \
+    libzip-dev \
+    && docker-php-ext-install -j$(nproc) \
+    pdo_mysql \
+    pdo_pgsql \
+    pgsql \
+    intl \
+    zip \
+    bcmath \
+    soap \
+    && pecl install redis \
+    && docker-php-ext-enable redis \
+    && apt-get autoremove -y && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
+
+# Set the working directory inside the container
+WORKDIR /var/www
+
+# Copy the entire Laravel application code into the container
+# -----------------------------------------------------------
+# In Laravel, `composer install` may trigger scripts
+# needing access to application code.
+# For example, the `post-autoload-dump` event might execute
+# Artisan commands like `php artisan package:discover`. If the
+# application code (including the `artisan` file) is not
+# present, these commands will fail, leading to build errors.
+#
+# By copying the entire application code before running
+# `composer install`, we ensure that all necessary files are
+# available, allowing these scripts to run successfully.
+# In other cases, it would be possible to copy composer files
+# first, to leverage Docker's layer caching mechanism.
+# -----------------------------------------------------------
+COPY . /var/www
+
+# Install Composer and dependencies
+RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \
+    && composer install --no-dev --optimize-autoloader --no-interaction --no-progress --prefer-dist
+
+# Stage 2: Production environment
+FROM php:8.5-fpm AS production
+
+# Install only runtime libraries needed in production
+# libfcgi-bin and procps are required for the php-fpm-healthcheck script
+RUN apt-get update && apt-get install -y --no-install-recommends \
+    libpq-dev \
+    libicu-dev \
+    libzip-dev \
+    libfcgi-bin \
+    procps \
+    && apt-get autoremove -y && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
+
+# Download and install php-fpm health check script
+RUN curl -o /usr/local/bin/php-fpm-healthcheck \
+    https://raw.githubusercontent.com/renatomefi/php-fpm-healthcheck/master/php-fpm-healthcheck \
+    && chmod +x /usr/local/bin/php-fpm-healthcheck
+
+# Copy the initialization script
+COPY ./docker/php-fpm/entrypoint.sh /usr/local/bin/entrypoint.sh
+RUN chmod +x /usr/local/bin/entrypoint.sh
+
+# Copy the initial storage structure
+COPY ./storage /var/www/storage-init
+
+# Copy PHP extensions and libraries from the builder stage
+COPY --from=builder /usr/local/lib/php/extensions/ /usr/local/lib/php/extensions/
+COPY --from=builder /usr/local/etc/php/conf.d/ /usr/local/etc/php/conf.d/
+COPY --from=builder /usr/local/bin/docker-php-ext-* /usr/local/bin/
+
+# Use the recommended production PHP configuration
+# -----------------------------------------------------------
+# PHP provides development and production configurations.
+# Here, we replace the default php.ini with the production
+# version to apply settings optimized for performance and
+# security in a live environment.
+# -----------------------------------------------------------
+RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
+
+# Keep the image-provided FPM global config intact and add pool overrides separately
+COPY ./docker/common/php-fpm/conf.d/*.conf /usr/local/etc/php-fpm.d/
+# Update the variables_order to include E (for ENV)
+#RUN sed -i 's/variables_order = "GPCS"/variables_order = "EGPCS"/' "$PHP_INI_DIR/php.ini"
+
+# Copy the application code and dependencies from the build stage
+COPY --from=builder /var/www /var/www
+
+# Set working directory
+WORKDIR /var/www
+
+# Ensure correct permissions
+RUN chown -R www-data:www-data /var/www
+
+# Switch to the non-privileged user to run the application
+USER www-data
+
+# Change the default command to run the entrypoint script
+ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]
+
+# Expose port 9000 and start php-fpm server
+EXPOSE 9000
+CMD ["php-fpm"]
+```
+
+### Create a Dockerfile for PHP-CLI (production)
+
+For production, you often need a separate container to run Artisan commands, migrations, and other CLI tasks. In most cases you can run these commands by reusing existing PHP-FPM container:
+
+```console
+$ docker compose -f compose.prod.yaml exec php-fpm php artisan route:list
+```
+
+If you need a separate CLI container with different extensions or strict separation of concerns, consider a php-cli Dockerfile:
+
+```dockerfile
+# Stage 1: Build environment and Composer dependencies
+FROM php:8.5-cli AS builder
+
+# Install system dependencies and PHP extensions required for Laravel + MySQL/PostgreSQL support
+# Some dependencies are required for PHP extensions only in the build stage
+RUN apt-get update && apt-get install -y --no-install-recommends \
+    curl \
+    unzip \
+    libpq-dev \
+    libonig-dev \
+    libssl-dev \
+    libxml2-dev \
+    libcurl4-openssl-dev \
+    libicu-dev \
+    libzip-dev \
+    && docker-php-ext-install -j$(nproc) \
+    pdo_mysql \
+    pdo_pgsql \
+    pgsql \
+    intl \
+    zip \
+    bcmath \
+    soap \
+    && pecl install redis \
+    && docker-php-ext-enable redis \
+    && apt-get autoremove -y && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
+
+# Set the working directory inside the container
+WORKDIR /var/www
+
+# Copy the entire Laravel application code into the container
+COPY . /var/www
+
+# Install Composer and dependencies
+RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \
+    && composer install --no-dev --optimize-autoloader --no-interaction --no-progress --prefer-dist
+
+# Stage 2: Production environment
+FROM php:8.5-cli
+
+# Install client libraries required for php extensions in runtime
+RUN apt-get update && apt-get install -y --no-install-recommends \
+    libpq-dev \
+    libicu-dev \
+    libzip-dev \
+    && apt-get autoremove -y && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
+
+# Copy PHP extensions and libraries from the builder stage
+COPY --from=builder /usr/local/lib/php/extensions/ /usr/local/lib/php/extensions/
+COPY --from=builder /usr/local/etc/php/conf.d/ /usr/local/etc/php/conf.d/
+COPY --from=builder /usr/local/bin/docker-php-ext-* /usr/local/bin/
+
+# Use the default production configuration for PHP runtime arguments
+RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
+
+# Copy the application code and dependencies from the build stage
+COPY --from=builder /var/www /var/www
+
+# Set working directory
+WORKDIR /var/www
+
+# Ensure correct permissions
+RUN chown -R www-data:www-data /var/www
+
+# Switch to the non-privileged user to run the application
+USER www-data
+
+# Default command: Provide a bash shell to allow running any command
+CMD ["bash"]
+```
+
+This Dockerfile is similar to the PHP-FPM Dockerfile, but it uses the `php:8.5-cli` image as the base image and sets up the container for running CLI commands.
+
+### Create a Dockerfile for Nginx (production)
+
+Nginx serves as the web server for the Laravel application. You can include static assets directly to the container. Here's an example of possible Dockerfile for Nginx:
+
+```dockerfile
+# docker/nginx/Dockerfile
+# Stage 1: Build assets
+FROM debian AS builder
+
+# Install Node.js and build tools
+RUN apt-get update && apt-get install -y --no-install-recommends \
+    curl \
+    nodejs \
+    npm \
+    && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
+
+# Set working directory
+WORKDIR /var/www
+
+# Copy Laravel application code
+COPY . /var/www
+
+# Install Node.js dependencies and build assets
+RUN npm install && npm run build
+
+# Stage 2: Nginx production image
+FROM nginx:alpine
+
+# Copy custom Nginx configuration
+# -----------------------------------------------------------
+# Replace the default Nginx configuration with our custom one
+# that is optimized for serving a Laravel application.
+# -----------------------------------------------------------
+COPY ./docker/nginx/nginx.conf /etc/nginx/nginx.conf
+
+# Copy Laravel's public assets from the builder stage
+# -----------------------------------------------------------
+# We only need the 'public' directory from our Laravel app.
+# -----------------------------------------------------------
+COPY --from=builder /var/www/public /var/www/public
+
+# Set the working directory to the public folder
+WORKDIR /var/www/public
+
+# Expose port 80 and start Nginx
+EXPOSE 80
+CMD ["nginx", "-g", "daemon off;"]
+```
+
+This Dockerfile uses a multi-stage build to separate the asset building process from the final production image. The first stage installs Node.js and builds the assets, while the second stage sets up the Nginx production image with the optimized configuration and the built assets.
+
+### Create a Docker Compose configuration for production
+
+To bring all the services together, create a `compose.prod.yaml` file that defines the services, volumes, and networks for the production environment. Here's an example configuration:
+
+```yaml
+services:
+  web:
+    build:
+      context: .
+      dockerfile: ./docker/production/nginx/Dockerfile
+    restart: unless-stopped # Automatically restart unless the service is explicitly stopped
+    volumes:
+      # Mount the 'laravel-storage' volume to '/var/www/storage' inside the container.
+      # -----------------------------------------------------------
+      # This volume stores persistent data like uploaded files and cache.
+      # The ':ro' option mounts it as read-only in the 'web' service because Nginx only needs to read these files.
+      # The 'php-fpm' service mounts the same volume without ':ro' to allow write operations.
+      # -----------------------------------------------------------
+      - laravel-storage-production:/var/www/storage:ro
+    networks:
+      - laravel-production
+    ports:
+      # Map port 80 inside the container to the port specified by 'NGINX_PORT' on the host machine.
+      # -----------------------------------------------------------
+      # This allows external access to the Nginx web server running inside the container.
+      # For example, if 'NGINX_PORT' is set to '8080', accessing 'http://localhost:8080' will reach the application.
+      # -----------------------------------------------------------
+      - "${NGINX_PORT:-80}:80"
+    depends_on:
+      php-fpm:
+        condition: service_healthy # Wait for php-fpm health check
+
+  php-fpm:
+    # For the php-fpm service, we will create a custom image to install the necessary PHP extensions and setup proper permissions.
+    build:
+      context: .
+      dockerfile: ./docker/common/php-fpm/Dockerfile
+      target: production # Use the 'production' stage in the Dockerfile
+    restart: unless-stopped
+    volumes:
+      - laravel-storage-production:/var/www/storage # Mount the storage volume
+    env_file:
+      - .env
+    networks:
+      - laravel-production
+    healthcheck:
+      test: ["CMD-SHELL", "php-fpm-healthcheck || exit 1"]
+      interval: 10s
+      timeout: 5s
+      retries: 3
+    # The 'depends_on' attribute with 'condition: service_healthy' ensures that
+    # this service will not start until the 'postgres' service passes its health check.
+    # This prevents the application from trying to connect to the database before it's ready.
+    depends_on:
+      postgres:
+        condition: service_healthy
+
+  # The 'php-cli' service provides a command-line interface for running Artisan commands and other CLI tasks.
+  # -----------------------------------------------------------
+  # This is useful for running migrations, seeders, or any custom scripts.
+  # It shares the same codebase and environment as the 'php-fpm' service.
+  # -----------------------------------------------------------
+  php-cli:
+    build:
+      context: .
+      dockerfile: ./docker/php-cli/Dockerfile
+    tty: true # Enables an interactive terminal
+    stdin_open: true # Keeps standard input open for 'docker exec'
+    env_file:
+      - .env
+    networks:
+      - laravel-production
+
+  postgres:
+    image: postgres:18
+    restart: unless-stopped
+    user: postgres
+    ports:
+      - "${POSTGRES_PORT}:5432"
+    environment:
+      - POSTGRES_DB=${POSTGRES_DATABASE}
+      - POSTGRES_USER=${POSTGRES_USERNAME}
+      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
+    volumes:
+      - postgres-data-production:/var/lib/postgresql
+    networks:
+      - laravel-production
+    # Health check for PostgreSQL
+    # -----------------------------------------------------------
+    # Health checks allow Docker to determine if a service is operational.
+    # The 'pg_isready' command checks if PostgreSQL is ready to accept connections.
+    # This prevents dependent services from starting before the database is ready.
+    # -----------------------------------------------------------
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+
+  redis:
+    image: redis:alpine
+    restart: unless-stopped # Automatically restart unless the service is explicitly stopped
+    networks:
+      - laravel-production
+    # Health check for Redis
+    # -----------------------------------------------------------
+    # Checks if Redis is responding to the 'PING' command.
+    # This ensures that the service is not only running but also operational.
+    # -----------------------------------------------------------
+    healthcheck:
+      test: ["CMD", "redis-cli", "ping"]
+      interval: 10s
+      timeout: 5s
+      retries: 3
+
+networks:
+  # Attach the service to the 'laravel-production' network.
+  # -----------------------------------------------------------
+  # This custom network allows all services within it to communicate using their service names as hostnames.
+  # For example, 'php-fpm' can connect to 'postgres' by using 'postgres' as the hostname.
+  # -----------------------------------------------------------
+  laravel-production:
+
+volumes:
+  postgres-data-production:
+  laravel-storage-production:
+```
+
+> [!NOTE]
+> Ensure you have an `.env` file at the root of your Laravel project with the necessary configurations to match the Docker Compose setup.
+
+### Running your production environment
+
+To start the production environment, run:
+
+```console
+$ docker compose -f compose.prod.yaml up --build -d
+```
+
+This command will build and start all the services in detached mode, providing a scalable and production-ready setup for your Laravel application.
+
+### Summary
+
+By setting up a Docker Compose environment for Laravel in production, you ensure that your application is optimized for performance, scalable, and secure. This setup makes deployments consistent and easier to manage, reducing the likelihood of errors due to differences between environments.
+
+## Laravel Development Setup with Docker Compose
+
+This guide demonstrates how to configure a **development** environment for a Laravel application using Docker and Docker Compose. It builds **on top of** the production image for PHP-FPM and then adds developer-focused features—like Xdebug—to streamline debugging. By basing the development container on a known production image, you keep both environments closely aligned.
+
+This setup includes PHP-FPM, Nginx, and PostgreSQL services (although you can easily swap PostgreSQL for another database, like MySQL or MariaDB). Everything runs in containers, so you can develop in isolation without altering your host system.
+
+> [!NOTE]
+> To experiment with a ready-to-run configuration, download the [Laravel Docker Examples](https://github.com/dockersamples/laravel-docker-examples) repository. It contains pre-configured setups for both development and production.
+
+### Project structure
+
+```plaintext
+my-laravel-app/
+├── app/
+├── bootstrap/
+├── config/
+├── database/
+├── public/
+├── docker/
+│   ├── common/
+│   │   └── php-fpm/
+│   │       └── Dockerfile
+│   ├── development/
+│   │   ├── php-fpm/
+│   │   │   └── entrypoint.sh
+│   │   ├── workspace/
+│   │   │   └── Dockerfile
+│   │   └── nginx
+│   │       ├── Dockerfile
+│   │       └── nginx.conf
+│   └── production/
+├── compose.dev.yaml
+├── compose.prod.yaml
+├── .dockerignore
+├── .env
+├── vendor/
+├── ...
+```
+
+This layout represents a typical Laravel project, with Docker configurations stored in a unified `docker` directory. You’ll find **two** Compose files — `compose.dev.yaml` (for development) and `compose.prod.yaml` (for production) — to keep your environments separate and manageable.
+
+The environment includes a `workspace` service, a sidecar container for tasks like building front-end assets, running Artisan commands, and other CLI tools your project may require. While this extra container may seem unusual, it’s a familiar pattern in solutions like **Laravel Sail** and **Laradock**. It also includes **Xdebug** to aid in debugging.
+
+### Create a Dockerfile for PHP-FPM
+
+This Dockerfile **extends** the production image by installing Xdebug and adjusting user permissions to ease local development. That way, your development environment stays consistent with production while still offering extra debug features and improved file mounting.
+
+```dockerfile
+# Builds a dev-only layer on top of the production image
+FROM production AS development
+
+# Use ARGs to define environment variables passed from the Docker build command or Docker Compose.
+ARG XDEBUG_ENABLED=true
+ARG XDEBUG_MODE=develop,coverage,debug,profile
+ARG XDEBUG_HOST=host.docker.internal
+ARG XDEBUG_IDE_KEY=DOCKER
+ARG XDEBUG_LOG=/dev/stdout
+ARG XDEBUG_LOG_LEVEL=0
+
+USER root
+
+# Configure Xdebug if enabled
+RUN if [ "${XDEBUG_ENABLED}" = "true" ]; then \
+    pecl install xdebug && \
+    docker-php-ext-enable xdebug && \
+    echo "xdebug.mode=${XDEBUG_MODE}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
+    echo "xdebug.idekey=${XDEBUG_IDE_KEY}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
+    echo "xdebug.log=${XDEBUG_LOG}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
+    echo "xdebug.log_level=${XDEBUG_LOG_LEVEL}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
+    echo "xdebug.client_host=${XDEBUG_HOST}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini ; \
+    echo "xdebug.start_with_request=yes" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini ; \
+fi
+
+# Add ARGs for syncing permissions
+ARG UID=1000
+ARG GID=1000
+
+# Create a new user with the specified UID and GID, reusing an existing group if GID exists
+RUN if getent group ${GID}; then \
+      group_name=$(getent group ${GID} | cut -d: -f1); \
+      useradd -m -u ${UID} -g ${GID} -s /bin/bash www; \
+    else \
+      groupadd -g ${GID} www && \
+      useradd -m -u ${UID} -g www -s /bin/bash www; \
+      group_name=www; \
+    fi
+
+# Dynamically update php-fpm to use the new user and group
+RUN sed -i "s/user = www-data/user = www/g" /usr/local/etc/php-fpm.d/www.conf && \
+    sed -i "s/group = www-data/group = $group_name/g" /usr/local/etc/php-fpm.d/www.conf
+
+
+# Set the working directory
+WORKDIR /var/www
+
+# Copy the entrypoint script
+COPY ./docker/development/php-fpm/entrypoint.sh /usr/local/bin/entrypoint.sh
+RUN chmod +x /usr/local/bin/entrypoint.sh
+
+# Switch back to the non-privileged user to run the application
+USER www-data
+
+# Change the default command to run the entrypoint script
+ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]
+
+# Expose port 9000 and start php-fpm server
+EXPOSE 9000
+CMD ["php-fpm"]
+```
+
+### Create a Dockerfile for Workspace
+
+A workspace container provides a dedicated shell for asset compilation, Artisan/Composer commands, and other CLI tasks. This approach follows patterns from Laravel Sail and Laradock, consolidating all development tools into one container for convenience.
+
+```dockerfile
+# docker/development/workspace/Dockerfile
+# Use the official PHP CLI image as the base
+FROM php:8.5-cli
+
+# Set environment variables for user and group ID
+ARG UID=1000
+ARG GID=1000
+ARG NODE_VERSION=22.0.0
+
+# Install system dependencies and build libraries
+RUN apt-get update && apt-get install -y --no-install-recommends \
+    curl \
+    unzip \
+    libpq-dev \
+    libonig-dev \
+    libssl-dev \
+    libxml2-dev \
+    libcurl4-openssl-dev \
+    libicu-dev \
+    libzip-dev \
+    && docker-php-ext-install -j$(nproc) \
+    pdo_mysql \
+    pdo_pgsql \
+    pgsql \
+    intl \
+    zip \
+    bcmath \
+    soap \
+    && pecl install redis \
+    && docker-php-ext-enable redis \
+    && curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \
+    && apt-get autoremove -y && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
+
+# Use ARG to define environment variables passed from the Docker build command or Docker Compose.
+ARG XDEBUG_ENABLED
+ARG XDEBUG_MODE
+ARG XDEBUG_HOST
+ARG XDEBUG_IDE_KEY
+ARG XDEBUG_LOG
+ARG XDEBUG_LOG_LEVEL
+
+# Configure Xdebug if enabled
+RUN if [ "${XDEBUG_ENABLED}" = "true" ]; then \
+    pecl install xdebug && \
+    docker-php-ext-enable xdebug && \
+    echo "xdebug.mode=${XDEBUG_MODE}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
+    echo "xdebug.idekey=${XDEBUG_IDE_KEY}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
+    echo "xdebug.log=${XDEBUG_LOG}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
+    echo "xdebug.log_level=${XDEBUG_LOG_LEVEL}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
+    echo "xdebug.client_host=${XDEBUG_HOST}" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini ; \
+    echo "xdebug.start_with_request=yes" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini ; \
+fi
+
+# If the group already exists, use it; otherwise, create the 'www' group
+RUN if getent group ${GID}; then \
+      useradd -m -u ${UID} -g ${GID} -s /bin/bash www; \
+    else \
+      groupadd -g ${GID} www && \
+      useradd -m -u ${UID} -g www -s /bin/bash www; \
+    fi && \
+    usermod -aG sudo www && \
+    echo 'www ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
+
+# Switch to the non-root user to install NVM and Node.js
+USER www
+
+# Install NVM (Node Version Manager) as the www user
+RUN export NVM_DIR="$HOME/.nvm" && \
+    curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.0/install.sh | bash && \
+    [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" && \
+    nvm install ${NODE_VERSION} && \
+    nvm alias default ${NODE_VERSION} && \
+    nvm use default
+
+# Ensure NVM is available for all future shells
+RUN echo 'export NVM_DIR="$HOME/.nvm"' >> /home/www/.bashrc && \
+    echo '[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"' >> /home/www/.bashrc && \
+    echo '[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"' >> /home/www/.bashrc
+
+# Set the working directory
+WORKDIR /var/www
+
+# Override the entrypoint to avoid the default php entrypoint
+ENTRYPOINT []
+
+# Default command to keep the container running
+CMD ["bash"]
+```
+
+> [!NOTE]
+> If you prefer a **one-service-per-container** approach, simply omit the workspace container and run separate containers for each task. For example, you could use a dedicated `php-cli` container for your PHP scripts, and a `node` container to handle the asset building.
+
+### Create a Docker Compose configuration for development
+
+Here's the `compose.yaml` file to set up the development environment:
+
+```yaml
+services:
+  web:
+    image: nginx:latest # Using the default Nginx image with custom configuration.
+    volumes:
+      # Mount the application code for live updates
+      - ./:/var/www
+      # Mount the Nginx configuration file
+      - ./docker/development/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
+    ports:
+      # Map port 80 inside the container to the port specified by 'NGINX_PORT' on the host machine
+      - "80:80"
+    environment:
+      - NGINX_HOST=localhost
+    networks:
+      - laravel-development
+    depends_on:
+      php-fpm:
+        condition: service_started # Wait for php-fpm to start
+
+  php-fpm:
+    # For the php-fpm service, we will use our common PHP-FPM Dockerfile with the development target
+    build:
+      context: .
+      dockerfile: ./docker/common/php-fpm/Dockerfile
+      target: development
+      args:
+        UID: ${UID:-1000}
+        GID: ${GID:-1000}
+        XDEBUG_ENABLED: ${XDEBUG_ENABLED:-true}
+        XDEBUG_MODE: develop,coverage,debug,profile
+        XDEBUG_HOST: ${XDEBUG_HOST:-host.docker.internal}
+        XDEBUG_IDE_KEY: ${XDEBUG_IDE_KEY:-DOCKER}
+        XDEBUG_LOG: /dev/stdout
+        XDEBUG_LOG_LEVEL: 0
+    env_file:
+      # Load the environment variables from the Laravel application
+      - .env
+    user: "${UID:-1000}:${GID:-1000}"
+    volumes:
+      # Mount the application code for live updates
+      - ./:/var/www
+    networks:
+      - laravel-development
+    depends_on:
+      postgres:
+        condition: service_started # Wait for postgres to start
+
+  workspace:
+    # For the workspace service, we will also create a custom image to install and setup all the necessary stuff.
+    build:
+      context: .
+      dockerfile: ./docker/development/workspace/Dockerfile
+      args:
+        UID: ${UID:-1000}
+        GID: ${GID:-1000}
+        XDEBUG_ENABLED: ${XDEBUG_ENABLED:-true}
+        XDEBUG_MODE: develop,coverage,debug,profile
+        XDEBUG_HOST: ${XDEBUG_HOST:-host.docker.internal}
+        XDEBUG_IDE_KEY: ${XDEBUG_IDE_KEY:-DOCKER}
+        XDEBUG_LOG: /dev/stdout
+        XDEBUG_LOG_LEVEL: 0
+    tty: true # Enables an interactive terminal
+    stdin_open: true # Keeps standard input open for 'docker exec'
+    env_file:
+      - .env
+    volumes:
+      - ./:/var/www
+    networks:
+      - laravel-development
+
+  postgres:
+    image: postgres:18
+    ports:
+      - "${POSTGRES_PORT:-5432}:5432"
+    environment:
+      - POSTGRES_DB=app
+      - POSTGRES_USER=laravel
+      - POSTGRES_PASSWORD=secret
+    volumes:
+      - postgres-data-development:/var/lib/postgresql
+    networks:
+      - laravel-development
+
+  redis:
+    image: redis:alpine
+    networks:
+      - laravel-development
+
+networks:
+  laravel-development:
+
+volumes:
+  postgres-data-development:
+```
+
+> [!NOTE]
+> Ensure you have an `.env` file at the root of your Laravel project with the necessary configurations. You can use the `.env.example` file as a template.
+
+### Run your development environment
+
+To start the development environment, use:
+
+```console
+$ docker compose -f compose.dev.yaml up --build -d
+```
+
+Run this command to build and start the development environment in detached mode. When the containers finish initializing, visit [http://localhost/](http://localhost/) to see your Laravel app in action.
+
+### Summary
+
+By building on top of the production image and adding debug tools like Xdebug, you create a Laravel development workflow that closely mirrors production. The optional workspace container simplifies tasks like asset building and running Artisan commands. If you prefer a separate container for every service (e.g., a dedicated `php-cli` and `node` container), you can skip the workspace approach. Either way, Docker Compose provides an efficient, consistent way to develop your Laravel project.
+
+## Common Questions on Using Laravel with Docker
+
+<!-- vale Docker.HeadingLength = NO -->
+
+### 1. Why should I use Docker Compose for Laravel?
+
+Docker Compose is a powerful tool for managing multi-container environments, particularly in development due to its simplicity. With Docker Compose, you can define and connect all necessary services for Laravel, such as PHP, Nginx, and databases, in a single configuration (`compose.*.yaml`). This setup ensures consistency across development, testing, and production environments, streamlining onboarding and reducing discrepancies between local and server setups.
+
+While Docker Compose is a great choice for development, tools like **Docker Swarm** or **Kubernetes** offer advanced scaling and orchestration features, which may be beneficial for complex production deployments.
+
+### 2. How do I debug my Laravel application with Docker Compose?
+
+To debug your Laravel application in a Docker environment, use **Xdebug**. In the development setup, Xdebug is installed in the `php-fpm` container to enable debugging. Ensure Xdebug is enabled in your `compose.dev.yaml` file by setting the environment variable `XDEBUG_ENABLED=true` and configuring your IDE (e.g., Visual Studio Code or PHPStorm) to connect to the remote container for debugging.
+
+### 3. Can I use Docker Compose with databases other than PostgreSQL?
+
+Yes, Docker Compose supports various database services for Laravel. While PostgreSQL is used in the examples, you can easily substitute **MySQL**, **MariaDB**, or even **SQLite**. Update the `compose.*.yaml` file to specify the required Docker image and adjust your `.env` file to reflect the new database configuration.
+
+### 4. How can I persist data in development and production?
+
+In both development and production, Docker volumes are used to persist data. For instance, in the `compose.*.yaml` file, the `postgres-data-*` volume stores PostgreSQL data, ensuring that data is retained even if the container restarts. You can also define named volumes for other services where data persistence is essential.
+
+### 5. What is the difference between development and production Docker configurations?
+
+In a development environment, Docker configurations include tools that streamline coding and debugging, such as Xdebug for debugging, and volume mounts to enable real-time code updates without requiring image rebuilds.
+
+In production, the configuration is optimized for performance, security, and efficiency. This setup uses multi-stage builds to keep the image lightweight and includes only essential tools, packages, and libraries.
+
+It’s recommended to use `alpine`-based images in production for smaller image sizes, enhancing deployment speed and security.
+
+Additionally, consider using [Docker Scout](/manuals/scout/_index.md) to detect and analyze vulnerabilities, especially in production environments.
+
+For additional information about using Docker Compose in production, see [this guide](/compose/how-tos/production/).
diff --git a/content/guides/localstack.md b/content/guides/localstack.md
index 856225f3de19..15a55bd1c9a8 100644
--- a/content/guides/localstack.md
+++ b/content/guides/localstack.md
@@ -6,9 +6,8 @@ linktitle: AWS development with LocalStack
 summary: |
   This guide explains how to use Docker to run LocalStack, a local AWS cloud
   stack emulator.
-tags: [cloud-services]
-languages: [js]
 params:
+  tags: [databases]
   time: 20 minutes
 ---
 
@@ -66,17 +65,17 @@ Launch a quick demo of LocalStack by using the following steps:
 
    This Compose file also includes specifications for a required Mongo database. You can verify the services are up and running by visiting the Docker Desktop Dashboard.
 
-   ![Diagram showing the LocalStack and Mongo container up and running on Docker Desktop ](./images/launch-localstack.webp)
+   ![Diagram showing the LocalStack and Mongo container up and running on Docker Desktop](./images/launch-localstack.webp)
 
 3. Verify that LocalStack is up and running by selecting the container and checking the logs.
 
-   ![Diagram showing the logs of LocalStack container ](./images/localstack-logs.webp)
+   ![Diagram showing the logs of LocalStack container](./images/localstack-logs.webp)
 
 4. Creating a Local Amazon S3 Bucket
 
    When you create a local S3 bucket using LocalStack, you're essentially simulating the creation of an S3 bucket on AWS. This lets you to test and develop applications that interact with S3 without needing an actual AWS account.
 
-   To create Local Amazon S3 bucket, you’ll need to install an `awscli-local` package to be installed on your system. This package provides the awslocal command, which is a thin wrapper around the AWS command line interface for use with LocalStack.  It lets you to test and develop against a simulated environment on your local machine without needing to access the real AWS services. You can learn more about this utility [here](https://github.com/localstack/awscli-local).
+   To create Local Amazon S3 bucket, install the [`awscli-local` CLI](https://github.com/localstack/awscli-local) on your system. The `awslocal` command is a thin wrapper around the AWS command line interface for use with LocalStack. It lets you to test and develop against a simulated environment on your local machine without needing to access the real AWS services.
 
     ```console
     $ pip install awscli-local
@@ -92,7 +91,7 @@ Launch a quick demo of LocalStack by using the following steps:
 
     You can verify if the S3 bucket gets created or not by selecting the LocalStack container on the Docker Desktop Dashboard and viewing the logs. The logs indicates that your LocalStack environment is configured correctly and you can now use the `mysamplebucket` for storing and retrieving objects.
 
-    ![Diagram showing the logs of LocalStack that highlights the S3 bucket being created successfully ](./images/localstack-s3put.webp)
+    ![Diagram showing the logs of LocalStack that highlights the S3 bucket being created successfully](./images/localstack-s3put.webp)
 
 ## Using LocalStack in development
 
@@ -103,14 +102,14 @@ Now that you've familiarized yourself with LocalStack, it's time to see it in ac
 - MongoDB: A database to store all the to-do list data
 - LocalStack: Emulates the Amazon S3 service and stores and retrieve images.
 
-![Diagram showing the tech stack of the sample todo-list application that includes LocalStack, frontend and backend services ](images/localstack-arch.webp)
+![Diagram showing the tech stack of the sample todo-list application that includes LocalStack, frontend and backend services](images/localstack-arch.webp)
 
 
 ## Connecting to LocalStack from a non-containerized app
 
 Now it’s time to connect your app to LocalStack. The `index.js` file, located in the backend/ directory, serves as the main entry point for the backend application.
 
-The code interacts with LocalStack’s S3 service, which is accessed via the endpoint defined by the `S3_ENDPOINT_URL` environment variable, typically set to `http://localhost:4556` for local development.
+The code interacts with LocalStack’s S3 service, which is accessed via the endpoint defined by the `S3_ENDPOINT_URL` environment variable, typically set to `http://localhost:4566` for local development.
 
 The `S3Client` from the AWS SDK is configured to use this LocalStack endpoint, along with test credentials (`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`) that are also sourced from environment variables. This setup lets the application to perform operations on the locally simulated S3 service as if it were interacting with the real AWS S3, making the code flexible for different environments.
 
@@ -264,7 +263,7 @@ Now that you have learnt how to connect a non-containerized Node.js application
          - SERVICES=s3
          - GATEWAY_LISTEN=0.0.0.0:4566
        volumes:
-         - ./localstack:/docker-entrypoint-initaws.d"
+         - ./localstack:/etc/localstack/init/ready.d
 
    volumes:
      mongodbdata:
@@ -308,6 +307,15 @@ Now that you have learnt how to connect a non-containerized Node.js application
 
    The command creates an S3 bucket named `mysamplebucket`.
 
+   > [!TIP]
+   >
+   > You can automate this step by placing a shell script (for example,
+   > `init.sh`) under the local `./localstack` directory. Make sure the
+   > script is executable (`chmod +x ./localstack/init.sh`). LocalStack
+   > runs files mounted in `/etc/localstack/init/ready.d` once it is ready.
+   > See [LocalStack init hooks](https://docs.localstack.cloud/references/init-hooks/)
+   > for more details.
+
    Open [http://localhost:5173](http://localhost:5173) to access the complete to-do list application and start uploading images to the Amazon S3 bucket. 
 
    > [!TIP]
diff --git a/content/guides/named-entity-recognition.md b/content/guides/named-entity-recognition.md
index 82b4149a9e88..b2cc582597c6 100644
--- a/content/guides/named-entity-recognition.md
+++ b/content/guides/named-entity-recognition.md
@@ -6,11 +6,10 @@ description: Learn how to build and run a named entity recognition application u
 summary: |
   This guide explains how to containerize named entity recognition (NER) models
   using Docker.
-tags: [ai]
-languages: [python]
 aliases:
   - /guides/use-case/nlp/named-entity-recognition/
 params:
+  tags: [ai]
   time: 20 minutes
 ---
 
diff --git a/content/guides/nextjs.md b/content/guides/nextjs.md
new file mode 100644
index 000000000000..790b36744965
--- /dev/null
+++ b/content/guides/nextjs.md
@@ -0,0 +1,1408 @@
+---
+title: Containerize a Next.js application
+linkTitle: Next.js
+description: Containerize, develop, and test Next.js apps with Docker
+keywords: getting started, Next.js, next.js, docker, language, Dockerfile
+summary: |
+  This guide explains how to containerize Next.js applications and set up
+  development and testing in containers.
+aliases:
+  - /guides/nextjs/configure-github-actions/
+  - /guides/nextjs/containerize/
+  - /guides/nextjs/deploy/
+  - /guides/nextjs/develop/
+  - /guides/nextjs/run-tests/
+params:
+  tags: [languages]
+  time: 20 minutes
+---
+
+This guide shows you how to containerize a Next.js application using Docker, following best practices for creating efficient, production-ready containers.
+
+[Next.js](https://nextjs.org/) is a React framework that enables server-side
+rendering, static site generation, and full-stack capabilities. Docker
+provides a consistent containerized environment from development to
+production.
+
+> **Acknowledgment**
+>
+> Docker extends its sincere gratitude to [Kristiyan Velkov](https://www.linkedin.com/in/kristiyan-velkov-763130b3/) for authoring this guide and contributing the official [Next.js Docker examples](https://github.com/vercel/next.js/tree/canary/examples/with-docker) to the Vercel Next.js repository, including the standalone and export output examples. As a Docker Captain and experienced engineer, his expertise in Docker, DevOps, and modern web development has made this resource invaluable for the community, helping developers navigate and optimize their Docker workflows.
+
+---
+
+## What will you learn?
+
+In this guide, you will learn how to:
+
+- Containerize and run a Next.js application using Docker.
+- Set up a local development environment for Next.js inside a container.
+- Run tests for your Next.js application within a Docker container.
+
+To begin, you'll start by containerizing an existing Next.js application.
+
+---
+
+## Prerequisites
+
+Before you begin, make sure you're familiar with the following:
+
+- Basic understanding of [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript) or [TypeScript](https://www.typescriptlang.org/).
+- Basic knowledge of [Node.js](https://nodejs.org/en) and [npm](https://docs.npmjs.com/about-npm) for managing dependencies and running scripts.
+- Familiarity with [React](https://react.dev/) and [Next.js](https://nextjs.org/) fundamentals.
+- Understanding of Docker concepts such as images, containers, and Dockerfiles. If you're new to Docker, start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
+
+Once you've completed the Next.js getting started modules, you'll be ready to containerize your own Next.js application using the examples and instructions provided in this guide.
+
+## Containerize a Next.js Application
+
+### Prerequisites
+
+Before you begin, make sure the following tools are installed and available on your system:
+
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
+- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
+
+> [!NOTE]
+> New to Docker? Start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide to get familiar with key concepts like images, containers, and Dockerfiles.
+
+---
+
+### Overview
+
+This guide walks you through containerizing a Next.js application with Docker.
+You'll learn how to create a production-ready Docker image using best
+practices that improve performance, security, scalability, and deployment
+efficiency.
+
+By the end of this guide, you will:
+
+- Containerize a Next.js application using Docker.
+- Create and optimize a Dockerfile for production builds.
+- Use multi-stage builds to minimize image size.
+- Leverage Next.js standalone or export output for efficient containerization.
+- Follow best practices for building secure and maintainable Docker images.
+
+---
+
+### Get the sample application
+
+Clone the sample application to use with this guide. Open a terminal, change
+directory to a directory that you want to work in, and run the following command
+to clone the git repository:
+
+```console
+$ git clone https://github.com/kristiyan-velkov/docker-nextjs-sample
+```
+
+---
+
+### Build the Docker image
+
+Next.js has specific requirements for production deployments. This guide shows two approaches: `standalone` output (Node.js server) and `export` output (static files with Nginx).
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for your project. Ask Gordon to create a Dockerfile, Compose file, and `.dockerignore` tailored to your application.
+
+#### Step 1: Configure Next.js and create the Dockerfile
+
+Before creating a Dockerfile, choose a base image: the [Node.js Official Image](https://hub.docker.com/_/node) or a [Docker Hardened Image (DHI)](https://hub.docker.com/hardened-images/catalog) from the Hardened Image catalog. Choosing DHI gives you a production-ready, lightweight, and secure image. For more information, see [Docker Hardened Images](https://docs.docker.com/dhi/).
+
+> [!IMPORTANT]
+> This guide uses stable Node.js LTS image tags that are considered secure when the guide is written. Because new releases and security patches are published regularly, always review the [official Node.js Docker images](https://hub.docker.com/_/node) and select a secure, up-to-date version before building or deploying.
+
+---
+
+##### 1.1 Next.js with standalone output
+
+Standalone output (`output: "standalone"`) makes Next.js build a self-contained output that includes only the files and dependencies needed to run the application. A single `node server.js` can serve the app, which is ideal for Docker and supports server-side rendering, API routes, and incremental static regeneration. For details, see the [Next.js output configuration documentation](https://nextjs.org/docs/app/api-reference/config/next-config-js/output) (including the "standalone" option).
+
+The container runs the Next.js server with Node.js on port 3000.
+
+Configure Next.js — Open or create `next.config.ts` in your project root:
+
+```ts
+import type { NextConfig } from "next";
+
+const nextConfig: NextConfig = {
+  output: "standalone",
+};
+
+export default nextConfig;
+```
+
+Choose either a Docker Hardened Image or the Docker Official Image, then create a `Dockerfile` using the content from the selected tab below.
+
+{{< tabs >}}
+{{< tab name="Using Docker Hardened Images" >}}
+
+Docker Hardened Images (DHIs) are available for Node.js in the [Docker Hardened Images catalog](https://hub.docker.com/hardened-images/catalog/dhi/node). For more information, see the [DHI quickstart](/dhi/get-started/) guide.
+
+1. Sign in to the DHI registry:
+
+   ```console
+   $ docker login dhi.io
+   ```
+
+2. Pull the Node.js DHI (check the catalog for available versions):
+
+   ```console
+   $ docker pull dhi.io/node:24-alpine3.22-dev
+   ```
+
+3. Create a file named `Dockerfile` with the following contents. The `FROM` instructions use `dhi.io/node:24-alpine3.22-dev`. Check the [Docker Hardened Images catalog](https://hub.docker.com/hardened-images/catalog) for the latest versions and update the image tags as needed for security and compatibility.
+
+   ```dockerfile
+   # ============================================
+   # Stage 1: Dependencies Installation Stage
+   # ============================================
+
+   # IMPORTANT: Docker Hardened Image (DHI) Version Maintenance
+   # This Dockerfile uses dhi.io/node. Regularly validate and update to the latest DHI versions in the catalog for security and compatibility.
+
+   FROM dhi.io/node:24-alpine3.22-dev AS dependencies
+
+   # Set working directory
+   WORKDIR /app
+
+   # Copy package-related files first to leverage Docker's caching mechanism
+   COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* .npmrc* ./
+
+   # Install project dependencies with frozen lockfile for reproducible builds
+   RUN --mount=type=cache,target=/root/.npm \
+       --mount=type=cache,target=/usr/local/share/.cache/yarn \
+       --mount=type=cache,target=/root/.local/share/pnpm/store \
+     if [ -f package-lock.json ]; then \
+       npm ci --no-audit --no-fund; \
+     elif [ -f yarn.lock ]; then \
+       corepack enable yarn && yarn install --frozen-lockfile --production=false; \
+     elif [ -f pnpm-lock.yaml ]; then \
+       corepack enable pnpm && pnpm install --frozen-lockfile; \
+     else \
+       echo "No lockfile found." && exit 1; \
+     fi
+
+   # ============================================
+   # Stage 2: Build Next.js application in standalone mode
+   # ============================================
+
+   FROM dhi.io/node:24-alpine3.22-dev AS builder
+
+   # Set working directory
+   WORKDIR /app
+
+   # Copy project dependencies from dependencies stage
+   COPY --from=dependencies /app/node_modules ./node_modules
+
+   # Copy application source code
+   COPY . .
+
+   ENV NODE_ENV=production
+
+   # Next.js collects completely anonymous telemetry data about general usage.
+   # Learn more here: https://nextjs.org/telemetry
+   # Uncomment the following line in case you want to disable telemetry during the build.
+   # ENV NEXT_TELEMETRY_DISABLED=1
+
+   # Build Next.js application
+   # If you want to speed up Docker rebuilds, you can cache the build artifacts
+   # by adding: --mount=type=cache,target=/app/.next/cache
+   # This caches the .next/cache directory across builds, but it also prevents
+   # .next/cache/fetch-cache from being included in the final image, meaning
+   # cached fetch responses from the build won't be available at runtime.
+   RUN if [ -f package-lock.json ]; then \
+       npm run build; \
+     elif [ -f yarn.lock ]; then \
+       corepack enable yarn && yarn build; \
+     elif [ -f pnpm-lock.yaml ]; then \
+       corepack enable pnpm && pnpm build; \
+     else \
+       echo "No lockfile found." && exit 1; \
+     fi
+
+   # ============================================
+   # Stage 3: Run Next.js application
+   # ============================================
+
+   FROM dhi.io/node:24-alpine3.22-dev AS runner
+
+   # Set working directory
+   WORKDIR /app
+
+   # Set production environment variables
+   ENV NODE_ENV=production
+   ENV PORT=3000
+   ENV HOSTNAME="0.0.0.0"
+
+   # Next.js collects completely anonymous telemetry data about general usage.
+   # Learn more here: https://nextjs.org/telemetry
+   # Uncomment the following line in case you want to disable telemetry during the run time.
+   # ENV NEXT_TELEMETRY_DISABLED=1
+
+   # Copy production assets
+   COPY --from=builder --chown=node:node /app/public ./public
+
+   # Set the correct permission for prerender cache
+   RUN mkdir .next
+   RUN chown node:node .next
+
+   # Automatically leverage output traces to reduce image size
+   # https://nextjs.org/docs/advanced-features/output-file-tracing
+   COPY --from=builder --chown=node:node /app/.next/standalone ./
+   COPY --from=builder --chown=node:node /app/.next/static ./.next/static
+
+   # If you want to persist the fetch cache generated during the build so that
+   # cached responses are available immediately on startup, uncomment this line:
+   # COPY --from=builder --chown=node:node /app/.next/cache ./.next/cache
+
+   # Switch to non-root user for security best practices
+   USER node
+
+   # Expose port 3000 to allow HTTP traffic
+   EXPOSE 3000
+
+   # Start Next.js standalone server
+   CMD ["node", "server.js"]
+   ```
+
+{{< /tab >}}
+{{< tab name="Using the Docker Official Image" >}}
+
+Create a file named `Dockerfile` with the following contents (uses `node`):
+
+```dockerfile
+  # ============================================
+  # Stage 1: Dependencies Installation Stage
+  # ============================================
+
+  ARG NODE_VERSION=24.14.0-slim
+
+  FROM node:${NODE_VERSION} AS dependencies
+
+  # Set working directory
+  WORKDIR /app
+
+  # Copy package-related files first to leverage Docker's caching mechanism
+  COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* .npmrc* ./
+
+  # Install project dependencies with frozen lockfile for reproducible builds
+  RUN --mount=type=cache,target=/root/.npm \
+      --mount=type=cache,target=/usr/local/share/.cache/yarn \
+      --mount=type=cache,target=/root/.local/share/pnpm/store \
+    if [ -f package-lock.json ]; then \
+      npm ci --no-audit --no-fund; \
+    elif [ -f yarn.lock ]; then \
+      corepack enable yarn && yarn install --frozen-lockfile --production=false; \
+    elif [ -f pnpm-lock.yaml ]; then \
+      corepack enable pnpm && pnpm install --frozen-lockfile; \
+    else \
+      echo "No lockfile found." && exit 1; \
+    fi
+
+  # ============================================
+  # Stage 2: Build Next.js application in standalone mode
+  # ============================================
+
+  FROM node:${NODE_VERSION} AS builder
+
+  # Set working directory
+  WORKDIR /app
+
+  # Copy project dependencies from dependencies stage
+  COPY --from=dependencies /app/node_modules ./node_modules
+
+  # Copy application source code
+  COPY . .
+
+  ENV NODE_ENV=production
+
+  # Next.js collects completely anonymous telemetry data about general usage.
+  # Learn more here: https://nextjs.org/telemetry
+  # Uncomment the following line in case you want to disable telemetry during the build.
+  # ENV NEXT_TELEMETRY_DISABLED=1
+
+  # Build Next.js application
+  # If you want to speed up Docker rebuilds, you can cache the build artifacts
+  # by adding: --mount=type=cache,target=/app/.next/cache
+  # This caches the .next/cache directory across builds, but it also prevents
+  # .next/cache/fetch-cache from being included in the final image, meaning
+  # cached fetch responses from the build won't be available at runtime.
+  RUN if [ -f package-lock.json ]; then \
+      npm run build; \
+    elif [ -f yarn.lock ]; then \
+      corepack enable yarn && yarn build; \
+    elif [ -f pnpm-lock.yaml ]; then \
+      corepack enable pnpm && pnpm build; \
+    else \
+      echo "No lockfile found." && exit 1; \
+    fi
+
+  # ============================================
+  # Stage 3: Run Next.js application
+  # ============================================
+
+  FROM node:${NODE_VERSION} AS runner
+
+  # Set working directory
+  WORKDIR /app
+
+  # Set production environment variables
+  ENV NODE_ENV=production
+  ENV PORT=3000
+  ENV HOSTNAME="0.0.0.0"
+
+  # Next.js collects completely anonymous telemetry data about general usage.
+  # Learn more here: https://nextjs.org/telemetry
+  # Uncomment the following line in case you want to disable telemetry during the run time.
+  # ENV NEXT_TELEMETRY_DISABLED=1
+
+  # Copy production assets
+  COPY --from=builder --chown=node:node /app/public ./public
+
+  # Set the correct permission for prerender cache
+  RUN mkdir .next
+  RUN chown node:node .next
+
+  # Automatically leverage output traces to reduce image size
+  # https://nextjs.org/docs/advanced-features/output-file-tracing
+  COPY --from=builder --chown=node:node /app/.next/standalone ./
+  COPY --from=builder --chown=node:node /app/.next/static ./.next/static
+
+  # If you want to persist the fetch cache generated during the build so that
+  # cached responses are available immediately on startup, uncomment this line:
+  # COPY --from=builder --chown=node:node /app/.next/cache ./.next/cache
+
+  # Switch to non-root user for security best practices
+  USER node
+
+  # Expose port 3000 to allow HTTP traffic
+  EXPOSE 3000
+
+  # Start Next.js standalone server
+  CMD ["node", "server.js"]
+```
+
+> [!NOTE]
+> This Dockerfile uses three stages: `dependencies`, `builder`, and `runner`. The final image runs `node server.js` and listens on port 3000.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+---
+
+##### 1.2 Next.js with export output
+
+Output export (`output: "export"`) makes Next.js build a fully static site at build time. It generates HTML, CSS, and JavaScript into an `out` directory that can be served by any static host or CDN—no Node.js server at runtime. Use this when you don't need server-side rendering or API routes. For details, see the [Next.js output configuration documentation](https://nextjs.org/docs/app/api-reference/config/next-config-js/output).
+
+Configure Next.js — Open `next.config.ts` in your project root and add the following code:
+
+```ts
+import type { NextConfig } from "next";
+
+const nextConfig: NextConfig = {
+  output: "export",
+  trailingSlash: true,
+  images: {
+    unoptimized: true,
+  },
+};
+
+export default nextConfig;
+```
+
+Choose either a Docker Hardened Image or the Docker Official Image, then create a `Dockerfile` using the content from the selected tab below.
+
+{{< tabs >}}
+{{< tab name="Using Docker Hardened Images" >}}
+
+Docker Hardened Images (DHIs) are available for Node.js and Nginx in the [Docker Hardened Images catalog](https://hub.docker.com/hardened-images/catalog). For more information, see the [DHI quickstart](/dhi/get-started/) guide.
+
+1. Sign in to the DHI registry:
+
+   ```console
+   $ docker login dhi.io
+   ```
+
+2. Pull the Node.js DHI (check the catalog for available versions):
+
+   ```console
+   $ docker pull dhi.io/node:24-alpine3.22-dev
+   ```
+
+3. Pull the Nginx DHI (check the catalog for available versions):
+
+   ```console
+   $ docker pull dhi.io/nginx:1.28.0-alpine3.21-dev
+   ```
+
+4. Create a file named `Dockerfile` with the following contents. The `FROM` instructions use Docker Hardened Images: `dhi.io/node:24-alpine3.22-dev` and `dhi.io/nginx:1.28.0-alpine3.21-dev`. Check the [Docker Hardened Images catalog](https://hub.docker.com/hardened-images/catalog) for the latest versions and update the image tags as needed for security and compatibility.
+
+   ```dockerfile
+   # ============================================
+   # Stage 1: Dependencies Installation Stage
+   # ============================================
+
+   # IMPORTANT: Docker Hardened Image (DHI) Version Maintenance
+   # This Dockerfile uses dhi.io/node and dhi.io/nginx. Regularly validate and update to the latest DHI versions in the catalog for security and compatibility.
+
+   FROM dhi.io/node:24-alpine3.22-dev AS dependencies
+
+   # Set the working directory
+   WORKDIR /app
+
+   # Copy package-related files first to leverage Docker's caching mechanism
+   COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* .npmrc* ./
+
+   # Install project dependencies with frozen lockfile for reproducible builds
+   RUN --mount=type=cache,target=/root/.npm \
+       --mount=type=cache,target=/usr/local/share/.cache/yarn \
+       --mount=type=cache,target=/root/.local/share/pnpm/store \
+     if [ -f package-lock.json ]; then \
+       npm ci --no-audit --no-fund; \
+     elif [ -f yarn.lock ]; then \
+       corepack enable yarn && yarn install --frozen-lockfile --production=false; \
+     elif [ -f pnpm-lock.yaml ]; then \
+       corepack enable pnpm && pnpm install --frozen-lockfile; \
+     else \
+       echo "No lockfile found." && exit 1; \
+     fi
+
+   # ============================================
+   # Stage 2: Build Next.js Application
+   # ============================================
+
+   FROM dhi.io/node:24-alpine3.22-dev AS builder
+
+   # Set the working directory
+   WORKDIR /app
+
+   # Copy project dependencies from dependencies stage
+   COPY --from=dependencies /app/node_modules ./node_modules
+
+   # Copy application source code
+   COPY . .
+
+   ENV NODE_ENV=production
+
+   # Next.js collects completely anonymous telemetry data about general usage.
+   # Learn more here: https://nextjs.org/telemetry
+   # Uncomment the following line in case you want to disable telemetry during the build.
+   # ENV NEXT_TELEMETRY_DISABLED=1
+
+   # Build Next.js application
+   RUN --mount=type=cache,target=/app/.next/cache \
+     if [ -f package-lock.json ]; then \
+       npm run build; \
+     elif [ -f yarn.lock ]; then \
+       corepack enable yarn && yarn build; \
+     elif [ -f pnpm-lock.yaml ]; then \
+       corepack enable pnpm && pnpm build; \
+     else \
+       echo "No lockfile found." && exit 1; \
+     fi
+
+   # =========================================
+   # Stage 3: Serve Static Files with Nginx
+   # =========================================
+
+   FROM dhi.io/nginx:1.28.0-alpine3.21-dev AS runner
+
+   # Set the working directory
+   WORKDIR /app
+
+   # Next.js collects completely anonymous telemetry data about general usage.
+   # Learn more here: https://nextjs.org/telemetry
+   # Uncomment the following line in case you want to disable telemetry during the run time.
+   # ENV NEXT_TELEMETRY_DISABLED=1
+
+   # Copy custom Nginx config
+   COPY nginx.conf /etc/nginx/nginx.conf
+
+   # Copy the static build output from the build stage to Nginx's default HTML serving directory
+   COPY --chown=nginx:nginx --from=builder /app/out /usr/share/nginx/html
+
+   # Non-root user for security best practices
+   USER nginx
+
+   # Expose port 8080 to allow HTTP traffic
+   EXPOSE 8080
+
+   # Start Nginx directly with custom config
+   ENTRYPOINT ["nginx", "-c", "/etc/nginx/nginx.conf"]
+   CMD ["-g", "daemon off;"]
+   ```
+
+{{< /tab >}}
+{{< tab name="Using the Docker Official Image" >}}
+
+Create a file named `Dockerfile` with the following contents (uses `node` and `nginxinc/nginx-unprivileged`):
+
+```dockerfile
+# ============================================
+# Stage 1: Dependencies Installation Stage
+# ============================================
+
+ARG NODE_VERSION=24.14.0-slim
+ARG NGINXINC_IMAGE_TAG=alpine3.22
+
+FROM node:${NODE_VERSION} AS dependencies
+
+# Set the working directory
+WORKDIR /app
+
+# Copy package-related files first to leverage Docker's caching mechanism
+COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* .npmrc* ./
+
+# Install project dependencies with frozen lockfile for reproducible builds
+RUN --mount=type=cache,target=/root/.npm \
+    --mount=type=cache,target=/usr/local/share/.cache/yarn \
+    --mount=type=cache,target=/root/.local/share/pnpm/store \
+  if [ -f package-lock.json ]; then \
+    npm ci --no-audit --no-fund; \
+  elif [ -f yarn.lock ]; then \
+    corepack enable yarn && yarn install --frozen-lockfile --production=false; \
+  elif [ -f pnpm-lock.yaml ]; then \
+    corepack enable pnpm && pnpm install --frozen-lockfile; \
+  else \
+    echo "No lockfile found." && exit 1; \
+  fi
+
+# ============================================
+# Stage 2: Build Next.js Application
+# ============================================
+
+FROM node:${NODE_VERSION} AS builder
+
+# Set the working directory
+WORKDIR /app
+
+# Copy project dependencies from dependencies stage
+COPY --from=dependencies /app/node_modules ./node_modules
+
+# Copy application source code
+COPY . .
+
+ENV NODE_ENV=production
+
+# Next.js collects completely anonymous telemetry data about general usage.
+# Learn more here: https://nextjs.org/telemetry
+# Uncomment the following line in case you want to disable telemetry during the build.
+# ENV NEXT_TELEMETRY_DISABLED=1
+
+# Build Next.js application
+RUN --mount=type=cache,target=/app/.next/cache \
+  if [ -f package-lock.json ]; then \
+    npm run build; \
+  elif [ -f yarn.lock ]; then \
+    corepack enable yarn && yarn build; \
+  elif [ -f pnpm-lock.yaml ]; then \
+    corepack enable pnpm && pnpm build; \
+  else \
+    echo "No lockfile found." && exit 1; \
+  fi
+
+# =========================================
+# Stage 3: Serve Static Files with Nginx
+# =========================================
+
+FROM nginxinc/nginx-unprivileged:${NGINXINC_IMAGE_TAG} AS runner
+
+# Set the working directory
+WORKDIR /app
+
+# Next.js collects completely anonymous telemetry data about general usage.
+# Learn more here: https://nextjs.org/telemetry
+# Uncomment the following line in case you want to disable telemetry during the run time.
+# ENV NEXT_TELEMETRY_DISABLED=1
+
+# Copy custom Nginx config
+COPY nginx.conf /etc/nginx/nginx.conf
+
+# Copy the static build output from the build stage to Nginx's default HTML serving directory
+COPY --from=builder /app/out /usr/share/nginx/html
+
+# Non-root user for security best practices
+USER nginx
+
+# Expose port 8080 to allow HTTP traffic
+EXPOSE 8080
+
+# Start Nginx directly with custom config
+ENTRYPOINT ["nginx", "-c", "/etc/nginx/nginx.conf"]
+CMD ["-g", "daemon off;"]
+```
+
+> [!NOTE]
+> This guide uses [nginx-unprivileged](https://hub.docker.com/r/nginxinc/nginx-unprivileged) instead of the standard Nginx image to run as a non-root user, following security best practices.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+1. Create `nginx.conf` (required for export output only) — Create a file named `nginx.conf` in the root of your project:
+
+   ```nginx
+   # Minimal Nginx config for static Next.js app
+   worker_processes 1;
+
+   # Store PID in /tmp (always writable)
+   pid /tmp/nginx.pid;
+
+   events {
+       worker_connections 1024;
+   }
+
+   http {
+       include       /etc/nginx/mime.types;
+       default_type  application/octet-stream;
+
+       # Disable logging to avoid permission issues
+       access_log off;
+       error_log  /dev/stderr;
+
+       # Optimize static file serving
+       sendfile        on;
+       tcp_nopush      on;
+       tcp_nodelay     on;
+       keepalive_timeout  65;
+
+       # Gzip compression
+       gzip on;
+       gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
+       gzip_min_length 256;
+
+       server {
+           listen       8080;
+           server_name  localhost;
+
+           # Serve static files
+           root /usr/share/nginx/html;
+           index index.html;
+
+           # Handle Next.js static export routing
+           # See: https://nextjs.org/docs/app/guides/static-exports#deploying
+           location / {
+               try_files $uri $uri.html $uri/ =404;
+           }
+
+           # This is necessary when `trailingSlash: false` (default).
+           # You can omit this when `trailingSlash: true` in next.config.
+           # Handles nested routes like /blog/post -> /blog/post.html
+           location ~ ^/(.+)/$ {
+               rewrite ^/(.+)/$ /$1.html break;
+           }
+
+           # Serve Next.js static assets
+           location ~ ^/_next/ {
+               try_files $uri =404;
+               expires 1y;
+               add_header Cache-Control "public, immutable";
+           }
+
+           # Optional 404 handling
+           error_page 404 /404.html;
+           location = /404.html {
+               internal;
+           }
+       }
+   }
+   ```
+
+   > [!NOTE]
+   > Export uses port 8080. For more details, see the [Next.js output configuration](https://nextjs.org/docs/app/api-reference/config/next-config-js/output) and [Nginx documentation](https://nginx.org/en/docs/).
+
+#### Step 2: Create the compose.yaml file
+
+Create a file named `compose.yaml` with the following contents:
+
+```yaml {collapse=true,title=compose.yaml}
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 3000:3000
+```
+
+> [!NOTE]
+> If using export output (Nginx), change the port mapping to `8080:8080`.
+
+#### Step 3: Create the .dockerignore file
+
+The `.dockerignore` file tells Docker which files and folders to exclude when building the image.
+
+> [!NOTE]
+> This helps:
+>
+> - Reduce image size
+> - Speed up the build process
+> - Prevent sensitive or unnecessary files (like `.env`, `.git`, or `node_modules`) from being added to the final image.
+>
+> To learn more, visit the [.dockerignore reference](/reference/dockerfile.md#dockerignore-file).
+
+Create a file named `.dockerignore` with the following contents:
+
+```dockerignore
+# Dependencies (installed inside the image, never copy from host)
+node_modules/
+.pnp/
+.pnp.js
+.pnpm-store/
+
+# Next.js build output (generated during the image build)
+.next/
+out/
+dist/
+build/
+.vercel/
+
+# Testing (not needed in the production image)
+coverage/
+.nyc_output/
+__tests__/
+__mocks__/
+jest/
+cypress/
+playwright-report/
+test-results/
+.vitest/
+
+# Environment files (avoid leaking secrets into the build context)
+.env
+.env*
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+# Debug and log files
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+pnpm-debug.log*
+lerna-debug.log*
+*.log
+
+# IDE and editor files
+.vscode/
+.idea/
+.cursor/
+.cursorrules
+.copilot/
+*.swp
+*.swo
+*~
+
+# Git
+.git/
+.gitignore
+.gitattributes
+
+# Docker files (reduce build context; not needed inside the image)
+Dockerfile*
+.dockerignore
+docker-compose*.yml
+compose*.yaml
+
+# Documentation (not needed in the image)
+*.md
+docs/
+
+# CI/CD (not needed in the image)
+.github/
+.gitlab-ci.yml
+.travis.yml
+.circleci/
+Jenkinsfile
+
+# TypeScript and build metadata
+*.tsbuildinfo
+
+# Cache and temporary directories
+.cache/
+.parcel-cache/
+.eslintcache
+.stylelintcache
+.turbo/
+.tmp/
+.temp/
+
+# Sensitive or dev-only config (optional; omit if your build needs these)
+.pem
+.editorconfig
+.prettierrc*
+.eslintrc*
+.stylelintrc*
+.babelrc*
+*.iml
+
+# OS-specific files
+.DS_Store
+._*
+.Spotlight-V100
+.Trashes
+ehthumbs.db
+Thumbs.db
+Desktop.ini
+```
+
+#### Step 4: Build the Next.js application image
+
+With your custom configuration in place, you're now ready to build the Docker image. Use the Dockerfile you created in Step 1 (standalone or export).
+
+The setup includes:
+
+- Multi-stage builds for optimized image size
+- Standalone: Node.js server on port 3000; Export: Nginx serving static files on port 8080
+- Non-root user for enhanced security
+- Proper file permissions and ownership
+
+After completing the previous steps, your project directory should contain at least the following files (export also requires `nginx.conf`):
+
+```text
+├── docker-nextjs-sample/
+│ ├── Dockerfile
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ └── next.config.ts
+```
+
+Now that your Dockerfile is configured, you can build the Docker image for your Next.js application.
+
+> [!NOTE]
+> The `docker build` command packages your application into an image using the instructions in the Dockerfile. It includes all necessary files from the current directory (called the [build context](/build/concepts/context/#what-is-a-build-context)).
+
+Run the following command from the root of your project:
+
+```console
+$ docker build --tag nextjs-sample .
+```
+
+What this command does:
+
+- Uses the Dockerfile in the current directory (.)
+- Packages the application and its dependencies into a Docker image
+- Tags the image as nextjs-sample so you can reference it later
+
+#### Step 5: View local images
+
+After building your Docker image, you can check which images are available on your local machine using either the Docker CLI or [Docker Desktop](/manuals/desktop/use-desktop/images.md). Since you're already working in the terminal, let's use the Docker CLI.
+
+To list all locally available Docker images, run the following command:
+
+```console
+$ docker images
+```
+
+Example Output:
+
+```shell
+REPOSITORY                TAG               IMAGE ID       CREATED         SIZE
+nextjs-sample             latest            8c5fc80f098e   14 seconds ago   130MB
+```
+
+This output provides key details about your images:
+
+- Repository – The name assigned to the image.
+- Tag – A version label that helps identify different builds (e.g., latest).
+- Image ID – A unique identifier for the image.
+- Created – The timestamp indicating when the image was built.
+- Size – The total disk space used by the image.
+
+If the build was successful, you should see `nextjs-sample` image listed.
+
+---
+
+### Run the containerized application
+
+In the previous step, you created a Dockerfile for your Next.js application and built a Docker image using the docker build command. Now it's time to run that image in a container and verify that your application works as expected.
+
+Run the following command in a terminal. Use the port that matches your setup: standalone uses port 3000, export uses port 8080.
+
+```console
+$ docker run -p 3000:3000 nextjs-sample
+```
+
+For export output, use port 8080 instead:
+
+```console
+$ docker run -p 8080:8080 nextjs-sample
+```
+
+Open a browser and view the application: [http://localhost:3000](http://localhost:3000) for standalone or [http://localhost:8080](http://localhost:8080) for export. You should see your Next.js web application.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d` option and `--name` to give the container a name so you can stop it later:
+
+```console
+$ docker run -d -p 3000:3000 --name nextjs-app nextjs-sample
+```
+
+For export output, use port 8080:
+
+```console
+$ docker run -d -p 8080:8080 --name nextjs-app nextjs-sample
+```
+
+Open a browser and view the application: [http://localhost:3000](http://localhost:3000) for standalone or [http://localhost:8080](http://localhost:8080) for export. You should see your web application.
+
+To confirm that the container is running, use the `docker ps` command:
+
+```console
+$ docker ps
+```
+
+This will list all active containers along with their ports, names, and status. Look for a container exposing port 3000 (standalone) or 8080 (export).
+
+Example Output:
+
+```shell
+CONTAINER ID   IMAGE           COMMAND                  CREATED             STATUS             PORTS                    NAMES
+f49b74736a9d   nextjs-sample   "node server.js"         About a minute ago   Up About a minute   0.0.0.0:3000->3000/tcp nextjs-app
+```
+
+To stop the application, run:
+
+```console
+$ docker stop nextjs-app
+```
+
+> [!NOTE]
+> For more information about running containers, see the [`docker run` CLI reference](/reference/cli/docker/container/run/) and the [`docker stop` CLI reference](/reference/cli/docker/container/stop/).
+
+---
+
+## Use containers for Next.js development
+
+### Prerequisites
+
+Complete [Containerize Next.js application](#containerize-a-nextjs-application).
+
+---
+
+### Overview
+
+In this section, you'll learn how to set up both production and development environments for your containerized Next.js application using Docker Compose. This setup allows you to run a production build using the standalone server and to develop efficiently inside containers using Next.js's built-in hot reloading with Compose Watch.
+
+You'll learn how to:
+
+- Configure separate containers for production and development
+- Enable automatic file syncing using Compose Watch in development
+- Debug and live-preview your changes in real-time without manual rebuilds
+
+---
+
+### Automatically update services (development mode)
+
+Use Compose Watch to automatically sync source file changes into your
+containerized development environment. This automatically syncs file changes
+without needing to restart or rebuild containers manually.
+
+### Step 1: Create a development Dockerfile
+
+Create a file named `Dockerfile.dev` in your project root with the following content (matching the [sample project](https://github.com/kristiyan-velkov/docker-nextjs-sample)):
+
+```dockerfile
+# ============================================
+# Development Dockerfile for Next.js
+# ============================================
+ARG NODE_VERSION=24.14.0-slim
+
+FROM node:${NODE_VERSION} AS dev
+
+WORKDIR /app
+
+COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* .npmrc* ./
+
+RUN --mount=type=cache,target=/root/.npm \
+    --mount=type=cache,target=/usr/local/share/.cache/yarn \
+    --mount=type=cache,target=/root/.local/share/pnpm/store \
+  if [ -f package-lock.json ]; then \
+    npm ci --no-audit --no-fund; \
+  elif [ -f yarn.lock ]; then \
+    corepack enable yarn && yarn install --frozen-lockfile --production=false; \
+  elif [ -f pnpm-lock.yaml ]; then \
+    corepack enable pnpm && pnpm install --frozen-lockfile; \
+  else \
+    echo "No lockfile found." && exit 1; \
+  fi
+
+COPY . .
+
+ENV WATCHPACK_POLLING=true
+ENV HOSTNAME="0.0.0.0"
+
+RUN chown -R node:node /app
+USER node
+
+EXPOSE 3000
+
+CMD ["sh", "-c", "if [ -f package-lock.json ]; then npm run dev; elif [ -f yarn.lock ]; then yarn dev; elif [ -f pnpm-lock.yaml ]; then pnpm dev; else npm run dev; fi"]
+```
+
+This file sets up a development environment for your Next.js app with hot module replacement and supports npm, yarn, and pnpm.
+
+#### Step 2: Update your `compose.yaml` file
+
+Open your `compose.yaml` file and define two services: one for production (`nextjs-prod-standalone`) and one for development (`nextjs-dev`). This matches the [sample project](https://github.com/kristiyan-velkov/docker-nextjs-sample) structure.
+
+Here's an example configuration for a Next.js application:
+
+```yaml
+services:
+  nextjs-prod-standalone:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: nextjs-sample:prod
+    container_name: nextjs-sample-prod
+    ports:
+      - "3000:3000"
+
+  nextjs-dev:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    image: nextjs-sample:dev
+    container_name: nextjs-sample-dev
+    ports:
+      - "3000:3000"
+    environment:
+      - WATCHPACK_POLLING=true
+    develop:
+      watch:
+        - action: sync
+          path: .
+          target: /app
+          ignore:
+            - node_modules/
+            - .next/
+        - action: rebuild
+          path: package.json
+```
+
+- The `nextjs-prod-standalone` service builds and runs your production Next.js app using the standalone output.
+- The `nextjs-dev` service runs your Next.js development server with hot module replacement.
+- `watch` triggers file sync with Compose Watch.
+- `WATCHPACK_POLLING=true` ensures file changes are detected properly inside Docker.
+- The `rebuild` action for `package.json` ensures dependencies are reinstalled when the file changes.
+
+> [!NOTE]
+> For more details, see the official guide: [Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
+
+#### Step 3: Configure Next.js for Docker development
+
+Next.js works well inside Docker containers out of the box, but there are a few configurations that can improve the development experience.
+
+The `next.config.ts` file you created during containerization already includes the `output: "standalone"` option for production. For development, Next.js automatically uses its built-in development server with hot reloading enabled.
+
+> [!NOTE]
+> The Next.js development server automatically:
+>
+> - Enables Hot Module Replacement (HMR) for instant updates
+> - Watches for file changes and recompiles automatically
+> - Provides detailed error messages in the browser
+>
+> The `WATCHPACK_POLLING=true` environment variable in the compose file ensures file watching works correctly inside Docker containers.
+
+After completing the previous steps, your project directory should now contain the following files:
+
+```text
+├── docker-nextjs-sample/
+│ ├── Dockerfile
+│ ├── Dockerfile.dev
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ └── next.config.ts
+```
+
+#### Step 4: Start Compose Watch
+
+Run the following command from your project root to start your container in watch mode:
+
+```console
+$ docker compose watch nextjs-dev
+```
+
+#### Step 5: Test Compose Watch with Next.js
+
+To verify that Compose Watch is working correctly:
+
+1. Open the `app/page.tsx` file in your text editor (or `src/app/page.tsx` if your project uses a `src` directory).
+
+2. Locate the main content area and find a text element to modify.
+
+3. Make a visible change, for example, update a heading:
+
+   ```tsx
+   <h1>Hello from Docker Compose Watch!</h1>
+   ```
+
+4. Save the file.
+
+5. Open your browser at [http://localhost:3000](http://localhost:3000).
+
+You should see the updated text appear instantly, without needing to rebuild the container manually. This confirms that file watching and automatic synchronization are working as expected.
+
+---
+
+## Run Next.js tests in a container
+
+### Prerequisites
+
+Complete all the previous sections of this guide, starting with [Containerize Next.js application](#containerize-a-nextjs-application).
+
+### Overview
+
+Testing is a critical part of the development process. In this section, you'll learn how to:
+
+- Run unit tests using Vitest (or Jest) inside a Docker container.
+- Run lint (e.g. ESLint) inside a Docker container.
+- Use Docker Compose to run tests and lint in an isolated, reproducible environment.
+
+The [sample project](https://github.com/kristiyan-velkov/docker-nextjs-sample) uses [Vitest](https://vitest.dev/) with [Testing Library](https://testing-library.com/) for component testing. You can use the same setup or follow the alternative Jest configuration later.
+
+---
+
+### Run tests during development
+
+The [sample project](https://github.com/kristiyan-velkov/docker-nextjs-sample) already includes lint (ESLint) and sample tests (Vitest, `app/page.test.tsx`) in place. If you're using the sample app, you can skip to **Step 3: Update compose.yaml** and run tests or lint with the commands below. If you're using your own project, follow the install and configuration steps to add the packages and scripts.
+
+The sample includes a test file at:
+
+```text
+app/page.test.tsx
+```
+
+This file uses Vitest and React Testing Library to verify the behavior of page components.
+
+#### Step 1: Install Vitest and React Testing Library (custom projects)
+
+If you're using a custom project and haven't already added the necessary testing tools, install them by running:
+
+```console
+$ npm install --save-dev vitest @vitejs/plugin-react @testing-library/react @testing-library/dom jsdom
+```
+
+Then, update the scripts section of your `package.json` file to include:
+
+```json
+"scripts": {
+  "test": "vitest",
+  "test:run": "vitest run"
+}
+```
+
+For lint, add a `lint` script (and optionally `lint:fix`). For example, with [ESLint](https://eslint.org/):
+
+```json
+"scripts": {
+  "test": "vitest",
+  "test:run": "vitest run",
+  "lint": "eslint .",
+  "lint:fix": "eslint . --fix"
+}
+```
+
+The sample project uses `eslint` and `eslint-config-next` for Next.js. Install them in a custom project with:
+
+```console
+$ npm install --save-dev eslint eslint-config-next @eslint/eslintrc
+```
+
+Create an ESLint config file (e.g. `eslint.config.cjs`) in your project root with Next.js rules and global ignores:
+
+```js
+const { defineConfig, globalIgnores } = require("eslint/config");
+const { FlatCompat } = require("@eslint/eslintrc");
+
+const compat = new FlatCompat({ baseDirectory: __dirname });
+
+module.exports = defineConfig([
+  ...compat.extends(
+    "eslint-config-next/core-web-vitals",
+    "eslint-config-next/typescript",
+  ),
+  globalIgnores([
+    ".next/**",
+    "out/**",
+    "build/**",
+    "next-env.d.ts",
+    "node_modules/**",
+    "eslint.config.cjs",
+  ]),
+]);
+```
+
+---
+
+#### Step 2: Configure Vitest (custom projects)
+
+If you're using a custom project, create a `vitest.config.ts` file in your project root (matching the [sample project](https://github.com/kristiyan-velkov/docker-nextjs-sample)):
+
+```ts
+import { defineConfig } from "vitest/config";
+import react from "@vitejs/plugin-react";
+
+export default defineConfig({
+  plugins: [react()],
+  test: {
+    environment: "jsdom",
+    setupFiles: "./vitest.setup.ts",
+    globals: true,
+  },
+});
+```
+
+Create a `vitest.setup.ts` file in your project root:
+
+```ts
+import "@testing-library/jest-dom/vitest";
+```
+
+> [!NOTE]
+> Vitest works well with Next.js and provides fast execution and ESM support. For more details, see the [Next.js testing documentation](https://nextjs.org/docs/app/building-your-application/testing) and [Vitest docs](https://vitest.dev/).
+
+#### Step 3: Update compose.yaml
+
+Add `nextjs-test` and `nextjs-lint` services to your `compose.yaml` file. In the sample project these services use the `tools` profile so they don't start with a normal `docker compose up`. Both reuse `Dockerfile.dev` and run the test or lint command:
+
+```yaml
+services:
+  nextjs-prod-standalone:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: nextjs-sample:prod
+    container_name: nextjs-sample-prod
+    ports:
+      - "3000:3000"
+
+  nextjs-dev:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    image: nextjs-sample:dev
+    container_name: nextjs-sample-dev
+    ports:
+      - "3000:3000"
+    environment:
+      - WATCHPACK_POLLING=true
+    develop:
+      watch:
+        - action: sync
+          path: .
+          target: /app
+          ignore:
+            - node_modules/
+            - .next/
+        - action: rebuild
+          path: package.json
+
+  nextjs-test:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    image: nextjs-sample:dev
+    container_name: nextjs-sample-test
+    command:
+      [
+        "sh",
+        "-c",
+        "if [ -f package-lock.json ]; then npm run test:run 2>/dev/null || npm run test -- --run; elif [ -f yarn.lock ]; then yarn test:run 2>/dev/null || yarn test --run; elif [ -f pnpm-lock.yaml ]; then pnpm run test:run; else npm run test -- --run; fi",
+      ]
+    profiles:
+      - tools
+
+  nextjs-lint:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    image: nextjs-sample:dev
+    container_name: nextjs-sample-lint
+    command:
+      [
+        "sh",
+        "-c",
+        "if [ -f package-lock.json ]; then npm run lint; elif [ -f yarn.lock ]; then yarn lint; elif [ -f pnpm-lock.yaml ]; then pnpm lint; else npm run lint; fi",
+      ]
+    profiles:
+      - tools
+```
+
+The `nextjs-test` and `nextjs-lint` services reuse the same `Dockerfile.dev` used for [development](#use-containers-for-nextjs-development) and override the default command to run tests or lint. The `profiles: [tools]` means these services only run when you use the `--profile tools` option.
+
+After completing the previous steps, your project directory should contain:
+
+```text
+├── docker-nextjs-sample/
+│ ├── Dockerfile
+│ ├── Dockerfile.dev
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ ├── vitest.config.ts
+│ ├── vitest.setup.ts
+│ └── next.config.ts
+```
+
+#### Step 4: Run the tests
+
+To execute your test suite inside the container, run from your project root:
+
+```console
+$ docker compose --profile tools run --rm nextjs-test
+```
+
+This command will:
+
+- Start the `nextjs-test` service (because of `--profile tools`).
+- Run your test script (`test:run` or `test -- --run`) in the same environment as development.
+- Remove the container after the tests complete ([`docker compose run --rm`](/reference/cli/docker/compose/run/)).
+
+> [!NOTE]
+> For more information about Compose commands and profiles, see the [Compose CLI reference](/reference/cli/docker/compose/).
+
+#### Step 5: Run lint in the container
+
+To run your linter (e.g. ESLint) inside the container, use the `nextjs-lint` service with the same `tools` profile:
+
+```console
+$ docker compose --profile tools run --rm nextjs-lint
+```
+
+This command will:
+
+- Start the `nextjs-lint` service (because of `--profile tools`).
+- Run your lint script (`npm run lint`, `yarn lint`, or `pnpm lint` depending on your lockfile) in the same environment as development.
+- Remove the container after lint completes.
+
+Ensure your `package.json` includes a `lint` script. The sample project already has `"lint": "eslint ."` and `"lint:fix": "eslint . --fix"`; for a custom project, add the same and install `eslint` and `eslint-config-next` if needed.
+
+---
+
+### Summary
+
+In this section, you learned how to run unit tests for your Next.js application inside a Docker container using Vitest and Docker Compose.
+
+What you accomplished:
+
+- Installed and configured Vitest and React Testing Library for testing Next.js components.
+- Created `nextjs-test` and `nextjs-lint` services in `compose.yaml` (with `tools` profile) to isolate test and lint execution.
+- Reused the development `Dockerfile.dev` to ensure consistency between dev, test, and lint environments.
+- Ran tests inside the container using `docker compose --profile tools run --rm nextjs-test`.
+- Ran lint inside the container using `docker compose --profile tools run --rm nextjs-lint`.
+- Ensured reliable, repeatable testing and linting across environments without relying on local machine setup.
+
+---
+
+### Related resources
+
+Explore official references and best practices to sharpen your Docker testing workflow:
+
+- [Dockerfile reference](/reference/dockerfile/) – Understand all Dockerfile instructions and syntax.
+- [Best practices for writing Dockerfiles](/develop/develop-images/dockerfile_best-practices/) – Write efficient, maintainable, and secure Dockerfiles.
+- [Compose file reference](/compose/compose-file/) – Learn the full syntax and options available for configuring services in `compose.yaml`.
+- [`docker compose run` CLI reference](/reference/cli/docker/compose/run/) – Run one-off commands in a service container.
+- [Next.js Testing Documentation](https://nextjs.org/docs/app/building-your-application/testing) – Official Next.js testing guide.
diff --git a/content/guides/nodejs.md b/content/guides/nodejs.md
new file mode 100644
index 000000000000..5957d88ee116
--- /dev/null
+++ b/content/guides/nodejs.md
@@ -0,0 +1,1350 @@
+---
+title: Node.js language-specific guide
+linkTitle: Node.js
+description: Containerize and develop Node.js applications using Docker
+keywords: getting started, node, node.js
+summary: |
+  This guide explains how to containerize Node.js applications using Docker.
+aliases:
+  - /guides/nodejs/containerize/
+  - /guides/nodejs/develop/
+  - /guides/nodejs/run-tests/
+  - /guides/nodejs/configure-github-actions/
+  - /guides/nodejs/deploy/
+  - /guides/nodejs/secure-supply-chain/
+  - /language/nodejs/
+  - /guides/language/nodejs/
+  - /get-started/nodejs/build-images/
+  - /language/nodejs/build-images/
+  - /language/nodejs/run-containers/
+  - /language/nodejs/containerize/
+  - /get-started/nodejs/develop/
+  - /language/nodejs/develop/
+  - /language/nodejs/run-tests/
+  - /language/nodejs/configure-ci-cd/
+  - /language/nodejs/deploy/
+weight: 2
+params:
+  tags: [languages]
+  featured: true
+  time: 20 minutes
+---
+
+[Node.js](https://nodejs.org/en) is a JavaScript runtime for building server-side applications. This guide shows you how to containerize a TypeScript Node.js application using Docker, starting from a simple Express API and progressively adding features like a database.
+
+This guide focuses on a backend Node.js API. If you're building a standalone frontend application, Docker has dedicated guides for [React.js](/guides/reactjs/), [Vue.js](/guides/vuejs/), [Angular](/guides/angular/), and [Next.js](/guides/nextjs/).
+
+> **Acknowledgment**
+>
+> Docker thanks [Kristiyan Velkov](https://www.linkedin.com/in/kristiyan-velkov-763130b3/) for his contribution to this guide.
+
+## What will you learn?
+
+In this guide, you'll learn how to:
+
+- Containerize and run a Node.js application using Docker.
+- Set up a local development environment using containers.
+- Run tests inside a Docker container.
+
+Start by containerizing a Node.js application.
+
+## Prerequisites
+
+- Basic understanding of [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript) and [TypeScript](https://www.typescriptlang.org/).
+- Basic knowledge of [Node.js](https://nodejs.org/en) and [npm](https://docs.npmjs.com/about-npm).
+- Familiarity with Docker concepts such as images, containers, and Dockerfiles. If you're new to Docker, start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
+
+## Containerize a Node.js application
+
+### Prerequisites
+
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
+- You're familiar with basic Docker concepts. If you're new to Docker, start with [Get started](/get-started/introduction/).
+
+### Overview
+
+Containerizing your application means packaging it together with its
+dependencies, configuration, and runtime into a single portable unit called a
+container image. Running that image creates a container, an isolated process
+that behaves the same on any machine, whether it's your laptop, a CI runner, or
+a production server.
+
+In this section, you'll containerize a simple [Express.js](https://expressjs.com/) API written in TypeScript. You'll write a `Dockerfile` that describes how to build the image, add a `compose.yaml` file that defines how Docker runs your container, and then build and start the application with one command.
+
+You'll use [Docker Hardened Images](/dhi/) as the base. These are minimal, secure Node.js images maintained by Docker.
+
+This guide focuses on a backend Node.js API. If you're building a standalone frontend application, Docker has dedicated guides for [React.js](/guides/reactjs/), [Vue.js](/guides/vuejs/), [Angular](/guides/angular/), and [Next.js](/guides/nextjs/).
+
+### Create the application
+
+The sample application is a minimal Express API with a single endpoint that returns a JSON greeting. Create the following files in a new `nodejs-docker-example` directory. To create all the files at once, switch to the **Scaffold script** tab in the file browser and copy the shell command.
+
+{{< files name="nodejs-docker-example" >}}
+
+{{< file path="src/index.ts" status="new" >}}
+
+```typescript
+// A minimal Express application.
+// The root endpoint (GET /) returns a JSON greeting.
+// See https://expressjs.com/ for the framework reference.
+
+import express, { type Request, type Response } from "express";
+
+const app = express();
+const port = parseInt(process.env.PORT ?? "3000", 10);
+
+app.get("/", (_req: Request, res: Response) => {
+  res.json({ message: "Hello World" });
+});
+
+app.listen(port, () => {
+  console.log(`Server listening on port ${port}`);
+});
+```
+
+{{< /file >}}
+
+{{< file path="package.json" status="new" >}}
+
+```json
+{
+  "name": "nodejs-docker-example",
+  "version": "1.0.0",
+  "description": "A minimal Node.js TypeScript application.",
+  "main": "dist/index.js",
+  "scripts": {
+    "build": "tsc",
+    "start": "node dist/index.js",
+    "dev": "tsx watch src/index.ts"
+  },
+  "dependencies": {
+    "express": "^4.21.2"
+  },
+  "devDependencies": {
+    "@types/express": "^4.17.21",
+    "@types/node": "^22.0.0",
+    "tsx": "^4.19.3",
+    "typescript": "^5.8.3"
+  }
+}
+```
+
+{{< /file >}}
+
+{{< file path="tsconfig.json" status="new" >}}
+
+```json
+{
+  // TypeScript compiler configuration for the Node.js application.
+  // Compiles src/ to dist/ as CommonJS modules targeting ES2022.
+  // See https://www.typescriptlang.org/tsconfig/ for all options.
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "commonjs",
+    "lib": ["ES2022"],
+    "outDir": "./dist",
+    "rootDir": "./src",
+    "strict": true,
+    "esModuleInterop": true,
+    "skipLibCheck": true
+  },
+  "include": ["src/**/*"],
+  "exclude": ["node_modules", "dist"]
+}
+```
+
+{{< /file >}}
+
+{{< file path=".gitignore" status="new" >}}
+
+```text
+# Files and directories that Git should ignore. Covers Node.js dependencies,
+# TypeScript build output, environment files, and common editor artifacts.
+# See https://git-scm.com/docs/gitignore for syntax reference.
+
+node_modules/
+dist/
+.env
+*.log
+.DS_Store
+coverage/
+db/password.txt
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+If you have Node.js installed and want to verify the app works before containerizing it, you can run it locally.
+
+To run in development mode with hot-reload:
+
+```console
+$ npm install
+$ npm run dev
+```
+
+To run the compiled production build (matching what the Dockerfile does):
+
+```console
+$ npm install
+$ npm run build
+$ npm start
+```
+
+Then open [http://localhost:3000](http://localhost:3000) in your browser. You should see `{"message":"Hello World"}`.
+
+If you don't have Node.js installed, skip ahead. The remaining steps run the application in a container, with no local Node.js required.
+
+### Create the Docker assets
+
+Sign in to the DHI registry so Docker can pull the Node.js base images during the build. The available Node.js images are listed in the [catalog](https://hub.docker.com/hardened-images/catalog/dhi/node).
+
+```console
+$ docker login dhi.io
+```
+
+Add the following three files to your `nodejs-docker-example` directory. The `Dockerfile` describes how to build the image, `compose.yaml` defines how Docker runs the container, and `.dockerignore` keeps unwanted files out of the build context.
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for
+> your project. Ask Gordon to create a Dockerfile, Compose file, and
+> `.dockerignore` tailored to your application.
+
+{{< files name="nodejs-docker-example" >}}
+
+{{< file path="src/index.ts" >}}
+
+```typescript
+// A minimal Express application.
+// The root endpoint (GET /) returns a JSON greeting.
+// See https://expressjs.com/ for the framework reference.
+
+import express, { type Request, type Response } from "express";
+
+const app = express();
+const port = parseInt(process.env.PORT ?? "3000", 10);
+
+app.get("/", (_req: Request, res: Response) => {
+  res.json({ message: "Hello World" });
+});
+
+app.listen(port, () => {
+  console.log(`Server listening on port ${port}`);
+});
+```
+
+{{< /file >}}
+
+{{< file path="package.json" >}}
+
+```json
+{
+  "name": "nodejs-docker-example",
+  "version": "1.0.0",
+  "description": "A minimal Node.js TypeScript application.",
+  "main": "dist/index.js",
+  "scripts": {
+    "build": "tsc",
+    "start": "node dist/index.js",
+    "dev": "tsx watch src/index.ts"
+  },
+  "dependencies": {
+    "express": "^4.21.2"
+  },
+  "devDependencies": {
+    "@types/express": "^4.17.21",
+    "@types/node": "^22.0.0",
+    "tsx": "^4.19.3",
+    "typescript": "^5.8.3"
+  }
+}
+```
+
+{{< /file >}}
+
+{{< file path="tsconfig.json" >}}
+
+```json
+{
+  // TypeScript compiler configuration for the Node.js application.
+  // Compiles src/ to dist/ as CommonJS modules targeting ES2022.
+  // See https://www.typescriptlang.org/tsconfig/ for all options.
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "commonjs",
+    "lib": ["ES2022"],
+    "outDir": "./dist",
+    "rootDir": "./src",
+    "strict": true,
+    "esModuleInterop": true,
+    "skipLibCheck": true
+  },
+  "include": ["src/**/*"],
+  "exclude": ["node_modules", "dist"]
+}
+```
+
+{{< /file >}}
+
+{{< file path="Dockerfile" status="new" >}}
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Dockerfile reference guide at
+# https://docs.docker.com/go/dockerfile-reference/
+
+# This Dockerfile uses Docker Hardened Images (DHI) for enhanced security.
+# For more information, see https://docs.docker.com/dhi/
+
+# Builder stage: install all dependencies and compile TypeScript.
+FROM dhi.io/node:24-alpine3.23-dev AS builder
+
+WORKDIR /app
+
+# Install dependencies as a separate step to take advantage of Docker's
+# caching. Leverage a cache mount to /root/.npm to speed up subsequent
+# builds. Leverage a bind mount to package.json to avoid having to copy
+# it into this layer.
+RUN --mount=type=cache,target=/root/.npm \
+    --mount=type=bind,source=package.json,target=package.json \
+    npm install
+# Once you create a package-lock.json by running npm install locally, switch to npm ci and bind both files:
+# RUN --mount=type=cache,target=/root/.npm \
+#     --mount=type=bind,source=package.json,target=package.json \
+#     --mount=type=bind,source=package-lock.json,target=package-lock.json \
+#     npm ci
+
+# Copy the source code into the container and compile TypeScript.
+COPY . .
+RUN npm run build
+
+
+# Deps stage: install production dependencies only.
+FROM dhi.io/node:24-alpine3.23-dev AS deps
+
+WORKDIR /app
+
+RUN --mount=type=cache,target=/root/.npm \
+    --mount=type=bind,source=package.json,target=package.json \
+    npm install --omit=dev
+# Once you create a package-lock.json by running npm install locally, switch to npm ci and bind both files:
+# RUN --mount=type=cache,target=/root/.npm \
+#     --mount=type=bind,source=package.json,target=package.json \
+#     --mount=type=bind,source=package-lock.json,target=package-lock.json \
+#     npm ci --omit=dev
+
+
+# Runner stage: minimal runtime image with compiled app and production deps.
+FROM dhi.io/node:24-alpine3.23 AS runner
+
+ENV PATH=/app/node_modules/.bin:$PATH
+
+WORKDIR /app
+
+COPY --from=deps --chown=node:node /app/node_modules ./node_modules
+COPY --from=builder --chown=node:node /app/dist ./dist
+
+# Expose the port that the application listens on.
+EXPOSE 3000
+
+# Run the application.
+CMD ["node", "dist/index.js"]
+```
+
+{{< /file >}}
+
+{{< file path="compose.yaml" status="new" >}}
+
+```yaml
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Docker Compose reference guide at
+# https://docs.docker.com/go/compose-spec-reference/
+
+# Here the instructions define your application as a service called "server".
+# This service is built from the Dockerfile in the current directory.
+# You can add other services your application may depend on here, such as a
+# database or a cache. For examples, see the Awesome Compose repository:
+# https://github.com/docker/awesome-compose
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 3000:3000
+```
+
+{{< /file >}}
+
+{{< file path=".dockerignore" status="new" >}}
+
+```text
+# Include any files or directories that you don't want to be copied to your
+# container here (e.g., local build artifacts, temporary files, etc.).
+#
+# For more help, visit the .dockerignore file reference guide at
+# https://docs.docker.com/go/build-context-dockerignore/
+
+node_modules/
+dist/
+.env
+.git
+.gitignore
+.DS_Store
+npm-debug.log*
+coverage/
+db/
+```
+
+{{< /file >}}
+
+{{< file path=".gitignore" >}}
+
+```text
+# Files and directories that Git should ignore. Covers Node.js dependencies,
+# TypeScript build output, environment files, and common editor artifacts.
+# See https://git-scm.com/docs/gitignore for syntax reference.
+
+node_modules/
+dist/
+.env
+*.log
+.DS_Store
+coverage/
+db/password.txt
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+The `Dockerfile` uses three stages. The `builder` stage installs all dependencies and compiles TypeScript. The `deps` stage does a fresh install of production-only dependencies. The `runner` stage copies the compiled output and production node_modules into a minimal runtime image that contains only Node.js.
+
+To learn more about each file, see the following:
+
+- [Dockerfile](/reference/dockerfile.md)
+- [.dockerignore](/reference/dockerfile.md#dockerignore-file)
+- [compose.yaml](/reference/compose-file/_index.md)
+
+### Run the application
+
+Inside the `nodejs-docker-example` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:3000](http://localhost:3000). You should see `{"message":"Hello World"}`.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `nodejs-docker-example` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:3000](http://localhost:3000).
+
+In the terminal, run the following command to stop the application.
+
+```console
+$ docker compose down
+```
+
+For more information about Compose commands, see the [Compose CLI
+reference](/reference/cli/docker/compose/).
+
+## Use containers for Node.js development
+
+### Prerequisites
+
+Complete [Containerize a Node.js application](#containerize-a-nodejs-application).
+
+### Overview
+
+Once your application runs in a container, the next step is making the container part of your everyday development workflow. Code changes should show up quickly, and services your app depends on, like databases, should run right alongside it.
+
+In this section, you'll adapt the Dockerfile for local development by renaming the `builder` stage to `dev` and pointing Compose at it. You'll also update the application to connect to a PostgreSQL database, add a database service to `compose.yaml`, persist data in a named volume, enable Compose Watch so changes in your editor are picked up without a manual rebuild, and set up Node.js debugging so you can attach VS Code or Chrome DevTools to the running container.
+
+### Update the application
+
+You'll update your application to connect to a PostgreSQL database. Continue working in your `nodejs-docker-example` directory.
+
+Replace `src/index.ts` and `package.json` with the following contents. The file browser shows only the files that change in this step.
+
+> [!NOTE]
+>
+> The application won't run yet after this step. It tries to connect to a
+> PostgreSQL database that doesn't exist. The next two sections add the
+> database service and the Docker configuration needed to run everything
+> together.
+
+{{< files name="nodejs-docker-example" >}}
+
+{{< file path="src/index.ts" status="modified" >}}
+
+```typescript
+// Express application backed by a PostgreSQL database.
+// Creates a heroes table at startup.
+// Endpoints: GET / (greeting), GET /health (health check), POST /heroes/ (create), GET /heroes/ (list).
+// See https://expressjs.com/ and https://node-postgres.com/
+
+import express, { type Request, type Response } from "express";
+import { Pool } from "pg";
+import { readFileSync } from "fs";
+
+const app = express();
+const port = parseInt(process.env.PORT ?? "3000", 10);
+
+app.use(express.json());
+
+function getPassword(): string {
+  const passwordFile = process.env.POSTGRES_PASSWORD_FILE;
+  if (passwordFile) {
+    return readFileSync(passwordFile, "utf8").trim();
+  }
+  return process.env.POSTGRES_PASSWORD ?? "";
+}
+
+const pool = new Pool({
+  host: process.env.POSTGRES_SERVER,
+  port: 5432,
+  database: process.env.POSTGRES_DB,
+  user: process.env.POSTGRES_USER,
+  password: getPassword(),
+});
+
+pool
+  .query(
+    `CREATE TABLE IF NOT EXISTS heroes (
+      id SERIAL PRIMARY KEY,
+      name TEXT NOT NULL,
+      secret_name TEXT NOT NULL,
+      age INTEGER
+    )`,
+  )
+  .catch(console.error);
+
+app.get("/", (_req: Request, res: Response) => {
+  res.json({ message: "Hello World" });
+});
+
+app.get("/health", (_req: Request, res: Response) => {
+  res.json({ status: "ok" });
+});
+
+app.post("/heroes/", async (req: Request, res: Response) => {
+  const { name, secret_name, age } = req.body as {
+    name: string;
+    secret_name: string;
+    age?: number;
+  };
+  const result = await pool.query(
+    "INSERT INTO heroes (name, secret_name, age) VALUES ($1, $2, $3) RETURNING *",
+    [name, secret_name, age],
+  );
+  res.json(result.rows[0]);
+});
+
+app.get("/heroes/", async (_req: Request, res: Response) => {
+  const result = await pool.query("SELECT * FROM heroes");
+  res.json(result.rows);
+});
+
+app.listen(port, () => {
+  console.log(`Server listening on port ${port}`);
+});
+```
+
+{{< /file >}}
+
+{{< file path="package.json" status="modified" hl_lines="13,18" >}}
+
+```json
+{
+  "name": "nodejs-docker-example",
+  "version": "1.0.0",
+  "description": "A minimal Node.js TypeScript application.",
+  "main": "dist/index.js",
+  "scripts": {
+    "build": "tsc",
+    "start": "node dist/index.js",
+    "dev": "tsx watch src/index.ts"
+  },
+  "dependencies": {
+    "express": "^4.21.2",
+    "pg": "^8.16.0"
+  },
+  "devDependencies": {
+    "@types/express": "^4.17.21",
+    "@types/node": "^22.0.0",
+    "@types/pg": "^8.11.0",
+    "tsx": "^4.19.3",
+    "typescript": "^5.8.3"
+  }
+}
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+### Update Docker assets
+
+Replace `Dockerfile` and `compose.yaml` with the following.
+
+{{< files name="nodejs-docker-example" >}}
+
+{{< file path="Dockerfile" status="modified" hl_lines="12,34,37,63" >}}
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Dockerfile reference guide at
+# https://docs.docker.com/go/dockerfile-reference/
+
+# This Dockerfile uses Docker Hardened Images (DHI) for enhanced security.
+# For more information, see https://docs.docker.com/dhi/
+
+# Development stage: install all dependencies, compile TypeScript, and
+# serve with hot-reload. Used directly in development via compose.yaml.
+FROM dhi.io/node:24-alpine3.23-dev AS dev
+
+WORKDIR /app
+
+# Install dependencies as a separate step to take advantage of Docker's
+# caching. Leverage a cache mount to /root/.npm to speed up subsequent
+# builds. Leverage a bind mount to package.json to avoid having to copy
+# it into this layer.
+RUN --mount=type=cache,target=/root/.npm \
+    --mount=type=bind,source=package.json,target=package.json \
+    npm install
+# Once you create a package-lock.json by running npm install locally, switch to npm ci and bind both files:
+# RUN --mount=type=cache,target=/root/.npm \
+#     --mount=type=bind,source=package.json,target=package.json \
+#     --mount=type=bind,source=package-lock.json,target=package-lock.json \
+#     npm ci
+
+# Copy the source code into the container and compile TypeScript.
+COPY . .
+RUN npm run build
+
+# Expose the port that the application listens on.
+EXPOSE 3000
+
+# Run the application in development mode.
+CMD ["npm", "run", "dev"]
+
+
+# Deps stage: install production dependencies only.
+FROM dhi.io/node:24-alpine3.23-dev AS deps
+
+WORKDIR /app
+
+RUN --mount=type=cache,target=/root/.npm \
+    --mount=type=bind,source=package.json,target=package.json \
+    npm install --omit=dev
+# Once you create a package-lock.json by running npm install locally, switch to npm ci and bind both files:
+# RUN --mount=type=cache,target=/root/.npm \
+#     --mount=type=bind,source=package.json,target=package.json \
+#     --mount=type=bind,source=package-lock.json,target=package-lock.json \
+#     npm ci --omit=dev
+
+
+# Runner stage: minimal runtime image with compiled app and production deps.
+FROM dhi.io/node:24-alpine3.23 AS runner
+
+ENV PATH=/app/node_modules/.bin:$PATH
+
+WORKDIR /app
+
+COPY --from=deps --chown=node:node /app/node_modules ./node_modules
+COPY --from=dev --chown=node:node /app/dist ./dist
+
+# Expose the port that the application listens on.
+EXPOSE 3000
+
+# Run the application.
+CMD ["node", "dist/index.js"]
+```
+
+{{< /file >}}
+
+{{< file path="compose.yaml" status="modified" hl_lines="8" >}}
+
+```yaml
+services:
+  # Application service. The `target: dev` line builds the development
+  # image (includes tsx and dev tooling); the runner stage of the
+  # Dockerfile is unused in development.
+  server:
+    build:
+      context: .
+      target: dev
+    ports:
+      - 3000:3000
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+#### About these changes
+
+The `builder` stage from containerize is renamed to `dev` and gains `EXPOSE 3000` and `CMD ["npm", "run", "dev"]`, which runs `tsx watch` for hot-reload. The `deps` and `runner` stages are unchanged.
+
+In `compose.yaml`, the new `target: dev` line tells Compose to build and run the `dev` stage during development. Unlike the production image, the development image includes `tsx` and other dev tooling. If you need a shell in a running production container, use [Docker Debug](/reference/cli/docker/debug/) instead.
+
+The build step runs `tsc`, which compiles each TypeScript file into a corresponding JavaScript file. [esbuild](https://esbuild.github.io/) is a popular alternative that bundles everything into a single output file and builds significantly faster. To switch, replace the `tsc` call in `package.json` with an esbuild command and update the `COPY --from=dev` path in the `runner` stage to match esbuild's output.
+
+### Add a local database and persist data
+
+You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service and a volume to persist data, and add a `db/password.txt` file that holds the database password.
+
+{{< files name="nodejs-docker-example" >}}
+
+{{< file path="compose.yaml" status="modified" hl_lines="11-46" >}}
+
+```yaml
+services:
+  # Application service. The `target: dev` line builds the development
+  # image (includes tsx and dev tooling); the runner stage of the
+  # Dockerfile is unused in development.
+  server:
+    build:
+      context: .
+      target: dev
+    ports:
+      - 3000:3000
+    environment:
+      - POSTGRES_SERVER=db
+      - POSTGRES_USER=postgres
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    depends_on:
+      db:
+        condition: service_healthy
+    secrets:
+      - db-password
+  # Database service. Reads the password from a Docker secret mounted at
+  # /run/secrets/db-password. Compose waits for the healthcheck to pass
+  # before starting the server, via the server's depends_on.
+  db:
+    image: dhi.io/postgres:18
+    restart: always
+    user: postgres
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    expose:
+      - 5432
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+{{< /file >}}
+
+{{< file path="db/password.txt" status="new" >}}
+
+```text
+mysecretpassword
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+> [!NOTE]
+>
+> To learn more about the instructions in the Compose file, see [Compose file
+> reference](/reference/compose-file/).
+
+Now, run the following `docker compose up` command to start your application.
+
+```console
+$ docker compose up --build
+```
+
+Now test your API endpoint. Open a new terminal and make a request to the server using the curl commands.
+
+Create an object with a POST request:
+
+```console
+$ curl -X 'POST' \
+  'http://localhost:3000/heroes/' \
+  -H 'accept: application/json' \
+  -H 'Content-Type: application/json' \
+  -d '{
+  "name": "my hero",
+  "secret_name": "austing",
+  "age": 12
+}'
+```
+
+You should receive the following response:
+
+```json
+{
+  "id": 1,
+  "name": "my hero",
+  "secret_name": "austing",
+  "age": 12
+}
+```
+
+Now make a GET request:
+
+```console
+$ curl http://localhost:3000/heroes/
+```
+
+You should receive the same response because it's the only object in the database.
+
+Press `ctrl`+`c` in the terminal to stop your application.
+
+### Automatically update services
+
+Use Compose Watch to automatically update your running Compose services as you edit and save your code. For more details about Compose Watch, see [Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
+
+Open your `compose.yaml` file in an IDE or text editor and add the highlighted Compose Watch instructions.
+
+{{< files name="nodejs-docker-example" >}}
+
+{{< file path="compose.yaml" status="modified" hl_lines="21-27" >}}
+
+```yaml
+services:
+  # Application service. The `target: dev` line builds the development
+  # image (includes tsx and dev tooling); the runner stage of the
+  # Dockerfile is unused in development.
+  server:
+    build:
+      context: .
+      target: dev
+    ports:
+      - 3000:3000
+    environment:
+      - POSTGRES_SERVER=db
+      - POSTGRES_USER=postgres
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    depends_on:
+      db:
+        condition: service_healthy
+    secrets:
+      - db-password
+    develop:
+      watch:
+        - action: sync
+          path: ./src
+          target: /app/src
+        - action: rebuild
+          path: package.json
+  db:
+    image: dhi.io/postgres:18
+    restart: always
+    user: postgres
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    expose:
+      - 5432
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+Run the following command to run your application with Compose Watch.
+
+```console
+$ docker compose watch
+```
+
+In a terminal, curl the application to get a response.
+
+```console
+$ curl http://localhost:3000
+{"message":"Hello World"}
+```
+
+Any changes to the application's source files on your local machine will now be immediately reflected in the running container.
+
+Open `nodejs-docker-example/src/index.ts` in an IDE or text editor and update the `Hello World` string by adding a few more exclamation marks.
+
+```diff
+-  res.json({ message: 'Hello World' });
++  res.json({ message: 'Hello World!!!' });
+```
+
+Save the changes to `src/index.ts` and then wait a few seconds for the application to reload. Curl the application again and verify that the updated text appears.
+
+```console
+$ curl http://localhost:3000
+{"message":"Hello World!!!"}
+```
+
+Press `ctrl`+`c` in the terminal to stop your application.
+
+### Debug your application
+
+`tsx watch` supports the Node.js inspector protocol, so you can attach a debugger from VS Code or Chrome DevTools and set breakpoints directly in your TypeScript source files.
+
+Update the `dev` script in `package.json` to start the inspector. The `--inspect=0.0.0.0:9229` flag tells Node.js to listen for debugger connections on all network interfaces at port 9229. Using `0.0.0.0` rather than `localhost` is necessary so the debugger is reachable from outside the container. Also expose the debug port in `compose.yaml`, and add a `.vscode/launch.json` file that tells VS Code how to attach to the running inspector.
+
+{{< files name="nodejs-docker-example" >}}
+
+{{< file path="package.json" status="modified" hl_lines="9" >}}
+
+```json
+{
+  "name": "nodejs-docker-example",
+  "version": "1.0.0",
+  "description": "A minimal Node.js TypeScript application.",
+  "main": "dist/index.js",
+  "scripts": {
+    "build": "tsc",
+    "start": "node dist/index.js",
+    "dev": "tsx watch --inspect=0.0.0.0:9229 src/index.ts"
+  },
+  "dependencies": {
+    "express": "^4.21.2",
+    "pg": "^8.16.0"
+  },
+  "devDependencies": {
+    "@types/express": "^4.17.21",
+    "@types/node": "^22.0.0",
+    "@types/pg": "^8.11.0",
+    "tsx": "^4.19.3",
+    "typescript": "^5.8.3"
+  }
+}
+```
+
+{{< /file >}}
+
+{{< file path=".vscode/launch.json" status="new" >}}
+
+```json
+{
+  "version": "0.2.0",
+  "configurations": [
+    {
+      "name": "Attach to Docker Container",
+      "type": "node",
+      "request": "attach",
+      "port": 9229,
+      "address": "localhost",
+      "localRoot": "${workspaceFolder}",
+      "remoteRoot": "/app",
+      "protocol": "inspector",
+      "restart": true,
+      "sourceMaps": true,
+      "skipFiles": ["<node_internals>/**"]
+    }
+  ]
+}
+```
+
+{{< /file >}}
+
+{{< file path="compose.yaml" status="modified" hl_lines="11" >}}
+
+```yaml
+services:
+  # Application service. The `target: dev` line builds the development
+  # image (includes tsx and dev tooling); the runner stage of the
+  # Dockerfile is unused in development.
+  server:
+    build:
+      context: .
+      target: dev
+    ports:
+      - 3000:3000
+      - 9229:9229
+    environment:
+      - POSTGRES_SERVER=db
+      - POSTGRES_USER=postgres
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    depends_on:
+      db:
+        condition: service_healthy
+    secrets:
+      - db-password
+    develop:
+      watch:
+        - action: sync
+          path: ./src
+          target: /app/src
+        - action: rebuild
+          path: package.json
+  db:
+    image: dhi.io/postgres:18
+    restart: always
+    user: postgres
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    expose:
+      - 5432
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+Rebuild and restart with the updated configuration:
+
+```console
+$ docker compose up --build
+```
+
+When the inspector is ready, you'll see a line like the following in the logs:
+
+```text
+Debugger listening on ws://0.0.0.0:9229/...
+```
+
+#### VS Code
+
+With `.vscode/launch.json` in place, attach the debugger using the Debug panel.
+
+Open the Debug panel (`Ctrl+Shift+D` on Windows and Linux, `Cmd+Shift+D` on Mac), select **Attach to Docker Container**, and press `F5`. You can now set breakpoints in your TypeScript source files under `src/`.
+
+#### Chrome DevTools
+
+You can also use the built-in Node.js inspector in Chrome without any editor setup.
+
+1. Open Chrome and go to `chrome://inspect`.
+
+2. Select **Configure** and add `localhost:9229`.
+
+3. When your Node.js target appears in the list, select **inspect**.
+
+#### Troubleshoot the debugger
+
+If the debugger doesn't connect, verify the container is running and the port is mapped correctly:
+
+```console
+$ docker compose ps
+$ docker compose logs server
+```
+
+The logs should include a line like:
+
+```text
+Debugger listening on ws://0.0.0.0:9229/...
+```
+
+If that line is missing, confirm the `dev` script in `package.json` includes `--inspect=0.0.0.0:9229` and that `9229:9229` appears in the `ports` list for the `server` service in `compose.yaml`.
+
+For more details about Node.js debugging, see the [Node.js debugging guide](https://nodejs.org/en/docs/guides/debugging-getting-started).
+
+## Run Node.js tests in a container
+
+### Prerequisites
+
+Complete all the previous sections of this guide, starting with [Containerize a Node.js application](#containerize-a-nodejs-application).
+
+### Overview
+
+Testing is a core part of building reliable software. Docker makes it easy to
+run your tests in the same environment used in CI and production, so failures
+are caught before they reach your users.
+
+In this section, you'll add [Vitest](https://vitest.dev/) to the project and
+run tests both locally and inside a container.
+
+### Update the application
+
+You'll refactor `src/index.ts` to export the Express `app` instance so tests
+can import it without starting a server. Add a test file and update
+`package.json` to add Vitest and a test runner for HTTP requests. The file browser shows only the files that change in this step.
+
+{{< files name="nodejs-docker-example" >}}
+
+{{< file path="src/index.ts" status="modified" hl_lines="10,31,70-75" >}}
+
+```typescript
+// Express application backed by a PostgreSQL database.
+// Creates a heroes table at startup.
+// Endpoints: GET / (greeting), GET /health (health check), POST /heroes/ (create), GET /heroes/ (list).
+// See https://expressjs.com/ and https://node-postgres.com/
+
+import express, { type Request, type Response } from "express";
+import { Pool } from "pg";
+import { readFileSync } from "fs";
+
+export const app = express();
+const port = parseInt(process.env.PORT ?? "3000", 10);
+
+app.use(express.json());
+
+function getPassword(): string {
+  const passwordFile = process.env.POSTGRES_PASSWORD_FILE;
+  if (passwordFile) {
+    return readFileSync(passwordFile, "utf8").trim();
+  }
+  return process.env.POSTGRES_PASSWORD ?? "";
+}
+
+const pool = new Pool({
+  host: process.env.POSTGRES_SERVER,
+  port: 5432,
+  database: process.env.POSTGRES_DB,
+  user: process.env.POSTGRES_USER,
+  password: getPassword(),
+});
+
+if (process.env.POSTGRES_SERVER) {
+  pool
+    .query(
+      `CREATE TABLE IF NOT EXISTS heroes (
+        id SERIAL PRIMARY KEY,
+        name TEXT NOT NULL,
+        secret_name TEXT NOT NULL,
+        age INTEGER
+      )`,
+    )
+    .catch(console.error);
+}
+
+app.get("/", (_req: Request, res: Response) => {
+  res.json({ message: "Hello World" });
+});
+
+app.get("/health", (_req: Request, res: Response) => {
+  res.json({ status: "ok" });
+});
+
+app.post("/heroes/", async (req: Request, res: Response) => {
+  const { name, secret_name, age } = req.body as {
+    name: string;
+    secret_name: string;
+    age?: number;
+  };
+  const result = await pool.query(
+    "INSERT INTO heroes (name, secret_name, age) VALUES ($1, $2, $3) RETURNING *",
+    [name, secret_name, age],
+  );
+  res.json(result.rows[0]);
+});
+
+app.get("/heroes/", async (_req: Request, res: Response) => {
+  const result = await pool.query("SELECT * FROM heroes");
+  res.json(result.rows);
+});
+
+// Only start the server when this file is run directly.
+if (require.main === module) {
+  app.listen(port, () => {
+    console.log(`Server listening on port ${port}`);
+  });
+}
+```
+
+{{< /file >}}
+
+{{< file path="src/index.test.ts" status="new" >}}
+
+```typescript
+// Unit tests for the Express application.
+// Tests the root endpoint without starting a server.
+// See https://vitest.dev/ for the test framework reference.
+
+import { describe, it, expect } from "vitest";
+import request from "supertest";
+import { app } from "./index";
+
+describe("GET /", () => {
+  it("returns a JSON greeting", async () => {
+    const response = await request(app).get("/");
+    expect(response.status).toBe(200);
+    expect(response.body).toEqual({ message: "Hello World" });
+  });
+});
+```
+
+{{< /file >}}
+
+{{< file path="package.json" status="modified" hl_lines="10,20-22" >}}
+
+```json
+{
+  "name": "nodejs-docker-example",
+  "version": "1.0.0",
+  "description": "A minimal Node.js TypeScript application.",
+  "main": "dist/index.js",
+  "scripts": {
+    "build": "tsc",
+    "start": "node dist/index.js",
+    "dev": "tsx watch src/index.ts",
+    "test": "vitest run"
+  },
+  "dependencies": {
+    "express": "^4.21.2",
+    "pg": "^8.16.0"
+  },
+  "devDependencies": {
+    "@types/express": "^4.17.21",
+    "@types/node": "^22.0.0",
+    "@types/pg": "^8.11.0",
+    "supertest": "^7.0.0",
+    "@types/supertest": "^6.0.0",
+    "tsx": "^4.19.3",
+    "typescript": "^5.8.3",
+    "vitest": "^3.0.0"
+  }
+}
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+### Run tests locally
+
+Run the following command to run the tests locally:
+
+```console
+$ npm install
+$ npm test
+```
+
+You should see output like the following:
+
+```console
+ RUN  v3.0.0 /app
+
+ ✓ src/index.test.ts (1)
+   ✓ GET / (1)
+     ✓ returns a JSON greeting
+
+ Test Files  1 passed (1)
+      Tests  1 passed (1)
+   Start at  12:00:00
+   Duration  500ms
+```
+
+### Run tests in a container
+
+Run the tests using the dev stage of your Dockerfile:
+
+```console
+$ docker compose run --build --rm --no-deps server npm test
+```
+
+The `--no-deps` flag skips starting the database, since the unit tests don't require it. The `--rm` flag removes the container when the tests finish.
+
+You should see the same test output as when running locally.
+
+### Run tests when building
+
+To run tests during the Docker build process, add a `test` stage to your Dockerfile that runs after the dev stage.
+
+```dockerfile {hl_lines="32-36"}
+FROM dhi.io/node:24-alpine3.23-dev AS dev
+
+WORKDIR /app
+
+RUN --mount=type=cache,target=/root/.npm \
+    --mount=type=bind,source=package.json,target=package.json \
+    npm install
+
+COPY . .
+RUN npm run build
+
+EXPOSE 3000
+CMD ["npm", "run", "dev"]
+
+
+FROM dhi.io/node:24-alpine3.23-dev AS deps
+WORKDIR /app
+RUN --mount=type=cache,target=/root/.npm \
+    --mount=type=bind,source=package.json,target=package.json \
+    npm install --omit=dev
+
+FROM dhi.io/node:24-alpine3.23 AS runner
+ENV PATH=/app/node_modules/.bin:$PATH
+WORKDIR /app
+COPY --from=deps --chown=node:node /app/node_modules ./node_modules
+COPY --from=dev --chown=node:node /app/dist ./dist
+
+EXPOSE 3000
+CMD ["node", "dist/index.js"]
+
+
+FROM dev AS test
+
+ENV CI=true
+
+CMD ["npm", "test"]
+```
+
+Then build and run the test stage:
+
+```console
+$ docker build --target test -t nodejs-app-test .
+$ docker run --rm nodejs-app-test
+```
+
+### Summary
+
+In this section, you learned how to run tests when developing locally and inside a container.
+
+Related information:
+
+- [Dockerfile reference](/reference/dockerfile/)
+- [Compose file reference](/compose/compose-file/)
+- [`docker compose run` CLI reference](/reference/cli/docker/compose/run/)
diff --git a/content/guides/nodejs/_index.md b/content/guides/nodejs/_index.md
deleted file mode 100644
index b7f04877a088..000000000000
--- a/content/guides/nodejs/_index.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Node.js language-specific guide
-linkTitle: Node.js
-description: Containerize and develop Node.js apps using Docker
-keywords: getting started, node, node.js
-summary: |
-  This guide explains how to containerize Node.js applications using Docker.
-toc_min: 1
-toc_max: 2
-aliases:
-  - /language/nodejs/
-  - /guides/language/nodejs/
-languages: [js]
-params:
-  time: 20 minutes
----
-
-The Node.js language-specific guide teaches you how to containerize a Node.js application using Docker. In this guide, you’ll learn how to:
-
-- Containerize and run a Node.js application
-- Set up a local environment to develop a Node.js application using containers
-- Run tests for a Node.js application using containers
-- Configure a CI/CD pipeline for a containerized Node.js application using GitHub Actions
-- Deploy your containerized Node.js application locally to Kubernetes to test and debug your deployment
-
-Start by containerizing an existing Node.js application.
diff --git a/content/guides/nodejs/configure-ci-cd.md b/content/guides/nodejs/configure-ci-cd.md
deleted file mode 100644
index 8e8218b813f1..000000000000
--- a/content/guides/nodejs/configure-ci-cd.md
+++ /dev/null
@@ -1,140 +0,0 @@
----
-title: Configure CI/CD for your Node.js application
-linkTitle: Configure CI/CD
-weight: 40
-keywords: ci/cd, github actions, node.js, node
-description: Learn how to configure CI/CD using GitHub Actions for your Node.js application.
-aliases:
-  - /language/nodejs/configure-ci-cd/
-  - /guides/language/nodejs/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a Node.js application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-## Overview
-
-In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps:
-
-1. Create a new repository on GitHub.
-2. Define the GitHub Actions workflow.
-3. Run the workflow.
-
-## Step one: Create the repository
-
-Create a GitHub repository, configure the Docker Hub credentials, and push your source code.
-
-1. [Create a new repository](https://github.com/new) on GitHub.
-
-2. Open the repository **Settings**, and go to **Secrets and variables** >
-   **Actions**.
-
-3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-4. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-5. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-6. In your local repository on your machine, run the following command to change
-   the origin to the repository you just created. Make sure you change
-   `your-username` to your GitHub username and `your-repository` to the name of
-   the repository you created.
-
-   ```console
-   $ git remote set-url origin https://github.com/your-username/your-repository.git
-   ```
-
-7. Run the following commands to stage, commit, and push your local repository to GitHub.
-
-   ```console
-   $ git add -A
-   $ git commit -m "my commit"
-   $ git push -u origin main
-   ```
-
-## Step two: Set up the workflow
-
-Set up your GitHub Actions workflow for building, testing, and pushing the image
-to Docker Hub.
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-
-2. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub actions workflow file in
-   your repository, under `.github/workflows/main.yml` by default.
-
-3. In the editor window, copy and paste the following YAML configuration.
-
-   ```yaml
-   name: ci
-
-   on:
-     push:
-       branches:
-         - main
-
-   jobs:
-     build:
-       runs-on: ubuntu-latest
-       steps:
-         - name: Login to Docker Hub
-           uses: docker/login-action@v3
-           with:
-             username: ${{ vars.DOCKER_USERNAME }}
-             password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-         - name: Set up Docker Buildx
-           uses: docker/setup-buildx-action@v3
-
-         - name: Build and test
-           uses: docker/build-push-action@v6
-           with:
-             target: test
-             load: true
-
-         - name: Build and push
-           uses: docker/build-push-action@v6
-           with:
-             platforms: linux/amd64,linux/arm64
-             push: true
-             target: prod
-             tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-   ```
-
-   For more information about the YAML syntax for `docker/build-push-action`,
-   refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
-## Step three: Run the workflow
-
-Save the workflow file and run the job.
-
-1. Select **Commit changes...** and push the changes to the `main` branch.
-
-   After pushing the commit, the workflow starts automatically.
-
-2. Go to the **Actions** tab. It displays the workflow.
-
-   Selecting the workflow shows you the breakdown of all the steps.
-
-3. When the workflow is complete, go to your
-   [repositories on Docker Hub](https://hub.docker.com/repositories).
-
-   If you see the new repository in that list, it means the GitHub Actions
-   successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your Node.js application.
-
-Related information:
-
-- [Introduction to GitHub Actions](/guides/gha.md)
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md)
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-Next, learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/nodejs/containerize.md b/content/guides/nodejs/containerize.md
deleted file mode 100644
index 0f54039de933..000000000000
--- a/content/guides/nodejs/containerize.md
+++ /dev/null
@@ -1,287 +0,0 @@
----
-title: Containerize a Node.js application
-linkTitle: Containerize your app
-weight: 10
-keywords: node.js, node, containerize, initialize
-description: Learn how to containerize a Node.js application.
-aliases:
-  - /get-started/nodejs/build-images/
-  - /language/nodejs/build-images/
-  - /language/nodejs/run-containers/
-  - /language/nodejs/containerize/
-  - /guides/language/nodejs/containerize/
----
-
-## Prerequisites
-
-- You have installed the latest version of [Docker
-  Desktop](/get-started/get-docker.md).
-- You have a [git client](https://git-scm.com/downloads). The examples in this
-  section use a command-line based git client, but you can use any client.
-
-## Overview
-
-This section walks you through containerizing and running a Node.js
-application.
-
-## Get the sample application
-
-Clone the sample application to use with this guide. Open a terminal, change
-directory to a directory that you want to work in, and run the following command
-to clone the repository:
-
-```console
-$ git clone https://github.com/docker/docker-nodejs-sample && cd docker-nodejs-sample
-```
-
-## Initialize Docker assets
-
-Now that you have an application, you can create the necessary Docker assets to
-containerize your application. You can use Docker Desktop's built-in Docker Init
-feature to help streamline the process, or you can manually create the assets.
-
-{{< tabs >}}
-{{< tab name="Use Docker Init" >}}
-
-Inside the `docker-nodejs-sample` directory, run
-the `docker init` command in a terminal. `docker init` provides some default
-configuration, but you'll need to answer a few questions about your application.
-Refer to the following example to answer the prompts from `docker init` and use
-the same answers for your prompts.
-
-```console
-$ docker init
-Welcome to the Docker Init CLI!
-
-This utility will walk you through creating the following files with sensible defaults for your project:
-  - .dockerignore
-  - Dockerfile
-  - compose.yaml
-  - README.Docker.md
-
-Let's get started!
-
-? What application platform does your project use? Node
-? What version of Node do you want to use? 18.0.0
-? Which package manager do you want to use? npm
-? What command do you want to use to start the app: node src/index.js
-? What port does your server listen on? 3000
-```
-
-{{< /tab >}}
-{{< tab name="Manually create assets" >}}
-
-If you don't have Docker Desktop installed or prefer creating the assets manually, you can create the following files in your project directory.
-
-Create a file named `Dockerfile` with the following contents.
-
-```dockerfile {collapse=true,title=Dockerfile}
-# syntax=docker/dockerfile:1
-
-# Comments are provided throughout this file to help you get started.
-# If you need more help, visit the Dockerfile reference guide at
-# https://docs.docker.com/go/dockerfile-reference/
-
-# Want to help us make this template better? Share your feedback here: https://forms.gle/ybq9Krt8jtBL3iCk7
-
-ARG NODE_VERSION=18.0.0
-
-FROM node:${NODE_VERSION}-alpine
-
-# Use production node environment by default.
-ENV NODE_ENV production
-
-
-WORKDIR /usr/src/app
-
-# Download dependencies as a separate step to take advantage of Docker's caching.
-# Leverage a cache mount to /root/.npm to speed up subsequent builds.
-# Leverage a bind mounts to package.json and package-lock.json to avoid having to copy them into
-# into this layer.
-RUN --mount=type=bind,source=package.json,target=package.json \
-    --mount=type=bind,source=package-lock.json,target=package-lock.json \
-    --mount=type=cache,target=/root/.npm \
-    npm ci --omit=dev
-
-# Run the application as a non-root user.
-USER node
-
-# Copy the rest of the source files into the image.
-COPY . .
-
-# Expose the port that the application listens on.
-EXPOSE 3000
-
-# Run the application.
-CMD node src/index.js
-```
-
-Create a file named `compose.yaml` with the following contents.
-
-```yaml {collapse=true,title=compose.yaml}
-# Comments are provided throughout this file to help you get started.
-# If you need more help, visit the Docker Compose reference guide at
-# https://docs.docker.com/go/compose-spec-reference/
-
-# Here the instructions define your application as a service called "server".
-# This service is built from the Dockerfile in the current directory.
-# You can add other services your application may depend on here, such as a
-# database or a cache. For examples, see the Awesome Compose repository:
-# https://github.com/docker/awesome-compose
-services:
-  server:
-    build:
-      context: .
-    environment:
-      NODE_ENV: production
-    ports:
-      - 3000:3000
-# The commented out section below is an example of how to define a PostgreSQL
-# database that your application can use. `depends_on` tells Docker Compose to
-# start the database before your application. The `db-data` volume persists the
-# database data between container restarts. The `db-password` secret is used
-# to set the database password. You must create `db/password.txt` and add
-# a password of your choosing to it before running `docker compose up`.
-#     depends_on:
-#       db:
-#         condition: service_healthy
-#   db:
-#     image: postgres
-#     restart: always
-#     user: postgres
-#     secrets:
-#       - db-password
-#     volumes:
-#       - db-data:/var/lib/postgresql/data
-#     environment:
-#       - POSTGRES_DB=example
-#       - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-#     expose:
-#       - 5432
-#     healthcheck:
-#       test: [ "CMD", "pg_isready" ]
-#       interval: 10s
-#       timeout: 5s
-#       retries: 5
-# volumes:
-#   db-data:
-# secrets:
-#   db-password:
-#     file: db/password.txt
-```
-
-Create a file named `.dockerignore` with the following contents.
-
-```text {collapse=true,title=".dockerignore"}
-# Include any files or directories that you don't want to be copied to your
-# container here (e.g., local build artifacts, temporary files, etc.).
-#
-# For more help, visit the .dockerignore file reference guide at
-# https://docs.docker.com/go/build-context-dockerignore/
-
-**/.classpath
-**/.dockerignore
-**/.env
-**/.git
-**/.gitignore
-**/.project
-**/.settings
-**/.toolstarget
-**/.vs
-**/.vscode
-**/.next
-**/.cache
-**/*.*proj.user
-**/*.dbmdl
-**/*.jfm
-**/charts
-**/docker-compose*
-**/compose.y*ml
-**/Dockerfile*
-**/node_modules
-**/npm-debug.log
-**/obj
-**/secrets.dev.yaml
-**/values.dev.yaml
-**/build
-**/dist
-LICENSE
-README.md
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-You should now have at least the following contents in your
-`docker-nodejs-sample` directory.
-
-```text
-├── docker-nodejs-sample/
-│ ├── spec/
-│ ├── src/
-│ ├── .dockerignore
-│ ├── .gitignore
-│ ├── compose.yaml
-│ ├── Dockerfile
-│ ├── package-lock.json
-│ ├── package.json
-│ └── README.md
-```
-
-To learn more about the files, see the following:
-
-- [Dockerfile](/reference/dockerfile.md)
-- [.dockerignore](/reference/dockerfile.md#dockerignore-file)
-- [compose.yaml](/reference/compose-file/_index.md)
-
-## Run the application
-
-Inside the `docker-nodejs-sample` directory, run the following command in a
-terminal.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:3000](http://localhost:3000). You should see a simple todo application.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-### Run the application in the background
-
-You can run the application detached from the terminal by adding the `-d`
-option. Inside the `docker-nodejs-sample` directory, run the following command
-in a terminal.
-
-```console
-$ docker compose up --build -d
-```
-
-Open a browser and view the application at [http://localhost:3000](http://localhost:3000).
-
-You should see a simple todo application.
-
-In the terminal, run the following command to stop the application.
-
-```console
-$ docker compose down
-```
-
-For more information about Compose commands, see the [Compose CLI
-reference](/reference/cli/docker/compose/_index.md).
-
-## Summary
-
-In this section, you learned how you can containerize and run your Node.js
-application using Docker.
-
-Related information:
-
-- [Dockerfile reference](/reference/dockerfile.md)
-- [.dockerignore file reference](/reference/dockerfile.md#dockerignore-file)
-- [Docker Compose overview](/manuals/compose/_index.md)
-
-## Next steps
-
-In the next section, you'll learn how you can develop your application using
-containers.
diff --git a/content/guides/nodejs/deploy.md b/content/guides/nodejs/deploy.md
deleted file mode 100644
index 5c6ca2960b8d..000000000000
--- a/content/guides/nodejs/deploy.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title: Test your Node.js deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, kubernetes, node, node.js
-description: Learn how to deploy locally to test and debug your Kubernetes deployment
-aliases:
-  - /language/nodejs/deploy/
-  - /guides/language/nodejs/deploy/
----
-
-## Prerequisites
-
-- Complete all the previous sections of this guide, starting with [Containerize a Node.js application](containerize.md).
-- [Turn on Kubernetes](/manuals/desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your
-application to a fully-featured Kubernetes environment on your development
-machine. This allows you to test and debug your workloads on Kubernetes locally
-before deploying.
-
-## Create a Kubernetes YAML file
-
-In the cloned repository's directory, create a file named
-`docker-node-kubernetes.yaml`. Open the file in an IDE or text editor and add
-the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker
-username and the name of the repository that you created in [Configure CI/CD for
-your Node.js application](configure-ci-cd.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: docker-nodejs-demo
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      todo: web
-  template:
-    metadata:
-      labels:
-        todo: web
-    spec:
-      containers:
-        - name: todo-site
-          image: DOCKER_USERNAME/REPO_NAME
-          imagePullPolicy: Always
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: todo-entrypoint
-  namespace: default
-spec:
-  type: NodePort
-  selector:
-    todo: web
-  ports:
-    - port: 3000
-      targetPort: 3000
-      nodePort: 30001
-```
-
-In this Kubernetes YAML file, there are two objects, separated by the `---`:
-
-- A Deployment, describing a scalable group of identical pods. In this case,
-  you'll get just one replica, or copy of your pod. That pod, which is
-  described under `template`, has just one container in it. The container is
-  created from the image built by GitHub Actions in [Configure CI/CD for your
-  Node.js application](configure-ci-cd.md).
-- A NodePort service, which will route traffic from port 30001 on your host to
-  port 3000 inside the pods it routes to, allowing you to reach your app
-  from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to where you created `docker-node-kubernetes.yaml`
-   and deploy your application to Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-node-kubernetes.yaml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```shell
-   deployment.apps/docker-nodejs-demo created
-   service/todo-entrypoint created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```shell
-   NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
-   docker-nodejs-demo   1/1     1            1           6s
-   ```
-
-   This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```shell
-   NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
-   kubernetes        ClusterIP   10.96.0.1        <none>        443/TCP          7d22h
-   todo-entrypoint   NodePort    10.111.101.229   <none>        3000:30001/TCP   33s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `todo-entrypoint` service, accepting traffic on port 30001/TCP.
-
-3. Open a browser and visit your app at `localhost:30001`. You should see your
-   application.
-
-4. Run the following command to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-node-kubernetes.yaml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine.
-
-Related information:
-
-- [Kubernetes documentation](https://kubernetes.io/docs/home/)
-- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-- [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/nodejs/develop.md b/content/guides/nodejs/develop.md
deleted file mode 100644
index 0e892375182c..000000000000
--- a/content/guides/nodejs/develop.md
+++ /dev/null
@@ -1,431 +0,0 @@
----
-title: Use containers for Node.js development
-linkTitle: Develop your app
-weight: 20
-keywords: node, node.js, development
-description: Learn how to develop your Node.js application locally using containers.
-aliases:
-  - /get-started/nodejs/develop/
-  - /language/nodejs/develop/
-  - /guides/language/nodejs/develop/
----
-
-## Prerequisites
-
-Complete [Containerize a Node.js application](containerize.md).
-
-## Overview
-
-In this section, you'll learn how to set up a development environment for your containerized application. This includes:
-
-- Adding a local database and persisting data
-- Configuring your container to run a development environment
-- Debugging your containerized application
-
-## Add a local database and persist data
-
-You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service and a volume to persist data.
-
-1. Open your `compose.yaml` file in an IDE or text editor.
-2. Uncomment the database related instructions. The following is the updated
-   `compose.yaml` file.
-
-   > [!IMPORTANT]
-   >
-   > For this section, don't run `docker compose up` until you are instructed to. Running the command at intermediate points may incorrectly initialize your database.
-
-   ```yaml {hl_lines="26-51",collapse=true,title=compose.yaml}
-   # Comments are provided throughout this file to help you get started.
-   # If you need more help, visit the Docker Compose reference guide at
-   # https://docs.docker.com/go/compose-spec-reference/
-
-   # Here the instructions define your application as a service called "server".
-   # This service is built from the Dockerfile in the current directory.
-   # You can add other services your application may depend on here, such as a
-   # database or a cache. For examples, see the Awesome Compose repository:
-   # https://github.com/docker/awesome-compose
-   services:
-     server:
-       build:
-         context: .
-       environment:
-         NODE_ENV: production
-       ports:
-         - 3000:3000
-
-       # The commented out section below is an example of how to define a PostgreSQL
-       # database that your application can use. `depends_on` tells Docker Compose to
-       # start the database before your application. The `db-data` volume persists the
-       # database data between container restarts. The `db-password` secret is used
-       # to set the database password. You must create `db/password.txt` and add
-       # a password of your choosing to it before running `docker compose up`.
-
-       depends_on:
-         db:
-           condition: service_healthy
-     db:
-       image: postgres
-       restart: always
-       user: postgres
-       secrets:
-         - db-password
-       volumes:
-         - db-data:/var/lib/postgresql/data
-       environment:
-         - POSTGRES_DB=example
-         - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-       expose:
-         - 5432
-       healthcheck:
-         test: ["CMD", "pg_isready"]
-         interval: 10s
-         timeout: 5s
-         retries: 5
-   volumes:
-     db-data:
-   secrets:
-     db-password:
-       file: db/password.txt
-   ```
-
-   > [!NOTE]
-   >
-   > To learn more about the instructions in the Compose file, see [Compose file
-   > reference](/reference/compose-file/).
-
-3. Open `src/persistence/postgres.js` in an IDE or text editor. You'll notice
-   that this application uses a Postgres database and requires some environment
-   variables in order to connect to the database. The `compose.yaml` file doesn't
-   have these variables defined yet.
-4. Add the environment variables that specify the database configuration. The
-   following is the updated `compose.yaml` file.
-
-   ```yaml {hl_lines="16-19",collapse=true,title=compose.yaml}
-   # Comments are provided throughout this file to help you get started.
-   # If you need more help, visit the Docker Compose reference guide at
-   # https://docs.docker.com/go/compose-spec-reference/
-
-   # Here the instructions define your application as a service called "server".
-   # This service is built from the Dockerfile in the current directory.
-   # You can add other services your application may depend on here, such as a
-   # database or a cache. For examples, see the Awesome Compose repository:
-   # https://github.com/docker/awesome-compose
-   services:
-     server:
-       build:
-         context: .
-       environment:
-         NODE_ENV: production
-         POSTGRES_HOST: db
-         POSTGRES_USER: postgres
-         POSTGRES_PASSWORD_FILE: /run/secrets/db-password
-         POSTGRES_DB: example
-       ports:
-         - 3000:3000
-
-       # The commented out section below is an example of how to define a PostgreSQL
-       # database that your application can use. `depends_on` tells Docker Compose to
-       # start the database before your application. The `db-data` volume persists the
-       # database data between container restarts. The `db-password` secret is used
-       # to set the database password. You must create `db/password.txt` and add
-       # a password of your choosing to it before running `docker compose up`.
-
-       depends_on:
-         db:
-           condition: service_healthy
-     db:
-       image: postgres
-       restart: always
-       user: postgres
-       secrets:
-         - db-password
-       volumes:
-         - db-data:/var/lib/postgresql/data
-       environment:
-         - POSTGRES_DB=example
-         - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-       expose:
-         - 5432
-       healthcheck:
-         test: ["CMD", "pg_isready"]
-         interval: 10s
-         timeout: 5s
-         retries: 5
-   volumes:
-     db-data:
-   secrets:
-     db-password:
-       file: db/password.txt
-   ```
-
-5. Add the `secrets` section under the `server` service so that your application securely handles the database password. The following is the updated `compose.yaml` file.
-
-   ```yaml {hl_lines="33-34",collapse=true,title=compose.yaml}
-   # Comments are provided throughout this file to help you get started.
-   # If you need more help, visit the Docker Compose reference guide at
-   # https://docs.docker.com/go/compose-spec-reference/
-
-   # Here the instructions define your application as a service called "server".
-   # This service is built from the Dockerfile in the current directory.
-   # You can add other services your application may depend on here, such as a
-   # database or a cache. For examples, see the Awesome Compose repository:
-   # https://github.com/docker/awesome-compose
-   services:
-     server:
-       build:
-         context: .
-       environment:
-         NODE_ENV: production
-         POSTGRES_HOST: db
-         POSTGRES_USER: postgres
-         POSTGRES_PASSWORD_FILE: /run/secrets/db-password
-         POSTGRES_DB: example
-       ports:
-         - 3000:3000
-
-       # The commented out section below is an example of how to define a PostgreSQL
-       # database that your application can use. `depends_on` tells Docker Compose to
-       # start the database before your application. The `db-data` volume persists the
-       # database data between container restarts. The `db-password` secret is used
-       # to set the database password. You must create `db/password.txt` and add
-       # a password of your choosing to it before running `docker compose up`.
-
-       depends_on:
-         db:
-           condition: service_healthy
-       secrets:
-         - db-password
-     db:
-       image: postgres
-       restart: always
-       user: postgres
-       secrets:
-         - db-password
-       volumes:
-         - db-data:/var/lib/postgresql/data
-       environment:
-         - POSTGRES_DB=example
-         - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-       expose:
-         - 5432
-       healthcheck:
-         test: ["CMD", "pg_isready"]
-         interval: 10s
-         timeout: 5s
-         retries: 5
-   volumes:
-     db-data:
-   secrets:
-     db-password:
-       file: db/password.txt
-   ```
-
-6. In the `docker-nodejs-sample` directory, create a directory named `db`.
-7. In the `db` directory, create a file named `password.txt`. This file will
-   contain your database password.
-
-   You should now have at least the following contents in your
-   `docker-nodejs-sample` directory.
-
-   ```text
-   ├── docker-nodejs-sample/
-   │ ├── db/
-   │ │ └── password.txt
-   │ ├── spec/
-   │ ├── src/
-   │ ├── .dockerignore
-   │ ├── .gitignore
-   │ ├── compose.yaml
-   │ ├── Dockerfile
-   │ ├── package-lock.json
-   │ ├── package.json
-   │ └── README.md
-   ```
-
-8. Open the `password.txt` file in an IDE or text editor, and specify a password
-   of your choice. Your password must be on a single line with no additional
-   lines. Ensure that the file doesn't contain any newline characters or other
-   hidden characters.
-9. Ensure that you save your changes to all the files that you have modified.
-10. Run the following command to start your application.
-
-    ```console
-    $ docker compose up --build
-    ```
-
-11. Open a browser and verify that the application is running at
-    [http://localhost:3000](http://localhost:3000).
-12. Add some items to the todo list to test data persistence.
-13. After adding some items to the todo list, press `ctrl+c` in the terminal to
-    stop your application.
-14. In the terminal, run `docker compose rm` to remove your containers.
-
-    ```console
-    $ docker compose rm
-    ```
-
-15. Run `docker compose up` to run your application again.
-
-    ```console
-    $ docker compose up --build
-    ```
-
-16. Refresh [http://localhost:3000](http://localhost:3000) in your browser and verify that the todo items persisted, even after the containers were removed and ran again.
-
-## Configure and run a development container
-
-You can use a bind mount to mount your source code into the container. The container can then see the changes you make to the code immediately, as soon as you save a file. This means that you can run processes, like nodemon, in the container that watch for filesystem changes and respond to them. To learn more about bind mounts, see [Storage overview](/manuals/engine/storage/_index.md).
-
-In addition to adding a bind mount, you can configure your Dockerfile and `compose.yaml` file to install development dependencies and run development tools.
-
-### Update your Dockerfile for development
-
-Open the Dockerfile in an IDE or text editor. Note that the Dockerfile doesn't
-install development dependencies and doesn't run nodemon. You'll
-need to update your Dockerfile to install the development dependencies and run
-nodemon.
-
-Rather than creating one Dockerfile for production, and another Dockerfile for
-development, you can use one multi-stage Dockerfile for both.
-
-Update your Dockerfile to the following multi-stage Dockerfile.
-
-```dockerfile {hl_lines="5-26",collapse=true,title=Dockerfile}
-# syntax=docker/dockerfile:1
-
-ARG NODE_VERSION=18.0.0
-
-FROM node:${NODE_VERSION}-alpine as base
-WORKDIR /usr/src/app
-EXPOSE 3000
-
-FROM base as dev
-RUN --mount=type=bind,source=package.json,target=package.json \
-    --mount=type=bind,source=package-lock.json,target=package-lock.json \
-    --mount=type=cache,target=/root/.npm \
-    npm ci --include=dev
-USER node
-COPY . .
-CMD npm run dev
-
-FROM base as prod
-RUN --mount=type=bind,source=package.json,target=package.json \
-    --mount=type=bind,source=package-lock.json,target=package-lock.json \
-    --mount=type=cache,target=/root/.npm \
-    npm ci --omit=dev
-USER node
-COPY . .
-CMD node src/index.js
-```
-
-In the Dockerfile, you first add a label `as base` to the `FROM
-node:${NODE_VERSION}-alpine` statement. This lets you refer to this build stage
-in other build stages. Next, you add a new build stage labeled `dev` to install
-your development dependencies and start the container using `npm run dev`.
-Finally, you add a stage labeled `prod` that omits the dev dependencies and runs
-your application using `node src/index.js`. To learn more about multi-stage
-builds, see [Multi-stage builds](/manuals/build/building/multi-stage.md).
-
-Next, you'll need to update your Compose file to use the new stage.
-
-### Update your Compose file for development
-
-To run the `dev` stage with Compose, you need to update your `compose.yaml`
-file. Open your `compose.yaml` file in an IDE or text editor, and then add the
-`target: dev` instruction to target the `dev` stage from your multi-stage
-Dockerfile.
-
-Also, add a new volume to the server service for the bind mount. For this application, you'll mount `./src` from your local machine to `/usr/src/app/src` in the container.
-
-Lastly, publish port `9229` for debugging.
-
-The following is the updated Compose file. All comments have been removed.
-
-```yaml {hl_lines=[5,8,20,21],collapse=true,title=compose.yaml}
-services:
-  server:
-    build:
-      context: .
-      target: dev
-    ports:
-      - 3000:3000
-      - 9229:9229
-    environment:
-      NODE_ENV: production
-      POSTGRES_HOST: db
-      POSTGRES_USER: postgres
-      POSTGRES_PASSWORD_FILE: /run/secrets/db-password
-      POSTGRES_DB: example
-    depends_on:
-      db:
-        condition: service_healthy
-    secrets:
-      - db-password
-    volumes:
-      - ./src:/usr/src/app/src
-  db:
-    image: postgres
-    restart: always
-    user: postgres
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=example
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    expose:
-      - 5432
-    healthcheck:
-      test: ["CMD", "pg_isready"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-### Run your development container and debug your application
-
-Run the following command to run your application with the new changes to the `Dockerfile` and `compose.yaml` file.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and verify that the application is running at [http://localhost:3000](http://localhost:3000).
-
-Any changes to the application's source files on your local machine will now be
-immediately reflected in the running container.
-
-Open `docker-nodejs-sample/src/static/js/app.js` in an IDE or text editor and update the button text on line 109 from `Add Item` to `Add`.
-
-```diff
-+                         {submitting ? 'Adding...' : 'Add'}
--                         {submitting ? 'Adding...' : 'Add Item'}
-```
-
-Refresh [http://localhost:3000](http://localhost:3000) in your browser and verify that the updated text appears.
-
-You can now connect an inspector client to your application for debugging. For
-more details about inspector clients, see the [Node.js
-documentation](https://nodejs.org/en/docs/guides/debugging-getting-started).
-
-## Summary
-
-In this section, you took a look at setting up your Compose file to add a mock
-database and persist data. You also learned how to create a multi-stage
-Dockerfile and set up a bind mount for development.
-
-Related information:
-
-- [Volumes top-level element](/reference/compose-file/volumes/)
-- [Services top-level element](/reference/compose-file/services/)
-- [Multi-stage builds](/manuals/build/building/multi-stage.md)
-
-## Next steps
-
-In the next section, you'll learn how to run unit tests using Docker.
diff --git a/content/guides/nodejs/run-tests.md b/content/guides/nodejs/run-tests.md
deleted file mode 100644
index b59072f9becf..000000000000
--- a/content/guides/nodejs/run-tests.md
+++ /dev/null
@@ -1,174 +0,0 @@
----
-title: Run Node.js tests in a container
-linkTitle: Run your tests
-weight: 30
-keywords: node.js, node, test
-description: Learn how to run your Node.js tests in a container.
-aliases:
-  - /language/nodejs/run-tests/
-  - /guides/language/nodejs/run-tests/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a Node.js application](containerize.md).
-
-## Overview
-
-Testing is an essential part of modern software development. Testing can mean a
-lot of things to different development teams. There are unit tests, integration
-tests and end-to-end testing. In this guide you take a look at running your unit
-tests in Docker when developing and when building.
-
-## Run tests when developing locally
-
-The sample application already has the Jest package for running tests and has tests inside the `spec` directory. When developing locally, you can use Compose to run your tests.
-
-Run the following command to run the test script from the `package.json` file inside a container.
-
-```console
-$ docker compose run server npm run test
-```
-
-To learn more about the command, see [docker compose run](/reference/cli/docker/compose/run/).
-
-You should see output like the following.
-
-```console
-> docker-nodejs@1.0.0 test
-> jest
-
- PASS  spec/routes/deleteItem.spec.js
- PASS  spec/routes/getItems.spec.js
- PASS  spec/routes/addItem.spec.js
- PASS  spec/routes/updateItem.spec.js
- PASS  spec/persistence/sqlite.spec.js
-  ● Console
-
-    console.log
-      Using sqlite database at /tmp/todo.db
-
-      at Database.log (src/persistence/sqlite.js:18:25)
-
-    console.log
-      Using sqlite database at /tmp/todo.db
-
-      at Database.log (src/persistence/sqlite.js:18:25)
-
-    console.log
-      Using sqlite database at /tmp/todo.db
-
-      at Database.log (src/persistence/sqlite.js:18:25)
-
-    console.log
-      Using sqlite database at /tmp/todo.db
-
-      at Database.log (src/persistence/sqlite.js:18:25)
-
-    console.log
-      Using sqlite database at /tmp/todo.db
-
-      at Database.log (src/persistence/sqlite.js:18:25)
-
-
-Test Suites: 5 passed, 5 total
-Tests:       9 passed, 9 total
-Snapshots:   0 total
-Time:        2.008 s
-Ran all test suites.
-```
-
-## Run tests when building
-
-To run your tests when building, you need to update your Dockerfile to add a new test stage.
-
-The following is the updated Dockerfile.
-
-```dockerfile {hl_lines="27-35"}
-# syntax=docker/dockerfile:1
-
-ARG NODE_VERSION=18.0.0
-
-FROM node:${NODE_VERSION}-alpine as base
-WORKDIR /usr/src/app
-EXPOSE 3000
-
-FROM base as dev
-RUN --mount=type=bind,source=package.json,target=package.json \
-    --mount=type=bind,source=package-lock.json,target=package-lock.json \
-    --mount=type=cache,target=/root/.npm \
-    npm ci --include=dev
-USER node
-COPY . .
-CMD npm run dev
-
-FROM base as prod
-RUN --mount=type=bind,source=package.json,target=package.json \
-    --mount=type=bind,source=package-lock.json,target=package-lock.json \
-    --mount=type=cache,target=/root/.npm \
-    npm ci --omit=dev
-USER node
-COPY . .
-CMD node src/index.js
-
-FROM base as test
-ENV NODE_ENV test
-RUN --mount=type=bind,source=package.json,target=package.json \
-    --mount=type=bind,source=package-lock.json,target=package-lock.json \
-    --mount=type=cache,target=/root/.npm \
-    npm ci --include=dev
-USER node
-COPY . .
-RUN npm run test
-```
-
-Instead of using `CMD` in the test stage, use `RUN` to run the tests. The reason is that the `CMD` instruction runs when the container runs, and the `RUN` instruction runs when the image is being built and the build will fail if the tests fail.
-
-Run the following command to build a new image using the test stage as the target and view the test results. Include `--progress=plain` to view the build output, `--no-cache` to ensure the tests always run, and `--target test` to target the test stage.
-
-```console
-$ docker build -t node-docker-image-test --progress=plain --no-cache --target test .
-```
-
-You should see output containing the following.
-
-```console
-...
-
-#11 [test 3/3] RUN npm run test
-#11 1.058
-#11 1.058 > docker-nodejs@1.0.0 test
-#11 1.058 > jest
-#11 1.058
-#11 3.765 PASS spec/routes/getItems.spec.js
-#11 3.767 PASS spec/routes/deleteItem.spec.js
-#11 3.783 PASS spec/routes/updateItem.spec.js
-#11 3.806 PASS spec/routes/addItem.spec.js
-#11 4.179 PASS spec/persistence/sqlite.spec.js
-#11 4.207
-#11 4.208 Test Suites: 5 passed, 5 total
-#11 4.208 Tests:       9 passed, 9 total
-#11 4.208 Snapshots:   0 total
-#11 4.208 Time:        2.168 s
-#11 4.208 Ran all test suites.
-#11 4.265 npm notice
-#11 4.265 npm notice New major version of npm available! 8.6.0 -> 9.8.1
-#11 4.265 npm notice Changelog: <https://github.com/npm/cli/releases/tag/v9.8.1>
-#11 4.265 npm notice Run `npm install -g npm@9.8.1` to update!
-#11 4.266 npm notice
-#11 DONE 4.3s
-
-...
-```
-
-## Summary
-
-In this section, you learned how to run tests when developing locally using Compose and how to run tests when building your image.
-
-Related information:
-
-- [docker compose run](/reference/cli/docker/compose/run/)
-
-## Next steps
-
-Next, you’ll learn how to set up a CI/CD pipeline using GitHub Actions.
diff --git a/content/guides/opencode-model-runner.md b/content/guides/opencode-model-runner.md
new file mode 100644
index 000000000000..ca667f17ea54
--- /dev/null
+++ b/content/guides/opencode-model-runner.md
@@ -0,0 +1,191 @@
+---
+title: Use OpenCode with Docker Model Runner
+description: Configure OpenCode to use Docker Model Runner so you can code with local models.
+summary: |
+  Connect OpenCode to Docker Model Runner with an OpenAI-compatible endpoint,
+  choose coding models, and package `gpt-oss` with a larger context window.
+keywords: ai, opencode, docker model runner, local models, coding assistant
+weight: 3
+params:
+  tags: [ai]
+  featured: true
+  time: 10 minutes
+---
+
+This guide shows how to connect OpenCode to Docker Model Runner so OpenCode can
+use local models for coding tasks. You'll configure an `opencode.json` file,
+verify the API endpoint, and run OpenCode against models served from your local
+Docker environment.
+
+> **Acknowledgment**
+>
+> Docker would like to thank [Pradumna Saraf](https://twitter.com/pradumna_saraf) for his contribution to this guide.
+
+Unlike the [OpenCode sandbox guide](../manuals/ai/sandboxes/agents/opencode.md),
+this guide focuses on using OpenCode as a local coding tool backed by Docker
+Model Runner rather than running OpenCode in a containerized sandbox.
+
+In this guide, you'll learn how to:
+
+- Pull coding models for OpenCode
+- Configure OpenCode to use Docker Model Runner
+- Verify the local API endpoint and start OpenCode
+- Package `gpt-oss` with a larger context window when you need it
+
+## Prerequisites
+
+Before you start, make sure you have:
+
+- [Docker Desktop](../get-started/get-docker.md) or Docker Engine installed
+- [Docker Model Runner enabled](../manuals/ai/model-runner/get-started.md#enable-docker-model-runner)
+- [OpenCode installed](https://opencode.ai/docs)
+
+If you use Docker Desktop, turn on TCP access in **Settings** > **AI**, or run:
+
+```console
+$ docker desktop enable model-runner --tcp 12434
+```
+
+## Step 1: Pull a coding model
+
+Pull one or more models before you configure OpenCode:
+
+```console
+$ docker model pull ai/qwen3-coder
+$ docker model pull ai/devstral-small-2
+```
+
+These models are a good fit for coding workflows because they support large
+context windows.
+
+## Step 2: Create an OpenCode configuration
+
+OpenCode reads configuration from either of these locations:
+
+- `~/.config/opencode/opencode.json` for a global setup
+- `opencode.json` in your project root for a project-specific setup
+
+Project-level configuration overrides the global file.
+
+Add a provider that points to Docker Model Runner:
+
+```json {title="opencode.json"}
+{
+  "$schema": "https://opencode.ai/config.json",
+  "provider": {
+    "dmr": {
+      "npm": "@ai-sdk/openai-compatible",
+      "name": "Docker Model Runner",
+      "options": {
+        "baseURL": "http://localhost:12434/v1"
+      },
+      "models": {
+        "qwen3-coder": {
+          "name": "ai/qwen3-coder"
+        },
+        "devstral-small-2": {
+          "name": "ai/devstral-small-2"
+        }
+      }
+    }
+  }
+}
+```
+
+This configuration adds Docker Model Runner as an OpenCode provider and exposes
+two local models.
+
+> [!NOTE]
+>
+> If your setup expects the older OpenAI-compatible path, use
+> `http://localhost:12434/engines/v1` instead.
+
+## Step 3: Verify the endpoint
+
+Check that Docker Model Runner is reachable before you open OpenCode:
+
+```console
+$ curl http://localhost:12434/v1/models
+```
+
+If you use the older path, run:
+
+```console
+$ curl http://localhost:12434/engines/v1/models
+```
+
+The response should list the models available through Docker Model Runner.
+
+## Step 4: Start OpenCode
+
+From your project directory, run:
+
+```console
+$ opencode
+```
+
+To switch models from the TUI, run:
+
+```text
+/models
+```
+
+Then select the model from the `dmr` provider.
+
+## Step 5: Package `gpt-oss` with a larger context window
+
+This step is optional. Use it if you need a larger context window for
+repository-scale tasks.
+
+`gpt-oss` defaults to a smaller context window than coding-focused models. If
+you want to use it for repository-scale tasks, package a larger variant:
+
+```console
+$ docker model pull ai/gpt-oss
+$ docker model package --from ai/gpt-oss --context-size 128000 gpt-oss:128k
+```
+
+Then add it to your OpenCode configuration:
+
+```json {title="opencode.json"}
+{
+  "$schema": "https://opencode.ai/config.json",
+  "provider": {
+    "dmr": {
+      "npm": "@ai-sdk/openai-compatible",
+      "name": "Docker Model Runner",
+      "options": {
+        "baseURL": "http://localhost:12434/v1"
+      },
+      "models": {
+        "gpt-oss:128k": {
+          "name": "gpt-oss:128k"
+        }
+      }
+    }
+  }
+}
+```
+
+## Troubleshooting
+
+If OpenCode can't connect, check Docker Model Runner status:
+
+```console
+$ docker model status
+```
+
+If OpenCode does not show your model, list local models:
+
+```console
+$ docker model ls
+```
+
+If the model is missing, pull it first and confirm the model name in
+`opencode.json` matches the local model you want to use.
+
+## Learn more
+
+- [Docker Model Runner overview](../manuals/ai/model-runner/_index.md)
+- [Docker Model Runner API reference](../manuals/ai/model-runner/api-reference.md)
+- [IDE and tool integrations](../manuals/ai/model-runner/ide-integrations.md)
diff --git a/content/guides/opentelemetry.md b/content/guides/opentelemetry.md
new file mode 100644
index 000000000000..8b9bf4bbfbef
--- /dev/null
+++ b/content/guides/opentelemetry.md
@@ -0,0 +1,197 @@
+---
+title: Instrumenting a JavaScript App with OpenTelemetry
+description: &desc Learn how to instrument a JavaScript application using OpenTelemetry in a Dockerized environment.
+keywords: OpenTelemetry, observability, tracing
+linktitle: Instrumenting JS Apps with OpenTelemetry
+summary: *desc
+params:
+  tags: [cicd]
+  time: 10 minutes
+---
+
+OpenTelemetry (OTel) is an open-source observability framework that provides a set of APIs, SDKs, and tools for collecting telemetry data, such as metrics, logs, and traces, from applications. With OpenTelemetry, developers can obtain valuable insights into how their services perform in production or during local development.
+
+A key component of OpenTelemetry is the OpenTelemetry Protocol (OTLP) a general-purpose, vendor-agnostic protocol designed to transmit telemetry data efficiently and reliably. OTLP supports multiple data types (traces, metrics, logs) over HTTP or gRPC, making it the default and recommended protocol for communication between instrumented applications, the OpenTelemetry Collector, and backends such as Jaeger or Prometheus.
+
+This guide walks you through how to instrument a simple Node.js application with OpenTelemetry and run both the app and a collector using Docker. This setup is ideal for local development and testing observability before integrating with external observability platforms like Prometheus, Jaeger, or Grafana.
+
+In this guide, you'll learn how to:
+
+- How to set up OpenTelemetry in a Node.js app.
+- How to run an OpenTelemetry Collector in Docker.
+- How to visualize traces with Jaeger.
+- How to use Docker Compose to manage the full observability stack.
+
+## Using OpenTelemetry with Docker
+
+The [Docker Official Image for OpenTelemetry](https://hub.docker.com/r/otel/opentelemetry-collector-contrib) provides a convenient way to deploy and manage Dex instances. OpenTelemetry is available for various CPU architectures, including amd64, armv7, and arm64, ensuring compatibility with different devices and platforms. Same for the [Jaeger Docker image](https://hub.docker.com/r/jaegertracing/jaeger).
+
+## Prerequisites
+
+[Docker Compose](/compose/): Recommended for managing multi-container Docker applications.
+
+Basic knowledge of Node.js and Docker.
+
+## Project structure
+
+Create the project directory:
+```bash
+mkdir otel-js-app
+cd otel-js-app
+```
+
+```bash
+otel-js-app/
+├── docker-compose.yaml
+├── collector-config.yaml
+├── app/
+│   ├── package.json
+│   ├── app.js
+│   └── tracer.js
+```
+
+## Create a simple Node.js app
+
+Initialize a basic Node.js app:
+
+```bash
+mkdir app && cd app
+npm init -y
+npm install express @opentelemetry/api @opentelemetry/sdk-node \
+            @opentelemetry/auto-instrumentations-node \
+            @opentelemetry/exporter-trace-otlp-http
+```
+
+Now, add the application logic:
+
+```js
+// app/app.js
+const express = require('express');
+require('./tracer'); // Initialize OpenTelemetry
+
+const app = express();
+
+app.get('/', (req, res) => {
+  res.send('Hello from OpenTelemetry demo app!');
+});
+
+const PORT = 3000;
+app.listen(PORT, () => {
+  console.log(`App listening at http://localhost:${PORT}`);
+});
+```
+
+## Configure OpenTelemetry tracing
+
+Create the tracer configuration file:
+
+```js
+// app/tracer.js
+const { NodeSDK } = require('@opentelemetry/sdk-node');
+const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
+const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');
+
+const sdk = new NodeSDK({
+  traceExporter: new OTLPTraceExporter({
+    url: 'http://collector:4318/v1/traces',
+  }),
+  instrumentations: [getNodeAutoInstrumentations()],
+});
+
+sdk.start();
+```
+
+## Configure the OpenTelemetry Collector
+
+Create a collector-config.yaml file at the root:
+
+```yaml
+# collector-config.yaml
+receivers:
+  otlp:
+    protocols:
+      http:
+
+exporters:
+  logging:
+    loglevel: debug
+  jaeger:
+    endpoint: jaeger:14250
+    tls:
+      insecure: true
+
+service:
+  pipelines:
+    traces:
+      receivers: [otlp]
+      exporters: [logging, jaeger]
+```
+
+## Add Docker Compose configuration
+
+Create the `docker-compose.yaml` file:
+
+```yaml
+services:
+  app:
+    build: ./app
+    ports:
+      - "3000:3000"
+    environment:
+      - NODE_ENV=development
+    depends_on:
+      - collector
+
+  collector:
+    image: otel/opentelemetry-collector:latest
+    volumes:
+      - ./collector-config.yaml:/etc/otelcol/config.yaml
+    command: ["--config=/etc/otelcol/config.yaml"]
+    ports:
+      - "4318:4318" # OTLP
+
+  jaeger:
+    image: jaegertracing/all-in-one:latest
+    ports:
+      - "16686:16686" # UI
+      - "14250:14250" # Collector gRPC
+```
+
+Now, add the `Dockerfile` inside the `app/` folder:
+
+```dockerfile
+# app/Dockerfile
+FROM node:18
+
+WORKDIR /usr/src/app
+COPY . .
+RUN npm install
+
+CMD ["node", "app.js"]
+```
+
+## Start the stack
+
+Start all services with Docker Compose:
+
+```bash
+docker compose up --build
+```
+
+Once the services are running:
+
+Visit your app at [http://localhost:3000](http://localhost:3000)
+
+View traces at [http://localhost:16686](http://localhost:16686) in the Jaeger UI
+
+## Verify traces in Jaeger
+
+After visiting your app's root endpoint, open Jaeger’s UI, search for the service (default is usually `unknown_service` unless explicitly named), and check the traces.
+
+You should see spans for the HTTP request, middleware, and auto-instrumented libraries.
+
+## Conclusion
+
+You now have a fully functional OpenTelemetry setup using Docker Compose. You've instrumented a basic JavaScript app to export traces and visualized them using Jaeger. This architecture is extendable for more complex applications and observability pipelines using Prometheus, Grafana, or cloud-native exporters.
+
+For advanced topics such as custom span creation, metrics, and logs, consult the OpenTelemetry JavaScript docs.
diff --git a/content/guides/orchestration.md b/content/guides/orchestration.md
deleted file mode 100644
index d63d54e0b5fd..000000000000
--- a/content/guides/orchestration.md
+++ /dev/null
@@ -1,323 +0,0 @@
----
-title: Deployment and orchestration
-keywords: orchestration, deploy, kubernetes, swarm,
-description: Get oriented on some basics of Docker and install Docker Desktop.
-aliases:
-  - /get-started/orchestration/
-  - /guides/deployment-orchestration/orchestration/
-summary: |
-  Explore the essentials of container orchestration with Docker.
-tags: [deploy]
-params:
-  time: 10 minutes
----
-
-Containerization provides an opportunity to move and scale applications to
-clouds and data centers. Containers effectively guarantee that those applications run the
-same way anywhere, allowing you to quickly and easily take advantage of all
-these environments. Additionally, as you scale your applications up, you need some
-tooling to help automate the maintenance of those applications, enable the
-replacement of failed containers automatically, and manage the roll-out of
-updates and reconfigurations of those containers during their lifecycle.
-
-Tools to manage, scale, and maintain containerized applications are called
-orchestrators. Two of the most popular orchestration tools are Kubernetes and
-Docker Swarm. Docker Desktop provides development environments for both of these
-orchestrators.
-
-The advanced modules teach you how to:
-
-1. [Set up and use a Kubernetes environment on your development machine](kube-deploy.md)
-2. [Set up and use a Swarm environment on your development machine](swarm-deploy.md)
-
-## Turn on Kubernetes
-
-Docker Desktop sets up Kubernetes for you quickly and easily. Follow the setup and validation instructions appropriate for your operating system:
-
-{{< tabs group="os" >}}
-{{< tab name="Mac and Linux" >}}
-
-### Mac
-
-1.  From the Docker Dashboard, navigate to **Settings**, and select the **Kubernetes** tab.
-
-2.  Select the checkbox labeled **Enable Kubernetes**, and select **Apply & Restart**. Docker Desktop automatically sets up Kubernetes for you. You'll know that Kubernetes has been successfully enabled when you see a green light beside 'Kubernetes _running_' in **Settings**.
-
-3.  To confirm that Kubernetes is up and running, create a text file called `pod.yaml` with the following content:
-
-    ```yaml
-    apiVersion: v1
-    kind: Pod
-    metadata:
-      name: demo
-    spec:
-      containers:
-        - name: testpod
-          image: alpine:latest
-          command: ["ping", "8.8.8.8"]
-    ```
-
-    This describes a pod with a single container, isolating a simple ping to 8.8.8.8.
-
-4.  In a terminal, navigate to where you created `pod.yaml` and create your pod:
-
-    ```console
-    $ kubectl apply -f pod.yaml
-    ```
-
-5.  Check that your pod is up and running:
-
-    ```console
-    $ kubectl get pods
-    ```
-
-    You should see something like:
-
-    ```shell
-    NAME      READY     STATUS    RESTARTS   AGE
-    demo      1/1       Running   0          4s
-    ```
-
-6.  Check that you get the logs you'd expect for a ping process:
-
-    ```console
-    $ kubectl logs demo
-    ```
-
-    You should see the output of a healthy ping process:
-
-    ```shell
-    PING 8.8.8.8 (8.8.8.8): 56 data bytes
-    64 bytes from 8.8.8.8: seq=0 ttl=37 time=21.393 ms
-    64 bytes from 8.8.8.8: seq=1 ttl=37 time=15.320 ms
-    64 bytes from 8.8.8.8: seq=2 ttl=37 time=11.111 ms
-    ...
-    ```
-
-7.  Finally, tear down your test pod:
-
-    ```console
-    $ kubectl delete -f pod.yaml
-    ```
-
-{{< /tab >}}
-{{< tab name="Windows" >}}
-
-### Windows
-
-1. From the Docker Dashboard, navigate to **Settings**, and select the **Kubernetes** tab.
-
-2. Select the checkbox labeled **Enable Kubernetes**, and select **Apply & Restart**. Docker Desktop automatically sets up Kubernetes for you. You'll know that Kubernetes has been successfully enabled when you see a green light beside 'Kubernetes _running_' in the **Settings** menu.
-
-3. To confirm that Kubernetes is up and running, create a text file called `pod.yaml` with the following content:
-
-   ```yaml
-   apiVersion: v1
-   kind: Pod
-   metadata:
-     name: demo
-   spec:
-     containers:
-       - name: testpod
-         image: alpine:latest
-         command: ["ping", "8.8.8.8"]
-   ```
-
-   This describes a pod with a single container, isolating a simple ping to 8.8.8.8.
-
-4. In PowerShell, navigate to where you created `pod.yaml` and create your pod:
-
-   ```console
-   $ kubectl apply -f pod.yaml
-   ```
-
-5. Check that your pod is up and running:
-
-   ```console
-   $ kubectl get pods
-   ```
-
-   You should see something like:
-
-   ```shell
-   NAME      READY     STATUS    RESTARTS   AGE
-   demo      1/1       Running   0          4s
-   ```
-
-6. Check that you get the logs you'd expect for a ping process:
-
-   ```console
-   $ kubectl logs demo
-   ```
-
-   You should see the output of a healthy ping process:
-
-   ```shell
-   PING 8.8.8.8 (8.8.8.8): 56 data bytes
-   64 bytes from 8.8.8.8: seq=0 ttl=37 time=21.393 ms
-   64 bytes from 8.8.8.8: seq=1 ttl=37 time=15.320 ms
-   64 bytes from 8.8.8.8: seq=2 ttl=37 time=11.111 ms
-   ...
-   ```
-
-7. Finally, tear down your test pod:
-
-   ```console
-   $ kubectl delete -f pod.yaml
-   ```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Enable Docker Swarm
-
-Docker Desktop runs primarily on Docker Engine, which has everything you need to run a Swarm built in. Follow the setup and validation instructions appropriate for your operating system:
-
-{{< tabs group="os" >}}
-{{< tab name="Mac" >}}
-
-### Mac
-
-1. Open a terminal, and initialize Docker Swarm mode:
-
-   ```console
-   $ docker swarm init
-   ```
-
-   If all goes well, you should see a message similar to the following:
-
-   ```shell
-   Swarm initialized: current node (tjjggogqpnpj2phbfbz8jd5oq) is now a manager.
-
-   To add a worker to this swarm, run the following command:
-
-       docker swarm join --token SWMTKN-1-3e0hh0jd5t4yjg209f4g5qpowbsczfahv2dea9a1ay2l8787cf-2h4ly330d0j917ocvzw30j5x9 192.168.65.3:2377
-
-   To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
-   ```
-
-2. Run a simple Docker service that uses an alpine-based filesystem, and isolates a ping to 8.8.8.8:
-
-   ```console
-   $ docker service create --name demo alpine:latest ping 8.8.8.8
-   ```
-
-3. Check that your service created one running container:
-
-   ```console
-   $ docker service ps demo
-   ```
-
-   You should see something like:
-
-   ```shell
-   ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE           ERROR               PORTS
-   463j2s3y4b5o        demo.1              alpine:latest       docker-desktop      Running             Running 8 seconds ago
-   ```
-
-4. Check that you get the logs you'd expect for a ping process:
-
-   ```console
-   $ docker service logs demo
-   ```
-
-   You should see the output of a healthy ping process:
-
-   ```shell
-   demo.1.463j2s3y4b5o@docker-desktop    | PING 8.8.8.8 (8.8.8.8): 56 data bytes
-   demo.1.463j2s3y4b5o@docker-desktop    | 64 bytes from 8.8.8.8: seq=0 ttl=37 time=13.005 ms
-   demo.1.463j2s3y4b5o@docker-desktop    | 64 bytes from 8.8.8.8: seq=1 ttl=37 time=13.847 ms
-   demo.1.463j2s3y4b5o@docker-desktop    | 64 bytes from 8.8.8.8: seq=2 ttl=37 time=41.296 ms
-   ...
-   ```
-
-5. Finally, tear down your test service:
-
-   ```console
-   $ docker service rm demo
-   ```
-
-{{< /tab >}}
-{{< tab name="Windows" >}}
-
-### Windows
-
-1. Open a PowerShell, and initialize Docker Swarm mode:
-
-   ```console
-   $ docker swarm init
-   ```
-
-   If all goes well, you should see a message similar to the following:
-
-   ```shell
-   Swarm initialized: current node (tjjggogqpnpj2phbfbz8jd5oq) is now a manager.
-
-   To add a worker to this swarm, run the following command:
-
-       docker swarm join --token SWMTKN-1-3e0hh0jd5t4yjg209f4g5qpowbsczfahv2dea9a1ay2l8787cf-2h4ly330d0j917ocvzw30j5x9 192.168.65.3:2377
-
-   To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
-   ```
-
-2. Run a simple Docker service that uses an alpine-based filesystem, and isolates a ping to 8.8.8.8:
-
-   ```console
-   $ docker service create --name demo alpine:latest ping 8.8.8.8
-   ```
-
-3. Check that your service created one running container:
-
-   ```console
-   $ docker service ps demo
-   ```
-
-   You should see something like:
-
-   ```shell
-   ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE           ERROR               PORTS
-   463j2s3y4b5o        demo.1              alpine:latest       docker-desktop      Running             Running 8 seconds ago
-   ```
-
-4. Check that you get the logs you'd expect for a ping process:
-
-   ```console
-   $ docker service logs demo
-   ```
-
-   You should see the output of a healthy ping process:
-
-   ```shell
-   demo.1.463j2s3y4b5o@docker-desktop    | PING 8.8.8.8 (8.8.8.8): 56 data bytes
-   demo.1.463j2s3y4b5o@docker-desktop    | 64 bytes from 8.8.8.8: seq=0 ttl=37 time=13.005 ms
-   demo.1.463j2s3y4b5o@docker-desktop    | 64 bytes from 8.8.8.8: seq=1 ttl=37 time=13.847 ms
-   demo.1.463j2s3y4b5o@docker-desktop    | 64 bytes from 8.8.8.8: seq=2 ttl=37 time=41.296 ms
-   ...
-   ```
-
-5. Finally, tear down your test service:
-
-   ```console
-   $ docker service rm demo
-   ```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Conclusion
-
-At this point, you've confirmed that you can run simple containerized workloads in Kubernetes and Swarm. The next step is to write a YAML file that describes how to run and manage these containers.
-
-- [Deploy to Kubernetes](kube-deploy.md)
-- [Deploy to Swarm](swarm-deploy.md)
-
-## CLI references
-
-Further documentation for all CLI commands used in this article are available here:
-
-- [`kubectl apply`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply)
-- [`kubectl get`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get)
-- [`kubectl logs`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs)
-- [`kubectl delete`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#delete)
-- [`docker swarm init`](/reference/cli/docker/swarm/init/)
-- [`docker service *`](/reference/cli/docker/service/)
diff --git a/content/guides/pgadmin.md b/content/guides/pgadmin.md
new file mode 100644
index 000000000000..2a688bbb181e
--- /dev/null
+++ b/content/guides/pgadmin.md
@@ -0,0 +1,170 @@
+---
+description: Visualizing your PostgreSQL databases with pgAdmin
+keywords: pgadmin, container-supported development
+title: Visualizing your PostgreSQL databases with pgAdmin
+linktitle: Visualizing your PostgreSQL databases with pgAdmin
+summary: |
+  Explore how to add pgAdmin to your development stack and make it as easy as possible for your teammates to navigate through your PostgreSQL databases.
+params:
+  tags: [databases]
+  time: 10 minutes
+---
+
+Many applications use PostgreSQL databases in the application stack. However, not all developers are knowledgeable about navigating and working with PostgreSQL databases.
+
+Fortunately, when you use containers in development, it is easy to add additional services to help with troubleshooting and debugging.
+
+The [pgAdmin](https://www.pgadmin.org/) tool is a popular open-source tool designed to help administer and visualize PostgreSQL databases.
+
+In this guide you will learn how to:
+
+1. Add pgAdmin to your application stack
+2. Configure pgAdmin to automatically connect to the development database
+
+
+
+## Adding pgAdmin to your stack
+
+1. In your `compose.yaml` file, add the `pgadmin` service next to your existing `postgres` service:
+
+    ```yaml
+    services:
+      postgres:
+        image: postgres:18
+        environment:
+          POSTGRES_USER: postgres
+          POSTGRES_PASSWORD: secret
+          POSTGRES_DB: demo
+
+      pgadmin:
+        image: dpage/pgadmin4:9.8
+        ports:
+          - 5050:80
+        environment:
+          # Required by pgAdmin
+          PGADMIN_DEFAULT_EMAIL: demo@example.com
+          PGADMIN_DEFAULT_PASSWORD: secret
+
+          # Don't require the user to login
+          PGADMIN_CONFIG_SERVER_MODE: 'False'
+
+          # Don't require a "master" password after logging in
+          PGADMIN_CONFIG_MASTER_PASSWORD_REQUIRED: 'False'
+    ```
+
+2. Start the Compose stack with the following command:
+
+    ```console
+    $ docker compose up
+    ```
+
+    After the image is downloaded the container starts, you will see output that looks similar to the following indicating pgAdmin is ready:
+
+    ```console
+    pgadmin-1   | [2025-09-22 15:52:47 +0000] [1] [INFO] Starting gunicorn 23.0.0
+    pgadmin-1   | [2025-09-22 15:52:47 +0000] [1] [INFO] Listening at: http://[::]:80 (1)
+    pgadmin-1   | [2025-09-22 15:52:47 +0000] [1] [INFO] Using worker: gthread
+    pgadmin-1   | [2025-09-22 15:52:47 +0000] [119] [INFO] Booting worker with pid: 119
+    ```
+
+3. Open pgAdmin by going to http://localhost:5050.
+
+4. Once in the admin panel, select the **Add New Server** link to define a new server. Enter the following details:
+
+    - **General** tab:
+        - **Name**: `postgres`
+    - **Connection** tab:
+        - **Host name/address**: `postgres`
+        - **Username**: `postgres`
+        - **Password**: `secret`
+        - Enable the **Save password?** field
+
+    > [!IMPORTANT]
+    >
+    > These connection details assume you are using the previous Compose file snippet. If you are using an existing Compose file,
+    > adjust the connection details as required. The **Host name/address** field should match the name of your postgres service.
+
+5. Select the **Save** button to create the new database.
+
+You now have pgAdmin setup and connected to your containerized database. Feel free to navigate around, view the tables, and explore your database.
+
+
+
+## Configuring pgAdmin to auto-connect to the database
+
+Although you have pgAdmin running, it would be nice if you could simply open the app without needing to configure the database connection. Reducing the setup steps would be a great way to make it easier for teammates to get value from this tool.
+
+Fortunately, there is an ability to auto-connect to the database.
+
+> [!WARNING]
+>
+> In order to auto-connect, the database credentials are shared using plaintext files. During local development, this is often acceptable as local data is not real customer data.
+> However, if you are using production or sensitive data, this practice is strongly discouraged.
+
+1. First, you need to define the server itself, which pgAdmin does using a `servers.json` file. 
+
+    Add the following to your `compose.yaml` file to define a config file for the `servers.json` file:
+
+    ```yaml
+    configs:
+      pgadmin-servers:
+        content: |
+          {
+            "Servers": {
+              "1": {
+                "Name": "Local Postgres",
+                "Group": "Servers",
+                "Host": "postgres",
+                "Port": 5432,
+                "MaintenanceDB": "postgres",
+                "Username": "postgres",
+                "PassFile": "/config/pgpass"
+              }
+            }
+          }
+    ```
+
+2. The `servers.json` file defines a `PassFile` field, which is a reference to a [postgreSQL password files](https://www.postgresql.org/docs/current/libpq-pgpass.html). These are often referred to as a pgpass file.
+
+    Add the following config to your `compose.yaml` file to define a pgpass file:
+
+    ```yaml
+    configs:
+      pgadmin-pgpass:
+        content: |
+          postgres:5432:*:postgres:secret
+    ```
+
+    This will indicate any connection requests to `postgres:5432` using the username `postgres` should provide a password of `secret`.
+
+3. In your `compose.yaml`, update the `pgadmin` service to inject the config files:
+
+    ```yaml
+    services:
+      pgadmin:
+        ...
+        configs:
+          - source: pgadmin-pgpass
+            target: /config/pgpass
+            uid: "5050"
+            gid: "5050"
+            mode: 0400
+          - source: pgadmin-servers
+            target: /pgadmin4/servers.json
+            mode: 0444
+    ```
+
+4. Update the application stack by running `docker compose up` again:
+
+    ```console
+    $ docker compose up
+    ```
+
+5. Once the application is restarted, open your browser to http://localhost:5050. You should be able to access the database without any logging in or configuration.
+
+
+## Conclusion
+
+Using containers makes it easy to not only run your application's dependencies, but also additional tools to help with troubleshooting and debugging. 
+
+When you add tools, think about the experience and possible friction your teammates might experience and how you might be able to remove it. In this case, you were able to take an extra step to add configuration to automatically configure and connect the databases, saving your teammates valuable time.
diff --git a/content/guides/php.md b/content/guides/php.md
new file mode 100644
index 000000000000..7165b516001a
--- /dev/null
+++ b/content/guides/php.md
@@ -0,0 +1,839 @@
+---
+title: PHP language-specific guide
+linkTitle: PHP
+description: Containerize and develop PHP apps using Docker
+keywords: getting started, php, composer
+summary: |
+  This guide explains how to containerize PHP applications using Docker.
+aliases:
+  - /language/php/
+  - /guides/language/php/
+  - /language/php/containerize/
+  - /language/php/develop/
+  - /language/php/run-tests/
+  - /language/php/configure-ci-cd/
+  - /language/php/deploy/
+  - /guides/php/configure-ci-cd/
+  - /guides/php/containerize/
+  - /guides/php/deploy/
+  - /guides/php/develop/
+  - /guides/php/run-tests/
+params:
+  tags: [languages]
+  time: 20 minutes
+---
+
+The PHP language-specific guide teaches you how to create a containerized PHP application using Docker. In this guide, you'll learn how to:
+
+- Containerize and run a PHP application
+- Set up a local environment to develop a PHP application using containers
+- Run tests for a PHP application within containers
+
+After completing the PHP language-specific guide, you should be able to containerize your own PHP application based on the examples and instructions provided in this guide.
+
+Start by containerizing an existing PHP application.
+
+## Containerize a PHP application
+
+### Prerequisites
+
+- You have installed the latest version of [Docker
+  Desktop](/get-started/get-docker.md).
+- You have a [git client](https://git-scm.com/downloads). The examples in this
+  section use a command-line based git client, but you can use any client.
+
+### Overview
+
+This section walks you through containerizing and running a PHP
+application.
+
+### Get the sample applications
+
+In this guide, you will use a pre-built PHP application. The application uses Composer for library dependency management. You'll serve the application via an Apache web server.
+
+Open a terminal, change directory to a directory that you want to work in, and
+run the following command to clone the repository.
+
+```console
+$ git clone https://github.com/docker/docker-php-sample
+```
+
+The sample application is a basic hello world application and an application that increments a counter in a database. In addition, the application uses PHPUnit for testing.
+
+### Create Docker assets
+
+Now that you have an application, you can create the necessary Docker assets to
+containerize it.
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for your project. Ask Gordon to create a Dockerfile, Compose file, and `.dockerignore` tailored to your application.
+
+Create the following files in your `docker-php-sample` directory.
+
+```dockerfile {collapse=true,title=Dockerfile}
+# syntax=docker/dockerfile:1
+
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Dockerfile reference guide at
+# https://docs.docker.com/go/dockerfile-reference/
+
+################################################################################
+
+# Create a stage for installing app dependencies defined in Composer.
+FROM composer:lts as deps
+
+WORKDIR /app
+
+# If your composer.json file defines scripts that run during dependency installation and
+# reference your application source files, uncomment the line below to copy all the files
+# into this layer.
+# COPY . .
+
+# Download dependencies as a separate step to take advantage of Docker's caching.
+# Leverage a bind mounts to composer.json and composer.lock to avoid having to copy them
+# into this layer.
+# Leverage a cache mount to /tmp/cache so that subsequent builds don't have to re-download packages.
+RUN --mount=type=bind,source=composer.json,target=composer.json \
+    --mount=type=bind,source=composer.lock,target=composer.lock \
+    --mount=type=cache,target=/tmp/cache \
+    composer install --no-dev --no-interaction
+
+################################################################################
+
+# Create a new stage for running the application that contains the minimal
+# runtime dependencies for the application. This often uses a different base
+# image from the install or build stage where the necessary files are copied
+# from the install stage.
+#
+# The example below uses the PHP Apache image as the foundation for running the app.
+# By specifying the "8.2-apache" tag, it will also use whatever happens to be the
+# most recent version of that tag when you build your Dockerfile.
+# If reproducibility is important, consider using a specific digest SHA, like
+# php@sha256:99cede493dfd88720b610eb8077c8688d3cca50003d76d1d539b0efc8cca72b4.
+FROM php:8.2-apache as final
+
+# Your PHP application may require additional PHP extensions to be installed
+# manually. For detailed instructions for installing extensions can be found, see
+# https://github.com/docker-library/docs/tree/master/php#how-to-install-more-php-extensions
+# The following code blocks provide examples that you can edit and use.
+#
+# Add core PHP extensions, see
+# https://github.com/docker-library/docs/tree/master/php#php-core-extensions
+# This example adds the apt packages for the 'gd' extension's dependencies and then
+# installs the 'gd' extension. For additional tips on running apt-get, see
+# https://docs.docker.com/go/dockerfile-aptget-best-practices/
+# RUN apt-get update && apt-get install -y \
+#     libfreetype-dev \
+#     libjpeg62-turbo-dev \
+#     libpng-dev \
+# && rm -rf /var/lib/apt/lists/* \
+#     && docker-php-ext-configure gd --with-freetype --with-jpeg \
+#     && docker-php-ext-install -j$(nproc) gd
+#
+# Add PECL extensions, see
+# https://github.com/docker-library/docs/tree/master/php#pecl-extensions
+# This example adds the 'redis' and 'xdebug' extensions.
+# RUN pecl install redis-5.3.7 \
+#    && pecl install xdebug-3.2.1 \
+#    && docker-php-ext-enable redis xdebug
+
+# Use the default production configuration for PHP runtime arguments, see
+# https://github.com/docker-library/docs/tree/master/php#configuration
+RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
+
+# Copy the app dependencies from the previous install stage.
+COPY --from=deps app/vendor/ /var/www/html/vendor
+# Copy the app files from the app directory.
+COPY ./src /var/www/html
+
+# Switch to a non-privileged user (defined in the base image) that the app will run under.
+# See https://docs.docker.com/go/dockerfile-user-best-practices/
+USER www-data
+```
+
+```yaml {collapse=true,title=compose.yaml}
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Docker Compose reference guide at
+# https://docs.docker.com/go/compose-spec-reference/
+
+# Here the instructions define your application as a service called "server".
+# This service is built from the Dockerfile in the current directory.
+# You can add other services your application may depend on here, such as a
+# database or a cache. For examples, see the Awesome Compose repository:
+# https://github.com/docker/awesome-compose
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 9000:80
+
+# The commented out section below is an example of how to define a PostgreSQL
+# database that your application can use. `depends_on` tells Docker Compose to
+# start the database before your application. The `db-data` volume persists the
+# database data between container restarts. The `db-password` secret is used
+# to set the database password. You must create `db/password.txt` and add
+# a password of your choosing to it before running `docker compose up`.
+#     depends_on:
+#       db:
+#         condition: service_healthy
+#   db:
+#     image: postgres
+#     restart: always
+#     user: postgres
+#     secrets:
+#       - db-password
+#     volumes:
+#       - db-data:/var/lib/postgresql/data
+#     environment:
+#       - POSTGRES_DB=example
+#       - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+#     expose:
+#       - 5432
+#     healthcheck:
+#       test: [ "CMD", "pg_isready" ]
+#       interval: 10s
+#       timeout: 5s
+#       retries: 5
+# volumes:
+#   db-data:
+# secrets:
+#   db-password:
+#     file: db/password.txt
+```
+
+```text {collapse=true,title=".dockerignore"}
+# Include any files or directories that you don't want to be copied to your
+# container here (e.g., local build artifacts, temporary files, etc.).
+#
+# For more help, visit the .dockerignore file reference guide at
+# https://docs.docker.com/go/build-context-dockerignore/
+
+**/.classpath
+**/.dockerignore
+**/.env
+**/.git
+**/.gitignore
+**/.project
+**/.settings
+**/.toolstarget
+**/.vs
+**/.vscode
+**/.next
+**/.cache
+**/*.*proj.user
+**/*.dbmdl
+**/*.jfm
+**/charts
+**/docker-compose*
+**/compose.y*ml
+!**/composer.json
+!**/composer.lock
+**/Dockerfile*
+**/node_modules
+**/npm-debug.log
+**/obj
+**/secrets.dev.yaml
+**/values.dev.yaml
+**/vendor
+LICENSE
+README.md
+```
+
+You should now have the following contents in your `docker-php-sample`
+directory.
+
+```text
+├── docker-php-sample/
+│ ├── .git/
+│ ├── src/
+│ ├── tests/
+│ ├── .dockerignore
+│ ├── .gitignore
+│ ├── compose.yaml
+│ ├── composer.json
+│ ├── composer.lock
+│ ├── Dockerfile
+│ └── README.md
+```
+
+To learn more about these files, see the following:
+
+- [Dockerfile](/reference/dockerfile.md)
+- [.dockerignore](/reference/dockerfile.md#dockerignore-file)
+- [compose.yaml](/reference/compose-file/_index.md)
+
+### Run the application
+
+Inside the `docker-php-sample` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:9000/hello.php](http://localhost:9000/hello.php). You should see a simple hello world application.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `docker-php-sample` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:9000/hello.php](http://localhost:9000/hello.php). You should see a simple hello world application.
+
+In the terminal, run the following command to stop the application.
+
+```console
+$ docker compose down
+```
+
+For more information about Compose commands, see the [Compose CLI
+reference](/reference/cli/docker/compose/).
+
+## Use containers for PHP development
+
+### Prerequisites
+
+Complete [Containerize a PHP application](#containerize-a-php-application).
+
+### Overview
+
+In this section, you'll learn how to set up a development environment for your containerized application. This includes:
+
+- Adding a local database and persisting data
+- Adding phpMyAdmin to interact with the database
+- Configuring Compose to automatically update your running Compose services as
+  you edit and save your code
+- Creating a development container that contains the dev dependencies
+
+### Add a local database and persist data
+
+You can use containers to set up local services, like a database.
+To do this for the sample application, you'll need to do the following:
+
+- Update the `Dockerfile` to install extensions to connect to the database
+- Update the `compose.yaml` file to add a database service and volume to persist data
+
+#### Update the Dockerfile to install extensions
+
+To install PHP extensions, you need to update the `Dockerfile`. Open your
+Dockerfile in an IDE or text editor and then update the contents. The following
+`Dockerfile` includes one new line that installs the `pdo` and `pdo_mysql`
+extensions. All comments have been removed.
+
+```dockerfile {hl_lines=11}
+# syntax=docker/dockerfile:1
+
+FROM composer:lts as deps
+WORKDIR /app
+RUN --mount=type=bind,source=composer.json,target=composer.json \
+    --mount=type=bind,source=composer.lock,target=composer.lock \
+    --mount=type=cache,target=/tmp/cache \
+    composer install --no-dev --no-interaction
+
+FROM php:8.2-apache as final
+RUN docker-php-ext-install pdo pdo_mysql
+RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
+COPY --from=deps app/vendor/ /var/www/html/vendor
+COPY ./src /var/www/html
+USER www-data
+```
+
+For more details about installing PHP extensions, see the [Official Docker Image for PHP](https://hub.docker.com/_/php).
+
+#### Update the compose.yaml file to add a db and persist data
+
+Open the `compose.yaml` file in an IDE or text editor. You'll notice it
+already contains commented-out instructions for a PostgreSQL database and volume. For this application, you'll use MariaDB. For more details about MariaDB, see the [MariaDB Official Docker image](https://hub.docker.com/_/mariadb).
+
+Open the `src/database.php` file in an IDE or text editor. You'll notice that it reads environment variables in order to connect to the database.
+
+In the `compose.yaml` file, you'll need to update the following:
+
+1. Uncomment and update the database instructions for MariaDB.
+2. Add a secret to the server service to pass in the database password.
+3. Add the database connection environment variables to the server service.
+4. Uncomment the volume instructions to persist data.
+
+The following is the updated `compose.yaml` file. All comments have been removed.
+
+```yaml
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 9000:80
+    depends_on:
+      db:
+        condition: service_healthy
+    secrets:
+      - db-password
+    environment:
+      - PASSWORD_FILE_PATH=/run/secrets/db-password
+      - DB_HOST=db
+      - DB_NAME=example
+      - DB_USER=root
+  db:
+    image: mariadb
+    restart: always
+    user: root
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/mysql
+    environment:
+      - MARIADB_ROOT_PASSWORD_FILE=/run/secrets/db-password
+      - MARIADB_DATABASE=example
+    expose:
+      - 3306
+    healthcheck:
+      test:
+        [
+          "CMD",
+          "/usr/local/bin/healthcheck.sh",
+          "--su-mysql",
+          "--connect",
+          "--innodb_initialized",
+        ]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+> [!NOTE]
+>
+> To learn more about the instructions in the Compose file, see [Compose file
+> reference](/reference/compose-file/).
+
+Before you run the application using Compose, notice that this Compose file uses
+`secrets` and specifies a `password.txt` file to hold the database's password.
+You must create this file as it's not included in the source repository.
+
+In the `docker-php-sample` directory, create a new directory named `db` and
+inside that directory create a file named `password.txt`. Open `password.txt` in an IDE or text editor and add the following password. The password must be on a single line, with no additional lines in the file.
+
+```text
+example
+```
+
+Save and close the `password.txt` file.
+
+You should now have the following in your `docker-php-sample` directory.
+
+```text
+├── docker-php-sample/
+│ ├── .git/
+│ ├── db/
+│ │ └── password.txt
+│ ├── src/
+│ ├── tests/
+│ ├── .dockerignore
+│ ├── .gitignore
+│ ├── compose.yaml
+│ ├── composer.json
+│ ├── composer.lock
+│ ├── Dockerfile
+│ └── README.md
+```
+
+Run the following command to start your application.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:9000/database.php](http://localhost:9000/database.php). You should see a simple web application with text and a counter that increments every time you refresh.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Verify that data persists in the database
+
+In the terminal, run `docker compose rm` to remove your containers and then run `docker compose up` to run your application again.
+
+```console
+$ docker compose rm
+$ docker compose up --build
+```
+
+Refresh [http://localhost:9000/database.php](http://localhost:9000/database.php) in your browser and verify that the previous count still exists. Without a volume, the database data wouldn't persist after you remove the container.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Add phpMyAdmin to interact with the database
+
+You can easily add services to your application stack by updating the `compose.yaml` file.
+
+Update your `compose.yaml` to add a new service for phpMyAdmin. For more details, see the [phpMyAdmin Official Docker Image](https://hub.docker.com/_/phpmyadmin). The following is the updated `compose.yaml` file.
+
+```yaml {hl_lines="42-49"}
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 9000:80
+    depends_on:
+      db:
+        condition: service_healthy
+    secrets:
+      - db-password
+    environment:
+      - PASSWORD_FILE_PATH=/run/secrets/db-password
+      - DB_HOST=db
+      - DB_NAME=example
+      - DB_USER=root
+  db:
+    image: mariadb
+    restart: always
+    user: root
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/mysql
+    environment:
+      - MARIADB_ROOT_PASSWORD_FILE=/run/secrets/db-password
+      - MARIADB_DATABASE=example
+    expose:
+      - 3306
+    healthcheck:
+      test:
+        [
+          "CMD",
+          "/usr/local/bin/healthcheck.sh",
+          "--su-mysql",
+          "--connect",
+          "--innodb_initialized",
+        ]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+  phpmyadmin:
+    image: phpmyadmin
+    ports:
+      - 8080:80
+    depends_on:
+      - db
+    environment:
+      - PMA_HOST=db
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+In the terminal, run `docker compose up` to run your application again.
+
+```console
+$ docker compose up --build
+```
+
+Open [http://localhost:8080](http://localhost:8080) in your browser to access phpMyAdmin. Log in using `root` as the username and `example` as the password. You can now interact with the database through phpMyAdmin.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Automatically update services
+
+Use Compose Watch to automatically update your running Compose services as you edit and save your code. For more details about Compose Watch, see [Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
+
+Open your `compose.yaml` file in an IDE or text editor and then add the Compose Watch instructions. The following is the updated `compose.yaml` file.
+
+```yaml {hl_lines="17-21"}
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 9000:80
+    depends_on:
+      db:
+        condition: service_healthy
+    secrets:
+      - db-password
+    environment:
+      - PASSWORD_FILE_PATH=/run/secrets/db-password
+      - DB_HOST=db
+      - DB_NAME=example
+      - DB_USER=root
+    develop:
+      watch:
+        - action: sync
+          path: ./src
+          target: /var/www/html
+  db:
+    image: mariadb
+    restart: always
+    user: root
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/mysql
+    environment:
+      - MARIADB_ROOT_PASSWORD_FILE=/run/secrets/db-password
+      - MARIADB_DATABASE=example
+    expose:
+      - 3306
+    healthcheck:
+      test:
+        [
+          "CMD",
+          "/usr/local/bin/healthcheck.sh",
+          "--su-mysql",
+          "--connect",
+          "--innodb_initialized",
+        ]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+  phpmyadmin:
+    image: phpmyadmin
+    ports:
+      - 8080:80
+    depends_on:
+      - db
+    environment:
+      - PMA_HOST=db
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+Run the following command to run your application with Compose Watch.
+
+```console
+$ docker compose watch
+```
+
+Open a browser and verify that the application is running at [http://localhost:9000/hello.php](http://localhost:9000/hello.php).
+
+Any changes to the application's source files on your local machine will now be
+immediately reflected in the running container.
+
+Open `hello.php` in an IDE or text editor and update the string `Hello, world!` to `Hello, Docker!`.
+
+Save the changes to `hello.php` and then wait a few seconds for the application to sync. Refresh [http://localhost:9000/hello.php](http://localhost:9000/hello.php) in your browser and verify that the updated text appears.
+
+Press `ctrl+c` in the terminal to stop Compose Watch. Run `docker compose down` in the terminal to stop the application.
+
+### Create a development container
+
+At this point, when you run your containerized application, Composer isn't installing the dev dependencies. While this small image is good for production, it lacks the tools and dependencies you may need when developing and it doesn't include the `tests` directory. You can use multi-stage builds to build stages for both development and production in the same Dockerfile. For more details, see [Multi-stage builds](/manuals/build/building/multi-stage.md).
+
+In the `Dockerfile`, you'll need to update the following:
+
+1. Split the `deps` staged into two stages. One stage for production
+   (`prod-deps`) and one stage (`dev-deps`) to install development dependencies.
+2. Create a common `base` stage.
+3. Create a new `development` stage for development.
+4. Update the `final` stage to copy dependencies from the new `prod-deps` stage.
+
+The following is the `Dockerfile` before and after the changes.
+
+{{< tabs >}}
+{{< tab name="Before" >}}
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+FROM composer:lts as deps
+WORKDIR /app
+RUN --mount=type=bind,source=composer.json,target=composer.json \
+    --mount=type=bind,source=composer.lock,target=composer.lock \
+    --mount=type=cache,target=/tmp/cache \
+    composer install --no-dev --no-interaction
+
+FROM php:8.2-apache as final
+RUN docker-php-ext-install pdo pdo_mysql
+RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
+COPY --from=deps app/vendor/ /var/www/html/vendor
+COPY ./src /var/www/html
+USER www-data
+```
+
+{{< /tab >}}
+{{< tab name="After" >}}
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+FROM composer:lts as prod-deps
+WORKDIR /app
+RUN --mount=type=bind,source=./composer.json,target=composer.json \
+    --mount=type=bind,source=./composer.lock,target=composer.lock \
+    --mount=type=cache,target=/tmp/cache \
+    composer install --no-dev --no-interaction
+
+FROM composer:lts as dev-deps
+WORKDIR /app
+RUN --mount=type=bind,source=./composer.json,target=composer.json \
+    --mount=type=bind,source=./composer.lock,target=composer.lock \
+    --mount=type=cache,target=/tmp/cache \
+    composer install --no-interaction
+
+FROM php:8.2-apache as base
+RUN docker-php-ext-install pdo pdo_mysql
+COPY ./src /var/www/html
+
+FROM base as development
+COPY ./tests /var/www/html/tests
+RUN mv "$PHP_INI_DIR/php.ini-development" "$PHP_INI_DIR/php.ini"
+COPY --from=dev-deps app/vendor/ /var/www/html/vendor
+
+FROM base as final
+RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
+COPY --from=prod-deps app/vendor/ /var/www/html/vendor
+USER www-data
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Update your `compose.yaml` file by adding an instruction to target the
+development stage.
+
+The following is the updated section of the `compose.yaml` file.
+
+```yaml {hl_lines=5}
+services:
+  server:
+    build:
+      context: .
+      target: development
+      # ...
+```
+
+Your containerized application will now install the dev dependencies.
+
+Run the following command to start your application.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:9000/hello.php](http://localhost:9000/hello.php). You should still see the simple "Hello, Docker!" application.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+While the application appears the same, you can now make use of the dev dependencies. Continue to the next section to learn how you can run tests using Docker.
+
+## Run PHP tests in a container
+
+### Prerequisites
+
+Complete all the previous sections of this guide, starting with [Containerize a PHP application](#containerize-a-php-application).
+
+### Overview
+
+Testing is an essential part of modern software development. Testing can mean a
+lot of things to different development teams. There are unit tests, integration
+tests and end-to-end testing. In this guide you take a look at running your unit
+tests in Docker when developing and when building.
+
+### Run tests when developing locally
+
+The sample application already has a PHPUnit test inside the `tests` directory. When developing locally, you can use Compose to run your tests.
+
+Run the following command in the `docker-php-sample` directory to run the tests inside a container.
+
+```console
+$ docker compose run --build --rm server ./vendor/bin/phpunit tests/HelloWorldTest.php
+```
+
+You should see output that contains the following.
+
+```console
+Hello, Docker!PHPUnit 9.6.13 by Sebastian Bergmann and contributors.
+
+.                                                                   1 / 1 (100%)
+
+Time: 00:00.003, Memory: 4.00 MB
+
+OK (1 test, 1 assertion)
+```
+
+To learn more about the command, see [docker compose run](/reference/cli/docker/compose/run/).
+
+### Run tests when building
+
+To run your tests when building, you need to update your Dockerfile. Create a new test stage that runs the tests.
+
+The following is the updated Dockerfile.
+
+```dockerfile {hl_lines="26-28"}
+# syntax=docker/dockerfile:1
+
+FROM composer:lts as prod-deps
+WORKDIR /app
+RUN --mount=type=bind,source=./composer.json,target=composer.json \
+    --mount=type=bind,source=./composer.lock,target=composer.lock \
+    --mount=type=cache,target=/tmp/cache \
+    composer install --no-dev --no-interaction
+
+FROM composer:lts as dev-deps
+WORKDIR /app
+RUN --mount=type=bind,source=./composer.json,target=composer.json \
+    --mount=type=bind,source=./composer.lock,target=composer.lock \
+    --mount=type=cache,target=/tmp/cache \
+    composer install --no-interaction
+
+FROM php:8.2-apache as base
+RUN docker-php-ext-install pdo pdo_mysql
+COPY ./src /var/www/html
+
+FROM base as development
+COPY ./tests /var/www/html/tests
+RUN mv "$PHP_INI_DIR/php.ini-development" "$PHP_INI_DIR/php.ini"
+COPY --from=dev-deps app/vendor/ /var/www/html/vendor
+
+FROM development as test
+WORKDIR /var/www/html
+RUN ./vendor/bin/phpunit tests/HelloWorldTest.php
+
+FROM base as final
+RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
+COPY --from=prod-deps app/vendor/ /var/www/html/vendor
+USER www-data
+```
+
+Run the following command to build an image using the test stage as the target and view the test results. Include `--progress plain` to view the build output, `--no-cache` to ensure the tests always run, and `--target test` to target the test stage.
+
+```console
+$ docker build -t php-docker-image-test --progress plain --no-cache --target test .
+```
+
+You should see output containing the following.
+
+```console
+#18 [test 2/2] RUN ./vendor/bin/phpunit tests/HelloWorldTest.php
+#18 0.385 Hello, Docker!PHPUnit 9.6.13 by Sebastian Bergmann and contributors.
+#18 0.392
+#18 0.394 .                                                                   1 / 1 (100%)
+#18 0.395
+#18 0.395 Time: 00:00.003, Memory: 4.00 MB
+#18 0.395
+#18 0.395 OK (1 test, 1 assertion)
+```
+
+### Summary
+
+In this section, you learned how to run tests when developing locally using Compose and how to run tests when building your image.
+
+Related information:
+
+- [docker compose run](/reference/cli/docker/compose/run/)
diff --git a/content/guides/php/_index.md b/content/guides/php/_index.md
deleted file mode 100644
index 358b13865aa9..000000000000
--- a/content/guides/php/_index.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: PHP language-specific guide
-linkTitle: PHP
-description: Containerize and develop PHP apps using Docker
-keywords: getting started, php, composer
-summary: |
-  This guide explains how to containerize PHP applications using Docker.
-toc_min: 1
-toc_max: 2
-aliases:
-  - /language/php/
-  - /guides/language/php/
-languages: [php]
-params:
-  time: 20 minutes
----
-
-The PHP language-specific guide teaches you how to create a containerized PHP application using Docker. In this guide, you'll learn how to:
-
-- Containerize and run a PHP application
-- Set up a local environment to develop a PHP application using containers
-- Run tests for a PHP application within containers
-- Configure a CI/CD pipeline for a containerized PHP application using GitHub Actions
-- Deploy your containerized application locally to Kubernetes to test and debug your deployment
-
-After completing the PHP language-specific guide, you should be able to containerize your own PHP application based on the examples and instructions provided in this guide.
-
-Start by containerizing an existing PHP application.
diff --git a/content/guides/php/configure-ci-cd.md b/content/guides/php/configure-ci-cd.md
deleted file mode 100644
index c67e2a17181e..000000000000
--- a/content/guides/php/configure-ci-cd.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-title: Configure CI/CD for your PHP application
-linkTitle: Configure CI/CD
-weight: 40
-keywords: php, CI/CD
-description: Learn how to Configure CI/CD for your PHP application
-aliases:
-  - /language/php/configure-ci-cd/
-  - /guides/language/php/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a PHP application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-## Overview
-
-In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps:
-
-1. Create a new repository on GitHub.
-2. Define the GitHub Actions workflow.
-3. Run the workflow.
-
-## Step one: Create the repository
-
-Create a GitHub repository, configure the Docker Hub credentials, and push your source code.
-
-1. [Create a new repository](https://github.com/new) on GitHub.
-
-2. Open the repository **Settings**, and go to **Secrets and variables** >
-   **Actions**.
-
-3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-4. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-5. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-6. In your local repository on your machine, run the following command to change
-   the origin to the repository you just created. Make sure you change
-   `your-username` to your GitHub username and `your-repository` to the name of
-   the repository you created.
-
-   ```console
-   $ git remote set-url origin https://github.com/your-username/your-repository.git
-   ```
-
-7. In your local repository on your machine, run the following command to rename
-   the branch to main.
-
-   ```console
-   $ git branch -M main
-   ```
-
-8. Run the following commands to stage, commit, and then push your local
-   repository to GitHub.
-
-   ```console
-   $ git add -A
-   $ git commit -m "my first commit"
-   $ git push -u origin main
-   ```
-
-## Step two: Set up the workflow
-
-Set up your GitHub Actions workflow for building, testing, and pushing the image
-to Docker Hub.
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-
-2. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub actions workflow file in
-   your repository, under `.github/workflows/main.yml` by default.
-
-3. In the editor window, copy and paste the following YAML configuration.
-
-   ```yaml
-   name: ci
-
-   on:
-     push:
-       branches:
-         - main
-
-   jobs:
-     build:
-       runs-on: ubuntu-latest
-       steps:
-         - name: Login to Docker Hub
-           uses: docker/login-action@v3
-           with:
-             username: ${{ vars.DOCKER_USERNAME }}
-             password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-         - name: Set up Docker Buildx
-           uses: docker/setup-buildx-action@v3
-
-         - name: Build and test
-           uses: docker/build-push-action@v6
-           with:
-             target: test
-             load: true
-
-         - name: Build and push
-           uses: docker/build-push-action@v6
-           with:
-             platforms: linux/amd64,linux/arm64
-             push: true
-             target: final
-             tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-   ```
-
-   For more information about the YAML syntax for `docker/build-push-action`,
-   refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
-## Step three: Run the workflow
-
-Save the workflow file and run the job.
-
-1. Select **Commit changes...** and push the changes to the `main` branch.
-
-   After pushing the commit, the workflow starts automatically.
-
-2. Go to the **Actions** tab. It displays the workflow.
-
-   Selecting the workflow shows you the breakdown of all the steps.
-
-3. When the workflow is complete, go to your
-   [repositories on Docker Hub](https://hub.docker.com/repositories).
-
-   If you see the new repository in that list, it means the GitHub Actions
-   successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your application.
-
-Related information:
-
-- [Introduction to GitHub Actions](/guides/gha.md)
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md)
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-Next, learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/php/containerize.md b/content/guides/php/containerize.md
deleted file mode 100644
index 8fa500b4d80b..000000000000
--- a/content/guides/php/containerize.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: Containerize a PHP application
-linkTitle: Containerize your app
-weight: 10
-keywords: php, containerize, initialize, apache, composer
-description: Learn how to containerize a PHP application.
-aliases:
-  - /language/php/containerize/
-  - /guides/language/php/containerize/
----
-
-## Prerequisites
-
-- You have installed the latest version of [Docker
-  Desktop](/get-started/get-docker.md).
-- You have a [git client](https://git-scm.com/downloads). The examples in this
-  section use a command-line based git client, but you can use any client.
-
-## Overview
-
-This section walks you through containerizing and running a PHP
-application.
-
-## Get the sample applications
-
-In this guide, you will use a pre-built PHP application. The application uses Composer for library dependency management. You'll serve the application via an Apache web server.
-
-Open a terminal, change directory to a directory that you want to work in, and
-run the following command to clone the repository.
-
-```console
-$ git clone https://github.com/docker/docker-php-sample
-```
-
-The sample application is a basic hello world application and an application that increments a counter in a database. In addition, the application uses PHPUnit for testing.
-
-## Initialize Docker assets
-
-Now that you have an application, you can use `docker init` to create the
-necessary Docker assets to containerize your application. Inside the
-`docker-php-sample` directory, run the `docker init` command in a terminal.
-`docker init` provides some default configuration, but you'll need to answer a
-few questions about your application. For example, this application uses PHP
-version 8.2. Refer to the following `docker init` example and use the same
-answers for your prompts.
-
-```console
-$ docker init
-Welcome to the Docker Init CLI!
-
-This utility will walk you through creating the following files with sensible defaults for your project:
-  - .dockerignore
-  - Dockerfile
-  - compose.yaml
-  - README.Docker.md
-
-Let's get started!
-
-? What application platform does your project use? PHP with Apache
-? What version of PHP do you want to use? 8.2
-? What's the relative directory (with a leading .) for your app? ./src
-? What local port do you want to use to access your server? 9000
-```
-
-You should now have the following contents in your `docker-php-sample`
-directory.
-
-```text
-├── docker-php-sample/
-│ ├── .git/
-│ ├── src/
-│ ├── tests/
-│ ├── .dockerignore
-│ ├── .gitignore
-│ ├── compose.yaml
-│ ├── composer.json
-│ ├── composer.lock
-│ ├── Dockerfile
-│ ├── README.Docker.md
-│ └── README.md
-```
-
-To learn more about the files that `docker init` added, see the following:
-
-- [Dockerfile](/reference/dockerfile.md)
-- [.dockerignore](/reference/dockerfile.md#dockerignore-file)
-- [compose.yaml](/reference/compose-file/_index.md)
-
-## Run the application
-
-Inside the `docker-php-sample` directory, run the following command in a
-terminal.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:9000/hello.php](http://localhost:9000/hello.php). You should see a simple hello world application.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-### Run the application in the background
-
-You can run the application detached from the terminal by adding the `-d`
-option. Inside the `docker-php-sample` directory, run the following command
-in a terminal.
-
-```console
-$ docker compose up --build -d
-```
-
-Open a browser and view the application at [http://localhost:9000/hello.php](http://localhost:9000/hello.php). You should see a simple hello world application.
-
-In the terminal, run the following command to stop the application.
-
-```console
-$ docker compose down
-```
-
-For more information about Compose commands, see the [Compose CLI
-reference](/reference/cli/docker/compose/_index.md).
-
-## Summary
-
-In this section, you learned how you can containerize and run a simple PHP
-application using Docker.
-
-Related information:
-
-- [docker init reference](/reference/cli/docker/init.md)
-
-## Next steps
-
-In the next section, you'll learn how you can develop your application using
-Docker containers.
diff --git a/content/guides/php/deploy.md b/content/guides/php/deploy.md
deleted file mode 100644
index e6b96660db7b..000000000000
--- a/content/guides/php/deploy.md
+++ /dev/null
@@ -1,146 +0,0 @@
----
-title: Test your PHP deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, php, local, development
-description: Learn how to deploy your application
-aliases:
-  - /language/php/deploy/
-  - /guides/language/php/deploy/
----
-
-## Prerequisites
-
-- Complete all the previous sections of this guide, starting with [Containerize
-  a PHP application](containerize.md).
-- [Turn on Kubernetes](/manuals/desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker
-  Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your
-application to a fully-featured Kubernetes environment on your development
-machine. This allows you to test and debug your workloads on Kubernetes locally
-before deploying.
-
-## Create a Kubernetes YAML file
-
-In your `docker-php-sample` directory, create a file named
-`docker-php-kubernetes.yaml`. Open the file in an IDE or text editor and add
-the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker
-username and the name of the repository that you created in [Configure CI/CD for
-your PHP application](configure-ci-cd.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: docker-php-demo
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      hello-php: web
-  template:
-    metadata:
-      labels:
-        hello-php: web
-    spec:
-      containers:
-        - name: hello-site
-          image: DOCKER_USERNAME/REPO_NAME
-          imagePullPolicy: Always
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: php-entrypoint
-  namespace: default
-spec:
-  type: NodePort
-  selector:
-    hello-php: web
-  ports:
-    - port: 80
-      targetPort: 80
-      nodePort: 30001
-```
-
-In this Kubernetes YAML file, there are two objects, separated by the `---`:
-
-- A Deployment, describing a scalable group of identical pods. In this case,
-  you'll get just one replica, or copy of your pod. That pod, which is
-  described under `template`, has just one container in it. The container is
-  created from the image built by GitHub Actions in [Configure CI/CD for your
-  PHP application](configure-ci-cd.md).
-- A NodePort service, which will route traffic from port 30001 on your host to
-  port 80 inside the pods it routes to, allowing you to reach your app
-  from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to the `docker-php-sample` directory
-   and deploy your application to Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-php-kubernetes.yaml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```text
-   deployment.apps/docker-php-demo created
-   service/php-entrypoint created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```text
-   NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
-   docker-php-demo      1/1     1            1           6s
-   ```
-
-   This indicates all of the pods are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```text
-   NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
-   kubernetes        ClusterIP   10.96.0.1        <none>        443/TCP          7d22h
-   php-entrypoint    NodePort    10.111.101.229   <none>        80:30001/TCP     33s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `php-entrypoint` service. The `php-entrypoint` service is accepting traffic on port 30001/TCP.
-
-3. Open a browser and visit your app at
-   [http://localhost:30001/hello.php](http://localhost:30001/hello.php). You
-   should see your application.
-
-4. Run the following command to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-php-kubernetes.yaml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine.
-
-Related information:
-
-- [Kubernetes documentation](https://kubernetes.io/docs/home/)
-- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-- [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/php/develop.md b/content/guides/php/develop.md
deleted file mode 100644
index 865f2de9f14b..000000000000
--- a/content/guides/php/develop.md
+++ /dev/null
@@ -1,459 +0,0 @@
----
-title: Use containers for PHP development
-linkTitle: Develop your app
-weight: 20
-keywords: php, development
-description: Learn how to develop your PHP application locally using containers.
-aliases:
-  - /language/php/develop/
-  - /guides/language/php/develop/
----
-
-## Prerequisites
-
-Complete [Containerize a PHP application](containerize.md).
-
-## Overview
-
-In this section, you'll learn how to set up a development environment for your containerized application. This includes:
-
-- Adding a local database and persisting data
-- Adding phpMyAdmin to interact with the database
-- Configuring Compose to automatically update your running Compose services as
-  you edit and save your code
-- Creating a development container that contains the dev dependencies
-
-## Add a local database and persist data
-
-You can use containers to set up local services, like a database.
-To do this for the sample application, you'll need to do the following:
-
-- Update the `Dockerfile` to install extensions to connect to the database
-- Update the `compose.yaml` file to add a database service and volume to persist data
-
-### Update the Dockerfile to install extensions
-
-To install PHP extensions, you need to update the `Dockerfile`. Open your
-Dockerfile in an IDE or text editor and then update the contents. The following
-`Dockerfile` includes one new line that installs the `pdo` and `pdo_mysql`
-extensions. All comments have been removed.
-
-```dockerfile {hl_lines=11}
-# syntax=docker/dockerfile:1
-
-FROM composer:lts as deps
-WORKDIR /app
-RUN --mount=type=bind,source=composer.json,target=composer.json \
-    --mount=type=bind,source=composer.lock,target=composer.lock \
-    --mount=type=cache,target=/tmp/cache \
-    composer install --no-dev --no-interaction
-
-FROM php:8.2-apache as final
-RUN docker-php-ext-install pdo pdo_mysql
-RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
-COPY --from=deps app/vendor/ /var/www/html/vendor
-COPY ./src /var/www/html
-USER www-data
-```
-
-For more details about installing PHP extensions, see the [Official Docker Image for PHP](https://hub.docker.com/_/php).
-
-### Update the compose.yaml file to add a db and persist data
-
-Open the `compose.yaml` file in an IDE or text editor. You'll notice it
-already contains commented-out instructions for a PostgreSQL database and volume. For this application, you'll use MariaDB. For more details about MariaDB, see the [MariaDB Official Docker image](https://hub.docker.com/_/mariadb).
-
-Open the `src/database.php` file in an IDE or text editor. You'll notice that it reads environment variables in order to connect to the database.
-
-In the `compose.yaml` file, you'll need to update the following:
-
-1. Uncomment and update the database instructions for MariaDB.
-2. Add a secret to the server service to pass in the database password.
-3. Add the database connection environment variables to the server service.
-4. Uncomment the volume instructions to persist data.
-
-The following is the updated `compose.yaml` file. All comments have been removed.
-
-```yaml
-services:
-  server:
-    build:
-      context: .
-    ports:
-      - 9000:80
-    depends_on:
-      db:
-        condition: service_healthy
-    secrets:
-      - db-password
-    environment:
-      - PASSWORD_FILE_PATH=/run/secrets/db-password
-      - DB_HOST=db
-      - DB_NAME=example
-      - DB_USER=root
-  db:
-    image: mariadb
-    restart: always
-    user: root
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/mysql
-    environment:
-      - MARIADB_ROOT_PASSWORD_FILE=/run/secrets/db-password
-      - MARIADB_DATABASE=example
-    expose:
-      - 3306
-    healthcheck:
-      test:
-        [
-          "CMD",
-          "/usr/local/bin/healthcheck.sh",
-          "--su-mysql",
-          "--connect",
-          "--innodb_initialized",
-        ]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-> [!NOTE]
->
-> To learn more about the instructions in the Compose file, see [Compose file
-> reference](/reference/compose-file/).
-
-Before you run the application using Compose, notice that this Compose file uses
-`secrets` and specifies a `password.txt` file to hold the database's password.
-You must create this file as it's not included in the source repository.
-
-In the `docker-php-sample` directory, create a new directory named `db` and
-inside that directory create a file named `password.txt`. Open `password.txt` in an IDE or text editor and add the following password. The password must be on a single line, with no additional lines in the file.
-
-```text
-example
-```
-
-Save and close the `password.txt` file.
-
-You should now have the following in your `docker-php-sample` directory.
-
-```text
-├── docker-php-sample/
-│ ├── .git/
-│ ├── db/
-│ │ └── password.txt
-│ ├── src/
-│ ├── tests/
-│ ├── .dockerignore
-│ ├── .gitignore
-│ ├── compose.yaml
-│ ├── composer.json
-│ ├── composer.lock
-│ ├── Dockerfile
-│ ├── README.Docker.md
-│ └── README.md
-```
-
-Run the following command to start your application.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:9000/database.php](http://localhost:9000/database.php). You should see a simple web application with text and a counter that increments every time you refresh.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Verify that data persists in the database
-
-In the terminal, run `docker compose rm` to remove your containers and then run `docker compose up` to run your application again.
-
-```console
-$ docker compose rm
-$ docker compose up --build
-```
-
-Refresh [http://localhost:9000/database.php](http://localhost:9000/database.php) in your browser and verify that the previous count still exists. Without a volume, the database data wouldn't persist after you remove the container.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Add phpMyAdmin to interact with the database
-
-You can easily add services to your application stack by updating the `compose.yaml` file.
-
-Update your `compose.yaml` to add a new service for phpMyAdmin. For more details, see the [phpMyAdmin Official Docker Image](https://hub.docker.com/_/phpmyadmin). The following is the updated `compose.yaml` file.
-
-```yaml {hl_lines="42-49"}
-services:
-  server:
-    build:
-      context: .
-    ports:
-      - 9000:80
-    depends_on:
-      db:
-        condition: service_healthy
-    secrets:
-      - db-password
-    environment:
-      - PASSWORD_FILE_PATH=/run/secrets/db-password
-      - DB_HOST=db
-      - DB_NAME=example
-      - DB_USER=root
-  db:
-    image: mariadb
-    restart: always
-    user: root
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/mysql
-    environment:
-      - MARIADB_ROOT_PASSWORD_FILE=/run/secrets/db-password
-      - MARIADB_DATABASE=example
-    expose:
-      - 3306
-    healthcheck:
-      test:
-        [
-          "CMD",
-          "/usr/local/bin/healthcheck.sh",
-          "--su-mysql",
-          "--connect",
-          "--innodb_initialized",
-        ]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-  phpmyadmin:
-    image: phpmyadmin
-    ports:
-      - 8080:80
-    depends_on:
-      - db
-    environment:
-      - PMA_HOST=db
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-In the terminal, run `docker compose up` to run your application again.
-
-```console
-$ docker compose up --build
-```
-
-Open [http://localhost:8080](http://localhost:8080) in your browser to access phpMyAdmin. Log in using `root` as the username and `example` as the password. You can now interact with the database through phpMyAdmin.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Automatically update services
-
-Use Compose Watch to automatically update your running Compose services as you edit and save your code. For more details about Compose Watch, see [Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
-
-Open your `compose.yaml` file in an IDE or text editor and then add the Compose Watch instructions. The following is the updated `compose.yaml` file.
-
-```yaml {hl_lines="17-21"}
-services:
-  server:
-    build:
-      context: .
-    ports:
-      - 9000:80
-    depends_on:
-      db:
-        condition: service_healthy
-    secrets:
-      - db-password
-    environment:
-      - PASSWORD_FILE_PATH=/run/secrets/db-password
-      - DB_HOST=db
-      - DB_NAME=example
-      - DB_USER=root
-    develop:
-      watch:
-        - action: sync
-          path: ./src
-          target: /var/www/html
-  db:
-    image: mariadb
-    restart: always
-    user: root
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/mysql
-    environment:
-      - MARIADB_ROOT_PASSWORD_FILE=/run/secrets/db-password
-      - MARIADB_DATABASE=example
-    expose:
-      - 3306
-    healthcheck:
-      test:
-        [
-          "CMD",
-          "/usr/local/bin/healthcheck.sh",
-          "--su-mysql",
-          "--connect",
-          "--innodb_initialized",
-        ]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-  phpmyadmin:
-    image: phpmyadmin
-    ports:
-      - 8080:80
-    depends_on:
-      - db
-    environment:
-      - PMA_HOST=db
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-Run the following command to run your application with Compose Watch.
-
-```console
-$ docker compose watch
-```
-
-Open a browser and verify that the application is running at [http://localhost:9000/hello.php](http://localhost:9000/hello.php).
-
-Any changes to the application's source files on your local machine will now be
-immediately reflected in the running container.
-
-Open `hello.php` in an IDE or text editor and update the string `Hello, world!` to `Hello, Docker!`.
-
-Save the changes to `hello.php` and then wait a few seconds for the application to sync. Refresh [http://localhost:9000/hello.php](http://localhost:9000/hello.php) in your browser and verify that the updated text appears.
-
-Press `ctrl+c` in the terminal to stop Compose Watch. Run `docker compose down` in the terminal to stop the application.
-
-## Create a development container
-
-At this point, when you run your containerized application, Composer isn't installing the dev dependencies. While this small image is good for production, it lacks the tools and dependencies you may need when developing and it doesn't include the `tests` directory. You can use multi-stage builds to build stages for both development and production in the same Dockerfile. For more details, see [Multi-stage builds](/manuals/build/building/multi-stage.md).
-
-In the `Dockerfile`, you'll need to update the following:
-
-1. Split the `deps` staged into two stages. One stage for production
-   (`prod-deps`) and one stage (`dev-deps`) to install development dependencies.
-2. Create a common `base` stage.
-3. Create a new `development` stage for development.
-4. Update the `final` stage to copy dependencies from the new `prod-deps` stage.
-
-The following is the `Dockerfile` before and after the changes.
-
-{{< tabs >}}
-{{< tab name="Before" >}}
-
-```dockerfile
-# syntax=docker/dockerfile:1
-
-FROM composer:lts as deps
-WORKDIR /app
-RUN --mount=type=bind,source=composer.json,target=composer.json \
-    --mount=type=bind,source=composer.lock,target=composer.lock \
-    --mount=type=cache,target=/tmp/cache \
-    composer install --no-dev --no-interaction
-
-FROM php:8.2-apache as final
-RUN docker-php-ext-install pdo pdo_mysql
-RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
-COPY --from=deps app/vendor/ /var/www/html/vendor
-COPY ./src /var/www/html
-USER www-data
-```
-
-{{< /tab >}}
-{{< tab name="After" >}}
-
-```dockerfile
-# syntax=docker/dockerfile:1
-
-FROM composer:lts as prod-deps
-WORKDIR /app
-RUN --mount=type=bind,source=./composer.json,target=composer.json \
-    --mount=type=bind,source=./composer.lock,target=composer.lock \
-    --mount=type=cache,target=/tmp/cache \
-    composer install --no-dev --no-interaction
-
-FROM composer:lts as dev-deps
-WORKDIR /app
-RUN --mount=type=bind,source=./composer.json,target=composer.json \
-    --mount=type=bind,source=./composer.lock,target=composer.lock \
-    --mount=type=cache,target=/tmp/cache \
-    composer install --no-interaction
-
-FROM php:8.2-apache as base
-RUN docker-php-ext-install pdo pdo_mysql
-COPY ./src /var/www/html
-
-FROM base as development
-COPY ./tests /var/www/html/tests
-RUN mv "$PHP_INI_DIR/php.ini-development" "$PHP_INI_DIR/php.ini"
-COPY --from=dev-deps app/vendor/ /var/www/html/vendor
-
-FROM base as final
-RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
-COPY --from=prod-deps app/vendor/ /var/www/html/vendor
-USER www-data
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-Update your `compose.yaml` file by adding an instruction to target the
-development stage.
-
-The following is the updated section of the `compose.yaml` file.
-
-```yaml {hl_lines=5}
-services:
-  server:
-    build:
-      context: .
-      target: development
-      # ...
-```
-
-Your containerized application will now install the dev dependencies.
-
-Run the following command to start your application.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:9000/hello.php](http://localhost:9000/hello.php). You should still see the simple "Hello, Docker!" application.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-While the application appears the same, you can now make use of the dev dependencies. Continue to the next section to learn how you can run tests using Docker.
-
-## Summary
-
-In this section, you took a look at setting up your Compose file to add a local
-database and persist data. You also learned how to use Compose Watch to automatically sync your application when you update your code. And finally, you learned how to create a development container that contains the dependencies needed for development.
-
-Related information:
-
-- [Compose file reference](/reference/compose-file/)
-- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
-- [Dockerfile reference](/reference/dockerfile.md)
-- [Official Docker Image for PHP](https://hub.docker.com/_/php)
-
-## Next steps
-
-In the next section, you'll learn how to run unit tests using Docker.
diff --git a/content/guides/php/run-tests.md b/content/guides/php/run-tests.md
deleted file mode 100644
index 7ddad4d72fb8..000000000000
--- a/content/guides/php/run-tests.md
+++ /dev/null
@@ -1,118 +0,0 @@
----
-title: Run PHP tests in a container
-linkTitle: Run your tests
-weight: 30
-keywords: php, test
-description: Learn how to run your PHP tests in a container.
-aliases:
-  - /language/php/run-tests/
-  - /guides/language/php/run-tests/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a PHP application](containerize.md).
-
-## Overview
-
-Testing is an essential part of modern software development. Testing can mean a
-lot of things to different development teams. There are unit tests, integration
-tests and end-to-end testing. In this guide you take a look at running your unit
-tests in Docker when developing and when building.
-
-## Run tests when developing locally
-
-The sample application already has a PHPUnit test inside the `tests` directory. When developing locally, you can use Compose to run your tests.
-
-Run the following command in the `docker-php-sample` directory to run the tests inside a container.
-
-```console
-$ docker compose run --build --rm server ./vendor/bin/phpunit tests/HelloWorldTest.php
-```
-
-You should see output that contains the following.
-
-```console
-Hello, Docker!PHPUnit 9.6.13 by Sebastian Bergmann and contributors.
-
-.                                                                   1 / 1 (100%)
-
-Time: 00:00.003, Memory: 4.00 MB
-
-OK (1 test, 1 assertion)
-```
-
-To learn more about the command, see [docker compose run](/reference/cli/docker/compose/run/).
-
-## Run tests when building
-
-To run your tests when building, you need to update your Dockerfile. Create a new test stage that runs the tests.
-
-The following is the updated Dockerfile.
-
-```dockerfile {hl_lines="26-28"}
-# syntax=docker/dockerfile:1
-
-FROM composer:lts as prod-deps
-WORKDIR /app
-RUN --mount=type=bind,source=./composer.json,target=composer.json \
-    --mount=type=bind,source=./composer.lock,target=composer.lock \
-    --mount=type=cache,target=/tmp/cache \
-    composer install --no-dev --no-interaction
-
-FROM composer:lts as dev-deps
-WORKDIR /app
-RUN --mount=type=bind,source=./composer.json,target=composer.json \
-    --mount=type=bind,source=./composer.lock,target=composer.lock \
-    --mount=type=cache,target=/tmp/cache \
-    composer install --no-interaction
-
-FROM php:8.2-apache as base
-RUN docker-php-ext-install pdo pdo_mysql
-COPY ./src /var/www/html
-
-FROM base as development
-COPY ./tests /var/www/html/tests
-RUN mv "$PHP_INI_DIR/php.ini-development" "$PHP_INI_DIR/php.ini"
-COPY --from=dev-deps app/vendor/ /var/www/html/vendor
-
-FROM development as test
-WORKDIR /var/www/html
-RUN ./vendor/bin/phpunit tests/HelloWorldTest.php
-
-FROM base as final
-RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
-COPY --from=prod-deps app/vendor/ /var/www/html/vendor
-USER www-data
-```
-
-Run the following command to build an image using the test stage as the target and view the test results. Include `--progress plain` to view the build output, `--no-cache` to ensure the tests always run, and `--target test` to target the test stage.
-
-```console
-$ docker build -t php-docker-image-test --progress plain --no-cache --target test .
-```
-
-You should see output containing the following.
-
-```console
-#18 [test 2/2] RUN ./vendor/bin/phpunit tests/HelloWorldTest.php
-#18 0.385 Hello, Docker!PHPUnit 9.6.13 by Sebastian Bergmann and contributors.
-#18 0.392
-#18 0.394 .                                                                   1 / 1 (100%)
-#18 0.395
-#18 0.395 Time: 00:00.003, Memory: 4.00 MB
-#18 0.395
-#18 0.395 OK (1 test, 1 assertion)
-```
-
-## Summary
-
-In this section, you learned how to run tests when developing locally using Compose and how to run tests when building your image.
-
-Related information:
-
-- [docker compose run](/reference/cli/docker/compose/run/)
-
-## Next steps
-
-Next, you’ll learn how to set up a CI/CD pipeline using GitHub Actions.
diff --git a/content/guides/postgresql.md b/content/guides/postgresql.md
new file mode 100644
index 000000000000..869e976739af
--- /dev/null
+++ b/content/guides/postgresql.md
@@ -0,0 +1,1171 @@
+---
+title: PostgreSQL specific guide
+linkTitle: PostgreSQL
+description: Containerize PostgreSQL databases using Docker
+keywords: Docker, getting started, postgresql, language
+summary: |
+  This guide explains how to containerize PostgreSQL databases using
+  Docker.
+aliases:
+  - /guides/postgresql/advanced-configuration-and-initialization/
+  - /guides/postgresql/companions-for-postgresql/
+  - /guides/postgresql/immediate-setup-and-data-persistence/
+  - /guides/postgresql/networking-and-connectivity/
+params:
+  tags: [databases]
+  time: 20 minutes
+---
+
+
+## Immediate setup & data persistence
+
+This guide gets you from zero to a running PostgreSQL container in under five minutes, then explains how to keep your data safe across container restarts and removals.
+
+### Overview
+
+Running PostgreSQL in Docker requires understanding one critical concept: containers are ephemeral, but your data shouldn't be. This guide covers:
+
+- Starting PostgreSQL with a single command
+- Understanding why containers lose data by default
+- Configuring volumes for persistent storage
+- Translating your setup to Docker Compose
+
+### Quick start (minimal viable container)
+
+> [!NOTE]
+>
+> [Docker Hardened Images (DHIs)](https://docs.docker.com/dhi/) are minimal, secure, and production-ready container base and application images maintained by Docker. DHIs are recommended whenever it is possible for better security. They are designed to reduce vulnerabilities and simplify compliance, freely available to everyone with no subscription required, no usage restrictions, and no vendor lock-in.
+
+Run PostgreSQL immediately with this single command:
+
+{{< tabs >}}
+{{< tab name="Using DHIs" >}}
+
+You must authenticate to dhi.io before you can pull Docker Hardened Images. Run `docker login dhi.io` to authenticate.
+
+```console
+docker run --rm --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 5432:5432 \
+  -d dhi.io/postgres:18
+```
+
+{{< /tab >}}
+
+{{< tab name="Using DOIs" >}}
+
+```console
+$ docker run --rm --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 5432:5432 \
+  -d postgres:18
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+#### Understanding the flags
+
+| Flag | Purpose |
+|------|---------|
+| `--rm` | Automatically removes the container when it stops |
+| `--name postgres-dev` | Assigns a memorable name instead of a random string |
+| `-e POSTGRES_PASSWORD=...` | Sets the superuser password (required) |
+| `-p 5432:5432` | Maps host port 5432 to container port 5432 |
+| `-d` | Runs the container in the background (detached mode) |
+
+Verify the container is running:
+
+```console
+$ docker ps --filter name=postgres-dev
+CONTAINER ID   IMAGE         COMMAND                  STATUS         PORTS                    NAMES
+a1b2c3d4e5f6   postgres:18   "docker-entrypoint.s…"   Up 2 seconds   0.0.0.0:5432->5432/tcp   postgres-dev
+```
+
+Connect using `psql` from inside the container:
+
+```console
+$ docker exec -it postgres-dev psql -U postgres
+psql (18.0)
+Type "help" for help.
+
+postgres=#
+```
+
+You now have a working PostgreSQL instance. But there's a problem—stop this container and your data disappears.
+
+### The data persistence problem
+
+Containers use an ephemeral filesystem. When a container is removed, everything inside it, including your database files, is deleted.
+
+Demonstrate this yourself:
+
+{{< tabs >}}
+{{< tab name="Using DHIs" >}}
+
+```console
+$ docker exec postgres-dev psql -U postgres -c "CREATE DATABASE testdb;"
+CREATE DATABASE
+
+$ docker exec postgres-dev psql -U postgres -c "\l" | grep testdb
+ testdb    | postgres | UTF8     | libc            | en_US.utf8 | en_US.utf8 |            |           |
+
+$ docker stop postgres-dev
+postgres-dev
+
+$ docker run --rm --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 5432:5432 \
+  -d dhi.io/postgres:18
+
+$ docker exec postgres-dev psql -U postgres -c "\l" | grep testdb
+(no output - database is gone)
+```
+
+{{< /tab >}}
+
+{{< tab name="Using DOIs" >}}
+
+```console
+$ docker exec postgres-dev psql -U postgres -c "CREATE DATABASE testdb;"
+CREATE DATABASE
+
+$ docker exec postgres-dev psql -U postgres -c "\l" | grep testdb
+ testdb    | postgres | UTF8     | libc            | en_US.utf8 | en_US.utf8 |            |           |
+
+$ docker stop postgres-dev
+postgres-dev
+
+$ docker run --rm --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 5432:5432 \
+  -d postgres:18
+
+$ docker exec postgres-dev psql -U postgres -c "\l" | grep testdb
+(no output - database is gone)
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Your `testdb` database vanished because the new container started with a fresh filesystem. This is expected behavior—and exactly why volumes exist.
+
+### Named volumes
+
+Named volumes are Docker-managed storage locations that persist independently of containers. Docker handles the filesystem location, permissions, and lifecycle.
+
+Create a container with a named volume:
+
+{{< tabs >}}
+{{< tab name="Using DHIs" >}}
+
+You must authenticate to dhi.io before you can pull Docker Hardened Images. Run `docker login dhi.io` to authenticate.
+
+```console
+$ docker run --rm --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 5432:5432 \
+  -v postgres_data:/var/lib/postgresql \
+  -d dhi.io/postgres:18
+```
+
+{{< /tab >}}
+
+{{< tab name="Using DOIs" >}}
+
+```console
+$ docker run --rm --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 5432:5432 \
+  -v postgres_data:/var/lib/postgresql \
+  -d postgres:18
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+
+The `-v postgres_data:/var/lib/postgresql` flag mounts a named volume called `postgres_data` to PostgreSQL's data directory. If the volume doesn't exist, Docker creates it automatically.
+
+> [!NOTE]
+>
+> PostgreSQL 18+ stores data in a version-specific subdirectory under `/var/lib/postgresql`. Mounting at this level (rather than `/var/lib/postgresql/data`) allows for easier upgrades using `pg_upgrade --link`.
+
+#### Verify persistence works
+
+To verify data persistence, repeat the previous test, but this time with the named volume attached in place.
+
+{{< tabs >}}
+{{< tab name="Using DHIs" >}}
+
+```console
+$ docker exec postgres-dev psql -U postgres -c "CREATE DATABASE testdb;"
+CREATE DATABASE
+
+$ docker stop postgres-dev
+postgres-dev
+
+$ docker run --rm --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 5432:5432 \
+  -v postgres_data:/var/lib/postgresql \
+  -d dhi.io/postgres:18
+
+$ docker exec postgres-dev psql -U postgres -c "\l" | grep testdb
+ testdb    | postgres | UTF8     | libc            | en_US.utf8 | en_US.utf8 |            |           |
+```
+
+{{< /tab >}}
+
+{{< tab name="Using DOIs" >}}
+
+```console
+$ docker exec postgres-dev psql -U postgres -c "CREATE DATABASE testdb;"
+CREATE DATABASE
+
+$ docker stop postgres-dev
+postgres-dev
+
+$ docker run --rm --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 5432:5432 \
+  -v postgres_data:/var/lib/postgresql \
+  -d postgres:18
+
+$ docker exec postgres-dev psql -U postgres -c "\l" | grep testdb
+ testdb    | postgres | UTF8     | libc            | en_US.utf8 | en_US.utf8 |            |           |
+```
+
+{{< /tab >}}
+
+{{< /tabs >}}
+
+If you see `testdb` in the output, persistence works: The database survived because the volume preserved the data directory.
+
+#### Managing volumes
+
+List all volumes:
+
+```console
+$ docker volume ls --filter name=postgres_data
+DRIVER    VOLUME NAME
+local     postgres_data
+```
+
+Inspect a volume to see its details:
+
+```console
+$ docker volume inspect postgres_data
+[
+    {
+        "CreatedAt": "2025-01-05T10:30:00Z",
+        "Driver": "local",
+        "Labels": null,
+        "Mountpoint": "/var/lib/docker/volumes/postgres_data/_data",
+        "Name": "postgres_data",
+        "Options": null,
+        "Scope": "local"
+    }
+]
+```
+
+Remove an unused volume (warning: this deletes all data):
+
+```console
+$ docker volume rm postgres_data
+```
+
+### Bind mounts (alternative)
+
+Bind mounts map a specific host directory to a container path. Unlike named volumes, you control exactly where data lives on the host filesystem.
+
+Create a directory on your host machine to store Postgres data.
+
+{{< tabs >}}
+{{< tab name="Using DHIs" >}}
+
+```console
+mkdir -p ~/postgres-data && sudo chown -R 999:999 ~/postgres-data
+```
+
+Run Postgres using a bind mount.
+
+```console
+docker run --rm --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 5432:5432 \
+  -v ~/postgres-data:/var/lib/postgresql \
+  -d dhi.io/postgres:18
+```
+
+{{< /tab >}}
+
+{{< tab name="Using DOIs" >}}
+
+```console
+$ mkdir -p ~/postgres-data
+```
+
+Run Postgres using a bind mount.
+
+```console
+$ docker run --rm --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 5432:5432 \
+  -v ~/postgres-data:/var/lib/postgresql \
+  -d postgres:18
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+#### When to use bind mounts
+
+Bind mounts are useful when you need direct filesystem access to the data directory for backup scripts that read files directly, when integrating with host-level monitoring tools, or when specific permission requirements exist. For most development and production scenarios, named volumes are simpler and less error-prone.
+
+#### Common bind mount issues
+
+Permission errors are the most frequent problem with bind mounts. PostgreSQL runs as user `postgres` (UID 999) inside the container. If your host directory has restrictive permissions, the container fails to start.
+
+Check logs if the container exits immediately:
+
+```console
+$ docker logs postgres-dev
+```
+
+### Docker Compose configuration
+
+Docker Compose captures your entire configuration in a file, making setups reproducible and easier to manage as complexity grows.
+
+Create a `compose.yaml` file:
+
+```yaml
+services:
+  db:
+    image: postgres:18
+    container_name: postgres-dev
+    environment:
+      POSTGRES_PASSWORD: mysecretpassword
+    ports:
+      - "5432:5432"
+    volumes:
+      - postgres_data:/var/lib/postgresql
+
+volumes:
+  postgres_data:
+```
+
+Start the database:
+
+```console
+$ docker compose up -d
+```
+
+Stop and remove containers (volume persists):
+
+```console
+$ docker compose down
+```
+
+Alternatively, you can stop, remove containers, and delete the volume:
+
+```console
+$ docker compose down -v
+```
+
+This compose file becomes the foundation for adding initialization scripts, performance tuning, and companion services covered in subsequent guides.
+
+#### Environment variables reference
+
+The official PostgreSQL image supports these environment variables:
+
+| Variable | Required | Description |
+|----------|----------|-------------|
+| `POSTGRES_PASSWORD` | Yes | Superuser password |
+| `POSTGRES_USER` | No | Superuser name (default: `postgres`) |
+| `POSTGRES_DB` | No | Default database name (default: value of `POSTGRES_USER`) |
+
+### Next steps
+
+With persistent storage configured, you're ready to customize PostgreSQL further. The next chapter of the guide covers:
+
+- Automated schema creation with initialization scripts
+- Performance tuning for containerized workloads
+- Timezone and locale configuration
+
+## Advanced Configuration and Initialization
+
+With persistent storage configured in the previous section, you're ready to customize PostgreSQL for real-world use. This guide covers advanced configuration techniques for running PostgreSQL in Docker containers, including automated database initialization, performance tuning, and timezone configuration.
+
+### Overview
+
+While PostgreSQL containers can be started quickly with default settings, production environments require customized configurations. This guide explains how to:
+
+- Automate database, schema, and user creation during container startup
+- Tune PostgreSQL performance parameters for containerized workloads
+- Configure timezone and locale settings
+
+### Initialization scripts
+
+The official PostgreSQL Docker image supports running initialization scripts automatically when the container starts for the first time. Any files placed in the `/docker-entrypoint-initdb.d/` directory are executed in alphabetical order.
+
+#### How initialization works
+
+When the container starts, it checks whether the PostgreSQL data directory is empty. If the directory already contains data, PostgreSQL starts immediately without running any initialization. If the directory is empty, the container runs `initdb` to create a new database cluster, then executes all scripts in `/docker-entrypoint-initdb.d/` in alphabetical order before starting PostgreSQL.
+
+#### Supported file formats
+
+| Format | Description |
+|--------|-------------|
+| `.sql` | SQL commands executed directly |
+| `.sql.gz` | Gzip-compressed SQL files |
+| `.sh` | Shell scripts executed with bash |
+
+> [!IMPORTANT]
+>
+> Initialization scripts only run when the PostgreSQL data directory (`/var/lib/postgresql/data`) is empty. If you mount a volume containing existing data, initialization is skipped. This behavior prevents overwriting existing databases.
+
+### Mounting initialization scripts
+
+Use Docker Compose to mount initialization scripts into the container. First, create a project directory:
+
+```console
+$ mkdir -p postgres-project/init-db
+$ cd postgres-project
+```
+
+Create a `compose.yaml` file:
+
+```yaml
+services:
+  db:
+    image: postgres:18
+    volumes:
+      - ./init-db:/docker-entrypoint-initdb.d
+      - postgres_data:/var/lib/postgresql
+    environment:
+      POSTGRES_PASSWORD: mysecretpassword
+
+volumes:
+  postgres_data:
+```
+
+All scripts in the `./init-db` directory execute when the container starts for the first time. This is great for bootstrapping databases.
+
+### Initialization script example
+
+Create a file named `init.sql` in your `init-db` directory:
+
+```sql
+CREATE TABLE users (
+    id SERIAL PRIMARY KEY,
+    email VARCHAR(255) UNIQUE NOT NULL,
+    name VARCHAR(100) NOT NULL,
+    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
+);
+```
+
+This script runs automatically when the container starts for the first time, creating your initial database schema.
+
+> [!NOTE]
+>
+> Ensure initialization scripts have proper read permissions. If you encounter "Permission denied" errors, run `chmod 644 init-db/*.sql` to make the files readable by the container.
+
+### Performance tuning
+
+Default PostgreSQL settings are conservative to work on systems with limited resources. For production workloads, you should tune these parameters based on your container's allocated resources.
+
+#### Method 1: Custom configuration file
+
+For complete control, mount a custom `postgresql.conf` file. First, extract the default configuration:
+
+```console
+$ docker run -i --rm postgres:18 cat /usr/share/postgresql/postgresql.conf.sample > my-postgres.conf
+```
+
+Edit `my-postgres.conf` with your desired settings, then mount it in your Compose file:
+
+```yaml
+services:
+  db:
+    image: postgres:18
+    volumes:
+      - ./my-postgres.conf:/etc/postgresql/postgresql.conf
+      - ./init-db:/docker-entrypoint-initdb.d
+      - postgres_data:/var/lib/postgresql
+    command: postgres -c config_file=/etc/postgresql/postgresql.conf
+    environment:
+      POSTGRES_PASSWORD: mysecretpassword
+
+volumes:
+  postgres_data:
+```
+
+### Key configuration parameters
+
+The following tables list important `postgresql.conf` parameters for containerized PostgreSQL deployments.
+
+#### Connection settings
+
+| Parameter | Description | Default |
+|-----------|-------------|---------|
+| `listen_addresses` | IP addresses to listen on | `localhost` |
+| `port` | TCP port number | `5432` |
+| `max_connections` | Maximum concurrent connections | `100` |
+
+#### Memory settings
+
+| Parameter | Description | Recommended starting value |
+|-----------|-------------|---------------------------|
+| `shared_buffers` | Shared memory for caching | 25% of container memory |
+| `work_mem` | Memory per query operation | 4MB - 64MB |
+| `maintenance_work_mem` | Memory for VACUUM, CREATE INDEX | 64MB - 256MB |
+| `effective_cache_size` | Planner's cache size estimate | 50-75% of container memory |
+
+##### Docker memory limits
+
+When tuning memory parameters, set explicit memory limits on your container using `deploy.resources.limits.memory` in Compose or `--memory` with `docker run`. Without limits, PostgreSQL sees the host's total RAM and may allocate more than intended. For example, if your container should use 4GB maximum, set `shared_buffers` to approximately 1GB (25%).
+
+#### I/O settings
+
+| Parameter | Description | Recommended starting value |
+|-----------|-------------|---------------------------|
+| `effective_io_concurrency` | Concurrent disk I/O operations | `200` for SSDs, `2` for HDDs |
+
+#### Timeout settings
+
+| Parameter | Description | Default |
+|-----------|-------------|---------|
+| `statement_timeout` | Max time for any statement | `0` (disabled) |
+| `lock_timeout` | Max time to wait for a lock | `0` (disabled) |
+| `deadlock_timeout` | Time before checking for deadlock | `1s` |
+| `transaction_timeout` | Max time for a transaction | `0` (disabled) |
+
+> [!NOTE]
+>
+> Setting `shared_buffers` too high in a container can exceed kernel shared memory limits. Use no more than 25-30% of the container's memory limit.
+
+### Timezone and locale configuration
+
+Proper localization ensures timestamps and sorting behave correctly for your application's users.
+
+```yaml
+services:
+  db:
+    image: postgres:18
+    volumes:
+      - postgres_data:/var/lib/postgresql
+      - /etc/localtime:/etc/localtime:ro
+      - /etc/timezone:/etc/timezone:ro
+    environment:
+      POSTGRES_PASSWORD: mysecretpassword
+      TZ: America/New_York
+
+volumes:
+  postgres_data:
+```
+
+Alternatively, set the timezone using a PostgreSQL command-line parameter:
+
+```yaml
+services:
+  db:
+    image: postgres:18
+    command: ["postgres", "-c", "timezone=America/New_York"]
+    environment:
+      POSTGRES_PASSWORD: mysecretpassword
+```
+
+#### Setting the locale
+
+Specify locale settings during database initialization using the `POSTGRES_INITDB_ARGS` environment variable:
+
+```yaml
+services:
+  db:
+    image: postgres:18
+    volumes:
+      - postgres_data:/var/lib/postgresql
+    environment:
+      POSTGRES_PASSWORD: mysecretpassword
+      POSTGRES_INITDB_ARGS: "--encoding=UTF8 --lc-collate=en_US.UTF-8 --lc-ctype=en_US.UTF-8"
+
+volumes:
+  postgres_data:
+```
+
+This affects collation (sorting) and character processing behavior. Changing this variable after database creation has no effect—it only applies during the first run when the data directory is initialized.
+
+### Connecting to the database
+
+You can interact with PostgreSQL running in a container even without `psql` installed on your host machine.
+
+#### Interactive shell
+
+Open a `psql` session inside the container:
+
+```console
+$ docker exec -it postgres-container psql -U postgres
+```
+
+Connect to a specific database:
+
+```console
+$ docker exec -it postgres-container psql -U postgres -d mydb
+```
+
+## Networking and connectivity
+
+This guide covers two common ways to connect to PostgreSQL running in Docker:
+
+- Container-to-container: Connect from your application container to PostgreSQL over a private Docker network. No ports need to be exposed to the host.
+- Host-to-container: Connect from your laptop or development machine using `localhost` and a published port.
+
+Prerequisite: This guide assumes you have PostgreSQL running with persistent storage. If you don't, follow the [Immediate Setup & Data Persistence](/guides/postgresql/immediate-setup-and-data-persistence/) guide first.
+
+### Internal network access (container-to-container)
+
+When your application runs in another container, connecting to PostgreSQL through a user-defined bridge network is the recommended approach. This setup provides automatic DNS resolution, so your application can connect to PostgreSQL using the container name as the hostname, without needing to track IP addresses.
+
+> [!NOTE]
+> Why not use the default bridge network? While containers on the default bridge network can communicate, they can only do so by IP address. Since container IP addresses change when containers restart, this would require updating your PostgreSQL connection strings each time. User-defined bridge networks solve this by providing automatic DNS resolution, ensuring your PostgreSQL connection strings remain stable even if containers restart and receive new IP addresses.
+
+Here's a quick comparison:
+
+> [!NOTE]
+>
+> The following examples show the difference in approach. To actually test this, follow the steps in this guide to set up containers on the appropriate networks first.
+
+With the default bridge network, you'd need to find the IP address first:
+```bash
+# Get the container's IP address (changes on restart)
+docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' postgres-dev
+# Output: 172.17.0.2
+
+# Then connect using that IP address from another container
+# (No --network flag needed - containers default to bridge network)
+docker run --rm -it \
+  -e PGPASSWORD=mysecretpassword \
+  postgres:18 \
+  psql -h 172.17.0.2 -U postgres
+```
+
+With a user-defined network, you simply use the container name:
+```bash
+# Container name works directly - no IP lookup needed
+docker run --rm -it \
+  --network my-app-net \
+  -e PGPASSWORD=mysecretpassword \
+  postgres:18 \
+  psql -h postgres-dev -U postgres
+```
+
+#### Step 1: Create a user-defined network
+
+```bash
+docker network create my-app-net
+
+# Example Output
+ab7f984be43a0ca15534a9ee568716ddbe869a5875077fad3ef3192e3af7d288
+
+docker network ls
+# Output
+ab7f984be43a   my-app-net    bridge    local
+
+
+```
+
+#### Step 2: Run PostgreSQL on that network (no port publishing)
+
+Notice there is no `-p 5432:5432` here. This keeps PostgreSQL internal to Docker and not accessible from the host machine, which is more secure for production environments.
+
+```bash
+docker run -d --name postgres-dev \
+  --network my-app-net \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -v postgres_data:/var/lib/postgresql \
+  postgres:18
+
+  # Output
+CONTAINER ID  IMAGE        COMMAND                 CREATED         STATUS        PORTS     NAMES
+6d351ed89efc  postgres:18  "docker-entrypoint.s…"  9 seconds ago   Up 8 seconds  5432/tcp  postgres-dev
+
+```
+
+#### Step 3: Connect from another container using the Postgres container name
+
+You can test connectivity with a temporary `psql` client container:
+
+```bash
+docker run --rm -it \
+  --network my-app-net \
+  -e PGPASSWORD=mysecretpassword \
+  postgres:18 \
+  psql -h postgres-dev -U postgres
+```
+
+Key point: `-h postgres-dev` works because Docker DNS resolves the container name on a user-defined network. The container name acts as the hostname.
+
+#### Connection string examples
+
+When connecting from your application container, use these PostgreSQL connection strings:
+
+- PostgreSQL URI format:
+  This is the standard PostgreSQL connection URI format that combines all connection parameters into a single string, widely supported by PostgreSQL clients and libraries.
+
+  ```bash
+  postgresql://postgres:mysecretpassword@postgres-dev:5432/postgres
+  ```
+
+  This command demonstrates passing a PostgreSQL URI connection string as an environment variable to a container, which your application can then read to connect to the database.
+
+  Example usage in a Docker run command:
+  ```bash
+  docker run --rm -it \
+    --network my-app-net \
+    -e DATABASE_URL="postgresql://postgres:mysecretpassword@postgres-dev:5432/postgres" \
+    alpine:latest \
+    sh -c 'echo "DATABASE_URL is set to: $DATABASE_URL"'
+  ```
+
+
+- PostgreSQL connection parameters:
+  This format uses key-value pairs separated by spaces, which many PostgreSQL client libraries accept as an alternative to URI format.
+  ```bash
+  host=postgres-dev
+  port=5432
+  user=postgres
+  password=mysecretpassword
+  dbname=postgres
+  ```
+
+  Example usage in application code (Python with psycopg2):
+  ```python
+  conn = psycopg2.connect(
+      host="postgres-dev",
+      port=5432,
+      user="postgres",
+      password="mysecretpassword",
+      dbname="postgres"
+  )
+  ```
+
+- Connecting to a specific database:
+  Replace the database name in the connection string to connect to a specific database instead of the default `postgres` database.
+  If you created a custom database (e.g., `testdb`), use:
+  ```bash
+  postgresql://postgres:mysecretpassword@postgres-dev:5432/testdb
+  ```
+
+  Example with SSL disabled (common in Docker networks):
+  Add `?sslmode=disable` to the connection string when connecting within a private Docker network where SSL encryption isn't required.
+  ```bash
+  postgresql://postgres:mysecretpassword@postgres-dev:5432/testdb?sslmode=disable
+  ```
+
+> [!NOTE]
+>
+> The default port `5432` is used in these examples. If you're connecting to a different PostgreSQL instance or have changed the port, update the connection string accordingly. The container name (`postgres-dev`) is resolved by Docker DNS to the container's IP address on the network.
+
+
+### Connecting from the host (external access)
+
+To connect to PostgreSQL from your host machine using tools like `psql`, `pgAdmin`, `DBeaver`, or database management scripts, you need to publish PostgreSQL's port (`5432`) to the host. This allows external tools to reach the PostgreSQL container.
+
+#### Expose Postgres to localhost only (recommended for development)
+
+This binds to `127.0.0.1` so it's only reachable from your local machine, not from other devices on your network. This is the most secure option for development.
+
+```bash
+docker run -d --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 127.0.0.1:5432:5432 \
+  -v postgres_data:/var/lib/postgresql \
+  postgres:18
+```
+
+Now connect from your host:
+
+- Host: `localhost` or `127.0.0.1`
+- Port: `5432`
+
+If you have `psql` installed on your host:
+```bash
+psql -h localhost -p 5432 -U postgres
+```
+
+You'll be prompted for the password. Alternatively, you can use the `PGPASSWORD` environment variable:
+```bash
+PGPASSWORD=mysecretpassword psql -h localhost -p 5432 -U postgres
+```
+
+#### Connecting with PostgreSQL GUI tools
+
+Popular PostgreSQL GUI tools can connect using these common connection details: Host: `localhost`, Port: `5432`, User: `postgres`, Database: `postgres` (or your database name).
+
+- pgAdmin: A web-based PostgreSQL administration and development platform
+- DBeaver: A universal database tool that supports PostgreSQL and many other databases. Select PostgreSQL as the connection type
+- TablePlus: A modern, native database management tool for macOS and Windows with a clean interface
+
+All tools will prompt for the password you set with `POSTGRES_PASSWORD`.
+
+#### Expose Postgres to all network interfaces (use with caution)
+
+To allow connections from other devices on your network, use `-p 5432:5432` instead of `-p 127.0.0.1:5432:5432`. This binds PostgreSQL to all network interfaces on your host, making it accessible from any device that can reach your host, not just localhost.
+
+```bash
+docker run -d --name postgres-dev \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -p 5432:5432 \
+  -v postgres_data:/var/lib/postgresql \
+  postgres:18
+```
+
+> [!WARNING]
+>
+> Exposing PostgreSQL to all network interfaces (`0.0.0.0:5432`) makes it accessible from any device that can reach your host. Only use this in trusted network environments or behind a firewall. For production, consider using a reverse proxy or VPN instead.
+
+#### PostgreSQL security considerations for external access
+
+When exposing PostgreSQL to external access, follow these PostgreSQL-specific security practices:
+
+- Avoid using the `postgres` superuser: The default `postgres` user has full database privileges. Create dedicated users with only the permissions your application needs.
+- Use strong passwords: PostgreSQL passwords should be complex. Consider using environment variables or secrets management instead of `hardcoding` passwords.
+- Limit network exposure: Binding to `127.0.0.1` (localhost only) is safer than exposing to all interfaces (`0.0.0.0`).
+- Consider SSL/TLS: For production, configure PostgreSQL to require SSL connections. The [Advanced Configuration and Initialization](/guides/postgresql/advanced-configuration-and-initialization/) guide shows how to configure PostgreSQL settings.
+- Create application-specific users: Use initialization scripts to create users with limited privileges. For example, a read-only user for reporting or a user that can only access specific databases.
+
+The [Advanced configuration and initialization](/guides/postgresql/advanced-configuration-and-initialization/) guide shows how to use initialization scripts to create users and roles automatically.
+
+### Using Docker Compose for networking
+
+Docker Compose automatically creates a network for your services, making networking configuration simpler. Here's an example that combines both internal and external access:
+
+```yaml
+services:
+  db:
+    image: postgres:18
+    container_name: postgres-dev
+    environment:
+      POSTGRES_PASSWORD: mysecretpassword
+    volumes:
+      - postgres_data:/var/lib/postgresql
+    ports:
+      - "127.0.0.1:5432:5432"  # Expose to localhost only
+    networks:
+      - app-network
+
+  app:
+    build: ./my-app
+    environment:
+      DATABASE_URL: postgresql://postgres:mysecretpassword@db:5432/mydb
+    networks:
+      - app-network
+    depends_on:
+      - db
+
+volumes:
+  postgres_data:
+
+networks:
+  app-network:
+    driver: bridge
+```
+
+In this PostgreSQL-focused setup:
+- The `app` service connects to PostgreSQL using the service name (`db`) as the hostname in the connection string
+- PostgreSQL is accessible from your host at `localhost:5432` for external tools
+- Both services are isolated on a custom network, providing network-level security
+- The `depends_on` directive ensures PostgreSQL starts before your application
+
+PostgreSQL connection details for the app service:
+- Hostname: `db` (resolved by Docker DNS)
+- Port: `5432` (PostgreSQL default port)
+- Database: `mydb` (as specified in the connection string)
+- User: `postgres` (or a custom user you've created)
+
+> [!NOTE]
+>
+> Docker Compose automatically creates a network for your project. Services can reach each other by service name without explicit network configuration, but defining a custom network gives you more control. For PostgreSQL, this means your application can always connect using the service name, regardless of container restarts or IP changes.
+
+### Troubleshooting
+
+This section covers common PostgreSQL connection issues and their solutions when working with Docker networking.
+
+#### "Could not translate host name postgres-dev"
+
+- Both containers must be on the same Docker network (`my-app-net`).
+- Verify the network exists: `docker network ls`
+- Check which network a container is on: `docker inspect postgres-dev | grep NetworkMode`
+- Ensure you're using a user-defined network, not the default bridge network
+
+#### "Connection refused" or "could not connect to server"
+
+- PostgreSQL may still be initializing: PostgreSQL takes a few seconds to start and initialize the database cluster. Wait 5-10 seconds after container start and retry.
+- Check if the PostgreSQL container is running:
+
+  ```bash
+  docker ps --filter name=postgres-dev
+  ```
+
+- Check PostgreSQL logs for initialization or connection errors:
+
+  ```bash
+  docker logs postgres-dev
+  ```
+
+  Look for messages like "database system is ready to accept connections" to confirm PostgreSQL is fully started.
+
+- Verify the port mapping is correct:
+
+  ```bash
+  docker port postgres-dev
+  ```
+
+  This should show `5432/tcp -> 127.0.0.1:5432` (or `0.0.0.0:5432` if bound to all interfaces).
+
+- Test PostgreSQL connectivity from inside the container:
+
+  ```bash
+  docker exec -it postgres-dev psql -U postgres -c "SELECT version();"
+  ```
+
+  If this works but external connections fail, the issue is with port publishing, not PostgreSQL itself.
+
+#### "Password authentication failed" or "FATAL: password authentication failed for user"
+
+- Confirm the password: Verify you're using the same password set in `POSTGRES_PASSWORD` when you started the container.
+- Existing volume with old credentials: If you reused an existing volume, the password from the original initialization is still in effect. The `POSTGRES_PASSWORD` environment variable only sets the password during the first database initialization. To reset:
+  - Remove the volume: `docker volume rm postgres_data`
+  - Or connect with the old password
+  - Or change the password after connecting: `ALTER USER postgres WITH PASSWORD 'newpassword';`
+- Try connecting with password prompt: `psql -h localhost -U postgres -W` (the `-W` flag forces a password prompt)
+- Use PGPASSWORD environment variable: `PGPASSWORD=mysecretpassword psql -h localhost -U postgres`
+- Check PostgreSQL authentication configuration: If you've customized `pg_hba.conf`, verify the authentication method allows password authentication
+
+#### "Network not found"
+
+- Ensure the network exists before starting containers: `docker network create my-app-net`
+- If using Docker Compose, the network is created automatically when you run `docker compose up`
+
+## Companions for PostgreSQL
+
+### PostgreSQL ecosystem companions: pgAdmin, PgBouncer, and performance testing
+
+Running a standalone PostgreSQL container is often just the beginning. What happens when thousands of connections arrive, or when you need a visual interface to manage your database?
+
+This is where **companion tools** come into play. These applications extend PostgreSQL with capabilities the core database engine doesn't provide natively: visual administration, connection pooling, and performance benchmarking. This guide covers how to deploy pgAdmin 4, PgBouncer, Pgpool-II, and `pgbench` in Docker, when to use each tool, and real-world benchmark results demonstrating their performance impact.
+
+### pgAdmin 4: Visual management platform
+
+pgAdmin 4 is the industry-standard open source management tool for PostgreSQL. When deployed in Docker, it typically runs in **Server Mode**, providing a multi-user web interface to manage one or more database instances.
+
+While you can accomplish everything from the command line using `psql`, a visual interface significantly simplifies writing complex queries, visualizing table structures, and exploring database objects.
+
+#### Key considerations
+
+When running pgAdmin in Docker, keep these points in mind:
+
+- **Image**: Use the official `dpage/pgadmin4` image
+- **Networking**: In a Docker Compose environment, pgAdmin connects to the database using the internal service name (for example, `db:5432`) rather than `localhost`
+
+#### Docker Compose configuration
+
+To quickly deploy pgAdmin:
+
+```yaml
+pgadmin:
+  image: dpage/pgadmin4:8.14
+  environment:
+    PGADMIN_DEFAULT_EMAIL: admin@example.com
+    PGADMIN_DEFAULT_PASSWORD: secure_password
+  volumes:
+    - pgadmin_data:/var/lib/pgadmin
+  ports:
+    - "8080:80"
+```
+
+With this configuration, access the pgAdmin interface at `http://localhost:8080`. Use the email and password specified in the environment variables for initial sign in.
+
+> [!IMPORTANT]
+>
+> In production environments, pass `PGADMIN_DEFAULT_PASSWORD` as an external environment variable or use Docker secrets. Storing passwords in plain text within `docker-compose.yml` poses a security risk.
+
+Now that you have visual database management in place, the next challenge in production environments is handling connection load. The following section explains how to manage high-volume database traffic.
+
+### PgBouncer: Lightweight connection pooling
+
+PostgreSQL creates a new process for every client connection, which consumes significant RAM. What happens when you have 1,000 concurrent users? PgBouncer solves exactly this problem.
+
+PgBouncer is a lightweight proxy that pools connections, allowing thousands of applications to share a small number of actual database backends. Think of it as a traffic controller: everyone wants to pass through simultaneously, but the controller regulates the flow to prevent congestion.
+
+#### Pooling modes
+
+PgBouncer offers three distinct pooling modes:
+
+| Mode | Description | Use case |
+|------|-------------|----------|
+| **Session** | Connection assigned for entire session duration | Long-lived connections, session variables |
+| **Transaction** | Connection returned after each transaction ends | Web applications, microservices (most common) |
+| **Statement** | Connection returned after every SQL statement | Simple queries, no multi-statement transactions |
+
+#### When to use PgBouncer
+
+PgBouncer becomes essential when you encounter:
+
+- "too many connections" errors
+- High memory consumption due to connection overhead
+- Many short-lived connections (web applications, serverless functions)
+- Need to serve thousands of clients with limited database connections
+
+#### Complete Docker Compose setup
+
+To run PostgreSQL and PgBouncer together, you need three files: `docker-compose.yml`, `pgbouncer.ini`, and `userlist.txt`.
+
+First, create the PgBouncer configuration file (`pgbouncer.ini`):
+
+```bash
+[databases]
+benchmark = host=postgres port=5432 dbname=benchmark user=postgres
+
+[pgbouncer]
+listen_addr = 0.0.0.0
+listen_port = 6432
+auth_type = trust
+auth_file = /etc/pgbouncer/userlist.txt
+admin_users = postgres
+pool_mode = transaction
+max_client_conn = 1000
+default_pool_size = 50
+min_pool_size = 10
+reserve_pool_size = 10
+max_db_connections = 100
+```
+
+Next, create the user authentication file (`userlist.txt`):
+
+```bash
+"postgres" "postgres"
+```
+
+Finally, create the Docker Compose file (`docker-compose.yml`):
+
+```yaml
+services:
+  postgres:
+    image: postgres:18
+    container_name: postgres
+    environment:
+      POSTGRES_USER: postgres
+      POSTGRES_PASSWORD: postgres
+      POSTGRES_DB: benchmark
+      POSTGRES_HOST_AUTH_METHOD: trust
+    volumes:
+      - postgres_data:/var/lib/postgresql
+    ports:
+      - "5432:5432"
+    networks:
+      - pgnet
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U postgres"]
+      interval: 5s
+      timeout: 5s
+      retries: 5
+
+  pgbouncer:
+    image: percona/percona-pgbouncer:1.25.0
+    container_name: pgbouncer
+    volumes:
+      - ./pgbouncer.ini:/etc/pgbouncer/pgbouncer.ini
+      - ./userlist.txt:/etc/pgbouncer/userlist.txt
+    ports:
+      - "6432:6432"
+    networks:
+      - pgnet
+    depends_on:
+      postgres:
+        condition: service_healthy
+
+volumes:
+  postgres_data:
+
+networks:
+  pgnet:
+    driver: bridge
+```
+
+Key configuration notes:
+
+- `PgBouncer` listens on port **6432**, avoiding confusion with the direct PostgreSQL connection on port 5432
+- The `depends_on` directive with `service_healthy` condition ensures PgBouncer starts only after PostgreSQL is ready
+- `pool_mode = transaction` is the optimal choice for most web applications
+- The [Percona PgBouncer image](https://hub.docker.com/r/percona/percona-pgbouncer) requires mounted configuration files (without the `:ro` flag, as the entrypoint script needs to modify them)
+- This example uses `trust` authentication for simplicity. In production, configure proper SCRAM-SHA-256 authentication
+
+> [!NOTE]
+>
+> The `Percona PgBouncer` entrypoint script processes the configuration files on startup. Mount them without the read-only flag to avoid permission errors.
+
+
+
+
+### `pgbench`: Performance benchmarking
+
+`pgbench` is a benchmarking utility included with the official PostgreSQL image. It allows you to simulate heavy workloads and verify how your Docker configuration performs under pressure.
+
+#### Initialize benchmark tables
+
+First, create the test tables. The `-s` (scale) parameter determines data size—scale factor 50 creates approximately 5 million rows:
+
+```bash
+docker exec postgres pgbench -i -s 50 -U postgres benchmark
+```
+
+#### Run stress tests
+
+Key parameters:
+
+- `-c`: Number of simulated clients
+- `-j`: Number of threads
+- `-T`: Duration in seconds
+
+Test with direct PostgreSQL connection:
+
+```bash
+docker exec postgres pgbench -h localhost -U postgres -c 50 -j 4 -T 60 benchmark
+```
+
+Test through PgBouncer:
+
+```bash
+docker exec postgres pgbench -h pgbouncer -p 6432 -U postgres -c 50 -j 4 -T 60 benchmark
+```
+
+### Understanding benchmark results
+
+Does PgBouncer actually make a difference? Run the benchmarks yourself to find out. Your results will vary based on your hardware, Docker configuration, network setup, and system load.
+
+#### What to expect
+
+When you run these benchmarks, you'll observe patterns rather than specific numbers. Think of it like comparing two different routes to work: the "faster" route depends on traffic conditions, time of day, and your vehicle.
+
+#### Key observations
+
+When comparing direct connections versus PgBouncer, you'll typically notice:
+
+##### 1. Connection overhead differs significantly
+
+Direct connections require PostgreSQL to spawn a new process for each client. PgBouncer reuses existing connections. Watch the "initial connection time" metric in your results—PgBouncer often shows dramatically faster connection setup.
+
+##### 2. Behavior under pressure reveals the real difference
+
+Try increasing the client count (`-c` parameter) gradually: 50, 100, 150, 200. At some point, direct connections will fail with "too many clients already" while PgBouncer continues handling requests. This is PgBouncer's primary value: **it prevents connection exhaustion**.
+
+##### 3. Throughput varies by environment
+
+On some systems, direct connections show higher transactions per second (TPS) at low concurrency. On others, PgBouncer wins even with few clients. The difference depends on:
+- CPU and memory available
+- Docker networking overhead
+- Disk I/O speed
+- Whether connections are being rapidly opened and closed
+
diff --git a/content/guides/pre-seeding.md b/content/guides/pre-seeding.md
index c7e65b10b626..f3af5342e8e9 100644
--- a/content/guides/pre-seeding.md
+++ b/content/guides/pre-seeding.md
@@ -4,8 +4,8 @@ linktitle: Pre-seeding database
 description: &desc Pre-seeding database with schema and data at startup for development environment
 keywords: Pre-seeding, database, postgres, container-supported development
 summary: *desc
-tags: [app-dev, databases]
 params:
+  tags: [databases]
   time: 20 minutes
 ---
 
@@ -123,7 +123,7 @@ Assuming that you have an existing Postgres database instance up and running, fo
    sampledb=# \l
                                                 List of databases
    Name    |  Owner   | Encoding |  Collate   |   Ctype    | ICU Locale | Locale Provider |   Access privileges
-   -----------+----------+----------+------------+------------+------------+-----------------+-----------------------
+   -----------+----------+----------+------------+------------+------------+-----------------+--------------------
    postgres  | postgres | UTF8     | en_US.utf8 | en_US.utf8 |            | libc            |
    sampledb  | postgres | UTF8     | en_US.utf8 | en_US.utf8 |            | libc            |
    template0 | postgres | UTF8     | en_US.utf8 | en_US.utf8 |            | libc            | =c/postgres          +
@@ -138,7 +138,7 @@ Assuming that you have an existing Postgres database instance up and running, fo
    ```console
    sampledb=# SELECT * FROM users;
    id | name  |       email
-   ----+-------+-------------------
+   ----+-------+----------------
     1 | Alpha | alpha@example.com
     2 | Beta  | beta@example.com
     3 | Gamma | gamma@example.com
@@ -179,7 +179,7 @@ $ docker container stop postgres
 
    ```plaintext
    # syntax=docker/dockerfile:1
-   FROM postgres:latest
+   FROM postgres:18
    COPY seed.sql /docker-entrypoint-initdb.d/
    ```
 
@@ -204,13 +204,13 @@ $ docker container stop postgres
        ports:
          - "5432:5432"
        volumes:
-         - data_sql:/var/lib/postgresql/data   # Persistent data storage
+         - data_sql:/var/lib/postgresql   # Persistent data storage
 
    volumes:
      data_sql:
     ```
   
-    It maps port `5432` on the host to the container's `5432`, let you access to the Postgres database from outside the container. It also define `data_sql` for persisting the database data, ensuring that data is not lost when the container is stopped.
+    It maps port `5432` on the host to the container's `5432`, letting you access the Postgres database from outside the container. It also defines `data_sql` for persisting the database data, ensuring that data is not lost when the container is stopped.
 
     It is important to note that the port mapping to the host is only necessary if you want to connect to the database from non-containerized programs. If you containerize the service that connects to the DB, you should connect to the database over a custom bridge network.
 
@@ -231,7 +231,7 @@ $ docker container stop postgres
     ```sql 
     sampledb=# SELECT * FROM users;
       id | name  |       email
-    ----+-------+-------------------
+    ----+-------+----------------
        1 | Alpha | alpha@example.com
        2 | Beta  | beta@example.com
        3 | Gamma | gamma@example.com
@@ -330,7 +330,7 @@ It is called at the end of the script to initiate the seeding process. The try..
     ```console
     sampledb=# SELECT * FROM todos;
     id |      task      | completed
-    ----+----------------+-----------
+    ----+----------------+--------
     1 | Watch netflix  | f
     2 | Finish podcast | f
     3 | Pick up kid    | f
diff --git a/content/guides/python.md b/content/guides/python.md
new file mode 100644
index 000000000000..116d23ec6d02
--- /dev/null
+++ b/content/guides/python.md
@@ -0,0 +1,2262 @@
+---
+title: Python language-specific guide
+linkTitle: Python
+description: Containerize Python apps using Docker
+keywords: Docker, getting started, Python, language
+summary: |
+  This guide explains how to containerize Python applications using Docker.
+aliases:
+  - /language/python/
+  - /guides/language/python/
+  - /language/python/build-images/
+  - /language/python/run-containers/
+  - /language/python/containerize/
+  - /language/python/develop/
+  - /language/python/configure-ci-cd/
+  - /guides/language/python/configure-ci-cd/
+  - /language/python/deploy/
+  - /guides/python/configure-github-actions/
+  - /guides/python/containerize/
+  - /guides/python/deploy/
+  - /guides/python/develop/
+  - /guides/python/lint-format-typing/
+  - /guides/python/secure-supply-chain/
+params:
+  tags: [languages]
+  time: 20 minutes
+---
+
+> **Acknowledgment**
+>
+> This guide is a community contribution. Docker would like to thank
+> [Esteban Maya](https://www.linkedin.com/in/esteban-x64/) and [Igor Aleksandrov](https://www.linkedin.com/in/igor-aleksandrov/) for their contribution
+> to this guide.
+
+The Python language-specific guide teaches you how to containerize a Python application using Docker. In this guide, you’ll learn how to:
+
+- Containerize and run a Python application
+- Set up a local environment to develop a Python application using containers
+- Lint, format, typing and best practices
+
+Start by containerizing an existing Python application.
+
+## Containerize a Python application
+
+### Prerequisites
+
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
+
+### Overview
+
+Containerizing your application means packaging it together with its
+dependencies, configuration, and runtime into a single portable unit called a
+container image. Running that image creates a container, an isolated process
+that behaves the same on any machine, whether it's your laptop, a CI runner, or
+a production server.
+
+In this section, you'll containerize a simple
+[FastAPI](https://fastapi.tiangolo.com) web application. You'll write a
+`Dockerfile` that describes how to build the image, add a `compose.yaml` file
+that defines how Docker runs your container, and then build and start the
+application with one command.
+
+You'll use [Docker Hardened Images](/dhi/) as the base. These are minimal,
+secure Python images maintained by Docker.
+
+### Create the application
+
+The sample application is a minimal FastAPI service with a single endpoint
+that returns a JSON greeting. Create the following files in a new
+`python-docker-example` directory. To create all the files at once, switch to
+the **Scaffold script** tab in the file browser and copy the shell command.
+
+{{< files name="python-docker-example" >}}
+
+{{< file path="app.py" status="new" >}}
+
+```python
+# A minimal FastAPI application.
+# The root endpoint (GET /) returns a JSON "Hello World" response.
+# See https://fastapi.tiangolo.com/ for the framework reference.
+
+from fastapi import FastAPI
+
+app = FastAPI()
+
+
+@app.get("/")
+async def root():
+    return {"message": "Hello World"}
+```
+
+{{< /file >}}
+
+{{< file path="requirements.txt" status="new" >}}
+
+```text
+# Python package dependencies for the application, pinned for reproducible builds.
+# See https://pip.pypa.io/en/stable/reference/requirements-file-format/
+
+fastapi==0.115.12
+uvicorn==0.34.3
+```
+
+{{< /file >}}
+
+{{< file path=".gitignore" status="new" >}}
+
+```text
+# Files and directories that Git should ignore. This is the standard Python
+# template covering bytecode, build artifacts, virtual environments, and IDE
+# settings. See https://git-scm.com/docs/gitignore for syntax reference.
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Secrets
+db/password.txt
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+If you already have Python installed and want to verify the app works before
+containerizing it, you can run it locally:
+
+```console
+$ python3 -m venv .venv
+$ source .venv/bin/activate
+$ pip install -r requirements.txt
+$ uvicorn app:app --reload
+```
+
+> [!NOTE]
+>
+> On Windows, activate the virtual environment with `.venv\Scripts\activate`
+> instead of `source .venv/bin/activate`.
+
+If you don't have Python installed, skip ahead to the next section. The
+remaining steps run the application in a container, with no local Python
+required.
+
+### Create the Docker assets
+
+Sign in to the DHI registry so Docker can pull the Python base images during
+the build. The available Python images are listed in the
+[catalog](https://hub.docker.com/hardened-images/catalog/dhi/python).
+
+```console
+$ docker login dhi.io
+```
+
+Add the following three files to your `python-docker-example` directory. The
+`Dockerfile` describes how to build the image, `compose.yaml` defines how
+Docker runs the container, and `.dockerignore` keeps unwanted files out of the
+build context.
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for
+> your project. Ask Gordon to create a Dockerfile, Compose file, and
+> `.dockerignore` tailored to your application.
+
+{{< files name="python-docker-example" >}}
+
+{{< file path="app.py" >}}
+
+```python
+# A minimal FastAPI application.
+# The root endpoint (GET /) returns a JSON "Hello World" response.
+# See https://fastapi.tiangolo.com/ for the framework reference.
+
+from fastapi import FastAPI
+
+app = FastAPI()
+
+
+@app.get("/")
+async def root():
+    return {"message": "Hello World"}
+```
+
+{{< /file >}}
+
+{{< file path="requirements.txt" >}}
+
+```text
+# Python package dependencies for the application, pinned for reproducible builds.
+# See https://pip.pypa.io/en/stable/reference/requirements-file-format/
+
+fastapi==0.115.12
+uvicorn==0.34.3
+```
+
+{{< /file >}}
+
+{{< file path="Dockerfile" status="new" >}}
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Dockerfile reference guide at
+# https://docs.docker.com/go/dockerfile-reference/
+
+# This Dockerfile uses Docker Hardened Images (DHI) for enhanced security.
+# For more information, see https://docs.docker.com/dhi/
+
+# Use the dev image to build and install dependencies.
+FROM dhi.io/python:3.12-dev AS builder
+
+WORKDIR /app
+
+RUN python3 -m venv /venv
+ENV PATH="/venv/bin:$PATH"
+
+# Download dependencies as a separate step to take advantage of Docker's caching.
+# Leverage a cache mount to /root/.cache/pip to speed up subsequent builds.
+# Leverage a bind mount to requirements.txt to avoid having to copy them into
+# this layer.
+RUN --mount=type=cache,target=/root/.cache/pip \
+    --mount=type=bind,source=requirements.txt,target=requirements.txt \
+    pip install -r requirements.txt
+
+# Use the minimal runtime image. It runs as nonroot by default.
+FROM dhi.io/python:3.12
+
+WORKDIR /app
+
+COPY --from=builder /venv /venv
+ENV PATH="/venv/bin:$PATH"
+
+# Copy the source code into the container.
+COPY . .
+
+# Expose the port that the application listens on.
+EXPOSE 8000
+
+# Run the application.
+CMD ["/venv/bin/python3", "-m", "uvicorn", "app:app", "--host=0.0.0.0", "--port=8000"]
+```
+
+{{< /file >}}
+
+{{< file path="compose.yaml" status="new" >}}
+
+```yaml
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Docker Compose reference guide at
+# https://docs.docker.com/go/compose-spec-reference/
+
+# Here the instructions define your application as a service called "server".
+# This service is built from the Dockerfile in the current directory.
+# You can add other services your application may depend on here, such as a
+# database or a cache. For examples, see the Awesome Compose repository:
+# https://github.com/docker/awesome-compose
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 8000:8000
+```
+
+{{< /file >}}
+
+{{< file path=".dockerignore" status="new" >}}
+
+```text
+# Include any files or directories that you don't want to be copied to your
+# container here (e.g., local build artifacts, temporary files, etc.).
+#
+# For more help, visit the .dockerignore file reference guide at
+# https://docs.docker.com/go/build-context-dockerignore/
+
+**/.DS_Store
+**/__pycache__
+**/.venv
+**/.classpath
+**/.dockerignore
+**/.env
+**/.git
+**/.gitignore
+**/.project
+**/.settings
+**/.toolstarget
+**/.vs
+**/.vscode
+**/*.*proj.user
+**/*.dbmdl
+**/*.jfm
+**/bin
+**/charts
+**/docker-compose*
+**/compose.y*ml
+**/Dockerfile*
+**/node_modules
+**/npm-debug.log
+**/obj
+**/secrets.dev.yaml
+**/values.dev.yaml
+LICENSE
+README.md
+```
+
+{{< /file >}}
+
+{{< file path=".gitignore" >}}
+
+```text
+# Files and directories that Git should ignore. This is the standard Python
+# template covering bytecode, build artifacts, virtual environments, and IDE
+# settings. See https://git-scm.com/docs/gitignore for syntax reference.
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Secrets
+db/password.txt
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+To learn more about each file, see the following:
+
+- [Dockerfile](/reference/dockerfile.md)
+- [.dockerignore](/reference/dockerfile.md#dockerignore-file)
+- [compose.yaml](/reference/compose-file/_index.md)
+
+### Run the application
+
+Inside the `python-docker-example` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:8000](http://localhost:8000). You should see a simple FastAPI application.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `python-docker-example` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:8000](http://localhost:8000).
+
+To see the OpenAPI docs you can go to [http://localhost:8000/docs](http://localhost:8000/docs).
+
+You should see a simple FastAPI application.
+
+In the terminal, run the following command to stop the application.
+
+```console
+$ docker compose down
+```
+
+For more information about Compose commands, see the [Compose CLI
+reference](/reference/cli/docker/compose/).
+
+## Use containers for Python development
+
+### Prerequisites
+
+Complete [Containerize a Python application](#containerize-a-python-application).
+
+### Overview
+
+Once your application runs in a container, the next step is making the
+container loop part of your everyday development workflow. Code changes should
+show up quickly, and services your app depends on, like databases, should run
+right alongside it.
+
+In this section, you'll extend the project from the previous topic by adding a
+PostgreSQL database service to your `compose.yaml`, persisting the database
+data in a named volume, and enabling Compose Watch so that changes you save in
+your editor are picked up by the running container without a manual rebuild.
+
+### Update the application
+
+You'll update your application to connect to a PostgreSQL database. Continue
+working in your `python-docker-example` directory.
+
+Replace `app.py` and `requirements.txt`, and add a new `config.py` file with the
+following contents.
+
+> [!NOTE]
+>
+> The application won't run yet after this step. It tries to connect to a
+> PostgreSQL database that doesn't exist. The next two sections add the
+> database service and the Docker configuration needed to run everything
+> together.
+
+{{< files name="python-docker-example" >}}
+
+{{< file path="app.py" status="modified" >}}
+
+```python
+# FastAPI application backed by a PostgreSQL database via SQLModel.
+# The FastAPI lifespan handler creates database tables at startup.
+# Endpoints: GET / (greeting), POST /heroes/ (create), GET /heroes/ (list).
+# See https://fastapi.tiangolo.com/ and https://sqlmodel.tiangolo.com/
+
+from collections.abc import AsyncGenerator, Sequence
+from contextlib import asynccontextmanager
+
+from fastapi import FastAPI
+from sqlmodel import Field, Session, SQLModel, create_engine, select
+
+from config import settings
+
+
+class Hero(SQLModel, table=True):
+    id: int | None = Field(default=None, primary_key=True)
+    name: str = Field(index=True)
+    secret_name: str
+    age: int | None = Field(default=None, index=True)
+
+
+engine = create_engine(str(settings.SQLALCHEMY_DATABASE_URI))
+
+
+def create_db_and_tables() -> None:
+    SQLModel.metadata.create_all(engine)
+
+
+@asynccontextmanager
+async def lifespan(_app: FastAPI) -> AsyncGenerator[None, None]:
+    create_db_and_tables()
+    yield
+
+
+app = FastAPI(lifespan=lifespan)
+
+
+@app.get("/")
+def hello() -> str:
+    return "Hello, Docker!"
+
+
+@app.post("/heroes/")
+def create_hero(hero: Hero) -> Hero:
+    with Session(engine) as session:
+        session.add(hero)
+        session.commit()
+        session.refresh(hero)
+        return hero
+
+
+@app.get("/heroes/")
+def read_heroes() -> Sequence[Hero]:
+    with Session(engine) as session:
+        heroes = session.exec(select(Hero)).all()
+        return heroes
+```
+
+{{< /file >}}
+
+{{< file path="config.py" status="new" >}}
+
+```python
+# Pydantic settings that read PostgreSQL connection details from the
+# environment. Supports a password file (Docker secrets) via
+# POSTGRES_PASSWORD_FILE in addition to POSTGRES_PASSWORD.
+# See https://docs.pydantic.dev/latest/concepts/pydantic_settings/
+
+import os
+from typing import Any
+
+from pydantic import (
+    PostgresDsn,
+    computed_field,
+    field_validator,
+    model_validator,
+)
+from pydantic_core import MultiHostUrl
+from pydantic_settings import BaseSettings
+
+
+class Settings(BaseSettings):
+    POSTGRES_SERVER: str
+    POSTGRES_PORT: int = 5432
+    POSTGRES_USER: str
+    POSTGRES_PASSWORD: str | None = None
+    POSTGRES_PASSWORD_FILE: str | None = None
+    POSTGRES_DB: str
+
+    @model_validator(mode="before")
+    @classmethod
+    def check_postgres_password(cls, data: Any) -> Any:
+        """Validate that either POSTGRES_PASSWORD or POSTGRES_PASSWORD_FILE is set."""
+        if isinstance(data, dict):
+            password_file: str | None = data.get("POSTGRES_PASSWORD_FILE")  # type: ignore
+            password: str | None = data.get("POSTGRES_PASSWORD")  # type: ignore
+            if password_file is None and password is None:
+                raise ValueError(
+                    "At least one of POSTGRES_PASSWORD_FILE and POSTGRES_PASSWORD must be set."
+                )
+        return data  # type: ignore
+
+    @field_validator("POSTGRES_PASSWORD_FILE", mode="before")
+    @classmethod
+    def read_password_from_file(cls, v: str | None) -> str | None:
+        if v is not None:
+            file_path = v
+            if os.path.exists(file_path):
+                with open(file_path) as file:
+                    return file.read().strip()
+            raise ValueError(f"Password file {file_path} does not exist.")
+        return v
+
+    @computed_field
+    @property
+    def SQLALCHEMY_DATABASE_URI(self) -> PostgresDsn:
+        url = MultiHostUrl.build(
+            scheme="postgresql+psycopg",
+            username=self.POSTGRES_USER,
+            password=self.POSTGRES_PASSWORD
+            if self.POSTGRES_PASSWORD
+            else self.POSTGRES_PASSWORD_FILE,
+            host=self.POSTGRES_SERVER,
+            port=self.POSTGRES_PORT,
+            path=self.POSTGRES_DB,
+        )
+        return PostgresDsn(url)
+
+
+settings = Settings()  # type: ignore
+```
+
+{{< /file >}}
+
+{{< file path="requirements.txt" status="modified" hl_lines="5-7" >}}
+
+```text
+# Python package dependencies for the application, pinned for reproducible builds.
+# See https://pip.pypa.io/en/stable/reference/requirements-file-format/
+
+fastapi==0.115.12
+sqlmodel==0.0.24
+psycopg[binary]==3.2.9
+pydantic-settings==2.9.1
+uvicorn==0.34.3
+```
+
+{{< /file >}}
+
+{{< file path="Dockerfile" >}}
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Dockerfile reference guide at
+# https://docs.docker.com/go/dockerfile-reference/
+
+# This Dockerfile uses Docker Hardened Images (DHI) for enhanced security.
+# For more information, see https://docs.docker.com/dhi/
+
+# Use the dev image to build and install dependencies.
+FROM dhi.io/python:3.12-dev AS builder
+
+WORKDIR /app
+
+RUN python3 -m venv /venv
+ENV PATH="/venv/bin:$PATH"
+
+# Download dependencies as a separate step to take advantage of Docker's caching.
+# Leverage a cache mount to /root/.cache/pip to speed up subsequent builds.
+# Leverage a bind mount to requirements.txt to avoid having to copy them into
+# this layer.
+RUN --mount=type=cache,target=/root/.cache/pip \
+    --mount=type=bind,source=requirements.txt,target=requirements.txt \
+    pip install -r requirements.txt
+
+# Use the minimal runtime image. It runs as nonroot by default.
+FROM dhi.io/python:3.12
+
+WORKDIR /app
+
+COPY --from=builder /venv /venv
+ENV PATH="/venv/bin:$PATH"
+
+# Copy the source code into the container.
+COPY . .
+
+# Expose the port that the application listens on.
+EXPOSE 8000
+
+# Run the application.
+CMD ["/venv/bin/python3", "-m", "uvicorn", "app:app", "--host=0.0.0.0", "--port=8000"]
+```
+
+{{< /file >}}
+
+{{< file path="compose.yaml" >}}
+
+```yaml
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Docker Compose reference guide at
+# https://docs.docker.com/go/compose-spec-reference/
+
+# Here the instructions define your application as a service called "server".
+# This service is built from the Dockerfile in the current directory.
+# You can add other services your application may depend on here, such as a
+# database or a cache. For examples, see the Awesome Compose repository:
+# https://github.com/docker/awesome-compose
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 8000:8000
+```
+
+{{< /file >}}
+
+{{< file path=".dockerignore" >}}
+
+```text
+# Include any files or directories that you don't want to be copied to your
+# container here (e.g., local build artifacts, temporary files, etc.).
+#
+# For more help, visit the .dockerignore file reference guide at
+# https://docs.docker.com/go/build-context-dockerignore/
+
+**/.DS_Store
+**/__pycache__
+**/.venv
+**/.classpath
+**/.dockerignore
+**/.env
+**/.git
+**/.gitignore
+**/.project
+**/.settings
+**/.toolstarget
+**/.vs
+**/.vscode
+**/*.*proj.user
+**/*.dbmdl
+**/*.jfm
+**/bin
+**/charts
+**/docker-compose*
+**/compose.y*ml
+**/Dockerfile*
+**/node_modules
+**/npm-debug.log
+**/obj
+**/secrets.dev.yaml
+**/values.dev.yaml
+LICENSE
+README.md
+```
+
+{{< /file >}}
+
+{{< file path=".gitignore" >}}
+
+```text
+# Files and directories that Git should ignore. This is the standard Python
+# template covering bytecode, build artifacts, virtual environments, and IDE
+# settings. See https://git-scm.com/docs/gitignore for syntax reference.
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Secrets
+db/password.txt
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+### Update Docker assets
+
+Replace `Dockerfile` and `compose.yaml` with the following.
+
+{{< files name="python-docker-example" >}}
+
+{{< file path="app.py" >}}
+
+```python
+# FastAPI application backed by a PostgreSQL database via SQLModel.
+# The FastAPI lifespan handler creates database tables at startup.
+# Endpoints: GET / (greeting), POST /heroes/ (create), GET /heroes/ (list).
+# See https://fastapi.tiangolo.com/ and https://sqlmodel.tiangolo.com/
+
+from collections.abc import AsyncGenerator, Sequence
+from contextlib import asynccontextmanager
+
+from fastapi import FastAPI
+from sqlmodel import Field, Session, SQLModel, create_engine, select
+
+from config import settings
+
+
+class Hero(SQLModel, table=True):
+    id: int | None = Field(default=None, primary_key=True)
+    name: str = Field(index=True)
+    secret_name: str
+    age: int | None = Field(default=None, index=True)
+
+
+engine = create_engine(str(settings.SQLALCHEMY_DATABASE_URI))
+
+
+def create_db_and_tables() -> None:
+    SQLModel.metadata.create_all(engine)
+
+
+@asynccontextmanager
+async def lifespan(_app: FastAPI) -> AsyncGenerator[None, None]:
+    create_db_and_tables()
+    yield
+
+
+app = FastAPI(lifespan=lifespan)
+
+
+@app.get("/")
+def hello() -> str:
+    return "Hello, Docker!"
+
+
+@app.post("/heroes/")
+def create_hero(hero: Hero) -> Hero:
+    with Session(engine) as session:
+        session.add(hero)
+        session.commit()
+        session.refresh(hero)
+        return hero
+
+
+@app.get("/heroes/")
+def read_heroes() -> Sequence[Hero]:
+    with Session(engine) as session:
+        heroes = session.exec(select(Hero)).all()
+        return heroes
+```
+
+{{< /file >}}
+
+{{< file path="config.py" >}}
+
+```python
+# Pydantic settings that read PostgreSQL connection details from the
+# environment. Supports a password file (Docker secrets) via
+# POSTGRES_PASSWORD_FILE in addition to POSTGRES_PASSWORD.
+# See https://docs.pydantic.dev/latest/concepts/pydantic_settings/
+
+import os
+from typing import Any
+
+from pydantic import (
+    PostgresDsn,
+    computed_field,
+    field_validator,
+    model_validator,
+)
+from pydantic_core import MultiHostUrl
+from pydantic_settings import BaseSettings
+
+
+class Settings(BaseSettings):
+    POSTGRES_SERVER: str
+    POSTGRES_PORT: int = 5432
+    POSTGRES_USER: str
+    POSTGRES_PASSWORD: str | None = None
+    POSTGRES_PASSWORD_FILE: str | None = None
+    POSTGRES_DB: str
+
+    @model_validator(mode="before")
+    @classmethod
+    def check_postgres_password(cls, data: Any) -> Any:
+        """Validate that either POSTGRES_PASSWORD or POSTGRES_PASSWORD_FILE is set."""
+        if isinstance(data, dict):
+            password_file: str | None = data.get("POSTGRES_PASSWORD_FILE")  # type: ignore
+            password: str | None = data.get("POSTGRES_PASSWORD")  # type: ignore
+            if password_file is None and password is None:
+                raise ValueError(
+                    "At least one of POSTGRES_PASSWORD_FILE and POSTGRES_PASSWORD must be set."
+                )
+        return data  # type: ignore
+
+    @field_validator("POSTGRES_PASSWORD_FILE", mode="before")
+    @classmethod
+    def read_password_from_file(cls, v: str | None) -> str | None:
+        if v is not None:
+            file_path = v
+            if os.path.exists(file_path):
+                with open(file_path) as file:
+                    return file.read().strip()
+            raise ValueError(f"Password file {file_path} does not exist.")
+        return v
+
+    @computed_field
+    @property
+    def SQLALCHEMY_DATABASE_URI(self) -> PostgresDsn:
+        url = MultiHostUrl.build(
+            scheme="postgresql+psycopg",
+            username=self.POSTGRES_USER,
+            password=self.POSTGRES_PASSWORD
+            if self.POSTGRES_PASSWORD
+            else self.POSTGRES_PASSWORD_FILE,
+            host=self.POSTGRES_SERVER,
+            port=self.POSTGRES_PORT,
+            path=self.POSTGRES_DB,
+        )
+        return PostgresDsn(url)
+
+
+settings = Settings()  # type: ignore
+```
+
+{{< /file >}}
+
+{{< file path="requirements.txt" >}}
+
+```text
+# Python package dependencies for the application, pinned for reproducible builds.
+# See https://pip.pypa.io/en/stable/reference/requirements-file-format/
+
+fastapi==0.115.12
+sqlmodel==0.0.24
+psycopg[binary]==3.2.9
+pydantic-settings==2.9.1
+uvicorn==0.34.3
+```
+
+{{< /file >}}
+
+{{< file path="Dockerfile" status="modified" hl_lines="11,27-34,37,45" >}}
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Dockerfile reference guide at
+# https://docs.docker.com/go/dockerfile-reference/
+
+# This Dockerfile uses Docker Hardened Images (DHI) for enhanced security.
+# For more information, see https://docs.docker.com/dhi/
+
+# Use the dev image to build and install dependencies.
+# The builder stage is also used directly in development (see compose.yaml).
+FROM dhi.io/python:3.12-dev AS builder
+
+WORKDIR /app
+
+RUN python3 -m venv /venv
+ENV PATH="/venv/bin:$PATH"
+
+# Download dependencies as a separate step to take advantage of Docker's caching.
+# Leverage a cache mount to /root/.cache/pip to speed up subsequent builds.
+# Leverage a bind mount to requirements.txt to avoid having to copy them
+# into this layer.
+RUN --mount=type=cache,target=/root/.cache/pip \
+    --mount=type=bind,source=requirements.txt,target=requirements.txt \
+    pip install -r requirements.txt
+
+# Copy the source code into the container.
+COPY . .
+
+# Expose the port that the application listens on.
+EXPOSE 8000
+
+# Run the application.
+CMD ["/venv/bin/python3", "-m", "uvicorn", "app:app", "--host=0.0.0.0", "--port=8000"]
+
+
+# Use the minimal runtime image for production. It runs as nonroot by default.
+FROM dhi.io/python:3.12
+
+WORKDIR /app
+
+COPY --from=builder /venv /venv
+ENV PATH="/venv/bin:$PATH"
+
+COPY --from=builder /app .
+
+EXPOSE 8000
+
+CMD ["/venv/bin/python3", "-m", "uvicorn", "app:app", "--host=0.0.0.0", "--port=8000"]
+```
+
+{{< /file >}}
+
+{{< file path="compose.yaml" status="modified" hl_lines="8" >}}
+
+```yaml
+services:
+  # Application service. The `target: builder` line builds the development
+  # image (includes a shell and tools); the production stage of the
+  # Dockerfile is unused in development.
+  server:
+    build:
+      context: .
+      target: builder
+    ports:
+      - 8000:8000
+```
+
+{{< /file >}}
+
+{{< file path=".dockerignore" >}}
+
+```text
+# Include any files or directories that you don't want to be copied to your
+# container here (e.g., local build artifacts, temporary files, etc.).
+#
+# For more help, visit the .dockerignore file reference guide at
+# https://docs.docker.com/go/build-context-dockerignore/
+
+**/.DS_Store
+**/__pycache__
+**/.venv
+**/.classpath
+**/.dockerignore
+**/.env
+**/.git
+**/.gitignore
+**/.project
+**/.settings
+**/.toolstarget
+**/.vs
+**/.vscode
+**/*.*proj.user
+**/*.dbmdl
+**/*.jfm
+**/bin
+**/charts
+**/docker-compose*
+**/compose.y*ml
+**/Dockerfile*
+**/node_modules
+**/npm-debug.log
+**/obj
+**/secrets.dev.yaml
+**/values.dev.yaml
+LICENSE
+README.md
+```
+
+{{< /file >}}
+
+{{< file path=".gitignore" >}}
+
+```text
+# Files and directories that Git should ignore. This is the standard Python
+# template covering bytecode, build artifacts, virtual environments, and IDE
+# settings. See https://git-scm.com/docs/gitignore for syntax reference.
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Secrets
+db/password.txt
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+#### About these changes
+
+The `Dockerfile` builder stage now includes `COPY . .` and a `CMD`
+instruction, which makes it directly runnable. This lets Compose target the
+builder stage during development without rebuilding the production stage. The
+production stage at the bottom is unchanged and still produces a minimal,
+nonroot runtime image for shipping.
+
+In `compose.yaml`, the new `target: builder` line tells Compose to build and
+run the builder stage of the Dockerfile during development. Unlike the minimal
+production image, the development image includes a shell and additional tools
+that make debugging easier. If you need a shell in a running production
+container, use [Docker Debug](/reference/cli/docker/debug/) instead.
+
+### Add a local database and persist data
+
+You can use containers to set up local services, like a database. In this
+section, you'll update the `compose.yaml` file to define a database service
+and a volume to persist data, and add a `db/password.txt` file that holds the
+database password.
+
+{{< files name="python-docker-example" >}}
+
+{{< file path="app.py" >}}
+
+```python
+# FastAPI application backed by a PostgreSQL database via SQLModel.
+# The FastAPI lifespan handler creates database tables at startup.
+# Endpoints: GET / (greeting), POST /heroes/ (create), GET /heroes/ (list).
+# See https://fastapi.tiangolo.com/ and https://sqlmodel.tiangolo.com/
+
+from collections.abc import AsyncGenerator, Sequence
+from contextlib import asynccontextmanager
+
+from fastapi import FastAPI
+from sqlmodel import Field, Session, SQLModel, create_engine, select
+
+from config import settings
+
+
+class Hero(SQLModel, table=True):
+    id: int | None = Field(default=None, primary_key=True)
+    name: str = Field(index=True)
+    secret_name: str
+    age: int | None = Field(default=None, index=True)
+
+
+engine = create_engine(str(settings.SQLALCHEMY_DATABASE_URI))
+
+
+def create_db_and_tables() -> None:
+    SQLModel.metadata.create_all(engine)
+
+
+@asynccontextmanager
+async def lifespan(_app: FastAPI) -> AsyncGenerator[None, None]:
+    create_db_and_tables()
+    yield
+
+
+app = FastAPI(lifespan=lifespan)
+
+
+@app.get("/")
+def hello() -> str:
+    return "Hello, Docker!"
+
+
+@app.post("/heroes/")
+def create_hero(hero: Hero) -> Hero:
+    with Session(engine) as session:
+        session.add(hero)
+        session.commit()
+        session.refresh(hero)
+        return hero
+
+
+@app.get("/heroes/")
+def read_heroes() -> Sequence[Hero]:
+    with Session(engine) as session:
+        heroes = session.exec(select(Hero)).all()
+        return heroes
+```
+
+{{< /file >}}
+
+{{< file path="config.py" >}}
+
+```python
+# Pydantic settings that read PostgreSQL connection details from the
+# environment. Supports a password file (Docker secrets) via
+# POSTGRES_PASSWORD_FILE in addition to POSTGRES_PASSWORD.
+# See https://docs.pydantic.dev/latest/concepts/pydantic_settings/
+
+import os
+from typing import Any
+
+from pydantic import (
+    PostgresDsn,
+    computed_field,
+    field_validator,
+    model_validator,
+)
+from pydantic_core import MultiHostUrl
+from pydantic_settings import BaseSettings
+
+
+class Settings(BaseSettings):
+    POSTGRES_SERVER: str
+    POSTGRES_PORT: int = 5432
+    POSTGRES_USER: str
+    POSTGRES_PASSWORD: str | None = None
+    POSTGRES_PASSWORD_FILE: str | None = None
+    POSTGRES_DB: str
+
+    @model_validator(mode="before")
+    @classmethod
+    def check_postgres_password(cls, data: Any) -> Any:
+        """Validate that either POSTGRES_PASSWORD or POSTGRES_PASSWORD_FILE is set."""
+        if isinstance(data, dict):
+            password_file: str | None = data.get("POSTGRES_PASSWORD_FILE")  # type: ignore
+            password: str | None = data.get("POSTGRES_PASSWORD")  # type: ignore
+            if password_file is None and password is None:
+                raise ValueError(
+                    "At least one of POSTGRES_PASSWORD_FILE and POSTGRES_PASSWORD must be set."
+                )
+        return data  # type: ignore
+
+    @field_validator("POSTGRES_PASSWORD_FILE", mode="before")
+    @classmethod
+    def read_password_from_file(cls, v: str | None) -> str | None:
+        if v is not None:
+            file_path = v
+            if os.path.exists(file_path):
+                with open(file_path) as file:
+                    return file.read().strip()
+            raise ValueError(f"Password file {file_path} does not exist.")
+        return v
+
+    @computed_field
+    @property
+    def SQLALCHEMY_DATABASE_URI(self) -> PostgresDsn:
+        url = MultiHostUrl.build(
+            scheme="postgresql+psycopg",
+            username=self.POSTGRES_USER,
+            password=self.POSTGRES_PASSWORD
+            if self.POSTGRES_PASSWORD
+            else self.POSTGRES_PASSWORD_FILE,
+            host=self.POSTGRES_SERVER,
+            port=self.POSTGRES_PORT,
+            path=self.POSTGRES_DB,
+        )
+        return PostgresDsn(url)
+
+
+settings = Settings()  # type: ignore
+```
+
+{{< /file >}}
+
+{{< file path="requirements.txt" >}}
+
+```text
+# Python package dependencies for the application, pinned for reproducible builds.
+# See https://pip.pypa.io/en/stable/reference/requirements-file-format/
+
+fastapi==0.115.12
+sqlmodel==0.0.24
+psycopg[binary]==3.2.9
+pydantic-settings==2.9.1
+uvicorn==0.34.3
+```
+
+{{< /file >}}
+
+{{< file path="Dockerfile" >}}
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Dockerfile reference guide at
+# https://docs.docker.com/go/dockerfile-reference/
+
+# This Dockerfile uses Docker Hardened Images (DHI) for enhanced security.
+# For more information, see https://docs.docker.com/dhi/
+
+# Use the dev image to build and install dependencies.
+# The builder stage is also used directly in development (see compose.yaml).
+FROM dhi.io/python:3.12-dev AS builder
+
+WORKDIR /app
+
+RUN python3 -m venv /venv
+ENV PATH="/venv/bin:$PATH"
+
+# Download dependencies as a separate step to take advantage of Docker's caching.
+# Leverage a cache mount to /root/.cache/pip to speed up subsequent builds.
+# Leverage a bind mount to requirements.txt to avoid having to copy them
+# into this layer.
+RUN --mount=type=cache,target=/root/.cache/pip \
+    --mount=type=bind,source=requirements.txt,target=requirements.txt \
+    pip install -r requirements.txt
+
+# Copy the source code into the container.
+COPY . .
+
+# Expose the port that the application listens on.
+EXPOSE 8000
+
+# Run the application.
+CMD ["/venv/bin/python3", "-m", "uvicorn", "app:app", "--host=0.0.0.0", "--port=8000"]
+
+
+# Use the minimal runtime image for production. It runs as nonroot by default.
+FROM dhi.io/python:3.12
+
+WORKDIR /app
+
+COPY --from=builder /venv /venv
+ENV PATH="/venv/bin:$PATH"
+
+COPY --from=builder /app .
+
+EXPOSE 8000
+
+CMD ["/venv/bin/python3", "-m", "uvicorn", "app:app", "--host=0.0.0.0", "--port=8000"]
+```
+
+{{< /file >}}
+
+{{< file path="compose.yaml" status="modified" hl_lines="11-46" >}}
+
+```yaml
+services:
+  # Application service. The `target: builder` line builds the development
+  # image (includes a shell and tools); the production stage of the
+  # Dockerfile is unused in development.
+  server:
+    build:
+      context: .
+      target: builder
+    ports:
+      - 8000:8000
+    environment:
+      - POSTGRES_SERVER=db
+      - POSTGRES_USER=postgres
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    depends_on:
+      db:
+        condition: service_healthy
+    secrets:
+      - db-password
+  # Database service. Reads the password from a Docker secret mounted at
+  # /run/secrets/db-password. Compose waits for the healthcheck to pass
+  # before starting the server, via the server's depends_on.
+  db:
+    image: dhi.io/postgres:18
+    restart: always
+    user: postgres
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    expose:
+      - 5432
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+{{< /file >}}
+
+{{< file path="db/password.txt" status="new" >}}
+
+```text
+mysecretpassword
+```
+
+{{< /file >}}
+
+{{< file path=".dockerignore" >}}
+
+```text
+# Include any files or directories that you don't want to be copied to your
+# container here (e.g., local build artifacts, temporary files, etc.).
+#
+# For more help, visit the .dockerignore file reference guide at
+# https://docs.docker.com/go/build-context-dockerignore/
+
+**/.DS_Store
+**/__pycache__
+**/.venv
+**/.classpath
+**/.dockerignore
+**/.env
+**/.git
+**/.gitignore
+**/.project
+**/.settings
+**/.toolstarget
+**/.vs
+**/.vscode
+**/*.*proj.user
+**/*.dbmdl
+**/*.jfm
+**/bin
+**/charts
+**/docker-compose*
+**/compose.y*ml
+**/Dockerfile*
+**/node_modules
+**/npm-debug.log
+**/obj
+**/secrets.dev.yaml
+**/values.dev.yaml
+LICENSE
+README.md
+```
+
+{{< /file >}}
+
+{{< file path=".gitignore" >}}
+
+```text
+# Files and directories that Git should ignore. This is the standard Python
+# template covering bytecode, build artifacts, virtual environments, and IDE
+# settings. See https://git-scm.com/docs/gitignore for syntax reference.
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Secrets
+db/password.txt
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+> [!NOTE]
+>
+> To learn more about the instructions in the Compose file, see [Compose file
+> reference](/reference/compose-file/).
+
+Now, run the following `docker compose up` command to start your application.
+
+```console
+$ docker compose up --build
+```
+
+Now test your API endpoint. Open a new terminal then make a request to the server using the curl commands:
+
+Create an object with a POST request:
+
+```console
+$ curl -X 'POST' \
+  'http://localhost:8000/heroes/' \
+  -H 'accept: application/json' \
+  -H 'Content-Type: application/json' \
+  -d '{
+  "id": 1,
+  "name": "my hero",
+  "secret_name": "austing",
+  "age": 12
+}'
+```
+
+You should receive the following response:
+
+```json
+{
+  "age": 12,
+  "id": 1,
+  "name": "my hero",
+  "secret_name": "austing"
+}
+```
+
+Now make a GET request:
+
+```console
+$ curl -X 'GET' \
+  'http://localhost:8000/heroes/' \
+  -H 'accept: application/json'
+```
+
+You should receive the same response as above because it's the only object in the database.
+
+```json
+{
+  "age": 12,
+  "id": 1,
+  "name": "my hero",
+  "secret_name": "austing"
+}
+```
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Automatically update services
+
+Use Compose Watch to automatically update your running Compose services as you
+edit and save your code. For more details about Compose Watch, see [Use Compose
+Watch](/manuals/compose/how-tos/file-watch.md).
+
+Open your `compose.yaml` file in an IDE or text editor and add the highlighted
+Compose Watch instructions.
+
+{{< files name="python-docker-example" >}}
+
+{{< file path="app.py" >}}
+
+```python
+# FastAPI application backed by a PostgreSQL database via SQLModel.
+# The FastAPI lifespan handler creates database tables at startup.
+# Endpoints: GET / (greeting), POST /heroes/ (create), GET /heroes/ (list).
+# See https://fastapi.tiangolo.com/ and https://sqlmodel.tiangolo.com/
+
+from collections.abc import AsyncGenerator, Sequence
+from contextlib import asynccontextmanager
+
+from fastapi import FastAPI
+from sqlmodel import Field, Session, SQLModel, create_engine, select
+
+from config import settings
+
+
+class Hero(SQLModel, table=True):
+    id: int | None = Field(default=None, primary_key=True)
+    name: str = Field(index=True)
+    secret_name: str
+    age: int | None = Field(default=None, index=True)
+
+
+engine = create_engine(str(settings.SQLALCHEMY_DATABASE_URI))
+
+
+def create_db_and_tables() -> None:
+    SQLModel.metadata.create_all(engine)
+
+
+@asynccontextmanager
+async def lifespan(_app: FastAPI) -> AsyncGenerator[None, None]:
+    create_db_and_tables()
+    yield
+
+
+app = FastAPI(lifespan=lifespan)
+
+
+@app.get("/")
+def hello() -> str:
+    return "Hello, Docker!"
+
+
+@app.post("/heroes/")
+def create_hero(hero: Hero) -> Hero:
+    with Session(engine) as session:
+        session.add(hero)
+        session.commit()
+        session.refresh(hero)
+        return hero
+
+
+@app.get("/heroes/")
+def read_heroes() -> Sequence[Hero]:
+    with Session(engine) as session:
+        heroes = session.exec(select(Hero)).all()
+        return heroes
+```
+
+{{< /file >}}
+
+{{< file path="config.py" >}}
+
+```python
+# Pydantic settings that read PostgreSQL connection details from the
+# environment. Supports a password file (Docker secrets) via
+# POSTGRES_PASSWORD_FILE in addition to POSTGRES_PASSWORD.
+# See https://docs.pydantic.dev/latest/concepts/pydantic_settings/
+
+import os
+from typing import Any
+
+from pydantic import (
+    PostgresDsn,
+    computed_field,
+    field_validator,
+    model_validator,
+)
+from pydantic_core import MultiHostUrl
+from pydantic_settings import BaseSettings
+
+
+class Settings(BaseSettings):
+    POSTGRES_SERVER: str
+    POSTGRES_PORT: int = 5432
+    POSTGRES_USER: str
+    POSTGRES_PASSWORD: str | None = None
+    POSTGRES_PASSWORD_FILE: str | None = None
+    POSTGRES_DB: str
+
+    @model_validator(mode="before")
+    @classmethod
+    def check_postgres_password(cls, data: Any) -> Any:
+        """Validate that either POSTGRES_PASSWORD or POSTGRES_PASSWORD_FILE is set."""
+        if isinstance(data, dict):
+            password_file: str | None = data.get("POSTGRES_PASSWORD_FILE")  # type: ignore
+            password: str | None = data.get("POSTGRES_PASSWORD")  # type: ignore
+            if password_file is None and password is None:
+                raise ValueError(
+                    "At least one of POSTGRES_PASSWORD_FILE and POSTGRES_PASSWORD must be set."
+                )
+        return data  # type: ignore
+
+    @field_validator("POSTGRES_PASSWORD_FILE", mode="before")
+    @classmethod
+    def read_password_from_file(cls, v: str | None) -> str | None:
+        if v is not None:
+            file_path = v
+            if os.path.exists(file_path):
+                with open(file_path) as file:
+                    return file.read().strip()
+            raise ValueError(f"Password file {file_path} does not exist.")
+        return v
+
+    @computed_field
+    @property
+    def SQLALCHEMY_DATABASE_URI(self) -> PostgresDsn:
+        url = MultiHostUrl.build(
+            scheme="postgresql+psycopg",
+            username=self.POSTGRES_USER,
+            password=self.POSTGRES_PASSWORD
+            if self.POSTGRES_PASSWORD
+            else self.POSTGRES_PASSWORD_FILE,
+            host=self.POSTGRES_SERVER,
+            port=self.POSTGRES_PORT,
+            path=self.POSTGRES_DB,
+        )
+        return PostgresDsn(url)
+
+
+settings = Settings()  # type: ignore
+```
+
+{{< /file >}}
+
+{{< file path="requirements.txt" >}}
+
+```text
+# Python package dependencies for the application, pinned for reproducible builds.
+# See https://pip.pypa.io/en/stable/reference/requirements-file-format/
+
+fastapi==0.115.12
+sqlmodel==0.0.24
+psycopg[binary]==3.2.9
+pydantic-settings==2.9.1
+uvicorn==0.34.3
+```
+
+{{< /file >}}
+
+{{< file path="Dockerfile" >}}
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Dockerfile reference guide at
+# https://docs.docker.com/go/dockerfile-reference/
+
+# This Dockerfile uses Docker Hardened Images (DHI) for enhanced security.
+# For more information, see https://docs.docker.com/dhi/
+
+# Use the dev image to build and install dependencies.
+# The builder stage is also used directly in development (see compose.yaml).
+FROM dhi.io/python:3.12-dev AS builder
+
+WORKDIR /app
+
+RUN python3 -m venv /venv
+ENV PATH="/venv/bin:$PATH"
+
+# Download dependencies as a separate step to take advantage of Docker's caching.
+# Leverage a cache mount to /root/.cache/pip to speed up subsequent builds.
+# Leverage a bind mount to requirements.txt to avoid having to copy them
+# into this layer.
+RUN --mount=type=cache,target=/root/.cache/pip \
+    --mount=type=bind,source=requirements.txt,target=requirements.txt \
+    pip install -r requirements.txt
+
+# Copy the source code into the container.
+COPY . .
+
+# Expose the port that the application listens on.
+EXPOSE 8000
+
+# Run the application.
+CMD ["/venv/bin/python3", "-m", "uvicorn", "app:app", "--host=0.0.0.0", "--port=8000"]
+
+
+# Use the minimal runtime image for production. It runs as nonroot by default.
+FROM dhi.io/python:3.12
+
+WORKDIR /app
+
+COPY --from=builder /venv /venv
+ENV PATH="/venv/bin:$PATH"
+
+COPY --from=builder /app .
+
+EXPOSE 8000
+
+CMD ["/venv/bin/python3", "-m", "uvicorn", "app:app", "--host=0.0.0.0", "--port=8000"]
+```
+
+{{< /file >}}
+
+{{< file path="compose.yaml" status="modified" hl_lines="21-24" >}}
+
+```yaml
+services:
+  # Application service. The `target: builder` line builds the development
+  # image (includes a shell and tools); the production stage of the
+  # Dockerfile is unused in development.
+  server:
+    build:
+      context: .
+      target: builder
+    ports:
+      - 8000:8000
+    environment:
+      - POSTGRES_SERVER=db
+      - POSTGRES_USER=postgres
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    depends_on:
+      db:
+        condition: service_healthy
+    secrets:
+      - db-password
+    develop:
+      watch:
+        - action: rebuild
+          path: .
+  db:
+    image: dhi.io/postgres:18
+    restart: always
+    user: postgres
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    expose:
+      - 5432
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+{{< /file >}}
+
+{{< file path="db/password.txt" >}}
+
+```text
+mysecretpassword
+```
+
+{{< /file >}}
+
+{{< file path=".dockerignore" >}}
+
+```text
+# Include any files or directories that you don't want to be copied to your
+# container here (e.g., local build artifacts, temporary files, etc.).
+#
+# For more help, visit the .dockerignore file reference guide at
+# https://docs.docker.com/go/build-context-dockerignore/
+
+**/.DS_Store
+**/__pycache__
+**/.venv
+**/.classpath
+**/.dockerignore
+**/.env
+**/.git
+**/.gitignore
+**/.project
+**/.settings
+**/.toolstarget
+**/.vs
+**/.vscode
+**/*.*proj.user
+**/*.dbmdl
+**/*.jfm
+**/bin
+**/charts
+**/docker-compose*
+**/compose.y*ml
+**/Dockerfile*
+**/node_modules
+**/npm-debug.log
+**/obj
+**/secrets.dev.yaml
+**/values.dev.yaml
+LICENSE
+README.md
+```
+
+{{< /file >}}
+
+{{< file path=".gitignore" >}}
+
+```text
+# Files and directories that Git should ignore. This is the standard Python
+# template covering bytecode, build artifacts, virtual environments, and IDE
+# settings. See https://git-scm.com/docs/gitignore for syntax reference.
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Secrets
+db/password.txt
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+Run the following command to run your application with Compose Watch.
+
+```console
+$ docker compose watch
+```
+
+In a terminal, curl the application to get a response.
+
+```console
+$ curl http://localhost:8000
+Hello, Docker!
+```
+
+Any changes to the application's source files on your local machine will now be immediately reflected in the running container.
+
+Open `python-docker-example/app.py` in an IDE or text editor and update the `Hello, Docker!` string by adding a few more exclamation marks.
+
+```diff
+-    return 'Hello, Docker!'
++    return 'Hello, Docker!!!'
+```
+
+Save the changes to `app.py` and then wait a few seconds for the application to rebuild. Curl the application again and verify that the updated text appears.
+
+```console
+$ curl http://localhost:8000
+Hello, Docker!!!
+```
+
+Press `ctrl+c` in the terminal to stop your application.
+
+## Linting, formatting, and type checking for Python
+
+### Prerequisites
+
+Complete [Develop your app](#use-containers-for-python-development). This topic requires a local Python
+installation because the tools and Git hooks introduced here run on your
+host. If you don't want to install Python locally, skip this topic. You can
+also run the same checks in CI.
+
+### Overview
+
+Linting, formatting, and type checking are automated ways to catch bugs,
+enforce style, and spot type errors before code runs. Running them on every
+commit, in CI, and in your editor catches problems early when they're cheap
+to fix.
+
+In this section, you'll configure three tools for your Python application.
+Ruff handles linting and formatting in a single fast pass. Pyright statically
+checks your code for type errors. Pre-commit hooks run both of these
+automatically before each Git commit so problems are caught locally before
+they're committed.
+
+### Linting and formatting with Ruff
+
+Ruff is an extremely fast Python linter and formatter written in Rust. It replaces multiple tools like flake8, isort, and black with a single unified tool.
+
+Create a `pyproject.toml` file in your `python-docker-example` directory:
+
+{{< files name="python-docker-example" >}}
+
+{{< file path="pyproject.toml" status="new" >}}
+
+```toml
+# Configuration for code-quality tools.
+# - [tool.ruff]: linting and formatting (https://docs.astral.sh/ruff/)
+# - [tool.pyright]: static type checking (https://microsoft.github.io/pyright/)
+
+[tool.ruff]
+target-version = "py312"
+
+[tool.ruff.lint]
+select = [
+    "E",  # pycodestyle errors
+    "W",  # pycodestyle warnings
+    "F",  # pyflakes
+    "I",  # isort
+    "B",  # flake8-bugbear
+    "C4",  # flake8-comprehensions
+    "UP",  # pyupgrade
+    "ARG001", # unused arguments in functions
+]
+ignore = [
+    "E501",  # line too long, handled by black
+    "B008",  # do not perform function calls in argument defaults
+    "W191",  # indentation contains tabs
+    "B904",  # Allow raising exceptions without from e, for HTTPException
+]
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+Install Ruff:
+
+```console
+$ pip install ruff
+```
+
+If you're using a virtual environment, make sure it is activated so the `ruff`
+command is available.
+
+Run these commands to check and format your code:
+
+```console
+# Check for errors
+$ ruff check .
+
+# Automatically fix fixable errors
+$ ruff check --fix .
+
+# Format code
+$ ruff format .
+```
+
+### Type checking with Pyright
+
+Pyright is a fast static type checker for Python that works well with modern Python features.
+
+Update `pyproject.toml` to add the Pyright configuration at the bottom.
+
+{{< files name="python-docker-example" >}}
+
+{{< file path="pyproject.toml" status="modified" hl_lines="25-29" >}}
+
+```toml
+# Configuration for code-quality tools.
+# - [tool.ruff]: linting and formatting (https://docs.astral.sh/ruff/)
+# - [tool.pyright]: static type checking (https://microsoft.github.io/pyright/)
+
+[tool.ruff]
+target-version = "py312"
+
+[tool.ruff.lint]
+select = [
+    "E",  # pycodestyle errors
+    "W",  # pycodestyle warnings
+    "F",  # pyflakes
+    "I",  # isort
+    "B",  # flake8-bugbear
+    "C4",  # flake8-comprehensions
+    "UP",  # pyupgrade
+    "ARG001", # unused arguments in functions
+]
+ignore = [
+    "E501",  # line too long, handled by black
+    "B008",  # do not perform function calls in argument defaults
+    "W191",  # indentation contains tabs
+    "B904",  # Allow raising exceptions without from e, for HTTPException
+]
+
+[tool.pyright]
+typeCheckingMode = "strict"
+pythonVersion = "3.12"
+exclude = [".venv"]
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+Install Pyright and run it:
+
+```console
+$ pip install pyright
+$ pyright
+```
+
+### Setting up pre-commit hooks
+
+Pre-commit hooks run checks automatically before each commit on your local
+machine. Create a `.pre-commit-config.yaml` file in your `python-docker-example`
+directory to set up Ruff hooks:
+
+{{< files name="python-docker-example" >}}
+
+{{< file path=".pre-commit-config.yaml" status="new" >}}
+
+```yaml
+# Pre-commit hook configuration. Runs Ruff (lint + format) on every
+# `git commit`. See https://pre-commit.com/
+
+repos:
+  - repo: https://github.com/astral-sh/ruff-pre-commit
+    rev: v0.15.15
+    hooks:
+      - id: ruff
+        args: [--fix]
+      - id: ruff-format
+```
+
+{{< /file >}}
+
+{{< /files >}}
+
+To install and use:
+
+```console
+$ pip install pre-commit
+$ pre-commit install
+$ git commit -m "Test commit"  # Automatically runs checks
+```
+
+### Summary
+
+In this section, you learned how to:
+
+- Configure and use Ruff for linting and formatting
+- Set up Pyright for static type checking
+- Automate checks with pre-commit hooks
+
+These tools help maintain code quality and catch errors early in development.
+
+Related information:
+
+- [Ruff documentation](https://docs.astral.sh/ruff/)
+- [Pyright documentation](https://microsoft.github.io/pyright/)
+- [pre-commit framework](https://pre-commit.com/)
+
+### Next steps
+
+- Customize linting rules to match your team's style preferences
+- Explore advanced type checking features
diff --git a/content/guides/python/_index.md b/content/guides/python/_index.md
deleted file mode 100644
index 221c540f1ed4..000000000000
--- a/content/guides/python/_index.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Python language-specific guide
-linkTitle: Python
-description: Containerize Python apps using Docker
-keywords: Docker, getting started, Python, language
-summary: |
-  This guide explains how to containerize Python applications using Docker.
-toc_min: 1
-toc_max: 2
-aliases:
-  - /language/python/
-  - /guides/language/python/
-languages: [python]
-params:
-  time: 20 minutes
----
-
-The Python language-specific guide teaches you how to containerize a Python application using Docker. In this guide, you’ll learn how to:
-
-- Containerize and run a Python application
-- Set up a local environment to develop a Python application using containers
-- Configure a CI/CD pipeline for a containerized Python application using GitHub Actions
-- Deploy your containerized Python application locally to Kubernetes to test and debug your deployment
-
-Start by containerizing an existing Python application.
diff --git a/content/guides/python/configure-ci-cd.md b/content/guides/python/configure-ci-cd.md
deleted file mode 100644
index f45cca1cf43b..000000000000
--- a/content/guides/python/configure-ci-cd.md
+++ /dev/null
@@ -1,133 +0,0 @@
----
-title: Configure CI/CD for your Python application
-linkTitle: Configure CI/CD
-weight: 40
-keywords: ci/cd, github actions, python, flask
-description: Learn how to configure CI/CD using GitHub Actions for your Python application.
-aliases:
-  - /language/python/configure-ci-cd/
-  - /guides/language/python/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a Python application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-## Overview
-
-In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps:
-
-1. Create a new repository on GitHub.
-2. Define the GitHub Actions workflow.
-3. Run the workflow.
-
-## Step one: Create the repository
-
-Create a GitHub repository, configure the Docker Hub credentials, and push your source code.
-
-1. [Create a new repository](https://github.com/new) on GitHub.
-
-2. Open the repository **Settings**, and go to **Secrets and variables** >
-   **Actions**.
-
-3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-4. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-5. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-6. In your local repository on your machine, run the following command to change
-   the origin to the repository you just created. Make sure you change
-   `your-username` to your GitHub username and `your-repository` to the name of
-   the repository you created.
-
-   ```console
-   $ git remote set-url origin https://github.com/your-username/your-repository.git
-   ```
-
-7. Run the following commands to stage, commit, and push your local repository to GitHub.
-
-   ```console
-   $ git add -A
-   $ git commit -m "my commit"
-   $ git push -u origin main
-   ```
-
-## Step two: Set up the workflow
-
-Set up your GitHub Actions workflow for building, testing, and pushing the image
-to Docker Hub.
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-
-2. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub actions workflow file in
-   your repository, under `.github/workflows/main.yml` by default.
-
-3. In the editor window, copy and paste the following YAML configuration.
-
-   ```yaml
-   name: ci
-
-   on:
-     push:
-       branches:
-         - main
-
-   jobs:
-     build:
-       runs-on: ubuntu-latest
-       steps:
-         - name: Login to Docker Hub
-           uses: docker/login-action@v3
-           with:
-             username: ${{ vars.DOCKER_USERNAME }}
-             password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-         - name: Set up Docker Buildx
-           uses: docker/setup-buildx-action@v3
-
-         - name: Build and push
-           uses: docker/build-push-action@v6
-           with:
-             platforms: linux/amd64,linux/arm64
-             push: true
-             tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-   ```
-
-   For more information about the YAML syntax for `docker/build-push-action`,
-   refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
-## Step three: Run the workflow
-
-Save the workflow file and run the job.
-
-1. Select **Commit changes...** and push the changes to the `main` branch.
-
-   After pushing the commit, the workflow starts automatically.
-
-2. Go to the **Actions** tab. It displays the workflow.
-
-   Selecting the workflow shows you the breakdown of all the steps.
-
-3. When the workflow is complete, go to your
-   [repositories on Docker Hub](https://hub.docker.com/repositories).
-
-   If you see the new repository in that list, it means the GitHub Actions
-   successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your Python application.
-
-Related information:
-
-- [Introduction to GitHub Actions](/guides/gha.md)
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md)
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-Next, learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/python/containerize.md b/content/guides/python/containerize.md
deleted file mode 100644
index 039e81910441..000000000000
--- a/content/guides/python/containerize.md
+++ /dev/null
@@ -1,379 +0,0 @@
----
-title: Containerize a Python application
-linkTitle: Containerize your app
-weight: 10
-keywords: python, flask, containerize, initialize
-description: Learn how to containerize a Python application.
-aliases:
-  - /language/python/build-images/
-  - /language/python/run-containers/
-  - /language/python/containerize/
-  - /guides/language/python/containerize/
----
-
-## Prerequisites
-
-- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
-- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
-
-## Overview
-
-This section walks you through containerizing and running a Python application.
-
-## Get the sample application
-
-The sample application uses the popular [FastAPI](https://fastapi.tiangolo.com) framework.
-
-Clone the sample application to use with this guide. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
-
-```console
-$ git clone https://github.com/estebanx64/python-docker-example && cd python-docker-example
-```
-
-## Initialize Docker assets
-
-Now that you have an application, you can create the necessary Docker assets to
-containerize your application. You can use Docker Desktop's built-in Docker Init
-feature to help streamline the process, or you can manually create the assets.
-
-{{< tabs >}}
-{{< tab name="Use Docker Init" >}}
-
-Inside the `python-docker-example` directory, run the `docker init` command. `docker
-init` provides some default configuration, but you'll need to answer a few
-questions about your application. For example, this application uses FastAPI to
-run. Refer to the following example to answer the prompts from `docker init` and
-use the same answers for your prompts.
-
-```console
-$ docker init
-Welcome to the Docker Init CLI!
-
-This utility will walk you through creating the following files with sensible defaults for your project:
-  - .dockerignore
-  - Dockerfile
-  - compose.yaml
-  - README.Docker.md
-
-Let's get started!
-
-? What application platform does your project use? Python
-? What version of Python do you want to use? 3.11.4
-? What port do you want your app to listen on? 8000
-? What is the command to run your app? python3 -m uvicorn app:app --host=0.0.0.0 --port=8000
-```
-
-Create a file named `.gitignore` with the following contents.
-
-```text {collapse=true,title=".gitignore"}
-# Byte-compiled / optimized / DLL files
-__pycache__/
-*.py[cod]
-*$py.class
-
-# C extensions
-*.so
-
-# Distribution / packaging
-.Python
-build/
-develop-eggs/
-dist/
-downloads/
-eggs/
-.eggs/
-lib/
-lib64/
-parts/
-sdist/
-var/
-wheels/
-share/python-wheels/
-*.egg-info/
-.installed.cfg
-*.egg
-MANIFEST
-
-# Unit test / coverage reports
-htmlcov/
-.tox/
-.nox/
-.coverage
-.coverage.*
-.cache
-nosetests.xml
-coverage.xml
-*.cover
-*.py,cover
-.hypothesis/
-.pytest_cache/
-cover/
-
-# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
-__pypackages__/
-
-# Environments
-.env
-.venv
-env/
-venv/
-ENV/
-env.bak/
-venv.bak/
-```
-
-{{< /tab >}}
-{{< tab name="Manually create assets" >}}
-
-If you don't have Docker Desktop installed or prefer creating the assets
-manually, you can create the following files in your project directory.
-
-Create a file named `Dockerfile` with the following contents.
-
-```dockerfile {collapse=true,title=Dockerfile}
-# syntax=docker/dockerfile:1
-
-# Comments are provided throughout this file to help you get started.
-# If you need more help, visit the Dockerfile reference guide at
-# https://docs.docker.com/go/dockerfile-reference/
-
-# Want to help us make this template better? Share your feedback here: https://forms.gle/ybq9Krt8jtBL3iCk7
-
-ARG PYTHON_VERSION=3.11.4
-FROM python:${PYTHON_VERSION}-slim AS base
-
-# Prevents Python from writing pyc files.
-ENV PYTHONDONTWRITEBYTECODE=1
-
-# Keeps Python from buffering stdout and stderr to avoid situations where
-# the application crashes without emitting any logs due to buffering.
-ENV PYTHONUNBUFFERED=1
-
-WORKDIR /app
-
-# Create a non-privileged user that the app will run under.
-# See https://docs.docker.com/go/dockerfile-user-best-practices/
-ARG UID=10001
-RUN adduser \
-    --disabled-password \
-    --gecos "" \
-    --home "/nonexistent" \
-    --shell "/sbin/nologin" \
-    --no-create-home \
-    --uid "${UID}" \
-    appuser
-
-# Download dependencies as a separate step to take advantage of Docker's caching.
-# Leverage a cache mount to /root/.cache/pip to speed up subsequent builds.
-# Leverage a bind mount to requirements.txt to avoid having to copy them into
-# into this layer.
-RUN --mount=type=cache,target=/root/.cache/pip \
-    --mount=type=bind,source=requirements.txt,target=requirements.txt \
-    python -m pip install -r requirements.txt
-
-# Switch to the non-privileged user to run the application.
-USER appuser
-
-# Copy the source code into the container.
-COPY . .
-
-# Expose the port that the application listens on.
-EXPOSE 8000
-
-# Run the application.
-CMD python3 -m uvicorn app:app --host=0.0.0.0 --port=8000
-```
-
-Create a file named `compose.yaml` with the following contents.
-
-```yaml {collapse=true,title=compose.yaml}
-# Comments are provided throughout this file to help you get started.
-# If you need more help, visit the Docker Compose reference guide at
-# https://docs.docker.com/go/compose-spec-reference/
-
-# Here the instructions define your application as a service called "server".
-# This service is built from the Dockerfile in the current directory.
-# You can add other services your application may depend on here, such as a
-# database or a cache. For examples, see the Awesome Compose repository:
-# https://github.com/docker/awesome-compose
-services:
-  server:
-    build:
-      context: .
-    ports:
-      - 8000:8000
-```
-
-Create a file named `.dockerignore` with the following contents.
-
-```text {collapse=true,title=".dockerignore"}
-# Include any files or directories that you don't want to be copied to your
-# container here (e.g., local build artifacts, temporary files, etc.).
-#
-# For more help, visit the .dockerignore file reference guide at
-# https://docs.docker.com/go/build-context-dockerignore/
-
-**/.DS_Store
-**/__pycache__
-**/.venv
-**/.classpath
-**/.dockerignore
-**/.env
-**/.git
-**/.gitignore
-**/.project
-**/.settings
-**/.toolstarget
-**/.vs
-**/.vscode
-**/*.*proj.user
-**/*.dbmdl
-**/*.jfm
-**/bin
-**/charts
-**/docker-compose*
-**/compose.y*ml
-**/Dockerfile*
-**/node_modules
-**/npm-debug.log
-**/obj
-**/secrets.dev.yaml
-**/values.dev.yaml
-LICENSE
-README.md
-```
-
-Create a file named `.gitignore` with the following contents.
-
-```text {collapse=true,title=".gitignore"}
-# Byte-compiled / optimized / DLL files
-__pycache__/
-*.py[cod]
-*$py.class
-
-# C extensions
-*.so
-
-# Distribution / packaging
-.Python
-build/
-develop-eggs/
-dist/
-downloads/
-eggs/
-.eggs/
-lib/
-lib64/
-parts/
-sdist/
-var/
-wheels/
-share/python-wheels/
-*.egg-info/
-.installed.cfg
-*.egg
-MANIFEST
-
-# Unit test / coverage reports
-htmlcov/
-.tox/
-.nox/
-.coverage
-.coverage.*
-.cache
-nosetests.xml
-coverage.xml
-*.cover
-*.py,cover
-.hypothesis/
-.pytest_cache/
-cover/
-
-# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
-__pypackages__/
-
-# Environments
-.env
-.venv
-env/
-venv/
-ENV/
-env.bak/
-venv.bak/
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-You should now have the following contents in your `python-docker-example`
-directory.
-
-```text
-├── python-docker-example/
-│ ├── app.py
-│ ├── requirements.txt
-│ ├── .dockerignore
-│ ├── .gitignore
-│ ├── compose.yaml
-│ ├── Dockerfile
-│ └── README.md
-```
-
-To learn more about the files, see the following:
-
-- [Dockerfile](/reference/dockerfile.md)
-- [.dockerignore](/reference/dockerfile.md#dockerignore-file)
-- [.gitignore](https://git-scm.com/docs/gitignore)
-- [compose.yaml](/reference/compose-file/_index.md)
-
-## Run the application
-
-Inside the `python-docker-example` directory, run the following command in a
-terminal.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:8000](http://localhost:8000). You should see a simple FastAPI application.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-### Run the application in the background
-
-You can run the application detached from the terminal by adding the `-d`
-option. Inside the `python-docker-example` directory, run the following command
-in a terminal.
-
-```console
-$ docker compose up --build -d
-```
-
-Open a browser and view the application at [http://localhost:8000](http://localhost:8000).
-
-To see the OpenAPI docs you can go to [http://localhost:8000/docs](http://localhost:8000/docs).
-
-You should see a simple FastAPI application.
-
-In the terminal, run the following command to stop the application.
-
-```console
-$ docker compose down
-```
-
-For more information about Compose commands, see the [Compose CLI
-reference](/reference/cli/docker/compose/_index.md).
-
-## Summary
-
-In this section, you learned how you can containerize and run your Python
-application using Docker.
-
-Related information:
-
-- [Docker Compose overview](/manuals/compose/_index.md)
-
-## Next steps
-
-In the next section, you'll learn how you can develop your application using
-containers.
diff --git a/content/guides/python/deploy.md b/content/guides/python/deploy.md
deleted file mode 100644
index 81f04dba2e39..000000000000
--- a/content/guides/python/deploy.md
+++ /dev/null
@@ -1,260 +0,0 @@
----
-title: Test your Python deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, kubernetes, python
-description: Learn how to develop locally using Kubernetes
-aliases:
-  - /language/python/deploy/
-  - /guides/language/python/deploy/
----
-
-## Prerequisites
-
-- Complete all the previous sections of this guide, starting with [Use containers for Python development](develop.md).
-- [Turn on Kubernetes](/manuals/desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This allows you to test and debug your workloads on Kubernetes locally before deploying.
-
-## Create a Kubernetes YAML file
-
-In your `python-docker-dev-example` directory, create a file named `docker-postgres-kubernetes.yaml`. Open the file in an IDE or text editor and add
-the following contents.
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: postgres
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: postgres
-  template:
-    metadata:
-      labels:
-        app: postgres
-    spec:
-      containers:
-        - name: postgres
-          image: postgres
-          ports:
-            - containerPort: 5432
-          env:
-            - name: POSTGRES_DB
-              value: example
-            - name: POSTGRES_USER
-              value: postgres
-            - name: POSTGRES_PASSWORD
-              valueFrom:
-                secretKeyRef:
-                  name: postgres-secret
-                  key: POSTGRES_PASSWORD
-          volumeMounts:
-            - name: postgres-data
-              mountPath: /var/lib/postgresql/data
-      volumes:
-        - name: postgres-data
-          persistentVolumeClaim:
-            claimName: postgres-pvc
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: postgres
-  namespace: default
-spec:
-  ports:
-    - port: 5432
-  selector:
-    app: postgres
----
-apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: postgres-pvc
-  namespace: default
-spec:
-  accessModes:
-    - ReadWriteOnce
-  resources:
-    requests:
-      storage: 1Gi
----
-apiVersion: v1
-kind: Secret
-metadata:
-  name: postgres-secret
-  namespace: default
-type: Opaque
-data:
-  POSTGRES_PASSWORD: cG9zdGdyZXNfcGFzc3dvcmQ= # Base64 encoded password (e.g., 'postgres_password')
-```
-
-In your `python-docker-dev-example` directory, create a file named
-`docker-python-kubernetes.yaml`. Replace `DOCKER_USERNAME/REPO_NAME` with your
-Docker username and the repository name that you created in [Configure CI/CD for
-your Python application](./configure-ci-cd.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: docker-python-demo
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      service: fastapi
-  template:
-    metadata:
-      labels:
-        service: fastapi
-    spec:
-      containers:
-        - name: fastapi-service
-          image: DOCKER_USERNAME/REPO_NAME
-          imagePullPolicy: Always
-          env:
-            - name: POSTGRES_PASSWORD
-              valueFrom:
-                secretKeyRef:
-                  name: postgres-secret
-                  key: POSTGRES_PASSWORD
-            - name: POSTGRES_USER
-              value: postgres
-            - name: POSTGRES_DB
-              value: example
-            - name: POSTGRES_SERVER
-              value: postgres
-            - name: POSTGRES_PORT
-              value: "5432"
-          ports:
-            - containerPort: 8001
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: service-entrypoint
-  namespace: default
-spec:
-  type: NodePort
-  selector:
-    service: fastapi
-  ports:
-    - port: 8001
-      targetPort: 8001
-      nodePort: 30001
-```
-
-In these Kubernetes YAML file, there are various objects, separated by the `---`:
-
-- A Deployment, describing a scalable group of identical pods. In this case,
-  you'll get just one replica, or copy of your pod. That pod, which is
-  described under `template`, has just one container in it. The
-  container is created from the image built by GitHub Actions in [Configure CI/CD for
-  your Python application](configure-ci-cd.md).
-- A Service, which will define how the ports are mapped in the containers.
-- A PersistentVolumeClaim, to define a storage that will be persistent through restarts for the database.
-- A Secret, Keeping the database password as an example using secret kubernetes resource.
-- A NodePort service, which will route traffic from port 30001 on your host to
-  port 8001 inside the pods it routes to, allowing you to reach your app
-  from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-> [!NOTE]
->
-> - The `NodePort` service is good for development/testing purposes. For production you should implement an [ingress-controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to `python-docker-dev-example` and deploy your database to
-   Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-postgres-kubernetes.yaml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```console
-   deployment.apps/postgres created
-   service/postgres created
-   persistentvolumeclaim/postgres-pvc created
-   secret/postgres-secret created
-   ```
-
-   Now, deploy your python application.
-
-   ```console
-   kubectl apply -f docker-python-kubernetes.yaml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```console
-   deployment.apps/docker-python-demo created
-   service/service-entrypoint created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```console
-   NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
-   docker-python-demo   1/1     1            1           48s
-   postgres             1/1     1            1           2m39s
-   ```
-
-   This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```console
-   NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
-   kubernetes           ClusterIP   10.43.0.1      <none>        443/TCP          13h
-   postgres             ClusterIP   10.43.209.25   <none>        5432/TCP         3m10s
-   service-entrypoint   NodePort    10.43.67.120   <none>        8001:30001/TCP   79s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP and the internal `ClusterIP` `postgres` with the port `5432` open to accept connections from you python app.
-
-3. In a terminal, curl the service. Note that a database was not deployed in
-   this example.
-
-   ```console
-   $ curl http://localhost:30001/
-   Hello, Docker!!!
-   ```
-
-4. Run the following commands to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-python-kubernetes.yaml
-   $ kubectl delete -f docker-postgres-kubernetes.yaml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine.
-
-Related information:
-
-- [Kubernetes documentation](https://kubernetes.io/docs/home/)
-- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-- [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/python/develop.md b/content/guides/python/develop.md
deleted file mode 100644
index da9bd980e0f7..000000000000
--- a/content/guides/python/develop.md
+++ /dev/null
@@ -1,572 +0,0 @@
----
-title: Use containers for Python development
-linkTitle: Develop your app
-weight: 20
-keywords: python, local, development
-description: Learn how to develop your Python application locally.
-aliases:
-  - /language/python/develop/
-  - /guides/language/python/develop/
----
-
-## Prerequisites
-
-Complete [Containerize a Python application](containerize.md).
-
-## Overview
-
-In this section, you'll learn how to set up a development environment for your containerized application. This includes:
-
-- Adding a local database and persisting data
-- Configuring Compose to automatically update your running Compose services as you edit and save your code
-
-## Get the sample application
-
-You'll need to clone a new repository to get a sample application that includes logic to connect to the database.
-
-1. Change to a directory where you want to clone the repository and run the following command.
-
-   ```console
-   $ git clone https://github.com/estebanx64/python-docker-dev-example
-   ```
-
-2. In the cloned repository's directory, manually create the Docker assets or run `docker init` to create the necessary Docker assets.
-
-   {{< tabs >}}
-   {{< tab name="Use Docker Init" >}}
-
-   In the cloned repository's directory, run `docker init`. Refer to the
-   following example to answer the prompts from `docker init`.
-
-   ```console
-   $ docker init
-   Welcome to the Docker Init CLI!
-
-   This utility will walk you through creating the following files with sensible defaults for your project:
-     - .dockerignore
-     - Dockerfile
-     - compose.yaml
-     - README.Docker.md
-
-   Let's get started!
-
-   ? What application platform does your project use? Python
-   ? What version of Python do you want to use? 3.11.4
-   ? What port do you want your app to listen on? 8001
-   ? What is the command to run your app? python3 -m uvicorn app:app --host=0.0.0.0 --port=8001
-   ```
-
-   Create a file named `.gitignore` with the following contents.
-
-   ```text {collapse=true,title=".gitignore"}
-   # Byte-compiled / optimized / DLL files
-   __pycache__/
-   *.py[cod]
-   *$py.class
-
-   # C extensions
-   *.so
-
-   # Distribution / packaging
-   .Python
-   build/
-   develop-eggs/
-   dist/
-   downloads/
-   eggs/
-   .eggs/
-   lib/
-   lib64/
-   parts/
-   sdist/
-   var/
-   wheels/
-   share/python-wheels/
-   *.egg-info/
-   .installed.cfg
-   *.egg
-   MANIFEST
-
-   # Unit test / coverage reports
-   htmlcov/
-   .tox/
-   .nox/
-   .coverage
-   .coverage.*
-   .cache
-   nosetests.xml
-   coverage.xml
-   *.cover
-   *.py,cover
-   .hypothesis/
-   .pytest_cache/
-   cover/
-
-   # PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
-   __pypackages__/
-
-   # Environments
-   .env
-   .venv
-   env/
-   venv/
-   ENV/
-   env.bak/
-   venv.bak/
-   ```
-
-   {{< /tab >}}
-   {{< tab name="Manually create assets" >}}
-
-   If you don't have Docker Desktop installed or prefer creating the assets
-   manually, you can create the following files in your project directory.
-
-   Create a file named `Dockerfile` with the following contents.
-
-   ```dockerfile {collapse=true,title=Dockerfile}
-   # syntax=docker/dockerfile:1
-
-   # Comments are provided throughout this file to help you get started.
-   # If you need more help, visit the Dockerfile reference guide at
-   # https://docs.docker.com/go/dockerfile-reference/
-
-   # Want to help us make this template better? Share your feedback here: https://   forms.gle/ybq9Krt8jtBL3iCk7
-
-   ARG PYTHON_VERSION=3.11.4
-   FROM python:${PYTHON_VERSION}-slim as base
-
-   # Prevents Python from writing pyc files.
-   ENV PYTHONDONTWRITEBYTECODE=1
-
-   # Keeps Python from buffering stdout and stderr to avoid situations where
-   # the application crashes without emitting any logs due to buffering.
-   ENV PYTHONUNBUFFERED=1
-
-   WORKDIR /app
-
-   # Create a non-privileged user that the app will run under.
-   # See https://docs.docker.com/go/dockerfile-user-best-practices/
-   ARG UID=10001
-   RUN adduser \
-       --disabled-password \
-       --gecos "" \
-       --home "/nonexistent" \
-       --shell "/sbin/nologin" \
-       --no-create-home \
-       --uid "${UID}" \
-       appuser
-
-   # Download dependencies as a separate step to take advantage of Docker's    caching.
-   # Leverage a cache mount to /root/.cache/pip to speed up subsequent builds.
-   # Leverage a bind mount to requirements.txt to avoid having to copy them into
-   # into this layer.
-   RUN --mount=type=cache,target=/root/.cache/pip \
-       --mount=type=bind,source=requirements.txt,target=requirements.txt \
-       python -m pip install -r requirements.txt
-
-   # Switch to the non-privileged user to run the application.
-   USER appuser
-
-   # Copy the source code into the container.
-   COPY . .
-
-   # Expose the port that the application listens on.
-   EXPOSE 8001
-
-   # Run the application.
-   CMD python3 -m uvicorn app:app --host=0.0.0.0 --port=8001
-   ```
-
-   Create a file named `compose.yaml` with the following contents.
-
-   ```yaml {collapse=true,title=compose.yaml}
-   # Comments are provided throughout this file to help you get started.
-   # If you need more help, visit the Docker Compose reference guide at
-   # https://docs.docker.com/go/compose-spec-reference/
-
-   # Here the instructions define your application as a service called "server".
-   # This service is built from the Dockerfile in the current directory.
-   # You can add other services your application may depend on here, such as a
-   # database or a cache. For examples, see the Awesome Compose repository:
-   # https://github.com/docker/awesome-compose
-   services:
-     server:
-       build:
-         context: .
-       ports:
-         - 8001:8001
-   # The commented out section below is an example of how to define a PostgreSQL
-   # database that your application can use. `depends_on` tells Docker Compose to
-   # start the database before your application. The `db-data` volume persists the
-   # database data between container restarts. The `db-password` secret is used
-   # to set the database password. You must create `db/password.txt` and add
-   # a password of your choosing to it before running `docker compose up`.
-   #     depends_on:
-   #       db:
-   #         condition: service_healthy
-   #   db:
-   #     image: postgres
-   #     restart: always
-   #     user: postgres
-   #     secrets:
-   #       - db-password
-   #     volumes:
-   #       - db-data:/var/lib/postgresql/data
-   #     environment:
-   #       - POSTGRES_DB=example
-   #       - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-   #     expose:
-   #       - 5432
-   #     healthcheck:
-   #       test: [ "CMD", "pg_isready" ]
-   #       interval: 10s
-   #       timeout: 5s
-   #       retries: 5
-   # volumes:
-   #   db-data:
-   # secrets:
-   #   db-password:
-   #     file: db/password.txt
-   ```
-
-   Create a file named `.dockerignore` with the following contents.
-
-   ```text {collapse=true,title=".dockerignore"}
-   # Include any files or directories that you don't want to be copied to your
-   # container here (e.g., local build artifacts, temporary files, etc.).
-   #
-   # For more help, visit the .dockerignore file reference guide at
-   # https://docs.docker.com/go/build-context-dockerignore/
-
-   **/.DS_Store
-   **/__pycache__
-   **/.venv
-   **/.classpath
-   **/.dockerignore
-   **/.env
-   **/.git
-   **/.gitignore
-   **/.project
-   **/.settings
-   **/.toolstarget
-   **/.vs
-   **/.vscode
-   **/*.*proj.user
-   **/*.dbmdl
-   **/*.jfm
-   **/bin
-   **/charts
-   **/docker-compose*
-   **/compose.y*ml
-   **/Dockerfile*
-   **/node_modules
-   **/npm-debug.log
-   **/obj
-   **/secrets.dev.yaml
-   **/values.dev.yaml
-   LICENSE
-   README.md
-   ```
-
-   Create a file named `.gitignore` with the following contents.
-
-   ```text {collapse=true,title=".gitignore"}
-   # Byte-compiled / optimized / DLL files
-   __pycache__/
-   *.py[cod]
-   *$py.class
-
-   # C extensions
-   *.so
-
-   # Distribution / packaging
-   .Python
-   build/
-   develop-eggs/
-   dist/
-   downloads/
-   eggs/
-   .eggs/
-   lib/
-   lib64/
-   parts/
-   sdist/
-   var/
-   wheels/
-   share/python-wheels/
-   *.egg-info/
-   .installed.cfg
-   *.egg
-   MANIFEST
-
-   # Unit test / coverage reports
-   htmlcov/
-   .tox/
-   .nox/
-   .coverage
-   .coverage.*
-   .cache
-   nosetests.xml
-   coverage.xml
-   *.cover
-   *.py,cover
-   .hypothesis/
-   .pytest_cache/
-   cover/
-
-   # PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
-   __pypackages__/
-
-   # Environments
-   .env
-   .venv
-   env/
-   venv/
-   ENV/
-   env.bak/
-   venv.bak/
-   ```
-
-   {{< /tab >}}
-   {{< /tabs >}}
-
-## Add a local database and persist data
-
-You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service and a volume to persist data.
-
-In the cloned repository's directory, open the `compose.yaml` file in an IDE or text editor. `docker init` handled creating most of the instructions, but you'll need to update it for your unique application.
-
-In the `compose.yaml` file, you need to uncomment all of the database instructions. In addition, you need to add the database password file as an environment variable to the server service and specify the secret file to use .
-
-The following is the updated `compose.yaml` file.
-
-```yaml {hl_lines="7-43"}
-services:
-  server:
-    build:
-      context: .
-    ports:
-      - 8001:8001
-    environment:
-      - POSTGRES_SERVER=db
-      - POSTGRES_USER=postgres
-      - POSTGRES_DB=example
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    depends_on:
-      db:
-        condition: service_healthy
-    secrets:
-      - db-password
-  db:
-    image: postgres
-    restart: always
-    user: postgres
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=example
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    expose:
-      - 5432
-    healthcheck:
-      test: ["CMD", "pg_isready"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-> [!NOTE]
->
-> To learn more about the instructions in the Compose file, see [Compose file
-> reference](/reference/compose-file/).
-
-Before you run the application using Compose, notice that this Compose file specifies a `password.txt` file to hold the database's password. You must create this file as it's not included in the source repository.
-
-In the cloned repository's directory, create a new directory named `db` and inside that directory create a file named `password.txt` that contains the password for the database. Using your favorite IDE or text editor, add the following contents to the `password.txt` file.
-
-```text
-mysecretpassword
-```
-
-Save and close the `password.txt` file.
-
-You should now have the following contents in your `python-docker-dev-example`
-directory.
-
-```text
-├── python-docker-dev-example/
-│ ├── db/
-│ │ └── password.txt
-│ ├── app.py
-│ ├── config.py
-│ ├── requirements.txt
-│ ├── .dockerignore
-│ ├── .gitignore
-│ ├── compose.yaml
-│ ├── Dockerfile
-│ ├── README.Docker.md
-│ └── README.md
-```
-
-Now, run the following `docker compose up` command to start your application.
-
-```console
-$ docker compose up --build
-```
-
-Now test your API endpoint. Open a new terminal then make a request to the server using the curl commands:
-
-Let's create an object with a post method
-
-```console
-$ curl -X 'POST' \
-  'http://localhost:8001/heroes/' \
-  -H 'accept: application/json' \
-  -H 'Content-Type: application/json' \
-  -d '{
-  "id": 1,
-  "name": "my hero",
-  "secret_name": "austing",
-  "age": 12
-}'
-```
-
-You should receive the following response:
-
-```json
-{
-  "age": 12,
-  "id": 1,
-  "name": "my hero",
-  "secret_name": "austing"
-}
-```
-
-Let's make a get request with the next curl command:
-
-```console
-curl -X 'GET' \
-  'http://localhost:8001/heroes/' \
-  -H 'accept: application/json'
-```
-
-You should receive the same response as above because it's the only one object we have in database.
-
-```json
-{
-  "age": 12,
-  "id": 1,
-  "name": "my hero",
-  "secret_name": "austing"
-}
-```
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Automatically update services
-
-Use Compose Watch to automatically update your running Compose services as you
-edit and save your code. For more details about Compose Watch, see [Use Compose
-Watch](/manuals/compose/how-tos/file-watch.md).
-
-Open your `compose.yaml` file in an IDE or text editor and then add the Compose
-Watch instructions. The following is the updated `compose.yaml` file.
-
-```yaml {hl_lines="17-20"}
-services:
-  server:
-    build:
-      context: .
-    ports:
-      - 8001:8001
-    environment:
-      - POSTGRES_SERVER=db
-      - POSTGRES_USER=postgres
-      - POSTGRES_DB=example
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    depends_on:
-      db:
-        condition: service_healthy
-    secrets:
-      - db-password
-    develop:
-      watch:
-        - action: rebuild
-          path: .
-  db:
-    image: postgres
-    restart: always
-    user: postgres
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=example
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    expose:
-      - 5432
-    healthcheck:
-      test: ["CMD", "pg_isready"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-Run the following command to run your application with Compose Watch.
-
-```console
-$ docker compose watch
-```
-
-In a terminal, curl the application to get a response.
-
-```console
-$ curl http://localhost:8001
-Hello, Docker!
-```
-
-Any changes to the application's source files on your local machine will now be immediately reflected in the running container.
-
-Open `python-docker-dev-example/app.py` in an IDE or text editor and update the `Hello, Docker!` string by adding a few more exclamation marks.
-
-```diff
--    return 'Hello, Docker!'
-+    return 'Hello, Docker!!!'
-```
-
-Save the changes to `app.py` and then wait a few seconds for the application to rebuild. Curl the application again and verify that the updated text appears.
-
-```console
-$ curl http://localhost:8001
-Hello, Docker!!!
-```
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Summary
-
-In this section, you took a look at setting up your Compose file to add a local
-database and persist data. You also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
-
-Related information:
-
-- [Compose file reference](/reference/compose-file/)
-- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
-- [Multi-stage builds](/manuals/build/building/multi-stage.md)
-
-## Next steps
-
-In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions.
diff --git a/content/guides/r.md b/content/guides/r.md
new file mode 100644
index 000000000000..84fce50850f8
--- /dev/null
+++ b/content/guides/r.md
@@ -0,0 +1,316 @@
+---
+title: R language-specific guide
+linkTitle: R
+description: Containerize R apps using Docker
+keywords: Docker, getting started, R, language
+summary: |
+  This guide details how to containerize R applications using Docker.
+aliases:
+  - /languages/r/
+  - /guides/languages/r/
+  - /language/R/build-images/
+  - /language/R/run-containers/
+  - /language/r/containerize/
+  - /language/r/develop/
+  - /language/r/configure-ci-cd/
+  - /language/r/deploy/
+  - /guides/r/configure-ci-cd/
+  - /guides/r/containerize/
+  - /guides/r/deploy/
+  - /guides/r/develop/
+params:
+  tags: [languages]
+  time: 10 minutes
+---
+
+The R language-specific guide teaches you how to containerize a R application using Docker. In this guide, you’ll learn how to:
+
+- Containerize and run a R application
+- Set up a local environment to develop a R application using containers
+
+Start by containerizing an existing R application.
+
+## Containerize a R application
+
+### Prerequisites
+
+- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
+
+### Overview
+
+This section walks you through containerizing and running a R application.
+
+### Get the sample application
+
+The sample application uses the popular [Shiny](https://shiny.posit.co/) framework.
+
+Clone the sample application to use with this guide. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
+
+```console
+$ git clone https://github.com/mfranzon/r-docker-dev.git && cd r-docker-dev
+```
+
+You should now have the following contents in your `r-docker-dev`
+directory.
+
+```text
+├── r-docker-dev/
+│ ├── src/
+│ │ └── app.R
+│ ├── src_db/
+│ │ └── app_db.R
+│ ├── compose.yaml
+│ ├── Dockerfile
+│ └── README.md
+```
+
+To learn more about the files in the repository, see the following:
+
+- [Dockerfile](/reference/dockerfile.md)
+- [.dockerignore](/reference/dockerfile.md#dockerignore-file)
+- [compose.yaml](/reference/compose-file/_index.md)
+
+### Run the application
+
+Inside the `r-docker-dev` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:3838](http://localhost:3838). You should see a simple Shiny application.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `r-docker-dev` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:3838](http://localhost:3838).
+
+You should see a simple Shiny application.
+
+In the terminal, run the following command to stop the application.
+
+```console
+$ docker compose down
+```
+
+For more information about Compose commands, see the [Compose CLI
+reference](/reference/cli/docker/compose/).
+
+## Use containers for R development
+
+### Prerequisites
+
+Complete [Containerize a R application](#containerize-a-r-application).
+
+### Overview
+
+In this section, you'll learn how to set up a development environment for your containerized application. This includes:
+
+- Adding a local database and persisting data
+- Configuring Compose to automatically update your running Compose services as you edit and save your code
+
+### Get the sample application
+
+You'll need to clone a new repository to get a sample application that includes logic to connect to the database.
+
+Change to a directory where you want to clone the repository and run the following command.
+
+```console
+$ git clone https://github.com/mfranzon/r-docker-dev.git
+```
+
+### Configure the application to use the database
+
+To try the connection between the Shiny application and the local database you have to modify the `Dockerfile` changing the `COPY` instruction:
+
+```diff
+-COPY src/ .
++COPY src_db/ .
+```
+
+### Add a local database and persist data
+
+You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service and a volume to persist data.
+
+In the cloned repository's directory, open the `compose.yaml` file in an IDE or text editor.
+
+In the `compose.yaml` file, you need to un-comment the properties for configuring the database. You must also mount the database password file and set an environment variable on the `shiny-app` service pointing to the location of the file in the container.
+
+The following is the updated `compose.yaml` file.
+
+```yaml
+services:
+  shiny-app:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    ports:
+      - 3838:3838
+    environment:
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    depends_on:
+      db:
+        condition: service_healthy
+    secrets:
+      - db-password
+  db:
+    image: postgres:18
+    restart: always
+    user: postgres
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    expose:
+      - 5432
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+> [!NOTE]
+>
+> To learn more about the instructions in the Compose file, see [Compose file
+> reference](/reference/compose-file/).
+
+Before you run the application using Compose, notice that this Compose file specifies a `password.txt` file to hold the database's password. You must create this file as it's not included in the source repository.
+
+In the cloned repository's directory, create a new directory named `db` and inside that directory create a file named `password.txt` that contains the password for the database. Using your favorite IDE or text editor, add the following contents to the `password.txt` file.
+
+```text
+mysecretpassword
+```
+
+Save and close the `password.txt` file.
+
+You should now have the following contents in your `r-docker-dev`
+directory.
+
+```text
+├── r-docker-dev/
+│ ├── db/
+│ │ └── password.txt
+│ ├── src/
+│ │ └── app.R
+│ ├── src_db/
+│ │ └── app_db.R
+│ ├── requirements.txt
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ ├── Dockerfile
+│ └── README.md
+```
+
+Now, run the following `docker compose up` command to start your application.
+
+```console
+$ docker compose up --build
+```
+
+Now test your DB connection opening a browser at:
+
+```console
+http://localhost:3838
+```
+
+You should see a pop-up message:
+
+```text
+DB CONNECTED
+```
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Automatically update services
+
+Use Compose Watch to automatically update your running Compose services as you
+edit and save your code. For more details about Compose Watch, see [Use Compose
+Watch](/manuals/compose/how-tos/file-watch.md).
+
+Lines 15 to 18 in the `compose.yaml` file contain properties that trigger Docker
+to rebuild the image when a file in the current working directory is changed:
+
+```yaml {hl_lines="15-18",linenos=true}
+services:
+  shiny-app:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    ports:
+      - 3838:3838
+    environment:
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    depends_on:
+      db:
+        condition: service_healthy
+    secrets:
+      - db-password
+    develop:
+      watch:
+        - action: rebuild
+          path: .
+  db:
+    image: postgres:18
+    restart: always
+    user: postgres
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    expose:
+      - 5432
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+Run the following command to run your application with Compose Watch.
+
+```console
+$ docker compose watch
+```
+
+Now, if you modify your `app.R` you will see the changes in real time without re-building the image!
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Summary
+
+In this section, you took a look at setting up your Compose file to add a local
+database and persist data. You also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
+
+Related information:
+
+- [Compose file reference](/reference/compose-file/)
+- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
+- [Multi-stage builds](/manuals/build/building/multi-stage.md)
diff --git a/content/guides/r/_index.md b/content/guides/r/_index.md
deleted file mode 100644
index c599db41a572..000000000000
--- a/content/guides/r/_index.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: R language-specific guide
-linkTitle: R
-description: Containerize R apps using Docker
-keywords: Docker, getting started, R, language
-summary: |
-  This guide details how to containerize R applications using Docker.
-toc_min: 1
-toc_max: 2
-aliases:
-  - /languages/r/
-  - /guides/languages/r/
-languages: [r]
-params:
-  time: 10 minutes
----
-
-The R language-specific guide teaches you how to containerize a R application using Docker. In this guide, you’ll learn how to:
-
-- Containerize and run a R application
-- Set up a local environment to develop a R application using containers
-- Configure a CI/CD pipeline for a containerized R application using GitHub Actions
-- Deploy your containerized R application locally to Kubernetes to test and debug your deployment
-
-Start by containerizing an existing R application.
diff --git a/content/guides/r/configure-ci-cd.md b/content/guides/r/configure-ci-cd.md
deleted file mode 100644
index 8c1c4fcc5079..000000000000
--- a/content/guides/r/configure-ci-cd.md
+++ /dev/null
@@ -1,133 +0,0 @@
----
-title: Configure CI/CD for your R application
-linkTitle: Configure CI/CD
-weight: 40
-keywords: ci/cd, github actions, R, shiny
-description: Learn how to configure CI/CD using GitHub Actions for your R application.
-aliases:
-  - /language/r/configure-ci-cd/
-  - /guides/language/r/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a R application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-## Overview
-
-In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps:
-
-1. Create a new repository on GitHub.
-2. Define the GitHub Actions workflow.
-3. Run the workflow.
-
-## Step one: Create the repository
-
-Create a GitHub repository, configure the Docker Hub credentials, and push your source code.
-
-1. [Create a new repository](https://github.com/new) on GitHub.
-
-2. Open the repository **Settings**, and go to **Secrets and variables** >
-   **Actions**.
-
-3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-4. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-5. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-6. In your local repository on your machine, run the following command to change
-   the origin to the repository you just created. Make sure you change
-   `your-username` to your GitHub username and `your-repository` to the name of
-   the repository you created.
-
-   ```console
-   $ git remote set-url origin https://github.com/your-username/your-repository.git
-   ```
-
-7. Run the following commands to stage, commit, and push your local repository to GitHub.
-
-   ```console
-   $ git add -A
-   $ git commit -m "my commit"
-   $ git push -u origin main
-   ```
-
-## Step two: Set up the workflow
-
-Set up your GitHub Actions workflow for building, testing, and pushing the image
-to Docker Hub.
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-
-2. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub actions workflow file in
-   your repository, under `.github/workflows/main.yml` by default.
-
-3. In the editor window, copy and paste the following YAML configuration.
-
-   ```yaml
-   name: ci
-
-   on:
-     push:
-       branches:
-         - main
-
-   jobs:
-     build:
-       runs-on: ubuntu-latest
-       steps:
-         - name: Login to Docker Hub
-           uses: docker/login-action@v3
-           with:
-             username: ${{ vars.DOCKER_USERNAME }}
-             password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-         - name: Set up Docker Buildx
-           uses: docker/setup-buildx-action@v3
-
-         - name: Build and push
-           uses: docker/build-push-action@v6
-           with:
-             platforms: linux/amd64,linux/arm64
-             push: true
-             tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-   ```
-
-   For more information about the YAML syntax for `docker/build-push-action`,
-   refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
-## Step three: Run the workflow
-
-Save the workflow file and run the job.
-
-1. Select **Commit changes...** and push the changes to the `main` branch.
-
-   After pushing the commit, the workflow starts automatically.
-
-2. Go to the **Actions** tab. It displays the workflow.
-
-   Selecting the workflow shows you the breakdown of all the steps.
-
-3. When the workflow is complete, go to your
-   [repositories on Docker Hub](https://hub.docker.com/repositories).
-
-   If you see the new repository in that list, it means the GitHub Actions
-   successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your R application.
-
-Related information:
-
-- [Introduction to GitHub Actions](/guides/gha.md)
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md)
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-Next, learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/r/containerize.md b/content/guides/r/containerize.md
deleted file mode 100644
index 14b4a8dd3061..000000000000
--- a/content/guides/r/containerize.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-title: Containerize a R application
-linkTitle: Containerize your app
-weight: 10
-keywords: R, containerize, initialize
-description: Learn how to containerize a R application.
-aliases:
-  - /language/R/build-images/
-  - /language/R/run-containers/
-  - /language/r/containerize/
-  - /guides/language/r/containerize/
----
-
-## Prerequisites
-
-- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
-
-## Overview
-
-This section walks you through containerizing and running a R application.
-
-## Get the sample application
-
-The sample application uses the popular [Shiny](https://shiny.posit.co/) framework.
-
-Clone the sample application to use with this guide. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
-
-```console
-$ git clone https://github.com/mfranzon/r-docker-dev.git && cd r-docker-dev
-```
-
-You should now have the following contents in your `r-docker-dev`
-directory.
-
-```text
-├── r-docker-dev/
-│ ├── src/
-│ │ └── app.R
-│ ├── src_db/
-│ │ └── app_db.R
-│ ├── compose.yaml
-│ ├── Dockerfile
-│ └── README.md
-```
-
-To learn more about the files in the repository, see the following:
-
-- [Dockerfile](/reference/dockerfile.md)
-- [.dockerignore](/reference/dockerfile.md#dockerignore-file)
-- [compose.yaml](/reference/compose-file/_index.md)
-
-## Run the application
-
-Inside the `r-docker-dev` directory, run the following command in a
-terminal.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:3838](http://localhost:3838). You should see a simple Shiny application.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-### Run the application in the background
-
-You can run the application detached from the terminal by adding the `-d`
-option. Inside the `r-docker-dev` directory, run the following command
-in a terminal.
-
-```console
-$ docker compose up --build -d
-```
-
-Open a browser and view the application at [http://localhost:3838](http://localhost:3838).
-
-You should see a simple Shiny application.
-
-In the terminal, run the following command to stop the application.
-
-```console
-$ docker compose down
-```
-
-For more information about Compose commands, see the [Compose CLI
-reference](/reference/cli/docker/compose/_index.md).
-
-## Summary
-
-In this section, you learned how you can containerize and run your R
-application using Docker.
-
-Related information:
-
-- [Docker Compose overview](/manuals/compose/_index.md)
-
-## Next steps
-
-In the next section, you'll learn how you can develop your application using
-containers.
diff --git a/content/guides/r/deploy.md b/content/guides/r/deploy.md
deleted file mode 100644
index 6aa8c4aba515..000000000000
--- a/content/guides/r/deploy.md
+++ /dev/null
@@ -1,147 +0,0 @@
----
-title: Test your R deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, kubernetes, R
-description: Learn how to develop locally using Kubernetes
-aliases:
-  - /language/r/deploy/
-  - /guides/language/r/deploy/
----
-
-## Prerequisites
-
-- Complete all the previous sections of this guide, starting with [Containerize a R application](containerize.md).
-- [Turn on Kubernetes](/manuals/desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This allows you to test and debug your workloads on Kubernetes locally before deploying.
-
-## Create a Kubernetes YAML file
-
-In your `r-docker-dev` directory, create a file named
-`docker-r-kubernetes.yaml`. Open the file in an IDE or text editor and add
-the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker
-username and the name of the repository that you created in [Configure CI/CD for
-your R application](configure-ci-cd.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: docker-r-demo
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      service: shiny
-  template:
-    metadata:
-      labels:
-        service: shiny
-    spec:
-      containers:
-        - name: shiny-service
-          image: DOCKER_USERNAME/REPO_NAME
-          imagePullPolicy: Always
-          env:
-            - name: POSTGRES_PASSWORD
-              value: mysecretpassword
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: service-entrypoint
-  namespace: default
-spec:
-  type: NodePort
-  selector:
-    service: shiny
-  ports:
-    - port: 3838
-      targetPort: 3838
-      nodePort: 30001
-```
-
-In this Kubernetes YAML file, there are two objects, separated by the `---`:
-
-- A Deployment, describing a scalable group of identical pods. In this case,
-  you'll get just one replica, or copy of your pod. That pod, which is
-  described under `template`, has just one container in it. The
-  container is created from the image built by GitHub Actions in [Configure CI/CD for
-  your R application](configure-ci-cd.md).
-- A NodePort service, which will route traffic from port 30001 on your host to
-  port 3838 inside the pods it routes to, allowing you to reach your app
-  from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to `r-docker-dev` and deploy your application to
-   Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-r-kubernetes.yaml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```text
-   deployment.apps/docker-r-demo created
-   service/service-entrypoint created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```shell
-   NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
-   docker-r-demo   1/1     1            1           15s
-   ```
-
-   This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```shell
-   NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
-   kubernetes           ClusterIP   10.96.0.1       <none>        443/TCP          23h
-   service-entrypoint   NodePort    10.99.128.230   <none>        3838:30001/TCP   75s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP.
-
-3. In a browser, visit the following address. Note that a database was not deployed in
-   this example.
-
-   ```console
-   http://localhost:30001/
-   ```
-
-4. Run the following command to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-r-kubernetes.yaml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine.
-
-Related information:
-
-- [Kubernetes documentation](https://kubernetes.io/docs/home/)
-- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-- [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/r/develop.md b/content/guides/r/develop.md
deleted file mode 100644
index 523fc6e492ec..000000000000
--- a/content/guides/r/develop.md
+++ /dev/null
@@ -1,222 +0,0 @@
----
-title: Use containers for R development
-linkTitle: Develop your app
-weight: 20
-keywords: R, local, development
-description: Learn how to develop your R application locally.
-aliases:
-  - /language/r/develop/
-  - /guides/language/r/develop/
----
-
-## Prerequisites
-
-Complete [Containerize a R application](containerize.md).
-
-## Overview
-
-In this section, you'll learn how to set up a development environment for your containerized application. This includes:
-
-- Adding a local database and persisting data
-- Configuring Compose to automatically update your running Compose services as you edit and save your code
-
-## Get the sample application
-
-You'll need to clone a new repository to get a sample application that includes logic to connect to the database.
-
-Change to a directory where you want to clone the repository and run the following command.
-
-```console
-$ git clone https://github.com/mfranzon/r-docker-dev.git
-```
-
-## Configure the application to use the database
-
-To try the connection between the Shiny application and the local database you have to modify the `Dockerfile` changing the `COPY` instruction:
-
-```diff
--COPY src/ .
-+COPY src_db/ .
-```
-
-## Add a local database and persist data
-
-You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service and a volume to persist data.
-
-In the cloned repository's directory, open the `compose.yaml` file in an IDE or text editor.
-
-In the `compose.yaml` file, you need to un-comment the properties for configuring the database. You must also mount the database password file and set an environment variable on the `shiny-app` service pointing to the location of the file in the container.
-
-The following is the updated `compose.yaml` file.
-
-```yaml
-services:
-  shiny-app:
-    build:
-      context: .
-      dockerfile: Dockerfile
-    ports:
-      - 3838:3838
-    environment:
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    depends_on:
-      db:
-        condition: service_healthy
-    secrets:
-      - db-password
-  db:
-    image: postgres
-    restart: always
-    user: postgres
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=example
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    expose:
-      - 5432
-    healthcheck:
-      test: ["CMD", "pg_isready"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-> [!NOTE]
->
-> To learn more about the instructions in the Compose file, see [Compose file
-> reference](/reference/compose-file/).
-
-Before you run the application using Compose, notice that this Compose file specifies a `password.txt` file to hold the database's password. You must create this file as it's not included in the source repository.
-
-In the cloned repository's directory, create a new directory named `db` and inside that directory create a file named `password.txt` that contains the password for the database. Using your favorite IDE or text editor, add the following contents to the `password.txt` file.
-
-```text
-mysecretpassword
-```
-
-Save and close the `password.txt` file.
-
-You should now have the following contents in your `r-docker-dev`
-directory.
-
-```text
-├── r-docker-dev/
-│ ├── db/
-│ │ └── password.txt
-│ ├── src/
-│ │ └── app.R
-│ ├── src_db/
-│ │ └── app_db.R
-│ ├── requirements.txt
-│ ├── .dockerignore
-│ ├── compose.yaml
-│ ├── Dockerfile
-│ ├── README.Docker.md
-│ └── README.md
-```
-
-Now, run the following `docker compose up` command to start your application.
-
-```console
-$ docker compose up --build
-```
-
-Now test your DB connection opening a browser at:
-
-```console
-http://localhost:3838
-```
-
-You should see a pop-up message:
-
-```text
-DB CONNECTED
-```
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Automatically update services
-
-Use Compose Watch to automatically update your running Compose services as you
-edit and save your code. For more details about Compose Watch, see [Use Compose
-Watch](/manuals/compose/how-tos/file-watch.md).
-
-Lines 15 to 18 in the `compose.yaml` file contain properties that trigger Docker
-to rebuild the image when a file in the current working directory is changed:
-
-```yaml {hl_lines="15-18",linenos=true}
-services:
-  shiny-app:
-    build:
-      context: .
-      dockerfile: Dockerfile
-    ports:
-      - 3838:3838
-    environment:
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    depends_on:
-      db:
-        condition: service_healthy
-    secrets:
-      - db-password
-    develop:
-      watch:
-        - action: rebuild
-          path: .
-  db:
-    image: postgres
-    restart: always
-    user: postgres
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=example
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    expose:
-      - 5432
-    healthcheck:
-      test: ["CMD", "pg_isready"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-Run the following command to run your application with Compose Watch.
-
-```console
-$ docker compose watch
-```
-
-Now, if you modify your `app.R` you will see the changes in real time without re-building the image!
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Summary
-
-In this section, you took a look at setting up your Compose file to add a local
-database and persist data. You also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
-
-Related information:
-
-- [Compose file reference](/reference/compose-file/)
-- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
-- [Multi-stage builds](/manuals/build/building/multi-stage.md)
-
-## Next steps
-
-In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions.
diff --git a/content/guides/rag-ollama.md b/content/guides/rag-ollama.md
new file mode 100644
index 000000000000..17650e4871df
--- /dev/null
+++ b/content/guides/rag-ollama.md
@@ -0,0 +1,282 @@
+---
+description: Containerize RAG application using Ollama and Docker
+keywords: python, generative ai, genai, llm, ollama, rag, qdrant
+title: Build a RAG application using Ollama and Docker
+linkTitle: RAG Ollama application
+summary: |
+  This guide demonstrates how to use Docker to deploy Retrieval-Augmented
+  Generation (RAG) models with Ollama.
+aliases:
+  - /guides/use-case/rag-ollama/
+  - /guides/rag-ollama/containerize/
+  - /guides/rag-ollama/develop/
+params:
+  tags: [ai]
+  time: 20 minutes
+---
+
+
+The Retrieval Augmented Generation (RAG) guide teaches you how to containerize an existing RAG application using Docker. The example application is a RAG that acts like a sommelier, giving you the best pairings between wines and food. In this guide, you’ll learn how to:
+
+- Containerize and run a RAG application
+- Set up a local environment to run the complete RAG stack locally for development
+
+Start by containerizing an existing RAG application.
+
+## Containerize a RAG application
+
+### Overview
+
+This section walks you through containerizing a RAG application using Docker.
+
+> [!NOTE]
+> You can see more samples of containerized GenAI applications in the [GenAI Stack](https://github.com/docker/genai-stack) demo applications.
+
+### Get the sample application
+
+The sample application used in this guide is an example of RAG application, made by three main components, which are the building blocks for every RAG application. A Large Language Model hosted somewhere, in this case it is hosted in a container and served via [Ollama](https://ollama.ai/). A vector database, [Qdrant](https://qdrant.tech/), to store the embeddings of local data, and a web application, using [Streamlit](https://streamlit.io/) to offer the best user experience to the user.
+
+Clone the sample application. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
+
+```console
+$ git clone https://github.com/mfranzon/winy.git
+```
+
+You should now have the following files in your `winy` directory.
+
+```text
+├── winy/
+│ ├── .gitignore
+│ ├── app/
+│ │ ├── main.py
+│ │ ├── Dockerfile
+| | └── requirements.txt
+│ ├── tools/
+│ │ ├── create_db.py
+│ │ ├── create_embeddings.py
+│ │ ├── requirements.txt
+│ │ ├── test.py
+| | └── download_model.sh
+│ ├── docker-compose.yaml
+│ ├── wine_database.db
+│ ├── LICENSE
+│ └── README.md
+```
+
+### Containerizing your application: Essentials
+
+Containerizing an application involves packaging it along with its dependencies into a container, which ensures consistency across different environments. Here’s what you need to containerize an app like Winy :
+
+1. Dockerfile: A Dockerfile that contains instructions on how to build a Docker image for your application. It specifies the base image, dependencies, configuration files, and the command to run your application.
+
+2. Docker Compose File: Docker Compose is a tool for defining and running multi-container Docker applications. A Compose file allows you to configure your application's services, networks, and volumes in a single file.
+
+### Run the application
+
+Inside the `winy` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+Docker builds and runs your application. Depending on your network connection, it may take several minutes to download all the dependencies. You'll see a message like the following in the terminal when the application is running.
+
+```console
+server-1  |   You can now view your Streamlit app in your browser.
+server-1  |
+server-1  |   URL: http://0.0.0.0:8501
+server-1  |
+```
+
+Open a browser and view the application at [http://localhost:8501](http://localhost:8501). You should see a simple Streamlit application.
+
+The application requires a Qdrant database service and an LLM service to work properly. If you have access to services that you ran outside of Docker, specify the connection information in the `docker-compose.yaml`.
+
+```yaml
+winy:
+  build:
+    context: ./app
+    dockerfile: Dockerfile
+  environment:
+    - QDRANT_CLIENT=http://qdrant:6333 # Specifies the url for the qdrant database
+    - OLLAMA=http://ollama:11434 # Specifies the url for the ollama service
+  container_name: winy
+  ports:
+    - "8501:8501"
+  depends_on:
+    - qdrant
+    - ollama
+```
+
+If you don't have the services running, continue with this guide to learn how you can run some or all of these services with Docker.
+Remember that the `ollama` service is empty; it doesn't have any model. For this reason you need to pull a model before starting to use the RAG application. All the instructions are in the following page.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+### Summary
+
+In this section, you learned how you can containerize and run your RAG
+application using Docker.
+
+### Next steps
+
+In the next section, you'll learn how to properly configure the application with your preferred LLM model, completely locally, using Docker.
+
+## Use containers for RAG development
+
+### Prerequisites
+
+Complete [Containerize a RAG application](#containerize-a-rag-application).
+
+### Overview
+
+In this section, you'll learn how to set up a development environment to access all the services that your generative RAG application needs. This includes:
+
+- Adding a local database
+- Adding a local or remote LLM service
+
+> [!NOTE]
+> You can see more samples of containerized GenAI applications in the [GenAI Stack](https://github.com/docker/genai-stack) demo applications.
+
+### Add a local database
+
+You can use containers to set up local services, like a database. In this section, you'll explore the database service in the `docker-compose.yaml` file.
+
+To run the database service:
+
+1. In the cloned repository's directory, open the `docker-compose.yaml` file in an IDE or text editor.
+
+2. In the `docker-compose.yaml` file, you'll see the following:
+
+   ```yaml
+   services:
+     qdrant:
+       image: qdrant/qdrant
+       container_name: qdrant
+       ports:
+         - "6333:6333"
+       volumes:
+         - qdrant_data:/qdrant/storage
+   ```
+
+   > [!NOTE]
+   > To learn more about Qdrant, see the [Qdrant Official Docker Image](https://hub.docker.com/r/qdrant/qdrant).
+
+3. Start the application. Inside the `winy` directory, run the following command in a terminal.
+
+   ```console
+   $ docker compose up --build
+   ```
+
+4. Access the application. Open a browser and view the application at [http://localhost:8501](http://localhost:8501). You should see a simple Streamlit application.
+
+5. Stop the application. In the terminal, press `ctrl`+`c` to stop the application.
+
+### Add a local or remote LLM service
+
+The sample application supports both [Ollama](https://ollama.ai/). This guide provides instructions for the following scenarios:
+
+- Run Ollama in a container
+- Run Ollama outside of a container
+
+While all platforms can use any of the previous scenarios, the performance and
+GPU support may vary. You can use the following guidelines to help you choose the appropriate option:
+
+- Run Ollama in a container if you're on Linux, and using a native installation of the Docker Engine, or Windows 10/11, and using Docker Desktop, you
+  have a CUDA-supported GPU, and your system has at least 8 GB of RAM.
+- Run Ollama outside of a container if running Docker Desktop on a Linux Machine.
+
+Choose one of the following options for your LLM service.
+
+{{< tabs >}}
+{{< tab name="Run Ollama in a container" >}}
+
+When running Ollama in a container, you should have a CUDA-supported GPU. While you can run Ollama in a container without a supported GPU, the performance may not be acceptable. Only Linux and Windows 11 support GPU access to containers.
+
+To run Ollama in a container and provide GPU access:
+
+1. Install the prerequisites.
+   - For Docker Engine on Linux, install the [NVIDIA Container Toolkilt](https://github.com/NVIDIA/nvidia-container-toolkit).
+   - For Docker Desktop on Windows 10/11, install the latest [NVIDIA driver](https://www.nvidia.com/Download/index.aspx) and make sure you are using the [WSL2 backend](/manuals/desktop/features/wsl/_index.md#turn-on-docker-desktop-wsl-2)
+2. The `docker-compose.yaml` file already contains the necessary instructions. In your own apps, you'll need to add the Ollama service in your `docker-compose.yaml`. The following is
+   the updated `docker-compose.yaml`:
+
+   ```yaml
+   ollama:
+     image: ollama/ollama
+     container_name: ollama
+     ports:
+       - "8000:8000"
+     deploy:
+       resources:
+         reservations:
+           devices:
+             - driver: nvidia
+               count: 1
+               capabilities: [gpu]
+   ```
+
+   > [!NOTE]
+   > For more details about the Compose instructions, see [Turn on GPU access with Docker Compose](/manuals/compose/how-tos/gpu-support.md).
+
+3. Once the Ollama container is up and running it is possible to use the `download_model.sh` inside the `tools` folder with this command:
+
+   ```console
+   . ./download_model.sh <model-name>
+   ```
+
+Pulling an Ollama model can take several minutes.
+
+{{< /tab >}}
+{{< tab name="Run Ollama outside of a container" >}}
+
+To run Ollama outside of a container:
+
+1. [Install](https://github.com/jmorganca/ollama) and run Ollama on your host
+   machine.
+2. Pull the model to Ollama using the following command.
+
+   ```console
+   $ ollama pull llama2
+   ```
+
+3. Remove the `ollama` service from the `docker-compose.yaml` and update properly the connection variables in `winy` service:
+
+   ```diff
+   - OLLAMA=http://ollama:11434
+   + OLLAMA=<your-url>
+   ```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Run your RAG application
+
+At this point, you have the following services in your Compose file:
+
+- Server service for your main RAG application
+- Database service to store vectors in a Qdrant database
+- (optional) Ollama service to run the LLM
+  service
+
+Once the application is running, open a browser and access the application at [http://localhost:8501](http://localhost:8501).
+
+Depending on your system and the LLM service that you chose, it may take several
+minutes to answer.
+
+### Summary
+
+In this section, you learned how to set up a development environment to provide
+access all the services that your GenAI application needs.
+
+Related information:
+
+- [Dockerfile reference](/reference/dockerfile.md)
+- [Compose file reference](/reference/compose-file/_index.md)
+- [Ollama Docker image](https://hub.docker.com/r/ollama/ollama)
+- [GenAI Stack demo applications](https://github.com/docker/genai-stack)
+
+### Next steps
+
+See samples of more GenAI applications in the [GenAI Stack demo applications](https://github.com/docker/genai-stack).
diff --git a/content/guides/rag-ollama/_index.md b/content/guides/rag-ollama/_index.md
deleted file mode 100644
index 79bfff446fbc..000000000000
--- a/content/guides/rag-ollama/_index.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-description: Containerize RAG application using Ollama and Docker
-keywords: python, generative ai, genai, llm, ollama, rag, qdrant
-title: Build a RAG application using Ollama and Docker
-linkTitle: RAG Ollama application
-summary: |
-  This guide demonstrates how to use Docker to deploy Retrieval-Augmented
-  Generation (RAG) models with Ollama.
-tags: [ai]
-aliases:
-  - /guides/use-case/rag-ollama/
-params:
-  time: 20 minutes
----
-
-The Retrieval Augmented Generation (RAG) guide teaches you how to containerize an existing RAG application using Docker. The example application is a RAG that acts like a sommelier, giving you the best pairings between wines and food. In this guide, you’ll learn how to:
-
-- Containerize and run a RAG application
-- Set up a local environment to run the complete RAG stack locally for development
-
-Start by containerizing an existing RAG application.
diff --git a/content/guides/rag-ollama/containerize.md b/content/guides/rag-ollama/containerize.md
deleted file mode 100644
index 402c480af541..000000000000
--- a/content/guides/rag-ollama/containerize.md
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: Containerize a RAG application
-linkTitle: Containerize your app
-weight: 10
-keywords: python, generative ai, genai, llm, ollama, containerize, initialize, qdrant
-description: Learn how to containerize a RAG application.
-aliases:
-  - /guides/use-case/rag-ollama/containerize/
----
-
-## Overview
-
-This section walks you through containerizing a RAG application using Docker.
-
-> [!NOTE]
-> You can see more samples of containerized GenAI applications in the [GenAI Stack](https://github.com/docker/genai-stack) demo applications.
-
-## Get the sample application
-
-The sample application used in this guide is an example of RAG application, made by three main components, which are the building blocks for every RAG application. A Large Language Model hosted somewhere, in this case it is hosted in a container and served via [Ollama](https://ollama.ai/). A vector database, [Qdrant](https://qdrant.tech/), to store the embeddings of local data, and a web application, using [Streamlit](https://streamlit.io/) to offer the best user experience to the user.
-
-Clone the sample application. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
-
-```console
-$ git clone https://github.com/mfranzon/winy.git
-```
-
-You should now have the following files in your `winy` directory.
-
-```text
-├── winy/
-│ ├── .gitignore
-│ ├── app/
-│ │ ├── main.py
-│ │ ├── Dockerfile
-| | └── requirements.txt
-│ ├── tools/
-│ │ ├── create_db.py
-│ │ ├── create_embeddings.py
-│ │ ├── requirements.txt
-│ │ ├── test.py
-| | └── download_model.sh
-│ ├── docker-compose.yaml
-│ ├── wine_database.db
-│ ├── LICENSE
-│ └── README.md
-```
-
-## Containerizing your application: Essentials
-
-Containerizing an application involves packaging it along with its dependencies into a container, which ensures consistency across different environments. Here’s what you need to containerize an app like Winy :
-
-1. Dockerfile: A Dockerfile that contains instructions on how to build a Docker image for your application. It specifies the base image, dependencies, configuration files, and the command to run your application.
-
-2. Docker Compose File: Docker Compose is a tool for defining and running multi-container Docker applications. A Compose file allows you to configure your application's services, networks, and volumes in a single file.
-
-## Run the application
-
-Inside the `winy` directory, run the following command in a
-terminal.
-
-```console
-$ docker compose up --build
-```
-
-Docker builds and runs your application. Depending on your network connection, it may take several minutes to download all the dependencies. You'll see a message like the following in the terminal when the application is running.
-
-```console
-server-1  |   You can now view your Streamlit app in your browser.
-server-1  |
-server-1  |   URL: http://0.0.0.0:8501
-server-1  |
-```
-
-Open a browser and view the application at [http://localhost:8501](http://localhost:8501). You should see a simple Streamlit application.
-
-The application requires a Qdrant database service and an LLM service to work properly. If you have access to services that you ran outside of Docker, specify the connection information in the `docker-compose.yaml`.
-
-```yaml
-winy:
-  build:
-    context: ./app
-    dockerfile: Dockerfile
-  environment:
-    - QDRANT_CLIENT=http://qdrant:6333 # Specifies the url for the qdrant database
-    - OLLAMA=http://ollama:11434 # Specifies the url for the ollama service
-  container_name: winy
-  ports:
-    - "8501:8501"
-  depends_on:
-    - qdrant
-    - ollama
-```
-
-If you don't have the services running, continue with this guide to learn how you can run some or all of these services with Docker.
-Remember that the `ollama` service is empty; it doesn't have any model. For this reason you need to pull a model before starting to use the RAG application. All the instructions are in the following page.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-## Summary
-
-In this section, you learned how you can containerize and run your RAG
-application using Docker.
-
-## Next steps
-
-In the next section, you'll learn how to properly configure the application with your preferred LLM model, completely locally, using Docker.
-
diff --git a/content/guides/rag-ollama/develop.md b/content/guides/rag-ollama/develop.md
deleted file mode 100644
index 280da3295777..000000000000
--- a/content/guides/rag-ollama/develop.md
+++ /dev/null
@@ -1,165 +0,0 @@
----
-title: Use containers for RAG development
-linkTitle: Develop your app
-weight: 10
-keywords: python, local, development, generative ai, genai, llm, rag, ollama
-description: Learn how to develop your generative RAG application locally.
-aliases:
-  - /guides/use-case/rag-ollama/develop/
----
-
-## Prerequisites
-
-Complete [Containerize a RAG application](containerize.md).
-
-## Overview
-
-In this section, you'll learn how to set up a development environment to access all the services that your generative RAG application needs. This includes:
-
-- Adding a local database
-- Adding a local or remote LLM service
-
-> [!NOTE]
-> You can see more samples of containerized GenAI applications in the [GenAI Stack](https://github.com/docker/genai-stack) demo applications.
-
-## Add a local database
-
-You can use containers to set up local services, like a database. In this section, you'll explore the database service in the `docker-compose.yaml` file.
-
-To run the database service:
-
-1. In the cloned repository's directory, open the `docker-compose.yaml` file in an IDE or text editor.
-
-2. In the `docker-compose.yaml` file, you'll see the following:
-
-   ```yaml
-   services:
-     qdrant:
-       image: qdrant/qdrant
-       container_name: qdrant
-       ports:
-         - "6333:6333"
-       volumes:
-         - qdrant_data:/qdrant/storage
-   ```
-
-   > [!NOTE]
-   > To learn more about Qdrant, see the [Qdrant Official Docker Image](https://hub.docker.com/r/qdrant/qdrant).
-
-3. Start the application. Inside the `winy` directory, run the following command in a terminal.
-
-   ```console
-   $ docker compose up --build
-   ```
-
-4. Access the application. Open a browser and view the application at [http://localhost:8501](http://localhost:8501). You should see a simple Streamlit application.
-
-5. Stop the application. In the terminal, press `ctrl`+`c` to stop the application.
-
-## Add a local or remote LLM service
-
-The sample application supports both [Ollama](https://ollama.ai/). This guide provides instructions for the following scenarios:
-
-- Run Ollama in a container
-- Run Ollama outside of a container
-
-While all platforms can use any of the previous scenarios, the performance and
-GPU support may vary. You can use the following guidelines to help you choose the appropriate option:
-
-- Run Ollama in a container if you're on Linux, and using a native installation of the Docker Engine, or Windows 10/11, and using Docker Desktop, you
-  have a CUDA-supported GPU, and your system has at least 8 GB of RAM.
-- Run Ollama outside of a container if running Docker Desktop on a Linux Machine.
-
-Choose one of the following options for your LLM service.
-
-{{< tabs >}}
-{{< tab name="Run Ollama in a container" >}}
-
-When running Ollama in a container, you should have a CUDA-supported GPU. While you can run Ollama in a container without a supported GPU, the performance may not be acceptable. Only Linux and Windows 11 support GPU access to containers.
-
-To run Ollama in a container and provide GPU access:
-
-1. Install the prerequisites.
-   - For Docker Engine on Linux, install the [NVIDIA Container Toolkilt](https://github.com/NVIDIA/nvidia-container-toolkit).
-   - For Docker Desktop on Windows 10/11, install the latest [NVIDIA driver](https://www.nvidia.com/Download/index.aspx) and make sure you are using the [WSL2 backend](/manuals/desktop/features/wsl/_index.md#turn-on-docker-desktop-wsl-2)
-2. The `docker-compose.yaml` file already contains the necessary instructions. In your own apps, you'll need to add the Ollama service in your `docker-compose.yaml`. The following is
-   the updated `docker-compose.yaml`:
-
-   ```yaml
-   ollama:
-     image: ollama/ollama
-     container_name: ollama
-     ports:
-       - "8000:8000"
-     deploy:
-       resources:
-         reservations:
-           devices:
-             - driver: nvidia
-               count: 1
-               capabilities: [gpu]
-   ```
-
-   > [!NOTE]
-   > For more details about the Compose instructions, see [Turn on GPU access with Docker Compose](/manuals/compose/how-tos/gpu-support.md).
-
-3. Once the Ollama container is up and running it is possible to use the `download_model.sh` inside the `tools` folder with this command:
-
-   ```console
-   . ./download_model.sh <model-name>
-   ```
-
-Pulling an Ollama model can take several minutes.
-
-{{< /tab >}}
-{{< tab name="Run Ollama outside of a container" >}}
-
-To run Ollama outside of a container:
-
-1. [Install](https://github.com/jmorganca/ollama) and run Ollama on your host
-   machine.
-2. Pull the model to Ollama using the following command.
-
-   ```console
-   $ ollama pull llama2
-   ```
-
-3. Remove the `ollama` service from the `docker-compose.yaml` and update properly the connection variables in `winy` service:
-
-   ```diff
-   - OLLAMA=http://ollama:11434
-   + OLLAMA=<your-url>
-   ```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Run your RAG application
-
-At this point, you have the following services in your Compose file:
-
-- Server service for your main RAG application
-- Database service to store vectors in a Qdrant database
-- (optional) Ollama service to run the LLM
-  service
-
-Once the application is running, open a browser and access the application at [http://localhost:8501](http://localhost:8501).
-
-Depending on your system and the LLM service that you chose, it may take several
-minutes to answer.
-
-## Summary
-
-In this section, you learned how to set up a development environment to provide
-access all the services that your GenAI application needs.
-
-Related information:
-
-- [Dockerfile reference](/reference/dockerfile.md)
-- [Compose file reference](/reference/compose-file/_index.md)
-- [Ollama Docker image](https://hub.docker.com/r/ollama/ollama)
-- [GenAI Stack demo applications](https://github.com/docker/genai-stack)
-
-## Next steps
-
-See samples of more GenAI applications in the [GenAI Stack demo applications](https://github.com/docker/genai-stack).
diff --git a/content/guides/reactjs.md b/content/guides/reactjs.md
new file mode 100644
index 000000000000..3a1545e65a8f
--- /dev/null
+++ b/content/guides/reactjs.md
@@ -0,0 +1,854 @@
+---
+title: React.js language-specific guide
+linkTitle: React.js
+description: Containerize and develop React.js apps using Docker
+keywords: getting started, React.js, react.js, docker, language, Dockerfile
+summary: |
+  This guide explains how to containerize React.js applications using Docker.
+aliases:
+  - /guides/reactjs/configure-github-actions/
+  - /guides/reactjs/containerize/
+  - /guides/reactjs/deploy/
+  - /guides/reactjs/develop/
+  - /guides/reactjs/run-tests/
+params:
+  tags: [languages]
+  time: 20 minutes
+---
+
+The React.js language-specific guide shows you how to containerize a React.js application using Docker, following best practices for creating efficient, production-ready containers.
+
+[React.js](https://react.dev/) is a widely used library for building interactive user interfaces. However, managing dependencies, environments, and deployments efficiently can be complex. Docker simplifies this process by providing a consistent and containerized environment.
+
+> **Acknowledgment**
+>
+> Docker extends its sincere gratitude to [Kristiyan Velkov](https://www.linkedin.com/in/kristiyan-velkov-763130b3/) for authoring this guide. As a Docker Captain and experienced Front-end engineer, his expertise in Docker, DevOps, and modern web development has made this resource invaluable for the community, helping developers navigate and optimize their Docker workflows.
+
+---
+
+## What will you learn?
+
+In this guide, you will learn how to:
+
+- Containerize and run a React.js application using Docker.
+- Set up a local development environment for React.js inside a container.
+- Run tests for your React.js application within a Docker container.
+
+To begin, you’ll start by containerizing an existing React.js application.
+
+---
+
+## Prerequisites
+
+Before you begin, make sure you're familiar with the following:
+
+- Basic understanding of [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript) or [TypeScript](https://www.typescriptlang.org/).
+- Basic knowledge of [Node.js](https://nodejs.org/en) and [npm](https://docs.npmjs.com/about-npm) for managing dependencies and running scripts.
+- Familiarity with [React.js](https://react.dev/) fundamentals.
+- Understanding of Docker concepts such as images, containers, and Dockerfiles. If you're new to Docker, start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
+
+Once you've completed the React.js getting started modules, you’ll be ready to containerize your own React.js application using the examples and instructions provided in this guide.
+
+## Containerize a React.js Application
+
+### Prerequisites
+
+Before you begin, make sure the following tools are installed and available on your system:
+
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
+- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
+
+> **New to Docker?**  
+> Start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide to get familiar with key concepts like images, containers, and Dockerfiles.
+
+---
+
+### Overview
+
+This guide walks you through the complete process of containerizing a React.js application with Docker. You’ll learn how to create a production-ready Docker image using best practices that improve performance, security, scalability, and deployment efficiency.
+
+By the end of this guide, you will:
+
+- Containerize a React.js application using Docker.
+- Create and optimize a Dockerfile for production builds.
+- Use multi-stage builds to minimize image size.
+- Serve the application efficiently with a custom NGINX configuration.
+- Follow best practices for building secure and maintainable Docker images.
+
+---
+
+### Get the sample application
+
+Clone the sample application to use with this guide. Open a terminal, change
+directory to a directory that you want to work in, and run the following command
+to clone the git repository:
+
+```console
+$ git clone https://github.com/kristiyan-velkov/docker-reactjs-sample
+```
+
+---
+
+### Build the Docker image
+
+React.js is a front-end library that compiles into static assets, so the Dockerfile is tailored to optimize how React applications are built and served in a production environment.
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for your project. Ask Gordon to create a Dockerfile, Compose file, and `.dockerignore` tailored to your application.
+
+#### Step 1: Create the Dockerfile
+
+Before creating a Dockerfile, you need to choose a base image. You can either use the [Node.js Official Image](https://hub.docker.com/_/node) or a Docker Hardened Image (DHI) from the [Hardened Image catalog](https://hub.docker.com/hardened-images/catalog).
+
+Choosing DHI offers the advantage of a production-ready image that is lightweight and secure. For more information, see [Docker Hardened Images](https://docs.docker.com/dhi/).
+
+> [!IMPORTANT]
+> This guide uses a stable Node.js LTS image tag that is considered secure when the guide is written. Because new releases and security patches are published regularly, the tag shown here may no longer be the safest option when you follow the guide. Always review the latest available image tags and select a secure, up-to-date version before building or deploying your application.
+>
+> Official Node.js Docker Images: https://hub.docker.com/_/node
+
+{{< tabs >}}
+{{< tab name="Using Docker Hardened Images" >}}
+Docker Hardened Images (DHIs) are available for Node.js in the [Docker Hardened Images catalog](https://hub.docker.com/hardened-images/catalog/dhi/node). Docker Hardened Images are freely available to everyone with no subscription required. You can pull and use them like any other Docker image after signing in to the DHI registry. For more information, see the [DHI quickstart](/dhi/get-started/) guide.
+
+1. Sign in to the DHI registry:
+
+   ```console
+   $ docker login dhi.io
+   ```
+
+2. Pull the Node.js DHI (check the catalog for available versions):
+
+   ```console
+   $ docker pull dhi.io/node:24-alpine3.22-dev
+   ```
+
+3. Pull the Nginx DHI (check the catalog for available versions):
+   ```console
+   $ docker pull dhi.io/nginx:1.28.0-alpine3.21-dev
+   ```
+
+In the following Dockerfile, the `FROM` instructions use `dhi.io/node:24-alpine3.22-dev` and `dhi.io/nginx:1.28.0-alpine3.21-dev` as the base images.
+
+```dockerfile
+# =========================================
+# Stage 1: Build the React.js Application
+# =========================================
+
+# Use a lightweight Node.js image for building (customizable via ARG)
+FROM dhi.io/node:24-alpine3.22-dev AS builder
+
+# Set the working directory inside the container
+WORKDIR /app
+
+# Copy package-related files first to leverage Docker's caching mechanism
+COPY package.json package-lock.json* ./
+
+# Install project dependencies using npm ci (ensures a clean, reproducible install)
+RUN --mount=type=cache,target=/root/.npm npm ci
+
+# Copy the rest of the application source code into the container
+COPY . .
+
+# Build the React.js application (outputs to /app/dist)
+RUN npm run build
+
+# =========================================
+# Stage 2: Prepare Nginx to Serve Static Files
+# =========================================
+
+FROM dhi.io/nginx:1.28.0-alpine3.21-dev AS runner
+
+# Copy custom Nginx config
+COPY nginx.conf /etc/nginx/nginx.conf
+
+# Copy the static build output from the build stage to Nginx's default HTML serving directory
+COPY --chown=nginx:nginx --from=builder /app/dist /usr/share/nginx/html
+
+# Use a non-root user for security best practices
+USER nginx
+
+# Expose port 8080 to allow HTTP traffic
+# Note: The default NGINX container now listens on port 8080 instead of 80
+EXPOSE 8080
+
+# Start Nginx directly with custom config
+ENTRYPOINT ["nginx", "-c", "/etc/nginx/nginx.conf"]
+CMD ["-g", "daemon off;"]
+```
+
+{{< /tab >}}
+{{< tab name="Using the Docker Official Image" >}}
+
+Create a file named `Dockerfile` with the following contents:
+
+```dockerfile
+# =========================================
+# Stage 1: Build the React.js Application
+# =========================================
+ARG NODE_VERSION=24.12.0-alpine
+ARG NGINX_VERSION=alpine3.22
+
+# Use a lightweight Node.js image for building (customizable via ARG)
+FROM node:${NODE_VERSION} AS builder
+
+# Set the working directory inside the container
+WORKDIR /app
+
+# Copy package-related files first to leverage Docker's caching mechanism
+COPY package.json package-lock.json* ./
+
+# Install project dependencies using npm ci (ensures a clean, reproducible install)
+RUN --mount=type=cache,target=/root/.npm npm ci
+
+# Copy the rest of the application source code into the container
+COPY . .
+
+# Build the React.js application (outputs to /app/dist)
+RUN npm run build
+
+# =========================================
+# Stage 2: Prepare Nginx to Serve Static Files
+# =========================================
+
+FROM nginxinc/nginx-unprivileged:${NGINX_VERSION} AS runner
+
+# Copy custom Nginx config
+COPY nginx.conf /etc/nginx/nginx.conf
+
+# Copy the static build output from the build stage to Nginx's default HTML serving directory
+COPY --chown=nginx:nginx --from=builder /app/dist /usr/share/nginx/html
+
+# Use a built-in non-root user for security best practices
+USER nginx
+
+# Expose port 8080 to allow HTTP traffic
+# Note: The default NGINX container now listens on port 8080 instead of 80
+EXPOSE 8080
+
+# Start Nginx directly with custom config
+ENTRYPOINT ["nginx", "-c", "/etc/nginx/nginx.conf"]
+CMD ["-g", "daemon off;"]
+```
+
+> [!NOTE]
+> We are using nginx-unprivileged instead of the standard NGINX image to follow security best practices.
+> Running as a non-root user in the final image:
+>
+> - Reduces the attack surface
+> - Aligns with Docker’s recommendations for container hardening
+> - Helps comply with stricter security policies in production environments
+
+{{< /tab >}}
+{{< /tabs >}}
+
+#### Step 2: Create the compose.yaml file
+
+Create a file named `compose.yaml` with the following contents:
+
+```yaml {collapse=true,title=compose.yaml}
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 8080:8080
+```
+
+#### Step 3: Create the .dockerignore file
+
+The `.dockerignore` file tells Docker which files and folders to exclude when building the image.
+
+> [!NOTE]
+> This helps:
+>
+> - Reduce image size
+> - Speed up the build process
+> - Prevent sensitive or unnecessary files (like `.env`, `.git`, or `node_modules`) from being added to the final image.
+>
+> To learn more, visit the [.dockerignore reference](/reference/dockerfile.md#dockerignore-file).
+
+Create a file named `.dockerignore` with the following contents:
+
+```dockerignore
+# Ignore dependencies and build output
+node_modules/
+dist/
+out/
+.tmp/
+.cache/
+
+# Ignore Vite, Webpack, and React-specific build artifacts
+.vite/
+.vitepress/
+.eslintcache
+.npm/
+coverage/
+jest/
+cypress/
+cypress/screenshots/
+cypress/videos/
+reports/
+
+# Ignore environment and config files (sensitive data)
+*.env*
+*.log
+
+# Ignore TypeScript build artifacts (if using TypeScript)
+*.tsbuildinfo
+
+# Ignore lockfiles (optional if using Docker for package installation)
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+pnpm-debug.log*
+
+# Ignore local development files
+.git/
+.gitignore
+.vscode/
+.idea/
+*.swp
+.DS_Store
+Thumbs.db
+
+# Ignore Docker-related files (to avoid copying unnecessary configs)
+Dockerfile
+.dockerignore
+docker-compose.yml
+docker-compose.override.yml
+
+# Ignore build-specific cache files
+*.lock
+
+```
+
+#### Step 4: Create the `nginx.conf` file
+
+To serve your React.js application efficiently inside the container, you’ll configure NGINX with a custom setup. This configuration is optimized for performance, browser caching, gzip compression, and support for client-side routing.
+
+Create a file named `nginx.conf` in the root of your project directory, and add the following content:
+
+> [!NOTE]
+> To learn more about configuring NGINX, see the [official NGINX documentation](https://nginx.org/en/docs/).
+
+```nginx
+worker_processes auto;
+
+# Store PID in /tmp (always writable)
+pid /tmp/nginx.pid;
+
+events {
+    worker_connections 1024;
+}
+
+http {
+    include       /etc/nginx/mime.types;
+    default_type  application/octet-stream;
+
+    # Disable logging to avoid permission issues
+    access_log off;
+    error_log  /dev/stderr warn;
+
+    # Optimize static file serving
+    sendfile        on;
+    tcp_nopush      on;
+    tcp_nodelay     on;
+    keepalive_timeout  65;
+    keepalive_requests 1000;
+
+    # Gzip compression for optimized delivery
+    gzip on;
+    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
+    gzip_min_length 256;
+    gzip_vary on;
+
+    server {
+        listen       8080;
+        server_name  localhost;
+
+        # Root directory where React.js build files are placed
+        root /usr/share/nginx/html;
+        index index.html;
+
+        # Serve React.js static files with proper caching
+        location / {
+            try_files $uri /index.html;
+        }
+
+        # Serve static assets with long cache expiration
+        location ~* \.(?:ico|css|js|gif|jpe?g|png|woff2?|eot|ttf|svg|map)$ {
+            expires 1y;
+            access_log off;
+            add_header Cache-Control "public, immutable";
+        }
+
+        # Handle React.js client-side routing
+        location /static/ {
+            expires 1y;
+            add_header Cache-Control "public, immutable";
+        }
+    }
+}
+```
+
+#### Step 5: Build the React.js application image
+
+With your custom configuration in place, you're now ready to build the Docker image for your React.js application.
+
+The updated setup includes:
+
+- Optimized browser caching and gzip compression
+- Secure, non-root logging to avoid permission issues
+- Support for React client-side routing by redirecting unmatched routes to `index.html`
+
+After completing the previous steps, your project directory should now contain the following files:
+
+```text
+├── docker-reactjs-sample/
+│ ├── Dockerfile
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ └── nginx.conf
+```
+
+Now that your Dockerfile is configured, you can build the Docker image for your React.js application.
+
+> [!NOTE]
+> The `docker build` command packages your application into an image using the instructions in the Dockerfile. It includes all necessary files from the current directory (called the [build context](/build/concepts/context/#what-is-a-build-context)).
+
+Run the following command from the root of your project:
+
+```console
+$ docker build --tag docker-reactjs-sample .
+```
+
+What this command does:
+
+- Uses the Dockerfile in the current directory (.)
+- Packages the application and its dependencies into a Docker image
+- Tags the image as docker-reactjs-sample so you can reference it later
+
+#### Step 6: View local images
+
+After building your Docker image, you can check which images are available on your local machine using either the Docker CLI or [Docker Desktop](/manuals/desktop/use-desktop/images.md). Since you're already working in the terminal, let's use the Docker CLI.
+
+To list all locally available Docker images, run the following command:
+
+```console
+$ docker images
+```
+
+Example Output:
+
+```shell
+REPOSITORY                TAG               IMAGE ID       CREATED         SIZE
+docker-reactjs-sample     latest            f39b47a97156   14 seconds ago   75.8MB
+```
+
+This output provides key details about your images:
+
+- **Repository** – The name assigned to the image.
+- **Tag** – A version label that helps identify different builds (e.g., latest).
+- **Image ID** – A unique identifier for the image.
+- **Created** – The timestamp indicating when the image was built.
+- **Size** – The total disk space used by the image.
+
+If the build was successful, you should see `docker-reactjs-sample` image listed.
+
+---
+
+### Run the containerized application
+
+In the previous step, you created a Dockerfile for your React.js application and built a Docker image using the docker build command. Now it’s time to run that image in a container and verify that your application works as expected.
+
+Inside the `docker-reactjs-sample` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple React.js web application.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `docker-reactjs-sample` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple web application preview.
+
+To confirm that the container is running, use `docker ps` command:
+
+```console
+$ docker ps
+```
+
+This will list all active containers along with their ports, names, and status. Look for a container exposing port 8080.
+
+Example Output:
+
+```shell
+CONTAINER ID   IMAGE                          COMMAND                  CREATED             STATUS             PORTS                    NAMES
+88bced6ade95   docker-reactjs-sample-server   "nginx -c /etc/nginx…"   About a minute ago  Up About a minute  0.0.0.0:8080->8080/tcp   docker-reactjs-sample-server-1
+```
+
+To stop the application, run:
+
+```console
+$ docker compose down
+```
+
+> [!NOTE]
+> For more information about Compose commands, see the [Compose CLI
+> reference](/reference/cli/docker/compose/).
+
+---
+
+## Use containers for React.js development
+
+### Prerequisites
+
+Complete [Containerize React.js application](#containerize-a-reactjs-application).
+
+---
+
+### Overview
+
+In this section, you'll learn how to set up both production and development environments for your containerized React.js application using Docker Compose. This setup allows you to serve a static production build via Nginx and to develop efficiently inside containers using a live-reloading dev server with Compose Watch.
+
+You’ll learn how to:
+
+- Configure separate containers for production and development
+- Enable automatic file syncing using Compose Watch in development
+- Debug and live-preview your changes in real-time without manual rebuilds
+
+---
+
+### Automatically update services (development mode)
+
+Use Compose Watch to automatically sync source file changes into your containerized development environment. This provides a seamless, efficient development experience without needing to restart or rebuild containers manually.
+
+### Step 1: Create a development Dockerfile
+
+Create a file named `Dockerfile.dev` in your project root with the following content:
+
+```dockerfile
+# =========================================
+# Stage 1: Develop the React.js Application
+# =========================================
+ARG NODE_VERSION=24.12.0-alpine
+
+# Use a lightweight Node.js image for development
+FROM node:${NODE_VERSION} AS dev
+
+# Set the working directory inside the container
+WORKDIR /app
+
+# Copy package-related files first to leverage Docker's caching mechanism
+COPY package.json package-lock.json* ./
+
+# Install project dependencies
+RUN --mount=type=cache,target=/root/.npm npm install
+
+# Copy the rest of the application source code into the container
+COPY . .
+
+# Expose the port used by the Vite development server
+EXPOSE 5173
+
+# Use a default command, can be overridden in Docker compose.yml file
+CMD ["npm", "run", "dev"]
+```
+
+This file sets up a lightweight development environment for your React app using the dev server.
+
+#### Step 2: Update your `compose.yaml` file
+
+Open your `compose.yaml` file and define two services: one for production (`react-prod`) and one for development (`react-dev`).
+
+Here’s an example configuration for a React.js application:
+
+```yaml
+services:
+  react-prod:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: docker-reactjs-sample
+    ports:
+      - "8080:8080"
+
+  react-dev:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    ports:
+      - "5173:5173"
+    develop:
+      watch:
+        - action: sync
+          path: .
+          target: /app
+```
+
+- The `react-prod` service builds and serves your static production app using Nginx.
+- The `react-dev` service runs your React development server with live reload and hot module replacement.
+- `watch` triggers file sync with Compose Watch.
+
+> [!NOTE]
+> For more details, see the official guide: [Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
+
+#### Step 3: Update vite.config.ts to ensure it works properly inside Docker
+
+To make Vite’s development server work reliably inside Docker, you need to update your vite.config.ts with the correct settings.
+
+Open the `vite.config.ts` file in your project root and update it as follows:
+
+```ts
+/// <reference types="vitest" />
+
+import { defineConfig } from "vite";
+import react from "@vitejs/plugin-react";
+
+export default defineConfig({
+  base: "/",
+  plugins: [react()],
+  server: {
+    host: true,
+    port: 5173,
+    strictPort: true,
+  },
+});
+```
+
+> [!NOTE]
+> The `server` options in `vite.config.ts` are essential for running Vite inside Docker:
+>
+> - `host: true` allows the dev server to be accessible from outside the container.
+> - `port: 5173` sets a consistent development port (must match the one exposed in Docker).
+> - `strictPort: true` ensures Vite fails clearly if the port is unavailable, rather than switching silently.
+>
+> For full details, refer to the [Vite server configuration docs](https://vitejs.dev/config/server-options.html).
+
+After completing the previous steps, your project directory should now contain the following files:
+
+```text
+├── docker-reactjs-sample/
+│ ├── Dockerfile
+│ ├── Dockerfile.dev
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ └── nginx.conf
+```
+
+#### Step 4: Start Compose Watch
+
+Run the following command from your project root to start your container in watch mode:
+
+```console
+$ docker compose watch react-dev
+```
+
+#### Step 5: Test Compose Watch with React
+
+To verify that Compose Watch is working correctly:
+
+1. Open the `src/App.tsx` file in your text editor.
+
+2. Locate the following line:
+
+   ```html
+   <h1>Vite + React</h1>
+   ```
+
+3. Change it to:
+
+   ```html
+   <h1>Hello from Docker Compose Watch</h1>
+   ```
+
+4. Save the file.
+
+5. Open your browser at [http://localhost:5173](http://localhost:5173).
+
+You should see the updated text appear instantly, without needing to rebuild the container manually. This confirms that file watching and automatic synchronization are working as expected.
+
+---
+
+## Run React.js tests in a container
+
+### Prerequisites
+
+Complete all the previous sections of this guide, starting with [Containerize React.js application](#containerize-a-reactjs-application).
+
+### Overview
+
+Testing is a critical part of the development process. In this section, you'll learn how to:
+
+- Run unit tests using Vitest inside a Docker container.
+- Use Docker Compose to run tests in an isolated, reproducible environment.
+
+You’ll use [Vitest](https://vitest.dev) — a blazing fast test runner designed for Vite — along with [Testing Library](https://testing-library.com/) for assertions.
+
+---
+
+### Run tests during development
+
+`docker-reactjs-sample` application includes a sample test file at location:
+
+```console
+$ src/App.test.tsx
+```
+
+This file uses Vitest and React Testing Library to verify the behavior of `App` component.
+
+#### Step 1: Install Vitest and React Testing Library
+
+If you haven’t already added the necessary testing tools, install them by running:
+
+```console
+$ npm install --save-dev vitest @testing-library/react @testing-library/jest-dom jsdom
+```
+
+Then, update the scripts section of your `package.json` file to include the following:
+
+```json
+"scripts": {
+  "test": "vitest run"
+}
+```
+
+---
+
+#### Step 2: Configure Vitest
+
+Update `vitest.config.ts` file in your project root with the following configuration:
+
+```ts {hl_lines="14-18",linenos=true}
+/// <reference types="vitest" />
+
+import { defineConfig } from "vite";
+import react from "@vitejs/plugin-react";
+
+export default defineConfig({
+  base: "/",
+  plugins: [react()],
+  server: {
+    host: true,
+    port: 5173,
+    strictPort: true,
+  },
+  test: {
+    environment: "jsdom",
+    setupFiles: "./src/setupTests.ts",
+    globals: true,
+  },
+});
+```
+
+> [!NOTE]
+> The `test` options in `vitest.config.ts` are essential for reliable testing inside Docker:
+>
+> - `environment: "jsdom"` simulates a browser-like environment for rendering and DOM interactions.
+> - `setupFiles: "./src/setupTests.ts"` loads global configuration or mocks before each test file (optional but recommended).
+> - `globals: true` enables global test functions like `describe`, `it`, and `expect` without importing them.
+>
+> For more details, see the official [Vitest configuration docs](https://vitest.dev/config/).
+
+#### Step 3: Update compose.yaml
+
+Add a new service named `react-test` to your `compose.yaml` file. This service allows you to run your test suite in an isolated containerized environment.
+
+```yaml {hl_lines="22-26",linenos=true}
+services:
+  react-dev:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    ports:
+      - "5173:5173"
+    develop:
+      watch:
+        - action: sync
+          path: .
+          target: /app
+
+  react-prod:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: docker-reactjs-sample
+    ports:
+      - "8080:8080"
+
+  react-test:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    command: ["npm", "run", "test"]
+```
+
+The react-test service reuses the same `Dockerfile.dev` used for [development](#use-containers-for-reactjs-development) and overrides the default command to run tests with `npm run test`. This setup ensures a consistent test environment that matches your local development configuration.
+
+After completing the previous steps, your project directory should contain the following files:
+
+```text
+├── docker-reactjs-sample/
+│ ├── Dockerfile
+│ ├── Dockerfile.dev
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ └── nginx.conf
+```
+
+#### Step 4: Run the tests
+
+To execute your test suite inside the container, run the following command from your project root:
+
+```console
+$ docker compose run --rm react-test
+```
+
+This command will:
+
+- Start the `react-test` service defined in your `compose.yaml` file.
+- Execute the `npm run test` script using the same environment as development.
+- Automatically remove the container after the tests complete [`docker compose run --rm`](/reference/cli/docker/compose/run/) command.
+
+> [!NOTE]
+> For more information about Compose commands, see the [Compose CLI
+> reference](/reference/cli/docker/compose/).
+
+---
+
+### Summary
+
+In this section, you learned how to run unit tests for your React.js application inside a Docker container using Vitest and Docker Compose.
+
+What you accomplished:
+
+- Installed and configured Vitest and React Testing Library for testing React components.
+- Created a `react-test` service in `compose.yaml` to isolate test execution.
+- Reused the development `Dockerfile.dev` to ensure consistency between dev and test environments.
+- Ran tests inside the container using `docker compose run --rm react-test`.
+- Ensured reliable, repeatable testing across environments without relying on local machine setup.
+
+---
+
+### Related resources
+
+Explore official references and best practices to sharpen your Docker testing workflow:
+
+- [Dockerfile reference](/reference/dockerfile/) – Understand all Dockerfile instructions and syntax.
+- [Best practices for writing Dockerfiles](/develop/develop-images/dockerfile_best-practices/) – Write efficient, maintainable, and secure Dockerfiles.
+- [Compose file reference](/compose/compose-file/) – Learn the full syntax and options available for configuring services in `compose.yaml`.
+- [`docker compose run` CLI reference](/reference/cli/docker/compose/run/) – Run one-off commands in a service container.
diff --git a/content/guides/reactjs/_index.md b/content/guides/reactjs/_index.md
deleted file mode 100644
index 10024e063f5e..000000000000
--- a/content/guides/reactjs/_index.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: React.js language-specific guide
-linkTitle: React.js
-description: Containerize and develop React.js apps using Docker
-keywords: getting started, React.js, react.js, docker, language, Dockerfile
-summary: |
-  This guide explains how to containerize React.js applications using Docker.
-toc_min: 1
-toc_max: 2
-languages: [js]
-params:
-  time: 20 minutes
-
----
-
-The React.js language-specific guide shows you how to containerize a React.js application using Docker, following best practices for creating efficient, production-ready containers.
-
-[React.js](https://react.dev/) is a widely used library for building interactive user interfaces. However, managing dependencies, environments, and deployments efficiently can be complex. Docker simplifies this process by providing a consistent and containerized environment.
-
-> 
-> **Acknowledgment**
->
-> Docker extends its sincere gratitude to [Kristiyan Velkov](https://www.linkedin.com/in/kristiyan-velkov-763130b3/) for authoring this guide. As a Docker Captain and experienced Front-end engineer, his expertise in Docker, DevOps, and modern web development has made this resource invaluable for the community, helping developers navigate and optimize their Docker workflows.
-
----
-
-## What will you learn?
-
-In this guide, you will learn how to:
-
-- Containerize and run a React.js application using Docker.
-- Set up a local development environment for React.js inside a container. 
-- Run tests for your React.js application within a Docker container.
-- Configure a CI/CD pipeline using GitHub Actions for your containerized app.
-- Deploy the containerized React.js application to a local Kubernetes cluster for testing and debugging.
-
-To begin, you’ll start by containerizing an existing React.js application.
-
----
-
-## Prerequisites
-
-Before you begin, make sure you're familiar with the following:
-
-- Basic understanding of [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript) or [TypeScript](https://www.typescriptlang.org/).
-- Basic knowledge of [Node.js](https://nodejs.org/en) and [npm](https://docs.npmjs.com/about-npm) for managing dependencies and running scripts.
-- Familiarity with [React.js](https://react.dev/) fundamentals.
-- Understanding of Docker concepts such as images, containers, and Dockerfiles. If you're new to Docker, start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
-
-Once you've completed the React.js getting started modules, you’ll be ready to containerize your own React.js application using the examples and instructions provided in this guide.
diff --git a/content/guides/reactjs/configure-ci-cd.md b/content/guides/reactjs/configure-ci-cd.md
deleted file mode 100644
index bced3a22e841..000000000000
--- a/content/guides/reactjs/configure-ci-cd.md
+++ /dev/null
@@ -1,321 +0,0 @@
----
-title: Configure CI/CD for your React.js application
-linkTitle: Configure CI/CD
-weight: 60
-keywords: CI/CD, GitHub( Actions), React.js, Next.js
-description: Learn how to configure CI/CD using GitHub Actions for your React.js application.
-
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize React.js application](containerize.md).
-
-You must also have:
-- A [GitHub](https://github.com/signup) account.
-- A [Docker Hub](https://hub.docker.com/signup) account.
-
----
-
-## Overview
-
-In this section, you'll set up a **CI/CD pipeline** using [GitHub Actions](https://docs.github.com/en/actions) to automatically:
-
-- Build your React.js application inside a Docker container.
-- Run tests in a consistent environment.
-- Push the production-ready image to [Docker Hub](https://hub.docker.com).
-
----
-
-## Connect your GitHub repository to Docker Hub
-
-To enable GitHub Actions to build and push Docker images, you’ll securely store your Docker Hub credentials in your new GitHub repository.
-
-### Step 1: Connect your GitHub repository to Docker Hub
-
-1. Create a Personal Access Token (PAT) from [Docker Hub](https://hub.docker.com)
-   1. Go to your **Docker Hub account → Account Settings → Security**.
-   2. Generate a new Access Token with **Read/Write** permissions.
-   3. Name it something like `docker-reactjs-sample`.
-   4. Copy and save the token — you’ll need it in Step 4.
-
-2. Create a repository in [Docker Hub](https://hub.docker.com/repositories/)
-   1. Go to your **Docker Hub account → Create a repository**.
-   2. For the Repository Name, use something descriptive — for example: `reactjs-sample`.
-   3. Once created, copy and save the repository name — you’ll need it in Step 4.
-
-3. Create a new [GitHub repository](https://github.com/new) for your React.js project
-
-4. Add Docker Hub credentials as GitHub repository secrets
-
-   In your newly created GitHub repository:
-   
-   1. Navigate to:
-   **Settings → Secrets and variables → Actions → New repository secret**.
-
-   2. Add the following secrets:
-
-   | Name              | Value                          |
-   |-------------------|--------------------------------|
-   | `DOCKER_USERNAME` | Your Docker Hub username       |
-   | `DOCKERHUB_TOKEN` | Your Docker Hub access token (created in Step 1)   |
-   | `DOCKERHUB_PROJECT_NAME` | Your Docker Project Name (created in Step 2)   |
-
-   These secrets let GitHub Actions to authenticate securely with Docker Hub during automated workflows.
-
-5. Connect Your Local Project to GitHub
-
-   Link your local project `docker-reactjs-sample` to the GitHub repository you just created by running the following command from your project root:
-
-   ```console
-      $ git remote set-url origin https://github.com/{your-username}/{your-repository-name}.git
-   ```
-
-   >[!IMPORTANT]
-   >Replace `{your-username}` and `{your-repository}` with your actual GitHub username and repository name.
-
-   To confirm that your local project is correctly connected to the remote GitHub repository, run:
-
-   ```console
-   $ git remote -v
-   ```
-
-   You should see output similar to:
-
-   ```console
-   origin  https://github.com/{your-username}/{your-repository-name}.git (fetch)
-   origin  https://github.com/{your-username}/{your-repository-name}.git (push)
-   ```
-
-   This confirms that your local repository is properly linked and ready to push your source code to GitHub.
-
-6. Push Your Source Code to GitHub
-
-   Follow these steps to commit and push your local project to your GitHub repository:
-
-   1. Stage all files for commit.
-
-      ```console
-      $ git add -A
-      ```
-      This command stages all changes — including new, modified, and deleted files — preparing them for commit.
-
-
-   2. Commit your changes.
-
-      ```console
-      $ git commit -m "Initial commit"
-      ```
-      This command creates a commit that snapshots the staged changes with a descriptive message.  
-
-   3. Push the code to the `main` branch.
-
-      ```console
-      $ git push -u origin main
-      ```
-      This command pushes your local commits to the `main` branch of the remote GitHub repository and sets the upstream branch.
-
-Once completed, your code will be available on GitHub, and any GitHub Actions workflow you’ve configured will run automatically.
-
-> [!NOTE]  
-> Learn more about the Git commands used in this step:
-> - [Git add](https://git-scm.com/docs/git-add) – Stage changes (new, modified, deleted) for commit  
-> - [Git commit](https://git-scm.com/docs/git-commit) – Save a snapshot of your staged changes  
-> - [Git push](https://git-scm.com/docs/git-push) – Upload local commits to your GitHub repository  
-> - [Git remote](https://git-scm.com/docs/git-remote) – View and manage remote repository URLs
-
----
-
-### Step 2: Set up the workflow
-
-Now you'll create a GitHub Actions workflow that builds your Docker image, runs tests, and pushes the image to Docker Hub.
-
-1. Go to your repository on GitHub and select the **Actions** tab in the top menu.
-
-2. Select **Set up a workflow yourself** when prompted.
-
-    This opens an inline editor to create a new workflow file. By default, it will be saved to:
-   `.github/workflows/main.yml`
-
-   
-3. Add the following workflow configuration to the new file:
-
-```yaml
-name: CI/CD – React.js Application with Docker
-
-on:
-  push:
-    branches: [main]
-  pull_request:
-    branches: [main]
-    types: [opened, synchronize, reopened]
-
-jobs:
-  build-test-push:
-    name: Build, Test and Push Docker Image
-    runs-on: ubuntu-latest
-
-    steps:
-      # 1. Checkout source code
-      - name: Checkout source code
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0 # Fetches full history for better caching/context
-
-      # 2. Set up Docker Buildx
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
-
-      # 3. Cache Docker layers
-      - name: Cache Docker layers
-        uses: actions/cache@v4
-        with:
-          path: /tmp/.buildx-cache
-          key: ${{ runner.os }}-buildx-${{ github.sha }}
-          restore-keys: ${{ runner.os }}-buildx-
-
-      # 4. Cache npm dependencies
-      - name: Cache npm dependencies
-        uses: actions/cache@v4
-        with:
-          path: ~/.npm
-          key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
-          restore-keys: ${{ runner.os }}-npm-
-
-      # 5. Extract metadata
-      - name: Extract metadata
-        id: meta
-        run: |
-          echo "REPO_NAME=${GITHUB_REPOSITORY##*/}" >> "$GITHUB_OUTPUT"
-          echo "SHORT_SHA=${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT"
-
-      # 6. Build dev Docker image
-      - name: Build Docker image for tests
-        uses: docker/build-push-action@v6
-        with:
-          context: .
-          file: Dockerfile.dev
-          tags: ${{ steps.meta.outputs.REPO_NAME }}-dev:latest
-          load: true # Load to local Docker daemon for testing
-          cache-from: type=local,src=/tmp/.buildx-cache
-          cache-to: type=local,dest=/tmp/.buildx-cache,mode=max
-
-      # 7. Run Vitest tests
-      - name: Run Vitest tests and generate report
-        run: |
-          docker run --rm \
-            --workdir /app \
-            --entrypoint "" \
-            ${{ steps.meta.outputs.REPO_NAME }}-dev:latest \
-            sh -c "npm ci && npx vitest run --reporter=verbose"
-        env:
-          CI: true
-          NODE_ENV: test
-        timeout-minutes: 10
-
-      # 8. Login to Docker Hub
-      - name: Log in to Docker Hub
-        uses: docker/login-action@v3
-        with:
-          username: ${{ secrets.DOCKER_USERNAME }}
-          password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-      # 9. Build and push prod image
-      - name: Build and push production image
-        uses: docker/build-push-action@v6
-        with:
-          context: .
-          file: Dockerfile
-          push: true
-          platforms: linux/amd64,linux/arm64
-          tags: |
-            ${{ secrets.DOCKER_USERNAME }}/${{ secrets.DOCKERHUB_PROJECT_NAME }}:latest
-            ${{ secrets.DOCKER_USERNAME }}/${{ secrets.DOCKERHUB_PROJECT_NAME }}:${{ steps.meta.outputs.SHORT_SHA }}
-          cache-from: type=local,src=/tmp/.buildx-cache
-```
-
-This workflow performs the following tasks for your React.js application:
-- Triggers on every `push` or `pull request` targeting the `main` branch.
-- Builds a development Docker image using `Dockerfile.dev`, optimized for testing.
-- Executes unit tests using Vitest inside a clean, containerized environment to ensure consistency.
-- Halts the workflow immediately if any test fails — enforcing code quality.
-- Caches both Docker build layers and npm dependencies for faster CI runs.
-- Authenticates securely with Docker Hub using GitHub repository secrets.
-- Builds a production-ready image using the `prod` stage in `Dockerfile`.
-- Tags and pushes the final image to Docker Hub with both `latest` and short SHA tags for traceability.
-
-> [!NOTE]
->  For more information about  `docker/build-push-action`, refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
----
-
-### Step 3: Run the workflow
-
-After you've added your workflow file, it's time to trigger and observe the CI/CD process in action.
-
-1. Commit and push your workflow file
-
-   Select "Commit changes…" in the GitHub editor.
-
-   - This push will automatically trigger the GitHub Actions pipeline.
-
-2. Monitor the workflow execution
-
-   1. Go to the Actions tab in your GitHub repository.
-   2. Click into the workflow run to follow each step: **build**, **test**, and (if successful) **push**.
-
-3. Verify the Docker image on Docker Hub
-
-   - After a successful workflow run, visit your [Docker Hub repositories](https://hub.docker.com/repositories).
-   - You should see a new image under your repository with:
-      - Repository name: `${your-repository-name}`
-      - Tags include:
-         - `latest` – represents the most recent successful build; ideal for quick testing or deployment.
-         - `<short-sha>` – a unique identifier based on the commit hash, useful for version tracking, rollbacks, and traceability.
-
-> [!TIP] Protect your main branch
-> To maintain code quality and prevent accidental direct pushes, enable branch protection rules:
->  - Navigate to your **GitHub repo → Settings → Branches**.
->  - Under Branch protection rules, click **Add rule**.
->  - Specify `main` as the branch name.
->  - Enable options like:
->     - *Require a pull request before merging*.
->     - *Require status checks to pass before merging*.
->
->  This ensures that only tested and reviewed code is merged into `main` branch.
----
-
-## Summary
-
-In this section, you set up a complete CI/CD pipeline for your containerized React.js application using GitHub Actions.
-
-Here's what you accomplished:
-
-- Created a new GitHub repository specifically for your project.
-- Generated a secure Docker Hub access token and added it to GitHub as a secret.
-- Defined a GitHub Actions workflow to:
-   - Build your application inside a Docker container.
-   - Run tests in a consistent, containerized environment.
-   - Push a production-ready image to Docker Hub if tests pass.
-- Triggered and verified the workflow execution through GitHub Actions.
-- Confirmed that your image was successfully published to Docker Hub.
-
-With this setup, your React.js application is now ready for automated testing and deployment across environments — increasing confidence, consistency, and team productivity.
-
----
-
-## Related resources
-
-Deepen your understanding of automation and best practices for containerized apps:
-
-- [Introduction to GitHub Actions](/guides/gha.md) – Learn how GitHub Actions automate your workflows  
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) – Set up container builds with GitHub Actions  
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) – Full reference for writing GitHub workflows  
-- [Compose file reference](/compose/compose-file/) – Full configuration reference for `compose.yaml`  
-- [Best practices for writing Dockerfiles](/develop/develop-images/dockerfile_best-practices/) – Optimize your image for performance and security  
-
----
-
-## Next steps
-
-Next, learn how you can locally test and debug your React.js workloads on Kubernetes before deploying. This helps you ensure your application behaves as expected in a production-like environment, reducing surprises during deployment.
diff --git a/content/guides/reactjs/containerize.md b/content/guides/reactjs/containerize.md
deleted file mode 100644
index f1d4f6673d50..000000000000
--- a/content/guides/reactjs/containerize.md
+++ /dev/null
@@ -1,473 +0,0 @@
----
-title: Containerize a React.js Application
-linkTitle: Containerize
-weight: 10
-keywords: react.js, node, image, initialize, build
-description: Learn how to containerize a React.js application with Docker by creating an optimized, production-ready image using best practices for performance, security, and scalability.
-
----
-
-
-## Prerequisites
-
-Before you begin, make sure the following tools are installed and available on your system:
-
-- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
-- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
-
-> **New to Docker?**  
-> Start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide to get familiar with key concepts like images, containers, and Dockerfiles.
-
----
-
-## Overview
-
-This guide walks you through the complete process of containerizing a React.js application with Docker. You’ll learn how to create a production-ready Docker image using best practices that improve performance, security, scalability, and deployment efficiency.
-
-By the end of this guide, you will:
-
-- Containerize a React.js application using Docker.
-- Create and optimize a Dockerfile for production builds. 
-- Use multi-stage builds to minimize image size.
-- Serve the application efficiently with a custom NGINX configuration.
-- Follow best practices for building secure and maintainable Docker images. 
-
----
-
-## Get the sample application
-
-Clone the sample application to use with this guide. Open a terminal, change
-directory to a directory that you want to work in, and run the following command
-to clone the git repository:
-
-```console
-$ git clone https://github.com/kristiyan-velkov/docker-reactjs-sample
-```
----
-
-## Generate a Dockerfile
-
-Docker provides an interactive CLI tool called `docker init` that helps scaffold the necessary configuration files for containerizing your application. This includes generating a `Dockerfile`, `.dockerignore`, `compose.yaml`, and `README.Docker.md`.
-
-To begin, navigate to the root of your project directory:
-
-```console
-$ cd docker-reactjs-sample
-```
-
-Then run the following command:
-
-```console
-$ docker init
-```
-You’ll see output similar to:
-
-```text
-Welcome to the Docker Init CLI!
-
-This utility will walk you through creating the following files with sensible defaults for your project:
-  - .dockerignore
-  - Dockerfile
-  - compose.yaml
-  - README.Docker.md
-
-Let's get started!
-```
-
-The CLI will prompt you with a few questions about your app setup.
-For consistency, please use the same responses shown in the example below when prompted:
-| Question                                                   | Answer          |
-|------------------------------------------------------------|-----------------|
-| What application platform does your project use?           | Node            |
-| What version of Node do you want to use?                   | 22.14.0-alpine  |
-| Which package manager do you want to use?                  | npm             |
-| Do you want to run "npm run build" before starting server? | yes             |
-| What directory is your build output to?                    | dist            |
-| What command do you want to use to start the app?          | npm run dev     |
-| What port does your server listen on?                      | 8080            |
-
-After completion, your project directory will contain the following new files:
-
-```text
-├── docker-reactjs-sample/
-│ ├── Dockerfile
-│ ├── .dockerignore
-│ ├── compose.yaml
-│ └── README.Docker.md
-```
-
----
-
-## Build the Docker image
-
-The default Dockerfile generated by `docker init` serves as a solid starting point for general Node.js applications. However, React.js is a front-end library that compiles into static assets, so we need to tailor the Dockerfile to optimize for how React applications are built and served in a production environment.
-
-### Step 1: Review the generated files
-
-In this step, you’ll improve the Dockerfile and configuration files by following best practices:
-
-- Use multi-stage builds to keep the final image clean and small  
-- Serve the app using NGINX, a fast and secure web server  
-- Improve performance and security by only including what’s needed  
-
-These updates help ensure your app is easy to deploy, fast to load, and production-ready.
-
-> [!NOTE]
-> A `Dockerfile` is a plain text file that contains step-by-step instructions to build a Docker image. It automates packaging your application along with its dependencies and runtime environment.  
-> For full details, see the [Dockerfile reference](/reference/dockerfile/).
-
-
-### Step 2: Configure the Dockerfile file 
-
-Copy and replace the contents of your existing `Dockerfile` with the configuration below:
-
-```dockerfile
-# =========================================
-# Stage 1: Build the React.js Application
-# =========================================
-ARG NODE_VERSION=22.14.0-alpine
-ARG NGINX_VERSION=alpine3.21
-
-# Use a lightweight Node.js image for building (customizable via ARG)
-FROM node:${NODE_VERSION} AS builder
-
-# Set the working directory inside the container
-WORKDIR /app
-
-# Copy package-related files first to leverage Docker's caching mechanism
-COPY --link package.json package-lock.json ./
-
-# Install project dependencies using npm ci (ensures a clean, reproducible install)
-RUN --mount=type=cache,target=/root/.npm npm ci
-
-# Copy the rest of the application source code into the container
-COPY --link . .
-
-# Build the React.js application (outputs to /app/dist)
-RUN npm run build
-
-# =========================================
-# Stage 2: Prepare Nginx to Serve Static Files
-# =========================================
-
-FROM nginxinc/nginx-unprivileged:${NGINX_VERSION} AS runner
-
-# Use a built-in non-root user for security best practices
-USER nginx
-
-# Copy custom Nginx config
-COPY --link nginx.conf /etc/nginx/nginx.conf
-
-# Copy the static build output from the build stage to Nginx's default HTML serving directory
-COPY --link --from=builder /app/dist /usr/share/nginx/html
-
-# Expose port 8080 to allow HTTP traffic
-# Note: The default NGINX container now listens on port 8080 instead of 80 
-EXPOSE 8080
-
-# Start Nginx directly with custom config
-ENTRYPOINT ["nginx", "-c", "/etc/nginx/nginx.conf"]
-CMD ["-g", "daemon off;"]
-```
-
-### Step 3: Configure the .dockerignore file
-
-The `.dockerignore` file tells Docker which files and folders to exclude when building the image.
-
-
-> [!NOTE]
->This helps:
->- Reduce image size  
->- Speed up the build process  
->- Prevent sensitive or unnecessary files (like `.env`, `.git`, or `node_modules`) from being added to the final image.
->
-> To learn more, visit the [.dockerignore reference](/reference/dockerfile.md#dockerignore-file).
-
-Copy and replace the contents of your existing `.dockerignore` with the configuration below:
-
-```dockerignore
-# Ignore dependencies and build output
-node_modules/
-dist/
-out/
-.tmp/
-.cache/
-
-# Ignore Vite, Webpack, and React-specific build artifacts
-.vite/
-.vitepress/
-.eslintcache
-.npm/
-coverage/
-jest/
-cypress/
-cypress/screenshots/
-cypress/videos/
-reports/
-
-# Ignore environment and config files (sensitive data)
-*.env*
-*.log
-
-# Ignore TypeScript build artifacts (if using TypeScript)
-*.tsbuildinfo
-
-# Ignore lockfiles (optional if using Docker for package installation)
-npm-debug.log*
-yarn-debug.log*
-yarn-error.log*
-pnpm-debug.log*
-
-# Ignore local development files
-.git/
-.gitignore
-.vscode/
-.idea/
-*.swp
-.DS_Store
-Thumbs.db
-
-# Ignore Docker-related files (to avoid copying unnecessary configs)
-Dockerfile
-.dockerignore
-docker-compose.yml
-docker-compose.override.yml
-
-# Ignore build-specific cache files
-*.lock
-
-```
-
-### Step 4: Create the `nginx.conf` file
-
-To serve your React.js application efficiently inside the container, you’ll configure NGINX with a custom setup. This configuration is optimized for performance, browser caching, gzip compression, and support for client-side routing.
-
-Create a file named `nginx.conf` in the root of your project directory, and add the following content:
-
-> [!NOTE]
-> To learn more about configuring NGINX, see the [official NGINX documentation](https://nginx.org/en/docs/).
-
-
-```nginx
-worker_processes auto;
-
-# Store PID in /tmp (always writable)
-pid /tmp/nginx.pid;
-
-events {
-    worker_connections 1024;
-}
-
-http {
-    include       /etc/nginx/mime.types;
-    default_type  application/octet-stream;
-
-    # Disable logging to avoid permission issues
-    access_log off;
-    error_log  /dev/stderr warn;
-
-    # Optimize static file serving
-    sendfile        on;
-    tcp_nopush      on;
-    tcp_nodelay     on;
-    keepalive_timeout  65;
-    keepalive_requests 1000;
-
-    # Gzip compression for optimized delivery
-    gzip on;
-    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
-    gzip_min_length 256;
-    gzip_vary on;
-
-    server {
-        listen       8080;
-        server_name  localhost;
-
-        # Root directory where React.js build files are placed
-        root /usr/share/nginx/html;
-        index index.html;
-
-        # Serve React.js static files with proper caching
-        location / {
-            try_files $uri /index.html;
-        }
-
-        # Serve static assets with long cache expiration
-        location ~* \.(?:ico|css|js|gif|jpe?g|png|woff2?|eot|ttf|svg|map)$ {
-            expires 1y;
-            access_log off;
-            add_header Cache-Control "public, immutable";
-        }
-
-        # Handle React.js client-side routing
-        location /static/ {
-            expires 1y;
-            add_header Cache-Control "public, immutable";
-        }
-    }
-}
-```
-
-### Step 5: Build the React.js application image
-
-With your custom configuration in place, you're now ready to build the Docker image for your React.js application.
-
-The updated setup includes:
-
-- Optimized browser caching and gzip compression  
-- Secure, non-root logging to avoid permission issues  
-- Support for React client-side routing by redirecting unmatched routes to `index.html`  
-
-After completing the previous steps, your project directory should now contain the following files:
-
-```text
-├── docker-reactjs-sample/
-│ ├── Dockerfile
-│ ├── .dockerignore
-│ ├── compose.yaml
-│ ├── nginx.conf
-│ └── README.Docker.md
-```
-
-Now that your Dockerfile is configured, you can build the Docker image for your React.js application.
-
-> [!NOTE]
-> The `docker build` command packages your application into an image using the instructions in the Dockerfile. It includes all necessary files from the current directory (called the [build context](/build/concepts/context/#what-is-a-build-context)).
-
-Run the following command from the root of your project:
-
-```console
-$ docker build --tag docker-reactjs-sample .
-```
-
-What this command does:
-- Uses the Dockerfile in the current directory (.)
-- Packages the application and its dependencies into a Docker image
-- Tags the image as docker-reactjs-sample so you can reference it later
-
-
-#### Step 6:  View local images
-
-After building your Docker image, you can check which images are available on your local machine using either the Docker CLI or [Docker Desktop](/manuals/desktop/use-desktop/images.md). Since you're already working in the terminal, let's use the Docker CLI.
-
-To list all locally available Docker images, run the following command:
-
-```console
-$ docker images
-```
-
-Example Output:
-
-```shell
-REPOSITORY                TAG               IMAGE ID       CREATED         SIZE
-docker-reactjs-sample     latest            f39b47a97156   14 seconds ago   75.8MB
-```
-
-This output provides key details about your images:
-
-- **Repository** – The name assigned to the image.
-- **Tag** – A version label that helps identify different builds (e.g., latest).
-- **Image ID** – A unique identifier for the image.
-- **Created** – The timestamp indicating when the image was built.
-- **Size** – The total disk space used by the image.
-
-If the build was successful, you should see `docker-reactjs-sample` image listed. 
-
----
-
-## Run the containerized application
-
-In the previous step, you created a Dockerfile for your React.js application and built a Docker image using the docker build command. Now it’s time to run that image in a container and verify that your application works as expected.
-
-
-Inside the `docker-reactjs-sample` directory, run the following command in a
-terminal.
-
-```console
-$ docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple React.js web application.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-### Run the application in the background
-
-You can run the application detached from the terminal by adding the `-d`
-option. Inside the `docker-reactjs-sample` directory, run the following command
-in a terminal.
-
-```console
-$ docker compose up --build -d
-```
-
-Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple web application preview.
-
-
-To confirm that the container is running, use `docker ps` command:
-
-```console
-$ docker ps
-```
-
-This will list all active containers along with their ports, names, and status. Look for a container exposing port 8080.
-
-Example Output:
-
-```shell
-CONTAINER ID   IMAGE                          COMMAND                  CREATED             STATUS             PORTS                    NAMES
-88bced6ade95   docker-reactjs-sample-server   "nginx -c /etc/nginx…"   About a minute ago  Up About a minute  0.0.0.0:8080->8080/tcp   docker-reactjs-sample-server-1
-```
-
-
-To stop the application, run:
-
-```console
-$ docker compose down
-```
-
-
-> [!NOTE]
-> For more information about Compose commands, see the [Compose CLI
-> reference](/reference/cli/docker/compose/_index.md).
-
----
-
-## Summary
-
-In this guide, you learned how to containerize, build, and run a React.js application using Docker. By following best practices, you created a secure, optimized, and production-ready setup.
-
-What you accomplished:
-- Initialized your project using `docker init` to scaffold essential Docker configuration files.
-- Replaced the default `Dockerfile` with a multi-stage build that compiles the React.js application and serves the static files using Nginx.
-- Replaced the default `.dockerignore` file to exclude unnecessary files and keep the image clean and efficient.
-- Built your Docker image using `docker build`.
-- Ran the container using `docker compose up`, both in the foreground and in detached mode.
-- Verified that the app was running by visiting [http://localhost:8080](http://localhost:8080).
-- Learned how to stop the containerized application using `docker compose down`.
-
-You now have a fully containerized React.js application, running in a Docker container, and ready for deployment across any environment with confidence and consistency.
-
----
-
-## Related resources
-
-Explore official references and best practices to sharpen your Docker workflow:
-
-- [Multi-stage builds](/build/building/multi-stage/) – Learn how to separate build and runtime stages.
-- [Best practices for writing Dockerfiles](/develop/develop-images/dockerfile_best-practices/) – Write efficient, maintainable, and secure Dockerfiles.  
-- [Build context in Docker](/build/concepts/context/) – Learn how context affects image builds.  
-- [`docker init` CLI reference](/reference/cli/docker/init/) – Scaffold Docker assets automatically.
-- [`docker build` CLI reference](/reference/cli/docker/build/) – Build Docker images from a Dockerfile.
-- [`docker images` CLI reference](/reference/cli/docker/images/) – Manage and inspect local Docker images.
-- [`docker compose up` CLI reference](/reference/cli/docker/compose/up/) – Start and run multi-container applications.
-- [`docker compose down` CLI reference](/reference/cli/docker/compose/down/) – Stop and remove containers, networks, and volumes.
-
----
-
-## Next steps
-
-With your React.js application now containerized, you're ready to move on to the next step.
-
-In the next section, you'll learn how to develop your application using Docker containers, enabling a consistent, isolated, and reproducible development environment across any machine.
-
diff --git a/content/guides/reactjs/deploy.md b/content/guides/reactjs/deploy.md
deleted file mode 100644
index c02301b8d015..000000000000
--- a/content/guides/reactjs/deploy.md
+++ /dev/null
@@ -1,194 +0,0 @@
----
-title: Test your React.js deployment
-linkTitle: Test your deployment
-weight: 60
-keywords: deploy, kubernetes, react, react.js
-description: Learn how to deploy locally to test and debug your Kubernetes deployment
-
----
-
-## Prerequisites
-
-Before you begin, make sure you’ve completed the following:
-- Complete all the previous sections of this guide, starting with [Containerize React.js application](containerize.md).
-- [Enable Kubernetes](/manuals/desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker Desktop.
-
-> **New to Kubernetes?**  
-> Visit the [Kubernetes basics tutorial](https://kubernetes.io/docs/tutorials/kubernetes-basics/) to get familiar with how clusters, pods, deployments, and services work.
-
----
-
-## Overview
-
-This section guides you through deploying your containerized React.js application locally using [Docker Desktop’s built-in Kubernetes](/desktop/kubernetes/). Running your app in a local Kubernetes cluster allows you to closely simulate a real production environment, enabling you to test, validate, and debug your workloads with confidence before promoting them to staging or production.
-
----
-
-## Create a Kubernetes YAML file
-
-Follow these steps to define your deployment configuration:
-
-1. In the root of your project, create a new file named: reactjs-sample-kubernetes.yaml
-
-2. Open the file in your IDE or preferred text editor.
-
-3. Add the following configuration, and be sure to replace `{DOCKER_USERNAME}` and `{DOCKERHUB_PROJECT_NAME}` with your actual Docker Hub username and repository name from the previous [Configure CI/CD for your React.js application](configure-ci-cd.md).
-
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: reactjs-sample
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: reactjs-sample
-  template:
-    metadata:
-      labels:
-        app: reactjs-sample
-    spec:
-      containers:
-        - name: reactjs-container
-          image: {DOCKER_USERNAME}/{DOCKERHUB_PROJECT_NAME}:latest
-          imagePullPolicy: Always
-          ports:
-            - containerPort: 8080
----
-apiVersion: v1
-kind: Service
-metadata:
-  name:  reactjs-sample-service
-  namespace: default
-spec:
-  type: NodePort
-  selector:
-    app:  reactjs-sample
-  ports:
-    - port: 8080
-      targetPort: 8080
-      nodePort: 30001
-```
-
-This manifest defines two key Kubernetes resources, separated by `---`:
-
-- Deployment
-  Deploys a single replica of your React.js application inside a pod. The pod uses the Docker image built and pushed by your GitHub Actions CI/CD workflow  
-  (refer to [Configure CI/CD for your React.js application](configure-ci-cd.md)).  
-  The container listens on port `8080`, which is typically used by [Nginx](https://nginx.org/en/docs/) to serve your production React app.
-
-- Service (NodePort) 
-  Exposes the deployed pod to your local machine.  
-  It forwards traffic from port `30001` on your host to port `8080` inside the container.  
-  This lets you access the application in your browser at [http://localhost:30001](http://localhost:30001).
-
-> [!NOTE]
-> To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
----
-
-## Deploy and check your application
-
-Follow these steps to deploy your containerized React.js app into a local Kubernetes cluster and verify that it’s running correctly.
-
-### Step 1. Apply the Kubernetes configuration
-
-In your terminal, navigate to the directory where your `reactjs-sample-kubernetes.yaml` file is located, then deploy the resources using:
-
-```console
-  $ kubectl apply -f reactjs-sample-kubernetes.yaml
-```
-
-If everything is configured properly, you’ll see confirmation that both the Deployment and the Service were created:
-
-```shell
-  deployment.apps/reactjs-sample created
-  service/reactjs-sample-service created
-```
-   
-This output means that both the Deployment and the Service were successfully created and are now running inside your local cluster.
-
-### Step 2. Check the Deployment status
-
-Run the following command to check the status of your deployment:
-   
-```console
-  $ kubectl get deployments
-```
-
-You should see an output similar to:
-
-```shell
-  NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
-  reactjs-sample       1/1     1            1           14s
-```
-
-This confirms that your pod is up and running with one replica available.
-
-### Step 3. Verify the Service exposure
-
-Check if the NodePort service is exposing your app to your local machine:
-
-```console
-$ kubectl get services
-```
-
-You should see something like:
-
-```shell
-NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
-reactjs-sample-service   NodePort    10.100.244.65    <none>        8080:30001/TCP   1m
-```
-
-This output confirms that your app is available via NodePort on port 30001.
-
-### Step 4. Access your app in the browser
-
-Open your browser and navigate to [http://localhost:30001](http://localhost:30001).
-
-You should see your production-ready React.js Sample application running — served by your local Kubernetes cluster.
-
-### Step 5. Clean up Kubernetes resources
-
-Once you're done testing, you can delete the deployment and service using:
-
-```console
-  $ kubectl delete -f reactjs-sample-kubernetes.yaml
-```
-
-Expected output:
-
-```shell
-  deployment.apps "reactjs-sample" deleted
-  service "reactjs-sample-service" deleted
-```
-
-This ensures your cluster stays clean and ready for the next deployment.
-   
----
-
-## Summary
-
-In this section, you learned how to deploy your React.js application to a local Kubernetes cluster using Docker Desktop. This setup allows you to test and debug your containerized app in a production-like environment before deploying it to the cloud.
-
-What you accomplished:
-
-- Created a Kubernetes Deployment and NodePort Service for your React.js app  
-- Used `kubectl apply` to deploy the application locally  
-- Verified the app was running and accessible at `http://localhost:30001`  
-- Cleaned up your Kubernetes resources after testing
-
----
-
-## Related resources
-
-Explore official references and best practices to sharpen your Kubernetes deployment workflow:
-
-- [Kubernetes documentation](https://kubernetes.io/docs/home/) – Learn about core concepts, workloads, services, and more.  
-- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md) – Use Docker Desktop’s built-in Kubernetes support for local testing and development.
-- [`kubectl` CLI reference](https://kubernetes.io/docs/reference/kubectl/) – Manage Kubernetes clusters from the command line.  
-- [Kubernetes Deployment resource](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) – Understand how to manage and scale applications using Deployments.  
-- [Kubernetes Service resource](https://kubernetes.io/docs/concepts/services-networking/service/) – Learn how to expose your application to internal and external traffic.
\ No newline at end of file
diff --git a/content/guides/reactjs/develop.md b/content/guides/reactjs/develop.md
deleted file mode 100644
index caf711938e5e..000000000000
--- a/content/guides/reactjs/develop.md
+++ /dev/null
@@ -1,206 +0,0 @@
----
-title: Use containers for React.js development
-linkTitle: Develop your app
-weight: 30
-keywords: react.js, development, node
-description: Learn how to develop your React.js application locally using containers.
-
----
-
-## Prerequisites
-
-Complete [Containerize React.js application](containerize.md).
-
----
-
-## Overview
-
-In this section, you'll learn how to set up both production and development environments for your containerized React.js application using Docker Compose. This setup allows you to serve a static production build via Nginx and to develop efficiently inside containers using a live-reloading dev server with Compose Watch.
-
-You’ll learn how to:
-- Configure separate containers for production and development
-- Enable automatic file syncing using Compose Watch in development
-- Debug and live-preview your changes in real-time without manual rebuilds
-
----
-
-## Automatically update services (Development Mode)
-
-Use Compose Watch to automatically sync source file changes into your containerized development environment. This provides a seamless, efficient development experience without needing to restart or rebuild containers manually.
-
-## Step 1: Create a development Dockerfile
-
-Create a file named `Dockerfile.dev` in your project root with the following content:
-
-```dockerfile
-# =========================================
-# Stage 1: Develop the React.js Application
-# =========================================
-ARG NODE_VERSION=22.14.0-alpine
-
-# Use a lightweight Node.js image for development
-FROM node:${NODE_VERSION} AS dev
-
-# Set the working directory inside the container
-WORKDIR /app
-
-# Copy package-related files first to leverage Docker's caching mechanism
-COPY --link package.json package-lock.json ./
-
-# Install project dependencies
-RUN --mount=type=cache,target=/root/.npm npm install
-
-# Copy the rest of the application source code into the container
-COPY --link . .
-
-# Expose the port used by the Vite development server
-EXPOSE 5173
-
-# Use a default command, can be overridden in Docker compose.yml file
-CMD ["npm", "run", "dev"]
-```
-
-This file sets up a lightweight development environment for your React app using the dev server.
-
-
-### Step 2: Update your `compose.yaml` file
-
-Open your `compose.yaml` file and define two services: one for production (`react-prod`) and one for development (`react-dev`).
-
-Here’s an example configuration for a React.js application:
-
-```yaml
-services:
-  react-prod:
-    build:
-      context: .
-      dockerfile: Dockerfile
-    image: docker-reactjs-sample
-    ports:
-      - "8080:8080"
-
-  react-dev:
-    build:
-      context: .
-      dockerfile: Dockerfile.dev
-    ports:
-      - "5173:5173"
-    develop:
-      watch:
-        - action: sync
-          path: .
-          target: /app
-
-```
-- The `react-prod` service builds and serves your static production app using Nginx.
-- The `react-dev` service runs your React development server with live reload and hot module replacement.
-- `watch` triggers file sync with Compose Watch.
-
-> [!NOTE]
-> For more details, see the official guide: [Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
-
-### Step 3: Update vite.config.ts to ensure it works properly inside Docker
-
-To make Vite’s development server work reliably inside Docker, you need to update your vite.config.ts with the correct settings.
-
-Open the `vite.config.ts` file in your project root and update it as follows:
-
-```ts
-/// <reference types="vitest" />
-
-import { defineConfig } from "vite";
-import react from "@vitejs/plugin-react";
-
-export default defineConfig({
-  base: "/",
-  plugins: [react()],
-  server: {
-    host: true,
-    port: 5173,
-    strictPort: true,
-  },
-});
-```
-
-> [!NOTE]
-> The `server` options in `vite.config.ts` are essential for running Vite inside Docker:
-> - `host: true` allows the dev server to be accessible from outside the container.
-> - `port: 5173` sets a consistent development port (must match the one exposed in Docker).
-> - `strictPort: true` ensures Vite fails clearly if the port is unavailable, rather than switching silently.
-> 
-> For full details, refer to the [Vite server configuration docs](https://vitejs.dev/config/server-options.html).
-
-
-After completing the previous steps, your project directory should now contain the following files:
-
-```text
-├── docker-reactjs-sample/
-│ ├── Dockerfile
-│ ├── Dockerfile.dev
-│ ├── .dockerignore
-│ ├── compose.yaml
-│ ├── nginx.conf
-│ └── README.Docker.md
-```
-
-### Step 4: Start Compose Watch
-
-Run the following command from your project root to start your container in watch mode:
-
-```console
-$ docker compose watch react-dev
-```
-
-### Step 5: Test Compose Watch with React
-
-To verify that Compose Watch is working correctly:
-
-1. Open the `src/App.tsx` file in your text editor.
-
-2. Locate the following line:
-
-    ```html
-    <h1>Vite + React</h1>
-    ```
-
-3. Change it to:
-
-    ```html
-    <h1>Hello from Docker Compose Watch</h1>
-    ```
-
-4. Save the file.
-
-5. Open your browser at [http://localhost:5173](http://localhost:5173).
-
-You should see the updated text appear instantly, without needing to rebuild the container manually. This confirms that file watching and automatic synchronization are working as expected.
-
----
-
-## Summary
-
-In this section, you set up a complete development and production workflow for your React.js application using Docker and Docker Compose.
-
-Here's what you achieved:
-- Created a `Dockerfile.dev` to streamline local development with hot reloading  
-- Defined separate `react-dev` and `react-prod` services in your `compose.yaml` file  
-- Enabled real-time file syncing using Compose Watch for a smoother development experience  
-- Verified that live updates work seamlessly by modifying and previewing a component
-
-With this setup, you're now equipped to build, run, and iterate on your React.js app entirely within containers—efficiently and consistently across environments.
-
----
-
-## Related resources
-
-Deepen your knowledge and improve your containerized development workflow with these guides:
-
-- [Using Compose Watch](/manuals/compose/how-tos/file-watch.md) – Automatically sync source changes during development  
-- [Multi-stage builds](/manuals/build/building/multi-stage.md) – Create efficient, production-ready Docker images  
-- [Dockerfile best practices](/build/building/best-practices/) – Write clean, secure, and optimized Dockerfiles.
-- [Compose file reference](/compose/compose-file/) – Learn the full syntax and options available for configuring services in `compose.yaml`.
-- [Docker volumes](/storage/volumes/) – Persist and manage data between container runs  
-
-## Next steps
-
-In the next section, you'll learn how to run unit tests for your React.js application inside Docker containers. This ensures consistent testing across all environments and removes dependencies on local machine setup.
diff --git a/content/guides/reactjs/run-tests.md b/content/guides/reactjs/run-tests.md
deleted file mode 100644
index dea7d484c664..000000000000
--- a/content/guides/reactjs/run-tests.md
+++ /dev/null
@@ -1,180 +0,0 @@
----
-title: Run React.js tests in a container
-linkTitle: Run your tests
-weight: 40
-keywords: react.js, react, test, vitest
-description: Learn how to run your React.js tests in a container.
-
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize React.js application](containerize.md).
-
-## Overview
-
-Testing is a critical part of the development process. In this section, you'll learn how to:
-
-- Run unit tests using Vitest inside a Docker container.
-- Use Docker Compose to run tests in an isolated, reproducible environment.
-
-You’ll use [Vitest](https://vitest.dev) — a blazing fast test runner designed for Vite — along with [Testing Library](https://testing-library.com/) for assertions.
-
----
-
-## Run tests during development
-
-`docker-reactjs-sample` application includes a sample test file at location:
-
-```console
-$ src/App.test.tsx
-```
-
-This file uses Vitest and React Testing Library to verify the behavior of `App` component.
-
-### Step 1: Install Vitest and React Testing Library
-
-If you haven’t already added the necessary testing tools, install them by running:
-
-```console
-$ npm install --save-dev vitest @testing-library/react @testing-library/jest-dom jsdom
-```
-
-Then, update the scripts section of your `package.json` file to include the following:
-
-```json
-"scripts": {
-  "test": "vitest run"
-}
-```
-
----
-
-### Step 2: Configure Vitest
-
-Update `vitest.config.ts` file in your project root with the following configuration:
-
-```ts {hl_lines="14-18",linenos=true}
-/// <reference types="vitest" />
-
-import { defineConfig } from "vite";
-import react from "@vitejs/plugin-react";
-
-export default defineConfig({
-  base: "/",
-  plugins: [react()],
-  server: {
-    host: true,
-    port: 5173,
-    strictPort: true,
-  },
-  test: {
-    environment: "jsdom",
-    setupFiles: "./src/setupTests.ts",
-    globals: true,
-  },
-});
-```
-
-> [!NOTE]
-> The `test` options in `vitest.config.ts` are essential for reliable testing inside Docker:
-> - `environment: "jsdom"` simulates a browser-like environment for rendering and DOM interactions.  
-> - `setupFiles: "./src/setupTests.ts"` loads global configuration or mocks before each test file (optional but recommended).  
-> - `globals: true` enables global test functions like `describe`, `it`, and `expect` without importing them.
->
-> For more details, see the official [Vitest configuration docs](https://vitest.dev/config/).
-
-### Step 3: Update compose.yaml
-
-Add a new service named `react-test` to your `compose.yaml` file. This service allows you to run your test suite in an isolated containerized environment.
-
-```yaml {hl_lines="22-26",linenos=true}
-services:
-  react-dev:
-    build:
-      context: .
-      dockerfile: Dockerfile.dev
-    ports:
-      - "5173:5173"
-    develop:
-      watch:
-        - action: sync
-          path: .
-          target: /app
-
-  react-prod:
-    build:
-      context: .
-      dockerfile: Dockerfile
-    image: docker-reactjs-sample
-    ports:
-      - "8080:8080"
-
-  react-test:
-    build:
-      context: .
-      dockerfile: Dockerfile.dev
-    command: ["npm", "run", "test"]
-
-```
-
-The react-test service reuses the same `Dockerfile.dev` used for [development](develop.md) and overrides the default command to run tests with `npm run test`. This setup ensures a consistent test environment that matches your local development configuration.
-
-
-After completing the previous steps, your project directory should contain the following files:
-
-```text
-├── docker-reactjs-sample/
-│ ├── Dockerfile
-│ ├── Dockerfile.dev
-│ ├── .dockerignore
-│ ├── compose.yaml
-│ ├── nginx.conf
-│ └── README.Docker.md
-```
-
-### Step 4: Run the tests
-
-To execute your test suite inside the container, run the following command from your project root:
-
-```console
-$ docker compose run --rm react-test
-```
-
-This command will:
-- Start the `react-test` service defined in your `compose.yaml` file.
-- Execute the `npm run test` script using the same environment as development.
-- Automatically remove the container after the tests complete [`docker compose run --rm`](/engine/reference/commandline/compose_run) command.
-
-> [!NOTE]
-> For more information about Compose commands, see the [Compose CLI
-> reference](/reference/cli/docker/compose/_index.md).
-
----
-
-## Summary
-
-In this section, you learned how to run unit tests for your React.js application inside a Docker container using Vitest and Docker Compose.
-
-What you accomplished:
-- Installed and configured Vitest and React Testing Library for testing React components.
-- Created a `react-test` service in `compose.yaml` to isolate test execution.
-- Reused the development `Dockerfile.dev` to ensure consistency between dev and test environments.
-- Ran tests inside the container using `docker compose run --rm react-test`.
-- Ensured reliable, repeatable testing across environments without relying on local machine setup.
-
----
-
-## Related resources
-
-Explore official references and best practices to sharpen your Docker testing workflow:
-
-- [Dockerfile reference](/reference/dockerfile/) – Understand all Dockerfile instructions and syntax.
-- [Best practices for writing Dockerfiles](/develop/develop-images/dockerfile_best-practices/) – Write efficient, maintainable, and secure Dockerfiles.
-- [Compose file reference](/compose/compose-file/) – Learn the full syntax and options available for configuring services in `compose.yaml`.  
-- [`docker compose run` CLI reference](/reference/cli/docker/compose/run/) – Run one-off commands in a service container.
----
-
-## Next steps
-
-Next, you’ll learn how to set up a CI/CD pipeline using GitHub Actions to automatically build and test your React.js application in a containerized environment. This ensures your code is validated on every push or pull request, maintaining consistency and reliability across your development workflow.
diff --git a/content/guides/ros2.md b/content/guides/ros2.md
new file mode 100644
index 000000000000..2717f87995eb
--- /dev/null
+++ b/content/guides/ros2.md
@@ -0,0 +1,462 @@
+---
+title: Introduction to ROS 2 Development with Docker
+linkTitle: ROS 2
+description: Learn how to containerize and develop ROS 2 applications using Docker.
+keywords: ros2, robotics, devcontainers, python, cpp, Dockerfile, rviz
+summary: |
+  This guide details how to containerize ROS 2 applications using Docker.
+aliases:
+  - /guides/ros2/develop/
+  - /guides/ros2/run-ros2/
+  - /guides/ros2/turtlesim-example/
+params:
+  tags: [deployment]
+  time: 30 minutes
+  image: /images/guides/ros2.jpg
+  featured: false
+---
+
+
+> **Acknowledgment**
+>
+> This guide is a community contribution. Docker would like to thank
+> [Shakirth Anisha](https://www.linkedin.com/in/shakirth-anisha/) for her contribution
+> to this guide.
+
+[ROS 2](https://www.ros.org/) is a set of software libraries and tools for building robot applications. It uses Data Distribution Service (DDS) for real-time, secure communication between distributed nodes, making it ideal for robotics and autonomous systems.
+
+---
+
+## What will you learn?
+
+In this guide, you'll learn how to:
+
+- Use official ROS 2 base images from Docker Hub
+- Run ROS 2 in an Ubuntu container
+- Install ROS 2 packages and dependencies
+- Set up a development container for local development
+- Run a complete end-to-end example with Turtlesim
+
+## Prerequisites
+
+Before you begin, make sure you're familiar with the following:
+
+- [Docker Desktop](https://docs.docker.com/desktop/): You must have Docker Desktop installed and running.
+- [Docker concepts](/get-started/docker-concepts/the-basics/what-is-a-container.md): You must understand core Docker concepts, such as images and containers.
+- [ROS 2 concepts](https://www.ros.org): Basic understanding of concepts like nodes, packages, topics, and services.
+
+## What's next?
+
+Start by setting up your ROS 2 development environment using Docker and dev containers.
+
+## Run ROS 2 in a container
+
+### Overview
+
+In this section, you will run ROS 2 in an isolated Docker container using official ROS 2 images, verify that ROS 2 is working, and install additional ROS 2 packages for development and testing.
+
+---
+
+### Run ROS 2 in a container
+
+The fastest way to get started with ROS 2 is to use the [official Docker image](https://hub.docker.com/_/ros/). To pull an image, start a container, and open an interactive bash shell:
+
+1. Pull and run the official ROS 2 Docker image:
+
+   ```console
+   $ docker run -it ros:humble
+   ```
+
+   This guide uses the Humble distribution. You can replace `humble` with another supported distribution such as `rolling`, `jazzy`, or `iron`.
+
+   > [!NOTE]
+   >
+   > This environment is temporary and does not maintain persistence.
+   > Any files you create or packages you install will be deleted once the container is stopped or removed.
+
+2. Verify ROS 2 is working:
+
+   ```console
+   $ echo $ROS_DISTRO
+   ```
+
+   You should see output similar to:
+
+   ```text
+   humble
+   ```
+
+### Install ROS 2 packages
+
+The official ROS 2 images include core packages. To install additional packages, use the `apt` package manager:
+
+1. Update the package manager:
+
+   ```console
+   $ sudo apt update
+   ```
+
+2. Install the desired package:
+
+   ```console
+   $ sudo apt install $PACKAGE_NAME
+   ```
+
+Replace `$PACKAGE_NAME` with any package you want to install.
+
+Some commonly used packages include:
+
+- `ros-humble-turtlesim` - Visualization and simulation tool
+- `ros-humble-rviz2` - 3D visualization tool
+- `ros-humble-rqt` - Qt-based ROS graphical tools
+- `ros-humble-demo-nodes-cpp` - C++ demo nodes
+- `ros-humble-demo-nodes-py` - Python demo nodes
+- `ros-humble-colcon-common-extensions` - Build system extensions
+
+### Summary
+
+In this section, you pulled an official ROS 2 Docker image, launched an interactive session, and extended the container's capabilities by installing additional ROS 2 packages using apt.
+
+### Next steps
+
+In the next section, you will configure a persistent workspace to ensure your code and modifications are saved across sessions.
+
+## Build and develop a ROS 2 workspace
+
+### Overview
+
+In this section, you will set up a ROS 2 workspace using Docker and development containers, review the workspace layout, open the workspace in Visual Studio Code, and edit and build ROS 2 projects inside the container.
+
+---
+
+### Get the sample ROS 2 workspace
+
+A consistent workspace simplifies managing ROS 2 projects and build artifacts across different distributions.
+
+1. Open a terminal and clone the sample workspace repository:
+
+   ```console
+   $ git clone https://github.com/shakirth-anisha/docker-ros2-workspace.git
+   $ cd docker-ros2-workspace
+
+   ```
+
+   Moving forward, Linux users can use the `ws_linux` folder, and macOS users can use `ws_mac`.
+
+2. Verify the workspace structure:
+
+   ```text
+   ws_linux/
+   ├── compose.yml
+   ├── Dockerfile
+   └── src/
+       ├── package1/
+       └── package2/
+
+   ws_mac/
+   ├── compose.yml
+   ├── Dockerfile
+   └── src/
+       ├── package1/
+       └── package2/
+
+   ```
+
+3. Explore the workspace layout
+
+- `compose.yml` : Defines how Docker Compose builds and runs the ROS 2 container, including mounts, environment variables, and networking settings.
+- `Dockerfile` : Builds the ROS 2 development image. It uses an official ROS 2 base image, creates a non-root development user, and installs required system and ROS 2 dependencies.
+- `src` : Contains all ROS 2 packages. This directory is mounted into the container as the active workspace.
+
+### Open and build the container
+
+1. Execute the following commands to build and start the container:
+
+   For Linux:
+
+   ```console
+   $ cd ws_linux
+   $ docker compose up -d
+   $ docker compose exec ros2 /bin/bash
+   ```
+
+   For macOS:
+
+   ```console
+   $ cd ws_mac
+   $ docker compose up -d
+   $ docker compose exec ros2 /bin/bash
+   ```
+
+   This command builds the Docker image defined in your `Dockerfile` and starts the container in the background.
+
+   > [!NOTE]
+   >
+   > Building the image may take several minutes during the first run
+   > as the CLI pulls the base ROS 2 image and installs required dependencies.
+   > Subsequent starts will be significantly faster.
+
+2. Once the container is running, execute commands inside it using `exec`:
+
+   ```console
+   $ docker compose exec ros2 /bin/bash
+   ```
+
+3. Inside the container terminal, verify the environment:
+
+```console
+$ echo $ROS_VERSION
+$ which colcon
+```
+
+All commands should execute successfully inside the container.
+
+### Switch ROS 2 distributions
+
+Update the base image in your `Dockerfile`, changing from `humble` to another distribution like `rolling`, `jazzy`, or `iron`.
+
+### Summary
+
+In this section, you learned how to create a structured workspace, write a Dockerfile with development tools, and configure a Docker Compose setup. Your ROS 2 development environment is now ready with a consistent, reproducible setup across any machine.
+
+### Next steps
+
+In the next section, you'll run a complete end-to-end example with Turtlesim.
+
+## Run a complete example with Turtlesim
+
+### Overview
+
+Turtlesim is a simple simulation tool that demonstrates fundamental ROS 2 concepts such as nodes, topics, and services. In this section, you'll run a complete example with Turtlesim, control the turtle, monitor topics, and visualize the system with rqt.
+
+---
+
+### Configure display forwarding
+
+#### Linux
+
+Allow Docker access to your X server:
+
+```console
+$ xhost +local:docker
+```
+
+#### macOS
+
+On macOS, use XQuartz to provide X11 support. Install XQuartz using Homebrew:
+
+1. Install XQuartz using Homebrew:
+
+   ```console
+   $ brew install --cask xquartz
+   ```
+
+2. Open XQuartz from Applications, then navigate to `Preferences > Security` and enable `Allow connections from network clients`. Restart your computer to ensure the changes take effect.
+
+3. After rebooting, open a terminal and allow local connections:
+
+   ```console
+   $ defaults write org.xquartz.X11 nolisten_tcp -bool false
+   $ xhost +localhost
+   $ xhost + 127.0.0.1
+   ```
+
+### Start the container
+
+Start the container using the same Docker Compose setup from the workspace section.
+
+For Linux:
+
+```console
+$ cd ws_linux
+$ docker compose up -d
+$ docker compose exec ros2 /bin/bash
+```
+
+For macOS:
+
+```console
+$ cd ws_mac
+$ docker compose up -d
+$ docker compose exec ros2 /bin/bash
+```
+
+### Install and run Turtlesim
+
+Inside the container, install the Turtlesim package:
+
+1. Update the package manager:
+
+   ```console
+   $ sudo apt update
+   ```
+
+2. Install the Turtlesim package:
+
+   ```console
+   $ sudo apt install -y ros-humble-turtlesim
+   ```
+
+3. Run the Turtlesim node:
+
+   ```console
+   $ ros2 run turtlesim turtlesim_node
+   ```
+
+A window should appear on your desktop showing a turtle in a grid.
+
+### Control the turtle
+
+1. Open a new terminal and connect to the same container, then start the keyboard teleop node:
+
+   ```console
+   $ ros2 run turtlesim turtle_teleop_key
+   ```
+
+   This node allows you to control the turtle using your keyboard. Use the arrow keys to move the turtle forward, backward, left, and right. Press `Ctrl+C` to stop the teleop node.
+
+2. Move the turtle around the window. You should see it draw a path as it moves.
+
+### Monitor topics
+
+1. Open another terminal and connect to the same container, then list all active topics:
+
+   ```console
+   $ ros2 topic list
+   ```
+
+   You should see output similar to the following:
+
+   ```text
+   /parameter_events
+   /rosout
+   /turtle1/cmd_vel
+   /turtle1/color_sensor
+   /turtle1/pose
+   ```
+
+2. Get information about a specific topic:
+
+   ```console
+   $ ros2 topic info /turtle1/pose
+   ```
+
+   You'll see the topic type and which nodes publish and subscribe to it.
+
+### Visualize the system with rqt
+
+1. Open another terminal and connect to the same container, then update the package manager:
+
+   ```console
+   $ sudo apt update
+   ```
+
+2. Install rqt:
+
+   ```console
+   $ sudo apt install -y 'ros-humble-rqt*'
+   ```
+
+3. Start rqt:
+
+   ```console
+   $ ros2 run rqt_gui rqt_gui
+   ```
+
+An rqt window should appear. rqt provides several useful plugins for visualizing and monitoring ROS 2 systems.
+
+#### Node Graph
+
+You can explore the node graph by navigating to **Plugins > Introspection > Node Graph**. A new tab opens showing nodes and topics with connections illustrated as lines. This visualization demonstrates how the teleop node sends velocity commands to the Turtlesim node, and how the Turtlesim node publishes position data back through topics.
+
+#### Topic Monitor
+
+You can monitor active topics by navigating to **Plugins > Topics > Topic Monitor**. A new tab opens displaying all active topics and their current values. Select the eye icon next to `/turtle1/pose` to monitor it. As you move the turtle, watch the pose values update in real time, showing the position of the turtle and orientation changing based on your commands.
+
+#### Service Caller
+
+You can call services from rqt using **Plugins > Services > Service Caller**. Select a service such as `/turtle1/teleport_absolute`, enter values for the request fields, and select **Call** to send the request.
+
+#### Plots
+
+To plot topic data over time navigate to **Plugins > Visualization > Plot**. For example, in the Plot window, type `/turtle1/pose/x` in the Topic field and press Enter. Move the turtle and watch the X position displayed as a graph over time.
+
+### Call ROS 2 services
+
+Turtlesim provides services for actions such as repositioning the turtle and clearing the path.
+
+1. List available services:
+
+   ```console
+   $ ros2 service list
+   ```
+
+   You should see services such as `/turtle1/set_pen` (to change pen color and width), `/turtle1/teleport_absolute` (to move the turtle to a specific position), and `/turtle1/teleport_relative` (to move the turtle relative to its current position).
+
+2. Teleport the turtle to a new position:
+
+   ```console
+   $ ros2 service call /turtle1/teleport_absolute turtlesim/srv/TeleportAbsolute "
+   x: 1.0
+   y: 3.0
+   theta: 0.0
+   "
+   ```
+
+   The turtle should instantly move to the specified position (1.0, 3.0).
+
+### Create a simple publisher
+
+1. Create a Python script that publishes velocity commands to control the turtle programmatically. In a new terminal, create a file called `move_turtle.py`:
+
+   ```python
+   import rclpy
+   from geometry_msgs.msg import Twist
+   import time
+
+   def main():
+       rclpy.init()
+       node = rclpy.create_node('turtle_mover')
+       publisher = node.create_publisher(Twist, 'turtle1/cmd_vel', 10)
+
+       # Create a twist message
+       msg = Twist()
+       msg.linear.x = 2.0  # Move forward at 2 m/s
+       msg.angular.z = 1.0  # Rotate at 1 rad/s
+
+       # Publish the message
+       for i in range(50):
+           publisher.publish(msg)
+           time.sleep(0.1)
+
+       # Stop the turtle
+       msg.linear.x = 0.0
+       msg.angular.z = 0.0
+       publisher.publish(msg)
+
+       node.destroy_node()
+       rclpy.shutdown()
+
+   if __name__ == '__main__':
+       main()
+   ```
+
+2. Run the script:
+
+   ```console
+   $ python3 move_turtle.py
+   ```
+
+   The turtle should move in a circular motion for 5 seconds and then stop.
+
+### Summary
+
+In this section, you configured display forwarding, used the Turtlesim nodes, inspected nodes and topics, and visualized the system using rqt. Finally, you interacted with ROS 2 services and created a simple publisher to move the turtle programmatically.
+
+These fundamental concepts apply directly to real-world robotics applications with actual sensors and actuators.
+
+### Related resources
+
+- [ROS 2 Turtlesim tutorials](https://docs.ros.org/en/humble/Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics.html)
+- [ROS 2 Concepts](https://docs.ros.org/en/humble/Concepts.html)
+- [Geometry Messages](https://github.com/ros2/geometry2/tree/humble/geometry_msgs)
diff --git a/content/guides/ruby.md b/content/guides/ruby.md
new file mode 100644
index 000000000000..dd0be6677306
--- /dev/null
+++ b/content/guides/ruby.md
@@ -0,0 +1,590 @@
+---
+title: Ruby on Rails language-specific guide
+linkTitle: Ruby
+description: Containerize Ruby on Rails apps using Docker
+keywords: Docker, getting started, ruby, language
+summary: |
+  This guide explains how to containerize Ruby on Rails applications using
+  Docker.
+aliases:
+  - /language/ruby/
+  - /guides/language/ruby/
+  - /language/ruby/build-images/
+  - /language/ruby/run-containers/
+  - /language/ruby/containerize/
+  - /language/ruby/configure-ci-cd/
+  - /guides/language/ruby/configure-ci-cd/
+  - /language/ruby/develop/
+  - /language/ruby/deploy/
+  - /guides/ruby/configure-github-actions/
+  - /guides/ruby/containerize/
+  - /guides/ruby/deploy/
+  - /guides/ruby/develop/
+params:
+  tags: [languages]
+  time: 20 minutes
+---
+
+The Ruby language-specific guide teaches you how to containerize a Ruby on Rails application using Docker. In this guide, you’ll learn how to:
+
+- Containerize and run a Ruby on Rails application
+- Set up a local environment to develop a Ruby on Rails application using containers
+
+Start by containerizing an existing Ruby on Rails application.
+
+## Containerize a Ruby on Rails application
+
+### Prerequisites
+
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
+- You have a [Git client](https://git-scm.com/downloads). The examples in this section show the Git CLI, but you can use any client.
+
+### Overview
+
+This section walks you through containerizing and running a [Ruby on Rails](https://rubyonrails.org/) application.
+
+Starting from Rails 7.1 [Docker is supported out of the box](https://guides.rubyonrails.org/7_1_release_notes.html#generate-dockerfiles-for-new-rails-applications). This means that you will get a `Dockerfile`, `.dockerignore` and `bin/docker-entrypoint` files generated for you when you create a new Rails application.
+
+If you have an existing Rails application, you will need to create the Docker assets manually from the examples below.
+
+### 1. Create Docker assets
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for your project. Ask Gordon to create a Dockerfile, Compose file, and `.dockerignore` tailored to your application.
+
+Rails 7.1 and newer generates multistage Dockerfile out of the box. Following are two versions of such a file: one using Docker Hardened Images (DHIs) and another using the Docker Official Image (DOIs). Although the Dockerfile is generated automatically, understanding its purpose and functionality is important. Reviewing the following example is highly recommended.
+
+[Docker Hardened Images (DHIs)](https://docs.docker.com/dhi/) are minimal, secure, and production-ready container base and application images maintained by Docker. DHIs are recommended whenever it is possible for better security. They are designed to reduce vulnerabilities and simplify compliance, freely available to everyone with no subscription required, no usage restrictions, and no vendor lock-in.
+
+Multistage Dockerfiles help create smaller, more efficient images by separating build and runtime dependencies, ensuring only necessary components are included in the final image. Read more in the [Multi-stage builds guide](/get-started/docker-concepts/building-images/multi-stage-builds/).
+
+{{< tabs >}}
+{{< tab name="Using DHIs" >}}
+
+You must authenticate to `dhi.io` before you can pull Docker Hardened Images. Run `docker login dhi.io` to authenticate.
+
+```dockerfile {title=Dockerfile}
+# syntax=docker/dockerfile:1
+# check=error=true
+
+# This Dockerfile is designed for production, not development.
+# docker build -t app .
+# docker run -d -p 80:80 -e RAILS_MASTER_KEY=<value from config/master.key> --name app app
+
+# For a containerized dev environment, see Dev Containers: https://guides.rubyonrails.org/getting_started_with_devcontainer.html
+
+# Make sure RUBY_VERSION matches the Ruby version in .ruby-version
+ARG RUBY_VERSION=3.4.8
+FROM dhi.io/ruby:$RUBY_VERSION-dev AS base
+
+# Rails app lives here
+WORKDIR /rails
+
+# Install base packages
+# Replace libpq-dev with sqlite3 if using SQLite, or libmysqlclient-dev if using MySQL
+RUN apt-get update -qq && \
+    apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev && \
+    rm -rf /var/lib/apt/lists /var/cache/apt/archives
+
+# Set production environment
+ENV RAILS_ENV="production" \
+    BUNDLE_DEPLOYMENT="1" \
+    BUNDLE_PATH="/usr/local/bundle" \
+    BUNDLE_WITHOUT="development"
+
+# Throw-away build stage to reduce size of final image
+FROM base AS build
+
+# Install packages needed to build gems
+RUN apt-get update -qq && \
+    apt-get install --no-install-recommends -y build-essential curl git pkg-config libyaml-dev && \
+    rm -rf /var/lib/apt/lists /var/cache/apt/archives
+
+# Install JavaScript dependencies and Node.js for asset compilation
+#
+# Uncomment the following lines if you are using NodeJS need to compile assets
+#
+# ARG NODE_VERSION=18.12.0
+# ARG YARN_VERSION=1.22.19
+# ENV PATH=/usr/local/node/bin:$PATH
+# RUN curl -sL https://github.com/nodenv/node-build/archive/master.tar.gz | tar xz -C /tmp/ && \
+#     /tmp/node-build-master/bin/node-build "${NODE_VERSION}" /usr/local/node && \
+#     npm install -g yarn@$YARN_VERSION && \
+#     npm install -g mjml && \
+#     rm -rf /tmp/node-build-master
+
+# Install application gems
+COPY Gemfile Gemfile.lock ./
+RUN bundle install && \
+    rm -rf ~/.bundle/ "${BUNDLE_PATH}"/ruby/*/cache "${BUNDLE_PATH}"/ruby/*/bundler/gems/*/.git && \
+    bundle exec bootsnap precompile --gemfile
+
+# Install node modules
+#
+# Uncomment the following lines if you are using NodeJS need to compile assets
+#
+# COPY package.json yarn.lock ./
+# RUN --mount=type=cache,id=yarn,target=/rails/.cache/yarn YARN_CACHE_FOLDER=/rails/.cache/yarn \
+#     yarn install --frozen-lockfile
+
+# Copy application code
+COPY . .
+
+# Precompile bootsnap code for faster boot times
+RUN bundle exec bootsnap precompile app/ lib/
+
+# Precompiling assets for production without requiring secret RAILS_MASTER_KEY
+RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile
+
+# Final stage for app image
+FROM base
+
+# Copy built artifacts: gems, application
+COPY --from=build "${BUNDLE_PATH}" "${BUNDLE_PATH}"
+COPY --from=build /rails /rails
+
+# Run and own only the runtime files as a non-root user for security
+RUN groupadd --system --gid 1000 rails && \
+    useradd rails --uid 1000 --gid 1000 --create-home --shell /bin/bash && \
+    chown -R rails:rails db log storage tmp
+USER 1000:1000
+
+# Entrypoint prepares the database.
+ENTRYPOINT ["/rails/bin/docker-entrypoint"]
+
+# Start server via Thruster by default, this can be overwritten at runtime
+EXPOSE 80
+CMD ["./bin/thrust", "./bin/rails", "server"]
+```
+
+{{< /tab >}}
+{{< tab name="Using DOIs" >}}
+
+```dockerfile {title=Dockerfile}
+# syntax=docker/dockerfile:1
+# check=error=true
+
+# This Dockerfile is designed for production, not development.
+# docker build -t app .
+# docker run -d -p 80:80 -e RAILS_MASTER_KEY=<value from config/master.key> --name app app
+
+# For a containerized dev environment, see Dev Containers: https://guides.rubyonrails.org/getting_started_with_devcontainer.html
+
+# Make sure RUBY_VERSION matches the Ruby version in .ruby-version
+ARG RUBY_VERSION=3.4.8
+FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base
+
+# Rails app lives here
+WORKDIR /rails
+
+# Install base packages
+# Replace libpq-dev with sqlite3 if using SQLite, or libmysqlclient-dev if using MySQL
+RUN apt-get update -qq && \
+    apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev && \
+    rm -rf /var/lib/apt/lists /var/cache/apt/archives
+
+# Set production environment
+ENV RAILS_ENV="production" \
+    BUNDLE_DEPLOYMENT="1" \
+    BUNDLE_PATH="/usr/local/bundle" \
+    BUNDLE_WITHOUT="development"
+
+# Throw-away build stage to reduce size of final image
+FROM base AS build
+
+# Install packages needed to build gems
+RUN apt-get update -qq && \
+    apt-get install --no-install-recommends -y build-essential curl git pkg-config libyaml-dev && \
+    rm -rf /var/lib/apt/lists /var/cache/apt/archives
+
+# Install JavaScript dependencies and Node.js for asset compilation
+#
+# Uncomment the following lines if you are using NodeJS need to compile assets
+#
+# ARG NODE_VERSION=18.12.0
+# ARG YARN_VERSION=1.22.19
+# ENV PATH=/usr/local/node/bin:$PATH
+# RUN curl -sL https://github.com/nodenv/node-build/archive/master.tar.gz | tar xz -C /tmp/ && \
+#     /tmp/node-build-master/bin/node-build "${NODE_VERSION}" /usr/local/node && \
+#     npm install -g yarn@$YARN_VERSION && \
+#     npm install -g mjml && \
+#     rm -rf /tmp/node-build-master
+
+# Install application gems
+COPY Gemfile Gemfile.lock ./
+RUN bundle install && \
+    rm -rf ~/.bundle/ "${BUNDLE_PATH}"/ruby/*/cache "${BUNDLE_PATH}"/ruby/*/bundler/gems/*/.git && \
+    bundle exec bootsnap precompile --gemfile
+
+# Install node modules
+#
+# Uncomment the following lines if you are using NodeJS need to compile assets
+#
+# COPY package.json yarn.lock ./
+# RUN --mount=type=cache,id=yarn,target=/rails/.cache/yarn YARN_CACHE_FOLDER=/rails/.cache/yarn \
+#     yarn install --frozen-lockfile
+
+# Copy application code
+COPY . .
+
+# Precompile bootsnap code for faster boot times
+RUN bundle exec bootsnap precompile app/ lib/
+
+# Precompiling assets for production without requiring secret RAILS_MASTER_KEY
+RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile
+
+# Final stage for app image
+FROM base
+
+# Copy built artifacts: gems, application
+COPY --from=build "${BUNDLE_PATH}" "${BUNDLE_PATH}"
+COPY --from=build /rails /rails
+
+# Run and own only the runtime files as a non-root user for security
+RUN groupadd --system --gid 1000 rails && \
+    useradd rails --uid 1000 --gid 1000 --create-home --shell /bin/bash && \
+    chown -R rails:rails db log storage tmp
+USER 1000:1000
+
+# Entrypoint prepares the database.
+ENTRYPOINT ["/rails/bin/docker-entrypoint"]
+
+# Start server via Thruster by default, this can be overwritten at runtime
+EXPOSE 80
+CMD ["./bin/thrust", "./bin/rails", "server"]
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+The Dockerfile above assumes you are using Thruster together with Puma as an application server. In case you are using any other server, you can replace the last three lines with the following:
+
+```dockerfile
+# Start the application server
+EXPOSE 3000
+CMD ["./bin/rails", "server"]
+```
+
+This Dockerfile uses a script at `./bin/docker-entrypoint` as the container's entrypoint. This script prepares the database and runs the application server. Below is an example of such a script.
+
+```bash {title=docker-entrypoint}
+#!/bin/bash -e
+
+# Enable jemalloc for reduced memory usage and latency.
+if [ -z "${LD_PRELOAD+x}" ]; then
+    LD_PRELOAD=$(find /usr/lib -name libjemalloc.so.2 -print -quit)
+    export LD_PRELOAD
+fi
+
+# If running the rails server then create or migrate existing database
+if [ "${@: -2:1}" == "./bin/rails" ] && [ "${@: -1:1}" == "server" ]; then
+  ./bin/rails db:prepare
+fi
+
+exec "${@}"
+```
+
+Besides the two files above you will also need a `.dockerignore` file. This file is used to exclude files and directories from the context of the build. Below is an example of a `.dockerignore` file.
+
+```text {collapse=true,title=".dockerignore"}
+# See https://docs.docker.com/engine/reference/builder/#dockerignore-file for more about ignoring files.
+
+# Ignore git directory.
+/.git/
+/.gitignore
+
+# Ignore bundler config.
+/.bundle
+
+# Ignore all environment files.
+/.env*
+
+# Ignore all default key files.
+/config/master.key
+/config/credentials/*.key
+
+# Ignore all logfiles and tempfiles.
+/log/*
+/tmp/*
+!/log/.keep
+!/tmp/.keep
+
+# Ignore pidfiles, but keep the directory.
+/tmp/pids/*
+!/tmp/pids/.keep
+
+# Ignore storage (uploaded files in development and any SQLite databases).
+/storage/*
+!/storage/.keep
+/tmp/storage/*
+!/tmp/storage/.keep
+
+# Ignore assets.
+/node_modules/
+/app/assets/builds/*
+!/app/assets/builds/.keep
+/public/assets
+
+# Ignore CI service files.
+/.github
+
+# Ignore development files
+/.devcontainer
+
+# Ignore Docker-related files
+/.dockerignore
+/Dockerfile*
+```
+
+The last optional file that you may want is the `compose.yaml` file, which is used by Docker Compose to define the services that make up the application. Since SQLite is being used as the database, there is no need to define a separate service for the database. The only service required is the Rails application itself.
+
+```yaml {title=compose.yaml}
+services:
+  web:
+    build: .
+    environment:
+      - RAILS_MASTER_KEY
+    ports:
+      - "3000:80"
+```
+
+You should now have the following files in your application folder:
+
+- `.dockerignore`
+- `compose.yaml`
+- `Dockerfile`
+- `bin/docker-entrypoint`
+
+To learn more about the files, see the following:
+
+- [Dockerfile](/reference/dockerfile)
+- [.dockerignore](/reference/dockerfile#dockerignore-file)
+- [compose.yaml](/reference/compose-file/_index.md)
+- [docker-entrypoint](/reference/dockerfile/#entrypoint)
+
+### 2. Run the application
+
+To run the application, run the following command in a terminal inside the application's directory.
+
+```console
+$ RAILS_MASTER_KEY=<master_key_value> docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:3000](http://localhost:3000). You should see a simple Ruby on Rails application.
+
+In the terminal, press `ctrl`+`c` to stop the application.
+
+### 3. Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `docker-ruby-on-rails` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:3000](http://localhost:3000).
+
+You should see a simple Ruby on Rails application.
+
+In the terminal, run the following command to stop the application.
+
+```console
+$ docker compose down
+```
+
+For more information about Compose commands, see the [Compose CLI
+reference](/reference/cli/docker/compose/).
+
+## Use containers for Ruby on Rails development
+
+### Prerequisites
+
+Complete [Containerize a Ruby on Rails application](#containerize-a-ruby-on-rails-application).
+
+### Overview
+
+In this section, you'll learn how to set up a development environment for your containerized application. This includes:
+
+- Adding a local database and persisting data
+- Configuring Compose to automatically update your running Compose services as you edit and save your code
+
+### Add a local database and persist data
+
+You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service and a volume to persist data.
+
+In the cloned repository's directory, open the `compose.yaml` file in an IDE or text editor. You need to add the database password file as an environment variable to the server service and specify the secret file to use.
+
+The following is the updated `compose.yaml` file.
+
+```yaml {hl_lines="07-25"}
+services:
+  web:
+    build: .
+    command: bundle exec rails s -b '0.0.0.0'
+    ports:
+      - "3000:3000"
+    depends_on:
+      - db
+    environment:
+      - RAILS_ENV=test
+    env_file: "webapp.env"
+  db:
+    image: postgres:18
+    secrets:
+      - db-password
+    environment:
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    volumes:
+      - postgres_data:/var/lib/postgresql
+
+volumes:
+  postgres_data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+> [!NOTE]
+>
+> To learn more about the instructions in the Compose file, see [Compose file
+> reference](/reference/compose-file/).
+
+Before you run the application using Compose, notice that this Compose file specifies a `password.txt` file to hold the database's password. You must create this file as it's not included in the source repository.
+
+In the cloned repository's directory, create a new directory named `db` and inside that directory create a file named `password.txt` that contains the password for the database. Using your favorite IDE or text editor, add the following contents to the `password.txt` file.
+
+```text
+mysecretpassword
+```
+
+Save and close the `password.txt` file. In addition, in the file `webapp.env` you can change the password to connect to the database.
+
+You should now have the following contents in your `docker-ruby-on-rails`
+directory.
+
+```text
+.
+├── Dockerfile
+├── Gemfile
+├── Gemfile.lock
+├── README.md
+├── Rakefile
+├── app/
+├── bin/
+├── compose.yaml
+├── config/
+├── config.ru
+├── db/
+│   ├── development.sqlite3
+│   ├── migrate
+│   ├── password.txt
+│   ├── schema.rb
+│   └── seeds.rb
+├── lib/
+├── log/
+├── public/
+├── storage/
+├── test/
+├── tmp/
+└── vendor
+```
+
+Now, run the following `docker compose up` command to start your application.
+
+```console
+$ docker compose up --build
+```
+
+In Ruby on Rails, `db:migrate` is a Rake task that is used to run migrations on the database. Migrations are a way to alter the structure of your database schema over time in a consistent and easy way.
+
+```console
+$ docker exec -it docker-ruby-on-rails-web-1 rake db:migrate RAILS_ENV=test
+```
+
+You will see a similar message like this:
+
+```console
+== 20240710193146 CreateWhales: migrating =====================================
+-- create_table(:whales)
+   -> 0.0126s
+== 20240710193146 CreateWhales: migrated (0.0127s) ============================
+```
+
+Refresh <http://localhost:3000> in your browser and add the whales.
+
+Press `ctrl+c` in the terminal to stop your application and run `docker compose up` again, the whales are being persisted.
+
+### Automatically update services
+
+Use Compose Watch to automatically update your running Compose services as you
+edit and save your code. For more details about Compose Watch, see [Use Compose
+Watch](/manuals/compose/how-tos/file-watch.md).
+
+Open your `compose.yaml` file in an IDE or text editor and then add the Compose
+Watch instructions. The following is the updated `compose.yaml` file.
+
+```yaml {hl_lines="13-16"}
+services:
+  web:
+    build: .
+    command: bundle exec rails s -b '0.0.0.0'
+    ports:
+      - "3000:3000"
+    depends_on:
+      - db
+    environment:
+      - RAILS_ENV=test
+    env_file: "webapp.env"
+
+    develop:
+      watch:
+        - action: rebuild
+          path: .
+  db:
+    image: postgres:18
+    secrets:
+      - db-password
+    environment:
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    volumes:
+      - postgres_data:/var/lib/postgresql
+
+volumes:
+  postgres_data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+Run the following command to run your application with Compose Watch.
+
+```console
+$ docker compose watch
+```
+
+Any changes to the application's source files on your local machine will now be immediately reflected in the running container.
+
+Open `docker-ruby-on-rails/app/views/whales/index.html.erb` in an IDE or text editor and update the `Whales` string by adding an exclamation mark.
+
+```diff
+-    <h1>Whales</h1>
++    <h1>Whales!</h1>
+```
+
+Save the changes to `index.html.erb` and then wait a few seconds for the application to rebuild. Go to the application again and verify that the updated text appears.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+### Summary
+
+In this section, you took a look at setting up your Compose file to add a local
+database and persist data. You also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
+
+Related information:
+
+- [Compose file reference](/reference/compose-file/)
+- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
+- [Multi-stage builds](/manuals/build/building/multi-stage.md)
diff --git a/content/guides/ruby/_index.md b/content/guides/ruby/_index.md
deleted file mode 100644
index 5652dc7fe5b2..000000000000
--- a/content/guides/ruby/_index.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Ruby on Rails language-specific guide
-linkTitle: Ruby
-description: Containerize Ruby on Rails apps using Docker
-keywords: Docker, getting started, ruby, language
-summary: |
-  This guide explains how to containerize Ruby on Rails applications using
-  Docker.
-toc_min: 1
-toc_max: 2
-aliases:
-  - /language/ruby/
-  - /guides/language/ruby/
-languages: [ruby]
-tags: [frameworks]
-params:
-  time: 20 minutes
----
-
-The Ruby language-specific guide teaches you how to containerize a Ruby on Rails application using Docker. In this guide, you’ll learn how to:
-
-- Containerize and run a Ruby on Rails application
-- Configure a GitHub Actions workflow to build and push a Docker image to Docker Hub
-- Set up a local environment to develop a Ruby on Rails application using containers
-- Deploy your containerized Ruby on Rails application locally to Kubernetes to test and debug your deployment
-
-Start by containerizing an existing Ruby on Rails application.
diff --git a/content/guides/ruby/configure-github-actions.md b/content/guides/ruby/configure-github-actions.md
deleted file mode 100644
index a4d28d9f5016..000000000000
--- a/content/guides/ruby/configure-github-actions.md
+++ /dev/null
@@ -1,111 +0,0 @@
----
-title: Automate your builds with GitHub Actions
-linkTitle: Automate your builds with GitHub Actions
-weight: 20
-keywords: ci/cd, github actions, ruby, flask
-description: Learn how to configure CI/CD using GitHub Actions for your Ruby on Rails application.
-aliases:
-  - /language/ruby/configure-ci-cd/
-  - /guides/language/ruby/configure-ci-cd/
-  - /guides/ruby/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete all the previous sections of this guide, starting with [Containerize a Ruby on Rails application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-If you didn't create a [GitHub repository](https://github.com/new) for your project yet, it is time to do it. After creating the repository, don't forget to [add a remote](https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories) and ensure you can commit and [push your code](https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository#about-git-push) to GitHub.
-
-1. In your project's GitHub repository, open **Settings**, and go to **Secrets and variables** > **Actions**.
-
-2. Under the **Variables** tab, create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-3. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-4. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-## Overview
-
-GitHub Actions is a CI/CD (Continuous Integration and Continuous Deployment) automation tool built into GitHub. It allows you to define custom workflows for building, testing, and deploying your code when specific events occur (e.g., pushing code, creating a pull request, etc.). A workflow is a YAML-based automation script that defines a sequence of steps to be executed when triggered. Workflows are stored in the `.github/workflows/` directory of a repository.
-
-In this section, you'll learn how to set up and use GitHub Actions to build your Docker image as well as push it to Docker Hub. You will complete the following steps:
-
-1. Define the GitHub Actions workflow.
-2. Run the workflow.
-
-## 1. Define the GitHub Actions workflow
-
-You can create a GitHub Actions workflow by creating a YAML file in the `.github/workflows/` directory of your repository. To do this use your favorite text editor or the GitHub web interface. The following steps show you how to create a workflow file using the GitHub web interface.
-
-If you prefer to use the GitHub web interface, follow these steps:
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-
-2. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub Actions workflow file in
-   your repository. By default, the file is created under `.github/workflows/main.yml`, let's change it name to `build.yml`.
-
-If you prefer to use your text editor, create a new file named `build.yml` in the `.github/workflows/` directory of your repository.
-
-Add the following content to the file:
-
-```yaml
-name: Build and push Docker image
-
-on:
-  push:
-    branches:
-      - main
-
-jobs:
-  build_and_push:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Login to Docker Hub
-        uses: docker/login-action@v3
-        with:
-          username: ${{ vars.DOCKER_USERNAME }}
-          password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
-
-      - name: Build and push
-        uses: docker/build-push-action@v6
-        with:
-          push: true
-          tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-```
-
-Each GitHub Actions workflow includes one or several jobs. Each job consists of steps. Each step can either run a set of commands or use already [existing actions](https://github.com/marketplace?type=actions). The action above has three steps:
-
-1. [**Login to Docker Hub**](https://github.com/docker/login-action): Action logs in to Docker Hub using the Docker ID and Personal Access Token (PAT) you created earlier.
-
-2. [**Set up Docker Buildx**](https://github.com/docker/setup-buildx-action): Action sets up Docker [Buildx](https://github.com/docker/buildx), a CLI plugin that extends the capabilities of the Docker CLI.
-
-3. [**Build and push**](https://github.com/docker/build-push-action): Action builds and pushes the Docker image to Docker Hub. The `tags` parameter specifies the image name and tag. The `latest` tag is used in this example.
-
-## 2. Run the workflow
-
-Let's commit the changes, push them to the `main` branch. In the workflow above, the trigger is set to `push` events on the `main` branch. This means that the workflow will run every time you push changes to the `main` branch. You can find more information about the workflow triggers [here](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows).
-
-Go to the **Actions** tab of you GitHub repository. It displays the workflow. Selecting the workflow shows you the breakdown of all the steps.
-
-When the workflow is complete, go to your [repositories on Docker Hub](https://hub.docker.com/repositories). If you see the new repository in that list, it means the GitHub Actions workflow successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your Ruby on Rails application.
-
-Related information:
-
-- [Introduction to GitHub Actions](/guides/gha.md)
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md)
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-In the next section, you'll learn how you can develop your application using containers.
-
diff --git a/content/guides/ruby/containerize.md b/content/guides/ruby/containerize.md
deleted file mode 100644
index 18fbd21eef71..000000000000
--- a/content/guides/ruby/containerize.md
+++ /dev/null
@@ -1,281 +0,0 @@
----
-title: Containerize a Ruby on Rails application
-linkTitle: Containerize your app
-weight: 10
-keywords: ruby, flask, containerize, initialize
-description: Learn how to containerize a Ruby on Rails application.
-aliases:
-  - /language/ruby/build-images/
-  - /language/ruby/run-containers/
-  - /language/ruby/containerize/
-  - /guides/language/ruby/containerize/
----
-
-## Prerequisites
-
-- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
-- You have a [Git client](https://git-scm.com/downloads). The examples in this section show the Git CLI, but you can use any client.
-
-## Overview
-
-This section walks you through containerizing and running a [Ruby on Rails](https://rubyonrails.org/) application.
-
-Starting from Rails 7.1 [Docker is supported out of the box](https://guides.rubyonrails.org/7_1_release_notes.html#generate-dockerfiles-for-new-rails-applications). This means that you will get a `Dockerfile`, `.dockerignore` and `bin/docker-entrypoint` files generated for you when you create a new Rails application.
-
-If you have an existing Rails application, you will need to create the Docker assets manually. Unfortunately `docker init` command does not yet support Rails. This means that if you are working with Rails, you'll need to copy Dockerfile and other related configurations manually from the examples below.
-
-## 1. Initialize Docker assets
-
-Rails 7.1 generates multistage Dockerfile out of the box, below is an example of such file generated from a Rails template.
-
-> Multistage Dockerfiles help create smaller, more efficient images by separating build and runtime dependencies, ensuring only necessary components are included in the final image. Read more in the [Multi-stage builds guide](/get-started/docker-concepts/building-images/multi-stage-builds/).
-
-Although the Dockerfile is generated automatically, understanding its purpose and functionality is important. Reviewing the following example is highly recommended.
-
-
-```dockerfile {title=Dockerfile}
-# syntax=docker/dockerfile:1
-# check=error=true
-
-# This Dockerfile is designed for production, not development.
-# docker build -t app .
-# docker run -d -p 80:80 -e RAILS_MASTER_KEY=<value from config/master.key> --name app app
-
-# For a containerized dev environment, see Dev Containers: https://guides.rubyonrails.org/getting_started_with_devcontainer.html
-
-# Make sure RUBY_VERSION matches the Ruby version in .ruby-version
-ARG RUBY_VERSION=3.3.6
-FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base
-
-# Rails app lives here
-WORKDIR /rails
-
-# Install base packages
-# Replace libpq-dev with sqlite3 if using SQLite, or libmysqlclient-dev if using MySQL
-RUN apt-get update -qq && \
-    apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev && \
-    rm -rf /var/lib/apt/lists /var/cache/apt/archives
-
-# Set production environment
-ENV RAILS_ENV="production" \
-    BUNDLE_DEPLOYMENT="1" \
-    BUNDLE_PATH="/usr/local/bundle" \
-    BUNDLE_WITHOUT="development"
-
-# Throw-away build stage to reduce size of final image
-FROM base AS build
-
-# Install packages needed to build gems
-RUN apt-get update -qq && \
-    apt-get install --no-install-recommends -y build-essential curl git pkg-config libyaml-dev && \
-    rm -rf /var/lib/apt/lists /var/cache/apt/archives
-
-# Install JavaScript dependencies and Node.js for asset compilation
-#
-# Uncomment the following lines if you are using NodeJS need to compile assets
-#
-# ARG NODE_VERSION=18.12.0
-# ARG YARN_VERSION=1.22.19
-# ENV PATH=/usr/local/node/bin:$PATH
-# RUN curl -sL https://github.com/nodenv/node-build/archive/master.tar.gz | tar xz -C /tmp/ && \
-#     /tmp/node-build-master/bin/node-build "${NODE_VERSION}" /usr/local/node && \
-#     npm install -g yarn@$YARN_VERSION && \
-#     npm install -g mjml && \
-#     rm -rf /tmp/node-build-master
-
-# Install application gems
-COPY Gemfile Gemfile.lock ./
-RUN bundle install && \
-    rm -rf ~/.bundle/ "${BUNDLE_PATH}"/ruby/*/cache "${BUNDLE_PATH}"/ruby/*/bundler/gems/*/.git && \
-    bundle exec bootsnap precompile --gemfile
-
-# Install node modules
-#
-# Uncomment the following lines if you are using NodeJS need to compile assets
-#
-# COPY package.json yarn.lock ./
-# RUN --mount=type=cache,id=yarn,target=/rails/.cache/yarn YARN_CACHE_FOLDER=/rails/.cache/yarn \
-#     yarn install --frozen-lockfile
-
-# Copy application code
-COPY . .
-
-# Precompile bootsnap code for faster boot times
-RUN bundle exec bootsnap precompile app/ lib/
-
-# Precompiling assets for production without requiring secret RAILS_MASTER_KEY
-RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile
-
-# Final stage for app image
-FROM base
-
-# Copy built artifacts: gems, application
-COPY --from=build "${BUNDLE_PATH}" "${BUNDLE_PATH}"
-COPY --from=build /rails /rails
-
-# Run and own only the runtime files as a non-root user for security
-RUN groupadd --system --gid 1000 rails && \
-    useradd rails --uid 1000 --gid 1000 --create-home --shell /bin/bash && \
-    chown -R rails:rails db log storage tmp
-USER 1000:1000
-
-# Entrypoint prepares the database.
-ENTRYPOINT ["/rails/bin/docker-entrypoint"]
-
-# Start server via Thruster by default, this can be overwritten at runtime
-EXPOSE 80
-CMD ["./bin/thrust", "./bin/rails", "server"]
-```
-
-The Dockerfile above assumes you are using Thruster together with Puma as an application server. In case you are using any other server, you can replace the last three lines with the following:
-
-```dockerfile
-# Start the application server
-EXPOSE 3000
-CMD ["./bin/rails", "server"]
-```
-
-This Dockerfile uses a script at `./bin/docker-entrypoint` as the container's entrypiont. This script prepares the database and runs the application server. Below is an example of such a script.
-
-```bash {title=docker-entrypoint}
-#!/bin/bash -e
-
-# Enable jemalloc for reduced memory usage and latency.
-if [ -z "${LD_PRELOAD+x}" ]; then
-    LD_PRELOAD=$(find /usr/lib -name libjemalloc.so.2 -print -quit)
-    export LD_PRELOAD
-fi
-
-# If running the rails server then create or migrate existing database
-if [ "${@: -2:1}" == "./bin/rails" ] && [ "${@: -1:1}" == "server" ]; then
-  ./bin/rails db:prepare
-fi
-
-exec "${@}"
-```
-
-Besides the two files above you will also need a `.dockerignore` file. This file is used to exclude files and directories from the context of the build. Below is an example of a `.dockerignore` file.
-
-```text {collapse=true,title=".dockerignore"}
-# See https://docs.docker.com/engine/reference/builder/#dockerignore-file for more about ignoring files.
-
-# Ignore git directory.
-/.git/
-/.gitignore
-
-# Ignore bundler config.
-/.bundle
-
-# Ignore all environment files.
-/.env*
-
-# Ignore all default key files.
-/config/master.key
-/config/credentials/*.key
-
-# Ignore all logfiles and tempfiles.
-/log/*
-/tmp/*
-!/log/.keep
-!/tmp/.keep
-
-# Ignore pidfiles, but keep the directory.
-/tmp/pids/*
-!/tmp/pids/.keep
-
-# Ignore storage (uploaded files in development and any SQLite databases).
-/storage/*
-!/storage/.keep
-/tmp/storage/*
-!/tmp/storage/.keep
-
-# Ignore assets.
-/node_modules/
-/app/assets/builds/*
-!/app/assets/builds/.keep
-/public/assets
-
-# Ignore CI service files.
-/.github
-
-# Ignore development files
-/.devcontainer
-
-# Ignore Docker-related files
-/.dockerignore
-/Dockerfile*
-```
-
-The last optional file that you may want is the `compose.yaml` file, which is used by Docker Compose to define the services that make up the application. Since SQLite is being used as the database, there is no need to define a separate service for the database. The only service required is the Rails application itself.
-
-```yaml {title=compose.yaml}
-services:
-  web:
-    build: .
-    environment:
-      - RAILS_MASTER_KEY
-    ports:
-      - "3000:80"
-```
-
-You should now have the following files in your application folder:
-
-- `.dockerignore`
-- `compose.yaml`
-- `Dockerfile`
-- `bin/docker-entrypoint`
-
-To learn more about the files, see the following:
-
-- [Dockerfile](/reference/dockerfile)
-- [.dockerignore](/reference/dockerfile#dockerignore-file)
-- [compose.yaml](/reference/compose-file/_index.md)
-- [docker-entrypoint](/reference/dockerfile/#entrypoint)
-
-## 2. Run the application
-
-To run the application, run the following command in a terminal inside the application's directory.
-
-```console
-$ RAILS_MASTER_KEY=<master_key_value> docker compose up --build
-```
-
-Open a browser and view the application at [http://localhost:3000](http://localhost:3000). You should see a simple Ruby on Rails application.
-
-In the terminal, press `ctrl`+`c` to stop the application.
-
-## 3. Run the application in the background
-
-You can run the application detached from the terminal by adding the `-d`
-option. Inside the `docker-ruby-on-rails` directory, run the following command
-in a terminal.
-
-```console
-$ docker compose up --build -d
-```
-
-Open a browser and view the application at [http://localhost:3000](http://localhost:3000).
-
-You should see a simple Ruby on Rails application.
-
-In the terminal, run the following command to stop the application.
-
-```console
-$ docker compose down
-```
-
-For more information about Compose commands, see the [Compose CLI
-reference](/reference/cli/docker/compose/_index.md).
-
-## Summary
-
-In this section, you learned how you can containerize and run your Ruby
-application using Docker.
-
-Related information:
-
-- [Docker Compose overview](/manuals/compose/_index.md)
-
-## Next steps
-
-In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions.
\ No newline at end of file
diff --git a/content/guides/ruby/deploy.md b/content/guides/ruby/deploy.md
deleted file mode 100644
index 91d511d2d03d..000000000000
--- a/content/guides/ruby/deploy.md
+++ /dev/null
@@ -1,167 +0,0 @@
----
-title: Test your Ruby on Rails deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, kubernetes, ruby
-description: Learn how to develop locally using Kubernetes
-aliases:
-  - /language/ruby/deploy/
-  - /guides/language/ruby/deploy/
----
-
-## Prerequisites
-
-- Complete all the previous sections of this guide, starting with [Containerize a Ruby on Rails application](containerize.md).
-- [Turn on Kubernetes](/manuals/desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This lets you to test and debug your workloads on Kubernetes locally before deploying.
-
-## Create a Kubernetes YAML file
-
-In your `docker-ruby-on-rails` directory, create a file named
-`docker-ruby-on-rails-kubernetes.yaml`. Open the file in an IDE or text editor and add
-the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker
-username and the name of the repository that you created in [Configure CI/CD for
-your Ruby on Rails application](configure-github-actions.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: docker-ruby-on-rails-demo
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      service: ruby-on-rails
-  template:
-    metadata:
-      labels:
-        service: ruby-on-rails
-    spec:
-      containers:
-        - name: ruby-on-rails-container
-          image: DOCKER_USERNAME/REPO_NAME
-          imagePullPolicy: Always
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: docker-ruby-on-rails-demo
-  namespace: default
-spec:
-  type: NodePort
-  selector:
-    service: ruby-on-rails
-  ports:
-    - port: 3000
-      targetPort: 3000
-      nodePort: 30001
-```
-
-In this Kubernetes YAML file, there are two objects, separated by the `---`:
-
-- A Deployment, describing a scalable group of identical pods. In this case,
-  you'll get just one replica, or copy of your pod. That pod, which is
-  described under `template`, has just one container in it. The
-  container is created from the image built by GitHub Actions in [Configure CI/CD for
-  your Ruby on Rails application](configure-github-actions.md).
-- A NodePort service, which will route traffic from port 30001 on your host to
-  port 8001 inside the pods it routes to, allowing you to reach your app
-  from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to `docker-ruby-on-rails` and deploy your application to
-   Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-ruby-on-rails-kubernetes.yaml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```shell
-   deployment.apps/docker-ruby-on-rails-demo created
-   service/docker-ruby-on-rails-demo created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```shell
-   NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
-   docker-ruby-on-rails-demo  1/1     1            1           15s
-   ```
-
-   This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```shell
-   NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
-   kubernetes                  ClusterIP   10.96.0.1       <none>        443/TCP          23h
-   docker-ruby-on-rails-demo   NodePort    10.99.128.230   <none>        3000:30001/TCP   75s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `docker-ruby-on-rails-demo` service, accepting traffic on port 30001/TCP.
-
-3. To create and migrate the database in a Ruby on Rails application running on Kubernetes, you need to follow these steps.
-
-   **Get the Current Pods**:
-   First, you need to identify the pods running in your Kubernetes cluster. Execute the following command to list the current pods in the `default` namespace:
-
-   ```sh
-   # Get the current pods in the cluster in the namespace default
-   $ kubectl get pods
-   ```
-
-   This command will display a list of all pods in the `default` namespace. Look for the pod with the prefix `docker-ruby-on-rails-demo-`. Here is an example output:
-
-   ```console
-   NAME                                         READY   STATUS    RESTARTS      AGE
-   docker-ruby-on-rails-demo-7cbddb5d6f-qh44l   1/1     Running   2 (22h ago)   9d
-   ```
-
-   **Execute the Migration Command**:
-   Once you've identified the correct pod, use the `kubectl exec` command to run the database migration inside the pod.
-
-   ```sh
-   $ kubectl exec -it docker-ruby-on-rails-demo-7cbddb5d6f-qh44l -- rails db:migrate RAILS_ENV=development
-   ```
-
-   This command opens an interactive terminal session (`-it`) in the specified pod and runs the `rails db:migrate` command with the environment set to development (`RAILS_ENV=development`).
-
-   By following these steps, you ensure that your database is properly migrated within the Ruby on Rails application running in your Kubernetes cluster. This process helps maintain the integrity and consistency of your application's data structure during deployment and updates.
-
-4. Open the browser and go to [http://localhost:30001](http://localhost:30001), you should see the ruby on rails application working.
-
-5. Run the following command to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-ruby-on-rails-kubernetes.yaml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine.
-
-Related information:
-
-- [Kubernetes documentation](https://kubernetes.io/docs/home/)
-- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-- [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/ruby/develop.md b/content/guides/ruby/develop.md
deleted file mode 100644
index 7b7b94b4729f..000000000000
--- a/content/guides/ruby/develop.md
+++ /dev/null
@@ -1,203 +0,0 @@
----
-title: Use containers for Ruby on Rails development
-linkTitle: Develop your app
-weight: 40
-keywords: ruby, local, development
-description: Learn how to develop your Ruby on Rails application locally.
-aliases:
-  - /language/ruby/develop/
-  - /guides/language/ruby/develop/
----
-
-## Prerequisites
-
-Complete [Containerize a Ruby on Rails application](containerize.md).
-
-## Overview
-
-In this section, you'll learn how to set up a development environment for your containerized application. This includes:
-
-- Adding a local database and persisting data
-- Configuring Compose to automatically update your running Compose services as you edit and save your code
-
-## Add a local database and persist data
-
-You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service and a volume to persist data.
-
-In the cloned repository's directory, open the `compose.yaml` file in an IDE or text editor. You need to add the database password file as an environment variable to the server service and specify the secret file to use.
-
-The following is the updated `compose.yaml` file.
-
-```yaml {hl_lines="07-25"}
-services:
-  web:
-    build: .
-    command: bundle exec rails s -b '0.0.0.0'
-    ports:
-      - "3000:3000"
-    depends_on:
-      - db
-    environment:
-      - RAILS_ENV=test
-    env_file: "webapp.env"
-  db:
-    image: postgres:latest
-    secrets:
-      - db-password
-    environment:
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    volumes:
-      - postgres_data:/var/lib/postgresql/data
-
-volumes:
-  postgres_data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-> [!NOTE]
->
-> To learn more about the instructions in the Compose file, see [Compose file
-> reference](/reference/compose-file/).
-
-Before you run the application using Compose, notice that this Compose file specifies a `password.txt` file to hold the database's password. You must create this file as it's not included in the source repository.
-
-In the cloned repository's directory, create a new directory named `db` and inside that directory create a file named `password.txt` that contains the password for the database. Using your favorite IDE or text editor, add the following contents to the `password.txt` file.
-
-```text
-mysecretpassword
-```
-
-Save and close the `password.txt` file. In addition, in the file `webapp.env` you can change the password to connect to the database.
-
-You should now have the following contents in your `docker-ruby-on-rails`
-directory.
-
-```text
-.
-├── Dockerfile
-├── Gemfile
-├── Gemfile.lock
-├── README.md
-├── Rakefile
-├── app/
-├── bin/
-├── compose.yaml
-├── config/
-├── config.ru
-├── db/
-│   ├── development.sqlite3
-│   ├── migrate
-│   ├── password.txt
-│   ├── schema.rb
-│   └── seeds.rb
-├── lib/
-├── log/
-├── public/
-├── storage/
-├── test/
-├── tmp/
-└── vendor
-```
-
-Now, run the following `docker compose up` command to start your application.
-
-```console
-$ docker compose up --build
-```
-
-In Ruby on Rails, `db:migrate` is a Rake task that is used to run migrations on the database. Migrations are a way to alter the structure of your database schema over time in a consistent and easy way.
-
-```console
-$ docker exec -it docker-ruby-on-rails-web-1 rake db:migrate RAILS_ENV=test
-```
-
-You will see a similar message like this:
-
-`console
-== 20240710193146 CreateWhales: migrating =====================================
--- create_table(:whales)
-   -> 0.0126s
-== 20240710193146 CreateWhales: migrated (0.0127s) ============================
-`
-
-Refresh <http://localhost:3000> in your browser and add the whales.
-
-Press `ctrl+c` in the terminal to stop your application and run `docker compose up` again, the whales are being persisted.
-
-## Automatically update services
-
-Use Compose Watch to automatically update your running Compose services as you
-edit and save your code. For more details about Compose Watch, see [Use Compose
-Watch](/manuals/compose/how-tos/file-watch.md).
-
-Open your `compose.yaml` file in an IDE or text editor and then add the Compose
-Watch instructions. The following is the updated `compose.yaml` file.
-
-```yaml {hl_lines="13-16"}
-services:
-  web:
-    build: .
-    command: bundle exec rails s -b '0.0.0.0'
-    ports:
-      - "3000:3000"
-    depends_on:
-      - db
-    environment:
-      - RAILS_ENV=test
-    env_file: "webapp.env"
-
-    develop:
-      watch:
-        - action: rebuild
-          path: .
-  db:
-    image: postgres:latest
-    secrets:
-      - db-password
-    environment:
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    volumes:
-      - postgres_data:/var/lib/postgresql/data
-
-volumes:
-  postgres_data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-Run the following command to run your application with Compose Watch.
-
-```console
-$ docker compose watch
-```
-
-Any changes to the application's source files on your local machine will now be immediately reflected in the running container.
-
-Open `docker-ruby-on-rails/app/views/whales/index.html.erb` in an IDE or text editor and update the `Whales` string by adding an exclamation mark.
-
-```diff
--    <h1>Whales</h1>
-+    <h1>Whales!</h1>
-```
-
-Save the changes to `index.html.erb` and then wait a few seconds for the application to rebuild. Go to the application again and verify that the updated text appears.
-
-Press `ctrl+c` in the terminal to stop your application.
-
-## Summary
-
-In this section, you took a look at setting up your Compose file to add a local
-database and persist data. You also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
-
-Related information:
-
-- [Compose file reference](/reference/compose-file/)
-- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
-- [Multi-stage builds](/manuals/build/building/multi-stage.md)
-
-## Next steps
-
-In the next section, you'll learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/rust.md b/content/guides/rust.md
new file mode 100644
index 000000000000..d3ce876ee27a
--- /dev/null
+++ b/content/guides/rust.md
@@ -0,0 +1,794 @@
+---
+title: Rust language-specific guide
+linkTitle: Rust
+description: Containerize Rust apps using Docker
+keywords: Docker, getting started, Rust, language
+summary: |
+  This guide covers how to containerize Rust applications using Docker.
+aliases:
+  - /language/rust/
+  - /guides/language/rust/
+  - /language/rust/build-images/
+  - /language/rust/run-containers/
+  - /language/rust/develop/
+  - /language/rust/configure-ci-cd/
+  - /language/rust/deploy/
+  - /guides/rust/build-images/
+  - /guides/rust/configure-ci-cd/
+  - /guides/rust/deploy/
+  - /guides/rust/develop/
+  - /guides/rust/run-containers/
+params:
+  tags: [languages]
+  time: 20 minutes
+---
+
+The Rust language-specific guide teaches you how to create a containerized Rust application using Docker. In this guide, you'll learn how to:
+
+- Containerize a Rust application
+- Build an image and run the newly built image as a container
+- Set up volumes and networking
+- Orchestrate containers using Compose
+- Use containers for development
+
+After completing the Rust modules, you should be able to containerize your own Rust application based on the examples and instructions provided in this guide.
+
+Start with building your first Rust image.
+
+## Build your Rust image
+
+### Prerequisites
+
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
+- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
+
+### Overview
+
+This guide walks you through building your first Rust image. An image
+includes everything needed to run an application - the code or binary, runtime,
+dependencies, and any other file system objects required.
+
+### Get the sample application
+
+Clone the sample application to use with this guide. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
+
+```console
+$ git clone https://github.com/docker/docker-rust-hello && cd docker-rust-hello
+```
+
+### Choose a base image
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for your project. Ask Gordon to create a Dockerfile, Compose file, and `.dockerignore` tailored to your application.
+
+Before editing your Dockerfile, you need to choose a base image. You can use the [Rust Docker Official Image](https://hub.docker.com/_/rust),  
+or a [Docker Hardened Image (DHI)](https://hub.docker.com/hardened-images/catalog/dhi/rust).
+
+Docker Hardened Images (DHIs) are minimal, secure, and production-ready base images maintained by Docker.  
+They help reduce vulnerabilities and simplify compliance. For more details, see [Docker Hardened Images](/dhi/).
+
+{{< tabs >}}
+{{< tab name="Using Docker Hardened Images" >}}
+
+Docker Hardened Images (DHIs) are publicly available and can be used directly as base images.
+To pull Docker Hardened Images, authenticate once with Docker:
+
+```bash
+docker login dhi.io
+```
+
+Use DHIs from the dhi.io registry, for example:
+
+```bash
+FROM dhi.io/rust:${RUST_VERSION}-alpine3.22-dev AS build
+```
+
+The following Dockerfile uses a Rust DHI as the build base image:
+
+```dockerfile {title=Dockerfile}
+# Make sure RUST_VERSION matches the Rust version
+ARG RUST_VERSION=1.92
+ARG APP_NAME=docker-rust-hello
+
+################################################################################
+# Create a stage for building the application.
+################################################################################
+
+FROM dhi.io/rust:${RUST_VERSION}-alpine3.22-dev AS build
+ARG APP_NAME
+WORKDIR /app
+
+# Install host build dependencies.
+RUN apk add --no-cache clang lld musl-dev git
+
+# Build the application.
+RUN --mount=type=bind,source=src,target=src \
+    --mount=type=bind,source=Cargo.toml,target=Cargo.toml \
+    --mount=type=bind,source=Cargo.lock,target=Cargo.lock \
+    --mount=type=cache,target=/app/target/ \
+    --mount=type=cache,target=/var/cache/cargo \
+    CARGO_HOME=/var/cache/cargo cargo build --locked --release && \
+    cp ./target/release/$APP_NAME /bin/server
+
+################################################################################
+# Create a new stage for running the application that contains the minimal
+# We use dhi.io/static for the final stage because it’s a minimal Docker Hardened Image runtime (basically “just # enough OS to run the binary”), which helps keep the image small and with a lower attack surface compared to a # # full Alpine/Debian runtime.
+################################################################################
+
+FROM dhi.io/static:20250419 AS final
+
+# Copy the executable from the "build" stage.
+COPY --from=build /bin/server /bin/
+
+# Configure rocket to listen on all interfaces.
+ENV ROCKET_ADDRESS=0.0.0.0
+
+# Expose the port that the application listens on.
+EXPOSE 8000
+
+# What the container should run when it is started.
+CMD ["/bin/server"]
+
+```
+
+{{< /tab >}}
+{{< tab name="Using the Docker Official Images" >}}
+
+```dockerfile {title=Dockerfile}
+# Pin the Rust toolchain version used in the build stage.
+ARG RUST_VERSION=1.92
+
+# Name of the compiled binary produced by Cargo (must match Cargo.toml package name).
+ARG APP_NAME=docker-rust-hello
+
+################################################################################
+# Build stage (DOI Rust image)
+# This stage compiles the application.
+################################################################################
+
+FROM docker.io/library/rust:${RUST_VERSION}-alpine AS build
+
+# Re-declare args inside the stage if you want to use them here.
+ARG APP_NAME
+
+# All build steps happen inside /app.
+WORKDIR /app
+
+# Install build dependencies needed to compile Rust crates on Alpine
+RUN apk add --no-cache clang lld musl-dev git
+
+# Build the application
+RUN --mount=type=bind,source=src,target=src \
+    --mount=type=bind,source=Cargo.toml,target=Cargo.toml \
+    --mount=type=bind,source=Cargo.lock,target=Cargo.lock \
+    --mount=type=cache,target=/app/target/ \
+    --mount=type=cache,target=/var/cache/cargo \
+    CARGO_HOME=/var/cache/cargo cargo build --locked --release && \
+    cp ./target/release/$APP_NAME /bin/server
+
+################################################################################
+# Runtime stage (DOI Alpine image)
+# This stage runs the already-compiled binary with minimal dependencies.
+################################################################################
+
+FROM docker.io/library/alpine:3.18 AS final
+
+# Create a non-privileged user (recommended best practice)
+ARG UID=10001
+RUN adduser \
+    --disabled-password \
+    --gecos "" \
+    --home "/nonexistent" \
+    --shell "/sbin/nologin" \
+    --no-create-home \
+    --uid "${UID}" \
+    appuser
+
+# Drop privileges for runtime.
+USER appuser
+
+# Copy only the compiled binary from the build stage.
+COPY --from=build /bin/server /bin/
+
+# Rocket: listen on all interfaces inside the container.
+ENV ROCKET_ADDRESS=0.0.0.0
+
+# Document the port your app listens on.
+EXPOSE 8000
+
+# Start the application.
+CMD ["/bin/server"]
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+The cache mount uses a single `CARGO_HOME` so concurrent builds coordinate
+access through Cargo's cache lock. Setting `CARGO_HOME` also changes where
+Cargo looks for global configuration and credentials. Project-level
+`.cargo/config.toml` files are unaffected.
+
+For building an image, only the Dockerfile is necessary. Open the Dockerfile
+in your favorite IDE or text editor and see what it contains. To learn more
+about Dockerfiles, see the [Dockerfile reference](/reference/dockerfile.md).
+
+### .dockerignore file
+
+The [`.dockerignore`](/reference/dockerfile.md#dockerignore-file) file specifies patterns and paths that you don't want copied into the image in order to keep the image as small as possible. Open up the `.dockerignore` file in your favorite IDE or text editor to review its contents.
+
+### Build an image
+
+Now that you’ve created the Dockerfile, you can build the image. To do this, use
+the `docker build` command. The `docker build` command builds Docker images from
+a Dockerfile and a context. A build's context is the set of files located in
+the specified PATH or URL. The Docker build process can access any of the files
+located in this context.
+
+The build command optionally takes a `--tag` flag. The tag sets the name of the
+image and an optional tag in the format `name:tag`. If you don't pass a tag,
+Docker uses "latest" as its default tag.
+
+Build the Docker image.
+
+```console
+$ docker build --tag docker-rust-image-dhi .
+```
+
+You should see output like the following.
+
+```console
+[+] Building 1.4s (13/13) FINISHED                                                                                                                                 docker:desktop-linux
+ => [internal] load build definition from Dockerfile                                                                                                                               0.0s
+ => => transferring dockerfile: 1.67kB                                                                                                                                             0.0s
+ => [internal] load metadata for dhi.io/static:20250419                                                                                                                            1.1s
+ => [internal] load metadata for dhi.io/rust:1.92-alpine3.22-dev                                                                                                                   1.2s
+ => [auth] static:pull token for dhi.io                                                                                                                                            0.0s
+ => [auth] rust:pull token for dhi.io                                                                                                                                              0.0s
+ => [internal] load .dockerignore                                                                                                                                                  0.0s
+ => => transferring context: 646B                                                                                                                                                  0.0s
+ => [build 1/3] FROM dhi.io/rust:1.92-alpine3.22-dev@sha256:49eb72825a9e15fe48f2c4875a63c7e7f52a5b430bb52b8254b91d132aa5bf38                                                       0.0s
+ => => resolve dhi.io/rust:1.92-alpine3.22-dev@sha256:49eb72825a9e15fe48f2c4875a63c7e7f52a5b430bb52b8254b91d132aa5bf38                                                             0.0s
+ => [final 1/2] FROM dhi.io/static:20250419@sha256:74fc43fa240887b8159970e434244039aab0c6efaaa9cf044004cdc22aa2a34d                                                                0.0s
+ => => resolve dhi.io/static:20250419@sha256:74fc43fa240887b8159970e434244039aab0c6efaaa9cf044004cdc22aa2a34d                                                                      0.0s
+ => [internal] load build context                                                                                                                                                  0.0s
+ => => transferring context: 117B                                                                                                                                                  0.0s
+ => CACHED [build 2/3] WORKDIR /build                                                                                                                                              0.0s
+ => CACHED [build 3/3] RUN --mount=type=bind,source=src,target=src     --mount=type=bind,source=Cargo.toml,target=Cargo.toml     --mount=type=bind,source=Cargo.lock,target=Cargo  0.0s
+ => CACHED [final 2/2] COPY --from=build /build/target/release/docker-rust-hello /server                                                                                           0.0s
+ => exporting to image                                                                                                                                                             0.1s
+ => => exporting layers                                                                                                                                                            0.0s
+ => => exporting manifest sha256:cc937bbdd712ef6e5445501f77e02ef8455ef64c567598786d46b7b21a4d4fa8                                                                                  0.0s
+ => => exporting config sha256:077507b483af4b5e1a928e527e4bb3a4aaf0557e1eea81cd39465f564c187669                                                                                    0.0s
+ => => exporting attestation manifest sha256:11b60e7608170493da1fdd88c120e2d2957f2a72a22edbc9cfbdd0dd37d21f89                                                                      0.0s
+ => => exporting manifest list sha256:99a1b925a8d6ebf80e376b8a1e50cd806ec42d194479a3375e1cd9d2911b4db9                                                                             0.0s
+ => => naming to docker.io/library/docker-rust-image-dhi:latest                                                                                                                    0.0s
+ => => unpacking to docker.io/library/docker-rust-image-dhi:latest                                                                                                                 0.0s
+
+View build details: docker-desktop://dashboard/build/desktop-linux/desktop-linux/yczk0ijw8kc5g20e8nbc8r6lj
+```
+
+### View local images
+
+To see a list of images you have on your local machine, you have two options. One is to use the Docker CLI and the other is to use [Docker Desktop](/manuals/desktop/use-desktop/images.md). As you are working in the terminal already, take a look at listing images using the CLI.
+
+To list images, run the `docker images` command.
+
+```console
+$ docker images
+IMAGE                          ID             DISK USAGE   CONTENT SIZE   EXTRA
+docker-rust-image-dhi:latest   99a1b925a8d6       11.6MB         2.45MB    U
+```
+
+You should see at least one image listed, including the image you just built `docker-rust-image-dhi:latest`.
+
+### Tag images
+
+As mentioned earlier, an image name is made up of slash-separated name components. Name components may contain lowercase letters, digits, and separators. A separator can include a period, one or two underscores, or one or more dashes. A name component may not start or end with a separator.
+
+An image is made up of a manifest and a list of layers. Don't worry too much about manifests and layers at this point other than a "tag" points to a combination of these artifacts. You can have multiple tags for an image. Create a second tag for the image you built and take a look at its layers.
+
+To create a new tag for the image you built, run the following command.
+
+```console
+$ docker tag docker-rust-image-dhi:latest docker-rust-image-dhi:v1.0.0
+```
+
+The `docker tag` command creates a new tag for an image. It doesn't create a new image. The tag points to the same image and is just another way to reference the image.
+
+Now, run the `docker images` command to see a list of the local images.
+
+```console
+$ docker images
+IMAGE                          ID             DISK USAGE   CONTENT SIZE   EXTRA
+docker-rust-image-dhi:latest   99a1b925a8d6       11.6MB         2.45MB    U
+docker-rust-image-dhi:v1.0.0   99a1b925a8d6       11.6MB         2.45MB    U
+```
+
+You can see that two images start with `docker-rust-image-dhi`. You know they're the same image because if you take a look at the `IMAGE ID` column, you can see that the values are the same for the two images.
+
+Remove the tag you just created. To do this, use the `rmi` command. The `rmi` command stands for remove image.
+
+```console
+$ docker rmi docker-rust-image-dhi:v1.0.0
+Untagged: docker-rust-image-dhi:v1.0.0
+```
+
+Note that the response from Docker tells you that Docker didn't remove the image, but only "untagged" it. You can check this by running the `docker images` command.
+
+```console
+$ docker images
+IMAGE                          ID             DISK USAGE   CONTENT SIZE   EXTRA
+docker-rust-image-dhi:latest   99a1b925a8d6       11.6MB         2.45MB    U
+```
+
+Docker removed the image tagged with `:v1.0.0`, but the `docker-rust-image-dhi:latest` tag is available on your machine.
+
+## Run your Rust image as a container
+
+### Prerequisite
+
+You have completed [Build your Rust image](#build-your-rust-image) and you have built an image.
+
+### Overview
+
+A container is a normal operating system process except that Docker isolates this process so that it has its own file system, its own networking, and its own isolated process tree separate from the host.
+
+To run an image inside of a container, you use the `docker run` command. The `docker run` command requires one parameter which is the name of the image.
+
+### Run an image
+
+Use `docker run` to run the image you built in [Build your Rust image](#build-your-rust-image).
+
+```console
+$ docker run docker-rust-image-dhi
+```
+
+After running this command, you’ll notice that you weren't returned to the command prompt. This is because your application is a server that runs in a loop waiting for incoming requests without returning control back to the OS until you stop the container.
+
+Open a new terminal then make a request to the server using the `curl` command.
+
+```console
+$ curl http://localhost:8000
+```
+
+You should see output like the following.
+
+```console
+curl: (7) Failed to connect to localhost port 8000 after 2236 ms: Couldn't connect to server
+```
+
+As you can see, your `curl` command failed. This means you weren't able to connect to the localhost on port 8000. This is normal because your container is running in isolation which includes networking. Stop the container and restart with port 8000 published on your local network.
+
+To stop the container, press ctrl-c. This will return you to the terminal prompt.
+
+To publish a port for your container, you’ll use the `--publish` flag (`-p` for short) on the `docker run` command. The format of the `--publish` command is `[host port]:[container port]`. So, if you wanted to expose port 8000 inside the container to port 3001 outside the container, you would pass `3001:8000` to the `--publish` flag.
+
+You didn't specify a port when running the application in the container and the default is 8000. If you want your previous request going to port 8000 to work, you can map the host's port 3001 to the container's port 8000:
+
+```console
+$ docker run --publish 3001:8000 docker-rust-image-dhi
+```
+
+Now, rerun the curl command. Remember to open a new terminal.
+
+```console
+$ curl http://localhost:3001
+```
+
+You should see output like the following.
+
+```console
+Hello, Docker!
+```
+
+Success! You were able to connect to the application running inside of your container on port 8000. Switch back to the terminal where your container is running and stop it.
+
+Press ctrl-c to stop the container.
+
+### Run in detached mode
+
+This is great so far, but your sample application is a web server and you don't have to be connected to the container. Docker can run your container in detached mode or in the background. To do this, you can use the `--detach` or `-d` for short. Docker starts your container the same as before but this time will "detach" from the container and return you to the terminal prompt.
+
+```console
+$ docker run -d -p 3001:8000 docker-rust-image-dhi
+3e4830e7f01304811d97dd3469d47a0c7a916a8b6c28ce0ef19c6f689a521144
+```
+
+Docker started your container in the background and printed the Container ID on the terminal.
+
+Again, make sure that your container is running properly. Run the curl command again.
+
+```console
+$ curl http://localhost:3001
+```
+
+You should see output like the following.
+
+```console
+Hello, Docker!
+```
+
+### List containers
+
+Since you ran your container in the background, how do you know if your container is running or what other containers are running on your machine? Well, to see a list of containers running on your machine, run `docker ps`. This is similar to how you use the ps command in Linux to see a list of processes.
+
+You should see output like the following.
+
+```console
+CONTAINER ID   IMAGE                   COMMAND                  CREATED          STATUS          PORTS                                         NAMES
+3e4830e7f013   docker-rust-image-dhi   "/server"                23 seconds ago   Up 22 seconds   0.0.0.0:3001->8000/tcp, [::]:3001->8000/tcp   youthful_lamport
+```
+
+The `docker ps` command provides a bunch of information about your running containers. You can see the container ID, the image running inside the container, the command that was used to start the container, when it was created, the status, ports that were exposed, and the name of the container.
+
+You are probably wondering where the name of your container is coming from. Since you didn’t provide a name for the container when you started it, Docker generated a random name. You’ll fix this in a minute, but first you need to stop the container. To stop the container, run the `docker stop` command which does just that, stops the container. You need to pass the name of the container or you can use the container ID.
+
+```console
+$ docker stop youthful_lamport
+youthful_lamport
+```
+
+Now, rerun the `docker ps` command to see a list of running containers.
+
+```console
+$ docker ps
+CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
+```
+
+### Stop, start, and name containers
+
+You can start, stop, and restart Docker containers. When you stop a container, it's not removed, but the status is changed to stopped and the process inside the container is stopped. When you ran the `docker ps` command in the previous module, the default output only shows running containers. When you pass the `--all` or `-a` for short, you see all containers on your machine, irrespective of their start or stop status.
+
+```console
+$ docker ps -a
+CONTAINER ID   IMAGE                   COMMAND                  CREATED              STATUS                          PORTS                                         NAMES
+3e4830e7f013   docker-rust-image-dhi   "/server"                About a minute ago   Exited (0) 28 seconds ago                                                     youthful_lamport
+60009b7eaf40   docker-rust-image-dhi   "/server"                2 minutes ago        Exited (0) About a minute ago                                                 sharp_noyce
+152e1d7d9eea   docker-rust-image-dhi   "/server ."              4 minutes ago        Exited (0) 2 minutes ago                                                      magical_bhabha
+```
+
+You should now see several containers listed. These are containers that you started and stopped but you haven't removed.
+
+Restart the container that you just stopped. Locate the name of the container you just stopped and replace the name of the container in following restart command.
+
+```console
+$ docker restart youthful_lamport
+```
+
+Now list all the containers again using the `docker ps --all` command.
+
+```console
+$ docker ps --all
+CONTAINER ID   IMAGE                   COMMAND                  CREATED             STATUS                         PORTS                                         NAMES
+3e4830e7f013   docker-rust-image-dhi   "/server"                3 minutes ago       Up 7 seconds                   0.0.0.0:3001->8000/tcp, [::]:3001->8000/tcp   youthful_lamport
+60009b7eaf40   docker-rust-image-dhi   "/server"                4 minutes ago       Exited (0) 3 minutes ago                                                     sharp_noyce
+152e1d7d9eea   docker-rust-image-dhi   "/server ."              5 minutes ago       Exited (0) 4 minutes ago                                                     magical_bhabha
+```
+
+Notice that the container you just restarted has been started in detached mode. Also, observe the status of the container is "Up X seconds". When you restart a container, it starts with the same flags or commands that it was originally started with.
+
+Now, stop and remove all of your containers and take a look at fixing the random naming issue. Stop the container you just started. Find the name of your running container and replace the name in the following command with the name of the container on your system.
+
+```console
+$ docker stop youthful_lamport
+youthful_lamport
+```
+
+Now that you have stopped all of your containers, remove them. When you remove a container, it's no longer running, nor is it in the stopped status, but the process inside the container has been stopped and the metadata for the container has been removed.
+
+To remove a container, run the `docker rm` command with the container name. You can pass multiple container names to the command using a single command. Again, replace the container names in the following command with the container names from your system.
+
+```console
+$ docker rm youthful_lamport friendly_montalcini tender_bose
+youthful_lamport
+sharp_noyce
+magical_bhabha
+```
+
+Run the `docker ps --all` command again to see that Docker removed all containers.
+
+Now, it's time to address the random naming issue. Standard practice is to name your containers for the simple reason that it's easier to identify what's running in the container and what application or service it's associated with.
+
+To name a container, pass the `--name` flag to the `docker run` command.
+
+```console
+$ docker run -d -p 3001:8000 --name docker-rust-container docker-rust-image-dhi
+1aa5d46418a68705c81782a58456a4ccdb56a309cb5e6bd399478d01eaa5cdda
+$ docker ps
+CONTAINER ID   IMAGE                   COMMAND                  CREATED         STATUS         PORTS                                         NAMES
+219b2e3c7c38   docker-rust-image-dhi   "/server"                6 seconds ago   Up 5 seconds   0.0.0.0:3001->8000/tcp, [::]:3001->8000/tcp   docker-rust-container
+```
+
+Now you can identify your container based on the name.
+
+## Develop your Rust application
+
+### Prerequisites
+
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
+- You have completed the walkthroughs in the Docker Desktop [Learning Center](/manuals/desktop/use-desktop/_index.md) to learn about Docker concepts.
+- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
+
+### Overview
+
+In this section, you’ll learn how to use volumes and networking in Docker. You’ll also use Docker to build your images and Docker Compose to make everything a whole lot easier.
+
+First, you’ll take a look at running a database in a container and how you can use volumes and networking to persist your data and let your application talk with the database. Then you’ll pull everything together into a Compose file which lets you set up and run a local development environment with one command.
+
+### Run a database in a container
+
+Instead of downloading PostgreSQL, installing, configuring, and then running the PostgreSQL database as a service, you can use the Docker Official Image for PostgreSQL and run it in a container.
+
+Before you run PostgreSQL in a container, create a volume that Docker can manage to store your persistent data and configuration. Use the named volumes feature that Docker provides instead of using bind mounts.
+
+Run the following command to create your volume.
+
+```console
+$ docker volume create db-data
+```
+
+Now create a network that your application and database will use to talk to each other. The network is called a user-defined bridge network and gives you a nice DNS lookup service which you can use when creating your connection string.
+
+```console
+$ docker network create postgresnet
+```
+
+Now you can run PostgreSQL in a container and attach to the volume and network that you created previously. Docker pulls the image from Hub and runs it for you locally.
+In the following command, option `--mount` is for starting the container with a volume. For more information, see [Docker volumes](/manuals/engine/storage/volumes.md).
+
+```console
+$ docker run --rm -d --mount \
+  "type=volume,src=db-data,target=/var/lib/postgresql" \
+  -p 5432:5432 \
+  --network postgresnet \
+  --name db \
+  -e POSTGRES_PASSWORD=mysecretpassword \
+  -e POSTGRES_DB=example \
+  postgres:18
+```
+
+Now, make sure that your PostgreSQL database is running and that you can connect to it. Connect to the running PostgreSQL database inside the container.
+
+```console
+$ docker exec -it db psql -U postgres
+```
+
+You should see output like the following.
+
+```console
+psql (15.3 (Debian 15.3-1.pgdg110+1))
+Type "help" for help.
+
+postgres=#
+```
+
+In the previous command, you logged in to the PostgreSQL database by passing the `psql` command to the `db` container. Press ctrl-d to exit the PostgreSQL interactive terminal.
+
+### Get and run the sample application
+
+For the sample application, you'll use a variation of the backend from the react-rust-postgres application from [Awesome Compose](https://github.com/docker/awesome-compose/tree/master/react-rust-postgres).
+
+1. Clone the sample application repository using the following command.
+
+   ```console
+   $ git clone https://github.com/docker/docker-rust-postgres
+   ```
+
+2. In the cloned repository's directory, create a `Dockerfile`. This application includes a `migrations` directory (in addition to `src`) to initialize the database, so the Dockerfile includes a bind mount for that directory in the build stage.
+
+   ```dockerfile {hl_lines="28"}
+   # syntax=docker/dockerfile:1
+
+   # Comments are provided throughout this file to help you get started.
+   # If you need more help, visit the Dockerfile reference guide at
+   # https://docs.docker.com/reference/dockerfile/
+
+   ################################################################################
+   # Create a stage for building the application.
+
+   ARG RUST_VERSION=1.70.0
+   ARG APP_NAME=react-rust-postgres
+   FROM rust:${RUST_VERSION}-slim-bullseye AS build
+   ARG APP_NAME
+   WORKDIR /app
+
+   # Build the application.
+   # Leverage a cache mount to /var/cache/cargo for downloaded dependencies
+   # and a cache mount to /app/target/ for compiled dependencies which will
+   # speed up subsequent builds.
+   # Leverage a bind mount to the src directory to avoid having to copy the
+   # source code into the container. Once built, copy the executable to an
+   # output directory before the cache mounted /app/target is unmounted.
+   RUN --mount=type=bind,source=src,target=src \
+       --mount=type=bind,source=Cargo.toml,target=Cargo.toml \
+       --mount=type=bind,source=Cargo.lock,target=Cargo.lock \
+       --mount=type=cache,target=/app/target/ \
+       --mount=type=cache,target=/var/cache/cargo \
+       --mount=type=bind,source=migrations,target=migrations \
+       <<EOF
+   set -e
+   CARGO_HOME=/var/cache/cargo cargo build --locked --release
+   cp ./target/release/$APP_NAME /bin/server
+   EOF
+
+   ################################################################################
+   # Create a new stage for running the application that contains the minimal
+   # runtime dependencies for the application. This often uses a different base
+   # image from the build stage where the necessary files are copied from the build
+   # stage.
+   #
+   # The example below uses the debian bullseye image as the foundation for    running the app.
+   # By specifying the "bullseye-slim" tag, it will also use whatever happens to    be the
+   # most recent version of that tag when you build your Dockerfile. If
+   # reproducibility is important, consider using a digest
+   # (e.g.,    debian@sha256:ac707220fbd7b67fc19b112cee8170b41a9e97f703f588b2cdbbcdcecdd8af57).
+   FROM debian:bullseye-slim AS final
+
+   # Create a non-privileged user that the app will run under.
+   # See https://docs.docker.com/develop/develop-images/dockerfile_best-practices/   #user
+   ARG UID=10001
+   RUN adduser \
+       --disabled-password \
+       --gecos "" \
+       --home "/nonexistent" \
+       --shell "/sbin/nologin" \
+       --no-create-home \
+       --uid "${UID}" \
+       appuser
+   USER appuser
+
+   # Copy the executable from the "build" stage.
+   COPY --from=build /bin/server /bin/
+
+   # Expose the port that the application listens on.
+   EXPOSE 8000
+
+   # What the container should run when it is started.
+   CMD ["/bin/server"]
+   ```
+
+3. In the cloned repository's directory, run `docker build` to build the image.
+
+   ```console
+   $ docker build -t rust-backend-image .
+   ```
+
+4. Run `docker run` with the following options to run the image as a container on the same network as the database.
+
+   ```console
+   $ docker run \
+     --rm -d \
+     --network postgresnet \
+     --name docker-develop-rust-container \
+     -p 3001:8000 \
+     -e PG_DBNAME=example \
+     -e PG_HOST=db \
+     -e PG_USER=postgres \
+     -e PG_PASSWORD=mysecretpassword \
+     -e ADDRESS=0.0.0.0:8000 \
+     -e RUST_LOG=debug \
+     rust-backend-image
+   ```
+
+5. Curl the application to verify that it connects to the database.
+
+   ```console
+   $ curl http://localhost:3001/users
+   ```
+
+   You should get a response like the following.
+
+   ```json
+   [{ "id": 1, "login": "root" }]
+   ```
+
+### Use Compose to develop locally
+
+In the cloned repository's directory, create a `compose.yaml` file. Using Compose, you don't have to type all the parameters to pass to the `docker run` command — you can declare them in the file instead.
+
+You need to update the following items in the `compose.yaml` file:
+
+- Uncomment all of the database instructions.
+- Add the environment variables under the server service.
+
+The following is the updated `compose.yaml` file.
+
+```yaml {hl_lines=["17-23","30-55"]}
+# Comments are provided throughout this file to help you get started.
+# If you need more help, visit the Docker compose reference guide at
+# https://docs.docker.com/reference/compose-file/
+
+# Here the instructions define your application as a service called "server".
+# This service is built from the Dockerfile in the current directory.
+# You can add other services your application may depend on here, such as a
+# database or a cache. For examples, see the Awesome Compose repository:
+# https://github.com/docker/awesome-compose
+services:
+  server:
+    build:
+      context: .
+      target: final
+    ports:
+      - 8000:8000
+    environment:
+      - PG_DBNAME=example
+      - PG_HOST=db
+      - PG_USER=postgres
+      - PG_PASSWORD=mysecretpassword
+      - ADDRESS=0.0.0.0:8000
+      - RUST_LOG=debug
+    # The commented out section below is an example of how to define a PostgreSQL
+    # database that your application can use. `depends_on` tells Docker Compose to
+    # start the database before your application. The `db-data` volume persists the
+    # database data between container restarts. The `db-password` secret is used
+    # to set the database password. You must create `db/password.txt` and add
+    # a password of your choosing to it before running `docker compose up`.
+    depends_on:
+      db:
+        condition: service_healthy
+  db:
+    image: postgres:18
+    restart: always
+    user: postgres
+    secrets:
+      - db-password
+    volumes:
+      - db-data:/var/lib/postgresql
+    environment:
+      - POSTGRES_DB=example
+      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
+    expose:
+      - 5432
+    healthcheck:
+      test: ["CMD", "pg_isready"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+volumes:
+  db-data:
+secrets:
+  db-password:
+    file: db/password.txt
+```
+
+Note that the file doesn't specify a network for those 2 services. When you use Compose, it automatically creates a network and connects the services to it. For more information see [Networking in Compose](/manuals/compose/how-tos/networking.md).
+
+Before you run the application using Compose, notice that this Compose file specifies a `password.txt` file to hold the database's password. You must create this file as it's not included in the source repository.
+
+In the cloned repository's directory, create a new directory named `db` and inside that directory create a file named `password.txt` that contains the password for the database. Using your favorite IDE or text editor, add the following contents to the `password.txt` file.
+
+```text
+mysecretpassword
+```
+
+If you have any other containers running from the previous sections, [stop](#stop-start-and-name-containers) them now.
+
+Now, run the following `docker compose up` command to start your application.
+
+```console
+$ docker compose up --build
+```
+
+The command passes the `--build` flag so Docker will compile your image and then start the containers.
+
+Now test your API endpoint. Open a new terminal then make a request to the server using the curl commands:
+
+```console
+$ curl http://localhost:8000/users
+```
+
+You should receive the following response:
+
+```json
+[{ "id": 1, "login": "root" }]
+```
+
+### Summary
+
+In this section, you took a look at setting up your Compose file to run your Rust application and database with a single command.
+
+Related information:
+
+- [Docker volumes](/manuals/engine/storage/volumes.md)
+- [Compose overview](/manuals/compose/_index.md)
diff --git a/content/guides/rust/_index.md b/content/guides/rust/_index.md
deleted file mode 100644
index 2a1c1c3d121c..000000000000
--- a/content/guides/rust/_index.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Rust language-specific guide
-linkTitle: Rust
-description: Containerize Rust apps using Docker
-keywords: Docker, getting started, Rust, language
-summary: |
-  This guide covers how to containerize Rust applications using Docker.
-toc_min: 1
-toc_max: 2
-aliases:
-  - /language/rust/
-  - /guides/language/rust/
-languages: [rust]
-params:
-  time: 20 minutes
----
-
-The Rust language-specific guide teaches you how to create a containerized Rust application using Docker. In this guide, you'll learn how to:
-
-- Containerize a Rust application
-- Build an image and run the newly built image as a container
-- Set up volumes and networking
-- Orchestrate containers using Compose
-- Use containers for development
-- Configure a CI/CD pipeline for your application using GitHub Actions
-- Deploy your containerized Rust application locally to Kubernetes to test and debug your deployment
-
-After completing the Rust modules, you should be able to containerize your own Rust application based on the examples and instructions provided in this guide.
-
-Start with building your first Rust image.
diff --git a/content/guides/rust/build-images.md b/content/guides/rust/build-images.md
deleted file mode 100644
index d2e414274728..000000000000
--- a/content/guides/rust/build-images.md
+++ /dev/null
@@ -1,188 +0,0 @@
----
-title: Build your Rust image
-linkTitle: Build images
-weight: 5
-keywords: rust, build, images, dockerfile
-description: Learn how to build your first Rust Docker image
-aliases:
-  - /language/rust/build-images/
-  - /guides/language/rust/build-images/
----
-
-## Prerequisites
-
-- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
-- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
-
-## Overview
-
-This guide walks you through building your first Rust image. An image
-includes everything needed to run an application - the code or binary, runtime,
-dependencies, and any other file system objects required.
-
-## Get the sample application
-
-Clone the sample application to use with this guide. Open a terminal, change directory to a directory that you want to work in, and run the following command to clone the repository:
-
-```console
-$ git clone https://github.com/docker/docker-rust-hello && cd docker-rust-hello
-```
-
-## Create a Dockerfile for Rust
-
-Now that you have an application, you can use `docker init` to create a
-Dockerfile for it. Inside the `docker-rust-hello` directory, run the `docker
-init` command. `docker init` provides some default configuration, but you'll
-need to answer a few questions about your application. Refer to the following
-example to answer the prompts from `docker init` and use the same answers for
-your prompts.
-
-```console
-$ docker init
-Welcome to the Docker Init CLI!
-
-This utility will walk you through creating the following files with sensible defaults for your project:
-  - .dockerignore
-  - Dockerfile
-  - compose.yaml
-  - README.Docker.md
-
-Let's get started!
-
-? What application platform does your project use? Rust
-? What version of Rust do you want to use? 1.70.0
-? What port does your server listen on? 8000
-```
-
-You should now have the following new files in your `docker-rust-hello`
-directory:
-
-- Dockerfile
-- .dockerignore
-- compose.yaml
-- README.Docker.md
-
-For building an image, only the Dockerfile is necessary. Open the Dockerfile
-in your favorite IDE or text editor and see what it contains. To learn more
-about Dockerfiles, see the [Dockerfile reference](/reference/dockerfile.md).
-
-## .dockerignore file
-
-When you run `docker init`, it also creates a [`.dockerignore`](/reference/dockerfile.md#dockerignore-file) file. Use the `.dockerignore` file to specify patterns and paths that you don't want copied into the image in order to keep the image as small as possible. Open up the `.dockerignore` file in your favorite IDE or text editor and see what's inside already.
-
-## Build an image
-
-Now that you’ve created the Dockerfile, you can build the image. To do this, use
-the `docker build` command. The `docker build` command builds Docker images from
-a Dockerfile and a context. A build's context is the set of files located in
-the specified PATH or URL. The Docker build process can access any of the files
-located in this context.
-
-The build command optionally takes a `--tag` flag. The tag sets the name of the
-image and an optional tag in the format `name:tag`. If you don't pass a tag,
-Docker uses "latest" as its default tag.
-
-Build the Docker image.
-
-```console
-$ docker build --tag docker-rust-image .
-```
-
-You should see output like the following.
-
-```console
-[+] Building 62.6s (14/14) FINISHED
- => [internal] load .dockerignore                                                                                                    0.1s
- => => transferring context: 2B                                                                                                      0.0s
- => [internal] load build definition from Dockerfile                                                                                 0.1s
- => => transferring dockerfile: 2.70kB                                                                                               0.0s
- => resolve image config for docker.io/docker/dockerfile:1                                                                           2.3s
- => CACHED docker-image://docker.io/docker/dockerfile:1@sha256:39b85bbfa7536a5feceb7372a0817649ecb2724562a38360f4d6a7782a409b14      0.0s
- => [internal] load metadata for docker.io/library/debian:bullseye-slim                                                              1.9s
- => [internal] load metadata for docker.io/library/rust:1.70.0-slim-bullseye                                                         1.7s
- => [build 1/3] FROM docker.io/library/rust:1.70.0-slim-bullseye@sha256:585eeddab1ec712dade54381e115f676bba239b1c79198832ddda397c1f  0.0s
- => [internal] load build context                                                                                                    0.0s
- => => transferring context: 35.29kB                                                                                                 0.0s
- => [final 1/3] FROM docker.io/library/debian:bullseye-slim@sha256:7606bef5684b393434f06a50a3d1a09808fee5a0240d37da5d181b1b121e7637  0.0s
- => CACHED [build 2/3] WORKDIR /app                                                                                                  0.0s
- => [build 3/3] RUN --mount=type=bind,source=src,target=src     --mount=type=bind,source=Cargo.toml,target=Cargo.toml     --mount=  57.7s
- => CACHED [final 2/3] RUN adduser     --disabled-password     --gecos ""     --home "/nonexistent"     --shell "/sbin/nologin"      0.0s
- => CACHED [final 3/3] COPY --from=build /bin/server /bin/                                                                           0.0s
- => exporting to image                                                                                                               0.0s
- => => exporting layers                                                                                                              0.0s
- => => writing image sha256:f1aa4a9f58d2ecf73b0c2b7f28a6646d9849b32c3921e42adc3ab75e12a3de14                                         0.0s
- => => naming to docker.io/library/docker-rust-image
-```
-
-## View local images
-
-To see a list of images you have on your local machine, you have two options. One is to use the Docker CLI and the other is to use [Docker Desktop](/manuals/desktop/use-desktop/images.md). As you are working in the terminal already, take a look at listing images using the CLI.
-
-To list images, run the `docker images` command.
-
-```console
-$ docker images
-REPOSITORY                TAG               IMAGE ID       CREATED         SIZE
-docker-rust-image         latest            8cae92a8fbd6   3 minutes ago   123MB
-```
-
-You should see at least one image listed, including the image you just built `docker-rust-image:latest`.
-
-## Tag images
-
-As mentioned earlier, an image name is made up of slash-separated name components. Name components may contain lowercase letters, digits, and separators. A separator can include a period, one or two underscores, or one or more dashes. A name component may not start or end with a separator.
-
-An image is made up of a manifest and a list of layers. Don't worry too much about manifests and layers at this point other than a "tag" points to a combination of these artifacts. You can have multiple tags for an image. Create a second tag for the image you built and take a look at its layers.
-
-To create a new tag for the image you built, run the following command.
-
-```console
-$ docker tag docker-rust-image:latest docker-rust-image:v1.0.0
-```
-
-The `docker tag` command creates a new tag for an image. It doesn't create a new image. The tag points to the same image and is just another way to reference the image.
-
-Now, run the `docker images` command to see a list of the local images.
-
-```console
-$ docker images
-REPOSITORY                TAG               IMAGE ID       CREATED         SIZE
-docker-rust-image         latest            8cae92a8fbd6   4 minutes ago   123MB
-docker-rust-image         v1.0.0            8cae92a8fbd6   4 minutes ago   123MB
-rust                      latest            be5d294735c6   4 minutes ago   113MB
-```
-
-You can see that two images start with `docker-rust-image`. You know they're the same image because if you take a look at the `IMAGE ID` column, you can see that the values are the same for the two images.
-
-Remove the tag you just created. To do this, use the `rmi` command. The `rmi` command stands for remove image.
-
-```console
-$ docker rmi docker-rust-image:v1.0.0
-Untagged: docker-rust-image:v1.0.0
-```
-
-Note that the response from Docker tells you that Docker didn't remove the image, but only "untagged" it. You can check this by running the `docker images` command.
-
-```console
-$ docker images
-REPOSITORY               TAG               IMAGE ID       CREATED         SIZE
-docker-rust-image        latest            8cae92a8fbd6   6 minutes ago   123MB
-rust                     latest            be5d294735c6   6 minutes ago   113MB
-```
-
-Docker removed the image tagged with `:v1.0.0`, but the `docker-rust-image:latest` tag is available on your machine.
-
-## Summary
-
-This section showed how you can use `docker init` to create a Dockerfile and .dockerignore file for a Rust application. It then showed you how to build an image. And finally, it showed you how to tag an image and list all images.
-
-Related information:
-
-- [Dockerfile reference](/reference/dockerfile.md)
-- [.dockerignore file](/reference/dockerfile.md#dockerignore-file)
-- [docker init CLI reference](/reference/cli/docker/init.md)
-- [docker build CLI reference](/reference/cli/docker/buildx/build.md)
-
-## Next steps
-
-In the next section learn how to run your image as a container.
diff --git a/content/guides/rust/configure-ci-cd.md b/content/guides/rust/configure-ci-cd.md
deleted file mode 100644
index 3f7241cb67f5..000000000000
--- a/content/guides/rust/configure-ci-cd.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-title: Configure CI/CD for your Rust application
-linkTitle: Configure CI/CD
-weight: 40
-keywords: rust, CI/CD, local, development
-description: Learn how to Configure CI/CD for your application
-aliases:
-  - /language/rust/configure-ci-cd/
-  - /guides/language/rust/configure-ci-cd/
----
-
-## Prerequisites
-
-Complete the previous sections of this guide, starting with [Develop your Rust application](develop.md). You must have a [GitHub](https://github.com/signup) account and a [Docker](https://hub.docker.com/signup) account to complete this section.
-
-## Overview
-
-In this section, you'll learn how to set up and use GitHub Actions to build and push your Docker image to Docker Hub. You will complete the following steps:
-
-1. Create a new repository on GitHub.
-2. Define the GitHub Actions workflow.
-3. Run the workflow.
-
-## Step one: Create the repository
-
-Create a GitHub repository, configure the Docker Hub credentials, and push your source code.
-
-1. [Create a new repository](https://github.com/new) on GitHub.
-
-2. Open the repository **Settings**, and go to **Secrets and variables** >
-   **Actions**.
-
-3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value.
-
-4. Create a new [Personal Access Token (PAT)](/manuals/security/for-developers/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write.
-
-5. Add the PAT as a **Repository secret** in your GitHub repository, with the name
-   `DOCKERHUB_TOKEN`.
-
-6. In your local repository on your machine, run the following command to change
-   the origin to the repository you just created. Make sure you change
-   `your-username` to your GitHub username and `your-repository` to the name of
-   the repository you created.
-
-   ```console
-   $ git remote set-url origin https://github.com/your-username/your-repository.git
-   ```
-
-7. Run the following commands to stage, commit, and push your local repository to GitHub.
-
-   ```console
-   $ git add -A
-   $ git commit -m "my commit"
-   $ git push -u origin main
-   ```
-
-## Step two: Set up the workflow
-
-Set up your GitHub Actions workflow for building, testing, and pushing the image
-to Docker Hub.
-
-1. Go to your repository on GitHub and then select the **Actions** tab.
-
-2. Select **set up a workflow yourself**.
-
-   This takes you to a page for creating a new GitHub actions workflow file in
-   your repository, under `.github/workflows/main.yml` by default.
-
-3. In the editor window, copy and paste the following YAML configuration.
-
-   ```yaml
-   name: ci
-
-   on:
-     push:
-       branches:
-         - main
-
-   jobs:
-     build:
-       runs-on: ubuntu-latest
-       steps:
-         - name: Login to Docker Hub
-           uses: docker/login-action@v3
-           with:
-             username: ${{ vars.DOCKER_USERNAME }}
-             password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-         - name: Set up Docker Buildx
-           uses: docker/setup-buildx-action@v3
-
-         - name: Build and push
-           uses: docker/build-push-action@v6
-           with:
-             push: true
-             tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest
-   ```
-
-   For more information about the YAML syntax for `docker/build-push-action`,
-   refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md).
-
-## Step three: Run the workflow
-
-Save the workflow file and run the job.
-
-1. Select **Commit changes...** and push the changes to the `main` branch.
-
-   After pushing the commit, the workflow starts automatically.
-
-2. Go to the **Actions** tab. It displays the workflow.
-
-   Selecting the workflow shows you the breakdown of all the steps.
-
-3. When the workflow is complete, go to your
-   [repositories on Docker Hub](https://hub.docker.com/repositories).
-
-   If you see the new repository in that list, it means the GitHub Actions
-   successfully pushed the image to Docker Hub.
-
-## Summary
-
-In this section, you learned how to set up a GitHub Actions workflow for your Rust application.
-
-Related information:
-
-- [Introduction to GitHub Actions](/guides/gha.md)
-- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md)
-- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
-
-## Next steps
-
-Next, learn how you can locally test and debug your workloads on Kubernetes before deploying.
diff --git a/content/guides/rust/deploy.md b/content/guides/rust/deploy.md
deleted file mode 100644
index ac48e760ace8..000000000000
--- a/content/guides/rust/deploy.md
+++ /dev/null
@@ -1,238 +0,0 @@
----
-title: Test your Rust deployment
-linkTitle: Test your deployment
-weight: 50
-keywords: deploy, kubernetes, rust
-description: Learn how to test your Rust deployment locally using Kubernetes
-aliases:
-  - /language/rust/deploy/
-  - /guides/language/rust/deploy/
----
-
-## Prerequisites
-
-- Complete the previous sections of this guide, starting with [Develop your Rust application](develop.md).
-- [Turn on Kubernetes](/manuals/desktop/features/kubernetes.md#install-and-turn-on-kubernetes) in Docker Desktop.
-
-## Overview
-
-In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This lets you to test and debug your workloads on Kubernetes locally before deploying.
-
-## Create a Kubernetes YAML file
-
-In your `docker-rust-postgres` directory, create a file named
-`docker-rust-kubernetes.yaml`. Open the file in an IDE or text editor and add
-the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker
-username and the name of the repository that you created in [Configure CI/CD for
-your Rust application](configure-ci-cd.md).
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  labels:
-    service: server
-  name: server
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      service: server
-  strategy: {}
-  template:
-    metadata:
-      labels:
-        service: server
-    spec:
-      initContainers:
-        - name: wait-for-db
-          image: busybox:1.28
-          command:
-            [
-              "sh",
-              "-c",
-              'until nc -zv db 5432; do echo "waiting for db"; sleep 2; done;',
-            ]
-      containers:
-        - image: DOCKER_USERNAME/REPO_NAME
-          name: server
-          imagePullPolicy: Always
-          ports:
-            - containerPort: 8000
-              hostPort: 5000
-              protocol: TCP
-          env:
-            - name: ADDRESS
-              value: 0.0.0.0:8000
-            - name: PG_DBNAME
-              value: example
-            - name: PG_HOST
-              value: db
-            - name: PG_PASSWORD
-              value: mysecretpassword
-            - name: PG_USER
-              value: postgres
-            - name: RUST_LOG
-              value: debug
-          resources: {}
-      restartPolicy: Always
-status: {}
----
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  labels:
-    service: db
-  name: db
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      service: db
-  strategy:
-    type: Recreate
-  template:
-    metadata:
-      labels:
-        service: db
-    spec:
-      containers:
-        - env:
-            - name: POSTGRES_DB
-              value: example
-            - name: POSTGRES_PASSWORD
-              value: mysecretpassword
-            - name: POSTGRES_USER
-              value: postgres
-          image: postgres
-          name: db
-          ports:
-            - containerPort: 5432
-              protocol: TCP
-          resources: {}
-      restartPolicy: Always
-status: {}
----
-apiVersion: v1
-kind: Service
-metadata:
-  labels:
-    service: server
-  name: server
-  namespace: default
-spec:
-  type: NodePort
-  ports:
-    - name: "5000"
-      port: 5000
-      targetPort: 8000
-      nodePort: 30001
-  selector:
-    service: server
-status:
-  loadBalancer: {}
----
-apiVersion: v1
-kind: Service
-metadata:
-  labels:
-    service: db
-  name: db
-  namespace: default
-spec:
-  ports:
-    - name: "5432"
-      port: 5432
-      targetPort: 5432
-  selector:
-    service: db
-status:
-  loadBalancer: {}
-```
-
-In this Kubernetes YAML file, there are four objects, separated by the `---`. In addition to a Service and Deployment for the database, the other two objects are:
-
-- A Deployment, describing a scalable group of identical pods. In this case,
-  you'll get just one replica, or copy of your pod. That pod, which is
-  described under `template`, has just one container in it. The container is
-  created from the image built by GitHub Actions in [Configure CI/CD for your
-  Rust application](configure-ci-cd.md).
-- A NodePort service, which will route traffic from port 30001 on your host to
-  port 5000 inside the pods it routes to, allowing you to reach your app
-  from the network.
-
-To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/).
-
-## Deploy and check your application
-
-1. In a terminal, navigate to `docker-rust-postgres` and deploy your application
-   to Kubernetes.
-
-   ```console
-   $ kubectl apply -f docker-rust-kubernetes.yaml
-   ```
-
-   You should see output that looks like the following, indicating your Kubernetes objects were created successfully.
-
-   ```shell
-   deployment.apps/server created
-   deployment.apps/db created
-   service/server created
-   service/db created
-   ```
-
-2. Make sure everything worked by listing your deployments.
-
-   ```console
-   $ kubectl get deployments
-   ```
-
-   Your deployment should be listed as follows:
-
-   ```shell
-   NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
-   db       1/1     1            1           2m21s
-   server   1/1     1            1           2m21s
-   ```
-
-   This indicates all of the pods you asked for in your YAML are up and running. Do the same check for your services.
-
-   ```console
-   $ kubectl get services
-   ```
-
-   You should get output like the following.
-
-   ```shell
-   NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
-   db           ClusterIP   10.105.167.81    <none>        5432/TCP         109s
-   kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP          9d
-   server       NodePort    10.101.235.213   <none>        5000:30001/TCP   109s
-   ```
-
-   In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP.
-
-3. In a terminal, curl the service.
-
-   ```console
-   $ curl http://localhost:30001/users
-   [{"id":1,"login":"root"}]
-   ```
-
-4. Run the following command to tear down your application.
-
-   ```console
-   $ kubectl delete -f docker-rust-kubernetes.yaml
-   ```
-
-## Summary
-
-In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine.
-
-Related information:
-
-- [Kubernetes documentation](https://kubernetes.io/docs/home/)
-- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/features/kubernetes.md)
-- [Swarm mode overview](/manuals/engine/swarm/_index.md)
diff --git a/content/guides/rust/develop.md b/content/guides/rust/develop.md
deleted file mode 100644
index 462fc229deb2..000000000000
--- a/content/guides/rust/develop.md
+++ /dev/null
@@ -1,328 +0,0 @@
----
-title: Develop your Rust application
-linkTitle: Develop your app
-weight: 20
-keywords: rust, local, development, run,
-description: Learn how to develop your Rust application locally.
-aliases:
-  - /language/rust/develop/
-  - /guides/language/rust/develop/
----
-
-## Prerequisites
-
-- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
-- You have completed the walkthroughs in the Docker Desktop [Learning Center](/manuals/desktop/use-desktop/_index.md) to learn about Docker concepts.
-- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
-
-## Overview
-
-In this section, you’ll learn how to use volumes and networking in Docker. You’ll also use Docker to build your images and Docker Compose to make everything a whole lot easier.
-
-First, you’ll take a look at running a database in a container and how you can use volumes and networking to persist your data and let your application talk with the database. Then you’ll pull everything together into a Compose file which lets you set up and run a local development environment with one command.
-
-## Run a database in a container
-
-Instead of downloading PostgreSQL, installing, configuring, and then running the PostgreSQL database as a service, you can use the Docker Official Image for PostgreSQL and run it in a container.
-
-Before you run PostgreSQL in a container, create a volume that Docker can manage to store your persistent data and configuration. Use the named volumes feature that Docker provides instead of using bind mounts.
-
-Run the following command to create your volume.
-
-```console
-$ docker volume create db-data
-```
-
-Now create a network that your application and database will use to talk to each other. The network is called a user-defined bridge network and gives you a nice DNS lookup service which you can use when creating your connection string.
-
-```console
-$ docker network create postgresnet
-```
-
-Now you can run PostgreSQL in a container and attach to the volume and network that you created previously. Docker pulls the image from Hub and runs it for you locally.
-In the following command, option `--mount` is for starting the container with a volume. For more information, see [Docker volumes](/manuals/engine/storage/volumes.md).
-
-```console
-$ docker run --rm -d --mount \
-  "type=volume,src=db-data,target=/var/lib/postgresql/data" \
-  -p 5432:5432 \
-  --network postgresnet \
-  --name db \
-  -e POSTGRES_PASSWORD=mysecretpassword \
-  -e POSTGRES_DB=example \
-  postgres
-```
-
-Now, make sure that your PostgreSQL database is running and that you can connect to it. Connect to the running PostgreSQL database inside the container.
-
-```console
-$ docker exec -it db psql -U postgres
-```
-
-You should see output like the following.
-
-```console
-psql (15.3 (Debian 15.3-1.pgdg110+1))
-Type "help" for help.
-
-postgres=#
-```
-
-In the previous command, you logged in to the PostgreSQL database by passing the `psql` command to the `db` container. Press ctrl-d to exit the PostgreSQL interactive terminal.
-
-## Get and run the sample application
-
-For the sample application, you'll use a variation of the backend from the react-rust-postgres application from [Awesome Compose](https://github.com/docker/awesome-compose/tree/master/react-rust-postgres).
-
-1. Clone the sample application repository using the following command.
-
-   ```console
-   $ git clone https://github.com/docker/docker-rust-postgres
-   ```
-
-2. In the cloned repository's directory, run `docker init` to create the necessary Docker files. Refer to the following example to answer the prompts from `docker init`.
-
-   ```console
-   $ docker init
-   Welcome to the Docker Init CLI!
-
-   This utility will walk you through creating the following files with sensible defaults for your project:
-     - .dockerignore
-     - Dockerfile
-     - compose.yaml
-     - README.Docker.md
-
-   Let's get started!
-
-   ? What application platform does your project use? Rust
-   ? What version of Rust do you want to use? 1.70.0
-   ? What port does your server listen on? 8000
-   ```
-
-3. In the cloned repository's directory, open the `Dockerfile` in an IDE or text editor to update it.
-
-   `docker init` handled creating most of the instructions in the Dockerfile, but you'll need to update it for your unique application. In addition to a `src` directory, this application includes a `migrations` directory to initialize the database. Add a bind mount for the `migrations` directory to the build stage in the Dockerfile. The following is the updated Dockerfile.
-
-   ```dockerfile {hl_lines="28"}
-   # syntax=docker/dockerfile:1
-
-   # Comments are provided throughout this file to help you get started.
-   # If you need more help, visit the Dockerfile reference guide at
-   # https://docs.docker.com/reference/dockerfile/
-
-   ################################################################################
-   # Create a stage for building the application.
-
-   ARG RUST_VERSION=1.70.0
-   ARG APP_NAME=react-rust-postgres
-   FROM rust:${RUST_VERSION}-slim-bullseye AS build
-   ARG APP_NAME
-   WORKDIR /app
-
-   # Build the application.
-   # Leverage a cache mount to /usr/local/cargo/registry/
-   # for downloaded dependencies and a cache mount to /app/target/ for
-   # compiled dependencies which will speed up subsequent builds.
-   # Leverage a bind mount to the src directory to avoid having to copy the
-   # source code into the container. Once built, copy the executable to an
-   # output directory before the cache mounted /app/target is unmounted.
-   RUN --mount=type=bind,source=src,target=src \
-       --mount=type=bind,source=Cargo.toml,target=Cargo.toml \
-       --mount=type=bind,source=Cargo.lock,target=Cargo.lock \
-       --mount=type=cache,target=/app/target/ \
-       --mount=type=cache,target=/usr/local/cargo/registry/ \
-       --mount=type=bind,source=migrations,target=migrations \
-       <<EOF
-   set -e
-   cargo build --locked --release
-   cp ./target/release/$APP_NAME /bin/server
-   EOF
-
-   ################################################################################
-   # Create a new stage for running the application that contains the minimal
-   # runtime dependencies for the application. This often uses a different base
-   # image from the build stage where the necessary files are copied from the build
-   # stage.
-   #
-   # The example below uses the debian bullseye image as the foundation for    running the app.
-   # By specifying the "bullseye-slim" tag, it will also use whatever happens to    be the
-   # most recent version of that tag when you build your Dockerfile. If
-   # reproducibility is important, consider using a digest
-   # (e.g.,    debian@sha256:ac707220fbd7b67fc19b112cee8170b41a9e97f703f588b2cdbbcdcecdd8af57).
-   FROM debian:bullseye-slim AS final
-
-   # Create a non-privileged user that the app will run under.
-   # See https://docs.docker.com/develop/develop-images/dockerfile_best-practices/   #user
-   ARG UID=10001
-   RUN adduser \
-       --disabled-password \
-       --gecos "" \
-       --home "/nonexistent" \
-       --shell "/sbin/nologin" \
-       --no-create-home \
-       --uid "${UID}" \
-       appuser
-   USER appuser
-
-   # Copy the executable from the "build" stage.
-   COPY --from=build /bin/server /bin/
-
-   # Expose the port that the application listens on.
-   EXPOSE 8000
-
-   # What the container should run when it is started.
-   CMD ["/bin/server"]
-   ```
-
-4. In the cloned repository's directory, run `docker build` to build the image.
-
-   ```console
-   $ docker build -t rust-backend-image .
-   ```
-
-5. Run `docker run` with the following options to run the image as a container on the same network as the database.
-
-   ```console
-   $ docker run \
-     --rm -d \
-     --network postgresnet \
-     --name docker-develop-rust-container \
-     -p 3001:8000 \
-     -e PG_DBNAME=example \
-     -e PG_HOST=db \
-     -e PG_USER=postgres \
-     -e PG_PASSWORD=mysecretpassword \
-     -e ADDRESS=0.0.0.0:8000 \
-     -e RUST_LOG=debug \
-     rust-backend-image
-   ```
-
-6. Curl the application to verify that it connects to the database.
-
-   ```console
-   $ curl http://localhost:3001/users
-   ```
-
-   You should get a response like the following.
-
-   ```json
-   [{ "id": 1, "login": "root" }]
-   ```
-
-## Use Compose to develop locally
-
-When you run `docker init`, in addition to a `Dockerfile`, it also creates a `compose.yaml` file.
-
-This Compose file is super convenient as you don't have to type all the parameters to pass to the `docker run` command. You can declaratively do that using a Compose file.
-
-In the cloned repository's directory, open the `compose.yaml` file in an IDE or text editor. `docker init` handled creating most of the instructions, but you'll need to update it for your unique application.
-
-You need to update the following items in the `compose.yaml` file:
-
-- Uncomment all of the database instructions.
-- Add the environment variables under the server service.
-
-The following is the updated `compose.yaml` file.
-
-```yaml {hl_lines=["17-23","30-55"]}
-# Comments are provided throughout this file to help you get started.
-# If you need more help, visit the Docker compose reference guide at
-# https://docs.docker.com/reference/compose-file/
-
-# Here the instructions define your application as a service called "server".
-# This service is built from the Dockerfile in the current directory.
-# You can add other services your application may depend on here, such as a
-# database or a cache. For examples, see the Awesome Compose repository:
-# https://github.com/docker/awesome-compose
-services:
-  server:
-    build:
-      context: .
-      target: final
-    ports:
-      - 8000:8000
-    environment:
-      - PG_DBNAME=example
-      - PG_HOST=db
-      - PG_USER=postgres
-      - PG_PASSWORD=mysecretpassword
-      - ADDRESS=0.0.0.0:8000
-      - RUST_LOG=debug
-    # The commented out section below is an example of how to define a PostgreSQL
-    # database that your application can use. `depends_on` tells Docker Compose to
-    # start the database before your application. The `db-data` volume persists the
-    # database data between container restarts. The `db-password` secret is used
-    # to set the database password. You must create `db/password.txt` and add
-    # a password of your choosing to it before running `docker compose up`.
-    depends_on:
-      db:
-        condition: service_healthy
-  db:
-    image: postgres
-    restart: always
-    user: postgres
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    environment:
-      - POSTGRES_DB=example
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-    expose:
-      - 5432
-    healthcheck:
-      test: ["CMD", "pg_isready"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-Note that the file doesn't specify a network for those 2 services. When you use Compose, it automatically creates a network and connects the services to it. For more information see [Networking in Compose](/manuals/compose/how-tos/networking.md).
-
-Before you run the application using Compose, notice that this Compose file specifies a `password.txt` file to hold the database's password. You must create this file as it's not included in the source repository.
-
-In the cloned repository's directory, create a new directory named `db` and inside that directory create a file named `password.txt` that contains the password for the database. Using your favorite IDE or text editor, add the following contents to the `password.txt` file.
-
-```text
-mysecretpassword
-```
-
-If you have any other containers running from the previous sections, [stop](./run-containers.md#stop-start-and-name-containers) them now.
-
-Now, run the following `docker compose up` command to start your application.
-
-```console
-$ docker compose up --build
-```
-
-The command passes the `--build` flag so Docker will compile your image and then start the containers.
-
-Now test your API endpoint. Open a new terminal then make a request to the server using the curl commands:
-
-```console
-$ curl http://localhost:8000/users
-```
-
-You should receive the following response:
-
-```json
-[{ "id": 1, "login": "root" }]
-```
-
-## Summary
-
-In this section, you took a look at setting up your Compose file to run your Rust application and database with a single command.
-
-Related information:
-
-- [Docker volumes](/manuals/engine/storage/volumes.md)
-- [Compose overview](/manuals/compose/_index.md)
-
-## Next steps
-
-In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions.
diff --git a/content/guides/rust/run-containers.md b/content/guides/rust/run-containers.md
deleted file mode 100644
index f02194d365ce..000000000000
--- a/content/guides/rust/run-containers.md
+++ /dev/null
@@ -1,205 +0,0 @@
----
-title: Run your Rust image as a container
-linkTitle: Run containers
-weight: 10
-keywords: rust, run, image, container,
-description: Learn how to run your Rust image as a container.
-aliases:
-  - /language/rust/run-containers/
-  - /guides/language/rust/run-containers/
----
-
-## Prerequisite
-
-You have completed [Build your Rust image](build-images.md) and you have built an image.
-
-## Overview
-
-A container is a normal operating system process except that Docker isolates this process so that it has its own file system, its own networking, and its own isolated process tree separate from the host.
-
-To run an image inside of a container, you use the `docker run` command. The `docker run` command requires one parameter which is the name of the image.
-
-## Run an image
-
-Use `docker run` to run the image you built in [Build your Rust image](build-images.md).
-
-```console
-$ docker run docker-rust-image
-```
-
-After running this command, you’ll notice that you weren't returned to the command prompt. This is because your application is a server that runs in a loop waiting for incoming requests without returning control back to the OS until you stop the container.
-
-Open a new terminal then make a request to the server using the `curl` command.
-
-```console
-$ curl http://localhost:8000
-```
-
-You should see output like the following.
-
-```console
-curl: (7) Failed to connect to localhost port 8000 after 2236 ms: Couldn't connect to server
-```
-
-As you can see, your `curl` command failed. This means you weren't able to connect to the localhost on port 8000. This is normal because your container is running in isolation which includes networking. Stop the container and restart with port 8000 published on your local network.
-
-To stop the container, press ctrl-c. This will return you to the terminal prompt.
-
-To publish a port for your container, you’ll use the `--publish` flag (`-p` for short) on the `docker run` command. The format of the `--publish` command is `[host port]:[container port]`. So, if you wanted to expose port 8000 inside the container to port 3001 outside the container, you would pass `3001:8000` to the `--publish` flag.
-
-You didn't specify a port when running the application in the container and the default is 8000. If you want your previous request going to port 8000 to work, you can map the host's port 3001 to the container's port 8000:
-
-```console
-$ docker run --publish 3001:8000 docker-rust-image
-```
-
-Now, rerun the curl command. Remember to open a new terminal.
-
-```console
-$ curl http://localhost:3001
-```
-
-You should see output like the following.
-
-```console
-Hello, Docker!
-```
-
-Success! You were able to connect to the application running inside of your container on port 8000. Switch back to the terminal where your container is running and stop it.
-
-Press ctrl-c to stop the container.
-
-## Run in detached mode
-
-This is great so far, but your sample application is a web server and you don't have to be connected to the container. Docker can run your container in detached mode or in the background. To do this, you can use the `--detach` or `-d` for short. Docker starts your container the same as before but this time will "detach" from the container and return you to the terminal prompt.
-
-```console
-$ docker run -d -p 3001:8000 docker-rust-image
-ce02b3179f0f10085db9edfccd731101868f58631bdf918ca490ff6fd223a93b
-```
-
-Docker started your container in the background and printed the Container ID on the terminal.
-
-Again, make sure that your container is running properly. Run the curl command again.
-
-```console
-$ curl http://localhost:3001
-```
-
-You should see output like the following.
-
-```console
-Hello, Docker!
-```
-
-## List containers
-
-Since you ran your container in the background, how do you know if your container is running or what other containers are running on your machine? Well, to see a list of containers running on your machine, run `docker ps`. This is similar to how you use the ps command in Linux to see a list of processes.
-
-You should see output like the following.
-
-```console
-CONTAINER ID   IMAGE                   COMMAND         CREATED         STATUS         PORTS                    NAMES
-3074745e412c   docker-rust-image       "/bin/server"   8 seconds ago   Up 7 seconds   0.0.0.0:3001->8000/tcp   wonderful_kalam
-```
-
-The `docker ps` command provides a bunch of information about your running containers. You can see the container ID, the image running inside the container, the command that was used to start the container, when it was created, the status, ports that were exposed, and the name of the container.
-
-You are probably wondering where the name of your container is coming from. Since you didn’t provide a name for the container when you started it, Docker generated a random name. You’ll fix this in a minute, but first you need to stop the container. To stop the container, run the `docker stop` command which does just that, stops the container. You need to pass the name of the container or you can use the container ID.
-
-```console
-$ docker stop wonderful_kalam
-wonderful_kalam
-```
-
-Now, rerun the `docker ps` command to see a list of running containers.
-
-```console
-$ docker ps
-CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
-```
-
-## Stop, start, and name containers
-
-You can start, stop, and restart Docker containers. When you stop a container, it's not removed, but the status is changed to stopped and the process inside the container is stopped. When you ran the `docker ps` command in the previous module, the default output only shows running containers. When you pass the `--all` or `-a` for short, you see all containers on your machine, irrespective of their start or stop status.
-
-```console
-$ docker ps -a
-CONTAINER ID   IMAGE                   COMMAND                  CREATED          STATUS                      PORTS
-     NAMES
-3074745e412c   docker-rust-image       "/bin/server"            3 minutes ago    Exited (0) 6 seconds ago
-     wonderful_kalam
-6cfa26e2e3c9   docker-rust-image       "/bin/server"            14 minutes ago   Exited (0) 5 minutes ago
-     friendly_montalcini
-4cbe94b2ea0e   docker-rust-image       "/bin/server"            15 minutes ago   Exited (0) 14 minutes ago
-     tender_bose
-```
-
-You should now see several containers listed. These are containers that you started and stopped but you haven't removed.
-
-Restart the container that you just stopped. Locate the name of the container you just stopped and replace the name of the container in following restart command.
-
-```console
-$ docker restart wonderful_kalam
-```
-
-Now list all the containers again using the `docker ps` command.
-
-```console
-$ docker ps --all
-CONTAINER ID   IMAGE                   COMMAND                  CREATED          STATUS                      PORTS
-     NAMES
-3074745e412c   docker-rust-image       "/bin/server"            6 minutes ago    Up 4 seconds                0.0.0.0:3001->8000/tcp           wonderful_kalam
-6cfa26e2e3c9   docker-rust-image       "/bin/server"            16 minutes ago   Exited (0) 7 minutes ago
-     friendly_montalcini
-4cbe94b2ea0e   docker-rust-image       "/bin/server"            18 minutes ago   Exited (0) 17 minutes ago
-     tender_bose
-```
-
-Notice that the container you just restarted has been started in detached mode. Also, observe the status of the container is "Up X seconds". When you restart a container, it starts with the same flags or commands that it was originally started with.
-
-Now, stop and remove all of your containers and take a look at fixing the random naming issue. Stop the container you just started. Find the name of your running container and replace the name in the following command with the name of the container on your system.
-
-```console
-$ docker stop wonderful_kalam
-wonderful_kalam
-```
-
-Now that you have stopped all of your containers, remove them. When you remove a container, it's no longer running, nor is it in the stopped status, but the process inside the container has been stopped and the metadata for the container has been removed.
-
-To remove a container, run the `docker rm` command with the container name. You can pass multiple container names to the command using a single command. Again, replace the container names in the following command with the container names from your system.
-
-```console
-$ docker rm wonderful_kalam friendly_montalcini tender_bose
-wonderful_kalam
-friendly_montalcini
-tender_bose
-```
-
-Run the `docker ps --all` command again to see that Docker removed all containers.
-
-Now, it's time to address the random naming issue. Standard practice is to name your containers for the simple reason that it's easier to identify what's running in the container and what application or service it's associated with.
-
-To name a container, you just need to pass the `--name` flag to the `docker run` command.
-
-```console
-$ docker run -d -p 3001:8000 --name docker-rust-container docker-rust-image
-1aa5d46418a68705c81782a58456a4ccdb56a309cb5e6bd399478d01eaa5cdda
-$ docker ps
-CONTAINER ID   IMAGE                   COMMAND         CREATED         STATUS         PORTS                    NAMES
-c68fa18de1f6   docker-rust-image       "/bin/server"   7 seconds ago   Up 6 seconds   0.0.0.0:3001->8000/tcp   docker-rust-container
-```
-
-That’s better! You can now easily identify your container based on the name.
-
-## Summary
-
-In this section, you took a look at running containers. You also took a look at managing containers by starting, stopping, and restarting them. And finally, you looked at naming your containers so they are more easily identifiable.
-
-Related information:
-
-- [docker run CLI reference](/reference/cli/docker/container/run.md)
-
-## Next steps
-
-In the next section, you’ll learn how to run a database in a container and connect it to a Rust application.
diff --git a/content/guides/sentiment-analysis.md b/content/guides/sentiment-analysis.md
index 725899efe9fc..c9883cf0af9e 100644
--- a/content/guides/sentiment-analysis.md
+++ b/content/guides/sentiment-analysis.md
@@ -6,11 +6,10 @@ description: Learn how to build and run a sentiment analysis application using P
 summary: |
   This guide demonstrates how to containerize sentiment analysis models using
   Docker.
-tags: [ai]
-languages: [python]
 aliases:
   - /guides/use-case/nlp/sentiment-analysis/
 params:
+  tags: [ai]
   time: 20 minutes
 ---
 
diff --git a/content/guides/swarm-deploy.md b/content/guides/swarm-deploy.md
deleted file mode 100644
index ff04acec9554..000000000000
--- a/content/guides/swarm-deploy.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: Deploy to Swarm
-keywords: swarm, swarm services, stacks
-description: Learn how to describe and deploy a simple application on Docker Swarm.
-aliases:
-  - /get-started/part4/
-  - /get-started/swarm-deploy/
-  - /guides/deployment-orchestration/swarm-deploy/
-summary: |
-  Discover how to deploy and manage Docker containers using Docker Swarm.
-tags: [deploy]
-params:
-  time: 10 minutes
----
-
-{{% include "swarm-mode.md" %}}
-
-## Prerequisites
-
-- Download and install Docker Desktop as described in [Get Docker](/get-started/get-docker.md).
-- Work through containerizing an application in [Docker workshop part 2](/get-started/workshop/02_our_app.md)
-- Make sure that Swarm is enabled on your Docker Desktop by typing `docker system info`, and looking for a message `Swarm: active` (you might have to scroll up a little).
-
-  If Swarm isn't running, simply type `docker swarm init` in a shell prompt to set it up.
-
-## Introduction
-
-Now that you've demonstrated that the individual components of your application run as stand-alone containers and shown how to deploy it using Kubernetes, you can look at how to arrange for them to be managed by Docker Swarm. Swarm provides many tools for scaling, networking, securing and maintaining your containerized applications, above and beyond the abilities of containers themselves.
-
-In order to validate that your containerized application works well on Swarm, you'll use Docker Desktop's built in Swarm environment right on your development machine to deploy your application, before handing it off to run on a full Swarm cluster in production. The Swarm environment created by Docker Desktop is fully featured, meaning it has all the Swarm features your app will enjoy on a real cluster, accessible from the convenience of your development machine.
-
-## Describe apps using stack files
-
-Swarm never creates individual containers like you did in the previous step of this tutorial. Instead, all Swarm workloads are scheduled as services, which are scalable groups of containers with added networking features maintained automatically by Swarm. Furthermore, all Swarm objects can and should be described in manifests called stack files. These YAML files describe all the components and configurations of your Swarm app, and can be used to create and destroy your app in any Swarm environment.
-
-Now you can write a simple stack file to run and manage your Todo app, the container `getting-started` image created in [Part 2](02_our_app.md) of the tutorial. Place the following in a file called `bb-stack.yaml`:
-
-{{% include "swarm-compose-compat.md" %}}
-
-```yaml
-version: "3.7"
-
-services:
-  bb-app:
-    image: getting-started
-    ports:
-      - "8000:3000"
-```
-
-In this Swarm YAML file, there is one object, a `service`, describing a scalable group of identical containers. In this case, you'll get just one container (the default), and that container will be based on your `getting-started` image created in [Part 2](02_our_app.md) of the tutorial. In addition, you've asked Swarm to forward all traffic arriving at port 8000 on your development machine to port 3000 inside our getting-started container.
-
-> **Kubernetes Services and Swarm Services are very different**
->
-> Despite the similar name, the two orchestrators mean very different things by
-> the term 'service'. In Swarm, a service provides both scheduling and
-> networking facilities, creating containers and providing tools for routing
-> traffic to them. In Kubernetes, scheduling and networking are handled
-> separately, deployments (or other controllers) handle the scheduling of
-> containers as pods, while services are responsible only for adding
-> networking features to those pods.
-
-## Deploy and check your application
-
-1. Deploy your application to Swarm:
-
-   ```console
-   $ docker stack deploy -c bb-stack.yaml demo
-   ```
-
-   If all goes well, Swarm will report creating all your stack objects with no complaints:
-
-   ```shell
-   Creating network demo_default
-   Creating service demo_bb-app
-   ```
-
-   Notice that in addition to your service, Swarm also creates a Docker network by default to isolate the containers deployed as part of your stack.
-
-2. Make sure everything worked by listing your service:
-
-   ```console
-   $ docker service ls
-   ```
-
-   If all has gone well, your service will report with 1/1 of its replicas created:
-
-   ```shell
-   ID                  NAME                MODE                REPLICAS            IMAGE               PORTS
-   il7elwunymbs        demo_bb-app         replicated          1/1                 getting-started:latest   *:8000->3000/tcp
-   ```
-
-   This indicates 1/1 containers you asked for as part of your services are up and running. Also, you see that port 8000 on your development machine is getting forwarded to port 3000 in your getting-started container.
-
-3. Open a browser and visit your Todo app at `localhost:8000`; you should see your Todo application, the same as when you ran it as a stand-alone container in [Part 2](02_our_app.md) of the tutorial.
-
-4. Once satisfied, tear down your application:
-
-   ```console
-   $ docker stack rm demo
-   ```
-
-## Conclusion
-
-At this point, you've successfully used Docker Desktop to deploy your application to a fully-featured Swarm environment on your development machine. You can now add other components to your app and taking advantage of all the features and power of Swarm, right on your own machine.
-
-In addition to deploying to Swarm, you've also described your application as a stack file. This simple text file contains everything you need to create your application in a running state; you can check it in to version control and share it with your colleagues, letting you to distribute your applications to other clusters (like the testing and production clusters that probably come after your development environments).
-
-## Swarm and CLI references
-
-Further documentation for all new Swarm objects and CLI commands used in this article are available here:
-
-- [Swarm Mode](/manuals/engine/swarm/_index.md)
-- [Swarm Mode Services](/manuals/engine/swarm/how-swarm-mode-works/services.md)
-- [Swarm Stacks](/manuals/engine/swarm/stack-deploy.md)
-- [`docker stack *`](/reference/cli/docker/stack/)
-- [`docker service *`](/reference/cli/docker/service/)
diff --git a/content/guides/tensorflowjs.md b/content/guides/tensorflowjs.md
index cd988f74aebf..1810de2c11aa 100644
--- a/content/guides/tensorflowjs.md
+++ b/content/guides/tensorflowjs.md
@@ -4,11 +4,10 @@ keywords: tensorflow.js, machine learning, ml, mediapipe, blazeface, face detect
 title: Face detection with TensorFlow.js
 summary: |
   This guide explains how to run TensorFlow.js in Docker containers.
-tags: [ai]
-languages: [js]
 aliases:
   - /guides/use-case/tensorflowjs/
 params:
+  tags: [ai]
   time: 20 minutes
 ---
 
@@ -43,7 +42,7 @@ pre-trained models, facilitating a wide range of ML applications directly in web
 environments. TensorFlow.js offers efficient computation, making sophisticated
 ML tasks accessible to web developers without deep ML expertise.
 
-## Why Use TensorFlow.js and Docker together?
+## Why use TensorFlow.js and Docker together?
 
 - Environment consistency and simplified deployment: Docker packages
   TensorFlow.js applications and their dependencies into containers, ensuring
@@ -293,10 +292,10 @@ gui
   .add(state, "backend", ["wasm", "webgl", "cpu"])
   .onChange(async (backend) => {
     await tf.setBackend(backend);
-    addFlagLables();
+    addFlagLabels();
   });
 
-async function addFlagLables() {
+async function addFlagLabels() {
   if (!document.querySelector("#simd_supported")) {
     const simdSupportLabel = document.createElement("div");
     simdSupportLabel.id = "simd_supported";
@@ -385,7 +384,7 @@ const renderPrediction = async () => {
 
 const setupPage = async () => {
   await tf.setBackend(state.backend);
-  addFlagLables();
+  addFlagLabels();
   await setupCamera();
   video.play();
 
@@ -512,7 +511,7 @@ others, enabling seamless integration into diverse projects. It also promotes
 the adoption of your containerized solutions, broadening their impact across the
 developer ecosystem. To share your image:
 
-1. [Sign up](https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade) or sign in to [Docker Hub](https://hub.docker.com).
+1. [Sign up](https://www.docker.com/pricing?ref=Docs&refAction=DocsGuidesTensorflowjs) or sign in to [Docker Hub](https://hub.docker.com).
 
 2. Rebuild your image to include the changes to your application. This time,
    prefix the image name with your Docker ID. Docker uses the name to determine
diff --git a/content/guides/testcontainers-cloud.md b/content/guides/testcontainers-cloud.md
new file mode 100644
index 000000000000..409a9fc5c734
--- /dev/null
+++ b/content/guides/testcontainers-cloud.md
@@ -0,0 +1,132 @@
+---
+title: |
+  Mastering Testcontainers Cloud by Docker: streamlining integration testing with containers
+linkTitle: Testcontainers Cloud by Docker
+summary: |
+  Automate, scale, and optimize testing workflows with Testcontainers Cloud
+description: |
+  Testcontainers Cloud by Docker streamlines integration testing by offloading container management to the cloud. It enables faster, consistent tests for containerized services like databases, improving performance and scalability in CI/CD pipelines without straining local or CI resources. Ideal for developers needing efficient, reliable testing environments.
+keywords: testcontainers cloud, integration testing, ci/cd, containerized tests, cloud testing, scalable testing
+aliases:
+  - /guides/testcontainers-cloud/common-questions/
+  - /guides/testcontainers-cloud/demo-ci/
+  - /guides/testcontainers-cloud/demo-local/
+  - /guides/testcontainers-cloud/why/
+params:
+  tags: [testing]
+  image: images/learning-paths/testcontainers-cloud-learning-path.png
+  time: 12 minutes
+---
+
+
+Testcontainers Cloud is a cloud-based solution designed to streamline and enhance the process of running integration tests using Testcontainers. Testcontainers is the open source framework, which allows developers to easily spin up containerized dependencies such as databases, message brokers, and other services required for testing. By shifting the management of Testcontainers-based services to the cloud, Testcontainers Cloud optimizes performance, reduces resource constraints on local machines or CI servers, and ensures consistent test environments. This solution is particularly beneficial for teams working on complex, distributed systems, as it allows for scalable, isolated, and reliable testing without the typical overhead of managing containers locally.
+
+## What you'll learn
+
+- Understand the fundamentals of Docker Testcontainers Cloud and its role in integration testing.
+- Learn how to set up and configure Docker Testcontainers Cloud for automated testing in various environments.
+- Explore how Testcontainers Cloud integrates with CI/CD pipelines to streamline testing workflows.
+
+## Tools integration
+
+Works well with Docker Desktop, GitHub Actions, Jenkins, Kubernetes, and other CI solutions
+
+Docker Pro, Team, and Business subscriptions come with Testcontainers Cloud runtime minutes, and additional minutes are available via consumption pricing. Testcontainers Cloud runtime minutes do not rollover month to month.
+
+## Who’s this for?
+
+- Teams that build cloud-native applications and are already using Testcontainers open source.
+- DevOps Teams that integrate automated container-based testing into CI/CD pipelines for continuous testing.
+- QA Teams that seek scalable and consistent test environments for comprehensive integration and end-to-end testing.
+- Developers who need reliable, containerized test environments for testing microservices and databases.
+
+## Why Testcontainers Cloud?
+
+{{< youtube-embed "6dRRlk5Vd0E" >}}
+
+Testcontainers Cloud is a powerful cloud-based solution designed to optimize integration testing with Testcontainers by offloading container management to the cloud. It helps developers and teams overcome the limitations of traditional local and CI-based testing, ensuring consistent environments, faster test execution, and scalable workflows. Whether you're new to Testcontainers or looking to enhance your existing setup, Testcontainers Cloud offers a seamless way to manage containerized tests, improving efficiency and reliability in your development pipeline.
+
+Testcontainers Cloud provides several benefits:
+
+- **Offloading to the Cloud:** Frees up local resources by shifting container management to the cloud, keeping your laptop responsive.
+- **Consistent Testing Environments:** Ensures that tests run in isolated, reliable environments, reducing inconsistencies across platforms from Dev to CI.
+- **Scalability:** Allows running large numbers of containers simultaneously without being limited by local or CI resources.
+- **Faster CI/CD Pipelines:** Reduces configuration bottlenecks and speeds up build times by offloading containers to multiple on-demand cloud workers with the Turbo-mode feature.
+
+Testcontainers Cloud streamlines integration testing by offloading container management to the cloud, ensuring consistent environments and faster test execution resulting in reduced resource strain, making it an essential tool for improving the stability of your Testcontainers-based workflows.
+
+## Setting up Testcontainers Cloud by Docker
+
+{{< youtube-embed "7c3xLAG560U" >}}
+
+This demo shows the process of setting up Testcontainers Cloud by Docker to
+work in your local development environment using the Testcontainers Desktop
+application. By the end of this walkthrough, you'll have Testcontainers Cloud
+by Docker up and running, ready to offload container management from your local
+machine to the cloud for more efficient testing.
+
+- Install and configure Testcontainers Cloud and the CLI to seamlessly integrate with your local development environment.
+- Set up and configure the Testcontainers Desktop application to monitor and manage cloud-based containers during local tests.
+- Create and run integration tests using Testcontainers that leverage cloud-based container resources.
+- Monitor and manage containers efficiently, understanding how Testcontainers Cloud automates cleanup and ensures consistent testing environments.
+- Review options for monitoring and troubleshooting in the Testcontainers Cloud Dashboard.
+
+## Configuring Testcontainers Cloud in the CI Pipeline
+
+{{< youtube-embed "NlZY9aumKJU" >}}
+
+This demo shows how Testcontainers Cloud can be seamlessly integrated into a
+Continuous Integration (CI) pipeline using GitHub Workflows, providing a
+powerful solution for running containerized integration tests without
+overloading local or CI runner resources. By leveraging GitHub Actions,
+developers can automate the process of spinning up and managing containers for
+testing in the cloud, ensuring faster and more reliable test execution. With
+just a few configuration steps, including setting up Testcontainers Cloud
+authentication and adding it to your workflow, you can offload container
+orchestration to the cloud. This approach improves the scalability of your
+pipeline, ensures consistency across tests, and simplifies resource management,
+making it an ideal solution for modern, containerized development workflows.
+
+- Understand how to set up a GitHub Actions workflow to automate the build and testing of a project.
+- Learn how to configure Testcontainers Cloud within GitHub Actions to offload containerized testing to the cloud, improving efficiency and resource management.
+- Explore how Testcontainers Cloud integrates with GitHub workflows to run integration tests that require containerized services, such as databases and message brokers.
+
+## Common challenges and questions
+
+<!-- vale Docker.HeadingLength = NO -->
+
+#### How is Testcontainers Cloud different from the open-source Testcontainers framework?
+
+While the open-source Testcontainers is a library that provides a lightweight APIs for bootstrapping local development and test dependencies with real services wrapped in Docker containers, Testcontainers Cloud provides a cloud runtime for these containers. This reduces the resource strain on local environments and provides more scalability, especially in CI/CD workflows, that enables consistent Testcontainers experience across the organization.
+
+#### What types of containers can I run with Testcontainers Cloud?
+
+Testcontainers Cloud supports any containers you would typically use with the Testcontainers framework, including databases (PostgreSQL, MySQL, MongoDB), message brokers (Kafka, RabbitMQ), and other services required for integration testing.
+
+#### Do I need to change my existing test code to use Testcontainers Cloud?
+
+No, you don't need to change your existing test code. Testcontainers Cloud integrates seamlessly with the open-source Testcontainers framework. Once the cloud configuration is set up, it automatically manages the containers in the cloud without requiring code changes.
+
+#### How do I integrate Testcontainers Cloud into my project?
+
+To integrate Testcontainers Cloud, you need to install the Testcontainers Desktop app and select run with Testcontainers Cloud option in the menu. In CI you’ll need to add a workflow step that downloads Testcontainers Cloud agent. No code changes are required beyond enabling Cloud runtime via the Testcontainers Desktop app locally or installing Testcontainers Cloud agent in CI.
+
+#### Can I use Testcontainers Cloud in a CI/CD pipeline?
+
+Yes, Testcontainers Cloud is designed to work efficiently in CI/CD pipelines. It helps reduce build times and resource bottlenecks by offloading containers that you spin up with Testcontainers library to the cloud, making it a perfect fit for continuous testing environments.
+
+#### What are the benefits of using Testcontainers Cloud?
+
+The key benefits include reduced resource usage on local machines and CI servers, scalability (run more containers without performance degradation), consistent testing environments, centralized monitoring, ease of CI configuration with removed security concerns of running Docker-in-Docker or a privileged daemon.
+
+#### Does Testcontainers Cloud support all programming languages?
+
+Testcontainers Cloud supports any language that works with the open-source Testcontainers libraries, including Java, Python, Node.js, Go, and others. As long as your project uses Testcontainers, it can be offloaded to Testcontainers Cloud.
+
+#### How is container cleanup handled in Testcontainers Cloud?
+
+While Testcontainers library automatically handles container lifecycle management, Testcontainers Cloud manages the allocated cloud worker lifetime. This means that containers are spun up, monitored, and cleaned up after tests are completed by Testcontainers library, and the worker where these containers have being running will be removed automatically after the ~35 min idle period by Testcontainers Cloud. This approach frees developers from manually managing containers and associated cloud resources.
+
+#### Is there a free tier or pricing model for Testcontainers Cloud?
+
+Pricing details for Testcontainers Cloud can be found on the [pricing page](https://testcontainers.com/cloud/pricing/).
diff --git a/content/guides/testcontainers-cloud/_index.md b/content/guides/testcontainers-cloud/_index.md
deleted file mode 100644
index 9cd9b4bebfca..000000000000
--- a/content/guides/testcontainers-cloud/_index.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: |
-  Mastering Testcontainers Cloud by Docker: streamlining integration testing with containers
-linkTitle: Testcontainers Cloud by Docker
-summary: |
-  Automate, scale, and optimize testing workflows with Testcontainers Cloud
-description: |
-  Testcontainers Cloud by Docker streamlines integration testing by offloading container management to the cloud. It enables faster, consistent tests for containerized services like databases, improving performance and scalability in CI/CD pipelines without straining local or CI resources. Ideal for developers needing efficient, reliable testing environments.
-tags: [product-demo]
-params:
-  featured: true
-  image: images/learning-paths/testcontainers-cloud-learning-path.png
-  time: 12 minutes
-  resource_links:
-    - title: Testcontainers Guides
-      url: https://testcontainers.com/guides
-    - title: Testcontainers Best Practices
-      url: https://www.docker.com/blog/testcontainers-best-practices/
-    - title: Simple local development with Testcontainers Desktop
-      url: https://testcontainers.com/guides/simple-local-development-with-testcontainers-desktop/
-    - title: Streamlining Local Development with Dev Containers and Testcontainers Cloud
-      url: https://www.docker.com/blog/streamlining-local-development-with-dev-containers-and-testcontainers-cloud/
-    - title: Running Testcontainers Tests Using GitHub Actions and Testcontainers Cloud
-      url: https://www.docker.com/blog/running-testcontainers-tests-using-github-actions/
-    - title: Testcontainers Cloud on the Docker Blog
-      url: https://www.docker.com/search/?_sf_s=testcontainers%20cloud
----
-
-Testcontainers Cloud is a cloud-based solution designed to streamline and enhance the process of running integration tests using Testcontainers. Testcontainers is the open source framework, which allows developers to easily spin up containerized dependencies such as databases, message brokers, and other services required for testing. By shifting the management of Testcontainers-based services to the cloud, Testcontainers Cloud optimizes performance, reduces resource constraints on local machines or CI servers, and ensures consistent test environments. This solution is particularly beneficial for teams working on complex, distributed systems, as it allows for scalable, isolated, and reliable testing without the typical overhead of managing containers locally.
-
-## What you'll learn
-
-- Understand the fundamentals of Docker Testcontainers Cloud and its role in integration testing.
-- Learn how to set up and configure Docker Testcontainers Cloud for automated testing in various environments.
-- Explore how Testcontainers Cloud integrates with CI/CD pipelines to streamline testing workflows.
-
-## Tools integration
-
-Works well with Docker Desktop, GitHub Actions, Jenkins, Kubernetes, and other CI solutions
-
-Docker Pro, Team, and Business subscriptions come with Testcontainers Cloud runtime minutes, and additional minutes are available via consumption pricing. Testcontainers Cloud runtime minutes do not rollover month to month.
-
-## Who’s this for?
-
-- Teams that build cloud-native applications and are already using Testcontainers open source.
-- DevOps Teams that integrate automated container-based testing into CI/CD pipelines for continuous testing.
-- QA Teams that seek scalable and consistent test environments for comprehensive integration and end-to-end testing.
-- Developers who need reliable, containerized test environments for testing microservices and databases.
diff --git a/content/guides/testcontainers-cloud/common-questions.md b/content/guides/testcontainers-cloud/common-questions.md
deleted file mode 100644
index 4a0cbab4f590..000000000000
--- a/content/guides/testcontainers-cloud/common-questions.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: Common challenges and questions
-description: Explore common challenges and questions related to Testcontainers Cloud by Docker.
-weight: 40
----
-
-<!-- vale Docker.HeadingLength = NO -->
-
-### How is Testcontainers Cloud different from the open-source Testcontainers framework?
-
-While the open-source Testcontainers is a library that provides a lightweight APIs for bootstrapping local development and test dependencies with real services wrapped in Docker containers, Testcontainers Cloud provides a cloud runtime for these containers. This reduces the resource strain on local environments and provides more scalability, especially in CI/CD workflows, that enables consistent Testcontainers experience across the organization.
-
-### What types of containers can I run with Testcontainers Cloud?
-
-Testcontainers Cloud supports any containers you would typically use with the Testcontainers framework, including databases (PostgreSQL, MySQL, MongoDB), message brokers (Kafka, RabbitMQ), and other services required for integration testing.
-
-### Do I need to change my existing test code to use Testcontainers Cloud?
-
-No, you don't need to change your existing test code. Testcontainers Cloud integrates seamlessly with the open-source Testcontainers framework. Once the cloud configuration is set up, it automatically manages the containers in the cloud without requiring code changes.
-
-### How do I integrate Testcontainers Cloud into my project?
-
-To integrate Testcontainers Cloud, you need to install the Testcontainers Desktop app and select run with Testcontainers Cloud option in the menu. In CI you’ll need to add a workflow step that downloads Testcontainers Cloud agent. No code changes are required beyond enabling Cloud runtime via the Testcontainers Desktop app locally or installing Testcontainers Cloud agent in CI.
-
-### Can I use Testcontainers Cloud in a CI/CD pipeline?
-
-Yes, Testcontainers Cloud is designed to work efficiently in CI/CD pipelines. It helps reduce build times and resource bottlenecks by offloading containers that you spin up with Testcontainers library to the cloud, making it a perfect fit for continuous testing environments.
-
-### What are the benefits of using Testcontainers Cloud?
-
-The key benefits include reduced resource usage on local machines and CI servers, scalability (run more containers without performance degradation), consistent testing environments, centralized monitoring, ease of CI configuration with removed security concerns of running Docker-in-Docker or a privileged daemon.
-
-### Does Testcontainers Cloud support all programming languages?
-
-Testcontainers Cloud supports any language that works with the open-source Testcontainers libraries, including Java, Python, Node.js, Go, and others. As long as your project uses Testcontainers, it can be offloaded to Testcontainers Cloud.
-
-### How is container cleanup handled in Testcontainers Cloud?
-
-While Testcontainers library automatically handles container lifecycle management, Testcontainers Cloud manages the allocated cloud worker lifetime. This means that containers are spun up, monitored, and cleaned up after tests are completed by Testcontainers library, and the worker where these containers have being running will be removed automatically after the ~35 min idle period by Testcontainers Cloud. This approach frees developers from manually managing containers and assosiated cloud resources. 
-
-### Is there a free tier or pricing model for Testcontainers Cloud?
-
-Pricing details for Testcontainers Cloud can be found on the [pricing page](https://testcontainers.com/cloud/pricing/).
diff --git a/content/guides/testcontainers-cloud/demo-ci.md b/content/guides/testcontainers-cloud/demo-ci.md
deleted file mode 100644
index 1f2dd2dbf894..000000000000
--- a/content/guides/testcontainers-cloud/demo-ci.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Configuring Testcontainers Cloud in the CI Pipeline
-description: Use Testcontainers Cloud with GitHub Workflows to automate testing in a CI pipeline.
-weight: 30
----
-
-{{< youtube-embed "NlZY9aumKJU" >}}
-
-This demo shows how Testcontainers Cloud can be seamlessly integrated into a
-Continuous Integration (CI) pipeline using GitHub Workflows, providing a
-powerful solution for running containerized integration tests without
-overloading local or CI runner resources. By leveraging GitHub Actions,
-developers can automate the process of spinning up and managing containers for
-testing in the cloud, ensuring faster and more reliable test execution. With
-just a few configuration steps, including setting up Testcontainers Cloud
-authentication and adding it to your workflow, you can offload container
-orchestration to the cloud. This approach improves the scalability of your
-pipeline, ensures consistency across tests, and simplifies resource management,
-making it an ideal solution for modern, containerized development workflows.
-
-- Understand how to set up a GitHub Actions workflow to automate the build and testing of a project.   
-- Learn how to configure Testcontainers Cloud within GitHub Actions to offload containerized testing to the cloud, improving efficiency and resource management.
-- Explore how Testcontainers Cloud integrates with GitHub workflows to run integration tests that require containerized services, such as databases and message brokers.
diff --git a/content/guides/testcontainers-cloud/demo-local.md b/content/guides/testcontainers-cloud/demo-local.md
deleted file mode 100644
index 138804b73af9..000000000000
--- a/content/guides/testcontainers-cloud/demo-local.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Setting up Testcontainers Cloud by Docker
-description: Set up Testcontainers Cloud by Docker in a local development environment.
-weight: 20
----
-
-{{< youtube-embed "7c3xLAG560U" >}}
-
-This demo shows the process of setting up Testcontainers Cloud by Docker to
-work in your local development environment using the Testcontainers Desktop
-application. By the end of this walkthrough, you'll have Testcontainers Cloud
-by Docker up and running, ready to offload container management from your local
-machine to the cloud for more efficient testing.
-
-- Install and configure Testcontainers Cloud and the CLI to seamlessly integrate with your local development environment.
-- Set up and configure the Testcontainers Desktop application to monitor and manage cloud-based containers during local tests.
-- Create and run integration tests using Testcontainers that leverage cloud-based container resources.
-- Monitor and manage containers efficiently, understanding how Testcontainers Cloud automates cleanup and ensures consistent testing environments.
-- Review options for monitoring and troubleshooting in the Testcontainers Cloud Dashboard.
diff --git a/content/guides/testcontainers-cloud/why.md b/content/guides/testcontainers-cloud/why.md
deleted file mode 100644
index e9b3cbf2de93..000000000000
--- a/content/guides/testcontainers-cloud/why.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Why Testcontainers Cloud?
-description: Learn how Testcontainers Cloud by Docker can help you optimize integration testing.
-weight: 10
----
-
-{{< youtube-embed "6dRRlk5Vd0E" >}}
-
-Testcontainers Cloud is a powerful cloud-based solution designed to optimize integration testing with Testcontainers by offloading container management to the cloud. It helps developers and teams overcome the limitations of traditional local and CI-based testing, ensuring consistent environments, faster test execution, and scalable workflows. Whether you're new to Testcontainers or looking to enhance your existing setup, Testcontainers Cloud offers a seamless way to manage containerized tests, improving efficiency and reliability in your development pipeline.
-
-Testcontainers Cloud provides several benefits:
-
-- **Offloading to the Cloud:** Frees up local resources by shifting container management to the cloud, keeping your laptop responsive.
-- **Consistent Testing Environments:** Ensures that tests run in isolated, reliable environments, reducing inconsistencies across platforms from Dev to CI.
-- **Scalability:** Allows running large numbers of containers simultaneously without being limited by local or CI resources.
-- **Faster CI/CD Pipelines:** Reduces configuration bottlenecks and speeds up build times by offloading containers to multiple on-demand cloud workers with the Turbo-mode feature.
-
-Testcontainers Cloud streamlines integration testing by offloading container management to the cloud, ensuring consistent environments and faster test execution resulting in reduced resource strain, making it an essential tool for improving the stability of your Testcontainers-based workflows.
diff --git a/content/guides/testcontainers-dotnet-aspnet-core.md b/content/guides/testcontainers-dotnet-aspnet-core.md
new file mode 100644
index 000000000000..31769970ae01
--- /dev/null
+++ b/content/guides/testcontainers-dotnet-aspnet-core.md
@@ -0,0 +1,501 @@
+---
+title: Testing an ASP.NET Core web app with Testcontainers
+linkTitle: ASP.NET Core testing
+description: Learn how to use Testcontainers for .NET to replace SQLite with a real Microsoft SQL Server in ASP.NET Core integration tests.
+keywords: testcontainers, dotnet, csharp, testing, mssql, asp.net core, integration testing, entity framework
+summary: |
+  Learn how to test an ASP.NET Core web app using Testcontainers for .NET
+  with a real Microsoft SQL Server instance instead of SQLite.
+aliases:
+  - /guides/testcontainers-dotnet-aspnet-core/create-project/
+  - /guides/testcontainers-dotnet-aspnet-core/run-tests/
+  - /guides/testcontainers-dotnet-aspnet-core/write-tests/
+params:
+  tags: [testing]
+  time: 25 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-testing-aspnet-core -->
+
+In this guide, you'll learn how to:
+
+- Use Testcontainers for .NET to spin up a Microsoft SQL Server container for integration tests
+- Replace SQLite with a production-like database provider in ASP.NET Core tests
+- Customize `WebApplicationFactory` to configure test dependencies with Testcontainers
+- Manage container lifecycle with xUnit's `IAsyncLifetime`
+
+## Prerequisites
+
+- .NET 8.0+ SDK
+- A code editor or IDE (Visual Studio, VS Code, Rider)
+- A Docker environment supported by Testcontainers. For details, see the
+  [Testcontainers .NET system requirements](https://dotnet.testcontainers.org/supported_docker_environment/).
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Set up the project
+
+### Background
+
+This guide builds on top of Microsoft's
+[Integration tests in ASP.NET Core](https://learn.microsoft.com/en-us/aspnet/core/test/integration-tests)
+documentation. The original sample uses an in-memory SQLite database as the
+backing store for integration tests. You'll replace SQLite with a real
+Microsoft SQL Server instance running in a Docker container using
+Testcontainers.
+
+You can find the original code sample in the
+[dotnet/AspNetCore.Docs.Samples](https://github.com/dotnet/AspNetCore.Docs.Samples/tree/main/test/integration-tests/IntegrationTestsSample)
+repository.
+
+### Clone the repository
+
+Clone the Testcontainers guide repository and change into the project
+directory:
+
+```console
+$ git clone https://github.com/testcontainers/tc-guide-testing-aspnet-core.git
+$ cd tc-guide-testing-aspnet-core
+```
+
+### Project structure
+
+The solution contains two projects:
+
+```text
+RazorPagesProject.sln
+├── src/RazorPagesProject/              # ASP.NET Core Razor Pages app
+└── tests/RazorPagesProject.Tests/      # xUnit integration tests
+```
+
+#### Application project
+
+The application project (`src/RazorPagesProject/RazorPagesProject.csproj`)
+is a Razor Pages web app that uses Entity Framework Core with SQLite as its
+default database provider:
+
+```xml
+<Project Sdk="Microsoft.NET.Sdk.Web">
+
+  <PropertyGroup>
+    <TargetFramework>net9.0</TargetFramework>
+    <ImplicitUsings>enable</ImplicitUsings>
+  </PropertyGroup>
+
+  <ItemGroup>
+    <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="7.0.0" />
+    <PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="7.0.0" />
+    <PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="7.0.0" />
+    <PackageReference Include="Microsoft.AspNetCore.Identity.UI" Version="7.0.0" />
+    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="7.0.0">
+      <PrivateAssets>all</PrivateAssets>
+      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
+    </PackageReference>
+  </ItemGroup>
+
+</Project>
+```
+
+The `ApplicationDbContext` stores `Message` entities and provides methods to
+query and manage them:
+
+```csharp
+public class ApplicationDbContext : IdentityDbContext
+{
+    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
+        : base(options)
+    {
+    }
+
+    public virtual DbSet<Message> Messages { get; set; }
+
+    public async virtual Task<List<Message>> GetMessagesAsync()
+    {
+        return await Messages
+            .OrderBy(message => message.Text)
+            .AsNoTracking()
+            .ToListAsync();
+    }
+
+    public async virtual Task AddMessageAsync(Message message)
+    {
+        await Messages.AddAsync(message);
+        await SaveChangesAsync();
+    }
+
+    public async virtual Task DeleteAllMessagesAsync()
+    {
+        foreach (Message message in Messages)
+        {
+            Messages.Remove(message);
+        }
+
+        await SaveChangesAsync();
+    }
+
+    public async virtual Task DeleteMessageAsync(int id)
+    {
+        var message = await Messages.FindAsync(id);
+
+        if (message != null)
+        {
+            Messages.Remove(message);
+            await SaveChangesAsync();
+        }
+    }
+
+    public void Initialize()
+    {
+        Messages.AddRange(GetSeedingMessages());
+        SaveChanges();
+    }
+
+    public static List<Message> GetSeedingMessages()
+    {
+        return new List<Message>()
+        {
+            new Message(){ Text = "You're standing on my scarf." },
+            new Message(){ Text = "Would you like a jelly baby?" },
+            new Message(){ Text = "To the rational mind, nothing is inexplicable; only unexplained." }
+        };
+    }
+}
+```
+
+#### Test project
+
+The test project (`tests/RazorPagesProject.Tests/RazorPagesProject.Tests.csproj`)
+includes xUnit, the ASP.NET Core testing infrastructure, and the
+Testcontainers MSSQL module:
+
+```xml
+<Project Sdk="Microsoft.NET.Sdk.Web">
+
+  <PropertyGroup>
+    <TargetFramework>net9.0</TargetFramework>
+    <ImplicitUsings>enable</ImplicitUsings>
+  </PropertyGroup>
+
+  <ItemGroup>
+    <PackageReference Include="AngleSharp" Version="0.17.1" />
+    <PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="7.0.0" />
+    <PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="7.0.0" />
+    <PackageReference Include="Microsoft.AspNetCore.Identity.UI" Version="7.0.0" />
+    <PackageReference Include="Microsoft.AspNetCore.Mvc.Testing" Version="7.0.0" />
+    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="7.0.0" />
+    <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="7.0.0" />
+    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="7.0.0" />
+    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="7.0.0">
+      <PrivateAssets>all</PrivateAssets>
+      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
+    </PackageReference>
+
+    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.4.0" />
+
+    <PackageReference Include="Testcontainers.MsSql" Version="3.0.0" />
+    <PackageReference Include="xunit" Version="2.4.2" />
+    <PackageReference Include="xunit.runner.visualstudio" Version="2.4.5">
+      <PrivateAssets>all</PrivateAssets>
+      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
+    </PackageReference>
+  </ItemGroup>
+
+  <ItemGroup>
+    <ProjectReference Include="..\..\src\RazorPagesProject\RazorPagesProject.csproj" />
+  </ItemGroup>
+
+  <ItemGroup>
+    <Content Update="xunit.runner.json">
+      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
+    </Content>
+  </ItemGroup>
+
+</Project>
+```
+
+The key dependencies are:
+
+- `Microsoft.AspNetCore.Mvc.Testing` - provides `WebApplicationFactory` for
+  bootstrapping the app in tests
+- `Microsoft.EntityFrameworkCore.SqlServer` - the SQL Server database provider
+  for Entity Framework Core
+- `Testcontainers.MsSql` - the Testcontainers module for Microsoft SQL Server
+
+#### Existing SQLite-based test factory
+
+The original project includes a `CustomWebApplicationFactory` that replaces
+the application's database with an in-memory SQLite instance:
+
+```csharp
+public class CustomWebApplicationFactory<TProgram>
+    : WebApplicationFactory<TProgram> where TProgram : class
+{
+    protected override void ConfigureWebHost(IWebHostBuilder builder)
+    {
+        builder.ConfigureServices(services =>
+        {
+            var dbContextDescriptor = services.SingleOrDefault(
+                d => d.ServiceType ==
+                    typeof(DbContextOptions<ApplicationDbContext>));
+
+            services.Remove(dbContextDescriptor);
+
+            var dbConnectionDescriptor = services.SingleOrDefault(
+                d => d.ServiceType ==
+                    typeof(DbConnection));
+
+            services.Remove(dbConnectionDescriptor);
+
+            // Create open SqliteConnection so EF won't automatically close it.
+            services.AddSingleton<DbConnection>(container =>
+            {
+                var connection = new SqliteConnection("DataSource=:memory:");
+                connection.Open();
+
+                return connection;
+            });
+
+            services.AddDbContext<ApplicationDbContext>((container, options) =>
+            {
+                var connection = container.GetRequiredService<DbConnection>();
+                options.UseSqlite(connection);
+            });
+        });
+
+        builder.UseEnvironment("Development");
+    }
+}
+```
+
+While this approach works, SQLite has behavioral differences from the database
+you'd use in production. In the next section, you'll replace it with a
+Testcontainers-managed Microsoft SQL Server instance.
+
+## Write tests with Testcontainers
+
+The existing tests use an in-memory SQLite database. While convenient, this
+doesn't match production behavior. You can replace it with a real Microsoft SQL
+Server instance managed by Testcontainers.
+
+### Add dependencies
+
+Change to the test project directory and add the SQL Server Entity Framework
+provider and the Testcontainers MSSQL module:
+
+```console
+$ cd tests/RazorPagesProject.Tests
+$ dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 7.0.0
+$ dotnet add package Testcontainers.MsSql --version 3.0.0
+```
+
+> [!NOTE]
+> Testcontainers for .NET offers a range of
+> [modules](https://www.nuget.org/profiles/Testcontainers) that follow best
+> practice configurations.
+
+### Create the test class
+
+Create a `MsSqlTests.cs` file in the `IntegrationTests` directory. This class
+manages the SQL Server container lifecycle and contains a nested test class.
+
+```csharp
+using System.Data.Common;
+using System.Net;
+using AngleSharp.Html.Dom;
+using Microsoft.AspNetCore.Mvc.Testing;
+using Microsoft.EntityFrameworkCore;
+using RazorPagesProject.Data;
+using RazorPagesProject.Tests.Helpers;
+using Testcontainers.MsSql;
+using Xunit;
+
+namespace RazorPagesProject.Tests.IntegrationTests;
+
+public sealed class MsSqlTests : IAsyncLifetime
+{
+    private readonly MsSqlContainer _msSqlContainer = new MsSqlBuilder().Build();
+
+    public Task InitializeAsync()
+    {
+        return _msSqlContainer.StartAsync();
+    }
+
+    public Task DisposeAsync()
+    {
+        return _msSqlContainer.DisposeAsync().AsTask();
+    }
+
+    public sealed class IndexPageTests : IClassFixture<MsSqlTests>, IDisposable
+    {
+        private readonly WebApplicationFactory<Program> _webApplicationFactory;
+
+        private readonly HttpClient _httpClient;
+
+        public IndexPageTests(MsSqlTests fixture)
+        {
+            var clientOptions = new WebApplicationFactoryClientOptions();
+            clientOptions.AllowAutoRedirect = false;
+
+            _webApplicationFactory = new CustomWebApplicationFactory(fixture);
+            _httpClient = _webApplicationFactory.CreateClient(clientOptions);
+        }
+
+        public void Dispose()
+        {
+            _webApplicationFactory.Dispose();
+        }
+
+        [Fact]
+        public async Task Post_DeleteAllMessagesHandler_ReturnsRedirectToRoot()
+        {
+            // Arrange
+            var defaultPage = await _httpClient.GetAsync("/")
+                .ConfigureAwait(false);
+
+            var document = await HtmlHelpers.GetDocumentAsync(defaultPage)
+                .ConfigureAwait(false);
+
+            // Act
+            var form = (IHtmlFormElement)document.QuerySelector("form[id='messages']");
+            var submitButton = (IHtmlButtonElement)document.QuerySelector("button[id='deleteAllBtn']");
+
+            var response = await _httpClient.SendAsync(form, submitButton)
+                .ConfigureAwait(false);
+
+            // Assert
+            Assert.Equal(HttpStatusCode.OK, defaultPage.StatusCode);
+            Assert.Equal(HttpStatusCode.Redirect, response.StatusCode);
+            Assert.Equal("/", response.Headers.Location.OriginalString);
+        }
+
+        private sealed class CustomWebApplicationFactory : WebApplicationFactory<Program>
+        {
+            private readonly string _connectionString;
+
+            public CustomWebApplicationFactory(MsSqlTests fixture)
+            {
+                _connectionString = fixture._msSqlContainer.GetConnectionString();
+            }
+
+            protected override void ConfigureWebHost(IWebHostBuilder builder)
+            {
+                builder.ConfigureServices(services =>
+                {
+                    services.Remove(services.SingleOrDefault(service => typeof(DbContextOptions<ApplicationDbContext>) == service.ServiceType));
+                    services.Remove(services.SingleOrDefault(service => typeof(DbConnection) == service.ServiceType));
+                    services.AddDbContext<ApplicationDbContext>((_, option) => option.UseSqlServer(_connectionString));
+                });
+            }
+        }
+    }
+}
+```
+
+### Understand the test structure
+
+#### Container lifecycle with IAsyncLifetime
+
+The outer `MsSqlTests` class implements `IAsyncLifetime`. xUnit calls
+`InitializeAsync()` right after creating the class instance, which starts the
+SQL Server container. After all tests complete, `DisposeAsync()` stops and
+removes the container.
+
+```csharp
+private readonly MsSqlContainer _msSqlContainer = new MsSqlBuilder().Build();
+```
+
+`MsSqlBuilder().Build()` creates a pre-configured Microsoft SQL Server
+container. Testcontainers modules follow best practices, so you don't need
+to configure ports, passwords, or startup wait strategies yourself.
+
+#### Nested test class with IClassFixture
+
+The `IndexPageTests` class is nested inside `MsSqlTests` and implements
+`IClassFixture<MsSqlTests>`. This gives the test class access to the
+container's private field and creates a clean hierarchy in the test explorer.
+
+#### Custom WebApplicationFactory
+
+Instead of using the SQLite-based factory, the nested
+`CustomWebApplicationFactory` retrieves the connection string from the running
+SQL Server container and passes it to `UseSqlServer()`:
+
+```csharp
+private sealed class CustomWebApplicationFactory : WebApplicationFactory<Program>
+{
+    private readonly string _connectionString;
+
+    public CustomWebApplicationFactory(MsSqlTests fixture)
+    {
+        _connectionString = fixture._msSqlContainer.GetConnectionString();
+    }
+
+    protected override void ConfigureWebHost(IWebHostBuilder builder)
+    {
+        builder.ConfigureServices(services =>
+        {
+            services.Remove(services.SingleOrDefault(service => typeof(DbContextOptions<ApplicationDbContext>) == service.ServiceType));
+            services.Remove(services.SingleOrDefault(service => typeof(DbConnection) == service.ServiceType));
+            services.AddDbContext<ApplicationDbContext>((_, option) => option.UseSqlServer(_connectionString));
+        });
+    }
+}
+```
+
+This factory:
+
+1. Removes the existing `DbContextOptions<ApplicationDbContext>` registration
+2. Removes the existing `DbConnection` registration
+3. Adds a new `ApplicationDbContext` configured with the SQL Server connection
+   string from the Testcontainers-managed container
+
+> [!NOTE]
+> The Microsoft SQL Server Docker image isn't compatible with ARM devices, such
+> as Macs with Apple Silicon. You can use the
+> [SqlEdge](https://www.nuget.org/packages/Testcontainers.SqlEdge) module or
+> [Testcontainers Cloud](https://www.testcontainers.cloud/) as alternatives.
+
+## Run tests and next steps
+
+### Run the tests
+
+Run the tests from the solution root:
+
+```console
+$ dotnet test ./RazorPagesProject.sln
+```
+
+The first run may take longer because Docker needs to pull the Microsoft SQL
+Server image. On subsequent runs, the image is cached locally.
+
+You should see xUnit discover and run the tests, including the
+`MsSqlTests.IndexPageTests` class. Testcontainers starts a SQL Server
+container, the tests execute against it, and the container is stopped and
+removed automatically after the tests finish.
+
+### Summary
+
+By replacing SQLite with a Testcontainers-managed Microsoft SQL Server
+instance, the integration tests run against the same type of database used in
+production. This approach catches database-specific issues early, such as
+differences in SQL dialect, transaction behavior, or data type handling between
+SQLite and SQL Server.
+
+The `MsSqlTests` class uses `IAsyncLifetime` to manage the container lifecycle,
+and a nested `CustomWebApplicationFactory` wires the container's connection
+string into the application's service configuration. You can apply this same
+pattern to any database or service that Testcontainers supports.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Testcontainers for .NET documentation](https://dotnet.testcontainers.org/)
+- [Testcontainers for .NET modules](https://dotnet.testcontainers.org/modules/)
+- [Microsoft SQL Server module](https://www.nuget.org/packages/Testcontainers.MsSql)
+- [Integration tests in ASP.NET Core](https://learn.microsoft.com/en-us/aspnet/core/test/integration-tests)
diff --git a/content/guides/testcontainers-dotnet-getting-started.md b/content/guides/testcontainers-dotnet-getting-started.md
new file mode 100644
index 000000000000..a6fde6a88d97
--- /dev/null
+++ b/content/guides/testcontainers-dotnet-getting-started.md
@@ -0,0 +1,263 @@
+---
+title: Getting started with Testcontainers for .NET
+linkTitle: Testcontainers for .NET
+description: Learn how to use Testcontainers for .NET to test database interactions with a real PostgreSQL instance.
+keywords: testcontainers, dotnet, csharp, testing, postgresql, integration testing, xunit
+summary: |
+  Learn how to create a .NET application and test database interactions
+  using Testcontainers for .NET with a real PostgreSQL instance.
+aliases:
+  - /guides/testcontainers-dotnet-getting-started/create-project/
+  - /guides/testcontainers-dotnet-getting-started/run-tests/
+  - /guides/testcontainers-dotnet-getting-started/write-tests/
+params:
+  tags: [testing]
+  time: 20 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-getting-started-with-testcontainers-for-dotnet -->
+
+In this guide, you will learn how to:
+
+- Create a .NET solution with a source and test project
+- Implement a `CustomerService` that manages customer records in PostgreSQL
+- Write integration tests using Testcontainers and xUnit
+- Manage container lifecycle with `IAsyncLifetime`
+
+## Prerequisites
+
+- .NET 8.0+ SDK
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the .NET project
+
+### Set up the solution
+
+Create a .NET solution with source and test projects:
+
+```console
+$ dotnet new sln -o TestcontainersDemo
+$ cd TestcontainersDemo
+$ dotnet new classlib -o CustomerService
+$ dotnet sln add ./CustomerService/CustomerService.csproj
+$ dotnet new xunit -o CustomerService.Tests
+$ dotnet sln add ./CustomerService.Tests/CustomerService.Tests.csproj
+$ dotnet add ./CustomerService.Tests/CustomerService.Tests.csproj reference ./CustomerService/CustomerService.csproj
+```
+
+Add the Npgsql dependency to the source project:
+
+```console
+$ dotnet add ./CustomerService/CustomerService.csproj package Npgsql
+```
+
+### Implement the business logic
+
+Create a `Customer` record type:
+
+```csharp
+namespace Customers;
+
+public readonly record struct Customer(long Id, string Name);
+```
+
+Create a `DbConnectionProvider` class to manage database connections:
+
+```csharp
+using System.Data.Common;
+using Npgsql;
+
+namespace Customers;
+
+public sealed class DbConnectionProvider
+{
+    private readonly string _connectionString;
+
+    public DbConnectionProvider(string connectionString)
+    {
+        _connectionString = connectionString;
+    }
+
+    public DbConnection GetConnection()
+    {
+        return new NpgsqlConnection(_connectionString);
+    }
+}
+```
+
+Create the `CustomerService` class:
+
+```csharp
+namespace Customers;
+
+public sealed class CustomerService
+{
+    private readonly DbConnectionProvider _dbConnectionProvider;
+
+    public CustomerService(DbConnectionProvider dbConnectionProvider)
+    {
+        _dbConnectionProvider = dbConnectionProvider;
+        CreateCustomersTable();
+    }
+
+    public IEnumerable<Customer> GetCustomers()
+    {
+        IList<Customer> customers = new List<Customer>();
+
+        using var connection = _dbConnectionProvider.GetConnection();
+        using var command = connection.CreateCommand();
+        command.CommandText = "SELECT id, name FROM customers";
+        command.Connection?.Open();
+
+        using var dataReader = command.ExecuteReader();
+        while (dataReader.Read())
+        {
+            var id = dataReader.GetInt64(0);
+            var name = dataReader.GetString(1);
+            customers.Add(new Customer(id, name));
+        }
+
+        return customers;
+    }
+
+    public void Create(Customer customer)
+    {
+        using var connection = _dbConnectionProvider.GetConnection();
+        using var command = connection.CreateCommand();
+
+        var id = command.CreateParameter();
+        id.ParameterName = "@id";
+        id.Value = customer.Id;
+
+        var name = command.CreateParameter();
+        name.ParameterName = "@name";
+        name.Value = customer.Name;
+
+        command.CommandText = "INSERT INTO customers (id, name) VALUES(@id, @name)";
+        command.Parameters.Add(id);
+        command.Parameters.Add(name);
+        command.Connection?.Open();
+        command.ExecuteNonQuery();
+    }
+
+    private void CreateCustomersTable()
+    {
+        using var connection = _dbConnectionProvider.GetConnection();
+        using var command = connection.CreateCommand();
+        command.CommandText = "CREATE TABLE IF NOT EXISTS customers (id BIGINT NOT NULL, name VARCHAR NOT NULL, PRIMARY KEY (id))";
+        command.Connection?.Open();
+        command.ExecuteNonQuery();
+    }
+}
+```
+
+Here's what `CustomerService` does:
+
+- The constructor calls `CreateCustomersTable()` to ensure the table exists.
+- `GetCustomers()` fetches all rows from the `customers` table and returns them as `Customer` objects.
+- `Create()` inserts a customer record into the database.
+
+## Write tests with Testcontainers
+
+### Add Testcontainers dependencies
+
+Add the Testcontainers PostgreSQL module to the test project:
+
+```console
+$ dotnet add ./CustomerService.Tests/CustomerService.Tests.csproj package Testcontainers.PostgreSql
+```
+
+### Write the test
+
+Create `CustomerServiceTest.cs` in the test project:
+
+```csharp
+using Testcontainers.PostgreSql;
+
+namespace Customers.Tests;
+
+public sealed class CustomerServiceTest : IAsyncLifetime
+{
+    private readonly PostgreSqlContainer _postgres = new PostgreSqlBuilder()
+        .WithImage("postgres:16-alpine")
+        .Build();
+
+    public Task InitializeAsync()
+    {
+        return _postgres.StartAsync();
+    }
+
+    public Task DisposeAsync()
+    {
+        return _postgres.DisposeAsync().AsTask();
+    }
+
+    [Fact]
+    public void ShouldReturnTwoCustomers()
+    {
+        // Given
+        var customerService = new CustomerService(new DbConnectionProvider(_postgres.GetConnectionString()));
+
+        // When
+        customerService.Create(new Customer(1, "George"));
+        customerService.Create(new Customer(2, "John"));
+        var customers = customerService.GetCustomers();
+
+        // Then
+        Assert.Equal(2, customers.Count());
+    }
+}
+```
+
+Here's what the test does:
+
+- Declares a `PostgreSqlContainer` using the `PostgreSqlBuilder` with the
+  `postgres:16-alpine` Docker image.
+- Implements `IAsyncLifetime` for container lifecycle management:
+  - `InitializeAsync()` starts the container before the test runs.
+  - `DisposeAsync()` stops and removes the container after the test finishes.
+- `ShouldReturnTwoCustomers()` creates a `CustomerService` with connection
+  details from the container, inserts two customers, fetches all customers, and
+  asserts the count.
+
+## Run tests and next steps
+
+### Run the tests
+
+Run the tests:
+
+```console
+$ dotnet test
+```
+
+You can see in the output that Testcontainers pulls the Postgres Docker image
+from Docker Hub (if not already available locally), starts the container, and
+runs the test.
+
+Writing an integration test using Testcontainers works like writing a unit test
+that you can run from your IDE. Your teammates can clone the project and run
+tests without installing Postgres on their machines.
+
+### Summary
+
+The Testcontainers for .NET library helps you write integration tests using the
+same type of database (Postgres) that you use in production, instead of mocks.
+Because you aren't using mocks and instead talk to real services, you're free
+to refactor code and still verify that the application works as expected.
+
+In addition to Postgres, Testcontainers provides dedicated
+[modules](https://www.nuget.org/profiles/Testcontainers) for many SQL
+databases, NoSQL databases, messaging queues, and more.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Testing an ASP.NET Core web app](https://testcontainers.com/guides/testing-an-aspnet-core-web-app/)
diff --git a/content/guides/testcontainers-go-getting-started.md b/content/guides/testcontainers-go-getting-started.md
new file mode 100644
index 000000000000..650d9fb1aef9
--- /dev/null
+++ b/content/guides/testcontainers-go-getting-started.md
@@ -0,0 +1,413 @@
+---
+title: Getting started with Testcontainers for Go
+linkTitle: Testcontainers for Go
+description: Learn how to use Testcontainers for Go to test database interactions with a real PostgreSQL instance.
+keywords: testcontainers, go, golang, testing, postgresql, integration testing
+summary: |
+  Learn how to create a Go application and test database interactions
+  using Testcontainers for Go with a real PostgreSQL instance.
+aliases:
+  - /guides/testcontainers-go-getting-started/create-project/
+  - /guides/testcontainers-go-getting-started/run-tests/
+  - /guides/testcontainers-go-getting-started/test-suites/
+  - /guides/testcontainers-go-getting-started/write-tests/
+params:
+  tags: [testing]
+  time: 20 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-getting-started-with-testcontainers-for-go -->
+
+In this guide, you will learn how to:
+
+- Create a Go application with modules support
+- Implement a Repository to manage customer data in a PostgreSQL database using the pgx driver
+- Write integration tests using testcontainers-go
+- Reuse containers across multiple tests using test suites
+
+## Prerequisites
+
+- Go 1.25+
+- Your preferred IDE (VS Code, GoLand)
+- A Docker environment supported by Testcontainers. For details, see
+  the [testcontainers-go system requirements](https://golang.testcontainers.org/system_requirements/).
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Go project
+
+### Initialize the project
+
+Start by creating a Go project.
+
+```console
+$ mkdir testcontainers-go-demo
+$ cd testcontainers-go-demo
+$ go mod init github.com/testcontainers/testcontainers-go-demo
+```
+
+This guide uses the [jackc/pgx](https://github.com/jackc/pgx) PostgreSQL
+driver to interact with the Postgres database and the testcontainers-go
+[Postgres module](https://golang.testcontainers.org/modules/postgres/) to
+spin up a Postgres Docker instance for testing. It also uses
+[testify](https://github.com/stretchr/testify) for running multiple tests
+as a suite and for writing assertions.
+
+Install these dependencies:
+
+```console
+$ go get github.com/jackc/pgx/v5
+$ go get github.com/testcontainers/testcontainers-go
+$ go get github.com/testcontainers/testcontainers-go/modules/postgres
+$ go get github.com/stretchr/testify
+```
+
+### Create Customer struct
+
+Create a `types.go` file in the `customer` package and define the `Customer`
+struct to model the customer details:
+
+```go
+package customer
+
+type Customer struct {
+	Id    int
+	Name  string
+	Email string
+}
+```
+
+### Create Repository
+
+Next, create `customer/repo.go`, define the `Repository` struct, and add
+methods to create a customer and get a customer by email:
+
+```go
+package customer
+
+import (
+	"context"
+	"fmt"
+	"os"
+
+	"github.com/jackc/pgx/v5"
+)
+
+type Repository struct {
+	conn *pgx.Conn
+}
+
+func NewRepository(ctx context.Context, connStr string) (*Repository, error) {
+	conn, err := pgx.Connect(ctx, connStr)
+	if err != nil {
+		_, _ = fmt.Fprintf(os.Stderr, "Unable to connect to database: %v\n", err)
+		return nil, err
+	}
+	return &Repository{
+		conn: conn,
+	}, nil
+}
+
+func (r Repository) CreateCustomer(ctx context.Context, customer Customer) (Customer, error) {
+	err := r.conn.QueryRow(ctx,
+		"INSERT INTO customers (name, email) VALUES ($1, $2) RETURNING id",
+		customer.Name, customer.Email).Scan(&customer.Id)
+	return customer, err
+}
+
+func (r Repository) GetCustomerByEmail(ctx context.Context, email string) (Customer, error) {
+	var customer Customer
+	query := "SELECT id, name, email FROM customers WHERE email = $1"
+	err := r.conn.QueryRow(ctx, query, email).
+		Scan(&customer.Id, &customer.Name, &customer.Email)
+	if err != nil {
+		return Customer{}, err
+	}
+	return customer, nil
+}
+```
+
+Here's what the code does:
+
+- `Repository` holds a `*pgx.Conn` for performing database operations.
+- `NewRepository(connStr)` takes a database connection string and initializes a `Repository`.
+- `CreateCustomer()` and `GetCustomerByEmail()` are methods on the `Repository` receiver that insert and query customer records.
+
+## Write tests with Testcontainers
+
+You have the `Repository` implementation ready, but for testing you need a
+PostgreSQL database. You can use testcontainers-go to spin up a Postgres
+database in a Docker container and run your tests against that database.
+
+### Set up the test database
+
+In real applications you might use a database migration tool, but for this
+guide, use a script to initialize the database.
+
+Create a `testdata/init-db.sql` file to create the `CUSTOMERS` table and
+insert sample data:
+
+```sql
+CREATE TABLE IF NOT EXISTS customers (id serial, name varchar(255), email varchar(255));
+
+INSERT INTO customers(name, email) VALUES ('John', 'john@gmail.com');
+```
+
+### Understand the testcontainers-go API
+
+The testcontainers-go library provides the generic `Container` abstraction
+that can run any containerized service. To further simplify, testcontainers-go
+provides technology-specific modules that reduce boilerplate and provide a
+functional options pattern to construct the container instance.
+
+For example, `PostgresContainer` provides `WithDatabase()`,
+`WithUsername()`, `WithPassword()`, and other functions to set various
+properties of Postgres containers.
+
+### Write the test
+
+Create the `customer/repo_test.go` file and implement the test:
+
+```go
+package customer
+
+import (
+	"context"
+	"path/filepath"
+	"testing"
+
+	"github.com/stretchr/testify/assert"
+	"github.com/stretchr/testify/require"
+	"github.com/testcontainers/testcontainers-go"
+	"github.com/testcontainers/testcontainers-go/modules/postgres"
+)
+
+func TestCustomerRepository(t *testing.T) {
+	ctx := context.Background()
+
+	ctr, err := postgres.Run(ctx,
+		"postgres:16-alpine",
+		postgres.WithInitScripts(filepath.Join("..", "testdata", "init-db.sql")),
+		postgres.WithDatabase("test-db"),
+		postgres.WithUsername("postgres"),
+		postgres.WithPassword("postgres"),
+		postgres.BasicWaitStrategies(),
+	)
+	testcontainers.CleanupContainer(t, ctr)
+	require.NoError(t, err)
+
+	connStr, err := ctr.ConnectionString(ctx, "sslmode=disable")
+	require.NoError(t, err)
+
+	customerRepo, err := NewRepository(ctx, connStr)
+	require.NoError(t, err)
+
+	c, err := customerRepo.CreateCustomer(ctx, Customer{
+		Name:  "Henry",
+		Email: "henry@gmail.com",
+	})
+	assert.NoError(t, err)
+	assert.NotNil(t, c)
+
+	customer, err := customerRepo.GetCustomerByEmail(ctx, "henry@gmail.com")
+	assert.NoError(t, err)
+	assert.NotNil(t, customer)
+	assert.Equal(t, "Henry", customer.Name)
+	assert.Equal(t, "henry@gmail.com", customer.Email)
+}
+```
+
+Here's what the test does:
+
+- Calls `postgres.Run()` with the `postgres:16-alpine` Docker image as the
+  first argument. This is the v0.41.0 API — the image is a required positional
+  parameter instead of an option.
+- Configures initialization scripts using `WithInitScripts(...)` so that the
+  `CUSTOMERS` table is created and sample data is inserted after the database
+  starts.
+- Uses `postgres.BasicWaitStrategies()` which combines waiting for the Postgres
+  log message and for the port to be ready. This replaces manual wait strategy
+  configuration.
+- Calls `testcontainers.CleanupContainer(t, ctr)` right after `postgres.Run()`.
+  This registers automatic cleanup with the test framework, replacing the manual
+  `t.Cleanup` and `Terminate` pattern.
+- Obtains the database `ConnectionString` from the container and initializes a
+  `Repository`.
+- Creates a customer with the email `henry@gmail.com` and verifies that the
+  customer exists in the database.
+
+## Reuse containers with test suites
+
+In the previous section, you saw how to spin up a Postgres Docker container
+for a single test. But often you have multiple tests in a single file, and you
+may want to reuse the same Postgres Docker container for all of them.
+
+You can use the [testify suite](https://pkg.go.dev/github.com/stretchr/testify/suite)
+package to implement common test setup and teardown actions.
+
+### Extract container setup
+
+First, extract the `PostgresContainer` creation logic into a separate file
+called `testhelpers/containers.go`:
+
+```go
+package testhelpers
+
+import (
+	"context"
+	"path/filepath"
+	"testing"
+
+	"github.com/stretchr/testify/require"
+	"github.com/testcontainers/testcontainers-go"
+	"github.com/testcontainers/testcontainers-go/modules/postgres"
+)
+
+type PostgresContainer struct {
+	*postgres.PostgresContainer
+	ConnectionString string
+}
+
+func CreatePostgresContainer(t *testing.T, ctx context.Context) *PostgresContainer {
+	t.Helper()
+
+	ctr, err := postgres.Run(ctx,
+		"postgres:16-alpine",
+		postgres.WithInitScripts(filepath.Join("..", "testdata", "init-db.sql")),
+		postgres.WithDatabase("test-db"),
+		postgres.WithUsername("postgres"),
+		postgres.WithPassword("postgres"),
+		postgres.BasicWaitStrategies(),
+	)
+	testcontainers.CleanupContainer(t, ctr)
+	require.NoError(t, err)
+
+	connStr, err := ctr.ConnectionString(ctx, "sslmode=disable")
+	require.NoError(t, err)
+
+	return &PostgresContainer{
+		PostgresContainer: ctr,
+		ConnectionString:  connStr,
+	}
+}
+```
+
+In `containers.go`, `PostgresContainer` extends the testcontainers-go
+`PostgresContainer` to provide easy access to `ConnectionString`. The
+`CreatePostgresContainer()` function accepts `*testing.T` as its first
+parameter, calls `t.Helper()` so that test failures point to the caller,
+and uses `testcontainers.CleanupContainer()` to register automatic cleanup.
+
+### Write the test suite
+
+Create `customer/repo_suite_test.go` and implement tests for creating
+a customer and getting a customer by email using the testify suite package:
+
+```go
+package customer
+
+import (
+	"context"
+	"testing"
+
+	"github.com/stretchr/testify/assert"
+	"github.com/stretchr/testify/require"
+	"github.com/stretchr/testify/suite"
+	"github.com/testcontainers/testcontainers-go-demo/testhelpers"
+)
+
+type CustomerRepoTestSuite struct {
+	suite.Suite
+	pgContainer *testhelpers.PostgresContainer
+	repository  *Repository
+	ctx         context.Context
+}
+
+func (suite *CustomerRepoTestSuite) SetupSuite() {
+	suite.ctx = context.Background()
+	suite.pgContainer = testhelpers.CreatePostgresContainer(suite.T(), suite.ctx)
+
+	repository, err := NewRepository(suite.ctx, suite.pgContainer.ConnectionString)
+	require.NoError(suite.T(), err)
+	suite.repository = repository
+}
+
+func (suite *CustomerRepoTestSuite) TestCreateCustomer() {
+	t := suite.T()
+
+	customer, err := suite.repository.CreateCustomer(suite.ctx, Customer{
+		Name:  "Henry",
+		Email: "henry@gmail.com",
+	})
+	require.NoError(t, err)
+	assert.NotNil(t, customer.Id)
+}
+
+func (suite *CustomerRepoTestSuite) TestGetCustomerByEmail() {
+	t := suite.T()
+
+	customer, err := suite.repository.GetCustomerByEmail(suite.ctx, "john@gmail.com")
+	require.NoError(t, err)
+	assert.Equal(t, "John", customer.Name)
+	assert.Equal(t, "john@gmail.com", customer.Email)
+}
+
+func TestCustomerRepoTestSuite(t *testing.T) {
+	suite.Run(t, new(CustomerRepoTestSuite))
+}
+```
+
+Here's what the code does:
+
+- `CustomerRepoTestSuite` extends `suite.Suite` and includes fields shared
+  across multiple tests.
+- `SetupSuite()` runs once before all tests. It calls
+  `CreatePostgresContainer(suite.T(), ...)` which handles cleanup registration
+  automatically via `CleanupContainer`, so no `TearDownSuite()` is needed.
+- `TestCreateCustomer()` uses `require.NoError()` for the create operation
+  (fail immediately if it errors) and `assert.NotNil()` for the ID check.
+- `TestGetCustomerByEmail()` uses `require.NoError()` then asserts on the
+  returned values.
+- `TestCustomerRepoTestSuite(t *testing.T)` runs the test suite when you
+  execute `go test`.
+
+> [!TIP]
+> For the purpose of this guide, the tests don't reset data in the database.
+> In practice, it's a good idea to reset the database to a known state before
+> running each test.
+
+## Run tests and next steps
+
+### Run the tests
+
+Run all the tests using `go test ./...`. Optionally add the `-v` flag for
+verbose output:
+
+```console
+$ go test -v ./...
+```
+
+You should see two Postgres Docker containers start automatically: one for the
+suite and its two tests, and another for the initial standalone test. All tests
+should pass. After the tests finish, the containers are stopped and removed
+automatically.
+
+### Summary
+
+The Testcontainers for Go library helps you write integration tests by using
+the same type of database (Postgres) that you use in production, instead of
+mocks. Because you aren't using mocks and instead talk to real services, you're
+free to refactor code and still verify that the application works as expected.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Testcontainers for Go documentation](https://golang.testcontainers.org/)
+- [Testcontainers for Go quickstart](https://golang.testcontainers.org/quickstart/)
+- [Testcontainers Postgres module for Go](https://golang.testcontainers.org/modules/postgres/)
diff --git a/content/guides/testcontainers-java-aws-localstack.md b/content/guides/testcontainers-java-aws-localstack.md
new file mode 100644
index 000000000000..fa6295b5ee42
--- /dev/null
+++ b/content/guides/testcontainers-java-aws-localstack.md
@@ -0,0 +1,450 @@
+---
+title: Testing AWS service integrations using LocalStack
+linkTitle: AWS LocalStack
+description: Learn how to test Spring Cloud AWS applications using LocalStack and Testcontainers.
+keywords: testcontainers, java, spring boot, testing, aws, localstack, s3, sqs, spring cloud aws
+summary: |
+  Learn how to create a Spring Boot application with Spring Cloud AWS,
+  then test S3 and SQS integrations using Testcontainers and LocalStack.
+aliases:
+  - /guides/testcontainers-java-aws-localstack/create-project/
+  - /guides/testcontainers-java-aws-localstack/run-tests/
+  - /guides/testcontainers-java-aws-localstack/write-tests/
+params:
+  tags: [testing]
+  time: 25 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-testing-aws-service-integrations-using-localstack -->
+
+In this guide, you will learn how to:
+
+- Create a Spring Boot application with Spring Cloud AWS integration
+- Use AWS S3 and SQS services
+- Test the application using Testcontainers and LocalStack
+
+## Prerequisites
+
+- Java 17+
+- Maven or Gradle
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Spring Boot project
+
+### Set up the project
+
+Create a Spring Boot project from [Spring Initializr](https://start.spring.io)
+by selecting the **Testcontainers** starter. Spring Cloud AWS starters are not
+available on Spring Initializr, so you need to add them manually.
+
+Alternatively, clone the
+[guide repository](https://github.com/testcontainers/tc-guide-testing-aws-service-integrations-using-localstack).
+
+Add the Spring Cloud AWS BOM to your dependency management and add the S3, SQS
+starters as dependencies. Testcontainers provides a
+[LocalStack module](https://testcontainers.com/modules/localstack/) for testing
+AWS service integrations. You also need
+[Awaitility](http://www.awaitility.org/) for testing asynchronous SQS
+processing.
+
+The key dependencies in `pom.xml` are:
+
+```xml
+<properties>
+    <java.version>17</java.version>
+    <testcontainers.version>2.0.4</testcontainers.version>
+    <awspring.version>3.0.3</awspring.version>
+</properties>
+
+<dependencies>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-web</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>io.awspring.cloud</groupId>
+        <artifactId>spring-cloud-aws-starter-s3</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>io.awspring.cloud</groupId>
+        <artifactId>spring-cloud-aws-starter-sqs</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-test</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-testcontainers</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-junit-jupiter</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-localstack</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.awaitility</groupId>
+        <artifactId>awaitility</artifactId>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+
+<dependencyManagement>
+    <dependencies>
+        <dependency>
+            <groupId>io.awspring.cloud</groupId>
+            <artifactId>spring-cloud-aws-dependencies</artifactId>
+            <version>${awspring.version}</version>
+            <type>pom</type>
+            <scope>import</scope>
+        </dependency>
+    </dependencies>
+</dependencyManagement>
+```
+
+### Create the configuration properties
+
+To make the SQS queue and S3 bucket names configurable, create an
+`ApplicationProperties` record:
+
+```java
+package com.testcontainers.demo;
+
+import org.springframework.boot.context.properties.ConfigurationProperties;
+
+@ConfigurationProperties(prefix = "app")
+public record ApplicationProperties(String queue, String bucket) {}
+```
+
+Then add `@ConfigurationPropertiesScan` to the main application class so that
+Spring automatically scans for `@ConfigurationProperties`-annotated classes and
+registers them as beans:
+
+```java
+package com.testcontainers.demo;
+
+import org.springframework.boot.SpringApplication;
+import org.springframework.boot.autoconfigure.SpringBootApplication;
+import org.springframework.boot.context.properties.ConfigurationPropertiesScan;
+
+@SpringBootApplication
+@ConfigurationPropertiesScan
+public class Application {
+
+  public static void main(String[] args) {
+    SpringApplication.run(Application.class, args);
+  }
+}
+```
+
+### Implement StorageService for S3
+
+Spring Cloud AWS provides higher-level abstractions like `S3Template` with
+convenience methods for uploading and downloading files. Create a
+`StorageService` class:
+
+```java
+package com.testcontainers.demo;
+
+import io.awspring.cloud.s3.S3Template;
+import java.io.IOException;
+import java.io.InputStream;
+import org.springframework.stereotype.Service;
+
+@Service
+public class StorageService {
+
+  private final S3Template s3Template;
+
+  public StorageService(S3Template s3Template) {
+    this.s3Template = s3Template;
+  }
+
+  public void upload(String bucketName, String key, InputStream stream) {
+    this.s3Template.upload(bucketName, key, stream);
+  }
+
+  public InputStream download(String bucketName, String key)
+    throws IOException {
+    return this.s3Template.download(bucketName, key).getInputStream();
+  }
+
+  public String downloadAsString(String bucketName, String key)
+    throws IOException {
+    try (InputStream is = this.download(bucketName, key)) {
+      return new String(is.readAllBytes());
+    }
+  }
+}
+```
+
+### Create the SQS message model
+
+Create a `Message` record that represents the payload you send to the SQS
+queue:
+
+```java
+package com.testcontainers.demo;
+
+import java.util.UUID;
+
+public record Message(UUID uuid, String content) {}
+```
+
+### Implement the message sender
+
+Create `MessageSender`, which uses `SqsTemplate` to publish messages:
+
+```java
+package com.testcontainers.demo;
+
+import io.awspring.cloud.sqs.operations.SqsTemplate;
+import org.springframework.stereotype.Service;
+
+@Service
+public class MessageSender {
+
+  private final SqsTemplate sqsTemplate;
+
+  public MessageSender(SqsTemplate sqsTemplate) {
+    this.sqsTemplate = sqsTemplate;
+  }
+
+  public void publish(String queueName, Message message) {
+    sqsTemplate.send(to -> to.queue(queueName).payload(message));
+  }
+}
+```
+
+### Implement the message listener
+
+Create `MessageListener` with a handler method annotated with `@SqsListener`.
+When a message arrives, the listener uploads the content to an S3 bucket using
+the message UUID as the key:
+
+```java
+package com.testcontainers.demo;
+
+import io.awspring.cloud.sqs.annotation.SqsListener;
+import java.io.ByteArrayInputStream;
+import java.nio.charset.StandardCharsets;
+import org.springframework.stereotype.Service;
+
+@Service
+public class MessageListener {
+
+  private final StorageService storageService;
+  private final ApplicationProperties properties;
+
+  public MessageListener(
+    StorageService storageService,
+    ApplicationProperties properties
+  ) {
+    this.storageService = storageService;
+    this.properties = properties;
+  }
+
+  @SqsListener(queueNames = { "${app.queue}" })
+  public void handle(Message message) {
+    String bucketName = this.properties.bucket();
+    String key = message.uuid().toString();
+    ByteArrayInputStream is = new ByteArrayInputStream(
+      message.content().getBytes(StandardCharsets.UTF_8)
+    );
+    this.storageService.upload(bucketName, key, is);
+  }
+}
+```
+
+The `${app.queue}` expression reads the queue name from application
+configuration instead of hard-coding it.
+
+## Write tests with Testcontainers
+
+To test the application, you need a running LocalStack instance that emulates
+the AWS S3 and SQS services. Testcontainers spins up LocalStack in a Docker
+container and `@DynamicPropertySource` connects it to Spring Cloud AWS.
+
+### Configure the test container
+
+You can start a LocalStack container and configure the Spring Cloud AWS
+properties to talk to it instead of actual AWS services. The properties you
+need to set are:
+
+```properties
+spring.cloud.aws.s3.endpoint=http://localhost:4566
+spring.cloud.aws.sqs.endpoint=http://localhost:4566
+spring.cloud.aws.credentials.access-key=noop
+spring.cloud.aws.credentials.secret-key=noop
+spring.cloud.aws.region.static=us-east-1
+```
+
+For testing, use an ephemeral container that starts on a random available port
+so that you can run multiple builds in CI in parallel without port conflicts.
+
+### Write the test
+
+Create `MessageListenerTest.java`:
+
+```java
+package com.testcontainers.demo;
+
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.awaitility.Awaitility.await;
+import static org.testcontainers.containers.localstack.LocalStackContainer.Service.S3;
+import static org.testcontainers.containers.localstack.LocalStackContainer.Service.SQS;
+
+import java.io.IOException;
+import java.time.Duration;
+import java.util.UUID;
+import org.junit.jupiter.api.BeforeAll;
+import org.junit.jupiter.api.Test;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.test.context.DynamicPropertyRegistry;
+import org.springframework.test.context.DynamicPropertySource;
+import org.testcontainers.containers.localstack.LocalStackContainer;
+import org.testcontainers.junit.jupiter.Container;
+import org.testcontainers.junit.jupiter.Testcontainers;
+import org.testcontainers.utility.DockerImageName;
+
+@SpringBootTest
+@Testcontainers
+class MessageListenerTest {
+
+  @Container
+  static LocalStackContainer localStack = new LocalStackContainer(
+    DockerImageName.parse("localstack/localstack:3.0")
+  );
+
+  static final String BUCKET_NAME = UUID.randomUUID().toString();
+  static final String QUEUE_NAME = UUID.randomUUID().toString();
+
+  @DynamicPropertySource
+  static void overrideProperties(DynamicPropertyRegistry registry) {
+    registry.add("app.bucket", () -> BUCKET_NAME);
+    registry.add("app.queue", () -> QUEUE_NAME);
+    registry.add(
+      "spring.cloud.aws.region.static",
+      () -> localStack.getRegion()
+    );
+    registry.add(
+      "spring.cloud.aws.credentials.access-key",
+      () -> localStack.getAccessKey()
+    );
+    registry.add(
+      "spring.cloud.aws.credentials.secret-key",
+      () -> localStack.getSecretKey()
+    );
+    registry.add(
+      "spring.cloud.aws.s3.endpoint",
+      () -> localStack.getEndpointOverride(S3).toString()
+    );
+    registry.add(
+      "spring.cloud.aws.sqs.endpoint",
+      () -> localStack.getEndpointOverride(SQS).toString()
+    );
+  }
+
+  @BeforeAll
+  static void beforeAll() throws IOException, InterruptedException {
+    localStack.execInContainer("awslocal", "s3", "mb", "s3://" + BUCKET_NAME);
+    localStack.execInContainer(
+      "awslocal",
+      "sqs",
+      "create-queue",
+      "--queue-name",
+      QUEUE_NAME
+    );
+  }
+
+  @Autowired
+  StorageService storageService;
+
+  @Autowired
+  MessageSender publisher;
+
+  @Autowired
+  ApplicationProperties properties;
+
+  @Test
+  void shouldHandleMessageSuccessfully() {
+    Message message = new Message(UUID.randomUUID(), "Hello World");
+    publisher.publish(properties.queue(), message);
+
+    await()
+      .pollInterval(Duration.ofSeconds(2))
+      .atMost(Duration.ofSeconds(10))
+      .ignoreExceptions()
+      .untilAsserted(() -> {
+        String msg = storageService.downloadAsString(
+          properties.bucket(),
+          message.uuid().toString()
+        );
+        assertThat(msg).isEqualTo("Hello World");
+      });
+  }
+}
+```
+
+Here's what the test does:
+
+- `@SpringBootTest` starts the full Spring application context.
+- The Testcontainers JUnit 5 annotations `@Testcontainers` and `@Container`
+  manage the lifecycle of a `LocalStackContainer` instance.
+- `@DynamicPropertySource` obtains the dynamic S3 and SQS endpoint URLs,
+  region, access key, and secret key from the container, and registers them as
+  Spring Cloud AWS configuration properties.
+- `@BeforeAll` creates the required SQS queue and S3 bucket using the
+  `awslocal` CLI tool that comes pre-installed in the LocalStack Docker image.
+  The `localStack.execInContainer()` API runs commands inside the container.
+- `shouldHandleMessageSuccessfully()` publishes a `Message` to the SQS queue.
+  The listener receives the message and stores its content in the S3 bucket
+  with the UUID as the key. Awaitility waits up to 10 seconds for the expected
+  content to appear in the bucket.
+
+## Run tests and next steps
+
+### Run the tests
+
+```console
+$ ./mvnw test
+```
+
+Or with Gradle:
+
+```console
+$ ./gradlew test
+```
+
+You should see the LocalStack Docker container start and the test pass. After
+the tests finish, the container stops and is removed automatically.
+
+### Summary
+
+LocalStack lets you develop and test AWS-based applications locally.
+The Testcontainers LocalStack module makes it straightforward to write
+integration tests by using ephemeral LocalStack containers that start on random
+ports with no external setup required.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Testcontainers LocalStack module](https://java.testcontainers.org/modules/localstack/)
+- [Getting started with Testcontainers for Java](https://java.testcontainers.org/quickstart/junit_5_quickstart/)
+- [Spring Cloud AWS documentation](https://docs.awspring.io/spring-cloud-aws/docs/3.0.3/reference/html/index.html)
diff --git a/content/guides/testcontainers-java-getting-started.md b/content/guides/testcontainers-java-getting-started.md
new file mode 100644
index 000000000000..0e8750894002
--- /dev/null
+++ b/content/guides/testcontainers-java-getting-started.md
@@ -0,0 +1,326 @@
+---
+title: Getting started with Testcontainers for Java
+linkTitle: Testcontainers for Java
+description: Learn how to use Testcontainers for Java to test a customer service with a real PostgreSQL database.
+keywords: testcontainers, java, testing, postgresql, integration testing, junit, maven
+summary: |
+  Learn how to create a Java application and test database interactions
+  using Testcontainers for Java with a real PostgreSQL instance.
+aliases:
+  - /guides/testcontainers-java-getting-started/create-project/
+  - /guides/testcontainers-java-getting-started/run-tests/
+  - /guides/testcontainers-java-getting-started/write-tests/
+params:
+  tags: [testing]
+  time: 20 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-getting-started-with-testcontainers-for-java -->
+
+In this guide, you will learn how to:
+
+- Create a Java project with Maven
+- Implement a `CustomerService` that manages customer records in PostgreSQL
+- Write integration tests using Testcontainers with a real Postgres database
+- Run the tests and verify everything works
+
+## Prerequisites
+
+- Java 17+
+- Maven or Gradle
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Java project
+
+### Set up the Maven project
+
+Create a Java project with Maven from your preferred IDE. This guide uses
+Maven, but you can use Gradle if you prefer. Add the following dependencies
+to `pom.xml`:
+
+```xml
+<dependencies>
+    <dependency>
+        <groupId>org.postgresql</groupId>
+        <artifactId>postgresql</artifactId>
+        <version>42.7.3</version>
+    </dependency>
+    <dependency>
+        <groupId>ch.qos.logback</groupId>
+        <artifactId>logback-classic</artifactId>
+        <version>1.5.6</version>
+    </dependency>
+    <dependency>
+        <groupId>org.junit.jupiter</groupId>
+        <artifactId>junit-jupiter</artifactId>
+        <version>5.10.2</version>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+
+<build>
+    <plugins>
+        <plugin>
+            <groupId>org.apache.maven.plugins</groupId>
+            <artifactId>maven-surefire-plugin</artifactId>
+            <version>3.2.5</version>
+        </plugin>
+    </plugins>
+</build>
+```
+
+This adds the Postgres JDBC driver, logback for logging, JUnit 5 for testing,
+and the latest `maven-surefire-plugin` for JUnit 5 support.
+
+### Implement the business logic
+
+Create a `Customer` record:
+
+```java
+package com.testcontainers.demo;
+
+public record Customer(Long id, String name) {}
+```
+
+Create a `DBConnectionProvider` class to hold JDBC connection parameters and
+provide a database `Connection`:
+
+```java
+package com.testcontainers.demo;
+
+import java.sql.Connection;
+import java.sql.DriverManager;
+
+class DBConnectionProvider {
+
+  private final String url;
+  private final String username;
+  private final String password;
+
+  public DBConnectionProvider(String url, String username, String password) {
+    this.url = url;
+    this.username = username;
+    this.password = password;
+  }
+
+  Connection getConnection() {
+    try {
+      return DriverManager.getConnection(url, username, password);
+    } catch (Exception e) {
+      throw new RuntimeException(e);
+    }
+  }
+}
+```
+
+Create the `CustomerService` class:
+
+```java
+package com.testcontainers.demo;
+
+import java.sql.Connection;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+import java.util.ArrayList;
+import java.util.List;
+
+public class CustomerService {
+
+  private final DBConnectionProvider connectionProvider;
+
+  public CustomerService(DBConnectionProvider connectionProvider) {
+    this.connectionProvider = connectionProvider;
+    createCustomersTableIfNotExists();
+  }
+
+  public void createCustomer(Customer customer) {
+    try (Connection conn = this.connectionProvider.getConnection()) {
+      PreparedStatement pstmt = conn.prepareStatement(
+        "insert into customers(id,name) values(?,?)"
+      );
+      pstmt.setLong(1, customer.id());
+      pstmt.setString(2, customer.name());
+      pstmt.execute();
+    } catch (SQLException e) {
+      throw new RuntimeException(e);
+    }
+  }
+
+  public List<Customer> getAllCustomers() {
+    List<Customer> customers = new ArrayList<>();
+
+    try (Connection conn = this.connectionProvider.getConnection()) {
+      PreparedStatement pstmt = conn.prepareStatement(
+        "select id,name from customers"
+      );
+      ResultSet rs = pstmt.executeQuery();
+      while (rs.next()) {
+        long id = rs.getLong("id");
+        String name = rs.getString("name");
+        customers.add(new Customer(id, name));
+      }
+    } catch (SQLException e) {
+      throw new RuntimeException(e);
+    }
+    return customers;
+  }
+
+  private void createCustomersTableIfNotExists() {
+    try (Connection conn = this.connectionProvider.getConnection()) {
+      PreparedStatement pstmt = conn.prepareStatement(
+        """
+        create table if not exists customers (
+            id bigint not null,
+            name varchar not null,
+            primary key (id)
+        )
+        """
+      );
+      pstmt.execute();
+    } catch (SQLException e) {
+      throw new RuntimeException(e);
+    }
+  }
+}
+```
+
+Here's what `CustomerService` does:
+
+- The constructor calls `createCustomersTableIfNotExists()` to ensure the table exists.
+- `createCustomer()` inserts a customer record into the database.
+- `getAllCustomers()` fetches all rows from the `customers` table and returns a list of `Customer` objects.
+
+## Write tests with Testcontainers
+
+You have the `CustomerService` implementation ready, but for testing you need a
+PostgreSQL database. You can use Testcontainers to spin up a Postgres database
+in a Docker container and run your tests against it.
+
+### Add Testcontainers dependencies
+
+Add the Testcontainers PostgreSQL module as a test dependency in `pom.xml`:
+
+```xml
+<dependency>
+    <groupId>org.testcontainers</groupId>
+    <artifactId>testcontainers-postgresql</artifactId>
+    <version>2.0.4</version>
+    <scope>test</scope>
+</dependency>
+```
+
+Since the application uses a Postgres database, the Testcontainers Postgres
+module provides a `PostgreSQLContainer` class for managing the container.
+
+### Write the test
+
+Create `CustomerServiceTest.java` under `src/test/java`:
+
+```java
+package com.testcontainers.demo;
+
+import static org.junit.jupiter.api.Assertions.assertEquals;
+
+import java.util.List;
+import org.junit.jupiter.api.AfterAll;
+import org.junit.jupiter.api.BeforeAll;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.testcontainers.postgresql.PostgreSQLContainer;
+
+class CustomerServiceTest {
+
+  static PostgreSQLContainer postgres = new PostgreSQLContainer(
+    "postgres:16-alpine"
+  );
+
+  CustomerService customerService;
+
+  @BeforeAll
+  static void beforeAll() {
+    postgres.start();
+  }
+
+  @AfterAll
+  static void afterAll() {
+    postgres.stop();
+  }
+
+  @BeforeEach
+  void setUp() {
+    DBConnectionProvider connectionProvider = new DBConnectionProvider(
+      postgres.getJdbcUrl(),
+      postgres.getUsername(),
+      postgres.getPassword()
+    );
+    customerService = new CustomerService(connectionProvider);
+  }
+
+  @Test
+  void shouldGetCustomers() {
+    customerService.createCustomer(new Customer(1L, "George"));
+    customerService.createCustomer(new Customer(2L, "John"));
+
+    List<Customer> customers = customerService.getAllCustomers();
+    assertEquals(2, customers.size());
+  }
+}
+```
+
+Here's what the test does:
+
+- Declares a `PostgreSQLContainer` with the `postgres:16-alpine` Docker image.
+- The `@BeforeAll` callback starts the Postgres container before any test
+  methods run.
+- The `@BeforeEach` callback creates a `DBConnectionProvider` using the JDBC
+  connection parameters from the container, then creates a `CustomerService`.
+  The `CustomerService` constructor creates the `customers` table if it
+  doesn't exist.
+- `shouldGetCustomers()` inserts 2 customer records, fetches all customers,
+  and asserts the count.
+- The `@AfterAll` callback stops the container after all test methods finish.
+
+## Run tests and next steps
+
+### Run the tests
+
+Run the tests using Maven:
+
+```console
+$ mvn test
+```
+
+You can see in the logs that Testcontainers pulls the Postgres Docker image
+from Docker Hub (if not already available locally), starts the container, and
+runs the test.
+
+Writing an integration test using Testcontainers works like writing a unit test
+that you can run from your IDE. Your teammates can clone the project
+and run tests without installing Postgres on their machines.
+
+### Summary
+
+The Testcontainers for Java library helps you write integration tests using the
+same type of database (Postgres) that you use in production, instead of mocks.
+Because you aren't using mocks and instead talk to real services, you're free
+to refactor code and still verify that the application works as expected.
+
+In addition to Postgres, Testcontainers provides dedicated modules for many
+SQL databases, NoSQL databases, messaging queues, and more. You can use
+Testcontainers to run any containerized dependency for your tests.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Testcontainers container lifecycle management using JUnit 5](https://testcontainers.com/guides/testcontainers-container-lifecycle/)
+- [Replace H2 with a real database for testing](https://testcontainers.com/guides/replace-h2-with-real-database-for-testing/)
+- [Getting started with Testcontainers in a Java Spring Boot project](https://testcontainers.com/guides/testing-spring-boot-rest-api-using-testcontainers/)
diff --git a/content/guides/testcontainers-java-jooq-flyway.md b/content/guides/testcontainers-java-jooq-flyway.md
new file mode 100644
index 000000000000..e6a3a954eb34
--- /dev/null
+++ b/content/guides/testcontainers-java-jooq-flyway.md
@@ -0,0 +1,610 @@
+---
+title: Working with jOOQ and Flyway using Testcontainers
+linkTitle: jOOQ and Flyway
+description: Learn how to generate jOOQ code from a database using Testcontainers and Flyway, then test your persistence layer.
+keywords: testcontainers, java, testing, jooq, flyway, postgresql, spring boot, code generation
+summary: |
+  Generate typesafe jOOQ code from a real PostgreSQL database managed by
+  Flyway migrations, then test repositories using Testcontainers.
+aliases:
+  - /guides/testcontainers-java-jooq-flyway/create-project/
+  - /guides/testcontainers-java-jooq-flyway/run-tests/
+  - /guides/testcontainers-java-jooq-flyway/write-tests/
+params:
+  tags: [testing]
+  time: 25 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-working-with-jooq-flyway-using-testcontainers -->
+
+In this guide, you will learn how to:
+
+- Create a Spring Boot application with jOOQ support
+- Generate jOOQ code using Testcontainers, Flyway, and a Maven plugin
+- Implement basic database operations using jOOQ
+- Load complex object graphs using jOOQ's MULTISET feature
+- Test the jOOQ persistence layer using Testcontainers
+
+## Prerequisites
+
+- Java 17+
+- Maven
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Spring Boot project
+
+### Set up the project
+
+Create a Spring Boot project from [Spring Initializr](https://start.spring.io)
+by selecting Maven as the build tool and adding the **JOOQ Access Layer**,
+**Flyway Migration**, **Spring Boot DevTools**, **PostgreSQL Driver**, and
+**Testcontainers** starters.
+
+Alternatively, clone the
+[guide repository](https://github.com/testcontainers/tc-guide-working-with-jooq-flyway-using-testcontainers).
+
+jOOQ (jOOQ Object Oriented Querying) provides a fluent API for building
+typesafe SQL queries. To get the full benefit of its typesafe DSL, you need
+to generate Java code from your database tables, views, and other objects.
+
+> [!TIP]
+> To learn more about how the jOOQ code generator helps, read
+> [Why You Should Use jOOQ With Code Generation](https://blog.jooq.org/why-you-should-use-jooq-with-code-generation/).
+
+The typical process for building and testing the application with jOOQ code
+generation is:
+
+1. Create a database instance using Testcontainers.
+2. Apply Flyway database migrations.
+3. Run the jOOQ code generator to produce Java code from the database objects.
+4. Run integration tests.
+
+The
+[testcontainers-jooq-codegen-maven-plugin](https://github.com/testcontainers/testcontainers-jooq-codegen-maven-plugin)
+automates this as part of the Maven build.
+
+### Create Flyway migration scripts
+
+The sample application has `users`, `posts`, and `comments` tables. Create
+the first migration script following the Flyway naming convention.
+
+Create `src/main/resources/db/migration/V1__create_tables.sql`:
+
+```sql
+create table users
+(
+    id         bigserial not null,
+    name       varchar   not null,
+    email      varchar   not null,
+    created_at timestamp,
+    updated_at timestamp,
+    primary key (id),
+    constraint user_email_unique unique (email)
+);
+
+create table posts
+(
+    id         bigserial                    not null,
+    title      varchar                      not null,
+    content    varchar                      not null,
+    created_by bigint references users (id) not null,
+    created_at timestamp,
+    updated_at timestamp,
+    primary key (id)
+);
+
+create table comments
+(
+    id         bigserial                    not null,
+    name       varchar                      not null,
+    content    varchar                      not null,
+    post_id    bigint references posts (id) not null,
+    created_at timestamp,
+    updated_at timestamp,
+    primary key (id)
+);
+
+ALTER SEQUENCE users_id_seq RESTART WITH 101;
+ALTER SEQUENCE posts_id_seq RESTART WITH 101;
+ALTER SEQUENCE comments_id_seq RESTART WITH 101;
+```
+
+The sequence values restart at 101 so that you can insert sample data with
+explicit primary key values for testing.
+
+### Configure jOOQ code generation
+
+Add the `testcontainers-jooq-codegen-maven-plugin` to `pom.xml`:
+
+```xml
+<properties>
+    <testcontainers.version>2.0.4</testcontainers.version>
+    <testcontainers-jooq-codegen-maven-plugin.version>0.0.4</testcontainers-jooq-codegen-maven-plugin.version>
+</properties>
+
+<build>
+    <plugins>
+        <plugin>
+            <groupId>org.testcontainers</groupId>
+            <artifactId>testcontainers-jooq-codegen-maven-plugin</artifactId>
+            <version>${testcontainers-jooq-codegen-maven-plugin.version}</version>
+            <dependencies>
+                <dependency>
+                    <groupId>org.testcontainers</groupId>
+                    <artifactId>testcontainers-postgresql</artifactId>
+                    <version>${testcontainers.version}</version>
+                </dependency>
+                <dependency>
+                    <groupId>org.postgresql</groupId>
+                    <artifactId>postgresql</artifactId>
+                    <version>${postgresql.version}</version>
+                </dependency>
+            </dependencies>
+            <executions>
+                <execution>
+                    <id>generate-jooq-sources</id>
+                    <goals>
+                        <goal>generate</goal>
+                    </goals>
+                    <phase>generate-sources</phase>
+                    <configuration>
+                        <database>
+                            <type>POSTGRES</type>
+                            <containerImage>postgres:16-alpine</containerImage>
+                        </database>
+                        <flyway>
+                            <locations>
+                                filesystem:src/main/resources/db/migration
+                            </locations>
+                        </flyway>
+                        <jooq>
+                            <generator>
+                                <database>
+                                    <includes>.*</includes>
+                                    <excludes>flyway_schema_history</excludes>
+                                    <inputSchema>public</inputSchema>
+                                </database>
+                                <target>
+                                    <packageName>com.testcontainers.demo.jooq</packageName>
+                                    <directory>target/generated-sources/jooq</directory>
+                                </target>
+                            </generator>
+                        </jooq>
+                    </configuration>
+                </execution>
+            </executions>
+        </plugin>
+    </plugins>
+</build>
+```
+
+Here's what the plugin configuration does:
+
+- The `<configuration>/<database>` section sets the database type to
+  `POSTGRES` and the Docker image to `postgres:16-alpine`.
+- The `<configuration>/<flyway>` section points to the Flyway migration
+  scripts.
+- The `<configuration>/<jooq>` section configures the package name and
+  output directory for the generated code. You can use any configuration
+  option that the official `jooq-code-generator` plugin supports.
+
+When you run `./mvnw clean package`, the plugin uses Testcontainers to
+spin up a PostgreSQL container, applies the Flyway migrations, and generates
+Java code under `target/generated-sources/jooq`.
+
+### Create model classes
+
+Create model classes to represent the data structures for various use cases.
+These records hold a subset of column values from the tables.
+
+`User.java`:
+
+```java
+package com.testcontainers.demo.domain;
+
+public record User(Long id, String name, String email) {}
+```
+
+`Post.java`:
+
+```java
+package com.testcontainers.demo.domain;
+
+import java.time.LocalDateTime;
+import java.util.List;
+
+public record Post(
+  Long id,
+  String title,
+  String content,
+  User createdBy,
+  List<Comment> comments,
+  LocalDateTime createdAt,
+  LocalDateTime updatedAt
+) {}
+```
+
+`Comment.java`:
+
+```java
+package com.testcontainers.demo.domain;
+
+import java.time.LocalDateTime;
+
+public record Comment(
+  Long id,
+  String name,
+  String content,
+  LocalDateTime createdAt,
+  LocalDateTime updatedAt
+) {}
+```
+
+### Implement repositories using jOOQ
+
+Create `UserRepository.java` with methods to create a user and look up a user
+by email:
+
+```java
+package com.testcontainers.demo.domain;
+
+import static com.testcontainers.demo.jooq.tables.Users.USERS;
+import static org.jooq.Records.mapping;
+
+import java.time.LocalDateTime;
+import java.util.Optional;
+import org.jooq.DSLContext;
+import org.springframework.stereotype.Repository;
+
+@Repository
+class UserRepository {
+
+  private final DSLContext dsl;
+
+  UserRepository(DSLContext dsl) {
+    this.dsl = dsl;
+  }
+
+  public User createUser(User user) {
+    return this.dsl.insertInto(USERS)
+      .set(USERS.NAME, user.name())
+      .set(USERS.EMAIL, user.email())
+      .set(USERS.CREATED_AT, LocalDateTime.now())
+      .returningResult(USERS.ID, USERS.NAME, USERS.EMAIL)
+      .fetchOne(mapping(User::new));
+  }
+
+  public Optional<User> getUserByEmail(String email) {
+    return this.dsl.select(USERS.ID, USERS.NAME, USERS.EMAIL)
+      .from(USERS)
+      .where(USERS.EMAIL.equalIgnoreCase(email))
+      .fetchOptional(mapping(User::new));
+  }
+}
+```
+
+The jOOQ DSL looks similar to SQL but written in Java. Because the code is
+generated from the database schema, it stays in sync with the database
+structure and provides type safety. For example,
+`where(USERS.EMAIL.equalIgnoreCase(email))` expects a `String` value. If you
+pass a non-string value like `123`, you get a compiler error.
+
+### Fetch complex object graphs
+
+jOOQ shines when it comes to complex queries. The database has a many-to-one
+relationship from `Post` to `User` and a one-to-many relationship from `Post`
+to `Comment`.
+
+Create `PostRepository.java` to load a `Post` with its creator and comments
+using a single query with jOOQ's MULTISET feature:
+
+```java
+package com.testcontainers.demo.domain;
+
+import static com.testcontainers.demo.jooq.Tables.COMMENTS;
+import static com.testcontainers.demo.jooq.tables.Posts.POSTS;
+import static org.jooq.Records.mapping;
+import static org.jooq.impl.DSL.multiset;
+import static org.jooq.impl.DSL.row;
+import static org.jooq.impl.DSL.select;
+
+import java.util.Optional;
+import org.jooq.DSLContext;
+import org.springframework.stereotype.Repository;
+
+@Repository
+class PostRepository {
+
+  private final DSLContext dsl;
+
+  PostRepository(DSLContext dsl) {
+    this.dsl = dsl;
+  }
+
+  public Optional<Post> getPostById(Long id) {
+    return this.dsl.select(
+        POSTS.ID,
+        POSTS.TITLE,
+        POSTS.CONTENT,
+        row(POSTS.users().ID, POSTS.users().NAME, POSTS.users().EMAIL)
+          .mapping(User::new)
+          .as("createdBy"),
+        multiset(
+          select(
+            COMMENTS.ID,
+            COMMENTS.NAME,
+            COMMENTS.CONTENT,
+            COMMENTS.CREATED_AT,
+            COMMENTS.UPDATED_AT
+          )
+            .from(COMMENTS)
+            .where(POSTS.ID.eq(COMMENTS.POST_ID))
+        )
+          .as("comments")
+          .convertFrom(r -> r.map(mapping(Comment::new))),
+        POSTS.CREATED_AT,
+        POSTS.UPDATED_AT
+      )
+      .from(POSTS)
+      .where(POSTS.ID.eq(id))
+      .fetchOptional(mapping(Post::new));
+  }
+}
+```
+
+This uses jOOQ's
+[nested records](https://www.jooq.org/doc/latest/manual/sql-building/column-expressions/nested-records/)
+for the many-to-one `Post`-to-`User` association and
+[MULTISET](https://www.jooq.org/doc/latest/manual/sql-building/column-expressions/multiset-value-constructor/)
+for the one-to-many `Post`-to-`Comment` association.
+
+## Write tests with Testcontainers
+
+Before writing the tests, create an SQL script to seed test data at
+`src/test/resources/test-data.sql`:
+
+```sql
+DELETE FROM comments;
+DELETE FROM posts;
+DELETE FROM users;
+
+INSERT INTO users(id, name, email) VALUES
+(1, 'Siva', 'siva@gmail.com'),
+(2, 'Oleg', 'oleg@gmail.com');
+
+INSERT INTO posts(id, title, content, created_by, created_at) VALUES
+(1, 'Post 1 Title', 'Post 1 content', 1, CURRENT_TIMESTAMP),
+(2, 'Post 2 Title', 'Post 2 content', 2, CURRENT_TIMESTAMP);
+
+INSERT INTO comments(id, name, content, post_id, created_at) VALUES
+(1, 'Ron', 'Comment 1', 1, CURRENT_TIMESTAMP),
+(2, 'James', 'Comment 2', 1, CURRENT_TIMESTAMP),
+(3, 'Robert', 'Comment 3', 2, CURRENT_TIMESTAMP);
+```
+
+### Test with the @JooqTest slice
+
+The `@JooqTest` annotation loads only the persistence layer components and
+auto-configures jOOQ's `DSLContext`. Use the Testcontainers special JDBC URL
+to start a Postgres container.
+
+Create `UserRepositoryJooqTest.java`:
+
+```java
+package com.testcontainers.demo.domain;
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+import org.jooq.DSLContext;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.boot.test.autoconfigure.jooq.JooqTest;
+import org.springframework.test.context.jdbc.Sql;
+
+@JooqTest(
+  properties = {
+    "spring.test.database.replace=none",
+    "spring.datasource.url=jdbc:tc:postgresql:16-alpine:///db",
+  }
+)
+@Sql("/test-data.sql")
+class UserRepositoryJooqTest {
+
+  @Autowired
+  DSLContext dsl;
+
+  UserRepository repository;
+
+  @BeforeEach
+  void setUp() {
+    this.repository = new UserRepository(dsl);
+  }
+
+  @Test
+  void shouldCreateUserSuccessfully() {
+    User user = new User(null, "John", "john@gmail.com");
+
+    User savedUser = repository.createUser(user);
+
+    assertThat(savedUser.id()).isNotNull();
+    assertThat(savedUser.name()).isEqualTo("John");
+    assertThat(savedUser.email()).isEqualTo("john@gmail.com");
+  }
+
+  @Test
+  void shouldGetUserByEmail() {
+    User user = repository.getUserByEmail("siva@gmail.com").orElseThrow();
+
+    assertThat(user.id()).isEqualTo(1L);
+    assertThat(user.name()).isEqualTo("Siva");
+    assertThat(user.email()).isEqualTo("siva@gmail.com");
+  }
+}
+```
+
+Here's what the test does:
+
+- `@JooqTest` loads only the persistence layer and auto-configures
+  `DSLContext`.
+- The Testcontainers special JDBC URL
+  (`jdbc:tc:postgresql:16-alpine:///db`) starts a PostgreSQL container
+  automatically.
+- Because `flyway-core` is on the classpath, Spring Boot runs the Flyway
+  migrations from `src/main/resources/db/migration` on startup.
+- `@Sql("/test-data.sql")` loads the test data before each test.
+- The `UserRepository` is instantiated manually with the injected
+  `DSLContext`.
+
+### Integration test with @SpringBootTest
+
+For a full integration test, use `@SpringBootTest` with the Testcontainers
+`@ServiceConnection` support introduced in Spring Boot 3.1.
+
+Create `UserRepositoryTest.java`:
+
+```java
+package com.testcontainers.demo.domain;
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+import org.junit.jupiter.api.Test;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.boot.testcontainers.service.connection.ServiceConnection;
+import org.springframework.test.context.jdbc.Sql;
+import org.testcontainers.postgresql.PostgreSQLContainer;
+import org.testcontainers.junit.jupiter.Container;
+import org.testcontainers.junit.jupiter.Testcontainers;
+
+@SpringBootTest
+@Sql("/test-data.sql")
+@Testcontainers
+class UserRepositoryTest {
+
+  @Container
+  @ServiceConnection
+  static PostgreSQLContainer postgres = new PostgreSQLContainer(
+    "postgres:16-alpine"
+  );
+
+  @Autowired
+  UserRepository repository;
+
+  @Test
+  void shouldCreateUserSuccessfully() {
+    User user = new User(null, "John", "john@gmail.com");
+
+    User savedUser = repository.createUser(user);
+
+    assertThat(savedUser.id()).isNotNull();
+    assertThat(savedUser.name()).isEqualTo("John");
+    assertThat(savedUser.email()).isEqualTo("john@gmail.com");
+  }
+
+  @Test
+  void shouldGetUserByEmail() {
+    User user = repository.getUserByEmail("siva@gmail.com").orElseThrow();
+
+    assertThat(user.id()).isEqualTo(1L);
+    assertThat(user.name()).isEqualTo("Siva");
+    assertThat(user.email()).isEqualTo("siva@gmail.com");
+  }
+}
+```
+
+Here's what the test does:
+
+- `@SpringBootTest` loads the entire application context, so
+  `UserRepository` is injected directly.
+- `@Testcontainers` and `@Container` manage the PostgreSQL container
+  lifecycle.
+- `@ServiceConnection` auto-configures the datasource properties from the
+  running container, replacing the need for `@DynamicPropertySource`.
+- `@Sql("/test-data.sql")` initializes the test data.
+
+### Test PostRepository
+
+Test the `PostRepository` that fetches complex object graphs using the
+Testcontainers special JDBC URL.
+
+Create `PostRepositoryTest.java`:
+
+```java
+package com.testcontainers.demo.domain;
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+import org.junit.jupiter.api.Test;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.test.context.jdbc.Sql;
+
+@SpringBootTest(
+  properties = {
+    "spring.test.database.replace=none",
+    "spring.datasource.url=jdbc:tc:postgresql:16-alpine:///db",
+  }
+)
+@Sql("/test-data.sql")
+class PostRepositoryTest {
+
+  @Autowired
+  PostRepository repository;
+
+  @Test
+  void shouldGetPostById() {
+    Post post = repository.getPostById(1L).orElseThrow();
+
+    assertThat(post.id()).isEqualTo(1L);
+    assertThat(post.title()).isEqualTo("Post 1 Title");
+    assertThat(post.content()).isEqualTo("Post 1 content");
+    assertThat(post.createdBy().id()).isEqualTo(1L);
+    assertThat(post.createdBy().name()).isEqualTo("Siva");
+    assertThat(post.createdBy().email()).isEqualTo("siva@gmail.com");
+    assertThat(post.comments()).hasSize(2);
+  }
+}
+```
+
+This test verifies that `getPostById` loads the post along with its creator
+and comments in a single query using jOOQ's MULTISET feature.
+
+## Run tests and next steps
+
+### Run the tests
+
+```console
+$ ./mvnw test
+```
+
+You should see the PostgreSQL Docker container start, jOOQ code generation
+complete, and all tests pass. After the tests finish, the container stops and
+is removed automatically.
+
+### Summary
+
+The Testcontainers library helps you generate Java code from the database
+using the jOOQ code generator and test your persistence layer against the
+same type of database (PostgreSQL) that you use in production, instead of
+mocks or in-memory databases.
+
+Because the code is always generated from the database's current state, you
+can be confident that your code stays in sync with database changes. You're
+free to refactor and still verify that the application works as expected.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [jOOQ documentation](https://www.jooq.org/)
+- [jOOQ code generation](https://www.jooq.org/doc/latest/manual/code-generation/)
+- [Spring Boot Testcontainers support](https://docs.spring.io/spring-boot/reference/testing/testcontainers.html)
+- [Replace H2 with a real database for testing](/guides/testcontainers-java-replace-h2/)
diff --git a/content/guides/testcontainers-java-keycloak-spring-boot.md b/content/guides/testcontainers-java-keycloak-spring-boot.md
new file mode 100644
index 000000000000..187f024cd3b6
--- /dev/null
+++ b/content/guides/testcontainers-java-keycloak-spring-boot.md
@@ -0,0 +1,605 @@
+---
+title: Securing Spring Boot microservice using Keycloak and Testcontainers
+linkTitle: Keycloak with Spring Boot
+description: Learn how to secure a Spring Boot microservice using Keycloak and test it with the Testcontainers Keycloak module.
+keywords: testcontainers, java, spring boot, testing, keycloak, security, oauth2, jwt
+summary: |
+  Learn how to create an OAuth 2.0 Resource Server using Spring Boot, secure API
+  endpoints with Keycloak, and test the application using the Testcontainers Keycloak module.
+aliases:
+  - /guides/testcontainers-java-keycloak-spring-boot/create-project/
+  - /guides/testcontainers-java-keycloak-spring-boot/run-tests/
+  - /guides/testcontainers-java-keycloak-spring-boot/write-tests/
+params:
+  tags: [testing]
+  time: 30 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-securing-spring-boot-microservice-using-keycloak-and-testcontainers -->
+
+In this guide, you'll learn how to:
+
+- Create an OAuth 2.0 Resource Server using Spring Boot
+- Secure API endpoints using Keycloak
+- Test the APIs using the Testcontainers Keycloak module
+- Run the application locally using the Testcontainers Keycloak module
+
+## Prerequisites
+
+- Java 17+
+- Maven or Gradle
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Spring Boot project
+
+### Set up the project
+
+Create a Spring Boot project from [Spring Initializr](https://start.spring.io)
+by selecting the **Spring Web**, **Validation**, **JDBC API**,
+**PostgreSQL Driver**, **Spring Security**, **OAuth2 Resource Server**, and
+**Testcontainers** starters.
+
+Alternatively, clone the
+[guide repository](https://github.com/testcontainers/tc-guide-securing-spring-boot-microservice-using-keycloak-and-testcontainers).
+
+After generating the application, add the
+[testcontainers-keycloak](https://github.com/dasniko/testcontainers-keycloak)
+community module and [REST Assured](https://rest-assured.io/) as test
+dependencies.
+
+The key dependencies in `pom.xml` are:
+
+```xml
+<properties>
+    <java.version>17</java.version>
+    <testcontainers.version>2.0.4</testcontainers.version>
+</properties>
+<dependencies>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-web</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-validation</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-jdbc</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.postgresql</groupId>
+        <artifactId>postgresql</artifactId>
+        <scope>runtime</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-security</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-test</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.security</groupId>
+        <artifactId>spring-security-test</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-testcontainers</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-junit-jupiter</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-postgresql</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>com.github.dasniko</groupId>
+        <artifactId>testcontainers-keycloak</artifactId>
+        <version>3.4.0</version>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.rest-assured</groupId>
+        <artifactId>rest-assured</artifactId>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+```
+
+### Create the domain model
+
+Create a `Product` record that represents the domain object:
+
+```java
+package com.testcontainers.products.domain;
+
+import jakarta.validation.constraints.NotEmpty;
+
+public record Product(Long id, @NotEmpty String title, String description) {}
+```
+
+### Create the repository
+
+Implement `ProductRepository` using Spring `JdbcClient` to interact with a
+PostgreSQL database:
+
+```java
+package com.testcontainers.products.domain;
+
+import java.util.List;
+import org.springframework.jdbc.core.simple.JdbcClient;
+import org.springframework.jdbc.support.GeneratedKeyHolder;
+import org.springframework.jdbc.support.KeyHolder;
+import org.springframework.stereotype.Repository;
+
+@Repository
+public class ProductRepository {
+
+  private final JdbcClient jdbcClient;
+
+  public ProductRepository(JdbcClient jdbcClient) {
+    this.jdbcClient = jdbcClient;
+  }
+
+  public List<Product> getAll() {
+    return jdbcClient.sql("SELECT * FROM products").query(Product.class).list();
+  }
+
+  public Product create(Product product) {
+    String sql =
+      "INSERT INTO products(title, description) VALUES (:title,:description) RETURNING id";
+    KeyHolder keyHolder = new GeneratedKeyHolder();
+    jdbcClient
+      .sql(sql)
+      .param("title", product.title())
+      .param("description", product.description())
+      .update(keyHolder);
+    Long id = keyHolder.getKeyAs(Long.class);
+    return new Product(id, product.title(), product.description());
+  }
+}
+```
+
+### Add a schema creation script
+
+Create `src/main/resources/schema.sql` to initialize the `products` table:
+
+```sql
+CREATE TABLE products (
+    id bigserial primary key,
+    title varchar not null,
+    description text
+);
+```
+
+Enable schema initialization in `src/main/resources/application.properties`:
+
+```properties
+spring.sql.init.mode=always
+```
+
+For production applications, use a database migration tool like Flyway or
+Liquibase instead.
+
+### Implement the API endpoints
+
+Create `ProductController` with endpoints to fetch all products and create a
+product:
+
+```java
+package com.testcontainers.products.api;
+
+import com.testcontainers.products.domain.Product;
+import com.testcontainers.products.domain.ProductRepository;
+import jakarta.validation.Valid;
+import java.util.List;
+import org.springframework.http.HttpStatus;
+import org.springframework.web.bind.annotation.GetMapping;
+import org.springframework.web.bind.annotation.PostMapping;
+import org.springframework.web.bind.annotation.RequestBody;
+import org.springframework.web.bind.annotation.RequestMapping;
+import org.springframework.web.bind.annotation.ResponseStatus;
+import org.springframework.web.bind.annotation.RestController;
+
+@RestController
+@RequestMapping("/api/products")
+class ProductController {
+
+  private final ProductRepository productRepository;
+
+  ProductController(ProductRepository productRepository) {
+    this.productRepository = productRepository;
+  }
+
+  @GetMapping
+  List<Product> getAll() {
+    return productRepository.getAll();
+  }
+
+  @PostMapping
+  @ResponseStatus(HttpStatus.CREATED)
+  Product createProduct(@RequestBody @Valid Product product) {
+    return productRepository.create(product);
+  }
+}
+```
+
+### Configure OAuth 2.0 security
+
+Create a `SecurityConfig` class that protects the API endpoints using JWT
+token-based authentication:
+
+```java
+package com.testcontainers.products.config;
+
+import static org.springframework.security.config.Customizer.withDefaults;
+
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.http.HttpMethod;
+import org.springframework.security.config.annotation.web.builders.HttpSecurity;
+import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
+import org.springframework.security.config.annotation.web.configurers.CorsConfigurer;
+import org.springframework.security.config.annotation.web.configurers.CsrfConfigurer;
+import org.springframework.security.config.http.SessionCreationPolicy;
+import org.springframework.security.web.SecurityFilterChain;
+
+@Configuration
+@EnableWebSecurity
+class SecurityConfig {
+
+  @Bean
+  SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
+    http
+      .authorizeHttpRequests(c ->
+        c
+          .requestMatchers(HttpMethod.GET, "/api/products")
+          .permitAll()
+          .requestMatchers(HttpMethod.POST, "/api/products")
+          .authenticated()
+          .anyRequest()
+          .authenticated()
+      )
+      .sessionManagement(c ->
+        c.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
+      )
+      .cors(CorsConfigurer::disable)
+      .csrf(CsrfConfigurer::disable)
+      .oauth2ResourceServer(oauth2 -> oauth2.jwt(withDefaults()));
+    return http.build();
+  }
+}
+```
+
+This configuration:
+
+- Permits unauthenticated access to `GET /api/products`.
+- Requires authentication for `POST /api/products` and all other endpoints.
+- Configures the OAuth 2.0 Resource Server with JWT token-based authentication.
+- Disables CORS and CSRF because this is a stateless API.
+
+Add the JWT issuer URI to `application.properties`:
+
+```properties
+spring.security.oauth2.resourceserver.jwt.issuer-uri=http://localhost:9090/realms/keycloaktcdemo
+```
+
+### Export the Keycloak realm configuration
+
+Before writing the tests, export a Keycloak realm configuration so that the test
+environment can import it automatically. Start a temporary Keycloak instance:
+
+```console
+$ docker run -p 9090:8080 \
+    -e KEYCLOAK_ADMIN=admin \
+    -e KEYCLOAK_ADMIN_PASSWORD=admin \
+    quay.io/keycloak/keycloak:25 start-dev
+```
+
+Open `http://localhost:9090` and sign in to the Admin Console with `admin/admin`.
+Then set up the realm:
+
+1. In the top-left corner, select the realm drop-down and create a realm named
+   `keycloaktcdemo`.
+2. Under the `keycloaktcdemo` realm, create a client with the following
+   settings:
+   - **Client ID**: `product-service`
+   - **Client Authentication**: `On`
+   - **Authentication flow**: select only **Service accounts roles**
+3. On the **Client details** screen, go to the **Credentials** tab and copy the
+   **Client secret** value.
+
+Export the realm configuration:
+
+```console
+$ docker ps
+# copy the keycloak container id
+
+$ docker exec -it <container-id> /bin/bash
+
+$ /opt/keycloak/bin/kc.sh export --dir /opt/keycloak/data/import --realm keycloaktcdemo
+
+$ exit
+
+$ docker cp <container-id>:/opt/keycloak/data/import/keycloaktcdemo-realm.json keycloaktcdemo-realm.json
+```
+
+Copy the exported `keycloaktcdemo-realm.json` file into `src/test/resources`.
+
+## Write tests with Testcontainers
+
+To test the secured API endpoints, you need a running Keycloak instance and a
+PostgreSQL database, plus a started Spring context. Testcontainers spins up both
+services in Docker containers and connects them to Spring through dynamic
+property registration.
+
+### Configure the test containers
+
+Spring Boot's Testcontainers support lets you declare containers as beans. For
+Keycloak, `@ServiceConnection` isn't available, but you can use
+`DynamicPropertyRegistry` to set the JWT issuer URI dynamically.
+
+Create `ContainersConfig.java` under `src/test/java`:
+
+```java
+package com.testcontainers.products;
+
+import dasniko.testcontainers.keycloak.KeycloakContainer;
+import org.springframework.boot.test.context.TestConfiguration;
+import org.springframework.boot.testcontainers.service.connection.ServiceConnection;
+import org.springframework.context.annotation.Bean;
+import org.springframework.test.context.DynamicPropertyRegistry;
+import org.testcontainers.postgresql.PostgreSQLContainer;
+
+@TestConfiguration(proxyBeanMethods = false)
+public class ContainersConfig {
+
+  static String POSTGRES_IMAGE = "postgres:16-alpine";
+  static String KEYCLOAK_IMAGE = "quay.io/keycloak/keycloak:25.0";
+  static String realmImportFile = "/keycloaktcdemo-realm.json";
+  static String realmName = "keycloaktcdemo";
+
+  @Bean
+  @ServiceConnection
+  PostgreSQLContainer postgres() {
+    return new PostgreSQLContainer(POSTGRES_IMAGE);
+  }
+
+  @Bean
+  KeycloakContainer keycloak(DynamicPropertyRegistry registry) {
+    var keycloak = new KeycloakContainer(KEYCLOAK_IMAGE)
+      .withRealmImportFile(realmImportFile);
+    registry.add(
+      "spring.security.oauth2.resourceserver.jwt.issuer-uri",
+      () -> keycloak.getAuthServerUrl() + "/realms/" + realmName
+    );
+    return keycloak;
+  }
+}
+```
+
+This configuration:
+
+- Declares a `PostgreSQLContainer` bean with `@ServiceConnection`, which starts
+  a PostgreSQL container and automatically registers the datasource properties.
+- Declares a `KeycloakContainer` bean using the `quay.io/keycloak/keycloak:25.0`
+  image, imports the realm configuration file, and dynamically registers the JWT
+  issuer URI from the Keycloak container's auth server URL.
+
+### Write the test
+
+Create `ProductControllerTests.java`:
+
+```java
+package com.testcontainers.products.api;
+
+import static io.restassured.RestAssured.given;
+import static io.restassured.RestAssured.when;
+import static java.util.Collections.singletonList;
+import static org.springframework.boot.test.context.SpringBootTest.WebEnvironment.RANDOM_PORT;
+
+import com.fasterxml.jackson.annotation.JsonProperty;
+import com.testcontainers.products.ContainersConfig;
+import io.restassured.RestAssured;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.boot.autoconfigure.security.oauth2.resource.OAuth2ResourceServerProperties;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.boot.test.web.server.LocalServerPort;
+import org.springframework.context.annotation.Import;
+import org.springframework.http.HttpEntity;
+import org.springframework.http.HttpHeaders;
+import org.springframework.http.MediaType;
+import org.springframework.util.LinkedMultiValueMap;
+import org.springframework.util.MultiValueMap;
+import org.springframework.web.client.RestTemplate;
+
+@SpringBootTest(webEnvironment = RANDOM_PORT)
+@Import(ContainersConfig.class)
+class ProductControllerTests {
+
+  static final String GRANT_TYPE_CLIENT_CREDENTIALS = "client_credentials";
+  static final String CLIENT_ID = "product-service";
+  static final String CLIENT_SECRET = "jTJJqdzeCSt3DmypfHZa42vX8U9rQKZ9";
+
+  @LocalServerPort
+  private int port;
+
+  @Autowired
+  OAuth2ResourceServerProperties oAuth2ResourceServerProperties;
+
+  @BeforeEach
+  void setup() {
+    RestAssured.port = port;
+  }
+
+  @Test
+  void shouldGetProductsWithoutAuthToken() {
+    when().get("/api/products").then().statusCode(200);
+  }
+
+  @Test
+  void shouldGetUnauthorizedWhenCreateProductWithoutAuthToken() {
+    given()
+      .contentType("application/json")
+      .body(
+        """
+            {
+                "title": "New Product",
+                "description": "Brand New Product"
+            }
+        """
+      )
+      .when()
+      .post("/api/products")
+      .then()
+      .statusCode(401);
+  }
+
+  @Test
+  void shouldCreateProductWithAuthToken() {
+    String token = getToken();
+
+    given()
+      .header("Authorization", "Bearer " + token)
+      .contentType("application/json")
+      .body(
+        """
+            {
+                "title": "New Product",
+                "description": "Brand New Product"
+            }
+        """
+      )
+      .when()
+      .post("/api/products")
+      .then()
+      .statusCode(201);
+  }
+
+  private String getToken() {
+    RestTemplate restTemplate = new RestTemplate();
+    HttpHeaders httpHeaders = new HttpHeaders();
+    httpHeaders.setContentType(MediaType.APPLICATION_FORM_URLENCODED);
+
+    MultiValueMap<String, String> map = new LinkedMultiValueMap<>();
+    map.put("grant_type", singletonList(GRANT_TYPE_CLIENT_CREDENTIALS));
+    map.put("client_id", singletonList(CLIENT_ID));
+    map.put("client_secret", singletonList(CLIENT_SECRET));
+
+    String authServerUrl =
+      oAuth2ResourceServerProperties.getJwt().getIssuerUri() +
+      "/protocol/openid-connect/token";
+
+    var request = new HttpEntity<>(map, httpHeaders);
+    KeyCloakToken token = restTemplate.postForObject(
+      authServerUrl,
+      request,
+      KeyCloakToken.class
+    );
+
+    assert token != null;
+    return token.accessToken();
+  }
+
+  record KeyCloakToken(@JsonProperty("access_token") String accessToken) {}
+}
+```
+
+Here's what the tests cover:
+
+- `shouldGetProductsWithoutAuthToken()` invokes `GET /api/products` without an
+  `Authorization` header. Because this endpoint is configured to permit
+  unauthenticated access, the response status code is 200.
+- `shouldGetUnauthorizedWhenCreateProductWithoutAuthToken()` invokes the secured
+  `POST /api/products` endpoint without an `Authorization` header and asserts
+  the response status code is 401 (Unauthorized).
+- `shouldCreateProductWithAuthToken()` first obtains an `access_token` using the
+  Client Credentials flow. It then includes the token as a Bearer token in the
+  `Authorization` header when invoking `POST /api/products` and asserts the
+  response status code is 201 (Created).
+
+The `getToken()` helper method requests an access token from the Keycloak token
+endpoint using the client ID and client secret that were configured in the
+exported realm.
+
+### Use Testcontainers for local development
+
+Spring Boot's Testcontainers support also works for local development. Create
+`TestApplication.java` under `src/test/java`:
+
+```java
+package com.testcontainers.products;
+
+import org.springframework.boot.SpringApplication;
+
+public class TestApplication {
+
+  public static void main(String[] args) {
+    SpringApplication
+      .from(Application::main)
+      .with(ContainersConfig.class)
+      .run(args);
+  }
+}
+```
+
+Run `TestApplication.java` from your IDE instead of the main `Application.java`.
+It starts the containers defined in `ContainersConfig` and configures the
+application to use the dynamically registered properties, so you don't have to
+install or configure PostgreSQL and Keycloak manually.
+
+## Run tests and next steps
+
+### Run the tests
+
+```console
+$ ./mvnw test
+```
+
+Or with Gradle:
+
+```console
+$ ./gradlew test
+```
+
+You should see the Keycloak and PostgreSQL Docker containers start with the
+realm settings imported and the tests pass. After the tests finish, the
+containers stop and are removed automatically.
+
+### Summary
+
+The Testcontainers Keycloak module lets you develop and test applications using a
+real Keycloak server instead of mocks. Testing against a real OAuth 2.0
+provider that mirrors your production setup gives you more confidence in your
+security configuration and token-based authentication flows.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Getting started with Testcontainers in a Java Spring Boot project](https://testcontainers.com/guides/testing-spring-boot-rest-api-using-testcontainers/)
+- [Testcontainers Keycloak module](https://testcontainers.com/modules/keycloak/)
+- [testcontainers-keycloak GitHub repository](https://github.com/dasniko/testcontainers-keycloak)
+- [Spring Boot OAuth 2.0 Resource Server](https://docs.spring.io/spring-security/reference/servlet/oauth2/resource-server/index.html)
diff --git a/content/guides/testcontainers-java-lifecycle.md b/content/guides/testcontainers-java-lifecycle.md
new file mode 100644
index 000000000000..2db26128fc9e
--- /dev/null
+++ b/content/guides/testcontainers-java-lifecycle.md
@@ -0,0 +1,469 @@
+---
+title: Testcontainers container lifecycle management using JUnit 5
+linkTitle: Container lifecycle (Java)
+description: Learn how to manage Testcontainers container lifecycle using JUnit 5 callbacks, extension annotations, and the singleton containers pattern.
+keywords: testcontainers, java, testing, junit, lifecycle, singleton containers, postgresql
+summary: |
+  Learn different approaches to manage container lifecycle with Testcontainers
+  using JUnit 5 lifecycle callbacks, extension annotations, and the singleton
+  containers pattern.
+aliases:
+  - /guides/testcontainers-java-lifecycle/create-project/
+  - /guides/testcontainers-java-lifecycle/extension-annotations/
+  - /guides/testcontainers-java-lifecycle/lifecycle-callbacks/
+  - /guides/testcontainers-java-lifecycle/singleton-containers/
+params:
+  tags: [testing]
+  time: 20 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-testcontainers-lifecycle -->
+
+In this guide, you will learn how to:
+
+- Start and stop containers using JUnit 5 lifecycle callbacks
+- Manage containers using JUnit 5 extension annotations (`@Testcontainers` and `@Container`)
+- Share containers across multiple test classes using the singleton containers pattern
+- Avoid a common misconfiguration when combining extension annotations with singleton containers
+
+## Prerequisites
+
+- Java 17+
+- Your preferred IDE
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the project and business logic
+
+### Set up the project
+
+Create a Java project with Maven and add the required dependencies:
+
+```xml
+<dependencies>
+    <dependency>
+        <groupId>org.postgresql</groupId>
+        <artifactId>postgresql</artifactId>
+        <version>42.7.3</version>
+    </dependency>
+    <dependency>
+        <groupId>ch.qos.logback</groupId>
+        <artifactId>logback-classic</artifactId>
+        <version>1.5.6</version>
+    </dependency>
+    <dependency>
+        <groupId>org.junit.jupiter</groupId>
+        <artifactId>junit-jupiter</artifactId>
+        <version>5.10.2</version>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-junit-jupiter</artifactId>
+        <version>2.0.4</version>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-postgresql</artifactId>
+        <version>2.0.4</version>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+```
+
+### Create the business logic
+
+Create a `Customer` record:
+
+```java
+package com.testcontainers.demo;
+
+public record Customer(Long id, String name) {}
+```
+
+Create a `CustomerService` class with methods to create, retrieve, and delete
+customers:
+
+```java
+package com.testcontainers.demo;
+
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Optional;
+
+public class CustomerService {
+
+  private final String url;
+  private final String username;
+  private final String password;
+
+  public CustomerService(String url, String username, String password) {
+    this.url = url;
+    this.username = username;
+    this.password = password;
+    createCustomersTableIfNotExists();
+  }
+
+  public void createCustomer(Customer customer) {
+    try (Connection conn = this.getConnection()) {
+      PreparedStatement pstmt = conn.prepareStatement(
+        "insert into customers(id,name) values(?,?)"
+      );
+      pstmt.setLong(1, customer.id());
+      pstmt.setString(2, customer.name());
+      pstmt.execute();
+    } catch (SQLException e) {
+      throw new RuntimeException(e);
+    }
+  }
+
+  public List<Customer> getAllCustomers() {
+    List<Customer> customers = new ArrayList<>();
+    try (Connection conn = this.getConnection()) {
+      PreparedStatement pstmt = conn.prepareStatement(
+        "select id,name from customers"
+      );
+      ResultSet rs = pstmt.executeQuery();
+      while (rs.next()) {
+        long id = rs.getLong("id");
+        String name = rs.getString("name");
+        customers.add(new Customer(id, name));
+      }
+    } catch (SQLException e) {
+      throw new RuntimeException(e);
+    }
+    return customers;
+  }
+
+  public Optional<Customer> getCustomer(Long customerId) {
+    try (Connection conn = this.getConnection()) {
+      PreparedStatement pstmt = conn.prepareStatement(
+        "select id,name from customers where id = ?"
+      );
+      pstmt.setLong(1, customerId);
+      ResultSet rs = pstmt.executeQuery();
+      if (rs.next()) {
+        long id = rs.getLong("id");
+        String name = rs.getString("name");
+        return Optional.of(new Customer(id, name));
+      }
+    } catch (SQLException e) {
+      throw new RuntimeException(e);
+    }
+    return Optional.empty();
+  }
+
+  public void deleteAllCustomers() {
+    try (Connection conn = this.getConnection()) {
+      PreparedStatement pstmt = conn.prepareStatement("delete from customers");
+      pstmt.execute();
+    } catch (SQLException e) {
+      throw new RuntimeException(e);
+    }
+  }
+
+  private void createCustomersTableIfNotExists() {
+    try (Connection conn = this.getConnection()) {
+      PreparedStatement pstmt = conn.prepareStatement(
+        """
+        create table if not exists customers (
+            id bigint not null,
+            name varchar not null,
+            primary key (id)
+        )
+        """
+      );
+      pstmt.execute();
+    } catch (SQLException e) {
+      throw new RuntimeException(e);
+    }
+  }
+
+  private Connection getConnection() {
+    try {
+      return DriverManager.getConnection(url, username, password);
+    } catch (Exception e) {
+      throw new RuntimeException(e);
+    }
+  }
+}
+```
+
+## JUnit 5 lifecycle callbacks
+
+When testing with Testcontainers, you want to start the required containers
+before executing any tests and remove them afterwards. You can use JUnit 5
+`@BeforeAll` and `@AfterAll` lifecycle callback methods for this:
+
+```java
+package com.testcontainers.demo;
+
+import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.junit.jupiter.api.Assertions.assertTrue;
+
+import java.util.List;
+import java.util.Optional;
+import org.junit.jupiter.api.AfterAll;
+import org.junit.jupiter.api.BeforeAll;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.testcontainers.postgresql.PostgreSQLContainer;
+
+class CustomerServiceWithLifeCycleCallbacksTest {
+
+  static PostgreSQLContainer postgres = new PostgreSQLContainer(
+    "postgres:16-alpine"
+  );
+
+  CustomerService customerService;
+
+  @BeforeAll
+  static void startContainers() {
+    postgres.start();
+  }
+
+  @AfterAll
+  static void stopContainers() {
+    postgres.stop();
+  }
+
+  @BeforeEach
+  void setUp() {
+    customerService =
+    new CustomerService(
+      postgres.getJdbcUrl(),
+      postgres.getUsername(),
+      postgres.getPassword()
+    );
+    customerService.deleteAllCustomers();
+  }
+
+  @Test
+  void shouldCreateCustomer() {
+    customerService.createCustomer(new Customer(1L, "George"));
+
+    Optional<Customer> customer = customerService.getCustomer(1L);
+    assertTrue(customer.isPresent());
+    assertEquals(1L, customer.get().id());
+    assertEquals("George", customer.get().name());
+  }
+
+  @Test
+  void shouldGetCustomers() {
+    customerService.createCustomer(new Customer(1L, "George"));
+    customerService.createCustomer(new Customer(2L, "John"));
+
+    List<Customer> customers = customerService.getAllCustomers();
+    assertEquals(2, customers.size());
+  }
+}
+```
+
+Here's what the code does:
+
+- `PostgreSQLContainer` is declared as a **static field**. The container starts
+  before all tests and stops after all tests in this class.
+- `@BeforeAll` starts the container, `@AfterAll` stops it.
+- `@BeforeEach` initializes `CustomerService` with the container's JDBC
+  parameters and deletes all rows to give each test a clean database.
+
+Key observations:
+
+- Because the container is a **static field**, it's shared across all test
+  methods in the class. You can declare it as a non-static field and use
+  `@BeforeEach`/`@AfterEach` to start a new container per test, but this
+  isn't recommended as it's resource-intensive.
+- Even without explicitly stopping the container in `@AfterAll`, Testcontainers
+  uses the [Ryuk container](https://github.com/testcontainers/moby-ryuk) to
+  clean up containers automatically when the JVM exits.
+
+## JUnit 5 extension annotations
+
+The Testcontainers library provides a JUnit 5 extension that simplifies
+starting and stopping containers using annotations. To use it, add the
+`org.testcontainers:testcontainers-junit-jupiter` test dependency.
+
+```java
+package com.testcontainers.demo;
+
+import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.junit.jupiter.api.Assertions.assertTrue;
+
+import java.util.List;
+import java.util.Optional;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.testcontainers.postgresql.PostgreSQLContainer;
+import org.testcontainers.junit.jupiter.Container;
+import org.testcontainers.junit.jupiter.Testcontainers;
+
+@Testcontainers
+class CustomerServiceWithJUnit5ExtensionTest {
+
+  @Container
+  static PostgreSQLContainer postgres = new PostgreSQLContainer(
+    "postgres:16-alpine"
+  );
+
+  CustomerService customerService;
+
+  @BeforeEach
+  void setUp() {
+    customerService =
+    new CustomerService(
+      postgres.getJdbcUrl(),
+      postgres.getUsername(),
+      postgres.getPassword()
+    );
+    customerService.deleteAllCustomers();
+  }
+
+  @Test
+  void shouldCreateCustomer() {
+    customerService.createCustomer(new Customer(1L, "George"));
+
+    Optional<Customer> customer = customerService.getCustomer(1L);
+    assertTrue(customer.isPresent());
+    assertEquals(1L, customer.get().id());
+    assertEquals("George", customer.get().name());
+  }
+
+  @Test
+  void shouldGetCustomers() {
+    customerService.createCustomer(new Customer(1L, "George"));
+    customerService.createCustomer(new Customer(2L, "John"));
+
+    List<Customer> customers = customerService.getAllCustomers();
+    assertEquals(2, customers.size());
+  }
+}
+```
+
+Instead of manually starting and stopping the container in `@BeforeAll` and
+`@AfterAll`, the `@Testcontainers` annotation on the class and the
+`@Container` annotation on the field handle it automatically:
+
+- The extension finds all `@Container`-annotated fields.
+- **Static fields** start once before all tests and stop after all tests.
+- **Instance fields** start before each test and stop after each test (not
+  recommended — it's resource-intensive).
+
+## Singleton containers pattern
+
+As the number of test classes grows, starting containers for each class adds
+up. The singleton containers pattern starts all required containers once in a
+common base class and reuses them across all integration tests.
+
+### Define the base class
+
+Create an abstract base class that starts the containers in a static
+initializer:
+
+```java
+package com.testcontainers.demo;
+
+import org.testcontainers.postgresql.PostgreSQLContainer;
+import org.testcontainers.kafka.ConfluentKafkaContainer;
+
+public abstract class AbstractIntegrationTest {
+
+   static PostgreSQLContainer postgres = new PostgreSQLContainer(
+           "postgres:16-alpine");
+   static ConfluentKafkaContainer kafka = new ConfluentKafkaContainer(
+           "confluentinc/cp-kafka:7.8.0");
+
+   static {
+       postgres.start();
+       kafka.start();
+   }
+}
+```
+
+The containers start once when the class loads and Testcontainers uses the
+[Ryuk container](https://github.com/testcontainers/moby-ryuk) to remove them
+after the JVM exits.
+
+> [!TIP]
+> Instead of starting containers sequentially, start them in parallel using
+> `Startables.deepStart(postgres, kafka).join();`
+
+### Extend the base class
+
+Each test class inherits from the base class and reuses the same containers:
+
+```java
+class ProductControllerTest extends AbstractIntegrationTest {
+
+   ProductRepository productRepository;
+
+   @BeforeEach
+   void setUp() {
+       productRepository = new ProductRepository(...);
+       productRepository.deleteAll();
+   }
+
+   @Test
+   void shouldGetAllProducts() {
+       // test logic using the shared postgres container
+   }
+}
+```
+
+### Avoid a common misconfiguration
+
+A common mistake is combining singleton containers with the `@Testcontainers`
+and `@Container` annotations:
+
+```java
+// DON'T DO THIS — containers will stop after each test class
+@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
+@Testcontainers
+public abstract class AbstractIntegrationTest {
+
+   @Container
+   static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>(
+           DockerImageName.parse("postgres:16-alpine"));
+
+   @DynamicPropertySource
+   static void configureProperties(DynamicPropertyRegistry registry) {
+       registry.add("spring.datasource.url", postgres::getJdbcUrl);
+       registry.add("spring.datasource.username", postgres::getUsername);
+       registry.add("spring.datasource.password", postgres::getPassword);
+   }
+}
+```
+
+The `@Testcontainers` extension stops containers at the end of **each test
+class**. Subsequent test classes reuse the cached Spring context, but the
+containers are already stopped — causing connection failures.
+
+Instead, use a static initializer or `@BeforeAll` to start the containers,
+without the `@Testcontainers` and `@Container` annotations.
+
+### Summary
+
+- Use **JUnit 5 lifecycle callbacks** (`@BeforeAll`/`@AfterAll`) for
+  explicit control over container startup and shutdown.
+- Use **extension annotations** (`@Testcontainers`/`@Container`) for less
+  boilerplate in single test classes.
+- Use the **singleton containers pattern** (static initializer in a base class)
+  to share containers across multiple test classes.
+- Don't mix singleton containers with `@Testcontainers`/`@Container`
+  annotations.
+
+### Further reading
+
+- [Testcontainers JUnit 5 quickstart](https://java.testcontainers.org/quickstart/junit_5_quickstart/)
+- [Testcontainers singleton containers pattern](https://java.testcontainers.org/test_framework_integration/manual_lifecycle_control/#singleton-containers)
+- [Testing a Spring Boot REST API with Testcontainers](/guides/testcontainers-java-spring-boot-rest-api/)
diff --git a/content/guides/testcontainers-java-micronaut-kafka.md b/content/guides/testcontainers-java-micronaut-kafka.md
new file mode 100644
index 000000000000..4aa9e9263765
--- /dev/null
+++ b/content/guides/testcontainers-java-micronaut-kafka.md
@@ -0,0 +1,472 @@
+---
+title: Testing Micronaut Kafka Listener using Testcontainers
+linkTitle: Micronaut Kafka
+description: Learn how to test a Micronaut Kafka listener using Testcontainers with Kafka and MySQL modules.
+keywords: testcontainers, java, micronaut, testing, kafka, mysql, jpa, awaitility
+summary: |
+  Learn how to create a Micronaut application with a Kafka listener that persists data in MySQL,
+  then test it using Testcontainers Kafka and MySQL modules with Awaitility.
+aliases:
+  - /guides/testcontainers-java-micronaut-kafka/create-project/
+  - /guides/testcontainers-java-micronaut-kafka/run-tests/
+  - /guides/testcontainers-java-micronaut-kafka/write-tests/
+params:
+  tags: [testing]
+  time: 25 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-testing-micronaut-kafka-listener -->
+
+In this guide, you'll learn how to:
+
+- Create a Micronaut application with Kafka integration
+- Implement a Kafka listener and persist data in a MySQL database
+- Test the Kafka listener using Testcontainers and Awaitility
+
+## Prerequisites
+
+- Java 17+
+- Maven or Gradle
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Micronaut project
+
+### Set up the project
+
+Create a Micronaut project from [Micronaut Launch](https://micronaut.io/launch) by
+selecting the **kafka**, **data-jpa**, **mysql**, **awaitility**, **assertj**, and
+**testcontainers** features.
+
+Alternatively, clone the
+[guide repository](https://github.com/testcontainers/tc-guide-testing-micronaut-kafka-listener).
+
+You'll use the [Awaitility](http://www.awaitility.org/) library to assert the
+expectations of an asynchronous process flow.
+
+The key dependencies in `pom.xml` are:
+
+```xml
+<parent>
+    <groupId>io.micronaut.platform</groupId>
+    <artifactId>micronaut-parent</artifactId>
+    <version>4.1.4</version>
+</parent>
+<dependencies>
+    <dependency>
+        <groupId>io.micronaut.data</groupId>
+        <artifactId>micronaut-data-hibernate-jpa</artifactId>
+        <scope>compile</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.micronaut.kafka</groupId>
+        <artifactId>micronaut-kafka</artifactId>
+        <scope>compile</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.micronaut.serde</groupId>
+        <artifactId>micronaut-serde-jackson</artifactId>
+        <scope>compile</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.micronaut.sql</groupId>
+        <artifactId>micronaut-jdbc-hikari</artifactId>
+        <scope>compile</scope>
+    </dependency>
+    <dependency>
+        <groupId>mysql</groupId>
+        <artifactId>mysql-connector-java</artifactId>
+        <scope>runtime</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.awaitility</groupId>
+        <artifactId>awaitility</artifactId>
+        <version>4.2.0</version>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-junit-jupiter</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-kafka</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-mysql</artifactId>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+```
+
+The Micronaut parent POM manages the Testcontainers BOM, so you don't need to
+specify versions for Testcontainers modules individually.
+
+### Create the JPA entity
+
+The application listens to a topic called `product-price-changes`. When a
+message arrives, it extracts the product code and price from the event payload
+and updates the price for that product in the MySQL database.
+
+Create `Product.java`:
+
+```java
+package com.testcontainers.demo;
+
+import jakarta.persistence.Column;
+import jakarta.persistence.Entity;
+import jakarta.persistence.GeneratedValue;
+import jakarta.persistence.GenerationType;
+import jakarta.persistence.Id;
+import jakarta.persistence.Table;
+import java.math.BigDecimal;
+
+@Entity
+@Table(name = "products")
+public class Product {
+
+    @Id
+    @GeneratedValue(strategy = GenerationType.IDENTITY)
+    private Long id;
+
+    @Column(nullable = false, unique = true)
+    private String code;
+
+    @Column(nullable = false)
+    private String name;
+
+    @Column(nullable = false)
+    private BigDecimal price;
+
+    public Product() {}
+
+    public Product(Long id, String code, String name, BigDecimal price) {
+        this.id = id;
+        this.code = code;
+        this.name = name;
+        this.price = price;
+    }
+
+    public Long getId() {
+        return id;
+    }
+
+    public void setId(Long id) {
+        this.id = id;
+    }
+
+    public String getCode() {
+        return code;
+    }
+
+    public void setCode(String code) {
+        this.code = code;
+    }
+
+    public String getName() {
+        return name;
+    }
+
+    public void setName(String name) {
+        this.name = name;
+    }
+
+    public BigDecimal getPrice() {
+        return price;
+    }
+
+    public void setPrice(BigDecimal price) {
+        this.price = price;
+    }
+}
+```
+
+### Create the Micronaut Data JPA repository
+
+Create a repository interface for the `Product` entity with a method to find a
+product by code and a method to update the price for a given product code:
+
+```java
+package com.testcontainers.demo;
+
+import io.micronaut.data.annotation.Query;
+import io.micronaut.data.annotation.Repository;
+import io.micronaut.data.jpa.repository.JpaRepository;
+import java.math.BigDecimal;
+import java.util.Optional;
+
+@Repository
+public interface ProductRepository extends JpaRepository<Product, Long> {
+
+    Optional<Product> findByCode(String code);
+
+    @Query("update Product p set p.price = :price where p.code = :productCode")
+    void updateProductPrice(String productCode, BigDecimal price);
+}
+```
+
+Unlike Spring Data JPA, Micronaut Data uses compile-time annotation processing
+to implement repository methods, avoiding runtime reflection.
+
+### Create the event payload
+
+Create a record named `ProductPriceChangedEvent` that represents the structure
+of the event payload received from the Kafka topic:
+
+```java
+package com.testcontainers.demo;
+
+import io.micronaut.serde.annotation.Serdeable;
+import java.math.BigDecimal;
+
+@Serdeable
+public record ProductPriceChangedEvent(String productCode, BigDecimal price) {}
+```
+
+The `@Serdeable` annotation tells Micronaut Serialization that this type can be
+serialized and deserialized.
+
+The sender and receiver agree on the following JSON format:
+
+```json
+{
+  "productCode": "P100",
+  "price": 25.0
+}
+```
+
+### Implement the Kafka listener
+
+Create `ProductPriceChangedEventHandler.java`, which handles messages from the
+`product-price-changes` topic and updates the product price in the database:
+
+```java
+package com.testcontainers.demo;
+
+import static io.micronaut.configuration.kafka.annotation.OffsetReset.EARLIEST;
+
+import io.micronaut.configuration.kafka.annotation.KafkaListener;
+import io.micronaut.configuration.kafka.annotation.Topic;
+import jakarta.inject.Singleton;
+import jakarta.transaction.Transactional;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+@Singleton
+@Transactional
+class ProductPriceChangedEventHandler {
+
+    private static final Logger LOG = LoggerFactory.getLogger(ProductPriceChangedEventHandler.class);
+
+    private final ProductRepository productRepository;
+
+    ProductPriceChangedEventHandler(ProductRepository productRepository) {
+        this.productRepository = productRepository;
+    }
+
+    @Topic("product-price-changes")
+    @KafkaListener(offsetReset = EARLIEST, groupId = "demo")
+    public void handle(ProductPriceChangedEvent event) {
+        LOG.info("Received a ProductPriceChangedEvent with productCode:{}: ", event.productCode());
+        productRepository.updateProductPrice(event.productCode(), event.price());
+    }
+}
+```
+
+Key details:
+
+- The `@KafkaListener` annotation marks this class as a Kafka message listener.
+  Setting `offsetReset` to `EARLIEST` makes the listener start consuming
+  messages from the beginning of the partition, which is useful during testing.
+- The `@Topic` annotation specifies which topic to subscribe to.
+- Micronaut handles JSON deserialization of the `ProductPriceChangedEvent`
+  automatically using Micronaut Serialization.
+
+### Configure the datasource
+
+Add the following properties to `src/main/resources/application.properties`:
+
+```properties
+micronaut.application.name=tc-guide-testing-micronaut-kafka-listener
+datasources.default.db-type=mysql
+datasources.default.dialect=MYSQL
+jpa.default.properties.hibernate.hbm2ddl.auto=update
+jpa.default.entity-scan.packages=com.testcontainers.demo
+datasources.default.driver-class-name=com.mysql.cj.jdbc.Driver
+```
+
+Hibernate's `hbm2ddl.auto=update` creates and updates the database schema
+automatically. For testing, you'll override this to `create-drop` in the test
+properties file.
+
+Create `src/test/resources/application-test.properties`:
+
+```properties
+jpa.default.properties.hibernate.hbm2ddl.auto=create-drop
+```
+
+## Write tests with Testcontainers
+
+To test the Kafka listener, you need a running Kafka broker and a MySQL
+database, plus a started Micronaut application context. Testcontainers spins up
+both services in Docker containers and the `TestPropertyProvider` interface
+connects them to Micronaut.
+
+### Create a Kafka client for testing
+
+First, create a `@KafkaClient` interface to publish events in the test:
+
+```java
+package com.testcontainers.demo;
+
+import io.micronaut.configuration.kafka.annotation.KafkaClient;
+import io.micronaut.configuration.kafka.annotation.KafkaKey;
+import io.micronaut.configuration.kafka.annotation.Topic;
+
+@KafkaClient
+public interface ProductPriceChangesClient {
+
+    @Topic("product-price-changes")
+    void send(@KafkaKey String productCode, ProductPriceChangedEvent event);
+}
+```
+
+Key details:
+
+- The `@KafkaClient` annotation designates this interface as a Kafka producer.
+- The `@Topic` annotation specifies the target topic.
+- The `@KafkaKey` annotation marks the parameter used as the Kafka message key.
+  If no such parameter exists, Micronaut sends the record with a null key.
+
+### Write the test
+
+Create `ProductPriceChangedEventHandlerTest.java`:
+
+```java
+package com.testcontainers.demo;
+
+import static java.util.concurrent.TimeUnit.SECONDS;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.awaitility.Awaitility.await;
+
+import io.micronaut.context.annotation.Property;
+import io.micronaut.core.annotation.NonNull;
+import io.micronaut.test.extensions.junit5.annotation.MicronautTest;
+import io.micronaut.test.support.TestPropertyProvider;
+import java.math.BigDecimal;
+import java.time.Duration;
+import java.util.Collections;
+import java.util.Map;
+import java.util.Optional;
+import org.junit.jupiter.api.Test;
+import org.junit.jupiter.api.TestInstance;
+import org.testcontainers.kafka.ConfluentKafkaContainer;
+import org.testcontainers.junit.jupiter.Container;
+import org.testcontainers.junit.jupiter.Testcontainers;
+
+@MicronautTest(transactional = false)
+@Property(name = "datasources.default.driver-class-name", value = "org.testcontainers.jdbc.ContainerDatabaseDriver")
+@Property(name = "datasources.default.url", value = "jdbc:tc:mysql:8.0.32:///db")
+@Testcontainers(disabledWithoutDocker = true)
+@TestInstance(TestInstance.Lifecycle.PER_CLASS)
+class ProductPriceChangedEventHandlerTest implements TestPropertyProvider {
+
+    @Container
+    static final ConfluentKafkaContainer kafka = new ConfluentKafkaContainer("confluentinc/cp-kafka:7.8.0");
+
+    @Override
+    public @NonNull Map<String, String> getProperties() {
+        if (!kafka.isRunning()) {
+            kafka.start();
+        }
+        return Collections.singletonMap("kafka.bootstrap.servers", kafka.getBootstrapServers());
+    }
+
+    @Test
+    void shouldHandleProductPriceChangedEvent(
+            ProductPriceChangesClient productPriceChangesClient, ProductRepository productRepository) {
+        Product product = new Product(null, "P100", "Product One", BigDecimal.TEN);
+        Long id = productRepository.save(product).getId();
+
+        ProductPriceChangedEvent event = new ProductPriceChangedEvent("P100", new BigDecimal("14.50"));
+
+        productPriceChangesClient.send(event.productCode(), event);
+
+        await().pollInterval(Duration.ofSeconds(3)).atMost(10, SECONDS).untilAsserted(() -> {
+            Optional<Product> optionalProduct = productRepository.findByCode("P100");
+            assertThat(optionalProduct).isPresent();
+            assertThat(optionalProduct.get().getCode()).isEqualTo("P100");
+            assertThat(optionalProduct.get().getPrice()).isEqualTo(new BigDecimal("14.50"));
+        });
+
+        productRepository.deleteById(id);
+    }
+}
+```
+
+Here's what the test does:
+
+- `@MicronautTest` initializes the Micronaut application context and the
+  embedded server. Setting `transactional` to `false` prevents each test method
+  from running inside a rolled-back transaction, which is necessary because the
+  Kafka listener processes messages in a separate thread.
+- The `@Property` annotations override the datasource driver and URL to use the
+  Testcontainers special JDBC URL (`jdbc:tc:mysql:8.0.32:///db`). This spins up
+  a MySQL container and configures it as the datasource automatically.
+- `@Testcontainers` and `@Container` manage the Kafka container lifecycle.
+  The `TestPropertyProvider` interface registers the Kafka bootstrap servers
+  with Micronaut so that the producer and consumer connect to the test container.
+- `@TestInstance(TestInstance.Lifecycle.PER_CLASS)` creates a single test
+  instance for all test methods, which is required when implementing
+  `TestPropertyProvider`.
+- The test creates a `Product` record in the database, then sends a
+  `ProductPriceChangedEvent` to the `product-price-changes` topic using the
+  `ProductPriceChangesClient`.
+- Because Kafka message processing is asynchronous, the test uses
+  [Awaitility](http://www.awaitility.org/) to poll every 3 seconds (up to a
+  maximum of 10 seconds) until the product price in the database matches the
+  expected value.
+
+## Run tests and next steps
+
+### Run the tests
+
+```console
+$ ./mvnw test
+```
+
+Or with Gradle:
+
+```console
+$ ./gradlew test
+```
+
+You should see the Kafka and MySQL Docker containers start and all tests pass.
+After the tests finish, the containers stop and are removed automatically.
+
+### Summary
+
+Testing with real Kafka and MySQL instances gives you more confidence in the
+correctness of your code than mocks or embedded alternatives. The
+Testcontainers library manages the container lifecycle so that your integration
+tests run against the same services you use in production.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Testing REST API integrations in Micronaut apps using WireMock](/guides/testcontainers-java-micronaut-wiremock/)
+- [Testing Spring Boot Kafka Listener using Testcontainers](/guides/testcontainers-java-spring-boot-kafka/)
+- [Getting started with Testcontainers in a Java Spring Boot project](https://testcontainers.com/guides/testing-spring-boot-rest-api-using-testcontainers/)
+- [Awaitility](http://www.awaitility.org/)
+- [Testcontainers Kafka module](https://java.testcontainers.org/modules/kafka/)
+- [Testcontainers MySQL module](https://java.testcontainers.org/modules/databases/mysql/)
diff --git a/content/guides/testcontainers-java-micronaut-wiremock.md b/content/guides/testcontainers-java-micronaut-wiremock.md
new file mode 100644
index 000000000000..9cd2b0b05265
--- /dev/null
+++ b/content/guides/testcontainers-java-micronaut-wiremock.md
@@ -0,0 +1,673 @@
+---
+title: Testing REST API integrations in Micronaut apps using WireMock
+linkTitle: Micronaut WireMock
+description: Learn how to test REST API integrations in a Micronaut application using the Testcontainers WireMock module.
+keywords: testcontainers, java, micronaut, testing, wiremock, rest api
+summary: |
+  Learn how to create a Micronaut application that integrates with
+  external REST APIs, then test those integrations using WireMock
+  and the Testcontainers WireMock module.
+aliases:
+  - /guides/testcontainers-java-micronaut-wiremock/create-project/
+  - /guides/testcontainers-java-micronaut-wiremock/run-tests/
+  - /guides/testcontainers-java-micronaut-wiremock/write-tests/
+params:
+  tags: [testing]
+  time: 20 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-testing-rest-api-integrations-in-micronaut-apps-using-wiremock -->
+
+In this guide, you'll learn how to:
+
+- Create a Micronaut application that talks to external REST APIs
+- Test external API integrations using WireMock
+- Use the Testcontainers WireMock module to run WireMock as a Docker container
+
+## Prerequisites
+
+- Java 17+
+- Maven or Gradle
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Micronaut project
+
+### Set up the project
+
+Create a Micronaut project from [Micronaut Launch](https://micronaut.io/launch)
+by selecting the **http-client**, **micronaut-test-rest-assured**, and
+**testcontainers** features.
+
+Alternatively, clone the
+[guide repository](https://github.com/testcontainers/tc-guide-testing-rest-api-integrations-in-micronaut-apps-using-wiremock).
+
+After generating the project, add the **WireMock** and **Testcontainers
+WireMock** libraries as test dependencies. The key dependencies in `pom.xml`
+are:
+
+```xml
+<parent>
+    <groupId>io.micronaut.platform</groupId>
+    <artifactId>micronaut-parent</artifactId>
+    <version>4.1.2</version>
+</parent>
+
+<properties>
+    <jdk.version>17</jdk.version>
+    <micronaut.version>4.1.2</micronaut.version>
+    <micronaut.runtime>netty</micronaut.runtime>
+</properties>
+
+<repositories>
+    <repository>
+        <id>jitpack.io</id>
+        <url>https://jitpack.io</url>
+    </repository>
+</repositories>
+
+<dependencies>
+    <dependency>
+        <groupId>io.micronaut</groupId>
+        <artifactId>micronaut-http-client</artifactId>
+        <scope>compile</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.micronaut</groupId>
+        <artifactId>micronaut-http-server-netty</artifactId>
+        <scope>compile</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.micronaut.serde</groupId>
+        <artifactId>micronaut-serde-jackson</artifactId>
+        <scope>compile</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.micronaut.test</groupId>
+        <artifactId>micronaut-test-junit5</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.micronaut.test</groupId>
+        <artifactId>micronaut-test-rest-assured</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-junit-jupiter</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.wiremock</groupId>
+        <artifactId>wiremock-standalone</artifactId>
+        <version>3.2.0</version>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.wiremock.integrations.testcontainers</groupId>
+        <artifactId>wiremock-testcontainers-module</artifactId>
+        <version>1.0-alpha-13</version>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+```
+
+This guide builds an application that manages video albums. A third-party REST
+API handles photo assets. For demonstration purposes, the application uses the
+publicly available [JSONPlaceholder](https://jsonplaceholder.typicode.com/) API
+as a photo service.
+
+The application exposes a `GET /api/albums/{albumId}` endpoint that calls the
+photo service to fetch photos for a given album.
+[WireMock](https://wiremock.org/) is a tool for building mock APIs.
+Testcontainers provides a
+[WireMock module](https://testcontainers.com/modules/wiremock/) that runs
+WireMock as a Docker container.
+
+### Create the Album and Photo models
+
+Create `Album.java` using Java records. Annotate both records with `@Serdeable`
+to allow serialization and deserialization:
+
+```java
+package com.testcontainers.demo;
+
+import io.micronaut.serde.annotation.Serdeable;
+import java.util.List;
+
+@Serdeable
+public record Album(Long albumId, List<Photo> photos) {}
+
+@Serdeable
+record Photo(Long id, String title, String url, String thumbnailUrl) {}
+```
+
+### Create the PhotoServiceClient
+
+Micronaut provides
+[declarative HTTP client](https://docs.micronaut.io/latest/guide/#httpClient)
+support. Create an interface with a method that fetches photos for a given album
+ID:
+
+```java
+package com.testcontainers.demo;
+
+import io.micronaut.http.annotation.Get;
+import io.micronaut.http.annotation.PathVariable;
+import io.micronaut.http.client.annotation.Client;
+import java.util.List;
+
+@Client(id = "photosapi")
+interface PhotoServiceClient {
+
+    @Get("/albums/{albumId}/photos")
+    List<Photo> getPhotos(@PathVariable Long albumId);
+}
+```
+
+The `@Client(id = "photosapi")` annotation ties this client to a named
+configuration. Add the following property to
+`src/main/resources/application.properties` to set the base URL:
+
+```properties
+micronaut.http.services.photosapi.url=https://jsonplaceholder.typicode.com
+```
+
+### Create the REST API endpoint
+
+Create `AlbumController.java`:
+
+```java
+package com.testcontainers.demo;
+
+import static io.micronaut.scheduling.TaskExecutors.BLOCKING;
+
+import io.micronaut.http.annotation.Controller;
+import io.micronaut.http.annotation.Get;
+import io.micronaut.http.annotation.PathVariable;
+import io.micronaut.scheduling.annotation.ExecuteOn;
+
+@Controller("/api")
+class AlbumController {
+
+    private final PhotoServiceClient photoServiceClient;
+
+    AlbumController(PhotoServiceClient photoServiceClient) {
+        this.photoServiceClient = photoServiceClient;
+    }
+
+    @ExecuteOn(BLOCKING)
+    @Get("/albums/{albumId}")
+    public Album getAlbumById(@PathVariable Long albumId) {
+        return new Album(albumId, photoServiceClient.getPhotos(albumId));
+    }
+}
+```
+
+Here's what this controller does:
+
+- `@Controller("/api")` maps the controller to the `/api` path.
+- Constructor injection provides a `PhotoServiceClient` bean.
+- `@ExecuteOn(BLOCKING)` offloads blocking I/O to a separate thread pool so it
+  doesn't block the event loop.
+- `@Get("/albums/{albumId}")` maps the `getAlbumById()` method to an HTTP GET
+  request.
+
+This endpoint calls the photo service for a given album ID and returns a
+response like:
+
+```json
+{
+  "albumId": 1,
+  "photos": [
+    {
+      "id": 51,
+      "title": "non sunt voluptatem placeat consequuntur rem incidunt",
+      "url": "https://via.placeholder.com/600/8e973b",
+      "thumbnailUrl": "https://via.placeholder.com/150/8e973b"
+    },
+    {
+      "id": 52,
+      "title": "eveniet pariatur quia nobis reiciendis laboriosam ea",
+      "url": "https://via.placeholder.com/600/121fa4",
+      "thumbnailUrl": "https://via.placeholder.com/150/121fa4"
+    }
+  ]
+}
+```
+
+## Write tests with WireMock and Testcontainers
+
+Mocking external API interactions at the HTTP protocol level, rather than
+mocking Java methods, lets you verify marshalling and unmarshalling behavior and
+simulate network issues.
+
+### Test with WireMock's JUnit 5 extension
+
+The first approach uses WireMock's `WireMockExtension` to start an in-process
+WireMock server on a dynamic port.
+
+Create `AlbumControllerTest.java`:
+
+```java
+package com.testcontainers.demo;
+
+import static com.github.tomakehurst.wiremock.client.WireMock.aResponse;
+import static com.github.tomakehurst.wiremock.client.WireMock.urlMatching;
+import static com.github.tomakehurst.wiremock.core.WireMockConfiguration.wireMockConfig;
+import static io.restassured.RestAssured.given;
+import static org.hamcrest.CoreMatchers.is;
+import static org.hamcrest.Matchers.hasSize;
+
+import com.github.tomakehurst.wiremock.client.WireMock;
+import com.github.tomakehurst.wiremock.junit5.WireMockExtension;
+import io.micronaut.context.ApplicationContext;
+import io.micronaut.http.MediaType;
+import io.micronaut.runtime.server.EmbeddedServer;
+import io.restassured.RestAssured;
+import io.restassured.http.ContentType;
+import java.util.Collections;
+import java.util.Map;
+import org.junit.jupiter.api.Test;
+import org.junit.jupiter.api.extension.RegisterExtension;
+
+class AlbumControllerTest {
+
+    @RegisterExtension
+    static WireMockExtension wireMock = WireMockExtension.newInstance()
+            .options(wireMockConfig().dynamicPort())
+            .build();
+
+    private Map<String, Object> getProperties() {
+        return Collections.singletonMap("micronaut.http.services.photosapi.url", wireMock.baseUrl());
+    }
+
+    @Test
+    void shouldGetAlbumById() {
+        try (EmbeddedServer server = ApplicationContext.run(EmbeddedServer.class, getProperties())) {
+            RestAssured.port = server.getPort();
+            Long albumId = 1L;
+            String responseJson =
+                    """
+            [
+                 {
+                     "id": 1,
+                     "title": "accusamus beatae ad facilis cum similique qui sunt",
+                     "url": "https://via.placeholder.com/600/92c952",
+                     "thumbnailUrl": "https://via.placeholder.com/150/92c952"
+                 },
+                 {
+                     "id": 2,
+                     "title": "reprehenderit est deserunt velit ipsam",
+                     "url": "https://via.placeholder.com/600/771796",
+                     "thumbnailUrl": "https://via.placeholder.com/150/771796"
+                 }
+             ]
+            """;
+            wireMock.stubFor(WireMock.get(urlMatching("/albums/" + albumId + "/photos"))
+                    .willReturn(aResponse()
+                            .withHeader("Content-Type", MediaType.APPLICATION_JSON)
+                            .withBody(responseJson)));
+
+            given().contentType(ContentType.JSON)
+                    .when()
+                    .get("/api/albums/{albumId}", albumId)
+                    .then()
+                    .statusCode(200)
+                    .body("albumId", is(albumId.intValue()))
+                    .body("photos", hasSize(2));
+        }
+    }
+
+    @Test
+    void shouldReturnServerErrorWhenPhotoServiceCallFailed() {
+        try (EmbeddedServer server = ApplicationContext.run(EmbeddedServer.class, getProperties())) {
+            RestAssured.port = server.getPort();
+            Long albumId = 2L;
+            wireMock.stubFor(WireMock.get(urlMatching("/albums/" + albumId + "/photos"))
+                    .willReturn(aResponse().withStatus(500)));
+
+            given().contentType(ContentType.JSON)
+                    .when()
+                    .get("/api/albums/{albumId}", albumId)
+                    .then()
+                    .statusCode(500);
+        }
+    }
+}
+```
+
+Here's what this test does:
+
+- `WireMockExtension` starts a WireMock server on a dynamic port.
+- The `getProperties()` method overrides `micronaut.http.services.photosapi.url`
+  to point at the WireMock endpoint, so the application talks to WireMock
+  instead of the real photo service.
+- `shouldGetAlbumById()` configures a mock response for
+  `/albums/{albumId}/photos`, sends a request to the application's
+  `/api/albums/{albumId}` endpoint, and verifies the response body.
+- `shouldReturnServerErrorWhenPhotoServiceCallFailed()` configures WireMock to
+  return a 500 status and verifies the application propagates that error.
+
+### Stub using JSON mapping files
+
+Instead of stubbing with the WireMock Java API, you can use JSON mapping-based
+configuration.
+
+Create `src/test/resources/wiremock/mappings/get-album-photos.json`:
+
+```json
+{
+  "mappings": [
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/([0-9]+)/photos"
+      },
+      "response": {
+        "status": 200,
+        "headers": {
+          "Content-Type": "application/json"
+        },
+        "bodyFileName": "album-photos-resp-200.json"
+      }
+    },
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/2/photos"
+      },
+      "response": {
+        "status": 500,
+        "headers": {
+          "Content-Type": "application/json"
+        }
+      }
+    },
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/3/photos"
+      },
+      "response": {
+        "status": 200,
+        "headers": {
+          "Content-Type": "application/json"
+        },
+        "jsonBody": []
+      }
+    }
+  ]
+}
+```
+
+Create `src/test/resources/wiremock/__files/album-photos-resp-200.json`:
+
+```json
+[
+  {
+    "id": 1,
+    "title": "accusamus beatae ad facilis cum similique qui sunt",
+    "url": "https://via.placeholder.com/600/92c952",
+    "thumbnailUrl": "https://via.placeholder.com/150/92c952"
+  },
+  {
+    "id": 2,
+    "title": "reprehenderit est deserunt velit ipsam",
+    "url": "https://via.placeholder.com/600/771796",
+    "thumbnailUrl": "https://via.placeholder.com/150/771796"
+  }
+]
+```
+
+Then initialize WireMock to load stub mappings from these files:
+
+```java
+@RegisterExtension
+static WireMockExtension wireMock = WireMockExtension.newInstance()
+     .options(
+         wireMockConfig()
+            .dynamicPort()
+            .usingFilesUnderClasspath("wiremock")
+    )
+    .build();
+```
+
+With mapping files-based stubbing in place, write tests without needing
+programmatic stubs:
+
+```java
+@Test
+void shouldGetAlbumById() {
+    Long albumId = 1L;
+    try (EmbeddedServer server = ApplicationContext.run(EmbeddedServer.class, getProperties())) {
+        RestAssured.port = server.getPort();
+
+        given().contentType(ContentType.JSON)
+                .when()
+                .get("/api/albums/{albumId}", albumId)
+                .then()
+                .statusCode(200)
+                .body("albumId", is(albumId.intValue()))
+                .body("photos", hasSize(2));
+    }
+}
+```
+
+### Use the Testcontainers WireMock module
+
+The [Testcontainers WireMock module](https://testcontainers.com/modules/wiremock/)
+provisions a WireMock server as a standalone container within your tests, based
+on [WireMock Docker](https://github.com/wiremock/wiremock-docker).
+
+Create `src/test/resources/mocks-config.json` with the stub mappings:
+
+```json
+{
+  "mappings": [
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/([0-9]+)/photos"
+      },
+      "response": {
+        "status": 200,
+        "headers": {
+          "Content-Type": "application/json"
+        },
+        "bodyFileName": "album-photos-response.json"
+      }
+    },
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/2/photos"
+      },
+      "response": {
+        "status": 500,
+        "headers": {
+          "Content-Type": "application/json"
+        }
+      }
+    },
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/3/photos"
+      },
+      "response": {
+        "status": 200,
+        "headers": {
+          "Content-Type": "application/json"
+        },
+        "jsonBody": []
+      }
+    }
+  ]
+}
+```
+
+Create `src/test/resources/album-photos-response.json`:
+
+```json
+[
+  {
+    "id": 1,
+    "title": "accusamus beatae ad facilis cum similique qui sunt",
+    "url": "https://via.placeholder.com/600/92c952",
+    "thumbnailUrl": "https://via.placeholder.com/150/92c952"
+  },
+  {
+    "id": 2,
+    "title": "reprehenderit est deserunt velit ipsam",
+    "url": "https://via.placeholder.com/600/771796",
+    "thumbnailUrl": "https://via.placeholder.com/150/771796"
+  }
+]
+```
+
+Create `AlbumControllerTestcontainersTests.java`:
+
+```java
+package com.testcontainers.demo;
+
+import static io.restassured.RestAssured.given;
+import static org.hamcrest.CoreMatchers.is;
+import static org.hamcrest.Matchers.hasSize;
+import static org.hamcrest.Matchers.nullValue;
+
+import io.micronaut.context.ApplicationContext;
+import io.micronaut.core.annotation.NonNull;
+import io.micronaut.runtime.server.EmbeddedServer;
+import io.restassured.RestAssured;
+import io.restassured.http.ContentType;
+import java.util.Collections;
+import java.util.Map;
+import org.junit.jupiter.api.Test;
+import org.testcontainers.junit.jupiter.Container;
+import org.testcontainers.junit.jupiter.Testcontainers;
+import org.wiremock.integrations.testcontainers.WireMockContainer;
+
+@Testcontainers(disabledWithoutDocker = true)
+class AlbumControllerTestcontainersTests {
+
+    @Container
+    static WireMockContainer wiremockServer = new WireMockContainer("wiremock/wiremock:2.35.0")
+            .withMappingFromResource("mocks-config.json")
+            .withFileFromResource("album-photos-response.json");
+
+    @NonNull public Map<String, Object> getProperties() {
+        return Collections.singletonMap("micronaut.http.services.photosapi.url", wiremockServer.getBaseUrl());
+    }
+
+    @Test
+    void shouldGetAlbumById() {
+        Long albumId = 1L;
+        try (EmbeddedServer server = ApplicationContext.run(EmbeddedServer.class, getProperties())) {
+            RestAssured.port = server.getPort();
+
+            given().contentType(ContentType.JSON)
+                    .when()
+                    .get("/api/albums/{albumId}", albumId)
+                    .then()
+                    .statusCode(200)
+                    .body("albumId", is(albumId.intValue()))
+                    .body("photos", hasSize(2));
+        }
+    }
+
+    @Test
+    void shouldReturnServerErrorWhenPhotoServiceCallFailed() {
+        Long albumId = 2L;
+        try (EmbeddedServer server = ApplicationContext.run(EmbeddedServer.class, getProperties())) {
+            RestAssured.port = server.getPort();
+            given().contentType(ContentType.JSON)
+                    .when()
+                    .get("/api/albums/{albumId}", albumId)
+                    .then()
+                    .statusCode(500);
+        }
+    }
+
+    @Test
+    void shouldReturnEmptyPhotos() {
+        Long albumId = 3L;
+        try (EmbeddedServer server = ApplicationContext.run(EmbeddedServer.class, getProperties())) {
+            RestAssured.port = server.getPort();
+            given().contentType(ContentType.JSON)
+                    .when()
+                    .get("/api/albums/{albumId}", albumId)
+                    .then()
+                    .statusCode(200)
+                    .body("albumId", is(albumId.intValue()))
+                    .body("photos", nullValue());
+        }
+    }
+}
+```
+
+Here's what this test does:
+
+- `@Testcontainers` and `@Container` annotations start a `WireMockContainer`
+  using the `wiremock/wiremock:2.35.0` Docker image.
+- `withMappingFromResource("mocks-config.json")` loads stub mappings from the
+  classpath resource.
+- `withFileFromResource("album-photos-response.json")` makes the response body
+  file available to WireMock.
+- `getProperties()` overrides the photo service URL to point at the WireMock
+  container's base URL.
+- `shouldGetAlbumById()` verifies that the application returns the expected
+  album with two photos.
+- `shouldReturnServerErrorWhenPhotoServiceCallFailed()` verifies that a 500
+  from the photo service propagates to the caller.
+- `shouldReturnEmptyPhotos()` verifies the application handles an empty photo
+  list.
+
+## Run tests and next steps
+
+### Run the tests
+
+```console
+$ ./mvnw test
+```
+
+Or with Gradle:
+
+```console
+$ ./gradlew test
+```
+
+You should see the WireMock Docker container start in the console output. It
+acts as the photo service, serving mock responses based on the configured
+expectations. All tests should pass.
+
+### Summary
+
+You built a Micronaut application that integrates with an external REST API
+using declarative HTTP clients, then tested that integration using WireMock and
+the Testcontainers WireMock module. Testing at the HTTP protocol level instead
+of mocking Java methods lets you catch serialization issues and simulate
+realistic failure scenarios.
+
+> [!TIP]
+> Testcontainers WireMock modules are available for Go and Python as well.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Testcontainers WireMock module](https://testcontainers.com/modules/wiremock/)
+- [WireMock documentation](https://wiremock.org/docs/)
+- [Testcontainers JUnit 5 quickstart](https://java.testcontainers.org/quickstart/junit_5_quickstart/)
+- [Testing REST API integrations in Spring Boot using WireMock](/guides/testcontainers-java-wiremock/)
diff --git a/content/guides/testcontainers-java-mockserver.md b/content/guides/testcontainers-java-mockserver.md
new file mode 100644
index 000000000000..fe8a48c137a7
--- /dev/null
+++ b/content/guides/testcontainers-java-mockserver.md
@@ -0,0 +1,445 @@
+---
+title: Testing REST API integrations using MockServer
+linkTitle: MockServer
+description: Learn how to test REST API integrations in a Spring Boot application using the Testcontainers MockServer module.
+keywords: testcontainers, java, spring boot, testing, mockserver, rest api, rest assured
+summary: |
+  Learn how to create a Spring Boot application that integrates with
+  external REST APIs, then test those integrations using Testcontainers
+  and MockServer.
+aliases:
+  - /guides/testcontainers-java-mockserver/create-project/
+  - /guides/testcontainers-java-mockserver/run-tests/
+  - /guides/testcontainers-java-mockserver/write-tests/
+params:
+  tags: [testing]
+  time: 20 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-testing-rest-api-integrations-using-mockserver -->
+
+In this guide, you will learn how to:
+
+- Create a Spring Boot application that talks to external REST APIs
+- Test external API integrations using the Testcontainers MockServer module
+
+## Prerequisites
+
+- Java 17+
+- Maven or Gradle
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Spring Boot project
+
+### Set up the project
+
+Create a Spring Boot project from [Spring Initializr](https://start.spring.io)
+by selecting the **Spring Web**, **Spring Reactive Web**, and **Testcontainers**
+starters.
+
+Alternatively, clone the
+[guide repository](https://github.com/testcontainers/tc-guide-testing-rest-api-integrations-using-mockserver).
+
+After generating the project, add the **REST Assured** and **MockServer**
+libraries as test dependencies. The key dependencies in `pom.xml` are:
+
+```xml
+<properties>
+    <java.version>17</java.version>
+    <testcontainers.version>2.0.4</testcontainers.version>
+</properties>
+<dependencies>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-web</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-webflux</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-test</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-junit-jupiter</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-mockserver</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.mock-server</groupId>
+        <artifactId>mockserver-netty</artifactId>
+        <version>5.15.0</version>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.rest-assured</groupId>
+        <artifactId>rest-assured</artifactId>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+```
+
+Using the Testcontainers BOM (Bill of Materials) is recommended so that you
+don't have to repeat the version for every Testcontainers module dependency.
+
+This guide builds an application that manages video albums. A third-party REST
+API handles photo assets. For demonstration purposes, the application uses the
+publicly available [JSONPlaceholder](https://jsonplaceholder.typicode.com/) API
+as a photo service.
+
+The application exposes a `GET /api/albums/{albumId}` endpoint that calls the
+photo service to fetch photos for a given album.
+[MockServer](https://www.mock-server.com/) is a library for mocking HTTP-based
+services. Testcontainers provides a
+[MockServer module](https://java.testcontainers.org/modules/mockserver/) that
+runs MockServer as a Docker container.
+
+### Create the Album and Photo models
+
+Create `Album.java` using Java records:
+
+```java
+package com.testcontainers.demo;
+
+import java.util.List;
+
+public record Album(Long albumId, List<Photo> photos) {}
+
+record Photo(Long id, String title, String url, String thumbnailUrl) {}
+```
+
+### Create the PhotoServiceClient interface
+
+Spring Framework 6 introduced
+[declarative HTTP client support](https://docs.spring.io/spring-framework/reference/integration/rest-clients.html#rest-http-interface).
+Create an interface with a method that fetches photos for a given album ID:
+
+```java
+package com.testcontainers.demo;
+
+import java.util.List;
+import org.springframework.web.bind.annotation.PathVariable;
+import org.springframework.web.service.annotation.GetExchange;
+
+interface PhotoServiceClient {
+  @GetExchange("/albums/{albumId}/photos")
+  List<Photo> getPhotos(@PathVariable Long albumId);
+}
+```
+
+### Register PhotoServiceClient as a bean
+
+To generate a runtime implementation of `PhotoServiceClient`, register it as a
+Spring bean using `HttpServiceProxyFactory`. The factory requires an
+`HttpClientAdapter` implementation. Spring Boot provides `WebClientAdapter` as
+part of the `spring-webflux` library:
+
+```java
+package com.testcontainers.demo;
+
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.web.reactive.function.client.WebClient;
+import org.springframework.web.reactive.function.client.support.WebClientAdapter;
+import org.springframework.web.service.invoker.HttpServiceProxyFactory;
+
+@Configuration
+public class AppConfig {
+
+  @Bean
+  public PhotoServiceClient photoServiceClient(
+    @Value("${photos.api.base-url}") String photosApiBaseUrl
+  ) {
+    WebClient client = WebClient.builder().baseUrl(photosApiBaseUrl).build();
+    HttpServiceProxyFactory factory = HttpServiceProxyFactory
+      .builder(WebClientAdapter.forClient(client))
+      .build();
+    return factory.createClient(PhotoServiceClient.class);
+  }
+}
+```
+
+The photo service base URL is externalized as a configuration property. Add the
+following entry to `src/main/resources/application.properties`:
+
+```properties
+photos.api.base-url=https://jsonplaceholder.typicode.com
+```
+
+### Create the REST API endpoint
+
+Create `AlbumController.java`:
+
+```java
+package com.testcontainers.demo;
+
+import java.util.List;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.springframework.http.ResponseEntity;
+import org.springframework.web.bind.annotation.GetMapping;
+import org.springframework.web.bind.annotation.PathVariable;
+import org.springframework.web.bind.annotation.RequestMapping;
+import org.springframework.web.bind.annotation.RestController;
+import org.springframework.web.reactive.function.client.WebClientResponseException;
+
+@RestController
+@RequestMapping("/api")
+class AlbumController {
+
+  private static final Logger logger = LoggerFactory.getLogger(
+    AlbumController.class
+  );
+
+  private final PhotoServiceClient photoServiceClient;
+
+  AlbumController(PhotoServiceClient photoServiceClient) {
+    this.photoServiceClient = photoServiceClient;
+  }
+
+  @GetMapping("/albums/{albumId}")
+  public ResponseEntity<Album> getAlbumById(@PathVariable Long albumId) {
+    try {
+      List<Photo> photos = photoServiceClient.getPhotos(albumId);
+      return ResponseEntity.ok(new Album(albumId, photos));
+    } catch (WebClientResponseException e) {
+      logger.error("Failed to get photos", e);
+      return new ResponseEntity<>(e.getStatusCode());
+    }
+  }
+}
+```
+
+This endpoint calls the photo service for a given album ID and returns a
+response like:
+
+```json
+{
+  "albumId": 1,
+  "photos": [
+    {
+      "id": 51,
+      "title": "non sunt voluptatem placeat consequuntur rem incidunt",
+      "url": "https://via.placeholder.com/600/8e973b",
+      "thumbnailUrl": "https://via.placeholder.com/150/8e973b"
+    },
+    {
+      "id": 52,
+      "title": "eveniet pariatur quia nobis reiciendis laboriosam ea",
+      "url": "https://via.placeholder.com/600/121fa4",
+      "thumbnailUrl": "https://via.placeholder.com/150/121fa4"
+    }
+  ]
+}
+```
+
+## Write tests with Testcontainers MockServer
+
+Mocking external API interactions at the HTTP protocol level, rather than
+mocking Java methods, lets you verify marshalling and unmarshalling behavior and
+simulate network issues.
+
+Testcontainers provides a MockServer module that starts a
+[MockServer](https://www.mock-server.com/) instance inside a Docker container.
+You can then use `MockServerClient` to configure mock expectations.
+
+### Write the test
+
+Create `AlbumControllerTest.java`:
+
+```java
+package com.testcontainers.demo;
+
+import static io.restassured.RestAssured.given;
+import static org.hamcrest.CoreMatchers.is;
+import static org.hamcrest.Matchers.hasSize;
+import static org.mockserver.model.HttpRequest.request;
+import static org.mockserver.model.HttpResponse.response;
+import static org.mockserver.model.JsonBody.json;
+
+import io.restassured.RestAssured;
+import io.restassured.http.ContentType;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.mockserver.client.MockServerClient;
+import org.mockserver.model.Header;
+import org.mockserver.verify.VerificationTimes;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.boot.test.web.server.LocalServerPort;
+import org.springframework.test.context.DynamicPropertyRegistry;
+import org.springframework.test.context.DynamicPropertySource;
+import org.testcontainers.mockserver.MockServerContainer;
+import org.testcontainers.junit.jupiter.Container;
+import org.testcontainers.junit.jupiter.Testcontainers;
+
+@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
+@Testcontainers
+class AlbumControllerTest {
+
+  @LocalServerPort
+  private Integer port;
+
+  @Container
+  static MockServerContainer mockServerContainer =
+    new MockServerContainer("mockserver/mockserver:5.15.0");
+
+  static MockServerClient mockServerClient;
+
+  @DynamicPropertySource
+  static void overrideProperties(DynamicPropertyRegistry registry) {
+    mockServerClient =
+    new MockServerClient(
+      mockServerContainer.getHost(),
+      mockServerContainer.getServerPort()
+    );
+    registry.add("photos.api.base-url", mockServerContainer::getEndpoint);
+  }
+
+  @BeforeEach
+  void setUp() {
+    RestAssured.port = port;
+    mockServerClient.reset();
+  }
+
+  @Test
+  void shouldGetAlbumById() {
+    Long albumId = 1L;
+
+    mockServerClient
+      .when(
+        request().withMethod("GET").withPath("/albums/" + albumId + "/photos")
+      )
+      .respond(
+        response()
+          .withStatusCode(200)
+          .withHeaders(
+            new Header("Content-Type", "application/json; charset=utf-8")
+          )
+          .withBody(
+            json(
+              """
+              [
+                   {
+                       "id": 1,
+                       "title": "accusamus beatae ad facilis cum similique qui sunt",
+                       "url": "https://via.placeholder.com/600/92c952",
+                       "thumbnailUrl": "https://via.placeholder.com/150/92c952"
+                   },
+                   {
+                       "id": 2,
+                       "title": "reprehenderit est deserunt velit ipsam",
+                       "url": "https://via.placeholder.com/600/771796",
+                       "thumbnailUrl": "https://via.placeholder.com/150/771796"
+                   }
+               ]
+              """
+            )
+          )
+      );
+
+    given()
+      .contentType(ContentType.JSON)
+      .when()
+      .get("/api/albums/{albumId}", albumId)
+      .then()
+      .statusCode(200)
+      .body("albumId", is(albumId.intValue()))
+      .body("photos", hasSize(2));
+
+    verifyMockServerRequest("GET", "/albums/" + albumId + "/photos", 1);
+  }
+
+  @Test
+  void shouldReturn404StatusWhenAlbumNotFound() {
+    Long albumId = 1L;
+    mockServerClient
+      .when(
+        request().withMethod("GET").withPath("/albums/" + albumId + "/photos")
+      )
+      .respond(response().withStatusCode(404));
+
+    given()
+      .contentType(ContentType.JSON)
+      .when()
+      .get("/api/albums/{albumId}", albumId)
+      .then()
+      .statusCode(404);
+
+    verifyMockServerRequest("GET", "/albums/" + albumId + "/photos", 1);
+  }
+
+  private void verifyMockServerRequest(String method, String path, int times) {
+    mockServerClient.verify(
+      request().withMethod(method).withPath(path),
+      VerificationTimes.exactly(times)
+    );
+  }
+}
+```
+
+Here's what the test does:
+
+- `@SpringBootTest` starts the full application on a random port.
+- The `@Testcontainers` and `@Container` annotations start a
+  `MockServerContainer` and create a `MockServerClient` connected to it.
+- `@DynamicPropertySource` overrides `photos.api.base-url` to point at the
+  MockServer endpoint, so the application talks to MockServer instead of the
+  real photo service.
+- `@BeforeEach` resets the `MockServerClient` before every test so that
+  expectations from one test don't affect another.
+- `shouldGetAlbumById()` configures a mock response for
+  `/albums/{albumId}/photos`, sends a request to the application's
+  `/api/albums/{albumId}` endpoint, and verifies the response body. It also
+  uses `mockServerClient.verify()` to confirm that the expected API call
+  reached MockServer.
+- `shouldReturn404StatusWhenAlbumNotFound()` configures MockServer to return a
+  404 status and verifies the application propagates that status to the caller.
+
+## Run tests and next steps
+
+### Run the tests
+
+```console
+$ ./mvnw test
+```
+
+Or with Gradle:
+
+```console
+$ ./gradlew test
+```
+
+You should see the MockServer Docker container start in the console output. It
+acts as the photo service, serving mock responses based on the configured
+expectations. All tests should pass.
+
+### Summary
+
+You built a Spring Boot application that integrates with an external REST API
+using declarative HTTP clients, then tested that integration using the
+Testcontainers MockServer module. Testing at the HTTP protocol level instead of
+mocking Java methods lets you catch serialization issues and simulate realistic
+failure scenarios.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Testcontainers MockServer module](https://java.testcontainers.org/modules/mockserver/)
+- [MockServer documentation](https://www.mock-server.com/)
+- [Testcontainers JUnit 5 quickstart](https://java.testcontainers.org/quickstart/junit_5_quickstart/)
diff --git a/content/guides/testcontainers-java-quarkus.md b/content/guides/testcontainers-java-quarkus.md
new file mode 100644
index 000000000000..71b1447de4d3
--- /dev/null
+++ b/content/guides/testcontainers-java-quarkus.md
@@ -0,0 +1,474 @@
+---
+title: Testing Quarkus applications with Testcontainers
+linkTitle: Quarkus
+description: Learn how to test a Quarkus REST API using Testcontainers with PostgreSQL, Hibernate ORM with Panache, and REST Assured.
+keywords: testcontainers, java, quarkus, testing, postgresql, rest api, rest assured, panache, dev services
+summary: |
+  Learn how to create a Quarkus REST API with Hibernate ORM with Panache and PostgreSQL,
+  then test it using Quarkus Dev Services, Testcontainers, and REST Assured.
+aliases:
+  - /guides/testcontainers-java-quarkus/create-project/
+  - /guides/testcontainers-java-quarkus/run-tests/
+  - /guides/testcontainers-java-quarkus/write-tests/
+params:
+  tags: [testing]
+  time: 25 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-testcontainers-in-quarkus-applications -->
+
+In this guide, you'll learn how to:
+
+- Create a Quarkus application with REST API endpoints
+- Use Hibernate ORM with Panache and PostgreSQL for persistence
+- Test the REST API using Quarkus Dev Services, which uses Testcontainers behind
+  the scenes
+- Test with services not supported by Dev Services using
+  `QuarkusTestResourceLifecycleManager`
+
+## Prerequisites
+
+- Java 17+
+- Maven or Gradle
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Quarkus project
+
+### Set up the project
+
+Create a Quarkus project from [code.quarkus.io](https://code.quarkus.io/) by
+selecting the **RESTEasy Classic**, **RESTEasy Classic Jackson**,
+**Hibernate Validator**, **Hibernate ORM with Panache**, **JDBC Driver -
+PostgreSQL**, and **Flyway** extensions.
+
+Alternatively, clone the
+[guide repository](https://github.com/testcontainers/tc-guide-testcontainers-in-quarkus-applications).
+
+The key dependencies in `pom.xml` are:
+
+```xml
+<properties>
+    <quarkus.platform.version>3.22.3</quarkus.platform.version>
+</properties>
+<dependencies>
+    <dependency>
+        <groupId>io.quarkus</groupId>
+        <artifactId>quarkus-hibernate-orm-panache</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>io.quarkus</groupId>
+        <artifactId>quarkus-flyway</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>io.quarkus</groupId>
+        <artifactId>quarkus-hibernate-validator</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>io.quarkus</groupId>
+        <artifactId>quarkus-resteasy</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>io.quarkus</groupId>
+        <artifactId>quarkus-resteasy-jackson</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>io.quarkus</groupId>
+        <artifactId>quarkus-jdbc-postgresql</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>io.quarkus</groupId>
+        <artifactId>quarkus-junit5</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.rest-assured</groupId>
+        <artifactId>rest-assured</artifactId>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+```
+
+### Create the JPA entity
+
+Hibernate ORM with Panache supports the Active Record pattern and the
+Repository pattern to simplify JPA usage. This guide uses the Active Record
+pattern.
+
+Create `Customer.java` by extending `PanacheEntity`. This gives the entity
+built-in persistence methods such as `persist()`, `listAll()`, and
+`findById()`.
+
+```java
+package com.testcontainers.demo;
+
+import io.quarkus.hibernate.orm.panache.PanacheEntity;
+import jakarta.persistence.Column;
+import jakarta.persistence.Entity;
+import jakarta.persistence.Table;
+
+@Entity
+@Table(name = "customers")
+public class Customer extends PanacheEntity {
+
+    @Column(nullable = false)
+    public String name;
+
+    @Column(nullable = false, unique = true)
+    public String email;
+
+    public Customer() {}
+
+    public Customer(Long id, String name, String email) {
+        this.id = id;
+        this.name = name;
+        this.email = email;
+    }
+}
+```
+
+### Create the CustomerService CDI bean
+
+Create a `CustomerService` class annotated with `@ApplicationScoped` and
+`@Transactional` to handle persistence operations:
+
+```java
+package com.testcontainers.demo;
+
+import jakarta.enterprise.context.ApplicationScoped;
+import jakarta.transaction.Transactional;
+import java.util.List;
+
+@ApplicationScoped
+@Transactional
+public class CustomerService {
+
+    public List<Customer> getAll() {
+        return Customer.listAll();
+    }
+
+    public Customer create(Customer customer) {
+        customer.persist();
+        return customer;
+    }
+}
+```
+
+### Add the Flyway database migration script
+
+Create `src/main/resources/db/migration/V1__init_database.sql`:
+
+```sql
+create sequence customers_seq start with 1 increment by 50;
+
+create table customers
+(
+    id    bigint DEFAULT nextval('customers_seq') not null,
+    name  varchar                                 not null,
+    email varchar                                 not null,
+    primary key (id)
+);
+
+insert into customers(name, email)
+values ('john', 'john@mail.com'),
+       ('rambo', 'rambo@mail.com');
+```
+
+Enable Flyway migrations in `src/main/resources/application.properties`:
+
+```properties
+quarkus.flyway.migrate-at-start=true
+```
+
+### Create the REST API endpoints
+
+Create `CustomerResource.java` with endpoints for fetching all customers and
+creating a customer:
+
+```java
+package com.testcontainers.demo;
+
+import jakarta.ws.rs.Consumes;
+import jakarta.ws.rs.GET;
+import jakarta.ws.rs.POST;
+import jakarta.ws.rs.Path;
+import jakarta.ws.rs.Produces;
+import jakarta.ws.rs.core.MediaType;
+import jakarta.ws.rs.core.Response;
+import java.util.List;
+
+@Path("/api/customers")
+@Produces(MediaType.APPLICATION_JSON)
+@Consumes(MediaType.APPLICATION_JSON)
+public class CustomerResource {
+    private final CustomerService customerService;
+
+    public CustomerResource(CustomerService customerService) {
+        this.customerService = customerService;
+    }
+
+    @GET
+    public List<Customer> getAllCustomers() {
+        return customerService.getAll();
+    }
+
+    @POST
+    public Response createCustomer(Customer customer) {
+        var savedCustomer = customerService.create(customer);
+        return Response.status(Response.Status.CREATED).entity(savedCustomer).build();
+    }
+}
+```
+
+## Write tests with Testcontainers
+
+### Quarkus Dev Services
+
+Quarkus Dev Services automatically provisions unconfigured services in
+development and test mode. When you include an extension and don't configure it,
+Quarkus starts the relevant service using
+[Testcontainers](https://www.testcontainers.org/) behind the scenes and wires
+the application to use that service.
+
+> [!NOTE]
+> Dev Services requires a
+> [supported Docker environment](https://www.testcontainers.org/supported_docker_environment/).
+
+Quarkus Dev Services supports most commonly used services like SQL databases,
+Kafka, RabbitMQ, Redis, and MongoDB. For more information, see the
+[Quarkus Dev Services guide](https://quarkus.io/guides/dev-services).
+
+### Write tests for the API endpoints
+
+Test the `GET /api/customers` and `POST /api/customers` endpoints using REST
+Assured. The `io.rest-assured:rest-assured` library was already added as a test
+dependency when you generated the project.
+
+Create `CustomerResourceTest.java` and annotate it with `@QuarkusTest`. This
+bootstraps the application along with the required services using Dev Services.
+Because you haven't configured datasource properties, Dev Services automatically
+starts a PostgreSQL database using Testcontainers.
+
+```java
+package com.testcontainers.demo;
+
+import static io.restassured.RestAssured.given;
+import static org.hamcrest.CoreMatchers.is;
+import static org.junit.jupiter.api.Assertions.assertFalse;
+
+import io.quarkus.test.junit.QuarkusTest;
+import io.restassured.common.mapper.TypeRef;
+import io.restassured.http.ContentType;
+import java.util.List;
+import org.junit.jupiter.api.Test;
+
+@QuarkusTest
+class CustomerResourceTest {
+
+    @Test
+    void shouldGetAllCustomers() {
+        List<Customer> customers = given().when()
+                .get("/api/customers")
+                .then()
+                .statusCode(200)
+                .extract()
+                .as(new TypeRef<>() {});
+        assertFalse(customers.isEmpty());
+    }
+
+    @Test
+    void shouldCreateCustomerSuccessfully() {
+        Customer customer = new Customer(null, "John", "john@gmail.com");
+        given().contentType(ContentType.JSON)
+                .body(customer)
+                .when()
+                .post("/api/customers")
+                .then()
+                .statusCode(201)
+                .body("name", is("John"))
+                .body("email", is("john@gmail.com"));
+    }
+}
+```
+
+Here's what the test does:
+
+- `@QuarkusTest` starts the full Quarkus application with Dev Services enabled.
+- Dev Services starts a PostgreSQL container using Testcontainers and configures
+  the datasource automatically.
+- `shouldGetAllCustomers()` calls `GET /api/customers` and verifies that seeded
+  data from the Flyway migration is returned.
+- `shouldCreateCustomerSuccessfully()` sends a `POST /api/customers` request and
+  verifies the response contains the created customer data.
+
+### Customize test configuration
+
+By default, the Quarkus test instance starts on port 8081 and uses a
+`postgres:14` Docker image. Customize both by adding these properties to
+`src/main/resources/application.properties`:
+
+```properties
+quarkus.http.test-port=0
+quarkus.datasource.devservices.image-name=postgres:15.2-alpine
+```
+
+Setting `quarkus.http.test-port=0` starts the application on a random available
+port, avoiding port conflicts. The `devservices.image-name` property lets you
+pin the PostgreSQL image to a specific version that matches production.
+
+### Test with services not supported by Dev Services
+
+Your application might use a service that Dev Services doesn't support out of
+the box. In that case, use `QuarkusTestResourceLifecycleManager` to start the
+service before the Quarkus application starts for testing.
+
+For example, suppose the application uses CockroachDB. First, add the
+CockroachDB Testcontainers module dependency:
+
+```xml
+<dependency>
+    <groupId>org.testcontainers</groupId>
+    <artifactId>cockroachdb</artifactId>
+    <scope>test</scope>
+</dependency>
+```
+
+Create a `CockroachDBTestResource` that implements
+`QuarkusTestResourceLifecycleManager`:
+
+```java
+package com.testcontainers.demo;
+
+import io.quarkus.test.common.QuarkusTestResourceLifecycleManager;
+import java.util.HashMap;
+import java.util.Map;
+import org.testcontainers.containers.CockroachContainer;
+
+public class CockroachDBTestResource implements QuarkusTestResourceLifecycleManager {
+
+    CockroachContainer cockroachdb;
+
+    @Override
+    public Map<String, String> start() {
+        cockroachdb = new CockroachContainer("cockroachdb/cockroach:v22.2.0");
+        cockroachdb.start();
+        Map<String, String> conf = new HashMap<>();
+        conf.put("quarkus.datasource.jdbc.url", cockroachdb.getJdbcUrl());
+        conf.put("quarkus.datasource.username", cockroachdb.getUsername());
+        conf.put("quarkus.datasource.password", cockroachdb.getPassword());
+        return conf;
+    }
+
+    @Override
+    public void stop() {
+        cockroachdb.stop();
+    }
+}
+```
+
+Use the `CockroachDBTestResource` with `@QuarkusTestResource` in a test class:
+
+```java
+package com.testcontainers.demo;
+
+import static io.restassured.RestAssured.given;
+import static org.junit.jupiter.api.Assertions.assertFalse;
+
+import io.quarkus.test.common.QuarkusTestResource;
+import io.quarkus.test.junit.QuarkusTest;
+import io.restassured.common.mapper.TypeRef;
+import java.util.List;
+import org.junit.jupiter.api.Test;
+
+@QuarkusTest
+@QuarkusTestResource(value = CockroachDBTestResource.class, restrictToAnnotatedClass = true)
+class CockroachDBTest {
+
+    @Test
+    void shouldGetAllCustomers() {
+        List<Customer> customers = given().when()
+                .get("/api/customers")
+                .then()
+                .statusCode(200)
+                .extract()
+                .as(new TypeRef<>() {});
+        assertFalse(customers.isEmpty());
+    }
+}
+```
+
+The `restrictToAnnotatedClass = true` attribute ensures the CockroachDB
+container only starts when running this specific test class, rather than being
+activated for all tests.
+
+## Run tests and next steps
+
+### Run the tests
+
+```console
+$ ./mvnw test
+```
+
+Or with Gradle:
+
+```console
+$ ./gradlew test
+```
+
+You should see the PostgreSQL Docker container start and all tests pass. After
+the tests finish, the container stops and is removed automatically.
+
+### Run the application locally
+
+Quarkus Dev Services automatically provisions unconfigured services in
+development mode. Start the Quarkus application in dev mode:
+
+```console
+$ ./mvnw compile quarkus:dev
+```
+
+Or with Gradle:
+
+```console
+$ ./gradlew quarkusDev
+```
+
+Dev Services starts a PostgreSQL container automatically. If you're running a
+PostgreSQL database on your system and want to use that instead, configure the
+datasource properties in `src/main/resources/application.properties`:
+
+```properties
+quarkus.datasource.jdbc.url=jdbc:postgresql://localhost:5432/postgres
+quarkus.datasource.username=postgres
+quarkus.datasource.password=postgres
+```
+
+When these properties are set explicitly, Dev Services doesn't provision the
+database container and instead connects to the configured database.
+
+### Summary
+
+Quarkus Dev Services improves the developer experience by automatically
+provisioning the required services using Testcontainers during development and
+testing. This guide covered:
+
+- Building a REST API using JAX-RS with Hibernate ORM with Panache
+- Testing API endpoints using REST Assured with Dev Services handling database
+  provisioning
+- Using `QuarkusTestResourceLifecycleManager` for services not supported by Dev
+  Services
+- Running the application locally with Dev Services
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Quarkus Dev Services overview](https://quarkus.io/guides/dev-services)
+- [Quarkus testing guide](https://quarkus.io/guides/getting-started-testing)
+- [Testcontainers Postgres module](https://java.testcontainers.org/modules/databases/postgres/)
diff --git a/content/guides/testcontainers-java-replace-h2.md b/content/guides/testcontainers-java-replace-h2.md
new file mode 100644
index 000000000000..ee4062a99a83
--- /dev/null
+++ b/content/guides/testcontainers-java-replace-h2.md
@@ -0,0 +1,266 @@
+---
+title: Replace H2 with a real database for testing
+linkTitle: Replace H2 database
+description: Learn how to replace an H2 in-memory database with a real PostgreSQL database for testing using Testcontainers.
+keywords: testcontainers, java, testing, h2, postgresql, spring boot, spring data jpa, jdbc
+summary: |
+  Replace your H2 in-memory test database with a real PostgreSQL instance
+  using the Testcontainers special JDBC URL — a one-line change.
+aliases:
+  - /guides/testcontainers-java-replace-h2/jdbc-url-approach/
+  - /guides/testcontainers-java-replace-h2/junit-extension-approach/
+  - /guides/testcontainers-java-replace-h2/problem-with-h2/
+params:
+  tags: [testing]
+  time: 15 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-replace-h2-with-real-database-for-testing -->
+
+In this guide, you will learn how to:
+
+- Understand the drawbacks of using H2 in-memory databases for testing
+- Replace H2 with a real PostgreSQL database using the Testcontainers special JDBC URL
+- Use the Testcontainers JUnit 5 extension for more control over the container
+- Test both Spring Data JPA and JdbcTemplate-based repositories
+
+## Prerequisites
+
+- Java 17+
+- Maven or Gradle
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## The problem with H2 for testing
+
+A common practice is to use lightweight databases like H2 or HSQL as
+in-memory databases for testing while using PostgreSQL, MySQL, or Oracle in
+production. This approach has significant drawbacks:
+
+- The test database might not support all features of your production database.
+- SQL syntax might not be compatible between H2 and your production database.
+- Tests passing with H2 don't guarantee they'll work in production.
+
+### Example: PostgreSQL-specific syntax
+
+Consider implementing an "upsert" — insert a product only if it doesn't
+already exist. In PostgreSQL, you can use:
+
+```sql
+INSERT INTO products(id, code, name) VALUES(?,?,?) ON CONFLICT DO NOTHING;
+```
+
+This query doesn't work with H2 by default:
+
+```text
+Caused by: org.h2.jdbc.JdbcSQLException: Syntax error in SQL statement
+"INSERT INTO products (id, code, name) VALUES (?, ?, ?) ON[*] CONFLICT DO NOTHING";
+```
+
+You can run H2 in PostgreSQL compatibility mode, but not all features are
+supported. The inverse is also true — H2 supports `ROWNUM()` which PostgreSQL
+doesn't.
+
+Testing with a different database than production means you can't trust your
+test results and must verify after deployment, defeating the purpose of
+automated tests.
+
+### The Spring Boot test using H2
+
+A typical H2-based test looks like this:
+
+```java
+@DataJpaTest
+class ProductRepositoryTest {
+
+   @Autowired
+   ProductRepository productRepository;
+
+   @Test
+   @Sql("classpath:/sql/seed-data.sql")
+   void shouldGetAllProducts() {
+       List<Product> products = productRepository.findAll();
+       assertEquals(2, products.size());
+   }
+}
+```
+
+Spring Boot uses H2 automatically when it's on the classpath. The test passes,
+but it doesn't catch PostgreSQL-specific issues.
+
+## Replace H2 with the Testcontainers JDBC URL
+
+Replacing H2 with a real PostgreSQL database requires two test properties:
+
+```java
+@DataJpaTest
+@TestPropertySource(properties = {
+  "spring.test.database.replace=none",
+  "spring.datasource.url=jdbc:tc:postgresql:16-alpine:///db"
+})
+class ProductRepositoryWithJdbcUrlTest {
+
+  @Autowired
+  ProductRepository productRepository;
+
+  @Test
+  @Sql("classpath:/sql/seed-data.sql")
+  void shouldGetAllProducts() {
+    List<Product> products = productRepository.findAll();
+    assertEquals(2, products.size());
+  }
+}
+```
+
+That's it — two properties and your tests run against a real PostgreSQL
+database.
+
+### How the special JDBC URL works
+
+A standard PostgreSQL JDBC URL looks like:
+
+```text
+jdbc:postgresql://localhost:5432/postgres
+```
+
+The Testcontainers special JDBC URL inserts `tc:` after `jdbc:`:
+
+```text
+jdbc:tc:postgresql:///db
+```
+
+The hostname, port, and database name are ignored — Testcontainers manages them
+automatically. You can specify the Docker image tag after the database name:
+
+```text
+jdbc:tc:postgresql:16-alpine:///db
+```
+
+This creates a container from the `postgres:16-alpine` image.
+
+### Initialize the database with a script
+
+Pass `TC_INITSCRIPT` to run an SQL script when the container starts:
+
+```text
+jdbc:tc:postgresql:16-alpine:///db?TC_INITSCRIPT=sql/init-db.sql
+```
+
+Testcontainers runs the script automatically. For production applications,
+use a database migration tool like Flyway or Liquibase instead.
+
+The special JDBC URL also works for MySQL, MariaDB, PostGIS, YugabyteDB,
+CockroachDB, and other databases with Testcontainers JDBC support.
+
+### Testing JdbcTemplate-based repositories
+
+The same approach works for `JdbcTemplate`-based repositories. Use `@JdbcTest`
+instead of `@DataJpaTest`:
+
+```java
+@JdbcTest
+@TestPropertySource(properties = {
+  "spring.test.database.replace=none",
+  "spring.datasource.url=jdbc:tc:postgresql:16-alpine:///db?TC_INITSCRIPT=sql/init-db.sql"
+})
+class JdbcProductRepositoryTest {
+
+  @Autowired
+  private JdbcTemplate jdbcTemplate;
+
+  private JdbcProductRepository productRepository;
+
+  @BeforeEach
+  void setUp() {
+    productRepository = new JdbcProductRepository(jdbcTemplate);
+  }
+
+  @Test
+  @Sql("/sql/seed-data.sql")
+  void shouldGetAllProducts() {
+    List<Product> products = productRepository.getAllProducts();
+    assertEquals(2, products.size());
+  }
+}
+```
+
+## Use the JUnit 5 extension for more control
+
+If the special JDBC URL doesn't meet your needs, or you need more control over
+container creation (for example, to copy initialization scripts), use the
+Testcontainers JUnit 5 extension:
+
+```java
+@DataJpaTest
+@TestPropertySource(properties = {
+    "spring.test.database.replace=none"
+})
+@Testcontainers
+class ProductRepositoryTest {
+
+  @Container
+  static PostgreSQLContainer postgres =
+    new PostgreSQLContainer("postgres:16-alpine")
+      .withCopyFileToContainer(
+        MountableFile.forClasspathResource("sql/init-db.sql"),
+        "/docker-entrypoint-initdb.d/init-db.sql");
+
+  @DynamicPropertySource
+  static void configureProperties(DynamicPropertyRegistry registry) {
+    registry.add("spring.datasource.url", postgres::getJdbcUrl);
+    registry.add("spring.datasource.username", postgres::getUsername);
+    registry.add("spring.datasource.password", postgres::getPassword);
+  }
+
+  @Autowired
+  ProductRepository productRepository;
+
+  @Test
+  @Sql("/sql/seed-data.sql")
+  void shouldGetAllProducts() {
+    List<Product> products = productRepository.findAll();
+    assertEquals(2, products.size());
+  }
+
+  @Test
+  @Sql("/sql/seed-data.sql")
+  void shouldNotCreateAProductWithDuplicateCode() {
+    Product product = new Product(3L, "p101", "Test Product");
+    productRepository.createProductIfNotExists(product);
+    Optional<Product> optionalProduct = productRepository.findById(
+      product.getId()
+    );
+    assertThat(optionalProduct).isEmpty();
+  }
+}
+```
+
+This approach:
+
+- Uses `@Testcontainers` and `@Container` to manage the container lifecycle.
+- Copies `init-db.sql` into the container's init directory so PostgreSQL
+  runs it at startup.
+- Uses `@DynamicPropertySource` to register the container's connection details
+  with Spring Boot.
+- Tests PostgreSQL-specific features like `ON CONFLICT DO NOTHING` that
+  wouldn't work with H2.
+
+### Summary
+
+- Use the **special JDBC URL** (`jdbc:tc:postgresql:...`) for the quickest way
+  to switch from H2 to a real database — it's a one-property change.
+- Use the **JUnit 5 extension** when you need more control over the container
+  (custom init scripts, environment variables, etc.).
+- Both approaches work with Spring Data JPA (`@DataJpaTest`) and JdbcTemplate
+  (`@JdbcTest`) tests.
+
+### Further reading
+
+- [Testcontainers Postgres module](https://java.testcontainers.org/modules/databases/postgres/)
+- [Testcontainers JDBC support](https://java.testcontainers.org/modules/databases/jdbc/)
+- [Testing a Spring Boot REST API with Testcontainers](/guides/testcontainers-java-spring-boot-rest-api/)
diff --git a/content/guides/testcontainers-java-service-configuration.md b/content/guides/testcontainers-java-service-configuration.md
new file mode 100644
index 000000000000..c969f11b2bee
--- /dev/null
+++ b/content/guides/testcontainers-java-service-configuration.md
@@ -0,0 +1,233 @@
+---
+title: Configuration of services running in a container
+linkTitle: Service configuration (Java)
+description: Learn how to configure services running in Testcontainers by copying files and executing commands inside containers.
+keywords: testcontainers, java, testing, postgresql, localstack, container configuration
+summary: |
+  Learn how to initialize and configure Docker containers for testing
+  by copying files into containers and executing commands inside them.
+aliases:
+  - /guides/testcontainers-java-service-configuration/copy-files/
+  - /guides/testcontainers-java-service-configuration/exec-in-container/
+params:
+  tags: [testing]
+  time: 15 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-configuration-of-services-running-in-container -->
+
+In this guide, you will learn how to:
+
+- Initialize containers by copying files into them
+- Run commands inside running containers using `execInContainer()`
+- Set up a PostgreSQL database with SQL scripts
+- Create AWS S3 buckets in LocalStack containers
+
+## Prerequisites
+
+- Java 17+
+- Your preferred IDE
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Copy files into containers
+
+Sometimes you need to initialize a container by placing files in a specific
+location. For example, PostgreSQL runs SQL scripts from
+`/docker-entrypoint-initdb.d/` when the container starts.
+
+### Create the initialization script
+
+Create `src/test/resources/init-db.sql`:
+
+```sql
+create table customers (
+     id bigint not null,
+     name varchar not null,
+     primary key (id)
+);
+```
+
+### Copy the file into the container
+
+Use `withCopyFileToContainer()` to copy the SQL script into the container's
+init directory:
+
+```java
+package com.testcontainers.demo;
+
+import static org.junit.jupiter.api.Assertions.assertFalse;
+
+import java.util.List;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.testcontainers.postgresql.PostgreSQLContainer;
+import org.testcontainers.junit.jupiter.Container;
+import org.testcontainers.junit.jupiter.Testcontainers;
+import org.testcontainers.utility.MountableFile;
+
+@Testcontainers
+class CustomerServiceTest {
+
+  @Container
+  static PostgreSQLContainer postgres = new PostgreSQLContainer(
+    "postgres:16-alpine"
+  )
+    .withCopyFileToContainer(
+      MountableFile.forClasspathResource("init-db.sql"),
+      "/docker-entrypoint-initdb.d/"
+    );
+
+  CustomerService customerService;
+
+  @BeforeEach
+  void setUp() {
+    customerService =
+    new CustomerService(
+      postgres.getJdbcUrl(),
+      postgres.getUsername(),
+      postgres.getPassword()
+    );
+  }
+
+  @Test
+  void shouldGetCustomers() {
+    customerService.createCustomer(new Customer(1L, "George"));
+    customerService.createCustomer(new Customer(2L, "John"));
+
+    List<Customer> customers = customerService.getAllCustomers();
+    assertFalse(customers.isEmpty());
+  }
+}
+```
+
+The `withCopyFileToContainer(MountableFile, String)` method copies `init-db.sql`
+from the classpath into `/docker-entrypoint-initdb.d/` inside the container.
+PostgreSQL executes scripts in that directory automatically at startup.
+
+You can also copy files from any path on the host:
+
+```java
+.withCopyFileToContainer(
+    MountableFile.forHostPath("/host/path/to/init-db.sql"),
+    "/docker-entrypoint-initdb.d/"
+);
+```
+
+## Execute commands inside containers
+
+Some Docker containers provide CLI tools for performing actions. You can use
+`container.execInContainer(String...)` to run any available command inside a
+running container.
+
+### Example: Create an S3 bucket in LocalStack
+
+The [LocalStack](https://localstack.cloud/) module emulates AWS services. To
+test S3 file uploads, create a bucket before running tests:
+
+```java
+package com.testcontainers.demo;
+
+import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.junit.jupiter.api.Assertions.assertTrue;
+import static org.testcontainers.containers.localstack.LocalStackContainer.Service.S3;
+
+import java.io.IOException;
+import java.net.URI;
+import java.util.List;
+import org.junit.jupiter.api.BeforeAll;
+import org.junit.jupiter.api.Test;
+import org.testcontainers.containers.localstack.LocalStackContainer;
+import org.testcontainers.junit.jupiter.Container;
+import org.testcontainers.junit.jupiter.Testcontainers;
+import org.testcontainers.utility.DockerImageName;
+import software.amazon.awssdk.auth.credentials.AwsBasicCredentials;
+import software.amazon.awssdk.auth.credentials.StaticCredentialsProvider;
+import software.amazon.awssdk.regions.Region;
+import software.amazon.awssdk.services.s3.S3Client;
+import software.amazon.awssdk.services.s3.model.Bucket;
+
+@Testcontainers
+class LocalStackTest {
+
+  static final String bucketName = "mybucket";
+
+  @Container
+  static LocalStackContainer localStack = new LocalStackContainer(
+    DockerImageName.parse("localstack/localstack:3.4.0")
+  );
+
+  @BeforeAll
+  static void beforeAll() throws IOException, InterruptedException {
+    localStack.execInContainer("awslocal", "s3", "mb", "s3://" + bucketName);
+
+    org.testcontainers.containers.Container.ExecResult execResult =
+      localStack.execInContainer("awslocal", "s3", "ls");
+    String stdout = execResult.getStdout();
+    int exitCode = execResult.getExitCode();
+    assertTrue(stdout.contains(bucketName));
+    assertEquals(0, exitCode);
+  }
+
+  @Test
+  void shouldListBuckets() {
+    URI s3Endpoint = localStack.getEndpointOverride(S3);
+    StaticCredentialsProvider credentialsProvider =
+      StaticCredentialsProvider.create(
+        AwsBasicCredentials.create(
+          localStack.getAccessKey(),
+          localStack.getSecretKey()
+        )
+      );
+    S3Client s3 = S3Client
+      .builder()
+      .endpointOverride(s3Endpoint)
+      .credentialsProvider(credentialsProvider)
+      .region(Region.of(localStack.getRegion()))
+      .build();
+
+    List<String> s3Buckets = s3
+      .listBuckets()
+      .buckets()
+      .stream()
+      .map(Bucket::name)
+      .toList();
+
+    assertTrue(s3Buckets.contains(bucketName));
+  }
+}
+```
+
+The `execInContainer("awslocal", "s3", "mb", "s3://mybucket")` call runs the
+`awslocal` CLI tool (provided by the LocalStack image) to create an S3 bucket.
+
+You can capture the output and exit code from any command:
+
+```java
+Container.ExecResult execResult =
+    localStack.execInContainer("awslocal", "s3", "ls");
+String stdout = execResult.getStdout();
+int exitCode = execResult.getExitCode();
+```
+
+> [!NOTE]
+> The `withCopyFileToContainer()` and `execInContainer()` methods are inherited
+> from `GenericContainer`, so they're available for all Testcontainers modules.
+
+### Summary
+
+- Use `withCopyFileToContainer()` to place initialization files inside
+  containers before they start.
+- Use `execInContainer()` to run commands inside running containers for
+  setup tasks like creating buckets, topics, or queues.
+
+### Further reading
+
+- [Getting started with Testcontainers for Java](/guides/testcontainers-java-getting-started/)
+- [Testcontainers Postgres module](https://java.testcontainers.org/modules/databases/postgres/)
+- [Testcontainers LocalStack module](https://java.testcontainers.org/modules/localstack/)
diff --git a/content/guides/testcontainers-java-spring-boot-kafka.md b/content/guides/testcontainers-java-spring-boot-kafka.md
new file mode 100644
index 000000000000..203db79898f8
--- /dev/null
+++ b/content/guides/testcontainers-java-spring-boot-kafka.md
@@ -0,0 +1,471 @@
+---
+title: Testing Spring Boot Kafka Listener using Testcontainers
+linkTitle: Spring Boot Kafka
+description: Learn how to test a Spring Boot Kafka listener using Testcontainers with Kafka and MySQL modules.
+keywords: testcontainers, java, spring boot, testing, kafka, mysql, jpa, awaitility
+summary: |
+  Learn how to create a Spring Boot application with a Kafka listener that persists data in MySQL,
+  then test it using Testcontainers Kafka and MySQL modules with Awaitility.
+aliases:
+  - /guides/testcontainers-java-spring-boot-kafka/create-project/
+  - /guides/testcontainers-java-spring-boot-kafka/run-tests/
+  - /guides/testcontainers-java-spring-boot-kafka/write-tests/
+params:
+  tags: [testing]
+  time: 25 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-testing-spring-boot-kafka-listener -->
+
+In this guide, you will learn how to:
+
+- Create a Spring Boot application with Kafka integration
+- Implement a Kafka listener and persist data in a MySQL database
+- Test the Kafka listener using Testcontainers and Awaitility
+
+## Prerequisites
+
+- Java 17+
+- Maven or Gradle
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Spring Boot project
+
+### Set up the project
+
+Create a Spring Boot project from [Spring Initializr](https://start.spring.io)
+by selecting the **Spring for Apache Kafka**, **Spring Data JPA**, **MySQL Driver**,
+and **Testcontainers** starters.
+
+Alternatively, clone the
+[guide repository](https://github.com/testcontainers/tc-guide-testing-spring-boot-kafka-listener).
+
+After generating the application, add the Awaitility library as a test
+dependency. You'll use it later to assert the expectations of an asynchronous
+process flow.
+
+The key dependencies in `pom.xml` are:
+
+```xml
+<properties>
+    <java.version>17</java.version>
+    <testcontainers.version>2.0.4</testcontainers.version>
+</properties>
+<dependencies>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-data-jpa</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.kafka</groupId>
+        <artifactId>spring-kafka</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>com.mysql</groupId>
+        <artifactId>mysql-connector-j</artifactId>
+        <scope>runtime</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-test</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.kafka</groupId>
+        <artifactId>spring-kafka-test</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-junit-jupiter</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-kafka</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-mysql</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.awaitility</groupId>
+        <artifactId>awaitility</artifactId>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+```
+
+Using the Testcontainers BOM (Bill of Materials) is recommended so that you
+don't have to repeat the version for every Testcontainers module dependency.
+
+### Create the JPA entity
+
+The application listens to a topic called `product-price-changes`. When a
+message arrives, it extracts the product code and price from the event payload
+and updates the price for that product in the MySQL database.
+
+Create `Product.java`:
+
+```java
+package com.testcontainers.demo;
+
+import jakarta.persistence.Column;
+import jakarta.persistence.Entity;
+import jakarta.persistence.GeneratedValue;
+import jakarta.persistence.GenerationType;
+import jakarta.persistence.Id;
+import jakarta.persistence.Table;
+import java.math.BigDecimal;
+
+@Entity
+@Table(name = "products")
+class Product {
+
+  @Id
+  @GeneratedValue(strategy = GenerationType.IDENTITY)
+  private Long id;
+
+  @Column(nullable = false, unique = true)
+  private String code;
+
+  @Column(nullable = false)
+  private String name;
+
+  @Column(nullable = false)
+  private BigDecimal price;
+
+  public Product() {}
+
+  public Product(Long id, String code, String name, BigDecimal price) {
+    this.id = id;
+    this.code = code;
+    this.name = name;
+    this.price = price;
+  }
+
+  public Long getId() {
+    return id;
+  }
+
+  public void setId(Long id) {
+    this.id = id;
+  }
+
+  public String getCode() {
+    return code;
+  }
+
+  public void setCode(String code) {
+    this.code = code;
+  }
+
+  public String getName() {
+    return name;
+  }
+
+  public void setName(String name) {
+    this.name = name;
+  }
+
+  public BigDecimal getPrice() {
+    return price;
+  }
+
+  public void setPrice(BigDecimal price) {
+    this.price = price;
+  }
+}
+```
+
+### Create the Spring Data JPA repository
+
+Create a repository interface for the `Product` entity with a method to find a
+product by code and a method to update the price for a given product code:
+
+```java
+package com.testcontainers.demo;
+
+import java.math.BigDecimal;
+import java.util.Optional;
+import org.springframework.data.jpa.repository.JpaRepository;
+import org.springframework.data.jpa.repository.Modifying;
+import org.springframework.data.jpa.repository.Query;
+import org.springframework.data.repository.query.Param;
+
+interface ProductRepository extends JpaRepository<Product, Long> {
+  Optional<Product> findByCode(String code);
+
+  @Modifying
+  @Query("update Product p set p.price = :price where p.code = :productCode")
+  void updateProductPrice(
+    @Param("productCode") String productCode,
+    @Param("price") BigDecimal price
+  );
+}
+```
+
+### Add a schema creation script
+
+Because the application doesn't use an in-memory database, you need to create
+the MySQL tables. The recommended approach for production is a migration tool
+like Flyway or Liquibase, but for this guide the built-in Spring Boot schema
+initialization is sufficient.
+
+Create `src/main/resources/schema.sql`:
+
+```sql
+create table products (
+      id int NOT NULL AUTO_INCREMENT,
+      code varchar(255) not null,
+      name varchar(255) not null,
+      price numeric(5,2) not null,
+      PRIMARY KEY (id),
+      UNIQUE (code)
+);
+```
+
+Enable schema initialization in `src/main/resources/application.properties`:
+
+```properties
+spring.sql.init.mode=always
+```
+
+### Create the event payload
+
+Create a record named `ProductPriceChangedEvent` that represents the structure
+of the event payload received from the Kafka topic:
+
+```java
+package com.testcontainers.demo;
+
+import java.math.BigDecimal;
+
+record ProductPriceChangedEvent(String productCode, BigDecimal price) {}
+```
+
+The sender and receiver agree on the following JSON format:
+
+```json
+{
+  "productCode": "P100",
+  "price": 25.0
+}
+```
+
+### Implement the Kafka listener
+
+Create `ProductPriceChangedEventHandler.java`, which handles messages from the
+`product-price-changes` topic and updates the product price in the database:
+
+```java
+package com.testcontainers.demo;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.springframework.kafka.annotation.KafkaListener;
+import org.springframework.stereotype.Component;
+import org.springframework.transaction.annotation.Transactional;
+
+@Component
+@Transactional
+class ProductPriceChangedEventHandler {
+
+  private static final Logger log = LoggerFactory.getLogger(
+    ProductPriceChangedEventHandler.class
+  );
+
+  private final ProductRepository productRepository;
+
+  ProductPriceChangedEventHandler(ProductRepository productRepository) {
+    this.productRepository = productRepository;
+  }
+
+  @KafkaListener(topics = "product-price-changes", groupId = "demo")
+  public void handle(ProductPriceChangedEvent event) {
+    log.info(
+      "Received a ProductPriceChangedEvent with productCode:{}: ",
+      event.productCode()
+    );
+    productRepository.updateProductPrice(event.productCode(), event.price());
+  }
+}
+```
+
+The `@KafkaListener` annotation specifies the topic name to listen to. Spring
+Kafka handles serialization and deserialization based on the properties
+configured in `application.properties`.
+
+### Configure Kafka serialization
+
+Add the following Kafka properties to
+`src/main/resources/application.properties`:
+
+```properties
+######## Kafka Configuration  #########
+spring.kafka.bootstrap-servers=localhost:9092
+spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer
+spring.kafka.producer.value-serializer=org.springframework.kafka.support.serializer.JsonSerializer
+
+spring.kafka.consumer.group-id=demo
+spring.kafka.consumer.auto-offset-reset=latest
+spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringDeserializer
+spring.kafka.consumer.value-deserializer=org.springframework.kafka.support.serializer.JsonDeserializer
+spring.kafka.consumer.properties.spring.json.trusted.packages=com.testcontainers.demo
+```
+
+The `productCode` key is (de)serialized using `StringSerializer`/`StringDeserializer`,
+and the `ProductPriceChangedEvent` value is (de)serialized using
+`JsonSerializer`/`JsonDeserializer`.
+
+## Write tests with Testcontainers
+
+To test the Kafka listener, you need a running Kafka broker and a MySQL
+database, plus a started Spring context. Testcontainers spins up both services
+in Docker containers and `@DynamicPropertySource` connects them to Spring.
+
+### Write the test
+
+Create `ProductPriceChangedEventHandlerTest.java`:
+
+```java
+package com.testcontainers.demo;
+
+import static java.util.concurrent.TimeUnit.SECONDS;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.awaitility.Awaitility.await;
+
+import java.math.BigDecimal;
+import java.time.Duration;
+import java.util.Optional;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.kafka.core.KafkaTemplate;
+import org.springframework.test.context.DynamicPropertyRegistry;
+import org.springframework.test.context.DynamicPropertySource;
+import org.springframework.test.context.TestPropertySource;
+import org.testcontainers.kafka.ConfluentKafkaContainer;
+import org.testcontainers.junit.jupiter.Container;
+import org.testcontainers.junit.jupiter.Testcontainers;
+
+@SpringBootTest
+@TestPropertySource(
+  properties = {
+    "spring.kafka.consumer.auto-offset-reset=earliest",
+    "spring.datasource.url=jdbc:tc:mysql:8.0.32:///db",
+  }
+)
+@Testcontainers
+class ProductPriceChangedEventHandlerTest {
+
+  @Container
+  static final ConfluentKafkaContainer kafka =
+    new ConfluentKafkaContainer("confluentinc/cp-kafka:7.8.0");
+
+  @DynamicPropertySource
+  static void overrideProperties(DynamicPropertyRegistry registry) {
+    registry.add("spring.kafka.bootstrap-servers", kafka::getBootstrapServers);
+  }
+
+  @Autowired
+  private KafkaTemplate<String, Object> kafkaTemplate;
+
+  @Autowired
+  private ProductRepository productRepository;
+
+  @BeforeEach
+  void setUp() {
+    Product product = new Product(null, "P100", "Product One", BigDecimal.TEN);
+    productRepository.save(product);
+  }
+
+  @Test
+  void shouldHandleProductPriceChangedEvent() {
+    ProductPriceChangedEvent event = new ProductPriceChangedEvent(
+      "P100",
+      new BigDecimal("14.50")
+    );
+
+    kafkaTemplate.send("product-price-changes", event.productCode(), event);
+
+    await()
+      .pollInterval(Duration.ofSeconds(3))
+      .atMost(10, SECONDS)
+      .untilAsserted(() -> {
+        Optional<Product> optionalProduct = productRepository.findByCode(
+          "P100"
+        );
+        assertThat(optionalProduct).isPresent();
+        assertThat(optionalProduct.get().getCode()).isEqualTo("P100");
+        assertThat(optionalProduct.get().getPrice())
+          .isEqualTo(new BigDecimal("14.50"));
+      });
+  }
+}
+```
+
+Here's what the test does:
+
+- `@SpringBootTest` starts the full Spring application context.
+- The Testcontainers special JDBC URL (`jdbc:tc:mysql:8.0.32:///db`) in
+  `@TestPropertySource` spins up a MySQL container and configures it as the
+  datasource automatically.
+- `@Testcontainers` and `@Container` manage the lifecycle of the Kafka
+  container. `@DynamicPropertySource` registers the Kafka bootstrap servers
+  with Spring so that the producer and consumer connect to the test container.
+- `@BeforeEach` creates a `Product` record in the database before each test.
+- The test sends a `ProductPriceChangedEvent` to the `product-price-changes`
+  topic using `KafkaTemplate`. Spring Boot converts the object to JSON using
+  `JsonSerializer`.
+- Because Kafka message processing is asynchronous, the test uses
+  [Awaitility](http://www.awaitility.org/) to poll every 3 seconds (up to a
+  maximum of 10 seconds) until the product price in the database matches the
+  expected value.
+- The property `spring.kafka.consumer.auto-offset-reset` is set to `earliest`
+  so that the listener consumes messages even if they're sent to the topic
+  before the listener is ready. This setting is helpful when running tests.
+
+## Run tests and next steps
+
+### Run the tests
+
+```console
+$ ./mvnw test
+```
+
+Or with Gradle:
+
+```console
+$ ./gradlew test
+```
+
+You should see the Kafka and MySQL Docker containers start and all tests pass.
+After the tests finish, the containers stop and are removed automatically.
+
+### Summary
+
+Testing with real Kafka and MySQL instances gives you more confidence in the
+correctness of your code than mocks or embedded alternatives. The
+Testcontainers library manages the container lifecycle so that your integration
+tests run against the same services you use in production.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Getting started with Testcontainers in a Java Spring Boot project](https://testcontainers.com/guides/testing-spring-boot-rest-api-using-testcontainers/)
+- [The simplest way to replace H2 with a real database for testing](https://testcontainers.com/guides/replace-h2-with-real-database-for-testing/)
+- [Awaitility](http://www.awaitility.org/)
+- [Testcontainers Kafka module](https://java.testcontainers.org/modules/kafka/)
+- [Testcontainers MySQL module](https://java.testcontainers.org/modules/databases/mysql/)
diff --git a/content/guides/testcontainers-java-spring-boot-rest-api.md b/content/guides/testcontainers-java-spring-boot-rest-api.md
new file mode 100644
index 000000000000..edc177db5bfd
--- /dev/null
+++ b/content/guides/testcontainers-java-spring-boot-rest-api.md
@@ -0,0 +1,342 @@
+---
+title: Testing a Spring Boot REST API with Testcontainers
+linkTitle: Spring Boot REST API
+description: Learn how to test a Spring Boot REST API using Testcontainers with PostgreSQL and REST Assured.
+keywords: testcontainers, java, spring boot, testing, postgresql, rest api, rest assured, jpa
+summary: |
+  Learn how to create a Spring Boot REST API with Spring Data JPA and PostgreSQL,
+  then test it using Testcontainers and REST Assured.
+aliases:
+  - /guides/testcontainers-java-spring-boot-rest-api/create-project/
+  - /guides/testcontainers-java-spring-boot-rest-api/run-tests/
+  - /guides/testcontainers-java-spring-boot-rest-api/write-tests/
+params:
+  tags: [testing]
+  time: 25 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-testing-spring-boot-rest-api -->
+
+In this guide, you will learn how to:
+
+- Create a Spring Boot application with a REST API endpoint
+- Use Spring Data JPA with PostgreSQL to store and retrieve data
+- Test the REST API using Testcontainers and REST Assured
+
+## Prerequisites
+
+- Java 17+
+- Maven or Gradle
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Spring Boot project
+
+### Set up the project
+
+Create a Spring Boot project from [Spring Initializr](https://start.spring.io)
+by selecting the **Spring Web**, **Spring Data JPA**, **PostgreSQL Driver**, and
+**Testcontainers** starters.
+
+Alternatively, clone the
+[guide repository](https://github.com/testcontainers/tc-guide-testing-spring-boot-rest-api).
+
+The key dependencies in `pom.xml` are:
+
+```xml
+<properties>
+    <java.version>17</java.version>
+    <testcontainers.version>2.0.4</testcontainers.version>
+</properties>
+<dependencies>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-data-jpa</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-web</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.postgresql</groupId>
+        <artifactId>postgresql</artifactId>
+        <scope>runtime</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-test</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-junit-jupiter</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-postgresql</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.rest-assured</groupId>
+        <artifactId>rest-assured</artifactId>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+```
+
+Using the Testcontainers BOM (Bill of Materials) is recommended so that you
+don't have to repeat the version for every Testcontainers module dependency.
+
+### Create the JPA entity
+
+Create `Customer.java`:
+
+```java
+package com.testcontainers.demo;
+
+import jakarta.persistence.Column;
+import jakarta.persistence.Entity;
+import jakarta.persistence.GeneratedValue;
+import jakarta.persistence.GenerationType;
+import jakarta.persistence.Id;
+import jakarta.persistence.Table;
+
+@Entity
+@Table(name = "customers")
+class Customer {
+
+  @Id
+  @GeneratedValue(strategy = GenerationType.IDENTITY)
+  private Long id;
+
+  @Column(nullable = false)
+  private String name;
+
+  @Column(nullable = false, unique = true)
+  private String email;
+
+  public Customer() {}
+
+  public Customer(Long id, String name, String email) {
+    this.id = id;
+    this.name = name;
+    this.email = email;
+  }
+
+  public Long getId() {
+    return id;
+  }
+
+  public void setId(Long id) {
+    this.id = id;
+  }
+
+  public String getName() {
+    return name;
+  }
+
+  public void setName(String name) {
+    this.name = name;
+  }
+
+  public String getEmail() {
+    return email;
+  }
+
+  public void setEmail(String email) {
+    this.email = email;
+  }
+}
+```
+
+### Create the Spring Data JPA repository
+
+```java
+package com.testcontainers.demo;
+
+import org.springframework.data.jpa.repository.JpaRepository;
+
+interface CustomerRepository extends JpaRepository<Customer, Long> {}
+```
+
+### Add the schema creation script
+
+Create `src/main/resources/schema.sql`:
+
+```sql
+create table if not exists customers (
+    id bigserial not null,
+    name varchar not null,
+    email varchar not null,
+    primary key (id),
+    UNIQUE (email)
+);
+```
+
+Enable schema initialization in `src/main/resources/application.properties`:
+
+```properties
+spring.sql.init.mode=always
+```
+
+### Create the REST API endpoint
+
+Create `CustomerController.java`:
+
+```java
+package com.testcontainers.demo;
+
+import java.util.List;
+import org.springframework.web.bind.annotation.GetMapping;
+import org.springframework.web.bind.annotation.RestController;
+
+@RestController
+class CustomerController {
+
+  private final CustomerRepository repo;
+
+  CustomerController(CustomerRepository repo) {
+    this.repo = repo;
+  }
+
+  @GetMapping("/api/customers")
+  List<Customer> getAll() {
+    return repo.findAll();
+  }
+}
+```
+
+## Write tests with Testcontainers
+
+To test the REST API, you need a running Postgres database and a started
+Spring context. Testcontainers spins up Postgres in a Docker container and
+`@DynamicPropertySource` connects it to Spring.
+
+### Write the test
+
+Create `CustomerControllerTest.java`:
+
+```java
+package com.testcontainers.demo;
+
+import static io.restassured.RestAssured.given;
+import static org.hamcrest.Matchers.hasSize;
+
+import io.restassured.RestAssured;
+import io.restassured.http.ContentType;
+import java.util.List;
+import org.junit.jupiter.api.AfterAll;
+import org.junit.jupiter.api.BeforeAll;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.boot.test.web.server.LocalServerPort;
+import org.springframework.test.context.DynamicPropertyRegistry;
+import org.springframework.test.context.DynamicPropertySource;
+import org.testcontainers.postgresql.PostgreSQLContainer;
+
+@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
+class CustomerControllerTest {
+
+  @LocalServerPort
+  private Integer port;
+
+  static PostgreSQLContainer postgres = new PostgreSQLContainer(
+    "postgres:16-alpine"
+  );
+
+  @BeforeAll
+  static void beforeAll() {
+    postgres.start();
+  }
+
+  @AfterAll
+  static void afterAll() {
+    postgres.stop();
+  }
+
+  @DynamicPropertySource
+  static void configureProperties(DynamicPropertyRegistry registry) {
+    registry.add("spring.datasource.url", postgres::getJdbcUrl);
+    registry.add("spring.datasource.username", postgres::getUsername);
+    registry.add("spring.datasource.password", postgres::getPassword);
+  }
+
+  @Autowired
+  CustomerRepository customerRepository;
+
+  @BeforeEach
+  void setUp() {
+    RestAssured.baseURI = "http://localhost:" + port;
+    customerRepository.deleteAll();
+  }
+
+  @Test
+  void shouldGetAllCustomers() {
+    List<Customer> customers = List.of(
+      new Customer(null, "John", "john@mail.com"),
+      new Customer(null, "Dennis", "dennis@mail.com")
+    );
+    customerRepository.saveAll(customers);
+
+    given()
+      .contentType(ContentType.JSON)
+      .when()
+      .get("/api/customers")
+      .then()
+      .statusCode(200)
+      .body(".", hasSize(2));
+  }
+}
+```
+
+Here's what the test does:
+
+- `@SpringBootTest` starts the full application on a random port.
+- A `PostgreSQLContainer` starts in `@BeforeAll` and stops in `@AfterAll`.
+- `@DynamicPropertySource` registers the container's JDBC URL, username, and
+  password with Spring so that the datasource connects to the test container.
+- `@BeforeEach` deletes all customer rows before each test to prevent test
+  pollution.
+- `shouldGetAllCustomers()` inserts two customers, calls `GET /api/customers`,
+  and verifies the response contains 2 records.
+
+## Run tests and next steps
+
+### Run the tests
+
+```console
+$ ./mvnw test
+```
+
+Or with Gradle:
+
+```console
+$ ./gradlew test
+```
+
+You should see the Postgres Docker container start and all tests pass. After
+the tests finish, the container stops and is removed automatically.
+
+### Summary
+
+The Testcontainers library helps you write integration tests by using the same
+type of database (Postgres) that you use in production, instead of mocks or
+in-memory databases. Because you test against real services, you're free to
+refactor code and still verify that the application works as expected.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Testcontainers JUnit 5 quickstart](https://java.testcontainers.org/quickstart/junit_5_quickstart/)
+- [Testcontainers Postgres module](https://java.testcontainers.org/modules/databases/postgres/)
+- [Testcontainers JDBC support](https://java.testcontainers.org/modules/databases/jdbc/)
diff --git a/content/guides/testcontainers-java-wiremock.md b/content/guides/testcontainers-java-wiremock.md
new file mode 100644
index 000000000000..536683ddc493
--- /dev/null
+++ b/content/guides/testcontainers-java-wiremock.md
@@ -0,0 +1,770 @@
+---
+title: Testing REST API integrations using WireMock
+linkTitle: WireMock
+description: Learn how to test REST API integrations in a Spring Boot application using the Testcontainers WireMock module.
+keywords: testcontainers, java, spring boot, testing, wiremock, rest api, rest assured
+summary: |
+  Learn how to create a Spring Boot application that integrates with
+  external REST APIs, then test those integrations using Testcontainers
+  and WireMock.
+aliases:
+  - /guides/testcontainers-java-wiremock/create-project/
+  - /guides/testcontainers-java-wiremock/run-tests/
+  - /guides/testcontainers-java-wiremock/write-tests/
+params:
+  tags: [testing]
+  time: 20 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-testing-rest-api-integrations-using-wiremock -->
+
+In this guide, you'll learn how to:
+
+- Create a Spring Boot application that talks to external REST APIs
+- Test external API integrations using WireMock with both the JUnit 5 extension
+  and the Testcontainers WireMock module
+
+## Prerequisites
+
+- Java 17+
+- Maven or Gradle
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Spring Boot project
+
+### Set up the project
+
+Create a Spring Boot project from [Spring Initializr](https://start.spring.io)
+by selecting the **Spring Web** and **Testcontainers** starters.
+
+Alternatively, clone the
+[guide repository](https://github.com/testcontainers/tc-guide-testing-rest-api-integrations-using-wiremock).
+
+After generating the project, add the **REST Assured**, **WireMock**, and
+**WireMock Testcontainers module** libraries as test dependencies. The key
+dependencies in `pom.xml` are:
+
+```xml
+<properties>
+    <java.version>17</java.version>
+    <testcontainers.version>2.0.4</testcontainers.version>
+    <wiremock-testcontainers.version>1.0-alpha-13</wiremock-testcontainers.version>
+</properties>
+<dependencies>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-web</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-test</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.testcontainers</groupId>
+        <artifactId>testcontainers-junit-jupiter</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.wiremock</groupId>
+        <artifactId>wiremock-standalone</artifactId>
+        <version>3.6.0</version>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.wiremock.integrations.testcontainers</groupId>
+        <artifactId>wiremock-testcontainers-module</artifactId>
+        <version>${wiremock-testcontainers.version}</version>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>io.rest-assured</groupId>
+        <artifactId>rest-assured</artifactId>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+```
+
+Using the Testcontainers BOM (Bill of Materials) is recommended so that you
+don't have to repeat the version for every Testcontainers module dependency.
+
+This guide builds an application that manages video albums. A third-party REST
+API handles photo assets. For demonstration purposes, the application uses the
+publicly available [JSONPlaceholder](https://jsonplaceholder.typicode.com/) API
+as a photo service.
+
+The application exposes a `GET /api/albums/{albumId}` endpoint that calls the
+photo service to fetch photos for a given album.
+[WireMock](https://wiremock.org/) is a tool for building mock APIs.
+Testcontainers provides a
+[WireMock module](https://testcontainers.com/modules/wiremock/) that runs
+WireMock as a Docker container.
+
+### Create the Album and Photo models
+
+Create `Album.java` using Java records:
+
+```java
+package com.testcontainers.demo;
+
+import java.util.List;
+
+public record Album(Long albumId, List<Photo> photos) {}
+
+record Photo(Long id, String title, String url, String thumbnailUrl) {}
+```
+
+### Create the PhotoServiceClient
+
+Create `PhotoServiceClient.java`, which uses `RestTemplate` to fetch photos for
+a given album ID:
+
+```java
+package com.testcontainers.demo;
+
+import java.util.List;
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.boot.web.client.RestTemplateBuilder;
+import org.springframework.core.ParameterizedTypeReference;
+import org.springframework.http.HttpMethod;
+import org.springframework.http.ResponseEntity;
+import org.springframework.stereotype.Service;
+import org.springframework.web.client.RestTemplate;
+
+@Service
+class PhotoServiceClient {
+
+  private final String baseUrl;
+  private final RestTemplate restTemplate;
+
+  PhotoServiceClient(
+    @Value("${photos.api.base-url}") String baseUrl,
+    RestTemplateBuilder builder
+  ) {
+    this.baseUrl = baseUrl;
+    this.restTemplate = builder.build();
+  }
+
+  List<Photo> getPhotos(Long albumId) {
+    String url = baseUrl + "/albums/{albumId}/photos";
+    ResponseEntity<List<Photo>> response = restTemplate.exchange(
+      url,
+      HttpMethod.GET,
+      null,
+      new ParameterizedTypeReference<>() {},
+      albumId
+    );
+    return response.getBody();
+  }
+}
+```
+
+The photo service base URL is externalized as a configuration property. Add the
+following entry to `src/main/resources/application.properties`:
+
+```properties
+photos.api.base-url=https://jsonplaceholder.typicode.com
+```
+
+### Create the REST API endpoint
+
+Create `AlbumController.java`:
+
+```java
+package com.testcontainers.demo;
+
+import java.util.List;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.springframework.http.ResponseEntity;
+import org.springframework.web.bind.annotation.GetMapping;
+import org.springframework.web.bind.annotation.PathVariable;
+import org.springframework.web.bind.annotation.RequestMapping;
+import org.springframework.web.bind.annotation.RestController;
+import org.springframework.web.client.RestClientResponseException;
+
+@RestController
+@RequestMapping("/api")
+class AlbumController {
+
+  private static final Logger logger = LoggerFactory.getLogger(
+    AlbumController.class
+  );
+
+  private final PhotoServiceClient photoServiceClient;
+
+  AlbumController(PhotoServiceClient photoServiceClient) {
+    this.photoServiceClient = photoServiceClient;
+  }
+
+  @GetMapping("/albums/{albumId}")
+  public ResponseEntity<Album> getAlbumById(@PathVariable Long albumId) {
+    try {
+      List<Photo> photos = photoServiceClient.getPhotos(albumId);
+      return ResponseEntity.ok(new Album(albumId, photos));
+    } catch (RestClientResponseException e) {
+      logger.error("Failed to get photos", e);
+      return new ResponseEntity<>(e.getStatusCode());
+    }
+  }
+}
+```
+
+This endpoint calls the photo service for a given album ID and returns a
+response like:
+
+```json
+{
+  "albumId": 1,
+  "photos": [
+    {
+      "id": 51,
+      "title": "non sunt voluptatem placeat consequuntur rem incidunt",
+      "url": "https://via.placeholder.com/600/8e973b",
+      "thumbnailUrl": "https://via.placeholder.com/150/8e973b"
+    },
+    {
+      "id": 52,
+      "title": "eveniet pariatur quia nobis reiciendis laboriosam ea",
+      "url": "https://via.placeholder.com/600/121fa4",
+      "thumbnailUrl": "https://via.placeholder.com/150/121fa4"
+    }
+  ]
+}
+```
+
+## Write tests with WireMock and Testcontainers
+
+Mocking external API interactions at the HTTP protocol level, rather than
+mocking Java methods, lets you verify marshalling and unmarshalling behavior and
+simulate network issues.
+
+### Test using WireMock JUnit 5 extension
+
+WireMock provides a JUnit 5 extension that starts an in-process WireMock server.
+You can configure stub responses using the WireMock Java API.
+
+Create `AlbumControllerTest.java`:
+
+```java
+package com.testcontainers.demo;
+
+import static com.github.tomakehurst.wiremock.client.WireMock.aResponse;
+import static com.github.tomakehurst.wiremock.client.WireMock.urlMatching;
+import static com.github.tomakehurst.wiremock.core.WireMockConfiguration.wireMockConfig;
+import static io.restassured.RestAssured.given;
+import static org.hamcrest.CoreMatchers.is;
+import static org.hamcrest.Matchers.hasSize;
+import static org.springframework.boot.test.context.SpringBootTest.WebEnvironment.RANDOM_PORT;
+
+import com.github.tomakehurst.wiremock.client.WireMock;
+import com.github.tomakehurst.wiremock.junit5.WireMockExtension;
+import io.restassured.RestAssured;
+import io.restassured.http.ContentType;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.junit.jupiter.api.extension.RegisterExtension;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.boot.test.web.server.LocalServerPort;
+import org.springframework.http.MediaType;
+import org.springframework.test.context.DynamicPropertyRegistry;
+import org.springframework.test.context.DynamicPropertySource;
+
+@SpringBootTest(webEnvironment = RANDOM_PORT)
+class AlbumControllerTest {
+
+  @LocalServerPort
+  private Integer port;
+
+  @RegisterExtension
+  static WireMockExtension wireMock = WireMockExtension
+    .newInstance()
+    .options(wireMockConfig().dynamicPort())
+    .build();
+
+  @DynamicPropertySource
+  static void configureProperties(DynamicPropertyRegistry registry) {
+    registry.add("photos.api.base-url", wireMock::baseUrl);
+  }
+
+  @BeforeEach
+  void setUp() {
+    RestAssured.port = port;
+  }
+
+  @Test
+  void shouldGetAlbumById() {
+    Long albumId = 1L;
+
+    wireMock.stubFor(
+      WireMock
+        .get(urlMatching("/albums/" + albumId + "/photos"))
+        .willReturn(
+          aResponse()
+            .withHeader("Content-Type", MediaType.APPLICATION_JSON_VALUE)
+            .withBody(
+              """
+              [
+                   {
+                       "id": 1,
+                       "title": "accusamus beatae ad facilis cum similique qui sunt",
+                       "url": "https://via.placeholder.com/600/92c952",
+                       "thumbnailUrl": "https://via.placeholder.com/150/92c952"
+                   },
+                   {
+                       "id": 2,
+                       "title": "reprehenderit est deserunt velit ipsam",
+                       "url": "https://via.placeholder.com/600/771796",
+                       "thumbnailUrl": "https://via.placeholder.com/150/771796"
+                   }
+               ]
+              """
+            )
+        )
+    );
+
+    given()
+      .contentType(ContentType.JSON)
+      .when()
+      .get("/api/albums/{albumId}", albumId)
+      .then()
+      .statusCode(200)
+      .body("albumId", is(albumId.intValue()))
+      .body("photos", hasSize(2));
+  }
+
+  @Test
+  void shouldReturnServerErrorWhenPhotoServiceCallFailed() {
+    Long albumId = 2L;
+    wireMock.stubFor(
+      WireMock
+        .get(urlMatching("/albums/" + albumId + "/photos"))
+        .willReturn(aResponse().withStatus(500))
+    );
+
+    given()
+      .contentType(ContentType.JSON)
+      .when()
+      .get("/api/albums/{albumId}", albumId)
+      .then()
+      .statusCode(500);
+  }
+}
+```
+
+Here's what the test does:
+
+- `@SpringBootTest` starts the full application on a random port.
+- `@RegisterExtension` creates a `WireMockExtension` that starts WireMock on a
+  dynamic port.
+- `@DynamicPropertySource` overrides `photos.api.base-url` to point at the
+  WireMock endpoint, so the application talks to WireMock instead of the real
+  photo service.
+- `shouldGetAlbumById()` configures a stub response for
+  `/albums/{albumId}/photos`, sends a request to the application's
+  `/api/albums/{albumId}` endpoint, and verifies the response body.
+- `shouldReturnServerErrorWhenPhotoServiceCallFailed()` configures WireMock to
+  return a 500 status and verifies that the application propagates that status to
+  the caller.
+
+### Stub using JSON mapping files
+
+Instead of using the WireMock Java API, you can configure stubs with JSON
+mapping files. Create
+`src/test/resources/wiremock/mappings/get-album-photos.json`:
+
+```json
+{
+  "mappings": [
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/([0-9]+)/photos"
+      },
+      "response": {
+        "status": 200,
+        "headers": {
+          "Content-Type": "application/json"
+        },
+        "bodyFileName": "album-photos-resp-200.json"
+      }
+    },
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/2/photos"
+      },
+      "response": {
+        "status": 500,
+        "headers": {
+          "Content-Type": "application/json"
+        }
+      }
+    },
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/3/photos"
+      },
+      "response": {
+        "status": 200,
+        "headers": {
+          "Content-Type": "application/json"
+        },
+        "jsonBody": []
+      }
+    }
+  ]
+}
+```
+
+Create the response body file at
+`src/test/resources/wiremock/__files/album-photos-resp-200.json`:
+
+```json
+[
+  {
+    "id": 1,
+    "title": "accusamus beatae ad facilis cum similique qui sunt",
+    "url": "https://via.placeholder.com/600/92c952",
+    "thumbnailUrl": "https://via.placeholder.com/150/92c952"
+  },
+  {
+    "id": 2,
+    "title": "reprehenderit est deserunt velit ipsam",
+    "url": "https://via.placeholder.com/600/771796",
+    "thumbnailUrl": "https://via.placeholder.com/150/771796"
+  }
+]
+```
+
+Initialize WireMock to load stubs from the mapping files:
+
+```java
+@RegisterExtension
+static WireMockExtension wireMockServer = WireMockExtension
+  .newInstance()
+  .options(
+    wireMockConfig().dynamicPort().usingFilesUnderClasspath("wiremock")
+  )
+  .build();
+```
+
+With mapping-based stubs in place, create
+`AlbumControllerWireMockMappingTests.java`:
+
+```java
+package com.testcontainers.demo;
+
+import static com.github.tomakehurst.wiremock.core.WireMockConfiguration.wireMockConfig;
+import static io.restassured.RestAssured.given;
+import static org.hamcrest.CoreMatchers.is;
+import static org.hamcrest.Matchers.hasSize;
+import static org.springframework.boot.test.context.SpringBootTest.WebEnvironment.RANDOM_PORT;
+
+import com.github.tomakehurst.wiremock.junit5.WireMockExtension;
+import io.restassured.RestAssured;
+import io.restassured.http.ContentType;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.junit.jupiter.api.extension.RegisterExtension;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.boot.test.web.server.LocalServerPort;
+import org.springframework.test.context.DynamicPropertyRegistry;
+import org.springframework.test.context.DynamicPropertySource;
+
+@SpringBootTest(webEnvironment = RANDOM_PORT)
+class AlbumControllerWireMockMappingTests {
+
+  @LocalServerPort
+  private Integer port;
+
+  @RegisterExtension
+  static WireMockExtension wireMockServer = WireMockExtension
+    .newInstance()
+    .options(
+      wireMockConfig().dynamicPort().usingFilesUnderClasspath("wiremock")
+    )
+    .build();
+
+  @DynamicPropertySource
+  static void configureProperties(DynamicPropertyRegistry registry) {
+    registry.add("photos.api.base-url", wireMockServer::baseUrl);
+  }
+
+  @BeforeEach
+  void setUp() {
+    RestAssured.port = port;
+  }
+
+  @Test
+  void shouldGetAlbumById() {
+    Long albumId = 1L;
+
+    given()
+      .contentType(ContentType.JSON)
+      .when()
+      .get("/api/albums/{albumId}", albumId)
+      .then()
+      .statusCode(200)
+      .body("albumId", is(albumId.intValue()))
+      .body("photos", hasSize(2));
+  }
+
+  @Test
+  void shouldReturnServerErrorWhenPhotoServiceCallFailed() {
+    Long albumId = 2L;
+
+    given()
+      .contentType(ContentType.JSON)
+      .when()
+      .get("/api/albums/{albumId}", albumId)
+      .then()
+      .statusCode(500);
+  }
+
+  @Test
+  void shouldReturnEmptyPhotos() {
+    Long albumId = 3L;
+
+    given()
+      .contentType(ContentType.JSON)
+      .when()
+      .get("/api/albums/{albumId}", albumId)
+      .then()
+      .statusCode(200)
+      .body("albumId", is(albumId.intValue()))
+      .body("photos", hasSize(0));
+  }
+}
+```
+
+The tests don't need inline stub definitions because WireMock loads the mappings
+automatically from the classpath.
+
+### Test using the Testcontainers WireMock module
+
+The [Testcontainers WireMock module](https://testcontainers.com/modules/wiremock/)
+provisions WireMock as a standalone Docker container, based on
+[WireMock Docker](https://github.com/wiremock/wiremock-docker). This approach is
+useful when you want complete isolation between the test JVM and the mock server.
+
+Create a mock configuration file at
+`src/test/resources/com/testcontainers/demo/AlbumControllerTestcontainersTests/mocks-config.json`:
+
+```json
+{
+  "mappings": [
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/([0-9]+)/photos"
+      },
+      "response": {
+        "status": 200,
+        "headers": {
+          "Content-Type": "application/json"
+        },
+        "bodyFileName": "album-photos-response.json"
+      }
+    },
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/2/photos"
+      },
+      "response": {
+        "status": 500,
+        "headers": {
+          "Content-Type": "application/json"
+        }
+      }
+    },
+    {
+      "request": {
+        "method": "GET",
+        "urlPattern": "/albums/3/photos"
+      },
+      "response": {
+        "status": 200,
+        "headers": {
+          "Content-Type": "application/json"
+        },
+        "jsonBody": []
+      }
+    }
+  ]
+}
+```
+
+Create the response body file at
+`src/test/resources/com/testcontainers/demo/AlbumControllerTestcontainersTests/album-photos-response.json`:
+
+```json
+[
+  {
+    "id": 1,
+    "title": "accusamus beatae ad facilis cum similique qui sunt",
+    "url": "https://via.placeholder.com/600/92c952",
+    "thumbnailUrl": "https://via.placeholder.com/150/92c952"
+  },
+  {
+    "id": 2,
+    "title": "reprehenderit est deserunt velit ipsam",
+    "url": "https://via.placeholder.com/600/771796",
+    "thumbnailUrl": "https://via.placeholder.com/150/771796"
+  }
+]
+```
+
+Create `AlbumControllerTestcontainersTests.java`:
+
+```java
+package com.testcontainers.demo;
+
+import static io.restassured.RestAssured.given;
+import static org.hamcrest.CoreMatchers.is;
+import static org.hamcrest.Matchers.hasSize;
+import static org.springframework.boot.test.context.SpringBootTest.WebEnvironment.RANDOM_PORT;
+
+import io.restassured.RestAssured;
+import io.restassured.http.ContentType;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.boot.test.web.server.LocalServerPort;
+import org.springframework.test.context.DynamicPropertyRegistry;
+import org.springframework.test.context.DynamicPropertySource;
+import org.testcontainers.junit.jupiter.Container;
+import org.testcontainers.junit.jupiter.Testcontainers;
+import org.wiremock.integrations.testcontainers.WireMockContainer;
+
+@SpringBootTest(webEnvironment = RANDOM_PORT)
+@Testcontainers
+class AlbumControllerTestcontainersTests {
+
+  @LocalServerPort
+  private Integer port;
+
+  @Container
+  static WireMockContainer wiremockServer = new WireMockContainer(
+    "wiremock/wiremock:3.6.0"
+  )
+    .withMapping(
+      "photos-by-album",
+      AlbumControllerTestcontainersTests.class,
+      "mocks-config.json"
+    )
+    .withFileFromResource(
+      "album-photos-response.json",
+      AlbumControllerTestcontainersTests.class,
+      "album-photos-response.json"
+    );
+
+  @DynamicPropertySource
+  static void configureProperties(DynamicPropertyRegistry registry) {
+    registry.add("photos.api.base-url", wiremockServer::getBaseUrl);
+  }
+
+  @BeforeEach
+  void setUp() {
+    RestAssured.port = port;
+  }
+
+  @Test
+  void shouldGetAlbumById() {
+    Long albumId = 1L;
+
+    given()
+      .contentType(ContentType.JSON)
+      .when()
+      .get("/api/albums/{albumId}", albumId)
+      .then()
+      .statusCode(200)
+      .body("albumId", is(albumId.intValue()))
+      .body("photos", hasSize(2));
+  }
+
+  @Test
+  void shouldReturnServerErrorWhenPhotoServiceCallFailed() {
+    Long albumId = 2L;
+
+    given()
+      .contentType(ContentType.JSON)
+      .when()
+      .get("/api/albums/{albumId}", albumId)
+      .then()
+      .statusCode(500);
+  }
+
+  @Test
+  void shouldReturnEmptyPhotos() {
+    Long albumId = 3L;
+
+    given()
+      .contentType(ContentType.JSON)
+      .when()
+      .get("/api/albums/{albumId}", albumId)
+      .then()
+      .statusCode(200)
+      .body("albumId", is(albumId.intValue()))
+      .body("photos", hasSize(0));
+  }
+}
+```
+
+Here's what the test does:
+
+- The `@Testcontainers` and `@Container` annotations start a
+  `WireMockContainer` using the `wiremock/wiremock:3.6.0` Docker image.
+- `withMapping()` loads stub mappings from `mocks-config.json`, and
+  `withFileFromResource()` loads the response body file.
+- `@DynamicPropertySource` overrides `photos.api.base-url` to point at the
+  WireMock container's base URL.
+- The tests don't contain inline stub definitions because WireMock loads them
+  from the JSON configuration files.
+
+## Run tests and next steps
+
+### Run the tests
+
+```console
+$ ./mvnw test
+```
+
+Or with Gradle:
+
+```console
+$ ./gradlew test
+```
+
+You should see the WireMock Docker container start in the console output. It
+acts as the photo service, serving mock responses based on the configured
+expectations. All tests should pass.
+
+### Summary
+
+You built a Spring Boot application that integrates with an external REST API,
+then tested that integration using three different approaches:
+
+- WireMock JUnit 5 extension with inline stubs
+- WireMock JUnit 5 extension with JSON mapping files
+- Testcontainers WireMock module running WireMock in a Docker container
+
+Testing at the HTTP protocol level instead of mocking Java methods lets you
+catch serialization issues and simulate realistic failure scenarios.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Testcontainers WireMock module](https://testcontainers.com/modules/wiremock/)
+- [WireMock documentation](https://wiremock.org/docs/)
+- [Testcontainers JUnit 5 quickstart](https://java.testcontainers.org/quickstart/junit_5_quickstart/)
diff --git a/content/guides/testcontainers-nodejs-getting-started.md b/content/guides/testcontainers-nodejs-getting-started.md
new file mode 100644
index 000000000000..f59c191ae6cb
--- /dev/null
+++ b/content/guides/testcontainers-nodejs-getting-started.md
@@ -0,0 +1,199 @@
+---
+title: Getting started with Testcontainers for Node.js
+linkTitle: Testcontainers for Node.js
+description: Learn how to use Testcontainers for Node.js to test database interactions with a real PostgreSQL instance.
+keywords: testcontainers, nodejs, javascript, testing, postgresql, integration testing, jest
+summary: |
+  Learn how to create a Node.js application and test database interactions
+  using Testcontainers for Node.js with a real PostgreSQL instance.
+aliases:
+  - /guides/testcontainers-nodejs-getting-started/create-project/
+  - /guides/testcontainers-nodejs-getting-started/run-tests/
+  - /guides/testcontainers-nodejs-getting-started/write-tests/
+params:
+  tags: [testing]
+  time: 15 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-getting-started-with-testcontainers-for-nodejs -->
+
+In this guide, you will learn how to:
+
+- Create a Node.js application that stores and retrieves customers from PostgreSQL
+- Write integration tests using Testcontainers and Jest
+- Run tests against a real PostgreSQL database in a Docker container
+
+## Prerequisites
+
+- Node.js 18+
+- npm
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Node.js project
+
+### Initialize the project
+
+Create a new Node.js project:
+
+```console
+$ npm init -y
+```
+
+Add `pg`, `jest`, and `@testcontainers/postgresql` as dependencies:
+
+```console
+$ npm install pg --save
+$ npm install jest @testcontainers/postgresql --save-dev
+```
+
+### Implement the customer repository
+
+Create `src/customer-repository.js` with functions to manage customers in
+PostgreSQL:
+
+```javascript
+async function createCustomerTable(client) {
+  const sql =
+    "CREATE TABLE IF NOT EXISTS customers (id INT NOT NULL, name VARCHAR NOT NULL, PRIMARY KEY (id))";
+  await client.query(sql);
+}
+
+async function createCustomer(client, customer) {
+  const sql = "INSERT INTO customers (id, name) VALUES($1, $2)";
+  await client.query(sql, [customer.id, customer.name]);
+}
+
+async function getCustomers(client) {
+  const sql = "SELECT * FROM customers";
+  const result = await client.query(sql);
+  return result.rows;
+}
+
+module.exports = { createCustomerTable, createCustomer, getCustomers };
+```
+
+The module provides three functions:
+
+- `createCustomerTable()` creates the `customers` table if it doesn't exist.
+- `createCustomer()` inserts a customer record.
+- `getCustomers()` fetches all customer records.
+
+## Write tests with Testcontainers
+
+Create `src/customer-repository.test.js` with the test:
+
+```javascript
+const { Client } = require("pg");
+const { PostgreSqlContainer } = require("@testcontainers/postgresql");
+const {
+  createCustomerTable,
+  createCustomer,
+  getCustomers,
+} = require("./customer-repository");
+
+describe("Customer Repository", () => {
+  jest.setTimeout(60000);
+
+  let postgresContainer;
+  let postgresClient;
+
+  beforeAll(async () => {
+    postgresContainer = await new PostgreSqlContainer().start();
+    postgresClient = new Client({
+      connectionString: postgresContainer.getConnectionUri(),
+    });
+    await postgresClient.connect();
+    await createCustomerTable(postgresClient);
+  });
+
+  afterAll(async () => {
+    await postgresClient.end();
+    await postgresContainer.stop();
+  });
+
+  it("should create and return multiple customers", async () => {
+    const customer1 = { id: 1, name: "John Doe" };
+    const customer2 = { id: 2, name: "Jane Doe" };
+
+    await createCustomer(postgresClient, customer1);
+    await createCustomer(postgresClient, customer2);
+
+    const customers = await getCustomers(postgresClient);
+    expect(customers).toEqual([customer1, customer2]);
+  });
+});
+```
+
+Here's what the test does:
+
+- The `beforeAll` block starts a real PostgreSQL container using
+  `PostgreSqlContainer`. It then creates a `pg` client connected to the
+  container and sets up the `customers` table.
+- The `afterAll` block closes the client connection and stops the container.
+- The test inserts two customers, fetches all customers, and asserts the
+  results match.
+
+The test timeout is set to 60 seconds to allow time for the container to start
+on the first run (when the Docker image needs to be pulled).
+
+## Run tests and next steps
+
+### Run the tests
+
+Add the test script to `package.json` if it isn't there already:
+
+```json
+{
+  "scripts": {
+    "test": "jest"
+  }
+}
+```
+
+Then run the tests:
+
+```console
+$ npm test
+```
+
+You should see output like:
+
+```text
+ PASS  src/customer-repository.test.js
+  Customer Repository
+    ✓ should create and return multiple customers (5 ms)
+
+Test Suites: 1 passed, 1 total
+Tests:       1 passed, 1 total
+```
+
+To see what Testcontainers is doing under the hood — which containers it
+starts, what versions it uses — set the `DEBUG` environment variable:
+
+```console
+$ DEBUG=testcontainers* npm test
+```
+
+### Summary
+
+The Testcontainers for Node.js library helps you write integration tests using
+the same type of database (Postgres) that you use in production, instead of
+mocks. Because you aren't using mocks and instead talk to real services, you're
+free to refactor code and still verify that the application works as expected.
+
+In addition to PostgreSQL, Testcontainers provides dedicated
+[modules](https://github.com/testcontainers/testcontainers-node/tree/main/packages/modules)
+for many SQL databases, NoSQL databases, messaging queues, and more.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [Testcontainers for Node.js documentation](https://node.testcontainers.org)
diff --git a/content/guides/testcontainers-python-getting-started.md b/content/guides/testcontainers-python-getting-started.md
new file mode 100644
index 000000000000..a2cf612e56e9
--- /dev/null
+++ b/content/guides/testcontainers-python-getting-started.md
@@ -0,0 +1,310 @@
+---
+title: Getting started with Testcontainers for Python
+linkTitle: Testcontainers for Python
+description: Learn how to use Testcontainers for Python to test database interactions with a real PostgreSQL instance.
+keywords: testcontainers, python, testing, postgresql, integration testing, pytest
+summary: |
+  Learn how to create a Python application and test database interactions
+  using Testcontainers for Python with a real PostgreSQL instance.
+aliases:
+  - /guides/testcontainers-python-getting-started/create-project/
+  - /guides/testcontainers-python-getting-started/run-tests/
+  - /guides/testcontainers-python-getting-started/write-tests/
+params:
+  tags: [testing]
+  time: 15 minutes
+---
+
+
+<!-- Source: https://github.com/testcontainers/tc-guide-getting-started-with-testcontainers-for-python -->
+
+In this guide, you will learn how to:
+
+- Create a Python application that uses PostgreSQL to store customer data
+- Use `psycopg` to interact with the database
+- Write integration tests using `testcontainers-python` and `pytest`
+- Manage container lifecycle with pytest fixtures
+
+## Prerequisites
+
+- Python 3.10+
+- pip
+- A Docker environment supported by Testcontainers
+
+> [!NOTE]
+> If you're new to Testcontainers, visit the
+> [Testcontainers overview](https://testcontainers.com/getting-started/) to learn more about
+> Testcontainers and the benefits of using it.
+
+## Create the Python project
+
+### Initialize the project
+
+Start by creating a Python project with a virtual environment:
+
+```console
+$ mkdir tc-python-demo
+$ cd tc-python-demo
+$ python3 -m venv venv
+$ source venv/bin/activate
+```
+
+This guide uses [psycopg3](https://www.psycopg.org/psycopg3/) to interact
+with the Postgres database, [pytest](https://pytest.org/) for testing, and
+[testcontainers-python](https://testcontainers-python.readthedocs.io/) for
+running a PostgreSQL database in a container.
+
+Install the dependencies:
+
+```console
+$ pip install "psycopg[binary]" pytest testcontainers[postgres]
+$ pip freeze > requirements.txt
+```
+
+The `pip freeze` command generates a `requirements.txt` file so that others
+can install the same package versions using `pip install -r requirements.txt`.
+
+### Create the database helper
+
+Create a `db/connection.py` file with a function to get a database connection:
+
+```python
+import os
+
+import psycopg
+
+
+def get_connection():
+    host = os.getenv("DB_HOST", "localhost")
+    port = os.getenv("DB_PORT", "5432")
+    username = os.getenv("DB_USERNAME", "postgres")
+    password = os.getenv("DB_PASSWORD", "postgres")
+    database = os.getenv("DB_NAME", "postgres")
+    return psycopg.connect(f"host={host} dbname={database} user={username} password={password} port={port}")
+```
+
+Instead of hard-coding the database connection parameters, the function uses
+environment variables. This makes it possible to run the application in
+different environments without changing code.
+
+### Create the business logic
+
+Create a `customers/customers.py` file and define the `Customer` class:
+
+```python
+class Customer:
+    def __init__(self, cust_id, name, email):
+        self.id = cust_id
+        self.name = name
+        self.email = email
+
+    def __str__(self):
+        return f"Customer({self.id}, {self.name}, {self.email})"
+```
+
+Add a `create_table()` function to create the `customers` table:
+
+```python
+from db.connection import get_connection
+
+
+def create_table():
+    with get_connection() as conn:
+        with conn.cursor() as cur:
+            cur.execute("""
+                CREATE TABLE customers (
+                    id serial PRIMARY KEY,
+                    name varchar not null,
+                    email varchar not null unique)
+                """)
+            conn.commit()
+```
+
+The function obtains a database connection using `get_connection()` and creates
+the `customers` table. The `with` statement automatically closes the connection
+when done.
+
+Add the remaining CRUD functions:
+
+```python
+def create_customer(name, email):
+    with get_connection() as conn:
+        with conn.cursor() as cur:
+            cur.execute(
+                "INSERT INTO customers (name, email) VALUES (%s, %s)", (name, email))
+            conn.commit()
+
+
+def get_all_customers() -> list[Customer]:
+    with get_connection() as conn:
+        with conn.cursor() as cur:
+            cur.execute("SELECT * FROM customers")
+            return [Customer(cid, name, email) for cid, name, email in cur]
+
+
+def get_customer_by_email(email) -> Customer:
+    with get_connection() as conn:
+        with conn.cursor() as cur:
+            cur.execute("SELECT id, name, email FROM customers WHERE email = %s", (email,))
+            (cid, name, email) = cur.fetchone()
+            return Customer(cid, name, email)
+
+
+def delete_all_customers():
+    with get_connection() as conn:
+        with conn.cursor() as cur:
+            cur.execute("DELETE FROM customers")
+            conn.commit()
+```
+
+> [!NOTE]
+> To keep it straightforward for this guide, each function creates a new
+> connection. In a real-world application, use a connection pool to reuse
+> connections.
+
+## Write tests with Testcontainers
+
+You'll create a PostgreSQL container using Testcontainers and use it for all
+the tests. Before each test, you'll delete all customer records so that tests
+run with a clean database.
+
+### Set up pytest fixtures
+
+This guide uses [pytest fixtures](https://pytest.org/en/stable/how-to/fixtures.html)
+for setup and teardown logic. A recommended approach is to use
+[finalizers](https://pytest.org/en/stable/how-to/fixtures.html#adding-finalizers-directly)
+to guarantee cleanup runs even if setup fails:
+
+```python
+@pytest.fixture
+def setup(request):
+    # setup code
+
+    def cleanup():
+        # teardown code
+
+    request.addfinalizer(cleanup)
+    return some_value
+```
+
+### Create the test file
+
+Create a `tests/__init__.py` file with empty content to enable pytest
+[auto-discovery](https://pytest.org/explanation/goodpractices.html#test-discovery).
+
+Then create `tests/test_customers.py` with the fixtures:
+
+```python
+import os
+import pytest
+from testcontainers.postgres import PostgresContainer
+
+from customers import customers
+
+postgres = PostgresContainer("postgres:16-alpine")
+
+
+@pytest.fixture(scope="module", autouse=True)
+def setup(request):
+    postgres.start()
+
+    def remove_container():
+        postgres.stop()
+
+    request.addfinalizer(remove_container)
+    os.environ["DB_CONN"] = postgres.get_connection_url()
+    os.environ["DB_HOST"] = postgres.get_container_host_ip()
+    os.environ["DB_PORT"] = str(postgres.get_exposed_port(5432))
+    os.environ["DB_USERNAME"] = postgres.username
+    os.environ["DB_PASSWORD"] = postgres.password
+    os.environ["DB_NAME"] = postgres.dbname
+    customers.create_table()
+
+
+@pytest.fixture(scope="function", autouse=True)
+def setup_data():
+    customers.delete_all_customers()
+```
+
+Here's what the fixtures do:
+
+- The `setup` fixture has `scope="module"`, so it runs once for all tests in
+  the file. It starts a PostgreSQL container, sets environment variables with
+  the connection details, and creates the `customers` table. A cleanup
+  function removes the container after all tests complete.
+- The `setup_data` fixture has `scope="function"`, so it runs before every
+  test. It deletes all records to give each test a clean database.
+
+### Write the tests
+
+Add the test functions to the same file:
+
+```python
+def test_get_all_customers():
+    customers.create_customer("Siva", "siva@gmail.com")
+    customers.create_customer("James", "james@gmail.com")
+    customers_list = customers.get_all_customers()
+    assert len(customers_list) == 2
+
+
+def test_get_customer_by_email():
+    customers.create_customer("John", "john@gmail.com")
+    customer = customers.get_customer_by_email("john@gmail.com")
+    assert customer.name == "John"
+    assert customer.email == "john@gmail.com"
+```
+
+- `test_get_all_customers()` inserts two customer records, fetches all
+  customers, and asserts the count.
+- `test_get_customer_by_email()` inserts a customer, fetches it by email, and
+  asserts the details.
+
+Because `setup_data` deletes all records before each test, the tests can run in
+any order.
+
+## Run tests and next steps
+
+### Run the tests
+
+Run the tests using pytest:
+
+```console
+$ pytest -v
+```
+
+You should see output similar to:
+
+```text
+============================= test session starts ==============================
+platform linux -- Python 3.13.x, pytest-9.x.x
+collected 2 items
+
+tests/test_customers.py::test_get_all_customers PASSED                   [ 50%]
+tests/test_customers.py::test_get_customer_by_email PASSED               [100%]
+
+============================== 2 passed in 1.90s ===============================
+```
+
+The tests run against a real PostgreSQL database instead of mocks, which gives
+more confidence in the implementation.
+
+### Summary
+
+The Testcontainers for Python library helps you write integration tests using the
+same type of database (Postgres) that you use in production, instead of mocks.
+Because you aren't using mocks and instead talk to real services, you're free
+to refactor code and still verify that the application works as expected.
+
+In addition to PostgreSQL, Testcontainers for Python provides modules for many
+SQL databases, NoSQL databases, messaging queues, and more. You can use
+Testcontainers to run any containerized dependency for your tests.
+
+To learn more about Testcontainers, visit the
+[Testcontainers overview](https://testcontainers.com/getting-started/).
+
+### Further reading
+
+- [testcontainers-python documentation](https://testcontainers-python.readthedocs.io/)
+- [Getting started with Testcontainers for Go](/guides/testcontainers-go-getting-started/)
+- [Getting started with Testcontainers for Java](https://testcontainers.com/guides/getting-started-with-testcontainers-for-java/)
+- [Getting started with Testcontainers for Node.js](https://testcontainers.com/guides/getting-started-with-testcontainers-for-nodejs/)
diff --git a/content/guides/text-classification.md b/content/guides/text-classification.md
index 81df374797a9..c57ba6261786 100644
--- a/content/guides/text-classification.md
+++ b/content/guides/text-classification.md
@@ -6,11 +6,10 @@ description: Learn how to build and run a text recognition application using Pyt
 summary: |
   This guide details how to containerize text classification models using
   Docker.
-tags: [ai]
-languages: [python]
 aliases:
   - /guides/use-case/nlp/text-classification/
 params:
+  tags: [ai]
   time: 20 minutes
 ---
 
diff --git a/content/guides/text-summarization.md b/content/guides/text-summarization.md
index e4657f072b12..a0409e862c63 100644
--- a/content/guides/text-summarization.md
+++ b/content/guides/text-summarization.md
@@ -5,11 +5,10 @@ keywords: nlp, natural language processing, text summarization, python, bert ext
 description: Learn how to build and run a text summarization application using Python, Bert Extractive Summarizer, and Docker.
 summary: |
   This guide shows how to containerize text summarization models with Docker.
-tags: [ai]
-languages: [python]
 aliases:
   - /guides/use-case/nlp/text-summarization/
 params:
+  tags: [ai]
   time: 20 minutes
 ---
 
diff --git a/content/guides/traefik.md b/content/guides/traefik.md
index 08708fdb33a5..c91c42032935 100644
--- a/content/guides/traefik.md
+++ b/content/guides/traefik.md
@@ -4,8 +4,8 @@ description: &desc Use Traefik to easily route traffic between multiple containe
 keywords: traefik, container-supported development
 linktitle: HTTP routing with Traefik
 summary: *desc
-tags: [networking]
 params:
+  tags: [deployment]
   time: 20 minutes
 ---
 
@@ -47,18 +47,78 @@ Let’s do a quick demo of starting Traefik and then configuring two additional
    $ docker network create traefik-demo
    ```
 
-2. Start a Traefik container using the following command. The command exposes Traefik on port 80, mounts the Docker socket (which is used to monitor containers to update configuration), and passes the `--providers.docker` argument to configure Traefik to use the Docker provider.
+2. Start a Traefik container using one of the following methods. These commands exposes Traefik on port 80, mounts the Docker socket (which is used to monitor containers to update configuration), and passes the `--providers.docker` argument to configure Traefik to use the Docker provider.
+
+   {{< tabs >}}
+   {{< tab name="Using Docker Hardened Images" >}}
+
+   Docker Hardened Images (DHI) for Traefik are available on [Docker Hub](https://hub.docker.com/hardened-images/catalog/dhi/traefik).
+   If you haven't authenticated yet, first run:
+
+   ```bash
+   $ docker login dhi.io
+   ```
+
+   Then start a container using the Hardened image:
+
+   ```console
+   $ docker run -d --network=traefik-demo \
+     -p 80:80 \
+     -v /var/run/docker.sock:/var/run/docker.sock \
+     dhi.io/traefik:3.6.2 \
+     --providers.docker
+   ```
+
+   {{< /tab >}}
+
+   {{< tab name="Using the official image" >}}
+
+   You can also use the official image from Docker Hub:
 
    ```console
-   $ docker run -d --network=traefik-demo -p 80:80 -v /var/run/docker.sock:/var/run/docker.sock traefik:v3.1.2 --providers.docker
+   $ docker run -d --network=traefik-demo \
+     -p 80:80 \
+     -v /var/run/docker.sock:/var/run/docker.sock \
+     traefik:v3.6.2 \
+     --providers.docker
    ```
 
+   {{< /tab >}}
+   {{< /tabs >}}
+
 3. Now, start a simple Nginx container and define the labels Traefik is watching for to configure the HTTP routing. Note that the Nginx container is not exposing any ports.
 
+   {{< tabs >}}
+   {{< tab name="Using Docker Hardened Images" >}}
+
+   Docker Hardened Images (DHI) for Nginx are available on [Nginx DHI image](https://hub.docker.com/hardened-images/catalog/dhi/nginx).
+   If you haven't authenticated yet, first run:
+
+   ```bash
+   $ docker login dhi.io
+   ```
+
    ```console
-   $ docker run -d --network=traefik-demo --label 'traefik.http.routers.nginx.rule=Host(`nginx.localhost`)' nginx
+   $ docker run -d --network=traefik-demo \
+     --label 'traefik.http.routers.nginx.rule=Host(`nginx.localhost`)' \
+     dhi.io/nginx:1.29.3
    ```
 
+   {{< /tab >}}
+
+   {{< tab name="Using the official image" >}}
+
+   You can also run the official Nginx image as follows:
+
+   ```console
+   $ docker run -d --network=traefik-demo \
+     --label 'traefik.http.routers.nginx.rule=Host(`nginx.localhost`)' \
+     nginx:1.29.3
+   ```
+
+   {{< /tab >}}
+   {{< /tabs >}}
+
    Once the container starts, open your browser to [http://nginx.localhost](http://nginx.localhost) to see the app (all Chromium-based browsers route \*.localhost requests locally with no additional setup).
 
 4. Start a second application that will use a different hostname.
@@ -83,10 +143,13 @@ The application can be accessed on GitHub at [dockersamples/easy-http-routing-wi
 
 1. In the `compose.yaml` file, Traefik is using the following configuration:
 
+   {{< tabs >}}
+   {{< tab name="Using DHI image" >}}
+
    ```yaml
    services:
      proxy:
-       image: traefik:v3.1.2
+       image: dhi.io/traefik:3.6.2
        command: --providers.docker
        ports:
          - 80:80
@@ -94,21 +157,70 @@ The application can be accessed on GitHub at [dockersamples/easy-http-routing-wi
          - /var/run/docker.sock:/var/run/docker.sock
    ```
 
+   {{< /tab >}}
+
+   {{< tab name="Using official image" >}}
+
+   ```yaml
+   services:
+     proxy:
+       image: traefik:v3.6.2
+       command: --providers.docker
+       ports:
+         - 80:80
+       volumes:
+         - /var/run/docker.sock:/var/run/docker.sock
+   ```
+
+   {{< /tab >}}
+   {{< /tabs >}}
+
    Note that this is essentially the same configuration as used earlier, but now in a Compose syntax.
 
 2. The client service has the following configuration, which will start the container and provide it with the labels to receive requests at localhost.
 
-   ```yaml {hl_lines=[7,8]}
+   {{< tabs >}}
+   {{< tab name="Using Docker Hardened Images" >}}
+
+   Docker Hardened Images (DHI) for Nginx are available on [Nginx DHI image](https://hub.docker.com/hardened-images/catalog/dhi/nginx).
+
+   If you haven't authenticated yet, first run:
+
+   ```bash
+   $ docker login dhi.io
+   ```
+
+   You can use it as your base image as shown following:
+
+   ```yaml
    services:
      # …
      client:
-       image: nginx:alpine
+       image: dhi.io/nginx:1.29.3-alpine3.21
        volumes:
          - "./client:/usr/share/nginx/html"
        labels:
          traefik.http.routers.client.rule: "Host(`localhost`)"
    ```
 
+   {{< /tab >}}
+
+   {{< tab name="Using the official image" >}}
+
+   ```yaml
+   services:
+     # …
+     client:
+       image: nginx:1.29.3-alpine3.22
+       volumes:
+         - "./client:/usr/share/nginx/html"
+       labels:
+         traefik.http.routers.client.rule: "Host(`localhost`)"
+   ```
+
+   {{< /tab >}}
+   {{< /tabs >}}
+
 3. The api service has a similar configuration, but you’ll notice the routing rule has two conditions - the host must be “localhost” and the URL path must have a prefix of “/api”. Since this rule is more specific, Traefik will evaluate it first compared to the client rule.
 
    ```yaml {hl_lines=[7,8]}
@@ -138,7 +250,7 @@ The application can be accessed on GitHub at [dockersamples/easy-http-routing-wi
 
 5. Before starting the stack, stop the Nginx container if it is still running.
 
-And that’s it. Now, you only need to spin up the Compose stack with a `docker compose up` and all of the services and applications will be ready for development.
+   And that’s it. Now, you only need to spin up the Compose stack with a `docker compose up` and all of the services and applications will be ready for development.
 
 ## Sending traffic to non-containerized workloads
 
@@ -176,18 +288,41 @@ With this file, the only change is to the Compose configuration for Traefik. The
 1. The configuration file is mounted into the Traefik container (the exact destination path is up to you)
 2. The `command` is updated to add the file provider and point to the location of the configuration file
 
-```yaml
-services:
-  proxy:
-    image: traefik:v3.1.2
-    command: --providers.docker --providers.file.filename=/config/traefik-config.yaml --api.insecure
-    ports:
-      - 80:80
-      - 8080:8080
-    volumes:
-      - /var/run/docker.sock:/var/run/docker.sock
-      - ./dev/traefik-config.yaml:/config/traefik-config.yaml
-```
+  {{< tabs >}}
+  {{< tab name="Using DHI image" >}}
+
+  ```yaml
+  services:
+    proxy:
+      image: dhi.io/traefik:3.6.2
+      command: --providers.docker --providers.file.filename=/config/traefik-config.yaml --api.insecure
+      ports:
+        - 80:80
+        - 8080:8080
+      volumes:
+        - /var/run/docker.sock:/var/run/docker.sock
+        - ./dev/traefik-config.yaml:/config/traefik-config.yaml
+  ```
+
+  {{< /tab >}}
+
+  {{< tab name="Using official image" >}}
+
+  ```yaml
+  services:
+    proxy:
+      image: traefik:v3.6.2
+      command: --providers.docker --providers.file.filename=/config/traefik-config.yaml --api.insecure
+      ports:
+        - 80:80
+        - 8080:8080
+      volumes:
+        - /var/run/docker.sock:/var/run/docker.sock
+        - ./dev/traefik-config.yaml:/config/traefik-config.yaml
+  ```
+
+  {{< /tab >}}
+  {{< /tabs >}}
 
 ### Starting the example app
 
diff --git a/content/guides/vuejs.md b/content/guides/vuejs.md
new file mode 100644
index 000000000000..5eff6cfb3c14
--- /dev/null
+++ b/content/guides/vuejs.md
@@ -0,0 +1,823 @@
+---
+title: Vue.js language-specific guide
+linkTitle: Vue.js
+description: Containerize and develop Vue.js apps using Docker
+keywords: getting started, vue, vuejs docker, language, Dockerfile
+summary: |
+  This guide explains how to containerize Vue.js applications using Docker.
+aliases:
+  - /frameworks/vue/
+  - /guides/vuejs/configure-github-actions/
+  - /guides/vuejs/containerize/
+  - /guides/vuejs/deploy/
+  - /guides/vuejs/develop/
+  - /guides/vuejs/run-tests/
+params:
+  tags: [languages]
+  time: 20 minutes
+---
+
+The Vue.js language-specific guide shows you how to containerize an Vue.js application using Docker, following best practices for creating efficient, production-ready containers.
+
+[Vue.js](https://vuejs.org/) is a progressive and flexible framework for building modern, interactive web applications. However, as applications scale, managing dependencies, environments, and deployments can become complex. Docker simplifies these challenges by providing a consistent, isolated environment for both development and production.
+
+> **Acknowledgment**
+>
+> Docker extends its sincere gratitude to [Kristiyan Velkov](https://www.linkedin.com/in/kristiyan-velkov-763130b3/) for authoring this guide. As a Docker Captain and highly skilled Front-end engineer, Kristiyan brings exceptional expertise in modern web development, Docker, and DevOps. His hands-on approach and clear, actionable guidance make this guide an essential resource for developers aiming to build, optimize, and secure Vue.js applications with Docker.
+
+---
+
+## What will you learn?
+
+In this guide, you will learn how to:
+
+- Containerize and run an Vue.js application using Docker.
+- Set up a local development environment for Vue.js inside a container.
+- Run tests for your Vue.js application within a Docker container.
+
+You'll start by containerizing an existing Vue.js application and work your way up to production-level deployments.
+
+---
+
+## Prerequisites
+
+Before you begin, ensure you have a working knowledge of:
+
+- Basic understanding of [TypeScript](https://www.typescriptlang.org/) and [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript).
+- Familiarity with [Node.js](https://nodejs.org/en) and [npm](https://docs.npmjs.com/about-npm) for managing dependencies and running scripts.
+- Familiarity with [Vue.js](https://vuejs.org/) fundamentals.
+- Understanding of core Docker concepts such as images, containers, and Dockerfiles. If you're new to Docker, start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide.
+
+Once you've completed the Vue.js getting started modules, you’ll be fully prepared to containerize your own Vue.js application using the detailed examples and best practices outlined in this guide.
+
+## Containerize an Vue.js Application
+
+### Prerequisites
+
+Before you begin, make sure the following tools are installed and available on your system:
+
+- You have installed the latest version of [Docker Desktop](/get-started/get-docker.md).
+- You have a [git client](https://git-scm.com/downloads). The examples in this section use a command-line based git client, but you can use any client.
+
+> **New to Docker?**  
+> Start with the [Docker basics](/get-started/docker-concepts/the-basics/what-is-a-container.md) guide to get familiar with key concepts like images, containers, and Dockerfiles.
+
+---
+
+### Overview
+
+This guide walks you through the complete process of containerizing an Vue.js application with Docker. You’ll learn how to create a production-ready Docker image using best practices that improve performance, security, scalability, and deployment efficiency.
+
+By the end of this guide, you will:
+
+- Containerize an Vue.js application using Docker.
+- Create and optimize a Dockerfile for production builds.
+- Use multi-stage builds to minimize image size.
+- Serve the application efficiently with a custom Nginx configuration.
+- Build secure and maintainable Docker images by following best practices.
+
+---
+
+### Get the sample application
+
+Clone the sample application to use with this guide. Open a terminal, navigate to the directory where you want to work, and run the following command
+to clone the git repository:
+
+```console
+$ git clone https://github.com/kristiyan-velkov/docker-vuejs-sample
+```
+
+---
+
+### Build the Docker image
+
+Vue.js is a front-end framework that compiles into static assets, so the Dockerfile is customized to align with how Vue.js applications are built and efficiently served in a production environment.
+
+> [!TIP]
+>
+> [Gordon](/ai/gordon/), Docker's AI assistant, can generate Docker assets for your project. Ask Gordon to create a Dockerfile, Compose file, and `.dockerignore` tailored to your application.
+
+#### Step 1: Create the Dockerfile
+
+Before creating a Dockerfile, you need to choose a base image. You can either use the [Node.js Official Image](https://hub.docker.com/_/node) or a Docker Hardened Image (DHI) from the [Hardened Image catalog](https://hub.docker.com/hardened-images/catalog).
+
+Choosing DHI offers the advantage of a production-ready image that is lightweight and secure. For more information, see [Docker Hardened Images](https://docs.docker.com/dhi/).
+
+> [!IMPORTANT]
+> This guide uses a stable Node.js LTS image tag that is considered secure when the guide is written. Because new releases and security patches are published regularly, the tag shown here may no longer be the safest option when you follow the guide. Always review the latest available image tags and select a secure, up-to-date version before building or deploying your application.
+>
+> Official Node.js Docker Images: https://hub.docker.com/_/node
+
+{{< tabs >}}
+{{< tab name="Using Docker Hardened Images" >}}
+Docker Hardened Images (DHIs) are available for Node.js in the [Docker Hardened Images catalog](https://hub.docker.com/hardened-images/catalog/dhi/node). Docker Hardened Images are freely available to everyone with no subscription required. You can pull and use them like any other Docker image after signing in to the DHI registry. For more information, see the [DHI quickstart](/dhi/get-started/) guide.
+
+1. Sign in to the DHI registry:
+
+   ```console
+   $ docker login dhi.io
+   ```
+
+2. Pull the Node.js DHI (check the catalog for available versions):
+
+   ```console
+   $ docker pull dhi.io/node:24-alpine3.22-dev
+   ```
+
+3. Pull the Nginx DHI (check the catalog for available versions):
+   ```console
+   $ docker pull dhi.io/nginx:1.28.0-alpine3.21-dev
+   ```
+
+In the following Dockerfile, the `FROM` instructions use `dhi.io/node:24-alpine3.22-dev` and `dhi.io/nginx:1.28.0-alpine3.21-dev` as the base images.
+
+```dockerfile
+# =========================================
+# Stage 1: Build the Vue.js Application
+# =========================================
+# Use a lightweight DHI Node.js image for building
+FROM dhi.io/node:24-alpine3.22-dev AS builder
+
+# Set the working directory inside the container
+WORKDIR /app
+
+# Copy package-related files first to leverage Docker's caching mechanism
+COPY package.json package-lock.json* ./
+
+# Install project dependencies using npm ci (ensures a clean, reproducible install)
+RUN --mount=type=cache,target=/root/.npm npm ci
+
+# Copy the rest of the application source code into the container
+COPY . .
+
+# Build the Vue.js application
+RUN npm run build
+
+# =========================================
+# Stage 2: Prepare Nginx to Serve Static Files
+# =========================================
+
+FROM dhi.io/nginx:1.28.0-alpine3.21-dev AS runner
+
+# Copy custom Nginx config
+COPY nginx.conf /etc/nginx/nginx.conf
+
+# Copy the static build output from the build stage to Nginx's default HTML serving directory
+COPY --chown=nginx:nginx --from=builder /app/dist /usr/share/nginx/html
+
+# Use a built-in non-root user for security best practices
+USER nginx
+
+# Expose port 8080 to allow HTTP traffic
+# Note: The default Nginx container now listens on port 8080 instead of 80
+EXPOSE 8080
+
+# Start Nginx directly with custom config
+ENTRYPOINT ["nginx", "-c", "/etc/nginx/nginx.conf"]
+CMD ["-g", "daemon off;"]
+```
+
+{{< /tab >}}
+{{< tab name="Using the Docker Official Image" >}}
+
+Create a file named `Dockerfile` with the following contents:
+
+```dockerfile
+# =========================================
+# Stage 1: Build the Vue.js Application
+# =========================================
+ARG NODE_VERSION=24.12.0-alpine
+ARG NGINX_VERSION=alpine3.22
+
+# Use a lightweight Node.js image for building (customizable via ARG)
+FROM node:${NODE_VERSION} AS builder
+
+# Set the working directory inside the container
+WORKDIR /app
+
+# Copy package-related files first to leverage Docker's caching mechanism
+COPY package.json package-lock.json* ./
+
+# Install project dependencies using npm ci (ensures a clean, reproducible install)
+RUN --mount=type=cache,target=/root/.npm npm ci
+
+# Copy the rest of the application source code into the container
+COPY . .
+
+# Build the Vue.js application
+RUN npm run build
+
+# =========================================
+# Stage 2: Prepare Nginx to Serve Static Files
+# =========================================
+
+FROM nginxinc/nginx-unprivileged:${NGINX_VERSION} AS runner
+
+# Copy custom Nginx config
+COPY nginx.conf /etc/nginx/nginx.conf
+
+# Copy the static build output from the build stage to Nginx's default HTML serving directory
+COPY --chown=nginx:nginx --from=builder /app/dist /usr/share/nginx/html
+
+# Use a built-in non-root user for security best practices
+USER nginx
+
+# Expose port 8080 to allow HTTP traffic
+# Note: The default Nginx container now listens on port 8080 instead of 80
+EXPOSE 8080
+
+# Start Nginx directly with custom config
+ENTRYPOINT ["nginx", "-c", "/etc/nginx/nginx.conf"]
+CMD ["-g", "daemon off;"]
+```
+
+> [!NOTE]
+> We are using nginx-unprivileged instead of the standard Nginx image to follow security best practices.
+> Running as a non-root user in the final image:
+>
+> - Reduces the attack surface
+> - Aligns with Docker’s recommendations for container hardening
+> - Helps comply with stricter security policies in production environments
+
+{{< /tab >}}
+{{< /tabs >}}
+
+#### Step 2: Create the compose.yaml file
+
+Create a file named `compose.yaml` with the following contents:
+
+```yaml {collapse=true,title=compose.yaml}
+services:
+  server:
+    build:
+      context: .
+    ports:
+      - 8080:8080
+```
+
+#### Step 3: Create the .dockerignore file
+
+The `.dockerignore` file plays a crucial role in optimizing your Docker image by specifying which files and directories should be excluded from the build context.
+
+> [!NOTE]
+> This helps:
+>
+> - Reduce image size
+> - Speed up the build process
+> - Prevent sensitive or unnecessary files (like `.env`, `.git`, or `node_modules`) from being added to the final image.
+>
+> To learn more, visit the [.dockerignore reference](/reference/dockerfile.md#dockerignore-file).
+
+Create a file named `.dockerignore` with the following contents:
+
+```dockerignore
+# -------------------------------
+# Dependency directories
+# -------------------------------
+node_modules/
+
+# -------------------------------
+# Production and build outputs
+# -------------------------------
+dist/
+out/
+build/
+public/build/
+
+# -------------------------------
+# Vite, VuePress, and cache dirs
+# -------------------------------
+.vite/
+.vitepress/
+.cache/
+.tmp/
+
+# -------------------------------
+# Test output and coverage
+# -------------------------------
+coverage/
+reports/
+jest/
+cypress/
+cypress/screenshots/
+cypress/videos/
+
+# -------------------------------
+# Environment and config files
+# -------------------------------
+*.env*
+!.env.production    # Keep production env if needed
+*.local
+*.log
+
+# -------------------------------
+# TypeScript artifacts
+# -------------------------------
+*.tsbuildinfo
+
+# -------------------------------
+# Editor and IDE config
+# -------------------------------
+.vscode/
+.idea/
+*.swp
+
+# -------------------------------
+# System files
+# -------------------------------
+.DS_Store
+Thumbs.db
+
+# -------------------------------
+# Lockfiles (optional)
+# -------------------------------
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+pnpm-debug.log*
+
+# -------------------------------
+# Git files
+# -------------------------------
+.git/
+.gitignore
+
+# -------------------------------
+# Docker-related files
+# -------------------------------
+Dockerfile
+.dockerignore
+docker-compose.yml
+docker-compose.override.yml
+```
+
+#### Step 4: Create the `nginx.conf` file
+
+To serve your Vue.js application efficiently inside the container, you’ll configure Nginx with a custom setup. This configuration is optimized for performance, browser caching, gzip compression, and support for client-side routing.
+
+Create a file named `nginx.conf` in the root of your project directory, and add the following content:
+
+> [!NOTE]
+> To learn more about configuring Nginx, see the [official Nginx documentation](https://nginx.org/en/docs/).
+
+```nginx
+worker_processes auto;
+pid /tmp/nginx.pid;
+
+events {
+    worker_connections 1024;
+}
+
+http {
+    include       /etc/nginx/mime.types;
+    default_type  application/octet-stream;
+    charset       utf-8;
+
+    access_log    off;
+    error_log     /dev/stderr warn;
+
+    sendfile        on;
+    tcp_nopush      on;
+    tcp_nodelay     on;
+    keepalive_timeout  65;
+    keepalive_requests 1000;
+
+    gzip on;
+    gzip_comp_level 6;
+    gzip_proxied any;
+    gzip_min_length 256;
+    gzip_vary on;
+    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
+
+    server {
+        listen       8080;
+        server_name  localhost;
+
+        root   /usr/share/nginx/html;
+        index  index.html;
+
+        location / {
+            try_files $uri $uri/ /index.html;
+        }
+
+        location ~* \.(?:ico|css|js|gif|jpe?g|png|woff2?|eot|ttf|svg|map)$ {
+            expires 1y;
+            access_log off;
+            add_header Cache-Control "public, immutable";
+            add_header X-Content-Type-Options nosniff;
+        }
+
+        location /assets/ {
+            expires 1y;
+            add_header Cache-Control "public, immutable";
+            add_header X-Content-Type-Options nosniff;
+        }
+
+        error_page 404 /index.html;
+    }
+}
+```
+
+#### Step 5: Build the Vue.js application image
+
+With your custom configuration in place, you're now ready to build the Docker image for your Vue.js application.
+
+The updated setup includes:
+
+- The updated setup includes a clean, production-ready Nginx configuration tailored specifically for Vue.js.
+- Efficient multi-stage Docker build, ensuring a small and secure final image.
+
+After completing the previous steps, your project directory should now contain the following files:
+
+```text
+├── docker-vuejs-sample/
+│ ├── Dockerfile
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ └── nginx.conf
+```
+
+Now that your Dockerfile is configured, you can build the Docker image for your Vue.js application.
+
+> [!NOTE]
+> The `docker build` command packages your application into an image using the instructions in the Dockerfile. It includes all necessary files from the current directory (called the [build context](/build/concepts/context/#what-is-a-build-context)).
+
+Run the following command from the root of your project:
+
+```console
+$ docker build --tag docker-vuejs-sample .
+```
+
+What this command does:
+
+- Uses the Dockerfile in the current directory (.)
+- Packages the application and its dependencies into a Docker image
+- Tags the image as docker-vuejs-sample so you can reference it later
+
+#### Step 6: View local images
+
+After building your Docker image, you can check which images are available on your local machine using either the Docker CLI or [Docker Desktop](/manuals/desktop/use-desktop/images.md). Since you're already working in the terminal, let's use the Docker CLI.
+
+To list all locally available Docker images, run the following command:
+
+```console
+$ docker images
+```
+
+Example Output:
+
+```shell
+REPOSITORY                TAG               IMAGE ID       CREATED         SIZE
+docker-vuejs-sample       latest            8c9c199179d4   14 seconds ago   76.2MB
+```
+
+This output provides key details about your images:
+
+- **Repository** – The name assigned to the image.
+- **Tag** – A version label that helps identify different builds (e.g., latest).
+- **Image ID** – A unique identifier for the image.
+- **Created** – The timestamp indicating when the image was built.
+- **Size** – The total disk space used by the image.
+
+If the build was successful, you should see `docker-vuejs-sample` image listed.
+
+---
+
+### Run the containerized application
+
+In the previous step, you created a Dockerfile for your Vue.js application and built a Docker image using the docker build command. Now it’s time to run that image in a container and verify that your application works as expected.
+
+Inside the `docker-vuejs-sample` directory, run the following command in a
+terminal.
+
+```console
+$ docker compose up --build
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see a simple Vue.js web application.
+
+Press `ctrl+c` in the terminal to stop your application.
+
+#### Run the application in the background
+
+You can run the application detached from the terminal by adding the `-d`
+option. Inside the `docker-vuejs-sample` directory, run the following command
+in a terminal.
+
+```console
+$ docker compose up --build -d
+```
+
+Open a browser and view the application at [http://localhost:8080](http://localhost:8080). You should see your Vue.js application running in the browser.
+
+To confirm that the container is running, use `docker ps` command:
+
+```console
+$ docker ps
+```
+
+This will list all active containers along with their ports, names, and status. Look for a container exposing port 8080.
+
+Example Output:
+
+```shell
+CONTAINER ID   IMAGE                          COMMAND                  CREATED             STATUS             PORTS                    NAMES
+37a1fa85e4b0   docker-vuejs-sample-server     "nginx -c /etc/nginx…"   About a minute ago  Up About a minute  0.0.0.0:8080->8080/tcp   docker-vuejs-sample-server-1
+```
+
+To stop the application, run:
+
+```console
+$ docker compose down
+```
+
+> [!NOTE]
+> For more information about Compose commands, see the [Compose CLI
+> reference](/reference/cli/docker/compose/).
+
+---
+
+## Use containers for Vue.js development
+
+### Prerequisites
+
+Complete [Containerize Vue.js application](#containerize-an-vuejs-application).
+
+---
+
+### Overview
+
+In this section, you'll set up both production and development environments for your Vue.js application using Docker Compose. This approach streamlines your workflow—delivering a lightweight, static site via Nginx in production, and providing a fast, live-reloading dev server with Compose Watch for efficient local development.
+
+You’ll learn how to:
+
+- Configure isolated environments: Set up separate containers optimized for production and development use cases.
+- Live-reload in development: Use Compose Watch to automatically sync file changes, enabling real-time updates without manual intervention.
+- Preview and debug with ease: Develop inside containers with a seamless preview and debug experience—no rebuilds required after every change.
+
+---
+
+### Automatically update services (development mode)
+
+Leverage Compose Watch to enable real-time file synchronization between your local machine and the containerized Vue.js development environment. This powerful feature eliminates the need to manually rebuild or restart containers, providing a fast, seamless, and efficient development workflow.
+
+With Compose Watch, your code updates are instantly reflected inside the container—perfect for rapid testing, debugging, and live previewing changes.
+
+### Step 1: Create a development Dockerfile
+
+Create a file named `Dockerfile.dev` in your project root with the following content:
+
+```dockerfile
+# =========================================
+# Stage 1: Develop the Vue.js Application
+# =========================================
+ARG NODE_VERSION=24.12.0-alpine
+
+# Use a lightweight Node.js image for development
+FROM node:${NODE_VERSION} AS dev
+
+# Set environment variable to indicate development mode
+ENV NODE_ENV=development
+
+# Set the working directory inside the container
+WORKDIR /app
+
+# Copy package-related files first to leverage Docker's caching mechanism
+COPY package.json package-lock.json* ./
+
+# Install project dependencies
+RUN --mount=type=cache,target=/root/.npm npm install
+
+# Copy the rest of the application source code into the container
+COPY . .
+
+# Change ownership of the application directory to the node user
+RUN chown -R node:node /app
+
+# Switch to the node user
+USER node
+
+# Expose the port used by the Vite development server
+EXPOSE 5173
+
+# Use a default command, can be overridden in Docker compose.yml file
+CMD [ "npm", "run", "dev", "--", "--host" ]
+
+```
+
+This file sets up a lightweight development environment for your Vue.js application using the dev server.
+
+#### Step 2: Update your `compose.yaml` file
+
+Open your `compose.yaml` file and define two services: one for production (`vuejs-prod`) and one for development (`vuejs-dev`).
+
+Here’s an example configuration for an Vue.js application:
+
+```yaml
+services:
+  vuejs-prod:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: docker-vuejs-sample
+    ports:
+      - "8080:8080"
+
+  vuejs-dev:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    ports:
+      - "5173:5173"
+    develop:
+      watch:
+        - path: ./src
+          target: /app/src
+          action: sync
+        - path: ./package.json
+          target: /app/package.json
+          action: restart
+        - path: ./vite.config.js
+          target: /app/vite.config.js
+          action: restart
+```
+
+- The `vuejs-prod` service builds and serves your static production app using Nginx.
+- The `vuejs-dev` service runs your Vue.js development server with live reload and hot module replacement.
+- `watch` triggers file sync with Compose Watch.
+
+> [!NOTE]
+> For more details, see the official guide: [Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
+
+After completing the previous steps, your project directory should now contain the following files:
+
+```text
+├── docker-vuejs-sample/
+│ ├── Dockerfile
+│ ├── Dockerfile.dev
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ └── nginx.conf
+```
+
+#### Step 4: Start Compose Watch
+
+Run the following command from the project root to start the container in watch mode
+
+```console
+$ docker compose watch vuejs-dev
+```
+
+#### Step 5: Test Compose Watch with Vue.js
+
+To confirm that Compose Watch is functioning correctly:
+
+1. Open the `src/App.vue` file in your text editor.
+
+2. Locate the following line:
+
+   ```html
+   <HelloWorld msg="You did it!" />
+   ```
+
+3. Change it to:
+
+   ```html
+   <HelloWorld msg="Hello from Docker Compose Watch" />
+   ```
+
+4. Save the file.
+
+5. Open your browser at [http://localhost:5173](http://localhost:5173).
+
+You should see the updated text appear instantly, without needing to rebuild the container manually. This confirms that file watching and automatic synchronization are working as expected.
+
+---
+
+## Run vue.js tests in a container
+
+### Prerequisites
+
+Complete all the previous sections of this guide, starting with [Containerize Vue.js application](#containerize-an-vuejs-application).
+
+### Overview
+
+Testing is a critical part of the development process. In this section, you'll learn how to:
+
+- Run unit tests using Vitest inside a Docker container.
+- Use Docker Compose to run tests in an isolated, reproducible environment.
+
+You’ll use [Vitest](https://vitest.dev) — a blazing fast test runner designed for Vite — together with [@vue/test-utils](https://test-utils.vuejs.org/) to write unit tests that validate your component logic, props, events, and reactive behavior.
+
+This setup ensures your Vue.js components are tested in an environment that mirrors how users actually interact with your application.
+
+---
+
+### Run tests during development
+
+`docker-vuejs-sample` application includes a sample test file at location:
+
+```console
+$ src/components/__tests__/HelloWorld.spec.ts
+```
+
+This test uses Vitest and Vue Test Utils to verify the behavior of the HelloWorld component.
+
+---
+
+#### Step 1: Update compose.yaml
+
+Add a new service named `vuejs-test` to your `compose.yaml` file. This service allows you to run your test suite in an isolated containerized environment.
+
+```yaml {hl_lines="22-26",linenos=true}
+services:
+  vuejs-prod:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: docker-vuejs-sample
+    ports:
+      - "8080:8080"
+
+  vuejs-dev:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    ports:
+      - "5173:5173"
+    develop:
+      watch:
+        - action: sync
+          path: .
+          target: /app
+
+  vuejs-test:
+    build:
+      context: .
+      dockerfile: Dockerfile.dev
+    command: ["npm", "run", "test:unit"]
+```
+
+The vuejs-test service reuses the same `Dockerfile.dev` used for [development](#use-containers-for-vuejs-development) and overrides the default command to run tests with `npm run test`. This setup ensures a consistent test environment that matches your local development configuration.
+
+After completing the previous steps, your project directory should contain the following files:
+
+```text
+├── docker-vuejs-sample/
+│ ├── Dockerfile
+│ ├── Dockerfile.dev
+│ ├── .dockerignore
+│ ├── compose.yaml
+│ └── nginx.conf
+```
+
+#### Step 2: Run the tests
+
+To execute your test suite inside the container, run the following command from your project root:
+
+```console
+$ docker compose run --rm vuejs-test
+```
+
+This command will:
+
+- Start the `vuejs-test` service defined in your `compose.yaml` file.
+- Execute the `npm run test` script using the same environment as development.
+- Automatically remove the container after the tests complete [`docker compose run --rm`](/reference/cli/docker/compose/run/) command.
+
+You should see output similar to the following:
+
+```shell
+Test Files: 1 passed (1)
+Tests:      1 passed (1)
+Start at:   16:50:55
+Duration:   718ms
+```
+
+> [!NOTE]
+> For more information about Compose commands, see the [Compose CLI
+> reference](/reference/cli/docker/compose/).
+
+---
+
+### Summary
+
+In this section, you learned how to run unit tests for your Vue.js application inside a Docker container using Vitest and Docker Compose.
+
+What you accomplished:
+
+- Created a `vuejs-test` service in `compose.yaml` to isolate test execution.
+- Reused the development `Dockerfile.dev` to ensure consistency between dev and test environments.
+- Ran tests inside the container using `docker compose run --rm vuejs-test`.
+- Ensured reliable, repeatable testing across environments without depending on your local machine setup.
+
+---
+
+### Related resources
+
+Explore official references and best practices to sharpen your Docker testing workflow:
+
+- [Dockerfile reference](/reference/dockerfile/) – Understand all Dockerfile instructions and syntax.
+- [Best practices for writing Dockerfiles](/develop/develop-images/dockerfile_best-practices/) – Write efficient, maintainable, and secure Dockerfiles.
+- [Compose file reference](/compose/compose-file/) – Learn the full syntax and options available for configuring services in `compose.yaml`.
+- [`docker compose run` CLI reference](/reference/cli/docker/compose/run/) – Run one-off commands in a service container.
diff --git a/content/guides/wiremock.md b/content/guides/wiremock.md
index ccdc05e219c1..394caf39f205 100644
--- a/content/guides/wiremock.md
+++ b/content/guides/wiremock.md
@@ -4,9 +4,8 @@ description: &desc Mocking API services in development and testing with WireMock
 keywords: WireMock, container-supported development
 linktitle: Mocking API services with WireMock
 summary: *desc
-tags: [app-dev, distributed-systems]
-languages: [js]
 params:
+  tags: [testing]
   time: 20 minutes
 ---
 
@@ -58,12 +57,12 @@ Launch a quick demo of WireMock by using the following steps:
 
     After a moment, the application will be up and running. 
 
-    ![Diagram showing the WireMock container running on Docker Desktop ](./images/wiremock-using-docker.webp)
+    ![Diagram showing the WireMock container running on Docker Desktop](./images/wiremock-using-docker.webp)
 
 
     You can check the logs by selecting the `wiremock-node-docker` container:
 
-    ![Diagram showing the logs of WireMock container running on Docker Desktop ](./images/wiremock-logs-docker-desktop.webp)
+    ![Diagram showing the logs of WireMock container running on Docker Desktop](./images/wiremock-logs-docker-desktop.webp)
 
  4. Test the Mock API.
 
@@ -94,7 +93,7 @@ Now that you have tried WireMock, let’s use it in development and testing. In
   - External AccuWeather API: The real API from which live weather data is fetched.
   - WireMock: The mock server that simulates the API responses during testing. It runs as a Docker container.
 
-  ![Diagram showing the architecture of WireMock in development ](./images/wiremock-arch.webp)
+  ![Diagram showing the architecture of WireMock in development](./images/wiremock-arch.webp)
 
   - In development, the Node.js backend sends a request to WireMock instead of the actual AccuWeather API.
   - In production, it connects directly to the live AccuWeather API for real data.
@@ -208,7 +207,7 @@ Follow the steps to setup a non-containerized Node application:
    > [!TIP]
    > Before you proceed to the next step, ensure that you stop the node application service.
 
-## Use a Live API in production to fetch real-time weather data from AccuWeather
+## Use a live API in production to fetch real-time weather data from AccuWeather
 
    To enhance your Node.js application with real-time weather data, you can seamlessly integrate the AccuWeather API. This section of the guide will walk you through the steps involved in setting up a non-containerized Node.js application and fetching weather information directly from the AccuWeather API.
 
diff --git a/content/guides/zscaler.md b/content/guides/zscaler.md
new file mode 100644
index 000000000000..c705e34e526a
--- /dev/null
+++ b/content/guides/zscaler.md
@@ -0,0 +1,142 @@
+---
+title: Using Docker with Zscaler
+summary: |
+  This guide explains how to embed Zscaler's root certificate into Docker
+  images, allowing containers to operate securely with Zscaler proxies and
+  avoid SSL errors.
+keywords: zscaler, proxy, ssl certificates, corporate network, https, root certificate
+params:
+  tags: [admin]
+  time: 10 minutes
+---
+
+In many corporate environments, network traffic is intercepted and monitored
+using HTTPS proxies, such as Zscaler. While Zscaler ensures security compliance
+and network control, it can cause issues for developers using Docker,
+particularly during build processes, where SSL certificate validation errors
+might occur. This guide outlines how to configure Docker containers and builds
+to properly handle Zscaler's custom certificates, ensuring smooth operation in
+monitored environments.
+
+## The role of certificates in Docker
+
+When Docker builds or runs containers, it often needs to fetch resources from
+the internet—whether it's pulling a base image from a registry, downloading
+dependencies, or communicating with external services. In a proxied
+environment, Zscaler intercepts HTTPS traffic and replaces the remote server's
+certificate with its own. However, Docker doesn't trust this Zscaler
+certificate by default, leading to SSL errors.
+
+```plaintext
+x509: certificate signed by unknown authority
+```
+
+These errors occur because Docker cannot verify the validity of the certificate
+presented by Zscaler. To avoid this, you must configure Docker to trust
+Zscaler's certificate.
+
+## Configure Zscaler proxy for Docker Desktop
+
+Depending on how Zscaler is deployed, you may need to configure Docker Desktop
+proxy settings manually to use the Zscaler proxy.
+
+If you're using Zscaler as a system-level proxy via the [Zscaler Client Connector](https://help.zscaler.com/zscaler-client-connector/what-is-zscaler-client-connector),
+all traffic on the device is automatically routed through Zscaler, so Docker
+Desktop uses the Zscaler proxy automatically with no additional configuration
+necessary.
+
+If you are not using Zscaler as a system-level proxy, manually configure proxy
+settings in Docker Desktop. Set up proxy settings for all clients in the
+organization using [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md),
+or edit proxy configuration in the Docker Desktop GUI under [**Settings > Resources > Proxies**](/manuals/desktop/settings-and-maintenance/settings.md#proxies).
+
+## Install root certificates in Docker images
+
+To enable containers to use and trust the Zscaler proxy, embed the certificate
+in the image and configure the image's trust store. Installing certificates at
+image build time is the preferred approach, as it removes the need for
+configuration during startup and provides an auditable, consistent environment.
+
+### Obtaining the root certificate
+
+The easiest way to obtain the root certificate is to export it from a machine
+where an administrator has already installed it. You can use either a web
+browser or the system's certificate management service (for example, Windows
+Certificate Store).
+
+#### Example: Exporting the certificate using Google Chrome
+
+1. In Google Chrome, navigate to `chrome://certificate-manager/`.
+2. Under **Local certificates**, select **View imported certificates**.
+3. Find the Zscaler root certificate, often labeled **Zscaler Root CA**.
+4. Open the certificate details and select **Export**.
+5. Save the certificate in ASCII PEM format.
+6. Open the exported file in a text editor to confirm it includes `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----`.
+
+When you have obtained the certificate, store it in an accessible repository,
+such as JFrog Artifactory or a Git repository. Alternatively, use generic
+storage like AWS S3.
+
+### Building with the certificate
+
+To install these certificates when building images, copy the certificate into
+the build container and update the trust store. An example Dockerfile looks
+like this:
+
+```dockerfile
+FROM debian:bookworm
+COPY zscaler-root-ca.crt /usr/local/share/ca-certificates/zscaler-root-ca.crt
+RUN apt-get update && \
+    apt-get install -y ca-certificates && \
+    update-ca-certificates
+```
+
+Here, `zscaler-root-ca.crt` is the root certificate, located at the root of the
+build context (often within the application's Git repository).
+
+If you use an artifact repository, you can fetch the certificate directly using
+the `ADD` instruction. You can also use the `--checksum` flag to verify that
+the content digest of the certificate is correct.
+
+```dockerfile
+FROM debian:bookworm
+ADD --checksum=sha256:24454f830cdb571e2c4ad15481119c43b3cafd48dd869a9b2945d1036d1dc68d \
+    https://artifacts.example/certs/zscaler-root-ca.crt /usr/local/share/ca-certificates/zscaler-root-ca.crt
+RUN apt-get update && \
+    apt-get install -y ca-certificates && \
+    update-ca-certificates
+```
+
+#### Using multi-stage builds
+
+For multi-stage builds where certificates are needed in the final runtime
+image, ensure the certificate installation occurs in the final stage.
+
+```dockerfile
+FROM debian:bookworm AS build
+WORKDIR /build
+RUN apt-get update && apt-get install -y \
+    build-essential \
+    cmake \
+    curl \
+    git
+RUN --mount=target=. cmake -B output/
+
+FROM debian:bookworm-slim AS final
+ADD --checksum=sha256:24454f830cdb571e2c4ad15481119c43b3cafd48dd869a9b2945d1036d1dc68d \
+    https://artifacts.example/certs/zscaler-root-ca.crt /usr/local/share/ca-certificates/zscaler-root-ca.crt
+RUN apt-get update && \
+    apt-get install -y ca-certificates && \
+    update-ca-certificates
+WORKDIR /app
+COPY --from=build /build/output/bin .
+ENTRYPOINT ["/app/bin"]
+```
+
+## Conclusion
+
+Embedding the Zscaler root certificate directly into your Docker images ensures
+that containers run smoothly within Zscaler-proxied environments. By using this
+approach, you reduce potential runtime errors and create a consistent,
+auditable configuration that allows for smooth Docker operations within a
+monitored network.
diff --git a/content/guides/zscaler/index.md b/content/guides/zscaler/index.md
deleted file mode 100644
index c6b7b32b2b01..000000000000
--- a/content/guides/zscaler/index.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: Using Docker with Zscaler
-tags: [networking, admin]
-summary: |
-  This guide explains how to embed Zscaler’s root certificate into Docker
-  images, allowing containers to operate securely with Zscaler proxies and
-  avoid SSL errors.
-params:
-  time: 10 minutes
----
-
-In many corporate environments, network traffic is intercepted and monitored
-using HTTPS proxies, such as Zscaler. While Zscaler ensures security compliance
-and network control, it can cause issues for developers using Docker,
-particularly during build processes, where SSL certificate validation errors
-might occur. This guide outlines how to configure Docker containers and builds
-to properly handle Zscaler's custom certificates, ensuring smooth operation in
-monitored environments.
-
-## The role of certificates in Docker
-
-When Docker builds or runs containers, it often needs to fetch resources from
-the internet—whether it's pulling a base image from a registry, downloading
-dependencies, or communicating with external services. In a proxied
-environment, Zscaler intercepts HTTPS traffic and replaces the remote server's
-certificate with its own. However, Docker doesn't trust this Zscaler
-certificate by default, leading to SSL errors.
-
-```plaintext
-x509: certificate signed by unknown authority
-```
-
-These errors occur because Docker cannot verify the validity of the certificate
-presented by Zscaler. To avoid this, you must configure Docker to trust
-Zscaler's certificate.
-
-## Configure Zscaler proxy for Docker Desktop
-
-Depending on how Zscaler is deployed, you may need to configure Docker Desktop
-proxy settings manually to use the Zscaler proxy.
-
-If you're using Zscaler as a system-level proxy via the [Zscaler Client Connector](https://help.zscaler.com/zscaler-client-connector/what-is-zscaler-client-connector),
-all traffic on the device is automatically routed through Zscaler, so Docker
-Desktop uses the Zscaler proxy automatically with no additional configuration
-necessary.
-
-If you are not using Zscaler as a system-level proxy, manually configure proxy
-settings in Docker Desktop. Set up proxy settings for all clients in the
-organization using [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md),
-or edit proxy configuration in the Docker Desktop GUI under [**Settings > Resources > Proxies**](/manuals/desktop/settings-and-maintenance/settings.md#proxies).
-
-## Install root certificates in Docker images
-
-To enable containers to use and trust the Zscaler proxy, embed the certificate
-in the image and configure the image's trust store. Installing certificates at
-image build time is the preferred approach, as it removes the need for
-configuration during startup and provides an auditable, consistent environment.
-
-### Obtaining the root certificate
-
-The easiest way to obtain the root certificate is to export it from a machine
-where an administrator has already installed it. You can use either a web
-browser or the system's certificate management service (for example, Windows
-Certificate Store).
-
-#### Example: Exporting the certificate using Google Chrome
-
-1. In Google Chrome, navigate to `chrome://certificate-manager/`.
-2. Under **Local certificates**, select **View imported certificates**.
-3. Find the Zscaler root certificate, often labeled **Zscaler Root CA**.
-4. Open the certificate details and select **Export**.
-5. Save the certificate in ASCII PEM format.
-6. Open the exported file in a text editor to confirm it includes `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----`.
-
-When you have obtained the certificate, store it in an accessible repository,
-such as JFrog Artifactory or a Git repository. Alternatively, use generic
-storage like AWS S3.
-
-### Building with the certificate
-
-To install these certificates when building images, copy the certificate into
-the build container and update the trust store. An example Dockerfile looks
-like this:
-
-```dockerfile
-FROM debian:bookworm
-COPY zscaler-root-ca.crt /usr/local/share/ca-certificates/zscaler-root-ca.crt
-RUN apt-get update && \
-    apt-get install -y ca-certificates && \
-    update-ca-certificates
-```
-
-Here, `zscaler-root-ca.crt` is the root certificate, located at the root of the
-build context (often within the application's Git repository).
-
-If you use an artifact repository, you can fetch the certificate directly using
-the `ADD` instruction. You can also use the `--checksum` flag to verify that
-the content digest of the certificate is correct.
-
-```dockerfile
-FROM debian:bookworm
-ADD --checksum=sha256:24454f830cdb571e2c4ad15481119c43b3cafd48dd869a9b2945d1036d1dc68d \
-    https://artifacts.example/certs/zscaler-root-ca.crt /usr/local/share/ca-certificates/zscaler-root-ca.crt
-RUN apt-get update && \
-    apt-get install -y ca-certificates && \
-    update-ca-certificates
-```
-
-#### Using multi-stage builds
-
-For multi-stage builds where certificates are needed in the final runtime
-image, ensure the certificate installation occurs in the final stage.
-
-```dockerfile
-FROM debian:bookworm AS build
-WORKDIR /build
-RUN apt-get update && apt-get install -y \
-    build-essential \
-    cmake \
-    curl \
-    git
-RUN --mount=target=. cmake -B output/
-
-FROM debian:bookworm-slim AS final
-ADD --checksum=sha256:24454f830cdb571e2c4ad15481119c43b3cafd48dd869a9b2945d1036d1dc68d \
-    https://artifacts.example/certs/zscaler-root-ca.crt /usr/local/share/ca-certificates/zscaler-root-ca.crt
-RUN apt-get update && \
-    apt-get install -y ca-certificates && \
-    update-ca-certificates
-WORKDIR /app
-COPY --from=build /build/output/bin .
-ENTRYPOINT ["/app/bin"]
-```
-
-## Conclusion
-
-Embedding the Zscaler root certificate directly into your Docker images ensures
-that containers run smoothly within Zscaler-proxied environments. By using this
-approach, you reduce potential runtime errors and create a consistent,
-auditable configuration that allows for smooth Docker operations within a
-monitored network.
diff --git a/content/includes/aci-ecs-eol.md b/content/includes/aci-ecs-eol.md
deleted file mode 100644
index b106ceb43860..000000000000
--- a/content/includes/aci-ecs-eol.md
+++ /dev/null
@@ -1,3 +0,0 @@
-> [!IMPORTANT]
->
-> Docker Compose's integration for ECS and ACI is retiring in November 2023.
diff --git a/content/includes/admin-company-overview.md b/content/includes/admin-company-overview.md
deleted file mode 100644
index 9595e947572d..000000000000
--- a/content/includes/admin-company-overview.md
+++ /dev/null
@@ -1,22 +0,0 @@
-A company provides a single point of visibility across multiple organizations. This view simplifies the management of Docker organizations and settings. Organization owners with a Docker Business subscription can create a company and then manage it through the [Docker Admin Console](https://app.docker.com/admin).
-
-The following diagram depicts the setup of a company and how it relates to associated organizations.
-
-![company-hierarchy](/admin/images/docker-admin-structure.webp)
-
-## Key features
-
-With a company, administrators can:
-
-- View and manage all nested organizations and configure settings centrally
-- Carefully control access to the company and company settings
-- Have up to ten unique users assigned the company owner role
-- Configure SSO and SCIM for all nested organizations
-- Enforce SSO for all users in the company
-
-## Prerequisites
-
-Before you create a company, verify the following:
-
-- Any organizations you want to add to a company have a Docker Business subscription
-- You're an organization owner for your organization and any additional organizations you want to add
diff --git a/content/includes/admin-org-overview.md b/content/includes/admin-org-overview.md
deleted file mode 100644
index 3aff83bc2fea..000000000000
--- a/content/includes/admin-org-overview.md
+++ /dev/null
@@ -1,14 +0,0 @@
-An organization in Docker is a collection of teams and repositories
-that can be managed together. A team is a group of Docker members that belong to an organization.
-An organization can have multiple teams. Members don't have to be added to a team to be part of an organization.
-
-Docker users become members of an organization once they're associated with that organization by an organization owner. An organization owner is a user with administrative access to the organization.
-
-Owners can invite users, assign them roles, create new teams, and add
-members to an existing team using their Docker ID or email address. An organization owner can also add
-additional owners to help them manage users, teams, and repositories in the
-organization.
-
-The following diagram depicts the setup of an organization and how it relates to teams. Teams are an optional feature that owners can use to group members and assign permissions.
-
-![organization-hierarchy](/admin/images/org-structure.webp)
diff --git a/content/includes/buildx-v0.10-disclaimer.md b/content/includes/buildx-v0.10-disclaimer.md
deleted file mode 100644
index 855bc5f58b61..000000000000
--- a/content/includes/buildx-v0.10-disclaimer.md
+++ /dev/null
@@ -1,8 +0,0 @@
-> [!NOTE]
->
-> Buildx v0.10 enables support for a minimal [SLSA Provenance](https://slsa.dev/provenance/)
-> attestation, which requires support for [OCI-compliant](https://github.com/opencontainers/image-spec)
-> multi-platform images. This may introduce issues with registry and runtime support
-> (e.g. [Google Cloud Run and AWS Lambda](https://github.com/docker/buildx/issues/1533)).
-> You can optionally disable the default provenance attestation functionality
-> using `--provenance=false`.
diff --git a/content/includes/compose-eol.md b/content/includes/compose-eol.md
deleted file mode 100644
index 711d40880170..000000000000
--- a/content/includes/compose-eol.md
+++ /dev/null
@@ -1,5 +0,0 @@
-> [!IMPORTANT]
->
-> Docker's documentation refers to and describes Compose V2 functionality. 
->
-> Effective July 2023, Compose V1 stopped receiving updates and is no longer in new Docker Desktop releases. Compose V2 has replaced it and is now integrated into all current Docker Desktop versions. For more information, see [Migrate to Compose V2](/compose/migrate).
diff --git a/content/includes/compose/configs.md b/content/includes/compose/configs.md
index 639b679661fc..93711909b237 100644
--- a/content/includes/compose/configs.md
+++ b/content/includes/compose/configs.md
@@ -1 +1 @@
-Configs let services to adapt their behaviour without the need to rebuild a Docker image. As with volumes, configs are mounted as files into a container's filesystem. The location of the mount point within the container defaults to `/<config-name>` in Linux containers and `C:\<config-name>` in Windows containers. 
+Configs let services adapt their behaviour without the need to rebuild a Docker image. As with volumes, configs are mounted as files into a container's filesystem. The location of the mount point within the container defaults to `/<config-name>` in Linux containers and `C:\<config-name>` in Windows containers. 
diff --git a/content/includes/compose/fragments.md b/content/includes/compose/fragments.md
index b4f56ed6db27..c6e8e5b0305b 100644
--- a/content/includes/compose/fragments.md
+++ b/content/includes/compose/fragments.md
@@ -1 +1 @@
-With Compose, you can use built-in [YAML](https://www.yaml.org/spec/1.2/spec.html#id2765878) features to make your Compose file neater and more efficient. Anchors and aliases let you create re-usable blocks. This is useful if you start to find common configurations that span multiple services. Having re-usable blocks minimizes potential mistakes.
+With Compose, you can use built-in [YAML](https://www.yaml.org/spec/1.2/spec.html#id2765878) features to make your Compose file neater and more efficient. Anchors and aliases let you create reusable blocks. This is useful if you start to find common configurations that span multiple services. Having reusable blocks minimizes potential mistakes.
diff --git a/content/includes/daemon-cfg-desktop.md b/content/includes/daemon-cfg-desktop.md
new file mode 100644
index 000000000000..d00bf3813b18
--- /dev/null
+++ b/content/includes/daemon-cfg-desktop.md
@@ -0,0 +1,6 @@
+> [!NOTE]
+>
+> If you're using Docker Desktop, edit the daemon configuration through the
+> Docker Desktop Dashboard. Open **Settings** and select **Docker Engine**.
+> For details, see
+> [Docker Engine settings](/manuals/desktop/settings-and-maintenance/settings.md#docker-engine).
diff --git a/content/includes/deploy.md b/content/includes/deploy.md
deleted file mode 100644
index 0512c4418de2..000000000000
--- a/content/includes/deploy.md
+++ /dev/null
@@ -1,28 +0,0 @@
-Now that we have configured a CI/CD pipeline, let's look at how we can deploy the application. Docker supports deploying containers on Azure ACI and AWS ECS. You can also deploy your application to Kubernetes if you have enabled Kubernetes in Docker Desktop.
-
-## Docker and Azure ACI
-
-The Docker Azure Integration enables developers to use native Docker commands to run applications in Azure Container Instances (ACI) when building cloud-native applications. The new experience provides a tight integration between Docker Desktop and Microsoft Azure allowing developers to quickly run applications using the Docker CLI or VS Code extension to switch seamlessly from local development to cloud deployment.
-
-For detailed instructions, see [Deploying Docker containers on Azure](/cloud/aci-integration/).
-
-## Docker and AWS ECS
-
-The Docker ECS Integration enables developers to use native Docker commands in the Docker Compose CLI to run applications in an Amazon EC2 Container Service (ECS) when building cloud-native applications.
-
-The integration between Docker and Amazon ECS allows developers to use the Docker Compose CLI to set up an AWS context in one Docker command, allowing them to switch from a local context to a cloud context and run applications quickly and easily to simplify multi-container application development on Amazon ECS using Compose files.
-
-For detailed instructions, see [Deploying Docker containers on ECS](/cloud/ecs-integration/).
-
-## Kubernetes
-
-Docker Desktop includes a standalone Kubernetes server and client, as well as Docker CLI integration that runs on your machine. When you enable Kubernetes, you can test your workloads on Kubernetes.
-
-To enable Kubernetes:
-
-1. From the Docker menu, select **Settings**.
-2. Select **Kubernetes** and click **Enable Kubernetes**.
-
-    This starts a Kubernetes single-node cluster when Docker Desktop starts.
-
-For detailed information, see [Deploy on Kubernetes](/manuals/desktop/features/kubernetes.md) and [Describing apps using Kubernetes YAML](/guides/deployment-orchestration/kube-deploy/#describing-apps-using-kubernetes-yaml).
diff --git a/content/includes/desktop-linux-launch.md b/content/includes/desktop-linux-launch.md
index fe90fc1bef5c..28a34afb1a31 100644
--- a/content/includes/desktop-linux-launch.md
+++ b/content/includes/desktop-linux-launch.md
@@ -35,16 +35,16 @@ of these binaries by running the following commands:
 
 ```console
 $ docker compose version
-Docker Compose version v2.29.1
+Docker Compose version v2.39.4
 
 $ docker --version
-Docker version 27.1.1, build 6312585
+Docker version 28.4.0, build d8eb465
 
 $ docker version
-Client: 
- Version:           23.0.5
- API version:       1.42
- Go version:        go1.21.12
+Client:
+ Version:           28.4.0
+ API version:       1.51
+ Go version:        go1.24.7
 <...>
 ```
 
diff --git a/content/includes/dev-envs-changing.md b/content/includes/dev-envs-changing.md
deleted file mode 100644
index edd3984a57f1..000000000000
--- a/content/includes/dev-envs-changing.md
+++ /dev/null
@@ -1,5 +0,0 @@
-> [!IMPORTANT]
->
-> Dev Environments is no longer under active development. 
->
-> While the current functionality remains available, it may take us longer to respond to support requests.
diff --git a/content/includes/dockerfile-labs-channel.md b/content/includes/dockerfile-labs-channel.md
deleted file mode 100644
index 8a7bca00d15b..000000000000
--- a/content/includes/dockerfile-labs-channel.md
+++ /dev/null
@@ -1,3 +0,0 @@
-> [!IMPORTANT]
->
-> The labs channel gives you access to experimental Dockerfile features not yet available in the stable channel.
\ No newline at end of file
diff --git a/content/includes/engine-license.md b/content/includes/engine-license.md
new file mode 100644
index 000000000000..050799b4f94d
--- /dev/null
+++ b/content/includes/engine-license.md
@@ -0,0 +1 @@
+Apache License, Version 2.0. See [LICENSE](https://github.com/moby/moby/blob/master/LICENSE) for the full license.
\ No newline at end of file
diff --git a/content/includes/experimental.md b/content/includes/experimental.md
deleted file mode 100644
index 86cebbd3f983..000000000000
--- a/content/includes/experimental.md
+++ /dev/null
@@ -1,7 +0,0 @@
-Experimental features provide early access to future product functionality.
-These features are intended for testing and feedback only as they may change
-between releases without warning or can be removed entirely from a future
-release. Experimental features must not be used in production environments.
-Docker does not offer support for experimental features.
-
-For a list of current experimental features in the Docker CLI, see [Docker CLI Experimental features](https://github.com/docker/cli/blob/master/experimental/README.md).
diff --git a/content/includes/guides-get-docker.md b/content/includes/guides-get-docker.md
deleted file mode 100644
index 0a5ae3a13a4f..000000000000
--- a/content/includes/guides-get-docker.md
+++ /dev/null
@@ -1 +0,0 @@
-Before you start, get the latest version of [Docker Desktop](/get-started/get-docker.md). Docker adds new features regularly and some parts of this guide may work only with the latest version of Docker Desktop.
diff --git a/content/includes/hub-categories.md b/content/includes/hub-categories.md
index 5b2b747b0c4f..e9acc20681e8 100644
--- a/content/includes/hub-categories.md
+++ b/content/includes/hub-categories.md
@@ -1,34 +1,36 @@
 The categories include:
 
-- **API Management**: Tools for creating, publishing, analyzing, and securing
+- **API management**: Tools for creating, publishing, analyzing, and securing
   APIs.
-- **Content Management System:** Software applications to create and manage
+- **Content management system:** Software applications to create and manage
   digital content through templates, procedures, and standard formats.
-- **Data Science:** Tools and software to support analyzing data and generating
+- **Data science:** Tools and software to support analyzing data and generating
   actionable insights.
-- **Databases & Storage:** Systems for storing, retrieving, and managing data.
-- **Languages & Frameworks:** Programming language runtimes and frameworks.
-- **Integrations & Delivery:** Tools for Continuous Integration (CI) and
+- **Developer tools:** Software and utilities that assist developers in
+  creating, debugging, maintaining, and supporting applications and systems.
+- **Databases & storage:** Systems for storing, retrieving, and managing data.
+- **Languages & frameworks:** Programming language runtimes and frameworks.
+- **Integration & delivery:** Tools for Continuous Integration (CI) and
   Continuous Delivery (CD).
-- **Internet of Things:** Tools supporting Internet of Things (IoT)
+- **Internet of things:** Tools supporting Internet of Things (IoT)
   applications.
-- **Machine Learning & AI:** Tools and frameworks optimized for artificial
+- **Machine learning & AI:** Tools and frameworks optimized for artificial
   intelligence and machine learning projects, such as pre-installed libraries
   and frameworks for data analysis, model training, and deployment.
-- **Message Queues:** Message queuing systems optimized for reliable, scalable,
+- **Message queues:** Message queuing systems optimized for reliable, scalable,
   and efficient message handling.
 - **Monitoring & Observability:** Tools to track software and system performance
   through metrics, logs, and traces, as well as observability to explore the
   system’s state and diagnose issues.
 - **Networking:** Repositories that support data exchange and connecting
   computers and other devices to share resources.
-- **Operating Systems:** Software that manages all other programs on a computer
+- **Operating systems:** Software that manages all other programs on a computer
   and serves as an intermediary between users and the computer hardware, while
   overseeing applications and system resources.
 - **Security:** Tools to protect a computer system or network from theft,
   unauthorized access, or damage to their hardware, software, or electronic
   data, as well as from service disruption.
-- **Web Servers:** Software to serve web pages, HTML files, and other assets to
+- **Web servers:** Software to serve web pages, HTML files, and other assets to
   users or other systems.
-- **Web Analytics:** Tools to collect, measure, analyze, and report on web data
+- **Web analytics:** Tools to collect, measure, analyze, and report on web data
   and website visitor engagement.
\ No newline at end of file
diff --git a/content/includes/hub-org-management.md b/content/includes/hub-org-management.md
deleted file mode 100644
index b75bb77bf96d..000000000000
--- a/content/includes/hub-org-management.md
+++ /dev/null
@@ -1,6 +0,0 @@
-> [!IMPORTANT]
->
-> Organization management is moving to the Admin Console.
->
-> Manage members, team, settings, and activity logs in the Docker Admin Console.
-> Access to these features in Docker Hub will end soon. Explore the [Admin Console](https://app.docker.com/admin).
\ No newline at end of file
diff --git a/content/includes/install-script.md b/content/includes/install-script.md
index c273505dbdaf..e5037aa2412a 100644
--- a/content/includes/install-script.md
+++ b/content/includes/install-script.md
@@ -53,7 +53,7 @@ Executing docker install script, commit: 7cae5f8b0decc17d6571f9f52eb840fbc13b273
 
 You have now successfully installed and started Docker Engine. The `docker`
 service starts automatically on Debian based distributions. On `RPM` based
-distributions, such as CentOS, Fedora, RHEL or SLES, you need to start it
+distributions, such as CentOS, Fedora or RHEL, you need to start it
 manually using the appropriate `systemctl` or `service` command. As the message
 indicates, non-root users can't run Docker commands by default.
 
diff --git a/content/includes/open-terminal.md b/content/includes/open-terminal.md
deleted file mode 100644
index 845154bc21d7..000000000000
--- a/content/includes/open-terminal.md
+++ /dev/null
@@ -1,10 +0,0 @@
-> [!TIP]
->
-> To run Docker commands, you must use a terminal. Based on your
-> operating system, you can open a terminal by doing the following:
->
-> For Windows, select the Start Menu, specify `cmd`, and then select
-> **Command Prompt**.
->
-> For Mac, select the **Launchpad** icon in the Dock, specify `Terminal` in the
-> search field, then select **Terminal**.
diff --git a/content/includes/swarm-mode.md b/content/includes/swarm-mode.md
index 03202e0ee3b5..8bd9d72d970e 100644
--- a/content/includes/swarm-mode.md
+++ b/content/includes/swarm-mode.md
@@ -7,4 +7,4 @@
 > If you're not planning on deploying with Swarm, use
 > [Docker Compose](/compose/) instead.
 > If you're developing for a Kubernetes deployment, consider using the
-> [integrated Kubernetes feature](/manuals/desktop/features/kubernetes.md) in Docker Desktop.
+> [integrated Kubernetes feature](/manuals/desktop/use-desktop/kubernetes.md) in Docker Desktop.
diff --git a/content/includes/tax-compliance.md b/content/includes/tax-compliance.md
deleted file mode 100644
index fdada055f3c4..000000000000
--- a/content/includes/tax-compliance.md
+++ /dev/null
@@ -1,5 +0,0 @@
-> [!IMPORTANT]
->
-> Starting July 1, 2024, Docker will begin collecting sales tax on subscription fees in compliance with state regulations for customers in the United States. For our global customers subject to VAT, the implementation will start rolling out on July 1, 2024. Note that while the roll out begins on this date, VAT charges may not apply to all applicable subscriptions immediately.
->
-> To ensure that tax assessments are correct, make sure that your [billing information](/billing/details/) and VAT/Tax ID, if applicable, are updated. If you're exempt from sales tax, see [Register a tax certificate](/billing/tax-certificate/).
diff --git a/content/languages/_index.md b/content/languages/_index.md
deleted file mode 100644
index 78fd6dd9e27e..000000000000
--- a/content/languages/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-cascade:
-  build:
-    render: never
----
-
diff --git a/content/languages/c-sharp/_index.md b/content/languages/c-sharp/_index.md
deleted file mode 100644
index a579a538ceda..000000000000
--- a/content/languages/c-sharp/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: C#
-params:
-  icon: https://cdn.jsdelivr.net/gh/devicons/devicon@latest/icons/csharp/csharp-original.svg
----
diff --git a/content/languages/cpp/_index.md b/content/languages/cpp/_index.md
deleted file mode 100644
index f77781db89e4..000000000000
--- a/content/languages/cpp/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: C++
-params:
-  icon: https://cdn.jsdelivr.net/gh/devicons/devicon@latest/icons/cplusplus/cplusplus-original.svg
----
diff --git a/content/languages/go/_index.md b/content/languages/go/_index.md
deleted file mode 100644
index b98a732a750a..000000000000
--- a/content/languages/go/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Go
-params:
-  icon: https://cdn.jsdelivr.net/gh/devicons/devicon@latest/icons/go/go-original.svg
----
diff --git a/content/languages/java/_index.md b/content/languages/java/_index.md
deleted file mode 100644
index 302591c35a09..000000000000
--- a/content/languages/java/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Java
-params:
-  icon: https://cdn.jsdelivr.net/gh/devicons/devicon@latest/icons/java/java-original.svg
----
diff --git a/content/languages/js/_index.md b/content/languages/js/_index.md
deleted file mode 100644
index 92ef7a7ff00d..000000000000
--- a/content/languages/js/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: JavaScript
-params:
-  icon: https://cdn.jsdelivr.net/gh/devicons/devicon@latest/icons/javascript/javascript-original.svg
----
diff --git a/content/languages/php/_index.md b/content/languages/php/_index.md
deleted file mode 100644
index 03bf6baa77ef..000000000000
--- a/content/languages/php/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: PHP
-params:
-  icon: https://cdn.jsdelivr.net/gh/devicons/devicon@latest/icons/php/php-original.svg
----
diff --git a/content/languages/python/_index.md b/content/languages/python/_index.md
deleted file mode 100644
index 1e0a5bb33858..000000000000
--- a/content/languages/python/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Python
-params:
-  icon: https://cdn.jsdelivr.net/gh/devicons/devicon@latest/icons/python/python-original.svg
----
diff --git a/content/languages/r/_index.md b/content/languages/r/_index.md
deleted file mode 100644
index c02712c12d00..000000000000
--- a/content/languages/r/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: R
-params:
-  icon: https://cdn.jsdelivr.net/gh/devicons/devicon@latest/icons/r/r-original.svg
----
diff --git a/content/languages/ruby/_index.md b/content/languages/ruby/_index.md
deleted file mode 100644
index d99155828e3c..000000000000
--- a/content/languages/ruby/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Ruby
-params:
-  icon: https://cdn.jsdelivr.net/gh/devicons/devicon@latest/icons/ruby/ruby-original.svg
----
diff --git a/content/languages/rust/_index.md b/content/languages/rust/_index.md
deleted file mode 100644
index 80b981d535f9..000000000000
--- a/content/languages/rust/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Rust
-params:
-  icon: https://cdn.jsdelivr.net/gh/devicons/devicon@latest/icons/rust/rust-original.svg
----
diff --git a/content/manuals/_index.md b/content/manuals/_index.md
index ac033af064fc..20c7a49c57b4 100644
--- a/content/manuals/_index.md
+++ b/content/manuals/_index.md
@@ -6,116 +6,136 @@ keywords: docker, docs, manuals, products, user guides, how-to
 url: /manuals/
 layout: wide
 params:
-  icon: description
+  icon: document-text
   sidebar:
     groups:
-      - Open source
-      - AI
-      - Products
+      - AI and agents
+      - Application development
+      - Supply chain security
       - Platform
+      - Enterprise
   notoc: true
-  open-source:
+  ai-and-agents:
+  - title: Docker Sandboxes
+    description: Run AI coding agents in isolated environments.
+    icon: command-line
+    link: /ai/sandboxes/
+  - title: MCP Catalog and Toolkit
+    description: Augment your AI workflow with MCP servers.
+    icon: /icons/toolkit.svg
+    link: /ai/mcp-catalog-and-toolkit/
+  - title: Gordon
+    description: Streamline your workflow and get the most out of the Docker ecosystem with your personal AI assistant.
+    icon: document-plus
+    link: /ai/gordon/
+  - title: Docker Model Runner
+    description: View and manage your local models.
+    icon: /icons/models.svg
+    link: /ai/model-runner/
+  - title: Docker Agent
+    description: The open-source multi-agent solution to assist you in your tasks.
+    icon: /icons/cagent.svg
+    link: /ai/docker-agent
+  application-development:
+  - title: Docker Desktop
+    description: Your command center for container development.
+    icon: /icons/Whale.svg
+    link: /desktop/
+  - title: Docker Offload
+    description: Build and run containers in the cloud.
+    icon: cloud
+    link: /offload/
+  - title: Docker Build Cloud
+    description: Build your images faster in the cloud.
+    icon: /icons/logo-build-cloud.svg
+    link: /build-cloud/
+  - title: Testcontainers
+    description: Run containers programmatically in your preferred programming language.
+    icon: /icons/Testcontainers.svg
+    link: /testcontainers/
   - title: Docker Build
     description: Build and ship any application anywhere.
-    icon: build
+    icon: wrench-screwdriver
     link: /build/
   - title: Docker Engine
     description: The industry-leading container runtime.
-    icon: developer_board
+    icon: cpu-chip
     link: /engine/
   - title: Docker Compose
     description: Define and run multi-container applications.
-    icon: /assets/icons/Compose.svg
+    icon: /icons/Compose.svg
     link: /compose/
-  - title: Testcontainers
-    description: Run containers programmatically in your preferred programming language.
-    icon: /assets/icons/Testcontainers.svg
-    link: /testcontainers/
-  ai:
-  - title: Ask Gordon
-    description: streamline your workflow and get the most out of the Docker ecosystem with your personal AI assistant.
-    icon: note_add
-    link: /ai/gordon/
-  - title: Docker Model Runner
-    description: View and manage your local models
-    icon: view_in_ar
-    link: /model-runner/
-  products:
-  - title: Docker Desktop
-    description: Your command center for container development.
-    icon: /assets/icons/Whale.svg
-    link: /desktop/
-  - title: Build Cloud
-    description: Build your images faster in the cloud.
-    icon: /assets/images/logo-build-cloud.svg
-    link: /build-cloud/
+  supply-chain-security:
   - title: Docker Hub
     description: Discover, share, and integrate container images.
-    icon: hub
+    icon: globe-alt
     link: /docker-hub/
+  - title: Docker Hardened Images
+    description: Secure, minimal images for trusted software delivery.
+    icon: /icons/dhi.svg
+    link: /dhi/
   - title: Docker Scout
     description: Image analysis and policy evaluation.
-    icon: /assets/icons/Scout.svg
+    icon: /icons/Scout.svg
     link: /scout/
-  - title: Docker for GitHub Copilot
-    description: Integrate Docker's capabilities with GitHub Copilot.
-    icon: chat
-    link: /copilot/
-  - title: Docker Extensions
-    description: Customize your Docker Desktop workflow.
-    icon: extension
-    link: /extensions/
-  - title: Testcontainers Cloud
-    description: Run integration tests, with real dependencies, in the cloud.
-    icon: package_2
-    link: https://testcontainers.com/cloud/docs/
   platform:
   - title: Administration
     description: Centralized observability for companies and organizations.
-    icon: admin_panel_settings
+    icon: shield-check
     link: /admin/
   - title: Billing
     description: Manage billing and payment methods.
-    icon: payments
+    icon: credit-card
     link: /billing/
   - title: Accounts
     description: Manage your Docker account.
-    icon: account_circle
+    icon: user-circle
     link: /accounts/
   - title: Security
     description: Security guardrails for both administrators and developers.
-    icon: lock
+    icon: lock-closed
     link: /security/
   - title: Subscription
     description: Commercial use licenses for Docker products.
-    icon: card_membership
+    icon: credit-card
     link: /subscription/
+  enterprise:
+  - title: Deploy Docker Desktop
+    description: Deploy Docker Desktop at scale within your company
+    icon: arrow-down-tray
+    link: /enterprise/enterprise-deployment/
 ---
 
 This section contains user guides on how to install, set up, configure, and use
 Docker products.
 
-## Open source
+## AI and agents
 
-Open source development and containerization technologies.
+All the Docker AI tools in one easy-to-access location.
 
-{{< grid items=open-source >}}
+{{< grid items=ai-and-agents >}}
 
-## AI
+## Application development
 
-All the Docker AI tools in one easy-to-access location. 
+End-to-end developer solutions for innovative teams.
 
-{{< grid items=ai >}}
+{{< grid items=application-development >}}
 
-## Products
+## Supply chain security
 
-End-to-end developer solutions for innovative teams.
+Security guardrails and image analysis for your software supply chain.
 
-{{< grid items=products >}}
+{{< grid items=supply-chain-security >}}
 
 ## Platform
 
 Documentation related to the Docker platform, such as administration and
-subscription management for organizations.
+subscription management.
 
 {{< grid items=platform >}}
+
+## Enterprise
+
+Targeted at IT administrators with help on deploying Docker Desktop at scale with configuration guidance on security related features.
+
+{{< grid items=enterprise >}}
diff --git a/content/manuals/accounts/_index.md b/content/manuals/accounts/_index.md
index 383593e8755e..67ffb1841983 100644
--- a/content/manuals/accounts/_index.md
+++ b/content/manuals/accounts/_index.md
@@ -1,40 +1,64 @@
 ---
 title: Docker accounts
-description: Learn how to create and manage your Docker account.
-keywords: accounts, docker ID, account management, account settings, docker account, docker home
-weight: 30
+description: >
+  Learn what a Docker account is, how Docker IDs, emails, and sign-in methods
+  relate, and how individual accounts connect to organizations
+keywords: accounts, docker ID, username, email, Google, GitHub, sign-in,
+  authentication, account management, docker account, individual account,
+  organization account, account types, Docker Hub, SSO, deactivate account
+weight: 10
 params:
   sidebar:
     group: Platform
 grid:
-- title: Create a Docker ID
-  description: Get started with Docker and create an account.
-  icon: fingerprint
-  link: /accounts/create-account/
-- title: Manage account
-  description: Learn how to manage the settings for your account.
-  icon: manage_accounts
-  link: /accounts/manage-account/
-- title: Account FAQ
-  description: Explore popular FAQ topics about organizations.
-  icon: help
-  link: /faq/admin/general-faqs/
-- title: Personal access tokens
-  description: Learn how to create and manage access tokens for your account.
-  icon: password
-  link: /security/for-developers/access-tokens/
-- title: Set up two-factor authentication
-  description: Add an extra layer of authentication to your Docker account.
-  link: /security/for-developers/2fa/
-  icon: phonelink_lock
-- title: Deactivate an account
-  description: Learn how to deactivate a Docker user account.
-  link: /accounts/deactivate-user-account/
-  icon: disabled_by_default
+  - title: Create an account
+    description: Get started with Docker and create an account.
+    icon: finger-print
+    link: /accounts/create-account/
+  - title: Manage account
+    description: Learn how to manage the settings for your account.
+    icon: cog
+    link: /accounts/manage-account/
+  - title: Personal access tokens
+    description: Learn how to create and manage access tokens for your account.
+    icon: lock-closed
+    link: /security/access-tokens/
+  - title: Set up two-factor authentication
+    description: Add an extra layer of authentication to your Docker account.
+    link: /security/2fa/
+    icon: device-phone-mobile
+  - title: Organization overview
+    description: Learn how to create and manage Docker organizations.
+    icon: building-storefront
+    link: /admin/organization/
+  - title: Account FAQs
+    description: Explore frequently asked questions about Docker accounts.
+    icon: question-mark-circle
+    link: /accounts/general-faqs/
 ---
 
-You can create a Docker account to secure a Docker ID, which is a username for your account that lets you access Docker products. You can use your Docker account to sign in to Docker products like Docker Hub, Docker Desktop, or Docker Scout. You can centrally manage your [Docker account settings](https://app.docker.com/settings), as well as account security features, in [Docker Home](https://app.docker.com).
+A Docker account is how Docker identifies you. Use it to access products like
+Docker Hub and Docker Desktop, manage settings, and join organizations.
 
-In this section, explore how you can create, manage, or update your account.
+Docker has two primary account types: individual and organization. You create
+and administer organizations with your individual account. For organization
+accounts, see [Organizations](/manuals/admin/organization/_index.md). For
+organizations and companies, see [Administration](/manuals/admin/_index.md).
+
+## Docker ID, email, and sign-in
+
+When you create an account, you choose a Docker ID and a sign-in method.
+Docker also ties a verified email to the account.
+
+- Docker account: Associates your plans, Hub repositories, and account
+  settings.
+- Docker ID: A unique username that identifies you.
+- Email: How Docker contacts you for notifications and security-related
+  communications.
+- Sign-in method: Email and password,
+  [single sign-on (SSO)](/manuals/enterprise/security/single-sign-on/_index.md),
+  Google, or GitHub.
+
+## Next steps
 
 {{< grid >}}
diff --git a/content/manuals/accounts/create-account.md b/content/manuals/accounts/create-account.md
index 746c7f132777..5bdff24960c3 100644
--- a/content/manuals/accounts/create-account.md
+++ b/content/manuals/accounts/create-account.md
@@ -1,102 +1,89 @@
 ---
-title: Create an account
+title: Create a Docker account
+linkTitle: Create
 weight: 10
-description: Learn how to register for a Docker ID and sign in to your account
-keywords: accounts, docker ID, billing, paid plans, support, Hub, Store, Forums, knowledge
-  base, beta access, email, activation, verification
+description: Create a Docker ID with email, Google, or GitHub, then verify your
+  account
+keywords:
+  create docker account, docker ID, sign up, sign in, email, Google, GitHub,
+  verification, OTP, password, docker login, username requirements
 aliases:
-- /docker-hub/accounts/
-- /docker-id/
+  - /docker-hub/accounts/
+  - /docker-id/
 ---
 
-You can create a free Docker account with your email address or by signing up with your Google or GitHub account. Once you've created your account with a unique Docker ID, you can access all Docker products, including Docker Hub. With Docker Hub, you can access repositories and explore images that are available from the community and verified publishers.
+You can create a free Docker account with your email address or by signing up
+with your Google or GitHub account. After creating a unique Docker ID, you can
+access Docker products, including Docker Hub, Docker Desktop, and Docker Scout.
 
-Your Docker ID becomes your username for hosted Docker services, and [Docker forums](https://forums.docker.com/).
+Your Docker ID becomes your username for hosted Docker services and
+[Docker forums](https://forums.docker.com/).
 
 > [!TIP]
 >
-> Explore [Docker's subscriptions](https://www.docker.com/pricing/) to see what else Docker can offer you.
+> See
+> [Docker's subscriptions](https://www.docker.com/pricing?ref=Docs&refAction=DocsCreateAccount)
+> for available plans.
 
-## Create a Docker ID
+## Create and verify your account
 
-### Sign up with your email address
+Signing up with an email address, Google, or GitHub requires verification
+before you can sign in:
 
-1. Go to the [Docker sign-up page](https://app.docker.com/signup/).
-
-2. Enter a unique, valid email address.
-
-3. Enter a username to use as your Docker ID. Once you create your Docker ID you can't reuse it in the future if you deactivate this account.
-
-    Your username:
-    - Must be between 4 and 30 characters long
-    - Can only contain numbers and lowercase letters
+- If you sign up with Google or GitHub, verify your email address with that
+  provider first.
+- If you sign up with an email address, Docker sends a one-time password
+  (OTP). Enter the code from the Docker email on the OTP page.
 
-4. Enter a password that's at least 9 characters long.
+Docker blocks sign-in until you've verified your account.
 
-5. Select **Sign Up**.
+{{< tabs >}}
+{{< tab name="Email" >}}
 
-6. Open your email client. Docker sends a verification email to the address you provided.
-
-7. Verify your email address to complete the registration process.
-
-> [!NOTE]
->
-> You must verify your email address before you have full access to Docker's features.
+1. Go to the [Docker sign-up page](https://app.docker.com/signup/) and enter a
+   unique, valid email address.
+1. Enter a username to use as your Docker ID. After you create your Docker
+   ID, you can't change it or reuse it if you deactivate this account. Your
+   username:
+   - Must be between 4 and 30 characters long
+   - Can only contain numbers and lowercase letters
+1. Choose a password that's at least 9 characters long, then select
+   **Sign up**.
+1. Verify your email address when you receive the Docker OTP verification
+   email. This completes the registration process.
 
-### Sign up with Google or GitHub
-
-> [!IMPORTANT]
->
-> To sign up with your social provider, you must verify your email address with your provider before you begin.
+{{< /tab >}}
+{{< tab name="Google or GitHub" >}}
 
 1. Go to the [Docker sign-up page](https://app.docker.com/signup/).
+1. Select your social provider, Google or GitHub.
+1. Select the social account you want to link to your Docker account.
+1. Select **Authorize Docker** to let Docker access your social account
+   information. Docker redirects you to the sign-up page.
+1. Enter a username to use as your Docker ID. After you create your Docker
+   ID, you can't change it or reuse it if you deactivate this account. Your
+   username:
+   - Must be between 4 and 30 characters long
+   - Can only contain numbers and lowercase letters
+1. Select **Sign up**.
+
+{{< /tab >}}
+{{< /tabs >}}
 
-2. Select your social provider, Google or GitHub.
-
-3. Select the social account you want to link to your Docker account.
-
-4. Select **Authorize Docker** to let Docker to access your social account information. You will be re-routed to the sign-up page.
-
-5. Enter a username to use as your Docker ID.
-
-    Your username:
-    - Must be between 4 and 30 characters long
-    - Can only contain numbers and lowercase letters
-
-6. Select **Sign up**.
-
-## Sign in
-
-Once you register your Docker ID and verify your email address, you can sign in to [your Docker account](https://login.docker.com/u/login/). You can either:
-- Sign in with your email address (or username) and password.
-- Sign in with your social provider. For more information, see [Sign in with your social provider](#sign-in-with-your-social-provider).
-- Sign in through the CLI using the `docker login` command. For more information, see [`docker login`](/reference/cli/docker/login.md).
-
-> [!WARNING]
->
-> When you use the `docker login` command, your credentials are
-stored in your home directory in `.docker/config.json`. The password is base64-encoded in this file.
->
-> We recommend using one of the [Docker credential helpers](https://github.com/docker/docker-credential-helpers) for secure storage of passwords. For extra security, you can also use a [personal access token](../security/for-developers/access-tokens.md) to sign in instead, which is still encoded in this file (without a Docker credential helper) but doesn't permit administrator actions (such as changing the password).
-
-### Sign in with your social provider
-
-> [!IMPORTANT]
->
-> To sign in with your social provider, you must verify your email address with your provider before you begin.
-
-You can also sign in to your Docker account with your Google or GitHub account. If a Docker account exists with the same email address as the primary email for your social provider, your Docker account will automatically be linked to the social profile. This lets you sign in with your social provider.
-
-If you try to sign in with your social provider and don't have a Docker account yet, a new account will be created for you. Follow the on-screen instructions to create a Docker ID using your social provider.
+## Troubleshooting
 
-## Reset your password at sign in
+If you have a paid Docker subscription,
+[contact the Support team](https://hub.docker.com/support/contact/) for
+assistance.
 
-To reset your password, enter your email address on the [Sign in](https://login.docker.com/u/login) page and continue to sign in. When prompted for your password, select **Forgot password?**.
+All Docker users can seek troubleshooting information and support through the
+following resources, where Docker or the community respond on a best-effort
+basis:
 
-## Troubleshooting
+- [Docker Community Forums](https://forums.docker.com/)
+- [Docker Community Slack](https://dockr.ly/comm-slack)
 
-If you have a paid Docker subscription, you can [contact the Support team](https://hub.docker.com/support/contact/) for assistance.
+## Next steps
 
-All Docker users can seek troubleshooting information and support through the following resources, where Docker or the community respond on a best effort basis:
-   - [Docker Community Forums](https://forums.docker.com/)
-   - [Docker Community Slack](http://dockr.ly/comm-slack)
+- [Manage a Docker account](/manuals/accounts/manage-account.md)
+- [Enable two-factor authentication](/manuals/security/2fa/_index.md)
diff --git a/content/manuals/accounts/deactivate-user-account.md b/content/manuals/accounts/deactivate-user-account.md
index 21788c607b31..e7203eb6b47c 100644
--- a/content/manuals/accounts/deactivate-user-account.md
+++ b/content/manuals/accounts/deactivate-user-account.md
@@ -1,46 +1,72 @@
 ---
-title: Deactivate an account
+title: Deactivate a Docker account
+linkTitle: Deactivate
 weight: 30
-description: Learn how to deactivate a Docker user account.
-keywords: Docker Hub, delete, deactivate, account, account management
+description: Prerequisites and steps to deactivate an individual Docker account
+keywords:
+  deactivate docker account, delete docker account, close docker account,
+  disable docker account, account management, leave organization, privacy
+  request, personal data
 ---
 
-You can deactivate an account at any time. This section describes the prerequisites and steps to deactivate a user account. For information on deactivating an organization, see [Deactivating an organization](../admin/organization/deactivate-account.md).
+Learn how to deactivate an individual Docker account, including the
+prerequisites required for deactivation.
 
->[!WARNING]
+For information on deactivating an organization, see
+[Deactivate an organization](/manuals/admin/organization/deactivate-account.md).
+
+> [!WARNING]
 >
-> All Docker products and services that use your Docker account will be inaccessible after deactivating your account.
+> All Docker products and services that use your Docker account are
+> inaccessible after deactivating your account.
 
 ## Prerequisites
 
-Before deactivating your Docker account, ensure you meet the following requirements:
-
-- For owners, you must leave your organization or company before deactivating your Docker account.
-    To do this:
-    1. Sign in to the [Docker Admin Console](https://app.docker.com/admin).
-    2. Select the organization you need to leave from the **Choose profile** page.
-    3. Find your username in the **Members** tab.
-    4. Select the **More options** menu and then select **Leave organization**.
-
-- If you are the sole owner of an organization, you must assign the owner role to another member of the organization and then remove yourself from the organization, or deactivate the organization. Similarly, if you are the sole owner of a company, either add someone else as a company owner and then remove yourself, or deactivate the company.
+Before deactivating your Docker account, complete the following
+requirements:
 
-- If you have an active Docker subscription, [downgrade it to a Docker Personal subscription](../subscription/change.md).
-
-- Download any images and tags you want to keep. Use `docker pull -a <image>:<tag>`.
-
-- Unlink your [GitHub and Bitbucket accounts](../docker-hub/repos/manage/builds/link-source.md#unlink-a-github-user-account).
+- If you are an organization or company owner, you must leave your
+  organization or company before deactivating your Docker account:
+  1. Sign in to [Docker Home](https://app.docker.com/admin) and choose your
+     organization.
+  1. Select **Members** and find your username.
+  1. Select the **Actions** menu and then select **Leave organization**.
+- If you are the sole owner of an organization, you must assign the owner
+  role to another member of the organization and then remove yourself from
+  the organization, or deactivate the organization. Similarly, if you are
+  the sole owner of a company, either add someone else as a company owner
+  and then remove yourself, or deactivate the company.
+- If you have an active Docker subscription,
+  [downgrade it to a Docker Personal
+  subscription](/manuals/subscription/plans/docker.md#cancel-a-docker-plan).
+- Download any images and tags you want to keep. Use
+  `docker pull -a <image>` to pull all tags, or `docker pull <image>:<tag>`
+  to pull a specific tag.
+- If you linked a GitHub or Bitbucket account for automated builds, unlink
+  it. See
+  [Unlink a GitHub user
+  account](/manuals/docker-hub/repos/manage/builds/link-source.md#unlink-a-github-user-account)
+  or
+  [Unlink a Bitbucket user
+  account](/manuals/docker-hub/repos/manage/builds/link-source.md#unlink-a-bitbucket-user-account).
 
 ## Deactivate
 
-Once you have completed all the previous steps, you can deactivate your account.
+After you complete the prerequisites, you can deactivate your account.
 
 > [!WARNING]
 >
-> This cannot be undone. Be sure you've gathered all the data you need from your account before deactivating it.
+> Deactivating your account is permanent and can't be undone. Make sure
+> to back up any important data.
 
 1. Sign in to [Docker Home](https://app.docker.com/login).
-2. Select your avatar to open the drop-down menu.
-3. Select **Account settings**.
-4. Select **Deactivate**.
-5. Select **Deactivate account**.
-6. To confirm, select **Deactivate account**.
+1. Select your avatar to open the drop-down menu.
+1. Select **Account settings**.
+1. Select **Deactivate**.
+1. Select **Deactivate account**, then select again to confirm.
+
+## Delete personal data
+
+Deactivating your account does not delete your personal data. To request
+personal data deletion, fill out Docker's
+[Privacy request form](https://preferences.docker.com/).
diff --git a/content/manuals/accounts/general-faqs.md b/content/manuals/accounts/general-faqs.md
new file mode 100644
index 000000000000..8e00863d7881
--- /dev/null
+++ b/content/manuals/accounts/general-faqs.md
@@ -0,0 +1,62 @@
+---
+title: Docker account FAQs
+linkTitle: FAQs
+weight: 40
+description: FAQs about Docker IDs, account creation, and organization names
+keywords:
+  docker ID, docker account FAQ, change docker ID, username taken, trademark,
+  organization name, organization namespace, create account, Google, GitHub,
+  deactivate docker ID
+tags: [FAQ]
+aliases:
+  - /docker-hub/general-faqs/
+  - /docker-hub/onboarding-faqs/
+  - /faq/admin/general-faqs/
+  - /admin/faqs/general-faqs/
+---
+
+## What is a Docker ID?
+
+A Docker ID is a username for your Docker account that lets you access Docker
+products. To create a Docker ID you need one of the following:
+
+- An email address
+- A Google account
+- A GitHub account
+
+Your Docker ID must be between 4 and 30 characters long, and can only contain
+numbers and lowercase letters. You can't use any special characters or spaces.
+
+For more information, see
+[Create a Docker account](/manuals/accounts/create-account.md).
+
+## Can I change my Docker ID?
+
+No. You can't change your Docker ID once it's created. If you need a different
+Docker ID, you must create a new Docker account with a new Docker ID.
+
+Docker IDs can't be reused after deactivation.
+
+## What if my Docker ID is taken?
+
+All Docker IDs are first-come, first-served except for companies that have a
+U.S. Trademark on a username.
+
+If you have a trademark for your Docker ID,
+[Docker Support](https://hub.docker.com/support/contact/) can retrieve the
+Docker ID for you.
+
+## What's an organization name or namespace?
+
+The organization name, sometimes referred to as the organization namespace or
+the organization ID, is the unique identifier of a Docker organization. The
+organization name can't be the same as an existing Docker ID.
+
+For more information, see
+[Docker organization overview](/manuals/admin/organization/_index.md).
+
+## Next steps
+
+- [Create a Docker account](/manuals/accounts/create-account.md)
+- [Manage a Docker account](/manuals/accounts/manage-account.md)
+- [Docker organization overview](/manuals/admin/organization/_index.md)
diff --git a/content/manuals/accounts/manage-account.md b/content/manuals/accounts/manage-account.md
index 02684e50f77b..d75ab1ab4f35 100644
--- a/content/manuals/accounts/manage-account.md
+++ b/content/manuals/accounts/manage-account.md
@@ -1,92 +1,130 @@
 ---
-title: Manage an account
+title: Manage a Docker account
+linkTitle: Manage
 weight: 20
-description: Learn how to manage settings for your Docker account.
-keywords: accounts, docker ID, account settings, account management, docker home
+description: Update account settings, email, password, 2FA, tokens, and
+  connected accounts
+keywords:
+  manage docker account, account settings, update email, change password,
+  Gravatar, two-factor authentication, personal access tokens, Google, GitHub,
+  connected accounts, convert account, deactivate account, Docker Home
 ---
 
-You can centrally manage your Docker account settings using Docker Home. Here
-you can also take administrative actions for your account and manage your
-account security.
+You can manage your Docker account in Docker Home, including administrative
+and security settings.
 
 > [!TIP]
 >
 > If your account is associated with an organization that enforces single
 > sign-on (SSO), you may not have permissions to update your account settings.
-> You must contact your administrator to update your settings.
+> Contact your administrator to update your settings.
 
-## Update general settings
+## Update account information
 
-1. Sign in to your [Docker account](https://app.docker.com/login).
-2. In Docker Home, select your avatar in the top-right corner to open the
-drop-down.
-3. Select **Account settings**.
-
-From the Account settings page, you can take any of the following actions.
-
-### Update account information
-
-Account information is visible on your account profile in Docker Hub. You can
-update the following account information:
+Account information is visible on your **Account settings** page. You can
+update the following:
 
 - Full name
 - Company
 - Location
 - Website
-- Gravatar email: To add an avatar to your Docker account, create a
-[Gravatar account](https://gravatar.com/) and create your avatar. Next, add your
-Gravatar email to your Docker account settings. It may take some time for your
-avatar to update in Docker.
+- Gravatar email
+
+To add or update your avatar using Gravatar:
+
+1. Create a [Gravatar account](https://gravatar.com/).
+1. Create your avatar.
+1. Add your Gravatar email to your Docker account settings.
+
+It may take some time for your avatar to update in Docker.
+
+## Update email address
+
+To update your email address:
+
+1. Sign in to your [Docker account](https://app.docker.com/login).
+1. Select your avatar in the top-right corner and select **Account settings**.
+1. Select **Email**.
+1. Enter your new email address and confirm your identity with your password.
+   Select **Verify email**.
+1. Go to the new Docker email and copy the 6-digit verification code.
+1. Paste the verification code to complete updating your email.
+
+Your verification session expires after 15 minutes.
 
-Make your changes here, then select **Save** to save your settings.
+> [!NOTE]
+>
+> Docker accounts only support one verified email address at a time, which
+> is used for account notifications and security-related communications. You
+> can't add multiple verified email addresses to your account.
+
+## Change your password
 
-### Update email address
+Initiate your password reset through email:
 
-To update your email address, select **Email**:
+1. Sign in to your [Docker account](https://app.docker.com/login).
+1. Select your avatar in the top-right corner and select **Account settings**.
+1. Select **Password**, then **Reset password**.
+1. Docker sends you a password reset email with instructions to reset your
+   password.
 
-1. Enter your new email address.
-2. Enter your password to confirm the change.
-3. Select **Send verification email** to send a verification email to your new
-email address.
+## Manage two-factor authentication
 
-Once you verify your email address, your account information will update.
+To update your two-factor authentication (2FA) settings:
 
-### Change your password
+1. Sign in to your [Docker account](https://app.docker.com/login).
+1. Select your avatar in the top-right corner and select **Account settings**.
+1. Select **2FA**.
 
-You can change your password by initiating a password reset via email.
+For more information, see
+[Enable two-factor authentication](/manuals/security/2fa/_index.md).
 
-To change your password, select **Password** and then **Reset password**.
-Follow the instructions in the password reset email.
+## Manage personal access tokens
 
-## Manage security settings
+To manage personal access tokens:
 
-To update your two-factor authentication (2FA) settings, select **2FA**.
-For information on two-factor authentication (2FA) for your account, see
-[Enable two-factor authentication](../security/for-developers/2fa/_index.md)
-to get started.
+1. Sign in to your [Docker account](https://app.docker.com/login).
+1. Select your avatar in the top-right corner and select **Account settings**.
+1. Select **Personal access tokens**.
 
-To manage personal access tokens, select **Personal access tokens**.
-For information on personal access tokens, see
-[Create and manage access tokens](../security/for-developers/access-tokens.md).
+For more information, see
+[Create and manage access tokens](/manuals/security/access-tokens.md).
 
 ## Manage connected accounts
 
-You can unlink Google or GitHub accounts that are linked to your Docker account
-using the Account settings page:
+If you signed up with Google or GitHub, that provider appears under
+**Connected accounts**. Disconnecting it removes the OAuth connection. It
+doesn't change your Docker ID, and it doesn't let you add a different sign-in
+method. You can't connect both Google and GitHub to the same account.
+
+To disconnect a connected account:
 
+1. Sign in to your [Docker account](https://app.docker.com/login).
+1. Select your avatar in the top-right corner and select **Account settings**.
 1. Select **Connected accounts**.
-2. Select **Disconnect** on your connected account.
-3. To fully unlink your Docker account, you must also unlink Docker from Google
+1. Select **Disconnect** on your connected account.
+
+To fully unlink your Docker account, you must also unlink Docker from Google
 or GitHub. See Google or GitHub's documentation for more information:
-    - [Manage connections between your Google Account and third-parties](https://support.google.com/accounts/answer/13533235?hl=en)
-    - [Reviewing and revoking authorization of GitHub Apps](https://docs.github.com/en/apps/using-github-apps/reviewing-and-revoking-authorization-of-github-apps)
 
-## Account management
+- [Manage connections between your Google Account and
+  third-parties](https://support.google.com/accounts/answer/13533235?hl=en)
+- [Reviewing and revoking authorization of GitHub
+  Apps](https://docs.github.com/en/apps/using-github-apps/reviewing-and-revoking-authorization-of-github-apps)
+
+## Convert your account
 
-To convert your account into an organization, select **Convert**.
-For more information on converting your account, see
-[Convert an account into an organization](../admin/organization/convert-account.md).
+For information on converting your account into an organization, see
+[Convert an account into an
+organization](/manuals/admin/organization/setup/convert-account.md).
+
+## Deactivate your account
 
-To deactivate your account, select **Deactivate**.
 For information on deactivating your account, see
-[Deactivating a user account](./deactivate-user-account.md).
+[Deactivate a Docker account](/manuals/accounts/deactivate-user-account.md).
+
+## Next steps
+
+- [Docker accounts overview](/manuals/accounts/_index.md)
+- [Create a Docker account](/manuals/accounts/create-account.md)
+- [Enable two-factor authentication](/manuals/security/2fa/_index.md)
diff --git a/content/manuals/admin/_index.md b/content/manuals/admin/_index.md
index cf5274bfd919..780462e3d624 100644
--- a/content/manuals/admin/_index.md
+++ b/content/manuals/admin/_index.md
@@ -1,51 +1,88 @@
 ---
 title: Administration
-description: Discover manuals on administration for accounts, organizations, and companies.
-keywords: admin, administration, company, organization, Admin Console, user accounts, account management
+description: Overview of administration features and roles in Docker Home
+keywords: admin, administration, company, organization, Docker Home, user accounts, account management
 weight: 10
 params:
   sidebar:
-    group: Platform
+    group: Enterprise
 grid:
-- title: Company administration
-  description: Explore how to manage a company.
-  icon: apartment
-  link: /admin/company/
-- title: Organization administration
-  description: Learn about organization administration.
-  icon: store
-  link: /admin/organization/
-- title: Onboard your organization
-  description: Learn how to onboard and secure your organization.
-  icon: explore
-  link: /admin/organization/onboard
-- title: Company FAQ
-  description: Discover common questions and answers about companies.
-  icon: help
-  link: /faq/admin/company-faqs/
-- title: Organization FAQ
-  description: Explore popular FAQ topics about organizations.
-  icon: help
-  link: /faq/admin/organization-faqs/
-- title: Security
-  description: Explore security features for administrators.
-  icon: shield_locked
-  link: /security/
+  - title: Company administration
+    description: Explore how to manage a company.
+    icon: building-office-2
+    link: /admin/company/
+  - title: Organization administration
+    description: Learn about organization administration.
+    icon: building-storefront
+    link: /admin/organization/
+  - title: Onboard your organization
+    description: Learn how to onboard and secure your organization.
+    icon: magnifying-glass-plus
+    link: /admin/organization/setup/onboard
+  - title: Security
+    description: Explore security features for administrators.
+    icon: shield-check
+    link: /enterprise/security/
 aliases:
-- /docker-hub/admin-overview
+  - /docker-hub/admin-overview
 ---
 
-Administrators can manage companies and organizations using the Docker Admin Console.
+Organization and company owners can manage members, control access, and enforce
+security across their Docker environments. You perform these tasks in Docker
+Home, which provides centralized observability, access management, and security
+controls.
 
-The [Docker Admin Console](https://admin.docker.com) provides administrators with centralized observability, access management, and controls for their company and organizations. To provide these features, Docker uses the following hierarchy and roles.
+As an organization or company owner, you can:
 
-![Docker hierarchy](./images/docker-admin-structure.webp)
+- Create and manage companies and organizations
+- Assign roles and permissions to members
+- Group members into teams to manage access by project or role
+- Set company-wide policies, including SCIM provisioning and security
+  enforcement
 
-- Company: A company simplifies the management of Docker organizations and settings. Creating a company is optional and only available to Docker Business subscribers.
-  - Company owner: A company can have multiple owners. Company owners have company-wide observability and can manage company-wide settings that apply to all associated organizations. In addition, company owners have the same access as organization owners for all associated organizations.
-- Organization: An organization is a collection of teams and repositories. Docker Team and Business subscribers must have at least one organization.
-  - Organization owner: An organization can have multiple owners. Organization owners have observability into their organization and can manage its users and settings.
-- Team: A team is a group of Docker members that belong to an organization. Organization and company owners can group members into additional teams to configure repository permissions on a per-team basis. Using teams to group members is optional.
-- Member: A member is a Docker user that's a member of an organization. Organization and company owners can assign roles to members to define their permissions.
+## Company and organization hierarchy
+
+To provide centralized administration, Docker organizes companies and
+organizations into the following hierarchy and roles.
+
+![Diagram showing Docker’s administration hierarchy with Company at the top, followed by Organizations, Teams, and Members](./images/docker-admin-structure.webp)
+
+### Company
+
+A company groups multiple Docker organizations for centralized configuration. A
+company owner can view and manage every organization in the company and its
+company-wide settings, with the same access rights as an organization owner. For
+the company owner role and how it affects seats, see
+[Company roles](/manuals/admin/company/_index.md#company-roles).
+
+Companies are only available for Docker Business subscribers.
+
+### Organization
+
+An organization sits below the company and is where you group teams and
+members and assign access to repositories. Every Docker Team and Business
+subscriber has at least one organization.
+
+Organization owners hold the organization owner administrator role and manage
+organization settings, users, and access controls. Each owner occupies a
+[seat](/manuals/admin/organization/organization-faqs.md#what-is-the-difference-between-user-invitee-seat-and-member).
+
+[Upgrading to a Docker Business plan](https://www.docker.com/pricing?ref=Docs&refAction=DocsAdmin)
+grants you the company owner role so you can manage multiple organizations.
+
+### Team
+
+Teams are optional and let you group members to assign repository permissions
+collectively. Teams simplify permission management across projects
+or functions.
+
+### Member
+
+A member is any Docker user added to an organization. Organization and company
+owners can assign roles to members to define their level of access.
+
+## Next steps
+
+Learn how to manage companies and organizations in the following sections.
 
 {{< grid >}}
diff --git a/content/manuals/admin/activity-logs.md b/content/manuals/admin/activity-logs.md
new file mode 100644
index 000000000000..d4d97991d524
--- /dev/null
+++ b/content/manuals/admin/activity-logs.md
@@ -0,0 +1,158 @@
+---
+title: Activity logs
+weight: 30
+description: Learn how to access and interpret Docker activity logs for organizations and repositories.
+keywords: audit log, organization activity, Docker business logs, repository activity, track changes Docker, security logs Docker, filter logs, log Docker events
+aliases:
+- /docker-hub/audit-log/
+- /admin/organization/activity-logs/
+---
+
+{{< summary-bar feature_name="Activity logs" >}}
+
+Activity logs display a chronological list of activities that occur at organization and repository levels. The activity log provides organization owners with a record of all
+member activities.
+
+With activity logs, owners can view and track:
+
+ - What changes were made
+ - The date when a change was made
+ - Who initiated the change
+
+For example, activity logs display activities such as the date when a repository was created or deleted, the member who created the repository, the name of the repository, and when there was a change to the privacy settings.
+
+Owners can also see the activity logs for their repository if the repository is part of the organization subscribed to a Docker Business or Team subscription.
+
+## Access activity logs
+
+{{< tabs >}}
+{{< tab name="Docker Home">}}
+
+To view activity logs in Docker Home:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+organization.
+1. Select **Activity**.
+
+{{< /tab >}}
+{{< tab name="API">}}
+
+To view activity logs using the Docker Hub API, use the [Audit logs endpoints](https://docs.docker.com/reference/api/hub/latest/#tag/audit-logs).
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Filter and customize activity logs
+
+> [!IMPORTANT]
+>
+> Docker Home retains activity logs for 30 days. To retrieve
+activities beyond 30 days, you must use the
+[Docker Hub API](https://docs.docker.com/reference/api/hub/latest/#tag/audit-logs).
+
+By default, the **Activity** tab displays all recorded events within
+the last 30 days. To narrow your view, use the calendar to select a specific
+date range. The log updates to show only the activities that occurred during
+that period.
+
+You can also filter by activity type. Use the **All Activities** drop-down to
+focus on organization-level, repository-level, or billing-related events.
+In Docker Hub, when viewing a repository, the **Activities** tab only shows
+events for that repository.
+
+After selecting a category—**Organization**, **Repository**, or **Billing**—use
+the **All Actions** drop-down to refine the results even further by specific
+event type.
+
+> [!NOTE]
+>
+> Events triggered by Docker Support appear under the username **dockersupport**.
+
+## Types of activity log events
+
+Refer to the following section for a list of events and their descriptions:
+
+### Organization events
+
+| Event                                                          | Description                                   |
+|:------------------------------------------------------------------|:------------------------------------------------|
+| Team Created | Activities related to the creation of a team |
+| Team Updated | Activities related to the modification of a team |
+| Team Deleted | Activities related to the deletion of a team |
+| Team Member Added | Details of the member added to your team |
+| Team Member Removed | Details of the member removed from your team |
+| Team Member Invited | Details of the member invited to your team |
+| Organization Member Added | Details of the member added to your organization |
+| Organization Member Removed | Details about the member removed from your organization |
+| Member Role Changed | Details about the role changed for a member in your organization |
+| Organization Created | Activities related to the creation of a new organization |
+| Organization Settings Updated | Details related to the organization setting that was updated |
+| Registry Access Management enabled | Activities related to enabling Registry Access Management |
+| Registry Access Management disabled | Activities related to disabling Registry Access Management |
+| Registry Access Management registry added | Activities related to the addition of a registry |
+| Registry Access Management registry removed | Activities related to the removal of a registry |
+| Registry Access Management registry updated | Details related to the registry that was updated |
+| Single Sign-On domain added | Details of the single sign-on domain added to your organization |
+| Single Sign-On domain removed | Details of the single sign-on domain removed from your organization |
+| Single Sign-On domain verified | Details of the single sign-on domain verified for your organization |
+| Access token created | Access token created in organization |
+| Access token updated | Access token updated in organization |
+| Access token deleted | Access token deleted in organization |
+| Policy created | Details of adding a settings policy |
+| Policy updated | Details of updating a settings policy |
+| Policy deleted | Details of deleting a settings policy |
+| Policy transferred | Details of transferring a settings policy to another owner |
+| Create SSO Connection | Details of creating a new org/company SSO connection |
+| Update SSO Connection | Details of updating an existing org/company SSO connection |
+| Delete SSO Connection | Details of deleting an existing org/company SSO connection |
+| Enforce SSO | Details of toggling enforcement on an existing org/company SSO connection |
+| Enforce SCIM | Details of toggling SCIM on an existing org/company SSO connection |
+| Refresh SCIM Token | Details of a SCIM token refresh on an existing org/company SSO connection |
+| Change SSO Connection Type | Details of a connection type change on an existing org/company SSO connection |
+| Toggle JIT provisioning | Details of a JIT toggle on an existing org/company SSO connection |
+
+### Repository events
+
+> [!NOTE]
+>
+> Event descriptions that include a user action can refer to a Docker username, personal access token (PAT) or organization access token (OAT). For example, if a user pushes a tag to a repository, the event would include the description: `<user-access-token>` pushed the tag to the repository.
+
+| Event                                                          | Description                                   |
+|:------------------------------------------------------------------|:------------------------------------------------|
+| Repository Created | Activities related to the creation of a new repository |
+| Repository Deleted | Activities related to the deletion of a repository |
+| Repository Updated | Activities related to updating the description, full description, or status of a repository |
+| Privacy Changed | Details related to the privacy policies that were updated |
+| Tag Pushed | Activities related to the tags pushed |
+| Tag Deleted | Activities related to the tags deleted |
+| Categories Updated | Activities related to setting or updating categories of a repository |
+
+### Billing events
+
+| Event                                                          | Description                                   |
+|:------------------------------------------------------------------|:------------------------------------------------|
+| Plan Upgraded | Occurs when your organization’s billing plan is upgraded to a higher tier plan.|
+| Plan Downgraded | Occurs when your organization’s billing plan is downgraded to a lower tier plan. |
+| Seat Added | Occurs when a seat is added to your organization’s billing plan. |
+| Seat Removed | Occurs when a seat is removed from your organization’s billing plan. |
+| Billing Cycle Changed | Occurs when there is a change in the recurring interval that your organization is charged.|
+| Plan Downgrade Canceled | Occurs when a scheduled plan downgrade for your organization is canceled.|
+| Seat Removal Canceled | Occurs when a scheduled seat removal for an organization’s billing plan is canceled. |
+| Plan Upgrade Requested | Occurs when a user in your organization requests a plan upgrade. |
+| Plan Downgrade Requested | Occurs when a user in your organization requests a plan downgrade. |
+| Seat Addition Requested | Occurs when a user in your organization requests an increase in the number of seats. |
+| Seat Removal Requested | Occurs when a user in your organization requests a decrease in the number of seats. |
+| Billing Cycle Change Requested | Occurs when a user in your organization requests a change in the billing cycle. |
+| Plan Downgrade Cancellation Requested | Occurs when a user in your organization requests a cancellation of a scheduled plan downgrade. |
+| Seat Removal Cancellation Requested | Occurs when a user in your organization requests a cancellation of a scheduled seat removal. |
+
+### Offload events
+
+> [!NOTE]
+>
+> Event descriptions show the Docker username of the actor and details about the lease.
+
+| Event                                                          | Description                                   |
+|:------------------------------------------------------------------|:------------------------------------------------|
+| Offload Lease Start | Occurs when an Offload lease is started in your organization. |
+| Offload Lease End | Occurs when an Offload lease is ended in your organization. |
diff --git a/content/manuals/admin/company/_index.md b/content/manuals/admin/company/_index.md
index 72d5b33439b0..55398a5b3474 100644
--- a/content/manuals/admin/company/_index.md
+++ b/content/manuals/admin/company/_index.md
@@ -1,51 +1,71 @@
 ---
-title: Company administration
+title: Company overview
+linkTitle: Company
 weight: 20
 description: Learn how to manage multiple organizations using companies, including managing users, owners, and security.
-keywords: company, multiple organizations, manage companies
+keywords: company, multiple organizations, manage companies, Docker Home, Docker Business settings
 grid:
-- title: Create a company
-  description: Get started by learning how to create a company.
-  icon: apartment
-  link: /admin/company/new-company/
-- title: Manage organizations
-  description: Learn how to add and manage organizations as well as seats within your
-    company.
-  icon: store
-  link: /admin/company/organizations/
-- title: Manage users
-  description: Explore how to manage users in all organizations.
-  icon: group_add
-  link: /admin/company/users/
-- title: Manage company owners
-  description: Find out more about company owners and how to manage them.
-  icon: supervised_user_circle
-  link: /admin/company/owners/
-- title: Configure Single Sign-On
-  description: Discover how to configure SSO for your entire company.
-  icon: key
-  link: /security/for-admins/single-sign-on/
-- title: Set up SCIM
-  description: Set up SCIM to automatically provision and deprovision users in your
-    company.
-  icon: checklist
-  link: /security/for-admins/provisioning/scim/
-- title: Domain management
-  description: Add and verify your domains.
-  icon: domain_verification
-  link: /admin/company/settings/domains/
-- title: FAQs
-  description: Explore common company FAQs.
-  link: /faq/admin/company-faqs/
-  icon: help
+  - title: Create a company
+    description: Get started by learning how to create a company.
+    icon: building-office-2
+    link: /admin/company/new-company/
+  - title: Manage your company
+    description: Add organizations, manage company owners, and invite members.
+    icon: building-storefront
+    link: /admin/company/manage/
+  - title: Configure SSO and SCIM
+    description: Set up single sign-on and SCIM provisioning for your company.
+    icon: key
+    link: /enterprise/security/single-sign-on/
+  - title: Domain management
+    description: Add and verify your company's domains.
+    icon: check-badge
+    link: /enterprise/security/domain-management/
+  - title: FAQs
+    description: Explore frequently asked questions about companies.
+    link: /faq/admin/company-faqs/
+    icon: question-mark-circle
 aliases:
-- /docker-hub/creating-companies/
+  - /docker-hub/creating-companies/
 ---
 
 {{< summary-bar feature_name="Company" >}}
 
-{{% include "admin-company-overview.md" %}}
+A company provides a single point of visibility across multiple
+organizations, for centralized organization and settings management.
+Organization owners with a Docker Business subscription can create a company
+and manage it through Docker Home.
 
-Learn how to administer a company in the following sections.
+## Company structure
+
+The following diagram shows how a company relates to its associated
+organizations.
+
+![Diagram showing how companies relate to Docker organizations](/admin/images/docker-admin-structure.webp)
+
+For the full administration hierarchy, see the
+[administration overview](/manuals/admin/_index.md#company-and-organization-hierarchy).
+
+## Company roles
+
+A company includes one or more company owners. The creator of a company
+becomes both a company owner and an organization owner, and occupies a seat
+as organization owner. After creation, a company can have multiple owners,
+and each owner has visibility across the entire company. They can manage
+settings for every organization under it and have the same access rights as
+organization owners.
+
+- A company can have up to ten unique company owners.
+- Company owners don't occupy a seat unless one of the following applies:
+  - They're added as a member of an organization under the company.
+  - SSO is enabled and the company owner signs in through SSO, which
+    automatically adds them as an organization member.
+
+To add or remove company owners, see
+[Manage your company](/manuals/admin/company/manage.md#company-owners).
+
+## Next steps
+
+Learn how to create and manage a company in the following sections.
 
 {{< grid >}}
diff --git a/content/manuals/admin/company/company-faqs.md b/content/manuals/admin/company/company-faqs.md
new file mode 100644
index 000000000000..8ab054c97ce7
--- /dev/null
+++ b/content/manuals/admin/company/company-faqs.md
@@ -0,0 +1,49 @@
+---
+title: Company FAQs
+linkTitle: FAQs
+weight: 30
+description: Frequently asked questions about Docker companies, including subscriptions, seats, company owners, and permissions.
+keywords: Docker, Docker Hub, SSO FAQs, single sign-on, company, administration, company management
+tags: [FAQ]
+aliases:
+  - /docker-hub/company-faqs/
+  - /faq/admin/company-faqs/
+  - /admin/faqs/company-faqs/
+---
+
+### Some of my organizations don’t have a Docker Business subscription. Can I still use a parent company?
+
+Yes, but you can only add organizations with a Docker Business subscription
+to a company. For more details, see [Add more organizations](/manuals/admin/company/manage.md#add-more-organizations).
+
+### What happens if one of my organizations downgrades from Docker Business, but I still need access as a company owner?
+
+To access and manage a nested organization, it must have a Docker Business
+subscription. If an organization downgrades from Docker Business, its owner must
+manage it outside of the company. For more details, see
+[Add more organizations](/manuals/admin/company/manage.md#add-more-organizations).
+
+### Do company owners occupy a subscription seat?
+
+Company owners don't occupy a seat unless one of the following is true:
+
+- They are added as a member of an organization under your company
+- SSO is enabled and the company owner signs in through SSO, which
+  automatically adds them as an organization member
+
+When you first create a company, your account is both a company owner and an
+organization owner, so it occupies a seat as long as you remain an organization
+owner. To free up that seat,
+[assign another user as the organization owner](/manuals/admin/organization/manage/members.md#update-a-member-role)
+and remove yourself from the organization. You keep full administrative access
+as a company owner without using a subscription seat.
+
+### What permissions does the company owner have in the associated/nested organizations?
+
+Company owners can navigate to the **Organizations** page to view all their
+nested organizations in a single location. They can also view or edit
+organization members and change single sign-on (SSO) and System for
+Cross-domain Identity Management (SCIM) settings. Changes to company settings
+impact all users in each organization under the company.
+
+For more information, see [Roles and permissions](/manuals/enterprise/security/roles-and-permissions.md).
diff --git a/content/manuals/admin/company/manage.md b/content/manuals/admin/company/manage.md
new file mode 100644
index 000000000000..4b91db7a0e2b
--- /dev/null
+++ b/content/manuals/admin/company/manage.md
@@ -0,0 +1,121 @@
+---
+title: Manage your company
+linkTitle: Manage
+weight: 20
+description: Learn how to manage your company, including its organizations, owners, and members, using Docker Home.
+keywords: company, manage company, multiple organizations, company owners, company members, Docker Home, add organization, resend invites
+aliases:
+  - /admin/company/manage/organizations/
+  - /admin/company/manage/owners/
+  - /admin/company/manage/users/
+  - /admin/company/organizations/
+  - /admin/company/owners/
+  - /admin/company/users/
+  - /docker-hub/company-owner/
+---
+
+{{< summary-bar feature_name="Company" >}}
+
+After creating a company, you can manage multiple organizations from Docker
+Home. Company owners can use the company portal to invite users to specific
+organizations, view seat availability across organizations, and add new
+company owners.
+
+## Add more organizations
+
+Company owners can add Docker organizations with a Docker Business plan to
+their company, so long as they're also the organization owners for that
+organization. There's no limit to the number of organizations you add to a
+company.
+
+> [!IMPORTANT]
+>
+> Once you add an organization to a company, you can't remove it from the
+> company.
+
+1. Sign in to [Docker Home](https://app.docker.com) and select
+   your company.
+1. Select **Managed organizations**.
+1. Select **Add organization**, then choose an organization from the dropdown.
+
+A nested organization must keep its Docker Business subscription to stay managed
+by the company. If an organization downgrades from Docker Business, you can no
+longer manage it through the company, and its owner must manage it separately.
+
+## Company owners
+
+A company can have multiple owners who manage the company and all of its
+organizations. For details about the company owner role and how it affects
+seats, see [Company roles](/manuals/admin/company/_index.md#company-roles).
+
+### Add a company owner
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your company.
+1. Select **Company owners**, then choose **Add owner**.
+1. Specify the user's Docker ID, then finish by selecting **Add company owner**.
+
+### Remove a company owner
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your company.
+1. Select **Company owners**.
+1. Find the company owner you want to remove and select the **Actions** menu,
+   then choose **Remove as company owner**.
+
+## Company invitations
+
+You add a user to your company by inviting them to an organization within the
+company. Company owners can invite members to any organization in the company
+using a Docker ID, email address, or in bulk with a CSV file of email addresses.
+
+Members and invitations belong to individual organizations, not to the company
+itself. A pending invitation occupies a seat in the organization the user is
+invited to.
+
+### Invite members to an organization
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your company.
+1. Select **Users**, then choose **Invite**.
+1. Choose how you want to invite members:
+   - To invite individual users, select **Emails or usernames**.
+   - To invite groups of users, select **CSV upload**.
+1. Add user(s) to an organization by choosing **Select an organization**.
+
+Users receive invitations in their email with instructions to accept the
+invitation. After accepting the invitation, new members appear on the
+**Users** page. The table specifies how many organizations they're members of.
+
+### Resend invitations
+
+Company owners can resend invitations from the company-level **Users** page.
+To resend individual invitations:
+
+1. Select your company from [Docker Home](https://app.docker.com/).
+1. Select **Users**, then locate the invitee from the users table.
+1. Select the **Actions** menu, then choose **Resend**.
+   - Before resending, confirm you are resending the invitation to the correct
+     invitee.
+   - The resend invitation modal displays the date you originally invited the
+     invitee.
+1. Choose **Invite** to confirm.
+
+To bulk resend invitations:
+
+1. From the users table, use the multi-select checkboxes next to the invitees
+   you want to invite.
+1. Select **Resend invites**, then choose **Resend** to confirm.
+
+## Add seats to an organization
+
+If you have a self-serve subscription that has no pending subscription changes,
+you can add seats using Docker Home. For more information about adding seats,
+see [Manage seats](/manuals/admin/organization/manage/manage-seats.md#add-seats-to-your-subscription).
+
+If you have a sales-assisted subscription, you must contact Docker support or
+sales to add seats.
+
+## Manage teams
+
+Teams exist at the organization level, not the company level. After inviting
+members to an organization, you can add them to teams within that organization.
+For more details, see
+[Manage members on a team](/manuals/admin/organization/manage/members.md#manage-members-on-a-team).
diff --git a/content/manuals/admin/company/new-company.md b/content/manuals/admin/company/new-company.md
index af6cb560a38d..38cd05e04842 100644
--- a/content/manuals/admin/company/new-company.md
+++ b/content/manuals/admin/company/new-company.md
@@ -1,14 +1,22 @@
 ---
-title: Create a company
+title: Create new company
+linkTitle: Setup
+weight: 10
 description: Learn how to create a company to centrally manage multiple organizations.
-keywords: company, hub, organization, company owner, Admin Console, company management
+keywords: company, hub, organization, company owner, Docker Home, company management, Docker Business, create company
 aliases:
-- /docker-hub/new-company/
+  - /docker-hub/new-company/
 ---
 
 {{< summary-bar feature_name="Company" >}}
 
-You can create a new company in the Docker Admin Console. Before you begin, you must:
+Learn how to create a new company in Docker Home, a centralized
+dashboard for managing organizations.
+
+## Prerequisites
+
+Before you begin, you must:
+
 - Be the owner of the organization you want to add to your company
 - Have a Docker Business subscription
 
@@ -16,26 +24,30 @@ You can create a new company in the Docker Admin Console. Before you begin, you
 
 To create a new company:
 
-1. Sign in to the [Admin Console](https://app.docker.com/admin).
-2. Select your organization you want to add to your company from the **Choose profile** page.
-3. Under **Organization settings**, select **Company management**.
-4. Select **Create a company**.
-5. Enter a unique name for your company, then select **Continue**.
+1. Sign in to [Docker Home](https://app.docker.com/) and select the
+   organization you want to add to your company.
+1. Select **Organization settings**.
+1. Select **Create a company**.
+1. Enter a unique name for your company, then select **Continue**.
 
-    > [!TIP]
-    >
-    > The name for your company can't be the same as an existing user, organization, or company namespace.
+   > [!TIP]
+   >
+   > The name for your company can't be the same as an existing user,
+   > organization, or company namespace.
 
-6. Review the company migration details and then select **Create company**.
+1. Review the migration details and then select **Create company**.
 
-For more information on how you can add organizations to your company, see [Add organizations to a company](./organizations.md#add-organizations-to-a-company).
+When you create the company, the organization you selected is automatically
+migrated to the new company.
 
+For more information on how you can add more organizations to your company,
+see [Add more organizations](./manage.md#add-more-organizations).
 
 ## Next steps
 
-- [Manage organizations](./organizations.md)
-- [Manage company users](./users.md)
-- [Manage company owners](./owners.md)
+- [Add organizations](./manage.md#add-more-organizations)
+- [Invite company members](./manage.md#company-invitations)
+- [Manage company owners](./manage.md#company-owners)
 
 ## More resources
 
diff --git a/content/manuals/admin/company/organizations.md b/content/manuals/admin/company/organizations.md
deleted file mode 100644
index aa1907682bd7..000000000000
--- a/content/manuals/admin/company/organizations.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-description: Learn how to manage organizations in a company.
-keywords: company, multiple organizations, manage organizations
-title: Manage company organizations
----
-
-{{< summary-bar feature_name="Company" >}}
-
-You can manage the organizations in a company in the Docker Admin Console.
-
-## View all organizations
-
-1. Sign in to the [Admin Console](https://admin.docker.com).
-2. Select your company on the **Choose profile** page.
-3. Under **Organizations**, select **Overview**.
-
-The organization overview page displays all organizations under your company.
-
-## Add seats to an organization
-
-When you have a [self-serve](../../subscription/details.md#self-serve) subscription that has no pending subscription changes, you can add seats using the following steps. If you have a sales-assisted subscription, you can contact Docker support or sales to add seats.
-
-For more information about adding seats, see [Manage seats](/manuals/subscription/manage-seats.md#add-seats).
-
-## Add organizations to a company
-
-You must be a company owner to add an organization to a company. You must also be an organization owner of the organization you want to add. There is no limit to the number of organizations you can have under a company layer. All organizations must have a Business subscription.
-
-> [!IMPORTANT]
->
-> Once you add an organization to a company, you can't remove it from the company.
-
-1. Sign in to the [Admin Console](https://admin.docker.com).
-2. Select your company on the **Choose profile** page.
-3. Select **Organizations**, then **Overview**.
-4. Select **Add organization**.
-5. Choose the organization you want to add from the drop-down menu.
-6. Select **Add organization** to confirm.
-
-## Manage an organization
-
-1. Sign in to the [Admin Console](https://admin.docker.com).
-2. Select your company on the **Choose profile** page.
-3. Select the organization that you want to manage.
-
-For more details about managing an organization, see [Organization administration](../organization/_index.md).
-
-## More resources
-
-- [Video: Managing a company and nested organizations](https://youtu.be/XZ5_i6qiKho?feature=shared&t=229)
-- [Video: Adding nested organizations to a company](https://youtu.be/XZ5_i6qiKho?feature=shared&t=454)
diff --git a/content/manuals/admin/company/owners.md b/content/manuals/admin/company/owners.md
deleted file mode 100644
index 6ce17576fb19..000000000000
--- a/content/manuals/admin/company/owners.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-description: Learn how to add and remove company owners.
-keywords: company, owners
-title: Manage company owners
-aliases:
-- /docker-hub/company-owner/
----
-
-{{< summary-bar feature_name="Company" >}}
-
-A company can have multiple owners. Company owners have company-wide
-observability and can manage company-wide settings that apply to all associated
-organizations. In addition, company owners have the same access as organization
-owners for all associated organizations. Unlike organization owners, company
-owners don't need to be member of an organization.
-
-> [!NOTE]
->
-> Company owners do not occupy a seat unless one of the following is true:
->
->   - They are added as a member of an organization under your company
->   - SSO is enabled
-
-## Add a company owner
-
-1. Sign in to the [Admin Console](https://admin.docker.com).
-2. Select your company on the **Choose profile** page.
-3. Select **Company owners**.
-4. Select **Add owner**.
-5. Specify the user's Docker ID to search for the user.
-6. After you find the user, select **Add company owner**.
-
-## Remove a company owner
-
-1. Sign in to the [Admin Console](https://admin.docker.com).
-2. Select your company on the **Choose profile** page.
-3. Select **Company owners**.
-4. Select the **Action** icon in the row of the company owner that your want to remove.
-5. Select **Remove as company owner**.
diff --git a/content/manuals/admin/company/users.md b/content/manuals/admin/company/users.md
deleted file mode 100644
index 653bc71375de..000000000000
--- a/content/manuals/admin/company/users.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-description: Learn how to manage company users in the Docker Admin Console.
-keywords: company, company users, users, admin, Admin Console
-title: Manage company users
----
-
-{{< summary-bar feature_name="Company" >}}
-
-You can manage users at the company-level in the Docker Admin Console.
-
-{{% admin-users product="admin" layer="company" %}}
-
-## Manage members on a team
-
-Use Docker Hub to add a member to a team or remove a member from a team. For more details, see [Manage members in Docker Hub](../organization/members.md#manage-members-on-a-team).
diff --git a/content/manuals/admin/faqs/_index.md b/content/manuals/admin/faqs/_index.md
deleted file mode 100644
index 5bae20c90b97..000000000000
--- a/content/manuals/admin/faqs/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-build:
-  render: never
-title: Account and admin FAQ
-weight: 30
----
diff --git a/content/manuals/admin/faqs/company-faqs.md b/content/manuals/admin/faqs/company-faqs.md
deleted file mode 100644
index 33e0fb425e2f..000000000000
--- a/content/manuals/admin/faqs/company-faqs.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: FAQs on companies
-linkTitle: Company
-weight: 30
-description: Company FAQs
-keywords: Docker, Docker Hub, SSO FAQs, single sign-on, company, administration, company management
-tags: [FAQ]
-aliases:
-- /docker-hub/company-faqs/
-- /faq/admin/company-faqs/
----
-
-### Are existing subscriptions affected when you create a company and add organizations to it?
-
-You can manage subscriptions and related billing details at the organization level.
-
-### Some of my organizations don’t have a Docker Business subscription. Can I still use a parent company?
-
-Yes, but you can only add organizations with a Docker Business subscription to a company.
-
-### What happens if one of my organizations downgrades from Docker Business, but I still need access as a company owner?
-
-To access and manage child organizations, the organization must have a Docker Business subscription. If the organization isn’t included in this subscription, the owner of the organization must manage the organization outside of the company.
-
-### Does my organization need to prepare for downtime during the migration process?
-
-No, you can continue with business as usual.
-
-### How many company owners can I add?
-
-You can add a maximum of 10 company owners to a single company account.
-
-### Do company owners occupy a subscription seat?
-
-Company owners do not occupy a seat unless one of the following is true:
-
-- They are added as a member of an organization under your company
-- SSO is enabled
-
-Although company owners have the same access as organization owners across all
-organizations in the company, it's not necessary to add them to any
-organization. Doing so will cause them to occupy a seat.
-
-When you first create a company, your account is both a company owner and an
-organization owner. In that case, your account will occupy a seat as long as
-you remain an organization owner.
-
-To avoid occupying a seat, [assign another user as the organization owner](/manuals/admin/organization/members.md#update-a-member-role) and remove yourself from the organization.
-You'll retain full administrative access as a company owner without using a
-subscription seat.
-
-### What permissions does the company owner have in the associated/nested organizations?
-
-Company owners can navigate to the **Organizations** page to view all their nested organizations in a single location. They can also view or edit organization members and change single sign-on (SSO) and System for Cross-domain Identity Management (SCIM) settings. Changes to company settings impact all users in each organization under the company. For more information, see [Roles and permissions](../../security/for-admins/roles-and-permissions.md).
-
-### What features are supported at the company level?
-
-You can manage domain verification, SSO, and SCIM at the company level. The following features aren't supported at the company level, but you can manage them at the organization level:
-
-- Image Access Management
-- Registry Access Management
-- User management
-- Billing
-
-To view and manage users across all the organizations under your company, you can [manage users at the company level](../../admin/company/users.md) when you use the [Admin Console](https://admin.docker.com).
-
-Domain audit isn't supported for companies or organizations within a company.
-
-### What's required to create a company name?
-
-A company name must be unique to that of its child organization. If a child organization requires the same name as a company, you should modify it slightly. For example, **Docker Inc** (parent company), **Docker** (child organization).
-
-### How does a company owner add an organization to the company?
-
-You can add organizations to a company in the Admin Console. For more information, see [Add organizations to a company](../../admin/company/organizations.md#add-organizations-to-a-company.md).
-
-### How does a company owner manage SSO/SCIM settings for a company?
-
-See your [SCIM](scim.md) and [SSO](../../security/for-admins/single-sign-on/configure/_index.md) settings.
-
-### How does a company owner enable group mapping in an IdP?
-
-See [SCIM](scim.md) and [group mapping](../../security/for-admins/provisioning/group-mapping.md) for more information.
-
-### What's the definition of a company versus an organization?
-
-A company is a collection of organizations that are managed together. An organization is a collection of repositories and teams that are managed together.
diff --git a/content/manuals/admin/faqs/general-faqs.md b/content/manuals/admin/faqs/general-faqs.md
deleted file mode 100644
index 2bd3216269c9..000000000000
--- a/content/manuals/admin/faqs/general-faqs.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: General FAQs for Docker accounts
-linkTitle: General
-weight: 10
-description: Frequently asked Docker account and administration questions
-keywords: onboarding, docker, teams, orgs, user accounts, organization accounts
-tags: [FAQ]
-aliases:
-- /docker-hub/general-faqs/
-- /docker-hub/onboarding-faqs/
-- /faq/admin/general-faqs/
----
-
-### What is a Docker ID?
-
-A Docker ID is a username for your Docker account that lets you access Docker products. To create a Docker ID, you need an email address or you can sign up with your social or GitHub accounts. Your Docker ID must be between 4 and 30 characters long, and can only contain numbers and lowercase letters. You can't use any special characters or spaces.
-
-For more information, see [Docker ID](/accounts/create-account/). If your administrator enforces [single sign-on (SSO)](../../security/for-admins/single-sign-on/_index.md), this provisions a Docker ID for new users.
-
-Developers may have multiple Docker IDs in order to separate their Docker IDs associated with an organization with a Docker Business or Team subscription, and their personal use Docker IDs.
-
-### Can I change my Docker ID?
-
-No. You can't change your Docker ID once it's created. If you need a different Docker ID, you must create a new Docker account with a new Docker ID.
-
-Additionally, you can't reuse a Docker ID in the future if you deactivate your account.
-
-### What if my Docker ID is taken?
-
-All Docker IDs are first-come, first-served except for companies that have a US Trademark on a username. If you have a trademark for your namespace, [Docker Support](https://hub.docker.com/support/contact/) can retrieve the Docker ID for you.
-
-### What’s an organization?
-
-An organization in Docker is a collection of teams and repositories that are managed together. Docker users become members of an organization once they're associated with that organization by an organization owner. An [organization owner](#who-is-an-organization-owner) is a user with administrative access to the organization. For more information on creating organizations, see [Create your organization](orgs.md).
-
-### What's an organization name or namespace?
-
-The organization name, sometimes referred to as the organization namespace or the organization ID, is the unique identifier of a Docker organization. The organization name can't be the same as an existing Docker ID.
-
-### What are roles?
-
-A role is a collection of permissions granted to members. Roles define access to perform actions in Docker Hub like creating repositories, managing tags, or viewing teams. See [Roles and permissions](roles-and-permissions.md).
-
-### What’s a team?
-
-A team is a group of Docker users that belong to an organization. An organization can have multiple teams. An organization owner can then create new teams and add members to an existing team using Docker IDs or email address and by selecting a team the user should be part of. See [Create and manage a team](manage-a-team.md).
-
-### What's a company?
-
-A company is a management layer that centralizes administration of multiple organizations. Administrators can add organizations with a Docker Business subscription to a company and configure settings for all organizations under the company. See [Set up your company](/admin/company/).
-
-### Who is an organization owner?
-
-An organization owner is an administrator who has permissions to manage
-repositories, add members, and manage member roles. They have full access to
-private repositories, all teams, billing information, and organization settings.
-An organization owner can also specify [repository permissions](manage-a-team.md#configure-repository-permissions-for-a-team) for each team in the
-organization. Only an organization owner can enable SSO for the organization.
-When SSO is enabled for your organization, the organization owner can also
-manage users.
-
-Docker can auto-provision Docker IDs for new end-users or users who'd like to
-have a separate Docker ID for company use through SSO enforcement.
-
-The organization owner can also add additional owners to help them manage users, teams, and repositories in the organization.
-
-### Can I configure multiple SSO identity providers (IdPs) to authenticate users to a single org?
-
-Docker SSO allows only one IdP configuration per organization. For more
-information, see [Configure SSO](../../security/for-admins/single-sign-on/configure/_index.md) and [SSO FAQs](../../security/faqs/single-sign-on/faqs.md).
-
-### What is a service account?
-
-> [!IMPORTANT]
->
-> As of December 10, 2024, service accounts are no longer available. Existing Service Account agreements will be honored until their current term expires, but new purchases or renewals of service accounts no longer available and customers must renew under a new subscription plan. It is recommended to transition to Organization Access Tokens (OATs), which can provide similar functionality. For more information, see [Organization access tokens (Beta)](/manuals/security/for-admins/access-tokens.md).
-
-A [service account](../../docker-hub/service-accounts.md) is a Docker ID used for automated management of container images or containerized applications. Service accounts are typically used in automated workflows, and don't share Docker IDs with the members in the Team or Business plan. Common use cases for service accounts include mirroring content on Docker Hub, or tying in image pulls from your CI/CD process.
-
-### Can I delete or deactivate a Docker account for another user?
-
-Only someone with access to the Docker account can deactivate the account. For more details, see [Deactivating an account](../../admin/organization/deactivate-account.md).
-
-If the user is a member of your organization, you can remove the user from your organization. For more details, see [Remove a member or invitee](../../admin/organization/members.md#remove-a-member-from-a-team).
-
-### How do I manage settings for a user account?
-
-You can manage your account settings anytime when you sign in to your [Docker account](https://app.docker.com/login). In Docker Home, select your avatar in the top-right navigation, then select **My Account**. You can also access this menu from any Docker web applications when you're signed in to your account. See [Manage your Docker account](/accounts/manage-account). If your account is associated with an organization that uses SSO, you may have limited access to the settings that you can control.
-
-### How do I add an avatar to my Docker account?
-
-To add an avatar to your Docker account, create a [Gravatar account](https://gravatar.com/) and create your avatar. Next, add your Gravatar email to your Docker account settings.
-
-Note, that it may take some time for your avatar to update in Docker.
\ No newline at end of file
diff --git a/content/manuals/admin/faqs/organization-faqs.md b/content/manuals/admin/faqs/organization-faqs.md
deleted file mode 100644
index 0f6261fcb6bf..000000000000
--- a/content/manuals/admin/faqs/organization-faqs.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-description: Organization FAQs
-linkTitle: Organization
-weight: 20
-keywords: Docker, Docker Hub, SSO FAQs, single sign-on, organizations, administration, Admin Console, members, organization management, manage orgs
-title: FAQs on organizations
-tags: [FAQ]
-aliases:
-- /docker-hub/organization-faqs/
-- /faq/admin/organization-faqs/
----
-
-### What if the Docker ID I want for my organization or company is taken?
-
-All Docker IDs are first-come, first-served except for companies that have a U.S. Trademark on a username. If you have a trademark for your namespace, [Docker Support](https://hub.docker.com/support/contact/) can retrieve the Docker ID for you.
-
-### How do I add an organization owner?
-
-An existing owner can add additional team members as organization owners. You can [invite a member](../../admin/organization/members.md#invite-members) and assign them the owner role in Docker Hub or the Docker Admin Console.
-
-### How do I know how many active users are part of my organization?
-
-If your organization uses a Software Asset Management tool, you can use it to find out how many users have Docker Desktop installed. If your organization doesn't use this software, you can run an internal survey to find out who is using Docker Desktop. See [Identify your Docker users and their Docker accounts](../../admin/organization/onboard.md#step-1-identify-your-docker-users-and-their-docker-accounts). With a Docker Business subscription, you can manage members in your identity provider and automatically provision them to your Docker organization with [SSO](../../security/for-admins/single-sign-on/_index.md) or [SCIM](../../security/for-admins/provisioning/scim.md).
-
-### Do users first need to authenticate with Docker before an owner can add them to an organization?
-
-No. Organization owners can invite users with their email addresses, and also assign them to a team during the invite process.
-
-### Can I force my organization's members to authenticate before using Docker Desktop and are there any benefits?
-
-Yes. You can [enforce sign-in](../../security/for-admins/enforce-sign-in/_index.md). Some benefits of enforcing sign-in are:
-
-- Administrators can enforce features like [Image Access Management](/manuals/security/for-admins/hardened-desktop/image-access-management.md) and [Registry Access Management](../../security/for-admins/hardened-desktop/registry-access-management.md).
- - Administrators can ensure compliance by blocking Docker Desktop usage for users who don't sign in as members of the organization.
-
-### If a user has their personal email associated with a user account in Docker Hub, do they have to convert to using the organization's domain before they can be invited to join an organization?
-
-Yes. When SSO is enabled for your organization, each user must sign in with the company’s domain. However, the user can retain their personal credentials and create a new Docker ID associated with their organization's domain.
-
-### Can I convert my personal user account (Docker ID) to an organization account?
-
-Yes. You can convert your user account to an organization account. Once you
-convert a user account into an organization, it's not possible to
-revert it to a personal user account. For prerequisites and instructions, see
-[Convert an account into an organization](convert-account.md).
-
-### Our users create Docker Hub accounts through self-service. How do we know when the total number of users for the requested licenses has been met? Is it possible to add more members to the organization than the total number of licenses?
-
-There isn't any automatic notification when the total number of users for the requested licenses has been met. However, if the number of team members exceed the number of licenses, you will receive an error informing you to contact the administrator due to lack of seats. You can [add seats](../../subscription/manage-seats.md) if needed.
-
-### How can I merge organization accounts?
-
-You can downgrade a secondary organization and transition your users and data to a primary organization. See [Merge organizations](../organization/orgs.md#merge-organizations).
-
-### Do organization invitees take up seats?
-
-Yes. A user invited to an organization will take up one of the provisioned
-seats, even if that user hasn’t accepted their invitation yet. Organization
-owners can manage the list of invitees through the **Invitees** tab on the organization settings page in Docker Hub, or in the **Members** page in Admin Console.
-
-### Do organization owners take a seat?
-
-Yes. Organization owners will take up a seat.
-
-### What is the difference between user, invitee, seat, and member?
-
-User refers to a Docker user with a Docker ID.
-
-An invitee is a user that an administrator has invited to join an organization but has not yet accepted their invitation.
-
-Seats are the number of planned members within an organization.
-
-Member may refer to a user who has received and accepted an invitation to join an organization. Member can also refer to a member of a team within an organization.
-
-### If there are two organizations and a user belongs to both organizations, do they take up two seats?
-
-Yes. In a scenario where a user belongs to two organizations, they take up one seat in each organization.
-
-### Is it possible to set permissions for repositories within an organization?
-
-Yes. You can configure repository access on a per-team basis. For example, you
-can specify that all teams within an organization have **Read and Write** access
-to repositories A and B, whereas only specific teams have **Admin** access. Org
-owners have full administrative access to all repositories within the
-organization. See [Configure repository permissions for a team](manage-a-team.md#configure-repository-permissions-for-a-team). Administrators can also assign members the editor role, which grants administrative permissions for repositories across the namespace of the organization. See [Roles and permissions](../../security/for-admins/roles-and-permissions.md).
-
-### Does my organization need to use Docker's registry?
-
-A registry is a hosted service containing repositories of images that responds to the Registry API. Docker Hub is Docker's primary registry, but you can use Docker with other container image registries. You can access the default registry by browsing to [Docker Hub](https://hub.docker.com) or using the `docker search` command.
diff --git a/content/manuals/admin/insights.md b/content/manuals/admin/insights.md
new file mode 100644
index 000000000000..1b498cc8bbbc
--- /dev/null
+++ b/content/manuals/admin/insights.md
@@ -0,0 +1,210 @@
+---
+title: Insights
+weight: 40
+description: Gain insights about your organization's users and their Docker usage.
+keywords: organization, insights, Docker Desktop analytics, user usage statistics, Docker Business, track Docker activity
+---
+
+{{< summary-bar feature_name="Insights" >}}
+
+Insights helps administrators visualize and understand how Docker is used within
+their organizations. With Insights, administrators can ensure their teams are
+fully equipped to utilize Docker to its fullest potential, leading to improved
+productivity and efficiency across the organization.
+
+Key benefits include:
+
+- Uniform working environment: Establish and maintain standardized
+  configurations across teams.
+- Best practices: Promote and enforce usage guidelines to ensure optimal
+  performance.
+- Increased visibility: Monitor and drive adoption of organizational
+  configurations and policies.
+- Optimized license use: Ensure that developers have access to advanced
+  features provided by a Docker subscription.
+
+## Prerequisites
+
+To use Insights, you must meet the following requirements:
+
+- [Docker Business subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsAdminInsights)
+- Administrators must [enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md)
+  for users
+- Your Account Executive must turn on Insights for your organization
+
+## View Insights for organization users
+
+To access Insights, contact your Account Executive to turn on the feature. Once enabled, access Insights using the
+following steps:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and choose
+   your organization.
+2. Select **Insights**, then select a time period for the data you want to view.
+
+> [!NOTE]
+>
+> Insights data is not real-time and is updated daily. At the top-right of the
+> Insights page, view the **Last updated** date to understand when the data was
+> last updated.
+
+### Docker Desktop users
+
+Track active Docker Desktop users in your domain, differentiated by license
+status. This chart helps you understand the engagement levels within your
+organization, providing insights into how many users are actively using Docker
+Desktop. Note that users who opt out of analytics aren't included in the active
+counts.
+
+The chart contains the following data:
+
+| Data                         | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
+| :--------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Active user                  | The number of users who have actively used Docker Desktop and either signed in with a Docker account that has a license in your organization or signed in to a Docker account with an email address from a domain associated with your organization. <br><br>Users who don’t sign in to an account associated with your organization are not represented in the data. To ensure users sign in with an account associated with your organization, you can [enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md). |
+| Total organization members   | The number of users who have used Docker Desktop, regardless of their Insights activity.                                                                                                                                                                                                                                                                                                                                                                                                                                            |
+| Users opted out of analytics | The number of users who are members of your organization that have opted out of sending analytics. <br><br>When users opt out of sending analytics, you won't see any of their data in Insights. To ensure that the data includes all users, you can use [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md) to set `analyticsEnabled` for all your users.                                                                                                                           |
+| Active users (graph)         | The view over time for total active users.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
+
+### Builds
+
+Monitor development efficiency and the time your team invests in builds with
+this chart. It provides a clear view of the build activity, helping you identify
+patterns, optimize build times, and enhance overall development productivity.
+
+The chart contains the following data:
+
+| Data                   | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Average build per user | The average number of builds per active user. A build includes any time a user runs one of the following commands: <ul><li>`docker build`</li><li>`docker buildx b`</li><li>`docker buildx bake`</li><li>`docker buildx build`</li><li>`docker buildx f`</li><li>`docker builder b`</li><li>`docker builder bake`</li><li>`docker builder build`</li><li>`docker builder f`</li><li>`docker compose build`</li><li>`docker compose up --build`</li><li>`docker image build`</li></ul> |
+| Average build time     | The average build time per build.                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| Build success rate     | The percentage of builds that were successful out of the total number of builds. A successful build includes any build that exits normally.                                                                                                                                                                                                                                                                                                                                           |
+| Total builds (graph)   | The total number of builds separated into successful builds and failed builds. A successful build includes any build that exits normally. A failed build includes any build that exits abnormally.                                                                                                                                                                                                                                                                                    |
+
+### Containers
+
+View the total and average number of containers run by users with this chart. It
+lets you gauge container usage across your organization, helping you understand
+usage trends and manage resources effectively.
+
+The chart contains the following data:
+
+| Data                                   | Description                                                                                                                                                                |
+| :------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Total containers run                   | The total number of containers run by active users. Containers run include those run using the Docker Desktop graphical user interface, `docker run`, or `docker compose`. |
+| Average number of containers run       | The average number of containers run per active user.                                                                                                                      |
+| Containers run by active users (graph) | The number of containers run over time by active users.                                                                                                                    |
+
+### Docker Desktop usage
+
+Explore Docker Desktop usage patterns with this chart to optimize your team's
+workflows and ensure compatibility. It provides valuable insights into how
+Docker Desktop is being utilized, enabling you to streamline processes and
+improve efficiency.
+
+The chart contains the following data:
+
+| Data                              | Description                                                                                                                                                                                                                                                                       |
+| :-------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Most used version                 | The most used version of Docker Desktop by users in your organization.                                                                                                                                                                                                            |
+| Most used OS                      | The most used operating system by users.                                                                                                                                                                                                                                          |
+| Versions by active users (graph)  | The number of active users using each version of Docker Desktop. <br><br>To learn more about each version and release dates, see the [Docker Desktop release notes](/manuals/desktop/release-notes.md).                                                                           |
+| Interface by active users (graph) | The number of active users grouped into the type of interface they used to interact with Docker Desktop. <br><br>A CLI user is any active user who has run a `docker` command. A GUI user is any active user who has interacted with the Docker Desktop graphical user interface. |
+
+### Docker Hub images
+
+Analyze image distribution activity with this chart and view the most utilized
+Docker Hub images within your domain. This information helps you manage image
+usage, ensuring that the most critical resources are readily available and
+efficiently used.
+
+> [!NOTE]
+>
+> Data for images is only for Docker Hub. Data for third-party
+> registries and mirrors aren't included.
+
+The chart contains the following data:
+
+| Data                 | Description                                                                                                     |
+| :------------------- | :-------------------------------------------------------------------------------------------------------------- |
+| Total pulled images  | The total number of images pulled by users from Docker Hub.                                                     |
+| Total pushed images  | The total number of images pushed by users to Docker Hub.                                                       |
+| Top 10 pulled images | A list of the top 10 images pulled by users from Docker Hub and the number of times each image has been pulled. |
+
+### Extensions
+
+Monitor extension installation activity with this chart. It provides visibility
+into the Docker Desktop extensions your teams are using, letting you track
+adoption and identify popular tools that enhance productivity.
+
+The chart contains the following data:
+
+| Data                                           | Description                                                                                                                                      |
+| :--------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------- |
+| Percentage of org with extensions installed    | The percentage of users in your organization with at least one Docker Desktop extension installed.                                               |
+| Top 5 extensions installed in the organization | A list of the top 5 Docker Desktop extensions installed by users in your organization and the number of users who have installed each extension. |
+
+## Export Docker Desktop user data
+
+You can export Docker Desktop user data as a CSV file:
+
+1. Open [Docker Home](https://app.docker.com) and select your organization from the top-left account drop-down.
+1. Select **Docker Desktop**, then **Desktop insights**.
+1. Choose a timeframe for your insights data: **1 Week**, **1 Month**, or
+   **3 Months**.
+1. Select **Export** and choose **Docker Desktop users** from the drop-down.
+
+Your export will automatically download. Open the file to view
+the export data.
+
+### Understanding export data
+
+A Docker Desktop user export file contains the following data points:
+
+- Name: User's name
+- Username: User's Docker ID
+- Email: User's email address associated with their Docker ID
+- Type: User type
+- Role: User [role](/manuals/enterprise/security/roles-and-permissions.md)
+- Teams: Team(s) within your organization the user is a
+  member of
+- Date Joined: The date the user joined your organization
+- Last Logged-In Date: The last date the user logged into Docker using
+  their web browser (this includes Docker Hub and Docker Home)
+- Docker Desktop Version: The version of Docker Desktop the user has
+  installed
+- Last Seen Date: The last date the user used the Docker Desktop application
+- Opted Out Analytics: Whether the user has opted out of the
+  [Send usage statistics](/manuals/enterprise/security/hardened-desktop/settings-management/settings-reference.md#send-usage-statistics) setting in Docker Desktop
+
+## Troubleshoot Insights
+
+If you’re experiencing issues with data in Insights, consider the following
+solutions to resolve common problems:
+
+- Update users to the latest version of Docker Desktop.
+
+  Data is not shown for users using versions 4.16 or lower of Docker Desktop.
+  In addition, older versions may not provide all data. Ensure all users have
+  installed the latest version of Docker Desktop.
+
+- Turn on **Send usage statistics** in Docker Desktop for all your users.
+
+  If users have opted out of sending usage statistics for Docker Desktop, then
+  their usage data will not be a part of Insights. To manage the setting at
+  scale for all your users, you can use [Settings
+  Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md) and turn on the
+  `analyticsEnabled` setting.
+
+- Ensure users use Docker Desktop and aren't using the standalone
+  version of Docker Engine.
+
+  Only Docker Desktop can provide data for Insights. If a user installs Docker
+  Engine outside of Docker Desktop, Docker Engine won't provide
+  data for that user.
+
+- Make sure users sign in to an account associated with your
+  organization.
+
+  Users who don’t sign in to an account associated with your organization are
+  not represented in the data. To ensure users sign in with an account
+  associated with your organization, you can [enforce
+  sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md).
diff --git a/content/manuals/admin/organization/_index.md b/content/manuals/admin/organization/_index.md
index 0cbef4d6d0bb..438bf56e5a69 100644
--- a/content/manuals/admin/organization/_index.md
+++ b/content/manuals/admin/organization/_index.md
@@ -1,54 +1,76 @@
 ---
-title: Organization administration overview
-linkTitle: Organization administration
+title: Docker organization overview
+linkTitle: Organization
 weight: 10
-description: Learn about managing organizations in Docker including how they relate to teams, how to onboard, and more
-keywords: organizations, admin, overview
+description: >
+  Learn how Docker organization accounts relate to individual accounts, and how
+  to manage teams, members, permissions, and settings.
+keywords: organizations, admin, overview, manage teams, roles, members,
+  permissions, organization settings, organization account, individual account,
+  Docker ID, account types, owners, teams
 grid:
-- title: Onboard your organization
-  description: Learn how to onboard and secure your organization.
-  icon: explore
-  link: /admin/organization/onboard
-- title: Manage members
-  description: Explore how to manage members.
-  icon: group_add
-  link: /admin/organization/members/
-- title: Activity logs
-  description: Learn how to audit the activities of your members.
-  icon: text_snippet
-  link: /admin/organization/activity-logs/
-- title: Image Access Management
-  description: Control which types of images your developers can pull.
-  icon: photo_library
-  link: /admin/organization/image-access/
-- title: Registry Access Management
-  description: Define which registries your developers can access.
-  icon: home_storage
-  link: /admin/organization/registry-access/
-- title: Organization settings
-  description: Configure information for your organization and manage settings.
-  icon: settings
-  link: /admin/organization/general-settings/
-- title: SSO and SCIM
-  description: 'Set up [Single Sign-On](/security/for-admins/single-sign-on/)
-    and [SCIM](/security/for-admins/provisioning/scim/) for your organization.
-
-    '
-  icon: key
-- title: Domain management
-  description: Add, verify, and audit your domains.
-  link: /admin/organization/security-settings/domains/
-  icon: domain_verification
-- title: FAQs
-  description: Explore common organization FAQs.
-  link: /faq/admin/organization-faqs/
-  icon: help
+  - title: Onboard your organization
+    description: Learn how to onboard and secure your organization.
+    icon: magnifying-glass-plus
+    link: /admin/organization/setup/onboard
+  - title: Manage members
+    description: Learn how to manage members.
+    icon: user-plus
+    link: /admin/organization/manage/members/
+  - title: Activity logs
+    description: Learn how to audit the activities of your members.
+    icon: document-text
+    link: /admin/activity-logs/
+  - title: Security
+    description:
+      Start here to manage security and access for your organization, including
+      single sign-on, provisioning, and image and registry access management.
+    icon: shield-check
+    link: /enterprise/security/
 ---
 
-{{% include "admin-org-overview.md" %}}
+A Docker organization is a collection of teams and repositories under
+centralized management. Organization administrators group members and
+assign repository access at scale.
 
-To create an organization, see [Create your organization](../organization/orgs.md).
+## Organization structure
 
-Learn how to administer an organization in the following sections.
+The following diagram shows how organizations relate to teams and members.
+
+![Diagram showing how teams and members relate within a Docker
+organization](/admin/images/org-structure.webp)
+
+For how organizations fit into the broader company hierarchy, see
+[Administration
+overview](/manuals/admin/_index.md#company-and-organization-hierarchy).
+
+## Individual and organization accounts
+
+Docker has two primary account types:
+
+- Individual accounts that are identified by a Docker ID.
+- Organization accounts that are shared workspaces for teams and
+  repositories.
+
+Every organization is created and administered by one or more individual
+accounts. You always sign in with your individual account, then work in the
+organizations you own or belong to. Organization owners and members are
+individual accounts that hold a role in that organization. For individual
+accounts, see [Accounts](/manuals/accounts/_index.md).
+
+## Organization roles
+
+An organization includes owners, members, and optional teams. Organization
+owners have full administrator access to manage members, roles, and teams. A
+team is an optional grouping of members that share the same repository
+permissions.
+
+For details about each role and its permissions, see
+[Roles and
+permissions](/manuals/enterprise/security/roles-and-permissions/_index.md).
+
+## Next steps
+
+Learn how to create and manage your organization in the following sections.
 
 {{< grid >}}
diff --git a/content/manuals/admin/organization/activity-logs.md b/content/manuals/admin/organization/activity-logs.md
deleted file mode 100644
index 18c9b5a14085..000000000000
--- a/content/manuals/admin/organization/activity-logs.md
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: Activity logs
-weight: 50
-description: Learn about activity logs.
-keywords: team, organization, activity, log, audit, activities
-aliases:
-- /docker-hub/audit-log/
----
-
-{{< summary-bar feature_name="Activity logs" >}}
-
-Activity logs display a chronological list of activities that occur at organization and repository levels. It provides a report to owners on all their member activities.
-
-With activity logs, owners can view and track:
- - What changes were made
- - The date when a change was made
- - Who initiated the change
-
-For example, activity logs display activities such as the date when a repository was created or deleted, the member who created the repository, the name of the repository, and when there was a change to the privacy settings.
-
-Owners can also see the activity logs for their repository if the repository is part of the organization subscribed to a Docker Business or Team plan.
-
-## Manage activity logs
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-{{% admin-org-audit-log product="admin" %}}
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-{{% admin-org-audit-log product="hub" %}}
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Event definitions
-
-Refer to the following section for a list of events and their descriptions:
-
-### Organization events
-
-| Event                                                          | Description                                   |
-|:------------------------------------------------------------------|:------------------------------------------------|
-| Team Created | Activities related to the creation of a team |
-| Team Updated | Activities related to the modification of a team |
-| Team Deleted | Activities related to the deletion of a team |
-| Team Member Added | Details of the member added to your team |
-| Team Member Removed | Details of the member removed from your team |
-| Team Member Invited | Details of the member invited to your team |
-| Organization Member Added | Details of the member added to your organization |
-| Organization Member Removed | Details about the member removed from your organization |
-| Member Role Changed | Details about the role changed for a member in your organization |
-| Organization Created | Activities related to the creation of a new organization |
-| Organization Settings Updated | Details related to the organization setting that was updated |
-| Registry Access Management enabled | Activities related to enabling Registry Access Management |
-| Registry Access Management disabled | Activities related to disabling Registry Access Management |
-| Registry Access Management registry added | Activities related to the addition of a registry |
-| Registry Access Management registry removed | Activities related to the removal of a registry |
-| Registry Access Management registry updated | Details related to the registry that was updated |
-| Single Sign-On domain added | Details of the single sign-on domain added to your organization |
-| Single Sign-On domain removed | Details of the single sign-on domain removed from your organization |
-| Single Sign-On domain verified | Details of the single sign-on domain verified for your organization |
-| Access token created | Access token created in organization |
-| Access token updated | Access token updated in organization |
-| Access token deleted | Access token deleted in organization |
-| Policy created | Details of adding a settings policy |
-| Policy updated | Details of updating a settings policy |
-| Policy deleted | Details of deleting a settings policy |
-| Policy transferred | Details of transferring a settings policy to another owner |
-
-### Repository events
-
-> [!NOTE]
->
-> Event descriptions that include a user action can refer to a Docker username, personal access token (PAT) or organization access token (OAT). For example, if a user pushes a tag to a repository, the event would include the description: `<user-access-token>` pushed the tag to the repository.
-
-| Event                                                          | Description                                   |
-|:------------------------------------------------------------------|:------------------------------------------------|
-| Repository Created | Activities related to the creation of a new repository |
-| Repository Deleted | Activities related to the deletion of a repository |
-| Repository Updated | Activities related to updating the description, full description, or status of a repository |
-| Privacy Changed | Details related to the privacy policies that were updated |
-| Tag Pushed | Activities related to the tags pushed |
-| Tag Deleted | Activities related to the tags deleted |
-| Categories Updated | Activities related to setting or updating categories of a repository |
-
-### Billing events
-
-| Event                                                          | Description                                   |
-|:------------------------------------------------------------------|:------------------------------------------------|
-| Plan Upgraded | Occurs when your organization’s billing plan is upgraded to a higher tier plan.|
-| Plan Downgraded | Occurs when your organization’s billing plan is downgraded to a lower tier plan. |
-| Seat Added | Occurs when a seat is added to your organization’s billing plan. |
-| Seat Removed | Occurs when a seat is removed from your organization’s billing plan. |
-| Billing Cycle Changed | Occurs when there is a change in the recurring interval that your organization is charged.|
-| Plan Downgrade Canceled | Occurs when a scheduled plan downgrade for your organization is canceled.|
-| Seat Removal Canceled | Occurs when a scheduled seat removal for an organization’s billing plan is canceled. |
-| Plan Upgrade Requested | Occurs when a user in your organization requests a plan upgrade. |
-| Plan Downgrade Requested | Occurs when a user in your organization requests a plan downgrade. |
-| Seat Addition Requested | Occurs when a user in your organization requests an increase in the number of seats. |
-| Seat Removal Requested | Occurs when a user in your organization requests a decrease in the number of seats. |
-| Billing Cycle Change Requested | Occurs when a user in your organization requests a change in the billing cycle. |
-| Plan Downgrade Cancellation Requested | Occurs when a user in your organization requests a cancellation of a scheduled plan downgrade. |
-| Seat Removal Cancellation Requested | Occurs when a user in your organization requests a cancellation of a scheduled seat removal. |
diff --git a/content/manuals/admin/organization/convert-account.md b/content/manuals/admin/organization/convert-account.md
deleted file mode 100644
index 66791d0396ef..000000000000
--- a/content/manuals/admin/organization/convert-account.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-description: Convert your Docker Hub user account into an organization
-title: Convert an account into an organization
-keywords: docker hub, hub, organization, convert account, migrate account
-weight: 35
-aliases:
-- /docker-hub/convert-account/
----
-
-{{< summary-bar feature_name="Admin orgs" >}}
-
-You can convert an existing user account to an organization. This is useful if you need multiple users to access your account and the repositories that it’s connected to. Converting it to an organization gives you better control over permissions for these users through [teams](manage-a-team.md) and [roles](roles-and-permissions.md).
-
-When you convert a user account to an organization, the account is migrated to a Docker Team plan.
-
-> [!IMPORTANT]
->
-> Once you convert your account to an organization, you can’t revert it to a user account.
-
-## Prerequisites
-
-Before you convert a user account to an organization, ensure that you meet the following requirements:
-
-- The user account that you want to convert must not be a member of a company or any teams or organizations. You must remove the account from all teams, organizations, or the company.
-
-    To do this:
-    1. Navigate to **My Hub** and then select the organization you need to leave.
-    2. Find your username in the **Members** tab.
-    3. Select the **More options** menu and then select **Leave organization**.
-
-    If the user account is the sole owner of any organization or company, assign another user the owner role and then remove yourself from the organization or company.
-
--  You must have a separate Docker ID ready to assign as the owner of the organization during conversion.
-
-    If you want to convert your user account into an organization account and you don't have any other user accounts, you need to create a new user account to assign it as the owner of the new organization. With the owner role assigned, this user account has full administrative access to configure and manage the organization. You can assign more users the owner role after the conversion.
-
-## Effects of converting an account into an organization
-
-Consider the following effects of converting your account:
-
-- This process removes the email address for the account, and organization owners will receive notification emails instead. You'll be able to reuse the removed email address for another account after converting.
-
-- The current plan will cancel and your new subscription will start.
-
-- Repository namespaces and names won't change, but converting your account removes any repository collaborators. Once you convert the account, you'll need to add those users as team members.
-
-- Existing automated builds will appear as if they were set up by the first owner added to the organization. See [Convert an account into an organization](#convert-an-account-into-an-organization) for steps on adding the first owner.
-
-- The user account that you add as the first owner will have full administrative access to configure and manage the organization.
-
-- To transfer a user's personal access tokens (PATs) to your converted organization,
-you must designate the user as an organization owner. This will ensure any PATs associated with the user's account are transferred to the organization owner.
-
-> [!TIP]
->
-> To avoid potentially disrupting service of personal access tokens when converting an account or changing ownership, it is recommended to use [organization access tokens](/manuals/security/for-admins/access-tokens.md). Organization access tokens are
-associated with an organization, not a single user account.
-
-## Convert an account into an organization
-
-1. Ensure you have removed your user account from any company or teams or organizations. Also make sure that you have a new Docker ID before you convert an account. See the [Prerequisites](#prerequisites) section for details.
-
-2. Sign in to [Docker Home](https://app.docker.com/login).
-
-3. In Docker Home, select your avatar in the top-right corner to open the drop-down.
-
-4. Select **Account settings**.
-
-5. Select **Convert**.
-
-6. Review the warning displayed about converting a user account. This action cannot be undone and has considerable implications for your assets and the account.
-
-7. Enter a **Username of new owner** to set an organization owner. This is the user account that will manage the organization, and the only way to access the organization settings after conversion. You cannot use the same Docker ID as the account you are trying to convert.
-
-8. Select **Confirm**. The new owner receives a notification email. Use that owner account to sign in and manage the new organization.
diff --git a/content/manuals/admin/organization/deactivate-account.md b/content/manuals/admin/organization/deactivate-account.md
index b0ad4ab3525e..cd4b8cfaa8f5 100644
--- a/content/manuals/admin/organization/deactivate-account.md
+++ b/content/manuals/admin/organization/deactivate-account.md
@@ -1,59 +1,55 @@
 ---
 title: Deactivate an organization
-description: Learn how to deactivate a Docker organization.
-keywords: Docker Hub, delete, deactivate organization, account, organization management
-weight: 42
+linkTitle: Deactivate
+description: Learn how to deactivate a Docker organization and required
+  prerequisite steps.
+keywords: deactivate organization, delete organization, organization
+  management, Docker Home, cancel subscription, unlink GitHub, remove SSO
+weight: 50
 aliases:
-- /docker-hub/deactivate-account/
+  - /docker-hub/deactivate-account/
 ---
 
 {{< summary-bar feature_name="General admin" >}}
 
-You can deactivate an account at any time. This section describes the prerequisites and steps to deactivate an organization account. For information on deactivating a user account, see [Deactivate a user account](../../accounts/deactivate-user-account.md).
+Learn how to deactivate a Docker organization, including required prerequisite
+steps. For information about deactivating user accounts, see
+[Deactivate a Docker
+account](/manuals/accounts/deactivate-user-account.md).
 
 > [!WARNING]
 >
-> All Docker products and services that use your Docker account or organization account will be inaccessible after deactivating your account.
+> All Docker products and services that use this organization are
+> inaccessible after you deactivate it. Your individual Docker account
+> remains active.
 
 ## Prerequisites
 
-Before deactivating an organization, complete the following:
-
-- Download any images and tags you want to keep:
-  `docker pull -a <image>:<tag>`.
-
-- If you have an active Docker subscription, [downgrade it to a free subscription](../../subscription/change.md).
+You must complete all the following steps before you can deactivate your
+organization:
 
+- Download any images and tags you want to keep. Use `docker pull -a <image>`
+  to pull all tags, or `docker pull <image>:<tag>` to pull a specific tag.
+- If you have an active Docker subscription, [downgrade it to a basic
+  organization
+  account](/manuals/subscription/plans/docker.md#cancel-a-docker-plan).
 - Remove all other members within the organization.
-
-- Unlink your [Github and Bitbucket accounts](../../docker-hub/repos/manage/builds/link-source.md#unlink-a-github-user-account).
-
-- For Business organizations, [remove your SSO connection](../../security/for-admins/single-sign-on/manage/#remove-an-organization).
+- Unlink your [GitHub and Bitbucket
+  accounts](/manuals/docker-hub/repos/manage/builds/link-source.md#unlink-a-github-user-account).
+- For Business organizations, [remove your SSO
+  connection](/manuals/enterprise/security/single-sign-on/manage.md#delete-a-connection).
 
 ## Deactivate
 
-Once you have completed all the previous steps, you can deactivate your organization.
-
 > [!WARNING]
 >
-> This cannot be undone. Be sure you've gathered all the data you need from your organization before deactivating it.
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-1. In Admin Console, choose the organization you want to deactivate.
-2. Under **Organization settings**, select **Deactivate**.
-3. Enter the organization name to confirm deactivation.
-4. Select **Deactivate organization**.
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-1. On Docker Hub, select **My Hub**.
-2. Choose the organization you want to deactivate.
-3. In **Settings**, select the **Deactivate org** and then **Deactivate organization**.
-
-{{< /tab >}}
-{{< /tabs >}}
+> Deactivating an organization is permanent and can't be undone. Make sure
+> you've gathered all the data you need before you deactivate it.
+
+1. Sign in to [Docker Home](https://app.docker.com) and select the organization
+   you want to deactivate.
+1. Select **Organization settings**, then **Deactivate**. If the **Deactivate**
+   button is unavailable, confirm you've completed all
+   [Prerequisites](#prerequisites).
+1. Enter the organization name to confirm deactivation.
+1. Select **Deactivate organization**.
diff --git a/content/manuals/admin/organization/general-settings.md b/content/manuals/admin/organization/general-settings.md
deleted file mode 100644
index 6cc04ab9071b..000000000000
--- a/content/manuals/admin/organization/general-settings.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Organization settings
-weight: 60
-description: Learn how to manage settings for organizations using Docker Admin Console.
-keywords: organization, settings, Admin Console
----
-
-This section describes how to manage organization settings in the Docker Admin Console.
-
-## Configure general information
-
-General organization information appears on your organization landing page in the Admin Console.
-
-This information includes:
- - Organization Name
- - Company
- - Location
- - Website
- - Gravatar email: To add an avatar to your Docker account, create a [Gravatar account](https://gravatar.com/) and create your avatar. Next, add your Gravatar email to your Docker account settings. It may take some time for your avatar to update in Docker.
-
-To edit this information:
-
-1. Sign in to the [Admin Console](https://admin.docker.com).
-2. Select your company on the **Choose profile** page.
-3. Under **Organization settings**, select **General**.
-4. Specify the organization information and select **Save**.
-
-## Next steps
-
-In the **Organization settings** menu, you can also [configure SSO](../../security/for-admins/single-sign-on/configure/) and [set up SCIM](../../security/for-admins/provisioning/scim.md). If your organization isn't part of a company, from here you can also [audit your domains](../../security/for-admins/domain-audit.md) or [create a company](new-company.md).
diff --git a/content/manuals/admin/organization/insights.md b/content/manuals/admin/organization/insights.md
deleted file mode 100644
index 187f0c57e404..000000000000
--- a/content/manuals/admin/organization/insights.md
+++ /dev/null
@@ -1,186 +0,0 @@
----
-description: Gain insights about your organization's users and their Docker usage.
-keywords: organization, insights
-title: Insights
----
-
-{{< summary-bar feature_name="Insights" >}}
-
-Insights helps administrators visualize and understand how Docker is used within
-their organizations. With Insights, administrators can ensure their teams are
-fully equipped to utilize Docker to its fullest potential, leading to improved
-productivity and efficiency across the organization.
-
-Key benefits include:
-
-- Uniform working environment. Establish and maintain standardized
-  configurations across teams.
-- Best practices. Promote and enforce usage guidelines to ensure optimal
-  performance.
-- Increased visibility. Monitor and drive adoption of organizational
-  configurations and policies.
-- Optimized license use. Ensure that developers have access to advanced
-  features provided by a Docker subscription.
-
-## Prerequisites
-
-- [Docker Business subscription](../../subscription/details.md#docker-business)
-- Administrators must [enforce sign-in](/security/for-admins/enforce-sign-in/) for users
-- Insights enabled by your Customer Success Manager
-
-## View Insights for organization users
-
-To access Insights, you must contact your Customer Success Manager to have the
-feature enabled. Once the feature is enabled, access Insights using the following
-steps:
-
-1. Go to the [Admin Console](https://app.docker.com/admin/) and sign in to an
-   account that is an organization owner.
-2. Select your company on the **Choose profile** page.
-3. Select **Insights**.
-4. On the **Insights** page, select the period of time for the data.
-
-> [!NOTE]
->
-> Insights data is not real-time and is updated daily. At the top-right of the
-> Insights page, view the **Last updated** date to understand when the data was
-> last updated.
-
-You can view data in the following charts:
-
- - [Docker Desktop users](#docker-desktop-users)
- - [Builds](#builds)
- - [Containers](#containers)
- - [Docker Desktop usage](#docker-desktop-usage)
- - [Docker Hub images](#docker-hub-images)
- - [Extensions](#extensions)
-
-### Docker Desktop users
-
-Track active Docker Desktop users in your domain, differentiated by license
-status. This chart helps you understand the engagement levels within your
-organization, providing insights into how many users are actively using Docker
-Desktop. Note that users who opt out of analytics aren't included in the active
-counts.
-
-The chart contains the following data.
-
-| Data | Description |
-|:-----------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Active user | The number of users that have actively used Docker Desktop and either signed in with a Docker account that has a license in your organization or signed in to a Docker account with an email address from a domain associated with your organization. <br><br>Users who don’t sign in to an account associated with your organization are not represented in the data. To ensure users sign in with an account associated with your organization, you can [enforce sign-in](/security/for-admins/enforce-sign-in/). |
-| Total organization members | The number of users that have used Docker Desktop, regardless of their Insights activity. |
-| Users opted out of analytics | The number of users that are a member of your organization that have opted out of sending analytics. <br><br>When users opt out of sending analytics, you won't see any of their data in Insights. To ensure that the data includes all users, you can use [Settings Management](/desktop/hardened-desktop/settings-management/) to set `analyticsEnabled` for all your users. |
-| Active users (graph) | The view over time for total active users. |
-
-
-### Builds
-
-Monitor development efficiency and the time your team invests in builds with
-this chart. It provides a clear view of the build activity, helping you identify
-patterns, optimize build times, and enhance overall development productivity.
-
-The chart contains the following data.
-
-| Data                   | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
-|:-----------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Average build per user | The average number of builds per active user. A build includes any time a user runs one of the following commands: <ul><li>`docker build`</li><li>`docker buildx b`</li><li>`docker buildx bake`</li><li>`docker buildx build`</li><li>`docker buildx f`</li><li>`docker builder b`</li><li>`docker builder bake`</li><li>`docker builder build`</li><li>`docker builder f`</li><li>`docker compose build`</li><li>`docker compose up --build`</li><li>`docker image build`</li></ul> |
-| Average build time     | The average build time per build.                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
-| Build success rate     | The percentage of builds that were successful out of the total number of builds. A successful build includes any build that exits normally.                                                                                                                                                                                                                                                                                                                                          |
-| Total builds (graph)   | The total number of builds separated into successful builds and failed builds. A successful build includes any build that exits normally. A failed build includes any build that exits abnormally.                                                                                                                                                                                                                                                                                   |
-
-### Containers
-
-View the total and average number of containers run by users with this chart. It
-lets you gauge container usage across your organization, helping you understand
-usage trends and manage resources effectively.
-
-The chart contains the following data.
-
-| Data                                   | Description                                                                                                                                                                |
-|:---------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Total containers run                   | The total number of containers run by active users. Containers run include those run using the Docker Desktop graphical user interface, `docker run`, or `docker compose`. |
-| Average number of containers run       | The average number of containers run per active user.                                                                                                                      |
-| Containers run by active users (graph) | The number of containers run over time by active users.                                                                                                                    |
-
-### Docker Desktop usage
-
-Explore Docker Desktop usage patterns with this chart to optimize your team's
-workflows and ensure compatibility. It provides valuable insights into how
-Docker Desktop is being utilized, enabling you to streamline processes and
-improve efficiency.
-
-The chart contains the following data.
-
-| Data                              | Description                                                                                                                                                                                                                                                                       |
-|:----------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Most used version                 | The most used version of Docker Desktop by users in your organization.                                                                                                                                                                                                            |
-| Most used OS                      | The most used operating system by users.                                                                                                                                                                                                                                          |
-| Versions by active users (graph)  | The number of active users using each version of Docker Desktop. <br><br>To learn more about each version and release dates, see the [Docker Desktop release notes](/desktop/release-notes/).                                                                                     |
-| Interface by active users (graph) | The number of active users grouped into the type of interface they used to interact with Docker Desktop. <br><br>A CLI user is any active user who has run a `docker` command. A GUI user is any active user who has interacted with the Docker Desktop graphical user interface. |
-
-### Docker Hub images
-
-Analyze image distribution activity with this chart and view the most utilized
-Docker Hub images within your domain. This information helps you manage image
-usage, ensuring that the most critical resources are readily available and
-efficiently used.
-
-> [!NOTE]
-> Data for images is only for Docker Hub. Data for third-party
-> registries and mirrors aren't included.
-
-The chart contains the following data.
-
-| Data                 | Description                                                                                                     |
-|:---------------------|:----------------------------------------------------------------------------------------------------------------|
-| Total pulled images  | The total number of images pulled by users from Docker Hub.                                                     |
-| Total pushed images  | The total number of images pushed by users to Docker Hub.                                                       |
-| Top 10 pulled images | A list of the top 10 images pulled by users from Docker Hub and the number of times each image has been pulled. |
-
-### Extensions
-
-Monitor extension installation activity with this chart. It provides visibility
-into the Docker Desktop extensions your team are using, letting you track
-adoption and identify popular tools that enhance productivity.
-
-The chart contains the following data.
-
-| Data                                           | Description                                                                                                                                      |
-|:-----------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------|
-| Percentage of org with extensions installed    | The percentage of users in your organization with at least one Docker Desktop extension installed.                                               |
-| Top 5 extensions installed in the organization | A list of the top 5 Docker Desktop extensions installed by users in your organization and the number of users who have installed each extension. |
-
-
-## Troubleshoot Insights
-
-If you’re experiencing issues with data in Insights, consider the following
-solutions to resolve common problems.
-
-* Update users to the latest version of Docker Desktop.
-
-   Data is not shown for users using versions 4.16 or lower of Docker Desktop.
-   In addition, older versions may not provide all data. Ensure all users have
-   installed the latest version of Docker Desktop.
-
-* Enable **Send usage statistics** in Docker Desktop for all your users.
-
-   If users have opted out of sending usage statistics for Docker Desktop, then
-   their usage data will not be a part of Insights. To manage the setting at
-   scale for all your users, you can use [Settings
-   Management](/desktop/hardened-desktop/settings-management/) and enable the
-   `analyticsEnabled` setting.
-
-* Ensure that users are using Docker Desktop and aren't using the standalone
-  version of Docker Engine.
-
-   Only Docker Desktop can provide data for Insights. If a user installs and
-   uses Docker Engine outside of Docker Desktop, Docker Engine won't provide
-   data for that user.
-
-* Ensure that users are signing in to an account associated with your
-  organization.
-
-   Users who don’t sign in to an account associated with your organization are
-   not represented in the data. To ensure users sign in with an account
-   associated with your organization, you can [enforce
-   sign-in](/security/for-admins/enforce-sign-in/).
diff --git a/content/manuals/admin/organization/manage-a-team.md b/content/manuals/admin/organization/manage-a-team.md
deleted file mode 100644
index 1491f77edea7..000000000000
--- a/content/manuals/admin/organization/manage-a-team.md
+++ /dev/null
@@ -1,150 +0,0 @@
----
-title: Create and manage a team
-weight: 40
-description: Learn how to create and manage teams for your organization
-keywords: Docker, docker, registry, teams, organizations, plans, Dockerfile, Docker
-  Hub, docs, documentation, repository permissions
-aliases:
-- /docker-hub/manage-a-team/
----
-
-{{< summary-bar feature_name="Admin orgs" >}}
-
-You can create teams for your organization in Docker Hub and the Docker Admin Console. You can [configure repository access for a team](#configure-repository-permissions-for-a-team) in Docker Hub.
-
-A team is a group of Docker users that belong to an organization. An organization can have multiple teams. An organization owner can then create new teams and add members to an existing team using their Docker ID or email address and by selecting a team the user should be part of. Members aren't required to be part of a team to be associated with an organization.
-
-The organization owner can add additional organization owners to help them manage users, teams, and repositories in the organization by assigning them the owner role.
-
-## Organization owner
-
-An organization owner is an administrator who has the following permissions:
-
-- Manage repositories and add team members to the organization.
-- Access private repositories, all teams, billing information, and organization settings.
-- Specify [permissions](#permissions-reference) for each team in the organization.
-- Enable [SSO](../../security/for-admins/single-sign-on/_index.md) for the organization.
-
-When SSO is enabled for your organization, the organization owner can
-also manage users. Docker can auto-provision Docker IDs for new end-users or
-users who'd like to have a separate Docker ID for company use through SSO
-enforcement.
-
-The organization owner can also add additional organization owners to help them manage users, teams, and repositories in the organization.
-
-## Create a team
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-1. In Admin Console, select your organization.
-2. In the **User management** section, select **Teams**.
-3. Select **Create team**.
-4. Fill out your team's information and select **Create**.
-5. [Add members to your team](members.md#add-a-member-to-a-team).
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select **My Hub** and choose your organization.
-3. Select the **Teams** and then select **Create Team**.
-4. Fill out your team's information and select **Create**.
-5. [Add members to your team](members.md#add-a-member-to-a-team).
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Configure repository permissions for a team
-
-Organization owners can configure repository permissions on a per-team basis.
-For example, you can specify that all teams within an organization have "Read and
-Write" access to repositories A and B, whereas only specific teams have "Admin"
-access. Note that organization owners have full administrative access to all repositories within the organization.
-
-To give a team access to a repository:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select **My Hub** and choose your organization.
-3. Select the **Teams** and select the team that you'd like to configure repository access to.
-4. Select the **Permissions** tab and select a repository from the
-   **Repository** drop-down.
-5. Choose a permission from the **Permissions** drop-down list and select
-   **Add**.
-
-Organization owners can also assign members the editor role to grant partial administrative access. See [Roles and permissions](../../security/for-admins/roles-and-permissions.md) for more about the editor role.
-
-### Permissions reference
-
-- `Read-only` access lets users view, search, and pull a private repository in the same way as they can a public repository.
-- `Read & Write` access lets users pull, push, and view a repository. In addition, it lets users view, cancel, retry or trigger builds
-- `Admin` access lets users pull, push, view, edit, and delete a
-  repository. You can also edit build settings, and update the repositories description, collaborators rights, public/private visibility, and delete.
-
-Permissions are cumulative. For example, if you have "Read & Write" permissions,
-you automatically have "Read-only" permissions:
-
-| Action | Read-only | Read & Write | Admin |
-|:------------------:|:---------:|:------------:|:-----:|
-| Pull a Repository | ✅ | ✅ | ✅ |
-| View a Repository | ✅ | ✅ | ✅ |
-| Push a Repository | ❌ | ✅ | ✅ |
-| Edit a Repository | ❌ | ❌ | ✅ |
-| Delete a Repository | ❌ | ❌ | ✅ |
-| Update a Repository Description | ❌ | ❌ | ✅ |
-| View Builds | ✅ | ✅ | ✅ |
-| Cancel Builds | ❌ | ✅ | ✅ |
-| Retry Builds | ❌ | ✅ | ✅ |
-| Trigger Builds | ❌ | ✅ | ✅ |
-| Edit Build Settings | ❌ | ❌ | ✅ |
-
-> [!NOTE]
->
-> A user who hasn't verified their email address only has
-> `Read-only` access to the repository, regardless of the rights their team
-> membership has given them.
-
-## View a team's permissions for all repositories
-
-To view a team's permissions across all repositories:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select **My Hub** and choose your organization.
-3. Select **Teams** and choose your team name.
-4. Select the **Permissions** tab, where you can view the repositories this team can access.
-
-## Delete a team
-
-Organization owners can delete a team in Docker Hub or Admin Console. When you remove a team from your organization, this action revokes the members' access to the team's permitted resources. It won't remove users from other teams that they belong to, nor will it delete any resources.
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-1. In the [Admin Console](https://app.docker.com/admin), select your organization.
-2. In the **User management** section, select **Teams**.
-3. Select the **Actions** icon next to the name of the team you want to delete.
-4. Select **Delete team**.
-5. Review the confirmation message, then select **Delete**.
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select **My Hub** and choose your organization.
-3. Select **Teams**.
-4. Select the name of the team that you want to delete.
-5. Select **Settings**.
-6. Select **Delete Team**.
-7. Review the confirmation message, then select **Delete**.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## More resources
-
-- [Video: Docker teams](https://youtu.be/WKlT1O-4Du8?feature=shared&t=348)
-- [Video: Roles, teams, and repositories](https://youtu.be/WKlT1O-4Du8?feature=shared&t=435)
diff --git a/content/manuals/admin/organization/manage-products.md b/content/manuals/admin/organization/manage-products.md
deleted file mode 100644
index b20004ed23f3..000000000000
--- a/content/manuals/admin/organization/manage-products.md
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: Manage Docker products
-weight: 45
-description: Learn how to manage Docker products for your organization
-keywords: organization, tools, products
----
-
-{{< summary-bar feature_name="Admin orgs" >}}
-
-In this section, learn how to manage access and view usage of the Docker
-products for your organization. For more detailed information about each
-product, including how to set up and configure them, see the following manuals:
-
-- [Docker Build Cloud](../../build-cloud/_index.md)
-- [Docker Desktop](../../desktop/_index.md)
-- [Docker Hub](../../docker-hub/_index.md)
-- [Docker Scout](../../scout/_index.md)
-- [Testcontainers Cloud](https://testcontainers.com/cloud/docs/#getting-started)
-
-## Manage access to Docker products
-
-Access to Docker products included in your subscription is enabled by default
-for all users. The included products are:
-
-- Docker Hub
-- Docker Build Cloud
-- Docker Desktop
-- Docker Scout
-
-Testcontainers Cloud is not enabled by default. To enable Testcontainers Cloud, see the Testcontainers [Getting Started](https://testcontainers.com/cloud/docs/#getting-started) guide.
-
-The following sections describe how to enable or disable access for these products.
-
-### Manage access to Docker Build Cloud
-
-To learn how to initially set up and configure Docker Build Cloud, sign in to
-the [Docker Build Cloud Dashboard](https://app.docker.com/build) and follow the
-on-screen instructions.
-
-To manage access to Docker Build Cloud, sign in to [Docker Build
-Cloud](http://app.docker.com/build) as an organization owner, select **Account
-settings**, and then manage access under **Lock Docker Build Cloud**.
-
-### Manage access to Docker Scout
-
-To learn how to initially set up and configure Docker Scout for remote
-repositories, sign in to the [Docker Scout Dashboard](https://scout.docker.com/)
-and follow the on-screen instructions.
-
-To manage access to Docker Scout for use on remote repositories, sign in to the
-[Docker Scout Dashboard](https://scout.docker.com/) and configure
-[integrations](../../scout/explore/dashboard.md#integrations) and [repository
-settings](../../scout/explore/dashboard.md#repository-settings).
-
-To manage access to Docker Scout for use on local images with Docker Desktop, use
-[Settings
-Management](../../security/for-admins/hardened-desktop/settings-management/_index.md)
-and set `sbomIndexing` to `false` to disable, or to `true` to enable.
-
-### Manage access to Docker Hub
-
-To manage access to Docker Hub, sign in to the [Docker Admin Console](https://app.docker.com/admin) and configure [Registry Access
-Management](../../security/for-admins/hardened-desktop/registry-access-management.md)
-or [Image Access
-Management](../../security/for-admins/hardened-desktop/image-access-management.md).
-
-### Manage access to Testcontainers Cloud
-
-To learn how to initially set up and configure Testcontainers Cloud, sign in to
-[Testcontainers Cloud](https://app.testcontainers.cloud/) and follow the
-on-screen instructions.
-
-To manage access to Testcontainers Cloud, sign in to the [Testcontainers Cloud
-Settings page](https://app.testcontainers.cloud/dashboard/settings) as
-an organization owner, and then manage access under **Lock Testcontainers
-Cloud**.
-
-### Manage access to Docker Desktop
-
-To manage access to Docker Desktop, you can [enforce
-sign-in](../../security/for-admins/enforce-sign-in/_index.md), then and manage
-members [manually](./members.md) or use
-[provisioning](../../security/for-admins/provisioning/_index.md). With sign-in
-enforced, only users who are a member of your organization can use Docker
-Desktop after signing in.
-
-## View Docker product usage
-
-View usage for the products on the following pages:
-
-- Docker Build Cloud: View the **Build minutes** page in the [Docker Build Cloud
-  Dashboard](http://app.docker.com/build).
-
-- Docker Scout: View the [**Repository settings**
-  page](https://scout.docker.com/settings/repos) in the Docker Scout
-  Dashboard.
-
-- Docker Hub: View the [**Usage** page](https://hub.docker.com/usage) in Docker
-  Hub.
-
-- Testcontainers Cloud: View the [**Billing**
-  page](https://app.testcontainers.cloud/dashboard/billing) in the
-  Testcontainers Cloud Dashboard.
-
-- Docker Desktop: View the **Insights** page in the [Docker Admin Console](https://app.docker.com/admin). For more details, see
-  [Insights](./insights.md).
-
-If your usage exceeds your subscription amount, you can [scale your
-subscription](../../subscription/scale.md) to meet your needs.
\ No newline at end of file
diff --git a/content/manuals/admin/organization/manage/_index.md b/content/manuals/admin/organization/manage/_index.md
new file mode 100644
index 000000000000..5ccfc50fa17c
--- /dev/null
+++ b/content/manuals/admin/organization/manage/_index.md
@@ -0,0 +1,53 @@
+---
+title: Manage your organization
+linkTitle: Manage
+weight: 20
+description: Learn how to manage your Docker organization, including members, teams, licenses, seats, and product access.
+keywords: manage organization, members, teams, licenses, seats, product access, organization management, docker home
+grid:
+  - title: Members
+    description: Invite, manage, and assign roles to your organization members.
+    icon: user-plus
+    link: /admin/organization/manage/members/
+  - title: Product access and usage
+    description: Manage access and view usage for Docker products across your organization.
+    icon: squares-2x2
+    link: /admin/organization/manage/manage-products/
+  - title: Security
+    description: Configure single sign-on, provisioning, and access management.
+    icon: shield-check
+    link: /enterprise/security/
+  - title: Billing
+    description: Manage payment methods and view billing history.
+    icon: credit-card
+    link: /billing/
+---
+
+As an organization owner, you manage your organization's membership, access,
+and product usage. You can invite members, group them into teams, assign or
+revoke licenses and seats, and change access to Docker products.
+
+## Managing your organization
+
+You manage your organization from [Docker Home](https://app.docker.com) and
+must be assigned the
+[organization owner role](/manuals/enterprise/security/roles-and-permissions/_index.md).
+
+## Seats and licenses
+
+Seats and licenses both control access, but they apply to different kinds of
+plans. The following table summarizes the difference.
+
+| Entitlement | What it grants                                          | Applies to                                       | Managed from |
+| ----------- | ------------------------------------------------------- | ------------------------------------------------ | ------------ |
+| Seat        | Membership in your Docker Team or Business subscription | Docker Core subscription                         | Billing      |
+| License     | Access to a specific product or add-on                  | AI Governance, Docker Offload, and other add-ons | Members      |
+
+For details, see [Seats](/manuals/admin/organization/manage/manage-seats.md)
+and [License assignment](/manuals/admin/organization/manage/manage-licenses.md).
+
+## Next steps
+
+Explore the following sections to manage your organization.
+
+{{< grid >}}
diff --git a/content/manuals/admin/organization/manage/manage-a-team.md b/content/manuals/admin/organization/manage/manage-a-team.md
new file mode 100644
index 000000000000..31fd9b53bfc7
--- /dev/null
+++ b/content/manuals/admin/organization/manage/manage-a-team.md
@@ -0,0 +1,133 @@
+---
+title: Create and manage a team
+linkTitle: Teams
+weight: 20
+description: Learn how to create and manage teams for your organization
+keywords: docker, registry, teams, organizations, plans, Dockerfile, Docker
+  Hub, docs, documentation, repository permissions, configure repository access, team management
+aliases:
+  - /docker-hub/manage-a-team/
+  - /admin/organization/manage-a-team/
+---
+
+{{< summary-bar feature_name="Admin orgs" >}}
+
+You can create teams for your organization in Docker Home or Docker Hub,
+and configure team repository access in Docker Hub.
+
+A team is a group of Docker users that belong to an organization. An
+organization can have multiple teams. An organization owner can create new
+teams and add members to an existing team using their Docker ID or email
+address. Members aren't required to be part of a team to be associated with an
+organization.
+
+The organization owner can add additional organization owners to help them
+manage users, teams, and repositories in the organization by assigning them
+the owner role.
+
+## What is an organization owner?
+
+An organization owner is an administrator who has the following permissions:
+
+- Manage repositories and add team members to the organization
+- Access private repositories, all teams, billing information, and
+  organization settings
+- Specify [permissions](#permissions-reference) for each team in the
+  organization
+- Enable [SSO](/manuals/enterprise/security/single-sign-on/_index.md) for the
+  organization
+
+When SSO is enabled for your organization, the organization owner can
+also manage users. Docker can auto-provision Docker IDs for new end-users or
+users who'd like to have a separate Docker ID for company use through SSO
+enforcement.
+
+Organization owners can add others with the owner role to help them
+manage users, teams, and repositories in the organization.
+
+For more information on roles, see
+[Roles and permissions](/manuals/enterprise/security/roles-and-permissions.md).
+
+## Create a team
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+   organization.
+1. Select **Teams**.
+1. Select **Create team**.
+1. Provide the team's information, then select **Create**.
+
+## Set team repository permissions
+
+You must create a team before you are able to configure repository permissions.
+For more details, see [Create and manage a
+team](/manuals/admin/organization/manage/manage-a-team.md).
+
+To set team repository permissions:
+
+1. Sign in to [Docker Hub](https://hub.docker.com).
+1. Select **My Hub** > **Repositories**.
+
+   A list of your repositories appears.
+
+1. Select a repository.
+
+   The **General** page for the repository appears.
+
+1. Select the **Permissions** tab.
+1. Add, modify, or remove a team's repository permissions.
+   - Add: Specify the **Team**, select the **Permission**, and then select **Add**.
+   - Modify: Specify the new permission next to the team.
+   - Remove: Select the **Remove permission** icon next to the team.
+
+### Permissions reference
+
+- `Read-only` access lets users view, search, and pull a private repository
+  in the same way as they can a public repository.
+- `Read & Write` access lets users pull, push, and view a repository. In
+  addition, it lets users view, cancel, retry or trigger builds.
+- `Admin` access lets users pull, push, view, edit, and delete a
+  repository. You can also edit build settings and update the repository’s
+  description, collaborator permissions, public/private visibility, and delete.
+
+Permissions are cumulative. For example, if you have "Read & Write" permissions,
+you automatically have "Read-only" permissions.
+
+The following table shows what each permission level allows users to do:
+
+|             Action              | Read-only | Read & Write | Admin |
+| :-----------------------------: | :-------: | :----------: | :---: |
+|        Pull a Repository        |    ✅     |      ✅      |  ✅   |
+|        View a Repository        |    ✅     |      ✅      |  ✅   |
+|        Push a Repository        |    ❌     |      ✅      |  ✅   |
+|        Edit a Repository        |    ❌     |      ❌      |  ✅   |
+|       Delete a Repository       |    ❌     |      ❌      |  ✅   |
+| Update a Repository Description |    ❌     |      ❌      |  ✅   |
+|           View Builds           |    ✅     |      ✅      |  ✅   |
+|          Cancel Builds          |    ❌     |      ✅      |  ✅   |
+|          Retry Builds           |    ❌     |      ✅      |  ✅   |
+|         Trigger Builds          |    ❌     |      ✅      |  ✅   |
+|       Edit Build Settings       |    ❌     |      ❌      |  ✅   |
+
+> [!NOTE]
+>
+> A user who hasn't verified their email address only has `Read-only` access to
+> the repository, regardless of the rights their team membership has given them.
+
+## Delete a team
+
+Organization owners can delete a team. When you remove a team from your
+organization, this action revokes member access to the team's permitted
+resources. It won't remove users from other teams that they belong to, and it
+won't delete any resources.
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization.
+1. Select **Teams**.
+1. Select the **Actions** icon next to the name of the team you want to delete.
+1. Select **Delete team**.
+1. Review the confirmation message, then select **Delete**.
+
+## More resources
+
+- [Video: Docker Teams](https://youtu.be/WKlT1O-4Du8?feature=shared&t=348)
+- [Video: Roles, teams, and repositories](https://youtu.be/WKlT1O-4Du8?feature=shared&t=435)
diff --git a/content/manuals/admin/organization/manage/manage-licenses.md b/content/manuals/admin/organization/manage/manage-licenses.md
new file mode 100644
index 000000000000..4a1d142dc728
--- /dev/null
+++ b/content/manuals/admin/organization/manage/manage-licenses.md
@@ -0,0 +1,124 @@
+---
+title: Manage license assignment
+linkTitle: License assignment
+description: Manage product licenses for your organization, including invite-time assignment, revocation, and automatic assignment.
+keywords: licenses, organization, members, invite, invitation, Docker Core, Docker Offload, AI Governance, license assignment, docker home
+weight: 30
+---
+
+Licenses let you choose which organization members can access supported Docker
+products. Organization owners can manage active licenses for their members, or
+configure licenses to assign automatically when members access supported Docker
+products.
+
+> [!TIP]
+> To learn more about product licenses, Docker Core seats, and other Docker
+> add-ons, see [Docker plans](/manuals/subscription/plans/_index.md),
+> or
+> <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_admin_licenses" class="link" rel="noopener">contact sales</a>
+> to purchase licenses.
+
+## Licenses and invites
+
+When you invite someone, you can select a product license to assign when they
+accept. Docker doesn't reserve or deduct the license at invite time; assignment
+happens on acceptance:
+
+- If a license is available when they accept, Docker assigns it to them and the
+  number of available licenses decreases by one.
+- If no licenses remain when they accept, they still join your organization,
+  but without a license.
+
+> [!NOTE]
+> Docker doesn't notify you or the invitee when a selected license is
+> unavailable at acceptance.
+
+Licenses aren't reserved for pending invitations, so they must still be
+available when each invitee accepts. Monitor availability on the Members page
+while invitations are pending.
+
+### Select licenses when inviting
+
+Selecting licenses when you invite is an alternative to assigning one manually
+after they join, or, where available, relying on automatic license assignment
+the first time they use a supported product. To select licenses when you invite
+a member:
+
+1. Sign in to [Docker Home](https://app.docker.com), then choose your
+   organization.
+1. Select **Members** from the left navigation, then select **Invite**.
+1. Select **Emails or usernames**.
+1. Enter the email addresses or Docker IDs of the people you want to invite,
+   then assign their
+   [role](/manuals/enterprise/security/roles-and-permissions/_index.md).
+1. Under **Licenses (optional)**, select one or more licenses that are
+   available to your organization.
+1. Select **Invite** to send the invite.
+
+For more about sending, resending, and removing invitations, including CSV
+file limits, see
+[Manage organization members](/manuals/admin/organization/manage/members.md).
+
+### Accept invites
+
+A user can accept from the link in their invitation email or from their
+**Notifications Center**. If the selected license is available, Docker assigns
+it automatically upon acceptance.
+
+## Automatic license assignment
+
+Automatic license assignment gives members a product license when they use a
+supported product for the first time. Automatic license assignment is available
+for AI Governance licenses. Only organizations that purchase AI Governance can
+set up auto-assignment for Docker Core as well.
+
+- When you purchase AI Governance, signing in to
+  [Docker Sandboxes](/manuals/ai/sandboxes/_index.md) with the `sbx login`
+  command automatically provisions AI Governance licenses on a first-come,
+  first-served basis.
+- Similarly, signing in to Docker Desktop automatically provisions Docker Core
+  for AI Governance license-holding organizations that have available Docker
+  Core seats.
+- Licenses are assigned until exhausted.
+  - Once the available licenses are exhausted, automatic license assignment
+    stops until you purchase more licenses or revoke assigned licenses.
+  - Members can still use Docker Sandboxes or Docker Desktop, but organization
+    policies for those products won't affect their usage.
+
+AI Governance licenses include single sign-on (SSO) and provisioning features
+regardless of your Docker Core subscription. Automatic license assignment
+requires
+[setting up SSO](/manuals/enterprise/security/single-sign-on/connect.md), then
+[provisioning](/manuals/enterprise/security/provisioning/_index.md) with System
+for Cross-domain Identity Management (SCIM) or Just-in-Time (JIT).
+
+## Manage licenses
+
+The **Members** page lets you track the number of available licenses for your
+organization and who holds a license. You can also assign or revoke licenses
+from this page.
+
+To manage licenses for your organization:
+
+1. Sign in to [Docker Home](https://app.docker.com), then choose your
+   organization.
+1. Select **Members** from the left navigation.
+1. Select the action menu at the end of the row to assign or revoke an active
+   license.
+1. Optional. To bulk assign or revoke licenses, choose the members you want to
+   bulk manage, then select the **Bulk actions** menu.
+1. Optional. To manage automatic license assignment, turn off or turn on with
+   the **Automatically assign licenses** toggle.
+
+## Next steps
+
+Explore Docker Core add-ons and products that need licenses:
+
+- [Docker plans](/manuals/subscription/plans/_index.md) to learn about different
+  add-ons
+- [Manage seats](/manuals/admin/organization/manage/manage-seats.md) to add more
+  seats to your Docker Core subscription
+- [AI Governance plan](/manuals/subscription/plans/ai-governance.md) to learn
+  about AI Governance license usage and billing
+- [Docker Offload](/manuals/offload/about.md) to let your developers offload
+  building and running containers to the cloud
diff --git a/content/manuals/admin/organization/manage/manage-products.md b/content/manuals/admin/organization/manage/manage-products.md
new file mode 100644
index 000000000000..dd6afd68cb5f
--- /dev/null
+++ b/content/manuals/admin/organization/manage/manage-products.md
@@ -0,0 +1,155 @@
+---
+title: Manage usage and access for Docker products
+linkTitle: Product usage and access
+weight: 50
+description: Learn how to manage access and usage for Docker products for your organization
+keywords: organization, product access, product usage, access control, docker desktop, docker hub, docker scout, docker build cloud, docker offload, testcontainers cloud
+aliases:
+  - /admin/organization/manage-products/
+---
+
+{{< summary-bar feature_name="Admin orgs" >}}
+
+Use this page to learn how to control and monitor product access and usage
+for your organization's members. If you're looking for setup and
+configuration instructions, see each product's manual under
+[Next steps](#next-steps).
+
+## Control access for your organization
+
+Organization members can access Docker products that your organization is
+subscribed to by default. When signed in as an organization owner, you can
+use the following procedures to control access for all members.
+
+### Docker Desktop access
+
+To manage Docker Desktop access:
+
+1. [Enforce sign-in](../../../enterprise/security/enforce-sign-in/_index.md).
+1. Manage members [manually](./members.md) or use
+   [provisioning](../../../enterprise/security/provisioning/_index.md).
+
+With sign-in enforced, only users who are a member of your organization can
+use Docker Desktop after signing in.
+
+### Docker Hub access
+
+To manage Docker Hub access:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization, then select **Docker Desktop**.
+1. Select **Registry Access** to configure
+   [Registry Access Management](../../../enterprise/security/hardened-desktop/registry-access-management.md).
+1. Select **Image Access** to control
+   [Image Access Management](../../../enterprise/security/hardened-desktop/image-access-management.md).
+
+### Docker Build Cloud access
+
+To initially set up and configure Docker Build Cloud, sign in to
+[Docker Build Cloud](https://app.docker.com/build) and follow the
+on-screen instructions.
+
+To manage Docker Build Cloud access:
+
+1. Sign in to [Docker Home](https://app.docker.com/), then select
+   [Docker Build Cloud](http://app.docker.com/build).
+1. Select **Account settings**.
+1. Select **Lock access to Docker Build Account**.
+
+### Docker Scout access
+
+To initially set up and configure Docker Scout, sign in to
+[Docker Scout](https://scout.docker.com/) and follow the on-screen
+instructions.
+
+To manage Docker Scout access:
+
+1. Sign in to [Docker Home](https://app.docker.com/), then select
+   [Docker Scout](https://scout.docker.com/).
+1. Select your organization, then **Settings**.
+1. To manage what repositories are enabled for Docker Scout analysis, select
+   **Repository settings**. For more information, see
+   [repository settings](../../../scout/explore/dashboard.md#repository-settings).
+1. To manage access to Docker Scout for use on local images with Docker
+   Desktop, use
+   [Settings Management](../../../enterprise/security/hardened-desktop/settings-management/_index.md)
+   and set `sbomIndexing` to `false` to disable, or to `true` to enable.
+
+### Testcontainers Cloud access
+
+To initially set up and configure Testcontainers Cloud, sign in to
+[Testcontainers Cloud](https://app.testcontainers.cloud/) and follow the
+on-screen instructions.
+
+To manage access to Testcontainers Cloud:
+
+1. Sign in to the [Testcontainers Cloud](https://app.testcontainers.cloud/),
+   then select the menu icon.
+1. Select **Account**, then **Settings**.
+1. Choose **Lock access to Testcontainers Cloud**.
+
+### Docker Offload access
+
+> [!NOTE]
+>
+> Docker Offload isn't included in the core Docker subscription plans. To
+> make Docker Offload available, you must
+> [contact sales](https://www.docker.com/products/docker-offload/) and
+> subscribe.
+
+To manage Docker Offload access for your organization, use [Settings
+Management](../../../enterprise/security/hardened-desktop/settings-management/_index.md):
+
+1. Sign in to [Docker Home](https://app.docker.com/), then select **Docker
+   Desktop**.
+1. Select **Settings Management**.
+1. Configure the **Enable Docker Offload** setting to control whether
+   Docker Offload features are available in Docker Desktop. You can
+   configure this setting in five states:
+   - **Always enabled**: Docker Offload is always enabled and users cannot
+     disable it. The Offload toggle is always visible in the Docker Desktop
+     header. Recommended for VDI environments where local Docker execution
+     is not possible.
+   - **Enabled**: Docker Offload is enabled by default but users can
+     disable it in Docker Desktop settings. Suitable for hybrid
+     environments.
+   - **Disabled**: Docker Offload is disabled by default but users can
+     enable it in Docker Desktop settings.
+   - **Always disabled**: Docker Offload is disabled and users cannot
+     enable it. The option is visible but locked. Use when Docker Offload
+     is not approved for organizational use.
+   - **User defined**: No enforced default. Users choose whether to enable
+     or disable Docker Offload in their Docker Desktop settings.
+1. Select **Save**.
+
+For more details on Settings Management, see the [Settings
+reference](../../../enterprise/security/hardened-desktop/settings-management/settings-reference.md#enable-docker-offload).
+
+## Monitor product usage for your organization
+
+You can monitor usage for Docker products across your organization. Use the
+following table to learn where you can monitor organization usage:
+
+| Product              | Monitor usage                                                                                                                                                                                    |
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Docker Desktop       | From [Docker Home](https://app.docker.com/), view the [**Insights**](../../insights.md) page.                                                                                                    |
+| Docker Hub           | From Docker Hub, view the [**Usage** page](https://hub.docker.com/usage).                                                                                                                        |
+| Docker Build Cloud   | From [Docker Build Cloud](http://app.docker.com/build), view the **Build minutes** page.                                                                                                         |
+| Docker Scout         | From [Docker Home](https://app.docker.com/), select **Go to Scout** to view the [**Repository settings** page](https://scout.docker.com/settings/repos).                                         |
+| Testcontainers Cloud | From [Docker Home](https://app.docker.com/), select **Go to Testcontainers Cloud**, then select the menu icon. Go to the [**Billing** page](https://app.testcontainers.cloud/dashboard/billing). |
+| Docker Offload       | From [Docker Home](https://app.docker.com/), select **Offload**, then **Offload activity**. See [Docker Offload usage and billing](../../../offload/usage.md) for more details.                  |
+
+If your usage or seat count exceeds your subscription amount, you can
+[add seats](./manage-seats.md) or [view available Docker plans](../../../subscription/plans/_index.md) to meet your needs.
+
+## Next steps
+
+For more detailed information about each product, including how to set up
+and configure them, see the following manuals:
+
+- [Docker Desktop](../../../desktop/_index.md)
+- [Docker Hub](../../../docker-hub/_index.md)
+- [Docker Build Cloud](../../../build-cloud/_index.md)
+- [Docker Scout](../../../scout/_index.md)
+- [Testcontainers Cloud](https://testcontainers.com/cloud/docs/#getting-started)
+- [Docker Offload](../../../offload/_index.md)
diff --git a/content/manuals/admin/organization/manage/manage-seats.md b/content/manuals/admin/organization/manage/manage-seats.md
new file mode 100644
index 000000000000..c67156f5224a
--- /dev/null
+++ b/content/manuals/admin/organization/manage/manage-seats.md
@@ -0,0 +1,56 @@
+---
+title: Manage subscription seats
+linkTitle: Seats
+description: Add or remove seats for Docker Team and Business subscriptions
+keywords: manage seats, add seats, remove seats, subscription billing, team members
+aliases:
+  - /docker-hub/billing/add-seats/
+  - /subscription/add-seats/
+  - /docker-hub/billing/remove-seats/
+  - /subscription/remove-seats/
+  - /subscription/core-subscription/add-seats/
+  - /subscription/core-subscription/remove-seats/
+  - /subscription/manage-seats/
+weight: 40
+---
+
+You can add or remove seats from your Docker Team or Business subscription at any time to accommodate team changes. When you add seats mid-billing cycle, you're charged a prorated amount for the additional seats.
+
+> [!IMPORTANT]
+> If you have a sales-assisted Docker Business subscription,
+> contact your account manager to add or remove seats from your subscription.
+
+## Add seats to your subscription
+
+To add seats:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization.
+1. Select **Billing**.
+1. Select the action menu from the **Active Plans** tile, then choose **Add seats**.
+1. Follow the on-screen instructions to complete adding seats.
+   - You can't use pay by invoice for purchasing additional seats.
+   - You must use a card or US bank account.
+
+You can add more members to your organization. For more information, see [Manage organization members](./members.md).
+
+## Volume pricing
+
+Docker offers volume pricing for Docker Business subscriptions starting at 25 seats. Contact the <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_volume_pricing" class="link" rel="noopener">Docker Sales Team</a> for more information.
+
+## Remove seats from your subscription
+
+You can remove seats from your Team or Business subscription at any time. To remove seats:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization.
+1. Select **Billing**.
+1. Select the action menu, then choose **Remove seats**.
+1. Follow the on-screen instructions to complete removing seats.
+
+Changes apply to your next billing cycle, and unused portions aren't refundable.
+
+For example, if you're billed on the 8th of every month for 10 seats and remove 2 seats on the 15th, the 2 seats remain available until your next billing cycle. Your payment for 8 seats begins on the next billing cycle.
+
+> [!TIP]
+> You can cancel the removal of seats before your next billing cycle. To do so, select **Cancel change**.
diff --git a/content/manuals/admin/organization/manage/members.md b/content/manuals/admin/organization/manage/members.md
new file mode 100644
index 000000000000..f8fe6cf014e2
--- /dev/null
+++ b/content/manuals/admin/organization/manage/members.md
@@ -0,0 +1,255 @@
+---
+title: Manage organization members
+linkTitle: Members
+weight: 10
+description: Manage organization members, including invitations, roles, teams,
+  and member-list exports.
+keywords: members, organization members, invitations, teams, manage team
+  members, export member list, edit roles, user management
+aliases:
+  - /docker-hub/members/
+  - /admin/organization/members/
+---
+
+Manage organization invitations, member roles, teams, and member-list exports.
+
+## Invite members
+
+Owners can invite new members to an organization via Docker ID, email address,
+or with a CSV file containing email addresses. If an invitee doesn't have a
+Docker account, they must create one and verify their email address before
+they can accept an invitation to join the organization. When inviting members,
+their pending invitation occupies a seat.
+
+You can also select one or more product licenses for an invitee; Docker
+assigns available licenses when they accept. Unlike a seat, licenses aren't
+deducted from your organization's available licenses until the invitee accepts.
+See
+[Licenses and invites](/manuals/admin/organization/manage/manage-licenses.md#licenses-and-invites).
+
+### Invite members via Docker ID or email address
+
+Use the following steps to invite members to your organization via Docker ID
+or email address.
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+   organization from the top-left account drop-down.
+1. Select **Members**, then **Invite**.
+1. Select **Emails or usernames**.
+1. Follow the on-screen instructions to invite members. Invite a maximum of
+   1000 members and separate multiple entries by comma, semicolon, or space.
+
+When you invite members, you assign them a role. See
+[Roles and permissions](/manuals/enterprise/security/roles-and-permissions/_index.md)
+for details about the access permissions for each role.
+
+Pending invitations appear in the table. Invitees can accept or decline the
+invitation from the invitation email or the **Notifications Center**.
+
+### Invite members via CSV file
+
+To invite multiple members to an organization via a CSV file containing email
+addresses:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+   organization from the top-left account drop-down. Select **Members** >
+   **Invite** > **CSV upload**.
+1. Optional. Select **Download the template CSV file** to download an example
+   CSV file. The following is an example of the contents of a valid CSV file:
+
+   ```text
+   email
+   docker.user-0@example.com
+   docker.user-1@example.com
+   ```
+
+   The example file demonstrates CSV file requirements:
+   - The file must contain a header row with at least one heading named email.
+     Additional columns are allowed and are ignored in the import.
+   - The file must contain a maximum of 1000 email addresses (rows). To invite
+     more than 1000 users, create multiple CSV files and perform all steps in
+     this task for each file.
+
+1. Create a new CSV file or export a CSV file from another application.
+   - To export a CSV file from another application, see the application’s
+     documentation.
+   - To create a new CSV file, open a new file in a text editor, type email on
+     the first line, type the user email addresses one per line on the
+     following lines, and then save the file with a .csv extension.
+1. Select **Browse files** and then select your CSV file, or drag and drop the
+   CSV file into the **Select a CSV file to upload** box. You can only select
+   one CSV file at a time.
+1. After the CSV file has been uploaded, select **Review** to identify any
+   invalid email addresses, already invited users, invited users who are
+   already members, or duplicated email addresses within the same CSV file.
+1. Follow the on-screen instructions to invite members.
+
+Pending invitations appear in the table. Invitees can accept or decline the
+invitation from the invitation email or the **Notifications Center**.
+
+### Invite members via API
+
+You can bulk invite members using the Docker Hub API. For more information, see
+the [Bulk create invites](https://docs.docker.com/reference/api/hub/latest/#tag/invites/paths/~1v2~1invites~1bulk/post)
+API endpoint.
+
+## Accept invitation
+
+Users can accept or decline an invitation from the invitation email or the
+**Notifications Center**.
+
+To accept from the invitation email:
+
+1. Check your email inbox and open the Docker email with an invitation to
+   join the Docker organization.
+1. To open the link to Docker Hub, select the link in the invitation email.
+1. The Docker account creation page opens. If you already have an account,
+   select **Already have an account? Sign in**. If you don't have an account,
+   create one using the same email address you received the invitation
+   through.
+1. Optional. If you don't have an account and created one, you must navigate
+   back to your email inbox and verify your email address using the Docker
+   verification email.
+1. Once you are signed in to Docker Hub, select **My Hub** from the top-level
+   navigation menu.
+1. Select **Accept** on your invitation.
+
+To accept from the **Notifications Center**:
+
+1. Sign in to [Docker Hub](https://hub.docker.com/) or
+   [Docker Home](https://app.docker.com/).
+1. Open the **Notifications Center** in the header.
+1. Select **Accept** on the invitation.
+
+After accepting an invitation, you become a member of the organization.
+
+Invitation email links expire after 14 days. If your email link has expired,
+you can still accept from the **Notifications Center**.
+
+## Manage invitations
+
+After inviting members, you can resend or remove invitations as needed. Each
+invitee occupies one seat, so if the amount of email addresses in your CSV
+file exceeds the number of available seats in your organization, you won't be
+able to invite more members.
+
+> [!TIP]
+> Need to manage more than 1,000 team members?
+> [Upgrade to Docker Business for unlimited user invites](https://www.docker.com/pricing?ref=Docs&refAction=DocsAdminMembers)
+> and advanced role management. You can also
+> [add seats](/manuals/admin/organization/manage/manage-seats.md) to your
+> subscription.
+
+### Resend an invitation
+
+You can send individual invitations, or bulk invitations from the Admin
+Console.
+
+To resend an individual invitation:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization.
+1. Select **Members**.
+1. Select the **action menu** next to the invitee and select **Resend**.
+1. Select **Invite** to confirm.
+
+To bulk resend invitations:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization.
+1. Select **Members**.
+1. Use the **checkboxes** next to **Usernames** to bulk select users.
+1. Select **Resend invites**.
+1. Select **Resend** to confirm.
+
+### Remove an invitation
+
+To remove an invitation:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization.
+1. Select **Members**.
+1. Select the **action menu** next to the invitee and select
+   **Remove invitee**.
+1. Select **Remove** to confirm.
+
+## Manage members on a team
+
+Use Docker Hub or Docker Home to add or remove team members.
+Organization owners can add a member to one or more teams within an
+organization.
+
+### Add a member to a team
+
+To add a member to a team:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization.
+1. Select **Teams**.
+1. Select the team name.
+1. Select **Add member**. You can add the member by searching for their email
+   address or username.
+
+An invitee must first accept the invitation to join the organization before
+being added to the team.
+
+### Remove members from teams
+
+If your organization uses single sign-on (SSO) with
+[SCIM](/manuals/enterprise/security/provisioning/scim/_index.md) enabled, you
+should remove members from your identity provider (IdP). This automatically
+removes members from Docker. If SCIM is disabled, follow procedures in this
+doc to remove members manually in Docker.
+
+Organization owners can remove a member from a team. Removing the member from
+the team revokes their access to the permitted resources. To remove a member
+from a specific team:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization.
+1. Select **Teams**, then choose the name of the team member you want to
+   remove.
+1. Select the **X** next to the user's name to remove them from the team.
+1. When prompted, select **Remove** to confirm.
+
+### Update a member role
+
+Organization owners can manage
+[roles](/manuals/enterprise/security/roles-and-permissions/_index.md) within
+an organization. If an organization is part of a company, the company owner
+can also manage that organization's roles. If you have SSO enabled, you can
+use [SCIM for role mapping](/manuals/enterprise/security/provisioning/scim/_index.md).
+
+To update a member role:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization.
+1. Select **Members**.
+1. Find the username of the member whose role you want to edit. Select the
+   **Actions** menu, then **Edit role**.
+
+If you're the only owner of an organization and you want to edit your role,
+assign a new owner for your organization so you can edit your role.
+
+## Export members CSV file
+
+{{< summary-bar feature_name="Admin orgs" >}}
+
+Owners can export a CSV file containing all members. The CSV file for a company
+contains the following fields:
+
+- Name: The user's name
+- Username: The user's Docker ID
+- Email: The user's email address
+- Member of Organizations: All organizations the user is a member of within a
+  company
+- Invited to Organizations: All organizations the user is an invitee of within
+  a company
+- Account Created: The time and date when the user account was created
+
+To export a CSV file of your members:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization.
+1. Select **Members**.
+1. Select the **download** icon to export a CSV file of all members.
diff --git a/content/manuals/admin/organization/members.md b/content/manuals/admin/organization/members.md
deleted file mode 100644
index 536de693e38b..000000000000
--- a/content/manuals/admin/organization/members.md
+++ /dev/null
@@ -1,272 +0,0 @@
----
-title: Manage organization members
-weight: 30
-description: Learn how to manage organization members in Docker Hub and Docker Admin Console.
-keywords: members, teams, organizations, invite members, manage team members
-aliases:
-- /docker-hub/members/
----
-
-Learn how to manage members for your organization in Docker Hub and the Docker Admin Console.
-
-## Invite members
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-{{% admin-users product="admin" %}}
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-{{% admin-users product="hub" %}}
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Accept invitation
-
-When an invitation is to a user's email address, they receive
-a link to Docker Hub where they can accept or decline the invitation.
-To accept an invitation:
-
-1. Navigate to your email inbox and open the Docker email with an invitation to
-join the Docker organization.
-2. To open the link to Docker Hub, select the **click here** link.
-
-   > [!WARNING]
-   >
-   > Invitation email links expire after 14 days. If your email link has expired,
-   > you can sign in to [Docker Hub](https://hub.docker.com/) with the email
-   > address the link was sent to and accept the invitation from the
-   > **Notifications** panel.
-
-3. The Docker create an account page will open. If you already have an account, select **Already have an account? Sign in**.
-If you do not have an account yet, create an account using the same email
-address you received the invitation through.
-4. Optional. If you do not have an account and created one, you must navigate
-back to your email inbox and verify your email address using the Docker verification
-email.
-5. Once you are signed in to Docker Hub, select **My Hub** from the top-level navigation menu.
-6. Select **Accept** on your invitation.
-
-After accepting an invitation, you are now a member of the organization.
-
-## Manage invitations
-
-After inviting members, you can resend or remove invitations as needed.
-
-### Resend an invitation
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-To resend an invitation from the Admin Console:
-
-1. In the [Admin Console](https://app.docker.com/admin), select your organization.
-2. Select **Members**.
-3. Select the **action menu** next to the invitee and select **Resend invitation**.
-4. Select **Invite** to confirm.
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-To resend an invitation from Docker Hub:
-
-1. Sign in to [Docker Hub](https://hub.docker.com/).
-2. Select **My Hub**, your organization, and then **Members**.
-3. In the table, locate the invitee, select the **Actions** icon, and then select
-**Resend invitation**.
-4. Select **Invite** to confirm.
-
-You can also resend an invitation using the Docker Hub API. For more information,
-see the [Resend an invite](https://docs.docker.com/reference/api/hub/latest/#tag/invites/paths/~1v2~1invites~1%7Bid%7D~1resend/patch) API endpoint.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Remove an invitation
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-To remove an invitation from the Admin Console:
-
-1. In the [Admin Console](https://app.docker.com/admin), select your organization.
-2. Select **Members**.
-3. Select the **action menu** next to the invitee and select **Remove invitee**.
-4. Select **Remove** to confirm.
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-To remove a member's invitation from Docker Hub:
-
-1. Sign in to [Docker Hub](https://hub.docker.com/).
-2. Select **My Hub**, your organization, and then **Members**.
-3. In the table, select the **Action** icon, and then select **Remove member** or **Remove invitee**.
-4. Follow the on-screen instructions to remove the member or invitee.
-
-You can also remove an invitation using the Docker Hub API. For more information,
-see the [Cancel an invite](https://docs.docker.com/reference/api/hub/latest/#tag/invites/paths/~1v2~1invites~1%7Bid%7D/delete) API endpoint.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Manage members on a team
-
-Use Docker Hub or the Admin Console to add or remove team members. Organization owners can add a member to one or more teams within an organization.
-
-### Add a member to a team
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-To add a member to a team with the Admin Console:
-
-1. In the [Admin Console](https://app.docker.com/admin), select your organization.
-2. Select the team name.
-3. Select **Add member**. You can add the member by searching for their email address or username.
-
-   > [!NOTE]
-   >
-   > An invitee must first accept the invitation to join the organization before being added to the team.
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-To add a member to a team with Docker Hub:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select **My Hub**, your organization, and then **Members**.
-3. Select the **Action** icon, and then select **Add to team**.
-
-   > [!NOTE]
-   >
-   > You can also navigate to **My Hub** > **Your Organization** > **Teams** > **Your Team Name** and select **Add Member**. Select a member from the drop-down list to add them to the team or search by Docker ID or email.
-4. Select the team and then select **Add**.
-
-   > [!NOTE]
-   >
-   > An invitee must first accept the invitation to join the organization before being added to the team.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Remove a member from a team
-
-> [!NOTE]
->
-> If your organization uses single sign-on (SSO) with [SCIM](/manuals/security/for-admins/provisioning/scim.md) enabled, you should remove members from your identity provider (IdP). This will automatically remove members from Docker. If SCIM is disabled, you must manually manage members in Docker.
-
-Organization owners can remove a member from a team in Docker Hub or Admin Console. Removing the member from the team will revoke their access to the permitted resources.
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-To remove a member from a specific team with the Admin Console:
-
-1. In the [Admin Console](https://app.docker.com/admin), select your organization.
-2. Select the team name.
-3. Select the **X** next to the user's name to remove them from the team.
-4. When prompted, select **Remove** to confirm.
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-To remove a member from a specific team with Docker Hub:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select **My Hub**, your organization, **Teams**, and then the team.
-3. Select the **X** next to the user’s name to remove them from the team.
-4. When prompted, select **Remove** to confirm.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Update a member role
-
-Organization owners can manage [roles](/security/for-admins/roles-and-permissions/)
-within an organization. If an organization is part of a company,
-the company owner can also manage that organization's roles. If you have SSO enabled, you can use [SCIM for role mapping](/security/for-admins/provisioning/scim/).
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-To update a member role in the Admin Console:
-
-1. In the [Admin Console](https://app.docker.com/admin), select your organization.
-2. Select the **Members** tab.
-3. Find the username of the member whose role you want to edit. Select the
-**Actions menu**, then **Edit role**.
-
-> [!NOTE]
->
-> If you're the only owner of an organization,
-> you need to assign a new owner before you can edit your role.
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-To update a member role in Docker Hub:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select **My Hub**, your organization, and then **Members**.
-3. Find the username of the member whose role you want to edit. In the table, select the **Actions** icon.
-4. Select **Edit role**.
-5. Select their organization, select the role you want to assign, and then select **Save**.
-
-> [!NOTE]
->
-> If you're the only owner of an organization,
-> you need to assign a new owner before you can edit your role.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Export members CSV file
-
-{{< summary-bar feature_name="Admin orgs" >}}
-
-Owners can export a CSV file containing all members. The CSV file for a company contains the following fields:
-- Name: The user's name
-- Username: The user's Docker ID
-- Email: The user's email address
-- Member of Organizations: All organizations the user is a member of within a company
-- Invited to Organizations: All organizations the user is an invitee of within a company
-- Account Created: The time and date when the user account was created
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-To export a CSV file of your members:
-
-1. In the [Admin Console](https://app.docker.com/admin), select your organization.
-2. Select **Members**.
-3. Select the **download** icon to export a CSV file of all members.
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-To export a CSV file of your members:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select **My Hub**, your organization, and then **Members**.
-3. Select the **Action** icon and then select **Export users as CSV**.
-
-{{< /tab >}}
-{{< /tabs >}}
\ No newline at end of file
diff --git a/content/manuals/admin/organization/onboard.md b/content/manuals/admin/organization/onboard.md
deleted file mode 100644
index 6fa0cf1936d1..000000000000
--- a/content/manuals/admin/organization/onboard.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-title: Onboard your organization
-weight: 20
-description: Get started onboarding your Docker Team or Business organization.
-keywords: business, team, organizations, get started, onboarding
-toc_min: 1
-toc_max: 3
-aliases:
-- /docker-hub/onboard/
-- /docker-hub/onboard-team/
-- /docker-hub/onboard-business/
----
-
-{{< summary-bar feature_name="Admin orgs" >}}
-
-Learn how to onboard your organization using Docker Hub or the Docker Admin Console.
-
-Onboarding your organization lets administrators gain visibility into user activity and enforce security settings. In addition, members of your organization receive increased pull limits and other organization wide benefits. For more details, see [Docker subscriptions and features](../../subscription/details.md).
-
-In this guide, you'll learn how to do the following:
-
-- Identify your users to help you efficiently allocate your subscription seats
-- Invite members and owners to your organization
-- Secure authentication and authorization for your organization using Single Sign-On (SSO) and System for Cross-domain Identity Management (SCIM)
-- Enforce sign-on for Docker Desktop to ensure security best practices
-
-## Prerequisites
-
-Before you start onboarding your organization, ensure that you:
-
-- Have a Docker Team or Business subscription. See [Docker Pricing](https://www.docker.com/pricing/) for details.
-
-  > [!NOTE]
-  >
-  > When purchasing a self-serve subscription, the on-screen instructions guide you through creating an organization. If you have purchased a subscription through Docker Sales and you have not yet created an organization, see [Create an organization](/admin/organization/orgs).
-
-- Familiarize yourself with Docker concepts and terminology in the [administration overview](../_index.md) and [FAQs](/faq/admin/general-faqs/).
-
-## Onboard with guided setup
-
-The Admin Console has a guided setup to help you easily
-onboard your organization. The guided setup steps consist of basic onboarding
-tasks. If you want to onboard outside of the guided setup,
-see [Recommended onboarding steps](/manuals/admin/organization/onboard.md#recommended-onboarding-steps).
-
-To onboard using the guided setup,
-navigate to the [Admin Console](https://app.docker.com) and
-select **Guided setup** in the left-hand navigation.
-
-The guided setup walks you through the following onboarding steps:
-
-- **Invite your team**: Invite owners and members.
-- **Manage user access**: Add and verify a domain, manage users with SSO, and
-enforce Docker Desktop sign-in.
-- **Docker Desktop security**: Configure image access management, registry access
-management, and settings management.
-
-## Recommended onboarding steps
-
-### Step one: Identify your Docker users
-
-Identifying your users helps you allocate seats efficiently and ensures they
-receive your Docker subscription benefits.
-
-1. Identify the Docker users in your organization.
-   - If your organization uses device management software, like MDM or Jamf, you can use the device management software to help identify Docker users. See your device management software's documentation for details. You can identify Docker users by checking if Docker Desktop is installed at the following location on each user's machine:
-      - Mac: `/Applications/Docker.app`
-      - Windows: `C:\Program Files\Docker\Docker`
-      - Linux: `/opt/docker-desktop`
-   - If your organization doesn't use device management software or your users haven't installed Docker Desktop yet, you can survey your users.
-2. Ask users to update their Docker account email to one in your organization’s domain, or create a new account with that email.
-   - To update an account's email address, instruct your users to sign in to [Docker Hub](https://hub.docker.com), and update the email address to their email address in your organization's domain.
-   - To create a new account, instruct your users to go [sign up](https://hub.docker.com/signup) using their email address in your organization's domain.
-3. Ask your Docker sales representative or [contact sales](https://www.docker.com/pricing/contact-sales/) to get a list of Docker accounts that use an email address in your organization's domain.
-
-### Step two: Invite owners
-
-When you create an organization, you are the only owner. It is optional to add additional owners. Owners can help you onboard and manage your organization.
-
-To add an owner, invite a user and assign them the owner role. For more details, see [Invite members](/admin/organization/members/).
-
-### Step three: Invite members
-
-When you add users to your organization, you gain visibility into their activity and you can enforce security settings. In addition, members of your organization receive increased pull limits and other organization wide benefits.
-
-To add a member, invite a user and assign them the member role. For more details, see [Invite members](/admin/organization/members/).
-
-### Step four: Manage user access with SSO and SCIM
-
-Configuring SSO and SCIM is optional and only available to Docker Business subscribers. To upgrade a Docker Team subscription to a Docker Business subscription, see [Upgrade your subscription](/subscription/upgrade/).
-
-Use your identity provider (IdP) to manage members and provision them to Docker
-automatically via SSO and SCIM. See the following for more details:
-
-   - [Configure SSO](/manuals/security/for-admins/single-sign-on/configure.md) to authenticate and add members when they sign in to Docker through your identity provider.
-   - Optional. [Enforce SSO](/manuals/security/for-admins/single-sign-on/connect.md) to ensure that when users sign in to Docker, they must use SSO.
-
-     > [!NOTE]
-     >
-     > Enforcing single sign-on (SSO) and enforcing Docker Desktop sign in
-     are different features. For more details, see
-     > [Enforcing sign-in versus enforcing single sign-on (SSO)](/security/for-admins/enforce-sign-in/#enforcing-sign-in-versus-enforcing-single-sign-on-sso).
-
-   - [Configure SCIM](/security/for-admins/provisioning/scim/) to automatically provision, add, and de-provision members to Docker through your identity provider.
-
-### Step five: Enforce sign-in for Docker Desktop
-
-By default, members of your organization can use Docker Desktop without signing
-in. When users don’t sign in as a member of your organization, they don’t
-receive the [benefits of your organization’s subscription](../../subscription/details.md) and they can circumvent [Docker’s security features](/security/for-admins/hardened-desktop/).
-
-There are multiple ways you can enforce sign-in, depending on your company's setup and preferences:
-- [Registry key method (Windows only)](/security/for-admins/enforce-sign-in/methods/#registry-key-method-windows-only)
-- [`.plist` method (Mac only)](/security/for-admins/enforce-sign-in/methods/#plist-method-mac-only)
-- [`registry.json` method (All)](/security/for-admins/enforce-sign-in/methods/#registryjson-method-all)
-
-### Step six: Manage Docker Desktop security
-
-Docker offers the following security features to manage your organization's
-security posture:
-
-- [Image Access Management](/manuals/security/for-admins/hardened-desktop/image-access-management.md): Control which types of images your developers can pull from Docker Hub.
-- [Registry Access Management](/manuals/security/for-admins/hardened-desktop/registry-access-management.md): Define which registries your developers can access.
-- [Settings management](/manuals/security/for-admins/hardened-desktop/settings-management.md): Set and control Docker Desktop settings for your users.
-
-## What's next
-
-- [Manage Docker products](./manage-products.md) to configure access and view usage.
-- Configure [Hardened Docker Desktop](/desktop/hardened-desktop/) to improve your organization’s security posture for containerized development.
-- [Audit your domains](/docker-hub/domain-audit/) to ensure that all Docker users in your domain are part of your organization.
-
-Your Docker subscription provides many more additional features. To learn more, see [Docker subscriptions and features](/subscription/details/).
\ No newline at end of file
diff --git a/content/manuals/admin/organization/organization-faqs.md b/content/manuals/admin/organization/organization-faqs.md
new file mode 100644
index 000000000000..e013e5539d7e
--- /dev/null
+++ b/content/manuals/admin/organization/organization-faqs.md
@@ -0,0 +1,72 @@
+---
+title: Organization FAQs
+linkTitle: FAQs
+weight: 60
+description: Organization FAQs
+keywords: Docker, Docker Hub, SSO FAQs, single sign-on, organizations, administration, Docker Home, members, organization management, manage orgs
+tags: [FAQ]
+aliases:
+  - /docker-hub/organization-faqs/
+  - /faq/admin/organization-faqs/
+  - /admin/faqs/organization-faqs/
+---
+
+### How can I see how many active users are in my organization?
+
+If your organization uses a Software Asset Management tool, you can use it to
+find out how many users have Docker Desktop installed. If your organization
+doesn't use this software, you can run an internal survey
+to find out who is using Docker Desktop.
+
+For more information, see [Identify your Docker users and their Docker accounts](../../admin/organization/setup/onboard.md#step-one-identify-your-docker-users).
+
+### Do users need to authenticate with Docker before an owner can add them to an organization?
+
+No. Organization owners can invite users with their email addresses, and also
+assign them to a team during the invite process.
+
+### Can I force my organization's members to authenticate before using Docker Desktop and are there any benefits?
+
+Yes. You can
+[enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md).
+
+Some benefits of enforcing sign-in are:
+
+- Ensures users receive the benefits of your subscription.
+- Ensures security features like [Image Access Management](/manuals/enterprise/security/hardened-desktop/image-access-management.md) and [Registry Access Management](/manuals/enterprise/security/hardened-desktop/registry-access-management.md) are applied.
+- Ensures you gain insights into users' activity.
+
+### Can I convert my personal Docker ID to an organization account?
+
+Yes. You can convert your user account to an organization account. Once you
+convert a user account into an organization, it's not possible to
+revert it to a personal user account.
+
+For prerequisites and instructions, see
+[Convert an account into an organization](setup/convert-account.md).
+
+### Do organization invitees take up seats?
+
+Yes. A user invited to an organization will take up one of the provisioned
+seats, even if that user hasn’t accepted their invitation yet.
+
+To manage invites, see [Manage organization members](/manuals/admin/organization/manage/members.md).
+
+### Do organization owners take a seat?
+
+Yes. Organization owners occupy a seat.
+
+### What is the difference between user, invitee, seat, and member?
+
+- User: Docker user with a Docker ID.
+- Invitee: A user that an administrator has invited to join an organization but
+  has not yet accepted their invitation.
+- Seats: The number of purchased seats in an organization.
+- Member: A user who has received and accepted an invitation to join an
+  organization. Member can also refer to a member of a team within an
+  organization.
+
+### If I have two organizations and a user belongs to both organizations, do they take up two seats?
+
+Yes. In a scenario where a user belongs to two organizations, they take up one
+seat in each organization.
diff --git a/content/manuals/admin/organization/orgs.md b/content/manuals/admin/organization/orgs.md
deleted file mode 100644
index ef048a8a0c9c..000000000000
--- a/content/manuals/admin/organization/orgs.md
+++ /dev/null
@@ -1,191 +0,0 @@
----
-title: Create your organization
-weight: 10
-description: Learn how to create an organization.
-keywords: Docker, docker, registry, teams, organizations, plans, Dockerfile, Docker
-  Hub, docs, documentation
-aliases:
-- /docker-hub/orgs/
----
-
-{{< summary-bar feature_name="Admin orgs" >}}
-
-This section describes how to create an organization. Before you begin:
-
-- You need a [Docker ID](/accounts/create-account/)
-- Review the [Docker subscriptions and features](../../subscription/details.md) to determine what plan to choose for your organization
-
-## Create an organization
-
-There are multiple ways to create an organization. You can either:
-- Create a new organization using the **Create Organization** option in Docker Hub
-- Convert an existing user account to an organization
-
-The following section contains instructions on how to create a new organization. For prerequisites and
-detailed instructions on converting an existing user account to an organization, see
-[Convert an account into an organization](/manuals/admin/organization/convert-account.md).
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-To create an organization:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Go to Admin Console**.
-3. Select the **Organization** drop-down in the left-hand navigation and then **Create Organization**.
-4. Choose a plan for your organization, a billing cycle, and specify how many seats you need. See [Docker Pricing](https://www.docker.com/pricing/) for details on the features offered in the Team and Business plan.
-5. Select **Continue to profile**.
-6. Enter an **Organization namespace**. This is the official, unique name for
-your organization in Docker Hub. It's not possible to change the name of the
-organization after you've created it.
-
-   > [!NOTE]
-   >
-   > You can't use the same name for the organization and your Docker ID. If you want to use your Docker ID as the organization name, then you must first [convert your account into an organization](/manuals/admin/organization/convert-account.md).
-
-7. Enter your **Company name**. This is the full name of your company. Docker
-displays the company name on your organization page and in the details of any
-public images you publish. You can update the company name anytime by navigating
-to your organization's **Settings** page.
-8. Select **Continue to billing** to continue.
-9. Enter your organization's billing information and select **Continue to payment** to continue to the billing portal.
-10. Provide your card details and select **Purchase**.
-
-You've now created an organization.
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-1. Sign in to [Docker Hub](https://hub.docker.com/) using your Docker ID, your email address, or your social provider.
-2. Select **My Hub**, select the account drop-down, and then **Create Organization** to create a new organization.
-3. Choose a plan for your organization, a billing cycle, and specify how many seats you need. See [Docker Pricing](https://www.docker.com/pricing/) for details on the features offered in the Team and Business plan.
-4. Select **Continue to profile**.
-5. Enter an **Organization namespace**. This is the official, unique name for
-your organization in Docker Hub. It's not possible to change the name of the
-organization after you've created it.
-
-   > [!NOTE]
-   >
-   > You can't use the same name for the organization and your Docker ID. If you want to use your Docker ID as the organization name, then you must first [convert your account into an organization](/manuals/admin/organization/convert-account.md).
-
-6. Enter your **Company name**. This is the full name of your company. Docker
-displays the company name on your organization page and in the details of any
-public images you publish. You can update the company name anytime by navigating
-to your organization's **Settings** page.
-7. Select **Continue to billing** to continue.
-8. Enter your organization's billing information and select **Continue to payment** to continue to the billing portal.
-9. Provide your card details and select **Purchase**.
-
-You've now created an organization.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## View an organization
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-To view an organization in the Admin Console:
-
-1. Sign in to [Docker Home](https://app.docker.com).
-2. Under Settings and administration, select **Go to Admin Console**.
-3. Select your organization from the **Organization** drop-down in the left-hand navigation.
-
-The Admin Console displays various options that let you to
-configure your organization.
-
-- **Members**: Displays a list of team members. You
-  can invite new members using the **Invite members** button. See [Manage members](./members.md) for details.
-
-- **Teams**: Displays a list of existing teams and the number of
-  members in each team. See [Create a team](./manage-a-team.md) for details.
-
-- **Activity** Displays the audit logs, a chronological list of activities that
-  occur at organization and repository levels. It provides the org owners a
-  report of all their team member activities. See [Audit logs](./activity-logs.md) for
-  details.
-
-- **Security and access**: Manage security settings. For more information, see [Security](/manuals/security/_index.md).
-
-- **Organization settings**: Update general settings, manage your company settings, or [deactivate your organization](/manuals/admin/organization/deactivate-account.md).
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-To view an organization:
-
-1. Sign in to [Docker Hub](https://hub.docker.com) with a user account that is a member of any team in the organization.
-
-      > [!NOTE]
-      >
-      > You can't *directly* sign in to an organization. This is especially
-      > important to note if you create an organization by
-      [converting a user account](/manuals/admin/organization/convert-account.md), as conversion means you lose the ability to log into that
-      > "account", since it no longer exists. To view the organization you
-      > need to sign in with the new owner account assigned during the
-      > conversion or another account that was added as a member. If you
-      > don't see the organization after logging in,
-      > then you are neither a member or an owner of it. An organization
-      > administrator needs to add you as a member of the organization.
-
-2. Select **My Hub** in the top navigation bar, then choose your
-   organization from the list.
-
-The organization landing page displays various options that let you to
-configure your organization.
-
-- **Members**: Displays a list of team members. You
-  can invite new members using the **Invite members** button. See [Manage members](./members.md) for details.
-
-- **Teams**: Displays a list of existing teams and the number of
-  members in each team. See [Create a team](./manage-a-team.md) for details.
-
-- **Repositories**: Displays a list of repositories associated with the
-  organization. See [Repositories](../../docker-hub/repos/_index.md) for detailed information about
-  working with repositories.
-
-- **Activity** Displays the audit logs, a chronological list of activities that
-  occur at organization and repository levels. It provides the org owners a
-  report of all their team member activities. See [Audit logs](./activity-logs.md) for
-  details.
-
-- **Settings**: Displays information about your
-  organization, and you to view and change your repository privacy
-  settings, configure org permissions such as
-  [Image Access Management](/manuals/security/for-admins/hardened-desktop/image-access-management.md), configure notification settings, and [deactivate](/manuals/admin/organization/deactivate-account.md#deactivate-an-organization) You can also update your organization name and company name that appear on your organization landing page. You must be an owner to access the
-   organization's **Settings** page.
-
-- **Billing**: Displays information about your existing
-[Docker subscription (plan)](../../subscription/_index.md), including the number of seats and next payment due date. For how to access the billing history and payment methods for your organization, see [View billing history](../../billing/history.md).
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Merge organizations
-
-> [!WARNING]
->
-> If you are merging organizations, it is recommended to do so at the *end* of
-> your billing cycle. When you merge an organization and downgrade another, you
-> will lose seats on your downgraded organization. Docker does not offer
-> refunds for downgrades.
-
-If you have multiple organizations that you want to merge into one, complete the following:
-
-1. Based on the number of seats from the secondary organization, [purchase additional seats](../../subscription/manage-seats.md) for the primary organization account that you want to keep.
-2. Manually add users to the primary organization and remove existing users from the secondary organization.
-3. Manually move over your data, including all repositories.
-4. Once you're done moving all of your users and data, [downgrade](../../subscription/change.md) the secondary account to a free subscription. Note that Docker does not offer refunds for downgrading organizations mid-billing cycle.
-
-> [!TIP]
->
-> If your organization has a Docker Business subscription with a purchase order, contact Support or your Account Manager at Docker.
-
-## More resources
-
-- [Video: Docker Hub Organizations](https://www.youtube.com/watch?v=WKlT1O-4Du8)
diff --git a/content/manuals/admin/organization/setup/_index.md b/content/manuals/admin/organization/setup/_index.md
new file mode 100644
index 000000000000..eb36ef60da67
--- /dev/null
+++ b/content/manuals/admin/organization/setup/_index.md
@@ -0,0 +1,57 @@
+---
+title: Set up your organization
+linkTitle: Setup
+weight: 10
+description: Learn how to set up your Docker organization, including creating an organization, onboarding, and configuring settings.
+keywords: set up organization, create organization, onboard, convert account, organization settings, docker home
+grid:
+  - title: Create your organization
+    description: Create an organization to group teams and members and assign access.
+    icon: building-storefront
+    link: /admin/organization/setup/orgs/
+  - title: Onboard your organization
+    description: Onboard and secure your Docker Team or Business organization.
+    icon: magnifying-glass-plus
+    link: /admin/organization/setup/onboard/
+  - title: Change information
+    description: Update your organization's general information and settings.
+    icon: pencil-square
+    link: /admin/organization/setup/general-settings/
+  - title: Convert account
+    description: Convert an existing Docker user account into an organization.
+    icon: arrows-right-left
+    link: /admin/organization/setup/convert-account/
+  - title: Manage your organization
+    description: Add members, teams, licenses, and seats after setup.
+    icon: user-group
+    link: /admin/organization/manage/
+  - title: Security
+    description: Configure single sign-on, provisioning, and access management.
+    icon: shield-check
+    link: /enterprise/security/
+---
+
+Before you manage members and access, set up your Docker organization. You can
+create an organization, onboard and secure it, update its information, or convert
+an existing user account into an organization.
+
+## Setting up your organization
+
+You set up your organization from [Docker Home](https://app.docker.com) and
+must be assigned the
+[organization owner role](/manuals/enterprise/security/roles-and-permissions/_index.md).
+Setting up an organization happens in broad phases:
+
+1. You can create a new organization, or convert an existing user account
+   into one. Choose the option that fits how you already use Docker. You
+   don't need both.
+1. After creating your organization, you must onboard it by inviting members,
+   securing authentication, and enforcing sign-in. These steps build on each
+   other, so follow them in order.
+1. You can update your organization's general information whenever it changes.
+
+## Next steps
+
+Explore the following sections to set up your organization.
+
+{{< grid >}}
diff --git a/content/manuals/admin/organization/setup/convert-account.md b/content/manuals/admin/organization/setup/convert-account.md
new file mode 100644
index 000000000000..7c5b856d5bfc
--- /dev/null
+++ b/content/manuals/admin/organization/setup/convert-account.md
@@ -0,0 +1,81 @@
+---
+description: Convert your Docker Hub user account into an organization
+linkTitle: Convert account
+title: Convert an account into an organization
+keywords: docker hub, hub, organization, convert account, migrate account
+weight: 40
+aliases:
+  - /docker-hub/convert-account/
+  - /admin/organization/convert-account/
+---
+
+{{< summary-bar feature_name="Admin orgs" >}}
+
+Learn how to convert an existing user account into an organization. This is
+useful if you need multiple users to access your account and the repositories
+it’s connected to. Converting it to an organization gives you better control
+over permissions for these users through
+[teams](/manuals/admin/organization/manage/manage-a-team.md) and
+[roles](/manuals/enterprise/security/roles-and-permissions.md).
+
+When you convert a user account to an organization, the account is migrated to
+a Docker Team subscription by default.
+
+## Prerequisites
+
+Before you convert a user account to an organization, ensure that you meet the following requirements:
+
+- The user account that you want to convert must not be a member of a company or any teams or organizations. You must remove the account from all teams, organizations, or the company.
+
+  To do this:
+  1. Navigate to **My Hub** and then select the organization you need to leave.
+  1. Find your username in the **Members** tab.
+  1. Select the **More options** menu and then select **Leave organization**.
+
+  If the user account is the sole owner of any organization or company, assign another user the owner role and then remove yourself from the organization or company.
+
+- You must have a separate Docker ID ready to assign as the owner of the organization during conversion.
+
+  If you want to convert your user account into an organization account and you don't have any other user accounts, you need to create a new user account to assign it as the owner of the new organization. With the owner role assigned, this user account has full administrative access to configure and manage the organization. You can assign more users the owner role after the conversion.
+
+## What happens when you convert your account
+
+The following happens when you convert your account into
+an organization:
+
+- This process removes the email address for the account. Notifications are
+  instead sent to organization owners. You'll be able to reuse the
+  removed email address for another account after converting.
+- The current subscription will automatically cancel and your new subscription
+  will start.
+- Repository namespaces and names won't change, but converting your account
+  removes any repository collaborators. Once you convert the account, you'll need
+  to add repository collaborators as team members.
+- Existing automated builds appear as if they were set up by the first owner
+  added to the organization.
+- The user account that you add as the first owner will have full
+  administrative access to configure and manage the organization.
+- To transfer a user's personal access tokens (PATs) to your converted
+  organization, you must designate the user as an organization owner. This will
+  ensure any PATs associated with the user's account are transferred to the
+  organization owner.
+
+## Convert an account into an organization
+
+> [!IMPORTANT]
+>
+> Converting an account into an organization is permanent. Back up any data
+> or settings you want to retain.
+
+1. Sign in to [Docker Home](https://app.docker.com/).
+1. Select your avatar in the top-right corner to open the drop-down.
+1. From **Account settings**, select **Convert**.
+1. Review the warning displayed about converting a user account. This action
+   cannot be undone and has considerable implications for your assets and the
+   account.
+1. Enter a **Username of new owner** to set an organization owner. The new
+   Docker ID you specify becomes the organization’s owner. You cannot use the
+   same Docker ID as the account you are trying to convert. The Docker ID is
+   case-sensitive.
+1. Select **Confirm**. The new owner receives a notification email. Use that
+   owner account to sign in and manage the new organization.
diff --git a/content/manuals/admin/organization/setup/general-settings.md b/content/manuals/admin/organization/setup/general-settings.md
new file mode 100644
index 000000000000..3c7d4c9b2e04
--- /dev/null
+++ b/content/manuals/admin/organization/setup/general-settings.md
@@ -0,0 +1,39 @@
+---
+title: Change general organization information
+linkTitle: Change information
+weight: 30
+description: Learn how to manage settings for organizations.
+keywords: organization, settings, Docker Home, manage, Docker organization, Gravatar, SCIM, SSO setup, domain management, organization settings
+aliases:
+  - /admin/organization/general-settings/
+---
+
+Learn how to update your organization information.
+
+## Update organization information
+
+General organization information appears on your organization landing page.
+
+This information includes:
+
+- Organization Name
+- Company
+- Location
+- Website
+- Gravatar email: To add an avatar to your Docker account, create a [Gravatar account](https://gravatar.com/) and upload an avatar. Next, add your Gravatar email to your Docker account settings. It may take some time for your avatar to update in Docker.
+
+To edit this information:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+   organization from the top-left account drop-down.
+1. Select **Organization settings**.
+1. Enter or update your organization’s details, then select **Save**.
+
+## Next steps
+
+After configuring your organization information, you can:
+
+- [Configure single sign-on (SSO)](/manuals/enterprise/security/single-sign-on/connect.md)
+- [Set up SCIM provisioning](/manuals/enterprise/security/provisioning/scim/_index.md)
+- [Manage domains](/manuals/enterprise/security/domain-management.md)
+- [Create a company](/manuals/admin/company/new-company.md)
diff --git a/content/manuals/admin/organization/setup/onboard.md b/content/manuals/admin/organization/setup/onboard.md
new file mode 100644
index 000000000000..e71216f1bff7
--- /dev/null
+++ b/content/manuals/admin/organization/setup/onboard.md
@@ -0,0 +1,178 @@
+---
+title: Onboard your organization
+linkTitle: Onboard
+weight: 20
+description: Get started onboarding your Docker Team or Business organization.
+keywords: business, team, organizations, get started, onboarding, Docker Home, organization management,
+toc_min: 1
+toc_max: 3
+aliases:
+  - /docker-hub/onboard/
+  - /docker-hub/onboard-team/
+  - /docker-hub/onboard-business/
+  - /admin/organization/onboard/
+---
+
+{{< summary-bar feature_name="Admin orgs" >}}
+
+Learn how to onboard your organization.
+
+Onboarding your organization includes:
+
+- Identifying users to help you allocate your subscription seats
+- Invite members and owners to your organization
+- Secure authentication and authorization for your organization
+- Enforce sign-in for Docker Desktop to ensure security best practices
+
+These actions help administrators gain visibility into user activity and
+enforce security settings. Organization members also receive increased pull
+limits and other benefits when they are signed in.
+
+## Prerequisites
+
+Before you start onboarding your organization, ensure you:
+
+- Have a Docker Team or Business subscription. For more details, see
+  [Docker subscriptions and features](https://www.docker.com/pricing?ref=Docs&refAction=DocsAdminOnboard).
+
+  > [!NOTE]
+  >
+  > When purchasing a self-serve subscription, the on-screen instructions
+  > guide you through creating an organization. If you have purchased a
+  > subscription through Docker Sales and you have not yet created an
+  > organization, see [Create an organization](/manuals/admin/organization/setup/orgs.md).
+
+- Familiarize yourself with Docker concepts and terminology in
+  the [administration overview](../../_index.md).
+
+## Onboard with guided setup
+
+Docker Home has a guided setup to help you
+onboard your organization. The guided setup's steps consist of basic onboarding
+tasks. If you want to onboard outside of the guided setup,
+see [Recommended onboarding steps](/manuals/admin/organization/setup/onboard.md#recommended-onboarding-steps).
+
+To onboard using the guided setup,
+navigate to [Docker Home](https://app.docker.com) and
+select **Guided setup** in the left-hand navigation.
+
+The guided setup walks you through the following onboarding steps:
+
+- **Invite your team**: Invite owners and members.
+- **Manage user access**: Add and verify a domain, manage users with SSO, and
+  enforce Docker Desktop sign-in.
+- **Docker Desktop security**: Configure image access management, registry
+  access management, and settings management.
+
+## Recommended onboarding steps
+
+### Step one: Identify your Docker users
+
+Identifying your users helps you allocate seats efficiently and ensures they
+receive your Docker subscription benefits.
+
+1. Identify the Docker users in your organization.
+   - If your organization uses device management software, like MDM or Jamf,
+     you can use the device management software to help identify Docker users.
+     See your device management software's documentation for details. You can
+     identify Docker users by checking if Docker Desktop is installed at the
+     following location on each user's machine:
+     - Mac: `/Applications/Docker.app`
+     - Windows: `C:\Program Files\Docker\Docker`(all-user installation) or `%LOCALAPPDATA%\Programs\DockerDesktop` (per-user installation (Beta))
+     - Linux: `/opt/docker-desktop`
+   - If your organization doesn't use device management software or your
+     users haven't installed Docker Desktop yet, you can survey your users to
+     identify who is using Docker Desktop.
+1. Ask users to update their Docker account's email address to one associated
+   with your organization's domain, or create a new account with that email.
+   - To update an account's email address, instruct your users to sign in
+     to [Docker Hub](https://hub.docker.com), and update the email address to
+     their email address in your organization's domain.
+   - To create a new account, instruct your users to
+     [sign up](https://hub.docker.com/signup) using their email address associated
+     with your organization's domain. Ensure your users verify their email address.
+1. Identify Docker accounts associated with your organization's domain:
+   - Ask your Docker sales representative or
+     <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_org_onboarding" class="link" rel="noopener">contact sales</a> to get a list
+     of Docker accounts that use an email address in your organization's domain.
+
+### Step two: Invite owners
+
+Owners can help you onboard and manage your organization.
+
+When you create an organization, you are the only owner. It is optional to
+add additional owners.
+
+To add an owner, invite a user and assign them the owner role. For more
+details, see [Invite members](/manuals/admin/organization/manage/members.md) and
+[Roles and permissions](/manuals/enterprise/security/roles-and-permissions.md).
+
+### Step three: Invite members
+
+When you add users to your organization, you gain visibility into their
+activity and you can enforce security settings. Your members also
+receive increased pull limits and other organization wide benefits when
+they are signed in.
+
+To add a member, invite a user and assign them the member role.
+For more details, see [Invite members](/manuals/admin/organization/manage/members.md) and
+[Roles and permissions](/manuals/enterprise/security/roles-and-permissions.md).
+
+### Step four: Manage user access with SSO and SCIM
+
+Configuring SSO and SCIM is optional and only available to Docker Business
+subscribers. To upgrade a Docker Team subscription to a Docker Business
+subscription, see [Upgrade a plan](/manuals/subscription/manage.md#upgrade-plans).
+
+Use your identity provider (IdP) to manage members and provision them to Docker
+automatically via SSO and SCIM. See the following for more details:
+
+- [Configure SSO](/manuals/enterprise/security/single-sign-on/connect.md)
+  to authenticate and add members when they sign in to Docker through your
+  identity provider.
+- Optional.
+  [Enforce SSO](/manuals/enterprise/security/single-sign-on/connect.md) to
+  ensure that when users sign in to Docker, they must use SSO.
+
+  > [!NOTE]
+  >
+  > Enforcing single sign-on (SSO) and enforcing Docker Desktop sign in
+  > are different features. For more details, see
+  > [Enforcing sign-in versus enforcing single sign-on (SSO)](/manuals/enterprise/security/enforce-sign-in/_index.md#enforcing-sign-in-versus-enforcing-single-sign-on-sso).
+
+- [Configure SCIM](/manuals/enterprise/security/provisioning/scim/_index.md) to
+  automatically provision, add, and de-provision members to Docker through
+  your identity provider.
+
+### Step five: Enforce sign-in for Docker Desktop
+
+By default, members of your organization can use Docker Desktop without signing
+in. When users don’t sign in as a member of your organization, they don’t
+receive the
+[benefits of your organization’s subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsAdminOnboard)
+and they can circumvent [Docker’s security features](/manuals/enterprise/security/hardened-desktop/_index.md).
+
+There are multiple ways you can enforce sign-in, depending on your organization's
+Docker configuration:
+
+- [Registry key method (Windows only)](/manuals/enterprise/security/enforce-sign-in/methods.md#registry-key-method-windows-only)
+- [`.plist` method (Mac only)](/manuals/enterprise/security/enforce-sign-in/methods.md#plist-method-mac-only)
+- [`registry.json` method (All)](/manuals/enterprise/security/enforce-sign-in/methods.md#registryjson-method-all)
+
+### Step six: Manage Docker Desktop security
+
+Docker offers the following security features to manage your organization's
+security posture:
+
+- [Image Access Management](/manuals/enterprise/security/hardened-desktop/image-access-management.md): Control which types of images your developers can pull from Docker Hub.
+- [Registry Access Management](/manuals/enterprise/security/hardened-desktop/registry-access-management.md): Define which registries your developers can access.
+- [Settings management](/manuals/enterprise/security/hardened-desktop/settings-management.md): Set and control Docker Desktop settings for your users.
+
+## Next steps
+
+- [Manage Docker products](../manage/manage-products.md) to configure access and view usage.
+- Configure [Hardened Docker Desktop](/manuals/enterprise/security/hardened-desktop/_index.md) to improve your organization’s security posture for containerized development.
+- [Manage your domains](/manuals/enterprise/security/domain-management.md) to ensure that all Docker users in your domain are part of your organization.
+
+Your Docker subscription provides many more additional features. To learn more,
+see [Docker subscriptions and features](https://www.docker.com/pricing?ref=Docs&refAction=DocsAdminOnboard).
diff --git a/content/manuals/admin/organization/setup/orgs.md b/content/manuals/admin/organization/setup/orgs.md
new file mode 100644
index 000000000000..5cb67788393d
--- /dev/null
+++ b/content/manuals/admin/organization/setup/orgs.md
@@ -0,0 +1,81 @@
+---
+title: Create your organization
+linkTitle: Create
+weight: 10
+description: Learn how to create an organization.
+keywords: docker organizations, organization, create organization, docker teams, organization management
+aliases:
+  - /docker-hub/orgs/
+  - /admin/organization/orgs/
+---
+
+{{< summary-bar feature_name="Admin orgs" >}}
+
+There are multiple ways to create an organization. You can either:
+
+- Create a new organization using the **Create Organization** option in the
+  Docker Home
+- Convert an existing user account to an organization
+
+## Prerequisites
+
+- Before you create an organization, you need a [Docker ID](/manuals/accounts/create-account.md).
+- For prerequisites and detailed instructions on converting an existing user account to an organization, see
+  [Convert an account into an organization](/manuals/admin/organization/setup/convert-account.md).
+
+> [!TIP]
+> Need a different plan for your team's needs? Review different [Docker subscriptions and features](https://www.docker.com/pricing?ref=Docs&refAction=DocsAdminOrgs) to choose a subscription for your organization.
+
+## Create an organization
+
+1. Sign in to [Docker Home](https://app.docker.com/) and navigate to the bottom
+   of the organization list. Select **Create new organization**.
+1. Choose a subscription for your organization, a billing cycle, and specify how many seats you need. See [Docker Pricing](https://www.docker.com/pricing?ref=Docs&refAction=DocsAdminOrgs) for details on the features offered in the Team and Business subscription.
+1. Select **Continue to profile**, then **Create an organization** to create a new organization.
+1. Enter an **Organization namespace**. This is the official, unique name for
+   your organization in Docker Hub.
+   - It's not possible to change the name of the organization after you've created it.
+   - Your Docker ID and organization can't share the same name.
+   - If you want to use your Docker ID as the organization name, then you must first [convert your account into an organization](/manuals/admin/organization/setup/convert-account.md).
+1. Enter your **Company name**. This is the full name of your company.
+   - Docker displays the company name on your organization page and in the details of any
+     public images you publish.
+   - You can update the company name anytime by navigating to your organization's **Settings** page.
+1. Select **Continue to billing** to continue, then enter your organization's billing information. Select **Continue to payment** to continue to the billing portal.
+1. Provide your payment details and select **Purchase**.
+
+You've now created an organization.
+
+## View an organization
+
+To view an organization:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+   organization.
+
+Docker Home contains many options that let you to
+configure your organization.
+
+## Merge organizations
+
+> [!WARNING]
+>
+> If you are merging organizations, it is recommended to do so at the _end_ of
+> your billing cycle. When you merge an organization and downgrade another, you
+> will lose seats on your downgraded organization. Docker does not offer
+> refunds for downgrades.
+
+If you have multiple organizations that you want to merge into one, complete
+the following steps:
+
+1. Based on the number of seats from the secondary organization, [purchase additional seats](../manage/manage-seats.md) for the primary organization account that you want to keep.
+1. Manually add users to the primary organization and remove existing users from the secondary organization.
+1. Manually move over your data, including all repositories.
+1. Once you're done moving all of your users and data, [downgrade](../../../subscription/plans/docker.md#cancel-a-docker-plan) the secondary account to a free subscription. Note that Docker does not offer refunds for downgrading organizations mid-billing cycle.
+
+If your organization has a Docker Business subscription with a purchase
+order, contact Support or your Account Manager at Docker.
+
+## More resources
+
+- [Video: Docker Hub Organizations](https://www.youtube.com/watch?v=WKlT1O-4Du8)
diff --git a/content/manuals/agentic-platform/_index.md b/content/manuals/agentic-platform/_index.md
new file mode 100644
index 000000000000..179c8e790c77
--- /dev/null
+++ b/content/manuals/agentic-platform/_index.md
@@ -0,0 +1,70 @@
+---
+title: Docker Agentic Platform
+description: Run agents and tools in isolated, hosted sandboxes with Docker Agentic Platform.
+keywords: docker agentic platform, agents, sandboxes, mcp, secrets, network policies
+weight: 5
+sitemap: false
+cascade:
+  sitemap: false
+params:
+  sidebar:
+    group: AI and agents
+    badge:
+      color: violet
+      text: Experimental
+grid:
+  - title: Get started
+    description: Choose an agent environment and start a sandbox.
+    icon: rocket-launch
+    link: /agentic-platform/get-started/
+  - title: Sandboxes
+    description: Work with hosted agent environments.
+    icon: command-line
+    link: /agentic-platform/sandboxes/
+  - title: MCP
+    description: Connect predefined or custom MCP servers.
+    icon: cpu-chip
+    link: /agentic-platform/mcp/
+  - title: Secrets
+    description: Manage model provider and service credentials.
+    icon: key
+    link: /agentic-platform/secrets/
+  - title: Policies
+    description: Control outbound network access from sandboxes.
+    icon: shield-check
+    link: /agentic-platform/policies/
+  - title: FAQ
+    description: Review launch scope and product boundaries.
+    icon: question-mark-circle
+    link: /agentic-platform/faq/
+---
+
+> [!NOTE]
+> Docker Agentic Platform is experimental. Features and behavior may change.
+
+Docker Agentic Platform runs agents and agent-powered tools in isolated
+sandboxes on Docker-managed cloud infrastructure. An active workload is not
+tied to your computer remaining awake or connected. You can leave the Console
+and return to the sandbox while the agent continues working.
+
+For sandboxes that run on your development machine through the `sbx` CLI, see
+[Docker Sandboxes](/manuals/ai/sandboxes/_index.md).
+
+From the web Console, choose the type of sandbox to run and configure its model
+credential, network access, tools, and compute. Docker creates the sandbox and
+opens a live terminal for interacting with the agent. The **Sandboxes** page
+provides one place to return to and manage your running and paused workloads.
+
+Account-level configuration can be reused across sandboxes:
+
+- [MCP](/manuals/agentic-platform/mcp.md) connects external tools.
+- [Secrets](/manuals/agentic-platform/secrets.md) provide credentials
+  without placing their values inside a sandbox.
+- [Network policies](/manuals/agentic-platform/policies.md) control
+  outbound destinations.
+
+To begin, open [Docker Agentic Platform](https://agentic-platform.docker.com/)
+and sign in with your Docker account. Docker meters sandbox compute per second.
+For account and payment information, see [Docker Billing](/billing/).
+
+{{< grid >}}
diff --git a/content/manuals/agentic-platform/faq.md b/content/manuals/agentic-platform/faq.md
new file mode 100644
index 000000000000..e40da49e8205
--- /dev/null
+++ b/content/manuals/agentic-platform/faq.md
@@ -0,0 +1,61 @@
+---
+title: Docker Agentic Platform FAQ
+linkTitle: FAQ
+description: Find answers about Docker Agentic Platform sandboxes, access, credentials, billing, and data retention.
+keywords: docker agentic platform, faq, sandboxes, agents, docker sandboxes, usage, billing, inference, logs, telemetry, snapshots, data retention
+weight: 80
+aliases:
+  - /agentic-platform/concepts/local-cloud/
+---
+
+## What can I run in Docker Agentic Platform?
+
+Docker Agentic Platform provides predefined sandbox types for Claude Code,
+Codex, OpenCode, Copilot, and Gemini CLI. Each runs in an isolated, Docker-hosted
+sandbox with a live terminal.
+
+## How does Docker Agentic Platform differ from Docker Sandboxes?
+
+Docker Agentic Platform runs sandboxes on Docker-managed cloud infrastructure
+through a web Console. Docker Sandboxes runs sandboxes on your development
+machine through the `sbx` command. Docker Agentic Platform manages the compute,
+MCP connections, secrets, and network policies used by its hosted sandboxes.
+
+## Can I move a sandbox between my machine and Docker Agentic Platform?
+
+No. Local and hosted sandboxes are separate in the initial release. You cannot
+move a running sandbox or its local bind mounts into Docker Agentic Platform.
+
+## Can I share sandboxes and configuration with a team?
+
+The initial self-service experience is single-user. You manage your own
+sandboxes, MCP connections, secrets, and network policies. Shared workspaces
+and collaborative ownership are not part of the initial release.
+
+## How does a sandbox access external services?
+
+Network policies control the destinations a sandbox can reach. The sandbox
+type's read-only kit policy applies automatically, and you can select zero or
+more user policies when you create the sandbox. If you select no user policies,
+only the kit policy applies and destinations that it does not allow are blocked.
+A deny rule takes precedence over an allow rule. Docker stores configured
+secret values outside the sandbox and applies them to matching requests through
+the sandbox proxy.
+
+## How are sandbox usage and model inference billed?
+
+Docker bills sandbox compute per second while the sandbox runs. The Console
+also shows the equivalent hourly rate.
+
+Model inference is billed separately. The sandbox uses your credential for an
+external model provider, which meters and bills inference under that provider
+account. See [Docker Billing](/billing/) for account, usage, and payment
+information.
+
+## How long are logs, telemetry, and snapshots retained?
+
+Docker retains Docker Agentic Platform service logs for 31 days and raw
+telemetry for 12 months.
+
+All snapshots, including the most recent snapshot created when you pause a
+sandbox, are automatically deleted after seven days of non-use.
diff --git a/content/manuals/agentic-platform/get-started.md b/content/manuals/agentic-platform/get-started.md
new file mode 100644
index 000000000000..c1d26afd8a0b
--- /dev/null
+++ b/content/manuals/agentic-platform/get-started.md
@@ -0,0 +1,52 @@
+---
+title: Get started with Docker Agentic Platform
+linkTitle: Get started
+description: Choose an agent environment and start a Docker Agentic Platform sandbox.
+keywords: docker agentic platform, get started, agents, sandbox, live terminal
+weight: 10
+aliases:
+  - /agentic-platform/concepts/platform-model/
+  - /agentic-platform/concepts/kits/
+  - /agentic-platform/guides/manage-kits/
+---
+
+The Docker Agentic Platform launcher collects the configuration needed to start
+an agent in an isolated sandbox.
+
+## Before you begin
+
+You need a Docker account, access to Docker Agentic Platform, and an API key for
+the model provider you want to use. You can add the key under **Secrets** before
+creating the sandbox or provide it in the launcher when prompted.
+
+The available sandbox types are Claude Code, Codex, OpenCode, Copilot, and
+Gemini CLI. The supported model provider credentials are Anthropic, OpenAI,
+GitHub Copilot, Google, Groq, and xAI.
+
+## Start a sandbox
+
+1. Open [Docker Agentic Platform](https://agentic-platform.docker.com/) and
+   select **New**.
+2. Choose a sandbox type and select or add its required model credential.
+   Copilot uses `GITHUB_TOKEN`; add the same GitHub secret to any other sandbox
+   type that needs private repository access.
+3. Configure the sandbox. The initial settings are **open access**, **no tools
+   added**, and **medium compute**.
+4. Choose whether Docker stops or deletes the sandbox when its timer expires,
+   and set the timer from 1 to 24 hours.
+5. Review the configuration and select **Run**.
+
+You cannot change the sandbox's authentication, tools, access policy, or compute
+size after it starts. Docker creates the sandbox, marks it as running, and opens
+its terminal.
+
+Use the terminal to interact with the selected agent or tool.
+
+Return to **Sandboxes** to find the running sandbox and reopen its terminal.
+
+## Next steps
+
+- [Manage sandboxes](/manuals/agentic-platform/sandboxes.md)
+- [Connect MCP servers](/manuals/agentic-platform/mcp.md)
+- [Manage secrets](/manuals/agentic-platform/secrets.md)
+- [Manage network policies](/manuals/agentic-platform/policies.md)
diff --git a/content/manuals/agentic-platform/mcp.md b/content/manuals/agentic-platform/mcp.md
new file mode 100644
index 000000000000..629bf799ab56
--- /dev/null
+++ b/content/manuals/agentic-platform/mcp.md
@@ -0,0 +1,33 @@
+---
+title: MCP
+description: Connect predefined and custom MCP servers for Docker Agentic Platform sandboxes.
+keywords: docker agentic platform, mcp servers, mcp tools, authorization, remote url
+weight: 30
+aliases:
+  - /agentic-platform/concepts/mcp-tools/
+  - /agentic-platform/guides/configure-mcp-tools/
+---
+
+Model Context Protocol (MCP) servers connect agents to external services and
+expose operations from those services as tools. From the **MCP** page, connect a
+predefined server or add a custom server by URL. Complete authorization when a
+server requires it.
+
+MCP configuration grants agents tools they can invoke. It does not restrict or
+inspect ordinary network access from a sandbox. Use
+[network policies](/manuals/agentic-platform/policies.md) to control outbound
+destinations. MCP-specific policies are not part of the initial release.
+
+## Connect a predefined server
+
+1. Open **MCP** and choose a predefined server.
+2. Connect the server.
+3. Complete authorization if prompted.
+
+## Add a server by URL
+
+To connect a server that is not predefined:
+
+1. Open **MCP**.
+2. Choose the option to add a server and enter its URL.
+3. Connect the server and complete authorization if prompted.
diff --git a/content/manuals/agentic-platform/policies.md b/content/manuals/agentic-platform/policies.md
new file mode 100644
index 000000000000..6667183748c7
--- /dev/null
+++ b/content/manuals/agentic-platform/policies.md
@@ -0,0 +1,83 @@
+---
+title: Network policies
+linkTitle: Policies
+description: Control outbound network access from Docker Agentic Platform sandboxes.
+keywords: docker agentic platform, network policies, network access, allow rules, deny rules
+weight: 50
+aliases:
+  - /agentic-platform/concepts/policies/
+  - /agentic-platform/guides/create-and-apply-policies/
+---
+
+Network policies control the external destinations that sandboxes can reach.
+They are separate from MCP server connections and secret bindings.
+
+Docker Agentic Platform uses two types of network policy:
+
+- Kit policies are read-only policies for each sandbox type. The corresponding
+  kit policy is applied automatically when you create a sandbox. These rules
+  are the sandbox type's kit defaults. Review them under **Kit policies** on the
+  **Policies** page.
+- User policies are policies that you can select when you create a sandbox.
+  Docker provides the read-only **Open** and **Balanced** presets, and you can
+  create custom policies. **Open** allows all outbound destinations.
+  **Balanced** allows a curated set of destinations.
+
+You can select no user policies, one policy, or multiple policies. The selected
+user policies are combined with the sandbox type's kit policy. Docker evaluates
+all applicable rules, and a deny rule takes precedence over an allow rule.
+
+If you select no user policies, only the kit policy applies. Network access is
+default-deny, so the sandbox can reach only destinations that the kit policy
+explicitly allows. If its kit policy has no network rules, all outbound
+destinations are blocked.
+
+## Policy rules
+
+Policy rules allow or deny network destinations. Use the following hostname
+patterns:
+
+| Pattern               | Example           | Matches                                            |
+| --------------------- | ----------------- | -------------------------------------------------- |
+| Exact hostname        | `example.com`     | `example.com` only, not subdomains                 |
+| Single-level wildcard | `*.example.com`   | One subdomain level, such as `api.example.com`     |
+| Multi-level wildcard  | `**.example.com`  | Any depth: `api.example.com`, `v2.api.example.com` |
+| Hostname with port    | `example.com:443` | `example.com` on port 443 only                     |
+
+`example.com` does not match subdomains, and `*.example.com` does not match the
+root domain. Add each pattern required by your destinations.
+
+You can also match IPv4 and IPv6 CIDR ranges, such as `10.0.0.0/8`,
+`192.168.1.0/24`, and `2001:db8::/32`.
+
+When defining access, include every service the sandbox needs during startup
+and operation. Depending on the workload, these services can include source
+control hosts, package registries, and model providers.
+
+## Create a policy
+
+1. Open **Policies** and select **New policy**.
+2. Enter a name that identifies the intended workload or access level.
+3. Add allow and deny rules for the required destinations.
+4. Review the rules and save the policy.
+
+To apply the policy, select it under **Egress policy for this sandbox** when you
+create a sandbox.
+
+You can edit, copy, or delete a custom policy. Docker-managed policies cannot
+be edited or deleted.
+
+## Understand blocked access
+
+An agent might report an HTTP 403 response, a connection failure, or another
+service error when a required destination is not allowed. The error output from
+the agent or tool is the primary source for identifying the destination.
+
+For a sandbox that uses limited access, account for every host and port the
+workload needs, including source control, package registries, model providers,
+and supporting APIs. Add the narrowest allow rule that covers the required
+destination. Use **Open** when broad outbound access is appropriate for the
+workload.
+
+Network policy controls outbound destinations. It does not grant MCP tools or
+supply credentials. Configure those separately under **MCP** and **Secrets**.
diff --git a/content/manuals/agentic-platform/release-notes.md b/content/manuals/agentic-platform/release-notes.md
new file mode 100644
index 000000000000..fe2227b6c4e4
--- /dev/null
+++ b/content/manuals/agentic-platform/release-notes.md
@@ -0,0 +1,32 @@
+---
+title: Docker Agentic Platform release notes
+linkTitle: Release notes
+description: Review feature updates, behavior changes, and fixes in Docker Agentic Platform.
+keywords: docker agentic platform, release notes, updates, fixes
+weight: 90
+---
+
+## August 27, 2026
+
+- Added Groq and xAI credentials under **Secrets** for OpenCode sandboxes.
+
+## August 26, 2026
+
+Docker Agentic Platform is available for running agent and tool workloads in
+sandboxes hosted on Docker-managed cloud infrastructure.
+
+The initial release includes:
+
+- Predefined sandbox types for Claude Code, Codex, OpenCode, Copilot, and
+  Gemini CLI
+- A live terminal for interacting with the workload running in a sandbox
+- Pause, resume, and delete controls for sandboxes
+- Automatic sandbox stop or deletion after a timer from 1 to 24 hours
+- Predefined MCP servers and custom servers added by URL, with connection and
+  authorization flows
+- Provider and service credential management under **Secrets**, with values
+  kept outside sandboxes
+- Read-only kit policies that apply automatically, Docker-managed Open and
+  Balanced user policies, selectable custom policies, and deny-over-allow
+  precedence
+- Metered sandbox compute with selectable instance sizes
diff --git a/content/manuals/agentic-platform/sandboxes.md b/content/manuals/agentic-platform/sandboxes.md
new file mode 100644
index 000000000000..b9ecf3b49035
--- /dev/null
+++ b/content/manuals/agentic-platform/sandboxes.md
@@ -0,0 +1,76 @@
+---
+title: Sandboxes
+description: Create and manage hosted agent environments in Docker Agentic Platform.
+keywords: docker agentic platform, sandboxes, agents, cloud runtime, terminal, compute
+weight: 20
+aliases:
+  - /agentic-platform/concepts/sandboxes/
+  - /agentic-platform/guides/manage-sandboxes/
+---
+
+A sandbox is an isolated runtime for an agent or tool. Docker hosts and meters
+the sandbox on managed cloud infrastructure and provides a live terminal for
+interacting with it.
+
+Docker Agentic Platform provides predefined sandbox types for Claude Code,
+Codex, OpenCode, Copilot, and Gemini CLI. Each sandbox has its own compute,
+filesystem, network access, and terminal. A sandbox continues running
+independently of your connection to the Console until it is paused, stopped by
+its lifecycle timer, or deleted.
+
+## Source code and files
+
+A sandbox starts with a fresh filesystem. Docker Agentic Platform does not
+mount a repository, local directory, or workspace from your computer into the
+sandbox by default.
+
+A sandbox does not synchronize its filesystem with your computer or a remote
+repository. Work remains only in the sandbox unless you commit and push it to a
+remote repository. Push work that you want to keep before deleting the
+sandbox; files that exist only in a deleted sandbox are not available from a
+later sandbox.
+
+Docker Agentic Platform supports GitHub repositories for bringing source into
+a sandbox and preserving changes. Configure `GITHUB_TOKEN` under **Secrets** or
+from the sandbox launcher to clone a private repository or perform write
+operations such as pushing a branch or opening a pull request. The token must
+have the required repository permissions. Public repositories can be cloned
+without a GitHub credential, but writing to them still requires authentication.
+
+## Open a sandbox
+
+After you select **Run**, Docker creates the sandbox and opens its detail page.
+Use the terminal to interact with the selected agent or tool.
+
+Open **Sandboxes** to review each sandbox's name, type, status, hourly rate,
+expiration, and age. Select a sandbox to reopen its detail page and terminal.
+
+## Manage the lifecycle
+
+A sandbox can be running or paused:
+
+- Pause a running sandbox to stop its compute without deleting it.
+- Resume a paused sandbox to continue working with it.
+- Delete a sandbox when you no longer need it.
+
+When you create a sandbox, set a lifecycle timer from 1 to 24 hours and choose
+what happens when it expires. **Stop** stops the sandbox, while **Delete**
+deletes the sandbox and its files.
+
+The sandbox's authentication, tools, access policy, and compute size are fixed
+when the sandbox is created and cannot be changed while it runs.
+
+Docker bills sandbox compute per second while the sandbox runs. Model inference
+uses your external provider credential and is metered by that provider. For
+account, usage, and payment information, see [Docker Billing](/billing/).
+
+## Check sandbox configuration
+
+If the agent cannot reach a service or use a tool, check the configuration that
+applies to the request:
+
+- Confirm that the network policies permit the destination.
+- If the agent needs an MCP tool, confirm that its server is connected and
+  authorized.
+- If the destination requires authentication, confirm that the required
+  service credential is configured under **Secrets**.
diff --git a/content/manuals/agentic-platform/secrets.md b/content/manuals/agentic-platform/secrets.md
new file mode 100644
index 000000000000..7f9c452d79b7
--- /dev/null
+++ b/content/manuals/agentic-platform/secrets.md
@@ -0,0 +1,61 @@
+---
+title: Secrets
+description: Manage model provider and service credentials for Docker Agentic Platform sandboxes.
+keywords: docker agentic platform, secrets, api keys, service credentials, proxy
+weight: 40
+aliases:
+  - /agentic-platform/concepts/secrets/
+  - /agentic-platform/guides/manage-secrets/
+---
+
+Secrets provide credentials to agents without placing their values in a
+sandbox. Docker Agentic Platform stores each value outside sandboxes and uses
+the sandbox proxy to apply it to matching requests.
+
+Docker Agentic Platform supports the following credentials:
+
+| Service       | Secret ID           | Used by                                           |
+| ------------- | ------------------- | ------------------------------------------------- |
+| Anthropic     | `ANTHROPIC_API_KEY` | Claude Code and OpenCode with Anthropic models    |
+| OpenAI        | `OPENAI_API_KEY`    | Codex and OpenCode with OpenAI models             |
+| Google Gemini | `GEMINI_API_KEY`    | Gemini CLI and OpenCode with Google models        |
+| Groq          | `GROQ_API_KEY`      | OpenCode with Groq models                         |
+| xAI           | `XAI_API_KEY`       | OpenCode with xAI models                          |
+| GitHub        | `GITHUB_TOKEN`      | Copilot and any sandbox type that accesses GitHub |
+
+Provider-specific credentials are applied only to matching requests from
+compatible sandbox types. For example, an Anthropic credential is not applied
+to requests from a Codex sandbox. OpenCode can use any configured provider that
+it supports.
+
+## GitHub credential
+
+`GITHUB_TOKEN` authenticates both Copilot and GitHub repository operations.
+Entering it in the launcher stores it as the same GitHub secret shown under
+**Secrets**. Any sandbox type can use it for matching GitHub requests, such as
+cloning a private repository or pushing changes.
+
+## Configure a secret
+
+To configure a credential before launching a sandbox:
+
+1. Open **Secrets** and find the service.
+2. Select the edit icon for that service.
+3. Enter its API key or token and save the value.
+
+You can also provide a required credential from **New** when you launch a
+sandbox.
+
+## Manage secrets
+
+The **Secrets** page shows each secret ID and the sandboxes that use it. Select
+the copy icon to copy the secret ID, or select the edit icon to change the
+stored value.
+
+Agents see the secret ID, not the stored value. When an outbound request matches
+the secret's service binding, the sandbox proxy applies the value to the
+request. A secret for one service does not become a general-purpose credential
+inside the sandbox.
+
+Do not put API keys or tokens in prompts or files inside the sandbox. Rotate or
+revoke a credential at its provider when it is no longer needed.
diff --git a/content/manuals/ai-overview.md b/content/manuals/ai-overview.md
new file mode 100644
index 000000000000..d43e99ae2966
--- /dev/null
+++ b/content/manuals/ai-overview.md
@@ -0,0 +1,46 @@
+---
+title: Docker AI overview
+linkTitle: Overview
+description: Docker's AI tools help you build, run, and manage AI-powered applications and workflows.
+weight: 1
+keywords: docker, ai, gordon, docker agent, sandboxes, model runner, mcp
+params:
+  sidebar:
+    group: AI and agents
+---
+
+Docker provides tools for working with AI across your development workflow.
+Each tool serves a different purpose.
+
+## Which tool do I need?
+
+| I want to...                                                    | Use                                                      | CLI command      |
+| --------------------------------------------------------------- | -------------------------------------------------------- | ---------------- |
+| Get AI help with Docker tasks (containers, images, Dockerfiles) | [Gordon](./ai/gordon/)                                   | `docker ai`      |
+| Run AI models locally with an OpenAI-compatible API             | [Model Runner](./ai/model-runner/)                       | `docker model`   |
+| Connect AI tools to external services via MCP                   | [MCP Catalog and Toolkit](./ai/mcp-catalog-and-toolkit/) | `docker mcp`     |
+| Build and orchestrate custom multi-agent teams                  | [Docker Agent](./ai/docker-agent/)                       | `docker agent`   |
+| Run coding agents in isolated environments                      | [Docker Sandboxes](./ai/sandboxes/)                      | `sbx`            |
+
+## How these tools relate
+
+**Gordon** is Docker's built-in AI assistant. It helps with Docker-specific
+tasks like debugging containers, writing Dockerfiles, and managing images. You
+interact with it through Docker Desktop or the `docker ai` command.
+
+**Docker Agent** is an open-source framework for defining teams of AI agents
+in YAML. You configure agents with specific roles, models, and tools, then
+run them from your terminal. Docker Agent is a general-purpose agent runtime,
+not specific to Docker tasks.
+
+**Docker Sandboxes** provides isolated microVM environments for running coding
+agents. It supports multiple agents including Claude Code, Codex, Copilot,
+Gemini, and Docker Agent. Sandboxes is the isolation layer — the agents
+themselves are separate tools.
+
+**Model Runner** lets you run LLMs locally. Other tools like Docker Agent can
+use Model Runner as a model provider.
+
+**MCP Catalog and Toolkit** manages connections between AI tools and external
+services using the Model Context Protocol. Gordon, Docker Agent, and
+third-party tools can all use MCP servers configured through the Toolkit.
diff --git a/content/manuals/ai/compose/_index.md b/content/manuals/ai/compose/_index.md
new file mode 100644
index 000000000000..0f2905440944
--- /dev/null
+++ b/content/manuals/ai/compose/_index.md
@@ -0,0 +1,9 @@
+---
+build:
+  render: never
+title: AI and Docker Compose
+weight: 50
+params:
+  sidebar:
+    group: AI and agents
+---
diff --git a/content/manuals/ai/compose/models-and-compose.md b/content/manuals/ai/compose/models-and-compose.md
new file mode 100644
index 000000000000..aa5502f6f8a7
--- /dev/null
+++ b/content/manuals/ai/compose/models-and-compose.md
@@ -0,0 +1,356 @@
+---
+title: Define AI Models in Docker Compose applications
+linkTitle: Use AI models in Compose
+description: Learn how to define and use AI models in Docker Compose applications using the models top-level element
+keywords: compose, docker compose, models, ai, machine learning, cloud providers, specification
+weight: 10
+---
+
+{{< summary-bar feature_name="Compose models" >}}
+
+Compose lets you define AI models as core components of your application, so you can declare model dependencies alongside services and run the application on any platform that supports the Compose Specification.
+
+## Prerequisites
+
+- Docker Compose v2.38 or later
+- A platform that supports Compose models such as [Docker Model Runner (DMR)](/manuals/ai/model-runner/_index.md#requirements).
+
+## What are Compose models?
+
+Compose `models` are a standardized way to define AI model dependencies in your application. By using the [`models` top-level element](/reference/compose-file/models.md) in your Compose file, you can:
+
+- Declare which AI models your application needs
+- Specify model configurations and requirements
+- Make your application portable across different platforms
+- Let the platform handle model provisioning and lifecycle management
+
+## Basic model definition
+
+To define models in your Compose application, use the `models` top-level element:
+
+```yaml
+services:
+  chat-app:
+    image: my-chat-app
+    models:
+      - llm
+
+models:
+  llm:
+    model: ai/smollm2
+```
+
+This example defines:
+- A service called `chat-app` that uses a model named `llm`
+- A model definition for `llm` that references the `ai/smollm2` model image
+
+## Model configuration options
+
+Models support various configuration options:
+
+```yaml
+models:
+  llm:
+    model: ai/smollm2
+    context_size: 1024
+    runtime_flags:
+      - "--a-flag"
+      - "--another-flag=42"
+```
+
+Common configuration options include:
+- `model` (required): The OCI artifact identifier for the model. This is what Compose pulls and runs via the model runner.
+- `context_size`: Defines the maximum token context size for the model.
+
+   > [!NOTE]
+   > Each model has its own maximum context size. When increasing the context length,
+   > consider your hardware constraints. In general, try to keep context size
+   > as small as feasible for your specific needs.
+
+- `runtime_flags`: A list of raw command-line flags passed to the inference engine when the model is started.
+   See [Configuration options](/manuals/ai/model-runner/configuration.md) for commonly used parameters and examples.
+- Platform-specific options may also be available via extension attributes `x-*`
+
+> [!TIP]
+> See more example in the [Common runtime configurations](#common-runtime-configurations) section.
+
+## Service model binding
+
+Services can reference models in two ways: short syntax and long syntax.
+
+### Short syntax
+
+The short syntax is the simplest way to bind a model to a service:
+
+```yaml
+services:
+  app:
+    image: my-app
+    models:
+      - llm
+      - embedding-model
+
+models:
+  llm:
+    model: ai/smollm2
+  embedding-model:
+    model: ai/all-minilm
+```
+
+With short syntax, the platform automatically generates environment variables based on the model name:
+- `LLM_URL` - URL to access the LLM model
+- `LLM_MODEL` - Model identifier for the LLM model
+- `EMBEDDING_MODEL_URL` - URL to access the embedding-model
+- `EMBEDDING_MODEL_MODEL` - Model identifier for the embedding-model
+
+### Long syntax
+
+The long syntax allows you to customize environment variable names:
+
+```yaml
+services:
+  app:
+    image: my-app
+    models:
+      llm:
+        endpoint_var: AI_MODEL_URL
+        model_var: AI_MODEL_NAME
+      embedding-model:
+        endpoint_var: EMBEDDING_URL
+        model_var: EMBEDDING_NAME
+
+models:
+  llm:
+    model: ai/smollm2
+  embedding-model:
+    model: ai/all-minilm
+```
+
+With this configuration, your service receives:
+- `AI_MODEL_URL` and `AI_MODEL_NAME` for the LLM model
+- `EMBEDDING_URL` and `EMBEDDING_NAME` for the embedding model
+
+## Platform portability
+
+One of the key benefits of using Compose models is portability across different platforms that support the Compose specification.
+
+### Docker Model Runner
+
+When [Docker Model Runner is enabled](/manuals/ai/model-runner/_index.md):
+
+```yaml
+services:
+  chat-app:
+    image: my-chat-app
+    models:
+      llm:
+        endpoint_var: AI_MODEL_URL
+        model_var: AI_MODEL_NAME
+
+models:
+  llm:
+    model: ai/smollm2
+    context_size: 4096
+    runtime_flags:
+      - "--no-prefill-assistant"
+```
+
+Docker Model Runner will:
+- Pull and run the specified model locally
+- Provide endpoint URLs for accessing the model
+- Inject environment variables into the service
+
+### Cloud providers
+
+The Compose models specification is portable. Platforms that implement the Compose specification can support the `models` top-level element, allowing the same Compose file to run on different infrastructure. Cloud-specific behavior can be configured using extension attributes (`x-*`):
+
+```yaml
+services:
+  chat-app:
+    image: my-chat-app
+    models:
+      - llm
+
+models:
+  llm:
+    model: ai/smollm2
+    # Cloud-specific configurations
+    x-cloud-options:
+      - "cloud.instance-type=gpu-small"
+      - "cloud.region=us-west-2"
+```
+
+How a platform handles model definitions depends on its implementation. A platform might:
+
+- Use managed AI services instead of running models locally
+- Apply platform-specific optimizations and scaling
+- Provide additional monitoring and logging capabilities
+- Handle model versioning and updates automatically
+
+## Common runtime configurations
+
+Below are some example configurations for various use cases.
+
+### Development
+
+```yaml
+services:
+  app:
+    image: app
+    models:
+      dev_model:
+        endpoint_var: DEV_URL
+        model_var: DEV_MODEL
+
+models:
+  dev_model:
+    model: ai/model
+    context_size: 4096
+    runtime_flags:
+      - "--verbose"                       # Set verbosity level to infinity
+      - "--verbose-prompt"                # Print a verbose prompt before generation
+      - "--log-prefix"                    # Enable prefix in log messages
+      - "--log-timestamps"                # Enable timestamps in log messages
+      - "--log-colors"                    # Enable colored logging
+```
+
+### Conservative with disabled reasoning
+
+```yaml
+services:
+  app:
+    image: app
+    models:
+      conservative_model:
+        endpoint_var: CONSERVATIVE_URL
+        model_var: CONSERVATIVE_MODEL
+
+models:
+  conservative_model:
+    model: ai/model
+    context_size: 4096
+    runtime_flags:
+      - "--temp"                # Temperature
+      - "0.1"
+      - "--top-k"               # Top-k sampling
+      - "1"
+      - "--reasoning-budget"    # Disable reasoning
+      - "0"
+```
+
+### Creative with high randomness
+
+```yaml
+services:
+  app:
+    image: app
+    models:
+      creative_model:
+        endpoint_var: CREATIVE_URL
+        model_var: CREATIVE_MODEL
+
+models:
+  creative_model:
+    model: ai/model
+    context_size: 4096
+    runtime_flags:
+      - "--temp"                # Temperature
+      - "1"
+      - "--top-p"               # Top-p sampling
+      - "0.9"
+```
+
+### Highly deterministic
+
+```yaml
+services:
+  app:
+    image: app
+    models:
+      deterministic_model:
+        endpoint_var: DET_URL
+        model_var: DET_MODEL
+
+models:
+  deterministic_model:
+    model: ai/model
+    context_size: 4096
+    runtime_flags:
+      - "--temp"                # Temperature
+      - "0"
+      - "--top-k"               # Top-k sampling
+      - "1"
+```
+
+### Concurrent processing
+
+```yaml
+services:
+  app:
+    image: app
+    models:
+      concurrent_model:
+        endpoint_var: CONCURRENT_URL
+        model_var: CONCURRENT_MODEL
+
+models:
+  concurrent_model:
+    model: ai/model
+    context_size: 2048
+    runtime_flags:
+      - "--threads"             # Number of threads to use during generation
+      - "8"
+      - "--mlock"               # Lock memory to prevent swapping
+```
+
+### Rich vocabulary model
+
+```yaml
+services:
+  app:
+    image: app
+    models:
+      rich_vocab_model:
+        endpoint_var: RICH_VOCAB_URL
+        model_var: RICH_VOCAB_MODEL
+
+models:
+  rich_vocab_model:
+    model: ai/model
+    context_size: 4096
+    runtime_flags:
+      - "--temp"                # Temperature
+      - "0.1"
+      - "--top-p"               # Top-p sampling
+      - "0.9"
+```
+
+### Embeddings
+
+When using embedding models with the `/v1/embeddings` endpoint, you must include the `--embeddings` runtime flag for the model to be properly configured.
+
+```yaml
+services:
+  app:
+    image: app
+    models:
+      embedding_model:
+        endpoint_var: EMBEDDING_URL
+        model_var: EMBEDDING_MODEL
+
+models:
+  embedding_model:
+    model: ai/all-minilm
+    context_size: 2048
+    runtime_flags:
+      - "--embeddings"          # Required for embedding models
+```
+
+## Reference
+
+- [`models` top-level element](/reference/compose-file/models.md)
+- [`models` attribute](/reference/compose-file/services.md#models)
+- [Docker Model Runner documentation](/manuals/ai/model-runner/_index.md)
+- [Configuration options](/manuals/ai/model-runner/configuration.md) - Context size and runtime parameters
+- [Inference engines](/manuals/ai/model-runner/inference-engines.md) - llama.cpp and vLLM details
+- [API reference](/manuals/ai/model-runner/api-reference.md) - OpenAI and Ollama-compatible APIs
diff --git a/content/manuals/ai/docker-agent/_index.md b/content/manuals/ai/docker-agent/_index.md
new file mode 100644
index 000000000000..bb69c0115df8
--- /dev/null
+++ b/content/manuals/ai/docker-agent/_index.md
@@ -0,0 +1,166 @@
+---
+title: Docker Agent
+description: Docker Agent lets you build, orchestrate, and share AI agents that work together as a team.
+weight: 60
+aliases:
+  - /ai/cagent/
+  - /manuals/ai/cagent/
+  - /ai/docker-agent/integrations/
+  - /ai/docker-agent/reference/
+  - /ai/docker-agent/reference/examples/
+params:
+  sidebar:
+    group: AI and agents
+keywords: [ai, agent, docker agent, cagent]
+---
+
+[Docker Agent](https://github.com/docker/docker-agent) is an open-source framework
+for building teams of specialized AI agents. Instead of prompting one
+generalist model, you define agents with specific roles and instructions that
+collaborate to solve problems. Run these agent teams from your terminal using
+any LLM provider.
+
+> [!NOTE]
+> Docker Agent is a framework for building and running custom agent teams.
+> For Docker's built-in AI assistant, see [Gordon](/ai/gordon/) (`docker ai`).
+
+## Why agent teams
+
+One agent handling complex work means constant context-switching. Split the work
+across focused agents instead - each handles what it's best at. Docker Agent manages
+the coordination.
+
+Here's a two-agent team that debugs problems:
+
+```yaml
+agents:
+  root:
+    model: openai/gpt-5-mini # Change to the model that you want to use
+    description: Bug investigator
+    instruction: |
+      Analyze error messages, stack traces, and code to find bug root causes.
+      Explain what's wrong and why it's happening.
+      Delegate fix implementation to the fixer agent.
+    sub_agents: [fixer]
+    toolsets:
+      - type: filesystem
+      - type: mcp
+        ref: docker:duckduckgo
+
+  fixer:
+    model: anthropic/claude-sonnet-4-5 # Change to the model that you want to use
+    description: Fix implementer
+    instruction: |
+      Write fixes for bugs diagnosed by the investigator.
+      Make minimal, targeted changes and add tests to prevent regression.
+    toolsets:
+      - type: filesystem
+      - type: shell
+```
+
+The root agent investigates and explains the problem. When it understands the
+issue, it hands off to `fixer` for implementation. Each agent stays focused on
+its specialty.
+
+## Installation
+
+Docker Agent is included in Docker Desktop 4.63 and later. In Docker Desktop versions 4.49 through 4.62, this feature was called cagent.
+
+For Docker Engine users or custom installations:
+
+- **Homebrew**: `brew install docker-agent`
+- **Winget**: `winget install Docker.Agent`
+- **Pre-built binaries**: [GitHub
+  releases](https://github.com/docker/docker-agent/releases)
+- **From source**: See the [Docker Agent
+  repository](https://github.com/docker/docker-agent?tab=readme-ov-file#build-from-source)
+
+The `docker-agent` binary should be copied to `~/.docker/cli-plugins` and then can be used with the `docker agent` command. Alternatively, it can be used as a standalone binary.
+
+## Get started
+
+Try the bug analyzer team:
+
+1. Set your API key for the model provider you want to use:
+
+   ```console
+   $ export ANTHROPIC_API_KEY=<your_key>  # For Claude models
+   $ export OPENAI_API_KEY=<your_key>     # For OpenAI models
+   $ export GOOGLE_API_KEY=<your_key>     # For Gemini models
+   ```
+
+2. Save the [example configuration](#why-agent-teams) as `debugger.yaml`.
+
+3. Run your agent team:
+
+   ```console
+   $ docker agent run debugger.yaml
+   ```
+
+You'll see a prompt where you can describe bugs or paste error messages. The
+investigator analyzes the problem, then hands off to the fixer for
+implementation.
+
+## How it works
+
+You interact with the _root agent_, which can delegate work to sub-agents you
+define. Each agent:
+
+- Uses its own model and parameters
+- Has its own context (agents don't share knowledge)
+- Can access built-in tools like todo lists, memory, and task delegation
+- Can use external tools via [MCP
+  servers](/manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md)
+
+The root agent delegates tasks to agents listed under `sub_agents`. Sub-agents
+can have their own sub-agents for deeper hierarchies.
+
+## Configuration options
+
+Agent configurations are YAML files. A basic structure looks like this:
+
+```yaml
+agents:
+  root:
+    model: claude-sonnet-4-0
+    description: Brief role summary
+    instruction: |
+      Detailed instructions for this agent...
+    sub_agents: [helper]
+
+  helper:
+    model: gpt-5-mini
+    description: Specialist agent role
+    instruction: |
+      Instructions for the helper agent...
+```
+
+You can also configure model settings (like context limits), tools (including
+MCP servers), and more. See the [configuration
+reference](./configuration/overview/index.md)
+for complete details.
+
+## Share agent teams
+
+Agent configurations are packaged as OCI artifacts. Push and pull them like
+container images:
+
+```console
+$ docker agent share push ./debugger.yaml myusername/debugger
+$ docker agent share pull myusername/debugger
+```
+
+Use Docker Hub or any OCI-compatible registry. Pushing creates the repository if
+it doesn't exist yet.
+
+## What's next
+
+- Follow the [quickstart](./getting-started/quickstart/index.md) to build your first agent
+- Learn [best practices](./guides/tips/index.md) for building effective agents
+- Integrate Docker Agent with your [editor](./features/acp/index.md) or use agents as
+  [tools in MCP clients](./tools/mcp/index.md)
+- Browse example agent configurations in the [Docker Agent
+  repository](https://github.com/docker/docker-agent/tree/main/examples)
+- Connect agents to external tools via the [Docker MCP
+  Gateway](/manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md)
+- Read the full [configuration reference](./configuration/overview/index.md)
diff --git a/content/manuals/ai/gordon/_index.md b/content/manuals/ai/gordon/_index.md
index 6cd19cd555be..6b586e91c999 100644
--- a/content/manuals/ai/gordon/_index.md
+++ b/content/manuals/ai/gordon/_index.md
@@ -1,259 +1,137 @@
 ---
-title: Ask Gordon
-description: Learn how to streamline your workflow with Docker's AI-powered assistant.
-weight: 10
+title: Gordon
+description:
+  AI assistant for Docker workflows - execute tasks, debug issues, and
+  manage containers with intelligent assistance
+weight: 40
 params:
   sidebar:
-    badge:
-      color: blue
-      text: Beta
-    group: AI
-aliases: 
- - /desktop/features/gordon/
+    group: AI and agents
+aliases:
+  - /desktop/features/gordon/
 ---
 
-{{< summary-bar feature_name="Ask Gordon" >}}
+{{< summary-bar feature_name="Gordon" >}}
 
-Ask Gordon is your personal AI assistant embedded in Docker Desktop and the
-Docker CLI. It's designed to streamline your workflow and help you make the most
-of the Docker ecosystem.
+Gordon is an AI-powered assistant that takes action on your Docker workflows.
+It analyzes your environment, proposes solutions, and executes commands with
+your permission.
 
-## What is Ask Gordon?
+## What Gordon does
 
-Ask Gordon provides AI-powered assistance in Docker tools. It offers contextual help for tasks like:
+Gordon takes action to help you with Docker tasks:
 
-- Improving Dockerfiles
-- Running and troubleshooting containers
-- Interacting with your images and code
-- Finding vulnerabilities or configuration issues
+- Explains Docker concepts and commands
+- Searches Docker documentation and web resources for solutions
+- Writes and modifies Dockerfiles following best practices
+- Debugs container failures by reading logs and proposing fixes
+- Manages containers, images, volumes, and networks
 
-It understands your local environment, including source code, Dockerfiles, and images, to provide personalized and actionable guidance.
+Gordon proposes every action before executing. You approve what it does.
 
-These features are not enabled by default, and are not
-production-ready. You may also encounter the term "Docker AI" as a broader
-reference to this technology.
+## Where to use Gordon
 
-> [!NOTE] 
->
-> Ask Gordon is powered by Large Language Models (LLMs). Like all
-> LLM-based tools, its responses may sometimes be inaccurate. Always verify the
-> information provided.
+Gordon is available on four surfaces:
 
-### What data does Gordon access?
+- Open the Gordon view from the Docker Desktop sidebar to run Docker commands
+  with your approval. See [Using Gordon in Docker
+  Desktop](./how-to/docker-desktop.md).
+- Run `docker ai` in the terminal to use the full assistant from the command
+  line. See [Using Gordon via CLI](./how-to/cli.md).
+- Select the Gordon icon on any repository page at
+  [hub.docker.com](https://hub.docker.com) to ask about a repository's
+  images, tags, and metadata. Hand off to Docker Desktop to take action.
+- Select the Gordon icon on any page at
+  [docs.docker.com](https://docs.docker.com) to ask Docker questions.
 
-When you use Ask Gordon, the data it accesses depends on the context of your
-query:
+Docker Desktop and the CLI count against your Gordon plan's [usage
+limits](./usage-limits.md). Gordon on Docker Hub and docs.docker.com is free
+and does not require a Docker account or a Docker Desktop install. It has
+its own shared public usage limit and does not access your Docker
+environment.
 
-- Local files: If you use the `docker ai` command, Ask Gordon can access files
-  and directories in the current working directory where the command is
-  executed. In Docker Desktop, if you ask about a specific file or directory in
-  the **Ask Gordon** view, you'll be prompted to select the relevant context.
-- Local images: Gordon integrates with Docker Desktop and can view all images in
-  your local image store. This includes images you've built or pulled from a
-  registry.
+## Get started
 
-To provide accurate responses, Ask Gordon may send relevant files, directories,
-or image metadata to the Gordon backend along with your query. This data
-transfer occurs over the network but is never stored persistently or shared with
-third parties. It is used exclusively to process your request and formulate a
-response. For more information about privacy terms and conditions for Docker AI,
-review [Gordon's Supplemental
-Terms](https://www.docker.com/legal/docker-ai-supplemental-terms/).
+### Prerequisites
 
-All data transferred is encrypted in transit.
+Before you begin:
 
-### How your data is collected and used
+- Docker Desktop 4.74 or later
+- Sign in to your Docker account
 
-Docker collects anonymized data from your interactions with Ask Gordon to
-enhance the service. This includes the following:
+> [!NOTE]
+> Gordon is enabled by default for signed-in Docker users. If your account
+> belongs to an organization with a Business subscription, access requires two
+> additional steps:
+>
+> 1. Contact Docker Support to activate Gordon for your organization. Docker
+>    will confirm when activation is complete.
+> 2. Once confirmed, an organization administrator must turn on Gordon via
+>    [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md).
+>    Set **Enable Gordon** to **Enabled** or **Always enabled**. Ensure all
+>    Settings Management prerequisites are met for the setting to take effect
+>    on Docker Desktop clients.
 
-- Your queries: Questions you ask Gordon.
-- Responses: Answers provided by Gordon.
-- Feedback: Thumbs-up and thumbs-down ratings.
+### Quick start
 
-To ensure privacy and security:
+{{< tabs >}}
+{{< tab name="Docker Desktop" >}}
 
-- Data is anonymized and cannot be traced back to you or your account.
-- Docker does not use this data to train AI models or share it with third
-  parties.
+1. Open Docker Desktop.
+2. Select **Gordon** in the sidebar.
+3. Select your project directory.
+4. Type a question: "What containers are running?"
 
-By using Ask Gordon, you help improve Docker AI's reliability and accuracy,
-making it more effective for all users.
+   ![Gordon running in Docker Desktop](./images/gordon_gui.avif)
 
-If you have concerns about data collection or usage, you can
-[disable](#disable-ask-gordon) the feature at any time.
+5. Review Gordon's proposed actions and approve.
 
-## Enable Ask Gordon
+{{< /tab >}}
+{{< tab name="CLI" >}}
 
-1. Sign in to your Docker account.
-2. Navigate to the **Features in development** tab in settings.
-3. Under the **Experimental features** tab, select **Access experimental features**.
-4. Select **Apply and restart**. 
-5. Quit and reopen Docker Desktop to ensure the changes take effect. 
-6. Open the **Settings** view in Docker Desktop.
-7. Navigate to **Features in development**.
-8. From the **Beta** tab, check the **Enable Docker AI** checkbox.
+1. Open your terminal and run:
 
-   The Docker AI terms of service agreement is displayed. You must agree to the
-   terms before you can enable the feature. Review the terms and select **Accept
-   and enable** to continue.
+   ```console
+   $ docker ai
+   ```
 
-9. Select **Apply & restart**.
+   This opens the Terminal User Interface (TUI) for Gordon.
 
-You can also enable Ask Gordon from the **Ask Gordon** tab if you have selected the  **Access experimental features** setting. Simply select the **Enable Ask Gordon** button, and then accept the Docker AI terms of service agreement.
+2. Type a question: "what containers are running?" and press <kbd>Enter</kbd>.
 
-## Using Ask Gordon
+   ![Gordon running in the terminal](./images/gordon_tui.avif)
 
-The primary interfaces to Docker's AI capabilities are through the **Ask
-Gordon** view in Docker Desktop, or if you prefer to use the CLI: the `docker
-ai` CLI command.
+3. Review Gordon's proposed actions and approve by typing `y`.
 
-Once you've enabled the Docker AI features, you'll also find references to **Ask
-Gordon** in various other places throughout the Docker Desktop user interface.
-Whenever you encounter a button with the **Sparkles** (✨) icon in the user
-interface, you can use the button to get contextual support from Ask Gordon.
+{{< /tab >}}
+{{< /tabs >}}
 
-## Example workflows
+### Permissions
 
-Ask Gordon is a general-purpose AI assistant created to help you with all your
-Docker-related tasks and workflows. If you need some inspiration, here are a few
-ways things you can try:
+By default, Gordon asks for approval before executing actions. You can approve
+individual actions or allow all actions for the current session.
 
-- [Troubleshoot a crashed container](#troubleshoot-a-crashed-container)
-- [Get help with running a container](#get-help-with-running-a-container)
-- [Improve a Dockerfile](#improve-a-dockerfile)
+![Gordon permission request](./images/gordon_permissions_prompt.avif)
 
-For more examples, try asking Gordon directly. For example:
+Permissions reset for each session. To configure default permissions or enable
+auto-approve mode, see [Permissions](./how-to/permissions.md).
 
-```console
-$ docker ai "What can you do?"
-```
+### Try these examples
 
-### Troubleshoot a crashed container
-
-If you try to start a container with an invalid configuration or command, you
-can use Ask Gordon to troubleshoot the error. For example, try starting a
-Postgres container without specifying a database password:
+Container inspection:
 
 ```console
-$ docker run postgres
-Error: Database is uninitialized and superuser password is not specified.
-       You must specify POSTGRES_PASSWORD to a non-empty value for the
-       superuser. For example, "-e POSTGRES_PASSWORD=password" on "docker run".
-
-       You may also use "POSTGRES_HOST_AUTH_METHOD=trust" to allow all
-       connections without a password. This is *not* recommended.
-
-       See PostgreSQL documentation about "trust":
-       https://www.postgresql.org/docs/current/auth-trust.html
+$ docker ai "show me logs from my nginx container"
 ```
 
-In the **Containers** view in Docker Desktop, select the ✨ icon next to the
-container's name, or inspect the container and open the **Ask Gordon** tab.
-
-### Get help with running a container
-
-If you want to run a specific image but you're not sure how, Gordon might be
-able to help you get set up:
-
-1. Pull an image from Docker Hub (for example, `postgres`).
-2. Open the **Images** view in Docker Desktop and select the image.
-3. Select the **Run** button.
-
-In the **Run a new container** dialog, you should see a message about
-**Ask Gordon**.
-
-![Ask Gordon hint in Docker Desktop](../../images/gordon-run-ctr.png)
-
-The linked text in the hint is a suggested prompt to start a conversation with
-Ask Gordon.
-
-### Improve a Dockerfile
-
-Gordon can analyze your Dockerfile and suggest improvements. To have Gordon
-evaluate your Dockerfile using the `docker ai` command:
-
-1. Navigate to your project directory:
-
-   ```console
-   $ cd path/to/my/project
-   ```
-
-2. Use the `docker ai` command to rate your Dockerfile:
+Dockerfile review:
 
-   ```console
-   $ docker ai rate my Dockerfile
-   ```
-
-Gordon will analyze your Dockerfile and identify opportunities for improvement
-across several dimensions:
-
-- Build cache optimization
-- Security
-- Image size efficiency
-- Best practices compliance
-- Maintainability
-- Reproducibility
-- Portability
-- Resource efficiency
-
-## Disable Ask Gordon
-
-### For individual users
-
-If you've enabled Ask Gordon and you want to disable it again:
-
-1. Open the **Settings** view in Docker Desktop.
-2. Navigate to **Features in development**.
-3. Clear the **Enable Docker AI** checkbox.
-4. Select **Apply & restart**.
-
-### For organizations
-
-If you want to disable Ask Gordon for your entire Docker organization, using
-[Settings
-Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md),
-add the following property to your `admin-settings.json` file:
-
-```json
-{
-  "enableDockerAI": {
-    "value": false,
-    "locked": true
-  }
-}
+```console
+$ docker ai "review my Dockerfile for best practices"
 ```
 
-Alternatively, you can disable all Beta features by setting `allowBetaFeatures`
-to false:
+Image management:
 
-```json
-{
-  "allowBetaFeatures": {
-    "value": false,
-    "locked": true
-  }
-}
+```console
+$ docker ai "list my local images and their sizes"
 ```
-
-## Feedback
-
-<!-- vale Docker.We = NO -->
-
-We value your input on Ask Gordon and encourage you to share your experience.
-Your feedback helps us improve and refine Ask Gordon for all users. If you
-encounter issues, have suggestions, or simply want to share what you like,
-here's how you can get in touch:
-
-- Thumbs-up and thumbs-down buttons
-
-  Rate Ask Gordon's responses using the thumbs-up or thumbs-down buttons in the
-  response.
-
-- Feedback survey
-
-  You can access the Ask Gordon survey by following the _Give feedback_ link in
-  the **Ask Gordon** view in Docker Desktop, or from the CLI by running the
-  `docker ai feedback` command.
-
-
diff --git a/content/manuals/ai/gordon/concepts/_index.md b/content/manuals/ai/gordon/concepts/_index.md
new file mode 100644
index 000000000000..ea6852be5702
--- /dev/null
+++ b/content/manuals/ai/gordon/concepts/_index.md
@@ -0,0 +1,6 @@
+---
+build:
+  render: never
+title: Concepts
+weight: 20
+---
diff --git a/content/manuals/ai/gordon/concepts/capabilities.md b/content/manuals/ai/gordon/concepts/capabilities.md
new file mode 100644
index 000000000000..ac0c190772e9
--- /dev/null
+++ b/content/manuals/ai/gordon/concepts/capabilities.md
@@ -0,0 +1,93 @@
+---
+title: Gordon's capabilities
+linkTitle: Capabilities
+description: Understand what Gordon can do and the tools it has access to
+weight: 10
+---
+
+{{< summary-bar feature_name="Gordon" >}}
+
+Gordon combines multiple capabilities to handle Docker workflows. This page
+explains what Gordon can do and the tools it uses.
+
+## Core capabilities
+
+Gordon uses five capabilities to take action on your behalf:
+
+- Specialized sub-agents for specific Docker tasks
+- Shell access to run commands
+- Filesystem access to read and write files
+- Knowledge base of Docker documentation and best practices
+- Web access to fetch external resources
+
+## Internal architecture
+
+Gordon uses a primary agent that handles most tasks, with a specialized
+sub-agent for specific workflows:
+
+- **Main agent**: Handles all Docker operations, software development,
+  containerization, and general development tasks
+- **DHI migration sub-agent**: Specialized handler for migrating Dockerfiles to
+  Docker Hardened Images
+
+The main agent handles:
+
+- Creating Docker assets (Dockerfile, compose.yaml, .dockerignore)
+- Optimizing Dockerfiles to reduce image size and improve build performance
+- Running Docker commands (ps, logs, exec, build, compose)
+- Debugging container issues and analyzing configurations
+- Writing and reviewing code across multiple programming languages
+- General development questions and tasks
+
+When you request DHI migration, Gordon automatically delegates to the DHI
+migration sub-agent.
+
+## Shell access
+
+Gordon executes shell commands in your environment after you approve them.
+This includes Docker CLI commands, system utilities, and application-specific
+tools.
+
+Example commands Gordon might run:
+
+```console
+$ docker ps
+$ docker logs container-name
+$ docker exec -it container-name bash
+$ grep "error" app.log
+```
+
+Commands run with your user permissions. Gordon cannot access `sudo` unless
+you've explicitly granted it.
+
+## Filesystem access
+
+Gordon reads and writes files on your system. It can analyze Dockerfiles, read
+configuration files, scan directories, and parse logs without approval. Writing
+files requires your approval.
+
+The working directory sets the default context for file operations, but Gordon
+can access files outside this directory when needed.
+
+## Knowledge base
+
+Gordon uses retrieval-augmented generation to access Docker documentation,
+best practices, troubleshooting procedures, and security recommendations. This
+lets Gordon answer questions accurately, explain errors, and suggest
+solutions that follow Docker's guidelines.
+
+## Web access
+
+Gordon fetches external web resources to look up error messages, package
+versions, and framework documentation. This helps when debugging issues that
+require context outside Docker's own documentation.
+
+Gordon cannot access authenticated or private resources, and external requests
+are rate-limited.
+
+## Working with other tools
+
+Gordon complements general-purpose AI coding assistants by focusing on Docker
+workflows. Use tools like Cursor or GitHub Copilot for application code and
+refactoring, and use Gordon for containerization, deployment configuration,
+and Docker operations. They work well together.
diff --git a/content/manuals/ai/gordon/concepts/data-privacy.md b/content/manuals/ai/gordon/concepts/data-privacy.md
new file mode 100644
index 000000000000..38f5a5b49acb
--- /dev/null
+++ b/content/manuals/ai/gordon/concepts/data-privacy.md
@@ -0,0 +1,124 @@
+---
+title: Data privacy and Gordon
+linkTitle: Data privacy
+description: How Gordon handles your data and what information is collected
+weight: 30
+---
+
+{{< summary-bar feature_name="Gordon" >}}
+
+This page explains what data Gordon accesses, how it's used, and what privacy
+protections are in place.
+
+## What data Gordon accesses
+
+When you use Gordon, the data it accesses depends on your query and
+configuration.
+
+### Local files
+
+When you use the `docker ai` command, Gordon can access files and directories
+on your system. The working directory sets the default context for file
+operations.
+
+In Docker Desktop, if you ask about a specific file or directory in the Gordon
+view, you'll be prompted to select the relevant context.
+
+### Local images
+
+Gordon integrates with Docker Desktop and can view all images in your local
+image store. This includes images you've built or pulled from a registry.
+
+### Docker environment
+
+Gordon has access to your Docker daemon's state, including:
+
+- Running and stopped containers
+- Container logs and configuration
+- Images and image layers
+- Volumes and networks
+- Build cache
+
+## Data retention policy
+
+Gordon's data retention differs based on your subscription tier:
+
+### Paid subscriptions
+
+Docker and its AI providers do not retain any inputs or outputs from your
+Gordon sessions. Your queries, Gordon's responses, and any code or files
+processed are not stored. This applies to all paid subscriptions: Docker
+Desktop plans (Pro, Team, Business) and Gordon plans (Plus, Max, Ultra).
+
+### Personal (free) subscription
+
+Anonymized conversation threads are stored for 5 days to help guarantee
+quality of service and fight abuse. Individual queries and responses are
+retained as part of your conversation history.
+
+### All subscriptions
+
+Data is never used for training AI models or shared with third parties. All
+data transferred to Gordon's backend is encrypted in transit. Docker's
+third-party AI providers process requests under zero-data-retention
+agreements: they don't store your prompts or Gordon's responses.
+
+## Sensitive data protection
+
+Gordon automatically detects and redacts secrets and other sensitive material
+from your requests using [portcullis](https://github.com/docker/portcullis),
+Docker's open source redaction library. Around 240 patterns are covered,
+including:
+
+- Cloud provider credentials (AWS, GCP, Azure, and others)
+- API tokens (GitHub, GitLab, Docker Hub, Slack, OpenAI, Stripe, and more)
+- PEM private keys and JWTs
+- Database connection-string passwords
+- Payment card numbers, IBANs, and US Social Security numbers
+
+Detected values are replaced with `[REDACTED]` before your request is
+processed.
+
+## Data security
+
+Your data is protected through encryption in transit. For paid subscriptions,
+no persistent storage occurs—Gordon processes your requests and discards the
+data immediately.
+
+For questions about privacy terms and conditions, review [Gordon's
+Supplemental
+Terms](https://www.docker.com/legal/docker-ai-supplemental-terms/).
+
+## Organizational data policies
+
+For Business subscriptions, administrators can enable or disable Gordon for
+their organization using Settings Management. Review your organization's data
+handling requirements before enabling Gordon.
+
+See [Settings Management](/enterprise/security/hardened-desktop/settings-management/)
+for configuration details.
+
+## Disabling Gordon
+
+You can disable Gordon at any time:
+
+Individual users:
+
+1. Open Docker Desktop Settings.
+2. Navigate to the **AI** section.
+3. Clear the **Enable Gordon** option.
+4. Select **Apply**.
+
+Business organizations:
+
+Administrators can disable Gordon for the entire organization using Settings
+Management. See [Settings Management](/enterprise/security/hardened-desktop/settings-management/)
+for details.
+
+## Questions about privacy
+
+For questions about Docker's privacy practices:
+
+- Review the [Docker Privacy Policy](https://www.docker.com/legal/privacy/)
+- Read [Gordon's Supplemental Terms](https://www.docker.com/legal/docker-ai-supplemental-terms/)
+- Contact Docker Support for specific concerns
diff --git a/content/manuals/ai/gordon/how-to/_index.md b/content/manuals/ai/gordon/how-to/_index.md
new file mode 100644
index 000000000000..1bf572db1540
--- /dev/null
+++ b/content/manuals/ai/gordon/how-to/_index.md
@@ -0,0 +1,6 @@
+---
+build:
+  render: never
+title: How-to guides
+weight: 30
+---
diff --git a/content/manuals/ai/gordon/how-to/cli.md b/content/manuals/ai/gordon/how-to/cli.md
new file mode 100644
index 000000000000..e3f22aba1f31
--- /dev/null
+++ b/content/manuals/ai/gordon/how-to/cli.md
@@ -0,0 +1,87 @@
+---
+title: Using Gordon via CLI
+linkTitle: CLI
+description: Access and use Gordon through the docker ai command
+weight: 20
+---
+
+{{< summary-bar feature_name="Gordon" >}}
+
+The `docker ai` command provides a Terminal User Interface (TUI) for Gordon,
+integrating AI assistance directly into your terminal.
+
+## Basic usage
+
+Launch the interactive TUI:
+
+```console
+$ docker ai
+```
+
+This opens Gordon's terminal interface where you can type prompts, approve
+actions, and continue conversations with full context.
+
+<script src="https://asciinema.org/a/9kvZFH9LO9ZVDpwS.js" id="asciicast-9kvZFH9LO9ZVDpwS" async="true"></script>
+
+Pass a prompt directly as an argument:
+
+```console
+$ docker ai "list my running containers"
+```
+
+Exit the TUI with `/exit` or <kbd>Ctrl+C</kbd>.
+
+## Working directory
+
+The working directory sets the default context for Gordon's file operations.
+
+Gordon uses your current shell directory as the working directory:
+
+```console
+$ cd ~/my-project
+$ docker ai
+```
+
+Override with `-C` or `--working-dir`:
+
+```console
+$ docker ai -C ~/different-project
+```
+
+## Disabling Gordon
+
+Gordon CLI is part of Docker Desktop. To disable it, disable Gordon in Docker
+Desktop Settings:
+
+1. Open Docker Desktop Settings.
+2. Navigate to the **AI** section.
+3. Clear the **Enable Gordon** option.
+4. Select **Apply**.
+
+## Commands
+
+The `docker ai` command includes several subcommands:
+
+Interactive mode (default):
+
+```console
+$ docker ai
+```
+
+Opens the TUI for conversational interaction.
+
+Version:
+
+```console
+$ docker ai version
+```
+
+Displays the Gordon version.
+
+Feedback:
+
+```console
+$ docker ai feedback
+```
+
+Opens a feedback form in your browser.
diff --git a/content/manuals/ai/gordon/how-to/configure-tools.md b/content/manuals/ai/gordon/how-to/configure-tools.md
new file mode 100644
index 000000000000..90c3b6ae11f7
--- /dev/null
+++ b/content/manuals/ai/gordon/how-to/configure-tools.md
@@ -0,0 +1,81 @@
+---
+title: Configure Gordon's tools
+linkTitle: Configure tools
+description: Enable and disable Gordon's built-in tools based on your needs
+weight: 40
+---
+
+{{< summary-bar feature_name="Gordon" >}}
+
+Gordon includes built-in tools that extend its capabilities. You can configure
+which tools Gordon has access to based on your security requirements and
+workflow needs.
+
+Tool configuration provides an additional layer of control:
+
+- Enabled tools: Gordon can propose actions using these tools (subject to
+  your approval)
+- Disabled tools: Gordon cannot use these tools, and will not request
+  permission to use them
+
+## Accessing tool settings
+
+To configure Gordon's tools:
+
+1. Open Docker Desktop.
+2. Select **Gordon** in the sidebar.
+3. Select the settings icon at the bottom of the text input area.
+
+   ![Session settings icon](../images/gordon_permission_settings.avif)
+
+The tool settings dialog opens with two tabs: **Basic** and **Advanced**.
+
+## Basic tool settings
+
+In the **Basic** tab, you can enable or disable individual tools globally.
+
+To disable a tool:
+
+1. Find the tool you want to disable in the list.
+2. Toggle it off.
+3. Select **Save**.
+
+Disabled tools cannot be used by Gordon, even with your approval.
+
+## Advanced tool settings
+
+The **Advanced** tab lets you create fine-grained allow-lists and deny-lists
+for specific commands or patterns.
+
+Allow-lists:
+Gordon can use allow-listed commands even when the main tool is disabled. For
+example, disable the shell tool but allow `cat`, `grep`, and `ls`.
+
+Deny-lists:
+Block specific commands while keeping the tool enabled. For example, allow the
+shell tool but deny `chown` and `chmod`.
+
+To configure:
+
+1. Switch to the **Advanced** tab.
+2. Add commands to **Allow rules** or **Deny rules**.
+3. Select **Save**.
+
+![Advanced tool configuration](../images/gordon_advanced_tool_config.avif)
+
+Gordon still requests approval before running allow-listed tools, unless YOLO
+mode (auto-approve mode that bypasses permission checks) is enabled.
+
+## Organizational controls
+
+For Business subscriptions, administrators can control tool access for the
+entire organization using Settings Management.
+
+Administrators can:
+
+- Disable specific tools for all users
+- Lock tool configuration to prevent users from changing it
+- Set organization-wide tool policies
+
+See [Settings Management](/enterprise/security/hardened-desktop/settings-management/)
+for details.
diff --git a/content/manuals/ai/gordon/how-to/docker-desktop.md b/content/manuals/ai/gordon/how-to/docker-desktop.md
new file mode 100644
index 000000000000..1586bdbccab7
--- /dev/null
+++ b/content/manuals/ai/gordon/how-to/docker-desktop.md
@@ -0,0 +1,57 @@
+---
+title: Using Gordon in Docker Desktop
+linkTitle: Docker Desktop
+description: Access and use Gordon through the Docker Desktop graphical interface
+weight: 10
+---
+
+{{< summary-bar feature_name="Gordon" >}}
+
+Gordon is integrated into Docker Desktop. Access it from the sidebar to open
+the Gordon view.
+
+## Basic usage
+
+To access Gordon:
+
+1. Open Docker Desktop and sign in to your Docker account.
+2. Select **Gordon** in the sidebar.
+3. Type your question or request in the input field.
+4. Press <kbd>Enter</kbd> or select the send button.
+
+Gordon responds in the chat view and maintains context throughout the session.
+
+## Working directory
+
+The working directory sets the default context for Gordon's file operations.
+Select your working directory when you start Gordon or use the directory icon
+to change it during a conversation:
+
+1. Select the directory icon in the Gordon input area.
+2. Browse and select a different directory.
+
+## Contextual help
+
+The Gordon icon appears throughout Docker Desktop. Selecting it opens Gordon
+pre-loaded with context about the item you are working with, such as container
+logs or build output.
+
+## Usage indicator
+
+Docker Desktop shows a usage indicator so you can see how close you are to
+your tier limit. See [Usage limits and tiers](../usage-limits.md) for details.
+
+## Disabling Gordon
+
+To disable Gordon:
+
+1. Open Docker Desktop Settings.
+2. Navigate to the **AI** section.
+3. Clear the **Enable Gordon** option.
+4. Select **Apply**.
+
+## Configure tools
+
+You can control which tools Gordon has access to. See [Configure
+tools](./configure-tools.md) for details on enabling, disabling, and
+fine-tuning tool permissions.
diff --git a/content/manuals/ai/gordon/how-to/permissions.md b/content/manuals/ai/gordon/how-to/permissions.md
new file mode 100644
index 000000000000..3e08cfb3c58a
--- /dev/null
+++ b/content/manuals/ai/gordon/how-to/permissions.md
@@ -0,0 +1,125 @@
+---
+title: Gordon's permission model
+linkTitle: Permissions
+description: How Gordon's ask-first approach keeps you in control
+weight: 30
+---
+
+{{< summary-bar feature_name="Gordon" >}}
+
+Before Gordon uses a tool or action that can modify your system, it proposes
+the action and waits for your approval before executing.
+
+## What requires approval
+
+By default, the following actions require approval before Gordon can use them:
+
+- Commands executed in your shell
+- Writing or changing files
+- Fetching information from the internet
+
+## What doesn't require approval
+
+- Reading files, listing directories (even outside Gordon's working directory)
+- Searching the Docker documentation
+- Analyzing code or explaining errors
+
+## Configuring permission settings
+
+To change the default permission settings for Gordon:
+
+1. Open Docker Desktop.
+2. Select **Gordon** in the sidebar.
+3. Select the settings icon at the bottom of text input.
+
+   ![Session settings icon](../images/gordon_permission_settings.avif)
+
+In the **Basic** tab you can configure whether Gordon should ask for permission
+before using a tool.
+
+You can also enable YOLO mode to bypass permission checking altogether.
+
+The new permission settings apply immediately to all sessions.
+
+## Session-level permissions
+
+When you choose "Approve for this session" (Desktop) or "A" (CLI), Gordon can
+use that specific tool without asking again during the current conversation.
+
+Example:
+
+```console
+$ docker ai "check my containers and clean up stopped ones"
+
+Gordon proposes:
+  docker ps -a
+
+Approve? [Y/n/a]: a
+
+[Gordon executes docker ps -a]
+
+Gordon proposes:
+  docker container prune -f
+
+[Executes automatically - you approved shell access for this session]
+```
+
+Session permissions reset when:
+
+- You close the Gordon view (Desktop)
+- You exit `docker ai` (CLI)
+- You start a new conversation
+
+## Security considerations
+
+Working directory
+: The working directory sets the default context for file operations. It does
+  not constrain Gordon's access to files or directories; Gordon can read files
+  outside this directory.
+
+Verify before approving
+: Gordon can make mistakes. Before approving:
+
+  - Confirm commands match your intent
+  - Check container names and image tags are correct
+  - Verify volume mounts and port mappings
+  - Review file changes for important logic
+
+  If you don't understand an operation, ask Gordon to explain it or reject and
+  request a different approach.
+
+Destructive operations
+: Gordon warns about destructive operations but won't prevent them. Operations
+  like `docker container rm`, `docker system prune`, and `docker volume rm` can
+  cause permanent data loss. Back up important data first.
+
+## Stopping and reverting
+
+Stop Gordon during execution by pressing `Ctrl+C` (CLI) or selecting **Cancel**
+(Desktop).
+
+Revert Gordon's actions using Docker commands or version control:
+
+- Restore files from Git
+- Restart stopped containers
+- Rebuild images
+- Recreate volumes from backups
+
+Use version control for all files in your working directory.
+
+## Organizational controls
+
+Administrators can control Gordon's capabilities at the organization level
+using Settings Management.
+
+Available controls:
+
+- Disable Gordon entirely
+- Restrict tool capabilities
+- Set working directory boundaries
+
+For Business subscriptions, Gordon must be enabled by an administrator before
+users can access it.
+
+See [Settings Management](/enterprise/security/hardened-desktop/settings-management/)
+for details.
diff --git a/content/manuals/ai/gordon/images/delete.webp b/content/manuals/ai/gordon/images/delete.webp
deleted file mode 100644
index e939fb150e69..000000000000
Binary files a/content/manuals/ai/gordon/images/delete.webp and /dev/null differ
diff --git a/content/manuals/ai/gordon/images/gordon.webp b/content/manuals/ai/gordon/images/gordon.webp
deleted file mode 100644
index ebf97291489d..000000000000
Binary files a/content/manuals/ai/gordon/images/gordon.webp and /dev/null differ
diff --git a/content/manuals/ai/gordon/images/gordon_advanced_tool_config.avif b/content/manuals/ai/gordon/images/gordon_advanced_tool_config.avif
new file mode 100644
index 000000000000..2b02955daa46
Binary files /dev/null and b/content/manuals/ai/gordon/images/gordon_advanced_tool_config.avif differ
diff --git a/content/manuals/ai/gordon/images/gordon_gui.avif b/content/manuals/ai/gordon/images/gordon_gui.avif
new file mode 100644
index 000000000000..5b77c21d56cc
Binary files /dev/null and b/content/manuals/ai/gordon/images/gordon_gui.avif differ
diff --git a/content/manuals/ai/gordon/images/gordon_permission_settings.avif b/content/manuals/ai/gordon/images/gordon_permission_settings.avif
new file mode 100644
index 000000000000..eea123b3e84e
Binary files /dev/null and b/content/manuals/ai/gordon/images/gordon_permission_settings.avif differ
diff --git a/content/manuals/ai/gordon/images/gordon_permissions_prompt.avif b/content/manuals/ai/gordon/images/gordon_permissions_prompt.avif
new file mode 100644
index 000000000000..8ddbf4e91304
Binary files /dev/null and b/content/manuals/ai/gordon/images/gordon_permissions_prompt.avif differ
diff --git a/content/manuals/ai/gordon/images/gordon_tui.avif b/content/manuals/ai/gordon/images/gordon_tui.avif
new file mode 100644
index 000000000000..e429b2aae814
Binary files /dev/null and b/content/manuals/ai/gordon/images/gordon_tui.avif differ
diff --git a/content/manuals/ai/gordon/images/toolbox.webp b/content/manuals/ai/gordon/images/toolbox.webp
deleted file mode 100644
index ae8fcf006804..000000000000
Binary files a/content/manuals/ai/gordon/images/toolbox.webp and /dev/null differ
diff --git a/content/manuals/ai/gordon/mcp/_index.md b/content/manuals/ai/gordon/mcp/_index.md
deleted file mode 100644
index af49c24ed450..000000000000
--- a/content/manuals/ai/gordon/mcp/_index.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: MCP
-description: Learn how to use MCP servers with Gordon
-keywords: ai, mcp, gordon, docker desktop, docker, llm, 
-grid:
-- title: Built-in tools
-  description: Use the built-in tools.
-  icon: construction
-  link: /ai/gordon/mcp/built-in-tools
-- title: MCP configuration
-  description: Configure MCP tools on a per-project basis.
-  icon: manufacturing
-  link: /ai/gordon/mcp/yaml
-- title: MCP Server
-  description: Use Gordon as an MCP server
-  icon: dns
-  link: /ai/gordon/mcp/gordon-mcp-server/
-aliases:
- - /desktop/features/gordon/mcp/
----
-
-## What is MCP?
-
-[Model Context Protocol](https://modelcontextprotocol.io/introduction) (MCP) is
-an open protocol that standardizes how applications provide context and extra
-functionality to large language models. MCP functions as a client-server
-protocol, where the client, for example an application like Gordon, sends
-requests, and the server processes those requests to deliver the necessary
-context to the AI. This context may be gathered by the MCP server by executing
-some code to perform an action and getting the result of the action, calling
-external APIs, etc.
-
-Gordon, along with other MCP clients like Claude Desktop or Cursor, can interact
-with MCP servers running as containers.
-
-{{< grid >}}
\ No newline at end of file
diff --git a/content/manuals/ai/gordon/mcp/built-in-tools.md b/content/manuals/ai/gordon/mcp/built-in-tools.md
deleted file mode 100644
index 9fd76880ac10..000000000000
--- a/content/manuals/ai/gordon/mcp/built-in-tools.md
+++ /dev/null
@@ -1,238 +0,0 @@
----
-title: Built-in tools
-description: How to use Gordon's built-in tools
-keywords: ai, mcp, gordon
-aliases:
- - /desktop/features/gordon/mcp/built-in-tools/
----
-
-Gordon comes with an integrated toolbox providing access to various system tools
-and capabilities. These tools extend Gordon's functionality by allowing it to
-interact with the Docker Engine, Kubernetes, Docker Scout's security scanning,
-and other developer utilities. This documentation covers the available tools,
-their configuration, and usage patterns.
-
-## Configuration
-
-Tools can be configured globally in the toolbox, making them accessible
-throughout the Gordon interfaces, including both Docker Desktop and the CLI.
-
-To configure:
-
-1. On the **Ask Gordon** view in Docker Desktop, select the `Toolbox` button in the bottom left of the input area.
-
-   ![Gordon page with the toolbox button](../images/gordon.webp)
-
-2. Choose the tools you want to make available. Selecting a card lets you view extra information regarding each tool and what it does.
-
-   ![Gordon's Toolbox](../images/toolbox.webp)
-
-   For more information on the possible tools, see [Reference](#reference).
-
-## Usage examples
-
-This section provides task-oriented examples for common operations with Gordon
-tools.
-
-### Managing Docker containers
-
-#### List and monitor containers
-
-```console
-# List all running containers
-$ docker ai "Show me all running containers"
-
-# List containers using specific resources
-$ docker ai "List all containers using more than 1GB of memory"
-
-# View logs from a specific container
-$ docker ai "Show me logs from my running api-container from the last hour"
-```
-
-#### Manage container lifecycle
-
-```console
-# Run a new container
-$ docker ai "Run a nginx container with port 80 exposed to localhost"
-
-# Stop a specific container
-$ docker ai "Stop my database container"
-
-# Clean up unused containers
-$ docker ai "Remove all stopped containers"
-```
-
-### Working with Docker images
-
-```console
-# List available images
-$ docker ai "Show me all my local Docker images"
-
-# Pull a specific image
-$ docker ai "Pull the latest Ubuntu image"
-
-# Build an image from a Dockerfile
-$ docker ai "Build an image from my current directory and tag it as myapp:latest"
-
-# Clean up unused images
-$ docker ai "Remove all my unused images"
-```
-
-### Managing Docker volumes
-
-```console
-# List volumes
-$ docker ai "List all my Docker volumes"
-
-# Create a new volume
-$ docker ai "Create a new volume called postgres-data"
-
-# Backup data from a container to a volume
-$ docker ai "Create a backup of my postgres container data to a new volume"
-```
-
-### Kubernetes operations
-
-```console
-# Create a deployment
-$ docker ai "Create an nginx deployment and make sure it's exposed locally"
-
-# List resources
-$ docker ai "Show me all deployments in the default namespace"
-
-# Get logs
-$ docker ai "Show me logs from the auth-service pod"
-```
-
-### Security analysis
-
-
-```console
-# Scan  for CVEs
-$ docker ai "Scan my application for security vulnerabilities"
-
-# Get security recommendations
-$ docker ai "Give me recommendations for improving the security of my nodejs-app image"
-```
-
-### Development workflows
-
-```console
-# Analyze and commit changes
-$ docker ai "Look at my local changes, create multiple commits with sensible commit messages"
-
-# Review branch status
-$ docker ai "Show me the status of my current branch compared to main"
-```
-
-## Reference
-
-This section provides a comprehensive listing of the built-in tools you can find
-in Gordon's toolbox.
-
-### Docker tools
-
-Tools to interact with your Docker containers, images, and volumes.
-
-#### Container management
-
-| Name | Description |
-|------|-------------|
-| `list_containers` | List all Docker containers |
-| `remove_containers` | Remove one or more Docker containers |
-| `stop_container` | Stop a running Docker container |
-| `fetch_container_logs` | Retrieve logs from a Docker container |
-| `run_container` | Run a new Docker container |
-
-#### Volume management
-
-| Tool | Description |
-|------|-------------|
-| `list_volumes` | List all Docker volumes |
-| `remove_volume` | Remove a Docker volume |
-| `create_volume` | Create a new Docker volume |
-
-#### Image management
-
-| Tool | Description |
-|------|-------------|
-| `list_images` | List all Docker images |
-| `remove_images` | Remove Docker images |
-| `pull_image` | Pull an image from a registry |
-| `push_image` | Push an image to a registry |
-| `build_image` | Build a Docker image |
-| `tag_image` | Tag a Docker image |
-| `inspect` | Inspect a Docker object |
-
-### Kubernetes tools
-
-Tools to interact with your Kubernetes cluster
-
-#### Pods
-
-| Tool | Description |
-|------|-------------|
-| `list_pods` | List all pods in the cluster |
-| `get_pod_logs` | Get logs from a specific pod |
-
-#### Deployment management
-
-
-| Tool | Description |
-|------|-------------|
-| `list_deployments` | List all deployments |
-| `create_deployment` | Create a new deployment |
-| `expose_deployment` | Expose a deployment as a service |
-| `remove_deployment` | Remove a deployment |
-
-#### Service management
-
-| Tool | Description |
-|------|-------------|
-| `list_services` | List all services |
-| `remove_service` | Remove a service |
-
-#### Cluster information
-
-| Tool | Description |
-|------|-------------|
-| `list_namespaces` | List all namespaces |
-| `list_nodes` | List all nodes in the cluster |
-
-### Docker Scout tools
-
-Security analysis tools powered by Docker Scout.
-
-| Tool | Description |
-|------|-------------|
-| `search_for_cves` | Analyze a Docker image, a project directory, or other artifacts for vulnerabilities using Docker Scout CVEs.search for cves |
-| `get_security_recommendations` | Analyze a Docker image, a project directory, or other artifacts for base image update recommendations using Docker Scout. |
-
-### Developer tools
-
-General-purpose development utilities.
-
-| Tool | Description |
-|------|-------------|
-| `fetch` | Retrieve content from a URL |
-| `get_command_help` | Get help for CLI commands |
-| `run_command` | Execute shell commands |
-| `filesystem` | Perform filesystem operations |
-| `git` | Execute git commands |
-
-### AI model tools
-
-| Tool | Description |
-|------|-------------|
-| `list_models` | List all available AI models |
-| `pull_model` | Download an AI model |
-| `run_model` | Query a model with a prompt |
-| `remove_model` | Remove an AI model |
-
-### AI Tool Catalog
-
-When the [AI Tool
-Catalog](https://open.docker.com/extensions/marketplace?extensionId=docker/labs-ai-tools-for-devs)
-Docker Desktop extension is installed, all the tools enabled in the catalog are
-available for Gordon to use. After installation, you can enable the usage of the
-AI Tool Catalog tools in the toolbox section of Gordon.
diff --git a/content/manuals/ai/gordon/mcp/gordon-mcp-server.md b/content/manuals/ai/gordon/mcp/gordon-mcp-server.md
deleted file mode 100644
index 39a163ca87d8..000000000000
--- a/content/manuals/ai/gordon/mcp/gordon-mcp-server.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: Gordon as an MCP server
-description: How to use Gordon as an MCP server
-keywords: ai, mcp, gordon
-aliases:
- - /desktop/features/gordon/mcp/gordon-mcp-server/
----
-
-## Gordon as an MCP server
-
-In addition to functioning as an MCP client, Gordon can also act as an MCP
-server. This means that all the tools configured in the toolbox section of
-Gordon can be exposed to another MCP client like Claude Desktop, Cursor and
-others.
-
-To use Gordon’s built-in tools in other MCP clients, configure your client of
-choice to use the `docker ai mcpserver` command. This allows Gordon to serve its
-built-in tools via the MCP protocol for various clients.
-
-For example, to enable Gordon’s tools in Claude Desktop, add the following
-configuration to the Claude configuration file:
-
-```json
-{
-  "mcpServers": {
-    "gordon": {
-      "command": "docker",
-      "args": ["ai", "mcpserver"]
-    }
-  }
-}
-```
-
-This setup ensures that Claude Desktop can communicate with Gordon as an MCP
-server, leveraging its built-in tools. You can follow the [Claude Desktop
-documentation](https://modelcontextprotocol.io/quickstart/user) to explore
-further.
-
-### Tool permissions and security
-
-These tools operate with the same permissions as the user running the
-application.
-
-Any potentially destructive tool call, changing files, deleting images or
-stopping containers will ask for your confirmation before proceeding.
-
-![Gordon page with the delete confirmation question](../images/delete.webp)
diff --git a/content/manuals/ai/gordon/mcp/yaml.md b/content/manuals/ai/gordon/mcp/yaml.md
deleted file mode 100644
index 326c5d6071a2..000000000000
--- a/content/manuals/ai/gordon/mcp/yaml.md
+++ /dev/null
@@ -1,173 +0,0 @@
----
-title: YAML configuration
-description: Learn how to use MCP servers with Gordon
-keywords: ai, mcp, gordon
-aliases: 
- - /desktop/features/gordon/mcp/yaml/
----
-
-Docker has partnered with Anthropic to build container images for the [reference
-implementations](https://github.com/modelcontextprotocol/servers/) of MCP
-servers available on Docker Hub under [the mcp
-namespace](https://hub.docker.com/u/mcp).
-
-When you run the `docker ai` command in your terminal to ask a question, Gordon
-looks in the `gordon-mcp.yml` file in your working directory (if present) for a
-list of MCP servers that should be used when in that context. The
-`gordon-mcp.yml` file is a Docker Compose file that configures MCP servers as
-Compose services for Gordon to access.
-
-The following minimal example shows how you can use the [mcp-time
-server](https://hub.docker.com/r/mcp/time) to provide temporal capabilities to
-Gordon. For more information, you can check out the [source code and
-documentation](https://github.com/modelcontextprotocol/servers/tree/main/src/time).
-
-Create the `gordon-mcp.yml` file in your working directory and add the time
-   server:
-
-```yaml
-services:
-  time:
-    image: mcp/time
-```
-
-With this file present, you can now ask Gordon to tell you the time in
-   another timezone:
-
-  ```bash
-  $ docker ai 'what time is it now in kiribati?'
-  
-      • Calling get_current_time
-  
-    The current time in Kiribati (Tarawa) is 9:38 PM on January 7, 2025.
-  
-  ```
-
-As you can see, Gordon found the MCP time server and called its tool when
-needed.
-
-## Advanced usage
-
-Some MCP servers need access to your filesystem or system environment variables.
-Docker Compose can help with this. Since `gordon-mcp.yml` is a Compose file you
-can add bind mounts using the regular Docker Compose syntax, which makes your
-filesystem resources available to the container:
-
-```yaml
-services:
-  fs:
-    image: mcp/filesystem
-    command:
-      - /rootfs
-    volumes:
-      - .:/rootfs
-```
-
-The `gordon-mcp.yml` file adds filesystem access capabilities to Gordon and
-since everything runs inside a container Gordon only has access to the
-directories you specify.
-
-Gordon can handle any number of MCP servers. For example, if you give Gordon
-access to the internet with the `mcp/fetch` server:
-
-```yaml
-services:
-  fetch:
-    image: mcp/fetch
-  fs:
-    image: mcp/filesystem
-    command:
-      - /rootfs
-    volumes:
-      - .:/rootfs
-```
-
-You can now ask things like:
-
-```bash
-$ docker ai can you fetch rumpl.dev and write the summary to a file test.txt 
-
-    • Calling fetch ✔️
-    • Calling write_file ✔️
-  
-  The summary of the website rumpl.dev has been successfully written to the file test.txt in the allowed directory. Let me know if you need further assistance!
-
-
-$ cat test.txt 
-The website rumpl.dev features a variety of blog posts and articles authored by the site owner. Here's a summary of the content:
-
-1. **Wasmio 2023 (March 25, 2023)**: A recap of the WasmIO 2023 conference held in Barcelona. The author shares their experience as a speaker and praises the organizers for a successful event.
-
-2. **Writing a Window Manager in Rust - Part 2 (January 3, 2023)**: The second part of a series on creating a window manager in Rust. This installment focuses on enhancing the functionality to manage windows effectively.
-
-3. **2022 in Review (December 29, 2022)**: A personal and professional recap of the year 2022. The author reflects on the highs and lows of the year, emphasizing professional achievements.
-
-4. **Writing a Window Manager in Rust - Part 1 (December 28, 2022)**: The first part of the series on building a window manager in Rust. The author discusses setting up a Linux machine and the challenges of working with X11 and Rust.
-
-5. **Add docker/docker to your dependencies (May 10, 2020)**: A guide for Go developers on how to use the Docker client library in their projects. The post includes a code snippet demonstrating the integration.
-
-6. **First (October 11, 2019)**: The inaugural post on the blog, featuring a simple "Hello World" program in Go.
-```
-
-## What’s next?
-
-Now that you’ve learned how to use MCP servers with Gordon, here are a few ways
-you can get started:
-
-- Experiment: Try integrating one or more of the tested MCP servers into your
-  `gordon-mcp.yml` file and explore their capabilities.
-- Explore the ecosystem: Check out the [reference implementations on
-   GitHub](https://github.com/modelcontextprotocol/servers/) or browse the
-   [Docker Hub MCP namespace](https://hub.docker.com/u/mcp) for additional
-   servers that might suit your needs.
-- Build your own: If none of the existing servers meet your needs, or you’re
-   curious about exploring how they work in more detail, consider developing a
-   custom MCP server. Use the [MCP
-   specification](https://www.anthropic.com/news/model-context-protocol) as a
-   guide.
-- Share your feedback: If you discover new servers that work well with Gordon
-   or encounter issues with existing ones, [share your findings to help improve
-   the ecosystem](https://docker.qualtrics.com/jfe/form/SV_9tT3kdgXfAa6cWa).
-
-With MCP support, Gordon offers powerful extensibility and flexibility to meet
-your specific use cases whether you’re adding temporal awareness, file
-management, or internet access.
-
-### Compatible MCP servers
-
-These are MCP servers that have been tested with Gordon and are known to be
-working:
-
-- `mcp/time`
-- `mcp/fetch`
-- `mcp/filesystem`
-- `mcp/postgres`
-- `mcp/git`
-- `mcp/sqlite`
-- `mcp/github`
-
-### Untested (should work with appropriate API tokens)
-
-These are MCP servers that were not tested but should work if given the
-appropriate API tokens:
-
-- `mcp/brave-search`
-- `mcp/gdrive`
-- `mcp/slack`
-- `mcp/google-maps`
-- `mcp/gitlab`
-- `mcp/everything`
-- `mcp/aws-kb-retrieval-server`
-- `mcp/sentry`
-
-### Unsupported
-
-These are MCP servers that are currently known to be unsupported:
-
-- `mcp/sequentialthinking` - (The tool description is too long)
-- `mcp/puppeteer` - Puppeteer sends back images and Gordon doesn’t know how to
-  handle them, it only handles text responses from tools
-- `mcp/everart` - Everart sends back images and Gordon doesn’t know how to
-  handle them, it only handles text responses from tools
-- `mcp/memory` - There is no way to configure the server to use a custom path
-  for its knowledge base
diff --git a/content/manuals/ai/gordon/usage-limits.md b/content/manuals/ai/gordon/usage-limits.md
new file mode 100644
index 000000000000..73568fad124a
--- /dev/null
+++ b/content/manuals/ai/gordon/usage-limits.md
@@ -0,0 +1,49 @@
+---
+title: Gordon usage limits and tiers
+linkTitle: Usage limits
+description: Gordon subscription tiers and usage limits for Docker Desktop and the CLI
+weight: 50
+keywords: [gordon, usage, limits, tiers, base, plus, max, ultra, subscription]
+---
+
+{{< summary-bar feature_name="Gordon" >}}
+
+Gordon is included with every Docker account at the Base tier. Paid Gordon
+plans unlock higher usage limits.
+
+## Tiers
+
+| Tier  | Usage allocation                 |
+| ----- | -------------------------------- |
+| Base  | Included with any Docker account |
+| Plus  | 2× Base                          |
+| Max   | 5× Base                          |
+| Ultra | 10× Base                         |
+
+For more information about Gordon tiers and how to upgrade, go to
+[docker.com](https://www.docker.com/products/gordon).
+
+## Usage limits
+
+Gordon usage is measured in questions. The number you can ask depends on
+complexity: questions that involve more context, files, or Docker operations
+count more toward your limit.
+
+| Tier  | Per 4 hours | Per day | Per month |
+| ----- | ----------- | ------- | --------- |
+| Base  | ~40         | ~100    | ~180      |
+| Plus  | ~80         | ~200    | ~360      |
+| Max   | ~200        | ~500    | ~900      |
+| Ultra | ~400        | ~1000   | ~1800     |
+
+These are estimates and vary based on question complexity.
+
+Usage limits reset at fixed UTC times, not on a sliding window. The 4-hour
+window resets every 4 hours starting at 00:00 UTC, the daily window resets at
+00:00 UTC, and the monthly window resets on the first day of each calendar
+month at 00:00 UTC.
+
+## View your usage
+
+Docker Desktop shows a usage indicator so you can see how close you are to
+your limit. To get more usage, upgrade your tier.
diff --git a/content/manuals/ai/gordon/use-cases.md b/content/manuals/ai/gordon/use-cases.md
new file mode 100644
index 000000000000..460f3ddfc345
--- /dev/null
+++ b/content/manuals/ai/gordon/use-cases.md
@@ -0,0 +1,157 @@
+---
+title: Gordon use cases and examples
+linkTitle: Use cases
+description: Example prompts for common Docker workflows
+weight: 10
+---
+
+{{< summary-bar feature_name="Gordon" >}}
+
+Gordon handles Docker workflows through natural conversation. In Docker
+Desktop, Gordon is available from the sidebar for open-ended sessions and from
+contextual entry points in views like Containers, Images, Builds, and Volumes.
+Selecting Gordon from one of these views opens a conversation pre-loaded with
+context about the item you're looking at. You can ask the same questions from
+the CLI with `docker ai`.
+
+## Debug a failing container
+
+You're in the Containers view and a container has crashed or behaves
+unexpectedly. Open Gordon from the container row to ask about that container's
+state and configuration:
+
+- "Why did this container exit?"
+- "What environment variables are set in this container?"
+- "How long did this container run?"
+- "What security settings are applied to this container?"
+
+From the CLI:
+
+```console
+$ docker ai "why is my postgres container crashing on startup?"
+```
+
+## Debug a failed build
+
+You're in the Builds view looking at a build that failed or is slower than
+expected. Open Gordon from the build to inspect the Dockerfile, build
+arguments, and cache behavior:
+
+- "Why did this build fail?"
+- "How can I improve cache usage for this build?"
+- "What Dockerfile instructions were used?"
+- "What build arguments were used?"
+
+From the CLI:
+
+```console
+$ docker ai "my build is failing at the pip install step, what's wrong?"
+```
+
+## Inspect an image
+
+You're in the Images view and want to understand what's in an image before
+running it, or you want to size up a base image:
+
+- "How do I run this image in the CLI?"
+- "What environment variables are configured?"
+- "What entrypoint is configured?"
+- "What's the base architecture of this image?"
+- "Is there a lighter version of this image?"
+
+From the CLI:
+
+```console
+$ docker ai "compare my python:3.12 image to python:3.12-slim"
+```
+
+## Manage volumes and resources
+
+From the Volumes view, ask Gordon about what's stored, which containers use a
+volume, or how to clean up. From any view, use the Gordon sidebar to inspect
+your wider environment:
+
+- "Which containers are using this volume?"
+- "Show me all my containers and their status"
+- "How much disk space is Docker using?"
+- "List my images sorted by size"
+
+From the CLI:
+
+```console
+$ docker ai "clean up all unused Docker resources"
+```
+
+## Build and containerize
+
+For new projects, start a conversation in the Gordon sidebar or via `docker
+ai` from your project directory. Gordon reads your working directory and
+proposes the right files:
+
+- "Containerize my Node.js app"
+- "Create a docker-compose for my stack"
+- "Set up a dev environment with Postgres and Redis"
+
+From the CLI:
+
+```console
+$ cd ~/my-project
+$ docker ai "create a Dockerfile for this application"
+```
+
+## Develop and optimize
+
+Ask Gordon to review and improve existing Dockerfiles or service definitions.
+You can start from the Images view (for an image you've already built) or from
+the Gordon sidebar with your project context:
+
+- "Optimize this Dockerfile"
+- "Add a health check to my service"
+- "Make my Dockerfile more secure"
+
+From the CLI:
+
+```console
+$ docker ai "rate my Dockerfile and suggest improvements"
+```
+
+## Learn Docker
+
+For conceptual questions, use the Gordon sidebar or CLI. Gordon explains
+concepts grounded in your environment, not generic answers:
+
+- "What is a Docker volume?"
+- "Explain multi-stage builds"
+- "How does networking work in Docker?"
+
+From the CLI:
+
+```console
+$ docker ai "what's the difference between COPY and ADD in a Dockerfile?"
+```
+
+## Writing effective prompts
+
+Be specific:
+
+- Include relevant context: "my postgres container" not "the database"
+- State your goal: "make my build faster" not "optimize"
+- Include error messages when debugging
+
+Gordon works best when you describe what you want to achieve rather than how
+to do it. Gordon maintains context across a conversation, so you can follow up
+with clarifications or ask related questions without repeating yourself.
+
+### Working directory context
+
+When using `docker ai` in the CLI, Gordon uses your current working directory
+as the default context for file operations. Change to your project directory
+before starting Gordon to ensure it has access to the right files:
+
+```console
+$ cd ~/my-project
+$ docker ai "review my Dockerfile"
+```
+
+You can also override the working directory with the `-C` flag. See [Using
+Gordon via CLI](./how-to/cli.md#working-directory) for details.
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/_index.md b/content/manuals/ai/mcp-catalog-and-toolkit/_index.md
new file mode 100644
index 000000000000..5841670b91d1
--- /dev/null
+++ b/content/manuals/ai/mcp-catalog-and-toolkit/_index.md
@@ -0,0 +1,95 @@
+---
+title: Docker MCP Catalog and Toolkit
+linkTitle: MCP Catalog and Toolkit
+params:
+  sidebar:
+    group: AI and agents
+    badge:
+      color: blue
+      text: Beta
+weight: 20
+description: Learn about Docker's MCP catalog on Docker Hub
+keywords: Docker, ai, mcp servers, ai agents, extension, docker desktop, llm, docker hub
+grid:
+  - title: Get started with MCP Toolkit
+    description: Learn how to quickly install and use the MCP Toolkit to set up servers and clients.
+    icon: magnifying-glass-plus
+    link: /ai/mcp-catalog-and-toolkit/get-started/
+  - title: MCP Catalog
+    description: Browse Docker's curated collection of verified MCP servers
+    icon: globe-alt
+    link: /ai/mcp-catalog-and-toolkit/catalog/
+  - title: MCP Profiles
+    description: Organize servers into profiles for different projects and share configurations
+    icon: folder
+    link: /ai/mcp-catalog-and-toolkit/profiles/
+  - title: MCP Toolkit
+    description: Use Docker Desktop's UI to discover, configure, and manage MCP servers
+    icon: /icons/toolkit.svg
+    link: /ai/mcp-catalog-and-toolkit/toolkit/
+  - title: MCP Gateway
+    description: Use the CLI and Gateway to run MCP servers with custom configurations
+    icon: cpu-chip
+    link: /ai/mcp-catalog-and-toolkit/mcp-gateway/
+  - title: Dynamic MCP
+    description: Discover and add MCP servers on-demand using natural language. This feature is experimental.
+    icon: magnifying-glass
+    link: /ai/mcp-catalog-and-toolkit/dynamic-mcp/
+  - title: Security FAQs
+    description: Common questions about MCP security, credentials, and server verification
+    icon: shield-check
+    link: /ai/mcp-catalog-and-toolkit/faqs/
+  - title: E2B sandboxes
+    description: Cloud sandboxes for AI agents with built-in MCP Catalog access
+    icon: cloud
+    link: /ai/mcp-catalog-and-toolkit/e2b-sandboxes/
+---
+
+{{< summary-bar feature_name="Docker MCP Catalog and Toolkit" >}}
+
+[Model Context Protocol](https://modelcontextprotocol.io/introduction) (MCP) is
+an open protocol that standardizes how AI applications access external tools
+and data sources. By connecting LLMs to local development tools, databases,
+APIs, and other resources, MCP extends their capabilities beyond their base
+training.
+
+The challenge is that running MCP servers locally creates operational friction.
+Each server requires separate installation and configuration for every
+application you use. You run untrusted code directly on your machine, manage
+updates manually, and troubleshoot dependency conflicts yourself. Configure a
+GitHub server for Claude, then configure it again for Cursor, and so on. Each
+time you manage credentials, permissions, and environment setup.
+
+## Docker MCP features
+
+The [MCP Toolkit](/ai/mcp-catalog-and-toolkit/toolkit/) and [MCP
+Gateway](/ai/mcp-catalog-and-toolkit/mcp-gateway/) solve these challenges
+through centralized management. Instead of configuring each server for every AI
+application separately, you set things up once and connect all your clients to
+it. The workflow centers on three concepts: catalogs, profiles, and clients.
+
+![MCP overview](./images/mcp_toolkit.avif)
+
+[Catalogs](/ai/mcp-catalog-and-toolkit/catalog/) are curated collections of
+MCP servers. The Docker MCP Catalog provides 300+ verified servers packaged as
+container images with versioning, provenance, and security updates. Organizations
+can create [custom
+catalogs](/ai/mcp-catalog-and-toolkit/catalog/#custom-catalogs) with approved
+servers for their teams.
+
+[Profiles](/ai/mcp-catalog-and-toolkit/profiles/) organize servers into named
+collections for different projects. Your "web-dev" profile might use GitHub and
+Playwright; your "backend" profile, database tools. Profiles support both
+containerized servers from catalogs and remote MCP servers. Configure a profile
+once, then share it across clients or with your team.
+
+Clients are the AI applications that connect to your profiles. Claude Code,
+Cursor, Zed, and others connect through the MCP Gateway, which routes requests
+to the right server and handles authentication and lifecycle management.
+
+> [!NOTE]
+> MCP Gateway as part of Docker AI Governance is an invite-only feature. [Contact Docker Sales](https://www.docker.com/pricing/contact-sales/) to learn more.
+
+## Learn more
+
+{{< grid >}}
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/catalog.md b/content/manuals/ai/mcp-catalog-and-toolkit/catalog.md
new file mode 100644
index 000000000000..284d4198b31b
--- /dev/null
+++ b/content/manuals/ai/mcp-catalog-and-toolkit/catalog.md
@@ -0,0 +1,139 @@
+---
+title: Docker MCP Catalog
+linkTitle: Catalog
+description: Browse Docker's curated collection of verified MCP servers, and create custom catalogs for your team or organization.
+keywords: docker hub, mcp, mcp servers, ai agents, catalog, custom catalog, docker
+weight: 20
+---
+
+{{< summary-bar feature_name="Docker MCP Catalog" >}}
+
+The [Docker MCP Catalog](https://hub.docker.com/mcp) is a curated collection of
+verified MCP servers, packaged as Docker images and distributed through Docker
+Hub. It solves common challenges with running MCP servers locally: environment
+conflicts, setup complexity, and security concerns.
+
+The catalog serves as the source of available MCP servers. When you add servers
+to your [profiles](/manuals/ai/mcp-catalog-and-toolkit/profiles.md), you select
+them from the catalog. Each server runs as an isolated container, making it
+portable and consistent across different environments.
+
+> [!NOTE]
+> E2B sandboxes now include direct access to the Docker MCP Catalog, giving
+> developers access to over 200 tools and services to seamlessly build and run
+> AI agents. For more information, see [E2B Sandboxes](e2b-sandboxes.md).
+
+## What's in the catalog
+
+The Docker MCP Catalog includes:
+
+- Verified servers: All servers are versioned with full provenance and SBOM
+  metadata
+- Partner tools: Servers from New Relic, Stripe, Grafana, and other trusted
+  partners
+- Docker-built servers: Locally-running servers built and digitally signed by
+  Docker for enhanced security
+- Remote services: Cloud-hosted servers that connect to external services like
+  GitHub, Notion, and Linear
+
+### Local versus remote servers
+
+The catalog contains two types of servers based on where they run:
+
+Local servers run as containers on your machine. They work offline once
+downloaded and offer predictable performance and complete data privacy. Docker
+builds and signs all local servers in the catalog.
+
+Remote servers run on the provider's infrastructure and connect to external
+services. Many remote servers use OAuth authentication, which the MCP Toolkit
+handles automatically through your browser.
+
+## Browse the catalog
+
+Browse available MCP servers at [hub.docker.com/mcp](https://hub.docker.com/mcp)
+or directly in Docker Desktop:
+
+1. In Docker Desktop, select **MCP Toolkit**.
+2. Select the **Catalog** tab to browse available servers.
+3. Select a server to view its description, tools, and configuration options.
+
+## Add servers to a profile
+
+To add a server from the catalog to a profile:
+
+1. In the **Catalog** tab, select the checkbox next to a server.
+2. Choose the profile to add it to from the drop-down.
+
+For step-by-step instructions and client connection, see
+[Get started with MCP Toolkit](get-started.md) or
+[MCP Profiles](profiles.md).
+
+## Custom catalogs
+
+Custom catalogs let you curate focused collections of servers for your team or
+organization. Instead of exposing all 300+ servers in the Docker catalog, you
+define exactly which servers are available.
+
+Common use cases:
+
+- Restrict which servers your organization approves for use
+- Add your organization's private MCP servers alongside public ones
+- Control which server versions your team uses
+- Define the server set available to AI agents using [Dynamic MCP](dynamic-mcp.md)
+
+### Custom catalogs with Dynamic MCP
+
+Custom catalogs work particularly well with
+[Dynamic MCP](/ai/mcp-catalog-and-toolkit/dynamic-mcp/), where agents discover
+and add MCP servers on-demand during conversations. When you run the gateway
+with a custom catalog, the `mcp-find` tool searches only within that catalog.
+If your catalog contains 20 servers instead of 300+, agents work within that
+focused set, discovering and enabling tools as needed without manual
+configuration each time.
+
+### Import a custom catalog
+
+If someone on your team has created and published a catalog, you can import it
+using its OCI registry reference.
+
+In Docker Desktop:
+
+1. Select **MCP Toolkit** and select the **Catalog** tab.
+2. Select **Import catalog**.
+3. Enter the OCI reference for the catalog (for example,
+   `registry.example.com/mcp/team-catalog:latest`).
+4. Select **Import**.
+
+Using the CLI:
+
+```console
+$ docker mcp catalog pull <oci-reference>
+```
+
+Once imported, the catalog appears alongside the Docker catalog and you can add
+its servers to your profiles.
+
+### Create and manage custom catalogs
+
+Creating and managing custom catalogs requires the CLI. See
+[Custom catalogs](/manuals/ai/mcp-catalog-and-toolkit/cli.md#custom-catalogs)
+in the CLI how-to for step-by-step instructions, including:
+
+- Curating a subset of the Docker catalog
+- Adding private servers to a catalog
+- Building a focused catalog from scratch
+- Pushing a catalog to a registry for your team to import
+
+## Contribute an MCP server to the catalog
+
+The MCP server registry is available at
+https://github.com/docker/mcp-registry. To submit an MCP server, follow the
+[contributing guidelines](https://github.com/docker/mcp-registry/blob/main/CONTRIBUTING.md).
+
+When your pull request is reviewed and approved, your MCP server is available
+within 24 hours on:
+
+- Docker Desktop's [MCP Toolkit feature](toolkit.md).
+- The [Docker MCP Catalog](https://hub.docker.com/mcp).
+- The [Docker Hub](https://hub.docker.com/u/mcp) `mcp` namespace (for MCP
+  servers built by Docker).
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/cli.md b/content/manuals/ai/mcp-catalog-and-toolkit/cli.md
new file mode 100644
index 000000000000..dd80b53564a6
--- /dev/null
+++ b/content/manuals/ai/mcp-catalog-and-toolkit/cli.md
@@ -0,0 +1,385 @@
+---
+title: Use MCP Toolkit from the CLI
+linkTitle: Use with CLI
+description: Manage MCP profiles, servers, and catalogs using Docker MCP CLI.
+keywords: docker mcp, cli, profiles, servers, catalog, gateway
+weight: 35
+---
+
+{{< summary-bar feature_name="Docker MCP Toolkit" >}}
+
+> [!NOTE]
+> The `docker mcp` commands documented here are available in Docker Desktop
+> 4.62 and later. Earlier versions may not support all commands shown.
+
+The `docker mcp` commands let you manage MCP profiles, servers, OAuth
+credentials, and catalogs from the terminal. Use the CLI for scripting,
+automation, and headless environments.
+
+## Profiles
+
+### Create a profile
+
+```console
+$ docker mcp profile create --name <profile-id>
+```
+
+The profile ID is used to reference the profile in subsequent commands:
+
+```console
+$ docker mcp profile create --name web-dev
+```
+
+### List profiles
+
+```console
+$ docker mcp profile list
+```
+
+### View a profile
+
+```console
+$ docker mcp profile show <profile-id>
+```
+
+### Remove a profile
+
+```console
+$ docker mcp profile remove <profile-id>
+```
+
+> [!CAUTION]
+> Removing a profile deletes all its server configurations and settings. This
+> action can't be undone.
+
+## Servers
+
+### Browse the catalog
+
+List available servers and their IDs:
+
+```console
+$ docker mcp catalog server ls mcp/docker-mcp-catalog
+```
+
+The output lists each server by name. The name (for example, `playwright` or
+`github-official`) is the server ID to use in `catalog://` URIs.
+
+To look up a server ID in Docker Desktop, open **MCP Toolkit** > **Catalog**,
+select a server, and check the **Server ID** field.
+
+### Add servers to a profile
+
+Servers are referenced by URI. The URI format depends on where the server
+comes from:
+
+| Format                                | Source                     |
+| ------------------------------------- | -------------------------- |
+| `catalog://<catalog-ref>/<server-id>` | An OCI catalog             |
+| `docker://<image>:<tag>`              | A Docker image             |
+| `https://<url>/v0/servers/<uuid>`     | The MCP community registry |
+| `file://<path>`                       | A local YAML or JSON file  |
+
+The most common format is `catalog://`, where `<catalog-ref>` matches the
+**Catalog** field and `<server-id>` matches the **Server ID** field shown in
+Docker Desktop or in the `catalog server ls` output:
+
+```console
+$ docker mcp profile server add <profile-id> \
+  --server catalog://<catalog-ref>/<server-id>
+```
+
+Add multiple servers in one command:
+
+```console
+$ docker mcp profile server add web-dev \
+  --server catalog://mcp/docker-mcp-catalog/github-official \
+  --server catalog://mcp/docker-mcp-catalog/playwright
+```
+
+To add a server defined in a local YAML file:
+
+```console
+$ docker mcp profile server add my-profile \
+  --server file://./my-server.yaml
+```
+
+The YAML file defines the server image and configuration:
+
+```yaml
+name: my-server
+title: My Server
+type: server
+image: myimage:latest
+description: Description of the server
+```
+
+If the server requires OAuth authentication, authorize it in Docker Desktop
+after adding. See [OAuth authentication](/manuals/ai/mcp-catalog-and-toolkit/toolkit.md#oauth-authentication).
+
+### List servers
+
+List all servers across all profiles:
+
+```console
+$ docker mcp profile server ls
+```
+
+Filter by profile:
+
+```console
+$ docker mcp profile server ls --filter profile=web-dev
+```
+
+### Remove a server
+
+```console
+$ docker mcp profile server remove <profile-id> --name <server-name>
+```
+
+Remove multiple servers at once:
+
+```console
+$ docker mcp profile server remove web-dev \
+  --name github-official \
+  --name playwright
+```
+
+### Configure server settings
+
+Set and retrieve configuration values for servers in a profile:
+
+```console
+$ docker mcp profile config <profile-id> --set <server-id>.<key>=<value>
+$ docker mcp profile config <profile-id> --get-all
+$ docker mcp profile config <profile-id> --del <server-id>.<key>
+```
+
+Server configuration keys and their expected values are defined by each server.
+Check the server's documentation or its entry in Docker Desktop under
+**MCP Toolkit** > **Catalog** > **Configuration**.
+
+## Gateway
+
+Run the MCP Gateway with a specific profile:
+
+```console
+$ docker mcp gateway run --profile <profile-id>
+```
+
+Omit `--profile` to use the default profile.
+
+### Connect a client manually
+
+To connect any client that isn't listed in Docker Desktop, configure it to run
+the gateway over `stdio`. For example, in a JSON-based client configuration:
+
+```json
+{
+  "servers": {
+    "MCP_DOCKER": {
+      "command": "docker",
+      "args": ["mcp", "gateway", "run", "--profile", "web-dev"],
+      "type": "stdio"
+    }
+  }
+}
+```
+
+For Claude Desktop, the format is:
+
+```json
+{
+  "mcpServers": {
+    "MCP_DOCKER": {
+      "command": "docker",
+      "args": ["mcp", "gateway", "run", "--profile", "web-dev"]
+    }
+  }
+}
+```
+
+### Connect a named client
+
+Connect a supported client to a profile:
+
+```console
+$ docker mcp client connect <client> --profile <profile-id>
+```
+
+For example, to connect VS Code to a project-specific profile:
+
+```console
+$ docker mcp client connect vscode --profile my-project
+```
+
+This creates a `.vscode/mcp.json` file in the current directory. Because this
+is a user-specific file, add it to `.gitignore`:
+
+```console
+$ echo ".vscode/mcp.json" >> .gitignore
+```
+
+## Share profiles
+
+Share profiles with your team using OCI registries or version control.
+
+### Share via OCI registry
+
+Profiles are shared as OCI artifacts via any OCI-compatible registry.
+Credentials are not included for security reasons. Team members configure
+authentication credentials separately after pulling.
+
+To push an existing profile called `web-dev` to an OCI registry:
+
+```console
+$ docker mcp profile push web-dev registry.example.com/profiles/web-dev:v1
+```
+
+To pull the same profile:
+
+```console
+$ docker mcp profile pull registry.example.com/profiles/team-standard:latest
+```
+
+### Share via version control
+
+For project-specific profiles, you can use the `export` and `import` commands
+and store the profiles in version control alongside your code. Team members can
+import the file to get the same configuration.
+
+To export a profile to your project directory:
+
+```console
+$ mkdir -p .docker
+$ docker mcp profile export web-dev .docker/mcp-profile.json
+```
+
+Team members who clone the repository can import the profile:
+
+```console
+$ docker mcp profile import .docker/mcp-profile.json
+```
+
+This creates a profile with the servers and configuration defined in the
+file. Any authentication credentials must be configured separately if needed.
+
+## Custom catalogs
+
+Custom catalogs let you curate a focused collection of servers for your team
+or organization. For an overview of what custom catalogs are and when to use
+them, see [Custom catalogs](/manuals/ai/mcp-catalog-and-toolkit/catalog.md#custom-catalogs).
+
+Catalogs are referenced by OCI reference, for example
+`registry.example.com/mcp/my-catalog:latest`. Servers within a catalog use
+the same URI schemes as when
+[adding servers to a profile](#add-servers-to-a-profile).
+
+### Customize the Docker catalog
+
+Use the Docker catalog as a base, then add or remove servers to fit your
+organization's needs. Copy it first:
+
+```console
+$ docker mcp catalog tag mcp/docker-mcp-catalog \
+  registry.example.com/mcp/company-tools:latest
+```
+
+List the servers it contains:
+
+```console
+$ docker mcp catalog server ls registry.example.com/mcp/company-tools:latest
+```
+
+Remove servers your organization doesn't approve:
+
+```console
+$ docker mcp catalog server remove \
+  registry.example.com/mcp/company-tools:latest \
+  --name <server-name>
+```
+
+Add your own private servers, packaged as Docker images:
+
+```console
+$ docker mcp catalog server add registry.example.com/mcp/company-tools:latest \
+  --server docker://registry.example.com/mcp/internal-api:latest \
+  --server docker://registry.example.com/mcp/data-pipeline:latest
+```
+
+Push when ready:
+
+```console
+$ docker mcp catalog push registry.example.com/mcp/company-tools:latest
+```
+
+### Build a catalog from scratch
+
+To include exactly what you choose and nothing else, create a catalog from
+scratch. You can include servers from the Docker catalog, your own private
+images, or both.
+
+Create a catalog and specify which servers to include:
+
+```console
+$ docker mcp catalog create registry.example.com/mcp/data-tools:latest \
+  --title "Data Analysis Tools" \
+  --server catalog://mcp/docker-mcp-catalog/sequentialthinking \
+  --server catalog://mcp/docker-mcp-catalog/brave \
+  --server docker://registry.example.com/mcp/analytics:latest
+```
+
+View the result:
+
+```console
+$ docker mcp catalog show registry.example.com/mcp/data-tools:latest
+```
+
+Push to distribute:
+
+```console
+$ docker mcp catalog push registry.example.com/mcp/data-tools:latest
+```
+
+### Distribute a catalog
+
+Push your catalog so team members can import it:
+
+```console
+$ docker mcp catalog push <oci-reference>
+```
+
+Team members can pull it using the CLI:
+
+```console
+$ docker mcp catalog pull <oci-reference>
+```
+
+Or import it using Docker Desktop: select **MCP Toolkit** > **Catalog** >
+**Import catalog** and enter the OCI reference.
+
+### Use a custom catalog with the gateway
+
+Run the gateway with your catalog instead of the default Docker catalog:
+
+```console
+$ docker mcp gateway run --catalog <oci-reference>
+```
+
+For [Dynamic MCP](/manuals/ai/mcp-catalog-and-toolkit/dynamic-mcp.md), where
+agents discover and add servers during conversations, this limits what agents
+can find to your curated set.
+
+To enable specific servers from your catalog without using a profile:
+
+```console
+$ docker mcp gateway run --catalog <oci-reference> \
+  --servers <name1> --servers <name2>
+```
+
+## Further reading
+
+- [Get started with MCP Toolkit](/manuals/ai/mcp-catalog-and-toolkit/get-started.md)
+- [MCP Profiles](/manuals/ai/mcp-catalog-and-toolkit/profiles.md)
+- [MCP Catalog](/manuals/ai/mcp-catalog-and-toolkit/catalog.md)
+- [MCP Gateway](/manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md)
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/dynamic-mcp.md b/content/manuals/ai/mcp-catalog-and-toolkit/dynamic-mcp.md
new file mode 100644
index 000000000000..4194002b1bc5
--- /dev/null
+++ b/content/manuals/ai/mcp-catalog-and-toolkit/dynamic-mcp.md
@@ -0,0 +1,152 @@
+---
+title: Dynamic MCP
+linkTitle: Dynamic discovery
+description: Discover and add MCP servers on-demand using natural language with Dynamic MCP servers
+keywords: dynamic mcps, mcp discovery, mcp-find, mcp-add, code-mode, ai agents, model context protocol
+weight: 40
+---
+
+Dynamic MCP enables AI agents to discover and add MCP servers on-demand during
+a conversation, without manual configuration. Instead of pre-configuring every
+MCP server before starting your agent session, clients can search the
+[MCP Catalog](/manuals/ai/mcp-catalog-and-toolkit/catalog.md) and add servers
+as needed.
+
+This capability is enabled automatically when you connect an MCP client to the
+[MCP Toolkit](/manuals/ai/mcp-catalog-and-toolkit/toolkit.md). The gateway
+provides a set of primordial tools that agents use to discover and manage
+servers during runtime.
+
+{{% experimental %}}
+
+Dynamic MCP is an experimental feature in early development. While you're
+welcome to try it out and explore its capabilities, you may encounter
+unexpected behavior or limitations. Feedback is welcome via at [GitHub
+issues](https://github.com/docker/mcp-gateway/issues) for bug reports and
+[GitHub discussions](https://github.com/docker/mcp-gateway/discussions) for
+general questions and feature requests.
+
+{{% /experimental %}}
+
+## How it works
+
+When you connect a client to the MCP Gateway, the gateway exposes a small set
+of management tools alongside any MCP servers in your active profile. These
+management tools let agents interact with the gateway's configuration:
+
+| Tool             | Description                                                              |
+| ---------------- | ------------------------------------------------------------------------ |
+| `mcp-find`       | Search for MCP servers in the catalog by name or description             |
+| `mcp-add`        | Add a new MCP server to the current session                              |
+| `mcp-config-set` | Configure settings for an MCP server                                     |
+| `mcp-remove`     | Remove an MCP server from the session                                    |
+| `mcp-exec`       | Execute a tool by name that exists in the current session                |
+| `code-mode`      | Create a JavaScript-enabled tool that combines multiple MCP server tools |
+
+With these tools available, an agent can search the catalog, add servers,
+handle authentication, and use newly added tools directly without requiring a
+restart or manual configuration.
+
+Dynamically added servers and tools are associated with your _current session
+only_. They're not persisted to your profile. When you start a new session,
+only servers you've added to your profile through the
+[MCP Toolkit](/manuals/ai/mcp-catalog-and-toolkit/toolkit.md) or
+[Profiles](/manuals/ai/mcp-catalog-and-toolkit/profiles.md) are available.
+
+## Prerequisites
+
+To use Dynamic MCP, you need:
+
+- Docker Desktop version 4.50 or later, with [MCP Toolkit](/manuals/ai/mcp-catalog-and-toolkit/toolkit.md) enabled
+- An LLM application that supports MCP (such as Claude Desktop, Visual Studio Code, or Claude Code)
+- Your client configured to connect to the MCP Gateway
+
+See [Get started with Docker MCP Toolkit](/manuals/ai/mcp-catalog-and-toolkit/get-started.md)
+for setup instructions.
+
+## Usage
+
+Dynamic MCP is enabled automatically when you use the MCP Toolkit. Your
+connected clients can now use `mcp-find`, `mcp-add`, and other management tools
+during conversations.
+
+To see Dynamic MCP in action, connect your AI client to the Docker MCP Toolkit
+and try this prompt:
+
+```plaintext
+What MCP servers can I use for working with SQL databases?
+```
+
+Given this prompt, your agent will use the `mcp-find` tool provided by MCP
+Toolkit to search for SQL-related servers in the [MCP Catalog](./catalog.md).
+
+And to add a server to a session, simply write a prompt and the MCP Toolkit
+takes care of installing and running the server:
+
+```plaintext
+Add the postgres mcp server
+```
+
+## Tool composition with code mode
+
+The `code-mode` tool is available as an experimental capability for creating
+custom JavaScript functions that combine multiple MCP server tools. The
+intended use case is to enable workflows that coordinate multiple services
+in a single operation.
+
+> **Note**
+>
+> Code mode is in early development and is not yet reliable for general use.
+> The documentation intentionally omits usage examples at this time.
+>
+> The core Dynamic MCP capabilities (`mcp-find`, `mcp-add`, `mcp-config-set`,
+> `mcp-remove`) work as documented and are the recommended focus for current
+> use.
+
+The architecture works as follows:
+
+1. The agent calls `code-mode` with a list of server names and a tool name
+2. The gateway creates a sandbox with access to those servers' tools
+3. A new tool is registered in the current session with the specified name
+4. The agent calls the newly created tool
+5. The code executes in the sandbox with access to the specified tools
+6. Results are returned to the agent
+
+The sandbox can only interact with the outside world through MCP tools,
+which are already running in isolated containers with restricted privileges.
+
+## Security considerations
+
+Dynamic MCP maintains the same security model as static MCP server
+configuration in MCP Toolkit:
+
+- All servers in the MCP Catalog are built, signed, and maintained by Docker
+- Servers run in isolated containers with restricted resources
+- Code mode runs agent-written JavaScript in an isolated sandbox that can only
+  interact through MCP tools
+- Credentials are managed by the gateway and injected securely into containers
+
+The key difference with dynamic capabilities is that agents can add new tools
+during runtime.
+
+## Disabling Dynamic MCP
+
+Dynamic MCP is enabled by default in the MCP Toolkit. If you prefer to use only
+statically configured MCP servers, you can disable the dynamic tools feature:
+
+```console
+$ docker mcp feature disable dynamic-tools
+```
+
+To re-enable the feature later:
+
+```console
+$ docker mcp feature enable dynamic-tools
+```
+
+After changing this setting, you may need to restart any connected MCP clients.
+
+## Further reading
+
+Check out the [Dynamic MCP servers with Docker](https://docker.com/blog) blog
+post for more examples and inspiration on how you can use dynamic tools.
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/e2b-sandboxes.md b/content/manuals/ai/mcp-catalog-and-toolkit/e2b-sandboxes.md
new file mode 100644
index 000000000000..d5501b8c4204
--- /dev/null
+++ b/content/manuals/ai/mcp-catalog-and-toolkit/e2b-sandboxes.md
@@ -0,0 +1,452 @@
+---
+title: E2B sandboxes
+description: Cloud-based secure sandboxes for AI agents with built-in Docker MCP Gateway integration
+keywords: E2B, cloud sandboxes, MCP Gateway, AI agents, MCP Catalog
+aliases:
+  - /ai/mcp-catalog-and-toolkit/sandboxes/
+---
+
+[E2B](https://e2b.dev/) provides secure cloud sandboxes for AI agents with direct access to Docker's [MCP Catalog](https://hub.docker.com/mcp), a collection of 200+ tools from publishers including GitHub, Notion, and Stripe.
+
+When you create an E2B sandbox, you specify which MCP tools it should access. E2B launches these tools and provides access through the Docker MCP Gateway.
+
+## Example: Using GitHub and Notion MCP server
+
+This example demonstrates how to connect multiple MCP servers in an E2B sandbox. You'll analyze data in Notion and create GitHub issues using Claude.
+
+### Prerequisites
+
+Before you begin, make sure you have the following:
+
+- [E2B account](https://e2b.dev/docs/quickstart) with API access
+- Anthropic API key for Claude
+
+  > [!NOTE]
+  > This example uses Claude Code, which is pre-installed in E2B sandboxes.
+  > However, you can adapt the example to work with other AI assistants of your
+  > choice. See [E2B's MCP documentation](https://e2b.dev/docs/mcp/quickstart)
+  > for alternative connection methods.
+
+- Node.js 18+ installed on your machine
+- Notion account with:
+  - A database containing sample data
+  - [Integration token](https://www.notion.com/help/add-and-manage-connections-with-the-api)
+- GitHub account with:
+  - A repository for testing
+  - Personal access token with `repo` scope
+
+### Set up your environment
+
+Create a new directory and initialize a Node.js project:
+
+```console
+$ mkdir mcp-e2b-quickstart
+$ cd mcp-e2b-quickstart
+$ npm init -y
+```
+
+Configure your project for ES modules by updating `package.json`:
+
+```json
+{
+  "name": "mcp-e2b-quickstart",
+  "version": "1.0.0",
+  "type": "module",
+  "scripts": {
+    "start": "node index.js"
+  }
+}
+```
+
+Install required dependencies:
+
+```console
+$ npm install e2b dotenv
+```
+
+Create a `.env` file with your credentials:
+
+```console
+$ cat > .env << 'EOF'
+E2B_API_KEY=your_e2b_api_key_here
+ANTHROPIC_API_KEY=your_anthropic_api_key_here
+NOTION_INTEGRATION_TOKEN=ntn_your_notion_integration_token_here
+GITHUB_TOKEN=ghp_your_github_pat_here
+EOF
+```
+
+Protect your credentials:
+
+```console
+$ echo ".env" >> .gitignore
+$ echo "node_modules/" >> .gitignore
+```
+
+### Create an E2B sandbox with MCP servers
+
+{{< tabs group="" >}}
+{{< tab name="Typescript">}}
+
+Create a file named `index.ts`:
+
+```typescript
+import "dotenv/config";
+import { Sandbox } from "e2b";
+
+async function quickstart(): Promise<void> {
+  console.log("Creating E2B sandbox with Notion and GitHub MCP servers...\n");
+
+  const sbx: Sandbox = await Sandbox.create({
+    envs: {
+      ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY as string,
+    },
+    mcp: {
+      notion: {
+        internalIntegrationToken: process.env
+          .NOTION_INTEGRATION_TOKEN as string,
+      },
+      githubOfficial: {
+        githubPersonalAccessToken: process.env.GITHUB_TOKEN as string,
+      },
+    },
+  });
+
+  const mcpUrl = sbx.getMcpUrl();
+  const mcpToken = await sbx.getMcpToken();
+
+  console.log("Sandbox created successfully!");
+  console.log(`MCP Gateway URL: ${mcpUrl}\n`);
+
+  // Wait for MCP initialization
+  await new Promise<void>((resolve) => setTimeout(resolve, 1000));
+
+  // Connect Claude to MCP gateway
+  console.log("Connecting Claude to MCP gateway...");
+  await sbx.commands.run(
+    `claude mcp add --transport http e2b-mcp-gateway ${mcpUrl} --header "Authorization: Bearer ${mcpToken}"`,
+    {
+      timeoutMs: 0,
+      onStdout: console.log,
+      onStderr: console.log,
+    },
+  );
+
+  console.log("\nConnection successful! Cleaning up...");
+  await sbx.kill();
+}
+
+quickstart().catch(console.error);
+```
+
+Run the script:
+
+```console
+$ npx tsx index.ts
+```
+
+{{< /tab >}}
+{{< tab name="Python">}}
+
+Create a file named `index.py`:
+
+```python
+import os
+import asyncio
+from dotenv import load_dotenv
+from e2b import Sandbox
+
+load_dotenv()
+
+async def quickstart():
+    print("Creating E2B sandbox with Notion and GitHub MCP servers...\n")
+
+    sbx = await Sandbox.beta_create(
+        envs={
+            "ANTHROPIC_API_KEY": os.getenv("ANTHROPIC_API_KEY"),
+        },
+        mcp={
+            "notion": {
+                "internalIntegrationToken": os.getenv("NOTION_INTEGRATION_TOKEN"),
+            },
+            "githubOfficial": {
+                "githubPersonalAccessToken": os.getenv("GITHUB_TOKEN"),
+            },
+        },
+    )
+
+    mcp_url = sbx.beta_get_mcp_url()
+    mcp_token = await sbx.beta_get_mcp_token()
+
+    print("Sandbox created successfully!")
+    print(f"MCP Gateway URL: {mcp_url}\n")
+
+    # Wait for MCP initialization
+    await asyncio.sleep(1)
+
+    # Connect Claude to MCP gateway
+    print("Connecting Claude to MCP gateway...")
+
+    def on_stdout(output):
+        print(output, end='')
+
+    def on_stderr(output):
+        print(output, end='')
+
+    await sbx.commands.run(
+        f'claude mcp add --transport http e2b-mcp-gateway {mcp_url} --header "Authorization: Bearer {mcp_token}"',
+        timeout_ms=0,
+        on_stdout=on_stdout,
+        on_stderr=on_stderr
+    )
+
+    print("\nConnection successful! Cleaning up...")
+    await sbx.kill()
+
+if __name__ == "__main__":
+    try:
+        asyncio.run(quickstart())
+    except Exception as e:
+        print(f"Error: {e}")
+
+```
+
+Run the script:
+
+```console
+$ python index.py
+```
+
+{{< /tab >}}
+{{</tabs >}}
+
+You should see:
+
+```console
+Creating E2B sandbox with Notion and GitHub MCP servers...
+
+Sandbox created successfully!
+MCP Gateway URL: https://50005-xxxxx.e2b.app/mcp
+
+Connecting Claude to MCP gateway...
+Added HTTP MCP server e2b-mcp-gateway with URL: https://50005-xxxxx.e2b.app/mcp
+
+Connection successful! Cleaning up...
+```
+
+### Test with example workflow
+
+Now, test the setup by running a simple workflow that searches Notion and creates a GitHub issue.
+
+{{< tabs group="" >}}
+{{< tab name="Typescript">}}
+
+> [!IMPORTANT]
+>
+> Replace `owner/repo` in the prompt with your actual GitHub username and repository
+> name (for example, `yourname/test-repo`).
+
+Update `index.ts` with the following example:
+
+```typescript
+import "dotenv/config";
+import { Sandbox } from "e2b";
+
+async function exampleWorkflow(): Promise<void> {
+  console.log("Creating sandbox...\n");
+
+  const sbx: Sandbox = await Sandbox.create({
+    envs: {
+      ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY as string,
+    },
+    mcp: {
+      notion: {
+        internalIntegrationToken: process.env
+          .NOTION_INTEGRATION_TOKEN as string,
+      },
+      githubOfficial: {
+        githubPersonalAccessToken: process.env.GITHUB_TOKEN as string,
+      },
+    },
+  });
+
+  const mcpUrl = sbx.getMcpUrl();
+  const mcpToken = await sbx.getMcpToken();
+
+  console.log("Sandbox created successfully\n");
+
+  // Wait for MCP servers to initialize
+  await new Promise<void>((resolve) => setTimeout(resolve, 3000));
+
+  console.log("Connecting Claude to MCP gateway...\n");
+  await sbx.commands.run(
+    `claude mcp add --transport http e2b-mcp-gateway ${mcpUrl} --header "Authorization: Bearer ${mcpToken}"`,
+    {
+      timeoutMs: 0,
+      onStdout: console.log,
+      onStderr: console.log,
+    },
+  );
+
+  console.log("\nRunning example: Search Notion and create GitHub issue...\n");
+
+  const prompt: string = `Using Notion and GitHub MCP tools:
+1. Search my Notion workspace for databases
+2. Create a test issue in owner/repo titled "MCP Toolkit Test" with description "Testing E2B + Docker MCP integration"
+3. Confirm both operations completed successfully`;
+
+  await sbx.commands.run(
+    `echo '${prompt.replace(/'/g, "'\\''")}' | claude -p --dangerously-skip-permissions`,
+    {
+      timeoutMs: 0,
+      onStdout: console.log,
+      onStderr: console.log,
+    },
+  );
+
+  await sbx.kill();
+}
+
+exampleWorkflow().catch(console.error);
+```
+
+Run the script:
+
+```console
+$ npx tsx index.ts
+```
+
+{{< /tab >}}
+{{< tab name="Python">}}
+
+Update `index.py` with this example:
+
+> [!IMPORTANT]
+>
+> Replace `owner/repo` in the prompt with your actual GitHub username and repository
+> name (for example, `yourname/test-repo`).
+
+```python
+import os
+import asyncio
+import shlex
+from dotenv import load_dotenv
+from e2b import Sandbox
+
+load_dotenv()
+
+async def example_workflow():
+    print("Creating sandbox...\n")
+
+    sbx = await Sandbox.beta_create(
+        envs={
+            "ANTHROPIC_API_KEY": os.getenv("ANTHROPIC_API_KEY"),
+        },
+        mcp={
+            "notion": {
+                "internalIntegrationToken": os.getenv("NOTION_INTEGRATION_TOKEN"),
+            },
+            "githubOfficial": {
+                "githubPersonalAccessToken": os.getenv("GITHUB_TOKEN"),
+            },
+        },
+    )
+
+    mcp_url = sbx.beta_get_mcp_url()
+    mcp_token = await sbx.beta_get_mcp_token()
+
+    print("Sandbox created successfully\n")
+
+    # Wait for MCP servers to initialize
+    await asyncio.sleep(3)
+
+    print("Connecting Claude to MCP gateway...\n")
+
+    def on_stdout(output):
+        print(output, end='')
+
+    def on_stderr(output):
+        print(output, end='')
+
+    await sbx.commands.run(
+        f'claude mcp add --transport http e2b-mcp-gateway {mcp_url} --header "Authorization: Bearer {mcp_token}"',
+        timeout_ms=0,
+        on_stdout=on_stdout,
+        on_stderr=on_stderr
+    )
+
+    print("\nRunning example: Search Notion and create GitHub issue...\n")
+
+    prompt = """Using Notion and GitHub MCP tools:
+1. Search my Notion workspace for databases
+2. Create a test issue in owner/repo titled "MCP Toolkit Test" with description "Testing E2B + Docker MCP integration"
+3. Confirm both operations completed successfully"""
+
+    # Escape single quotes for shell
+    escaped_prompt = prompt.replace("'", "'\\''")
+
+    await sbx.commands.run(
+        f"echo '{escaped_prompt}' | claude -p --dangerously-skip-permissions",
+        timeout_ms=0,
+        on_stdout=on_stdout,
+        on_stderr=on_stderr
+    )
+
+    await sbx.kill()
+
+if __name__ == "__main__":
+    try:
+        asyncio.run(example_workflow())
+    except Exception as e:
+        print(f"Error: {e}")
+```
+
+Run the script:
+
+```console
+$ python workflow.py
+```
+
+{{< /tab >}}
+{{</tabs >}}
+
+You should see:
+
+```console
+Creating sandbox...
+
+Running example: Search Notion and create GitHub issue...
+
+## Task Completed Successfully
+
+I've completed both operations using the Notion and GitHub MCP tools:
+
+### 1. Notion Workspace Search
+
+Found 3 databases in your Notion workspace:
+- **Customer Feedback** - Database with 12 entries tracking feature requests
+- **Product Roadmap** - Planning database with 8 active projects
+- **Meeting Notes** - Shared workspace with 45 pages
+
+### 2. GitHub Issue Creation
+
+Successfully created test issue:
+- **Repository**: your-org/your-repo
+- **Issue Number**: #47
+- **Title**: "MCP Test"
+- **Description**: "Testing E2B + Docker MCP integration"
+- **Status**: Open
+- **URL**: https://github.com/your-org/your-repo/issues/47
+
+Both operations completed successfully. The MCP servers are properly configured and working.
+```
+
+The sandbox connected multiple MCP servers and orchestrated a workflow across Notion and GitHub. You can extend this pattern to combine any of the 200+ MCP servers in the Docker MCP Catalog.
+
+## Related pages
+
+- [How to build an AI-powered code quality workflow with SonarQube and E2B](/guides/github-sonarqube-sandbox.md)
+- [Docker + E2B: Building the Future of Trusted AI](https://www.docker.com/blog/docker-e2b-building-the-future-of-trusted-ai/)
+- [Docker Sandboxes](/manuals/ai/sandboxes/_index.md)
+- [Docker MCP Toolkit and Catalog](/manuals/ai/mcp-catalog-and-toolkit/_index.md)
+- [Docker MCP Gateway](/manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md)
+- [E2B MCP documentation](https://e2b.dev/docs/mcp)
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/faqs.md b/content/manuals/ai/mcp-catalog-and-toolkit/faqs.md
new file mode 100644
index 000000000000..6d803b1c97dd
--- /dev/null
+++ b/content/manuals/ai/mcp-catalog-and-toolkit/faqs.md
@@ -0,0 +1,114 @@
+---
+title: MCP Toolkit FAQs
+linkTitle: FAQs
+description: Frequently asked questions related to MCP Catalog and Toolkit security
+keywords: MCP, Toolkit, MCP server, MCP client, security, faq
+tags: [FAQ]
+weight: 70
+---
+
+Docker MCP Catalog and Toolkit is a solution for securely building, sharing, and
+running MCP tools. This page answers common questions about MCP Catalog and Toolkit security.
+
+### What process does Docker follow to add a new MCP server to the catalog?
+
+Developers can submit a pull request to the [Docker MCP Registry](https://github.com/docker/mcp-registry) to propose new servers. Docker provides detailed [contribution guidelines](https://github.com/docker/mcp-registry/blob/main/CONTRIBUTING.md) to help developers meet the required standards.
+
+Currently, a majority of the servers in the catalog are built directly by Docker. Each server includes attestations such as:
+
+- Build attestation: Servers are built on Docker Build Cloud.
+- Source provenance: Verifiable source code origins.
+- Signed SBOMs: Software Bill of Materials with cryptographic signatures.
+
+> [!NOTE]
+> When using the images with [Docker MCP gateway](/manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md),
+> you can verify attestations at runtime using the `docker mcp gateway run
+--verify-signatures` CLI command.
+
+
+In addition to Docker-built servers, the catalog includes select servers from trusted registries such as GitHub and HashiCorp. Each third-party server undergoes a verification process that includes:
+
+- Pulling and building the code in an ephemeral build environment.
+- Testing initialization and functionality.
+- Verifying that tools can be successfully listed.
+
+### Under what conditions does Docker reject MCP server submissions?
+
+Docker rejects MCP server submissions that fail automated testing and validation processes during pull request review. Additionally, Docker reviewers evaluate submissions against specific requirements and reject MCP servers that don't meet these criteria.
+
+### Does Docker take accountability for malicious MCP servers in the Toolkit?
+
+Docker’s security measures currently represent a best-effort approach. While Docker implements automated testing, scanning, and metadata extraction for each server in the catalog, these security measures are not yet exhaustive. Docker is actively working to enhance its security processes and expand testing coverage. Enterprise customers can contact their Docker account manager for specific security requirements and implementation details.
+
+### How are credentials managed for MCP servers?
+
+Starting with Docker Desktop version 4.43.0, credentials are stored securely in the Docker Desktop VM. The storage implementation depends on the platform (for example, macOS, WSL2). You can manage the credentials using the following CLI commands:
+
+- `docker mcp secret ls` - List stored credentials
+- `docker mcp secret rm` - Remove specific credentials
+- `docker mcp oauth revoke` - Revoke OAuth-based credentials
+
+In the upcoming versions of Docker Desktop, Docker plans to support pluggable storage for these secrets and additional out-of-the-box storage providers to give users more flexibility in managing credentials.
+
+### Are credentials removed when an MCP server is uninstalled?
+
+No. MCP servers are not technically uninstalled since they exist as Docker containers pulled to your local Docker Desktop. Removing an MCP server stops the container but leaves the image on your system. Even if the container is deleted, credentials remain stored until you remove them manually.
+
+### Why don't I see remote MCP servers in the catalog?
+
+If remote MCP servers aren't visible in the Docker Desktop catalog, your local
+catalog may be out of date. Remote servers are indicated by a cloud icon and
+include services like GitHub, Notion, and Linear.
+
+Update your catalog by running:
+
+```console
+$ docker mcp catalog update
+```
+
+After the update completes, refresh the **Catalog** tab in Docker Desktop.
+
+### What's the difference between profiles and the catalog?
+
+The [catalog](/manuals/ai/mcp-catalog-and-toolkit/catalog.md) is the source of
+available MCP servers - a library of tools you can choose from.
+[Profiles](/manuals/ai/mcp-catalog-and-toolkit/profiles.md) are collections of
+servers you've added to organize your work. Think of the catalog as a library,
+and profiles as your personal bookshelves containing the books you've selected
+for different purposes.
+
+### Can I share profiles with my team?
+
+Yes. Profiles can be pushed to OCI-compliant registries using
+`docker mcp profile push my-profile registry.example.com/profiles/my-profile:v1`.
+Team members can pull your profile with
+`docker mcp profile pull registry.example.com/profiles/my-profile:v1`. Note
+that credentials aren't included in shared profiles for security reasons - team
+members need to configure OAuth and other credentials separately.
+
+### Do I need to create a profile to use MCP Toolkit?
+
+Yes, MCP Toolkit requires a profile to run servers. If you're upgrading from a
+version before profiles were introduced, a default profile is automatically
+created for you with your existing server configurations. You can create
+additional named profiles to organize servers for different projects or
+environments.
+
+### What happens to servers when I switch profiles?
+
+Each profile contains its own set of servers and configurations. When you run
+the gateway with `--profile profile-name`, only servers in that profile are
+available to clients. The default profile is used when no profile is specified.
+Switching between profiles changes which servers your AI applications can
+access.
+
+### Can I use the same server in multiple profiles?
+
+Yes. You can add the same MCP server to multiple profiles, each with different
+configurations if needed. This is useful when you need the same server with
+different settings for different projects or environments.
+
+## Related pages
+
+- [Get started with MCP Toolkit](/manuals/ai/mcp-catalog-and-toolkit/get-started.md)
+- [Open-source MCP Gateway](/manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md)
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/get-started.md b/content/manuals/ai/mcp-catalog-and-toolkit/get-started.md
new file mode 100644
index 000000000000..69c4af74f8be
--- /dev/null
+++ b/content/manuals/ai/mcp-catalog-and-toolkit/get-started.md
@@ -0,0 +1,461 @@
+---
+title: Get started with Docker MCP Toolkit
+linkTitle: Get started
+description: Learn how to quickly install and use the MCP Toolkit to set up servers and clients.
+keywords: Docker MCP Toolkit, MCP server, MCP client, AI agents
+weight: 5
+params:
+  test_prompt: Use the GitHub MCP server to show me my open pull requests
+---
+
+{{< summary-bar feature_name="Docker MCP Toolkit" >}}
+
+> [!NOTE]
+> This page describes the MCP Toolkit interface in Docker Desktop 4.62 and
+> later. Earlier versions have a different UI. Upgrade to follow these
+> instructions exactly.
+
+The Docker MCP Toolkit makes it easy to set up, manage, and run containerized
+Model Context Protocol (MCP) servers in profiles, and connect them to AI
+agents. It provides secure defaults and support for a growing ecosystem of
+LLM-based clients. This page shows you how to get started quickly with the
+Docker MCP Toolkit.
+
+## Setup
+
+Before you begin, make sure you meet the following requirements to get started with Docker MCP Toolkit.
+
+1. Download and install the latest version of [Docker Desktop](/get-started/get-docker/).
+2. Open the Docker Desktop settings and select **Beta features**.
+3. Select **Enable Docker MCP Toolkit**.
+4. Select **Apply**.
+
+The **Learning center** in Docker Desktop provides walkthroughs and resources
+to help you get started with Docker products and features. On the **MCP
+Toolkit** page, the **Get started** walkthrough guides you through installing
+an MCP server, connecting a client, and testing your setup.
+
+Alternatively, follow the step-by-step instructions on this page:
+
+- [Create a profile](#create-a-profile) - Your workspace for organizing servers
+- [Add MCP servers to your profile](#add-mcp-servers) - Select tools from the catalog
+- [Connect clients](#connect-clients) - Link AI applications to your profile
+- [Verify connections](#verify-connections) - Test that everything works
+
+Once configured, your AI applications can use all the servers in your profile.
+
+> [!TIP]
+> Prefer working from the terminal? See [Use MCP Toolkit from the CLI](cli.md)
+> for instructions on using the `docker mcp` commands.
+
+## Create a profile
+
+Profiles organize your MCP servers into collections. Create a profile for your
+work:
+
+> [!NOTE]
+> If you're upgrading from a previous version of MCP Toolkit, your existing
+> server configurations are already in a `default` profile. You can continue
+> using the default profile or create new profiles for different projects.
+
+1. In Docker Desktop, select **MCP Toolkit** and select the **Profiles** tab.
+2. Select **Create profile**.
+3. Enter a name for your profile (e.g., "Frontend development").
+4. Optionally, add servers and clients now, or add them later.
+5. Select **Create**.
+
+Your new profile appears in the profiles list.
+
+## Add MCP servers
+
+1. In Docker Desktop, select **MCP Toolkit** and select the **Catalog** tab.
+2. Browse the catalog and select the servers you want to add.
+3. Select the **Add to** button and choose whether you want to add the servers
+   to an existing profile, or create a new profile.
+
+If a server requires configuration, a **Configuration Required** badge appears
+next to the server's name. You must complete the mandatory configuration before
+you can use the server.
+
+You've now successfully added MCP servers to your profile. Next, connect an MCP
+client to use the servers in your profile.
+
+## Connect clients
+
+To connect a client to MCP Toolkit:
+
+1. In Docker Desktop, select **MCP Toolkit** and select the **Clients** tab.
+2. Find your application in the list.
+3. Select **Connect** to configure the client.
+
+If your client isn't listed, you can connect the MCP Toolkit manually over
+`stdio` by configuring your client to run the gateway with your profile:
+
+```plaintext
+docker mcp gateway run --profile my_profile
+```
+
+For example, if your client uses a JSON file to configure MCP servers, you may
+add an entry like:
+
+```json {title="Example configuration"
+{
+  "servers": {
+    "MCP_DOCKER": {
+      "command": "docker",
+      "args": ["mcp", "gateway", "run", "--profile", "my_profile"],
+      "type": "stdio"
+    }
+  }
+}
+```
+
+Consult the documentation of the application you're using for instructions on
+how to set up MCP servers manually.
+
+## Verify connections
+
+Refer to the relevant section for instructions on how to verify that your setup
+is working:
+
+- [Claude Code](#claude-code)
+- [Claude Desktop](#claude-desktop)
+- [OpenAI Codex](#codex)
+- [Continue](#continue)
+- [Cursor](#cursor)
+- [Gemini](#gemini)
+- [Goose](#goose)
+- [LM Studio](#lm-studio)
+- [OpenCode](#opencode)
+- [Sema4.ai](#sema4)
+- [Visual Studio Code](#vscode)
+- [Zed](#zed)
+- [Mistral Vibe](#mistral-vibe)
+
+### Claude Code
+
+If you configured the MCP Toolkit for a specific project, navigate to the
+relevant project directory. Then run `claude mcp list`. The output should show
+`MCP_DOCKER` with a "connected" status:
+
+```console
+$ claude mcp list
+Checking MCP server health...
+
+MCP_DOCKER: docker mcp gateway run - ✓ Connected
+```
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```console
+$ claude "{{% param test_prompt %}}"
+```
+
+### Claude Desktop
+
+Restart Claude Desktop and check the **Search and tools** menu in the chat
+input. You should see the `MCP_DOCKER` server listed and enabled:
+
+![Claude Desktop](images/claude-desktop.avif)
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```plaintext
+{{% param test_prompt %}}
+```
+
+### Codex
+
+Run `codex mcp list` to view active MCP servers and their statuses. The
+`MCP_DOCKER` server should appear in the list with an "enabled" status:
+
+```console
+$ codex mcp list
+Name        Command  Args             Env  Cwd  Status   Auth
+MCP_DOCKER  docker   mcp gateway run  -    -    enabled  Unsupported
+```
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```console
+$ codex "{{% param test_prompt %}}"
+```
+
+### Continue
+
+Launch the Continue terminal UI by running `cn`. Use the `/mcp` command to view
+active MCP servers and their statuses. The `MCP_DOCKER` server should appear in
+the list with a "connected" status:
+
+```plaintext
+   MCP Servers
+
+   ➤ 🟢 MCP_DOCKER (🔧75 📝3)
+     🔄 Restart all servers
+     ⏹️ Stop all servers
+     🔍 Explore MCP Servers
+     Back
+
+   ↑/↓ to navigate, Enter to select, Esc to go back
+```
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```console
+$ cn "{{% param test_prompt %}}"
+```
+
+### Cursor
+
+Open Cursor. If you configured the MCP Toolkit for a specific project, open the
+relevant project directory. Then navigate to **Cursor Settings > Tools & MCP**.
+You should see `MCP_DOCKER` under **Installed MCP Servers**:
+
+![Cursor](images/cursor.avif)
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```plaintext
+{{% param test_prompt %}}
+```
+
+### Gemini
+
+Run `gemini mcp list` to view active MCP servers and their statuses. The
+`MCP_DOCKER` should appear in the list with a "connected" status.
+
+```console
+$ gemini mcp list
+Configured MCP servers:
+
+✓ MCP_DOCKER: docker mcp gateway run (stdio) - Connected
+```
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```console
+$ gemini "{{% param test_prompt %}}"
+```
+
+### Goose
+
+{{< tabs >}}
+{{< tab name="Desktop app" >}}
+
+Open the Goose desktop application and select **Extensions** in the sidebar.
+Under **Enabled Extensions**, you should see an extension named `Mcpdocker`:
+
+![Goose desktop app](images/goose.avif)
+
+{{< /tab >}}
+{{< tab name="CLI" >}}
+
+Run `goose info -v` and look for an entry named `mcpdocker` under extensions.
+The status should show `enabled: true`:
+
+```console
+$ goose info -v
+…
+    mcpdocker:
+      args:
+      - mcp
+      - gateway
+      - run
+      available_tools: []
+      bundled: null
+      cmd: docker
+      description: The Docker MCP Toolkit allows for easy configuration and consumption of MCP servers from the Docker MCP Catalog
+      enabled: true
+      env_keys: []
+      envs: {}
+      name: mcpdocker
+      timeout: 300
+      type: stdio
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```plaintext
+{{% param "test_prompt" %}}
+```
+
+### LM Studio
+
+Restart LM Studio and start a new chat. Open the integrations menu and look for
+an entry named `mcp/mcp-docker`. Use the toggle to enable the server:
+
+![LM Studio](images/lm-studio.avif)
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```plaintext
+{{% param "test_prompt" %}}
+```
+
+### OpenCode
+
+The OpenCode configuration file (at `~/.config/opencode/opencode.json` by
+default) contains the setup for MCP Toolkit:
+
+```json
+{
+  "mcp": {
+    "MCP_DOCKER": {
+      "type": "local",
+      "command": ["docker", "mcp", "gateway", "run"],
+      "enabled": true
+    }
+  },
+  "$schema": "https://opencode.ai/config.json"
+}
+```
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```console
+$ opencode "{{% param "test_prompt" %}}"
+```
+
+### Sema4.ai Studio {#sema4}
+
+In Sema4.ai Studio, select **Actions** in the sidebar, then select the **MCP
+Servers** tab. You should see Docker MCP Toolkit in the list:
+
+![Docker MCP Toolkit in Sema4.ai Studio](./images/sema4-mcp-list.avif)
+
+To use MCP Toolkit with Sema4.ai, add it as an agent action. Find the agent you
+want to connect to the MCP Toolkit and open the agent editor. Select **Add
+Action**, enable Docker MCP Toolkit in the list, then save your agent:
+
+![Editing an agent in Sema4.ai Studio](images/sema4-edit-agent.avif)
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```plaintext
+{{% param test_prompt %}}
+```
+
+### Visual Studio Code {#vscode}
+
+Open Visual Studio Code. If you configured the MCP Toolkit for a specific
+project, open the relevant project directory. Then open the **Extensions**
+pane. You should see the `MCP_DOCKER` server listed under installed MCP
+servers.
+
+![MCP_DOCKER installed in Visual Studio Code](images/vscode-extensions.avif)
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```plaintext
+{{% param test_prompt %}}
+```
+
+### Zed
+
+Launch Zed and open agent settings:
+
+![Opening Zed agent settings from command palette](images/zed-cmd-palette.avif)
+
+Ensure that `MCP_DOCKER` is listed and enabled in the MCP Servers section:
+
+![MCP_DOCKER in Zed's agent settings](images/zed-agent-settings.avif)
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```plaintext
+{{% param test_prompt %}}
+```
+
+### Mistral Vibe
+
+Mistral Vibe uses a TOML configuration file at `~/.vibe/config.toml`. Add the
+MCP Toolkit as a stdio MCP server in the `[[mcp_servers]]` section:
+
+{{< tabs >}}
+{{< tab name="Linux" >}}
+
+```toml
+[[mcp_servers]]
+name = "MCP_DOCKER"
+transport = "stdio"
+command = ["docker"]
+args = ["mcp", "gateway", "run", "--profile", "my_profile"]
+startup_timeout_sec = 60
+disabled = false
+```
+
+{{< /tab >}}
+{{< tab name="macOS" >}}
+
+```toml
+[[mcp_servers]]
+name = "MCP_DOCKER"
+transport = "stdio"
+command = ["docker"]
+args = ["mcp", "gateway", "run", "--profile", "my_profile"]
+startup_timeout_sec = 60
+disabled = false
+```
+
+{{< /tab >}}
+{{< tab name="Windows" >}}
+
+On Windows, the Docker installation path (`C:\Program Files\Docker\...`)
+contains a space. Use a list for `command` with the full path to `docker.exe`,
+and add `PROGRAMFILES` and `PROGRAMDATA` environment variables that the MCP
+Python SDK doesn't inherit by default:
+
+```toml
+[[mcp_servers]]
+name = "MCP_DOCKER"
+transport = "stdio"
+command = ["C:/Program Files/Docker/Docker/resources/bin/docker.exe"]
+args = ["mcp", "gateway", "run", "--profile", "my_profile"]
+env = { PROGRAMFILES = "C:\\Program Files", PROGRAMDATA = "C:\\ProgramData" }
+startup_timeout_sec = 60
+disabled = false
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+The `startup_timeout_sec = 60` is recommended because the Docker MCP Gateway
+takes approximately 15-25 seconds to start. The default timeout is 10 seconds,
+which isn't enough for the gateway to initialize.
+
+Restart Vibe. In a Vibe CLI session, run `/mcp` to view active MCP servers.
+The `MCP_DOCKER` server should appear in the list:
+
+```console
+$ vibe
+> /mcp
+```
+
+Test the connection by submitting a prompt that invokes one of your installed
+MCP servers:
+
+```console
+$ vibe "{{% param test_prompt %}}"
+```
+
+## Further reading
+
+- [MCP Profiles](/manuals/ai/mcp-catalog-and-toolkit/profiles.md)
+- [MCP Toolkit](/manuals/ai/mcp-catalog-and-toolkit/toolkit.md)
+- [MCP Catalog](/manuals/ai/mcp-catalog-and-toolkit/catalog.md)
+- [MCP Gateway](/manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md)
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/ask-gordon.avif b/content/manuals/ai/mcp-catalog-and-toolkit/images/ask-gordon.avif
new file mode 100644
index 000000000000..9bd35d4f3f72
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/ask-gordon.avif differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/claude-desktop.avif b/content/manuals/ai/mcp-catalog-and-toolkit/images/claude-desktop.avif
new file mode 100644
index 000000000000..e574f4874094
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/claude-desktop.avif differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/copilot-mode.png b/content/manuals/ai/mcp-catalog-and-toolkit/images/copilot-mode.png
new file mode 100644
index 000000000000..9ce6e961c5c6
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/copilot-mode.png differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/cursor.avif b/content/manuals/ai/mcp-catalog-and-toolkit/images/cursor.avif
new file mode 100644
index 000000000000..f092705f87b3
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/cursor.avif differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/goose.avif b/content/manuals/ai/mcp-catalog-and-toolkit/images/goose.avif
new file mode 100644
index 000000000000..3753df012199
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/goose.avif differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/lm-studio.avif b/content/manuals/ai/mcp-catalog-and-toolkit/images/lm-studio.avif
new file mode 100644
index 000000000000..b317ee569dac
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/lm-studio.avif differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/mcp_toolkit.avif b/content/manuals/ai/mcp-catalog-and-toolkit/images/mcp_toolkit.avif
new file mode 100644
index 000000000000..2b33fe673146
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/mcp_toolkit.avif differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/sema4-edit-agent.avif b/content/manuals/ai/mcp-catalog-and-toolkit/images/sema4-edit-agent.avif
new file mode 100644
index 000000000000..b143bee1267f
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/sema4-edit-agent.avif differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/sema4-mcp-list.avif b/content/manuals/ai/mcp-catalog-and-toolkit/images/sema4-mcp-list.avif
new file mode 100644
index 000000000000..92f7a0617e5c
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/sema4-mcp-list.avif differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/tools.png b/content/manuals/ai/mcp-catalog-and-toolkit/images/tools.png
new file mode 100644
index 000000000000..4439dc4b5e1f
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/tools.png differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/vscode-extensions.avif b/content/manuals/ai/mcp-catalog-and-toolkit/images/vscode-extensions.avif
new file mode 100644
index 000000000000..9cd229474f21
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/vscode-extensions.avif differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/zed-agent-settings.avif b/content/manuals/ai/mcp-catalog-and-toolkit/images/zed-agent-settings.avif
new file mode 100644
index 000000000000..6df7e69785ed
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/zed-agent-settings.avif differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/images/zed-cmd-palette.avif b/content/manuals/ai/mcp-catalog-and-toolkit/images/zed-cmd-palette.avif
new file mode 100644
index 000000000000..540dc673106f
Binary files /dev/null and b/content/manuals/ai/mcp-catalog-and-toolkit/images/zed-cmd-palette.avif differ
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md b/content/manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md
new file mode 100644
index 000000000000..f430b1ea55ca
--- /dev/null
+++ b/content/manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md
@@ -0,0 +1,95 @@
+---
+title: MCP Gateway
+linkTitle: Gateway
+description: "Docker's MCP Gateway provides secure, centralized, and scalable orchestration of AI tools through containerized MCP servers, empowering developers, operators, and security teams."
+keywords: MCP Gateway
+weight: 40
+aliases:
+  - /ai/mcp-gateway/
+---
+
+> [!NOTE]
+> MCP Gateway as part of Docker AI Governance is an invite-only feature. [Contact Docker Sales](https://www.docker.com/pricing/contact-sales/) to learn more.
+
+The MCP Gateway is Docker's open source solution for orchestrating Model
+Context Protocol (MCP) servers. It acts as a centralized proxy between clients
+and servers, managing configuration, credentials, and access control.
+
+When using MCP servers without the MCP Gateway, you need to configure
+applications individually for each AI application. With the MCP Gateway, you
+configure applications to connect to the Gateway. The Gateway then handles
+server lifecycle, routing, and authentication across all servers in your
+[profiles](/manuals/ai/mcp-catalog-and-toolkit/profiles.md).
+
+If you use Docker Desktop with MCP Toolkit enabled, the Gateway runs
+automatically in the background. You don't need to start or configure it
+manually. This documentation is for users who want to understand how the Gateway works or run it directly for advanced use cases.
+
+> [!TIP]
+> E2B sandboxes now include direct access to the Docker MCP Catalog, giving developers
+> access to over 200 tools and services to seamlessly build and run AI agents. For
+> more information, see [E2B Sandboxes](e2b-sandboxes.md).
+
+## How it works
+
+MCP Gateway runs MCP servers in isolated Docker containers with restricted
+privileges, network access, and resource usage. It includes built-in logging
+and call-tracing capabilities to ensure full visibility and governance of AI
+tool activity.
+
+The MCP Gateway manages the server's entire lifecycle. When an AI application
+needs to use a tool, it sends a request to the Gateway. The Gateway identifies
+which server handles that tool and, if the server isn't already running, starts
+it as a Docker container. The Gateway then injects any required credentials,
+applies security restrictions, and forwards the request to the server. The
+server processes the request and returns the result through the Gateway back to
+the AI application.
+
+The MCP Gateway solves a fundamental problem: MCP servers are just programs
+that need to run somewhere. Running them directly on your machine means dealing
+with installation, dependencies, updates, and security risks. By running them
+as containers managed by the Gateway, you get isolation, consistent
+environments, and centralized control.
+
+The Gateway works with profiles to determine which servers are available. When
+you run the Gateway, you specify which profile to use with the `--profile` flag
+to determine which servers are made available to clients.
+
+## Usage
+
+To use the MCP Gateway, you'll need Docker Desktop with MCP Toolkit enabled.
+Follow the [MCP Toolkit guide](toolkit.md) to enable and configure servers
+through the Docker Desktop interface, or see
+[Use MCP Toolkit from the CLI](cli.md) for terminal-based workflows.
+
+### Install the MCP Gateway manually
+
+For Docker Engine without Docker Desktop, you'll need to download and install
+the MCP Gateway separately before you can run it.
+
+1. Download the latest binary from the [GitHub releases page](https://github.com/docker/mcp-gateway/releases/latest).
+
+2. Move or symlink the binary to the destination matching your OS:
+
+   | OS      | Binary destination                  |
+   | ------- | ----------------------------------- |
+   | Linux   | `~/.docker/cli-plugins/docker-mcp`  |
+   | macOS   | `~/.docker/cli-plugins/docker-mcp`  |
+   | Windows | `%USERPROFILE%\.docker\cli-plugins` |
+
+3. Make the binaries executable:
+
+   ```bash
+   $ chmod +x ~/.docker/cli-plugins/docker-mcp
+   ```
+
+You can now use the `docker mcp` command:
+
+```bash
+docker mcp --help
+```
+
+## Additional information
+
+For more details on how the MCP Gateway works and available customization
+options, see the complete documentation [on GitHub](https://github.com/docker/mcp-gateway).
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/profiles.md b/content/manuals/ai/mcp-catalog-and-toolkit/profiles.md
new file mode 100644
index 000000000000..8529872e4275
--- /dev/null
+++ b/content/manuals/ai/mcp-catalog-and-toolkit/profiles.md
@@ -0,0 +1,268 @@
+---
+title: MCP Profiles
+linkTitle: Profiles
+description: Organize MCP servers into profiles for different projects and environments
+keywords: Docker MCP, profiles, MCP servers, configuration, sharing
+weight: 25
+---
+
+{{< summary-bar feature_name="MCP Profiles" >}}
+
+Profiles organize your MCP servers into named collections. Without profiles,
+you'd configure servers separately for every AI application you use. Each time
+you want to change which servers are available, you'd update Claude Desktop, VS
+Code, Cursor, and other tools individually. Profiles solve this by centralizing
+your server configurations.
+
+## What profiles do
+
+A profile is a named collection of MCP servers with their configurations and
+settings. You select servers from the [MCP
+Catalog](/manuals/ai/mcp-catalog-and-toolkit/catalog.md) (the source of
+available servers) and add them to your profiles (your configured server
+collections for specific work). Think of the catalog as a library of tools, and
+profiles as your toolboxes organized for different jobs.
+
+Your "web-dev" profile might include GitHub, Playwright, and database servers.
+Your "data-analysis" profile might include spreadsheet, API, and visualization
+servers. Connect different AI clients to different profiles, or switch between
+profiles as you change tasks.
+
+When you run the MCP Gateway or connect a client without specifying a profile,
+Docker MCP uses your default profile. If you're upgrading from a previous
+version of MCP Toolkit, your existing server configurations are already in the
+default profile.
+
+## Profile capabilities
+
+Each profile maintains its own isolated collection of servers and
+configurations. Your "web-dev" profile might include GitHub, Playwright, and
+database servers, while your "data-analysis" profile includes spreadsheet, API,
+and visualization servers. Create as many profiles as you need, each containing
+only the servers relevant to that context.
+
+> [!NOTE]
+>
+> OAuth credentials are an exception to profile isolation — they are shared
+> across all profiles. If you need to use different accounts for different
+> projects, revoke and re-authorize when switching profiles.
+
+You can connect different AI applications to different profiles. When you
+connect a client, you specify which profile it should use. This means Claude
+Desktop and VS Code can have access to different server collections if needed.
+
+Profiles can be shared with your team. Push a profile to your registry, and
+team members can pull it to get the exact same server collection and
+configuration you use.
+
+## Creating and managing profiles
+
+### Create a profile
+
+1. In Docker Desktop, select **MCP Toolkit** and select the **Profiles** tab.
+2. Select **Create profile**.
+3. Enter a name for your profile (e.g., "web-dev").
+4. Optionally, search and add servers to your profile now, or add them later.
+5. Optionally, search and add clients to connect to your profile.
+6. Select **Create**.
+
+Your new profile appears in the profiles list.
+
+### View profile details
+
+Select a profile in the **Profiles** tab to view its details. The profile view
+has two tabs:
+
+- **Overview**: Shows the servers in your profile, secrets configuration, and
+  connected clients. Use the **+** buttons to add more servers or clients.
+- **Tools**: Lists all available tools from your profile's servers. You can
+  enable or disable individual tools.
+
+### Remove a profile
+
+1. In the **Profiles** tab, find the profile you want to remove.
+2. Select ⋮ next to the profile name, and then **Delete**.
+3. Confirm the removal.
+
+> [!CAUTION]
+> Removing a profile deletes all its server configurations and settings, and
+> updates the client configuration (removes MCP Toolkit). This action can't be
+> undone.
+
+### Default profile
+
+When you run the MCP Gateway or use MCP Toolkit without specifying a profile,
+Docker MCP uses a profile named `default`, or an empty configuration if a
+`default` profile does not exist.
+
+If you're upgrading from a previous version of MCP Toolkit, your existing
+server configurations automatically migrate to the `default` profile. You don't
+need to manually recreate your setup - everything continues to work as before.
+
+You can always specify a different profile using the `--profile` flag with the
+gateway command:
+
+```console
+$ docker mcp gateway run --profile web-dev
+```
+
+## Adding servers to profiles
+
+Profiles contain the MCP servers you select from the catalog. Add servers to
+organize your tools for specific workflows.
+
+### Add a server
+
+You can add servers to a profile in two ways.
+
+From the Catalog tab:
+
+1. Select the **Catalog** tab.
+2. Select the checkbox next to servers you want to add to see which profile to
+   add them to.
+3. Choose your profile from the drop-down.
+
+From within a profile:
+
+1. Select the **Profiles** tab and select your profile.
+2. In the **Servers** section, select the **+** button.
+3. Search for and select servers to add.
+
+If a server requires OAuth authentication, you're prompted to authorize it. See
+[OAuth authentication](/manuals/ai/mcp-catalog-and-toolkit/toolkit.md#oauth-authentication)
+for details.
+
+### List servers in a profile
+
+Select a profile in the **Profiles** tab to see all servers it contains.
+
+### Remove a server
+
+1. Select the **Profiles** tab and select your profile.
+2. In the **Servers** section, find the server you want to remove.
+3. Select the delete icon next to the server.
+
+## Configuring profiles
+
+### Server configuration
+
+Some servers require configuration beyond authentication. Configure server
+settings within your profile.
+
+1. Select the **Profiles** tab and select your profile.
+2. In the **Servers** section, select the configure icon next to the server.
+3. Adjust the server's configuration settings as needed.
+
+### OAuth credentials
+
+OAuth credentials are shared across all profiles. When you authorize access to
+a service like GitHub or Notion, that authorization is available to any server
+in any profile that needs it.
+
+This means all profiles use the same OAuth credentials for a given service. If
+you need to use different accounts for different projects, you'll need to
+revoke and re-authorize between switching profiles.
+
+See [OAuth authentication](/manuals/ai/mcp-catalog-and-toolkit/toolkit.md#oauth-authentication)
+for details on authorizing servers.
+
+### Configuration persistence
+
+Profile configurations persist in your Docker installation. When you restart
+Docker Desktop or your system, your profiles, servers, and configurations
+remain intact.
+
+## Sharing profiles
+
+Profiles can be shared with your team by pushing them to OCI-compliant
+registries as artifacts. This is useful for distributing standardized MCP
+setups across your organization. Credentials are not included in shared
+profiles for security reasons. Team members configure OAuth separately after
+pulling.
+
+### Push a profile
+
+1. Select the profile you want to share in the **Profiles** tab.
+2. Select **Push to Registry**.
+3. Enter the registry destination (e.g., `registry.example.com/profiles/web-dev:v1`).
+4. Complete authentication if required.
+
+### Pull a profile
+
+1. Select **Pull from Registry** in the **Profiles** tab.
+2. Enter the registry reference (e.g., `registry.example.com/profiles/team-standard:latest`).
+3. Complete authentication if required.
+
+The profile is downloaded and added to your profiles list. Configure any
+required OAuth credentials separately.
+
+### Team collaboration workflow
+
+A typical workflow for sharing profiles across a team:
+
+1. Create and configure a profile with the servers your team needs.
+2. Test the profile to ensure it works as expected.
+3. Push the profile to your team's registry with a version tag (e.g.,
+   `registry.example.com/profiles/team-dev:v1`).
+4. Share the registry reference with your team.
+5. Team members pull the profile and configure any required OAuth credentials.
+
+This ensures everyone uses the same server collection and configuration,
+reducing setup time and inconsistencies.
+
+## Using profiles with clients
+
+When you connect an AI client to the MCP Gateway, you specify which profile's
+servers the client can access.
+
+### Run the gateway with a profile
+
+Connect clients to your profile through the **Clients** section in the MCP
+Toolkit. You can add clients when creating a profile or add them to existing
+profiles later.
+
+### Configure clients for specific profiles
+
+When setting up a client manually, you can specify which profile the client
+uses. This lets different clients connect to different profiles.
+
+For example, your Claude Desktop configuration might use:
+
+```json
+{
+  "mcpServers": {
+    "MCP_DOCKER": {
+      "command": "docker",
+      "args": ["mcp", "gateway", "run", "--profile", "claude-work"]
+    }
+  }
+}
+```
+
+While your VS Code configuration uses a different profile:
+
+```json
+{
+  "mcp": {
+    "servers": {
+      "MCP_DOCKER": {
+        "command": "docker",
+        "args": ["mcp", "gateway", "run", "--profile", "vscode-dev"],
+        "type": "stdio"
+      }
+    }
+  }
+}
+```
+
+### Switching between profiles
+
+To switch the profile your clients use, update the client configuration to
+specify a different `--profile` value in the gateway command arguments.
+
+## Further reading
+
+- [Get started with MCP Toolkit](/manuals/ai/mcp-catalog-and-toolkit/get-started.md)
+- [Use MCP Toolkit from the CLI](/manuals/ai/mcp-catalog-and-toolkit/cli.md)
+- [MCP Catalog](/manuals/ai/mcp-catalog-and-toolkit/catalog.md)
+- [MCP Toolkit](/manuals/ai/mcp-catalog-and-toolkit/toolkit.md)
diff --git a/content/manuals/ai/mcp-catalog-and-toolkit/toolkit.md b/content/manuals/ai/mcp-catalog-and-toolkit/toolkit.md
new file mode 100644
index 000000000000..7a851c17effe
--- /dev/null
+++ b/content/manuals/ai/mcp-catalog-and-toolkit/toolkit.md
@@ -0,0 +1,199 @@
+---
+title: Docker MCP Toolkit
+linkTitle: Toolkit UI
+description: Use the MCP Toolkit to set up MCP servers and MCP clients.
+keywords: Docker MCP Toolkit, MCP server, MCP client, AI agents
+weight: 30
+aliases:
+  - /desktop/features/gordon/mcp/gordon-mcp-server/
+  - /ai/gordon/mcp/gordon-mcp-server/
+---
+
+{{< summary-bar feature_name="Docker MCP Toolkit" >}}
+
+> [!NOTE]
+> This page describes the MCP Toolkit interface in Docker Desktop 4.62 and
+> later. Earlier versions have a different UI. Upgrade to follow these
+> instructions exactly.
+
+The Docker MCP Toolkit is a management interface integrated into Docker Desktop
+that lets you set up, manage, and run containerized MCP servers in profiles and
+connect them to AI agents. It removes friction from tool usage by offering
+secure defaults, easy setup, and support for a growing ecosystem of LLM-based
+clients. It is the fastest way from MCP tool discovery to local execution.
+
+## Key features
+
+- Cross-LLM compatibility: Works with Claude, Cursor, and other MCP clients.
+- Integrated tool discovery: Browse and launch MCP servers from the Docker MCP Catalog directly in Docker Desktop.
+- Zero manual setup: No dependency management, runtime configuration, or setup required.
+- Profile-based organization: Create separate server collections for different projects or environments.
+- Organizes MCP servers into profiles, acting as a gateway for clients to access the servers in each profile.
+
+> [!TIP]
+> The MCP Toolkit includes [Dynamic MCP](/manuals/ai/mcp-catalog-and-toolkit/dynamic-mcp.md),
+> which enables AI agents to discover, add, and compose MCP servers on-demand during
+> conversations, without manual configuration. Your agent can search the catalog and
+> add tools as needed when you connect to the gateway.
+
+## How the MCP Toolkit works
+
+MCP introduces two core concepts: MCP clients and MCP servers.
+
+- MCP clients are typically embedded in LLM-based applications, such as the
+  Claude Desktop app. They request resources or actions.
+- MCP servers are launched by the client to perform the requested tasks, using
+  any necessary tools, languages, or processes.
+
+Docker standardizes the development, packaging, and distribution of
+applications, including MCP servers. By packaging MCP servers as containers,
+Docker eliminates issues related to isolation and environment differences. You
+can run a container directly, without managing dependencies or configuring
+runtimes.
+
+Depending on the MCP server, the tools it provides might run within the same
+container as the server or in dedicated containers for better isolation.
+
+The MCP Toolkit organizes servers into profiles: named collections of servers
+with their configurations. This lets you maintain different server setups for
+different projects or environments. When you connect a client, you specify
+which profile it should use.
+
+## Security
+
+The Docker MCP Toolkit combines passive and active measures to reduce attack
+surfaces and ensure safe runtime behavior.
+
+### Passive security
+
+Passive security refers to measures implemented at build-time, when the MCP
+server code is packaged into a Docker image.
+
+- Image signing and attestation: All MCP server images under `mcp/` in the [MCP
+  Catalog](catalog.md) are built by Docker and digitally signed to verify their
+  source and integrity. Each image includes a Software Bill of Materials (SBOM)
+  for full transparency.
+
+### Active security
+
+Active security refers to security measures at runtime, before and after tools
+are invoked, enforced through resource and access limitations.
+
+- CPU allocation: MCP tools are run in their own container. They are
+  restricted to 1 CPU, limiting the impact of potential misuse of computing
+  resources.
+
+- Memory allocation: Containers for MCP tools are limited to 2 GB.
+
+- Filesystem access: By default, MCP Servers have no access to the host filesystem.
+  The user explicitly selects the servers that will be granted file mounts.
+
+- Interception of tool requests: Requests to and from tools that contain sensitive
+  information such as secrets are blocked.
+
+### OAuth authentication
+
+Some MCP servers require authentication to access external services like
+GitHub, Notion, and Linear. The MCP Toolkit handles OAuth authentication
+automatically. You authorize access through your browser, and the Toolkit
+manages credentials securely. You don't need to manually create API tokens or
+configure authentication for each service.
+
+#### Authorize a server with OAuth
+
+1. In Docker Desktop, go to **MCP Toolkit** and select the **Catalog** tab.
+2. Find and add an MCP server that requires OAuth.
+3. In the server's **Configuration** tab, select the **OAuth** authentication
+   method. Follow the link to begin the OAuth authorization.
+4. Your browser opens the authorization page for the service. Follow the
+   on-screen instructions to complete authentication.
+5. Return to Docker Desktop when authentication is complete.
+
+View all authorized services in the **OAuth** tab. To revoke access, select
+**Revoke** next to the service you want to disconnect.
+
+## Usage examples
+
+### Example: Use Claude Desktop as a client
+
+Imagine you have Claude Desktop installed, and you want to use the GitHub MCP
+server and the Puppeteer MCP server. You do not have to install the servers in
+Claude Desktop. You can add these 2 MCP servers to your profile in the MCP
+Toolkit and connect Claude Desktop as a client:
+
+1. From the **MCP Toolkit** menu, select the **Catalog** tab and find the **Puppeteer** server and add it to your profile.
+1. Repeat for the **GitHub Official** server.
+1. From the **Clients** tab, select **Connect** next to **Claude Desktop**. Restart
+   Claude Desktop if it's running, and it can now access all the servers in the MCP Toolkit.
+1. Within Claude Desktop, run a test by submitting the following prompt using the Sonnet 3.5 model:
+
+   ```text
+   Take a screenshot of docs.docker.com and then invert the colors
+   ```
+
+### Example: Use Visual Studio Code as a client
+
+You can interact with all your installed MCP servers in Visual Studio Code:
+
+1. To enable the MCP Toolkit:
+
+   {{< tabs group="" >}}
+   {{< tab name="Enable globally">}}
+   1. Insert the following in your Visual Studio Code's User `mcp.json`:
+
+      ```json
+      "mcp": {
+       "servers": {
+         "MCP_DOCKER": {
+           "command": "docker",
+           "args": [
+             "mcp",
+             "gateway",
+             "run",
+             "--profile",
+             "my_profile"
+           ],
+           "type": "stdio"
+         }
+       }
+      }
+      ```
+
+   {{< /tab >}}
+   {{< tab name="Enable for a given project">}}
+   1. In your terminal, navigate to your project's folder.
+   1. Run:
+
+      ```bash
+      docker mcp client connect vscode --profile my_profile
+      ```
+
+      > [!NOTE]
+      > This command creates a `.vscode/mcp.json` file in the current directory
+      > that connects VSCode to your profile. As this is a user-specific file,
+      > add it to your `.gitignore` file to prevent it from being committed to
+      > the repository.
+      >
+      > ```console
+      > echo ".vscode/mcp.json" >> .gitignore
+      > ```
+
+{{< /tab >}}
+{{</tabs >}}
+
+1. In Visual Studio Code, open a new Chat and select the **Agent** mode:
+
+   ![Copilot mode switching](./images/copilot-mode.png)
+
+1. You can also check the available MCP tools:
+
+   ![Displaying tools in VSCode](./images/tools.png)
+
+For more information about the Agent mode, see the
+[Visual Studio Code documentation](https://code.visualstudio.com/docs/copilot/chat/mcp-servers#_use-mcp-tools-in-agent-mode).
+
+## Further reading
+
+- [Use MCP Toolkit from the CLI](/manuals/ai/mcp-catalog-and-toolkit/cli.md)
+- [MCP Catalog](/manuals/ai/mcp-catalog-and-toolkit/catalog.md)
+- [MCP Gateway](/manuals/ai/mcp-catalog-and-toolkit/mcp-gateway.md)
diff --git a/content/manuals/ai/model-runner.md b/content/manuals/ai/model-runner.md
deleted file mode 100644
index 1f8aab071af9..000000000000
--- a/content/manuals/ai/model-runner.md
+++ /dev/null
@@ -1,373 +0,0 @@
----
-title: Docker Model Runner
-params:
-  sidebar:
-    badge:
-      color: blue
-      text: Beta
-    group: AI
-weight: 20
-description: Learn how to use Docker Model Runner to manage and run AI models. 
-keywords: Docker, ai, model runner, docker deskotp, llm
-aliases: 
-  - /desktop/features/model-runner/
----
-
-{{< summary-bar feature_name="Docker Model Runner" >}}
-
-The Docker Model Runner plugin lets you:
-
-- [Pull models from Docker Hub](https://hub.docker.com/u/ai)
-- Run AI models directly from the command line
-- Manage local models (add, list, remove)
-- Interact with models using a submitted prompt or in chat mode in the CLI or Docker Desktop Dashboard
-- Push models to Docker Hub
-
-Models are pulled from Docker Hub the first time they're used and stored locally. They're loaded into memory only at runtime when a request is made, and unloaded when not in use to optimize resources. Since models can be large, the initial pull may take some time — but after that, they're cached locally for faster access. You can interact with the model using [OpenAI-compatible APIs](#what-api-endpoints-are-available).
-
-> [!TIP]
->
-> Using Testcontainers or Docker Compose? [Testcontainers for Java](https://java.testcontainers.org/modules/docker_model_runner/) and [Go](https://golang.testcontainers.org/modules/dockermodelrunner/), and [Docker Compose](/manuals/compose/how-tos/model-runner.md) now support Docker Model Runner.
-
-## Enable Docker Model Runner
-
-1. Navigate to the **Features in development** tab in settings.
-2. Under the **Experimental features** tab, select **Access experimental features**.
-3. Select **Apply and restart**. 
-4. Quit and reopen Docker Desktop to ensure the changes take effect. 
-5. Open the **Settings** view in Docker Desktop.
-6. Navigate to **Features in development**.
-7. From the **Beta** tab, check the **Enable Docker Model Runner** setting.
-
-You can now use the `docker model` command in the CLI and view and interact with your local models in the **Models** tab in the Docker Desktop Dashboard.
-
-## Available commands
-
-### Model runner status
-
-Check whether the Docker Model Runner is active:
-
-```console
-$ docker model status
-```
-
-### View all commands
-
-Displays help information and a list of available subcommands.
- 
-```console
-$ docker model help
-```
-
-Output:
-
-```text
-Usage:  docker model COMMAND
-
-Commands:
-  list        List models available locally
-  pull        Download a model from Docker Hub
-  rm          Remove a downloaded model
-  run         Run a model interactively or with a prompt
-  status      Check if the model runner is running
-  version     Show the current version
-```
-
-### Pull a model 
-
-Pulls a model from Docker Hub to your local environment.
-
-```console
-$ docker model pull <model>
-```
-
-Example: 
-
-```console
-$ docker model pull ai/smollm2
-```
-
-Output:
-
-```text
-Downloaded: 257.71 MB
-Model ai/smollm2 pulled successfully
-```
-
-The models also display in the Docker Desktop Dashboard.
-
-### List available models
-
-Lists all models currently pulled to your local environment.
-
-```console
-$ docker model list
-```
-
-You will see something similar to:
-
-```text
-+MODEL       PARAMETERS  QUANTIZATION    ARCHITECTURE  MODEL ID      CREATED     SIZE
-+ai/smollm2  361.82 M    IQ2_XXS/Q4_K_M  llama         354bf30d0aa3  3 days ago  256.35 MiB
-```
-
-### Run a model
-
-Run a model and interact with it using a submitted prompt or in chat mode.
-
-#### One-time prompt
-
-```console
-$ docker model run ai/smollm2 "Hi"
-```
-
-Output:
-
-```text
-Hello! How can I assist you today?
-```
-
-#### Interactive chat
-
-```console
-$ docker model run ai/smollm2
-```
-
-Output:
-
-```text
-Interactive chat mode started. Type '/bye' to exit.
-> Hi
-Hi there! It's SmolLM, AI assistant. How can I help you today?
-> /bye
-Chat session ended.
-```
-
-> [!TIP]
->
-> You can also use chat mode in the Docker Desktop Dashboard when you select the model in the **Models** tab.
-
-### Push a model to Docker Hub
-
-Use the following command to push your model to Docker Hub:
-
-```console
-$ docker model push <namespace>/<model>
-```
-
-### Tag a model
-
-You can specify a particular version or variant of the model:
-
-```console
-$ docker model tag 
-```
-
-If no tag is provided, Docker defaults to `latest`.
-
-### View the logs
-
-Fetch logs from Docker Model Runner to monitor activity or debug issues.
-
-```console
-$ docker model logs 
-```
-
-The following flags are accepted:
-
-- `-f`/`--follow`: View logs with real-time streaming
-- `--no-engines`: Exclude inference engine logs from the output
-
-### Remove a model
-
-Removes a downloaded model from your system.
-
-```console
-$ docker model rm <model>
-```
-
-Output:
-
-```text
-Model <model> removed successfully
-```
-
-## Integrate the Docker Model Runner into your software development lifecycle
-
-You can now start building your Generative AI application powered by the Docker Model Runner.
-
-If you want to try an existing GenAI application, follow these instructions.
-
-1. Set up the sample app. Clone and run the following repository:
-
-   ```console
-   $ git clone https://github.com/docker/hello-genai.git
-   ```
-
-2. In your terminal, navigate to the `hello-genai` directory.
-
-3. Run `run.sh` for pulling the chosen model and run the app(s):
-
-4. Open you app in the browser at the addresses specified in the repository [README](https://github.com/docker/hello-genai).
-
-You'll see the GenAI app's interface where you can start typing your prompts. 
-
-You can now interact with your own GenAI app, powered by a local model. Try a few prompts and notice how fast the responses are — all running on your machine with Docker.
-
-## FAQs
-
-### What models are available?
-
-All the available models are hosted in the [public Docker Hub namespace of `ai`](https://hub.docker.com/u/ai). 
-
-### What API endpoints are available?
-
-Once the feature is enabled, the following new APIs are available:
-
-```text
-#### Inside containers ####
-
-http://model-runner.docker.internal/
-
-    # Docker Model management
-    POST /models/create
-    GET /models
-    GET /models/{namespace}/{name}
-    DELETE /models/{namespace}/{name}
-
-    # OpenAI endpoints
-    GET /engines/llama.cpp/v1/models
-    GET /engines/llama.cpp/v1/models/{namespace}/{name}
-    POST /engines/llama.cpp/v1/chat/completions
-    POST /engines/llama.cpp/v1/completions
-    POST /engines/llama.cpp/v1/embeddings
-    Note: You can also omit llama.cpp.
-    E.g., POST /engines/v1/chat/completions.
-
-#### Inside or outside containers (host) ####
-
-Same endpoints on /var/run/docker.sock
-
-    # While still in Beta
-    Prefixed with /exp/vDD4.40
-```
-
-### How do I interact through the OpenAI API?
-
-#### From within a container
-
-Examples of calling an OpenAI endpoint (`chat/completions`) from within another container using `curl`:
-
-```bash
-#!/bin/sh
-
-curl http://model-runner.docker.internal/engines/llama.cpp/v1/chat/completions \
-    -H "Content-Type: application/json" \
-    -d '{
-        "model": "ai/smollm2",
-        "messages": [
-            {
-                "role": "system",
-                "content": "You are a helpful assistant."
-            },
-            {
-                "role": "user",
-                "content": "Please write 500 words about the fall of Rome."
-            }
-        ]
-    }'
-
-```
-
-#### From the host using a Unix socket
-
-Examples of calling an OpenAI endpoint (`chat/completions`) through the Docker socket from the host using `curl`:
-
-```bash
-#!/bin/sh
-
-curl --unix-socket $HOME/.docker/run/docker.sock \
-    localhost/exp/vDD4.40/engines/llama.cpp/v1/chat/completions \
-    -H "Content-Type: application/json" \
-    -d '{
-        "model": "ai/smollm2",
-        "messages": [
-            {
-                "role": "system",
-                "content": "You are a helpful assistant."
-            },
-            {
-                "role": "user",
-                "content": "Please write 500 words about the fall of Rome."
-            }
-        ]
-    }'
-
-```
-
-#### From the host using TCP
-
-In case you want to interact with the API from the host, but use TCP instead of a Docker socket, you can enable the host-side TCP support from the Docker Desktop GUI, or via the [Docker Desktop CLI](/manuals/desktop/features/desktop-cli.md). For example, using `docker desktop enable model-runner --tcp <port>`.
-
-Afterwards, interact with it as previously documented using `localhost` and the chosen, or the default port.
-
-```bash
-#!/bin/sh
-
-	curl http://localhost:12434/engines/llama.cpp/v1/chat/completions \
-    -H "Content-Type: application/json" \
-    -d '{
-        "model": "ai/smollm2",
-        "messages": [
-            {
-                "role": "system",
-                "content": "You are a helpful assistant."
-            },
-            {
-                "role": "user",
-                "content": "Please write 500 words about the fall of Rome."
-            }
-        ]
-    }'
-```
-
-## Known issues
-
-### `docker model` is not recognised
-
-If you run a Docker Model Runner command and see:
-
-```text
-docker: 'model' is not a docker command
-```
-
-It means Docker can't find the plugin because it's not in the expected CLI plugins directory.
-
-To fix this, create a symlink so Docker can detect it:
-
-```console
-$ ln -s /Applications/Docker.app/Contents/Resources/cli-plugins/docker-model ~/.docker/cli-plugins/docker-model
-```
-
-Once linked, re-run the command.
-
-### No safeguard for running oversized models
-
-Currently, Docker Model Runner doesn't include safeguards to prevent you from launching models that exceed their system’s available resources. Attempting to run a model that is too large for the host machine may result in severe slowdowns or render the system temporarily unusable. This issue is particularly common when running LLMs models without sufficient GPU memory or system RAM. 
-
-### No consistent digest support in Model CLI
-
-The Docker Model CLI currently lacks consistent support for specifying models by image digest. As a temporary workaround, you should refer to models by name instead of digest.
-
-## Share feedback
-
-Thanks for trying out Docker Model Runner. Give feedback or report any bugs you may find through the **Give feedback** link next to the **Enable Docker Model Runner** setting. 
-
-## Disable the feature
-
-To disable Docker Model Runner:
-
-1. Open the **Settings** view in Docker Desktop.
-2. Navigate to the **Beta** tab in **Features in development**.
-3. Clear the **Enable Docker Model Runner** checkbox.
-4. Select **Apply & restart**.
\ No newline at end of file
diff --git a/content/manuals/ai/model-runner/_index.md b/content/manuals/ai/model-runner/_index.md
new file mode 100644
index 000000000000..d54acb3b32d8
--- /dev/null
+++ b/content/manuals/ai/model-runner/_index.md
@@ -0,0 +1,185 @@
+---
+title: Docker Model Runner
+linkTitle: Model Runner
+params:
+  sidebar:
+    group: AI and agents
+weight: 30
+description: Learn how to use Docker Model Runner to manage and run AI models.
+keywords: Docker, ai, model runner, docker desktop, docker engine, llm, openai, ollama, llama.cpp, vllm, diffusers, cpu, nvidia, cuda, amd, rocm, vulkan, cline, continue, cursor, image generation, stable diffusion
+aliases:
+  - /desktop/features/model-runner/
+  - /model-runner/
+---
+
+{{< summary-bar feature_name="Docker Model Runner" >}}
+
+Docker Model Runner (DMR) makes it easy to manage, run, and
+deploy AI models using Docker. Designed for developers,
+Docker Model Runner streamlines the process of pulling, running, and serving
+large language models (LLMs) and other AI models directly from Docker Hub,
+any OCI-compliant registry, or [Hugging Face](https://huggingface.co/).
+
+With seamless integration into Docker Desktop and Docker
+Engine, you can serve models via OpenAI and Ollama-compatible APIs, package GGUF files as
+OCI Artifacts, and interact with models from both the command line and graphical
+interface.
+
+Whether you're building generative AI applications, experimenting with machine
+learning workflows, or integrating AI into your software development lifecycle,
+Docker Model Runner provides a consistent, secure, and efficient way to work
+with AI models locally.
+
+## Key features
+
+- [Pull and push models to and from Docker Hub or any OCI-compliant registry](https://hub.docker.com/u/ai)
+- [Pull models from Hugging Face](https://huggingface.co/)
+- Serve models on [OpenAI and Ollama-compatible APIs](api-reference.md) for easy integration with existing apps
+- Support for [llama.cpp, vLLM, and Diffusers inference engines](inference-engines.md) (vLLM and Diffusers on Linux with NVIDIA GPUs)
+- [Generate images from text prompts](inference-engines.md#diffusers) using Stable Diffusion models with the Diffusers backend
+- Package GGUF and Safetensors files as OCI Artifacts and publish them to any Container Registry
+- Run and interact with AI models directly from the command line or from the Docker Desktop GUI
+- [Connect to AI coding tools](ide-integrations.md) like Cline, Continue, Cursor, and Aider
+- [Configure context size and model parameters](configuration.md) to tune performance
+- [Set up Open WebUI](openwebui-integration.md) for a ChatGPT-like web interface
+- Manage local models and display logs
+- Display prompt and response details
+- Conversational context support for multi-turn interactions
+
+## Requirements
+
+Docker Model Runner is supported on the following platforms:
+
+{{< tabs >}}
+{{< tab name="Windows">}}
+
+Windows(amd64):
+-  NVIDIA GPUs
+-  NVIDIA drivers 576.57+
+
+Windows(arm64):
+- OpenCL for Adreno
+- Qualcomm Adreno GPU (6xx series and later)
+
+  > [!NOTE]
+  > Some llama.cpp features might not be fully supported on the 6xx series.
+
+{{< /tab >}}
+{{< tab name="MacOS">}}
+
+- Apple Silicon
+
+{{< /tab >}}
+{{< tab name="Linux">}}
+
+Docker Engine only:
+
+- Supports CPU, NVIDIA (CUDA), AMD (ROCm), and Vulkan backends
+- Requires NVIDIA driver 575.57.08+ when using NVIDIA GPUs
+
+{{< /tab >}}
+{{</tabs >}}
+
+## How Docker Model Runner works
+
+Models are pulled from Docker Hub, an OCI-compliant registry, or
+[Hugging Face](https://huggingface.co/) the first time you use them and are
+stored locally. They load into memory only at runtime when a request is made,
+and unload when not in use to optimize resources. Because models can be large,
+the initial pull may take some time. After that, they're cached locally for
+faster access. You can interact with the model using
+[OpenAI and Ollama-compatible APIs](api-reference.md).
+
+### Inference engines
+
+Docker Model Runner supports three inference engines:
+
+| Engine | Best for | Model format |
+|--------|----------|--------------|
+| [llama.cpp](inference-engines.md#llamacpp) | Local development, resource efficiency | GGUF (quantized) |
+| [vLLM](inference-engines.md#vllm) | Production, high throughput | Safetensors |
+| [Diffusers](inference-engines.md#diffusers) | Image generation (Stable Diffusion) | Safetensors |
+
+llama.cpp is the default engine and works on all platforms. vLLM requires NVIDIA GPUs and is supported on Linux x86_64 and Windows with WSL2. Diffusers enables image generation and requires NVIDIA GPUs on Linux (x86_64 or ARM64). See [Inference engines](inference-engines.md) for detailed comparison and setup.
+
+### Context size
+
+Models have a configurable context size (context length) that determines how many tokens they can process. The default varies by model but is typically 2,048-8,192 tokens. You can adjust this per-model:
+
+```console
+$ docker model configure --context-size 8192 ai/qwen2.5-coder
+```
+
+See [Configuration options](configuration.md) for details on context size and other parameters.
+
+> [!TIP]
+>
+> Using Testcontainers or Docker Compose?
+> [Testcontainers for Java](https://java.testcontainers.org/modules/docker_model_runner/)
+> and [Go](https://golang.testcontainers.org/modules/dockermodelrunner/), and
+> [Docker Compose](/manuals/ai/compose/models-and-compose.md) support Docker
+> Model Runner.
+
+## Security and isolation
+
+### Execution environment
+
+Docker Model Runner isolates inference engines from your host:
+
+- On Linux, Docker Model Runner and its inference engines, such as Diffusers,
+  run inside a container, which provides the isolation boundary.
+- On macOS and Windows, the engines don't run inside a container, so Docker
+  Model Runner runs them in a sandboxed environment (seatbelt/sandbox-exec and Job Objects respectively)
+
+### Networking
+
+The Model Runner API is not authenticated. Any client that can reach it,
+including other containers on the same Docker network, can pull, load, and
+run models, and send inference requests.
+
+## Known issues
+
+### `docker model` is not recognised
+
+If you run a Docker Model Runner command and see:
+
+```text
+docker: 'model' is not a docker command
+```
+
+It means Docker can't find the plugin because it's not in the expected CLI plugins directory.
+
+To fix this, create a symlink so Docker can detect it:
+
+```console
+$ ln -s /Applications/Docker.app/Contents/Resources/cli-plugins/docker-model ~/.docker/cli-plugins/docker-model
+```
+
+Once linked, rerun the command.
+
+## Privacy and data collection
+
+Docker Model Runner respects your privacy settings in Docker Desktop. Data collection is controlled by the **Send usage statistics** setting:
+
+- **Disabled**: No usage data is collected
+- **Enabled**: Only minimal, non-personal data is collected:
+  - [Model names](https://github.com/docker/model-runner/blob/eb76b5defb1a598396f99001a500a30bbbb48f01/pkg/metrics/metrics.go#L96) (via HEAD requests to Docker Hub)
+  - User agent information
+  - Whether requests originate from the host or containers
+
+When using Docker Model Runner with Docker Engine, HEAD requests to Docker Hub are made to track model names, regardless of any settings.
+
+No prompt content, responses, or personally identifiable information is ever collected.
+
+## Share feedback
+
+Thanks for trying out Docker Model Runner. To report bugs or request features, [open an issue on GitHub](https://github.com/docker/model-runner/issues). You can also give feedback through the **Give feedback** link next to the **Enable Docker Model Runner** setting.
+
+## Next steps
+
+- [Get started with DMR](get-started.md) - Enable DMR and run your first model
+- [API reference](api-reference.md) - OpenAI and Ollama-compatible API documentation
+- [Configuration options](configuration.md) - Context size and runtime parameters
+- [Inference engines](inference-engines.md) - llama.cpp, vLLM, and Diffusers details
+- [IDE integrations](ide-integrations.md) - Connect Cline, Continue, Cursor, and more
+- [Open WebUI integration](openwebui-integration.md) - Set up a web chat interface
diff --git a/content/manuals/ai/model-runner/api-reference.md b/content/manuals/ai/model-runner/api-reference.md
new file mode 100644
index 000000000000..edc36eec9aa4
--- /dev/null
+++ b/content/manuals/ai/model-runner/api-reference.md
@@ -0,0 +1,439 @@
+---
+title: DMR REST API
+description: Reference documentation for the Docker Model Runner REST API endpoints, including OpenAI, Anthropic, and Ollama compatibility.
+weight: 30
+keywords: Docker, ai, model runner, rest api, openai, anthropic, ollama, endpoints, documentation, cline, continue, cursor
+---
+
+Once Model Runner is enabled, new API endpoints are available. You can use
+these endpoints to interact with a model programmatically. Docker Model Runner
+provides compatibility with OpenAI, Anthropic, and Ollama API formats.
+
+## Determine the base URL
+
+The base URL to interact with the endpoints depends on how you run Docker and
+which API format you're using.
+
+{{< tabs >}}
+{{< tab name="Docker Desktop">}}
+
+| Access from | Base URL |
+|-------------|----------|
+| Containers | `http://model-runner.docker.internal` |
+| Host processes (TCP) | `http://localhost:12434` |
+
+> [!NOTE]
+> TCP host access must be enabled. See [Enable Docker Model Runner](get-started.md#enable-docker-model-runner-in-docker-desktop).
+
+{{< /tab >}}
+{{< tab name="Docker Engine">}}
+
+| Access from | Base URL |
+|-------------|----------|
+| Containers | `http://172.17.0.1:12434` |
+| Host processes | `http://localhost:12434` |
+
+> [!NOTE]
+> The `172.17.0.1` interface may not be available by default to containers
+  within a Compose project.
+> In this case, add an `extra_hosts` directive to your Compose service YAML:
+>
+> ```yaml
+> extra_hosts:
+>   - "model-runner.docker.internal:host-gateway"
+> ```
+> Then you can access the Docker Model Runner APIs at `http://model-runner.docker.internal:12434/`
+
+{{< /tab >}}
+{{</tabs >}}
+
+### Base URLs for third-party tools
+
+When configuring third-party tools that expect OpenAI-compatible APIs, use these base URLs:
+
+| Tool type | Base URL format |
+|-----------|-----------------|
+| OpenAI SDK / clients | `http://localhost:12434/engines/v1` |
+| Anthropic SDK / clients | `http://localhost:12434` |
+| Ollama-compatible clients | `http://localhost:12434` |
+
+See [IDE and tool integrations](ide-integrations.md) for specific configuration examples.
+
+## Supported APIs
+
+Docker Model Runner supports multiple API formats:
+
+| API | Description | Use case |
+|-----|-------------|----------|
+| [OpenAI API](#openai-compatible-api) | OpenAI-compatible chat completions, embeddings | Most AI frameworks and tools |
+| [Anthropic API](#anthropic-compatible-api) | Anthropic-compatible messages endpoint | Tools built for Claude |
+| [Ollama API](#ollama-compatible-api) | Ollama-compatible endpoints | Tools built for Ollama |
+| [Image Generation API](#image-generation-api-diffusers) | Diffusers-based image generation | Generating images from text prompts |
+| [DMR API](#dmr-native-endpoints) | Native Docker Model Runner endpoints | Model management |
+
+## OpenAI-compatible API
+
+DMR implements the OpenAI API specification for maximum compatibility with existing tools and frameworks.
+
+### Endpoints
+
+| Endpoint | Method | Description |
+|----------|--------|-------------|
+| `/engines/v1/models` | GET | [List models](https://platform.openai.com/docs/api-reference/models/list) |
+| `/engines/v1/models/{namespace}/{name}` | GET | [Retrieve model](https://platform.openai.com/docs/api-reference/models/retrieve) |
+| `/engines/v1/chat/completions` | POST | [Create chat completion](https://platform.openai.com/docs/api-reference/chat/create) |
+| `/engines/v1/completions` | POST | [Create completion](https://platform.openai.com/docs/api-reference/completions/create) |
+| `/engines/v1/embeddings` | POST | [Create embeddings](https://platform.openai.com/docs/api-reference/embeddings/create) |
+
+> [!NOTE]
+> You can optionally include the engine name in the path: `/engines/llama.cpp/v1/chat/completions`.
+> This is useful when running multiple inference engines.
+
+### Model name format
+
+When specifying a model in API requests, use the full model identifier including the namespace:
+
+```json
+{
+  "model": "ai/smollm2",
+  "messages": [...]
+}
+```
+
+Common model name formats:
+- Docker Hub models: `ai/smollm2`, `ai/llama3.2`, `ai/qwen2.5-coder`
+- Tagged versions: `ai/smollm2:360M-Q4_K_M`
+- Custom models: `myorg/mymodel`
+
+### Supported parameters
+
+The following OpenAI API parameters are supported:
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `model` | string | Required. The model identifier. |
+| `messages` | array | Required for chat completions. The conversation history. |
+| `prompt` | string | Required for completions. The prompt text. |
+| `max_tokens` | integer | Maximum tokens to generate. |
+| `temperature` | float | Sampling temperature (0.0-2.0). |
+| `top_p` | float | Nucleus sampling parameter (0.0-1.0). |
+| `stream` | Boolean | Enable streaming responses. |
+| `stop` | string/array | Stop sequences. |
+| `presence_penalty` | float | Presence penalty (-2.0 to 2.0). |
+| `frequency_penalty` | float | Frequency penalty (-2.0 to 2.0). |
+
+### Limitations and differences from OpenAI
+
+Be aware of these differences when using DMR's OpenAI-compatible API:
+
+| Feature | DMR behavior |
+|---------|--------------|
+| API key | Not required. DMR ignores the `Authorization` header. |
+| Function calling | Supported with llama.cpp for compatible models. |
+| Vision | Supported for multi-modal models (e.g., LLaVA). |
+| JSON mode | Supported via `response_format: {"type": "json_object"}`. |
+| Logprobs | Supported. |
+| Token counting | Uses the model's native token encoder, which may differ from OpenAI's. |
+
+## Anthropic-compatible API
+
+DMR provides [Anthropic Messages API](https://platform.claude.com/docs/en/api/messages) compatibility for tools and frameworks built for Claude.
+
+### Endpoints
+
+| Endpoint | Method | Description |
+|----------|--------|-------------|
+| `/anthropic/v1/messages` | POST | [Create a message](https://platform.claude.com/docs/en/api/messages/create) |
+| `/anthropic/v1/messages/count_tokens` | POST | [Count tokens](https://docs.anthropic.com/en/api/messages-count-tokens) |
+
+### Supported parameters
+
+The following Anthropic API parameters are supported:
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `model` | string | Required. The model identifier. |
+| `messages` | array | Required. The conversation messages. |
+| `max_tokens` | integer | Maximum tokens to generate. |
+| `temperature` | float | Sampling temperature (0.0-1.0). |
+| `top_p` | float | Nucleus sampling parameter. |
+| `top_k` | integer | Top-k sampling parameter. |
+| `stream` | Boolean | Enable streaming responses. |
+| `stop_sequences` | array | Custom stop sequences. |
+| `system` | string | System prompt. |
+
+### Example: Chat with Anthropic API
+
+```bash
+curl http://localhost:12434/v1/messages \
+  -H "Content-Type: application/json" \
+  -d '{
+    "model": "ai/smollm2",
+    "max_tokens": 1024,
+    "messages": [
+      {"role": "user", "content": "Hello!"}
+    ]
+  }'
+```
+
+### Example: Streaming response
+
+```bash
+curl http://localhost:12434/v1/messages \
+  -H "Content-Type: application/json" \
+  -d '{
+    "model": "ai/smollm2",
+    "max_tokens": 1024,
+    "stream": true,
+    "messages": [
+      {"role": "user", "content": "Count from 1 to 10"}
+    ]
+  }'
+```
+
+## Ollama-compatible API
+
+DMR also provides Ollama-compatible endpoints for tools and frameworks built for Ollama.
+
+### Endpoints
+
+| Endpoint | Method | Description |
+|----------|--------|-------------|
+| `/api/tags` | GET | List available models |
+| `/api/show` | POST | Show model information |
+| `/api/chat` | POST | Generate chat completion |
+| `/api/generate` | POST | Generate completion |
+| `/api/embeddings` | POST | Generate embeddings |
+
+### Example: Chat with Ollama API
+
+```bash
+curl http://localhost:12434/api/chat \
+  -H "Content-Type: application/json" \
+  -d '{
+    "model": "ai/smollm2",
+    "messages": [
+      {"role": "user", "content": "Hello!"}
+    ]
+  }'
+```
+
+### Example: List models
+
+```bash
+curl http://localhost:12434/api/tags
+```
+
+## Image generation API (Diffusers)
+
+DMR supports image generation through the Diffusers backend, enabling you to generate
+images from text prompts using models like Stable Diffusion.
+
+> [!NOTE]
+> The Diffusers backend requires an NVIDIA GPU with CUDA support and is only
+> available on Linux (x86_64 and ARM64). See [Inference engines](inference-engines.md#diffusers)
+> for setup instructions.
+
+### Endpoint
+
+| Endpoint | Method | Description |
+|----------|--------|-------------|
+| `/engines/diffusers/v1/images/generations` | POST | Generate an image from a text prompt |
+
+### Supported parameters
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `model` | string | Required. The model identifier (e.g., `stable-diffusion:Q4`). |
+| `prompt` | string | Required. The text description of the image to generate. |
+| `size` | string | Image dimensions in `WIDTHxHEIGHT` format (e.g., `512x512`). |
+
+### Response format
+
+The API returns a JSON response with the generated image encoded in base64:
+
+```json
+{
+  "data": [
+    {
+      "b64_json": "<base64-encoded-image-data>"
+    }
+  ]
+}
+```
+
+### Example: Generate an image
+
+```bash
+curl -s -X POST http://localhost:12434/engines/diffusers/v1/images/generations \
+  -H "Content-Type: application/json" \
+  -d '{
+    "model": "stable-diffusion:Q4",
+    "prompt": "A picture of a nice cat",
+    "size": "512x512"
+  }' | jq -r '.data[0].b64_json' | base64 -d > image.png
+```
+
+This command:
+1. Sends a POST request to the Diffusers image generation endpoint
+2. Specifies the model, prompt, and output image size
+3. Extracts the base64-encoded image from the response using `jq`
+4. Decodes the base64 data and saves it as `image.png`
+
+
+## DMR native endpoints
+
+These endpoints are specific to Docker Model Runner for model management:
+
+| Endpoint | Method | Description |
+|----------|--------|-------------|
+| `/models/create` | POST | Pull/create a model |
+| `/models` | GET | List local models |
+| `/models/{namespace}/{name}` | GET | Get model details |
+| `/models/{namespace}/{name}` | DELETE | Delete a local model |
+
+## REST API examples
+
+### Request from within a container
+
+To call the `chat/completions` OpenAI endpoint from within another container using `curl`:
+
+```bash
+#!/bin/sh
+
+curl http://model-runner.docker.internal/engines/v1/chat/completions \
+    -H "Content-Type: application/json" \
+    -d '{
+        "model": "ai/smollm2",
+        "messages": [
+            {
+                "role": "system",
+                "content": "You are a helpful assistant."
+            },
+            {
+                "role": "user",
+                "content": "Please write 500 words about the fall of Rome."
+            }
+        ]
+    }'
+
+```
+
+### Request from the host using TCP
+
+To call the `chat/completions` OpenAI endpoint from the host via TCP:
+
+1. Enable the host-side TCP support from the Docker Desktop GUI, or via the [Docker Desktop CLI](/manuals/desktop/features/desktop-cli.md).
+   For example: `docker desktop enable model-runner --tcp <port>`.
+
+   If you are running on Windows, also enable GPU-backed inference.
+   See [Enable Docker Model Runner](get-started.md#enable-docker-model-runner-in-docker-desktop).
+
+1. Interact with it as documented in the previous section using `localhost` and the correct port.
+
+```bash
+#!/bin/sh
+
+curl http://localhost:12434/engines/v1/chat/completions \
+  -H "Content-Type: application/json" \
+  -d '{
+      "model": "ai/smollm2",
+      "messages": [
+          {
+              "role": "system",
+              "content": "You are a helpful assistant."
+          },
+          {
+              "role": "user",
+              "content": "Please write 500 words about the fall of Rome."
+          }
+      ]
+  }'
+```
+
+### Request from the host using a Unix socket
+
+To call the `chat/completions` OpenAI endpoint through the Docker socket from the host using `curl`:
+
+```bash
+#!/bin/sh
+
+curl --unix-socket $HOME/.docker/run/docker.sock \
+    localhost/exp/vDD4.40/engines/v1/chat/completions \
+    -H "Content-Type: application/json" \
+    -d '{
+        "model": "ai/smollm2",
+        "messages": [
+            {
+                "role": "system",
+                "content": "You are a helpful assistant."
+            },
+            {
+                "role": "user",
+                "content": "Please write 500 words about the fall of Rome."
+            }
+        ]
+    }'
+```
+
+### Streaming responses
+
+To receive streaming responses, set `stream: true`:
+
+```bash
+curl http://localhost:12434/engines/v1/chat/completions \
+  -H "Content-Type: application/json" \
+  -d '{
+      "model": "ai/smollm2",
+      "stream": true,
+      "messages": [
+          {"role": "user", "content": "Count from 1 to 10"}
+      ]
+  }'
+```
+
+## Using with OpenAI SDKs
+
+### Python
+
+```python
+from openai import OpenAI
+
+client = OpenAI(
+    base_url="http://localhost:12434/engines/v1",
+    api_key="not-needed"  # DMR doesn't require an API key
+)
+
+response = client.chat.completions.create(
+    model="ai/smollm2",
+    messages=[
+        {"role": "user", "content": "Hello!"}
+    ]
+)
+
+print(response.choices[0].message.content)
+```
+
+### Node.js
+
+```javascript
+import OpenAI from 'openai';
+
+const client = new OpenAI({
+  baseURL: 'http://localhost:12434/engines/v1',
+  apiKey: 'not-needed',
+});
+
+const response = await client.chat.completions.create({
+  model: 'ai/smollm2',
+  messages: [{ role: 'user', content: 'Hello!' }],
+});
+
+console.log(response.choices[0].message.content);
+```
+
+## What's next
+
+- [IDE and tool integrations](ide-integrations.md) - Configure Cline, Continue, Cursor, and other tools
+- [Configuration options](configuration.md) - Adjust context size and runtime parameters
+- [Inference engines](inference-engines.md) - Learn about llama.cpp, vLLM, and Diffusers options
diff --git a/content/manuals/ai/model-runner/configuration.md b/content/manuals/ai/model-runner/configuration.md
new file mode 100644
index 000000000000..89934e97a7ca
--- /dev/null
+++ b/content/manuals/ai/model-runner/configuration.md
@@ -0,0 +1,305 @@
+---
+title: Configuration options
+description: Configure context size, runtime parameters, and model behavior in Docker Model Runner.
+weight: 35
+keywords: Docker, ai, model runner, configuration, context size, context length, tokens, llama.cpp, parameters
+---
+
+Docker Model Runner provides several configuration options to tune model behavior,
+memory usage, and inference performance. This guide covers the key settings and
+how to apply them.
+
+## Context size (context length)
+
+The context size determines the maximum number of tokens a model can process in
+a single request, including both the input prompt and generated output. This is
+one of the most important settings affecting memory usage and model capabilities.
+
+### Default context size
+
+By default, Docker Model Runner uses a context size that balances capability with
+resource efficiency:
+
+| Engine | Default behavior |
+|--------|------------------|
+| llama.cpp | 4096 tokens |
+| vLLM | Uses the model's maximum trained context size |
+
+> [!NOTE]
+> The actual default varies by model. Most models support between 2,048 and 8,192
+> tokens by default. Some newer models support 32K, 128K, or even larger contexts.
+
+### Configure context size
+
+You can adjust context size per model using the `docker model configure` command:
+
+```console
+$ docker model configure --context-size 8192 ai/qwen2.5-coder
+```
+
+Or in a Compose file:
+
+```yaml
+models:
+  llm:
+    model: ai/qwen2.5-coder
+    context_size: 8192
+```
+
+### Context size guidelines
+
+| Context size | Typical use case | Memory impact |
+|--------------|------------------|---------------|
+| 2,048 | Simple queries, short code snippets | Low |
+| 4,096 | Standard conversations, medium code files | Moderate |
+| 8,192 | Long conversations, larger code files | Higher |
+| 16,384+ | Extended documents, multi-file context | High |
+
+> [!IMPORTANT]
+> Larger context sizes require more memory (RAM/VRAM). If you experience out-of-memory
+> errors, reduce the context size. As a rough guide, each additional 1,000 tokens
+> requires approximately 100-500 MB of additional memory, depending on the model size.
+
+### Check a model's maximum context
+
+To see a model's configuration including context size:
+
+```console
+$ docker model inspect ai/qwen2.5-coder
+```
+
+> [!NOTE]
+> The `docker model inspect` command shows the model's maximum supported context length
+> (e.g., `gemma3.context_length`), not the configured context size. The configured context
+> size is what you set with `docker model configure --context-size` and represents the
+> actual limit used during inference, which should be less than or equal to the model's
+> maximum supported context length.
+
+## Runtime flags
+
+Runtime flags let you pass parameters directly to the underlying inference engine.
+This provides fine-grained control over model behavior.
+
+### Using runtime flags
+
+Runtime flags can be provided through multiple mechanisms:
+
+#### Using Docker Compose
+
+In a Compose file:
+
+```yaml
+models:
+  llm:
+    model: ai/qwen2.5-coder
+    context_size: 4096
+    runtime_flags:
+      - "--temp"
+      - "0.7"
+      - "--top-p"
+      - "0.9"
+```
+
+#### Using Command Line
+
+With the `docker model configure` command:
+
+```console
+$ docker model configure ai/qwen2.5-coder -- --temp 0.7 --top-p 0.9
+```
+
+### Common llama.cpp parameters
+
+These are the most commonly used llama.cpp parameters. You don't need to look up
+the llama.cpp documentation for typical use cases.
+
+#### Sampling parameters
+
+| Flag | Description | Default | Range |
+|------|-------------|---------|-------|
+| `--temp` | Temperature for sampling. Lower = more deterministic, higher = more creative | 0.8 | 0.0-2.0 |
+| `--top-k` | Limit sampling to top K tokens. Lower = more focused | 40 | 1-100 |
+| `--top-p` | Nucleus sampling threshold. Lower = more focused | 0.9 | 0.0-1.0 |
+| `--min-p` | Minimum probability threshold | 0.05 | 0.0-1.0 |
+| `--repeat-penalty` | Penalty for repeating tokens | 1.1 | 1.0-2.0 |
+
+**Example: Deterministic output (for code generation)**
+
+```yaml
+runtime_flags:
+  - "--temp"
+  - "0"
+  - "--top-k"
+  - "1"
+```
+
+**Example: Creative output (for storytelling)**
+
+```yaml
+runtime_flags:
+  - "--temp"
+  - "1.2"
+  - "--top-p"
+  - "0.95"
+```
+
+#### Performance parameters
+
+| Flag | Description | Default | Notes |
+|------|-------------|---------|-------|
+| `--threads` | CPU threads for generation | Auto | Set to number of performance cores |
+| `--threads-batch` | CPU threads for batch processing | Auto | Usually same as `--threads` |
+| `--batch-size` | Batch size for prompt processing | 512 | Higher = faster prompt processing |
+| `--mlock` | Lock model in memory | Off | Prevents swapping, requires sufficient RAM |
+| `--no-mmap` | Disable memory mapping | Off | May improve performance on some systems |
+
+**Example: Optimized for multi-core CPU**
+
+```yaml
+runtime_flags:
+  - "--threads"
+  - "8"
+  - "--batch-size"
+  - "1024"
+```
+
+#### GPU parameters
+
+| Flag | Description | Default | Notes |
+|------|-------------|---------|-------|
+| `--n-gpu-layers` | Layers to offload to GPU | All (if GPU available) | Reduce if running out of VRAM |
+| `--main-gpu` | GPU to use for computation | 0 | For multi-GPU systems |
+| `--split-mode` | How to split across GPUs | layer | Options: `none`, `layer`, `row` |
+
+**Example: Partial GPU offload (limited VRAM)**
+
+```yaml
+runtime_flags:
+  - "--n-gpu-layers"
+  - "20"
+```
+
+#### Advanced parameters
+
+| Flag | Description | Default |
+|------|-------------|---------|
+| `--rope-scaling` | RoPE scaling method | Auto |
+| `--rope-freq-base` | RoPE base frequency | Model default |
+| `--rope-freq-scale` | RoPE frequency scale | Model default |
+| `--no-prefill-assistant` | Disable assistant pre-fill | Off |
+| `--reasoning-budget` | Token budget for reasoning models | 0 (disabled) |
+
+### vLLM parameters
+
+When using the vLLM backend, different parameters are available.
+
+Use `--hf_overrides` to pass HuggingFace model config overrides as JSON:
+
+```console
+$ docker model configure --hf_overrides '{"rope_scaling": {"type": "dynamic", "factor": 2.0}}' ai/model-vllm
+```
+
+## Configuration presets
+
+Here are complete configuration examples for common use cases.
+
+### Code completion (fast, deterministic)
+
+```yaml
+models:
+  coder:
+    model: ai/qwen2.5-coder
+    context_size: 4096
+    runtime_flags:
+      - "--temp"
+      - "0.1"
+      - "--top-k"
+      - "1"
+      - "--batch-size"
+      - "1024"
+```
+
+### Chat assistant (balanced)
+
+```yaml
+models:
+  assistant:
+    model: ai/llama3.2
+    context_size: 8192
+    runtime_flags:
+      - "--temp"
+      - "0.7"
+      - "--top-p"
+      - "0.9"
+      - "--repeat-penalty"
+      - "1.1"
+```
+
+### Creative writing (high temperature)
+
+```yaml
+models:
+  writer:
+    model: ai/llama3.2
+    context_size: 8192
+    runtime_flags:
+      - "--temp"
+      - "1.2"
+      - "--top-p"
+      - "0.95"
+      - "--repeat-penalty"
+      - "1.0"
+```
+
+### Long document analysis (large context)
+
+```yaml
+models:
+  analyzer:
+    model: ai/qwen2.5-coder:14B
+    context_size: 32768
+    runtime_flags:
+      - "--mlock"
+      - "--batch-size"
+      - "2048"
+```
+
+### Low memory system
+
+```yaml
+models:
+  efficient:
+    model: ai/smollm2:360M-Q4_K_M
+    context_size: 2048
+    runtime_flags:
+      - "--threads"
+      - "4"
+```
+
+## Environment-based configuration
+
+You can also configure models via environment variables in containers:
+
+| Variable | Description |
+|----------|-------------|
+| `LLM_URL` | Auto-injected URL of the model endpoint |
+| `LLM_MODEL` | Auto-injected model identifier |
+
+See [Models and Compose](/manuals/ai/compose/models-and-compose.md) for details on how these are populated.
+
+## Reset configuration
+
+Configuration set via `docker model configure` persists until the model is removed.
+To reset configuration:
+
+```console
+$ docker model configure --context-size -1 ai/qwen2.5-coder
+```
+
+Using `-1` resets to the default value.
+
+## What's next
+
+- [Inference engines](inference-engines.md) - Learn about llama.cpp and vLLM
+- [API reference](api-reference.md) - API parameters for per-request configuration
+- [Models and Compose](/manuals/ai/compose/models-and-compose.md) - Configure models in Compose applications
diff --git a/content/manuals/ai/model-runner/examples.md b/content/manuals/ai/model-runner/examples.md
new file mode 100644
index 000000000000..1570b07285f0
--- /dev/null
+++ b/content/manuals/ai/model-runner/examples.md
@@ -0,0 +1,192 @@
+---
+title: DMR examples
+description: Example projects and CI/CD workflows for Docker Model Runner.
+weight: 40
+keywords: Docker, ai, model runner, examples, github actions, genai, sample project
+---
+
+See some examples of complete workflows using Docker Model Runner.
+
+## Sample project
+
+You can now start building your generative AI application powered by Docker
+Model Runner.
+
+If you want to try an existing GenAI application, follow these steps:
+
+1. Set up the sample app. Clone and run the following repository:
+
+   ```console
+   $ git clone https://github.com/docker/hello-genai.git
+   ```
+
+1. In your terminal, go to the `hello-genai` directory.
+
+1. Run `run.sh` to pull the chosen model and run the app.
+
+1. Open your app in the browser at the addresses specified in the repository
+   [README](https://github.com/docker/hello-genai).
+
+You see the GenAI app's interface where you can start typing your prompts.
+
+You can now interact with your own GenAI app, powered by a local model. Try a
+few prompts and notice how fast the responses are — all running on your machine
+with Docker.
+
+## Use Model Runner in GitHub Actions
+
+Here is an example of how to use Model Runner as part of a GitHub workflow.
+The example installs Model Runner, tests the installation, pulls and runs a
+model, interacts with the model via the API, and deletes the model.
+
+```yaml {title="dmr-run.yml", collapse=true}
+name: Docker Model Runner Example Workflow
+
+permissions:
+  contents: read
+
+on:
+  workflow_dispatch:
+    inputs:
+      test_model:
+        description: 'Model to test with (default: ai/smollm2:360M-Q4_K_M)'
+        required: false
+        type: string
+        default: 'ai/smollm2:360M-Q4_K_M'
+
+jobs:
+  dmr-test:
+    runs-on: ubuntu-latest
+    timeout-minutes: 30
+
+    steps:
+      - name: Set up Docker
+        uses: docker/setup-docker-action@{{% param "setup_docker_action_version" %}}
+
+      - name: Install docker-model-plugin
+        run: |
+          echo "Installing docker-model-plugin..."
+          # Add Docker's official GPG key:
+          sudo apt-get update
+          sudo apt-get install ca-certificates curl
+          sudo install -m 0755 -d /etc/apt/keyrings
+          sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
+          sudo chmod a+r /etc/apt/keyrings/docker.asc
+          
+          # Add the repository to Apt sources:
+          echo \
+          "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
+          $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
+          sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
+          sudo apt-get update
+          sudo apt-get install -y docker-model-plugin
+          
+          echo "Installation completed successfully"
+
+      - name: Test docker model version
+        run: |
+          echo "Testing docker model version command..."
+          sudo docker model version
+          
+          # Verify the command returns successfully
+          if [ $? -eq 0 ]; then
+            echo "✅ docker model version command works correctly"
+          else
+            echo "❌ docker model version command failed"
+            exit 1
+          fi
+
+      - name: Pull the provided model and run it
+        run: |
+          MODEL="${{ github.event.inputs.test_model || 'ai/smollm2:360M-Q4_K_M' }}"
+          echo "Testing with model: $MODEL"
+          
+          # Test model pull
+          echo "Pulling model..."
+          sudo docker model pull "$MODEL"
+          
+          if [ $? -eq 0 ]; then
+            echo "✅ Model pull successful"
+          else
+            echo "❌ Model pull failed"
+            exit 1
+          fi
+                  
+          # Test basic model run (with timeout to avoid hanging)
+          echo "Testing docker model run..."
+          timeout 60s sudo docker model run "$MODEL" "Give me a fact about whales." || {
+            exit_code=$?
+            if [ $exit_code -eq 124 ]; then
+              echo "✅ Model run test completed (timed out as expected for non-interactive test)"
+            else
+              echo "❌ Model run failed with exit code: $exit_code"
+              exit 1
+            fi
+          }
+
+      - name: Test API endpoint
+        run: |
+          MODEL="${{ github.event.inputs.test_model || 'ai/smollm2:360M-Q4_K_M' }}"
+          echo "Testing API endpoint with model: $MODEL"
+                  
+          # Test API call with curl
+          echo "Testing API call..."
+          RESPONSE=$(curl -s http://localhost:12434/engines/llama.cpp/v1/chat/completions \
+            -H "Content-Type: application/json" \
+            -d "{
+                \"model\": \"$MODEL\",
+                \"messages\": [
+                    {
+                        \"role\": \"user\",
+                        \"content\": \"Say hello\"
+                    }
+                ],
+                \"top_k\": 1,
+                \"temperature\": 0
+            }")
+          
+          if [ $? -eq 0 ]; then
+            echo "✅ API call successful"
+            echo "Response received: $RESPONSE"
+            
+            # Check if response contains "hello" (case-insensitive)
+            if echo "$RESPONSE" | grep -qi "hello"; then
+              echo "✅ Response contains 'hello' (case-insensitive)"
+            else
+              echo "❌ Response does not contain 'hello'"
+              echo "Full response: $RESPONSE"
+              exit 1
+            fi
+          else
+            echo "❌ API call failed"
+            exit 1
+          fi
+
+      - name: Test model cleanup
+        run: |
+          MODEL="${{ github.event.inputs.test_model || 'ai/smollm2:360M-Q4_K_M' }}"
+          
+          echo "Cleaning up test model..."
+          sudo docker model rm "$MODEL" || echo "Model removal failed or model not found"
+          
+          # Verify model was removed
+          echo "Verifying model cleanup..."
+          sudo docker model ls
+          
+          echo "✅ Model cleanup completed"
+
+      - name: Report success
+        if: success()
+        run: |
+          echo "🎉 Docker Model Runner daily health check completed successfully!"
+          echo "All tests passed:"
+          echo "  ✅ docker-model-plugin installation successful"
+          echo "  ✅ docker model version command working"
+          echo "  ✅ Model pull and run operations successful"
+          echo "  ✅ API endpoint operations successful"
+          echo "  ✅ Cleanup operations successful"
+```
+
+## Related pages
+
+- [Models and Compose](../compose/models-and-compose.md)
diff --git a/content/manuals/ai/model-runner/get-started.md b/content/manuals/ai/model-runner/get-started.md
new file mode 100644
index 000000000000..02ba0e71f69b
--- /dev/null
+++ b/content/manuals/ai/model-runner/get-started.md
@@ -0,0 +1,223 @@
+---
+title: Get started with DMR
+description: How to install, enable, and use Docker Model Runner to manage and run AI models.
+weight: 10
+keywords: Docker, ai, model runner, setup, installation, getting started
+---
+
+Docker Model Runner (DMR) lets you run and manage AI models locally using Docker. This page shows you how to enable DMR, pull and run a model, configure model settings, and publish custom models.
+
+## Enable Docker Model Runner
+
+You can enable DMR using Docker Desktop or Docker Engine. Follow the instructions below based on your setup.
+
+### Docker Desktop
+
+1. In the settings view, go to the **AI** tab.
+1. Select the **Enable Docker Model Runner** setting.
+1. If you use Windows with a supported NVIDIA GPU, you also see and can select
+   **Enable GPU-backed inference**.
+1. Optional: To enable TCP support, select **Enable host-side TCP support**.
+   1. In the **Port** field, type the port you want to use.
+   1. If you interact with Model Runner from a local frontend web app, in
+      **CORS Allows Origins**, select the origins that Model Runner should
+      accept requests from. An origin is the URL where your web app runs, for
+      example `http://localhost:3131`.
+
+You can now use the `docker model` command in the CLI and view and interact
+with your local models in the **Models** tab in the Docker Desktop Dashboard.
+
+### Docker Engine
+
+1. Ensure you have installed [Docker Engine](/engine/install/).
+1. Docker Model Runner is available as a package. To install it, run:
+
+   {{< tabs >}}
+   {{< tab name="Ubuntu/Debian">}}
+
+   ```bash
+   $ sudo apt-get update
+   $ sudo apt-get install docker-model-plugin
+   ```
+
+   {{< /tab >}}
+   {{< tab name="RPM-base distributions">}}
+
+   ```bash
+   $ sudo dnf update
+   $ sudo dnf install docker-model-plugin
+   ```
+
+   {{< /tab >}}
+   {{< /tabs >}}
+
+1. Test the installation:
+
+   ```bash
+   $ docker model version
+   $ docker model run ai/smollm2
+   ```
+
+> [!NOTE]
+> TCP support is enabled by default for Docker Engine on port `12434`.
+
+### Update DMR in Docker Engine
+
+To update Docker Model Runner in Docker Engine, uninstall it with
+[`docker model uninstall-runner`](/reference/cli/docker/model/uninstall-runner/)
+then reinstall it:
+
+```bash
+docker model uninstall-runner --images && docker model install-runner
+```
+> [!NOTE]
+> With the above command, local models are preserved and only the Docker Model Runner images are removed.
+> To also delete the local models during the upgrade, add the `--models` option to the `uninstall-runner` command.
+
+## Pull a model
+
+Models are cached locally.
+
+> [!NOTE]
+>
+> When you use the Docker CLI, you can also pull models directly from
+> [HuggingFace](https://huggingface.co/).
+
+{{< tabs group="release" >}}
+{{< tab name="From Docker Desktop">}}
+
+1. Select **Models** and select the **Docker Hub** tab.
+1. Find the model you want and select **Pull**.
+
+![Screenshot showing the Docker Hub view.](./images/dmr-catalog.png)
+
+{{< /tab >}}
+{{< tab name="From the Docker CLI">}}
+
+Use the [`docker model pull` command](/reference/cli/docker/model/pull/).
+For example:
+
+```bash {title="Pulling from Docker Hub"}
+docker model pull ai/smollm2:360M-Q4_K_M
+```
+
+```bash {title="Pulling from HuggingFace"}
+docker model pull hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Run a model
+
+{{< tabs group="release" >}}
+{{< tab name="From Docker Desktop">}}
+
+1. Select **Models** and select the **Local** tab.
+1. Select the play button. The interactive chat screen opens.
+
+![Screenshot showing the Local view.](./images/dmr-run.png)
+
+{{< /tab >}}
+{{< tab name="From the Docker CLI" >}}
+
+Use the [`docker model run` command](/reference/cli/docker/model/run/).
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Configure a model
+
+You can configure a model, such as its maximum token limit and more,
+use Docker Compose.
+See [Models and Compose - Model configuration options](../compose/models-and-compose.md#model-configuration-options).
+
+## Publish a model
+
+> [!NOTE]
+>
+> This works for any Container Registry supporting OCI Artifacts, not only
+> Docker Hub.
+
+You can tag existing models with a new name and publish them under a different
+namespace and repository:
+
+```bash
+# Tag a pulled model under a new name
+$ docker model tag ai/smollm2 myorg/smollm2
+
+# Push it to Docker Hub
+$ docker model push myorg/smollm2
+```
+
+For more details, see the [`docker model tag`](/reference/cli/docker/model/tag)
+and [`docker model push`](/reference/cli/docker/model/push) command
+documentation.
+
+You can also package a model file in GGUF format as an OCI Artifact and publish
+it to Docker Hub.
+
+```bash
+# Download a model file in GGUF format, for example from HuggingFace
+$ curl -L -o model.gguf https://huggingface.co/TheBloke/Mistral-7B-v0.1-GGUF/resolve/main/mistral-7b-v0.1.Q4_K_M.gguf
+
+# Package it as OCI Artifact and push it to Docker Hub
+$ docker model package --gguf "$(pwd)/model.gguf" --push myorg/mistral-7b-v0.1:Q4_K_M
+```
+
+For more details, see the
+[`docker model package`](/reference/cli/docker/model/package/) command
+documentation.
+
+## Troubleshooting
+
+### Display the logs
+
+To troubleshoot issues, display the logs:
+
+{{< tabs group="release" >}}
+{{< tab name="From Docker Desktop">}}
+
+Select **Models** and select the **Logs** tab.
+
+![Screenshot showing the Models view.](./images/dmr-logs.png)
+
+{{< /tab >}}
+{{< tab name="From the Docker CLI">}}
+
+Use the [`docker model logs` command](/reference/cli/docker/model/logs/).
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Inspect requests and responses
+
+Inspecting requests and responses helps you diagnose model-related issues.
+For example, you can evaluate context usage to verify you stay within the model's context
+window or display the full body of a request to control the parameters you are passing to your models
+when developing with a framework.
+
+In Docker Desktop, to inspect the requests and responses for each model:
+
+1. Select **Models** and select the **Requests** tab. This view displays all the requests to all models:
+   - The time the request was sent.
+   - The model name and version
+   - The prompt/request
+   - The context usage
+   - The time it took for the response to be generated.
+1. Select one of the requests to display further details:
+   - In the **Overview** tab, view the token usage, response metadata and generation speed, and the actual prompt and response.
+   - In the **Request**  and **Response** tabs, view the full JSON payload of the request and the response.
+
+> [!NOTE]
+> You can also display the requests for a specific model when you select a model and then select the **Requests** tab.
+
+## Related pages
+
+- [API reference](./api-reference.md) - OpenAI and Ollama-compatible API documentation
+- [Configuration options](./configuration.md) - Context size and runtime parameters
+- [Inference engines](./inference-engines.md) - llama.cpp and vLLM details
+- [IDE integrations](./ide-integrations.md) - Connect Cline, Continue, Cursor, and more
+- [Open WebUI integration](./openwebui-integration.md) - Set up a web chat interface
+- [Models and Compose](../compose/models-and-compose.md) - Use models in Compose applications
+- [Docker Model Runner CLI reference](/reference/cli/docker/model) - Complete CLI documentation
\ No newline at end of file
diff --git a/content/manuals/ai/model-runner/ide-integrations.md b/content/manuals/ai/model-runner/ide-integrations.md
new file mode 100644
index 000000000000..2d6e477c59b9
--- /dev/null
+++ b/content/manuals/ai/model-runner/ide-integrations.md
@@ -0,0 +1,373 @@
+---
+title: IDE and tool integrations
+description: Configure popular AI coding assistants and tools to use Docker Model Runner as their backend.
+weight: 40
+keywords: Docker, ai, model runner, cline, continue, cursor, vscode, ide, integration, openai, ollama, claude, anthropic, claude-code
+---
+
+Docker Model Runner can serve as a local backend for popular AI coding assistants
+and development tools. This guide shows how to configure common tools to use
+models running in DMR.
+
+## Prerequisites
+
+Before configuring any tool:
+
+1. [Enable Docker Model Runner](get-started.md#enable-docker-model-runner) in Docker Desktop or Docker Engine.
+2. Enable TCP host access:
+   - Docker Desktop: Enable **host-side TCP support** in Settings > AI, or run:
+     ```console
+     $ docker desktop enable model-runner --tcp 12434
+     ```
+   - Docker Engine: TCP is enabled by default on port 12434.
+3. Pull a model:
+   ```console
+   $ docker model pull ai/qwen2.5-coder
+   ```
+
+> [!TIP]
+> 
+> The default context size for many models (such as `gpt-oss`) is 4,096 tokens, which is limiting for coding tasks.
+> You can repackage it with a larger context window:
+>
+> ```console
+> $ docker model pull gpt-oss
+> $ docker model package --from ai/gpt-oss --context-size 32000 gpt-oss:32k
+> ```
+> Alternatively, models like ai/glm-4.7-flash, ai/qwen2.5-coder, and ai/devstral-small-2
+> come with 128K context by default and work without repackaging.
+
+## Cline (VS Code)
+
+[Cline](https://github.com/cline/cline) is an AI coding assistant for VS Code.
+
+### Configuration
+
+1. Open VS Code and go to the Cline extension settings.
+2. Select **OpenAI Compatible** as the API provider.
+3. Configure the following settings:
+
+| Setting | Value |
+|---------|-------|
+| Base URL | `http://localhost:12434/engines/v1` |
+| API Key | `not-needed` (or any placeholder value) |
+| Model ID | `ai/qwen2.5-coder` (or your preferred model) |
+
+> [!IMPORTANT]
+> The base URL must include `/engines/v1` at the end. Do not include a trailing slash.
+
+### Troubleshooting Cline
+
+If Cline fails to connect:
+
+1. Verify DMR is running:
+   ```console
+   $ docker model status
+   ```
+
+2. Test the endpoint directly:
+   ```console
+   $ curl http://localhost:12434/engines/v1/models
+   ```
+
+3. Check that CORS is configured if running a web-based version:
+   - In Docker Desktop Settings > AI, add your origin to **CORS Allowed Origins**
+
+## Continue (VS Code / JetBrains)
+
+[Continue](https://continue.dev) is an open-source AI code assistant that works with VS Code and JetBrains IDEs.
+
+### Configuration
+
+Edit your Continue configuration file (`~/.continue/config.json`):
+
+```json
+{
+  "models": [
+    {
+      "title": "Docker Model Runner",
+      "provider": "openai",
+      "model": "ai/qwen2.5-coder",
+      "apiBase": "http://localhost:12434/engines/v1",
+      "apiKey": "not-needed"
+    }
+  ]
+}
+```
+
+### Using Ollama provider
+
+Continue also supports the Ollama provider, which works with DMR:
+
+```json
+{
+  "models": [
+    {
+      "title": "Docker Model Runner (Ollama)",
+      "provider": "ollama",
+      "model": "ai/qwen2.5-coder",
+      "apiBase": "http://localhost:12434"
+    }
+  ]
+}
+```
+
+## Cursor
+
+[Cursor](https://cursor.sh) is an AI-powered code editor.
+
+### Configuration
+
+1. Open Cursor Settings (Cmd/Ctrl + ,).
+2. Navigate to **Models** > **OpenAI API Key**.
+3. Configure:
+
+   | Setting | Value |
+   |---------|-------|
+   | OpenAI API Key | `not-needed` |
+   | Override OpenAI Base URL | `http://localhost:12434/engines/v1` |
+
+4. In the model drop-down, enter your model name: `ai/qwen2.5-coder`
+
+> [!NOTE]
+> Some Cursor features may require models with specific capabilities (e.g., function calling).
+> Use capable models like `ai/qwen2.5-coder` or `ai/llama3.2` for best results.
+
+## Zed
+
+[Zed](https://zed.dev) is a high-performance code editor with AI features.
+
+### Configuration
+
+Edit your Zed settings (`~/.config/zed/settings.json`):
+
+```json
+{
+  "language_models": {
+    "openai": {
+      "api_url": "http://localhost:12434/engines/v1",
+      "available_models": [
+        {
+          "name": "ai/qwen2.5-coder",
+          "display_name": "Qwen 2.5 Coder (DMR)",
+          "max_tokens": 8192
+        }
+      ]
+    }
+  }
+}
+```
+
+## Open WebUI
+
+[Open WebUI](https://github.com/open-webui/open-webui) provides a ChatGPT-like interface for local models.
+
+See [Open WebUI integration](openwebui-integration.md) for detailed setup instructions.
+
+## Aider
+
+[Aider](https://aider.chat) is an AI pair programming tool for the terminal.
+
+### Configuration
+
+Set environment variables or use command-line flags:
+
+```bash
+export OPENAI_API_BASE=http://localhost:12434/engines/v1
+export OPENAI_API_KEY=not-needed
+
+aider --model openai/ai/qwen2.5-coder
+```
+
+Or in a single command:
+
+```console
+$ aider --openai-api-base http://localhost:12434/engines/v1 \
+        --openai-api-key not-needed \
+        --model openai/ai/qwen2.5-coder
+```
+
+## LangChain
+
+### Python
+
+```python
+from langchain_openai import ChatOpenAI
+
+llm = ChatOpenAI(
+    base_url="http://localhost:12434/engines/v1",
+    api_key="not-needed",
+    model="ai/qwen2.5-coder"
+)
+
+response = llm.invoke("Write a hello world function in Python")
+print(response.content)
+```
+
+### JavaScript/TypeScript
+
+```typescript
+import { ChatOpenAI } from "@langchain/openai";
+
+const model = new ChatOpenAI({
+  configuration: {
+    baseURL: "http://localhost:12434/engines/v1",
+  },
+  apiKey: "not-needed",
+  modelName: "ai/qwen2.5-coder",
+});
+
+const response = await model.invoke("Write a hello world function");
+console.log(response.content);
+```
+
+## LlamaIndex
+
+```python
+from llama_index.llms.openai_like import OpenAILike
+
+llm = OpenAILike(
+    api_base="http://localhost:12434/engines/v1",
+    api_key="not-needed",
+    model="ai/qwen2.5-coder"
+)
+
+response = llm.complete("Write a hello world function")
+print(response.text)
+```
+
+## OpenCode
+
+[OpenCode](https://opencode.ai/) is an open-source coding assistant designed to integrate directly into developer workflows. It supports multiple model providers and exposes a flexible configuration system that makes it easy to switch between them.
+
+See [Use OpenCode with Docker Model Runner](../../../guides/opencode-model-runner.md)
+for a task-focused guide that walks through model setup, configuration, and
+troubleshooting.
+
+### Configuration
+
+1. Install OpenCode (see [docs](https://opencode.ai/docs/#install))
+2. Reference DMR in your OpenCode configuration, either globally at `~/.config/opencode/opencode.json` or project specific with a `opencode.json` file in the root of your project
+   ```json
+   {
+     "$schema": "https://opencode.ai/config.json",
+     "provider": {
+       "dmr": {
+         "npm": "@ai-sdk/openai-compatible",
+         "name": "Docker Model Runner",
+         "options": {
+           "baseURL": "http://localhost:12434/v1"
+         },
+         "models": {
+           "ai/qwen2.5-coder": {
+             "name": "ai/qwen2.5-coder"
+           },
+           "ai/llama3.2": {
+             "name": "ai/llama3.2"
+           }
+         }
+       }
+     }
+   }
+   ```
+3. Select the model you want in OpenCode
+
+You can find more details in [this Docker Blog post](https://www.docker.com/blog/opencode-docker-model-runner-private-ai-coding/)
+
+## Claude Code
+
+[Claude Code](https://claude.com/product/claude-code) is [Anthropic's](https://www.anthropic.com/) command-line tool for agentic coding. It lives in your terminal, understands your codebase, and executes routine tasks, explains complex code, and handles Git workflows through natural language commands.
+
+See [Use Claude Code with Docker Model Runner](../../../guides/claude-code-model-runner.md)
+for a task-focused guide that walks through model setup, configuration, and
+inspecting requests. To run Claude Code in an isolated Docker Sandbox against
+a local model, see
+[Run Claude Code in a Docker Sandbox with Docker Model Runner](../../../guides/claude-code-sandbox-model-runner.md).
+
+### Configuration
+
+1. Install Claude Code (see [docs](https://code.claude.com/docs/en/quickstart#step-1-install-claude-code))
+2. Use the `ANTHROPIC_BASE_URL` environment variable to point Claude Code at DMR. On Mac or Linux, you can do this, for example if you want to use the `gpt-oss:32k` model:
+    ```bash
+    ANTHROPIC_BASE_URL=http://localhost:12434 claude --model qwen2.5-coder
+    ```
+    On Windows (PowerShell) you can do it like this:
+    ```powershell
+    $env:ANTHROPIC_BASE_URL="http://localhost:12434"
+    claude --model gpt-oss:32k
+    ```
+
+> [!TIP]
+>
+> To avoid setting the variable each time, add it to your shell profile (`~/.bashrc`, `~/.zshrc`, or equivalent):
+>
+> ```shell
+> export ANTHROPIC_BASE_URL=http://localhost:12434
+> ```
+
+You can find more details in [this Docker Blog post](https://www.docker.com/blog/run-claude-code-locally-docker-model-runner/)
+
+> [!NOTE]
+>
+> While the other integrations on this page use the [OpenAI-compatible API](/ai/model-runner/api-reference/#openai-compatible-api), DMR also exposes a [Anthropic-compatible API](/ai/model-runner/api-reference/#anthropic-compatible-api) used here.
+
+## Common issues
+
+### "Connection refused" errors
+
+1. Ensure Docker Model Runner is enabled and running:
+   ```console
+   $ docker model status
+   ```
+
+2. Verify TCP access is enabled:
+   ```console
+   $ curl http://localhost:12434/engines/v1/models
+   ```
+
+3. Check if another service is using port 12434.
+
+4. If you run your tool in WSL and want to connect to DMR on the host via `localhost`, this might not directly work. Configuring WSL to use [mirrored networking](https://learn.microsoft.com/en-us/windows/wsl/networking#mirrored-mode-networking) can solve this.
+
+### "Model not found" errors
+
+1. Verify the model is pulled:
+   ```console
+   $ docker model list
+   ```
+
+2. Use the full model name including namespace (e.g., `ai/qwen2.5-coder`, not just `qwen2.5-coder`).
+
+### Slow responses or timeouts
+
+1. For first requests, models need to load into memory. Subsequent requests are faster.
+
+2. Consider using a smaller model or adjusting the context size:
+   ```console
+   $ docker model configure --context-size 4096 ai/qwen2.5-coder
+   ```
+
+3. Check available system resources (RAM, GPU memory).
+
+### CORS errors (web-based tools)
+
+If using browser-based tools, add the origin to CORS allowed origins:
+
+1. Docker Desktop: Settings > AI > CORS Allowed Origins
+2. Add your tool's URL (e.g., `http://localhost:3000`)
+
+## Recommended models by use case
+
+| Use case | Recommended model | Notes |
+|----------|-------------------|-------|
+| Code completion | `ai/qwen3-coder` | Optimized for coding tasks with a large context window |
+| Agentic coding | `ai/devstral-small-2` | Good fit for tools such as Claude Code and OpenCode |
+| General assistant | `ai/llama3.2` | Good balance of capabilities |
+| Small/fast | `ai/smollm2` | Low resource usage |
+| Embeddings | `ai/all-minilm` | For RAG and semantic search |
+
+## What's next
+
+- [API reference](api-reference.md) - Full API documentation
+- [Configuration options](configuration.md) - Tune model behavior
+- [Open WebUI integration](openwebui-integration.md) - Set up a web interface
diff --git a/content/manuals/ai/model-runner/images/dmr-catalog.png b/content/manuals/ai/model-runner/images/dmr-catalog.png
new file mode 100644
index 000000000000..15d8bd04df11
Binary files /dev/null and b/content/manuals/ai/model-runner/images/dmr-catalog.png differ
diff --git a/content/manuals/ai/model-runner/images/dmr-logs.png b/content/manuals/ai/model-runner/images/dmr-logs.png
new file mode 100644
index 000000000000..e2b2289e9886
Binary files /dev/null and b/content/manuals/ai/model-runner/images/dmr-logs.png differ
diff --git a/content/manuals/ai/model-runner/images/dmr-run.png b/content/manuals/ai/model-runner/images/dmr-run.png
new file mode 100644
index 000000000000..c12b3bd5fdd4
Binary files /dev/null and b/content/manuals/ai/model-runner/images/dmr-run.png differ
diff --git a/content/manuals/ai/model-runner/inference-engines.md b/content/manuals/ai/model-runner/inference-engines.md
new file mode 100644
index 000000000000..952e29489337
--- /dev/null
+++ b/content/manuals/ai/model-runner/inference-engines.md
@@ -0,0 +1,410 @@
+---
+title: Inference engines
+description: Learn about the llama.cpp, vLLM, and Diffusers inference engines in Docker Model Runner.
+weight: 50
+keywords: Docker, ai, model runner, llama.cpp, vllm, diffusers, inference, gguf, safetensors, cuda, gpu, image generation, stable diffusion
+---
+
+Docker Model Runner supports three inference engines: **llama.cpp**, **vLLM**, and **Diffusers**.
+Each engine has different strengths, supported platforms, and model format
+requirements. This guide helps you choose the right engine and configure it for
+your use case.
+
+## Engine comparison
+
+| Feature | llama.cpp | vLLM | Diffusers                           |
+|---------|-----------|------|-------------------------------------|
+| **Model formats** | GGUF | Safetensors, HuggingFace | DDUF                                |
+| **Platforms** | All (macOS, Windows, Linux) | Linux x86_64 only | Linux (x86_64, ARM64)               |
+| **GPU support** | NVIDIA, AMD, Apple Silicon, Vulkan | NVIDIA CUDA only | NVIDIA CUDA only                    |
+| **CPU inference** | Yes | No | No                                  |
+| **Quantization** | Built-in (Q4, Q5, Q8, etc.) | Limited | Limited                             |
+| **Memory efficiency** | High (with quantization) | Moderate | Moderate                            |
+| **Throughput** | Good | High (with batching) | Good                                |
+| **Best for** | Local development, resource-constrained environments | Production, high throughput | Image generation                    |
+| **Use case** | Text generation (LLMs) | Text generation (LLMs) | Image generation (Stable Diffusion) |
+
+## llama.cpp
+
+[llama.cpp](https://github.com/ggerganov/llama.cpp) is the default inference
+engine in Docker Model Runner. It's designed for efficient local inference and
+supports a wide range of hardware configurations.
+
+### Platform support
+
+| Platform | GPU support | Notes |
+|----------|-------------|-------|
+| macOS (Apple Silicon) | Metal | Automatic GPU acceleration |
+| Windows (x64) | NVIDIA CUDA | Requires NVIDIA drivers 576.57+ |
+| Windows (ARM64) | Adreno OpenCL | Qualcomm 6xx series and later |
+| Linux (x64) | NVIDIA, AMD, Vulkan | Multiple backend options |
+| Linux | CPU only | Works on any x64/ARM64 system |
+
+### Model format: GGUF
+
+llama.cpp uses the GGUF format, which supports efficient quantization for reduced
+memory usage without significant quality loss.
+
+#### Quantization levels
+
+| Quantization | Bits per weight | Memory usage | Quality |
+|--------------|-----------------|--------------|---------|
+| Q2_K | ~2.5 | Lowest | Reduced |
+| Q3_K_M | ~3.5 | Minimal | Acceptable |
+| Q4_K_M | ~4.5 | Low | Good |
+| Q5_K_M | ~5.5 | Moderate | Excellent |
+| Q6_K | ~6.5 | Higher | Excellent |
+| Q8_0 | 8 | High | Near-original |
+| F16 | 16 | Highest | Original |
+
+**Recommended**: Q4_K_M offers the best balance of quality and memory usage for
+most use cases.
+
+#### Pulling quantized models
+
+Models on Docker Hub often include quantization in the tag:
+
+```console
+$ docker model pull ai/llama3.2:3B-Q4_K_M
+```
+
+### Using llama.cpp
+
+llama.cpp is the default engine. No special configuration is required:
+
+```console
+$ docker model run ai/smollm2
+```
+
+To explicitly specify llama.cpp when running models:
+
+```console
+$ docker model run ai/smollm2 --backend llama.cpp
+```
+
+### llama.cpp API endpoints
+
+When using llama.cpp, API calls use the llama.cpp engine path:
+
+```text
+POST /engines/llama.cpp/v1/chat/completions
+```
+
+Or without the engine prefix:
+
+```text
+POST /engines/v1/chat/completions
+```
+
+## vLLM
+
+[vLLM](https://github.com/vllm-project/vllm) is a high-performance inference
+engine optimized for production workloads with high throughput requirements.
+
+### Platform support
+
+| Platform | GPU | Support status |
+|----------|-----|----------------|
+| Linux x86_64 | NVIDIA CUDA | Supported |
+| Windows with WSL2 | NVIDIA CUDA | Supported (Docker Desktop 4.54+) |
+| macOS | - | Not supported |
+| Linux ARM64 | - | Not supported |
+| AMD GPUs | - | Not supported |
+
+> [!IMPORTANT]
+> vLLM requires an NVIDIA GPU with CUDA support. It does not support CPU-only
+> inference.
+
+### Model format: Safetensors
+
+vLLM works with models in Safetensors format, which is the standard format for
+HuggingFace models. These models typically use more memory than quantized GGUF
+models but may offer better quality and faster inference on powerful hardware.
+
+### Setting up vLLM
+
+#### Docker Engine (Linux)
+
+Install the Model Runner with vLLM backend:
+
+```console
+$ docker model install-runner --backend vllm --gpu cuda
+```
+
+Verify the installation:
+
+```console
+$ docker model status
+Docker Model Runner is running
+
+Status:
+llama.cpp: running llama.cpp version: c22473b
+vllm: running vllm version: 0.11.0
+```
+
+#### Docker Desktop (Windows with WSL2)
+
+1. Ensure you have:
+   - Docker Desktop 4.54 or later (minimum version for vLLM support)
+   - NVIDIA GPU with updated drivers
+   - WSL2 enabled
+
+2. Install vLLM backend:
+   ```console
+   $ docker model install-runner --backend vllm --gpu cuda
+   ```
+
+### Running models with vLLM
+
+vLLM models are typically tagged with `-vllm` suffix:
+
+```console
+$ docker model run ai/smollm2-vllm
+```
+
+To specify the vLLM backend explicitly:
+
+```console
+$ docker model run ai/model --backend vllm
+```
+
+### vLLM API endpoints
+
+When using vLLM, specify the engine in the API path:
+
+```text
+POST /engines/vllm/v1/chat/completions
+```
+
+### vLLM configuration
+
+#### HuggingFace overrides
+
+Use `--hf_overrides` to pass model configuration overrides:
+
+```console
+$ docker model configure --hf_overrides '{"max_model_len": 8192}' ai/model-vllm
+```
+
+#### Common vLLM settings
+
+| Setting | Description | Example |
+|---------|-------------|---------|
+| `max_model_len` | Maximum context length | 8192 |
+| `gpu_memory_utilization` | Fraction of GPU memory to use | 0.9 |
+| `tensor_parallel_size` | GPUs for tensor parallelism | 2 |
+
+### vLLM and llama.cpp performance comparison
+
+| Scenario | Recommended engine |
+|----------|-------------------|
+| Single user, local development | llama.cpp |
+| Multiple concurrent requests | vLLM |
+| Limited GPU memory | llama.cpp (with quantization) |
+| Maximum throughput | vLLM |
+| CPU-only system | llama.cpp |
+| Apple Silicon Mac | llama.cpp |
+| Production deployment | vLLM (if hardware supports it) |
+
+## Diffusers
+
+[Diffusers](https://github.com/huggingface/diffusers) is an inference engine
+for image generation models, including Stable Diffusion. Unlike llama.cpp and
+vLLM which focus on text generation with LLMs, Diffusers enables you to generate
+images from text prompts.
+
+### Platform support
+
+| Platform | GPU | Support status |
+|----------|-----|----------------|
+| Linux x86_64 | NVIDIA CUDA | Supported |
+| Linux ARM64 | NVIDIA CUDA | Supported |
+| Windows | - | Not supported |
+| macOS | - | Not supported |
+
+> [!IMPORTANT]
+> Diffusers requires an NVIDIA GPU with CUDA support. It does not support
+> CPU-only inference.
+
+### Setting up Diffusers
+
+Install the Model Runner with Diffusers backend:
+
+```console
+$ docker model reinstall-runner --backend diffusers --gpu cuda
+```
+
+Verify the installation:
+
+```console
+$ docker model status
+Docker Model Runner is running
+
+Status:
+llama.cpp: running llama.cpp version: 34ce48d
+mlx: not installed
+sglang: sglang package not installed
+vllm: vLLM binary not found
+diffusers: running diffusers version: 0.36.0
+```
+
+### Pulling Diffusers models
+
+Pull a Stable Diffusion model:
+
+```console
+$ docker model pull stable-diffusion:Q4
+```
+
+### Generating images with Diffusers
+
+Diffusers uses an image generation API endpoint. To generate an image:
+
+```console
+$ curl -s -X POST http://localhost:12434/engines/diffusers/v1/images/generations \
+  -H "Content-Type: application/json" \
+  -d '{
+    "model": "stable-diffusion:Q4",
+    "prompt": "A picture of a nice cat",
+    "size": "512x512"
+  }' | jq -r '.data[0].b64_json' | base64 -d > image.png
+```
+
+This command:
+1. Sends a POST request to the Diffusers image generation endpoint
+2. Specifies the model, prompt, and output image size
+3. Extracts the base64-encoded image from the response
+4. Decodes it and saves it as `image.png`
+
+### Diffusers API endpoint
+
+When using Diffusers, specify the engine in the API path:
+
+```text
+POST /engines/diffusers/v1/images/generations
+```
+
+### Supported parameters
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `model` | string | Required. The model identifier (e.g., `stable-diffusion:Q4`). |
+| `prompt` | string | Required. The text description of the image to generate. |
+| `size` | string | Image dimensions in `WIDTHxHEIGHT` format (e.g., `512x512`). |
+
+## Running multiple engines
+
+You can run llama.cpp, vLLM, and Diffusers simultaneously. Docker Model Runner routes
+requests to the appropriate engine based on the model or explicit engine selection.
+
+Check which engines are running:
+
+```console
+$ docker model status
+Docker Model Runner is running
+
+Status:
+llama.cpp: running llama.cpp version: 34ce48d
+mlx: not installed
+sglang: sglang package not installed
+vllm: running vllm version: 0.11.0
+diffusers: running diffusers version: 0.36.0
+```
+
+### Engine-specific API paths
+
+| Engine | API path | Use case |
+|--------|----------|----------|
+| llama.cpp | `/engines/llama.cpp/v1/chat/completions` | Text generation |
+| vLLM | `/engines/vllm/v1/chat/completions` | Text generation |
+| Diffusers | `/engines/diffusers/v1/images/generations` | Image generation |
+| Auto-select | `/engines/v1/chat/completions` | Text generation (auto-selects engine) |
+
+## Managing inference engines
+
+### Install an engine
+
+```console
+$ docker model install-runner --backend <engine> [--gpu <type>]
+```
+
+Options:
+- `--backend`: `llama.cpp`, `vllm`, or `diffusers`
+- `--gpu`: `cuda`, `rocm`, `vulkan`, or `metal` (depends on platform)
+
+### Reinstall an engine
+
+```console
+$ docker model reinstall-runner --backend <engine>
+```
+
+### Check engine status
+
+```console
+$ docker model status
+```
+
+### View engine logs
+
+```console
+$ docker model logs
+```
+
+## Packaging models for each engine
+
+### Package a GGUF model (llama.cpp)
+
+```console
+$ docker model package --gguf ./model.gguf --push myorg/mymodel:Q4_K_M
+```
+
+### Package a Safetensors model (vLLM)
+
+```console
+$ docker model package --safetensors ./model/ --push myorg/mymodel-vllm
+```
+
+## Troubleshooting
+
+### vLLM won't start
+
+1. Verify NVIDIA GPU is available:
+   ```console
+   $ nvidia-smi
+   ```
+
+2. Check Docker has GPU access:
+   ```console
+   $ docker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smi
+   ```
+
+3. Verify you're on a supported platform (Linux x86_64 or Windows WSL2).
+
+### llama.cpp is slow
+
+1. Ensure GPU acceleration is working (check logs for Metal/CUDA messages).
+
+2. Try a more aggressive quantization:
+   ```console
+   $ docker model pull ai/model:Q4_K_M
+   ```
+
+3. Reduce context size:
+   ```console
+   $ docker model configure --context-size 2048 ai/model
+   ```
+
+### Out of memory errors
+
+1. Use a smaller quantization (Q4 instead of Q8).
+2. Reduce context size.
+3. For vLLM, adjust `gpu_memory_utilization`:
+   ```console
+   $ docker model configure --hf_overrides '{"gpu_memory_utilization": 0.8}' ai/model
+   ```
+
+## What's next
+
+- [Configuration options](configuration.md) - Detailed parameter reference
+- [API reference](api-reference.md) - API documentation
+- [GPU support](/manuals/desktop/features/gpu.md) - GPU configuration for Docker Desktop
diff --git a/content/manuals/ai/model-runner/openwebui-integration.md b/content/manuals/ai/model-runner/openwebui-integration.md
new file mode 100644
index 000000000000..1e8cdd5805ad
--- /dev/null
+++ b/content/manuals/ai/model-runner/openwebui-integration.md
@@ -0,0 +1,293 @@
+---
+title: Open WebUI integration
+description: Set up Open WebUI as a ChatGPT-like interface for Docker Model Runner.
+weight: 45
+keywords: Docker, ai, model runner, open webui, openwebui, chat interface, ollama, ui
+---
+
+[Open WebUI](https://github.com/open-webui/open-webui) is an open-source,
+self-hosted web interface that provides a ChatGPT-like experience for local
+AI models. You can connect it to Docker Model Runner to get a polished chat
+interface for your models.
+
+## Prerequisites
+
+- Docker Model Runner enabled with TCP access
+- A model pulled (e.g., `docker model pull ai/llama3.2`)
+
+## Quick start with Docker Compose
+
+The easiest way to run Open WebUI with Docker Model Runner is using Docker Compose.
+
+Create a `compose.yaml` file:
+
+```yaml
+services:
+  open-webui:
+    image: ghcr.io/open-webui/open-webui:main
+    ports:
+      - "3000:8080"
+    environment:
+      - OLLAMA_BASE_URL=http://host.docker.internal:12434
+      - WEBUI_AUTH=false
+    extra_hosts:
+      - "host.docker.internal:host-gateway"
+    volumes:
+      - open-webui:/app/backend/data
+
+volumes:
+  open-webui:
+```
+
+Start the services:
+
+```console
+$ docker compose up -d
+```
+
+Open your browser to [http://localhost:3000](http://localhost:3000).
+
+## Configuration options
+
+### Environment variables
+
+| Variable | Description | Default |
+|----------|-------------|---------|
+| `OLLAMA_BASE_URL` | URL of Docker Model Runner | Required |
+| `WEBUI_AUTH` | Enable authentication | `true` |
+| `OPENAI_API_BASE_URL` | Use OpenAI-compatible API instead | - |
+| `OPENAI_API_KEY` | API key (use any value for DMR) | - |
+
+### Using OpenAI-compatible API
+
+If you prefer to use the OpenAI-compatible API instead of the Ollama API:
+
+```yaml
+services:
+  open-webui:
+    image: ghcr.io/open-webui/open-webui:main
+    ports:
+      - "3000:8080"
+    environment:
+      - OPENAI_API_BASE_URL=http://host.docker.internal:12434/engines/v1
+      - OPENAI_API_KEY=not-needed
+      - WEBUI_AUTH=false
+    extra_hosts:
+      - "host.docker.internal:host-gateway"
+    volumes:
+      - open-webui:/app/backend/data
+
+volumes:
+  open-webui:
+```
+
+## Network configuration
+
+### Docker Desktop
+
+On Docker Desktop, `host.docker.internal` automatically resolves to the host machine.
+The previous example works without modification.
+
+### Docker Engine (Linux)
+
+On Docker Engine, you may need to configure the network differently:
+
+```yaml
+services:
+  open-webui:
+    image: ghcr.io/open-webui/open-webui:main
+    network_mode: host
+    environment:
+      - OLLAMA_BASE_URL=http://localhost:12434
+      - WEBUI_AUTH=false
+    volumes:
+      - open-webui:/app/backend/data
+
+volumes:
+  open-webui:
+```
+
+Or use the host gateway:
+
+```yaml
+services:
+  open-webui:
+    image: ghcr.io/open-webui/open-webui:main
+    ports:
+      - "3000:8080"
+    environment:
+      - OLLAMA_BASE_URL=http://172.17.0.1:12434
+      - WEBUI_AUTH=false
+    volumes:
+      - open-webui:/app/backend/data
+
+volumes:
+  open-webui:
+```
+
+## Using Open WebUI
+
+### Select a model
+
+1. Open [http://localhost:3000](http://localhost:3000)
+2. Select the model drop-down in the top-left
+3. Select from your pulled models (they appear with `ai/` prefix)
+
+### Pull models through the UI
+
+Open WebUI can pull models directly:
+
+1. Select the model drop-down
+2. Enter a model name: `ai/llama3.2`
+3. Select the download icon
+
+### Chat features
+
+Open WebUI provides:
+
+- Multi-turn conversations with context
+- Message editing and regeneration
+- Code syntax highlighting
+- Markdown rendering
+- Conversation history and search
+- Export conversations
+
+## Complete example with multiple models
+
+This example sets up Open WebUI with Docker Model Runner and pre-pulls several models:
+
+```yaml
+services:
+  open-webui:
+    image: ghcr.io/open-webui/open-webui:main
+    ports:
+      - "3000:8080"
+    environment:
+      - OLLAMA_BASE_URL=http://host.docker.internal:12434
+      - WEBUI_AUTH=false
+      - DEFAULT_MODELS=ai/llama3.2
+    extra_hosts:
+      - "host.docker.internal:host-gateway"
+    volumes:
+      - open-webui:/app/backend/data
+    depends_on:
+      model-setup:
+        condition: service_completed_successfully
+
+  model-setup:
+    image: docker:cli
+    volumes:
+      - /var/run/docker.sock:/var/run/docker.sock
+    command: >
+      sh -c "
+        docker model pull ai/llama3.2 &&
+        docker model pull ai/qwen2.5-coder &&
+        docker model pull ai/smollm2
+      "
+
+volumes:
+  open-webui:
+```
+
+## Enabling authentication
+
+For multi-user setups or security, enable authentication:
+
+```yaml
+services:
+  open-webui:
+    image: ghcr.io/open-webui/open-webui:main
+    ports:
+      - "3000:8080"
+    environment:
+      - OLLAMA_BASE_URL=http://host.docker.internal:12434
+      - WEBUI_AUTH=true
+    extra_hosts:
+      - "host.docker.internal:host-gateway"
+    volumes:
+      - open-webui:/app/backend/data
+
+volumes:
+  open-webui:
+```
+
+On first visit, you'll create an admin account.
+
+## Troubleshooting
+
+### Models don't appear in the drop-down
+
+1. Verify Docker Model Runner is accessible:
+   ```console
+   $ curl http://localhost:12434/api/tags
+   ```
+
+2. Check that models are pulled:
+   ```console
+   $ docker model list
+   ```
+
+3. Verify the `OLLAMA_BASE_URL` is correct and accessible from the container.
+
+### "Connection refused" errors
+
+1. Ensure TCP access is enabled for Docker Model Runner.
+
+2. On Docker Desktop, verify `host.docker.internal` resolves:
+   ```console
+   $ docker run --rm alpine ping -c 1 host.docker.internal
+   ```
+
+3. On Docker Engine, try using `network_mode: host` or the explicit host IP.
+
+### Slow response times
+
+1. First requests load the model into memory, which takes time.
+
+2. Subsequent requests are much faster.
+
+3. If consistently slow, consider:
+   - Using a smaller model
+   - Reducing context size
+   - Checking GPU acceleration is working
+
+### CORS errors
+
+If running Open WebUI on a different host:
+
+1. In Docker Desktop, go to Settings > AI
+2. Add the Open WebUI URL to **CORS Allowed Origins**
+
+## Customization
+
+### Custom system prompts
+
+Open WebUI supports setting system prompts per model. Configure these in the UI under Settings > Models.
+
+### Model parameters
+
+Adjust model parameters in the chat interface:
+
+1. Select the settings icon next to the model name
+2. Adjust temperature, top-p, max tokens, etc.
+
+These settings are passed through to Docker Model Runner.
+
+## Running on a different port
+
+To run Open WebUI on a different port:
+
+```yaml
+services:
+  open-webui:
+    image: ghcr.io/open-webui/open-webui:main
+    ports:
+      - "8080:8080"  # Change first port number
+    # ... rest of config
+```
+
+## What's next
+
+- [API reference](api-reference.md) - Learn about the APIs Open WebUI uses
+- [Configuration options](configuration.md) - Tune model behavior
+- [IDE integrations](ide-integrations.md) - Connect other tools to DMR
diff --git a/content/manuals/ai/sandboxes/_index.md b/content/manuals/ai/sandboxes/_index.md
new file mode 100644
index 000000000000..a6ec29d0d2c6
--- /dev/null
+++ b/content/manuals/ai/sandboxes/_index.md
@@ -0,0 +1,65 @@
+---
+title: Docker Sandboxes
+description: Run AI coding agents in isolated environments
+keywords: docker sandboxes, sbx, ai agents, sandboxed agents, microVM
+weight: 10
+params:
+  sidebar:
+    group: AI and agents
+---
+
+Docker Sandboxes run AI coding agents in isolated microVM sandboxes. Each
+sandbox gets its own Docker daemon, filesystem, and network — the agent can
+build containers, install packages, and modify files without touching your host
+system.
+
+> [!NOTE]
+> The `sbx` CLI is free to use, including for commercial work. Only
+> [organization governance](governance/) requires a separate paid subscription.
+
+Organization admins can
+[centrally manage sandbox network, filesystem, and MCP policies](governance/access-controls/organization.md),
+so the same controls apply uniformly across every developer's machine.
+Available on a separate paid subscription.
+
+## Get started
+
+Follow the [installation guide](install.md) to check the system requirements,
+install the `sbx` CLI, and sign in.
+
+Then launch an agent in a sandbox:
+
+```console
+$ cd ~/my-project
+$ sbx run claude
+```
+
+See the [get started guide](get-started.md) for a first-session walkthrough, or
+jump to the [usage guide](usage.md) for basic commands.
+
+## Learn more
+
+- [Agents](agents/) — supported agents and per-agent configuration
+- [Workflows](workflows/) — patterns for Git, local development,
+  authentication, agent skills, and automation
+- [Configuration](configuration/) — manage credentials, declare project
+  environments, turn on GPU passthrough, and configure an upstream proxy
+- [Integrations](integrations/) — connect editors and apps like VS Code and
+  Cursor to a sandbox over SSH
+- [MCP gateway](mcp-gateway.md) — register MCP servers and connect them to
+  sandboxed agents
+- [Customize](customize/) — reusable templates and declarative kits for
+  extending or tailoring sandboxes
+- [Architecture](architecture.md) — microVM isolation, workspace mounting,
+  networking
+- [Security](security/) — isolation model, credential handling, and
+  network policies
+- [CLI reference](/reference/cli/sbx/) — full list of `sbx` commands and options
+- [Troubleshooting](troubleshooting.md) — common issues and fixes
+- [FAQ](faq.md) — login requirements, telemetry, etc
+
+## Feedback
+
+Your feedback shapes what gets built next. If you run into a bug, hit a
+missing feature, or have a suggestion, open an issue at
+[github.com/docker/sbx-releases/issues](https://github.com/docker/sbx-releases/issues).
diff --git a/content/manuals/ai/sandboxes/agents/_index.md b/content/manuals/ai/sandboxes/agents/_index.md
new file mode 100644
index 000000000000..d50303b3f5e3
--- /dev/null
+++ b/content/manuals/ai/sandboxes/agents/_index.md
@@ -0,0 +1,23 @@
+---
+title: Supported agents
+linkTitle: Agents
+weight: 40
+description: AI coding agents supported by Docker Sandboxes.
+keywords: docker sandboxes, ai agents, claude code, codex, cursor, gemini
+---
+
+Docker Sandboxes runs the following agents out of the box:
+
+- [Claude Code](claude-code/)
+- [Codex](codex/)
+- [Copilot](copilot/)
+- [Cursor](cursor/)
+- [Docker Agent](docker-agent/)
+- [Droid](droid/)
+- [Gemini](gemini/)
+- [Kiro](kiro/)
+- [OpenCode](opencode/)
+- [Shell](shell/) — agent-less sandbox for manual setup or testing
+
+Want to pre-install tools or customize an agent's environment?
+See [Customize](../customize/).
diff --git a/content/manuals/ai/sandboxes/agents/claude-code.md b/content/manuals/ai/sandboxes/agents/claude-code.md
new file mode 100644
index 000000000000..89cfc814da6e
--- /dev/null
+++ b/content/manuals/ai/sandboxes/agents/claude-code.md
@@ -0,0 +1,168 @@
+---
+title: Claude Code
+weight: 10
+description: |
+  Use Claude Code in Docker Sandboxes with authentication, local models,
+  configuration, and YOLO mode for AI-assisted development.
+keywords: docker sandboxes, claude code, anthropic, ai agent, sbx, local models, llmman, ollama
+---
+
+Official documentation: [Claude Code](https://code.claude.com/docs)
+
+## Quick start
+
+Launch Claude Code in a sandbox by pointing it at a project directory:
+
+```console
+$ sbx run claude ~/my-project
+```
+
+The workspace parameter defaults to the current directory, so `sbx run claude`
+from inside your project works too. To start Claude with a specific prompt:
+
+```console
+$ sbx run claude --name my-sandbox -- "Add error handling to the login function"
+```
+
+Everything after `--` is passed directly to Claude Code. You can also pipe in a
+prompt from a file with `-- "$(cat prompt.txt)"`.
+
+## Authentication
+
+Claude Code requires either an Anthropic API key or a Claude subscription.
+
+**API key**: Store your key using
+[stored secrets](../configuration/credentials.md#stored-secrets):
+
+```console
+$ sbx secret set anthropic
+```
+
+**Claude subscription**: If no API key is set, use the `/login` command inside
+Claude Code to authenticate via OAuth.
+
+## Configuration
+
+Sandboxes don't pick up user-level configuration from your host, such as
+`~/.claude`. Only project-level configuration in the working directory is
+available inside the sandbox. See
+[Why doesn't the sandbox use my user-level agent configuration?](../faq.md#why-doesnt-the-sandbox-use-my-user-level-agent-configuration)
+for workarounds.
+
+### Remote control
+
+To use Claude Code's `/remote-control` command inside a sandbox, turn on remote
+control:
+
+```console
+$ sbx settings set claude.remoteControl true
+```
+
+### Default startup command
+
+Without extra args, the sandbox runs:
+
+```text
+claude --dangerously-skip-permissions
+```
+
+Arguments after `--` are added after the default flags when the first one is
+itself a flag (begins with `-`), so `--dangerously-skip-permissions` is
+preserved:
+
+```console
+$ sbx run claude -- -c   # runs claude --dangerously-skip-permissions -c
+```
+
+When the first argument is a bare word, such as the `agents` subcommand, it
+replaces the defaults instead.
+
+See the [Claude Code CLI reference](https://code.claude.com/docs/en/cli-reference)
+for available options.
+
+## Agents view
+
+Claude Code's [agents view](https://code.claude.com/docs/en/agent-view)
+starts background sessions that run tasks in parallel. Pair it with
+[clone mode](../workflows/git.md#clone-mode) to keep their changes inside the
+sandbox:
+
+```console
+$ sbx run --clone claude -- agents
+```
+
+This invocation replaces the
+[default startup command](#default-startup-command), so it doesn't
+include `--dangerously-skip-permissions` and you can't switch to
+bypass-permissions mode inside the sandbox. To work around this, either
+use Claude Code's auto mode or pass the flag explicitly:
+
+```console
+$ sbx run --clone claude -- --dangerously-skip-permissions agents
+```
+
+Claude Code may use branches or worktrees to keep changes from its background
+sessions separate. This depends on the task, Claude Code configuration, and
+project instructions. The `--clone` flag doesn't control this behavior. Claude
+Code creates any branches and worktrees inside the sandbox, not in your host
+checkout.
+
+To review a branch created by a session, fetch the
+`sandbox-<sandbox-name>` remote from the host:
+
+```console
+$ git fetch sandbox-<sandbox-name>
+$ git diff main..sandbox-<sandbox-name>/<branch>
+```
+
+See [Git workflows](../workflows/git.md) for clone-mode details.
+
+## Base image
+
+The sandbox uses `docker/sandbox-templates:claude-code`. See
+[Templates](../customize/templates.md) to build your own image on top of
+this base.
+
+## Use a local model
+
+The `--model` flag routes Claude Code's Anthropic API requests to a model
+served on your host. This feature is experimental and isn't supported on
+Windows.
+
+Enable the feature:
+
+```console
+$ sbx settings set platform.allowExperimentalFeatures true
+$ sbx settings set feature.model true
+```
+
+To use the bundled `llmman` model server, pass a GGUF model reference or short
+name:
+
+```console
+$ sbx run --model gemma4 claude
+```
+
+On first use, `sbx` starts `llmman`, pulls the model, and leaves the server
+running on your host. Later sandboxes reuse the server and its model store.
+
+To use an existing Ollama installation instead, set the provider to `ollama`:
+
+```console
+$ sbx run --model gemma4 --provider ollama claude
+```
+
+Ollama must already be installed and running. `sbx` connects to it but doesn't
+start or manage the Ollama process.
+
+You can also change the model for an existing sandbox:
+
+```console
+$ sbx run --name <sandbox-name> --model <model-name>
+```
+
+Changing the model recreates the sandbox container. The workspace and
+kit-owned volumes persist.
+
+To use Docker Model Runner instead, see
+[Run Claude Code in a Docker Sandbox with Docker Model Runner](/guides/claude-code-sandbox-model-runner/).
diff --git a/content/manuals/ai/sandboxes/agents/codex.md b/content/manuals/ai/sandboxes/agents/codex.md
new file mode 100644
index 000000000000..fa72cf19fdcf
--- /dev/null
+++ b/content/manuals/ai/sandboxes/agents/codex.md
@@ -0,0 +1,86 @@
+---
+title: Codex
+weight: 20
+description: |
+  Use OpenAI Codex in Docker Sandboxes with API key authentication and YOLO
+  mode configuration.
+keywords: docker sandboxes, codex, openai, ai agent, sbx
+---
+
+This guide covers authentication, configuration, and usage of Codex in a
+sandboxed environment.
+
+Official documentation: [Codex CLI](https://developers.openai.com/codex/cli)
+
+## Quick start
+
+Create a sandbox and run Codex for a project directory:
+
+```console
+$ sbx run codex ~/my-project
+```
+
+The workspace parameter is optional and defaults to the current directory:
+
+```console
+$ cd ~/my-project
+$ sbx run codex
+```
+
+## Authentication
+
+If you haven't stored an OpenAI credential, `sbx run codex` prompts you to
+authenticate on your host before launching the sandbox. The flow runs on the
+host, so credentials are never exposed inside the sandbox.
+
+To set up authentication ahead of time, choose one of the following methods.
+
+**OAuth**: Start the OAuth flow on your host with:
+
+```console
+$ sbx secret set openai --oauth
+```
+
+This opens a browser window for authentication and stores the resulting tokens
+in your OS keychain. The OAuth flow runs on the host, not inside the sandbox,
+so browser-based authentication works without any extra setup.
+
+**API key**: Store your OpenAI API key using
+[stored secrets](../configuration/credentials.md#stored-secrets):
+
+```console
+$ sbx secret set openai
+```
+
+See [Credentials](../configuration/credentials.md) for more details.
+
+## Configuration
+
+Sandboxes don't pick up user-level configuration from your host, such as
+`~/.codex`. Only project-level configuration in the working directory is
+available inside the sandbox. See
+[Why doesn't the sandbox use my user-level agent configuration?](../faq.md#why-doesnt-the-sandbox-use-my-user-level-agent-configuration)
+for workarounds.
+
+### Default startup command
+
+Without extra args, the sandbox runs:
+
+```text
+codex --dangerously-bypass-approvals-and-sandbox
+```
+
+Arguments after `--` are added after the default flags when the first one is
+itself a flag (begins with `-`). A bare word — such as a prompt — replaces the
+defaults instead, so lead with the flag to keep bypass mode:
+
+```console
+$ sbx run codex -- --dangerously-bypass-approvals-and-sandbox "fix the build"
+```
+
+## Base image
+
+Template: `docker/sandbox-templates:codex`
+
+See [Customize](../customize/) to pre-install tools or customize this
+environment.
diff --git a/content/manuals/ai/sandboxes/agents/copilot.md b/content/manuals/ai/sandboxes/agents/copilot.md
new file mode 100644
index 000000000000..feb5b68b92b9
--- /dev/null
+++ b/content/manuals/ai/sandboxes/agents/copilot.md
@@ -0,0 +1,75 @@
+---
+title: Copilot
+weight: 30
+description: |
+  Use GitHub Copilot in Docker Sandboxes with GitHub token authentication and
+  trusted folder configuration.
+keywords: docker sandboxes, github copilot, ai agent, github token, sbx
+---
+
+This guide covers authentication, configuration, and usage of GitHub Copilot
+in a sandboxed environment.
+
+Official documentation: [GitHub Copilot CLI](https://docs.github.com/en/copilot/how-tos/copilot-cli)
+
+## Quick start
+
+Create a sandbox and run Copilot for a project directory:
+
+```console
+$ sbx run copilot ~/my-project
+```
+
+The workspace parameter is optional and defaults to the current directory:
+
+```console
+$ cd ~/my-project
+$ sbx run copilot
+```
+
+## Authentication
+
+Copilot requires a GitHub token with Copilot access. Store your token using
+[stored secrets](../configuration/credentials.md#stored-secrets):
+
+```console
+$ sbx secret set github --command 'gh auth token'
+```
+
+## Configuration
+
+Sandboxes don't pick up user-level configuration from your host. Only
+project-level configuration in the working directory is available inside the
+sandbox. See
+[Why doesn't the sandbox use my user-level agent configuration?](../faq.md#why-doesnt-the-sandbox-use-my-user-level-agent-configuration)
+for workarounds.
+
+Copilot is configured to trust the workspace directory by default, so it
+operates without repeated confirmations for workspace files.
+
+### Default startup command
+
+Without extra args, the sandbox runs:
+
+```text
+copilot --yolo
+```
+
+Arguments after `--` are added after the default flags when the first one is
+itself a flag (begins with `-`), so `--yolo` is preserved:
+
+```console
+$ sbx run copilot -- -p "review this PR"   # runs copilot --yolo -p "review this PR"
+```
+
+When the first argument is a bare word — a subcommand or prompt — it replaces
+the defaults instead.
+
+## Base image
+
+Template: `docker/sandbox-templates:copilot`
+
+Preconfigured to trust the workspace directory.
+
+See [Customize](../customize/) to pre-install tools or customize this
+environment.
diff --git a/content/manuals/ai/sandboxes/agents/cursor.md b/content/manuals/ai/sandboxes/agents/cursor.md
new file mode 100644
index 000000000000..0f4c3378c1f3
--- /dev/null
+++ b/content/manuals/ai/sandboxes/agents/cursor.md
@@ -0,0 +1,83 @@
+---
+title: Cursor
+weight: 40
+description: |
+  Use Cursor in Docker Sandboxes with API key or proxy-managed OAuth
+  authentication.
+keywords: docker sandboxes, cursor, cursor agent, ai agent, sbx
+---
+
+This guide covers authentication, configuration, and usage of Cursor in a
+sandboxed environment.
+
+Official documentation: [Cursor CLI](https://cursor.com/cli)
+
+## Quick start
+
+Create a sandbox and run Cursor for a project directory:
+
+```console
+$ sbx run cursor ~/my-project
+```
+
+The workspace parameter is optional and defaults to the current directory:
+
+```console
+$ cd ~/my-project
+$ sbx run cursor
+```
+
+## Authentication
+
+Cursor supports two authentication methods: an API key or OAuth.
+
+**API key**: Store your Cursor API key using
+[stored secrets](../configuration/credentials.md#stored-secrets):
+
+```console
+$ sbx secret set cursor
+```
+
+**OAuth**: If no API key is set, Cursor prompts you to sign in interactively
+on first run. The proxy intercepts the token exchange with
+`api2.cursor.sh/auth/poll`, so credentials are managed by the host and aren't
+stored inside the sandbox.
+
+## Configuration
+
+Sandboxes don't pick up user-level configuration from your host, such as
+`~/.cursor`. Only project-level configuration in the working directory is
+available inside the sandbox. See
+[Why doesn't the sandbox use my user-level agent configuration?](../faq.md#why-doesnt-the-sandbox-use-my-user-level-agent-configuration)
+for workarounds.
+
+Cursor reads `AGENTS.md` from the workspace for agent-specific instructions.
+
+### Default startup command
+
+Without extra args, the sandbox runs:
+
+```text
+cursor-agent --yolo
+```
+
+Arguments after `--` are added after the default flags when the first one is
+itself a flag (begins with `-`), so `--yolo` is preserved:
+
+```console
+$ sbx run cursor -- -p "refactor this"   # runs cursor-agent --yolo -p "refactor this"
+```
+
+When the first argument is a bare word — a subcommand or prompt — it replaces
+the defaults instead.
+
+## Base image
+
+Template: `docker/sandbox-templates:cursor-agent-docker`
+
+Preconfigured with HTTP/1.1 and server-sent events for agent traffic so
+requests flow through the host proxy. Authentication state is persisted across
+sandbox restarts.
+
+See [Customize](../customize/) to pre-install tools or customize this
+environment.
diff --git a/content/manuals/ai/sandboxes/agents/docker-agent.md b/content/manuals/ai/sandboxes/agents/docker-agent.md
new file mode 100644
index 000000000000..0839f7cb1477
--- /dev/null
+++ b/content/manuals/ai/sandboxes/agents/docker-agent.md
@@ -0,0 +1,70 @@
+---
+title: Docker Agent
+weight: 50
+description: |
+  Use Docker Agent in Docker Sandboxes with multi-provider authentication
+  supporting OpenAI, Anthropic, and more.
+keywords: docker sandboxes, docker agent, openai, anthropic, sbx
+---
+
+Official documentation: [Docker Agent](/manuals/ai/docker-agent/_index.md)
+
+## Quick start
+
+Create a sandbox and run Docker Agent for a project directory:
+
+```console
+$ sbx run docker-agent ~/my-project
+```
+
+The workspace parameter defaults to the current directory, so
+`sbx run docker-agent` from inside your project works too.
+
+## Authentication
+
+Docker Agent supports multiple providers. Store keys for the providers you want
+to use with [stored secrets](../configuration/credentials.md#stored-secrets):
+
+```console
+$ sbx secret set openai
+$ sbx secret set anthropic
+$ sbx secret set google
+$ sbx secret set xai
+$ sbx secret set nebius
+$ sbx secret set mistral
+$ sbx secret set openrouter
+```
+
+You only need to configure the providers you want to use. Docker Agent detects
+available credentials and routes requests to the appropriate provider.
+
+## Configuration
+
+Sandboxes don't pick up user-level configuration from your host. Only
+project-level configuration in the working directory is available inside the
+sandbox. See
+[Why doesn't the sandbox use my user-level agent configuration?](../faq.md#why-doesnt-the-sandbox-use-my-user-level-agent-configuration)
+for workarounds.
+
+### Default startup command
+
+Without extra args, the sandbox runs:
+
+```text
+docker-agent run --yolo
+```
+
+Arguments after `--` are added after the default flags when the first one is
+itself a flag (begins with `-`). When the first argument is a bare word — such
+as the `run` subcommand or a config file — it replaces the defaults, so include
+`run --yolo` yourself:
+
+```console
+$ sbx run docker-agent -- run --yolo agent.yml
+```
+
+## Base image
+
+The sandbox uses `docker/sandbox-templates:docker-agent`. See
+[Templates](../customize/templates.md) to build your own image on top of
+this base.
diff --git a/content/manuals/ai/sandboxes/agents/droid.md b/content/manuals/ai/sandboxes/agents/droid.md
new file mode 100644
index 000000000000..40bfaddb74c9
--- /dev/null
+++ b/content/manuals/ai/sandboxes/agents/droid.md
@@ -0,0 +1,72 @@
+---
+title: Droid
+weight: 60
+description: |
+  Use Droid in Docker Sandboxes with API key or OAuth authentication.
+keywords: docker sandboxes, droid, factory, ai agent, sbx
+---
+
+This guide covers authentication, configuration, and usage of Droid, an AI
+coding agent by Factory, in a sandboxed environment.
+
+Official documentation: [Droid](https://docs.factory.ai/)
+
+## Quick start
+
+Create a sandbox and run Droid for a project directory:
+
+```console
+$ sbx run droid ~/my-project
+```
+
+The workspace parameter is optional and defaults to the current directory:
+
+```console
+$ cd ~/my-project
+$ sbx run droid
+```
+
+## Authentication
+
+Droid requires a [Factory account](https://factory.ai). Both authentication
+methods authenticate you to Factory's service directly — unlike other agents
+where you supply a model provider key, Factory manages model access through
+your Factory account.
+
+**API key**: Store your Factory API key using
+[stored secrets](../configuration/credentials.md#stored-secrets):
+
+```console
+$ sbx secret set droid
+```
+
+**OAuth**: If no API key is set, Droid prompts you to authenticate
+interactively on first run. The proxy handles the OAuth flow, so credentials
+aren't stored inside the sandbox.
+
+## Configuration
+
+Sandboxes don't pick up user-level configuration from your host. Only
+project-level configuration in the working directory is available inside the
+sandbox. See
+[Why doesn't the sandbox use my user-level agent configuration?](../faq.md#why-doesnt-the-sandbox-use-my-user-level-agent-configuration)
+for workarounds.
+
+### Default startup command
+
+The sandbox runs `droid` with no implicit flags. Args after `--` are passed
+straight through:
+
+```console
+$ sbx run droid -- exec "fix the build"
+```
+
+## Base image
+
+Template: `docker/sandbox-templates:droid-docker`
+
+Preconfigured to run without approval prompts. Authentication state is
+persisted across sandbox restarts.
+
+See [Customize](../customize/) to pre-install tools or customize this
+environment.
diff --git a/content/manuals/ai/sandboxes/agents/gemini.md b/content/manuals/ai/sandboxes/agents/gemini.md
new file mode 100644
index 000000000000..156fd75de2c9
--- /dev/null
+++ b/content/manuals/ai/sandboxes/agents/gemini.md
@@ -0,0 +1,82 @@
+---
+title: Gemini
+weight: 70
+description: |
+  Use Google Gemini in Docker Sandboxes with proxy-managed authentication and
+  API key configuration.
+keywords: docker sandboxes, gemini, google, ai agent, sbx
+---
+
+This guide covers authentication, configuration, and usage of Google Gemini in
+a sandboxed environment.
+
+Official documentation: [Gemini CLI](https://geminicli.com/docs/)
+
+## Quick start
+
+Create a sandbox and run Gemini for a project directory:
+
+```console
+$ sbx run gemini ~/my-project
+```
+
+The workspace parameter is optional and defaults to the current directory:
+
+```console
+$ cd ~/my-project
+$ sbx run gemini
+```
+
+## Authentication
+
+Gemini requires either a Google API key or a Google account with Gemini access.
+
+**API key**: Store your key using
+[stored secrets](../configuration/credentials.md#stored-secrets):
+
+```console
+$ sbx secret set google
+```
+
+**Google account**: If no API key is set, Gemini prompts you to sign in
+interactively when it starts. Interactive authentication is scoped to the
+sandbox and doesn't persist if you remove and recreate it.
+
+## Configuration
+
+Sandboxes don't pick up user-level configuration from your host, such as
+`~/.gemini`. Only project-level configuration in the working directory is
+available inside the sandbox. See
+[Why doesn't the sandbox use my user-level agent configuration?](../faq.md#why-doesnt-the-sandbox-use-my-user-level-agent-configuration)
+for workarounds.
+
+The sandbox disables Gemini's built-in sandbox tool (since the sandbox itself
+provides isolation).
+
+### Default startup command
+
+Without extra args, the sandbox runs:
+
+```text
+gemini --yolo
+```
+
+Arguments after `--` are added after the default flags when the first one is
+itself a flag (begins with `-`), so `--yolo` is preserved:
+
+```console
+$ sbx run gemini -- -p "explain this"   # runs gemini --yolo -p "explain this"
+```
+
+When the first argument is a bare word — a subcommand or prompt — it replaces
+the defaults instead.
+
+## Base image
+
+Template: `docker/sandbox-templates:gemini`
+
+Gemini is configured to disable its built-in OAuth flow. Authentication is
+managed through the proxy with API keys.
+
+See [Customize](../customize/) to pre-install tools or customize this
+environment.
diff --git a/content/manuals/ai/sandboxes/agents/kiro.md b/content/manuals/ai/sandboxes/agents/kiro.md
new file mode 100644
index 000000000000..b9d7bc6940ab
--- /dev/null
+++ b/content/manuals/ai/sandboxes/agents/kiro.md
@@ -0,0 +1,106 @@
+---
+title: Kiro
+weight: 80
+description: |
+  Use Kiro in Docker Sandboxes with device flow authentication for interactive
+  AI-assisted development.
+keywords: docker sandboxes, kiro, ai agent, authentication, sbx
+---
+
+This guide covers authentication, configuration, and usage of Kiro in a
+sandboxed environment.
+
+Official documentation: [Kiro CLI](https://kiro.dev/docs/cli/)
+
+## Quick start
+
+Create a sandbox and run Kiro for a project directory:
+
+```console
+$ sbx run kiro ~/my-project
+```
+
+The workspace parameter is optional and defaults to the current directory:
+
+```console
+$ cd ~/my-project
+$ sbx run kiro
+```
+
+On first run, Kiro prompts you to authenticate using device flow.
+
+## Authentication
+
+Kiro uses device flow authentication, which requires interactive login through
+a web browser. This method provides secure authentication without storing API
+keys directly.
+
+### Device flow login
+
+When you first run Kiro, it prompts you to authenticate:
+
+1. Kiro displays a URL and a verification code
+2. Open the URL in your web browser
+3. Enter the verification code
+4. Complete the authentication flow in your browser
+5. Return to the terminal - Kiro proceeds automatically
+
+The authentication session is persisted in the sandbox and doesn't require
+repeated login unless you destroy and recreate the sandbox.
+
+### Manual login
+
+You can trigger the login flow manually:
+
+```console
+$ sbx run kiro --name <sandbox-name> -- login --use-device-flow
+```
+
+This command initiates device flow authentication without starting a coding
+session.
+
+### Authentication persistence
+
+Kiro stores authentication state in `~/.local/share/kiro-cli/data.sqlite3`
+inside the sandbox. This database persists as long as the sandbox exists. If
+you destroy the sandbox, you'll need to authenticate again when you recreate
+it.
+
+## Configuration
+
+Sandboxes don't pick up user-level configuration from your host. Only
+project-level configuration in the working directory is available inside the
+sandbox. See
+[Why doesn't the sandbox use my user-level agent configuration?](../faq.md#why-doesnt-the-sandbox-use-my-user-level-agent-configuration)
+for workarounds.
+
+Kiro requires minimal configuration. The agent runs with trust-all-tools mode
+by default, which lets it execute commands without repeated approval prompts.
+
+### Default startup command
+
+Without extra args, the sandbox runs:
+
+```text
+kiro chat --trust-all-tools
+```
+
+When the first argument after `--` is a flag (begins with `-`), it's added
+after the defaults — for example, `sbx run kiro -- --resume` runs
+`kiro chat --trust-all-tools --resume`. When the first argument is a bare word,
+it replaces the defaults, which is why `sbx run kiro -- login --use-device-flow`
+runs the login subcommand on its own. To run `chat` with extra arguments of
+your own, include the subcommand:
+
+```console
+$ sbx run kiro -- chat --trust-all-tools --resume
+```
+
+## Base image
+
+Template: `docker/sandbox-templates:kiro`
+
+Authentication state is persisted across sandbox restarts.
+
+See [Customize](../customize/) to pre-install tools or customize this
+environment.
diff --git a/content/manuals/ai/sandboxes/agents/opencode.md b/content/manuals/ai/sandboxes/agents/opencode.md
new file mode 100644
index 000000000000..fa192b3ca82e
--- /dev/null
+++ b/content/manuals/ai/sandboxes/agents/opencode.md
@@ -0,0 +1,119 @@
+---
+title: OpenCode
+weight: 90
+description: |
+  Use OpenCode in Docker Sandboxes with multi-provider authentication and TUI
+  interface for AI development.
+keywords: docker sandboxes, opencode, ai agent, authentication, sbx
+---
+
+This guide covers authentication, configuration, and usage of OpenCode in a
+sandboxed environment.
+
+Official documentation: [OpenCode](https://opencode.ai/docs)
+
+## Quick start
+
+Create a sandbox and run OpenCode for a project directory:
+
+```console
+$ sbx run opencode ~/my-project
+```
+
+The workspace parameter is optional and defaults to the current directory:
+
+```console
+$ cd ~/my-project
+$ sbx run opencode
+```
+
+OpenCode launches a TUI (text user interface) where you can select your
+preferred LLM provider and interact with the agent.
+
+## Authentication
+
+OpenCode supports multiple providers. Store keys for the providers you want to
+use with [stored secrets](../configuration/credentials.md#stored-secrets):
+
+```console
+$ sbx secret set openai
+$ sbx secret set anthropic
+$ sbx secret set google
+$ sbx secret set xai
+$ sbx secret set groq
+$ sbx secret set aws
+$ sbx secret set openrouter
+```
+
+You only need to configure the providers you want to use. OpenCode detects
+available credentials and offers those providers in the TUI.
+
+### OpenCode Zen API keys
+
+OpenCode Zen API keys aren't part of the built-in OpenCode credentials that
+`sbx secret set` supports. To use an OpenCode Zen API key, store it as a
+[custom secret](../configuration/credentials.md#custom-secrets):
+
+Set the `OPENCODE_API_KEY` environment variable on the host, then store it:
+
+```console
+$ sbx secret set-custom \
+    --host opencode.ai \
+    --env OPENCODE_API_KEY \
+    --value "$OPENCODE_API_KEY"
+```
+
+Custom secrets keep the real key in the host secret store. The sandbox receives
+`OPENCODE_API_KEY` as a placeholder, and the host-side proxy replaces that
+placeholder with the real key on requests to `opencode.ai`.
+
+OpenCode Zen also requires network access to `opencode.ai`:
+
+```console
+$ sbx policy allow network opencode.ai:443
+```
+
+If you add a global custom secret, recreate existing OpenCode sandboxes so the
+new environment variable is available inside the sandbox.
+
+## Configuration
+
+Sandboxes don't pick up user-level configuration from your host. Only
+project-level configuration in the working directory is available inside the
+sandbox. See
+[Why doesn't the sandbox use my user-level agent configuration?](../faq.md#why-doesnt-the-sandbox-use-my-user-level-agent-configuration)
+for workarounds.
+
+OpenCode uses a TUI interface and doesn't require extensive configuration
+files. The agent prompts you to select a provider when it starts, and you can
+switch providers during a session.
+
+### Default startup command
+
+The sandbox runs `opencode` with no implicit flags. Args after `--` are passed
+straight through. For example, to resume an existing session:
+
+```console
+$ sbx run opencode -- -s <session-id>
+```
+
+### TUI mode
+
+OpenCode launches in TUI mode by default. The interface shows:
+
+- Available LLM providers (based on configured credentials)
+- Current conversation history
+- File operations and tool usage
+- Real-time agent responses
+
+Use keyboard shortcuts to navigate the interface and interact with the agent.
+
+## Base image
+
+Template: `docker/sandbox-templates:opencode`
+
+OpenCode supports multiple LLM providers with automatic credential injection
+through the sandbox proxy.
+
+See [Customize](../customize/) to pre-install tools or customize this
+environment.
diff --git a/content/manuals/ai/sandboxes/agents/shell.md b/content/manuals/ai/sandboxes/agents/shell.md
new file mode 100644
index 000000000000..70c0ac8b63c0
--- /dev/null
+++ b/content/manuals/ai/sandboxes/agents/shell.md
@@ -0,0 +1,53 @@
+---
+title: Shell
+weight: 100
+description: Run an agent-less sandbox with a Bash login shell for manual setup, testing custom agent implementations, or inspecting a running environment.
+keywords: sandboxes, sbx, shell, agent, manual setup, testing
+---
+
+`sbx run shell` drops you into a Bash login shell inside a sandbox with no
+pre-installed agent binary. It's useful for installing and configuring
+agents manually, testing custom implementations, or inspecting a running
+environment.
+
+```console
+$ sbx run shell ~/my-project
+```
+
+The workspace path defaults to the current directory. To run a one-off
+command instead of an interactive shell, pass it after `--`:
+
+```console
+$ sbx run shell -- -c "echo 'Hello from sandbox'"
+```
+
+## Default startup command
+
+Without extra args, the sandbox runs `bash -l`. When the first argument after
+`--` is a flag (begins with `-`), it's added after `-l`, so login-shell
+behavior is preserved:
+
+```console
+$ sbx run shell -- -c "echo hi"   # runs bash -l -c "echo hi"
+```
+
+When the first argument is a bare word, it replaces `-l` instead.
+
+Store credentials using [stored secrets](../configuration/credentials.md#stored-secrets)
+before running the sandbox. The proxy injects them into outbound API requests;
+credentials are never stored inside the VM:
+
+```console
+$ sbx secret set anthropic
+$ sbx secret set openai
+```
+
+Once inside the shell, you can install agents using their standard methods,
+for example `npm install -g @continuedev/cli`. For complex setups, build a
+[custom template](../customize/templates.md) instead of installing
+interactively each time.
+
+## Base image
+
+The shell sandbox uses the `shell` base image — the common base environment
+without a pre-installed agent.
diff --git a/content/manuals/ai/sandboxes/architecture.md b/content/manuals/ai/sandboxes/architecture.md
new file mode 100644
index 000000000000..88c8da4bdebe
--- /dev/null
+++ b/content/manuals/ai/sandboxes/architecture.md
@@ -0,0 +1,123 @@
+---
+title: Architecture
+weight: 100
+description: Technical architecture of Docker Sandboxes; workspace mounting, storage, networking, and sandbox lifecycle.
+keywords: docker sandboxes, architecture, microVM, workspace mounting, sandbox lifecycle
+---
+
+This page explains how Docker Sandboxes work under the hood. For the security
+properties of the architecture, see [Sandbox isolation](security/isolation.md).
+
+## Workspace mounting
+
+Your workspace is mounted directly into the sandbox through a filesystem
+passthrough. The sandbox sees your actual host files, so changes in either
+direction are instant with no sync process involved.
+
+Your workspace is mounted at the same absolute path as on your host. Preserving
+absolute paths means error messages, configuration files, and build outputs all
+reference paths you can find on your host. The agent sees exactly the directory
+structure you see, which reduces confusion when debugging or reviewing changes.
+
+> [!WARNING]
+> Avoid mounting network-attached or remote storage (network drives, SMB/NFS
+> shares, or cloud-synced folders) as a workspace. The sandbox accesses
+> workspaces through a filesystem passthrough, so every file read and write
+> goes over the network. This adds latency and slows agent performance.
+
+## Storage and persistence
+
+When you create a sandbox, everything inside it persists until you remove it:
+Docker images and containers built or pulled by the agent, installed packages,
+agent state and history, and workspace changes.
+
+Each sandbox maintains its own Docker daemon state, image cache, and package
+installations. Multiple sandboxes don't share images or layers. The
+[shared agent skills store](workflows/agent-skills.md) is an exception:
+supported agents mount the same host-side store read-write unless you opt out
+when creating the sandbox.
+
+Each sandbox consumes disk space for its VM image, Docker images, container
+layers, and volumes, and this grows as you build images and install packages.
+
+Virtiofs caching is enabled by default on all operating systems. File reads
+from the sandbox VM are cached on the host side, reducing round-trips through
+the filesystem passthrough and improving performance for read-heavy workloads
+such as `git status` or directory scans. To opt out, set
+`DOCKER_SANDBOXES_ENABLE_VIRTIOFS_CACHE=0` when creating the sandbox:
+
+```console
+$ DOCKER_SANDBOXES_ENABLE_VIRTIOFS_CACHE=0 sbx run <template>
+```
+
+## Networking
+
+All outbound TCP traffic from the sandbox routes through a proxy on your host.
+Agents use a forward proxy for HTTP and HTTPS; other TCP traffic is forwarded
+transparently. Both paths enforce
+[network access policies](governance/access-controls/network.md). The forward
+proxy also handles [credential injection](configuration/credentials.md). See
+[Network isolation](security/isolation.md#network-isolation) for how this
+works and [Default security posture](security/defaults.md) for what is
+allowed out of the box.
+
+### Upstream proxy
+
+The host-side proxy makes its outbound connections using your host's network
+configuration and routing. When a destination is reachable through a direct
+route, traffic follows that route. When reaching a destination requires an
+upstream proxy, the host-side proxy forwards the request to it. Chaining to an
+upstream proxy means sandbox traffic respects the same egress controls as other
+applications on your host.
+
+By default, both sandbox traffic and the daemon's own traffic follow your OS
+system proxy, so this usually works without any configuration. To set a proxy
+explicitly — with a proxy URL, a PAC file, a SOCKS5 proxy, or separate settings
+for sandbox and daemon traffic — see
+[Configure an upstream proxy](configuration/upstream-proxy.md). Upstream proxy support is
+experimental and subject to change.
+
+Only HTTP and HTTPS traffic can be forwarded to an upstream proxy. Other TCP
+traffic can't be redirected to a proxy.
+
+## MCP gateway
+
+Supported agents connect to a single MCP gateway endpoint for the sandbox. The
+gateway runs on the host side of the sandbox boundary and brokers access to
+registered MCP servers.
+
+Registered MCP servers can be remote endpoints, or they can be local stdio
+servers launched on the host. Local stdio servers don't run inside the sandbox
+VM. If a local stdio server is packaged as an OCI image, or if you register an
+explicit `docker` command, it uses Docker on the host.
+
+When MCP policies apply, enforcement happens on the MCP gateway path, separate
+from the HTTP/HTTPS network proxy. Server registration is checked before the
+server is stored, and governed MCP requests are checked by the gateway before
+tool calls, resource reads, prompt retrieval, or gateway meta-tool execution.
+
+## Lifecycle
+
+`sbx run` initializes a VM with a workspace for a specified agent and starts
+the agent. You can stop and restart without recreating the VM, preserving
+installed packages and Docker images.
+
+Sandboxes persist until explicitly removed. Stopping an agent doesn't delete
+the VM; environment setup carries over between runs. Use `sbx rm` to delete
+the sandbox, its VM, and all of its contents. If the sandbox used
+[`--clone`](usage.md#clone-mode), the `sandbox-<name>` Git remote is also
+removed from your host repository.
+
+## Comparison to alternatives
+
+| Approach                                            | Isolation            | Docker access      | Use case           |
+| --------------------------------------------------- | -------------------- | ------------------ | ------------------ |
+| Sandboxes (microVMs)                                | Full (hypervisor)    | Isolated daemon    | Autonomous agents  |
+| Container with socket mount                         | Partial (namespaces) | Shared host daemon | Trusted tools      |
+| [Docker-in-Docker](https://hub.docker.com/_/docker) | Partial (privileged) | Nested daemon      | CI/CD pipelines    |
+| Host execution                                      | None                 | Host daemon        | Manual development |
+
+Sandboxes trade higher resource overhead (a VM plus its own daemon) for
+complete isolation. Use containers when you need lightweight packaging without
+Docker access. Use sandboxes when you need to give something autonomous full
+Docker capabilities without trusting it with your host environment.
diff --git a/content/manuals/ai/sandboxes/configuration/_index.md b/content/manuals/ai/sandboxes/configuration/_index.md
new file mode 100644
index 000000000000..31d09f14b143
--- /dev/null
+++ b/content/manuals/ai/sandboxes/configuration/_index.md
@@ -0,0 +1,21 @@
+---
+title: Configure Docker Sandboxes
+linkTitle: Configuration
+weight: 60
+description: Configure credentials, project environments, GPU passthrough, and upstream proxy settings for Docker Sandboxes.
+keywords: docker sandboxes, sbx, configuration, credentials, environment files, gpu passthrough, upstream proxy
+---
+
+Configure credentials and how Docker Sandboxes run for a project, host, or
+network environment. These settings control sandbox creation, authentication,
+and connectivity. To change the tools and agent configuration inside a
+sandbox, see [Customize](../customize/).
+
+- [Credentials](credentials.md) configures API keys, authentication
+  credentials, and registry access for sandboxed agents.
+- [Environment files](environment-files.md) declare reusable project
+  configuration in `.sbxenv.yaml`.
+- [GPU passthrough](gpu-passthrough.md) configures a Linux host and sandbox for
+  NVIDIA GPU workloads.
+- [Upstream proxy](upstream-proxy.md) routes sandbox and daemon traffic through
+  an operating system or corporate proxy.
diff --git a/content/manuals/ai/sandboxes/configuration/credentials.md b/content/manuals/ai/sandboxes/configuration/credentials.md
new file mode 100644
index 000000000000..9c28102d19aa
--- /dev/null
+++ b/content/manuals/ai/sandboxes/configuration/credentials.md
@@ -0,0 +1,554 @@
+---
+title: Manage credentials
+linkTitle: Credentials
+weight: 10
+description: How Docker Sandboxes handle API keys and authentication credentials for sandboxed agents.
+keywords: docker sandboxes, credentials, api keys, authentication, proxy, ssh agent, secrets
+aliases:
+  - /ai/sandboxes/security/credentials/
+---
+
+Most agents need an API key for their model provider. An HTTP/HTTPS proxy on
+your host intercepts outbound requests from the sandbox, looks up the matching
+credential on the host, and overwrites the auth header before forwarding. The
+real credential stays on the host when proxy management is active; the sandbox
+sees only a sentinel value. See
+[Trust boundaries](../security/_index.md#trust-boundaries) for how credential isolation
+fits into the broader sandbox security model.
+
+## How credential injection works
+
+When a sandbox makes an outbound request, the host-side proxy decides three
+things: whether the request **matches** a service the kit (or built-in agent)
+declares, what **header** to write, and what **value** to inject. The kit
+declares the match and the header; you provide the value on the host. For
+proxy-managed credentials, the real value never enters the sandbox — the agent
+sees only a sentinel like `proxy-managed`.
+
+A kit can set OAuth `passthrough: true` to opt out of sentinel masking. This
+sends the real token response into the sandbox and reduces credential isolation.
+See the [`oauth` kit fields](../customize/kit-reference.md#oauth).
+
+There are several ways to provide that value. When more than one source has a
+value for the same service, the stored secret takes precedence.
+
+| Form                                                                        | What it is                                                   | Use it when                                                                                                      |
+| --------------------------------------------------------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- |
+| [Stored secrets](#stored-secrets) (`sbx secret set`)                        | A value or dynamic source in your OS keychain, keyed by service | The default for any built-in or kit-declared service                                                          |
+| [Custom secrets](#custom-secrets) (`sbx secret set-custom`)                 | A value keyed to a domain and environment variable           | The service model doesn't fit — the agent validates the variable's format, or the secret rides in a request body |
+| OAuth                                                                       | A host-side sign-in flow; the token never enters the sandbox | The agent supports it, such as Claude Code, Codex, Cursor, or Droid                                              |
+| [Credential bindings](#credential-bindings) (`credentials.yaml`)            | Per-service mechanism and domain approval                    | Required for third-party `schemaVersion: "2"` kits                                                               |
+| [Registry credentials](#registry-credentials) (`sbx secret set --registry`) | Authentication for pulling images and kits                   | Pulling templates or kits from a private registry                                                                |
+
+For multi-provider agents (OpenCode, Docker Agent), the proxy selects
+credentials based on the API endpoint being called. See individual
+[agent pages](../agents/) for provider-specific details.
+
+## Stored secrets
+
+`sbx secret set` stores credential values or dynamic secret sources in your OS
+keychain, keyed on a service identifier. Built-in agents declare a fixed set of
+services. Custom kits can declare their own. The same `sbx secret set` flow
+works for both.
+
+### Where secrets are stored
+
+The store backing `sbx secret set` depends on your operating system:
+
+- macOS: the system Keychain.
+- Windows: the Windows Credential Manager.
+- Linux: the Secret Service exposed by your desktop keyring, such as GNOME
+  Keyring or KDE Wallet.
+
+The Ubuntu package depends on GNOME Keyring, so a standard desktop install
+needs no extra setup.
+
+On Linux hosts without a running Secret Service — headless servers and some WSL
+setups — `sbx` falls back to a file under your user config directory
+`$XDG_CONFIG_HOME/com.docker.sandboxes`, which defaults to
+`~/.config/com.docker.sandboxes` when `$XDG_CONFIG_HOME` is unset. The fallback
+is automatic and needs no configuration. When you store a secret this way,
+`sbx` prints a notice:
+
+```text
+No keychain detected - this secret will be stored on disk, protected by file permissions rather than a password
+```
+
+`sbx` stores the file in a directory with `0700` permissions, the same
+file-permission model used for `~/.docker/config.json`. Any user or process that
+can read the file can retrieve the stored credentials, so treat the directory as
+sensitive. Where available, prefer a keychain, which mediates access per
+application.
+
+If you start a Secret Service on the host later, `sbx` stores new secrets in the
+keychain again. For more on running sandboxes without a desktop keyring, see
+[Can I use Docker Sandboxes on headless Linux?](../faq.md#can-i-use-docker-sandboxes-on-headless-linux)
+
+### Store a secret
+
+```console
+$ sbx secret set anthropic
+```
+
+This prompts you for the secret value interactively. Service secrets are
+global by default, so the secret is available to all sandboxes. To scope a
+secret to a specific sandbox instead:
+
+```console
+$ sbx secret set openai --sandbox my-sandbox
+```
+
+> [!NOTE]
+> A sandbox-scoped secret takes effect immediately, even if the sandbox is
+> running. A global secret only applies when a sandbox is created. If
+> you set or change a global secret while a sandbox is running, recreate the
+> sandbox for the new value to take effect.
+
+### Use a dynamic secret source
+
+Dynamic secret sources let `sbx` retrieve a credential from an authenticated
+host tool when the proxy needs it. The secret store contains the reference or
+command instead of the credential value. Resolution and caching happen on the
+host, and the sandbox still receives only the proxy-managed placeholder.
+
+Use `--ref` with a 1Password secret reference or an AWS Secrets Manager ARN:
+
+```console
+$ sbx secret set anthropic --ref 'op://Work/Anthropic/credential'
+$ sbx secret set openai \
+    --ref 'arn:aws:secretsmanager:us-west-2:123456789012:secret:openai-api-key'
+```
+
+The corresponding `op` or `aws` CLI must be installed and authenticated on the
+host.
+
+> [!NOTE]
+> To resolve a reference with a specific 1Password account or AWS profile, set
+> `OP_ACCOUNT` or `AWS_PROFILE` when you run `sbx secret set`. `sbx` uses that
+> account or profile whenever it resolves the secret. If neither variable is
+> set, the provider CLI uses its default.
+
+Use `--command` for another host tool that prints a secret to standard output:
+
+```console
+$ sbx secret set github --command 'gh auth token'
+```
+
+`sbx` runs the command through the host shell and trims its output. The command
+text is stored and replayed by the daemon. Don't embed a secret directly in the
+command because the text can appear in shell history and process listings.
+
+By default, `sbx` verifies the source when you register it and reports an error
+without exposing the resolver's standard error. Use `--no-verify` to store a
+source that can't be resolved during registration. To troubleshoot an initial
+verification failure, use `--show-error`. Provider error output can contain
+sensitive information. You can't combine `--show-error` with `--no-verify`.
+
+Resolved service secrets are cached for 55 minutes by default. To change the
+cache duration, use `--refresh <duration>`. To resolve the source for every
+credential use instead of caching it, pass `--refresh on-demand`:
+
+```console
+$ sbx secret set anthropic \
+    --ref 'op://Work/Anthropic/credential' \
+    --refresh 30m
+$ sbx secret set github --command 'gh auth token' --refresh on-demand
+```
+
+`--ref` and `--command` are mutually exclusive. They can't be combined with
+`--token`, `--oauth`, or `--registry`.
+
+### Import from environment variables
+
+If you already have API keys set in your shell, `sbx secret import` reads them
+and stores them in the keychain without typing each value manually:
+
+```console
+$ sbx secret import
+```
+
+This scans your current session for the environment variables in the
+[built-in services table](#built-in-services) below and prompts you to confirm
+each one before writing. To import a single service:
+
+```console
+$ sbx secret import openai
+```
+
+Pass `--all` to import everything without prompting (new entries only; existing
+entries are left unchanged), or `--force` to overwrite existing entries:
+
+```console
+$ sbx secret import --all
+$ sbx secret import openai --force
+```
+
+Pass `--dry-run` to preview what would be imported without writing anything.
+Run `sbx secret ls` afterwards to confirm what's stored. For setting up
+credentials in CI, see [CI and headless use](../workflows/automation.md).
+
+### Built-in services
+
+Each built-in service name maps to the environment variables `sbx secret import`
+reads and the API domains the proxy injects credentials into:
+
+| Service      | Environment variables              | API domains                                                                                                                   |
+| ------------ | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
+| `anthropic`  | `ANTHROPIC_API_KEY`                | `api.anthropic.com`, `console.anthropic.com`, `claude.ai`, `mcp-proxy.anthropic.com`                                          |
+| `cursor`     | `CURSOR_API_KEY`                   | `api2.cursor.sh`, `api3.cursor.sh`, `repo42.cursor.sh`, `cursor.com`                                                          |
+| `droid`      | `FACTORY_API_KEY`                  | `api.factory.ai`, `app.factory.ai`, `relay.factory.ai`                                                                        |
+| `github`     | `GH_TOKEN`, `GITHUB_TOKEN`         | `api.github.com`, `github.com`, `raw.githubusercontent.com`, `gist.github.com`, `copilot.github.com`, `api.githubcopilot.com` |
+| `google`     | `GEMINI_API_KEY`, `GOOGLE_API_KEY` | `generativelanguage.googleapis.com`, `oauth2.googleapis.com`, `aiplatform.googleapis.com`, `vertexai.googleapis.com`          |
+| `groq`       | `GROQ_API_KEY`                     | `api.groq.com`                                                                                                                |
+| `mistral`    | `MISTRAL_API_KEY`                  | `api.mistral.ai`                                                                                                              |
+| `nebius`     | `NEBIUS_API_KEY`                   | `api.studio.nebius.com`, `api.tokenfactory.nebius.com`                                                                        |
+| `openai`     | `OPENAI_API_KEY`                   | `api.openai.com`, `openai.com`, `chatgpt.com`, `www.chatgpt.com`                                                              |
+| `openrouter` | `OPENROUTER_API_KEY`               | `openrouter.ai`                                                                                                               |
+| `xai`        | `XAI_API_KEY`                      | `api.x.ai`                                                                                                                    |
+
+When you store a secret with `sbx secret set <service>`, the proxy injects
+it into requests to the listed API domains.
+
+### Services declared by kits
+
+Custom kits can declare their own service identifiers in `spec.yaml`. In
+`schemaVersion: "2"`, credentials are declared under the `credentials:` list:
+
+```yaml
+credentials:
+  - service: my-service
+    apiKey:
+      name: MY_SERVICE_TOKEN
+      proxyManaged: true
+      inject:
+        - domain: api.my-service.com
+          scheme: bearer
+```
+
+Each service declares `apiKey`, `oauth`, or both. When both resolve at runtime,
+the API key takes precedence and OAuth acts as the fallback. To provide the
+credential value, run `sbx secret set` with the same identifier the kit
+declares:
+
+```console
+$ sbx secret set my-service
+```
+
+There's no separate registration step; the keychain entry is keyed on the
+identifier the kit already uses. See
+[Authenticate to external services](../customize/kits.md#authenticate-to-external-services)
+for the full kit-side wiring.
+
+### List and remove secrets
+
+List all stored secrets:
+
+```console
+$ sbx secret ls
+SCOPE      TYPE      NAME      SECRET
+(global)   service   github    gho_GCaw4o****...****43qy
+```
+
+Remove a secret:
+
+```console
+$ sbx secret rm github
+```
+
+> [!NOTE]
+> Running `sbx reset` deletes all stored secrets along with all sandbox state.
+> You'll need to re-add your secrets after a reset.
+
+### GitHub token
+
+The `github` service gives the agent access to the `gh` CLI inside the
+sandbox. Resolve your existing GitHub CLI token on the host:
+
+```console
+$ sbx secret set github --command 'gh auth token'
+```
+
+The daemon refreshes the token from the host command after the default cache
+period. This is useful for agents that create pull requests, open issues, or
+interact with GitHub APIs on your behalf.
+
+### SSH agent
+
+If your host has an SSH agent and `SSH_AUTH_SOCK` is set, Docker Sandboxes
+forwards the agent into the sandbox and sets `SSH_AUTH_SOCK` there. The
+private keys stay on your host. Processes inside the sandbox can request
+signatures from the forwarded agent, but they can't read or copy the private
+key.
+
+Use SSH agent forwarding for Git operations over SSH and SSH-based commit
+signing. The signing key must be loaded in the host SSH agent for sandboxed
+commit signing to work. Outbound SSH connections are still subject to sandbox
+network policy. For details, see
+[Commit signing](../workflows/git.md#commit-signing).
+
+## Custom secrets
+
+> [!IMPORTANT]
+> Custom secrets are experimental. Behavior, flags, and the placeholder format may
+> change without notice.
+
+For credentials that don't fit the service-identifier model — for example,
+when an agent validates the environment variable format at boot, or when the
+credential lands in a request body rather than a header — use
+`sbx secret set-custom`. The secret is keyed on one or more target domains, an
+environment variable name, and an optional placeholder string, instead of a
+service identifier. Custom secrets are global by default. Pass `--sandbox` to
+scope one to a specific sandbox.
+
+```console
+$ sbx secret set-custom \
+    --host api.example.com \
+    --env API_KEY \
+    --value <secret>
+```
+
+Repeat `--host` to cover multiple domains with the same secret — useful when
+an API is split across related hostnames or when two unrelated endpoints share
+a credential:
+
+```console
+$ sbx secret set-custom \
+    --host api.example.com \
+    --host uploads.example.com \
+    --env API_KEY \
+    --value <secret>
+```
+
+A `--host` value can also use wildcards, with the same syntax as
+[network rules](../governance/concepts.md#network-rules): `*` matches a
+single label (`*.example.com` covers `api.example.com`) and `**` matches any
+number (`**.example.com` covers `api.example.com` and `v2.api.example.com`).
+
+Custom secrets also accept [dynamic secret sources](#use-a-dynamic-secret-source).
+Replace `--value` with either `--ref` or `--command`:
+
+```console
+$ sbx secret set-custom \
+    --host api.example.com \
+    --env API_KEY \
+    --ref 'op://Work/Example/credential'
+```
+
+Dynamic custom secrets resolve on demand by default. Pass `--refresh` with a
+duration to cache the resolved value. The verification and error-output flags
+work the same as they do for service secrets. `--ref` and `--command` can't be
+combined with `--value` or `--token`.
+
+> [!WARNING]
+> Passing the secret as `--value <secret>` records it in your shell history
+> and exposes it to other processes running as your user. Avoid pasting
+> real credentials inline — read the value from a variable that's already
+> in your environment, and clear shell history if a real secret was passed
+> on the command line.
+
+Inside the sandbox, `API_KEY` is set to a generated placeholder (for example,
+`sbx-cs-<rand>`). When a sandboxed process sends a request to any of the
+configured hosts and the placeholder appears anywhere in the request, the
+proxy replaces it with the real value. The agent never sees the real secret.
+
+Prefer the [service-based flow](#stored-secrets) whenever it's an option —
+the kit handles the wiring; you only provide the value.
+
+## Credential bindings
+
+A credential bindings file records which credential mechanisms and domains
+you've approved for each service. It lives at
+`~/.config/sbx/credentials.yaml`, or `%APPDATA%\sbx\credentials.yaml` on
+Windows.
+
+Third-party kits that declare `schemaVersion: "2"` require an approved binding
+for each credential they use. `sbx` creates one interactively the first time you
+run such a kit (see [First-run approval](#first-run-approval)); you can also
+write entries by hand. Credentials declared only by embedded, built-in kits are
+authorized by provenance and don't need a binding.
+
+Each entry under `bindings` is keyed by a
+[service identifier](#built-in-services) and approves one or both credential
+mechanisms:
+
+- `apiKey` — approves injecting the service's stored API key. The value comes
+  from the [secret store](#stored-secrets) (`sbx secret set <service>`); the
+  binding records approval, it doesn't hold or locate the value.
+- `oauth` — approves the OAuth flow for the service. You sign in on the host,
+  and the proxy handles token refresh and routing. OAuth domains include the
+  token endpoint host and any resource hosts declared by the kit.
+
+Each mechanism takes a `domains` list that records the domains you approved.
+`sbx` asks for approval when a kit requests domains that the existing binding
+doesn't cover.
+
+```yaml
+bindings:
+  anthropic:
+    apiKey:
+      domains: [api.anthropic.com]
+  github:
+    apiKey:
+      domains: [api.github.com, github.com]
+```
+
+A binding is only an approval record: the presence of `apiKey` or `oauth`
+authorizes that mechanism. Declining a credential writes no entry at all.
+The real credential isn't stored in this file.
+
+### First-run approval
+
+When a third-party kit needs a credential that has no binding, `sbx` walks you
+through approving one. For an API key, you can use a value already in the secret
+store or enter one at the prompt. For OAuth, you approve the sign-in flow. In
+both cases, you approve the domains declared by the kit. `sbx` writes the entry
+to `credentials.yaml`.
+
+In non-interactive contexts (CI or `--detached`), there's no one to answer the
+prompt. Without a binding, the sandbox starts with the credential withheld. If
+the kit marks the credential as `required: true`, `sbx` also prints a warning.
+Pre-create the binding by running the kit interactively once or by writing
+`credentials.yaml` directly before running unattended.
+
+The bindings file gates whether a third-party v2 kit can use a service
+credential. The kit's credential injection rules and network permissions still
+constrain which requests can carry the credential.
+
+### Kits that require a binding
+
+Only third-party kits that declare `schemaVersion: "2"` require a binding.
+Built-in agents also use `schemaVersion: "2"`, but credentials declared only by
+embedded kits are authorized by provenance and inject automatically. A
+third-party kit that extends a built-in agent inherits its credentials, but not
+its built-in provenance. The inherited credentials therefore require approval.
+If a third-party kit declares the same service itself, that service also
+requires approval. Kits on `schemaVersion: "1"` inject their declared
+credentials without a binding.
+
+> [!WARNING]
+> Proxy-managed OAuth isn't supported for third-party sandbox agents, including
+> kits that extend a built-in agent. Repeating the parent's OAuth declaration in
+> the child kit doesn't activate OAuth interception. Use a stored API key when
+> the service supports one. Otherwise, an OAuth login performed inside the
+> sandbox stores the real token there.
+
+## Registry credentials
+
+Registry credentials authenticate to private OCI registries when pulling
+[templates](../customize/templates.md) or [kits](../customize/kits.md), and can
+also let the agent pull and push images from inside the sandbox through the
+host-side proxy. Use `sbx secret set --registry <host>` to store them. For
+Docker Hub, `sbx` reuses your `sbx login` session — no registry secret needed.
+For other registries (GitHub Container Registry, ECR, ACR, self-hosted Nexus,
+and so on), store credentials with `sbx secret set --registry`.
+
+Choose the scope by adding `--all-sandboxes`, adding `--sandbox SANDBOX`, or
+passing neither:
+
+```text
+sbx secret set [--all-sandboxes | --sandbox SANDBOX] --registry HOST
+```
+
+- **Host-only** (no scope flag): the `sbx` CLI uses it to pull templates
+  and kits when creating a sandbox. The credential stays on the host and is
+  never available inside the sandbox.
+- **All sandboxes** (`--all-sandboxes`): same as host-only, plus the proxy
+  authenticates registry login requests from sandboxes. The credential stays
+  on the host and is never written to the sandbox filesystem. Use it when
+  agents build and publish container images.
+- **Sandbox-scoped** (`--sandbox SANDBOX`): same proxy behavior as
+  `--all-sandboxes`, but only for the named sandbox. Use it when only one
+  sandbox needs registry access.
+
+### Store registry credentials
+
+Pipe a token from stdin and target the registry hostname:
+
+```console
+$ gh auth token | sbx secret set --registry ghcr.io --password-stdin
+```
+
+For registries that require a username (for example, ACR with an admin
+account), add `--username`:
+
+```console
+$ echo "$ACR_PASSWORD" | sbx secret set \
+    --registry myregistry.azurecr.io \
+    --username myuser \
+    --password-stdin
+```
+
+Add `--all-sandboxes` to make the credential available to every new sandbox:
+
+```console
+$ gh auth token | sbx secret set --all-sandboxes --registry ghcr.io --password-stdin
+$ sbx run claude
+```
+
+Store all-sandboxes registry credentials before creating a sandbox. Existing
+sandboxes don't pick up all-sandboxes registry credentials added later. To add
+registry access to an existing sandbox, use a sandbox-scoped credential instead.
+
+To scope the credential to a single sandbox, store it under that sandbox's name:
+
+```console
+$ gh auth token | sbx secret set --sandbox my-app --registry ghcr.io --password-stdin
+```
+
+`sbx kit pull` also uses these credentials, with the Docker credential
+store as a fallback. `sbx kit push` uses only the Docker credential store —
+push targets still require a prior `docker login`.
+
+### Remove registry credentials
+
+Remove both the host-only and all-sandboxes entries for a registry:
+
+```console
+$ sbx secret rm --registry ghcr.io -f
+```
+
+To remove only the all-sandboxes entry and leave the host-only credential in
+place, pass `--all-sandboxes`:
+
+```console
+$ sbx secret rm --all-sandboxes --registry ghcr.io -f
+```
+
+To remove a sandbox-scoped credential, pass the sandbox name:
+
+```console
+$ sbx secret rm --sandbox my-sandbox --registry ghcr.io -f
+```
+
+## Best practices
+
+- Use [stored secrets](#stored-secrets) to provide credentials. The OS keychain
+  protects them at rest; on Linux hosts without a keychain they are held in a
+  permission-protected file instead. See
+  [Where secrets are stored](#where-secrets-are-stored).
+- Don't set API keys manually inside the sandbox. Sandbox agents are
+  pre-configured to use proxy-managed credentials.
+- Registry credentials stay on the host and are injected by the proxy when a
+  sandbox authenticates to the registry. Reserve them for sandboxes that need
+  registry access, and prefer sandbox scope over `--all-sandboxes` to limit
+  exposure.
+- Several agents support OAuth as another secure option: the flow runs on the
+  host, so the token is never exposed inside the sandbox. If you haven't stored
+  a credential, the agent prompts you to authenticate — Codex prompts on the
+  host from `sbx run codex`, while Claude Code, Cursor, and Droid prompt
+  interactively inside the sandbox. To authenticate ahead of time, run
+  `sbx secret set openai --oauth` for Codex or use `/login` inside Claude
+  Code; Cursor and Droid have no ahead-of-time option, so their sign-in prompt
+  appears when the agent starts. See the individual [agent pages](../agents/)
+  for each agent's flow.
+- If you store credentials in 1Password or AWS Secrets Manager, see
+  [Sourcing credentials from 1Password](../workflows/authentication.md#source-credentials-from-1password)
+  and [Sourcing credentials from AWS Secrets Manager](../workflows/authentication.md#source-credentials-from-aws-secrets-manager).
+
+## Custom templates and placeholder values
+
+When building custom templates or installing agents manually in a shell
+sandbox, some agents require environment variables like `OPENAI_API_KEY` to be
+set before they start. Set these to placeholder values (e.g. `proxy-managed`)
+if needed. The proxy injects actual credentials regardless of the environment
+variable value.
diff --git a/content/manuals/ai/sandboxes/configuration/environment-files.md b/content/manuals/ai/sandboxes/configuration/environment-files.md
new file mode 100644
index 000000000000..82089b2e66df
--- /dev/null
+++ b/content/manuals/ai/sandboxes/configuration/environment-files.md
@@ -0,0 +1,397 @@
+---
+title: Sandbox environment files
+linkTitle: Environment files
+weight: 20
+description: Use a declarative .sbxenv.yaml file to describe and share your sandbox configuration.
+keywords:
+  - docker sandboxes
+  - sbx env
+  - sbxenv
+  - environment file
+  - sandbox configuration
+  - declarative
+aliases:
+  - /ai/sandboxes/sandbox-environments/
+params:
+  sidebar:
+    badge:
+      color: violet
+      text: Experimental
+---
+
+A sandbox environment file captures the setup for a project in a
+`.sbxenv.yaml` file. Share the file with project contributors so they use the
+same agent, tools, resources, and credentials without reproducing CLI flags and
+setup steps.
+
+> [!NOTE]
+> `sbx env` requires `sbx` 0.39.0 or later. The feature is experimental, so the
+> command interface and file format may change in future releases.
+
+## Start an environment
+
+Keep the environment file outside the directories you mount into the sandbox.
+That includes the primary workspace and every `additionalWorkspaces` mount.
+For example, place it beside your project:
+
+```text
+web-app-env/
+├── .sbxenv.yaml
+└── web-app/
+```
+
+Create `web-app-env/.sbxenv.yaml`. This example gives the agent a shared
+environment variable and the Playwright browser-testing tools. It also
+publishes the application's development port:
+
+```yaml
+schemaVersion: "1"
+name: web-app
+agent: claude
+workspace: ./web-app
+
+kits:
+  - docker.io/sbx/playwright-kit:latest
+
+env:
+  NODE_ENV: test
+
+ports:
+  - sandbox: 3000
+    host: 3000
+```
+
+From `web-app-env`, run the environment:
+
+```console
+$ sbx env run
+```
+
+The `web-app` directory becomes the workspace, while `.sbxenv.yaml` remains
+outside the sandbox. If the environment doesn't exist, `sbx` creates a sandbox
+named `web-app`, installs Playwright and Chromium, and publishes sandbox port
+`3000` on the host. It then attaches to the agent. Later runs attach to the
+existing sandbox.
+
+This placement keeps the environment file outside the agent's writable
+workspace. If you later add `additionalWorkspaces`, keep `.sbxenv.yaml`
+outside those directories too. See the [`workspace` guidance](#workspace)
+for details.
+
+## Commands
+
+| Command                                                                                 | Description                                                                                          |
+| --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
+| [`sbx env run`](/reference/cli/sbx/env/run/) `[PATH...]`                                | Creates the environment if needed, then attaches. Re-runs apply only [`env` and MCP changes](#update-an-environment). Remove and recreate for other changes |
+| [`sbx env create`](/reference/cli/sbx/env/create/) `[PATH...]`                          | Creates the environment without attaching                                                            |
+| [`sbx env exec`](/reference/cli/sbx/env/exec/) `[PATH...] -- COMMAND [ARG...]`           | Runs a command in an existing environment                                                            |
+| [`sbx env rm`](/reference/cli/sbx/env/rm/) `[PATH...]`                                  | Removes the sandbox and its scoped credentials                                                       |
+
+`PATH` can be a directory or a direct path to an environment file. When you
+pass a directory, `sbx` reads `.sbxenv.yaml` and falls back to `.sbxenv.yml`.
+With no path, `sbx` searches the working directory.
+
+Pass the same set of paths to each lifecycle command so they resolve the same
+sandbox.
+
+## Common workflows
+
+The following examples combine environment file fields into configurations you
+can adapt for a project.
+
+### Combine team defaults and personal settings
+
+Keep the shared configuration in a version-controlled environment directory
+outside the mounted workspace. Put machine-specific settings in a file excluded
+from version control. For example, commit `base.sbxenv.yaml` beside the
+`web-app` directory:
+
+```yaml
+schemaVersion: "1"
+name: web-app
+agent: claude
+workspace: ./web-app
+
+env:
+  NODE_ENV: development
+
+sandboxOptions:
+  cpus: 4
+  memory: 8g
+```
+
+Add `local.sbxenv.yaml` to `.gitignore`, then use it for personal settings:
+
+```yaml
+env:
+  LOG_LEVEL: debug
+
+sandboxOptions:
+  memory: 12g
+```
+
+Pass both files in merge order:
+
+```console
+$ sbx env run base.sbxenv.yaml local.sbxenv.yaml
+```
+
+Nested mappings merge by key, lists concatenate, and values from later files
+replace earlier scalar values. In this example, the sandbox has four CPUs,
+12 GB of memory, and both environment variables. The first file controls the
+base directory for relative workspace paths and the default sandbox name.
+
+### Work across multiple repositories
+
+Mount related repositories alongside the primary project when the agent needs
+to coordinate changes or consult shared code and documentation:
+
+```yaml
+# .sbxenv.yaml in the directory above the repositories
+schemaVersion: "1"
+name: web-platform
+agent: codex
+
+workspace: ./web-app
+
+additionalWorkspaces:
+  - path: ./shared-components
+  - path: ./architecture-docs
+    readOnly: true
+```
+
+The agent starts in `web-app`, can modify `shared-components`, and can read
+`architecture-docs` without changing it. The environment file stays outside all
+three workspaces. Relative paths resolve from the directory of the first
+environment file. Additional workspaces are mounted directly even when the
+primary workspace uses clone mode.
+
+### Reuse an environment in automation
+
+Use the same committed environment for interactive development and automated
+tasks. Developers attach to the agent with `run`:
+
+```console
+$ sbx env run
+```
+
+Automation can create the sandbox without attaching, run commands in it, and
+remove it afterward:
+
+```console
+$ sbx env create
+$ sbx env exec -- npm test
+$ sbx env rm --force
+```
+
+Commands and vault references under `secrets` resolve on the host, so the
+automation runner must provide the referenced tools and authentication. The
+secret values remain outside the environment file.
+
+## Update an environment
+
+`sbx env run` starts and attaches to an existing sandbox without provisioning
+its secrets and bindings again. For an existing sandbox, the command applies
+changes to `env` to the new session and reconciles declared MCP servers. Changes
+to workspaces, kits, ports, secrets, bindings, and `sandboxOptions` require you
+to remove the environment with `sbx env rm` and create it again.
+
+## Remove an environment
+
+Secrets and registry credentials are sandbox-scoped. Credential bindings and
+MCP server registrations are host-global and can be shared by multiple
+sandboxes.
+
+`sbx env rm` removes the sandbox and its scoped credentials. Global credential
+bindings remain unless you pass `--prune-bindings`. MCP registrations remain
+available to other sandboxes.
+
+### Clean up after a failed create
+
+Secret provisioning, binding updates, and MCP server registration occur before
+the sandbox is created. If sandbox creation fails, scoped secrets remain, and
+bindings and MCP registrations may also remain. Run `sbx env rm` with the same
+paths to remove the scoped secrets. Pass `--prune-bindings` if you also want to
+remove the declared global bindings. MCP registrations are host-global and
+remain after cleanup.
+
+## File reference
+
+The loader rejects unknown fields and unsupported schema versions.
+
+### Top-level fields
+
+| Field                  | Type             | Required | Default                        | Description                                                                     |
+| ---------------------- | ---------------- | -------- | ------------------------------ | ------------------------------------------------------------------------------- |
+| `schemaVersion`        | string           | Yes      | None                           | Schema version. The supported value is `"1"`                                   |
+| `name`                 | string           | No       | `<agent>-<workspace-basename>` | Sandbox name                                                                    |
+| `agent`                | string           | Yes      | None                           | Built-in agent or the name of an agent kit                                      |
+| `kits`                 | list of strings  | No       | None                           | Kits to install at creation. See [`kits`](#kits)                                 |
+| `workspace`            | string or object | No       | First file's directory         | Primary workspace. See [`workspace`](#workspace)                                |
+| `additionalWorkspaces` | list             | No       | None                           | Extra directories to mount. See [`additionalWorkspaces`](#additionalworkspaces) |
+| `env`                  | map of strings   | No       | None                           | Environment variables for the sandbox                                           |
+| `sandboxOptions`       | object           | No       | None                           | Creation options. See [`sandboxOptions`](#sandboxoptions)                        |
+| `secrets`              | map              | No       | None                           | Service credentials. See [`secrets`](#secrets)                                  |
+| `bindings`             | map              | No       | None                           | Credential injection approvals. See [`bindings`](#bindings)                     |
+| `registries`           | map              | No       | None                           | Registry pull credentials. See [`registries`](#registries)                      |
+| `mcp`                  | object           | No       | None                           | MCP servers. See [`mcp`](#mcp)                                                  |
+| `ports`                | list             | No       | None                           | Port mappings. See [`ports`](#ports)                                            |
+
+### `kits`
+
+`kits` accepts local directories, ZIP archives, OCI registry references, and
+Git URLs prefixed with `git+https://` or `git+ssh://`. Kits can install tools,
+configure the sandbox, and give the agent project-specific instructions. See
+[Kits](../customize/kits.md) for details.
+
+Remote kit sources must match the
+[kit source allowlist](../customize/kits.md#restrict-kit-sources). Docker Hub is
+allowed by default. To use Git kits from `docker/sbx-kits-contrib`, add its
+source:
+
+```console
+$ sbx settings set kit.allowedSources '["docker.io/","github.com/docker/"]'
+```
+
+The setting replaces the complete allowlist, so include any existing sources
+you want to keep. For reproducible setup, pin Git kits with the `ref` URL
+parameter and OCI kits with an immutable tag or digest.
+
+### `workspace`
+
+When specified as a string, `workspace` is the path. Use the object form for
+clone mode:
+
+> [!WARNING]
+> With [direct mount](../security/isolation.md#direct-mount-default), the agent can
+> modify every file in a workspace. If an environment file is inside a mounted
+> workspace, the agent can change the file that controls later `sbx env`
+> commands. Store environment files outside all direct-mounted workspaces,
+> including every `additionalWorkspaces` mount.
+> [Clone mode](../security/isolation.md#clone-mode) protects files in the primary
+> repository, but additional workspaces remain direct-mounted.
+
+| Field   | Type    | Default                | Description                                                             |
+| ------- | ------- | ---------------------- | ----------------------------------------------------------------------- |
+| `path`  | string  | First file's directory | Workspace directory. Relative paths resolve from the first file         |
+| `clone` | boolean | `false`                | Use a private clone, equivalent to `sbx create --clone`                  |
+
+You can override `workspace.clone` for one `create` or `run` invocation with
+`--clone` or `--clone=false`.
+
+### `additionalWorkspaces`
+
+Each additional workspace is mounted after the primary workspace. Relative
+paths resolve from the directory of the first environment file.
+
+| Field      | Type    | Required | Default | Description                   |
+| ---------- | ------- | -------- | ------- | ----------------------------- |
+| `path`     | string  | Yes      | None    | Directory to mount            |
+| `readOnly` | boolean | No       | `false` | Mount the directory read-only |
+
+### `sandboxOptions`
+
+| Field        | Type    | Default  | Description                                                     |
+| ------------ | ------- | -------- | --------------------------------------------------------------- |
+| `template`   | string  | None     | Custom sandbox template image                                   |
+| `memory`     | string  | None     | Memory limit, such as `8g` or `512m`                             |
+| `cpus`       | integer | `0`      | Number of CPUs. `0` allocates all host CPUs                      |
+| `pullPolicy` | string  | `always` | Image pull policy: `always`, `missing`, or `never`               |
+| `profile`    | string  | None     | Governance profile name                                         |
+
+### `secrets`
+
+`secrets` maps service names to secret sources. Each entry must set exactly one
+of `value`, `ref`, or `command`. The secret is stored at the sandbox scope when
+the environment is created.
+
+| Field      | Type    | Default | Description                                                                  |
+| ---------- | ------- | ------- | ---------------------------------------------------------------------------- |
+| `value`    | string  | None    | Literal secret value                                                         |
+| `ref`      | string  | None    | Vault URI, such as `op://Vault/Item/field`                                    |
+| `command`  | string  | None    | Host shell command whose standard output becomes the secret                   |
+| `refresh`  | string  | None    | Resolution policy for `ref` or `command`, such as `on-demand` or `55m`        |
+| `backend`  | string  | Automatic | Resolver for `ref`: `sdk` or `cli`                                          |
+| `noVerify` | boolean | `false` | Skip verifying that a `ref` or `command` resolves during provisioning          |
+
+> [!WARNING]
+> A literal `value` is visible to anyone with read access to the file. Use a
+> vault URI with `ref` or obtain the value at runtime with `command`.
+
+```yaml
+secrets:
+  anthropic:
+    ref: op://Private/Anthropic/api-key
+    refresh: 55m
+  github:
+    command: gh auth token
+```
+
+### `bindings`
+
+`bindings` approves credential injection domains for each service. The
+environment merges these approvals into the user's global
+`credentials.yaml`. Each service can contain an `apiKey` block, an `oauth`
+block, or both. Each block contains a `domains` list:
+
+```yaml
+bindings:
+  github:
+    apiKey:
+      domains:
+        - api.github.com
+```
+
+`sbx env rm` preserves global bindings by default. Pass `--prune-bindings` to
+remove every service binding declared by the environment file.
+
+> [!WARNING]
+> `--prune-bindings` deletes the complete global binding entry for every
+> service declared in the environment file. This can affect other sandboxes
+> that share those service bindings.
+
+### `registries`
+
+`registries` maps registry hostnames to pull credentials. Each entry requires
+`secret` and accepts an optional `username`. Both fields accept a secret source
+with exactly one of `value`, `ref`, or `command`.
+
+When `username` is omitted, `sbx` stores a token-only credential. Registries
+such as GHCR and GitLab accept token-only credentials.
+
+```yaml
+registries:
+  ghcr.io:
+    secret:
+      command: gh auth token
+```
+
+### `mcp`
+
+The `mcp.servers` list registers servers with the built-in
+[MCP gateway](../mcp-gateway.md) and adds them to the sandbox. MCP registrations
+are host-global and remain after `sbx env rm`.
+
+| Field     | Type            | Required | Default | Description                                                     |
+| --------- | --------------- | -------- | ------- | --------------------------------------------------------------- |
+| `name`    | string          | Yes      | None    | Server name                                                     |
+| `url`     | string          | No       | None    | Remote server URL, registry reference, or OCI reference          |
+| `command` | string          | No       | None    | Command for a local stdio server                                 |
+| `args`    | list of strings | No       | None    | Arguments passed to `command`                                   |
+
+Each server must set exactly one of `url` or `command`.
+
+### `ports`
+
+`ports` publishes sandbox ports when the environment is created. Ports exposed
+by a kit but omitted from this list receive an ephemeral host port.
+
+| Field      | Type    | Required | Default          | Description                                                           |
+| ---------- | ------- | -------- | ---------------- | --------------------------------------------------------------------- |
+| `sandbox`  | integer | Yes      | None             | Sandbox port from 1 through 65535                                     |
+| `host`     | integer | No       | Ephemeral        | Host port from 1 through 65535                                        |
+| `protocol` | string  | No       | `tcp`            | `tcp`, `tcp4`, `tcp6`, `udp`, `udp4`, or `udp6`                       |
+| `hostIP`   | string  | No       | Loopback         | Host interface. The default uses available IPv4 and IPv6 loopback     |
+
+If a port can't be published, sandbox creation fails and removes the new
+sandbox.
diff --git a/content/manuals/ai/sandboxes/configuration/gpu-passthrough.md b/content/manuals/ai/sandboxes/configuration/gpu-passthrough.md
new file mode 100644
index 000000000000..77a6a3fde64f
--- /dev/null
+++ b/content/manuals/ai/sandboxes/configuration/gpu-passthrough.md
@@ -0,0 +1,142 @@
+---
+title: Enable NVIDIA GPU passthrough
+linkTitle: GPU passthrough
+description: Run GPU-accelerated workloads in a sandbox by building and installing the NVIDIA driver bundle for VFIO passthrough.
+keywords: docker sandboxes, sbx, gpu, gpu passthrough, nvidia, vfio, iommu, driver bundle, cuda
+weight: 30
+aliases:
+  - /ai/sandboxes/gpu-passthrough/
+---
+
+> [!IMPORTANT]
+> GPU passthrough is experimental. The `--gpu` flag, the driver bundle, and the
+> setup steps on this page are subject to change.
+
+Docker Sandboxes supports GPU passthrough, which allows running
+workloads against a physical NVIDIA GPU.
+
+GPU passthrough in Docker sandboxes works via [VFIO](https://www.kernel.org/doc/html/latest/driver-api/vfio.html), a Linux feature
+that assigns a PCI device directly to a virtual machine. The GPU is
+bound to VFIO instead of the host's driver, and the sandboxed workload
+drives the hardware itself.
+
+## Requirements
+
+VFIO-based GPU passthrough is supported only on `x86_64` Linux hosts (not Arm)
+with NVIDIA GPUs, and requires a GPU that nothing else is using: a headless
+host with a GPU, or an additional GPU.
+
+The host also needs IOMMU turned on in its BIOS, and the `iommufd` and
+`vfio_pci` kernel modules loaded:
+
+```console
+sudo modprobe -a iommufd vfio_pci
+```
+
+For the sandbox to drive the GPU, it requires:
+
+- The `nvidia` and `nvidia-uvm` kernel modules, built for the Docker Sandboxes
+  guest kernel
+- The NVIDIA userspace driver libraries and firmware
+
+Docker Sandboxes looks for these dependencies, packaged as an EROFS image, at
+`/usr/libexec/nerdbox-nvidia-bundle.erofs`. This bundle isn't included with
+Docker Sandboxes. To build it, see [Build the bundle](#build-the-bundle).
+
+## Turn on the feature
+
+The `--gpu` flag is hidden until you turn on experimental features and the GPU
+feature flag:
+
+```console
+sbx settings set platform.allowExperimentalFeatures true
+sbx settings set feature.sandbox-gpu true
+```
+
+## Build the bundle
+
+A zip archive containing all the components required to build the bundle is
+published with each Docker Sandboxes release, as
+`nerdbox-nvidia-modules-x86_64.zip`. The archive contains the kernel modules
+(`nvidia.ko` and `nvidia-uvm.ko`), the driver version they were built against
+(`VERSION`), and a build script.
+
+The build script runs a `linux/amd64` container that downloads the matching
+NVIDIA driver, assembles the bundle, and installs it to
+`/usr/libexec/nerdbox-nvidia-bundle.erofs`. Writing to that path requires root,
+hence the `sudo` in the following commands.
+
+Prerequisites:
+
+- Network access to `download.nvidia.com`
+- Docker
+
+Download and unpack the archive, then run the script from the unpacked
+directory:
+
+```console
+curl -fSLO https://github.com/docker/sbx-releases/releases/latest/download/nerdbox-nvidia-modules-x86_64.zip
+unzip nerdbox-nvidia-modules-x86_64.zip -d nvidia-modules
+cd nvidia-modules
+sudo ./prepare-nvidia-bundle.sh
+```
+
+If the script can't write to the output path, it leaves the bundle in the
+current directory and prints the `install` command that finishes the job.
+
+Two environment variables override the script's default behavior:
+
+| Variable                | Default                                    | Purpose                                                                       |
+| ----------------------- | ------------------------------------------ | ----------------------------------------------------------------------------- |
+| `OUTPUT`                | `/usr/libexec/nerdbox-nvidia-bundle.erofs` | Where the finished bundle is written.                                         |
+| `ACCEPT_NVIDIA_LICENSE` | None                                       | Set to `1` to accept the NVIDIA license non-interactively, for scripts or CI. |
+
+For example, the following command writes the finished bundle to
+`/mnt/some-place/nerdbox-nvidia-bundle.erofs`:
+
+```console
+OUTPUT=/mnt/some-place/nerdbox-nvidia-bundle.erofs ./prepare-nvidia-bundle.sh
+```
+
+## Install the bundle
+
+If you ran the script on the `x86_64` Linux host that runs your GPU sandboxes,
+and you didn't override `OUTPUT`, the bundle is already in place. If you built
+it elsewhere, copy the `nerdbox-nvidia-bundle.erofs` file it produced into that
+host's `/usr/libexec` directory.
+
+## Run a sandbox with a GPU
+
+To run a sandbox with GPU passthrough, pass the `--gpu` flag:
+
+```console
+sbx create --gpu claude .
+```
+
+The `sbx run` command takes the same flag:
+
+```console
+sbx run --gpu claude
+```
+
+The flag takes effect when the sandbox is created. Passing it when you
+re-attach to an existing sandbox has no effect.
+
+> [!IMPORTANT]
+> Each Docker Sandboxes release uses a specific guest kernel. The NVIDIA 
+> kernel modules in your bundle must match that kernel. After upgrading
+> Docker Sandboxes, download the new release's `nerdbox-nvidia-modules-x86_64.zip`
+> archive and run the script again to rebuild the bundle.
+
+## Troubleshooting
+
+### The script reports `... not found in the driver download`
+
+The extracted driver didn't contain an expected library or firmware file.
+Confirm that the download completed. If a library is named differently in your
+driver version, adjust `DRIVER_LIB_FAMILIES` in the script.
+
+### GPU workloads fail after a Docker Sandboxes upgrade
+
+The guest kernel or the pinned driver version likely changed. Download the new
+release's archive, re-run the script, and reinstall the bundle.
diff --git a/content/manuals/ai/sandboxes/configuration/upstream-proxy.md b/content/manuals/ai/sandboxes/configuration/upstream-proxy.md
new file mode 100644
index 000000000000..bb87cd3176b6
--- /dev/null
+++ b/content/manuals/ai/sandboxes/configuration/upstream-proxy.md
@@ -0,0 +1,172 @@
+---
+title: Configure an upstream proxy
+linkTitle: Upstream proxy
+description: Route sandbox and daemon traffic through a corporate or upstream proxy, including PAC files, SOCKS5, and your OS system proxy.
+keywords: docker sandboxes, sbx, upstream proxy, corporate proxy, pac, socks5, system proxy, no_proxy, egress, ntlm, kerberos
+weight: 40
+aliases:
+  - /ai/sandboxes/upstream-proxy/
+---
+
+> [!IMPORTANT]
+> Upstream proxy support is experimental. Everything described on this page —
+> proxy URLs, PAC files, SOCKS5, use of the OS system proxy, proxy
+> authentication, and the settings that configure them — is subject to change.
+> Share feedback and bug reports in the
+> [docker/sbx-releases](https://github.com/docker/sbx-releases) repository.
+
+An upstream proxy is the corporate or network proxy that Docker Sandboxes
+forwards outbound traffic through on its way to the internet. This is separate
+from the [network policy](../governance/access-controls/network.md), which decides
+_which_ destinations are allowed. The upstream proxy decides _how_ allowed
+traffic reaches them.
+
+Docker Sandboxes sends two kinds of outbound traffic, and you can proxy them
+independently:
+
+- Sandbox traffic — network access from inside your sandboxes.
+- Daemon traffic — the `sbx` daemon's own access: image pulls, telemetry,
+  sign-in, and feature flags.
+
+## Default behavior
+
+By default, both kinds of traffic use your operating system's proxy settings,
+including any PAC URL configured there. You don't need to configure anything. On
+macOS and Windows, `sbx` tracks the OS proxy setting while it runs, so a change
+to your network, VPN, or PAC configuration is picked up without a restart. If
+your OS has no proxy configured, traffic goes direct.
+
+## Set a proxy manually
+
+Use `sbx settings set` to override the default for one or both kinds of traffic:
+
+```console
+$ sbx settings set proxy http://proxy.corp:3128          # both kinds of traffic
+$ sbx settings set proxy.sandbox socks5://proxy.corp:1080 # sandbox traffic only
+$ sbx settings set proxy.daemon direct                    # daemon traffic only
+```
+
+A proxy value can be any of the following:
+
+| Value                                                                                  | Meaning                                                                                          |
+| -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
+| _(unset)_                                                                              | Fall back to the wider scope, then environment variables, then the OS system proxy (the default) |
+| `http://host:port` or `https://host:port`                                              | An HTTP or HTTPS proxy                                                                           |
+| `socks5://host:port` or `socks5h://host:port`                                          | A SOCKS5 proxy                                                                                   |
+| `pac+http://host/proxy.pac`, `pac+https://host/proxy.pac`, or `file:///path/proxy.pac` | A PAC (proxy auto-config) file                                                                   |
+| `system`                                                                               | Force the use of the OS system proxy                                                             |
+| `direct`                                                                               | Force a direct connection with no proxy                                                          |
+
+With `socks5://`, DNS is resolved locally before the connection is handed to the
+proxy. With `socks5h://`, DNS resolution is delegated to the proxy.
+
+### Exclude destinations from the proxy
+
+Exclusion lists mirror the same scopes. Each takes a comma-separated list of
+hosts, domain suffixes, IP addresses, or CIDR ranges, or `*` to bypass the
+proxy entirely:
+
+```console
+$ sbx settings set no_proxy "*.internal.corp,10.0.0.0/8"    # both kinds of traffic
+$ sbx settings set no_proxy.sandbox "*.svc.cluster.local"   # sandbox traffic only
+$ sbx settings set no_proxy.daemon "registry.internal"      # daemon traffic only
+```
+
+## Environment variables
+
+Because `sbx` runs from your shell, it also honors the standard and legacy proxy
+environment variables, so existing setups keep working without migration:
+
+- `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` (and their lowercase forms) — the
+  standard variables. They apply to both kinds of traffic when no `proxy` or
+  `no_proxy` setting is configured.
+- `DOCKER_SANDBOXES_PROXY` and `DOCKER_SANDBOXES_NO_PROXY` — the environment
+  form of `proxy.sandbox` and `no_proxy.sandbox`. They apply to sandbox traffic
+  only and never affect daemon traffic.
+
+The daemon reads these variables when it starts, so set them before your first
+`sbx` command, or restart the daemon for a change to take effect.
+
+## Precedence
+
+For each kind of traffic, the first match wins:
+
+1. The scope-specific value:
+   - `proxy.sandbox` or `DOCKER_SANDBOXES_PROXY` for sandbox traffic
+   - `proxy.daemon` for daemon traffic
+2. The `proxy` setting
+3. `HTTP_PROXY` or `HTTPS_PROXY` from the shell
+4. The OS system proxy (the default)
+5. Direct
+
+The matching exclusion list (`no_proxy.<scope>`, then `no_proxy`) applies to the
+chosen proxy, and the standard `NO_PROXY` variable still applies on the
+environment path.
+
+For example, if `proxy` specifies a shared proxy and `proxy.sandbox` is set to
+`direct`, sandbox traffic connects directly while daemon traffic uses the
+shared proxy. If no proxy setting is configured, `HTTP_PROXY` takes precedence
+over the OS system proxy.
+
+## When changes take effect
+
+The two kinds of traffic are resolved at different times:
+
+- Sandbox scope (`proxy.sandbox`, `no_proxy.sandbox`, and the sandbox side of
+  `proxy` and `no_proxy`) is re-resolved every time a sandbox is created or
+  restarted. A change takes effect on the next sandbox you create or restart;
+  already-running sandboxes keep the proxy they were created with.
+- Daemon scope (`proxy.daemon`, `no_proxy.daemon`, and the daemon side of
+  `proxy` and `no_proxy`) is resolved once when the daemon starts. A change
+  requires a daemon restart.
+
+The `DOCKER_SANDBOXES_*` environment variables are a separate case. They control
+sandbox traffic only, as described in
+[Environment variables](#environment-variables), but `sbx` reads them from the
+daemon's environment as the daemon starts, so changing one also requires a
+daemon restart.
+
+When a `system` or PAC proxy is in use, `sbx` still tracks OS-level proxy changes
+(such as switching networks, connecting a VPN, or updated PAC contents) live.
+
+## Authentication
+
+If the upstream proxy requires you to authenticate to it, `sbx` supports two
+mechanisms.
+
+### Credentials in the proxy URL
+
+Put the credentials in the proxy URL: `http://user:pass@host:port` for an HTTP
+or HTTPS proxy, or `socks5://user:pass@host:port` for SOCKS5. This works on all
+platforms and covers proxies that challenge with Basic authentication.
+
+### Integrated Windows authentication
+
+Proxies that answer `CONNECT` with a `407` challenge and accept only integrated
+schemes — NTLM or Kerberos/Negotiate — can instead authenticate you with your
+Windows sign-in identity. This is opt-in and off by default:
+
+```console
+$ sbx settings set proxy.integratedAuth true
+```
+
+The setting isn't scoped: it applies to both sandbox and daemon traffic. If the
+proxy offers several schemes, the strongest one is used, preferring Negotiate
+over NTLM. A change takes effect on the same schedule as the other proxy
+settings: on the next sandbox you create or restart for sandbox traffic, and
+after `sbx daemon restart` for daemon traffic.
+
+Your identity stays on the host. Authentication to the upstream proxy happens
+on the host side of the sandbox boundary, after network policy has already been
+applied, so no credential enters the sandbox and nothing about which
+destinations a sandbox may reach changes.
+
+This depends on Windows SSPI, so it has no effect on macOS or Linux. On those
+platforms, credentials in the proxy URL remain the only option.
+
+## Related pages
+
+- [Network isolation](../security/isolation.md) — how traffic leaves a sandbox and
+  the network policy it passes through
+- [Troubleshooting: API calls fail with a certificate error](../troubleshooting.md#api-calls-fail-with-a-certificate-error)
+  — installing an internal root CA when your proxy inspects HTTPS traffic
diff --git a/content/manuals/ai/sandboxes/customize/_index.md b/content/manuals/ai/sandboxes/customize/_index.md
new file mode 100644
index 000000000000..94e3434250a2
--- /dev/null
+++ b/content/manuals/ai/sandboxes/customize/_index.md
@@ -0,0 +1,70 @@
+---
+title: Customizing sandboxes
+linkTitle: Customize
+description: Build reusable sandbox images and extend or define agents using templates and kits.
+keywords: sandboxes, sbx, customize, templates, kits, mixins, custom agents
+weight: 90
+aliases:
+  - /ai/sandboxes/agents/custom-environments/
+params:
+  sidebar:
+    badge:
+      color: blue
+      text: Early Access
+---
+
+{{< summary-bar feature_name="Docker Sandboxes sbx" >}}
+
+Docker Sandboxes offers two ways to customize a sandbox beyond the built-in
+defaults:
+
+- [Templates](templates.md) — reusable sandbox images with tools, packages,
+  and configuration baked in. Extend a base image with a Dockerfile, or
+  save a running sandbox as a template.
+- [Kits](kits.md) — declarative YAML artifacts that extend an agent with
+  tools, credentials, network rules, and files at runtime, or define a new
+  agent from scratch.
+
+Kits are experimental. The kit file format, CLI commands, and experience for
+creating, loading, and managing kits are subject to change as the feature
+evolves. Share feedback and bug reports in the
+[docker/sbx-releases](https://github.com/docker/sbx-releases) repository.
+
+## Templates and kits, side by side
+
+A template is a Docker image that the sandbox runs. It's built ahead
+of time with a Dockerfile (or saved from a running sandbox), pushed to a
+registry, and pulled when a sandbox is created. Use templates for things
+that belong in an image: system packages, language toolchains, large
+dependencies — anything you'd rather not reinstall on every sandbox start.
+
+A kit is a YAML artifact applied at sandbox creation. The kit can run
+install commands, drop files into the sandbox, declare network and
+credential rules, and (for sandbox kits) define which template image the
+agent runs in. Use kits for things that vary per agent or per team:
+shared linter config, project-specific install steps, credential
+injection for a service the agent talks to.
+
+Templates and kits work together. A sandbox kit's `sandbox.image` field
+points at a template: the template provides the base environment, the
+kit layers config, secrets, and runtime behavior on top. A team can ship
+one heavy template and several thin kits without rebuilding the image
+each time something changes.
+
+## When to use which
+
+| Goal                                                      | Option                                                        |
+| --------------------------------------------------------- | ------------------------------------------------------------- |
+| Pre-install tools and packages into a reusable base image | [Template](templates.md)                                      |
+| Capture a configured running sandbox for reuse            | [Saved template](templates.md#saving-a-sandbox-as-a-template) |
+| Add a tool, credential, or config to agent runs via YAML  | [Kit (mixin)](kits.md)                                        |
+| Define a new agent from scratch                           | [Kit (sandbox)](kits.md#define-an-agent)                      |
+
+Templates and kits can be used together. A template bakes heavy tools into
+the image for fast sandbox startup; a kit layered on top adds per-run
+credentials, config, or extra capabilities.
+
+## Tutorials
+
+- [Build your own agent kit](build-an-agent.md) — step-by-step walkthrough
+  for packaging [Amp](https://ampcode.com/) as a sandbox kit.
diff --git a/content/manuals/ai/sandboxes/customize/build-an-agent.md b/content/manuals/ai/sandboxes/customize/build-an-agent.md
new file mode 100644
index 000000000000..1e920b4c11d8
--- /dev/null
+++ b/content/manuals/ai/sandboxes/customize/build-an-agent.md
@@ -0,0 +1,326 @@
+---
+title: Build your own agent kit
+linkTitle: Build an agent
+description: Walk through building an agent kit for Amp, from base image choice to invocation.
+keywords: sandboxes, sbx, kits, agent, tutorial, amp, ampcode
+weight: 30
+---
+
+{{< summary-bar feature_name="Docker Sandboxes sbx" >}}
+
+> [!NOTE]
+> Kits are experimental. The kit file format, CLI commands, and experience
+> for creating, loading, and managing kits are subject to change as the
+> feature evolves. Share feedback and bug reports in the
+> [docker/sbx-releases](https://github.com/docker/sbx-releases) repository.
+
+This tutorial walks through building an agent kit for the
+[Amp](https://ampcode.com/) coding agent. Each step explains the decision
+behind a part of the spec, so you can apply the same reasoning to other agents.
+
+For reference on every field, see the [Kit spec reference](kit-reference.md).
+This tutorial focuses on the journey.
+
+The finished kit is also published as a runnable sample at
+[docker/sbx-kits-contrib](https://github.com/docker/sbx-kits-contrib/tree/main/amp) —
+useful as a reference while you follow along.
+
+## Choose a base image
+
+An agent kit needs a container image that satisfies the
+[base image requirements](kit-reference.md#base-image-requirements): non-root
+`agent` user at UID 1000, passwordless sudo, `/home/agent/` home, and HTTP
+proxy environment variable forwarding.
+
+Rather than build an image from scratch, extend one of the published
+sandbox templates. Three common starting points:
+
+- `docker/sandbox-templates:shell`. Generic base with no pre-installed
+  agent.
+- `docker/sandbox-templates:shell-docker`. Same, with Docker Engine inside
+  the sandbox.
+- Agent-specific variants (`claude-code`, `codex`, etc.). Only useful if
+  you're extending that specific agent.
+
+For Amp, pick `shell-docker`:
+
+- Amp isn't pre-installed in any variant, so you need a generic base
+  (`shell`).
+- Docker support is handy since coding agents often need to run containers.
+- If you don't need Docker inside the sandbox, use the `shell` tag for a
+  lighter, non-privileged environment.
+
+## Plan authentication
+
+Amp authenticates with an API key in `AMP_API_KEY`. To keep the real key
+out of the VM, you split the work in two:
+
+- The kit's network section maps the API host to a service identifier
+  and tells the proxy which header to inject.
+- You provide your key once on the host, via sbx's secret store. The
+  real value stays on the host; only a placeholder reaches the sandbox.
+
+Inside the sandbox `AMP_API_KEY` is set to that placeholder. The proxy
+substitutes the real key on outbound requests to the API host, so the
+secret never enters the sandbox. A later section walks through the
+specific command for storing the key.
+
+## Write the sandbox block
+
+The `sandbox:` block tells the sandbox how to launch Amp when the user
+attaches.
+
+```yaml {title="amp/spec.yaml"}
+schemaVersion: "1"
+kind: sandbox
+name: amp
+displayName: Amp
+description: The frontier coding agent.
+
+sandbox:
+  image: "docker/sandbox-templates:shell-docker"
+  aiFilename: AGENTS.md
+  entrypoint:
+    run: [amp, --dangerously-allow-all]
+```
+
+- `aiFilename: AGENTS.md` tells the sandbox to create `AGENTS.md` at launch
+  and append the [`agentContext`](#prime-amp-with-memory) block to it. Amp reads
+  this file for instructions.
+- `entrypoint.run` runs `amp` in "YOLO-mode" when the sandbox starts. Adjust if
+  you want to pass different args on startup.
+
+## Install Amp
+
+Amp installs via a curl-to-bash script:
+
+```yaml
+commands:
+  install:
+    - command: "curl -fsSL https://ampcode.com/install.sh | bash"
+      user: "1000"
+      description: Install Amp
+```
+
+Note `user: "1000"`. That's the agent user. Install commands run as root
+(UID 0) by default, and Amp's installer puts the binary in the user's home
+directory. Running as root would land the binary in `/root/` where the
+agent can't reach it.
+
+## Allow network access
+
+The network block does two things: it lists the hosts the sandbox can
+reach (`allowedDomains`), and it wires the kit-side half of the auth flow
+from [Plan authentication](#plan-authentication) with `serviceDomains` and
+`serviceAuth`.
+
+```yaml
+network:
+  serviceDomains:
+    ampcode.com: amp
+  serviceAuth:
+    amp:
+      headerName: Authorization
+      valueFormat: "Bearer %s"
+  allowedDomains:
+    - "ampcode.com:443"
+    - "*.ampcode.com:443"
+```
+
+`allowedDomains` here covers the apex (`ampcode.com`) and the
+install/CDN subdomains (`*.ampcode.com`). Treat it as a starting point;
+Amp may reach other domains (model providers, analytics, updates) that
+you'll discover by watching `sbx policy log` while testing.
+
+Kits can also declare `deniedDomains` for hosts the sandbox should not
+reach, such as telemetry endpoints. Deny rules take precedence over
+allow rules and apply only to sandboxes that use the kit.
+
+For the auth wiring, when the agent makes an outbound request to
+`ampcode.com`, the proxy looks up the host in `serviceDomains` to find
+the service id `amp`, then uses `serviceAuth.amp` to inject an
+`Authorization: Bearer <key>` header. The `<key>` value comes from the
+secret you'll register in
+[Register your API key](#register-your-api-key), matched by host. The
+service id (`amp`) is just a label that ties the two blocks together —
+pick any name.
+
+> [!IMPORTANT]
+> Keep `serviceDomains` narrow. Mapping `*.ampcode.com` would push the
+> proxy into TLS-intercepting mode for every subdomain — including the
+> binary CDN the install script downloads from — which corrupts those
+> downloads. List only the host that actually needs auth.
+
+## Prime Amp with memory
+
+The `agentContext` field appends markdown to `AGENTS.md` at sandbox creation.
+Use it to tell Amp about the sandbox environment so it knows the
+conventions when it starts.
+
+```yaml
+agentContext: |
+  ## Sandbox environment
+
+  You are running inside a Docker sandbox. The workspace is mounted at
+  its absolute host path. `sudo` is passwordless; use it for package
+  installs. Docker is available inside the sandbox; containers you start
+  are isolated in the microVM.
+```
+
+Keep this short and sandbox-specific. For project instructions, put a
+regular `AGENTS.md` in the workspace.
+
+## The full spec
+
+Putting it all together:
+
+```yaml {title="amp/spec.yaml"}
+schemaVersion: "1"
+kind: sandbox
+name: amp
+displayName: Amp
+description: The frontier coding agent.
+
+sandbox:
+  image: "docker/sandbox-templates:shell-docker"
+  aiFilename: AGENTS.md
+  entrypoint:
+    run: [amp, --dangerously-allow-all]
+
+network:
+  serviceDomains:
+    ampcode.com: amp
+  serviceAuth:
+    amp:
+      headerName: Authorization
+      valueFormat: "Bearer %s"
+  allowedDomains:
+    - "ampcode.com:443"
+    - "*.ampcode.com:443"
+
+commands:
+  install:
+    - command: "curl -fsSL https://ampcode.com/install.sh | bash"
+      user: "1000"
+      description: Install Amp
+
+agentContext: |
+  ## Sandbox environment
+
+  You are running inside a Docker sandbox. The workspace is mounted at
+  its absolute host path. `sudo` is passwordless; use it for package
+  installs.
+```
+
+## Register your API key
+
+Register your Amp API key on the host with `sbx secret set-custom`. The
+value goes into the host secret store, and a placeholder is exposed
+inside every sandbox you launch from this kit.
+
+Amp validates `AMP_API_KEY`'s format at startup, so the placeholder needs
+to look like a real Amp key. Pick a placeholder shape that matches Amp's
+expected format:
+
+```console
+$ sbx secret set-custom \
+    --host ampcode.com \
+    --env AMP_API_KEY \
+    --placeholder "sgamp-{rand}" \
+    --value "$AMP_API_KEY"
+```
+
+`{rand}` expands to a random suffix at registration time. Inside the
+sandbox `AMP_API_KEY` is set to that placeholder; Amp accepts it as a
+syntactically valid key, and the proxy substitutes the real secret on
+outbound requests to `ampcode.com`.
+
+> [!TIP]
+> `sbx secret set-custom` is only required because Amp validates the
+> key's format. If your agent reads the env var without a local format
+> check, you can declare `environment.proxyManaged: [AMP_API_KEY]` in
+> the kit instead and skip this user-side step — the proxy uses a
+> default sentinel value (`proxy-managed`) that the agent never sees
+> rejected.
+
+> [!NOTE]
+> `sbx secret set-custom` is experimental and may change in future
+> releases. This tutorial surfaces it because there's no other path to
+> register a custom-format placeholder.
+
+## Run it
+
+Validate the spec:
+
+```console
+$ sbx kit validate ./amp/
+```
+
+Launch a sandbox with the kit, passing the kit's `name:` (`amp`) as the
+agent argument:
+
+```console
+$ sbx run --kit ./amp/ amp
+```
+
+The published copy of this kit also runs directly from the contrib
+repository:
+
+```console
+$ sbx run --kit "git+https://github.com/docker/sbx-kits-contrib.git#dir=amp" amp
+```
+
+## Iterate
+
+As you use the kit, you'll likely hit missing domains or install quirks.
+Two loops help:
+
+- Watch the network policy log (`sbx policy log`) to catch blocked
+  requests, then add their domains to `allowedDomains`.
+- Add domains to `deniedDomains` when the agent should stay blocked from
+  a host even if another policy permits it.
+- Edit the spec and re-run `sbx run --kit ./amp/ amp` to pick up changes.
+  Remove the sandbox first (`sbx rm <name>`) for a clean start.
+
+Flesh out the `agentContext` block as you refine how Amp should behave in the
+sandbox.
+
+## Publish
+
+Once the kit works, share it by packaging as a ZIP, pushing to an OCI
+registry, or committing to a Git repository. See
+[Packaging and distribution](kits.md#packaging-and-distribution) for the
+`sbx kit` subcommands.
+
+## Adapt this to another agent
+
+Most of the specifics here are Amp's. To port the pattern, work through
+the same decisions for your agent:
+
+- **Base image**: `shell-docker` if you need Docker inside the sandbox,
+  `shell` otherwise. Or extend either with your own image if the install
+  is heavy.
+- **Install**: a `commands.install` block at runtime, or bake the agent
+  into a custom image. Pick install if it's a one-line script; bake if
+  the install is slow or you need a pinned version.
+- **Network mapping**: list only the API host in `serviceDomains`, not
+  a wildcard. Keep install/CDN paths out of TLS-intercepting mode. Use
+  `deniedDomains` for hosts the agent should not reach.
+- **Credential injection**: if the agent validates the API key's format
+  locally, register with `sbx secret set-custom` and pick a matching
+  placeholder. If it accepts the env var as-is, declare
+  `environment.proxyManaged` in the kit and skip the user-side step.
+
+The rest — agent-context block, network-policy iteration, packaging — is the
+same regardless of agent.
+
+## Remove the stored secret
+
+To remove the entry created earlier with `sbx secret set-custom`, pass
+the host to `sbx secret rm`:
+
+```console
+$ sbx secret rm --host ampcode.com
+```
+
+The `--host` flag is part of the experimental `set-custom` surface and doesn't appear in `sbx secret rm --help`.
diff --git a/content/manuals/ai/sandboxes/customize/kit-examples.md b/content/manuals/ai/sandboxes/customize/kit-examples.md
new file mode 100644
index 000000000000..90c6504c0e57
--- /dev/null
+++ b/content/manuals/ai/sandboxes/customize/kit-examples.md
@@ -0,0 +1,477 @@
+---
+title: Kit examples
+linkTitle: Examples
+description: Copy-and-adapt spec.yaml snippets for common mixin and sandbox kit patterns — static files, install commands, shell customization, background services, setup files, Claude Code skills, and agent forks.
+keywords: sandboxes, sbx, kits, mixins, examples, patterns, skills
+weight: 40
+---
+
+{{< summary-bar feature_name="Docker Sandboxes sbx" >}}
+
+> [!NOTE]
+> Kits are experimental. The kit file format, CLI commands, and experience
+> for creating, loading, and managing kits are subject to change as the
+> feature evolves. Share feedback and bug reports in the
+> [docker/sbx-releases](https://github.com/docker/sbx-releases) repository.
+
+Each section below shows one `spec.yaml` snippet that demonstrates a
+single kit pattern. These aren't complete, distributable kits — they're
+small, focused examples you can lift into your own kit. For the full
+spec reference, see [Kit spec reference](kit-reference.md).
+
+## Drop a shared config file
+
+Use static files under `files/workspace/` when the content is the same
+across every sandbox and doesn't need any runtime values substituted
+in. Typical use cases: linter rules, editor settings, a shared
+`.editorconfig`, team dotfiles.
+
+```text
+ruff-lint/
+├── spec.yaml
+└── files/
+    └── workspace/
+        └── ruff.toml
+```
+
+```yaml {title="ruff-lint/spec.yaml"}
+schemaVersion: "2"
+kind: mixin
+name: ruff-lint
+displayName: Ruff
+description: Python linting with shared team config
+
+setup:
+  install:
+    - command: "uv tool install ruff@latest"
+      user: "1000"
+```
+
+```toml {title="ruff-lint/files/workspace/ruff.toml"}
+line-length = 80
+
+[lint]
+select = ["E", "F", "I"]
+```
+
+## Install a tool at sandbox creation
+
+`setup.install` runs once per sandbox, at creation time. It's where
+anything that needs to land in the image goes — package managers
+(`apt-get`, `pip`, `npm`), binary downloads, or vendor install scripts.
+
+> [!TIP]
+> Each new sandbox runs all `setup.install` commands. The results aren't
+> cached between sandboxes. Creating a kit avoids building and distributing an
+> image, so kits work well for smaller, composable changes. For substantial
+> build or installation steps, consider a
+> [custom template](templates.md#build-a-custom-template). Sandboxes reuse
+> template images from the local cache.
+
+```yaml
+setup:
+  install:
+    - command: "apt-get update && apt-get install -y jq"
+    - command: "curl -fsSL https://example.com/install.sh | sh"
+```
+
+Install commands run as root by default. Set `user: "1000"` when the
+step should run as the agent user — for example, `npm install -g`
+against a user-scoped prefix, or anything that writes to
+`/home/agent/`.
+
+Install steps run under `sh`, not bash, so bash-only builtins such as
+`source` fail with `sh: source: not found`. Pipe explicitly to `bash`
+(`curl … | bash`) or wrap the step in `bash -c '…'` when you need them.
+
+Downloads are subject to the sandbox's
+[network access rules](../governance/access-controls/network.md). A domain that
+resolves from your host can still be blocked inside the sandbox — for
+example, `get.sdkman.io` returns a 403 until you allow it with
+`sbx policy allow network get.sdkman.io`. A tool may also need base
+packages that aren't in the image: [SDKMAN!](https://sdkman.io/), for
+instance, needs `zip` and `unzip`, so add an
+`apt-get install -y zip unzip` step (as root) before installing it.
+
+> [!WARNING]
+> `curl … | bash` masks download failures. The pipe's exit status is
+> bash's, and bash exits `0` on empty input, so a blocked or failed
+> download still reports success — the sandbox is created with no error
+> even though nothing was installed. Download first, then run, so a
+> failed fetch fails the step:
+>
+> ```yaml
+> setup:
+>   install:
+>     - command: "curl -fsSL https://example.com/install.sh -o /tmp/install.sh && bash /tmp/install.sh"
+>       user: "1000"
+> ```
+
+## Customize the shell environment
+
+Some tools install into a versioned directory and expect you to source
+an init script from your shell profile so their commands land on `PATH`.
+Version managers like [nvm](https://github.com/nvm-sh/nvm) and
+[SDKMAN!](https://sdkman.io/) follow this pattern. To make the tool
+available in every shell, append the source line to
+`/etc/sandbox-persistent.sh` in an install command.
+
+`/etc/sandbox-persistent.sh` is the sandbox's persistent environment
+file. It's sourced before every bash invocation — interactive shells and
+non-interactive ones, including agents started with `sbx run` and
+commands run with `sbx exec`. Appending here makes the tool available to
+the agent regardless of how its shell is launched. Use
+[`environment.variables`](kit-reference.md#environment) for ordinary variables
+declared by a kit. To pass variables when creating a sandbox, use
+[`-e` or `--env-file`](../usage.md#set-environment-variables).
+
+```yaml {title="nvm/spec.yaml"}
+schemaVersion: "2"
+kind: mixin
+name: nvm
+displayName: nvm
+description: Node version manager available in every shell
+
+setup:
+  install:
+    - command: "curl -fsSL https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash"
+      user: "1000"
+      description: Install nvm
+    - command: |
+        cat >> /etc/sandbox-persistent.sh <<'EOF'
+        export NVM_DIR="$HOME/.nvm"
+        unset NPM_CONFIG_PREFIX
+        [ -s "$NVM_DIR/nvm.sh" ] && source "$NVM_DIR/nvm.sh"
+        EOF
+      user: "1000"
+      description: Source nvm for every shell
+```
+
+Both install steps run as `user: "1000"`. This installs the tool under
+`/home/agent/` and can update `/etc/sandbox-persistent.sh`, which the agent user
+owns. The `$HOME` in the appended lines resolves per user at source time, so the
+agent user finds its own install. Append to the file rather than overwriting it
+— the sandbox relies on its existing contents.
+
+The base image ships its own Node and sets `NPM_CONFIG_PREFIX`, which
+nvm won't activate alongside. `unset NPM_CONFIG_PREFIX` before sourcing
+`nvm.sh` clears that conflict. Sourcing makes the `nvm` command
+available; it doesn't put a Node version on `PATH`. Run
+`nvm install --lts` to add one — wrap it in `bash -c '…'` if you script
+it as an install step, since install steps run under `sh`.
+
+Append only the init script, not the tool's tab-completion script.
+Because `/etc/sandbox-persistent.sh` is sourced before every command,
+completion scripts — which rely on variables that exist only during
+completion — can break non-interactive shells that agents rely on.
+
+## Install an internal CA certificate
+
+If your organization uses a proxy that inspects HTTPS traffic, install
+the proxy's internal root CA in the sandbox trust store. This helps
+agents and SDKs trust certificates signed by the proxy.
+
+```text
+internal-ca/
+├── spec.yaml
+└── files/
+    └── home/
+        └── internal-ca.crt
+```
+
+Use a PEM-encoded certificate with a `.crt` extension. Files under
+`files/home/` land in `/home/agent/` in the sandbox, so
+`files/home/internal-ca.crt` becomes `/home/agent/internal-ca.crt` —
+which is the path the install command reads from. If traffic can be
+signed by more than one internal proxy, include each proxy's root CA in
+the kit and install each certificate before running
+`update-ca-certificates`.
+
+```yaml {title="internal-ca/spec.yaml"}
+schemaVersion: "2"
+kind: mixin
+name: internal-ca
+
+setup:
+  install:
+    - command: "install -m 0644 /home/agent/internal-ca.crt /usr/local/share/ca-certificates/internal-ca.crt && update-ca-certificates"
+      user: "0"
+      description: Install internal CA certificate
+```
+
+`update-ca-certificates` adds the certificate to the system trust
+store, so tools and SDKs that read the system bundle trust the proxy's
+certificates without further configuration.
+
+## Run a background service
+
+`setup.startup` runs on every sandbox start. To keep a long-running
+service such as a dev server or daemon alive, set `background: true`. The
+sandbox runs the command in the background and replays startup commands on
+each start, so the service comes back after a stop/start cycle:
+
+```yaml
+setup:
+  startup:
+    - command: ["my-service", "--port", "8080"]
+      user: "1000"
+      background: true
+```
+
+A background service doesn't write to your terminal. To capture its output
+for debugging, wrap the command in a shell and redirect to a log file. Let
+`background: true` run the command in the background rather than adding a
+trailing `&` yourself:
+
+```yaml
+setup:
+  startup:
+    - command:
+        - sh
+        - -c
+        - my-service --port 8080 > /tmp/my-service.log 2>&1
+      user: "1000"
+      background: true
+```
+
+An empty log file tells you the wrapper ran; a populated one tells you why
+the service failed.
+
+## Write runtime values to a file
+
+When a config file needs a value that isn't known until sandbox start
+— most often the absolute workspace path — use `setup.files`.
+The `${WORKDIR}` placeholder expands to the primary workspace path
+when the file is written.
+
+```yaml
+setup:
+  files:
+    - path: /home/agent/.local/bin/start-code-server.sh
+      content: |
+        exec code-server --bind-addr 0.0.0.0:8080 --auth none "${WORKDIR}"
+      mode: "0755"
+  startup:
+    - command:
+        - sh
+        - -c
+        - nohup /home/agent/.local/bin/start-code-server.sh > /tmp/code-server.log 2>&1 &
+      user: "1000"
+```
+
+`mode: "0755"` makes the generated file executable so the startup
+command can invoke it directly.
+
+Use `setup.files` instead of a static file whenever the content depends
+on a runtime value. Use a static file otherwise.
+
+> [!TIP]
+> This snippet is lifted from the
+> [code-server kit](https://github.com/docker/sbx-kits-contrib/tree/main/code-server)
+> in the contrib repository, which is also a runnable sample that demonstrates
+> the full pattern.
+
+## Ship a Claude Code skill
+
+Claude Code reads project-scoped skills from
+`.claude/skills/<name>/SKILL.md` in the workspace. Drop one into
+`files/workspace/` and it's available in the sandbox.
+
+```text
+docker-review/
+├── spec.yaml
+└── files/
+    └── workspace/
+        └── .claude/
+            └── skills/
+                └── docker-review/
+                    └── SKILL.md
+```
+
+```yaml {title="docker-review/spec.yaml"}
+schemaVersion: "2"
+kind: mixin
+name: docker-review
+displayName: Dockerfile review skill
+description: Ships a Claude Code skill that reviews Dockerfiles
+```
+
+```markdown {title="docker-review/files/workspace/.claude/skills/docker-review/SKILL.md"}
+---
+name: docker-review
+description: Review a Dockerfile for best practices. Use when the user asks to review, audit, or improve a Dockerfile.
+---
+
+When reviewing a Dockerfile, check:
+
+1. Base image — pinned tag or digest, appropriate for the workload
+2. Layer order — dependencies copied before application source
+3. Image size — multi-stage builds, `.dockerignore`, package-manager cache flags
+4. Security — non-root `USER`, no secrets in `ARG`/`ENV`
+5. Reproducibility — pinned package versions, frontend directive where relevant
+```
+
+Kits have to target the workspace rather than `~/.claude/` because
+sandboxes don't pick up user-level agent configuration from the host.
+See the
+[FAQ](../faq.md#why-doesnt-the-sandbox-use-my-user-level-agent-configuration)
+for details.
+
+## Customize agent settings
+
+Some agents combine settings from several files. When the agent supports it,
+place kit settings in a separate file instead of replacing
+[sandbox-managed agent configuration](kits.md#sandbox-managed-agent-configuration).
+
+Claude Code's `--settings` option loads an additional settings file. Extend the
+built-in `claude` kit to add the option without reproducing its configuration,
+and place the additional file outside the path the sandbox manages:
+
+```text
+claude-sonnet/
+├── spec.yaml
+└── files/
+    └── home/
+        └── .config/
+            └── claude/
+                └── sonnet.json
+```
+
+```yaml {title="claude-sonnet/spec.yaml"}
+schemaVersion: "2"
+kind: sandbox
+name: claude-sonnet
+extends: claude
+
+sandbox:
+  command:
+    - --dangerously-skip-permissions
+    - --settings
+    - /home/agent/.config/claude/sonnet.json
+```
+
+```json {title="claude-sonnet/files/home/.config/claude/sonnet.json"}
+{
+  "model": "sonnet"
+}
+```
+
+Claude Code merges the additional file with the sandbox-managed user settings.
+Because the file is under `files/home/`, it stays inside the sandbox instead of
+being written into a directly mounted host workspace. Launch the sandbox with
+the child kit's name:
+
+```console
+$ sbx run claude-sonnet --kit ./claude-sonnet
+```
+
+Proxy-managed OAuth isn't supported for a third-party kit that extends the
+built-in `claude` agent. Store an Anthropic API key on the host before the first
+launch:
+
+```console
+$ sbx secret set anthropic
+```
+
+When you launch the kit for the first time, `sbx` prompts you to approve its
+inherited Anthropic credentials. Because this is a third-party schema v2 kit,
+`sbx` records your approval as a
+[credential binding](../configuration/credentials.md#credential-bindings). The
+sandbox receives a sentinel value, and the proxy injects the real API key into
+requests to the domains declared by the kit.
+
+> [!WARNING]
+> The approval prompt also lists OAuth, but OAuth doesn't work for the extended
+> agent. If you use Claude Code's `/login` command, Claude Code stores the real
+> OAuth tokens inside the sandbox.
+
+OpenCode supports an additional config file through `OPENCODE_CONFIG`. Keep the
+kit's config separate from the sandbox-managed
+`/home/agent/.config/opencode/opencode.json`, for example at
+`/home/agent/.config/opencode/team.json`:
+
+```text
+opencode-team/
+├── spec.yaml
+└── files/
+    └── home/
+        └── .config/
+            └── opencode/
+                └── team.json
+```
+
+```yaml {title="opencode-team/spec.yaml"}
+schemaVersion: "2"
+kind: mixin
+name: opencode-team
+requires:
+  agent: opencode
+
+environment:
+  variables:
+    OPENCODE_CONFIG: /home/agent/.config/opencode/team.json
+```
+
+```json {title="opencode-team/files/home/.config/opencode/team.json"}
+{
+  "$schema": "https://opencode.ai/config.json",
+  "autoupdate": false
+}
+```
+
+OpenCode merges the custom file with its global and project config files. See
+the OpenCode [config precedence](https://opencode.ai/docs/config/#precedence-order)
+for the complete order.
+
+Agent settings mechanisms differ. If an agent doesn't support an additional
+config file, launch option, or environment variable for the setting, kits can't
+replace the sandbox-managed user settings before the agent launches.
+`setup.startup` doesn't gate the agent entrypoint, so don't use it for settings
+the agent must read during initialization.
+
+## Fork an existing agent
+
+Sandbox kits (`kind: sandbox`) define a full agent from scratch. The most
+common variant is a fork of a built-in agent. Use `extends:` to inherit the
+parent's complete configuration and declare only the fields you want to change.
+This example replaces the built-in `claude` entrypoint so Claude Code uses
+manual permission mode instead of bypassing approval prompts:
+
+```yaml {title="claude-safe/spec.yaml"}
+schemaVersion: "2"
+kind: sandbox
+name: claude-safe
+displayName: Claude Code (with approval prompts)
+description: Claude Code in manual permission mode
+
+extends: claude
+
+sandbox:
+  entrypoint: [claude, "--permission-mode", "manual"]
+```
+
+The child inherits the built-in image, credentials, network permissions,
+persistent volumes, settings, MCP integration, and agent instructions. Its
+`sandbox.entrypoint` replaces the inherited entrypoint. Proxy-managed OAuth
+isn't supported for the extended agent, so follow the
+[Anthropic API-key setup](#customize-agent-settings) before launching it.
+
+Launch with the kit's `name:` as the agent argument to `sbx run`:
+
+```console
+$ sbx run claude-safe --kit ./claude-safe
+```
+
+For a step-by-step walkthrough of building a new sandbox kit from
+scratch, see [Build an agent](build-an-agent.md).
+
+## More examples
+
+These patterns are all drawn from working kits in the
+[sbx-kits-contrib](https://github.com/docker/sbx-kits-contrib)
+repository, which contains each example as a complete, loadable kit.
+Use it to study the full shape of a kit, or load one directly:
+
+```console
+$ sbx run claude --kit "git+https://github.com/docker/sbx-kits-contrib.git#dir=<kit>"
+```
diff --git a/content/manuals/ai/sandboxes/customize/kit-reference.md b/content/manuals/ai/sandboxes/customize/kit-reference.md
new file mode 100644
index 000000000000..aa3aff28e1d1
--- /dev/null
+++ b/content/manuals/ai/sandboxes/customize/kit-reference.md
@@ -0,0 +1,518 @@
+---
+title: Kit spec reference
+linkTitle: Spec reference
+description: Field-by-field reference for a kit's spec.yaml, including credentials, network rules, environment, setup, files, agent instructions, and the sandbox block.
+keywords: sandboxes, sbx, kits, spec.yaml, reference, schema, fields
+weight: 50
+---
+
+{{< summary-bar feature_name="Docker Sandboxes sbx" >}}
+
+> [!NOTE]
+> Kits are experimental. The kit file format, CLI commands, and experience
+> for creating, loading, and managing kits are subject to change as the
+> feature evolves. Share feedback and bug reports in the
+> [docker/sbx-releases](https://github.com/docker/sbx-releases) repository.
+
+This page documents every field in a kit's `spec.yaml`. For an overview of
+what kits are and how to use them, see [Kits](kits.md).
+
+For the normative v2 grammar used by the parser and tests, see the
+[`schemaVersion: "2"` specification](https://github.com/docker/sbx-kits-contrib/blob/main/spec/SPEC-v2.md)
+in the `docker/sbx-kits-contrib` repository.
+
+A kit directory has a required `spec.yaml` and an optional `files/` tree:
+
+```text
+my-kit/
+├── spec.yaml       # required
+└── files/          # optional — static files to inject
+    ├── home/
+    └── workspace/
+```
+
+## Schema versions
+
+Starting with Docker Sandboxes version 0.36, two schema versions are supported.
+Use `schemaVersion: "2"` for new kits. Version `"1"` remains accepted through
+the legacy path.
+
+The loader forks on `schemaVersion`. A v2 spec uses the v2 grammar only. Legacy
+v1 fields in a `schemaVersion: "2"` spec are rejected during decode instead of
+being folded into the v2 model. Keep each `spec.yaml` on one grammar.
+
+What changed in v2:
+
+| v1                                          | v2                                       |
+| ------------------------------------------- | ---------------------------------------- |
+| `credentials.sources.<id>`                  | `credentials:` list entry with `service` |
+| `network.allowedDomains` / `deniedDomains`  | `permissions.network.allow` / `deny`     |
+| `network.serviceDomains` / `serviceAuth`    | `credentials[].apiKey.inject`            |
+| `network.publishedPorts` / `publishedPorts` | top-level `ports`                        |
+| standalone `oauth:` block                   | `credentials[].oauth`                    |
+| `oauth.skipIfEnv`                           | Accepted but ignored                     |
+| `environment.proxyManaged`                  | `credentials[].apiKey.proxyManaged`      |
+| `memory` / `agentContext`                   | `agentInstructions.content`              |
+| `kind: agent` / `agent:` block              | `kind: sandbox` / `sandbox:` block       |
+| `sandbox.aiFilename`                        | `agentInstructions.filename`             |
+| `sandbox.entrypoint.run`                    | `sandbox.entrypoint`                     |
+| `sandbox.entrypoint.args`                   | `sandbox.command.default`                |
+| `sandbox.entrypoint.ttyArgs`                | `sandbox.command.interactive`            |
+| `tmpfs:`                                    | `volumes:` entries with `type: tmpfs`    |
+| `volumes:` (mapping form)                   | `volumes:` sequence (`- path: <path>`)   |
+| `commands:` / `commands.initFiles`          | `setup:` / `setup.files`                 |
+| `settings:` / `kitDir` / `persistence`      | Removed                                  |
+
+Credential discovery also moved out of the kit in v2: a kit declares which
+credentials it needs and how to inject them, but where each value comes from is
+controlled by the user through
+[credential bindings](../configuration/credentials.md#credential-bindings).
+
+> [!NOTE]
+> `mixins` and `sandbox.build` are accepted by the parser, but runtime support
+> is pending. A kit that sets `sandbox.build` must also set `sandbox.image`.
+
+## Top-level fields
+
+```yaml
+schemaVersion: "2"
+kind: <mixin | sandbox>
+name: <name>
+version: <version>
+displayName: <name>
+description: <text>
+sourceURL: <url>
+licenses:
+  - MIT
+locked:
+  - sandbox.image
+security:
+  privileged: false
+```
+
+| Field           | Required | Description                                                                                     |
+| --------------- | -------- | ----------------------------------------------------------------------------------------------- |
+| `schemaVersion` | Yes      | Spec schema version. Use `"2"` for this grammar.                                                |
+| `kind`          | Yes      | `mixin` for kits that extend an agent; `sandbox` for kits that define one.                      |
+| `name`          | Yes      | Unique identifier. Lowercase alphanumeric with hyphens, 1 to 64 characters.                     |
+| `version`       | No       | Kit version.                                                                                    |
+| `displayName`   | No       | Human-readable name.                                                                            |
+| `description`   | No       | Short description.                                                                              |
+| `sourceURL`     | No       | Source repository or documentation URL.                                                         |
+| `licenses`      | No       | SPDX license identifiers.                                                                       |
+| `locked`        | No       | Dotted paths child kits may not override.                                                       |
+| `security`      | No       | Container security settings. `security.privileged: true` runs the container in privileged mode. |
+
+A kit also declares behavior blocks such as `agentInstructions`,
+`permissions`, `ports`, `credentials`, `environment`, `setup`, and `volumes`.
+
+## Kit kinds
+
+### `kind: mixin`
+
+A mixin layers capabilities onto an existing sandbox. It must not declare a
+`sandbox:` block, `extends:`, or `mixins:`. A mixin can declare `requires:` to
+pin the base agent it is designed for:
+
+```yaml
+schemaVersion: "2"
+kind: mixin
+name: github-tools
+requires:
+  agent: claude
+```
+
+`requires.agent` takes one base-agent name. It is validated as a kit name and
+enforced during composition.
+
+### `kind: sandbox`
+
+A sandbox kit defines a full agent. A root sandbox must declare a `sandbox:`
+block. A sandbox that uses `extends:` can inherit the parent image and omit its
+own `sandbox:` block:
+
+```yaml
+schemaVersion: "2"
+kind: sandbox
+name: claude-safe
+extends: claude
+```
+
+`extends:` is sandbox-only. The parent must resolve to a sandbox kit. `mixins:`
+is also sandbox-only and accepted by the parser, but runtime composition support
+is pending.
+
+## Sandbox block
+
+```yaml
+sandbox:
+  image: <image-ref>
+  build:
+    context: .
+    dockerfile: Dockerfile
+    args:
+      AGENT_VERSION: "1.0.0"
+    target: runtime
+    platforms:
+      - linux/amd64
+  entrypoint: [my-agent, "--flag"]
+  command:
+    default: ["--task-mode"]
+    interactive: []
+  resources:
+    cpu: 2
+    memory: 4g
+    gpu: "1"
+```
+
+| Field                | Required | Description                                                                                                     |
+| -------------------- | -------- | --------------------------------------------------------------------------------------------------------------- |
+| `sandbox.image`      | When `extends:` is omitted | Docker image reference.                                                                                         |
+| `sandbox.build`      | No       | Build configuration. Runtime support is pending, so a kit with `build:` must also set `image:`.                 |
+| `sandbox.entrypoint` | No       | Fixed process prefix as a string array. The first element is the agent binary.                                  |
+| `sandbox.command`    | No       | Mode-specific argument tail. Use a list shorthand for `default`, or a mapping with `default` and `interactive`. |
+| `sandbox.resources`  | No       | Optional CPU, memory, and GPU constraints. Memory uses byte-size strings such as `4096m` or `4g`.               |
+
+The effective command is `entrypoint` plus `command.default` for non-interactive
+launches, and `entrypoint` plus `command.interactive` for TTY sessions. If
+`interactive` is omitted, it falls back to `default`.
+
+For a kit that uses `extends:`, `sandbox.command` replaces the full inherited
+argument tail, including flags after the binary in the parent's
+`sandbox.entrypoint`. It doesn't append to that tail. Define every argument the
+child needs. For example, a child of `claude` that adds `--settings` must also
+include `--dangerously-skip-permissions` to preserve that behavior.
+
+The agent's container image must provide:
+
+- A non-root `agent` user at UID 1000 with passwordless sudo.
+- A `/home/agent/` home directory owned by `agent`.
+- HTTP proxy environment variables (`HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`) preserved across sudo.
+- The agent binary, either baked in or installed with [`setup.install`](#setup).
+
+Build on top of `docker/sandbox-templates:shell-docker` to get these base
+requirements.
+
+## Agent instructions
+
+```yaml
+agentInstructions:
+  filename: CLAUDE.md
+  content: |
+    Ruff is installed. Run `ruff check` before committing.
+```
+
+| Field      | Description                                                                                         |
+| ---------- | --------------------------------------------------------------------------------------------------- |
+| `filename` | AI profile filename. Meaningful for `kind: sandbox`; ignored with a warning for `kind: mixin`.      |
+| `content`  | Markdown instructions. For a sandbox, inlined into the profile. For a mixin, written to kit memory. |
+
+For mixins, the engine writes `content` to
+`<dir-of-AI-file>/kits-memory/<kit-name>.md` and adds a `## Kits` pointer
+section to the base AI file. This keeps each mixin's instructions in a separate
+file.
+
+## Credentials
+
+A kit declares the credentials it needs and how the proxy injects them into
+outbound requests. It does not declare a host discovery source. The user
+provides the value through the secret store or the first-run prompt, and a
+[credential binding](../configuration/credentials.md) authorizes its use. A kit
+can't read arbitrary host environment variables or files.
+
+```yaml
+credentials:
+  - service: <service-id>
+    description: <text> # optional
+    required: <true | false> # optional, default false
+    provider: <provider> # optional, reserved
+    apiKey:
+      name: <ENV_VAR>
+      proxyManaged: true
+      inject:
+        - domain: <domain>
+          header: <header>
+          format: <format>
+        - domain: <domain>
+          scheme: bearer
+        - domain: <domain>
+          scheme: basic
+          username: <user> # required with scheme: basic
+    oauth:
+      tokenEndpoint:
+        host: <host>
+        path: <path>
+      sentinels:
+        accessToken: <sentinel>
+        refreshToken: <sentinel>
+      credentialFile:
+        path: <path>
+        structure:
+          <key>:
+            accessToken: "{{.AccessToken}}"
+            refreshToken: "{{.RefreshToken}}"
+            expiresAt: "{{.ExpiresAt}}"
+            scopes: "{{.Scopes}}"
+```
+
+`credentials` is a list; each entry names a `service` and configures one or more
+auth mechanisms.
+
+| Field         | Description                                                                                                                                 |
+| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
+| `service`     | Credential identifier, matched against the value stored with `sbx secret set`. Lowercase kebab-case.                                        |
+| `description` | Optional. Shown to the user when approving a [binding](../configuration/credentials.md#credential-bindings).                                     |
+| `required`    | Marks the credential as essential to the agent. If it has no binding, `sbx` warns and starts with the credential withheld. Default `false`. |
+| `provider`    | Reserved for a provider registry. Accepted with a warning and no runtime effect.                                                            |
+| `apiKey`      | API-key injection (see [apiKey](#apikey)).                                                                                                  |
+| `oauth`       | OAuth interception (see [oauth](#oauth)).                                                                                                   |
+
+Each service must declare `apiKey`, `oauth`, or both. When both resolve at
+runtime, the API key takes precedence and OAuth acts as the fallback.
+
+### `apiKey`
+
+| Field               | Description                                                                                                                                       |
+| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `name`              | Environment variable name for the credential (for example, `ANTHROPIC_API_KEY`).                                                                  |
+| `proxyManaged`      | If `true`, `sbx` sets `name` inside the container to the `proxy-managed` sentinel. Default `false`.                                               |
+| `inject[].domain`   | Domain to inject the credential into. Must also be allowed in [`permissions.network`](#network).                                                  |
+| `inject[].header`   | HTTP header the proxy sets (for example, `x-api-key`, `Authorization`).                                                                           |
+| `inject[].format`   | Header value format, with one `%s` placeholder (for example, `"%s"` or `"Bearer %s"`). Mutually exclusive with `scheme`.                          |
+| `inject[].scheme`   | Shorthand for common auth schemes. `bearer` expands to `Authorization: Bearer %s`; `basic` requires `username`. Mutually exclusive with `format`. |
+| `inject[].username` | Username for HTTP Basic auth, for example `x-access-token` for Git over HTTPS.                                                                    |
+
+### `oauth`
+
+For agents that authenticate with OAuth (for example, Claude Code), the proxy
+intercepts token responses and replaces real tokens with sentinels, then swaps
+the real token back in on outbound requests. By default, the token never enters
+the sandbox. Setting `passthrough: true` opts out of sentinel masking and sends
+the real token response into the sandbox.
+
+| Field                                    | Description                                                                                                                                                                                       |
+| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `tokenEndpoint.host` / `path`            | The OAuth token endpoint the proxy intercepts.                                                                                                                                                    |
+| `sentinels.accessToken` / `refreshToken` | Sentinel values written into the container in place of the real tokens.                                                                                                                           |
+| `credentialFile.path`                    | Where to write the credential file inside the container (`~` expands).                                                                                                                            |
+| `credentialFile.structure`               | Declarative JSON shape. Supports `{{.AccessToken}}`, `{{.RefreshToken}}`, `{{.ExpiresAt}}`, and `{{.Scopes}}`.                                                                                   |
+| `credentialFile.template`                | Go template. Supports `{{.AccessToken}}`, `{{.RefreshToken}}`, `{{.ExpiresAt}}`, `{{.Scopes}}`, and `{{.ScopesJSON}}`.                                                                          |
+| `resourceHosts`                          | API hosts where the proxy attaches the token on outbound requests, distinct from the token endpoint host.                                                                                         |
+| `skipIfEnv`                              | Accepted for compatibility, but ignored for schema v2. A v2 binding is authoritative instead of host environment variables.                                                                       |
+| `responseFields`                         | Overrides the default field names the proxy reads from the token response.                                                                                                                        |
+| `passthrough`                            | If `true`, the proxy passes the token response through unchanged instead of replacing the tokens with sentinels.                                                                                  |
+
+`credentialFile.structure` provides a declarative alternative to
+`credentialFile.template`. The engine renders it as well-formed JSON. If both
+fields are set, `structure` takes precedence.
+
+## Network
+
+Network egress is declared under `permissions.network`. Credentials no longer carry
+their own domain mapping — the proxy injects a credential only into the domains
+its [`apiKey.inject`](#apikey) lists, and every domain the
+sandbox reaches must be allowed here.
+
+```yaml
+permissions:
+  network:
+    allow: [<domain>, ...]
+    deny: [<domain>, ...]
+```
+
+| Field                       | Description                                                                                                     |
+| --------------------------- | --------------------------------------------------------------------------------------------------------------- |
+| `permissions.network.allow` | Domains the sandbox can reach.                                                                                  |
+| `permissions.network.deny`  | Domains the sandbox is blocked from reaching. Deny takes precedence over allow, including across composed kits. |
+
+Allow and deny patterns:
+
+| Pattern               | Example                  | Status                      |
+| --------------------- | ------------------------ | --------------------------- |
+| Exact host            | `api.example.com`        | Enforced                    |
+| Exact host and port   | `api.example.com:8080`   | Enforced                    |
+| Single-label wildcard | `*.example.com`          | Enforced                    |
+| Multi-label wildcard  | `**.example.com`         | Parsed; enforcement pending |
+| Port range            | `api.example.com:80-443` | Parsed; enforcement pending |
+| Port wildcard         | `api.example.com:*`      | Parsed; enforcement pending |
+| CIDR                  | `10.0.0.0/8`             | Parsed; enforcement pending |
+
+In v1 this was the `network:` block (`allowedDomains` / `deniedDomains`, plus
+`serviceDomains` / `serviceAuth`). In v2, those fields are decode errors.
+
+## Ports
+
+Use `ports` to expose sandbox services to the host:
+
+```yaml
+ports:
+  - container: 8080
+    protocol: tcp
+    name: web
+```
+
+| Field       | Description                                                         |
+| ----------- | ------------------------------------------------------------------- |
+| `container` | Container port, 1 to 65535.                                         |
+| `protocol`  | `tcp` or `udp`. Empty means `tcp`.                                  |
+| `name`      | Optional label surfaced by tools that list published port bindings. |
+
+Host ports are allocated ephemerally on `127.0.0.1`. Users can pin host ports
+with `sbx ports --publish <host>:<container>`.
+
+## Environment
+
+```yaml
+environment:
+  variables:
+    <NAME>: <value>
+```
+
+| Field       | Description                                    |
+| ----------- | ---------------------------------------------- |
+| `variables` | Key-value pairs set directly in the container. |
+
+Variable names must be valid shell identifiers (`[A-Za-z_][A-Za-z0-9_]*`).
+
+Do not set `DASH_`, `SBX_`, or `DOCKER_` variables, and avoid overriding
+`HOME`, `USER`, `SHELL`, `PATH`, `LD_PRELOAD`, and `LD_LIBRARY_PATH`. The
+runtime reserves these names and may override them.
+
+## Setup
+
+```yaml
+setup:
+  install:
+    - command: <shell-string>
+      user: <uid>
+      description: <text>
+  startup:
+    - command: [<argv>, ...]
+      user: <uid>
+      background: <true | false>
+      description: <text>
+  files:
+    - path: <path>
+      content: <text>
+      mode: <octal>
+      onlyIfMissing: <true | false>
+      description: <text>
+```
+
+### Execution order
+
+When a sandbox is created, kit content is applied in this order:
+
+1. Network permissions and environment variables.
+2. Static files under `files/home/`.
+3. `setup.install` commands, in declaration order.
+4. `setup.files` entries.
+5. `setup.startup` commands are registered for each sandbox start.
+6. Static files under `files/workspace/`, after the workspace is ready. With
+   `--clone`, this means after the repository has been cloned.
+
+For stacked kits, entries in each stage are applied in `--kit` order. An install
+command can consume a bundled file from `files/home/`, but not one from
+`files/workspace/` or `setup.files`, because those files land later.
+
+`sbx kit add` recreates the sandbox rather than modifying it in place. It
+supports mixin kits limited to
+`environment.variables`, `setup.install`, and `permissions.network.allow`,
+which follow the same order as sandbox creation. It rejects a kit that declares
+static files, `setup.startup`, or `setup.files`. To use those fields, recreate
+the sandbox with the kit.
+
+### install
+
+Runs synchronously when a kit is applied, either during sandbox creation or
+through `sbx kit add`. Shell strings are passed to `sh -c`.
+
+| Field         | Default | Description                   |
+| ------------- | ------- | ----------------------------- |
+| `command`     | —       | Shell command string.         |
+| `user`        | `"0"`   | User to run as. `"0"` = root. |
+| `description` | —       | Human-readable description.   |
+
+### startup
+
+Runs at every sandbox start. String array, not interpreted by a shell.
+
+| Field         | Default  | Description                         |
+| ------------- | -------- | ----------------------------------- |
+| `command`     | —        | Command and args as a string array. |
+| `user`        | `"1000"` | User to run as. `"1000"` = agent.   |
+| `background`  | `false`  | Block later startup commands until this command finishes. Set to `true` to let later commands run without waiting. |
+| `description` | —        | Human-readable description.         |
+
+Startup commands are non-interactive. They run before the agent
+attaches, with no terminal connected, so they can't prompt the user
+(for example, an interactive `aws login` will hang or fail). They also
+don't gate the agent's entrypoint: the agent launches once startup
+commands have been dispatched, regardless of `background`. A value of
+`false` waits within the startup dispatcher before it runs the next command;
+it doesn't delay the agent entrypoint. Use startup commands
+for work that can run alongside the agent. Use `setup.files` for any value that
+needs to land on disk before the agent runs.
+
+Startup commands must be idempotent. They run on every sandbox start
+and replay on container restarts, so a command that fails or
+misbehaves on a second invocation breaks the restart path. Guard
+work with existence checks, use upserts instead of inserts, and
+prefer commands that converge to the same end state regardless of
+how many times they run.
+
+### files
+
+Files written at sandbox start, with runtime substitution.
+
+| Field           | Default  | Description                                               |
+| --------------- | -------- | --------------------------------------------------------- |
+| `path`          | —        | Absolute container path.                                  |
+| `content`       | —        | File content. `${WORKDIR}` expands to the workspace path. |
+| `mode`          | `"0644"` | File permissions in octal.                                |
+| `onlyIfMissing` | `false`  | Skip if the file already exists.                          |
+
+The runtime writes these files as the agent user with UID 1000. The target
+path must be writable by that user. To write to a root-owned path such as
+`/etc`, use an `install` command, which runs as root by default. Set ownership
+in the install command if the agent needs to modify the file later.
+
+## Static files
+
+```text
+my-kit/files/
+├── home/       → /home/agent/
+└── workspace/  → primary workspace path
+```
+
+| Kit path           | Container destination                   |
+| ------------------ | --------------------------------------- |
+| `files/home/`      | `/home/agent/` (config files, dotfiles) |
+| `files/workspace/` | The primary workspace path              |
+
+Parent directories are created automatically. Existing files are
+overwritten. Absolute paths and path-traversal sequences (`../../`) are
+rejected.
+
+## Volumes
+
+```yaml
+volumes:
+  - path: /workspace
+    size: 10g
+    mode: "0755"
+  - path: /tmp/scratch
+    type: tmpfs
+    size: 512m
+    mode: "1777"
+```
+
+| Field  | Description                                                         |
+| ------ | ------------------------------------------------------------------- |
+| `path` | Required absolute container path.                                   |
+| `type` | Empty for a block-backed volume, or `tmpfs` for RAM-backed storage. |
+| `size` | Optional byte-size string.                                          |
+| `mode` | Optional octal permissions.                                         |
+
+Volumes are applied only when a sandbox is created. `sbx kit add` cannot attach
+volumes to a running container.
diff --git a/content/manuals/ai/sandboxes/customize/kits.md b/content/manuals/ai/sandboxes/customize/kits.md
new file mode 100644
index 000000000000..92e5bef2bf87
--- /dev/null
+++ b/content/manuals/ai/sandboxes/customize/kits.md
@@ -0,0 +1,533 @@
+---
+title: Kits
+description: Extend a sandbox with tools, credentials, network rules, and configuration using declarative YAML artifacts.
+keywords: sandboxes, sbx, kits, mixins, customization, extensions, agents
+weight: 20
+---
+
+{{< summary-bar feature_name="Docker Sandboxes sbx" >}}
+
+> [!NOTE]
+> Kits are experimental. The kit file format, CLI commands, and experience
+> for creating, loading, and managing kits are subject to change as the
+> feature evolves. Share feedback and bug reports in the
+> [docker/sbx-releases](https://github.com/docker/sbx-releases) repository.
+
+A kit packages a set of capabilities a sandbox can use, such as:
+
+- Tools to install
+- Environment variables to set
+- Credentials to inject
+- Network rules to allow or deny domains
+- Files to drop in
+- Startup commands to run
+- Memory instructions to give the agent
+
+You declare these in a single `spec.yaml` file, point the CLI at the
+directory (or a ZIP, OCI artifact, or Git URL), and the sandbox applies
+and enforces them at runtime. Credentials stay on the host and go through
+a proxy instead of entering the VM, and outbound traffic is restricted to
+the domains permitted by the kit's network rules.
+
+A kit is either a mixin or a sandbox:
+
+- Mixin kits (`kind: mixin`) extend an existing agent with extra
+  capabilities. Stack several on the same sandbox.
+- Sandbox kits (`kind: sandbox`) define a full agent from scratch: its image,
+  entrypoint, network policies, and everything else the agent needs.
+
+## What kits can do
+
+### Run commands
+
+A kit can run commands inside the sandbox automatically. **Install
+commands** run once at creation; **startup commands** run each time
+the sandbox starts.
+
+Install commands are the place to put anything an agent needs into the
+image, via `apt`, `pip`, `npm`, `curl | bash`, or whatever fits:
+
+```yaml
+setup:
+  install:
+    - command: "apt-get update && apt-get install -y jq"
+```
+
+Startup commands are for work that can run alongside the agent, such as a
+background service. They must be idempotent — see the
+[`startup`](kit-reference.md#startup) spec reference:
+
+```yaml
+setup:
+  startup:
+    - command: ["my-daemon"]
+      background: true
+```
+
+### Inject files
+
+Kits can inject files into the sandbox in two ways: **static files** bundled
+with the kit, and **`setup.files`** written at startup with runtime values
+substituted in.
+
+Static files work well for content that doesn't vary between sandboxes, such
+as tool configurations, shared linter rules, helper scripts the agent can
+invoke, or reference material like a style guide or API cheatsheet.
+
+```text
+my-kit/
+├── spec.yaml
+└── files/
+    ├── home/
+    │   └── .config/my-tool/settings.json
+    └── workspace/
+        └── .editorconfig
+```
+
+`setup.files` cover content that depends on runtime values, such as an
+absolute workspace path that a tool needs to bake into its config file
+at startup:
+
+```yaml
+setup:
+  files:
+    - path: /home/agent/.my-tool/config.json
+      content: '{"workspace": "${WORKDIR}"}'
+      onlyIfMissing: true
+```
+
+See [`setup.files`](kit-reference.md#files) in the spec reference for all
+fields.
+
+#### Sandbox-managed agent configuration
+
+Built-in agent kits reserve the following paths for sandbox setup. Treat these
+paths as sandbox-managed, even if a file is only needed for a particular
+feature. Don't target them with static files, `setup.files`, or install
+commands. Later setup can replace your content or depend on settings that your
+file removes. In this table, `~` is `/home/agent`.
+
+| Built-in agent kit | Managed configuration paths |
+| ------------------ | --------------------------- |
+| `claude` | `~/.claude.json`, `~/.claude/settings.json`, `~/.claude/.config.json` |
+| `codex` | `~/.codex/config.toml` |
+| `copilot` | `~/.copilot/config.json` |
+| `cursor` | `~/.cursor/cli-config.json` |
+| `gemini` | `~/.gemini/settings.json` |
+| `kiro` | `~/.kiro/settings/mcp.json` |
+| `opencode` | `~/.config/opencode/opencode.json` |
+
+Use a separate settings layer when the agent supports one. For example, Claude
+Code can load an additional settings file with `--settings`, and OpenCode can
+load one from the path in `OPENCODE_CONFIG`. See
+[Customize agent settings](kit-examples.md#customize-agent-settings) for
+examples. Don't use `setup.startup` for settings the agent must read during
+initialization because startup commands don't gate the agent entrypoint.
+
+### Set environment variables
+
+Environment variables set by the kit are available to the agent at
+runtime:
+
+```yaml
+environment:
+  variables:
+    MY_TOOL_WORKSPACE: /home/agent/my-tool
+```
+
+For credentials, see
+[Authenticate to external services](#authenticate-to-external-services).
+Don't put secret values directly in `environment.variables` — they'd
+be visible inside the sandbox VM.
+
+> [!IMPORTANT]
+> The sandbox manages proxy settings for you. It sets `HTTP_PROXY`,
+> `HTTPS_PROXY`, `NO_PROXY`, and their lowercase equivalents automatically so
+> that traffic flows through its built-in forward proxy, which enforces
+> network policy and injects credentials. Leave these variables to the
+> sandbox — setting them in a kit points traffic away from the forward proxy,
+> so it can no longer apply network policy or inject credentials, and those
+> requests typically fail to connect. To send sandbox traffic through an
+> upstream corporate proxy, configure it on the host. See
+> [Upstream proxy](../architecture.md#upstream-proxy).
+
+### Control network access
+
+Network rules define which domains the sandbox can reach or block. Kit
+network rules apply only to sandboxes that use the kit:
+
+```yaml
+permissions:
+  network:
+    allow:
+      - api.example.com
+      - "*.cdn.example.com"
+    deny:
+      - telemetry.example.com
+```
+
+Use `allow` for hosts the agent needs, such as package
+registries, install endpoints, or external APIs. Use `deny` for
+hosts the agent should not reach, such as telemetry endpoints. If a domain
+matches both an allow rule and a deny rule, the deny rule wins.
+
+> [!IMPORTANT]
+> When organization governance is active, only organization allow rules grant
+> access, so kit-defined `allow` rules are ignored — including any domains a kit
+> allows for the agent to reach. Kit-defined `deny` rules still apply, because a
+> deny can only restrict access further. For details, see
+> [Policy precedence](../governance/concepts.md#precedence).
+
+For authenticated services, see
+[Authenticate to external services](#authenticate-to-external-services).
+
+### Authenticate to external services
+
+A kit can attach credentials to outbound requests through the
+host-side proxy. The agent inside the VM works with a sentinel value;
+the proxy reads the real credential on the host and overwrites the
+auth header before the request leaves the sandbox.
+
+A kit declares the service, the in-container environment variable, and how
+to inject the credential. It doesn't declare a host discovery source. The user
+provides the value through the secret store or first-run prompt, and a
+[credential binding](../configuration/credentials.md) authorizes its use:
+
+```yaml
+credentials:
+  - service: my-service
+    apiKey:
+      name: MY_SERVICE_API_KEY # in-VM env var, set to a sentinel
+      proxyManaged: true
+      inject:
+        - domain: api.example.com # inject on requests to this domain
+          header: Authorization # overwrite this header
+          format: "Bearer %s"
+
+permissions:
+  network:
+    allow:
+      - api.example.com # the domain must also be reachable
+```
+
+The agent boots with `MY_SERVICE_API_KEY=proxy-managed`, sends a
+request with that sentinel in `Authorization`, and the proxy overwrites
+the header with the real credential before forwarding. The real
+secret never enters the VM.
+
+See [Credentials](../configuration/credentials.md) for how to provide the
+credential value on your host, other approaches for cases the example
+above doesn't fit, and what the proxy does at request time. See
+[Credential bindings](../configuration/credentials.md) to approve the mechanisms
+and domains declared by a third-party v2 kit.
+
+### Inject agent memory
+
+A kit can append content to the agent's memory file, such as `CLAUDE.md`
+or `AGENTS.md`. The agent reads this file at startup. Use it to give
+the agent project conventions, usage tips for a tool the kit installs,
+or other guidance that should be in scope when the sandbox runs.
+
+```yaml
+agentInstructions:
+  content: |
+    Ruff is installed. Run `ruff check` before committing.
+    Shared config lives at `/workspace/ruff.toml`.
+```
+
+Both mixin and sandbox kits can declare `agentInstructions.content`. The active
+sandbox kit sets `agentInstructions.filename`, which determines the memory
+file's name. The sandbox kit's content is written inline in that file. Each
+mixin's content is written to its own `<kit-name>.md` file under a sibling
+`kits-memory/` directory, and the main memory file gets a `## Kits` section that
+points to each mixin file:
+
+```text
+/Users/you/
+├── myproject/              # workspace
+├── AGENTS.md               # main memory file with a "## Kits" index
+└── kits-memory/
+    ├── ruff-lint.md
+    ├── vale.md
+    └── git-ssh-sign.md
+```
+
+See [`agentInstructions`](kit-reference.md#agent-instructions) in the spec
+reference for the full field schema.
+
+### Define an agent
+
+Sandbox kits declare a `sandbox:` block with the image the agent runs in and
+the command the user attaches to when they launch the sandbox:
+
+```yaml
+sandbox:
+  image: "my-registry/my-agent:latest"
+  entrypoint: [my-agent, "--yolo"]
+```
+
+See [Sandbox kits](#sandbox-kits) for use cases and an example.
+
+## Mixin kits
+
+A mixin kit extends an existing agent with extra capabilities. Common use
+cases:
+
+- Pre-install tools: linters, libraries, or other custom programs
+- Grant the agent access to a new authenticated service (a database, a
+  vendor API)
+- Inject shared team config (linter rules, editor settings, dotfiles)
+
+See [Drop a shared config file](kit-examples.md#drop-a-shared-config-file) and
+[Install a tool at sandbox creation](kit-examples.md#install-a-tool-at-sandbox-creation)
+for complete mixin examples.
+
+## Sandbox kits
+
+A sandbox kit defines a full agent from scratch — image, entrypoint, and
+everything the agent needs. Common use cases:
+
+- Package a custom agent you've built so others can run it
+- Ship a team-internal agent with defaults baked in
+- Run a fork of an existing agent with your own config
+- Prototype a new agent integration
+
+Sandbox kits declare everything a mixin kit can, plus an
+[`sandbox:` block](kit-reference.md#sandbox-block) that tells the sandbox how to launch the
+agent. For a step-by-step walkthrough, see
+[Build your own agent kit](build-an-agent.md).
+
+### Extend a built-in agent
+
+Use `extends:` to create a variant of a built-in agent without reproducing its
+configuration. The child kit inherits the parent's image, credentials, network
+permissions, persistent volumes, settings, MCP integration, and agent
+instructions. Use `extends:` for a single parent agent; use a mixin to add an
+independent capability that can work with one or more agents. See
+[Fork an existing agent](kit-examples.md#fork-an-existing-agent) for an example
+that changes Claude Code's permission mode.
+
+## Using kits
+
+Kits can be loaded from a local path (a directory or ZIP file), a Git
+repository, or an OCI registry. Pass `--kit` more than once to stack
+several kits on the same sandbox.
+
+> [!IMPORTANT]
+> `--kit` only takes effect when a sandbox is created. Passing it against an
+> existing sandbox name fails with
+> `--kit can only be used when creating a new sandbox`. To add a supported
+> mixin kit to a running sandbox, use [`sbx kit add`](#local) instead.
+> `sbx kit add` restarts the sandbox to apply the updated kit set.
+> VM state — installed packages, Docker images, volumes, and agent history
+> — is preserved across the restart. It supports mixin kits limited to
+> `environment.variables`, `setup.install`, and `permissions.network.allow`.
+> To use other fields, recreate the sandbox with `--kit`.
+
+### Local
+
+Point `--kit` at a directory or ZIP file on disk:
+
+```console
+$ sbx run claude --kit ./my-kit/
+$ sbx run claude --kit ./my-kit-1.0.zip
+```
+
+While iterating on a supported mixin kit, apply changes to a running sandbox
+with `sbx kit add`:
+
+```console
+$ sbx kit add my-sandbox ./my-kit/
+```
+
+`sbx kit add` restarts the sandbox to apply the updated kit set.
+VM state — installed packages, Docker images, volumes, and agent history — is
+preserved across the restart. Kits can't be removed from a running sandbox —
+remove and recreate it to start clean.
+
+### Git repository
+
+```console
+$ sbx run claude --kit "git+https://github.com/docker/sbx-kits-contrib.git#ref=v0.1.0&dir=code-server"
+```
+
+- `#ref=<branch|tag|commit>` pins to a specific revision. Defaults to the
+  repository's default branch.
+- `#dir=<path>` loads a kit from a subdirectory.
+- `git+ssh://` URLs also work, using your local SSH agent, Git credential
+  helpers, and `.netrc`.
+- Quote the URL in shells where `&` starts a background job.
+
+### OCI registry
+
+```console
+$ sbx run claude --kit ghcr.io/myorg/my-kit:1.0
+```
+
+For Docker Hub, include the full `docker.io` prefix. See
+[Packaging and distribution](#packaging-and-distribution) for publishing.
+
+> [!IMPORTANT]
+> For Docker Hub, `sbx` reuses your `sbx login` session to pull private
+> kits. For other registries, store pull credentials with
+> [`sbx secret set --registry`](../configuration/credentials.md#registry-credentials)
+> before running the sandbox:
+>
+> ```console
+> $ gh auth token | sbx secret set --registry ghcr.io --password-stdin
+> ```
+>
+> Without stored credentials, pulls from non-Docker Hub registries are
+> anonymous and private kits fail to pull.
+
+### Restrict kit sources
+
+`sbx` restricts which sources a kit can install from. A kit's install
+commands run with root privileges inside the sandbox, so limiting where kits
+come from reduces supply-chain risk. By default, only kits hosted on Docker
+Hub (`docker.io/`) are allowed. Loading a kit from any other source fails:
+
+```console
+$ sbx run claude --kit "git+https://github.com/docker/sbx-kits-contrib.git#dir=vale"
+ERROR: resolve kits: kit "git+https://github.com/docker/sbx-kits-contrib.git#dir=vale" cannot be installed — its source is not in your allowlist.
+```
+
+To allow another publisher, add its host or host/path prefix to the
+`kit.allowedSources` setting. The setting replaces the whole list, so include
+the entries you want to keep:
+
+```console
+$ sbx settings set kit.allowedSources '["docker.io/","github.com/docker/"]'
+```
+
+Entries match as prefixes on a path-segment boundary, so `github.com/docker/`
+allows `github.com/docker/sbx-kits-contrib` but not `github.com/docker-evil/kit`.
+To remove the restriction and allow any remote source, set the list to
+`["*"]`. This isn't recommended.
+
+Installing from a local directory or ZIP file is governed separately by the
+`kit.allowLocalKits` setting, which defaults to `true`. Set it to `false` to
+require a remote source:
+
+```console
+$ sbx settings set kit.allowLocalKits false
+```
+
+For non-interactive use, both settings have environment-variable equivalents:
+`DOCKER_SANDBOXES_KIT_ALLOWED_SOURCES` and `DOCKER_SANDBOXES_KIT_ALLOW_LOCAL`.
+
+## Sign and verify kits
+
+Use cosign-compatible Sigstore signatures to verify who approved a kit and
+that its signed content hasn't changed. Signing is keyless by default. Verify a
+keyless signature with the certificate identity and OpenID Connect (OIDC)
+issuer:
+
+```console
+$ sbx kit sign ./my-kit/
+$ sbx kit verify \
+    --certificate-identity user@example.com \
+    --certificate-oidc-issuer https://accounts.google.com \
+    ./my-kit/
+```
+
+For key-based signing, use an ECDSA P-256 key pair:
+
+```console
+$ sbx kit sign --key cosign.key ./my-kit/
+$ sbx kit verify --key cosign.pub ./my-kit/
+```
+
+For a local directory, `sbx kit sign` writes a `kit.sig.bundle` file next to
+`spec.yaml`. Commit this file so consumers can verify a kit loaded from the Git
+repository. For an OCI kit, the signature is stored as an OCI referrer. You can
+sign an OCI kit after pushing it, or push and sign it in one step:
+
+```console
+$ sbx kit push ./my-kit/ ghcr.io/myorg/my-kit:1.0 --sign
+```
+
+ZIP kits can't carry verifiable signatures.
+
+### Require signed kits
+
+Set a trusted signer policy for the identities or keys you trust before
+requiring signatures. Otherwise, `sbx` uses the default policy, which trusts
+Docker employee identities attested by Google's OpenID Connect issuer. A
+keyless policy must specify both the certificate identity and its OpenID
+Connect issuer:
+
+```console
+$ sbx settings set kit.trustedSigners \
+    '[{"identity":"release-bot@example.com","issuer":"https://accounts.google.com"}]'
+$ sbx settings set kit.requireSignature true
+```
+
+To trust a key-based signature, set the policy to the public key path:
+
+```console
+$ sbx settings set kit.trustedSigners '[{"key":"/path/to/cosign.pub"}]'
+$ sbx settings set kit.requireSignature true
+```
+
+When `kit.requireSignature` is `true`, `sbx` rejects unsigned kits, signatures
+that don't match `kit.trustedSigners`, and ZIP kits. This policy applies when a
+kit is loaded from a local directory, Git repository, or OCI registry.
+
+The signature covers `spec.yaml` and the kit's `files/` content, but not mutable
+dependencies such as image tags or content downloaded by install and startup
+commands. Pin those dependencies by digest or checksum when they must remain
+immutable.
+
+## Packaging and distribution
+
+The `sbx kit` subcommands validate, inspect, and publish kits:
+
+- `sbx kit validate <path>` — check that a kit directory or ZIP is
+  well-formed.
+- `sbx kit inspect <path>` — display kit details. Add `--json` for
+  machine-readable output.
+- `sbx kit pack <path> -o <file.zip>` — package a directory as a ZIP file
+  for sharing.
+- `sbx kit push <path> <ref>` — publish to an OCI registry (for example,
+  `ghcr.io/myorg/my-kit:1.0`).
+- `sbx kit pull <ref>` — download a kit from a registry as a ZIP file to
+  the working directory.
+
+For Docker Hub, include the full `docker.io` prefix — `sbx` doesn't add it
+automatically.
+
+`sbx kit pull` prefers credentials stored with
+[`sbx secret set --registry`](../configuration/credentials.md#registry-credentials),
+falling back to the Docker credential store. `sbx kit push` only uses the
+Docker credential store, so pushing to a private registry requires a prior
+`docker login`.
+
+## Spec reference
+
+For a field-by-field reference of every `spec.yaml` block — top-level
+fields, credentials, network, environment, setup, static files,
+agent instructions, and the sandbox block — see [Kit spec reference](kit-reference.md).
+
+## Debugging
+
+When a kit doesn't behave as expected, start with the network policy log
+and direct inspection inside the sandbox:
+
+- `sbx policy log` shows every outbound request the sandbox proxy saw,
+  the rule it matched, extra context when available, and its `PROXY`
+  value, such as `forward`, `forward-bypass`, `transparent`, or
+  `browser-open`. Use it to diagnose install-time download failures,
+  blocked domains, and unexpected TLS interception. If downloads fail or
+  arrive corrupted after you add a credential's `apiKey.inject`, check
+  whether an injection domain is too broad. Inject only on the hosts that
+  need credentials.
+- `sbx exec <sandbox> -- <cmd>` runs an arbitrary command inside an
+  existing sandbox. Useful for inspecting post-install state without
+  recreating: `which mytool`, `ls /home/agent/.local/bin/`,
+  `cat /home/agent/.config/...`, and so on.
+
+Install and startup command output is only emitted during `sbx run` or
+`sbx create`; `sbx` doesn't retain it for later inspection. To repeat
+setup with fresh output, remove and recreate the sandbox:
+`sbx rm <sandbox> && sbx run ...`.
diff --git a/content/manuals/ai/sandboxes/customize/templates.md b/content/manuals/ai/sandboxes/customize/templates.md
new file mode 100644
index 000000000000..72bcade5d944
--- /dev/null
+++ b/content/manuals/ai/sandboxes/customize/templates.md
@@ -0,0 +1,251 @@
+---
+title: Templates
+weight: 10
+description: Build reusable sandbox images with tools and configuration baked in, or save a running sandbox as a template.
+keywords: sandboxes, sbx, templates, images, dockerfile, snapshot, custom environments
+---
+
+{{< summary-bar feature_name="Docker Sandboxes sbx" >}}
+
+Every sandbox is customizable — agents install packages, pull images, and
+configure tools as they work, and those changes persist for the sandbox's
+lifetime. Templates capture a configured environment into a reusable image
+so you don't have to set it up again every time.
+
+## Custom templates
+
+Custom templates are reusable sandbox images that extend one of the built-in
+agent environments with additional tools and configuration baked in. Instead
+of asking the agent to install packages every time, build a template once and
+reuse it across sandboxes and team members.
+
+Templates make sense when multiple people need the same environment, when
+setup involves steps that are tedious to repeat, or when you need pinned
+versions of specific tools. For one-off work, the default image is fine —
+ask the agent to install what's needed.
+
+> [!NOTE]
+> Custom templates customize an existing agent's environment — they don't
+> create new agent runtimes. The agent that launches inside the sandbox is
+> determined by the base image variant you extend and the agent you specify
+> in the `sbx run` command, not by binaries installed in the template. To
+> define a new agent from scratch, see [Kits](kits.md#define-an-agent).
+
+### Base images
+
+All sandbox templates are published as
+`docker/sandbox-templates:<variant>`. They are based on Ubuntu and run as a
+non-root `agent` user with sudo access. Most variants include Git, Docker
+CLI, and common development tools like Node.js, Python, Go, and Java.
+
+| Variant               | Agent                                                                |
+| --------------------- | -------------------------------------------------------------------- |
+| `claude-code`         | [Claude Code](https://claude.ai/download)                            |
+| `claude-code-minimal` | Claude Code with a minimal toolset (no Node.js, Python, Go, or Java) |
+| `codex`               | [OpenAI Codex](https://github.com/openai/codex)                      |
+| `copilot`             | [GitHub Copilot](https://github.com/github/copilot-cli)              |
+| `cursor-agent`        | [Cursor](https://cursor.com/cli)                                     |
+| `docker-agent`        | [Docker Agent](https://github.com/docker/docker-agent)               |
+| `droid`               | [Droid](https://www.factory.ai)                                      |
+| `gemini`              | [Gemini CLI](https://github.com/google-gemini/gemini-cli)            |
+| `kiro`                | [Kiro](https://kiro.dev)                                             |
+| `opencode`            | [OpenCode](https://opencode.ai)                                      |
+| `shell`               | No agent pre-installed. Use for manual agent setup.                  |
+
+Each variant also has a `-docker` version (for example, `claude-code-docker`)
+that includes a full Docker Engine running inside the sandbox — no local Docker
+daemon required. When you pick a built-in agent without specifying a custom
+template, `sbx run` and `sbx create` use the `-docker` template variants by
+default.
+
+The agent containers created from the `-docker` templates run in privileged
+mode inside the microVM (not on your host), with a dedicated block volume at
+`/var/lib/docker`, and `dockerd` starts automatically inside the sandbox. The
+block volume defaults to 50 GB and uses a sparse file, so it only consumes
+disk space as Docker writes to it.
+
+To override the volume size, set the `DOCKER_SANDBOXES_DOCKER_SIZE`
+environment variable to a size string before starting the sandbox:
+
+```console
+$ DOCKER_SANDBOXES_DOCKER_SIZE=10g sbx run claude
+```
+
+Use the non-Docker variant if you don't need to build or run containers
+inside the sandbox and want a lighter, non-privileged environment. Specify
+it explicitly with `--template`:
+
+```console
+$ sbx run claude --template docker.io/docker/sandbox-templates:claude-code
+```
+
+### Build a custom template
+
+Building a custom template requires
+[Docker Desktop](/manuals/desktop/_index.md).
+
+Write a Dockerfile that extends one of the base images. Pick the variant
+that matches the agent you plan to run. For example, extend `claude-code`
+to customize a Claude Code environment, or `codex` to customize an OpenAI
+Codex environment.
+
+The following example creates a Claude Code template with Rust and
+protocol buffer tools pre-installed:
+
+```dockerfile
+FROM docker/sandbox-templates:claude-code
+USER root
+RUN apt-get update && apt-get install -y protobuf-compiler
+USER agent
+RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
+```
+
+Use `root` for system-level package installations (`apt-get`), and switch
+back to `agent` before installing user-level tools. Tools that install into
+the home directory, such as `rustup`, `nvm`, or `pyenv`, must run as
+`agent` — otherwise they install under `/root/` and aren't available in
+the sandbox.
+
+Build the image and push it to an OCI registry, such as Docker Hub:
+
+```console
+$ docker build -t my-org/my-template:v1 --push .
+```
+
+> [!NOTE]
+> The Docker daemon used by Docker Sandboxes pulls templates from a
+> registry directly; it doesn't share the image store of your local Docker
+> daemon on the host.
+
+> [!IMPORTANT]
+> For Docker Hub, `sbx` reuses your `sbx login` session to pull private
+> images. For other registries (GitHub Container Registry, ECR, ACR, a
+> self-hosted Nexus, and so on), store pull credentials with
+> [`sbx secret set --registry`](../configuration/credentials.md#registry-credentials)
+> before running the sandbox:
+>
+> ```console
+> $ gh auth token | sbx secret set --registry ghcr.io --password-stdin
+> ```
+>
+> Without stored credentials, pulls from non-Docker Hub registries are
+> anonymous and private images fail to pull.
+
+For locally-built images, save the image to a tar and load it directly
+into the sandbox runtime instead of pulling from a registry:
+
+```console
+$ docker image save my-org/my-template:v1 -o my-template.tar
+$ sbx template load my-template.tar
+$ sbx run --template my-org/my-template:v1 claude
+```
+
+`sbx template load` imports the tar into the sandbox runtime's image
+store, so the image doesn't need to be reachable from a registry at
+sandbox creation time.
+
+Unless you use the permissive `allow-all` network policy, you may also need
+to allow-list any domains that your custom tools depend on:
+
+```console
+$ sbx policy allow network "*.example.com:443,example.com:443"
+```
+
+Then run a sandbox with your template. The agent you specify must match
+the base image variant your template extends:
+
+```console
+$ sbx run --template docker.io/my-org/my-template:v1 claude
+```
+
+Because this template extends the `claude-code` base image, you run it
+with `claude`. If you extend `codex`, use `codex`; if you extend `shell`,
+use `shell` (which drops you into a Bash shell with no agent).
+
+> [!NOTE]
+> Unlike Docker commands, `sbx` does not automatically resolve the Docker
+> Hub domain (`docker.io`) in image references.
+
+### Template caching
+
+Template images are cached locally. The first use pulls from the registry;
+subsequent sandboxes reuse the cache. Cached images persist across sandbox
+creation and deletion, and are cleared when you run `sbx reset`.
+
+## Saving a sandbox as a template
+
+Instead of writing a Dockerfile, you can save a running sandbox's state as
+a template. This captures installed packages, configuration changes, and
+files into a reusable image — useful when you've set up an environment
+interactively and want to preserve it.
+
+> [!WARNING]
+> Saving a sandbox captures its entire filesystem, including any secrets
+> stored on it. If you manually added API keys, tokens, or other
+> credentials to the sandbox, they're embedded in the saved template and
+> shared with anyone you distribute it to. To keep credentials out of
+> templates, manage them with `sbx secret set` instead — the proxy injects
+> them at runtime so they're never written to the filesystem. For more
+> information, see [Manage credentials](../configuration/credentials.md).
+
+### Save and reuse
+
+Stop the sandbox (or let the CLI prompt you), then save it with a name and
+tag:
+
+```console
+$ sbx template save my-sandbox my-template:v1
+```
+
+The image is stored in the sandbox runtime's local image store. Create a
+new sandbox from it with the `-t` flag:
+
+```console
+$ sbx run -t my-template:v1 claude
+```
+
+### List and remove templates
+
+List all saved templates:
+
+```console
+$ sbx template ls
+```
+
+Remove a template you no longer need:
+
+```console
+$ sbx template rm my-template:v1
+```
+
+### Export and import
+
+To share a saved template or move it to another machine, export it as a
+tar file:
+
+```console
+$ sbx template save my-sandbox my-template:v1 --output my-template.tar
+```
+
+On the other machine, load the tar file and use it:
+
+```console
+$ sbx template load my-template.tar
+$ sbx run -t my-template:v1 claude
+```
+
+### Limitations
+
+Agent configuration files are always recreated when a sandbox is created.
+Changes to user-level agent configuration files, such as
+`/home/agent/.claude/settings.json` and `/home/agent/.claude.json`, do not
+persist in saved templates.
+
+If the saved template was built for a different agent than the one you
+specify in `sbx run`, you get a warning. For example, saving a Claude
+sandbox and running it with `codex` produces:
+
+```text
+⚠ WARNING: template "my-template:v1" was built for the "claude" agent but you are using "codex".
+  The sandbox may not work correctly. Consider using: sbx run -t my-template:v1 claude
+```
diff --git a/content/manuals/ai/sandboxes/faq.md b/content/manuals/ai/sandboxes/faq.md
new file mode 100644
index 000000000000..b02ddfb783a0
--- /dev/null
+++ b/content/manuals/ai/sandboxes/faq.md
@@ -0,0 +1,214 @@
+---
+title: FAQ
+weight: 140
+description: Frequently asked questions about Docker Sandboxes.
+keywords: docker sandboxes, sbx, faq, sign in, telemetry, clipboard, image paste, pricing, commercial use, allowlist, firewall, domains, proxy
+---
+
+## Is Docker Sandboxes free? Can I use it commercially?
+
+Yes to both. The `sbx` CLI is free to use, including for commercial and
+professional work, with no per-seat fee. Install it, sign in with a free
+Docker account, and run sandboxes at no cost.
+
+The only paid component is organization governance: centrally managed network,
+filesystem, and MCP policies,
+[sign-in enforcement](governance/monitor-and-enforce/sign-in-enforcement.md),
+and [audit logs](governance/audit/). These
+[organization governance features](governance/) require a separate paid
+subscription —
+[contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
+to get started. Everything else, including running agents in isolated
+sandboxes, is free.
+
+## Why do I need to sign in?
+
+Docker Sandboxes is built around the idea that you and your agents are a team.
+Signing in gives each sandbox a verified identity, which lets Docker:
+
+- **Tie sandboxes to a real person.** Governance matters when agents can build
+  containers, install packages, and push code. Your Docker identity is the
+  anchor.
+- **Enable team features.** Team-scale features like
+  [organization governance](governance/), shared environments, and audit logs
+  need a concept of "who," and adding that later would be worse for everyone.
+- **Authenticate against Docker infrastructure.** Sandboxes pull images, run
+  daemons, and talk to Docker services. A Docker account authenticates those
+  requests.
+
+Your Docker account email is only used for authentication, not marketing.
+
+## Can I enforce sandbox policies across my organization?
+
+Yes. Admins can centrally manage network, filesystem, and MCP policies. These
+controls apply to every sandbox in the organization. When organization
+governance is active, only organization allow rules grant access: local allow
+rules set with `sbx policy` are no longer evaluated, while local deny rules
+still apply on top.
+
+See [Organization policies](governance/access-controls/organization.md). This
+feature requires a separate paid subscription —
+[contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
+to get started.
+
+## Which domains do I need to allow for Docker Sandboxes to work?
+
+If your organization restricts outbound network access with a firewall or
+proxy, add the following domains to your allowlist so that `sbx` can
+authenticate, pull images, and report diagnostics.
+
+| Domain                                             | Description             |
+| -------------------------------------------------- | ----------------------- |
+| https://login.docker.com                           | Authentication          |
+| https://hub.docker.com                             | Docker Hub              |
+| https://api.docker.com                             | Docker API              |
+| https://marlin-2.docker.com                        | Telemetry               |
+| https://marlin-api.docker.com                      | Telemetry               |
+| https://registry-1.docker.io                       | Docker pull/push        |
+| https://auth.docker.io                             | Registry authentication |
+| https://dhi.io                                     | Docker Hardened Images  |
+| https://sbx-diagnostics.s3.us-east-1.amazonaws.com | Diagnostics upload      |
+
+## Does the CLI collect telemetry?
+
+The `sbx` CLI collects basic usage data about CLI invocations:
+
+- Which command you ran
+- Whether it succeeded or failed
+- How long it took
+- If you're signed in, your Docker username is included
+
+Docker Sandboxes doesn't monitor sessions, read your prompts, or access your
+code. Your code stays in the sandbox and on your host.
+
+To opt out of all analytics, set the `SBX_NO_TELEMETRY` environment variable:
+
+```console
+$ export SBX_NO_TELEMETRY=1
+```
+
+## How do I set custom environment variables inside a sandbox?
+
+Starting with `sbx` version 0.39.0, use `-e`/`--env` or `--env-file` with
+`sbx run` and `sbx create`. See
+[Set environment variables](usage.md#set-environment-variables) for syntax,
+precedence rules, persistent configuration for an existing sandbox, and
+guidance for credentials.
+
+Variables in `/etc/sandbox-persistent.sh` are available to interactive sessions
+and agents started with `sbx run`. A variable only takes effect for sessions
+and agents started after it's added. Restart a running agent, or stop and start
+the sandbox, to pick up the new value.
+
+## Why do agents run without approval prompts?
+
+The sandbox itself is the safety boundary. Because agents run inside an
+isolated microVM with [network policies](governance/access-controls/network.md),
+[credential isolation](security/isolation.md#credential-isolation), and no access to your host
+system outside explicitly shared paths, the usual reasons for approval prompts
+(preventing destructive commands, network access, file modifications) are
+handled by the sandbox isolation layers instead.
+
+If you prefer to re-enable approval prompts, change the permission mode
+inside the session. Most agents let you switch permission modes after
+startup. In Claude Code, use the `/permissions` command to change the mode
+interactively.
+
+To make approval prompts the default for every session, define a custom
+sandbox kit that overrides the agent's entrypoint to drop the
+permission-skipping flag. For example, a kit that launches Claude Code
+without `--dangerously-skip-permissions`:
+
+```yaml {title="claude-safe/spec.yaml"}
+schemaVersion: "1"
+kind: sandbox
+name: claude-safe
+sandbox:
+  image: "docker/sandbox-templates:claude-code-docker"
+  entrypoint:
+    run: [claude]
+```
+
+Run it with `sbx run claude-safe --kit ./claude-safe/`. See
+[Sandbox kits](customize/kits.md#sandbox-kits) for the full pattern.
+
+## How do I know if my agent is running in a sandbox?
+
+Ask the agent. The agent can see whether or not it's running inside a sandbox.
+In Claude Code, use the `/btw` slash command to ask without interrupting an
+in-progress task:
+
+```text
+/btw are you running in a sandbox?
+```
+
+## Why doesn't the sandbox use my user-level agent configuration?
+
+Sandboxes don't import your complete user-level agent configuration. Hooks,
+settings, and other files under directories such as `~/.claude` remain on the
+host. Project-level configuration in the working directory remains available
+inside the sandbox.
+
+Shared agent skills are the exception. Run `sbx skills import` to copy skills
+from supported host directories into a persistent store shared with
+sandboxes. See [Share agent skills](workflows/agent-skills.md) for the
+supported directories, mount behavior, and per-sandbox opt-out.
+
+Keep project-specific skills and other agent configuration in the project
+itself. This versions the configuration alongside the code. Don't use symlinks
+to host paths because a sandboxed agent can't follow them outside the sandbox.
+
+## Can I paste images into an agent?
+
+Yes, but it's off by default. Text paste already works, because the terminal
+sends it directly. Pasting an image or screenshot with `Ctrl+V` is different:
+the agent reads it from your host clipboard, and the sandbox blocks that access
+unless you opt in.
+
+Turn it on with a local setting:
+
+```console
+$ sbx settings set clipboard.imagePaste true
+```
+
+`Ctrl+V` then pastes host images into agents that read the clipboard, including
+Claude Code and Codex. The setting takes effect within a few seconds, even for
+running sandboxes.
+
+This is opt-in because it relaxes the sandbox's isolation: when enabled, a process
+inside the sandbox can read your host clipboard through the host-side proxy. The
+exposure is narrow — reads happen only on a paste, return image data only
+(`image/png`), and clipboard content is never cached or logged — but it's still
+host data crossing into the sandbox, so it stays off until you turn it on.
+
+To turn it back off:
+
+```console
+$ sbx settings set clipboard.imagePaste false
+```
+
+## Can I use Docker Sandboxes on headless Linux?
+
+Yes. On Linux, `sbx` stores secrets in the Secret Service exposed by your
+desktop keyring, such as GNOME Keyring or KDE Wallet. Headless servers and some
+WSL setups have no running Secret Service, so `sbx` falls back to a file under
+`$XDG_CONFIG_HOME/com.docker.sandboxes`, which defaults to
+`~/.config/com.docker.sandboxes` when `$XDG_CONFIG_HOME` is unset. No setup is
+required. When you store a secret on such a host, `sbx` prints a notice:
+
+```text
+No keychain detected - this secret will be stored on disk, protected by file permissions rather than a password
+```
+
+`sbx` stores the file in a directory with `0700` permissions, the same
+file-permission model used for `~/.docker/config.json`. Any user or process that
+can read the file can retrieve the stored credentials, so treat the directory as
+sensitive. Where available, prefer a keychain, which mediates access per
+application.
+
+To keep secrets in a keyring instead, run a Secret Service on the host before
+storing them: install `gnome-keyring` and start `dbus-run-session`, or run the
+keyring daemon under a login session that unlocks it. Once a working Secret
+Service is available, `sbx` stores new
+secrets in the keychain again. For where each platform keeps secrets, see
+[Where secrets are stored](configuration/credentials.md#where-secrets-are-stored).
diff --git a/content/manuals/ai/sandboxes/get-started.md b/content/manuals/ai/sandboxes/get-started.md
new file mode 100644
index 000000000000..81aa8685b477
--- /dev/null
+++ b/content/manuals/ai/sandboxes/get-started.md
@@ -0,0 +1,188 @@
+---
+title: Get started with Docker Sandboxes
+linkTitle: Get started
+weight: 20
+description: Configure agent credentials and work through your first Docker Sandboxes session.
+keywords: sandbox, sbx, get started, credentials, clone mode, network policy
+---
+
+Docker Sandboxes run AI coding agents in isolated microVM sandboxes. Each
+sandbox gets its own Docker daemon, filesystem, and network — the agent can
+build containers, install packages, and modify files without touching your host
+system.
+
+This page walks through your first session: run an agent in a sandbox, see how
+the sandbox isolates it, control what it can reach on the network, and clean
+up.
+
+## Prerequisites
+
+- [Install the `sbx` CLI](install.md) and sign in to Docker
+- Configure an authentication method for the agent you want to use. Most agents
+  require an API key for their model provider. See the [agent pages](agents/)
+  for provider-specific instructions.
+
+## Authenticate your agent
+
+For Claude Code with a Claude subscription (Max, Team, or Enterprise), no
+upfront setup is needed — use the `/login` command inside the sandbox to sign
+in with OAuth. The session token stays on your host and is never stored inside
+the sandbox.
+
+If you prefer to authenticate with an API key, see
+[Credentials](configuration/credentials.md) for how to store one with
+`sbx secret set`.
+
+To give the agent access to GitHub for creating pull requests or interacting
+with repositories:
+
+```console
+$ sbx secret set github --command 'gh auth token'
+```
+
+## Run your first sandbox
+
+Pick a project directory and launch an agent with
+[`sbx run`](/reference/cli/sbx/run/):
+
+```console
+$ cd ~/my-project
+$ sbx run --name my-sandbox claude
+```
+
+The first time you run a sandbox, the CLI prompts you to choose a default
+network preset:
+
+```plaintext
+Initialize the global network policy for your sandboxes:
+
+  Applies to all sandboxes, current and future — change it later with
+  "sbx policy allow/deny/rm". Kits, including built-in agent kits, may
+  also add per-sandbox rules.
+
+     1. Open         — All network traffic allowed, no restrictions.
+  ❯  2. Balanced     — Default deny, with common dev sites allowed.
+     3. Locked Down  — All network traffic blocked unless you allow it.
+
+  Use ↑/↓ or 1–3 to navigate, Enter to confirm, Esc to cancel.
+```
+
+**Balanced** is a good starting point — it permits traffic to common
+development services while blocking everything else. You can adjust individual
+rules later. See [Local policy](governance/access-controls/local.md) for a full
+description of each option.
+
+Replace `claude` with the agent you want to use — see [Agents](agents/) for the
+full list.
+
+The first run takes a little longer while the agent image is pulled. Subsequent
+runs reuse the cached image and start in seconds.
+
+This attaches you to the agent running inside the sandbox. Give it a real
+task — ask it to add a feature, install a dependency, or build and run your
+project. The agent has a full Linux environment with its own Docker daemon, so
+it can install packages, build images, and start containers on its own while it
+works.
+
+## See what the agent can touch
+
+From another terminal, list your sandboxes:
+
+```console
+$ sbx ls
+SANDBOX       AGENT    STATUS    PORTS   WORKSPACE
+my-sandbox    claude   running           ~/my-project
+```
+
+Each row shows a sandbox's name, the agent running in it, its status, any
+[published ports](usage.md#publish-ports), and its
+workspace — the host directory shared into the sandbox. That workspace is the
+one part of your machine the agent can see.
+
+By default, the workspace is shared read-write, so the agent and your host see
+the same files. Edits the agent makes to your project appear in your working
+tree as it writes them, and you review them as an ordinary Git diff before
+committing.
+
+Everything else runs inside the microVM, isolated from your host:
+
+- The agent has its own filesystem, Docker daemon, and network.
+- Packages it installs, images it pulls, and containers it starts stay inside
+  the sandbox. Your host system is untouched, and removing the sandbox discards
+  them.
+
+If you'd rather the agent not touch your working tree at all — for example,
+when running several agents on one repository — use
+[clone mode](usage.md#clone-mode), which gives it a private clone instead.
+
+## Control what the agent can reach
+
+Isolation isn't only about the filesystem. You also control what the sandbox
+can reach on the network. You chose a default policy before the sandbox
+started, and you can inspect or adjust it at any time.
+
+Check which rules are in effect:
+
+```console
+$ sbx policy ls
+```
+
+To allow a specific host:
+
+```console
+$ sbx policy allow network registry.npmjs.org
+```
+
+With **Locked Down**, even your model provider API is blocked unless you
+explicitly allow it. With **Balanced**, common development services are
+permitted by default. See
+[local policy](governance/access-controls/local.md) for the full rule set
+and how to customize it.
+
+## Clean up
+
+Sandboxes persist after the agent exits, so you can stop one and pick up where
+you left off later:
+
+```console
+$ sbx stop my-sandbox
+```
+
+Installed packages, Docker images, and configuration changes are preserved
+across restarts. When you're done with a sandbox, remove it to reclaim disk
+space:
+
+```console
+$ sbx rm my-sandbox
+```
+
+Removing a sandbox deletes everything inside it — installed packages, Docker
+images, and the in-sandbox Git clone if you used clone mode. Files in your
+host working tree are unaffected.
+
+## What's next
+
+You've run an agent, seen how the sandbox isolates it, and controlled its
+network access. A few directions from here.
+
+Run `sbx` with no arguments to open the interactive dashboard: a live view of
+every sandbox where you can attach to agents, open shells, and manage network
+rules from one place.
+
+![The interactive dashboard showing sandbox status, resource usage, and network governance controls.](images/sbx-dashboard.png)
+
+Then explore:
+
+- [Usage guide](usage.md) — basic commands, reconnecting, workspaces, and port
+  publishing.
+- [Workflow patterns](workflows/) — Git strategies, local services, CI, and
+  authenticated tools.
+- [Sandbox environment files](configuration/environment-files.md) — declare and share
+  repeatable local sandbox configurations with `.sbxenv.yaml`. Requires `sbx`
+  0.39.0 or later.
+- [Customize with kits](customize/) — package an agent, its tools, and its
+  network rules into a reusable definition you launch with a single flag.
+- [Agents](agents/) — the full list of supported agents and how to configure
+  each one.
+- [Governance](governance/) — centrally manage network, filesystem, and MCP
+  policies across a team.
diff --git a/content/manuals/ai/sandboxes/governance/_index.md b/content/manuals/ai/sandboxes/governance/_index.md
new file mode 100644
index 000000000000..4db45c542720
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/_index.md
@@ -0,0 +1,72 @@
+---
+title: Governance
+weight: 120
+description: Control what sandboxes can access, from local developer rules to org-wide enforcement.
+keywords: docker sandboxes, governance, policy, network access, filesystem access, mcp policy, organization policy
+---
+
+Sandbox governance covers the policy system that controls what sandboxes can
+access over the network, on the filesystem, and through MCP. For MCP setup and
+server registration, see [MCP gateway](../mcp-gateway.md). Governance operates
+at two layers:
+
+**Local policy** is configured per machine using the `sbx policy` CLI. It
+lets individual developers customize which domains their sandboxes can reach.
+See [Local policy](access-controls/local.md).
+
+**Organization policy** is configured centrally in Docker Home. Network and
+filesystem policies can also be managed via the
+[Governance API](/reference/api/ai-governance/). Controls defined at the org
+level apply uniformly across every sandbox in the organization. Organization
+governance can also include MCP policies for sandbox MCP activity. When
+organization governance is active, only organization allow rules grant access:
+local `sbx policy` allow rules are no longer evaluated, while local deny rules
+still apply on top. See
+[Organization policies](access-controls/organization.md).
+
+Alongside this access-control policy, admins can require developers to sign in
+as members of their organization before using sandboxes at all.
+[Sign-in enforcement](monitor-and-enforce/sign-in-enforcement.md) is deployed
+through endpoint management and ensures developers can't bypass organization
+policy by using a personal account.
+
+> [!NOTE]
+> Organization governance is available on a separate paid subscription.
+> [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
+> to request access.
+
+## Learn more
+
+Start with [Policy concepts](concepts.md) for the resource model, rule syntax,
+MCP policy basics, evaluation, and precedence.
+
+### Access controls
+
+- [Local policy](access-controls/local.md): configure network rules on your
+  machine with the `sbx policy` CLI.
+- [Organization policies](access-controls/organization.md): centrally manage
+  sandbox policies across your organization.
+- [Network access policies](access-controls/network.md): control outbound network
+  access from sandboxes.
+- [Filesystem access policies](access-controls/filesystem.md): control which
+  host paths sandboxes can mount as workspaces.
+- [MCP access policies](access-controls/mcp.md): control MCP server registration,
+  tool calls, resources, prompts, and approval gates.
+
+### Monitor and enforce
+
+- [Monitoring policies](monitor-and-enforce/monitoring.md): inspect active
+  rules and monitor sandbox network traffic with `sbx policy ls` and
+  `sbx policy log`.
+- [Audit logs](audit/): view, configure, export, and collect governance audit
+  records.
+- [Sign-in enforcement](monitor-and-enforce/sign-in-enforcement.md): require
+  developers to sign in as organization members, enforced through endpoint
+  management.
+
+### Reference
+
+- [AI Governance API](/reference/api/ai-governance/): manage network and
+  filesystem org policies programmatically.
+- [MCP policy reference](reference/mcp-policy.md): look up Docker MCP policy
+  actions, resources, attributes, context fields, and approval behavior.
diff --git a/content/manuals/ai/sandboxes/governance/access-controls/_index.md b/content/manuals/ai/sandboxes/governance/access-controls/_index.md
new file mode 100644
index 000000000000..a2d2e1ff1f3c
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/access-controls/_index.md
@@ -0,0 +1,27 @@
+---
+title: Access controls
+weight: 20
+description: Configure local and organization controls for sandbox network, filesystem, and MCP access.
+keywords: docker sandboxes, access controls, governance, network access, filesystem access, MCP access
+---
+
+Access controls are expressed as policies. Local and organization pages
+describe where policies apply. Network and filesystem pages describe the rules
+inside those policies. MCP policies use Cedar statements instead of the network
+and filesystem rule format.
+
+## Policy scope
+
+- [Local policy](local.md): configure network rules on a developer machine with
+  the `sbx policy` CLI.
+- [Organization policies](organization.md): manage centralized policies for an
+  organization or team.
+
+## Access surfaces
+
+- [Network access policies](network.md): control outbound network access from
+  sandboxes.
+- [Filesystem access policies](filesystem.md): control which host paths
+  sandboxes can mount as workspaces.
+- [MCP access policies](mcp.md): control MCP server registration, tool calls,
+  resources, prompts, and approval gates with Cedar policy.
diff --git a/content/manuals/ai/sandboxes/governance/access-controls/filesystem.md b/content/manuals/ai/sandboxes/governance/access-controls/filesystem.md
new file mode 100644
index 000000000000..7445a10d42f4
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/access-controls/filesystem.md
@@ -0,0 +1,55 @@
+---
+title: Filesystem access policies
+linkTitle: Filesystem access
+weight: 40
+description: Control which host paths Docker Sandboxes can mount as workspaces with organization filesystem policies.
+keywords: docker sandboxes, filesystem access, filesystem rules, workspace mount, organization policy, governance
+---
+
+Filesystem access policies control which host paths a sandbox can mount as a
+workspace. Each policy contains one or more rules that restrict sandbox
+workspaces to approved directories.
+
+Filesystem access is managed with [organization policies](organization.md). When
+organization governance is active, organization rules determine which paths a
+sandbox can mount, and the local filesystem allow rules from the default preset
+become inactive. `sbx policy deny` applies to network access only, so there are
+no local filesystem deny rules to layer on top. See
+[Precedence](../concepts.md#precedence).
+
+## Rule syntax
+
+Filesystem rules use the actions `read` and `write`. Resources are host path
+patterns.
+
+A writable workspace mount must be allowed by both a `read` rule and a `write`
+rule. A read-only workspace needs only `read`.
+
+Examples:
+
+- `~/**`
+- `/data/project/**`
+- `C:\data\project\**`
+- `\\wsl.localhost\<distro>\data\project\**`
+
+Use `**` to match a directory tree recursively. A single `*` matches only one
+path segment. For exact path matching behavior across macOS, Linux, Windows,
+and WSL, see [Filesystem rules](../concepts.md#filesystem-rules).
+
+## Organization filesystem rules
+
+Organization filesystem rules belong to policies that can apply to the whole
+organization or to selected teams. For setup steps and team scoping, see
+[Organization policies](organization.md).
+
+Filesystem policy is checked when a workspace is mounted, which happens when a
+sandbox is created. To apply a filesystem policy change to a running workflow,
+remove the sandbox and create a new one.
+
+## Troubleshooting
+
+### Sandbox cannot mount workspace
+
+If a sandbox fails to mount with a `mount policy denied` error, verify that the
+filesystem allow rule uses `**` rather than `*`. A single `*` doesn't match
+across directory separators.
diff --git a/content/manuals/ai/sandboxes/governance/access-controls/local.md b/content/manuals/ai/sandboxes/governance/access-controls/local.md
new file mode 100644
index 000000000000..566138f474e6
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/access-controls/local.md
@@ -0,0 +1,212 @@
+---
+title: Local policy
+weight: 10
+description: Configure local network access rules for sandboxes on your machine.
+keywords: docker sandboxes, local policy, network access, allow rules, deny rules, sbx policy
+aliases:
+  - /ai/sandboxes/security/policy/
+  - /ai/sandboxes/governance/local/
+---
+
+The `sbx policy` command manages the local policy on your machine. The local
+policy contains network access rules. Rules apply to all sandboxes on the
+machine when you use the global scope, or to a single sandbox when scoped by
+name.
+
+Local policy interacts with organization governance as follows:
+
+- **No org governance**: the local policy controls what sandboxes can access.
+- **Org governance active**: only organization allow rules grant access, so
+  local allow rules are inactive and can't expand what the organization permits.
+  Local deny rules are still evaluated, so you can restrict access further than
+  the organization policy does. To list inactive rules, run
+  `sbx policy ls --include-inactive`. See
+  [Monitoring](../monitor-and-enforce/monitoring.md#showing-inactive-rules).
+
+See [Organization policies](organization.md) for how organization governance
+works.
+
+For domain patterns, wildcards, CIDR ranges, and filesystem path syntax, see
+[Policy concepts](../concepts.md#rule-syntax).
+
+## Default preset
+
+Outbound TCP traffic passes through a proxy on your host, which enforces access
+rules on every connection. Non-HTTP TCP traffic, including SSH, can be allowed
+with a hostname rule (for example, `sbx policy allow network "myhost:22"`) or an
+address-based rule. UDP and ICMP are blocked at the network layer and can't be
+unblocked with policy rules.
+
+If you haven't chosen a default preset, the CLI prompts you before it runs a
+sandbox. Running `sbx policy reset` clears the preset and prompts you to choose
+again:
+
+```plaintext
+Initialize the global network policy for your sandboxes:
+
+  Applies to all sandboxes, current and future — change it later with
+  "sbx policy allow/deny/rm". Kits, including built-in agent kits, may
+  also add per-sandbox rules.
+
+     1. Open         — All network traffic allowed, no restrictions.
+  ❯  2. Balanced     — Default deny, with common dev sites allowed.
+     3. Locked Down  — All network traffic blocked unless you allow it.
+
+  Use ↑/↓ or 1–3 to navigate, Enter to confirm, Esc to cancel.
+```
+
+| Preset      | Description                                                                                                                                       |
+| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Open        | All outbound traffic is allowed. Equivalent to adding a wildcard allow rule with `sbx policy allow network "**"`.                                 |
+| Balanced    | Default deny, with a baseline allowlist covering AI provider APIs, package managers, code hosts, container registries, and common cloud services. |
+| Locked Down | All outbound traffic is blocked, including model provider APIs (for example, `api.anthropic.com`). You must explicitly allow everything you need. |
+
+The **Balanced** preset's baseline allowlist is a good starting point for most
+workflows. Run `sbx policy ls` to see exactly which rules it includes. As of
+v0.35.0, the Balanced preset also allows VS Code domains, Azure Blob Storage
+(`*.blob.core.windows.net`), and `dhi.io` over HTTP.
+
+> [!NOTE]
+> If your organization manages sandbox policies centrally, organization rules
+> take precedence over the preset you select here. See
+> [Organization policies](organization.md).
+
+### Non-interactive environments
+
+In non-interactive environments such as CI pipelines or headless servers, the
+interactive prompt can't be displayed. Use `sbx policy init` to set the
+preset before running any other `sbx` commands:
+
+```console
+$ sbx policy init balanced
+```
+
+Available values are `allow-all`, `balanced`, and `deny-all`.
+
+## Managing rules
+
+Use [`sbx policy allow`](/reference/cli/sbx/policy/allow/) and
+[`sbx policy deny`](/reference/cli/sbx/policy/deny/) to add or restrict access
+on top of the active preset. Changes take effect immediately. Rules apply to
+all sandboxes by default:
+
+```console
+$ sbx policy allow network api.anthropic.com
+$ sbx policy deny network ads.example.com
+```
+
+Pass `--sandbox <name>` to scope a rule to one sandbox:
+
+```console
+$ sbx policy allow network --sandbox my-sandbox api.example.com
+$ sbx policy deny network --sandbox my-sandbox ads.example.com
+```
+
+As of v0.38.0, you can also set per-sandbox deny rules at creation time with
+`--deny-network` on `sbx create` or `sbx run`, instead of adding them after the
+fact:
+
+```console
+$ sbx create --deny-network ads.example.com claude .
+$ sbx run --deny-network ads.example.com claude
+```
+
+Pass the flag multiple times to deny more than one host. Rules added this way
+appear in `sbx policy ls <name>` and can be removed with
+`sbx policy rm network --sandbox <name> --resource <host>`.
+
+Specify multiple hosts in one command with a comma-separated list:
+
+```console
+$ sbx policy allow network "api.anthropic.com,*.npmjs.org,*.pypi.org"
+```
+
+Remove a rule by resource or by rule ID:
+
+```console
+$ sbx policy rm network --resource ads.example.com
+$ sbx policy rm network --id 2d3c1f0e-4a73-4e05-bc9d-f2f9a4b50d67
+```
+
+To remove a sandbox-scoped rule, pass `--sandbox <name>`:
+
+```console
+$ sbx policy rm network --sandbox my-sandbox --resource api.example.com
+```
+
+To inspect which policies are active and where they come from, use
+`sbx policy ls`. Use `--source` to filter by origin (`local`, `org`, `kit`),
+`--decision` to filter by outcome (`allow`, `deny`), and `--wide` for
+rule-level detail including rule IDs. To inspect a single policy or rule in
+full, use `sbx policy inspect`. See
+[Monitoring](../monitor-and-enforce/monitoring.md).
+
+## Testing policy
+
+Before running a sandbox, you can check whether the current policy would allow
+a network request with `sbx policy check network`:
+
+```console
+$ sbx policy check network api.anthropic.com
+Allowed: api.anthropic.com
+
+$ sbx policy check network blocked.example.com
+Denied: blocked.example.com
+```
+
+The target can be a hostname, a `host:port` pair, an IP address, or a URL.
+Bare hostnames and IP addresses are evaluated against port 443. This is useful
+for verifying custom rules or checking what the Locked Down preset blocks
+before you start an agent.
+
+To check policy in the context of a specific sandbox:
+
+```console
+$ sbx policy check network --sandbox my-sandbox api.example.com
+```
+
+### Resetting
+
+To remove all custom rules and start fresh with a new preset, use
+`sbx policy reset`:
+
+```console
+$ sbx policy reset
+```
+
+This deletes the local policy store, restarts the daemon, and prompts you to
+choose a new preset. Running sandboxes stop when the daemon shuts down. Pass
+`--force` to skip the confirmation prompt:
+
+```console
+$ sbx policy reset --force
+```
+
+## Troubleshooting
+
+### Local allow rules have no effect
+
+If rules you add with `sbx policy allow` don't change sandbox behavior, your
+organization likely has governance enabled. Run `sbx policy ls` to check: if
+the output starts with a `Governance:` status line showing `Managed by <org>`,
+org governance is active. When it's active, local allow rules are inactive.
+You can't use them to loosen restrictions the org policy imposes.
+
+Inactive allow rules are hidden from `sbx policy ls` by default; run
+`sbx policy ls --include-inactive` to see them with an `inactive` status in
+the `STATUS` column.
+
+When organization governance is active, only organization allow rules can grant
+access. Ask your admin to update the organization policy if you need access to
+an additional resource. Local deny rules remain active, so you can use
+`sbx policy deny` to restrict access further.
+
+### A domain is still blocked after adding an allow rule
+
+If a domain remains blocked after you add a local allow rule, your organization
+likely enforces governance, which makes local allow rules inactive. Run `sbx
+policy ls` to check whether org governance is active; if the output starts with
+a `Governance:` status line showing `Managed by <org>`, it is. Add
+`--include-inactive` to confirm your rule shows an `inactive` status. If so,
+the block can only be lifted by updating the org policy in Docker Home or via
+the [API](/reference/api/ai-governance/).
diff --git a/content/manuals/ai/sandboxes/governance/access-controls/mcp.md b/content/manuals/ai/sandboxes/governance/access-controls/mcp.md
new file mode 100644
index 000000000000..07475cb8984d
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/access-controls/mcp.md
@@ -0,0 +1,245 @@
+---
+title: MCP access policies
+linkTitle: MCP access
+weight: 50
+description: Use Cedar-based policies to control MCP server registration and activity routed through the Docker Sandboxes MCP gateway.
+keywords: docker sandboxes, MCP policy, MCP access, Cedar policy, requireApproval, AI Governance
+---
+
+MCP access policies let organization administrators control which Model
+Context Protocol (MCP) servers developers can register and what agents can do
+through Docker's MCP gateway. Use these policies to approve trusted servers,
+withdraw access to a server, require approval for tool calls, and restrict
+host-run servers. To register MCP servers and connect them to sandboxes, see
+[MCP gateway](../../mcp-gateway.md).
+
+MCP access policies apply only to server registration and requests handled by
+Docker's MCP gateway. They don't govern an MCP server that an agent or MCP
+client configures and connects to directly from inside the sandbox. A direct
+connection to a remote MCP server is outbound sandbox traffic, so
+[network access policy](network.md) determines whether the sandbox can reach
+the server. To prevent access through both paths, block the server in MCP
+access policy and block its network destination in network access policy.
+
+Unlike [network access policies](network.md) and
+[filesystem access policies](filesystem.md), MCP policies are organization
+policies written in Cedar. Docker defines the `MCP` namespace, including the
+actions, resource types, attributes, and approval behavior that policies can
+match. This page focuses on representative access patterns. For Docker's exact
+policy surface, see the [MCP policy reference](../reference/mcp-policy.md). For
+Cedar syntax and language semantics, see the
+[Cedar documentation](https://docs.cedarpolicy.com/).
+
+## Govern the server lifecycle
+
+MCP policy applies at two points in a server's lifecycle. A rule for one point
+doesn't automatically govern the other.
+
+| Admin decision                             | Evaluation point                            | Match with                                                                 |
+| ------------------------------------------ | ------------------------------------------- | -------------------------------------------------------------------------- |
+| Whether a server can be registered         | When a developer runs `sbx mcp add`         | The registered name and resolved server attributes, such as `identityURL`  |
+| What agents can do through the MCP gateway | When the gateway handles a governed request | The registered server name, tool annotations, resource URI, or prompt name |
+
+Registration rules affect future registrations. They don't remove a saved
+registration or prevent an existing registration from being loaded with
+`sbx mcp load`. Use-time rules govern tool calls, resource reads, and prompt
+retrieval from servers that are already registered or loaded.
+
+Server names are chosen during registration. Registration rules can match the
+chosen name and resolved server identity together. At use time, tools,
+resources, and prompts are associated with the registered name, so rules for an
+existing server must match every name under which it was registered.
+
+Built-in gateway tools, such as `mcp-add`, `code-mode`, and OAuth authorization
+helpers, are also governed at use time. They are `MCP::Primordial` resources
+rather than tools associated with a registered server. For details, see
+[Built-in gateway tools](../../mcp-gateway.md#built-in-gateway-tools).
+
+Use-time policy doesn't hide or remove existing registrations. Tool and
+resource listings can also include entries that policy denies when an agent
+tries to use them.
+
+## Choose an access posture
+
+When MCP policy enforcement is active for a user, registration and governed MCP
+requests are denied unless a matching `permit` allows them. A matching `forbid`
+overrides any `permit`, including a permit with `@requireApproval`.
+
+Use permits for an allowlist policy. For a blocklist policy that grants MCP
+activity except for explicit restrictions, start with an actionless permit:
+
+```plaintext
+permit (principal, action, resource);
+```
+
+This statement permits every MCP action that reaches Cedar evaluation. Add
+`forbid` statements for the restrictions the policy must enforce.
+
+Policy scope supplies the principal. Use organization or team scope instead of
+matching users, teams, tenants, or roles in Cedar. If MCP policy enforcement
+isn't active for a user, the gateway doesn't evaluate Cedar policy and permits
+MCP activity. MCP doesn't have a local preset equivalent to network policy.
+
+## Approve a server
+
+For an allowlist, approve both the server registration and its use-time
+capabilities. The following policy approves a remote server only when it is
+registered as `example` with the expected identity URL. It permits read-only
+tool calls, resource reads, and prompt retrieval from that registered server:
+
+```plaintext
+// Permit registration with the expected name and identity URL.
+permit (principal, action == MCP::Action::"register", resource)
+when {
+  resource in MCP::Server::"example" &&
+  resource.identityURL == "https://mcp.example.com/mcp"
+};
+
+// Permit read-only tool calls.
+permit (principal, action == MCP::Action::"invokeTool", resource)
+when {
+  resource in MCP::Server::"example" &&
+  resource.readOnly == true
+};
+
+// Permit resource reads.
+permit (principal, action == MCP::Action::"readResource", resource)
+when { resource in MCP::Server::"example" };
+
+// Permit prompt retrieval.
+permit (principal, action == MCP::Action::"getPrompt", resource)
+when { resource in MCP::Server::"example" };
+```
+
+Matching both the name and identity URL establishes a canonical registration.
+It prevents a developer from registering another endpoint under the approved
+name or registering the approved endpoint under another name. Remove the
+resource or prompt permit if users don't need that capability.
+
+## Require confirmation with MCP elicitation
+
+Use `@requireApproval` to require per-request confirmation through MCP. When a
+request matches the annotated `permit`, the gateway sends an
+`elicitation/create` request to the same MCP client session that made the
+governed request. In a human-driven client, the person operating the agent sees
+the prompt and decides whether to proceed.
+
+The following policy requires confirmation for non-read-only tools on a server
+registered as `example`. Use it alongside any permits needed to register the
+server or use its other capabilities. The annotation string becomes the reason
+shown in the elicitation:
+
+```plaintext
+@requireApproval("non-read-only tool call")
+permit (principal, action == MCP::Action::"invokeTool", resource)
+when {
+  resource in MCP::Server::"example" &&
+  resource.readOnly == false
+};
+```
+
+Tool annotations are supplied by the server and are advisory. `readOnly`
+defaults to `false` for tools that don't declare it, so this pattern requires
+confirmation for unannotated tools.
+
+The gateway handles a matching request as follows:
+
+```mermaid
+flowchart TD
+  request["Agent sends a governed MCP request"] --> evaluate["Gateway evaluates MCP policy"]
+  evaluate -->|"Normal permit"| forward["Forward request"]
+  evaluate -->|"No permit or matching forbid"| deny["Deny request"]
+  evaluate -->|"Permit with @requireApproval"| elicit["Send MCP elicitation to connected client"]
+  elicit --> confirm{"Client returns explicit confirmation?"}
+  confirm -->|"No, unsupported, or error"| deny
+  confirm -->|"Yes"| reevaluate["Re-evaluate with approval digest"]
+  reevaluate -->|"Allowed"| forward
+  reevaluate -->|"Denied or changed"| deny
+```
+
+The prompt identifies the server or gateway tool and includes the annotation
+reason. It doesn't include raw tool arguments. Each matching request requires a
+new confirmation. After confirmation, the gateway re-evaluates the request with
+a digest that binds the response to the evaluated authorization request.
+
+Use this mechanism as a confirmation guardrail for human-driven clients. It
+doesn't create administrator approval or separation of duties. An autonomous
+MCP client can respond to an in-protocol elicitation programmatically. Use
+`forbid` for operations that must never run.
+
+The request is denied if the originating client session can't handle MCP
+elicitation, the user declines, the elicitation fails, or re-evaluation doesn't
+allow the request. `sbx mcp add` can't present an elicitation, so a registration
+permit with `@requireApproval` results in a denial. Tool calls made from an
+execution context that can't relay an elicitation, including calls from inside
+`code-mode`, are also denied.
+
+## Withdraw server access
+
+To withdraw access from a server that broader rules permit, block it at
+registration and at use time. Registration policy controls future `sbx mcp add`
+operations, while use-time policy controls requests from servers that are
+already registered or loaded.
+
+Prevent future registrations of the server by matching its identity URL:
+
+```plaintext
+forbid (principal, action == MCP::Action::"register", resource)
+when { resource.identityURL == "https://mcp.example.com/mcp" };
+```
+
+Deny use-time requests for each registered name that refers to the server:
+
+```plaintext
+forbid (principal, action == MCP::Action::"invokeTool", resource)
+when { resource in MCP::Server::"example" };
+
+forbid (principal, action == MCP::Action::"readResource", resource)
+when { resource in MCP::Server::"example" };
+
+forbid (principal, action == MCP::Action::"getPrompt", resource)
+when { resource in MCP::Server::"example" };
+```
+
+The registration remains saved and can still be listed or loaded. These rules
+prevent another registration for the identity URL and deny governed use under
+the registered name. If the server was registered under other names, add
+use-time rules for those names as well.
+
+An OAuth authorization helper is a built-in gateway tool, not a child of the
+registered server. To prevent agents from starting authorization for the
+server, govern the helper separately:
+
+```plaintext
+forbid (principal, action == MCP::Action::"invokePrimordial", resource)
+when { resource in MCP::Primordial::"example-authorize" };
+```
+
+## Restrict host-run servers
+
+Local stdio servers run on the host, outside the sandbox VM. This includes
+explicit host commands and OCI-packaged stdio servers started with host Docker.
+For details about this boundary, see
+[Docker Engine isolation](../../security/isolation.md#docker-engine-isolation).
+
+In a blocklist policy that otherwise permits registration, deny the host-run
+server type:
+
+```plaintext
+forbid (principal, action == MCP::Action::"register", resource)
+when { resource.type == "local-stdio" };
+```
+
+`local-stdio` covers explicit commands, including commands that start a Docker
+container, and OCI-packaged stdio servers resolved from registry or manifest
+metadata with `--local`.
+
+## Related information
+
+- [MCP policy concepts](../concepts.md#mcp-policies): policy model and rule
+  evaluation.
+- [MCP policy reference](../reference/mcp-policy.md): exact action, resource,
+  attribute, context, and approval behavior.
+- [Organization policies](organization.md): policy creation and scope.
+- [MCP policy audit logs](../audit/): policy decision
+  records.
diff --git a/content/manuals/ai/sandboxes/governance/access-controls/network.md b/content/manuals/ai/sandboxes/governance/access-controls/network.md
new file mode 100644
index 000000000000..3085f7aa14ce
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/access-controls/network.md
@@ -0,0 +1,70 @@
+---
+title: Network access policies
+linkTitle: Network access
+weight: 30
+description: Control outbound network access from Docker Sandboxes with local and organization policy rules.
+keywords: docker sandboxes, network access, network rules, governance, local policy, organization policy
+---
+
+Network access policies control outbound connections from sandboxes. Each
+policy contains one or more rules that allow the domains, IP ranges, and ports a
+workflow needs, or block destinations that should stay unavailable.
+
+You can configure network access in two places:
+
+- [Local policy](local.md), which applies to sandboxes on one developer machine
+  when organization governance is not active.
+- [Organization policies](organization.md), which apply centrally across an
+  organization or to selected teams.
+
+When organization governance is active, only organization allow rules grant
+network access. Local allow rules are inactive until organization governance no
+longer applies, while local deny rules still apply on top of the organization
+policy. See [Precedence](../concepts.md#precedence).
+
+## Rule syntax
+
+Network rules use the action `connect:tcp`. Resources are hostnames, CIDR
+ranges, ports, or hostnames with ports. The governance policy schema also
+accepts `connect:udp`, but Docker Sandboxes always blocks direct external UDP
+and ICMP. `connect:udp` rules have no effect.
+
+Examples:
+
+- `api.example.com`
+- `*.example.com`
+- `**.example.com`
+- `example.com:443`
+- `10.0.0.0/8`
+
+For exact wildcard behavior and CIDR support, see
+[Network rules](../concepts.md#network-rules).
+
+## Local network rules
+
+Use `sbx policy allow network` and `sbx policy deny network` to manage local
+network rules:
+
+```console
+$ sbx policy allow network api.example.com
+$ sbx policy deny network ads.example.com
+```
+
+For presets, sandbox-scoped rules, testing, and troubleshooting, see
+[Local policy](local.md).
+
+## Organization network rules
+
+Organization network rules belong to policies that can apply to the whole
+organization or to selected teams. For setup steps and team scoping, see
+[Organization policies](organization.md).
+
+Use [Monitoring policies](../monitor-and-enforce/monitoring.md) to inspect
+which network rules are active on a developer machine.
+
+> [!NOTE]
+> To manage Model Context Protocol (MCP) server registration and requests
+> through Docker's MCP gateway, use [MCP access policies](mcp.md). These
+> policies apply only to the gateway. Direct MCP connections from a sandbox
+> don't use the gateway, but you can control access to remote MCP servers with
+> network policy.
diff --git a/content/manuals/ai/sandboxes/governance/access-controls/organization.md b/content/manuals/ai/sandboxes/governance/access-controls/organization.md
new file mode 100644
index 000000000000..18d8eeb14cef
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/access-controls/organization.md
@@ -0,0 +1,176 @@
+---
+title: Organization policies
+linkTitle: Org policies
+weight: 20
+description: Centrally manage sandbox network, filesystem, and MCP policies for your organization.
+keywords: docker sandboxes, governance, organization policy, AI governance, Docker Home, network access, filesystem access, mcp policy
+aliases:
+  - /ai/sandboxes/security/governance/
+  - /ai/sandboxes/governance/org/
+---
+
+[Local policies](local.md) give individual developers control over what their
+sandboxes can access. Organization policy moves that control to the admin level:
+organization policies apply to sandboxes across the organization, either to
+every member or to specific teams. When organization governance is active, only
+organization allow rules grant access: local `sbx policy` allow rules are no
+longer evaluated and can't expand what the organization permits. Local network
+deny rules remain active, so developers can restrict access further but never
+loosen it.
+
+Admins can manage organization policies through the Docker Home UI. For
+programmatic management of network and filesystem policies, use the
+[Governance API](/reference/api/ai-governance/).
+
+By default, only organization
+[owners](/manuals/enterprise/security/roles-and-permissions/core-roles.md) can
+view and manage AI Governance policies. To let someone other than an owner
+manage policies, create a
+[custom role](/manuals/enterprise/security/roles-and-permissions/custom-roles/_index.md)
+with the **Governance** permissions and assign it to a user or team.
+
+> [!NOTE]
+> Sandbox organization governance is available on a separate paid
+> subscription.
+> [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
+> to request access.
+
+## Create a policy
+
+Manage policies from the **AI Platform** section in the left-hand navigation
+of [Docker Home](https://app.docker.com).
+
+To create a policy:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+   organization.
+1. In the left-hand navigation, expand **AI Platform** and select
+   **Network access**, **Filesystem access**, or **MCP access**.
+1. Select **Create policy**.
+1. Enter a **Policy name**.
+1. Set the **Scope** to **Organization** or **Teams**. If you select **Teams**,
+   choose the teams the policy applies to. See
+   [Scope policies to teams](#scope-policies-to-teams).
+1. Define the policy rules. For network and filesystem policies, select
+   **Add rule** for each rule. For MCP policies, enter Cedar statements in the
+   policy editor. For syntax and examples, use the relevant access-control page
+   in [Choose a policy type](#choose-a-policy-type).
+
+Existing policies are listed with their name, scope, rule count, and last
+update. Use the action menu (⋮) to edit or delete a policy.
+
+## Configure a support message
+
+Admins can add an optional support message that appears after the policy denial
+details when a sandbox action is blocked by organization governance. Use it to
+point members to an internal support channel, ticket queue, or security contact.
+
+To set the message:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+   organization.
+1. In the left-hand navigation, expand **AI Platform** and select **Manage**.
+1. In **Support message**, enter up to 500 characters.
+1. Select **Save changes**.
+
+Docker shows the message only for denials caused by organization governance
+policy. If you leave it blank, Docker shows the policy denial without additional
+contact text.
+
+## Choose a policy type
+
+Organization policies are managed by access surface. Use the access-control
+pages for syntax, examples, and enforcement details:
+
+- [Network access policies](network.md): control outbound network access from
+  sandboxes.
+- [Filesystem access policies](filesystem.md): control which host paths
+  sandboxes can mount as workspaces.
+- [MCP access policies](mcp.md): control MCP server registration, tool calls,
+  resources, prompts, and approval gates with Cedar policy.
+
+When organization governance is active, local and kit-defined allow rules are
+not evaluated, while deny rules from those sources still apply. See
+[Precedence](../concepts.md#precedence). To see which rules are active on a
+developer machine, use
+[Monitoring policies](../monitor-and-enforce/monitoring.md).
+
+## Scope policies to teams
+
+An organization can have more than one policy, and each policy applies either
+to the whole organization or to specific teams. Scoping lets you apply different
+rules to different parts of the organization.
+
+A policy's [**Scope**](#create-a-policy) controls who it applies to. Set it to
+**Organization** to apply the policy to every member, or to **Teams** to apply
+it only to members of the teams you select.
+
+### Before you start
+
+Team scoping targets your organization's existing
+[teams](/manuals/admin/organization/manage/manage-a-team.md), so a team must
+exist before you can scope a policy to it. Create teams and manage their members
+in one of two ways:
+
+- Manually, in Docker Home.
+- Automatically, by using
+  [group mapping](/manuals/enterprise/security/provisioning/scim/group-mapping.md)
+  to synchronize your identity provider's groups with the teams in your
+  organization. Group mapping creates teams that don't already exist and keeps
+  their membership in step with your IdP groups.
+
+Because policies apply by team, a user's policies update automatically as their
+team membership changes, including changes synced from your IdP.
+
+### How scoped policies combine
+
+A user is governed by all of their
+[effective policies](../concepts.md#policy-scope): every org-wide policy, plus
+the team-scoped policies for the teams they belong to. Use org-wide policies
+for guardrails that must apply everywhere, and team-scoped policies for access
+that only some teams need.
+
+For precedence between local and organization policies, and for how allow and
+deny rules combine, see [Policy concepts](../concepts.md).
+
+## Troubleshooting
+
+### Policy changes not taking effect
+
+After updating organization policies, changes take up to 5 minutes to
+propagate to developer machines. To apply changes immediately, users can run
+`sbx policy reset`, which stops the daemon and forces it to pull the latest
+organization policies on the next `sbx` command.
+
+> [!WARNING]
+> `sbx policy reset` deletes all locally configured policy rules. The command
+> prompts for confirmation before proceeding.
+
+#### Enforcement timing by policy type
+
+Policy types differ in when a change takes effect after it reaches the
+developer machine:
+
+- Network policy is evaluated on every outbound request. Once a policy
+  change has synced to the developer's machine (up to 5 minutes), it applies
+  immediately to subsequent requests.
+
+- Filesystem policy is only checked when a workspace is mounted — that
+  is, when a sandbox is created. Once a sandbox is running, changing the
+  filesystem policy has no effect on that sandbox. The sandbox continues to
+  access the previously allowed path until it is removed and a new one is
+  created.
+
+- MCP registration policy is evaluated when a server is registered with
+  `sbx mcp add`. Changing registration rules doesn't remove existing
+  registrations or stop an already-loaded server by itself.
+
+- MCP use-time policy is evaluated by the MCP gateway when a sandbox makes a
+  governed MCP request, such as a tool call, resource read, prompt retrieval,
+  or built-in gateway tool call. Once a policy change has synced, use-time
+  rules apply to subsequent governed MCP requests through the gateway.
+
+To apply a filesystem policy change immediately, remove the running sandbox
+and create a new one. To prevent use of an MCP server that is already registered
+or loaded, add use-time rules for the registered server name. For examples, see
+[Withdraw server access](mcp.md#withdraw-server-access).
diff --git a/content/manuals/ai/sandboxes/governance/audit/_index.md b/content/manuals/ai/sandboxes/governance/audit/_index.md
new file mode 100644
index 000000000000..35ac8c59b7da
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/audit/_index.md
@@ -0,0 +1,83 @@
+---
+title: AI Governance Audit Logs
+linkTitle: Audit logs
+weight: 30
+description: Capture, view, export, and collect structured audit records for Docker AI Governance policy decisions.
+keywords: docker sandboxes, audit log, audit logging, AI Governance, policy decision, SIEM, compliance, jsonl
+---
+
+{{< summary-bar feature_name="AI Governance Audit Logs" >}}
+
+AI Governance Audit Logs record Docker AI Governance activity for your
+organization. Each record captures the principal, action, target, decision, and
+time for a governance event. Records contain metadata only. They don't contain
+prompt content, agent output, or parameter values.
+
+Audit logs are exposed when AI Governance is enabled for your organization.
+Docker Sandboxes send audit records only for signed-in users who have an AI
+Governance license and are governed by an enforced centralized [organization
+policy](../access-controls/organization.md). Docker Sandboxes users without both
+don't send audit data to audit logs.
+
+> [!NOTE]
+> AI Governance Audit Logs are part of Docker AI Governance and require a
+> separate paid subscription.
+> [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
+> to request access.
+
+## Requirements
+
+To use AI Governance Audit Logs, your organization needs:
+
+- A Docker [AI Governance plan](/manuals/subscription/plans/ai-governance.md)
+- An enforced organization governance policy
+- A Docker organization account
+- An organization owner, or a user with a [custom role](/manuals/enterprise/security/roles-and-permissions/custom-roles/_index.md) that includes AI Governance audit permissions, to configure delivery and view hosted events
+
+> [!NOTE]
+> Other Docker subscriptions are not sufficient on their own to use AI Governance
+> Audit Logs. Users without an AI Governance license and an enforced organization
+> policy will not generate audit data and will not appear in audit events or SIEM
+> forwarding output. Personal accounts are not supported.
+
+## Coverage
+
+AI Governance Audit Logs cover Docker Sandboxes policy decisions and sandbox
+session events. Other Docker AI sources can emit records through the same schema
+as they become available.
+
+## Delivery modes
+
+Docker supports two delivery modes for audit records:
+
+- **Local disk**: the sandbox daemon writes JSON Lines (`.jsonl`)
+  files on each host. Use this mode for host-local retention, air-gapped
+  collection, or collection through your own log shipper.
+- **Docker Cloud**: Docker stores audit records in Docker Cloud. Cloud
+  delivery powers the hosted audit log view, CSV export, and SIEM streaming from
+  app.docker.com. Cloud delivery is on by default when AI Governance is enabled.
+  Organization owners can disable it in [audit delivery settings](configure.md).
+
+Organization owners and users with a [custom role](/manuals/enterprise/security/roles-and-permissions/custom-roles/_index.md) that includes AI Governance audit permissions can configure local disk, Docker Cloud, or both.
+
+The hosted audit log view, CSV export, and SIEM forwarding all require Docker Cloud delivery to be enabled. Local delivery alone does not power these features.
+
+Organizations that used local audit logging before hosted audit logs were
+available start with cloud delivery off until an owner opts in from
+[audit delivery settings](configure.md).
+
+## Data handling
+
+When Docker Cloud delivery is enabled, Docker stores audit records in Docker
+Cloud for the retention window configured by your organization. For legal and
+privacy terms that govern Docker services, see Docker's [Terms of
+Service](https://www.docker.com/legal/docker-terms-service/) and [Privacy
+Policy](https://www.docker.com/legal/privacy/).
+
+## Learn more
+
+- [Local audit logs](local.md)
+- [Configure audit delivery](configure.md)
+- [View and export audit events](view-export.md)
+- [SIEM forwarding](siem.md)
+- [Audit record reference](record-reference.md)
diff --git a/content/manuals/ai/sandboxes/governance/audit/configure.md b/content/manuals/ai/sandboxes/governance/audit/configure.md
new file mode 100644
index 000000000000..38342b898f44
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/audit/configure.md
@@ -0,0 +1,73 @@
+---
+title: Configure audit delivery
+linkTitle: Configure delivery
+weight: 20
+description: Configure local and cloud delivery, retention, and history for Docker AI Governance Audit Logs.
+keywords: docker sandboxes, audit delivery, AI Governance, audit logs, retention, cloud delivery, AI Platform
+---
+
+Organization owners and users with a [custom role](/manuals/enterprise/security/roles-and-permissions/custom-roles/_index.md) that includes AI Governance audit permissions can configure where Docker writes audit events.
+Two delivery destinations are available and can be used independently or
+together:
+
+- **Local disk**: The sandbox daemon writes audit events to the local disk
+  on each host.
+- **Docker Cloud**: Audit events are sent to Docker's cloud platform, enabling
+  the hosted log view, CSV export, and SIEM forwarding.
+
+## Before you begin
+
+Your organization needs:
+
+- A Docker [AI Governance plan](/manuals/subscription/plans/ai-governance.md)
+- An enforced organization governance policy
+- Organization owner access, or a [custom role](/manuals/enterprise/security/roles-and-permissions/custom-roles/_index.md) with AI Governance audit permissions
+
+Only users who have an AI Governance license and are governed by the enforced
+organization policy send Docker Sandboxes audit data.
+
+## Configure delivery
+
+To configure audit delivery:
+
+1. Sign in to [Docker Home](https://app.docker.com/).
+2. Open your organization.
+3. Go to **AI Platform** > **Audit logs**.
+4. Open **Audit Delivery**.
+5. Choose one or both delivery modes:
+   - **Local disk** writes audit records to JSON Lines files on each host.
+   - **Docker Cloud** stores audit records in Docker Cloud for hosted search,
+     CSV export, and SIEM forwarding.
+6. Save your changes.
+
+Cloud delivery is on by default when AI Governance is enabled. To keep records
+local to your hosts, turn off **Docker Cloud** and keep **Local disk** on.
+
+Organizations that used local audit logging before hosted audit logs were
+available start with cloud delivery off until an owner opts in.
+
+## Configure retention
+
+When **Docker Cloud** is selected, you can also configure how long cloud-stored
+events are retained:
+
+| Field                          | Description                                                        | Default |
+| ------------------------------ | ------------------------------------------------------------------ | ------- |
+| Searchable retention (days)    | How long events stay searchable in the hosted audit log view.      | 90 days |
+| Archive retention (days)       | How long events are kept in long-term archive storage.             | 90 days |
+
+Archive retention must be greater than or equal to searchable retention.
+
+Retention reductions apply going forward. They don't delete records that were
+already retained under a longer retention window.
+
+## Audit delivery change history
+
+Docker keeps a record of every change made to your organization's audit delivery
+settings. Each entry captures the timestamp, the user who made the change, and
+the delivery configuration that was set. Use this history to audit configuration
+changes and verify when delivery modes or retention windows were modified.
+
+Open **History** to review delivery and retention changes for your organization.
+History entries show who made the change, when it happened, and the before and
+after values.
diff --git a/content/manuals/ai/sandboxes/governance/audit/local.md b/content/manuals/ai/sandboxes/governance/audit/local.md
new file mode 100644
index 000000000000..0e1931fe9272
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/audit/local.md
@@ -0,0 +1,99 @@
+---
+title: Local audit logs
+linkTitle: Local audit logs
+weight: 10
+description: Collect Docker AI Governance audit records from local JSON Lines files written by the sandbox daemon.
+keywords: docker sandboxes, audit log, local audit logs, audit logging, jsonl, SIEM, splunk, filebeat
+---
+
+The sandbox daemon writes local audit records as JSON Lines (`.jsonl`) files.
+Local audit logs stay on the host that produced them and can be collected by
+your own log shipper. Local delivery is independent of
+[cloud delivery](configure.md), so you can use local files with cloud delivery
+on or off.
+
+The sandbox daemon writes local audit records only for signed-in users who have
+an AI Governance license and are governed by an enforced centralized
+[organization policy](../access-controls/organization.md). Docker Sandboxes
+users without both do not send audit data to audit logs. To confirm governance
+is active, run `sbx policy ls`. The output includes a `Governance: Managed by
+<org>` line when an organization policy is in effect.
+
+## What gets recorded
+
+The daemon writes two categories of local record:
+
+- Evaluation records capture each policy decision: the resource, the action,
+  the verdict, and the reason for a denial.
+- Session lifecycle records mark the start and end of each daemon run.
+  Evaluation records share the run's `audit_session_id`, so you can correlate
+  every decision back to a daemon session.
+
+Records contain metadata only. They don't contain prompt content, agent output,
+or parameter values. For field details, see
+[Audit record reference](record-reference.md).
+
+A network evaluation record looks like this:
+
+```json
+{
+  "audit_event_id": "95e7257f-93c9-4f29-bde7-88830e2dae80",
+  "timestamp": "2026-05-28T19:15:00.728933Z",
+  "schema_version": "1.82.0",
+  "category": "AUDIT_CATEGORY_EVALUATION",
+  "decision": "AUDIT_DECISION_DENY",
+  "username": "jordandoe",
+  "user_email": "jordandoe@example.com",
+  "org_id": "9f8e7d6c-5b4a-3210-fedc-ba9876543210",
+  "org_name": "Acme Inc",
+  "audit_session_id": "8a3bc076-79d0-4502-baf3-cc6ad35fb578",
+  "resource_id": "example.com:443",
+  "os": "macos",
+  "app_version": "v0.31.0",
+  "client_name": "sbx",
+  "hostname": "host-machine",
+  "deny_reason": [
+    "no applicable policies for op(action=net:connect:tcp, resource=net:domain:example.com:443)"
+  ],
+  "action_type": "network_egress",
+  "network_egress": { "protocol": "tcp" },
+  "agent": "claude"
+}
+```
+
+## Where records are stored
+
+The daemon writes audit records, not the CLI. Running a command such as
+`sbx create` sends a request to the daemon, and the daemon emits the resulting
+record to its own audit directory.
+
+The default location depends on your operating system:
+
+| OS      | Default path                                                      |
+| ------- | ----------------------------------------------------------------- |
+| macOS   | `~/Library/Logs/com.docker.sandboxes/sandboxes/auditkit/`         |
+| Linux   | `${XDG_STATE_HOME:-~/.local/state}/sandboxes/sandboxes/auditkit/` |
+| Windows | `%LOCALAPPDATA%\DockerSandboxes\sandboxes\logs\auditkit\`         |
+
+The directory layout differs by platform because each operating system places
+application logs in its own conventional location.
+
+Files are named `audit-<utc-timestamp>-<process-uuid>-<seq>.jsonl`.
+
+The daemon writes in-progress records to a temporary `.tmp` file and
+finalizes it into a `.jsonl` file by atomic rename. Finalization happens at a
+rotation threshold: by default, 5 minutes, 1000 events, or 50 MiB, whichever
+comes first. Finalization also happens when the daemon shuts down cleanly. Only
+`.jsonl` files are complete. Treat `.tmp` files as incomplete and don't collect
+them.
+
+Sandboxes never delete `.jsonl` files. Retention and cleanup are the
+responsibility of your log shipper or your own housekeeping.
+
+## Collect records with a SIEM
+
+Point your log shipper at the audit directory and configure it to collect
+`.jsonl` files only. Tools such as the Splunk Universal Forwarder,
+Filebeat, and CrowdStrike Falcon LogScale read the directory and forward each
+line as an event. Because in-progress records live in `.tmp` files until they
+are finalized, collectors never see partial records.
diff --git a/content/manuals/ai/sandboxes/governance/audit/record-reference.md b/content/manuals/ai/sandboxes/governance/audit/record-reference.md
new file mode 100644
index 000000000000..6f895e72d541
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/audit/record-reference.md
@@ -0,0 +1,105 @@
+---
+title: Audit record reference
+linkTitle: Record reference
+weight: 50
+description: Reference fields, categories, decisions, and payload types for Docker AI Governance audit records.
+keywords: docker sandboxes, audit record, audit schema, AI Governance, policy decision, action_type, jsonl
+---
+
+Docker AI Governance audit records use one schema across delivery modes. Local
+JSON Lines files and cloud-delivered records contain the same metadata fields.
+
+Records capture metadata only. They don't contain prompt content, agent output,
+or parameter values. Parameter keys may appear when they help identify an
+action.
+
+## Common fields
+
+| Field              | Description                                                                                                      |
+| ------------------ | ---------------------------------------------------------------------------------------------------------------- |
+| `audit_event_id`   | Unique ID for the audit event.                                                                                   |
+| `timestamp`        | UTC time when Docker recorded the event.                                                                         |
+| `schema_version`   | Version of the record schema. Pin SIEM field mappings to this value.                                             |
+| `category`         | Event category, such as `AUDIT_CATEGORY_MANAGEMENT`, `AUDIT_CATEGORY_EVALUATION`, or `AUDIT_CATEGORY_EXECUTION`. |
+| `decision`         | Governance decision for evaluation records.                                                                      |
+| `username`         | The signed-in Docker user's Docker Hub username.                                                                 |
+| `user_email`       | The signed-in Docker user's email address.                                                                       |
+| `org_id`           | ID of the organization whose governance policy is in effect.                                                     |
+| `org_name`         | Display name of the organization whose governance policy is in effect.                                           |
+| `audit_session_id` | Identifies the daemon session that produced the record.                                                          |
+| `resource_id`      | Target of the evaluation, such as a host and port, file path, or tool.                                           |
+| `os`               | Operating system that produced the record.                                                                       |
+| `app_version`      | Version of the Docker component that produced the record.                                                        |
+| `client_name`      | Source component, such as `sbx` for Docker Sandboxes.                                                            |
+| `hostname`         | Hostname of the machine that produced the record.                                                                |
+| `deny_reason`      | Why a denied request was blocked. Present on deny decisions.                                                     |
+| `action_type`      | Payload discriminator that identifies the action-specific object in the record.                                  |
+| `agent`            | AI agent associated with the event, when Docker knows it.                                                        |
+
+## Categories
+
+| Category                    | Description                                                   |
+| --------------------------- | ------------------------------------------------------------- |
+| `AUDIT_CATEGORY_MANAGEMENT` | Session lifecycle, policy sync, and configuration events.     |
+| `AUDIT_CATEGORY_EVALUATION` | Governance policy decisions, such as allow, deny, or consent. |
+| `AUDIT_CATEGORY_EXECUTION`  | Outcomes after an evaluated action runs.                      |
+
+## Decisions
+
+| Decision                           | Description                                    |
+| ---------------------------------- | ---------------------------------------------- |
+| `AUDIT_DECISION_ALLOW`             | Docker allowed the action.                     |
+| `AUDIT_DECISION_DENY`              | Docker denied the action.                      |
+| `AUDIT_DECISION_APPROVAL_REQUIRED` | Docker required consent before the action ran. |
+| `AUDIT_DECISION_APPROVED`          | A consent request was approved.                |
+| `AUDIT_DECISION_REJECTED`          | A consent request was rejected.                |
+
+## Action types
+
+The `action_type` field identifies the action-specific payload in the record.
+
+| Action type            | Description                                  |
+| ---------------------- | -------------------------------------------- |
+| `session`              | Sandbox daemon session lifecycle event.      |
+| `network_egress`       | Network access evaluation.                   |
+| `filesystem_mount`     | Filesystem mount or path access evaluation.  |
+| `tool_invocation`      | Tool invocation evaluation.                  |
+| `resource_read`        | Resource read evaluation.                    |
+| `server_registration`  | Server registration event.                   |
+| `prompt`               | Prompt-related metadata event.               |
+| `network_execution`    | Outcome of a network action.                 |
+| `filesystem_execution` | Outcome of a filesystem action.              |
+| `tool_execution`       | Outcome of a tool invocation.                |
+| `resource_execution`   | Outcome of a resource read.                  |
+| `policy_sync`          | Policy synchronization event.                |
+| `pii_detection`        | Metadata event for a data detection result.  |
+| `c_score_report`       | Metadata event for a C-score report.         |
+| `policy_action`        | Policy configuration or policy action event. |
+
+## Sample record
+
+```json
+{
+  "audit_event_id": "95e7257f-93c9-4f29-bde7-88830e2dae80",
+  "timestamp": "2026-05-28T19:15:00.728933Z",
+  "schema_version": "1.82.0",
+  "category": "AUDIT_CATEGORY_EVALUATION",
+  "decision": "AUDIT_DECISION_DENY",
+  "username": "jordandoe",
+  "user_email": "jordandoe@example.com",
+  "org_id": "9f8e7d6c-5b4a-3210-fedc-ba9876543210",
+  "org_name": "Acme Inc",
+  "audit_session_id": "8a3bc076-79d0-4502-baf3-cc6ad35fb578",
+  "resource_id": "example.com:443",
+  "os": "macos",
+  "app_version": "v0.31.0",
+  "client_name": "sbx",
+  "hostname": "host-machine",
+  "deny_reason": [
+    "no applicable policies for op(action=net:connect:tcp, resource=net:domain:example.com:443)"
+  ],
+  "action_type": "network_egress",
+  "network_egress": { "protocol": "tcp" },
+  "agent": "claude"
+}
+```
diff --git a/content/manuals/ai/sandboxes/governance/audit/siem.md b/content/manuals/ai/sandboxes/governance/audit/siem.md
new file mode 100644
index 000000000000..a5511fbdef47
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/audit/siem.md
@@ -0,0 +1,63 @@
+---
+title: SIEM forwarding
+linkTitle: SIEM forwarding
+weight: 40
+description: Forward Docker AI Governance audit events to Splunk, Dynatrace, or Datadog.
+keywords: docker sandboxes, SIEM, audit logs, Splunk, Dynatrace, Datadog, AI Governance, forwarding, NDJSON
+---
+
+{{< summary-bar feature_name="AI Governance Audit Logs" >}}
+
+Docker can forward audit events to your security information and event
+management (SIEM) system, letting you centralize Docker governance data
+alongside other security signals. Docker verifies the endpoint is reachable
+with the supplied credential before saving.
+
+## Supported destinations
+
+| Destination                      | Description                                                     |
+| -------------------------------- | --------------------------------------------------------------- |
+| Splunk Cloud (HEC)               | Hosted Splunk using the HTTP Event Collector                    |
+| Dynatrace                        | Dynatrace Log Management using the Log Ingest API               |
+| Datadog                          | Datadog Logs using the HTTP log intake API                      |
+
+## Before you begin
+
+SIEM forwarding requires Docker Sandboxes
+[0.39.0](/manuals/ai/sandboxes/release-notes.md) or later. Earlier versions
+don't deliver audit records to a SIEM destination, even when forwarding is
+configured. Update Docker Sandboxes before enabling a new destination.
+
+SIEM forwarding requires Docker Cloud delivery to be enabled for your
+organization. If you haven't already, enable it under **AI Platform** >
+**Audit logs** > **Audit delivery** before configuring a SIEM destination. See
+[Configure audit delivery](configure.md).
+
+Gather credentials from your SIEM before configuring forwarding:
+
+- **Splunk Cloud**: HEC ingest URL and an HEC token. Optionally, a Splunk index
+  name. See [Splunk documentation](https://docs.splunk.com/).
+- **Dynatrace**: Log Ingest API URL and an API token with the `logs.ingest`
+  scope. See [Dynatrace documentation](https://docs.dynatrace.com/).
+- **Datadog**: Logs intake URL for your Datadog site and an API key. See
+  [Datadog documentation](https://docs.datadoghq.com/).
+
+## Add a SIEM destination
+
+1. Sign in to [Docker Home](https://app.docker.com/).
+1. Open your organization.
+1. Go to **AI Platform** > **Audit logs**.
+1. Open **Export & Connectors**.
+1. Select **Add destination**.
+1. Select your destination and complete the form.
+1. Select **Save**.
+
+If verification fails, check that the URL and credential are correct and that
+the endpoint is accessible from the internet.
+
+## Manage destinations
+
+From the **SIEM forwarding** list, select the menu next to a destination to
+edit or delete it. The edit form lets you update credentials and toggle
+forwarding on or off for that destination. Deleting a destination permanently
+removes the endpoint and its stored credential and cannot be undone.
diff --git a/content/manuals/ai/sandboxes/governance/audit/view-export.md b/content/manuals/ai/sandboxes/governance/audit/view-export.md
new file mode 100644
index 000000000000..7b1e7adf67b0
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/audit/view-export.md
@@ -0,0 +1,50 @@
+---
+title: View and export audit events
+linkTitle: View and export
+weight: 30
+description: Search, filter, and export Docker AI Governance audit events from the hosted audit log UI.
+keywords: docker sandboxes, audit events, audit logs, AI Governance, CSV export
+---
+
+Cloud delivery stores AI Governance audit records in Docker Cloud and makes
+them available in the hosted audit log UI. Use the hosted view to investigate
+policy decisions or export events to CSV.
+
+## View audit events
+
+To view audit events:
+
+1. Sign in to [Docker Home](https://app.docker.com/).
+1. Open your organization.
+1. Go to **AI Platform** > **Audit logs**.
+1. Open **Audit Events**.
+
+The **Audit Events** view includes summary tiles for total events, allowed
+events, denied events, and consent-required events. The event table includes:
+
+| Column    | Description                                                   |
+| --------- | ------------------------------------------------------------- |
+| Time      | When Docker recorded the event.                               |
+| Event     | The event type or policy action.                              |
+| Principal | The Docker user associated with the event.                    |
+| Resource  | The target resource, such as a domain, file path, or tool.    |
+| Decision  | The governance decision, such as allow, deny, or consent.     |
+| Agent     | The AI agent associated with the event, when Docker knows it. |
+
+## Filter and search events
+
+Use the audit log filters to narrow the event table by decision and time range.
+Use search to find events by principal, resource, event type, or agent.
+
+The event table uses cursor pagination for large result sets.
+
+## Export events to CSV
+
+Use CSV export when you need an offline copy of filtered audit events:
+
+1. Open **Audit Events**.
+1. Apply the filters and search terms for the events you want to export.
+1. Select **Export**.
+1. Download the generated CSV file from the link Docker provides.
+
+CSV exports include up to 1 000 000 rows. Download links expire after 24 hours.
diff --git a/content/manuals/ai/sandboxes/governance/concepts.md b/content/manuals/ai/sandboxes/governance/concepts.md
new file mode 100644
index 000000000000..d39cd47f128c
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/concepts.md
@@ -0,0 +1,205 @@
+---
+title: Policy concepts
+weight: 10
+description: The resource model, rule syntax, and evaluation logic behind Docker sandbox governance.
+keywords: docker sandboxes, policy concepts, rule syntax, network rules, filesystem rules, mcp policy, cedar policy, precedence, rule evaluation
+---
+
+## Resource model
+
+Docker sandbox governance is built around two resource types: **policies** and
+**rules**.
+
+A **policy** is a named collection of rules that controls sandbox access.
+Policies exist at two levels:
+
+- **Local**: configured per machine using the `sbx policy` CLI. Applies to
+  sandboxes on that machine only.
+- **Organization**: configured in Docker Home. Network and filesystem policies
+  can also be managed via the
+  [Governance API](/reference/api/ai-governance/). Applies to sandboxes across
+  the organization. An organization can have several policies, each applying
+  either org-wide or to specific teams. See [Policy scope](#policy-scope).
+
+When organization governance is active, only organization allow rules can grant
+access. Local and kit-defined deny rules still apply on top. See
+[Precedence](#precedence).
+
+A **rule** is the unit of access control within a policy. Each rule has:
+
+- **Name**: a human-readable label
+- **Actions**: the type of access the rule controls
+- **Resources**: the targets the rule matches against
+- **Decision**: `allow` or `deny`
+
+Rules are grouped by domain. Network and filesystem rules in a policy must
+share the same domain, either `network` or `filesystem`. MCP policies use Cedar
+statements written in the `MCP` namespace instead of the network and filesystem
+rule format.
+
+## Policy scope
+
+Each organization policy applies either across the whole organization or only
+to specific teams:
+
+- Org-wide: with no teams assigned, the policy applies to every member of the
+  organization.
+- Team-scoped: with one or more teams assigned, the policy applies only to
+  members of those teams.
+
+Teams are the same [teams](/manuals/admin/organization/manage/manage-a-team.md)
+you manage for your organization; Docker matches a policy's teams against each
+user's team membership. Because an organization can mix org-wide and team-scoped
+policies, a single user is often subject to several at once. The policies that
+apply to a given user are their _effective policies_: every org-wide policy,
+plus every team-scoped policy for a team they belong to. See
+[Rule evaluation](#rule-evaluation) for how a user's effective policies combine.
+
+## Rule syntax
+
+### Network rules
+
+Network rules use the action `connect:tcp`. Resources are hostnames, CIDR
+ranges, or ports. The governance policy schema also accepts `connect:udp`, but
+Docker Sandboxes always blocks direct external UDP and ICMP. `connect:udp`
+rules have no effect.
+
+**Hostname patterns**
+
+| Pattern               | Example           | Matches                                            |
+| --------------------- | ----------------- | -------------------------------------------------- |
+| Exact hostname        | `example.com`     | `example.com` only, not subdomains                 |
+| Single-level wildcard | `*.example.com`   | One subdomain level: `api.example.com`             |
+| Multi-level wildcard  | `**.example.com`  | Any depth: `api.example.com`, `v2.api.example.com` |
+| Hostname with port    | `example.com:443` | `example.com` on port 443 only                     |
+
+`example.com` and `*.example.com` don't cover each other. Specify both if you
+need to match the root domain and its subdomains.
+
+**CIDR ranges**
+
+Both IPv4 and IPv6 notation are supported: `10.0.0.0/8`, `192.168.1.0/24`,
+`2001:db8::/32`.
+
+For local and organization policy configuration, see
+[Network access policies](access-controls/network.md).
+
+### Filesystem rules
+
+Filesystem rules use the actions `read` and `write`. Resources are host paths
+that sandboxes can mount as workspaces.
+
+A workspace mounted with write access must be allowed by both a `read` and a
+`write` rule; a read-only workspace needs only `read`. When default deny blocks
+a mount, the denial reason names whether read or write access was missing.
+
+`~` expands to the user's home directory on every platform, including Windows,
+where it resolves to `%USERPROFILE%`. A single `~/**` rule therefore matches
+each user's home tree on macOS, Linux, and Windows. The policy engine expands
+only `~`: it does not expand environment variables, so a pattern such as
+`%USERPROFILE%\**` or `$HOME/**` matches nothing.
+
+For a path outside the home directory, write it in the format the user's
+operating system uses. A rule matches only the format it's written in, so a
+location that several platforms share needs a rule for each:
+
+| Operating system | Example path                               |
+| ---------------- | ------------------------------------------ |
+| macOS, Linux     | `/data/project/**`                         |
+| Windows          | `C:\data\project\**`                       |
+| WSL              | `\\wsl.localhost\<distro>\data\project\**` |
+
+On Windows, `*:` matches any drive letter, so `*:\data\**` matches the path on
+any drive.
+
+Wildcards behave the same way in every path format:
+
+| Pattern            | Example    | Matches                                                    |
+| ------------------ | ---------- | ---------------------------------------------------------- |
+| Exact path         | `/data`    | `/data` only                                               |
+| Segment wildcard   | `/data/*`  | `/data/project`, one path segment only, not subdirectories |
+| Recursive wildcard | `/data/**` | `/data/project`, `/data/project/src`, any depth            |
+
+Use `**` to match a directory tree recursively. A single `*` matches within one
+path segment and won't cross a path separator. For example, `~/**` matches all
+paths under the home directory, while `~/*` matches only its direct children.
+
+For organization policy configuration and enforcement details, see
+[Filesystem access policies](access-controls/filesystem.md).
+
+### MCP policies
+
+MCP policies control Model Context Protocol activity made available to a
+sandbox through Docker's [MCP gateway](../mcp-gateway.md). They are
+organization policies written in Cedar using the `MCP` namespace, rather than
+the network and filesystem rule format.
+
+MCP policy applies when a developer registers a server and when an agent uses
+the MCP gateway. Registration rules control future `sbx mcp add` operations.
+Use-time rules control tool calls, gateway meta-tools, resource reads, and
+prompt retrieval from servers that are already registered or loaded.
+
+Governed MCP activity is default deny: a request is blocked unless a matching
+`permit` allows it. A matching `forbid` overrides any `permit`, including a
+permit that requires approval. Policy scope supplies the principal, so use
+organization or team scope instead of matching users, teams, tenants, or roles
+in Cedar.
+
+For representative policies, see [MCP access policies](access-controls/mcp.md).
+For exact action, resource, context, and approval behavior, see the
+[MCP policy reference](reference/mcp-policy.md).
+
+## Rule evaluation
+
+When organization governance is active, the rules from all of a user's
+[effective policies](#policy-scope) are combined and evaluated together against
+each request, following two principles:
+
+- Deny wins: if any rule matches with `decision: deny`, the request is denied,
+  regardless of any matching allow rules.
+- Default deny: anything an allow rule doesn't match is blocked. Outbound
+  network traffic is blocked unless a network rule allows the destination, and a
+  host path can't be mounted unless a filesystem rule allows it. MCP activity is
+  blocked unless an MCP `permit` allows it.
+
+Because every effective policy feeds the same evaluation, allows are additive (a
+request is allowed if any effective policy allows it) and denies are absolute (a
+request is blocked if any effective policy denies it). A deny rule in an
+org-wide policy therefore applies to everyone and can't be overridden by a
+team-scoped policy, which makes org-wide deny rules useful as guardrails.
+
+Local and kit-defined allow rules take no part in this evaluation. Deny rules
+from those sources do still apply. See [Precedence](#precedence).
+
+## Precedence
+
+What applies depends on whether your organization has governance enabled:
+
+- No organization governance: local rules and any
+  [kit-defined network rules](../customize/kits.md#control-network-access)
+  determine what sandboxes can access.
+- Organization governance active: organization policy determines what access can
+  be granted. Only organization allow rules grant access, so local and
+  kit-defined allow rules are inactive and can't expand what the organization
+  permits. Deny rules apply from every source, so a local or kit-defined deny
+  can still restrict access further.
+
+Precedence is decided by a rule's decision rather than its source:
+
+| Rule                | Evaluated under organization governance |
+| ------------------- | --------------------------------------- |
+| Organization allow  | Yes                                     |
+| Organization deny   | Yes                                     |
+| Local allow         | No                                      |
+| Local deny          | Yes                                     |
+| Kit-defined allow   | No                                      |
+| Kit-defined deny    | Yes                                     |
+
+Local and kit-defined rules cover network access only, so a deny that layers on
+top of organization policy is always a network deny. `sbx policy ls` hides
+inactive rules by default. See
+[Monitoring](monitor-and-enforce/monitoring.md#showing-inactive-rules) for how
+to list them.
+
+When organization governance is active, a user's organization policies are
+evaluated together, as described in [Rule evaluation](#rule-evaluation).
diff --git a/content/manuals/ai/sandboxes/governance/monitor-and-enforce/_index.md b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/_index.md
new file mode 100644
index 000000000000..0ff58d417a22
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/_index.md
@@ -0,0 +1,16 @@
+---
+title: Monitor and enforce
+weight: 40
+description: Inspect active sandbox governance rules, collect audit records, and enforce organization sign-in.
+keywords: docker sandboxes, governance monitoring, audit logs, sign-in enforcement, policy enforcement
+---
+
+After policies are configured, use monitoring, audit records, and sign-in
+enforcement to verify how governance behaves across developer machines.
+
+- [Monitoring policies](monitoring.md): inspect active policy rules and monitor
+  sandbox network traffic.
+- [Audit logs](../audit/): view, configure, export, and collect governance audit
+  records.
+- [Sign-in enforcement](sign-in-enforcement.md): require users to sign in as
+  members of approved Docker organizations.
diff --git a/content/manuals/ai/sandboxes/governance/monitor-and-enforce/monitoring.md b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/monitoring.md
new file mode 100644
index 000000000000..8f2333ce8b53
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/monitoring.md
@@ -0,0 +1,162 @@
+---
+title: Monitoring policies
+weight: 10
+description: Inspect active policy rules and monitor sandbox network traffic with sbx policy ls and sbx policy log.
+keywords: docker sandboxes, policy monitoring, sbx policy ls, sbx policy log, network traffic, policy debugging
+aliases:
+  - /ai/sandboxes/governance/monitoring/
+---
+
+`sbx policy ls` and `sbx policy log` give you a combined view of all active
+policy rules and sandbox network activity, regardless of whether those rules
+come from local configuration or organization governance. They're useful both
+for verifying rules you've written and for debugging why a request is being
+blocked or allowed.
+
+## Listing rules
+
+Use `sbx policy ls` to see all active policies and their current status:
+
+```console
+$ sbx policy ls
+POLICY                                 SOURCE   APPLIES TO          SUMMARY
+local-policy                           local    all                 network: 42 allow, 1 deny; filesystem read: 1 allow; filesystem write: 1 allow
+1b2633ea-e604-48bb-a5e6-3ac86ba383fe   kit      sandbox:my-sandbox  network: 3 allow
+```
+
+The columns are:
+
+- `POLICY`: the policy name.
+- `SOURCE`: where the policy came from. `local` means your local configuration
+  — a preset or rules you added with `sbx policy`. `kit` means a
+  [kit](../../customize/kits.md#control-network-access). `org` means your
+  organization.
+- `APPLIES TO`: which sandboxes the policy applies to. `all` means the policy
+  is global. `sandbox:<name>` scopes it to a single sandbox; a profile name
+  scopes it to sandboxes using that profile.
+- `SUMMARY`: a count of rules by type and decision — for example,
+  `network: 5 allow, 1 deny`.
+
+To see full rule-level detail including rule IDs and resources, pass `--wide`.
+To inspect a single policy or rule, use `sbx policy inspect`:
+
+```console
+$ sbx policy inspect Balanced
+```
+
+Use `--source` to filter by origin (`local`, `org`, or `kit`) and `--decision`
+to filter by outcome (`allow` or `deny`).
+
+A `STATUS` column also appears when you pass `--include-inactive`; see
+[Showing inactive rules](#showing-inactive-rules).
+
+When organization governance is active, the output starts with a summary line
+showing which organization manages the policy, the sync state, and how many
+inactive rules are hidden:
+
+```console
+$ sbx policy ls
+Governance: Managed by my-org | Sync: OK, last synced 08:21:01 | Hidden: 9 inactive rules. Show with: sbx policy ls --include-inactive
+
+POLICY               SOURCE   APPLIES TO   SUMMARY
+default filesystem   org      all          filesystem read: 2 allow; filesystem write: 7 allow, 2 deny
+default network      org      all          network: 38 allow, 4 deny
+```
+
+`Governance` shows which organization manages the policy, and `Sync` confirms
+the daemon has pulled the latest rules. If the sync state shows an error or a
+stale timestamp, the daemon may not have the most recent org policy. Run
+`sbx policy reset` to force a fresh pull. `Hidden` reports how many inactive
+rules are suppressed and how to reveal them.
+
+### Showing inactive rules
+
+When organization governance is active, local and kit-defined allow rules are
+not evaluated, so `sbx policy ls` hides them by default. To list them too — for
+example, to confirm which allow rules the organization policy overrides — pass
+`--include-inactive`. This adds a `STATUS` column:
+
+```console
+$ sbx policy ls --include-inactive
+Governance: Managed by my-org | Sync: OK, last synced 08:41:06
+
+POLICY                       SOURCE   APPLIES TO   SUMMARY                                                    STATUS
+default filesystem           org      all          filesystem read: 2 allow; filesystem write: 7 allow, 2 deny   active
+default network              org      all          network: 38 allow, 4 deny                                   active
+default-fs-read-allow-all    local    all          filesystem read: 1 allow                                    inactive
+default-fs-write-allow-all   local    all          filesystem write: 1 allow                                   inactive
+```
+
+Inactive policies show `inactive` in the `STATUS` column. They have no effect
+while organization governance is active. Local and kit-defined deny rules stay
+active and aren't hidden, because a deny still applies on top of the
+organization policy. See [Precedence](../concepts.md#precedence).
+
+Use `--type network` or `--type filesystem` to show only policies of that type.
+Without a sandbox argument, `sbx policy ls` shows every policy across all
+sandboxes. Pass a sandbox name to filter to global policies and those scoped to
+that sandbox:
+
+```console
+$ sbx policy ls my-sandbox
+```
+
+### Filesystem rules
+
+`sbx policy ls` lists filesystem policies alongside network policies. Filesystem
+rules control which host paths a sandbox can mount as a workspace. Pass
+`--type filesystem` to show only them:
+
+```console
+$ sbx policy ls --type filesystem
+POLICY         SOURCE   APPLIES TO   SUMMARY
+local-policy   local    all          filesystem read: 1 allow; filesystem write: 1 allow
+```
+
+A writable workspace mount must be allowed by both a `filesystem:read` and a
+`filesystem:write` rule; a read-only mount needs only `filesystem:read`. The
+default local policy allows read and write access to all paths, shown as the
+two `default-fs-*` rules above. For the rule syntax and path patterns, see
+[Policy concepts](../concepts.md#filesystem-rules).
+
+## Monitoring traffic
+
+Use `sbx policy log` to see which hosts your sandboxes have contacted and
+which rules matched:
+
+```console
+$ sbx policy log
+Blocked requests:
+SANDBOX      TYPE     HOST                   PROXY        RULE            REASON         LAST SEEN        COUNT
+my-sandbox   network  blocked.example.com    transparent  domain-blocked  default-deny   10:15:25 29-Jan  1
+
+Allowed requests:
+SANDBOX      TYPE     HOST                   PROXY          RULE             REASON   LAST SEEN        COUNT
+my-sandbox   network  api.anthropic.com      forward        domain-allowed            10:15:23 29-Jan  42
+my-sandbox   network  registry.npmjs.org     forward-bypass domain-allowed            10:15:20 29-Jan  18
+my-sandbox   network  app.example.com        browser-open                             10:15:10 29-Jan  1
+```
+
+The `PROXY` column shows how the request left the sandbox:
+
+| Value            | Description                                                                                                    |
+| ---------------- | -------------------------------------------------------------------------------------------------------------- |
+| `forward`        | Routed through the forward proxy. Supports [credential injection](../../configuration/credentials.md).              |
+| `forward-bypass` | Routed through the forward proxy without credential injection.                                                 |
+| `transparent`    | Intercepted by the transparent proxy. Policy is enforced but credential injection is not available.            |
+| `network`        | Non-HTTP traffic (raw TCP, UDP, ICMP). TCP can be allowed with a policy rule. UDP and ICMP are always blocked. |
+| `browser-open`   | A sandbox process requested opening a URL in the host browser. Policy is enforced before opening the URL.      |
+
+The `RULE` column identifies the policy rule that matched the request. The
+`REASON` column includes extra context when the daemon records one.
+
+Filter by sandbox name by passing it as an argument:
+
+```console
+$ sbx policy log my-sandbox
+```
+
+Use `--limit N` to show only the last `N` entries, `--json` for
+machine-readable output, or `--type network` to filter by policy type.
+`sbx policy log` records network traffic only; filesystem mount decisions
+aren't available in the log yet.
diff --git a/content/manuals/ai/sandboxes/governance/monitor-and-enforce/sign-in-enforcement.md b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/sign-in-enforcement.md
new file mode 100644
index 000000000000..ba30413d3453
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/monitor-and-enforce/sign-in-enforcement.md
@@ -0,0 +1,273 @@
+---
+title: Sign-in enforcement
+linkTitle: Sign-in enforcement
+weight: 20
+description: Require Docker Sandboxes users to sign in as members of your organization, enforced through endpoint management.
+keywords: docker sandboxes, sign-in enforcement, organization enforcement, sbx login, MDM, configuration profile, registry key, allowedOrgs
+aliases:
+  - /ai/sandboxes/governance/sign-in-enforcement/
+---
+
+Sign-in enforcement restricts Docker Sandboxes to users who are members of
+specific Docker organizations. An administrator deploys an enforcement
+configuration to managed endpoints, and `sbx login` verifies organization
+membership after the user authenticates. If the check fails, credentials are
+immediately revoked and the user can't run sandboxes.
+
+Without this enforcement, a developer can sign in with a personal account and
+bypass organization [governance policies](../access-controls/organization.md).
+Sign-in enforcement closes that gap at the endpoint, where users can't override
+it.
+
+> [!NOTE]
+> Sign-in enforcement is part of Docker's AI Governance offering.
+> [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
+> to learn more.
+
+## How it works
+
+1. An administrator deploys an enforcement configuration to managed endpoints
+   through MDM, Group Policy, or configuration management, specifying one or
+   more allowed Docker organization slugs.
+2. When a user runs `sbx login`, they authenticate with Docker. Credentials
+   are saved temporarily, then Docker Sandboxes calls the Docker API to
+   verify organization membership.
+3. If the user belongs to at least one allowed organization, login succeeds and
+   the credentials are kept.
+4. If not, Docker Sandboxes immediately revokes the saved credentials and the
+   user receives an [error message](#error-messages) listing the required
+   organizations.
+
+`sbx login` and `sbx logout` always run regardless of organization membership.
+Other commands require a valid signed-in session, so they fail after a denied
+login until the user signs in with an allowed account.
+
+## Enforcement configuration
+
+All platforms express the same logical schema. The canonical JSON
+representation:
+
+```json
+{
+  "allowedOrgs": ["docker", "acme-corp"],
+  "adminEmail": "it-security@acme-corp.com",
+  "adminURL": "https://acme-corp.atlassian.net/servicedesk/it",
+  "adminName": "ACME IT Security Team"
+}
+```
+
+| Field         | Type            | Required | Description                                                                                         |
+| ------------- | --------------- | -------- | --------------------------------------------------------------------------------------------------- |
+| `allowedOrgs` | list of strings | Yes      | Docker organization slugs. The user must be a member of at least one. Matching is case-insensitive. |
+| `adminName`   | string          | No       | Administrator or team display name shown in the denial message.                                     |
+| `adminEmail`  | string          | No       | Contact email shown in the denial message.                                                          |
+| `adminURL`    | string          | No       | Help desk or access-request URL shown in the denial message.                                        |
+
+If `allowedOrgs` is empty or missing, enforcement is inactive and any
+authenticated user can use Docker Sandboxes.
+
+The optional `adminName`, `adminEmail`, and `adminURL` fields give denied users
+a path to resolution. Include the contact details your organization uses for
+access requests.
+
+## Deploy the configuration
+
+Use your existing endpoint management tooling to deploy the configuration. Each
+platform reads it from a native location that ordinary users can't modify.
+
+{{< tabs >}}
+{{< tab name="macOS" >}}
+
+On macOS, the configuration is a managed preferences domain, `com.docker.sbx`.
+
+Deploy it through any MDM solution, such as Jamf or Intune, as a custom
+configuration profile. MDM-deployed profiles take precedence over user-level
+preferences and can only be removed by removing the device from MDM management,
+so users can't override them.
+
+The following `.mobileconfig` payload sets the allowed organization and admin
+contact details:
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
+  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+  <key>PayloadContent</key>
+  <array>
+    <dict>
+      <key>PayloadType</key>
+      <string>com.apple.ManagedClient.preferences</string>
+      <key>PayloadVersion</key>
+      <integer>1</integer>
+      <key>PayloadIdentifier</key>
+      <string>com.docker.sbx.policy</string>
+      <key>PayloadUUID</key>
+      <string><!-- generate a UUID --></string>
+      <key>PayloadEnabled</key>
+      <true/>
+      <key>PayloadDisplayName</key>
+      <string>Docker Sandboxes Policy</string>
+      <key>PayloadContent</key>
+      <dict>
+        <key>com.docker.sbx</key>
+        <dict>
+          <key>Forced</key>
+          <array>
+            <dict>
+              <key>mcx_preference_settings</key>
+              <dict>
+                <key>allowedOrgs</key>
+                <array>
+                  <string>acme-corp</string>
+                </array>
+                <key>adminEmail</key>
+                <string>it-security@acme-corp.com</string>
+                <key>adminURL</key>
+                <string>https://acme-corp.atlassian.net/servicedesk/it</string>
+                <key>adminName</key>
+                <string>ACME IT Security</string>
+              </dict>
+            </dict>
+          </array>
+        </dict>
+      </dict>
+    </dict>
+  </array>
+</dict>
+</plist>
+```
+
+To test the configuration locally without MDM, write to the user preferences
+domain:
+
+```console
+$ defaults write com.docker.sbx allowedOrgs -array "acme-corp"
+$ defaults write com.docker.sbx adminEmail "it@acme.com"
+```
+
+To remove the test configuration:
+
+```console
+$ defaults delete com.docker.sbx
+```
+
+`defaults write` uses the user preferences domain, not the managed-preferences
+domain. On a managed device, the MDM profile is authoritative and user-level
+settings in the same domain are ignored.
+
+{{< /tab >}}
+{{< tab name="Windows" >}}
+
+Deploy it through Group Policy, Intune, or any endpoint management tool that can
+write registry values.
+
+| Value name    | Type           | Description                                         |
+| ------------- | -------------- | --------------------------------------------------- |
+| `allowedOrgs` | `REG_MULTI_SZ` | Multi-string list, one organization slug per string |
+| `adminName`   | `REG_SZ`       | Administrator or team name (optional)               |
+| `adminEmail`  | `REG_SZ`       | Contact email (optional)                            |
+| `adminURL`    | `REG_SZ`       | Help desk URL (optional)                            |
+
+To test the configuration locally, run the following in an elevated PowerShell
+session. Use `New-ItemProperty` to create values with an explicit type;
+`Set-ItemProperty` doesn't create new values.
+
+```powershell
+New-Item -Path "HKLM:\SOFTWARE\Policies\Docker\SBX" -Force
+
+New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Docker\SBX" `
+  -Name "allowedOrgs" -Value @("acme-corp") -PropertyType MultiString -Force
+New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Docker\SBX" `
+  -Name "adminEmail" -Value "it@acme.com" -PropertyType String -Force
+```
+
+To remove the configuration:
+
+```powershell
+Remove-Item -Path "HKLM:\SOFTWARE\Policies\Docker\SBX" -Recurse -Force
+```
+
+{{< /tab >}}
+{{< tab name="Linux" >}}
+
+On Linux, the configuration is a root-owned JSON file at
+`/etc/docker-sbx/config.json`.
+
+Deploy it through configuration management such as Ansible, Puppet, Chef, or
+Salt. The file must be owned by root with `644` permissions.
+
+```json
+{
+  "allowedOrgs": ["acme-corp"],
+  "adminEmail": "it-security@acme-corp.com",
+  "adminURL": "https://acme-corp.atlassian.net/servicedesk/it",
+  "adminName": "ACME IT Security"
+}
+```
+
+To deploy and set ownership:
+
+```console
+$ sudo mkdir -p /etc/docker-sbx
+$ sudo tee /etc/docker-sbx/config.json <<'EOF'
+{"allowedOrgs": ["acme-corp"], "adminEmail": "it@acme.com"}
+EOF
+$ sudo chown root:root /etc/docker-sbx/config.json
+$ sudo chmod 644 /etc/docker-sbx/config.json
+```
+
+To remove the configuration:
+
+```console
+$ sudo rm -f /etc/docker-sbx/config.json
+```
+
+The Linux loader fails closed if the file is a symlink, isn't a regular file,
+isn't owned by root, or is writable by group or other. Any deviation is treated
+as a configuration error and `sbx login` is denied with a descriptive message.
+Deploying with the commands above passes these checks.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Error messages
+
+When a user signs in with an account that isn't a member of an allowed
+organization, they're signed out and shown a denial message. Only the contact
+fields you configure appear: if only `adminEmail` is set, the URL line is
+omitted.
+
+When no admin contact details are configured:
+
+```text
+Access denied: Your administrator requires you to be logged into an account
+that is a member of one of the following Docker organizations:
+  - acme-corp
+
+Sign in with an account that belongs to one of these organizations, or
+contact your administrator for access.
+```
+
+When admin contact details are configured:
+
+```text
+Access denied: Your administrator requires you to be logged into an account
+that is a member of one of the following Docker organizations:
+  - acme-corp
+
+For access, contact ACME IT Security:
+  Email: it-security@acme-corp.com
+  URL:   https://acme-corp.atlassian.net/servicedesk/it
+```
+
+## Related pages
+
+- [Organization policies](../access-controls/organization.md): centrally manage
+  sandbox network, filesystem, and MCP access controls from the Docker Admin
+  Console
+- [Governance overview](../_index.md): how local and organization governance fit
+  together
+- [Enforce sign-in for Docker Desktop](/manuals/enterprise/security/enforce-sign-in/_index.md):
+  the equivalent control for Docker Desktop
diff --git a/content/manuals/ai/sandboxes/governance/reference/_index.md b/content/manuals/ai/sandboxes/governance/reference/_index.md
new file mode 100644
index 000000000000..5358776a0a49
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/reference/_index.md
@@ -0,0 +1,15 @@
+---
+title: Reference
+weight: 50
+description: Reference material for Docker AI Governance policy APIs and policy syntax.
+keywords: docker sandboxes, governance reference, governance API, policy reference
+---
+
+Use reference material when you need API details or exact policy syntax.
+
+- [Policy concepts](../concepts.md): resource model, rule syntax, policy
+  evaluation, and precedence.
+- [AI Governance API](/reference/api/ai-governance/): HTTP API reference for
+  network and filesystem organization policies.
+- [MCP policy reference](mcp-policy.md): Docker MCP policy actions, resources,
+  attributes, context fields, and approval behavior.
diff --git a/content/manuals/ai/sandboxes/governance/reference/api.md b/content/manuals/ai/sandboxes/governance/reference/api.md
new file mode 100644
index 000000000000..36e6297f165b
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/reference/api.md
@@ -0,0 +1,11 @@
+---
+title: AI Governance API
+linkTitle: API reference
+description: Programmatic management of Docker AI Governance policies and rules via HTTP+JSON.
+keywords: docker sandboxes, AI Governance API, governance API, policy API, organization policies
+weight: 10
+build:
+  render: never
+sidebar:
+  goto: /reference/api/ai-governance/
+---
diff --git a/content/manuals/ai/sandboxes/governance/reference/mcp-policy.md b/content/manuals/ai/sandboxes/governance/reference/mcp-policy.md
new file mode 100644
index 000000000000..2080e85a23ca
--- /dev/null
+++ b/content/manuals/ai/sandboxes/governance/reference/mcp-policy.md
@@ -0,0 +1,201 @@
+---
+title: MCP policy reference
+linkTitle: MCP policy
+weight: 20
+description: Reference for Docker MCP policy actions, resources, attributes, context fields, and approval behavior.
+keywords: docker sandboxes, MCP policy, Cedar policy, MCP actions, MCP resources, requireApproval, AI Governance
+---
+
+MCP policies are organization policies written in Cedar using Docker's `MCP`
+namespace. This reference defines the Docker-specific policy surface for Model
+Context Protocol (MCP) activity made available to sandboxes through Docker's
+[MCP gateway](../../mcp-gateway.md).
+
+Use this reference with [MCP access policies](../access-controls/mcp.md) for
+common policy patterns. For the Cedar language, see the
+[Cedar documentation](https://docs.cedarpolicy.com/).
+
+## Evaluation model
+
+Cedar evaluates MCP requests against a principal, action, resource, and context.
+For Docker MCP policies, policy scope supplies the principal. Write policies
+against the action, resource, and context. Clauses that reference principal
+attributes, such as `principal in ...`, `principal.role`, or
+`principal.tenant`, don't match.
+
+Governed MCP activity is default deny. A request is blocked unless a matching
+`permit` allows it. A matching `forbid` overrides any `permit`, including a
+permit annotated with `@requireApproval`.
+
+For details about when Docker Sandboxes evaluates MCP policies for a user, see
+[Govern the server lifecycle](../access-controls/mcp.md#govern-the-server-lifecycle).
+
+An actionless `permit` matches every MCP action that reaches Cedar evaluation:
+
+```plaintext
+permit (principal, action, resource);
+```
+
+## Actions
+
+| Action              | Governs                   | Notes                                                                                                          |
+| ------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------- |
+| `register`          | MCP server registration   | Server registration needs an explicit `permit`. Use server attributes to scope registration.                   |
+| `invokeTool`        | MCP tool calls            | Most tool access policies target this action.                                                                  |
+| `invokePrimordial`  | Gateway meta-tool calls   | Applies to built-in gateway tools such as `mcp-exec`, `mcp-add`, `code-mode`, and OAuth authorization helpers. |
+| `readResource`      | MCP resource reads        | Rules match `MCP::Resource` and `resource.uri`.                                                                |
+| `getPrompt`         | MCP prompt retrieval      | Rules match `MCP::Prompt` and `resource.name`.                                                                 |
+| `listTools`         | MCP tool listing          | Defined in the schema but not Cedar-gated. Tool listings can include tools denied at invocation.               |
+| `listResources`     | MCP resource listing      | Defined in the schema but not Cedar-gated. Resource listings can include resources denied by policy.           |
+| `subscribeResource` | MCP resource subscription | Defined in the schema but not Cedar-gated.                                                                     |
+
+## Resources
+
+Match resources with the MCP entity type and attributes for the request.
+
+| Entity            | Match with             | Notes                                                                                                                            |
+| ----------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| `MCP::Server`     | Registered server name | The canonical server identity is the `resource.identityURL` attribute, not the entity ID.                                        |
+| `MCP::Tool`       | Bare tool name         | Use `resource.name`. Display prefixes aren't included. A bare-name match applies to every server exposing a tool with that name. |
+| `MCP::Resource`   | Resource URI           | Use `resource.uri`.                                                                                                              |
+| `MCP::Prompt`     | Prompt name            | Use `resource.name`.                                                                                                             |
+| `MCP::Primordial` | Gateway meta-tool name | Match a specific primordial with an entity reference.                                                                            |
+
+Examples:
+
+```plaintext
+resource in MCP::Server::"notion"
+resource.name == "move_file"
+resource.uri like "*/docs/*"
+resource in MCP::Primordial::"code-mode"
+```
+
+## Resource attributes
+
+Tool annotation attributes come from MCP tool annotations or catalog metadata
+and are advisory.
+
+| Attribute                  | Applies to        | Notes                                                                                                                                                 |
+| -------------------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `resource.name`            | Tools and prompts | For tools, this is the bare tool name, not a display-prefixed name.                                                                                   |
+| `resource.uri`             | Resources         | Use with string operators such as `like`.                                                                                                             |
+| `resource.readOnly`        | Tools             | Defaults to `false` when a tool doesn't declare it.                                                                                                   |
+| `resource.destructive`     | Tools             | Defaults to `true` when a tool doesn't declare it.                                                                                                    |
+| `resource.idempotent`      | Tools             | Defaults to `false` when a tool doesn't declare it.                                                                                                   |
+| `resource.openWorld`       | Tools             | Defaults to `true` when a tool doesn't declare it.                                                                                                    |
+| `resource.type`            | Servers           | Use for server registration rules. See [Server type values](#server-type-values).                                                                     |
+| `resource.identityURL`     | Servers           | Canonical server identity. The value depends on the registration type. See [Server identity values](#server-identity-values).                         |
+| `resource.requiresOAuth`   | Servers           | Use for server registration rules.                                                                                                                    |
+| `resource.requiresNetwork` | Servers           | Use for server registration rules.                                                                                                                    |
+| `resource.command`         | Servers           | Local stdio server command, such as `npx` or `docker`, when available. Empty for remote servers and registrations that don't include command details. |
+| `resource.args`            | Servers           | Local stdio server arguments when available. This is a set, so `.contains()` can match values. Empty when no command details are available.           |
+
+Use `like` for string attributes. In Cedar, `like` uses `*` as its wildcard,
+matches the full string, treats `?` as a literal character, and treats `\*` as
+a literal asterisk.
+
+Use `.contains()` only on set attributes, such as `resource.args`. On string
+attributes, use `like`.
+
+### Server type values
+
+Local gateway registrations use these values:
+
+- `local-stdio`: a host-run stdio server. This includes explicit commands and
+  OCI-packaged stdio servers resolved from metadata with `--local`.
+- `container-stdio`: an OCI-packaged server resolved from metadata without
+  `--local`. This value can appear in `register` decisions, but the local
+  gateway can't attach or run this server type.
+- `remote-dcr`: a remote endpoint that doesn't require OAuth or supports OAuth
+  Dynamic Client Registration.
+- `remote-no-dcr`: a remote OAuth endpoint that doesn't support Dynamic Client
+  Registration.
+
+### Server identity values
+
+For a remote server, `resource.identityURL` is the endpoint URL. For an explicit
+local command, it is the resolved executable path on the host. For a `--local`
+metadata registration, it is `local://stdio/<name>`, not the registry or
+manifest URL.
+
+## Context fields
+
+| Field                  | Notes                                                                                                                                       |
+| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
+| `context.request_time` | Bound for tool calls, built-in gateway tool calls, resource reads, and prompt retrieval. Registration requests don't include it.            |
+| `context.args`         | Arguments for `invokeTool` and `invokePrimordial` requests evaluated by the gateway. Present when arguments are available as a JSON object. |
+
+A registration `permit` conditioned on `context.request_time` doesn't match,
+so the registration falls to default deny.
+
+Guard tool-call argument rules with `context has args` and a field check:
+
+```plaintext
+permit (principal, action == MCP::Action::"invokeTool", resource)
+when {
+  resource.name == "approve_expense" &&
+  context has args &&
+  context.args has amount &&
+  context.args.amount <= 500
+};
+```
+
+A `permit` gated on missing arguments doesn't match, so the request falls to
+default deny. A `forbid` gated on missing arguments doesn't match, so it
+doesn't block the request.
+
+Only object-shaped tool arguments are represented in `context.args`.
+Unsupported or malformed arguments are omitted.
+
+## Approval annotation
+
+Use `@requireApproval("reason")` on a `permit` statement to require in-session
+confirmation through MCP elicitation before a matching request runs:
+
+```plaintext
+@requireApproval("write tool call")
+permit (principal, action == MCP::Action::"invokeTool", resource)
+when { resource.readOnly == false };
+```
+
+When a request matches the annotated `permit` and no `forbid` overrides it, the
+policy engine returns an approval-required outcome. The annotation string is
+shown as the elicitation reason. An approval-required outcome takes precedence
+over a normal `permit`. A matching `forbid` denies the request without an
+elicitation.
+
+For the request flow and trust model, see
+[Require confirmation with MCP elicitation](../access-controls/mcp.md#require-confirmation-with-mcp-elicitation).
+
+Approval requires a client session that can present an MCP elicitation request
+to the user. If the request can't be presented for approval, the request is
+denied. Approval is an in-session confirmation, not an out-of-band approval
+workflow. Each confirmation applies to one authorization request. After the
+client confirms, the gateway re-evaluates the request with an approval digest.
+
+`sbx mcp add` can't present an elicitation request. A registration permit with
+`@requireApproval` therefore results in a denial.
+
+Only the exact annotation name `@requireApproval` applies approval behavior.
+Other annotation names, such as `@requireConsent` or `@requireConfirmation`,
+don't require approval.
+
+## Limitations
+
+- Tool and resource listing actions aren't Cedar-gated. Listings can include
+  entries that a policy denies when the sandbox tries to use them.
+- Approval-gated requests are denied when the execution context can't relay an
+  MCP elicitation to the originating client. This includes tool calls made from
+  inside `code-mode`.
+- Registration policy is evaluated when a server is registered. It doesn't
+  remove existing registrations or stop an already-loaded server by itself.
+  Govern existing registrations with use-time rules such as `invokeTool`,
+  `readResource`, and `getPrompt`.
+- Server command and argument rules using `resource.command` or `resource.args`
+  apply only when the resolved server registration includes local stdio command
+  details. Remote servers and metadata-resolved local servers can have empty
+  values for those attributes. Use `resource.type == "local-stdio"` to match
+  host-run servers independently of command details.
+- Principal-based rules don't take effect. Use organization and team policy
+  scope to target users.
+- Server groups aren't supported in MCP policy. Reference servers individually.
diff --git a/content/manuals/ai/sandboxes/images/sbx-dashboard.png b/content/manuals/ai/sandboxes/images/sbx-dashboard.png
new file mode 100644
index 000000000000..fb454c1d45c1
Binary files /dev/null and b/content/manuals/ai/sandboxes/images/sbx-dashboard.png differ
diff --git a/content/manuals/ai/sandboxes/images/sbx-security.png b/content/manuals/ai/sandboxes/images/sbx-security.png
new file mode 100644
index 000000000000..0f86c436c507
Binary files /dev/null and b/content/manuals/ai/sandboxes/images/sbx-security.png differ
diff --git a/content/manuals/ai/sandboxes/install.md b/content/manuals/ai/sandboxes/install.md
new file mode 100644
index 000000000000..01aa69e2d647
--- /dev/null
+++ b/content/manuals/ai/sandboxes/install.md
@@ -0,0 +1,124 @@
+---
+title: Install Docker Sandboxes
+linkTitle: Install
+weight: 10
+description: Install the sbx CLI on macOS, Windows, or Linux and sign in to Docker Sandboxes.
+keywords: sandbox, sbx, install, macOS, Windows, Linux, Ubuntu
+---
+
+Install the `sbx` CLI to run AI coding agents in isolated microVMs. You don't
+need Docker Desktop or Docker Engine to use `sbx`.
+
+## Prerequisites
+
+### macOS
+
+- macOS Sonoma version 14 or later
+- Apple silicon
+
+### Windows
+
+- Windows 11
+- A 64-bit Intel or AMD processor
+- Windows Hypervisor Platform
+
+To turn on Windows Hypervisor Platform, open an elevated PowerShell prompt and
+run:
+
+```powershell
+Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All
+```
+
+### Linux
+
+- Ubuntu 24.04 or later
+- A 64-bit Intel or AMD processor, or a 64-bit Arm processor
+- KVM hardware virtualization supported and turned on by the CPU
+- Your user account in the `kvm` group
+
+If you're running inside a virtual machine or virtual desktop infrastructure
+environment, the environment must support nested virtualization.
+
+Verify that KVM is available:
+
+```console
+$ lsmod | grep kvm
+```
+
+A working setup shows `kvm_intel`, `kvm_amd`, `kvm_arm64`, or `kvm` in the
+output. If the output is empty, run `kvm-ok` for diagnostics. `sbx` requires
+KVM to start.
+
+Add your user to the `kvm` group:
+
+```console
+$ sudo usermod -aG kvm $USER
+```
+
+Sign out and back in, or run `newgrp kvm`, for the group change to take effect.
+
+## Install on macOS
+
+Install `sbx` using Homebrew:
+
+```console
+$ brew trust docker/tap
+$ brew install docker/tap/sbx
+```
+
+## Install on Windows
+
+Install `sbx` using Windows Package Manager:
+
+```powershell
+winget install -h Docker.sbx
+```
+
+## Install on Ubuntu
+
+> [!NOTE]
+>
+> Docker does not test or support Docker Sandboxes on Ubuntu derivatives, such
+> as Linux Mint and Pop!_OS. The convenience script can configure an incorrect
+> package repository on these distributions.
+
+You can install `sbx` with Docker Engine or install only the `sbx` package.
+
+### Install Docker Engine and SBX
+
+Run Docker's convenience script with `SBX=1` to install Docker Engine and the
+`docker-sbx` package together:
+
+```console
+$ curl -fsSL https://get.docker.com | sudo SBX=1 sh
+```
+
+### Install SBX only
+
+To install `sbx` without Docker Engine on the host, add Docker's `apt`
+repository and install the `docker-sbx` package:
+
+```console
+$ curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
+$ sudo apt install docker-sbx
+```
+
+## Install from release artifacts
+
+To install `sbx` from a package or archive, follow the
+[manual installation instructions](https://github.com/docker/sbx-releases#manual-install-from-release-artifacts).
+The availability of a Linux release artifact does not indicate that Docker
+tests or supports the corresponding distribution.
+
+## Sign in
+
+Sign in to Docker:
+
+```console
+$ sbx login
+```
+
+The command opens a browser for Docker OAuth. See the [FAQ](faq.md) for why
+sign-in is required and how Docker handles your data.
+
+After signing in, [run your first sandbox](get-started.md).
diff --git a/content/manuals/ai/sandboxes/integrations/_index.md b/content/manuals/ai/sandboxes/integrations/_index.md
new file mode 100644
index 000000000000..f83db01d2ad1
--- /dev/null
+++ b/content/manuals/ai/sandboxes/integrations/_index.md
@@ -0,0 +1,148 @@
+---
+title: Editor and app integrations
+linkTitle: Integrations
+weight: 70
+description: Connect editors and desktop apps to a Docker Sandbox over SSH.
+keywords: docker sandboxes, ssh, integrations, vs code, cursor, remote development, sbx
+---
+
+{{< summary-bar feature_name="Docker Sandboxes SSH" >}}
+
+You can connect an external editor or desktop app to a running sandbox over
+SSH. This lets you use the tools you already know — VS Code, Cursor, Claude
+Desktop, and others — while your code runs, builds, and executes inside the
+isolated sandbox instead of on your host.
+
+Each sandbox is reachable at `<name>.sbx`, where `<name>` is the sandbox name.
+Once SSH is set up, `<name>.sbx` behaves like any other SSH host, so any tool
+that supports remote development over SSH can connect to it.
+
+## Prerequisites
+
+- The `sbx` CLI installed and signed in. See [Get started](../get-started.md).
+- An SSH client. macOS and most Linux distributions include OpenSSH. On
+  Windows, install the OpenSSH client.
+- The editor or app you want to connect, with its remote-over-SSH support
+  installed.
+
+## Enable SSH access
+
+Run the SSH setup command once:
+
+```console
+$ sbx setup ssh
+```
+
+The command starts the Docker Sandboxes daemon if needed and configures your
+SSH client. You can re-run it at any time.
+
+## Create or identify a sandbox
+
+SSH connections require an existing sandbox. To create a named shell sandbox
+for the current directory:
+
+```console
+$ sbx create --name demo shell .
+```
+
+To identify an existing sandbox, list your sandboxes:
+
+```console
+$ sbx ls
+```
+
+## Connect to a sandbox over SSH
+
+Use the sandbox name with the `.sbx` suffix. For example, to connect to a
+sandbox named `demo`:
+
+```console
+$ ssh demo.sbx
+```
+
+## Select the workspace folder
+
+Connecting an app to a sandbox selects the remote environment, but it might not
+open the mounted workspace automatically. Use the app's remote folder picker to
+select the workspace when you configure the connection or start a session.
+
+The folder picker might open at the sandbox user's home directory, typically
+`/home/agent`. Workspaces retain their absolute host paths inside the sandbox.
+For example, if you mount `/Users/bob/src/my-project`, select
+`/Users/bob/src/my-project` in the remote folder picker.
+
+## Connect a specific tool
+
+- [VS Code](vscode.md)
+- [Cursor](cursor.md)
+- [Claude Desktop](claude-desktop.md)
+- [ChatGPT](chatgpt.md)
+- [T3 Code](t3-code.md)
+
+## How SSH connections work
+
+### Managed SSH configuration
+
+`sbx setup ssh` writes a managed block to your SSH config: `~/.ssh/config` on
+macOS and Linux, or `%USERPROFILE%\.ssh\config` on Windows. The block is similar
+to the following:
+
+```text
+# >>> docker sandboxes (managed) >>>
+Host *.sbx
+    User _default_user_
+    ProxyCommand "sbx" ssh proxy %n
+    IdentityAgent none
+    IdentityFile /dev/null
+    IdentitiesOnly yes
+    ControlMaster no
+    ControlPath none
+    UserKnownHostsFile "~/.ssh/sbx_known_hosts"
+    KnownHostsCommand "sbx" ssh known-hosts %H
+    StrictHostKeyChecking yes
+# <<< docker sandboxes (managed) <<<
+```
+
+You don't edit this block by hand. Its key entries work as follows:
+
+- `Host *.sbx` maps sandbox hostnames to the sandbox daemon. Application host
+  pickers don't discover individual sandbox names from this wildcard, so enter
+  the hostname, such as `demo.sbx`, manually when you configure an integration.
+- `User _default_user_` tells the daemon to use the sandbox image's default
+  user, so your host username is never sent.
+
+### Connection and authentication
+
+Connections don't use a network port or an SSH key:
+
+- A `ProxyCommand` relays the SSH stream to the daemon over its local socket
+  (a Unix domain socket on macOS and Linux, a named pipe on Windows).
+- The daemon accepts the connection only while you have an active Docker login.
+  Authentication is tied to your login, not to a stored key.
+- The host key is verified on every connection, so a rotated daemon key never
+  triggers a host-key mismatch.
+
+Because SSH terminates at the daemon, no SSH server runs inside the sandbox.
+The sandbox must already be created. If it is stopped, connecting to
+`<name>.sbx` starts it automatically.
+
+### Environment variables
+
+SSH connections don't forward client environment variables into the sandbox.
+The daemon acknowledges SSH environment requests for compatibility but ignores
+their names and values.
+
+### Port forwarding
+
+SSH clients can use local port forwarding to make a service listening on the
+sandbox's loopback interface available on the host. For example, a remote
+development client can map `127.0.0.1:4321` in the sandbox to
+`127.0.0.1:55565` on the host, choosing an available host port automatically.
+Traffic passes through the SSH connection instead of a published Docker port.
+
+The sandbox daemon accepts forwarded connections only to loopback addresses in
+the sandbox, including `localhost`, `127.0.0.0/8`, and `::1`. The SSH client
+chooses the bind address for the listener on the host. A listener bound to
+`127.0.0.1` or `::1` is reachable only from the host. A client configured to
+bind to a non-loopback address can make the forwarded service reachable from
+other machines, subject to the host's network and firewall configuration.
diff --git a/content/manuals/ai/sandboxes/integrations/chatgpt.md b/content/manuals/ai/sandboxes/integrations/chatgpt.md
new file mode 100644
index 000000000000..134a0f70d6ec
--- /dev/null
+++ b/content/manuals/ai/sandboxes/integrations/chatgpt.md
@@ -0,0 +1,68 @@
+---
+title: Connect ChatGPT to a sandbox
+linkTitle: ChatGPT
+weight: 40
+description: Run Codex in the ChatGPT desktop app against a Docker Sandbox over SSH.
+keywords: docker sandboxes, chatgpt, codex, openai, remote ssh, sbx
+---
+
+{{< summary-bar feature_name="Docker Sandboxes SSH" >}}
+
+Connect the ChatGPT desktop app to a sandbox over SSH so Codex works inside the
+isolated environment instead of on your host.
+
+> [!NOTE]
+> This page covers running Codex in the ChatGPT desktop app connected to a
+> sandbox over SSH. To run the Codex CLI inside a sandbox directly, see
+> [Codex](../agents/codex.md).
+
+## Prerequisites
+
+- SSH access set up. See [Editor and app integrations](_index.md#enable-ssh-access).
+- The ChatGPT desktop app installed.
+
+ChatGPT's remote server requires the `codex` command in the sandbox. The Codex
+sandbox template used in the following section includes this command.
+
+## Connect
+
+Create a named Codex sandbox for the current directory if you don't already
+have one:
+
+```console
+$ sbx create --name demo codex .
+```
+
+Confirm that you can connect to the sandbox from a terminal:
+
+```console
+$ ssh demo.sbx
+```
+
+In the ChatGPT desktop app, open **Settings > Connections** and add an SSH
+connection manually. Enter the sandbox hostname, such as `demo.sbx`, as the
+host, then use the remote folder picker to
+[select the mounted workspace](_index.md#select-the-workspace-folder) as the
+remote project.
+
+For more connection options, see the OpenAI instructions to
+[connect to an SSH host](https://learn.chatgpt.com/docs/remote-connections#connect-to-an-ssh-host).
+
+## Full access still prompts for approval
+
+ChatGPT controls Codex permissions separately from the Docker Sandbox. To run
+commands without Codex approval prompts, select **Full access** from the
+permissions menu for the remote chat. Enabling **Full access** under
+**Settings > General** only adds the mode to the permissions menu. It doesn't
+change an existing chat.
+
+If the chat continues to request approval while showing **Full access**, update
+the ChatGPT desktop app, then stop and restart the active task. Approval prompts
+that return after reconnecting can indicate a
+[Codex remote-permission synchronization issue](https://github.com/openai/codex/issues/29054).
+
+## Related
+
+- [Editor and app integrations](_index.md) — how SSH access works and how to
+  set it up
+- [Codex](../agents/codex.md) — run the Codex CLI inside a sandbox
diff --git a/content/manuals/ai/sandboxes/integrations/claude-desktop.md b/content/manuals/ai/sandboxes/integrations/claude-desktop.md
new file mode 100644
index 000000000000..26017d71942f
--- /dev/null
+++ b/content/manuals/ai/sandboxes/integrations/claude-desktop.md
@@ -0,0 +1,92 @@
+---
+title: Connect Claude Desktop to a sandbox
+linkTitle: Claude Desktop
+weight: 30
+description: Run Claude Code from Claude Desktop against a Docker Sandbox over SSH.
+keywords: docker sandboxes, claude desktop, claude code, remote ssh, sbx
+---
+
+{{< summary-bar feature_name="Docker Sandboxes SSH" >}}
+
+Claude Desktop can run Claude Code on a remote machine over SSH. Point it at a
+sandbox so the agent works inside the isolated environment instead of on your
+host.
+
+> [!NOTE]
+> This page covers Claude Desktop connecting to a sandbox over SSH. To run the
+> Claude Code CLI inside a sandbox directly, see
+> [Claude Code](../agents/claude-code.md).
+
+## Prerequisites
+
+- SSH access set up. See [Editor and app integrations](_index.md#enable-ssh-access).
+- Claude Desktop installed.
+
+Use a sandbox created with the Claude agent type. The Claude sandbox template
+configures Anthropic credentials and network access for the remote Claude Code
+session.
+
+## Connect
+
+> [!WARNING]
+> Connecting Claude Desktop to a sandbox over SSH transmits Anthropic
+> credentials into the Claude Code process within the sandbox, reducing
+> isolation guarantees.
+
+Create a named Claude sandbox for the current directory if you don't already
+have one:
+
+```console
+$ sbx create --name demo claude .
+```
+
+Confirm that you can connect to the sandbox from a terminal:
+
+```console
+$ ssh demo.sbx
+```
+
+In Claude Desktop, open the environment drop-down before starting a session and
+select **+ Add SSH connection**. Enter a name for the connection and enter the
+sandbox hostname, such as `demo.sbx`, in **SSH Host**. Leave **SSH Port** and
+**Identity File** empty because the managed SSH config supplies them.
+
+Select the connection from the environment drop-down, then use the remote
+folder picker to
+[select the mounted workspace](_index.md#select-the-workspace-folder). The
+picker might initially open at `/home/agent`.
+
+For more connection options, see the Claude Desktop instructions for
+[SSH sessions](https://code.claude.com/docs/en/desktop#ssh-sessions).
+
+## Troubleshoot a broken SSH connection after token refresh
+
+The SSH connection drops when the Anthropic token expires and needs to be
+refreshed. To work around this, run the sandbox manually from your host:
+
+```console
+$ sbx run --name <sandbox-name>
+```
+
+## Troubleshoot SSH connection timeouts on Windows
+
+Claude Desktop requires Git on Windows. If an SSH connection times out and the
+Claude Desktop logs include `ProxyCommand error: spawn sh ENOENT`, install
+[Git for Windows](https://git-scm.com/download/win).
+
+If Git is already installed, verify that `sh.exe` is available on your `PATH`:
+
+```powershell
+PS> where.exe sh
+```
+
+If the command doesn't find `sh.exe`, add the Git `bin` directory to your user
+`Path`. The default directory is `C:\Program Files\Git\bin`. Quit and restart
+Claude Desktop after updating `Path`.
+
+## Related
+
+- [Editor and app integrations](_index.md) — how SSH access works and how to
+  set it up
+- [Claude Code](../agents/claude-code.md) — run the Claude Code CLI inside a
+  sandbox
diff --git a/content/manuals/ai/sandboxes/integrations/cursor.md b/content/manuals/ai/sandboxes/integrations/cursor.md
new file mode 100644
index 000000000000..13024801ba69
--- /dev/null
+++ b/content/manuals/ai/sandboxes/integrations/cursor.md
@@ -0,0 +1,47 @@
+---
+title: Connect Cursor to a sandbox
+linkTitle: Cursor
+weight: 20
+description: Use Cursor's Remote - SSH support to develop inside a Docker Sandbox.
+keywords: docker sandboxes, cursor, remote ssh, remote development, sbx
+---
+
+{{< summary-bar feature_name="Docker Sandboxes SSH" >}}
+
+Cursor is built on VS Code, so it connects to a sandbox the same way, using
+Remote - SSH. Your editor stays on your host while files, terminals, and
+extensions run in the isolated sandbox.
+
+> [!NOTE]
+> This page covers the Cursor editor connecting to a sandbox over SSH. To run
+> the Cursor agent CLI inside a sandbox instead, see
+> [Cursor agent](../agents/cursor.md).
+
+## Prerequisites
+
+- SSH access set up. See [Editor and app integrations](_index.md#enable-ssh-access).
+- Cursor's Remote - SSH support installed.
+
+## Connect
+
+Confirm that you can connect to the sandbox from a terminal:
+
+```console
+$ ssh demo.sbx
+```
+
+1. Open the Command Palette and run **Remote-SSH: Connect to Host**.
+2. Enter the sandbox host manually as `<name>.sbx`.
+3. Cursor opens a new window connected to the sandbox. Use the remote folder
+   picker to [select the mounted workspace](_index.md#select-the-workspace-folder).
+
+## Notes
+
+- The first connection installs the editor server inside the sandbox, so it
+  can take a moment. Later connections are faster.
+
+## Related
+
+- [Editor and app integrations](_index.md) — how SSH access works and how to
+  set it up
+- [Cursor agent](../agents/cursor.md) — run the Cursor CLI inside a sandbox
diff --git a/content/manuals/ai/sandboxes/integrations/t3-code.md b/content/manuals/ai/sandboxes/integrations/t3-code.md
new file mode 100644
index 000000000000..fe7ddffb575b
--- /dev/null
+++ b/content/manuals/ai/sandboxes/integrations/t3-code.md
@@ -0,0 +1,158 @@
+---
+title: Connect T3 Code to a sandbox
+linkTitle: T3 Code
+weight: 50
+description: Run T3 Code against a Docker Sandbox over SSH.
+keywords: docker sandboxes, t3 code, remote ssh, remote development, sbx
+---
+
+{{< summary-bar feature_name="Docker Sandboxes SSH" >}}
+
+T3 Code's SSH integration lets the desktop app drive coding agents inside a
+sandbox. T3 Code has no dedicated Docker Sandboxes integration — it treats the
+sandbox as an ordinary SSH host, connects to it, and starts a T3 server inside
+that tunnels back to the app.
+
+## Prerequisites
+
+- SSH access set up. See [Editor and app integrations](_index.md#enable-ssh-access).
+- T3 Code installed.
+
+The first connection installs the T3 server in the sandbox, which needs a
+build toolchain. T3 depends on `node-pty`, which ships prebuilt binaries only
+for macOS and Windows. On a Linux sandbox, `node-pty` compiles from source and
+the build fails without `make`, `python3`, and a compiler such as `g++`.
+
+The [`t3code` kit](https://github.com/docker/sbx-kits-contrib/tree/main/t3code)
+prepares a sandbox for T3 Code: it installs the build toolchain and the `t3`
+npm package when the sandbox is created, so the first connection starts a
+pre-installed server instead of building `node-pty` from source. Pair it with
+any agent whose base image ships Node.js 18 or later, which all standard
+agent templates do:
+
+```console
+$ sbx run claude --kit docker.io/sbx/t3code-kit:latest
+```
+
+For an existing sandbox, install the toolchain manually:
+
+```console
+$ sbx exec <sandbox> -- sudo apt-get update
+$ sbx exec <sandbox> -- sudo DEBIAN_FRONTEND=noninteractive apt-get install -y g++ make python3
+```
+
+Verify the toolchain is in place:
+
+```console
+$ sbx exec <sandbox> -- sh -lc 'command -v g++ && command -v make && command -v python3'
+```
+
+A manual install lasts only until the sandbox is recreated, and the first
+connection still builds `node-pty` from source. For a setup that persists,
+recreate the sandbox with the [kit](../customize/kits.md) or a custom
+[template](../customize/templates.md).
+
+## Connect
+
+Confirm that you can connect to the sandbox from a terminal:
+
+```console
+$ ssh demo.sbx
+```
+
+In T3 Code, add an SSH environment and enter the sandbox hostname, such as
+`demo.sbx`, as the host. The first connection installs the T3 server inside
+the sandbox unless the `t3code` kit pre-installed it, so it can take a
+moment. Later connections are faster.
+
+Then add a new project, select the SSH environment from the list, and
+[choose the mounted workspace](_index.md#select-the-workspace-folder) as the
+project directory inside the sandbox.
+
+## Troubleshoot a server that never becomes ready
+
+T3 Code can fail to connect with an error like the following, wrapped here
+for readability. It concatenates the connection failure with npm's install
+output from inside the sandbox into a single error dialog:
+
+```text
+Could not prepare the SSH environment: ... SshCommandError: Connecting to
+sandbox "sandboxes"… Remote T3 server did not become ready on
+127.0.0.1:3773. npm WARN EBADENGINE Unsupported engine { package:
+'ini@7.0.0', required: { node: '^22.22.2 || ^24.15.0 || >=26.0.0' },
+current: { node: 'v22.22.1', npm: '9.2.0' } }
+```
+
+The `npm WARN EBADENGINE` lines warn about the transitive `ini` dependency
+and are separate from the failure: npm enforces engine requirements only
+when `engine-strict` is set, which is off by default, so this warning alone
+still lets the install proceed.
+
+The most common causes are a missing C++ toolchain and a full disk, and both
+produce this identical error. Get npm's actual output to tell them apart:
+
+```console
+$ sbx exec <sandbox> -- sh -lc \
+  'rm -rf /tmp/t3probe && mkdir -p /tmp/t3probe && cd /tmp/t3probe \
+   && npm init -y >/dev/null && npm install t3@latest 2>&1 | tail -40'
+```
+
+A missing compiler fails the native `node-pty` build with `Error 127` from
+`make`:
+
+```text
+npm ERR! make: g++: No such file or directory
+npm ERR! make: *** [pty.target.mk:115: Release/obj.target/pty/src/unix/pty.o] Error 127
+npm ERR! gyp ERR! build error
+npm ERR! gyp ERR! stack Error: `make` failed with exit code: 2
+```
+
+Install the build toolchain as described in [Prerequisites](#prerequisites).
+
+A full disk fails with `ENOSPC`, and no gyp output appears at all because npm
+fails before the native build starts:
+
+```text
+npm ERR! code ENOSPC
+npm ERR! nospc ENOSPC: no space left on device
+```
+
+Check free disk space:
+
+```console
+$ sbx exec <sandbox> -- df -h /
+```
+
+A sandbox can have both problems at once. Fixing one still leaves the same
+top-level error, so check both the toolchain and disk space before
+concluding the sandbox is ready. Free up space or install the toolchain as
+needed, then reconnect.
+
+## Troubleshoot `turn/setPermissionMode failed`
+
+If your organization manages Claude Code with a policy file, a local T3 Code
+thread can fail to start with `turn/setPermissionMode failed`. T3 Code's
+default runtime mode is Full access, which maps to the Claude Agent SDK's
+`bypassPermissions` mode. A managed policy that disables that mode rejects
+the request.
+
+On macOS, check whether this applies to you:
+
+```console
+$ cat "/Library/Application Support/ClaudeCode/managed-settings.json"
+```
+
+If `permissions.disableBypassPermissionsMode` is set to `disable`, switch T3
+Code to a different runtime mode, such as Supervised, Auto-accept edits, or
+Auto, then start a new thread. The permission mode is captured once when a
+thread starts, so switching modes in an already-failing thread doesn't
+recover it.
+
+This restriction applies to the host running Claude Code, not to a sandbox.
+A thread connected to a sandbox isn't subject to the host's managed policy,
+so Full access works normally there.
+
+## Related
+
+- [Editor and app integrations](_index.md) — how SSH access works and how to
+  set it up
diff --git a/content/manuals/ai/sandboxes/integrations/vscode.md b/content/manuals/ai/sandboxes/integrations/vscode.md
new file mode 100644
index 000000000000..3e82d46c674c
--- /dev/null
+++ b/content/manuals/ai/sandboxes/integrations/vscode.md
@@ -0,0 +1,88 @@
+---
+title: Connect VS Code to a sandbox
+linkTitle: VS Code
+weight: 10
+description: Use VS Code Remote - SSH to develop inside a Docker Sandbox.
+keywords: docker sandboxes, vs code, remote ssh, remote development, sbx
+---
+
+{{< summary-bar feature_name="Docker Sandboxes SSH" >}}
+
+Use the Remote - SSH extension to open a VS Code window that runs inside a
+sandbox. Your editor stays on your host while files, terminals, and extensions
+run in the isolated sandbox.
+
+## Prerequisites
+
+- SSH access set up. See [Editor and app integrations](_index.md#enable-ssh-access).
+- The [Remote - SSH](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh)
+  extension (`ms-vscode-remote.remote-ssh`) installed in VS Code.
+
+## Connect
+
+Confirm that you can connect to the sandbox from a terminal:
+
+```console
+$ ssh demo.sbx
+```
+
+In VS Code, open the Command Palette and run **Remote-SSH: Connect to Host...**.
+Enter the sandbox hostname, such as `demo.sbx`, manually. After VS Code
+connects, use the remote folder picker to
+[select the mounted workspace](_index.md#select-the-workspace-folder).
+
+For more connection options, see the VS Code instructions to
+[connect to a remote host](https://code.visualstudio.com/docs/remote/ssh#_connect-to-a-remote-host).
+
+## Notes
+
+- The first connection installs the VS Code server inside the sandbox, so it
+  can take a moment. Later connections are faster.
+
+### Reconnect loop on macOS
+
+Affected versions of VS Code can enter an infinite reconnect loop on macOS. If
+this happens, set `remote.SSH.useLocalServer` to `false` in your VS Code user
+settings:
+
+```json
+{
+  "remote.SSH.useLocalServer": false
+}
+```
+
+For details, see
+[microsoft/vscode-remote-release#11672](https://github.com/microsoft/vscode-remote-release/issues/11672).
+
+### SSH host key verification fails
+
+VS Code can leave duplicate or malformed `Host *.sbx` blocks in your SSH
+config after you add an SSH host. If a VS Code connection reports a
+`KnownHostsCommand` error or `Host key verification failed`, remove every SSH
+config block marked `docker sandboxes (managed)`, including the marker
+comments:
+
+```diff
+-# >>> docker sandboxes (managed) >>>
+-Host *.sbx
+-    User _default_user_
+-    ProxyCommand "sbx" ssh proxy %n
+-    ...
+-    UserKnownHostsFile "~/.ssh/sbx_known_hosts"
+-    KnownHostsCommand "sbx" ssh known-hosts %H
+-    StrictHostKeyChecking yes
+-# <<< docker sandboxes (managed) <<<
+```
+
+Then regenerate the managed block:
+
+```console
+$ sbx setup ssh
+```
+
+Reconnect to the sandbox from VS Code.
+
+## Related
+
+- [Editor and app integrations](_index.md) — how SSH access works and how to
+  set it up
diff --git a/content/manuals/ai/sandboxes/mcp-gateway.md b/content/manuals/ai/sandboxes/mcp-gateway.md
new file mode 100644
index 000000000000..81ef547e8e6c
--- /dev/null
+++ b/content/manuals/ai/sandboxes/mcp-gateway.md
@@ -0,0 +1,379 @@
+---
+title: MCP gateway
+description: Register MCP servers, authorize OAuth-backed servers, and connect MCP tools to Docker Sandboxes.
+keywords: docker sandboxes, sbx, MCP gateway, Model Context Protocol, MCP servers, sbx mcp, static MCP, OAuth
+weight: 80
+---
+
+Docker Sandboxes includes an MCP gateway for connecting agents to Model Context
+Protocol servers. The gateway gives the agent inside the sandbox one MCP
+endpoint, while `sbx` manages the registered servers, OAuth credentials, and
+sandbox lifecycle on the host.
+
+This is different from configuring an MCP server directly in an agent such as
+Claude Code. Direct MCP setup configures that agent's own MCP client. With
+Docker Sandboxes, you register MCP servers once on the host, and the sandbox
+gateway exposes them to supported agents inside isolated sandboxes. That
+host-managed gateway provides a single path for credentials, explicit server
+loading, live updates, and organization governance.
+
+> [!NOTE]
+> The Docker Sandboxes MCP gateway is separate from the Docker Desktop MCP
+> Toolkit. You don't need the Docker Desktop MCP Toolkit to use `sbx mcp`, and
+> MCP Toolkit server settings aren't shared with Docker Sandboxes.
+
+## Prerequisites
+
+- Sign in with `sbx login`.
+- Use an agent integration that configures MCP at startup: Claude Code, Codex,
+  Gemini, Kiro, or OpenCode.
+- For remote servers that require OAuth without Dynamic Client Registration,
+  register an OAuth client with the server provider.
+- For `--local --url` registrations that resolve to OCI packages, use a host
+  with Docker installed and running. Docker is also required for explicit
+  `--command docker ...` registrations.
+
+## Quick start
+
+Start by registering one MCP server on the host:
+
+```console
+$ sbx mcp add notion --url https://mcp.notion.com/mcp
+```
+
+If the server requires OAuth, `sbx` opens an authorization flow before it stores
+the registration. After registration, verify that the server is registered:
+
+```console
+$ sbx mcp ls
+NAME                 TYPE     URL/COMMAND
+notion               remote   https://mcp.notion.com/mcp
+```
+
+Then start a sandbox and expose the registered server:
+
+```console
+$ sbx run claude --name mcp-demo --static-mcp notion
+```
+
+The sandbox starts with an MCP gateway and pre-loads the `notion` server. The
+registration remains on the host and can be reused by other sandboxes.
+
+## Register an MCP server
+
+`sbx mcp add` registers an MCP server by name. The registration records the
+server definition on the host. It doesn't attach the server to a sandbox by
+itself. To expose a registered server to a sandbox, pass it with
+[`--static-mcp`](#use-static-mode) when you create the
+sandbox, or use [`sbx mcp load`](#add-a-server-to-a-running-sandbox) for a
+sandbox that's already running.
+
+Server names can contain letters, numbers, dots, hyphens, and underscores.
+
+The `--url` flag can point to different kinds of input. The execution location
+depends on what you register:
+
+- A remote endpoint URL identifies a running MCP server. The server runs
+  remotely, and the sandbox gateway connects to it.
+- A metadata URL with `--local` returns a registry entry, `server.json`, or
+  `server.yaml` that describes an OCI-packaged stdio server. `sbx` resolves the
+  image and runs it on the host with Docker.
+- An explicit command runs on the host as a stdio MCP server.
+
+Local stdio servers run on the host, not inside the sandbox. The agent inside
+the sandbox connects only to the MCP gateway.
+
+### Remote endpoint URL
+
+For a remote MCP endpoint, pass the server URL:
+
+```console
+$ sbx mcp add notion --url https://mcp.notion.com/mcp
+$ sbx mcp add linear --url https://mcp.linear.app/mcp
+```
+
+### Local stdio server
+
+Some MCP servers communicate over stdio instead of exposing a remote HTTP
+endpoint. Use a local stdio server when `sbx` should launch the MCP server on
+the host. You can provide a metadata URL or an explicit command.
+
+#### From registry or manifest metadata
+
+Use `--local --url` when you have an MCP community registry URL or a URL that
+returns a `server.json` or `server.yaml` document. The registry entry or
+manifest must describe an OCI package that uses stdio transport. `sbx` doesn't
+launch non-OCI package types, such as `npm`, from metadata. To use those
+servers, register an explicit command.
+
+This path resolves the image from the metadata and starts it on the host with
+Docker, so Docker must be installed and running on the host.
+
+```console
+$ sbx mcp add fetch --local \
+  --url https://registry.modelcontextprotocol.io/v0/servers/fetch-mcp/versions/latest
+```
+
+If the entry doesn't publish an OCI stdio package, `sbx` rejects the
+registration instead of starting it locally.
+
+A server manifest describes the MCP server package and how to start it. It can
+be hosted on a GitHub raw URL, internal HTTP server, or CDN.
+
+```console
+$ sbx mcp add opine --local --url https://example.com/mcp/opine/server.yaml
+```
+
+#### From an explicit command
+
+Use `--command` when you already know the executable and arguments, or when you
+need custom Docker flags. The command can be a package runner such as `npx` or
+a Docker container command:
+
+```console
+$ sbx mcp add playwright --command npx --args @playwright/mcp@latest
+$ sbx mcp add local-image-server --command docker \
+  --args "run,-i,--rm,your/image"
+```
+
+To set the working directory for the host process, pass `--dir`. This flag is
+only valid with `--command`:
+
+```console
+$ sbx mcp add local-fs --command node --args server.js --dir /srv/data
+```
+
+Use registry or manifest metadata when you have a published server definition
+and don't need to customize `docker run`. Use `--command` for local
+development, private servers, or custom container flags.
+
+> [!WARNING]
+> Local stdio servers run on the host, outside sandbox isolation. If the command
+> starts a Docker container, that container uses host Docker isolation, not
+> sandbox isolation. The process or container can access host files, host
+> network resources, and credentials made available to it. Use trusted commands
+> and images, and avoid mounting host paths or passing credentials unless the
+> server needs them.
+
+## Authorize OAuth-backed servers
+
+If a registered remote server requires OAuth, `sbx mcp add` starts the
+authorization flow by default:
+
+```console
+$ sbx mcp add notion --url https://mcp.notion.com/mcp
+Resolving MCP server "notion"...
+Open this URL to authorize MCP server "notion":
+https://api.notion.com/v1/oauth/authorize?...
+MCP server "notion" authorized
+MCP server "notion" registered (type: remote)
+```
+
+OAuth credentials stay on the host. In local gateway mode, `sbx` stores tokens
+in the host operating system's credential store.
+
+To register an OAuth-backed server without authorizing it, pass `--skip_auth`:
+
+```console
+$ sbx mcp add notion --url https://mcp.notion.com/mcp --skip_auth
+```
+
+### Use a pre-registered OAuth client
+
+In local gateway mode, you can register a remote OAuth server that doesn't
+support Dynamic Client Registration. If the server publishes OAuth metadata,
+pass the client ID that you registered with the server provider:
+
+```console
+$ sbx mcp add slack --url https://slack.example.com/mcp \
+  --client-id <CLIENT_ID>
+```
+
+If the server doesn't publish OAuth metadata, pass
+`--oauth-authorization-server` with the client ID. The flag accepts a local
+file path or an HTTP or HTTPS URL to an RFC 8414 authorization server metadata
+document. The document must define `authorization_endpoint` and
+`token_endpoint`:
+
+```console
+$ sbx mcp add serverx --url https://mcp.serverx.example/mcp \
+  --oauth-authorization-server ./serverx-authorization-server.json \
+  --client-id <CLIENT_ID>
+```
+
+These flags are only valid with `--url`.
+
+For a confidential OAuth client, store the client secret before registering
+the server. There is no `--client-secret` flag:
+
+```console
+$ sbx secret set mcp:slack.client_secret
+$ sbx mcp add slack --url https://slack.example.com/mcp \
+  --client-id <CLIENT_ID>
+```
+
+The client secret stays in the encrypted host credential store and isn't
+written to the MCP registration. If the server requires a confidential client
+and no secret is stored, registration succeeds but authorization is skipped.
+Store the secret, then run `sbx mcp auth <server>`.
+
+### Set OAuth scopes
+
+Use the repeatable `--scope` flag to record the default scopes requested during
+authorization:
+
+```console
+$ sbx mcp add serverx --url https://mcp.serverx.example/mcp \
+  --scope read --scope write
+```
+
+The `sbx mcp auth` command also accepts `--scope` to override the recorded
+defaults for one authorization. If the authorization server advertises
+supported scopes, every requested scope must be in that set.
+
+For each OAuth-backed remote server exposed to a sandbox, the gateway exposes a
+helper tool named `<server>-authorize`, such as `notion-authorize`. The agent can
+call the tool to authorize or reauthorize the server. If the server isn't
+authorized, the helper is the only tool exposed for that server.
+
+You can manage OAuth credentials from the host:
+
+```console
+$ sbx mcp auth status notion
+$ sbx mcp auth notion
+$ sbx mcp auth rm notion
+```
+
+Use `--all` to apply `auth`, `auth status`, or `auth rm` to all registered
+OAuth-backed servers. Use `--format=json` for machine-readable output.
+
+## Choose an MCP mode
+
+Every sandbox starts an MCP gateway. When the sandbox starts, supported agent
+integrations read the gateway URL and register it with the agent.
+
+Whether you pass `--static-mcp` when you create the sandbox determines its MCP
+mode:
+
+- Static mode pre-loads the specified servers and doesn't expose dynamic
+  discovery tools to the agent.
+- Dynamic mode pre-loads no servers and lets the agent find and attach
+  registered servers.
+
+This choice persists across sandbox restarts.
+
+### Use static mode
+
+Pass `--static-mcp` to pre-load registered MCP servers:
+
+```console
+$ sbx mcp add notion --url https://mcp.notion.com/mcp
+$ sbx mcp add linear --url https://mcp.linear.app/mcp
+$ sbx run claude --name my-session --static-mcp notion,linear
+```
+
+You can pass `--static-mcp` as a comma-separated list or repeat the flag:
+
+```console
+$ sbx run claude --name my-session \
+  --static-mcp notion --static-mcp linear
+```
+
+Every name in the static set must already be registered with `sbx mcp add`. The
+gateway doesn't expose `mcp-find`, `mcp-add`, or `mcp-config-set` to the agent.
+
+You can't replace the initial set by passing `--static-mcp` when reconnecting to
+an existing sandbox. To attach another server from the host, use
+[`sbx mcp load`](#add-a-server-to-a-running-sandbox).
+
+### Use dynamic mode
+
+Omit `--static-mcp` to use dynamic mode. The gateway pre-loads no servers and
+exposes `mcp-find`, `mcp-add`, and `mcp-config-set` to the agent. The agent can
+search the registered server catalog and attach servers during the session.
+
+If you run `sbx mcp add` after a dynamic sandbox starts, its gateway refreshes
+the searchable catalog. The agent can then find and attach the new registration
+without restarting. The `sbx mcp add` command doesn't attach the server by
+itself.
+
+## Add a server to a running sandbox
+
+To attach an already-registered server to a running sandbox, use
+`sbx mcp load`. This works in both static and dynamic modes:
+
+```console
+$ sbx mcp add linear --url https://mcp.linear.app/mcp
+$ sbx mcp load linear --sandbox my-session
+MCP server "linear" loaded into sandbox "my-session" (live)
+```
+
+Connected agent sessions receive a tool-list update, so the added tools become
+visible without reconnecting. The loaded server remains attached across sandbox
+restarts.
+
+## Built-in gateway tools
+
+The local MCP gateway exposes a small set of built-in tools. These tools belong
+to the gateway itself, not to a registered MCP server. Agents can see and call
+them on the same MCP connection as server tools, so they can appear in agent
+tool lists, logs, policy decisions, audit logs, or approval prompts.
+
+You don't need to call these tools directly for normal setup. Use `sbx mcp`
+commands to register servers and manage credentials from the host. The tools
+matter because agents can call them during a session, and admins can govern
+them separately from tools provided by registered MCP servers.
+
+| Tool                 | Description                                                                                |
+| -------------------- | ------------------------------------------------------------------------------------------ |
+| `mcp-exec`           | Executes a tool by name through the gateway.                                               |
+| `code-mode`          | Creates an ephemeral JavaScript tool that can call selected tools through the MCP gateway. |
+| `mcp-find`           | Searches the registered server catalog without changing sandbox state. Dynamic mode only.  |
+| `mcp-add`            | Attaches a registered server to the sandbox. Dynamic mode only.                            |
+| `mcp-config-set`     | Sets per-session configuration overrides for an attached server. Dynamic mode only.        |
+| `<server>-authorize` | Starts or restarts OAuth authorization for an exposed OAuth-backed remote server.          |
+
+Servers attached with `mcp-add` remain attached across sandbox restarts. The
+gateway exposes `<server>-authorize` for OAuth-backed remote servers, even when
+they already have a valid token. Local stdio servers don't expose this helper.
+If `code-mode` creates a generated tool, the tool is shared by clients connected
+to the sandbox's gateway and disappears when the gateway is replaced or stops.
+
+In MCP access policies, built-in gateway tools are `MCP::Primordial` resources
+and use the `invokePrimordial` action. Tools from registered MCP servers are
+`MCP::Tool` resources and use the `invokeTool` action. For details, see the
+[MCP policy reference](governance/reference/mcp-policy.md).
+
+## Manage registrations
+
+List registered servers:
+
+```console
+$ sbx mcp ls
+```
+
+Inspect a registered server:
+
+```console
+$ sbx mcp inspect notion
+```
+
+Remove a registered server:
+
+```console
+$ sbx mcp rm notion
+```
+
+For OAuth-backed servers, `sbx mcp rm` removes the OAuth access token before it
+removes the server registration. A client secret for a pre-registered OAuth
+client and its identity binding remain in the host credential store so you can
+reuse them when you re-add the same client. The command prints the
+`sbx secret rm` commands for removing them. To remove only the OAuth access
+token, use `sbx mcp auth rm`.
+
+## Governance
+
+Organizations with AI Governance can use
+[MCP access policies](governance/access-controls/mcp.md) to control MCP server
+registration, tool calls, gateway meta-tools, resources, prompts, and approval
+requirements. MCP access policies are organization policies written in Cedar.
diff --git a/content/manuals/ai/sandboxes/release-notes.md b/content/manuals/ai/sandboxes/release-notes.md
new file mode 100644
index 000000000000..04d356e2039c
--- /dev/null
+++ b/content/manuals/ai/sandboxes/release-notes.md
@@ -0,0 +1,256 @@
+---
+title: Docker Sandboxes release notes
+linkTitle: Release notes
+description: New features, bug fixes, and changes in Docker Sandboxes
+keywords: docker sandboxes, sbx, release notes, changelog
+weight: 150
+toc_min: 1
+toc_max: 2
+tags:
+  - Release notes
+---
+
+This page lists changes in recent stable releases of Docker Sandboxes. For
+the full release history, including pre-releases and downloads, see the
+[Docker Sandboxes releases on GitHub](https://github.com/docker/sbx-releases/releases).
+
+<!-- BEGIN GENERATED RELEASES -->
+
+## 0.39.0
+
+{{< release-date date="2026-08-19" >}}
+
+[GitHub release](https://github.com/docker/sbx-releases/releases/tag/v0.39.0)
+
+### Highlights
+
+**Declarative sandbox environments.** Define a complete, reproducible sandbox in a `.sbxenv.yaml` file, including the agent, workspace, kits, environment variables, secrets, registry credentials, ports, and resource limits. Commit the file with your project so contributors can launch the same environment with `sbx env run`. This feature is experimental.
+
+### What's New
+
+#### Sandbox environments
+
+- Use `sbx env run` to provision an environment from `.sbxenv.yaml` and open an interactive session.
+- Use `sbx env create`, `sbx env exec`, and `sbx env rm` to manage the environment lifecycle.
+- Combine multiple environment files for shared configuration and local overrides.
+- Reference host environment variables in environment files for machine-specific paths and credentials.
+- See the [sandbox environment files documentation](https://docs.docker.com/ai/sandboxes/sandbox-environments/).
+
+#### CLI
+
+- Add an experimental `--usb` flag to `sbx create` behind the `DOCKER_SANDBOXES_FEATURE_SANDBOX_USB` environment variable to re-attach the specified USB devices. They will be available inside a sandbox via usbfs. Linux x86_64/ARM64 only.
+- sbx run --model now selects the Ollama backend via a new `--provider ollama` flag instead of an `ollama/` prefix on the model name.
+- Stopped sandboxes can now be cleaned up in bulk with `sbx prune`, which never removes a running sandbox and can filter on how long each has been stopped.
+- `sbx run` and `sbx create` now accept `-e`/`--env` and `--env-file` to set environment variables in a sandbox, following `docker run` precedence rules.
+
+#### Secrets
+
+- `sbx secret set` and `sbx secret set-custom` can now configure dynamic secrets that resolve values from a reference or command, with options to control refreshing, verification, and error output.
+- On Linux hosts without an available OS keychain, newly stored secrets are now read and written much faster; secrets already on disk keep their previous cost until they are next written.
+
+#### Daemon
+
+- Sandboxes now expose their own identity as `SANDBOX_NAME` and `SANDBOX_ID` environment variables, matching the name and id shown by `sbx ls --json`; the older `SANDBOX_VM_ID` still carries the sandbox name but is deprecated.
+
+#### Networking
+
+- Claude Code's `/remote-control` can now be used inside sandboxes by enabling `claude.remoteControl` setting: `sbx settings set claude.remoteControl true`.
+
+#### Bug Fixes
+
+- sandboxd now removes the sandbox container immediately when container startup fails, so an interrupted `sbx create`/`sbx run` is less likely to leave the sandbox name unusable.
+- Agent kits that declare a persistent volume without a size now get a 512 MB volume instead of a 50 GB one, which significantly reduces sandbox disk usage on the host.
+- `sbx` now reports a clear error for an unrecognized command, subcommand, or `sbx help` topic instead of printing help and succeeding, and reports a mistyped command without first asking an unauthenticated user to sign in.
+- Claude sandboxes now use around 3.9 GB less disk space on the host.
+- Claude sandboxes can connect to required Anthropic services when using the locked-down network policy.
+- `sbx kit inspect` now describes kits using kit-spec v2 field names and lists any deprecated fields a kit still relies on, and `sbx kit validate` now rejects OAuth credentials missing sentinels, a service, or a credential-file body.
+- DNS lookups in a sandbox now succeed for any host that network policy allows on any port, including hosts allowed only on a non-standard port such as `myhost:2222`.
+- `sbx template load` now fails with an error when an image import does not complete, instead of reporting success.
+- Correct the `sbx create --name` help text and CLI reference, which incorrectly listed plus signs as valid sandbox-name characters and omitted the leading-alphanumeric and two-character-minimum rules.
+- `sbx reset` now removes the Docker Sandboxes-managed block from `~/.ssh/config`.
+- `sbx` now reports the exit code when a sandbox container dies at startup, and rejects a template image built for a different CPU architecture with a clear message instead of failing after a 30-second wait.
+- Signing in to Claude Code with an Anthropic Console API key now succeeds on repeat logins instead of failing with a 401 error.
+- Fixed `sbx cp` failing on Windows when the local path has no directory component (e.g. `sbx cp file.txt sandbox:/tmp/`).
+- `sbx daemon restart` now starts the daemon again after a stop that reports a failure but leaves no daemon running.
+
+#### Other
+
+- `sbx diagnose` now reports free disk space on the volume holding sandbox data, and diagnostics bundles include host disk totals.
+- `sbx diagnose` now detects broken, shadowed, or stale SSH client configuration.
+- Add a `platform.images.registryMirror` setting that redirects Docker Hub-resolving sandbox template and kit images to an organization's registry mirror.
+- Filesystem policy denials now include the organization's support contact message, matching network denials.
+- sbx now reports when the host cannot provide a hypervisor — including a Windows installation running inside a virtual machine without nested virtualization — instead of a generic "failed to run sandbox container" error, and `sbx diagnose` now checks host virtualization support.
+- Kits can now be signed and verified with cosign-compatible Sigstore signatures via `sbx kit sign` / `sbx kit verify`, with optional policy enforcement at load time.
+- OAuth kits can declare their credential file with the declarative `credentialFile.structure` form, rendered to well-formed JSON, instead of a free-form Go template.
+- Ubuntu 25.10 packages are no longer published; Ubuntu 25.10 is end-of-life.
+
+## 0.38.0
+
+{{< release-date date="2026-08-06" >}}
+
+[GitHub release](https://github.com/docker/sbx-releases/releases/tag/v0.38.0)
+
+### Highlights
+
+**Kit spec v2.** A new schema is available for authoring kits, with a clearer structure for setup, permissions, agent instructions, networking, and credentials. Use `schemaVersion: "2"` for new kits; existing v1 kits continue to load through the legacy path. See the [kit spec reference](https://docs.docker.com/ai/sandboxes/customize/kit-reference/#schema-versions) for migration details.
+
+**MCP management is now a first-class feature.** Register remote or local MCP servers once with `sbx mcp`, then reuse them across supported agents and sandboxes through a built-in MCP gateway. OAuth credentials stay on the host, and organizations can govern server registration and tool calls with Cedar policies. See the [MCP gateway documentation](https://docs.docker.com/ai/sandboxes/mcp-gateway/).
+
+### What's new
+
+#### CLI
+
+- `sbx create` and `sbx run` show detailed structured progress during startup, including environment files loaded, resources provisioned, and each kit command's outcome; kit-install progress streams live during `sbx create --kit`.
+- Added `sbx daemon restart` to stop and restart the sandboxd daemon in the background.
+- `sbx inspect` now displays custom secrets configured for a sandbox.
+- `DOCKER_SANDBOXES_CLONED_WORKSPACE_SIZE` configures the size of the cloned workspace volume.
+- `sbx setup ssh` warns when `ssh` is missing from PATH, and on Windows when `sh` (required by Claude Desktop's SSH ProxyCommand) is missing.
+- Port publishing failures now identify the affected host port and explain when the OS requires extra daemon privileges.
+
+#### MCP
+
+- The `sbx mcp` subcommand is now available for managing MCP servers.
+- Includes dynamic MCP tools (`mcp-find`, `mcp-add`, `mcp-config-set`) for attaching registered servers to sandboxes.
+- Govern MCP servers and tools for your organization using Cedar policies.
+
+#### Networking & policy
+
+- `--deny-network HOST` on `sbx run` and `sbx create` records per-sandbox network deny rules at creation time, with layer-aware egress messages.
+- `sbx policy allow network` reports a clear "managed by your organization" error when org governance overrides the local allow, and failed rule removals now explain what went wrong using a single rule identifier.
+- Signing in refreshes organization policies in the running daemon immediately instead of waiting for the next polling interval.
+- IP-literal destinations denied by a CIDR rule fail fast with a policy message instead of timing out.
+- Blocked HTTPS proxy connections appear in `sbx policy log` even when the client aborts the TLS handshake.
+
+#### Secrets & credentials
+
+- Service and custom secrets are global by default, with `--sandbox` for sandbox scope; legacy positional and `--global` forms are deprecated with warnings.
+- Sandbox-scoped GitHub credentials added after creation now work without recreating the sandbox.
+- Pressing Ctrl+C while entering a secret cancels the command without saving it.
+
+#### Agents
+
+- Docker Agent and OpenCode sandboxes can authenticate GitHub Copilot requests with proxy-managed GitHub credentials.
+- Codex sandboxes created from the TUI prefer stored OpenAI OAuth credentials over API keys; kit environment variables now reach cloud agents, and git no longer hangs Codex startup prompting for credentials.
+- Shared agent skills: directory symlinks under the skills folder are resolved and their contents imported.
+
+#### Kits & templates
+
+- Kit specs use the new v2 grammar.
+- Kits using `extends` correctly inherit and override the base image or build source of their parent.
+- Kit install commands can consume static files from `files/home`, including binary files.
+
+#### Packaging
+
+- Homebrew installs from a stapled `.dmg` artifact rather than a `.tar.gz` archive, improving Gatekeeper compatibility on macOS.
+- Windows: the running sandboxd daemon is stopped during a WinGet/MSI upgrade so client and server end up on the same version.
+
+#### Security
+
+- Claude Desktop SSH sessions no longer expose Desktop OAuth access tokens inside sandboxes.
+- Fixed a destination-escape flaw in `sbx cp` copy-out (CVE-2026-17106).
+- The daemon's loopback egress proxy only serves the daemon's own traffic, preventing other local users on a multi-user host from reaching the configured upstream proxy through it.
+
+#### Bug fixes
+
+- Fixed a hang where sandboxd stopped answering all endpoints and could not be stopped without SIGKILL after a crash; fatal daemon tracebacks are now included in `sbx diagnose --upload` bundles.
+- Fixed intermittent sandboxd startup failures when a running daemon was slow to answer its health check.
+- Fixed `sbx daemon stop` hanging when an idle SSH session (for example, Claude Desktop) was connected to a sandbox.
+- sandboxd automatically repairs a corrupted local image cache by re-pulling the image, and otherwise reports a clear "run `sbx daemon reset`" error.
+- Fixed recreate failures ("base image not found") after daemon restarts when swapping a sandbox's container via `sbx kit add`; recreates self-heal by recomposing from the sandbox's template.
+- Fixed reverse DNS (PTR) lookups from sandboxes returning NXDOMAIN for container-resolved addresses.
+- Fixed a goroutine and network-endpoint leak from hijacked HTTP CONNECT tunnels that could eventually stall sandbox creation after many delete/recreate cycles.
+- Fixed an intermittent 500 error when deleting a sandbox while its network endpoints were being torn down.
+- The daemon restores saved sandboxes' network proxies in parallel on restart, speeding up startup with several sandboxes and fixing a potential crash during first-run policy application.
+- Fixed host `.git/config` corruption when creating a sandbox for repositories using `includeIf` directives in `~/.gitconfig`; the sandbox now writes git identity only to the container's gitconfig.
+- `sbx skills` shows a single usage form and clearer help for importing shared agent skills.
+- sbx no longer reports that a stored credential was not injected when the daemon injects it.
+
+### Experimental features
+
+#### Enterprise networking
+
+Settings-driven upstream-proxy configuration with separate sandbox and daemon scopes, integrated NTLM/Kerberos proxy authentication on Windows.
+
+- Configure separate proxy settings for sandbox and daemon traffic using `proxy`, `proxy.sandbox`, `proxy.daemon`, and the matching `no_proxy` settings. These default to the host operating system's proxy settings. The daemon's own traffic, including image pulls and telemetry, also uses the configured proxy.
+- On Windows, sbx can authenticate to upstream proxies that require integrated NTLM or Kerberos/Negotiate authentication. Enable this behavior with the `proxy.integratedAuth` setting.
+- If a TLS-inspecting proxy issues certificates with negative serial numbers, enable compatibility with `sbx settings set tls.allowNegativeSerial true`, then restart the daemon.
+
+#### GPU passthrough
+
+Run a sandbox with NVIDIA VFIO GPU passthrough on Linux using `sbx run --gpu`. Enable this feature with `sbx settings set feature.sandbox-gpu true`.
+
+#### Local models
+
+Run Claude Code against a local GGUF model with `sbx run --model <name> claude`. To use a model from an existing Ollama installation, prefix the model name with `ollama/`. See [Claude Code > Use a local model](https://docs.docker.com/ai/sandboxes/agents/claude-code/#use-a-local-model).
+
+## 0.37.1
+
+{{< release-date date="2026-07-29" >}}
+
+[GitHub release](https://github.com/docker/sbx-releases/releases/tag/v0.37.1)
+
+### Highlights
+
+This patch release stops SSH sessions from **forwarding credential environment variables into sandboxes by default**. Variables such as `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, and `GH_TOKEN` are no longer sent from the client to the sandbox unless explicitly allowed via the `ssh.acceptEnv` setting.
+
+### What's New
+
+#### Bug Fixes
+
+- SSH sessions no longer forward credential environment variables (`ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, `GH_TOKEN`, ...) from the client into the sandbox by default; use the `ssh.acceptEnv` setting to opt back in for specific variables
+
+## 0.37.0
+
+{{< release-date date="2026-07-24" >}}
+
+[GitHub release](https://github.com/docker/sbx-releases/releases/tag/v0.37.0)
+
+### Highlights
+
+**SSH access to sandboxes (experimental).** Docker Sandboxes can now be used as SSH targets. After enabling SSH access, run `sbx setup ssh` once, then connect to an existing sandbox by name with `ssh my-sandbox.sbx`. Use the connection for interactive shells, one-shot commands, and SSH-based remote development.
+
+**Shared agent skills.** Docker Sandboxes can now import skills from supported host agents into a persistent store shared across sandboxes. Run sbx skills import to import them. New sandboxes mount the store read-write by default; use --no-share-skills to opt out.
+
+### What's New
+
+#### SSH
+
+- `sbx setup ssh` adds a managed `*.sbx` entry to your SSH config, making existing sandboxes available at `<name>.sbx`.
+- SSH connections start the local Docker Sandboxes daemon and the target sandbox automatically when needed.
+- Connect using OpenSSH-compatible clients and remote-development tools such as VS Code, Cursor, Claude Desktop, and ChatGPT.
+
+#### Shared skills
+
+- `sbx skills import` discovers and imports skills from the host and makes them available to sandboxed agents. Use `--dry-run` to preview imports and `--force` to replace existing skills.
+- Imported skills persist after sandbox deletion and are mounted into new sandboxes for supported agents.
+- Pass `--no-share-skills` to `sbx run` or `sbx create` when creating a sandbox to opt out.
+
+#### CLI
+
+- `sbx create` and `sbx run` accept `-p/--publish` to publish sandbox ports at creation time.
+
+#### Networking & Policy
+
+- `DOCKER_SANDBOXES_PROXY=system` routes sandbox egress through the host operating system's proxy configuration (macOS/Windows), including any PAC auto-config URL.
+- Governance-policy denials can now display an organization-configured support message (for example, who to contact).
+
+#### Security & Audit
+
+- Audit now emits execution-outcome records for network egress (per allowed connection) and filesystem mounts (per allowed path) — success, latency, and error class — alongside the policy-attributed decision records.
+- sandboxd excludes itself from Windows Error Reporting so daemon crash dumps cannot capture in-memory credentials.
+
+#### Performance
+
+- `sbx secret ls` and sandbox startup are faster on Linux hosts without an OS keychain — stored secrets are no longer all decrypted just to list or resolve credentials.
+
+### Bug Fixes
+
+- Fixed sandboxd failing to start on Linux hosts without an OS keychain, where the on-disk secret store's key derivation could peg a CPU during startup and the CLI would kill the still-starting daemon.
+- Fixed an intermittent "failed to fully delete sandbox" error when removing a running sandbox, caused by a network-teardown race with the engine's endpoint cleanup.
+
+<!-- END GENERATED RELEASES -->
+
+## Earlier releases
+
+For older versions, see the
+[Docker Sandboxes releases on GitHub](https://github.com/docker/sbx-releases/releases).
diff --git a/content/manuals/ai/sandboxes/security/_index.md b/content/manuals/ai/sandboxes/security/_index.md
new file mode 100644
index 000000000000..5af246133cf2
--- /dev/null
+++ b/content/manuals/ai/sandboxes/security/_index.md
@@ -0,0 +1,143 @@
+---
+title: Security model
+linkTitle: Security model
+weight: 110
+description: Trust boundaries, isolation layers, and security properties of Docker Sandboxes.
+keywords: docker sandboxes, security model, isolation, trust boundaries, microVM
+---
+
+Docker Sandboxes run AI agents in microVMs so they can execute code, install
+packages, and use tools without accessing your host system. Multiple isolation
+layers protect your host system.
+
+## Trust boundaries
+
+The primary trust boundary is the microVM. The agent has full control inside
+the VM, including sudo access. The VM boundary prevents the agent from reaching
+anything on your host except what is explicitly shared.
+
+What crosses the boundary into the VM:
+
+- **Workspace directory:** mounted into the VM. The default direct mount is
+  read-write — the agent edits your working tree in place. With
+  [`--clone`](../usage.md#clone-mode), your repository is mounted read-only
+  and the agent works on a private clone.
+- **Credentials:** the host-side proxy injects authentication headers into
+  outbound HTTP requests. The raw credential values never enter the VM.
+- **Network access:** outbound TCP connections to destinations allowed by
+  [network policy](defaults/) are proxied through the host.
+- **Shared agent skills:** a persistent host-side store is mounted read-write
+  at the agent's skills directory unless you opt out when creating the
+  sandbox. Supported agents in other sandboxes mount the same store.
+- **MCP gateway traffic:** supported agents connect to a host-side MCP gateway
+  endpoint. The gateway brokers access to registered MCP servers.
+
+What crosses the boundary back to the host:
+
+- **Workspace file changes:** visible on your host in real time with the
+  default direct mount.
+- **Outbound TCP connections:** sent to allowed destinations through the host
+  proxy.
+- **Shared skill changes:** written to the host-side store and visible to other
+  sandboxes that share it.
+
+Outside the workspace and shared skills store, the agent cannot access your
+host filesystem. It also cannot access your host Docker daemon, your host
+network directly, or any destination not allowed by network policy. Sandboxes
+cannot communicate directly over the network. Direct external UDP and ICMP are
+blocked at the network layer.
+
+MCP servers are an explicit integration point. Remote MCP servers run outside
+Docker Sandboxes, and local stdio MCP servers run on the host, not inside the
+sandbox VM. An agent can invoke the tools those servers expose through the MCP
+gateway, subject to MCP policies when organization governance is active. Treat
+local MCP servers as trusted host integrations.
+
+![Sandbox security model showing the hypervisor boundary between the sandbox VM and the host system. The workspace directory is shared read-write. The agent process, Docker Engine, packages, and VM filesystem are inside the VM. Host filesystem, processes, Docker Engine, and network are outside the VM and not accessible. A proxy enforces allow/deny policies and injects credentials into outbound requests.](../images/sbx-security.png)
+
+## Isolation layers
+
+The sandbox security model has five layers. See
+[Isolation layers](isolation/) for technical details on each.
+
+- **Hypervisor isolation:** separate kernel per sandbox. No shared memory or
+  processes with the host.
+- **Network isolation:** outbound TCP traffic is proxied through the host and
+  governed by a [deny-by-default policy](defaults/). Direct external UDP and
+  ICMP are blocked.
+- **Docker Engine isolation:** each sandbox has its own Docker Engine with no
+  path to the host daemon.
+- **Workspace isolation** (opt-in via `--clone`): the agent works on a
+  private in-VM clone and your repository is mounted read-only. The default
+  direct mode applies no workspace boundary — the agent edits your working
+  tree in place.
+- **Credential isolation:** API keys are injected into HTTP headers by the
+  host-side proxy. Credential values never enter the VM.
+
+## What the agent can do inside the sandbox
+
+Inside the VM, the agent has full privileges: sudo access, package installation,
+a private Docker Engine, and read-write access to the workspace. Installed
+packages, Docker images, and other VM state persist across restarts. See
+[Default security posture](defaults/) for the full breakdown of what is
+permitted and what is blocked.
+
+## What is not isolated by default
+
+The sandbox isolates the agent from your host system, but the agent's actions
+can still affect you through the shared workspace and allowed network channels.
+
+In direct mode, workspace changes are live on your host. With the default
+direct mount, the agent edits the same files you see on your host. This
+includes files that execute implicitly during normal development: Git hooks,
+CI configuration, IDE task configs, AI project configuration and settings,
+`Makefile`, `package.json` scripts, and similar build files. Review changes
+before running any modified code. Note that Git hooks live inside `.git/`
+and do not appear in `git diff` output — check them separately. See
+[Workspace isolation](isolation/#workspace-isolation) for the full list and
+for the alternative clone-mode boundary.
+
+The default allowed domains include broad wildcards. Some defaults like
+`*.googleapis.com` cover many services beyond AI APIs. Run `sbx policy ls` to
+see the full list of active rules, and remove entries you don't need. See
+[Default security posture](defaults/).
+
+Kits run install commands with root privileges inside the sandbox. To limit
+supply-chain risk, `sbx` restricts kit installs to an allowlist of sources
+that defaults to Docker Hub only. See
+[Restrict kit sources](../customize/kits.md#restrict-kit-sources).
+
+Shared agent skills create a narrow exception to cross-sandbox isolation. The
+store is mounted read-write, so one sandbox can modify instructions or scripts
+that an agent later uses in another sandbox. This doesn't expose the rest of
+the host filesystem or create a direct network path between sandboxes, but it
+does put participating sandboxes in the same trust boundary. See
+[Share agent skills](../workflows/agent-skills.md) for details and the
+per-sandbox opt-out.
+
+Local stdio MCP servers run outside the sandbox VM. If you register a local MCP
+server that starts a host process or host Docker container, that process or
+container uses host permissions and host isolation, not sandbox isolation. See
+[MCP gateway](../mcp-gateway.md).
+
+## Organization-wide control
+
+On a single developer's machine, security and policy are configured locally —
+for example, network and filesystem rules set with `sbx policy`. Admins can
+move these controls to the organization level so that security, policy, and
+access apply consistently across every developer's sandboxes, rather than
+depending on local configuration.
+
+See [Governance](../governance/) for the controls available to organization
+admins.
+
+## Learn more
+
+- [Isolation layers](isolation/): how hypervisor, network, Docker,
+  workspace, and credential isolation work
+- [Default security posture](defaults/): what a fresh sandbox permits and
+  blocks
+- [Manage credentials](../configuration/credentials.md): provide and manage API
+  keys while keeping their values outside the sandbox
+- [Governance](../governance/): configure network, filesystem, and MCP access
+  controls locally or across your organization
diff --git a/content/manuals/ai/sandboxes/security/defaults.md b/content/manuals/ai/sandboxes/security/defaults.md
new file mode 100644
index 000000000000..95cd06402174
--- /dev/null
+++ b/content/manuals/ai/sandboxes/security/defaults.md
@@ -0,0 +1,78 @@
+---
+title: Default security posture
+linkTitle: Defaults
+weight: 20
+description: What a sandbox permits and blocks before you change any settings.
+keywords: docker sandboxes, security defaults, network policy, credentials, shared skills, sbx
+---
+
+A sandbox created with `sbx run` and no additional flags has the following
+security posture.
+
+## Network defaults
+
+All outbound TCP traffic, including HTTP, HTTPS, and SSH, is blocked unless an
+explicit rule allows the destination. Direct external UDP and ICMP traffic is
+blocked at the network layer. DNS queries use the sandbox's internal resolver,
+which enforces network policy.
+
+Run `sbx policy ls` to see the active network rules for your installation.
+Rules can be customized per machine with the `sbx policy` CLI, or managed
+centrally across your organization. Org-level rules take precedence over local
+rules. See
+[Network access policies](../governance/access-controls/network.md).
+
+## Workspace defaults
+
+Sandboxes use a direct mount by default. The agent sees and modifies your
+working tree directly, and changes appear on your host immediately.
+
+The agent can read, write, and delete any file within the workspace directory,
+including hidden files, configuration files, build scripts, and Git hooks.
+See [Workspace isolation](isolation.md#workspace-isolation) for what to
+review after an agent session.
+
+## Shared skills defaults
+
+Sandboxes for supported agents mount a persistent shared skills store
+read-write by default. Every sandbox that uses the store can change skills that
+other participating sandboxes may load. Use `--no-share-skills` when creating a
+sandbox to keep it outside this shared trust boundary. See
+[Share agent skills](../workflows/agent-skills.md).
+
+## Credential defaults
+
+No credentials are available to the sandbox unless you provide them using
+`sbx secret` or environment variables. When credentials are provided, the
+host-side proxy injects them into outbound HTTP headers. The agent cannot
+read the raw credential values.
+
+See [Credentials](../configuration/credentials.md) for setup instructions.
+
+## Agent capabilities inside the sandbox
+
+The agent runs with full control inside the sandbox VM:
+
+- `sudo` access (the agent runs as a non-root user with sudo privileges)
+- A private Docker Engine for building images and running containers
+- Package installation through `apt`, `pip`, `npm`, and other package managers
+- Full read and write access to the VM filesystem
+
+Everything the agent installs or creates inside the VM, including packages,
+Docker images, and configuration changes, persists across stop and restart
+cycles. When you remove the sandbox with `sbx rm`, the VM and its contents
+are deleted. Workspace files and the shared skills store remain on the host.
+
+## What is blocked by default
+
+The following are blocked for all sandboxes and cannot be changed through
+policy configuration:
+
+- Host filesystem access outside explicitly mounted workspaces and the shared
+  skills store
+- Host Docker daemon
+- Direct network communication between sandboxes
+- Direct external UDP and ICMP connections
+
+Outbound TCP to destinations not in the allow list is also blocked by default,
+but you can add allow rules with `sbx policy allow`.
diff --git a/content/manuals/ai/sandboxes/security/isolation.md b/content/manuals/ai/sandboxes/security/isolation.md
new file mode 100644
index 000000000000..8515413c6b2f
--- /dev/null
+++ b/content/manuals/ai/sandboxes/security/isolation.md
@@ -0,0 +1,236 @@
+---
+title: Isolation layers
+weight: 10
+description: How Docker Sandboxes isolate AI agents using hypervisor, network, Docker Engine, workspace, and credential boundaries.
+keywords: docker sandboxes, isolation, hypervisor, network, credentials, workspace, git
+aliases:
+  - /ai/sandboxes/security/workspace/
+---
+
+AI coding agents need to execute code, install packages, and run tools on
+your behalf. Docker Sandboxes run each agent in its own microVM. Five
+isolation layers protect your host: hypervisor, network, Docker Engine,
+workspace, and credential proxy.
+
+## Hypervisor isolation
+
+Every sandbox runs inside a lightweight microVM with its own Linux kernel.
+Unlike containers, which share the host kernel, a sandbox VM cannot access host
+processes, files, or resources outside its defined boundaries.
+
+- **Process isolation:** separate kernel per sandbox; processes inside the VM
+  are invisible to your host and to other sandboxes
+- **Filesystem isolation:** your workspace directory and, for supported agents
+  that haven't opted out, the dedicated [shared skills
+  store](../workflows/agent-skills.md) are shared with the host. The rest
+  of the VM filesystem persists across restarts but is removed when you delete
+  the sandbox. Symlinks pointing outside the workspace scope are not followed.
+- **Full cleanup:** when you remove a sandbox with `sbx rm`, the VM and
+  everything inside it is deleted
+
+The agent runs as a non-root user with sudo privileges inside the VM. The
+hypervisor boundary is the isolation control, not in-VM privilege separation.
+
+## Network isolation
+
+Each sandbox has its own isolated network. Sandboxes cannot communicate
+directly with each other or share a network with your host. To reach a service
+running on the host through a policy-controlled connection, see
+[Accessing host services from a sandbox](../workflows/development.md#accessing-host-services-from-a-sandbox).
+
+All outbound TCP traffic passes through a proxy on your host that enforces the
+[network access policy](../governance/access-controls/network.md). The sandbox
+routes traffic through either a forward proxy or a transparent proxy depending
+on the client's configuration. Both enforce the network policy. Only the
+forward proxy [injects credentials](../configuration/credentials.md) for AI services.
+
+Direct external UDP and ICMP are blocked at the network layer. DNS queries use
+the sandbox's internal resolver, which enforces network policy. TCP connections
+are allowed only when a policy rule matches the destination.
+
+For the default set of allowed domains, see
+[Default security posture](defaults.md). To forward allowed traffic through a
+corporate or upstream proxy, see
+[Configure an upstream proxy](../configuration/upstream-proxy.md).
+
+## Docker Engine isolation
+
+Agents often need to build images, run containers, and use Docker Compose.
+Mounting your host Docker socket into a container would give the agent full
+access to your environment.
+
+Docker Sandboxes avoid this by running a separate [Docker
+Engine](/manuals/engine/_index.md) inside the sandbox environment, isolated from
+your host. When the agent runs `docker build` or `docker compose up`, those
+commands execute against that engine. The agent has no path to your host Docker
+daemon.
+
+This Docker Engine boundary applies to processes running inside the sandbox VM.
+It doesn't apply to local stdio MCP servers registered through the
+[MCP gateway](../mcp-gateway.md). Those servers run on the host, outside the
+sandbox VM. If a local MCP server starts a Docker container, it uses Docker on
+the host.
+
+Each sandbox VM runs its own Docker Engine. The agent runs inside the VM,
+alongside that engine, and drives it to create containers, all within the
+VM:
+
+```mermaid
+flowchart TB
+  subgraph host["Host system"]
+    subgraph hostd["Host Docker daemon"]
+      hc["Your containers and images"]
+    end
+    subgraph vm["Sandbox (microVM)"]
+      a["Agent"]
+      subgraph e["Sandbox Docker engine"]
+        c["Containers created by agent"]
+      end
+      a -->|"docker build / compose up"| e
+    end
+  end
+  style host fill:#3b82f622,stroke:#3b82f6
+```
+
+## Workspace isolation
+
+When you create a sandbox, you choose one of two ways to share your
+workspace with it:
+
+- **Direct mount** (the default): the agent has read-write access to
+  your working tree. There is no boundary between the agent's edits and
+  your host filesystem.
+- **Clone mode** (`--clone`): your repository is mounted read-only into
+  the VM and the agent works on a private clone inside the VM. The
+  agent's edits never reach your host until you fetch them.
+
+See [Git workflows](../workflows/git.md) for the workflow side of
+each.
+
+### Direct mount (default)
+
+By default, your workspace is shared into the VM as a read-write mount.
+The agent and the host see the same files, and changes the agent makes
+appear on your host as soon as they're written.
+
+There is no isolation between the agent and your workspace in this mode.
+The agent can create, modify, or delete any file in the workspace,
+including:
+
+- Source code and configuration files
+- Build files (`Makefile`, `package.json`, `Cargo.toml`)
+- Git hooks (`.git/hooks/`)
+- CI configuration (`.github/workflows/`, `.gitlab-ci.yml`)
+- IDE configuration (`.vscode/tasks.json`, `.idea/` run configurations)
+- AI project configuration and settings (`.claude/`, `.codex/`, `.gemini/`)
+- Sandbox environment files (`.sbxenv.yaml`)
+- Hidden files, shell scripts, and executables
+
+Some of these files execute code when you trigger normal development
+actions — committing, pushing, building, or opening the project in an IDE.
+Review them after any agent session before performing those actions:
+
+- Git hooks (`.git/hooks/`) run on commit, push, and other Git actions.
+  These are inside `.git/` and don't appear in `git diff` output —
+  check them separately with `ls -la .git/hooks/`.
+- CI configuration (`.github/workflows/`, `.gitlab-ci.yml`) runs on
+  push.
+- Build files (`Makefile`, `package.json` scripts, `Cargo.toml`) run
+  during build or install steps.
+- IDE configuration (`.vscode/tasks.json`, `.idea/`) can run tasks
+  when you open the project.
+- AI project configuration and settings (`.claude/settings.json`, `.codex/config.toml`,
+  `.gemini/settings.json`) can define hooks and startup commands that
+  execute automatically.
+- Sandbox environment files (`.sbxenv.yaml`) can declare `secrets` and
+  `registries` whose values come from a `command`. Those commands run on
+  the host, as you, the next time you run `sbx env create` or
+  `sbx env run` in that directory — before the sandbox exists. Because the
+  file sits in the workspace, an agent in direct mount can add or change
+  one.
+
+> [!WARNING]
+> Treat sandbox-modified workspace files the same way you would treat a pull
+> request from an untrusted contributor: review before you trust them on
+> your host.
+
+### Clone mode
+
+When you start a sandbox with [`--clone`](../usage.md#clone-mode), the agent
+never works directly against your host repository. Even with full root
+inside the VM, it cannot modify your `.git` directory, your working tree,
+or any tracked file on your host.
+
+> [!IMPORTANT]
+> Clone mode protects your host repository from modification, **not from
+> inspection**. Your repository is still mounted read-only into the sandbox,
+> including untracked files and files excluded by `.gitignore`. Files such as
+> `.env` remain readable by the agent. Store secrets outside your working
+> directory or use [credential isolation](#credential-isolation) instead.
+
+```mermaid
+flowchart LR
+  subgraph host["Host repository (untouched)"]
+    direction TB
+    repo[".git/ + working tree"]
+    remote["remote sandbox-&lt;name&gt;"]
+  end
+  subgraph vm["Sandbox VM"]
+    direction TB
+    mount["/run/sandbox/source<br/>(read-only bind mount)"]
+    clone["private clone (RW)<br/>agent edits here"]
+    daemon["git-daemon"]
+  end
+  repo -->|"read-only bind mount"| mount
+  mount -->|"git clone"| clone
+  clone --> daemon
+  daemon -->|"git fetch"| remote
+```
+
+How the boundary is enforced:
+
+- Your repository's Git root is mounted at `/run/sandbox/source` as
+  read-only. The mount covers your entire working directory, including
+  untracked files and files excluded by `.gitignore`. Nothing the agent
+  does inside the VM can write back through that mount, but all files
+  under the Git root are readable inside the sandbox. This includes
+  credential files not tracked by Git, such as `.env`.
+- The agent works on a private clone that lives inside the sandbox. The
+  clone has its own index, its own refs, and its own working tree. Writes
+  to the clone never reach your host.
+- The sandbox publishes the clone over a Git daemon bound to localhost on
+  the host. The CLI wires it up as a `sandbox-<sandbox-name>` Git remote on
+  your host repository. Fetching from that remote uses the same trust
+  model as fetching from any third-party remote — nothing is integrated
+  until you explicitly merge or check out the fetched refs.
+
+The practical guarantees:
+
+- The agent cannot modify any tracked file or any byte under `.git/` on
+  your host. A compromised or buggy agent cannot drop a
+  `.git/hooks/pre-commit`, alter `.github/workflows/`, or sneak changes
+  into your working tree.
+- Concurrent `git` commands on the host and inside the sandbox cannot
+  race on a shared `.git/index` or shared refs — there is no shared
+  writable Git state.
+- Credentials, signing keys, and any settings in your repository's
+  `.git/config` stay on the host. The agent's clone has its own
+  independent configuration.
+
+Use clone mode whenever you want a strong boundary between the agent's
+Git activity and your host repository — for example when running an
+unfamiliar agent, running multiple agents on the same repository at once,
+or keeping your working tree clean while the agent works.
+
+## Credential isolation
+
+Most agents need API keys for their model provider. Rather than passing keys
+into the sandbox, the host-side proxy intercepts outbound API requests and
+injects authentication headers before forwarding each request.
+
+Credential values are never stored inside the VM. They are not available as
+environment variables or files inside the sandbox unless you explicitly set
+them. This means a compromised sandbox cannot read API keys from the local
+environment.
+
+For how to store and manage credentials, see [Credentials](../configuration/credentials.md).
diff --git a/content/manuals/ai/sandboxes/troubleshooting.md b/content/manuals/ai/sandboxes/troubleshooting.md
new file mode 100644
index 000000000000..fc518e40ebfe
--- /dev/null
+++ b/content/manuals/ai/sandboxes/troubleshooting.md
@@ -0,0 +1,395 @@
+---
+title: Troubleshooting
+weight: 130
+description: Resolve common issues when using Docker Sandboxes.
+keywords: docker sandboxes, sbx, troubleshooting, diagnostics, reset, network policy, git, ssh
+---
+
+## Run diagnostics
+
+Before digging into a specific issue, run
+[`sbx diagnose`](/reference/cli/sbx/diagnose/) to check for common problems
+with your installation, such as a missing CLI binary, daemon reachability
+problems, a CLI/daemon version mismatch, missing storage directories, or
+broken authentication.
+
+```console
+$ sbx diagnose
+```
+
+The command prints a summary of checks that passed, warned, or failed, along
+with suggested fixes. Use `--output json` to get machine-readable output, or
+`--output github-issue` to generate a Markdown snippet suitable for pasting
+into a GitHub issue.
+
+## Restart the sandbox daemon
+
+If sandbox commands hang, fail to connect to the daemon, or keep returning
+daemon errors, restart the sandbox daemon before resetting sandbox state:
+
+```console
+$ sbx daemon restart
+```
+
+Then retry the command that failed. Restarting the daemon doesn't delete
+sandbox data. If the issue persists or state is corrupted, use
+[`sbx reset`](/reference/cli/sbx/reset/).
+
+## Resetting sandboxes
+
+If you hit persistent issues or corrupted state, run
+[`sbx reset`](/reference/cli/sbx/reset/) to stop all VMs and delete all sandbox
+data. Create fresh sandboxes afterwards.
+
+## Agent can't install packages or reach an API
+
+Sandboxes use [network access rules](governance/access-controls/network.md) to
+control outbound traffic.
+If the agent fails to install packages or call an external API, the target
+domain is likely not in the allow list. Check which requests are being blocked:
+
+```console
+$ sbx policy log
+```
+
+Then allow the domains your workflow needs:
+
+```console
+$ sbx policy allow network "*.npmjs.org,*.pypi.org,files.pythonhosted.org"
+```
+
+To allow all outbound traffic instead:
+
+```console
+$ sbx policy allow network "**"
+```
+
+If `sbx policy allow` doesn't unblock the request, your organization may
+manage sandbox policies centrally and take precedence over local rules. See
+[Organization policies](governance/access-controls/organization.md).
+
+## Kit fails to install: source not in allowlist
+
+If loading a kit fails with a message like its source is not in your
+allowlist:
+
+```console
+$ sbx run claude --kit "git+https://github.com/docker/sbx-kits-contrib.git#dir=vale"
+ERROR: resolve kits: kit "git+https://github.com/docker/sbx-kits-contrib.git#dir=vale" cannot be installed — its source is not in your allowlist.
+```
+
+`sbx` restricts kit installs to an allowlist of sources, which defaults to
+Docker Hub (`docker.io/`) only. Add the kit's publisher to the
+`kit.allowedSources` setting, keeping the entries you want to retain:
+
+```console
+$ sbx settings set kit.allowedSources '["docker.io/","github.com/docker/"]'
+```
+
+Then run the command again. For details, including how to allow local kits or
+any remote source, see [Restrict kit sources](customize/kits.md#restrict-kit-sources).
+
+## SSH and other non-HTTP connections fail
+
+Non-HTTP TCP connections such as SSH can be allowed by adding a policy rule for
+the destination. Hostname rules work for these connections because the sandbox
+recovers the hostname from its DNS resolver when the protocol doesn't include
+one:
+
+```console
+$ sbx policy allow network "myhost:22"
+```
+
+If the destination is reached by IP address without a DNS lookup, the hostname
+can't be recovered. Use an address-based rule in that case:
+
+```console
+$ sbx policy allow network "10.1.2.3:22"
+```
+
+UDP and ICMP traffic is blocked at the network layer and can't be unblocked
+with policy rules.
+
+For Git operations over SSH, you can either add an allow rule for the Git
+server's hostname or IP address, or use HTTPS URLs instead:
+
+```console
+$ git clone https://github.com/owner/repo.git
+```
+
+## Can't reach a service running on the host
+
+If a request to `127.0.0.1` or a local network IP returns "connection refused"
+from inside a sandbox, the address is not reachable from within the sandbox VM.
+See [Accessing host services from a sandbox](workflows/development.md#accessing-host-services-from-a-sandbox).
+
+## Docker authentication failure
+
+If you see a message like `You are not authenticated to Docker`, your login
+session has expired. In an interactive terminal, the CLI prompts you to sign in
+again. In non-interactive environments such as scripts or CI, run `sbx login`
+to re-authenticate.
+
+## Agent authentication failure
+
+If the agent can't reach its model provider or you see API key errors, the key
+is likely invalid, expired, or not configured. Verify it's set in your shell
+configuration file and that you sourced it or opened a new terminal.
+
+For agents that use the [credential proxy](configuration/credentials.md), make sure
+you haven't set the API key to an invalid value inside the sandbox — the proxy
+injects credentials automatically on outbound requests.
+
+If credentials are configured correctly but API calls still fail, check
+`sbx policy log` and look at the **PROXY** column. Requests routed through
+the `transparent` proxy don't get credential injection. This can happen when a
+client inside the sandbox (such as a process in a Docker container) isn't
+configured to use the forward proxy. See
+[Monitoring network activity](governance/monitor-and-enforce/monitoring.md)
+for details.
+
+## API calls fail with a certificate error
+
+If your organization uses a proxy that inspects HTTPS traffic, agent requests
+can fail with a certificate error such as
+`SSL certificate problem: self-signed certificate in certificate chain`. Install
+your organization's internal root CA inside the sandbox so the agent and its
+SDKs trust certificates signed by the proxy. Certificate errors can stop a
+request before the credential proxy can inject credentials.
+
+For repeatable setup, create a [sandbox kit](customize/kits.md) that installs
+the CA when the sandbox is created. See
+[Install an internal CA certificate](customize/kit-examples.md#install-an-internal-ca-certificate)
+for an example kit.
+
+Use a PEM-encoded certificate with a `.crt` extension. If traffic can be signed
+by more than one internal proxy, install each proxy's root CA before running
+`update-ca-certificates`.
+
+Create a sandbox with the kit:
+
+```console
+$ sbx run claude --kit ./internal-ca/
+```
+
+To update an existing sandbox, copy the certificate into the sandbox and update
+the trust store:
+
+```console
+$ sbx cp ./internal-ca.crt <sandbox-name>:/tmp/internal-ca.crt
+$ sbx exec <sandbox-name> -- sudo install -m 0644 /tmp/internal-ca.crt /usr/local/share/ca-certificates/internal-ca.crt
+$ sbx exec <sandbox-name> -- sudo update-ca-certificates
+```
+
+> [!IMPORTANT]
+> Install the CA into the system trust store with `update-ca-certificates`, as
+> shown above. Don't override the sandbox's TLS trust variables (such as
+> `SSL_CERT_FILE`) to point at only your internal CA. Doing so replaces the
+> system bundle
+> and breaks the trust the credential proxy depends on, so requests on the
+> `forward` egress path fail.
+
+If API calls still fail after installing the CA, run `sbx policy log` and check
+the egress path in the **PROXY** column:
+
+- `forward`: the credential proxy terminates TLS and presents its own
+  certificate, which the sandbox already trusts. Requests on this path don't
+  need the internal CA, and overriding the sandbox's trust variables breaks
+  them, as described above.
+- `forward-bypass` and `transparent`: the proxy forwards packets to the
+  upstream proxy without terminating TLS, so the sandbox sees your
+  organization's certificate directly. These paths are where installing the
+  internal CA applies. The only difference between them is whether the client
+  knows it's talking to a proxy.
+
+## Sandbox runs out of disk space
+
+The sandbox root (`/`) filesystem defaults to 20 GB. To increase it, set `DOCKER_SANDBOXES_ROOT_SIZE`
+before creating the sandbox:
+
+```console
+$ DOCKER_SANDBOXES_ROOT_SIZE=40g sbx run claude
+```
+
+`DOCKER_SANDBOXES_ROOT_SIZE` controls the root filesystem size. `DOCKER_SANDBOXES_DOCKER_SIZE`
+controls the Docker data disk (`/var/lib/docker`) size. The two are independent — set both if needed.
+
+For a [clone-mode sandbox](usage.md#clone-mode), set
+`DOCKER_SANDBOXES_CLONED_WORKSPACE_SIZE` before creating the sandbox to
+configure the cloned workspace volume capacity. The variable accepts
+human-readable size strings such as `100g`:
+
+```console
+$ DOCKER_SANDBOXES_CLONED_WORKSPACE_SIZE=100g sbx run --clone claude
+```
+
+## Filesystem operations are slow in large repositories
+
+Filesystem operations such as `git status`, `git log`, or directory scans can
+be noticeably slow when the sandbox workspace is mounted in direct mode (the
+default for workspaces without `--clone`). Virtiofs caching speeds up these
+workloads. Clone-mode sandboxes always enable it, so this tuning applies only
+to direct mode.
+
+Virtiofs caching is enabled by default on all operating systems. If you
+experience Git index corruption or unexpected file content, disable caching
+with the kill switch and recreate the sandbox:
+
+```console
+$ DOCKER_SANDBOXES_ENABLE_VIRTIOFS_CACHE=0 sbx run <template>
+```
+
+## Clone mode reports "not in a Git repository" on WSL
+
+On Windows, running [`sbx run --clone`](usage.md#clone-mode) against a
+repository on a WSL filesystem (a `\\wsl.localhost\...` path) can fail even
+though the directory is a valid Git repository:
+
+```console
+> sbx run --clone claude \\wsl.localhost\Ubuntu\home\you\repo
+ERROR: --clone requires a Git repository, but \\wsl.localhost\Ubuntu\home\you\repo is not in a Git repository
+```
+
+The cause is Git's dubious ownership check. When Git on Windows accesses a
+repository owned by a different user across the WSL boundary, it refuses to
+operate on it, so the underlying repository detection fails:
+
+```console
+> git -C \\wsl.localhost\Ubuntu\home\you\repo rev-parse --show-toplevel
+fatal: detected dubious ownership in repository at '//wsl.localhost/Ubuntu/home/you/repo'
+```
+
+Add the repository to Git's `safe.directory` list to allow access, then run
+the command again:
+
+```console
+> git config --global --add safe.directory '%(prefix)///wsl.localhost/Ubuntu/home/you/repo'
+> sbx run --clone claude \\wsl.localhost\Ubuntu\home\you\repo
+✓ Git repository detected: \\wsl.localhost\Ubuntu\home\you\repo
+```
+
+## Sandbox commits aren't signed
+
+Docker Sandboxes can sign Git commits with SSH keys from your host agent.
+For setup steps, see [Commit signing](workflows/git.md#commit-signing).
+
+If `ssh-add -L` prints `The agent has no identities.`, the sandbox can reach
+the forwarded agent, but the host agent doesn't have a loaded key. Load the
+signing key into your host SSH agent:
+
+```console
+$ ssh-add ~/.ssh/id_ed25519
+```
+
+If commit signing works on the host but fails in a sandbox, check whether Git
+is configured to sign with a host file path such as
+`/Users/me/.ssh/id_ed25519.pub`. The sandbox uses the forwarded SSH agent, not
+the host key file path. Use the inline public key form instead:
+
+```console
+$ git config --global gpg.format ssh
+$ git config --global user.signingkey "key::$(ssh-add -L | head -n 1)"
+```
+
+If Git reports that `ssh-keygen` is missing, use a sandbox template that
+includes OpenSSH client tools.
+
+If `git log --show-signature` reports that `gpg.ssh.allowedSignersFile` needs
+to be configured, Git can't verify the SSH signature locally. This verification
+config isn't required to create signed commits. GitHub uses the SSH signing
+keys configured in your GitHub account to verify commits.
+
+GPG and S/MIME signing keys aren't available inside the sandbox. If your
+repository or organization requires GPG or S/MIME signatures, or if SSH signing
+isn't configured, use one of these workarounds:
+
+- Commit outside the sandbox. Let the agent make changes without committing,
+  then commit and sign from your host terminal.
+
+- Sign after the fact. Let the agent commit inside the sandbox, then re-sign
+  the commits on your host:
+
+  ```console
+  $ git rebase --exec 'git commit --amend --no-edit -S' origin/main
+  ```
+
+  This replays each commit on the branch and re-signs it with your local
+  signing key.
+
+## Daemon fails to start after downgrading
+
+If you downgrade `sbx` to a version older than the one that last managed your
+local state, the daemon may fail to start with a database version mismatch:
+
+```text
+ERROR: failed to start backend in-process: start backend: creating containerd
+server: ... database is at major version 6, but this binary only supports up
+to major version 1
+```
+
+A newer version of `sbx` upgraded the local database to a schema that older
+binaries don't understand. To recover, reset all sandbox state:
+
+```console
+$ sbx reset --preserve-secrets
+```
+
+This stops all VMs and deletes all sandbox data. You'll need to create new
+sandboxes afterwards. The `--preserve-secrets` flag keeps any secrets you've
+set so you don't have to reconfigure them.
+
+## Removing all state
+
+As a last resort, if `sbx reset` doesn't resolve your issue, you can remove the
+`sbx` state directory entirely. This deletes all sandbox data, configuration, and
+cached images. Stop all running sandboxes first with `sbx reset`.
+
+{{< tabs >}}
+{{< tab name="macOS" >}}
+
+```console
+$ rm -rf ~/Library/Application\ Support/com.docker.sandboxes/
+```
+
+{{< /tab >}}
+{{< tab name="Windows" >}}
+
+```powershell
+> Remove-Item -Recurse -Force "$env:LOCALAPPDATA\DockerSandboxes"
+```
+
+{{< /tab >}}
+{{< tab name="Linux" >}}
+
+Sandbox state on Linux follows the XDG Base Directory specification and is
+spread across three directories:
+
+```console
+$ rm -rf ~/.local/state/sandboxes/
+$ rm -rf ~/.cache/sandboxes/
+$ rm -rf ~/.config/sandboxes/
+```
+
+If you have set custom `XDG_STATE_HOME`, `XDG_CACHE_HOME`, or
+`XDG_CONFIG_HOME` environment variables, replace `~/.local/state`,
+`~/.cache`, and `~/.config` with the corresponding values.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Report an issue
+
+If you've exhausted the steps above and the problem persists, file a GitHub
+issue at [github.com/docker/sbx-releases/issues](https://github.com/docker/sbx-releases/issues).
+
+To help Docker investigate, generate a diagnostics bundle and share it when
+reporting the issue:
+
+```console
+$ sbx diagnose --upload
+```
+
+The bundle contains daemon logs, diagnostic check results, and basic system
+information. When `--upload` is confirmed, the bundle is uploaded to Docker
+support and the command prints a diagnostics ID. Include this ID in your
+issue so the team can correlate it with the uploaded bundle.
diff --git a/content/manuals/ai/sandboxes/usage.md b/content/manuals/ai/sandboxes/usage.md
new file mode 100644
index 000000000000..79c37ea7a4b7
--- /dev/null
+++ b/content/manuals/ai/sandboxes/usage.md
@@ -0,0 +1,345 @@
+---
+title: Usage
+weight: 30
+description: Basic sbx commands for creating, managing, and connecting to Docker Sandboxes.
+keywords: docker sandboxes, sbx, usage, run, create, stop, remove, ports, workspaces
+---
+
+Use this page as a command-oriented guide to day-to-day `sbx` operations. For
+scenario-based recommendations, see [Workflow patterns](workflows/).
+
+## Sign in
+
+Sign in from a terminal:
+
+```console
+$ sbx login
+```
+
+For scripts or CI runners where a browser isn't available, see
+[CI and headless use](workflows/automation.md).
+
+## Start, stop, and remove
+
+The basic workflow is [`run`](/reference/cli/sbx/run/) to start,
+[`ls`](/reference/cli/sbx/ls/) to check status,
+[`stop`](/reference/cli/sbx/stop/) to pause, and
+[`rm`](/reference/cli/sbx/rm/) to clean up:
+
+```console
+$ sbx run claude                    # start an agent
+$ sbx ls                            # see what's running
+$ sbx stop my-sandbox               # pause it
+$ sbx rm my-sandbox                 # delete it entirely
+```
+
+If the sandbox has an active session — an open attach, SSH connection, or
+in-flight SFTP transfer — `sbx rm` refuses unless you pass `--force`:
+
+```console
+$ sbx rm --force my-sandbox
+```
+
+If you need a clean slate, remove the sandbox and run it again:
+
+```console
+$ sbx stop my-sandbox
+$ sbx rm my-sandbox
+$ sbx run claude
+```
+
+To remove all stopped local sandboxes, use `sbx prune`. Running sandboxes are
+never removed. Preview the sandboxes that would be removed, or filter out
+sandboxes stopped within the last week:
+
+```console
+$ sbx prune --dry-run
+$ sbx prune --filter since=168h
+```
+
+Run `sbx prune` without flags to confirm and remove all stopped sandboxes.
+
+## Reconnect and name sandboxes
+
+Sandboxes persist after the agent exits. Running the same workspace path again
+reconnects to the existing sandbox rather than creating another sandbox:
+
+```console
+$ sbx run claude ~/my-project  # creates sandbox
+$ sbx run claude ~/my-project  # reconnects to same sandbox
+```
+
+Use `--name` to give a sandbox an explicit identity:
+
+```console
+$ sbx run claude --name my-project
+```
+
+Once a named sandbox exists, use `--name` to re-attach to it from any working
+directory, with or without the agent positional:
+
+```console
+$ sbx run --name my-project        # re-attaches from anywhere
+$ sbx run claude --name my-project # same, with agent confirmed
+```
+
+To run multiple sandboxes against the same workspace, give each a distinct
+name:
+
+```console
+$ sbx run claude --name feature ~/my-project
+$ sbx run claude --name spike ~/my-project
+```
+
+## Create without attaching
+
+[`sbx run`](/reference/cli/sbx/run/) creates the sandbox and attaches you to the
+agent. To create a sandbox in the background without attaching:
+
+```console
+$ sbx create --name my-project claude .
+```
+
+Unlike `run`, `create` requires an explicit workspace path. Attach later with
+`sbx run --name`:
+
+```console
+$ sbx run --name my-project
+```
+
+## Set environment variables
+
+> [!NOTE]
+> The `-e`/`--env` and `--env-file` flags require `sbx` version 0.39.0 or
+> later.
+
+Pass `-e` or `--env` to `sbx run` or `sbx create` to set an environment
+variable in the sandbox:
+
+```console
+$ sbx run -e LOG_LEVEL=debug claude
+```
+
+Specify a variable name without a value to copy its value from the host
+environment:
+
+```console
+$ export API_URL=https://api.example.com
+$ sbx run -e API_URL claude
+```
+
+To load multiple variables, pass one or more environment files:
+
+```console
+$ sbx create --name my-project --env-file .env.sandbox claude .
+```
+
+The flags follow `docker run` precedence rules. Values passed with `-e`
+override values from environment files. When you pass multiple environment
+files, a value in a later file overrides the same variable in an earlier file.
+
+When either command creates a sandbox, the variables are stored with the
+sandbox. They are also available to the agent session started by `sbx run`.
+When `sbx run` re-attaches to an existing sandbox, the variables apply to that
+agent session without changing the sandbox's stored environment. To set
+variables for one command instead, use `sbx exec -e` or
+`sbx exec --env-file`.
+
+To persist a variable across future sessions of an existing sandbox, append an
+export to `/etc/sandbox-persistent.sh`:
+
+```console
+$ sbx exec -d <sandbox-name> bash -c "echo 'export INTERNAL_API_URL=https://api.example.com' >> /etc/sandbox-persistent.sh"
+```
+
+The `bash -c` wrapper ensures the `>>` redirect runs inside the sandbox instead
+of on your host. The file is sourced when Bash starts inside the sandbox,
+including for interactive sessions and agents started with `sbx run`. A command
+passed directly to `sbx exec` doesn't start a shell. Wrap that command in
+`bash -c` if it needs variables from the persistent environment file.
+
+A variable added to the file only takes effect for sessions and agents started
+afterward. Restart a running agent, or stop and start the sandbox, to pick up
+the new value.
+
+Environment variables are readable by processes inside the sandbox. For API
+keys and other credentials, use [`sbx secret set`](configuration/credentials.md#store-a-secret)
+for a supported service or the experimental
+[`sbx secret set-custom`](configuration/credentials.md#custom-secrets) for a
+credential sent to known hosts. The host-side proxy can then inject the real
+value without exposing it to the agent.
+
+## Run commands inside a sandbox
+
+To get a shell inside a running sandbox, use [`sbx exec`](/reference/cli/sbx/exec/):
+
+```console
+$ sbx exec -it <sandbox-name> bash
+```
+
+## Interactive mode
+
+Running `sbx` with no subcommands opens an interactive terminal dashboard:
+
+```console
+$ sbx
+```
+
+The dashboard shows all your sandboxes as cards with live status, CPU, and
+memory usage. From here you can:
+
+- **Create** a sandbox (`c`).
+- **Start or stop** a sandbox (`s`).
+- **Attach** to an agent session (`Enter`), same as `sbx run`.
+- **Open a shell** inside the sandbox (`x`), same as `sbx exec`.
+- **Remove** a sandbox (`r`).
+
+The dashboard also includes a network governance panel where you can monitor
+outbound connections made by your sandboxes and manage network rules. Use `tab`
+to switch between the sandboxes panel and the network panel.
+
+From the network panel you can browse connection logs, allow or block specific
+hosts, and add custom network rules. Press `?` to see all keyboard shortcuts.
+
+## Git workspace modes
+
+When your primary workspace is a Git repository, choose how the sandbox receives
+it when you create the sandbox:
+
+- Direct mode is the default. The agent has read-write access to your working
+  tree, and changes appear on your host immediately.
+- [Clone mode](#clone-mode) uses `--clone`. The agent edits a separate Git clone
+  inside the sandbox. Its changes stay there until you fetch them or the agent
+  pushes them. Your host repository is also available at
+  `/run/sandbox/source`, but only with read access.
+
+For guidance on branch strategy, fetching work from a sandbox, and parallel
+agent workflows, see [Git workflows](workflows/git.md). For the
+security model behind each mode, see
+[Workspace isolation](security/isolation.md#workspace-isolation).
+
+### Clone mode
+
+To create a clone-mode sandbox, pass `--clone` when you run or create it:
+
+```console
+$ sbx run --clone claude
+```
+
+You can also create the sandbox in the background and attach later:
+
+```console
+$ sbx create --clone --name my-sandbox claude .
+$ sbx run --name my-sandbox
+```
+
+Clone mode has a few create-time constraints:
+
+- Clone mode is fixed at create time. To switch an existing sandbox to clone
+  mode, remove it and recreate it with `sbx create --clone`.
+- The clone follows whichever ref your host repository has checked out at create
+  time. No branch is created automatically.
+- The primary workspace must be a Git repository. Omit `--clone` for non-Git
+  workspaces.
+- Clone mode is rejected from inside a Git worktree other than the main one. The
+  read-only bind mount can't resolve the worktree's `.git` pointer file. Run
+  `sbx create --clone` from the main repository checkout instead.
+- Removing a clone-mode sandbox drops the in-sandbox clone. Fetch or push any
+  commits you want to keep before you remove it.
+
+## Multiple workspaces
+
+You can mount extra directories into a sandbox alongside the main workspace.
+The first path is the primary workspace — the agent starts here, and the
+sandbox's in-container Git clone is populated from this directory if you
+use `--clone`. Extra workspaces are always mounted directly.
+
+All workspaces appear inside the sandbox at their absolute host paths. Append
+`:ro` to mount an extra workspace read-only — useful for reference material or
+shared libraries the agent shouldn't modify:
+
+```console
+$ sbx run claude ~/project-a ~/shared-libs:ro ~/docs:ro
+```
+
+You can also run separate projects side-by-side. Remove unused sandboxes when
+you're done to reclaim disk space:
+
+```console
+$ sbx run claude ~/project-a
+$ sbx run claude ~/project-b
+$ sbx rm <sandbox-name>       # when finished
+```
+
+## Copying files between host and sandbox
+
+Use [`sbx cp`](/reference/cli/sbx/cp/) to copy files or directories between
+your host and a sandbox. This is useful for one-off files that aren't part of a
+mounted workspace, such as generated output, logs, or setup files.
+
+```console
+$ sbx cp ./config.json my-sandbox:/home/user/
+$ sbx cp my-sandbox:/home/user/output.log ./
+$ sbx cp ./src/ my-sandbox:/home/user/src
+```
+
+One side of the copy must use `SANDBOX:PATH`. Copying directly between two
+sandboxes isn't supported.
+
+## Publish ports
+
+Sandboxes are [network-isolated](security/isolation.md) — your browser or local
+tools can't reach a server running inside one by default. A port mapping of
+`8080:3000` publishes sandbox port 3000 on host port 8080.
+
+If you know which ports you need, publish them when you create the sandbox:
+
+```console
+$ sbx run --publish 8080:3000 --name my-sandbox claude
+```
+
+For an existing sandbox, use [`sbx ports`](/reference/cli/sbx/ports/) to
+forward traffic from your host:
+
+```console
+$ sbx ports my-sandbox --publish 8080:3000
+$ open http://localhost:8080
+```
+
+To let the OS pick a free host port instead of choosing one yourself, specify
+only the sandbox port. Then use `sbx ports` to check which host port was
+assigned:
+
+```console
+$ sbx ports my-sandbox --publish 3000
+$ sbx ports my-sandbox
+```
+
+`sbx ls` shows active port mappings alongside each sandbox. `sbx ports` lists
+them in detail.
+
+```console
+$ sbx ls
+SANDBOX         AGENT   STATUS   PORTS                    WORKSPACE
+my-sandbox      claude  running  127.0.0.1:8080->3000/tcp /home/user/proj
+```
+
+To stop forwarding a port:
+
+```console
+$ sbx ports my-sandbox --unpublish 8080:3000
+```
+
+When `sbx run` re-attaches to an existing sandbox, it ignores `--publish`. Use
+`sbx ports` to publish ports on that sandbox. For dev server and host-service
+recipes, see
+[Local services](workflows/development.md#local-services).
+
+## What persists
+
+While a sandbox exists, installed packages, Docker images, configuration
+changes, and command history all persist across stops and restarts. When you
+remove a sandbox, everything inside is deleted. Your workspace files and the
+[shared agent skills store](workflows/agent-skills.md) remain on your
+host. To preserve a configured environment, create a [custom
+template](customize/templates.md) or use a [kit](customize/kits.md).
diff --git a/content/manuals/ai/sandboxes/workflows/_index.md b/content/manuals/ai/sandboxes/workflows/_index.md
new file mode 100644
index 000000000000..f0b24191ab10
--- /dev/null
+++ b/content/manuals/ai/sandboxes/workflows/_index.md
@@ -0,0 +1,46 @@
+---
+title: Workflow patterns
+linkTitle: Workflows
+weight: 50
+description: Choose a Docker Sandboxes workflow for agent skills, Git, local development, authenticated tools, or headless automation.
+keywords: docker sandboxes, sbx, workflows, agent skills, shared skills, clone mode, git, local development, authentication, ci, headless
+toc_max: 2
+---
+
+Choose a workflow based on how you want to develop, authenticate tools, or run
+sandboxes in automation. For command syntax and lifecycle basics, see
+[Usage](../usage.md).
+
+## Choose how code moves
+
+Your workspace strategy determines when an agent's changes appear on the host.
+Direct mode edits the host working tree in place. Clone mode keeps changes in a
+private clone until you fetch or push them. Host worktrees provide branch
+isolation while keeping Git operations on the host. See [Git workflows](git.md)
+to choose a strategy for single or parallel tasks.
+
+## Develop in the sandbox
+
+Each sandbox has a private Docker daemon and runtime for building images,
+installing dependencies, and running tests. You can publish services from the
+sandbox or connect to services on the host. See
+[Develop and test locally](development.md).
+
+Tools inside the sandbox can use credentials configured on the host without
+copying secret values into the VM. See
+[Authenticate command-line tools](authentication.md) for GitHub CLI, registry,
+and external secret-provider workflows.
+
+## Reuse and automate workflows
+
+Sandbox environment files work like Compose files for sandboxes: they capture
+project configuration in a versioned YAML file. Use `.sbxenv.yaml` to define
+the agent, workspaces, tools, resources, credentials, and ports so contributors
+can start a consistent environment without reproducing CLI flags and setup
+steps. See [Sandbox environment files](../configuration/environment-files.md).
+
+You can also import skills from supported host agents into a persistent store
+shared with new sandboxes. See [Share agent skills](agent-skills.md).
+
+For unattended jobs, use headless authentication and manage the sandbox
+lifecycle from scripts. See [Run sandboxes in CI](automation.md).
diff --git a/content/manuals/ai/sandboxes/workflows/agent-skills.md b/content/manuals/ai/sandboxes/workflows/agent-skills.md
new file mode 100644
index 000000000000..8efaf6069e12
--- /dev/null
+++ b/content/manuals/ai/sandboxes/workflows/agent-skills.md
@@ -0,0 +1,87 @@
+---
+title: Share agent skills
+linkTitle: Agent skills
+weight: 40
+description: Import skills from supported host agents into a persistent store shared with Docker Sandboxes.
+keywords: docker sandboxes, sbx, agent skills, shared skills, claude code, codex, copilot, cursor, droid
+---
+
+Shared agent skills make skills from supported agents on your host available
+inside your sandboxes. Importing copies the skills into a persistent store that
+survives sandbox deletion and is shared by default with new sandboxes that run
+a supported agent.
+
+> [!NOTE]
+> Shared agent skills are experimental.
+
+Preview the skills that `sbx` finds without copying them:
+
+```console
+$ sbx skills import --dry-run
+```
+
+The command scans the following directories in order and copies each skill
+subdirectory into the shared store. When the sandbox starts, `sbx` mounts the
+store at the path the agent reads inside the sandbox.
+
+| Agent       | Host source         | Sandbox mount target          |
+| ----------- | ------------------- | ----------------------------- |
+| Claude Code | `~/.claude/skills`  | `/home/agent/.claude/skills`  |
+| Codex       | `~/.agents/skills`  | `/home/agent/.agents/skills`  |
+| Copilot     | `~/.copilot/skills` | `/home/agent/.copilot/skills` |
+| Cursor      | `~/.cursor/skills`  | `/home/agent/.cursor/skills`  |
+| Droid       | `~/.factory/skills` | `/home/agent/.factory/skills` |
+
+All imported skills go into the same store, regardless of their source. If
+more than one source contains a skill with the same directory name, the skill
+from the first source in the table wins and `sbx` warns about the others.
+
+Import the skills:
+
+```console
+$ sbx skills import
+```
+
+The final output reports the shared store path. The default locations are:
+
+| Platform | Shared store path                                                           |
+| -------- | --------------------------------------------------------------------------- |
+| macOS    | `~/Library/Application Support/com.docker.sandboxes/sandboxes/agent-skills` |
+| Linux    | `~/.local/state/sandboxes/sandboxes/agent-skills`                           |
+| Windows  | `%LOCALAPPDATA%\DockerSandboxes\sandboxes\state\agent-skills`               |
+
+On Linux, `sbx` uses `$XDG_STATE_HOME/sandboxes/sandboxes/agent-skills` when
+`XDG_STATE_HOME` is set.
+
+When a skill already exists in the store, `sbx` prompts before replacing it.
+Use `--force` to replace existing skills without prompts. Importing replaces
+the complete skill directory rather than merging files. Run the import command
+again when you want to copy updates from the host. Running `sbx reset` clears
+the shared store.
+
+Sandboxes created with `sbx` version 0.37.0 or later for a supported agent are
+configured to mount the store read-write by default. These sandboxes mount the
+current contents of the store each time they start, so you can import skills
+before or after creating them. To create a sandbox without the shared store,
+use `--no-share-skills`:
+
+```console
+$ sbx run --no-share-skills claude
+```
+
+Upgrading `sbx` does not enable shared skills for sandboxes created with an
+earlier version. Remove and recreate those sandboxes after upgrading. The
+`--no-share-skills` option also only applies when the sandbox is created. To
+turn off shared skills for an existing sandbox, remove it and recreate it with
+the option.
+
+> [!WARNING]
+> The shared skills store is mounted read-write. A sandbox can modify any skill
+> in the store, and another sandbox can later load the modified instructions or
+> run the modified scripts. The store is dedicated sandbox state, so this does
+> not by itself execute the modified skill on your host. It does put every
+> sandbox that shares the store in the same trust boundary. Use
+> `--no-share-skills` to keep a sandbox outside that boundary.
+
+Some agents scan for skills when a session starts. If imported skills don't
+appear in an existing session, start another agent session.
diff --git a/content/manuals/ai/sandboxes/workflows/authentication.md b/content/manuals/ai/sandboxes/workflows/authentication.md
new file mode 100644
index 000000000000..0edd3012888f
--- /dev/null
+++ b/content/manuals/ai/sandboxes/workflows/authentication.md
@@ -0,0 +1,109 @@
+---
+title: Authenticate command-line tools
+linkTitle: Authenticate tools
+weight: 30
+description: Use authenticated command-line tools and dynamic secret sources inside Docker Sandboxes.
+keywords: docker sandboxes, sbx, authentication, github cli, registry, 1password, aws secrets manager
+---
+
+The sandbox proxy handles API credentials for model providers automatically,
+but agents often also need credentials for tools like `gh`, `docker`, or a
+secrets manager. Configure the credential source on your host, and the proxy
+injects the resolved value into matching requests from the sandbox. Dynamic
+secret sources can retrieve a value from an authenticated host CLI without
+copying the value into the secret store.
+
+> [!NOTE]
+> Service secrets are global by default, so all future sandboxes can use them.
+> Sandboxes that already exist when you run `sbx secret set` do not
+> receive the updated value. To update a running sandbox, scope the secret to
+> it directly: `sbx secret set <service> --sandbox <sandbox-name>`.
+
+## GitHub CLI
+
+Store your GitHub token as a sandbox secret. The proxy injects it into
+outbound requests, so `gh` works inside the sandbox without any additional
+configuration:
+
+```console
+$ sbx secret set github --command 'gh auth token'
+```
+
+The daemon runs `gh auth token` on the host and caches its output for 55 minutes
+by default. After the cache expires, it runs the command again, so token updates
+from `gh` don't need to be copied into `sbx` manually. Use `--refresh on-demand`
+to run the command for every credential use.
+
+The agent can then create pull requests, open issues, comment on PRs, and
+interact with the GitHub API the same way it would from your host:
+
+```console
+# Inside the sandbox
+$ gh pr create --title "feat: my feature" --body "..."
+$ gh issue list
+```
+
+The token is never stored in plaintext inside the sandbox. See
+[GitHub token](../configuration/credentials.md#github-token) for details.
+
+## Docker registry
+
+When using Docker Hub, authentication is handled automatically; `sbx` reuses
+your existing login session. For other registries, you need to configure
+credentials for `sbx` so it can pull private [templates](../customize/templates.md)
+and kits when creating a sandbox:
+
+```console
+$ gh auth token | sbx secret set --all-sandboxes --registry ghcr.io \
+    --username <github-username> --password-stdin
+$ echo "$ACR_PASSWORD" | sbx secret set --all-sandboxes \
+    --registry myregistry.azurecr.io \
+    --username myuser --password-stdin
+```
+
+Add `-g` or a sandbox name when the agent needs to run authenticated
+`docker pull` or `docker push` commands from inside the sandbox. The host-side
+proxy handles the registry login without writing the credential into the
+sandbox.
+
+Images and containers built inside the sandbox run on the sandbox's private
+Docker daemon, not your host's. They're deleted when the sandbox is removed.
+
+For information on how registry credentials differ from other secrets,
+per-registry username requirements, and all-sandbox versus per-sandbox scoping, see
+[Registry credentials](../configuration/credentials.md#registry-credentials).
+
+## Source credentials from 1Password
+
+Install the 1Password CLI, sign in on the host, and pass an `op://` reference to
+`sbx secret set`. The secret store records the reference, and the daemon uses
+`op read` on the host when the proxy needs the credential:
+
+```console
+$ sbx secret set github --ref 'op://Work/GitHub/token'
+$ sbx secret set anthropic --ref 'op://Work/Anthropic/credential'
+```
+
+The real value stays on your host, and the sandbox sees the proxy-managed
+placeholder. Service secrets are cached for 55 minutes by default. To retrieve
+the value from 1Password for every credential use, set the refresh policy:
+
+```console
+$ sbx secret set anthropic \
+    --ref 'op://Work/Anthropic/credential' \
+    --refresh on-demand
+```
+
+## Source credentials from AWS Secrets Manager
+
+Install and authenticate the AWS CLI on the host, then register the secret's
+ARN. The daemon calls AWS Secrets Manager when the proxy needs the value:
+
+```console
+$ sbx secret set anthropic \
+    --ref 'arn:aws:secretsmanager:us-west-2:123456789012:secret:anthropic-api-key'
+```
+
+See [Use a dynamic secret source](../configuration/credentials.md#use-a-dynamic-secret-source)
+for refresh policies, verification options, custom secrets, and provider
+account or profile selection.
diff --git a/content/manuals/ai/sandboxes/workflows/automation.md b/content/manuals/ai/sandboxes/workflows/automation.md
new file mode 100644
index 000000000000..f7b6d38fdfe8
--- /dev/null
+++ b/content/manuals/ai/sandboxes/workflows/automation.md
@@ -0,0 +1,46 @@
+---
+title: Run sandboxes in CI
+linkTitle: CI and headless
+weight: 50
+description: Authenticate and run Docker Sandboxes in CI systems and other headless environments.
+keywords: docker sandboxes, sbx, ci, headless, automation, personal access token
+---
+
+For CI environments and scripts where a browser isn't available, authenticate
+with a Docker Personal Access Token (PAT):
+
+```console
+$ echo "$DOCKER_PAT" | sbx login --username <your-docker-id> --password-stdin
+```
+
+Generate a PAT from your
+[Docker account settings](https://app.docker.com/settings/personal-access-tokens)
+with at least **Read** scope.
+
+From there, the rest of the `sbx` workflow is the same as interactive use.
+Create the sandbox in the background with `sbx create`, run agent tasks with
+`sbx exec`, and clean up with `sbx rm`:
+
+```console
+$ sbx create --name ci-task --clone claude
+$ sbx run --name ci-task  # attach and give instructions, or use sbx exec for one-off commands
+$ git fetch sandbox-ci-task
+$ sbx rm ci-task
+```
+
+Agent credentials (API keys, GitHub token) can be preconfigured as global
+secrets so they're available to any sandbox the CI runner creates. If the
+relevant environment variables are already set in the CI environment (see the
+[built-in services table](../configuration/credentials.md#built-in-services) for which
+variables each service reads), import them all at once:
+
+```console
+$ sbx secret import --all
+```
+
+To overwrite an existing stored entry, add `--force`. To pass a value from your
+CI provider's secret store, use `-t`. For example, in a GitHub Actions step:
+
+```yaml
+- run: sbx secret set anthropic -t "${{ secrets.ANTHROPIC_API_KEY }}"
+```
diff --git a/content/manuals/ai/sandboxes/workflows/development.md b/content/manuals/ai/sandboxes/workflows/development.md
new file mode 100644
index 000000000000..3080053c0630
--- /dev/null
+++ b/content/manuals/ai/sandboxes/workflows/development.md
@@ -0,0 +1,124 @@
+---
+title: Develop and test locally
+linkTitle: Local development
+weight: 20
+description: Build, test, and connect to development services in Docker Sandboxes.
+keywords: docker sandboxes, sbx, local development, build, test, ports, host services
+---
+
+Use a sandbox's private runtime to build images, run tests, and connect local
+tools to development services across the sandbox boundary.
+
+## Build and test inside a sandbox
+
+Agents have sudo access inside the sandbox, so they can install packages,
+start databases, run test dependencies, and prepare the environment they need.
+Installed packages persist for the sandbox's lifetime. For repeated setup, use
+[Customize](../customize/) to package the environment as a template or kit.
+
+Agents can also build Docker images, run containers, and use
+[Compose](/manuals/compose/_index.md). Everything runs inside the sandbox's
+private Docker daemon, so containers started by the agent never appear in your
+host's `docker ps`. When you remove the sandbox, all images, containers, and
+volumes inside it are deleted with it.
+
+This pattern works well for tasks where the agent needs to run the project's
+test suite or inspect a service it started. If you need to reach that service
+from your host, publish the port when you create the sandbox, or publish it
+later with `sbx ports`.
+
+## Local services
+
+Use this workflow when a sandboxed agent starts a dev server, or when the agent
+needs to call a service running on your host.
+
+### Accessing services in the sandbox
+
+Sandboxes are [network-isolated](../security/isolation.md) — your browser or local
+tools can't reach a server running inside one by default. A port mapping of
+`8080:3000` publishes sandbox port 3000 on host port 8080.
+
+If you know which ports you need, publish them when you create the sandbox:
+
+```console
+$ sbx run --publish 8080:3000 --name my-sandbox claude
+```
+
+For an existing sandbox, use [`sbx ports`](/reference/cli/sbx/ports/) to
+forward traffic from your host.
+
+The common case: an agent has started a dev server or API, and you want to open
+it in your browser or run tests against it.
+
+```console
+$ sbx ports my-sandbox --publish 8080:3000
+$ open http://localhost:8080
+```
+
+To let the OS pick a free host port instead of choosing one yourself, specify
+only the sandbox port. Then use `sbx ports` to check which host port was
+assigned:
+
+```console
+$ sbx ports my-sandbox --publish 3000
+$ sbx ports my-sandbox
+```
+
+`sbx ls` shows active port mappings alongside each sandbox, and `sbx ports`
+lists them in detail:
+
+```console
+$ sbx ls
+SANDBOX         AGENT   STATUS   PORTS                    WORKSPACE
+my-sandbox      claude  running  127.0.0.1:8080->3000/tcp /home/user/proj
+```
+
+To stop forwarding a port:
+
+```console
+$ sbx ports my-sandbox --unpublish 8080:3000
+```
+
+For a service to be reachable, it must listen on all interfaces inside the
+sandbox, not only `127.0.0.1`. Bind it to `0.0.0.0` for IPv4 or `[::]` for both
+IPv4 and IPv6. Most dev servers need a flag like `--host 0.0.0.0` to do this.
+On the host, `--publish` listens on both `127.0.0.1` and `::1`, so a client
+resolving `localhost` might pick IPv6 and fail with "connection reset by peer"
+if the sandboxed service only listens on IPv4, even when
+`http://127.0.0.1:<port>/` works. To fix that, bind the service to `[::]`, or
+pin the published port to one family with `--publish 8080:3000/tcp4` or
+`/tcp6`.
+
+Published ports survive restarts: `sbx` re-publishes them when the sandbox or
+the daemon restarts. Explicit host ports are reused, while a port published with
+an OS-assigned host port, such as `--publish 3000`, gets a different host port
+on each start. Check `sbx ports my-sandbox` to find it. If an explicit host port
+is already in use at restart, the CLI or the dashboard prompts you to choose
+another. Removing the sandbox releases its ports.
+
+When `sbx run` re-attaches to an existing sandbox, it ignores `--publish`. Use
+`sbx ports` to publish ports on that sandbox. To stop forwarding,
+`--unpublish 8080:3000` removes a single mapping, and `--unpublish 3000`
+removes every host port mapped to sandbox port 3000.
+
+### Accessing host services from a sandbox
+
+Services running on your host are reachable from inside a sandbox using the
+hostname `host.docker.internal`. Use this instead of `127.0.0.1` or your
+machine's local network IP address, which are not reachable from inside the
+sandbox.
+
+The sandbox proxy translates `host.docker.internal` to `localhost` before
+forwarding the request, so you must add the `localhost` address with the
+specific port to your network policy allowlist:
+
+```console
+$ sbx policy allow network localhost:11434
+```
+
+Then use `host.docker.internal` in any configuration or request that points at
+the host service. For example, to verify connectivity from a sandbox shell:
+
+```console
+$ curl http://host.docker.internal:11434
+```
diff --git a/content/manuals/ai/sandboxes/workflows/git.md b/content/manuals/ai/sandboxes/workflows/git.md
new file mode 100644
index 000000000000..07ccf097acd3
--- /dev/null
+++ b/content/manuals/ai/sandboxes/workflows/git.md
@@ -0,0 +1,218 @@
+---
+title: Use Git with sandboxes
+linkTitle: Git workflows
+weight: 10
+description: Choose a Git workspace mode and manage branches, parallel tasks, and signed commits with Docker Sandboxes.
+keywords: docker sandboxes, sbx, git, clone mode, direct mode, worktrees, branches, commit signing
+---
+
+Sandboxes support three approaches for working with Git repositories. The
+right choice depends on whether you want branch isolation and whether you
+plan to run tasks in parallel:
+
+|                           | Direct mode      | Clone mode (`--clone`)       | Host worktree                 |
+| ------------------------- | ---------------- | ---------------------------- | ----------------------------- |
+| Branch management         | You, on the host | Agent, inside the clone      | You, on the host              |
+| Changes visible on host   | Immediately      | After fetch or agent push    | Immediately                   |
+| Agent can use Git         | Yes              | Yes                          | No                            |
+| Parallelism               | No               | Multiple agents, one sandbox | One sandbox per parallel task |
+| Mode fixed at create time | No               | Yes                          | —                             |
+
+## Direct mode
+
+The simplest approach. The sandbox mounts your host working tree directly —
+the agent edits files in place and changes appear immediately. You manage
+branches yourself.
+
+1. Check out the branch you want to work on:
+
+   ```console
+   $ git checkout -b feat/my-feature
+   ```
+
+2. Start the sandbox. No special flags needed:
+
+   ```console
+   $ sbx run claude
+   ```
+
+3. The agent edits files in your working tree. Review diffs, stage, and
+   commit as you normally would:
+
+   ```console
+   $ git diff
+   $ git add -p
+   $ git commit
+   $ git push -u origin feat/my-feature
+   ```
+
+Because the sandbox mounts your working tree, switching branches on the host
+also changes what the agent sees. This makes direct mode well-suited for
+focused, single-branch work where you're collaborating with the agent
+turn-by-turn.
+
+## Clone mode
+
+In clone mode, `sbx` creates a separate Git clone inside the sandbox. The agent
+edits this clone instead of your host working tree. Its changes stay inside the
+sandbox until you fetch a branch or the agent pushes one to a remote. Your host
+repository is also available at `/run/sandbox/source`, but only with read
+access. The sandbox clone is not a Git worktree linked to your host checkout.
+
+A single clone-mode sandbox can hold multiple branches and worktrees for
+parallel tasks. The `--clone` flag creates the clone, but it doesn't separate
+one task from another. To keep parallel tasks isolated, instruct your agent tool
+to create a separate branch or worktree for each task.
+
+> [!NOTE]
+> `--clone` is a create-time flag and cannot be changed on an existing
+> sandbox. To change a sandbox from clone mode to direct mode, remove and
+> recreate it. To run both modes against the same repository, create separate
+> sandboxes with distinct names.
+
+### Sandbox remote behavior
+
+The CLI copies Git remotes from your host repository, such as `origin` and
+`upstream`, into the in-sandbox clone. Local-path remotes, such as `file://`
+URLs and filesystem paths, aren't copied because they aren't reachable from
+inside the sandbox.
+
+The Git daemon that exposes the in-sandbox clone runs as part of the sandbox.
+It's only reachable while the sandbox is running:
+
+- `sbx stop` shuts down the daemon. `git fetch sandbox-<name>` fails until the
+  sandbox starts again.
+- Restarting the sandbox assigns another ephemeral port to the daemon. The CLI
+  updates the `sandbox-<name>` remote URL in your host repository's Git config,
+  so fetching continues without manual reconfiguration.
+- `sbx rm` removes the sandbox, the daemon, the published port, and the
+  `sandbox-<name>` remote entry from your host repository.
+
+### Single task
+
+1. Start a clone-mode sandbox:
+
+   ```console
+   $ sbx run --clone claude
+   ```
+
+2. Ask the agent to create a branch before it starts editing:
+
+   > Create a branch `feat/my-feature` and make the changes.
+
+3. Fetch the agent's branch when it's done:
+
+   ```console
+   $ git fetch sandbox-<name>
+   $ git log sandbox-<name>/feat/my-feature
+   $ git diff main..sandbox-<name>/feat/my-feature
+   ```
+
+4. Pull the branch to the host and push, or ask the agent to push directly:
+
+   ```console
+   # Pull to host, then push
+   $ git checkout -b feat/my-feature sandbox-<name>/feat/my-feature
+   $ git push -u origin feat/my-feature
+   $ gh pr create
+
+   # Or ask the agent
+   # "Push feat/my-feature to origin and open a PR."
+   ```
+
+### Parallel tasks
+
+1. Start a clone-mode sandbox and open the
+   [agents view](../agents/claude-code.md#agents-view):
+
+   ```console
+   $ sbx run --clone claude
+   ```
+
+2. Dispatch each independent task to a separate background session. Your agent
+   tool may use branches or worktrees to keep their changes separate. If it
+   doesn't, add a project instruction such as:
+
+   ```markdown
+   Always start each task on its own git branch before making changes.
+   ```
+
+3. Fetch all branches when the agents are done:
+
+   ```console
+   $ git fetch sandbox-<name>
+   $ git log sandbox-<name>/feat/task-a
+   $ git log sandbox-<name>/feat/task-b
+   ```
+
+4. Check out the branches you want to keep and open PRs as normal.
+
+## Host worktree
+
+You can create a Git worktree on your host and point the sandbox at it. The
+agent edits files directly in the worktree — but because the sandbox mounts
+only the worktree directory (not the parent repository), it can't resolve the
+`.git` pointer file and has no Git access. The agent can read and write files,
+but can't commit, branch, or check status.
+
+This is useful when you want branch isolation without the create-time
+commitment of clone mode, and you're comfortable committing from the host
+yourself after reviewing the changes.
+
+1. Create the worktree on the host:
+
+   ```console
+   $ git worktree add -b feat/my-feature ../my-feature-work
+   ```
+
+2. Start the sandbox with the worktree as the workspace:
+
+   ```console
+   $ sbx run claude ../my-feature-work
+   ```
+
+3. The agent edits files. When it's done, commit and push from the host:
+
+   ```console
+   $ cd ../my-feature-work
+   $ git diff
+   $ git add -p && git commit
+   $ git push -u origin feat/my-feature
+   $ gh pr create
+   ```
+
+## Commit signing
+
+Sandboxes forward your host SSH agent into the sandbox, so the agent can
+sign commits with your SSH key without the private key ever leaving your
+host.
+
+1. On your host, make sure the signing key is loaded in your SSH agent:
+
+   ```console
+   $ ssh-add ~/.ssh/id_ed25519
+   $ ssh-add -L  # confirm the key appears
+   ```
+
+2. Inside the sandbox, configure Git to sign with SSH. Use the forwarded key
+   directly rather than a file path, since host paths don't exist inside the
+   sandbox:
+
+   ```console
+   $ git config --global gpg.format ssh
+   $ git config --global user.signingkey "key::$(ssh-add -L | head -n 1)"
+   ```
+
+3. Sign commits as usual:
+
+   ```console
+   $ git commit -S -m "feat: my change"
+   ```
+
+To apply this configuration automatically to every sandbox, use the
+[`git-ssh-sign`](https://github.com/docker/sbx-kits-contrib/tree/main/git-ssh-sign)
+community kit, which handles all of the above setup. See [Kits](../customize/kits.md)
+if you want to package it alongside other sandbox customizations.
+
+For troubleshooting, see
+[Sandbox commits aren't signed](../troubleshooting.md#sandbox-commits-arent-signed).
diff --git a/content/manuals/billing/3d-secure.md b/content/manuals/billing/3d-secure.md
index 32f815c8768b..eca8852ca43c 100644
--- a/content/manuals/billing/3d-secure.md
+++ b/content/manuals/billing/3d-secure.md
@@ -1,31 +1,52 @@
 ---
-title: 3D Secure authentication
-description: Learn about 3D Secure support for Docker billing.
-keywords: billing, renewal, payments, subscriptions
-weight: 40
+title: Use 3D Secure authentication for Docker billing
+linkTitle: 3D Secure
+description: Learn how 3D Secure authentication works for Docker subscription payments and how to troubleshoot verification issues.
+keywords: billing, payments, subscriptions, 3D Secure, 3DS, credit card verification, payment authentication
+weight: 30
 ---
 
-> [!NOTE]
->
-> [Docker plan](../subscription/setup.md) payments support 3D secure authentication.
+Docker supports 3D Secure (3DS), an extra layer of authentication required
+for certain credit card payments. If your bank or card issuer requires 3DS, you
+may need to verify your identity before your payment can be completed.
+
+## How it works
+
+When a 3DS check is triggered during checkout, your bank or card issuer
+may ask you to verify your identity. This can include:
 
-3D Secure (3DS) authentication incorporates an additional security layer for credit card transactions. If you’re making payments for your Docker billing in a region that requires 3DS, or using a payment method that requires 3DS, you’ll need to verify your identity to complete any transactions. The method used to verify your identity varies depending on your banking institution.
+- Entering a one-time password sent to your phone
+- Approving the charge through your mobile banking app
+- Answering a security question or using biometrics
 
-The following transactions will use 3DS authentication if your payment method requires it.
+The exact verification steps depend on your financial institution's
+requirements.
 
-- Starting a [new paid subscription](../subscription/setup.md)
-- Changing your [billing cycle](/billing/cycle/) from monthly to annual
-- [Upgrading your subscription](../subscription/change.md)
-- [Adding seats](../subscription/manage-seats.md) to an existing subscription
+## When you need to verify
 
-## Troubleshooting
+You may be asked to verify your identity when performing any of the following
+actions:
 
-If you encounter errors completing payments due to 3DS, you can troubleshoot in the following ways.
+- Starting a [paid subscription](../subscription/manage.md)
+- Changing your [billing cycle](/manuals/billing/details.md#billing-cycle) from monthly to annual
+- [Upgrading your subscription](../subscription/manage.md#upgrade-plans)
+- [Adding seats](../admin/organization/manage/manage-seats.md) to an existing
+  subscription
 
-1. Retry your transaction and verification of your identity.
-2. Contact your bank to determine any errors on their end.
-3. Try a different payment method that doesn’t require 3DS.
+If 3DS is required and your payment method supports it, the verification prompt
+will appear during checkout.
 
-> [!TIP]
+## Troubleshooting payment verification
+
+If you're unable to complete your payment due to 3DS:
+
+1. Retry your transaction. Make sure you're completing the verification
+   prompt in the same browser tab.
+1. Use a different payment method.
+1. Contact your bank to confirm whether it's blocking the payment or the 3DS
+   verification attempt.
+
+> [!NOTE]
 >
-> Make sure you allow third-party scripts in your browser and that any ad blocker you may use is disabled when attempting to complete payments.
+> Disabling ad blockers or browser extensions that block pop-ups can help
+> the 3DS prompt display correctly.
diff --git a/content/manuals/billing/_index.md b/content/manuals/billing/_index.md
index fc869b4dcb26..4f94c88bdec0 100644
--- a/content/manuals/billing/_index.md
+++ b/content/manuals/billing/_index.md
@@ -1,41 +1,80 @@
 ---
-title: Billing and payments
+title: Manage billing and payments
 linkTitle: Billing
-description: Discover information on billing and payment processes for Docker subscriptions.
-keywords: billing, invoice, payment, subscription
-weight: 20
+description: >
+  Manage Docker billing and payments, including usage, costs, credits,
+  invoices, payment methods, and tax details.
+keywords:
+  billing, invoice, payment, subscription, Docker billing, update payment
+  method, billing history, invoices, payment verification, tax exemption,
+  usage, costs, credits, metered billing
+weight: 30
 params:
   sidebar:
     group: Platform
 grid_core:
-- title: Add or update a payment method
-  description: Learn how to add or update a payment method for your personal account or organization.
-  link: /billing/payment-method/
-  icon: credit_score
-- title: Update billing information
-  description: Discover how to update the billing information for your personal account or organization.
-  link: /billing/details/
-  icon: contract_edit
-- title: View billing history
-  description: Learn how to view billing history and download past invoices.
-  link: /billing/history/
-  icon: payments
-- title: Billing FAQs
-  description: Find the answers you need and explore common questions.
-  link: /billing/faqs/
-  icon: help
-- title: Register a tax certificate
-  description: Learn how to register a tax exemption certificate.
-  link: /billing/tax-certificate/
-  icon: developer_guide
-- title: 3D Secure authentication
-  description: Discover how Docker billing supports 3DS and how to troubleshoot potential issues.
-  link: /billing/3d-secure/
-  icon: wallet
+  - title: Add or update a payment method
+    description: Learn how to add or update a payment method for your personal account or organization.
+    link: /billing/payment-method/
+    icon: credit-card
+  - title: Update billing information
+    description: Learn how to update billing information for your personal account or organization.
+    link: /billing/details/
+    icon: pencil-square
+  - title: View billing history
+    description: Learn how to view billing history and download past invoices.
+    link: /billing/history/
+    icon: credit-card
+  - title: 3D Secure authentication
+    description: Learn how 3DS works and how to troubleshoot verification issues.
+    link: /billing/3d-secure/
+    icon: wallet
+  - title: Taxes
+    description: Learn how to submit a US tax exemption certificate or add a VAT number.
+    link: /billing/tax-certificate/
+    icon: document-text
 aliases:
   - /billing/docker-hub-pricing/
 ---
 
-Use the resources in this section to manage your billing and payment settings for your Docker subscription plans.
+You can use the billing portal to manage your Docker subscriptions, such
+as updating payment methods, reviewing billing details, and tracking
+invoice history.
+
+## Billing
+
+You can manage your Docker plans from the billing portal:
+
+1. Sign in to [Docker Home](https://app.docker.com/), then choose your
+   account.
+1. Go to **Billing** to view the **Overview** page.
+1. Select the page you want to explore.
+
+### Usage
+
+The billing **Usage** page helps you compare usage-based charges across
+billing periods. You can track usage by changing the period, product,
+and how the product is metered.
+
+### Costs
+
+The billing **Costs** page aggregates all costs by billing period. It
+breaks down charges by resource (the product accruing a charge), the
+status of your billing period, and costs to date.
+
+### Credits
+
+The billing **Credits** page shows credits applied to your costs. If you
+received a promotional credit, you can see how it applies to your bill
+from this page.
+
+## Docker plans and billing cycle
+
+Your invoice history is a reference to the Docker plans you subscribe
+to. For information about your billing cycle and renewal dates, see
+[Billing cycle](/manuals/billing/details.md#billing-cycle). To upgrade or add
+a new plan, see [Subscription](/manuals/subscription/_index.md).
+
+## Next steps
 
 {{< grid items="grid_core" >}}
diff --git a/content/manuals/billing/cycle.md b/content/manuals/billing/cycle.md
deleted file mode 100644
index e3e98563ff5c..000000000000
--- a/content/manuals/billing/cycle.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: Change your billing cycle
-weight: 50
-description: Learn to change your billing cycle for your Docker subscription
-keywords: billing, cycle, payments, subscription
----
-
-You can pay for a subscription plan on a monthly or yearly billing cycle. You select your preferred billing cycle when you buy your subscription.
-
-> [!NOTE]
->
-> Business plan is available only on yearly billing cycle.
-
-If you have a monthly billing cycle, you can choose to switch to an annual billing cycle.
-
-> [!NOTE]
->
-> You can't switch from an annual billing cycle to a monthly cycle.
-
-When you change the billing cycle's duration:
-
-- The next billing date reflects the new cycle. To find your next billing date, see [View renewal date](history.md#view-renewal-date).
-- The subscription's start date resets. For example, if the start date of the monthly subscription is March 1st and the end date is April 1st, then after switching the billing duration to March 15th, 2024 the new start date is March 15th, 2024, and the new end date is March 15th, 2025.
-- Any unused monthly subscription is prorated and applied as credit towards the new annual period. For example, if you switch from a $10 monthly subscription to a $100 annual plan, deducting the unused monthly value (in this case $5), the migration cost becomes $95 ($100 - $5). The renewal cost after March 15, 2025 is $100.
-
-{{% include "tax-compliance.md" %}}
-
-## Personal account
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-To change your billing cycle:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. On the plans and usage page, select **Switch to annual billing**.
-4. Verify your billing information.
-5. Select **Continue to payment**.
-6. Verify payment information and select **Upgrade subscription**.
-
-> [!NOTE]
->
-> If you choose to pay using a US bank account, you must verify the account. For
-> more information, see [Verify a bank account](manuals/billing/payment-method.md#verify-a-bank-account).
-
-The billing plans and usage page will now reflect your new annual plan details.
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-To change your billing cycle:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your avatar in the top-right corner.
-3. From the drop-down menu select **Billing**.
-4. In the bottom-right of the **Plan** tab, select **Switch to annual billing**.
-5. Review the information displayed on the **Change to an Annual subscription** page and select **Accept Terms and Purchase** to confirm.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Organization
-
-> [!NOTE]
->
-> You must be an organization owner to make changes to the payment information.
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-To change your organization's billing cycle:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. On the plans and usage page, select **Switch to annual billing**.
-4. Verify your billing information.
-5. Select **Continue to payment**.
-6. Verify payment information and select **Upgrade subscription**.
-
-> [!NOTE]
->
-> If you choose to pay using a US bank account, you must verify the account. For
-> more information, see [Verify a bank account](manuals/billing/payment-method.md#verify-a-bank-account).
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-To change your organization's billing cycle:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select **My Hub** from the top-level navigation.
-3. Select the organization that you want to change the payment method for, and then select **Billing**.
-4. Select **Switch to annual billing**.
-5. Review the information displayed on the **Change to an Annual subscription** page and select **Accept Terms and Purchase** to confirm.
-
-{{< /tab >}}
-{{< /tabs >}}
\ No newline at end of file
diff --git a/content/manuals/billing/details.md b/content/manuals/billing/details.md
index 764888444065..817272f845df 100644
--- a/content/manuals/billing/details.md
+++ b/content/manuals/billing/details.md
@@ -1,173 +1,40 @@
 ---
-title: Update billing information
-weight: 30
-description: Learn how to update your billing information in Docker Hub
-keywords: payments, billing, subscription, invoices
+title: Update your billing details
+linkTitle: Update details
+weight: 40
+description: Learn how to update billing details, like contact information, addresses, and notification email for Docker subscriptions.
+keywords: payments, billing, subscription, invoices, update billing email, change billing address, Docker billing account
+aliases:
+  - /billing/cycle/
 ---
 
-You can update the billing information for your personal account or for an organization. When you update your billing information, these changes apply to future billing invoices. Note that you can't update an existing invoice, including paid and unpaid invoices.
+You can update your billing contact information, address, and notification email at any time. Existing invoices, whether paid or unpaid, cannot be updated. Changes only apply to future invoices.
 
-The billing information provided appears on all your billing invoices. The email address provided is where Docker sends all invoices and other [billing-related communication](#update-your-billing-invoice-email-address).
+## Update billing details
 
-{{% include "tax-compliance.md" %}}
+You can update your billing details for Docker individual accounts and Docker organization accounts using the same procedures.
 
-## Manage billing information
+To update your billing information from **Settings** in Docker Home:
 
-### Personal account
+1. Sign in to [Docker Home](https://app.docker.com/) and select your personal or organization
+   account.
+1. Select **Billing**, then go to **Settings**.
+1. Select **Edit** to make your changes.
+1. Verify your information, then select **Save as default**.
 
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
+For more information on changing your default payment method, see [Change default payment method](/manuals/billing/payment-method.md#change-default-payment-method).
 
-To update your billing information:
+## Billing notifications
 
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Select **Billing information** from the left-hand navigation.
-4. On your billing information card, select **Change**.
-5. Update your billing contact and billing address information.
-6. Optional. To add or update a VAT ID, select the **I'm purchasing as a business** checkbox and enter your Tax ID.
+Docker sends invoices and other billing-related communications
+to the billing account's email address. These communications include:
 
-    > [!IMPORTANT]
-    >
-    > Your VAT number must include your country prefix. For example, if you are
-    entering a VAT number for Germany, you would enter `DE123456789`.
+- Confirmations, such as new subscriptions, paid invoices
+- Notifications for card failure and card expiration errors
+- Reminders for subscription renewal
 
-7. Select **Update**.
+## Billing cycle
 
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-To update your billing information:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your avatar in the top-right corner.
-3. From the drop-down menu, select **Billing**.
-4. Select **Billing Address** and enter your updated billing information.
-5. Optional. To add or update a VAT ID, enter your **Tax ID/VAT**.
-
-    > [!IMPORTANT]
-    >
-    > Your VAT number must include your country prefix. For example, if you are
-    entering a VAT number for Germany, you would enter `DE123456789`.
-
-6. Select **Submit**.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Organization
-
-> [!NOTE]
->
-> You must be an organization owner to make changes to the billing information.
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-To update your billing information:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Select **Billing information** from the left-hand navigation.
-4. On your billing information card, select **Change**.
-5. Update your billing contact and billing address information.
-6. Optional. To add or update a VAT ID, select the **I'm purchasing as a business** checkbox and enter your Tax ID.
-
-    > [!IMPORTANT]
-    >
-    > Your VAT number must include your country prefix. For example, if you are
-    entering a VAT number for Germany, you would enter `DE123456789`.
-
-7. Select **Update**.
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-To update your billing information:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your avatar in the top-right corner.
-3. From the drop-down menu select **Billing**.
-4. Select the organization that you want to change the payment method for.
-5. Select **Billing Address**.
-6. Optional. To add or update a VAT ID, enter your **Tax ID/VAT**.
-
-    > [!IMPORTANT]
-    >
-    > Your VAT number must include your country prefix. For example, if you are
-    entering a VAT number for Germany, you would enter `DE123456789`.
-
-7. Select **Submit**.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Update your billing invoice email address
-
-Docker sends the following billing-related emails:
-
-- Confirmation of a new subscription.
-- Confirmation of paid invoices.
-- Notifications of credit or debit card payment failures.
-- Notifications of credit or debit card expiration.
-- Confirmation of a cancelled subscription
-- Reminders of subscription renewals for annual subscribers. This is sent 14 days before the renewal date.
-
-You can update the email address that receives billing invoices at any time.
-
-### Personal account
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-To update your billing email address:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Select **Billing information** from the left-hand navigation.
-4. On your billing information card, select **Change**.
-5. Update your billing contact information and select **Update**.
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-To update your billing email address:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your avatar in the top-right corner.
-3. From the drop-down menu select **Billing**.
-4. Select **Billing Address**.
-5. Update the email address in the **Billing contact** section.
-6. Select **Submit**.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Organizations
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-To update your billing email address:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Select **Billing information** from the left-hand navigation.
-4. On your billing information card, select **Change**.
-5. Update your billing contact information and select **Update**.
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-To update your billing email address:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your avatar in the top-right corner.
-3. From the drop-down menu select **Billing**.
-4. Select the name of the organization.
-5. Select **Billing Address**.
-6. Update the email address in the **Billing contact** section.
-7. Select **Submit**.
-
-{{< /tab >}}
-{{< /tabs >}}
+Billing cycles are defined on a per-plan basis. Depending on the product you
+subscribe to, your cycle can be monthly, annual, or another cadence. For
+plan-specific billing cycle details, see [Plans](/manuals/subscription/plans/_index.md).
diff --git a/content/manuals/billing/faqs.md b/content/manuals/billing/faqs.md
index d9212c8b50f7..2f7a9a838b9f 100644
--- a/content/manuals/billing/faqs.md
+++ b/content/manuals/billing/faqs.md
@@ -1,62 +1,63 @@
 ---
 title: Billing FAQs
 linkTitle: FAQs
-description: Frequently asked questions related to billing
-keywords: billing, renewal, payments, faq
+description: Find answers to common questions about Docker billing, failed payments, taxes, and pay by invoice.
+keywords: billing, renewal, failed payments, sales tax, VAT, academic pricing, pay by invoice
 tags: [FAQ]
-weight: 60
+weight: 80
 ---
 
-### What credit and debit cards are supported?
+## What happens if my subscription payment fails?
 
-- Visa
-- MasterCard
-- American Express
-- Discover
-- JCB
-- Diners
-- UnionPay
-- Link
-- ACH transfer with a [verified](manuals/billing/payment-method.md#verify-a-bank-account) US bank account
-
-### What currency is supported?
-
-United States dollar (USD).
-
-### What happens if my subscription payment fails?
-
-If your subscription payment fails, there is a grace period of 15 days, including the due date. Docker retries to collect the payment 3 times using the following schedule:
+If your subscription payment fails, there is a grace period of 15 days,
+including the due date. Docker attempts to collect the payment three times using
+the following schedule:
 
 - 3 days after the due date
 - 5 days after the previous attempt
 - 7 days after the previous attempt
 
-Docker also sends an email notification `Action Required - Credit Card Payment Failed` with an attached unpaid invoice after each failed payment attempt.
+Docker also sends an email notification
+`Action Required - Credit Card Payment Failed` with an attached unpaid invoice
+after each failed payment attempt.
 
-Once the grace period is over and the invoice is still not paid, the subscription downgrades to a free plan and all paid features are disabled.
+If the invoice remains unpaid after the grace period, the
+subscription downgrades to a free subscription and all paid features are
+disabled.
 
-### Can I manually retry a failed payment?
+## Can I manually retry a failed payment?
 
-No. Docker retries failed payments on a [retry schedule](/manuals/billing/faqs.md#what-happens-if-my-subscription-payment-fails).
+Yes. If your payment fails, select **Pay now** to retry the payment through
+Stripe.
 
-To ensure a retired payment is successful, verify your default payment is
-updated. If you need to update your default payment method, see
-[Manage payment method](/manuals/billing/payment-method.md#manage-payment-method).
+Before retrying, verify that your default payment method is up to date. For
+instructions, see
+[Manage a payment method](/manuals/billing/payment-method.md#manage-payment-method).
 
-### Does Docker collect sales tax and/or VAT?
+## Does Docker collect sales tax and VAT?
 
-Docker began collecting sales tax on subscription fees for United States customers on July 1, 2024. For European customers, Docker will begin collecting VAT on March 1, 2025.
+Docker collects sales tax or VAT from the following customers:
 
-To ensure that tax assessments are correct, make sure that your billing information and VAT/Tax ID, if applicable, are updated. See [Update the billing information](/billing/details/).
+- For United States customers, Docker began collecting sales tax on
+  July 1, 2024.
+- For European customers, Docker began collecting VAT on March 1, 2025.
+- For United Kingdom customers, Docker began collecting VAT on May 1, 2025.
 
-### How do I certify my tax exempt status?
+To help ensure correct tax assessments, keep your
+[billing information](/manuals/billing/details.md) up to date. For details on
+adding a VAT number or submitting a US tax exemption certificate, see
+[Taxes](/manuals/billing/tax-certificate.md).
 
-If you're exempt from sales tax, you can [register a valid tax exemption certificate](./tax-certificate.md) with Docker's Support team. [Contact Support](https://hub.docker.com/support/contact) to get started.
+## Does Docker offer academic pricing?
 
-### Does Docker offer academic pricing?
+For academic pricing, contact the
+[Docker Sales Team](https://www.docker.com/company/contact).
 
-Contact the [Docker Sales Team](https://www.docker.com/company/contact).
+## Can I use pay by invoice for upgrades or additional seats?
 
-### Do I need to do anything at the end of my subscription term?
+No. Pay by invoice is only available for renewing annual subscriptions, not for
+purchasing upgrades or additional seats. You must use card payment or US bank
+accounts for these changes.
 
-No. All monthly and annual subscriptions are automatically renewed at the end of the term using the original form of payment.
\ No newline at end of file
+For a list of supported payment methods, see
+[Add or update a payment method](/manuals/billing/payment-method.md).
diff --git a/content/manuals/billing/history.md b/content/manuals/billing/history.md
index 20295cd3d19f..c56089369f3b 100644
--- a/content/manuals/billing/history.md
+++ b/content/manuals/billing/history.md
@@ -1,170 +1,79 @@
 ---
-title: View billing history
-weight: 40
-description: Discover how to view your billing history in Docker Hub
-keywords: payments, billing, subscription, invoices, renewals, invoice management, billing administration
+title: Billing and invoice history
+linkTitle: Invoice history
+weight: 60
+description: Learn how to view your Docker billing history, understand what's on an invoice, and pay by invoice.
+keywords: payments, billing, subscription, invoices, renewals, billing history, pay by invoice
 aliases:
-    - /billing/core-billing/history/
+  - /billing/core-billing/history/
 ---
 
-In this section, learn how you can view your billing history, manage your invoices, and verify your renewal date. All monthly and annual subscriptions are automatically renewed at the end of the term using the original form of payment.
+Docker issues an invoice each time a subscription to a Docker plan renews or changes. You can track invoices issued to your account so you can review the plans you've
+subscribed to over time, check payment status, and download records as
+needed.
 
-{{% include "tax-compliance.md" %}}
-
-## Invoices
-
-Your invoice includes the following:
-
-- Invoice number
-- Date of issue
-- Date due
-- Your "Bill to" information
-- Amount due (in USD)
-- Description of your order, quantity if applicable, unit price, and amount (in USD)
-
-The information listed in the **Bill to** section of your invoice is based on your billing information. Not all fields are required. The billing information includes the following:
-
-- Name (required): The name of the administrator or company
-- Email address (required): The email address that receives all billing-related emails for the account
-- Address (required)
-- Phone number
-- Tax ID or VAT
-
-You can’t make changes to a paid or unpaid billing invoice. When you update your billing information, this change won't update an existing invoice. If you need to update your billing information, make sure you do so before your subscription renewal date when your invoice is finalized. For more information, see [Update the billing information](details.md).
-
-### View renewal date
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-You receive your invoice when the subscription renews. To verify your renewal date, sign in to the [Docker Home Billing](https://app.docker.com/billing). Your renewal date and amount are displayed on your subscription plan card.
-
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-You receive your invoice when the subscription renews. To verify your renewal date:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your user avatar to open the drop-down menu.
-3. Select **Billing**.
-4. Select the user or organization account to view the billing details. Here you can find your renewal date and the renewal amount.
+## View billing history
 
-{{< /tab >}}
-{{< /tabs >}}
+Personal accounts and organization accounts use the same steps to view billing
+history. To view your billing history:
 
-### Include your VAT number on your invoice
+1. Sign in to [Docker Home](https://app.docker.com/) and select your personal
+   account or organization account.
+1. Select **Billing**, then **Invoices**.
+1. View an individual invoice by selecting:
+   - **Invoice number** to open invoice details in your browser
+   - **Download** to download a copy of your invoice.
 
 > [!NOTE]
 >
-> If the VAT number field is not available, complete the [Contact Support form](https://hub.docker.com/support/contact/). This field may need to be manually added.
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-To add or update your VAT number:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Select **Billing information** from the left-hand menu.
-4. Select **Change** on your billing information card.
-5. Ensure the **I'm purchasing as a business** checkbox is checked.
-6. Enter your VAT number in the Tax ID section.
-
-    > [!IMPORTANT]
-    >
-    > Your VAT number must include your country prefix. For example, if you are
-    entering a VAT number for Germany, you would enter `DE123456789`.
-
-7. Select **Update**.
-
-Your VAT number will be included on your next invoice.
+> If you want to view your organization account's
+> billing history, you must be an organization owner.
 
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
+## Understand your invoice
 
-To add or update your VAT number:
+Your invoice includes the following information:
 
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. For user accounts, Select your avatar in the top-right corner, then **Billing**. For organizations, select the name of the organization.
-3. Select the **Billing address** link.
-4. In the **Billing Information** section, select **Update information**.
-5. Enter your VAT number in the Tax ID section.
+| Invoice field  | Description                                                                                   |
+| -------------- | --------------------------------------------------------------------------------------------- |
+| Invoice number | A unique identifier for the invoice                                                           |
+| Date of issue  | The date Docker generated the invoice                                                         |
+| Due date       | The date your payment is due                                                                  |
+| Bill to        | Your billing name, address, and contact information                                           |
+| Line items     | The description, quantity (if applicable), unit price, and amount for each item on your order |
+| Subtotal       | The total amount before any discounts                                                         |
+| Total          | The subtotal after any discounts, matching the amount due                                     |
+| Amount due     | The total amount you owe, in USD                                                              |
+| Pay online     | A link to pay an unpaid invoice online                                                        |
 
-    > [!IMPORTANT]
-    >
-    > Your VAT number must include your country prefix. For example, if you are
-    entering a VAT number for Germany, you would enter `DE123456789`.
+The information in the **Bill to** section comes from your billing
+information.
 
-6. Select **Save**.
+- Not all fields are required.
+- You can't change a paid or unpaid invoice.
+- Updating your billing information
+  doesn't update an existing invoice.
 
-Your VAT number will be included on your next invoice.
+If you want different billing information reflected in your invoice, update your billing information before your renewal date, when
+Docker finalizes your invoice. For more information, see [Update billing information](details.md).
 
-{{< /tab >}}
-{{< /tabs >}}
+## View renewal date
 
-## View billing history
-
-You can view the billing history and download past invoices for a personal account or organization.
-
-### Personal account
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-To view billing history:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Select **Invoices** from the left-hand menu.
-4. Optional. Select the **Invoice number** to open invoice details.
-5. Optional. Select the **Download** button to download an invoice.
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-To view billing history:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your avatar in the top-right corner.
-3. From the drop-down menu select **Billing**.
-4. Select the **Payment methods and billing history** link.
-    You can find your past invoices in the **Invoice History** section.
-
-From here you can download an invoice.
+Renewal dates are set on a per-plan basis, so check each plan individually if you subscribe to more than one. Depending on the product, your billing cycle can be monthly, annual, or another cadence. For plan-specific renewal and billing cycle details, see [Plans](/manuals/subscription/plans/_index.md).
 
-{{< /tab >}}
-{{< /tabs >}}
+## Pay by invoice
 
-### Organization
-
-> [!NOTE]
+> [!TIP]
 >
-> You must be an owner of the organization to view the billing history.
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-To view billing history:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Select **Invoices** from the left-hand menu.
-4. Optional. Select the **invoice number** to open invoice details.
-5. Optional. Select the **download** button to download an invoice.
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-To view billing history:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your avatar in the top-right corner.
-3. From the drop-down menu select **Billing**.
-4. Select the **Payment methods and billing history** link.
-    You can find your past invoices in the **Invoice History** section.
-
-From here you can download an invoice.
-
-{{< /tab >}}
-{{< /tabs >}}
+> To pay by invoice,
+> [upgrade to a Docker Team or Docker Business plan](https://www.docker.com/pricing?ref=Docs&refAction=DocsBillingPaymentMethod)
+> and choose an annual subscription.
+
+Pay by invoice requires upfront payment for your first subscription period
+using a payment card or ACH bank transfer. At renewal, Docker emails you an
+invoice to pay manually instead of charging your default payment method.
+
+- To add pay by invoice as a payment method, contact your Docker sales
+  representative.
+- You can only pay by invoice by choosing it as a payment method when
+  subscribing to Docker Team or Docker Business plans.
+- Pay by invoice isn't available for subscription upgrades or changes.
diff --git a/content/manuals/billing/payment-method.md b/content/manuals/billing/payment-method.md
index f4c2ad3e2a96..6c6a64e274d7 100644
--- a/content/manuals/billing/payment-method.md
+++ b/content/manuals/billing/payment-method.md
@@ -1,219 +1,146 @@
 ---
 title: Add or update a payment method
+linkTitle: Payment methods
 weight: 20
-description: Learn how to add or update a payment method in Docker Hub
-keywords: payments, billing, subscription, supported payment methods, failed payments, coupons
-alisases:
-    - /billing/core-billing/payment-method/
+description: Learn how to manage cards, US bank accounts, Stripe Link, and pay by invoice for Docker subscriptions.
+keywords: payments, billing, subscription, payment methods, credit card, ACH, US bank account, Stripe Link, pay by invoice, failed payments
+aliases:
+  - /billing/core-billing/payment-method/
 ---
 
-This page describes how to add or update a payment method for your personal account or for an organization.
+Docker supports several payment methods for paid personal accounts and
+organizations. This page describes supported payment types, how to manage
+payments from [Docker Home](https://app.docker.com/), and how to set up pay by
+invoice.
 
-You can add a payment method or update your account's existing payment method at any time.
+## Supported payment types
 
-> [!IMPORTANT]
->
-> If you want to remove all payment methods, you must first downgrade your subscription to a free plan. See [Downgrade](../subscription/change.md).
-
-The following payment methods are supported:
+You can add or update a payment method at any time. All charges are in United
+States dollars (USD). Docker supports the following payment methods:
 
-- Cards
-  - Visa
-  - MasterCard
-  - American Express
-  - Discover
-  - JCB
-  - Diners
-  - UnionPay
-- Wallets
-  - Stripe Link
-- Bank accounts
-  - ACH transfer with a [verified](manuals/billing/payment-method.md#verify-a-bank-account) US bank account
+| Category      | Payment type                                                            |
+| ------------- | ----------------------------------------------------------------------- |
+| Cards         | Visa, MasterCard, American Express, Discover, JCB, Diners, UnionPay     |
+| Wallets       | Stripe Link                                                             |
+| Bank accounts | Automated Clearing House (ACH) transfer with a verified US bank account |
 
-All currency, for example the amount listed on your billing invoice, is in United States dollar (USD).
+Some payment methods require additional setup before changing it to your default payment method. For example:
 
-{{% include "tax-compliance.md" %}}
+- Verify a
+  [bank account](#verify-a-bank-account) before choosing it as a payment method.
+- Use an existing Stripe Link account, or enter your card information to set up
+  Stripe Link.
 
 ## Manage payment method
 
-### Personal account
+Paid personal accounts and organizations follow the same procedures to add,
+update, or remove payment methods.
 
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
+### Add payment method
 
-To add a payment method:
+You can add multiple payment methods in the billing portal. When you add a new payment method, you set it as a new default payment method.
 
 1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Select **Payment methods** from the left-hand menu.
-4. Select **Add payment method**.
-5. Enter your new payment information:
-    - If you are adding a card:
-        - Select **Card** and fill out the card information form.
-    - If you are adding a Link payment:
-        - Select **Secure, 1-click checkout with Link** and enter your Link **email address** and **phone number**.
-        - If you are not an existing Link customer, you must fill out the card information form to store a card for Link payments.
-    - If you are adding a bank account:
-        - Select **US bank account**.
-        - Verify your **Email** and **Full name**.
-        - If your bank is listed, select your bank's name.
-        - If your bank is not listed, select **Search for your bank**.
-        - To verify your bank account, see [Verify a bank account](manuals/billing/payment-method.md#verify-a-bank-account).
-6. Select **Add payment method**.
-7. Optional. You can set a new default payment method by selecting the **Set as default** action.
-8. Optional. You can remove non-default payment methods by selecting the **Delete** action.
-
-> [!NOTE]
->
-> If you want to set a US bank account as your default payment method, you must
-> verify the account first.
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-To add a payment method:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your avatar in the top-right corner.
-3. From the drop-down menu select **Billing**.
-4. Select the **Payment methods and billing history** link.
-5. In the **Payment method** section, select **Add payment method**.
-6. Enter your new payment information:
-    - If you are adding a card:
-        - Select **Card** and fill out the card information form.
-    - If you are adding a Link payment:
-        - Select **Secure, 1-click checkout with Link** and enter your Link **email address** and **phone number**.
-        - If you are not an existing Link customer, you must fill out the card information form to store a card for Link payments.
-7. Select **Add**.
-8. Select the **Actions** icon, then select **Make default** to ensure that your new payment method applies to all purchases and subscriptions.
-9. Optional. You can remove non-default payment methods by selecting the **Actions** icon. Then, select **Delete**.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Organization
-
-> [!NOTE]
->
-> You must be an organization owner to make changes to the payment information.
+1. Select your username for a personal account, or select your organization
+   name for an organization.
+1. Select **Billing** to go to the billing portal, then **Change** in the **Payment method** tile.
+1. From the **Change payment method** modal, choose to add a card, a US bank account, or a Stripe Link payment.
+   - To pay with a card, enter your card information.
+   - To pay with a US bank account, verify your **Email** and **Full name**.
+     - If your bank is listed, select your bank's name.
+     - If your bank is not listed, select **Search for your bank**.
+   - To pay through Stripe Link, select an existing payment method, then select
+     **Use this card**.
+1. For first-time setup, enter your billing information.
+1. Finish adding the payment method by selecting **Save as default**.
 
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
+### Change default payment method
 
-To add a payment method:
+After adding one or more payment methods, you can set one as a default method.
 
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Choose your organization from the top-left drop-down.
-4. Select **Payment methods** from the left-hand menu.
-5. Select **Add payment method**.
-6. Enter your new payment information:
-    - If you are adding a card:
-        - Select **Card** and fill out the card information form.
-    - If you are adding a Link payment:
-        - Select **Secure, 1-click checkout with Link** and enter your Link **email address** and **phone number**.
-        - If you are not an existing Link customer, you must fill out the card information form to store a card for Link payments.
-    - If you are adding a bank account:
-        - Select **US bank account**.
-        - Verify your **Email** and **Full name**.
-        - If your bank is listed, select your bank's name.
-        - If your bank is not listed, select **Search for your bank**.
-        - To verify your bank account, see [Verify a bank account](manuals/billing/payment-method.md#verify-a-bank-account).
-7. Select **Add payment method**.
-8. Select **Add payment method**.
-9. Optional. You can set a new default payment method by selecting the **Set as default** action.
-10. Optional. You can remove non-default payment methods by selecting the **Delete** action.
-
-> [!NOTE]
->
-> If you want to set a US bank account as your default payment method, you must
-> verify the account first.
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-To add a payment method:
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your avatar in the top-right corner.
-3. From the drop-down menu select **Billing**.
-4. Select the organization account you want to update.
-5. Select the **Payment methods and billing history** link.
-6. In the **Payment Method** section, select **Add payment method**.
-7. Enter your new payment information:
-    - If you are adding a card:
-        - Select **Card** and fill out the card information form.
-    - If you are adding a Link payment:
-        - Select **Secure, 1-click checkout with Link** and enter your Link **email address** and **phone number**.
-        - If you are not an existing Link customer, you must fill out the card information form to store a card for Link payments.
-8. Select **Add payment method**.
-9. Select the **Actions** icon, then select **Make default** to ensure that your new payment method applies to all purchases and subscriptions.
-10. Optional. You can remove non-default payment methods by selecting the **Actions** icon. Then, select **Delete**.
-
-{{< /tab >}}
-{{< /tabs >}}
+1. From **Billing**, go to the **Payment method** tile.
+1. Select **Change** to open the **Change payment method** modal, then select **Change** next to your current default method.
+1. Choose the payment method you want to set as default.
+1. Verify your information, then select **Save as default**.
 
-## Verify a bank account
+### Remove payment method
 
-There are two ways to verify a bank account as a payment method:
+You can only remove secondary payment methods. To remove a secondary payment method:
 
-- Instant verification: Docker supports several major banks for instant verification.
-- Manual verification: All other banks must be verified manually.
+1. From **Billing**, go to the **Payment method** tile.
+1. Select **Change** to open the **Change payment method** modal.
+1. Select the **Actions** menu next to the payment method you want to remove, then select **Remove**.
+1. Verify your billing details, then select **Save as default**.
 
-### Instant verification
+To remove your default payment method, first set a different payment method as default, or [downgrade to a free subscription](/manuals/subscription/plans/docker.md#cancel-a-docker-plan).
 
-To verify your bank account instantly, you must sign in to your bank account
-from the Docker billing flow:
+## Enable and disable pay by invoice
 
-1. Choose **US bank account** as your payment method.
-2. Verify your **Email** and **Full name**.
-3. If your bank is listed, select your bank's name or select **Search for your bank**.
-4. Sign in to your bank and review the terms and conditions. This agreement
-allows Docker to debit payments from your connected bank account.
-5. Select **Agree and continue**.
-6. Select an account to link and verify, and select **Connect account**.
+> [!TIP]
+> Do you need to pay by invoice? [Upgrade to a Docker Business or Docker Team plan](https://www.docker.com/pricing?ref=Docs&refAction=DocsBillingPaymentMethod) and choose the annual subscription.
 
-When the account is verified, you will see a success message in the pop-up modal.
+Pay by invoice requires you to pay upfront for your first subscription period using a payment card or ACH bank transfer. At renewal time, instead of automatic payment, you'll receive an invoice via
+email that you must pay manually.
 
-### Manual verification
+Follow these steps to enable or disable pay by invoice:
 
-To verify your bank account manually, you must enter the micro-deposit amount from your bank statement:
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization.
+2. Select **Billing**, then **Payment methods**.
+3. Select **Pay by invoice**, then select the pay by invoice toggle to enable or disable.
+4. Confirm your billing contact details. If you need to change them, select
+   **Change** and enter your new details.
 
+Pay by invoice is not available for
+subscription upgrades or changes.
+
+## Verify a bank account
+
+You can verify your bank account with instant verification for supported banks. You must sign in to your US bank account when adding your bank as a payment method:
+
+1. From **Billing**, go to the **Payment method** tile and select **Change**.
 1. Choose **US bank account** as your payment method.
-2. Verify your **Email** and **First and last name**.
-3. Select **Enter bank details manually instead**.
-4. Enter your bank details: **Routing number** and **Account number**.
-5. Select **Submit**.
-6. You will receive an email with instructions on how to manually verify.
+1. Verify your **Email** and **Full name**.
+1. Search for your bank, then select it to initiate the sign-in flow.
+1. Review the terms and conditions. This agreement
+   allows Docker to debit payments from your connected bank account.
+1. Select **Agree and continue**.
+1. Select an account to link and verify, then select **Connect account**.
 
-Manual verification uses micro-deposits. You should see a small deposit
-(e.g. $-0.01) in your bank account in 1-2 business days. Open your manual verification email and enter the amount of this deposit to verify your account.
+When the account is verified, a success message appears.
 
 ## Failed payments
 
-> [!NOTE]
->
-> You can't manually retry a failed payment. Docker will retry failed payments
-based on the retry schedule.
+If your payment fails, select **Pay now** to retry the payment through Stripe.
 
-If your subscription payment fails, there is a grace period of 15 days, including the due date. Docker retries to collect the payment 3 times using the following schedule:
+You have a grace period of 15 days, including the due date, when your payment
+fails. Docker attempts to collect the payment three times using the following
+schedule:
 
 - 3 days after the due date
 - 5 days after the previous attempt
 - 7 days after the previous attempt
 
-Docker also sends an email notification `Action Required - Credit Card Payment Failed` with an attached unpaid invoice after each failed payment attempt.
-
-Once the grace period is over and the invoice is still not paid, the subscription downgrades to a free plan and all paid features are disabled.
+Docker also sends an email notification
+`Action Required - Credit Card Payment Failed` with an attached unpaid invoice
+after each failed payment attempt.
 
-## Redeem a coupon
+If the invoice remains unpaid after the grace period, the
+subscription downgrades to a free subscription and all paid features are
+disabled.
 
-You can redeem a coupon for any paid Docker subscription.
+## Pay by invoice
 
-A coupon can be used when you:
-- Sign up to a new paid subscription from a free subscription
-- Upgrade an existing paid subscription
+> [!TIP]
+>
+> To pay by invoice,
+> [upgrade to a Docker Team or Docker Business plan](https://www.docker.com/pricing?ref=Docs&refAction=DocsBillingPaymentMethod)
+> and choose an annual subscription.
 
-You are asked to enter your coupon code when you confirm or enter your payment method.
+Pay by invoice requires upfront payment for your first subscription period
+using a payment card or ACH bank transfer. At renewal, Docker emails you an
+invoice to pay manually instead of charging your default payment method.
 
-If you use a coupon to pay for a subscription, when the coupon expires, your payment method is charged the full cost of your subscription. If you don't have a saved payment method, your account downgrades to a free subscription.
+- To add pay by invoice as a payment method, contact your Docker sales representative.
+- You can only pay by invoice by choosing it as a payment method when subscribing to Docker Team or Docker Business plans. 
+- Pay by invoice isn't available for subscription upgrades or changes.
diff --git a/content/manuals/billing/tax-certificate.md b/content/manuals/billing/tax-certificate.md
index 2d3ba9891ed4..6b6a83b58ab1 100644
--- a/content/manuals/billing/tax-certificate.md
+++ b/content/manuals/billing/tax-certificate.md
@@ -1,42 +1,91 @@
 ---
-title: Register a tax certificate
-description: Learn how to submit a tax exemption certificate for your Docker billing.
-keywords: billing, renewal, payments, tax
-weight: 50
+title: Sales tax exemption and VAT
+linkTitle: Taxes
+description: >
+  Learn how Docker collects sales tax and VAT, how to submit a US tax
+  exemption certificate, and how to add a VAT number at checkout.
+keywords:
+  billing, sales tax, VAT, tax exemption certificate, tax ID, VAT number,
+  United States tax exemption, Docker Support, billing portal
+weight: 70
 ---
 
-If you're a customer in the United States and you're exempt from sales tax, you can register a valid tax exemption certificate with Docker's Support team. If you're a global customer subject to VAT, make sure that you provide your [VAT number](/billing/history/#include-your-vat-number-on-your-invoice) including your VAT country prefix.
+Depending on your location, Docker may collect sales tax or VAT on your
+subscription. Tax relief is the same idea in both cases, but the process
+differs:
 
-{{% include "tax-compliance.md" %}}
+- United States customers request exemption by submitting a tax exemption
+  certificate through Docker Support. The billing portal has no self-serve
+  tax ID field for US customers.
+- Customers in VAT countries enter a tax ID or VAT number themselves when they
+  purchase a Docker plan.
 
-## Prerequisites
+## United States tax exemption
 
-Before you submit your tax exemption certificate, ensure the following.
+US customers submit a support ticket with a valid tax exemption certificate
+to receive tax-exempt status. Docker reviews the certificate and applies the
+exemption to your billing profile. You can apply for tax-exempt status:
 
-1. Your customer name matches the name on the exemption certificate
-2. Your tax exemption certificate specifies Docker Inc as the Seller or Vendor and all applicable information is filled out
-3. Your certificate is signed and dated, and the expiration date hasn't passed
-4. You have a valid Docker ID/namespace(s) of the accounts that you want to apply the tax exemption certificate to
+- Before you purchase, submit your certificate and wait for Docker to approve
+  it. After approval, you can purchase without sales tax.
+- If you were charged sales tax, open a support ticket to coordinate with
+  Docker Support on exempt status.
 
-## Contact information
+### Prerequisites
 
-You can use the following for Docker's contact information on your tax exemption certificate.
+Before submitting your certificate, confirm the following:
 
-Docker, Inc.  
-3790 El Camino Real #1052  
-Palo Alto, CA 94306  
+- Customer name matches the name on the certificate.
+- The certificate lists Docker, Inc. as the seller or vendor, with all
+  relevant fields completed.
+- The certificate is signed, dated, and not expired.
+- You've included the Docker ID or namespace(s) for all accounts the
+  certificate applies to.
+
+> [!TIP]
+>
+> You can use the same certificate for multiple namespaces when applicable.
+
+### Contact information
+
+Use the following contact information on your certificate:
+
+```text
+Docker, Inc.
+3790 El Camino Real #1052
+Palo Alto, CA 94306
 (415) 941-0376
+```
+
+### Submit a tax exemption certificate
+
+1. [Submit a Docker Support ticket](https://hub.docker.com/support/contact?topic=Billing&subtopic=Tax%20information)
+   to start the tax certificate registration process.
+1. Enter **Tax certificate** as the support ticket **Subject**.
+1. In the **Details** field, enter **Submitting a tax certificate**.
+1. Follow the instructions that appear for submitting a tax certificate.
+1. Complete all required fields on the support form.
+1. In the file upload section, add the tax certificate by dragging and dropping
+   the file, or selecting **Browse files**.
+1. Select **Submit**.
+
+Docker Support contacts you if additional information is required. Docker sends
+an email confirmation after applying the tax exemption status to your account.
+
+## Add a VAT number or tax ID
 
-## Register a tax certificate
+When you select a VAT-applicable country during checkout, a tax ID field
+appears. Customers in VAT countries enter their tax ID or VAT number
+during checkout without opening a support ticket.
 
-1. [Submit a Docker Support ticket](https://hub.docker.com/support/contact?topic=Billing&subtopic=Tax%20information) to initiate the process to register a tax certificate.
-2. Enter the required information.
-3. In the **Additional Information** field, list the Docker ID/namespace(s) of the accounts that you want to apply the tax exemption certificate to.
+Your VAT number must include your country prefix. For example, enter
+`DE123456789` for a German VAT number.
 
-   > [!TIP]
-   >
-   > You can list multiple namespaces that share the same tax exemption certificate, if applicable.
-4. Add the tax certificate from your system by dragging and dropping them onto the file area, or select the **Browse Files** button to open a file dialog.
-5. Select **Submit**.
+> [!NOTE]
+>
+> The tax ID field appears during checkout only when you select
+> **I'm purchasing as a business**. It doesn't appear when you edit an
+> existing payment method or billing details in billing settings.
 
-Docker's support team will reach out to you if any additional information is required. You'll receive an e-mail confirmation from Docker once your tax exemption status is applied to your account.
+Add a VAT number or tax ID when you
+[set up a new plan](/manuals/subscription/manage.md#set-up-a-new-plan).
\ No newline at end of file
diff --git a/content/manuals/build-cloud/_index.md b/content/manuals/build-cloud/_index.md
index f07c4bc1ed4e..80458665e99d 100644
--- a/content/manuals/build-cloud/_index.md
+++ b/content/manuals/build-cloud/_index.md
@@ -5,7 +5,7 @@ description: Find documentation on Docker Build Cloud to help you build your con
 keywords: build, cloud, cloud build, remote builder
 params:
   sidebar:
-    group: Products
+    group: Application development
 aliases:
   - /build/cloud/faq/
   - /build/cloud/
@@ -47,12 +47,7 @@ cache, and encryption in transit. That means there are no shared processes or
 data between cloud builders.
 
 > [!NOTE]
->
-> Docker Build Cloud is currently only available in the US East region. Users
-> in Europe and Asia may experience increased latency compared to users based
-> in North America.
->
-> Support for multi-region builders is on the roadmap.
+> Docker Build Cloud is only available in the US East region.
 
 ## Get Docker Build Cloud
 
@@ -61,12 +56,12 @@ To get started with Docker Build Cloud,
 to get access to Docker Build Cloud:
 
 - Users with a free Personal account can opt-in to a 7-day free trial, with the option
-to subscribe for access. To start your free trial, sign in to [Docker Build Cloud Dashboard](https://app.docker.com/build/) and follow the on-screen instructions.
+  to subscribe for access. To start your free trial, sign in to [Docker Build Cloud Dashboard](https://app.docker.com/build/) and follow the on-screen instructions.
 - All users with a paid Docker subscription have access to Docker Build Cloud included
-with their Docker suite of products. See [Docker subscriptions and features](/manuals/subscription/details.md) for more information.
+  with their Docker suite of products. See [Docker subscriptions and features](https://www.docker.com/pricing?ref=Docs&refAction=DocsBuildCloud) for more information.
 
 Once you've signed up and created a builder, continue by
 [setting up the builder in your local environment](./setup.md).
 
 For information about roles and permissions related to Docker Build Cloud, see
-[Roles and Permissions](/manuals/security/for-admins/roles-and-permissions.md#docker-build-cloud-permissions).
+[Roles and Permissions](/manuals/enterprise/security/roles-and-permissions/core-roles.md#docker-build-cloud).
diff --git a/content/manuals/build-cloud/builder-settings.md b/content/manuals/build-cloud/builder-settings.md
index a77402c7c45e..665fa99b05dc 100644
--- a/content/manuals/build-cloud/builder-settings.md
+++ b/content/manuals/build-cloud/builder-settings.md
@@ -6,17 +6,53 @@ keywords: build, cloud build, optimize, remote, local, cloud, registry, package
 
 The **Builder settings** page in Docker Build Cloud lets you configure disk allocation, private resource access, and firewall settings for your cloud builders in your organization. These configurations help optimize storage, enable access to private registries, and secure outbound network traffic.
 
-## Disk allocation
+## Storage and cache management
 
-The **Disk allocation** setting lets you control how much of the available storage is dedicated to the build cache. A lower allocation increases storage available for active builds.
+### Disk allocation
 
-To make disk allocation changes, navigate to **Builder settings** in Docker Build Cloud and then adjust the **Disk allocation** slider to specify the percentage of storage used for build caching.
+The **Disk allocation** setting lets you control how much of the available
+storage is dedicated to the build cache. A lower allocation increases
+storage available for active builds.
+
+To make disk allocation changes, navigate to **Builder settings** in Docker
+Build Cloud and then adjust the **Disk allocation** slider to specify the
+percentage of storage used for build caching.
 
 Any changes take effect immediately.
 
+### Build cache space
+
+Your subscription includes the following Build cache space:
+
+| Subscription | Build cache space |
+| ------------ | ----------------- |
+| Personal     | N/A               |
+| Pro          | 50GB              |
+| Team         | 100GB             |
+| Business     | 200GB             |
+
+### Multi-architecture storage allocation
+
+Docker Build Cloud automatically provisions builders for both amd64 and arm64 architectures. Your total build cache space is split equally between these
+two builders:
+
+- Pro (50GB total): 25GB for amd64 builder + 25GB for arm64 builder
+- Team (100GB total): 50GB for amd64 builder + 50GB for arm64 builder
+- Business (200GB total): 100GB for amd64 builder + 100GB for arm64 builder
+
+> [!IMPORTANT]
+>
+> If you only build for one architecture, be aware that your effective cache
+> space is half of your subscription's total allocation.
+
+### Get more build cache space
+
+To get more Build cache space, [upgrade your subscription](/manuals/subscription/manage.md#upgrade-plans).
+
 > [!TIP]
-> 
-> If you build very large images, consider allocating less storage for caching.
+>
+> If you build large images, consider allocating less storage for caching to
+> leave more space for active builds.
 
 ## Private resource access
 
@@ -26,7 +62,7 @@ For example, if your organization hosts a private [PyPI](https://pypi.org/) repo
 
 To enable your cloud builders to access your private resources, enter the host name and port of your private resource and then select **Add**.
 
-### Authentication 
+### Authentication
 
 If your internal artifacts require authentication, make sure that you
 authenticate with the repository either before or during the build. For
@@ -34,10 +70,9 @@ internal package repositories for npm or PyPI, use [build secrets](/manuals/buil
 to authenticate during the build. For internal OCI registries, use `docker
 login` to authenticate before building.
 
-Note that if you use a private registry that requires authentication, you will
-need to authenticate with `docker login` twice before building. This is because
-the cloud builder needs to authenticate with Docker to use the cloud builder,
-and then again to authenticate with the private registry.
+If you use a private registry that requires authentication, you need to
+authenticate twice before building: once to Docker Hub (to access Docker Build
+Cloud), and once to your private registry (to push/pull images).
 
 ```console
 $ echo $DOCKER_PAT | docker login docker.io -u <username> --password-stdin
@@ -50,7 +85,5 @@ $ docker build --builder <cloud-builder> --tag registry.example.com/<image> --pu
 Firewall settings let you restrict cloud builder egress traffic to specific IP addresses. This helps enhance security by limiting external network egress from the builder.
 
 1. Select the **Enable firewall: Restrict cloud builder egress to specific public IP address** checkbox.
-
 2. Enter the IP address you want to allow.
-
 3. Select **Add** to apply the restriction.
diff --git a/content/manuals/build-cloud/ci.md b/content/manuals/build-cloud/ci.md
index 71a709f30328..110853ecd513 100644
--- a/content/manuals/build-cloud/ci.md
+++ b/content/manuals/build-cloud/ci.md
@@ -29,30 +29,54 @@ See [Loading build results](./usage/#loading-build-results) for details.
 
 > [!NOTE]
 >
-> Builds on Docker Build Cloud have a timeout limit of two hours. Builds that
-> run for longer than two hours are automatically cancelled.
+> Builds on Docker Build Cloud have a timeout limit that depends on your
+> subscription plan. Builds that run for longer than your limit are
+> automatically cancelled.
 
-## CI platform examples
+## Setting up credentials for CI/CD
 
-### GitHub Actions
+To enable your CI/CD system to build and push images using Docker Build Cloud, provide both an access token and a username. The type of token and the username you use depend on your account type and permissions.
+
+- If you are an organization administrator or have permission to create [organization access tokens (OAT)](/manuals/enterprise/security/access-tokens.md), use an OAT and set `DOCKER_ACCOUNT` to your Docker Hub organization name.
+- If you do not have permission to create OATs or are using a personal account, use a [personal access token (PAT)](/security/access-tokens/) and set `DOCKER_ACCOUNT` to your Docker Hub username.
+
+### Creating access tokens
+
+#### For organization accounts
+
+If you are an organization administrator:
+
+- Create an [organization access token (OAT)](/manuals/enterprise/security/access-tokens.md). The token must have these permissions:
+    1. **cloud-connect** scope
+    2. **Read public repositories** permission
+    3. **Repository access** with **Image push** permission for the target repository:
+        - Expand the **Repository** drop-down.
+        - Select **Add repository** and choose your target repository.
+        - Set the **Image push** permission for the repository.
+
+If you are not an organization administrator:
+
+- Ask your organization administrator for an access token with the permissions listed above, or use a personal access token.
+
+#### For personal accounts
+
+- Create a [personal access token (PAT)](/security/access-tokens/) with the following permissions:
+   1. **Read & write** access.
+        - Note: Building with Docker Build Cloud only requires read access, but you need write access to push images to a Docker Hub repository.
+
+
+## CI platform examples
 
 > [!NOTE]
 >
-> Version 4.0.0 and later of `docker/build-push-action` and
-> `docker/bake-action` builds images with [provenance attestations by
-> default](/manuals/build/ci/github-actions/attestations.md#default-provenance). Docker
-> Build Cloud automatically attempts to load images to the local image store if
-> you don't explicitly push them to a registry.
+> In your CI/CD configuration, set the following variables/secrets:
+> - `DOCKER_ACCESS_TOKEN` — your access token (PAT or OAT). Use a secret to store the token.
+> - `DOCKER_ACCOUNT` — your Docker Hub organization name (for OAT) or username (for PAT)
+> - `CLOUD_BUILDER_NAME` — the name of the cloud builder you created in the [Docker Build Cloud Dashboard](https://app.docker.com/build/)
 >
-> This results in a conflicting scenario where if you build a tagged image
-> without pushing it to a registry, Docker Build Cloud attempts to load images
-> containing attestations. But the local image store on the GitHub runner
-> doesn't support attestations, and the image load fails as a result.
->
-> If you want to load images built with `docker/build-push-action` together
-> with Docker Build Cloud, you must disable provenance attestations by setting
-> `provenance: false` in the GitHub Action inputs (or in `docker-bake.hcl` if
-> you use Bake).
+> This ensures your builds authenticate correctly with Docker Build Cloud.
+
+### GitHub Actions
 
 ```yaml
 name: ci
@@ -67,27 +91,51 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
-          username: ${{ vars.DOCKER_USER }}
-          password: ${{ secrets.DOCKER_PAT }}
+          username: ${{ vars.DOCKER_ACCOUNT }}
+          password: ${{ secrets.DOCKER_ACCESS_TOKEN }}
       
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         with:
           driver: cloud
-          endpoint: "<ORG>/default"
-          install: true
+          endpoint: "${{ vars.DOCKER_ACCOUNT }}/${{ vars.CLOUD_BUILDER_NAME }}" # for example, "acme/default"
       
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
-          tags: "<IMAGE>"
+          tags: "<IMAGE>" # for example, "acme/my-image:latest"
           # For pull requests, export results to the build cache.
           # Otherwise, push to a registry.
           outputs: ${{ github.event_name == 'pull_request' && 'type=cacheonly' || 'type=registry' }}
 ```
 
+The example above uses `docker/build-push-action`, which automatically uses the
+builder set up by `setup-buildx-action`. If you need to use the `docker build`
+command directly instead, you have two options:
+
+- Use `docker buildx build` instead of `docker build`
+- Set the `BUILDX_BUILDER` environment variable to use the cloud builder:
+
+  ```yaml
+  - name: Set up Docker Buildx
+    id: builder
+    uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
+    with:
+      driver: cloud
+      endpoint: "${{ vars.DOCKER_ACCOUNT }}/${{ vars.CLOUD_BUILDER_NAME }}"
+
+  - name: Build
+    run: |
+      docker build .
+    env:
+      BUILDX_BUILDER: ${{ steps.builder.outputs.name }}
+  ```
+
+For more information about the `BUILDX_BUILDER` environment variable, see
+[Build variables](/manuals/build/building/variables.md#buildx_builder).
+
 ### GitLab
 
 ```yaml
@@ -97,7 +145,7 @@ default:
     - docker:24-dind
   before_script:
     - docker info
-    - echo "$DOCKER_PAT" | docker login --username "$DOCKER_USER" --password-stdin
+    - echo "$DOCKER_ACCESS_TOKEN" | docker login --username "$DOCKER_ACCOUNT" --password-stdin
     - |
       apk add curl jq
       ARCH=${CI_RUNNER_EXECUTABLE_ARCH#*/}
@@ -105,11 +153,12 @@ default:
       mkdir -vp ~/.docker/cli-plugins/
       curl --silent -L --output ~/.docker/cli-plugins/docker-buildx $BUILDX_URL
       chmod a+x ~/.docker/cli-plugins/docker-buildx
-    - docker buildx create --use --driver cloud ${DOCKER_ORG}/default
+    - docker buildx create --use --driver cloud ${DOCKER_ACCOUNT}/${CLOUD_BUILDER_NAME}
 
 variables:
   IMAGE_NAME: <IMAGE>
-  DOCKER_ORG: <ORG>
+  DOCKER_ACCOUNT: <DOCKER_ACCOUNT> # your Docker Hub organization name (or username when using a personal account)
+  CLOUD_BUILDER_NAME: <CLOUD_BUILDER_NAME> # the name of the cloud builder you created in the [Docker Build Cloud Dashboard](https://app.docker.com/build/)
 
 # Build multi-platform image and push to a registry
 build_push:
@@ -153,8 +202,8 @@ jobs:
           curl --silent -L --output ~/.docker/cli-plugins/docker-buildx $BUILDX_URL
           chmod a+x ~/.docker/cli-plugins/docker-buildx
 
-      - run: echo "$DOCKER_PAT" | docker login --username $DOCKER_USER --password-stdin
-      - run: docker buildx create --use --driver cloud "<ORG>/default"
+      - run: echo "$DOCKER_ACCESS_TOKEN" | docker login --username $DOCKER_ACCOUNT --password-stdin
+      - run: docker buildx create --use --driver cloud "${DOCKER_ACCOUNT}/${CLOUD_BUILDER_NAME}"
 
       - run: |
           docker buildx build \
@@ -176,8 +225,8 @@ jobs:
           curl --silent -L --output ~/.docker/cli-plugins/docker-buildx $BUILDX_URL
           chmod a+x ~/.docker/cli-plugins/docker-buildx
 
-      - run: echo "$DOCKER_PAT" | docker login --username $DOCKER_USER --password-stdin
-      - run: docker buildx create --use --driver cloud "<ORG>/default"
+      - run: echo "$DOCKER_ACCESS_TOKEN" | docker login --username $DOCKER_ACCOUNT --password-stdin
+      - run: docker buildx create --use --driver cloud "${DOCKER_ACCOUNT}/${CLOUD_BUILDER_NAME}"
 
       - run: |
           docker buildx build \
@@ -208,7 +257,7 @@ Add the following `environment` hook agent's hook directory:
 set -euo pipefail
 
 if [[ "$BUILDKITE_PIPELINE_NAME" == "build-push-docker" ]]; then
- export DOCKER_PAT="<DOCKER_PERSONAL_ACCESS_TOKEN>"
+ export DOCKER_ACCESS_TOKEN="<DOCKER_ACCESS_TOKEN>"
 fi
 ```
 
@@ -216,7 +265,8 @@ Create a `pipeline.yml` that uses the `docker-login` plugin:
 
 ```yaml
 env:
-  DOCKER_ORG: <ORG>
+  DOCKER_ACCOUNT: <DOCKER_ACCOUNT> # your Docker Hub organization name (or username when using a personal account)
+  CLOUD_BUILDER_NAME: <CLOUD_BUILDER_NAME> # the name of the cloud builder you created in the [Docker Build Cloud Dashboard](https://app.docker.com/build/)
   IMAGE_NAME: <IMAGE>
 
 steps:
@@ -224,8 +274,8 @@ steps:
     key: build-push
     plugins:
       - docker-login#v2.1.0:
-          username: <DOCKER_USER>
-          password-env: DOCKER_PAT # the variable name in the environment hook
+          username: DOCKER_ACCOUNT
+          password-env: DOCKER_ACCESS_TOKEN # the variable name in the environment hook
 ```
 
 Create the `build.sh` script:
@@ -254,7 +304,7 @@ curl --silent -L --output $DOCKER_DIR/cli-plugins/docker-buildx $BUILDX_URL
 chmod a+x ~/.docker/cli-plugins/docker-buildx
 
 # Connect to your builder and set it as the default builder
-docker buildx create --use --driver cloud "$DOCKER_ORG/default"
+docker buildx create --use --driver cloud "${DOCKER_ACCOUNT}/${CLOUD_BUILDER_NAME}"
 
 # Cache-only image build
 docker buildx build \
@@ -279,9 +329,9 @@ pipeline {
 
   environment {
     ARCH = 'amd64'
-    DOCKER_PAT = credentials('docker-personal-access-token')
-    DOCKER_USER = credentials('docker-username')
-    DOCKER_ORG = '<ORG>'
+    DOCKER_ACCESS_TOKEN = credentials('docker-access-token')
+    DOCKER_ACCOUNT = credentials('docker-account')
+    CLOUD_BUILDER_NAME = '<CLOUD_BUILDER_NAME>'
     IMAGE_NAME = '<IMAGE>'
   }
 
@@ -294,8 +344,8 @@ pipeline {
         sh 'mkdir -vp ~/.docker/cli-plugins/'
         sh 'curl --silent -L --output ~/.docker/cli-plugins/docker-buildx $BUILDX_URL'
         sh 'chmod a+x ~/.docker/cli-plugins/docker-buildx'
-        sh 'echo "$DOCKER_PAT" | docker login --username $DOCKER_USER --password-stdin'
-        sh 'docker buildx create --use --driver cloud "$DOCKER_ORG/default"'
+        sh 'echo "$DOCKER_ACCESS_TOKEN" | docker login --username $DOCKER_ACCOUNT --password-stdin'
+        sh 'docker buildx create --use --driver cloud "${DOCKER_ACCOUNT}/${CLOUD_BUILDER_NAME}"'
         // Cache-only build
         sh 'docker buildx build --platform linux/amd64,linux/arm64 --tag "$IMAGE_NAME" --output type=cacheonly .'
         // Build and push a multi-platform image
@@ -317,10 +367,10 @@ services:
 
 env:
   global:
-    - IMAGE_NAME=username/repo
+    - IMAGE_NAME=<IMAGE> # for example, "acme/my-image:latest"
 
 before_install: |
-  echo "$DOCKER_PAT" | docker login --username "$DOCKER_USER" --password-stdin
+  echo "$DOCKER_ACCESS_TOKEN" | docker login --username "$DOCKER_ACCOUNT" --password-stdin
 
 install: |
   set -e 
@@ -328,7 +378,7 @@ install: |
   mkdir -vp ~/.docker/cli-plugins/
   curl --silent -L --output ~/.docker/cli-plugins/docker-buildx $BUILDX_URL
   chmod a+x ~/.docker/cli-plugins/docker-buildx
-  docker buildx create --use --driver cloud "<ORG>/default"
+  docker buildx create --use --driver cloud "${DOCKER_ACCOUNT}/${CLOUD_BUILDER_NAME}"
 
 script: |
   docker buildx build \
@@ -340,9 +390,8 @@ script: |
 ### BitBucket Pipelines 
 
 ```yaml
-# Prerequisites: $DOCKER_USER, $DOCKER_PAT setup as deployment variables
+# Prerequisites: $DOCKER_ACCOUNT, $CLOUD_BUILDER_NAME, $DOCKER_ACCESS_TOKEN setup as deployment variables
 # This pipeline assumes $BITBUCKET_REPO_SLUG as the image name
-# Replace <ORG> in the `docker buildx create` command with your Docker org
 
 image: atlassian/default-image:3
 
@@ -356,8 +405,8 @@ pipelines:
           - BUILDX_URL=$(curl -s https://raw.githubusercontent.com/docker/actions-toolkit/main/.github/buildx-lab-releases.json | jq -r ".latest.assets[] | select(endswith(\"linux-$ARCH\"))")
           - curl --silent -L --output ~/.docker/cli-plugins/docker-buildx $BUILDX_URL
           - chmod a+x ~/.docker/cli-plugins/docker-buildx
-          - echo "$DOCKER_PAT" | docker login --username $DOCKER_USER --password-stdin
-          - docker buildx create --use --driver cloud "<ORG>/default"
+          - echo "$DOCKER_ACCESS_TOKEN" | docker login --username $DOCKER_ACCOUNT --password-stdin
+          - docker buildx create --use --driver cloud "${DOCKER_ACCOUNT}/${CLOUD_BUILDER_NAME}"
           - IMAGE_NAME=$BITBUCKET_REPO_SLUG
           - docker buildx build
             --platform linux/amd64,linux/arm64
@@ -381,11 +430,11 @@ mkdir -vp ~/.docker/cli-plugins/
 curl --silent -L --output ~/.docker/cli-plugins/docker-buildx $BUILDX_URL
 chmod a+x ~/.docker/cli-plugins/docker-buildx
 
-# Login to Docker Hub. For security reasons $DOCKER_PAT should be a Personal Access Token. See https://docs.docker.com/security/for-developers/access-tokens/
-echo "$DOCKER_PAT" | docker login --username $DOCKER_USER --password-stdin
+# Login to Docker Hub with an access token. See https://docs.docker.com/build-cloud/ci/#creating-access-tokens
+echo "$DOCKER_ACCESS_TOKEN" | docker login --username $DOCKER_ACCOUNT --password-stdin
 
 # Connect to your builder and set it as the default builder
-docker buildx create --use --driver cloud "<ORG>/default"
+docker buildx create --use --driver cloud "${DOCKER_ACCOUNT}/${CLOUD_BUILDER_NAME}"
 
 # Cache-only image build
 docker buildx build \
@@ -426,11 +475,11 @@ curl --silent -L --output ~/.docker/cli-plugins/docker-compose $COMPOSE_URL
 chmod a+x ~/.docker/cli-plugins/docker-buildx
 chmod a+x ~/.docker/cli-plugins/docker-compose
 
-# Login to Docker Hub. For security reasons $DOCKER_PAT should be a Personal Access Token. See https://docs.docker.com/security/for-developers/access-tokens/
-echo "$DOCKER_PAT" | docker login --username $DOCKER_USER --password-stdin
+# Login to Docker Hub with an access token. See https://docs.docker.com/build-cloud/ci/#creating-access-tokens
+echo "$DOCKER_ACCESS_TOKEN" | docker login --username $DOCKER_ACCOUNT --password-stdin
 
 # Connect to your builder and set it as the default builder
-docker buildx create --use --driver cloud "<ORG>/default"
+docker buildx create --use --driver cloud "${DOCKER_ACCOUNT}/${CLOUD_BUILDER_NAME}"
 
 # Build the image build
 docker compose build
diff --git a/content/manuals/build-cloud/release-notes.md b/content/manuals/build-cloud/release-notes.md
index d37174d8fdf2..5786e5176e5d 100644
--- a/content/manuals/build-cloud/release-notes.md
+++ b/content/manuals/build-cloud/release-notes.md
@@ -9,6 +9,86 @@ tags: [Release notes]
 This page contains information about the new features, improvements, known
 issues, and bug fixes in Docker Build Cloud releases. 
 
+## 2026-08-03
+
+### Enhancements
+
+- Cloud builders now run BuildKit v0.32.1, upgraded from v0.20.0. This spans
+  twelve minor BuildKit releases of new build features, performance
+  improvements, and bug fixes. For the full list of changes, see the
+  [BuildKit release notes](https://github.com/moby/buildkit/releases).
+
+  This range includes the following changes to default behavior. Each of these
+  is an [exporter attribute](/manuals/build/exporters/image-registry.md) that
+  you pass with `--output`, or an
+  [attestation attribute](/manuals/build/metadata/attestations/_index.md) that
+  you pass with `--attest`:
+
+  - Image results now use OCI media types by default. If your registry doesn't
+    support OCI media types, build with
+    `--output type=image,oci-mediatypes=false`. Treat this as a temporary
+    measure until your registry supports OCI media types.
+  - Attestations now use OCI artifact descriptors by default. If your registry
+    doesn't support OCI artifacts, build with
+    `--output type=image,oci-artifact=false`. Note that the attribute is
+    singular.
+  - [Provenance attestations](/manuals/build/metadata/attestations/slsa-provenance.md)
+    now default to SLSA v1 instead of v0.2, which changes both the predicate
+    type and the schema. If you verify provenance in your CI pipeline, confirm
+    that your verifier supports the SLSA v1 predicate before your next build.
+    A verifier that doesn't recognize the new predicate type may report that no
+    attestation was found rather than failing outright, which can silently
+    weaken a supply chain check. To keep the previous format while you update
+    your tooling, build with `--attest type=provenance,version=v0.2`.
+
+- Docker Build Cloud is verified against Buildx v0.36.0, up from v0.21.0. Buildx
+  is the client you build with, and it's distributed with Docker Desktop and
+  Docker Engine rather than with Docker Build Cloud, so your client version
+  depends on how you installed Docker. For the client-side features available
+  when building with a cloud builder, see the
+  [Buildx release notes](https://github.com/docker/buildx/releases).
+
+## 2025-12-19
+
+### Bug fixes
+
+- Fixed an error when building
+  [Docker Hardened Images](/manuals/dhi/_index.md) with a cloud builder.
+- Fixed builds failing with gRPC message size errors when transferring large
+  amounts of data.
+- Fixed a 500 error when pulling images whose attestations or signatures are
+  resolved through the OCI referrers fallback, which registries use when they
+  don't implement the referrers API directly.
+
+## 2025-06-04
+
+### Enhancements
+
+- Build timeouts are now determined by your subscription plan rather than by a
+  single fixed limit applied to every build.
+
+## 2025-04-29
+
+### Enhancements
+
+- Improved build error messages. Failures caused by your Dockerfile or build
+  context are now reported as build errors rather than internal errors. This
+  includes denied base image pulls, invalid stage names, and invalid `chmod`
+  and `mkdir` targets.
+
+## 2025-04-09
+
+### Enhancements
+
+- Added a consolidated cloud usage report covering all builds in your
+  organization.
+
+## 2025-03-05
+
+### Enhancements
+
+- Build usage reports now support custom date ranges.
+
 ## 2025-02-24
 
 ### New
diff --git a/content/manuals/build-cloud/setup.md b/content/manuals/build-cloud/setup.md
index 57c2e366314d..88aca9d035b8 100644
--- a/content/manuals/build-cloud/setup.md
+++ b/content/manuals/build-cloud/setup.md
@@ -16,7 +16,8 @@ environment.
 To get started with Docker Build Cloud, you need to:
 
 - Download and install Docker Desktop version 4.26.0 or later.
-- Sign up for a Docker Build Cloud subscription in the [Docker Build Cloud Dashboard](https://app.docker.com/build/).
+- Create a cloud builder on the [Docker Build Cloud Dashboard](https://app.docker.com/build/).
+  - When you create the builder, choose a name for it (for example, `default`). You will use this name as `BUILDER_NAME` in the CLI steps below.
 
 ### Use Docker Build Cloud without Docker Desktop
 
@@ -44,15 +45,29 @@ command, or using the Docker Desktop settings GUI.
    $ docker login
    ```
 
-2. Add the cloud builder endpoint.
+2. Connect Buildx to your cloud builder.
 
    ```console
    $ docker buildx create --driver cloud <ORG>/<BUILDER_NAME>
    ```
 
-   Replace `ORG` with the Docker Hub namespace of your Docker organization.
+   Replace `<ORG>` with the Docker Hub namespace of your Docker organization (or your username if you are using a personal account), and `<BUILDER_NAME>` with the name you chose when creating the builder in the dashboard.
 
-This creates a builder named `cloud-ORG-BUILDER_NAME`.
+   This registers a local endpoint for the cloud builder named `cloud-ORG-BUILDER_NAME`.
+
+   > [!NOTE]
+   >
+   > This command connects Buildx to an existing Docker Build Cloud builder. It
+   > does not create a new cloud builder. To add a new builder, use the
+   > [Docker Build Cloud Dashboard](https://app.docker.com/build/).
+
+   > [!NOTE]
+   >
+   > If your organization is `acme` and you named your builder `default`, use:
+   >
+   > ```console
+   > $ docker buildx create --driver cloud acme/default
+   > ```
 
 {{< /tab >}}
 {{< tab name="Docker Desktop" >}}
diff --git a/content/manuals/build-cloud/usage.md b/content/manuals/build-cloud/usage.md
index 891bb7df9cf2..a6970aeceb16 100644
--- a/content/manuals/build-cloud/usage.md
+++ b/content/manuals/build-cloud/usage.md
@@ -45,11 +45,11 @@ Changing your default builder with `docker buildx use` only changes the default
 builder for the `docker buildx build` command. The `docker build` command still
 uses the `default` builder, unless you specify the `--builder` flag explicitly.
 
-If you use build scripts, such as `make`, we recommend that you update your
-build commands from `docker build` to `docker buildx build`, to avoid any
-confusion with regards to builder selection. Alternatively, you can run `docker
-buildx install` to make the default `docker build` command behave like `docker
-buildx build`, without discrepancies.
+If you use build scripts, such as `make`, that use the `docker build` command,
+we recommend updating your build commands to `docker buildx build`. Alternatively,
+you can set the [`BUILDX_BUILDER` environment
+variable](/manuals/build/building/variables.md#buildx_builder) to specify which
+builder `docker build` should use.
 
 ## Use with Docker Compose
 
@@ -144,7 +144,7 @@ The traffic is encrypted and secrets are never stored in the build cache.
 >
 > If you're misusing build arguments to pass credentials, authentication
 > tokens, or other secrets, you should refactor your build to pass the secrets using
-> [secret mounts](/reference/cli/docker/buildx/build.md#secret) instead.
+> [secret mounts](/reference/cli/docker/buildx/build/#secret) instead.
 > Build arguments are stored in the cache and their values are exposed through attestations.
 > Secret mounts don't leak outside of the build and are never included in attestations.
 
diff --git a/content/manuals/build/_index.md b/content/manuals/build/_index.md
index c4af3ceb1af8..c703c678dfb0 100644
--- a/content/manuals/build/_index.md
+++ b/content/manuals/build/_index.md
@@ -5,38 +5,38 @@ description: Get an overview of Docker Build to package and bundle your code and
 keywords: build, buildx, buildkit
 params:
   sidebar:
-    group: Open source
+    group: Application development
 grid:
 - title: Packaging your software
   description: 'Build and package your application to run it anywhere: locally or
     in the cloud.'
-  icon: inventory_2
+  icon: archive-box
   link: /build/concepts/overview/
 - title: Multi-stage builds
   description: Keep your images small and secure with minimal dependencies.
-  icon: stairs
+  icon: arrow-trending-up
   link: /build/building/multi-stage/
 - title: Multi-platform images
   description: Build, push, pull, and run images seamlessly on different computer
     architectures.
-  icon: content_copy
+  icon: document-duplicate
   link: /build/building/multi-platform/
 - title: BuildKit
   description: Explore BuildKit, the open source build engine.
-  icon: construction
+  icon: wrench-screwdriver
   link: /build/buildkit/
 - title: Build drivers
   description: Configure where and how you run your builds.
-  icon: engineering
+  icon: wrench-screwdriver
   link: /build/builders/drivers/
 - title: Exporters
   description: Export any artifact you like, not just Docker images.
-  icon: output
+  icon: arrow-up-on-square
   link: /build/exporters/
 - title: Build caching
   description: Avoid unnecessary repetitions of costly operations, such as package
     installs.
-  icon: cycle
+  icon: arrow-path
   link: /build/cache/
 - title: Bake
   description: Orchestrate your builds with Bake.
diff --git a/content/manuals/build/bake/_index.md b/content/manuals/build/bake/_index.md
index ee9e59453cdd..088609244c55 100644
--- a/content/manuals/build/bake/_index.md
+++ b/content/manuals/build/bake/_index.md
@@ -10,9 +10,9 @@ Bake is a feature of Docker Buildx that lets you define your build configuration
 using a declarative file, as opposed to specifying a complex CLI expression. It
 also lets you run multiple builds concurrently with a single invocation.
 
-A Bake file can be written in HCL, JSON, or YAML formats, where the YAML format
-is an extension of a Docker Compose file. Here's an example Bake file in HCL
-format:
+A Bake file can be written in HCL or JSON format. Bake can also build directly
+from a [Docker Compose file](./compose-file.md). Here's an example Bake file in
+HCL format:
 
 ```hcl {title=docker-bake.hcl}
 group "default" {
diff --git a/content/manuals/build/bake/compose-file.md b/content/manuals/build/bake/compose-file.md
index e142133828c9..7347fd32e41a 100644
--- a/content/manuals/build/bake/compose-file.md
+++ b/content/manuals/build/bake/compose-file.md
@@ -94,7 +94,7 @@ $ docker buildx bake --print
 
 The compose format has some limitations compared to the HCL format:
 
-- Specifying variables or global scope attributes is not yet supported
+- Specifying variables or global scope attributes is not supported
 - `inherits` service field is not supported, but you can use [YAML anchors](/reference/compose-file/fragments.md)
   to reference other services, as demonstrated in the previous example with `&build-dev`.
 
diff --git a/content/manuals/build/bake/contexts.md b/content/manuals/build/bake/contexts.md
index 6157b805b503..490b20a469d5 100644
--- a/content/manuals/build/bake/contexts.md
+++ b/content/manuals/build/bake/contexts.md
@@ -14,7 +14,7 @@ aliases:
 In addition to the main `context` key that defines the build context, each
 target can also define additional named contexts with a map defined with key
 `contexts`. These values map to the `--build-context` flag in the [build
-command](/reference/cli/docker/buildx/build.md#build-context).
+command](/reference/cli/docker/buildx/build/#build-context).
 
 Inside the Dockerfile these contexts can be used with the `FROM` instruction or
 `--from` flag.
@@ -68,6 +68,7 @@ name with `target:` prefix.
 ```dockerfile {title=baseapp.Dockerfile}
 FROM scratch
 ```
+
 ```dockerfile {title=Dockerfile}
 # syntax=docker/dockerfile:1
 FROM baseapp
@@ -89,104 +90,3 @@ target "app" {
 In most cases you should just use a single multi-stage Dockerfile with multiple
 targets for similar behavior. This case is only recommended when you have
 multiple Dockerfiles that can't be easily merged into one.
-
-## Deduplicate context transfer
-
-> [!NOTE]
->
-> As of Buildx version 0.17.0 and later, Bake automatically de-duplicates
-> context transfer for targets that share the same context. In addition to
-> Buildx version 0.17.0, the builder must be running BuildKit version 0.16.0 or
-> later, and the Dockerfile syntax must be `docker/dockerfile:1.10` or later.
->
-> If you meet these requirements, you don't need to manually de-duplicate
-> context transfer as described in this section.
->
-> - To check your Buildx version, run `docker buildx version`.
-> - To check your BuildKit version, run `docker buildx inspect --bootstrap` and
->   look for the `BuildKit version` field.
-> - To check your Dockerfile syntax version, check the `syntax`
->   [parser directive](/reference/dockerfile.md#syntax) in your Dockerfile. If
->   it's not present, the default version whatever comes bundled with your
->   current version of BuildKit. To set the version explicitly, add
->   `#syntax=docker/dockerfile:1.10` at the top of your Dockerfile.
-
-When you build targets concurrently, using groups, build contexts are loaded
-independently for each target. If the same context is used by multiple targets
-in a group, that context is transferred once for each time it's used. This can
-result in significant impact on build time, depending on your build
-configuration. For example, say you have a Bake file that defines the following
-group of targets:
-
-```hcl {title=docker-bake.hcl}
-group "default" {
-  targets = ["target1", "target2"]
-}
-
-target "target1" {
-  target = "target1"
-  context = "."
-}
-
-target "target2" {
-  target = "target2"
-  context = "."
-}
-```
-
-In this case, the context `.` is transferred twice when you build the default
-group: once for `target1` and once for `target2`.
-
-If your context is small, and if you are using a local builder, duplicate
-context transfers may not be a big deal. But if your build context is big, or
-you have a large number of targets, or you're transferring the context over a
-network to a remote builder, context transfer becomes a performance bottleneck.
-
-To avoid transferring the same context multiple times, you can define a named
-context that only loads the context files, and have each target that needs
-those files reference that named context. For example, the following Bake file
-defines a named target `ctx`, which is used by both `target1` and `target2`:
-
-```hcl {title=docker-bake.hcl}
-group "default" {
-  targets = ["target1", "target2"]
-}
-
-target "ctx" {
-  context = "."
-  target = "ctx"
-}
-
-target "target1" {
-  target = "target1"
-  contexts = {
-    ctx = "target:ctx"
-  }
-}
-
-target "target2" {
-  target = "target2"
-  contexts = {
-    ctx = "target:ctx"
-  }
-}
-```
-
-The named context `ctx` represents a Dockerfile stage, which copies the files
-from its context (`.`). Other stages in the Dockerfile can now reference the
-`ctx` named context and, for example, mount its files with `--mount=from=ctx`.
-
-```dockerfile {title=Dockerfile}
-FROM scratch AS ctx
-COPY --link . .
-
-FROM golang:alpine AS target1
-WORKDIR /work
-RUN --mount=from=ctx \
-    go build -o /out/client ./cmd/client \
-
-FROM golang:alpine AS target2
-WORKDIR /work
-RUN --mount=from=ctx \
-    go build -o /out/server ./cmd/server
-```
diff --git a/content/manuals/build/bake/expressions.md b/content/manuals/build/bake/expressions.md
index 71e7ef7de72e..05620f0866cc 100644
--- a/content/manuals/build/bake/expressions.md
+++ b/content/manuals/build/bake/expressions.md
@@ -62,7 +62,7 @@ target "default" {
   dockerfile="Dockerfile"
   tags = [
     "my-image:latest",
-    notequal("",TAG) ? "my-image:${TAG}": "",
+    notequal("",TAG) ? "my-image:${TAG}": ""
   ]
 }
 ```
diff --git a/content/manuals/build/bake/funcs.md b/content/manuals/build/bake/funcs.md
index 76a39b282514..e99236d63c7f 100644
--- a/content/manuals/build/bake/funcs.md
+++ b/content/manuals/build/bake/funcs.md
@@ -13,8 +13,9 @@ configuration in more complex ways than just concatenation or interpolation.
 
 ## Standard library
 
-Bake ships with built-in support for the [`go-cty` standard library functions](https://github.com/zclconf/go-cty/tree/main/cty/function/stdlib).
-The following example shows the `add` function.
+Bake ships with built-in support for the [standard library functions](/manuals/build/bake/stdlib.md).
+
+The following example shows the `add` function:
 
 ```hcl {title=docker-bake.hcl}
 variable "TAG" {
@@ -108,8 +109,6 @@ $ docker buildx bake --print webapp
 You can make references to [variables](./variables) and standard library
 functions inside your functions.
 
-You can't reference user-defined functions from other functions.
-
 The following example uses a global variable (`REPO`) in a custom function.
 
 ```hcl {title=docker-bake.hcl}
diff --git a/content/manuals/build/bake/introduction.md b/content/manuals/build/bake/introduction.md
index fcc035a9a8fa..e1387f2e6e0e 100644
--- a/content/manuals/build/bake/introduction.md
+++ b/content/manuals/build/bake/introduction.md
@@ -51,10 +51,11 @@ building images in a consistent way, with the same configuration.
 
 ## The Bake file format
 
-You can write Bake files in HCL, YAML (Docker Compose files), or JSON. In
-general, HCL is the most expressive and flexible format, which is why you'll
-see it used in most of the examples in this documentation, and in projects that
-use Bake.
+You can write Bake files in HCL or JSON. Bake can also read
+[Docker Compose files](./compose-file.md) and translate each service to a build
+target. HCL is the most expressive and flexible format, which is why you'll see
+it used in most of the examples in this documentation, and in projects that use
+Bake.
 
 The properties that can be set for a target closely resemble the CLI flags for
 `docker build`. For instance, consider the following `docker build` command:
@@ -87,7 +88,7 @@ target "myapp" {
 > [!TIP]
 >
 > Want a better editing experience for Bake files in VS Code?
-> Check out the [Docker VS Code Extension (Beta)](https://marketplace.visualstudio.com/items?itemName=docker.docker) for linting, code navigation, and vulnerability scanning.
+> Check out the [Docker DX](https://marketplace.visualstudio.com/items?itemName=docker.docker) extension for linting, code navigation, and vulnerability scanning.
 
 ## Next steps
 
diff --git a/content/manuals/build/bake/overrides.md b/content/manuals/build/bake/overrides.md
index ff051976a697..51ef54a9a76b 100644
--- a/content/manuals/build/bake/overrides.md
+++ b/content/manuals/build/bake/overrides.md
@@ -177,7 +177,7 @@ $ docker buildx bake -f docker-bake.hcl -f overrides.hcl --print
 ## Command line
 
 You can also override target configurations from the command line with the
-[`--set` flag](/reference/cli/docker/buildx/bake.md#set):
+[`--set` flag](/reference/cli/docker/buildx/bake/#set):
 
 ```hcl
 # docker-bake.hcl
@@ -212,6 +212,11 @@ $ docker buildx bake --set app.args.mybuildarg=bar --set app.platform=linux/arm6
 }
 ```
 
+> [!NOTE]
+>
+> `--set` is a repeatable flag. For array fields such as `tags`, repeat `--set` to provide multiple values or use the `+=` operator to append without replacing.
+> Array literal syntax like `--set target.tags=[a,b]` is not supported.
+
 Pattern matching syntax defined in [https://golang.org/pkg/path/#Match](https://golang.org/pkg/path/#Match)
 is also supported:
 
diff --git a/content/manuals/build/bake/remote-definition.md b/content/manuals/build/bake/remote-definition.md
index 15b1769f4acc..895850817f1f 100644
--- a/content/manuals/build/bake/remote-definition.md
+++ b/content/manuals/build/bake/remote-definition.md
@@ -176,7 +176,7 @@ and use the `cwd://` prefix for the metadata Bake file:
 
 ```yml
       - name: Build
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@{{% param "bake_action_version" %}}
         with:
           files: |
             ./docker-bake.hcl
diff --git a/content/manuals/build/bake/targets.md b/content/manuals/build/bake/targets.md
index 29c6a1d376b6..e7fc93ae3350 100644
--- a/content/manuals/build/bake/targets.md
+++ b/content/manuals/build/bake/targets.md
@@ -54,6 +54,18 @@ $ docker buildx bake
 The properties you can set for a target closely resemble the CLI flags for
 `docker build`, with a few additional properties that are specific to Bake.
 
+The `dockerfile` property specifies the path to the Dockerfile for a target.
+If you also set a `context`, the `dockerfile` path resolves relative to that
+context.
+
+```hcl {title=docker-bake.hcl}
+target "default" {
+  context = "app"
+  # resolves to app/src/www/Dockerfile
+  dockerfile = "src/www/Dockerfile"
+}
+```
+
 For all the properties you can set for a target, see the [Bake reference](/build/bake/reference#target).
 
 ## Grouping targets
@@ -81,8 +93,8 @@ target "api" {
 target "tests" {
   dockerfile = "tests.Dockerfile"
   contexts = {
-    webapp = "target:webapp",
-    api = "target:api",
+    webapp = "target:webapp"
+    api = "target:api"
   }
   output = ["type=local,dest=build/tests"]
   context = "."
@@ -96,6 +108,47 @@ command.
 $ docker buildx bake all
 ```
 
+## Pattern matching for targets and groups
+
+Bake supports shell-style wildcard patterns when specifying target or grouped targets.
+This makes it easier to build multiple targets without listing each one explicitly.
+
+Supported patterns:
+
+- `*` matches any sequence of characters
+- `?` matches any single character
+- `[abc]` matches any character in brackets
+
+> [!NOTE]
+>
+> Always wrap wildcard patterns in quotes. Without quotes, your shell will expand the
+> wildcard to match files in the current directory, causing errors.
+
+Examples:
+
+```console
+# Match all targets starting with 'foo-'
+$ docker buildx bake "foo-*"
+
+# Match all targets
+$ docker buildx bake "*"
+
+# Matches: foo-baz, foo-caz, foo-daz, etc.
+$ docker buildx bake "foo-?az"
+
+# Matches: foo-bar, boo-bar
+$ docker buildx bake "[fb]oo-bar"
+
+# Matches: mtx-a-b-d, mtx-a-b-e, mtx-a-b-f
+$ docker buildx bake "mtx-a-b-*"
+```
+
+You can also combine multiple patterns:
+
+```console
+$ docker buildx bake "foo*" "tests"
+```
+
 ## Additional resources
 
 Refer to the following pages to learn more about Bake's features:
diff --git a/content/manuals/build/bake/variables.md b/content/manuals/build/bake/variables.md
index e4861a5a7239..120c18b3e848 100644
--- a/content/manuals/build/bake/variables.md
+++ b/content/manuals/build/bake/variables.md
@@ -2,7 +2,7 @@
 title: Variables in Bake
 linkTitle: Variables
 weight: 40
-description: 
+description:
 keywords: build, buildx, bake, buildkit, hcl, variables
 ---
 
@@ -93,7 +93,7 @@ range, or other condition, you can define custom validation rules using the
 `validation` block.
 
 In the following example, validation is used to enforce a numeric constraint on
-a variable value; the `PORT` variable must be 1024 or higher.
+a variable value; the `PORT` variable must be 1024 or greater.
 
 ```hcl {title=docker-bake.hcl}
 # Define a variable `PORT` with a default value and a validation rule
@@ -103,7 +103,7 @@ variable "PORT" {
   # Validation block to ensure `PORT` is a valid number within the acceptable range
   validation {
     condition = PORT >= 1024  # Ensure `PORT` is at least 1024
-    error_message = "The variable 'PORT' must be 1024 or higher."  # Error message for invalid values
+    error_message = "The variable 'PORT' must be 1024 or greater."  # Error message for invalid values
   }
 }
 ```
diff --git a/content/manuals/build/builders/_index.md b/content/manuals/build/builders/_index.md
index ccb8d9a6202e..bc61ea2aaf12 100644
--- a/content/manuals/build/builders/_index.md
+++ b/content/manuals/build/builders/_index.md
@@ -78,27 +78,21 @@ older versions of the Docker CLI. The `docker buildx build` command, on the
 other hand, checks whether you've set a different builder as the default
 builder before it sends your build to BuildKit.
 
-To use the `docker build` command with a non-default builder, you must either:
+To use the `docker build` command with a non-default builder, you must either
+specify the builder explicitly:
 
-- Specify the builder explicitly, using the `--builder` flag or the `BUILDX_BUILDER` environment variable:
+- Using the `--builder` flag:
 
   ```console
-  $ BUILDX_BUILDER=my_builder docker build .
   $ docker build --builder my_builder .
   ```
 
-- Configure Buildx as the default client by running the following command:
+- Or the `BUILDX_BUILDER` environment variable:
 
   ```console
-  $ docker buildx install
+  $ BUILDX_BUILDER=my_builder docker build .
   ```
 
-  This updates your [Docker CLI configuration file](/reference/cli/docker/_index.md#configuration-files)
-  to ensure all of your build-related commands are routed via Buildx.
-
-  > [!TIP]
-  > To undo this change, run `docker buildx uninstall`.
-
 <!-- vale Docker.We = NO -->
 
 In general, we recommend that you use the `docker buildx build` command when
diff --git a/content/manuals/build/builders/drivers/_index.md b/content/manuals/build/builders/drivers/_index.md
index de4f772c6411..a90261ca451a 100644
--- a/content/manuals/build/builders/drivers/_index.md
+++ b/content/manuals/build/builders/drivers/_index.md
@@ -28,7 +28,7 @@ The following table outlines some differences between drivers.
 | Feature                      |  `docker`   | `docker-container` | `kubernetes` |      `remote`      |
 | :--------------------------- | :---------: | :----------------: | :----------: | :----------------: |
 | **Automatically load image** |     ✅      |                    |              |                    |
-| **Cache export**             |     ✓\*     |         ✅         |      ✅      |         ✅         |
+| **Cache export**             |     ✅\*     |         ✅         |      ✅      |         ✅         |
 | **Tarball output**           |             |         ✅         |      ✅      |         ✅         |
 | **Multi-arch images**        |             |         ✅         |      ✅      |         ✅         |
 | **BuildKit configuration**   |             |         ✅         |      ✅      | Managed externally |
diff --git a/content/manuals/build/builders/drivers/docker-container.md b/content/manuals/build/builders/drivers/docker-container.md
index 025db83eba5d..28ceb4508ec4 100644
--- a/content/manuals/build/builders/drivers/docker-container.md
+++ b/content/manuals/build/builders/drivers/docker-container.md
@@ -49,6 +49,7 @@ pass to `--driver-opt`:
 | `cgroup-parent`  | String  | `/docker/buildx` | Sets the cgroup parent of the container if Docker is using the "cgroupfs" driver.                                      |
 | `restart-policy` | String  | `unless-stopped` | Sets the container's [restart policy](/manuals/engine/containers/start-containers-automatically.md#use-a-restart-policy).      |
 | `env.<key>`      | String  |                  | Sets the environment variable `key` to the specified `value` in the container.                                         |
+| `provenance-add-gha`   | Boolean |    `true`       | Automatically writes GitHub Actions context into the builder for provenance.                                                   |
 
 Before you configure the resource limits for the container,
 read about [configuring runtime resource constraints for containers](/engine/containers/resource_constraints/).
@@ -133,14 +134,14 @@ $ docker buildx build \
 You can customize the network that the builder container uses. This is useful
 if you need to use a specific network for your builds.
 
-For example, let's [create a network](/reference/cli/docker/network/create.md)
+For example, let's [create a network](/reference/cli/docker/network/create/)
 named `foonet`:
 
 ```console
 $ docker network create foonet
 ```
 
-Now create a [`docker-container` builder](/reference/cli/docker/buildx/create.md)
+Now create a [`docker-container` builder](/reference/cli/docker/buildx/create/)
 that will use this network:
 
 ```console
@@ -150,13 +151,13 @@ $ docker buildx create --use \
   --driver-opt "network=foonet"
 ```
 
-Boot and [inspect `mybuilder`](/reference/cli/docker/buildx/inspect.md):
+Boot and [inspect `mybuilder`](/reference/cli/docker/buildx/inspect/):
 
 ```console
 $ docker buildx inspect --bootstrap
 ```
 
-[Inspect the builder container](/reference/cli/docker/inspect.md)
+[Inspect the builder container](/reference/cli/docker/inspect/)
 and see what network is being used:
 
 ```console
@@ -167,4 +168,4 @@ map[foonet:0xc00018c0c0]
 ## Further reading
 
 For more information on the Docker container driver, see the
-[buildx reference](/reference/cli/docker/buildx/create.md#driver).
+[buildx reference](/reference/cli/docker/buildx/create/#driver).
diff --git a/content/manuals/build/builders/drivers/docker.md b/content/manuals/build/builders/drivers/docker.md
index 91fe317c22b1..a01fb3161370 100644
--- a/content/manuals/build/builders/drivers/docker.md
+++ b/content/manuals/build/builders/drivers/docker.md
@@ -37,4 +37,4 @@ If you need additional configuration and flexibility, consider using the
 ## Further reading
 
 For more information on the Docker driver, see the
-[buildx reference](/reference/cli/docker/buildx/create.md#driver).
+[buildx reference](/reference/cli/docker/buildx/create/#driver).
diff --git a/content/manuals/build/builders/drivers/kubernetes.md b/content/manuals/build/builders/drivers/kubernetes.md
index 115bb73cfd4a..946e014fde81 100644
--- a/content/manuals/build/builders/drivers/kubernetes.md
+++ b/content/manuals/build/builders/drivers/kubernetes.md
@@ -30,29 +30,31 @@ $ docker buildx create \
 The following table describes the available driver-specific options that you
 can pass to `--driver-opt`:
 
-| Parameter                    | Type         | Default                                 | Description                                                                                                                          |
-| ---------------------------- | ------------ | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
-| `image`                      | String       |                                         | Sets the image to use for running BuildKit.                                                                                          |
-| `namespace`                  | String       | Namespace in current Kubernetes context | Sets the Kubernetes namespace.                                                                                                       |
-| `default-load`               | Boolean      | `false`                                 | Automatically load images to the Docker Engine image store.                                                                          |
-| `replicas`                   | Integer      | 1                                       | Sets the number of Pod replicas to create. See [scaling BuildKit][1]                                                                 |
-| `requests.cpu`               | CPU units    |                                         | Sets the request CPU value specified in units of Kubernetes CPU. For example `requests.cpu=100m` or `requests.cpu=2`                 |
-| `requests.memory`            | Memory size  |                                         | Sets the request memory value specified in bytes or with a valid suffix. For example `requests.memory=500Mi` or `requests.memory=4G` |
-| `requests.ephemeral-storage` | Storage size |                                         | Sets the request ephemeral-storage value specified in bytes or with a valid suffix. For example `requests.ephemeral-storage=2Gi`     |
-| `limits.cpu`                 | CPU units    |                                         | Sets the limit CPU value specified in units of Kubernetes CPU. For example `requests.cpu=100m` or `requests.cpu=2`                   |
-| `limits.memory`              | Memory size  |                                         | Sets the limit memory value specified in bytes or with a valid suffix. For example `requests.memory=500Mi` or `requests.memory=4G`   |
-| `limits.ephemeral-storage`   | Storage size |                                         | Sets the limit ephemeral-storage value specified in bytes or with a valid suffix. For example `requests.ephemeral-storage=100M`      |
-| `nodeselector`               | CSV string   |                                         | Sets the pod's `nodeSelector` label(s). See [node assignment][2].                                                                    |
-| `annotations`                | CSV string   |                                         | Sets additional annotations on the deployments and pods.                                                                             |
-| `labels`                     | CSV string   |                                         | Sets additional labels on the deployments and pods.                                                                                  |
-| `tolerations`                | CSV string   |                                         | Configures the pod's taint toleration. See [node assignment][2].                                                                     |
-| `serviceaccount`             | String       |                                         | Sets the pod's `serviceAccountName`.                                                                                                 |
-| `schedulername`              | String       |                                         | Sets the scheduler responsible for scheduling the pod.                                                                               |
-| `timeout`                    | Time         | `120s`                                  | Set the timeout limit that determines how long Buildx will wait for pods to be provisioned before a build.                           |
-| `rootless`                   | Boolean      | `false`                                 | Run the container as a non-root user. See [rootless mode][3].                                                                        |
-| `loadbalance`                | String       | `sticky`                                | Load-balancing strategy (`sticky` or `random`). If set to `sticky`, the pod is chosen using the hash of the context path.            |
-| `qemu.install`               | Boolean      | `false`                                 | Install QEMU emulation for multi platforms support. See [QEMU][4].                                                                   |
-| `qemu.image`                 | String       | `tonistiigi/binfmt:latest`              | Sets the QEMU emulation image. See [QEMU][4].                                                                                        |
+| Parameter                                  | Type         | Default                                 | Description                                                                                                                                                                                                   |
+| ------------------------------------------ | ------------ | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `image`                                    | String       |                                         | Sets the image to use for running BuildKit.                                                                                                                                                                   |
+| `namespace`                                | String       | Namespace in current Kubernetes context | Sets the Kubernetes namespace.                                                                                                                                                                                |
+| `default-load`                             | Boolean      | `false`                                 | Automatically load images to the Docker Engine image store.                                                                                                                                                   |
+| `replicas`                                 | Integer      | 1                                       | Sets the number of Pod replicas to create. See [scaling BuildKit][1]                                                                                                                                          |
+| `requests.cpu`                             | CPU units    |                                         | Sets the request CPU value specified in units of Kubernetes CPU. For example `requests.cpu=100m` or `requests.cpu=2`                                                                                          |
+| `requests.memory`                          | Memory size  |                                         | Sets the request memory value specified in bytes or with a valid suffix. For example `requests.memory=500Mi` or `requests.memory=4G`                                                                          |
+| `requests.ephemeral-storage`               | Storage size |                                         | Sets the request ephemeral-storage value specified in bytes or with a valid suffix. For example `requests.ephemeral-storage=2Gi`                                                                              |
+| `persistent-volume-claim.requests.storage` | Storage size |                                         | Sets the requested size for a persistent volume claim. When set, Buildx creates a `StatefulSet` and stores the BuildKit build cache in the claim. For example `persistent-volume-claim.requests.storage=20Gi` |
+| `limits.cpu`                               | CPU units    |                                         | Sets the limit CPU value specified in units of Kubernetes CPU. For example `requests.cpu=100m` or `requests.cpu=2`                                                                                            |
+| `limits.memory`                            | Memory size  |                                         | Sets the limit memory value specified in bytes or with a valid suffix. For example `requests.memory=500Mi` or `requests.memory=4G`                                                                            |
+| `limits.ephemeral-storage`                 | Storage size |                                         | Sets the limit ephemeral-storage value specified in bytes or with a valid suffix. For example `requests.ephemeral-storage=100M`                                                                               |
+| `buildkit-root-volume-memory`              | Memory size  | Using regular file system               | Mounts `/var/lib/buildkit` on an `emptyDir` memory-backed volume, with `SizeLimit` as the value. For example, `buildkit-root-folder-memory=6G`                                                                |
+| `nodeselector`                             | CSV string   |                                         | Sets the pod's `nodeSelector` label(s). See [node assignment][2].                                                                                                                                             |
+| `annotations`                              | CSV string   |                                         | Sets additional annotations on the `Deployment` or `StatefulSet` and pods.                                                                                                                                    |
+| `labels`                                   | CSV string   |                                         | Sets additional labels on the `Deployment` or `StatefulSet` and pods.                                                                                                                                         |
+| `tolerations`                              | CSV string   |                                         | Configures the pod's taint toleration. See [node assignment][2].                                                                                                                                              |
+| `serviceaccount`                           | String       |                                         | Sets the pod's `serviceAccountName`.                                                                                                                                                                          |
+| `schedulername`                            | String       |                                         | Sets the scheduler responsible for scheduling the pod.                                                                                                                                                        |
+| `timeout`                                  | Time         | `120s`                                  | Set the timeout limit that determines how long Buildx will wait for pods to be provisioned before a build.                                                                                                    |
+| `rootless`                                 | Boolean      | `false`                                 | Run the container as a non-root user. See [rootless mode][3].                                                                                                                                                 |
+| `loadbalance`                              | String       | `sticky`                                | Load-balancing strategy (`sticky` or `random`). If set to `sticky`, the pod is chosen using the hash of the context path.                                                                                     |
+| `qemu.install`                             | Boolean      | `false`                                 | Install QEMU emulation for multi platforms support. See [QEMU][4].                                                                                                                                            |
+| `qemu.image`                               | String       | `tonistiigi/binfmt:latest`              | Sets the QEMU emulation image. See [QEMU][4].                                                                                                                                                                 |
 
 [1]: #scaling-buildkit
 [2]: #node-assignment
@@ -74,8 +76,7 @@ is configurable using the following driver options:
 - `requests.cpu`, `requests.memory`, `requests.ephemeral-storage`, `limits.cpu`, `limits.memory`, `limits.ephemeral-storage`
 
   These options allow requesting and limiting the resources available to each
-  BuildKit pod according to the official Kubernetes documentation
-  [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
+  BuildKit pod [according to the official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
 
 For example, to create 4 replica BuildKit pods:
 
@@ -109,7 +110,28 @@ replicas. `sticky` (the default) attempts to connect the same build performed
 multiple times to the same node each time, ensuring better use of local cache.
 
 For more information on scalability, see the options for
-[`docker buildx create`](/reference/cli/docker/buildx/create.md#driver-opt).
+[`docker buildx create`](/reference/cli/docker/buildx/create/#driver-opt).
+
+## Persistent storage
+
+Set the `persistent-volume-claim.requests.storage` driver option to store the
+BuildKit build cache in a persistent volume claim instead of the pod
+filesystem.
+When you set this option, Buildx creates a `StatefulSet` instead of a
+`Deployment`.
+
+If you also set `replicas`, each replica gets its own persistent volume claim.
+This keeps the build cache local to each pod across restarts.
+
+For example, to create a builder with 20 GiB of persistent storage per replica:
+
+```console
+$ docker buildx create \
+  --bootstrap \
+  --name=kube \
+  --driver=kubernetes \
+  --driver-opt=namespace=buildkit,replicas=4,persistent-volume-claim.requests.storage=20Gi
+```
 
 ## Node assignment
 
@@ -118,7 +140,8 @@ using the `nodeSelector` and `tolerations` driver options.
 You can also set the `schedulername` option if you want to use a custom scheduler altogether.
 
 You can use the `annotations` and `labels` driver options to apply additional
-metadata to the deployments and pods that's hosting your builders.
+metadata to the `Deployment` or `StatefulSet` and the pods hosting your
+builders.
 
 The value of the `nodeSelector` parameter is a comma-separated string of
 key-value pairs, where the key is the node label and the value is the label
@@ -246,8 +269,8 @@ that you want to support.
 ## Rootless mode
 
 The Kubernetes driver supports rootless mode. For more information on how
-rootless mode works, and its requirements, see
-[here](https://github.com/moby/buildkit/blob/master/docs/rootless.md).
+rootless mode works, and its requirements, refer to the
+[Rootless Buildkit documentation](https://github.com/moby/buildkit/blob/master/docs/rootless.md).
 
 To turn it on in your cluster, you can use the `rootless=true` driver option:
 
@@ -349,4 +372,4 @@ That's it: you've now built an image from a Kubernetes pod, using Buildx.
 ## Further reading
 
 For more information on the Kubernetes driver, see the
-[buildx reference](/reference/cli/docker/buildx/create.md#driver).
+[buildx reference](/reference/cli/docker/buildx/create/#driver).
diff --git a/content/manuals/build/builders/drivers/remote.md b/content/manuals/build/builders/drivers/remote.md
index f002d49ea368..d059cdfdcc70 100644
--- a/content/manuals/build/builders/drivers/remote.md
+++ b/content/manuals/build/builders/drivers/remote.md
@@ -48,9 +48,9 @@ Unix socket, and have Buildx connect through it.
    $ sudo ./buildkitd --group $(id -gn) --addr unix://$HOME/buildkitd.sock
    ```
 
-   Alternatively, [see here](https://github.com/moby/buildkit/blob/master/docs/rootless.md)
-   for running buildkitd in rootless mode or [here](https://github.com/moby/buildkit/tree/master/examples/systemd)
-   for examples of running it as a systemd service.
+   Alternatively, refer to the [Rootless Buildkit documentation](https://github.com/moby/buildkit/blob/master/docs/rootless.md)
+   for running buildkitd in rootless mode, or [the BuildKit systemd examples](https://github.com/moby/buildkit/tree/master/examples/systemd)
+   for running it as a systemd service.
 
 2. Check that you have a Unix socket that you can connect to.
 
@@ -159,13 +159,13 @@ BuildKit manually. Additionally, when executing builds from inside Kubernetes
 pods, the Buildx builder will need to be recreated from within each pod or
 copied between them.
 
-1. Create a Kubernetes deployment of `buildkitd`, as per the instructions
-   [here](https://github.com/moby/buildkit/tree/master/examples/kubernetes).
+1. Create a Kubernetes deployment of `buildkitd` by following the instructions
+   [in the BuildKit documentation](https://github.com/moby/buildkit/tree/master/examples/kubernetes).
 
-   Following the guide, create certificates for the BuildKit daemon and client
-   using [create-certs.sh](https://github.com/moby/buildkit/blob/master/examples/kubernetes/create-certs.sh),
-   and create a deployment of BuildKit pods with a service that connects to
-   them.
+   Create certificates for the BuildKit daemon and client using the
+   [create-certs.sh](https://github.com/moby/buildkit/blob/master/examples/kubernetes/create-certs.sh),
+   script and create a deployment of BuildKit pods with a service that connects
+   to them.
 
 2. Assuming that the service is called `buildkitd`, create a remote builder in
    Buildx, ensuring that the listed certificate files are present:
diff --git a/content/manuals/build/builders/manage.md b/content/manuals/build/builders/manage.md
index 5039fa18e5ed..e3c5df846944 100644
--- a/content/manuals/build/builders/manage.md
+++ b/content/manuals/build/builders/manage.md
@@ -16,7 +16,7 @@ that use other drivers, such as the
 which runs the BuildKit daemon in a container.
 
 Use the
-[`docker buildx create`](/reference/cli/docker/buildx/create.md)
+[`docker buildx create`](/reference/cli/docker/buildx/create/)
 command to create a builder.
 
 ```console
@@ -100,7 +100,7 @@ Total:        2.01GB
 ## Remove a builder
 
 Use the
-[`docker buildx remove`](/reference/cli/docker/buildx/create.md)
+[`docker buildx remove`](/reference/cli/docker/buildx/create/)
 command to remove a builder.
 
 ```console
diff --git a/content/manuals/build/building/base-images.md b/content/manuals/build/building/base-images.md
index 2e11b0ba540b..85886a53839a 100644
--- a/content/manuals/build/building/base-images.md
+++ b/content/manuals/build/building/base-images.md
@@ -1,6 +1,6 @@
 ---
 title: Base images
-weight: 70
+weight: 80
 description: Learn about base images and how they're created
 keywords: images, base image, examples
 aliases:
@@ -99,20 +99,22 @@ the distribution you'd like to package as a base image, though that is
 not required for some tools like Debian's [Debootstrap](https://wiki.debian.org/Debootstrap),
 which you can also use to build Ubuntu images.
 
-For example, to create an Ubuntu base image:
+For example, to create an Ubuntu base image using the `noble` codename for
+Ubuntu 24.04, run the following commands. Replace `noble` with the codename
+for the Ubuntu release you want to import:
 
 ```dockerfile
-$ sudo debootstrap focal focal > /dev/null
-$ sudo tar -C focal -c . | docker import - focal
+$ sudo debootstrap noble noble > /dev/null
+$ sudo tar -C noble -c . | docker import - noble
 
 sha256:81ec9a55a92a5618161f68ae691d092bf14d700129093158297b3d01593f4ee3
 
-$ docker run focal cat /etc/lsb-release
+$ docker run noble cat /etc/lsb-release
 
 DISTRIB_ID=Ubuntu
-DISTRIB_RELEASE=20.04
-DISTRIB_CODENAME=focal
-DISTRIB_DESCRIPTION="Ubuntu 20.04 LTS"
+DISTRIB_RELEASE=24.04
+DISTRIB_CODENAME=noble
+DISTRIB_DESCRIPTION="Ubuntu 24.04.2 LTS"
 ```
 
 There are more example scripts for creating base images in
diff --git a/content/manuals/build/building/best-practices.md b/content/manuals/build/building/best-practices.md
index eb308bcf862a..f9485bb7f337 100644
--- a/content/manuals/build/building/best-practices.md
+++ b/content/manuals/build/building/best-practices.md
@@ -1,7 +1,7 @@
 ---
 title: Building best practices
 linkTitle: Best practices
-weight: 60
+weight: 70
 description: Hints, tips and guidelines for writing clean, reliable Dockerfiles
 keywords: base images, dockerfile, best practices, hub, official image
 tags: [Best practices]
@@ -45,17 +45,17 @@ The first step towards achieving a secure image is to choose the right base
 image. When choosing an image, ensure it's built from a trusted source and keep
 it small.
 
-- [Docker Official Images](https://hub.docker.com/search?image_filter=official)
+- [Docker Official Images](https://hub.docker.com/search?badges=official)
   are a curated collection that have clear documentation, promote best
   practices, and are regularly updated. They provide a trusted starting point
   for many applications.
 
-- [Verified Publisher](https://hub.docker.com/search?image_filter=store) images
+- [Verified Publisher](https://hub.docker.com/search?badges=verified_publisher) images
   are high-quality images published and maintained by the organizations
   partnering with Docker, with Docker verifying the authenticity of the content
   in their repositories.
 
-- [Docker-Sponsored Open Source](https://hub.docker.com/search?image_filter=open_source)
+- [Docker-Sponsored Open Source](https://hub.docker.com/search?badges=open_source)
   are published and maintained by open source projects sponsored by Docker
   through an [open source program](../../docker-hub/image-library/trusted-content.md#docker-sponsored-open-source-software-images).
 
@@ -77,23 +77,17 @@ dependencies can considerably lower the attack surface.
 
 ## Rebuild your images often
 
-Docker images are immutable. Building an image is taking a snapshot of that
-image at that moment. That includes any base images, libraries, or other
-software you use in your build. To keep your images up-to-date and secure, make
-sure to rebuild your image often, with updated dependencies.
+Docker images are immutable. Building an image is taking a snapshot of
+that image at that moment. That includes any base images, libraries, or
+other software you use in your build. To keep your images up-to-date and
+secure, rebuild your images regularly with updated dependencies.
 
-To ensure that you're getting the latest versions of dependencies in your build,
-you can use the `--no-cache` option to avoid cache hits.
+### Use --pull to get fresh base images
 
-```console
-$ docker build --no-cache -t my-image:my-tag .
-```
-
-The following Dockerfile uses the `24.04` tag of the `ubuntu` image. Over time,
-that tag may resolve to a different underlying version of the `ubuntu` image,
-as the publisher rebuilds the image with new security patches and updated
-libraries. Using the `--no-cache`, you can avoid cache hits and ensure a fresh
-download of base images and dependencies.
+The following Dockerfile uses the `24.04` tag of the `ubuntu` image.
+Over time, that tag may resolve to a different underlying version of the
+`ubuntu` image, as the publisher rebuilds the image with new security
+patches and updated libraries.
 
 ```dockerfile
 # syntax=docker/dockerfile:1
@@ -101,6 +95,35 @@ FROM ubuntu:24.04
 RUN apt-get -y update && apt-get install -y --no-install-recommends python3
 ```
 
+To get the latest version of the base image, use the `--pull` flag:
+
+```console
+$ docker build --pull -t my-image:my-tag .
+```
+
+The `--pull` flag forces Docker to check for and download a newer
+version of the base image, even if you have a version cached locally.
+
+### Use --no-cache for clean builds
+
+The `--no-cache` flag disables the build cache, forcing Docker to
+rebuild all layers from scratch:
+
+```console
+$ docker build --no-cache -t my-image:my-tag .
+```
+
+This gets the latest available versions of dependencies from package
+managers like `apt-get` or `npm`. It does not pull a fresh base image —
+for that, use `--pull`.
+
+The two flags serve distinct purposes and can be combined. Use both
+together to get a fresh base image and re-execute all build steps:
+
+```console
+$ docker build --pull --no-cache -t my-image:my-tag .
+```
+
 Also consider [pinning base image versions](#pin-base-image-versions).
 
 ## Exclude with .dockerignore
@@ -192,17 +215,17 @@ image. This is useful because it lets publishers update tags to point to
 newer versions of an image. And as an image consumer, it means you
 automatically get the new version when you re-build your image.
 
-For example, if you specify `FROM alpine:3.19` in your Dockerfile, `3.19`
-resolves to the latest patch version for `3.19`.
+For example, if you specify `FROM alpine:3.21` in your Dockerfile, `3.21`
+resolves to the latest patch version for `3.21`.
 
 ```dockerfile
 # syntax=docker/dockerfile:1
-FROM alpine:3.19
+FROM alpine:3.21
 ```
 
-At one point in time, the `3.19` tag might point to version 3.19.1 of the
+At one point in time, the `3.21` tag might point to version 3.21.1 of the
 image. If you rebuild the image 3 months later, the same tag might point to a
-different version, such as 3.19.4. This publishing workflow is best practice,
+different version, such as 3.21.4. This publishing workflow is best practice,
 and most publishers use this tagging strategy, but it isn't enforced.
 
 The downside with this is that you're not guaranteed to get the same for every
@@ -213,16 +236,16 @@ To fully secure your supply chain integrity, you can pin the image version to a
 specific digest. By pinning your images to a digest, you're guaranteed to
 always use the same image version, even if a publisher replaces the tag with a
 new image. For example, the following Dockerfile pins the Alpine image to the
-same tag as earlier, `3.19`, but this time with a digest reference as well.
+same tag as earlier, `3.21`, but this time with a digest reference as well.
 
 ```dockerfile
 # syntax=docker/dockerfile:1
-FROM alpine:3.19@sha256:13b7e62e8df80264dbb747995705a986aa530415763a6c58f84a3ca8af9a5bcd
+FROM alpine:3.21@sha256:a8560b36e8b8210634f77d9f7f9efd7ffa463e380b75e2e74aff4511df3ef88c
 ```
 
-With this Dockerfile, even if the publisher updates the `3.19` tag, your builds
+With this Dockerfile, even if the publisher updates the `3.21` tag, your builds
 would still use the pinned image version:
-`13b7e62e8df80264dbb747995705a986aa530415763a6c58f84a3ca8af9a5bcd`.
+`a8560b36e8b8210634f77d9f7f9efd7ffa463e380b75e2e74aff4511df3ef88c`.
 
 While this helps you avoid unexpected changes, it's also more tedious to have
 to look up and include the image digest for base image versions manually each
@@ -244,7 +267,7 @@ changes the version automatically, because you're in control and you have an
 audit trail of when and how the change occurred.
 
 For more information about automatically updating your base images with Docker
-Scout, see [Remediation](/manuals/scout/policy/remediation.md).
+Scout, see [Remediation](/manuals/scout/policy/dashboard.md).
 
 ## Build and test your images in CI
 
@@ -259,14 +282,14 @@ to create an efficient and maintainable Dockerfile.
 
 > [!TIP]
 >
-> Want a better editing experience for Dockerfiles in VS Code?
-> Check out the [Docker VS Code Extension (Beta)](https://marketplace.visualstudio.com/items?itemName=docker.docker) for linting, code navigation, and vulnerability scanning.
+> To improve linting, code navigation, and vulnerability scanning of your Dockerfiles in Visual Studio Code
+> see the [Docker DX](https://marketplace.visualstudio.com/items?itemName=docker.docker) extension.
 
 ### FROM
 
 Whenever possible, use current official images as the basis for your
 images. Docker recommends the [Alpine image](https://hub.docker.com/_/alpine/) as it
-is tightly controlled and small in size (currently under 6 MB), while still
+is tightly controlled and small in size (under 6 MB), while still
 being a full Linux distribution.
 
 For more information about the `FROM` instruction, see [Dockerfile reference for the FROM instruction](/reference/dockerfile.md#from).
@@ -442,7 +465,7 @@ reduces the image size, since the apt cache isn't stored in a layer. Since the
 `RUN` statement starts with `apt-get update`, the package cache is always
 refreshed prior to `apt-get install`.
 
-Official Debian and Ubuntu images [automatically run `apt-get clean`](https://github.com/moby/moby/blob/03e2923e42446dbb830c654d0eec323a0b4ef02a/contrib/mkimage/debootstrap#L82-L105), so explicit invocation is not required.
+Official Debian and Ubuntu images [automatically run `apt-get clean`](https://github.com/debuerreotype/debuerreotype/blob/c9542ab785e72696eb2908a6dbc9220abbabef39/scripts/debuerreotype-minimizing-config#L87-L109), so explicit invocation is not required.
 
 #### Using pipes
 
@@ -487,7 +510,7 @@ service, such as Apache and Rails, you would run something like `CMD
 for any service-based image.
 
 In most other cases, `CMD` should be given an interactive shell, such as bash,
-python and perl. For example, `CMD ["perl", "-de0"]`, `CMD ["python"]`, or `CMD
+Python and perl. For example, `CMD ["perl", "-de0"]`, `CMD ["python"]`, or `CMD
 ["php", "-a"]`. Using this form means that when you execute something like
 `docker run -it python`, you’ll get dropped into a usable shell, ready to go.
 `CMD` should rarely be used in the manner of `CMD ["param", "param"]` in
@@ -556,7 +579,7 @@ $ docker run --rm test sh -c 'echo $ADMIN_USER'
 mark
 ```
 
-To prevent this, and really unset the environment variable, use a `RUN` command
+To prevent this and unset the environment variable, use a `RUN` command
 with shell commands, to set, use, and unset the variable all in a single layer.
 You can separate your commands with `;` or `&&`. If you use the second method,
 and one of the commands fails, the `docker build` also fails. This is usually a
@@ -610,7 +633,7 @@ as part of your build. `ADD` is better than manually adding files using
 something like `wget` and `tar`, because it ensures a more precise build cache.
 `ADD` also has built-in support for checksum validation of the remote
 resources, and a protocol for parsing branches, tags, and subdirectories from
-[Git URLs](/reference/cli/docker/buildx/build.md#git-repositories).
+[Git URLs](/reference/cli/docker/buildx/build/).
 
 The following example uses `ADD` to download a .NET installer. Combined with
 multi-stage builds, only the .NET runtime remains in the final stage, no
@@ -639,10 +662,10 @@ RUN ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet
 ```
 
 For more information about `ADD` or `COPY`, see the following:
+
 - [Dockerfile reference for the ADD instruction](/reference/dockerfile.md#add)
 - [Dockerfile reference for the COPY instruction](/reference/dockerfile.md#copy)
 
-
 ### ENTRYPOINT
 
 The best use for `ENTRYPOINT` is to set the image's main command, allowing that
@@ -679,7 +702,7 @@ For example, the [Postgres Official Image](https://hub.docker.com/_/postgres/)
 uses the following script as its `ENTRYPOINT`:
 
 ```bash
-#!/bin/bash
+#!/bin/sh
 set -e
 
 if [ "$1" = 'postgres' ]; then
@@ -695,8 +718,7 @@ fi
 exec "$@"
 ```
 
-
-This script uses [the `exec` Bash command](https://wiki.bash-hackers.org/commands/builtin/exec) so that the final running application becomes the container's PID 1. This allows the application to receive any Unix signals sent to the container. For more information, see the [`ENTRYPOINT` reference](/reference/dockerfile.md#entrypoint).
+This script uses [the `exec` builtin](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#exec) so that the final running application becomes the container's PID 1. This allows the application to receive any Unix signals sent to the container. For more information, see the [`ENTRYPOINT` reference](/reference/dockerfile.md#entrypoint).
 
 In the following example, a helper script is copied into the container and run via `ENTRYPOINT` on
 container start:
@@ -763,7 +785,7 @@ RUN groupadd -r postgres && useradd --no-log-init -r -g postgres postgres
 > with a significantly large UID inside a Docker container can lead to disk
 > exhaustion because `/var/log/faillog` in the container layer is filled with
 > NULL (\0) characters. A workaround is to pass the `--no-log-init` flag to
-> useradd. The Debian/Ubuntu `adduser` wrapper does not support this flag.
+> `useradd`. The Debian/Ubuntu `adduser` wrapper does not support this flag.
 
 Avoid installing or using `sudo` as it has unpredictable TTY and
 signal-forwarding behavior that can cause problems. If you absolutely need
@@ -778,11 +800,11 @@ For more information about `USER`, see [Dockerfile reference for the USER instru
 ### WORKDIR
 
 For clarity and reliability, you should always use absolute paths for your
-`WORKDIR`. Also, you should use `WORKDIR` instead of  proliferating instructions
+`WORKDIR`. Also, you should use `WORKDIR` instead of proliferating instructions
 like `RUN cd … && do-something`, which are hard to read, troubleshoot, and
 maintain.
 
-For more information about `WORKDIR`, see [Dockerfile reference for the WORKDIR instruction](/reference/dockerfile.md#workdir).
+For more information about `WORKDIR`, see [Dockerfile reference for the `WORKDIR` instruction](/reference/dockerfile.md#workdir).
 
 ### ONBUILD
 
@@ -802,7 +824,7 @@ Dockerfile, as you can see in [Ruby’s `ONBUILD` variants](https://github.com/d
 Images built with `ONBUILD` should get a separate tag. For example,
 `ruby:1.9-onbuild` or `ruby:2.0-onbuild`.
 
-Be careful when putting `ADD` or `COPY` in `ONBUILD`. The onbuild image
+Be careful when putting `ADD` or `COPY` in `ONBUILD`. The image
 fails catastrophically if the new build's context is missing the resource being
 added. Adding a separate tag, as recommended above, helps mitigate this by
 allowing the Dockerfile author to make a choice.
diff --git a/content/manuals/build/building/cdi.md b/content/manuals/build/building/cdi.md
new file mode 100644
index 000000000000..ce459f15e1b1
--- /dev/null
+++ b/content/manuals/build/building/cdi.md
@@ -0,0 +1,540 @@
+---
+title: Container Device Interface (CDI)
+weight: 60
+description: Using CDI to access GPUs and other devices in your builds
+keywords: build, buildkit, buildx, guide, tutorial, cdi, device, gpu, nvidia, cuda, amd, rocm
+---
+
+<!-- vale Docker.We = NO -->
+
+The [Container Device Interface (CDI)](https://github.com/cncf-tags/container-device-interface/blob/main/SPEC.md)
+is a specification designed to standardize how devices (like GPUs, FPGAs, and
+other hardware accelerators) are exposed to and used by containers. The aim is
+to provide a more consistent and secure mechanism for using hardware devices in
+containerized environments, addressing the challenges associated with
+device-specific setups and configurations.
+
+In addition to enabling the container to interact with the device node, CDI also
+lets you specify additional configuration for the device, such as environment
+variables, host mounts (such as shared objects), and executable hooks.
+
+## Getting started
+
+To get started with CDI, you need to have a compatible environment set up. This
+includes having Docker v27+ installed with [CDI configured](/reference/cli/dockerd.md#configure-cdi-devices)
+and Buildx v0.22+.
+
+You also need to create the [device specifications using JSON or YAML files](https://github.com/cncf-tags/container-device-interface/blob/main/SPEC.md#cdi-json-specification)
+in one of the following locations:
+
+* `/etc/cdi`
+* `/var/run/cdi`
+* `/etc/buildkit/cdi`
+
+> [!NOTE]
+> Location can be changed by setting the `specDirs` option in the `cdi` section
+> of the [`buildkitd.toml` configuration file](../buildkit/configure.md) if you
+> are using BuildKit directly. If you're building using the Docker Daemon with
+> the `docker` driver, see [Configure CDI devices](/reference/cli/dockerd.md#configure-cdi-devices)
+> documentation.
+
+> [!NOTE]
+> If you are creating a container builder on WSL, you need to ensure that
+> [Docker Desktop](../../desktop/_index.md) is installed and [WSL 2 GPU Paravirtualization](../../desktop/features/gpu.md#prerequisites)
+> is enabled. Buildx v0.27+ is also required to mount the WSL libraries in the
+> container.
+
+## Building with a simple CDI specification
+
+Let's start with a simple CDI specification that injects an environment variable
+into the build environment and write it to `/etc/cdi/foo.yaml`:
+
+```yaml {title="/etc/cdi/foo.yaml"}
+cdiVersion: "0.6.0"
+kind: "vendor1.com/device"
+devices:
+- name: foo
+  containerEdits:
+    env:
+    - FOO=injected
+```
+
+Inspect the `default` builder to verify that `vendor1.com/device` is detected
+as a device:
+
+```console
+$ docker buildx inspect
+Name:   default
+Driver: docker
+
+Nodes:
+Name:             default
+Endpoint:         default
+Status:           running
+BuildKit version: v0.23.2
+Platforms:        linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/amd64/v4, linux/386
+Labels:
+ org.mobyproject.buildkit.worker.moby.host-gateway-ip: 172.17.0.1
+Devices:
+ Name:                  vendor1.com/device=foo
+ Automatically allowed: false
+GC Policy rule#0:
+ All:            false
+ Filters:        type==source.local,type==exec.cachemount,type==source.git.checkout
+ Keep Duration:  48h0m0s
+ Max Used Space: 658.9MiB
+GC Policy rule#1:
+ All:            false
+ Keep Duration:  1440h0m0s
+ Reserved Space: 4.657GiB
+ Max Used Space: 953.7MiB
+ Min Free Space: 2.794GiB
+GC Policy rule#2:
+ All:            false
+ Reserved Space: 4.657GiB
+ Max Used Space: 953.7MiB
+ Min Free Space: 2.794GiB
+GC Policy rule#3:
+ All:            true
+ Reserved Space: 4.657GiB
+ Max Used Space: 953.7MiB
+ Min Free Space: 2.794GiB
+```
+
+Now let's create a Dockerfile to use this device:
+
+```dockerfile
+# syntax=docker/dockerfile:1-labs
+FROM busybox
+RUN --device=vendor1.com/device \
+  env | grep ^FOO=
+```
+
+Here we use the [`RUN --device` command](/reference/dockerfile.md#run---device)
+and set `vendor1.com/device` which requests the first device available in the
+specification. In this case it uses `foo`, which is the first device in
+`/etc/cdi/foo.yaml`.
+
+> [!NOTE]
+> [`RUN --device` command](/reference/dockerfile.md#run---device) is only
+> featured in [`labs` channel](../buildkit/frontend.md#labs-channel) since
+> [Dockerfile frontend v1.14.0-labs](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.14.0-labs)
+> and not yet available in stable syntax.
+
+Now let's build this Dockerfile:
+
+```console
+$ docker buildx build .
+[+] Building 0.4s (5/5) FINISHED                                                                                                        docker:default
+ => [internal] load build definition from Dockerfile                                                                                    0.0s 
+ => => transferring dockerfile: 155B                                                                                                    0.0s
+ => resolve image config for docker-image://docker/dockerfile:1-labs                                                                    0.1s 
+ => CACHED docker-image://docker/dockerfile:1-labs@sha256:9187104f31e3a002a8a6a3209ea1f937fb7486c093cbbde1e14b0fa0d7e4f1b5              0.0s
+ => [internal] load metadata for docker.io/library/busybox:latest                                                                       0.1s 
+ => [internal] load .dockerignore                                                                                                       0.0s
+ => => transferring context: 2B                                                                                                         0.0s 
+ERROR: failed to build: failed to solve: failed to load LLB: device vendor1.com/device=foo is requested by the build but not allowed
+```
+
+It fails because the device `vendor1.com/device=foo` is not automatically
+allowed by the build as shown in the `buildx inspect` output above:
+
+```text
+Devices:
+ Name:                  vendor1.com/device=foo
+ Automatically allowed: false
+```
+
+To allow the device, you can use the [`--allow` flag](/reference/cli/docker/buildx/build/#allow)
+with the `docker buildx build` command:
+
+```console
+$ docker buildx build --allow device .
+```
+
+Or you can set the `org.mobyproject.buildkit.device.autoallow` annotation in
+the CDI specification to automatically allow the device for all builds:
+
+```yaml {title="/etc/cdi/foo.yaml"}
+cdiVersion: "0.6.0"
+kind: "vendor1.com/device"
+devices:
+- name: foo
+  containerEdits:
+    env:
+    - FOO=injected
+annotations:
+  org.mobyproject.buildkit.device.autoallow: true
+```
+
+Now running the build again with the `--allow device` flag:
+
+```console
+$ docker buildx build --progress=plain --allow device .
+#0 building with "default" instance using docker driver
+
+#1 [internal] load build definition from Dockerfile
+#1 transferring dockerfile: 159B done
+#1 DONE 0.0s
+
+#2 resolve image config for docker-image://docker/dockerfile:1-labs
+#2 DONE 0.1s
+
+#3 docker-image://docker/dockerfile:1-labs@sha256:9187104f31e3a002a8a6a3209ea1f937fb7486c093cbbde1e14b0fa0d7e4f1b5
+#3 CACHED
+
+#4 [internal] load metadata for docker.io/library/busybox:latest
+#4 DONE 0.1s
+
+#5 [internal] load .dockerignore
+#5 transferring context: 2B done
+#5 DONE 0.0s
+
+#6 [1/2] FROM docker.io/library/busybox:latest@sha256:f85340bf132ae937d2c2a763b8335c9bab35d6e8293f70f606b9c6178d84f42b
+#6 CACHED
+
+#7 [2/2] RUN --device=vendor1.com/device   env | grep ^FOO=
+#7 0.155 FOO=injected
+#7 DONE 0.2s
+```
+
+The build is successful and the output shows that the `FOO` environment variable
+was injected into the build environment as specified in the CDI specification.
+
+## Set up a container builder with GPU support
+
+In this section, we will show you how to set up a [container builder](../builders/drivers/docker-container.md)
+using NVIDIA GPUs. Since Buildx v0.22, when creating a new container builder, a
+GPU request is automatically added to the container builder if the host has GPU
+drivers installed in the kernel. This is similar to using [`--gpus=all` with the `docker run`](/reference/cli/docker/container/run/#gpus)
+command.
+
+Now let's create a container builder named `gpubuilder` using Buildx:
+
+```console
+$ docker buildx create --name gpubuilder --driver-opt "image=moby/buildkit:buildx-stable-1-gpu" --bootstrap
+#1 [internal] booting buildkit
+#1 pulling image moby/buildkit:buildx-stable-1-gpu
+#1 pulling image moby/buildkit:buildx-stable-1-gpu 1.0s done
+#1 creating container buildx_buildkit_gpubuilder0
+#1 creating container buildx_buildkit_gpubuilder0 8.8s done
+#1 DONE 9.8s
+gpubuilder
+```
+
+> [!NOTE]
+> We made a specially crafted BuildKit image because the current BuildKit
+> release image is based on Alpine that doesn't support NVIDIA drivers. The
+> following image is based on Ubuntu and installs the NVIDIA client libraries
+> and generates the CDI specification for your GPU in the container builder if
+> a device is requested during a build.
+
+Let's inspect this builder:
+
+```console
+$ docker buildx inspect gpubuilder
+Name:          gpubuilder
+Driver:        docker-container
+Last Activity: 2025-07-10 08:18:09 +0000 UTC
+
+Nodes:
+Name:                  gpubuilder0
+Endpoint:              unix:///var/run/docker.sock
+Driver Options:        image="moby/buildkit:buildx-stable-1-gpu"
+Status:                running
+BuildKit daemon flags: --allow-insecure-entitlement=network.host
+BuildKit version:      v0.26.2
+Platforms:             linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
+Labels:
+ org.mobyproject.buildkit.worker.executor:         oci
+ org.mobyproject.buildkit.worker.hostname:         d6aa9cbe8462
+ org.mobyproject.buildkit.worker.network:          host
+ org.mobyproject.buildkit.worker.oci.process-mode: sandbox
+ org.mobyproject.buildkit.worker.selinux.enabled:  false
+ org.mobyproject.buildkit.worker.snapshotter:      overlayfs
+Devices:
+ Name:      nvidia.com/gpu
+ On-Demand: true
+GC Policy rule#0:
+ All:            false
+ Filters:        type==source.local,type==exec.cachemount,type==source.git.checkout
+ Keep Duration:  48h0m0s
+ Max Used Space: 488.3MiB
+GC Policy rule#1:
+ All:            false
+ Keep Duration:  1440h0m0s
+ Reserved Space: 9.313GiB
+ Max Used Space: 93.13GiB
+ Min Free Space: 188.1GiB
+GC Policy rule#2:
+ All:            false
+ Reserved Space: 9.313GiB
+ Max Used Space: 93.13GiB
+ Min Free Space: 188.1GiB
+GC Policy rule#3:
+ All:            true
+ Reserved Space: 9.313GiB
+ Max Used Space: 93.13GiB
+ Min Free Space: 188.1GiB
+```
+
+We can see `nvidia.com/gpu` vendor is detected as a device in the builder which
+means that drivers were detected.
+
+Optionally you can check if NVIDIA GPU devices are available in the container
+using `nvidia-smi`:
+
+```console
+$ docker exec -it buildx_buildkit_gpubuilder0 nvidia-smi -L
+GPU 0: Tesla T4 (UUID: GPU-6cf00fa7-59ac-16f2-3e83-d24ccdc56f84)
+```
+
+## Building with GPU support
+
+Let's create a simple Dockerfile that will use the GPU device:
+
+```dockerfile
+# syntax=docker/dockerfile:1-labs
+FROM ubuntu
+RUN --device=nvidia.com/gpu nvidia-smi -L
+```
+
+Now run the build using the `gpubuilder` builder we created earlier:
+
+```console
+$ docker buildx --builder gpubuilder build --progress=plain .
+#0 building with "gpubuilder" instance using docker-container driver
+...
+
+#7 preparing device nvidia.com/gpu
+#7 0.000 > apt-get update
+...
+#7 4.872 > apt-get install -y gpg
+...
+#7 10.16 Downloading NVIDIA GPG key
+#7 10.21 > apt-get update
+...
+#7 12.15 > apt-get install -y --no-install-recommends nvidia-container-toolkit-base
+...
+#7 17.80 time="2025-04-15T08:58:16Z" level=info msg="Generated CDI spec with version 0.8.0"
+#7 DONE 17.8s
+
+#8 [2/2] RUN --device=nvidia.com/gpu nvidia-smi -L
+#8 0.527 GPU 0: Tesla T4 (UUID: GPU-6cf00fa7-59ac-16f2-3e83-d24ccdc56f84)
+#8 DONE 1.6s
+```
+
+As you might have noticed, the step `#7` is preparing the `nvidia.com/gpu`
+device by installing client libraries and the toolkit to generate the CDI
+specifications for the GPU.
+
+The `nvidia-smi -L` command is then executed in the container using the GPU
+device. The output shows the GPU UUID.
+
+You can check the generated CDI specification within the container builder with
+the following command:
+
+```console
+$ docker exec -it buildx_buildkit_gpubuilder0 cat /etc/cdi/nvidia.yaml
+```
+
+For the EC2 instance [`g4dn.xlarge`](https://aws.amazon.com/ec2/instance-types/g4/)
+used here, it looks like this:
+
+```yaml {collapse=true}
+cdiVersion: 0.6.0
+containerEdits:
+  deviceNodes:
+  - path: /dev/nvidia-modeset
+  - path: /dev/nvidia-uvm
+  - path: /dev/nvidia-uvm-tools
+  - path: /dev/nvidiactl
+  env:
+  - NVIDIA_VISIBLE_DEVICES=void
+  hooks:
+  - args:
+    - nvidia-cdi-hook
+    - create-symlinks
+    - --link
+    - ../libnvidia-allocator.so.1::/usr/lib/x86_64-linux-gnu/gbm/nvidia-drm_gbm.so
+    hookName: createContainer
+    path: /usr/bin/nvidia-cdi-hook
+  - args:
+    - nvidia-cdi-hook
+    - create-symlinks
+    - --link
+    - libcuda.so.1::/usr/lib/x86_64-linux-gnu/libcuda.so
+    hookName: createContainer
+    path: /usr/bin/nvidia-cdi-hook
+  - args:
+    - nvidia-cdi-hook
+    - enable-cuda-compat
+    - --host-driver-version=570.133.20
+    hookName: createContainer
+    path: /usr/bin/nvidia-cdi-hook
+  - args:
+    - nvidia-cdi-hook
+    - update-ldcache
+    - --folder
+    - /usr/lib/x86_64-linux-gnu
+    hookName: createContainer
+    path: /usr/bin/nvidia-cdi-hook
+  mounts:
+  - containerPath: /run/nvidia-persistenced/socket
+    hostPath: /run/nvidia-persistenced/socket
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+    - noexec
+  - containerPath: /usr/bin/nvidia-cuda-mps-control
+    hostPath: /usr/bin/nvidia-cuda-mps-control
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/bin/nvidia-cuda-mps-server
+    hostPath: /usr/bin/nvidia-cuda-mps-server
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/bin/nvidia-debugdump
+    hostPath: /usr/bin/nvidia-debugdump
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/bin/nvidia-persistenced
+    hostPath: /usr/bin/nvidia-persistenced
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/bin/nvidia-smi
+    hostPath: /usr/bin/nvidia-smi
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libcuda.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libcuda.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libcudadebugger.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libcudadebugger.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libnvidia-allocator.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libnvidia-allocator.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libnvidia-cfg.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libnvidia-cfg.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libnvidia-gpucomp.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libnvidia-gpucomp.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libnvidia-nscq.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libnvidia-nscq.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libnvidia-nvvm.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libnvidia-nvvm.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libnvidia-pkcs11-openssl3.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libnvidia-pkcs11-openssl3.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libnvidia-pkcs11.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libnvidia-pkcs11.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.570.133.20
+    hostPath: /usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.570.133.20
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /lib/firmware/nvidia/570.133.20/gsp_ga10x.bin
+    hostPath: /lib/firmware/nvidia/570.133.20/gsp_ga10x.bin
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+  - containerPath: /lib/firmware/nvidia/570.133.20/gsp_tu10x.bin
+    hostPath: /lib/firmware/nvidia/570.133.20/gsp_tu10x.bin
+    options:
+    - ro
+    - nosuid
+    - nodev
+    - bind
+devices:
+- containerEdits:
+    deviceNodes:
+    - path: /dev/nvidia0
+  name: "0"
+- containerEdits:
+    deviceNodes:
+    - path: /dev/nvidia0
+  name: GPU-6cf00fa7-59ac-16f2-3e83-d24ccdc56f84
+- containerEdits:
+    deviceNodes:
+    - path: /dev/nvidia0
+  name: all
+kind: nvidia.com/gpu
+```
+
+Congrats on your first build using a GPU device with BuildKit and CDI.
diff --git a/content/manuals/build/building/export.md b/content/manuals/build/building/export.md
index 1b813c3f890e..e507c5588c74 100644
--- a/content/manuals/build/building/export.md
+++ b/content/manuals/build/building/export.md
@@ -18,7 +18,7 @@ from that image, or push it to a registry. Under the hood, this uses the default
 exporter, called the `docker` exporter.
 
 To export your build results as files instead, you can use the `--output` flag,
-or `-o` for short. the `--output` flag lets you change the output format of
+or `-o` for short. The `--output` flag lets you change the output format of
 your build.
 
 ## Export binaries from a build
diff --git a/content/manuals/build/building/multi-platform.md b/content/manuals/build/building/multi-platform.md
index e60db90b3808..8ffae449a5db 100644
--- a/content/manuals/build/building/multi-platform.md
+++ b/content/manuals/build/building/multi-platform.md
@@ -5,11 +5,11 @@ weight: 40
 description: Introduction to what multi-platform builds are and how to execute them using Docker Buildx.
 keywords: build, buildx, buildkit, multi-platform, cross-platform, cross-compilation, emulation, QEMU, ARM, x86, Windows, Linux, macOS
 aliases:
-- /build/buildx/multiplatform-images/
-- /desktop/multi-arch/
-- /docker-for-mac/multi-arch/
-- /mackit/multi-arch/
-- /build/guide/multi-platform/
+  - /build/buildx/multiplatform-images/
+  - /desktop/multi-arch/
+  - /docker-for-mac/multi-arch/
+  - /mackit/multi-arch/
+  - /build/guide/multi-platform/
 ---
 
 A multi-platform build refers to a single build invocation that targets
@@ -55,40 +55,26 @@ selects the `linux/amd64` variant (if you're using Linux containers).
 
 ## Prerequisites
 
-To build multi-platform images, you first need to make sure that your Docker
-environment is set up to support it. There are two ways you can do that:
+Multi-platform images require an image store that supports manifest lists.
+Docker Desktop and Docker Engine 29.0+ use the
+[containerd image store](/manuals/desktop/features/containerd.md) by default,
+which supports multi-platform images out of the box. If you're using one of
+these versions, no additional setup is needed.
 
-- You can switch from the "classic" image store to the containerd image store.
-- You can create and use a custom builder.
+If you're using an older version of Docker Engine, or if you upgraded from an
+older version that still uses classic storage drivers, you have two options:
 
-The "classic" image store of the Docker Engine does not support multi-platform
-images. Switching to the containerd image store ensures that your Docker Engine
-can push, pull, and build multi-platform images.
+- Enable the containerd image store using the
+  [daemon configuration file](/manuals/engine/storage/containerd.md).
+- Create a custom builder using the `docker-container` driver (see the following section).
 
-Creating a custom builder that uses a driver with multi-platform support,
-such as the `docker-container` driver, will let you build multi-platform images
-without switching to a different image store. However, you still won't be able
-to load the multi-platform images you build into your Docker Engine image
-store. But you can push them to a container registry directly with `docker
-build --push`.
+### Custom builder
 
-{{< tabs >}}
-{{< tab name="containerd image store" >}}
-
-The steps for enabling the containerd image store depends on whether you're
-using Docker Desktop or Docker Engine standalone:
-
-- If you're using Docker Desktop, enable the containerd image store in the
-  [Docker Desktop settings](/manuals/desktop/features/containerd.md).
-
-- If you're using Docker Engine standalone, enable the containerd image store
-  using the [daemon configuration file](/manuals/engine/storage/containerd.md).
-
-{{< /tab >}}
-{{< tab name="Custom builder" >}}
-
-To create a custom builder, use the `docker buildx create` command to create a
-builder that uses the `docker-container` driver.
+As an alternative to using the containerd image store, you can create a custom
+builder that uses the `docker-container` driver. This driver supports
+multi-platform builds, but the resulting images aren't loaded into your Docker
+Engine image store. You can push them to a container registry directly with
+`docker build --push`.
 
 ```console
 $ docker buildx create \
@@ -102,12 +88,12 @@ $ docker buildx create \
 > Docker Engine image store. For more information, see [Build
 > drivers](/manuals/build/builders/drivers/_index.md).
 
-{{< /tab >}}
-{{< /tabs >}}
-
 If you're using Docker Engine standalone and you need to build multi-platform
-images using emulation, you also need to install QEMU, see [Install QEMU
-manually](#install-qemu-manually).
+images using emulation, official BuildKit releases bundle QEMU user-mode
+emulators, so in most cases you don't need to install QEMU manually. See
+[Install QEMU manually](#install-qemu-manually) if emulation fails, for
+example with a third-party BuildKit package that doesn't ship the bundled
+emulators.
 
 ## Build multi-platform images
 
@@ -148,10 +134,10 @@ QEMU that's bundled within the Docker Desktop VM.
 
 #### Install QEMU manually
 
-If you're using a builder outside of Docker Desktop, such as if you're using
-Docker Engine on Linux, or a custom remote builder, you need to install QEMU
-and register the executable types on the host OS. The prerequisites for
-installing QEMU are:
+If the QEMU emulators bundled with BuildKit don't work for your build, for
+example with a third-party BuildKit package that doesn't ship them, you can
+install QEMU and register the executable types on the host OS. The
+prerequisites for installing QEMU are:
 
 - Linux kernel version 4.8 or later
 - `binfmt-support` version 2.1.7 or later
@@ -257,7 +243,6 @@ architecture of the container.
 Prerequisites:
 
 - Docker Desktop, or Docker Engine with [QEMU installed](#install-qemu-manually)
-- containerd image store enabled
 
 Steps:
 
@@ -331,7 +316,7 @@ Steps:
        unzip
    ADD https://github.com/neovim/neovim.git#stable .
    RUN make CMAKE_BUILD_TYPE=RelWithDebInfo
-   
+
    FROM scratch
    COPY --from=build /work/build/bin/nvim /
    ```
@@ -358,7 +343,7 @@ Steps:
    │   └── nvim
    └── linux_arm64
        └── nvim
-   
+
    3 directories, 2 files
    ```
 
@@ -399,7 +384,7 @@ Steps:
    WORKDIR /app
    ADD https://github.com/dvdksn/buildme.git#eb6279e0ad8a10003718656c6867539bd9426ad8 .
    RUN go build -o server .
-   
+
    FROM alpine
    COPY --from=build /app/server /server
    ENTRYPOINT ["/server"]
@@ -411,10 +396,7 @@ Steps:
    platforms.
 
 3. To add cross-compilation support, update the Dockerfile to use the
-   pre-defined `BUILDPLATFORM` and `TARGETPLATFORM` build arguments. These
-   arguments are automatically available in the Dockerfile when you use the
-   `--platform` flag with `docker build`.
-
+   pre-defined `BUILDPLATFORM`, `TARGETOS` and `TARGETARCH` build arguments.
    - Pin the `golang` image to the platform of the builder using the
      `--platform=$BUILDPLATFORM` option.
    - Add `ARG` instructions for the Go compilation stages to make the
@@ -435,7 +417,7 @@ Steps:
    WORKDIR /app
    ADD https://github.com/dvdksn/buildme.git#eb6279e0ad8a10003718656c6867539bd9426ad8 .
    RUN GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build -o server .
-   
+
    FROM alpine
    COPY --from=build /app/server /server
    ENTRYPOINT ["/server"]
@@ -450,7 +432,7 @@ Steps:
    WORKDIR /app
    ADD https://github.com/dvdksn/buildme.git#eb6279e0ad8a10003718656c6867539bd9426ad8 .
    RUN go build -o server .
-   
+
    FROM alpine
    COPY --from=build /app/server /server
    ENTRYPOINT ["/server"]
@@ -469,7 +451,7 @@ Steps:
    ADD https://github.com/dvdksn/buildme.git#eb6279e0ad8a10003718656c6867539bd9426ad8 .
    -RUN go build -o server .
    +RUN GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build -o server .
-   
+
    FROM alpine
    COPY --from=build /app/server /server
    ENTRYPOINT ["/server"]
diff --git a/content/manuals/build/building/secrets.md b/content/manuals/build/building/secrets.md
index b262d39e4603..8d2c535c7cd0 100644
--- a/content/manuals/build/building/secrets.md
+++ b/content/manuals/build/building/secrets.md
@@ -37,7 +37,7 @@ First you need to pass the secret into the `docker build` command, and then you
 need to consume the secret in your Dockerfile.
 
 To pass a secret to a build, use the [`docker build --secret`
-flag](/reference/cli/docker/buildx/build.md#secret), or the
+flag](/reference/cli/docker/buildx/build/#secret), or the
 equivalent options for [Bake](../bake/reference.md#targetsecret).
 
 {{< tabs >}}
@@ -84,8 +84,8 @@ builds, such as API tokens, passwords, or SSH keys.
 ### Sources
 
 The source of a secret can be either a
-[file](/reference/cli/docker/buildx/build.md#file) or an
-[environment variable](/reference/cli/docker/buildx/build.md#env).
+[file](/reference/cli/docker/buildx/build/#file) or an
+[environment variable](/reference/cli/docker/buildx/build/#typeenv).
 When you use the CLI or Bake, the type can be detected automatically. You can
 also specify it explicitly with `type=file` or `type=env`.
 
@@ -159,7 +159,7 @@ ADD git@github.com:me/myprivaterepo.git /src/
 ```
 
 To pass an SSH socket the build, you use the [`docker build --ssh`
-flag](/reference/cli/docker/buildx/build.md#ssh), or equivalent
+flag](/reference/cli/docker/buildx/build/#ssh), or equivalent
 options for [Bake](../bake/reference.md#targetssh).
 
 ```console
@@ -175,29 +175,29 @@ building with remote, private Git repositories, including:
 - Building with a private Git repository as build context
 - Fetching private Git repositories in a build with `ADD`
 
-For example, say you have a private GitLab project at
-`https://gitlab.com/example/todo-app.git`, and you want to run a build using
+For example, say you have a private GitHub repository at
+`https://github.com/example/todo-app.git`, and you want to run a build using
 that repository as the build context. An unauthenticated `docker build` command
 fails because the builder isn't authorized to pull the repository:
 
 ```console
-$ docker build https://gitlab.com/example/todo-app.git
+$ docker build https://github.com/example/todo-app.git
 [+] Building 0.4s (1/1) FINISHED
- => ERROR [internal] load git source https://gitlab.com/example/todo-app.git
+ => ERROR [internal] load git source https://github.com/example/todo-app.git
 ------
- > [internal] load git source https://gitlab.com/example/todo-app.git:
-0.313 fatal: could not read Username for 'https://gitlab.com': terminal prompts disabled
+ > [internal] load git source https://github.com/example/todo-app.git:
+0.313 fatal: could not read Username for 'https://github.com': terminal prompts disabled
 ------
 ```
 
-To authenticate the builder to the Git server, set the `GIT_AUTH_TOKEN`
-environment variable to contain a valid GitLab access token, and pass it as a
+To authenticate the builder to GitHub, set the `GIT_AUTH_TOKEN`
+environment variable to contain a valid GitHub access token, and pass it as a
 secret to the build:
 
 ```console
-$ GIT_AUTH_TOKEN=$(cat gitlab-token.txt) docker build \
+$ GIT_AUTH_TOKEN=$(gh auth token) docker build \
   --secret id=GIT_AUTH_TOKEN \
-  https://gitlab.com/example/todo-app.git
+  https://github.com/example/todo-app.git
 ```
 
 The `GIT_AUTH_TOKEN` also works with `ADD` to fetch private Git repositories as
@@ -205,31 +205,50 @@ part of your build:
 
 ```dockerfile
 FROM alpine
-ADD https://gitlab.com/example/todo-app.git /src
+ADD https://github.com/example/todo-app.git /src
 ```
 
 ### HTTP authentication scheme
 
-By default, Git authentication over HTTP uses the Bearer authentication scheme:
+BuildKit supports two Git authentication secrets:
+
+- **`GIT_AUTH_TOKEN`**: Uses Basic authentication with a fixed username of `x-access-token` (the GitHub-style default)
+- **`GIT_AUTH_HEADER`**: Uses the raw authorization header value you provide (works with any Git provider)
+
+#### Using GIT_AUTH_TOKEN (for example, GitHub)
+
+When you use `GIT_AUTH_TOKEN`, BuildKit constructs a Basic authentication header using `x-access-token` as the user:
 
 ```http
-Authorization: Bearer <GIT_AUTH_TOKEN>
+Authorization: Basic <base64("x-access-token:<GIT_AUTH_TOKEN>")>
 ```
 
-If you need to use a Basic scheme, with a username and password, you can set
-the `GIT_AUTH_HEADER` build secret:
+This method works for providers that accept the `x-access-token` Basic auth pattern, such as GitHub. Example usage:
 
 ```console
-$ export GIT_AUTH_TOKEN=$(cat gitlab-token.txt)
-$ export GIT_AUTH_HEADER=basic
+$ export GIT_AUTH_TOKEN=$(gh auth token)
 $ docker build \
   --secret id=GIT_AUTH_TOKEN \
+  https://github.com/example/todo-app.git
+```
+
+#### Using GIT_AUTH_HEADER (custom authorization header)
+
+When you use `GIT_AUTH_HEADER`, BuildKit uses the exact value you provide as the `Authorization` header:
+
+```http
+Authorization: <GIT_AUTH_HEADER>
+```
+
+Example usage with GitLab CI/CD token:
+
+```console
+$ export GIT_AUTH_HEADER="Basic $(echo -n "gitlab-ci-token:${CI_JOB_TOKEN}" | base64)"
+$ docker build \
   --secret id=GIT_AUTH_HEADER \
   https://gitlab.com/example/todo-app.git
 ```
 
-BuildKit currently only supports the Bearer and Basic schemes.
-
 ### Multiple hosts
 
 You can set the `GIT_AUTH_TOKEN` and `GIT_AUTH_HEADER` secrets on a per-host
@@ -238,12 +257,20 @@ hostnames. To specify a hostname, append the hostname as a suffix to the secret
 ID:
 
 ```console
-$ export GITLAB_TOKEN=$(cat gitlab-token.txt)
-$ export GERRIT_TOKEN=$(cat gerrit-username-password.txt)
-$ export GERRIT_SCHEME=basic
+$ export GITHUB_TOKEN=$(gh auth token)
+$ export GITLAB_AUTH_HEADER="Basic $(echo -n "gitlab-ci-token:${CI_JOB_TOKEN}" | base64)"
 $ docker build \
-  --secret id=GIT_AUTH_TOKEN.gitlab.com,env=GITLAB_TOKEN \
-  --secret id=GIT_AUTH_TOKEN.gerrit.internal.example,env=GERRIT_TOKEN \
-  --secret id=GIT_AUTH_HEADER.gerrit.internal.example,env=GERRIT_SCHEME \
-  https://gitlab.com/example/todo-app.git
+  --secret id=GIT_AUTH_TOKEN.github.com,env=GITHUB_TOKEN \
+  --secret id=GIT_AUTH_HEADER.gitlab.com,env=GITLAB_AUTH_HEADER \
+  https://github.com/example/todo-app.git
 ```
+
+## HTTP authentication for `COPY` and `ADD`
+
+To use secrets in `COPY` or `ADD` commands, you can create
+`HTTP_AUTH_TOKEN_<host>` or `HTTP_AUTH_HEADER_<host>` secrets for use when
+accessing the specified host. For example `HTTP_AUTH_TOKEN_127.0.0.1=token` will
+make requests to `127.0.0.1` add a header `Authorization: Bearer token`.
+
+These variables follow the same convention as the [Git HTTP authentication
+scheme](#http-authentication-scheme) handling.
diff --git a/content/manuals/build/building/variables.md b/content/manuals/build/building/variables.md
index 28662a9b19e3..f709a7cc8c43 100644
--- a/content/manuals/build/building/variables.md
+++ b/content/manuals/build/building/variables.md
@@ -119,7 +119,7 @@ $ docker build --build-arg NODE_VERSION=current .
 For more information on how to use build arguments, refer to:
 
 - [`ARG` Dockerfile reference](/reference/dockerfile.md#arg)
-- [`docker build --build-arg` reference](/reference/cli/docker/buildx/build.md#build-arg)
+- [`docker build --build-arg` reference](/reference/cli/docker/buildx/build/#build-arg)
 
 ## `ENV` usage example
 
@@ -310,6 +310,8 @@ They're used to configure the Buildx client, or the BuildKit daemon.
 | [BUILDKIT_HOST](#buildkit_host)                                             | String            | Specify host to use for remote builders.                         |
 | [BUILDKIT_PROGRESS](#buildkit_progress)                                     | String            | Configure type of progress output.                               |
 | [BUILDKIT_TTY_LOG_LINES](#buildkit_tty_log_lines)                           | String            | Number of log lines (for active steps in TTY mode).              |
+| [BUILDX_BAKE_FILE](#buildx_bake_file)                                       | String            | Specify the build definition file(s) for `docker buildx bake`.   |
+| [BUILDX_BAKE_FILE_SEPARATOR](#buildx_bake_file_separator)                   | String            | Specify the file-path separator for `BUILDX_BAKE_FILE`.          |
 | [BUILDX_BAKE_GIT_AUTH_HEADER](#buildx_bake_git_auth_header)                 | String            | HTTP authentication scheme for remote Bake files.                |
 | [BUILDX_BAKE_GIT_AUTH_TOKEN](#buildx_bake_git_auth_token)                   | String            | HTTP authentication token for remote Bake files.                 |
 | [BUILDX_BAKE_GIT_SSH](#buildx_bake_git_ssh)                                 | String            | SSH authentication for remote Bake files.                        |
@@ -321,9 +323,10 @@ They're used to configure the Buildx client, or the BuildKit daemon.
 | [BUILDX_GIT_INFO](#buildx_git_info)                                         | Boolean           | Remove Git information in provenance attestations.               |
 | [BUILDX_GIT_LABELS](#buildx_git_labels)                                     | String \| Boolean | Add Git provenance labels to images.                             |
 | [BUILDX_MEM_PROFILE](#buildx_mem_profile)                                   | String            | Generate a `pprof` memory profile at the specified location.     |
-| [BUILDX_METADATA_PROVENANCE](#buildx_metadata_provenance)                   | String \| Boolean | Customize provenance informations included in the metadata file. |
+| [BUILDX_METADATA_PROVENANCE](#buildx_metadata_provenance)                   | String \| Boolean | Customize provenance information included in the metadata file.  |
 | [BUILDX_METADATA_WARNINGS](#buildx_metadata_warnings)                       | String            | Include build warnings in the metadata file.                     |
 | [BUILDX_NO_DEFAULT_ATTESTATIONS](#buildx_no_default_attestations)           | Boolean           | Turn off default provenance attestations.                        |
+| [BUILDX_NO_DEFAULT_OCI_ARTIFACT](#buildx_no_default_oci_artifact)           | Boolean           | Turn off OCI artifact storage for attestations by default.       |
 | [BUILDX_NO_DEFAULT_LOAD](#buildx_no_default_load)                           | Boolean           | Turn off loading images to image store by default.               |
 | [EXPERIMENTAL_BUILDKIT_SOURCE_POLICY](#experimental_buildkit_source_policy) | String            | Specify a BuildKit source policy file.                           |
 
@@ -374,11 +377,12 @@ argument, the argument takes priority.
 
 Sets the type of the BuildKit progress output. Valid values are:
 
-- `auto` (default)
-- `plain`
-- `tty`
-- `quiet`
-- `rawjson`
+- `auto` (default): automatically uses `tty` in interactive terminals, `plain` otherwise
+- `plain`: displays build steps sequentially in simple text format
+- `tty`: interactive output with formatted progress bars and build steps
+- `quiet`: suppresses progress output, only shows errors and final image ID
+- `none`: no progress output, only shows errors
+- `rawjson`: outputs build progress as raw JSON (useful for parsing by other tools)
 
 Usage:
 
@@ -438,6 +442,44 @@ Example:
 }
 ```
 
+### BUILDX_BAKE_FILE
+
+{{< summary-bar feature_name="Buildx bake file" >}}
+
+Specify one or more build definition files for `docker buildx bake`. 
+
+This environment variable provides an alternative to the `-f` / `--file` command-line flag.
+
+Multiple files can be specified by separating them with the system path separator (":" on Linux/macOS, ";" on Windows):
+
+```console
+export BUILDX_BAKE_FILE=file1.hcl:file2.hcl
+```
+
+Or with a custom separator defined by the [BUILDX_BAKE_FILE_SEPARATOR](#buildx_bake_file_separator) variable:
+
+```console
+export BUILDX_BAKE_FILE_SEPARATOR=@
+export BUILDX_BAKE_FILE=file1.hcl@file2.hcl
+```
+
+If both `BUILDX_BAKE_FILE` and the `-f` flag are set, only the files provided via `-f` are used. 
+
+If a listed file does not exist or is invalid, bake returns an error.
+
+### BUILDX_BAKE_FILE_SEPARATOR
+
+{{< summary-bar feature_name="Buildx bake file separator" >}}
+
+Controls the separator used between file paths in the `BUILDX_BAKE_FILE` environment variable. 
+
+This is useful if your file paths contain the default separator character or if you want to standardize separators across different platforms.
+
+```console
+export BUILDX_BAKE_PATH_SEPARATOR=@
+export BUILDX_BAKE_FILE=file1.hcl@file2.hcl
+```
+
 ### BUILDX_BAKE_GIT_AUTH_HEADER
 
 {{< summary-bar feature_name="Buildx bake Git auth token" >}}
@@ -645,6 +687,22 @@ Usage:
 $ export BUILDX_NO_DEFAULT_ATTESTATIONS=1
 ```
 
+### BUILDX_NO_DEFAULT_OCI_ARTIFACT
+
+{{< summary-bar feature_name="Buildx no default OCI artifact" >}}
+
+Starting with BuildKit v0.32.0, BuildKit stores attestations as OCI artifacts
+when OCI media types are enabled. Set `BUILDX_NO_DEFAULT_OCI_ARTIFACT=1` to
+make Buildx set `oci-artifact=false` when the build uses an exporter that
+supports attestations and you haven't explicitly set the `oci-artifact`
+exporter attribute.
+
+Usage:
+
+```console
+$ export BUILDX_NO_DEFAULT_OCI_ARTIFACT=1
+```
+
 ### BUILDX_NO_DEFAULT_LOAD
 
 When you build an image using the `docker` driver, the image is automatically
diff --git a/content/manuals/build/buildkit/_index.md b/content/manuals/build/buildkit/_index.md
index 89d75f2ad539..20bbddd30925 100644
--- a/content/manuals/build/buildkit/_index.md
+++ b/content/manuals/build/buildkit/_index.md
@@ -5,14 +5,10 @@ description: Introduction and overview of BuildKit
 keywords: build, buildkit
 ---
 
-## Overview
-
-[BuildKit](https://github.com/moby/buildkit)
-is an improved backend to replace the legacy builder. BuildKit is the default builder
-for users on Docker Desktop, and Docker Engine as of version 23.0.
-
-BuildKit provides new functionality and improves your builds' performance.
-It also introduces support for handling more complex scenarios:
+[BuildKit](https://github.com/moby/buildkit) is the builder backend used by
+Docker. BuildKit provides improved functionality and improves your builds'
+performance over the legacy builder used in earlier versions of Docker. It also
+introduces support for handling more complex scenarios:
 
 - Detect and skip executing unused build stages
 - Parallelize building independent build stages
@@ -21,16 +17,16 @@ It also introduces support for handling more complex scenarios:
 - Detect and skip transferring unused files in your
   [build context](../concepts/context.md)
 - Use [Dockerfile frontend](frontend.md) implementations with many
-  new features
+  additional features
 - Avoid side effects with rest of the API (intermediate images and containers)
 - Prioritize your build cache for automatic pruning
 
-Apart from many new features, the main areas BuildKit improves on the current
-experience are performance, storage management, and extensibility. From the
-performance side, a significant update is a new fully concurrent build graph
-solver. It can run build steps in parallel when possible and optimize out
-commands that don't have an impact on the final result. We have also optimized
-the access to the local source files. By tracking only the updates made to these
+The main areas BuildKit improves on the legacy builder are performance, storage
+management, and extensibility. From the performance side, a significant update
+is a fully concurrent build graph solver. It can run build steps in parallel when possible and optimize out
+commands that don't have an impact on the final result.
+The access to the local source files has also been optimized. By tracking
+only the updates made to these
 files between repeated build invocations, there is no need to wait for local
 files to be read or uploaded before the work can begin.
 
@@ -39,7 +35,7 @@ files to be read or uploaded before the work can begin.
 At the core of BuildKit is a
 [Low-Level Build (LLB)](https://github.com/moby/buildkit#exploring-llb) definition format. LLB is an intermediate binary format
 that allows developers to extend BuildKit. LLB defines a content-addressable
-dependency graph that can be used to put together very complex build
+dependency graph that can be used to put together complex build
 definitions. It also supports features not exposed in Dockerfiles, like direct
 data mounting and nested invocation.
 
@@ -72,39 +68,8 @@ BuildKit, you would
 
 ## Getting started
 
-BuildKit is the default builder for users on Docker Desktop and Docker Engine
-v23.0 and later.
-
-If you have installed Docker Desktop, you don't need to enable BuildKit. If you
-are running a version of Docker Engine version earlier than 23.0, you can enable
-BuildKit either by setting an environment variable, or by making BuildKit the
-default setting in the daemon configuration.
-
-To set the BuildKit environment variable when running the `docker build`
-command, run:
-
-```console
-$ DOCKER_BUILDKIT=1 docker build .
-```
-
-> [!NOTE]
->
-> Buildx always uses BuildKit.
-
-To use Docker BuildKit by default, edit the Docker daemon configuration in
-`/etc/docker/daemon.json` as follows, and restart the daemon.
-
-```json
-{
-  "features": {
-    "buildkit": true
-  }
-}
-```
-
-If the `/etc/docker/daemon.json` file doesn't exist, create new file called
-`daemon.json` and then add the following to the file. And restart the Docker
-daemon.
+BuildKit is the default builder for Docker Desktop and Docker Engine users.
+If you're building Windows containers, the legacy builder is used instead.
 
 ## BuildKit on Windows
 
@@ -115,7 +80,7 @@ daemon.
 
 BuildKit has experimental support for Windows containers (WCOW) as of version 0.13.
 This section walks you through the steps for trying it out.
-We appreciate any feedback you submit by [opening an issue here](https://github.com/moby/buildkit/issues/new), especially `buildkitd.exe`.
+To share feedback, [open an issue in the repository](https://github.com/moby/buildkit/issues/new), especially `buildkitd.exe`.
 
 ### Known limitations
 
@@ -149,12 +114,12 @@ see [GitHub issues](https://github.com/moby/buildkit/issues?q=is%3Aissue%20state
 
    Select the Docker icon in the taskbar, and then **Switch to Windows containers...**.
 
-3. Install containerd version 1.7.7 or later following the setup instructions [here](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#installing-containerd-on-windows).
+3. Install containerd version 1.7.7 or later following the [setup instructions](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#installing-containerd-on-windows).
 
 4. Download and extract the latest BuildKit release.
 
    ```powershell
-   $version = "v0.13.1" # specify the release version, v0.13+
+   $version = "v0.22.0" # specify the release version, v0.13+
    $arch = "amd64" # arm64 binary available too
    curl.exe -LO https://github.com/moby/buildkit/releases/download/$version/buildkit-$version.windows-$arch.tar.gz
    # there could be another `.\bin` directory from containerd instructions
@@ -179,12 +144,17 @@ see [GitHub issues](https://github.com/moby/buildkit/issues?q=is%3Aissue%20state
    $Env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + `
        [System.Environment]::GetEnvironmentVariable("Path","User")
    ```
+
 6. Start the BuildKit daemon.
 
    ```console
    > buildkitd.exe
    ```
 
+   > [!NOTE]
+   > If you are running a _dockerd-managed_ `containerd` process, use that instead, by supplying the address:
+   > `buildkitd.exe --containerd-worker-addr "npipe:////./pipe/docker-containerd"`
+
 7. In another terminal with administrator privileges, create a remote builder that uses the local BuildKit daemon.
 
    > [!NOTE]
diff --git a/content/manuals/build/buildkit/configure.md b/content/manuals/build/buildkit/configure.md
index bef1959c75b5..367a62fe1d9b 100644
--- a/content/manuals/build/buildkit/configure.md
+++ b/content/manuals/build/buildkit/configure.md
@@ -6,8 +6,8 @@ keywords: build, buildkit, configuration, buildx, network, cni, registry
 
 If you create a `docker-container` or `kubernetes` builder with Buildx, you can
 apply a custom [BuildKit configuration](toml-configuration.md) by passing the
-[`--config` flag](/reference/cli/docker/buildx/create.md#config) to
-the `docker buildx create` command.
+[`--buildkitd-config` flag](/reference/cli/docker/buildx/create/#buildkitd-config)
+to the `docker buildx create` command.
 
 ## Registry mirror
 
@@ -34,7 +34,7 @@ defining a mirror for `docker.io` (Docker Hub) to `mirror.gcr.io`.
    $ docker buildx create --use --bootstrap \
      --name mybuilder \
      --driver docker-container \
-     --config /etc/buildkitd.toml
+     --buildkitd-config /etc/buildkitd.toml
    ```
 
 3. Build an image:
@@ -96,7 +96,7 @@ configuration.
    $ docker buildx create --use --bootstrap \
      --name mybuilder \
      --driver docker-container \
-     --config /etc/buildkitd.toml
+     --buildkitd-config /etc/buildkitd.toml
    ```
 
 3. Inspect the builder's configuration file (`/etc/buildkit/buildkitd.toml`), it
@@ -136,9 +136,29 @@ $ docker buildx build --push --tag myregistry.com/myimage:latest .
 ## CNI networking
 
 CNI networking for builders can be useful for dealing with network port
-contention during concurrent builds. CNI is [not yet](https://github.com/moby/buildkit/issues/28)
-available in the default BuildKit image. But you can create your own image that
-includes CNI support.
+contention during concurrent builds.
+
+### Bridge networking
+
+The BuildKit image ships with a built-in bridge network provider that uses a
+minimal set of bundled CNI plugins, so you don't need to build a custom image
+or supply your own CNI configuration. To use it, set the worker network mode to
+`bridge` when you create the builder:
+
+```console
+$ docker buildx create --use --bootstrap \
+  --name mybuilder \
+  --driver docker-container \
+  --buildkitd-flags "--oci-worker-net=bridge"
+```
+
+BuildKit creates a `buildkit0` bridge with a default subnet of `10.10.0.0/16`,
+and cleans up the bridge automatically when the daemon shuts down.
+
+### Custom CNI configuration
+
+For more control over networking, build a custom BuildKit image with your own
+CNI configuration and plugins.
 
 The following Dockerfile example shows a custom BuildKit image with CNI support.
 It uses the [CNI config for integration tests](https://github.com/moby/buildkit/blob/master//hack/fixtures/cni.json)
@@ -166,7 +186,7 @@ ADD https://raw.githubusercontent.com/moby/buildkit/${BUILDKIT_VERSION}/hack/fix
 ```
 
 Now you can build this image, and create a builder instance from it using
-[the `--driver-opt image` option](/reference/cli/docker/buildx/create.md#driver-opt):
+[the `--driver-opt image` option](/reference/cli/docker/buildx/create/#driver-opt):
 
 ```console
 $ docker buildx build --tag buildkit-cni:local --load .
@@ -183,7 +203,7 @@ $ docker buildx create --use --bootstrap \
 
 You can limit the parallelism of the BuildKit solver, which is particularly useful
 for low-powered machines, using a [BuildKit configuration](toml-configuration.md)
-while creating a builder with the [`--config` flags](/reference/cli/docker/buildx/create.md#config).
+while creating a builder with the [`--buildkitd-config` flag](/reference/cli/docker/buildx/create/#buildkitd-config).
 
 ```toml
 # /etc/buildkitd.toml
@@ -198,7 +218,7 @@ that will use this BuildKit configuration to limit parallelism.
 $ docker buildx create --use \
   --name mybuilder \
   --driver docker-container \
-  --config /etc/buildkitd.toml
+  --buildkitd-config /etc/buildkitd.toml
 ```
 
 ### TCP connection limit
diff --git a/content/manuals/build/buildkit/dockerfile-release-notes.md b/content/manuals/build/buildkit/dockerfile-release-notes.md
index 35e5a586b04c..404a1a0528ce 100644
--- a/content/manuals/build/buildkit/dockerfile-release-notes.md
+++ b/content/manuals/build/buildkit/dockerfile-release-notes.md
@@ -1,564 +1,8 @@
 ---
 title: Dockerfile release notes
-description: Release notes for Dockerfile frontend
-keywords: build, dockerfile, frontend, release notes
-tags: [Release notes]
-toc_max: 2
+params:
+  sidebar:
+    goto: "https://github.com/moby/buildkit/releases"
 aliases:
   - /build/dockerfile/release-notes/
 ---
-
-This page contains information about the new features, improvements, known
-issues, and bug fixes in [Dockerfile reference](/reference/dockerfile.md).
-
-For usage, see the [Dockerfile frontend syntax](frontend.md) page.
-
-## 1.15.0
-
-{{< release-date date="2025-04-15" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.15.0).
-
-```dockerfile
-# syntax=docker/dockerfile:1.15.0
-```
-
-- Build error for invalid target now shows suggestions for correct possible names. [moby/buildkit#5851](https://github.com/moby/buildkit/pull/5851)
-- Fix SBOM attestation producing error for Windows targets. [moby/buildkit#5837](https://github.com/moby/buildkit/pull/5837)
-- Fix recursive `ARG` producing an infinite loop when processing an outline request. [moby/buildkit#5823](https://github.com/moby/buildkit/pull/5823)
-- Fix parsing syntax directive from JSON that would fail if the JSON had other datatypes than strings. [moby/buildkit#5815](https://github.com/moby/buildkit/pull/5815)
-- Fix platform in image config being in unnormalized form (regression from 1.12). [moby/buildkit#5776](https://github.com/moby/buildkit/pull/5776)
-- Fix copying into destination directory when directory is not present with WCOW. [moby/buildkit#5249](https://github.com/moby/buildkit/pull/5249)
-
-## 1.14.1
-
-{{< release-date date="2025-03-05" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.14.1).
-
-```dockerfile
-# syntax=docker/dockerfile:1.14.1
-```
-
-- Normalize platform in image config. [moby/buildkit#5776](https://github.com/moby/buildkit/pull/5776)
-
-## 1.14.0
-
-{{< release-date date="2025-02-19" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.14.0).
-
-```dockerfile
-# syntax=docker/dockerfile:1.14.0
-```
-
-- `COPY --chmod` now allows non-octal values. This feature was previously in the labs channel and is now available in the main release. [moby/buildkit#5734](https://github.com/moby/buildkit/pull/5734)
-- Fix handling of OSVersion platform property if one is set by the base image [moby/buildkit#5714](https://github.com/moby/buildkit/pull/5714)
-- Fix errors where a named context metadata could be resolved even if it was not reachable by the current build configuration, leading to build errors [moby/buildkit#5688](https://github.com/moby/buildkit/pull/5688)
-
-## 1.14.0 (labs)
-
-{{< release-date date="2025-02-19" >}}
-
-{{% include "dockerfile-labs-channel.md" %}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.14.0-labs).
-
-```dockerfile
-# syntax=docker.io/docker/dockerfile-upstream:1.14.0-labs
-```
-
-- New `RUN --device=name,[required]` flag lets builds request CDI devices are available to the build step. Requires BuildKit v0.20.0+ [moby/buildkit#4056](https://github.com/moby/buildkit/pull/4056), [moby/buildkit#5738](https://github.com/moby/buildkit/pull/5738)
-
-## 1.13.0
-
-{{< release-date date="2025-01-20" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.13.0).
-
-```dockerfile
-# syntax=docker/dockerfile:1.13.0
-```
-
-- New `TARGETOSVERSION`, `BUILDOSVERSION` builtin build-args are available for Windows builds, and `TARGETPLATFORM` value now also contains `OSVersion` value. [moby/buildkit#5614](https://github.com/moby/buildkit/pull/5614)
-- Allow syntax forwarding for external frontends for files starting with a Byte Order Mark (BOM). [moby/buildkit#5645](https://github.com/moby/buildkit/pull/5645)
-- Default `PATH` in Windows Containers has been updated with `powershell.exe` directory. [moby/buildkit#5446](https://github.com/moby/buildkit/pull/5446)
-- Fix Dockerfile directive parsing to not allow invalid syntax. [moby/buildkit#5646](https://github.com/moby/buildkit/pull/5646)
-- Fix case where `ONBUILD` command may have run twice on inherited stage. [moby/buildkit#5593](https://github.com/moby/buildkit/pull/5593)
-- Fix possible missing named context replacement for child stages in Dockerfile. [moby/buildkit#5596](https://github.com/moby/buildkit/pull/5596)
-
-## 1.13.0 (labs)
-
-{{< release-date date="2025-01-20" >}}
-
-{{% include "dockerfile-labs-channel.md" %}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.13.0-labs).
-
-```dockerfile
-# syntax=docker.io/docker/dockerfile-upstream:1.13.0-labs
-```
-
-- Fix support for non-octal values for `COPY --chmod`. [moby/buildkit#5626](https://github.com/moby/buildkit/pull/5626)
-
-## 1.12.0
-
-{{< release-date date="2024-11-27" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.12.0).
-
-```dockerfile
-# syntax=docker/dockerfile:1.12.0
-```
-
-- Fix incorrect description in History line of image configuration with multiple `ARG` instructions. [moby/buildkit#5508]
-
-[moby/buildkit#5508]: https://github.com/moby/buildkit/pull/5508
-
-## 1.11.1
-
-{{< release-date date="2024-11-08" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.11.1).
-
-```dockerfile
-# syntax=docker/dockerfile:1.11.1
-```
-
-- Fix regression when using the `ONBUILD` instruction in stages inherited within the same Dockerfile. [moby/buildkit#5490]
-
-[moby/buildkit#5490]: https://github.com/moby/buildkit/pull/5490
-
-## 1.11.0
-
-{{< release-date date="2024-10-30" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.11.0).
-
-```dockerfile
-# syntax=docker/dockerfile:1.11.0
-```
-
-- The [`ONBUILD` instruction](/reference/dockerfile.md#onbuild) now supports commands that refer to other stages or images with `from`, such as `COPY --from` or `RUN mount=from=...`. [moby/buildkit#5357]
-- The [`SecretsUsedInArgOrEnv`](/reference/build-checks/secrets-used-in-arg-or-env.md) build check has been improved to reduce false positives. [moby/buildkit#5208]
-- A new [`InvalidDefinitionDescription`](/reference/build-checks/invalid-definition-description.md) build check recommends formatting comments for build arguments and stages descriptions. This is an [experimental check](/manuals/build/checks.md#experimental-checks). [moby/buildkit#5208], [moby/buildkit#5414]
-- Multiple fixes for the `ONBUILD` instruction's progress and error handling. [moby/buildkit#5397]
-- Improved error reporting for missing flag errors. [moby/buildkit#5369]
-- Enhanced progress output for secret values mounted as environment variables. [moby/buildkit#5336]
-- Added built-in build argument `TARGETSTAGE` to expose the name of the (final) target stage for the current build. [moby/buildkit#5431]
-
-## 1.11.0 (labs)
-
-{{% include "dockerfile-labs-channel.md" %}}
-
-- `COPY --chmod` now supports non-octal values. [moby/buildkit#5380]
-
-[moby/buildkit#5357]: https://github.com/moby/buildkit/pull/5357
-[moby/buildkit#5208]: https://github.com/moby/buildkit/pull/5208
-[moby/buildkit#5414]: https://github.com/moby/buildkit/pull/5414
-[moby/buildkit#5397]: https://github.com/moby/buildkit/pull/5397
-[moby/buildkit#5369]: https://github.com/moby/buildkit/pull/5369
-[moby/buildkit#5336]: https://github.com/moby/buildkit/pull/5336
-[moby/buildkit#5431]: https://github.com/moby/buildkit/pull/5431
-[moby/buildkit#5380]: https://github.com/moby/buildkit/pull/5380
-
-## 1.10.0
-
-{{< release-date date="2024-09-10" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.10.0).
-
-```dockerfile
-# syntax=docker/dockerfile:1.10.0
-```
-
-- [Build secrets](/manuals/build/building/secrets.md#target) can now be mounted as environment variables using the `env=VARIABLE` option. [moby/buildkit#5215]
-- The [`# check` directive](/reference/dockerfile.md#check) now allows new experimental attribute for enabling experimental validation rules like `CopyIgnoredFile`. [moby/buildkit#5213]
-- Improve validation of unsupported modifiers for variable substitution. [moby/buildkit#5146]
-- `ADD` and `COPY` instructions now support variable interpolation for build arguments for the `--chmod` option values. [moby/buildkit#5151]
-- Improve validation of the `--chmod` option for `COPY` and `ADD` instructions. [moby/buildkit#5148]
-- Fix missing completions for size and destination attributes on mounts. [moby/buildkit#5245]
-- OCI annotations are now set to the Dockerfile frontend release image. [moby/buildkit#5197]
-
-[moby/buildkit#5215]: https://github.com/moby/buildkit/pull/5215
-[moby/buildkit#5213]: https://github.com/moby/buildkit/pull/5213
-[moby/buildkit#5146]: https://github.com/moby/buildkit/pull/5146
-[moby/buildkit#5151]: https://github.com/moby/buildkit/pull/5151
-[moby/buildkit#5148]: https://github.com/moby/buildkit/pull/5148
-[moby/buildkit#5245]: https://github.com/moby/buildkit/pull/5245
-[moby/buildkit#5197]: https://github.com/moby/buildkit/pull/5197
-
-## 1.9.0
-
-{{< release-date date="2024-07-11" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.9.0).
-
-```dockerfile
-# syntax=docker/dockerfile:1.9.0
-```
-
-- Add new validation rules:
-  - `SecretsUsedInArgOrEnv`
-  - `InvalidDefaultArgInFrom`
-  - `RedundantTargetPlatform`
-  - `CopyIgnoredFile` (experimental)
-  - `FromPlatformFlagConstDisallowed`
-- Many performance improvements for working with big Dockerfiles. [moby/buildkit#5067](https://github.com/moby/buildkit/pull/5067/), [moby/buildkit#5029](https://github.com/moby/buildkit/pull/5029/)
-- Fix possible panic when building Dockerfile without defined stages. [moby/buildkit#5150](https://github.com/moby/buildkit/pull/5150/)
-- Fix incorrect JSON parsing that could cause some incorrect JSON values to pass without producing an error. [moby/buildkit#5107](https://github.com/moby/buildkit/pull/5107/)
-- Fix a regression where `COPY --link` with a destination path of `.` could fail. [moby/buildkit#5080](https://github.com/moby/buildkit/pull/5080/)
-- Fix validation of `ADD --checksum` when used with a Git URL. [moby/buildkit#5085](https://github.com/moby/buildkit/pull/5085/)
-
-## 1.8.1
-
-{{< release-date date="2024-06-18" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.8.1).
-
-```dockerfile
-# syntax=docker/dockerfile:1.8.1
-```
-
-### Bug fixes and enhancements
-
-- Fix handling of empty strings on variable expansion. [moby/buildkit#5052](https://github.com/moby/buildkit/pull/5052/)
-- Improve formatting of build warnings. [moby/buildkit#5037](https://github.com/moby/buildkit/pull/5037/), [moby/buildkit#5045](https://github.com/moby/buildkit/pull/5045/), [moby/buildkit#5046](https://github.com/moby/buildkit/pull/5046/)
-- Fix possible invalid output for `UndeclaredVariable` warning for multi-stage builds. [moby/buildkit#5048](https://github.com/moby/buildkit/pull/5048/)
-
-## 1.8.0
-
-{{< release-date date="2024-06-11" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.8.0).
-
-```dockerfile
-# syntax=docker/dockerfile:1.8.0
-```
-
-- Many new validation rules have been added to verify that your Dockerfile is using best practices. These rules are validated during build and new `check` frontend method can be used to only trigger validation without completing the whole build.
-- New directive `#check` and build argument `BUILDKIT_DOCKERFILE_CHECK` lets you control the behavior or build checks. [moby/buildkit#4962](https://github.com/moby/buildkit/pull/4962/)
-- Using a single-platform base image that does not match your expected platform is now validated. [moby/buildkit#4924](https://github.com/moby/buildkit/pull/4924/)
-- Errors from the expansion of `ARG` definitions in global scope are now handled properly. [moby/buildkit#4856](https://github.com/moby/buildkit/pull/4856/)
-- Expansion of the default value of `ARG` now only happens if it is not overwritten by the user. Previously, expansion was completed and value was later ignored, which could result in an unexpected expansion error. [moby/buildkit#4856](https://github.com/moby/buildkit/pull/4856/)
-- Performance of parsing huge Dockerfiles with many stages has been improved. [moby/buildkit#4970](https://github.com/moby/buildkit/pull/4970/)
-- Fix some Windows path handling consistency errors. [moby/buildkit#4825](https://github.com/moby/buildkit/pull/4825/)
-
-## 1.7.0
-
-{{< release-date date="2024-03-06" >}}
-
-### Stable
-
-```dockerfile
-# syntax=docker/dockerfile:1.7
-```
-
-- Variable expansion now allows string substitutions and trimming.
-  [moby/buildkit#4427](https://github.com/moby/buildkit/pull/4427),
-  [moby/buildkit#4287](https://github.com/moby/buildkit/pull/4287)
-- Named contexts with local sources now correctly transfer only the files used in the Dockerfile instead of the full source directory.
-  [moby/buildkit#4161](https://github.com/moby/buildkit/pull/4161)
-- Dockerfile now better validates the order of stages and returns nice errors with stack traces if stages are in incorrect order.
-  [moby/buildkit#4568](https://github.com/moby/buildkit/pull/4568),
-  [moby/buildkit#4567](https://github.com/moby/buildkit/pull/4567)
-- History commit messages now contain flags used with `COPY` and `ADD`.
-  [moby/buildkit#4597](https://github.com/moby/buildkit/pull/4597)
-- Progress messages for `ADD` commands from Git and HTTP sources have been improved.
-  [moby/buildkit#4408](https://github.com/moby/buildkit/pull/4408)
-
-### Labs
-
-```dockerfile
-# syntax=docker/dockerfile:1.7-labs
-```
-
-- New `--parents` flag has been added to `COPY` for copying files while keeping the parent directory structure.
-  [moby/buildkit#4598](https://github.com/moby/buildkit/pull/4598),
-  [moby/buildkit#3001](https://github.com/moby/buildkit/pull/3001),
-  [moby/buildkit#4720](https://github.com/moby/buildkit/pull/4720),
-  [moby/buildkit#4728](https://github.com/moby/buildkit/pull/4728),
-  [docs](/reference/dockerfile.md#copy---parents)
-- New `--exclude` flag can be used in `COPY` and `ADD` commands to apply filter to copied files.
-  [moby/buildkit#4561](https://github.com/moby/buildkit/pull/4561),
-  [docs](/reference/dockerfile.md#copy---exclude)
-
-## 1.6.0
-
-{{< release-date date="2023-06-13" >}}
-
-### New
-
-- Add `--start-interval` flag to the
-  [`HEALTHCHECK` instruction](/reference/dockerfile.md#healthcheck).
-
-The following features have graduated from the labs channel to stable:
-
-- The `ADD` instruction can now [import files directly from Git URLs](/reference/dockerfile.md#adding-a-git-repository-add-git-ref-dir)
-- The `ADD` instruction now supports [`--checksum` flag](/reference/dockerfile.md#verifying-a-remote-file-checksum-add---checksumchecksum-http-src-dest)
-  to validate the contents of the remote URL contents
-
-### Bug fixes and enhancements
-
-- Variable substitution now supports additional POSIX compatible variants without `:`.
-  [moby/buildkit#3611](https://github.com/moby/buildkit/pull/3611)
-- Exported Windows images now contain OSVersion and OSFeatures values from base image.
-  [moby/buildkit#3619](https://github.com/moby/buildkit/pull/3619)
-- Changed the permissions for Heredocs to 0644.
-  [moby/buildkit#3992](https://github.com/moby/buildkit/pull/3992)
-
-## 1.5.2
-
-{{< release-date date="2023-02-14" >}}
-
-### Bug fixes and enhancements
-
-- Fix building from Git reference that is missing branch name but contains a
-  subdir
-- 386 platform image is now included in the release
-
-## 1.5.1
-
-{{< release-date date="2023-01-18" >}}
-
-### Bug fixes and enhancements
-
-- Fix possible panic when warning conditions appear in multi-platform builds
-
-## 1.5.0 (labs)
-
-{{< release-date date="2023-01-10" >}}
-
-{{% include "dockerfile-labs-channel.md" %}}
-
-### New
-
-- `ADD` command now supports [`--checksum` flag](/reference/dockerfile.md#verifying-a-remote-file-checksum-add---checksumchecksum-http-src-dest)
-  to validate the contents of the remote URL contents
-
-## 1.5.0
-
-{{< release-date date="2023-01-10" >}}
-
-### New
-
-- `ADD` command can now [import files directly from Git URLs](/reference/dockerfile.md#adding-a-git-repository-add-git-ref-dir)
-
-### Bug fixes and enhancements
-
-- Named contexts now support `oci-layout://` protocol for including images from
-  local OCI layout structure
-- Dockerfile now supports secondary requests for listing all build targets or
-  printing outline of accepted parameters for a specific build target
-- Dockerfile `#syntax` directive that redirects to an external frontend image
-  now allows the directive to be also set with `//` comments or JSON. The file
-  may also contain a shebang header
-- Named context can now be initialized with an empty scratch image
-- Named contexts can now be initialized with an SSH Git URL
-- Fix handling of `ONBUILD` when importing Schema1 images
-
-## 1.4.3
-
-{{< release-date date="2022-08-23" >}}
-
-### Bug fixes and enhancements
-
-- Fix creation timestamp not getting reset when building image from
-  `docker-image://` named context
-- Fix passing `--platform` flag of `FROM` command when loading
-  `docker-image://` named context
-
-## 1.4.2
-
-{{< release-date date="2022-05-06" >}}
-
-### Bug fixes and enhancements
-
-- Fix loading certain environment variables from an image passed with built
-  context
-
-## 1.4.1
-
-{{< release-date date="2022-04-08" >}}
-
-### Bug fixes and enhancements
-
-- Fix named context resolution for cross-compilation cases from input when input
-  is built for a different platform
-
-## 1.4.0
-
-{{< release-date date="2022-03-09" >}}
-
-### New
-
-- [`COPY --link` and `ADD --link`](/reference/dockerfile.md#copy---link)
-  allow copying files with increased cache efficiency and rebase images without
-  requiring them to be rebuilt. `--link` copies files to a separate layer and
-  then uses new LLB MergeOp implementation to chain independent layers together
-- [Heredocs](/reference/dockerfile.md#here-documents) support have
-  been promoted from labs channel to stable. This feature allows writing
-  multiline inline scripts and files
-- Additional [named build contexts](/reference/cli/docker/buildx/build.md#build-context)
-  can be passed to build to add or overwrite a stage or an image inside the
-  build. A source for the context can be a local source, image, Git, or HTTP URL
-- [`BUILDKIT_SANDBOX_HOSTNAME` build-arg](/reference/dockerfile.md#buildkit-built-in-build-args)
-  can be used to set the default hostname for the `RUN` steps
-
-### Bug fixes and enhancements
-
-- When using a cross-compilation stage, the target platform for a step is now
-  seen on progress output
-- Fix some cases where Heredocs incorrectly removed quotes from content
-
-## 1.3.1
-
-{{< release-date date="2021-10-04" >}}
-
-### Bug fixes and enhancements
-
-- Fix parsing "required" mount key without a value
-
-## 1.3.0 (labs)
-
-{{< release-date date="2021-07-16" >}}
-
-{{% include "dockerfile-labs-channel.md" %}}
-
-### New
-
-- `RUN` and `COPY` commands now support [Here-document syntax](/reference/dockerfile.md#here-documents)
-  allowing writing multiline inline scripts and files
-
-## 1.3.0
-
-{{< release-date date="2021-07-16" >}}
-
-### New
-
-- `RUN` command allows [`--network` flag](/reference/dockerfile.md#run---network)
-  for requesting a specific type of network conditions. `--network=host`
-  requires allowing `network.host` entitlement. This feature was previously
-  only available on labs channel
-
-### Bug fixes and enhancements
-
-- `ADD` command with a remote URL input now correctly handles the `--chmod` flag
-- Values for [`RUN --mount` flag](/reference/dockerfile.md#run---mount)
-  now support variable expansion, except for the `from` field
-- Allow [`BUILDKIT_MULTI_PLATFORM` build arg](/reference/dockerfile.md#buildkit-built-in-build-args)
-  to force always creating multi-platform image, even if only contains single
-  platform
-
-## 1.2.1 (labs)
-
-{{< release-date date="2020-12-12" >}}
-
-{{% include "dockerfile-labs-channel.md" %}}
-
-### Bug fixes and enhancements
-
-- `RUN` command allows [`--network` flag](/reference/dockerfile.md#run---network)
-  for requesting a specific type of network conditions. `--network=host`
-  requires allowing `network.host` entitlement
-
-## 1.2.1
-
-{{< release-date date="2020-12-12" >}}
-
-### Bug fixes and enhancements
-
-- Revert "Ensure ENTRYPOINT command has at least one argument"
-- Optimize processing `COPY` calls on multi-platform cross-compilation builds
-
-## 1.2.0 (labs)
-
-{{< release-date date="2020-12-03" >}}
-
-{{% include "dockerfile-labs-channel.md" %}}
-
-### Bug fixes and enhancements
-
-- Experimental channel has been renamed to _labs_
-
-## 1.2.0
-
-{{< release-date date="2020-12-03" >}}
-
-### New
-
-- [`RUN --mount` syntax](/reference/dockerfile.md#run---mount) for
-  creating secret, ssh, bind, and cache mounts have been moved to mainline
-  channel
-- [`ARG` command](/reference/dockerfile.md#arg) now supports defining
-  multiple build args on the same line similarly to `ENV`
-
-### Bug fixes and enhancements
-
-- Metadata load errors are now handled as fatal to avoid incorrect build results
-- Allow lowercase Dockerfile name
-- `--chown` flag in `ADD` now allows parameter expansion
-- `ENTRYPOINT` requires at least one argument to avoid creating broken images
-
-## 1.1.7
-
-{{< release-date date="2020-04-18" >}}
-
-### Bug fixes and enhancements
-
-- Forward `FrontendInputs` to the gateway
-
-## 1.1.2 (labs)
-
-{{< release-date date="2019-07-31" >}}
-
-{{% include "dockerfile-labs-channel.md" %}}
-
-### Bug fixes and enhancements
-
-- Allow setting security mode for a process with `RUN --security=sandbox|insecure`
-- Allow setting uid/gid for [cache mounts](/reference/dockerfile.md#run---mounttypecache)
-- Avoid requesting internally linked paths to be pulled to build context
-- Ensure missing cache IDs default to target paths
-- Allow setting namespace for cache mounts with [`BUILDKIT_CACHE_MOUNT_NS` build arg](/reference/dockerfile.md#buildkit-built-in-build-args)
-
-## 1.1.2
-
-{{< release-date date="2019-07-31" >}}
-
-### Bug fixes and enhancements
-
-- Fix workdir creation with correct user and don't reset custom ownership
-- Fix handling empty build args also used as `ENV`
-- Detect circular dependencies
-
-## 1.1.0
-
-{{< release-date date="2019-04-27" >}}
-
-### New
-
-- `ADD/COPY` commands now support implementation based on `llb.FileOp` and do
-  not require helper image if builtin file operations support is available
-- `--chown` flag for `COPY` command now supports variable expansion
-
-### Bug fixes and enhancements
-
-- To find the files ignored from the build context Dockerfile frontend will
-  first look for a file `<path/to/Dockerfile>.dockerignore` and if it is not
-  found `.dockerignore` file will be looked up from the root of the build
-  context. This allows projects with multiple Dockerfiles to use different
-  `.dockerignore` definitions
diff --git a/content/manuals/build/cache/backends/_index.md b/content/manuals/build/cache/backends/_index.md
index de54ea0f6cec..aac96afbdd07 100644
--- a/content/manuals/build/cache/backends/_index.md
+++ b/content/manuals/build/cache/backends/_index.md
@@ -25,7 +25,7 @@ Other cache backends require you to select a different [driver](/manuals/build/b
 >
 > If you use secrets or credentials inside your build process, ensure you
 > manipulate them using the dedicated
-> [`--secret` option](/reference/cli/docker/buildx/build.md#secret).
+> [`--secret` option](/reference/cli/docker/buildx/build/#secret).
 > Manually managing secrets using `COPY` or `ARG` could result in leaked
 > credentials.
 
@@ -56,9 +56,9 @@ Buildx supports the following cache storage backends:
 ## Command syntax
 
 To use any of the cache backends, you first need to specify it on build with the
-[`--cache-to` option](/reference/cli/docker/buildx/build.md#cache-to)
+[`--cache-to` option](/reference/cli/docker/buildx/build/#cache-to)
 to export the cache to your storage backend of choice. Then, use the
-[`--cache-from` option](/reference/cli/docker/buildx/build.md#cache-from)
+[`--cache-from` option](/reference/cli/docker/buildx/build/#cache-from)
 to import the cache from the storage backend into the current build. Unlike the
 local BuildKit cache (which is always enabled), all of the cache storage
 backends must be explicitly exported to, and explicitly imported from.
@@ -179,3 +179,6 @@ $ docker buildx build --push -t <registry>/<image> \
   --cache-to type=registry,ref=<registry>/<cache-image>,oci-mediatypes=true,image-manifest=true \
   --cache-from type=registry,ref=<registry>/<cache-image> .
 ```
+
+> [!NOTE]
+> Since BuildKit v0.21, `image-manifest` is enabled by default.
diff --git a/content/manuals/build/cache/backends/gha.md b/content/manuals/build/cache/backends/gha.md
index 9b3f5c1040d0..81b239995988 100644
--- a/content/manuals/build/cache/backends/gha.md
+++ b/content/manuals/build/cache/backends/gha.md
@@ -30,21 +30,23 @@ $ docker buildx build --push -t <registry>/<image> \
 The following table describes the available CSV parameters that you can pass to
 `--cache-to` and `--cache-from`.
 
-| Name           | Option                  | Type        | Default                  | Description                                                          |
-|----------------|-------------------------|-------------|--------------------------|----------------------------------------------------------------------|
-| `url`          | `cache-to`,`cache-from` | String      | `$ACTIONS_CACHE_URL`     | Cache server URL, see [authentication][1].                           |
-| `url_v2`       | `cache-to`,`cache-from` | String      | `$ACTIONS_CACHE_URL`     | Cache v2 server URL, see [authentication][1].                        |
-| `token`        | `cache-to`,`cache-from` | String      | `$ACTIONS_RUNTIME_TOKEN` | Access token, see [authentication][1].                               |
-| `scope`        | `cache-to`,`cache-from` | String      | `buildkit`               | Which scope cache object belongs to, see [scope][2]                  |
-| `mode`         | `cache-to`              | `min`,`max` | `min`                    | Cache layers to export, see [cache mode][3].                         |
-| `ignore-error` | `cache-to`              | Boolean     | `false`                  | Ignore errors caused by failed cache exports.                        |
-| `timeout`      | `cache-to`,`cache-from` | String      | `10m`                    | Max duration for importing or exporting cache before it's timed out. |
-| `repository`   | `cache-to`              | String      |                          | GitHub repository used for cache storage.                            |
-| `ghtoken`      | `cache-to`              | String      |                          | GitHub token required for accessing the GitHub API.                  |
+| Name           | Option                  | Type        | Default                                        | Description                                                          |
+|----------------|-------------------------|-------------|------------------------------------------------|----------------------------------------------------------------------|
+| `url`          | `cache-to`,`cache-from` | String      | `$ACTIONS_CACHE_URL` or `$ACTIONS_RESULTS_URL` | Cache server URL, see [authentication][1]. Ignored when `version=2`. |
+| `url_v2`       | `cache-to`,`cache-from` | String      | `$ACTIONS_RESULTS_URL`                         | Cache v2 server URL, see [authentication][1].                        |
+| `token`        | `cache-to`,`cache-from` | String      | `$ACTIONS_RUNTIME_TOKEN`                       | Access token, see [authentication][1].                               |
+| `scope`        | `cache-to`,`cache-from` | String      | `buildkit`                                     | Which scope cache object belongs to, see [scope][2]                  |
+| `mode`         | `cache-to`              | `min`,`max` | `min`                                          | Cache layers to export, see [cache mode][3].                         |
+| `ignore-error` | `cache-to`              | Boolean     | `false`                                        | Ignore errors caused by failed cache exports.                        |
+| `timeout`      | `cache-to`,`cache-from` | String      | `10m`                                          | Max duration for importing or exporting cache before it's timed out. |
+| `repository`   | `cache-to`              | String      |                                                | GitHub repository used for cache storage.                            |
+| `ghtoken`      | `cache-to`              | String      |                                                | GitHub token required for accessing the GitHub API.                  |
+| `version`      | `cache-to`,`cache-from` | String      | `1` unless `$ACTIONS_CACHE_SERVICE_V2` is set, then `2` | Selects GitHub Actions cache version, see [version][4]      |
 
 [1]: #authentication
 [2]: #scope
 [3]: _index.md#cache-mode
+[4]: #version
 
 ## Authentication
 
@@ -78,6 +80,15 @@ GitHub's [cache access restrictions](https://docs.github.com/en/actions/advanced
 still apply. Only the cache for the current branch, the base branch and the
 default branch is accessible by a workflow.
 
+## Version
+
+If you don’t set `version` explicitly, the default is v1. However, if the environment variable `$ACTIONS_CACHE_SERVICE_V2` is set to a value interpreted as `true` ( `1`, `true`, `yes`), then v2 is used automatically.
+
+Only one URL is relevant at a time:
+
+ - With v1, use `url` (defaults to `$ACTIONS_CACHE_URL`).
+ - With v2, use `url_v2` (defaults to `$ACTIONS_RESULTS_URL`).
+
 ### Using `docker/build-push-action`
 
 When using the
@@ -89,7 +100,7 @@ For example:
 
 ```yaml
 - name: Build and push
-  uses: docker/build-push-action@v6
+  uses: docker/build-push-action@{{% param "build_push_action_version" %}}
   with:
     context: .
     push: true
@@ -138,7 +149,7 @@ action. You can also set the `ghtoken` parameter manually using the
 
 ```yaml
 - name: Build and push
-  uses: docker/build-push-action@v6
+  uses: docker/build-push-action@{{% param "build_push_action_version" %}}
   with:
     context: .
     push: true
diff --git a/content/manuals/build/cache/backends/local.md b/content/manuals/build/cache/backends/local.md
index 5d033bf27549..577e94566867 100644
--- a/content/manuals/build/cache/backends/local.md
+++ b/content/manuals/build/cache/backends/local.md
@@ -25,13 +25,14 @@ The following table describes the available CSV parameters that you can pass to
 `--cache-to` and `--cache-from`.
 
 | Name                | Option       | Type                    | Default | Description                                                                                                                     |
-| ------------------- | ------------ | ----------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------- |
+|---------------------|--------------|-------------------------|---------|---------------------------------------------------------------------------------------------------------------------------------|
 | `src`               | `cache-from` | String                  |         | Path of the local directory where cache gets imported from.                                                                     |
 | `digest`            | `cache-from` | String                  |         | Digest of manifest to import, see [cache versioning][4].                                                                        |
+| `tag`               | `cache-to`,`cache-from` | String                  | `latest` | Tag of the cache manifest, see [cache versioning][4].                                                                          |
 | `dest`              | `cache-to`   | String                  |         | Path of the local directory where cache gets exported to.                                                                       |
 | `mode`              | `cache-to`   | `min`,`max`             | `min`   | Cache layers to export, see [cache mode][1].                                                                                    |
 | `oci-mediatypes`    | `cache-to`   | `true`,`false`          | `true`  | Use OCI media types in exported manifests, see [OCI media types][2].                                                            |
-| `image-manifest`    | `cache-to`   | `true`,`false`          | `false` | When using OCI media types, generate an image manifest instead of an image index for the cache image, see [OCI media types][2]. |
+| `image-manifest`    | `cache-to`   | `true`,`false`          | `true`  | When using OCI media types, generate an image manifest instead of an image index for the cache image, see [OCI media types][2]. |
 | `compression`       | `cache-to`   | `gzip`,`estargz`,`zstd` | `gzip`  | Compression type, see [cache compression][3].                                                                                   |
 | `compression-level` | `cache-to`   | `0..22`                 |         | Compression level, see [cache compression][3].                                                                                  |
 | `force-compression` | `cache-to`   | `true`,`false`          | `false` | Forcibly apply compression, see [cache compression][3].                                                                         |
@@ -47,49 +48,42 @@ build continues.
 
 ## Cache versioning
 
-<!-- FIXME: update once https://github.com/moby/buildkit/pull/3111 is released -->
+A local cache directory uses an OCI image layout. Its `index.json` file
+associates tags with cache manifests, while the `blobs` directory stores the
+manifest and cache data.
 
-This section describes how versioning works for caches on a local filesystem,
-and how you can use the `digest` parameter to use older versions of cache.
-
-If you inspect the cache directory manually, you can see the resulting OCI image
-layout:
+By default, BuildKit exports and imports the cache tagged `latest`. Use
+different tags to keep multiple caches in the same directory:
 
 ```console
-$ ls cache
-blobs  index.json  ingest
-$ cat cache/index.json | jq
-{
-  "schemaVersion": 2,
-  "manifests": [
-    {
-      "mediaType": "application/vnd.oci.image.index.v1+json",
-      "digest": "sha256:6982c70595cb91769f61cd1e064cf5f41d5357387bab6b18c0164c5f98c1f707",
-      "size": 1560,
-      "annotations": {
-        "org.opencontainers.image.ref.name": "latest"
-      }
-    }
-  ]
-}
+$ docker buildx build --cache-to type=local,dest=path/to/local/dir,tag=v1 .
+$ docker buildx build --cache-to type=local,dest=path/to/local/dir,tag=v2 .
 ```
 
-Like other cache types, local cache gets replaced on export, by replacing the
-contents of the `index.json` file. However, previous caches will still be
-available in the `blobs` directory. These old caches are addressable by digest,
-and kept indefinitely. Therefore, the size of the local cache will continue to
-grow (see [`moby/buildkit#1896`](https://github.com/moby/buildkit/issues/1896)
-for more information).
+Exporting another cache with the same tag updates that tag to reference the new
+manifest. Manifests referenced by other tags remain unchanged.
 
-When importing cache using `--cache-from`, you can specify the `digest` parameter
-to force loading an older version of the cache, for example:
+Import a cache by specifying its tag:
 
 ```console
-$ docker buildx build --push -t <registry>/<image> \
-  --cache-to type=local,dest=path/to/local/dir \
-  --cache-from type=local,ref=path/to/local/dir,digest=sha256:6982c70595cb91769f61cd1e064cf5f41d5357387bab6b18c0164c5f98c1f707 .
+$ docker buildx build --cache-from type=local,src=path/to/local/dir,tag=v1 .
+```
+
+A digest identifies an exact cache manifest. BuildKit reports the digest of
+each exported manifest in the build output. Use `digest` instead of `tag` when
+you need a specific manifest:
+
+```console
+$ docker buildx build \
+  --cache-from type=local,src=path/to/local/dir,digest=sha256:<DIGEST> .
 ```
 
+If you specify both `digest` and `tag`, BuildKit uses `digest`.
+
+By default, updating a tag doesn't delete the blobs used by its previous
+manifest. The previous manifest remains available by digest, so the local cache
+directory grows over time.
+
 ## Further reading
 
 For an introduction to caching see [Docker build cache](../_index.md).
diff --git a/content/manuals/build/cache/backends/registry.md b/content/manuals/build/cache/backends/registry.md
index 9a4ff0d1a027..4aacff60b451 100644
--- a/content/manuals/build/cache/backends/registry.md
+++ b/content/manuals/build/cache/backends/registry.md
@@ -18,8 +18,9 @@ everything that the inline cache can do, and more:
 - It works with other exporters for more flexibility, instead of only the
   `image` exporter.
 
-This cache storage backend is not supported with the default `docker` driver.
-To use this feature, create a new builder using a different driver. See
+This cache storage backend works with the default `docker` driver only when the
+[containerd image store](/manuals/desktop/features/containerd.md) is enabled. If
+the containerd image store isn't enabled, use a different driver. See
 [Build drivers](/manuals/build/builders/drivers/_index.md) for more information.
 
 ## Synopsis
@@ -37,11 +38,11 @@ The following table describes the available CSV parameters that you can pass to
 `--cache-to` and `--cache-from`.
 
 | Name                | Option                  | Type                    | Default | Description                                                                                                                     |
-| ------------------- | ----------------------- | ----------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------- |
+|---------------------|-------------------------|-------------------------|---------|---------------------------------------------------------------------------------------------------------------------------------|
 | `ref`               | `cache-to`,`cache-from` | String                  |         | Full name of the cache image to import.                                                                                         |
 | `mode`              | `cache-to`              | `min`,`max`             | `min`   | Cache layers to export, see [cache mode][1].                                                                                    |
 | `oci-mediatypes`    | `cache-to`              | `true`,`false`          | `true`  | Use OCI media types in exported manifests, see [OCI media types][2].                                                            |
-| `image-manifest`    | `cache-to`              | `true`,`false`          | `false` | When using OCI media types, generate an image manifest instead of an image index for the cache image, see [OCI media types][2]. |
+| `image-manifest`    | `cache-to`              | `true`,`false`          | `true`  | When using OCI media types, generate an image manifest instead of an image index for the cache image, see [OCI media types][2]. |
 | `compression`       | `cache-to`              | `gzip`,`estargz`,`zstd` | `gzip`  | Compression type, see [cache compression][3].                                                                                   |
 | `compression-level` | `cache-to`              | `0..22`                 |         | Compression level, see [cache compression][3].                                                                                  |
 | `force-compression` | `cache-to`              | `true`,`false`          | `false` | Forcibly apply compression, see [cache compression][3].                                                                         |
diff --git a/content/manuals/build/cache/backends/s3.md b/content/manuals/build/cache/backends/s3.md
index abfbfe80c20f..99831816ca38 100644
--- a/content/manuals/build/cache/backends/s3.md
+++ b/content/manuals/build/cache/backends/s3.md
@@ -27,22 +27,23 @@ $ docker buildx build --push -t <user>/<image> \
 The following table describes the available CSV parameters that you can pass to
 `--cache-to` and `--cache-from`.
 
-| Name                 | Option                  | Type        | Default | Description                                                    |
-| -------------------- | ----------------------- | ----------- | ------- | -------------------------------------------------------------- |
-| `region`             | `cache-to`,`cache-from` | String      |         | Required. Geographic location.                                 |
-| `bucket`             | `cache-to`,`cache-from` | String      |         | Required. Name of the S3 bucket.                               |
-| `name`               | `cache-to`,`cache-from` | String      |         | Name of the cache image.                                       |
-| `endpoint_url`       | `cache-to`,`cache-from` | String      |         | Endpoint of the S3 bucket.                                     |
-| `blobs_prefix`       | `cache-to`,`cache-from` | String      |         | Prefix to prepend to blob filenames.                           |
-| `upload_parallelism` | `cache-to`              | Integer     | `4`     | Number of parallel layer uploads.                              |
-| `touch_refresh`      | `cache-to`              | Time        | `24h`   | Interval for updating the timestamp of unchanged cache layers. |
-| `manifests_prefix`   | `cache-to`,`cache-from` | String      |         | Prefix to prepend on manifest filenames.                       |
-| `use_path_style`     | `cache-to`,`cache-from` | Boolean     | `false` | When `true`, uses `bucket` in the URL instead of hostname.     |
-| `access_key_id`      | `cache-to`,`cache-from` | String      |         | See [authentication][1].                                       |
-| `secret_access_key`  | `cache-to`,`cache-from` | String      |         | See [authentication][1].                                       |
-| `session_token`      | `cache-to`,`cache-from` | String      |         | See [authentication][1].                                       |
-| `mode`               | `cache-to`              | `min`,`max` | `min`   | Cache layers to export, see [cache mode][2].                   |
-| `ignore-error`       | `cache-to`              | Boolean     | `false` | Ignore errors caused by failed cache exports.                  |
+| Name                 | Option                  | Type        | Default      | Description                                                    |
+|----------------------| ----------------------- | ----------- |--------------|----------------------------------------------------------------|
+| `region`             | `cache-to`,`cache-from` | String      |              | Required. Geographic location.                                 |
+| `bucket`             | `cache-to`,`cache-from` | String      |              | Required. Name of the S3 bucket.                               |
+| `name`               | `cache-to`,`cache-from` | String      | `buildkit`   | Name of the cache image.                                       |
+| `endpoint_url`       | `cache-to`,`cache-from` | String      |              | Endpoint of the S3 bucket.                                     |
+| `prefix`             | `cache-to`,`cache-from` | String      |              | Prefix to prepend to all filenames.                            |
+| `blobs_prefix`       | `cache-to`,`cache-from` | String      | `blobs/`     | Prefix to prepend to blob filenames.                           |
+| `upload_parallelism` | `cache-to`              | Integer     | `4`          | Number of parallel layer uploads.                              |
+| `touch_refresh`      | `cache-to`              | Time        | `24h`        | Interval for updating the timestamp of unchanged cache layers. |
+| `manifests_prefix`   | `cache-to`,`cache-from` | String      | `manifests/` | Prefix to prepend to manifest filenames.                       |
+| `use_path_style`     | `cache-to`,`cache-from` | Boolean     | `false`      | When `true`, uses `bucket` in the URL instead of hostname.     |
+| `access_key_id`      | `cache-to`,`cache-from` | String      |              | See [authentication][1].                                       |
+| `secret_access_key`  | `cache-to`,`cache-from` | String      |              | See [authentication][1].                                       |
+| `session_token`      | `cache-to`,`cache-from` | String      |              | See [authentication][1].                                       |
+| `mode`               | `cache-to`              | `min`,`max` | `min`        | Cache layers to export, see [cache mode][2].                   |
+| `ignore-error`       | `cache-to`              | Boolean     | `false`      | Ignore errors caused by failed cache exports.                  |
 
 [1]: #authentication
 [2]: _index.md#cache-mode
@@ -57,7 +58,7 @@ Alternatively, you can use the `access_key_id`, `secret_access_key`, and
 Refer to [AWS Go SDK, Specifying Credentials][3] for details about
 authentication using environment variables and credentials file.
 
-[3]: https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials
+[3]: https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/configure-gosdk.html#specifying-credentials
 
 ## Further reading
 
diff --git a/content/manuals/build/cache/garbage-collection.md b/content/manuals/build/cache/garbage-collection.md
index 9e35068d24cf..7609bab11a08 100644
--- a/content/manuals/build/cache/garbage-collection.md
+++ b/content/manuals/build/cache/garbage-collection.md
@@ -6,8 +6,8 @@ aliases:
   - /build/building/cache/garbage-collection/
 ---
 
-While [`docker builder prune`](/reference/cli/docker/builder/prune.md)
-or [`docker buildx prune`](/reference/cli/docker/buildx/prune.md)
+While [`docker builder prune`](/reference/cli/docker/builder/prune/)
+or [`docker buildx prune`](/reference/cli/docker/buildx/prune/)
 commands run at once, Garbage Collection (GC) runs periodically and follows an
 ordered list of prune policies. The BuildKit daemon clears the build cache when
 the cache size becomes too big, or when the cache age expires.
@@ -119,15 +119,15 @@ default GC policies resolve to:
       "enabled": true,
       "policy": [
         {
-          "keepStorage": "2.764GB",
+          "reservedSpace": "2.764GB",
+          "keepDuration": "48h",
           "filter": [
-            "unused-for=48h",
-            "type==source.local,type==exec.cachemount,type==source.git.checkout"
+            "type=source.local,type=exec.cachemount,type=source.git.checkout"
           ]
         },
-        { "keepStorage": "20GB", "filter": ["unused-for=1440h"] },
-        { "keepStorage": "20GB" },
-        { "keepStorage": "20GB", "all": true }
+        { "reservedSpace": "20GB", "keepDuration": ["1440h"] },
+        { "reservedSpace": "20GB" },
+        { "reservedSpace": "20GB", "all": true }
       ]
     }
   }
@@ -140,6 +140,8 @@ is to adjust the `defaultKeepStorage` option:
 - Increase the limit if you feel like you think the GC is too aggressive.
 - Decrease the limit if you need to preserve space.
 
+#### Custom GC policies in the Docker daemon configuration file
+
 If you need even more control, you can define your own GC policies directly.
 The following example defines a more conservative GC configuration with the
 following policies:
@@ -153,19 +155,30 @@ following policies:
   "builder": {
     "gc": {
       "enabled": true,
-      "defaultKeepStorage": "50GB",
       "policy": [
-        { "keepStorage": "0", "filter": ["unused-for=1440h"] },
-        { "keepStorage": "0" },
-        { "keepStorage": "100GB", "all": true }
+        { "reservedSpace": "50GB", "keepDuration": ["1440h"] },
+        { "reservedSpace": "50GB" },
+        { "reservedSpace": "100GB", "all": true }
       ]
     }
   }
 }
 ```
 
-Policies 1 and 2 here set `keepStorage` to `0`, which means they'll fall back
-to the default limit of 50GB as defined by `defaultKeepStorage`.
+> [!NOTE]
+> In the Docker daemon configuration file, the "equals" operator in GC filters
+> is denoted using a single `=`, whereas BuildKit's configuration file uses
+> `==`:
+>
+> | `daemon.json`       | `buildkitd.toml`     |
+> |---------------------|----------------------|
+> | `type=source.local` | `type==source.local` |
+> | `private=true`      | `private==true`      |
+> | `shared=true`       | `shared==true`       |
+>
+> See [prune filters](/reference/cli/docker/buildx/prune/#filter) for
+> information about available GC filters. GC configuration in `daemon.json`
+> supports all filters except `mutable` and `immutable`.
 
 ### BuildKit configuration file
 
@@ -288,3 +301,6 @@ when defining a GC policy you have two additional configuration options:
   pruned.
 - `filters`: Filters let you specify specific types of cache records that a GC
   policy is allowed to prune.
+
+See [buildx prune filters](/reference/cli/docker/buildx/prune/#filter) for
+information about available GC filters.
diff --git a/content/manuals/build/cache/invalidation.md b/content/manuals/build/cache/invalidation.md
index 535f3df28162..4bf3ee7d327f 100644
--- a/content/manuals/build/cache/invalidation.md
+++ b/content/manuals/build/cache/invalidation.md
@@ -44,6 +44,23 @@ If your build contains several layers and you want to ensure the build cache is
 reusable, order the instructions from less frequently changed to more
 frequently changed where possible.
 
+## WORKDIR and SOURCE_DATE_EPOCH
+
+The `WORKDIR` instruction respects the `SOURCE_DATE_EPOCH` build argument when
+determining cache validity. Changing `SOURCE_DATE_EPOCH` between builds
+invalidates the cache for `WORKDIR` and all subsequent instructions.
+
+`SOURCE_DATE_EPOCH` sets timestamps for files created during the build. If you
+set this to a dynamic value like a Git commit timestamp, the cache breaks with
+each commit. This is expected behavior when tracking build provenance.
+
+For reproducible builds without frequent cache invalidation, use a fixed
+timestamp:
+
+```console
+$ docker build --build-arg SOURCE_DATE_EPOCH=0 .
+```
+
 ## RUN instructions
 
 The cache for `RUN` instructions isn't invalidated automatically between builds.
@@ -60,7 +77,7 @@ To force a re-execution of the `RUN` instruction, you can:
 
 - Make sure that a layer before it has changed
 - Clear the build cache ahead of the build using
-  [`docker builder prune`](/reference/cli/docker/builder/prune.md)
+  [`docker builder prune`](/reference/cli/docker/builder/prune/)
 - Use the `--no-cache` or `--no-cache-filter` options
 
 The `--no-cache-filter` option lets you specify a specific build stage to
diff --git a/content/manuals/build/cache/optimize.md b/content/manuals/build/cache/optimize.md
index 3e0dfed9f78f..efc696738c69 100644
--- a/content/manuals/build/cache/optimize.md
+++ b/content/manuals/build/cache/optimize.md
@@ -116,13 +116,16 @@ instruction in your Dockerfile:
 
 ```dockerfile
 FROM golang:latest
-WORKDIR /app
+WORKDIR /build
 RUN --mount=type=bind,target=. go build -o /app/hello
 ```
 
-In this example, the current directory is mounted into the build container
-before the `go build` command gets executed. The source code is available in
-the build container for the duration of that `RUN` instruction. When the
+In this example, the current directory is mounted into the build container at
+`/build` before the `go build` command gets executed. The build output is
+written to `/app/hello`, which is outside the mount point. This distinction is
+important: the build output must be written outside the bind mount target,
+since the mount is read-only by default. The source code is available in the
+build container for the duration of that `RUN` instruction. When the
 instruction is done executing, the mounted files are not persisted in the final
 image, or in the build cache. Only the output of the `go build` command
 remains.
@@ -225,6 +228,7 @@ tool you're using. Here are a few examples:
 
 ```dockerfile
 RUN --mount=type=cache,target=/go/pkg/mod \
+    --mount=type=cache,target=/root/.cache/go-build \
     go build -o /app/hello
 ```
 
@@ -258,11 +262,15 @@ RUN --mount=type=cache,target=/root/.gem \
 
 ```dockerfile
 RUN --mount=type=cache,target=/app/target/ \
-    --mount=type=cache,target=/usr/local/cargo/git/db \
-    --mount=type=cache,target=/usr/local/cargo/registry/ \
-    cargo build
+    --mount=type=cache,target=/var/cache/cargo \
+    CARGO_HOME=/var/cache/cargo cargo build
 ```
 
+The cache mount uses a single `CARGO_HOME` so concurrent builds coordinate
+access through Cargo's cache lock. Setting `CARGO_HOME` also changes where
+Cargo looks for global configuration and credentials. Project-level
+`.cargo/config.toml` files are unaffected.
+
 {{< /tab >}}
 {{< tab name=".NET" >}}
 
@@ -324,16 +332,16 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: true
           tags: user/app:latest
diff --git a/content/manuals/build/checks.md b/content/manuals/build/checks.md
index afbf82392668..a6aa1f18828d 100644
--- a/content/manuals/build/checks.md
+++ b/content/manuals/build/checks.md
@@ -1,12 +1,7 @@
 ---
 title: Checking your build configuration
 linkTitle: Build checks
-params:
-  sidebar:
-    badge:
-      color: green
-      text: New
-weight: 30
+weight: 20
 description: Learn how to use build checks to validate your build configuration.
 keywords: build, buildx, buildkit, checks, validate, configuration, lint
 ---
@@ -38,8 +33,8 @@ Build checks are useful for:
 
 > [!TIP]
 >
-> Want a better editing experience for Dockerfiles in VS Code?
-> Check out the [Docker VS Code Extension (Beta)](https://marketplace.visualstudio.com/items?itemName=docker.docker) for linting, code navigation, and vulnerability scanning.
+> To improve linting, code navigation, and vulnerability scanning of your Dockerfiles in Visual Studio Code
+> see the [Docker DX](https://marketplace.visualstudio.com/items?itemName=docker.docker) extension.
 
 ## Build with checks
 
@@ -79,7 +74,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Build and push
-        uses: docker/build-push-action@v6.6.0
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
 ```
 
 ![GitHub Actions build check annotations](./images/gha-check-annotations.png)
diff --git a/content/manuals/build/ci/github-actions/_index.md b/content/manuals/build/ci/github-actions/_index.md
index 4f80a110be52..68968242d5c3 100644
--- a/content/manuals/build/ci/github-actions/_index.md
+++ b/content/manuals/build/ci/github-actions/_index.md
@@ -29,7 +29,7 @@ The following GitHub Actions are available:
 - [Docker Setup Compose](https://github.com/marketplace/actions/docker-setup-compose):
   installs and sets up [Compose](../../../compose).
 - [Docker Setup Docker](https://github.com/marketplace/actions/docker-setup-docker):
-  installs Docker CE.
+  installs Docker Engine.
 - [Docker Setup QEMU](https://github.com/marketplace/actions/docker-setup-qemu):
   installs [QEMU](https://github.com/qemu/qemu) static binaries for
   multi-platform builds.
diff --git a/content/manuals/build/ci/github-actions/annotations.md b/content/manuals/build/ci/github-actions/annotations.md
index 5491d671b9de..6faee4ab38d6 100644
--- a/content/manuals/build/ci/github-actions/annotations.md
+++ b/content/manuals/build/ci/github-actions/annotations.md
@@ -34,22 +34,22 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Extract metadata
         id: meta
-        uses: docker/metadata-action@v5
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
         with:
           images: ${{ env.IMAGE_NAME }}
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           tags: ${{ steps.meta.outputs.tags }}
           annotations: ${{ steps.meta.outputs.annotations }}
@@ -73,22 +73,22 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
       
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Extract metadata
         id: meta
-        uses: docker/metadata-action@v5
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
         with:
           images: ${{ env.IMAGE_NAME }}
 
       - name: Build
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@{{% param "bake_action_version" %}}
         with:
           files: |
             ./docker-bake.hcl
@@ -126,24 +126,24 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
       
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Extract metadata
         id: meta
-        uses: docker/metadata-action@v5
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
         with:
           images: ${{ env.IMAGE_NAME }}
         env:
           DOCKER_METADATA_ANNOTATIONS_LEVELS: manifest,index
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           tags: ${{ steps.meta.outputs.tags }}
           annotations: ${{ steps.meta.outputs.annotations }}
diff --git a/content/manuals/build/ci/github-actions/attestations.md b/content/manuals/build/ci/github-actions/attestations.md
index eb99baf0d2da..75a1c822b72e 100644
--- a/content/manuals/build/ci/github-actions/attestations.md
+++ b/content/manuals/build/ci/github-actions/attestations.md
@@ -34,7 +34,7 @@ attestations to your image, with the following conditions:
 > arguments to pass secrets to your build, such as user credentials or
 > authentication tokens, those secrets are exposed in the provenance
 > attestation. Refactor your build to pass those secrets using
-> [secret mounts](/reference/cli/docker/buildx/build.md#secret)
+> [secret mounts](/reference/cli/docker/buildx/build/#secret)
 > instead. Also remember to rotate any secrets you may have exposed.
 
 ## Max-level provenance
@@ -63,22 +63,22 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
       
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Extract metadata
         id: meta
-        uses: docker/metadata-action@v5
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
         with:
           images: ${{ env.IMAGE_NAME }}
 
       - name: Build and push image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: true
           provenance: mode=max
@@ -109,22 +109,22 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Extract metadata
         id: meta
-        uses: docker/metadata-action@v5
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
         with:
           images: ${{ env.IMAGE_NAME }}
 
       - name: Build and push image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           sbom: true
           push: true
diff --git a/content/manuals/build/ci/github-actions/build-summary.md b/content/manuals/build/ci/github-actions/build-summary.md
index 9472ead8e685..6bf130667c64 100644
--- a/content/manuals/build/ci/github-actions/build-summary.md
+++ b/content/manuals/build/ci/github-actions/build-summary.md
@@ -19,8 +19,8 @@ versions of the [Build and push Docker images](https://github.com/marketplace/ac
 or [Docker Buildx Bake](https://github.com/marketplace/actions/docker-buildx-bake)
 GitHub Actions:
 
-- `docker/build-push-action@v6`
-- `docker/bake-action@v6`
+- `docker/build-push-action@{{% param "build_push_action_version" %}}`
+- `docker/bake-action@{{% param "bake_action_version" %}}`
 
 To view the job summary, open the details page for the job in GitHub after the
 job has finished. The summary is available for both failed and successful
@@ -31,8 +31,6 @@ message that caused the build to fail:
 
 ## Import build records to Docker Desktop
 
-{{< summary-bar feature_name="Import builds" >}}
-
 The job summary includes a link for downloading a build record archive for the
 run. The build record archive is a ZIP file containing the details about a build
 (or builds, if you use `docker/bake-action` to build multiple targets). You can
@@ -67,7 +65,7 @@ in the YAML configuration for your build step:
 
 ```yaml {hl_lines=4}
       - name: Build
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         env:
           DOCKER_BUILD_SUMMARY: false
         with:
@@ -83,7 +81,7 @@ your build step:
 
 ```yaml {hl_lines=4}
       - name: Build
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         env:
           DOCKER_BUILD_RECORD_UPLOAD: false
         with:
@@ -98,7 +96,5 @@ contain a link to download the build record archive.
 
 Build summaries are currently not supported for:
 
-- Builds using [Docker Build Cloud](/manuals/build-cloud/_index.md). Support for Docker
-  Build Cloud is planned for a future release.
 - Repositories hosted on GitHub Enterprise Servers. Summaries can only be
   viewed for repositories hosted on GitHub.com.
diff --git a/content/manuals/build/ci/github-actions/cache.md b/content/manuals/build/ci/github-actions/cache.md
index 5626447e1e43..ff3ed02f07bb 100644
--- a/content/manuals/build/ci/github-actions/cache.md
+++ b/content/manuals/build/ci/github-actions/cache.md
@@ -30,16 +30,16 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
-      
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
+
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: true
           tags: user/app:latest
@@ -63,16 +63,16 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
-      
+
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
-      
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
+
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: true
           tags: user/app:latest
@@ -104,16 +104,16 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
-      
+
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
-      
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
+
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: true
           tags: user/app:latest
@@ -123,14 +123,14 @@ jobs:
 
 > [!IMPORTANT]
 >
-> Starting [April 15th, 2025, only GitHub Cache service API v2 will be supported](https://gh.io/gha-cache-sunset).
-> 
+> As of April 15th, 2025, [only GitHub Cache service API v2 is supported.](https://gh.io/gha-cache-sunset). The legacy v1 API has been shut down.
+>
 > If you encounter the following error during your build:
-> 
+>
 > ```console
 > ERROR: failed to solve: This legacy service is shutting down, effective April 15, 2025. Migrate to the new service ASAP. For more information: https://gh.io/gha-cache-sunset
 > ```
-> 
+>
 > You're probably using outdated tools that only support the legacy GitHub
 > Cache service API v1. Here are the minimum versions you need to upgrade to
 > depending on your use case:
@@ -138,37 +138,37 @@ jobs:
 > * BuildKit >= v0.20.0
 > * Docker Compose >= v2.33.1
 > * Docker Engine >= v28.0.0 (if you're building using the Docker driver with containerd image store enabled)
-> 
+>
 > If you're building using the `docker/build-push-action` or `docker/bake-action`
 > actions on GitHub hosted runners, Docker Buildx and BuildKit are already up
 > to date but on self-hosted runners, you may need to update them yourself.
 > Alternatively, you can use the `docker/setup-buildx-action` action to install
 > the latest version of Docker Buildx:
-> 
+>
 > ```yaml
 > - name: Set up Docker Buildx
->   uses: docker/setup-buildx-action@v3
+>   uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 >   with:
 >    version: latest
 > ```
-> 
+>
 > If you're building using Docker Compose, you can use the
 > `docker/setup-compose-action` action:
-> 
+>
 > ```yaml
 > - name: Set up Docker Compose
->   uses: docker/setup-compose-action@v1
+>   uses: docker/setup-compose-action@{{% param "setup_compose_action_version" %}}
 >   with:
 >    version: latest
 > ```
-> 
+>
 > If you're building using the Docker Engine with the containerd image store
 > enabled, you can use the `docker/setup-docker-action` action:
-> 
+>
 > ```yaml
 > -
 >   name: Set up Docker
->   uses: docker/setup-docker-action@v4
+>   uses: docker/setup-docker-action@{{% param "setup_docker_action_version" %}}
 >   with:
 >     version: latest
 >     daemon-config: |
@@ -182,7 +182,7 @@ jobs:
 ### Cache mounts
 
 BuildKit doesn't preserve cache mounts in the GitHub Actions cache by default.
-If you wish to put your cache mounts into GitHub Actions cache and reuse it
+To put your cache mounts into GitHub Actions cache and reuse it
 between builds, you can use a workaround provided by
 [`reproducible-containers/buildkit-cache-dance`](https://github.com/reproducible-containers/buildkit-cache-dance).
 
@@ -197,13 +197,16 @@ Example Dockerfile in `build/package/Dockerfile`
 FROM golang:1.21.1-alpine as base-build
 
 WORKDIR /build
-RUN go env -w GOMODCACHE=/root/.cache/go-build
 
-COPY go.mod go.sum ./
-RUN --mount=type=cache,target=/root/.cache/go-build go mod download
+RUN --mount=type=cache,target=/go/pkg/mod \
+    --mount=type=bind,source=go.mod,target=go.mod \
+    --mount=type=bind,source=go.sum,target=go.sum \
+    go mod download
 
-COPY ./src ./
-RUN --mount=type=cache,target=/root/.cache/go-build go build -o /bin/app /build/src
+RUN --mount=type=cache,target=/go/pkg/mod \
+    --mount=type=cache,target=/root/.cache/go-build \
+    --mount=type=bind,target=. \
+    go build -o /bin/app ./src
 ...
 ```
 
@@ -220,20 +223,20 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
-      
+
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Docker meta
         id: meta
-        uses: docker/metadata-action@v5
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
         with:
           images: user/app
           tags: |
@@ -243,7 +246,7 @@ jobs:
             type=semver,pattern={{major}}.{{minor}}
 
       - name: Go Build Cache for Docker
-        uses: actions/cache@v4
+        uses: actions/cache@{{% param "cache_action_version" %}}
         with:
           path: go-build-cache
           key: ${{ runner.os }}-go-build-cache-${{ hashFiles('**/go.sum') }}
@@ -254,7 +257,7 @@ jobs:
           cache-source: go-build-cache
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           cache-from: type=gha
           cache-to: type=gha,mode=max
@@ -291,16 +294,16 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Cache Docker layers
-        uses: actions/cache@v4
+        uses: actions/cache@{{% param "cache_action_version" %}}
         with:
           path: ${{ runner.temp }}/.buildx-cache
           key: ${{ runner.os }}-buildx-${{ github.sha }}
@@ -308,7 +311,7 @@ jobs:
             ${{ runner.os }}-buildx-
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: true
           tags: user/app:latest
diff --git a/content/manuals/build/ci/github-actions/checks.md b/content/manuals/build/ci/github-actions/checks.md
index c9dbccff14cf..c9c15d468bdb 100644
--- a/content/manuals/build/ci/github-actions/checks.md
+++ b/content/manuals/build/ci/github-actions/checks.md
@@ -25,21 +25,21 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ secrets.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
       
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Validate build configuration
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           call: check
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: true
           tags: user/app:latest
@@ -79,22 +79,48 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Validate build configuration
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@{{% param "bake_action_version" %}}
         with:
           targets: validate-build
 
       - name: Build
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@{{% param "bake_action_version" %}}
         with:
           targets: build
           push: true
 ```
+
+### Using the `call` input directly
+
+You can also set the build method with the `call` input which is equivalent to using the `--call` flag with `docker buildx bake`
+
+For example, to run a check without defining `call` in your Bake file:
+
+```yaml
+name: ci
+
+on:
+  push:
+
+jobs:
+  docker:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
+
+      - name: Validate build configuration
+        uses: docker/bake-action@{{% param "bake_action_version" %}}
+        with:
+          targets: build
+          call: check
+```
diff --git a/content/manuals/build/ci/github-actions/configure-builder.md b/content/manuals/build/ci/github-actions/configure-builder.md
index 4d6bd1c981a6..65da9f0df77a 100644
--- a/content/manuals/build/ci/github-actions/configure-builder.md
+++ b/content/manuals/build/ci/github-actions/configure-builder.md
@@ -19,7 +19,7 @@ to pin to Buildx v0.10.0:
 
 ```yaml
 - name: Set up Docker Buildx
-  uses: docker/setup-buildx-action@v3
+  uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
   with:
     version: v0.10.0
 ```
@@ -29,7 +29,7 @@ To pin to a specific version of BuildKit, use the `image` option in the
 
 ```yaml
 - name: Set up Docker Buildx
-  uses: docker/setup-buildx-action@v3
+  uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
   with:
     driver-opts: image=moby/buildkit:v0.11.0
 ```
@@ -51,12 +51,12 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         with:
           buildkitd-flags: --debug
       
       - name: Build
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
 ```
 
 Logs will be available at the end of a job:
@@ -85,7 +85,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         with:
           buildkitd-config-inline: |
             [registry."docker.io"]
@@ -120,7 +120,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         with:
           config: .github/buildkitd.toml
 ```
@@ -140,11 +140,11 @@ fields:
 
 | Name              | Type   | Description                                                                                                                                                                                                                                                             |
 | ----------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `name`            | String | [Name of the node](/reference/cli/docker/buildx/create.md#node). If empty, it's the name of the builder it belongs to, with an index number suffix. This is useful to set it if you want to modify/remove a node in an underlying step of you workflow. |
-| `endpoint`        | String | [Docker context or endpoint](/reference/cli/docker/buildx/create.md#description) of the node to add to the builder                                                                                                                                      |
-| `driver-opts`     | List   | List of additional [driver-specific options](/reference/cli/docker/buildx/create.md#driver-opt)                                                                                                                                                         |
-| `buildkitd-flags` | String | [Flags for buildkitd](/reference/cli/docker/buildx/create.md#buildkitd-flags) daemon                                                                                                                                                                    |
-| `platforms`       | String | Fixed [platforms](/reference/cli/docker/buildx/create.md#platform) for the node. If not empty, values take priority over the detected ones.                                                                                                             |
+| `name`            | String | [Name of the node](/reference/cli/docker/buildx/create/#node). If empty, it's the name of the builder it belongs to, with an index number suffix. This is useful to set it if you want to modify/remove a node in an underlying step of your workflow. |
+| `endpoint`        | String | [Docker context or endpoint](/reference/cli/docker/buildx/create/#description) of the node to add to the builder                                                                                                                                      |
+| `driver-opts`     | List   | List of additional [driver-specific options](/reference/cli/docker/buildx/create/#driver-opt)                                                                                                                                                         |
+| `buildkitd-flags` | String | [Flags for buildkitd](/reference/cli/docker/buildx/create/#buildkitd-flags) daemon                                                                                                                                                                    |
+| `platforms`       | String | Fixed [platforms](/reference/cli/docker/buildx/create/#platform) for the node. If not empty, values take priority over the detected ones.                                                                                                             |
 
 Here is an example using remote nodes with the [`remote` driver](/manuals/build/builders/drivers/remote.md)
 and [TLS authentication](#tls-authentication):
@@ -160,7 +160,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         with:
           driver: remote
           endpoint: tcp://oneprovider:1234
@@ -209,7 +209,7 @@ jobs:
           private-key-name: aws_graviton2
       
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         with:
           endpoint: ssh://me@graviton2
 ```
@@ -238,7 +238,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         with:
           driver: remote
           endpoint: tcp://graviton2:1234
@@ -266,10 +266,10 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@{{% param "checkout_action_version" %}}
       
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         with:
           driver: kubernetes
       
@@ -303,21 +303,21 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up builder1
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         id: builder1
       
       - name: Set up builder2
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         id: builder2
       
       - name: Build against builder1
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           builder: ${{ steps.builder1.outputs.name }}
           target: mytarget1
       
       - name: Build against builder2
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           builder: ${{ steps.builder2.outputs.name }}
           target: mytarget2
diff --git a/content/manuals/build/ci/github-actions/copy-image-registries.md b/content/manuals/build/ci/github-actions/copy-image-registries.md
index 4897a070f8ff..f0ccb9b9eb33 100644
--- a/content/manuals/build/ci/github-actions/copy-image-registries.md
+++ b/content/manuals/build/ci/github-actions/copy-image-registries.md
@@ -6,7 +6,7 @@ keywords: ci, github actions, gha, buildkit, buildx, registry
 ---
 
 [Multi-platform images](../../building/multi-platform.md) built using Buildx can
-be copied from one registry to another using the [`buildx imagetools create` command](/reference/cli/docker/buildx/imagetools/create.md):
+be copied from one registry to another using the [`buildx imagetools create` command](/reference/cli/docker/buildx/imagetools/create/):
 
 ```yaml
 name: ci
@@ -19,26 +19,26 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Login to GitHub Container Registry
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           registry: ghcr.io
           username: ${{ github.repository_owner }}
           password: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
       
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           platforms: linux/amd64,linux/arm64
           push: true
diff --git a/content/manuals/build/ci/github-actions/export-docker.md b/content/manuals/build/ci/github-actions/export-docker.md
index 61489e886dc6..366db42df7f5 100644
--- a/content/manuals/build/ci/github-actions/export-docker.md
+++ b/content/manuals/build/ci/github-actions/export-docker.md
@@ -19,10 +19,10 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
       
       - name: Build
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           load: true
           tags: myimage:latest
diff --git a/content/manuals/build/ci/github-actions/github-builder/_index.md b/content/manuals/build/ci/github-actions/github-builder/_index.md
new file mode 100644
index 000000000000..4322d7968805
--- /dev/null
+++ b/content/manuals/build/ci/github-actions/github-builder/_index.md
@@ -0,0 +1,107 @@
+---
+title: Docker GitHub Builder
+linkTitle: GitHub Builder
+description: Use Docker-maintained reusable GitHub Actions workflows to build images and artifacts with BuildKit.
+keywords: ci, github actions, gha, buildkit, buildx, bake, reusable workflows
+params:
+  sidebar:
+    badge:
+      color: green
+      text: New
+---
+
+Docker GitHub Builder is a set of [reusable workflows](https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows)
+in the [`docker/github-builder` repository](https://github.com/docker/github-builder)
+for building container images and local artifacts with [BuildKit](../../../buildkit/_index.md).
+This section explains what the workflows solve, how they differ from wiring
+together individual GitHub Actions in each repository, and when to use
+[`build.yml`](build.md) or [`bake.yml`](bake.md).
+
+If you compose a build job from `docker/login-action`, `docker/setup-buildx-action`,
+`docker/metadata-action`, and either `docker/build-push-action` or
+`docker/bake-action`, your repository owns every detail of how the build runs.
+That approach works, but it also means every repository has to maintain its own
+runner selection, [cache setup](../cache.md), [Provenance settings](../attestations.md),
+signing behavior, and [multi-platform manifest handling](../multi-platform.md).
+Docker GitHub Builder moves that implementation into Docker-maintained reusable
+workflows, so your workflow only decides when to build and which inputs to pass.
+
+The difference is easiest to see in the job definition. A conventional workflow
+spells out each action step:
+
+```yaml
+jobs:
+  docker:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Login to Docker Hub
+        uses: docker/login-action@{{% param "login_action_version" %}}
+        with:
+          username: ${{ vars.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
+      
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
+        
+      - name: Docker meta
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
+        id: meta
+        with:
+          images: name/app
+
+      - name: Build and push
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
+        with:
+          push: ${{ github.event_name != 'pull_request' }}
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
+          cache-from: type=gha
+          cache-to: type=gha
+```
+
+With Docker GitHub Builder, the same build is a reusable workflow call:
+
+```yaml
+jobs:
+  build:
+    uses: docker/github-builder/.github/workflows/build.yml@{{% param "github_builder_version" %}}
+    permissions:
+      contents: read # to fetch the repository content
+      id-token: write # for signing attestation(s) with GitHub OIDC Token
+    with:
+      output: image
+      push: ${{ github.event_name != 'pull_request' }}
+      meta-images: name/app
+    secrets:
+      registry-auths: |
+        - registry: docker.io
+          username: ${{ vars.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+```
+
+This model gives you a build pipeline that is maintained in the Docker
+organization, uses a pinned [BuildKit](../../../buildkit/_index.md) environment,
+distributes [multi-platform builds](../../../building/multi-platform.md) across
+runners when that helps, and emits signed [SLSA provenance](../../../metadata/attestations/slsa-provenance.md)
+that records both the source commit and the builder identity.
+
+That tradeoff is intentional. You keep control of when the build runs and which
+inputs it uses, but the build implementation itself lives in the
+Docker-maintained workflow rather than in per-repository job steps.
+
+Use [`build.yml`](build.md) when your repository builds from a Dockerfile and
+the familiar `build-push-action` inputs map cleanly to your workflow. Use
+[`bake.yml`](bake.md) when your repository already describes builds in a
+[Bake definition](../../../bake/_index.md), or when you want Bake targets,
+overrides, and variables to stay as the source of truth.
+
+Both workflows support image output, local output, cache export to the
+[GitHub Actions cache backend](../../../cache/backends/gha.md),
+[SBOM generation](../../../metadata/attestations/sbom.md), and signing. The
+Bake workflow adds Bake definition validation and builds one target per workflow
+call.
+
+{{% sectionlinks %}}
diff --git a/content/manuals/build/ci/github-actions/github-builder/architecture.md b/content/manuals/build/ci/github-actions/github-builder/architecture.md
new file mode 100644
index 000000000000..bcb3bddda746
--- /dev/null
+++ b/content/manuals/build/ci/github-actions/github-builder/architecture.md
@@ -0,0 +1,230 @@
+---
+title: Docker GitHub Builder architecture
+linkTitle: Architecture
+description: Learn about the architecture of Docker GitHub Builder, a set of reusable workflows for building images and artifacts with BuildKit in GitHub Actions.
+keywords: ci, github actions, gha, buildkit, buildx, bake, reusable workflows
+weight: 10
+---
+
+Docker GitHub Builder separates repository orchestration from build
+implementation. A consuming repository decides when a build runs, which
+permissions and secrets are granted, and which inputs are passed. The reusable
+workflow in [`docker/github-builder` repository](https://github.com/docker/github-builder)
+owns the build implementation itself. That split keeps repository workflows
+short while centralizing BuildKit, caching, provenance, SBOM generation,
+signing, and multi-platform assembly in one Docker-maintained path.
+
+![GitHub Builder overview](./images/architecture-overview.png)
+
+## Core architecture
+
+A caller workflow invokes either [`build.yml`](build.md) or [`bake.yml`](bake.md).
+[`build.yml`](build.md) is the entrypoint for Dockerfile-oriented builds.
+[`bake.yml`](bake.md) is the entrypoint for Bake-oriented builds, where the
+Bake definition remains the source of truth for targets and overrides. In both
+cases the caller still owns repository policy, including triggers, branch
+conditions, permissions, secrets, target selection, metadata inputs, and the
+choice between image output and local output.
+
+Inside the reusable workflow, the first phase prepares the build. It validates
+the incoming inputs, resolves the runner config, and expands a multi-platform
+request into one job per platform. The execution model is easiest to picture as
+a matrix where `linux/amd64` runs on `ubuntu-24.04` and `linux/arm64` runs on
+`ubuntu-24.04-arm`. Each platform job builds independently, then the workflow
+finalizes the result into one caller-facing output contract.
+
+```yaml
+requested platforms:
+  linux/amd64,linux/arm64
+
+conceptual platform jobs:
+  linux/amd64 -> ubuntu-24.04
+  linux/arm64 -> ubuntu-24.04-arm
+```
+
+### Runner selection
+
+The `runner` input accepts either a single GitHub-hosted Linux runner label or a
+newline-delimited platform mapping.
+
+The default value is a platform mapping that uses GitHub-hosted Ubuntu runners:
+
+```yaml
+runner: |
+  default=ubuntu-24.04
+  linux/arm=ubuntu-24.04-arm
+  linux/arm64=ubuntu-24.04-arm
+```
+
+In the platform job, the runner label resolves to a single value:
+
+```yaml
+runner: ubuntu-24.04
+```
+
+A mapping must define a `default` runner. Other keys are platform prefixes, and
+the most specific matching prefix wins. For example, `linux/arm` matches
+variants such as `linux/arm/v7`, while `linux/arm64` is a separate prefix:
+
+In the following example, `linux` matches Linux platforms that do not match a
+longer prefix. The `default` key is still required because it is the fallback
+when no platform prefix matches.
+
+```yaml
+runner: |
+  default=ubuntu-24.04
+  linux=ubuntu-24.04
+  linux/arm=ubuntu-24.04-arm
+  linux/arm64=ubuntu-24.04-arm
+```
+
+The reusable workflows require GitHub-hosted Linux runners. The legacy `auto`,
+`amd64`, and `arm64` values are still accepted for compatibility, but emit
+deprecation warnings. Use an explicit runner label or platform mapping instead.
+
+## Execution path
+
+![GitHub Builder execution flow](./images/execution-flow.png)
+
+The execution path stays short on purpose. The consuming repository calls the
+reusable workflow. The reusable workflow prepares the build, runs the
+per-platform jobs, and finalizes the result. For image output, finalization
+produces a registry image and multi-platform manifest. For local output,
+finalization merges the per-platform files and can upload the merged result as
+a GitHub artifact. The caller does not need to reconstruct how Buildx,
+BuildKit, caching, or manifest assembly were wired together.
+
+## The two reusable entrypoints
+
+[`build.yml`](build.md) is the better fit when the build is already expressed as
+a Dockerfile-oriented workflow. It lines up naturally with concepts such as
+`context`, `file`, `target`, `build-args`, `labels`, `annotations`, and
+`platforms`. This is the entrypoint that feels closest to
+`docker/build-push-action`, except the workflow implementation is centralized.
+
+[`bake.yml`](bake.md) is the better fit when the repository already uses Bake
+as the build definition. It preserves the Bake model, including target
+resolution, `files`, `set`, and `vars`, while still routing execution through
+the same Docker-maintained build path. One important architectural detail is
+that the Bake workflow is centered on one target per workflow call, which keeps
+provenance, digest handling, and final manifest assembly scoped to one build
+unit at a time.
+
+## Output model
+
+The reusable workflows expose a stable set of caller-facing outputs so
+downstream jobs can consume results without understanding the internal job
+graph. In practice, the main values are `digest`, `meta-json`, `artifact-name`,
+`output-type`, and `signed`. That contract matters because it keeps promotion,
+publishing, or follow-on automation decoupled from the mechanics of runner
+selection and per-platform assembly.
+
+## Examples
+
+### Dockerfile-oriented image build
+
+The following example shows the shape of a multi-platform image build driven
+by [`build.yml`](build.md).
+
+```yaml
+name: ci
+
+on:
+  push:
+    branches:
+      - "main"
+    tags:
+      - "v*"
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  build:
+    uses: docker/github-builder/.github/workflows/build.yml@{{% param "github_builder_version" %}}
+    permissions:
+      contents: read
+      id-token: write
+    with:
+      output: image
+      push: ${{ github.event_name != 'pull_request' }}
+      platforms: linux/amd64,linux/arm64
+      meta-images: name/app
+      meta-tags: |
+        type=ref,event=branch
+        type=ref,event=pr
+        type=semver,pattern={{version}}
+    secrets:
+      registry-auths: |
+        - registry: docker.io
+          username: ${{ vars.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+```
+
+This call is small because the reusable workflow absorbs the heavy lifting. The
+repository decides when the build should run and which inputs it wants, while
+the shared implementation handles Buildx setup, BuildKit configuration,
+platform fan-out, metadata generation, provenance, SBOM generation, signing,
+and final manifest creation.
+
+### Bake-oriented local output
+
+The following example shows the shape of a Bake call that exports local output
+and uploads the merged artifact.
+
+```yaml
+name: ci
+
+on:
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  bake:
+    uses: docker/github-builder/.github/workflows/bake.yml@{{% param "github_builder_version" %}}
+    permissions:
+      contents: read
+      id-token: write
+    with:
+      output: local
+      target: binaries
+      artifact-upload: true
+      artifact-name: bake-output
+```
+
+This form is useful when the repository already keeps its build definition in
+Bake and wants to preserve that source of truth. The workflow injects the local
+output behavior into the Bake run, executes the target per platform when
+needed, and merges the result into one caller-facing artifact.
+
+## Why this architecture works
+
+### Performance
+
+The performance story comes from native platform fan-out, shared BuildKit
+configuration, and centralized cache handling. Multi-platform work can be
+spread across matching GitHub-hosted runners instead of forcing every
+architecture through one build machine. That reduces emulation pressure,
+shortens the critical path for cross-platform builds, and gives every
+consuming repository the same optimized build baseline.
+
+### Security
+
+The security model comes from putting the build implementation in
+Docker-maintained reusable workflows instead of ad hoc job steps in each
+consumer repository. The caller still controls permissions and secrets, but
+the build logic itself is centrally reviewed and versioned. The project also
+treats provenance, SBOM generation, and signing as first-class concerns,
+which strengthens the trust boundary between repository orchestration and
+artifact production.
+
+### Isolation and reliability
+
+The reliability story comes from separation of concerns. The consuming
+repository orchestrates the build. The reusable workflow executes the build.
+That reduces CI drift, removes repeated glue code from repositories, and makes
+the outcome easier to reason about because the caller sees a stable contract
+instead of a large custom job definition.
diff --git a/content/manuals/build/ci/github-actions/github-builder/bake.md b/content/manuals/build/ci/github-actions/github-builder/bake.md
new file mode 100644
index 000000000000..c40d4a6314c4
--- /dev/null
+++ b/content/manuals/build/ci/github-actions/github-builder/bake.md
@@ -0,0 +1,149 @@
+---
+title: Bake with Docker GitHub Builder
+linkTitle: Bake workflow
+description: Use the Docker GitHub Builder bake.yml reusable workflow to build images and local artifacts from a Bake definition.
+keywords: ci, github actions, gha, buildkit, buildx, bake, reusable workflow
+weight: 30
+---
+
+The [`bake.yml` reusable workflow](https://github.com/docker/github-builder?tab=readme-ov-file#bake-reusable-workflow)
+builds from a [Bake definition](../../../bake/_index.md) instead of a Dockerfile
+input set. This page shows how to call the workflow for a target, how to pass
+Bake overrides and variables, and how to export local output when a Bake file
+is already the source of truth for your build.
+
+## Build and push a Bake target
+
+The following workflow builds the `image` target from `docker-bake.hcl` and
+publishes the result with tags generated from [metadata inputs](../manage-tags-labels.md):
+
+```yaml
+name: ci
+
+on:
+  push:
+    branches:
+      - "main"
+    tags:
+      - "v*"
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  bake:
+    uses: docker/github-builder/.github/workflows/bake.yml@{{% param "github_builder_version" %}}
+    permissions:
+      contents: read # to fetch the repository content
+      id-token: write # for signing attestation(s) with GitHub OIDC Token
+    with:
+      output: image
+      push: ${{ github.event_name != 'pull_request' }}
+      target: image
+      meta-images: name/app
+      meta-tags: |
+        type=ref,event=branch
+        type=ref,event=pr
+        type=semver,pattern={{version}}
+    secrets:
+      registry-auths: |
+        - registry: docker.io
+          username: ${{ vars.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+```
+
+Bake workflows build one target per workflow call. Groups and multi-target
+builds aren't supported because [SLSA provenance](../attestations.md), digest
+handling, and manifest creation are scoped to a single target.
+
+The workflow validates the definition before the build starts and resolves
+the target from the files you pass in `files`. Runner selection uses the same
+`runner` input as the Build workflow. Set a single GitHub-hosted Linux runner
+label or a platform mapping when the default mapping is not enough. For details,
+see [runner selection](architecture.md#runner-selection).
+
+## Override target values and variables
+
+Because the workflow delegates the build to Bake, you can keep using `set` and
+`vars` for target-specific overrides:
+
+```yaml
+name: ci
+
+on:
+  push:
+    branches:
+      - "main"
+
+permissions:
+  contents: read
+
+jobs:
+  bake:
+    uses: docker/github-builder/.github/workflows/bake.yml@{{% param "github_builder_version" %}}
+    permissions:
+      contents: read # to fetch the repository content
+      id-token: write # for signing attestation(s) with GitHub OIDC Token
+    with:
+      output: image
+      push: true
+      target: image
+      vars: |
+        IMAGE_TAG=${{ github.sha }}
+      set: |
+        *.args.BUILD_RUN_ID=${{ github.run_id }}
+        *.platform=linux/amd64,linux/arm64
+      cache: true
+      cache-scope: image
+      meta-images: name/app
+      meta-tags: |
+        type=sha
+      set-meta-annotations: true
+    secrets:
+      registry-auths: |
+        - registry: docker.io
+          username: ${{ vars.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+```
+
+This form fits repositories that already use Bake groups, target inheritance,
+and variable expansion. The reusable workflow takes care of Buildx setup,
+[GitHub Actions cache export](../../../cache/backends/gha.md),
+[Provenance defaults](../../../metadata/attestations/slsa-provenance.md),
+signing behavior, and the final multi-platform manifest. Metadata labels and
+annotations can be merged into the Bake definition without adding a separate
+metadata step to your workflow.
+
+## Export local output from Bake
+
+If the target should export files instead of publishing an image, switch the
+workflow output to `local` and upload the artifact:
+
+```yaml
+name: ci
+
+on:
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  bake:
+    uses: docker/github-builder/.github/workflows/bake.yml@{{% param "github_builder_version" %}}
+    permissions:
+      contents: read # to fetch the repository content
+      id-token: write # for signing attestation(s) with GitHub OIDC Token
+    with:
+      output: local
+      target: binaries
+      artifact-upload: true
+      artifact-name: bake-output
+```
+
+With `output: local`, the workflow injects the matching local output override
+into the Bake run and merges the uploaded artifacts after the per-platform
+builds finish. If you need a manual Bake pattern that stays in a normal job,
+see [Multi-platform image](../multi-platform.md). If your build does not need a
+Bake definition, use [build.yml](build.md) instead.
diff --git a/content/manuals/build/ci/github-actions/github-builder/build.md b/content/manuals/build/ci/github-actions/github-builder/build.md
new file mode 100644
index 000000000000..46f15d37ee21
--- /dev/null
+++ b/content/manuals/build/ci/github-actions/github-builder/build.md
@@ -0,0 +1,152 @@
+---
+title: Build with Docker GitHub Builder
+linkTitle: Build workflow
+description: Use the Docker GitHub Builder build.yml reusable workflow to build images and local artifacts from a Dockerfile.
+keywords: ci, github actions, gha, buildkit, buildx, reusable workflow, dockerfile
+weight: 20
+---
+
+The [`build.yml` reusable workflow](https://github.com/docker/github-builder?tab=readme-ov-file#build-reusable-workflow)
+builds from a Dockerfile and packages the same core tasks that many repositories
+wire together by hand. This page shows how to call the workflow, publish
+[multi-platform images](../../../building/multi-platform.md), and export local
+build artifacts without rebuilding the job structure in every repository.
+
+## Build and push an image
+
+The following workflow builds from the repository Dockerfile, pushes on branch
+and tag events, and uses metadata inputs to generate tags:
+
+```yaml
+name: ci
+
+on:
+  push:
+    branches:
+      - "main"
+    tags:
+      - "v*"
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  build:
+    uses: docker/github-builder/.github/workflows/build.yml@{{% param "github_builder_version" %}}
+    permissions:
+      contents: read # to fetch the repository content
+      id-token: write # for signing attestation(s) with GitHub OIDC Token
+    with:
+      output: image
+      push: ${{ github.event_name != 'pull_request' }}
+      platforms: linux/amd64,linux/arm64
+      meta-images: name/app
+      meta-tags: |
+        type=ref,event=branch
+        type=ref,event=pr
+        type=semver,pattern={{version}}
+    secrets:
+      registry-auths: |
+        - registry: docker.io
+          username: ${{ vars.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+```
+
+When you set `output: image`, `meta-images` is required because the workflow
+creates image names and [manifest tags](../manage-tags-labels.md) from that
+input. `distribute: true` is the default, so a multi-platform build can fan out
+across native GitHub-hosted runners instead of forcing the whole build onto one
+machine. The default `runner` mapping sends Linux Arm platforms to
+`ubuntu-24.04-arm` and uses `ubuntu-24.04` for other platforms. To change that
+mapping, see [runner selection](architecture.md#runner-selection). `sign: auto`
+is also the default, which means the workflow signs
+[attestation manifests](../attestations.md) when the image is pushed.
+
+## Export local output as an artifact
+
+The same workflow can export files instead of publishing an image. This is
+useful when you want compiled assets, an unpacked root filesystem, or another
+local exporter result as part of CI:
+
+```yaml
+name: ci
+
+on:
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  build:
+    uses: docker/github-builder/.github/workflows/build.yml@{{% param "github_builder_version" %}}
+    permissions:
+      contents: read # to fetch the repository content
+      id-token: write # for signing attestation(s) with GitHub OIDC Token
+    with:
+      output: local
+      artifact-upload: true
+      artifact-name: build-output
+      platforms: linux/amd64,linux/arm64
+```
+
+With `output: local`, the workflow exports files to the runner filesystem and
+merges per-platform artifacts in the finalize phase. When
+`artifact-upload: true` is set, the merged result is uploaded as a GitHub
+artifact, and `sign: auto` signs the uploaded artifacts. `push` is ignored for
+local output, so there is no registry requirement in this form.
+
+## Add cache, Dockerfile inputs, and metadata labels
+
+You can tune the Dockerfile build in the same job call. This example sets a
+custom Dockerfile path, a target stage, GitHub Actions cache, and metadata
+labels:
+
+```yaml
+name: ci
+
+on:
+  push:
+    branches:
+      - "main"
+
+permissions:
+  contents: read
+
+jobs:
+  build:
+    uses: docker/github-builder/.github/workflows/build.yml@{{% param "github_builder_version" %}}
+    permissions:
+      contents: read # to fetch the repository content
+      id-token: write # for signing attestation(s) with GitHub OIDC Token
+    with:
+      output: image
+      push: true
+      context: .
+      file: ./docker/Dockerfile
+      target: runtime
+      build-args: |
+        NODE_ENV=production
+        VERSION=${{ github.sha }}
+      cache: true
+      cache-scope: myapp
+      meta-images: name/app
+      meta-tags: |
+        type=sha
+      set-meta-labels: true
+    secrets:
+      registry-auths: |
+        - registry: docker.io
+          username: ${{ vars.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+```
+
+This is a Dockerfile build, so the inputs map closely to
+`docker/build-push-action`. The difference is that the reusable workflow owns
+Buildx setup, [BuildKit](../../../buildkit/_index.md) configuration,
+[SLSA provenance](../../../metadata/attestations/slsa-provenance.md) mode,
+[GitHub Actions cache backend](../../../cache/backends/gha.md) wiring, signing,
+and manifest creation. If you need more background on metadata or platform
+distribution, see [Manage tags and labels](../manage-tags-labels.md) and
+[Multi-platform image](../multi-platform.md).
diff --git a/content/manuals/build/ci/github-actions/github-builder/images/architecture-overview.png b/content/manuals/build/ci/github-actions/github-builder/images/architecture-overview.png
new file mode 100644
index 000000000000..801ff48faf59
Binary files /dev/null and b/content/manuals/build/ci/github-actions/github-builder/images/architecture-overview.png differ
diff --git a/content/manuals/build/ci/github-actions/github-builder/images/execution-flow.png b/content/manuals/build/ci/github-actions/github-builder/images/execution-flow.png
new file mode 100644
index 000000000000..7d4765f86a1d
Binary files /dev/null and b/content/manuals/build/ci/github-actions/github-builder/images/execution-flow.png differ
diff --git a/content/manuals/build/ci/github-actions/local-registry.md b/content/manuals/build/ci/github-actions/local-registry.md
index 807b7e7c320b..638cfd5c1ff5 100644
--- a/content/manuals/build/ci/github-actions/local-registry.md
+++ b/content/manuals/build/ci/github-actions/local-registry.md
@@ -19,20 +19,20 @@ jobs:
     runs-on: ubuntu-latest
     services:
       registry:
-        image: registry:2
+        image: registry:3
         ports:
           - 5000:5000
     steps:
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
       
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         with:
           driver-opts: network=host
       
       - name: Build and push to local registry
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: true
           tags: localhost:5000/name/app:latest
diff --git a/content/manuals/build/ci/github-actions/manage-tags-labels.md b/content/manuals/build/ci/github-actions/manage-tags-labels.md
index 00d2082585bd..5e3f0e19158f 100644
--- a/content/manuals/build/ci/github-actions/manage-tags-labels.md
+++ b/content/manuals/build/ci/github-actions/manage-tags-labels.md
@@ -29,7 +29,7 @@ jobs:
     steps:
       - name: Docker meta
         id: meta
-        uses: docker/metadata-action@v5
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
         with:
           # list of Docker images to use as base name for tags
           images: |
@@ -47,27 +47,27 @@ jobs:
 
       - name: Login to Docker Hub
         if: github.event_name != 'pull_request'
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Login to GHCR
         if: github.event_name != 'pull_request'
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           registry: ghcr.io
           username: ${{ github.repository_owner }}
           password: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: ${{ github.event_name != 'pull_request' }}
           tags: ${{ steps.meta.outputs.tags }}
diff --git a/content/manuals/build/ci/github-actions/multi-platform.md b/content/manuals/build/ci/github-actions/multi-platform.md
index 787abccda09d..1b03149a1257 100644
--- a/content/manuals/build/ci/github-actions/multi-platform.md
+++ b/content/manuals/build/ci/github-actions/multi-platform.md
@@ -26,19 +26,19 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           platforms: linux/amd64,linux/arm64
           push: true
@@ -47,10 +47,7 @@ jobs:
 
 ## Build and load multi-platform images
 
-The default Docker setup for GitHub Actions runners does not support loading
-multi-platform images to the local image store of the runner after building
-them. To load a multi-platform image, you need to enable the containerd image
-store option for the Docker Engine.
+The default Docker setup for GitHub Actions runners supports building and pushing multi-platform images to registries. However, it does not support loading multi-platform images to the local image store of the runner after building them. To load a multi-platform image locally, you need to enable the containerd image store option for the Docker Engine.
 
 There is no way to configure the default Docker setup in the GitHub Actions
 runners directly, but you can use `docker/setup-docker-action` to customize the
@@ -71,7 +68,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker
-        uses: docker/setup-docker-action@v4
+        uses: docker/setup-docker-action@{{% param "setup_docker_action_version" %}}
         with:
           daemon-config: |
             {
@@ -82,16 +79,16 @@ jobs:
             }
 
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           platforms: linux/amd64,linux/arm64
           load: true
@@ -100,17 +97,16 @@ jobs:
 
 ## Distribute build across multiple runners
 
-In the previous example, each platform is built on the same runner which can
-take a long time depending on the number of platforms and your Dockerfile.
+Building multiple platforms on the same runner can significantly extend build
+times, particularly when dealing with complex Dockerfiles or a high number of
+target platforms. If you want to split platform builds across multiple runners
+without maintaining a custom matrix and merge job, use the
+[Docker GitHub Builder](github-builder/_index.md). The reusable workflows
+compute the per-platform matrix, run each platform on its own runner, and
+create the final manifest for you.
 
-To solve this issue you can use a matrix strategy to distribute the build for
-each platform across multiple runners and create manifest list using the
-[`buildx imagetools create` command](/reference/cli/docker/buildx/imagetools/create.md).
-
-The following workflow will build the image for each platform on a dedicated
-runner using a matrix strategy and push by digest. Then, the `merge` job will
-create manifest lists and push them to Docker Hub. The [`metadata` action](https://github.com/docker/metadata-action)
-is used to set tags and labels.
+The following workflow uses the [`build.yml` reusable workflow](github-builder/build.md)
+to distribute a multi-platform Dockerfile build:
 
 ```yaml
 name: ci
@@ -118,117 +114,46 @@ name: ci
 on:
   push:
 
-env:
-  REGISTRY_IMAGE: user/app
+permissions:
+  contents: read
 
 jobs:
   build:
-    runs-on: ubuntu-latest
-    strategy:
-      fail-fast: false
-      matrix:
-        platform:
-          - linux/amd64
-          - linux/arm64
-    steps:
-      - name: Prepare
-        run: |
-          platform=${{ matrix.platform }}
-          echo "PLATFORM_PAIR=${platform//\//-}" >> $GITHUB_ENV
-
-      - name: Docker meta
-        id: meta
-        uses: docker/metadata-action@v5
-        with:
-          images: ${{ env.REGISTRY_IMAGE }}
-
-      - name: Login to Docker Hub
-        uses: docker/login-action@v3
-        with:
-          username: ${{ vars.DOCKERHUB_USERNAME }}
-          password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-      - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
-
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
-
-      - name: Build and push by digest
-        id: build
-        uses: docker/build-push-action@v6
-        with:
-          platforms: ${{ matrix.platform }}
-          labels: ${{ steps.meta.outputs.labels }}
-          tags: ${{ env.REGISTRY_IMAGE }}
-          outputs: type=image,push-by-digest=true,name-canonical=true,push=true
-
-      - name: Export digest
-        run: |
-          mkdir -p ${{ runner.temp }}/digests
-          digest="${{ steps.build.outputs.digest }}"
-          touch "${{ runner.temp }}/digests/${digest#sha256:}"
-
-      - name: Upload digest
-        uses: actions/upload-artifact@v4
-        with:
-          name: digests-${{ env.PLATFORM_PAIR }}
-          path: ${{ runner.temp }}/digests/*
-          if-no-files-found: error
-          retention-days: 1
-
-  merge:
-    runs-on: ubuntu-latest
-    needs:
-      - build
-    steps:
-      - name: Download digests
-        uses: actions/download-artifact@v4
-        with:
-          path: ${{ runner.temp }}/digests
-          pattern: digests-*
-          merge-multiple: true
-
-      - name: Login to Docker Hub
-        uses: docker/login-action@v3
-        with:
+    uses: docker/github-builder/.github/workflows/build.yml@{{% param "github_builder_version" %}}
+    permissions:
+      contents: read
+      id-token: write
+    with:
+      output: image
+      push: true
+      platforms: linux/amd64,linux/arm64
+      meta-images: user/app
+      meta-tags: |
+        type=ref,event=branch
+        type=ref,event=pr
+        type=semver,pattern={{version}}
+        type=semver,pattern={{major}}.{{minor}}
+    secrets:
+      registry-auths: |
+        - registry: docker.io
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
-
-      - name: Docker meta
-        id: meta
-        uses: docker/metadata-action@v5
-        with:
-          images: ${{ env.REGISTRY_IMAGE }}
-          tags: |
-            type=ref,event=branch
-            type=ref,event=pr
-            type=semver,pattern={{version}}
-            type=semver,pattern={{major}}.{{minor}}
-
-      - name: Create manifest list and push
-        working-directory: ${{ runner.temp }}/digests
-        run: |
-          docker buildx imagetools create $(jq -cr '.tags | map("-t " + .) | join(" ")' <<< "$DOCKER_METADATA_OUTPUT_JSON") \
-            $(printf '${{ env.REGISTRY_IMAGE }}@sha256:%s ' *)
-
-      - name: Inspect image
-        run: |
-          docker buildx imagetools inspect ${{ env.REGISTRY_IMAGE }}:${{ steps.meta.outputs.version }}
 ```
 
-### With Bake
-
-It's also possible to build on multiple runners using Bake, with the
-[bake action](https://github.com/docker/bake-action).
+With `distribute: true`, which is the default, the workflow splits the build
+into one platform per runner and assembles the final multi-platform image in
+its finalize phase. The default `runner` mapping sends Linux Arm platforms to
+`ubuntu-24.04-arm` and uses `ubuntu-24.04` for other platforms. To customize
+the mapping, see [runner selection](github-builder/architecture.md#runner-selection).
+If you need to control the Docker build inputs directly, see
+[Build with Docker GitHub Builder build.yml](github-builder/build.md).
 
-You can find a live example [in this GitHub repository](https://github.com/crazy-max/docker-linguist).
+### With Bake
 
-The following example achieves the same results as described in
-[the previous section](#distribute-build-across-multiple-runners).
+You can use the [`bake.yml` reusable workflow](github-builder/bake.md) for the
+same pattern when your build is defined in a Bake file. The workflow reads the
+target platforms from the Bake definition, distributes the per-platform builds,
+and publishes the final manifest without a separate prepare or merge job.
 
 ```hcl
 variable "DEFAULT_TAG" {
@@ -271,138 +196,26 @@ name: ci
 on:
   push:
 
-env:
-  REGISTRY_IMAGE: user/app
+permissions:
+  contents: read
 
 jobs:
-  prepare:
-    runs-on: ubuntu-latest
-    outputs:
-      matrix: ${{ steps.platforms.outputs.matrix }}
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-
-      - name: Create matrix
-        id: platforms
-        run: |
-          echo "matrix=$(docker buildx bake image-all --print | jq -cr '.target."image-all".platforms')" >>${GITHUB_OUTPUT}
-
-      - name: Show matrix
-        run: |
-          echo ${{ steps.platforms.outputs.matrix }}
-
-      - name: Docker meta
-        id: meta
-        uses: docker/metadata-action@v5
-        with:
-          images: ${{ env.REGISTRY_IMAGE }}
-
-      - name: Rename meta bake definition file
-        run: |
-          mv "${{ steps.meta.outputs.bake-file }}" "${{ runner.temp }}/bake-meta.json"
-
-      - name: Upload meta bake definition
-        uses: actions/upload-artifact@v4
-        with:
-          name: bake-meta
-          path: ${{ runner.temp }}/bake-meta.json
-          if-no-files-found: error
-          retention-days: 1
-
-  build:
-    runs-on: ubuntu-latest
-    needs:
-      - prepare
-    strategy:
-      fail-fast: false
-      matrix:
-        platform: ${{ fromJson(needs.prepare.outputs.matrix) }}
-    steps:
-      - name: Prepare
-        run: |
-          platform=${{ matrix.platform }}
-          echo "PLATFORM_PAIR=${platform//\//-}" >> $GITHUB_ENV
-
-      - name: Download meta bake definition
-        uses: actions/download-artifact@v4
-        with:
-          name: bake-meta
-          path: ${{ runner.temp }}
-      
-      - name: Login to Docker Hub
-        uses: docker/login-action@v3
-        with:
-          username: ${{ vars.DOCKERHUB_USERNAME }}
-          password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-      - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
-
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
-
-      - name: Build
-        id: bake
-        uses: docker/bake-action@v6
-        with:
-          files: |
-            ./docker-bake.hcl
-            cwd://${{ runner.temp }}/bake-meta.json
-          targets: image
-          set: |
-            *.tags=${{ env.REGISTRY_IMAGE }}
-            *.platform=${{ matrix.platform }}
-            *.output=type=image,push-by-digest=true,name-canonical=true,push=true
-
-      - name: Export digest
-        run: |
-          mkdir -p ${{ runner.temp }}/digests
-          digest="${{ fromJSON(steps.bake.outputs.metadata).image['containerimage.digest'] }}"
-          touch "${{ runner.temp }}/digests/${digest#sha256:}"
-
-      - name: Upload digest
-        uses: actions/upload-artifact@v4
-        with:
-          name: digests-${{ env.PLATFORM_PAIR }}
-          path: ${{ runner.temp }}/digests/*
-          if-no-files-found: error
-          retention-days: 1
-
-  merge:
-    runs-on: ubuntu-latest
-    needs:
-      - build
-    steps:
-      - name: Download meta bake definition
-        uses: actions/download-artifact@v4
-        with:
-          name: bake-meta
-          path: ${{ runner.temp }}
-
-      - name: Download digests
-        uses: actions/download-artifact@v4
-        with:
-          path: ${{ runner.temp }}/digests
-          pattern: digests-*
-          merge-multiple: true
-
-      - name: Login to DockerHub
-        uses: docker/login-action@v3
-        with:
+  bake:
+    uses: docker/github-builder/.github/workflows/bake.yml@{{% param "github_builder_version" %}}
+    permissions:
+      contents: read
+      id-token: write
+    with:
+      output: image
+      push: true
+      target: image-all
+      meta-images: user/app
+      meta-tags: |
+        type=ref,event=branch
+        type=sha
+    secrets:
+      registry-auths: |
+        - registry: docker.io
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
-
-      - name: Create manifest list and push
-        working-directory: ${{ runner.temp }}/digests
-        run: |
-          docker buildx imagetools create $(jq -cr '.target."docker-metadata-action".tags | map(select(startswith("${{ env.REGISTRY_IMAGE }}")) | "-t " + .) | join(" ")' ${{ runner.temp }}/bake-meta.json) \
-            $(printf '${{ env.REGISTRY_IMAGE }}@sha256:%s ' *)
-
-      - name: Inspect image
-        run: |
-          docker buildx imagetools inspect ${{ env.REGISTRY_IMAGE }}:$(jq -r '.target."docker-metadata-action".args.DOCKER_META_VERSION' ${{ runner.temp }}/bake-meta.json)
 ```
diff --git a/content/manuals/build/ci/github-actions/named-contexts.md b/content/manuals/build/ci/github-actions/named-contexts.md
index 0419bae733a0..fa0da022ea92 100644
--- a/content/manuals/build/ci/github-actions/named-contexts.md
+++ b/content/manuals/build/ci/github-actions/named-contexts.md
@@ -5,7 +5,7 @@ description: Use additional contexts in multi-stage builds with GitHub Actions
 keywords: ci, github actions, gha, buildkit, buildx, context
 ---
 
-You can define [additional build contexts](/reference/cli/docker/buildx/build.md#build-context),
+You can define [additional build contexts](/reference/cli/docker/buildx/build/#build-context),
 and access them in your Dockerfile with `FROM name` or `--from=name`. When
 Dockerfile defines a stage with the same name it's overwritten.
 
@@ -33,10 +33,10 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           build-contexts: |
             alpine=docker-image://alpine:{{% param "example_alpine_version" %}}
@@ -68,19 +68,19 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         with:
           driver: docker
 
       - name: Build base image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           context: "{{defaultContext}}:base"
           load: true
           tags: my-base-image:latest
 
       - name: Build
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           build-contexts: |
             alpine=docker-image://my-base-image:latest
@@ -112,28 +112,28 @@ jobs:
     runs-on: ubuntu-latest
     services:
       registry:
-        image: registry:2
+        image: registry:3
         ports:
           - 5000:5000
     steps:
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
         with:
           # network=host driver-opt needed to push to local registry
           driver-opts: network=host
 
       - name: Build base image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           context: "{{defaultContext}}:base"
           tags: localhost:5000/my-base-image:latest
           push: true
 
       - name: Build
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           build-contexts: |
             alpine=docker-image://localhost:5000/my-base-image:latest
diff --git a/content/manuals/build/ci/github-actions/push-multi-registries.md b/content/manuals/build/ci/github-actions/push-multi-registries.md
index 617b39d7cfff..e80bbc456b45 100644
--- a/content/manuals/build/ci/github-actions/push-multi-registries.md
+++ b/content/manuals/build/ci/github-actions/push-multi-registries.md
@@ -19,26 +19,26 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Login to GitHub Container Registry
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           registry: ghcr.io
           username: ${{ github.repository_owner }}
           password: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           platforms: linux/amd64,linux/arm64
           push: true
diff --git a/content/manuals/build/ci/github-actions/reproducible-builds.md b/content/manuals/build/ci/github-actions/reproducible-builds.md
index 038c64020ac0..0649ca534934 100644
--- a/content/manuals/build/ci/github-actions/reproducible-builds.md
+++ b/content/manuals/build/ci/github-actions/reproducible-builds.md
@@ -33,10 +33,10 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           tags: user/app:latest
         env:
@@ -57,10 +57,10 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@{{% param "bake_action_version" %}}
         env:
           SOURCE_DATE_EPOCH: 0
 ```
@@ -86,13 +86,13 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Get Git commit timestamps
         run: echo "TIMESTAMP=$(git log -1 --pretty=%ct)" >> $GITHUB_ENV
 
       - name: Build
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           tags: user/app:latest
         env:
@@ -113,13 +113,13 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Get Git commit timestamps
         run: echo "TIMESTAMP=$(git log -1 --pretty=%ct)" >> $GITHUB_ENV
 
       - name: Build
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@{{% param "bake_action_version" %}}
         env:
           SOURCE_DATE_EPOCH: ${{ env.TIMESTAMP }}
 ```
diff --git a/content/manuals/build/ci/github-actions/secrets.md b/content/manuals/build/ci/github-actions/secrets.md
index e24ea725d56a..edc7b045c47d 100644
--- a/content/manuals/build/ci/github-actions/secrets.md
+++ b/content/manuals/build/ci/github-actions/secrets.md
@@ -14,7 +14,7 @@ Docker Build supports two forms of secrets:
 - [SSH mounts](#ssh-mounts) add SSH agent sockets or keys into the build container.
 
 This page shows how to use secrets with GitHub Actions.
-For an introduction to secrets in general, see [Build secrets](../../building/secrets.md).
+For an introduction to secrets in general, see [Build secrets](/manuals/build/building/secrets.md).
 
 ## Secret mounts
 
@@ -43,13 +43,13 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           platforms: linux/amd64,linux/arm64
           tags: user/app:latest
@@ -58,13 +58,203 @@ jobs:
 ```
 
 > [!NOTE]
->
-> You can also expose a secret file to the build with the `secret-files` input:
->
-> ```yaml
-> secret-files: |
->   "MY_SECRET=./secret.txt"
-> ```
+> Secrets are mounted as files in the build container.
+> By default, they're available at `/run/secrets/<id>`.
+> You can also use the `env` option to load a secret into an environment variable,
+> or the `target` option to customize the mount path.
+> For details on secret mounts, see [Build secrets](/manuals/build/building/secrets.md).
+
+### Secret sources
+
+The `docker/build-push-action` inputs for secret mounts define where the secret
+value comes from. The Dockerfile `RUN --mount=type=secret` options define how
+the build step consumes the secret.
+
+| Action input                           | Source                             | Equivalent Buildx option                 |
+| -------------------------------------- | ---------------------------------- | ---------------------------------------- |
+| `secrets: MY_SECRET=value`             | Inline value from the workflow     | `--secret id=MY_SECRET,src=<temp-file>`  |
+| `secret-envs: MY_SECRET=MY_ENV_VAR`    | Environment variable on the runner | `--secret id=MY_SECRET,env=MY_ENV_VAR`   |
+| `secret-files: MY_SECRET=./secret.txt` | File on the runner                 | `--secret id=MY_SECRET,src=./secret.txt` |
+
+For example, `RUN --mount=type=secret,id=MY_SECRET` mounts the secret as a file
+at `/run/secrets/MY_SECRET`. To expose the same secret as an environment
+variable for a `RUN` instruction, use the `env` option in the Dockerfile:
+`RUN --mount=type=secret,id=MY_SECRET,env=MY_SECRET`.
+
+### Using environment variables as secret sources
+
+The `secret-envs` input reads secrets from environment variables on the GitHub
+Actions runner. Use it when a previous workflow step sets an environment
+variable, or when you want to map a runner environment variable to a different
+secret ID for the build.
+
+```yaml
+name: ci
+
+on:
+  push:
+
+jobs:
+  docker:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@{{% param "checkout_action_version" %}}
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
+
+      - name: Build
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
+        env:
+          SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
+        with:
+          context: .
+          secret-envs: |
+            sentry_token=SENTRY_AUTH_TOKEN
+          tags: user/app:latest
+```
+
+In your Dockerfile, mount the secret and expose it as an environment variable
+for the command that needs it:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+FROM node:20-alpine
+
+WORKDIR /app
+
+COPY package*.json ./
+RUN npm ci
+
+COPY . .
+
+RUN --mount=type=secret,id=sentry_token,env=SENTRY_AUTH_TOKEN \
+    npm run build
+```
+
+### Using secret files
+
+The `secret-files` input lets you mount existing files as secrets in your build.
+This is useful when you need to use credential files that are generated during your workflow,
+or when you need to mount configuration files like `.npmrc` or `.pypirc` that are already in the expected format.
+
+The key difference between `secrets`, `secret-envs`, and `secret-files`:
+
+- `secrets`: Pass secret values as strings from the workflow.
+- `secret-envs`: Read secret values from environment variables on the runner.
+- `secret-files`: Mount existing files from the runner's filesystem.
+
+#### Example: Using .npmrc for private npm packages
+
+If your build needs to install packages from a private npm registry,
+you can create an `.npmrc` file and mount it as a secret:
+
+```yaml
+name: ci
+
+on:
+  push:
+
+jobs:
+  docker:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@{{% param "checkout_action_version" %}}
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
+
+      - name: Create .npmrc file
+        run: |
+          echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}" > .npmrc
+
+      - name: Build
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
+        with:
+          context: .
+          secret-files: |
+            npmrc=./.npmrc
+          tags: user/app:latest
+```
+
+In your Dockerfile, mount the secret file to the expected location:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+FROM node:20-alpine
+
+WORKDIR /app
+
+COPY package*.json ./
+
+RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
+    npm ci
+
+COPY . .
+
+RUN npm run build
+```
+
+If a `RUN` instruction uses a non-root user, set `uid`, `gid`, or `mode` on the
+secret mount so the user can read the mounted file:
+
+```dockerfile
+RUN --mount=type=secret,id=npmrc,target=/home/node/.npmrc,uid=1000,gid=1000 \
+    npm ci
+```
+
+#### Example: Using dynamically generated credentials
+
+You can generate credential files from multiple secrets and mount them:
+
+```yaml
+name: ci
+
+on:
+  push:
+
+jobs:
+  docker:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@{{% param "checkout_action_version" %}}
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
+
+      - name: Create credentials file
+        run: |
+          cat <<EOF > aws-credentials
+          [default]
+          aws_access_key_id = ${{ secrets.AWS_ACCESS_KEY_ID }}
+          aws_secret_access_key = ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+          EOF
+
+      - name: Build
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
+        with:
+          context: .
+          secret-files: |
+            aws=./aws-credentials
+          tags: user/app:latest
+```
+
+In your Dockerfile:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+FROM alpine
+
+RUN apk add --no-cache aws-cli
+
+RUN --mount=type=secret,id=aws,target=/root/.aws/credentials \
+    aws s3 cp s3://my-private-bucket/data.tar.gz /tmp/
+```
+
+### Multi-line secrets
 
 If you're using [GitHub secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
 and need to handle multi-line value, you will need to place the key-value pair
@@ -178,7 +368,7 @@ jobs:
           private-key-name: github-ppk
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           ssh: default
           push: true
@@ -206,7 +396,7 @@ jobs:
           private-key-name: github-ppk
 
       - name: Build
-        uses: docker/bake-action@v6
+        uses: docker/bake-action@{{% param "bake_action_version" %}}
         with:
           set: |
             *.ssh=default
diff --git a/content/manuals/build/ci/github-actions/share-image-jobs.md b/content/manuals/build/ci/github-actions/share-image-jobs.md
index 0fb11c219575..c88fb0436c37 100644
--- a/content/manuals/build/ci/github-actions/share-image-jobs.md
+++ b/content/manuals/build/ci/github-actions/share-image-jobs.md
@@ -13,6 +13,14 @@ in a workflow using the [actions/upload-artifact](https://github.com/actions/upl
 and [actions/download-artifact](https://github.com/actions/download-artifact)
 actions:
 
+> [!NOTE]
+>
+> This workflow supports only single-platform images because the Docker exporter
+> doesn't support manifest lists. For multi-platform images, push the image to a
+> registry. If a later job rebuilds the image before pushing it, configure a
+> [shared cache backend](cache.md) to reuse the earlier build results. See also
+> [Multi-platform image with GitHub Actions](multi-platform.md).
+
 ```yaml
 name: ci
 
@@ -24,10 +32,10 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build and export
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           tags: myimage:latest
           outputs: type=docker,dest=${{ runner.temp }}/myimage.tar
diff --git a/content/manuals/build/ci/github-actions/test-before-push.md b/content/manuals/build/ci/github-actions/test-before-push.md
index 05c5f824b262..7aee48ac4510 100644
--- a/content/manuals/build/ci/github-actions/test-before-push.md
+++ b/content/manuals/build/ci/github-actions/test-before-push.md
@@ -28,19 +28,19 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build and export to Docker
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           load: true
           tags: ${{ env.TEST_TAG }}
@@ -50,7 +50,7 @@ jobs:
           docker run --rm ${{ env.TEST_TAG }}
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           platforms: linux/amd64,linux/arm64
           push: true
diff --git a/content/manuals/build/ci/github-actions/update-dockerhub-desc.md b/content/manuals/build/ci/github-actions/update-dockerhub-desc.md
index 6c49dc3ce886..c3f5e9d35a6f 100644
--- a/content/manuals/build/ci/github-actions/update-dockerhub-desc.md
+++ b/content/manuals/build/ci/github-actions/update-dockerhub-desc.md
@@ -20,19 +20,19 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Login to Docker Hub
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
+        uses: docker/setup-qemu-action@{{% param "setup_qemu_action_version" %}}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       - name: Build and push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           push: true
           tags: user/app:latest
diff --git a/content/manuals/build/concepts/context.md b/content/manuals/build/concepts/context.md
index 2818bec9b7b6..dffebe9f398f 100644
--- a/content/manuals/build/concepts/context.md
+++ b/content/manuals/build/concepts/context.md
@@ -245,6 +245,50 @@ docker build github.com/docker/buildx#d4f088e689b41353d74f1a0bfcd6d7c0b213aed2
 docker build github.com/docker/buildx#d4f088e
 ```
 
+#### URL queries
+
+{{< summary-bar feature_name="Build URL Queries" >}}
+
+URL queries are more structured and recommended over [URL fragments](#url-fragments):
+
+```console
+$ docker buildx build 'https://github.com/user/myrepo.git?branch=container&subdir=docker'
+```
+
+| Build syntax suffix                          | Commit used                   | Build context used |
+| -------------------------------------------- | ----------------------------- | ------------------ |
+| `myrepo.git`                                 | `refs/heads/<default branch>` | `/`                |
+| `myrepo.git?tag=mytag`                       | `refs/tags/mytag`             | `/`                |
+| `myrepo.git?branch=mybranch`                 | `refs/heads/mybranch`         | `/`                |
+| `myrepo.git?ref=pull/42/head`                | `refs/pull/42/head`           | `/`                |
+| `myrepo.git?subdir=myfolder`                 | `refs/heads/<default branch>` | `/myfolder`        |
+| `myrepo.git?branch=master&subdir=myfolder`   | `refs/heads/master`           | `/myfolder`        |
+| `myrepo.git?tag=mytag&subdir=myfolder`       | `refs/tags/mytag`             | `/myfolder`        |
+| `myrepo.git?branch=mybranch&subdir=myfolder` | `refs/heads/mybranch`         | `/myfolder`        |
+
+A commit hash can be specified as a `checksum` (alias `commit`) query, along with
+`tag`, `branch`, or `ref` queries to verify that the reference resolves to the
+expected commit:
+
+```console
+$ docker buildx build 'https://github.com/moby/buildkit.git?tag=v0.21.1&checksum=66735c67'
+```
+
+If it doesn't match, the build fails:
+
+```console
+$ docker buildx build 'https://github.com/user/myrepo.git?tag=v0.1.0&commit=deadbeef'
+...
+#3 [internal] load git source https://github.com/user/myrepo.git?tag=v0.1.0-rc1&commit=deadbeef
+#3 0.484 bb41e835b6c3523c7c45b248cf4b45e7f862bc42       refs/tags/v0.1.0
+#3 ERROR: expected checksum to match deadbeef, got bb41e835b6c3523c7c45b248cf4b45e7f862bc42
+```
+
+> [!NOTE]
+>
+> Short commit hash is supported with `checksum` (alias `commit`) query but for
+> `ref`, only the full hash of the commit is supported.
+
 #### Keep `.git` directory
 
 By default, BuildKit doesn't keep the `.git` directory when using Git contexts.
@@ -275,7 +319,7 @@ either SSH or token-based authentication.
 Buildx automatically detects and uses SSH credentials if the Git context you
 specify is an SSH or Git address. By default, this uses `$SSH_AUTH_SOCK`.
 You can configure the SSH credentials to use with the
-[`--ssh` flag](/reference/cli/docker/buildx/build.md#ssh).
+[`--ssh` flag](/reference/cli/docker/buildx/build/#ssh).
 
 ```console
 $ docker buildx build --ssh default git@github.com:user/private.git
@@ -283,7 +327,7 @@ $ docker buildx build --ssh default git@github.com:user/private.git
 
 If you want to use token-based authentication instead, you can pass the token
 using the
-[`--secret` flag](/reference/cli/docker/buildx/build.md#secret).
+[`--secret` flag](/reference/cli/docker/buildx/build/#secret).
 
 ```console
 $ GIT_AUTH_TOKEN=<token> docker buildx build \
@@ -498,6 +542,7 @@ The following code snippet shows an example `.dockerignore` file.
 */*/temp*
 temp?
 ```
+<!-- vale off -->
 
 This file causes the following build behavior:
 
@@ -508,6 +553,8 @@ This file causes the following build behavior:
 | `*/*/temp*` | Exclude files and directories starting with `temp` from any subdirectory that is two levels below the root. For example, `/somedir/subdir/temporary.txt` is excluded.                                         |
 | `temp?`     | Exclude files and directories in the root directory whose names are a one-character extension of `temp`. For example, `/tempa` and `/tempb` are excluded.                                                     |
 
+<!-- vale on -->
+
 Matching is done using Go's
 [`filepath.Match` function](https://golang.org/pkg/path/filepath#Match) rules.
 A preprocessing step uses Go's
@@ -755,5 +802,5 @@ $ docker buildx bake app
 
 For more information about working with named contexts, see:
 
-- [`--build-context` CLI reference](/reference/cli/docker/buildx/build.md#build-context)
+- [`--build-context` CLI reference](/reference/cli/docker/buildx/build/#build-context)
 - [Using Bake with additional contexts](/manuals/build/bake/contexts.md)
diff --git a/content/manuals/build/concepts/dockerfile.md b/content/manuals/build/concepts/dockerfile.md
index 18601a9b15de..1d0893c531e9 100644
--- a/content/manuals/build/concepts/dockerfile.md
+++ b/content/manuals/build/concepts/dockerfile.md
@@ -4,10 +4,12 @@ weight: 20
 description: Learn about Dockerfiles and how to use them with Docker Images to build and package your software
 keywords: build, buildx, buildkit, getting started, dockerfile
 aliases:
-- /build/hellobuild/
-- /build/building/packaging/
+  - /build/hellobuild/
+  - /build/building/packaging/
 ---
 
+<!-- vale Docker.We = NO -->
+
 ## Dockerfile
 
 It all starts with a Dockerfile.
@@ -19,8 +21,8 @@ reference in the [Dockerfile reference](/reference/dockerfile.md).
 
 Here are the most common types of instructions:
 
-| Instruction                                                        | Description                                                                                                                                                                                              |
-| ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Instruction                                               | Description                                                                                                                                                                                              |
+| --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | [`FROM <image>`](/reference/dockerfile.md#from)           | Defines a base for your image.                                                                                                                                                                           |
 | [`RUN <command>`](/reference/dockerfile.md#run)           | Executes any commands in a new layer on top of the current image and commits the result. `RUN` also has a shell form for running commands.                                                               |
 | [`WORKDIR <directory>`](/reference/dockerfile.md#workdir) | Sets the working directory for any `RUN`, `CMD`, `ENTRYPOINT`, `COPY`, and `ADD` instructions that follow it in the Dockerfile.                                                                          |
@@ -41,7 +43,7 @@ Some projects may need distinct Dockerfiles for specific purposes. A common
 convention is to name these `<something>.Dockerfile`. You can specify the
 Dockerfile filename using the `--file` flag for the `docker build` command.
 Refer to the
-[`docker build` CLI reference](/reference/cli/docker/buildx/build.md#file)
+[`docker build` CLI reference](/reference/cli/docker/buildx/build/#file)
 to learn about the `--file` flag.
 
 > [!NOTE]
@@ -146,7 +148,7 @@ use this notation to name your images. There are many public images you can
 leverage in your projects, by importing them into your build steps using the
 Dockerfile `FROM` instruction.
 
-[Docker Hub](https://hub.docker.com/search?image_filter=official&q=&type=image)
+[Docker Hub](https://hub.docker.com/search?badges=official)
 contains a large set of official images that you can use for this purpose.
 
 ### Environment setup
@@ -167,7 +169,7 @@ the container.
 Note the `# install app dependencies` line. This is a comment. Comments in
 Dockerfiles begin with the `#` symbol. As your Dockerfile evolves, comments can
 be instrumental to document how your Dockerfile works for any future readers
-and editors of the file, including your future self!
+and editors of the file, including your future self.
 
 > [!NOTE]
 >
@@ -194,7 +196,7 @@ use the command to install the flask web framework.
 
 The next instruction uses the
 [`COPY` instruction](/reference/dockerfile.md#copy) to copy the
-`hello.py` file from the local build context into the root directory of our image. 
+`hello.py` file from the local build context into the root directory of our image.
 
 ```dockerfile
 COPY hello.py /
@@ -281,5 +283,5 @@ Docker host.
 
 > [!TIP]
 >
-> Want a better editing experience for Dockerfiles in VS Code?
-> Check out the [Docker VS Code Extension (Beta)](https://marketplace.visualstudio.com/items?itemName=docker.docker) for linting, code navigation, and vulnerability scanning.
+> To improve linting, code navigation, and vulnerability scanning of your Dockerfiles in Visual Studio Code
+> see the [Docker DX](https://marketplace.visualstudio.com/items?itemName=docker.docker) extension.
diff --git a/content/manuals/build/debug/opentelemetry.md b/content/manuals/build/debug/opentelemetry.md
index 575d8fc15732..ad635daf05c1 100644
--- a/content/manuals/build/debug/opentelemetry.md
+++ b/content/manuals/build/debug/opentelemetry.md
@@ -29,7 +29,7 @@ $ docker buildx create --use \
   --driver-opt "env.JAEGER_TRACE=localhost:6831"
 ```
 
-Boot and [inspect `mybuilder`](/reference/cli/docker/buildx/inspect.md):
+Boot and [inspect `mybuilder`](/reference/cli/docker/buildx/inspect/):
 
 ```console
 $ docker buildx inspect --bootstrap
diff --git a/content/manuals/build/exporters/_index.md b/content/manuals/build/exporters/_index.md
index 2921fb1ff31e..57f465191adc 100644
--- a/content/manuals/build/exporters/_index.md
+++ b/content/manuals/build/exporters/_index.md
@@ -10,7 +10,7 @@ aliases:
 
 Exporters save your build results to a specified output type. You specify the
 exporter to use with the
-[`--output` CLI option](/reference/cli/docker/buildx/build.md#output).
+[`--output` CLI option](/reference/cli/docker/buildx/build/#output).
 Buildx supports the following exporters:
 
 - `image`: exports the build result to a container image.
@@ -222,8 +222,8 @@ The common parameters described here are:
 
 When you export a compressed output, you can configure the exact compression
 algorithm and level to use. While the default values provide a good
-out-of-the-box experience, you may wish to tweak the parameters to optimize for
-storage vs compute costs. Changing the compression parameters can reduce storage
+out-of-the-box experience, you can tweak the parameters to optimize for
+storage versus compute costs. Changing the compression parameters can reduce storage
 space required, and improve image download times, but will increase build times.
 
 To select the compression algorithm, you can use the `compression` option. For
@@ -252,6 +252,22 @@ the previous compression algorithm.
 > The `gzip` and `estargz` compression methods use the [`compress/gzip` package](https://pkg.go.dev/compress/gzip),
 > while `zstd` uses the [`github.com/klauspost/compress/zstd` package](https://github.com/klauspost/compress/tree/master/zstd).
 
+#### zstd compression levels
+
+When you specify `compression=zstd`, the `compression-level` parameter accepts
+values from 0 to 22. BuildKit maps these values to four internal compression
+levels:
+
+| compression-level | Internal level | Approximate zstd level | Description                           |
+| ----------------- | -------------- | ---------------------- | ------------------------------------- |
+| 0-2               | Fastest        | ~1                     | Fastest compression, larger file size |
+| 3-6 (default)     | Default        | ~3                     | Balanced compression and speed        |
+| 7-8               | Better         | ~7                     | Better compression, slower            |
+| 9-22              | Best           | ~11                    | Best compression, slowest             |
+
+For example, setting `compression-level=5` and `compression-level=6` produces
+the same compression output, since both map to the "Default" internal level.
+
 ### OCI media types
 
 The `image`, `registry`, `oci` and `docker` exporters create container images.
diff --git a/content/manuals/build/exporters/image-registry.md b/content/manuals/build/exporters/image-registry.md
index 159be14265fa..12fa29bff9d1 100644
--- a/content/manuals/build/exporters/image-registry.md
+++ b/content/manuals/build/exporters/image-registry.md
@@ -26,7 +26,7 @@ The following table describes the available parameters that you can pass to
 
 | Parameter              | Type                                   | Default | Description                                                                                                                                                                                                                         |
 | ---------------------- | -------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `name`                 | String                                 |         | Specify image name(s)                                                                                                                                                                                                               |
+| `name`                 | String                                 |         | Image name. To specify multiple names, use a comma-separated list.                                                                                                                                    |
 | `push`                 | `true`,`false`                         | `false` | Push after creating the image.                                                                                                                                                                                                      |
 | `push-by-digest`       | `true`,`false`                         | `false` | Push image without name.                                                                                                                                                                                                            |
 | `registry.insecure`    | `true`,`false`                         | `false` | Allow pushing to insecure registry.                                                                                                                                                                                                 |
@@ -48,6 +48,17 @@ The following table describes the available parameters that you can pass to
 [4]: https://github.com/moby/buildkit/blob/master/docs/build-repro.md
 [5]: /manuals/build/metadata/attestations/_index.md#attestations-as-oci-artifacts
 
+The `name` parameter is a CSV value inside the `--output` value. To specify
+multiple image names, quote the complete `name` field:
+
+```console
+$ docker buildx build \
+    --output 'type=image,"name=registry.example.com/myapp:1.0,registry.example.com/myapp:latest",push=true' .
+```
+
+To assign multiple names with CLI flags instead, repeat the
+[`--tag` flag](/reference/cli/docker/buildx/build/#tag).
+
 ## Annotations
 
 These exporters support adding OCI annotation using `annotation` parameter,
diff --git a/content/manuals/build/exporters/local-tar.md b/content/manuals/build/exporters/local-tar.md
index dca9f3ab6561..b2138da08f2d 100644
--- a/content/manuals/build/exporters/local-tar.md
+++ b/content/manuals/build/exporters/local-tar.md
@@ -25,9 +25,109 @@ $ docker buildx build --output type=tar[,parameters] .
 
 The following table describes the available parameters:
 
-| Parameter | Type   | Default | Description           |
-| --------- | ------ | ------- | --------------------- |
-| `dest`    | String |         | Path to copy files to |
+| Parameter        | Type    | Default | Description                                                                       |
+| ---------------- | ------- | ------- | --------------------------------------------------------------------------------- |
+| `dest`           | String  |         | Path to copy files to                                                             |
+| `platform-split` | Boolean | `true`  | `local` exporter only. Split multi-platform outputs into platform subdirectories. |
+
+## Multi-platform builds with local exporter
+
+The `platform-split` parameter controls how multi-platform build outputs are
+organized.
+
+Consider this Dockerfile that creates platform-specific files:
+
+```dockerfile
+FROM busybox AS build
+ARG TARGETOS
+ARG TARGETARCH
+RUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCH
+
+FROM scratch
+COPY --from=build /out /
+```
+
+### Split by platform (default)
+
+By default, the local exporter creates a separate subdirectory for each
+platform:
+
+```console
+$ docker buildx build \
+  --platform linux/amd64,linux/arm64 \
+  --output type=local,dest=./output \
+  .
+```
+
+This produces the following directory structure:
+
+```text
+output/
+├── linux_amd64/
+│   └── hello-linux-amd64
+└── linux_arm64/
+    └── hello-linux-arm64
+```
+
+### Merge all platforms
+
+To merge files from all platforms into the same directory, set
+`platform-split=false`:
+
+```console
+$ docker buildx build \
+  --platform linux/amd64,linux/arm64 \
+  --output type=local,dest=./output,platform-split=false \
+  .
+```
+
+This produces a flat directory structure:
+
+```text
+output/
+├── hello-linux-amd64
+└── hello-linux-arm64
+```
+
+Files from all platforms merge into a single directory. If multiple platforms
+produce files with identical names, the export fails with an error.
+
+### Single-platform builds
+
+Single-platform builds export directly to the destination directory without
+creating a platform subdirectory:
+
+```console
+$ docker buildx build \
+  --platform linux/amd64 \
+  --output type=local,dest=./output \
+  .
+```
+
+This produces:
+
+```text
+output/
+└── hello-linux-amd64
+```
+
+To include the platform subdirectory even for single-platform builds, explicitly
+set `platform-split=true`:
+
+```console
+$ docker buildx build \
+  --platform linux/amd64 \
+  --output type=local,dest=./output,platform-split=true \
+  .
+```
+
+This produces:
+
+```text
+output/
+└── linux_amd64/
+    └── hello-linux-amd64
+```
 
 ## Further reading
 
diff --git a/content/manuals/build/exporters/oci-docker.md b/content/manuals/build/exporters/oci-docker.md
index fdd49b550b16..b9d13be064d5 100644
--- a/content/manuals/build/exporters/oci-docker.md
+++ b/content/manuals/build/exporters/oci-docker.md
@@ -40,10 +40,12 @@ The following table describes the available parameters:
 | `force-compression` | `true`,`false`                         | `false` | Forcefully apply compression, see [compression][1]                                                                                    |
 | `oci-mediatypes`    | `true`,`false`                         |         | Use OCI media types in exporter manifests. Defaults to `true` for `type=oci`, and `false` for `type=docker`. See [OCI Media types][2] |
 | `annotation.<key>`  | String                                 |         | Attach an annotation with the respective `key` and `value` to the built image,see [annotations][3]                                    |
+| `rewrite-timestamp` | `true`,`false`                         | `false` | Rewrite the file timestamps to the `SOURCE_DATE_EPOCH` value. See [build reproducibility][4] for how to specify the `SOURCE_DATE_EPOCH` value. |
 
 [1]: _index.md#compression
 [2]: _index.md#oci-media-types
 [3]: #annotations
+[4]: https://github.com/moby/buildkit/blob/master/docs/build-repro.md
 
 ## Annotations
 
diff --git a/content/manuals/build/images/build-variables.svg b/content/manuals/build/images/build-variables.svg
index 13197975fb1c..07dab5f2d326 100644
--- a/content/manuals/build/images/build-variables.svg
+++ b/content/manuals/build/images/build-variables.svg
@@ -1,3 +1,3 @@
 <svg version="1.1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1061.9696259527584 1442.1673620954803" width="2123.939251905517" height="2884.3347241909605">
   <!-- svg-source:excalidraw -->
-  <g stroke-linecap="round" transform="translate(10 10.695992798288444) rotate(0 499.1377001126125 710.7356846485959)"><path d="M32 0 C255.74 -2.14, 478.15 -1.24, 966.28 0 M32 0 C378.71 -3.28, 724.69 -3.27, 966.28 0 M966.28 0 C986.17 0.74, 996.63 8.91, 998.28 32 M966.28 0 C985.53 0.47, 999.22 12.32, 998.28 32 M998.28 32 C998.87 540.44, 998.57 1047.3, 998.28 1389.47 M998.28 32 C1000.13 332.72, 999.89 632.34, 998.28 1389.47 M998.28 1389.47 C999.74 1412.68, 987.23 1421.33, 966.28 1421.47 M998.28 1389.47 C999.06 1409.62, 986.33 1421.09, 966.28 1421.47 M966.28 1421.47 C617.92 1417.07, 269.59 1418.23, 32 1421.47 M966.28 1421.47 C760.82 1420.97, 555.95 1421.09, 32 1421.47 M32 1421.47 C10.29 1419.93, 1.76 1410.9, 0 1389.47 M32 1421.47 C10.06 1422.32, 0.01 1412.67, 0 1389.47 M0 1389.47 C0.04 978.98, 1.4 567.71, 0 32 M0 1389.47 C-0.01 888.46, 0.38 386.83, 0 32 M0 32 C-1.3 10.77, 11.68 1.71, 32 0 M0 32 C2.2 11.96, 9.68 -1.32, 32 0" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g><g stroke-linecap="round"><g transform="translate(68.95218432054128 10.893058988452026) rotate(0 0 709.0292944687217)"><path d="M1 -0.89 C0.94 235.16, 0.22 1180.9, -0.05 1417.28 M0.07 1.25 C-0.18 237.36, -0.73 1182.22, -1.02 1418.4" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(-30.50876650189207 720.2254322648956) rotate(270 70.3125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">Global scope</text></g><g transform="translate(98.75403817344818 28.194164132218475) rotate(0 322.265625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Build arguments declared here are in the global scope</text></g><g transform="translate(98.75403817344818 61.069164132218475) rotate(0 216.796875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ARG GLOBAL_ARG="global default value"</text></g><g transform="translate(99.15768400678144 94.23322663221848) rotate(0 105.46875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ARG VERSION="3.19"</text></g><g transform="translate(98.75403817344818 138.37052499260426) rotate(0 357.421875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># You can't declare environment variables in the global scope</text></g><g transform="translate(98.75403817344818 171.24552499260426) rotate(0 117.1875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ENV GLOBAL_ENV=false</text></g><g stroke-linecap="round"><g transform="translate(96.71975251551498 199.24591157364756) rotate(0 10.875622044046054 1.871948995827239)"><path d="M-0.11 -0.2 C0.54 0.52, 2.86 4.62, 4.45 4.6 C6.05 4.59, 8.05 -0.28, 9.46 -0.26 C10.87 -0.25, 11.68 4.72, 12.91 4.71 C14.14 4.71, 15.32 -0.3, 16.84 -0.32 C18.36 -0.33, 21.28 3.92, 22.04 4.63 M0.83 -0.78 C1.37 -0.25, 2.61 3.81, 4.03 3.76 C5.45 3.7, 7.83 -1.08, 9.33 -1.09 C10.84 -1.1, 11.94 3.55, 13.07 3.72 C14.21 3.88, 14.82 -0.18, 16.17 -0.09 C17.51 -0.01, 20.28 3.43, 21.16 4.23" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(114.69967078783793 199.19590234429887) rotate(0 10.875622044046054 1.871948995827239)"><path d="M0.02 0.23 C0.85 1.07, 3.36 4.95, 4.88 4.84 C6.39 4.74, 7.8 -0.35, 9.12 -0.41 C10.44 -0.47, 11.47 4.46, 12.81 4.48 C14.14 4.51, 15.7 -0.16, 17.13 -0.25 C18.55 -0.34, 20.61 3.23, 21.36 3.94 M-0.64 -0.13 C0.17 0.58, 3.09 4.31, 4.67 4.12 C6.25 3.92, 7.45 -1.46, 8.82 -1.31 C10.19 -1.16, 11.62 4.81, 12.92 5.03 C14.21 5.25, 15.13 0.04, 16.61 0.01 C18.09 -0.02, 20.92 4.05, 21.8 4.85" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(150.92972871414293 199.94904082186486) rotate(179.39098195963928 10.875622044045997 1.871948995827239)"><path d="M0.44 0.46 C1.19 1.21, 3.11 4.88, 4.54 4.7 C5.96 4.51, 7.59 -0.61, 9.01 -0.64 C10.44 -0.66, 11.86 4.6, 13.1 4.55 C14.33 4.5, 15.02 -0.85, 16.45 -0.94 C17.87 -1.03, 20.72 3.16, 21.63 4 M0 0.23 C0.69 0.8, 2.71 3.93, 4.16 3.9 C5.6 3.86, 7.13 -0.2, 8.66 0.01 C10.2 0.21, 11.93 5.31, 13.36 5.13 C14.78 4.96, 15.77 -1.01, 17.24 -1.04 C18.71 -1.07, 21.37 3.96, 22.2 4.94" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(132.85989722751174 199.83301019081188) rotate(179.39098195963928 10.875622044046054 1.871948995827239)"><path d="M0.1 0.32 C0.77 0.99, 2.9 4.62, 4.43 4.47 C5.96 4.32, 7.97 -0.47, 9.3 -0.57 C10.63 -0.67, 11.18 3.91, 12.41 3.86 C13.65 3.81, 15.14 -0.91, 16.72 -0.88 C18.29 -0.85, 21 3.24, 21.87 4.06 M-0.51 0.01 C0.04 0.74, 2.4 3.81, 4 3.55 C5.6 3.29, 7.71 -1.65, 9.1 -1.56 C10.49 -1.47, 10.9 3.99, 12.32 4.09 C13.75 4.19, 15.94 -1.1, 17.65 -0.95 C19.35 -0.79, 21.79 4.08, 22.57 5.03" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(169.49752467353744 199.16543053706374) rotate(0 10.875622044045997 1.871948995827239)"><path d="M0 0.09 C0.77 0.79, 3.28 4.76, 4.72 4.53 C6.16 4.31, 7.29 -1.16, 8.62 -1.26 C9.95 -1.37, 11.29 3.85, 12.68 3.92 C14.07 3.99, 15.42 -0.83, 16.96 -0.82 C18.49 -0.81, 21.12 3.02, 21.91 4 M-0.67 -0.34 C0.05 0.16, 2.7 3.75, 4.44 3.65 C6.17 3.55, 8.35 -1.03, 9.74 -0.94 C11.12 -0.85, 11.63 4.16, 12.73 4.18 C13.83 4.19, 14.97 -0.98, 16.34 -0.86 C17.72 -0.73, 20.03 4.02, 20.97 4.94" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(187.47744294586028 199.09498977907566) rotate(0 10.875622044046054 1.871948995827239)"><path d="M0.29 0.16 C0.96 0.78, 2.61 4.07, 4.04 3.84 C5.47 3.62, 7.41 -1.23, 8.89 -1.2 C10.37 -1.18, 11.57 3.93, 12.92 3.98 C14.27 4.03, 15.53 -1.05, 17 -0.88 C18.46 -0.71, 20.92 4.07, 21.71 5.02 M-0.23 -0.24 C0.62 0.42, 3.62 4.37, 5.07 4.27 C6.52 4.17, 7.14 -0.85, 8.48 -0.85 C9.82 -0.85, 11.77 4.28, 13.09 4.27 C14.42 4.25, 14.87 -1.04, 16.41 -0.95 C17.95 -0.85, 21.39 3.94, 22.33 4.83" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(223.70750087216538 199.54548076066084) rotate(179.39098195963928 10.875622044046054 1.871948995827239)"><path d="M-0.39 -0.54 C0.28 0.09, 2.72 4, 4.31 3.9 C5.9 3.8, 7.69 -1.15, 9.13 -1.14 C10.57 -1.14, 11.69 3.71, 12.97 3.92 C14.24 4.13, 15.33 -0.01, 16.8 0.14 C18.27 0.29, 21.02 4.03, 21.77 4.83 M0.4 0.38 C0.97 1.04, 2.41 4.55, 3.81 4.36 C5.22 4.17, 7.28 -0.73, 8.84 -0.76 C10.4 -0.79, 11.95 4.23, 13.16 4.18 C14.37 4.13, 14.57 -1.12, 16.11 -1.06 C17.66 -1, 21.54 3.6, 22.42 4.54" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(205.63766938553385 199.93249249730445) rotate(179.39098195963928 10.875622044046054 1.871948995827239)"><path d="M-0.13 -0.48 C0.7 0.27, 3 4.08, 4.55 3.96 C6.1 3.84, 7.8 -1.37, 9.17 -1.2 C10.54 -1.04, 11.49 4.75, 12.77 4.94 C14.05 5.14, 15.43 -0.04, 16.86 -0.05 C18.29 -0.05, 20.46 4.14, 21.33 4.93 M0.81 0.47 C1.61 1.32, 2.83 4.67, 4.18 4.45 C5.53 4.23, 7.46 -0.78, 8.91 -0.85 C10.35 -0.91, 11.65 3.87, 12.86 4.06 C14.08 4.25, 14.72 0.21, 16.2 0.32 C17.68 0.42, 20.7 4.04, 21.76 4.69" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(241.88135191254798 199.20048715004572) rotate(0 10.875622044045997 1.871948995827239)"><path d="M0.11 -0.42 C0.9 0.31, 3.11 3.86, 4.59 3.9 C6.07 3.94, 7.6 -0.32, 8.98 -0.18 C10.35 -0.04, 11.59 4.71, 12.83 4.75 C14.07 4.79, 14.88 0.06, 16.42 0.05 C17.96 0.05, 21.16 4, 22.09 4.71 M-0.49 0.56 C0.25 1.38, 2.72 4.61, 4.24 4.36 C5.76 4.1, 7.16 -0.87, 8.61 -0.97 C10.06 -1.06, 11.52 3.81, 12.95 3.77 C14.38 3.74, 15.82 -1.29, 17.2 -1.2 C18.58 -1.1, 20.37 3.27, 21.25 4.35" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(259.8612701848708 199.675156325702) rotate(0 10.875622044046054 1.871948995827239)"><path d="M0.16 -0.48 C0.87 0.41, 2.92 4.91, 4.4 4.93 C5.88 4.94, 7.7 -0.36, 9.04 -0.37 C10.37 -0.38, 11.03 4.82, 12.39 4.85 C13.75 4.89, 15.57 -0.08, 17.18 -0.17 C18.79 -0.26, 21.35 3.57, 22.05 4.31 M-0.43 0.47 C0.2 1.26, 2.42 4.53, 3.94 4.24 C5.47 3.95, 7.31 -1.2, 8.7 -1.25 C10.09 -1.3, 10.95 3.7, 12.28 3.93 C13.62 4.16, 15.21 0.16, 16.69 0.13 C18.17 0.1, 20.38 2.91, 21.17 3.75" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(296.0913281111759 199.92687650310802) rotate(179.39098195963928 10.875622044046054 1.871948995827239)"><path d="M-0.04 0.55 C0.68 1.42, 3.02 4.87, 4.45 4.74 C5.89 4.6, 7.15 -0.25, 8.59 -0.27 C10.04 -0.29, 11.73 4.68, 13.15 4.63 C14.58 4.58, 15.77 -0.51, 17.14 -0.57 C18.5 -0.64, 20.59 3.32, 21.35 4.24 M-0.72 0.35 C-0.09 1.11, 2.3 4.2, 4.03 3.96 C5.77 3.71, 8.13 -1.04, 9.7 -1.1 C11.26 -1.16, 12.29 3.48, 13.44 3.59 C14.59 3.69, 15.23 -0.49, 16.62 -0.48 C18.01 -0.47, 20.9 2.8, 21.79 3.65" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(278.02149662454474 200.0255590636262) rotate(179.39098195963928 10.875622044045997 1.871948995827239)"><path d="M0.02 0.36 C0.7 1.07, 2.46 4.98, 4.01 4.84 C5.57 4.7, 7.84 -0.39, 9.36 -0.49 C10.87 -0.6, 11.92 4.25, 13.1 4.23 C14.28 4.21, 15.01 -0.76, 16.44 -0.64 C17.87 -0.51, 20.72 4.15, 21.68 4.96 M-0.63 0.07 C0.22 0.87, 3.39 4.36, 5.03 4.11 C6.67 3.86, 7.8 -1.53, 9.19 -1.44 C10.58 -1.35, 12.03 4.5, 13.37 4.65 C14.71 4.79, 15.75 -0.59, 17.23 -0.58 C18.72 -0.56, 21.65 3.78, 22.29 4.74" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(314.65912407057044 199.32697384617302) rotate(0 10.875622044046054 1.871948995827239)"><path d="M-0.42 0.46 C0.37 1.17, 3.16 4.84, 4.78 4.61 C6.4 4.39, 8.04 -0.82, 9.31 -0.89 C10.58 -0.97, 11.17 4, 12.41 4.16 C13.65 4.33, 15.14 0.07, 16.77 0.08 C18.4 0.1, 21.3 3.51, 22.21 4.25 M0.36 0.22 C1.11 0.73, 3.06 3.87, 4.52 3.77 C5.98 3.67, 7.81 -0.51, 9.11 -0.38 C10.41 -0.25, 11.16 4.68, 12.32 4.55 C13.47 4.42, 14.55 -1, 16.06 -1.15 C17.58 -1.3, 20.58 2.82, 21.42 3.67" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(153.889524612174 968.3053802939692) rotate(0 263.671875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># GLOBAL_ARG was not redeclared in this stage</text></g><g transform="translate(155.79056627884052 1001.2530445209427) rotate(0 117.1875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $GLOBAL_ARG</text></g><g stroke-linecap="round"><g transform="translate(154.4533933542814 1030.0620223560434) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M-0.47 -0.23 C0.3 0.35, 3 3.88, 4.56 3.83 C6.13 3.79, 7.6 -0.52, 8.92 -0.51 C10.24 -0.49, 11.17 3.93, 12.48 3.93 C13.79 3.92, 15.19 -0.55, 16.78 -0.53 C18.36 -0.5, 21.24 3.21, 22 4.05 M0.28 -0.82 C1.01 -0.23, 2.82 4.36, 4.2 4.25 C5.57 4.15, 7.16 -1.45, 8.53 -1.46 C9.9 -1.47, 11.16 4.02, 12.42 4.19 C13.68 4.36, 14.63 -0.55, 16.07 -0.41 C17.52 -0.27, 20.21 4.3, 21.11 5.02" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(172.43331162660434 1030.0120131266947) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M0.13 -0.54 C0.93 0.26, 2.92 4.71, 4.34 4.6 C5.77 4.49, 7.28 -1.14, 8.69 -1.2 C10.09 -1.25, 11.34 4.21, 12.74 4.27 C14.15 4.34, 15.66 -0.87, 17.09 -0.83 C18.52 -0.79, 20.55 3.65, 21.35 4.52 M-0.47 0.37 C0.29 1.02, 2.15 3.95, 3.86 3.75 C5.58 3.55, 8.34 -1, 9.83 -0.84 C11.33 -0.68, 11.7 4.72, 12.82 4.72 C13.94 4.71, 15.06 -0.76, 16.55 -0.87 C18.04 -0.98, 20.84 3.3, 21.78 4.06" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(208.66336955290933 1030.7651516042604) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M-0.09 0.22 C0.57 0.97, 2.6 4.09, 4.1 3.91 C5.61 3.73, 7.46 -0.86, 8.95 -0.85 C10.44 -0.84, 11.81 3.89, 13.06 3.97 C14.31 4.05, 14.97 -0.43, 16.44 -0.36 C17.9 -0.3, 21.01 3.56, 21.85 4.37 M-0.8 -0.14 C0.02 0.7, 3.61 4.4, 5.17 4.37 C6.73 4.34, 7.21 -0.29, 8.57 -0.31 C9.93 -0.33, 11.86 4.23, 13.3 4.26 C14.74 4.28, 15.68 -0.09, 17.22 -0.16 C18.77 -0.23, 21.81 3.16, 22.55 3.84" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(190.59353806627814 1030.6491209732073) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M-0.33 -0.47 C0.41 0.21, 2.77 4.37, 4.37 4.26 C5.97 4.14, 7.93 -1.18, 9.27 -1.15 C10.61 -1.12, 11.12 4.33, 12.4 4.44 C13.68 4.55, 15.43 -0.52, 16.94 -0.51 C18.46 -0.5, 20.81 3.68, 21.52 4.5 M0.5 0.48 C1.18 1.22, 2.48 5.1, 3.91 4.9 C5.33 4.69, 7.65 -0.78, 9.05 -0.77 C10.45 -0.76, 11.1 4.9, 12.31 4.96 C13.52 5.03, 14.71 -0.23, 16.33 -0.39 C17.95 -0.54, 21.23 3.35, 22.04 4.03" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(227.23116551230385 1029.9815413194594) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M-0.06 -0.12 C0.77 0.62, 3.24 4.05, 4.68 3.96 C6.13 3.86, 7.24 -0.74, 8.61 -0.68 C9.98 -0.63, 11.58 4.24, 12.91 4.29 C14.25 4.34, 15.23 -0.39, 16.61 -0.38 C17.99 -0.37, 20.35 3.49, 21.21 4.37 M-0.76 -0.66 C0.05 0.18, 2.63 4.34, 4.38 4.44 C6.13 4.54, 8.27 -0.11, 9.72 -0.06 C11.17 -0.01, 11.78 4.76, 13.08 4.74 C14.37 4.72, 16.07 -0.04, 17.48 -0.19 C18.9 -0.34, 20.8 3.06, 21.57 3.84" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(245.21108378462668 1029.9111005614711) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M0.25 -0.42 C0.93 0.33, 2.55 4.49, 4.03 4.42 C5.51 4.35, 7.7 -0.83, 9.12 -0.83 C10.54 -0.83, 11.38 4.36, 12.58 4.42 C13.77 4.47, 14.76 -0.59, 16.3 -0.51 C17.83 -0.43, 20.78 4.03, 21.78 4.91 M-0.29 0.55 C0.57 1.41, 3.54 5.28, 5.06 5.14 C6.57 5, 7.57 -0.25, 8.82 -0.29 C10.08 -0.32, 11.2 4.95, 12.57 4.93 C13.93 4.92, 15.37 -0.34, 17.01 -0.38 C18.66 -0.43, 21.74 3.87, 22.43 4.66" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(281.4411417109318 1030.3615915430566) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M-0.4 0.04 C0.31 0.83, 3.01 4.4, 4.54 4.27 C6.07 4.15, 7.5 -0.71, 8.78 -0.7 C10.07 -0.7, 10.92 4.17, 12.27 4.29 C13.61 4.41, 15.2 -0.05, 16.87 0.03 C18.53 0.11, 21.51 4.05, 22.28 4.78 M0.39 -0.41 C1.02 0.49, 2.84 4.86, 4.16 4.92 C5.48 4.97, 6.99 -0.06, 8.32 -0.09 C9.64 -0.12, 10.78 4.93, 12.1 4.74 C13.41 4.55, 14.64 -1.19, 16.21 -1.23 C17.78 -1.28, 20.62 3.63, 21.53 4.46" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(263.37131022430026 1030.7486032796999) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M0.1 -0.11 C0.87 0.62, 2.81 4.52, 4.2 4.4 C5.6 4.28, 7.03 -0.9, 8.47 -0.83 C9.91 -0.76, 11.35 4.71, 12.83 4.83 C14.32 4.95, 15.93 -0.02, 17.37 -0.1 C18.81 -0.18, 20.78 3.64, 21.49 4.37 M-0.51 -0.64 C0.2 0.18, 1.98 5.05, 3.65 5.11 C5.32 5.17, 7.96 -0.08, 9.51 -0.29 C11.06 -0.49, 11.72 3.8, 12.96 3.89 C14.2 3.98, 15.47 0.24, 16.97 0.23 C18.48 0.23, 21.19 3.01, 21.99 3.85" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(299.6149927513144 1030.0165979324413) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M-0.23 0.02 C0.4 0.75, 2.35 4.33, 3.89 4.28 C5.44 4.22, 7.47 -0.36, 9.04 -0.29 C10.62 -0.22, 12.08 4.73, 13.34 4.7 C14.59 4.66, 15.2 -0.44, 16.58 -0.5 C17.95 -0.57, 20.68 3.39, 21.59 4.31 M0.65 -0.44 C1.43 0.38, 3.5 5.04, 4.85 4.92 C6.19 4.81, 7.5 -0.93, 8.71 -1.14 C9.91 -1.34, 10.6 3.57, 12.06 3.69 C13.51 3.82, 15.75 -0.39, 17.44 -0.38 C19.12 -0.37, 21.31 2.91, 22.14 3.76" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(317.5949110236372 1030.4912671080976) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M-0.54 -0.1 C0.24 0.69, 2.78 4.87, 4.46 4.81 C6.14 4.76, 8.2 -0.34, 9.54 -0.42 C10.89 -0.51, 11.36 4.32, 12.54 4.3 C13.73 4.27, 15.1 -0.69, 16.68 -0.56 C18.25 -0.44, 21.12 4.24, 22.01 5.02 M0.18 -0.63 C0.91 0.02, 2.49 4.19, 4.04 4.07 C5.59 3.95, 8.05 -1.45, 9.47 -1.33 C10.88 -1.22, 11.17 4.6, 12.52 4.75 C13.87 4.89, 16.15 -0.48, 17.59 -0.47 C19.02 -0.46, 20.31 3.92, 21.12 4.83" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(353.82496894994233 1030.7429872855034) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M0.02 0.43 C0.94 1.23, 3.51 4.89, 4.96 4.68 C6.42 4.47, 7.47 -0.75, 8.75 -0.83 C10.03 -0.9, 11.25 4.07, 12.64 4.24 C14.04 4.4, 15.53 0.16, 17.1 0.14 C18.66 0.12, 21.35 3.33, 22.03 4.11 M-0.63 0.18 C0.31 0.83, 3.32 3.95, 4.8 3.87 C6.29 3.8, 6.95 -0.41, 8.27 -0.28 C9.58 -0.15, 11.29 4.79, 12.67 4.65 C14.05 4.52, 15.15 -1.14, 16.56 -1.07 C17.98 -0.99, 20.38 4.21, 21.16 5.11" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(335.75513746331114 1030.8416698460217) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M0.53 0.3 C1.22 0.94, 2.78 4.48, 4.17 4.28 C5.56 4.08, 7.37 -1, 8.85 -0.89 C10.33 -0.78, 11.69 4.92, 13.07 4.94 C14.45 4.96, 15.77 -0.74, 17.12 -0.77 C18.48 -0.8, 20.4 3.92, 21.2 4.78 M0.14 -0.02 C1.01 0.67, 3.89 4.99, 5.27 4.93 C6.65 4.87, 7.08 -0.23, 8.42 -0.37 C9.76 -0.52, 11.95 4.13, 13.31 4.06 C14.68 3.99, 15.23 -0.85, 16.6 -0.78 C17.98 -0.71, 20.61 3.71, 21.56 4.47" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(372.39276490933685 1030.1430846285687) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M-0.27 -0.1 C0.36 0.55, 2.68 4.23, 4.27 4.22 C5.86 4.2, 7.8 -0.15, 9.27 -0.18 C10.74 -0.21, 11.92 4.02, 13.09 4.03 C14.26 4.05, 14.82 -0.16, 16.29 -0.1 C17.76 -0.03, 20.94 3.72, 21.93 4.4 M0.6 -0.63 C1.09 0.08, 2.34 4.89, 3.75 4.84 C5.16 4.78, 7.46 -0.89, 9.06 -0.97 C10.66 -1.05, 12.03 4.15, 13.35 4.35 C14.67 4.55, 15.73 0.32, 17 0.24 C18.28 0.16, 20.32 3.13, 20.99 3.89" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(153.79679393652805 1061.8771925019407) rotate(0 205.078125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># LOCAL_ARG was declared in stage-a</text></g><g transform="translate(157.70304393652782 1093.5585237631292) rotate(0 111.328125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $LOCAL_ARG</text></g><g stroke-linecap="round"><g transform="translate(157.51652935521463 1122.345486074279) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M-0.05 -0.39 C0.74 0.16, 3.02 3.95, 4.45 3.85 C5.89 3.75, 7.1 -1.15, 8.55 -1.01 C9.99 -0.86, 11.71 4.61, 13.12 4.72 C14.53 4.84, 15.58 -0.2, 17 -0.32 C18.43 -0.44, 20.98 3.12, 21.68 4 M-0.74 0.6 C0.01 1.43, 2.3 4.47, 4.03 4.27 C5.76 4.08, 8.07 -0.46, 9.62 -0.55 C11.18 -0.64, 12.25 3.65, 13.39 3.73 C14.52 3.8, 14.94 -0.3, 16.42 -0.1 C17.9 0.11, 21.49 4.16, 22.29 4.95" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(175.49644762753758 1122.2954768449304) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M0.02 -0.53 C0.69 0.22, 2.42 4.08, 3.97 4.1 C5.52 4.12, 7.82 -0.47, 9.32 -0.4 C10.83 -0.34, 11.73 4.56, 12.97 4.48 C14.21 4.4, 15.4 -0.96, 16.77 -0.87 C18.14 -0.79, 20.34 4.05, 21.21 4.99 M-0.64 0.39 C0.2 1.24, 3.33 4.94, 4.96 4.66 C6.59 4.38, 7.77 -1.36, 9.13 -1.3 C10.5 -1.24, 12.01 4.96, 13.17 5.02 C14.32 5.09, 14.66 -0.9, 16.07 -0.94 C17.47 -0.98, 20.52 3.91, 21.58 4.79" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(211.72650555384257 1123.0486153224965) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M-0.47 -0.28 C0.32 0.59, 3.13 4.77, 4.74 4.7 C6.35 4.64, 7.85 -0.51, 9.18 -0.64 C10.51 -0.77, 11.55 3.8, 12.74 3.93 C13.93 4.05, 14.76 -0.03, 16.3 0.12 C17.84 0.26, 21.03 4.06, 22 4.78 M0.29 0.77 C1.03 1.53, 3.03 4.03, 4.47 3.91 C5.91 3.78, 7.52 -0.05, 8.92 0 C10.31 0.05, 11.46 4.37, 12.81 4.19 C14.17 4, 15.64 -1.15, 17.02 -1.1 C18.4 -1.06, 20.18 3.65, 21.1 4.47" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(193.65667406721138 1122.9325846914435) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M0.31 0.33 C1.15 1.12, 3.16 4.72, 4.6 4.46 C6.04 4.21, 7.67 -1.27, 8.95 -1.2 C10.22 -1.12, 10.91 4.73, 12.27 4.92 C13.62 5.1, 15.45 -0.01, 17.09 -0.09 C18.72 -0.17, 21.27 3.76, 22.08 4.43 M-0.2 0.02 C0.63 0.93, 2.79 5.35, 4.25 5.21 C5.71 5.06, 7.25 -0.64, 8.56 -0.84 C9.87 -1.04, 10.77 3.84, 12.1 4.02 C13.43 4.2, 15.02 0.26, 16.54 0.25 C18.06 0.23, 20.25 3.19, 21.22 3.94" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(230.2943015132371 1122.2650050376951) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M0.16 0.08 C0.84 0.68, 2.98 3.96, 4.36 3.91 C5.75 3.86, 7.03 -0.34, 8.48 -0.21 C9.92 -0.07, 11.6 4.75, 13.05 4.71 C14.5 4.67, 15.68 -0.32, 17.17 -0.44 C18.65 -0.56, 21.2 3.2, 21.96 3.98 M-0.42 -0.35 C0.16 0.27, 2.24 4.48, 3.9 4.37 C5.55 4.26, 7.95 -0.9, 9.51 -1.01 C11.08 -1.12, 12.1 3.59, 13.29 3.71 C14.48 3.83, 15.37 -0.48, 16.67 -0.28 C17.96 -0.08, 20.16 4.01, 21.04 4.92" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(248.27421978555992 1122.1945642797073) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M-0.07 -0.47 C0.55 0.33, 2.34 4.89, 3.89 4.9 C5.45 4.91, 7.72 -0.32, 9.26 -0.41 C10.8 -0.5, 11.84 4.44, 13.14 4.36 C14.43 4.28, 15.62 -0.88, 17.05 -0.9 C18.48 -0.92, 20.99 3.38, 21.72 4.22 M-0.77 0.48 C0 1.13, 3.22 4.5, 4.85 4.2 C6.48 3.9, 7.61 -1.43, 9.04 -1.32 C10.47 -1.21, 12.17 4.78, 13.42 4.84 C14.66 4.9, 15 -1.05, 16.49 -0.97 C17.97 -0.9, 21.5 4.29, 22.34 5.28" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(284.50427771186503 1122.6450552612923) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M-0.54 0.52 C0.25 1.38, 3.03 4.91, 4.68 4.69 C6.33 4.48, 7.95 -0.63, 9.34 -0.77 C10.73 -0.9, 11.77 3.88, 13.02 3.9 C14.26 3.92, 15.41 -0.69, 16.81 -0.66 C18.21 -0.62, 20.63 3.21, 21.42 4.12 M0.18 0.31 C0.93 1.05, 2.88 3.97, 4.37 3.89 C5.87 3.8, 7.68 -0.23, 9.16 -0.18 C10.64 -0.14, 12.08 4.22, 13.24 4.15 C14.4 4.08, 14.68 -0.77, 16.12 -0.61 C17.56 -0.44, 20.96 4.31, 21.89 5.13" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(266.4344462252335 1123.032066997936) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M0.24 0.31 C1.13 0.95, 3.26 4.6, 4.76 4.34 C6.26 4.09, 7.89 -1.19, 9.22 -1.22 C10.56 -1.25, 11.56 4.07, 12.78 4.14 C13.99 4.22, 15.05 -0.86, 16.51 -0.75 C17.97 -0.65, 20.57 3.89, 21.53 4.79 M-0.29 0 C0.59 0.96, 2.95 5.17, 4.5 5.02 C6.04 4.88, 7.59 -0.79, 8.98 -0.88 C10.38 -0.96, 11.48 4.5, 12.87 4.52 C14.26 4.54, 15.8 -0.75, 17.33 -0.76 C18.86 -0.76, 21.43 3.66, 22.05 4.48" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(302.67812875224763 1122.300061650677) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M-0.49 0.1 C0.19 0.76, 2.8 4.43, 4.36 4.33 C5.92 4.22, 7.46 -0.6, 8.86 -0.55 C10.25 -0.51, 11.35 4.52, 12.72 4.6 C14.09 4.68, 15.62 -0.09, 17.06 -0.06 C18.49 -0.03, 20.49 4.05, 21.34 4.79 M0.26 -0.32 C0.84 0.4, 2.53 5.2, 3.89 5 C5.25 4.8, 6.94 -1.56, 8.43 -1.53 C9.91 -1.49, 11.44 4.9, 12.79 5.21 C14.13 5.51, 15 0.42, 16.5 0.3 C18 0.18, 21.02 3.91, 21.77 4.48" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(320.65804702457046 1122.7747308263333) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M-0.08 -0.05 C0.72 0.69, 2.78 4.63, 4.28 4.56 C5.78 4.48, 7.47 -0.56, 8.93 -0.52 C10.39 -0.49, 11.78 4.67, 13.03 4.74 C14.28 4.82, 14.9 -0.03, 16.43 -0.08 C17.95 -0.14, 21.24 3.68, 22.17 4.39 M-0.78 -0.56 C-0.03 0.01, 2.21 3.83, 3.76 3.68 C5.32 3.53, 6.95 -1.5, 8.54 -1.49 C10.12 -1.47, 11.8 3.47, 13.25 3.76 C14.7 4.05, 15.86 0.24, 17.21 0.26 C18.56 0.28, 20.49 3.07, 21.36 3.88" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(356.8881049508756 1123.0264510037396) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M-0.16 0.18 C0.58 0.95, 2.78 4.67, 4.35 4.58 C5.91 4.49, 7.89 -0.4, 9.23 -0.38 C10.58 -0.36, 11.06 4.73, 12.4 4.72 C13.73 4.7, 15.65 -0.4, 17.26 -0.48 C18.86 -0.57, 21.27 3.44, 22.03 4.18 M0.76 -0.21 C1.43 0.4, 2.5 3.9, 3.87 3.72 C5.24 3.54, 7.59 -1.27, 9 -1.27 C10.4 -1.27, 11 3.56, 12.3 3.72 C13.6 3.87, 15.33 -0.6, 16.8 -0.35 C18.28 -0.1, 20.27 4.37, 21.14 5.23" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(338.8182734642444 1123.1251335642578) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M-0.09 0.2 C0.71 0.96, 3.2 4.83, 4.65 4.73 C6.1 4.62, 7.17 -0.34, 8.6 -0.41 C10.03 -0.48, 11.81 4.36, 13.23 4.32 C14.64 4.27, 15.69 -0.64, 17.12 -0.69 C18.54 -0.75, 21.03 3.09, 21.77 3.99 M-0.8 -0.17 C-0.03 0.42, 2.58 4.13, 4.33 3.94 C6.08 3.75, 8.17 -1.45, 9.71 -1.31 C11.25 -1.17, 12.41 4.67, 13.55 4.78 C14.7 4.88, 15.11 -0.69, 16.59 -0.66 C18.06 -0.64, 21.56 4.12, 22.42 4.93" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round" transform="translate(86.16203204724468 804.2740687105547) rotate(0 448.5219508046551 174.28500452423054)"><path d="M32 0 C351.79 3.61, 670.37 4.07, 865.04 0 M32 0 C264.12 0.05, 497.17 -0.3, 865.04 0 M865.04 0 C887.9 1.3, 896 12.03, 897.04 32 M865.04 0 C886.5 -0.3, 894.88 8.63, 897.04 32 M897.04 32 C897.48 97.41, 896.15 162.77, 897.04 316.57 M897.04 32 C897.07 92.06, 898.22 151.82, 897.04 316.57 M897.04 316.57 C897.58 336.71, 885.78 349.31, 865.04 348.57 M897.04 316.57 C895.85 339.4, 886.2 349.25, 865.04 348.57 M865.04 348.57 C629.97 345.86, 394.81 345.06, 32 348.57 M865.04 348.57 C550.26 351.01, 235.39 351.14, 32 348.57 M32 348.57 C12.01 348.62, -1.4 339.54, 0 316.57 M32 348.57 C9.95 348.14, 1.47 336.58, 0 316.57 M0 316.57 C1.5 240.72, 0.39 162.93, 0 32 M0 316.57 C-2.39 251.36, -1.66 184.74, 0 32 M0 32 C-1.31 10.19, 12.61 -0.29, 32 0 M0 32 C2.12 9.49, 8.94 1.64, 32 0" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g><g stroke-linecap="round"><g transform="translate(133.52793683734149 806.7575385411618) rotate(0 -5.684341886080802e-14 172.8749189001423)"><path d="M0.47 0.38 C0.86 57.78, 1.3 287.92, 1.16 345.5 M-0.74 -0.46 C-0.3 57.64, 0.92 288.95, 0.82 346.9" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(67.32218829724457 970.1031840213891) rotate(270 41.015625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">stage-b</text></g><g transform="translate(96.36391449189273 760.7606572486847) rotate(0 345.703125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">FROM --platform=$BUILDPLATFORM alpine:${VERSION} as stage-b</text></g><g stroke-linecap="round" transform="translate(90.36051876314593 305.3363422867699) rotate(0 450.0057524190432 185.89722333765815)"><path d="M32 0 C253.07 3.22, 475.72 3.73, 868.01 0 M32 0 C233.37 1.81, 434.09 1.91, 868.01 0 M868.01 0 C887.69 -1.83, 901.11 9.33, 900.01 32 M868.01 0 C890.95 0.42, 900.56 8.62, 900.01 32 M900.01 32 C899.04 106.43, 897.5 182.87, 900.01 339.79 M900.01 32 C900.22 153.56, 899.21 274.98, 900.01 339.79 M900.01 339.79 C901.08 362.67, 891.34 372.8, 868.01 371.79 M900.01 339.79 C899.93 360.28, 891.52 371.48, 868.01 371.79 M868.01 371.79 C546.1 368.69, 225.94 369.31, 32 371.79 M868.01 371.79 C547.75 370.12, 226.36 370.2, 32 371.79 M32 371.79 C11.81 373.14, 1.09 359.41, 0 339.79 M32 371.79 C12.32 372.28, 1.7 362.47, 0 339.79 M0 339.79 C1.67 267.75, 2.33 193.59, 0 32 M0 339.79 C-0.74 227.48, -0.24 115.43, 0 32 M0 32 C0.1 8.85, 11.2 -1.29, 32 0 M0 32 C0.24 10.87, 11.99 -0.62, 32 0" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g><g stroke-linecap="round"><g transform="translate(137.72642355324274 304.9262584799999) rotate(0 0 185.052722866983)"><path d="M0.02 0.26 C0.34 62, 0.8 307.84, 0.78 369.39 M-1.44 -0.65 C-1.1 61.32, 0.15 308.68, 0.24 370.55" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(72.28855765490334 484.2163361370194) rotate(270 41.015625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">stage-a</text></g><g transform="translate(95.722270550536 232.87221790524399) rotate(0 410.15625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># FROM-lines belong to the global scope and have access to global ARGs</text></g><g transform="translate(97.23013381272517 266.4822695378388) rotate(0 193.359375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">FROM alpine:${VERSION} as stage-a</text></g><g transform="translate(160.8094110936372 327.94112834784005) rotate(0 398.4375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Redeclaring GLOBAL_ARG without a value inherits the global default</text></g><g transform="translate(162.2978888321311 359.7027312066824) rotate(0 82.03125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ARG GLOBAL_ARG</text></g><g transform="translate(162.1833846676236 637.7797382867685) rotate(0 117.1875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $GLOBAL_ARG</text></g><g transform="translate(158.27871581681643 401.0411395379771) rotate(0 269.53125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># ARG here this scope creates a local argument</text></g><g transform="translate(160.17975748348294 433.10133271660504) rotate(0 210.9375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ARG LOCAL_ARG="local arg in stage-a"</text></g><g transform="translate(158.27871581681643 480.5488444213912) rotate(0 251.953125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Set an environment variable in this scope</text></g><g transform="translate(160.17975748348294 510.61994138181205) rotate(0 105.46875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ENV LOCAL_ENV=true</text></g><g transform="translate(158.27871581681643 551.2419656604121) rotate(0 363.28125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Set an environment variable to the value of a build argument</text></g><g transform="translate(158.66387367202674 583.326220486841) rotate(0 123.046875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ENV MY_VAR=$LOCAL_ARG</text></g><g stroke-linecap="round" transform="translate(91.87640257460168 1257.5483255258505) rotate(0 448.0768103203382 70.16871796463431)"><path d="M32 0 C344.86 1.25, 658.48 1.05, 864.15 0 M32 0 C232.76 2.32, 432.6 2.49, 864.15 0 M864.15 0 C886.73 -0.64, 894.99 11.08, 896.15 32 M864.15 0 C886.02 -0.23, 894.74 12.71, 896.15 32 M896.15 32 C896.74 54.19, 897.02 79.1, 896.15 108.34 M896.15 32 C897.59 59.95, 897.41 88.43, 896.15 108.34 M896.15 108.34 C897.72 130.08, 886.87 141.58, 864.15 140.34 M896.15 108.34 C895.98 128.64, 884.2 139.44, 864.15 140.34 M864.15 140.34 C543.22 139.74, 222.44 139.76, 32 140.34 M864.15 140.34 C558.29 138.23, 252.73 137.75, 32 140.34 M32 140.34 C8.78 138.64, 0.05 130.79, 0 108.34 M32 140.34 C12.59 142.62, 0.77 130.37, 0 108.34 M0 108.34 C1.79 89.03, -0.96 66.8, 0 32 M0 108.34 C1.15 89.79, 0.15 70.96, 0 32 M0 32 C-0.58 11.54, 10.17 0.01, 32 0 M0 32 C-2.02 11.84, 10.18 -0.43, 32 0" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g><g stroke-linecap="round"><g transform="translate(139.2423073646985 1257.6246950342768) rotate(0 0 70.4404739371115)"><path d="M0.77 -1.18 C0.89 22.37, 0.55 116.65, 0.47 140.17 M-0.29 0.81 C-0.26 24.61, -0.22 118, -0.23 141.34" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(73.03655882460157 1316.7954582743134) rotate(270 41.015625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">stage-c</text></g><g transform="translate(96.22756515435458 1188.2407683246124) rotate(0 175.78125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># New stage based on "stage-a"</text></g><g transform="translate(97.23815436199197 1221.8508199572072) rotate(0 134.765625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">FROM stage-a AS stage-c</text></g><g transform="translate(161.30668514818876 1280.7546527819427) rotate(0 339.84375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Arguments and variables are inherited from parent stages</text></g><g transform="translate(160.17975748348272 1320.0639886026324) rotate(0 111.328125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $LOCAL_ARG</text></g><g transform="translate(160.68505208730153 1353.798418819483) rotate(0 111.328125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $LOCAL_ENV</text></g><g transform="translate(459.51762903653366 1001.2272136084616) rotate(0 152.34375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints an empty string</text></g><g transform="translate(459.51762903653366 1094.562345428122) rotate(0 152.34375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints an empty string</text></g><g transform="translate(455.0599700089376 634.5587543162438) rotate(0 187.5 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints "global default value"</text></g><g transform="translate(459.7763686520491 1318.926103708041) rotate(0 187.5 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints "local arg in stage-a"</text></g><g transform="translate(459.7763686520491 1352.6765750234256) rotate(0 93.75 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints "true"</text></g><g transform="translate(157.31376429739407 868.3488129535199) rotate(0 105.46875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ARG TARGETPLATFORM</text></g><g transform="translate(154.5346844690887 828.9977562693839) rotate(0 380.859375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># You must redeclare pre-defined arguments to use them in a stage</text></g><g transform="translate(157.73636020851723 901.372882634279) rotate(0 140.625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $TARGETPLATFORM</text></g><g transform="translate(456.6373611167471 901.4832955042493) rotate(0 228.515625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints os/arch/variant of --platform</text></g><g stroke-linecap="round"><g transform="translate(535.1414722881311 675.2569609220587) rotate(0 250.3253528965804 288.4689111292416)"><path d="M0 0 C-1.43 6.83, -0.07 11.69, -0.4 26.76 M-0.4 26.76 C139.78 27.72, 280.08 28.44, 512.12 29.99 M512.12 29.99 C514.55 160.21, 515.61 291.93, 516.83 530.58 M516.83 530.58 C375.82 532.42, 234.27 532.95, -14.18 533.72 M-14.18 533.72 C-15.62 549.61, -16.91 564.02, -16.18 576.94" stroke="#1e1e1e" stroke-width="2.5" fill="none" stroke-dasharray="8 10"></path></g></g><mask></mask><g transform="translate(97.67451560383006 726.2688100539343) rotate(0 404.296875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Pre-defined multi-platform arguments like $BUILDPLATFORM are global</text></g></svg>
+  <g stroke-linecap="round" transform="translate(10 10.695992798288444) rotate(0 499.1377001126125 710.7356846485959)"><path d="M32 0 C255.74 -2.14, 478.15 -1.24, 966.28 0 M32 0 C378.71 -3.28, 724.69 -3.27, 966.28 0 M966.28 0 C986.17 0.74, 996.63 8.91, 998.28 32 M966.28 0 C985.53 0.47, 999.22 12.32, 998.28 32 M998.28 32 C998.87 540.44, 998.57 1047.3, 998.28 1389.47 M998.28 32 C1000.13 332.72, 999.89 632.34, 998.28 1389.47 M998.28 1389.47 C999.74 1412.68, 987.23 1421.33, 966.28 1421.47 M998.28 1389.47 C999.06 1409.62, 986.33 1421.09, 966.28 1421.47 M966.28 1421.47 C617.92 1417.07, 269.59 1418.23, 32 1421.47 M966.28 1421.47 C760.82 1420.97, 555.95 1421.09, 32 1421.47 M32 1421.47 C10.29 1419.93, 1.76 1410.9, 0 1389.47 M32 1421.47 C10.06 1422.32, 0.01 1412.67, 0 1389.47 M0 1389.47 C0.04 978.98, 1.4 567.71, 0 32 M0 1389.47 C-0.01 888.46, 0.38 386.83, 0 32 M0 32 C-1.3 10.77, 11.68 1.71, 32 0 M0 32 C2.2 11.96, 9.68 -1.32, 32 0" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g><g stroke-linecap="round"><g transform="translate(68.95218432054128 10.893058988452026) rotate(0 0 709.0292944687217)"><path d="M1 -0.89 C0.94 235.16, 0.22 1180.9, -0.05 1417.28 M0.07 1.25 C-0.18 237.36, -0.73 1182.22, -1.02 1418.4" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(-30.50876650189207 720.2254322648956) rotate(270 70.3125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">Global scope</text></g><g transform="translate(98.75403817344818 28.194164132218475) rotate(0 322.265625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Build arguments declared here are in the global scope</text></g><g transform="translate(98.75403817344818 61.069164132218475) rotate(0 216.796875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ARG GLOBAL_ARG="global default value"</text></g><g transform="translate(99.15768400678144 94.23322663221848) rotate(0 105.46875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ARG VERSION="3.21"</text></g><g transform="translate(98.75403817344818 138.37052499260426) rotate(0 357.421875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># You can't declare environment variables in the global scope</text></g><g transform="translate(98.75403817344818 171.24552499260426) rotate(0 117.1875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ENV GLOBAL_ENV=false</text></g><g stroke-linecap="round"><g transform="translate(96.71975251551498 199.24591157364756) rotate(0 10.875622044046054 1.871948995827239)"><path d="M-0.11 -0.2 C0.54 0.52, 2.86 4.62, 4.45 4.6 C6.05 4.59, 8.05 -0.28, 9.46 -0.26 C10.87 -0.25, 11.68 4.72, 12.91 4.71 C14.14 4.71, 15.32 -0.3, 16.84 -0.32 C18.36 -0.33, 21.28 3.92, 22.04 4.63 M0.83 -0.78 C1.37 -0.25, 2.61 3.81, 4.03 3.76 C5.45 3.7, 7.83 -1.08, 9.33 -1.09 C10.84 -1.1, 11.94 3.55, 13.07 3.72 C14.21 3.88, 14.82 -0.18, 16.17 -0.09 C17.51 -0.01, 20.28 3.43, 21.16 4.23" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(114.69967078783793 199.19590234429887) rotate(0 10.875622044046054 1.871948995827239)"><path d="M0.02 0.23 C0.85 1.07, 3.36 4.95, 4.88 4.84 C6.39 4.74, 7.8 -0.35, 9.12 -0.41 C10.44 -0.47, 11.47 4.46, 12.81 4.48 C14.14 4.51, 15.7 -0.16, 17.13 -0.25 C18.55 -0.34, 20.61 3.23, 21.36 3.94 M-0.64 -0.13 C0.17 0.58, 3.09 4.31, 4.67 4.12 C6.25 3.92, 7.45 -1.46, 8.82 -1.31 C10.19 -1.16, 11.62 4.81, 12.92 5.03 C14.21 5.25, 15.13 0.04, 16.61 0.01 C18.09 -0.02, 20.92 4.05, 21.8 4.85" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(150.92972871414293 199.94904082186486) rotate(179.39098195963928 10.875622044045997 1.871948995827239)"><path d="M0.44 0.46 C1.19 1.21, 3.11 4.88, 4.54 4.7 C5.96 4.51, 7.59 -0.61, 9.01 -0.64 C10.44 -0.66, 11.86 4.6, 13.1 4.55 C14.33 4.5, 15.02 -0.85, 16.45 -0.94 C17.87 -1.03, 20.72 3.16, 21.63 4 M0 0.23 C0.69 0.8, 2.71 3.93, 4.16 3.9 C5.6 3.86, 7.13 -0.2, 8.66 0.01 C10.2 0.21, 11.93 5.31, 13.36 5.13 C14.78 4.96, 15.77 -1.01, 17.24 -1.04 C18.71 -1.07, 21.37 3.96, 22.2 4.94" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(132.85989722751174 199.83301019081188) rotate(179.39098195963928 10.875622044046054 1.871948995827239)"><path d="M0.1 0.32 C0.77 0.99, 2.9 4.62, 4.43 4.47 C5.96 4.32, 7.97 -0.47, 9.3 -0.57 C10.63 -0.67, 11.18 3.91, 12.41 3.86 C13.65 3.81, 15.14 -0.91, 16.72 -0.88 C18.29 -0.85, 21 3.24, 21.87 4.06 M-0.51 0.01 C0.04 0.74, 2.4 3.81, 4 3.55 C5.6 3.29, 7.71 -1.65, 9.1 -1.56 C10.49 -1.47, 10.9 3.99, 12.32 4.09 C13.75 4.19, 15.94 -1.1, 17.65 -0.95 C19.35 -0.79, 21.79 4.08, 22.57 5.03" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(169.49752467353744 199.16543053706374) rotate(0 10.875622044045997 1.871948995827239)"><path d="M0 0.09 C0.77 0.79, 3.28 4.76, 4.72 4.53 C6.16 4.31, 7.29 -1.16, 8.62 -1.26 C9.95 -1.37, 11.29 3.85, 12.68 3.92 C14.07 3.99, 15.42 -0.83, 16.96 -0.82 C18.49 -0.81, 21.12 3.02, 21.91 4 M-0.67 -0.34 C0.05 0.16, 2.7 3.75, 4.44 3.65 C6.17 3.55, 8.35 -1.03, 9.74 -0.94 C11.12 -0.85, 11.63 4.16, 12.73 4.18 C13.83 4.19, 14.97 -0.98, 16.34 -0.86 C17.72 -0.73, 20.03 4.02, 20.97 4.94" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(187.47744294586028 199.09498977907566) rotate(0 10.875622044046054 1.871948995827239)"><path d="M0.29 0.16 C0.96 0.78, 2.61 4.07, 4.04 3.84 C5.47 3.62, 7.41 -1.23, 8.89 -1.2 C10.37 -1.18, 11.57 3.93, 12.92 3.98 C14.27 4.03, 15.53 -1.05, 17 -0.88 C18.46 -0.71, 20.92 4.07, 21.71 5.02 M-0.23 -0.24 C0.62 0.42, 3.62 4.37, 5.07 4.27 C6.52 4.17, 7.14 -0.85, 8.48 -0.85 C9.82 -0.85, 11.77 4.28, 13.09 4.27 C14.42 4.25, 14.87 -1.04, 16.41 -0.95 C17.95 -0.85, 21.39 3.94, 22.33 4.83" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(223.70750087216538 199.54548076066084) rotate(179.39098195963928 10.875622044046054 1.871948995827239)"><path d="M-0.39 -0.54 C0.28 0.09, 2.72 4, 4.31 3.9 C5.9 3.8, 7.69 -1.15, 9.13 -1.14 C10.57 -1.14, 11.69 3.71, 12.97 3.92 C14.24 4.13, 15.33 -0.01, 16.8 0.14 C18.27 0.29, 21.02 4.03, 21.77 4.83 M0.4 0.38 C0.97 1.04, 2.41 4.55, 3.81 4.36 C5.22 4.17, 7.28 -0.73, 8.84 -0.76 C10.4 -0.79, 11.95 4.23, 13.16 4.18 C14.37 4.13, 14.57 -1.12, 16.11 -1.06 C17.66 -1, 21.54 3.6, 22.42 4.54" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(205.63766938553385 199.93249249730445) rotate(179.39098195963928 10.875622044046054 1.871948995827239)"><path d="M-0.13 -0.48 C0.7 0.27, 3 4.08, 4.55 3.96 C6.1 3.84, 7.8 -1.37, 9.17 -1.2 C10.54 -1.04, 11.49 4.75, 12.77 4.94 C14.05 5.14, 15.43 -0.04, 16.86 -0.05 C18.29 -0.05, 20.46 4.14, 21.33 4.93 M0.81 0.47 C1.61 1.32, 2.83 4.67, 4.18 4.45 C5.53 4.23, 7.46 -0.78, 8.91 -0.85 C10.35 -0.91, 11.65 3.87, 12.86 4.06 C14.08 4.25, 14.72 0.21, 16.2 0.32 C17.68 0.42, 20.7 4.04, 21.76 4.69" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(241.88135191254798 199.20048715004572) rotate(0 10.875622044045997 1.871948995827239)"><path d="M0.11 -0.42 C0.9 0.31, 3.11 3.86, 4.59 3.9 C6.07 3.94, 7.6 -0.32, 8.98 -0.18 C10.35 -0.04, 11.59 4.71, 12.83 4.75 C14.07 4.79, 14.88 0.06, 16.42 0.05 C17.96 0.05, 21.16 4, 22.09 4.71 M-0.49 0.56 C0.25 1.38, 2.72 4.61, 4.24 4.36 C5.76 4.1, 7.16 -0.87, 8.61 -0.97 C10.06 -1.06, 11.52 3.81, 12.95 3.77 C14.38 3.74, 15.82 -1.29, 17.2 -1.2 C18.58 -1.1, 20.37 3.27, 21.25 4.35" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(259.8612701848708 199.675156325702) rotate(0 10.875622044046054 1.871948995827239)"><path d="M0.16 -0.48 C0.87 0.41, 2.92 4.91, 4.4 4.93 C5.88 4.94, 7.7 -0.36, 9.04 -0.37 C10.37 -0.38, 11.03 4.82, 12.39 4.85 C13.75 4.89, 15.57 -0.08, 17.18 -0.17 C18.79 -0.26, 21.35 3.57, 22.05 4.31 M-0.43 0.47 C0.2 1.26, 2.42 4.53, 3.94 4.24 C5.47 3.95, 7.31 -1.2, 8.7 -1.25 C10.09 -1.3, 10.95 3.7, 12.28 3.93 C13.62 4.16, 15.21 0.16, 16.69 0.13 C18.17 0.1, 20.38 2.91, 21.17 3.75" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(296.0913281111759 199.92687650310802) rotate(179.39098195963928 10.875622044046054 1.871948995827239)"><path d="M-0.04 0.55 C0.68 1.42, 3.02 4.87, 4.45 4.74 C5.89 4.6, 7.15 -0.25, 8.59 -0.27 C10.04 -0.29, 11.73 4.68, 13.15 4.63 C14.58 4.58, 15.77 -0.51, 17.14 -0.57 C18.5 -0.64, 20.59 3.32, 21.35 4.24 M-0.72 0.35 C-0.09 1.11, 2.3 4.2, 4.03 3.96 C5.77 3.71, 8.13 -1.04, 9.7 -1.1 C11.26 -1.16, 12.29 3.48, 13.44 3.59 C14.59 3.69, 15.23 -0.49, 16.62 -0.48 C18.01 -0.47, 20.9 2.8, 21.79 3.65" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(278.02149662454474 200.0255590636262) rotate(179.39098195963928 10.875622044045997 1.871948995827239)"><path d="M0.02 0.36 C0.7 1.07, 2.46 4.98, 4.01 4.84 C5.57 4.7, 7.84 -0.39, 9.36 -0.49 C10.87 -0.6, 11.92 4.25, 13.1 4.23 C14.28 4.21, 15.01 -0.76, 16.44 -0.64 C17.87 -0.51, 20.72 4.15, 21.68 4.96 M-0.63 0.07 C0.22 0.87, 3.39 4.36, 5.03 4.11 C6.67 3.86, 7.8 -1.53, 9.19 -1.44 C10.58 -1.35, 12.03 4.5, 13.37 4.65 C14.71 4.79, 15.75 -0.59, 17.23 -0.58 C18.72 -0.56, 21.65 3.78, 22.29 4.74" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(314.65912407057044 199.32697384617302) rotate(0 10.875622044046054 1.871948995827239)"><path d="M-0.42 0.46 C0.37 1.17, 3.16 4.84, 4.78 4.61 C6.4 4.39, 8.04 -0.82, 9.31 -0.89 C10.58 -0.97, 11.17 4, 12.41 4.16 C13.65 4.33, 15.14 0.07, 16.77 0.08 C18.4 0.1, 21.3 3.51, 22.21 4.25 M0.36 0.22 C1.11 0.73, 3.06 3.87, 4.52 3.77 C5.98 3.67, 7.81 -0.51, 9.11 -0.38 C10.41 -0.25, 11.16 4.68, 12.32 4.55 C13.47 4.42, 14.55 -1, 16.06 -1.15 C17.58 -1.3, 20.58 2.82, 21.42 3.67" stroke="#e03131" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(153.889524612174 968.3053802939692) rotate(0 263.671875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># GLOBAL_ARG was not redeclared in this stage</text></g><g transform="translate(155.79056627884052 1001.2530445209427) rotate(0 117.1875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $GLOBAL_ARG</text></g><g stroke-linecap="round"><g transform="translate(154.4533933542814 1030.0620223560434) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M-0.47 -0.23 C0.3 0.35, 3 3.88, 4.56 3.83 C6.13 3.79, 7.6 -0.52, 8.92 -0.51 C10.24 -0.49, 11.17 3.93, 12.48 3.93 C13.79 3.92, 15.19 -0.55, 16.78 -0.53 C18.36 -0.5, 21.24 3.21, 22 4.05 M0.28 -0.82 C1.01 -0.23, 2.82 4.36, 4.2 4.25 C5.57 4.15, 7.16 -1.45, 8.53 -1.46 C9.9 -1.47, 11.16 4.02, 12.42 4.19 C13.68 4.36, 14.63 -0.55, 16.07 -0.41 C17.52 -0.27, 20.21 4.3, 21.11 5.02" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(172.43331162660434 1030.0120131266947) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M0.13 -0.54 C0.93 0.26, 2.92 4.71, 4.34 4.6 C5.77 4.49, 7.28 -1.14, 8.69 -1.2 C10.09 -1.25, 11.34 4.21, 12.74 4.27 C14.15 4.34, 15.66 -0.87, 17.09 -0.83 C18.52 -0.79, 20.55 3.65, 21.35 4.52 M-0.47 0.37 C0.29 1.02, 2.15 3.95, 3.86 3.75 C5.58 3.55, 8.34 -1, 9.83 -0.84 C11.33 -0.68, 11.7 4.72, 12.82 4.72 C13.94 4.71, 15.06 -0.76, 16.55 -0.87 C18.04 -0.98, 20.84 3.3, 21.78 4.06" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(208.66336955290933 1030.7651516042604) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M-0.09 0.22 C0.57 0.97, 2.6 4.09, 4.1 3.91 C5.61 3.73, 7.46 -0.86, 8.95 -0.85 C10.44 -0.84, 11.81 3.89, 13.06 3.97 C14.31 4.05, 14.97 -0.43, 16.44 -0.36 C17.9 -0.3, 21.01 3.56, 21.85 4.37 M-0.8 -0.14 C0.02 0.7, 3.61 4.4, 5.17 4.37 C6.73 4.34, 7.21 -0.29, 8.57 -0.31 C9.93 -0.33, 11.86 4.23, 13.3 4.26 C14.74 4.28, 15.68 -0.09, 17.22 -0.16 C18.77 -0.23, 21.81 3.16, 22.55 3.84" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(190.59353806627814 1030.6491209732073) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M-0.33 -0.47 C0.41 0.21, 2.77 4.37, 4.37 4.26 C5.97 4.14, 7.93 -1.18, 9.27 -1.15 C10.61 -1.12, 11.12 4.33, 12.4 4.44 C13.68 4.55, 15.43 -0.52, 16.94 -0.51 C18.46 -0.5, 20.81 3.68, 21.52 4.5 M0.5 0.48 C1.18 1.22, 2.48 5.1, 3.91 4.9 C5.33 4.69, 7.65 -0.78, 9.05 -0.77 C10.45 -0.76, 11.1 4.9, 12.31 4.96 C13.52 5.03, 14.71 -0.23, 16.33 -0.39 C17.95 -0.54, 21.23 3.35, 22.04 4.03" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(227.23116551230385 1029.9815413194594) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M-0.06 -0.12 C0.77 0.62, 3.24 4.05, 4.68 3.96 C6.13 3.86, 7.24 -0.74, 8.61 -0.68 C9.98 -0.63, 11.58 4.24, 12.91 4.29 C14.25 4.34, 15.23 -0.39, 16.61 -0.38 C17.99 -0.37, 20.35 3.49, 21.21 4.37 M-0.76 -0.66 C0.05 0.18, 2.63 4.34, 4.38 4.44 C6.13 4.54, 8.27 -0.11, 9.72 -0.06 C11.17 -0.01, 11.78 4.76, 13.08 4.74 C14.37 4.72, 16.07 -0.04, 17.48 -0.19 C18.9 -0.34, 20.8 3.06, 21.57 3.84" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(245.21108378462668 1029.9111005614711) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M0.25 -0.42 C0.93 0.33, 2.55 4.49, 4.03 4.42 C5.51 4.35, 7.7 -0.83, 9.12 -0.83 C10.54 -0.83, 11.38 4.36, 12.58 4.42 C13.77 4.47, 14.76 -0.59, 16.3 -0.51 C17.83 -0.43, 20.78 4.03, 21.78 4.91 M-0.29 0.55 C0.57 1.41, 3.54 5.28, 5.06 5.14 C6.57 5, 7.57 -0.25, 8.82 -0.29 C10.08 -0.32, 11.2 4.95, 12.57 4.93 C13.93 4.92, 15.37 -0.34, 17.01 -0.38 C18.66 -0.43, 21.74 3.87, 22.43 4.66" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(281.4411417109318 1030.3615915430566) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M-0.4 0.04 C0.31 0.83, 3.01 4.4, 4.54 4.27 C6.07 4.15, 7.5 -0.71, 8.78 -0.7 C10.07 -0.7, 10.92 4.17, 12.27 4.29 C13.61 4.41, 15.2 -0.05, 16.87 0.03 C18.53 0.11, 21.51 4.05, 22.28 4.78 M0.39 -0.41 C1.02 0.49, 2.84 4.86, 4.16 4.92 C5.48 4.97, 6.99 -0.06, 8.32 -0.09 C9.64 -0.12, 10.78 4.93, 12.1 4.74 C13.41 4.55, 14.64 -1.19, 16.21 -1.23 C17.78 -1.28, 20.62 3.63, 21.53 4.46" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(263.37131022430026 1030.7486032796999) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M0.1 -0.11 C0.87 0.62, 2.81 4.52, 4.2 4.4 C5.6 4.28, 7.03 -0.9, 8.47 -0.83 C9.91 -0.76, 11.35 4.71, 12.83 4.83 C14.32 4.95, 15.93 -0.02, 17.37 -0.1 C18.81 -0.18, 20.78 3.64, 21.49 4.37 M-0.51 -0.64 C0.2 0.18, 1.98 5.05, 3.65 5.11 C5.32 5.17, 7.96 -0.08, 9.51 -0.29 C11.06 -0.49, 11.72 3.8, 12.96 3.89 C14.2 3.98, 15.47 0.24, 16.97 0.23 C18.48 0.23, 21.19 3.01, 21.99 3.85" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(299.6149927513144 1030.0165979324413) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M-0.23 0.02 C0.4 0.75, 2.35 4.33, 3.89 4.28 C5.44 4.22, 7.47 -0.36, 9.04 -0.29 C10.62 -0.22, 12.08 4.73, 13.34 4.7 C14.59 4.66, 15.2 -0.44, 16.58 -0.5 C17.95 -0.57, 20.68 3.39, 21.59 4.31 M0.65 -0.44 C1.43 0.38, 3.5 5.04, 4.85 4.92 C6.19 4.81, 7.5 -0.93, 8.71 -1.14 C9.91 -1.34, 10.6 3.57, 12.06 3.69 C13.51 3.82, 15.75 -0.39, 17.44 -0.38 C19.12 -0.37, 21.31 2.91, 22.14 3.76" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(317.5949110236372 1030.4912671080976) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M-0.54 -0.1 C0.24 0.69, 2.78 4.87, 4.46 4.81 C6.14 4.76, 8.2 -0.34, 9.54 -0.42 C10.89 -0.51, 11.36 4.32, 12.54 4.3 C13.73 4.27, 15.1 -0.69, 16.68 -0.56 C18.25 -0.44, 21.12 4.24, 22.01 5.02 M0.18 -0.63 C0.91 0.02, 2.49 4.19, 4.04 4.07 C5.59 3.95, 8.05 -1.45, 9.47 -1.33 C10.88 -1.22, 11.17 4.6, 12.52 4.75 C13.87 4.89, 16.15 -0.48, 17.59 -0.47 C19.02 -0.46, 20.31 3.92, 21.12 4.83" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(353.82496894994233 1030.7429872855034) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M0.02 0.43 C0.94 1.23, 3.51 4.89, 4.96 4.68 C6.42 4.47, 7.47 -0.75, 8.75 -0.83 C10.03 -0.9, 11.25 4.07, 12.64 4.24 C14.04 4.4, 15.53 0.16, 17.1 0.14 C18.66 0.12, 21.35 3.33, 22.03 4.11 M-0.63 0.18 C0.31 0.83, 3.32 3.95, 4.8 3.87 C6.29 3.8, 6.95 -0.41, 8.27 -0.28 C9.58 -0.15, 11.29 4.79, 12.67 4.65 C14.05 4.52, 15.15 -1.14, 16.56 -1.07 C17.98 -0.99, 20.38 4.21, 21.16 5.11" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(335.75513746331114 1030.8416698460217) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M0.53 0.3 C1.22 0.94, 2.78 4.48, 4.17 4.28 C5.56 4.08, 7.37 -1, 8.85 -0.89 C10.33 -0.78, 11.69 4.92, 13.07 4.94 C14.45 4.96, 15.77 -0.74, 17.12 -0.77 C18.48 -0.8, 20.4 3.92, 21.2 4.78 M0.14 -0.02 C1.01 0.67, 3.89 4.99, 5.27 4.93 C6.65 4.87, 7.08 -0.23, 8.42 -0.37 C9.76 -0.52, 11.95 4.13, 13.31 4.06 C14.68 3.99, 15.23 -0.85, 16.6 -0.78 C17.98 -0.71, 20.61 3.71, 21.56 4.47" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(372.39276490933685 1030.1430846285687) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M-0.27 -0.1 C0.36 0.55, 2.68 4.23, 4.27 4.22 C5.86 4.2, 7.8 -0.15, 9.27 -0.18 C10.74 -0.21, 11.92 4.02, 13.09 4.03 C14.26 4.05, 14.82 -0.16, 16.29 -0.1 C17.76 -0.03, 20.94 3.72, 21.93 4.4 M0.6 -0.63 C1.09 0.08, 2.34 4.89, 3.75 4.84 C5.16 4.78, 7.46 -0.89, 9.06 -0.97 C10.66 -1.05, 12.03 4.15, 13.35 4.35 C14.67 4.55, 15.73 0.32, 17 0.24 C18.28 0.16, 20.32 3.13, 20.99 3.89" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(153.79679393652805 1061.8771925019407) rotate(0 205.078125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># LOCAL_ARG was declared in stage-a</text></g><g transform="translate(157.70304393652782 1093.5585237631292) rotate(0 111.328125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $LOCAL_ARG</text></g><g stroke-linecap="round"><g transform="translate(157.51652935521463 1122.345486074279) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M-0.05 -0.39 C0.74 0.16, 3.02 3.95, 4.45 3.85 C5.89 3.75, 7.1 -1.15, 8.55 -1.01 C9.99 -0.86, 11.71 4.61, 13.12 4.72 C14.53 4.84, 15.58 -0.2, 17 -0.32 C18.43 -0.44, 20.98 3.12, 21.68 4 M-0.74 0.6 C0.01 1.43, 2.3 4.47, 4.03 4.27 C5.76 4.08, 8.07 -0.46, 9.62 -0.55 C11.18 -0.64, 12.25 3.65, 13.39 3.73 C14.52 3.8, 14.94 -0.3, 16.42 -0.1 C17.9 0.11, 21.49 4.16, 22.29 4.95" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(175.49644762753758 1122.2954768449304) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M0.02 -0.53 C0.69 0.22, 2.42 4.08, 3.97 4.1 C5.52 4.12, 7.82 -0.47, 9.32 -0.4 C10.83 -0.34, 11.73 4.56, 12.97 4.48 C14.21 4.4, 15.4 -0.96, 16.77 -0.87 C18.14 -0.79, 20.34 4.05, 21.21 4.99 M-0.64 0.39 C0.2 1.24, 3.33 4.94, 4.96 4.66 C6.59 4.38, 7.77 -1.36, 9.13 -1.3 C10.5 -1.24, 12.01 4.96, 13.17 5.02 C14.32 5.09, 14.66 -0.9, 16.07 -0.94 C17.47 -0.98, 20.52 3.91, 21.58 4.79" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(211.72650555384257 1123.0486153224965) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M-0.47 -0.28 C0.32 0.59, 3.13 4.77, 4.74 4.7 C6.35 4.64, 7.85 -0.51, 9.18 -0.64 C10.51 -0.77, 11.55 3.8, 12.74 3.93 C13.93 4.05, 14.76 -0.03, 16.3 0.12 C17.84 0.26, 21.03 4.06, 22 4.78 M0.29 0.77 C1.03 1.53, 3.03 4.03, 4.47 3.91 C5.91 3.78, 7.52 -0.05, 8.92 0 C10.31 0.05, 11.46 4.37, 12.81 4.19 C14.17 4, 15.64 -1.15, 17.02 -1.1 C18.4 -1.06, 20.18 3.65, 21.1 4.47" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(193.65667406721138 1122.9325846914435) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M0.31 0.33 C1.15 1.12, 3.16 4.72, 4.6 4.46 C6.04 4.21, 7.67 -1.27, 8.95 -1.2 C10.22 -1.12, 10.91 4.73, 12.27 4.92 C13.62 5.1, 15.45 -0.01, 17.09 -0.09 C18.72 -0.17, 21.27 3.76, 22.08 4.43 M-0.2 0.02 C0.63 0.93, 2.79 5.35, 4.25 5.21 C5.71 5.06, 7.25 -0.64, 8.56 -0.84 C9.87 -1.04, 10.77 3.84, 12.1 4.02 C13.43 4.2, 15.02 0.26, 16.54 0.25 C18.06 0.23, 20.25 3.19, 21.22 3.94" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(230.2943015132371 1122.2650050376951) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M0.16 0.08 C0.84 0.68, 2.98 3.96, 4.36 3.91 C5.75 3.86, 7.03 -0.34, 8.48 -0.21 C9.92 -0.07, 11.6 4.75, 13.05 4.71 C14.5 4.67, 15.68 -0.32, 17.17 -0.44 C18.65 -0.56, 21.2 3.2, 21.96 3.98 M-0.42 -0.35 C0.16 0.27, 2.24 4.48, 3.9 4.37 C5.55 4.26, 7.95 -0.9, 9.51 -1.01 C11.08 -1.12, 12.1 3.59, 13.29 3.71 C14.48 3.83, 15.37 -0.48, 16.67 -0.28 C17.96 -0.08, 20.16 4.01, 21.04 4.92" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(248.27421978555992 1122.1945642797073) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M-0.07 -0.47 C0.55 0.33, 2.34 4.89, 3.89 4.9 C5.45 4.91, 7.72 -0.32, 9.26 -0.41 C10.8 -0.5, 11.84 4.44, 13.14 4.36 C14.43 4.28, 15.62 -0.88, 17.05 -0.9 C18.48 -0.92, 20.99 3.38, 21.72 4.22 M-0.77 0.48 C0 1.13, 3.22 4.5, 4.85 4.2 C6.48 3.9, 7.61 -1.43, 9.04 -1.32 C10.47 -1.21, 12.17 4.78, 13.42 4.84 C14.66 4.9, 15 -1.05, 16.49 -0.97 C17.97 -0.9, 21.5 4.29, 22.34 5.28" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(284.50427771186503 1122.6450552612923) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M-0.54 0.52 C0.25 1.38, 3.03 4.91, 4.68 4.69 C6.33 4.48, 7.95 -0.63, 9.34 -0.77 C10.73 -0.9, 11.77 3.88, 13.02 3.9 C14.26 3.92, 15.41 -0.69, 16.81 -0.66 C18.21 -0.62, 20.63 3.21, 21.42 4.12 M0.18 0.31 C0.93 1.05, 2.88 3.97, 4.37 3.89 C5.87 3.8, 7.68 -0.23, 9.16 -0.18 C10.64 -0.14, 12.08 4.22, 13.24 4.15 C14.4 4.08, 14.68 -0.77, 16.12 -0.61 C17.56 -0.44, 20.96 4.31, 21.89 5.13" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(266.4344462252335 1123.032066997936) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M0.24 0.31 C1.13 0.95, 3.26 4.6, 4.76 4.34 C6.26 4.09, 7.89 -1.19, 9.22 -1.22 C10.56 -1.25, 11.56 4.07, 12.78 4.14 C13.99 4.22, 15.05 -0.86, 16.51 -0.75 C17.97 -0.65, 20.57 3.89, 21.53 4.79 M-0.29 0 C0.59 0.96, 2.95 5.17, 4.5 5.02 C6.04 4.88, 7.59 -0.79, 8.98 -0.88 C10.38 -0.96, 11.48 4.5, 12.87 4.52 C14.26 4.54, 15.8 -0.75, 17.33 -0.76 C18.86 -0.76, 21.43 3.66, 22.05 4.48" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(302.67812875224763 1122.300061650677) rotate(0 10.875622044046054 1.8719489958272106)"><path d="M-0.49 0.1 C0.19 0.76, 2.8 4.43, 4.36 4.33 C5.92 4.22, 7.46 -0.6, 8.86 -0.55 C10.25 -0.51, 11.35 4.52, 12.72 4.6 C14.09 4.68, 15.62 -0.09, 17.06 -0.06 C18.49 -0.03, 20.49 4.05, 21.34 4.79 M0.26 -0.32 C0.84 0.4, 2.53 5.2, 3.89 5 C5.25 4.8, 6.94 -1.56, 8.43 -1.53 C9.91 -1.49, 11.44 4.9, 12.79 5.21 C14.13 5.51, 15 0.42, 16.5 0.3 C18 0.18, 21.02 3.91, 21.77 4.48" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(320.65804702457046 1122.7747308263333) rotate(0 10.875622044045997 1.8719489958272106)"><path d="M-0.08 -0.05 C0.72 0.69, 2.78 4.63, 4.28 4.56 C5.78 4.48, 7.47 -0.56, 8.93 -0.52 C10.39 -0.49, 11.78 4.67, 13.03 4.74 C14.28 4.82, 14.9 -0.03, 16.43 -0.08 C17.95 -0.14, 21.24 3.68, 22.17 4.39 M-0.78 -0.56 C-0.03 0.01, 2.21 3.83, 3.76 3.68 C5.32 3.53, 6.95 -1.5, 8.54 -1.49 C10.12 -1.47, 11.8 3.47, 13.25 3.76 C14.7 4.05, 15.86 0.24, 17.21 0.26 C18.56 0.28, 20.49 3.07, 21.36 3.88" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(356.8881049508756 1123.0264510037396) rotate(179.39098195963928 10.875622044045997 1.8719489958272106)"><path d="M-0.16 0.18 C0.58 0.95, 2.78 4.67, 4.35 4.58 C5.91 4.49, 7.89 -0.4, 9.23 -0.38 C10.58 -0.36, 11.06 4.73, 12.4 4.72 C13.73 4.7, 15.65 -0.4, 17.26 -0.48 C18.86 -0.57, 21.27 3.44, 22.03 4.18 M0.76 -0.21 C1.43 0.4, 2.5 3.9, 3.87 3.72 C5.24 3.54, 7.59 -1.27, 9 -1.27 C10.4 -1.27, 11 3.56, 12.3 3.72 C13.6 3.87, 15.33 -0.6, 16.8 -0.35 C18.28 -0.1, 20.27 4.37, 21.14 5.23" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round"><g transform="translate(338.8182734642444 1123.1251335642578) rotate(179.39098195963928 10.875622044046054 1.8719489958272106)"><path d="M-0.09 0.2 C0.71 0.96, 3.2 4.83, 4.65 4.73 C6.1 4.62, 7.17 -0.34, 8.6 -0.41 C10.03 -0.48, 11.81 4.36, 13.23 4.32 C14.64 4.27, 15.69 -0.64, 17.12 -0.69 C18.54 -0.75, 21.03 3.09, 21.77 3.99 M-0.8 -0.17 C-0.03 0.42, 2.58 4.13, 4.33 3.94 C6.08 3.75, 8.17 -1.45, 9.71 -1.31 C11.25 -1.17, 12.41 4.67, 13.55 4.78 C14.7 4.88, 15.11 -0.69, 16.59 -0.66 C18.06 -0.64, 21.56 4.12, 22.42 4.93" stroke="#fab005" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round" transform="translate(86.16203204724468 804.2740687105547) rotate(0 448.5219508046551 174.28500452423054)"><path d="M32 0 C351.79 3.61, 670.37 4.07, 865.04 0 M32 0 C264.12 0.05, 497.17 -0.3, 865.04 0 M865.04 0 C887.9 1.3, 896 12.03, 897.04 32 M865.04 0 C886.5 -0.3, 894.88 8.63, 897.04 32 M897.04 32 C897.48 97.41, 896.15 162.77, 897.04 316.57 M897.04 32 C897.07 92.06, 898.22 151.82, 897.04 316.57 M897.04 316.57 C897.58 336.71, 885.78 349.31, 865.04 348.57 M897.04 316.57 C895.85 339.4, 886.2 349.25, 865.04 348.57 M865.04 348.57 C629.97 345.86, 394.81 345.06, 32 348.57 M865.04 348.57 C550.26 351.01, 235.39 351.14, 32 348.57 M32 348.57 C12.01 348.62, -1.4 339.54, 0 316.57 M32 348.57 C9.95 348.14, 1.47 336.58, 0 316.57 M0 316.57 C1.5 240.72, 0.39 162.93, 0 32 M0 316.57 C-2.39 251.36, -1.66 184.74, 0 32 M0 32 C-1.31 10.19, 12.61 -0.29, 32 0 M0 32 C2.12 9.49, 8.94 1.64, 32 0" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g><g stroke-linecap="round"><g transform="translate(133.52793683734149 806.7575385411618) rotate(0 -5.684341886080802e-14 172.8749189001423)"><path d="M0.47 0.38 C0.86 57.78, 1.3 287.92, 1.16 345.5 M-0.74 -0.46 C-0.3 57.64, 0.92 288.95, 0.82 346.9" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(67.32218829724457 970.1031840213891) rotate(270 41.015625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">stage-b</text></g><g transform="translate(96.36391449189273 760.7606572486847) rotate(0 345.703125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">FROM --platform=$BUILDPLATFORM alpine:${VERSION} as stage-b</text></g><g stroke-linecap="round" transform="translate(90.36051876314593 305.3363422867699) rotate(0 450.0057524190432 185.89722333765815)"><path d="M32 0 C253.07 3.22, 475.72 3.73, 868.01 0 M32 0 C233.37 1.81, 434.09 1.91, 868.01 0 M868.01 0 C887.69 -1.83, 901.11 9.33, 900.01 32 M868.01 0 C890.95 0.42, 900.56 8.62, 900.01 32 M900.01 32 C899.04 106.43, 897.5 182.87, 900.01 339.79 M900.01 32 C900.22 153.56, 899.21 274.98, 900.01 339.79 M900.01 339.79 C901.08 362.67, 891.34 372.8, 868.01 371.79 M900.01 339.79 C899.93 360.28, 891.52 371.48, 868.01 371.79 M868.01 371.79 C546.1 368.69, 225.94 369.31, 32 371.79 M868.01 371.79 C547.75 370.12, 226.36 370.2, 32 371.79 M32 371.79 C11.81 373.14, 1.09 359.41, 0 339.79 M32 371.79 C12.32 372.28, 1.7 362.47, 0 339.79 M0 339.79 C1.67 267.75, 2.33 193.59, 0 32 M0 339.79 C-0.74 227.48, -0.24 115.43, 0 32 M0 32 C0.1 8.85, 11.2 -1.29, 32 0 M0 32 C0.24 10.87, 11.99 -0.62, 32 0" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g><g stroke-linecap="round"><g transform="translate(137.72642355324274 304.9262584799999) rotate(0 0 185.052722866983)"><path d="M0.02 0.26 C0.34 62, 0.8 307.84, 0.78 369.39 M-1.44 -0.65 C-1.1 61.32, 0.15 308.68, 0.24 370.55" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(72.28855765490334 484.2163361370194) rotate(270 41.015625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">stage-a</text></g><g transform="translate(95.722270550536 232.87221790524399) rotate(0 410.15625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># FROM-lines belong to the global scope and have access to global ARGs</text></g><g transform="translate(97.23013381272517 266.4822695378388) rotate(0 193.359375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">FROM alpine:${VERSION} as stage-a</text></g><g transform="translate(160.8094110936372 327.94112834784005) rotate(0 398.4375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Redeclaring GLOBAL_ARG without a value inherits the global default</text></g><g transform="translate(162.2978888321311 359.7027312066824) rotate(0 82.03125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ARG GLOBAL_ARG</text></g><g transform="translate(162.1833846676236 637.7797382867685) rotate(0 117.1875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $GLOBAL_ARG</text></g><g transform="translate(158.27871581681643 401.0411395379771) rotate(0 269.53125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># ARG here this scope creates a local argument</text></g><g transform="translate(160.17975748348294 433.10133271660504) rotate(0 210.9375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ARG LOCAL_ARG="local arg in stage-a"</text></g><g transform="translate(158.27871581681643 480.5488444213912) rotate(0 251.953125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Set an environment variable in this scope</text></g><g transform="translate(160.17975748348294 510.61994138181205) rotate(0 105.46875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ENV LOCAL_ENV=true</text></g><g transform="translate(158.27871581681643 551.2419656604121) rotate(0 363.28125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Set an environment variable to the value of a build argument</text></g><g transform="translate(158.66387367202674 583.326220486841) rotate(0 123.046875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ENV MY_VAR=$LOCAL_ARG</text></g><g stroke-linecap="round" transform="translate(91.87640257460168 1257.5483255258505) rotate(0 448.0768103203382 70.16871796463431)"><path d="M32 0 C344.86 1.25, 658.48 1.05, 864.15 0 M32 0 C232.76 2.32, 432.6 2.49, 864.15 0 M864.15 0 C886.73 -0.64, 894.99 11.08, 896.15 32 M864.15 0 C886.02 -0.23, 894.74 12.71, 896.15 32 M896.15 32 C896.74 54.19, 897.02 79.1, 896.15 108.34 M896.15 32 C897.59 59.95, 897.41 88.43, 896.15 108.34 M896.15 108.34 C897.72 130.08, 886.87 141.58, 864.15 140.34 M896.15 108.34 C895.98 128.64, 884.2 139.44, 864.15 140.34 M864.15 140.34 C543.22 139.74, 222.44 139.76, 32 140.34 M864.15 140.34 C558.29 138.23, 252.73 137.75, 32 140.34 M32 140.34 C8.78 138.64, 0.05 130.79, 0 108.34 M32 140.34 C12.59 142.62, 0.77 130.37, 0 108.34 M0 108.34 C1.79 89.03, -0.96 66.8, 0 32 M0 108.34 C1.15 89.79, 0.15 70.96, 0 32 M0 32 C-0.58 11.54, 10.17 0.01, 32 0 M0 32 C-2.02 11.84, 10.18 -0.43, 32 0" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g><g stroke-linecap="round"><g transform="translate(139.2423073646985 1257.6246950342768) rotate(0 0 70.4404739371115)"><path d="M0.77 -1.18 C0.89 22.37, 0.55 116.65, 0.47 140.17 M-0.29 0.81 C-0.26 24.61, -0.22 118, -0.23 141.34" stroke="#1e1e1e" stroke-width="2" fill="none"></path></g></g><mask></mask><g transform="translate(73.03655882460157 1316.7954582743134) rotate(270 41.015625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">stage-c</text></g><g transform="translate(96.22756515435458 1188.2407683246124) rotate(0 175.78125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># New stage based on "stage-a"</text></g><g transform="translate(97.23815436199197 1221.8508199572072) rotate(0 134.765625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">FROM stage-a AS stage-c</text></g><g transform="translate(161.30668514818876 1280.7546527819427) rotate(0 339.84375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Arguments and variables are inherited from parent stages</text></g><g transform="translate(160.17975748348272 1320.0639886026324) rotate(0 111.328125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $LOCAL_ARG</text></g><g transform="translate(160.68505208730153 1353.798418819483) rotate(0 111.328125 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $LOCAL_ENV</text></g><g transform="translate(459.51762903653366 1001.2272136084616) rotate(0 152.34375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints an empty string</text></g><g transform="translate(459.51762903653366 1094.562345428122) rotate(0 152.34375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints an empty string</text></g><g transform="translate(455.0599700089376 634.5587543162438) rotate(0 187.5 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints "global default value"</text></g><g transform="translate(459.7763686520491 1318.926103708041) rotate(0 187.5 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints "local arg in stage-a"</text></g><g transform="translate(459.7763686520491 1352.6765750234256) rotate(0 93.75 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints "true"</text></g><g transform="translate(157.31376429739407 868.3488129535199) rotate(0 105.46875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">ARG TARGETPLATFORM</text></g><g transform="translate(154.5346844690887 828.9977562693839) rotate(0 380.859375 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># You must redeclare pre-defined arguments to use them in a stage</text></g><g transform="translate(157.73636020851723 901.372882634279) rotate(0 140.625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#1e1e1e" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">RUN echo $TARGETPLATFORM</text></g><g transform="translate(456.6373611167471 901.4832955042493) rotate(0 228.515625 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge">&lt;- prints os/arch/variant of --platform</text></g><g stroke-linecap="round"><g transform="translate(535.1414722881311 675.2569609220587) rotate(0 250.3253528965804 288.4689111292416)"><path d="M0 0 C-1.43 6.83, -0.07 11.69, -0.4 26.76 M-0.4 26.76 C139.78 27.72, 280.08 28.44, 512.12 29.99 M512.12 29.99 C514.55 160.21, 515.61 291.93, 516.83 530.58 M516.83 530.58 C375.82 532.42, 234.27 532.95, -14.18 533.72 M-14.18 533.72 C-15.62 549.61, -16.91 564.02, -16.18 576.94" stroke="#1e1e1e" stroke-width="2.5" fill="none" stroke-dasharray="8 10"></path></g></g><mask></mask><g transform="translate(97.67451560383006 726.2688100539343) rotate(0 404.296875 12)"><text x="0" y="0" font-family="monospace" font-size="20px" fill="#868e96" text-anchor="start" style="white-space: pre;" direction="ltr" dominant-baseline="text-before-edge"># Pre-defined multi-platform arguments like $BUILDPLATFORM are global</text></g></svg>
diff --git a/content/manuals/build/metadata/annotations.md b/content/manuals/build/metadata/annotations.md
index 910ce96f9d31..ee1f44a488f0 100644
--- a/content/manuals/build/metadata/annotations.md
+++ b/content/manuals/build/metadata/annotations.md
@@ -6,12 +6,14 @@ aliases:
 - /build/building/annotations/
 ---
 
+<!-- vale Docker.Spacing = NO -->
+
 Annotations provide descriptive metadata for images. Use annotations to record
 arbitrary information and attach it to your image, which helps consumers and
 tools understand the origin, contents, and how to use the image.
 
 Annotations are similar to, and in some sense overlap with, [labels]. Both
-serve the same purpose: attach metadata to a resource. As a general principle,
+serve the same purpose: to attach metadata to a resource. As a general principle,
 you can think of the difference between annotations and labels as follows:
 
 - Annotations describe OCI image components, such as [manifests], [indexes],
@@ -39,7 +41,7 @@ You can add annotations to an image at build-time, or when creating the image
 manifest or index.
 
 > [!NOTE]
-> 
+>
 > The Docker Engine image store doesn't support loading images with
 > annotations. To build with annotations, make sure to push the image directly
 > to a registry, using the `--push` CLI flag or the
@@ -68,7 +70,7 @@ For examples on how to add annotations to images built with GitHub Actions, see
 You can also add annotations to an image created using `docker buildx
 imagetools create`. This command only supports adding annotations to an index
 or manifest descriptors, see
-[CLI reference](/reference/cli/docker/buildx/imagetools/create.md#annotations).
+[CLI reference](/reference/cli/docker/buildx/imagetools/create/#annotation).
 
 ## Inspect annotations
 
@@ -202,9 +204,9 @@ Related articles:
 
 Reference information:
 
-- [`docker buildx build --annotation`](/reference/cli/docker/buildx/build.md#annotation)
+- [`docker buildx build --annotation`](/reference/cli/docker/buildx/build/#annotation)
 - [Bake file reference: `annotations`](/manuals/build/bake/reference.md#targetannotations)
-- [`docker buildx imagetools create --annotation`](/reference/cli/docker/buildx/imagetools/create.md#annotation)
+- [`docker buildx imagetools create --annotation`](/reference/cli/docker/buildx/imagetools/create/#annotation)
 
 <!-- links -->
 
diff --git a/content/manuals/build/metadata/attestations/_index.md b/content/manuals/build/metadata/attestations/_index.md
index e18977bf4679..7190094ad88e 100644
--- a/content/manuals/build/metadata/attestations/_index.md
+++ b/content/manuals/build/metadata/attestations/_index.md
@@ -20,7 +20,7 @@ you to make informed decisions about how an image impacts the supply chain secur
 of your application. It also enables the use of policy engines for validating
 images based on policy rules you've defined.
 
-Two types of build annotations are available:
+Two types of build attestations are available:
 
 - Software Bill of Material (SBOM): list of software artifacts that an image
   contains, or that were used to build the image.
@@ -43,39 +43,60 @@ to see if images you are already using are exposed to vulnerabilities.
 
 ## Creating attestations
 
-When you build an image with `docker buildx build`, you can add attestation
-records to the resulting image using the `--provenance` and `--sbom` options.
-You can opt in to add either the SBOM or provenance attestation type, or both.
+BuildKit generates the attestations when building the image. Provenance
+attestations with the `mode=min` level are added to images by default. The
+attestation records are wrapped in the in-toto JSON format and attached to the
+image index in a manifest for the final image.
+
+You can customize attestation behavior using the `--provenance` and `--sbom`
+flags:
+
+```bash
+# Opt in to SBOM attestations:
+docker buildx build --sbom=true .
+# Opt in to max-level provenance attestations:
+docker buildx build --provenance=mode=max .
+# Opt out of provenance attestations:
+docker buildx build --provenance=false .
+```
+
+You can also disable default provenance attestations by setting the
+[`BUILDX_NO_DEFAULT_ATTESTATIONS`](/manuals/build/building/variables.md#buildx_no_default_attestations)
+environment variable. See [Provenance attestation](./slsa-provenance.md) for
+more details about provenance modes and options.
+
+### Driver and image store support
+
+Attestations attach to an image index. The classic image store doesn't support
+image indices, so it can't hold an image with attestations.
 
-```console
-$ docker buildx build --sbom=true --provenance=true .
+The default `docker` driver builds with the BuildKit library bundled into the
+Docker daemon, and writes the result to the daemon's image store. If the daemon
+still uses the classic image store, the build fails:
+
+```text
+ERROR: failed to build: Attestation is not supported for the docker driver.
+Switch to a different driver, or turn on the containerd image store, and try again.
 ```
 
-> [!NOTE]
->
-> The default image store doesn't support attestations. If you're using the
-> default image store and you build an image using the default `docker` driver,
-> or using a different driver with the `--load` flag, the attestations are
-> lost.
->
-> To make sure the attestations are preserved, you can:
->
-> - Use a `docker-container` driver with the `--push` flag to push the image to
->   a registry directly.
-> - Enable the [containerd image store](/manuals/desktop/features/containerd.md).
-
-> [!NOTE]
->
-> Provenance attestations are enabled by default, with the `mode=min` option.
-> You can disable provenance attestations using the `--provenance=false` flag,
-> or by setting the [`BUILDX_NO_DEFAULT_ATTESTATIONS`](/manuals/build/building/variables.md#buildx_no_default_attestations) environment variable.
->
-> Using the `--provenance=true` flag attaches provenance attestations with `mode=max`
-> by default. See [Provenance attestation](./slsa-provenance.md) for more details.
-
-BuildKit generates the attestations when building the image. The attestation
-records are wrapped in the in-toto JSON format and attached to the image
-index in a manifest for the final image.
+To build attestations with the `docker` driver, turn on the containerd image
+store. See [containerd image store with Docker Desktop](/manuals/desktop/features/containerd.md)
+or [containerd image store with Docker Engine](/manuals/engine/storage/containerd.md).
+
+| Driver                    | Attestation support                 |
+| :------------------------ | :---------------------------------- |
+| `docker`                  | Requires the containerd image store |
+| `docker-container`        | Supported                           |
+| `kubernetes` and `remote` | Supported                           |
+
+The `docker-container`, `kubernetes`, and `remote` drivers run BuildKit outside
+the Docker daemon, so they build attestations regardless of which image store
+the daemon uses. Pushing the result to a registry with `--push` keeps the
+attestations. If you load the result into the daemon with `--load` instead, the
+same image store requirement applies.
+
+If you don't want to switch image stores or drivers, opt out of attestations
+with `--provenance=false --sbom=false`.
 
 ## Storage
 
diff --git a/content/manuals/build/metadata/attestations/sbom.md b/content/manuals/build/metadata/attestations/sbom.md
index ffbd5354317d..8a9a99d62a17 100644
--- a/content/manuals/build/metadata/attestations/sbom.md
+++ b/content/manuals/build/metadata/attestations/sbom.md
@@ -2,15 +2,12 @@
 title: SBOM attestations
 keywords: build, attestations, sbom, spdx, metadata, packages
 description: |
-  SBOM build attestations describe the contents of your image,
-  and the packages used to build it.
+  SBOM attestations describe what software artifacts an image contains and the artifacts used to create the image.
 aliases:
   - /build/attestations/sbom/
 ---
 
-Software Bill of Materials (SBOM) attestations describe what software artifacts
-an image contains, and artifacts used to create the image. Metadata included in
-an SBOM for describing software artifacts may include:
+SBOM attestations help ensure [software supply chain transparency](/guides/docker-scout/) by verifying the software artifacts an image contains and the artifacts used to create the image. Metadata included in an [SBOM](/guides/docker-scout/) for describing software artifacts may include:
 
 - Name of the artifact
 - Version
@@ -18,14 +15,9 @@ an SBOM for describing software artifacts may include:
 - Authors
 - Unique package identifier
 
-There are benefits to indexing contents of an image during the build, as opposed
-to scanning a final image. When scanning happens as part of the build, you're
-able to detect software you use to build the image, that may not show up in the
-final image.
+Indexing the contents of an image during the build has benefits over scanning a final image. When scanning happens as part of the build, you can detect software you used to build the image, which may not show up in the final image.
 
-The SBOMs generated by BuildKit follow the SPDX standard. SBOMs attach to the
-final image as a JSON-encoded SPDX document, using the format defined by the
-[in-toto SPDX predicate](https://github.com/in-toto/attestation/blob/main/spec/predicates/spdx.md).
+Docker supports SBOM generation and attestation through an SLSA-compliant build process using BuildKit and attestations. The SBOMs generated by [BuildKit](/manuals/build/buildkit/_index.md) follow the SPDX standard and attach to the final image as a JSON-encoded SPDX document, using the format defined by the [in-toto SPDX predicate](https://github.com/in-toto/attestation/blob/main/spec/predicates/spdx.md). On this page, you’ll learn how to create, manage, and verify SBOM attestations using Docker tooling.
 
 ## Create SBOM attestations
 
@@ -175,7 +167,7 @@ sbom.spdx.json
 ## Inspecting SBOMs
 
 To explore created SBOMs exported through the `image` exporter, you can use
-[`imagetools inspect`](/reference/cli/docker/buildx/imagetools/inspect.md).
+[`imagetools inspect`](/reference/cli/docker/buildx/imagetools/inspect/).
 
 Using the `--format` option, you can specify a template for the output. All
 SBOM-related data is available under the `.SBOM` attribute. For example, to get
@@ -210,7 +202,7 @@ base-passwd@3.5.47
 
 ## SBOM generator
 
-BuildKit generates the SBOM using a scanner plugin. By default, it uses is the
+BuildKit generates the SBOM using a scanner plugin. By default, it uses the
 [BuildKit Syft scanner](https://github.com/docker/buildkit-syft-scanner)
 plugin. This plugin is built on top of
 [Anchore's Syft](https://github.com/anchore/syft),
diff --git a/content/manuals/build/metadata/attestations/slsa-provenance.md b/content/manuals/build/metadata/attestations/slsa-provenance.md
index f3add2da14d6..54e00c78933a 100644
--- a/content/manuals/build/metadata/attestations/slsa-provenance.md
+++ b/content/manuals/build/metadata/attestations/slsa-provenance.md
@@ -16,8 +16,10 @@ details such as:
 - Source code details
 - Materials (files, scripts) consumed during the build
 
-Provenance attestations follow the
-[SLSA provenance schema, version 0.2](https://slsa.dev/provenance/v0.2#schema).
+By default, provenance attestations follow the
+[SLSA provenance schema, version 0.2](https://slsa.dev/spec/v0.2/provenance#schema).
+You can optionally enable [SLSA Provenance v1](https://slsa.dev/spec/v1.1/provenance#schema)
+using [the `version` parameter](#version).
 
 For more information about how BuildKit populates these provenance properties, refer to
 [SLSA definitions](slsa-definitions.md).
@@ -29,11 +31,12 @@ to the `docker buildx build` command:
 
 ```console
 $ docker buildx build --tag <namespace>/<image>:<version> \
-    --attest type=provenance,mode=[min,max] .
+    --attest type=provenance,mode=[min,max],version=[v0.2,v1] .
 ```
 
 Alternatively, you can use the shorthand `--provenance=true` option instead of `--attest type=provenance`.
-To specify the `mode` parameter using the shorthand option, use: `--provenance=mode=max`.
+To specify the `mode` or `version` parameters using the shorthand option, use:
+`--provenance=mode=max,version=v1`.
 
 For an example on how to add provenance attestations with GitHub Actions, see
 [Add attestations with GitHub Actions](/manuals/build/ci/github-actions/attestations.md).
@@ -41,8 +44,8 @@ For an example on how to add provenance attestations with GitHub Actions, see
 ## Mode
 
 You can use the `mode` parameter to define the level of detail to be included in
-the provenance attestation. Supported values are `mode=min`, and `mode=max`
-(default).
+the provenance attestation. Supported values are `mode=min` (default) and
+`mode=max`.
 
 ### Min
 
@@ -56,8 +59,8 @@ such as:
 - Build platform
 - Reproducibility
 
-Values of build arguments, the identities of secrets, and rich layer metadata is
-not included `mode=min`. The `min`-level provenance is safe to use for all
+Values of build arguments, the identities of secrets, and rich layer metadata are
+not included in `mode=min`. The `min`-level provenance is safe to use for all
 builds, as it doesn't leak information from any part of the build environment.
 
 The following JSON example shows the information included in a provenance
@@ -143,17 +146,34 @@ detailed information for analysis.
 > [!WARNING]
 >
 > Note that `mode=max` exposes the values of
-> [build arguments](/reference/cli/docker/buildx/build.md#build-arg).
+> [build arguments](/reference/cli/docker/buildx/build/#build-arg).
 >
 > If you're misusing build arguments to pass credentials, authentication
 > tokens, or other secrets, you should refactor your build to pass the secrets using
-> [secret mounts](/reference/cli/docker/buildx/build.md#secret) instead.
+> [secret mounts](/reference/cli/docker/buildx/build/#secret) instead.
 > Secret mounts don't leak outside of the build and are never included in provenance attestations.
 
+## Version
+
+The `version` parameter lets you specify which SLSA provenance schema version
+to use. Supported values are `version=v0.2` (default) and `version=v1`.
+
+To use SLSA Provenance v1:
+
+```console
+$ docker buildx build --tag <namespace>/<image>:<version> \
+    --attest type=provenance,mode=max,version=v1 .
+```
+
+For more information about SLSA Provenance v1, see the
+[SLSA specification](https://slsa.dev/spec/v1.1/provenance). To see the
+difference between SLSA v0.2 and v1 provenance attestations, refer to
+[SLSA definitions](./slsa-definitions.md)
+
 ## Inspecting Provenance
 
 To explore created Provenance exported through the `image` exporter, you can
-use [`imagetools inspect`](/reference/cli/docker/buildx/imagetools/inspect.md).
+use [`imagetools inspect`](/reference/cli/docker/buildx/imagetools/inspect/).
 
 Using the `--format` option, you can specify a template for the output. All
 provenance-related data is available under the `.Provenance` attribute. For
@@ -175,7 +195,7 @@ extract the full source code of the Dockerfile used to build the image:
 ```console
 $ docker buildx imagetools inspect <namespace>/<image>:<version> \
     --format '{{ range (index .Provenance.SLSA.metadata "https://mobyproject.org/buildkit@v1#metadata").source.infos }}{{ if eq .filename "Dockerfile" }}{{ .data }}{{ end }}{{ end }}' | base64 -d
-FROM ubuntu:20.04
+FROM ubuntu:24.04
 RUN apt-get update
 ...
 ```
diff --git a/content/manuals/build/policies/_index.md b/content/manuals/build/policies/_index.md
new file mode 100644
index 000000000000..5079a8e736f2
--- /dev/null
+++ b/content/manuals/build/policies/_index.md
@@ -0,0 +1,167 @@
+---
+title: Validating build inputs with policies
+linkTitle: Validating builds
+description: Secure your Docker builds by validating images, Git repositories, and dependencies with build policies
+keywords: build policies, opa, rego, docker security, supply chain, attestations
+weight: 70
+params:
+  sidebar:
+    badge:
+      color: blue
+      text: Experimental
+---
+
+Building with Docker often involves downloading remote resources. These
+external dependencies, such as Docker images, Git repositories, remote files,
+and other artifacts, are called build inputs.
+
+For example:
+
+- Pulling images from a registry
+- Cloning a source code repository
+- Fetching files from a server over HTTPS
+
+When consuming build inputs, it's a good idea to verify the contents are what
+you expect them to be. One way to do this is to use the `--checksum` option for
+the `ADD` Dockerfile instruction. This lets you verify the SHA256 checksum of a
+remote resource when pulling it into a build:
+
+```dockerfile
+ADD --checksum=sha256:c0ff3312345… https://example.com/archive.tar.gz /
+```
+
+If the remote `archive.tar.gz` file does not match the checksum that the
+Dockerfile expects, the build fails.
+
+Checksums verify that content matches what you expect, but only for the `ADD`
+instruction. They don't tell you anything about where the content came from or
+how it was produced. You can't use checksums to enforce constraints like
+"images must be signed" or "dependencies must come from approved sources."
+
+Build policies solve this problem. They let you define rules that validate all
+your build inputs, enforcing requirements like provenance attestations,
+approved registries, and signed Git tags across your entire build process.
+
+## Prerequisites
+
+Build policies is currently an experimental feature. To try it out, you'll
+need:
+
+- Buildx 0.31.0 or later - Check your version: `docker buildx version`
+- BuildKit 0.27.0 or later - Verify with: `docker buildx inspect --bootstrap`
+
+If you're using Docker Desktop, ensure you're on a version that includes these
+updates.
+
+## Build policies
+
+Buildx version 0.31.0 added support for build policies. Build policies are
+rules for securing your Docker build supply chain, and help protect against
+upstream compromises, malicious dependencies, and unauthorized modifications to
+your build inputs.
+
+Build policies let you enforce extended verifications on inputs used to build
+your projects, such as:
+
+- Docker images must use digest references (not tags alone)
+- Images must have provenance attestations and cosign signatures
+- Git tags are signed by maintainers with a PGP public key
+- All remote artifacts must use HTTPS and include a checksum for verification
+
+Build policies are defined in a declarative policy language, called Rego,
+created for the [Open Policy Agent (OPA)](https://www.openpolicyagent.org/).
+The following example shows a minimal build policy in Rego.
+
+```rego {title="Dockerfile.rego"}
+package docker
+
+default allow := false
+
+# Allow any local inputs for this build
+# For example: a local build context, or a local Dockerfile
+allow if input.local
+
+# Allow images, but only if they have provenance attestations
+allow if {
+    input.image.hasProvenance
+}
+
+decision := {"allow": allow}
+```
+
+If the Dockerfile associated with this policy references an image with no
+provenance attestation in a `FROM` instruction, the policy would be violated
+and the build would fail.
+
+## How policies work
+
+When you run `docker buildx build`, Buildx:
+
+1. Resolves all build inputs (images, Git repos, HTTP downloads)
+2. Looks for a policy file matching your Dockerfile name (e.g.,
+   `Dockerfile.rego`)
+3. Evaluates each input against the policy before the build starts
+4. Allows the build to proceed only if all inputs pass the policy
+
+Policies are written in Rego (Open Policy Agent's policy language). You don't
+need to be a Rego expert - the [Introduction](./intro.md) tutorial teaches you
+everything needed.
+
+Policy files live alongside your Dockerfile:
+
+```text
+project/
+├── Dockerfile
+├── Dockerfile.rego
+└── src/
+```
+
+No additional configuration is needed - Buildx automatically finds and loads
+the policy when you build.
+
+## Use cases
+
+Build policies help you enforce security and compliance requirements on your
+Docker builds. Common scenarios where policies provide value:
+
+### Enforce base image standards
+
+Require all production Dockerfiles to use specific, approved base images with
+digest references. Prevent developers from using arbitrary images that haven't
+been vetted by your security team.
+
+### Validate third-party dependencies
+
+When your build downloads files, libraries, or tools from the internet, verify
+they come from trusted sources and match expected checksums or signatures. This
+protects against supply chain attacks where an upstream dependency is
+compromised.
+
+### Ensure signed releases
+
+Require that all dependencies have valid signatures from trusted parties.
+
+- Check GPG signatures for Git repositories you clone in your builds
+- Verify provenance attestation signatures with Sigstore
+
+### Meet compliance requirements
+
+Some regulatory frameworks require evidence that you validate your build
+inputs. Build policies give you an auditable, declarative way to demonstrate
+you're checking dependencies against security standards.
+
+### Separate development and production rules
+
+Apply stricter validation for production builds while allowing more flexibility
+during development. The same policy file can contain conditional rules based on
+build context or target.
+
+## Get started
+
+Ready to start writing policies? The [Introduction](./intro.md) tutorial walks
+you through creating your first policy and teaches the Rego basics you need.
+
+For practical usage guidance, see [Using build policies](./usage.md).
+
+For practical examples you can copy and adapt, see the [Example
+policies](./examples.md) library.
diff --git a/content/manuals/build/policies/built-ins.md b/content/manuals/build/policies/built-ins.md
new file mode 100644
index 000000000000..310b25c92b74
--- /dev/null
+++ b/content/manuals/build/policies/built-ins.md
@@ -0,0 +1,205 @@
+---
+title: Built-in functions
+linkTitle: Built-in functions
+description: Buildx includes built-in helper functions to make writing policies easier
+keywords: build policies, built-in functions, rego functions, signature verification, policy helpers
+weight: 90
+---
+
+Buildx provides built-in functions, in addition to the [Rego
+built-ins](#rego-built-in-functions), to extend Rego policies with
+Docker-specific operations like loading local files, verifying Git signatures,
+and pinning image digests.
+
+## Rego built-in functions
+
+The functions [documented on this page](#buildx-built-in-functions) are
+Buildx-specific functions, distinct from [Rego's standard built-in
+functions](https://www.openpolicyagent.org/docs/policy-language#built-in-functions)
+
+Buildx also supports standard Rego built-in functions, but only a subset. To
+see the exact list of supported functions, refer to the Buildx [source
+code](https://github.com/docker/buildx/blob/master/policy/builtins.go).
+
+## Buildx built-in functions
+
+Buildx provides the following custom built-in functions for policy development:
+
+- [`print`](#print)
+- [`load_json`](#load_json)
+- [`verify_git_signature`](#verify_git_signature)
+- [`pin_image`](#pin_image)
+
+### `print`
+
+Outputs debug information during policy evaluation.
+
+Parameters:
+
+- Any number of values to print
+
+Returns: The values (pass-through)
+
+Example:
+
+```rego
+allow if {
+    input.image.repo == "alpine"
+    print("Allowing alpine image:", input.image.tag)
+}
+```
+
+Debug output appears when building with `--progress=plain`.
+
+### `load_json`
+
+Loads and parses JSON data from local files in the build context.
+
+Parameters:
+
+- `filename` (string) - Path to JSON file relative to policy directory
+
+Returns: Parsed JSON data as Rego value
+
+Example:
+
+```rego
+# Load approved versions from external file
+approved_versions = load_json("versions.json")
+
+allow if {
+    input.image.repo == "alpine"
+    some version in approved_versions.alpine
+    input.image.tag == version
+}
+```
+
+File structure:
+
+```text
+project/
+├── Dockerfile
+├── Dockerfile.rego
+└── versions.json
+```
+
+versions.json:
+
+```json
+{
+  "alpine": ["3.19", "3.20"],
+  "golang": ["1.21", "1.22"]
+}
+```
+
+The JSON file must be in the same directory as the policy or in a
+subdirectory accessible from the policy location.
+
+### `verify_git_signature`
+
+Verifies PGP signatures on Git commits or tags.
+
+Parameters:
+
+- `git_object` (object) - Either `input.git.commit` or `input.git.tag`
+- `keyfile` (string) - Path to PGP public key file (relative to policy
+  directory)
+
+Returns: Boolean - `true` if signature is valid, `false` otherwise
+
+Example:
+
+```rego
+# Require signed Git tags
+allow if {
+    input.git.tagName != ""
+    verify_git_signature(input.git.tag, "maintainer.asc")
+}
+
+# Require signed commits
+allow if {
+    input.git.commit
+    verify_git_signature(input.git.commit, "keys/team.asc")
+}
+```
+
+Directory structure:
+
+```text
+project/
+├── Dockerfile.rego
+└── maintainer.asc          # PGP public key
+```
+
+Or with subdirectory:
+
+```text
+project/
+├── Dockerfile.rego
+└── keys/
+    ├── maintainer.asc
+    └── team.asc
+```
+
+Obtaining public keys:
+
+```console
+$ gpg --export --armor user@example.com > maintainer.asc
+```
+
+### `pin_image`
+
+Pins an image to a specific digest, overriding the tag-based reference. Use
+this to force builds to use specific image versions.
+
+Parameters:
+
+- `image_object` (object) - Must be `input.image` (the current image being
+  evaluated)
+- `digest` (string) - Target digest in format `sha256:...`
+
+Returns: Boolean - `true` if pinning succeeds
+
+Example:
+
+```rego
+# Pin alpine 3.19 to specific digest
+alpine_3_19_digest = "sha256:4b7ce07002c69e8f3d704a9c5d6fd3053be500b7f1c69fc0d80990c2ad8dd412"
+
+allow if {
+    input.image.repo == "alpine"
+    input.image.tag == "3.19"
+    pin_image(input.image, alpine_3_19_digest)
+}
+```
+
+Automatic digest replacement:
+
+```rego
+# Replace old digests with patched versions
+replace_map = {
+  "3.22.0": "3.22.2",
+  "3.22.1": "3.22.2",
+}
+
+alpine_digests = {
+  "3.22.0": "sha256:8a1f59ffb675680d47db6337b49d22281a139e9d709335b492be023728e11715",
+  "3.22.2": "sha256:4b7ce07002c69e8f3d704a9c5d6fd3053be500b7f1c69fc0d80990c2ad8dd412",
+}
+
+allow if {
+    input.image.repo == "alpine"
+    some old_version, new_version in replace_map
+    input.image.checksum == alpine_digests[old_version]
+    print("Replacing", old_version, "with", new_version)
+    pin_image(input.image, alpine_digests[new_version])
+}
+```
+
+This pattern automatically upgrades old image versions to patched releases.
+
+## Next steps
+
+- Browse complete examples: [Example policies](./examples.md)
+- Learn policy development workflow: [Using build policies](./usage.md)
+- Reference input fields: [Input reference](./inputs.md)
diff --git a/content/manuals/build/policies/debugging.md b/content/manuals/build/policies/debugging.md
new file mode 100644
index 000000000000..16253a40d88b
--- /dev/null
+++ b/content/manuals/build/policies/debugging.md
@@ -0,0 +1,188 @@
+---
+title: Debugging build policies
+linkTitle: Debugging
+description: Debug policies during development with inspection and testing tools
+keywords: build policies, debugging, policy troubleshooting, log-level, policy eval, rego debugging
+weight: 70
+---
+
+When policies don't work as expected, use the tools available to inspect policy
+evaluation and understand what's happening. This guide covers the debugging
+techniques and common gotchas.
+
+## Quick reference
+
+Essential debugging commands:
+
+```console
+# See complete input data during builds (recommended)
+$ docker buildx build --progress=plain --policy log-level=debug .
+
+# See policy checks and decisions
+$ docker buildx build --progress=plain .
+
+# Explore input structure for different sources
+$ docker buildx policy eval --print .
+$ docker buildx policy eval --print https://github.com/org/repo.git
+$ docker buildx policy eval --print docker-image://alpine:3.19
+
+# Test if policy allows a source
+$ docker buildx policy eval .
+```
+
+## Policy output with `--progress=plain`
+
+To see policy evaluation during builds, use `--progress=plain`:
+
+```console
+$ docker buildx build --progress=plain .
+```
+
+This shows all policy checks, decisions, and `print()` output. Without
+`--progress=plain`, policy evaluation is silent unless there's an error.
+
+```plaintext
+#1 loading policies Dockerfile.rego
+#1 0.010 checking policy for source docker-image://alpine:3.19 (linux/arm64)
+#1 0.011 Dockerfile.rego:8: image: {"ref":"alpine:3.19","repo":"alpine","tag":"3.19"}
+#1 0.012 policy decision for source docker-image://alpine:3.19: ALLOW
+```
+
+If a policy denies a source, you'll see:
+
+```text
+#1 0.012 policy decision for source docker-image://nginx:latest: DENY
+ERROR: source "docker-image://nginx:latest" not allowed by policy
+```
+
+## Debug logging
+
+For detailed debugging, add `--policy log-level=debug` to see the full input
+JSON, unresolved fields, and policy responses:
+
+```console
+$ docker buildx build --progress=plain --policy log-level=debug .
+```
+
+This shows significantly more information than the default level, including the
+complete input structure for each source without needing `print()` statements
+in your policy.
+
+Complete input JSON:
+
+```text
+#1 0.007 policy input: {
+#1 0.007   "env": {
+#1 0.007     "filename": "."
+#1 0.007   },
+#1 0.007   "image": {
+#1 0.007     "ref": "docker.io/library/alpine:3.19",
+#1 0.007     "host": "docker.io",
+#1 0.007     "repo": "alpine",
+#1 0.007     "fullRepo": "docker.io/library/alpine",
+#1 0.007     "tag": "3.19",
+#1 0.007     "platform": "linux/arm64",
+#1 0.007     "os": "linux",
+#1 0.007     "arch": "arm64"
+#1 0.007   }
+#1 0.007 }
+```
+
+Unresolved fields:
+
+```text
+#1 0.007 unknowns for policy evaluation: [input.image.checksum input.image.labels input.image.user input.image.volumes input.image.workingDir input.image.env input.image.hasProvenance input.image.signatures]
+```
+
+Policy response:
+
+```text
+#1 0.008 policy response: map[allow:true]
+```
+
+This detailed output is invaluable for understanding exactly what data your
+policy receives and which fields are not yet resolved. Use debug logging when
+developing policies to avoid needing extensive `print()` statements.
+
+## Conditional debugging with print()
+
+While `--policy log-level=debug` shows all input data automatically, the
+`print()` function is useful for debugging specific rule logic and conditional
+flows:
+
+```rego
+allow if {
+    input.image
+    print("Checking image:", input.image.repo, "isCanonical:", input.image.isCanonical)
+    input.image.repo == "alpine"
+    input.image.isCanonical
+}
+```
+
+Use `print()` to debug conditional logic within rules or track which rules are
+evaluating. For general input inspection during development, use `--policy
+log-level=debug` instead - it requires no policy modifications.
+
+> [!NOTE]
+> Print statements only execute when their containing rule evaluates. A rule
+> like `allow if { input.image; print(...) }` only prints for image inputs,
+> not for Git repos, HTTP downloads, or local files.
+
+## Common issues
+
+### Full repository path or repository name
+
+Symptom: Policy checking repository names doesn't match as expected.
+
+Cause: Docker Hub images use `input.image.repo` for the short name
+(`"alpine"`) but `input.image.fullRepo` includes the full path
+(`"docker.io/library/alpine"`).
+
+Solution:
+
+```rego
+# Match just the repo name (works for Docker Hub and other registries)
+allow if {
+    input.image
+    input.image.repo == "alpine"
+}
+
+# Or match the full repository path
+allow if {
+    input.image
+    input.image.fullRepo == "docker.io/library/alpine"
+}
+```
+
+### Policy evaluation happens multiple times
+
+Symptom: Build output shows the same source evaluated multiple times.
+
+Cause: BuildKit may evaluate policies at different stages (reference
+resolution, actual pull) or for different platforms.
+
+This is normal behavior. Policies should be idempotent (produce same result
+each time for the same input).
+
+### Fields missing with `policy eval --print`
+
+Symptom: `docker buildx policy eval --print` doesn't show expected fields
+like `hasProvenance`, `labels`, or `checksum`.
+
+Cause: `--print` shows only reference information by default, without
+fetching from registries.
+
+Solution: Use `--fields` to fetch specific metadata fields:
+
+```console
+$ docker buildx policy eval --print --fields image.labels docker-image://alpine:3.19
+```
+
+See [Using build policies](./usage.md#testing-policies-with-policy-eval) for
+details.
+
+## Next steps
+
+- See complete field reference: [Input reference](./inputs.md)
+- Review example policies: [Examples](./examples.md)
+- Learn policy usage patterns: [Using build policies](./usage.md)
diff --git a/content/manuals/build/policies/examples.md b/content/manuals/build/policies/examples.md
new file mode 100644
index 000000000000..af4edbb6af1b
--- /dev/null
+++ b/content/manuals/build/policies/examples.md
@@ -0,0 +1,585 @@
+---
+title: Policy templates and examples
+linkTitle: Templates & examples
+description: Browse policy examples from quick-start configs to production-grade security templates
+keywords: build policies, policy examples, rego examples, docker security, registry allowlist, policy templates
+weight: 50
+---
+
+This page provides complete, working policy examples you can copy and adapt.
+The examples are organized into two sections: getting started policies for
+quick adoption, and production templates for comprehensive security.
+
+If you're new to policies, start with the tutorials:
+[Introduction](./intro.md), [Image validation](./validate-images.md), and [Git
+validation](./validate-git.md). Those pages teach individual techniques. This
+page shows complete policies combining those techniques.
+
+## How to use these examples
+
+1. Copy the policy code into a `Dockerfile.rego` file next to your
+   Dockerfile
+2. Customize any todo comments with your specific values
+3. Test by running `docker build .` and verifying the policy works as
+   expected
+4. Refine based on your team's needs
+
+### Using examples with bake
+
+These policies work with both `docker buildx build` and `docker buildx bake`.
+For bake, place the policy alongside your Dockerfile and it loads
+automatically. To use additional policies:
+
+```hcl
+target "default" {
+  dockerfile = "Dockerfile"
+  policy = ["extra.rego"]
+}
+```
+
+See the [Usage guide](./usage.md) for complete bake integration details.
+
+## Getting started
+
+These policies work immediately with minimal or no customization. Use them to
+adopt policies quickly and demonstrate value to your team.
+
+### Development-friendly baseline
+
+A permissive policy that allows typical development workflows while blocking
+obvious security issues.
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+allow if input.git
+
+# Allow common public registries
+allow if {
+  input.image.host == "docker.io"  # Docker Hub
+}
+
+allow if {
+  input.image.host == "ghcr.io"  # GitHub Container Registry
+}
+
+allow if {
+  input.image.host == "dhi.io"  # Docker Hardened Images
+}
+
+# Require HTTPS for all downloads
+allow if {
+  input.http.schema == "https"
+}
+
+decision := {"allow": allow}
+```
+
+This policy allows local and Git contexts, images from Docker Hub, GitHub
+Container Registry, and [Docker Hardened Images](/dhi/), and `ADD` downloads
+over HTTPS. It blocks HTTP downloads and non-standard registries.
+
+When to use: Starting point for teams new to policies. Provides basic security
+without disrupting development workflows.
+
+### Registry allowlist
+
+Control which registries your builds can pull images from.
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# TODO: Add your internal registry hostname
+allowed_registries := ["docker.io", "ghcr.io", "dhi.io", "registry.company.com"]
+
+allow if {
+  input.image.host in allowed_registries
+}
+
+# Allow mirrored DHI images from Docker Hub (DHI Enterprise users)
+# TODO: Replace with your organization namespace
+allow if {
+  input.image.host == "docker.io"
+  startswith(input.image.repo, "myorg/dhi-")
+}
+
+deny_msg contains msg if {
+  not allow
+  input.image
+  msg := sprintf("registry %s is not in the allowlist", [input.image.host])
+}
+
+decision := {"allow": allow, "deny_msg": deny_msg}
+```
+
+This policy restricts image pulls to approved registries. Customize and add
+your internal registry to the list. If you have a DHI Enterprise subscription
+and have mirrored Docker Hardened Images to Docker Hub, add a rule to allow
+images from your organization's namespace.
+
+When to use: Enforce corporate policies about approved image sources. Prevents
+developers from using arbitrary public registries.
+
+### Pin base images to digests
+
+Require digest references for reproducible builds.
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# Require digest references for all images
+allow if {
+  input.image.isCanonical
+}
+
+deny_msg contains msg if {
+  not allow
+  input.image
+  msg := sprintf("image %s must use digest reference (e.g., @sha256:...)", [input.image.ref])
+}
+
+decision := {"allow": allow, "deny_msg": deny_msg}
+```
+
+This policy requires images use digest references like
+`alpine@sha256:abc123...` instead of tags like `alpine:3.19`. Digests are
+immutable - the same digest always resolves to the same image content.
+
+When to use: Ensure build reproducibility. Prevents builds from breaking when
+upstream tags are updated. Required for compliance in some environments.
+
+### Control external dependencies
+
+Pin specific versions of dependencies downloaded during builds.
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# Allow any image (add restrictions as needed)
+allow if input.image
+
+# TODO: Add your allowed Git repositories and tags
+allowed_repos := {
+  "https://github.com/moby/buildkit.git": ["v0.26.1", "v0.27.0"],
+}
+# Only allow Git input from allowed_repos
+allow if {
+  some repo, versions in allowed_repos
+  input.git.remote == repo
+  input.git.tagName in versions
+}
+
+# TODO: Add your allowed downloads
+allow if {
+  input.http.url == "https://example.com/app-v1.0.tar.gz"
+}
+
+decision := {"allow": allow}
+```
+
+This policy creates allowlists for external dependencies. Add your Git
+repositories with approved version tags, and URLs.
+
+When to use: Control which external dependencies can be used in builds.
+Prevents builds from pulling arbitrary versions or unverified downloads.
+
+## Production templates
+
+These templates demonstrate comprehensive security patterns. They require
+customization but show best practices for production environments.
+
+### Image attestation and provenance
+
+Require images have provenance attestations from trusted builders.
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# TODO: Add your repository names
+allowed_repos := ["myorg/backend", "myorg/frontend", "myorg/worker"]
+
+# Production images need full attestations
+allow if {
+  some repo in allowed_repos
+  input.image.repo == repo
+  input.image.hasProvenance
+  some sig in input.image.signatures
+  trusted_github_builder(sig, repo)
+}
+
+# Helper to validate GitHub Actions build from main branch
+trusted_github_builder(sig, repo) if {
+  sig.signer.certificateIssuer == "CN=sigstore-intermediate,O=sigstore.dev"
+  sig.signer.issuer == "https://token.actions.githubusercontent.com"
+  startswith(sig.signer.buildSignerURI, sprintf("https://github.com/myorg/%s/.github/workflows/", [repo]))
+  sig.signer.sourceRepositoryRef == "refs/heads/main"
+  sig.signer.runnerEnvironment == "github-hosted"
+}
+
+# Allow Docker Hardened Images with built-in attestations
+allow if {
+  input.image.host == "dhi.io"
+  input.image.isCanonical
+  input.image.hasProvenance
+}
+
+# Allow official base images with digests
+allow if {
+  input.image.repo == "alpine"
+  input.image.host == "docker.io"
+  input.image.isCanonical
+}
+
+decision := {"allow": allow}
+```
+
+This template validates that your application images have provenance
+attestations, and were built by GitHub Actions from your main branch. Docker
+Hardened Images are allowed when using digests since they include comprehensive
+attestations by default. Other base images must use digests.
+
+Customize:
+
+- Replace `allowed_repos` with your image names
+- Update the organization name in `trusted_github_builder()`
+- Add rules for other base images you use
+
+When to use: Enforce supply chain security for production deployments. Ensures
+images are built by trusted CI/CD pipelines with auditable provenance.
+
+### Signed Git releases
+
+Enforce signed tags from trusted maintainers for Git dependencies.
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if input.image
+
+# TODO: Replace with your repository URL
+is_buildkit if {
+    input.git.remote == "https://github.com/moby/buildkit.git"
+}
+
+is_version_tag if {
+    is_buildkit
+    regex.match(`^v[0-9]+\.[0-9]+\.[0-9]+$`, input.git.tagName)
+}
+
+# Version tags must be signed
+allow if {
+    is_version_tag
+    input.git.tagName != ""
+    verify_git_signature(input.git.tag, "maintainers.asc")
+}
+
+# Allow unsigned refs for development
+allow if {
+    is_buildkit
+    not is_version_tag
+}
+
+decision := {"allow": allow}
+```
+
+This template requires production release tags to be signed by trusted
+maintainers. Development branches and commits can be unsigned.
+
+Setup:
+
+1. Export maintainer PGP public keys to `maintainers.asc`:
+   ```console
+   $ gpg --export --armor user1@example.com user2@example.com > maintainers.asc
+   ```
+2. Place `maintainers.asc` in the same directory as your policy file
+
+Customize:
+
+- Replace the repository URL in `is_buildkit`
+- Update the maintainers in the PGP keyring file
+- Adjust the version tag regex pattern if needed
+
+When to use: Validate that production dependencies come from signed releases.
+Protects against compromised releases or unauthorized updates.
+
+### Multi-registry policy
+
+Apply different validation rules for internal and external registries.
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# TODO: Replace with your internal registry hostname
+internal_registry := "registry.company.com"
+
+# Internal registry: basic validation
+allow if {
+  input.image.host == internal_registry
+}
+
+# External registries: strict validation
+allow if {
+  input.image.host != internal_registry
+  input.image.host != ""
+  input.image.isCanonical
+  input.image.hasProvenance
+}
+
+# Docker Hub: allowlist specific images
+allow if {
+  input.image.host == "docker.io"
+  # TODO: Add your approved base images
+  input.image.repo in ["alpine", "golang", "node"]
+  input.image.isCanonical
+}
+
+# Docker Hardened Images: trusted by default with built-in attestations
+allow if {
+  input.image.host == "dhi.io"
+  input.image.isCanonical
+}
+
+decision := {"allow": allow}
+```
+
+This template defines a trust boundary between internal and external image
+sources. Internal images require minimal validation, while external images need
+digests and provenance. Docker Hardened Images from `dhi.io` are treated as
+trusted since they include comprehensive attestations and security guarantees.
+
+Customize:
+
+- Set your internal registry hostname
+- Add your approved Docker Hub base images
+- Adjust validation requirements based on your security policies
+
+When to use: Organizations with internal registries that need different rules
+for internal and external sources. Balances security with practical workflow
+needs.
+
+### Multi-environment policy
+
+Apply different rules based on the build target or stage. For example,
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# TODO: Define your environment detection logic
+is_production if {
+  input.env.target == "production"
+}
+
+is_development if {
+  input.env.target == "development"
+}
+
+# Production: strict rules - only digest images with provenance
+allow if {
+  is_production
+  input.image.isCanonical
+  input.image.hasProvenance
+}
+
+# Development: permissive rules - any image
+allow if {
+  is_development
+  input.image
+}
+
+# Staging inherits production rules (default target detection)
+allow if {
+  not is_production
+  not is_development
+  input.image.isCanonical
+}
+
+decision := {"allow": allow}
+```
+
+This template uses build targets to apply different validation levels.
+Production requires attestations and digests, development is permissive, and
+staging uses moderate rules.
+
+Customize:
+
+- Update environment detection logic (target names, build args, etc.)
+- Adjust validation requirements for each environment
+- Add more environments as needed
+
+When to use: Teams with separate build configurations for different deployment
+stages. Allows flexibility in development while enforcing strict rules for
+production.
+
+### Complete dependency pinning
+
+Pin all external dependencies to specific versions across all input types.
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# TODO: Add your pinned images with exact digests
+# Docker Hub images use docker.io as host
+allowed_dockerhub := {
+  "alpine": "sha256:4b7ce07002c69e8f3d704a9c5d6fd3053be500b7f1c69fc0d80990c2ad8dd412",
+  "golang": "sha256:abc123...",
+}
+
+allow if {
+  input.image.host == "docker.io"
+  some repo, digest in allowed_dockerhub
+  input.image.repo == repo
+  input.image.checksum == digest
+}
+
+# TODO: Add your pinned DHI images
+allowed_dhi := {
+  "python": "sha256:def456...",
+  "node": "sha256:ghi789...",
+}
+
+allow if {
+  input.image.host == "dhi.io"
+  some repo, digest in allowed_dhi
+  input.image.repo == repo
+  input.image.checksum == digest
+}
+
+# TODO: Add your pinned Git dependencies
+allowed_git := {
+  "https://github.com/moby/buildkit.git": {
+    "tag": "v0.26.1",
+    "commit": "abc123...",
+  },
+}
+
+allow if {
+  some url, version in allowed_git
+  input.git.remote == url
+  input.git.tagName == version.tag
+  input.git.commitChecksum == version.commit
+}
+
+# TODO: Add your pinned HTTP downloads
+allowed_downloads := {
+  "https://releases.example.com/app-v1.0.tar.gz": "sha256:def456...",
+}
+
+allow if {
+  some url, checksum in allowed_downloads
+  input.http.url == url
+  input.http.checksum == checksum
+}
+
+decision := {"allow": allow}
+```
+
+This template pins every external dependency to exact versions with cryptographic
+verification. Images use digests, Git repos use commit SHAs, and downloads use
+checksums.
+
+Customize:
+
+- Add all your dependencies with exact versions/checksums
+- Maintain this file when updating dependencies
+- Consider automating updates through CI/CD
+
+When to use: Maximum reproducibility and security. Ensures builds always use
+exact versions of all dependencies. Required for high-security or regulated
+environments.
+
+### Manual signature verification
+
+Verify image signatures by inspecting signature metadata fields.
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# Require valid GitHub Actions signatures
+allow if {
+    input.image
+    input.image.hasProvenance
+    some sig in input.image.signatures
+    valid_github_signature(sig)
+}
+
+# Helper function to validate GitHub Actions signature
+valid_github_signature(sig) if {
+    # Sigstore keyless signing
+    sig.signer.certificateIssuer == "CN=sigstore-intermediate,O=sigstore.dev"
+    sig.signer.issuer == "https://token.actions.githubusercontent.com"
+
+    # TODO: Replace with your organization
+    startswith(sig.signer.buildSignerURI, "https://github.com/myorg/.github/workflows/")
+    startswith(sig.signer.sourceRepositoryURI, "https://github.com/myorg/")
+
+    # Verify GitHub hosted runner
+    sig.signer.runnerEnvironment == "github-hosted"
+
+    # Require timestamp
+    count(sig.timestamps) > 0
+}
+
+decision := {"allow": allow}
+```
+
+This policy validates that images were built by GitHub Actions using Sigstore
+keyless signing.
+
+Customize:
+
+- Replace `myorg` with your GitHub organization
+- Adjust workflow path restrictions
+- Add additional signature field checks as needed
+
+When to use: Enforce that images are built by CI/CD with verifiable signatures,
+not manually pushed by developers.
+
+## Next steps
+
+- Write unit tests for your policies: [Test build policies](./testing.md)
+- Review [Built-in functions](./built-ins.md) for signature verification and
+  attestation checking
+- Check the [Input reference](./inputs.md) for all available fields you can
+  validate
+- Read the tutorials for detailed explanations:
+  [Introduction](./intro.md), [Image validation](./validate-images.md), [Git
+  validation](./validate-git.md)
diff --git a/content/manuals/build/policies/inputs.md b/content/manuals/build/policies/inputs.md
new file mode 100644
index 000000000000..43aad88629c5
--- /dev/null
+++ b/content/manuals/build/policies/inputs.md
@@ -0,0 +1,539 @@
+---
+title: Input reference
+linkTitle: Input reference
+description: Reference documentation for policy input fields
+keywords: build policies, input reference, policy fields, image metadata, git metadata
+weight: 80
+---
+
+When Buildx evaluates policies, it provides information about build inputs
+through the `input` object. The structure of `input` depends on the type of
+resource your Dockerfile references.
+
+## Input types
+
+Build inputs correspond to Dockerfile instructions:
+
+| Dockerfile instruction                  | Input type | Access pattern |
+| --------------------------------------- | ---------- | -------------- |
+| `FROM alpine:latest`                    | Image      | `input.image`  |
+| `COPY --from=builder /app /app`         | Image      | `input.image`  |
+| `ADD https://example.com/file.tar.gz /` | HTTP       | `input.http`   |
+| `ADD git@github.com:user/repo.git /src` | Git        | `input.git`    |
+| Build context (`.`)                     | Local      | `input.local`  |
+
+Each input type has specific fields available for policy evaluation.
+
+## HTTP inputs
+
+HTTP inputs represent files downloaded over HTTP or HTTPS using the `ADD`
+instruction.
+
+### Example Dockerfile
+
+```dockerfile
+FROM alpine
+ADD --checksum=sha256:abc123... https://example.com/app.tar.gz /app.tar.gz
+```
+
+### Available fields
+
+#### `input.http.url`
+
+The complete URL of the resource.
+
+```rego
+allow if {
+    input.http.url == "https://example.com/app.tar.gz"
+}
+```
+
+#### `input.http.schema`
+
+The URL scheme (`http` or `https`).
+
+```rego
+# Require HTTPS for all downloads
+allow if {
+    input.http.schema == "https"
+}
+```
+
+#### `input.http.host`
+
+The hostname from the URL.
+
+```rego
+# Allow downloads from approved domains
+allow if {
+    input.http.host == "cdn.example.com"
+}
+```
+
+#### `input.http.path`
+
+The path component of the URL.
+
+```rego
+allow if {
+    startswith(input.http.path, "/releases/")
+}
+```
+
+#### `input.http.checksum`
+
+The checksum specified with `ADD --checksum=...`, if present. Empty string if
+no checksum was provided.
+
+```rego
+# Require checksums for all downloads
+allow if {
+    input.http.checksum != ""
+}
+```
+
+#### `input.http.hasAuth`
+
+Boolean indicating if the request includes authentication (HTTP basic auth or
+bearer token).
+
+```rego
+# Require authentication for internal servers
+allow if {
+    input.http.host == "internal.company.com"
+    input.http.hasAuth
+}
+```
+
+## Image inputs
+
+Image inputs represent container images from `FROM` instructions or
+`COPY --from` references.
+
+### Example Dockerfile
+
+```dockerfile
+FROM alpine:3.19@sha256:abc123...
+COPY --from=builder:latest /app /app
+```
+
+### Available fields
+
+#### `input.image.ref`
+
+The complete image reference as written in the Dockerfile.
+
+```rego
+allow if {
+    input.image.ref == "alpine:3.19@sha256:abc123..."
+}
+```
+
+#### `input.image.host`
+
+The registry hostname. Docker Hub images use `"docker.io"`.
+
+```rego
+# Only allow Docker Hub images
+allow if {
+    input.image.host == "docker.io"
+}
+
+# Only allow images from GitHub Container Registry
+allow if {
+    input.image.host == "ghcr.io"
+}
+```
+
+#### `input.image.repo`
+
+The repository name without the registry host.
+
+```rego
+allow if {
+    input.image.repo == "library/alpine"
+}
+```
+
+#### `input.image.fullRepo`
+
+The full repository path including registry host.
+
+```rego
+allow if {
+    input.image.fullRepo == "docker.io/library/alpine"
+}
+```
+
+#### `input.image.tag`
+
+The tag portion of the reference. Empty if using a digest reference.
+
+```rego
+# Allow only specific tags
+allow if {
+    input.image.tag == "3.19"
+}
+```
+
+#### `input.image.isCanonical`
+
+Boolean indicating if the reference uses a digest (`@sha256:...`).
+
+```rego
+# Require digest references
+allow if {
+    input.image.isCanonical
+}
+```
+
+#### `input.image.checksum`
+
+The SHA256 digest of the image manifest.
+
+```rego
+allow if {
+    input.image.checksum == "sha256:abc123..."
+}
+```
+
+#### `input.image.platform`
+
+The target platform for multi-platform images.
+
+```rego
+allow if {
+    input.image.platform == "linux/amd64"
+}
+```
+
+#### `input.image.os`
+
+The operating system from the image configuration.
+
+```rego
+allow if {
+    input.image.os == "linux"
+}
+```
+
+#### `input.image.arch`
+
+The CPU architecture from the image configuration.
+
+```rego
+allow if {
+    input.image.arch == "amd64"
+}
+```
+
+#### `input.image.hasProvenance`
+
+Boolean indicating if the image has provenance attestations.
+
+```rego
+# Require provenance for production images
+allow if {
+    input.image.hasProvenance
+}
+```
+
+#### `input.image.labels`
+
+A map of image labels from the image configuration.
+
+```rego
+# Check for specific labels
+allow if {
+    input.image.labels["org.opencontainers.image.vendor"] == "Example Corp"
+}
+```
+
+#### `input.image.signatures`
+
+Array of attestation signatures. Each signature in the array has the following
+fields:
+
+- `kind`: Signature kind (e.g., `"docker-github-builder"`, `"self-signed"`)
+- `type`: Signature type (e.g., `"bundle-v0.3"`, `"simplesigning-v1"`)
+- `timestamps`: Trusted timestamps from transparency logs
+- `dockerReference`: Docker image reference
+- `isDHI`: Boolean indicating if this is a Docker Hardened Image
+- `signer`: Sigstore certificate details
+
+```rego
+# Require at least one signature
+allow if {
+    count(input.image.signatures) > 0
+}
+```
+
+For Sigstore signatures, the `signer` object provides detailed certificate
+information from the signing workflow:
+
+- `certificateIssuer`: Certificate issuer
+- `subjectAlternativeName`: Subject alternative name from certificate
+- `buildSignerURI`: URI of the build signer
+- `buildSignerDigest`: Digest of the build signer
+- `runnerEnvironment`: CI/CD runner environment
+- `sourceRepositoryURI`: Source repository URL
+- `sourceRepositoryDigest`: Source repository digest
+- `sourceRepositoryRef`: Source repository ref (branch/tag)
+- `sourceRepositoryIdentifier`: Source repository identifier
+- `sourceRepositoryOwnerURI`: Repository owner URI
+- `buildConfigURI`: Build configuration URI
+- `buildTrigger`: What triggered the build
+- `runInvocationURI`: CI/CD run invocation URI
+
+```rego
+# Require signatures from GitHub Actions
+allow if {
+    some sig in input.image.signatures
+    sig.signer.runnerEnvironment == "github-hosted"
+    startswith(sig.signer.sourceRepositoryURI, "https://github.com/myorg/")
+}
+```
+
+## Git inputs
+
+Git inputs represent Git repositories referenced in `ADD` instructions or used
+as build context.
+
+### Example Dockerfile
+
+```dockerfile
+ADD git@github.com:moby/buildkit.git#v0.12.0 /src
+```
+
+### Available fields
+
+#### `input.git.schema`
+
+The URL scheme (`https`, `http`, `git`, or `ssh`).
+
+```rego
+# Require HTTPS for Git clones
+allow if {
+    input.git.schema == "https"
+}
+```
+
+#### `input.git.host`
+
+The Git host (e.g., `github.com`, `gitlab.com`).
+
+```rego
+allow if {
+    input.git.host == "github.com"
+}
+```
+
+#### `input.git.remote`
+
+The complete Git URL.
+
+```rego
+allow if {
+    input.git.remote == "https://github.com/moby/buildkit.git"
+}
+```
+
+#### `input.git.ref`
+
+The Git reference.
+
+```rego
+allow if {
+    input.git.ref == "refs/heads/master"
+}
+```
+
+#### `input.git.tagName`
+
+The tag name if the reference is a tag.
+
+```rego
+# Only allow version tags
+allow if {
+    regex.match(`^v[0-9]+\.[0-9]+\.[0-9]+$`, input.git.tagName)
+}
+```
+
+#### `input.git.branch`
+
+The branch name if the reference is a branch.
+
+```rego
+allow if {
+    input.git.branch == "main"
+}
+```
+
+#### `input.git.subDir`
+
+The subdirectory path within the repository, if specified.
+
+```rego
+# Ensure clones are from the root
+allow if {
+    input.git.subDir == ""
+}
+```
+
+#### `input.git.isCommitRef`
+
+Boolean indicating if the reference is a commit SHA (as opposed to a branch or
+tag name).
+
+```rego
+# Require commit SHAs for production
+allow if {
+    input.env.target == "production"
+    input.git.isCommitRef
+}
+```
+
+#### `input.git.checksum`
+
+The checksum of the Git reference. For commit references and branches, this is
+the commit hash. For annotated tags, this is the tag object hash.
+
+```rego
+allow if {
+    input.git.checksum == "abc123..."
+}
+```
+
+#### `input.git.commitChecksum`
+
+The commit hash that the reference points to. For annotated tags, this differs
+from `checksum` (which is the tag object hash). For commit references and
+branches, this is the same as `checksum`.
+
+```rego
+allow if {
+    input.git.commitChecksum == "abc123..."
+}
+```
+
+#### `input.git.isAnnotatedTag`
+
+Boolean indicating if the reference is an annotated tag (as opposed to a
+lightweight tag).
+
+```rego
+# Require annotated tags
+allow if {
+    input.git.tagName != ""
+    input.git.isAnnotatedTag
+}
+```
+
+#### `input.git.commit`
+
+Object containing commit metadata:
+
+- `author`: Author name, email, when
+- `committer`: Committer name, email, when
+- `message`: Commit message
+- `pgpSignature`: PGP signature details if signed
+- `sshSignature`: SSH signature details if signed
+
+```rego
+# Check commit author
+allow if {
+    input.git.commit.author.email == "maintainer@example.com"
+}
+```
+
+#### `input.git.tag`
+
+Object containing tag metadata for annotated tags:
+
+- `tagger`: Tagger name, email, when
+- `message`: Tag message
+- `pgpSignature`: PGP signature details if signed
+- `sshSignature`: SSH signature details if signed
+
+```rego
+# Require signed tags
+allow if {
+    input.git.tag.pgpSignature != null
+}
+```
+
+## Local inputs
+
+Local inputs represent the build context directory.
+
+### Available fields
+
+#### `input.local.name`
+
+The name or path of the local context.
+
+```rego
+allow if {
+    input.local.name == "."
+}
+```
+
+Local inputs are typically less restricted than remote inputs, but you can
+still write policies to enforce context requirements.
+
+## Environment fields
+
+The `input.env` object provides build configuration information set by user on
+invoking the build, not specific to a resource type.
+
+### Available fields
+
+#### `input.env.filename`
+
+The name of the Dockerfile being built.
+
+```rego
+# Stricter rules for production Dockerfile
+allow if {
+    input.env.filename == "Dockerfile"
+    input.image.isCanonical
+}
+
+# Relaxed rules for development
+allow if {
+    input.env.filename == "Dockerfile.dev"
+}
+```
+
+#### `input.env.target`
+
+The build target from multi-stage builds.
+
+```rego
+# Require signing only for release builds
+allow if {
+    input.env.target == "release"
+    input.git.tagName != ""
+    verify_git_signature(input.git.tag, "maintainer.asc")
+}
+```
+
+#### `input.env.args`
+
+Build arguments passed with `--build-arg`. Access specific arguments by key.
+
+```rego
+# Check build argument values
+allow if {
+    input.env.args.ENVIRONMENT == "production"
+    input.image.hasProvenance
+}
+```
+
+## Next steps
+
+- See [Built-in functions](./built-ins.md) for built-in helper functions to
+  check and validate input properties
+- Browse [Example policies](./examples.md) for common patterns
+- Read about [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/)
+  for advanced policy logic
diff --git a/content/manuals/build/policies/intro.md b/content/manuals/build/policies/intro.md
new file mode 100644
index 000000000000..ab27f47b8351
--- /dev/null
+++ b/content/manuals/build/policies/intro.md
@@ -0,0 +1,334 @@
+---
+title: Introduction to build policies
+linkTitle: Introduction
+description: Get started with writing and evaluating build policies
+keywords: build policies, opa, rego, policy tutorial, docker build, security
+weight: 10
+---
+
+Build policies let you validate the inputs to your Docker builds before they
+run. This tutorial walks you through creating your first policy, teaching the
+Rego basics you need along the way.
+
+## What you'll learn
+
+By the end of this tutorial, you'll understand:
+
+- How to create and organize policy files
+- Basic Rego syntax and patterns
+- How to write policies that validate URLs, checksums, and images
+- How policies evaluate during builds
+
+## Prerequisites
+
+- Buildx version 0.31 or later
+- Basic familiarity with Dockerfiles and building images
+
+## How policies work
+
+When you build an image, Buildx resolves all the inputs your
+Dockerfile references: base images from `FROM` instructions, files
+from `ADD` or `COPY` or build contexts, and Git repositories. Before
+running the build, Buildx evaluates your policies against these
+inputs. If any input violates a policy, the build fails before any
+instructions execute.
+
+Policies are written in Rego, a declarative language designed for expressing
+rules and constraints. You don't need to know Rego to get started - this
+tutorial teaches you what you need.
+
+## Create your first policy
+
+Create a new directory for this tutorial and add a Dockerfile:
+
+```console
+$ mkdir policy-tutorial
+$ cd policy-tutorial
+```
+
+Create a `Dockerfile` that downloads a file with `ADD`:
+
+```dockerfile
+FROM scratch
+ADD https://example.com/index.html /index.html
+```
+
+Now create a policy file. Policies use the `.rego` extension and live alongside
+your Dockerfile. Create `Dockerfile.rego`:
+
+```rego {title="Dockerfile.rego"}
+package docker
+
+default allow := false
+
+allow if input.local
+allow if {
+  input.http.host == "example.com"
+}
+
+decision := {"allow": allow}
+```
+
+Save this file as `Dockerfile.rego` in the same directory as your Dockerfile.
+
+Let's break down what this policy does:
+
+- `package docker` - All build policies must start with this package declaration
+- `default allow := false` - This example uses a deny-by-default rule: if inputs do not match an `allow` rule, the policy check fails
+- `allow if input.local` - The first rule allows any local files (your build context)
+- `allow if { input.http.host == "example.com" }` - The second rule allows HTTP downloads from `example.com`
+- `decision := {"allow": allow}` - The final decision object tells Buildx whether to allow or deny the input
+
+This policy says: "Only allow local files and HTTP downloads from
+`example.com`". Rego evaluates all the policy rules to figure out the return
+value for the `decision` variable, for each build input. The evaluations happen
+in parallel and on-demand; the order of the policy rules has no significance.
+
+### About `input.local`
+
+You'll see `allow if input.local` in nearly every policy. This rule allows
+local file access, which includes your build context (typically, the `.`
+directory) and importantly, the Dockerfile itself. Without this rule, Buildx
+can't read your Dockerfile to start the build.
+
+Even builds that don't reference any files from the build context often need
+`input.local` because the Dockerfile is a local file. The policy evaluates
+before the build starts, and denying local access means denying access to the
+Dockerfile.
+
+In rare cases, you might want stricter local file policies - for example, in CI
+builds where the build context uses a Git URL as a context directly. In these
+cases, you may want to deny local sources to prevent untracked files or changes
+from making their way into your build.
+
+## Automatic policy loading
+
+Buildx automatically loads policies that match your Dockerfile name. When you
+build with `Dockerfile`, Buildx looks for `Dockerfile.rego` in the same
+directory. For a file named `app.Dockerfile`, it looks for
+`app.Dockerfile.rego`.
+
+This automatic loading means you don't need any command-line flags in most
+cases - create the policy file and build.
+
+The policy file must be in the same directory as the Dockerfile. If Buildx
+can't find a matching policy, the build proceeds without policy evaluation
+(unless you use `--policy strict=true`).
+
+For more control over policy loading, see the [Usage guide](./usage.md).
+
+## Run a build with your policy
+
+Build the image with policy evaluation enabled:
+
+```console
+$ docker build .
+```
+
+The build succeeds because the URL in your Dockerfile matches the policy. Now
+try changing the URL in your Dockerfile to something else:
+
+```dockerfile
+FROM scratch
+ADD https://api.github.com/users/octocat /user.json
+```
+
+Build again:
+
+```console
+$ docker build .
+```
+
+This time the build fails with a policy violation. The `api.github.com`
+hostname doesn't match the rule in your policy, so Buildx rejects it before
+running any build steps.
+
+## Debugging policy failures
+
+If your build fails with a policy violation, use `--progress=plain` to see
+exactly what went wrong:
+
+```console
+$ docker buildx build --progress=plain .
+```
+
+This shows all policy checks, the input data for each source, and allow/deny
+decisions. For complete debugging guidance, see [Debugging](./debugging.md).
+
+## Add helpful error messages
+
+When a policy denies an input, users see a generic error message. You can
+provide custom messages that explain why the build was denied:
+
+```rego {title="Dockerfile.rego"}
+package docker
+
+default allow := false
+
+allow if input.local
+allow if {
+  input.http.host == "example.com"
+  input.http.schema == "https"
+}
+
+deny_msg contains msg if {
+  not allow
+  input.http
+  msg := "only HTTPS downloads from example.com are allowed"
+}
+
+decision := {"allow": allow, "deny_msg": deny_msg}
+```
+
+Now when a build is denied, users see your custom message explaining what went
+wrong:
+
+```console
+$ docker buildx build .
+Policy: only HTTPS downloads from example.com are allowed
+ERROR: failed to build: ... source not allowed by policy
+```
+
+The `deny_msg` rule uses `contains` to add messages to a set. You can add
+multiple deny messages for different failure conditions to help users understand
+exactly what needs to change.
+
+## Understand Rego rules
+
+Rego policies are built from rules. A rule defines when something is allowed.
+The basic pattern is:
+
+```rego
+allow if {
+    condition_one
+    condition_two
+    condition_three
+}
+```
+
+All conditions must be true for the rule to match. Think of it as an AND
+operation - the URL must match AND the checksum must match AND any other
+conditions you specify.
+
+You can have multiple `allow` rules in one policy. If any rule matches, the
+input is allowed:
+
+```rego
+# Allow downloads from example.com
+allow if {
+    input.http.host == "example.com"
+}
+
+# Also allow downloads from api.github.com
+allow if {
+    input.http.host == "api.github.com"
+}
+```
+
+This works like OR - the input can match the first rule OR the second rule.
+
+## Access input fields
+
+The `input` object gives you access to information about build inputs. The
+structure depends on the input type:
+
+- `input.http` - Files downloaded with `ADD https://...`
+- `input.image` - Container images from `FROM` or `COPY --from`
+- `input.git` - Git repositories from `ADD git://...` or build context
+- `input.local` - Local file context
+
+Refer to the [Input reference](./inputs.md) for all available input fields.
+
+For HTTP downloads, you can access:
+
+| Key                 | Description                        | Example                          |
+| ------------------- | ---------------------------------- | -------------------------------- |
+| `input.http.url`    | The full URL                       | `https://example.com/index.html` |
+| `input.http.schema` | The protocol (HTTP/HTTPS)          | `https`                          |
+| `input.http.host`   | The hostname                       | `example.com`                    |
+| `input.http.path`   | The URL path, including parameters | `/index.html`                    |
+
+Update your policy to require HTTPS:
+
+```rego
+package docker
+
+default allow := false
+
+allow if {
+    input.http.host == "example.com"
+    input.http.schema == "https"
+}
+
+decision := {"allow": allow}
+```
+
+Now the policy requires both the hostname to be `example.com` and the protocol
+to be HTTPS. HTTP URLs (without TLS) would fail the policy check.
+
+## Pattern matching and strings
+
+Rego provides [built-in functions] for pattern matching. Use `startswith()` to
+match URL prefixes:
+
+[built-in functions]: https://www.openpolicyagent.org/docs/policy-language#built-in-functions
+
+```rego
+allow if {
+    startswith(input.http.url, "https://example.com/")
+}
+```
+
+This allows any URL that starts with `https://example.com/`.
+
+Use `regex.match()` for complex patterns:
+
+```rego
+allow if {
+    regex.match(`^https://example\.com/.+\.json$`, input.http.url)
+}
+```
+
+This matches URLs that:
+
+- Start with `https://example.com/`
+- End with `.json`
+- Have at least one character between the domain and extension
+
+## Policy file location
+
+Policy files live adjacent to the Dockerfile they validate, using the naming
+pattern `<dockerfile-name>.rego`:
+
+```text
+project/
+├── Dockerfile           # Main Dockerfile
+├── Dockerfile.rego      # Policy for Dockerfile
+├── lint.Dockerfile      # Linting Dockerfile
+└── lint.Dockerfile.rego # Policy for lint.Dockerfile
+```
+
+When you build, Buildx automatically loads the corresponding policy file:
+
+```console
+$ docker buildx build -f Dockerfile .        # Loads Dockerfile.rego
+$ docker buildx build -f lint.Dockerfile .   # Loads lint.Dockerfile.rego
+```
+
+## Next steps
+
+You now understand how to write basic build policies for HTTP resources. To
+continue learning:
+
+- Apply and test policies: [Using build policies](./usage.md)
+- Learn [Image validation](./validate-images.md) to validate container images
+  from `FROM` instructions
+- Learn [Git validation](./validate-git.md) to validate Git repositories used
+  in builds
+- See [Example policies](./examples.md) for copy-paste-ready policies covering
+  common scenarios
+- Write unit tests for your policies: [Test build policies](./testing.md)
+- Debug policy failures: [Debugging](./debugging.md)
+- Read the [Input reference](./inputs.md) for all available input fields
+- Check the [Built-in functions](./built-ins.md) for signature verification,
+  attestations, and other security checks
diff --git a/content/manuals/build/policies/testing.md b/content/manuals/build/policies/testing.md
new file mode 100644
index 000000000000..300f2d3741f9
--- /dev/null
+++ b/content/manuals/build/policies/testing.md
@@ -0,0 +1,214 @@
+---
+title: Test build policies
+linkTitle: Testing
+description: Write and run unit tests for build policies, similar to the opa test command
+keywords: build policies, opa, rego, testing, unit tests, policy validation
+weight: 60
+---
+
+The [`docker buildx policy test`](/reference/cli/docker/buildx/policy/test/)
+command runs unit tests for build policies using OPA's [standard test
+framework](https://www.openpolicyagent.org/docs/policy-testing).
+
+```console
+$ docker buildx policy test <path>
+```
+
+This validates policy logic with mocked inputs.
+
+For testing against real sources (actual image metadata, Git repositories), use
+[`docker buildx policy eval`](/reference/cli/docker/buildx/policy/eval/)
+instead. You can use the `eval --print` option to resolve input for a specific
+source for writing a test case.
+
+## Basic example
+
+Start with a simple policy that only allows `alpine` images:
+
+```rego {title="Dockerfile.rego"}
+package docker
+
+default allow = false
+
+allow if {
+    input.image.repo == "alpine"
+}
+
+decision := {"allow": allow}
+```
+
+Create a test file with the `*_test.rego` suffix. Test functions must start
+with `test_`:
+
+```rego {title="Dockerfile_test.rego"}
+package docker
+
+test_alpine_allowed if {
+    decision.allow with input as {"image": {"repo": "alpine"}}
+}
+
+test_ubuntu_denied if {
+    not decision.allow with input as {"image": {"repo": "ubuntu"}}
+}
+```
+
+Run the tests:
+
+```console
+$ docker buildx policy test .
+test_alpine_allowed: PASS (allow=true)
+test_ubuntu_denied: PASS (allow=false)
+```
+
+`PASS` indicates that the tests defined in `Dockerfile_test.rego` executed
+successfully and all assertions were satisfied.
+
+## Command options
+
+Filter tests by name with `--run`:
+
+```console
+$ docker buildx policy test --run alpine .
+test_alpine_allowed: PASS (allow=true)
+```
+
+Test policies with non-default filenames using `--filename`:
+
+```console
+$ docker buildx policy test --filename app.Dockerfile .
+```
+
+This loads `app.Dockerfile.rego` and runs `*_test.rego` files against it.
+
+## Test output
+
+Passed tests show the allow status and any deny messages:
+
+```console
+test_alpine_allowed: PASS (allow=true)
+test_ubuntu_denied: PASS (allow=false, deny_msg=only alpine images are allowed)
+```
+
+Failed tests show input, decision output, and missing fields:
+
+```console
+test_invalid: FAIL (allow=false)
+input:
+  {
+    "image": {}
+  }
+decision:
+  {
+    "allow": false,
+    "deny_msg": [
+      "only alpine images are allowed"
+    ]
+  }
+missing_input: input.image.repo
+```
+
+## Test deny messages
+
+To test custom error messages, capture the full decision result and assert on
+the `deny_msg` field.
+
+For a policy with deny messages:
+
+```rego {title="Dockerfile.rego"}
+package docker
+
+default allow = false
+
+allow if {
+    input.image.repo == "alpine"
+}
+
+deny_msg contains msg if {
+    not allow
+    msg := "only alpine images are allowed"
+}
+
+decision := {"allow": allow, "deny_msg": deny_msg}
+```
+
+Test the deny message:
+
+```rego {title="Dockerfile_test.rego"}
+test_deny_message if {
+    result := decision with input as {"image": {"repo": "ubuntu"}}
+    not result.allow
+    "only alpine images are allowed" in result.deny_msg
+}
+```
+
+## Test patterns
+
+**Test environment-specific rules:**
+
+```rego
+test_production_requires_digest if {
+    decision.allow with input as {
+        "env": {"target": "production"},
+        "image": {"isCanonical": true}
+    }
+}
+
+test_development_allows_tags if {
+    decision.allow with input as {
+        "env": {"target": "development"},
+        "image": {"isCanonical": false}
+    }
+}
+```
+
+**Test multiple registries:**
+
+```rego
+test_dockerhub_allowed if {
+    decision.allow with input as {
+        "image": {
+            "ref": "docker.io/library/alpine",
+            "host": "docker.io",
+            "repo": "alpine"
+        }
+    }
+}
+
+test_ghcr_allowed if {
+    decision.allow with input as {
+        "image": {
+            "ref": "ghcr.io/myorg/myapp",
+            "host": "ghcr.io",
+            "repo": "myorg/myapp"
+        }
+    }
+}
+```
+
+For available input fields, see the [Input reference](./inputs.md).
+
+## Organize test files
+
+The test runner discovers all `*_test.rego` files recursively:
+
+```plaintext
+build-policies/
+├── Dockerfile.rego
+├── Dockerfile_test.rego
+└── tests/
+    ├── registries_test.rego
+    ├── signatures_test.rego
+    └── environments_test.rego
+```
+
+Run all tests:
+
+```console
+$ docker buildx policy test .
+```
+
+Or test specific files:
+
+```console
+$ docker buildx policy test tests/registries_test.rego
+```
diff --git a/content/manuals/build/policies/usage.md b/content/manuals/build/policies/usage.md
new file mode 100644
index 000000000000..c7ba7561611b
--- /dev/null
+++ b/content/manuals/build/policies/usage.md
@@ -0,0 +1,493 @@
+---
+title: Using build policies
+linkTitle: Usage
+description: Apply policies to builds and develop policies iteratively
+keywords: build policies, policy eval, docker buildx, policy development, debugging
+weight: 20
+---
+
+Build policies validate inputs before builds execute. This guide covers how to
+develop policies iteratively and apply them to real builds with `docker buildx
+build` and `docker buildx bake`.
+
+## Prerequisites
+
+- Buildx 0.31.0 or later - Check your version: `docker buildx version`
+- BuildKit 0.26.0 or later - Verify with: `docker buildx inspect
+  --bootstrap`
+
+If you're using Docker Desktop, ensure you're on a version that includes these
+updates.
+
+## Policy development workflow
+
+Buildx automatically loads policies that match your Dockerfile name. When you
+build with `Dockerfile`, Buildx looks for `Dockerfile.rego` in the same
+directory. For a file named `app.Dockerfile`, it looks for
+`app.Dockerfile.rego`. See the [Advanced: Policy configuration](#advanced-policy-configuration)
+section for configuration options and manual policy loading.
+
+Writing policies is an iterative process:
+
+1. Start with a basic deny-all policy.
+2. Build with debug logging to see what inputs your Dockerfile uses.
+3. Add rules to allow specific sources based on the debug output.
+4. Test and refine.
+
+### Viewing inputs from your Dockerfile
+
+To see the inputs that your Dockerfile references (images, Git repos, HTTP
+downloads), build with debug logging:
+
+```console
+$ docker buildx build --progress=plain --policy log-level=debug .
+```
+
+Example output for an image source:
+
+```text
+#1 0.010 checking policy for source docker-image://alpine:3.19 (linux/arm64)
+#1 0.011 policy input: {
+#1 0.011   "env": {
+#1 0.011     "filename": "."
+#1 0.011   },
+#1 0.011   "image": {
+#1 0.011     "ref": "docker.io/library/alpine:3.19",
+#1 0.011     "host": "docker.io",
+#1 0.011     "repo": "alpine",
+#1 0.011     "tag": "3.19",
+#1 0.011     "platform": "linux/arm64"
+#1 0.011   }
+#1 0.011 }
+#1 0.011 unknowns for policy evaluation: [input.image.checksum input.image.labels ...]
+#1 0.012 policy decision for source docker-image://alpine:3.19: ALLOW
+```
+
+This shows the complete input structure, which fields are unresolved, and the
+policy decision for each source. See [Input reference](./inputs.md) for all
+available fields.
+
+### Testing policies with policy eval
+
+Use [`docker buildx policy eval`](/reference/cli/docker/buildx/policy/eval/) to
+test whether your policy allows a specific source without running a full build.
+
+Note: `docker buildx policy eval` tests the source specified as the argument.
+It doesn't parse your Dockerfile to evaluate all inputs - for that, [build with
+--progress=plain](#viewing-inputs-from-your-dockerfile).
+
+Test if your policy allows the local context:
+
+```console
+$ docker buildx policy eval .
+```
+
+No output means the policy allowed the source. If denied, you see:
+
+```console
+ERROR: policy denied
+```
+
+Test other sources:
+
+```console
+$ docker buildx policy eval https://example.com              # Test HTTP
+$ docker buildx policy eval https://github.com/org/repo.git  # Test Git
+```
+
+By default, `--print` shows reference information parsed from the source string
+(like `repo`, `tag`, `host`) without fetching from registries. To inspect
+metadata that requires fetching the source (like `labels`, `checksum`, or
+`hasProvenance`), specify which fields to fetch with `--fields`:
+
+```console
+$ docker buildx policy eval --print --fields image.labels docker-image://alpine:3.19
+```
+
+Multiple fields can be specified as a comma-separated list.
+
+### Iterative development example
+
+Here's a practical workflow for developing policies:
+
+1. Start with basic deny-all policy:
+
+   ```rego {title="Dockerfile.rego"}
+   package docker
+
+   default allow := false
+
+   allow if input.local
+
+   decision := {"allow": allow}
+   ```
+
+2. Build with debug logging to see what inputs your Dockerfile uses:
+
+   ```console
+   $ docker buildx build --progress=plain --policy log-level=debug .
+   ```
+
+   The output shows the denied image and its input structure:
+
+   ```text
+   #1 0.026 checking policy for source docker-image://docker.io/library/alpine:3.19
+   #1 0.027 policy input: {
+   #1 0.027   "image": {
+   #1 0.027     "repo": "alpine",
+   #1 0.027     "tag": "3.19",
+   #1 0.027     ...
+   #1 0.027   }
+   #1 0.027 }
+   #1 0.028 policy decision for source docker-image://alpine:3.19: DENY
+   #1 ERROR: source "docker-image://alpine:3.19" not allowed by policy
+   ```
+
+3. Add a rule allowing the alpine image:
+
+   ```rego
+   allow if {
+       input.image.repo == "alpine"
+   }
+   ```
+
+4. Build again to verify the policy works:
+
+   ```console
+   $ docker buildx build .
+   ```
+
+If it fails, see [Debugging](./debugging.md) for troubleshooting guidance.
+
+## Using policies with `docker build`
+
+Once you've developed and tested your policy, apply it to real builds.
+
+### Basic usage
+
+Create a policy alongside your Dockerfile:
+
+```dockerfile {title="Dockerfile"}
+FROM alpine:3.19
+RUN echo "hello"
+```
+
+```rego {title="Dockerfile.rego"}
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+    input.image.repo == "alpine"
+}
+
+decision := {"allow": allow}
+```
+
+Build normally:
+
+```console
+$ docker buildx build .
+```
+
+Buildx loads the policy automatically and validates the `alpine:3.19` image
+before building.
+
+### Build with different Dockerfile names
+
+Specify the Dockerfile with `-f`:
+
+```console
+$ docker buildx build -f app.Dockerfile .
+```
+
+Buildx looks for `app.Dockerfile.rego` in the same directory.
+
+### Build with manual policy
+
+Add an extra policy to the automatic one:
+
+```console
+$ docker buildx build --policy filename=extra-checks.rego .
+```
+
+Both `Dockerfile.rego` (automatic) and `extra-checks.rego` (manual) must pass.
+
+### Build without automatic policy
+
+Use only your specified policy:
+
+```console
+$ docker buildx build --policy reset=true,filename=strict.rego .
+```
+
+## Using policies with bake
+
+[Bake](/build/bake/) supports automatic policy loading just like `docker buildx
+build`. Place `Dockerfile.rego` alongside your Dockerfile and run:
+
+```console
+$ docker buildx bake
+```
+
+### Manual policy in bake files
+
+Specify additional policies in your `docker-bake.hcl`:
+
+```hcl {title="docker-bake.hcl"}
+target "default" {
+  dockerfile = "Dockerfile"
+  policy = ["extra.rego"]
+}
+```
+
+The `policy` attribute takes a list of policy files. Bake loads these in
+addition to the automatic `Dockerfile.rego` (if it exists).
+
+### Multiple policies in bake
+
+```hcl {title="docker-bake.hcl"}
+target "webapp" {
+  dockerfile = "Dockerfile"
+  policy = [
+    "shared/base-policy.rego",
+    "security/image-signing.rego"
+  ]
+}
+```
+
+All policies must pass for the target to build successfully.
+
+### Different policies per target
+
+Apply different validation rules to different targets:
+
+```hcl {title="docker-bake.hcl"}
+target "development" {
+  dockerfile = "dev.Dockerfile"
+  policy = ["policies/permissive.rego"]
+}
+
+target "production" {
+  dockerfile = "prod.Dockerfile"
+  policy = ["policies/strict.rego", "policies/signing-required.rego"]
+}
+```
+
+Build with the appropriate target:
+
+```console
+$ docker buildx bake development  # Uses permissive policy
+$ docker buildx bake production   # Uses strict policies
+```
+
+### Bake with policy options
+
+Currently, bake doesn't support policy options (reset, strict, disabled) in the
+HCL file. Use command-line flags instead:
+
+```console
+$ docker buildx bake --policy disabled=true production
+```
+
+## Testing in CI/CD
+
+Validate policies in continuous integration by running builds with the `--policy` flag. For unit testing policies before running builds, see [Test build policies](./testing.md).
+
+Test policies during CI builds:
+
+```yaml {title=".github/workflows/test-policies.yml"}
+name: Test Build Policies
+on: [push, pull_request]
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@{{% param "checkout_action_version" %}}
+      - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
+      - name: Test build with policy
+        run: docker buildx build --policy strict=true .
+```
+
+This ensures policy changes don't break builds and that new rules work as
+intended. The `strict=true` flag fails the build if policies aren't loaded (for
+example, if the BuildKit instance used by the build is too old and doesn't
+support policies).
+
+## Advanced: Policy configuration
+
+This section covers advanced policy loading mechanisms and configuration
+options.
+
+### Automatic policy loading
+
+Buildx automatically loads policies that match your Dockerfile name. When you
+build with `Dockerfile`, Buildx looks for `Dockerfile.rego` in the same
+directory. For a file named `app.Dockerfile`, it looks for
+`app.Dockerfile.rego`.
+
+```text
+project/
+├── Dockerfile
+├── Dockerfile.rego          # Loaded automatically for Dockerfile
+├── app.Dockerfile
+├── app.Dockerfile.rego      # Loaded automatically for app.Dockerfile
+└── src/
+```
+
+This automatic loading means you don't need command-line flags in most cases.
+Create the policy file alongside your Dockerfile and build:
+
+```console
+$ docker buildx build .
+```
+
+Buildx detects `Dockerfile.rego` and evaluates it before running the build.
+
+> [!NOTE]
+> Policy files must be in the same directory as the Dockerfile they validate.
+> Buildx doesn't search parent directories or subdirectories.
+
+### When policies don't load
+
+If buildx can't find a matching `.rego` file, the build proceeds without policy
+evaluation. To require policies and fail if none are found, use strict mode:
+
+```console
+$ docker buildx build --policy strict=true .
+```
+
+This fails the build if no policy loads or if the BuildKit daemon doesn't
+support policies.
+
+### Manual policy configuration
+
+The `--policy` flag lets you specify additional policies, override automatic
+loading, or control policy behavior.
+
+Basic syntax:
+
+```console
+$ docker buildx build --policy filename=custom.rego .
+```
+
+This loads `custom.rego` in addition to the automatic `Dockerfile.rego` (if it
+exists).
+
+Multiple policies:
+
+```console
+$ docker buildx build --policy filename=policy1.rego --policy filename=policy2.rego .
+```
+
+All policies must pass for the build to succeed. Use this to enforce layered
+requirements (base policy + project-specific rules).
+
+Available options:
+
+| Option              | Description                                             | Example                       |
+| ------------------- | ------------------------------------------------------- | ----------------------------- |
+| `filename=<path>`   | Load policy from specified file                         | `filename=custom.rego`        |
+| `reset=true`        | Ignore automatic policies, use only specified ones      | `reset=true`                  |
+| `disabled=true`     | Disable all policy evaluation                           | `disabled=true`               |
+| `strict=true`       | Fail if BuildKit doesn't support policies               | `strict=true`                 |
+| `log-level=<level>` | Control policy logging (error, warn, info, debug, none). Use `debug` to see complete input JSON and unresolved fields | `log-level=debug`             |
+
+Combine options with commas:
+
+```console
+$ docker buildx build --policy filename=extra.rego,strict=true .
+```
+
+### Exploring sources with policy eval
+
+The `docker buildx policy eval` command lets you quickly explore and test
+sources without running a build.
+
+#### Inspect input structure with --print
+
+Use `--print` to see the input structure for any source without running policy
+evaluation:
+
+```console
+$ docker buildx policy eval --print https://github.com/moby/buildkit.git
+```
+
+```json
+{
+  "git": {
+    "schema": "https",
+    "host": "github.com",
+    "remote": "https://github.com/moby/buildkit.git"
+  }
+}
+```
+
+Test different source types:
+
+```console
+# HTTP downloads
+$ docker buildx policy eval --print https://releases.hashicorp.com/terraform/1.5.0/terraform.zip
+
+# Images (requires docker-image:// prefix)
+$ docker buildx policy eval --print docker-image://alpine:3.19
+
+# Local context
+$ docker buildx policy eval --print .
+```
+
+Shows information parsed from the source without fetching. Use `--fields` to
+fetch specific metadata (see [above](#testing-policies-with-policy-eval)).
+
+#### Test with specific policy files
+
+The `--filename` flag specifies which policy file to load by providing the base
+Dockerfile name (without the `.rego` extension). This is useful for testing
+sources against policies associated with different Dockerfiles.
+
+For example, to test a source against the policy for `app.Dockerfile`:
+
+```console
+$ docker buildx policy eval --filename app.Dockerfile .
+```
+
+This loads `app.Dockerfile.rego` and tests whether it allows the source `.`
+(the local directory). The flag defaults to `Dockerfile` if not specified.
+
+Test different sources against your policy:
+
+```console
+$ docker buildx policy eval --filename app.Dockerfile https://github.com/org/repo.git
+$ docker buildx policy eval --filename app.Dockerfile docker-image://alpine:3.19
+```
+
+### Reset automatic loading
+
+To use only your specified policies and ignore automatic `.rego` files:
+
+```console
+$ docker buildx build --policy reset=true,filename=custom.rego .
+```
+
+This skips `Dockerfile.rego` and loads only `custom.rego`.
+
+### Disable policies temporarily
+
+Disable policy evaluation for testing or emergencies:
+
+```console
+$ docker buildx build --policy disabled=true .
+```
+
+The build proceeds without any policy checks. Use this carefully - you're
+bypassing security controls.
+
+## Next steps
+
+- Write unit tests for your policies: [Test build policies](./testing.md)
+- Debug policy failures: [Debugging](./debugging.md)
+- Browse working examples: [Example policies](./examples.md)
+- Reference all input fields: [Input reference](./inputs.md)
diff --git a/content/manuals/build/policies/validate-git.md b/content/manuals/build/policies/validate-git.md
new file mode 100644
index 000000000000..98ebf6a52e70
--- /dev/null
+++ b/content/manuals/build/policies/validate-git.md
@@ -0,0 +1,431 @@
+---
+title: Validating Git repositories
+linkTitle: Git validation
+description: Write policies to validate Git repositories used in your builds
+keywords: build policies, git validation, git signatures, gpg, signed commits, signed tags
+weight: 40
+---
+
+Git repositories often appear in Docker builds as source code inputs. The `ADD`
+instruction can clone repositories, and build contexts can reference Git URLs.
+Validating these inputs ensures you're building from trusted sources with
+verified versions.
+
+This guide teaches you to write policies that validate Git inputs, from basic
+version pinning to verifying signed commits and tags.
+
+## Prerequisites
+
+You should understand the policy basics from the [Introduction](./intro.md):
+creating policy files, basic Rego syntax, and how policies evaluate during
+builds.
+
+## What are Git inputs?
+
+Git inputs come from `ADD` instructions that reference Git repositories:
+
+```dockerfile
+# Clone a specific tag
+ADD https://github.com/moby/buildkit.git#v0.26.1 /buildkit
+
+# Clone a branch
+ADD https://github.com/user/repo.git#main /src
+
+# Clone a commit
+ADD https://github.com/user/repo.git#abcde123 /src
+```
+
+The build context can also be a Git repository when you build with:
+
+```console
+$ docker build https://github.com/user/repo.git#main
+```
+
+Each Git reference triggers a policy evaluation. Your policy can inspect
+repository URLs, validate versions, check commit metadata, and verify
+signatures.
+
+## Match specific repositories
+
+The simplest Git policy restricts which repositories can be used:
+
+```rego {title="Dockerfile.rego"}
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+  input.git.host == "github.com"
+  input.git.remote == "https://github.com/moby/buildkit.git"
+}
+
+decision := {"allow": allow}
+```
+
+This policy:
+
+- Denies all inputs by default
+- Allows local build context
+- Allows only the BuildKit repository from GitHub
+
+The `host` field contains the Git server hostname, and `remote` contains the
+full repository URL. Test it:
+
+```dockerfile {title="Dockerfile"}
+FROM scratch
+ADD https://github.com/moby/buildkit.git#v0.26.1 /
+```
+
+```console
+$ docker build .
+```
+
+The build succeeds. Try a different repository and it fails.
+
+You can match multiple repositories with additional rules:
+
+```rego
+allow if {
+  input.git.host == "github.com"
+  input.git.remote == "https://github.com/moby/buildkit.git"
+}
+
+allow if {
+  input.git.host == "github.com"
+  input.git.remote == "https://github.com/docker/cli.git"
+}
+
+decision := {"allow": allow}
+```
+
+## Pin to specific versions
+
+Tags and branches can change over time. Pin to specific versions to ensure
+reproducible builds:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+  input.git.remote == "https://github.com/moby/buildkit.git"
+  input.git.tagName == "v0.26.1"
+}
+
+decision := {"allow": allow}
+```
+
+The `tagName` field contains the tag name when the Git reference points to a
+tag. Use `branch` for branches:
+
+```rego
+allow if {
+  input.git.remote == "https://github.com/user/repo.git"
+  input.git.branch == "main"
+}
+```
+
+Or use `ref` for any type of reference (branch, tag, or commit SHA):
+
+```rego
+allow if {
+  input.git.ref == "v0.26.1"
+}
+```
+
+## Use version allowlists
+
+For repositories you trust but want to control versions, maintain an allowlist:
+
+```rego
+package docker
+
+default allow := false
+
+allowed_versions = [
+    {"tag": "v0.26.1", "annotated": true, "sha": "abc123"},
+]
+
+is_buildkit if {
+    input.git.remote == "https://github.com/moby/buildkit.git"
+}
+
+allow if {
+    not is_buildkit
+}
+
+allow if {
+    is_buildkit
+    some version in allowed_versions
+    input.git.tagName == version.tag
+    input.git.isAnnotatedTag == version.annotated
+    startswith(input.git.commitChecksum, version.sha)
+}
+
+decision := {"allow": allow}
+```
+
+This policy:
+
+- Defines an allowlist of approved versions with metadata
+- Uses a helper rule (`is_buildkit`) for readability
+- Allows all non-BuildKit inputs
+- For BuildKit, checks the tag name, whether it's an annotated tag, and the commit SHA against the allowlist
+
+The helper rule makes complex policies more maintainable. You can expand the
+allowlist as new versions are approved:
+
+```rego
+allowed_versions = [
+    {"tag": "v0.26.1", "annotated": true, "sha": "abc123"},
+    {"tag": "v0.27.0", "annotated": true, "sha": "def456"},
+    {"tag": "v0.27.1", "annotated": true, "sha": "789abc"},
+]
+```
+
+## Validate with regex patterns
+
+Use pattern matching for semantic versioning:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+  input.git.remote == "https://github.com/moby/buildkit.git"
+  regex.match(`^v[0-9]+\.[0-9]+\.[0-9]+$`, input.git.tagName)
+}
+
+decision := {"allow": allow}
+```
+
+This allows any BuildKit tag matching the pattern `vX.Y.Z` where X, Y, and Z
+are numbers. The regex ensures you're using release versions, not pre-release
+tags like `v0.26.0-rc1`.
+
+Match major versions:
+
+```rego
+# Only allow v0.x releases
+allow if {
+  input.git.remote == "https://github.com/moby/buildkit.git"
+  regex.match(`^v0\.[0-9]+\.[0-9]+$`, input.git.tagName)
+}
+```
+
+## Inspect commit metadata
+
+The `commit` object provides detailed information about commits:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# Check commit author
+allow if {
+  input.git.remote == "https://github.com/user/repo.git"
+  input.git.commit.author.email == "trusted@example.com"
+}
+
+decision := {"allow": allow}
+```
+
+The `commit` object includes:
+
+- `author.name`: Author's name
+- `author.email`: Author's email
+- `author.when`: When the commit was authored
+- `committer.name`: Committer's name
+- `committer.email`: Committer's email
+- `committer.when`: When the commit was committed
+- `message`: Commit message
+
+Validate commit messages:
+
+```rego
+allow if {
+  input.git.commit
+  contains(input.git.commit.message, "Signed-off-by:")
+}
+```
+
+Pin to specific commit SHA:
+
+```rego
+allow if {
+  input.git.commitChecksum == "abc123def456..."
+}
+```
+
+## Require signed commits
+
+GPG-signed commits prove authenticity. Check for commit signatures:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+  input.git.remote == "https://github.com/moby/buildkit.git"
+  input.git.commit.pgpSignature != null
+}
+
+decision := {"allow": allow}
+```
+
+The `pgpSignature` field is `null` for unsigned commits. For signed commits, it
+contains signature details.
+
+SSH signatures work similarly:
+
+```rego
+allow if {
+  input.git.commit.sshSignature != null
+}
+```
+
+## Require signed tags
+
+Annotated tags can be signed, providing a cryptographic guarantee of the
+release:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+  input.git.remote == "https://github.com/moby/buildkit.git"
+  input.git.tag.pgpSignature != null
+}
+
+decision := {"allow": allow}
+```
+
+The `tag` object is only available for annotated tags. It includes:
+
+- `tagger.name`: Who created the tag
+- `tagger.email`: Tagger's email
+- `tagger.when`: When the tag was created
+- `message`: Tag message
+- `pgpSignature`: GPP signature (if signed)
+- `sshSignature`: SSH signature (if signed)
+
+Lightweight tags don't have a `tag` object, so this policy effectively requires
+annotated, signed tags.
+
+## Verify signatures with public keys
+
+Use the `verify_git_signature()` function to cryptographically verify Git
+signatures against trusted public keys:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+  input.git.remote == "https://github.com/moby/buildkit.git"
+  input.git.tagName != ""
+  verify_git_signature(input.git.tag, "keys.asc")
+}
+
+decision := {"allow": allow}
+```
+
+This verifies that Git tags are signed by keys in the `keys.asc` public
+key file. To set this up:
+
+1. Export maintainer public keys:
+   ```console
+   $ curl https://github.com/user.gpg > keys.asc
+   ```
+2. Place `keys.asc` alongside your policy file
+
+The function verifies PGP signatures on commits or tags. See [Built-in
+functions](./built-ins.md) for more details.
+
+## Apply conditional rules
+
+Use different rules for different contexts. Allow unsigned refs during
+development but require signing for production:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+is_buildkit if {
+    input.git.remote == "https://github.com/moby/buildkit.git"
+}
+
+is_version_tag if {
+    is_buildkit
+    regex.match(`^v[0-9]+\.[0-9]+\.[0-9]+$`, input.git.tagName)
+}
+
+# Version tags must be signed
+allow if {
+    is_version_tag
+    input.git.tagName != ""
+    verify_git_signature(input.git.tag, "keys.asc")
+}
+
+# Non-version refs allowed in development
+allow if {
+    is_buildkit
+    not is_version_tag
+    input.env.target != "release"
+}
+
+decision := {"allow": allow}
+```
+
+This policy:
+
+- Defines helper rules for readability
+- Requires signed version tags from maintainers
+- Allows unsigned refs (branches, commits) unless building the release target
+- Uses `input.env.target` to detect the build target
+
+Build a development target without signatures:
+
+```console
+$ docker buildx build --target=dev .
+```
+
+Build the release target, and signing is enforced:
+
+```console
+$ docker buildx build --target=release .
+```
+
+## Next steps
+
+You now understand how to validate Git repositories in build policies. To
+continue learning:
+
+- Browse [Example policies](./examples.md) for complete policy patterns
+- Read [Built-in functions](./built-ins.md) for Git signature verification
+  functions
+- Check the [Input reference](./inputs.md) for all available Git fields
diff --git a/content/manuals/build/policies/validate-images.md b/content/manuals/build/policies/validate-images.md
new file mode 100644
index 000000000000..3f4b4dd951a5
--- /dev/null
+++ b/content/manuals/build/policies/validate-images.md
@@ -0,0 +1,424 @@
+---
+title: Validating image inputs
+linkTitle: Image validation
+description: Write policies to validate container images used in your builds
+keywords: build policies, image validation, docker images, provenance, attestations, signatures
+weight: 30
+---
+
+Container images are the most common build inputs. Every `FROM` instruction
+pulls an image, and `COPY --from` references pull additional images. Validating
+these images protects your build supply chain from compromised registries,
+unexpected updates, and unauthorized base images.
+
+This guide teaches you to write policies that validate image inputs,
+progressing from basic allowlisting to advanced attestation checks.
+
+## Prerequisites
+
+You should understand the policy basics from the [Introduction](./intro.md):
+creating policy files, basic Rego syntax, and how policies evaluate during
+builds.
+
+## What are image inputs?
+
+Image inputs come from two Dockerfile instructions:
+
+```dockerfile
+# FROM instructions
+FROM alpine:3.22
+FROM golang:1.25-alpine AS builder
+
+# COPY --from references
+COPY --from=builder /app /app
+COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf
+```
+
+Each of these references triggers a policy evaluation. Your policy can inspect
+image metadata, verify attestations, and enforce constraints before the build
+proceeds.
+
+## Allowlist specific repositories
+
+The simplest image policy restricts which repositories can be used. This
+prevents developers from using arbitrary images that haven't been vetted.
+
+Create a policy that only allows Alpine:
+
+```rego {title="Dockerfile.rego"}
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+  input.image.repo == "alpine"
+}
+
+decision := {"allow": allow}
+```
+
+This policy:
+
+- Denies all inputs by default
+- Allows local build context
+- Allows any image from the `alpine` repository (any tag or digest)
+
+Test it with a Dockerfile:
+
+```dockerfile {title="Dockerfile"}
+FROM alpine
+RUN echo "hello"
+```
+
+```console
+$ docker build .
+```
+
+The build succeeds. Try changing to `FROM ubuntu`:
+
+```console
+$ docker build .
+```
+
+The build fails because `ubuntu` doesn't match the allowed repository.
+
+## Compare semantic versions
+
+Restrict images to specific version ranges using Rego's `semver` functions:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# Allow Go 1.21 or newer
+allow if {
+  input.image.repo == "golang"
+  semver.is_valid(input.image.tag)
+  semver.compare(input.image.tag, "1.21.0") >= 0
+}
+
+decision := {"allow": allow}
+```
+
+The `semver.compare(a, b)` function compares semantic versions and returns:
+
+- `-1` if version `a` is less than `b`
+- `0` if versions are equal
+- `1` if version `a` is greater than `b`
+
+Use `semver.is_valid()` to check if a tag is a valid semantic version before
+comparing.
+
+Restrict to specific version ranges:
+
+```rego
+allow if {
+  input.image.repo == "node"
+  version := input.image.tag
+  semver.is_valid(version)
+  semver.compare(version, "20.0.0") >= 0  # 20.0.0 or newer
+  semver.compare(version, "21.0.0") < 0   # older than 21.0.0
+}
+```
+
+This allows only Node.js 20.x versions. The pattern works for any image using
+semantic versioning.
+
+These `semver` functions are standard Rego built-ins documented in the [OPA
+policy
+reference](https://www.openpolicyagent.org/docs/latest/policy-reference/#semver).
+
+## Require digest references
+
+Tags like `alpine:3.22` can change - someone could push a new image with the
+same tag. Digests like `alpine@sha256:abc123...` are immutable.
+
+### Requiring users to provide digests
+
+You can require that users always specify digests in their Dockerfiles:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+  input.image.isCanonical
+}
+
+decision := {"allow": allow}
+```
+
+The `isCanonical` field is `true` when the user's reference includes a digest.
+This policy would allow:
+
+```dockerfile
+FROM alpine@sha256:4b7ce07002c69e8f3d704a9c5d6fd3053be500b7f1c69fc0d80990c2ad8dd412
+```
+
+But reject tag-only references like `FROM alpine:3.22`.
+
+### Pinning to specific digests
+
+Alternatively (or additionally), you can validate that an image's actual digest
+matches a specific value, regardless of how the user wrote the reference:
+
+```rego
+allow if {
+  input.image.repo == "alpine"
+  input.image.checksum == "sha256:4b7ce07002c69e8f3d704a9c5d6fd3053be500b7f1c69fc0d80990c2ad8dd412"
+}
+
+decision := {"allow": allow}
+```
+
+This checks the actual content digest of the pulled image. It would allow both:
+
+```dockerfile
+FROM alpine:3.22
+FROM alpine@sha256:4b7ce...
+```
+
+As long as the resolved image has the specified digest. This is useful for
+pinning critical base images to known-good versions.
+
+## Restrict registries
+
+Control which registries your builds can pull from. This helps enforce
+corporate policies or restrict to trusted sources.
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# Allow Docker Hub images
+allow if {
+  input.image.host == "docker.io"  # Docker Hub
+  input.image.repo == "alpine"
+}
+
+# Allow images from internal registry
+allow if {
+  input.image.host == "registry.company.com"
+}
+
+decision := {"allow": allow}
+```
+
+The `host` field contains the registry hostname. Docker Hub images use
+`"docker.io"` as the host value. Test with:
+
+```dockerfile
+FROM alpine                                    # Allowed (Docker Hub)
+FROM registry.company.com/myapp:latest         # Allowed (company registry)
+FROM ghcr.io/someorg/image:latest              # Denied (wrong registry)
+```
+
+Use `fullRepo` when you need the complete path including registry:
+
+```rego
+allow if {
+  input.image.fullRepo == "docker.io/library/alpine"
+}
+```
+
+## Validate platform constraints
+
+Multi-architecture images support different operating systems and CPU
+architectures. You can restrict builds to specific platforms:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+  input.image.os == "linux"
+  input.image.arch in ["amd64", "arm64"]
+}
+
+decision := {"allow": allow}
+```
+
+This policy:
+
+- Defines supported architectures in a list
+- Checks `input.image.os` matches Linux
+- Verifies `input.image.arch` is in the supported list
+
+The `os` and `arch` fields come from the image manifest, reflecting the actual
+image platform. This works with Docker's automatic platform selection -
+policies validate what Buildx resolves, not what you specify.
+
+## Inspect image metadata
+
+Images contain metadata like environment variables, labels, and working
+directories. You can validate these to ensure images meet requirements.
+
+Check for specific environment variables:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+  input.image.repo == "golang"
+  input.image.workingDir == "/go"
+  some ver in input.image.env
+  startswith(ver, "GOLANG_VERSION=")
+  some toolchain in input.image.env
+  toolchain == "GOTOOLCHAIN=local"
+}
+
+decision := {"allow": allow}
+```
+
+This policy validates the official Go image by checking:
+
+- The working directory is `/go`
+- The environment has `GOLANG_VERSION` set
+- The environment includes `GOTOOLCHAIN=local`
+
+The `input.image.env` field is an array of strings in `KEY=VALUE` format.
+Use Rego's `some` iteration to search the array.
+
+Check image labels:
+
+```rego
+allow if {
+  input.image.labels["org.opencontainers.image.vendor"] == "Example Corp"
+  input.image.labels["org.opencontainers.image.version"] != ""
+}
+```
+
+The `labels` field is a map, so you access values with bracket notation.
+
+## Require attestations and provenance
+
+Modern images include [attestations](/build/metadata/attestations/):
+machine-readable metadata about how the image was built.
+[Provenance](/build/metadata/attestations/slsa-provenance/) attestations
+describe the build process, and [SBOMs](/build/metadata/attestations/sbom/)
+list the software inside.
+
+Require provenance:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+allow if {
+  input.image.hasProvenance
+}
+
+decision := {"allow": allow}
+```
+
+The `hasProvenance` field is `true` when the image has provenance or SBOM
+[attestations](../metadata/attestations/_index.md).
+
+## Verify GitHub Actions signatures
+
+For images built with GitHub Actions, verify they came from trusted workflows by
+inspecting signature metadata:
+
+```rego
+allow if {
+  input.image.repo == "myapp"
+  input.image.hasProvenance
+  some sig in input.image.signatures
+  valid_github_signature(sig)
+}
+
+# Helper to validate GitHub Actions signature
+valid_github_signature(sig) if {
+  sig.signer.certificateIssuer == "CN=sigstore-intermediate,O=sigstore.dev"
+  sig.signer.issuer == "https://token.actions.githubusercontent.com"
+  startswith(sig.signer.buildSignerURI, "https://github.com/myorg/")
+  sig.signer.runnerEnvironment == "github-hosted"
+}
+
+decision := {"allow": allow}
+```
+
+This pattern works with any GitHub Actions workflow using Sigstore keyless
+signing. The signature metadata provides cryptographic proof of the build's
+origin. For complete signature verification examples, see [Example
+policies](./examples.md).
+
+## Combine multiple checks
+
+Real policies often combine several checks. Multiple conditions in one `allow`
+rule means AND - all must be true:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# Production images need everything
+allow if {
+  input.image.repo == "alpine"
+  input.image.isCanonical
+  input.image.hasProvenance
+}
+
+decision := {"allow": allow}
+```
+
+Multiple `allow` rules means OR - any rule can match:
+
+```rego
+package docker
+
+default allow := false
+
+allow if input.local
+
+# Allow Alpine with strict checks
+allow if {
+  input.image.repo == "alpine"
+  input.image.isCanonical
+}
+
+# Allow Go with different checks
+allow if {
+  input.image.repo == "golang"
+  input.image.workingDir == "/go"
+}
+
+decision := {"allow": allow}
+```
+
+Use this pattern to apply different requirements to different base images.
+
+## Next steps
+
+You now understand how to validate container images in build policies. To
+continue learning:
+
+- Learn [Git repository validation](./validate-git.md) for source code inputs
+- Browse [Example policies](./examples.md) for complete policy patterns
+- Read [Built-in functions](./built-ins.md) for signature verification and
+  attestation checking
+- Check the [Input reference](./inputs.md) for all available image fields
diff --git a/content/manuals/build/release-notes.md b/content/manuals/build/release-notes.md
index 14a60eef2e79..4b7b8e745326 100644
--- a/content/manuals/build/release-notes.md
+++ b/content/manuals/build/release-notes.md
@@ -1,1372 +1,7 @@
 ---
 title: Build release notes
 weight: 120
-description: Learn about the new features, bug fixes, and breaking changes for the newest Buildx release
-keywords: build, buildx, buildkit, release notes
-tags: [Release notes]
-toc_max: 2
----
-
-This page contains information about the new features, improvements, and bug
-fixes in [Docker Buildx](https://github.com/docker/buildx).
-
-## 0.23.0
-
-{{< release-date date="2025-04-15" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.23.0).
-
-### New
-
-- New `buildx history export` command allows exporting the build record into a bundle that can be imported to [Docker Desktop](/desktop/). [docker/buildx#3073](https://github.com/docker/buildx/pull/3073)
-
-### Enhancements
-
-- New `--local` and `--filter` flags allow filtering history records in `buildx history ls`. [docker/buildx#3091](https://github.com/docker/buildx/pull/3091)
-- Compose compatibility has been updated to v2.6.0. [docker/buildx#3080](https://github.com/docker/buildx/pull/3080), [docker/buildx#3105](https://github.com/docker/buildx/pull/3105)
-- Support CLI environment variables in standalone mode. [docker/buildx#3087](https://github.com/docker/buildx/pull/3087)
-
-### Bug fixes
-
-- Fix `--print` output for Bake producing output with unescaped variables that could cause build errors later. [docker/buildx#3097](https://github.com/docker/buildx/pull/3097)
-- Fix `additional_contexts` field not working correctly when pointing to another service. [docker/buildx#3090](https://github.com/docker/buildx/pull/3090)
-- Fix empty validation block crashing the Bake HCL parser. [docker/buildx#3101](https://github.com/docker/buildx/pull/3101)
-
-## 0.22.0
-
-{{< release-date date="2025-03-18" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.22.0).
-
-### New
-
-- New command `buildx history import` lets you import build records into Docker Desktop for further debugging in the [Build UI](/desktop/use-desktop/builds/). This command requires [Docker Desktop](/desktop/) to be installed. [docker/buildx#3039](https://github.com/docker/buildx/pull/3039)
-
-### Enhancements
-
-- History records can now be opened by offset from the latest in `history inspect`, `history logs` and `history open` commands (e.g. `^1`). [docker/buildx#3049](https://github.com/docker/buildx/pull/3049), [docker/buildx#3055](https://github.com/docker/buildx/pull/3055)
-- Bake now supports the `+=` operator to append when using `--set` for overrides. [docker/buildx#3031](https://github.com/docker/buildx/pull/3031)
-- Docker container driver adds GPU devices to the container if available. [docker/buildx#3063](https://github.com/docker/buildx/pull/3063)
-- Annotations can now be set when using overrides with Bake. [docker/buildx#2997](https://github.com/docker/buildx/pull/2997)
-- NetBSD binaries are now included in the release. [docker/buildx#2901](https://github.com/docker/buildx/pull/2901)
-- The `inspect` and `create` commands now return an error if a node fails to boot. [docker/buildx#3062](https://github.com/docker/buildx/pull/3062)
-
-### Bug fixes
-
-- Fix double pushing with Docker driver when the containerd image store is enabled. [docker/buildx#3023](https://github.com/docker/buildx/pull/3023)
-- Fix multiple tags being pushed for `imagetools create` command. Now only the final manifest pushes by tag. [docker/buildx#3024](https://github.com/docker/buildx/pull/3024)
-
-## 0.21.0
-
-{{< release-date date="2025-02-19" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.21.0).
-
-### New
-
-- New command `buildx history trace` lets you inspect traces of a build in a Jaeger UI-based viewer and compare one trace with another. [docker/buildx#2904](https://github.com/docker/buildx/pull/2904)
-
-### Enhancements
-
-- The history inspection command `buildx history inspect` now supports custom formatting with `--format` flag and JSON formatting for machine-readable output. [docker/buildx#2964](https://github.com/docker/buildx/pull/2964) 
-- Support for CDI device entitlement in build and bake. [docker/buildx#2994](https://github.com/docker/buildx/pull/2994)
-- Supported CDI devices are now shown in the builder inspection. [docker/buildx#2983](https://github.com/docker/buildx/pull/2983)
-- When using [GitHub Cache backend `type=gha`](cache/backends/gha.md), the URL for the Version 2 or API is now read from the environment and sent to BuildKit. Version 2 backend requires BuildKit v0.20.0 or later. [docker/buildx#2983](https://github.com/docker/buildx/pull/2983), [docker/buildx#3001](https://github.com/docker/buildx/pull/3001)
-
-### Bug fixes
-
-- Avoid unnecessary warnings and prompts when using `--progress=rawjson`. [docker/buildx#2957](https://github.com/docker/buildx/pull/2957)
-- Fix regression with debug shell sometimes not working correctly on `--on=error`. [docker/buildx#2958](https://github.com/docker/buildx/pull/2958)
-- Fix possible panic errors when using an unknown variable in the Bake definition. [docker/buildx#2960](https://github.com/docker/buildx/pull/2960)
-- Fix invalid duplicate output on JSON format formatting of `buildx ls` command. [docker/buildx#2970](https://github.com/docker/buildx/pull/2970)
-- Fix bake handling cache imports with CSV string containing multiple registry references. [docker/buildx#2944](https://github.com/docker/buildx/pull/2944)
-- Fix issue where error from pulling BuildKit image could be ignored. [docker/buildx#2988](https://github.com/docker/buildx/pull/2988)
-- Fix race on pausing progress on debug shell. [docker/buildx#3003](https://github.com/docker/buildx/pull/3003)
-
-## 0.20.1
-
-{{< release-date date="2025-01-23" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.20.1).
-
-### Bug fixes
-
-- Fix `bake --print` output after missing some attributes for attestations. [docker/buildx#2937](https://github.com/docker/buildx/pull/2937)
-- Fix allowing comma-separated image reference strings for cache import and export values. [docker/buildx#2944](https://github.com/docker/buildx/pull/2944)
-
-## 0.20.0
-
-{{< release-date date="2025-01-20" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.20.0).
-
-> [!NOTE]
->
-> This version of buildx enables filesystem entitlement checks for `buildx bake`
-> command by default. If your Bake definition needs to read or write files
-> outside your current working directory, you need to allow access to these
-> paths with `--allow fs=<path|*>`. On the terminal, you can also interactively
-> approve these paths with the provided prompt. Optionally, you can disable
-> these checks by setting `BUILDX_BAKE_ENTITLEMENTS_FS=0`. This validation
-> produced a warning in Buildx v0.19.0+, but starting from current release it
-> produces an error. For more information, see the [reference documentation](/reference/cli/docker/buildx/bake.md#allow).
-
-### New
-
-- New `buildx history` command has been added that allows working with build records of completed and running builds. You can use these commands to list, inspect, remove your builds, replay the logs of already completed builds, and quickly open your builds in Docker Desktop Build UI for further debugging. This is an early version of this command and we expect to add more features in the future releases. [#2891](https://github.com/docker/buildx/pull/2891), [#2925](https://github.com/docker/buildx/pull/2925)
-
-### Enhancements
-
-- Bake: Definition now supports new object notation for the fields that previously required CSV strings as inputs (`attest`, `output`, `cache-from`, `cache-to`, `secret`, `ssh`). [docker/buildx#2758](https://github.com/docker/buildx/pull/2758), [docker/buildx#2848](https://github.com/docker/buildx/pull/2848), [docker/buildx#2871](https://github.com/docker/buildx/pull/2871), [docker/buildx#2814](https://github.com/docker/buildx/pull/2814)
-- Bake: Filesystem entitlements now error by default. To disable this behavior, you can set `BUILDX_BAKE_ENTITLEMENTS_FS=0`. [docker/buildx#2875](https://github.com/docker/buildx/pull/2875)
-- Bake: Infer Git authentication token from remote files to build request. [docker/buildx#2905](https://github.com/docker/buildx/pull/2905)
-- Bake: Add support for `--list` flag to list targets and variables. [docker/buildx#2900](https://github.com/docker/buildx/pull/2900), [docker/buildx#2907](https://github.com/docker/buildx/pull/2907)
-- Bake: Update lookup order for default definition files to load the files with "override" suffix later. [docker/buildx#2886](https://github.com/docker/buildx/pull/2886)
-
-### Bug fixes
-
-- Bake: Fix entitlements check for default SSH socket. [docker/buildx#2898](https://github.com/docker/buildx/pull/2898)
-- Bake: Fix missing default target in group's default targets. [docker/buildx#2863](https://github.com/docker/buildx/pull/2863)
-- Bake: Fix named context from target platform matching. [docker/buildx#2877](https://github.com/docker/buildx/pull/2877)
-- Fix missing documentation for quiet progress mode. [docker/buildx#2899](https://github.com/docker/buildx/pull/2899)
-- Fix missing last progress from loading layers. [docker/buildx#2876](https://github.com/docker/buildx/pull/2876)
-- Validate BuildKit configuration before creating a builder. [docker/buildx#2864](https://github.com/docker/buildx/pull/2864)
-
-### Packaging
-
-- Compose compatibility has been updated to v2.4.7. [docker/buildx#2893](https://github.com/docker/buildx/pull/2893), [docker/buildx#2857](https://github.com/docker/buildx/pull/2857), [docker/buildx#2829](https://github.com/docker/buildx/pull/2829)
-
-## 0.19.1
-
-{{< release-date date="2024-11-27" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.19.1).
-
-### Bug fixes
-
-- Reverted the change in v0.19.0 that added new object notation for the fields
-  that previously required CSV strings in Bake definition. This enhancement was
-  reverted because of backwards incompatibility issues were discovered in some
-  edge cases. This feature has now been postponed to the v0.20.0 release.
-  [docker/buildx#2824](https://github.com/docker/buildx/pull/2824)
-
-## 0.19.0
-
-{{< release-date date="2024-11-27" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.19.0).
-
-### New
-
-- Bake now requires you to allow filesystem entitlements when your build needs
-  to read or write files outside of your current working directory.
-  [docker/buildx#2796](https://github.com/docker/buildx/pull/2796),
-  [docker/buildx#2812](https://github.com/docker/buildx/pull/2812).
-
-  To allow filesystem entitlements, use the `--allow fs.read=<path>` flag for
-  the `docker buildx bake` command.
-
-  This feature currently only reports a warning when using a local Bake
-  definition, but will start to produce an error starting from the v0.20
-  release. To enable the error in the current release, you can set
-  `BUILDX_BAKE_ENTITLEMENTS_FS=1`.
-
-### Enhancements
-
-- Bake definition now supports new object notation for the fields that previously required CSV strings as inputs. [docker/buildx#2758](https://github.com/docker/buildx/pull/2758)
-
-  > [!NOTE]
-  > This enhancement was reverted in [v0.19.1](#0191) due to a bug.
-
-- Bake definition now allows defining validation conditions to variables. [docker/buildx#2794](https://github.com/docker/buildx/pull/2794)
-- Metadata file values can now contain JSON array values. [docker/buildx#2777](https://github.com/docker/buildx/pull/2777)
-- Improved error messages when using an incorrect format for labels. [docker/buildx#2778](https://github.com/docker/buildx/pull/2778)
-- FreeBSD and OpenBSD artifacts are now included in the release. [docker/buildx#2774](https://github.com/docker/buildx/pull/2774), [docker/buildx#2775](https://github.com/docker/buildx/pull/2775), [docker/buildx#2781](https://github.com/docker/buildx/pull/2781)
-
-### Bug fixes
-
-- Fixed an issue with printing Bake definitions containing empty Compose networks. [docker/buildx#2790](https://github.com/docker/buildx/pull/2790).
-
-### Packaging
-
-- Compose support has been updated to v2.4.4. [docker/buildx#2806](https://github.com/docker/buildx/pull/2806) [docker/buildx#2780](https://github.com/docker/buildx/pull/2780).
-
-## 0.18.0
-
-{{< release-date date="2024-10-31" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.18.0).
-
-### New
-
-- The `docker buildx inspect` command now displays BuildKit daemon configuration options set with a TOML file. [docker/buildx#2684](https://github.com/docker/buildx/pull/2684)
-- The `docker buildx ls` command output is now more compact by default by compacting the platform list. A new `--no-trunc` option can be used for the full list. [docker/buildx#2138](https://github.com/docker/buildx/pull/2138), [docker/buildx#2717](https://github.com/docker/buildx/pull/2717)
-- The `docker buildx prune` command now supports new `--max-used-space` and `--min-free-space` filters with BuildKit v0.17.0+ builders. [docker/buildx#2766](https://github.com/docker/buildx/pull/2766)
-
-### Enhancements
-
-- Allow capturing of CPU and memory profiles with `pprof` using the [`BUILDX_CPU_PROFILE`](/manuals/build/building/variables.md#buildx_cpu_profile) and [`BUILDX_MEM_PROFILE`](/manuals/build/building/variables.md#buildx_mem_profile) environment variables. [docker/buildx#2746](https://github.com/docker/buildx/pull/2746)
-- Maximum Dockerfile size from standard input has increased. [docker/buildx#2716](https://github.com/docker/buildx/pull/2716), [docker/buildx#2719](https://github.com/docker/buildx/pull/2719)
-- Memory allocations have been reduced. [docker/buildx#2724](https://github.com/docker/buildx/pull/2724), [docker/buildx#2713](https://github.com/docker/buildx/pull/2713)
-- The `--list-targets` and `--list-variables` flags for `docker buildx bake` no longer require initialization of the builder. [docker/buildx#2763](https://github.com/docker/buildx/pull/2763)
-
-### Bug fixes
-
-- Check warnings now print the full filepath to the offending Dockerfile, relative to the current working directory. [docker/buildx#2672](https://github.com/docker/buildx/pull/2672)
-- Fallback images for the `--check` and `--call` options have been updated to correct references. [docker/buildx#2705](https://github.com/docker/buildx/pull/2705)
-- Fix issue with the build details link not showing in experimental mode. [docker/buildx#2722](https://github.com/docker/buildx/pull/2722)
-- Fix validation issue with invalid target linking for Bake. [docker/buildx#2700](https://github.com/docker/buildx/pull/2700)
-- Fix missing error message when running an invalid command. [docker/buildx#2741](https://github.com/docker/buildx/pull/2741)
-- Fix possible false warnings for local state in `--call` requests. [docker/buildx#2754](https://github.com/docker/buildx/pull/2754)
-- Fix potential issues with entitlements when using linked targets in Bake. [docker/buildx#2701](https://github.com/docker/buildx/pull/2701)
-- Fix possible permission issues when accessing local state after running Buildx with `sudo`. [docker/buildx#2745](https://github.com/docker/buildx/pull/2745)
-
-### Packaging
-
-- Compose compatibility has been updated to v2.4.1. [docker/buildx#2760](https://github.com/docker/buildx/pull/2760)
-
-## 0.17.1
-
-{{< release-date date="2024-09-13" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.17.1).
-
-### Bug fixes
-
-- Do not set `network.host` entitlement flag automatically on builder creation
-  for the `docker-container` and `kubernetes` drivers if the entitlement is set
-  in the [BuildKit configuration file](/manuals/build/buildkit/toml-configuration.md). [docker/buildx#2685]
-- Do not print the `network` field with `docker buildx bake --print` when empty. [docker/buildx#2689]
-- Fix telemetry socket path under WSL2. [docker/buildx#2698]
-
-[docker/buildx#2685]: https://github.com/docker/buildx/pull/2685
-[docker/buildx#2689]: https://github.com/docker/buildx/pull/2689
-[docker/buildx#2698]: https://github.com/docker/buildx/pull/2698
-
-## 0.17.0
-
-{{< release-date date="2024-09-10" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.17.0).
-
-### New
-
-- Add `basename`, `dirname` and `sanitize` functions to Bake. [docker/buildx#2649]
-- Enable support for Bake entitlements to allow privileged operations during builds. [docker/buildx#2666]
-
-### Enhancements
-
-- Introduce CLI metrics tracking for Bake commands. [docker/buildx#2610]
-- Add `--debug` to all build commands. Previously, it was only available on the top-level `docker` and `docker buildx` commands. [docker/buildx#2660]
-- Allow builds from stdin for multi-node builders. [docker/buildx#2656]
-- Improve `kubernetes` driver initialization. [docker/buildx#2606]
-- Include target name in the error message when building multiple targets with Bake. [docker/buildx#2651]
-- Optimize metrics handling to reduce performance overhead during progress tracking. [docker/buildx#2641]
-- Display the number of warnings after completing a rule check. [docker/buildx#2647]
-- Skip build ref and provenance metadata for frontend methods. [docker/buildx#2650]
-- Add support for setting network mode in Bake files (HCL and JSON). [docker/buildx#2671]
-- Support the `--metadata-file` flag when set along the `--call` flag. [docker/buildx#2640]
-- Use shared session for local contexts used by multiple Bake targets. [docker/buildx#2615], [docker/buildx#2607], [docker/buildx#2663]
-
-### Bug fixes
-
-- Improve memory management to avoid unnecessary allocations. [docker/buildx#2601]
-
-### Packaging updates
-
-- Compose support has been updated to v2.1.6. [docker/buildx#2547]
-
-[docker/buildx#2547]: https://github.com/docker/buildx/pull/2547/
-[docker/buildx#2601]: https://github.com/docker/buildx/pull/2601/
-[docker/buildx#2606]: https://github.com/docker/buildx/pull/2606/
-[docker/buildx#2607]: https://github.com/docker/buildx/pull/2607/
-[docker/buildx#2610]: https://github.com/docker/buildx/pull/2610/
-[docker/buildx#2615]: https://github.com/docker/buildx/pull/2615/
-[docker/buildx#2640]: https://github.com/docker/buildx/pull/2640/
-[docker/buildx#2641]: https://github.com/docker/buildx/pull/2641/
-[docker/buildx#2647]: https://github.com/docker/buildx/pull/2647/
-[docker/buildx#2649]: https://github.com/docker/buildx/pull/2649/
-[docker/buildx#2650]: https://github.com/docker/buildx/pull/2650/
-[docker/buildx#2651]: https://github.com/docker/buildx/pull/2651/
-[docker/buildx#2656]: https://github.com/docker/buildx/pull/2656/
-[docker/buildx#2660]: https://github.com/docker/buildx/pull/2660/
-[docker/buildx#2663]: https://github.com/docker/buildx/pull/2663/
-[docker/buildx#2666]: https://github.com/docker/buildx/pull/2666/
-[docker/buildx#2671]: https://github.com/docker/buildx/pull/2671/
-
-## 0.16.2
-
-{{< release-date date="2024-07-25" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.16.2).
-
-### Bug fixes
-
-- Fix possible "bad file descriptor" error when exporting local cache to NFS volume [docker/buildx#2629](https://github.com/docker/buildx/pull/2629/)
-
-## 0.16.1
-
-{{< release-date date="2024-07-18" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.16.1).
-
-### Bug fixes
-
-- Fix possible panic due to data race in `buildx bake --print` command [docker/buildx#2603](https://github.com/docker/buildx/pull/2603/)
-- Improve messaging about using `--debug` flag to inspect build warnings [docker/buildx#2612](https://github.com/docker/buildx/pull/2612/)
-
-## 0.16.0
-
-{{< release-date date="2024-07-11" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.16.0).
-
-### New
-
-- Bake command now supports `--call` and `--check` flags and `call` attribute in target definitions for selecting custom frontend methods. [docker/buildx#2556](https://github.com/docker/buildx/pull/2556/), [docker/buildx#2576](https://github.com/docker/buildx/pull/2576/)
-- {{< badge color=violet text=Experimental >}} Bake now supports `--list-targets` and `--list-variables` flags for inspecting the definition and possible configuration options for your project. [docker/buildx#2556](https://github.com/docker/buildx/pull/2556/)
-- Bake definition variables and targets supports new `description` attribute for defining text-based description that can be inspected using e.g. `--list-targets` and `--list-variables`. [docker/buildx#2556](https://github.com/docker/buildx/pull/2556/)
-- Bake now supports printing warnings for build check violations. [docker/buildx#2501](https://github.com/docker/buildx/pull/2501/)
-
-### Enhancements
-
-- The build command now ensures that multi-node builds use the same build reference for each node. [docker/buildx#2572](https://github.com/docker/buildx/pull/2572/)
-- Avoid duplicate requests and improve the performance of remote driver. [docker/buildx#2501](https://github.com/docker/buildx/pull/2501/)
-- Build warnings can now be saved to the metadata file by setting the `BUILDX_METADATA_WARNINGS=1` environment variable. [docker/buildx#2551](https://github.com/docker/buildx/pull/2551/), [docker/buildx#2521](https://github.com/docker/buildx/pull/2521/), [docker/buildx#2550](https://github.com/docker/buildx/pull/2550/)
-- Improve message of the `--check` flag when no warnings are detected. [docker/buildx#2549](https://github.com/docker/buildx/pull/2549/)
-
-### Bug fixes
-
-- Fix support for multi-type annotations during build. [docker/buildx#2522](https://github.com/docker/buildx/pull/2522/)
-- Fix a regression where possible inefficient transfer of files would occur when switching projects due to incremental transfer reuse. [docker/buildx#2558](https://github.com/docker/buildx/pull/2558/)
-- Fix incorrect default load for chained Bake targets. [docker/buildx#2583](https://github.com/docker/buildx/pull/2583/)
-- Fix incorrect `COMPOSE_PROJECT_NAME` handling in Bake. [docker/buildx#2579](https://github.com/docker/buildx/pull/2579/)
-- Fix index annotations support for multi-node builds. [docker/buildx#2546](https://github.com/docker/buildx/pull/2546/)
-- Fix capturing provenance metadata for builds from remote context. [docker/buildx#2560](https://github.com/docker/buildx/pull/2560/)
-
-### Packaging updates
-
-- Compose support has been updated to v2.1.3. [docker/buildx#2547](https://github.com/docker/buildx/pull/2547/)
-
-## 0.15.1
-
-{{< release-date date="2024-06-18" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.15.1).
-
-### Bug fixes
-
-- Fix missing build error and exit code for some validation requests with `--check`. [docker/buildx#2518](https://github.com/docker/buildx/pull/2518/)
-- Update fallback image for `--check` to Dockerfile v1.8.1. [docker/buildx#2538](https://github.com/docker/buildx/pull/2538/)
-
-## 0.15.0
-
-{{< release-date date="2024-06-11" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.15.0).
-
-### New
-
-- New `--call` option allows setting evaluation method for a build, replacing the previous experimental `--print` flag. [docker/buildx#2498](https://github.com/docker/buildx/pull/2498/), [docker/buildx#2487](https://github.com/docker/buildx/pull/2487/), [docker/buildx#2513](https://github.com/docker/buildx/pull/2513/)
-
-  In addition to the default `build` method, the following methods are implemented by Dockerfile frontend:
-
-  - [`--call=check`](/reference/cli/docker/buildx/build.md#check): Run validation routines for your build configuration. For more information about build checks, see [Build checks](/manuals/build/checks.md)
-  - [`--call=outline`](/reference/cli/docker/buildx/build.md#call-outline): Show configuration that would be used by current build, including all build arguments, secrets, SSH mounts, etc., that your build would use.
-  - [`--call=targets`](/reference/cli/docker/buildx/build.md#call-targets): Show all available targets and their descriptions.
-
-- New `--prefer-index` flag has been added to the `docker buildx imagetools create` command to control the behavior of creating image out of one single-platform image manifest. [docker/buildx#2482](https://github.com/docker/buildx/pull/2482/)
-- The [`kubernetes` driver](/manuals/build/builders/drivers/kubernetes.md) now supports a `timeout` option for configuring deployment timeout. [docker/buildx#2492](https://github.com/docker/buildx/pull/2492/)
-- New metrics definitions have been added for build warning types. [docker/buildx#2482](https://github.com/docker/buildx/pull/2482/), [docker/buildx#2507](https://github.com/docker/buildx/pull/2507/)
-- The [`buildx prune`](/reference/cli/docker/buildx/prune.md) and [`buildx du`](/reference/cli/docker/buildx/du.md) commands now support negative and prefix filters. [docker/buildx#2473](https://github.com/docker/buildx/pull/2473/)
-- Building Compose files with Bake now supports passing SSH forwarding configuration. [docker/buildx#2445](https://github.com/docker/buildx/pull/2445/)
-- Fix issue with configuring the `kubernetes` driver with custom TLS certificates. [docker/buildx#2454](https://github.com/docker/buildx/pull/2454/)
-- Fix concurrent kubeconfig access when loading nodes. [docker/buildx#2497](https://github.com/docker/buildx/pull/2497/)
-
-### Packaging updates
-
-- Compose support has been updated to v2.1.2. [docker/buildx#2502](https://github.com/docker/buildx/pull/2502/), [docker/buildx#2425](https://github.com/docker/buildx/pull/2425/)
-
-## 0.14.0
-
-{{< release-date date="2024-04-18" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.14.0).
-
-### Enhancements
-
-- Add support for `--print=lint` (experimental).
-  [docker/buildx#2404](https://github.com/docker/buildx/pull/2404),
-  [docker/buildx#2406](https://github.com/docker/buildx/pull/2406)
-- Fix JSON formatting for custom implementations of print sub-requests in frontends.
-  [docker/buildx#2374](https://github.com/docker/buildx/pull/2374)
-- Provenance records are now set when building with `--metadata-file`.
-  [docker/buildx#2280](https://github.com/docker/buildx/pull/2280)
-- Add [Git authentication support](./bake/remote-definition.md#remote-definition-in-a-private-repository) for remote definitions.
-  [docker/buildx#2363](https://github.com/docker/buildx/pull/2363)
-- New `default-load` driver option for the `docker-container`, `remote`, and `kubernetes` drivers to load build results to the Docker Engine image store by default.
-  [docker/buildx#2259](https://github.com/docker/buildx/pull/2259)
-- Add `requests.ephemeral-storage`, `limits.ephemeral-storage` and `schedulername` options to the [`kubernetes` driver](/manuals/build/builders/drivers/kubernetes.md).
-  [docker/buildx#2370](https://github.com/docker/buildx/pull/2370),
-  [docker/buildx#2415](https://github.com/docker/buildx/pull/2415)
-- Add `indexof` function for `docker-bake.hcl` files.
-  [docker/buildx#2384](https://github.com/docker/buildx/pull/2384)
-- OpenTelemetry metrics for Buildx now measure durations of idle time, image exports, run operations, and image transfers for image source operations during build.
-  [docker/buildx#2316](https://github.com/docker/buildx/pull/2316),
-  [docker/buildx#2317](https://github.com/docker/buildx/pull/2317),
-  [docker/buildx#2323](https://github.com/docker/buildx/pull/2323),
-  [docker/buildx#2271](https://github.com/docker/buildx/pull/2271)
-- Build progress metrics to the OpenTelemetry endpoint associated with the `desktop-linux` context no longer requires Buildx in experimental mode (`BUILDX_EXPERIMENTAL=1`).
-  [docker/buildx#2344](https://github.com/docker/buildx/pull/2344)
-
-### Bug fixes
-
-- Fix `--load` and `--push` incorrectly overriding outputs when used with multiple Bake file definitions.
-  [docker/buildx#2336](https://github.com/docker/buildx/pull/2336)
-- Fix build from stdin with experimental mode enabled.
-  [docker/buildx#2394](https://github.com/docker/buildx/pull/2394)
-- Fix an issue where delegated traces could be duplicated.
-  [docker/buildx#2362](https://github.com/docker/buildx/pull/2362)
-
-### Packaging updates
-
-- Compose support has been updated to [v2.26.1](https://github.com/docker/compose/releases/tag/v2.26.1)
-  (via [`compose-go` v2.0.2](https://github.com/compose-spec/compose-go/releases/tag/v2.0.2)).
-  [docker/buildx#2391](https://github.com/docker/buildx/pull/2391)
-
-## 0.13.1
-
-{{< release-date date="2024-03-13" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.13.1).
-
-### Bug fixes
-
-- Fix connecting to `docker-container://` and `kube-pod://` style URLs with remote driver. [docker/buildx#2327](https://github.com/docker/buildx/pull/2327)
-- Fix handling of `--push` with Bake when a target has already defined a non-image output. [docker/buildx#2330](https://github.com/docker/buildx/pull/2330)
-
-## 0.13.0
-
-{{< release-date date="2024-03-06" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.13.0).
-
-### New
-
-- New `docker buildx dial-stdio` command for directly contacting BuildKit daemon of the configured builder instance. [docker/buildx#2112](https://github.com/docker/buildx/pull/2112)
-- Windows container builders can now be created using the `remote` driver and npipe connections. [docker/buildx#2287](https://github.com/docker/buildx/pull/2287)
-- Npipe URL scheme is now supported on Windows. [docker/buildx#2250](https://github.com/docker/buildx/pull/2250)
-- {{< badge color=violet text=Experimental >}} Buildx can now export OpenTelemetry metrics for build duration and transfer sizes. [docker/buildx#2235](https://github.com/docker/buildx/pull/2235), [docker/buildx#2258](https://github.com/docker/buildx/pull/2258) [docker/buildx#2225](https://github.com/docker/buildx/pull/2225) [docker/buildx#2224](https://github.com/docker/buildx/pull/2224) [docker/buildx#2155](https://github.com/docker/buildx/pull/2155)
-
-### Enhancements
-
-- Bake command now supports defining `shm-size` and `ulimit` values. [docker/buildx#2279](https://github.com/docker/buildx/pull/2279), [docker/buildx#2242](https://github.com/docker/buildx/pull/2242)
-- Better handling of connecting to unhealthy nodes with remote driver. [docker/buildx#2130](https://github.com/docker/buildx/pull/2130)
-- Builders using the `docker-container` and `kubernetes` drivers now allow `network.host` entitlement by default (allowing access to the container's network). [docker/buildx#2266](https://github.com/docker/buildx/pull/2266)
-- Builds can now use multiple outputs with a single command (requires BuildKit v0.13+). [docker/buildx#2290](https://github.com/docker/buildx/pull/2290), [docker/buildx#2302](https://github.com/docker/buildx/pull/2302)
-- Default Git repository path is now found via configured tracking branch. [docker/buildx#2146](https://github.com/docker/buildx/pull/2146)
-- Fix possible cache invalidation when using linked targets in Bake. [docker/buildx#2265](https://github.com/docker/buildx/pull/2265)
-- Fixes for Git repository path sanitization in WSL. [docker/buildx#2167](https://github.com/docker/buildx/pull/2167)
-- Multiple builders can now be removed with a single command. [docker/buildx#2140](https://github.com/docker/buildx/pull/2140)
-- New cancellation signal handling via Unix socket. [docker/buildx#2184](https://github.com/docker/buildx/pull/2184) [docker/buildx#2289](https://github.com/docker/buildx/pull/2289)
-- The Compose spec support has been updated to v2.0.0-rc.8. [docker/buildx#2205](https://github.com/docker/buildx/pull/2205)
-- The `--config` flag for `docker buildx create` was renamed to `--buildkitd-config`. [docker/buildx#2268](https://github.com/docker/buildx/pull/2268)
-- The `--metadata-file` flag for `docker buildx build` can now also return build reference that can be used for further build debugging, for example, in Docker Desktop. [docker/buildx#2263](https://github.com/docker/buildx/pull/2263)
-- The `docker buildx bake` command now shares the same authentication provider for all targets for improved performance. [docker/buildx#2147](https://github.com/docker/buildx/pull/2147)
-- The `docker buildx imagetools inspect` command now shows DSSE-signed SBOM and Provenance attestations. [docker/buildx#2194](https://github.com/docker/buildx/pull/2194)
-- The `docker buildx ls` command now supports `--format` options for controlling the output. [docker/buildx#1787](https://github.com/docker/buildx/pull/1787)
-- The `docker-container` driver now supports driver options for defining restart policy for BuildKit container. [docker/buildx#1271](https://github.com/docker/buildx/pull/1271)
-- VCS attributes exported from Buildx now include the local directory sub-paths if they're relative to the current Git repository. [docker/buildx#2156](https://github.com/docker/buildx/pull/2156)
-- `--add-host` flag now permits a `=` separator for IPv6 addresses. [docker/buildx#2121](https://github.com/docker/buildx/pull/2121)
-
-### Bug fixes
-
-- Fix additional output when exporting progress with `--progress=rawjson` [docker/buildx#2252](https://github.com/docker/buildx/pull/2252)
-- Fix possible console warnings on Windows. [docker/buildx#2238](https://github.com/docker/buildx/pull/2238)
-- Fix possible inconsistent configuration merge order when using Bake with many configurations. [docker/buildx#2237](https://github.com/docker/buildx/pull/2237)
-- Fix possible panic in the `docker buildx imagetools create` command. [docker/buildx#2230](https://github.com/docker/buildx/pull/2230)
-
-## 0.12.1
-
-{{< release-date date="2024-01-12" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.12.1).
-
-### Bug fixes and enhancements
-
-- Fix incorrect validation of some `--driver-opt` values that could cause a panic and corrupt state to be stored.
-  [docker/buildx#2176](https://github.com/docker/buildx/pull/2176)
-
-## 0.12.0
-
-{{< release-date date="2023-11-16" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.12.0).
-
-### New
-
-- New `--annotation` flag for the `buildx build`, and an `annotations` key in the Bake file, that lets you add OCI Annotations to build results.
-  [#2020](https://github.com/docker/buildx/pull/2020),
-  [#2098](https://github.com/docker/buildx/pull/2098)
-- New experimental debugging features, including a new `debug` command and an interactive debugging console.
-  This feature currently requires setting `BUILDX_EXPERIMENTAL=1`.
-  [#2006](https://github.com/docker/buildx/pull/2006),
-  [#1896](https://github.com/docker/buildx/pull/1896),
-  [#1970](https://github.com/docker/buildx/pull/1970),
-  [#1914](https://github.com/docker/buildx/pull/1914),
-  [#2026](https://github.com/docker/buildx/pull/2026),
-  [#2086](https://github.com/docker/buildx/pull/2086)
-
-### Bug fixes and enhancements
-
-- The special `host-gateway` IP mapping can now be used with the `--add-host` flag during build.
-  [#1894](https://github.com/docker/buildx/pull/1894),
-  [#2083](https://github.com/docker/buildx/pull/2083)
-- Bake now allows adding local source files when building from remote definition.
-  [#1838](https://github.com/docker/buildx/pull/1838)
-- The status of uploading build results to Docker is now shown interactively on progress bar.
-  [#1994](https://github.com/docker/buildx/pull/1994)
-- Error handling has been improved when bootstrapping multi-node build clusters.
-  [#1869](https://github.com/docker/buildx/pull/1869)
-- The `buildx imagetools create` command now allows adding annotation when creating new images in the registry.
-  [#1965](https://github.com/docker/buildx/pull/1965)
-- OpenTelemetry build trace delegation from buildx is now possible with Docker and Remote driver.
-  [#2034](https://github.com/docker/buildx/pull/2034)
-- Bake command now shows all files where the build definition was loaded from on the progress bar.
-  [#2076](https://github.com/docker/buildx/pull/2076)
-- Bake files now allow the same attributes to be defined in multiple definition files.
-  [#1062](https://github.com/docker/buildx/pull/1062)
-- Using the Bake command with a remote definition now allows this definition to use local Dockerfiles.
-  [#2015](https://github.com/docker/buildx/pull/2015)
-- Docker container driver now explicitly sets BuildKit config path to make sure configurations are loaded from same location for both mainline and rootless images.
-  [#2093](https://github.com/docker/buildx/pull/2093)
-- Improve performance of detecting when BuildKit instance has completed booting.
-  [#1934](https://github.com/docker/buildx/pull/1934)
-- Container driver now accepts many new driver options for defining the resource limits for BuildKit container.
-  [#2048](https://github.com/docker/buildx/pull/2048)
-- Inspection commands formatting has been improved.
-  [#2068](https://github.com/docker/buildx/pull/2068)
-- Error messages about driver capabilities have been improved.
-  [#1998](https://github.com/docker/buildx/pull/1998)
-- Improve errors when invoking Bake command without targets.
-  [#2100](https://github.com/docker/buildx/pull/2100)
-- Allow enabling debug logs with environment variables when running in standalone mode.
-  [#1821](https://github.com/docker/buildx/pull/1821)
-- When using Docker driver the default image resolve mode has been updated to prefer local Docker images for backward compatibility.
-  [#1886](https://github.com/docker/buildx/pull/1886)
-- Kubernetes driver now allows setting custom annotations and labels to the BuildKit deployments and pods.
-  [#1938](https://github.com/docker/buildx/pull/1938)
-- Kubernetes driver now allows setting authentication token with endpoint configuration.
-  [#1891](https://github.com/docker/buildx/pull/1891)
-- Fix possible issue with chained targets in Bake that could result in build failing or local source for a target uploaded multiple times.
-  [#2113](https://github.com/docker/buildx/pull/2113)
-- Fix issue when accessing global target properties when using the matrix feature of the Bake command.
-  [#2106](https://github.com/docker/buildx/pull/2106)
-- Fixes for formatting validation of certain build flags
-  [#2040](https://github.com/docker/buildx/pull/2040)
-- Fixes to avoid locking certain commands unnecessarily while booting builder nodes.
-  [#2066](https://github.com/docker/buildx/pull/2066)
-- Fix cases where multiple builds try to bootstrap the same builder instance in parallel.
-  [#2000](https://github.com/docker/buildx/pull/2000)
-- Fix cases where errors on uploading build results to Docker could be dropped in some cases.
-  [#1927](https://github.com/docker/buildx/pull/1927)
-- Fix detecting capabilities for missing attestation support based on build output.
-  [#1988](https://github.com/docker/buildx/pull/1988)
-- Fix the build for loading in Bake remote definition to not show up in build history records.
-  [#1961](https://github.com/docker/buildx/pull/1961),
-  [#1954](https://github.com/docker/buildx/pull/1954)
-- Fix errors when building Compose files using the that define profiles with Bake.
-  [#1903](https://github.com/docker/buildx/pull/1903)
-- Fix possible time correction errors on progress bar.
-  [#1968](https://github.com/docker/buildx/pull/1968)
-- Fix passing custom cgroup parent to builds that used the new controller interface.
-  [#1913](https://github.com/docker/buildx/pull/1913)
-
-### Packaging
-
-- Compose support has been updated to 1.20, enabling "include" functionality when using the Bake command.
-  [#1971](https://github.com/docker/buildx/pull/1971),
-  [#2065](https://github.com/docker/buildx/pull/2065),
-  [#2094](https://github.com/docker/buildx/pull/2094)
-
-## 0.11.2
-
-{{< release-date date="2023-07-18" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.11.2).
-
-### Bug fixes and enhancements
-
-- Fix a regression that caused buildx to not read the `KUBECONFIG` path from the instance store.
-  [docker/buildx#1941](https://github.com/docker/buildx/pull/1941)
-- Fix a regression with result handle builds showing up in the build history incorrectly.
-  [docker/buildx#1954](https://github.com/docker/buildx/pull/1954)
-
-## 0.11.1
-
-{{< release-date date="2023-07-05" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.11.1).
-
-### Bug fixes and enhancements
-
-- Fix a regression for bake where services in profiles would not be loaded.
-  [docker/buildx#1903](https://github.com/docker/buildx/pull/1903)
-- Fix a regression where `--cgroup-parent` option had no effect during build.
-  [docker/buildx#1913](https://github.com/docker/buildx/pull/1913)
-- Fix a regression where valid docker contexts could fail buildx builder name
-  validation. [docker/buildx#1879](https://github.com/docker/buildx/pull/1879)
-- Fix a possible panic when terminal is resized during the build.
-  [docker/buildx#1929](https://github.com/docker/buildx/pull/1929)
-
-## 0.11.0
-
-{{< release-date date="2023-06-13" >}}
-
-The full release note for this release is available
-[on GitHub](https://github.com/docker/buildx/releases/tag/v0.11.0).
-
-### New
-
-- Bake now supports [matrix builds](/manuals/build/bake/reference.md#targetmatrix).
-  The new matrix field on `target` lets you create multiple similar targets to
-  remove duplication in bake files. [docker/buildx#1690](https://github.com/docker/buildx/pull/1690)
-- New experimental `--detach` flag for running builds in detached mode.
-  [docker/buildx#1296](https://github.com/docker/buildx/pull/1296),
-  [docker/buildx#1620](https://github.com/docker/buildx/pull/1620),
-  [docker/buildx#1614](https://github.com/docker/buildx/pull/1614),
-  [docker/buildx#1737](https://github.com/docker/buildx/pull/1737),
-  [docker/buildx#1755](https://github.com/docker/buildx/pull/1755)
-- New experimental [debug monitor mode](https://github.com/docker/buildx/blob/v0.11.0-rc1/docs/guides/debugging.md)
-  that lets you start a debug session in your builds.
-  [docker/buildx#1626](https://github.com/docker/buildx/pull/1626),
-  [docker/buildx#1640](https://github.com/docker/buildx/pull/1640)
-- New [`EXPERIMENTAL_BUILDKIT_SOURCE_POLICY` environment variable](./building/variables.md#experimental_buildkit_source_policy)
-  for applying a BuildKit source policy file.
-  [docker/buildx#1628](https://github.com/docker/buildx/pull/1628)
-
-### Bug fixes and enhancements
-
-- `--load` now supports loading multi-platform images when the containerd image
-  store is enabled.
-  [docker/buildx#1813](https://github.com/docker/buildx/pull/1813)
-- Build progress output now displays the name of the builder being used.
-  [docker/buildx#1177](https://github.com/docker/buildx/pull/1177)
-- Bake now supports detecting `compose.{yml,yaml}` files.
-  [docker/buildx#1752](https://github.com/docker/buildx/pull/1752)
-- Bake now supports new compose build keys `dockerfile_inline` and `additional_contexts`.
-  [docker/buildx#1784](https://github.com/docker/buildx/pull/1784)
-- Bake now supports replace HCL function.
-  [docker/buildx#1720](https://github.com/docker/buildx/pull/1720)
-- Bake now allows merging multiple similar attestation parameters into a single
-  parameter to allow overriding with a single global value.
-  [docker/buildx#1699](https://github.com/docker/buildx/pull/1699)
-- Initial support for shell completion.
-  [docker/buildx#1727](https://github.com/docker/buildx/pull/1727)
-- BuildKit versions now correctly display in `buildx ls` and `buildx inspect`
-  for builders using the `docker` driver.
-  [docker/buildx#1552](https://github.com/docker/buildx/pull/1552)
-- Display additional builder node details in buildx inspect view.
-  [docker/buildx#1440](https://github.com/docker/buildx/pull/1440),
-  [docker/buildx#1854](https://github.com/docker/buildx/pull/1874)
-- Builders using the `remote` driver allow using TLS without proving its own
-  key/cert (if BuildKit remote is configured to support it)
-  [docker/buildx#1693](https://github.com/docker/buildx/pull/1693)
-- Builders using the `kubernetes` driver support a new `serviceaccount` option,
-  which sets the `serviceAccountName` of the Kubernetes pod.
-  [docker/buildx#1597](https://github.com/docker/buildx/pull/1597)
-- Builders using the `kubernetes` driver support the `proxy-url` option in the
-  kubeconfig file.
-  [docker/buildx#1780](https://github.com/docker/buildx/pull/1780)
-- Builders using the `kubernetes` are now automatically assigned a node name if
-  no name is explicitly provided.
-  [docker/buildx#1673](https://github.com/docker/buildx/pull/1673)
-- Fix invalid path when writing certificates for `docker-container` driver on Windows.
-  [docker/buildx#1831](https://github.com/docker/buildx/pull/1831)
-- Fix bake failure when remote bake file is accessed using SSH.
-  [docker/buildx#1711](https://github.com/docker/buildx/pull/1711),
-  [docker/buildx#1734](https://github.com/docker/buildx/pull/1734)
-- Fix bake failure when remote bake context is incorrectly resolved.
-  [docker/buildx#1783](https://github.com/docker/buildx/pull/1783)
-- Fix path resolution of `BAKE_CMD_CONTEXT` and `cwd://` paths in bake contexts.
-  [docker/buildx#1840](https://github.com/docker/buildx/pull/1840)
-- Fix mixed OCI and Docker media types when creating images using
-  `buildx imagetools create`.
-  [docker/buildx#1797](https://github.com/docker/buildx/pull/1797)
-- Fix mismatched image id between `--iidfile` and `-q`.
-  [docker/buildx#1844](https://github.com/docker/buildx/pull/1844)
-- Fix AWS authentication when mixing static creds and IAM profiles.
-  [docker/buildx#1816](https://github.com/docker/buildx/pull/1816)
-
-## 0.10.4
-
-{{< release-date date="2023-03-06" >}}
-
-{{% include "buildx-v0.10-disclaimer.md" %}}
-
-### Bug fixes and enhancements
-
-- Add `BUILDX_NO_DEFAULT_ATTESTATIONS` as alternative to `--provenance false`. [docker/buildx#1645](https://github.com/docker/buildx/issues/1645)
-- Disable dirty Git checkout detection by default for performance. Can be enabled with `BUILDX_GIT_CHECK_DIRTY` opt-in. [docker/buildx#1650](https://github.com/docker/buildx/issues/1650)
-- Strip credentials from VCS hint URL before sending to BuildKit. [docker/buildx#1664](https://github.com/docker/buildx/issues/1664)
-
-## 0.10.3
-
-{{< release-date date="2023-02-16" >}}
-
-{{% include "buildx-v0.10-disclaimer.md" %}}
-
-### Bug fixes and enhancements
-
-- Fix reachable commit and warnings on collecting Git provenance info. [docker/buildx#1592](https://github.com/docker/buildx/issues/1592), [docker/buildx#1634](https://github.com/docker/buildx/issues/1634)
-- Fix a regression where docker context was not being validated. [docker/buildx#1596](https://github.com/docker/buildx/issues/1596)
-- Fix function resolution with JSON bake definition. [docker/buildx#1605](https://github.com/docker/buildx/issues/1605)
-- Fix case where original HCL bake diagnostic is discarded. [docker/buildx#1607](https://github.com/docker/buildx/issues/1607)
-- Fix labels not correctly set with bake and compose file. [docker/buildx#1631](https://github.com/docker/buildx/issues/1631)
-
-## 0.10.2
-
-{{< release-date date="2023-01-30" >}}
-
-{{% include "buildx-v0.10-disclaimer.md" %}}
-
-### Bug fixes and enhancements
-
-- Fix preferred platforms order not taken into account in multi-node builds. [docker/buildx#1561](https://github.com/docker/buildx/issues/1561)
-- Fix possible panic on handling `SOURCE_DATE_EPOCH` environment variable. [docker/buildx#1564](https://github.com/docker/buildx/issues/1564)
-- Fix possible push error on multi-node manifest merge since BuildKit v0.11 on
-  some registries. [docker/buildx#1566](https://github.com/docker/buildx/issues/1566)
-- Improve warnings on collecting Git provenance info. [docker/buildx#1568](https://github.com/docker/buildx/issues/1568)
-
-## 0.10.1
-
-{{< release-date date="2023-01-27" >}}
-
-{{% include "buildx-v0.10-disclaimer.md" %}}
-
-### Bug fixes and enhancements
-
-- Fix sending the correct origin URL as `vsc:source` metadata. [docker/buildx#1548](https://github.com/docker/buildx/issues/1548)
-- Fix possible panic from data-race. [docker/buildx#1504](https://github.com/docker/buildx/issues/1504)
-- Fix regression with `rm --all-inactive`. [docker/buildx#1547](https://github.com/docker/buildx/issues/1547)
-- Improve attestation access in `imagetools inspect` by lazily loading data. [docker/buildx#1546](https://github.com/docker/buildx/issues/1546)
-- Correctly mark capabilities request as internal. [docker/buildx#1538](https://github.com/docker/buildx/issues/1538)
-- Detect invalid attestation configuration. [docker/buildx#1545](https://github.com/docker/buildx/issues/1545)
-- Update containerd patches to fix possible push regression affecting
-  `imagetools` commands. [docker/buildx#1559](https://github.com/docker/buildx/issues/1559)
-
-## 0.10.0
-
-{{< release-date date="2023-01-10" >}}
-
-{{% include "buildx-v0.10-disclaimer.md" %}}
-
-### New
-
-- The `buildx build` command supports new `--attest` flag, along with
-  shorthands `--sbom` and `--provenance`, for adding attestations for your
-  current build. [docker/buildx#1412](https://github.com/docker/buildx/issues/1412)
-  [docker/buildx#1475](https://github.com/docker/buildx/issues/1475)
-  - `--attest type=sbom` or `--sbom=true` adds [SBOM attestations](/manuals/build/metadata/attestations/sbom.md).
-  - `--attest type=provenance` or `--provenance=true` adds [SLSA provenance attestation](/manuals/build/metadata/attestations/slsa-provenance.md).
-  - When creating OCI images, a minimal provenance attestation is included
-    with the image by default.
-- When building with BuildKit that supports provenance attestations Buildx will
-  automatically share the version control information of your build context, so
-  it can be shown in provenance for later debugging. Previously this only
-  happened when building from a Git URL directly. To opt-out of this behavior
-  you can set `BUILDX_GIT_INFO=0`. Optionally you can also automatically define
-  labels with VCS info by setting `BUILDX_GIT_LABELS=1`.
-  [docker/buildx#1462](https://github.com/docker/buildx/issues/1462),
-  [docker/buildx#1297](https://github.com/docker/buildx),
-  [docker/buildx#1341](https://github.com/docker/buildx/issues/1341),
-  [docker/buildx#1468](https://github.com/docker/buildx),
-  [docker/buildx#1477](https://github.com/docker/buildx/issues/1477)
-- Named contexts with `--build-context` now support `oci-layout://` protocol
-  for initializing the context with a value of a local OCI layout directory.
-  E.g. `--build-context stagename=oci-layout://path/to/dir`. This feature
-  requires BuildKit v0.11.0+ and Dockerfile 1.5.0+. [docker/buildx#1456](https://github.com/docker/buildx/issues/1456)
-- Bake now supports [resource interpolation](bake/inheritance.md#reusing-single-attribute-from-targets)
-  where you can reuse the values from other target definitions. [docker/buildx#1434](https://github.com/docker/buildx/issues/1434)
-- Buildx will now automatically forward `SOURCE_DATE_EPOCH` environment variable
-  if it is defined in your environment. This feature is meant to be used with
-  updated [reproducible builds](https://github.com/moby/buildkit/blob/master/docs/build-repro.md)
-  support in BuildKit v0.11.0+. [docker/buildx#1482](https://github.com/docker/buildx/issues/1482)
-- Buildx now remembers the last activity for a builder for better organization
-  of builder instances. [docker/buildx#1439](https://github.com/docker/buildx/issues/1439)
-- Bake definition now supports null values for [variables](bake/reference.md#variable) and [labels](bake/reference.md#targetlabels)
-  for build arguments and labels to use the defaults set in the Dockerfile.
-  [docker/buildx#1449](https://github.com/docker/buildx/issues/1449)
-- The [`buildx imagetools inspect` command](/reference/cli/docker/buildx/imagetools/inspect.md)
-  now supports showing SBOM and Provenance data.
-  [docker/buildx#1444](https://github.com/docker/buildx/issues/1444),
-  [docker/buildx#1498](https://github.com/docker/buildx/issues/1498)
-- Increase performance of `ls` command and inspect flows.
-  [docker/buildx#1430](https://github.com/docker/buildx/issues/1430),
-  [docker/buildx#1454](https://github.com/docker/buildx/issues/1454),
-  [docker/buildx#1455](https://github.com/docker/buildx/issues/1455),
-  [docker/buildx#1345](https://github.com/docker/buildx/issues/1345)
-- Adding extra hosts with [Docker driver](/manuals/build/builders/drivers/docker.md) now supports
-  Docker-specific `host-gateway` special value. [docker/buildx#1446](https://github.com/docker/buildx/issues/1446)
-- [OCI exporter](exporters/oci-docker.md) now supports `tar=false` option for
-  exporting OCI format directly in a directory. [docker/buildx#1420](https://github.com/docker/buildx/issues/1420)
-
-### Upgrades
-
-- Updated the Compose Specification to 1.6.0. [docker/buildx#1387](https://github.com/docker/buildx/issues/1387)
-
-### Bug fixes and enhancements
-
-- `--invoke` can now load default launch environment from the image metadata. [docker/buildx#1324](https://github.com/docker/buildx/issues/1324)
-- Fix container driver behavior in regards to UserNS. [docker/buildx#1368](https://github.com/docker/buildx/issues/1368)
-- Fix possible panic in Bake when using wrong variable value type. [docker/buildx#1442](https://github.com/docker/buildx/issues/1442)
-- Fix possible panic in `imagetools inspect`. [docker/buildx#1441](https://github.com/docker/buildx/issues/1441)
-  [docker/buildx#1406](https://github.com/docker/buildx/issues/1406)
-- Fix sending empty `--add-host` value to BuildKit by default. [docker/buildx#1457](https://github.com/docker/buildx/issues/1457)
-- Fix handling progress prefixes with progress groups. [docker/buildx#1305](https://github.com/docker/buildx/issues/1305)
-- Fix recursively resolving groups in Bake. [docker/buildx#1313](https://github.com/docker/buildx/issues/1313)
-- Fix possible wrong indentation on multi-node builder manifests. [docker/buildx#1396](https://github.com/docker/buildx/issues/1396)
-- Fix possible panic from missing OpenTelemetry configuration. [docker/buildx#1383](https://github.com/docker/buildx/issues/1383)
-- Fix `--progress=tty` behavior when TTY is not available. [docker/buildx#1371](https://github.com/docker/buildx/issues/1371)
-- Fix connection error conditions in `prune` and `du` commands. [docker/buildx#1307](https://github.com/docker/buildx/issues/1307)
-
-## 0.9.1
-
-{{< release-date date="2022-08-18" >}}
-
-### Bug fixes and enhancements
-
-- The `inspect` command now displays the BuildKit version in use. [docker/buildx#1279](https://github.com/docker/buildx/issues/1279)
-- Fixed a regression when building Compose files that contain services without a
-  build block. [docker/buildx#1277](https://github.com/docker/buildx/issues/1277)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.9.1).
-
-## 0.9.0
-
-{{< release-date date="2022-08-17" >}}
-
-### New
-
-- Support for a new [`remote` driver](/manuals/build/builders/drivers/remote.md) that you can use
-  to connect to any already running BuildKit instance.
-  [docker/buildx#1078](https://github.com/docker/buildx/issues/1078),
-  [docker/buildx#1093](https://github.com/docker/buildx/issues/1093),
-  [docker/buildx#1094](https://github.com/docker/buildx/issues/1094),
-  [docker/buildx#1103](https://github.com/docker/buildx/issues/1103),
-  [docker/buildx#1134](https://github.com/docker/buildx/issues/1134),
-  [docker/buildx#1204](https://github.com/docker/buildx/issues/1204)
-- You can now load Dockerfile from standard input even when the build context is
-  coming from external Git or HTTP URL. [docker/buildx#994](https://github.com/docker/buildx/issues/994)
-- Build commands now support new the build context type `oci-layout://` for loading
-  [build context from local OCI layout directories](/reference/cli/docker/buildx/build.md#source-oci-layout).
-  Note that this feature depends on an unreleased BuildKit feature and builder
-  instance from `moby/buildkit:master` needs to be used until BuildKit v0.11 is
-  released. [docker/buildx#1173](https://github.com/docker/buildx/issues/1173)
-- You can now use the new `--print` flag to run helper functions supported by the
-  BuildKit frontend performing the build and print their results. You can use
-  this feature in Dockerfile to show the build arguments and secrets that the
-  current build supports with `--print=outline` and list all available
-  Dockerfile stages with `--print=targets`. This feature is experimental for
-  gathering early feedback and requires enabling `BUILDX_EXPERIMENTAL=1`
-  environment variable. We plan to update/extend this feature in the future
-  without keeping backward compatibility. [docker/buildx#1100](https://github.com/docker/buildx/issues/1100),
-  [docker/buildx#1272](https://github.com/docker/buildx/issues/1272)
-- You can now use the new `--invoke` flag to launch interactive containers from
-  build results for an interactive debugging cycle. You can reload these
-  containers with code changes or restore them to an initial state from the
-  special monitor mode. This feature is experimental for gathering early
-  feedback and requires enabling `BUILDX_EXPERIMENTAL=1` environment variable.
-  We plan to update/extend this feature in the future without enabling backward
-  compatibility.
-  [docker/buildx#1168](https://github.com/docker/buildx/issues/1168),
-  [docker/buildx#1257](https://github.com/docker/buildx),
-  [docker/buildx#1259](https://github.com/docker/buildx/issues/1259)
-- Buildx now understands environment variable `BUILDKIT_COLORS` and `NO_COLOR`
-  to customize/disable the colors of interactive build progressbar. [docker/buildx#1230](https://github.com/docker/buildx/issues/1230),
-  [docker/buildx#1226](https://github.com/docker/buildx/issues/1226)
-- `buildx ls` command now shows the current BuildKit version of each builder
-  instance. [docker/buildx#998](https://github.com/docker/buildx/issues/998)
-- The `bake` command now loads `.env` file automatically when building Compose
-  files for compatibility. [docker/buildx#1261](https://github.com/docker/buildx/issues/1261)
-- Bake now supports Compose files with `cache_to` definition. [docker/buildx#1155](https://github.com/docker/buildx/issues/1155)
-- Bake now supports new builtin function `timestamp()` to access current time. [docker/buildx#1214](https://github.com/docker/buildx/issues/1214)
-- Bake now supports Compose build secrets definition. [docker/buildx#1069](https://github.com/docker/buildx/issues/1069)
-- Additional build context configuration is now supported in Compose files via `x-bake`. [docker/buildx#1256](https://github.com/docker/buildx/issues/1256)
-- Inspecting builder now shows current driver options configuration. [docker/buildx#1003](https://github.com/docker/buildx/issues/1003),
-  [docker/buildx#1066](https://github.com/docker/buildx/issues/1066)
-
-### Updates
-
-- Updated the Compose Specification to 1.4.0. [docker/buildx#1246](https://github.com/docker/buildx/issues/1246),
-  [docker/buildx#1251](https://github.com/docker/buildx/issues/1251)
-
-### Bug fixes and enhancements
-
-- The `buildx ls` command output has been updated with better access to errors
-  from different builders. [docker/buildx#1109](https://github.com/docker/buildx/issues/1109)
-- The `buildx create` command now performs additional validation of builder parameters
-  to avoid creating a builder instance with invalid configuration. [docker/buildx#1206](https://github.com/docker/buildx/issues/1206)
-- The `buildx imagetools create` command can now create new multi-platform images
-  even if the source subimages are located on different repositories or
-  registries. [docker/buildx#1137](https://github.com/docker/buildx/issues/1137)
-- You can now set the default builder config that is used when creating
-  builder instances without passing custom `--config` value. [docker/buildx#1111](https://github.com/docker/buildx/issues/1111)
-- Docker driver can now detect if `dockerd` instance supports initially
-  disabled Buildkit features like multi-platform images. [docker/buildx#1260](https://github.com/docker/buildx/issues/1260),
-  [docker/buildx#1262](https://github.com/docker/buildx/issues/1262)
-- Compose files using targets with `.` in the name are now converted to use `_`
-  so the selector keys can still be used in such targets. [docker/buildx#1011](https://github.com/docker/buildx/issues/1011)
-- Included an additional validation for checking valid driver configurations. [docker/buildx#1188](https://github.com/docker/buildx/issues/1188),
-  [docker/buildx#1273](https://github.com/docker/buildx/issues/1273)
-- The `remove` command now displays the removed builder and forbids removing
-  context builders. [docker/buildx#1128](https://github.com/docker/buildx/issues/1128)
-- Enable Azure authentication when using Kubernetes driver. [docker/buildx#974](https://github.com/docker/buildx/issues/974)
-- Add tolerations handling for kubernetes driver. [docker/buildx#1045](https://github.com/docker/buildx/issues/1045)
-  [docker/buildx#1053](https://github.com/docker/buildx/issues/1053)
-- Replace deprecated seccomp annotations with `securityContext` in the `kubernetes` driver.
-  [docker/buildx#1052](https://github.com/docker/buildx/issues/1052)
-- Fix panic on handling manifests with nil platform. [docker/buildx#1144](https://github.com/docker/buildx/issues/1144)
-- Fix using duration filter with `prune` command. [docker/buildx#1252](https://github.com/docker/buildx/issues/1252)
-- Fix merging multiple JSON files on Bake definition. [docker/buildx#1025](https://github.com/docker/buildx/issues/1025)
-- Fix issues with implicit builder created from Docker context had invalid
-  configuration or dropped connection. [docker/buildx#1129](https://github.com/docker/buildx/issues/1129)
-- Fix conditions for showing no-output warning when using named contexts. [docker/buildx#968](https://github.com/docker/buildx/issues/968)
-- Fix duplicating builders when builder instance and docker context have the
-  same name. [docker/buildx#1131](https://github.com/docker/buildx/issues/1131)
-- Fix printing unnecessary SSH warning logs. [docker/buildx#1085](https://github.com/docker/buildx/issues/1085)
-- Fix possible panic when using an empty variable block with Bake JSON
-  definition. [docker/buildx#1080](https://github.com/docker/buildx/issues/1080)
-- Fix image tools commands not handling `--builder` flag correctly. [docker/buildx#1067](https://github.com/docker/buildx/issues/1067)
-- Fix using custom image together with rootless option. [docker/buildx#1063](https://github.com/docker/buildx/issues/1063)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.9.0).
-
-## 0.8.2
-
-{{< release-date date="2022-04-04" >}}
-
-### Updates
-
-- Update Compose spec used by `buildx bake` to v1.2.1 to fix parsing ports definition. [docker/buildx#1033](https://github.com/docker/buildx/issues/1033)
-
-### Bug fixes and enhancements
-
-- Fix possible crash on handling progress streams from BuildKit v0.10. [docker/buildx#1042](https://github.com/docker/buildx/issues/1042)
-- Fix parsing groups in `buildx bake` when already loaded by a parent group. [docker/buildx#1021](https://github.com/docker/buildx/issues/1021)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.8.2).
-
-## 0.8.1
-
-{{< release-date date="2022-03-21" >}}
-
-### Bug fixes and enhancements
-
-- Fix possible panic on handling build context scanning errors. [docker/buildx#1005](https://github.com/docker/buildx/issues/1005)
-- Allow `.` on Compose target names in `buildx bake` for backward compatibility. [docker/buildx#1018](https://github.com/docker/buildx/issues/1018)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.8.1).
-
-## 0.8.0
-
-{{< release-date date="2022-03-09" >}}
-
-### New
-
-- Build command now accepts `--build-context` flag to [define additional named build contexts](/reference/cli/docker/buildx/build/#build-context)
-  for your builds. [docker/buildx#904](https://github.com/docker/buildx/issues/904)
-- Bake definitions now support [defining dependencies between targets](bake/contexts.md)
-  and using the result of one target in another build.
-  [docker/buildx#928](https://github.com/docker/buildx/issues/928),
-  [docker/buildx#965](https://github.com/docker/buildx/issues/965),
-  [docker/buildx#963](https://github.com/docker/buildx/issues/963),
-  [docker/buildx#962](https://github.com/docker/buildx/issues/962),
-  [docker/buildx#981](https://github.com/docker/buildx/issues/981)
-- `imagetools inspect` now accepts `--format` flag allowing access to config
-  and buildinfo for specific images. [docker/buildx#854](https://github.com/docker/buildx/issues/854),
-  [docker/buildx#972](https://github.com/docker/buildx/issues/972)
-- New flag `--no-cache-filter` allows configuring build, so it ignores cache
-  only for specified Dockerfile stages. [docker/buildx#860](https://github.com/docker/buildx/issues/860)
-- Builds can now show a summary of warnings sets by the building frontend. [docker/buildx#892](https://github.com/docker/buildx/issues/892)
-- The new build argument `BUILDKIT_INLINE_BUILDINFO_ATTRS` allows opting-in to embed
-  building attributes to resulting image. [docker/buildx#908](https://github.com/docker/buildx/issues/908)
-- The new flag `--keep-buildkitd` allows keeping BuildKit daemon running when removing a builder
-  - [docker/buildx#852](https://github.com/docker/buildx/issues/852)
-
-### Bug fixes and enhancements
-
-- `--metadata-file` output now supports embedded structure types. [docker/buildx#946](https://github.com/docker/buildx/issues/946)
-- `buildx rm` now accepts new flag `--all-inactive` for removing all builders
-  that are not currently running. [docker/buildx#885](https://github.com/docker/buildx/issues/885)
-- Proxy config is now read from Docker configuration file and sent with build
-  requests for backward compatibility. [docker/buildx#959](https://github.com/docker/buildx/issues/959)
-- Support host networking in Compose. [docker/buildx#905](https://github.com/docker/buildx/issues/905),
-  [docker/buildx#880](https://github.com/docker/buildx/issues/880)
-- Bake files can now be read from stdin with `-f -`. [docker/buildx#864](https://github.com/docker/buildx/issues/864)
-- `--iidfile` now always writes the image config digest independently of the
-  driver being used (use `--metadata-file` for digest). [docker/buildx#980](https://github.com/docker/buildx/issues/980)
-- Target names in Bake are now restricted to not use special characters. [docker/buildx#929](https://github.com/docker/buildx/issues/929)
-- Image manifest digest can be read from metadata when pushed with `docker`
-  driver. [docker/buildx#989](https://github.com/docker/buildx/issues/989)
-- Fix environment file handling in Compose files. [docker/buildx#905](https://github.com/docker/buildx/issues/905)
-- Show last access time in `du` command. [docker/buildx#867](https://github.com/docker/buildx/issues/867)
-- Fix possible double output logs when multiple Bake targets run same build
-  steps. [docker/buildx#977](https://github.com/docker/buildx/issues/977)
-- Fix possible errors on multi-node builder building multiple targets with
-  mixed platform. [docker/buildx#985](https://github.com/docker/buildx/issues/985)
-- Fix some nested inheritance cases in Bake. [docker/buildx#914](https://github.com/docker/buildx/issues/914)
-- Fix printing default group on Bake files. [docker/buildx#884](https://github.com/docker/buildx/issues/884)
-- Fix `UsernsMode` when using rootless container. [docker/buildx#887](https://github.com/docker/buildx/issues/887)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.8.0).
-
-## 0.7.1
-
-{{< release-date date="2021-08-25" >}}
-
-### Fixes
-
-- Fix issue with matching exclude rules in `.dockerignore`. [docker/buildx#858](https://github.com/docker/buildx/issues/858)
-- Fix `bake --print` JSON output for current group. [docker/buildx#857](https://github.com/docker/buildx/issues/857)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.7.1).
-
-## 0.7.0
-
-{{< release-date date="2021-11-10" >}}
-
-### New features
-
-- TLS certificates from BuildKit configuration are now transferred to build
-  container with `docker-container` and `kubernetes` drivers. [docker/buildx#787](https://github.com/docker/buildx/issues/787)
-- Builds support `--ulimit` flag for feature parity. [docker/buildx#800](https://github.com/docker/buildx/issues/800)
-- Builds support `--shm-size` flag for feature parity. [docker/buildx#790](https://github.com/docker/buildx/issues/790)
-- Builds support `--quiet` for feature parity. [docker/buildx#740](https://github.com/docker/buildx/issues/740)
-- Builds support `--cgroup-parent` flag for feature parity. [docker/buildx#814](https://github.com/docker/buildx/issues/814)
-- Bake supports builtin variable `BAKE_LOCAL_PLATFORM`. [docker/buildx#748](https://github.com/docker/buildx/issues/748)
-- Bake supports `x-bake` extension field in Compose files. [docker/buildx#721](https://github.com/docker/buildx/issues/721)
-- `kubernetes` driver now supports colon-separated `KUBECONFIG`. [docker/buildx#761](https://github.com/docker/buildx/issues/761)
-- `kubernetes` driver now supports setting Buildkit config file with `--config`. [docker/buildx#682](https://github.com/docker/buildx/issues/682)
-- `kubernetes` driver now supports installing QEMU emulators with driver-opt. [docker/buildx#682](https://github.com/docker/buildx/issues/682)
-
-### Enhancements
-
-- Allow using custom registry configuration for multi-node pushes from the
-  client. [docker/buildx#825](https://github.com/docker/buildx/issues/825)
-- Allow using custom registry configuration for `buildx imagetools` command. [docker/buildx#825](https://github.com/docker/buildx/issues/825)
-- Allow booting builder after creating with `buildx create --bootstrap`. [docker/buildx#692](https://github.com/docker/buildx/issues/692)
-- Allow `registry:insecure` output option for multi-node pushes. [docker/buildx#825](https://github.com/docker/buildx/issues/825)
-- BuildKit config and TLS files are now kept in Buildx state directory and
-  reused if BuildKit instance needs to be recreated. [docker/buildx#824](https://github.com/docker/buildx/issues/824)
-- Ensure different projects use separate destination directories for
-  incremental context transfer for better performance. [docker/buildx#817](https://github.com/docker/buildx/issues/817)
-- Build containers are now placed on separate cgroup by default. [docker/buildx#782](https://github.com/docker/buildx/issues/782)
-- Bake now prints the default group with `--print`. [docker/buildx#720](https://github.com/docker/buildx/issues/720)
-- `docker` driver now dials build session over HTTP for better performance. [docker/buildx#804](https://github.com/docker/buildx/issues/804)
-
-### Fixes
-
-- Fix using `--iidfile` together with a multi-node push. [docker/buildx#826](https://github.com/docker/buildx/issues/826)
-- Using `--push` in Bake does not clear other image export options in the file. [docker/buildx#773](https://github.com/docker/buildx/issues/773)
-- Fix Git URL detection for `buildx bake` when `https` protocol was used. [docker/buildx#822](https://github.com/docker/buildx/issues/822)
-- Fix pushing image with multiple names on multi-node builds. [docker/buildx#815](https://github.com/docker/buildx/issues/815)
-- Avoid showing `--builder` flags for commands that don't use it. [docker/buildx#818](https://github.com/docker/buildx/issues/818)
-- Unsupported build flags now show a warning. [docker/buildx#810](https://github.com/docker/buildx/issues/810)
-- Fix reporting error details in some OpenTelemetry traces. [docker/buildx#812](https://github.com/docker/buildx/issues/812)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.7.0).
-
-## 0.6.3
-
-{{< release-date date="2021-08-30" >}}
-
-### Fixes
-
-- Fix BuildKit state volume location for Windows clients. [docker/buildx#751](https://github.com/docker/buildx/issues/751)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.6.3).
-
-## 0.6.2
-
-{{< release-date date="2021-08-21" >}}
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.6.2).
-
-### Fixes
-
-- Fix connection error showing up in some SSH configurations. [docker/buildx#741](https://github.com/docker/buildx/issues/741)
-
-## 0.6.1
-
-{{< release-date date="2021-07-30" >}}
-
-### Enhancements
-
-- Set `ConfigFile` to parse compose files with Bake. [docker/buildx#704](https://github.com/docker/buildx/issues/704)
-
-### Fixes
-
-- Duplicate progress env var. [docker/buildx#693](https://github.com/docker/buildx/issues/693)
-- Should ignore nil client. [docker/buildx#686](https://github.com/docker/buildx/issues/686)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.6.1).
-
-## 0.6.0
-
-{{< release-date date="2021-07-16" >}}
-
-### New features
-
-- Support for OpenTelemetry traces and forwarding Buildx client traces to
-  BuildKit. [docker/buildx#635](https://github.com/docker/buildx/issues/635)
-- Experimental GitHub Actions remote cache backend with `--cache-to type=gha`
-  and `--cache-from type=gha`. [docker/buildx#535](https://github.com/docker/buildx/issues/535)
-- New `--metadata-file` flag has been added to build and Bake command that
-  allows saving build result metadata in JSON format. [docker/buildx#605](https://github.com/docker/buildx/issues/605)
-- This is the first release supporting Windows ARM64. [docker/buildx#654](https://github.com/docker/buildx/issues/654)
-- This is the first release supporting Linux Risc-V. [docker/buildx#652](https://github.com/docker/buildx/issues/652)
-- Bake now supports building from remote definition with local files or
-  another remote source as context. [docker/buildx#671](https://github.com/docker/buildx/issues/671)
-- Bake now allows variables to reference each other and using user functions
-  in variables and vice-versa.
-  [docker/buildx#575](https://github.com/docker/buildx/issues/575),
-  [docker/buildx#539](https://github.com/docker/buildx/issues/539),
-  [docker/buildx#532](https://github.com/docker/buildx/issues/532)
-- Bake allows defining attributes in the global scope. [docker/buildx#541](https://github.com/docker/buildx/issues/541)
-- Bake allows variables across multiple files. [docker/buildx#538](https://github.com/docker/buildx/issues/538)
-- New quiet mode has been added to progress printer. [docker/buildx#558](https://github.com/docker/buildx/issues/558)
-- `kubernetes` driver now supports defining resources/limits. [docker/buildx#618](https://github.com/docker/buildx/issues/618)
-- Buildx binaries can now be accessed through [buildx-bin](https://hub.docker.com/r/docker/buildx-bin)
-  Docker image. [docker/buildx#656](https://github.com/docker/buildx/issues/656)
-
-### Enhancements
-
-- `docker-container` driver now keeps BuildKit state in volume. Enabling
-  updates with keeping state. [docker/buildx#672](https://github.com/docker/buildx/issues/672)
-- Compose parser is now based on new [compose-go parser](https://github.com/compose-spec/compose-go)
-  fixing support for some newer syntax. [docker/buildx#669](https://github.com/docker/buildx/issues/669)
-- SSH socket is now automatically forwarded when building an ssh-based git URL. [docker/buildx#581](https://github.com/docker/buildx/issues/581)
-- Bake HCL parser has been rewritten. [docker/buildx#645](https://github.com/docker/buildx/issues/645)
-- Extend HCL support with more functions. [docker/buildx#491](https://github.com/docker/buildx/issues/491)
-  [docker/buildx#503](https://github.com/docker/buildx/issues/503)
-- Allow secrets from environment variables. [docker/buildx#488](https://github.com/docker/buildx/issues/488)
-- Builds with an unsupported multi-platform and load configuration now fail fast. [docker/buildx#582](https://github.com/docker/buildx/issues/582)
-- Store Kubernetes config file to make buildx builder switchable. [docker/buildx#497](https://github.com/docker/buildx/issues/497)
-- Kubernetes now lists all pods as nodes on inspection. [docker/buildx#477](https://github.com/docker/buildx/issues/477)
-- Default Rootless image has been set to `moby/buildkit:buildx-stable-1-rootless`. [docker/buildx#480](https://github.com/docker/buildx/issues/480)
-
-### Fixes
-
-- `imagetools create` command now correctly merges JSON descriptor with old one. [docker/buildx#592](https://github.com/docker/buildx/issues/592)
-- Fix building with `--network=none` not requiring extra security entitlements. [docker/buildx#531](https://github.com/docker/buildx/issues/531)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.6.0).
-
-## 0.5.1
-
-{{< release-date date="2020-12-15" >}}
-
-### Fixes
-
-- Fix regression on setting `--platform` on `buildx create` outside
-  `kubernetes` driver. [docker/buildx#475](https://github.com/docker/buildx/issues/475)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.5.1).
-
-## 0.5.0
-
-{{< release-date date="2020-12-15" >}}
-
-### New features
-
-- The `docker` driver now supports the `--push` flag. [docker/buildx#442](https://github.com/docker/buildx/issues/442)
-- Bake supports inline Dockerfiles. [docker/buildx#398](https://github.com/docker/buildx/issues/398)
-- Bake supports building from remote URLs and Git repositories. [docker/buildx#398](https://github.com/docker/buildx/issues/398)
-- `BUILDX_CONFIG` env var allow users to have separate buildx state from
-  Docker config. [docker/buildx#385](https://github.com/docker/buildx/issues/385)
-- `BUILDKIT_MULTI_PLATFORM` build arg allows to force building multi-platform
-  return objects even if only one `--platform` specified. [docker/buildx#467](https://github.com/docker/buildx/issues/467)
-
-### Enhancements
-
-- Allow `--append` to be used with `kubernetes` driver. [docker/buildx#370](https://github.com/docker/buildx/issues/370)
-- Build errors show error location in source files and system stacktraces
-  with `--debug`. [docker/buildx#389](https://github.com/docker/buildx/issues/389)
-- Bake formats HCL errors with source definition. [docker/buildx#391](https://github.com/docker/buildx/issues/391)
-- Bake allows empty string values in arrays that will be discarded. [docker/buildx#428](https://github.com/docker/buildx/issues/428)
-- You can now use the Kubernetes cluster config with the `kubernetes` driver. [docker/buildx#368](https://github.com/docker/buildx/issues/368)
-  [docker/buildx#460](https://github.com/docker/buildx/issues/460)
-- Creates a temporary token for pulling images instead of sharing credentials
-  when possible. [docker/buildx#469](https://github.com/docker/buildx/issues/469)
-- Ensure credentials are passed when pulling BuildKit container image. [docker/buildx#441](https://github.com/docker/buildx/issues/441)
-  [docker/buildx#433](https://github.com/docker/buildx/issues/433)
-- Disable user namespace remapping in `docker-container` driver. [docker/buildx#462](https://github.com/docker/buildx/issues/462)
-- Allow `--builder` flag to switch to default instance. [docker/buildx#425](https://github.com/docker/buildx/issues/425)
-- Avoid warn on empty `BUILDX_NO_DEFAULT_LOAD` config value. [docker/buildx#390](https://github.com/docker/buildx/issues/390)
-- Replace error generated by `quiet` option by a warning. [docker/buildx#403](https://github.com/docker/buildx/issues/403)
-- CI has been switched to GitHub Actions.
-  [docker/buildx#451](https://github.com/docker/buildx/issues/451),
-  [docker/buildx#463](https://github.com/docker/buildx/issues/463),
-  [docker/buildx#466](https://github.com/docker/buildx/issues/466),
-  [docker/buildx#468](https://github.com/docker/buildx/issues/468),
-  [docker/buildx#471](https://github.com/docker/buildx/issues/471)
-
-### Fixes
-
-- Handle lowercase Dockerfile name as a fallback for backward compatibility. [docker/buildx#444](https://github.com/docker/buildx/issues/444)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.5.0).
-
-## 0.4.2
-
-{{< release-date date="2020-08-22" >}}
-
-### New features
-
-- Support `cacheonly` exporter. [docker/buildx#337](https://github.com/docker/buildx/issues/337)
-
-### Enhancements
-
-- Update `go-cty` to pull in more `stdlib` functions. [docker/buildx#277](https://github.com/docker/buildx/issues/277)
-- Improve error checking on load. [docker/buildx#281](https://github.com/docker/buildx/issues/281)
-
-### Fixes
-
-- Fix parsing json config with HCL. [docker/buildx#280](https://github.com/docker/buildx/issues/280)
-- Ensure `--builder` is wired from root options. [docker/buildx#321](https://github.com/docker/buildx/issues/321)
-- Remove warning for multi-platform iidfile. [docker/buildx#351](https://github.com/docker/buildx/issues/351)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.4.2).
-
-## 0.4.1
-
-{{< release-date date="2020-05-01" >}}
-
-### Fixes
-
-- Fix regression on flag parsing. [docker/buildx#268](https://github.com/docker/buildx/issues/268)
-- Fix using pull and no-cache keys in HCL targets. [docker/buildx#268](https://github.com/docker/buildx/issues/268)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.4.1).
-
-## 0.4.0
-
-{{< release-date date="2020-04-30" >}}
-
-### New features
-
-- Add `kubernetes` driver. [docker/buildx#167](https://github.com/docker/buildx/issues/167)
-- New global `--builder` flag to override builder instance for a single command. [docker/buildx#246](https://github.com/docker/buildx/issues/246)
-- New `prune` and `du` commands for managing local builder cache. [docker/buildx#249](https://github.com/docker/buildx/issues/249)
-- You can now set the new `pull` and `no-cache` options for HCL targets. [docker/buildx#165](https://github.com/docker/buildx/issues/165)
-
-### Enhancements
-
-- Upgrade Bake to HCL2 with support for variables and functions. [docker/buildx#192](https://github.com/docker/buildx/issues/192)
-- Bake now supports `--load` and `--push`. [docker/buildx#164](https://github.com/docker/buildx/issues/164)
-- Bake now supports wildcard overrides for multiple targets. [docker/buildx#164](https://github.com/docker/buildx/issues/164)
-- Container driver allows setting environment variables via `driver-opt`. [docker/buildx#170](https://github.com/docker/buildx/issues/170)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.4.0).
-
-## 0.3.1
-
-{{< release-date date="2019-09-27" >}}
-
-### Enhancements
-
-- Handle copying unix sockets instead of erroring. [docker/buildx#155](https://github.com/docker/buildx/issues/155)
-  [moby/buildkit#1144](https://github.com/moby/buildkit/issues/1144)
-
-### Fixes
-
-- Running Bake with multiple Compose files now merges targets correctly. [docker/buildx#134](https://github.com/docker/buildx/issues/134)
-- Fix bug when building a Dockerfile from stdin (`build -f -`).
-  [docker/buildx#153](https://github.com/docker/buildx/issues/153)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.3.1).
-
-## 0.3.0
-
-{{< release-date date="2019-08-02" >}}
-
-### New features
-
-- Custom `buildkitd` daemon flags. [docker/buildx#102](https://github.com/docker/buildx/issues/102)
-- Driver-specific options on `create`. [docker/buildx#122](https://github.com/docker/buildx/issues/122)
-
-### Enhancements
-
-- Environment variables are used in Compose files. [docker/buildx#117](https://github.com/docker/buildx/issues/117)
-- Bake now honors `--no-cache` and `--pull`. [docker/buildx#118](https://github.com/docker/buildx/issues/118)
-- Custom BuildKit config file. [docker/buildx#121](https://github.com/docker/buildx/issues/121)
-- Entitlements support with `build --allow`. [docker/buildx#104](https://github.com/docker/buildx/issues/104)
-
-### Fixes
-
-- Fix bug where `--build-arg foo` would not read `foo` from environment. [docker/buildx#116](https://github.com/docker/buildx/issues/116)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.3.0).
-
-## 0.2.2
-
-{{< release-date date="2019-05-30" >}}
-
-### Enhancements
-
-- Change Compose file handling to require valid service specifications. [docker/buildx#87](https://github.com/docker/buildx/issues/87)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.2.2).
-
-## 0.2.1
-
-{{< release-date date="2019-05-25" >}}
-
-### New features
-
-- Add `BUILDKIT_PROGRESS` env var. [docker/buildx#69](https://github.com/docker/buildx/issues/69)
-- Add `local` platform. [docker/buildx#70](https://github.com/docker/buildx/issues/70)
-
-### Enhancements
-
-- Keep arm variant if one is defined in the config. [docker/buildx#68](https://github.com/docker/buildx/issues/68)
-- Make dockerfile relative to context. [docker/buildx#83](https://github.com/docker/buildx/issues/83)
-
-### Fixes
-
-- Fix parsing target from compose files. [docker/buildx#53](https://github.com/docker/buildx/issues/53)
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.2.1).
-
-## 0.2.0
-
-{{< release-date date="2019-04-25" >}}
-
-### New features
-
-- First release
-
-For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.2.0).
+params:
+  sidebar:
+    goto: "https://github.com/docker/buildx/releases"
+---
\ No newline at end of file
diff --git a/content/manuals/compose/_index.md b/content/manuals/compose/_index.md
index 8f16cd62fedd..9985171db82a 100644
--- a/content/manuals/compose/_index.md
+++ b/content/manuals/compose/_index.md
@@ -3,53 +3,49 @@ title: Docker Compose
 weight: 30
 description: Learn how to use Docker Compose to define and run multi-container applications
   with this detailed introduction to the tool.
-keywords: docker compose, docker-compose, docker compose command, docker compose files,
-  docker compose documentation, using docker compose, compose container, docker compose
-  service
+keywords: docker compose, docker-compose, compose.yaml, docker compose command, multi-container applications, container orchestration, docker cli
 params:
   sidebar:
-    group: Open source
+    group: Application development
 grid:
 - title: Why use Compose?
   description: Understand Docker Compose's key benefits
-  icon: feature_search
+  icon: magnifying-glass
   link: /compose/intro/features-uses/
 - title: How Compose works 
   description: Understand how Compose works
-  icon: category
+  icon: squares-2x2
   link: /compose/intro/compose-application-model/
 - title: Install Compose
   description: Follow the instructions on how to install Docker Compose.
-  icon: download
+  icon: arrow-down-tray
   link: /compose/install
 - title: Quickstart
   description: Learn the key concepts of Docker Compose whilst building a simple Python
     web application.
-  icon: explore
+  icon: magnifying-glass-plus
   link: /compose/gettingstarted
 - title: View the release notes
   description: Find out about the latest enhancements and bug fixes.
-  icon: note_add
-  link: /compose/release-notes
+  icon: document-plus
+  link: "https://github.com/docker/compose/releases"
 - title: Explore the Compose file reference
   description: Find information on defining services, networks, and volumes for a
     Docker application.
-  icon: polyline
+  icon: arrows-right-left
   link: /reference/compose-file
+- title: Use Compose Bridge
+  description: Transform your Compose configuration file into configuration files for different platforms, such as Kubernetes.
+  icon: arrow-down
+  link: /compose/bridge
 - title: Browse common FAQs
   description: Explore general FAQs and find out how to give feedback.
-  icon: help
+  icon: question-mark-circle
   link: /compose/faq
-- title: Migrate to Compose v2
-  description: Learn how to migrate from Compose v1 to v2
-  icon: folder_delete
-  link: /compose/releases/migrate/
 aliases:
-- /compose/cli-command/
-- /compose/networking/swarm/
 - /compose/overview/
 - /compose/swarm/
-- /compose/completion/
+- /compose/releases/migrate/
 ---
 
 Docker Compose is a tool for defining and running multi-container applications. 
@@ -58,12 +54,12 @@ It is the key to unlocking a streamlined and efficient development and deploymen
 Compose simplifies the control of your entire application stack, making it easy to manage services, networks, and volumes in a single YAML configuration file. Then, with a single command, you create and start all the services
 from your configuration file.
 
-Compose works in all environments; production, staging, development, testing, as
+Compose works in all environments - production, staging, development, testing, as
 well as CI workflows. It also has commands for managing the whole lifecycle of your application:
 
- * Start, stop, and rebuild services
- * View the status of running services
- * Stream the log output of running services
- * Run a one-off command on a service
+ - Start, stop, and rebuild services
+ - View the status of running services
+ - Stream the log output of running services
+ - Run a one-off command on a service
 
 {{< grid >}}
diff --git a/content/manuals/compose/bridge/_index.md b/content/manuals/compose/bridge/_index.md
index b84dcb8dba60..781a6f2cfb74 100644
--- a/content/manuals/compose/bridge/_index.md
+++ b/content/manuals/compose/bridge/_index.md
@@ -1,6 +1,6 @@
 ---
-description: Understand what Compose Bridge is and how it can be useful
-keywords: compose, orchestration, kubernetes, bridge
+description: Learn how Compose Bridge transforms Docker Compose files into Kubernetes manifests for seamless platform transitions
+keywords: docker compose bridge, compose to kubernetes, docker compose kubernetes integration, docker compose kustomize, compose bridge docker desktop
 title: Overview of Compose Bridge
 linkTitle: Compose Bridge
 weight: 50
@@ -8,15 +8,20 @@ weight: 50
 
 {{< summary-bar feature_name="Compose bridge" >}}
 
-Compose Bridge lets you transform your Compose configuration file into configuration files for different platforms, primarily focusing on Kubernetes. The default transformation generates Kubernetes manifests and a Kustomize overlay which are designed for deployment on Docker Desktop with Kubernetes enabled.  
+Compose Bridge converts your Docker Compose configuration into platform-specific deployment formats such as Kubernetes manifests. By default, it generates:
 
-It's a flexible tool that lets you either take advantage of the [default transformation](usage.md) or [create a custom transformation](customize.md) to suit specific project needs and requirements.  
+- Kubernetes manifests 
+- A Kustomize overlay
 
-Compose Bridge significantly simplifies the transition from Docker Compose to Kubernetes, making it easier for you to leverage the power of Kubernetes while maintaining the simplicity and efficiency of Docker Compose.
+These outputs are ready for deployment on Docker Desktop with [Kubernetes enabled](/manuals/desktop/settings-and-maintenance/settings.md#kubernetes).  
+
+Compose Bridge helps you bridge the gap between Compose and Kubernetes, making it easier to adopt Kubernetes while keeping the simplicity and efficiency of Compose.
+
+It's a flexible tool that lets you either take advantage of the [default transformation](usage.md) or [create a custom transformation](customize.md) to suit specific project needs and requirements. 
 
 ## How it works
 
-Compose Bridge uses transformations to let you convert a Compose model into another form. 
+Compose Bridge uses transformations to convert a Compose model into another form. 
 
 A transformation is packaged as a Docker image that receives the fully resolved Compose model as `/in/compose.yaml` and can produce any target format file under `/out`.
 
@@ -24,22 +29,31 @@ Compose Bridge provides its own transformation for Kubernetes using Go templates
 
 For more detailed information on how these transformations work and how you can customize them for your projects, see [Customize](customize.md).
 
-## Setup
+Compose Bridge also supports applications that use LLMs via Docker Model Runner.
+
+For more details, see [Use Model Runner](use-model-runner.md).
+
+## Apply organizational standards at scale 
+
+
+Compose Bridge supports custom transformation templates, which lets platform teams encode
+organizational standards once and apply them consistently whenever a `compose.yaml` file
+is converted to Kubernetes manifests or other formats.
 
-To get started with Compose Bridge, you need to:
+Developers continue to write standard Compose files. During conversion, Compose Bridge
+runs your custom transformation and automatically injects the required security contexts,
+resource limits, labels, and network policies into the output manifests — without
+requiring developers to know or manage those details.
 
-1. Download and install Docker Desktop version 4.33 and later.
-2. Sign in to your Docker account.
-3. Navigate to the **Features in development** tab in **Settings**. 
-4. From the **Experimental features** tab, select **Enable Compose Bridge**.
-5. Select **Apply & restart**.
+When your requirements change, update the transformation template in one place. Every team
+picks up the changes on their next conversion, with no edits to individual Compose files.
 
-## Feedback
+This separation of concerns keeps developers focused on application configuration, while
+platform teams control governance and enforce policy through the transformation layer.
 
-To give feedback, report bugs, or receive support, email `desktop-preview@docker.com`. There is also a dedicated Slack channel. To join, simply send an email to the provided address.
+To get started, see [Customize Compose Bridge](/manuals/compose/bridge/customize.md).
 
 ## What's next?
 
 - [Use Compose Bridge](usage.md)
 - [Explore how you can customize Compose Bridge](customize.md)
-- [Explore the advanced integration](advanced-integration.md)
diff --git a/content/manuals/compose/bridge/advanced-integration.md b/content/manuals/compose/bridge/advanced-integration.md
deleted file mode 100644
index db9e71837542..000000000000
--- a/content/manuals/compose/bridge/advanced-integration.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: Advanced integration
-linkTitle: Advanced
-weight: 30
-description: Learn about how Compose Bridge can function a kubectl plugin
-keywords: kubernetes, compose, compose bridge, plugin, advanced
----
-
-{{< summary-bar feature_name="Compose bridge" >}}
-
-Compose Bridge can also function as a `kubectl` plugin, allowing you to integrate its capabilities directly into your Kubernetes command-line operations. This integration simplifies the process of converting and deploying applications from Docker Compose to Kubernetes.
-
-## Use `compose-bridge` as a `kubectl` plugin
-
-To use the `compose-bridge` binary as a `kubectl` plugin, you need to make sure that the binary is available in your PATH and the name of the binary is prefixed with `kubectl-`. 
-
-1. Rename or copy the `compose-bridge` binary to `kubectl-compose_bridge`:
-
-    ```console
-    $ mv /path/to/compose-bridge /usr/local/bin/kubectl-compose_bridge
-    ```
-
-2. Ensure that the binary is executable:
-    
-    ```console
-    $ chmod +x /usr/local/bin/kubectl-compose_bridge
-    ```
-
-3. Verify that the plugin is recognized by `kubectl`:
-
-    ```console
-    $ kubectl plugin list
-    ```
-
-    In the output, you should see `kubectl-compose_bridge`.
-
-4. Now you can use `compose-bridge` as a `kubectl` plugin:
-
-    ```console
-   $ kubectl compose-bridge [command]
-    ```
-
-Replace `[command]` with any `compose-bridge` command you want to use.
diff --git a/content/manuals/compose/bridge/customize.md b/content/manuals/compose/bridge/customize.md
index d978ecf6b9fa..3834e65939b4 100644
--- a/content/manuals/compose/bridge/customize.md
+++ b/content/manuals/compose/bridge/customize.md
@@ -2,13 +2,15 @@
 title: Customize Compose Bridge 
 linkTitle: Customize
 weight: 20
-description: Learn about the Compose Bridge templates syntax
-keywords: compose, bridge, templates
+description: Learn how to customize Compose Bridge transformations using Go templates and Compose extensions
+keywords: docker compose bridge, customize compose bridge, compose bridge templates, compose to kubernetes, compose bridge transformation, go templates docker
 ---
 
 {{< summary-bar feature_name="Compose bridge" >}}
 
-This page explains how Compose Bridge utilizes templating to efficiently translate Docker Compose files into Kubernetes manifests. It also explain how you can customize these templates for your specific requirements and needs, or how you can build your own transformation. 
+You can customize how Compose Bridge converts your Docker Compose files into platform-specific formats. 
+
+This page explains how Compose Bridge uses templating to generate Kubernetes manifests and how you can customize these templates for your specific requirements and needs, or how you can build your own transformation.  
 
 ## How it works 
 
@@ -16,11 +18,11 @@ Compose bridge uses transformations to let you convert a Compose model into anot
 
 A transformation is packaged as a Docker image that receives the fully-resolved Compose model as `/in/compose.yaml` and can produce any target format file under `/out`.
 
-Compose Bridge provides its transformation for Kubernetes using Go templates, so that it is easy to extend for customization by just replacing or appending your own templates.
+Compose Bridge includes a default Kubernetes transformation using Go templates, which you can customize by replacing or extending templates.
 
-### Syntax
+### Template syntax
 
-Compose Bridge make use of templates to transform a Compose configuration file into Kubernetes manifests. Templates are plain text files that use the [Go templating syntax](https://pkg.go.dev/text/template). This enables the insertion of logic and data, making the templates dynamic and adaptable according to the Compose model.
+Compose Bridge makes use of templates to transform a Compose configuration file into Kubernetes manifests. Templates are plain text files that use the [Go templating syntax](https://pkg.go.dev/text/template). This enables the insertion of logic and data, making the templates dynamic and adaptable according to the Compose model.
 
 When a template is executed, it must produce a YAML file which is the standard format for Kubernetes manifests. Multiple files can be generated as long as they are separated by `---`
 
@@ -42,9 +44,11 @@ key: value
 {{ end }}
 ```
 
-### Input
+### Input model
+
+You can generate the input model by running `docker compose config`. 
 
-The input Compose model is the canonical YAML model you can get by running  `docker compose config`. Within the templates, data from the `compose.yaml` is accessed using dot notation, allowing you to navigate through nested data structures. For example, to access the deployment mode of a service, you would use `service.deploy.mode`:
+This canonical YAML output serves as the input for Compose Bridge transformations. Within the templates, data from the `compose.yaml` is accessed using dot notation, allowing you to navigate through nested data structures. For example, to access the deployment mode of a service, you would use `service.deploy.mode`:
 
  ```yaml
 # iterate over a yaml sequence
@@ -52,26 +56,28 @@ The input Compose model is the canonical YAML model you can get by running  `doc
   # access a nested attribute using dot notation
   {{ if eq $service.deploy.mode "global" }}
 kind: DaemonSet
-  {{ end }}
-{{ end }}
+  {{ end }}
+{{ end }}
 ```
 
-You can check the [Compose Specification JSON schema](https://github.com/compose-spec/compose-go/blob/main/schema/compose-spec.json) to have a full overview of the Compose model. This schema outlines all possible configurations and their data types in the Compose model. 
+You can check the [Compose Specification JSON schema](https://github.com/compose-spec/compose-go/blob/main/schema/compose-spec.json) for a full overview of the Compose model. This schema outlines all possible configurations and their data types in the Compose model. 
 
-### Helpers
+### Helper functions
 
 As part of the Go templating syntax, Compose Bridge offers a set of YAML helper functions designed to manipulate data within the templates efficiently:
 
-- `seconds`: Converts a [duration](/reference/compose-file/extension.md#specifying-durations) into an integer
-- `uppercase`: Converts a string into upper case characters
-- `title`: Converts a string by capitalizing the first letter of each word
-- `safe`: Converts a string into a safe identifier, replacing all characters (except lowercase a-z) with `-`
-- `truncate`: Removes the N first elements from a list
-- `join`: Groups elements from a list into a single string, using a separator
-- `base64`: Encodes a string as base64 used in Kubernetes for encoding secrets
-- `map`: Transforms a value according to mappings expressed as `"value -> newValue"` strings 
-- `indent`: Writes string content indented by N spaces
-- `helmValue`: Writes the string content as a template value in the final file
+| Function    | Description                                                                                                 |
+| ----------- | ----------------------------------------------------------------------------------------------------------- |
+| `seconds`   | Converts a [duration](/reference/compose-file/extension.md#specifying-durations) into an integer (seconds). |
+| `uppercase` | Converts a string to uppercase.                                                                             |
+| `title`     | Capitalizes the first letter of each word.                                                                  |
+| `safe`      | Converts a string into a safe identifier (replaces non-lowercase characters with `-`).                      |
+| `truncate`  | Removes the first N elements from a list.                                                                   |
+| `join`      | Joins list elements into a single string with a separator.                                                  |
+| `base64`    | Encodes a string as base64 (used for Kubernetes secrets).                                                   |
+| `map`       | Maps values using `“value -> newValue”` syntax.                                                             |
+| `indent`    | Indents string content by N spaces.                                                                         |
+| `helmValue` | Outputs a Helm-style template value.                                                                        |
 
 In the following example, the template checks if a healthcheck interval is specified for a service, applies the `seconds` function to convert this interval into seconds and assigns the value to the `periodSeconds` attribute.
 
@@ -81,38 +87,65 @@ In the following example, the template checks if a healthcheck interval is speci
 {{ end }}
 ```
 
-## Customization
+## Customize the default templates
 
 As Kubernetes is a versatile platform, there are many ways
 to map Compose concepts into Kubernetes resource definitions. Compose
 Bridge lets you customize the transformation to match your own infrastructure
-decisions and preferences, with various level of flexibility and effort.
+decisions and preferences, with varying level of flexibility and effort.
 
 ### Modify the default templates
 
-You can extract templates used by the default transformation `docker/compose-bridge-kubernetes`,
-by running `compose-bridge transformations create --from docker/compose-bridge-kubernetes my-template` 
-and adjusting the templates to match your needs.
+You can extract templates used by the default transformation `docker/compose-bridge-kubernetes`:
+
+```console
+$ docker compose bridge transformations create --from docker/compose-bridge-kubernetes my-template
+``` 
+
+The templates are extracted into a directory named after your template name, in this case `my-template`. It includes:
+
+- A Dockerfile that lets you create your own image to distribute your template
+- A directory containing the templating files
+
+Edit, [add](#add-your-own-templates), or remove templates as needed. 
 
-The templates are extracted into a directory named after your template name, in this case `my-template`.  
-It includes a Dockerfile that lets you create your own image to distribute your template, as well as a directory containing the templating files.  
-You are free to edit the existing files, delete them, or [add new ones](#add-your-own-templates) to subsequently generate Kubernetes manifests that meet your needs.  
 You can then use the generated Dockerfile to package your changes into a new transformation image, which you can then use with Compose Bridge:
 
 ```console
 $ docker build --tag mycompany/transform --push .
 ```
 
-You can then use your transformation as a replacement:
+Use your transformation as a replacement:
 
 ```console
-$ compose-bridge convert --transformations mycompany/transform 
+$ docker compose bridge convert --transformations mycompany/transform 
 ```
 
+#### Model Runner templates
+
+The default transformation also includes templates for applications that use LLMs:
+
+- `model-runner-deployment.tmpl`: Generates the Kubernetes deployment for Docker Model Runner. Customize it to change replica counts, image tags, resource requests and limits, GPU scheduling settings, tolerations, or additional environment variables.
+- `model-runner-service.tmpl`: Builds the service that exposes Docker Model Runner. Update it to switch between `ClusterIP`, `NodePort`, or `LoadBalancer` types, adjust ports, or add annotations for ingress and service meshes.
+- `model-runner-pvc.tmpl`: Defines the persistent volume claim used to store downloaded models. Edit it to set storage size, storage class, access modes, or volume annotations required by your storage provider.
+- `/overlays/model-runner/kustomization.yaml`: Kustomize overlay applied when you deploy Model Runner to a standalone Kubernetes cluster. Extend it to add patches for labels and annotations, attach `NetworkPolicies`, or include extra manifests.
+- `/overlays/desktop/deployment.tmpl`: Desktop-specific deployment template that keeps the in-cluster Model Runner scaled down and points workloads to the host endpoint. Adjust it if you change the Desktop endpoint or want to deploy Model Runner on Desktop instead of relying on the host service.
+
+Common customization scenarios:
+
+- Enable GPU support by adding vendor-specific resource requests, limits, and node selectors in `model-runner-deployment.tmpl`.
+- Increase or tune storage for model artifacts by editing `model-runner-pvc.tmpl` to set the desired size, storage class, or access mode.
+- Expose Model Runner outside the cluster by switching the service type in `model-runner-service.tmpl` or adding ingress annotations in the model-runner overlay.
+- Align cluster policies by adding labels, annotations, or NetworkPolicies through `/overlays/model-runner/kustomization.yaml`.
+
+For more details, see [Use Model Runner](use-model-runner.md).
+
 ### Add your own templates
 
 For resources that are not managed by Compose Bridge's default transformation, 
-you can build your own templates. The `compose.yaml` model may not offer all 
+you can build your own templates. 
+
+The `compose.yaml` model may not offer all 
 the configuration attributes required to populate the target manifest. If this is the case, you can
 then rely on Compose custom extensions to better describe the
 application, and offer an agnostic transformation.
@@ -152,7 +185,7 @@ when transforming Compose models into Kubernetes in addition to other
 transformations:
 
 ```console
-$ compose-bridge convert \
+$ docker compose bridge convert \
     --transformation docker/compose-bridge-kubernetes \
     --transformation mycompany/transform 
 ```
@@ -184,7 +217,3 @@ CMD ["/usr/bin/kompose", "convert", "-f", "/in/compose.yaml", "--out", "/out"]
 
 This Dockerfile bundles Kompose and defines the command to run this tool according
 to the Compose Bridge transformation contract.
-
-## What's next?
-
-- [Explore the advanced integration](advanced-integration.md)
diff --git a/content/manuals/compose/bridge/usage.md b/content/manuals/compose/bridge/usage.md
index 091457fbeefb..1f25bc2dcc32 100644
--- a/content/manuals/compose/bridge/usage.md
+++ b/content/manuals/compose/bridge/usage.md
@@ -2,13 +2,15 @@
 title: Use the default Compose Bridge transformation
 linkTitle: Usage
 weight: 10
-description: Learn about and use the Compose Bridge default transformation
-keywords: compose, bridge, kubernetes
+description: Learn how to use the default Compose Bridge transformation to convert Compose files into Kubernetes manifests
+keywords: docker compose bridge, compose kubernetes transform, kubernetes from compose, compose bridge convert, compose.yaml to kubernetes
 ---
 
 {{< summary-bar feature_name="Compose bridge" >}}
 
-Compose Bridge supplies an out-of-the box transformation for your Compose configuration file. Based on an arbitrary `compose.yaml` file, Compose Bridge produces:
+Compose Bridge includes a built-in transformation that automatically converts your Compose configuration into a set of Kubernetes manifests.
+
+Based on your `compose.yaml` file, it produces:
 
 - A [Namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) so all your resources are isolated and don't conflict with resources from other deployments.
 - A [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) with an entry for each and every [config](/reference/compose-file/configs.md) resource in your Compose application.
@@ -22,69 +24,97 @@ Compose Bridge supplies an out-of-the box transformation for your Compose config
 It also supplies a Kustomize overlay dedicated to Docker Desktop with:
  - `Loadbalancer` for services which need to expose ports on host.
  - A `PersistentVolumeClaim` to use the Docker Desktop storage provisioner `desktop-storage-provisioner` to handle volume provisioning more effectively.
- - A Kustomize file to link all the resources together.
+ - A `Kustomization.yaml` file to link all the resources together.
+
+If your Compose file defines a `models` section for a service, Compose Bridge automatically configures your deployment so your service can locate and use its models via Docker Model Runner.
+
+For each declared model, the transformation injects two environment variables:
+
+- `<MODELNAME>_URL`: The endpoint for Docker Model Runner serving that model  
+- `<MODELNAME>_MODEL`: The model’s name or identifier
+
+You can optionally customize these variable names using `endpoint_var` and `model_var`.
+
+The default transformation generates two different overlays - one for Docker Desktop whilst using a local instance of Docker Model Runner, and a `model-runner` overlay with all the relevant Kubernetes resources to deploy Docker Model Runner in a pod. 
+
+| Environment    | Endpoint                                        |
+| -------------- | ----------------------------------------------- |
+| Docker Desktop | `http://host.docker.internal:12434/engines/v1/` |
+| Kubernetes     | `http://model-runner/engines/v1/`               |
+
+
+For more details, see [Use Model Runner](use-model-runner.md).
 
 ## Use the default Compose Bridge transformation
 
-To use the default transformation run the following command:
+To convert your Compose file using the default transformation:
 
 ```console
-$ compose-bridge convert
+$ docker compose bridge convert
 ```
 
-Compose looks for a `compose.yaml` file inside the current directory and then converts it.
+Compose looks for a `compose.yaml` file inside the current directory and generates Kubernetes manifests.
+
+Example output:
 
-The following output is displayed 
 ```console
-$ compose-bridge convert -f compose.yaml 
-Kubernetes resource api-deployment.yaml created
-Kubernetes resource db-deployment.yaml created
-Kubernetes resource web-deployment.yaml created
-Kubernetes resource api-expose.yaml created
-Kubernetes resource db-expose.yaml created
-Kubernetes resource web-expose.yaml created
-Kubernetes resource 0-avatars-namespace.yaml created
+$ docker compose -f compose.yaml bridge convert
+Kubernetes resource backend-deployment.yaml created
+Kubernetes resource frontend-deployment.yaml created
+Kubernetes resource backend-expose.yaml created
+Kubernetes resource frontend-expose.yaml created
+Kubernetes resource 0-my-project-namespace.yaml created
 Kubernetes resource default-network-policy.yaml created
-Kubernetes resource private-network-policy.yaml created
-Kubernetes resource public-network-policy.yaml created
-Kubernetes resource db-db_data-persistentVolumeClaim.yaml created
-Kubernetes resource api-service.yaml created
-Kubernetes resource web-service.yaml created
+Kubernetes resource backend-service.yaml created
+Kubernetes resource frontend-service.yaml created
 Kubernetes resource kustomization.yaml created
-Kubernetes resource db-db_data-persistentVolumeClaim.yaml created
-Kubernetes resource api-service.yaml created
-Kubernetes resource web-service.yaml created
+Kubernetes resource backend-deployment.yaml created
+Kubernetes resource frontend-deployment.yaml created
+Kubernetes resource backend-service.yaml created
+Kubernetes resource frontend-service.yaml created
+Kubernetes resource kustomization.yaml created
+Kubernetes resource model-runner-configmap.yaml created
+Kubernetes resource model-runner-deployment.yaml created
+Kubernetes resource model-runner-service.yaml created
+Kubernetes resource model-runner-volume-claim.yaml created
 Kubernetes resource kustomization.yaml created
 ```
 
-These files are then stored within your project in the `/out` folder. 
+All generated files are stored in the `/out` directory in your project.
 
-The Kubernetes manifests can then be used to run the application on Kubernetes using
-the standard deployment command `kubectl apply -k out/overlays/desktop/`.
+## Deploy the generated manifests
 
-> [!NOTE]
+> [!IMPORTANT]
 >
-> Make sure you have enabled Kubernetes in Docker Desktop before you deploy your Compose Bridge transformations.
-
-If you want to convert a `compose.yaml` file that is located in another directory, you can run:
-
-```console
-$ compose-bridge convert -f <path-to-file>/compose.yaml 
-```
+> Before you deploy your Compose Bridge transformations, make sure you have [enabled Kubernetes](/manuals/desktop/settings-and-maintenance/settings.md#kubernetes) in Docker Desktop.
 
-To see all available flags, run:
+Once the manifests are generated, deploy them to your local Kubernetes cluster:
 
 ```console
-$ compose-bridge convert --help
+$ kubectl apply -k out/overlays/desktop/
 ```
 
 > [!TIP]
 >
-> You can now convert and deploy your Compose project to a Kubernetes cluster from the Compose file viewer.
+> You can convert and deploy your Compose project to a Kubernetes cluster from the Compose file viewer.
 > 
 > Make sure you are signed in to your Docker account, navigate to your container in the **Containers** view, and in the top-right corner select **View configurations** and then **Convert and Deploy to Kubernetes**. 
 
+## Additional commands
+
+Convert a `compose.yaml` file located in another directory:
+
+```console
+$ docker compose -f <path-to-file>/compose.yaml bridge convert
+```
+
+To see all available flags, run:
+
+```console
+$ docker compose bridge convert --help
+```
+
 ## What's next?
 
 - [Explore how you can customize Compose Bridge](customize.md)
-- [Explore the advanced integration](advanced-integration.md)
+- [Use Model Runner](use-model-runner.md).
\ No newline at end of file
diff --git a/content/manuals/compose/bridge/use-model-runner.md b/content/manuals/compose/bridge/use-model-runner.md
new file mode 100644
index 000000000000..7e3cb7923d18
--- /dev/null
+++ b/content/manuals/compose/bridge/use-model-runner.md
@@ -0,0 +1,91 @@
+---
+title: Use Docker Model Runner with Compose Bridge 
+linkTitle: Use Model Runner
+weight: 30
+description: How to use Docker Model Runner with Compose Bridge for consistent deployments
+keywords: docker compose bridge, customize compose bridge, compose bridge templates, compose to kubernetes, compose bridge transformation, go templates docker, model runner, ai, llms
+---
+
+Compose Bridge supports model-aware deployments. It can deploy and configure Docker Model Runner, a lightweight service that hosts and serves machine LLMs.
+
+This reduces manual setup for LLM-enabled services and keeps deployments consistent across Docker Desktop and Kubernetes environments.
+
+If you have a `models` top-level element in your `compose.yaml` file, Compose Bridge:
+
+- Automatically injects environment variables for each model’s endpoint and name.
+- Configures model endpoints differently for Docker Desktop vs Kubernetes.
+- Optionally deploys Docker Model Runner in Kubernetes when enabled in Helm values
+
+## Configure model runner settings
+
+When deploying using generated Helm Charts, you can control the model runner configuration through Helm values.
+
+```yaml
+# Model Runner settings
+modelRunner:
+    # Set to false for Docker Desktop (uses host instance)
+    # Set to true for standalone Kubernetes clusters
+    enabled: false
+    # Endpoint used when enabled=false (Docker Desktop)
+    hostEndpoint: "http://host.docker.internal:12434/engines/v1/"
+    # Deployment settings when enabled=true
+    image: "docker/model-runner:latest"
+    imagePullPolicy: "IfNotPresent"
+    # GPU support
+    gpu:
+        enabled: false
+        vendor: "nvidia" # nvidia or amd
+        count: 1
+    # Node scheduling (uncomment and customize as needed)
+    # nodeSelector:
+    #   accelerator: nvidia-tesla-t4
+    # tolerations: []
+    # affinity: {}
+
+    # Security context
+    securityContext:
+        allowPrivilegeEscalation: false
+    # Environment variables (uncomment and add as needed)
+    # env:
+    #   DMR_ORIGINS: "http://localhost:31246"
+    resources:
+        limits:
+            cpu: "1000m"
+            memory: "2Gi"
+        requests:
+            cpu: "100m"
+            memory: "256Mi"
+    # Storage for models
+    storage:
+        size: "100Gi"
+        storageClass: "" # Empty uses default storage class
+    # Models to pre-pull
+    models:
+        - ai/qwen2.5:latest
+        - ai/mxbai-embed-large
+```
+
+## Deploying a model runner
+
+### Docker Desktop
+
+When `modelRunner.enabled` is `false`, Compose Bridge configures your workloads to connect to Docker Model Runner running on the host:
+
+```text
+http://host.docker.internal:12434/engines/v1/
+```
+
+The endpoint is automatically injected into your service containers.
+
+### Kubernetes
+
+When `modelRunner.enabled` is `true`, Compose Bridge uses the generated manifests to deploy Docker Model Runner in your cluster, including:
+
+- Deployment: Runs the `docker-model-runner` container
+- Service: Exposes port `80` (maps to container port `12434`)
+- `PersistentVolumeClaim`: Stores model files
+
+The `modelRunner.enabled` setting also determines the number of replicas for the in-cluster `model-runner-deployment`:
+
+- When `true`, the Kubernetes deployment replica count is set to 1, and Docker Model Runner is deployed in the cluster.
+- When `false`, the Kubernetes deployment replica count is 0 (no in-cluster Model Runner). On Docker Desktop, workloads still connect to the host Model Runner as described above.
\ No newline at end of file
diff --git a/content/manuals/compose/compose-sdk.md b/content/manuals/compose/compose-sdk.md
new file mode 100644
index 000000000000..b2616a88b5db
--- /dev/null
+++ b/content/manuals/compose/compose-sdk.md
@@ -0,0 +1,177 @@
+---
+description: Integrate Docker Compose directly into your applications with the Compose SDK.
+keywords: docker compose sdk, compose api, Docker developer SDK
+title: Using the Compose SDK
+linkTitle: Compose SDK 
+weight: 60
+---
+
+{{< summary-bar feature_name="Compose SDK" >}}
+
+The `docker/compose` package can be used as a Go library by third-party applications to programmatically manage
+containerized applications defined in Compose files. This SDK provides a comprehensive API that lets you
+integrate Compose functionality directly into your applications, allowing you to load, validate, and manage
+multi-container environments without relying on the Compose CLI. 
+
+Whether you need to orchestrate containers as part of
+a deployment pipeline, build custom management tools, or embed container orchestration into your application, the
+Compose SDK offers the same powerful capabilities that drive the Docker Compose command-line tool.
+
+## Set up the SDK
+
+To get started, create an SDK instance using the `NewComposeService()` function, which initializes a service with the
+necessary configuration to interact with the Docker daemon and manage Compose projects. This service instance provides
+methods for all core Compose operations including creating, starting, stopping, and removing containers, as well as
+loading and validating Compose files. The service handles the underlying Docker API interactions and resource
+management, allowing you to focus on your application logic.
+
+### Requirements
+
+Before using the SDK, make sure you're using a compatible version of the Docker CLI. 
+
+```go
+require (
+    github.com/docker/cli v28.5.2+incompatible
+)
+```
+
+Docker CLI version 29.0.0 and later depends on the new `github.com/moby/moby` module, whereas Docker Compose v5 currently depends on `github.com/docker/docker`. This means you need to pin `docker/cli v28.5.2+incompatible` to ensure compatibility and avoid build errors.
+
+### Example usage
+
+Here's a basic example demonstrating how to load a Compose project and start the services:
+
+```go
+package main
+
+import (
+    "context"
+    "log"
+
+	"github.com/docker/cli/cli/command"
+	"github.com/docker/cli/cli/flags"
+    "github.com/docker/compose/v5/pkg/api"
+    "github.com/docker/compose/v5/pkg/compose"
+)
+
+func main() {
+    ctx := context.Background()
+
+	dockerCLI, err := command.NewDockerCli()
+	if err != nil {
+		log.Fatalf("Failed to create docker CLI: %v", err)
+	}
+	err = dockerCLI.Initialize(&flags.ClientOptions{})
+	if err != nil {
+		log.Fatalf("Failed to initialize docker CLI: %v", err)
+	}
+	
+    // Create a new Compose service instance
+    service, err := compose.NewComposeService(dockerCLI)
+    if err != nil {
+        log.Fatalf("Failed to create compose service: %v", err)
+    }
+
+    // Load the Compose project from a compose file
+    project, err := service.LoadProject(ctx, api.ProjectLoadOptions{
+        ConfigPaths: []string{"compose.yaml"},
+        ProjectName: "my-app",
+    })
+    if err != nil {
+        log.Fatalf("Failed to load project: %v", err)
+    }
+
+    // Start the services defined in the Compose file
+    err = service.Up(ctx, project, api.UpOptions{
+        Create: api.CreateOptions{},
+        Start:  api.StartOptions{},
+    })
+    if err != nil {
+        log.Fatalf("Failed to start services: %v", err)
+    }
+
+    log.Printf("Successfully started project: %s", project.Name)
+}
+```
+
+This example demonstrates the core workflow - creating a service instance, loading a project from a Compose file, and
+starting the services. The SDK provides many additional operations for managing the lifecycle of your containerized
+application.
+
+## Customizing the SDK
+
+The `NewComposeService()` function accepts optional `compose.Option` parameters to customize the SDK behavior. These
+options allow you to configure I/O streams, concurrency limits, dry-run mode, and other advanced features.
+
+```go
+    // Create a custom output buffer to capture logs
+    var outputBuffer bytes.Buffer
+
+    // Create a compose service with custom options
+    service, err := compose.NewComposeService(dockerCLI,
+        compose.WithOutputStream(&outputBuffer),          // Redirect output to custom writer
+        compose.WithErrorStream(os.Stderr),               // Use stderr for errors
+        compose.WithMaxConcurrency(4),                    // Limit concurrent operations
+        compose.WithPrompt(compose.AlwaysOkPrompt()),     // Auto-confirm all prompts
+    )
+```
+
+### Available options
+
+- `WithOutputStream(io.Writer)`: Redirect standard output to a custom writer
+- `WithErrorStream(io.Writer)`: Redirect error output to a custom writer
+- `WithInputStream(io.Reader)`: Provide a custom input stream for interactive prompts
+- `WithStreams(out, err, in)`: Set all I/O streams at once
+- `WithMaxConcurrency(int)`: Limit the number of concurrent operations against the Docker API
+- `WithPrompt(Prompt)`: Customize user confirmation behavior (use `AlwaysOkPrompt()` for non-interactive mode)
+- `WithDryRun`: Run operations in dry-run mode without actually applying changes
+- `WithContextInfo(api.ContextInfo)`: Set custom Docker context information
+- `WithProxyConfig(map[string]string)`: Configure HTTP proxy settings for builds
+- `WithEventProcessor(progress.EventProcessor)`: Receive progress events and operation notifications
+
+These options provide fine-grained control over the SDK's behavior, making it suitable for various integration
+scenarios including CLI tools, web services, automation scripts, and testing environments.
+
+## Tracking operations with `EventProcessor`
+
+The `EventProcessor` interface allows you to monitor Compose operations in real-time by receiving events about changes
+applied to Docker resources such as images, containers, volumes, and networks. This is particularly useful for building
+user interfaces, logging systems, or monitoring tools that need to track the progress of Compose operations.
+
+### Understanding `EventProcessor`
+
+A Compose operation, such as `up`, `down`, `build`, performs a series of changes to Docker resources. The
+`EventProcessor` receives notifications about these changes through three key methods:
+
+- `Start(ctx, operation)`: Called when a Compose operation begins, for example `up`
+- `On(events...)`: Called with progress events for individual resource changes, for example, container starting, image
+  being pulled
+- `Done(operation, success)`: Called when the operation completes, indicating success or failure
+
+Each event contains information about the resource being modified, its current status, and progress indicators when
+applicable (such as download progress for image pulls).
+
+### Event status types
+
+Events report resource changes with the following status types:
+
+- Working: Operation is in progress, for example, creating, starting, pulling
+- Done: Operation completed successfully
+- Warning: Operation completed with warnings
+- Error: Operation failed
+
+Common status text values include: `Creating`, `Created`, `Starting`, `Started`, `Running`, `Stopping`, `Stopped`,
+`Removing`, `Removed`, `Building`, `Built`, `Pulling`, `Pulled`, and more.
+
+### Built-in `EventProcessor` implementations
+
+The SDK provides three ready-to-use `EventProcessor` implementations:
+
+- `progress.NewTTYWriter(io.Writer)`: Renders an interactive terminal UI with progress bars and task lists
+  (similar to the Docker Compose CLI output)
+- `progress.NewPlainWriter(io.Writer)`: Outputs simple text-based progress messages suitable for non-interactive
+  environments or log files
+- `progress.NewJSONWriter()`: Render events as JSON objects
+- `progress.NewQuietWriter()`: (Default) Silently processes events without producing any output
+
+Using `EventProcessor`, a custom UI can be plugged into `docker/compose`.
\ No newline at end of file
diff --git a/content/manuals/compose/gettingstarted.md b/content/manuals/compose/gettingstarted.md
index 70edc888e4ac..7c65a1a6f376 100644
--- a/content/manuals/compose/gettingstarted.md
+++ b/content/manuals/compose/gettingstarted.md
@@ -1,5 +1,5 @@
 ---
-description: Check out this tutorial on how to use Docker Compose from defining application
+description: Follow this hands-on tutorial to learn how to use Docker Compose from defining application
   dependencies to experimenting with commands.
 keywords: docker compose example, docker compose tutorial, how to use docker compose,
   running docker compose, how to run docker compose, docker compose build image, docker
@@ -8,15 +8,13 @@ keywords: docker compose example, docker compose tutorial, how to use docker com
 title: Docker Compose Quickstart
 linkTitle: Quickstart
 weight: 30
+aliases:
+- /compose/support-and-feedback/samples-for-compose/
 ---
 
 This tutorial aims to introduce fundamental concepts of Docker Compose by guiding you through the development of a basic Python web application. 
 
-Using the Flask framework, the application features a hit counter in Redis, providing a practical example of how Docker Compose can be applied in web development scenarios. 
-
-The concepts demonstrated here should be understandable even if you're not familiar with Python. 
-
-This is a non-normative example that demonstrates core Compose functionality. 
+Using the Flask framework, the application features a hit counter in Redis, providing a practical example of how Docker Compose can be applied in web development scenarios. The concepts demonstrated here should be understandable even if you're not familiar with Python. 
 
 ## Prerequisites
 
@@ -25,330 +23,523 @@ Make sure you have:
 - [Installed the latest version of Docker Compose](/manuals/compose/install/_index.md)
 - A basic understanding of Docker concepts and how Docker works
 
-## Step 1: Set up
+## Step 1: Set up the project
 
 1. Create a directory for the project:
 
    ```console
-   $ mkdir composetest
-   $ cd composetest
+   $ mkdir compose-demo
+   $ cd compose-demo
    ```
 
-2. Create a file called `app.py` in your project directory and paste the following code in:
+2. Create `app.py` in your project directory and add the following:
 
    ```python
-   import time
-
+   import os
    import redis
    from flask import Flask
 
    app = Flask(__name__)
-   cache = redis.Redis(host='redis', port=6379)
-
-   def get_hit_count():
-       retries = 5
-       while True:
-           try:
-               return cache.incr('hits')
-           except redis.exceptions.ConnectionError as exc:
-               if retries == 0:
-                   raise exc
-               retries -= 1
-               time.sleep(0.5)
-
-   @app.route('/')
-   def hello():
-       count = get_hit_count()
-       return f'Hello World! I have been seen {count} times.\n'
-    ```
+   cache = redis.Redis(
+       host=os.getenv("REDIS_HOST", "redis"),
+       port=int(os.getenv("REDIS_PORT", "6379")),
+   )
 
-   In this example, `redis` is the hostname of the redis container on the
-   application's network and the default port, `6379` is used.
+   @app.route("/")
+   def hello():
+       count = cache.incr("hits")
+       return f"Hello from Docker! I have been seen {count} time(s).\n"
+   ```
 
-   > [!NOTE]
-   >
-   > Note the way the `get_hit_count` function is written. This basic retry
-   > loop attempts the request multiple times if the Redis service is
-   > not available. This is useful at startup while the application comes
-   > online, but also makes the application more resilient if the Redis
-   > service needs to be restarted anytime during the app's lifetime. In a
-   > cluster, this also helps handling momentary connection drops between
-   > nodes.
+   The app reads its Redis connection details from environment variables, with sensible defaults so it works out of the box.
 
-3. Create another file called `requirements.txt` in your project directory and
-   paste the following code in:
+3. Create `requirements.txt` in your project directory and add the following:
 
    ```text
    flask
    redis
    ```
 
-4. Create a `Dockerfile` and paste the following code in:
+4. Create a `Dockerfile`:
 
    ```dockerfile
    # syntax=docker/dockerfile:1
-   FROM python:3.10-alpine
+   
+   # Build an image with the Python 3.12 image
+   FROM python:3.12-alpine
+   
+   # Set the working directory to `/code`
    WORKDIR /code
+   
+   # Set environment variables used by the `flask` command
    ENV FLASK_APP=app.py
    ENV FLASK_RUN_HOST=0.0.0.0
+   
+   # Install `gcc` and other dependencies
    RUN apk add --no-cache gcc musl-dev linux-headers
-   COPY requirements.txt requirements.txt
+   
+   # Copy `requirements.txt`
+   COPY requirements.txt .
+   
+   # Install the Python dependencies
    RUN pip install -r requirements.txt
-   EXPOSE 5000
+   
+   # Copy the current directory `.` in the project to the workdir `.` in the image
    COPY . .
+   
+   EXPOSE 5000
+   
+   # Set the default command for the container to `flask run --debug`
    CMD ["flask", "run", "--debug"]
    ```
 
-   {{< accordion title="Understand the Dockerfile" >}}
+   > [!IMPORTANT]
+   >
+   > Make sure the file is named `Dockerfile` with no extension. Some editors add `.txt`
+   > automatically, which causes the build to fail.
 
-   This tells Docker to:
+   For more information on how to write Dockerfiles, see the [Dockerfile reference](/reference/dockerfile/).
 
-   * Build an image starting with the Python 3.10 image.
-   * Set the working directory to `/code`.
-   * Set environment variables used by the `flask` command.
-   * Install gcc and other dependencies
-   * Copy `requirements.txt` and install the Python dependencies.
-   * Add metadata to the image to describe that the container is listening on port 5000
-   * Copy the current directory `.` in the project to the workdir `.` in the image.
-   * Set the default command for the container to `flask run --debug`.
+5. Create a `.env` file to hold configuration values:
 
-   {{< /accordion >}}
+   ```text
+   APP_PORT=8000
+   REDIS_HOST=redis
+   REDIS_PORT=6379
+   ```
 
-   > [!IMPORTANT]
-   >
-   >Check that the `Dockerfile` has no file extension like `.txt`. Some editors may append this file extension automatically which results in an error when you run the application.
+   Compose automatically reads `.env` and makes these values available for interpolation
+   in your `compose.yaml`. For this example the gains are modest, but in practice,
+   keeping configuration out of the Compose file makes it easier to:
+   - Change values across environments without editing YAML
+   - Avoid committing secrets to version control
+   - Reuse values across multiple services
 
-   For more information on how to write Dockerfiles, see the [Dockerfile reference](/reference/dockerfile/).
+6. Create a `.dockerignore` file to keep unnecessary files out of your build context:
 
-## Step 2: Define services in a Compose file
+   ```text
+   .env
+   *.pyc
+   __pycache__
+   redis-data
+   ```
 
-Compose simplifies the control of your entire application stack, making it easy to manage services, networks, and volumes in a single, comprehensible YAML configuration file.
+   Docker sends everything in your project directory to the daemon when it builds an image.
+   Without `.dockerignore`, that includes your `.env` file (which may contain secrets) and
+   any cached Python bytecode. Excluding them keeps builds fast and avoids accidentally
+   baking sensitive values into an image layer.
 
-Create a file called `compose.yaml` in your project directory and paste
-the following:
+## Step 2: Define and start your services
 
-```yaml
-services:
-  web:
-    build: .
-    ports:
-      - "8000:5000"
-  redis:
-    image: "redis:alpine"
-```
+Compose simplifies the control of your entire application stack, making it easy to manage services, networks, and volumes in a single YAML configuration file. 
 
-This Compose file defines two services: `web` and `redis`. 
+1. Create `compose.yaml` in your project directory and paste the following:
 
-The `web` service uses an image that's built from the `Dockerfile` in the current directory.
-It then binds the container and the host machine to the exposed port, `8000`. This example service uses the default port for the Flask web server, `5000`.
+   ```yaml
+   services:
+     web:
+       build: .
+       ports:
+         - "${APP_PORT}:5000"
+       environment:
+         - REDIS_HOST=${REDIS_HOST}
+         - REDIS_PORT=${REDIS_PORT}
 
-The `redis` service uses a public [Redis](https://registry.hub.docker.com/_/redis/) 
-image pulled from the Docker Hub registry.
+     redis:
+       image: redis:alpine
+   ```
+
+   This Compose file defines two services: 
 
-For more information on the `compose.yaml` file, see [How Compose works](compose-application-model.md).
+   - The `web` service uses an image that's built from the `Dockerfile` in the current directory. It maps port `8000` on the host to port `5000` on the container where Flask listens by default.
 
-## Step 3: Build and run your app with Compose
+   - The `redis` service uses a public [Redis](https://registry.hub.docker.com/_/redis/) image pulled from the Docker Hub registry.
 
-With a single command, you create and start all the services from your configuration file.
+   For more information on the `compose.yaml` file, see [How Compose works](compose-application-model.md).
 
-1. From your project directory, start up your application by running `docker compose up`.
+2. Start up your application: 
 
    ```console
    $ docker compose up
+   ```
+
+   With a single command, you create and start all the services from your configuration file. Compose builds your web image, pulls the Redis image, and starts both containers. 
 
-   Creating network "composetest_default" with the default driver
-   Creating composetest_web_1 ...
-   Creating composetest_redis_1 ...
-   Creating composetest_web_1
-   Creating composetest_redis_1 ... done
-   Attaching to composetest_web_1, composetest_redis_1
-   web_1    |  * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
-   redis_1  | 1:C 17 Aug 22:11:10.480 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
-   redis_1  | 1:C 17 Aug 22:11:10.480 # Redis version=4.0.1, bits=64, commit=00000000, modified=0, pid=1, just started
-   redis_1  | 1:C 17 Aug 22:11:10.480 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
-   web_1    |  * Restarting with stat
-   redis_1  | 1:M 17 Aug 22:11:10.483 * Running mode=standalone, port=6379.
-   redis_1  | 1:M 17 Aug 22:11:10.483 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
-   web_1    |  * Debugger is active!
-   redis_1  | 1:M 17 Aug 22:11:10.483 # Server initialized
-   redis_1  | 1:M 17 Aug 22:11:10.483 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
-   web_1    |  * Debugger PIN: 330-787-903
-   redis_1  | 1:M 17 Aug 22:11:10.483 * Ready to accept connections
+3. Open `http://localhost:8000`. You should see:
+
+   ```text
+   Hello from Docker! I have been seen 1 time(s).
    ```
 
-   Compose pulls a Redis image, builds an image for your code, and starts the
-   services you defined. In this case, the code is statically copied into the image at build time.
+   Refresh the page — the counter increments on each visit.
 
-2. Enter `http://localhost:8000/` in a browser to see the application running.
+   This minimal setup works, but it has two problems you'll fix in the next steps:
 
-   If this doesn't resolve, you can also try `http://127.0.0.1:8000`.
+   - Startup race: `web` starts at the same time as `redis`. If Redis isn't ready yet,
+   the Flask app fails to connect and crashes.
+   - No persistence: If you run `docker compose down` followed by `docker compose up`, the
+   counter resets to zero. `docker compose down` removes the containers, and with them
+   any data written to the container's writable layer. `docker compose stop` preserves
+   the containers so data survives, but you can't rely on that in production where
+   containers are regularly replaced.
 
-   You should see a message in your browser saying:
+4. Stop the stack before moving on:
 
-   ```text
-   Hello World! I have been seen 1 times.
+   ```console
+   $ docker compose down
    ```
 
-   ![hello world in browser](images/quick-hello-world-1.png)
+## Step 3: Fix the startup race with health checks
 
-3. Refresh the page.
+To fix the startup race, Compose needs to wait until `redis` is confirmed healthy before
+starting `web`.
 
-   The number should increment.
+1. Update `compose.yaml`:
 
-   ```text
-   Hello World! I have been seen 2 times.
+   ```yaml
+   services:
+     web:
+       build: .
+       ports:
+         - "${APP_PORT}:5000"
+       environment:
+         - REDIS_HOST=${REDIS_HOST}
+         - REDIS_PORT=${REDIS_PORT}
+       depends_on:
+         redis:
+           condition: service_healthy
+
+     redis:
+       image: redis:alpine
+       healthcheck:
+         test: ["CMD", "redis-cli", "ping"]
+         interval: 5s
+         timeout: 3s
+         retries: 5
+         start_period: 10s
    ```
 
-   ![hello world in browser](images/quick-hello-world-2.png)
+   The `healthcheck` block tells Compose how to test whether Redis is ready:
 
-4. Switch to another terminal window, and type `docker image ls` to list local images.
+   - `test` is the command Compose runs inside the container to check its health.
+     `redis-cli ping` connects to Redis and expects a `PONG` response — if it gets one,
+     the container is healthy.
+   - `start_period` gives Redis 10 seconds to initialize before health checks begin.
+     Any failures during this window don't count toward the retry limit.
+   - `interval` runs the check every 5 seconds after the start period has elapsed.
+   - `timeout` gives each check 3 seconds to respond before treating it as a failure.
+   - `retries` sets how many consecutive failures are allowed before Compose marks the
+     container as unhealthy. With `interval: 5s` and `retries: 5`, Compose will wait up
+     to 25 seconds before giving up.
 
-   Listing images at this point should return `redis` and `web`.
+2. Start the stack to confirm the ordering is fixed:
 
    ```console
-   $ docker image ls
-
-   REPOSITORY        TAG           IMAGE ID      CREATED        SIZE
-   composetest_web   latest        e2c21aa48cc1  4 minutes ago  93.8MB
-   python            3.4-alpine    84e6077c7ab6  7 days ago     82.5MB
-   redis             alpine        9d8fa9aa0e5b  3 weeks ago    27.5MB
+   $ docker compose up
    ```
 
-   You can inspect images with `docker inspect <tag or id>`.
-
-5. Stop the application, either by running `docker compose down`
-   from within your project directory in the second terminal, or by
-   hitting `CTRL+C` in the original terminal where you started the app.
-
-## Step 4: Edit the Compose file to use Compose Watch
-
-Edit the `compose.yaml` file in your project directory to use `watch` so you can preview your running Compose services which are automatically updated as you edit and save your code:
-
-```yaml
-services:
-  web:
-    build: .
-    ports:
-      - "8000:5000"
-    develop:
-      watch:
-        - action: sync
-          path: .
-          target: /code
-  redis:
-    image: "redis:alpine"
-```
+   You should see something similar to:
 
-Whenever a file is changed, Compose syncs the file to the corresponding location under `/code` inside the container. Once copied, the bundler updates the running application without a restart.
+   ```text
+   [+] Running 2/2
+   ✔ Container compose-demo-redis-1  Healthy                       0.0s
+   ```
 
-For more information on how Compose Watch works, see [Use Compose Watch](/manuals/compose/how-tos/file-watch.md). Alternatively, see [Manage data in containers](/manuals/engine/storage/volumes.md) for other options.
+3. Open `http://localhost:8000` to confirm the app is still working, then stop the stack before moving on:
 
-> [!NOTE]
->
-> For this example to work, the `--debug` option is added to the `Dockerfile`. The `--debug` option in Flask enables automatic code reload, making it possible to work on the backend API without the need to restart or rebuild the container.
-> After changing the `.py` file, subsequent API calls will use the new code, but the browser UI will not automatically refresh in this small example. Most frontend development servers include native live reload support that works with Compose.
+   ```console
+   $ docker compose down
+   ```
 
-## Step 5: Re-build and run the app with Compose
+## Step 4: Enable Compose Watch for live updates
 
-From your project directory, type `docker compose watch` or `docker compose up --watch` to build and launch the app and start the file watch mode.
+Without Compose Watch, every code change requires you to stop the stack, rebuild the image, and restart the containers. Compose Watch eliminates that cycle by automatically syncing changes into your running container as you save files.
 
-```console
-$ docker compose watch
-[+] Running 2/2
- ✔ Container docs-redis-1 Created                                                                                                                                                                                                        0.0s
- ✔ Container docs-web-1    Recreated                                                                                                                                                                                                      0.1s
-Attaching to redis-1, web-1
-         ⦿ watch enabled
-...
-```
+1. Update `compose.yaml` to add the `develop.watch` block to the `web` service:
+   
+   ```yaml
+   services:
+     web:
+       build: .
+       ports:
+         - "${APP_PORT}:5000"
+       environment:
+         - REDIS_HOST=${REDIS_HOST}
+         - REDIS_PORT=${REDIS_PORT}
+       depends_on:
+         redis:
+           condition: service_healthy
+       develop:
+         watch:
+           - action: sync+restart
+             path: .
+             target: /code
+           - action: rebuild
+             path: requirements.txt
 
-Check the `Hello World` message in a web browser again, and refresh to see the
-count increment.
+     redis:
+       image: redis:alpine
+       healthcheck:
+         test: ["CMD", "redis-cli", "ping"]
+         interval: 5s
+         timeout: 3s
+         retries: 5
+         start_period: 10s
+   ```
 
-## Step 6: Update the application
+   The `watch` block defines two rules:
+   - The `sync+restart` action watches your project directory (`.`) on the host. When a file changes, Compose copies any changed files into `/code` inside the running container, then restarts the container. Because the container restarts with the updated files already in place, Flask starts up reading the new code directly — no manual rebuild or restart needed. 
+   - The `rebuild` action on `requirements.txt` triggers a full image rebuild whenever you add a new dependency, since installing packages requires rebuilding the image, not just syncing files.
+   
+2. Start the stack with Watch enabled:
 
-To see Compose Watch in action:
+   ```console
+   $ docker compose up --watch
+   ```
 
-1. Change the greeting in `app.py` and save it. For example, change the `Hello World!`
-message to `Hello from Docker!`:
+3. Make a live change. Open `app.py` and update the greeting:
 
    ```python
-   return f'Hello from Docker! I have been seen {count} times.\n'
+   return f"Hello from Compose Watch! I have been seen {count} time(s).\n"
    ```
 
-2. Refresh the app in your browser. The greeting should be updated, and the
-counter should still be incrementing.
+4. Save the file. Compose Watch detects the change and syncs it immediately:
 
-   ![hello world in browser](images/quick-hello-world-3.png)
+   ```text
+   Syncing service "web" after changes were detected
+   ```
 
-3. Once you're done, run `docker compose down`.
+5. Refresh `http://localhost:8000`. The updated greeting appears without any restart
+   and the counter should still be incrementing.
 
-## Step 7: Split up your services
+6. Stop the stack before moving on:
 
-Using multiple Compose files lets you customize a Compose application for different environments or workflows. This is useful for large applications that may use dozens of containers, with ownership distributed across multiple teams. 
+   ```console
+   $ docker compose down
+   ```
 
-1. In your project folder, create a new Compose file called `infra.yaml`.
+   For more information on how Compose Watch works, see [Use Compose Watch](/manuals/compose/how-tos/file-watch.md).
 
-2. Cut the Redis service from your `compose.yaml` file and paste it into your new `infra.yaml` file. Make sure you add the `services` top-level attribute at the top of your file. Your `infra.yaml` file should now look like this:
+## Step 5: Persist data with named volumes
+
+Each time you stop and restart the stack the visit counter resets to zero. Redis data
+lives inside the container, so it disappears when the container is removed. A named
+volume fixes this by storing the data on the host, outside the container lifecycle.
+
+1. Update `compose.yaml`:
 
    ```yaml
    services:
+     web:
+       build: .
+       ports:
+         - "${APP_PORT}:5000"
+       environment:
+         - REDIS_HOST=${REDIS_HOST}
+         - REDIS_PORT=${REDIS_PORT}
+       depends_on:
+         redis:
+           condition: service_healthy
+       develop:
+         watch:
+           - action: sync+restart
+             path: .
+             target: /code
+           - action: rebuild
+             path: requirements.txt
+
+     redis:
+       image: redis:alpine
+       volumes:
+         - redis-data:/data
+       healthcheck:
+         test: ["CMD", "redis-cli", "ping"]
+         interval: 5s
+         timeout: 3s
+         retries: 5
+         start_period: 10s
+
+   volumes:
+     redis-data:
+   ```
+
+   The `redis-data:/data` entry under `redis.volumes` mounts the named volume at `/data`, the path where Redis
+   writes its data files. The top-level `volumes` key registers it with Docker so it
+   persists between `compose down` and `compose up` cycles.
+
+2. Start the stack with `docker compose up --watch` and refresh `http://localhost:8000` a few times to build up a count.
+
+3. Tear down the stack with `docker compose down` and then bring it back up again with `docker compose up --watch`.
+
+4. Open `http://localhost:8000` — the counter continues from where it left off.
+
+5. Now reset the counter with `docker compose down -v`. 
+
+   The `-v` flag removes named volumes along with the containers. Use this intentionally — it permanently deletes the stored data.
+
+## Step 6: Structure your project with multiple Compose files
+
+As applications grow, a single `compose.yaml` becomes harder to maintain. The `include`
+top-level element lets you split services across multiple files while keeping them part of the
+same application.
+
+This is especially useful when different teams own different parts of the stack, or when
+you want to reuse infrastructure definitions across projects.
+
+1. Create a new file in your project directory called `infra.yaml` and move the Redis service and volume into it:
+
+   ```yaml
+    services:
      redis:
-       image: "redis:alpine"
+       image: redis:alpine
+       volumes:
+         - redis-data:/data
+       healthcheck:
+         test: ["CMD", "redis-cli", "ping"]
+         interval: 5s
+         timeout: 3s
+         retries: 5
+         start_period: 10s
+
+   volumes:
+     redis-data:
    ```
 
-3. In your `compose.yaml` file, add the `include` top-level attribute along with the path to the `infra.yaml` file.
+2. Update `compose.yaml` to include `infra.yaml`:
 
    ```yaml
    include:
-      - infra.yaml
+      - path: ./infra.yaml
    services:
      web:
        build: .
        ports:
-         - "8000:5000"
+         - "${APP_PORT}:5000"
+       environment:
+         - REDIS_HOST=${REDIS_HOST}
+         - REDIS_PORT=${REDIS_PORT}
+       depends_on:
+         redis:
+           condition: service_healthy
        develop:
          watch:
-           - action: sync
+           - action: sync+restart
              path: .
              target: /code
+           - action: rebuild
+             path: requirements.txt
    ```
 
-4. Run `docker compose up` to build the app with the updated Compose files, and run it. You should see the `Hello world` message in your browser. 
+3. Run the application to confirm everything still works:
 
-This is a simplified example, but it demonstrates the basic principle of `include` and how it can make it easier to modularize complex applications into sub-Compose files. For more information on `include` and working with multiple Compose files, see [Working with multiple Compose files](/manuals/compose/how-tos/multiple-compose-files/_index.md).
+   ```console
+   $ docker compose up --watch
+   ```
 
-## Step 8: Experiment with some other commands
+   Compose merges both files at startup. The `web` service can still reference `redis`
+   by name because all included services share the same default network.
 
-- If you want to run your services in the background, you can pass the `-d` flag (for "detached" mode) to `docker compose up` and use `docker compose ps` to see what is currently running:
+   This is a simplified example, but it demonstrates the basic principle of `include` and how it can make it easier to modularize complex applications into sub-Compose files. For more information on `include` and working with multiple Compose files, see [Working with multiple Compose files](/manuals/compose/how-tos/multiple-compose-files/_index.md).
+
+4. Stop the stack before moving on:
 
    ```console
-   $ docker compose up -d
+   $ docker compose down
+   ```
 
-   Starting composetest_redis_1...
-   Starting composetest_web_1...
+## Step 7: Inspect and debug your running stack
 
-   $ docker compose ps
+With a fully configured stack, you can observe what's happening inside your containers
+without stopping anything. This step covers the core commands for inspecting the resolved configuration, streaming logs, and running commands
+inside a running container.
 
-          Name                      Command               State           Ports         
-   -------------------------------------------------------------------------------------
-   composetest_redis_1   docker-entrypoint.sh redis ...   Up      6379/tcp              
-   composetest_web_1     flask run                        Up      0.0.0.0:8000->5000/tcp
-   ```
+Before starting the stack, verify that Compose has resolved your `.env` variables and
+merged all files correctly:
+
+```console
+$ docker compose config
+```
 
-- Run `docker compose --help` to see other available commands.
+`docker compose config` doesn't require the stack to be running — it works purely from
+your files. A few things worth noting in the output:
 
-- If you started Compose with `docker compose up -d`, stop your services once you've finished with them:
+- `${APP_PORT}`, `${REDIS_HOST}`, and `${REDIS_PORT}` have all been replaced with the
+  values from your `.env` file.
+- Short-form port notation (`"8000:5000"`) is expanded into its canonical fields
+  (`target`, `published`, `protocol`).
+- The default network and volume names are made explicit, prefixed with the project name
+  `compose-demo`.
+- The output is the fully resolved configuration, with any files
+  brought in via `include` merged into a single view.
 
-   ```console
-   $ docker compose stop
-   ```
+Use `docker compose config` any time you want to confirm what Compose will actually
+apply, especially when debugging variable substitution or working with multiple Compose files.
 
-- You can bring everything down, removing the containers entirely, with the `docker compose down` command. 
+Now start the stack in detached mode so the terminal stays free for the commands that
+follow:
+
+```console
+$ docker compose up -d
+```
+
+### Stream logs from all services
+
+```console
+$ docker compose logs -f
+```
+
+The `-f` flag follows the log stream in real time, interleaving output from both
+containers with color-coded service name prefixes. Refresh `http://localhost:8000` a
+few times and watch the Flask request logs appear. To follow logs for a single service,
+pass its name:
+
+```console
+$ docker compose logs -f web
+```
+
+Press `Ctrl+C` to stop following logs. The containers keep running.
+
+### Run commands inside a running container
+
+`docker compose exec` runs a command inside an already-running container without
+starting a new one. This is the primary tool for live debugging.
+
+#### Verify environment variables are set correctly
+
+```console
+$ docker compose exec web env | grep REDIS
+```
+
+```text
+REDIS_HOST=redis
+REDIS_PORT=6379
+```
+
+#### Test that the `web` container can reach Redis using the service name as the hostname
+
+```console
+$ docker compose exec web python -c "import redis; r = redis.Redis(host='redis'); print(r.ping())"
+```
+
+```text
+True
+```
+
+This uses the same `redis` library your app uses, so a `True` response confirms that
+service discovery, networking, and the Redis connection are all working end to end.
+
+#### Inspect the live value of the hit counter in Redis
+
+```console
+$ docker compose exec redis redis-cli GET hits
+```
 
 ## Where to go next
 
-- Try the [Sample apps with Compose](https://github.com/docker/awesome-compose)
-- [Explore the full list of Compose commands](/reference/cli/docker/compose.md)
+- [Explore the full list of Compose commands](/reference/cli/docker/compose/)
 - [Explore the Compose file reference](/reference/compose-file/_index.md)
 - [Check out the Learning Docker Compose video on LinkedIn Learning](https://www.linkedin.com/learning/learning-docker-compose/)
+- [Learn how to set environment variables in Compose](/compose/how-tos/environment-variables/set-environment-variables/)
+- [Learn how to package and distribute your Compose app](/compose/how-tos/oci-artifact/)
+
+
diff --git a/content/manuals/compose/how-tos/dependent-images.md b/content/manuals/compose/how-tos/dependent-images.md
index d62668548acf..7491f7dd11bf 100644
--- a/content/manuals/compose/how-tos/dependent-images.md
+++ b/content/manuals/compose/how-tos/dependent-images.md
@@ -8,7 +8,7 @@ weight: 50
 {{< summary-bar feature_name="Compose dependent images" >}}
 
 To reduce push/pull time and image weight, a common practice for Compose applications is to have services
-share base layers as much as possible. You will typically select the same operating system base image for
+share base layers as much as possible. You typically select the same operating system base image for
 all services. But you can also get one step further by sharing image layers when your images share the same
 system packages. The challenge to address is then to avoid repeating the exact same Dockerfile instruction 
 in all services.
@@ -162,3 +162,8 @@ Bake can also be selected as the default builder by editing your `$HOME/.docker/
   ...
 }
 ```
+
+## Additional resources
+
+- [Docker Compose build reference](/reference/cli/docker/compose/build/)
+- [Learn about multi-stage Dockerfiles](/manuals/build/building/multi-stage.md)
diff --git a/content/manuals/compose/how-tos/environment-variables/_index.md b/content/manuals/compose/how-tos/environment-variables/_index.md
index a2ddb86929a7..0775edc2665d 100644
--- a/content/manuals/compose/how-tos/environment-variables/_index.md
+++ b/content/manuals/compose/how-tos/environment-variables/_index.md
@@ -2,14 +2,13 @@
 title: Environment variables in Compose
 linkTitle: Use environment variables
 weight: 40
-description: Explainer on the ways to set, use and manage environment variables in
-  Compose
+description: Explains how to set, use, and manage environment variables in Docker Compose.
 keywords: compose, orchestration, environment, env file
 aliases:
 - /compose/environment-variables/
 ---
 
-By leveraging environment variables and interpolation in Docker Compose, you can create versatile and reusable configurations, making your Dockerized applications easier to manage and deploy across different environments. 
+Environment variables and interpolation in Docker Compose help you create reusable, flexible configurations. This makes Dockerized applications easier to manage and deploy across environments.
 
 > [!TIP]
 >
diff --git a/content/manuals/compose/how-tos/environment-variables/best-practices.md b/content/manuals/compose/how-tos/environment-variables/best-practices.md
index eb29f2482e65..30309e1c632d 100644
--- a/content/manuals/compose/how-tos/environment-variables/best-practices.md
+++ b/content/manuals/compose/how-tos/environment-variables/best-practices.md
@@ -6,8 +6,6 @@ description: Explainer on the best ways to set, use, and manage environment vari
 keywords: compose, orchestration, environment, env file, environment variables
 tags: [Best practices]
 weight: 50
-aliases:
-- /compose/environment-variables/best-practices/
 ---
 
 #### Handle sensitive information securely
diff --git a/content/manuals/compose/how-tos/environment-variables/envvars-precedence.md b/content/manuals/compose/how-tos/environment-variables/envvars-precedence.md
index f5e14549472d..223c11ead25a 100644
--- a/content/manuals/compose/how-tos/environment-variables/envvars-precedence.md
+++ b/content/manuals/compose/how-tos/environment-variables/envvars-precedence.md
@@ -6,13 +6,12 @@ description: Scenario overview illustrating how environment variables are resolv
 keywords: compose, environment, env file
 weight: 20
 aliases:
-- /compose/envvars-precedence/
 - /compose/environment-variables/envvars-precedence/
 ---
 
 When the same environment variable is set in multiple sources, Docker Compose follows a precedence rule to determine the value for that variable in your container's environment.
 
-This page contains information on the level of precedence each method of setting environmental variables takes.
+This page explains how Docker Compose determines the final value of an environment variable when it's defined in multiple locations.
 
 The order of precedence (highest to lowest) is as follows:
 1. Set using [`docker compose run -e` in the CLI](set-environment-variables.md#set-environment-variables-with-docker-compose-run---env).
@@ -22,6 +21,15 @@ The order of precedence (highest to lowest) is as follows:
 5. Set in a container image in the [ENV directive](/reference/dockerfile.md#env).
    Having any `ARG` or `ENV` setting in a `Dockerfile` evaluates only if there is no Docker Compose entry for `environment`, `env_file` or `run --env`.
 
+> [!NOTE] 
+> 
+> When `--env-file` is not set, Compose may load up to two `.env` files.
+> It first loads one from the project directory (determined by `--project-directory`
+> if set, otherwise the directory of the first `-f`/`--file` Compose file, otherwise
+> `PWD`). If that file sets `COMPOSE_FILE` to a path in a different directory, Compose
+> loads a second `.env` file from that directory with lower precedence. For more
+> information, see [local `.env` file versus project directory `.env` file](variable-interpolation.md#local-env-file-versus-project-directory-env-file).
+
 ## Simple example
 
 In the following example, a different value for the same environment variable in an `.env` file and with the `environment` attribute in the Compose file:
@@ -59,25 +67,25 @@ The columns `Host OS environment` and `.env` file is listed only for illustratio
 
 Each row represents a combination of contexts where `VALUE` is set, substituted, or both. The **Result** column indicates the final value for `VALUE` in each scenario.
 
-|  # |  `docker compose run`  |  `environment` attribute  |  `env_file` attribute  |  Image `ENV` |  `Host OS` environment  |  `.env` file      | |  Result  |
-|:--:|:----------------:|:-------------------------------:|:----------------------:|:------------:|:-----------------------:|:-----------------:|:---:|:----------:|
-|  1 |   -              |   -                             |   -                    |   -          |  `VALUE=1.4`            |  `VALUE=1.3`      || -               |
-|  2 |   -              |   -                             |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |   -               ||**`VALUE=1.6`**  |
-|  3 |   -              |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |   -               ||**`VALUE=1.7`**  |
-|  4 |   -              |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.5`**  |
-|  5 |`--env VALUE=1.8` |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.8`**  |
-|  6 |`--env VALUE`     |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.4`**  |
-|  7 |`--env VALUE`     |   -                             |   -                    |  `VALUE=1.5` |   -                     |  `VALUE=1.3`      ||**`VALUE=1.3`**  |
-|  8 |   -              |   -                             |   `VALUE`              |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.4`**  |
-|  9 |   -              |   -                             |   `VALUE`              |  `VALUE=1.5` |   -                     |  `VALUE=1.3`      ||**`VALUE=1.3`**  |
-| 10 |   -              |  `VALUE`                        |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.4`**  |
-| 11 |   -              |  `VALUE`                        |   -                    |  `VALUE=1.5` |  -                      |  `VALUE=1.3`      ||**`VALUE=1.3`**  |
-| 12 |`--env VALUE`     |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.4`**  |
-| 13 |`--env VALUE=1.8` |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.8`**  |
-| 14 |`--env VALUE=1.8` |   -                             |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.8`**  |
-| 15 |`--env VALUE=1.8` |  `VALUE=1.7`                    |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.8`**  |
-
-### Result explanation
+|  # |  `docker compose run`  |  `environment` attribute  |  `env_file` attribute  |  Image `ENV` |  `Host OS` environment  |  `.env` file      |   Result  |
+|:--:|:----------------:|:-------------------------------:|:----------------------:|:------------:|:-----------------------:|:-----------------:|:----------:|
+|  1 |   -              |   -                             |   -                    |   -          |  `VALUE=1.4`            |  `VALUE=1.3`      | -               |
+|  2 |   -              |   -                             |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |   -               |**`VALUE=1.6`**  |
+|  3 |   -              |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |   -               |**`VALUE=1.7`**  |
+|  4 |   -              |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.5`**  |
+|  5 |`--env VALUE=1.8` |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.8`**  |
+|  6 |`--env VALUE`     |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.4`**  |
+|  7 |`--env VALUE`     |   -                             |   -                    |  `VALUE=1.5` |   -                     |  `VALUE=1.3`      |**`VALUE=1.3`**  |
+|  8 |   -              |   -                             |   `VALUE`              |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.4`**  |
+|  9 |   -              |   -                             |   `VALUE`              |  `VALUE=1.5` |   -                     |  `VALUE=1.3`      |**`VALUE=1.3`**  |
+| 10 |   -              |  `VALUE`                        |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.4`**  |
+| 11 |   -              |  `VALUE`                        |   -                    |  `VALUE=1.5` |  -                      |  `VALUE=1.3`      |**`VALUE=1.3`**  |
+| 12 |`--env VALUE`     |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.4`**  |
+| 13 |`--env VALUE=1.8` |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.8`**  |
+| 14 |`--env VALUE=1.8` |   -                             |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.8`**  |
+| 15 |`--env VALUE=1.8` |  `VALUE=1.7`                    |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.8`**  |
+
+### Understanding precedence results
 
 Result 1: The local environment takes precedence, but the Compose file is not set to replicate this inside the container, so no such variable is set.
 
@@ -87,7 +95,7 @@ Result 3: The `environment` attribute in the Compose file defines an explicit va
 
 Result 4: The image's `ENV` directive declares the variable `VALUE`, and since the Compose file is not set to override this value, this variable is defined by image
 
-Result 5: The `docker compose run` command has the `--env` flag set which an explicit value, and overrides the value set by the image. 
+Result 5: The `docker compose run` command has the `--env` flag set with an explicit value, and overrides the value set by the image. 
 
 Result 6: The `docker compose run` command has the `--env` flag set to replicate the value from the environment. Host OS value takes precedence and is replicated into the container's environment.
 
@@ -104,3 +112,8 @@ Result 11: The `environment` attribute in the Compose file is set to replicate `
 Result 12: The `--env` flag has higher precedence than the `environment` and `env_file` attributes and is to set to replicate `VALUE` from the local environment. Host OS value takes precedence and is replicated into the container's environment.
 
 Results 13 to 15: The `--env` flag has higher precedence than the `environment` and `env_file` attributes and so sets the value. 
+
+## Next steps
+
+- [Set environment variables in Compose](set-environment-variables.md)
+- [Use variable interpolation in Compose files](variable-interpolation.md)
diff --git a/content/manuals/compose/how-tos/environment-variables/envvars.md b/content/manuals/compose/how-tos/environment-variables/envvars.md
index 67d5929673fa..e2ad859dd73c 100644
--- a/content/manuals/compose/how-tos/environment-variables/envvars.md
+++ b/content/manuals/compose/how-tos/environment-variables/envvars.md
@@ -1,7 +1,7 @@
 ---
 description: Compose pre-defined environment variables
-keywords: fig, composition, compose, docker, orchestration, cli, reference
-title: Set or change pre-defined environment variables in Docker Compose
+keywords: fig, composition, compose, docker, orchestration, cli, reference, compose environment configuration, docker env variables
+title: Configure pre-defined environment variables in Docker Compose
 linkTitle: Pre-defined environment variables
 weight: 30
 aliases:
@@ -9,9 +9,9 @@ aliases:
 - /compose/environment-variables/envvars/
 ---
 
-Compose already comes with pre-defined environment variables. It also inherits common Docker CLI environment variables, such as `DOCKER_HOST` and `DOCKER_CONTEXT`. See [Docker CLI environment variable reference](/reference/cli/docker/#environment-variables) for details.
+Docker Compose includes several pre-defined environment variables. It also inherits common Docker CLI environment variables, such as `DOCKER_HOST` and `DOCKER_CONTEXT`. See [Docker CLI environment variable reference](/reference/cli/docker/#environment-variables) for details.
 
-This page contains information on how you can set or change the following pre-defined environment variables if you need to:
+This page explains how to set or change the following pre-defined environment variables:
 
 - `COMPOSE_PROJECT_NAME`
 - `COMPOSE_FILE`
@@ -24,21 +24,26 @@ This page contains information on how you can set or change the following pre-de
 - `COMPOSE_ANSI`
 - `COMPOSE_STATUS_STDOUT`
 - `COMPOSE_ENV_FILES`
+- `COMPOSE_DISABLE_ENV_FILE`
 - `COMPOSE_MENU`
 - `COMPOSE_EXPERIMENTAL`
+- `COMPOSE_PROGRESS`
 
 ## Methods to override 
 
-You can set or change the pre-defined environment variables:
-- With an [`.env` file located in your working directory](/manuals/compose/how-tos/environment-variables/variable-interpolation.md) 
-- From the command line
-- From your [shell](variable-interpolation.md#substitute-from-the-shell)
+| Method      | Description                                  |
+| ----------- | -------------------------------------------- |
+| [`.env` file](/manuals/compose/how-tos/environment-variables/variable-interpolation.md) | Located in the working directory.            |
+| [Shell](variable-interpolation.md#substitute-from-the-shell)       | Defined in the host operating system shell.  |
+| CLI         | Passed with `--env` or `-e` flag at runtime. |
 
 When changing or setting any environment variables, be aware of [Environment variable precedence](envvars-precedence.md).
 
-## Configure
+## Configuration details
 
-### COMPOSE\_PROJECT\_NAME
+### Project and file configuration
+
+#### COMPOSE\_PROJECT\_NAME
 
 Sets the project name. This value is prepended along with the service name to
 the container's name on startup.
@@ -61,9 +66,9 @@ underscores, and must begin with a lowercase letter or decimal digit. If the
 `basename` of the project directory or current directory violates this
 constraint, you must use one of the other mechanisms.
 
-See also the [command-line options overview](/reference/cli/docker/compose/_index.md#command-options-overview-and-help) and [using `-p` to specify a project name](/reference/cli/docker/compose/_index.md#use--p-to-specify-a-project-name).
+See also [using `-p` to specify a project name](/reference/cli/docker/compose/#use--p-to-specify-a-project-name).
 
-### COMPOSE\_FILE
+#### COMPOSE\_FILE
 
 Specifies the path to a Compose file. Specifying multiple Compose files is supported.
 
@@ -78,9 +83,9 @@ Specifies the path to a Compose file. Specifying multiple Compose files is suppo
       ```  
    The path separator can also be customized using [`COMPOSE_PATH_SEPARATOR`](#compose_path_separator).  
 
-See also the [command-line options overview](/reference/cli/docker/compose/_index.md#command-options-overview-and-help) and [using `-f` to specify name and path of one or more Compose files](/reference/cli/docker/compose/_index.md#use--f-to-specify-the-name-and-path-of-one-or-more-compose-files).
+See also [using `-f` to specify name and path of one or more Compose files](/reference/cli/docker/compose/#use--f-to-specify-the-name-and-path-of-one-or-more-compose-files).
 
-### COMPOSE\_PROFILES
+#### COMPOSE\_PROFILES
 
 Specifies one or more profiles to be enabled when `docker compose up` is run.
 
@@ -97,26 +102,49 @@ The following example enables all services matching both the `frontend` and `deb
 COMPOSE_PROFILES=frontend,debug
 ```
 
-See also [Using profiles with Compose](../profiles.md) and the [`--profile` command-line option](/reference/cli/docker/compose/_index.md#use-profiles-to-enable-optional-services).
+See also [Using profiles with Compose](../profiles.md) and the [`--profile` command-line option](/reference/cli/docker/compose/#use-profiles-to-enable-optional-services).
 
-### COMPOSE\_CONVERT\_WINDOWS\_PATHS
+#### COMPOSE\_PATH\_SEPARATOR
 
-When enabled, Compose performs path conversion from Windows-style to Unix-style in volume definitions.
+Specifies a different path separator for items listed in `COMPOSE_FILE`.
+
+- Defaults to:
+    - On macOS and Linux to `:`
+    - On Windows to`;`
+
+#### COMPOSE\_ENV\_FILES
+
+Specifies which environment files Compose should use if `--env-file` isn't used.
+
+When using multiple environment files, use a comma as a separator. For example: 
+
+```console
+COMPOSE_ENV_FILES=.env.envfile1,.env.envfile2
+```
+
+If `COMPOSE_ENV_FILES` is not set, and you don't provide `--env-file` in the CLI, Docker Compose uses the default behavior, which is to look for an `.env` file in the project directory.
+
+#### COMPOSE\_DISABLE\_ENV\_FILE
+
+Lets you disable the use of the default `.env` file. 
 
 - Supported values: 
-    - `true` or `1`, to enable
-    - `false` or `0`, to disable
+    - `true` or `1`, Compose ignores the `.env` file
+    - `false` or `0`, Compose looks for an `.env` file in the project directory
 - Defaults to: `0`
 
-### COMPOSE\_PATH\_SEPARATOR
+### Environment handling and container lifecycle
 
-Specifies a different path separator for items listed in `COMPOSE_FILE`.
+#### COMPOSE\_CONVERT\_WINDOWS\_PATHS
 
-- Defaults to:
-    - On macOS and Linux to `:`
-    - On Windows to`;`
+When enabled, Compose performs path conversion from Windows-style to Unix-style in volume definitions.
+
+- Supported values: 
+    - `true` or `1`, to enable
+    - `false` or `0`, to disable
+- Defaults to: `0`
 
-### COMPOSE\_IGNORE\_ORPHANS
+#### COMPOSE\_IGNORE\_ORPHANS
 
 When enabled, Compose doesn't try to detect orphaned containers for the project.
 
@@ -125,7 +153,7 @@ When enabled, Compose doesn't try to detect orphaned containers for the project.
    - `false` or `0`, to disable
 - Defaults to: `0`
 
-### COMPOSE\_REMOVE\_ORPHANS
+#### COMPOSE\_REMOVE\_ORPHANS
 
 When enabled, Compose automatically removes orphaned containers when updating a service or stack. Orphaned containers are those that were created by a previous configuration but are no longer defined in the current `compose.yaml` file.
 
@@ -134,11 +162,13 @@ When enabled, Compose automatically removes orphaned containers when updating a
    - `false` or `0`, to disable automatic removal. Compose displays a warning about orphaned containers instead.
 - Defaults to: `0`
 
-### COMPOSE\_PARALLEL\_LIMIT
+#### COMPOSE\_PARALLEL\_LIMIT
 
 Specifies the maximum level of parallelism for concurrent engine calls.
 
-### COMPOSE\_ANSI
+### Output 
+
+#### COMPOSE\_ANSI
 
 Specifies when to print ANSI control characters. 
 
@@ -148,7 +178,7 @@ Specifies when to print ANSI control characters.
    - `always` or `0`, use TTY mode
 - Defaults to: `auto`
 
-### COMPOSE\_STATUS\_STDOUT
+#### COMPOSE\_STATUS\_STDOUT
 
 When enabled, Compose writes its internal status and progress messages to `stdout` instead of `stderr`. 
 The default value is false to clearly separate the output streams between Compose messages and your container's logs.
@@ -158,34 +188,33 @@ The default value is false to clearly separate the output streams between Compos
    - `false` or `0`, to disable
 - Defaults to: `0`
 
-### COMPOSE\_ENV\_FILES
+#### COMPOSE\_PROGRESS
 
-Lets you specify which environment files Compose should use if `--env-file` isn't used.
+{{< summary-bar feature_name="Compose progress" >}}
 
-When using multiple environment files, use a comma as a separator. For example: 
+Defines the type of progress output, if `--progress` isn't used. 
 
-```console
-COMPOSE_ENV_FILES=.env.envfile1, .env.envfile2
-```
+Supported values are `auto`, `tty`, `plain`, `json`, and `quiet`.
+Default is `auto`. 
 
-If `COMPOSE_ENV_FILES` is not set, and you don't provide `--env-file` in the CLI, Docker Compose uses the default behavior, which is to look for an `.env` file in the project directory.
+### User experience
 
-### COMPOSE\_MENU
+#### COMPOSE\_MENU
 
 {{< summary-bar feature_name="Compose menu" >}}
 
-When enabled, Compose displays a navigation menu where you can choose to open the Compose stack in Docker Desktop, switch on [`watch` mode](../file-watch.md), or use [Docker Debug](/reference/cli/docker/debug.md).
+When enabled, Compose displays a navigation menu where you can choose to open the Compose stack in Docker Desktop, switch on [`watch` mode](../file-watch.md), or use [Docker Debug](/reference/cli/docker/debug/).
 
 - Supported values:
    - `true` or `1`, to enable
    - `false` or `0`, to disable
 - Defaults to: `1` if you obtained Docker Compose through Docker Desktop, otherwise the default is `0`
 
-### COMPOSE\_EXPERIMENTAL
+#### COMPOSE\_EXPERIMENTAL
 
 {{< summary-bar feature_name="Compose experimental" >}}
 
-This is an opt-out variable. When turned off it deactivates the experimental features such as the navigation menu or [Synchronized file shares](/manuals/desktop/features/synchronized-file-sharing.md).
+This is an opt-out variable. When turned off it deactivates the experimental features.
 
 - Supported values:
    - `true` or `1`, to enable
@@ -195,7 +224,6 @@ This is an opt-out variable. When turned off it deactivates the experimental fea
 ## Unsupported in Compose V2
 
 The following environment variables have no effect in Compose V2.
-For more information, see [Migrate to Compose V2](/manuals/compose/releases/migrate.md).
 
 - `COMPOSE_API_VERSION`
     By default the API version is negotiated with the server. Use `DOCKER_API_VERSION`.  
@@ -206,3 +234,4 @@ For more information, see [Migrate to Compose V2](/manuals/compose/releases/migr
 - `COMPOSE_INTERACTIVE_NO_CLI`
 - `COMPOSE_DOCKER_CLI_BUILD`
     Use `DOCKER_BUILDKIT` to select between BuildKit and the classic builder. If `DOCKER_BUILDKIT=0` then `docker compose build` uses the classic builder to build images.
+
diff --git a/content/manuals/compose/how-tos/environment-variables/set-environment-variables.md b/content/manuals/compose/how-tos/environment-variables/set-environment-variables.md
index 2f7c925b4c1d..1d73c80ca0b1 100644
--- a/content/manuals/compose/how-tos/environment-variables/set-environment-variables.md
+++ b/content/manuals/compose/how-tos/environment-variables/set-environment-variables.md
@@ -5,8 +5,6 @@ weight: 10
 description: How to set, use, and manage environment variables with Compose
 keywords: compose, orchestration, environment, environment variables, container environment variables
 aliases:
-- /compose/env/
-- /compose/link-env-deprecated/
 - /compose/environment-variables/set-environment-variables/
 ---
 
diff --git a/content/manuals/compose/how-tos/environment-variables/variable-interpolation.md b/content/manuals/compose/how-tos/environment-variables/variable-interpolation.md
index bc2461c78ed5..7ba0d5dfa0f1 100644
--- a/content/manuals/compose/how-tos/environment-variables/variable-interpolation.md
+++ b/content/manuals/compose/how-tos/environment-variables/variable-interpolation.md
@@ -12,9 +12,9 @@ aliases:
 
 A Compose file can use variables to offer more flexibility. If you want to quickly switch 
 between image tags to test multiple versions, or want to adjust a volume source to your local
-environment, you don't need to edit the Compose file each time, you can just set variables that insert values into your Compose file at run time.
+environment, you don't need to edit the Compose file each time, you can just set variables that insert values into your Compose file at runtime.
 
-Interpolation can also be used to insert values into your Compose file at run time, which is then used to pass variables into your container's environment
+Interpolation can also be used to insert values into your Compose file at runtime, which is then used to pass variables into your container's environment
 
 Below is a simple example: 
 
@@ -28,7 +28,7 @@ services:
 ```
 
 When you run `docker compose up`, the `web` service defined in the Compose file [interpolates](variable-interpolation.md) in the image `webapp:v1.5` which was set in the `.env` file. You can verify this with the
-[config command](/reference/cli/docker/compose/config.md), which prints your resolved application config to the terminal:
+[config command](/reference/cli/docker/compose/config/), which prints your resolved application config to the terminal:
 
 ```console
 $ docker compose config
@@ -64,8 +64,12 @@ Docker Compose can interpolate variables into your Compose file from multiple so
 Note that when the same variable is declared by multiple sources, precedence applies:
 
 1. Variables from your shell environment
-2. If `--env-file` is not set, variables set by an `.env` file in local working directory (`PWD`)
-3. Variables from a file set by `--env-file` or an `.env` file in project directory
+2. Variables from a file set by `--env-file`
+3. If `--env-file` is not set, variables from an `.env` file in the project directory,
+   where the project directory is:
+   - `--project-directory` if set
+   - otherwise, the directory of the first Compose file specified with `-f`/`--file`
+   - otherwise, your shell's current directory (`PWD`)
 
 You can check variables and values used by Compose to interpolate the Compose model by running `docker compose config --environment`.
 
@@ -130,9 +134,13 @@ The following syntax rules apply to environment files:
 - Blank lines are ignored.
 - Unquoted and double-quoted (`"`) values have interpolation applied.
 - Each line represents a key-value pair. Values can optionally be quoted.
+- Delimiter separating key and value can be either `=` or `:`.
+- Spaces before and after value are ignored.
   - `VAR=VAL` -> `VAL`
   - `VAR="VAL"` -> `VAL`
   - `VAR='VAL'` -> `VAL`
+  - `VAR: VAL` -> `VAL`
+  - `VAR = VAL  ` -> `VAL` <!-- markdownlint-disable-line no-space-in-code -->
 - Inline comments for unquoted values must be preceded with a space.
   - `VAR=VAL # comment` -> `VAL`
   - `VAR=VAL# not a comment` -> `VAL# not a comment`
@@ -149,6 +157,21 @@ The following syntax rules apply to environment files:
   - `VAR="some\tvalue"` -> `some  value`
   - `VAR='some\tvalue'` -> `some\tvalue`
   - `VAR=some\tvalue` -> `some\tvalue`
+- Single-quoted values can span multiple lines. Example:
+
+   ```yaml
+   KEY='SOME
+   VALUE'
+   ```
+
+   If you then run `docker compose config`, you'll see:
+  
+   ```yaml
+   environment:
+     KEY: |-
+       SOME
+       VALUE
+   ```
 
 ### Substitute with `--env-file`
 
@@ -207,9 +230,13 @@ $ docker compose --env-file ./config/.env.dev up
 
 An `.env` file can also be used to declare [pre-defined environment variables](envvars.md) used to control Compose behavior and files to be loaded. 
 
-When executed without an explicit `--env-file` flag, Compose searches for an `.env` file in your working directory ([PWD](https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html#index-PWD)) and loads values 
-both for self-configuration and interpolation. If the values in this file define the `COMPOSE_FILE` pre-defined variable, which results in a project directory being set to another folder, 
-Compose will load a second `.env` file, if present. This second `.env` file has a lower precedence. 
+When executed without an explicit `--env-file` flag, Compose searches for an `.env` file
+in the project directory and loads values both for self-configuration and interpolation.
+The project directory is determined by `--project-directory` if set, otherwise by the
+directory of the first Compose file specified with `-f`/`--file`, otherwise `PWD`.
+If the values in this file define the `COMPOSE_FILE` pre-defined variable, which results
+in a project directory being set to another folder, Compose loads a second `.env` file,
+if present. This second `.env` file has a lower precedence. 
 
 This mechanism makes it possible to invoke an existing Compose project with a custom set of variables as overrides, without the need to pass environment variables by the command line.
 
diff --git a/content/manuals/compose/how-tos/file-watch.md b/content/manuals/compose/how-tos/file-watch.md
index 5cef4963916e..35e6ccb2f80b 100644
--- a/content/manuals/compose/how-tos/file-watch.md
+++ b/content/manuals/compose/how-tos/file-watch.md
@@ -31,8 +31,8 @@ Compose supports sharing a host directory inside service containers. Watch mode
 More importantly, `watch` allows for greater granularity than is practical with a bind mount. Watch rules let you ignore specific files or entire directories within the watched tree.
 
 For example, in a JavaScript project, ignoring the `node_modules/` directory has two benefits:
-* Performance. File trees with many small files can cause high I/O load in some configurations
-* Multi-platform. Compiled artifacts cannot be shared if the host OS or architecture is different to the container
+* Performance. File trees with many small files can cause a high I/O load in some configurations
+* Multi-platform. Compiled artifacts cannot be shared if the host OS or architecture is different from the container
 
 For example, in a Node.js project, it's not recommended to sync the `node_modules/` directory. Even though JavaScript is interpreted, `npm` packages can contain native code that is not portable across platforms.
 
@@ -88,12 +88,16 @@ If `action` is set to `rebuild`, Compose automatically builds a new image with B
 
 The behavior is the same as running `docker compose up --build <svc>`.
 
-Rebuild is ideal for compiled languages or as fallbacks for modifications to particular files that require a full
+Rebuild is ideal for compiled languages or as a fallback for modifications to particular files that require a full
 image rebuild (e.g. `package.json`).
 
+> [!NOTE]
+>
+> When a service is rebuilt, the previous image version becomes dangling. By default, Compose removes these superseded dangling images after each rebuild to avoid accumulating unused layers. To keep them, use `docker compose watch --prune=false`.
+
 #### Sync + Restart
 
-If `action` is set to `sync+restart`, Compose synchronizes your changes with the service containers and restarts it. 
+If `action` is set to `sync+restart`, Compose synchronizes your changes with the service containers and restarts them. 
 
 `sync+restart` is ideal when the config file changes, and you don't need to rebuild the image but just restart the main process of the service containers. 
 It will work well when you update a database configuration or your `nginx.conf` file, for example.
@@ -118,6 +122,10 @@ For `path: ./app/html` and a change to `./app/html/index.html`:
 
 The `ignore` patterns are relative to the `path` defined in the current `watch` action, not to the project directory. In the following Example 1, the ignore path would be relative to the `./web` directory specified in the `path` attribute.
 
+### `initial_sync`
+
+When using a `sync+x` action, the `initial_sync` attribute tells Compose to ensure files that are part of the defined `path` are up to date before starting a new watch session.
+
 ## Example 1
 
 This minimal example targets a Node.js application with the following structure:
@@ -142,6 +150,7 @@ services:
         - action: sync
           path: ./web
           target: /src/web
+          initial_sync: true
           ignore:
             - node_modules/
         - action: rebuild
@@ -207,10 +216,6 @@ This setup demonstrates how to use the `sync+restart` action in Docker Compose t
 > or [local setup for Docker docs](https://github.com/docker/docs/blob/main/CONTRIBUTING.md)
 > for a demonstration of Compose `watch`.
 
-## Feedback
-
-We are actively looking for feedback on this feature. Give feedback or report any bugs you may find in the [Compose Specification repository](https://github.com/compose-spec/compose-spec/pull/253).
-
 ## Reference
 
 - [Compose Develop Specification](/reference/compose-file/develop.md)
diff --git a/content/manuals/compose/how-tos/gpu-support.md b/content/manuals/compose/how-tos/gpu-support.md
index 0d5c6b7b4d08..eeb7919c4162 100644
--- a/content/manuals/compose/how-tos/gpu-support.md
+++ b/content/manuals/compose/how-tos/gpu-support.md
@@ -1,7 +1,7 @@
 ---
-description: Understand GPU support in Docker Compose
+description: Learn how to configure Docker Compose to use NVIDIA GPUs with CUDA-based containers
 keywords: documentation, docs, docker, compose, GPU access, NVIDIA, samples
-title: Enable GPU access with Docker Compose
+title: Run Docker Compose services with GPU access 
 linkTitle: Enable GPU support
 weight: 90
 aliases:
@@ -11,7 +11,6 @@ aliases:
 Compose services can define GPU device reservations if the Docker host contains such devices and the Docker Daemon is set accordingly. For this, make sure you install the [prerequisites](/manuals/engine/containers/resource_constraints.md#gpu) if you haven't already done so.
 
 The examples in the following sections focus specifically on providing service containers access to GPU devices with Docker Compose. 
-You can use either `docker-compose` or `docker compose` commands. For more information, see [Migrate to Compose V2](/manuals/compose/releases/migrate.md).
 
 ## Enabling GPU access to service containers
 
@@ -19,16 +18,18 @@ GPUs are referenced in a `compose.yaml` file using the [device](/reference/compo
 
 This provides more granular control over a GPU reservation as custom values can be set for the following device properties: 
 
-- `capabilities`. This value specifies as a list of strings (eg. `capabilities: [gpu]`). You must set this field in the Compose file. Otherwise, it returns an error on service deployment.
-- `count`. This value, specified as an integer or the value `all`, represents the number of GPU devices that should be reserved (providing the host holds that number of GPUs). If `count` is set to `all` or not specified, all GPUs available on the host are used by default.
+- `capabilities`. This value is specified as a list of strings. For example, `capabilities: [gpu]`. You must set this field in the Compose file. Otherwise, it returns an error on service deployment.
+- `count`. Specified as an integer or the value `all`, represents the number of GPU devices that should be reserved (providing the host holds that number of GPUs). If `count` is set to `all` or not specified, all GPUs available on the host are used by default.
 - `device_ids`. This value, specified as a list of strings, represents GPU device IDs from the host. You can find the device ID in the output of `nvidia-smi` on the host. If no `device_ids` are set, all GPUs available on the host are used by default.
-- `driver`. This value is specified as a string, for example `driver: 'nvidia'`
+- `driver`. Specified as a string, for example `driver: 'nvidia'`
 - `options`. Key-value pairs representing driver specific options.
 
 
 > [!IMPORTANT]
 >
 > You must set the `capabilities` field. Otherwise, it returns an error on service deployment.
+
+> [!NOTE]
 >
 > `count` and `device_ids` are mutually exclusive. You must only define one field at a time.
 
@@ -39,7 +40,7 @@ For more information on these properties, see the [Compose Deploy Specification]
 ```yaml
 services:
   test:
-    image: nvidia/cuda:12.3.1-base-ubuntu20.04
+    image: nvidia/cuda:12.9.0-base-ubuntu22.04
     command: nvidia-smi
     deploy:
       resources:
diff --git a/content/manuals/compose/how-tos/init-containers.md b/content/manuals/compose/how-tos/init-containers.md
new file mode 100644
index 000000000000..bbc034cbfd29
--- /dev/null
+++ b/content/manuals/compose/how-tos/init-containers.md
@@ -0,0 +1,173 @@
+---
+title: Use init containers in Compose
+linkTitle: Use init containers
+weight: 120
+description: Use pre_start init containers to run setup tasks before a service starts in Docker Compose.
+keywords: docker compose init containers, pre_start, docker compose migrations, volume permissions, docker compose lifecycle
+params:
+  sidebar:
+    badge:
+      color: green
+      text: New
+---
+
+{{< summary-bar feature_name="Compose pre_start" >}}
+
+Init containers are short-lived containers that run before a service's main container starts. They execute sequentially, each running to completion before the next begins. If any step exits with a non-zero code, the service will not start.
+
+Use them for setup work that must finish before the application boots: running database migrations, fixing volume permissions, generating dynamic configuration, or executing any ordered sequence of prerequisites.
+
+Compose models init containers as [`pre_start`](/reference/compose-file/services.md#pre_start) lifecycle hooks. Unlike [`post_start`](/reference/compose-file/services.md#post_start) and [`pre_stop`](/reference/compose-file/services.md#pre_stop), which run a command inside the running service container, each `pre_start` step runs in its own ephemeral container created after the service container is created but before it is started.
+
+## When not to use init containers
+
+For static files and secrets, use the native [`configs`](/reference/compose-file/configs.md) and [`secrets`](/reference/compose-file/secrets.md) top-level elements instead. Compose mounts them directly into containers with a configurable target path, mode, UID, and GID. No init container required.
+
+For background tasks with their own lifecycle - scheduled backups, post-exit cleanup, periodic maintenance — init containers are the wrong tool. Those tasks run independently of service startup, not before it.
+
+## How `pre_start` containers run
+
+Each step in a service's `pre_start` list:
+
+- Runs in its own ephemeral container, created after the service container is created but before it starts.
+- Inherits the service's image by default. Set `image` to override. The hook image follows the parent service's `pull_policy`, including refresh interval (`daily`, `weekly`, `every_<duration>`). This applies when starting services and when running `docker compose pull`.
+- Joins the same networks as the service, so it can reach services declared in [`depends_on`](/reference/compose-file/services.md#depends_on).
+- Shares the service's volume mounts, so files written to a shared volume are immediately visible to the service.
+- Must exit `0` for the next step, and the service itself, to start. A non-zero exit aborts startup for the service and anything that depends on it.
+
+A `pre_start` step is skipped on subsequent `docker compose up` runs if it previously succeeded, its definition hasn't changed, or when the service container restarts under its `restart` policy. It reruns if the definition changes, the previous run failed, or the service is recreated with `--force-recreate`.
+
+## Examples
+
+### Run a database migration before the app starts
+
+In the following example, `app` waits for `db` to be healthy, then runs
+`./manage.py migrate` in an ephemeral container that reuses the app's
+image. The service container only starts once the migration exits `0`.
+
+```yaml
+services:
+  app:
+    image: myapp:latest
+    depends_on:
+      db:
+        condition: service_healthy
+    pre_start:
+      - command: ["./manage.py", "migrate"]
+
+  db:
+    image: postgres:18
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
+      interval: 10s
+      retries: 5
+      start_period: 30s
+      timeout: 10s
+```
+
+If the migration fails, `app` does not start and the failure is reported in
+the `docker compose up` output.
+
+### Fix volume ownership before a non-root service starts
+
+Named volumes are created with root ownership. When the service runs as a
+non-root user, you can use a `pre_start` step to adjust ownership before
+the service mounts the volume.
+
+```yaml
+services:
+  app:
+    image: myapp:latest
+    user: "1000:1000"
+    volumes:
+      - data:/data
+    pre_start:
+      - image: busybox
+        user: root
+        command: sh -c 'chown -R 1000:1000 /data'
+
+volumes:
+  data:
+```
+
+The `pre_start` step uses a different image (`busybox`) and runs as `root`,
+even though the service itself runs as user `1000`.
+
+### Chain multiple setup steps
+
+`pre_start` steps run in declared order. The next step only starts once the
+previous one exits `0`. In the following example, the application waits
+for migrations to finish, then for seed data to load, before starting.
+
+```yaml
+services:
+  app:
+    image: myapp:latest
+    depends_on:
+      db:
+        condition: service_healthy
+    pre_start:
+      - command: ["./manage.py", "migrate"]
+      - command: ["./manage.py", "loaddata", "fixtures.json"]
+
+  db:
+    image: postgres:18
+```
+
+Each step runs in its own ephemeral container. If the second step fails,
+the first step is not rolled back, but `app` does not start.
+
+### Replace the one-shot service pattern
+
+Before `pre_start`, the common way to express "run X before Y starts" was
+to model the setup work as a service with `restart: "no"` and have the main
+service `depends_on` it with `condition: service_completed_successfully`:
+
+```yaml
+services:
+  migrate:
+    image: myapp:latest
+    command: ["./manage.py", "migrate"]
+    restart: "no"
+
+  app:
+    image: myapp:latest
+    depends_on:
+      migrate:
+        condition: service_completed_successfully
+```
+
+The equivalent expressed with `pre_start`:
+
+```yaml
+services:
+  app:
+    image: myapp:latest
+    pre_start:
+      - command: ["./manage.py", "migrate"]
+```
+
+`pre_start` is preferable because:
+
+- The setup work is modeled as a subordinate step of the service, not as a peer service that exits immediately.
+- Completed steps do not appear as exited services in `docker compose ps`.
+- Chaining several setup steps does not require a web of `depends_on` edges between one-shot services.
+- The ephemeral container inherits the service's image by default, so no duplicate `image:` declaration is needed.
+
+The one-shot service pattern still has its place when the setup work is a shared concern that multiple services depend on, or when it needs to be addressable independently of any single service.
+
+## Limitations
+
+- `pre_start` runs once for the service as a whole, not once per replica (`per_replica: false`). Per-replica execution (`per_replica: true`) is not yet supported.
+- Volume mounts shared across replicas (named volumes, bind mounts) are accessible from a `pre_start` step. Per-instance mounts such as `tmpfs`
+  or anonymous volumes cannot be addressed by a single shared run.
+- `pre_start` does not re-trigger when you scale a service up. A step runs again only on definition change, prior failure, or `--force-recreate`.
+
+## Reference and additional information
+
+- [`pre_start`](/reference/compose-file/services.md#pre_start)
+- [`post_start`](/reference/compose-file/services.md#post_start)
+- [`pre_stop`](/reference/compose-file/services.md#pre_stop)
+- [`depends_on`](/reference/compose-file/services.md#depends_on)
+- [Use lifecycle hooks](/manuals/compose/how-tos/lifecycle.md)
+- [Control startup order](/manuals/compose/how-tos/startup-order.md)
diff --git a/content/manuals/compose/how-tos/lifecycle.md b/content/manuals/compose/how-tos/lifecycle.md
index d60a942d9691..65f1ebd992b3 100644
--- a/content/manuals/compose/how-tos/lifecycle.md
+++ b/content/manuals/compose/how-tos/lifecycle.md
@@ -1,9 +1,9 @@
 ---
 title: Using lifecycle hooks with Compose
 linkTitle: Use lifecycle hooks
-weight: 20
-desription: How to use lifecycle hooks with Docker Compose
-keywords: cli, compose, lifecycle, hooks reference
+weight: 110
+description: Learn how to use Docker Compose lifecycle hooks like pre_start, post_start, and pre_stop to customize container behavior.
+keywords: docker compose lifecycle hooks, post_start, pre_stop, pre_start, docker compose entrypoint, docker container stop hooks, compose hook commands
 ---
 
 {{< summary-bar feature_name="Compose lifecycle hooks" >}}
@@ -28,25 +28,22 @@ Post-start hooks are commands that run after the container has started, but ther
 set time for when exactly they will execute. The hook execution timing is not assured during 
 the execution of the container's `entrypoint`.
 
-In the example provided:
+Because there is no ordering guarantee between the hook and the container's entrypoint,
+post-start hooks are best suited for tasks that do not need to complete before the
+application begins running, such as registering the container with an external system.
 
-- The hook is used to change the ownership of a volume to a non-root user (because volumes 
-are created with root ownership by default).
-- After the container starts, the `chown` command changes the ownership of the `/data` directory to user `1001`.
+In the following example, after the container starts, a root-level hook registers the
+service with an internal service registry. The application does not depend on registration
+being complete before it starts serving requests.
 
 ```yaml
 services:
   app:
     image: backend
     user: 1001
-    volumes:
-      - data:/data    
     post_start:
-      - command: chown -R /data 1001:1001
+      - command: /opt/scripts/register-service.sh
         user: root
-
-volumes:
-  data: {} # a Docker volume is created with root ownership
 ```
 
 ### Pre-stop hooks
@@ -55,15 +52,22 @@ Pre-stop hooks are commands that run before the container is stopped by a specif
 command (like `docker compose down` or stopping it manually with `Ctrl+C`). 
 These hooks won't run if the container stops by itself or gets killed suddenly.
 
-In the following example, before the container stops, the `./data_flush.sh` script is 
-run to perform any necessary cleanup.
+Because the pre-stop hook runs before the stop signal is sent to the container, it is
+suited for actions that must complete while the application is still fully running.
+
+In the following example, the hook backs up a data file before the container receives the stop signal.
 
 ```yaml
 services:
   app:
     image: backend
+    volumes:
+      - data:/data
     pre_stop:
-      - command: ./data_flush.sh
+      - command: cp /data/app.db /data/app.db.bak
+
+volumes:
+  data: {} # a Docker volume is created with root ownership
 ```
 
 ## Reference information
diff --git a/content/manuals/compose/how-tos/model-runner.md b/content/manuals/compose/how-tos/model-runner.md
deleted file mode 100644
index 36d27b2b7eba..000000000000
--- a/content/manuals/compose/how-tos/model-runner.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Use Docker Model Runner
-description: Learn how to integrate Docker Model Runner with Docker Compose to build AI-powered applications
-keywords: compose, docker compose, model runner, ai, llm, artificial intelligence, machine learning
-weight: 111
-params:
-  sidebar:
-    badge:
-      color: green
-      text: New
----
-
-{{< summary-bar feature_name="Compose model runner" >}}
-
-Docker Model Runner can be integrated with Docker Compose to run AI models as part of your multi-container applications.  
-This lets you define and run AI-powered applications alongside your other services.
-
-## Prerequisites
-
-- Docker Compose v2.35 or later
-- Docker Desktop 4.41 or later 
-- Docker Desktop for Mac with Apple Silicon or Docker Desktop for Windows with NVIDIA GPU
-- [Docker Model Runner enabled in Docker Desktop](/manuals/ai/model-runner.md#enable-docker-model-runner)
-
-## Provider services
-
-Compose introduces a new service type called `provider` that allows you to declare platform capabilities required by your application. For AI models, you can use the `model` type to declare model dependencies.
-
-Here's an example of how to define a model provider:
-
-```yaml
-services:
-  chat:
-    image: my-chat-app
-    depends_on:
-      - ai-runner
-
-  ai-runner:
-    provider:
-      type: model
-      options:
-        model: ai/smollm2
-```
-
-Notice the dedicated `provider` attribute in the `ai-runner` service.   
-This attribute specifies that the service is a model provider and lets you define options such as the name of the model to be used.
-
-There is also a `depends_on` attribute in the `chat` service.  
-This attribute specifies that the `chat` service depends on the `ai-runner` service.  
-This means that the `ai-runner` service will be started before the `chat` service to allow injection of model information to the `chat` service.
-
-## How it works
-
-During the `docker compose up` process, Docker Model Runner automatically pulls and runs the specified model.  
-It also sends Compose the model tag name and the URL to access the model runner.
-
-This information is then passed to services which declare a dependency on the model provider.  
-In the example above, the `chat` service receives 2 environment variables prefixed by the service name:
- - `AI-RUNNER_URL` with the URL to access the model runner
- - `AI-RUNNER_MODEL` with the model name which could be passed with the URL to request the model.
-
-This lets the `chat` service to interact with the model and use it for its own purposes.
-
-## Reference
-
-- [Docker Model Runner documentation](/manuals/ai/model-runner.md)
diff --git a/content/manuals/compose/how-tos/multiple-compose-files/_index.md b/content/manuals/compose/how-tos/multiple-compose-files/_index.md
index d7e9dc78a0da..d0520f3104b3 100644
--- a/content/manuals/compose/how-tos/multiple-compose-files/_index.md
+++ b/content/manuals/compose/how-tos/multiple-compose-files/_index.md
@@ -13,7 +13,10 @@ This section contains information on the ways you can work with multiple Compose
 
 Using multiple Compose files lets you customize a Compose application for different environments or workflows. This is useful for large applications that may use dozens of containers, with ownership distributed across multiple teams. For example, if your organization or team uses a monorepo, each team may have their own “local” Compose file to run a subset of the application. They then need to rely on other teams to provide a reference Compose file that defines the expected way to run their own subset. Complexity moves from the code in to the infrastructure and the configuration file.
 
-The quickest way to work with multiple Compose files is to [merge](merge.md) Compose files using the `-f` flag in the command line to list out your desired Compose files. However, [merging rules](merge.md#merging-rules) means this can soon get quite complicated.
+The simplest way to work with multiple Compose files is to [merge](merge.md) them using
+the `-f` flag. This works well for straightforward overrides, but the
+[merging rules](merge.md#merging-rules) can make it complex to manage as your
+configuration grows.
 
 Docker Compose provides two other options to manage this complexity when working with multiple Compose files. Depending on your project's needs, you can: 
 
diff --git a/content/manuals/compose/how-tos/multiple-compose-files/extends.md b/content/manuals/compose/how-tos/multiple-compose-files/extends.md
index 2ba1bb55b99e..295d4353b6a2 100644
--- a/content/manuals/compose/how-tos/multiple-compose-files/extends.md
+++ b/content/manuals/compose/how-tos/multiple-compose-files/extends.md
@@ -1,13 +1,11 @@
 ---
-description: How to use Docker Compose's extends keyword to share configuration between
-  files and projects
-keywords: fig, composition, compose, docker, orchestration, documentation, docs
+description: Learn how to reuse service configurations across files and projects using Docker Compose’s extends attribute.
+keywords: fig, composition, compose, docker, orchestration, documentation, docs, compose file modularization
 title: Extend your Compose file
 linkTitle: Extend
 weight: 20
 aliases:
 - /compose/extends/
-- /compose/multiple-compose-files/extends/
 ---
 
 Docker Compose's [`extends` attribute](/reference/compose-file/services.md#extends)
@@ -29,7 +27,13 @@ configuration. Tracking which fragment of a service is relative to which path is
 difficult and confusing, so to keep paths easier to understand, all paths must
 be defined relative to the base file. 
 
-## How it works
+> [!NOTE]
+>
+> `extends` is not supported when deploying with `docker stack deploy`. Running
+> `docker stack config` on a Compose file that uses `extends` returns the error:
+> `Configuration contains forbidden properties`.
+
+## How the `extends` attribute works
 
 ### Extending services from another file
 
@@ -43,7 +47,7 @@ services:
       service: webapp
 ```
 
-This instructs Compose to re-use only the properties of the `webapp` service
+This instructs Compose to reuse only the properties of the `webapp` service
 defined in the `common-services.yml` file. The `webapp` service itself is not part of the final project.
 
 If `common-services.yml`
@@ -62,12 +66,12 @@ You get exactly the same result as if you wrote
 `compose.yaml` with the same `build`, `ports`, and `volumes` configuration
 values defined directly under `web`.
 
-To include the service `webapp` in the final project when extending services from another file, you need to explicitly include both services in your current Compose file. For example (note this is a non-normative example):
+To include the service `webapp` in the final project when extending services from another file, you need to explicitly include both services in your current Compose file. For example (this is for illustrative purposes only):
 
 ```yaml
 services:
   web:
-    build: alpine
+    build: ./alpine
     command: echo
     extends:
       file: common-services.yml
@@ -87,7 +91,7 @@ If you define services in the same Compose file and extend one service from anot
 ```yaml 
 services:
   web:
-    build: alpine
+    build: ./alpine
     extends: webapp
   webapp:
     environment:
@@ -158,20 +162,6 @@ services:
       - queue
 ```
 
-## Exceptions and limitations
-
-`volumes_from` and `depends_on` are never shared between services using
-`extends`. These exceptions exist to avoid implicit dependencies; you always
-define `volumes_from` locally. This ensures dependencies between services are
-clearly visible when reading the current file. Defining these locally also
-ensures that changes to the referenced file don't break anything.
-
-`extends` is useful if you only need a single service to be shared and you are
-familiar with the file you're extending to, so you can tweak the
-configuration. But this isn’t an acceptable solution when you want to re-use
-someone else's unfamiliar configurations and you don’t know about its own
-dependencies.
-
 ## Relative paths
 
 When using `extends` with a `file` attribute which points to another folder, relative paths 
diff --git a/content/manuals/compose/how-tos/multiple-compose-files/include.md b/content/manuals/compose/how-tos/multiple-compose-files/include.md
index a07f0b989139..487b812ac2df 100644
--- a/content/manuals/compose/how-tos/multiple-compose-files/include.md
+++ b/content/manuals/compose/how-tos/multiple-compose-files/include.md
@@ -2,8 +2,6 @@
 description: How to use Docker Compose's include top-level element
 keywords: compose, docker, include, compose file
 title: Include
-aliases:
-- /compose/multiple-compose-files/include/
 ---
 
 {{< summary-bar feature_name="Compose include" >}}
@@ -18,7 +16,7 @@ Once the included Compose application loads, all resources are copied into the c
 
 > [!NOTE]
 >
-> `include` applies recursively so an included Compose file which declares its own `include` section, results in those other files being included as well.
+> `include` applies recursively so an included Compose file which declares its own `include` section, causes those files to also be included.
 
 ## Example
 
@@ -36,11 +34,24 @@ services:
 
 This means the team managing `serviceB` can refactor its own database component to introduce additional services without impacting any dependent teams. It also means that the dependent teams don't need to include additional flags on each Compose command they run.
 
-## Include and overrides
+```yaml
+include:
+  - oci://docker.io/username/my-compose-app:latest # use a Compose file stored as an OCI artifact
+services:
+  serviceA:
+    build: .
+    depends_on:
+      - serviceB 
+```
+`include` allows you to reference Compose files from remote sources, such as OCI artifacts or Git repositories.  
+Here `serviceB` is defined in a Compose file stored on Docker Hub.
+
+## Using overrides with included Compose files
 
 Compose reports an error if any resource from `include` conflicts with resources from the included Compose file. This rule prevents
-unexpected conflicts with resources defined by the included compose file author. However, there may be some circumstances where you might want to tweak the
+unexpected conflicts with resources defined by the included compose file author. However, there may be some circumstances where you might want to customize the
 included model. This can be achieved by adding an override file to the include directive:
+
 ```yaml
 include:
   - path : 
@@ -49,7 +60,7 @@ include:
 ```
 
 The main limitation with this approach is that you need to maintain a dedicated override file per include. For complex projects with multiple
-includes this would result into many Compose files.
+includes this would result in many Compose files.
 
 The other option is to use a `compose.override.yaml` file. While conflicts will be rejected from the file using `include` when same
 resource is declared, a global Compose override file can override the resulting merged model, as demonstrated in following example:
diff --git a/content/manuals/compose/how-tos/multiple-compose-files/merge.md b/content/manuals/compose/how-tos/multiple-compose-files/merge.md
index 360d73d24756..ebadca7c40a7 100644
--- a/content/manuals/compose/how-tos/multiple-compose-files/merge.md
+++ b/content/manuals/compose/how-tos/multiple-compose-files/merge.md
@@ -4,8 +4,6 @@ keywords: compose, docker, merge, compose file
 title: Merge Compose files
 linkTitle: Merge
 weight: 10
-aliases:
-- /compose/multiple-compose-files/merge/
 ---
 
 Docker Compose lets you merge and override a set of Compose files together to create a composite Compose file.
@@ -246,14 +244,14 @@ For more merging rules, see [Merge and override](/reference/compose-file/merge.m
    
 - You can use the `-f` flag to specify a path to a Compose file that is not located in the current directory, either from the command line or by setting up a [COMPOSE_FILE environment variable](../environment-variables/envvars.md#compose_file) in your shell or in an environment file.
 
-   For example, if you are running the [Compose Rails sample](https://github.com/docker/awesome-compose/tree/master/official-documentation-samples/rails/README.md), and have a `compose.yaml` file in a directory called `sandbox/rails`. You can use a command like [docker compose pull](/reference/cli/docker/compose/pull.md) to get the postgres image for the `db` service from anywhere by using the `-f` flag as follows: `docker compose -f ~/sandbox/rails/compose.yaml pull db`
+   For example, if you are running the [Compose Rails sample](https://github.com/docker/awesome-compose/tree/master/official-documentation-samples/rails/README.md), and have a `compose.yaml` file in a directory called `sandbox/rails`. You can use a command like [docker compose pull](/reference/cli/docker/compose/pull/) to get the postgres image for the `db` service from anywhere by using the `-f` flag as follows: `docker compose -f ~/sandbox/rails/compose.yaml pull db`
 
    Here's the full example:
 
    ```console
    $ docker compose -f ~/sandbox/rails/compose.yaml pull db
-   Pulling db (postgres:latest)...
-   latest: Pulling from library/postgres
+   Pulling db (postgres:18)...
+   18: Pulling from library/postgres
    ef0380f84d05: Pull complete
    50cf91dc1db8: Pull complete
    d3add4cd115c: Pull complete
@@ -268,7 +266,7 @@ For more merging rules, see [Merge and override](/reference/compose-file/merge.m
    dcca70822752: Pull complete
    cecf11b8ccf3: Pull complete
    Digest: sha256:1364924c753d5ff7e2260cd34dc4ba05ebd40ee8193391220be0f9901d4e1651
-   Status: Downloaded newer image for postgres:latest
+   Status: Downloaded newer image for postgres:18
    ```
 
 ## Example
@@ -292,7 +290,7 @@ services:
       - cache
 
   db:
-    image: postgres:latest
+    image: postgres:18
 
   cache:
     image: redis:latest
@@ -358,8 +356,22 @@ For more information, see [Using Compose in production](../production.md).
 
 ## Limitations
 
-Docker Compose supports relative paths for the many resources to be included in the application model: build context for service images, location of file defining environment variables, path to a local directory used in a bind-mounted volume.
-With such a constraint, code organization in a monorepo can become hard as a natural choice would be to have dedicated folders per team or component, but then the Compose files relative paths become irrelevant. 
+When merging Compose files, all relative paths (for build contexts, environment files,
+bind-mounted volumes, and other resources) are resolved relative to the base Compose file. The
+first file specified with `-f`, or `compose.yaml` in the current directory if `-f` is
+not used. Paths in override files are not resolved relative to the override file's own
+location.
+
+This means that in a monorepo where Compose files are spread across team or component
+subdirectories, relative paths in those files are resolved incorrectly when used as
+override files.
+
+> [!TIP] 
+>
+> If you need each Compose file's paths to resolve relative to its own location,
+> use the [`include` top-level element](include.md) instead of merging with `-f`. Each
+> included file is loaded with its own project directory, so relative paths resolve
+> correctly.
 
 ## Reference information
 
diff --git a/content/manuals/compose/how-tos/networking.md b/content/manuals/compose/how-tos/networking.md
index bea3c4004d7a..c025a080350f 100644
--- a/content/manuals/compose/how-tos/networking.md
+++ b/content/manuals/compose/how-tos/networking.md
@@ -5,22 +5,16 @@ title: Networking in Compose
 linkTitle: Networking
 weight: 70
 aliases:
-- /compose/networking/
+  - /compose/networking/
 ---
 
-{{% include "compose-eol.md" %}}
+Compose handles networking for you by default, but gives you fine-grained control when you need it. This page explains how the default network works and how containers discover each other by name. It also covers when and how to define custom networks, connect services across separate Compose projects, map custom hostnames, and debug connectivity issues.
 
-By default Compose sets up a single
-[network](/reference/cli/docker/network/create.md) for your app. Each
-container for a service joins the default network and is both reachable by
-other containers on that network, and discoverable by the service's name.
+## Default network and service discovery
 
-> [!NOTE]
->
-> Your app's network is given a name based on the "project name",
-> which is based on the name of the directory it lives in. You can override the
-> project name with either the [`--project-name` flag](/reference/cli/docker/compose.md)
-> or the [`COMPOSE_PROJECT_NAME` environment variable](environment-variables/envvars.md#compose_project_name).
+By default, Compose sets up a single [network](/reference/cli/docker/network/create/) for your app. Each container for a service joins the default network and is both reachable by other containers on that network, and discoverable by its service name. This network uses the `bridge` driver. To attach services to a different Compose network or an external one, see [Specify custom networks](#specify-custom-networks). To change how a service uses the host network stack (`network_mode: host`), see [Change the network mode](#change-the-network-mode).
+
+For most development setups, the default network is sufficient. When you run `docker compose up`, Compose creates a network named `<project-name>_default` and attaches all services to it. Each service registers its name with an internal DNS server, so containers can reach each other using the service name directly. No IP addresses or manual configuration is needed.
 
 For example, suppose your app is in a directory called `myapp`, and your `compose.yaml` looks like this:
 
@@ -31,71 +25,65 @@ services:
     ports:
       - "8000:8000"
   db:
-    image: postgres
+    image: postgres:latest
     ports:
       - "8001:5432"
 ```
 
+Compose automatically connects all services to the default network, so you don't need to define `networks` explicitly in the Compose file.
+
 When you run `docker compose up`, the following happens:
 
-1.  A network called `myapp_default` is created.
-2.  A container is created using `web`'s configuration. It joins the network
-    `myapp_default` under the name `web`.
-3.  A container is created using `db`'s configuration. It joins the network
-    `myapp_default` under the name `db`.
+1. A network called `myapp_default` is created.
+2. A container is created using `web`'s configuration. It joins `myapp_default` under the name `web`.
+3. A container is created using `db`'s configuration. It joins `myapp_default` under the name `db`.
 
-Each container can now look up the service name `web` or `db` and
-get back the appropriate container's IP address. For example, `web`'s
-application code could connect to the URL `postgres://db:5432` and start
-using the Postgres database.
+Each container can now look up the service name `web` or `db` and get back the appropriate container's IP address. The `web` service can connect to the database at `postgres://db:5432`. From the host machine, the same database is accessible at `postgres://localhost:8001` if your container is running locally.
+
+> [!TIP]
+>
+> Docker assigns container IP addresses dynamically from the network's subnet each time a container starts so they are not persisted across restarts or recreations. This means you should always reference services by name, not IP address. When containers are recreated, for example after a configuration change, they receive a new IP address. The service name stays stable.
 
-It is important to note the distinction between `HOST_PORT` and `CONTAINER_PORT`.
-In the above example, for `db`, the `HOST_PORT` is `8001` and the container port is
-`5432` (postgres default). Networked service-to-service
-communication uses the `CONTAINER_PORT`. When `HOST_PORT` is defined,
-the service is accessible outside the swarm as well.
+Your app's network is given a name based on the "project name", which is taken from the name of the directory it lives in. You can override the project name with either the [`--project-name` flag](/reference/cli/docker/compose/) or the [`COMPOSE_PROJECT_NAME` environment variable](environment-variables/envvars.md#compose_project_name).
 
-Within the `web` container, your connection string to `db` would look like
-`postgres://db:5432`, and from the host machine, the connection string would
-look like `postgres://{DOCKER_IP}:8001` for example `postgres://localhost:8001` if your container is running locally.
+The `HOST_PORT` and `CONTAINER_PORT` serve different purposes. In the example above, for `db`, the `HOST_PORT` is `8001` and the container port is `5432` (the Postgres default). Networked service-to-service communication uses the `CONTAINER_PORT`. The host port is only used when accessing the service from outside the network.
 
-## Update containers on the network
+### Updating containers on the network
 
 If you make a configuration change to a service and run `docker compose up` to update it, the old container is removed and the new one joins the network under a different IP address but the same name. Running containers can look up that name and connect to the new address, but the old address stops working.
 
-If any containers have connections open to the old container, they are closed. It is a container's responsibility to detect this condition, look up the name again and reconnect.
+If any containers have connections open to the old container, they are closed. It is each container's responsibility to detect this condition, look up the name again, and reconnect.
 
-> [!TIP]
->
-> Reference containers by name, not IP, whenever possible. Otherwise you’ll need to constantly update the IP address you use.
-
-## Link containers
+## Change the network mode
 
-Links allow you to define extra aliases by which a service is reachable from another service. They are not required to enable services to communicate. By default, any service can reach any other service at that service's name. In the following example, `db` is reachable from `web` at the hostnames `db` and `database`:
+By default, each service joins the project's bridge network. It is the most secure networking mode. If you don't specify [`network_mode`](/reference/compose-file/services.md#network_mode), this is the type of network you are creating.
 
-```yaml
-services:
-
-  web:
-    build: .
-    links:
-      - "db:database"
-  db:
-    image: postgres
-```
+You can override the networking mode on a per-service basis. The `network_mode` option accepts the following values:
 
-See the [links reference](/reference/compose-file/services.md#links) for more information.
+- `host`: The container shares the host's network stack. No port mapping is needed or supported, and service name DNS resolution does not work. Use for system-level tools like network monitors that require direct access to host interfaces. A container using `network_mode: host` can access all host ports and observe all network traffic on the host. Use it only when genuinely required.
+- `none`: Turns off all container networking.
+- `service:{name}`: Gives the container access to the specified container by referring to its service name.
+- `container:{name}`: Gives the container access to the specified container by referring to its container ID.
 
-## Multi-host networking
+You can mix modes in a single project:
 
-When deploying a Compose application on a Docker Engine with [Swarm mode enabled](/manuals/engine/swarm/_index.md),
-you can make use of the built-in `overlay` driver to enable multi-host communication.
+```yaml
+services:
+  app:
+    image: myapp
+    networks:
+      - isolated
+    ports:
+      - "3000:3000"
 
-Overlay networks are always created as `attachable`. You can optionally set the [`attachable`](/reference/compose-file/networks.md#attachable) property to `false`.
+  monitoring:
+    image: netdata/netdata
+    network_mode: host   # Can monitor host system and all host ports
 
-Consult the [Swarm mode section](/manuals/engine/swarm/_index.md), to see how to set up
-a Swarm cluster, and the [Getting started with multi-host networking](/manuals/engine/network/tutorials/overlay.md)
-to learn about multi-host overlay networks.
+networks:
+  isolated:
+    driver: bridge
+```
 
 ## Specify custom networks
 
@@ -117,19 +105,17 @@ services:
       - frontend
       - backend
   db:
-    image: postgres
+    image: postgres:latest
     networks:
       - backend
 
 networks:
   frontend:
-    # Specify driver options
-    driver: bridge
+    driver: bridge   # Specify driver options
     driver_opts:
       com.docker.network.bridge.host_binding_ipv4: "127.0.0.1"
   backend:
-    # Use a custom driver
-    driver: custom-driver
+    driver: custom-driver  # Use a custom driver
 ```
 
 Networks can be configured with static IP addresses by setting the [ipv4_address and/or ipv6_address](/reference/compose-file/services.md#ipv4_address-ipv6_address) for each attached network.
@@ -145,7 +131,32 @@ networks:
     driver: custom-driver-1
 ```
 
-## Configure the default network
+### Internal networks
+
+Setting `internal: true` on a network creates it without a connection to the host's network interfaces. It has no default gateway for external connectivity. This is useful for services like databases that should be completely unreachable from outside the container network:
+
+```yaml
+services:
+  cache:
+    image: redis
+    networks:
+      - isolated
+
+  worker:
+    image: myworker
+    networks:
+      - isolated
+      - public
+
+networks:
+  isolated:
+    internal: true   # No external connectivity
+  public:   # Standard bridge network, created by Compose on docker compose up
+```
+
+Note that a service connected to both an internal and a non-internal network (like `worker` above) can still reach the internet via the non-internal network `public`.
+
+### Configure the default network
 
 Instead of, or as well as, specifying your own networks, you can also change the settings of the app-wide default network by defining an entry under `networks` named `default`:
 
@@ -156,17 +167,17 @@ services:
     ports:
       - "8000:8000"
   db:
-    image: postgres
+    image: postgres:latest
 
 networks:
   default:
-    # Use a custom driver
-    driver: custom-driver-1
+    driver: custom-driver-1   # Use a custom driver
 ```
 
-## Use a pre-existing network
+## Use an existing external network
+
+If you've manually created a bridge network using `docker network create`, you can connect your Compose services to it by marking the network as [`external`](/reference/compose-file/networks.md#external):
 
-If you want your containers to join a pre-existing network, use the [`external` option](/reference/compose-file/networks.md#external)
 ```yaml
 services:
   # ...
@@ -176,9 +187,203 @@ networks:
     external: true
 ```
 
-Instead of attempting to create a network called `[projectname]_default`, Compose looks for a network called `my-pre-existing-network` and connects your app's containers to it.
+Instead of creating `<project-name>_default`, Compose looks for a network called `my-pre-existing-network` and connects your containers to it.
+
+### Connecting multiple Compose projects
+
+External networks are particularly useful when services in separate Compose projects need to communicate. Create a shared network once, then reference it as external in each project:
+
+```bash
+docker network create inter-project
+```
+
+backend-compose.yaml:
+
+```yaml
+services:
+  api:
+    image: myapi:latest
+    networks:
+      - shared
+      - default   # Also keep the project's internal network
+
+networks:
+  shared:
+    external: true
+    name: inter-project
+```
+
+frontend-compose.yaml:
+
+```yaml
+services:
+  web:
+    image: myfrontend:latest
+    environment:
+      API_URL: http://api:8080   # Reference by service name
+    networks:
+      - shared
+
+networks:
+  shared:
+    external: true
+    name: inter-project
+```
+
+Services on the same external network can reach each other by service name, just like services within a single project.
+
+> [!IMPORTANT]
+>
+> The external network must exist before you run `docker compose up`. If it doesn't, Compose fails with a `Network not found` error. Always create it first with `docker network create`.
+
+## Hybrid networking
+
+A service can belong to both an external shared network and its own project-internal network. This lets you expose only the services that need to be reachable from other projects, while keeping everything else, such as databases, fully isolated:
+
+```yaml
+services:
+  api:
+    image: myapp-api
+    networks:
+      - shared     # Reachable from other projects
+      - internal   # Can also reach the database
+
+  database:
+    image: postgres:latest
+    networks:
+      - internal   # Not exposed on the shared network
+
+networks:
+  shared:
+    name: inter-project
+    external: true
+  internal: {}     # Project-specific, isolated
+```
+
+## Custom DNS with `extra_hosts`
+
+You can add custom hostname-to-IP mappings to a container's `/etc/hosts` file using [`extra_hosts`](/reference/compose-file/services.md#extra_hosts). This is useful when a service needs to resolve a hostname that isn't registered in Docker's internal DNS. For example, a fixed-IP dependency or a staging endpoint:
+
+```yaml
+services:
+  app:
+    image: myapp
+    extra_hosts:
+      - "api.staging:192.168.1.100"
+      - "cache.internal:192.168.1.101"
+```
+
+To map a hostname dynamically to the host machine's IP, use the special `host-gateway` value:
+
+```yaml
+services:
+  app:
+    image: myapp
+    extra_hosts:
+      - "host.docker.internal:host-gateway"
+```
+
+On Linux, `host-gateway` resolves to the host's IP on the default bridge network. On Mac and Windows, Docker automatically provides this, `host-gateway` resolves to the same internal IP address as `host.docker.internal`.
+
+You can also drive `extra_hosts` from environment variables, which makes it easy to point services at different targets per environment:
+
+```yaml
+services:
+  app:
+    image: myapp
+    extra_hosts:
+      - "api.service:${API_HOST:-127.0.0.1}"
+      - "auth.service:${AUTH_HOST:-127.0.0.1}"
+```
+
+Where `.env.development` might set `API_HOST=localhost` and a production env file might set `API_HOST=10.0.1.50`.
+
+To verify what has been injected, inspect the hosts file inside the container:
+
+```bash
+$ docker compose exec app cat /etc/hosts
+```
+
+## Multi-host networking
+
+When deploying a Compose application on a Docker Engine with [Swarm mode enabled](/manuals/engine/swarm/_index.md), you can use the built-in `overlay` driver to enable multi-host communication. Overlay networks are always created as `attachable`. You can optionally set the [`attachable`](/reference/compose-file/networks.md#attachable) property to `false`.
+
+To learn more, see the [overlay network driver documentation](/manuals/engine/network/drivers/overlay.md).
+
+## Link containers
+
+Links allow you to define extra aliases by which a service is reachable from another service. They are not required for basic service-to-service communication. By default, any service can reach any other service at that service's name. In the following example, `db` is reachable from `web` at both the hostnames `db` and `database`:
+
+```yaml
+services:
+  web:
+    build: .
+    links:
+      - "db:database"
+  db:
+    image: postgres:latest
+```
+
+See the [links reference](/reference/compose-file/services.md#links) for more information.
+
+## Debugging
+
+When a service can't reach another, work through the following steps in order: first confirm the network configuration looks right, then confirm the containers are actually attached, then test live connectivity.
+
+### Inspect port mappings
+
+To find out which host port maps to a container port, use `docker compose port`:
+
+```bash
+# Which host port maps to container port 5432 on db?
+$ docker compose port db 5432
+# Output: 0.0.0.0:8001
+```
+
+This is especially useful when using dynamic port mapping, where the host port changes on every `docker compose up`:
+
+```yaml
+services:
+  web:
+    image: nginx
+    ports:
+      - "80"   # Docker assigns the host port dynamically
+```
+
+```bash
+$ docker compose port web 80
+# Output: 0.0.0.0:55432
+```
+
+When you scale a service, each replica gets its own dynamic port. Use `--index` to query a specific replica:
+
+```bash
+$ docker compose up -d --scale web=3
+
+$ docker compose port --index=1 web 80   # Output: 0.0.0.0:55001
+$ docker compose port --index=2 web 80   # Output: 0.0.0.0:55002
+$ docker compose port --index=3 web 80   # Output: 0.0.0.0:55003
+```
+
+By default, `docker compose port` looks for TCP mappings. If a service exposes both TCP and UDP on the same port, use `--protocol`:
+
+```bash
+$ docker compose port --protocol=udp myservice 53
+```
+
+### Verify network membership
+
+To check which containers are attached to a network (useful when troubleshooting connectivity across external or custom networks):
+
+```bash
+$ docker network inspect <network-name>
+```
+
+### Check connectivity
+
+If the network membership looks correct but services still can't reach each other, test connectivity from inside a running container using `docker compose exec`.
 
-## Further reference information 
+## Further reference information
 
 For full details of the network configuration options available, see the following references:
 
diff --git a/content/manuals/compose/how-tos/oci-artifact.md b/content/manuals/compose/how-tos/oci-artifact.md
index 0791df4e6f6b..6a2a6c669ee9 100644
--- a/content/manuals/compose/how-tos/oci-artifact.md
+++ b/content/manuals/compose/how-tos/oci-artifact.md
@@ -1,14 +1,9 @@
 ---
-title: Using Docker Compose with OCI artifacts
+title: Package and deploy Docker Compose applications as OCI artifacts
 linkTitle: OCI artifact applications
 weight: 110
-description: How to publish and start Compose applications as OCI artifacts
-keywords: cli, compose, oci, docker hub, artificats, publish, package, distribute
-params:
-  sidebar:
-    badge:
-      color: green
-      text: New
+description: Learn how to package, publish, and securely run Docker Compose applications from OCI-compliant registries.
+keywords: cli, compose, oci, docker hub, artificats, publish, package, distribute, docker compose oci support
 ---
 
 {{< summary-bar feature_name="Compose OCI artifact" >}}
@@ -18,7 +13,7 @@ Docker Compose supports working with [OCI artifacts](/manuals/docker-hub/repos/m
 ## Publish your Compose application as an OCI artifact
 
 To distribute your Compose application as an OCI artifact, you can use the `docker compose publish` command, to publish it to an OCI-compliant registry. 
-This allows others to deploy your application directly from the registry.
+This allows others to then deploy your application directly from the registry.
 
 The publish function supports most of the composition capabilities of Compose, like overrides, extends or include, [with some limitations](#limitations).
 
@@ -84,12 +79,12 @@ Are you ok to publish these environment variables? [y/N]:
 
 If you decline, the publish process stops without sending anything to the registry.
 
-### Limitations
+## Limitations
 
-There is limitations to publishing Compose applications as OCI artifacts. You can't publish a Compose configuration:
+There are limitations to publishing Compose applications as OCI artifacts. You can't publish a Compose configuration:
 - With service(s) containing bind mounts
 - With service(s) containing only a `build` section
-- That includes local files with the `include` attribute. To publish successfully, ensure that any included local files are also published. You can then `include` to reference these files as remote `include` is supported.
+- That includes local files with the `include` attribute. To publish successfully, ensure that any included local files are also published. You can then use  `include` to reference these files as remote `include` is supported.
 
 ## Start an OCI artifact application
 
@@ -147,3 +142,10 @@ The `docker compose publish` command supports non-interactive execution, letting
 ```console
 $ docker compose publish -y username/my-compose-app:latest
 ```
+
+## Next steps
+
+- [Familiarize yourself with Compose's trust model](/manuals/compose/trust-model.md)
+- [Learn about OCI artifacts in Docker Hub](/manuals/docker-hub/repos/manage/hub-images/oci-artifacts.md)
+- [Compose publish command](/reference/cli/docker/compose/publish/)
+- [Understand `include`](/reference/compose-file/include.md)
diff --git a/content/manuals/compose/how-tos/production.md b/content/manuals/compose/how-tos/production.md
index 0392c00ff9bd..c520bf6105cd 100644
--- a/content/manuals/compose/how-tos/production.md
+++ b/content/manuals/compose/how-tos/production.md
@@ -1,6 +1,6 @@
 ---
-description: Guide to using Docker Compose in production
-keywords: compose, orchestration, containers, production
+description: Learn how to configure, deploy, and update Docker Compose applications for production environments.
+keywords: compose, orchestration, containers, production, production docker compose configuration
 title: Use Compose in production
 weight: 100
 aliases:
@@ -29,8 +29,8 @@ production. These changes might include:
 - Adding extra services such as a log aggregator
 
 For this reason, consider defining an additional Compose file, for example
-`compose.production.yaml`, which specifies production-appropriate
-configuration. This configuration file only needs to include the changes you want to make from the original Compose file. The additional Compose file
+`compose.production.yaml`, with production-specific
+configuration details. This configuration file only needs to include the changes you want to make from the original Compose file. The additional Compose file
 is then applied over the original `compose.yaml` to create a new configuration.
 
 Once you have a second configuration file, you can use it with the
@@ -55,7 +55,7 @@ $ docker compose up --no-deps -d web
 
 This first command rebuilds the image for `web` and then stops, destroys, and recreates
 just the `web` service. The `--no-deps` flag prevents Compose from also
-recreating any services which `web` depends on.
+recreating any services that `web` depends on.
 
 ### Running Compose on a single server
 
@@ -65,3 +65,9 @@ appropriately. For more information, see [pre-defined environment variables](env
 
 Once you've set up your environment variables, all the normal `docker compose`
 commands work with no further configuration.
+
+## Next steps
+
+- [Familiarize yourself with Compose's trust model](/manuals/compose/trust-model.md)
+- [Using multiple Compose files](multiple-compose-files/_index.md)
+
diff --git a/content/manuals/compose/how-tos/profiles.md b/content/manuals/compose/how-tos/profiles.md
index 5d90153606b1..74641023c181 100644
--- a/content/manuals/compose/how-tos/profiles.md
+++ b/content/manuals/compose/how-tos/profiles.md
@@ -50,7 +50,7 @@ Valid profiles names follow the regex format of `[a-zA-Z0-9][a-zA-Z0-9_.-]+`.
 
 ## Start specific profiles
 
-To start a specific profile supply the `--profile` [command-line option](/reference/cli/docker/compose.md) or
+To start a specific profile supply the `--profile` [command-line option](/reference/cli/docker/compose/) or
 use the [`COMPOSE_PROFILES` environment variable](environment-variables/envvars.md#compose_profiles):
 
 ```console
@@ -85,6 +85,12 @@ If you want to enable all profiles at the same time, you can run `docker compose
 
 ## Auto-starting profiles and dependency resolution
 
+When you explicitly target a service on the command line that has one or more profiles assigned, you do not need to enable the profile manually as Compose runs that service regardless of whether its profile is activated. This is useful for running one-off services or debugging tools.
+
+Only the targeted service (and any of its declared dependencies via `depends_on`) is started. Other services that share the same profile will not be started unless:
+- They are also explicitly targeted, or
+- The profile is explicitly enabled using `--profile` or `COMPOSE_PROFILES`.
+
 When a service with assigned `profiles` is explicitly targeted on the command
 line its profiles are started automatically so you don't need to start them
 manually. This can be used for one-off services and debugging tools.
@@ -108,76 +114,23 @@ services:
 ```
 
 ```sh
-# Only start backend and db
+# Only start backend and db (no profiles involved)
 $ docker compose up -d
 
-# This runs db-migrations (and, if necessary, start db)
-# by implicitly enabling the profiles "tools"
+# Run the db-migrations service without manually enabling the 'tools' profile
 $ docker compose run db-migrations
 ```
 
-But keep in mind that `docker compose` only automatically starts the
-profiles of the services on the command line and not of any dependencies. 
-
-This means that any other services the targeted service `depends_on` should either:
-- Share a common profile 
-- Always be started, by omitting `profiles` or having a matching profile started explicitly
-
-```yaml
-services:
-  web:
-    image: web
-
-  mock-backend:
-    image: backend
-    profiles: ["dev"]
-    depends_on:
-      - db
-
-  db:
-    image: mysql
-    profiles: ["dev"]
-
-  phpmyadmin:
-    image: phpmyadmin
-    profiles: ["debug"]
-    depends_on:
-      - db
-```
-
-```sh
-# Only start "web"
-$ docker compose up -d
-
-# Start mock-backend (and, if necessary, db)
-# by implicitly enabling profiles "dev"
-$ docker compose up -d mock-backend
-
-# This fails because profiles "dev" is not enabled
-$ docker compose up phpmyadmin
-```
-
-Although targeting `phpmyadmin` automatically starts the profiles `debug`, it doesn't automatically start the profiles required by `db` which is `dev`. 
+In this example, `db-migrations` runs even though it is assigned to the tools profile, because it was explicitly targeted. The `db` service is also started automatically because it is listed in `depends_on`.
 
-To fix this you either have to add the `debug` profile to the `db` service:
-
-```yaml
-db:
-  image: mysql
-  profiles: ["debug", "dev"]
-```
-
-or start the `dev` profile explicitly:
-
-```console
-# Profiles "debug" is started automatically by targeting phpmyadmin
-$ docker compose --profile dev up phpmyadmin
-$ COMPOSE_PROFILES=dev docker compose up phpmyadmin
-```
+If the targeted service has dependencies that are also gated behind a profile, you must ensure those dependencies are either: 
+ - In the same profile
+ - Started separately
+ - Not assigned to any profile so are always enabled
 
 ## Stop application and services with specific profiles
 
-As with starting specific profiles, you can use the `--profile` [command-line option](/reference/cli/docker/compose.md#use--p-to-specify-a-project-name) or
+As with starting specific profiles, you can use the `--profile` [command-line option](/reference/cli/docker/compose/#use--p-to-specify-a-project-name) or
 use the [`COMPOSE_PROFILES` environment variable](environment-variables/envvars.md#compose_profiles):
 
 ```console
@@ -208,6 +161,7 @@ services:
 ```
 
 if you only want to stop the `phpmyadmin` service, you can run 
+
 ```console 
 $ docker compose down phpmyadmin
 ``` 
diff --git a/content/manuals/compose/how-tos/project-name.md b/content/manuals/compose/how-tos/project-name.md
index 18372aa7cc5e..be63fd17e405 100644
--- a/content/manuals/compose/how-tos/project-name.md
+++ b/content/manuals/compose/how-tos/project-name.md
@@ -1,20 +1,20 @@
 ---
 title: Specify a project name
 weight: 10
-description: Understand the different ways you can set a project name in Compose and what the precedence is.
+description: Learn how to set a custom project name in Compose and understand the precedence of each method.
 keywords: name, compose, project, -p flag, name top-level element
 aliases:
 - /compose/project-name/
 ---
 
-In Compose, the default project name is derived from the base name of the project directory. However, you have the flexibility to set a custom project name. 
+By default, Compose assigns the project name based on the name of the directory that contains the Compose file. You can override this with several methods.
 
 This page offers examples of scenarios where custom project names can be helpful, outlines the various methods to set a project name, and provides the order of precedence for each approach.
 
 > [!NOTE]
 >
 > The default project directory is the base directory of the Compose file. A custom value can also be set
-> for it using the [`--project-directory` command line option](/reference/cli/docker/compose.md#use--p-to-specify-a-project-name).
+> for it using the [`--project-directory` command line option](/reference/cli/docker/compose/#options).
 
 ## Example use cases
 
@@ -42,4 +42,4 @@ The precedence order for each method, from highest to lowest, is as follows:
 ## What's next?
 
 - Read up on [working with multiple Compose files](multiple-compose-files/_index.md).
-- Explore some [sample apps](samples-for-compose.md).
+- Explore some [sample apps](https://github.com/docker/awesome-compose).
diff --git a/content/manuals/compose/how-tos/provider-services.md b/content/manuals/compose/how-tos/provider-services.md
new file mode 100644
index 000000000000..c44a9f2f6e51
--- /dev/null
+++ b/content/manuals/compose/how-tos/provider-services.md
@@ -0,0 +1,124 @@
+---
+title: Use provider services
+description: Learn how to use provider services in Docker Compose to integrate external capabilities into your applications
+keywords: compose, docker compose, provider, services, platform capabilities, integration, model runner, ai
+weight: 130
+---
+
+{{< summary-bar feature_name="Compose provider services" >}}
+
+Docker Compose supports provider services, which allow integration with services whose lifecycles are managed by third-party components rather than by Compose itself.  
+This feature enables you to define and utilize platform-specific services without the need for manual setup or direct lifecycle management.
+
+## What are provider services?
+
+Provider services are a special type of service in Compose that represents platform capabilities rather than containers.
+They allow you to declare dependencies on specific platform features that your application needs.
+
+When you define a provider service in your Compose file, Compose works with the platform to provision and configure
+the requested capability, making it available to your application services.
+
+## Using provider services
+
+To use a provider service in your Compose file, you need to:
+
+1. Define a service with the `provider` attribute
+2. Specify the `type` of provider you want to use
+3. Configure any provider-specific options
+4. Declare dependencies from your application services to the provider service
+
+Here's a basic example:
+
+```yaml
+services:
+  database:
+    provider:
+      type: awesomecloud
+      options:
+        type: mysql
+        foo: bar  
+  app:
+    image: myapp 
+    depends_on:
+       - database
+```
+
+Notice the dedicated `provider` attribute in the `database` service.
+This attribute specifies that the service is managed by a provider and lets you define options specific to that provider type.
+
+The `depends_on` attribute in the `app` service specifies that it depends on the `database` service.
+This means that the `database` service will be started before the `app` service, allowing the provider information
+to be injected into the `app` service.
+
+## How it works
+
+During the `docker compose up` command execution, Compose identifies services relying on providers and works with them to provision
+the requested capabilities. The provider then populates Compose model with information about how to access the provisioned resource.
+
+This information is passed to services that declare a dependency on the provider service, typically through environment
+variables. The naming convention for these variables is:
+
+```env
+<<PROVIDER_SERVICE_NAME>>_<<VARIABLE_NAME>>
+```
+
+For example, if your provider service is named `database`, your application service might receive environment variables like:
+
+- `DATABASE_URL` with the URL to access the provisioned resource
+- `DATABASE_TOKEN` with an authentication token
+- Other provider-specific variables
+
+Your application can then use these environment variables to interact with the provisioned resource.
+
+## Provider types
+
+The `type` field in a provider service references the name of either:
+
+1. A Docker CLI plugin (e.g., `docker-model`)
+2. A binary available in the user's PATH
+3. A path to the binary or script to execute
+
+When Compose encounters a provider service, it looks for a plugin or binary with the specified name to handle the provisioning of the requested capability.
+
+For example, if you specify `type: model`, Compose will look for a Docker CLI plugin named `docker-model` or a binary named `model` in the PATH.
+
+```yaml
+services:
+  ai-runner:
+    provider:
+      type: model  # Looks for docker-model plugin or model binary
+      options:
+        model: ai/example-model
+```
+
+The plugin or binary is responsible for:
+
+1. Interpreting the options provided in the provider service
+2. Provisioning the requested capability
+3. Returning information about how to access the provisioned resource
+
+This information is then passed to dependent services as environment variables.
+
+> [!TIP]
+>
+> If you're working with AI models in Compose, use the [`models` top-level element](/manuals/ai/compose/models-and-compose.md) instead.
+
+## Benefits of using provider services
+
+Using provider services in your Compose applications offers several benefits:
+
+1. Simplified configuration: You don't need to manually configure and manage platform capabilities
+2. Declarative approach: You can declare all your application's dependencies in one place
+3. Consistent workflow: You use the same Compose commands to manage your entire application, including platform capabilities
+
+## Creating your own provider
+
+If you want to create your own provider to extend Compose with custom capabilities, you can implement a Compose plugin that registers provider types.
+
+For detailed information on how to create and implement your own provider, refer to the [Compose Extensions documentation](https://github.com/docker/compose/blob/main/docs/extension.md).   
+This guide explains the extension mechanism that allows you to add new provider types to Compose.
+
+## Reference
+
+- [Docker Model Runner documentation](/manuals/ai/model-runner.md)
+- [Compose Extensions documentation](https://github.com/docker/compose/blob/main/docs/extension.md)
\ No newline at end of file
diff --git a/content/manuals/compose/how-tos/startup-order.md b/content/manuals/compose/how-tos/startup-order.md
index 2234fff15690..156eda0d7ebb 100644
--- a/content/manuals/compose/how-tos/startup-order.md
+++ b/content/manuals/compose/how-tos/startup-order.md
@@ -1,6 +1,6 @@
 ---
-description: How to control service startup and shutdown order in Docker Compose
-keywords: documentation, docs, docker, compose, startup, shutdown, order
+description: Learn how to manage service startup and shutdown order in Docker Compose using depends_on and healthchecks.
+keywords: docker compose startup order, compose shutdown order, depends_on, service healthcheck, control service dependencies
 title: Control startup and shutdown order in Compose
 linkTitle: Control startup order
 weight: 30
@@ -13,7 +13,7 @@ You can control the order of service startup and shutdown with the
 containers in dependency order, where dependencies are determined by
 `depends_on`, `links`, `volumes_from`, and `network_mode: "service:..."`.
 
-A good example of when you might use this is an application which needs to access a database. If both services are started with `docker compose up`, there is a chance this will fail since the application service might start before the database service and won't find a database able to handle its SQL statements. 
+For example, if your application needs to access a database and both services are started with `docker compose up`, there is a chance this will fail since the application service might start before the database service and won't find a database able to handle its SQL statements. 
 
 ## Control startup
 
@@ -40,9 +40,9 @@ services:
   redis:
     image: redis
   db:
-    image: postgres
+    image: postgres:18
     healthcheck:
-      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
+      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
       interval: 10s
       retries: 5
       start_period: 30s
diff --git a/content/manuals/compose/how-tos/use-secrets.md b/content/manuals/compose/how-tos/use-secrets.md
index 63680e6ac352..5fb86f06d9bc 100644
--- a/content/manuals/compose/how-tos/use-secrets.md
+++ b/content/manuals/compose/how-tos/use-secrets.md
@@ -1,9 +1,9 @@
 ---
-title: How to use secrets in Docker Compose
+title: Manage secrets securely in Docker Compose
 linkTitle: Secrets in Compose
 weight: 60
-description: How to use secrets in Compose and their benefits
-keywords: secrets, compose, security, environment variables
+description: Learn how to securely manage runtime and build-time secrets in Docker Compose.
+keywords: secrets, compose, security, environment variables, docker secrets, secure Docker builds, sensitive data in containers
 tags: [Secrets]
 aliases:
 - /compose/use-secrets/
@@ -19,13 +19,17 @@ Environment variables are often available to all processes, and it can be diffic
 
 Secrets are mounted as a file in `/run/secrets/<secret_name>` inside the container.
 
+> [!NOTE]
+>
+> Secrets are supported on Linux containers only. Compose delivers each secret by bind-mounting a single file into the container, and Windows containers support bind-mounting directories only.
+
 Getting a secret into a container is a two-step process. First, define the secret using the [top-level secrets element in your Compose file](/reference/compose-file/secrets.md). Next, update your service definitions to reference the secrets they require with the [secrets attribute](/reference/compose-file/services.md#secrets). Compose grants access to secrets on a per-service basis.
 
 Unlike the other methods, this permits granular access control within a service container via standard filesystem permissions.
 
 ## Examples
 
-### Simple
+### Single-service secret injection
 
 In the following example, the frontend service is given access to the `my_secret` secret. In the container, `/run/secrets/my_secret` is set to the contents of the file `./my_secret.txt`.
 
@@ -40,7 +44,7 @@ secrets:
     file: ./my_secret.txt
 ```
 
-### Advanced
+### Multi-service secret sharing and password management
 
 ```yaml
 services:
@@ -84,7 +88,7 @@ In the advanced example above:
 
 - The `secrets` attribute under each service defines the secrets you want to inject into the specific container.
 - The top-level `secrets` section defines the variables `db_password` and `db_root_password` and provides the `file` that populates their values.
-- The deployment of each container means Docker creates a temporary filesystem mount under `/run/secrets/<secret_name>` with their specific values.
+- The deployment of each container means Docker creates a bind mount under `/run/secrets/<secret_name>` with their specific values.
 
 > [!NOTE]
 >
@@ -109,6 +113,7 @@ secrets:
 
 ## Resources
 
+- [Familiarize yourself with Compose's trust model](/manuals/compose/trust-model.md)
 - [Secrets top-level element](/reference/compose-file/secrets.md)
 - [Secrets attribute for services top-level element](/reference/compose-file/services.md#secrets)
 - [Build secrets](https://docs.docker.com/build/building/secrets/)
diff --git a/content/manuals/compose/images/quick-hello-world-1.png b/content/manuals/compose/images/quick-hello-world-1.png
deleted file mode 100644
index 9c0e99acfaf2..000000000000
Binary files a/content/manuals/compose/images/quick-hello-world-1.png and /dev/null differ
diff --git a/content/manuals/compose/images/quick-hello-world-2.png b/content/manuals/compose/images/quick-hello-world-2.png
deleted file mode 100644
index 65841c0b9cf3..000000000000
Binary files a/content/manuals/compose/images/quick-hello-world-2.png and /dev/null differ
diff --git a/content/manuals/compose/images/quick-hello-world-3.png b/content/manuals/compose/images/quick-hello-world-3.png
deleted file mode 100644
index ed500e020c34..000000000000
Binary files a/content/manuals/compose/images/quick-hello-world-3.png and /dev/null differ
diff --git a/content/manuals/compose/images/v1-versus-v2-versus-v5.png b/content/manuals/compose/images/v1-versus-v2-versus-v5.png
new file mode 100644
index 000000000000..4e4caecd56b4
Binary files /dev/null and b/content/manuals/compose/images/v1-versus-v2-versus-v5.png differ
diff --git a/content/manuals/compose/images/v1-versus-v2.png b/content/manuals/compose/images/v1-versus-v2.png
deleted file mode 100644
index 293d799525be..000000000000
Binary files a/content/manuals/compose/images/v1-versus-v2.png and /dev/null differ
diff --git a/content/manuals/compose/install/_index.md b/content/manuals/compose/install/_index.md
index 750c05b10d18..10c58ebecf94 100644
--- a/content/manuals/compose/install/_index.md
+++ b/content/manuals/compose/install/_index.md
@@ -1,24 +1,18 @@
 ---
 description: Learn how to install Docker Compose. Compose is available natively on
   Docker Desktop, as a Docker Engine plugin, and as a standalone tool.
-keywords: install docker compose, docker compose install, install docker compose ubuntu,
-  installing docker compose, docker compose download, docker compose not found, docker
-  compose windows, how to install docker compose
+keywords: install docker compose, docker compose plugin, install compose linux, install docker desktop, docker compose windows, standalone docker compose, docker compose not found
 title: Overview of installing Docker Compose
 linkTitle: Install
 weight: 20
 toc_max: 3
-aliases:
-- /compose/compose-desktop/
-- /compose/install/other/
-- /compose/install/compose-desktop/
 ---
 
 This page summarizes the different ways you can install Docker Compose, depending on your platform and needs.
 
 ## Installation scenarios 
 
-### Scenario one: Install Docker Desktop (Recommended)
+### Docker Desktop (Recommended)
 
 The easiest and recommended way to get Docker Compose is to install Docker Desktop. 
 
@@ -33,7 +27,7 @@ Docker Desktop is available for:
 > 
 > If you have already installed Docker Desktop, you can check which version of Compose you have by selecting **About Docker Desktop** from the Docker menu {{< inline-image src="../../desktop/images/whale-x.svg" alt="whale menu" >}}.
 
-### Scenario two: Install the Docker Compose plugin (Linux only)
+### Plugin (Linux only)
 
 > [!IMPORTANT]
 >
@@ -43,7 +37,7 @@ If you already have Docker Engine and Docker CLI installed, you can install the
 - [Using Docker's repository](linux.md#install-using-the-repository)
 - [Downloading and installing manually](linux.md#install-the-plugin-manually)
 
-### Scenario three: Install the Docker Compose standalone (Legacy)
+### Standalone (Legacy)
 
 > [!WARNING]
 >
diff --git a/content/manuals/compose/install/linux.md b/content/manuals/compose/install/linux.md
index d1b47fc2d139..ccc69653784c 100644
--- a/content/manuals/compose/install/linux.md
+++ b/content/manuals/compose/install/linux.md
@@ -1,16 +1,10 @@
 ---
-description: Download and install Docker Compose on Linux with this step-by-step handbook.
-  This plugin can be installed manually or by using a repository.
-keywords: install docker compose linux, docker compose linux, docker compose plugin,
-  docker-compose-plugin, linux install docker compose, install docker-compose linux,
-  linux install docker-compose, linux docker compose, docker compose v2 linux, install
-  docker compose on linux
+description: Step-by-step instructions for installing the Docker Compose plugin on Linux using a package repository or manual method.
+keywords: install docker compose linux, docker compose plugin, docker-compose-plugin linux, docker compose v2, docker compose manual install, linux docker compose
 toc_max: 3
 title: Install the Docker Compose plugin
 linkTitle: Plugin
 aliases:
-- /compose/compose-plugin/
-- /compose/compose-linux/
 - /compose/install/compose-plugin/
 weight: 10
 ---
@@ -34,8 +28,7 @@ To install the Docker Compose plugin on Linux, you can either:
     [Debian](/manuals/engine/install/debian.md#install-using-the-repository) |
     [Raspberry Pi OS](/manuals/engine/install/raspberry-pi-os.md#install-using-the-repository) |
     [Fedora](/manuals/engine/install/fedora.md#set-up-the-repository) |
-    [RHEL](/manuals/engine/install/rhel.md#set-up-the-repository) |
-    [SLES](/manuals/engine/install/sles.md#set-up-the-repository).
+    [RHEL](/manuals/engine/install/rhel.md#set-up-the-repository).
 
 2. Update the package index, and install the latest version of Docker Compose:
 
@@ -77,9 +70,9 @@ To update the Docker Compose plugin, run the following commands:
 
 ## Install the plugin manually
 
-> [!IMPORTANT]
+> [!WARNING]
 >
-> This option requires you to manage upgrades manually. It is recommended that you set up Docker's repository for easier maintenance.
+> Manual installations don’t auto-update. For ease of maintenance, use the Docker repository method.
 
 1.  To download and install the Docker Compose CLI plugin, run:
 
@@ -113,4 +106,8 @@ To update the Docker Compose plugin, run the following commands:
     ```console
     $ docker compose version
     ```
-    
\ No newline at end of file
+
+## What's next?
+
+- [Understand how Compose works](/manuals/compose/intro/compose-application-model.md)
+- [Try the Quickstart guide](/manuals/compose/gettingstarted.md)
diff --git a/content/manuals/compose/install/standalone.md b/content/manuals/compose/install/standalone.md
index d878c2daf745..add1a1005704 100644
--- a/content/manuals/compose/install/standalone.md
+++ b/content/manuals/compose/install/standalone.md
@@ -1,18 +1,26 @@
 ---
-title: Install the Docker Compose standalone
-linkTitle: Standalone
-description: How to install Docker Compose - Other Scenarios
-keywords: compose, orchestration, install, installation, docker, documentation
+title: Install the Docker Compose standalone (Legacy)
+linkTitle: Standalone (Legacy)
+description: Instructions for installing the legacy Docker Compose standalone tool on Linux and Windows Server
+keywords: install docker-compose, standalone docker compose, docker-compose windows server, install docker compose linux, legacy compose install
 toc_max: 3
 weight: 20
 ---
 
+> [!WARNING]
+>
+> This install scenario is not recommended and is only supported for backward compatibility purposes.
+> Use [Docker Desktop](/manuals/desktop/_index.md) or the
+> [Docker Compose plugin](/manuals/compose/install/linux.md) instead.
+> Use the standalone binary only if you cannot use either of these options.
+
 This page contains instructions on how to install Docker Compose standalone on Linux or Windows Server, from the command line.
 
 > [!WARNING]
 >
 > The Docker Compose standalone uses the `-compose` syntax instead of the current standard syntax `compose`.  
 > For example, you must type `docker-compose up` when using Docker Compose standalone, instead of `docker compose up`.
+> Use it only for backward compatibility.
 
 ## On Linux
 
@@ -35,6 +43,7 @@ This page contains instructions on how to install Docker Compose standalone on L
 > If the command `docker-compose` fails after installation, check your path.
 > You can also create a symbolic link to `/usr/bin` or any other directory in your path.
 > For example:
+>
 > ```console
 > $ sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
 > ```
@@ -47,14 +56,14 @@ on Microsoft Windows Server](/manuals/engine/install/binaries.md#install-server-
 1.  Run PowerShell as an administrator.
     In order to proceed with the installation, select **Yes** when asked if you want this app to make changes to your device.
 
-2.  Optional. Ensure TLS1.2 is enabled. 
+2.  Optional. Ensure TLS1.2 is enabled.
     GitHub requires TLS1.2 for secure connections. If you’re using an older version of Windows Server, for example 2016, or suspect that TLS1.2 is not enabled, run the following command in PowerShell:
 
     ```powershell
     [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
     ```
 
-3. Download the latest release of Docker Compose ({{% param "compose_version" %}}). Run the following command:
+3.  Download the latest release of Docker Compose ({{% param "compose_version" %}}). Run the following command:
 
     ```powershell
      Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/{{% param "compose_version" %}}/docker-compose-windows-x86_64.exe" -Destination $Env:ProgramFiles\Docker\docker-compose.exe
@@ -65,8 +74,8 @@ on Microsoft Windows Server](/manuals/engine/install/binaries.md#install-server-
     > [!NOTE]
     >
     > On Windows Server 2019 you can add the Compose executable to `$Env:ProgramFiles\Docker`.
-     Because this directory is registered in the system `PATH`, you can run the `docker-compose --version` 
-     command on the subsequent step with no additional configuration.
+    > Because this directory is registered in the system `PATH`, you can run the `docker-compose --version`
+    > command on the subsequent step with no additional configuration.
 
 4.  Test the installation.
 
@@ -74,3 +83,8 @@ on Microsoft Windows Server](/manuals/engine/install/binaries.md#install-server-
     $ docker-compose.exe version
     Docker Compose version {{% param "compose_version" %}}
     ```
+
+## What's next?
+
+- [Understand how Compose works](/manuals/compose/intro/compose-application-model.md)
+- [Try the Quickstart guide](/manuals/compose/gettingstarted.md)
diff --git a/content/manuals/compose/install/uninstall.md b/content/manuals/compose/install/uninstall.md
index 16585ab8b225..714389deda04 100644
--- a/content/manuals/compose/install/uninstall.md
+++ b/content/manuals/compose/install/uninstall.md
@@ -2,6 +2,7 @@
 description: How to uninstall Docker Compose
 keywords: compose, orchestration, uninstall, uninstallation, docker, documentation
 title: Uninstall Docker Compose
+linkTitle: Uninstall 
 ---
 
 How you uninstall Docker Compose depends on how it was installed. This guide covers uninstallation instructions for:
@@ -13,7 +14,7 @@ How you uninstall Docker Compose depends on how it was installed. This guide cov
 
 If you want to uninstall Docker Compose and you have installed Docker Desktop, see [Uninstall Docker Desktop](/manuals/desktop/uninstall.md).
 
-> [!NOTE]
+> [!WARNING]
 >
 > Unless you have other Docker instances installed on that specific environment, uninstalling Docker Desktop removes all Docker components, including Docker Engine, Docker CLI, and Docker Compose.
 
diff --git a/content/manuals/compose/intro/compose-application-model.md b/content/manuals/compose/intro/compose-application-model.md
index 127e99501a9d..962a6392482c 100644
--- a/content/manuals/compose/intro/compose-application-model.md
+++ b/content/manuals/compose/intro/compose-application-model.md
@@ -1,11 +1,10 @@
 ---
 title: How Compose works
 weight: 10
-description: Understand how Compose works and the Compose application model with an illustrative example 
-keywords: compose, docker compose, compose specification, compose model 
+description: Learn how Docker Compose works, from the application model to Compose files and CLI, whilst following a detailed example.
+keywords: docker compose, compose.yaml, docker compose model, compose cli, multi-container application, compose example 
 aliases:
 - /compose/compose-file/02-model/
-- /compose/compose-yaml-file/
 - /compose/compose-application-model/
 ---
 
@@ -21,7 +20,7 @@ Services communicate with each other through [networks](/reference/compose-file/
 
 Services store and share persistent data into [volumes](/reference/compose-file/volumes.md). The Specification describes such a persistent data as a high-level filesystem mount with global options.
 
-Some services require configuration data that is dependent on the runtime or platform. For this, the Specification defines a dedicated [configs](/reference/compose-file/configs.md) concept. From a service container point of view, configs are comparable to volumes, in that they are files mounted into the container. But the actual definition involves distinct platform resources and services, which are abstracted by this type.
+Some services require configuration data that is dependent on the runtime or platform. For this, the Specification defines a dedicated [configs](/reference/compose-file/configs.md) concept. From inside the container, configs behave like volumes—they’re mounted as files. However, configs are defined differently at the platform level.
 
 A [secret](/reference/compose-file/secrets.md) is a specific flavor of configuration data for sensitive data that should not be exposed without security considerations. Secrets are made available to services as files mounted into their containers, but the platform-specific resources to provide sensitive data are specific enough to deserve a distinct concept and definition within the Compose Specification.
 
@@ -47,7 +46,7 @@ You can use [fragments](/reference/compose-file/fragments.md) and [extensions](/
 
 Multiple Compose files can be [merged](/reference/compose-file/merge.md) together to define the application model. The combination of YAML files is implemented by appending or overriding YAML elements based on the Compose file order you set. 
 Simple attributes and maps get overridden by the highest order Compose file, lists get merged by appending. Relative
-paths are resolved based on the first Compose file's parent folder, whenever complimentary files being
+paths are resolved based on the first Compose file's parent folder, whenever complementary files being
 merged are hosted in other folders. As some Compose file elements can both be expressed as single strings or complex objects, merges apply to
 the expanded form. For more information, see [Working with multiple Compose files](/manuals/compose/how-tos/multiple-compose-files/_index.md).
 
@@ -55,7 +54,9 @@ If you want to reuse other Compose files, or factor out parts of your applicatio
 
 ## CLI
 
-The Docker CLI lets you interact with your Docker Compose applications through the `docker compose` command, and its subcommands. Using the CLI, you can manage the lifecycle of your multi-container applications defined in the `compose.yaml` file. The CLI commands enable you to start, stop, and configure your applications effortlessly.
+The Docker CLI lets you interact with your Docker Compose applications through the `docker compose` command and its subcommands. If you're using Docker Desktop, the Docker Compose CLI is included by default.
+
+Using the CLI, you can manage the lifecycle of your multi-container applications defined in the `compose.yaml` file. The CLI commands enable you to start, stop, and configure your applications effortlessly.
 
 ### Key commands 
 
@@ -83,7 +84,7 @@ To list all the services along with their current status:
 $ docker compose ps
 ```
 
-For a full list of all the Compose CLI commands, see the [reference documentation](/reference/cli/docker/compose/_index.md).
+For a full list of all the Compose CLI commands, see the [reference documentation](/reference/cli/docker/compose/).
 
 ## Illustrative example
 
@@ -101,11 +102,11 @@ Both services communicate with each other on an isolated back-tier network, whil
 
 The example application is composed of the following parts:
 
-- 2 services, backed by Docker images: `webapp` and `database`
-- 1 secret (HTTPS certificate), injected into the frontend
-- 1 configuration (HTTP), injected into the frontend
-- 1 persistent volume, attached to the backend
-- 2 networks
+- Two services, backed by Docker images: `webapp` and `database`
+- One secret (HTTPS certificate), injected into the frontend
+- One configuration (HTTP), injected into the frontend
+- One persistent volume, attached to the backend
+- Two networks
 
 ```yml
 services:
@@ -162,6 +163,6 @@ example-backend-1   example/database     "docker-entrypoint.s…"   backend
 
 ## What's next 
 
-- [Quickstart](/manuals/compose/gettingstarted.md)
-- [Explore some sample applications](/manuals/compose/support-and-feedback/samples-for-compose.md)
+- [Try the Quickstart guide](/manuals/compose/gettingstarted.md)
+- [Explore some sample applications](https://github.com/docker/awesome-compose)
 - [Familiarize yourself with the Compose Specification](/reference/compose-file/_index.md)
diff --git a/content/manuals/compose/intro/features-uses.md b/content/manuals/compose/intro/features-uses.md
index 1545bd81407b..0860ff42962e 100644
--- a/content/manuals/compose/intro/features-uses.md
+++ b/content/manuals/compose/intro/features-uses.md
@@ -1,26 +1,24 @@
 ---
-description: Key benefits and use cases of Docker Compose
-keywords: documentation, docs, docker, compose, orchestration, containers, uses,  benefits
+description: Discover the benefits and typical use cases of Docker Compose for containerized application development and deployment
+keywords: docker compose, compose use cases, compose benefits, container orchestration, development environments, testing containers, yaml file
 title: Why use Compose?
 weight: 20
-aliases: 
-- /compose/features-uses/
+aliases:
+  - /compose/features-uses/
 ---
 
 ## Key benefits of Docker Compose
 
 Using Docker Compose offers several benefits that streamline the development, deployment, and management of containerized applications:
 
-- Simplified control: Docker Compose allows you to define and manage multi-container applications in a single YAML file. This simplifies the complex task of orchestrating and coordinating various services, making it easier to manage and replicate your application environment.
+- Simplified control: Define and manage multi-container apps in one YAML file, streamlining orchestration and replication.
 
-- Efficient collaboration: Docker Compose configuration files are easy to share, facilitating collaboration among developers, operations teams, and other stakeholders. This collaborative approach leads to smoother workflows, faster issue resolution, and increased overall efficiency.
+- Efficient collaboration: Shareable YAML files support smooth collaboration between developers and operations, improving workflows and issue resolution, leading to increased overall efficiency.
 
-- Rapid application development: Compose caches the configuration used to create a container. When you restart a service that has not changed, Compose re-uses the existing containers. Re-using containers means that you can make changes to your environment very quickly.
+- Rapid application development: Compose caches the configuration used to create a container. When you restart a service that has not changed, Compose reuses the existing containers. Reusing containers means that you can make changes to your environment quickly.
 
 - Portability across environments: Compose supports variables in the Compose file. You can use these variables to customize your composition for different environments, or different users.
 
-- Extensive community and support: Docker Compose benefits from a vibrant and active community, which means abundant resources, tutorials, and support. This community-driven ecosystem contributes to the continuous improvement of Docker Compose and helps users troubleshoot issues effectively.
-
 ## Common use cases of Docker Compose
 
 Compose can be used in many different ways. Some common use cases are outlined
@@ -57,8 +55,9 @@ $ docker compose down
 
 ### Single host deployments
 
-Compose has traditionally been focused on development and testing workflows,
-but with each release we're making progress on more production-oriented features.
+Compose supports production deployments on single hosts. You can use
+Compose to deploy applications to remote Docker hosts and manage
+production-specific configurations.
 
 For details on using production-oriented features, see
 [Compose in production](/manuals/compose/how-tos/production.md).
@@ -67,4 +66,4 @@ For details on using production-oriented features, see
 
 - [Learn about the history of Compose](history.md)
 - [Understand how Compose works](compose-application-model.md)
-- [Quickstart](../gettingstarted.md)
+- [Try the Quickstart guide](../gettingstarted.md)
diff --git a/content/manuals/compose/intro/history.md b/content/manuals/compose/intro/history.md
index 862cb9eb12b3..f5aab1d24f41 100644
--- a/content/manuals/compose/intro/history.md
+++ b/content/manuals/compose/intro/history.md
@@ -1,7 +1,7 @@
 ---
 title: History and development of Docker Compose
 linkTitle: History and development
-description: History of Compose v1 and Compose YAML schema versioning
+description: Explore the evolution of Docker Compose from v1 to v5, including CLI changes, YAML versioning, and the Compose Specification.
 keywords: compose, compose yaml, swarm, migration, compatibility, docker compose vs docker-compose
 weight: 30
 aliases:
@@ -10,41 +10,48 @@ aliases:
 
 This page provides:
  - A brief history of the development of the Docker Compose CLI
- - A clear explanation of the major versions and file formats that make up Compose v1 and Compose v2
- - The main differences between Compose V1 and Compose v2 
+ - A clear explanation of the major versions and file formats that make up Compose v1, v2, and v5
+ - The main differences between Compose v1, v2, and v5
 
 ## Introduction
 
-![Image showing the main differences between Compose v1 and Compose v2](../images/v1-versus-v2.png)
+![Image showing the main differences between Compose v1, Compose v2, and Compose v5](../images/v1-versus-v2-versus-v5.png)
 
-The previous image shows that the currently supported version of the Docker Compose CLI is Compose v2 which is defined by the [Compose Specification](/reference/compose-file/_index.md).
+The diagram above highlights the key differences between Docker Compose v1, v2, and v5. Today, the supported Docker Compose CLI versions are Compose v2 and Compose v5, both of which are defined by the [Compose Specification](/reference/compose-file/_index.md).
 
-It also provides a quick snapshot of the differences in file formats, command-line syntax, and top-level elements. This is covered in more detail in the following sections.
+The diagram provides a high-level comparison of file formats, command-line syntax, and supported top-level elements. This is covered in more detail in the following sections.
 
 ### Docker Compose CLI versioning
 
-Version one of the Docker Compose command-line binary was first released in 2014. It was written in Python, and is invoked with `docker-compose`.
-Typically, Compose V1 projects include a top-level `version` element in the `compose.yaml` file, with values ranging from `2.0` to `3.8`, which refer to the specific [file formats](#compose-file-format-versioning).
+Compose v1 was first released in 2014. It was written in Python and invoked with `docker-compose`.
+Typically, Compose v1 projects include a top-level `version` element in the `compose.yaml` file, with values ranging from `2.0` to `3.8`, which refer to the specific [file formats](#compose-file-format-versioning).
 
-Version two of the Docker Compose command-line binary was announced in 2020, is written in Go, and is invoked with `docker compose`.
-Compose v2 ignores the `version` top-level element in the `compose.yaml` file.
+Compose v2, announced in 2020, is written in Go and is invoked with `docker compose`.
+Unlike v1, Compose v2 ignores the `version` top-level element in the `compose.yaml` file and relies entirely on the Compose Specification to interpret the file.
+
+Compose v5, released in 2025, is functionally identical to Compose v2. Its primary distinction is the introduction of an official [Go SDK](/manuals/compose/compose-sdk.md). This SDK provides a comprehensive API that lets you integrate Compose functionality directly into your applications, allowing you to load, validate, and manage multi-container environments without relying on the Compose CLI. To avoid confusion with the legacy Compose file formats labeled “v2” and “v3,” the versioning was advanced directly to v5.
 
 ### Compose file format versioning
 
 The Docker Compose CLIs are defined by specific file formats. 
 
-Three major versions of the Compose file format for Compose V1 were released:
+Three major versions of the Compose file format for Compose v1 were released:
 - Compose file format 1 with Compose 1.0.0 in 2014
 - Compose file format 2.x with Compose 1.6.0 in 2016
 - Compose file format 3.x with Compose 1.10.0 in 2017
 
 Compose file format 1 is substantially different to all the following formats as it lacks a top-level `services` key.
-Its usage is historical and files written in this format don't run with Compose v2.
+Its usage is historical and files written in this format don't run with Compose v2 or v5.
 
 Compose file format 2.x and 3.x are very similar to each other, but the latter introduced many new options targeted at Swarm deployments.
 
 To address confusion around Compose CLI versioning, Compose file format versioning, and feature parity depending on whether Swarm mode was in use, file format 2.x and 3.x were merged into the [Compose Specification](/reference/compose-file/_index.md). 
 
-Compose v2 uses the Compose Specification for project definition. Unlike the prior file formats, the Compose Specification is rolling and makes the `version` top-level element optional. Compose v2 also makes use of optional specifications - [Deploy](/reference/compose-file/deploy.md), [Develop](/reference/compose-file/develop.md), and [Build](/reference/compose-file/build.md).
+Compose v2 and v5 uses the Compose Specification for project definition. Unlike the prior file formats, the Compose Specification is rolling and makes the `version` top-level element optional. Compose v2 and v5 also makes use of optional specifications - [Deploy](/reference/compose-file/deploy.md), [Develop](/reference/compose-file/develop.md), and [Build](/reference/compose-file/build.md).
+
+To make migration easier, Compose v2 and v5 has backwards compatibility for certain elements that have been deprecated or changed between Compose file format 2.x/3.x and the Compose Specification.
+
+## What's next?
 
-To make [migration](/manuals/compose/releases/migrate.md) easier, Compose v2 has backwards compatibility for certain elements that have been deprecated or changed between Compose file format 2.x/3.x and the Compose Specification.
+- [How Compose works](compose-application-model.md)
+- [Compose Specification reference](/reference/compose-file/_index.md)
diff --git a/content/manuals/compose/release-notes.md b/content/manuals/compose/release-notes.md
new file mode 100644
index 000000000000..c6055dbd2f0f
--- /dev/null
+++ b/content/manuals/compose/release-notes.md
@@ -0,0 +1,7 @@
+---
+title: Release notes
+weight: 90
+params:
+  sidebar:
+    goto: "https://github.com/docker/compose/releases"
+---
\ No newline at end of file
diff --git a/content/manuals/compose/releases/_index.md b/content/manuals/compose/releases/_index.md
deleted file mode 100644
index 1d44967fb9a2..000000000000
--- a/content/manuals/compose/releases/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-build:
-  render: never
-title: Releases
-weight: 70
----
\ No newline at end of file
diff --git a/content/manuals/compose/releases/migrate.md b/content/manuals/compose/releases/migrate.md
deleted file mode 100644
index 1fc0ef126697..000000000000
--- a/content/manuals/compose/releases/migrate.md
+++ /dev/null
@@ -1,134 +0,0 @@
----
-title: Migrate to Compose v2
-weight: 20
-description: How to migrate from Compose v1 to v2
-keywords: compose, upgrade, migration, v1, v2, docker compose vs docker-compose
-aliases:
-- /compose/compose-v2/
-- /compose/cli-command-compatibility/
-- /compose/migrate/
----
-
-From July 2023, Compose v1 stopped receiving updates. It’s also no longer available in new releases of Docker Desktop.
-
-Compose v2, which was first released in 2020, is included with all currently supported versions of Docker Desktop. It offers an improved CLI experience, improved build performance with BuildKit, and continued new-feature development.
-
-## How do I switch to Compose v2?
-
-The easiest and recommended way is to make sure you have the latest version of [Docker Desktop](/manuals/desktop/release-notes.md), which bundles the Docker Engine and Docker CLI platform including Compose v2.
-
-With Docker Desktop, Compose v2 is always accessible as `docker compose`.
-
-For manual installs on Linux, you can get Compose v2 by either:
-- [Using Docker's repository](/manuals/compose/install/linux.md#install-using-the-repository) (recommended)
-- [Downloading and installing manually](/manuals/compose/install/linux.md#install-the-plugin-manually)
-
-## What are the differences between Compose v1 and Compose v2?
-
-### `docker-compose` vs `docker compose`
-
-Unlike Compose v1, Compose v2 integrates into the Docker CLI platform and the recommended command-line syntax is `docker compose`.
-
-The Docker CLI platform provides a consistent and predictable set of options and flags, such as the `DOCKER_HOST` environment variable or the `--context` command-line flag.
-
-This change lets you use all of the shared flags on the root `docker` command.
-For example, `docker --log-level=debug --tls compose up` enables debug logging from the Docker Engine as well as ensuring that TLS is used for the connection.
-
-> [!TIP]
->
-> Update scripts to use Compose v2 by replacing the hyphen (`-`) with a space, using `docker compose` instead of `docker-compose`.
-
-### Service container names
-
-Compose generates container names based on the project name, service name, and scale/replica count.
-
-In Compose v1, an underscore (`_`) was used as the word separator.
-In Compose v2, a hyphen (`-`) is used as the word separator.
-
-Underscores aren't valid characters in DNS hostnames.
-By using a hyphen instead, Compose v2 ensures service containers can be accessed over the network via consistent, predictable hostnames.
- 
-For example, running the Compose command `-p myproject up --scale=1 svc` results in a container named `myproject_svc_1` with Compose v1 and a container named `myproject-svc-1` with Compose v2.
-
-> [!TIP]
->
-> In Compose v2, the global `--compatibility` flag or `COMPOSE_COMPATIBILITY` environment variable preserves the Compose v1 behavior to use underscores (`_`) as the word separator.
-As this option must be specified for every Compose v2 command run, it's recommended that you only use this as a temporary measure while transitioning to Compose v2.
-
-### Command-line flags and subcommands
-
-Compose v2 supports almost all Compose V1 flags and subcommands, so in most cases, it can be used as a drop-in replacement in scripts.
-
-#### Unsupported in v2
-
-The following were deprecated in Compose v1 and aren't supported in Compose v2:
-* `docker-compose scale`. Use `docker compose up --scale` instead.
-* `docker-compose rm --all`
-
-#### Different in v2
-
-The following behave differently between Compose v1 and v2:
-
-|                         | Compose v1                                                       | Compose v2                                                                    |
-|-------------------------|------------------------------------------------------------------|-------------------------------------------------------------------------------|
-| `--compatibility`       | Deprecated. Migrates YAML fields based on legacy schema version. | Uses `_` as word separator for container names instead of `-` to match v1.    |
-| `ps --filter KEY-VALUE` | Undocumented. Allows filtering by arbitrary service properties.  | Only allows filtering by specific properties, e.g. `--filter=status=running`. |
-
-### Environment variables
-
-Environment variable behavior in Compose v1 wasn't formally documented and behaved inconsistently in some edge cases.
-
-For Compose v2, the [Environment variables](/manuals/compose/how-tos/environment-variables/_index.md) section covers both [precedence](/manuals/compose/how-tos/environment-variables/envvars-precedence.md) as well as [`.env` file interpolation](/manuals/compose/how-tos/environment-variables/variable-interpolation.md) and includes many examples covering tricky situations such as escaping nested quotes.
-
-Check if:
-- Your project uses multiple levels of environment variable overrides, for example `.env` file and `--env` CLI flags.
-- Any `.env` file values have escape sequences or nested quotes.
-- Any `.env` file values contain literal `$` signs in them. This is common with PHP projects.
-- Any variable values use advanced expansion syntax, for example `${VAR:?error}`.
-
-> [!TIP]
->
-> Run `docker compose config` on the project to preview the configuration after Compose v2 has performed interpolation to
-verify that values appear as expected.
->
-> Maintaining backwards compatibility with Compose v1 is typically achievable by ensuring that literal values (no
-interpolation) are single-quoted and values that should have interpolation applied are double-quoted.
-
-## What does this mean for my projects that use Compose v1?
-
-For most projects, switching to Compose v2 requires no changes to the Compose YAML or your development workflow.
-
-It's recommended that you adapt to the new preferred way of running Compose v2, which is to use `docker compose` instead of `docker-compose`.
-This provides additional flexibility and removes the requirement for a `docker-compose` compatibility alias. 
-
-However, Docker Desktop continues to support a `docker-compose` alias to redirect commands to `docker compose` for convenience and improved compatibility with third-party tools and scripts.
-
-## Is there anything else I need to know before I switch?
-
-### Migrating running projects
-
-In both v1 and v2, running up on a Compose project recreates service containers as needed. It compares the actual state in the Docker Engine to the resolved project configuration, which includes the Compose YAML, environment variables, and command-line flags.
-
-Because Compose v1 and v2 [name service containers differently](#service-container-names), running `up` using v2 the first time on a project with running services originally launched by v1, results in service containers being recreated with updated names.
-
-Note that even if `--compatibility` flag is used to preserve the v1 naming style, Compose still needs to recreate service containers originally launched by v1 the first time `up` is run by v2 to migrate the internal state.
-
-### Using Compose v2 with Docker-in-Docker
-
-Compose v2 is now included in the [Docker official image on Docker Hub](https://hub.docker.com/_/docker).
-
-Additionally, a new [docker/compose-bin image on Docker Hub](https://hub.docker.com/r/docker/compose-bin) packages the latest version of Compose v2 for use in multi-stage builds.
-
-## Can I still use Compose v1 if I want to?
-
-Yes. You can still download and install Compose v1 packages, but you won't get support from Docker if anything breaks.
-
->[!WARNING]
->
-> The final Compose v1 release, version 1.29.2, was May 10, 2021. These packages haven't received any security updates since then. Use at your own risk. 
-
-## Additional Resources
-
-- [docker-compose v1 on PyPI](https://pypi.org/project/docker-compose/1.29.2/)
-- [docker/compose v1 on Docker Hub](https://hub.docker.com/r/docker/compose)
-- [docker-compose v1 source on GitHub](https://github.com/docker/compose/releases/tag/1.29.2)
diff --git a/content/manuals/compose/releases/release-notes.md b/content/manuals/compose/releases/release-notes.md
deleted file mode 100644
index b90bed1afe75..000000000000
--- a/content/manuals/compose/releases/release-notes.md
+++ /dev/null
@@ -1,4314 +0,0 @@
----
-title: Docker Compose release notes
-linkTitle: Release notes
-weight: 10
-description: Learn about the new features, bug fixes, and breaking changes for the newest Docker Compose release
-keywords: release notes, compose
-tags: [Release notes]
-toc_max: 2
-aliases:
-- /release-notes/docker-compose/
-- /compose/release-notes/
----
-
-For more detailed information, see the [release notes in the Compose repo](https://github.com/docker/compose/releases/).
-
-## 2.35.1
-
-{{< release-date date="2025-04-17" >}}
-
-### Bug fixes and enhancements
-
-- Fixed an issue with bind mounts
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.6.0
-- Dependencies upgrade: bump docker engine and cli to v28.0.4
-- Dependencies upgrade: bump buildx to v0.22.0
-
-## 2.35.0
-
-{{< release-date date="2025-04-10" >}}
-
-### Bug fixes and enhancements
-
-- Added support for [Docker Model Runner](/manuals/ai/model-runner.md) to easily integrate AI models into your Compose applications
-- Added `build --print` command to help debug complex build configurations by showing the equivalent bake file
-- Added `volume.type=image` to provide more flexible volume management for container images
-- Added `--quiet` options to the `run` command for cleaner output when running containers
-- Added `config --no-env-resolution` option to view raw configuration without environment variable substitution
-- Fixed behavior of `depends_on` to prevent unnecessary container recreation when dependencies change
-- Fixed support for secrets defined by environment variables when using `include`
-- Fixed volume mount handling to ensure bind mounts work correctly in all scenarios
-
-### Update
-
-- Dependencies upgrade: bump docker engine and cli to v28.1.0
-- Dependencies upgrade: bump buildx to v0.23.0
-- Dependencies upgrade: bump buildkit to v0.21.0
-
-## 2.34.0
-
-{{< release-date date="2025-03-14" >}}
-
-### Bug fixes and enhancements
-
-- Added support of refresh `pull_policy` values `daily`, `weekly` and `every_<duration>`
-- Introduced `include` attribut to `watch` definition to match file patterns
-- Introduced `--env-from-file` in flag for the `docker compose run` command
-- Promoted `publish` as a regular command of Compose
-- Fixed a bug by loading `env_file` after services have been selected
-
-### Update
-
-- Dependencies upgrade: bump docker engine and cli to v28.0.1
-- Dependencies upgrade: bump buildkit to v0.17.1
-- Dependencies upgrade: Bump compose-go v2.4.9
-- Dependencies upgrade: Bump buildx v0.21.2
-
-## 2.33.1
-
-{{< release-date date="2025-02-21" >}}
-
-### Bug fixes and enhancements
-
-- Added support for `gw_priority`, `enable_ipv4` (requires Docker v28.0)
-- Fixed an issue with the navigation menu
-- Improved error message when using non-file secret/config with read-only service
-
-### Update
-
-- Dependencies upgrade: bump docker engine and cli to v28.0.0
-
-## 2.33.0
-
-{{< release-date date="2025-02-13" >}}
-
-### Bug fixes and enhancements
-
-- Introduced a hint to promote the use of [Bake](/build/bake/)
-- Introduced support for the `additional_context` attribute referencing another service
-- Added support for `BUILDKIT_PROGRESS`
-- Compose now warns you when a published Compose application includes environment variables
-- Added a `--with-env` flag to publish a Compose application with environment variables
-- Updated `ls --quiet` help description
-- Fixed multiple issues delegating build to Bake
-- Updated help in `stats` command
-- Fixed support for "builtin" seccomp profile
-- Fixed support for `watch` with multiple services
-- Removed exit code per error type used by legacy metrics system
-- Fixed test coverage for `compatibility`
-- Removed raw os.Args sent to OpenTelemetry
-- Enabled copyloopvar linter
-- Fixed provenance for binaries and generate SBOM
-- Main branch for docs upstream validation is now used
-- Added codeowners file
-- Added Docker Engine v28.x to the test-matrix
-
-### Update
-
-- Dependencies upgrade: Bump compose-go v2.4.8
-- Dependencies upgrade: Bump buildx v0.20.1
-- Dependencies upgrade: Bump docker to v27.5.1
-- Dependencies upgrade: Bump golangci-lint to v1.63.4
-- Dependencies upgrade: Bump golang.org/x/sys from 0.28.0 to 0.30.0
-- Dependencies upgrade: Bump github.com/moby/term v0.5.2
-- Dependencies upgrade: Bump github.com/otiai10/copy from 1.14.0 to 1.14.1
-- Dependencies upgrade: Bump github.com/jonboulle/clockwork from 0.4.0 to 0.5.0
-- Dependencies upgrade: Bump github.com/spf13/pflag from 1.0.5 to 1.0.6
-- Dependencies upgrade: Bump golang.org/x/sync from 0.10.0 to 0.11.0
-- Dependencies upgrade: Bump gotest.tools/v3 from 3.5.1 to 3.5.2
-
-## 2.32.4
-
-{{< release-date date="2025-01-16" >}}
-
-### Bug fixes and enhancements
-
-- Fixed an issue where the Compose version did not display properly when using `docker compose version`
-
-## 2.32.3
-
-{{< release-date date="2025-01-13" >}}
-
-> [!NOTE]
->
-> Binaries from the Compose GitHub repository may not display the version number properly. If you rely on `docker compose version`
-> in your development or CI processes, upgrade to Compose version 2.32.4.
-
-### Bug fixes and enhancements
-
-- Fixed an issue where Compose would override a service-level MAC address with the main network MAC address
-- Fixed a log rendering issue during concurrent builds
-
-## 2.32.2
-
-{{< release-date date="2025-01-07" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.4.7
-- Dependencies upgrade: bump golang to v1.22.10
-
-### Bug fixes and enhancements
-
-- Added `--pull` flag to the `docker compose run` command
-- Fixed a bug which meant the `restart` action of `watch` mode didn't monitor bind mounts
-- Fixed an issue recreating containers when using anonymous volumes
-
-## 2.32.1
-
-{{< release-date date="2024-12-16" >}}
-
-### Bug fixes and enhancements
-
-- Fixed a bug recreating containers when not needed
-
-## 2.32.0
-
-{{< release-date date="2024-12-13" >}}
-
-### Update
-
-- Dependencies upgrade: bump docker + buildx to latest release
-- Dependencies upgrade: bump otel dependencies to v1.28.0 and v0.53.0
-- Dependencies upgrade: bump golang.org/x/sys 0.28.0
-- Dependencies upgrade: bump golang.org/x/crypto to 0.31.0
-- Dependencies upgrade: bump google.golang.org/grpc to 1.68.1
-- Dependencies upgrade: bump golang.org/x/sync 0.10.0
-- Dependencies upgrade: bump xx to v1.6.1
-
-### Bug fixes and enhancements
-
-- Improved support when building with [Bake](/manuals/build/bake.md)
-- Added `restart` and `sync+exec` watch actions
-- Compose now recreates containers when the volume or network configuration changes
-- Fixed support for `mac_address`
-- Fixed `pull --quiet` to only hide progress, not global status
-- Fixed an issue where only the `rebuild` watch action now requires a build declaration
-- Compose now logs `watch` configuration error when enabled through the Compose menu
-
-
-## 2.31.0
-
-{{< release-date date="2024-11-28" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.4.5
-- Dependencies upgrade: bump docker engine and cli to v27.4.0-rc.2
-- Dependencies upgrade: bump buildx to v0.18.0
-- Dependencies upgrade: bump buildkit to v0.17.1
-
-### Bug fixes and enhancements
-
-- Added the ability to use Docker Buildx Bake to build Docker Compose services
-- Added `commit` command to create new images from running containers
-- Fixed an issue where network changes were not detected
-- Fixed an issue where containers stopped sequentially which slowed down the restart process
-
-
-## 2.30.3
-
-{{< release-date date="2024-11-07" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.4.4
-
-### Bug fixes and enhancements
-
-- Fixed an issue re-starting services that should not when using `--watch`
-- Improve the fix of using same YAML anchor multiple times in a Compose file
-
-
-## 2.30.2
-
-{{< release-date date="2024-11-05" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.4.3
-
-### Bug fixes and enhancements
-
-- Fixed an issue re-creating services when updating its profiles
-- Fixed a regression when using the same YAML anchor multiple times in a Compose file
-
-## 2.30.1
-
-{{< release-date date="2024-10-30" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.4.2
-
-### Bug fixes and enhancements
-
-- Fixed a regression when using stdin as input for `-f` flag
-- Fixed a regression when using the same YAML anchor multiple times in a Compose file
-
-## 2.30.0
-
-{{< release-date date="2024-10-29" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.4.1
-- Dependencies upgrade: bump docker engine and cli to v27.3.1
-
-### Bug fixes and enhancements
-
-- Introduction of service hooks support.
-- Addition of alpha `generate` command.
-- Addition of `export` command.
-- Added support for CDI device requests using `devices` in the Compose file.
-- A lot a bug fixes.
-
-## 2.29.7
-
-{{< release-date date="2024-09-20" >}}
-
-
-### Bug fixes and enhancements
-
-- Fixed a regression when using mount API for bind mounts.
-
-## 2.29.6
-
-{{< release-date date="2024-09-19" >}}
-
-### Update
-
-- Dependencies upgrade: bump docker engine and cli to v27.3.0-rc.2
-
-### Bug fixes and enhancements
-
-- Fixed an issue with Windows Containers bind mounts.
-
-## 2.29.5
-
-{{< release-date date="2024-09-17" >}}
-
-### Bug fixes and enhancements
-
-- Fixed an issue with bind mounts on WSL2.
-
-## 2.29.4
-
-{{< release-date date="2024-09-16" >}}
-
-### Update
-
-- Dependencies upgrade: bump buildx to v0.17.1
-- Dependencies upgrade: bump docker engine and cli to v27.3.0-rc.1
-
-### Bug fixes and enhancements
-
-- Fixed an issue with services not stopping when restarting diverged dependencies.
-- Fixed potential `nil` pointer error on the OTEL client.
-
-## 2.29.3
-
-{{< release-date date="2024-09-12" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.2.0
-- Dependencies upgrade: bump docker engine and cli to v27.2.1
-
-### Bug fixes and enhancements
-
-- Combination of bind mount and `rebuild` are now allowed with `watch`.
-- Fixed a bug recreating containers when `--no-deps` is used with `up`.
-- Fixed a bug not closing streams when reattaching containers.
-- Restored recreation of anonymous volumes when using `-V` or `--renew-anon-volumes`.
-
-## 2.29.2
-
-{{< release-date date="2024-08-16" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.1.6
-- Dependencies upgrade: bump docker engine and cli to v27.1.2
-- Dependencies upgrade: bump buildx to v0.16.2
-- Dependencies upgrade: bump buildkit to v0.15.2
-- Dependencies upgrade: bump golang to v1.21.12
-- Dependencies upgrade: bump sys to v0.22.0
-- Dependencies upgrade: bump flock to v0.12.1
-
-### Bug fixes and enhancements
-
-- Fixed the docs on `docker compose kill` usage.
-- Fixed redundant condition from `toAPIBuildOptions` in build.go.
-- Fixed initial Watch `sync` after Compose restarts with introduction of `x-initialSync`.
-- Fixed an issue which stopped the Compose process for a single container on `sync-restart` Watch action.
-
-## 2.29.1
-
-{{< release-date date="2024-07-23" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.1.5.
-- Dependencies upgrade: bump docker engine and cli to v27.1.0.
-
-### Bug fixes and enhancements
-
-- Enhance JSON progress events with more fields.
-
-
-## 2.29.0
-
-{{< release-date date="2024-07-17" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.1.4
-- Dependencies upgrade: bump docker engine and cli to v27.0.3
-- Dependencies upgrade: bump buildx to 0.16.0
-- Dependencies upgrade: bump buildkit to 0.15.0
-- Dependencies upgrade: bump containerd to 1.7.19
-
-### Bug fixes and enhancements
-
-- Added a JSON stream progress writer.
-- Added a `--prune` flag to the `docker compose watch` command.
-- Unnecessary resources are now excluded after services have been selected.
-- Empty variables with no value are unset in containers.
-
-## 2.28.1
-
-{{< release-date date="2024-06-24" >}}
-
-### Bug fixes and enhancements
-
-- Fixed progress display, broken in `v2.28.0`, when TTY mode available.
-
-## 2.28.0
-
-{{< release-date date="2024-06-21" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.1.3
-- Dependencies upgrade: bump docker engine and cli to v27.0.1-rc.1
-
-## 2.27.3
-
-{{< release-date date="2024-06-21" >}}
-
-### Update
-
-- Dependencies upgrade: bump buildx to 0.15.1
-- Dependencies upgrade: bump buildkit to 0.14.1
-
-## 2.27.2
-
-{{< release-date date="2024-06-20" >}}
-
-### Update
-
-- Dependencies upgrade: bump golang to 1.21.11
-- Dependencies upgrade: bump docker engine and cli to v26.1.4
-- Dependencies upgrade: bump buildx to 0.15.0
-- Dependencies upgrade: bump buildkit to 0.14.0
-- Dependencies upgrade: bump containerd to 1.7.18
-
-### Bug fixes and enhancements
-
-- Added an `--environment` flag to the `config` command
-- Fixed a bug which caused the  `watch` process to hang when used as flag with the `up` command
-- Fixed usage of `COMPOSE_PROFILES` in `.env` file
-
-## 2.27.1
-
-{{< release-date date="2024-05-24" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v2.1.1
-- Dependencies upgrade: bump docker engine and cli to v26.1.3
-- Dependencies upgrade: bump buildx to 0.14.1
-- Dependencies upgrade: bump containerd to 1.7.17
-
-### Bug fixes and enhancements
-
-- Added a navigation menu in the CLI where you can open your Compose file in Docker Desktop
-- Added documentation for `--menu` flag in `docker compose up`
-- Fixed a bug with `--resolve-image-digests` used with `--no-interpolate`
-- You can now use a local `.env` file to override `COMPOSE_*` environment variables
-
-## 2.27.0
-
-{{< release-date date="2024-04-24" >}}
-
-### Update
-
-- Dependencies upgrade: bump golang to 1.21.9
-- Dependencies upgrade: bump compose-go to v2.1.0
-- Dependencies upgrade: bump docker engine and cli to v26.1.0
-
-### Bug fixes and enhancements
-
-- Introduced `--abort-on-container-failure` flag
-- Introduced `--all-resources` to not exclude resources not used by services
-- Introduced support for `build.entitlements`
-- Fixed a bug so Docker Compose now ignores missing containers when `docker compose down/stop -p` is run
-- Fixed support for `--flag=value` syntax in compatibility mode
-
-## 2.26.1
-
-{{< release-date date="2024-03-29" >}}
-
-### Update
-
-- Dependencies upgrade: opencontainers/image-spec v1.1.0
-
-### Bug fixes and enhancements
-
-- Added image pull failure reason in output
-- Fixed crash when running up with `--no-build` and `--watch`
-- Fixed crash when no TTY available and menu enabled
-- Improved legibility of menu actions
-
-## 2.26.0
-
-{{< release-date date="2024-03-22" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go v2.0.2
-- Dependencies upgrade: bump docker v26.0.0
-
-### Bug fixes and enhancements
-
-- Reduced timeout of the Otel tracing command
-- Fixed `config --format json`
-- Fixed documentation on default build image name
-- Introduced Synchronized file shares for bind mounts in Compose
-- Added support for `annotations`
-- Introduced `config --variables` to list Compose model variables
-- Added a navigation menu within `docker compose up`
-
-## 2.25.0
-
-{{< release-date date="2024-03-15" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go v2.0.0
-
-### Bug fixes and enhancements
-
-- Restored `config` behaviour until `--no-interpolate` is set
-- Fixed service name shell completion
-- Added `--watch` flag to `up` command
-
-## 2.24.7
-
-{{< release-date date="2024-03-06" >}}
-
-### Update
-
-- Dependencies upgrade: bump golang to 1.21.8
-- Dependencies upgrade: bump compose-go to 2.0.0-rc8
-- Dependencies upgrade: bump docker to v24.0.4
-
-### Bug fixes and enhancements
-
-- Compose now ensures stable priority sort order for networks
-- Fixed interpolation with curly braces (e.g. JSON) in default values
-- Fixed validation for non-unique `container_name` values
-- Fixed validation for `develop.watch`
-- Fixed environment loading for `include`
-- Fixed panic when merging labels/networks
-- Added support for `--no-path-resolution` when using `include`
-- Fixed missing project name errors
-- Fixed `--no-interpolate` flag on `config`
-- Added a workaround for file lock issues with Watch mode on Windows
-- Fixed duplicate exit code status messages
-- Compose now respects `COMPOSE_REMOVE_ORPHANS` on `up`
-
-## 2.24.6
-
-{{< release-date date="2024-02-15" >}}
-
-### Update
-
-- Dependencies upgrade: bump cli to 25.0.3
-- Dependencies upgrade: bump compose-go to 2.0.0-rc.7
-
-### Bug fixes and enhancements
-
-- Fixed issue of `.env` file loading when project file is set via `COMPOSE_FILE` variable
-- Aligned `ps --status=exited` behaviour with the Docker CLI behaviour
-- Fixed a deadlock when collecting large logs
-
-## 2.24.5
-
-{{< release-date date="2024-01-30" >}}
-
-### Bug fixes and enhancements
-
-- Fixed "failed to solve: changes out of order" errors when building images on Windows.
-
-## 2.24.4
-
-{{< release-date date="2024-01-29" >}}
-
-### Update
-
-- Dependencies upgrade: bump cli to 25.0.1
-- Dependencies upgrade: bump docker to 25.0.1
-- Dependencies upgrade: bump compose-go to 2.0.0-rc.3
-
-### Bug fixes and enhancements
-
-- Fixed issue when checking external network existence when swarm is enabled.
-- Added support for `storage_opt` attribute.
-
-## 2.24.3
-
-{{< release-date date="2024-01-24" >}}
-
-This release fixes a build issue with Docker Desktop for Windows introduced in Compose v2.24.0.
-
-### Update
-
-- Compose now uses a custom version of `fsutils` library.
-
-## 2.24.2
-
-{{< release-date date="2024-01-22" >}}
-
-### Update
-
-- Dependencies upgrade: bump cli to 25.0.0 GA
-- Dependencies upgrade: bump compose-go to 2.0.0-rc.2
-
-## 2.24.1
-
-{{< release-date date="2024-01-18" >}}
-
-### Update
-
-- Dependencies upgrade: bump cli to 25.0.0-rc3
-- Dependencies upgrade: bump docker to 25.0.0-rc3
-- Dependencies upgrade: bump compose-go to 2.0.0-rc.1
-- Dependencies upgrade: bump containerd to 1.7.12
-
-### Bug fixes and enhancements
-
-- Reworked the display of container status during `up`
-- Fixed the engine version required to use `healthcheck.start_interval`
-- Removed `watch` subcommand from the `alpha` command
-- Fixed a bug when handling received signals
-
-## 2.24.0
-
-{{< release-date date="2024-01-11" >}}
-
-### Update
-
-- Dependencies upgrade: bump cli to 25.0.0-beta.3
-- Dependencies upgrade: bump compose-go to 2.0.0-beta.3
-- Dependencies upgrade: bump golang to 1.21.6
-
-### Bug fixes and enhancements
-
-- Introduced `docker compose attach` to attach local standard input, output, and error streams to a service's running container.
-- Introduced `docker compose stats` to display a live stream of container(s) resource usage statistics.
-- Introduced `docker compose ps --orphans` to include/exclude services not declared.
-- Introduced `docker compose logs --index` to select a replica container.
-- Introduced `docker compose build --with-dependencies` to also build dependencies.
-- Added source policies for build.
-- Included disabled services for shell completion.
-- Restored `Project` in ps JSON output.
-- Added OCI 1.0 fallback support for AWS ECR.
-- Build now does not require environment to be resolved.
-- Compose now sends out a cancel event on SIGINT/SIGTERM signal for `compose up`.
-- Fixed log by exposing services ports when `--verbose`.
-- Fixed inlined and environment-defined configs to be mounted under /\<id\> until an explicit target is set.
-- Fixed combination of `--pull always --no-build`.
-- Fixed race condition in log printer.
-- Fixed `docker compose up` teardown when command context is cancelled.
-
-## 2.23.3
-
-{{< release-date date="2023-11-22" >}}
-
-### Update
-
-- Dependencies upgrade: bump buildx to v0.12.0
-
-## 2.23.2
-
-{{< release-date date="2023-11-21" >}}
-
-### Update
-
-- Dependencies upgrade: bump buildkit 0.12.3
-- Dependencies upgrade: bump docker 24.0.7
-- Dependencies upgrade: bump cli 24.0.7
-- Dependencies upgrade: bump 1.20.2
-
-### Bug fixes and enhancements
-
-- Compose now supports `builds.tags` with `push` command.
-- Compose Watch now re-builds service images at startup.
-- Now `--remove-orphans` doesn't manage disabled services as orphaned.
-- Compose displays `Building` output log only if there is at least one service to build.
-
-## 2.23.1
-
-{{< release-date date="2023-11-16" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v1.20.1
-
-### Bug fixes and enhancements
-
-- Aligned Compose with OCI artifact best practices.
-- Introduced `--resolve-image-digests` so users can seal service images by digest when publishing a Compose application.
-- Improved Compose Watch configuration logging.
-- Compose now rejects a Compose file using `secrets|configs.driver` or `template_driver`.
-- Compose now fails to start if a dependency is missing.
-- Fixed SIGTERM support to stop/kill stack.
-- Fixed a `--hash` regression.
-- Fixed "Application failed to start after update" when an external network is on a watched service.
-- Fixed `--pull` documentation.
-- Fixed display by adding newline in cmd/compose/build.go.
-- Compose is rendered quiet after filtering applied.
-- Stripped project prefix from docker-compose up output.
-
-## 2.23.0
-
-{{< release-date date="2023-10-18" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v1.20.0
-- Dependencies upgrade: bump containerd to 1.7.7
-
-### Bug fixes and enhancements
-
-- Added dry-run support for publish command
-- Added `COMPOSE_ENV_FILES` env variable to pass a list of env files
-- Added `sync+restart` action to `compose watch`
-- Aligned `compose ps` output with Docker CLI by default and introduced `--no-trunc` to keep the previous behaviour
-- Fixed hashes inconsistency between `up` and `configure`
-- Enabled profiles when `down` ran with explicit service names
-- Fixed an issue when the pull policy provided was invalid
-
-## 2.22.0
-
-{{< release-date date="2023-09-21" >}}
-
-> [!NOTE]
->
-> The `watch` command is now generally available (GA). You can directly use it from the root command `docker compose watch`.
-> For more information, see [File watch](/manuals/compose/how-tos/file-watch.md).
-
-### Update
-
-- Dependencies upgrade: bump golang to 1.21.1
-- Dependencies upgrade: bump compose-go to v1.19.0
-- Dependencies upgrade: bump buildkit to v0.12.2
-
-### Bug fixes and enhancements
-
-- Added experimental support for the `publish` command.
-- The command `watch` now builds and launches the project during startup.
-- Added `policy` option to the `--pull` flag.
-- Fixed various race and deadlock conditions for `up` command on exit.
-- Fixed multi-platform issues on build.
-- Enabled services that are explicitly requested even when their `profiles` aren't activated.
-- Fixed  a `config` issue when the declared `env_file` is missing.
-- Passed BuildOptions to `up` and `run` commands.
-
-## 2.21.0
-
-{{< release-date date="2023-08-30" >}}
-
-> [!NOTE]
->
-> The format of `docker compose ps` and `docker compose ps --format=json` changed to better align with `docker ps` output. See [compose#10918](https://github.com/docker/compose/pull/10918).
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v1.18.3
-
-### Bug fixes and enhancements
-
-- Changed `docker compose ps` and `docker compose ps --format=json` output to align with Docker CLI.
-- Added support for multi-document YAML files.
-- Added support for loading remote Compose files from Git repos with `include` (experimental).
-- Fixed incorrect proxy variables during build.
-- Fixed truncated container logs on container exit.
-- Fixed "no such service" errors when using `include` with `--profile`.
-- Fixed `.env` overrides when using `include`.
-
-## 2.20.3
-
-{{< release-date date="2023-08-11" >}}
-
-### Update
-
-- Dependencies upgrade: bump golang to 1.21.0
-- Dependencies upgrade: bump compose-go to v1.18.1
-- Dependencies upgrade: bump buildkit to v0.12.1
-
-### Bug fixes and enhancements
-
-- Improved speed and reliability of `watch` sync.
-- Added builder's name on the first build line.
-- Improved shell completion for `--project-directory` and `--profile`.
-- Fixed build issue with proxy configuration not passing to legacy builder.
-- Removed unnecessary warning when an option dependency exists successfully.
-
-## 2.20.2
-
-{{< release-date date="2023-07-19" >}}
-
-### Bug fixes and enhancements
-
-- Added support for the `depends_on.required` attribute.
-- Fixed an issue where build tries to push unnamed service images.
-- Fixed a bug which meant the target secret path on Windows was not checked.
-- Fixed a bug resolving build context path for services using `extends.file`.
-
-## 2.20.1
-
-{{< release-date date="2023-07-18" >}}
-
-### Update
-
-- Dependencies upgrade: bump golang to 1.20.6
-- Dependencies upgrade: bump buildx to v0.11.2
-- Dependencies upgrade: bump buildkit to v0.12
-- Dependencies upgrade: bump docker-cli to v24.0.5-dev
-
-## 2.20.0
-
-{{< release-date date="2023-07-11" >}}
-
-### Update
-
-- Dependencies upgrade: bump docker/cli-docs-tools to v0.6.0
-- Dependencies upgrade: bump docker to v24.0.4
-- Dependencies upgrade: bump buildx to v0.11.1
-
-### Bug fixes and enhancements
-
-* Introduced the `wait` command.
-* Added support of `--builder` and `BUILDX_BUILDER` to the `build` command.
-* Added support for the `include` and `attach` attributes from the Compose Specification.
-* Fixed a DryRun mode issue when initializing CLI client.
-* Fixed a bug with random missing network when a service has more than one.
-* Fixed the Secrets file permission value to comply with the Compose Specification.
-* Fixed an issue about `no-deps` flag not being applied.
-* Fixed some source code comments.
-* Fixed a bug when `--index` is not set select.
-* Fixed a process leak in the wait e2e test.
-* Improved some test speeds.
-
-## 2.19.1
-
-{{< release-date date="2023-06-29" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v1.15.1
-
-### Bug fixes and enhancements
-
-- Fixed sporadic "container not connected to network" errors on `compose up`.
-- Fixed "please specify build context" errors on `compose build`.
-- Compose now warns if using a bind mount in a service `watch` configuration.
-
-## 2.19.0
-
-{{< release-date date="2023-06-21" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v1.15.0
-- Dependencies upgrade: bump buildx to v0.11.0
-- Dependencies upgrade: bump docker to v24.0.2
-- Dependencies upgrade: bump golang to 1.20.5
-
-### Bug fixes and enhancements
-
-- Introduced the ability to select a single service to be stopped by `compose down`.
-- Added `--progress` as top-level flag to configure progress UI style.
-- Introduced `run --cap-add` to run maintenance commands using service image.
-- Fixed a bug during detection of swarm mode.
-- Fixed a bug when setting the project name via `COMPOSE_PROJECT_NAME` environment variable.
-- Adjusted the display of the volumes flag with the help of `down` command.
-- Fixed a bug in the `up` command which should not silently ignore missing `depends_on` services.
-- Aligned forward signal to container behaviour with the `docker run` one.
-- Compose now detects network name conflict.
-- Fixed a typo in the warning message about an existing volume.
-- Compose now detects new services started after `compose -p x logs -f` command.
-- Fixed a bug when `compose` was used as project name.
-- Fixed a bug in the `watch` command when a directory does not exist.
-- Removed default timeout of 10 seconds when restarting or stopping services.
-- Fixed a bug in `watch` which applied the "rebuild" strategy by default.
-- Fixed a race condition, waiting for containers when one exit.
-- Added a warning telling users that uid,gid,mode are not implemented for `build.secrets`.
-- Fixed a bug in `watch` which was watching the whole build context instead of only configured paths.
-- Compose now sorts containers by creation date to scale down the older ones first.
-- Fixed a bug in the docs generation task for Windows environments.
-- Updated the docs to reflect Dry Run mode is feature complete.
-- Improved the diagnostic message on network label mismatch.
-- Fixed a bug which was rendering `Building` section when there was no build involved.
-- Fixed a bug in code coverage metrics.
-- Added OTEL initialization.
-- Added a GitHub action to trigger Docker Desktop e2e tests with Compose edge versions.
-- Added more ignore rules to dependabot.
-
-## 2.18.1
-
-{{< release-date date="2023-05-17" >}}
-
-### Bug fixes and enhancements
-
-- Fixed "Image not found" errors when building images
-
-## 2.18.0
-
-{{< release-date date="2023-05-16" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v1.13.5
-- Dependencies upgrade: bump buildkit to v0.11.6
-- Dependencies upgrade: bump docker to v23.0.5
-
-### Bug fixes and enhancements
-
-- Added dry run support using `--dry-run`
-- Added the first (alpha) implementation of the `viz` sub-command
-- Introduced `--no-path-resolution` to skip relative path to be resolved
-- Introduced `COMPOSE_ANSI` to define the `--ansi` default value
-- Introduced `COMPOSE_STATUS_STDOUT` to get status messages sent to stdout
-- Fixed the BuildKit progressui integration
-- Fixed a bug to stop blocking the events loop collecting logs
-- Restored support for `--memory`
-- Fixed a bug which meant containers didn't stop after termination
-- Compose now lets users declare the build secret target
-- Fixed a bug which caused a container to be recreated when the config has not changed
-- Fixed a race condition when `--parallel` is used with a large number of dependent services
-- Compose now checks the local image matches the required platform
-- Fixed local image removal when `compose down` is ran with `--project-name`
-- Compose now detects the active endpoint trying to remove the network and skips with a warning
-- Removed unnecessary [] output
-- Compose detects that a Windows terminal is not a `console.File` to avoid a panic
-- `--parallel` now has precedence over `COMPOSE_PARALLEL_LIMIT`
-- Compose now reports that the external network is not found when Swarm is disabled
-
-## 2.17.2
-
-{{< release-date date="2023-03-26" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v1.13.2
-
-### Bug fixes and enhancements
-
-- Fixed invalid project name error for directories with uppercase characters or `.` in the name. Fixed [compose#10405](https://github.com/docker/compose/issues/10405)
-
-## 2.17.1
-
-{{< release-date date="2023-03-24" >}}
-
-### Update
-
-- Dependencies upgrade: bump buildkit to v0.11.5
-- Dependencies upgrade: bump compose-go to v1.13.1
-- Dependencies upgrade: bump golang to 1.20.2
-
-### Bug fixes and enhancements
-
-- Fixed panic on `alpha watch` command. Pull Request [compose#10393](https://github.com/docker/compose/pull/10393)
-- Prevented conflicts for services named `extensions`. Fixed [compose-go#247](https://github.com/compose-spec/compose-go/issues/247)
-- Compose now validates project names more consistently. Fixed [compose-go#363](https://github.com/compose-spec/compose-go/issues/363)
-
-## 2.17.0
-
-{{< release-date date="2023-03-23" >}}
-
-### Upgrade notes
-
-- Project name validation is more strictly enforced. Project names can only include letters, numbers, `_`, `-` and must be lowercase and start with a letter or number.
-- Boolean fields in YAML must be either `true` or `false`. Deprecated YAML 1.1 values such as "on" or "no" are not supported.
-- Duplicate YAML merge keys (`<<`) are rejected.
-
-### Update
-
-- Dependencies upgrade: bump buildkit to v0.11.4
-- Dependencies upgrade: bump buildx to v0.10.4
-- Dependencies upgrade: bump containerd to 1.6.18
-- Dependencies upgrade: bump compose-go to v1.13.0
-
-### Bug fixes and enhancements
-
-* Introduced `--wait-timeout` on `up` command. Fixed [compose#10269](https://github.com/docker/compose/issues/10269)
-* Made `compose service --hash` output sort by service name. Pull Request [compose#10278](https://github.com/docker/compose/pull/10278)
-* Compose now renders a compact TUI progress report to monitor layers download. Pull Request [compose#10281](https://github.com/docker/compose/pull/10281)
-* Introduced `restart` for `depends_on`. Fixed [compose#10284](https://github.com/docker/compose/issues/10284)
-* Added support of `NO_COLOR` env var. Fixed [compose#10340](https://github.com/docker/compose/issues/10340)
-* Progress writer now uses `dockercli.Err` stream. Fixed [compose#10366](https://github.com/docker/compose/issues/10366)
-* Added support for `additional_contexts` in the `build` service configuration. Fixed [compose#9461](https://github.com/docker/compose/issues/9461) [compose#9961](https://github.com/docker/compose/issues/9961)
-* Added file delete/rename handling in `watch` mode. Pull Request [compose#10386](https://github.com/docker/compose/pull/10386)
-* Introduced an `ignore` attribute in `watch` mode. Pull Request [compose#10385](https://github.com/docker/compose/pull/10385)
-* Compose now uses progress writer to show copies status. Pull Request [compose#10387](https://github.com/docker/compose/pull/10387)
-* Updated reference documentation for `-p`/`--project-name` flag. Fixed [docs#16915](https://github.com/docker/docs/pull/16915), [compose-spec#311](https://github.com/compose-spec/compose-spec/issues/311)
-* Introduced a `replace` label to track the relationship between old and new containers of a service. Fixed [compose#9600](https://github.com/docker/compose/issues/9600)
-* Fixed a bug that meant dependent services were not restarted after a service was restarted. Fixed [compose#10263](https://github.com/docker/compose/issues/10263)
-* Compose now ignores services without a build section in `watch` mode. Fixed [compose#10270](https://github.com/docker/compose/issues/10270)
-* Compose now applies config options for pseudo-subcommands. Fixed [compose#10286](https://github.com/docker/compose/issues/10286)
-* Compose manages only containers with config_hash labels (i.e, created by compose). Fixed [compose#10317](https://github.com/docker/compose/issues/10317)
-* Compose triggers an error if the project name is empty after normalization. Fixed [compose#10313](https://github.com/docker/compose/issues/10313)
-* Compose restarts only needed services by checking `depends_on` relations. Fixed [compose#10337](https://github.com/docker/compose/issues/10337)
-* Fixed a display issue on small terminals. Fixed [compose#10322](https://github.com/docker/compose/issues/10322)
-* Fixed an issue with building the built images IDs collection. Pull Request [compose#10372](https://github.com/docker/compose/issues/10372)
-* Use configured name separator to define oneoff container name. Fixed [compose#10354](https://github.com/docker/compose/issues/10354)
-* Fixed concurrent map read/write issue when recreating containers. Fixed [compose#10319](https://github.com/docker/compose/issues/10319)
-* Compose now supports Dry Run mode for `stop` and `rm` commands. Pull Request [compose#10257](https://github.com/docker/compose/issues/10257)
-* Compose now supports Dry Run mode for `pull` command. Pull Request [compose#10341](https://github.com/docker/compose/issues/10341)
-* Compose now supports Dry Run mode for `push` command. Pull Request [compose#10355](https://github.com/docker/compose/issues/10355)
-* Compose now supports Dry Run mode for `exec` command. Pull Request [compose#10252](https://github.com/docker/compose/issues/10252)
-* Compose now supports Dry Run mode for `restart` command. Pull Request [compose#10339](https://github.com/docker/compose/issues/10339)
-
-## 2.16.0
-
-{{< release-date date="2023-02-08" >}}
-
-### Update
-
-- Dependencies upgrade: bump docker to v23.0.0
-- Dependencies upgrade: bump docker-cli to v23.0.0
-- Dependencies upgrade: bump buildkit to v0.11.2
-- Dependencies upgrade: bump buildx to v0.10.2
-- Dependencies upgrade: bump containerd to 1.6.16
-- Dependencies upgrade: bump golang to 1.20
-
-### Bug fixes and enhancements
-
-* Introduced `--remove-orphans` for the `compose create` command. Fixed [compose#9718](https://github.com/docker/compose/issues/9718)
-* Shortened the TTY output when the terminal is too small. Fixed [compose#9962](https://github.com/docker/compose/issues/9962)
-* Added `remove-orphans` functionality to run. Fixed [compose#9718](https://github.com/docker/compose/issues/9718#issuecomment-1209448445)
-* Introduced the experimental `watch` command. Pull Request [compose#10163](https://github.com/docker/compose/pull/10163)
-* Compose now allows TTY to be allocated with `-t`. Fixed [compose#10161](https://github.com/docker/compose/issues/10161)
-* Introduced the experimental `dry-run` command. Pull Request [compose#10173](https://github.com/docker/compose/issues/10173)
-* Updated the documentation to explain ways to configure parallelism. Pull Request [compose#10198](https://github.com/docker/compose/issues/10198)
-* Aligned the `logs` command with docker CLI by aliasing `-n` for `--tail`. Fixed [compose#10199](https://github.com/docker/compose/issues/10199)
-* Added support for `docker compose build --push`. Pull Request [compose#10148](https://github.com/docker/compose/issues/10148)
-* Added `--scale` to the `compose create` command. Fixed [compose#10208](https://github.com/docker/compose/issues/10208)
-* Renamed `convert` to `config` to align with the Compose V1 UX. Pull Request [compose#10214](https://github.com/docker/compose/issues/10214)
-* Compose now passes the proxy config as build args. Fixed [compose#8797](https://github.com/docker/compose/issues/8797)
-* Fixed parsing issue in `compose up` by ignoring containers not created by Compose. Fixed [compose#10162](https://github.com/docker/compose/issues/10162#issuecomment-1384989985)
-* Fixed the goroutine leak in log formatter initialization. Fixed [compose#10157](https://github.com/docker/compose/issues/10157)
-* Fixed an issue where compose logs don't exit when all running containers have been stopped. Pull Request [compose#10181](https://github.com/docker/compose/issues/10181)
-* Fixed the documentation to reflect `docker compose ps` being aligned with `docker ps`. Pull Request [compose#10195](https://github.com/docker/compose/issues/10195)
-* Fixed an issue where the remote Buildx driver was not found. Fixed [compose#9893](https://github.com/docker/compose/issues/9893)
-* Improved logging when recreating a service container. Pull request [compose#10236](https://github.com/docker/compose/issues/10236)
-* Fixed an issue so Compose now only waits for containers concerned by the wait condition. Fixed [compose#10200](https://github.com/docker/compose/issues/10200)
-* Compose now prevents assignment to entry in nil map. Fixed [compose#10244](https://github.com/docker/compose/issues/10244)
-* Added a dedicated GitHub Action workflow for Cucumber tests. Pull Request [compose#10165](https://github.com/docker/compose/issues/10165)
-* Cleaned the TUI lines when switching in compact log mode. Fixed [compose#10201](https://github.com/docker/compose/issues/10201)
-* Added Tilt watcher to detect code changes in watch mode. Pull Request [compose#10218](https://github.com/docker/compose/issues/10218)
-* Compose now supports Dry Run mode for `kill` command. Fixed [compose#10210](https://github.com/docker/compose/issues/10210)
-* Compose now supports Dry Run mode for `pause` command.Fixed [compose#10217](https://github.com/docker/compose/issues/10217)
-* Compose now supports Dry Run mode for `cp` command.Fixed [compose#10235](https://github.com/docker/compose/issues/10235)
-
-## 2.15.1
-
-{{< release-date date="2023-01-09" >}}
-
-### Update
-
-- Dependencies upgrade to fix Golan CVE-2022-27664 and CVE-2022-32149
-
-### Bug fixes and enhancements
-
-* Added support for UTS namespace. Fixed [compose#8408](https://github.com/docker/compose/issues/8408)
-* Fixed filtering issue when no filter set. Fixed [roadmap#418](https://github.com/docker/roadmap/issues/418)
-* Fixed concurrent map writes issue during build step. Pull Request [compose#10151](https://github.com/docker/compose/pull/10151)
-* Fixed issue when stdin is not a terminal. Fixed [compose#9739](https://github.com/docker/compose/issues/9739)
-
-## 2.15.0
-
-{{< release-date date="2023-01-05" >}}
-
-### Update
-
-- Dependencies upgrade: bump compose-go to v1.8.1
-- Dependencies upgrade: bump cli-docs-tool to 0.5.1
-
-### Bug fixes and enhancements
-
-* Added support of the `privileged` attribute in the `service.build` section. Pull Request [compose#10112](https://github.com/docker/compose/pull/10112)
-* Introduced `--ignore-buildable` to ignore buildable images on pull. Fixed [compose#8805](https://github.com/docker/compose/issues/8805)
-* Introduced `--no-attach` to ignore some service outputs. Fixed [compose#8546](https://github.com/docker/compose/issues/8546)
-* Fixed issue with `logs` when `driver:none` is set. Fixed [compose#9030](https://github.com/docker/compose/issues/9030)
-* Compose now relies on dockerCLI.streams. Pull Request [compose#10082](https://github.com/docker/compose/pull/10082)
-* Fixed issue with service hash that MUST exclude replicas. Fixed [compose#10077](https://github.com/docker/compose/issues/10077)
-* Compose now checks service names based on project, not running containers. Fixed [compose#9951](https://github.com/docker/compose/issues/9951)
-* Fixed security opts support (seccomp and unconfined). Fixed [compose#9505](https://github.com/docker/compose/issues/9505)
-* Fixed empty file when using compose config in case of smaller source files. Fixed [compose#10121](https://github.com/docker/compose/issues/10121)
-* Fixed issue with `--pull` not applied on `compose up`. Fixed [compose#10125](https://github.com/docker/compose/issues/10125)
-* Compose should ignore not only auto-removed containers but also "removal in progress" for orphan containers. Pull Request [compose#10136](https://github.com/docker/compose/pull/10136)
-* Compose limits build concurrency according to `--parallel`. Fixed [compose#9091](https://github.com/docker/compose/issues/9091)
-
-## 2.14.2
-
-{{< release-date date="2022-12-20" >}}
-
-### Update
-
-- Dependencies upgrade: bump containerd to 1.6.14
-
-### Bug fixes and enhancements
-
-* Compose now uses DOCKER_DEFAULT_PLATFORM to determine the platform when creating a container. Fixed [compose#10041](https://github.com/docker/compose/pull/10041)
-* Compose now detects when dependency failed to start. Fixed [compose#9732](https://github.com/docker/compose/pull/9732)
-* Fixed WCOW volume mounts.  Fixed [compose#9577](https://github.com/docker/compose/pull/9577)
-* List only running containers when using `--all=false`.  Fixed [compose#10085](https://github.com/docker/compose/pull/10085)
-* Fixed a regression when running pull `--ignore-pull-failures`.  Fixed [compose#10089](https://github.com/docker/compose/pull/10089)
-* Fixed CPU quota issue. Fixed [compose#10073](https://github.com/docker/compose/pull/10073)
-* Fixed race condition on compose logs. Fixed [compose#8880](https://github.com/docker/compose/pull/8880)
-* Updated projectOptions to be public by renaming it to ProjectOptions. Fixed [compose#100102](https://github.com/docker/compose/pull/100102)
-
-## 2.14.1
-
-{{< release-date date="2022-12-15" >}}
-
-### Updates
-
-- Dependencies upgrade: bump Go to 1.19.4
-- Dependencies upgrade: bump containerd to 1.6.12
-
-### Bug fixes and enhancements
-
-- Added `--parallel` to limit concurrent engine calls. Pull Request [compose#10030](https://github.com/docker/compose/pull/10030)
-- Distinguished stdout and stderr in `up` logs. Fixed [compose#8098](https://github.com/docker/compose/issues/8098)
-- Aligned `compose ps` output with `docker ps`. Fixed [compose#6867](https://github.com/docker/compose/issues/6867)
-- Added `--include-deps` to push command. Pull Request [compose#10044](https://github.com/docker/compose/pull/10044)
-- Introduced `--timestamp` option on `compose up`. Fixed [compose#5730](https://github.com/docker/compose/issues/5730)
-- Compose now applies uid/gid when creating a secret from the environment. Pull Request [compose#10084](https://github.com/docker/compose/pull/10084)
-- Fixed deadlock when waiting for attached-dependencies. Fixed [compose#10021](https://github.com/docker/compose/pull/10021)
-- Fixed race condition when collecting pulled images IDs. Fixed [compose#9897](https://github.com/docker/compose/pull/9897)
-- Compose doesn't stop the `pull` command for images that can be built. Fixed [compose#8724](https://github.com/docker/compose/pull/8724)
-- Fixed corner case when there's no container to attach to. Fixed [compose#8752](https://github.com/docker/compose/pull/8752)
-- Compose containers' startup must run sequentially for engine to assign distinct ports within a configured range. Fixed
-[compose#8530](https://github.com/docker/compose/pull/8530)
-- Fixed parsing of `repository:tag`. Fixed [compose#9208](https://github.com/docker/compose/pull/9208)
-- Load project from files when explicitly set by user. Fixed [compose#9554](https://github.com/docker/compose/pull/9554)
-
-## 2.14.0
-
-{{< release-date date="2022-12-02" >}}
-
-### Updates
-
-- Dependencies upgrade: bump compose-go to [v1.8.0](https://github.com/compose-spec/compose-go/releases/tag/v1.8.0)
-- Dependencies upgrade: bump Go to 1.19.3
-
-### Bug fixes and enhancements
-
-- Added `oom_score_adj` field to service definition. Pull Request [compose#10019](https://github.com/docker/compose/issues/10019)
-- Added mode field for tmpfs mount permissions. Pull Request [compose#10031](https://github.com/docker/compose/issues/10031)
-- Compose now only stops services started by `up` when interrupted. Fixed [compose#10028](https://github.com/docker/compose/issues/10028)
-- Compose now loads implicit profiles for targeted services. Fixed [compose#10025](https://github.com/docker/compose/issues/10025)
-- Compose does not require `service.build.platforms` to be set if `service.platform` is set. Fixed [compose#10017](https://github.com/docker/compose/issues/10017)
-- Plain output is used during buildx image builds if `--ansi=never` is set. Fixed [compose#10020](https://github.com/docker/compose/issues/10020)
-- `COMPOSE_IGNORE_ORPHANS` environment variable now behaves more consistently. Fixed [compose#10035](https://github.com/docker/compose/issues/10035)
-- Compose now uses the correct image name separator in `convert`. Fixed [compose#9904](https://github.com/docker/compose/issues/9904)
-- Fixed `run` for services using `network_mode: service:NAME`. Fixed [compose#10036](https://github.com/docker/compose/issues/10036)
-
-## 2.13.0
-
-{{< release-date date="2022-11-23" >}}
-
-### Updates
-
-- Dependencies upgrade: bump containerd to 1.6.10
-- Dependencies upgrade: bump docker-credential-helpers to v0.7.0
-- Update CI dependencies. Pull Request [compose#9982](https://github.com/docker/compose/pull/9982)
-
-### Bug fixes and enhancements
-
-- Added a `no-consistency` option to `convert` command. Fixed [compose#9963](https://github.com/docker/compose/issues/9963)
-- Added a `build` option to `run` command. Fixed [compose#10003](https://github.com/docker/compose/issues/10003)
-- Fixed mapping `restart_policy.condition` to engine supported values. Fixed [compose#8756](https://github.com/docker/compose/issues/8756), [docs#15936](https://github.com/docker/docs/pull/15936)
-- Fixed missing support of `deploy.reservation.memory`. Fixed [compose#9902](https://github.com/docker/compose/issues/9902)
-- Fixed a bug to prevent usage of `COMPOSE_PROFILES` when `--profile` arg is used. Fixed [compose#9895](https://github.com/docker/compose/issues/9895)
-- Fixed a bug to prevent pulling a service's image when depending on a service which will build this image. Fixed [compose#9983](https://github.com/docker/compose/issues/9983)
-- Fixed parsing issue when a container number label is not found. Fixed [compose#10004](https://github.com/docker/compose/issues/10004)
-- Compose now uses the platform value defined by `DOCKER_DEFAULT_PLATFORM` when no `service.platform` defined. Fixed [compose#9889](https://github.com/docker/compose/issues/9889)
-- Removed usage of the deprecated dependency `gotest.tools` v2. Pull Request [compose#9935](https://github.com/docker/compose/pull/9935)
-- Excluded issues labeled with `kind/feature` from stale bot process. Fixed [compose#9988](https://github.com/docker/compose/pull/9988)
-
-## 2.12.2
-
-{{< release-date date="2022-10-21" >}}
-
-### Updates
-
-- Updated Docker Engine API to restore compatibility with Golang 1.18 needed for Linux packaging. Pull Request [compose#9940](https://github.com/docker/compose/pull/9940)
-
-For the full change log or additional information, check the [Compose repository 2.12.2 release page](https://github.com/docker/compose/releases/tag/v2.12.2).
-
-## 2.12.1
-
-{{< release-date date="2022-10-21" >}}
-
-### Security
-
-- Updated Docker Engine API to apply fix of [CVE-2022-39253](https://nvd.nist.gov/vuln/detail/CVE-2022-39253). Pull Request [compose#9934](https://github.com/docker/compose/pull/9934)
-
-For the full change log or additional information, check the [Compose repository 2.12.1 release page](https://github.com/docker/compose/releases/tag/v2.12.1).
-
-## 2.12.0
-
-{{< release-date date="2022-10-18" >}}
-
-### Updates
-
-- CI update to the documentation repository path
-- Upgraded to compose-go from [1.5.1 to 1.6.0](https://github.com/compose-spec/compose-go/releases/tag/v1.6.0)
-
-- Updated to go 1.19.2 to address CVE-2022-2879, CVE-2022-2880, CVE-2022-41715
-
-### Bug fixes and enhancements
-
-- Added a `quiet` option when pushing an image. Fixed [compose#9089](https://github.com/docker/compose/issues/9089)
-- Fixed a misleading error message for `port` command. Pull Request [compose#9909](https://github.com/docker/compose/pull/9909)
-- Fixed a bug to prevent failure when Compose tries to remove a non-existing container. Fixed by [compose#9896](https://github.com/docker/compose/pull/9896/)
-- Switched GitHub issue template form
-
-For the full change log or additional information, check the [Compose repository 2.12.0 release page](https://github.com/docker/compose/releases/tag/v2.12.0).
-
-## 2.11.2
-
-{{< release-date date="2022-09-27" >}}
-
-> [!NOTE]
->
-> - Updates on environment file syntax & interpolation: see [compose#9879](https://github.com/docker/compose/issues/9879)
-> - Setting `DOCKER_HOST` via `.env` files is not supported in Compose v2
-
-### Updates
-
-- Upgraded to compose-go from [1.5.1 to 1.6.0](https://github.com/compose-spec/compose-go/releases/tag/v1.6.0)
-
-### Bug fixes and enhancements
-
-- Fixed a bug to prevent "invalid template" errors on valid environment variable values. Fixes [compose##9806](https://github.com/docker/compose/issues/9806), [compose##9746](https://github.com/docker/compose/issues/9746), [compose##9704](https://github.com/docker/compose/issues/9704), [compose##9294](https://github.com/docker/compose/issues/9294)
-- Fixed a bug to ensure new images from `docker compose build` are used. Fixes [compose#9856](https://github.com/docker/compose/issues/9856)
-- Fixed cross-architecture builds when `DOCKER_DEFAULT_PLATFORM` not set. Fixes [compose#9864](https://github.com/docker/compose/pull/9864)
-- Fixed intermittent conflict errors when using `depends_on`. Fixes [compose#9014](https://github.com/docker/compose/issues/9014)
-- Cleared service `CMD` when entry point is overridden. Fixes [compose#9622](https://github.com/docker/compose/issues/9622)
-- Configured default builder export when no `build.platforms` defined. Fixes [compose#9856](https://github.com/docker/compose/issues/9856)
-- Fixed a bug to keep the platform defined, in priority, via DOCKER_DEFAULT_PLATFORM or the `service.platform` attribute. Fixes [compose#9864](https://github.com/docker/compose/issues/9864)
-- Removed support for `DOCKER_HOST` in `.env` files. Fixes [compose#9210](https://github.com/docker/compose/issues/9210)
-- Fixed a bug to ensure clean service command if entry point is overridden in run command. Fixes [compose#9622](https://github.com/docker/compose/issues/9622)
-- Deps: fixed race condition during graph traversal. Fixes [compose#9014](https://github.com/docker/compose/issues/9014)
-- CI now runs on Windows & macOS including E2E tests via Docker Desktop
-- Added more information when `service.platform` isn't part of `service.build.platforms`
-- GitHub Workflows security hardening
-
-For the full change log or additional information, check the [Compose repository 2.11.2 release page](https://github.com/docker/compose/releases/tag/v2.11.2).
-
-## 2.11.1
-
-{{< release-date date="2022-09-20" >}}
-
-### Bug fixes and enhancements
-
-- Fixed a bug to keep `depends_on` condition when service has `volumes_from`. Fixes [compose#9843](https://github.com/docker/compose/issues/9843)
-- Fixed a bug to keep the platform defined at service level during build if no build platforms. Fixes [compose#9729](https://github.com/docker/compose/pull/9729#issuecomment-1246748144)
-- Fixed a bug to keep the platform defined via DOCKER_DEFAULT_PLATFORM during build if no build platforms provided. Fixes [compose#9853](https://github.com/docker/compose/issues/9853)
-
-For the full change log or additional information, check the [Compose repository 2.11.1 release page](https://github.com/docker/compose/releases/tag/v2.11.1).
-
-## 2.11.0
-
-{{< release-date date="2022-09-14" >}}
-
-### Updates
-
-- Dependencies upgrade: bump Golang to 1.19.1
-- Dependencies upgrade: bump github.com/docker/go-units from 0.4.0 to 0.5.0
-- Dependencies upgrade: bump github.com/cnabio/cnab-to-oci from 0.3.6 to 0.3.7
-- Dependencies upgrade: bump go.opentelemetry.io/otel from 1.9.0 to 1.10.0
-- Dependencies upgrade: bump github.com/AlecAivazis/survey/v2 from 2.3.5
-- Dependencies upgrade: bump go.opentelemetry.io/otel from 1.4.1 to 1.9.0
-- Dependencies upgrade: bump compose-go from [1.5.0 to 1.5.1](https://github.com/compose-spec/compose-go/releases/tag/v1.5.1)
-
-### Bug fixes and enhancements
-
-- Added platforms build. Fixes [compose-spec#267](https://github.com/compose-spec/compose-spec/pull/267)
-- Logs now filter to services from current Compose file. Fixes [compose#9801](https://github.com/docker/compose/issues/9801)
-- Added an improved output warning when pulling images. Fixes [compose#9820](https://github.com/docker/compose/issues/9820)
-- Fixed a bug to ensure correct capture of exit code when service has dependencies. Fixes [compose#9778](https://github.com/docker/compose/issues/9778)
-- Fixed `down` with `--rmi`. Fixes [compose#9655](https://github.com/docker/compose/issues/9655)
-- Fixed docker-compose convert that turns $ into $$ when using the --no-interpolate option. Fixes [compose#9160](https://github.com/docker/compose/issues/9160)
-- Fixed `build.go` access custom labels directly cause panic. See [compose#9810](https://github.com/docker/compose/pull/9810)
-- Applied newly loaded envvars to "DockerCli" and "APIClient". Fixes [compose#9210](https://github.com/docker/compose/issues/9210)
-- Only attempt to start specified services on `compose start [services]`. Fixes [compose#9796](https://github.com/docker/compose/issues/9796) [compose#9807](https://github.com/docker/compose/issues/9807)
-- Label built images for reliable cleanup on `down`. Fixes [compose#9655](https://github.com/docker/compose/issues/9655)
-
-For the full change log or additional information, check the [Compose repository 2.11.0 release page](https://github.com/docker/compose/releases/tag/v2.11.0).
-
-## 2.10.2
-
-{{< release-date date="2022-08-26" >}}
-
-### Bug fixes and enhancements
-
-- Properly respect `DOCKER_TLS_VERIFY` and `DOCKER_CERT_PATH` environment variables. Fixes [compose#9789](https://github.com/docker/compose/issues/9789).
-- Improved `Makefile` used in [docker/docker-ce-packaging#742](https://github.com/docker/docker-ce-packaging/pull/742).
-
-For the full change log or additional information, check the [Compose repository 2.10.2 release page](https://github.com/docker/compose/releases/tag/v2.10.2).
-
-## 2.10.1
-
-{{< release-date date="2022-08-24" >}}
-
-### Updates
-
-- Dependencies update: Bumped github.com/moby/buildkit from [0.10.3 to 0.10.4](https://github.com/moby/buildkit/releases/tag/v0.10.4).
-
-### Bug fixes and enhancements
-
-- Fixed image pulls being skipped when `pull_policy` was not set. Fixes [compose#9773](https://github.com/docker/compose/issues/9773).
-- Restored `.sha256` checksum files in release artifacts. Fixes [compose#9772](https://github.com/docker/compose/issues/9772).
-- Removed error message showing exit code when using --exit-code-from. Fixes [compose#9782](https://github.com/docker/compose/issues/9782).
-- Fixed `compose pull` to pull images even when they existed locally if `tag=latest`.
-- CI: Fixed checksums checking and brought back individual checksum files.
-
-For the full change log or additional information, check the [Compose repository 2.10.1 release page](https://github.com/docker/compose/releases/tag/v2.10.1).
-
-## 2.10.0
-
-{{< release-date date="2022-08-19" >}}
-
-### New
-
-- Applied newly loaded environment variables to `DockerCli` and `APIClient`. Fixes [compose#9210](https://github.com/docker/compose/issues/9210).
-- Added support for windows/arm64 and linux/riscv64.
-
-### Updates
-
-- Updated Dockerfile syntax to latest stable and renamed docs Dockerfile.
-- Dependencies update: Upgraded BuildKit & docker/distribution.
-- Dependencies update: Updated Docker CLI version used in CI to v20.10.17.
-- Dependencies update: Bumped github.com/containerd/containerd from [1.6.6 to 1.6.7](https://github.com/containerd/containerd/releases/tag/v1.6.7).
-- Dependencies update: Bump github.com/containerd/containerd from [1.6.7 to 1.6.8](https://github.com/containerd/containerd/releases/tag/v1.6.8).
-- Dependencies update: Bumped to Go 1.18.5.
-- Dependencies update: Bumped github.com/cnabio/cnab-to-oci from [0.3.5 to 0.3.6](https://github.com/cnabio/cnab-to-oci/releases/tag/v0.3.6).
-
-### Bug fixes and enhancements
-
-- Reverted environment variables precedence to OS over `.env` file. Fixes [compose#9737](https://github.com/docker/compose/issues/9737).
-- Updated usage strings for consistency.
-- Resolved environment variables case-insensitively on Windows. Fixes [compose#9431](https://github.com/docker/compose/issues/9431).
-- Fixed `compose up` so dependency containers aren't stopped when a stop signal is issued. This keeps parity with v1 behavior-wise.
-- Fixes [compose#9696](https://github.com/docker/compose/issues/9696).
-- Fixed commands that start/restart/pause/unpause so that, if ran from the Compose file, the Compose model is also applied. Fixes [compose#9705](https://github.com/docker/compose/issues/9705) and [compose#9705](https://github.com/docker/compose/issues/9671).
-- Removed extra whitespaces in help text of some subcommands.
-- Fixed `compose create` to not override service pull policy when the value from the command line is configured as the default. Fixes [compose#9717](https://github.com/docker/compose/issues/9717).
-- Filtered out "commandConn.Close- warning" message. Fixes[compose#8544](https://github.com/docker/compose/issues/8544).
-- Fixed up/start/run to not wait for disabled dependency. Fixes [compose#9591](https://github.com/docker/compose/issues/9591).
-- Applied Compose model on `compose kill`, added `--remove-orphans` option. Fixes [compose#9742](https://github.com/docker/compose/issues/9742).
-- Fixed `compose pull` to avoid pulling the same images multiple times. Fixes [compose#8768](https://github.com/docker/compose/issues/8768).
-- Fixed version of golangci-lint to v1.47.3, issue with v1.48.0 for now.
-
-For the full change log, check the [Compose repository 2.10.0 release page](https://github.com/docker/compose/releases/tag/v2.10.0).
-
-## 2.9.0
-
-{{< release-date date="2022-08-7" >}}
-
-> [!IMPORTANT]
->
-> Compose v2.9.0 contains changes to the environment variable's precedence that have since been reverted. We recommend using v2.10+ to avoid compatibility issues.
-
-> [!NOTE]
->
-> This release reverts the breaking changes introduced in [Compose v2.8.0](#280) by [`compose-go v1.3.0`](https://github.com/compose-spec/compose-go/releases/tag/v1.3.0).
-
-### Updates
-
-- Updated [`compose-go` to v1.4.0](https://github.com/compose-spec/compose-go/releases/tag/v1.4.0) as previous version introduced breaking changes. Fixes [compose#9700](https://github.com/docker/compose/issues/9700).
-
-### Bug fixes and enhancements
-
-- Overwritten parent commands PreRun code for `compose version`. Fixes [compose#9698](https://github.com/docker/compose/issues/9698).
-- Fixed `LinkLocalIPs` in V2. Fixes [compose#9692](https://github.com/docker/compose/issues/9692).
-- Linked to `BUILDING.md` for testing instructions. Fixes [compose#9439](https://github.com/docker/compose/issues/9439).
-
-For the full change log or additional information, check the [Compose repository 2.9.0 release page](https://github.com/docker/compose/releases/tag/v2.9.0).
-
-## 2.8.0
-
-{{< release-date date="2022-07-29" >}}
-
-> [!IMPORTANT]
->
->This release introduced a breaking change via `compose-go v1.3.0` and this [PR](https://github.com/compose-spec/compose-go/pull/294).
-In this release, Docker Compose recreates new resources (networks, volumes, secrets, configs, etc.) with new names, using a `-` (dash) instead an `_` (underscore) and tries to connect to or use these newly created resources instead of your existing ones!
->
-> Please use Compose the v2.9.0 release instead.
->
-
-### New
-
-- Introduced `--pull` flag to allow the force pull of updated service images. Fixes [compose#9451](https://github.com/docker/compose/issues/9451).
-- Increased code quality by adding `gocritic` to the linters.
-
-### Bug fixes and enhancements
-
-- Fixed interpolation error message output. Fixes [compose-spec/compose-go#292](https://github.com/compose-spec/compose-go/pull/292).
-- Defined precedence of the environment variables evaluation. Fixes [compose#9521](https://github.com/docker/compose/issues/9606),
-[compose#9638](https://github.com/docker/compose/issues/9638),
-[compose#9608](https://github.com/docker/compose/issues/9608),
-[compose#9578](https://github.com/docker/compose/issues/9578).
-[compose#9468](https://github.com/docker/compose/issues/9468), and
-[compose#9683](https://github.com/docker/compose/issues/9468).
-- Docs CI: Fixed to use push-to-fork when creating a PR.
-- Used environmental variable for golang's version and updates GitHub Actions from v2 to v3.
-- Used [google/addlicense](https://github.com/google/addlicense) instead of [kunalkushwaha/ltag](https://github.com/kunalkushwaha/ltag).
-
-For the full change log or additional information, check the [Compose repository 2.8.0 release page](https://github.com/docker/compose/releases/tag/v2.8.0).
-
-## 2.7.0
-
-{{< release-date date="2022-07-20" >}}
-
-### New
-
-- Added support for environment secrets during build step. Fixes [compose#9606](https://github.com/docker/compose/issues/9606).
-
-### Updates
-
-- Dependencies upgrade: bumped [go to 1.18.4](https://github.com/golang/go/compare/go1.18.3...go1.18.4).
-- Dependencies upgrade: bumped [compose-go to v1.2.9](https://github.com/compose-spec/compose-go/releases/tag/v1.2.9).
-
-### Bug fixes and enhancements
-
-- Networks: prevented issues due to duplicate names. Fixes [moby/moby#18864](https://github.com/moby/moby/issues/18864).
-- Fixed issue with close networks name on `compose up` and `compose down` commands. Fixes [compose#9630](https://github.com/docker/compose/issues/9044).
-- Used appropriate dependency condition for one-shot containers when running `compose up --wait`. Fixes [compose#9606](https://github.com/docker/compose/pull/9572).
-- Fixed environment variable expansion.
-- Validated depended-on services exist in consistency check. Fixes [compose#8910](https://github.com/docker/compose/issues/8910).
-- Fixed hash usage in environment values. Fixes [compose#9509](https://github.com/docker/compose/issues/9509).
-- Docker Build: added fix to respect dependency order for classic builder. Fixes [compose#8538](https://github.com/docker/compose/issues/8538).
-- Fixed panic caused by empty string argument. Fixes [compose-switch#35](https://github.com/docker/compose-switch/issues/35).
-- Fixed start/restart as to not impact one-off containers. Fixes [compose#9509](https://github.com/docker/compose/issues/9044).
-- Fixed to keep the container reference when `volumes_from` targets a container and not a service. Fixes [compose#8874](https://github.com/docker/compose/issues/8874).
-- build.go: added fix to initialize `CustomLabels` map if `nil`.
-- Added new targets to build Compose binary before running e2e tests.
-- CI: released workflow to open a PR on docs repo with latest changes.
-- e2e: added test for `ps`.
-- e2e: split out pause tests and add more cases.
-- e2e: add more start/stop test cases.
-
-For the full change log or additional information, check the [Compose repository 2.7.0 release page](https://github.com/docker/compose/releases/tag/v2.7.0).
-
-## 2.6.1
-
-{{< release-date date="2022-06-23" >}}
-
-### New
-
-- Added support for setting secrets from environment variable. Fixes [compose-spec/compose-spec#251](https://github.com/compose-spec/compose-spec/issues/251).
-
-### Updates
-
-- Upgrade: compose-go [v1.2.8](https://github.com/compose-spec/compose-go/releases/tag/v1.2.8).
-- Upgrade: buildx [v0.8.2](https://github.com/docker/buildx/releases/tag/v0.8.2).
-- Dependencies upgrade: bumped runc [to 1.1.2](https://github.com/opencontainers/runc/releases/tag/v1.1.2).
-- Dependencies upgrade: bumped golang to [1.18.3](https://go.dev/doc/devel/release#go1.18.minor).
-- Dependencies upgrade: bumped compose-go to [v1.2.8](https://github.com/compose-spec/compose-go/releases/tag/v1.2.8).
-- Dependencies upgrade: bumped github.com/theupdateframework/notary from 0.6.1 to 0.7.0.
-- Dependencies upgrade: bumped github.com/cnabio/cnab-to-oci from 0.3.1-beta1 to 0.3.3.
-- Dependencies upgrade: bumped github.com/hashicorp/go-version from 1.3.0 to 1.5.0.
-- Dependencies upgrade: bumped github.com/stretchr/testify from 1.7.0 to 1.7.2.
-- Dependencies upgrade: bumped github.com/docker/buildx from 0.8.1 to 0.8.2.
-- Dependencies upgrade: bumped github.com/AlecAivazis/survey/v2 from 2.3.2 to 2.3.5.
-- Dependencies upgrade: bumped github.com/containerd/containerd from 1.6.2 to 1.6.6.
-
-### Bug fixes and enhancements
-
-- Added links to container create request. Fixes [#9513](https://github.com/docker/compose/issues/9513).
-- Fixed `compose run` to start only direct dependencies. Fixes [#9459](https://github.com/docker/compose/issues/9459).
-- Fixed `compose up` 'service not found' errors when using `--no-deps` option. Fixes [#9427](https://github.com/docker/compose/issues/9427).
-- Fixed `compose down` to respect `COMPOSE_REMOVE_ORPHANS` environment variable. Fixes [#9562](https://github.com/docker/compose/issues/9562).
-- Fixed project-level bind mount volumes. Fixes [docker/for-mac#6317](https://github.com/docker/for-mac/issues/6317).
-- Fixed parsing of properties `deploy.limits.cpus` and `deploy.limits.pids` to respect floating-point values. Fixes [#9542](https://github.com/docker/compose/issues/9542) and [#9501](https://github.com/docker/compose/issues/9501).
-- Fixed `compose ps` output to list all exposed ports. Fixes [#9257](https://github.com/docker/compose/issues/9527).
-- Fixed spelling mistakes in `compose ps` code.
-- Fixed `docker compose` to honor `--no-ansi` even when deprecated option is requested.
-- Fixed network name and network ID possible ambiguity.
-- e2e: added test for `ps`.
-- e2e: unmarshalled json into container summaries.
-- e2e: fixed subtests and block parallel unsafe tests.
-- e2e: isolated test command env from system env.
-- e2e: fixed spurious `ps` failures.
-- e2e: ensured all compose commands standalone compatible.
-- e2e: improved test output on failures.
-
-For the full change log or additional information, check the [Compose repository 2.6.1 release page](https://github.com/docker/compose/releases/tag/v2.6.1).
-
-## 2.6.0
-
-{{< release-date date="2022-05-30" >}}
-
-### New
-
-- Added the tags property to the build section. In this property tags can be defined to be applied to the final image, in addition to the one defined in the image property.
-- Added end-to-end tests to ensure there is no regression on environment variables precedence.
-- Added ddev's end-to-end test.
-
-### Updates
-
-- Dependencies update: bumping [compose-go to 1.2.6](https://github.com/compose-spec/compose-go/releases/tag/v1.2.6).
-- Dependencies update: bumping [compose-go to 1.2.7](https://github.com/compose-spec/compose-go/releases/tag/v1.2.7).
-- Dependencies update: bumping [golang to 1.18](https://go.dev/doc/devel/release#go1.18).
-
-### Bug fixes and enhancements
-
-- Fixed `compose up` to attach only to services declared in project with enabled profiles. Fixes [#9286](https://github.com/docker/compose/issues/9286).
-- Fixed flickering prompt when pulling same image from multiple services. Fixes [#9469](https://github.com/docker/compose/issues/9469).
-- Fixed compose go to import .env file to OS environment to allow setting variables (such as DOCKER_BUILDKIT) through this file. Fixes [#9345](https://github.com/docker/compose/issues/9345).
-- Fixed `TestLocalComposeUp` that failed locally.
-- Fixed local run of make `e2e-compose-standalone`.
-
-For the full change log or additional information, check the [Compose repository 2.6.0 release page](https://github.com/docker/compose/releases/tag/v2.6.0).
-
-## 2.5.1
-
-{{< release-date date="2022-05-17" >}}
-
-### Updates
-
-- Dependencies updates: bumping compose-go to 1.2.5.
-
-### Bug fixes and enhancements
-
-- Fixed resolution of project's working directive absolute path when a relative path is declared using '--env-file'. Fixes [docker/for-mac#6229](https://github.com/docker/for-mac/issues/6229).
-- Fixed `compose down`: now rejects all arguments in order to clarify usage. Fixes [#9151](https://github.com/docker/compose/issues/9151).
-- Fixed `compose down`: now exits with status=0 if there is nothing to remove. Fixes [#9426](https://github.com/docker/compose/issues/9426).
-- Fixed extra space printed in logs output lines with --no-log-prefix option. Fixes [#9464](https://github.com/docker/compose/issues/9464).
-- Clarified what the default work dir is when multiple compose files are passed.
-- cp command: copy to all containers of a service as default behavior.
-
-For the full change log or additional information, check the [Compose repository 2.5.1 release page](https://github.com/docker/compose/releases/tag/v2.5.1).
-
-## 2.5.0
-
-{{< release-date date="2022-04-29" >}}
-
-### Bug fixes and enhancements
-
-- Fixed panic with `compose down` command when `-p` flag specified. Fixes [#9353](https://github.com/docker/compose/issues/9353).
-- Passed newly created project as input to start services (`docker compose up`). Fixes [#9356](https://github.com/docker/compose/issues/9356).
-- Included services declared under links in docker-compose file as implicit dependencies. Fixes [#9301](https://github.com/docker/compose/issues/9301).
-- Added changes `docker compose pull` command to respect defined policy: 1) skip services configured as `pull_policy: never` and 2) ignore those with an existing image and `pull_policy: missing`. Fixes [#3660](https://github.com/docker/compose/issues/3660).
-- Error building project from resources is no longer ignored in order to prevent `down` panic. Fixes [#9383](https://github.com/docker/compose/issues/9383).
-- Enforced project name to be lowercase. Fixes [#9378](https://github.com/docker/compose/issues/9378).
-- Added support to build-time secrets. Fixes [#6358](https://github.com/docker/compose/issues/6358).
-- Changed `compose-go` to allow (re)building volume string to be used by engine `bind` API when mount can't be used. Fixes [#9380](https://github.com/docker/compose/issues/9380).
-- Provided checksums.txt file and added `--binary` to allow verification in different OS. Fixes [#9388](https://github.com/docker/compose/issues/9388).
-- Added changes so locally pulled image's ID is inspected and persisted to `com.docker.compose.image`. Fixes [#9357](https://github.com/docker/compose/issues/9357).
-- Fixed issue regarding IPAM gateway setup. Fixes [#9330](https://github.com/docker/compose/issues/9330).
-- Added support for ppc64le architecture for docker compose binary.
-- Fixed search/replace typo in `--no-TTY` documentation.
-
-For the full change log or additional information, check the [Compose repository 2.5.0 release page](https://github.com/docker/compose/releases/tag/v2.5.0).
-
-## 2.4.1
-
-{{< release-date date="2022-04-04" >}}
-
-### Bug fixes and enhancements
-
-- Passed the `--rm flag` value as is to the Docker CLI when running a container with this flag. Fixes [#9314](https://github.com/docker/compose/issues/9314).
-- Added ssh config to the build options when building an image from a `docker compose up` command. Fixes [#9338](https://github.com/docker/compose/issues/9338).
-- Added inspection to container checking if a TTY is required. Running services with `tty:true` specified now show console output. Fixes [#9288](https://github.com/docker/compose/issues/9288).
-
-For the full change log or additional information, check the [Compose repository 2.4.1 release page](https://github.com/docker/compose/releases/tag/v2.4.1).
-
-
-## 2.4.0
-
-{{< release-date date="2022-04-1" >}}
-
-### Updates
-
-- Dependencies update: Bumped buildx to v0.8.1. to fix possible panic on handling build context scanning errors.
-
-### Bug fixes and enhancements
-
-- Passed the interactive flag '-i' from the Compose CLI to the Docker one to run exec command. Fixes [#9315](https://github.com/docker/compose/issues/9315).
-- Compose commands now take the value of `COMPOSE_PROJECT_NAME` environmental variable into consideration. Fixes [#9316](https://github.com/docker/compose/issues/9316).
-- Fixed issue of `compose down` command that when executed in contexts without any services started or resources to be deleted was returning an error. Error was due to command trying to delete an inexistent default network. Fixes [#9333](https://github.com/docker/compose/issues/9333).
-- Introduced support for `cache_from`, `cache_to`, `no_cache` and `pull` attributes in the build section. These attributes allow forcing a complete rebuild from sources and checking with registry for images used. These changes provide the basis for offering `--no-cache` and `--pull` options for compose build (or equivalent) command down the line.
-- Introduced support of an `--ssh` flag for the `build` command from CLI and Compose file. Fixes [#7025](https://github.com/docker/compose/issues/7025).
-- Fixed typo in `--ssh` flag description. Related to [#7025](https://github.com/docker/compose/issues/7025).
-- Pinned Kubernetes dependencies to the same version as in buildx.
-- Passed the interactive flag from the Compose CLI to the Docker one to run exec command.
-- Fixed race condition on start-stop end-to-end tests running in parallel.
-- Removed code regarding an obsolete warning.
-- Vendor: github.com/containerd/containerd v1.6.2. Includes a fix for CVE-2022-24769 (doesn't affect our codebase).
-
-For the full change log or additional information, check the [Compose repository 2.4.0 release page](https://github.com/docker/compose/releases/tag/v2.4.0).
-
-
-## 2.3.4
-
-{{< release-date date="2022-03-25" >}}
-
-### New
-
-- Introduced changes to use RunExec and RunStart from docker/cli to handle all the interactive/tty/* terminal logic.
-
-### Removed
-
-- Removed a container with no candidate now produces a warning instead of an error. Fixes [#9255](https://github.com/docker/compose/issues/9255).
-- Removed the "Deprecated" mentions from -i and -t options to run and exec commands. These options are on by default and in use. Fixes [#9229](https://github.com/docker/compose/pull/9229#discussion_r819730788).
-- Removed the "Deprecated" mention from the --filter flag, to keep consistency with other commands.
-- Removed the need to get the original compose.yaml file to run 'docker compose kill'.
-
-### Updates
-
-- Dependencies update: Bumped github.com/spf13/cobra from 1.3.0 to 1.4.0. Cobra library no longer requires Viper and all of its indirect dependencies [See cobra's release page](https://github.com/spf13/cobra/releases).
-- Dependencies update: Bumped buildx from v0.7.1 to v0.8.0.
-
-### Bug fixes and enhancements
-
-- Recovered behavior for 'compose up -d' of recreating containers of compose file images with refreshed content. Fixes [#9259](https://github.com/docker/compose/issues/9259).
-- Docker compose --status, --filter and --format flags documentation updates.
-- `docker compose down -v` now does not remove external volumes and networks as per the option's expected and documented behavior. Whenever project is specified it is also now used to enforce down to only remove resources listed in compose.yaml file.
-Fixes [#9172](https://github.com/docker/compose/issues/9172), [#9145](https://github.com/docker/compose/issues/9145).
-- Changed Compose API reference docs automation to pick up diffs code vs. docs.
-
-For the full change log or additional information, check the [Compose repository 2.3.4 release page](https://github.com/docker/compose/releases/tag/v2.3.4).
-
-## Other Releases
-
-(2022-03-8 to 2022-04-14)
-
-For the releases later than 1.29.2 and earlier than 2.3.4, please check the [Compose repository release pages](https://github.com/docker/compose/releases).
-
-## 1.29.2
-
-(2021-05-10)
-
-### Miscellaneous
-
-- Removed the prompt to use `docker-compose` in the `up` command.
-
-- Bumped `py` to `1.10.0` in `requirements-indirect.txt`.
-
-## 1.29.1
-
-(2021-04-13)
-
-### Bugs
-
-- Fixed invalid handler warning on Windows builds.
-
-- Fixed config hash to trigger container re-creation on IPC mode updates.
-
-- Fixed conversion map for `placement.max_replicas_per_node`.
-
-- Removed extra scan suggestion on build.
-
-## 1.29.0
-
-(2021-04-06)
-
-### Features
-
-- Added profile filter to `docker-compose config`.
-
-- Added a `depends_on` condition to wait for successful service completion.
-
-### Miscellaneous
-
-- Added an image scan message on build.
-
-- Updated warning message for `--no-ansi` to mention `--ansi never` as alternative.
-
-- Bumped docker-py to 5.0.0.
-
-- Bumped PyYAML to 5.4.1.
-
-- Bumped python-dotenv to 0.17.0.
-
-## 1.28.6
-
-(2021-03-23)
-
-### Bug fixes
-
-- Made `--env-file` relative to the current working directory. Environment file paths set with `--env-file` are now relative to the current working directory and override the default `.env` file located in the project directory.
-
-- Fixed missing service property `storage_opt` by updating the Compose schema.
-
-- Fixed build `extra_hosts` list format.
-
-- Removed additional error message on `exec`.
-
-### Miscellaneous
-
-- Added `compose.yml` and `compose.yaml` to the default filename list.
-
-## 1.28.5
-
-(2021-02-26)
-
-### Bugs
-
-- Fixed the OpenSSL version mismatch error when shelling out to the SSH client (via bump to docker-py 4.4.4 which contains the fix).
-
-- Added missing build flags to the native builder: `platform`, `isolation` and `extra_hosts`.
-
-- Removed info message on native build.
-
-- Fixed the log fetching bug when service logging driver is set to 'none'.
-
-## 1.28.4
-
-(2021-02-18)
-
-### Bug fixes
-
-- Fixed SSH port parsing by bumping docker-py to 4.4.3.
-
-### Miscellaneous
-
-- Bumped Python to 3.7.10.
-
-## 1.28.3
-
-(2021-02-17)
-
-### Bug fixes
-
-- Fixed SSH hostname parsing when it contains a leading 's'/'h', and removed the quiet option that was hiding the error (via docker-py bump to 4.4.2).
-
-- Fixed key error for `--no-log-prefix` option.
-
-- Fixed incorrect CLI environment variable name for service profiles: `COMPOSE_PROFILES` instead of `COMPOSE_PROFILE`.
-
-- Fixed the fish completion.
-
-### Miscellaneous
-
-- Bumped cryptography to 3.3.2.
-
-- Removed the log driver filter.
-
-For a list of PRs and issues fixed in this release, see [Compose 1.28.3](https://github.com/docker/compose/milestone/53?closed=1).
-
-## 1.28.2
-
-(2021-01-26)
-
-### Bug fixes
-
-- Revert to Python 3.7 bump for Linux static builds
-
-- Add bash completion for `docker-compose logs|up --no-log-prefix`
-
-### Miscellaneous
-
-- CI setup update
-
-## 1.28.0
-
-(2021-01-20)
-
-### Features
-
-- Added support for NVIDIA GPUs through device requests.
-
-- Added support for service profiles.
-
-- Changed the SSH connection approach to the Docker CLI by shelling out to the local SSH client. Set the `COMPOSE_PARAMIKO_SSH=1` environment variable to enable the old behavior.
-
-- Added a flag to disable log prefix.
-
-- Added a flag for ANSI output control.
-
-- Docker Compose now uses the native Docker CLI's `build` command when building images. Set the `COMPOSE_DOCKER_CLI_BUILD=0` environment variable to disable this feature.
-
-### Bug fixes
-
-- Made `parallel_pull=True` by default.
-
-- Restored the warning for configs in non-swarm mode.
-
-- Took `--file` into account when defining `project_dir`.
-
-- Fixed a service attach bug on `compose up`.
-
-### Miscellaneous
-
-- Added usage metrics.
-
-- Synced schema with COMPOSE specification.
-
-- Improved failure report for missing mandatory environment variables.
-
-- Bumped `attrs` to 20.3.0.
-
-- Bumped `more_itertools` to 8.6.0.
-
-- Bumped `cryptograhy` to 3.2.1.
-
-- Bumped `cffi` to 1.14.4.
-
-- Bumped `virtualenv` to 20.2.2.
-
-- Bumped `bcrypt` to 3.2.0.
-
-- Bumped GitPython to 3.1.11.
-
-- Bumped `docker-py` to 4.4.1.
-
-- Bumped Python to 3.9.
-
-- Linux: bumped Debian base image from stretch to buster (required for Python 3.9).
-
-- macOS: Bumped OpenSSL 1.1.1g to 1.1.1h, and Python 3.7.7 to 3.9.0.
-
-- Bumped PyInstaller to 4.1.
-
-- Relaxed the restriction on base images to latest minor.
-
-- Updated READMEs.
-
-## 1.27.4
-
-(2020-09-24)
-
-### Bug fixes
-
-- Removed path checks for bind mounts.
-
-- Fixed port rendering to output long form syntax for non-v1.
-
-- Added protocol to the Docker socket address.
-
-## 1.27.3
-
-(2020-09-16)
-
-### Bug fixes
-
-- Merged `max_replicas_per_node` on `docker-compose config`.
-
-- Fixed `depends_on` serialization on `docker-compose config`.
-
-- Fixed scaling when some containers are not running on `docker-compose up`.
-
-- Enabled relative paths for `driver_opts.device` for `local` driver.
-
-- Allowed strings for `cpus` fields.
-
-## 1.27.2
-
-(2020-09-10)
-
-### Bug fixes
-
-- Fixed bug on `docker-compose run` container attach.
-
-## 1.27.1
-
-(2020-09-10)
-
-### Bug fixes
-
-- Fixed `docker-compose run` when `service.scale` is specified.
-
-- Allowed the `driver` property for external networks as a temporary workaround for the Swarm network propagation issue.
-
-- Pinned the new internal schema version to `3.9` as the default.
-
-- Preserved the version number configured in the Compose file.
-
-## 1.27.0
-
-(2020-09-07)
-
-### Features
-
-- Merged 2.x and 3.x Compose formats and aligned with `COMPOSE_SPEC` schema.
-
-- Implemented service mode for `ipc`.
-
-- Passed `COMPOSE_PROJECT_NAME` environment variable in container mode.
-
-- Made `run` behave in the same way as `up`.
-
-- Used `docker build` on `docker-compose run` when `COMPOSE_DOCKER_CLI_BUILD` environment variable is set.
-
-- Used the docker-py default API version for engine queries (`auto`).
-
-- Parsed `network_mode` on build.
-
-### Bug fixes
-
-- Ignored build context path validation when building is not required.
-
-- Fixed float to bytes conversion via docker-py bump to 4.3.1.
-
-- Fixed the scale bug when the deploy section is set.
-
-- Fixed `docker-py` bump in `setup.py`.
-
-- Fixed experimental build failure detection.
-
-- Fixed context propagation to the Docker CLI.
-
-### Miscellaneous
-
-- Bumped `docker-py` to 4.3.1.
-
-- Bumped `tox` to 3.19.0.
-
-- Bumped `virtualenv` to 20.0.30.
-
-- Added script for Docs synchronization.
-
-## 1.26.2
-
-(2020-07-02)
-
-### Bug fixes
-
-- Enforced `docker-py` 4.2.2 as minimum version when installing with pip.
-
-## 1.26.1
-
-(2020-06-30)
-
-### Features
-
-- Bumped `docker-py` from 4.2.1 to 4.2.2.
-
-### Bug fixes
-
-- Enforced `docker-py` 4.2.1 as minimum version when installing with pip.
-
-- Fixed context load for non-docker endpoints.
-
-## 1.26.0
-
-(2020-06-03)
-
-### Features
-
-- Added `docker context` support.
-
-- Added missing test dependency `ddt` to `setup.py`.
-
-- Added `--attach-dependencies` to command `up` for attaching to dependencies.
-
-- Allowed compatibility option with `COMPOSE_COMPATIBILITY` environment variable.
-
-- Bumped `Pytest` to 5.3.4 and add refactor compatibility with the new version.
-
-- Bumped `OpenSSL` from 1.1.1f to 1.1.1g.
-
-- Bumped `certifi` from 2019.11.28 to 2020.4.5.1.
-
-- Bumped `docker-py` from 4.2.0 to 4.2.1.
-
-### Bug fixes
-
-- Properly escaped values coming from `env_files`.
-
-- Synchronized compose-schemas with upstream (docker/cli).
-
-- Removed `None` entries on exec command.
-
-- Added `distribution` package to get distribution information.
-
-- Added `python-dotenv` to delegate `.env` file processing.
-
-- Stopped adjusting output on terminal width when piped into another command.
-
-- Showed an error message when `version` attribute is malformed.
-
-- Fixed HTTPS connection when `DOCKER_HOST` is remote.
-
-## 1.25.5
-
-(2020-04-10)
-
-### Features
-
-- Bumped OpenSSL from 1.1.1d to 1.1.1f.
-
-- Added Compose version 3.8.
-
-  - Limited service scale to the size specified by the field `deploy.placement.max_replicas_per_node`.
-
-## 1.25.4
-
-(2020-02-03)
-
-### Bug fixes
-
-- Fixed the CI script to enforce the minimal MacOS version to 10.11.
-
-- Fixed docker-compose exec for keys with no value on environment files.
-
-## 1.25.3
-
-(2020-01-23)
-
-### Bug fixes
-
-- Fixed the CI script to enforce the compilation with Python3.
-
-- Updated the binary's sha256 on the release page.
-
-## 1.25.2
-
-(2020-01-20)
-
-### New features
-
-- Docker Compose now allows the compatibility option with `COMPOSE_COMPATIBILITY` environment variable.
-
-### Bug fixes
-
-- Fixed an issue that caused Docker Compose to crash when the `version` field was set to an invalid value. Docker Compose now displays an error message when invalid values are used in the version field.
-
-- Fixed an issue that caused Docker Compose to render messages incorrectly when running commands outside a terminal.
-
-## 1.25.1
-
-(2020-01-06)
-
-### Bugfixes
-
-- Decoded the `APIError` explanation to Unicode before using it to create and start a container.
-
-- Docker Compose discards `com.docker.compose.filepaths` labels that have `None` as value. This usually occurs when labels originate from stdin.
-
-- Added OS X binary as a directory to solve slow start up time issues caused by macOS Catalina binary scan.
-
-- Passed the `HOME` environment variable in container mode when running with `script/run/run.sh`.
-
-- Docker Compose now reports images that cannot be pulled, however, are required to be built.
-
-## 1.25.0
-
-(2019-11-18)
-
-### New features
-
-- Set no-colors to true by changing `CLICOLOR` env variable to `0`.
-
-- Added working directory, config files, and env file to service labels.
-
-- Added ARM build dependencies.
-
-- Added BuildKit support (use `DOCKER_BUILDKIT=1` and `COMPOSE_DOCKER_CLI_BUILD=1`).
-
-- Raised Paramiko to version 2.6.0.
-
-- Added the following tags: `docker-compose:latest`, `docker-compose:<version>-alpine`, and `docker-compose:<version>-debian`.
-
-- Raised `docker-py` to version 4.1.0.
-
-- Enhanced support for `requests`, up to version 2.22.0.
-
-- Removed empty tag on `build:cache_from`.
-
-- `Dockerfile` enhancement that provides for the generation of `libmusl` binaries for Alpine Linux.
-
-- Pulling only of images that cannot be built.
-
-- The `scale` attribute now accepts `0` as a value.
-
-- Added a `--quiet` option and a `--no-rm` option to the `docker-compose build` command.
-
-- Added a `--no-interpolate` option to the `docker-compose config` command.
-
-- Raised OpenSSL for MacOS build from `1.1.0` to `1.1.1c`.
-
-- Added support for the `docker-compose.yml` file's `credential_spec` configuration option.
-
-- Resolution of digests without having to pull the image.
-
-- Upgraded `pyyaml` to version `4.2b1`.
-
-- Lowered the severity to `warning` for instances in which `down` attempts to remove a non-existent image.
-
-- Mandated the use of improved API fields for project events, when possible.
-
-- Updated `setup.py` for modern `pypi/setuptools`, and removed `pandoc` dependencies.
-
-- Removed `Dockerfile.armhf`, which is no longer required.
-
-### Bug fixes
-
-- Made container service color deterministic, including the removal of the color red.
-
-- Fixed non-ASCII character errors (Python 2 only).
-
-- Changed image sizing to decimal format, to align with Docker CLI.
-
-- `tty` size acquired through Python POSIX support.
-
-- Fixed same file `extends` optimization.
-
-- Fixed `stdin_open`.
-
-- Fixed the issue of `--remove-orphans` being ignored encountered during use with `up --no-start` option.
-
-- Fixed `docker-compose ps --all` command.
-
-- Fixed the `depends_on` dependency recreation behavior.
-
-- Fixed bash completion for the `docker-compose build --memory` command.
-
-- Fixed the misleading environmental variables warning that occurs when the `docker-compose exec` command is performed.
-
-- Fixed the failure check in the `parallel_execute_watch function`.
-
-- Fixed the race condition that occurs following the pulling of an image.
-
-- Fixed error on duplicate mount points (a configuration error message now displays).
-
-- Fixed the merge on `networks` section.
-
-- Compose container is always connected to `stdin` by default.
-
-- Fixed the presentation of failed services on the `docker-compose start` command when containers are not available.
-
-## 1.24.1
-
-(2019-06-24)
-
-This release contains minor improvements and bug fixes.
-
-## 1.24.0
-
-(2019-03-28)
-
-### Features
-
-- Added support for connecting to the Docker Engine using the `ssh` protocol.
-
-- Added an `--all` flag to `docker-compose ps` to include stopped one-off containers
-  in the command's output.
-
-- Added bash completion for `ps --all|-a`.
-
-- Added support for credential_spec.
-
-- Added `--parallel` to `docker build`'s options in `bash` and `zsh` completion.
-
-### Bug fixes
-
-- Fixed a bug where some valid credential helpers weren't properly handled by Compose
-  when attempting to pull images from private registries.
-
-- Fixed an issue where the output of `docker-compose start` before containers were created
-  was misleading.
-
-- Compose will no longer accept whitespace in variable names sourced from environment files.
-  This matches the Docker CLI behavior.
-
-- Compose will now report a configuration error if a service attempts to declare
-  duplicate mount points in the volumes section.
-
-- Fixed an issue with the containerized version of Compose that prevented users from
-  writing to stdin during interactive sessions started by `run` or `exec`.
-
-- One-off containers started by `run` no longer adopt the restart policy of the service,
-  and are instead set to never restart.
-
-- Fixed an issue that caused some container events to not appear in the output of
-  the `docker-compose events` command.
-
-- Missing images will no longer stop the execution of `docker-compose down` commands. A warning is
-  now displayed instead.
-
-- Force `virtualenv` version for macOS CI.
-
-- Fixed merging of Compose files when network has `None` config.
-
-- Fixed `CTRL+C` issues by enabling `bootloader_ignore_signals` in `pyinstaller`.
-
-- Bumped `docker-py` version to `3.7.2` to fix SSH and proxy configuration issues.
-
-- Fixed release script and some typos on release documentation.
-
-## 1.23.2
-
-(2018-11-28)
-
-### Bug fixes
-
-- Reverted a 1.23.0 change that appended random strings to container names
-  created by `docker-compose up`, causing addressability issues.
-  > [!NOTE]
-  >
-  > Containers created by `docker-compose run` will continue to use randomly generated names to avoid collisions during parallel runs.
-
-- Fixed an issue where some `dockerfile` paths would fail unexpectedly when
-  attempting to build on Windows.
-
-- Fixed a bug where build context URLs would fail to build on Windows.
-
-- Fixed a bug that caused `run` and `exec` commands to fail for some otherwise
-  accepted values of the `--host` parameter.
-
-- Fixed an issue where overrides for the `storage_opt` and `isolation` keys in
-  service definitions weren't properly applied.
-
-- Fixed a bug where some invalid Compose files would raise an uncaught
-  exception during validation.
-
-## 1.23.1
-
-(2018-11-01)
-
-### Bug fixes
-
-- Fixed a bug where working with containers created with a version of Compose earlier than `1.23.0`
-  would cause unexpected crashes.
-
-- Fixed an issue where the behavior of the `--project-directory` flag would
-  vary depending on which subcommand was used.
-
-## 1.23.0
-
-(2018-10-30)
-
-### Important note
-
-The default naming scheme for containers created by Compose in this version
-has changed from `<project>_<service>_<index>` to
-`<project>_<service>_<index>_<slug>`, where `<slug>` is a randomly-generated
-hexadecimal string. Please make sure to update scripts relying on the old
-naming scheme accordingly before upgrading.
-
-### Features
-
-- Logs for containers restarting after a crash will now appear in the output
-  of the `up` and `logs` commands.
-
-- Added `--hash` option to the `docker-compose config` command, allowing users
-  to print a hash string for each service's configuration to facilitate rolling
-  updates.
-
-- Added `--parallel` flag to the `docker-compose build` command, allowing
-  Compose to build up to 5 images simultaneously.
-
-- Output for the `pull` command now reports status / progress even when pulling
-  multiple images in parallel.
-
-- For images with multiple names, Compose will now attempt to match the one
-  present in the service configuration in the output of the `images` command.
-
-### Bug fixes
-
-- Fixed an issue where parallel `run` commands for the same service would fail due to name
-  collisions.
-
-- Fixed an issue where paths longer than 260 characters on Windows clients would
-  cause `docker-compose build` to fail.
-
-- Fixed a bug where attempting to mount `/var/run/docker.sock` with
-  Docker Desktop for Windows would result in failure.
-
-- The `--project-directory` option is now used by Compose to determine where to
-  look for the `.env` file.
-
-- `docker-compose build` no longer fails when attempting to pull an image with
-  credentials provided by the ***gcloud credential helper***.
-
-- Fixed the `--exit-code-from` option in `docker-compose up` to always report
-  the actual exit code even when the watched container is not the cause of the
-  exit.
-
-- Fixed an issue that would prevent recreating a service in some cases where
-  a volume would be mapped to the same mountpoint as a volume declared within the Dockerfile for that image.
-
-- Fixed a bug that caused hash configuration with multiple networks to be
-  inconsistent, causing some services to be unnecessarily restarted.
-
-- Fixed a bug that would cause failures with variable substitution for services
-  with a name containing one or more dot characters.
-
-- Fixed a pipe handling issue when using the containerized version of Compose.
-
-- Fixed a bug causing `external: false` entries in the Compose file to be
-  printed as `external: true` in the output of `docker-compose config`.
-
-- Fixed a bug where issuing a `docker-compose pull` command on services
-  without a defined image key would cause Compose to crash.
-
-- Volumes and binds are now mounted in the order they are declared in the
-  service definition.
-
-### Miscellaneous
-
-- The `zsh` completion script has been updated with new options, and no
-  longer suggests container names where service names are expected.
-
-## 1.22.0
-
-(2018-07-17)
-
-### New features
-
-#### Compose format version 3.7
-
-- Introduced version 3.7 of the `docker-compose.yml` specification.
-  This version requires Docker Engine 18.06.0 or above.
-
-- Added support for `rollback_config` in the deploy configuration
-
-- Added support for the `init` parameter in service configurations
-
-- Added support for extension fields in service, network, volume, secret,
-  and config configurations
-
-#### Compose format version 2.4
-
-- Added support for extension fields in service, network,
-  and volume configurations
-
-### Bug fixes
-
-- Fixed a bug that prevented deployment with some Compose files when
-  `DOCKER_DEFAULT_PLATFORM` was set
-
-- Compose will no longer try to create containers or volumes with
-  invalid starting characters
-
-- Fixed several bugs that prevented Compose commands from working properly
-  with containers created with an older version of Compose
-
-- Fixed an issue with the output of `docker-compose config` with the
-  `--compatibility-mode` flag enabled when the source file contains
-  attachable networks
-
-- Fixed a bug that prevented the `gcloud` credential store from working
-  properly when used with the Compose binary on UNIX
-
-- Fixed a bug that caused connection errors when trying to operate
-  over a non-HTTPS TCP connection on Windows
-
-- Fixed a bug that caused builds to fail on Windows if the Dockerfile
-  was located in a subdirectory of the build context
-
-- Fixed an issue that prevented proper parsing of UTF-8 BOM encoded
-  Compose files on Windows
-
-- Fixed an issue with handling of the double-wildcard (`**`) pattern in `.dockerignore` files when using `docker-compose build`
-
-- Fixed a bug that caused auth values in legacy `.dockercfg` files to be ignored
-- `docker-compose build` will no longer attempt to create image names starting with an invalid character
-
-## 1.21.2
-
-(2018-05-03)
-
-### Bug fixes
-
-- Fixed a bug where the ip_range attribute in IPAM configs was prevented
-  from passing validation
-
-## 1.21.1
-
-(2018-04-27)
-
-### Bug fixes
-
-- In 1.21.0, we introduced a change to how project names are sanitized for
-  internal use in resource names. This caused issues when manipulating an
-  existing, deployed application whose name had changed as a result.
-  This release properly detects resources using "legacy" naming conventions.
-
-- Fixed an issue where specifying an in-context Dockerfile using an absolute
-  path would fail despite being valid.
-
-- Fixed a bug where IPAM option changes were incorrectly detected, preventing
-  redeployments.
-
-- Validation of v2 files now properly checks the structure of IPAM configs.
-
-- Improved support for credentials stores on Windows to include binaries using
-  extensions other than `.exe`. The list of valid extensions is determined by
-  the contents of the `PATHEXT` environment variable.
-
-- Fixed a bug where Compose would generate invalid binds containing duplicate
-  elements with some v3.2 files, triggering errors at the Engine level during
-  deployment.
-
-## 1.21.0
-
-(2018-04-11)
-
-### New features
-
-#### Compose file version 2.4
-
-- Introduced version 2.4 of the `docker-compose.yml` specification.
-  This version requires Docker Engine 17.12.0 or above.
-
-- Added support for the `platform` parameter in service definitions.
-  If supplied, the parameter is also used when performing build for the
-  service.
-
-#### Compose file version 2.2 and up
-
-- Added support for the `cpu_rt_period` and `cpu_rt_runtime` parameters
-  in service definitions (2.x only).
-
-#### Compose file version 2.1 and up
-
-- Added support for the `cpu_period` parameter in service definitions
-  (2.x only).
-
-- Added support for the `isolation` parameter in service build configurations.
-  Additionally, the `isolation` parameter in service definitions is used for
-  builds as well if no `build.isolation` parameter is defined. (2.x only)
-
-#### All formats
-
-- Added support for the `--workdir` flag in `docker-compose exec`.
-
-- Added support for the `--compress` flag in `docker-compose build`.
-
-- `docker-compose pull` is now performed in parallel by default. You can
-  opt out using the `--no-parallel` flag. The `--parallel` flag is now
-  deprecated and will be removed in a future version.
-
-- Dashes and underscores in project names are no longer stripped out.
-
-- `docker-compose build` now supports the use of Dockerfile from outside
-  the build context.
-
-### Bug fixes
-
-- Compose now checks that the volume's configuration matches the remote
-  volume, and errors out if a mismatch is detected.
-
-- Fixed a bug that caused Compose to raise unexpected errors when attempting
-  to create several one-off containers in parallel.
-
-- Fixed a bug with argument parsing when using `docker-machine config` to
-  generate TLS flags for `exec` and `run` commands.
-
-- Fixed a bug where variable substitution with an empty default value
-  (e.g. `${VAR:-}`) would print an incorrect warning.
-
-- Improved resilience when encoding of the Compose file doesn't match the
-  system's. Users are encouraged to use UTF-8 when possible.
-
-- Fixed a bug where external overlay networks in Swarm would be incorrectly
-  recognized as inexistent by Compose, interrupting otherwise valid
-  operations.
-
-## 1.20.0
-
-(2018-03-20)
-
-### New features
-
-#### Compose file version 3.6
-
-- Introduced version 3.6 of the `docker-compose.yml` specification.
-  This version must be used with Docker Engine 18.02.0 or above.
-
-- Added support for the `tmpfs.size` property in volume mappings
-
-#### Compose file version 3.2 and up
-
-- The `--build-arg` option can now be used without specifying a service
-  in `docker-compose build`
-
-#### Compose file version 2.3
-
-- Added support for `device_cgroup_rules` in service definitions
-
-- Added support for the `tmpfs.size` property in long-form volume mappings
-
-- The `--build-arg` option can now be used without specifying a service
-  in `docker-compose build`
-
-#### All formats
-
-- Added a `--log-level` option to the top-level `docker-compose` command.
-  Accepted values are `debug`, `info`, `warning`, `error`, `critical`.
-  Default log level is `info`
-
-- `docker-compose run` now allows users to unset the container's entrypoint
-
-- Proxy configuration found in the `~/.docker/config.json` file now populates
-  environment and build args for containers created by Compose
-
-- Added the `--use-aliases` flag to `docker-compose run`, indicating that
-  network aliases declared in the service's config should be used for the
-  running container
-
-- Added the `--include-deps` flag to `docker-compose pull`
-
-- `docker-compose run` now kills and removes the running container upon
-  receiving `SIGHUP`
-
-- `docker-compose ps` now shows the containers' health status if available
-
-- Added the long-form `--detach` option to the `exec`, `run` and `up`
-  commands
-
-### Bug fixes
-
-- Fixed `.dockerignore` handling, notably with regard to absolute paths
-  and last-line precedence rules
-
-- Fixed an issue where Compose would make costly DNS lookups when connecting
-  to the Engine when using Docker For Mac
-
-- Fixed a bug introduced in 1.19.0 which caused the default certificate path
-  to not be honored by Compose
-
-- Fixed a bug where Compose would incorrectly check whether a symlink's
-  destination was accessible when part of a build context
-
-- Fixed a bug where `.dockerignore` files containing lines of whitespace
-  caused Compose to error out on Windows
-
-- Fixed a bug where `--tls*` and `--host` options wouldn't be properly honored
-  for interactive `run` and `exec` commands
-
-- A `seccomp:<filepath>` entry in the `security_opt` config now correctly
-  sends the contents of the file to the engine
-
-- ANSI output for `up` and `down` operations should no longer affect the wrong
-  lines
-
-- Improved support for non-unicode locales
-
-- Fixed a crash occurring on Windows when the user's home directory name
-  contained non-ASCII characters
-
-- Fixed a bug occurring during builds caused by files with a negative `mtime`
-  values in the build context
-
-- Fixed an encoding bug when streaming build progress
-
-## 1.19.0
-
-(2018-02-07)
-
-### Breaking changes
-
-- On UNIX platforms, interactive `run` and `exec` commands now require
-  the `docker` CLI to be installed on the client by default. To revert
-  to the previous behavior, users may set the `COMPOSE_INTERACTIVE_NO_CLI`
-  environment variable.
-
-### New features
-
-#### Compose file version 3.x
-
-- The output of the `config` command should now merge `deploy` options from
-  several Compose files in a more accurate manner
-
-#### Compose file version 2.3
-
-- Added support for the `runtime` option in service definitions
-
-#### Compose file version 2.1 and up
-
-- Added support for the `${VAR:?err}` and `${VAR?err}` variable interpolation
-  syntax to indicate mandatory variables
-
-#### Compose file version 2.x
-
-- Added `priority` key to service network mappings, allowing the user to
-  define in which order the specified service will connect to each network
-
-#### All formats
-
-- Added `--renew-anon-volumes` (shorthand `-V`) to the `up` command,
-  preventing Compose from recovering volume data from previous containers for
-  anonymous volumes
-
-- Added limit for number of simultaneous parallel operations, which should
-  prevent accidental resource exhaustion of the server. Default is 64 and
-  can be configured using the `COMPOSE_PARALLEL_LIMIT` environment variable
-
-- Added `--always-recreate-deps` flag to the `up` command to force recreating
-  dependent services along with the dependency owner
-
-- Added `COMPOSE_IGNORE_ORPHANS` environment variable to forgo orphan
-  container detection and suppress warnings
-
-- Added `COMPOSE_FORCE_WINDOWS_HOST` environment variable to force Compose
-  to parse volume definitions as if the Docker host was a Windows system,
-  even if Compose itself is currently running on UNIX
-
-- Bash completion should now be able to better differentiate between running,
-  stopped and paused services
-
-### Bug fixes
-
-- Fixed a bug that would cause the `build` command to report a connection
-  error when the build context contained unreadable files or FIFO objects.
-  These file types will now be handled appropriately
-
-- Fixed various issues around interactive `run`/`exec` sessions.
-
-- Fixed a bug where setting TLS options with environment and CLI flags
-  simultaneously would result in part of the configuration being ignored
-
-- Fixed a bug where the DOCKER_TLS_VERIFY environment variable was being
-  ignored by Compose
-
-- Fixed a bug where the `-d` and `--timeout` flags in `up` were erroneously
-  marked as incompatible
-
-- Fixed a bug where the recreation of a service would break if the image
-  associated with the previous container had been removed
-
-- Fixed a bug where updating a mount's target would break Compose when
-  trying to recreate the associated service
-
-- Fixed a bug where `tmpfs` volumes declared using the extended syntax in
-  Compose files using version 3.2 would be erroneously created as anonymous
-  volumes instead
-
-- Fixed a bug where type conversion errors would print a stacktrace instead
-  of exiting gracefully
-
-- Fixed some errors related to unicode handling
-
-- Dependent services no longer get recreated along with the dependency owner
-  if their configuration hasn't changed
-
-- Added better validation of `labels` fields in Compose files. Label values
-  containing scalar types (number, boolean) now get automatically converted
-  to strings
-
-## 1.18.0
-
-(2017-12-18)
-
-### New features
-
-#### Compose file version 3.5
-
-- Introduced version 3.5 of the `docker-compose.yml` specification.
-  This version requires Docker Engine 17.06.0 or above
-
-- Added support for the `shm_size` parameter in build configurations
-
-- Added support for the `isolation` parameter in service definitions
-
-- Added support for custom names for network, secret and config definitions
-
-#### Compose file version 2.3
-
-- Added support for `extra_hosts` in build configuration
-
-- Added support for the [long syntax](/reference/compose-file/legacy-versions.md) for volume entries, as previously introduced in the 3.2 format.
-  Using this syntax will create [mounts](/manuals/engine/storage/bind-mounts.md) instead of volumes.
-
-#### Compose file version 2.1 and up
-
-- Added support for the `oom_kill_disable` parameter in service definitions
-  (2.x only)
-
-- Added support for custom names for network definitions (2.x only)
-
-
-#### All formats
-
-- Values interpolated from the environment will now be converted to the
-  proper type when used in non-string fields.
-
-- Added support for `--label` in `docker-compose run`
-
-- Added support for `--timeout` in `docker-compose down`
-
-- Added support for `--memory` in `docker-compose build`
-
-- Setting `stop_grace_period` in service definitions now also sets the
-  container's `stop_timeout`
-
-### Bug fixes
-
-- Fixed an issue where Compose was still handling service hostname according
-  to legacy engine behavior, causing hostnames containing dots to be cut up
-
-- Fixed a bug where the `X-Y:Z` syntax for ports was considered invalid
-  by Compose
-
-- Fixed an issue with CLI logging causing duplicate messages and inelegant
-  output to occur
-
-- Fixed an issue that caused `stop_grace_period` to be ignored when using
-  multiple Compose files
-
-- Fixed a bug that caused `docker-compose images` to crash when using
-  untagged images
-
-- Fixed a bug where the valid `${VAR:-}` syntax would cause Compose to
-  error out
-
-- Fixed a bug where `env_file` entries using an UTF-8 BOM were being read
-  incorrectly
-
-- Fixed a bug where missing secret files would generate an empty directory
-  in their place
-
-- Fixed character encoding issues in the CLI's error handlers
-
-- Added validation for the `test` field in healthchecks
-
-- Added validation for the `subnet` field in IPAM configurations
-
-- Added validation for `volumes` properties when using the long syntax in
-  service definitions
-
-- The CLI now explicit prevents using `-d` and `--timeout` together
-  in `docker-compose up`
-
-## 1.17.0
-
-(2017-11-01)
-
-### New features
-
-#### Compose file version 3.4
-
-- Introduced version 3.4 of the `docker-compose.yml` specification.
-  This version requires to be used with Docker Engine 17.06.0 or above.
-
-- Added support for `cache_from`, `network` and `target` options in build
-  configurations
-
-- Added support for the `order` parameter in the `update_config` section
-
-- Added support for setting a custom name in volume definitions using
-  the `name` parameter
-
-#### Compose file version 2.3
-
-- Added support for `shm_size` option in build configuration
-
-#### Compose file version 2.x
-
-- Added support for extension fields (`x-*`). Also available for v3.4 files
-
-#### All formats
-
-- Added new `--no-start` to the `up` command, allowing users to create all
-  resources (networks, volumes, containers) without starting services.
-  The `create` command is deprecated in favor of this new option
-
-### Bug fixes
-
-- Fixed a bug where `extra_hosts` values would be overridden by extension
-  files instead of merging together
-
-- Fixed a bug where the validation for v3.2 files would prevent using the
-  `consistency` field in service volume definitions
-
-- Fixed a bug that would cause a crash when configuration fields expecting
-  unique items would contain duplicates
-
-- Fixed a bug where mount overrides with a different mode would create a
-  duplicate entry instead of overriding the original entry
-
-- Fixed a bug where build labels declared as a list wouldn't be properly
-  parsed
-
-- Fixed a bug where the output of `docker-compose config` would be invalid
-  for some versions if the file contained custom-named external volumes
-
-- Improved error handling when issuing a build command on Windows using an
-  unsupported file version
-
-- Fixed an issue where networks with identical names would sometimes be
-  created when running `up` commands concurrently.
-
-## 1.16.0
-
-(2017-08-31)
-
-### New features
-
-#### Compose file version 2.3
-
-- Introduced version 2.3 of the `docker-compose.yml` specification.
-  This version requires to be used with Docker Engine 17.06.0 or above.
-
-- Added support for the `target` parameter in build configurations
-
-- Added support for the `start_period` parameter in healthcheck
-  configurations
-
-#### Compose file version 2.x
-
-- Added support for the `blkio_config` parameter in service definitions
-
-- Added support for setting a custom name in volume definitions using
-  the `name` parameter (not available for version 2.0)
-
-#### All formats
-
-- Added new CLI flag `--no-ansi` to suppress ANSI control characters in
-  output
-
-### Bug fixes
-
-- Fixed a bug where nested `extends` instructions weren't resolved
-  properly, causing "file not found" errors
-
-- Fixed several issues with `.dockerignore` parsing
-
-- Fixed issues where logs of TTY-enabled services were being printed
-  incorrectly and causing `MemoryError` exceptions
-
-- Fixed a bug where printing application logs would sometimes be interrupted
-  by a `UnicodeEncodeError` exception on Python 3
-
-- The `$` character in the output of `docker-compose config` is now
-  properly escaped
-
-- Fixed a bug where running `docker-compose top` would sometimes fail
-  with an uncaught exception
-
-- Fixed a bug where `docker-compose pull` with the `--parallel` flag
-  would return a `0` exit code when failing
-
-- Fixed an issue where keys in `deploy.resources` were not being validated
-
-- Fixed an issue where the `logging` options in the output of
-  `docker-compose config` would be set to `null`, an invalid value
-
-- Fixed the output of the `docker-compose images` command when an image
-  would come from a private repository using an explicit port number
-
-- Fixed the output of `docker-compose config` when a port definition used
-  `0` as the value for the published port
-
-## 1.15.0
-
-(2017-07-26)
-
-### New features
-
-#### Compose file version 2.2
-
-- Added support for the `network` parameter in build configurations.
-
-#### Compose file version 2.1 and up
-
-- The `pid` option in a service's definition now supports a `service:<name>`
-  value.
-
-- Added support for the `storage_opt` parameter in service definitions.
-  This option is not available for the v3 format
-
-#### All formats
-
-- Added `--quiet` flag to `docker-compose pull`, suppressing progress output
-
-- Some improvements to CLI output
-
-### Bug fixes
-
-- Volumes specified through the `--volume` flag of `docker-compose run` now
-  complement volumes declared in the service's definition instead of replacing
-  them
-
-- Fixed a bug where using multiple Compose files would unset the scale value
-  defined inside the Compose file.
-
-- Fixed an issue where the `credHelpers` entries in the `config.json` file
-  were not being honored by Compose
-
-- Fixed a bug where using multiple Compose files with port declarations
-  would cause failures in Python 3 environments
-
-- Fixed a bug where some proxy-related options present in the user's
-  environment would prevent Compose from running
-
-- Fixed an issue where the output of `docker-compose config` would be invalid
-  if the original file used `Y` or `N` values
-
-- Fixed an issue preventing `up` operations on a previously created stack on
-  Windows Engine.
-
-## 1.14.0
-
-(2017-06-19)
-
-### New features
-
-#### Compose file version 3.3
-
-- Introduced version 3.3 of the `docker-compose.yml` specification.
-  This version requires to be used with Docker Engine 17.06.0 or above.
-  Note: the `credential_spec` and `configs` keys only apply to Swarm services
-  and will be ignored by Compose
-
-#### Compose file version 2.2
-
-- Added the following parameters in service definitions: `cpu_count`,
-  `cpu_percent`, `cpus`
-
-#### Compose file version 2.1
-
-- Added support for build labels. This feature is also available in the
-  2.2 and 3.3 formats.
-
-#### All formats
-
-- Added shorthand `-u` for `--user` flag in `docker-compose exec`
-
-- Differences in labels between the Compose file and remote network
-  will now print a warning instead of preventing redeployment.
-
-### Bug fixes
-
-- Fixed a bug where service's dependencies were being rescaled to their
-  default scale when running a `docker-compose run` command
-
-- Fixed a bug where `docker-compose rm` with the `--stop` flag was not
-  behaving properly when provided with a list of services to remove
-
-- Fixed a bug where `cache_from` in the build section would be ignored when
-  using more than one Compose file.
-
-- Fixed a bug that prevented binding the same port to different IPs when
-  using more than one Compose file.
-
-- Fixed a bug where override files would not be picked up by Compose if they
-  had the `.yaml` extension
-
-- Fixed a bug on Windows Engine where networks would be incorrectly flagged
-  for recreation
-
-- Fixed a bug where services declaring ports would cause crashes on some
-  versions of Python 3
-
-- Fixed a bug where the output of `docker-compose config` would sometimes
-  contain invalid port definitions
-
-## 1.13.0
-
-(2017-05-02)
-
-### Breaking changes
-
-- `docker-compose up` now resets a service's scaling to its default value.
-  You can use the newly introduced `--scale` option to specify a custom
-  scale value
-
-### New features
-
-#### Compose file version 2.2
-
-- Introduced version 2.2 of the `docker-compose.yml` specification. This
-  version requires to be used with Docker Engine 1.13.0 or above
-
-- Added support for `init` in service definitions.
-
-- Added support for `scale` in service definitions. The configuration's value
-  can be overridden using the `--scale` flag in `docker-compose up`.
-  The `scale` command is disabled for this file format
-
-#### Compose file version 2.x
-
-- Added support for `options` in the `ipam` section of network definitions
-
-### Bug fixes
-
-- Fixed a bug where paths provided to compose via the `-f` option were not
-  being resolved properly
-
-- Fixed a bug where the `ext_ip::target_port` notation in the ports section
-  was incorrectly marked as invalid
-
-- Fixed an issue where the `exec` command would sometimes not return control
-  to the terminal when using the `-d` flag
-
-- Fixed a bug where secrets were missing from the output of the `config`
-  command for v3.2 files
-
-- Fixed an issue where `docker-compose` would hang if no internet connection
-  was available
-
-- Fixed an issue where paths containing unicode characters passed via the `-f`
-  flag were causing Compose to crash
-
-- Fixed an issue where the output of `docker-compose config` would be invalid
-  if the Compose file contained external secrets
-
-- Fixed a bug where using `--exit-code-from` with `up` would fail if Compose
-  was installed in a Python 3 environment
-
-- Fixed a bug where recreating containers using a combination of `tmpfs` and
-  `volumes` would result in an invalid config state
-
-## 1.12.0
-
-(2017-04-04)
-
-### New features
-
-#### Compose file version 3.2
-
-- Introduced version 3.2 of the `docker-compose.yml` specification
-
-- Added support for `cache_from` in the `build` section of services
-
-- Added support for the new expanded ports syntax in service definitions
-
-- Added support for the new expanded volumes syntax in service definitions
-
-#### Compose file version 2.1
-
-- Added support for `pids_limit` in service definitions
-
-#### Compose file version 2.0 and up
-
-- Added `--volumes` option to `docker-compose config` that lists named
-  volumes declared for that project
-
-- Added support for `mem_reservation` in service definitions (2.x only)
-
-- Added support for `dns_opt` in service definitions (2.x only)
-
-#### All formats
-
-- Added a new `docker-compose images` command that lists images used by
-  the current project's containers
-
-- Added a `--stop` (shorthand `-s`) option to `docker-compose rm` that stops
-  the running containers before removing them
-
-- Added a `--resolve-image-digests` option to `docker-compose config` that
-  pins the image version for each service to a permanent digest
-
-- Added a `--exit-code-from SERVICE` option to `docker-compose up`. When
-  used, `docker-compose` will exit on any container's exit with the code
-  corresponding to the specified service's exit code
-
-- Added a `--parallel` option to `docker-compose pull` that enables images
-  for multiple services to be pulled simultaneously
-
-- Added a `--build-arg` option to `docker-compose build`
-
-- Added a `--volume <volume_mapping>` (shorthand `-v`) option to
-  `docker-compose run` to declare runtime volumes to be mounted
-
-- Added a `--project-directory PATH` option to `docker-compose` that will
-  affect path resolution for the project
-
-- When using `--abort-on-container-exit` in `docker-compose up`, the exit
-  code for the container that caused the abort will be the exit code of
-  the `docker-compose up` command
-
-- Users can now configure which path separator character they want to use
-  to separate the `COMPOSE_FILE` environment value using the
-  `COMPOSE_PATH_SEPARATOR` environment variable
-
-- Added support for port range to a single port in port mappings, such as
-  `8000-8010:80`.
-
-### Bug fixes
-
-- `docker-compose run --rm` now removes anonymous volumes after execution,
-  matching the behavior of `docker run --rm`.
-
-- Fixed a bug where override files containing port lists would cause a
-  TypeError to be raised
-
-- Fixed a bug where the `deploy` key would be missing from the output of
-  `docker-compose config`
-
-- Fixed a bug where scaling services up or down would sometimes re-use
-  obsolete containers
-
-- Fixed a bug where the output of `docker-compose config` would be invalid
-  if the project declared anonymous volumes
-
-- Variable interpolation now properly occurs in the `secrets` section of
-  the Compose file
-
-- The `secrets` section now properly appears in the output of
-  `docker-compose config`
-
-- Fixed a bug where changes to some networks properties would not be
-  detected against previously created networks
-
-- Fixed a bug where `docker-compose` would crash when trying to write into
-  a closed pipe
-
-- Fixed an issue where Compose would not pick up on the value of
-  COMPOSE_TLS_VERSION when used in combination with command-line TLS flags
-
-## 1.11.2
-
-(2017-02-17)
-
-### Bug fixes
-
-- Fixed a bug that was preventing secrets configuration from being
-  loaded properly
-
-- Fixed a bug where the `docker-compose config` command would fail
-  if the config file contained secrets definitions
-
-- Fixed an issue where Compose on some linux distributions would
-  pick up and load an outdated version of the requests library
-
-- Fixed an issue where socket-type files inside a build folder
-  would cause `docker-compose` to crash when trying to build that
-  service
-
-- Fixed an issue where recursive wildcard patterns `**` were not being
-  recognized in `.dockerignore` files.
-
-## 1.11.1
-
-(2017-02-09)
-
-### Bug fixes
-
-- Fixed a bug where the 3.1 file format was not being recognized as valid
-  by the Compose parser
-
-## 1.11.0
-
-(2017-02-08)
-
-### New Features
-
-#### Compose file version 3.1
-
-- Introduced version 3.1 of the `docker-compose.yml` specification. This
-  version requires Docker Engine 1.13.0 or above. It introduces support
-  for secrets. See the documentation for more information
-
-#### Compose file version 2.0 and up
-
-- Introduced the `docker-compose top` command that displays processes running
-  for the different services managed by Compose.
-
-### Bug fixes
-
-- Fixed a bug where extending a service defining a healthcheck dictionary
-  would cause `docker-compose` to error out.
-
-- Fixed an issue where the `pid` entry in a service definition was being
-  ignored when using multiple Compose files.
-
-## 1.10.1
-
-(2017-02-01)
-
-### Bug fixes
-
-- Fixed an issue where the presence of older versions of the docker-py
-  package would cause unexpected crashes while running Compose
-
-- Fixed an issue where healthcheck dependencies would be lost when
-  using multiple compose files for a project
-
-- Fixed a few issues that made the output of the `config` command
-  invalid
-
-- Fixed an issue where adding volume labels to v3 Compose files would
-  result in an error
-
-- Fixed an issue on Windows where build context paths containing unicode
-  characters were being improperly encoded
-
-- Fixed a bug where Compose would occasionally crash while streaming logs
-  when containers would stop or restart
-
-## 1.10.0
-
-(2017-01-18)
-
-### New Features
-
-#### Compose file version 3.0
-
-- Introduced version 3.0 of the `docker-compose.yml` specification. This
-  version requires to be used with Docker Engine 1.13 or above and is
-  specifically designed to work with the `docker stack` commands.
-
-#### Compose file version 2.1 and up
-
-- Healthcheck configuration can now be done in the service definition using
-  the `healthcheck` parameter
-
-- Containers dependencies can now be set up to wait on positive healthchecks
-  when declared using `depends_on`. See the documentation for the updated
-  syntax.
-
-  > [!NOTE]
-  >
-  > This feature will not be ported to version 3 Compose files.
-
-- Added support for the `sysctls` parameter in service definitions
-
-- Added support for the `userns_mode` parameter in service definitions
-
-- Compose now adds identifying labels to networks and volumes it creates
-
-#### Compose file version 2.0 and up
-
-- Added support for the `stop_grace_period` option in service definitions.
-
-### Bug fixes
-
-- Colored output now works properly on Windows.
-
-- Fixed a bug where docker-compose run would fail to set up link aliases
-  in interactive mode on Windows.
-
-- Networks created by Compose are now always made attachable
-  (Compose files v2.1 and up).
-
-- Fixed a bug where falsy values of `COMPOSE_CONVERT_WINDOWS_PATHS`
-  (`0`, `false`, empty value) were being interpreted as true.
-
-- Fixed a bug where forward slashes in some .dockerignore patterns weren't
-  being parsed correctly on Windows
-
-## 1.9.0
-
-(2016-11-16)
-
-**Breaking changes**
-
-- When using Compose with Docker Toolbox/Machine on Windows, volume paths are
-  no longer converted from `C:\Users` to `/c/Users`-style by default. To
-  re-enable this conversion so that your volumes keep working, set the
-  environment variable `COMPOSE_CONVERT_WINDOWS_PATHS=1`. Users of
-  Docker for Windows are not affected and do not need to set the variable.
-
-### New Features
-
-- Interactive mode for `docker-compose run` and `docker-compose exec` is
-  now supported on Windows platforms. The `docker` binary
-  is required to be present on the system for this feature to work.
-
-- Introduced version 2.1 of the `docker-compose.yml` specification. This
-  version requires to be used with Docker Engine 1.12 or above.
-    - Added support for setting volume labels and network labels in
-  `docker-compose.yml`.
-    - Added support for the `isolation` parameter in service definitions.
-    - Added support for link-local IPs in the service networks definitions.
-    - Added support for shell-style inline defaults in variable interpolation.
-      The supported forms are `${FOO-default}` (fall back if FOO is unset) and
-      `${FOO:-default}` (fall back if FOO is unset or empty).
-
-- Added support for the `group_add` and `oom_score_adj` parameters in
-  service definitions.
-
-- Added support for the `internal` and `enable_ipv6` parameters in network
-  definitions.
-
-- Compose now defaults to using the `npipe` protocol on Windows.
-
-- Overriding a `logging` configuration will now properly merge the `options`
-  mappings if the `driver` values do not conflict.
-
-### Bug fixes
-
-- Fixed several bugs related to `npipe` protocol support on Windows.
-
-- Fixed an issue with Windows paths being incorrectly converted when
-  using Docker on Windows Server.
-
-- Fixed a bug where an empty `restart` value would sometimes result in an
-  exception being raised.
-
-- Fixed an issue where service logs containing unicode characters would
-  sometimes cause an error to occur.
-
-- Fixed a bug where unicode values in environment variables would sometimes
-  raise a unicode exception when retrieved.
-
-- Fixed an issue where Compose would incorrectly detect a configuration
-  mismatch for overlay networks.
-
-## 1.8.1
-
-(2016-09-22)
-
-### Bug fixes
-
-- Fixed a bug where users using a credentials store were not able
-  to access their private images.
-
-- Fixed a bug where users using identity tokens to authenticate
-  were not able to access their private images.
-
-- Fixed a bug where an `HttpHeaders` entry in the docker configuration
-  file would cause Compose to crash when trying to build an image.
-
-- Fixed a few bugs related to the handling of Windows paths in volume
-  binding declarations.
-
-- Fixed a bug where Compose would sometimes crash while trying to
-  read a streaming response from the engine.
-
-- Fixed an issue where Compose would crash when encountering an API error
-  while streaming container logs.
-
-- Fixed an issue where Compose would erroneously try to output logs from
-  drivers not handled by the Engine's API.
-
-- Fixed a bug where options from the `docker-machine config` command would
-  not be properly interpreted by Compose.
-
-- Fixed a bug where the connection to the Docker Engine would
-  sometimes fail when running a large number of services simultaneously.
-
-- Fixed an issue where Compose would sometimes print a misleading
-  suggestion message when running the `bundle` command.
-
-- Fixed a bug where connection errors would not be handled properly by
-  Compose during the project initialization phase.
-
-- Fixed a bug where a misleading error would appear when encountering
-  a connection timeout.
-
-## 1.8.0
-
-(2016-06-14)
-
-### Breaking Changes
-
-- As announced in 1.7.0, `docker-compose rm` now removes containers
-  created by `docker-compose run` by default.
-
-- Setting `entrypoint` on a service now empties out any default
-  command that was set on the image (i.e. any `CMD` instruction in the
-  Dockerfile used to build it). This makes it consistent with
-  the `--entrypoint` flag to `docker run`.
-
-### New Features
-
-- Added `docker-compose bundle`, a command that builds a bundle file
-  to be consumed by the new *Docker Stack* commands in Docker 1.12.
-
-- Added `docker-compose push`, a command that pushes service images
-  to a registry.
-
-- Compose now supports specifying a custom TLS version for
-  interaction with the Docker Engine using the `COMPOSE_TLS_VERSION`
-  environment variable.
-
-### Bug fixes
-
-- Fixed a bug where Compose would erroneously try to read `.env`
-  at the project's root when it is a directory.
-
-- `docker-compose run -e VAR` now passes `VAR` through from the shell
-  to the container, as with `docker run -e VAR`.
-
-- Improved config merging when multiple compose files are involved
-  for several service sub-keys.
-
-- Fixed a bug where volume mappings containing Windows drives would
-  sometimes be parsed incorrectly.
-
-- Fixed a bug in Windows environment where volume mappings of the
-  host's root directory would be parsed incorrectly.
-
-- Fixed a bug where `docker-compose config` would output an invalid
-  Compose file if external networks were specified.
-
-- Fixed an issue where unset buildargs would be assigned a string
-  containing `'None'` instead of the expected empty value.
-
-- Fixed a bug where yes/no prompts on Windows would not show before
-  receiving input.
-
-- Fixed a bug where trying to `docker-compose exec` on Windows
-  without the `-d` option would exit with a stacktrace. This will
-  still fail for the time being, but should do so gracefully.
-
-- Fixed a bug where errors during `docker-compose up` would show
-  an unrelated stacktrace at the end of the process.
-
-- `docker-compose create` and `docker-compose start` show more
-  descriptive error messages when something goes wrong.
-
-## 1.7.1
-
-(2016-05-04)
-
-### Bug fixes
-
-- Fixed a bug where the output of `docker-compose config` for v1 files
-  would be an invalid configuration file.
-
-- Fixed a bug where `docker-compose config` would not check the validity
-  of links.
-
-- Fixed an issue where `docker-compose help` would not output a list of
-  available commands and generic options as expected.
-
-- Fixed an issue where filtering by service when using `docker-compose logs`
-  would not apply for newly created services.
-
-- Fixed a bug where unchanged services would sometimes be recreated in
-  in the up phase when using Compose with Python 3.
-
-- Fixed an issue where API errors encountered during the up phase would
-  not be recognized as a failure state by Compose.
-
-- Fixed a bug where Compose would raise a NameError because of an undefined
-  exception name on non-Windows platforms.
-
-- Fixed a bug where the wrong version of `docker-py` would sometimes be
-  installed alongside Compose.
-
-- Fixed a bug where the host value output by `docker-machine config default`
-  would not be recognized as valid options by the `docker-compose`
-  command line.
-
-- Fixed an issue where Compose would sometimes exit unexpectedly  while
-  reading events broadcasted by a Swarm cluster.
-
-- Corrected a statement in the docs about the location of the `.env` file,
-  which is indeed read from the current directory, instead of in the same
-  location as the Compose file.
-
-## 1.7.0
-
-(2016-04-13)
-
-### Breaking Changes
-
--   `docker-compose logs` no longer follows log output by default. It now
-    matches the behavior of `docker logs` and exits after the current logs
-    are printed. Use `-f` to get the old default behavior.
-
--   Booleans are no longer allows as values for mappings in the Compose file
-    (for keys `environment`, `labels` and `extra_hosts`). Previously this
-    was a warning. Boolean values should be quoted so they become string values.
-
-### New Features
-
--   Compose now looks for a `.env` file in the directory where it's run and
-    reads any environment variables defined inside, if they're not already
-    set in the shell environment. This lets you easily set defaults for
-    variables used in the Compose file, or for any of the `COMPOSE_*` or
-    `DOCKER_*` variables.
-
--   Added a `--remove-orphans` flag to both `docker-compose up` and
-    `docker-compose down` to remove containers for services that were removed
-    from the Compose file.
-
--   Added a `--all` flag to `docker-compose rm` to include containers created
-    by `docker-compose run`. This will become the default behavior in the next
-    version of Compose.
-
--   Added support for all the same TLS configuration flags used by the `docker`
-    client: `--tls`, `--tlscert`, `--tlskey`, etc.
-
--   Compose files now support the `tmpfs` and `shm_size` options.
-
--   Added the `--workdir` flag to `docker-compose run`
-
--   `docker-compose logs` now shows logs for new containers that are created
-    after it starts.
-
--   The `COMPOSE_FILE` environment variable can now contain multiple files,
-    separated by the host system's standard path separator (`:` on Mac/Linux,
-    `;` on Windows).
-
--   You can now specify a static IP address when connecting a service to a
-    network with the `ipv4_address` and `ipv6_address` options.
-
--   Added `--follow`, `--timestamp`, and `--tail` flags to the
-    `docker-compose logs` command.
-
--   `docker-compose up`, and `docker-compose start` will now start containers
-    in parallel where possible.
-
--   `docker-compose stop` now stops containers in reverse dependency order
-    instead of all at once.
-
--   Added the `--build` flag to `docker-compose up` to force it to build a new
-    image. It now shows a warning if an image is automatically built when the
-    flag is not used.
-
--   Added the `docker-compose exec` command for executing a process in a running
-    container.
-
-
-### Bug fixes
-
--   `docker-compose down` now removes containers created by
-    `docker-compose run`.
-
--   A more appropriate error is shown when a timeout is hit during `up` when
-    using a tty.
-
--   Fixed a bug in `docker-compose down` where it would abort if some resources
-    had already been removed.
-
--   Fixed a bug where changes to network aliases would not trigger a service
-    to be recreated.
-
--   Fix a bug where a log message was printed about creating a new volume
-    when it already existed.
-
--   Fixed a bug where interrupting `up` would not always shut down containers.
-
--   Fixed a bug where `log_opt` and `log_driver` were not properly carried over
-    when extending services in the v1 Compose file format.
-
--   Fixed a bug where empty values for build args would cause file validation
-    to fail.
-
-## 1.6.2
-
-(2016-02-23)
-
--   Fixed a bug where connecting to a TLS-enabled Docker Engine would fail with
-    a certificate verification error.
-
-## 1.6.1
-
-(2016-02-23)
-
-### Bug fixes
-
--   Fixed a bug where recreating a container multiple times would cause the
-    new container to be started without the previous volumes.
-
--   Fixed a bug where Compose would set the value of unset environment variables
-    to an empty string, instead of a key without a value.
-
--   Provide a better error message when Compose requires a more recent version
-    of the Docker API.
-
--   Add a missing config field `network.aliases` which allows setting a network
-    scoped alias for a service.
-
--   Fixed a bug where `run` would not start services listed in `depends_on`.
-
--   Fixed a bug where `networks` and `network_mode` where not merged when using
-    extends or multiple Compose files.
-
--   Fixed a bug with service aliases where the short container id alias was
-    only contained 10 characters, instead of the 12 characters used in previous
-    versions.
-
--   Added a missing log message when creating a new named volume.
-
--   Fixed a bug where `build.args` was not merged when using `extends` or
-    multiple Compose files.
-
--   Fixed some bugs with config validation when null values or incorrect types
-    were used instead of a mapping.
-
--   Fixed a bug where a `build` section without a `context` would show a stack
-    trace instead of a helpful validation message.
-
--   Improved compatibility with swarm by only setting a container affinity to
-    the previous instance of a services' container when the service uses an
-    anonymous container volume. Previously the affinity was always set on all
-    containers.
-
--   Fixed the validation of some `driver_opts` would cause an error if a number
-    was used instead of a string.
-
--   Some improvements to the `run.sh` script used by the Compose container install
-    option.
-
--   Fixed a bug with `up --abort-on-container-exit` where Compose would exit,
-    but would not stop other containers.
-
--   Corrected the warning message that is printed when a boolean value is used
-    as a value in a mapping.
-
-## 1.6.0
-
-(2016-01-15)
-
-### Major Features
-
--   Compose 1.6 introduces a new format for `docker-compose.yml` which lets
-    you define networks and volumes in the Compose file as well as services. It
-    also makes a few changes to the structure of some configuration options.
-
-    You don't have to use it - your existing Compose files will run on Compose
-    1.6 exactly as they do today.
-
-    Check the [upgrade guide](/reference/compose-file/legacy-versions.md)
-    for full details.
-
--   Support for networking has exited experimental status and is the recommended
-    way to enable communication between containers.
-
-    If you use the new file format, your app will use networking. If you aren't
-    ready yet, just leave your Compose file as it is and it'll continue to work
-    just the same.
-
-    By default, you don't have to configure any networks. In fact, using
-    networking with Compose involves even less configuration than using links.
-    Consult the [networking guide](/manuals/compose/how-tos/networking.md) for how to use it.
-
-    The experimental flags `--x-networking` and `--x-network-driver`, introduced
-    in Compose 1.5, have been removed.
-
--   You can now pass arguments to a build if you're using the new file format:
-
-        build:
-          context: .
-          args:
-            buildno: 1
-
--   You can now specify both a `build` and an `image` key if you're using the
-    new file format. `docker-compose build` will build the image and tag it with
-    the name you've specified, while `docker-compose pull` will attempt to pull
-    it.
-
--   There's a new `events` command for monitoring container events from
-    the application, much like `docker events`. This is a good primitive for
-    building tools on top of Compose for performing actions when particular
-    things happen, such as containers starting and stopping.
-
--   There's a new `depends_on` option for specifying dependencies between
-    services. This enforces the order of startup, and ensures that when you run
-    `docker-compose up SERVICE` on a service with dependencies, those are started
-    as well.
-
-### New Features
-
--   Added a new command `config` which validates and prints the Compose
-    configuration after interpolating variables, resolving relative paths, and
-    merging multiple files and `extends`.
-
--   Added a new command `create` for creating containers without starting them.
-
--   Added a new command `down` to stop and remove all the resources created by
-    `up` in a single command.
-
--   Added support for the `cpu_quota` configuration option.
-
--   Added support for the `stop_signal` configuration option.
-
--   Commands `start`, `restart`, `pause`, and `unpause` now exit with an
-    error status code if no containers were modified.
-
--   Added a new `--abort-on-container-exit` flag to `up` which causes `up` to
-    stop all container and exit once the first container exits.
-
--   Removed support for `FIG_FILE`, `FIG_PROJECT_NAME`, and no longer reads
-    `fig.yml` as a default Compose file location.
-
--   Removed the `migrate-to-labels` command.
-
--   Removed the `--allow-insecure-ssl` flag.
-
-### Bug fixes
-
--   Fixed a validation bug that prevented the use of a range of ports in
-    the `expose` field.
-
--   Fixed a validation bug that prevented the use of arrays in the `entrypoint`
-    field if they contained duplicate entries.
-
--   Fixed a bug that caused `ulimits` to be ignored when used with `extends`.
-
--   Fixed a bug that prevented ipv6 addresses in `extra_hosts`.
-
--   Fixed a bug that caused `extends` to be ignored when included from
-    multiple Compose files.
-
--   Fixed an incorrect warning when a container volume was defined in
-    the Compose file.
-
--   Fixed a bug that prevented the force shutdown behavior of `up` and
-    `logs`.
-
--   Fixed a bug that caused `None` to be printed as the network driver name
-    when the default network driver was used.
-
--   Fixed a bug where using the string form of `dns` or `dns_search` would
-    cause an error.
-
--   Fixed a bug where a container would be reported as "Up" when it was
-    in the restarting state.
-
--   Fixed a confusing error message when DOCKER_CERT_PATH was not set properly.
-
--   Fixed a bug where attaching to a container would fail if it was using a
-    non-standard logging driver (or none at all).
-
-## 1.5.2
-
-(2015-12-03)
-
--   Fixed a bug which broke the use of `environment` and `env_file` with
-    `extends`, and caused environment keys without values to have a `None`
-    value, instead of a value from the host environment.
-
--   Fixed a regression in 1.5.1 that caused a warning about volumes to be
-    raised incorrectly when containers were recreated.
-
--   Fixed a bug which prevented building a `Dockerfile` that used `ADD <url>`
-
--   Fixed a bug with `docker-compose restart` which prevented it from
-    starting stopped containers.
-
--   Fixed handling of SIGTERM and SIGINT to properly stop containers
-
--   Add support for using a url as the value of `build`
-
--   Improved the validation of the `expose` option
-
-## 1.5.1
-
-(2015-11-12)
-
--   Add the `--force-rm` option to `build`.
-
--   Add the `ulimit` option for services in the Compose file.
-
--   Fixed a bug where `up` would error with "service needs to be built" if
-    a service changed from using `image` to using `build`.
-
--   Fixed a bug that would cause incorrect output of parallel operations
-    on some terminals.
-
--   Fixed a bug that prevented a container from being recreated when the
-    mode of a `volumes_from` was changed.
-
--   Fixed a regression in 1.5.0 where non-utf-8 unicode characters would cause
-    `up` or `logs` to crash.
-
--   Fixed a regression in 1.5.0 where Compose would use a success exit status
-    code when a command fails due to an HTTP timeout communicating with the
-    docker daemon.
-
--   Fixed a regression in 1.5.0 where `name` was being accepted as a valid
-    service option which would override the actual name of the service.
-
--   When using `--x-networking` Compose no longer sets the hostname to the
-    container name.
-
--   When using `--x-networking` Compose will only create the default network
-    if at least one container is using the network.
-
--   When printings logs during `up` or `logs`, flush the output buffer after
-    each line to prevent buffering issues from hiding logs.
-
--   Recreate a container if one of its dependencies is being created.
-    Previously a container was only recreated if it's dependencies already
-    existed, but were being recreated as well.
-
--   Add a warning when a `volume` in the Compose file is being ignored
-    and masked by a container volume from a previous container.
-
--   Improve the output of `pull` when run without a tty.
-
--   When using multiple Compose files, validate each before attempting to merge
-    them together. Previously invalid files would result in not helpful errors.
-
--   Allow dashes in keys in the `environment` service option.
-
--   Improve validation error messages by including the filename as part of the
-    error message.
-
-## 1.5.0
-
-(2015-11-03)
-
-### Breaking changes
-
-With the introduction of variable substitution support in the Compose file, any
-Compose file that uses an environment variable (`$VAR` or `${VAR}`) in the `command:`
-or `entrypoint:` field will break.
-
-Previously these values were interpolated inside the container, with a value
-from the container environment.  In Compose 1.5.0, the values will be
-interpolated on the host, with a value from the host environment.
-
-To migrate a Compose file to 1.5.0, escape the variables with an extra `$`
-(ex: `$$VAR` or `$${VAR}`).  See
-https://github.com/docker/compose/blob/8cc8e61/docs/compose-file.md#variable-substitution
-
-### Major features
-
--   Compose is now available for Windows.
-
--   Environment variables can be used in the Compose file. See
-    https://github.com/docker/compose/blob/8cc8e61/docs/compose-file.md#variable-substitution
-
--   Multiple compose files can be specified, allowing you to override
-    settings in the default Compose file. See
-    https://github.com/docker/compose/blob/8cc8e61/docs/reference/docker-compose.md
-    for more details.
-
--   Compose now produces better error messages when a file contains
-    invalid configuration.
-
--   `up` now waits for all services to exit before shutting down,
-    rather than shutting down as soon as one container exits.
-
--   Experimental support for the new docker networking system can be
-    enabled with the `--x-networking` flag. Read more here:
-    https://github.com/docker/docker/blob/8fee1c20/docs/userguide/dockernetworks.md
-
-### New features
-
--   You can now optionally pass a mode to `volumes_from`. For example,
-    `volumes_from: ["servicename:ro"]`.
-
--   Since Docker now lets you create volumes with names, you can refer to those
-    volumes by name in `docker-compose.yml`. For example,
-    `volumes: ["mydatavolume:/data"]` will mount the volume named
-    `mydatavolume` at the path `/data` inside the container.
-
-    If the first component of an entry in `volumes` starts with a `.`, `/` or `~`,
-    it is treated as a path and expansion of relative paths is performed as
-    necessary. Otherwise, it is treated as a volume name and passed straight
-    through to Docker.
-
-    Read more on named volumes and volume drivers here:
-    https://github.com/docker/docker/blob/244d9c33/docs/userguide/dockervolumes.md
-
--   `docker-compose build --pull` instructs Compose to pull the base image for
-    each Dockerfile before building.
-
--   `docker-compose pull --ignore-pull-failures` instructs Compose to continue
-    if it fails to pull a single service's image, rather than aborting.
-
--   You can now specify an IPC namespace in `docker-compose.yml` with the `ipc`
-    option.
-
--   Containers created by `docker-compose run` can now be named with the
-    `--name` flag.
-
--   If you install Compose with pip or use it as a library, it now works with
-    Python 3.
-
--   `image` now supports image digests (in addition to ids and tags). For example,
-    `image: "busybox@sha256:38a203e1986cf79639cfb9b2e1d6e773de84002feea2d4eb006b52004ee8502d"`
-
--   `ports` now supports ranges of ports. For example,
-
-        ports:
-          - "3000-3005"
-          - "9000-9001:8000-8001"
-
--   `docker-compose run` now supports a `-p|--publish` parameter, much like
-    `docker run -p`, for publishing specific ports to the host.
-
--   `docker-compose pause` and `docker-compose unpause` have been implemented,
-    analogous to `docker pause` and `docker unpause`.
-
--   When using `extends` to copy configuration from another service in the same
-    Compose file, you can omit the `file` option.
-
--   Compose can be installed and run as a Docker image. This is an experimental
-    feature.
-
-### Bug fixes
-
--   All values for the `log_driver` option which are supported by the Docker
-    daemon are now supported by Compose.
-
--   `docker-compose build` can now be run successfully against a Swarm cluster.
-
-## 1.4.2
-
-(2015-09-22)
-
--  Fixed a regression in the 1.4.1 release that would cause `docker-compose up`
-   without the `-d` option to exit immediately.
-
-## 1.4.1
-
-(2015-09-10)
-
-### Bug fixes
-
--   Some configuration changes (notably changes to `links`, `volumes_from`, and
-    `net`) were not properly triggering a container recreate as part of
-    `docker-compose up`.
--   `docker-compose up <service>` was showing logs for all services instead of
-    just the specified services.
--   Containers with custom container names were showing up in logs as
-    `service_number` instead of their custom container name.
--   When scaling a service sometimes containers would be recreated even when
-    the configuration had not changed.
-
-
-## 1.4.0
-
-(2015-08-04)
-
--   By default, `docker-compose up` now only recreates containers for services whose configuration has changed since they were created. This should result in a dramatic speed-up for many applications.
-
-    The experimental `--x-smart-recreate` flag which introduced this feature in Compose 1.3.0 has been removed, and a `--force-recreate` flag has been added for when you want to recreate everything.
-
--   Several of Compose's commands - `scale`, `stop`, `kill` and `rm` - now perform actions on multiple containers in parallel, rather than in sequence, which will run much faster on larger applications.
-
--   You can now specify a custom name for a service's container with `container_name`. Because Docker container names must be unique, this means you can't scale the service beyond one container.
-
--   You no longer have to specify a `file` option when using `extends` - it will default to the current file.
-
--   Service names can now contain dots, dashes and underscores.
-
--   Compose can now read YAML configuration from standard input, rather than from a file, by specifying `-` as the filename. This makes it easier to generate configuration dynamically:
-
-        $ echo 'redis: {"image": "redis"}' | docker-compose --file - up
-
--   There's a new `docker-compose version` command which prints extended information about Compose's bundled dependencies.
-
--   `docker-compose.yml` now supports `log_opt` as well as `log_driver`, allowing you to pass extra configuration to a service's logging driver.
-
--   `docker-compose.yml` now supports `memswap_limit`, similar to `docker run --memory-swap`.
-
--   When mounting volumes with the `volumes` option, you can now pass in any mode supported by the daemon, not just `:ro` or `:rw`. For example, SELinux users can pass `:z` or `:Z`.
-
--   You can now specify a custom volume driver with the `volume_driver` option in `docker-compose.yml`, much like `docker run --volume-driver`.
-
--   A bug has been fixed where Compose would fail to pull images from private registries serving plain (unsecured) HTTP. The `--allow-insecure-ssl` flag, which was previously used to work around this issue, has been deprecated and now has no effect.
-
--   A bug has been fixed where `docker-compose build` would fail if the build depended on a private Hub image or an image from a private registry.
-
--   A bug has been fixed where Compose would crash if there were containers which the Docker daemon had not finished removing.
-
--   Two bugs have been fixed where Compose would sometimes fail with a "Duplicate bind mount" error, or fail to attach volumes to a container, if there was a volume path specified in `docker-compose.yml` with a trailing slash.
-
-Thanks @mnowster, @dnephin, @ekristen, @funkyfuture, @jeffk and @lukemarsden!
-
-## 1.3.3
-
-(2015-07-15)
-
-### Regression fixes
-
-- When stopping containers gracefully, Compose was setting the timeout to 0, effectively forcing a SIGKILL every time.
-- Compose would sometimes crash depending on the formatting of container data returned from the Docker API.
-
-## 1.3.2
-
-(2015-07-14)
-
-### Bug fixes
-
-- When there were one-off containers created by running `docker-compose run` on an older version of Compose, `docker-compose run` would fail with a name collision. Compose now shows an error if you have leftover containers of this type lying around, and tells you how to remove them.
-- Compose was not reading Docker authentication config files created in the new location, `~/docker/config.json`, and authentication against private registries would therefore fail.
-- When a container had a pseudo-TTY attached, its output in `docker-compose up` would be truncated.
-- `docker-compose up --x-smart-recreate` would sometimes fail when an image tag was updated.
-- `docker-compose up` would sometimes create two containers with the same numeric suffix.
-- `docker-compose rm` and `docker-compose ps` would sometimes list services that aren't part of the current project (though no containers were erroneously removed).
-- Some `docker-compose` commands would not show an error if invalid service names were passed in.
-
-Thanks @dano, @josephpage, @kevinsimper, @lieryan, @phemmer, @soulrebel and @sschepens!
-
-## 1.3.1
-
-(2015-06-21)
-
-### Bug fixes
-
-- `docker-compose build` would always attempt to pull the base image before building.
-- `docker-compose help migrate-to-labels` failed with an error.
-- If no network mode was specified, Compose would set it to "bridge", rather than allowing the Docker daemon to use its configured default network mode.
-
-## 1.3.0
-
-(2015-06-18)
-
-### Important notes
-
-- **This release contains breaking changes, and you will need to either remove or migrate your existing containers before running your app** - see the [upgrading section of the install docs](https://github.com/docker/compose/blob/1.3.0rc1/docs/install.md#upgrading) for details.
-
-- Compose now requires Docker 1.6.0 or later.
-
-### Improvements
-
-- Compose now uses container labels, rather than names, to keep track of containers. This makes Compose both faster and easier to integrate with your own tools.
-
-- Compose no longer uses "intermediate containers" when recreating containers for a service. This makes `docker-compose up` less complex and more resilient to failure.
-
-### New features
-
-- `docker-compose up` has an **experimental** new behavior: it will only recreate containers for services whose configuration has changed in `docker-compose.yml`. This will eventually become the default, but for now you can take it for a spin:
-
-        $ docker-compose up --x-smart-recreate
-
-- When invoked in a subdirectory of a project, `docker-compose` will now climb up through parent directories until it finds a `docker-compose.yml`.
-
-Several new configuration keys have been added to `docker-compose.yml`:
-
-- `dockerfile`, like `docker build --file`, lets you specify an alternate Dockerfile to use with `build`.
-- `labels`, like `docker run --labels`, lets you add custom metadata to containers.
-- `extra_hosts`, like `docker run --add-host`, lets you add entries to a container's `/etc/hosts` file.
-- `pid: host`, like `docker run --pid=host`, lets you reuse the same PID namespace as the host machine.
-- `cpuset`, like `docker run --cpuset-cpus`, lets you specify which CPUs to allow execution in.
-- `read_only`, like `docker run --read-only`, lets you mount a container's filesystem as read-only.
-- `security_opt`, like `docker run --security-opt`, lets you specify [security options](/reference/cli/docker/container/run/#security-opt).
-- `log_driver`, like `docker run --log-driver`, lets you specify a [log driver](/reference/cli/docker/container/run/#log-driver).
-
-### Bug fixes
-
-- The output of `docker-compose run` was sometimes truncated, especially when running under Jenkins.
-- A service's volumes would sometimes not update after volume configuration was changed in `docker-compose.yml`.
-- Authenticating against third-party registries would sometimes fail.
-- `docker-compose run --rm` would fail to remove the container if the service had a `restart` policy in place.
-- `docker-compose scale` would refuse to scale a service beyond 1 container if it exposed a specific port number on the host.
-- Compose would refuse to create multiple volume entries with the same host path.
-
-Thanks @ahromis, @albers, @aleksandr-vin, @antoineco, @ccverak, @chernjie, @dnephin, @edmorley, @fordhurley, @josephpage, @KyleJamesWalker, @lsowen, @mchasal, @noironetworks, @sdake, @sdurrheimer, @sherter, @stephenlawrence, @thaJeztah, @thieman, @turtlemonvh, @twhiteman, @vdemeester, @xuxinkun and @zwily!
-
-## 1.2.0
-
-(2015-04-16)
-
-- `docker-compose.yml` now supports an `extends` option, which enables a service to inherit configuration from another service in another configuration file. This is really good for sharing common configuration between apps, or for configuring the same app for different environments. Here's the [documentation](https://github.com/docker/compose/blob/master/docs/).
-
-- When using Compose with a Swarm cluster, containers that depend on one another will be co-scheduled on the same node. This means that most Compose apps will now work out of the box, as long as they don't use `build`.
-
-- Repeated invocations of `docker-compose up` when using Compose with a Swarm cluster now work reliably.
-
-- Directories passed to `build`, filenames passed to `env_file` and volume host paths passed to `volumes` are now treated as relative to the *directory of the configuration file*, not the directory that `docker-compose` is being run in. In the majority of cases, those are the same, but if you use the `-f|--file` argument to specify a configuration file in another directory, **this is a breaking change**.
-
-- A service can now share another service's network namespace with `net: container:<service>`.
-
-- `volumes_from` and `net: container:<service>` entries are taken into account when resolving dependencies, so `docker-compose up <service>` will correctly start all dependencies of `<service>`.
-
-- `docker-compose run` now accepts a `--user` argument to specify a user to run the command as, just like `docker run`.
-
-- The `up`, `stop` and `restart` commands now accept a `--timeout` (or `-t`) argument to specify how long to wait when attempting to gracefully stop containers, just like `docker stop`.
-
-- `docker-compose rm` now accepts `-f` as a shorthand for `--force`, just like `docker rm`.
-
-Thanks, @abesto, @albers, @alunduil, @dnephin, @funkyfuture, @gilclark, @IanVS, @KingsleyKelly, @knutwalker, @thaJeztah and @vmalloc!
-
-## 1.1.0
-
-(2015-02-25)
-
-Fig has been renamed to Docker Compose, or just Compose for short. This has several implications for you:
-
-- The command you type is now `docker-compose`, not `fig`.
-- You should rename your fig.yml to docker-compose.yml.
-- If you’re installing via PyPI, the package is now `docker-compose`, so install it with `pip install docker-compose`.
-
-Besides that, there’s a lot of new stuff in this release:
-
-- We’ve made a few small changes to ensure that Compose will work with Swarm, Docker’s new clustering tool (https://github.com/docker/swarm). Eventually you'll be able to point Compose at a Swarm cluster instead of a standalone Docker host and it’ll run your containers on the cluster with no extra work from you. As Swarm is still developing, integration is rough and lots of Compose features don't work yet.
-
-- `docker-compose run` now has a `--service-ports` flag for exposing ports on the given service. This is useful for running your webapp with an interactive debugger, for example.
-
-- You can now link to containers outside your app with the `external_links` option in docker-compose.yml.
-
-- You can now prevent `docker-compose up` from automatically building images with the `--no-build` option. This will make fewer API calls and run faster.
-
-- If you don’t specify a tag when using the `image` key, Compose will default to the `latest` tag, rather than pulling all tags.
-
-- `docker-compose kill` now supports the `-s` flag, allowing you to specify the exact signal you want to send to a service’s containers.
-
-- docker-compose.yml now has an `env_file` key, analogous to `docker run --env-file`, letting you specify multiple environment variables in a separate file. This is great if you have a lot of them, or if you want to keep sensitive information out of version control.
-
-- docker-compose.yml now supports the `dns_search`, `cap_add`, `cap_drop`, `cpu_shares` and `restart` options, analogous to `docker run`’s `--dns-search`, `--cap-add`, `--cap-drop`, `--cpu-shares` and `--restart` options.
-
-- Compose now ships with Bash tab completion - see the installation and usage docs at https://github.com/docker/compose/blob/1.1.0/docs/completion.md
-
-- A number of bugs have been fixed - see the milestone for details: https://github.com/docker/compose/issues?q=milestone%3A1.1.0+
-
-Thanks @dnephin, @squebe, @jbalonso, @raulcd, @benlangfield, @albers, @ggtools, @bersace, @dtenenba, @petercv, @drewkett, @TFenby, @paulRbr, @Aigeruth and @salehe!
-
-## 1.0.1
-
-(2014-11-04)
-
- - Added an `--allow-insecure-ssl` option to allow `fig up`, `fig run` and `fig pull` to pull from insecure registries.
- - Fixed `fig run` not showing output in Jenkins.
- - Fixed a bug where Fig couldn't build Dockerfiles with ADD statements pointing at URLs.
-
-## 1.0.0
-
-(2014-10-16)
-
-The highlights:
-
- - [Fig has joined Docker.](https://www.orchardup.com/blog/orchard-is-joining-docker) Fig will continue to be maintained, but we'll also be incorporating the best bits of Fig into Docker itself.
-
-   This means the GitHub repository has moved to [https://github.com/docker/fig](https://github.com/docker/fig) and our IRC channel is now #docker-fig on Freenode.
-
- - Fig can be used with the [official Docker OS X installer](/manuals/desktop/setup/install/mac-install.md). Boot2Docker will mount the home directory from your host machine so volumes work as expected.
-
- - Fig supports Docker 1.3.
-
- - It is now possible to connect to the Docker daemon using TLS by using the `DOCKER_CERT_PATH` and `DOCKER_TLS_VERIFY` environment variables.
-
- - There is a new `fig port` command which outputs the host port binding of a service, in a similar way to `docker port`.
-
- - There is a new `fig pull` command which pulls the latest images for a service.
-
- - There is a new `fig restart` command which restarts a service's containers.
-
- - Fig creates multiple containers in service by appending a number to the service name. For example,  `db_1`, `db_2`. As a convenience, Fig will now give the first container an alias of the service name. For example, `db`.
-
-   This link alias is also a valid hostname and added to `/etc/hosts` so you can connect to linked services using their hostname. For example, instead of resolving the environment variables `DB_PORT_5432_TCP_ADDR` and `DB_PORT_5432_TCP_PORT`, you could just use the hostname `db` and port `5432` directly.
-
- - Volume definitions now support `ro` mode, expanding `~` and expanding environment variables.
-
- - `.dockerignore` is supported when building.
-
- - The project name can be set with the `FIG_PROJECT_NAME` environment variable.
-
- - The `--env` and `--entrypoint` options have been added to `fig run`.
-
- - The Fig binary for Linux is now linked against an older version of glibc so it works on CentOS 6 and Debian Wheezy.
-
-Other things:
-
- - `fig ps` now works on Jenkins and makes fewer API calls to the Docker daemon.
- - `--verbose` displays more useful debugging output.
- - When starting a service where `volumes_from` points to a service without any containers running, that service will now be started.
- - Lots of docs improvements. Notably, environment variables are documented and official repositories are used throughout.
-
-Thanks @dnephin, @d11wtq, @marksteve, @rubbish, @jbalonso, @timfreund, @alunduil, @mieciu, @shuron, @moss, @suzaku and @chmouel! Whew.
-
-## 0.5.2
-
-(2014-07-28)
-
- - Added a `--no-cache` option to `fig build`, which bypasses the cache just like `docker build --no-cache`.
- - Fixed the `dns:` fig.yml option, which was causing fig to error out.
- - Fixed a bug where fig couldn't start under Python 2.6.
- - Fixed a log-streaming bug that occasionally caused fig to exit.
-
-Thanks @dnephin and @marksteve!
-
-## 0.5.1
-
-(2014-07-11)
-
- - If a service has a command defined, `fig run [service]` with no further arguments will run it.
- - The project name now defaults to the directory containing fig.yml, not the current working directory (if they're different)
- - `volumes_from` now works properly with containers as well as services
- - Fixed a race condition when recreating containers in `fig up`
-
-Thanks @ryanbrainard and @d11wtq!
-
-## 0.5.0
-
-(2014-07-11)
-
- - Fig now starts links when you run `fig run` or `fig up`.
-
-   For example, if you have a `web` service which depends on a `db` service, `fig run web ...` will start the `db` service.
-
- - Environment variables can now be resolved from the environment that Fig is running in. Just specify it as a blank variable in your `fig.yml` and, if set, it'll be resolved:
-
-   ```yaml
-   environment:
-     RACK_ENV: development
-     SESSION_SECRET:
-   ```
-
- - `volumes_from` is now supported in `fig.yml`. All of the volumes from the specified services and containers will be mounted:
-
-   ```yaml
-   volumes_from:
-    - service_name
-    - container_name
-   ```
-
- - A host address can now be specified in `ports`:
-
-   ```yaml
-   ports:
-    - "0.0.0.0:8000:8000"
-    - "127.0.0.1:8001:8001"
-   ```
-
- - The `net` and `workdir` options are now supported in `fig.yml`.
- - The `hostname` option now works in the same way as the Docker CLI, splitting out into a `domainname` option.
- - TTY behavior is far more robust, and resizes are supported correctly.
- - Load YAML files safely.
-
-Thanks to @d11wtq, @ryanbrainard, @rail44, @j0hnsmith, @binarin, @Elemecca, @mozz100 and @marksteve for their help with this release!
-
-## 0.4.2
-
-(2014-06-18)
-
- - Fix various encoding errors when using `fig run`, `fig up` and `fig build`.
-
-## 0.4.1
-
-(2014-05-08)
-
- - Add support for Docker 0.11.0. (Thanks @marksteve!)
- - Make project name configurable. (Thanks @jefmathiot!)
- - Return correct exit code from `fig run`.
-
-## 0.4.0
-
-(2014-04-29)
-
- - Support Docker 0.9 and 0.10
- - Display progress bars correctly when pulling images (no more ski slopes)
- - `fig up` now stops all services when any container exits
- - Added support for the `privileged` config option in fig.yml (thanks @kvz!)
- - Shortened and aligned log prefixes in `fig up` output
- - Only containers started with `fig run` link back to their own service
- - Handle UTF-8 correctly when streaming `fig build/run/up` output (thanks @mauvm and @shanejonas!)
- - Error message improvements
-
-## 0.3.2
-
-(2014-03-05)
-
- - Added an `--rm` option to `fig run`. (Thanks @marksteve!)
- - Added an `expose` option to `fig.yml`.
-
-## 0.3.1
-
-(2014-03-04)
-
- - Added contribution instructions. (Thanks @kvz!)
- - Fixed `fig rm` throwing an error.
- - Fixed a bug in `fig ps` on Docker 0.8.1 when there is a container with no command.
-
-## 0.3.0
-
-(2014-03-03)
-
- - We now ship binaries for OS X and Linux. No more having to install with Pip!
- - Add `-f` flag to specify alternate `fig.yml` files
- - Add support for custom link names
- - Fix a bug where recreating would sometimes hang
- - Update docker-py to support Docker 0.8.0.
- - Various documentation improvements
- - Various error message improvements
-
-Thanks @marksteve, @Gazler and @teozkr!
-
-## 0.2.2
-
-(2014-02-17)
-
- - Resolve dependencies using Cormen/Tarjan topological sort
- - Fix `fig up` not printing log output
- - Stop containers in reverse order to starting
- - Fix scale command not binding ports
-
-Thanks to @barnybug and @dustinlacewell for their work on this release.
-
-## 0.2.1
-
-(2014-02-04)
-
- - General improvements to error reporting (#77, #79)
-
-## 0.2.0
-
-(2014-01-31)
-
- - Link services to themselves so run commands can access the running service. (#67)
- - Much better documentation.
- - Make service dependency resolution more reliable. (#48)
- - Load Fig configurations with a `.yaml` extension. (#58)
-
-Big thanks to @cameronmaske, @mrchrisadams and @damianmoore for their help with this release.
-
-## 0.1.4
-
-(2014-01-27)
-
- - Add a link alias without the project name. This makes the environment variables a little shorter: `REDIS_1_PORT_6379_TCP_ADDR`. (#54)
-
-## 0.1.3
-
-(2014-01-23)
-
- - Fix ports sometimes being configured incorrectly. (#46)
- - Fix log output sometimes not displaying. (#47)
-
-## 0.1.2
-
-(2014-01-22)
-
- - Add `-T` option to `fig run` to disable pseudo-TTY. (#34)
- - Fix `fig up` requiring the ubuntu image to be pulled to recreate containers. (#33) Thanks @cameronmaske!
- - Improve reliability, fix arrow keys and fix a race condition in `fig run`. (#34, #39, #40)
-
-## 0.1.1
-
-(2014-01-17)
-
- - Fix bug where ports were not exposed correctly (#29). Thanks @dustinlacewell!
-
-## 0.1.0
-
-(2014-01-16)
-
- - Containers are recreated on each `fig up`, ensuring config is up-to-date with `fig.yml` (#2)
- - Add `fig scale` command (#9)
- - Use `DOCKER_HOST` environment variable to find Docker daemon, for consistency with the official Docker client (was previously `DOCKER_URL`) (#19)
- - Truncate long commands in `fig ps` (#18)
- - Fill out CLI help banners for commands (#15, #16)
- - Show a friendlier error when `fig.yml` is missing (#4)
- - Fix bug with `fig build` logging (#3)
- - Fix bug where builds would time out if a step took a long time without generating output (#6)
- - Fix bug where streaming container output over the Unix socket raised an error (#7)
-
-Big thanks to @tomstuart, @EnTeQuAk, @schickling, @aronasorman and @GeoffreyPlitt.
-
-## 0.0.2
-
-(2014-01-02)
-
- - Improve documentation
- - Try to connect to Docker on `tcp://localdocker:4243` and a UNIX socket in addition to `localhost`.
- - Improve `fig up` behavior
- - Add confirmation prompt to `fig rm`
- - Add `fig build` command
-
-## 0.0.1
-
-(2013-12-20)
-
-Initial release.
diff --git a/content/manuals/compose/support-and-feedback/_index.md b/content/manuals/compose/support-and-feedback/_index.md
index 1e7e9933b717..cda0bf5b3042 100644
--- a/content/manuals/compose/support-and-feedback/_index.md
+++ b/content/manuals/compose/support-and-feedback/_index.md
@@ -2,5 +2,5 @@
 build:
   render: never
 title: Support and feedback
-weight: 60
+weight: 80
 ---
\ No newline at end of file
diff --git a/content/manuals/compose/support-and-feedback/faq.md b/content/manuals/compose/support-and-feedback/faq.md
index 52a113bb04fc..9955b065f3ac 100644
--- a/content/manuals/compose/support-and-feedback/faq.md
+++ b/content/manuals/compose/support-and-feedback/faq.md
@@ -1,7 +1,7 @@
 ---
-description: Frequently asked questions for Docker Compose
-keywords: documentation, docs,  docker, compose, faq, docker compose vs docker-compose
-title: Compose FAQs
+description: Answers to common questions about Docker Compose, including v1 vs v2, commands, shutdown behavior, and development setup.
+keywords: docker compose faq, docker compose questions, docker-compose vs docker compose, docker compose json, docker compose stop delay, run multiple docker compose
+title: Frequently asked questions about Docker Compose
 linkTitle: FAQs
 weight: 10
 tags: [FAQ]
@@ -15,6 +15,8 @@ Version one of the Docker Compose command-line binary was first released in 2014
 
 Version two of the Docker Compose command-line binary was announced in 2020, is written in Go, and is invoked with `docker compose`. Compose v2 ignores the version top-level element in the compose.yaml file.
 
+Compose v5, released in 2025, uses the same `docker compose` command and is functionally identical to Compose v2. Its primary distinction is the introduction of an official [Go SDK](/manuals/compose/compose-sdk.md).
+
 For further information, see [History and development of Compose](/manuals/compose/intro/history.md).
 
 ### What's the difference between `up`, `run`, and `start`?
@@ -40,7 +42,7 @@ containers.
 ### Why do my services take 10 seconds to recreate or stop?
 
 The `docker compose stop` command attempts to stop a container by sending a `SIGTERM`. It then waits
-for a [default timeout of 10 seconds](/reference/cli/docker/compose/stop.md). After the timeout,
+for a [default timeout of 10 seconds](/reference/cli/docker/compose/stop/). After the timeout,
 a `SIGKILL` is sent to the container to forcefully kill it. If you
 are waiting for this timeout, it means that your containers aren't shutting down
 when they receive the `SIGTERM` signal.
diff --git a/content/manuals/compose/support-and-feedback/feedback.md b/content/manuals/compose/support-and-feedback/feedback.md
index 04466f8a4e59..c6f98a595036 100644
--- a/content/manuals/compose/support-and-feedback/feedback.md
+++ b/content/manuals/compose/support-and-feedback/feedback.md
@@ -3,18 +3,10 @@ description: Find a way to provide feedback on Docker Compose that's right for y
 keywords: Feedback, Docker Compose, Community forum, bugs, problems, issues
 title: Give feedback
 weight: 20
-aliases:
-- /compose/feedback/
 ---
 
 There are many ways you can provide feedback on Docker Compose.
 
-### In-product feedback
-
-If you have obtained Docker Compose through Docker Desktop, you can use the `docker feedback` command to submit feedback directly from the command line.
-
-<script async id="asciicast-KkC0fFrhV8nAzvXUGqay06UXx" src="https://asciinema.org/a/KkC0fFrhV8nAzvXUGqay06UXx.js"></script>
-
 ### Report bugs or problems on GitHub
 
 To report bugs or problems, visit [Docker Compose on GitHub](https://github.com/docker/compose/issues)
diff --git a/content/manuals/compose/support-and-feedback/samples-for-compose.md b/content/manuals/compose/support-and-feedback/samples-for-compose.md
deleted file mode 100644
index cbeb84380e40..000000000000
--- a/content/manuals/compose/support-and-feedback/samples-for-compose.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-description: Summary of samples related to Compose
-keywords: documentation, docs, docker, compose, samples
-title: Sample apps with Compose
-linkTitle: Sample apps
-weight: 30
-aliases:
-- /compose/samples-for-compose/
----
-
-The following samples show the various aspects of how to work with Docker
-Compose. As a prerequisite, be sure to [install Docker Compose](/manuals/compose/install/_index.md)
-if you have not already done so.
-
-## Key concepts these samples cover
-
-The samples should help you to:
-
-- Define services based on Docker images using
-  [Compose files](/reference/compose-file/_index.md)
-- Understand the relationship between `compose.yaml` and
-  [Dockerfiles](/reference/dockerfile/)
-- Learn how to make calls to your application services from Compose files
-- Learn how to deploy applications and services to a [swarm](/manuals/engine/swarm/_index.md)
-
-## Awesome Compose samples
-
-The Awesome Compose samples provide a starting point on how to integrate different frameworks and technologies using Docker Compose. All samples are available in the [Awesome-compose GitHub repo](https://github.com/docker/awesome-compose) and are ready to run with `docker compose up`.
diff --git a/content/manuals/compose/trust-model.md b/content/manuals/compose/trust-model.md
new file mode 100644
index 000000000000..ce1e2a9f1e95
--- /dev/null
+++ b/content/manuals/compose/trust-model.md
@@ -0,0 +1,138 @@
+---
+title: Trust model for Compose files
+weight: 70
+description: Learn how Docker Compose treats Compose files as trusted input and what this means when using files you did not author.
+keywords: compose, security, trust model, oci, remote, registry, include, extends, supply chain, trust, best practices
+---
+
+Docker Compose treats every Compose file as trusted input. When a Compose file
+requests elevated privileges, host filesystem access, or any other
+configuration, Compose applies it as written. This is the same behavior as
+passing flags directly to `docker run`.
+
+This means that any Compose file you run, whether it lives on your local
+filesystem, in a Git repository, or in an OCI registry, has full control over
+how containers interact with your host. The security boundary is not where the file comes from but whether you trust the author.
+
+Evaluating trust means asking: Who authored this file? Has it changed since you last reviewed it? Do you understand every privilege it requests?
+
+## The dependency chain
+
+A Compose application can be assembled from multiple sources. The
+[`include`](/reference/compose-file/include.md) directive imports entire Compose
+files, while [`extends`](/reference/compose-file/services.md#extends) inherits
+configuration from a specific service in another file. Both support remote
+references and can be chained:
+
+```text
+Your command
+  └─ compose.yaml                                    (local or remote)
+       ├─ services, volumes, networks                (direct config)
+       ├─ include:
+       │    └─ oci://registry.example.com/base:v2   (remote dependency)
+       │         └─ services, volumes, networks      (indirect config)
+       └─ services:
+            └─ app:
+                 └─ extends:
+                      └─ file: oci://registry.example.com/templates:v1
+                           └─ service: webapp        (inherited config)
+```
+
+Each level has the same capabilities. The top-level file you inspect may appear
+safe while a nested `include` or `extends` introduces services with elevated
+privileges, host bind mounts, or untrusted images. These dependencies can also
+change independently. Risky settings can be introduced by a nested dependency that you never
+see unless you inspect the fully resolved output.
+
+> [!IMPORTANT]
+>
+> Compose warns you when a configuration references remote sources. Do not
+> accept this without understanding every reference in the chain.
+
+## Best practices
+
+### Inspect the full configuration
+
+To see exactly what Compose applies, including all resolved `includes`,
+`extends`, merged overrides, and interpolated variables, use:
+
+```console
+$ docker compose config
+```
+
+For remote references:
+
+```console
+$ docker compose -f oci://registry.example.com/myapp:latest config
+```
+
+Review this output before running `up` or `create`, especially when the
+configuration comes from a source you have not audited.
+
+#### Fields to look out for
+
+A Compose configuration has broad control over how containers interact with the
+host. The following is a non-exhaustive list of fields that carry security
+implications when set by an untrusted author:
+
+| Field | Effect |
+|-------|--------|
+| `privileged` | Grants the container full access to the host |
+| `cap_add` | Adds Linux capabilities such as `SYS_ADMIN` or `NET_RAW` |
+| `security_opt` | Configures security profiles including seccomp and AppArmor |
+| `volumes` / bind mounts | Mounts host directories into the container |
+| `network_mode: host` | Shares the host network stack |
+| `pid: host` | Shares the host PID namespace |
+| `devices` | Exposes host devices to the container |
+| `image` | Pulls and runs an arbitrary container image |
+| `env_file`, `label_file`, `secrets`/`configs` (`file:`), `include`, `extends` | Read files from the host, directly or through symlinks resolved from a remote checkout, and can surface their contents during configuration loading |
+| `provider` | Runs the binary named by `provider.type` on the host, outside any container, when you run `up`, `down`, or `stop` |
+
+When in doubt, look up the effect of any unfamiliar field before running the configuration.
+
+Like `volumes`, the file-reference fields read any file the user running Compose
+can access, including through symlinks resolved from a remote checkout, and their
+contents can appear in `docker compose config` output before any container starts.
+Compose does not confine reads to the project directory. Treat a Compose project as
+code you run, not data you inspect.
+
+### CI/CD environments
+
+Automated pipelines are particularly sensitive because they often run with
+access to credentials, cloud provider tokens, or Docker sockets.
+
+- Avoid referencing public or unverified Compose configurations in automated
+  pipelines.
+- Gate updates behind your normal code review process.
+- Use read-only Docker socket mounts where possible to limit your risk.
+
+### Pin remote references to digests
+
+Tags are mutable, meaning anyone with push access to a registry can overwrite a tag silently, so a reference you reviewed last week may point to different content today.
+
+Digests are immutable. Instead of referencing by tag, pin to the digest. 
+
+```yaml
+include:
+  - oci://registry.example.com/base@sha256:a1b2c3d4...
+```
+
+Treat any update to a pinned digest as a code change. Make sure you review the new content before updating the reference.
+
+### Other
+
+- Use a private registry: Host OCI artifacts on a registry your
+  organization controls. Restrict who can push to it.
+- Audit transitive dependencies: Check every remote `include` and `extends`
+  reference in the chain, not just the top-level file.
+- Review all Compose confirmation prompts: When loading remote Compose files,
+  Compose displays confirmation prompts for interpolation variables, environment
+  values, and remote includes. Review these before accepting.
+
+## Further reading
+
+- [OCI artifact applications](/manuals/compose/how-tos/oci-artifact.md)
+- [Use Compose in production](/manuals/compose/how-tos/production.md)
+- [`include` reference](/reference/compose-file/include.md)
+- [`extends` reference](/reference/compose-file/services.md#extends)
+- [Manage secrets in Compose](/manuals/compose/how-tos/use-secrets.md)
\ No newline at end of file
diff --git a/content/manuals/copilot/_index.md b/content/manuals/copilot/_index.md
deleted file mode 100644
index b40f6caedb11..000000000000
--- a/content/manuals/copilot/_index.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: Docker for GitHub Copilot
-params:
-  sidebar:
-    group: Products
-    badge:
-      color: violet
-      text: EA
-weight: 50
-description: |
-  Learn how to streamline Docker-related tasks with the Docker for GitHub
-  Copilot extension. This integration helps you generate Docker assets, analyze
-  vulnerabilities, and automate containerization through GitHub Copilot Chat in
-  various development environments.
-keywords: Docker, GitHub Copilot, extension, Visual Studio Code, chat, ai, containerization
----
-
-{{< summary-bar feature_name="Docker GitHub Copilot" >}}
-
-The [Docker for GitHub Copilot](https://github.com/marketplace/docker-for-github-copilot)
-extension integrates Docker's capabilities with GitHub Copilot, providing
-assistance with containerizing applications, generating Docker assets, and
-analyzing project vulnerabilities. This extension helps you streamline
-Docker-related tasks wherever GitHub Copilot Chat is available.
-
-## Key features
-
-Key features of the Docker for GitHub Copilot extension include:
-
-- Ask questions and receive responses about containerization in any context
-  where GitHub Copilot Chat is available, such as on GitHub.com and in Visual Studio Code.
-- Automatically generate Dockerfiles, Docker Compose files, and `.dockerignore`
-  files for a project.
-- Open pull requests with generated Docker assets directly from the chat
-  interface.
-- Get summaries of project vulnerabilities from [Docker
-  Scout](/manuals/scout/_index.md) and receive next steps via the CLI.
-
-## Data Privacy
-
-The Docker agent is trained exclusively on Docker's documentation and tools to
-assist with containerization and related tasks. It does not have access to your
-project's data outside the context of the questions you ask.
-
-When using the Docker Extension for GitHub Copilot, GitHub Copilot may include
-a reference to the currently open file in its request if authorized by the
-user. The Docker agent can read the file to provide context-aware responses.
-
-If the agent is requested to check for vulnerabilities or generate
-Docker-related assets, it will clone the referenced repository into in-memory
-storage to perform the necessary actions.
-
-Source code or project metadata is never persistently stored. Questions and
-answers are retained for analytics and troubleshooting. Data processed by the
-Docker agent is never shared with third parties.
-
-## Supported languages
-
-The Docker Extension for GitHub Copilot supports the following programming
-languages for tasks involving containerizing a project from scratch:
-
-- Go
-- Java
-- JavaScript
-- Python
-- Rust
-- TypeScript
diff --git a/content/manuals/copilot/examples.md b/content/manuals/copilot/examples.md
deleted file mode 100644
index 23bc2c8edf91..000000000000
--- a/content/manuals/copilot/examples.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Example prompts for the Docker agent
-linkTitle: Example prompts
-description: |
-  Discover example prompts to interact with the Docker agent and learn how to
-  automate tasks like Dockerizing projects or opening pull requests.
-weight: 30
----
-
-{{< summary-bar feature_name="Docker GitHub Copilot" >}}
-
-## Use cases
-
-Here are some examples of the types of questions you can ask the Docker agent:
-
-### Ask general Docker questions
-
-You can ask general question about Docker. For example:
-
-- `@docker what is a Dockerfile?`
-- `@docker how do I build a Docker image?`
-- `@docker how do I run a Docker container?`
-- `@docker what does 'docker buildx imagetools inspect' do?`
-
-### Get help containerizing your project
-
-You can ask the agent to help you containerize your existing project:
-
-- `@docker can you help create a compose file for this project?`
-- `@docker can you create a Dockerfile for this project?`
-
-#### Opening pull requests
-
-The Docker agent will analyze your project, generate the necessary files, and,
-if applicable, offer to raise a pull request with the necessary Docker assets.
-
-Automatically opening pull requests against your repositories is only available
-when the agent generates new Docker assets.
-
-### Analyze a project for vulnerabilities
-
-The agent can help you improve your security posture with [Docker
-Scout](/manuals/scout/_index.md):
-
-- `@docker can you help me find vulnerabilities in my project?`
-- `@docker does my project contain any insecure dependencies?`
-
-The agent will run use Docker Scout to analyze your project's dependencies, and
-report whether you're vulnerable to any [known CVEs](/manuals/scout/deep-dive/advisory-db-sources.md).
-
-![Copilot vulnerabilities report](images/copilot-vuln-report.png?w=500px&border=1)
-
-## Limitations
-
-- The agent is currently not able to access specific files in your repository,
-  such as the currently-opened file in your editor, or if you pass a file
-  reference with your message in the chat message.
-
-## Feedback
-
-For issues or feedback, visit the [GitHub feedback repository](https://github.com/docker/copilot-issues).
diff --git a/content/manuals/copilot/images/copilot-button.png b/content/manuals/copilot/images/copilot-button.png
deleted file mode 100644
index 7d40b5cf495c..000000000000
Binary files a/content/manuals/copilot/images/copilot-button.png and /dev/null differ
diff --git a/content/manuals/copilot/images/copilot-vuln-report.png b/content/manuals/copilot/images/copilot-vuln-report.png
deleted file mode 100644
index ca203875bd03..000000000000
Binary files a/content/manuals/copilot/images/copilot-vuln-report.png and /dev/null differ
diff --git a/content/manuals/copilot/images/docker-agent-copilot.png b/content/manuals/copilot/images/docker-agent-copilot.png
deleted file mode 100644
index 3e2476f5b28c..000000000000
Binary files a/content/manuals/copilot/images/docker-agent-copilot.png and /dev/null differ
diff --git a/content/manuals/copilot/install.md b/content/manuals/copilot/install.md
deleted file mode 100644
index 6b8dd2a87186..000000000000
--- a/content/manuals/copilot/install.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: Install the extension for your organization
-linkTitle: Install
-description: |
-  Learn how to install the Docker for GitHub Copilot extension for your
-  organization and manage relevant policies to enable seamless integration.
-weight: 10
----
-
-{{< summary-bar feature_name="Docker GitHub Copilot" >}}
-
-To use the Docker for GitHub copilot extension, you first need to
-[install](#install) the extension for your organization, and
-[manage](#manage-policies) policies for Copilot in your organization.
-
-## Prerequisites
-
-Before you start, ensure that you're signed in to your GitHub account on
-GitHub.com.
-
-## Install
-
-To install the Docker for GitHub Copilot extension for your GitHub organization:
-
-1. Go to the [Docker for GitHub Copilot](https://github.com/marketplace/docker-for-github-copilot)
-   app in the GitHub Marketplace.
-
-2. Select the **Add** button at the top of the page.
-
-3. Under **Pricing and setup**, select the organization that you want to
-   install the extension for and select **Install it for free**.
-
-4. Select the **Complete order and begin installation** button.
-
-5. Select the repositories where you want to use the Docker Extension for
-   GitHub Copilot and finish with **Install**.
-
-## Manage policies
-
-If you're enabling the extension for a GitHub organization, you also
-need to enable the Copilot Extensions policy. For instructions, see
-[Setting a policy for GitHub Copilot Extensions in your organization](https://docs.github.com/en/copilot/managing-copilot/managing-github-copilot-in-your-organization/setting-policies-for-copilot-in-your-organization/managing-policies-for-copilot-in-your-organization#setting-a-policy-for-github-copilot-extensions-in-your-organization).
diff --git a/content/manuals/copilot/usage.md b/content/manuals/copilot/usage.md
deleted file mode 100644
index 51ba028f20a3..000000000000
--- a/content/manuals/copilot/usage.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: Using the Docker for GitHub Copilot extension
-linkTitle: Usage
-description: |
-  Learn how to use the Docker for GitHub Copilot extension to interact with the
-  Docker agent, get help Dockerizing projects, and ask Docker-related questions
-  directly from your IDE or GitHub.com.
-weight: 20
----
-
-{{< summary-bar feature_name="Docker GitHub Copilot" >}}
-
-The Docker Extension for GitHub Copilot provides a chat interface that you can
-use to interact with the Docker agent. You can ask questions and get help
-Dockerizing your project.
-
-The Docker agent is trained to understand Docker-related questions, and provide
-guidance on Dockerfiles, Docker Compose files, and other Docker assets.
-
-## Setup
-
-Before you can start interacting with the Docker agent, make sure you've
-[installed](./install.md) the extension for your organization.
-
-### Enable GitHub Copilot chat in your editor or IDE
-
-For instructions on how to use the Docker Extension for GitHub Copilot in
-your editor, see:
-
-- [Visual Studio Code](https://docs.github.com/en/copilot/github-copilot-chat/copilot-chat-in-ides/using-github-copilot-chat-in-your-ide?tool=vscode)
-- [Visual Studio](https://docs.github.com/en/copilot/github-copilot-chat/copilot-chat-in-ides/using-github-copilot-chat-in-your-ide?tool=visualstudio)
-- [Codespaces](https://docs.github.com/en/codespaces/reference/using-github-copilot-in-github-codespaces)
-
-### Verify the setup
-
-You can verify that the extension has been properly installed by typing
-`@docker` in the Copilot Chat window. As you type, you should see the Docker
-agent appear in the chat interface.
-
-![Docker agent in chat](images/docker-agent-copilot.png)
-
-The first time you interact with the agent, you're prompted to sign in and
-authorize the Copilot extension with your Docker account.
-
-## Asking Docker questions in your editor
-
-To interact with the Docker agent from within your editor or IDE:
-
-1. Open your project in your editor.
-2. Open the Copilot chat interface.
-3. Interact with the Docker agent by tagging `@docker`, followed by your question.
-
-## Asking Docker questions on GitHub.com
-
-To interact with the Docker agent from the GitHub web interface:
-
-1. Go to [github.com](https://github.com/) and sign in to your account.
-2. Go to any repository.
-3. Select the Copilot logo in the site menu, or select the floating Copilot widget, to open the chat interface.
-
-   ![Copilot chat button](images/copilot-button.png?w=400px)
-
-4. Interact with the Docker agent by tagging `@docker`, followed by your question.
diff --git a/content/manuals/desktop/_index.md b/content/manuals/desktop/_index.md
index c5e18105331f..9df80515cdf8 100644
--- a/content/manuals/desktop/_index.md
+++ b/content/manuals/desktop/_index.md
@@ -6,7 +6,7 @@ keywords: how to use docker desktop, what is docker desktop used for, what does
   desktop do, using docker desktop
 params:
   sidebar:
-    group: Products
+    group: Application development
 grid:
 - title: Install Docker Desktop
   description: |
@@ -14,33 +14,27 @@ grid:
     [Mac](/desktop/setup/install/mac-install/),
     [Windows](/desktop/setup/install/windows-install/), or
     [Linux](/desktop/setup/install/linux/).
-  icon: download
+  icon: arrow-down-tray
 - title: Learn about Docker Desktop
   description: Navigate Docker Desktop.
-  icon: feature_search
+  icon: magnifying-glass
   link: /desktop/use-desktop/
 - title: Explore its key features
   description: |
-    Find information about [Docker VMM](/desktop/features/vmm/), [WSL](/desktop/features/wsl/), [deploying on Kubernetes](/desktop/features/kubernetes/), and more.
-  icon: category
+    Find information about [Networking](/desktop/features/networking/), [Docker VMM](/desktop/features/vmm/), [WSL](/desktop/features/wsl/), and more.
+  icon: squares-2x2
 - title: View the release notes
   description: Find out about new features, improvements, and bug fixes.
-  icon: note_add
+  icon: document-plus
   link: /desktop/release-notes/
 - title: Browse common FAQs
   description: Explore general FAQs or FAQs for specific platforms.
-  icon: help
+  icon: question-mark-circle
   link: /desktop/troubleshoot-and-support/faqs/general/
 - title: Give feedback
   description: Provide feedback on Docker Desktop or Docker Desktop features.
-  icon: sms
+  icon: chat-bubble-left
   link: /desktop/troubleshoot-and-support/feedback/
-aliases:
-- /desktop/opensource/
-- /docker-for-mac/dashboard/
-- /docker-for-mac/opensource/
-- /docker-for-windows/dashboard/
-- /docker-for-windows/opensource/
 ---
 
 Docker Desktop is a one-click-install application for your Mac, Linux, or Windows environment
@@ -52,22 +46,7 @@ Docker Desktop reduces the time spent on complex setups so you can focus on writ
 
 Docker Desktop integrates with your preferred development tools and languages, and gives you access to a vast ecosystem of trusted images and templates via Docker Hub. This empowers teams to accelerate development, automate builds, enable CI/CD workflows, and collaborate securely through shared repositories.
 
-{{< tabs >}}
-{{< tab name="What's included in Docker Desktop?" >}}
-
-- [Docker Engine](/manuals/engine/_index.md)
-- Docker CLI client
-- [Docker Scout](../scout/_index.md)
-- [Docker Build](/manuals/build/_index.md)
-- [Docker Compose](/manuals/compose/_index.md)
-- [Ask Gordon](/manuals/ai/gordon/_index.md)
-- [Docker Extensions](../extensions/_index.md)
-- [Docker Content Trust](/manuals/engine/security/trust/_index.md)
-- [Kubernetes](https://github.com/kubernetes/kubernetes/)
-- [Credential Helper](https://github.com/docker/docker-credential-helpers/)
-
-{{< /tab >}}
-{{< tab name="What are the key features of Docker Desktop?">}}
+## Key features
 
 * Ability to containerize and share any application on any cloud platform, in multiple languages and frameworks.
 * Quick installation and setup of a complete Docker development environment.
@@ -77,7 +56,19 @@ Docker Desktop integrates with your preferred development tools and languages, a
 * Ability to work natively on Linux through WSL 2 on Windows machines.
 * Volume mounting for code and data, including file change notifications and easy access to running containers on the localhost network.
 
-{{< /tab >}}
-{{< /tabs >}}
+## Products inside Docker Desktop
+
+- [Docker MCP Toolkit and Catalog](/manuals/ai/mcp-catalog-and-toolkit/_index.md)
+- [Docker Model Runner](/manuals/ai/model-runner/_index.md)
+- [Gordon](/manuals/ai/gordon/_index.md)
+- [Docker Offload](/manuals/offload/_index.md)
+- [Docker Engine](/manuals/engine/_index.md)
+- Docker CLI client
+- [Docker Build](/manuals/build/_index.md)
+- [Docker Compose](/manuals/compose/_index.md)
+- [Docker Scout](../scout/_index.md)
+- [Kubernetes](https://github.com/kubernetes/kubernetes/)
+
+## Next steps
 
 {{< grid >}}
diff --git a/content/manuals/desktop/cert-revoke-solution.md b/content/manuals/desktop/cert-revoke-solution.md
index 2a57d683e4a5..13f643c3a9c8 100644
--- a/content/manuals/desktop/cert-revoke-solution.md
+++ b/content/manuals/desktop/cert-revoke-solution.md
@@ -4,6 +4,7 @@ keywords: Docker desktop, fix, mac, troubleshooting, macos, false malware warnin
 title: Resolve the recent Docker Desktop issue on macOS
 linkTitle: Fix startup issue for Mac
 weight: 220
+sitemap: false
 ---
 
 This guide provides steps to address a recent issue affecting some macOS users of Docker Desktop. The issue may prevent Docker Desktop from starting and in some cases, may also trigger inaccurate malware warnings. For more details about the incident, see the [blog post](https://www.docker.com/blog/incident-update-docker-desktop-for-mac/).
diff --git a/content/manuals/desktop/enterprise/_index.md b/content/manuals/desktop/enterprise/_index.md
index ccd1d127952b..c71f13a1a0a6 100644
--- a/content/manuals/desktop/enterprise/_index.md
+++ b/content/manuals/desktop/enterprise/_index.md
@@ -4,20 +4,13 @@ description: Docker Desktop Enterprise
 keywords: Docker Desktop Enterprise
 sitemap: false
 aliases:
-- /ee/desktop/
-- /desktop/enterprise/release-notes/
 - /desktop/enterprise/admin/install/mac/
 - /desktop/enterprise/admin/configure/mac-admin/
 - /desktop/enterprise/admin/configure/windows-admin/
-- /desktop/enterprise/user/mac-user/
-- /desktop/enterprise/user/windows-user/
-- /desktop/enterprise/app-designer/
-- /desktop/enterprise/troubleshoot/mac-issues/
-- /desktop/enterprise/troubleshoot/windows-issues/
 ---
 
-Docker Desktop Enterprise (DDE) has been deprecated and is no longer in active development. Please use [Docker Desktop](../_index.md) Community instead.
+Docker Desktop Enterprise (DDE) has been deprecated and is no longer in active development. Use [Docker Desktop](/manuals/enterprise/enterprise-deployment/_index.md) instead.
 
-If you are an existing DDE customer, use our [Support form](https://hub.docker.com/support/desktop/) to request a transition to one of our new [subscription plans](https://www.docker.com/pricing).
+If you are an existing DDE customer, use the [Support form](https://hub.docker.com/support/desktop/) to request a transition to one of the new [subscriptions](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopEnterprise).
 
 If you are looking to deploy Docker Desktop at scale, contact us on [pricingquestions@docker.com](mailto:pricingquestions@docker.com).
diff --git a/content/manuals/desktop/features/containerd.md b/content/manuals/desktop/features/containerd.md
index 6f80994faebc..8b47f607f4c0 100644
--- a/content/manuals/desktop/features/containerd.md
+++ b/content/manuals/desktop/features/containerd.md
@@ -1,37 +1,29 @@
 ---
 title: containerd image store
 weight: 80
-description: How to activate the containerd integration feature in Docker Desktop
+description: Learn about the containerd image store in Docker Desktop and how it extends image management capabilities.
 keywords: Docker, containerd, engine, image store, lazy-pull
 toc_max: 3
 aliases:
-- /desktop/containerd/
+  - /desktop/containerd/
 ---
 
-Docker Desktop is transitioning to use containerd for image and filesystem management. This page outlines the benefits, setup process, and new capabilities enabled by the containerd image store.
-
-> [!NOTE]
-> 
-> Docker Desktop maintains separate image stores for the classic and containerd image stores.
-> When switching between them, images and containers from the inactive store remain on disk but are hidden until you switch back.
+Docker Desktop uses containerd as its image store by default. The image store
+is the component responsible for pushing, pulling, and storing images on your
+filesystem. The containerd image store supports features like multi-platform
+images, image attestations, and alternative snapshotters.
 
 ## What is `containerd`?
 
-`containerd` is a container runtime that provides a lightweight, consistent interface for container lifecycle management. It is already used under the hood by Docker Engine for creating, starting, and stopping containers.
-
-Docker Desktop’s ongoing integration of containerd now extends to the image store, offering more flexibility and modern image support.
+`containerd` is a container runtime that provides a lightweight, consistent
+interface for container lifecycle and image management. It is used under the
+hood by Docker Engine for creating, starting, and stopping containers.
 
 ## What is the `containerd` image store?
 
 The image store is the component responsible for pushing, pulling,
 and storing images on the filesystem.
 
-The classic Docker image store is limited in the types of images that it supports.
-For example, it doesn't support image indices, containing manifest lists.
-When you create multi-platform images, for example,
-the image index resolves all the platform-specific variants of the image.
-An image index is also required when building images with attestations.
-
 The containerd image store extends the range of image types
 that the Docker Engine can natively interact with.
 While this is a low-level architectural change,
@@ -47,27 +39,38 @@ it's a prerequisite for unlocking a range of new use cases, including:
 [2]: https://github.com/containerd/nydus-snapshotter
 [3]: https://github.com/dragonflyoss/image-service
 
-## Enable the containerd image store
+## Classic image store
 
-The containerd image store is enabled by default in Docker Desktop version 4.34
-and later, but only for clean installs or if you perform a factory reset. If
-you upgrade from an earlier version of Docker Desktop, or if you use an older
-version of Docker Desktop you must manually switch to the containerd image
-store.
+The classic image store is Docker's legacy storage backend, replaced by the
+containerd image store. It doesn't support image indices or manifest lists, so
+you can't load multi-platform images locally or build images with attestations.
+
+Most users have no reason to use the classic image store. It's available for
+cases where you need to match older behavior or have compatibility
+requirements.
+
+## Switch image stores
 
-To manually enable this feature in Docker Desktop:
+The containerd image store is enabled by default in Docker Desktop version 4.34
+and later. To switch between image stores:
 
 1. Navigate to **Settings** in Docker Desktop.
-2. In the **General** tab, check **Use containerd for pulling and storing images**.
-3. Select **Apply & Restart**.
+2. In the **General** tab, check or clear the **Use containerd for pulling and storing images** option.
+3. Select **Apply**.
 
-To disable the containerd image store,
-clear the **Use containerd for pulling and storing images** checkbox.
+> [!NOTE]
+>
+> Docker Desktop maintains separate image stores for the classic and containerd image stores.
+> When switching between them, images and containers from the inactive store remain on disk but are hidden until you switch back.
 
 ## Build multi-platform images
 
-The term multi-platform image refers to a bundle of images for multiple different architectures.
-Out of the box, the default builder for Docker Desktop doesn't support building multi-platform images.
+The containerd image store lets you build multi-platform images
+and load them to your local image store:
+
+<script async id="asciicast-ZSUI4Mi2foChLjbevl2dxt5GD" src="https://asciinema.org/a/ZSUI4Mi2foChLjbevl2dxt5GD.js"></script>
+
+Building multi-platform images with the classic image store is not supported:
 
 ```console
 $ docker build --platform=linux/amd64,linux/arm64 .
@@ -76,10 +79,3 @@ ERROR: Multi-platform build is not supported for the docker driver.
 Switch to a different driver, or turn on the containerd image store, and try again.
 Learn more at https://docs.docker.com/go/build-multi-platform/
 ```
-
-Enabling the containerd image store lets you build multi-platform images
-and load them to your local image store:
-
-<script async id="asciicast-ZSUI4Mi2foChLjbevl2dxt5GD" src="https://asciinema.org/a/ZSUI4Mi2foChLjbevl2dxt5GD.js"></script>
-
-
diff --git a/content/manuals/desktop/features/desktop-cli.md b/content/manuals/desktop/features/desktop-cli.md
index 798009755976..4f04bc07ac84 100644
--- a/content/manuals/desktop/features/desktop-cli.md
+++ b/content/manuals/desktop/features/desktop-cli.md
@@ -6,8 +6,6 @@ description: How to use the Docker Desktop CLI
 keywords: cli, docker desktop, macos, windows, linux
 ---
 
-{{< summary-bar feature_name="Docker Desktop CLI" >}}
-
 The Docker Desktop CLI lets you perform key operations such as starting, stopping, restarting, and updating Docker Desktop directly from the command line.
 
 The Docker Desktop CLI provides:
@@ -31,11 +29,12 @@ docker desktop COMMAND [OPTIONS]
 | `status`             | Displays whether Docker Desktop is running or stopped.       |
 | `engine ls`          | Lists available engines (Windows only)   |
 | `engine use`         | Switch between Linux and Windows containers (Windows only) |
-| `update`             | Manage Docker Desktop updates. Available for Mac only with Docker Desktop version 4.38, or all OSs with Docker Desktop version 4.39 and later. |
+| `update`             | Manage Docker Desktop updates. |
 | `logs`               | Print log entries                        |
 | `disable`            | Disable a feature                        |
 | `enable`             | Enable a feature                         | 
 | `version`            | Show the Docker Desktop CLI plugin version information |
-| `module`             | Manage Docker Desktop modules |
+| `kubernetes`         | List Kubernetes images used by Docker Desktop or restart the cluster. Available with Docker Desktop version 4.44 and later.          |
+| `diagnose`           | Diagnose Docker Desktop and upload the diagnostics. Available with Docker Desktop 4.60 and later. |
 
-For more details on each command, see the [Docker Desktop CLI reference](/reference/cli/docker/desktop/_index.md).
+For more details on each command, see the [Docker Desktop CLI reference](/reference/cli/docker/desktop/).
diff --git a/content/manuals/desktop/features/dev-environments/_index.md b/content/manuals/desktop/features/dev-environments/_index.md
deleted file mode 100644
index def2e621485e..000000000000
--- a/content/manuals/desktop/features/dev-environments/_index.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-description: Dev Environments
-keywords: Dev Environments, share, local, Compose
-title: Overview of Dev Environments
-linkTitle: Dev Environments 
-weight: 130
-aliases:
-- /desktop/dev-environments/
-params:
-  sidebar:
-    badge:
-      color: blue
-      text: Beta
----
-
-{{% include "dev-envs-changing.md" %}}
-
-{{< summary-bar feature_name="Dev Environments" >}}
-
-Dev Environments let you create a configurable developer environment with all the code and tools you need to quickly get up and running. 
-
-It uses tools built into code editors that allows Docker to access code mounted into a container rather than on your local host. This isolates the tools, files and running services on your machine allowing multiple versions of them to exist side by side.
-
-You can use Dev Environments through the intuitive GUI in Docker Desktop Dashboard or straight from your terminal with the new [`docker dev` CLI plugin](dev-cli.md).
-
-## Use Dev Environments
-
-To use Dev Environments: 
-1. Navigate to the **Features in Development** tab in **Settings**. 
-2. On the **Beta** tab, select **Turn on Dev Environments**. 
-3. Select **Apply & restart**. 
-
-The Dev Environments tab is now visible in Docker Desktop Dashboard. 
-
-## How does it work?
-
->**Changes to Dev Environments with Docker Desktop 4.13**
->
->Docker has simplified how you configure your dev environment project. All you need to get started is a `compose-dev.yaml` file. If you have an existing project with a `.docker/` folder this is automatically migrated the next time you launch.
-
-Dev Environments is powered by [Docker Compose](/compose/). This allows Dev Environments to take advantage of all the benefits and features of Compose whilst adding an intuitive GUI where you can launch environments with the click of a button.
-
-Every dev environment you want to run needs a `compose-dev.yaml` file which configures your application's services and lives in your project directory. You don't need to be an expert in Docker Compose or write a `compose-dev.yaml` file from scratch as Dev Environments creates a starter `compose-dev.yaml` files based on the main language in your project. 
-
-You can also use the many [sample dev environments](https://github.com/docker/awesome-compose) as a starting point for how to integrate different services. Alternatively, see [Set up a dev environment](set-up.md) for more information. 
-
-## What's next?
-
-Learn how to:
-- [Launch a dev environment](create-dev-env.md)
-- [Set up a dev environment](set-up.md)
-- [Distribute your dev environment](share.md)
diff --git a/content/manuals/desktop/features/dev-environments/create-dev-env.md b/content/manuals/desktop/features/dev-environments/create-dev-env.md
deleted file mode 100644
index 51a833c5d2c0..000000000000
--- a/content/manuals/desktop/features/dev-environments/create-dev-env.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-description: Dev Environments
-keywords: Dev Environments, share, Docker Desktop, Compose, launch
-title: Launch a dev environment
-aliases:
-- /desktop/dev-environments/create-compose-dev-env/
-- /desktop/dev-environments/create-dev-env/
-weight: 10
----
-
-{{% include "dev-envs-changing.md" %}}
-
-You can launch a dev environment from a:
-- Git repository
-- Branch or tag of a Git repository
-- Sub-folder of a Git repository
-- Local folder
-
-This does not conflict with any of the local files or local tooling set up on your host. 
-
->Tip
->
->Install the [Dev Environments browser extension](https://github.com/docker/dev-envs-extension) for [Chrome](https://chrome.google.com/webstore/detail/docker-dev-environments/gnagpachnalcofcblcgdbofnfakdbeka) or [Firefox](https://addons.mozilla.org/en-US/firefox/addon/docker-dev-environments/), to launch a dev environment faster.
-
-## Prerequisites
-
-To get started with Dev Environments, you must also install the following tools and extension on your machine:
-
-- [Git](https://git-scm.com). Make sure add Git to your PATH if you're a Windows user. 
-- [Visual Studio Code](https://code.visualstudio.com/)
-- [Visual Studio Code Remote Containers Extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers)
-
- After Git is installed, restart Docker Desktop. Select **Quit Docker Desktop**, and then start it again.
-
-## Launch a dev environment from a Git repository
-
-> [!NOTE]
->
-> When cloning a Git repository using SSH, ensure you've added your SSH key to the ssh-agent. To do this, open a terminal and run `ssh-add <path to your private ssh key>`.
-
-> [!IMPORTANT]
->
-> If you have enabled the WSL 2 integration in Docker Desktop for Windows, make sure you have an SSH agent running in your WSL 2 distribution.
-
-{{< accordion title="How to start an SSH agent in WSL 2" >}}
-
-If your WSL 2 distribution doesn't have an `ssh-agent` running, you can append this script at the end of your profile file (that is: ~/.profile, ~/.zshrc, ...).
-
-```bash
-SSH_ENV="$HOME/.ssh/agent-environment"
-function start_agent {
-    echo "Initializing new SSH agent..."
-    /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
-    echo succeeded
-    chmod 600 "${SSH_ENV}"
-    . "${SSH_ENV}" > /dev/null
-}
-# Source SSH settings, if applicable
-if [ -f "${SSH_ENV}" ]; then
-    . "${SSH_ENV}" > /dev/null
-    ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
-        start_agent;
-    }
-else
-    start_agent;
-fi
-```
-
-{{< /accordion >}}
-
-To launch a dev environment:
-
-1. From the **Dev Environments** tab in Docker Dashboard, select **Create**. The **Create a Dev Environment** dialog displays.
-2. Select **Get Started**. 
-3. Optional: Provide a name for you dev environment.
-4. Select **Existing Git repo** as the source and then paste your Git repository link into the field provided.
-5. Choose your IDE. You can choose either:
-    - **Visual Studio Code**. The Git repository is cloned into a Volume and attaches to your containers. This allows you to develop directly inside of them using Visual Studio Code.
-    - **Other**. The Git repository is cloned into your chosen local directory and attaches to your containers as a bind mount. This shares the directory from your computer to the container, and allows you to develop using any local editor or IDE.
-6. Select **Continue**.
-
-To launch the application, run the command `make run` in your terminal. This opens an http server on port 8080. Open [http://localhost:8080](http://localhost:8080) in your browser to see the running application.
-
-
-## Launch from a specific branch or tag
-
-You can launch a dev environment from a specific branch, for example a branch corresponding to a Pull Request, or a tag by adding `@mybranch` or `@tag` as a suffix to your Git URL:
-
- `https://github.com/dockersamples/single-dev-env@mybranch`
-
- or
-
- `git@github.com:dockersamples/single-dev-env.git@mybranch`
-
-Docker then clones the repository with your specified branch or tag.
-
-## Launch from a subfolder of a Git repository
-
->Note
->
->Currently, Dev Environments is not able to detect the main language of the subdirectory. You need to define your own base image or services in a `compose-dev.yaml`file located in your subdirectory. For more information on how to configure, see the [React application with a Spring backend and a MySQL database sample](https://github.com/docker/awesome-compose/tree/master/react-java-mysql) or the [Go server with an Nginx proxy and a Postgres database sample](https://github.com/docker/awesome-compose/tree/master/nginx-golang-postgres). 
-
-1. From **Dev Environments** in Docker Dashboard, select **Create**. The **Create a Dev Environment** dialog displays.
-2. Select **Get Started**.
-3. Optional: Provide a name for you dev environment.
-4. Select **Existing Git repo** as the source and then paste the link of your Git repo subfolder into the field provided.
-5. Choose your IDE. You can choose either:
-    - **Visual Studio Code**. The Git repository is cloned into a Volume and attaches to your containers. This allows you to develop directly inside of them using Visual Studio Code.
-    - **Other**. The Git repository is cloned into your chosen local directory and attaches to your containers as a bind mount. This shares the directory from your computer to the container, and allows you to develop using any local editor or IDE.
-6. Select **Continue**.
-
-To launch the application, run the command `make run` in your terminal. This opens an http server on port 8080. Open [http://localhost:8080](http://localhost:8080) in your browser to see the running application.
-
-## Launch from a local folder
-
-1. From **Dev Environments** in Docker Dashboard, select **Create**. The **Create a Dev Environment** dialog displays.
-2. Select **Get Started**.
-3. Optional: Provide a name for your dev environment.
-4. Choose **Local directory** as the source.
-5. Select **Select** to open the root directory of the code that you would like to work on.
-   
-   A directory from your computer is bind mounted to the container, so any changes you make locally is reflected in the dev environment. You can use an editor or IDE of your choice.
-
-> [!NOTE]
->
-> When using a local folder for a dev environment, file changes are synchronized between your environment container and your local files. This can affect the performance inside the container, depending on the number of files in your local folder and the operations performed in the container.
-
-## What's next?
-
-Learn how to:
-- [Set up a dev environment](set-up.md)
-- [Distribute your dev environment](share.md)
diff --git a/content/manuals/desktop/features/dev-environments/dev-cli.md b/content/manuals/desktop/features/dev-environments/dev-cli.md
deleted file mode 100644
index 2f7d66d5f9aa..000000000000
--- a/content/manuals/desktop/features/dev-environments/dev-cli.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-description: Set up a dev Environments
-keywords: Dev Environments, share, docker dev, Docker Desktop
-title: Use the docker dev CLI plugin
-aliases:
-- /desktop/dev-environments/dev-cli/
----
-
-{{% include "dev-envs-changing.md" %}}
-
-Use the new `docker dev` CLI plugin to get the full Dev Environments experience from the terminal in addition to the Dashboard.
-
-It is available with [Docker Desktop 4.13.0 and later](/manuals/desktop/release-notes.md). 
-
-### Usage
-
-```bash
-docker dev [OPTIONS] COMMAND
-```
-
-### Commands
-
-| Command              | Description                              |
-|:---------------------|:-----------------------------------------|
-| `check`              | Check Dev Environments                   |
-| `create`             | Create a new dev environment             |
-| `list`               | Lists all dev environments               |
-| `logs`               | Traces logs from a dev environment       |
-| `open`               | Open Dev Environment with the IDE        |
-| `rm`                 | Removes a dev environment                |
-| `start`              | Starts a dev environment                 |
-| `stop`               | Stops a dev environment                  |
-| `version`            | Shows the Docker Dev version information |
-
-### `docker dev check`
-
-#### Usage
-
-`docker dev check [OPTIONS]`
-
-#### Options
-
-| Name, shorthand      | Description                         |
-|:---------------------|:------------------------------------|
-| `--format`,`-f`      | Format the output.                  |
-
-### `docker dev create`
-
-#### Usage
-
-`docker dev create [OPTIONS] REPOSITORY_URL`
-
-#### Options
-
-| Name, shorthand      | Description                                               |
-|:---------------------|:----------------------------------------------------------|
-| `--detach`,`-d`      | Detach creates a Dev Env without attaching to it's logs.  |
-| `--open`,`-o`        | Open IDE after a successful creation                      |
-
-### `docker dev list`
-
-#### Usage
-
-`docker dev list [OPTIONS]`
-
-#### Options
-
-| Name, shorthand      | Description                   |
-|:---------------------|:------------------------------|
-| `--format`,`-f`      | Format the output             |
-| `--quiet`,`-q`       | Only show dev environments names  |
-
-### `docker dev logs`
-
-#### Usage
-
-`docker dev logs [OPTIONS] DEV_ENV_NAME`
-
-### `docker dev open`
-
-#### Usage
-
-`docker dev open DEV_ENV_NAME CONTAINER_REF [OPTIONS]`
-
-#### Options
-
-| Name, shorthand      | Description           |
-|:---------------------|:----------------------|
-| `--editor`,`-e`      | Editor.               |
-
-### `docker dev rm`
-
-#### Usage
-
-`docker dev rm DEV_ENV_NAME`
-
-### `docker dev start`
-
-#### Usage
-
-`docker dev start DEV_ENV_NAME`
-
-### `docker dev stop`
-
-#### Usage
-
-`docker dev stop DEV_ENV_NAME`
-
-### `docker dev version`
-
-#### Usage
-
-`docker dev version [OPTIONS]`
-
-#### Options
-
-| Name, shorthand      | Description                                   |
-|:---------------------|:----------------------------------------------|
-| `--format`,`-f`      | Format the output.                            |
-| `--short`,`-s`       | Shows only Docker Dev's version number.       |
diff --git a/content/manuals/desktop/features/dev-environments/set-up.md b/content/manuals/desktop/features/dev-environments/set-up.md
deleted file mode 100644
index 8239abb9343d..000000000000
--- a/content/manuals/desktop/features/dev-environments/set-up.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-description: Set up a dev Environments
-keywords: Dev Environments, share, set up, Compose, Docker Desktop
-title: Set up a dev environment
-weight: 20
-aliases:
-- /desktop/dev-environments/set-up/
----
-
-{{% include "dev-envs-changing.md" %}}
-
->**Changes to Dev Environments with Docker Desktop 4.13**
->
->Docker has simplified how you configure your dev environment project. All you need to get started is a `compose-dev.yaml` file. If you have an existing project with a `.docker/` folder this is automatically migrated the next time you launch.
->
-> If you are using `.docker/docker-compose.yaml`, we move it to `../compose-dev.yaml`.
->If you are using `.docker/config.json`, we create a `../compose-dev.yaml` file with a single service named "app”. It is configured to use the image or Dockerfile referenced in the JSON as a starting point.
-
-To set up a dev environment, there are additional configuration steps to tell Docker Desktop how to build, start, and use the right image for your services.
-
-Dev Environments use a `compose-dev.yaml` file located at the root of your project. This file allows you to define the image required for a dedicated service, the ports you'd like to expose, along with additional configuration options.
-
-The following is an example `compose-dev.yaml` file.
-
-```yaml
-version: "3.7"
-services:
-  backend:
-    build:
-      context: backend
-      target: development
-    secrets:
-      - db-password
-    depends_on:
-      - db
-  db:
-    image: mariadb
-    restart: always
-    healthcheck:
-      test: [ "CMD", "mysqladmin", "ping", "-h", "127.0.0.1", "--silent" ]
-      interval: 3s
-      retries: 5
-      start_period: 30s
-    secrets:
-      - db-password
-    volumes:
-      - db-data:/var/lib/mysql
-    environment:
-      - MYSQL_DATABASE=example
-      - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/db-password
-    expose:
-      - 3306
-  proxy:
-    build: proxy
-    ports:
-      - 8080:80
-    depends_on:
-      - backend
-volumes:
-  db-data:
-secrets:
-  db-password:
-    file: db/password.txt
-```
-
-In the yaml file, the build context `backend` specifies that that the container should be built using the `development` stage (`target` attribute) of the Dockerfile located in the `backend` directory (`context` attribute)
-
-The `development` stage of the Dockerfile is defined as follows:
-
-```dockerfile
-# syntax=docker/dockerfile:1
-FROM golang:1.16-alpine AS build
-WORKDIR /go/src/github.com/org/repo
-COPY . .
-RUN go build -o server .
-FROM build AS development
-RUN apk update \
-    && apk add git
-CMD ["go", "run", "main.go"]
-FROM alpine:3.12
-EXPOSE 8000
-COPY --from=build /go/src/github.com/org/repo/server /server
-CMD ["/server"]
-```
-
-The `development` target uses a `golang:1.16-alpine` image with all dependencies you need for development. You can start your project directly from VS Code and interact with the others applications or services such as the database or the frontend.
-
-In the example, the Docker Compose files are the same. However, they could be different and the services defined in the main Compose file may use other targets to build or directly reference other images.
-
-## What's next?
-
-Learn how to [distribute your dev environment](share.md)
diff --git a/content/manuals/desktop/features/dev-environments/share.md b/content/manuals/desktop/features/dev-environments/share.md
deleted file mode 100644
index 41bd8c482d47..000000000000
--- a/content/manuals/desktop/features/dev-environments/share.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-description: Dev Environments
-keywords: Dev Environments, share, Docker Desktop
-title: Distribute your dev environment
-weight: 30
-aliases:
-- /desktop/dev-environments/share/
----
-
-{{% include "dev-envs-changing.md" %}}
-
-The `compose-dev.yaml` config file makes distributing your dev environment easy so everyone can access the same code and any dependencies.
-
-### Distribute your dev environment
-
-When you are ready to share your environment, simply copy the link to the Github repo where your project is stored, and share the link with your team members. 
-
-You can also create a link that automatically starts your dev environment when opened. This can then be placed on a GitHub README or pasted into a Slack channel, for example. 
-
-To create the link simply join the following link with the link to your dev environment's GitHub repository:
-
-`https://open.docker.com/dashboard/dev-envs?url=`
-
-The following example opens a [Compose sample](https://github.com/docker/awesome-compose/tree/master/nginx-golang-mysql), a Go server with an Nginx proxy and a MariaDB/MySQL database, in Docker Desktop.
-
-[https://open.docker.com/dashboard/dev-envs?url=https://github.com/docker/awesome-compose/tree/master/nginx-golang-mysql](https://open.docker.com/dashboard/dev-envs?url=https://github.com/docker/awesome-compose/tree/master/nginx-golang-mysql)
-
-### Open a dev environment that has been distributed to you
-
-To open a dev environment that has been shared with you, select the **Create** button in the top right-hand corner, select source **Existing Git repo**, and then paste the URL.
diff --git a/content/manuals/desktop/features/gpu.md b/content/manuals/desktop/features/gpu.md
index 6e69184205fe..661d31e3566c 100644
--- a/content/manuals/desktop/features/gpu.md
+++ b/content/manuals/desktop/features/gpu.md
@@ -11,7 +11,7 @@ aliases:
 
 > [!NOTE]
 >
-> Currently GPU support in Docker Desktop is only available on Windows with the WSL2 backend.
+> GPU support in Docker Desktop is only available on Windows with the WSL2 backend.
 
 Docker Desktop for Windows supports NVIDIA GPU Paravirtualization (GPU-PV) on NVIDIA GPUs, allowing containers to access GPU resources for compute-intensive workloads like AI, machine learning, or video processing.
 
@@ -63,16 +63,28 @@ GPU Device 0: "GeForce RTX 2060 with Max-Q Design" with compute capability 7.5
 = 2724.379 single-precision GFLOP/s at 20 flops per interaction
 ```
 
-## Run a real-world model: Llama2 with Ollama
+## Run a real-world model: SmolLM2 with Docker Model Runner
 
-Use the [official Ollama image](https://hub.docker.com/r/ollama/ollama) to run the Llama2 LLM with GPU acceleration:
+Use Docker Model Runner to run the SmolLM2 LLM with vLLM and GPU acceleration:
 
 ```console
-$ docker run --gpus=all -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
+$ docker model install-runner --backend vllm --gpu cuda
 ```
 
-Then start the model:
+Check it's correctly installed:
 
 ```console
-$ docker exec -it ollama ollama run llama2
+$ docker model status
+Docker Model Runner is running
+
+Status:
+llama.cpp: running llama.cpp version: c22473b
+vllm: running vllm version: 0.11.0
+```
+
+Run the model:
+
+```console
+$ docker model run ai/smollm2-vllm hi
+Hello! I'm sure everything goes smoothly here. How can I assist you today?
 ```
diff --git a/content/manuals/desktop/features/kubernetes.md b/content/manuals/desktop/features/kubernetes.md
deleted file mode 100644
index 1a7f77313e15..000000000000
--- a/content/manuals/desktop/features/kubernetes.md
+++ /dev/null
@@ -1,151 +0,0 @@
----
-description: See how you can deploy to Kubernetes on Docker Desktop
-keywords: deploy, kubernetes, kubectl, orchestration, Docker Desktop
-title: Deploy on Kubernetes with Docker Desktop
-linkTitle: Deploy on Kubernetes
-aliases:
-- /docker-for-windows/kubernetes/
-- /docker-for-mac/kubernetes/
-- /desktop/kubernetes/
-weight: 60
----
-
-Docker Desktop includes a standalone Kubernetes server and client, as well as Docker CLI integration, enabling local Kubernetes development and testing directly on your machine.
-
-The Kubernetes server runs as a single or multi-node cluster, within Docker container(s). This lightweight setup helps you explore Kubernetes features, test workloads, and work with container orchestration in parallel with other Docker functionalities.
-
-Kubernetes on Docker Desktop runs alongside other workloads, including Swarm services and standalone containers.
-
-![k8s settings](../images/k8s-settings.png)
-
-## What happens when I enable Kubernetes in Docker Desktop?
-
-The following actions are triggered in the Docker Desktop backend and VM:
-
-- Generation of certificates and cluster configuration
-- Download and installation of Kubernetes internal components
-- Cluster bootup
-- Installation of additional controllers for networking and storage
-
-Turning the Kubernetes server on or off in Docker Desktop does not affect your other workloads.
-
-## Install and turn on Kubernetes
-
-1. Open the Docker Desktop Dashboard and navigate to **Settings**.
-2. Select the **Kubernetes** tab.
-3. Toggle on **Enable Kubernetes**.
-4. Choose your [cluster provisioning method](#cluster-provisioning-method).
-5. Select **Apply & Restart** to save the settings.
-
-This sets up the images required to run the Kubernetes server as containers, and installs the `kubectl` command-line tool on your system at `/usr/local/bin/kubectl` (Mac) or `C:\Program Files\Docker\Docker\resources\bin\kubectl.exe` (Windows).
-
-   > [!NOTE]
-   >
-   > Docker Desktop for Linux does not include `kubectl` by default. You can install it separately by following the [Kubernetes installation guide](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/). Ensure the `kubectl` binary is installed at `/usr/local/bin/kubectl`.
-
-When Kubernetes is enabled, its status is displayed in the Docker Desktop Dashboard footer and the Docker menu.
-
-You can check which version of Kubernetes you're on with:
-
-```console
-$ kubectl version
-```
-
-### Cluster provisioning method
-
-Docker Desktop Kubernetes can be provisioned with either the `kubeadm` or `kind`
-provisioners.
-
-`kubeadm` is the older provisioner. It supports a single-node cluster, you can't select the kubernetes
-version, it's slower to provision than `kind`, and it's not supported by [Enhanced Container Isolation](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/index.md) (ECI),
-meaning that if ECI is enabled the cluster works but it's not protected by ECI.
-
-`kind` is the newer provisioner, and it's available if you are signed in and are
-using Docker Desktop version 4.38 or later. It supports multi-node clusters (for
-a more realistic Kubernetes setup), you can choose the Kubernetes version, it's
-faster to provision than `kubeadm`, and it's supported by ECI (i.e., when ECI is
-enabled, the Kubernetes cluster runs in unprivileged Docker containers, thus
-making it more secure). Note however that `kind` requires that Docker Desktop be
-configured to use the [containerd image store](containerd.md) (the default image
-store in Docker Desktop 4.34 and later).
-
-The following table summarizes this comparison.
-
-| Feature | `kubeadm` | `kind` |
-| :------ | :-----: | :--: |
-| Availability | Docker Desktop 4.0+ | Docker Desktop 4.38+ (requires sign in) |
-| Multi-node cluster support | No | Yes |
-| Kubernetes version selector | No | Yes |
-| Speed to provision | ~1 min | ~30 seconds |
-| Supported by ECI | No | Yes |
-| Works with containerd image store | Yes | Yes |
-| Works with Docker image store | Yes | No |
-
-### Additional settings
-
-#### Viewing system containers
-
-By default, Kubernetes system containers are hidden. To inspect these containers, enable **Show system containers (advanced)**.
-
-You can now view the running Kubernetes containers with `docker ps` or in the Docker Desktop Dashboard.
-
-## Using the kubectl command
-
-Kubernetes integration automatically installs the Kubernetes CLI command
-at `/usr/local/bin/kubectl` on Mac and at `C:\Program Files\Docker\Docker\Resources\bin\kubectl.exe` on Windows. This location may not be in your shell's `PATH`
-variable, so you may need to type the full path of the command or add it to
-the `PATH`.
-
-If you have already installed `kubectl` and it is
-pointing to some other environment, such as `minikube` or a Google Kubernetes Engine cluster, ensure you change the context so that `kubectl` is pointing to `docker-desktop`:
-
-```console
-$ kubectl config get-contexts
-$ kubectl config use-context docker-desktop
-```
-
-> [!TIP]
->
-> If the `kubectl` config get-contexts command returns an empty result, try:
->
-> - Running the command in the Command Prompt or PowerShell.
-> - Setting the `KUBECONFIG` environment variable to point to your `.kube/config` file.
-
-### Verify installation
-
-To confirm that Kubernetes is running, list the available nodes:
-
-```console
-$ kubectl get nodes
-NAME                 STATUS    ROLES            AGE       VERSION
-docker-desktop       Ready     control-plane    3h        v1.29.1
-```
-
-If you installed `kubectl` using Homebrew, or by some other method, and
-experience conflicts, remove `/usr/local/bin/kubectl`.
-
-For more information about `kubectl`, see the
-[`kubectl` documentation](https://kubernetes.io/docs/reference/kubectl/overview/).
-
-## Upgrade your cluster
-
-Kubernetes clusters are not automatically upgraded with Docker Desktop updates. To upgrade the cluster, you must manually select **Reset Kubernetes Cluster** in settings.
-
-## Troubleshooting
-
-- If Kubernetes fails to start, make sure Docker Desktop is running with enough allocated resources. Check **Settings** > **Resources**.
-- If the `kubectl` commands return errors, confirm the context is set to `docker-desktop`
-   ```console
-   $ kubectl config use-context docker-desktop
-   ```
-   You can then try checking the logs of the [Kubernetes system containers](#viewing-system-containers) if you have enabled that setting.
-- If you're experiencing cluster issues after updating, reset your Kubernetes cluster. Resetting a Kubernetes cluster can help resolve issues by essentially reverting the cluster to a clean state, and clearing out misconfigurations, corrupted data, or stuck resources that may be causing problems. If the issue still persists, you may need to clean and purge data, and then restart Docker Desktop.
-
-## Turn off and uninstall Kubernetes
-
-To turn off Kubernetes in Docker Desktop:
-
-1. From the Docker Desktop Dashboard, select the **Settings** icon.
-2. Select the **Kubernetes** tab.
-3. Deselect the **Enable Kubernetes** checkbox.
-4. Select **Apply & Restart** to save the settings. This stops and removes Kubernetes containers, and also removes the `/usr/local/bin/kubectl` command.
diff --git a/content/manuals/desktop/features/networking.md b/content/manuals/desktop/features/networking.md
deleted file mode 100644
index 58d9a73c9b3e..000000000000
--- a/content/manuals/desktop/features/networking.md
+++ /dev/null
@@ -1,187 +0,0 @@
----
-description: Understand how networking works on Docker Desktop and see the known limitations
-keywords: networking, docker desktop, proxy, vpn, Linux, Mac, Windows
-title: Explore networking features on Docker Desktop
-linkTitle: Networking
-aliases:
-- /desktop/linux/networking/
-- /docker-for-mac/networking/
-- /mackit/networking/
-- /desktop/mac/networking/
-- /docker-for-win/networking/
-- /docker-for-windows/networking/
-- /desktop/windows/networking/
-- /desktop/networking/
-weight: 30
----
-
-Docker Desktop includes built-in networking capabilities to help you connect containers with services on your host, across containers, or through proxies and VPNs.
-
-## Networking features for all platforms
-
-### VPN Passthrough
-
-Docker Desktop networking can work when attached to a VPN. To do this,
-Docker Desktop intercepts traffic from the containers and injects it into
-the host as if it originated from the Docker application.
-
-### Port mapping
-
-When you run a container with the `-p` argument, for example:
-
-```console
-$ docker run -p 80:80 -d nginx
-```
-
-Docker Desktop makes whatever is running on port `80` in the container, in
-this case, `nginx`, available on port `80` of `localhost`. In this example, the
-host and container ports are the same. 
-
-To avoid conflicts with services already using port `80` on the host:
-
-```console
-$ docker run -p 8000:80 -d nginx
-```
-
-Now connections to `localhost:8000` are sent to port `80` in the container. 
-
-> [!TIP]
->
-> The syntax for `-p` is `HOST_PORT:CLIENT_PORT`.
-
-### HTTP/HTTPS Proxy support
-
-See [Proxies](/manuals/desktop/settings-and-maintenance/settings.md#proxies)
-
-### SOCKS5 proxy support
-
-{{< summary-bar feature_name="SOCKS5 proxy support" >}}
-
-SOCKS (Socket Secure) is a protocol that facilitates the routing of network packets between a client and a server through a proxy server. It provides a way to enhance privacy, security, and network performance for users and applications. 
-
-You can enable SOCKS proxy support to allow outgoing requests, such as pulling images, and access Linux container backend IPs from the host. 
-
-To enable and set up SOCKS proxy support:
-
-1. Navigate to the **Resources** tab in **Settings**. 
-2. From the dropdown menu select **Proxies**.
-3. Switch on the **Manual proxy configuration** toggle. 
-4. In the **Secure Web Server HTTPS** box, paste your `socks5://host:port` URL.
-
-## Networking features for Mac and Linux
-
-### SSH agent forwarding
-
-Docker Desktop for Mac and Linux lets you use the host’s SSH agent inside a container. To do this:
-
-1. Bind mount the SSH agent socket by adding the following parameter to your `docker run` command:
-
-   ```console
-   $--mount type=bind,src=/run/host-services/ssh-auth.sock,target=/run/host-services/ssh-auth.sock
-   ```
-
-2. Add the `SSH_AUTH_SOCK` environment variable in your container:
-
-    ```console
-    $ -e SSH_AUTH_SOCK="/run/host-services/ssh-auth.sock"
-    ```
-
-To enable the SSH agent in Docker Compose, add the following flags to your service:
-
- ```yaml
-services:
-  web:
-    image: nginx:alpine
-    volumes:
-      - type: bind
-        source: /run/host-services/ssh-auth.sock
-        target: /run/host-services/ssh-auth.sock
-    environment:
-      - SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock
- ```
-
-## Known limitations
-
-### Changing internal IP addresses
-
-The internal IP addresses used by Docker can be changed from **Settings**. After changing IPs, you need to reset the Kubernetes cluster and to leave any active Swarm.
-
-### There is no `docker0` bridge on the host
-
-Because of the way networking is implemented in Docker Desktop, you cannot
-see a `docker0` interface on the host. This interface is actually within the
-virtual machine.
-
-### I cannot ping my containers
-
-Docker Desktop can't route traffic to Linux containers. However if you're a Windows user, you can
-ping the Windows containers.
-
-### Per-container IP addressing is not possible
-
-This is because the Docker `bridge` network is not reachable from the host.
-However if you are a Windows user, per-container IP addressing is possible with Windows containers.
-
-## Use cases and workarounds 
-
-### I want to connect from a container to a service on the host
-
-The host has a changing IP address, or none if you have no network access.
-Docker recommends you connect to the special DNS name `host.docker.internal`,
-which resolves to the internal IP address used by the host.
-
-You can also reach the gateway using `gateway.docker.internal`.
-
-If you have installed Python on your machine, use the following instructions as an example to connect from a container to a service on the host:
-
-1. Run the following command to start a simple HTTP server on port 8000.
-
-    `python -m http.server 8000`
-
-    If you have installed Python 2.x, run `python -m SimpleHTTPServer 8000`.
-
-2. Now, run a container, install `curl`, and try to connect to the host using the following commands:
-
-    ```console
-    $ docker run --rm -it alpine sh
-    # apk add curl
-    # curl http://host.docker.internal:8000
-    # exit
-    ```
-
-### I want to connect to a container from the host
-
-Port forwarding works for `localhost`. `--publish`, `-p`, or `-P` all work.
-Ports exposed from Linux are forwarded to the host.
-
-Docker recommends you publish a port, or to connect from another
-container. This is what you need to do even on Linux if the container is on an
-overlay network, not a bridge network, as these are not routed.
-
-For example, to run an `nginx` webserver:
-
-```console
-$ docker run -d -p 80:80 --name webserver nginx
-```
-
-To clarify the syntax, the following two commands both publish container's port `80` to host's port `8000`:
-
-```console
-$ docker run --publish 8000:80 --name webserver nginx
-
-$ docker run -p 8000:80 --name webserver nginx
-```
-
-To publish all ports, use the `-P` flag. For example, the following command
-starts a container (in detached mode) and the `-P` flag publishes all exposed ports of the
-container to random ports on the host.
-
-```console
-$ docker run -d -P --name webserver nginx
-```
-
-Alternatively, you can also use [host networking](/manuals/engine/network/drivers/host.md#docker-desktop)
-to give the container direct access to the network stack of the host.
-
-See the [run command](/reference/cli/docker/container/run.md) for more details on
-publish options used with `docker run`.
diff --git a/content/manuals/desktop/features/networking/_index.md b/content/manuals/desktop/features/networking/_index.md
new file mode 100644
index 000000000000..4f69cc9800fb
--- /dev/null
+++ b/content/manuals/desktop/features/networking/_index.md
@@ -0,0 +1,91 @@
+---
+description: Understand how Docker Desktop handles networking, firewalls, file access, proxies, and endpoint visibility.
+keywords: docker desktop, networking, architecture, firewall, proxies, crowdstrike, vpn
+title: Networking on Docker Desktop
+linkTitle: Networking
+weight: 30
+---
+
+This page explains how Docker Desktop routes network traffic and file I/O between containers, the VM, and the host, and how this behavior is visible to firewalls and endpoint protection tools.
+
+## Overview
+
+Docker Desktop runs the Docker Engine inside a lightweight Linux virtual machine (VM). Depending on your system configuration and operating system, Docker Desktop routes network and file operations between the Docker VM and the host using different backend components.
+
+### Backend components and responsibilities
+
+The backend acts as:
+
+- Network proxy: Translates traffic between the host and Linux VM.
+  - On Windows and Mac, this is handled by the `com.docker.backend` process.
+  - On Linux, the `qemu` process performs this function.
+- File server: Handles file access from containers to the host filesystem.
+  - When using gRPC FUSE, the backend performs the file sharing.
+  - When using `virtiofs`, or `krun`, file access is handled by those respective daemons rather than the backend process.
+- Control plane: Manages Docker API calls, port forwarding, and proxy configuration.
+
+The following table summarizes typical setups in more detail:
+
+| Platform        | Setup                                 | Networking handled by    | File sharing handled by                | Notes                                                      |
+| --------------- | ------------------------------------- | ------------------------ | -------------------------------------- | ---------------------------------------------------------- |
+| Windows         | Hyper-V                               | `com.docker.backend.exe` | `com.docker.backend.exe`               | Simplest setup with full visibility to EDR/firewall tools  |
+| Windows (WSL 2) | WSL 2                                 | `com.docker.backend.exe` | WSL 2 kernel (no visibility from host) | Recommended only when WSL 2 integration is needed          |
+| Mac             | Virtualization framework + gRPC FUSE  | `com.docker.backend`     | `com.docker.backend`                   | Recommended for performance and visibility                 |
+| Mac             | Virtualization framework + `virtiofs` | `com.docker.backend`     | Apple's Virtualization framework       | Higher performance but no file access visibility from host |
+| Mac             | DockerVMM + `virtiofs`                | `com.docker.backend`     | `krun`                                 | Currently in Beta                                          |
+| Linux           | Native Linux VM                       | `qemu`                   | `virtiofsd`                            | No `com.docker.backend` process on Linux                   |
+
+## How containers connect to the internet
+
+Each Linux container in Docker Desktop runs inside a small virtual network managed by Docker and every container is attached to a Docker-managed network and receives its own internal IP address. You can view and manage these networks with `docker network ls`, `docker network create`, and `docker network inspect`. They are managed by the [`daemon.json`](/manuals/engine/daemon/_index.md).
+
+When a container initiates a network request, for example with `apt-get update` or `docker pull`:
+
+- The container’s `eth0` interface connects to a virtual bridge (`docker0`) inside the VM.
+- Outbound traffic from the container is sent through Network Address Translation (NAT) using a virtual adapter (typically with an internal IP such as `192.168.65.3`). You can view or change this with the [Docker Desktop settings](/manuals/desktop/settings-and-maintenance/settings.md#network).
+- The traffic is transferred to the host system over a shared-memory channel rather than through a traditional virtual network interface. This approach ensures reliable communication and avoids conflicts with host-level network adapters or firewall configurations.
+- On the host, Docker Desktop’s backend process receives the traffic and creates standard TCP/IP connections using the same networking APIs as other applications.
+
+All outbound container network traffic originates from the `com.docker.backend` process. Firewalls, VPNs, and security tools, like CrowdStrike, see traffic coming from this process — not from a VM or unknown source so firewall and endpoint security software can apply rules directly to `com.docker.backend`.
+
+## How exposed ports work
+
+When you publish a container port using the `-p` or `--publish` flag, Docker Desktop makes that container port accessible from your host system or local network.
+
+For example, with `docker run -p 80:80 nginx`:
+
+- Docker Desktop's backend process listens on the specified host port, in this case, port `80`.
+- When an application such as a web browser connects to that port, Docker Desktop forwards the connection into the Linux VM where the container is running over a shared-memory channel.
+- Inside the VM, the connection is routed to the container’s internal IP address and port, for example `172.17.0.2:80`.
+- The container responds through the same path, so you can access it from your host just like any other local service.
+
+By default, `docker run -p` listens on all network interfaces (`0.0.0.0`), but you can restrict it to a specific address, such as `127.0.0.1` (`localhost`) or a particular network adapter. This behavior can be modified to bind to `localhost` by default in [Docker Desktop's network settings](/manuals/desktop/settings-and-maintenance/settings.md#network)
+
+Host firewalls can permit or deny inbound connections by filtering on `com.docker.backend`.
+
+## Using Docker Desktop with a proxy
+
+Docker Desktop can use your system’s default proxy settings or custom settings that you configure with [Docker Desktop’s proxy setting](/manuals/desktop/settings-and-maintenance/settings.md#proxies).
+
+Docker Desktop routes traffic through two separate proxies. The Containers proxy governs all `docker image pull` operations, as well as running container traffic when air-gapped container enforcement is enabled. The Docker Desktop proxy governs host-level traffic - the Desktop application, Docker CLI, and extensions — and is a fallback for image pulls only when the Containers proxy is not explicitly configured.
+
+Note that:
+
+- The proxy honors system or manual proxy configuration.
+- On Windows, Basic, NTLM, and Kerberos authentication is supported.
+- For Mac, NTLM/Kerberos is not supported natively. Run a local proxy on `localhost` as a workaround.
+- CLI plugins and other tools that use the Docker API directly must be configured separately with the `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` environment variables.
+
+## Firewalls and endpoint visibility
+
+To restrict VM or container networking apply rules to `com.docker.backend.exe` (Windows) `com.docker.backend` (Mac) or `qemu` (Linux) as all VM networking is funneled through these processes.
+
+Use Windows Defender Firewall or enterprise endpoint firewalls for control. This enables traffic inspection and restriction at the host level without modifying the Docker Engine.
+
+CrowdStrike and similar tools can observe all traffic and file access that passes through the backend process.
+
+| Action                                       | Visible to host EDR? | Reason                                 |
+| -------------------------------------------- | -------------------- | -------------------------------------- |
+| Container reads host files                   | Yes                  | Access handled by `com.docker.backend` |
+| Container writes host files                  | Yes                  | Same process performs the write        |
+| Container accesses its own filesystem layers | No                   | Exists only inside the VM              |
diff --git a/content/manuals/desktop/features/networking/networking-how-tos.md b/content/manuals/desktop/features/networking/networking-how-tos.md
new file mode 100644
index 000000000000..6591a3abb671
--- /dev/null
+++ b/content/manuals/desktop/features/networking/networking-how-tos.md
@@ -0,0 +1,183 @@
+---
+description: Learn how to connect containers to the host, across containers, or through proxies and VPNs in Docker Desktop.
+keywords: docker desktop, networking, vpn, proxy, port mapping, dns
+title: Explore networking how-tos on Docker Desktop
+linkTitle: How-tos
+aliases:
+- /desktop/networking/
+---
+
+This page explains how to configure and use networking features, connect containers to host services, work behind proxies or VPNs, and troubleshoot common issues.
+
+For details on how Docker Desktop routes network traffic and file I/O between containers, the VM, and the host, see [Network overview](/manuals/desktop/features/networking/_index.md#overview).
+
+## Core networking how-tos
+
+### Connect a container to a service on the host
+
+The host has a changing IP address, or none if you have no network access. To connect to services running on your host, use the special DNS name:
+
+| Name                      | Description                                      |
+| ------------------------- | ------------------------------------------------ |
+| `host.docker.internal`    | Resolves to the internal IP address of your host |
+| `gateway.docker.internal` | Resolves to the gateway IP of the Docker VM      |
+
+
+#### Example
+
+Run a simple HTTP server on port `8000`:
+
+```console
+$ python -m http.server 8000
+```
+
+Then run a container, install `curl`, and try to connect to the host using the following commands:
+
+```console
+$ docker run --rm -it alpine sh
+# apk add curl
+# curl http://host.docker.internal:8000
+# exit
+```
+
+### Connect to a container from the host
+
+To access containerized services from your host or local network, publish ports with the `-p` or `--publish` flag. For example:
+
+```console
+$ docker run -d -p 80:80 --name webserver nginx
+```
+
+Docker Desktop makes whatever is running on port `80` in the container, in
+this case, `nginx`, available on port `80` of `localhost`. 
+
+> [!TIP]
+>
+> The syntax for `-p` is `HOST_PORT:CLIENT_PORT`.
+
+To publish all ports, use the `-P` flag. For example, the following command
+starts a container (in detached mode) and the `-P` flag publishes all exposed ports of the
+container to random ports on the host.
+
+```console
+$ docker run -d -P --name webserver nginx
+``` 
+
+Alternatively, you can also use [host networking](/manuals/engine/network/drivers/host.md#docker-desktop)
+to give the container direct access to the network stack of the host.
+
+See the [run command](/reference/cli/docker/container/run/) for more details on
+publish options used with `docker run`.
+
+All inbound connections pass through the Docker Desktop backend process (`com.docker.backend` (Mac), `com.docker.backend.exe` (Windows), or `qemu` (Linux)), which handles port forwarding into the VM.
+For more details, see [How exposed ports work](/manuals/desktop/features/networking/_index.md#how-exposed-ports-work)
+
+### Working with VPNs
+
+Docker Desktop networking can work when attached to a VPN. 
+
+To do this, Docker Desktop intercepts traffic from the containers and injects it into
+the host as if it originated from the Docker application.
+
+For details about how this traffic appears to host firewalls and endpoint detection systems, see [Firewalls and endpoint visibility](/manuals/desktop/features/networking/_index.md#firewalls-and-endpoint-visibility).
+
+### Working with proxies
+
+Docker Desktop can use your system proxy or a manual configuration.
+To configure proxies:
+
+1. Navigate to the **Resources** tab in **Settings**. 
+2. From the dropdown menu select **Proxies**.
+3. Switch on the **Manual proxy configuration** toggle.
+4. Enter your HTTP, HTTPS or SOCKS5 proxy URLS.
+
+For more details on proxies and proxy configurations, see the [Proxy settings documentation](/manuals/desktop/settings-and-maintenance/settings.md#proxies).
+
+## Network how-tos for Mac and Windows
+
+You can control how Docker handles container networking and DNS resolution to better support a range of environments — from IPv4-only to dual-stack and IPv6-only systems. These settings help prevent timeouts and connectivity issues caused by incompatible or misconfigured host networks.
+
+You can set the following settings on the **Network** tab in the Docker Desktop Dashboard settings, or if you're an admin, with Settings Management via the [`admin-settings.json` file](/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md#networking), or [Docker Home](/manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console.md)
+
+> [!NOTE]
+>
+> These settings can be overridden on a per-network basis using CLI flags or Compose file options.
+
+### Default networking mode
+
+Choose the default IP protocol used when Docker creates new networks. This allows you to align Docker with your host’s network capabilities or organizational requirements, such as enforcing IPv6-only access.
+
+| Mode                         | Description                                 |
+| ---------------------------- | ------------------------------------------- |
+| **Dual IPv4/IPv6 (default)** | Supports both IPv4 and IPv6. Most flexible. |
+| **IPv4 only**                | Uses only IPv4 addressing.                  |
+| **IPv6 only**                | Uses only IPv6 addressing.                  |
+
+### DNS resolution behavior 
+
+Control how Docker filters DNS records returned to containers, improving reliability in environments where only IPv4 or IPv6 is supported. This setting is especially useful for preventing apps from trying to connect using IP families that aren't actually available, which can cause avoidable delays or failures.
+
+| Option                         | Description                                                                 |
+| ------------------------------ | --------------------------------------------------------------------------- |
+| **Auto (recommended)**         | Automatically filters unsupported record types. (A for IPv4, AAAA for IPv6) |
+| **Filter IPv4 (A records)**    | Blocks IPv4 lookups. Only available in dual-stack mode.                     |
+| **Filter IPv6 (AAAA records)** | Blocks IPv6 lookups. Only available in dual-stack mode.                     |
+| **No filtering**               | Returns both A and AAAA records.                                            |
+
+> [!IMPORTANT]
+>
+> Switching the default networking mode resets the DNS filter to Auto.
+
+## Network how-tos for Mac and Linux
+
+### SSH agent forwarding
+
+Docker Desktop for Mac and Linux lets you use the host’s SSH agent inside a container. To do this:
+
+1. Bind mount the SSH agent socket by adding the following parameter to your `docker run` command:
+
+   ```console
+   $--mount type=bind,src=/run/host-services/ssh-auth.sock,target=/run/host-services/ssh-auth.sock
+   ```
+
+2. Add the `SSH_AUTH_SOCK` environment variable in your container:
+
+    ```console
+    $ -e SSH_AUTH_SOCK="/run/host-services/ssh-auth.sock"
+    ```
+
+To enable the SSH agent in Docker Compose, add the following flags to your service:
+
+ ```yaml
+services:
+  web:
+    image: nginx:alpine
+    volumes:
+      - type: bind
+        source: /run/host-services/ssh-auth.sock
+        target: /run/host-services/ssh-auth.sock
+    environment:
+      - SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock
+ ```
+
+## Known limitations
+
+### Changing internal IP addresses
+
+The internal IP addresses used by Docker can be changed from **Settings**. After changing IPs, you need to reset the Kubernetes cluster and to leave any active Swarm.
+
+### There is no `docker0` bridge on the host
+
+Because of the way networking is implemented in Docker Desktop, you cannot
+see a `docker0` interface on the host. This interface is actually within the
+virtual machine.
+
+### I cannot ping my containers
+
+Docker Desktop can't route traffic to Linux containers. However if you're a Windows user, you can
+ping the Windows containers.
+
+### Per-container IP addressing is not possible
+
+This is because the Docker `bridge` network is not reachable from the host.
+However if you are a Windows user, per-container IP addressing is possible with Windows containers.
diff --git a/content/manuals/desktop/features/synchronized-file-sharing.md b/content/manuals/desktop/features/synchronized-file-sharing.md
index d0ca03e66eb0..496d20e9dec0 100644
--- a/content/manuals/desktop/features/synchronized-file-sharing.md
+++ b/content/manuals/desktop/features/synchronized-file-sharing.md
@@ -3,21 +3,17 @@ title: Synchronized file shares
 weight: 70
 description: Get started with Synchronized file shares on Docker Desktop.
 keyword: mutagen, file sharing, docker desktop, bind mounts
-aliases:
-- /desktop/synchronized-file-sharing/
 ---
 
 {{< summary-bar feature_name="Synchronized file sharing" >}}
 
 Synchronized file shares is an alternative file sharing mechanism that provides fast and flexible host-to-VM file sharing, enhancing bind mount performance through the use of synchronized filesystem caches. 
-
-![Image of Synchronized file shares pane](../images/synched-file-shares.webp)
  
 ## Who is it for?
 
 Synchronized file shares is ideal for developers who: 
 - Have large repositories or monorepos with 100 000 files or more totaling hundreds of megabytes or even gigabytes.
-- Are using virtual filesystems, such as VirtioFS, gRPC FUSE, and osxfs, which are no longer scaling well with their codebases. 
+- Are using virtual filesystems, such as VirtioFS and gRPC FUSE which are no longer scaling well with their codebases. 
 - Regularly encounter performance limitations.
 - Don't want to worry about file ownership or spend time resolving conflicting file-ownership information when modifying multiple containers.
 
@@ -33,7 +29,7 @@ After creating a file share instance, any container using a bind mount that poin
 
 > [!IMPORTANT]
 >
-> Synchronized file shares isn't available on WSL or when using Windows containers. 
+> Synchronized file shares isn't available when using Windows containers. 
 
 ## Create a file share instance 
 
@@ -49,12 +45,7 @@ When the status indicator displays **Watching for filesystem changes**, your fil
 
 > [!NOTE]
 >
-> When you create a new service, setting the [bind mount option consistency](/reference/cli/docker/service/create.md#options-for-bind-mounts) to `:consistent` bypasses Synchronized file shares. 
-
-> [!TIP]
->
-> Docker Compose can automatically create file shares for bind mounts. 
-> Ensure you're signed in to Docker with a paid subscription and have enabled both **Access experimental features** and **Manage Synchronized file shares with Compose** in Docker Desktop's settings.
+> When you create a new service, setting the [bind mount option consistency](/reference/cli/docker/service/create/#options-for-bind-mounts) to `:consistent` bypasses Synchronized file shares. 
 
 ## Explore your file share instance
 
@@ -82,7 +73,7 @@ In general, use your `.syncignore` file to exclude items that aren't critical to
 
 - Changes made to `.syncignore` don't lead to immediate deletions unless the file share is recreated. In other words, files that are newly ignored due to modifications in the `.syncignore` file remain in their current location, but are no longer updated during synchronization.
 
-- File share instances are currently limited to approximately 2 million files per share. For best performance, if you have a file share instance of this size, try to decompose it into multiple shares corresponding to individual bind mount locations.
+- File share instances are limited to approximately 2 million files per share. For best performance, if you have a file share instance of this size, try to decompose it into multiple shares corresponding to individual bind mount locations.
 
 - Case conflicts, due to Linux being case-sensitive and macOS/Windows only being case-preserving, display as **File exists** problems in the GUI. These can be ignored. However, if they persist, you can report the issue.
 
diff --git a/content/manuals/desktop/features/usbip.md b/content/manuals/desktop/features/usbip.md
index 4e833dd2e054..3606cc41b1f2 100644
--- a/content/manuals/desktop/features/usbip.md
+++ b/content/manuals/desktop/features/usbip.md
@@ -5,8 +5,6 @@ weight: 50
 description: How to use USB/IP in Docker Desktop
 keywords: usb, usbip, docker desktop, macos, windows, linux
 toc_max: 3
-aliases:
-- /desktop/usbip/
 ---
 
 {{< summary-bar feature_name="USB/IP support" >}}
diff --git a/content/manuals/desktop/features/vmm.md b/content/manuals/desktop/features/vmm.md
index 5e977f7c6aab..d8fc0622a8ec 100644
--- a/content/manuals/desktop/features/vmm.md
+++ b/content/manuals/desktop/features/vmm.md
@@ -1,60 +1,90 @@
 ---
-title: Virtual Machine Manager for Docker Desktop on Mac
-linkTitle: Virtual Machine Manager 
-keywords: virtualization software, resource allocation, mac, docker desktop, vm monitoring, vm performance, apple silicon
-description: Discover Docker Desktop for Mac's Virtual Machine Manager (VMM) options, including the new Docker VMM for Apple Silicon, offering enhanced performance and efficiency
+title: Virtual Machine Manager
+linkTitle: Virtual Machine Manager
+keywords: virtualization software, resource allocation, mac, windows, docker desktop, vm performance, apple silicon, wsl, hyper-v
+description: Learn about Docker Desktop's Virtual Machine Manager options, including Docker VMM for Mac and Windows
 weight: 110
-aliases:
-- /desktop/vmm/
+params:
+  sidebar:
+    badge:
+      color: blue
+      text: Updated
 ---
 
-Docker Desktop supports multiple Virtual Machine Managers (VMMs) to power the Linux VM that runs containers. You can choose the most suitable option based on your system architecture (Intel or Apple Silicon), performance needs, and feature requirements. This page provides an overview of the available options.
-
-To change the VMM, go to **Settings** > **General** > **Virtual Machine Manager**.
+Docker Desktop supports multiple Virtual Machine Managers (VMMs) to power the Linux VM that runs containers. The options available depend on your platform.
 
 ## Docker VMM
 
 {{< summary-bar feature_name="VMM" >}}
 
-Docker VMM is a new, container-optimized hypervisor. By optimizing both the Linux kernel and hypervisor layers, Docker VMM delivers significant performance enhancements across common developer tasks.
+Docker VMM is a container-optimized hypervisor. From Docker Desktop 4.86, Docker VMM uses Docker's own hypervisor, replacing `libkrun` used in version 4.35 - 4.85 for Mac users. Built specifically for container workloads, Docker VMM:
 
-Some key performance enhancements provided by Docker VMM include:
- - Faster I/O operations: With a cold cache, iterating over a large shared filesystem with `find` is 2x faster than when the Apple Virtualization framework is used.
- - Improved caching: With a warm cache, performance can improve by as much as 25x, even surpassing native Mac operations.
+- Returns idle memory to the host when containers aren't active, so Docker Desktop doesn't hold RAM it's not using
+- Improves file I/O between container and host, reducing latency in the edit-compile-test loop
+- Reduces engine and container start-up time
 
-These improvements directly impact developers who rely on frequent file access and overall system responsiveness during containerized development. Docker VMM marks a significant leap in speed, enabling smoother workflows and faster iteration cycles.
+Because Docker controls the virtualization layer, it can be monitored and governed in ways that aren't possible with third-party backends. On Windows, Docker VMM provides a stable alternative to WSL 2 with a real VM boundary between the container environment and the host.
 
-> [!NOTE]
->
-> Docker VMM requires a minimum of 4GB of memory to be allocated to the Docker Linux VM. The memory needs to be increased before Docker VMM is enabled, and this can be done from the **Resources** tab in **Settings**.
+### Switch to Docker VMM
+
+Docker VMM requires a minimum of 4 GB of memory allocated to the Docker Linux VM. Increase memory in **Settings** > **Resources** before switching.
+
+{{< tabs >}}
+{{< tab name="Mac (Apple Silicon)" >}}
+
+1. Go to **Settings** > **General** > **Virtual Machine Manager**.
+2. Select **Docker VMM**.
+3. Select **Apply & restart**.
+
+If you previously had Docker VMM selected, which engine runs depends on your version:
+
+- Docker Desktop 4.35 and earlier is backed by `libkrun`
+- Docker Desktop 4.86 and later is backed by Docker's own hypervisor
+
+If you're upgrading from version 4.35 onwards, your setting is preserved and Docker Desktop switches to the new Docker VMM automatically on restart.
+
+{{< /tab >}}
+{{< tab name="Windows" >}}
+
+1. Go to **Settings** > **General** > **Virtual Machine Manager**.
+2. Select **Docker VMM**.
+3. Select **Apply & restart**.
+
+{{< /tab >}}
+{{< /tabs >}}
 
 ### Known issues
 
-As Docker VMM is still in Beta, there are a few known limitations:
+- A restart of Docker Desktop may be required after switching to Docker VMM.
+- Docker VMM does not support bind mount auto-shares. If you see a `file is not shared from the host` error, go to **Settings** > **Resources** > **File sharing** and add the directory you want to share.
+
+#### Mac only
 
 - Docker VMM does not currently support Rosetta, so emulation of amd64 architectures is slow. Docker is exploring potential solutions.
-- Certain databases, like MongoDB and Cassandra, may fail when using virtiofs with Docker VMM. This issue is expected to be resolved in a future release.
+- Certain databases, such as MongoDB and Cassandra, may fail when using virtiofs with Docker VMM. This issue is expected to be resolved in a future release.
 
-## Apple Virtualization framework
+## Alternative VMMs for Mac
 
-The Apple Virtualization framework is a stable and well-established option for managing virtual machines on Mac. It has been a reliable choice for many Mac users over the years. This framework is best suited for developers who prefer a proven solution with solid performance and broad compatibility.
+### Apple Virtualization framework
 
-## QEMU (Legacy) for Apple Silicon
+The Apple Virtualization framework is a stable and well-established option for managing virtual machines on Mac. It has been a reliable choice for many Mac users over the years.
+
+### HyperKit (Legacy) for Intel-based Macs
 
 > [!NOTE]
 >
-> QEMU will be deprecated on July 14, 2025. For more information, see the [blog announcement](https://www.docker.com/blog/docker-desktop-for-mac-qemu-virtualization-option-to-be-deprecated-in-90-days/) 
+> HyperKit is deprecated. Docker recommends switching to the Apple Virtualization framework.
 
-QEMU is a legacy virtualization option for Apple Silicon Macs, primarily supported for older use cases. 
+HyperKit is a legacy virtualization option for Intel-based Macs. Docker recommends switching to modern alternatives for better performance and to future-proof your setup.
 
-Docker recommends transitioning to newer alternatives, such as Docker VMM or the Apple Virtualization framework, as they offer superior performance and ongoing support. Docker VMM, in particular, offers substantial speed improvements and a more efficient development environment, making it a compelling choice for developers working with Apple Silicon.
+## Alternative VMMs for Windows
 
-Note that this is not related to using QEMU to emulate non-native architectures in [multi-platform builds](/manuals/build/building/multi-platform.md#qemu).
+### WSL 2
 
-## HyperKit (Legacy) for Intel-based Macs
+WSL 2 (Windows Subsystem for Linux 2) is the default Windows backend for Docker Desktop. It runs a full Linux kernel inside a lightweight VM with tight integration into the Windows host file system and networking. WSL 2 is available in both per-user and all-users installation modes and does not require administrator privileges.
 
-> [!NOTE]
->
-> HyperKit will be deprecated in a future release.
+For more information, see [Docker Desktop WSL 2 backend](/manuals/desktop/features/wsl/_index.md).
+
+### Hyper-V
 
-HyperKit is another legacy virtualization option, specifically for Intel-based Macs. Like QEMU, it is still available but considered deprecated. Docker recommends switching to modern alternatives for better performance and to future-proof your setup.
\ No newline at end of file
+Hyper-V is Windows' native hypervisor. It runs the Docker Linux VM in a fully isolated virtual machine, providing a strong boundary between the container environment and the Windows host. Hyper-V is only available in all-users installation mode and requires administrator privileges.
diff --git a/content/manuals/desktop/features/wasm.md b/content/manuals/desktop/features/wasm.md
index 35df7ca492c2..7ea9942057e3 100644
--- a/content/manuals/desktop/features/wasm.md
+++ b/content/manuals/desktop/features/wasm.md
@@ -15,6 +15,10 @@ params:
 
 {{< summary-bar feature_name="Wasm workloads" >}}
 
+> [!IMPORTANT]
+>
+> Wasm workloads are deprecated and will be removed in a future Docker Desktop release. This feature is no longer actively maintained. 
+
 WebAssembly (Wasm) is a fast, light alternative to Linux and
 Windows containers.  With Docker Desktop, you can now run Wasm workloads side by side with traditional containers.
 
@@ -34,7 +38,7 @@ then pre-existing images and containers will be inaccessible.
 1. Navigate to **Settings** in Docker Desktop.
 2. In the **General** tab, check **Use containerd for pulling and storing images**.
 3. Go to **Features in development** and check the **Enable Wasm** option.
-4. Select **Apply & restart** to save the settings.
+4. Select **Apply** to save the settings.
 5. In the confirmation dialog, select **Install** to install the Wasm runtimes.
 
 Docker Desktop downloads and installs the following runtimes: 
diff --git a/content/manuals/desktop/features/wsl/_index.md b/content/manuals/desktop/features/wsl/_index.md
index bba84c34e9e0..080e9d1bac09 100644
--- a/content/manuals/desktop/features/wsl/_index.md
+++ b/content/manuals/desktop/features/wsl/_index.md
@@ -8,61 +8,53 @@ linkTitle: WSL
 weight: 120
 aliases:
 - /docker-for-windows/wsl/
-- /docker-for-windows/wsl-tech-preview/
 - /desktop/windows/wsl/
 - /desktop/wsl/
+- /docker-for-windows/wsl-tech-preview/
 ---
 
-Windows Subsystem for Linux (WSL) 2 is a full Linux kernel built by Microsoft, which lets Linux distributions run without managing virtual machines. With Docker Desktop running on WSL 2, users can leverage Linux workspaces and avoid maintaining both Linux and Windows build scripts. In addition, WSL 2 provides improvements to file system sharing and boot time.
-
-Docker Desktop uses the dynamic memory allocation feature in WSL 2 to improve the resource consumption. This means Docker Desktop only uses the required amount of CPU and memory resources it needs, while allowing CPU and memory-intensive tasks such as building a container, to run much faster.
+Windows Subsystem for Linux (WSL) 2 is a full Linux kernel built by Microsoft that lets Linux distributions run without managing virtual machines. With Docker Desktop running on WSL 2, users can leverage Linux workspaces and avoid maintaining both Linux and Windows build scripts. In addition, WSL 2 provides improvements to file system sharing, faster cold-start times, and dynamic resource allocation.
 
-Additionally, with WSL 2, the time required to start a Docker daemon after a cold start is significantly faster.
+Because WSL 2 uses dynamic memory allocation, Docker Desktop requests only the CPU and memory it actually needs — freeing resources for the rest of your system, while still letting memory-intensive tasks such as multi-stage image builds run at full speed.
 
 ## Prerequisites
 
 Before you turn on the Docker Desktop WSL 2 feature, ensure you have:
 
-- At a minimum WSL version 1.1.3.0., but ideally the latest version of WSL to [avoid Docker Desktop not working as expected](best-practices.md).
+- At a minimum WSL version 2.1.5, but ideally the latest version of WSL to [avoid Docker Desktop not working as expected](best-practices.md).
 - Met the Docker Desktop for Windows' [system requirements](/manuals/desktop/setup/install/windows-install.md#system-requirements).
 - Installed the WSL 2 feature on Windows. For detailed instructions, refer to the [Microsoft documentation](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
 
 > [!TIP]
 >
-> For a better experience on WSL, consider enabling the WSL
-> [autoMemoryReclaim](https://learn.microsoft.com/en-us/windows/wsl/wsl-config#experimental-settings)
-> setting available since WSL 1.3.10 (experimental).
->
-> This feature enhances the Windows host's ability to reclaim unused memory within the WSL virtual machine, ensuring improved memory availability for other host applications. This capability is especially beneficial for Docker Desktop, as it prevents the WSL VM from retaining large amounts of memory (in GBs) within the Linux kernel's page cache during Docker container image builds, without releasing it back to the host when no longer needed within the VM.
+> Consider enabling the WSL [autoMemoryReclaim](https://learn.microsoft.com/en-us/windows/wsl/wsl-config#experimental-settings) setting, available since WSL 1.3.10 (experimental).
+>This setting allows Windows to reclaim unused memory from the WSL virtual machine, preventing the Linux kernel's page cache from holding onto large amounts of RAM after container image builds complete. The result is better memory availability for other applications on the host. 
 
 ## Turn on Docker Desktop WSL 2
 
-> [!IMPORTANT]
->
-> To avoid any potential conflicts with using WSL 2 on Docker Desktop, you must uninstall any previous versions of Docker Engine and CLI installed directly through Linux distributions before installing Docker Desktop.
+Before installing Docker Desktop, uninstall any version of Docker Engine or the Docker CLI
+that was installed directly inside a WSL Linux distribution. Running both can cause conflicts.
 
-1. Download and install the latest version of [Docker Desktop for Windows](https://desktop.docker.com/win/main/amd64/Docker%20Desktop%20Installer.exe).
+1. Download and install the latest version of [Docker Desktop for Windows](https://desktop.docker.com/win/main/amd64/Docker%20Desktop%20Installer.exe?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-windows).
 2. Follow the usual installation instructions to install Docker Desktop. Depending on which version of Windows you are using, Docker Desktop may prompt you to turn on WSL 2 during installation. Read the information displayed on the screen and turn on the WSL 2 feature to continue.
 3. Start Docker Desktop from the **Windows Start** menu.
 4. Navigate to **Settings**.
-5. From the **General** tab, select **Use WSL 2 based engine**..
+5. From the **General** tab, select **Use WSL 2 based engine**.
 
-    If you have installed Docker Desktop on a system that supports WSL 2, this option is turned on by default.
-6. Select **Apply & Restart**.
+    If you have installed Docker Desktop on a system that supports WSL 2, this option is turned on by default and the setting is not visible. 
+6. Select **Apply**.
 
-Now `docker` commands work from Windows using the new WSL 2 engine.
+`docker` commands are now available from any Windows terminal using the WSL 2 engine.
 
 > [!TIP]
 >
 > By default, Docker Desktop stores the data for the WSL 2 engine at `C:\Users\[USERNAME]\AppData\Local\Docker\wsl`.
-> If you want to change the location, for example, to another drive you can do so via the `Settings -> Resources -> Advanced` page from the Docker Dashboard.
+> If you want to change the location, go to `Settings -> Resources -> Advanced` page from the Docker Dashboard.
 > Read more about this and other Windows settings at [Changing settings](/manuals/desktop/settings-and-maintenance/settings.md)
 
-## Enabling Docker support in WSL 2 distributions
-
-WSL 2 adds support for "Linux distributions" to Windows, where each distribution behaves like a VM except they all run on top of a single shared Linux kernel.
+## Enable Docker in a WSL 2 distribution
 
-Docker Desktop does not require any particular Linux distributions to be installed. The `docker` CLI and UI all work fine from Windows without any additional Linux distributions. However for the best developer experience, we recommend installing at least one additional distribution and enable Docker support:
+WSL 2 lets multiple Linux distributions run side-by-side on a single shared kernel. Docker Desktop doesn't require a particular distribution to be installed, and `docker` commands work from Windows without one. However, enabling WSL integration for a distribution gives you direct access to `docker` commands from that distribution's terminal — which is useful for Linux-native development workflows.
 
 1. Ensure the distribution runs in WSL 2 mode. WSL can run distributions in both v1 or v2 mode.
 
@@ -88,30 +80,24 @@ Docker Desktop does not require any particular Linux distributions to be install
 
     The Docker-WSL integration is enabled on the default WSL distribution, which is [Ubuntu](https://learn.microsoft.com/en-us/windows/wsl/install). To change your default WSL distribution, run:
      ```console
-    $ wsl --set-default <distribution name>
+    $ wsl.exe --set-default <distribution name>
     ```
    If **WSL integrations** isn't available under **Resources**, Docker may be in Windows container mode. In your taskbar, select the Docker menu and then **Switch to Linux containers**.
 
-3. Select **Apply & Restart**.
-
-> [!NOTE]
->
-> With Docker Desktop version 4.30 and earlier, Docker Desktop installed two special-purpose internal Linux distributions `docker-desktop` and `docker-desktop-data`. `docker-desktop` is used to run the Docker engine `dockerd`, while `docker-desktop-data` stores containers and images. Neither can be used for general development.
->
-> With fresh installations of Docker Desktop 4.30 and later, `docker-desktop-data` is no longer created. Instead, Docker Desktop creates and 
-> manages its own virtual hard disk for storage. The `docker-desktop` distribution is still created and used to run the Docker engine.
->
-> Note that Docker Desktop version 4.30 and later keeps using the `docker-desktop-data` distribution if it was already created by an earlier version of Docker Desktop and has not been freshly installed or factory reset.
+3. Select **Apply**.
 
 ## WSL 2 security in Docker Desktop
 
-Docker Desktop’s WSL 2 integration operates within the existing security model of WSL and does not introduce additional security risks beyond standard WSL behavior.
+Docker Desktop's WSL 2 integration works within WSL's existing security model and does not introduce security risks beyond standard WSL behavior.
+
+Docker Desktop runs inside its own `docker-desktop` WSL distribution, isolated from other distributions in the same way any two WSL distributions are isolated from each other. Interaction between Docker Desktop and other distributions only occurs when you explicitly enable WSL integration for those distributions. This feature allows easy access to the Docker CLI from integrated distributions. 
 
-Docker Desktop runs within its own dedicated WSL distribution, `docker-desktop`, which follows the same isolation properties as any other WSL distribution. The only interaction between Docker Desktop and other installed WSL distributions occurs when the Docker Desktop **WSL integration** feature is enabled in settings. This feature allows easy access to the Docker CLI from integrated distributions. 
+WSL is designed to aid interoperability between Windows and Linux environments. Its file system is accessible from the Windows host `\\wsl$`, meaning Windows processes can read and modify files within WSL. This behavior is not specific to Docker Desktop, but rather a core aspect of WSL itself.
 
-WSL is designed to facilitate interoperability between Windows and Linux environments. Its file system is accessible from the Windows host `\\wsl$`, meaning Windows processes can read and modify files within WSL. This behavior is not specific to Docker Desktop, but rather a core aspect of WSL itself.
+For environments that require stricter isolation:
 
-For organizations concerned about security risks related to WSL and want stricter isolation and security controls, run Docker Desktop in Hyper-V mode instead of WSL 2. Alternatively, run your container workloads with [Enhanced Container Isolation](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md) enabled.
+- Run Docker Desktop in Hyper-V mode instead of WSL 2 to avoid the shared-kernel model entirely.
+- Enable [Enhanced Container Isolation](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md) to add an additional layer of protection around container workloads regardless of backend.
 
 ## Additional resources
 
diff --git a/content/manuals/desktop/features/wsl/best-practices.md b/content/manuals/desktop/features/wsl/best-practices.md
index 393604b2cede..d4db57121c38 100644
--- a/content/manuals/desktop/features/wsl/best-practices.md
+++ b/content/manuals/desktop/features/wsl/best-practices.md
@@ -1,26 +1,36 @@
 ---
-title: Best practices
+linkTitle: Best practices
+title: WSL 2 best practices for Docker Desktop on Windows 
 description: Best practices for using Docker Desktop with WSL 2
-keywords: wsl, docker desktop, best practices
+keywords: wsl 2, docker desktop, best practices, Windows Subsystem for Linux, Docker Desktop Windows performance
 tags: [Best practices]
 aliases:
 - /desktop/wsl/best-practices/
 ---
 
-- Always use the latest version of WSL. At a minimum you must use WSL version 1.1.3.0., otherwise Docker Desktop may not work as expected. Testing, development, and documentation is based on the newest kernel versions. Older versions of WSL can cause:
-    - Docker Desktop to hang periodically or when upgrading
-    - Deployment via SCCM to fail
-    - The `vmmem.exe` to consume all memory 
-    - Network filter policies to be applied globally, not to specific objects
-    - GPU failures with containers
+This page covers recommendations when running Docker Desktop on Windows using WSL 2, including version requirements and file system performance.
 
-- To get the best out of the file system performance when bind-mounting files, it's recommended that you store source code and other data that is bind-mounted into Linux containers. For instance, use `docker run -v <host-path>:<container-path>` in the Linux file system, rather than the Windows file system. You can also refer to the [recommendation](https://learn.microsoft.com/en-us/windows/wsl/compare-versions) from Microsoft.
-    - Linux containers only receive file change events, “inotify events”, if the original files are stored in the Linux filesystem. For example, some web development workflows rely on inotify events for automatic reloading when files have changed.
-    - Performance is much higher when files are bind-mounted from the Linux filesystem, rather than remoted from the Windows host. Therefore avoid `docker run -v /mnt/c/users:/users,` where `/mnt/c` is mounted from Windows.
-    - Instead, from a Linux shell use a command like `docker run -v ~/my-project:/sources <my-image>` where `~` is expanded by the Linux shell to `$HOME`.
+## Keep WSL up to date
 
-- If you have concerns about the size of the `docker-desktop-data` distribution, take a look at the [WSL tooling built into Windows](https://learn.microsoft.com/en-us/windows/wsl/disk-space). 
-    - Installations of Docker Desktop version 4.30 and later no longer rely on the `docker-desktop-data` distribution; instead Docker Desktop creates and manages its own virtual hard disk (VHDX) for storage. (note, however, that Docker Desktop keeps using the `docker-desktop-data` distribution if it was already created by an earlier version of the software).
-    - Starting from version 4.34 and later, Docker Desktop automatically manages the size of the managed VHDX and returns unused space to the operating system.
+Always use the latest version of WSL. 
 
-- If you have concerns about CPU or memory usage, you can configure limits on the memory, CPU, and swap size allocated to the [WSL 2 utility VM](https://learn.microsoft.com/en-us/windows/wsl/wsl-config#global-configuration-options-with-wslconfig).
+At a minimum you must use WSL version 2.1.5, otherwise Docker Desktop may not work as expected. Additionally, if you intend to use Enhanced Container Isolation, ensure you’re using WSL version 2.6 or later. This is required because ECI depends on a Linux kernel version of at least 6.3.0, and WSL 2.6+ bundles Linux kernel version 6.6. Testing, development, and documentation is based on the newest kernel versions. Older versions of WSL can cause:
+- Docker Desktop to hang periodically or when upgrading
+- Deployment via SCCM to fail
+- The `vmmem.exe` to consume all memory 
+- Network filter policies to be applied globally, not to specific objects
+- GPU failures with containers
+
+## Optimise file system performance with bind mounts
+
+To get the best out of the file system performance when bind-mounting files, store source code and other data that is bind-mounted into Linux containers. For instance, use `docker run -v <host-path>:<container-path>` in the Linux file system, rather than the Windows file system. You can also refer to [Microsoft's recommendation](https://learn.microsoft.com/en-us/windows/wsl/compare-versions).
+
+Linux containers only receive file change events, “inotify events”, if the original files are stored in the Linux filesystem. For example, some web development workflows rely on inotify events for automatic reloading when files have changed.
+
+Performance is much higher when files are bind-mounted from the Linux filesystem, rather than accessed from the Windows host filesystem. Therefore avoid `docker run -v /mnt/c/users:/users` where `/mnt/c` is mounted from Windows.
+
+Instead, from a Linux shell use a command like `docker run -v ~/my-project:/sources <my-image>` where `~` is expanded by the Linux shell to `$HOME`.
+
+## Limit CPU and memory usage
+
+If you have concerns about CPU or memory usage, configure limits on the memory, CPU, and swap size allocated to the [WSL 2 utility VM](https://learn.microsoft.com/en-us/windows/wsl/wsl-config#global-configuration-options-with-wslconfig).
diff --git a/content/manuals/desktop/features/wsl/custom-kernels.md b/content/manuals/desktop/features/wsl/custom-kernels.md
index 0fd8fcf01867..020c9e0f1fe5 100644
--- a/content/manuals/desktop/features/wsl/custom-kernels.md
+++ b/content/manuals/desktop/features/wsl/custom-kernels.md
@@ -1,31 +1,34 @@
 ---
+linkTitle: Custom kernels
 title: Custom kernels on WSL 
 description: Using custom kernels with Docker Desktop on WSL 2
 keywords: wsl, docker desktop, custom kernel
 tags: [Best practices, troubleshooting]
 ---
 
-Docker Desktop depends on several kernel features built into the default
-WSL 2 Linux kernel distributed by Microsoft. Consequently, using a
-custom kernel with Docker Desktop on WSL 2 is not officially supported
+> [!WARNING]
+>
+> Using a custom kernel with Docker Desktop on WSL 2 is not officially supported
 and may cause issues with Docker Desktop startup or operation.
 
+Docker Desktop depends on several kernel features built into the default
+WSL 2 Linux kernel distributed by Microsoft.
+
 However, in some cases it may be necessary
 to run custom kernels; Docker Desktop does not block their use, and
 some users have reported success using them.
 
-If you choose to use a custom kernel, it is recommended you start
+## Recommendations if you must use a custom kernel
+
+If you choose to use a custom kernel, start
 from the kernel tree distributed by Microsoft from their [official
 repository](https://github.com/microsoft/WSL2-Linux-Kernel) and then add
 the features you need on top of that.
 
-It's also recommended that you:
+Also:
 - Use the same kernel version as the one distributed by the latest WSL2
 release. You can find the version by running `wsl.exe --system uname -r`
 in a terminal.
-- Start from the default kernel configuration as provided by Microsoft
-from their [repository](https://github.com/microsoft/WSL2-Linux-Kernel)
-and add the features you need on top of that.
 - Make sure that your kernel build environment includes `pahole` and
 its version is properly reflected in the corresponding kernel config
 (`CONFIG_PAHOLE_VERSION`).
diff --git a/content/manuals/desktop/features/wsl/use-wsl.md b/content/manuals/desktop/features/wsl/use-wsl.md
index fc4a7fd40316..df88073bb7b9 100644
--- a/content/manuals/desktop/features/wsl/use-wsl.md
+++ b/content/manuals/desktop/features/wsl/use-wsl.md
@@ -1,16 +1,19 @@
 ---
-title: Use WSL
+linkTitle: Use WSL
+title: Develop with Docker Desktop using WSL 2 on Windows
 description: How to develop with Docker and WSL 2 and understand GPU support for WSL
 keywords: wsl, wsl 2, develop, docker desktop, windows
-aliases:
-- /desktop/wsl/use-wsl/
 ---
 
-The following section describes how to start developing your applications using Docker and WSL 2. We recommend that you have your code in your default Linux distribution for the best development experience using Docker and WSL 2. After you have turned on the WSL 2 feature on Docker Desktop, you can start working with your code inside the Linux distribution and ideally with your IDE still in Windows. This workflow is straightforward if you are using [VS Code](https://code.visualstudio.com/download).
+The following section describes how to start developing your applications using Docker and WSL 2. 
+
+For the best development experience, store your code inside your default Linux distribution. After you have turned on the WSL 2 feature on Docker Desktop, you can start working with your code inside the Linux distribution and ideally with your IDE still in Windows. This workflow is straightforward if you are using [VS Code](https://code.visualstudio.com/download).
 
 ## Develop with Docker and WSL 2
 
-1. Open VS Code and install the [Remote - WSL](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl) extension. This extension lets you work with a remote server in the Linux distribution and your IDE client still on Windows.
+Before you begin, make sure you have enabled WSL 2 integration in Docker Desktop under **Settings** > **Resources** > **WSL Integration**.
+
+1. Open VS Code and install the [WSL](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl) extension. This extension lets you work with a remote server in the Linux distribution and your IDE client still on Windows.
 2. Open your terminal and type:
 
     ```console
diff --git a/content/manuals/desktop/images/console.png b/content/manuals/desktop/images/console.png
deleted file mode 100644
index 75ff7c104028..000000000000
Binary files a/content/manuals/desktop/images/console.png and /dev/null differ
diff --git a/content/manuals/desktop/images/dashboard.png b/content/manuals/desktop/images/dashboard.png
deleted file mode 100644
index 904ff4dcd887..000000000000
Binary files a/content/manuals/desktop/images/dashboard.png and /dev/null differ
diff --git a/content/manuals/desktop/images/gordon-run-ctr.png b/content/manuals/desktop/images/gordon-run-ctr.png
deleted file mode 100644
index 5369a82a7b08..000000000000
Binary files a/content/manuals/desktop/images/gordon-run-ctr.png and /dev/null differ
diff --git a/content/manuals/desktop/images/k8s-settings.png b/content/manuals/desktop/images/k8s-settings.png
deleted file mode 100644
index aa8882b76473..000000000000
Binary files a/content/manuals/desktop/images/k8s-settings.png and /dev/null differ
diff --git a/content/manuals/desktop/images/resource-saver-settings.png b/content/manuals/desktop/images/resource-saver-settings.png
deleted file mode 100644
index d492399c816c..000000000000
Binary files a/content/manuals/desktop/images/resource-saver-settings.png and /dev/null differ
diff --git a/content/manuals/desktop/images/resource-saver-settings.webp b/content/manuals/desktop/images/resource-saver-settings.webp
new file mode 100644
index 000000000000..c43a64df94ee
Binary files /dev/null and b/content/manuals/desktop/images/resource-saver-settings.webp differ
diff --git a/content/manuals/desktop/images/resource-saver-status-bar.png b/content/manuals/desktop/images/resource-saver-status-bar.png
deleted file mode 100644
index c1724e58e78f..000000000000
Binary files a/content/manuals/desktop/images/resource-saver-status-bar.png and /dev/null differ
diff --git a/content/manuals/desktop/images/shared-folder-on-demand.png b/content/manuals/desktop/images/shared-folder-on-demand.png
deleted file mode 100644
index 957a5b9046eb..000000000000
Binary files a/content/manuals/desktop/images/shared-folder-on-demand.png and /dev/null differ
diff --git a/content/manuals/desktop/images/synched-file-shares.webp b/content/manuals/desktop/images/synched-file-shares.webp
deleted file mode 100644
index 828df943d074..000000000000
Binary files a/content/manuals/desktop/images/synched-file-shares.webp and /dev/null differ
diff --git a/content/manuals/desktop/previous-versions/2.x-mac.md b/content/manuals/desktop/previous-versions/2.x-mac.md
index d1e9b00fb78b..af846e3edcec 100644
--- a/content/manuals/desktop/previous-versions/2.x-mac.md
+++ b/content/manuals/desktop/previous-versions/2.x-mac.md
@@ -4,7 +4,6 @@ keywords: Docker Desktop for Mac 2.x release notes
 title: Docker Desktop for Mac 2.x release notes
 toc_min: 1
 toc_max: 2
-aliases: /desktop/mac/release-notes/2.x/
 sitemap: false
 ---
 
@@ -28,7 +27,7 @@ Docker Desktop 2.5.0.0 contains a Kubernetes upgrade. Your local Kubernetes clus
 
 ### New
 
-- Users with a paid Docker subscription plan can now see the vulnerability scan report on the Remote repositories tab in Docker Desktop.
+- Users with a paid Docker subscription can now see the vulnerability scan report on the Remote repositories tab in Docker Desktop.
 - Docker Desktop introduces a support option for users with a paid Docker subscription.
 
 ### Security
diff --git a/content/manuals/desktop/previous-versions/2.x-windows.md b/content/manuals/desktop/previous-versions/2.x-windows.md
index 1b20bc5c82dd..067acc3479b8 100644
--- a/content/manuals/desktop/previous-versions/2.x-windows.md
+++ b/content/manuals/desktop/previous-versions/2.x-windows.md
@@ -4,7 +4,6 @@ keywords: Docker Desktop for Windows 2.x, release notes
 title: Docker for Windows 2.x release notes
 toc_min: 1
 toc_max: 2
-aliases: /desktop/windows/release-notes/2.x/
 sitemap: false
 ---
 
diff --git a/content/manuals/desktop/previous-versions/3.x-mac.md b/content/manuals/desktop/previous-versions/3.x-mac.md
index 3444a12d02f3..48f31ec5aa48 100644
--- a/content/manuals/desktop/previous-versions/3.x-mac.md
+++ b/content/manuals/desktop/previous-versions/3.x-mac.md
@@ -4,10 +4,6 @@ keywords: Docker Desktop for Mac 3.x release notes
 title: Docker Desktop for Mac 3.x release notes
 toc_min: 1
 toc_max: 2
-aliases:
-- /desktop/mac/previous-versions/
-- /docker-for-mac/previous-versions/
-- /desktop/mac/release-notes/3.x/
 sitemap: false
 ---
 
@@ -49,7 +45,7 @@ This page contains release notes for Docker Desktop for Mac 3.x.
 
 ### New
 
-**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts. For more information and for instructions on how to use Dev Environments, see [Development Environments Preview](/manuals/desktop/features/dev-environments/_index.md).
+**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts.
 
 ### Upgrades
 
@@ -60,8 +56,8 @@ This page contains release notes for Docker Desktop for Mac 3.x.
   - Fixed network's IPAM configuration. Service can define a fixed IP. Fixes for [docker/compose-cli#1678](https://github.com/docker/compose-cli/issues/1678) and [docker/compose-cli#1816](https://github.com/docker/compose-cli/issues/1816)
 
 - Dev Environments
-  - Support VS Code Insiders. See [dev-environments#3](https://github.com/docker/dev-environments/issues/3)
-  - Allow users to specify a branch when cloning a project. See [dev-environments#11](https://github.com/docker/dev-environments/issues/11)
+  - Support VS Code Insiders. 
+  - Allow users to specify a branch when cloning a project. 
 
 ### Bug fixes and minor changes
 
@@ -77,9 +73,9 @@ This page contains release notes for Docker Desktop for Mac 3.x.
 
 ### New
 
-**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts. For more information and for instructions on how to use Dev Environments, see [Development Environments Preview](/manuals/desktop/features/dev-environments/_index.md).
+**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts.
 
-**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the [docker-compose compatibility list](/manuals/compose/releases/migrate.md) for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
+**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the docker-compose compatibility list for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
 
 ### Bug fixes and minor changes
 
@@ -90,9 +86,9 @@ This page contains release notes for Docker Desktop for Mac 3.x.
 
 ### New
 
-**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts. For more information and for instructions on how to use Dev Environments, see [Development Environments Preview](/manuals/desktop/features/dev-environments/_index.md).
+**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts.
 
-**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the [docker-compose compatibility list](/manuals/compose/releases/migrate.md) for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
+**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the docker-compose compatibility list for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
 
 ### Upgrades
 
@@ -124,7 +120,7 @@ This page contains release notes for Docker Desktop for Mac 3.x.
 
 **Volume Management**: Docker Desktop users can now create and delete volumes using the Docker Dashboard and also see which volumes are being used. For more information, see [Explore volumes](../use-desktop/volumes.md).
 
-**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the [docker-compose compatibility list](/manuals/compose/releases/migrate.md) for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
+**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the docker-compose compatibility list for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
 
 **Skip Docker Desktop updates**: All users can now skip an update when they are prompted to install individual Docker Desktop releases.
 
diff --git a/content/manuals/desktop/previous-versions/3.x-windows.md b/content/manuals/desktop/previous-versions/3.x-windows.md
index b93c1c7435fa..3eb153a381f3 100644
--- a/content/manuals/desktop/previous-versions/3.x-windows.md
+++ b/content/manuals/desktop/previous-versions/3.x-windows.md
@@ -4,10 +4,6 @@ keywords: Docker Desktop for Windows 3.x, release notes
 title: Docker for Windows 3.x release notes
 toc_min: 1
 toc_max: 2
-aliases:
-- /desktop/windows/previous-versions/
-- /docker-for-windows/previous-versions/
-- /desktop/windows/release-notes/3.x/
 sitemap: false
 ---
 
@@ -56,7 +52,7 @@ This page contains release notes for Docker Desktop for Windows 3.x.
 
 ### New
 
-**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts. For more information and for instructions on how to use Dev Environments, see [Development Environments Preview](/manuals/desktop/features/dev-environments/_index.md).
+**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts. 
 
 ### Upgrades
 
@@ -67,7 +63,7 @@ This page contains release notes for Docker Desktop for Windows 3.x.
   - Fixed network's IPAM configuration. Service can define a fixed IP. Fixes for [docker/compose-cli#1678](https://github.com/docker/compose-cli/issues/1678) and [docker/compose-cli#1816](https://github.com/docker/compose-cli/issues/1816)
 
 - Dev Environments
-  - Support VS Code Insiders. See [dev-environments#3](https://github.com/docker/dev-environments/issues/3)
+  - Support VS Code Insiders. 
   - Allow users to specify a branch when cloning a project. See [dev-environments#11](https://github.com/docker/dev-environments/issues/11)
 
 ### Bug fixes and minor changes
@@ -84,9 +80,9 @@ This page contains release notes for Docker Desktop for Windows 3.x.
 
 ### New
 
-**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts. For more information and for instructions on how to use Dev Environments, see [Development Environments Preview](/manuals/desktop/features/dev-environments/_index.md).
+**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts.
 
-**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the [docker-compose compatibility list](/manuals/compose/releases/migrate.md) for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
+**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the docker-compose compatibility list for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
 
 ### Bug fixes and minor changes
 
@@ -98,9 +94,9 @@ This page contains release notes for Docker Desktop for Windows 3.x.
 
 ### New
 
-**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts. For more information and for instructions on how to use Dev Environments, see [Development Environments Preview](/manuals/desktop/features/dev-environments/_index.md).
+**Dev Environments Preview**: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members' machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts.
 
-**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the [docker-compose compatibility list](/manuals/compose/releases/migrate.md) for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
+**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the docker-compose compatibility list for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
 
 ### Upgrades
 
@@ -131,7 +127,7 @@ This page contains release notes for Docker Desktop for Windows 3.x.
 
 **Volume Management**: Docker Desktop users can now create and delete volumes using the Docker Dashboard and also see which volumes are being used. For more information, see [Explore volumes](../use-desktop/volumes.md).
 
-**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the [docker-compose compatibility list](/manuals/compose/releases/migrate.md) for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
+**Compose V2 beta**: Docker Desktop now includes the beta version of Compose V2, which supports the `docker compose` command as part of the Docker CLI. While `docker-compose` is still supported and maintained, Compose V2 implementation relies directly on the compose-go bindings which are maintained as part of the specification. The compose command in the Docker CLI supports most of the `docker-compose` commands and flags. It is expected to be a drop-in replacement for `docker-compose`. There are a few remaining flags that have yet to be implemented, see the docker-compose compatibility list for more information about the flags that are supported in the new compose command. If you run into any problems with Compose V2, you can easily switch back to Compose v1 by either by making changes in Docker Desktop **Experimental** Settings, or by running the command `docker-compose disable-v2`. Let us know your feedback on the new ‘compose’ command by creating an issue in the [Compose-CLI](https://github.com/docker/compose-cli/issues) GitHub repository.
 
 **Skip Docker Desktop updates**: All users can now skip an update when they are prompted to install individual Docker Desktop releases. 
 
diff --git a/content/manuals/desktop/previous-versions/archive-mac.md b/content/manuals/desktop/previous-versions/archive-mac.md
index 692afebd842e..1760e106dad3 100644
--- a/content/manuals/desktop/previous-versions/archive-mac.md
+++ b/content/manuals/desktop/previous-versions/archive-mac.md
@@ -4,8 +4,6 @@ keywords: Docker Desktop for Mac, release notes
 title: Release notes for previous versions
 toc_min: 1
 toc_max: 2
-aliases:
-- /desktop/mac/release-notes/archive/
 sitemap: false
 ---
 
@@ -31,7 +29,7 @@ This page contains release notes for older versions of Docker Desktop for Mac.
   - Linux Kernel 4.9.93 with CEPH, DRBD, RBD, MPLS_ROUTING and MPLS_IPTUNNEL enabled
 
 * New
-  - Kubernetes Support. You can now run a single-node Kubernetes cluster from the "Kubernetes" Pane in Docker For Mac Preferences and use kubectl commands as well as docker commands. See [the Kubernetes section](/manuals/desktop/features/kubernetes.md)
+  - Kubernetes Support. You can now run a single-node Kubernetes cluster from the "Kubernetes" Pane in Docker For Mac Preferences and use kubectl commands as well as docker commands. See [the Kubernetes section](/manuals/desktop/use-desktop/kubernetes.md)
   - Add an experimental SOCKS server to allow access to container networks, see [docker/for-mac#2670](https://github.com/docker/for-mac/issues/2670#issuecomment-372365274). Also see [docker/for-mac#2721](https://github.com/docker/for-mac/issues/2721)
   - Re-enable raw as the default disk format for users running macOS 10.13.4 and higher. Note this change only takes effect after a "reset to factory defaults" or "remove all data" (from the Whale menu -> Preferences -> Reset). Related to [docker/for-mac#2625](https://github.com/docker/for-mac/issues/2625)
 
diff --git a/content/manuals/desktop/previous-versions/archive-windows.md b/content/manuals/desktop/previous-versions/archive-windows.md
index 262e7c79339b..bcbd5b733152 100644
--- a/content/manuals/desktop/previous-versions/archive-windows.md
+++ b/content/manuals/desktop/previous-versions/archive-windows.md
@@ -4,8 +4,6 @@ keywords: Docker Desktop for Windows, release notes
 title: Release notes for previous versions
 toc_min: 1
 toc_max: 2
-aliases:
-- /desktop/windows/release-notes/archive/
 sitemap: false
 ---
 
@@ -47,7 +45,7 @@ This page contains release notes for older versions of Docker Desktop for Window
   - Linux Kernel 4.9.93 with CEPH, DRBD, RBD, MPLS_ROUTING and MPLS_IPTUNNEL enabled
 
 * New
-  - Kubernetes Support. You can now run a single-node Kubernetes cluster from the "Kubernetes" Pane in Docker for Windows settings and use kubectl commands as well as Docker commands. See [the Kubernetes section](/manuals/desktop/features/kubernetes.md)
+  - Kubernetes Support. You can now run a single-node Kubernetes cluster from the "Kubernetes" Pane in Docker for Windows settings and use kubectl commands as well as Docker commands. See [the Kubernetes section](/manuals/desktop/use-desktop/kubernetes.md)
 
 * Bug fixes and minor changes
   - AUFS storage driver is deprecated in Docker Desktop and AUFS support will be removed in the next major release. You can continue with AUFS in Docker Desktop 18.06.x, but you will need to reset the disk image (in Settings > Reset menu) before updating to the next major update. You can check documentation to [save images](/reference/cli/docker/image/save/#examples) and [backup volumes](/manuals/engine/storage/volumes.md#back-up-restore-or-migrate-data-volumes)
diff --git a/content/manuals/desktop/previous-versions/edge-releases-mac.md b/content/manuals/desktop/previous-versions/edge-releases-mac.md
index 60a9bccf7f5a..6ab358c1dcc6 100644
--- a/content/manuals/desktop/previous-versions/edge-releases-mac.md
+++ b/content/manuals/desktop/previous-versions/edge-releases-mac.md
@@ -4,17 +4,16 @@ keywords: Docker Desktop for Mac, edge, release notes
 title: Docker Desktop for Mac Edge release notes
 toc_min: 1
 toc_max: 2
-aliases:
-- /desktop/mac/release-notes/edge-releases/
 sitemap: false
 ---
 
-This page contains information about Docker Desktop Edge releases. Edge releases give you early access to our newest features. Note that some of the features may be experimental, and some of them may not ever reach the Stable release. 
+This page contains information about Docker Desktop Edge releases. Edge releases give you early access to our newest features. Note that some of the features may be experimental, and some of them may not ever reach the Stable release.
 
 For Docker Desktop system requirements, see
 [What to know before you install](/manuals/desktop/setup/install/mac-install.md#system-requirements).
 
 ## Docker Desktop Community 2.5.4
+
 2020-12-07
 
 ### Upgrades
@@ -27,10 +26,11 @@ For Docker Desktop system requirements, see
 - Changed the «Update and quit» menu entry to «Update and restart».
 - Fixed the check for updates dialog reporting the build number instead of the version number of a new version.
 - Downgraded the kernel to [4.19.121](https://hub.docker.com/layers/docker/for-desktop-kernel/4.19.121-2a1dbedf3f998dac347c499808d7c7e029fbc4d3-amd64/images/sha256-4e7d94522be4f25f1fbb626d5a0142cbb6e785f37e437f6fd4285e64a199883a?context=repo) to reduce the CPU usage of hyperkit. Fixes [docker/for-mac#5044](https://github.com/docker/for-mac/issues/5044)
--  Fixed a bug that DNS would return `NXDOMAIN` when a name exists but the type of record was not found. Fixes [docker/for-mac#5020](https://github.com/docker/for-mac/issues/5020). Related to https://gitlab.alpinelinux.org/alpine/aports/-/issues/11879
+- Fixed a bug that DNS would return `NXDOMAIN` when a name exists but the type of record was not found. Fixes [docker/for-mac#5020](https://github.com/docker/for-mac/issues/5020). Related to https://gitlab.alpinelinux.org/alpine/aports/-/issues/11879
 - Avoid caching bad file sizes and modes when using `osxfs`. Fixes [docker/for-mac#5045](https://github.com/docker/for-mac/issues/5045).
 
 ## Docker Desktop Community 2.5.3
+
 2020-11-30
 
 ### Upgrades
@@ -43,6 +43,7 @@ For Docker Desktop system requirements, see
 - Removed unnecessary log messages which slow down filesystem event injection.
 
 ## Docker Desktop Community 2.5.2
+
 2020-11-26
 
 ### New
@@ -57,6 +58,7 @@ For Docker Desktop system requirements, see
 - Display an error message instead of crashing when the application needs write access on specific directories. See [docker/for-mac#5068](https://github.com/docker/for-mac/issues/5068)
 
 ## Docker Desktop Community 2.5.1.0
+
 2020-11-18
 
 This release contains a Kubernetes upgrade. Note that your local Kubernetes cluster will be reset after installing Docker Desktop.
@@ -78,6 +80,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 - Fixed an unexpected EOF error when trying to start a non-existing container. See [docker/for-mac#5025](https://github.com/docker/for-mac/issues/5025).
 
 ## Docker Desktop Community 2.4.2.0
+
 2020-10-19
 
 ### New
@@ -106,6 +109,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 - Fixed automatic start on log in. See [docker/for-mac#4877](https://github.com/docker/for-mac/issues/4877) and [docker/for-mac#4890](https://github.com/docker/for-mac/issues/4890).
 
 ## Docker Desktop Community 2.4.1.0
+
 2020-10-01
 
 ### Upgrades
@@ -122,6 +126,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 - Fixed a possible premature file handle close when using `gRPC-FUSE`.
 
 ## Docker Desktop Community 2.3.7.0
+
 2020-09-17
 
 ### New
@@ -146,10 +151,11 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 ### Known issues
 
 - The `clock_gettime64` system call returns `EPERM` rather than `ENOSYS`
-in i386 images. To work around this issue, disable `seccomp` by using 
-the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for-win/issues/8326).
+  in i386 images. To work around this issue, disable `seccomp` by using
+  the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for-win/issues/8326).
 
 ## Docker Desktop Community 2.3.6.1
+
 2020-09-08
 
 ### Upgrades
@@ -158,9 +164,10 @@ the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for
 
 ### Bug fixes and minor changes
 
--  Docker Desktop now correctly displays the state of "Use gRPC FUSE for file sharing" in the UI. Fixes [docker/for-mac#4864](https://github.com/docker/for-mac/issues/4864).
+- Docker Desktop now correctly displays the state of "Use gRPC FUSE for file sharing" in the UI. Fixes [docker/for-mac#4864](https://github.com/docker/for-mac/issues/4864).
 
 ## Docker Desktop Community 2.3.6.0
+
 2020-09-01
 
 ### New
@@ -183,9 +190,10 @@ the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for
 
 ### Bug fixes and minor changes
 
-- Fixed a Mac CPU usage bug by removing the serial console from `hyperkit`, see [docker/roadmap#12]( https://github.com/docker/roadmap/issues/12#issuecomment-663163280). To open a shell in the VM use either `nc -U ~/Library/Containers/com.docker.docker/Data/debug-shell.sock` (on Mac) or `putty -serial \\.\pipe\dockerDebugShell` (on Windows).
+- Fixed a Mac CPU usage bug by removing the serial console from `hyperkit`, see [docker/roadmap#12](https://github.com/docker/roadmap/issues/12#issuecomment-663163280). To open a shell in the VM use either `nc -U ~/Library/Containers/com.docker.docker/Data/debug-shell.sock` (on Mac) or `putty -serial \\.\pipe\dockerDebugShell` (on Windows).
 
 ## Docker Desktop Community 2.3.5.0
+
 2020-08-21
 
 ### New
@@ -214,6 +222,7 @@ the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for
 - Fixed minor bugs in the **Images** view.
 
 ## Docker Desktop Community 2.3.4.0
+
 2020-07-28
 
 ### New
@@ -233,6 +242,7 @@ the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for
 - Mutagen two-way sync now uses `.dockersyncignore` rather than `.dockerignore` to exclude files.
 
 ## Docker Desktop Community 2.3.3.2
+
 2020-07-21
 
 ### Upgrades
@@ -246,6 +256,7 @@ the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for
 - Docker CLI commands can now bypass any active Mutagen synchronization for volumes using `:cached`. See [docker/for-mac#1592](https://github.com/docker/for-mac/issues/1592#issuecomment-651309816).
 
 ## Docker Desktop Community 2.3.3.0
+
 2020-07-09
 
 ### Upgrades
@@ -262,6 +273,7 @@ the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for
 - Docker Desktop now implements the shared volume flag `:delegated` by automatically setting up a two-way file sync with Mutagen.
 
 ## Docker Desktop Community 2.3.2.0
+
 2020-06-25
 
 ### Upgrades
@@ -283,6 +295,7 @@ the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for
 - Removed the legacy Kubernetes context `docker-for-desktop`. The context `docker-desktop` should be used instead. See [docker/for-mac#4089](https://github.com/docker/for-mac/issues/4089).
 
 ## Docker Desktop Community 2.3.1.0
+
 2020-05-20
 
 ### New
@@ -302,16 +315,16 @@ We appreciate you trying out an early version of the Mutagen file sync feature.
 - Fixed containers logs in Docker Desktop **Dashboard** which were sometimes truncated. Fixes [docker/for-win#5954](https://github.com/docker/for-win/issues/5954).
 
 ## Docker Desktop Community 2.3.0.1
-2020-04-28
 
+2020-04-28
 
 ### Bug fixes and minor changes
 
 - Fixed a bug that caused starting and stopping of a Compose application from the UI to fail when the path contains whitespace.
 
 ## Docker Desktop Community 2.3.0.0
-2020-04-20
 
+2020-04-20
 
 ### Upgrades
 
@@ -332,8 +345,8 @@ We appreciate you trying out an early version of the Mutagen file sync feature.
 - Fixed bug where diagnostic upload would fail if the username contained spaces.
 
 ## Docker Desktop Community 2.2.3.0
-2020-04-02
 
+2020-04-02
 
 ### Upgrades
 
@@ -363,8 +376,8 @@ We appreciate you trying out an early version of the Mutagen file sync feature.
 - Loopback and unspecified IPv6 addresses (`::` and `::1`) within a container do not currently work. Some web servers and other programs may be using these addresses in their configuration files.
 
 ## Docker Desktop Community 2.2.2.0
-2020-03-02
 
+2020-03-02
 
 This release contains a Kubernetes upgrade. Note that your local Kubernetes cluster will be reset after installing Docker Desktop.
 
@@ -379,8 +392,8 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 - Ceph support has been removed from Docker Desktop to save disk space.
 
 ## Docker Desktop Community 2.2.1.0
-2020-02-12
 
+2020-02-12
 
 ### Upgrades
 
@@ -388,10 +401,10 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 - [Go 1.12.16](https://golang.org/doc/devel/release.html#go1.12)
 
 ## Docker Desktop Community 2.1.7.0
-2019-12-11
 
+2019-12-11
 
-> [!NOTE] 
+> [!NOTE]
 >
 > Docker Desktop Edge 2.1.7.0 is the release candidate for the upcoming major Stable release. Please help us test this version before the wider release and report any issues in the [docker/for-mac](https://github.com/docker/for-mac/issues) GitHub repository.
 
@@ -411,8 +424,8 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 - Fixed an issue where attempts to log into Docker through Docker Desktop could sometimes fail with the `Incorrect authentication credentials` error. Fixes [docker/for-mac#4010](https://github.com/docker/for-mac/issues/4010).
 
 ## Docker Desktop Community 2.1.6.0
-2019-11-18
 
+2019-11-18
 
 ### Upgrades
 
@@ -429,8 +442,8 @@ Added the ability to start and stop Compose-based applications and view combined
 - Fixed a container start error when a container has more than one port with an arbitrary or not-yet-configured external port number. For example, `docker run -p 80 -p 443 nginx`. Fixes [docker/for-win#4935](https://github.com/docker/for-win/issues/4935) and [docker/compose#6998](https://github.com/docker/compose/issues/6998).
 
 ## Docker Desktop Community 2.1.5.0
-2019-11-04
 
+2019-11-04
 
 This release contains a Kubernetes upgrade. Note that your local Kubernetes cluster will be reset after installation.
 
@@ -457,8 +470,8 @@ Fixed an issue that caused VMs running on older hardware with macOS Catalina to
 - When you deploy a Docker App with multiple containers on Kubernetes, Docker Desktop displays each Pod as an application on the Dashboard.
 
 ## Docker Desktop Community 2.1.4.0
-2019-10-15
 
+2019-10-15
 
 ### Upgrades
 
@@ -475,8 +488,8 @@ Fixed an issue that caused VMs running on older hardware with macOS Catalina to
 - Docker Machine is no longer included in the Docker Desktop installer. You can download it separately from the [Docker Machine releases](https://github.com/docker/machine/releases) page.
 
 ## Docker Desktop Community 2.1.3.0
-2019-09-16
 
+2019-09-16
 
 ### Bug fixes and minor changes
 
@@ -486,8 +499,8 @@ Fixed an issue that caused VMs running on older hardware with macOS Catalina to
 - Deactivated the **Reset Kubernetes** button when Kubernetes is not activated.
 
 ## Docker Desktop Community 2.1.2.0
-2019-09-09
 
+2019-09-09
 
 #### Upgrades
 
@@ -504,8 +517,8 @@ Fixed an issue that caused VMs running on older hardware with macOS Catalina to
 - Added support for `Expect: 100-continue` headers in the Docker API proxy. Some HTTP clients such as `curl` send this header when the payload is large, for example, when creating containers. Fixes [moby/moby#39693](https://github.com/moby/moby/issues/39693).
 
 ## Docker Desktop Community 2.1.1.0
-2019-08-12
 
+2019-08-12
 
 #### Upgrades
 
@@ -519,25 +532,25 @@ Fixed an issue that caused VMs running on older hardware with macOS Catalina to
 - Fixed an issue where running some Docker commands can fail if you are not using Credential Helpers. [docker/for-mac#3785](https://github.com/docker/for-mac/issues/3785)
 - Fixed a bug that did not allow users to copy and paste text in the **Preferences** > **Daemon** window. [docker/for-mac#3798](https://github.com/docker/for-mac/issues/3798)
 
-## Docker Desktop Community 2.1.0.0 
-2019-07-26
+## Docker Desktop Community 2.1.0.0
 
+2019-07-26
 
 This release contains Kubernetes security improvements. Note that your local Kubernetes PKI and cluster will be reset after installation.
 
 #### Upgrades
 
- - [Docker 19.03.1](https://github.com/docker/docker-ce/releases/tag/v19.03.1)
- - [Docker Compose 1.24.1](https://github.com/docker/compose/releases/tag/1.24.1)
- - [Alpine 3.10](https://alpinelinux.org/posts/Alpine-3.10.0-released.html)
- - Linux Kernel 4.9.184
- - [Docker Credential Helpers 0.6.3](https://github.com/docker/docker-credential-helpers/releases/tag/v0.6.3)
+- [Docker 19.03.1](https://github.com/docker/docker-ce/releases/tag/v19.03.1)
+- [Docker Compose 1.24.1](https://github.com/docker/compose/releases/tag/1.24.1)
+- [Alpine 3.10](https://alpinelinux.org/posts/Alpine-3.10.0-released.html)
+- Linux Kernel 4.9.184
+- [Docker Credential Helpers 0.6.3](https://github.com/docker/docker-credential-helpers/releases/tag/v0.6.3)
 
 #### New
 
- - Introduced a new user interface for the Docker Desktop **Preferences** menu.
- - The **Restart**, **Reset**, and **Uninstall** options are now available on the **Troubleshoot** menu.
- 
+- Introduced a new user interface for the Docker Desktop **Preferences** menu.
+- The **Restart**, **Reset**, and **Uninstall** options are now available on the **Troubleshoot** menu.
+
 #### Bug fixes and minor changes
 
 - Changed the host's Kubernetes context to ensure `docker run -v .kube:kube ... kubectl` works.
@@ -549,26 +562,25 @@ This release contains Kubernetes security improvements. Note that your local Kub
 
 ## Docker Community Edition 2.0.5.0 2019-06-12
 
-
 This is the Edge channel, which gives you early access to our newest features. Be aware that some of them may be experimental, and some of them may not ever reach the Stable release.
 
 This release contains a Kubernetes upgrade. Note that your local Kubernetes cluster will be reset after install.
 
-* Upgrades
+- Upgrades
   - [Docker 19.03.0-rc2](https://github.com/docker/docker-ce/releases/tag/v19.03.0-rc2)
   - [Kubernetes 1.14.3](https://github.com/kubernetes/kubernetes/releases/tag/v1.14.3)
   - [Compose on Kubernetes 0.4.23](https://github.com/docker/compose-on-kubernetes/releases/tag/v0.4.23)
   - [linuxkit v0.7](https://github.com/linuxkit/linuxkit/releases/tag/v0.7)
   - [Qemu 4.0.0](https://github.com/docker/binfmt) for cross compiling for ARM
 
-* New
+- New
   - Docker Desktop includes the `buildx` plugin (currently experimental).
-  - Selecting the `Experimental features` checkbox on the Docker Desktop Preferences Daemon page enables experimental features in the  Docker daemon and the Docker CLI.
+  - Selecting the `Experimental features` checkbox on the Docker Desktop Preferences Daemon page enables experimental features in the Docker daemon and the Docker CLI.
   - Docker Desktop has improved the reliability of `com.docker.osxfs trace` performance profiling command.
   - Users can now run the `com.docker.osxfs trace --summary` option to get a high-level summary of operations, instead of receiving a trace of all operations.
   - Docker Desktop now supports large lists of DNS resource records on Mac. Fixes [docker/for-mac#2160](https://github.com/docker/for-mac/issues/2160#issuecomment-431571031)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Docker Desktop does not send DNS queries for `docker-desktop.<domain>` every 10s. It now relies on the host's DNS domain search order rather than trying to replicate it inside the VM.
   - Docker Desktop has removed the ability to log in using email address as a username as the Docker command line does not support this.
   - Docker Desktop now allows running a Docker registry inside a container. Fixes [docker/for-mac#3611](https://github.com/docker/for-mac/issues/3611)
@@ -576,31 +588,27 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 
 ## Docker Community Edition 2.0.4.1 2019-05-07
 
-
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Upgrade QEMU from 2.8.0 to 3.1.0 to fix an emulation issue when building and running Java applications on Arm64 devices.
 
 ## Docker Community Edition 2.0.4.0 2019-04-30
 
-
-* Upgrades
+- Upgrades
   - [Docker 19.03.0-beta3](https://github.com/docker/docker-ce/releases/tag/v19.03.0-beta3)
   - [Docker Compose 1.24.0](https://github.com/docker/compose/releases/tag/1.24.0)
   - [Compose on Kubernetes 0.4.22](https://github.com/docker/compose-on-kubernetes/releases/tag/v0.4.22)
   - [Kubernetes 1.14.1](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md#changelog-since-v1141)
 
-* New
+- New
   - App: Docker CLI plugin to configure, share, and install applications
-  
     - Extend Compose files with metadata and parameters
     - Reuse the same application across multiple environments (Development/QA/Staging/Production)
     - Multi-orchestrator installation (Swarm or Kubernetes)
     - Push/Pull/Promotion/Signing supported for application, with the same workflow as images
     - Fully CNAB compliant
     - Full support for Docker Contexts
-    
+
   - Buildx (Tech Preview): Docker CLI plugin for extended build capabilities with BuildKit
-  
     - Familiar UI from docker build
     - Full BuildKit capabilities with container driver
     - Multiple builder instance support
@@ -608,53 +616,49 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
     - Concurrent building of Compose files
     - High-level build constructs with `bake`
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Truncate UDP DNS responses which are over 512 bytes in size
 
 ## Docker Community Edition 2.0.3.0 2019-03-05
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.09.3](https://github.com/docker/docker-ce/releases/tag/v18.09.3)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fixed port 8080 that was used on localhost when starting Kubernetes. Fixes [docker/for-mac#3522](https://github.com/docker/for-mac/issues/3522)
   - Error message improvements, do not propose to run diagnostics / reset to factory default when not appropriate.
 
 ### Docker Community Edition 2.0.2.1 2019-02-15
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.09.2](https://github.com/docker/docker-ce/releases/tag/v18.09.2), fixes [CVE-2019-5736](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736)
 
 ## Docker Community Edition 2.0.2.0 2019-02-06
 
-
-* Upgrades
+- Upgrades
   - [Docker Compose 1.24.0-rc1](https://github.com/docker/compose/releases/tag/1.24.0-rc1)
   - [Docker Machine 0.16.1](https://github.com/docker/machine/releases/tag/v0.16.1)
   - [Compose on Kubernetes 0.4.18](https://github.com/docker/compose-on-kubernetes/releases/tag/v0.4.18)
 
-* New
+- New
   - Rebranded UI
-  
-* Bug fixes and minor changes
+
+- Bug fixes and minor changes
   - Kubernetes: use default maximum number of pods for kubelet. [docker/for-mac#3453](https://github.com/docker/for-mac/issues/3453)
   - Fix DockerHelper crash. [docker/for-mac#3470](https://github.com/docker/for-mac/issues/3470)
   - Fix binding of privileged ports with specified IP. [docker/for-mac#3464](https://github.com/docker/for-mac/issues/3464)
 
 ## Docker Community Edition 2.0.1.0 2019-01-11
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.09.1](https://github.com/docker/docker-ce/releases/tag/v18.09.1)
   - [Kubernetes 1.13.0](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md#v1130)
   - [Kitematic 0.17.6](https://github.com/docker/kitematic/releases/tag/v0.17.6)
   - Golang 1.10.6, fixes CVEs: [CVE-2018-16875](https://www.cvedetails.com/cve/CVE-2018-16875), [CVE-2018-16873](https://www.cvedetails.com/cve/CVE-2018-16873) and [CVE-2018-16874](https://www.cvedetails.com/cve/CVE-2018-16874)
-  
+
   WARNING: If you have an existing Kubernetes cluster created with Docker Desktop, this upgrade will reset the cluster. If you need to back up your Kubernetes cluster or persistent volumes you can use [Ark](https://github.com/heptio/ark).
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix service log collection in diagnostics
   - Gather /etc/hosts to help diagnostics
   - Ensure localhost resolves to 127.0.0.1. Related to [docker/for-mac#2990](https://github.com/docker/for-mac/issues/2990#issuecomment-443097942), [docker/for-mac#3383](https://github.com/docker/for-mac/issues/3383)
@@ -666,20 +670,18 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 
 ### Docker Community Edition 2.0.0.0-mac82 2018-12-07
 
-
-* Upgrades
+- Upgrades
   - [Docker compose 1.23.2](https://github.com/docker/compose/releases/tag/1.23.2)
   - [Docker Machine 0.16.0](https://github.com/docker/machine/releases/tag/v0.16.0)
 
 ### Docker Community Edition 2.0.0.0-mac77 2018-11-14
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.09.0](https://github.com/docker/docker-ce-packaging/releases/tag/v18.09.0)
   - [Docker compose 1.23.1](https://github.com/docker/compose/releases/tag/1.23.1)
   - [Kitematic 0.17.5](https://github.com/docker/kitematic/releases/tag/v0.17.5)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix appearance in dark mode for OS X 10.14 (Mojave)
   - VPNKit: Improved scalability of port forwarding. Related to [docker/for-mac#2841](https://github.com/docker/for-mac/issues/2841)
   - VPNKit: Limit the size of the UDP NAT table. This ensures port forwarding and regular TCP traffic continue even when running very chatty UDP protocols.
@@ -687,52 +689,48 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 
 ### Docker Community Edition 2.0.0.0-beta1-mac75 2018-09-14
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.09.0-ce-beta1](https://github.com/docker/docker-ce/releases/tag/v18.09.0-ce-beta1)
   - Linux Kernel 4.9.125
 
-* New
+- New
   - New version scheme
 
-* Deprecation
+- Deprecation
   - Removed support of AUFS
   - Removed support of OS X 10.11
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix panic in diagnose
 
 ### Docker Community Edition 18.06.1-ce-mac74 2018-08-29
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.06.1-ce](https://github.com/docker/docker-ce/releases/tag/v18.06.1-ce)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix local DNS failing to resolve inside containers.
 
 ### Docker Community Edition 18.06.0-ce-mac69 2018-07-25
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.06.0-ce](https://github.com/docker/docker-ce/releases/tag/v18.06.0-ce)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix bug in experimental SOCKS server. See [docker/for-mac#2670](https://github.com/docker/for-mac/issues/2670)
   - Fix bug in docker login when "Securely store Docker logins in macOS keychain" is unchecked. Fixed [docker/for-mac#3104](https://github.com/docker/for-mac/issues/3104)
 
 ### Docker Community Edition 18.06.0-ce-rc3-mac68 2018-07-19
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.06.0-ce-rc3](https://github.com/docker/docker-ce/releases/tag/v18.06.0-ce-rc3)
   - [Docker Machine 0.15.0](https://github.com/docker/machine/releases/tag/v0.15.0)
   - [Docker compose 1.22.0](https://github.com/docker/compose/releases/tag/1.22.0)
 
-* New
+- New
   - Add an experimental SOCKS server to allow access to container networks, see [docker/for-mac#2670](https://github.com/docker/for-mac/issues/2670#issuecomment-372365274). Also see [docker/for-mac#2721](https://github.com/docker/for-mac/issues/2721)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - AUFS storage driver is deprecated in Docker Desktop and AUFS support will be removed in the next major release. You can continue with AUFS in Docker Desktop 18.06.x, but you will need to reset disk image (in Preferences > Reset menu) before updating to the next major update. You can check documentation to [save images](/reference/cli/docker/image/save/#examples) and [back up volumes](/manuals/engine/storage/volumes.md#back-up-restore-or-migrate-data-volumes)
   - Fix startup issue with AUFS [docker/for-mac#2804](https://github.com/docker/for-mac/issues/2804)
   - Fix status bug which could prevent the Kubernetes cluster from starting. Fixes [docker/for-mac#2990](https://github.com/docker/for-mac/issues/2990)
@@ -742,31 +740,28 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 
 ### Docker Community Edition 18.05.0-ce-mac67 2018-06-07
 
-
-* Upgrades
+- Upgrades
   - [LinuxKit v0.4](https://github.com/linuxkit/linuxkit/releases/tag/v0.4)
   - Linux Kernel 4.9.93 with CEPH, DRBD, RBD, MPLS_ROUTING and MPLS_IPTUNNEL enabled
   - [Kubernetes 1.10.3](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#v1103). If Kubernetes is enabled, the upgrade will be performed automatically when starting Docker Desktop for Mac.
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix VPNKit memory leak. Fixes [moby/vpnkit#371](https://github.com/moby/vpnkit/issues/371)
   - Fix com.docker.supervisor using 100% CPU. Fixes [docker/for-mac#2967](https://github.com/docker/for-mac/issues/2967), [docker/for-mac#2923](https://github.com/docker/for-mac/issues/2923)
   - Do not override existing kubectl binary in /usr/local/bin (installed with brew or otherwise). Fixes [docker/for-mac#2368](https://github.com/docker/for-mac/issues/2368), [docker/for-mac#2890](https://github.com/docker/for-mac/issues/2890)
-  - Detect Vmnetd install error. Fixes [docker/for-mac#2934](https://github.com/docker/for-mac/issues/2934), [docker/for-mac#2687](https://github.com/docker/for-mac/issues/2687) 
+  - Detect Vmnetd install error. Fixes [docker/for-mac#2934](https://github.com/docker/for-mac/issues/2934), [docker/for-mac#2687](https://github.com/docker/for-mac/issues/2687)
   - Virtual machine default disk path is stored relative to $HOME. Fixes [docker/for-mac#2928](https://github.com/docker/for-mac/issues/2928), [docker/for-mac#1209](https://github.com/docker/for-mac/issues/1209)
-  
 
 ### Docker Community Edition 18.05.0-ce-mac66 2018-05-17
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.05.0-ce](https://github.com/docker/docker-ce/releases/tag/v18.05.0-ce)
   - [Docker compose 1.21.2](https://github.com/docker/compose/releases/tag/1.21.2)
 
-* New 
+- New
   - Allow orchestrator selection from the UI in the "Kubernetes" pane, to allow "docker stack" commands to deploy to Swarm clusters, even if Kubernetes is enabled in Docker for Mac.
-  
-* Bug fixes and minor changes
+
+- Bug fixes and minor changes
   - Use Simple NTP to minimize clock drift between the virtual machine and the host. Fixes [docker/for-mac#2076](https://github.com/docker/for-mac/issues/2076)
   - Fix filesystem event notifications for Swarm services and those using the new-style --mount option. Fixes [docker/for-mac#2216](https://github.com/docker/for-mac/issues/2216), [docker/for-mac#2375](https://github.com/docker/for-mac/issues/2375)
   - Fix filesystem event delivery to Kubernetes pods when the path to the bind mount is a symlink.
@@ -777,80 +772,73 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 
 ### Docker Community Edition 18.05.0-ce-rc1-mac63 2018-04-26
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.05.0-ce-rc1](https://github.com/docker/docker-ce/releases/tag/v18.05.0-ce-rc1)
   - [Notary 0.6.1](https://github.com/docker/notary/releases/tag/v0.6.1)
 
-* New 
+- New
   - Re-enable raw as the default disk format for users running macOS 10.13.4 and higher. Note this change only takes effect after a "reset to factory defaults" or "remove all data" (from the Whale menu > Preferences > Reset). Related to [docker/for-mac#2625](https://github.com/docker/for-mac/issues/2625)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix Docker for Mac not starting due to socket file paths being too long (typically HOME folder path being too long). Fixes [docker/for-mac#2727](https://github.com/docker/for-mac/issues/2727), [docker/for-mac#2731](https://github.com/docker/for-mac/issues/2731).
 
 ### Docker Community Edition 18.04.0-ce-mac62 2018-04-12
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.04.0-ce](https://github.com/docker/docker-ce/releases/tag/v18.04.0-ce)
   - [Docker compose 1.21.0](https://github.com/docker/compose/releases/tag/1.21.0)
 
 ### Docker Community Edition 18.04.0-ce-rc2-mac61 2018-04-09
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.04.0-ce-rc2](https://github.com/docker/docker-ce/releases/tag/v18.04.0-ce-rc2)
   - [Kubernetes 1.9.6](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md#v196). If Kubernetes is enabled, the upgrade will be performed automatically when starting Docker for Mac.
 
-* New 
+- New
   - Enable ceph & rbd modules in LinuxKit virtual machine.
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix upgrade straight from pre-17.12 versions where Docker for Mac cannot restart once the upgrade has been performed. Fixes [docker/for-mac#2739](https://github.com/docker/for-mac/issues/2739)
 
 ### Docker Community Edition 18.03.0-ce-mac58 2018-03-26
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.03.0-ce](https://github.com/docker/docker-ce/releases/tag/v18.03.0-ce)
   - [Docker compose 1.20.1](https://github.com/docker/compose/releases/tag/1.20.1)
 
 ### Docker Community Edition 18.03.0-ce-rc4-mac57 2018-03-15
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.03.0-ce-rc4](https://github.com/docker/docker-ce/releases/tag/v18.03.0-ce-rc4)
   - AUFS 20180312
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix support for AUFS. Fixes [docker/for-win#1831](https://github.com/docker/for-win/issues/1831)
   - Fix synchronization between CLI `docker login` and GUI login.
 
 ### Docker Community Edition 18.03.0-ce-rc3-mac56 2018-03-13
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.03.0-ce-rc3](https://github.com/docker/docker-ce/releases/tag/v18.03.0-ce-rc3)
   - [Docker Machine 0.14.0](https://github.com/docker/machine/releases/tag/v0.14.0)
   - [Docker compose 1.20.0-rc2](https://github.com/docker/compose/releases/tag/1.20.0-rc2)
   - [Notary 0.6.0](https://github.com/docker/notary/releases/tag/v0.6.0)
   - Linux Kernel 4.9.87
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix for the HTTP/S transparent proxy when using "localhost" names (for example "host.docker.internal", "docker.for.mac.host.internal", "docker.for.mac.localhost").
   - Fix daemon not starting properly when setting TLS-related options. Fixes [docker/for-mac#2663](https://github.com/docker/for-mac/issues/2663)
 
 ### Docker Community Edition 18.03.0-ce-rc1-mac54 2018-02-27
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.03.0-ce-rc1](https://github.com/docker/docker-ce/releases/tag/v18.03.0-ce-rc1)
 
-* New
+- New
   - Virtual machine Swap size can be changed in settings. See [docker/for-mac#2566](https://github.com/docker/for-mac/issues/2566), [docker/for-mac#2389](https://github.com/docker/for-mac/issues/2389)
   - Support NFS Volume sharing. Also works in Kubernetes.
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Revert the default disk format to qcow2 for users running macOS 10.13 (High Sierra). There are confirmed reports of file corruption using the raw format which uses sparse files on APFS. This change only takes effect after a reset to factory defaults (from the Whale menu -> Preferences -> Reset). Related to [docker/for-mac#2625](https://github.com/docker/for-mac/issues/2625)
   - DNS name `host.docker.internal` should be used for host resolution from containers. Older aliases (still valid) are deprecated in favor of this one. (See https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06).
   - Kubernetes Load balanced services are no longer marked as `Pending`.
@@ -859,109 +847,101 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 
 ### Docker Community Edition 18.02.0-ce-mac53 2018-02-09
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.02.0-ce](https://github.com/docker/docker-ce/releases/tag/v18.02.0-ce)
   - [Docker compose 1.19.0](https://github.com/docker/compose/releases/tag/1.19.0)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix update startup failure in some cases.
   - Fix empty registry added by mistake in some cases in the Preference Daemon Pane. Fixes [docker/for-mac#2537](https://github.com/docker/for-mac/issues/2537)
   - Clearer error message when incompatible hardware is detected. Diagnostics are not proposed in the error popup in this case.
 
 ### Docker Community Edition 18.02.0-ce-rc2-mac51 2018-02-02
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.02.0-ce-rc2](https://github.com/docker/docker-ce/releases/tag/v18.02.0-ce-rc2)
   - [Docker compose 1.19.0-rc2](https://github.com/docker/compose/releases/tag/1.19.0-rc2)
   - [Kubernetes 1.9.2](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md#v192). If you have Kubernetes enabled, the upgrade will be performed automatically when starting Docker for Mac.
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix Kubernetes-compose integration update that was causing startup failure. Fixes [docker/for-mac#2536](https://github.com/docker/for-mac/issues/2536)
   - Fix some cases where selecting "Reset" after an error did not reset properly.
   - Fix incorrect NTP config. Fixes [docker/for-mac#2529](https://github.com/docker/for-mac/issues/2529)
 
 ### Docker Community Edition 18.02.0-ce-rc1-mac50 2018-01-26
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.02.0-ce-rc1](https://github.com/docker/docker-ce/releases/tag/v18.02.0-ce-rc1)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Added "Restart" menu item. See [docker/for-mac#2407](https://github.com/docker/for-mac/issues/2407)
   - Keep any existing kubectl binary when activating Kubernetes in Docker for Mac, and restore it when disabling Kubernetes. Fixes [docker/for-mac#2508](https://github.com/docker/for-mac/issues/2508), [docker/for-mac#2368](https://github.com/docker/for-mac/issues/2368)
   - Fix Kubernetes context selector. Fixes [docker/for-mac#2495](https://github.com/docker/for-mac/issues/2495)
 
 ### Docker Community Edition 18.01.0-ce-mac48 2018-01-19
 
-
-* Upgrades
+- Upgrades
   - [Docker 18.01.0-ce](https://github.com/docker/docker-ce/releases/tag/v18.01.0-ce)
   - Linux Kernel 4.9.75
 
-* New
+- New
   - The directory holding the disk images was renamed (from `~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux` to ~/Library/Containers/com.docker.docker/Data/vms/0`).
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix error during resize/create Docker.raw disk image in some cases. Fixes [docker/for-mac#2383](https://github.com/docker/for-mac/issues/2383), [docker/for-mac#2447](https://github.com/docker/for-mac/issues/2447), [docker/for-mac#2453], (https://github.com/docker/for-mac/issues/2453), [docker/for-mac#2420](https://github.com/docker/for-mac/issues/2420)
   - Fix additional allocated disk space not available in containers. Fixes [docker/for-mac#2449](https://github.com/docker/for-mac/issues/2449)
   - VPNkit port max idle time default restored to 300s. Fixes [docker/for-mac#2442](https://github.com/docker/for-mac/issues/2442)
   - Fix using an HTTP proxy with authentication. Fixes [docker/for-mac#2386](https://github.com/docker/for-mac/issues/2386)
-  - Allow HTTP proxy excludes to be written as .docker.com as well as *.docker.com
+  - Allow HTTP proxy excludes to be written as .docker.com as well as \*.docker.com
   - Allow individual IP addresses to be added to HTTP proxy excludes.
-  - Avoid hitting DNS timeouts when querying docker.for.mac.* when the upstream DNS servers are slow or missing.
+  - Avoid hitting DNS timeouts when querying docker.for.mac.\* when the upstream DNS servers are slow or missing.
   - Fix for `docker push` to an insecure registry. Fixes [docker/for-mac#2392](https://github.com/docker/for-mac/issues/2392)
   - Separate internal ports used to proxy HTTP and HTTPS content.
   - If kubectl was already installed before Docker For Mac, restore the existing kubectl when switching Kubernetes off in Docker for Mac.
   - Migration of Docker Toolbox images is not proposed anymore in Docker For Mac installer (still possible to migrate Toolbox images manually).
 
-
 ### Docker Community Edition 17.12.0-ce-mac45 2018-01-05
 
-
-* Upgrades
+- Upgrades
   - [Docker 17.12.0-ce](https://github.com/docker/docker-ce/releases/tag/v17.12.0-ce)
 
-* New
-  - Experimental Kubernetes Support. You can now run a single-node Kubernetes cluster from the "Kubernetes" Pane in Docker For Mac Preferences and use kubectl commands as well as docker commands. See [the Kubernetes section](/manuals/desktop/features/kubernetes.md)
+- New
+  - Experimental Kubernetes Support. You can now run a single-node Kubernetes cluster from the "Kubernetes" Pane in Docker For Mac Preferences and use kubectl commands as well as docker commands. See [the Kubernetes section](/manuals/desktop/use-desktop/kubernetes.md)
   - DNS name `docker.for.mac.host.internal` should be used instead of `docker.for.mac.localhost` (still valid) for host resolution from containers, since since there is an RFC banning the use of subdomains of localhost (See https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06).
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - The docker engine is configured to use VPNKit as an HTTP proxy, fixing 'docker pull' in environments with no DNS. Fixes [docker/for-mac#2320](https://github.com/docker/for-mac/issues/2320)
 
 ## Edge Releases of 2017
 
 ### Docker Community Edition 17.12.0-ce-rc4-mac44 2017-12-21
 
-
-* Upgrades
+- Upgrades
   - [Docker 17.12.0-ce-rc4](https://github.com/docker/docker-ce/releases/tag/v17.12.0-ce-rc4)
   - [Docker compose 1.18.0](https://github.com/docker/compose/releases/tag/1.18.0)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Display actual size used by the virtual machine disk, especially useful for disks using raw format. See [docker/for-mac#2297](https://github.com/docker/for-mac/issues/2297).
   - Fix more specific edge cases in filesharing settings migration.
 
 ### Docker Community Edition 17.12.0-ce-rc3-mac43 2017-12-15
 
-
-* Upgrades
+- Upgrades
   - [Docker 17.12.0-ce-rc3](https://github.com/docker/docker-ce/releases/tag/v17.12.0-ce-rc3)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix filesharing migration issue ([docker/for-mac#2317](https://github.com/docker/for-mac/issues/2317))
 
 ### Docker Community Edition 17.12.0-ce-rc2-mac41 2017-12-13
 
-* Upgrades
+- Upgrades
   - [Docker 17.12.0-ce-rc2](https://github.com/docker/docker-ce/releases/tag/v17.12.0-ce-rc2)
   - [Docker compose 1.18.0-rc2](https://github.com/docker/compose/releases/tag/1.18.0-rc2)
 
-* New
+- New
   - Virtual machine disk size can be changed in settings. (See [docker/for-mac#1037](https://github.com/docker/for-mac/issues/1037)).
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Avoid virtual machine reboot when changing host proxy settings.
   - Don't break HTTP traffic between containers by forwarding them through the external proxy [docker/for-mac#981](https://github.com/docker/for-mac/issues/981)
   - Filesharing settings are now stored in settings.json
@@ -971,100 +951,98 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 
 ### Docker Community Edition 17.11.0-ce-mac40 2017-11-22
 
-
-* Upgrades
+- Upgrades
   - [Docker 17.11.0-ce](https://github.com/docker/docker-ce/releases/tag/v17.11.0-ce)
 
 ### Docker Community Edition 17.11.0-ce-rc4-mac39 2017-11-17
 
-* Upgrades
+- Upgrades
   - [Docker 17.11.0-ce-rc4](https://github.com/docker/docker-ce/releases/tag/v17.11.0-ce-rc4)
   - [Docker compose 1.17.1](https://github.com/docker/compose/releases/tag/1.17.1)
   - Linux kernel 4.9.60
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix login into private repository with certificate issue. [docker/for-mac#2201](https://github.com/docker/for-mac/issues/2201)
 
-* New
+- New
   - For systems running APFS on SSD on High Sierra, use `raw` format virtual machine disks by default. This increases disk throughput (from 320MiB/sec to 600MiB/sec in `dd` on a 2015 MacBook Pro) and disk space handling.
-  Existing disks are kept in qcow format, if you want to switch to raw format you need to "Reset to factory defaults". To query the space usage of the file, use a command like:
-  `$ cd ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/`
-  `$ ls -ls Docker.raw`
-  `3944768 -rw-r--r--@ 1 user  staff  68719476736 Nov 16 11:19 Docker.raw`
-  The first number (`3944768`) is the allocated space in blocks; the larger number `68719476736` is the maximum total amount of space the file may consume in future in bytes.
+    Existing disks are kept in qcow format, if you want to switch to raw format you need to "Reset to factory defaults". To query the space usage of the file, use a command like:
+    `$ cd ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/`
+    `$ ls -ls Docker.raw`
+    `3944768 -rw-r--r--@ 1 user  staff  68719476736 Nov 16 11:19 Docker.raw`
+    The first number (`3944768`) is the allocated space in blocks; the larger number `68719476736` is the maximum total amount of space the file may consume in future in bytes.
 
 ### Docker Community Edition 17.11.0-ce-rc3-mac38 2017-11-09
 
-* Upgrades
+- Upgrades
   - [Docker 17.11.0-ce-rc3](https://github.com/docker/docker-ce/releases/tag/v17.11.0-ce-rc3)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix Docker build exits successfully but fails to build image [moby/#35413](https://github.com/moby/moby/issues/35413).
 
 ### Docker Community Edition 17.11.0-ce-rc2-mac37 2017-11-02
 
-* Upgrades
+- Upgrades
   - [Docker 17.11.0-ce-rc2](https://github.com/docker/docker-ce/releases/tag/v17.11.0-ce-rc2)
   - [Docker compose 1.17.0](https://github.com/docker/compose/releases/tag/1.17.0)
   - Linuxkit blueprint updated to [linuxkit/linuxkit#2633](https://github.com/linuxkit/linuxkit/pull/2633), fixes CVE-2017-15650
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix centos:5 & centos:6 images not starting properly with LinuxKit virtual machine (fixes [docker/for-mac#2169](https://github.com/docker/for-mac/issues/2169)).
 
-
 ### Docker Community Edition 17.10.0-ce-mac36 2017-10-24
 
-* Upgrades
+- Upgrades
   - [Docker 17.10.0-ce](https://github.com/docker/docker-ce/releases/tag/v17.10.0-ce)
   - [Docker Machine 0.13.0](https://github.com/docker/machine/releases/tag/v0.13.0)
   - [Docker compose 1.17.0-rc1](https://github.com/docker/compose/releases/tag/1.17.0-rc1)
 
-* New
+- New
   - Virtual machine entirely built with Linuxkit
 
 ### Docker Community Edition 17.09.0-ce-mac34 2017-10-06
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix Docker For Mac unable to start in some cases : removed use of libgmp sometimes causing the vpnkit process to die.
 
 ### Docker Community Edition 17.09.0-ce-mac31 2017-09-29
 
-* Upgrades
+- Upgrades
   - [Docker 17.09.0-ce](https://github.com/docker/docker-ce/releases/tag/v17.09.0-ce)
   - DataKit update (fix instability on High Sierra)
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Fix password encoding/decoding. May require to re-login to docker cloud after this version is installed. (Fixes:docker/for-mac#2008, docker/for-mac#2016, docker/for-mac#1919, docker/for-mac#712, docker/for-mac#1220).
 
 ### Docker Community Edition 17.09.0-ce-rc3-mac30 2017-09-22
 
-* Upgrades
+- Upgrades
   - [Docker 17.09.0-ce-rc3](https://github.com/docker/docker-ce/releases/tag/v17.09.0-ce-rc3)
 
 ### Docker Community Edition 17.09.0-ce-rc2-mac29 2017-09-19
 
-* Upgrades
+- Upgrades
   - [Docker 17.09.0-ce-rc2](https://github.com/docker/docker-ce/releases/tag/v17.09.0-ce-rc2)
   - Linux Kernel 4.9.49
   - AUFS 20170911
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - Kernel: Enable TASK_XACCT and TASK_IO_ACCOUNTING [docker/for-mac#1608](https://github.com/docker/for-mac/issues/1608)
   - Rotate logs in the virtual machine more often
 
 ### Docker Community Edition 17.09.0-ce-rc1-mac28 2017-09-07
 
-* Upgrades
+- Upgrades
   - [Docker 17.09.0-ce-rc1](https://github.com/docker/docker-ce/releases/tag/v17.09.0-ce-rc1)
   - [Docker compose 1.16.1](https://github.com/docker/compose/releases/tag/1.16.1)
   - Linux Kernel 4.9.46
 
-* Bug fixes and minor changes
+- Bug fixes and minor changes
   - VPNKit: change protocol to support error messages reported back from the server
 
 ### Docker Community Edition 17.07.0-ce-mac26, 2017-09-01
 
-* Upgrades
+- Upgrades
   - [Docker 17.07.0-ce](https://github.com/docker/docker-ce/releases/tag/v17.07.0-ce)
   - [Docker compose 1.16.0](https://github.com/docker/compose/releases/tag/1.16.0)
   - [Docker Credential Helpers 0.6.0](https://github.com/docker/docker-credential-helpers/releases/tag/v0.6.0)
@@ -1080,8 +1058,8 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 
 - Fixed string validation in daemon options (related to [docker/for-mac#1971](https://github.com/docker/for-mac/issues/1971))
 - VPNKit: Fixed a bug which causes a socket to leak if the corresponding
-TCP connection is idle for more than five minutes (related to
-[docker/for-mac#1374](https://github.com/docker/for-mac/issues/1374))
+  TCP connection is idle for more than five minutes (related to
+  [docker/for-mac#1374](https://github.com/docker/for-mac/issues/1374))
 
 ### Docker Community Edition 17.07.0-ce-rc3-mac23, 2017-08-21
 
@@ -1126,7 +1104,7 @@ TCP connection is idle for more than five minutes (related to
 
 - Add daemon options validation
 - Diagnose can be cancelled & Improved help information. Fixes [docker/for-mac#1134](https://github.com/docker/for-mac/issues/1134), [docker/for-mac#1474](https://github.com/docker/for-mac/issues/1474)
-- Support paging of Docker Cloud [repositories](../../docker-hub/repos/_index.md) and [organizations](../../admin/organization/orgs.md). Fixes [docker/for-mac#1538](https://github.com/docker/for-mac/issues/1538)
+- Support paging of Docker Cloud [repositories](../../docker-hub/repos/_index.md) and [organizations](../../admin/organization/setup/orgs.md). Fixes [docker/for-mac#1538](https://github.com/docker/for-mac/issues/1538)
 
 ### Docker Community Edition 17.06.1-ce-mac20, 2017-07-18
 
@@ -1218,7 +1196,6 @@ TCP connection is idle for more than five minutes (related to
 
 - [Docker 17.05.0-ce-rc1](https://github.com/docker/docker/releases/tag/v17.05.0-ce-rc1)
 
-
 ### Docker Community Edition 17.04.0-ce-mac7, 2017-04-06
 
 **New**
@@ -1255,7 +1232,6 @@ TCP connection is idle for more than five minutes (related to
 - Disk trimming should work as expected
 - Diagnostics now contains more settings data
 
-
 ### Docker Community Edition 17.03.1-ce-rc1-mac3, 2017-03-28
 
 **Upgrades**
@@ -1390,7 +1366,6 @@ TCP connection is idle for more than five minutes (related to
 - Fix for swap not being mounted
 - Fix AUFS xattr delete issue ([docker/docker#30245](https://github.com/docker/docker/issues/30245))
 
-
 ### Beta 38 Release Notes (2017-01-20 1.13.0-beta38)
 
 **Upgrades**
@@ -1613,7 +1588,6 @@ TCP connection is idle for more than five minutes (related to
 - Improvements to Logging and Diagnostics
 - osxfs: switched to `libev/kqueue` to improve latency
 
-
 ### Beta 29.3 Release Notes (2016-11-02 1.12.3-beta29.3)
 
 **Upgrades**
@@ -1651,7 +1625,7 @@ TCP connection is idle for more than five minutes (related to
 - Fixed application of system or custom proxy settings over container restart
 - Increased default ulimit for memlock (fixes [docker/for-mac#801](https://github.com/docker/for-mac/issues/801) )
 - Fixed an issue where the Docker status would continue to be
-      yellow/animated after the VM had started correctly
+  yellow/animated after the VM had started correctly
 - osxfs: fixed the prohibition of chown on read-only or mode 0 files (fixes [docker/for-mac#117](https://github.com/docker/for-mac/issues/117), [docker/for-mac#263](https://github.com/docker/for-mac/issues/263), [docker/for-mac#633](https://github.com/docker/for-mac/issues/633) )
 
 ### Beta 28 Release Notes (2016-10-13 1.12.2-rc3-beta28)
@@ -1673,179 +1647,179 @@ TCP connection is idle for more than five minutes (related to
 
 **Upgrades**
 
-* Docker 1.12.2-rc1
-* Docker Machine 0.8.2
-* Docker compose 1.8.1
-* Kernel vsock driver v7
-* Kernel 4.4.21
-* AUFS 20160912
+- Docker 1.12.2-rc1
+- Docker Machine 0.8.2
+- Docker compose 1.8.1
+- Kernel vsock driver v7
+- Kernel 4.4.21
+- AUFS 20160912
 
 **Bug fixes and minor changes**
 
-* Fixed an issue where some windows did not claim focus correctly
-* Added UI when switching channel to prevent user losing containers and settings
-* Check disk capacity before Toolbox import
-* Import certificates in `etc/ssl/certs/ca-certificates.crt`
-* DNS: reduce the number of UDP sockets consumed on the host
-* VPNkit: improve the connection-limiting code to avoid running out of sockets on the host
-* UDP: handle diagrams bigger than 2035, up to the configured macOS kernel limit
-* UDP: made the forwarding more robust; now, drop packets and continue rather than stopping
-* disk: made the "flush" behaviour configurable for database-like workloads. This works around a performance regression in `v1.12.1`.
+- Fixed an issue where some windows did not claim focus correctly
+- Added UI when switching channel to prevent user losing containers and settings
+- Check disk capacity before Toolbox import
+- Import certificates in `etc/ssl/certs/ca-certificates.crt`
+- DNS: reduce the number of UDP sockets consumed on the host
+- VPNkit: improve the connection-limiting code to avoid running out of sockets on the host
+- UDP: handle diagrams bigger than 2035, up to the configured macOS kernel limit
+- UDP: made the forwarding more robust; now, drop packets and continue rather than stopping
+- disk: made the "flush" behaviour configurable for database-like workloads. This works around a performance regression in `v1.12.1`.
 
 ### Beta 26 Release Notes (2016-09-14 1.12.1-beta26)
 
 **New**
 
-* Improved support for macOS 10.12 Sierra
+- Improved support for macOS 10.12 Sierra
 
 **Upgrades**
 
-* Linux kernel 4.4.20
-* AUFS 20160905
+- Linux kernel 4.4.20
+- AUFS 20160905
 
 **Bug fixes and minor changes**
 
-* Fixed communications glitch when UI talks to `com.docker.vmnetd`. Fixes [docker/for-mac#90](https://github.com/docker/for-mac/issues/90)
+- Fixed communications glitch when UI talks to `com.docker.vmnetd`. Fixes [docker/for-mac#90](https://github.com/docker/for-mac/issues/90)
 
-* UI fix for macOs 10.12
+- UI fix for macOs 10.12
 
-* Windows open on top of full screen app are available in all spaces
+- Windows open on top of full screen app are available in all spaces
 
-* Reporting a bug, while not previously logged into GitHub now works
+- Reporting a bug, while not previously logged into GitHub now works
 
-* When a diagnostic upload fails, the error is properly reported
+- When a diagnostic upload fails, the error is properly reported
 
-* `docker-diagnose` displays and records the time the diagnosis was captured
+- `docker-diagnose` displays and records the time the diagnosis was captured
 
-* Ports are allowed to bind to host addresses other than `0.0.0.0` and `127.0.0.1`. Fixes issue reported in [docker/for-mac#68](https://github.com/docker/for-mac/issues/68).
+- Ports are allowed to bind to host addresses other than `0.0.0.0` and `127.0.0.1`. Fixes issue reported in [docker/for-mac#68](https://github.com/docker/for-mac/issues/68).
 
-* We no longer compute the container folder in `com.docker.vmnetd`. Fixes [docker/for-mac#47](https://github.com/docker/for-mac/issues/47).
+- We no longer compute the container folder in `com.docker.vmnetd`. Fixes [docker/for-mac#47](https://github.com/docker/for-mac/issues/47).
 
 **Known Issues**
 
-* `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode. The
-issue is being investigated. The workaround is to restart Docker.app.
+- `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode. The
+  issue is being investigated. The workaround is to restart Docker.app.
 
-* There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and
-traversals of large directories are currently slow. Additionally, containers
-that perform large numbers of directory operations, such as repeated scans of
-large directory trees, may suffer from poor performance. More information is
-available in [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md) in Troubleshooting.
+- There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and
+  traversals of large directories are currently slow. Additionally, containers
+  that perform large numbers of directory operations, such as repeated scans of
+  large directory trees, may suffer from poor performance. More information is
+  available in [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md) in Troubleshooting.
 
-* Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart `Docker.app`.
+- Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart `Docker.app`.
 
 ### Beta 25 Release Notes (2016-09-07 1.12.1-beta25)
 
 **Upgrades**
 
-* Experimental support for macOS 10.12 Sierra (beta)
+- Experimental support for macOS 10.12 Sierra (beta)
 
 **Bug fixes and minor changes**
 
-* VPNKit supports search domains
-* Entries from `/etc/hosts` should now resolve from within containers
-* osxfs: fix thread leak
+- VPNKit supports search domains
+- Entries from `/etc/hosts` should now resolve from within containers
+- osxfs: fix thread leak
 
 **Known issues**
 
-* Several problems have been reported on macOS 10.12 Sierra and are being
-investigated. This includes failure to launch the app and being unable to
-upgrade to a new version.
+- Several problems have been reported on macOS 10.12 Sierra and are being
+  investigated. This includes failure to launch the app and being unable to
+  upgrade to a new version.
 
-* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The
-issue is being investigated. The workaround is to restart Docker.app
+- Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The
+  issue is being investigated. The workaround is to restart Docker.app
 
-* There are a number of issues with the performance of directories bind-mounted
-with `osxfs`. In particular, writes of small blocks and traversals of large
-directories are currently slow. Additionally, containers that perform large
-numbers of directory operations, such as repeated scans of large directory
-trees, may suffer from poor performance. More information is available in
-[Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md) in Troubleshooting.
+- There are a number of issues with the performance of directories bind-mounted
+  with `osxfs`. In particular, writes of small blocks and traversals of large
+  directories are currently slow. Additionally, containers that perform large
+  numbers of directory operations, such as repeated scans of large directory
+  trees, may suffer from poor performance. More information is available in
+  [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md) in Troubleshooting.
 
-* Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart Docker.app.
+- Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart Docker.app.
 
 ### Beta 24 Release Notes (2016-08-23 1.12.1-beta24)
 
 **Upgrades**
 
-* Docker 1.12.1
-* Docker Machine 0.8.1
-* Linux kernel 4.4.19
-* AUFS 20160822
+- Docker 1.12.1
+- Docker Machine 0.8.1
+- Linux kernel 4.4.19
+- AUFS 20160822
 
 **Bug fixes and minor changes**
 
-* osxfs: fixed a malfunction of new directories that have the same name as an old directory that is still open
+- osxfs: fixed a malfunction of new directories that have the same name as an old directory that is still open
 
-* osxfs: rename events now trigger DELETE and/or MODIFY `inotify` events (saving with TextEdit works now)
+- osxfs: rename events now trigger DELETE and/or MODIFY `inotify` events (saving with TextEdit works now)
 
-* slirp: support up to 8 external DNS servers
+- slirp: support up to 8 external DNS servers
 
-* slirp: reduce the number of sockets used by UDP NAT, reduce the probability that NAT rules will time out earlier than expected
+- slirp: reduce the number of sockets used by UDP NAT, reduce the probability that NAT rules will time out earlier than expected
 
-* The app warns user if BlueStacks is installed (potential kernel panic)
+- The app warns user if BlueStacks is installed (potential kernel panic)
 
 **Known issues**
 
-* Several problems have been reported on macOS 10.12 Sierra and are being investigated. This includes failure to launch the app and being unable to upgrade to a new version.
+- Several problems have been reported on macOS 10.12 Sierra and are being investigated. This includes failure to launch the app and being unable to upgrade to a new version.
 
-* `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode.  The issue is being investigated. The workaround is to restart `Docker.app`.
+- `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart `Docker.app`.
 
-* There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and traversals of large
-directories are currently slow. Additionally, containers that perform large
-numbers of directory operations, such as repeated scans of large directory
-trees, may suffer from poor performance. For more information and workarounds, see the bullet on performance of bind-mounted directories in [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md) in Troubleshooting.
+- There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and traversals of large
+  directories are currently slow. Additionally, containers that perform large
+  numbers of directory operations, such as repeated scans of large directory
+  trees, may suffer from poor performance. For more information and workarounds, see the bullet on performance of bind-mounted directories in [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md) in Troubleshooting.
 
-* Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart `Docker.app`.
+- Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart `Docker.app`.
 
 ### Beta 23 Release Notes (2016-08-16 1.12.1-rc1-beta23)
 
 **Upgrades**
 
-* Docker 1.12.1-rc1
-* Linux kernel 4.4.17
-* AUFS 20160808
+- Docker 1.12.1-rc1
+- Linux kernel 4.4.17
+- AUFS 20160808
 
 **Bug fixes and minor changes**
 
-* Moby: use default sysfs settings, transparent huge pages disabled
-* Moby: cgroup mount to support systemd in containers
-* osxfs: fixed an issue that caused `inotify` failure and crashes
-* osxfs: fixed a directory fd leak
-* Zsh completions
+- Moby: use default sysfs settings, transparent huge pages disabled
+- Moby: cgroup mount to support systemd in containers
+- osxfs: fixed an issue that caused `inotify` failure and crashes
+- osxfs: fixed a directory fd leak
+- Zsh completions
 
 **Known issues**
 
-*  Docker for Mac is not supported on macOS 10.12 Sierra
+- Docker for Mac is not supported on macOS 10.12 Sierra
 
-* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
+- Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
 
-* There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and traversals of large directories are currently slow. Additionally, containers that perform large numbers of directory operations, such as repeated scans of large directory trees, may suffer from poor performance. For more information and workarounds, see the bullet on performance of bind-mounted directories in [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md) in Troubleshooting.
+- There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and traversals of large directories are currently slow. Additionally, containers that perform large numbers of directory operations, such as repeated scans of large directory trees, may suffer from poor performance. For more information and workarounds, see the bullet on performance of bind-mounted directories in [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md) in Troubleshooting.
 
-* Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart Docker.app
+- Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart Docker.app
 
 ### Beta 22 Release Notes (2016-08-11 1.12.0-beta22)
 
 **Upgrades**
 
-*  Linux kernel to 4.4.16
+- Linux kernel to 4.4.16
 
 **Bug fixes and minor changes**
 
-* Increase Moby fs.file-max to 524288
-* Use Mac System Configuration database to detect DNS
-* HyperKit updated with dtrace support and lock fixes
-* Fix Moby Diagnostics and Update Kernel
-* UI Fixes
-* osxfs: fix socket chowns
+- Increase Moby fs.file-max to 524288
+- Use Mac System Configuration database to detect DNS
+- HyperKit updated with dtrace support and lock fixes
+- Fix Moby Diagnostics and Update Kernel
+- UI Fixes
+- osxfs: fix socket chowns
 
 **Known issues**
 
-* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
+- Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
 
-* There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and traversals of large directories are currently slow. Additionally, containers that perform large numbers of directory operations, such as repeated scans of large directory trees, may suffer from poor performance. More information is available in [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
+- There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks and traversals of large directories are currently slow. Additionally, containers that perform large numbers of directory operations, such as repeated scans of large directory trees, may suffer from poor performance. More information is available in [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
 
-* Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart Docker.app
+- Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart Docker.app
 
 ### Beta 21.1 Release Notes (2016-08-03 1.12.0-beta21.1)
 
@@ -1855,86 +1829,86 @@ events or unexpected unmounts.
 
 **Hotfixes**
 
-* osxfs: fixed an issue causing access to children of renamed directories to fail (symptoms: npm failures, apt-get failures)
+- osxfs: fixed an issue causing access to children of renamed directories to fail (symptoms: npm failures, apt-get failures)
 
-* osxfs: fixed an issue causing some ATTRIB and CREATE `inotify` events to fail delivery and other `inotify` events to stop
+- osxfs: fixed an issue causing some ATTRIB and CREATE `inotify` events to fail delivery and other `inotify` events to stop
 
-* osxfs: fixed an issue causing all `inotify` events to stop when an ancestor directory of a mounted directory was mounted
+- osxfs: fixed an issue causing all `inotify` events to stop when an ancestor directory of a mounted directory was mounted
 
-* osxfs: fixed an issue causing volumes mounted under other mounts to spontaneously unmount (docker/docker#24503)
+- osxfs: fixed an issue causing volumes mounted under other mounts to spontaneously unmount (docker/docker#24503)
 
 ### Docker for Mac 1.12.0 (2016-07-28 1.12.0-beta21)
 
 **New**
 
-* Docker for Mac is now available from 2 channels: **stable** and **beta**. New features and bug fixes will go out first in auto-updates to users in the beta channel. Updates to the stable channel are much less frequent and happen in sync with major and minor releases of the Docker Engine. Only features that are well-tested and ready for production are added to the stable channel releases. For downloads of both and more information, see the [installation guide](/manuals/desktop/setup/install/mac-install.md).
+- Docker for Mac is now available from 2 channels: **stable** and **beta**. New features and bug fixes will go out first in auto-updates to users in the beta channel. Updates to the stable channel are much less frequent and happen in sync with major and minor releases of the Docker Engine. Only features that are well-tested and ready for production are added to the stable channel releases. For downloads of both and more information, see the [installation guide](/manuals/desktop/setup/install/mac-install.md).
 
 **Upgrades**
 
-* Docker 1.12.0 with experimental features
-* Docker Machine 0.8.0
-* Docker Compose 1.8.0
+- Docker 1.12.0 with experimental features
+- Docker Machine 0.8.0
+- Docker Compose 1.8.0
 
 **Bug fixes and minor changes**
 
-* Check for updates, auto-update and diagnose can be run by non-admin users
-* osxfs: fixed an issue causing occasional incorrect short reads
-* osxfs: fixed an issue causing occasional EIO errors
-* osxfs: fixed an issue causing `inotify` creation events to fail
-* osxfs: increased the `fs.inotify.max_user_watches` limit in Moby to 524288
-* The UI shows documentation link for sharing volumes
-* Clearer error message when running with outdated VirtualBox version
-* Added link to sources for qemu-img
+- Check for updates, auto-update and diagnose can be run by non-admin users
+- osxfs: fixed an issue causing occasional incorrect short reads
+- osxfs: fixed an issue causing occasional EIO errors
+- osxfs: fixed an issue causing `inotify` creation events to fail
+- osxfs: increased the `fs.inotify.max_user_watches` limit in Moby to 524288
+- The UI shows documentation link for sharing volumes
+- Clearer error message when running with outdated VirtualBox version
+- Added link to sources for qemu-img
 
 **Known issues**
 
-* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
+- Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
 
-* There are a number of issues with the performance of directories bind-mounted with `osxfs`.  In particular, writes of small blocks, and traversals of large directories are currently slow.  Additionally, containers that perform large numbers of directory operations, such as repeated scans of large directory trees, may suffer from poor performance. For more information and workarounds, see [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md) in [Logs and Troubleshooting](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md).
+- There are a number of issues with the performance of directories bind-mounted with `osxfs`. In particular, writes of small blocks, and traversals of large directories are currently slow. Additionally, containers that perform large numbers of directory operations, such as repeated scans of large directory trees, may suffer from poor performance. For more information and workarounds, see [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md) in [Logs and Troubleshooting](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md).
 
-* Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart Docker.app
+- Under some unhandled error conditions, `inotify` event delivery can fail and become permanently disabled. The workaround is to restart Docker.app
 
 ### Beta 20 Release Notes (2016-07-19 1.12.0-rc4-beta20)
 
 **Bug fixes and minor changes**
 
-* Fixed `docker.sock` permission issues
-* Don't check for update when the settings panel opens
-* Removed obsolete DNS workaround
-* Use the secondary DNS server in more circumstances
-* Limit the number of concurrent port forwards to avoid running out of resources
-* Store the database as a "bare" git repo to avoid corruption problems
+- Fixed `docker.sock` permission issues
+- Don't check for update when the settings panel opens
+- Removed obsolete DNS workaround
+- Use the secondary DNS server in more circumstances
+- Limit the number of concurrent port forwards to avoid running out of resources
+- Store the database as a "bare" git repo to avoid corruption problems
 
 **Known issues**
 
-*  `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker for Mac (`Docker.app`).
+- `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker for Mac (`Docker.app`).
 
 ### Beta 19 Release Notes (2016-07-14 1.12.0-rc4-beta19)
 
 **New**
 
-* Added privacy tab in settings
-* Allow the definition of HTTP proxy overrides in the UI
+- Added privacy tab in settings
+- Allow the definition of HTTP proxy overrides in the UI
 
 **Upgrades**
 
-* Docker 1.12.0 RC4
-* Docker Compose 1.8.0 RC2
-* Docker Machine 0.8.0 RC2
-* Linux kernel 4.4.15
+- Docker 1.12.0 RC4
+- Docker Compose 1.8.0 RC2
+- Docker Machine 0.8.0 RC2
+- Linux kernel 4.4.15
 
 **Bug fixes and minor changes**
 
-* Filesystem sharing permissions can only be configured in the UI (no more `/Mac` in moby)
-* `com.docker.osx.xhyve.hyperkit`: increased max number of fds to 10240
-* Improved Moby syslog facilities
-* Improved file-sharing tab
-* `com.docker.slirp`: included the DNS TCP fallback fix, required when UDP responses are truncated
-* `docker build/events/logs/stats...` won't leak when iterrupted with Ctrl-C
+- Filesystem sharing permissions can only be configured in the UI (no more `/Mac` in moby)
+- `com.docker.osx.xhyve.hyperkit`: increased max number of fds to 10240
+- Improved Moby syslog facilities
+- Improved file-sharing tab
+- `com.docker.slirp`: included the DNS TCP fallback fix, required when UDP responses are truncated
+- `docker build/events/logs/stats...` won't leak when interrupted with Ctrl-C
 
 **Known issues**
 
-* See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
+- See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
 
 ### Beta 18.1 Release Notes (2016-07-07 1.12.0-rc3-beta18.1)
 
@@ -1944,176 +1918,175 @@ events or unexpected unmounts.
 
 **Hotfix**
 
-* Fixed issue resulting in error "Hijack is incompatible with use of CloseNotifier", reverts previous fix for `Ctrl-C` during build.
+- Fixed issue resulting in error "Hijack is incompatible with use of CloseNotifier", reverts previous fix for `Ctrl-C` during build.
 
 **New**
 
-* New host/container file sharing UI
-* `/Mac` bind mount prefix is deprecated and will be removed soon
+- New host/container file sharing UI
+- `/Mac` bind mount prefix is deprecated and will be removed soon
 
 **Upgrades**
 
-* Docker 1.12.0 RC3
+- Docker 1.12.0 RC3
 
 **Bug fixes and minor changes**
 
-* VPNKit: Improved scalability as number of network connections increases
-* The docker API proxy was failing to deal with some 1.12 features, such as health check.
+- VPNKit: Improved scalability as number of network connections increases
+- The docker API proxy was failing to deal with some 1.12 features, such as health check.
 
 **Known issues**
 
-* See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
+- See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
 
 ### Beta 18 Release Notes (2016-07-06 1.12.0-rc3-beta18)
 
 **New**
 
-* New host/container file sharing UI
-* `/Mac` bind mount prefix is deprecated and will be removed soon
+- New host/container file sharing UI
+- `/Mac` bind mount prefix is deprecated and will be removed soon
 
 **Upgrades**
 
-* Docker 1.12.0 RC3
+- Docker 1.12.0 RC3
 
 **Bug fixes and minor changes**
 
-* VPNKit: Improved scalability as number of network connections increases
-* Interrupting a `docker build` with Ctrl-C will actually stop the build
-* The docker API proxy was failing to deal with some 1.12 features, such as health check.
+- VPNKit: Improved scalability as number of network connections increases
+- Interrupting a `docker build` with Ctrl-C will actually stop the build
+- The docker API proxy was failing to deal with some 1.12 features, such as health check.
 
 **Known issues**
 
-* See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
+- See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
 
 ### Beta 17 Release Notes (2016-06-29 1.12.0-rc2-beta17)
 
 **Upgrades**
 
-* Linux kernel 4.4.14, AUFS 20160627
+- Linux kernel 4.4.14, AUFS 20160627
 
 **Bug fixes and minor changes**
 
-* Documentation moved to [/desktop/mac/](../_index.md)
-* Allow non-admin users to launch the app for the first time (using admin creds)
-* Prompt non-admin users for admin password when needed in Preferences
-* Fixed download links, documentation links
-* Fixed "failure: No error" message in diagnostic panel
-* Improved diagnostics for networking and logs for the service port openers
+- Documentation moved to [/desktop/mac/](../_index.md)
+- Allow non-admin users to launch the app for the first time (using admin creds)
+- Prompt non-admin users for admin password when needed in Preferences
+- Fixed download links, documentation links
+- Fixed "failure: No error" message in diagnostic panel
+- Improved diagnostics for networking and logs for the service port openers
 
 **Known issues**
 
-* See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
+- See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
 
 ### Beta 16 Release Notes (2016-06-17 1.12.0-rc2-beta16)
 
 **Upgrades**
 
-* Docker 1.12.0 RC2
-* docker-compose 1.8.0 RC1
-* docker-machine 0.8.0 RC1
-* notary 0.3
-* Alpine 3.4
+- Docker 1.12.0 RC2
+- docker-compose 1.8.0 RC1
+- docker-machine 0.8.0 RC1
+- notary 0.3
+- Alpine 3.4
 
 **Bug fixes and minor changes**
 
-* VPNKit: Fixed a regressed error message when a port is in use
-* Fixed UI crashing with `NSInternalInconsistencyException` / fixed leak
-* HyperKit API: Improved error reporting
-* osxfs: fix sporadic EBADF due to fd access/release races (#3683)
-
+- VPNKit: Fixed a regressed error message when a port is in use
+- Fixed UI crashing with `NSInternalInconsistencyException` / fixed leak
+- HyperKit API: Improved error reporting
+- osxfs: fix sporadic EBADF due to fd access/release races (#3683)
 
 **Known issues**
 
-* See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
+- See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
 
 ### Beta 15 Release Notes (2016-06-10 1.11.2-beta15)
 
 **New**
 
-* Registry mirror and insecure registries can now be configured from Preferences
-* Virtual machine can now be restarted from Preferences
-* `sysctl.conf` can be edited from Preferences
+- Registry mirror and insecure registries can now be configured from Preferences
+- Virtual machine can now be restarted from Preferences
+- `sysctl.conf` can be edited from Preferences
 
 **Upgrades**
 
-* Docker 1.11.2
-* Linux 4.4.12, `aufs` 20160530
+- Docker 1.11.2
+- Linux 4.4.12, `aufs` 20160530
 
 **Bug fixes and minor changes**
 
-* Timekeeping in Moby VM improved
-* Number of concurrent TCP/UDP connections increased in VPNKit
-* Hyperkit: `vsock` stability improvements
-* Fixed crash when user is admin
+- Timekeeping in Moby VM improved
+- Number of concurrent TCP/UDP connections increased in VPNKit
+- Hyperkit: `vsock` stability improvements
+- Fixed crash when user is admin
 
 **Known issues**
 
-* See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
+- See [Known Issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md).
 
 ### Beta 14 Release Notes (2016-06-02 1.11.1-beta14)
 
 **New**
 
-* New settings menu item, **Diagnose & Feedback**, is available to run diagnostics and upload logs to Docker.
+- New settings menu item, **Diagnose & Feedback**, is available to run diagnostics and upload logs to Docker.
 
 **Known issues**
 
-* `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode with macOS 10.10. The issue is being investigated. The workaround is to restart `Docker.app`.
+- `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode with macOS 10.10. The issue is being investigated. The workaround is to restart `Docker.app`.
 
 **Bug fixes and minor changes**
 
-* `osxfs`: now support `statfs`
-* **Preferences**: updated toolbar icons
-* Fall back to secondary DNS server if primary fails.
-* Added a link to the documentation from menu.
+- `osxfs`: now support `statfs`
+- **Preferences**: updated toolbar icons
+- Fall back to secondary DNS server if primary fails.
+- Added a link to the documentation from menu.
 
 ### Beta 13.1 Release Notes (2016-05-28 1.11.1-beta13.1)
 
 **Hotfixes**
 
-* `osxfs`:
+- `osxfs`:
   - Fixed sporadic EBADF errors and End_of_file crashes due to a race corrupting node table invariants
   - Fixed a crash after accessing a sibling of a file moved to another directory caused by a node table invariant violation
-* Fixed issue where Proxy settings were applied on network change, causing docker daemon to restart too often
-* Fixed issue where log file sizes doubled on docker daemon restart
+- Fixed issue where Proxy settings were applied on network change, causing docker daemon to restart too often
+- Fixed issue where log file sizes doubled on docker daemon restart
 
 ### Beta 13 Release Notes (2016-05-25 1.11.1-beta13)
 
 **New**
 
-* `osxfs`: Enabled 10ms dcache for 3x speedup on a `go list ./...` test against docker/machine. Workloads heavy in file system path resolution (common among dynamic languages and build systems) will have those resolutions performed in amortized constant time rather than time linear in the depth of the path so speedups of 2-10x will be common.
+- `osxfs`: Enabled 10ms dcache for 3x speedup on a `go list ./...` test against docker/machine. Workloads heavy in file system path resolution (common among dynamic languages and build systems) will have those resolutions performed in amortized constant time rather than time linear in the depth of the path so speedups of 2-10x will be common.
 
-* Support multiple users on the same machine, non-admin users can use the app as long as `vmnetd` has been installed. Currently, only one user can be logged in at the same time.
+- Support multiple users on the same machine, non-admin users can use the app as long as `vmnetd` has been installed. Currently, only one user can be logged in at the same time.
 
-* Basic support for using system HTTP/HTTPS proxy in docker daemon
+- Basic support for using system HTTP/HTTPS proxy in docker daemon
 
 **Known issues**
 
-* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
+- Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
 
 **Bug fixes and minor changes**
 
-* `osxfs`:
+- `osxfs`:
   - setting `atime` and `mtime` of nodes is now supported
   - Fixed major regression in Beta 12 with ENOENT, ENOTEMPY, and other spurious errors after a directory rename. This manifested as `npm install` failure and other directory traversal issues.
   - Fixed temporary file ENOENT errors
   - Fixed in-place editing file truncation error, such as when running `perl -i`
-* improved time synchronisation after sleep
+- improved time synchronisation after sleep
 
 ### Beta 12 Release (2016-05-17 1.11.1-beta12)
 
 **Upgrades**
 
-* FUSE 7.23 for osxfs
+- FUSE 7.23 for osxfs
 
 **Known issues**
 
-* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
+- Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
 
 **Bug fixes and minor changes**
 
-* UI improvements
-* Fixed a problem in osxfs where`mkdir` returned EBUSY but directory was created.
+- UI improvements
+- Fixed a problem in osxfs where`mkdir` returned EBUSY but directory was created.
 
 ### Beta 11 Release (2016-05-10 1.11.1-beta11)
 
@@ -2123,16 +2096,16 @@ The `osxfs` file system now persists ownership changes in an extended attribute.
 
 **Upgrades**
 
-* docker-compose 1.7.1 (see [changelog](https://github.com/docker/compose/releases/tag/1.7.1))
-* Linux kernel 4.4.9
+- docker-compose 1.7.1 (see [changelog](https://github.com/docker/compose/releases/tag/1.7.1))
+- Linux kernel 4.4.9
 
 **Bug fixes and minor changes**
 
-* Desktop notifications after successful update
-* No "update available" popup during install process
-* Fixed repeated bind of privileged ports
-* `osxfs`: Fixed the block count reported by stat
-* Moby (Backend) fixes:
+- Desktop notifications after successful update
+- No "update available" popup during install process
+- Fixed repeated bind of privileged ports
+- `osxfs`: Fixed the block count reported by stat
+- Moby (Backend) fixes:
   - Fixed `vsock` half closed issue
   - Added NFS support
   - Hostname is now Moby, not Docker
@@ -2143,145 +2116,141 @@ The `osxfs` file system now persists ownership changes in an extended attribute.
 
 **New**
 
-* Token validation is now done over an actual SSL tunnel (HTTPS). (This should fix issues with antivirus applications.)
+- Token validation is now done over an actual SSL tunnel (HTTPS). (This should fix issues with antivirus applications.)
 
 **Upgrades**
 
-* Docker 1.11.1
+- Docker 1.11.1
 
 **Bug fixes and minor changes**
 
-* UCP now starts again
-* Include debugging symbols in HyperKit
-* vsock stability improvements
-* Addressed glitches in **Preferences** panel
-* Fixed issues impacting the “whale menu”
-* Fixed uninstall process
-* HyperKit vcpu state machine improvements, may improve suspend/resume
-
+- UCP now starts again
+- Include debugging symbols in HyperKit
+- vsock stability improvements
+- Addressed glitches in **Preferences** panel
+- Fixed issues impacting the “whale menu”
+- Fixed uninstall process
+- HyperKit vcpu state machine improvements, may improve suspend/resume
 
 ### Beta 9 Release (2016-04-26 1.11.0-beta9)
 
 **New**
 
-* New Preferences window - memory and vCPUs now adjustable
-* `localhost` is now used for port forwarding by default.`docker.local` will no longer work as of Beta 9.
+- New Preferences window - memory and vCPUs now adjustable
+- `localhost` is now used for port forwarding by default.`docker.local` will no longer work as of Beta 9.
 
 **Known issues**
 
-* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
+- Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app.
 
 **Bug fixes and minor changes**
 
-* Fix loopback device naming
-* Improved docker socket download and osxfs sequential write by 20%
-* `com.docker.osxfs`
+- Fix loopback device naming
+- Improved docker socket download and osxfs sequential write by 20%
+- `com.docker.osxfs`
   - improved sequential read throughput by up to 20%
   - improved `readdir` performance by up to 6x
   - log all fatal exceptions
-* More reliable DNS forwarding over UDP and TCP
-* UDP ports can be proxied over vsock
-* Fixed EADDRINUSE (manifesting as errno 526) when ports are re-used
-* Send ICMP when asked to not fragment and we can't guarantee it
-* Fixed parsing of UDP datagrams with IP socket options
-* Drop abnormally large ethernet frames
-* Improved HyperKit logging
-* Record virtual machine start and stop events
+- More reliable DNS forwarding over UDP and TCP
+- UDP ports can be proxied over vsock
+- Fixed EADDRINUSE (manifesting as errno 526) when ports are re-used
+- Send ICMP when asked to not fragment and we can't guarantee it
+- Fixed parsing of UDP datagrams with IP socket options
+- Drop abnormally large ethernet frames
+- Improved HyperKit logging
+- Record virtual machine start and stop events
 
 ### Beta 8 Release (2016-04-20 1.11.0-beta8)
 
 **New**
 
-* Networking mode switched to VPN compatible by default, and as part of this change the overall experience has been improved:
- - `docker.local` now works in VPN compatibility mode
- - exposing ports on the Mac is available in both networking modes
- - port forwarding of privileged ports now works in both networking modes
- - traffic to external DNS servers is no longer dropped in VPN mode
-
+- Networking mode switched to VPN compatible by default, and as part of this change the overall experience has been improved:
 
-* `osxfs` now uses `AF_VSOCK` for transport giving ~1.8x speedup for large sequential read/write workloads but increasing latency by ~1.3x. `osxfs` performance engineering work continues.
+* `docker.local` now works in VPN compatibility mode
+* exposing ports on the Mac is available in both networking modes
+* port forwarding of privileged ports now works in both networking modes
+* traffic to external DNS servers is no longer dropped in VPN mode
 
+- `osxfs` now uses `AF_VSOCK` for transport giving ~1.8x speedup for large sequential read/write workloads but increasing latency by ~1.3x. `osxfs` performance engineering work continues.
 
 **Known issues**
 
-* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart `Docker.app`
+- Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart `Docker.app`
 
 **Bug fixes and minor changes**
 
-* Apple System Log now used for most logs instead of direct filesystem logging
-* `docker_proxy` fixes
-* Merged HyperKit upstream patches
-* Improved error reporting in `nat` network mode
-* `osxfs` `transfused` client now logs over `AF_VSOCK`
-* Fixed a `com.docker.osx.HyperKit.linux` supervisor deadlock if processes exit during a controlled shutdown
-* Fixed VPN mode malformed DNS query bug preventing some resolutions
-
+- Apple System Log now used for most logs instead of direct filesystem logging
+- `docker_proxy` fixes
+- Merged HyperKit upstream patches
+- Improved error reporting in `nat` network mode
+- `osxfs` `transfused` client now logs over `AF_VSOCK`
+- Fixed a `com.docker.osx.HyperKit.linux` supervisor deadlock if processes exit during a controlled shutdown
+- Fixed VPN mode malformed DNS query bug preventing some resolutions
 
 ### Beta 7 Release (2016-04-12 1.11.0-beta7)
 
 **New**
 
-* Docs are updated per the Beta 7 release
-* Use AF_VSOCK for docker socket transport
+- Docs are updated per the Beta 7 release
+- Use AF_VSOCK for docker socket transport
 
 **Upgrades**
 
-* docker 1.11.0-rc5
-* docker-machine 0.7.0-rc3
-* docker-compose 1.7.0rc2
-
+- docker 1.11.0-rc5
+- docker-machine 0.7.0-rc3
+- docker-compose 1.7.0rc2
 
 **Known issues**
 
-* Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
+- Docker.app sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart Docker.app
 
-* If VPN mode is enabled and then disabled and then re-enabled again, `docker ps` will block for 90s
+- If VPN mode is enabled and then disabled and then re-enabled again, `docker ps` will block for 90s
 
 **Bug fixes and minor changes**
 
-* Logging improvements
-* Improve process management
+- Logging improvements
+- Improve process management
 
 ### Beta 6 Release (2016-04-05 1.11.0-beta6)
 
 **New**
 
-* Docs are updated per the Beta 6 release
-* Added uninstall option in user interface
+- Docs are updated per the Beta 6 release
+- Added uninstall option in user interface
 
 **Upgrades**
 
-* docker 1.11.0-rc5
-* docker-machine 0.7.0-rc3
-* docker-compose 1.7.0rc2
+- docker 1.11.0-rc5
+- docker-machine 0.7.0-rc3
+- docker-compose 1.7.0rc2
 
 **Known issues**
 
-* `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode.
-The issue is being investigated. The workaround is to restart
-`Docker.app`.
+- `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode.
+  The issue is being investigated. The workaround is to restart
+  `Docker.app`.
 
-* If VPN mode is enabled, then disabled and re-enabled again,
-`docker ps` will block for 90 seconds.
+- If VPN mode is enabled, then disabled and re-enabled again,
+  `docker ps` will block for 90 seconds.
 
 **Bug fixes and minor changes**
 
-* Fixed osxfs multiple same directory bind mounts stopping inotify
-* Fixed osxfs `setattr` on mode 0 files (`sed` failures)
-* Fixed osxfs blocking all operations during `readdir`
-* Fixed osxfs mishandled errors which crashed the file system and VM
-* Removed outdated `lofs`/`9p` support
-* Added more debugging info to logs uploaded by `pinata diagnose`
-* Improved diagnostics from within the virtual machine
-* VirtualBox version check now also works without VBoxManage in path
-* VPN mode now uses same IP range as NAT mode
-* Tokens are now verified on port 443
-* Removed outdated uninstall scripts
-* Increased default ulimits
-* Port forwarding with `-p` and `-P` should work in VPN mode
-* Fixed a memory leak in `com.docker.db`
-* Fixed a race condition on startup between Docker and networking which can
-lead to `Docker.app` not starting on reboot
+- Fixed osxfs multiple same directory bind mounts stopping inotify
+- Fixed osxfs `setattr` on mode 0 files (`sed` failures)
+- Fixed osxfs blocking all operations during `readdir`
+- Fixed osxfs mishandled errors which crashed the file system and VM
+- Removed outdated `lofs`/`9p` support
+- Added more debugging info to logs uploaded by `pinata diagnose`
+- Improved diagnostics from within the virtual machine
+- VirtualBox version check now also works without VBoxManage in path
+- VPN mode now uses same IP range as NAT mode
+- Tokens are now verified on port 443
+- Removed outdated uninstall scripts
+- Increased default ulimits
+- Port forwarding with `-p` and `-P` should work in VPN mode
+- Fixed a memory leak in `com.docker.db`
+- Fixed a race condition on startup between Docker and networking which can
+  lead to `Docker.app` not starting on reboot
 
 ### Beta 5 Release (2016-03-29 1.10.3-beta5)
 
@@ -2326,8 +2295,8 @@ lead to `Docker.app` not starting on reboot
 - `Docker.app` sometimes uses 200% CPU after macOS wakes up from sleep mode. The issue is being investigated. The workaround is to restart `Docker.app`.
 
 - VPN/Hostnet: In VPN mode, the `-p` option needs to be explicitly of the form
-`-p <host port>:<container port>`. `-p <port>` and `-P` will not
-work yet.
+  `-p <host port>:<container port>`. `-p <port>` and `-P` will not
+  work yet.
 
 **Bug fixes and minor changes**
 
@@ -2343,7 +2312,6 @@ work yet.
 
 - Fixed watchdog crash on startup
 
-
 ### Beta 3 Release (2016-03-15 1.10.3-beta3)
 
 **New Features and Upgrades**
@@ -2364,7 +2332,6 @@ work yet.
   - Fixed osxfs chmod on sockets
   - FixED osxfs EINVAL from `open` using O_NOFOLLOW
 
-
 - Hypervisor stability fixes, resynced with upstream repository
 
 - Hostnet/VPN mode
@@ -2372,7 +2339,6 @@ work yet.
   - Added more verbose logging on errors in `nat` mode
   - Show correct forwarding details in `docker ps/inspect/port` in `nat` mode
 
-
 - New lines ignored in token entry field
 
 - Feedback mail has app version in subject field
@@ -2385,7 +2351,6 @@ work yet.
   - Fix proxy panics on EOF when decoding JSON
   - Fix long delay/crash when switching from `hostnet` to `nat` mode
 
-
 - Logging
   - Moby logs included in diagnose upload
   - App version included in logs on startup
@@ -2398,14 +2363,12 @@ work yet.
   - Added VPN mode/`hostnet` to Preferences
   - Added disable Time Machine backups of VM disk image to Preferences
 
-
 - Added `pinata` configuration tool for experimental Preferences
 
 - File System: Added guest-to-guest FIFO and socket file support
 
 - Upgraded Notary to version 0.2
 
-
 **Bug fixes and minor changes**
 
 - Fixed data corruption bug during cp (use of sendfile/splice)
@@ -2415,7 +2378,6 @@ work yet.
   - Stability fixes and tests
   - Fixed DNS issues when changing networks
 
-
 - Cleaned up Docker startup code related to Moby
 
 - Fixed various problems with linking and dependencies
@@ -2432,7 +2394,6 @@ work yet.
   - Added license agreement
   - Added MixPanel support
 
-
 - Added HockeyApp crash reporting
 - Improve signal handling on task manager
 - Use ISO timestamps with microsecond precision for logging
@@ -2443,17 +2404,13 @@ work yet.
   - docker-uninstall improvements
   - Remove docker-select as it's no longer used
 
-
 - Hypervisor
   - Added PID file
   - Networking reliability improvements
 
-
 - Hostnet
-
   - Fixed port forwarding issue
   - Stability fixes
   - Fixed setting hostname
 
-
 - Fixed permissions on `usr/local` symbolic links
diff --git a/content/manuals/desktop/previous-versions/edge-releases-windows.md b/content/manuals/desktop/previous-versions/edge-releases-windows.md
index ab7f67c78248..1b8997283e07 100644
--- a/content/manuals/desktop/previous-versions/edge-releases-windows.md
+++ b/content/manuals/desktop/previous-versions/edge-releases-windows.md
@@ -4,8 +4,6 @@ keywords: Docker Desktop for Windows, edge, release notes
 title: Docker Desktop for Windows Edge Release notes
 toc_min: 1
 toc_max: 2
-aliases:
-- /desktop/windows/release-notes/edge-releases/
 sitemap: false
 ---
 
@@ -144,8 +142,8 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 
 ### Known issues
 
-- The `clock_gettime64` system call returns `EPERM` rather than `ENOSYS` 
-in i386 images. To work around this issue, disable `seccomp` by using 
+- The `clock_gettime64` system call returns `EPERM` rather than `ENOSYS`
+in i386 images. To work around this issue, disable `seccomp` by using
 the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for-win/issues/8326).
 
 ## Docker Desktop Community 2.3.6.2
@@ -710,7 +708,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 - Docker Desktop now supports a configurable user timeout for VMs on slower machines. [docker/for-win#4393](https://github.com/docker/for-win/issues/4393)
 - Enabled Windows features such as Hyper-V and Containers during installation, thereby reducing the need for another restart after installation.
 
-## Docker Desktop Community 2.1.0.0 
+## Docker Desktop Community 2.1.0.0
 2019-07-30
 
 
@@ -728,14 +726,14 @@ This release contains Kubernetes security improvements. Note that your local Kub
 #### New
 
  - Introduced a new user interface for the Docker Desktop **Settings** menu.
- - The **Restart** and **Reset** options are now available on the **Troubleshoot** menu. 
+ - The **Restart** and **Reset** options are now available on the **Troubleshoot** menu.
 
 #### Bug fixes and minor changes
 
  - Changed the host's kubernetes context to ensure `docker run -v .kube:kube ... kubectl` works.
  - Restricted the `cluster-admin` role on local Kubernetes cluster to `kube-system` namespace.
  - Fixed Kubernetes installation with VPNkit subnet.
- - Fixed an issue where Docker Desktop restarts when a user logs out of Windows and logs back in, which results in retaining the    
+ - Fixed an issue where Docker Desktop restarts when a user logs out of Windows and logs back in, which results in retaining the
    exported ports on containers.
  - Reduced the VM startup time. `swap` is not created every time a virtual machine boots.
  - Fixed a bug which caused Docker Desktop to crash when a user cancels switching the version using Windows User Account Control (UAC)    settings.
@@ -795,16 +793,16 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 * New
 
   - App: Docker CLI plugin to configure, share, and install applications
-  
+
     - Extend Compose files with metadata and parameters
     - Reuse the same application across multiple environments (Development/QA/Staging/Production)
     - Multi-orchestrator installation (Swarm or Kubernetes)
     - Push/Pull/Promotion/Signing supported for application, with the same workflow as images
     - Fully CNAB compliant
     - Full support for Docker Contexts
-    
+
   - Buildx (Tech Preview): Docker CLI plugin for extended build capabilities with BuildKit
-  
+
     - Familiar UI from docker build
     - Full BuildKit capabilities with container driver
     - Multiple builder instance support
@@ -847,7 +845,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 
 * New
   - Rebranded UI
-  
+
 * Bug fixes and minor changes
   - Kubernetes: use default maximum number of pods for kubelet. [docker/for-mac#3453](https://github.com/docker/for-mac/issues/3453)
 
@@ -860,7 +858,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
   - [Kubernetes 1.13.0](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md#v1130)
   - [Kitematic 0.17.6](https://github.com/docker/kitematic/releases/tag/v0.17.6)
   - Golang 1.10.6, fixes CVEs: [CVE-2018-16875](https://www.cvedetails.com/cve/CVE-2018-16875), [CVE-2018-16873](https://www.cvedetails.com/cve/CVE-2018-16873) and [CVE-2018-16874](https://www.cvedetails.com/cve/CVE-2018-16874)
-  
+
   WARNING: If you have an existing Kubernetes cluster created with Docker Desktop, this upgrade will reset the cluster. If you need to back up your Kubernetes cluster or persistent volumes you can use [Ark](https://github.com/heptio/ark).
 
 * Bug fixes and minor changes
@@ -880,7 +878,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
   - [Docker compose 1.23.2](https://github.com/docker/compose/releases/tag/1.23.2)
 
 * Bug fixes and minor changes
-  - Compose: Fixed a bug where build context URLs would fail to build on Windows. Fixes [docker/for-win#2918](https://github.com/docker/for-win/issues/2918) 
+  - Compose: Fixed a bug where build context URLs would fail to build on Windows. Fixes [docker/for-win#2918](https://github.com/docker/for-win/issues/2918)
 
 ### Docker Community Edition 2.0.0.0-win77 2018-11-14
 
@@ -891,7 +889,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
   - [Kitematic 0.17.5](https://github.com/docker/kitematic/releases/tag/v0.17.5)
 
 * Bug fixes and minor changes
-  - Windows Containers: Fix group daemon option settings. Fixes [docker/for-win#2647](https://github.com/docker/for-win/issues/2647) 
+  - Windows Containers: Fix group daemon option settings. Fixes [docker/for-win#2647](https://github.com/docker/for-win/issues/2647)
   - Windows Containers: Improve host.docker.internal ip resolution
   - Do not try to update samba share mounts when using Windows containers
   - Improved dns update too verbose in logs
@@ -909,7 +907,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
 
 * Deprecation
   - Removed support of AUFS
-  
+
 * Bug fixes and minor changes
   - LCOW does not anymore need --platform flag on multi-arch images
   - Better WCOW host.docker.internal resolution on host, don't rewrite it if not modified. From [docker/for-win#1976](https://github.com/docker/for-win/issues/1976)
@@ -977,13 +975,13 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
   - [Docker 18.05.0-ce](https://github.com/docker/docker-ce/releases/tag/v18.05.0-ce)
   - [Docker compose 1.21.2](https://github.com/docker/compose/releases/tag/1.21.2)
 
-* New 
+* New
   - Allow orchestrator selection from the UI in the "Kubernetes" pane, to allow "docker stack" commands to deploy to swarm clusters, even if Kubernetes is enabled in Docker for Windows.
 
 * Bug fixes and minor changes
   - Fix restart issue when using Windows fast startup on latest 1709 Windows updates. Fixes [docker/for-win#1741](https://github.com/docker/for-win/issues/1741), [docker/for-win#1741](https://github.com/docker/for-win/issues/1741)
   - DNS name `host.docker.internal` can be used for host resolution from Windows containers.  Fixes [docker/for-win#1976](https://github.com/docker/for-win/issues/1976)
-  - Fix broken link in diagnostics window. 
+  - Fix broken link in diagnostics window.
 
 ### Docker Community Edition 18.05.0-ce-rc1-win63 2018-04-26
 
@@ -995,7 +993,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
   - Fix startup issue due to incompatibility with other programs (like Razer Synapse 3). Fixes [docker/for-win#1723](https://github.com/docker/for-win/issues/1723)
   - Fix Kubernetes hostPath translation for PersistentVolumeClaim (PVC). Previously failing PVCs must be deleted and recreated. Fixes [docker/for-win#1758](https://github.com/docker/for-win/issues/1758)
   - Fix Kubernetes status when resetting to factory defaults.
-  
+
 
 ### Docker Community Edition 18.04.0-ce-win62 2018-04-12
 
@@ -1009,7 +1007,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
   - [Docker 18.04.0-ce-rc2](https://github.com/docker/docker-ce/releases/tag/v18.04.0-ce-rc2)
   - [Kubernetes 1.9.6](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md#v196). If Kubernetes is enabled, the upgrade will be performed automatically when starting Docker for Windows.
 
-* New 
+* New
   - Enable ceph & rbd modules in LinuxKit VM.
 
 * Bug fixes and minor changes
@@ -1094,7 +1092,7 @@ This release contains a Kubernetes upgrade. Note that your local Kubernetes clus
   - [Docker 18.02.0-ce-rc1](https://github.com/docker/docker-ce/releases/tag/v18.02.0-ce-rc1)
 
 * New
-  - Experimental Kubernetes Support. You can now run a single-node Kubernetes cluster from the "Kubernetes" Pane in Docker for Windows settings and use kubectl commands as well as docker commands. See [the Kubernetes section](/manuals/desktop/features/kubernetes.md).
+  - Experimental Kubernetes Support. You can now run a single-node Kubernetes cluster from the "Kubernetes" Pane in Docker for Windows settings and use kubectl commands as well as docker commands. See [the Kubernetes section](/manuals/desktop/use-desktop/kubernetes.md).
   - LCOW containers can now be run next to Windows containers (on Windows RS3 build 16299 and later). Use `--platform=linux` in Windows container mode to run Linux Containers On Windows. Note that LCOW is still experimental, and requires daemon `experimental` option.
 
 * Bug fixes and minor changes
@@ -2561,7 +2559,7 @@ are working on a solution.
   - Improve layout of About and Settings dialog
   - Improve Updater
   - Link to *Help*
-  - Link to *Send Feeback*
+  - Link to *Send Feedback*
 
 **General**
 
diff --git a/content/manuals/desktop/release-notes.md b/content/manuals/desktop/release-notes.md
index 6e6df443d5c9..7260ad82eb1b 100644
--- a/content/manuals/desktop/release-notes.md
+++ b/content/manuals/desktop/release-notes.md
@@ -6,18 +6,17 @@ linkTitle: Release notes
 tags: [Release notes]
 toc_max: 2
 aliases:
-- /docker-for-mac/release-notes/
 - /docker-for-mac/edge-release-notes/
 - /desktop/mac/release-notes/
 - /docker-for-windows/edge-release-notes/
-- /docker-for-windows/release-notes/
 - /desktop/windows/release-notes/
 - /desktop/linux/release-notes/
 - /mackit/release-notes/
 weight: 220
 ---
+<!-- vale off -->
 
-This page contains information about the new features, improvements, known issues, and bug fixes in Docker Desktop releases. 
+This page contains information about the new features, improvements, known issues, and bug fixes in Docker Desktop releases.
 
 Releases are gradually rolled out to ensure quality control. If the latest version is not yet available to you, allow some time — updates typically become available within a week of the release date.
 
@@ -25,16 +24,1981 @@ Docker Desktop versions older than 6 months from the latest release are not avai
 
 For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoot-and-support/faqs/releases.md).
 
-> [!WARNING]
+## 4.88.1
+
+{{< release-date date="2026-08-25" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.88.1" build_path="/237512/" >}}
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue where opening the Dashboard would incorrectly redirect unauthenticated users to the sign-in prompt page.
+
+## 4.88.0
+
+{{< release-date date="2026-08-24" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.88.0" build_path="/237115/" >}}
+
+### Updates
+
+- [Docker Agent v1.124.0](https://github.com/docker/docker-agent/releases/tag/v1.124.0)
+- Docker Offload `v0.6.13`
+- [Docker Model Runner v1.2.8](https://github.com/docker/model-cli/releases/tag/v1.2.8)
+- [containerd v2.3.3](https://github.com/containerd/containerd/releases/tag/v2.3.3)
+- [Runc v1.4.3](https://github.com/opencontainers/runc/releases/tag/v1.4.3)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue where Docker Desktop reported `enable fsverity failed: operation not supported` as the crash cause instead of the real underlying error.
+- Fixed a bug where changing the hypervisor type in **Settings** had no effect when Docker Desktop was in Resource saver mode.
+- Fixed port bindings reported by `docker ps` to accurately reflect active listeners when using 'Localhost by default' or 'Localhost only' settings, and added `[::1]` loopback listener alongside `127.0.0.1`.
+- Fixed an HTTP 500 error that could occur during Docker Desktop startup or wake from idle-shutdown when the engine socket existed but was not yet listening.
+- Fixed a bug where Docker Desktop would fail to start if `~/.docker/daemon.json` was corrupted with null bytes (typically caused by a crash or power-loss during a settings save). Docker Desktop now automatically recovers to default daemon settings.
+- Fixed an issue in the Docker Engine config editor in settings where validation error messages would disappear immediately while typing invalid JSON.
+- Fixed a Docker VMM regression that reduced container inbound network throughput to roughly 0.3 GB per second.
+- Fixed error messages shown when the Docker Desktop VM exits unexpectedly to include the exit status code and surface the actual root cause of the crash.
+
+#### For Mac
+
+- Docker VMM can now use more than 28GiB of host memory.
+
+#### For Windows
+
+- Fixed a Windows auto-update failure when a self-updated CLI plugin (e.g `docker scout` or `docker agent`) newer than the bundled version was already present in the user's CLI-plugins folder.
+- Fixed an issue on per-user Windows installs where Hyper-V, Windows containers, and related settings are now correctly disabled and grayed out, preventing broken behavior caused by the unavailable priveleged helper service.
+
+## 4.87.0
+
+{{< release-date date="2026-08-17" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.87.0" build_path="/236836/" >}}
+
+### Updates
+
+- [Docker Agent v1.122.0](https://github.com/docker/docker-agent/releases/tag/v1.122.0)
+- [Docker Buildx v0.36.1](https://github.com/docker/buildx/releases/tag/v0.36.1)
+- Docker Offload `v0.6.10`
+- [Docker Compose v5.4.0](https://github.com/docker/compose/releases/tag/v5.4.0)
+- Linux kernel `v7.0.12`
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed a bug where the in-app update failed with `Source and destination path must have identical roots` when Docker Desktop was installed to a custom directory on another drive.
+- Fixed a misleading proxy error that named the destination server instead of the unreachable upstream proxy, and included machine-wide proxy configuration in diagnostics.
+- Fixed a bug where updating could keep failing with a `file exists` error after an earlier update had failed.
+- Fixed an issue where Gordon would lose access to tools and show misleading sign-in prompts after a failed auto-login at startup, without requiring a restart of Docker Desktop.
+
+#### For Mac
+
+- Fixed a false `Docker Desktop encountered an unexpected error` dialog that could appear during VM shutdown on with the `libkrun` engine.
+- Fixed a rare crash where the Docker Desktop with the Apple Virtualization Framework VM stopped unexpectedly right after a new connection was opened.
+
+#### For Windows
+
+- Fixed WSL error recovery on Windows not displaying specific, actionable error messages for errors like `HCS/0x80070569`, showing the generic fallback instead.
+- Fixed an issue on Windows where per-user `.EXE` installs applying an auto-update wrote `install-settings.json` to the system-wide path instead of the correct per-user location.
+- Fixed an issue on Windows where diagnostic bundles were missing network connection profile data due to an empty `Get-NetConnectionProfile.json` file.
+- Fixed a bug on Windows where Docker Desktop repeatedly asked users to run `wsl --update` when WSL was installed via the Microsoft Store rather than the inbox optional component.
+- Fixed an issue where the Resource Saver settings section was incorrectly shown when using Windows containers instead of Linux containers.
+- Fixed an issue on Windows where the disk image usage limit was hidden in **Resources** settings when Hyper-V was selected as the hypervisor.
+- Fixed an issue on Windows where installer logs from per-user installations were missing from diagnostic bundles.
+- Fixed the virtual disk limit not being applied when lowered on Windows with Hyper-V.
+- Fixed the disk usage limit slider being hidden and ignored for the Docker VMM backend on Windows, so users can now set and enforce disk size in **Settings** > **Resources** > **Advanced**.
+- Fixed a Windows auto-update failure when a self-updated CLI plugin (`docker scout` or `docker agent`) newer than the bundled version was already present in the user's CLI-plugins folder.
+
+## 4.86.0
+
+{{< release-date date="2026-08-10" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.86.0" build_path="/236216/" >}}
+
+### Updates
+
+- [Docker Engine v29.7.2](https://docs.docker.com/engine/release-notes/29/#2972)
+- [Docker Buildx v0.36.0](https://github.com/docker/buildx/releases/tag/v0.36.0)
+- [Docker Scout CLI v1.24.0](https://github.com/docker/scout-cli/releases/tag/v1.24.0)
+- [Docker Agent v1.119.0](https://github.com/docker/docker-agent/releases/tag/v1.119.0)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Docker VMM Beta performance improvements by Docker’s own container-optimized hypervisor. Available for Mac and Windows.
+- Gordon now displays specific error messages for tool failures, policy-blocked actions, and loop detection instead of a generic **Agent error**.
+- Fixed container stop timeouts and `unless-stopped` restart policies not being honored during engine shutdown.
+- Fixed a bug where enabling Docker Offload from the Docker Desktop Dashboard failed when the proxy was configured by the operating system instead of by environment variables.
+- Fixed a crash on startup after upgrading, for users whose settings file was written by a very old version.
+- Fixed port forwarding for Swarm services that use automatically assigned published ports, including host-mode task ports and repeated ingress port definitions.
+- Added a three-mode safety system (Strict, Balanced, Autonomous) to the Gordon AI agent's tool confirmation UI, replacing the previous binary approve/allow-all dialog, with risk-tier labels on confirmation.
+- Fixed a flash of incorrect UI content on app launch, such as a brief 'Waiting for the Docker Engine...' screen or unexpected navigation away from gated pages.
+- AF_UNIX sockets shared over VirtioFS now work in both directions (host to guest and guest to host).
+- Fixed a bug where restarting the VM would steal the window focus.
+
+#### For Mac
+
+- Fixed a bug where a Kubernetes (kind) cluster with Enhanced Container Isolation could fail to recover after a Docker Desktop restart.
+- Fixed nftables `fib` expressions failing with "Operation not supported" in `inet` tables on Apple Silicon.
+
+#### For Windows
+
+- Fixed an issue where the Windows installer reported success when it could not write its settings or enterprise policy files.
+- Fixed Model Runner failing to start with `CreateJobObject: Access is denied` when Docker Desktop is launched via a Secondary Logon (run-as-user) session.
+- Updated the bundled 7-Zip to 26.02 to avoid antivirus software quarantining it during an upgrade on Windows.
+
+#### For Linux
+
+- Fixed Docker Desktop failing to start on Linux arm64 hosts due to incorrect QEMU binary path resolution.
+
+### Security
+
+- Addressed CVE-2026-17106, a destination-escape flaw in `docker container cp`.
+
+## 4.85.0
+
+{{< release-date date="2026-08-03" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.85.0" build_path="/235549/" >}}
+
+### Updates
+
+- [Docker AI Agent v1.115.0](https://github.com/docker/docker-agent/releases/tag/v1.115.0)
+
+### Bug fixes and enhancements
+
+#### For all platforms 
+
+- Fixed an issue where native crash reports were uploaded to Bugsnag even when analytics was disabled by the user.
+- Fixed an issue where file content previews and diffs were hidden in the Gordon confirmation card when approving write or edit file actions.
+- Fixed an issue where an invalid `install-settings.json` caused a ~7-minute startup delay before showing the error dialog. The error now appears immediately.
+- Fixed an issue where Gordon's plan mode would silently revert to build mode after the first message, causing subsequent turns to run with full tool access despite plan mode appearing active.
+- Fixed an issue where an invalid `config.json` at startup would delay the error dialog by up to 7 minutes instead of appearing within seconds.
+- Fixed a Linux VM kernel panic that could hang Docker Desktop when a container's file watcher (inotify/fanotify) observed host-side changes to files on a bind mount.
+- Fixed Docker Hardened Images CLI ampersands being encoded when outputting JSON to the console.
+- Fixed a bug where extensions-related requests would fail on startup due to the extensions selector incorrectly defaulting to enabled before settings were loaded.
+- Fixed an issue where sub-agent message attribution was lost when reloading a historical multi-agent Gordon session, causing sub-agent messages to appear as if produced by the main agent.
+- Fixed Gordon's **Clean up Docker** suggestion prompt to propose a cleanup plan and wait for user confirmation before removing any resources, preventing unintended deletions.
+- Fixed the Gordon AI plan-mode toggle visibility to accurately reflect backend support, showing only when the connected agent declares plan capability.
+
+#### For Windows
+
+- Fixed a bug where per-user uninstalls of Docker Desktop on Windows failed with an unauthorized access error when attempting to revert the hosts file.
+- Added per-user install mode as the default for fresh Docker Desktop installations from the Microsoft Store on Windows, removing the need for admin privileges.
+- Fixed an issue where Docker Desktop crashed when the `docker-users` group is missing, now showing a recoverable group membership dialog instead.
+
+#### For Linux
+
+- Removing files on a host bind mount inside an Enhanced Container Isolation container no longer fails with "Value too large for data type".
+
+## 4.84.0
+
+{{< release-date date="2026-07-27" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.84.0" build_path="/234817/" >}}
+
+
+### Updates
+
+- [Docker Agent v1.111.0](https://github.com/docker/docker-agent/releases/tag/v1.111.0)
+- Kubernetes:
+  - cri-dockerd v0.4.4
+- [Docker Hardened Images CLI (`dhictl`) v0.0.7](https://github.com/docker-hardened-images/dhictl/releases/tag/v0.0.7)
+- Docker Desktop CLI `v0.4.3`
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed a bug where an invalid `~/.docker/config.json` caused Docker Desktop to hang with high CPU/memory and show no error dialog. Docker Desktop now surfaces an error dialog prompting the user to correct the file.
+- Fixed a bug that prevented some Docker Hardened Images customizations from being created.
+- Fixed a bug where deleting an unrelated credential ID could accidentally erase Docker Hub OAuth tokens, causing users to be unexpectedly signed out.
+- Removed Docker Scout CLI hints that previously appeared after running `docker pull` or `docker buildx build` commands.
+
+#### For Windows
+
+- Fixed a bug on Windows where an empty or malformed `install-settings.json` caused Docker Desktop to hang with high CPU/memory usage and no error dialog on startup.
+- The MSI installer now detects per-user Docker Desktop installations on the machine and blocks installation with a clear message naming the affected users. Affected users must uninstall their per-user Docker Desktop before the MSI can be installed.
+- Fixed a bug where uninstalling Docker Desktop could permanently lock the user out of their own application data directories if the deletion failed mid-way.
+
+## 4.83.0
+
+{{< release-date date="2026-07-20" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.83.0" build_path="/234302/" >}}
+
+### Updates
+
+- Docker Desktop CLI `v0.4.2`
+- [Docker Model Runner v1.2.6](https://github.com/docker/model-runner/releases/tag/v1.2.6)
+- Docker Offload `v0.6.9`
+- [Docker Agent v1.103.0](https://github.com/docker/docker-agent/releases/tag/v1.103.0)
+- [Docker Compose v5.3.1](https://github.com/docker/compose/releases/tag/v5.3.1)
+- Docker Desktop Build `v0.36.0`
+- [Docker Engine v29.6.2](https://docs.docker.com/engine/release-notes/29/#2962)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Added support for migrating a per-machine Docker Desktop installation to a per-user installation in-place via `install --user` on Windows, preserving user data without requiring a manual uninstall.
+- Fixed `kubectl exec` and `kubectl attach` functionality for v1.36.
+- Fixed Docker Engine startup failures being reported as a generic `io: read/write on closed pipe` error instead of the underlying cause.
+- Fixed the **Images** view showing **0 Bytes** reclaimable size for a while when many images are present.
+- Fixed the volumes list not correctly sorting by size.
+- Fixed an issue where a GPU process crash prevented the Docker Desktop Dashboard from loading by automatically disabling hardware acceleration and restarting the app.
+- Fixed an issue where `docker ai` sessions launched directly from a terminal were killed when Docker Desktop was restarted.
+- Fixed an issue where a malformed `daemon.json` would be silently overwritten with defaults on startup, causing users to lose their custom daemon configuration.
+- Added a **Custom rules** tab to Gordon's permissions dialog. Users can now add allow/deny rules for specific commands or MCP tools.
+- Added pulsing discovery badges to Gordon's **Plan mode** button, model selector, and **Feedback/Issues** button to help users find new features. 
+
+#### For Mac
+
+- Fixed an issue where a stale `com.docker.virtualization` process could prevent Docker Desktop from starting a new VM with a `VZErrorInvalidVirtualMachineConfiguration` error.
+
+#### For Windows
+
+- Fixed an issue where a failed delta update would leave users stranded on an old version by automatically falling back to the full installer.
+- Fixed the Windows MSI installer reporting success when the component installation step actually failed.
+- Fixed an issue where the Windows installer wizard froze while enabling Windows features via DISM during Docker Desktop installation.
+- Fixed a UI thread deadlock in the Windows installer that caused a blank or hung window when prerequisite services were registered but not running during admin installs.
+- Fixed the Windows installer silently reporting success when it could not install the Docker CLI plugins.
+- Fixed the Windows installer deleting a previously installed CLI plugin when re-linking it failed.
+- Fixed a bug where registry policy download failures were silently ignored, so users now see proper error reporting when the admin helper exits with a non-zero code.
+- Changed the Windows installer to select a per-user installation by default.
+- Fixed a WSL integration issue on WSL 2.6.x and later where Docker Desktop failed to work in user distros due to a 0-byte proxy binary, causing **Permission denied** or **Exec format error**.
+- Fixed the Docker CLI in integrated WSL distributions breaking after Resource Saver stopped the VM. The VM now stays running while a WSL integration is active and wakes when one is enabled. Fixes [docker/desktop-feedback#522](https://github.com/docker/desktop-feedback/issues/522).
+
+## 4.82.0
+
+{{< release-date date="2026-07-13" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.82.0" build_path="/233772/" >}}
+
+### Updates
+
+- [Docker Compose v5.3.0](https://github.com/docker/compose/releases/tag/v5.3.0)
+- [Docker Agent v1.98.0](https://github.com/docker/docker-agent/releases/tag/v1.98.0)
+- [Docker Scout CLI v1.23.1](https://github.com/docker/scout-cli/releases/tag/v1.23.1)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Added thumbs up and thumbs down feedback buttons to Gordon responses. Users can rate replies or report issues directly from the chat.
+- Fixed a bug where containers created by Docker Desktop had their stop timeout set to 1 second instead of the Docker Engine default, causing `docker stop` to terminate processes too quickly.
+- Fixed reset to factory defaults not clearing MCP Toolkit profiles, catalogs, and authorizations.
+- Fixed an issue where selected thumbs up/down feedback buttons in Gordon were visually indistinguishable after selecting.
+- Fixed reset to factory defaults not clearing downloaded LLM models.
+- Fixed a bug where the Gordon chat area would go blank when the agent requested free-text input via elicitation.
+- Fixed a delay in the Kubernetes screen where the progress UI did not appear immediately after confirming cluster creation or deletion.
+- Fixed a bug where a Kubernetes kind cluster failed to start with a **Failed to get API server port** error after a Docker Desktop restart.
+- With `docker pass`, the `ls` command now behaves consistently across all platforms.
+- Fixed an issue where users signed out due to sign-in enforcement policies were shown a generic sign-in prompt instead of a clear explanation of why they were signed out.
+
+#### For Mac
+
+- Fixed an issue where Docker Desktop child processes could linger after an unexpected backend exit.
+- Fixed an issue where Docker Desktop failed to start for users with long home directory paths that caused Unix socket paths to exceed OS length limits.
+- Fixed an issue where vsock listener failures showed a cryptic crash instead of a clear, actionable recovery dialog.
+
+#### For Windows
+
+- Fixed an issue where `.log` files were missing from diagnostic bundles, ensuring the Docker Desktop service log is now included.
+- Lowered the priority of Docker Desktop's background processes and enabled Windows Efficiency Mode while idle to reduce power and CPU usage.
+- Fixed factory reset leaving containers and images behind on Hyper-V when Docker Desktop is run by a user other than the one that installed it.
+- Fixed a multi-minute hang during WSL engine startup when the wsl-bootstrap process fails unexpectedly, surfacing the error promptly instead.
+- Fixed an issue where auto-updates could leave Docker Desktop stuck in a 'connecting' state due to a successful installation being incorrectly rolled back.
+- Fixed an issue where vsock listener failures on Windows Hyper-V showed a cryptic crash instead of a clear, actionable recovery dialog.
+- Fixed a race condition where connecting to `com.docker.service` immediately after startup could result in a **File not found** error.
+- Fixed an issue where a graphical installer window would flash during background auto-updates. Updates now run silently.
+- Improved security by verifying the Authenticode signature of the downloaded installer before executing it during updates.
+- Fixed an issue where missing or disabled Windows feature descriptions were not shown in diagnostic output.
+- Improved the installer progress screen with a single continuous progress bar that smoothly advances from 0% to 100% throughout the entire installation.
+- Fixed an issue where `~` in bind mount paths was not correctly resolved to the home directory when the `HOME` environment variable was not set.
+
+#### For Linux
+
+- Fixed an issue where Docker Desktop failed to start for users with long home directory paths that caused Unix socket paths to exceed OS length limits.
+
+## 4.81.0
+
+{{< release-date date="2026-07-06" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.81.0" build_path="/232925/" >}}
+
+### Updates
+
+- [Docker Model Runner v1.2.5](https://github.com/docker/model-runner/releases/tag/v1.2.5)
+- [Docker Agent v1.88.1](https://github.com/docker/docker-agent/releases/tag/v1.88.1)
+- Docker Offload `v0.6.7`
+- [Docker Compose v5.2.0](https://github.com/docker/compose/releases/tag/v5.2.0)
+- [Docker Scout CLI v1.22.0](https://github.com/docker/scout-cli/releases/tag/v1.22.0)
+- [DHI CLI (`dhictl`) v0.0.5](https://github.com/docker-hardened-images/dhictl/releases/tag/v0.0.5)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an error that caused volumes, images, and containers to fail to load in the Docker Desktop Dashboard.
+- Removed the deprecated `cagent` binary from Docker Desktop; use `docker agent` instead.
+- Kubernetes kind cluster now works with Registry Access Management.
+- Fixed a bug where the sign-in/update prompt was not shown when upgrading between versions that cross a version digit boundary (e.g., 4.9.x to 4.10.x).
+- Fixed an issue in Ask Gordon where the tool call permission dialog blocked the chat view, replacing it with an inline approval card so users can read Gordon's full message before approving or rejecting.
+- Fixed a rare case where Docker Desktop could shut down if the build service crashed, for example during a factory reset.
+- Fixed an issue where containers ignored user-configured stop timeouts during normal operation due to a proxy-level override forcing a 1-second timeout on all containers.
+
+#### For Mac
+
+- Fixed Docker Desktop failing to start when the user's environment contained very long environment variables.
+- Fixed a Docker Offload crash on Intel machines due to `SG_READ_ONLY` not being set in the `__DATA_CONST` segment, causing the system linker to fail to load the executable. Fixes [docker/desktop-feedback#471](https://github.com/docker/desktop-feedback/issues/471).
+
+#### For Windows
+
+- Fixed an issue on Windows where stopping Docker Desktop would immediately force off the Hyper-V VM without waiting for a graceful guest shutdown, reducing the risk of data corruption.
+- Fixed a bug on Windows where `dockerd` failed to connect through the local HTTPS proxy due to a TLS handshake error caused by an incorrect proxy URL scheme.
+- Fixed a Windows update that reverted and showed a **Mismatch patch version** error when it ran again after the target version was already installed.
+- Fixed Resource Saver not stopping the Docker engine when running on WSL.
+- Fixed a regression where Docker Desktop failed to start on WSL2 kernels that could not attach the Synchronized File Shares eBPF probes, such as Windows on Arm. Fixes [docker/desktop-feedback#470](https://github.com/docker/desktop-feedback/issues/470).
+
+#### For Linux
+
+- Fixed a bug where Docker Desktop would fail to start after a reset.
+
+## 4.80.0
+
+{{< release-date date="2026-06-29" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.80.0" build_path="/232116/" >}}
+
+### Updates
+
+- Docker Offload `v0.6.6`
+- [Docker Buildx v0.35.0](https://github.com/docker/buildx/releases/tag/v0.35.0)
+- [Docker Model Runner v1.2.4](https://github.com/docker/model-runner/releases/tag/v1.2.4)
+- [containerd v2.2.5](https://github.com/containerd/containerd/releases/tag/v2.2.5)
+- [Docker Engine v29.6.1](https://docs.docker.com/engine/release-notes/29/#2961)
+- [Runc v1.3.6](https://github.com/opencontainers/runc/releases/tag/v1.3.6)
+- Kubernetes v1.36.1
+   - CNI plugins v1.9.1
+   - cri-tools v1.35.0
+   - cri-dockerd v0.3.25
+- Updated Kubernetes images:
+   - Kubeadm:
+      - `docker/desktop-storage-provisioner:v4.0`
+      - `docker/desktop-vpnkit-controller:v4.0`
+      - `docker/desktop-kubernetes-etcd:3.6.8-0`
+      - `docker/desktop-kubernetes-coredns:v1.14.2`
+      - `docker/desktop-kubernetes-pause:3.10.2`
+      - `docker/desktop-kubernetes-apiserver:v1.36.1`
+      - `docker/desktop-kubernetes-controller-manager:v1.36.1`
+      - `docker/desktop-kubernetes-scheduler:v1.36.1`
+      - `docker/desktop-kubernetes-proxy:v1.36.1`
+   - Kind:
+      - `docker/desktop-containerd-registry-mirror:v0.0.4`
+      - `docker/desktop-cloud-provider-kind:v0.6.0`
+      - `envoyproxy/envoy:v1.36.7`
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- The experimental `docker sandbox` plugin has been removed. Migrate to [`docker sbx`](/manuals/ai/sandboxes/_index.md).
+- Fixed an issue where running out of disk space showed a generic error dialog instead of a clear **Disk full** message prompting users to free up space and restart.
+- Fixed an issue where using `docker -c desktop-linux` while a cloud context was active would silently route commands to the cloud engine instead of the local desktop Linux engine.
+- Fixed a bug where the backend would incorrectly report a stopped VM as running after an idle shutdown, especially when Enhanced Container Isolation was enabled.
+- Fixed an OS update notification timing issue where users with auto-download enabled were notified when an update was available rather than when it was ready to install.
+
+#### For Mac
+
+- Removed the legacy osxfs file sharing. Users still on osxfs are migrated to VirtioFS.
+- Increased VirtioFS filesharing performance by not persisting (fake) file ownership changes on the host. Calls to `chown` will succeed, but `stat` will not be affected.
+
+#### For Windows
+
+- Fixed an issue where the Windows installer failed when the destination directory contained leftover files from a previous interrupted installation.
+- Fixed an issue on Windows where upgrading Docker Desktop would unnecessarily shut down and unregister unrelated WSL distros via `wsl --shutdown`.
+- Fixed spurious Hyper-V job failures on Windows where operations briefly transitioning through suspended or shutting down states were incorrectly reported as failed.
+- Fixed an issue where the WSL engine failed to start with a **Permission denied** error on machines where the cross-distro WSL mount was configured as `noexec`.
+- Fixed an issue on Windows where end users could override the `NO_PROXY` exclusion list even when an admin had locked the proxy configuration.
+- Fixed an issue on Windows where Docker Desktop would silently disappear on startup failure. An error dialog is now displayed instead.
+- Fixed an issue on Windows where Docker Desktop showed a generic engine-start failure instead of routing to the WSL update recovery when an older wsl.exe did not support the --version flag.
+
+## 4.79.0
+
+{{< release-date date="2026-06-22" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.79.0" build_path="/230596/" >}}
+
+### Updates
+
+- [Docker Agent v1.79.0](https://github.com/docker/docker-agent/releases/tag/v1.79.0)
+- `docker pass` v0.1.5
+- Docker Desktop CLI v0.4.1
+- Docker Offload v0.6.4 
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Gordon improvements:
+   - Added context-aware suggested questions to the Ask Gordon menu in the **Containers**, **Images**, **Volumes**, and **Builds** tabs, surfacing relevant diagnostics first when items are in a problematic state.
+   - Added a **Give feedback** link to Gordon so you can report issues with a redacted conversation preview or share product feedback.
+   - Fixed a React warning in Gordon's sidebar search input that appeared on the first keystroke when typing a search query.
+- Fixed an issue where the Docker Engine settings editor displayed minified JSON instead of formatted JSON when first opened.
+- Fixed spurious 500 errors for Docker API calls made right after the VM woke from idle shutdown.
+- Fixed spurious 'Integrity issue detected' notifications caused by leftover symlinks from previously bundled binaries.
+- Fixed a broken documentation link in the error screen shown when the current user is not a member of the `docker-users` group.
+- Fixed a breaking change to the `/app/settings/grouped` API that caused integrations such as NVIDIA to stop working correctly.
+- Fixed high CPU usage (~30%) on macOS Retina displays caused by SVG animations in the Gordon landing page.
+- Fixed an issue where OAuth network errors caused Docker Desktop to incorrectly show users as signed out.
+- Fixed an issue where signing in via OAuth would not display the user's username and email in the UI after login.
+- QEMU has been updated to v10.2.3
+- **Logs** view improvements
+   - Added copy buttons. Copy all visible filtered logs at once or copy individual log entries on hover, respecting the current timestamp visibility setting.
+   - Improved the toolbar with a reorganized layout, saved filter presets that now capture container selection and build log visibility, and the ability to persist container filter state.
+   - Added the ability to clear logs.
+   - Combined **copy** and **expand**/**collapse** buttons into a single pinned column that stays visible during horizontal scrolling, and fixed **copy** accidentally toggling the row detail pan.
+- Fixed Registry Access Management policy downloads to avoid `permission denied` errors by fetching and caching policies in the user's own directory with tampering detection.
+
+#### For Windows
+
+- Fixed a bug where Docker Desktop on WSL failed to start with an 'is already mounted' error after a force-killed bootstrap left stale rootfs mounts behind.
+- Fixed an issue on Windows where clicking "Quit Docker Desktop" had no effect when the backend had crashed or been killed.
+- Fixed an issue on Windows where Docker Desktop processes could linger as orphans after an unexpected exit or crash.
+- Fixed getting stuck on "Starting the Docker Engine…" after an in-place upgrade on Windows when the WSL virtual machine had not been shut down.
+- Fixed the tray icon on Windows not matching the system taskbar theme, so the correct light or dark icon is now displayed.
+- Fixed a silent failure on Windows where backend startup errors were only written to a log file. Users now see a visible error dialog box when Docker Desktop fails to start.
+
+## 4.78.0
+
+{{< release-date date="2026-06-15" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.78.0" build_path="/229452/" >}}
+
+### Updates
+
+- [Docker Agent v1.73.0](https://github.com/docker/docker-agent/releases/tag/v1.73.0)
+- `docker pass` v0.1.4
+- [Credential helpers v0.9.8](https://github.com/docker/docker-credential-helpers/releases/tag/v0.9.8)
+
+### Bug fixes and enhancements
+
+#### For all platforms 
+
+- Fixed an out-of-memory crash that would cause Docker Desktop to become unresponsive or crash while streaming logs in the Docker Desktop Dashboard.
+- Improved update reliability by retrying stalled and transient download failures and resuming from the partially downloaded file.
+- Added live streaming output to Gordon tool calls so long-running commands like `docker compose up` display STDOUT/STDERR in real time instead of waiting until completion.
+- Added color-coded labels to the **Logs** view so each container and build source is visually distinguished by a unique color in both the log grid and the container-filter dropdown.
+- Improved the error message when the Docker Desktop VM fails to start. It now shows the underlying `VirtualizationFramework` / `libkrun` reason instead of the generic **Use of closed network connection**.
+- Fixed a bug where Docker CLI error messages were shown as raw JSON instead of human-readable text while Docker Desktop was in Resource Saver mode.
+- Fixed a crash that occurred in the **Logs** view when deselecting a container filter.
+- Fixed an issue where the support page was replaced by the no-virtualization override screen when accessed from the troubleshooting popover.
+- Fixed an issue where Docker Desktop failed to start on bare metal EC2 instances (e.g. `g4dn.metal`) with a **Nested virtualization not supported** error.
+- Increased the retry delay to accommodate transient rename failures caused by antivirus software holding file locks.
+- Gordon now shows clear network error messages with guidance to check VPN, proxy, or firewall settings when outbound HTTPS to Docker's services is blocked, instead of a generic agent error.
+- Fixed the Gordon AI model picker incorrectly showing an internal model identifier instead of **Default** for sessions with no explicit model selection.
+
+#### For Windows
+
+- Fixed Docker Desktop getting stuck on **Starting the Docker Engine…** after an in-place upgrade.
+- Fixed a bug where Docker Desktop was not restarted after a failed update was reverted to the previous version.
+- Fixed delta updates failing to prepare.
+- Fixed an issue on Hyper-V where Docker commands (e.g. `docker login`) would fail on the first attempt after the engine had been idle-shut-down or paused.
+- Fixed an issue on Windows where Docker Desktop showed a generic engine-start failure instead of a clear, actionable error message when WSL is not installed.
+
+## 4.77.0
+
+{{< release-date date="2026-06-08" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.77.0" build_path="/228796/" >}}
+
+### New
+
+- You can now export log data from the **Logs** view.
+
+### Updates
+
+- Docker Offload v0.6.3
+- [Docker Buildx v0.34.1](https://github.com/docker/buildx/releases/tag/v0.34.1)
+- [Docker Agent v1.70.0](https://github.com/docker/docker-agent/releases/tag/v1.70.0)
+- [Docker MCP gateway v0.42.2](https://github.com/docker/mcp-gateway/releases/tag/v0.42.2)
+- `docker pass` v0.1.2 
+- [containerd v2.2.4](https://github.com/containerd/containerd/releases/tag/v2.2.4)
+- [DHI CLI (`dhictl`) v0.0.4](https://github.com/docker-hardened-images/dhictl/releases/tag/v0.0.4)
+- [Docker Engine v29.5.3](https://docs.docker.com/engine/release-notes/29/#2953)
+
+### Bug fixes and enhancements
+
+#### For all platforms 
+
+- Increased the retry delay to accommodate transient rename failures caused by antivirus software holding file locks.
+- Marketplace extensions are now installed and updated by pinned manifest digest, instead of by tag, protecting against tag mutation after publication.
+- Added Buildx version information to the About window.
+- Added a case-sensitivity toggle to the **Logs** search bar which lets you switch between case-insensitive (default) and case-sensitive log filtering.
+- Fixed a bug where the mouse wheel scroll was not working in the **Logs** view grid.
+- Fixed an issue where the backend incorrectly exited with error code 150 on clean shutdown via SIGINT or SIGTERM, causing false failure signals.
+- Removed the bundled `hub-tool` binary from Docker Desktop.
+- Added working **Authenticate** and **Cancel** buttons to the MCP OAuth authorization chat bubble in Gordon, letting you complete or decline OAuth sign-in flows from MCP servers.
+- Added two new commands to `docker pass`:
+   - Use `docker pass run` to inject secrets into host commands.
+   - Use `docker pass plugins` for dynamic plugin management.
+- Fixed a regression where `docker cp` into a container with Enhanced Container Isolation (ECI) enabled set file ownership to `nobody:nogroup`.
+
+#### For Windows
+
+- Fixed an issue on Windows where Docker Desktop would get stuck on **Starting the Docker Engine...** after a failed WSL distro registration left a VHDX on disk.
+- Fixed a backend shutdown hang in Windows Containers mode that caused Docker Desktop to take a long time or fail to exit cleanly.
+
+## 4.76.0
+
+{{< release-date date="2026-06-01" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.76.0" build_path="/228118/" >}}
+
+### New
+
+- Docker Model Runner now supports registry mirrors.
+
+### Updates
+
+- [Docker Desktop Build v0.35.0](https://github.com/docker/desktop-build/releases/tag/v0.35.0)
+- [Docker Agent v1.62.0](https://github.com/docker/docker-agent/releases/tag/v1.62.0)
+- [NVIDIA Container Toolkit v1.19.1](https://github.com/NVIDIA/nvidia-container-toolkit/releases/tag/v1.19.1)
+- [Docker Compose v5.1.4](https://github.com/docker/compose/releases/tag/v5.1.4)
+- Docker Offload v0.5.93
+- [Docker Scout CLI v1.21.0](https://github.com/docker/scout-cli/releases/tag/v1.21.0)
+- `docker pass` v0.0.29
+
+### Security
+
+- Addressed [CVE-2026-8936](https://www.cve.org/CVERecord?id=CVE-2026-8936), a VM panic caused by unbounded recursion in the `grpcfuse` kernel module when a container created deeply nested directories on a bind-mounted host folder and triggered a `dentry` invalidation event.
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- The `docker sbom` command has been deprecated and will be removed in a future release. Use the [`docker scout sbom command`](/reference/cli/docker/scout/sbom/) instead.
+- Fixed a race condition in Docker Engine when **Resource Saver** was active.
+- Fixed a bug where anonymous Docker volumes were leaked each time a `kind` cluster was deleted, causing orphaned volumes to accumulate.
+- Fixed column resizing in the **All Logs** grid so that **Timestamp** and **Object** columns no longer expand unexpectedly, and column widths are now preserved across navigation sessions.
+- Fixed an issue where Docker Desktop failed to start when a VM disk resize operation encountered an error, even if the underlying filesystem was healthy.
+- Fixed an issue that caused Docker Desktop to hang when quit.
+- Fixed a bug where CPU and RAM resource totals could get stuck showing 0 in the Docker Desktop Dashboard after stopping or starting Docker Offload.
+- Fixed a flicker in Gordon where the final answer text would briefly appear inside the working group before jumping to the response bubble.
+- Fixed a daemon panic that could occur during concurrent sign-out and token refresh operations.
+- Fixed a bug where the **Volumes** view showed incorrect mount targets for containers with multiple volumes.
+- `docker pass` now has a `--force` flag on the `set` command. 
+- `docker --help` now shows `docker pass`.
+- Fixed stale API cache responses (synthetic 404s) for containers, images, networks, volumes, and plugins after restarting an idle-stopped engine via external API calls.
+- Fixed a bug where the **Delete** button on the **Builds** view might not be visible immediately after selecting a build. Fixes [docker/desktop-feedback#329](https://github.com/docker/desktop-feedback/issues/329) and fixes [docker/desktop-feedback#330](https://github.com/docker/desktop-feedback/issues/330).
+- Fixed time-namespaces being unavailable when Enhanced Container Isolation (ECI) is enabled.
+
+#### For Windows
+
+- Fixed a regression where the `--quiet` installer flag did not suppress the install-type dialog during silent installation.
+- Fixed a bug on Windows where a stale PID file with a trailing newline prevented the lingering daemon from being killed, leaving Windows Containers mode unconfigurable.
+- Fixed an issue on Windows where triggering an update while another installer instance was already running showed a generic error instead of a specific message.
+- Fixed an issue on Windows where the installer and updater executables incorrectly triggered UAC elevation prompts due to Windows heuristic installer detection.
+- Fixed double separator in the tray menu when running in Windows container mode.
+- Fixed port-binding failures on Windows Hyper-V where `docker run -p 0:N` could allocate HNS-reserved ports, causing bind errors.
+- Fixed garbled taskkill error messages in logs on non-English Windows systems (For example, Chinese Windows using GBK encoding).
+- Fixed unbounded growth of the WSL2 ISO cache. Old `docker-desktop.iso` and `docker-wsl-cli.iso` entries are now removed when a new version is installed. Fixes [docker/desktop-feedback#419](https://github.com/docker/desktop-feedback/issues/419).
+
+## 4.75.0
+
+{{< release-date date="2026-05-26" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.75.0" build_path="/227598/" >}}
+
+### Updates
+
+- Docker Offload v0.5.92
+- [Docker Engine v29.5.2](https://docs.docker.com/engine/release-notes/29/#2952)
+- [Docker Buildx v0.34.0](https://github.com/docker/buildx/releases/tag/v0.34.0)
+
+### Bug fixes and enhancements
+
+#### For all platforms 
+
+- Removed the Docker Scout view and disabled Scout-related OS notifications and notification popups.
+- Added support for time namespacing in ECI protected containers.
+- Fixed a bug where the `http_proxy` environment variable could prevent kind clusters from pulling local images.
+- Fixed a `500 Internal Server Error` that could occur on the first Docker API call right after the VM wakes up from idle shutdown. 
+- Fixed broken images in Docker Hub image descriptions caused by relative URLs being resolved to invalid `app://` scheme URLs.
+
+#### For Mac
+
+- Added a warning dialog that appears at startup when Docker Desktop is running from a staging directory due to a failed update. Also adds a link to download a fresh install.
+
+#### For Windows 
+
+- WSL integration with the default distribution has been disabled. To change this, visit **Settings**. 
+- Fixed a bug where `docker compose up` failed with an `EOF` error on Windows with a Hyper-V backend, when accepting a file-sharing consent prompt.
+- Fixed Windows installer bugs that could cause incorrect backend mode detection or unexpected directory creation during installation.
+
+## 4.74.0
+
+{{< release-date date="2026-05-19" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.74.0" build_path="/227015/" >}}
+
+### New
+
+- [Gordon](/ai/gordon) is now generally available. New usage plans are also available. Paid Gordon plans unlock higher usage limits.
+
+### Updates
+
+- Docker Offload v0.5.89
+- [Docker Agent v1.57.0](https://github.com/docker/docker-agent/releases/tag/v1.57.0)
+- [Credential helpers v0.9.7](https://github.com/docker/docker-credential-helpers/releases/tag/v0.9.7)
+- `docker pass` v0.0.26
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed a bug where Docker Desktop's own Electron helper processes (GPU, renderer, utility) were incorrectly detected and killed as lingering processes on startup when launching from the Start menu, causing a crash loop.
+- Fixed an issue where the **View build logs** toggle in Logs view display settings was reset after restarting Docker Desktop instead of persisting the user's preference.
+- Docker Extensions is now disabled by default.
+
+#### For Mac
+
+- Fixed published ports being inaccessible when a container is also connected to a Swarm overlay network. Fixes [docker/for-mac#7854](https://github.com/docker/for-mac/issues/7854).
+- Fixed dashboard TLS failures in some corporate environments.
+- Improved GUI security via content hash validation.
+
+#### For Linux
+
+- Added support for Ubuntu 26.04.
+
+## 4.73.1
+
+{{< release-date date="2026-05-13" >}}
+
+{{< desktop-install-v2 win=true version="4.73.1" build_path="/226574/" >}}
+
+### Bug fixes and enhancements
+
+#### For Windows
+
+- Fixed a bug where Docker Desktop's own Electron processes were incorrectly killed when launching from the Start menu. Fixes [docker/desktop-feedback#367](https://github.com/docker/desktop-feedback/issues/367).
+
+## 4.73.0
+
+{{< release-date date="2026-05-11" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.73.0" build_path="/226246/" >}}
+
+### Updates
+
+- [Docker Engine v29.4.3](https://docs.docker.com/engine/release-notes/29/#2943)
+- [Docker Agent v1.54.0](https://github.com/docker/docker-agent/releases/tag/v1.54.0)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed `Cmd+Q` (Mac) and `Ctrl+Q` (Windows/Linux) not fully quitting Docker Desktop. Fixes [docker/for-mac#7833](https://github.com/docker/for-mac/issues/7833).
+- Fixed a bug where canceling `docker load` left a containerd ref lock held, causing subsequent loads of the same image to fail.
+- Fixed an issue where Docker Desktop made unnecessary network requests to `mcp.docker.com` on sign-in when MCP Toolkit was disabled, causing unexpected proxy authentication prompts.
+- Fixed an issue where the search input in Gordon's session sidebar would not close if it was left empty.
+- Improved Docker Desktop handling of transient rename failures caused by antivirus software accessing those files simultaneously.
+
+#### For Mac
+
+- Fixed excessive memory usage on Apple Silicon Macs by improving the Linux VM's ability to return freed container memory back to the host OS.
+- Fixed a bug where containers received connections with a corrupted source IP when another container had an active outbound connection to an IP in the same subnet range. Fixes [docker/for-mac#7824](https://github.com/docker/for-mac/issues/7824).
+
+## 4.72.0
+
+{{< release-date date="2026-05-06" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.72.0" build_path="/225998/" >}}
+
+### New
+
+- The **Logs** view is now generally available.
+- New installations of Docker Desktop for Windows have a choice between per-user (Beta) or all-user installs.
+
+### Updates
+
+- [Docker Agent v1.50.0](https://github.com/docker/docker-agent/releases/tag/v1.50.0)
+- [Docker DHI (`dhictl`) v0.0.3](https://github.com/docker-hardened-images/dhictl/releases/tag/v0.0.3)
+- [Docker Model Runner v1.1.37](https://github.com/docker/model-cli/releases/tag/v1.1.37)
+- [credential helpers v0.9.6](https://github.com/docker/docker-credential-helpers/releases/tag/v0.9.6)
+
+### Security
+
+- The Extensions settings page now includes a security notice that extensions run with host-level privileges and are not audited by Docker.
+- [Fixed CVE-2026-31431 ("copy.fail")](https://xint.io/blog/copy-fail-linux-distributions) by backporting an upstream Linux kernel patch that prevents an unprivileged container user from gaining root inside the container via a controlled write into the host VM page cache.
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Improvements to Docker Offload idle notifications.
+- Fixed the **Open Gordon in TUI**  button not working due to a missing `run` subcommand in Docker Agent command arguments.
+- Fixed an issue where transient network errors or Docker Hub server errors during sign-in would unexpectedly sign users out instead of retrying automatically.
+- Improved data refresh for the Containers, Images, and Volumes screens by fetching up-to-date data on demand when navigating to those screens, reducing background polling load.
+- Fixed a kernel crash that could occur when changing filesharing technology after significant container file activity.
+- Enable the OpenAI Responses API (`/responses`) endpoint in Docker Model Runner.
+- Fixed a bug where users were unexpectedly signed out of Docker Desktop mid-flow when signing in via `docker login` using OAuth.
+
+#### For Windows
+
+- Fixed a bug on Windows where selecting the Docker Desktop taskbar icon multiple times could spawn multiple backend processes. Re-selecting the icon while Docker Desktop is running now brings the dashboard to focus.
+- Fixed a race condition on Windows that caused a false-positive "processes still running" dialog to appear when Docker Desktop starts or exits normally.
+
+### For Linux
+
+- Support for RHEL 8 has been dropped.
+
+## 4.71.0
+
+{{< release-date date="2026-04-27" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.71.0" build_path="/225177/" >}}
+
+> [!IMPORTANT]
+>
+> Support for RHEL 8 has ended. Installing Docker Desktop will require RHEL 9 or RHEL 10 in the next release.
+
+### Updates
+
+- [Docker Model Runner v1.1.36](https://github.com/docker/model-runner/releases/tag/v1.1.36)
+- [containerd to v2.2.3](https://github.com/containerd/containerd/releases/tag/v2.2.3)
+- [Runc v1.3.5](https://github.com/opencontainers/runc/releases/tag/v1.3.5)
+- [Docker Compose v5.1.3](https://github.com/docker/compose/releases/tag/v5.1.3)
+- [Docker Agent v1.44.0](https://github.com/docker/docker-agent/releases/tag/v1.44.0)
+- [Docker Engine v29.4.1](/manuals/engine/release-notes/29.md#2941)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Docker Model Runner is now disabled by default and must be explicitly enabled in **Settings**. When enabled, TCP host-side support is automatically active.
+- Fixed an issue where downloading a Docker Desktop update would fail without a clear error if the disk had insufficient free space.
+- Fixed an issue where Docker Scout tag recommendations, when inspecting an image, failed when the base image digest or repository name was empty.
+- Added a **Switch to local Docker context** button on the sign-in screen, allowing users in a cloud context to switch back to their local context without signing in.
+- Added a dedicated **Stopped** status screen for the cloud engine so users see a clear stopped state instead of an error screen when transitioning away from Docker Offload.
+
+#### For Mac
+
+- Fixed an issue where error tracking would temporarily continue sending session data directly after a user disabled analytics. Fixes [docker/for-mac#7768](https://github.com/docker/for-mac/issues/7768).
+
+#### For Windows
+
+- Fixed a critical issue where Docker Desktop Dashboard failed to open with `ERR_FAILED` errors caused by process hardening policies conflicting with Chromium.
+- Fixed a bug where Kubernetes could fail to start on WSL 2 when `HTTP_PROXY` environment variables are set in WSL 2 itself.
+- Fixed a bug in Enhanced Container Isolation (ECI) that was causing loss of container `rootfs` persistence across Docker Desktop restarts, when using WSL.
+
+### Security
+
+- Addressed [CVE-2026-5843](https://www.cve.org/cverecord?id=CVE-2026-5843), container-to-host code execution in the Docker Model Runner MLX inference backend via MLX-LM `model_file` importlib loading.
+
+## 4.70.0
+
+{{< release-date date="2026-04-20" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.70.0" build_path="/224270/" >}}
+
+### New
+
+- Added a CLI hint that surfaces the **Logs** view when running `logs`, `compose logs`, `compose attach`, or `compose up` commands, giving you quick access to logs across all running containers. Available with the **Logs** (Beta) feature enabled.
+
+### Updates
+
+- [Docker Compose v5.1.2](https://github.com/docker/compose/releases/tag/v5.1.2)
+- [Docker Engine v29.4.0](/manuals/engine/release-notes/29.md#2940)
+- [Docker Agent v1.43.0](https://github.com/docker/docker-agent/releases/tag/v1.43.0)
+- [Docker Model Runner v1.1.33](https://github.com/docker/model-runner/releases/tag/v1.1.33)
+- [Docker Scout CLI v1.20.4](https://github.com/docker/scout-cli/releases/tag/v1.20.4)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed a bug where `docker login` could fail silently in CI environments due to slow Docker Hub responses causing credential store update timeouts.
+- Fixed an issue where disabling Beta features also disabled Docker Model Runner.
+- Fixed `docker desktop start` causing the Docker AI agent API daemon to fail due to an inherited CLI plugin environment variable.
+
+#### For Mac
+
+- Fixed a crash loop where Docker Desktop repeatedly failed to start with exit status `42` after an update due to a corrupted `DockerAppLaunchPath` setting.
+- Fixed an issue where a failed update could leave Docker Desktop in a broken state. The installer now automatically reverts to the previous version and shows a clear error message.
+- Fixed a bug where stopping one container could disrupt active Unix socket forwards belonging to other running containers.
+
+#### For Windows
+
+- Fixed an issue where a failed update could leave Docker Desktop in a broken state. The installer now automatically reverts to the previous version and shows a clear error message.
+- Fixed a bug where a failed switch to Windows containers could leave Docker Desktop in a broken state, requiring a restart.
+- Fixed an issue where Docker Desktop failed to launch for users with `DEVHOME` set in their environment.
+- Temporarily rolled back process hardening that caused Electron crashes on Windows. Fixes [docker/desktop-feedback#245](https://github.com/docker/desktop-feedback/issues/245).
+
+## 4.69.0
+
+{{< release-date date="2026-04-13" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.69.0" build_path="/224084/" >}}
+
+### Updates
+
+- [Docker Agent v1.42.0](https://github.com/docker/docker-agent/releases/tag/v1.42.0)
+- [Docker Model v1.1.29](https://github.com/docker/model-runner/releases/tag/v1.1.29)
+- [containerd v2.2.2](https://github.com/containerd/containerd/releases/tag/v2.2.2)
+- [Docker Buildx v0.33.0](https://github.com/docker/buildx/releases/tag/v0.33.0)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue where `docker logout` from the CLI was ignored by Docker Desktop when OAuth tokens remained in the credential store, leaving the user unexpectedly signed in.
+- Fixed an issue where Docker Desktop could unexpectedly sign users out when unrelated credential updates, `docker login`, or transient network errors triggered a sign-out.
+- Fixed a data loss issue where backup data could be deleted during a failed restore operation, leaving users with no data.
+- Fixed an issue where sign-in credentials (`login-info.json`) could be included in diagnostic bundles, improving privacy and security. Note that this file contains an encoded organisation(s) name, plan name, encoded username, and encoded email only. No passwords or credentials are included.
+- Fixed the footer update label incorrectly showing **Downloading** during the prepare/unpack phase of an update. It now correctly displays **Preparing**.
+- Fixed an issue where Docker Desktop would not start when the internal storage disk was full.
+
+#### For Mac
+
+- Fixed an issue where the in-app update button was not disabled when `Docker.app` was installed in a non-user-writable directory, preventing failed update attempts.
+- Fixed update failure for users who installed Docker Desktop via Homebrew on Mac.
+
+#### For Windows
+
+- Fixed an unexpected WSL terminal popup appearing for Windows users using the Hyper-V backend during Docker Desktop installation or uninstallation.
+- Fixed an issue on Windows where factory reset deleted CLI plugins from `~/.docker/cli-plugins`, causing `docker build` to fall back to the legacy builder.
+- Fixed a bug where Kubernetes failed to start when WSL integration was enabled alongside another distro using cgroup v1 controllers.
+- Fixed a race condition that caused Kubernetes to fail to start when a Registry Access Management policy change occurred during startup.
+- Prevent Docker Desktop from fatally failing due to transient 'Access is denied' errors during file operations on Windows.
+
+## 4.68.0
+
+{{< release-date date="2026-04-07" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.68.0" build_path="/223695/" >}}
+
+### New
+
+- Gordon now has persistent local memory, allowing it to remember your preferences and context across sessions.
+
+### Updates
+
+- [Docker Agent v1.39.0](https://github.com/docker/docker-agent/releases/tag/v1.39.0)
+- [Docker Model v1.1.28](https://github.com/docker/model-runner/releases/tag/v1.1.28)
+- Docker Offload v0.5.81
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed a deadlock in Enhanced Container Isolation that caused containers to hang indefinitely during creation when ECI was enabled.
+- Added a warning banner to alert when an MCP server is community-provided and has not been verified by Docker.
+- Added a persistent **Show timestamps** toggle to the **Logs** view, allowing timestamps to be hidden in both table and visualiser views across sessions.
+- Fixed an issue where Docker Desktop frontend processes were not properly terminated on quit.
+- Fixed a deadlock when settings controlled by admins reload that could cause Docker Desktop to become unresponsive during sign in or sign out operations.
+- Fixed a bug where Docker Desktop could fail to start due to uncorrectable filesystem errors on the disk image not being repaired.
+- Fixed a bug that caused Enhanced Container Isolation (ECI) to inadvertently block startup of Kubernetes clusters.
+- Fixed an issue where a failed volume size fetch could make the **Volumes** view inaccessible; container counts on volumes now correctly exclude bind mounts.
+- Fixed race conditions in volume backup that could cause containers to be incorrectly restarted, export logs to be corrupted, or runtime panics when scheduling tasks.
+- Fixed a crash in the API cache that occurred when containers with no names caused a panic disrupting container listing.
+- Fixed a bug where starting a container could fail with `ENOENT` if a bind-mount parent directory was deleted while no container was using it.
+
+#### For Mac
+
+- Fixed a security vulnerability where tampered user-deployed config profiles could bypass organization sign-in enforcement.
+- Fixed a bug where a failed `vmnetd` handshake could dispatch a bogus command on a broken connection, causing unexpected networking errors.
+- Fixed a bug where the Docker Desktop Dashboard could be prematurely displayed when restoring to a fullscreen state on launch.
+- Fixed nested bind mounts showing empty child mount content on VirtioFS when using Docker Compose with multiple services sharing a volume. Fixes [docker/desktop-feedback#264](https://github.com/docker/desktop-feedback/issues/264).
+
+#### For Windows
+
+- Fixed an issue where the installer extraction did not update the progress bar and could take around 5 minutes, depending on the machine. Extraction is now ~60% faster and includes proper progress updates.
+- Fixed a race condition where container ports would sometimes not be published correctly after container start, affecting ephemeral ports, `--publish-all`, and gateway IP bindings.
+- Fixed an issue where a failed WSL distro move could leave the distro unregistered.
+
+### Security
+
+- Addressed [CVE-2026-5817](https://www.cve.org/cverecord?id=CVE-2026-5817), container-to-host code execution in the Docker Model Runner vllm-metal inference backend via unsandboxed `trust_remote_code` tokenizer loading.
+
+## 4.67.0
+
+{{< release-date date="2026-03-30" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.67.0" build_path="/222858/" >}}
+
+### New
+
+- Docker MCP Toolkit now has MCP profile template cards and an onboarding tour accessible via the **Profiles** tab.
+
+### Updates
+
+- [Docker Compose v5.1.1](https://github.com/docker/compose/releases/tag/v5.1.1)
+- [Docker Agent v1.34.0](https://github.com/docker/docker-agent/releases/tag/v1.34.0)
+- [Docker Scout CLI v1.20.3](https://github.com/docker/scout-cli/releases/tag/v1.20.3)
+- [Docker Model v1.1.25](https://github.com/docker/model-runner/releases/tag/v1.1.25)
+
+### Bug fixes and minor changes
+
+#### For all platforms
+
+- Docker Model Runner now supports Qwen3.5.
+- With the new **Logs (Beta)** view, you can now filter container logs by Compose stack.
+- Improved interaction with **Settings** while the Docker engine or Kubernetes is starting or stopping.
+- Fixed a bug where random UDP port bindings reported port `0` instead of the actual assigned port.
+- Fixed an issue with the Docker Desktop shortcut not reopening the Dashboard when Docker Desktop was already running.
+- Fixed an issue where the **Add to existing profile** dialog showed profiles that already contained all selected MCP servers in the dropdown.
+
+#### For Mac
+
+- Fixed intermittent `exec format error` when starting amd64 containers on Apple Silicon Macs due to a race condition between Rosetta `binfmt` registration and `virtiofs` device availability.
+
+#### For Windows
+
+- Fixed Hyper-V being silently re-enabled on every EXE upgrade for WSL 2 users.
+- Fixed an MSI installer bug where Docker Desktop processes could be left running after uninstall.
+- Fixed an issue on Windows where installations or updates using `--installation-dir` would fail due to the installer archive being extracted into the custom installation directory.
+- Improved Docker Desktop startup time on Windows by several seconds when using WSL 2.
+- Fixed a bug on the **Models** > **Logs** screen which caused `docker-model` processes to accumulate on Windows each time the screen was visited.
+
+### Security
+
+- Addressed [CVE-2026-33990](https://www.cve.org/cverecord?id=CVE-2026-33990), SSRF in Docker Model Runner OCI Registry Client
+
+## 4.66.1
+
+{{< release-date date="2026-03-26" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.66.1" build_path="/222799/" >}}
+
+### Updates
+
+- [Docker Engine v29.3.1](/manuals/engine/release-notes/29.md#2931)
+
+## 4.66.0
+
+{{< release-date date="2026-03-23" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.66.0" build_path="/222299/" >}}
+
+### Updates
+
+- [Docker Engine v29.3.0](https://docs.docker.com/engine/release-notes/29/#2930)
+- [NVIDIA Container Toolkit v1.19.0](https://github.com/NVIDIA/nvidia-container-toolkit/releases/tag/v1.19.0)
+
+### Bug fixes and minor changes
+
+#### For all platforms
+
+- Gordon improvements:
+   - Provides pre-filled prompts when deeplinking from command-line failure hints.
+   - Prevents Docker Hub rate limiting by authenticating before making requests.
+- Fixed a Kubernetes pod discovery hang when the kube context is broken or unreachable.
+- Fixed a terminal crash caused by an undefined dimensions error during terminal resize.
+- Fixed volume backup export error handling for file, image, and registry export operations.
+
+#### For Windows
+
+- Fixed high CPU usage in the Windows API proxy caused by unnecessary process enumeration.
+- Fixed the Windows MSI installer failing to update Docker Desktop. Versions between 4.56 and 4.65 need to uninstall before reinstalling version 4.66 or later. Note that uninstalling removes all associated data.
+
+## 4.65.0
+
+{{< release-date date="2026-03-16" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.65.0" build_path="/221669/" >}}
+
+### New
+
+- Added a new **Logs** view where you can explore logs from all sources in one unified view. (Beta)
+- Gordon hints now appear when `docker build`, `docker run`, or `docker compose` commands fail, offering contextual suggestions.
+- Community MCP servers now support OAuth authentication directly in the UI.
+- Added the [`docker dhi` CLI plugin](https://github.com/docker-hardened-images/dhictl) for managing Docker Hardened Images.
+
+### Updates
+
+- [Docker Scout CLI v1.20.1](https://github.com/docker/scout-cli/releases/tag/v1.20.1)
+- [Docker Agent v1.29.0](https://github.com/docker/docker-agent/releases/tag/v1.29.0)
+- [Docker Buildx v0.32.1](https://github.com/docker/buildx/releases/tag/v0.32.1)
+
+### Bug fixes and minor changes
+
+#### For all platforms
+
+- Kubernetes now defaults to kind for new clusters.
+- Fixed update progress bar not resuming correctly.
+
+#### For Windows 
+
+- Improved startup time by skipping docker-users group check when using WSL2 backend.
+
+### Known issues
+
+- The Windows MSI installer cannot update an existing Docker Desktop installation when the current version is between 4.56 and 4.65. As a workaround, uninstall the existing version before reinstalling the latest version. Note that uninstalling removes all associated data.
+
+## 4.64.0
+
+{{< release-date date="2026-03-11" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.64.0" build_path="/221278/" >}}
+
+### Updates
+
+- [Docker Compose v5.1.0](https://github.com/docker/compose/releases/tag/v5.1.0)
+- [Docker Scout CLI v1.20.0](https://github.com/docker/scout-cli/releases/tag/v1.20.0)
+- [Docker Agent v1.27.1](https://github.com/docker/docker-agent/releases/tag/v1.27.1)
+
+### Bug fixes and minor changes
+
+#### For all platforms
+
+- Fixed a bug in MCP Toolkit where disabling all tools in a profile would enable all tools.
+- Fixed the `docker ai` command stopping after a Docker Agent update.
+- Fixed Gordon session title flickering when hover buttons appeared.
+- Improved Gordon summary rendering and reduced narrative verbosity.
+- Fixed a bug where `docker ai` CLI commands did not correctly shell out to Docker Agent.
+- Fixed the **OAuth** tab in Docker MCP Toolkit not showing entries from all catalogs.
+- Improved MCP Catalog search.
+- Fixed the **Build logs** tab not retaining search terms and filters when switching tabs.
+- Fixed Kind container startup to be more reliable.
+
+#### For Mac
+
+- Improved update error reporting with more descriptive diagnostics.
+- Improved update reliability by preparing the updated `Docker.app` under `Application Support` instead of `/tmp`.
+
+### Known issues
+
+- The Windows MSI installer cannot update an existing Docker Desktop installation when the current version is between 4.56 and 4.65. As a workaround, uninstall the existing version before reinstalling the latest version. Note that uninstalling removes all associated data. 
+
+## 4.63.0
+
+{{< release-date date="2026-03-02" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.63.0" build_path="/220185/" >}}
+
+### New
+
+- Added SLSA v1 provenance support in the **Builds** view. 
+
+### Updates
+
+- [Kubernetes v1.34.3](https://github.com/kubernetes/kubernetes/releases/tag/v1.34.3)
+- Linux kernel `v6.12.72`
+
+### Bug fixes and minor changes
+
+#### For all platforms
+
+- Enhanced the proxy settings UI and added a separate proxy for containers.
+- Fixed an issue where community registry MCP catalogs failed to load when a server's config object contained `"required": null`.
+- Fixed an issue where `mcp-gateway` would hang when fetching secrets from the Secrets Engine while the Docker Desktop VM was in Resource Saver mode. 
+- Rebranded "Docker AI" references to "Gordon".
+
+#### For Windows
+
+- Improved startup time on Windows.
+
+### Known issues
+
+- The Windows MSI installer cannot update an existing Docker Desktop installation when the current version is between 4.56 and 4.65. As a workaround, uninstall the existing version before reinstalling the latest version. Note that uninstalling removes all associated data. 
+
+## 4.62.0
+
+{{< release-date date="2026-02-23" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.62.0" build_path="/219486/" >}}
+
+### New
+
+- With Docker MCP Toolkit, you can now use [profiles](/manuals/ai/mcp-catalog-and-toolkit/profiles.md) to organize your MCP servers into named collections. You can also create custom catalogs — curated collections of servers for your team or organization.
+
+### Updates
+
+- Linux kernel `v6.12.69`
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue where background update checks did not respect the **Automatically check for updates** setting when disabled. Fixes [docker/for-mac#3908](https://github.com/docker/for-mac/issues/3908).
+
+#### For Mac
+
+- Added support for vLLM Metal in Docker Model Runner.
+
+#### For Linux 
+
+- Fixed a networking crash on QEMU 10.2.0 and later.
+
+### Security
+
+- Addressed [CVE-2026-2664](https://www.cve.org/cverecord?id=CVE-2026-2664), out of bounds read in grpcfuse kernel module.
+- Addressed [CVE-2026-28400](https://www.cve.org/cverecord?id=CVE-2026-28400), runtime flag injection in Docker Model Runner.
+
+### Known issues
+
+- The Windows MSI installer cannot update an existing Docker Desktop installation when the current version is between 4.56 and 4.65. As a workaround, uninstall the existing version before reinstalling the latest version. Note that uninstalling removes all associated data.
+
+## 4.61.0
+
+{{< release-date date="2026-02-18" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.61.0" build_path="/219004/" >}}
+
+### New
+
+- You can now customize the left-hand navigation to show only the tabs that matter to you, and hide the ones that don’t.
+
+### Updates
+
+- Linux kernel `v6.12.68`
+- [Docker Engine v29.2.1](https://docs.docker.com/engine/release-notes/29/#2921)
+- Docker Sandbox `v0.12.0`
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Docker Sandboxes:
+   - Added automated image caching to prevent re-downloading images unnecessarily.
+   - Added Shell mode for blank coding agent sandboxes.
+   - Added support for OpenCode.
+   - Added support for mounting multiple workspaces.
+   - Added experimental Linux support (single user only, UID 1000).
+   - Added support for running in WSL 2.
+   - Sandboxes now start in the current working directory if no path is provided.
+
+### Known issues
+
+- The Windows MSI installer cannot update an existing Docker Desktop installation when the current version is between 4.56 and 4.65. As a workaround, uninstall the existing version before reinstalling the latest version. Note that uninstalling removes all associated data.
+
+## 4.60.1
+
+{{< release-date date="2026-02-10" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.60.1" build_path="/218372/" >}}
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed a rare issue that crashed the Docker Desktop Dashboard after sign-in.
+
+## 4.60.0
+
+{{< release-date date="2026-02-09" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.60.0" build_path="/218231/" >}}
+
+### New
+
+- Added a new `docker desktop diagnose` command to gather diagnostics.
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed `ping6 host.docker.internal`.
+- Enabled landlock LSM.
+- Docker Sandboxes improvements:
+   - Improved agent system prompt with network access documentation      
+   - Fixed Gemini API key injection  
+   - Sandboxes now block `console.anthropic.com/claude.ai` in proxy default rules
+   - Fix CLI help text for `run <agent> --help`
+   - Improved terminal size handling
+
+### Known issues
+
+- The Windows MSI installer cannot update an existing Docker Desktop installation when the current version is between 4.56 and 4.65. As a workaround, uninstall the existing version before reinstalling the latest version. Note that uninstalling removes all associated data. 
+
+## 4.59.1
+
+{{< release-date date="2026-02-03" >}}
+
+{{< desktop-install-v2 mac=true version="4.59.1" build_path="/217750/" >}}
+
+### Bug fixes and enhancements
+
+#### For Mac
+
+- Fixed an issue where CPU usage could spike at regular intervals. Fixes [docker/for-mac#7839](https://github.com/docker/for-mac/issues/7839).
+
+## 4.59.0
+
+{{< release-date date="2026-02-02" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.59.0" build_path="/217644/" >}}
+
+### Updates
+
+- Linux kernel `v6.12.67`
+- [Docker Compose v5.0.2](https://github.com/docker/compose/releases/tag/v5.0.2)
+- Docker Sandbox `v0.10.1`
+- [Docker Buildx v0.31.1](https://github.com/docker/buildx/releases/tag/v0.31.1)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Added Neo4j as a known publisher to the Docker MCP Catalog.
+- Fixed an issue where the **Models** tab would crash when displaying requests made via the Anthropic Messages API.
+
+#### For Mac
+
+- Fixed an issue where shared file permissions could be unintentionally modified when using DockerVMM. Fixes [docker/for-mac#7830](https://github.com/docker/for-mac/issues/7830).
+
+#### For Windows
+
+- Fixed an issue where container secrets injection could fail with `docker-pass`.
+- Temporarily disabled VHDX compaction for the WSL data disk to improve stability.
+
+### Security
+
+- Fixed a security issue in enhanced container isolation where Docker socket mount permissions could be bypassed when using the `--use-api-socket` flag.
+
+## 4.58.1
+
+{{< release-date date="2026-01-29" >}}
+
+{{< desktop-install-v2 mac=true version="4.58.1" build_path="/217134/" >}}
+
+### Bug fixes and enhancements
+
+#### For Mac
+
+- Fixed an issue where CPU usage could spike at regular intervals. Fixes [docker/for-mac#7839](https://github.com/docker/for-mac/issues/7839).
+
+## 4.58.0
+
+{{< release-date date="2026-01-26" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.58.0" build_path="/216728/" >}}
+
+### New
+
+- A new version of [Docker Sandboxes](/manuals/ai/sandboxes/_index.md) is now available on Docker Desktop. It provides a secure, isolated, microVM-based environment for running coding agents.
+
+### Updates
+
+- Linux kernel `v6.12.65`
+- [Credential helpers v0.9.5](https://github.com/docker/docker-credential-helpers/releases/tag/v0.9.5)
+- [Docker Engine v29.1.5](https://docs.docker.com/engine/release-notes/29/#2915)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Docker Model Runner now exposes an [Anthropic-compatible API](/manuals/ai/model-runner/api-reference.md#anthropic-compatible-api).
+- Docker Desktop now supports UTF-8 BOM for `admin-settings.json` and `registry.json`.
+- Fixed an issue where admin settings incorrectly changed user proxy settings after a restart.
+
+> [!IMPORTANT]
+>
+> Starting with Docker Desktop version 4.59, installing an update from the tray menu will proceed without opening the Docker Desktop Dashboard.
+
+#### For Mac
+
+- Fixed a bug where shared file permissions could be modified inadvertently while using DockerVMM on macOS. Fixes [docker/for-mac#7830](https://github.com/docker/for-mac/issues/7830).
+
+#### For Windows
+
+- Fixed an issue where the installer failed because of special ACLs set on `ProgramData`.
+
+
+### Security
+
+- Updated Kubernetes images to address CVEs.
+   - Kind:
+      - `docker/desktop-containerd-registry-mirror:v0.0.3`
+      - `docker/desktop-cloud-provider-kind:v0.5.0`
+   - Kubeadm:
+      - `docker/desktop-vpnkit-controller:v4.0`
+      - `docker/desktop-storage-provisioner:v3.0`
+- The `kind` dependency image `envoyproxy/envoy` was upgraded from v1.32.6 to v1.36.4. If you mirror `kind` images, ensure your mirrors are updated.
+
+## 4.57.0
+
+{{< release-date date="2026-01-19" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.57.0" build_path="/215387/" >}}
+
+### Security
+
+- Fixed [CVE-2025-14740](https://www.cve.org/cverecord?id=CVE-2025-14740) where the Docker Desktop for Windows installer contained multiple incorrect permission assignment vulnerabilities in the handling of the `C:\ProgramData\DockerDesktop` directory.
+
+### New
+
+- Docker Desktop now has a new issue tracker for all platforms at https://github.com/docker/desktop-feedback. Relevant, actively discussed issues from the previous platform-specific trackers will be migrated.
+
+### Updates
+
+- [Docker Compose v5.0.1](https://github.com/docker/compose/releases/tag/v5.0.1)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Improved alignment of the Ask Gordon streaming indicator so it stays in sync with content on large screens.
+- Fixed a bug where `docker debug` failed on containers started with environment variables but no '='. For example, `docker run -e NONEXISTENT_ENV_VAR`.
+
+## 4.56.0
+
+{{< release-date date="2026-01-12" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.56.0" build_path="/214940/" >}}
+
+### New
+
+- Docker Desktop now includes Docker Compose v5 which introduces a new official Go SDK. This SDK provides a comprehensive API that lets you integrate Compose functionality directly into your applications, allowing you to load, validate, and manage multi-container environments without relying on the Compose CLI. For more information, see the [Compose SDK docs](/manuals/compose/compose-sdk.md).
+
+### Updates
+
+- [containerd v2.2.1](https://github.com/containerd/containerd/releases/tag/v2.2.1)
+- [Docker Compose v5.0.0](https://github.com/docker/compose/releases/tag/v5.0.0)
+- [Docker Agent v1.18.6](https://github.com/docker/docker-agent/releases/tag/v1.18.6)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed a panic in filesharing tests when containers don't have an IP address immediately after starting.
+- Added support for custom DNS entries in the LinuxKit VM with the `ExtraDNSEntries` configuration field.
+
+#### For Windows
+
+- Fixed a bug on Windows where removing the state directory would fail because log files were still open.
+- Fixed installations from the Microsoft Store wrongly advertizing a new update.
+- Fixed a crash when running `/sbin/ldconfig` in `ubuntu:22.04` ARM64 containers by upgrading QEMU from 8.1.5 to 10.0.4. This resolves a known issue reported in [docker/for-win#15004](https://github.com/docker/for-win/issues/15004).
+
+  > [!NOTE]
+  >
+  > When running under ARM64 emulation, some `amd64` Go binaries built with older Go versions may still segfault. To avoid this, rebuild affected binaries using Go 1.25.4 or later. For details, see [golang/go#69255](https://github.com/golang/go/issues/69255) and the corresponding [Go commit](https://github.com/golang/go/commit/bf95b767394eb5643265f44c7b98bdbb85b897ce).
+
+#### For Linux
+
+- Fixed Kubernetes `hostPath` volume mounts failing on Linux hosts. Fixes [docker/desktop-linux#12](https://github.com/docker/desktop-linux/issues/12).
+
+## 4.55.0
+
+{{< release-date date="2025-12-16" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.55.0" build_path="/213807/" >}}
+
+### Updates
+
+- [Docker Engine v29.1.3](https://docs.docker.com/engine/release-notes/29/#2913)
+- [Docker Agent v1.15.1](https://github.com/docker/docker-agent/releases/tag/v1.15.1)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue that caused Docker Desktop to get stuck during startup.
+- Improved the error message when the `daemon.json` is invalid.
+- Fixed performance issues on every keystroke within a long Ask Gordon session.
+- Fixed an issue that prevented Kubernetes in kubeadm mode from starting up when an organization has configured Registry Access Management to block Docker Hub.
+
+> [!IMPORTANT]
+>
+> Wasm workloads will be deprecated and removed in a future Docker Desktop release.
+
+## 4.54.0
+
+{{< release-date date="2025-12-04" >}}
+
+### New
+
+- Added support for vLLM in Docker Model Runner on Windows with WSL2 and NVIDIA GPUs.
+
+### Bug fixes and enhancements
+
+#### For Mac
+
+- Fixed a bug where `/dev/shm` did not have enough permission for containers to write into. Fixes [docker/for-mac#7804](https://github.com/docker/for-mac/issues/7804). 
+
+### Upgrades
+
+- [Docker Buildx v0.30.1](https://github.com/docker/buildx/releases/tag/v0.30.1)
+- [Docker Engine v29.1.2](https://docs.docker.com/engine/release-notes/29/#2912)
+- [Runc v1.3.4](https://github.com/opencontainers/runc/releases/tag/v1.3.4)
+- [Docker Model Runner CLI v1.0.2](https://github.com/docker/model-runner/releases/tag/cmd%2Fcli%2Fv1.0.2)
+
+### Security 
+
+- Added a security patch to address [CVE-2025-13743](https://www.cve.org/cverecord?id=CVE-2025-13743) where Docker Desktop diagnostics bundles were found to include expired Hub PATs in log output due to error object serialization. 
+
+## 4.53.0
+
+{{< release-date date="2025-11-27" >}}
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue where the Support Diagnostics tooling inadvertently captured expired Docker Hub authorization bearer tokens.
+
+### Security 
+
+- Added security patches to address CVEs [2025-52565](https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2), [2025-52881](https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm), and [2025-31133](https://github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r) when using [Enhanced Container Isolation](https://docs.docker.com/enterprise/security/hardened-desktop/enhanced-container-isolation). 
+
+## 4.52.0
+
+{{< release-date date="2025-11-20" >}}
+
+### New
+
+- Added new port binding settings to Docker Desktop. This can also be controlled by administrators via Settings Management using the `admin-settings.json` file.
+- Added a new Docker Model Runner command. With `docker model purge` you can remove all your models.
+
+### Upgrades
+
+- [Docker Engine v29.0.0](/manuals/engine/release-notes/29.md#2900)
+- [Docker Model Runner v1.0.3](https://github.com/docker/model-runner/releases/tag/v1.0.3)
+- [Docker Model Runner CLI v1.0.0](https://github.com/docker/model-runner/releases/tag/cmd%2Fcli%2Fv1.0.0)
+- Docker MCP plugin `v0.28.0`
+
+### Bug fixes and enhancements
+
+#### For all platforms 
+
+- Docker MCP Toolkit improvements:
+   - Amazon Q client support
+   - OAuth DCR (Dynamic Client Registration) with Docker Engine
+   - Create MCP profiles using the CLI
+- Docker Model Runner improvements:
+   - You can now skip the `/engines` prefix for [Docker Model Runner's OpenAI API endpoint](/manuals/ai/model-runner/api-reference.md#rest-api-examples) `curl http://localhost:12434/v1/models`.
+   - You can now skip the `ai/` prefix for the models [published on Docker Hub with](https://hub.docker.com/u/ai) `docker model pull`.
+   - Downloads are now resumed when they get interrupted.
+
+#### For Windows
+
+- Fixed an issue with Kerberos/NTLM proxy sign in.
+
+## 4.51.0
+
+{{< release-date date="2025-11-13" >}}
+
+### New
+
+- You can now set up your Kubernetes resources from the **Kubernetes** view. This new view also provides a real-time display of your pods, services, and deployments. 
+
+### Upgrades
+
+- [Docker Engine v28.5.2](/manuals/engine/release-notes/28.md#2852)
+- Linux kernel `v6.12.54`
+
+### Bug fixes and enhancements
+
+#### For all platforms 
+
+- Kind now only pulls required dependency images if they are not available locally.
+
+## 4.50.0
+
+{{< release-date date="2025-11-06" >}}
+
+### New
+
+- [Dynamic MCP](/manuals/ai/mcp-catalog-and-toolkit/dynamic-mcp.md)(Experimental) is now available in Docker Desktop .
+- Introduced a new Welcome Survey to improve onboarding. New users can now provide information to help tailor their Docker Desktop experience.
+
+### Upgrades
+
+- [Docker Compose v2.40.3](https://github.com/docker/compose/releases/tag/v2.40.3)
+- [NVIDIA Container Toolkit v1.18.0](https://github.com/NVIDIA/nvidia-container-toolkit/releases/tag/v1.18.0)
+
+### Bug fixes and enhancements
+
+#### For all platforms 
+
+- Docker Desktop now detects and attempts to avoid clashes between the "Docker subnet" and physical networks using RFC1918 addresses. For example if the host has a non-default route which overlaps with `192.168.65.0/24` then an alternative network will be chosen automatically. You can still override the choice as before via Docker Desktop settings and admin settings.
+- Docker Desktop no longer treats Stargz Snapshotter failures as fatal. If a failure occurs, Docker Desktop continues to run without the Stargz Snapshotter.
+- Ask Gordon no longer displays images with user provided URLs.
+- Ask Gordon now asks for confirmation before running all built-in and all user added MCP tools.
+
+## 4.49.0
+
+{{< release-date date="2025-10-23" >}}
+
+> [!IMPORTANT]
+>
+> Support for Windows 10 21H2 (19044) and 11 22H2 (22621) has ended. Installing Docker Desktop will require Windows 10 22H2 (19045) or Windows 11 23H2 (22631) in the next release.
+
+### Security
+
+- Fixed [CVE-2025-9164](https://www.cve.org/cverecord?id=CVE-2025-9164) where the Docker Desktop for Windows installer was vulnerable to DLL hijacking due to insecure DLL search order. The installer searches for required DLLs in the user's Downloads folder before checking system directories, allowing local privilege escalation through malicious DLL placement.
+
+### New 
+
+- [Docker Agent](/manuals/ai/docker-agent/_index.md) is now available through Docker Desktop. 
+- [Docker Debug](/reference/cli/docker/debug/) is now free for all users. 
+
+### Upgrades
+
+- [Docker Engine v28.5.1](/manuals/engine/release-notes/28.md#2851)
+- [Docker Compose v2.40.2](https://github.com/docker/compose/releases/tag/v2.40.2)
+- [NVIDIA Container Toolkit v1.17.9](https://github.com/NVIDIA/nvidia-container-toolkit/releases/tag/v1.17.9)
+- Docker Debug `v0.0.45` 
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue where Docker Desktop used an expired proxy password while waiting for the user to enter a new one.
+- Fixed a 'chown' error shown on startup with Docker Debug.
+- Fixed a bug that caused some forwarded UDP ports to hang. 
+
+#### For Mac
+
+- Fixed Kubernetes startup hanging when another Kubernetes context was active. Fixes https://github.com/docker/for-mac/issues/7771.
+- If a Rosetta install is cancelled or fails, Rosetta will be disabled in Docker Desktop.
+- Minimum OS version to install or update Docker Desktop on macOS is now macOS Sonoma (version 14) or later.
+
+## 4.48.0
+
+{{< release-date date="2025-10-09" >}}
+
+> [!IMPORTANT]
 >
-> If you're experiencing malware detection issues on Mac, follow the steps documented in [docker/for-mac#7527](https://github.com/docker/for-mac/issues/7527).
+> Support for macOS 13 has ended. Installing Docker Desktop will require macOS 14 in the next release.
+
+### New
+
+- You can now specify PAC files and Embedded PAC scripts with installer flags for [macOS](/manuals/desktop/setup/install/mac-install.md#proxy-configuration) and [Windows](/manuals/desktop/setup/install/windows-install.md#proxy-configuration). 
+- Administrators can set proxy settings via [macOS configuration profiles](/manuals/enterprise/security/enforce-sign-in/methods.md#macos-configuration-profiles-method-recommended). 
+
+### Upgrades
+
+- [Docker Compose v2.40.0](https://github.com/docker/compose/releases/tag/v2.40.0)
+- [Docker Buildx v0.29.1](https://github.com/docker/buildx/releases/tag/v0.29.1)
+- [Docker Engine v28.5.1](https://docs.docker.com/engine/release-notes/28/#2851)
+- Docker MCP plugin `v0.22.0`
+- [Docker Model CLI v0.1.42](https://github.com/docker/model-cli/releases/tag/v0.1.42)
+
+### Bug fixes and enhancements
+
+#### For all platforms 
+
+- Fixed an issue where kind cluster state is sometimes reset when Desktop restarts. Fixes [docker/for-mac#77445](https://github.com/docker/for-mac/issues/7745).
+- Removed the obsolete `mcp` key to align with the latest VS Code MCP server changes.
+- Update credential helpers to [v0.9.4](https://github.com/docker/docker-credential-helpers/releases/tag/v0.9.4).
+- Fixed an issue where Docker Desktop used an expired proxy password while waiting for the user to enter a new one. 
+- Fixed a bug which caused Docker Desktop to regularly create new processes with Docker CLI tools under certain conditions. Fixes [docker/for-win#14944](https://github.com/docker/for-win/issues/14944).
+- Fixed a bug which caused models to not be configured for embeddings with Docker Model Runner via Compose. To specify that a model should be configured for embeddings, you must explicitly add the `--embeddings` runtime flag as described in [AI Models in Docker Compose](https://docs.docker.com/ai/compose/models-and-compose/#model-configuration-options). Fixes [docker/model-runner#166](https://github.com/docker/model-runner/issues/166).
+
+#### For Windows
+
+- Removed the `HKLM\SOFTWARE\Docker Inc.\Docker\1.0` registry key. Look for `docker.exe` in the path to find out where Docker Desktop is installed instead.
+- Fixed startup in WSL 2 mode when IPv6 has been disabled.
+
+## 4.47.0
+
+{{< release-date date="2025-09-25" >}}
+
+### Security
+
+- Fixed [CVE-2025-10657](https://www.cve.org/CVERecord?id=CVE-2025-10657) where the Enhanced Container Isolation [Docker Socket command restrictions](../enterprise/security/hardened-desktop/enhanced-container-isolation/config.md#command-restrictions) feature was not working properly in Docker Desktop 4.46.0 only (the configuration for it was being ignored).
+
+### New
+
+- Added dynamic MCP server discovery and support to Docker's MCP catalog.
+- With Enhanced Container Isolation, administrators can now block `docker plugin` and `docker login` commands in containers with Docker socket mounts.
+- Added a new Docker Model Runner command. With `docker model requests` you can fetch requests and responses.
+
+### Upgrades
+
+- [Docker Compose v2.39.4](https://github.com/docker/compose/releases/tag/v2.39.4)
+- [Kubernetes v1.34.1](https://github.com/kubernetes/kubernetes/releases/tag/v1.34.1)
+  - [CNI plugins v1.7.1](https://github.com/containernetworking/plugins/releases/tag/v1.7.1)
+  - [cri-tools v1.33.0](https://github.com/kubernetes-sigs/cri-tools/releases/tag/v1.33.0)
+  - [cri-dockerd v0.3.20](https://github.com/Mirantis/cri-dockerd/releases/tag/v0.3.20)
+- Docker Debug `v0.0.44`
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- You can now search for MCP servers more easily with filters, sorting, and improved search functionality.
+- Docker Debug no longer hangs when debugging containers that have environment variables set to an empty value.
+- Enhanced Docker Model Runner with rich response rendering in the CLI, conversational context in the Docker Desktop Dashboard, and resumable downloads.
+
+#### For Mac
+
+- Removed the `com.apple.security.cs.allow-dyld-environment-variables` entitlement which allow a signed, arbitrary dynamic library to be loaded with Docker Desktop via the `DYLD_INSERT_LIBRARIES` environment variable.
+- Fixed a regression where config profile sign-in enforcement broke for some customer environments.
+- Fixed a bug that sometimes caused the `docker model package` command to hang when writing to the local content store (without the `--push` flag).
+- Fixed a bug where containers started with the restart policy `unless-stopped` were never restarted. Fixes [docker/for-mac#7744](https://github.com/docker/for-mac/issues/7744).
+
+#### For Windows
+
+- Fixed the Goose MCP client connection on Windows for the Docker MCP Toolkit.
+- Addressed an issue with the "Skipping integration" of a WSL distro option, after a failed integration attempt.
+- Fixed a bug that sometimes caused the `docker model package` command to hang when writing to the local content store (without the `--push` flag).
+
+## 4.46.0
+
+{{< release-date date="2025-09-11" >}}
+
+### New
+
+- Added a new Learning center walkthrough for Docker MCP Toolkit and other onboarding improvements.
+- Administrators can now control [PAC configurations with Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md#proxy-settings).
+- The update experience has been redesigned to make it easier to understand and manage updates for Docker Desktop and its components.
+
+### Upgrades
+
+- [Docker Buildx v0.28.0](https://github.com/docker/buildx/releases/tag/v0.28.0)
+- [Docker Engine v28.4.0](https://docs.docker.com/engine/release-notes/28/#2840)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- With the Docker CLI, you can now set the `GODEBUG` environment variable when the key-value pair (`"GODEBUG":"..."`) exists inside the Docker context metadata. This means certificates that have negative serial numbers in the CLI binaries are supported by default.
+- Updated the Docker Subscription Service Agreement link to point to the latest version.
+
+#### For Mac
+
+- Improved the security of Docker Model Runner by enabling sandboxing of the `llama.cpp` inference processes.
+- Fixed a bug which caused Docker Desktop to start slowly and appear frozen. Fixes [docker/for-mac#7671](https://github.com/docker/for-mac/issues/7671).
+
+#### For Windows
+
+- Improved the security of Docker Model Runner by enabling sandboxing of the `llama.cpp` inference processes.
+
+#### For Linux
+
+- Fixed a path issue in the RHEL post-uninstall sequence.
+
+## 4.45.0
+
+{{< release-date date="2025-08-28" >}}
+
+### New
+
+- [Docker Model Runner](/manuals/ai/model-runner/_index.md) is now generally available.
+
+### Upgrades
+
+- [Docker Compose v2.39.2](https://github.com/docker/compose/releases/tag/v2.39.2)
+- [Docker Buildx v0.27.0](https://github.com/docker/buildx/releases/tag/v0.27.0)
+- [Docker Scout CLI v1.18.3](https://github.com/docker/scout-cli/releases/tag/v1.18.3)
+- [Docker Engine v28.3.3](https://docs.docker.com/engine/release-notes/28/#2833)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed a bug that caused the `com.docker.diagnose` to crash when uploading a diagnostics bundle behind a proxy that requires authentication.
+- The `kind` dependency image `envoyproxy/envoy` was upgraded from v1.32.0 to v1.32.6. If you mirror `kind` images, ensure your mirrors are updated.
+
+#### For Mac
+
+- Fixed a bug that caused Docker Desktop to crash after the laptop woke from sleep. Fixes [docker/for-mac#7741](https://github.com/docker/for-mac/issues/7741).
+- Fixed an issue where the VM would sometimes fail with the error **The virtual machine stopped unexpectedly.**
+- Fixed a bug that would break port mappings when a container was connected to or disconnected from a network after it was started. Fixes [docker/for-mac#7693](https://github.com/docker/for-mac/issues/7693).
+
+#### For Windows
+
+- Fixed a bug that prevented CLI plugins from being deployed to `~/.docker/cli-plugins` by default when users lacked the correct permissions.
+- Fixed a bug where relocating the WSL data distribution would fail if the `docker-desktop` distribution was not present.
+- Fixed a typo in the WSL install URL in the Docker Desktop Dashboard.
+- Fixed an issue where certain WSL distros would fail to integrate. Fixes [docker/for-win#14686](https://github.com/docker/for-win/issues/14686)
+
+## 4.44.3
+
+{{< release-date date="2025-08-20" >}}
+
+### Security
+
+- Fixed [CVE-2025-9074](https://www.cve.org/CVERecord?id=CVE-2025-9074) where a malicious container running on Docker Desktop could access the Docker Engine and launch additional containers without requiring the Docker socket to be mounted. This could allow unauthorized access to user files on the host system. Enhanced Container Isolation (ECI) does not mitigate this vulnerability.
+
+### Bug fixes and enhancements
+
+- Fixed a bug which caused the Docker Offload dialog to block users from accessing the dashboard.
+
+## 4.44.2
+
+{{< release-date date="2025-08-15" >}}
+
+### Bug fixes and enhancements
+
+ - Adds [Docker Offload](/manuals/offload/_index.md) to the **Beta features** settings tab and includes updates to support [Docker Offload Beta](https://www.docker.com/products/docker-offload/).
+
+## 4.44.1
+
+{{< release-date date="2025-08-13" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.44.1" build_path="/201842/" >}}
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue found in version 4.44.0 that caused startup to fail when `vpnkit` CIDR is locked without specifying a value in Desktop Settings Management.
+
+#### For Windows
+
+- Fixed an issue where volumes and containers were not visible after an upgrade from distributions using the legacy `version-pack-data` directory structure.
+- Resolved a rare issue in WSL 2 where the Docker CLI failed with a **Proxy Authentication Required** error.
+- Fixed a bug where CLI plugins were not deployed to `~/.docker/cli-plugins` if the user lacked execution permissions on that directory.
+
+## 4.44.0
+
+{{< release-date date="2025-08-07" >}}
+
+### New
+
+- WSL 2 stability improvements.
+- You can now inspect requests and responses to help you diagnose model-related issues in Docker Model Runner.
+- Added the ability to run multiple models and receive a warning on insufficient resources. This avoids Docker Desktop freezing when using big models.
+- Added new MCP clients to the MCP Toolkit: Gemini CLI, Goose.
+- Introduced `--gpu` (Windows only) and `--cors` flags for `docker desktop enable model-runner`.
+- Added a new `docker desktop kubernetes` command to the Docker Desktop CLI.
+- You can now search for specific configuration options within **Settings**.
+- Apple Virtualization is now the default VMM for better performance and QEMU Virtualization is removed. See [blog post](https://www.docker.com/blog/docker-desktop-for-mac-qemu-virtualization-option-to-be-deprecated-in-90-days/).
+- Performance and stability improvements to the DockerVMM.
+
+### Upgrades
+
+- [Docker Compose v2.39.1](https://github.com/docker/compose/releases/tag/v2.39.1)
+- [Docker Buildx v0.26.1](https://github.com/docker/buildx/releases/tag/v0.26.1)
+- [Docker Engine v28.3.2](https://docs.docker.com/engine/release-notes/28/#2832)
+- [Docker Scout CLI v1.18.2](https://github.com/docker/scout-cli/releases/tag/v1.18.2)
+- [Docker Model CLI v0.1.36](https://github.com/docker/model-cli/releases/tag/v0.1.36)
+- [Docker Desktop CLI v0.2.0](/manuals/desktop/features/desktop-cli.md)
+
+### Security
+
+We are aware of [CVE-2025-23266](https://nvd.nist.gov/vuln/detail/CVE-2025-23266), a critical vulnerability affecting the NVIDIA Container Toolkit in CDI mode up to version 1.17.7. Docker Desktop includes version 1.17.8, which is not impacted. However, older versions of Docker Desktop that bundled earlier toolkit versions may be affected if CDI mode was manually enabled. Upgrade to Docker Desktop 4.44 or later to ensure you're using the patched version.
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue pulling images with zstd differential layers when the containerd image store is enabled.
+- Fixed a bug causing containers launching  with the `--restart` flag to not restart properly when using Enhanced Container Isolation.
+- Improved interaction between [Kubernetes custom registry images](/manuals/desktop/use-desktop/kubernetes.md#configuring-a-custom-image-registry-for-kubernetes-control-plane-images) and Enhanced Container Isolation (ECI), so the [ECI Docker Socket image list](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md) no longer needs to be manually updated when using a custom registry for Kubernetes control plane images.
+- Fixed a bug where a Docker Desktop Kubernetes cluster in kind mode fails to start after restarting Docker Desktop if the user is required to be signed in but is currently signed out.
+- Fixed a bug that prevented the mounting of MCP secrets into containers when [Enhanced Container Isolation](/enterprise/security/hardened-desktop/enhanced-container-isolation/) is enabled.
+- Fixed a bug preventing the use of `--publish-all` when `--publish` was already specified.
+- Fixed a bug causing the **Images** view to scroll infinitely. Fixes [docker/for-mac#7725](https://github.com/docker/for-mac/issues/7725).
+- Fixed a bug which caused the **Volumes** tab to be blank while in Resource Saver mode.
+- Updated terms of service text on first launch.
+- More robustness in parsing newly released GGUF formats.
+
+#### For Mac
+
+- Fixed disk corruption on DockerVMM when reclaiming disk space.
+- Fixed regression since 4.42.0 on DockerVMM by re-introducing performance boost on general usage.
+- Removed QEMU hypervisor and switched to Apple Virtualization as the new default. See [blog post](https://www.docker.com/blog/docker-desktop-for-mac-qemu-virtualization-option-to-be-deprecated-in-90-days/).
+- Fixed a bug preventing Traefik from autodetecting containers' ports. Fixes [docker/for-mac#7693](https://github.com/docker/for-mac/issues/7693).
+- Fixed a bug that caused port mappings to break when a container was connected to or disconnected from a network after it was started. Fixes [docker/for-mac#7693](https://github.com/docker/for-mac/issues/7693#issuecomment-3131427879).
+- Removed eBPF which blocked `io_uring`. To enable `io_uring` in a container, use `--security-opt seccomp=unconfined`. Fixes [docker/for-mac#7707](https://github.com/docker/for-mac/issues/7707).
+- Docker Model Runner now supports GPT OSS models.
+
+#### For Windows
+
+- Re-added `docker-users` group to the named pipe security descriptors.
+- Fixed an installer crash when the current user has no `SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall` registry key.
+- Fixed a bug where Docker Desktop could leak a `com.docker.build` process and fail to start. Fixed [docker/for-win#14840](https://github.com/docker/for-win/issues/14840).
+- Fixed a bug that was preventing Docker Desktop Kubernetes in kind mode from starting when using WSL with `cgroups v1` and Enhanced Container Isolation (ECI) is enabled.
+- Fixed a typo in the WSL installation URL in the UI.
+- Docker Model Runner now supports GPT OSS models
+
+## 4.43.2
+
+{{< release-date date="2025-07-15" >}}
+
+### Upgrades
+
+- [Docker Compose v2.38.2](https://github.com/docker/compose/releases/tag/v2.38.2)
+- [Docker Engine v28.3.2](https://docs.docker.com/engine/release-notes/28/#2832)
+- Docker Model CLI v0.1.33
+
+## 4.43.1
+
+{{< release-date date="2025-07-04" >}}
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue that caused Docker Desktop UI to break when Ask Gordon responses contained HTML tags.
+- Fixed an issue that prevented extensions from communicating with their backends.
+
+## 4.43.0
+
+{{< release-date date="2025-07-03" >}}
+
+{{< desktop-install-v2 all=true win_arm_release="Early Access" version="4.43.0" build_path="/198134/" >}}
+
+### New
+
+- [Compose Bridge](/manuals/compose/bridge/_index.md) is now generally available.
+
+### Upgrades
+
+- [Docker Buildx v0.25.0](https://github.com/docker/buildx/releases/tag/v0.25.0)
+- [Docker Compose v2.38.1](https://github.com/docker/compose/releases/tag/v2.38.1)
+- [Docker Engine v28.3.0](https://docs.docker.com/engine/release-notes/28/#2830)
+- [NVIDIA Container Toolkit v1.17.8](https://github.com/NVIDIA/nvidia-container-toolkit/releases/tag/v1.17.8)
+
+### Security
+
+- Fixed [CVE-2025-6587](https://www.cve.org/CVERecord?id=CVE-2025-6587) where sensitive system environment variables were included in Docker Desktop diagnostic logs, allowing for potential secret exposure.
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed a bug causing `docker start` to drop the container's port mappings for a container already running.
+- Fixed a bug that prevented container ports to be displayed on the GUI when a container was re-started.
+- Fixed a bug that caused Docker API `500 Internal Server Error for API route and version` error application start.
+- The settings **Apply & restart** button is now labeled **Apply**. The VM is no longer restarted when applying changed settings.
+- Fixed a bug where the disk would be corrupted if Docker is shutdown during a `fsck`.
+- Fixed a bug causing an incorrect `~/.kube/config` in WSL2 when using a `kind` Kubernetes cluster.
+- Return an explicit error to a Docker API / `docker` CLI command if Docker Desktop has been manually paused.
+- Fixed an issue where unknown keys in Admin and Cloud settings caused a failure.
+
+#### For Mac
+
+- Removed `eBPF` which blocked `io_uring`. To enable `io_uring` in a container, use `--security-opt seccomp=unconfined`. Fixes [docker/for-mac#7707](https://github.com/docker/for-mac/issues/7707).
+
+#### For Windows
+
+- Fixed an issue that caused the Docker Desktop installer to crash when the current user has no `SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall` registry key.
+- Fixed a bug where Docker Desktop could leak a `com.docker.build` process and fail to start. Fixes [docker/for-win#14840](https://github.com/docker/for-win/issues/14840)
+
+### Known issues
+
+#### For all platforms
+
+- `docker buildx bake` will not build images in Compose files with a top-level models attribute. Use `docker compose build` instead.
+- Gordon responses containing HTML can cause Desktop UI to be permanently broken. As a workaround, you can delete `persisted-state.json` file to reset the UI. The file is located in the following directories:
+  - Windows: `%APPDATA%\Docker Desktop\persisted-state.json`
+  - Linux: `$XDG_CONFIG_HOME/Docker Desktop/persisted-state.json` or `~/.config/Docker Desktop/persisted-state.json`
+  - Mac: `~/Library/Application Support/Docker Desktop/persisted-state.json`
+
+#### For Windows
+
+- Possible incompatibility between the "host networking" feature of Docker Desktop and the most recent WSL 2 Linux kernel. If you encounter such issues, downgrade WSL 2 to 2.5.7.
+
+## 4.42.1
+
+{{< release-date date="2025-06-18" >}}
+
+### Upgrades
+
+- [Docker Compose v2.37.1](https://github.com/docker/compose/releases/tag/v2.37.1)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue where Docker domains were not reachable when the proxy configuration is not valid.
+- Fixed a possible deadlock when exposing ports.
+- Fixed a race condition which can cause `docker run -p` ports to disappear.
+
+#### For Mac
+
+- Fixed a bug where a container’s port list appeared empty when inspected immediately after it was created, for example, when using a script. [docker/for-mac#7693](https://github.com/docker/for-mac/issues/7693)
+
+#### For Windows
+
+- Disabled the Resource Saver mode in WSL 2 to prevent `docker` CLI commands hanging in WSL 2 distros. [docker/for-win#14656](https://github.com/docker/for-win/issues/14656#issuecomment-2960285463)
+
+## 4.42.0
+
+{{< release-date date="2025-06-04" >}}
+
+### New
+
+- Expanded network compatibility with IPv6 support.
+- The Docker MCP Toolkit is now natively integrated into Docker Desktop.
+- Docker Model Runner is now available for Windows systems running on Qualcomm/ARM GPUs.
+- Added a **Logs** tab to the Models view so you can see the inference engine output in real time.
+- Gordon now integrates the MCP Toolkit, providing access to 100+ MCP servers.
+
+### Upgrades
+
+- [Docker Buildx v0.24.0](https://github.com/docker/buildx/releases/tag/v0.24.0)
+- [Docker Engine v28.2.2](https://docs.docker.com/engine/release-notes/28/#2822)
+- [Compose Bridge v0.0.20](https://github.com/docker/compose-bridge-binaries/releases/tag/v0.0.20)
+- [Docker Compose v2.36.2](https://github.com/docker/compose/releases/tag/v2.36.2)
+- [NVIDIA Container Toolkit v1.17.7](https://github.com/NVIDIA/nvidia-container-toolkit/releases/tag/v1.17.7)
+- [Docker Scout CLI v1.18.0](https://github.com/docker/scout-cli/releases/tag/v1.18.0)
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Docker Desktop now accepts certificates with a negative serial number.
+- Re-enable `seccomp` for containers by default. Use `docker run --security-opt seccomp=unconfined` to disable seccomp for a container.
+- Fixed a bug that caused Docker Desktop to hang when it ran out of memory.
+- Block `io_uring` syscalls in containers.
+- Added support for pulling models from Docker Hub directly, simplifying the process of accessing and using models.
+- Docker Desktop now sets the disk usage limit to the size of the physical disk on fresh install and reset to defaults on Mac and Linux.
+- The maximum disk size in the settings UI now aligns with the full capacity of the host file system.
+- The **Models** view now has a **Docker Hub** tab that lists models under the `ai` namespace.
+- Improved the sign-in enforcement message when more than 10 organizations are enforced.
+- Changed the way ports are mapped by Docker Desktop to fully support IPv6 ports.
+- Fixed a bug in the Dashboard container logs screen causing the scrollbar to disappear as the mouse approaches.
+- [Enforced sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) fixed for Teams subscription users.
+- `llama.cpp` server now supports streaming and tool calling in Model Runner.
+- Sign-in Enforcement capability is now available to all subscriptions.
+
+#### For Mac
+
+- Fixed a bug where the disk would always have a minimum usage limit of 64GB when using Docker VMM.
+- Disabled the memory protection keys mechanism in the Docker Desktop Linux VM. This caused VS Code Dev Containers to not work properly. See [docker/for-mac#7667](https://github.com/docker/for-mac/issues/7667).
+- Fixed persistent volume claims under Kubernetes. Fixes [docker/for-mac#7625](https://github.com/docker/for-mac/issues/7625).
+- Fixed a bug where the VM failed to start using Apple virtualization.framework.
+- Minimum version to install or update Docker Desktop on is now macOS Ventura 13.3.
+
+#### For Windows
+
+- Fixed a bug in Enhanced Container Isolation on Windows WSL, where files with hardlinks inside containers had `nobody:nogroup` ownership.
+- Fixed a bug that caused Docker Desktop to crash. Related to [docker/for-win#14782](https://github.com/docker/for-win/issues/14782).
+- Fixed a bug that caused `The network name cannot be found` error when starting with WSL 2. Fixes [docker/for-win#14714](https://github.com/docker/for-win/issues/14714).
+- Fixed an issue where Docker Desktop would not remove entries in the hosts file when uninstalling.
+- Fixed an issue when reading auto-start registry key for some system languages. Fixes [docker/for-win#14731](https://github.com/docker/for-win/issues/14731).
+- Fixed a bug where Docker Desktop was adding unrecognised /etc/wsl.conf `crossDistro` option which was causing WSL 2 to log an error. See [microsoft/WSL#4577](https://github.com/microsoft/WSL/issues/4577)
+- Fixed a bug where Docker Desktop failed to start on WSL 2.5.7 if another WSL distro is still using Linux cgroups v1. Fixes [docker/for-win#14801](https://github.com/docker/for-win/issues/14801)
+- Windows Subsystem for Linux (WSL) version 2.1.5 is now the minimum version required for proper functioning of Docker Desktop application
+
+### Known issues
+
+#### For all platforms
+
+- This release contains a regression with  `docker port`, resulting in "No host port found for host IP" errors when using testcontainers-node. See [testcontainers/testcontainers-node#818](https://github.com/testcontainers/testcontainers-node/issues/818#issuecomment-2941575369)
+
+#### For Windows
+
+- Running containers with Wasm will hang sporadically. See [docker/for-mac#7666](https://github.com/docker/for-mac/issues/7666).
+- On some machines Resource Saver will cause other WSL 2 distros to freeze. The workaround is to disable Resource Saver. See [docker/for-win#14656](https://github.com/docker/for-win/issues/14656).
+
+## 4.41.2
+
+{{< release-date date="2025-05-06" >}}
+
+### Bug fixes and enhancements
+
+#### For all platforms
+
+- Fixed an issue where the `Models` menu was displayed in the GUI even when Docker Model Runner was not supported or not enabled.
 
 ## 4.41.1
 
 {{< release-date date="2025-04-30" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.41.1" build_path="/191279/" >}}
-
 ### Bug fixes and enhancements
 
 #### For all platforms
@@ -49,14 +2013,12 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2025-04-28" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.41.0" build_path="/190950/" >}}
-
 ### New
 
 - Docker Model Runner is now available on x86 Windows machines with NVIDIA GPUs.
 - You can now [push models](/manuals/ai/model-runner.md#push-a-model-to-docker-hub) to Docker Hub with Docker Model Runner.
 - Added support for Docker Model Runner's model management and chat interface in Docker Desktop for Mac and Windows (on hardware supporting Docker Model Runner). Users can now view, interact with, and manage local AI models through a new dedicated interface.
-- [Docker Compose](/manuals/compose/how-tos/model-runner.md) and Testcontainers [Java](https://java.testcontainers.org/modules/docker_model_runner/) and [Go](https://golang.testcontainers.org/modules/dockermodelrunner/) now support Docker Model Runner.
+- [Docker Compose](/manuals/ai/compose/models-and-compose.md) and Testcontainers [Java](https://java.testcontainers.org/modules/docker_model_runner/) and [Go](https://golang.testcontainers.org/modules/dockermodelrunner/) now support Docker Model Runner.
 - Introducing Docker Desktop in the [Microsoft App Store](https://apps.microsoft.com/detail/xp8cbj40xlbwkx?hl=en-GB&gl=GB).
 
 ### Upgrades
@@ -84,7 +2046,7 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 - Improved error messages when downloading Registry Access Management configuration.
 - If Docker can't bind an ICMPv4 socket, it now logs an error and continues rather than quits.
 - Enabled the memory protection keys mechanism in the Docker Desktop Linux VM, allowing containers like Oracle database images to run correctly.
-- Fixed a problem with containers accessing `/proc/sys/kernel/shm*` sysctls when [Enhanced Container Isolation](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md) is enabled on Mac, Windows Hyper-V, or Linux.
+- Fixed a problem with containers accessing `/proc/sys/kernel/shm*` sysctls when [Enhanced Container Isolation](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md) is enabled on Mac, Windows Hyper-V, or Linux.
 - Added kernel module `nft_fib_inet`, required for running firewalld in a Linux container.
 - MacOS QEMU Virtualization option is being deprecated on July 14, 2025.
 
@@ -113,8 +2075,6 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2025-03-31" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.40.0" build_path="/187762/" >}}
-
 ### New
 
 - You can now pull, run, and manage AI models from Docker Hub directly in Docker Desktop with [Docker Model Runner (Beta)](/manuals/ai/model-runner.md). Currently available for Docker Desktop for Mac with Apple Silicon.
@@ -162,12 +2122,10 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2025-03-05" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.39.0" build_path="/184744/" >}}
-
 ### New
 
 - The [Docker Desktop CLI](/manuals/desktop/features/desktop-cli.md) is now generally available. You can now also print logs with the new `docker desktop logs` command.
-- Docker Desktop now supports the `--platform` flag on [`docker load`](/reference/cli/docker/image/load.md) and [`docker save`](/reference/cli/docker/image/save.md). This helps you import and export a subset of multi-platform images.
+- Docker Desktop now supports the `--platform` flag on [`docker load`](/reference/cli/docker/image/load/) and [`docker save`](/reference/cli/docker/image/save/). This helps you import and export a subset of multi-platform images.
 
 ### Upgrades
 
@@ -218,14 +2176,12 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2025-01-30" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.38.0" build_path="/181591/" >}}
-
 ### New
 
 - Installing Docker Desktop via the PKG installer is now generally available.
 - Enforcing sign-in via configuration profiles is now generally available.
 - Docker Compose, Docker Scout, the Docker CLI, and Ask Gordon can now be updated independently of Docker Desktop and without a full restart (Beta).
-- The new [`update` command](/reference/cli/docker/desktop/update.md) has been added to the Docker Desktop CLI (Mac only).
+- The new [`update` command](/reference/cli/docker/desktop/update/) has been added to the Docker Desktop CLI (Mac only).
 - [Bake](/manuals//build/bake/_index.md) is now generally available, with support for entitlements and composable attributes.
 - You can now create [multi-node Kubernetes clusters](/manuals/desktop/settings-and-maintenance/settings.md#kubernetes) in Docker Desktop.
 - [Ask Gordon](/manuals/ai/gordon/_index.md) is more widely available. It is still in Beta.
@@ -247,7 +2203,7 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 #### For all platforms
 
 - Fixed a bug where access tokens generated by the `docker login` web flow could not be refreshed by Docker Desktop.
-- Fixed a bug where container creation via the Docker API using `curl` failed when [Enhanced Container Isolation](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md) was enabled.
+- Fixed a bug where container creation via the Docker API using `curl` failed when [Enhanced Container Isolation](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md) was enabled.
 - Fixed a bug where the RAM policy was not refreshed after the refresh period had elapsed.
 - Fixed a bug in Enhanced Container Isolation when mounting the Docker socket into a container, and then creating Docker containers with bind-mounts from within that container.
 - Fixed an issue that caused a discrepancy between the GUI and the CLI, the former forcing the `0.0.0.0` HostIP in port-mappings. This caused default binding IPs configured through Engine's `ip` flag, or through the bridge option `com.docker.network.bridge.host_binding_ipv4`, to not be used.
@@ -285,8 +2241,6 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2025-01-09" >}}
 
-{{< desktop-install-v2 mac=true version="4.37.2" build_path="/179585/" >}}
-
 ### Bug fixes and enhancements
 
 #### For Mac
@@ -303,14 +2257,12 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2024-12-17" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.37.1" build_path="/178610/" >}}
-
 ### Bug fixes and enhancements
 
 #### For all platforms
 
 - Fixed an issue that caused the AI Catalog in Docker Hub to be unavailable in Docker Desktop.
-- Fixed an issue that caused Docker Desktop to panic with `index out of range [0] with length 0` when using [Enhanced Container Isolation](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md).
+- Fixed an issue that caused Docker Desktop to panic with `index out of range [0] with length 0` when using [Enhanced Container Isolation](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md).
 
 ### Known issues
 
@@ -322,8 +2274,6 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2024-12-12" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.37.0" build_path="/178034/" >}}
-
 ### New
 
 - You can now perform key operations such as starting, stopping, restarting, and checking the status of Docker Desktop directly from the [command line](/manuals/desktop/features/desktop-cli.md) (Beta).
@@ -382,8 +2332,6 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2025-01-09" >}}
 
-{{< desktop-install-v2 mac=true version="4.36.1" build_path="/179655/" >}}
-
 ### Bug fixes and enhancements
 
 #### For Mac
@@ -400,19 +2348,17 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2024-11-18" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.36.0" build_path="/175267/" >}}
-
 ### New
 
 - Existing Docker Desktop installations using the WSL2 engine on Windows are now automatically migrated to a unified single-distribution architecture for enhanced consistency and performance.
 - Administrators can now:
-  - Enforce sign-in with macOS [configuration profiles](/manuals/security/for-admins/enforce-sign-in/methods.md#configuration-profiles-method-mac-only) (Early Access).
+  - Enforce sign-in with macOS [configuration profiles](/manuals/enterprise/security/enforce-sign-in/methods.md#configuration-profiles-method-mac-only) (Early Access).
   - Enforce sign-in for more than one organization at a time (Early Access).
-  - Deploy Docker Desktop for Mac in bulk with the [PKG installer](/manuals/desktop/setup/install/enterprise-deployment/pkg-install-and-configure.md) (Early Access).
+  - Deploy Docker Desktop for Mac in bulk with the [PKG installer](/manuals/enterprise/enterprise-deployment/pkg-install-and-configure.md) (Early Access).
   - Use Desktop Settings Management to manage and enforce defaults via admin.docker.com (Early Access).
 - Enhance Container Isolation (ECI) has been improved to:
-  - Allow admins to [turn off Docker socket mount restrictions](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md#allowing-all-containers-to-mount-the-docker-socket).
-  - Support wildcard tags when using the [`allowedDerivedImages` setting](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md#docker-socket-mount-permissions-for-derived-images).
+  - Allow admins to [turn off Docker socket mount restrictions](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md#allowing-all-containers-to-mount-the-docker-socket).
+  - Support wildcard tags when using the [`allowedDerivedImages` setting](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md#docker-socket-mount-permissions-for-derived-images).
 
 ### Upgrades
 
@@ -462,7 +2408,6 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2025-01-09" >}}
 
-{{< desktop-install-v2 mac=true version="4.35.2" build_path="/179656/" >}}
 
 ### Bug fixes and enhancements
 
@@ -480,8 +2425,6 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2024-10-30" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.35.1" build_path="/173168/" >}}
-
 #### For all platforms
 
 - Fixed a bug where Docker Desktop would incorrectly bind to port `8888`. Fixes [docker/for-win#14389](https://github.com/docker/for-win/issues/14389) and [docker/for-mac#7468](https://github.com/docker/for-mac/issues/7468)
@@ -490,8 +2433,6 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2024-10-24" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.35.0" build_path="/172550/" >}}
-
 ### New
 
 - Support for [Docker Desktop on Red Hat Enterprise Linux](/manuals/desktop/setup/install/linux/rhel.md) is now generally available.
@@ -521,7 +2462,7 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 - Fixed a bug where the **Push to Docker Hub** action in the **Images** view would result in an `invalid tag format` error. Fixes [docker/for-win#14258](https://github.com/docker/for-win/issues/14258).
 - Fixed an issue where Docker Desktop startup failed when ICMPv6 setup was not successful.
 - Added drivers that allow USB/IP to work.
-- Fixed a bug in Enhanced Container Isolation (ECI) [Docker socket mount permissions for derived images](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md) where it was incorrectly denying Docker socket mounts for some images when Docker Desktop uses the containerd image store.
+- Fixed a bug in Enhanced Container Isolation (ECI) [Docker socket mount permissions for derived images](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md) where it was incorrectly denying Docker socket mounts for some images when Docker Desktop uses the containerd image store.
 - Enable `NFT_NUMGEN`, `NFT_FIB_IPV4` and `NFT_FIB_IPV6` kernel modules.
 - Build UI:
   - Highlight build check warnings in the **Completed builds** list.
@@ -529,7 +2470,7 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
   - Image tags added to **Build results** section under the **Info** tab.
 - Improved efficiency of host-side disk utilization for fresh installations on Mac and Linux.
 - Fixed a bug that prevented the Sign in enforcement popup to be triggered when token expires.
-- Fixed a bug where containers would not be displayed in the GUI immediately after signing in when using [enforced sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md).
+- Fixed a bug where containers would not be displayed in the GUI immediately after signing in when using [enforced sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md).
 - `settings.json` has been renamed to `settings-store.json`
 - The host networking feature no longer requires users to be signed-in in order to use it.
 
@@ -566,8 +2507,6 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2025-01-09" >}}
 
-{{< desktop-install-v2 mac=true version="4.34.4" build_path="/179671/" >}}
-
 ### Bug fixes and enhancements
 
 #### For Mac
@@ -584,7 +2523,7 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2024-10-09" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.34.3" build_path="/170107/" >}}
+{{< desktop-install-v2 all=true win_arm_release="Beta" version="4.34.3" build_path="/170107/" >}}
 
 ### Upgrades
 
@@ -600,8 +2539,6 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2024-09-12" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.34.2" build_path="/167172/" >}}
-
 ### Bug fixes and enhancements
 
 #### For all platforms
@@ -617,7 +2554,7 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2024-09-05" >}}
 
-{{< desktop-install-v2 win=true beta_win_arm=true version="4.34.1" build_path="/166053/" >}}
+{{< desktop-install-v2 win=true win_arm_release="Beta" version="4.34.1" build_path="/166053/" >}}
 
 ### Bug fixes and enhancements
 
@@ -629,15 +2566,13 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2024-08-29" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.34.0" build_path="/165256/" >}}
-
 ### New
 
 - [Host networking](/manuals/engine/network/drivers/host.md#docker-desktop) support on Docker Desktop is now generally available.
 - If you authenticate via the CLI, you can now authenticate through a browser-based flow, removing the need for manual PAT generation.
 - Windows now supports automatic reclamation of disk space in Docker Desktop for WSL2 installations [using a managed virtual hard disk](/manuals/desktop/features/wsl/best-practices.md).
-- Deploying Docker Desktop via the [MSI installer](/manuals/desktop/setup/install/enterprise-deployment/msi-install-and-configure.md) is now generally available.
-- Two new methods to [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) (windows registry key and `.plist` file) are now generally available.
+- Deploying Docker Desktop via the [MSI installer](/manuals/enterprise/enterprise-deployment/msi-install-and-configure.md) is now generally available.
+- Two new methods to [enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) (windows registry key and `.plist` file) are now generally available.
 - Fresh installations of Docker Desktop now use the containerd image store by default.
 - [Compose Bridge](/manuals/compose/bridge/_index.md) (Experimental) is now available from the Compose file viewer. Easily convert and deploy your Compose project to a Kubernetes cluster.
 
@@ -684,15 +2619,13 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
   > [!NOTE]
   > Using `docker login` with an address that includes URL path segments is not a documented use case and is considered unsupported. The recommended usage is to specify only a registry hostname, and optionally a port, as the address for `docker login`.
 - When running `docker compose up` and Docker Desktop is in the Resource Saver mode, the command is unresponsive. As a workaround, manually exit the Resource Saving mode and Docker Compose becomes responsive again.
-- When [Enhanced Container Isolation (ECI)](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md) is enabled, Docker Desktop may not enter Resource Saver mode. This will be fixed in a future Docker Desktop release.
-- The new [ECI Docker socket mount permissions for derived images](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md#docker-socket-mount-permissions-for-derived-images) feature does not yet work when Docker Desktop is configured with the  **Use containerd for pulling and storing images**. This will be fixed in the next Docker Desktop release.
+- When [Enhanced Container Isolation (ECI)](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md) is enabled, Docker Desktop may not enter Resource Saver mode. This will be fixed in a future Docker Desktop release.
+- The new [ECI Docker socket mount permissions for derived images](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md#docker-socket-mount-permissions-for-derived-images) feature does not yet work when Docker Desktop is configured with the  **Use containerd for pulling and storing images**. This will be fixed in the next Docker Desktop release.
 
 ## 4.33.2
 
 {{< release-date date="2025-01-09" >}}
 
-{{< desktop-install-v2 mac=true version="4.33.2" build_path="/179689/" >}}
-
 ### Bug fixes and enhancements
 
 #### For Mac
@@ -709,8 +2642,6 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2024-07-31" >}}
 
-{{< desktop-install-v2 win=true beta_win_arm=true version="4.33.0" build_path="/161083/" >}}
-
 ### Bug fixes and enhancements
 
 #### For Windows
@@ -721,11 +2652,11 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
 
 {{< release-date date="2024-07-25" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.33.0" build_path="/160616/" >}}
+{{< desktop-install-v2 all=true win_arm_release="Beta" version="4.33.0" build_path="/160616/" >}}
 
 ### New
 
-- [Docker Debug](/reference/cli/docker/debug.md) is now generally available.
+- [Docker Debug](/reference/cli/docker/debug/) is now generally available.
 - BuildKit now evaluates Dockerfile rules to inform you of potential issues.
 - **Resource Allocation** settings can now be accessed directly from the resource usage data displayed in the Dashboard footer.
 - New and improved experience for [troubleshooting](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md).
@@ -813,7 +2744,6 @@ For more information, see [microsoft/WSL#11794](https://github.com/microsoft/WSL
 
 {{< release-date date="2024-07-04" >}}
 
-{{< desktop-install-v2 all=true beta_win_arm=true version="4.32.0" build_path="/157355/" >}}
 
 ### New
 
@@ -836,7 +2766,7 @@ For more information, see [microsoft/WSL#11794](https://github.com/microsoft/WSL
 
 - Improved instructions for `watch` in the Compose File Viewer
 - Added support for Golang projects that don't have dependencies in Docker Init. Addresses [docker/roadmap#611](https://github.com/docker/roadmap/issues/611)
-- [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md) now lets admins set the default value to `ProxyEnableKerberosNTLM`.
+- [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md) now lets admins set the default value to `ProxyEnableKerberosNTLM`.
 - Removed a temporary compatibility fix for older versions of Visual Studio Code.
 - Builds view:
   - Changed icon for imported build record to a "files" icon.
@@ -881,10 +2811,6 @@ For more information, see [microsoft/WSL#11794](https://github.com/microsoft/WSL
 
 ## 4.31.1
 
-{{< release-date date="2024-06-10" >}}
-
-{{< desktop-install win=true beta_win_arm=true version="4.31.1" build_path="/153621/" >}}
-
 ### Bug fixes and enhancements
 
 #### For Windows
@@ -893,13 +2819,9 @@ For more information, see [microsoft/WSL#11794](https://github.com/microsoft/WSL
 
 ## 4.31.0
 
-{{< release-date date="2024-06-06" >}}
-
-{{< desktop-install all=true beta_win_arm=true version="4.31.0" build_path="/153195/" >}}
-
 ### New
 
-- [Air-Gapped Containers](/manuals/security/for-admins/hardened-desktop/air-gapped-containers.md) is now generally available.
+- [Air-Gapped Containers](/manuals/enterprise/security/hardened-desktop/air-gapped-containers.md) is now generally available.
 - Docker Compose File Viewer shows your Compose YAML with syntax highlighting and contextual links to relevant docs (Beta, progressive rollout).
 - New Sidebar user experience.
 
@@ -923,7 +2845,7 @@ For more information, see [microsoft/WSL#11794](https://github.com/microsoft/WSL
 - Added `proxyEnableKerberosNTLM` config to `settings.json` to enable fallback to basic proxy authentication if Kerberos/NTLM environment is not properly set up.
 - Fixed a bug where Docker Debug was not working properly with Enhanced Container Isolation enabled.
 - Fixed a bug where UDP responses were not truncated properly.
-- Fixed a bug where the **Update** screen was hidden when using [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md).
+- Fixed a bug where the **Update** screen was hidden when using [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md).
 - Fixed a bug where proxy settings defined in `admin-settings.json` were not applied correctly on startup.
 - Fixed a bug where the **Manage Synchronized file shares with Compose** toggle did not correctly reflect the value with the feature.
 - Fixed a bug where a bind mounted file modified on host is not updated after the container restarts, when gRPC FUSE file sharing is used on macOS and on Windows with Hyper-V. Fixes [docker/for-mac#7274](https://github.com/docker/for-mac/issues/7274), [docker/for-win#14060](https://github.com/docker/for-win/issues/14060).
@@ -981,14 +2903,12 @@ For more information, see [microsoft/WSL#11794](https://github.com/microsoft/WSL
 
 {{< release-date date="2024-05-06" >}}
 
-{{< desktop-install all=true beta_win_arm=true version="4.30.0" build_path="/149282/" >}}
-
 ### New
 
 #### For all platforms
 
 - Docker Desktop now supports [SOCKS5 proxies](/manuals/desktop/features/networking.md#socks5-proxy-support). Requires a Business subscription.
-- Added a new setting to manage the onboarding survey in [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md).
+- Added a new setting to manage the onboarding survey in [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md).
 
 #### For Windows
 
@@ -1063,18 +2983,16 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 
 {{< release-date date="2024-04-08" >}}
 
-{{< desktop-install all=true beta_win_arm=true version="4.29.0" build_path="/145265/" >}}
-
 ### New
 
-- You can now enforce Rosetta usage via [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md).
-- [Docker socket mount restrictions](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md) with ECI is now generally available.
+- You can now enforce Rosetta usage via [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md).
+- [Docker socket mount restrictions](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md) with ECI is now generally available.
 - Docker Engine and CLI updated to [Moby 26.0](https://github.com/moby/moby/releases/tag/v26.0.0). This includes Buildkit 0.13, sub volumes mounts, networking updates, and improvements to the containerd multi-platform image store UX.
 - New and improved Docker Desktop error screens: swift troubleshooting, easy diagnostics uploads, and actionable remediation.
 - Compose supports [Synchronized file shares (experimental)](/manuals/desktop/features/synchronized-file-sharing.md).
 - New [interactive Compose CLI (experimental)](/manuals/compose/how-tos/environment-variables/envvars.md#compose_menu).
 - Beta release of:
-  - Air-Gapped Containers with [Settings Management](/manuals/security/for-admins/hardened-desktop/air-gapped-containers/_index.md).
+  - Air-Gapped Containers with [Settings Management](/manuals/enterprise/security/hardened-desktop/air-gapped-containers.md).
   - [Host networking](/manuals/engine/network/drivers/host.md#docker-desktop) in Docker Desktop.
   - [Docker Debug](use-desktop/container.md#integrated-terminal) for running containers.
   - [Volumes Backup & Share extension](use-desktop/volumes.md) functionality available in the **Volumes** tab.
@@ -1145,7 +3063,7 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 
 ### New
 
-- [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md) now allows admins to set the default file-sharing implementation and specify which paths developer can add file shares to.
+- [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md) now allows admins to set the default file-sharing implementation and specify which paths developer can add file shares to.
 - Added support for `socks5://` HTTP and HTTPS proxy URLs when the [`SOCKS` proxy support beta feature](/manuals/desktop/features/networking.md) is enabled.
 - Users can now filter volumes to see which ones are in use in the **Volumes** tab.
 
@@ -1264,9 +3182,9 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 
 - Docker init now supports Java and is generally available to all users.
 - [Synchronized File Shares](/manuals/desktop/features/synchronized-file-sharing.md) provides fast and flexible host-to-VM file sharing within Docker Desktop. Utilizing the technology behind [Docker’s acquisition of Mutagen](https://www.docker.com/blog/mutagen-acquisition/), this feature provides an alternative to virtual bind mounts that uses synchronized filesystem caches, improving performance for developers working with large codebases.
-- Organization admins can now [configure Docker socket mount permissions](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md) when ECI is enabled.
+- Organization admins can now [configure Docker socket mount permissions](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md) when ECI is enabled.
 - [Containerd Image Store](/manuals/desktop/features/containerd.md) support is now generally available to all users.
-- Get a debug shell into any container or image with the new [`docker debug` command](/reference/cli/docker/debug.md) (Beta).
+- Get a debug shell into any container or image with the new [`docker debug` command](/reference/cli/docker/debug/) (Beta).
 - Organization admins, with a Docker Business subscription, can now configure a custom list of extensions with [Private Extensions Marketplace](/manuals/extensions/private-marketplace.md) enabled (Beta)
 
 ### Upgrades
@@ -1285,7 +3203,7 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 
 #### For all platforms
 
-- The `docker scan` command has been removed. To continue learning about the vulnerabilities of your images, and many other features, use the [`docker scout` command](/reference/cli/docker/scout/_index.md).
+- The `docker scan` command has been removed. To continue learning about the vulnerabilities of your images, and many other features, use the [`docker scout` command](/reference/cli/docker/scout/).
 - Fixed a bug where automatic updates would not download when the **Always download updates** checkbox was selected.
 - Fixed typo in the dashboard tooltip. Fixes [docker/for-mac#7132](https://github.com/docker/for-mac/issues/7132)
 - Improved signal handling behavior (e.g. when pressing Ctrl-C in the terminal while running a `docker` command).
@@ -1365,7 +3283,7 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 
 ### New
 
-- Administrators can now control access to beta and experimental features in the **Features in development** tab with [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md).
+- Administrators can now control access to beta and experimental features in the **Features in development** tab with [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md).
 - Introduced four new version update states in the footer.
 - `docker init` (Beta) now supports PHP with Apache + Composer.
 - The [**Builds** view](use-desktop/builds.md) is now GA. You can now inspect builds, troubleshoot errors, and optimize build speed.
@@ -1475,7 +3393,7 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 - Rosetta is now Generally Available for all users on macOS 13 or later. It provides faster emulation of Intel-based images on Apple Silicon. To use Rosetta, see [Settings](/manuals/desktop/settings-and-maintenance/settings.md). Rosetta is enabled by default on macOS 14.1 and later.
 - Docker Desktop now detects if a WSL version is out of date. If an out dated version of WSL is detected, you can allow Docker Desktop to automatically update the installation or you can manually update WSL outside of Docker Desktop.
 - New installations of Docker Desktop for Windows now require a Windows version of 19044 or later.
-- Administrators now have the ability to control Docker Scout image analysis in [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md).
+- Administrators now have the ability to control Docker Scout image analysis in [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md).
 
 ### Upgrades
 
@@ -1554,8 +3472,6 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 
 {{< release-date date="2023-10-04" >}}
 
-{{< desktop-install win=true version="4.24.1" build_path="/123237/" >}}
-
 ### Bug fixes and enhancements
 
 #### For Windows
@@ -1645,12 +3561,12 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 ### New
 
 - Added support for new Wasm runtimes: wws and lunatic.
-- [`docker init`](/reference/cli/docker/init.md) now supports ASP.NET
+- [`docker init`](/reference/cli/docker/init/) now supports ASP.NET
 - Increased performance of exposed ports on macOS, for example with `docker run -p`.
 
 ### Removed
 
-- Removed Compose V1 from Docker Desktop as it has stopped receiving updates.  Compose V2 has replaced it and is now integrated into all current Docker Desktop versions. For more information, see [Migrate to Compose V2](/manuals/compose/releases/migrate.md).
+- Removed Compose V1 from Docker Desktop as it has stopped receiving updates.  Compose V2 has replaced it and is now integrated into all current Docker Desktop versions.
 
 ### Bug fixes and enhancements
 
@@ -1738,7 +3654,7 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 
 #### For all platforms
 
-- [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md) now lets you turn off Docker Extensions for your organisation.
+- [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md) now lets you turn off Docker Extensions for your organisation.
 - Fixed a bug where turning on Kubernetes from the UI failed when the system was paused.
 - Fixed a bug where turning on Wasm from the UI failed when the system was paused.
 - Bind mounts are now shown when you [inspect a container](use-desktop/container.md).
@@ -1896,7 +3812,7 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 
 ### Removed
 
-- Removed `docker scan` command. To continue learning about the vulnerabilities of your images, and many other features, use the new `docker scout` command. Run `docker scout --help`, or [read the docs to learn more](/reference/cli/docker/scout/_index.md).
+- Removed `docker scan` command. To continue learning about the vulnerabilities of your images, and many other features, use the new `docker scout` command. Run `docker scout --help`, or [read the docs to learn more](/reference/cli/docker/scout/).
 
 ### Upgrades
 
@@ -1915,7 +3831,7 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 - Added more details to dashboard errors when a `docker-compose` action fails ([docker/for-win#13378](https://github.com/docker/for-win/issues/13378)).
 - Added support for setting HTTP proxy configuration during installation. This can be done via the `--proxy-http-mode`, `--overrider-proxy-http`, `--override-proxy-https` and `--override-proxy-exclude` installer flags in the case of installation from the CLI on [Mac](/manuals/desktop/setup/install/mac-install.md#install-from-the-command-line) and [Windows](/manuals/desktop/setup/install/windows-install.md#install-from-the-command-line), or alternatively by setting the values in the `install-settings.json` file.
 - Docker Desktop now stops overriding .docker/config.json `credsStore` keys on application start. Note that if you use a custom credential helper then the CLI `docker login` and `docker logout` does not affect whether the UI is signed in to Docker or not. In general, it is better to sign into Docker via the UI since the UI supports multi-factor authentication.
-- Added a warning about the [forthcoming removal of Compose V1 from Docker Desktop](/manuals/compose/releases/migrate.md). Can be suppressed with `COMPOSE_V1_EOL_SILENT=1`.
+- Added a warning about the forthcoming removal of Compose V1 from Docker Desktop. Can be suppressed with `COMPOSE_V1_EOL_SILENT=1`.
 - In the Compose config, boolean fields in YAML should be either `true` or `false`. Deprecated YAML 1.1 values such as “on” or “no” now produce a warning.
 - Improved UI for image table, allowing rows to use more available space.
 - Fixed various bugs in port-forwarding.
@@ -1990,7 +3906,7 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 - Fixed a bug where `docker run --gpus=all` hangs. Fixes [docker/for-win#13324](https://github.com/docker/for-win/issues/13324).
 - Fixed a bug where Registry Access Management policy updates were not downloaded.
 - Docker Desktop now allows Windows containers to work when BitLocker is enabled on `C:`.
-- Docker Desktop with the WSL backend no longer requires the `com.docker.service` privileged service to run permanently. For more information see [Permission requirements for Windows](https://docs.docker.com/desktop/windows/permission-requirements/).
+- Docker Desktop with the WSL backend no longer requires the `com.docker.service` privileged service to run permanently. For more information see [Permission requirements for Windows](/manuals/desktop/setup/install/windows-permission-requirements.md).
 
 ### For Mac
 
@@ -2370,7 +4286,7 @@ This can be resolved by adding the user to the **docker-users** group. Before st
 
 ### New
 
-- Two new security features have been introduced for Docker Business users, Settings Management and Enhanced Container Isolation. Read more about Docker Desktop’s new [Hardened Docker Desktop security model](/manuals/security/for-admins/hardened-desktop/_index.md).
+- Two new security features have been introduced for Docker Business users, Settings Management and Enhanced Container Isolation. Read more about Docker Desktop’s new [Hardened Docker Desktop security model](/manuals/enterprise/security/hardened-desktop/_index.md).
 - Added the new Dev Environments CLI `docker dev`, so you can create, list, and run Dev Envs via command line. Now it's easier to integrate Dev Envs into custom scripts.
 - Docker Desktop can now be installed to any drive and folder using the `--installation-dir`. Partially addresses [docker/roadmap#94](https://github.com/docker/roadmap/issues/94).
 
@@ -3067,7 +4983,7 @@ Installing Docker Desktop 4.5.0 from scratch has a bug which defaults Docker Des
 ### New
 
 - Easy, Secure sign in with Auth0 and Single Sign-on
-  - Single Sign-on: Users with a Docker Business subscription can now configure SSO to authenticate using their identity providers (IdPs) to access Docker. For more information, see [Single Sign-on](../security/for-admins/single-sign-on/_index.md).
+  - Single Sign-on: Users with a Docker Business subscription can now configure SSO to authenticate using their identity providers (IdPs) to access Docker. For more information, see [Single Sign-on](/manuals/enterprise/security/single-sign-on/_index.md).
   - Signing in to Docker Desktop now takes you through the browser so that you get all the benefits of auto-filling from password managers.
 
 ### Upgrades
@@ -3193,7 +5109,7 @@ CVE-2021-44228](https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/).
 
 Docker Desktop Dashboard incorrectly displays the container memory usage as zero on
 Hyper-V based machines.
-You can use the [`docker stats`](/reference/cli/docker/container/stats.md)
+You can use the [`docker stats`](/reference/cli/docker/container/stats/)
 command on the command line as a workaround to view the
 actual memory usage. See
 [docker/for-mac#6076](https://github.com/docker/for-mac/issues/6076).
diff --git a/content/manuals/desktop/settings-and-maintenance/backup-and-restore.md b/content/manuals/desktop/settings-and-maintenance/backup-and-restore.md
index 4ada95b5fda3..292b5d4d9047 100644
--- a/content/manuals/desktop/settings-and-maintenance/backup-and-restore.md
+++ b/content/manuals/desktop/settings-and-maintenance/backup-and-restore.md
@@ -8,15 +8,17 @@ aliases:
  - /desktop/backup-and-restore/
 ---
 
-Use this procedure to back up and restore your images and container data. This is useful if you want to reset your VM disk or to move your Docker environment to a new computer.
+Use this procedure to back up and restore your images and container data. This is useful if you want to reset your VM disk or to move your Docker environment to a new computer, or recover from a failed Docker Desktop update or installation.
 
 > [!IMPORTANT]
 >
 > If you use volumes or bind-mounts to store your container data, backing up your containers may not be needed, but make sure to remember the options that were used when creating the container or use a [Docker Compose file](/reference/compose-file/_index.md) if you want to re-create your containers with the same configuration after re-installation.
 
-## Save your data
+## If Docker Desktop is functioning normally
 
-1. Commit your containers to an image with [`docker container commit`](/reference/cli/docker/container/commit.md).
+### Save your data
+
+1. Commit your containers to an image with [`docker container commit`](/reference/cli/docker/container/commit/).
 
    Committing a container stores filesystem changes and some container configurations, such as labels and environment variables, as a local image. Be aware that environment variables may contain sensitive
    information such as passwords or proxy-authentication, so take care when pushing the resulting image to a registry.
@@ -26,20 +28,20 @@ Use this procedure to back up and restore your images and container data. This i
 
    If you used a [named volume](/manuals/engine/storage/_index.md#more-details-about-mount-types) to store container data, such as databases, refer to the [back up, restore, or migrate data volumes](/manuals/engine/storage/volumes.md#back-up-restore-or-migrate-data-volumes) page in the storage section.
 
-2. Use [`docker push`](/reference/cli/docker/image/push.md) to push any
+2. Use [`docker push`](/reference/cli/docker/image/push/) to push any
    images you have built locally and want to keep to the [Docker Hub registry](/manuals/docker-hub/_index.md).
    
    > [!TIP]
    >
    > [Set the repository visibility to private](/manuals/docker-hub/repos/_index.md) if your image includes sensitive content.
 
-   Alternatively, use [`docker image save -o images.tar image1 [image2 ...]`](/reference/cli/docker/image/save.md)
+   Alternatively, use [`docker image save -o images.tar image1 [image2 ...]`](/reference/cli/docker/image/save/)
    to save any images you want to keep to a local `.tar` file. 
 
 After backing up your data, you can uninstall the current version of Docker Desktop
 and [install a different version](/manuals/desktop/release-notes.md) or reset Docker Desktop to factory defaults.
 
-## Restore your data
+### Restore your data
 
 1. Load your images.
 
@@ -55,7 +57,73 @@ and [install a different version](/manuals/desktop/release-notes.md) or reset Do
       $ docker image load -i images.tar
       ```
 
-2. Re-create your containers if needed, using [`docker run`](/reference/cli/docker/container/run.md),
+2. Re-create your containers if needed, using [`docker run`](/reference/cli/docker/container/run/),
    or [Docker Compose](/manuals/compose/_index.md).
 
 To restore volume data, refer to [backup, restore, or migrate data volumes](/manuals/engine/storage/volumes.md#back-up-restore-or-migrate-data-volumes). 
+
+## If Docker Desktop fails to start or you want to back up the whole Docker Desktop VM
+
+If Docker Desktop cannot launch and must be reinstalled, you can back up its VM disk and image data directly from disk. Docker Desktop must be fully stopped before backing up these files.
+
+{{< tabs >}}
+{{< tab name="Windows" >}}
+
+1. Back up Docker containers/images.
+
+   Backup the following file:
+
+   ```console
+   %LOCALAPPDATA%\Docker\wsl\data\docker_data.vhdx
+   ```
+
+   Copy it to a safe location. 
+
+1. Back up WSL distributions.
+
+   If you're running any WSL Linux distributions (Ubuntu, Alpine, etc.), back them up using [Microsoft's guide](https://learn.microsoft.com/en-us/windows/wsl/faq#how-can-i-back-up-my-wsl-distributions-).
+
+1. Restore. 
+
+   After reinstalling Docker Desktop, restore the `docker_data.vhdx` to the same location and re-import your WSL distributions if needed.
+
+{{< /tab >}}
+{{< tab name="Mac" >}}
+
+1. Back up Docker containers/images.
+
+   Backup the following file:
+
+   ```console
+   ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
+   ```
+
+   Copy it to a safe location. 
+
+   > [!TIP]
+   >
+   > To include Docker Desktop data in Time Machine backups, make sure the `~/Library/Containers/com.docker.docker` directory is not excluded from your Time Machine backup configuration.
+
+1. Restore. 
+
+   After reinstalling Docker Desktop, restore the `Docker.raw` to the same location.
+
+{{< /tab >}}
+{{< tab name="Linux" >}}
+
+1. Back up Docker containers/images:
+
+   Backup the following file:
+
+   ```console
+   ~/.docker/desktop/vms/0/data/Docker.raw
+   ```
+
+   Copy it to a safe location.
+
+1. Restore. 
+
+   After reinstalling Docker Desktop, restore the `Docker.raw` to the same location.
+
+{{< /tab >}}
+{{< /tabs >}}
\ No newline at end of file
diff --git a/content/manuals/desktop/settings-and-maintenance/settings.md b/content/manuals/desktop/settings-and-maintenance/settings.md
index 662d07d83df9..32f91f922ed2 100644
--- a/content/manuals/desktop/settings-and-maintenance/settings.md
+++ b/content/manuals/desktop/settings-and-maintenance/settings.md
@@ -12,349 +12,196 @@ aliases:
 weight: 10
 ---
 
-To navigate to **Settings** either:
+Customize Docker Desktop behavior and optimize performance and resource usage with Docker Desktop's settings.
+
+To open **Settings** either:
 
 - Select the Docker menu {{< inline-image src="../images/whale-x.svg" alt="whale menu" >}} and then **Settings**
 - Select the **Settings** icon from the Docker Desktop Dashboard.
 
-You can also locate the `settings-store.json` file (or `settings.json` for Docker Desktop versions 4.34 and earlier) at:
+You can also locate the `settings-store.json` file at:
  - Mac: `~/Library/Group\ Containers/group.com.docker/settings-store.json`
  - Windows: `C:\Users\[USERNAME]\AppData\Roaming\Docker\settings-store.json`
  - Linux: `~/.docker/desktop/settings-store.json`
 
-## General
-
-On the **General** tab, you can configure when to start Docker and specify other settings:
-
-- **Start Docker Desktop when you sign in to your computer**. Select to automatically start Docker
-  Desktop when you sign in to your machine.
-
-- **Open Docker Dashboard when Docker Desktop starts**. Select to automatically open the
-  dashboard when starting Docker Desktop.
-
-- **Choose theme for Docker Desktop**. Choose whether you want to apply a **Light** or **Dark** theme to Docker Desktop. Alternatively you can set Docker Desktop to **Use system settings**.
-
-- **Configure shell completions**. Automatically edits your shell configuration and gives you word completion for commands, flags, and Docker objects (such as container and volume names) when you hit `<Tab>` as you type into your terminal. For more information, see [Completion](/manuals/engine/cli/completion.md).
-
-- **Choose container terminal**. Determines which terminal is launched when opening the terminal from a container.
-If you choose the integrated terminal, you can run commands in a running container straight from the Docker Desktop Dashboard. For more information, see [Explore containers](/manuals/desktop/use-desktop/container.md).
-
-- **Enable Docker terminal**. Interact with your host machine and execute commands directly from Docker Desktop.
-
-- **Enable Docker Debug by default**. Check this option to use Docker Debug by default when accessing the integrated terminal. For more information, see [Explore containers](/manuals/desktop/use-desktop/container.md#integrated-terminal).
-
-- {{< badge color=blue text="Mac only" >}}**Include VM in Time Machine backups**. Select to back up the Docker Desktop
-  virtual machine. This option is turned off by default.
-
-- **Use containerd for pulling and storing images**.
-  Turns on the containerd image store.
-  This brings new features like faster container startup performance by lazy-pulling images,
-  and the ability to run Wasm applications with Docker.
-  For more information, see [containerd image store](/manuals/desktop/features/containerd.md).
-
-- {{< badge color=blue text="Windows only" >}}**Expose daemon on tcp://localhost:2375 without TLS**. Check this option to
-  enable legacy clients to connect to the Docker daemon. You must use this option
-  with caution as exposing the daemon without TLS can result in remote code
-  execution attacks.
-
-- {{< badge color=blue text="Windows only" >}}**Use the WSL 2 based engine**. WSL 2 provides better performance than the
-  Hyper-V backend. For more information, see [Docker Desktop WSL 2 backend](/manuals/desktop/features/wsl/_index.md).
-
-- {{< badge color=blue text="Windows only" >}}**Add the `*.docker.internal` names to the host's `/etc/hosts` file (Password required)**. Lets you resolve `*.docker.internal` DNS names from both the host and your containers.
-
-- {{< badge color=blue text="Mac only" >}} **Choose Virtual Machine Manager (VMM)**. Choose the Virtual Machine Manager for creating and managing the Docker Desktop Linux VM.
-  - Select **Docker VMM** for the latest and most performant Hypervisor/Virtual Machine Manager. This option is available only on Apple Silicon Macs running macOS 12.5 or later and is currently in Beta.
-    > [!TIP]
-    >
-    > Turn this setting on to make Docker Desktop run faster.
-  - Alternatively, you can choose **Apple Virtualization framework**, **QEMU** (for Apple Silicon), or **HyperKit** (for Intel Macs). For macOS 12.5 and later, Apple Virtualization framework is the default setting.
-
-   For more information, see [Virtual Machine Manager](/manuals/desktop/features/vmm.md).
-
-- {{< badge color=blue text="Mac only" >}}**Choose file sharing implementation for your containers**. Choose whether you want to share files using **VirtioFS**, **gRPC FUSE**, or **osxfs (Legacy)**. VirtioFS is only available for macOS 12.5 and later, and is turned on by default.
-    > [!TIP]
-    >
-    > Use VirtioFS for speedy file sharing. VirtioFS has reduced the time taken to complete filesystem operations by [up to 98%](https://github.com/docker/roadmap/issues/7#issuecomment-1044452206). It is the only file sharing implementation supported by Docker VMM.
-
-- {{< badge color=blue text="Mac only" >}}**Use Rosetta for x86_64/amd64 emulation on Apple Silicon**. Turns on Rosetta to accelerate x86/AMD64 binary emulation on Apple Silicon. This option is only available if you have selected **Apple Virtualization framework** as the Virtual Machine Manager. You must also be on macOS 13 or later.
-
-- **Send usage statistics**. Select so Docker Desktop sends diagnostics,
-  crash reports, and usage data. This information helps Docker improve and
-  troubleshoot the application. Clear the checkbox to opt out. Docker may
-  periodically prompt you for more information.
-
-- **Use Enhanced Container Isolation**. Select to enhance security by preventing containers from breaching the Linux VM. For more information, see [Enhanced Container Isolation](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md).
-    > [!NOTE]
-    >
-    > This setting is only available if you are signed in to Docker Desktop and have a Docker Business subscription.
-
-- **Show CLI hints**. Displays CLI hints and tips when running Docker commands in the CLI. This is turned on by default. To turn CLI hints on or off from the CLI, set `DOCKER_CLI_HINTS` to `true` or `false` respectively.
-
-- **Enable Scout image analysis**. When this option is enabled, inspecting an image in Docker Desktop shows a **Start analysis** button that, when selected, analyzes the image with Docker Scout.
+For information on enforcing settings at an organization level, see [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/settings-reference.md).
 
-- **Enable background SBOM indexing**. When this option is enabled, Docker Scout automatically analyzes images that you build or pull.
-
-- {{< badge color=blue text="Mac only" >}}**Automatically check configuration**. Regularly checks your configuration to ensure no unexpected changes have been made by another application.
+## General
 
-  Docker Desktop checks if your setup, configured during installation, has been altered by external apps like Orbstack. Docker Desktop checks:
-    - The symlinks of Docker binaries to `/usr/local/bin`.
-    - The symlink of the default Docker socket. 
-  Additionally, Docker Desktop ensures that the context is switched to `desktop-linux` on startup.
-  
-  You are notified if changes are found and are able to restore the configuration directly from the notification. For more information, see the [FAQs](/manuals/desktop/troubleshoot-and-support/faqs/macfaqs.md#why-do-i-keep-getting-a-notification-telling-me-an-application-has-changed-my-desktop-configurations).
+Configure startup behavior, UI appearance, terminal preferences, and feature defaults for Docker Desktop.
+
+| Setting                                                           | Description                                                                | Default            | Platform     | Notes                                 |
+| ----------------------------------------------------------------- | -------------------------------------------------------------------------- | ------------------ | ------------ | ------------------------------------- |
+| **Start Docker Desktop when you sign in to your computer**        | Automatically start Docker Desktop when you sign in to your machine.        | Disabled           | All          | Recommended for frequent users.        |
+| **Open Docker Dashboard when Docker Desktop starts**              | Automatically open the dashboard when starting Docker Desktop.              | Disabled           | All          |                                       |
+| **Choose theme for Docker Desktop**                               | Apply a **Light** or **Dark** theme to Docker Desktop. | **Use system settings**. | All |                                   |
+| **Configure shell completions**                                  | Edits your shell configuration to enable word completion for commands, flags, and Docker objects when you press `<Tab>` in your terminal. For more information, see [Completion](/manuals/engine/cli/completion.md). | Disabled | All | |
+| **Choose container terminal** | Sets which terminal opens when you select a container terminal. Use the integrated terminal to run commands in a running container from the Dashboard. For more information, see [Explore containers](/manuals/desktop/use-desktop/container.md). | Disabled | All | |
+| **Enable Docker terminal**.                                       | Interact with your host machine and execute commands directly from Docker Desktop.  | Disabled | All | |
+| **Enable Docker Debug by default**                                | Use Docker Debug by default opening the integrated terminal. For more information, see [Explore containers](/manuals/desktop/use-desktop/container.md#integrated-terminal).   | Disabled | All | |
+| **Include VM in Time Machine backups**                            | Back up the Docker Desktop virtual machine. | Disabled | Mac | |
+| **Use containerd for pulling and storing images**     | Uses containerd image store instead of classic image store. For more information, see [containerd image store](/manuals/desktop/features/containerd.md).| Enabled  | All   |           |
+| **Expose daemon on tcp://localhost:2375 without TLS** | Allow legacy clients to connect to the Docker daemon. Use with caution as exposing the daemon without TLS can result in remote code execution attacks. | Disabled                  | Windows (Hyper-V backend only) | |
+| **Use the WSL 2 based engine** | WSL 2 provides better performance than the Hyper-V backend. For more information, see [Docker Desktop WSL 2 backend](/manuals/desktop/features/wsl/_index.md). | Disabled | Windows | |
+| **Add \*.docker.internal to host file**                | Adds internal DNS entries.                                  | Enabled                   | Windows                        | Helps resolve Docker-internal domains |
+| **Choose Virtual Machine Manager (VMM)**              | Choose the VMM for creating and managing the Docker Desktop Linux VM. For more information, see [Virtual Machine Manager](/manuals/desktop/features/vmm.md). | | Mac, Windows | Select **Docker VMM** for optimized container performance. Docker VMM is in Beta. |
+| **Choose file sharing implementation for your containers** | Choose whether you want to share files using **VirtioFS**, or **gRPC FUSE** | **VirtioFS** | Mac | Use VirtioFS for speedy file sharing. VirtioFS has reduced the time taken to complete filesystem operations by [up to 98%](https://github.com/docker/roadmap/issues/7#issuecomment-1044452206). It is the only file sharing implementation supported by Docker VMM. |
+|**Use Rosetta for x86_64/amd64 emulation on Apple Silicon** | Accelerate x86/AMD64 binary emulation on Apple Silicon. This option is only available if you have selected **Apple Virtualization framework** as the Virtual Machine Manager. | Disabled | Mac | |
+| **Send usage statistics** | Send diagnostics, crash reports, and usage data to Docker to improve and troubleshoot the application. Docker may periodically prompt you for more information. | Enabled | All | |
+| **Use Enhanced Container Isolation** | Prevent containers from breaching the Linux VM. For more information, see [Enhanced Container Isolation](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md). | Disabled | All | Must be signed in and have a Docker Business subscription. |
+| **Show CLI hints**                                   | Display helpful CLI suggestions in terminal.               | Enabled                  | All        | Improves discoverability              |
+| **Enable Docker Scout image analysis**                | Show a **Start analysis** button when inspecting an image, which analyzes the image with Docker Scout.         | Enabled                   | All   | |
+| **Enable background SBOM indexing** | Automatically analyze images that you build or pull. | Disabled | All | |
+| **Automatically check configuration** | Regularly check your configuration to ensure no unexpected changes have been made by another application. Notifies you if changes are found with the option to restore the configuration directly from the notification. For more information, see the [FAQs](/manuals/desktop/troubleshoot-and-support/faqs/macfaqs.md#why-do-i-keep-getting-a-notification-telling-me-an-application-has-changed-my-desktop-configurations). | Enabled | Mac | Docker Desktop checks if your setup, configured during installation, has been altered by external apps like Orbstack. Docker Desktop checks the symlinks of Docker binaries to `/usr/local/bin` and the symlink of the default Docker socket. Additionally, Docker Desktop ensures that the context is switched to `desktop-linux` on startup. |
 
 ## Resources
 
-The **Resources** tab allows you to configure CPU, memory, disk, proxies,
-network, and other resources.
+Control the CPU, memory, disk, file sharing, proxy, and network resources available to Docker Desktop.
 
 ### Advanced
 
-> [!NOTE]
->
-> On Windows, the **Resource allocation** options in the **Advanced** tab are only available in Hyper-V mode, because Windows manages
-> the resources in WSL 2 mode and Windows container mode. In WSL 2
-> mode, you can configure limits on the memory, CPU, and swap size allocated
-> to the [WSL 2 utility VM](https://docs.microsoft.com/en-us/windows/wsl/wsl-config#configure-global-options-with-wslconfig).
-
-On the **Advanced** tab, you can limit resources available to the Docker Linux VM.
-
-Advanced settings are:
+| Setting             | Description                               | Platform | Notes                                 |
+| ------------------- | ----------------------------------------- | -------- | ------------------------------------- |
+| **CPU limit** | Specify the maximum number of CPUs to be used by Docker Desktop. | Mac, Linux, Windows Hyper-V | |
+| **Memory limit** | RAM allocated to the Docker VM | Mac, Linux, Windows Hyper-V | Defaults to 50% of your host's memory. |
+| **Swap** | Configure swap file size as needed. | Mac, Linux, Windows Hyper-V | 1 GB default. |
+| **Disk usage limit** | Specify the maximum amount of disk space the engine can use. | Mac, Linux, Windows Hyper-V | |
+|  **Disk image location** | Specify the location of the Linux volume where containers and images are stored. On the **Advanced** tab, you can limit resources available to the Docker Linux VM. | Mac, Linux, Windows Hyper-V | You can also move the disk image to a different location. If you attempt to move a disk image to a location that already has one, you are asked if you want to use the existing image or replace it. |
+| **Resource Saver** | Enable or disable [Resource Saver mode](/manuals/desktop/use-desktop/resource-saver.md), which significantly reduces CPU and memory utilization on the host by automatically turning off the Linux VM when Docker Desktop is idle. | Mac, Linux, Windows Hyper-V | Restarts automatically when containers run. Restart may take 3–10 seconds. |
 
-- **CPU limit**. Specify the maximum number of CPUs to be used by Docker Desktop.
-  By default, Docker Desktop is set to use all the processors available on the host machine.
+In WSL 2 mode, configure memory, CPU, and swap limits on the [WSL 2 utility VM](https://docs.microsoft.com/en-us/windows/wsl/wsl-config#configure-global-options-with-wslconfig).
 
-- **Memory limit**. By default, Docker Desktop is set to use up to 50% of your host's
-  memory. To increase the RAM, set this to a higher number; to decrease it,
-  lower the number.
-
-- **Swap**. Configure swap file size as needed. The default is 1 GB.
-
-- **Disk usage limit**. Specify the maximum amount of disk space the engine can use.
-
-- **Disk image location**. Specify the location of the Linux volume where containers and images are stored.
-
-  You can also move the disk image to a different location. If you attempt to
-  move a disk image to a location that already has one, you are asked if you
-  want to use the existing image or replace it.
-
->[!TIP]
+> [!TIP]
 >
 > If you feel Docker Desktop starting to get slow or you're running
-> multi-container workloads, increase the memory and disk image space allocation
-
-- **Resource Saver**. Enable or disable [Resource Saver mode](/manuals/desktop/use-desktop/resource-saver.md),
-  which significantly reduces CPU and memory utilization on the host by
-  automatically turning off the Linux VM when Docker Desktop is idle (i.e., no
-  containers are running).
-
-  You can also configure the Resource Saver timeout which indicates how long
-  should Docker Desktop be idle before Resource Saver mode kicks in. Default is
-  5 minutes.
-
-  > [!NOTE]
-  >
-  > Exit from Resource Saver mode occurs automatically when containers run. Exit
-  > may take a few seconds (~3 to 10 secs) as Docker Desktop restarts the Linux VM.
-
+> multi-container workloads, increase the memory and disk image space allocation.
 
 ### File sharing
 
-> [!NOTE]
->
-> On Windows, the **File sharing** tab is only available in Hyper-V mode because the files
-> are automatically shared in WSL 2 mode and Windows container mode.
-
 Use File sharing to allow local directories on your machine to be shared with
 Linux containers. This is especially useful for editing source code in an IDE on
 the host while running and testing the code in a container.
 
-#### Synchronized file shares 
-
-Synchronized file shares is an alternative file sharing mechanism that provides fast and flexible host-to-VM file sharing, enhancing bind mount performance through the use of synchronized filesystem caches. Available with Pro, Team, and Business subscriptions.
-
-To learn more, see [Synchronized file share](/manuals/desktop/features/synchronized-file-sharing.md).
-
-#### Virtual file shares
-
-By default the `/Users`, `/Volumes`, `/private`, `/tmp` and `/var/folders` directory are shared.
-If your project is outside this directory then it must be added to the list,
-otherwise you may get `Mounts denied` or `cannot start service` errors at runtime.
-
-File share settings are:
-
-- **Add a Directory**. Select `+` and navigate to the directory you want to add.
-
-- **Remove a Directory**. Select `-` next to the directory you want to remove
-
-- **Apply & Restart** makes the directory available to containers using Docker's
-  bind mount (`-v`) feature.
-
-> [!TIP]
->
-> * Share only the directories that you need with the container. File sharing
->   introduces overhead as any changes to the files on the host need to be notified
->   to the Linux VM. Sharing too many files can lead to high CPU load and slow
->   filesystem performance.
-> * Shared folders are designed to allow application code to be edited
->   on the host while being executed in containers. For non-code items
->   such as cache directories or databases, the performance will be much
->   better if they are stored in the Linux VM, using a [data volume](/manuals/engine/storage/volumes.md)
->   (named volume) or [data container](/manuals/engine/storage/volumes.md).
-> * If you share the whole of your home directory into a container, MacOS may
->   prompt you to give Docker access to personal areas of your home directory such as
->   your Reminders or Downloads.
-> * By default, Mac file systems are case-insensitive while Linux is case-sensitive.
->   On Linux, it is possible to create two separate files: `test` and `Test`,
->   while on Mac these filenames would actually refer to the same underlying
->   file. This can lead to problems where an app works correctly on a developer's
->   machine (where the file contents are shared) but fails when run in Linux in
->   production (where the file contents are distinct). To avoid this, Docker Desktop
->   insists that all shared files are accessed as their original case. Therefore,
->   if a file is created called `test`, it must be opened as `test`. Attempts to
->   open `Test` will fail with the error "No such file or directory". Similarly,
->   once a file called `test` is created, attempts to create a second file called
->   `Test` will fail.
->
-> For more information, see [Volume mounting requires file sharing for any project directories outside of `/Users`](/manuals/desktop/troubleshoot-and-support/troubleshoot/topics.md)
-
-#### Shared folders on demand
-
-On Windows, you can share a folder "on demand" the first time a particular folder is used by a container.
-
-If you run a Docker command from a shell with a volume mount (as shown in the
-example below) or kick off a Compose file that includes volume mounts, you get a
-popup asking if you want to share the specified folder.
-
-You can select to **Share it**, in which case it is added to your Docker Desktop Shared Folders list and available to
-containers. Alternatively, you can opt not to share it by selecting **Cancel**.
-
-![Shared folder on demand](../images/shared-folder-on-demand.png)
+| Setting             | Description                               | Platform | Notes                                 |
+| ------------------- | ----------------------------------------- | -------- | ------------------------------------- |
+| **Synchronized file shares** | Fast and flexible host-to-VM file sharing, enhancing bind mount performance through the use of synchronized filesystem caches. To learn more, see [Synchronized file share](/manuals/desktop/features/synchronized-file-sharing.md). | Mac, Linux, Windows Hyper-V | Available with Pro, Team, and Business subscriptions. |
+| **Virtual file shares** | Share local directories with Linux containers. By default the `/Users`, `/Volumes`, `/private`, `/tmp` and `/var/folders` directory are shared. If your project is outside this directory then it must be added to the list, otherwise you may get `Mounts denied` or `cannot start service` errors at runtime. | Mac, Linux, Windows Hyper-V | |
+
+
+- Share only the directories that you need with the container. File sharing
+introduces overhead as any changes to the files on the host need to be notified
+to the Linux VM. Sharing too many files can lead to high CPU load and slow
+filesystem performance.
+- Shared folders are designed to allow application code to be edited
+on the host while being executed in containers. For non-code items
+such as cache directories or databases, the performance will be much
+better if they are stored in the Linux VM, using a [data volume](/manuals/engine/storage/volumes.md)
+(named volume) or [data container](/manuals/engine/storage/volumes.md).
+- If you share the whole of your home directory into a container, Mac may
+prompt you to give Docker access to personal areas of your home directory such as
+your Reminders or Downloads.
+- By default, Mac file systems are case-insensitive while Linux is case-sensitive.
+On Linux, it is possible to create two separate files: `test` and `Test`,
+while on Mac these filenames would actually refer to the same underlying
+file. This can lead to problems where an app works correctly on a developer's
+machine (where the file contents are shared) but fails when run in Linux in
+production (where the file contents are distinct). To avoid this, Docker Desktop
+insists that all shared files are accessed as their original case. Therefore,
+if a file is created called `test`, it must be opened as `test`. Attempts to
+open `Test` will fail with the error "No such file or directory". Similarly,
+once a file called `test` is created, attempts to create a second file called
+`Test` will fail.
+
+For more information, see [Volume mounting requires file sharing for any project directories outside of `/Users`](/manuals/desktop/troubleshoot-and-support/troubleshoot/topics.md).
 
 ### Proxies
 
-Docker Desktop supports the use of HTTP/HTTPS and [SOCKS5 proxies](/manuals/desktop/features/networking.md#socks5-proxy-support).
-
-HTTP/HTTPS proxies can be used when:
-
-- Signing in to Docker
-- Pulling or pushing images
-- Fetching artifacts during image builds
-- Containers interact with the external network
-- Scanning images
+Docker Desktop supports HTTP/HTTPS and SOCKS5 proxies. SOCKS5 requires a Business subscription.
 
-If the host uses a HTTP/HTTPS proxy configuration (static or via Proxy Auto-Configuration (PAC)), Docker Desktop reads
-this configuration
-and automatically uses these settings for signing in to Docker, for pulling and pushing images, and for
-container Internet access. If the proxy requires authorization then Docker Desktop dynamically asks
-the developer for a username and password. All passwords are stored securely in the OS credential store.
-Note that only the `Basic` proxy authentication method is supported so we recommend using an `https://`
-URL for your HTTP/HTTPS proxies to protect passwords while in transit on the network. Docker Desktop
-supports TLS 1.3 when communicating with proxies.
+To prevent developers from accidentally changing the proxy settings, see
+[Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md#what-features-can-i-configure-with-settings-management).
 
-To set a different proxy for Docker Desktop, turn on **Manual proxy configuration** and enter a single
-upstream proxy URL of the form `http://proxy:port` or `https://proxy:port`.
+#### Docker Desktop proxy
 
-To prevent developers from accidentally changing the proxy settings, see
-[Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md#what-features-can-i-configure-with-settings-management).
+Used for Docker Desktop host-level traffic: signing in to Docker, the Desktop application, CLI, and extensions. Acts as a fallback for `docker image pull` only when [Containers proxy](#containers-proxy) is not configured.
 
-The HTTPS proxy settings used for scanning images are set using the `HTTPS_PROXY` environment variable.
+| Proxy mode | Description |
+|------------|-------------|
+| **System proxy** | Use the proxy configured on the host (static or Proxy Auto-Configuration (PAC)). Docker Desktop reads this automatically. |
+| **No proxy** | Connect directly without a proxy. |
+| **Manual configuration** | Enter a **Web Server (HTTP)** and **Secure Web Server (HTTPS)** URL manually. Use the format `http://proxy:port` or `https://proxy:port`. You can also specify hosts and domains that should bypass the proxy, for example: `registry-1.docker.com,*.docker.com,10.0.0.0/8`. |
 
 > [!NOTE]
 >
-> If you are using a PAC file hosted on a web server, make sure to add the MIME type `application/x-ns-proxy-autoconfig` for the `.pac` file extension on the server or website. Without this configuration, the PAC file may not be parsed correctly.
+> If you use a PAC file hosted on a web server, add the MIME type `application/x-ns-proxy-autoconfig` for the `.pac` extension. Without this, the PAC file may not parse correctly. See [Hardened Docker Desktop](/manuals/enterprise/security/hardened-desktop/air-gapped-containers.md#proxy-auto-configuration-files).
 
-> [!IMPORTANT]
-> You cannot configure the proxy settings using the Docker daemon configuration
-> file (`daemon.json`), and we recommend you do not configure the proxy
-> settings via the Docker CLI configuration file (`config.json`).
->
-> To manage proxy configurations for Docker Desktop, configure the settings in
-> the Docker Desktop app or use [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md).
+#### Containers proxy
 
-#### Proxy authentication
-
-##### Basic authentication
-
-If your proxy uses Basic authentication, Docker Desktop prompts developers for a username and password and caches the credentials. All passwords are stored securely in the OS credential store. It will request re-authentication if that cache is removed.
+Used for `docker image pull` (always enforced - all `docker pull` and Compose pull operations go through this proxy) and for outbound traffic from running containers when air-gapped container enforcement is configured. If a PAC file is configured here, ensure it returns an appropriate proxy server for Docker registry endpoints, or image pulls will fail.
 
-It's recommended that you use an `https://` URL for HTTP/HTTPS proxies to protect passwords during network transit. Docker Desktop also supports TLS 1.3 for communication with proxies.
-
-##### Kerberos and NTLM authentication
+| Proxy mode | Description |
+|------------|-------------|
+| **Same as host proxy** | Use the same proxy configuration as the Docker Desktop proxy. |
+| **System proxy** | Use the proxy configured on the host. |
+| **No proxy** | Connect directly without a proxy. |
+| **Manual configuration** | Enter a **Web Server (HTTP)** and **Secure Web Server (HTTPS)** URL manually. Use the format `http://proxy:port` or `https://proxy:port`. You can also specify hosts and domains that should bypass the proxy, for example: `registry-1.docker.com,*.docker.com,10.0.0.0/8`. |
 
 > [!NOTE]
 >
-> Available for Docker Business subscribers with Docker Desktop for Windows version 4.30 and later.
-
-Developers are no longer interrupted by prompts for proxy credentials as authentication is centralized. This also reduces the risk of account lockouts due to incorrect sign in attempts.
+> The HTTPS proxy used for image scanning is configured using the `HTTPS_PROXY` environment variable.
 
-If your proxy offers multiple authentication schemes in 407 (Proxy Authentication Required) response, Docker Desktop by default selects the Basic authentication scheme.
+#### Windows Docker daemon proxy
 
-For Docker Desktop version 4.30 to 4.31: 
+When you run Windows containers, enable **Use proxy for Windows Docker daemon**
+to let the Windows Docker daemon connect to Docker Desktop's internal proxy.
+This allows Windows containers to use the configured Docker Desktop proxy, and
+it is required if you want [Registry Access Management](/manuals/enterprise/security/hardened-desktop/registry-access-management.md)
+restrictions to apply to Windows image operations. Administrators can manage
+the same behavior with
+[**Override Windows "dockerd" port**](/manuals/enterprise/security/hardened-desktop/settings-management/settings-reference.md#override-windows-dockerd-port).
 
-To enable Kerberos or NTLM proxy authentication, no additional configuration is needed beyond specifying the proxy IP address and port.
-
-For Docker Desktop version 4.32 and later: 
+#### Proxy authentication
 
-To enable Kerberos or NTLM proxy authentication you must pass the `--proxy-enable-kerberosntlm` installer flag during installation via the command line, and ensure your proxy server is properly configured for Kerberos or NTLM authentication.
+| Method |  Behavior | Notes |
+|--------|-----------| ----- |
+| **Basic** | Docker Desktop prompts for credentials and caches them in the OS credential store. | Use an `https://` proxy URL to protect passwords in transit. Supports TLS 1.3. |
+| **Kerberos / NTLM** |  Centralizes authentication — developers aren't prompted for credentials, reducing the risk of account lockouts. If the proxy returns multiple schemes in a 407 response, Docker Desktop defaults to Basic. | Requires a Business subscription. To enable Kerberos or NTLM proxy authentication you must pass the `--proxy-enable-kerberosntlm` installer flag during installation via the command line, and ensure your proxy server is properly configured for Kerberos or NTLM authentication. |
 
 ### Network
 
 > [!NOTE]
 >
-> On Windows, the **Network** tab isn't available in the Windows container mode because
-> Windows manages networking.
-
-Docker Desktop uses a private IPv4 network for internal services such as a DNS server and an HTTP proxy. In case Docker Desktop's choice of subnet clashes with IPs in your environment, you can specify a custom subnet using the **Network** setting.
+> On Windows, the **Network** tab is not available in Windows container mode because Windows manages networking.
 
-On Mac, you can also select the **Use kernel networking for UDP** setting. This lets you use a more efficient kernel networking path for UDP. This may not be compatible with your VPN software.
+| Setting | Description | Platform |
+|---------|-------------|----------|
+| **Docker subnet** | Set a custom subnet to avoid conflicts with IPs in your environment. Docker Desktop uses a private IPv4 network for internal services, including a DNS server and HTTP proxy. Default: `192.168.65.0/24`. | All |
+| **Use kernel networking for UDP** | Use a more efficient kernel networking path for UDP traffic. May not be compatible with VPN software. | Mac |
+| **Enable host networking** | Allows containers started with `--net=host` to use `localhost` to connect to TCP and UDP services on the host. Also allows host software to use `localhost` to connect to TCP and UDP services in the container. | Mac |
 
-### WSL Integration
+On Windows and Mac, you can also set the default networking mode and DNS resolution behavior. For more information, see [Networking](/manuals/desktop/features/networking/networking-how-tos.md#network-how-tos-for-mac-and-windows).
 
-On Windows in WSL 2 mode, you can configure which WSL 2 distributions will have the Docker
-WSL integration.
+### WSL integration (Windows only)
 
-By default, the integration is enabled on your default WSL distribution.
-To change your default WSL distribution, run `wsl --set-default <distribution name>`. (For example,
-to set Ubuntu as your default WSL distribution, run `wsl --set-default ubuntu`).
-
-You can also select any additional distributions you would like to enable the WSL 2 integration on.
+| Setting             | Description                               | Notes                               |
+| ------------------- | ----------------------------------------- | ------------------------------------- |
+| WSL distribution integration| Select which WSL 2 distributions have Docker WSL integration enabled. | Integration is enabled on your default WSL distribution by default. To change your default distribution, run `wsl --set-default <distribution name>`. |
 
 For more details on configuring Docker Desktop to use WSL 2, see
 [Docker Desktop WSL 2 backend](/manuals/desktop/features/wsl/_index.md).
 
 ## Docker Engine
 
-The **Docker Engine** tab allows you to configure the Docker daemon used to run containers with Docker Desktop.
-
-You configure the daemon using a JSON configuration file. Here's what the file might look like:
-
-```json
-{
-  "builder": {
-    "gc": {
-      "defaultKeepStorage": "20GB",
-      "enabled": true
-    }
-  },
-  "experimental": false
-}
-```
+Configure the Docker daemon using a JSON configuration file.
 
-You can find this file at `$HOME/.docker/daemon.json`. To change the configuration, either
-edit the JSON configuration directly from the dashboard in Docker Desktop, or open and
-edit the file using your favorite text editor.
+The file is located at `$HOME/.docker/daemon.json`. Edit it directly in the Docker Desktop Dashboard or in a text editor.
 
 To see the full list of possible configuration options, see the
 [dockerd command reference](/reference/cli/dockerd/).
 
-Select **Apply & Restart** to save your settings and restart Docker Desktop.
-
 ## Builders
 
-If you have turned on the
-[Docker Desktop Builds view](/manuals/desktop/use-desktop/builds.md), you can use the
-**Builders** tab to inspect and manage builders in the Docker Desktop settings.
+Use the **Builders** tab to inspect and manage builders in the Docker Desktop settings.
 
 ### Inspect
 
@@ -416,67 +263,54 @@ Running a build automatically starts the container if it's stopped.
 
 You can only start and stop builders using the `docker-container` driver.
 
+## AI
+
+From the AI tab, you can configure settings for:
+
+- [Gordon](/manuals/ai/gordon/_index.md), the AI-powered assistant that takes action on your Docker workflows.
+- [Docker Model Runner](/manuals/ai/model-runner/_index.md), which makes it easy to manage, run, and deploy AI models using Docker.
+
 ## Kubernetes
 
 > [!NOTE]
 >
 > On Windows the **Kubernetes** tab is not available in Windows container mode.
 
-Docker Desktop includes a standalone Kubernetes server, so that you can test
-deploying your Docker workloads on Kubernetes. To turn on Kubernetes support and
-install a standalone instance of Kubernetes running as a Docker container,
-select **Enable Kubernetes**.
-
-With Docker Desktop version 4.38 and later, you can choose your cluster provisioning method:
- - **Kubeadm** creates a single-node cluster and the version is set by Docker Desktop.
- - **kind** creates a multi-node cluster and you can set the version and number of nodes. 
+Enable and configure the built-in standalone Kubernetes cluster for testing container deployments.
 
-Select **Show system containers (advanced)** to view internal containers when
-using Docker commands.
-
-Select **Reset Kubernetes cluster** to delete all stacks and Kubernetes resources.
+| Setting             | Description                               |
+| ------------------- | ----------------------------------------- |
+| **Enable Kubernetes** | Install and run a standalone Kubernetes server as a Docker container for testing deployments. |
+| **Cluster provisioning method** | Choose either **Kubeadm**, a single-node cluster with the version set by Docker Desktop, or **Kind**, a multi-node cluster where you can set the version and number of nodes. |
+| **Show system containers (advanced)** | Show internal containers when using Docker commands. |
+| **Reset Kubernetes cluster** | Delete all stacks and Kubernetes resources. |
 
 For more information about using the Kubernetes integration with Docker Desktop,
-see [Deploy on Kubernetes](/manuals/desktop/features/kubernetes.md).
-
-## Software Updates
-
-The **Software Updates** tab notifies you of any updates available to Docker Desktop.
-When there's a new update, you can choose to download the update right away, or
-select the **Release Notes** option to learn what's included in the updated version.
+see [Explore the Kubernetes view](/manuals/desktop/use-desktop/kubernetes.md).
 
-Turn off the check for updates by clearing the **Automatically check for updates**
-check box. This disables notifications in the Docker menu and the notification
-badge that appears on the Docker Desktop Dashboard. To check for updates manually, select
-the **Check for updates** option in the Docker menu.
+## Software updates
 
-To allow Docker Desktop to automatically download new updates in the background,
-select **Always download updates**. This downloads newer versions of Docker Desktop
-when an update becomes available. After downloading the update, select
-**Apply and Restart** to install the update. You can do this either through the
-Docker menu or in the **Updates** section in the Docker Desktop Dashboard.
+Manage how and when Docker Desktop checks for and downloads updates.
 
-> [!TIP]
-> 
-> With Docker Desktop version 4.38 and later, components of Docker Desktop, such as Docker Compose, Docker Scout, and the Docker CLI, can be updated independently without the need for a full restart. This feature is still in Beta. 
+| Setting             | Description                               | Default                             |
+| ------------------- | ----------------------------------------- | ------------------------------------- |
+| **Automatically check for updates** | Notifies you of available updates in the Docker menu and Dashboard footer. | Enabled |
+| **Always download updates** | Automatically download new versions of Docker Desktop in the background. | Disabled |
+| **Automatically update components** | Update Docker Desktop components (such as Docker Compose, Docker Scout, and the Docker CLI) independently, without a full restart. | Enabled |
 
 ## Extensions
 
-Use the **Extensions** tab to:
-
-- **Enable Docker Extensions**
-- **Allow only extensions distributed through the Docker Marketplace**
-- **Show Docker Extensions system containers**
-
-For more information about Docker extensions, see [Extensions](/manuals/extensions/_index.md).
+Enable Docker Extensions and control which extensions are available to install and run.
 
-## Features in development
+| Setting             | Description                               |
+| ------------------- | ----------------------------------------- |
+| **Enable Docker Extensions** | Turn Docker Extensions on or off. Turned off by default. |
+| **Allow only extensions distributed through the Docker Marketplace** | Restrict extensions to Marketplace-approved sources only. |
+| **Show Docker Extensions system containers** | Show containers used by Docker Extensions. |
 
-On the **Feature control** tab you can control your settings for **Beta features** and **Experimental features**.
+For more information about Docker extensions, see [Docker Extensions](/manuals/extensions/_index.md).
 
-You can also sign up to the [Developer Preview program](https://www.docker.com/community/get-involved/developer-preview/) from the **Features in development** tab.
-
-### Beta features
+## Beta features
 
 Beta features provide access to future product functionality.
 These features are intended for testing and feedback only as they may change
@@ -484,47 +318,42 @@ between releases without warning or remove them entirely from a future
 release. Beta features must not be used in production environments.
 Docker doesn't offer support for beta features.
 
-### Experimental features
-
-Experimental features provide early access to future product functionality.
-These features are intended for testing and feedback only as they may change
-between releases without warning or can be removed entirely from a future
-release. Experimental features must not be used in production environments.
-Docker does not offer support for experimental features.
+You can also sign up to the [Developer Preview program](https://www.docker.com/community/get-involved/developer-preview/) from the **Beta features** tab.
 
 For a list of current experimental features in the Docker CLI, see [Docker CLI Experimental features](https://github.com/docker/cli/blob/master/experimental/README.md).
 
 ## Notifications
 
-Use the **Notifications** tab to turn on or turn off notifications for the following events:
-
-- **Status updates on tasks and processes**
-- **Recommendations from Docker**
-- **Docker announcements**
-- **Docker surveys**
-
-By default, all general notifications are turned on. You'll always receive error notifications and notifications about new Docker Desktop releases and updates.
+Choose which types of Docker Desktop notifications you want to receive.
 
-You can also [configure notification settings for Docker Scout-related issues](/manuals/scout/explore/dashboard.md#notification-settings). 
+| Notification type | Default|
+| ----------------- | ------ |
+| Status updates on tasks and processes | Enabled |
+| Recommendations from Docker | Enabled |
+| Docker announcements | Enabled |
+| Docker surveys | Enabled |
+| Error notifications | Always Enabled (cannot be changed) |
+| New releases | Always Enabled (cannot be changed) |
 
-Notifications momentarily appear in the lower-right of the Docker Desktop Dashboard and then move to the **Notifications** drawer which can be accessed from the top-right of the Docker Desktop Dashboard.
+Notifications appear briefly in the lower-right of the Docker Desktop Dashboard, then move to the **Notifications** drawer, accessible from the top-right of the Dashboard.
 
-## Advanced
+## Advanced (Mac only)
 
-On Mac, you can reconfigure your initial installation settings  on the **Advanced** tab:
+Reconfigure CLI tool installation paths and privileged system permissions set during initial install.
 
-- **Choose how to configure the installation of Docker's CLI tools**.
-  - **System**: Docker CLI tools are installed in the system directory under `/usr/local/bin`
-  - **User**: Docker CLI tools are installed in the user directory under `$HOME/.docker/bin`. You must then add `$HOME/.docker/bin` to your PATH. To add `$HOME/.docker/bin` to your path:
-      1. Open your shell configuration file. This is `~/.bashrc` if you're using a bash shell, or `~/.zshrc` if you're using a zsh shell.
-      2. Copy and paste the following:
-            ```console
-            $ export PATH=$PATH:~/.docker/bin
-            ```
-     3. Save and the close the file. Restart your shell to apply the changes to the PATH variable.
+| Setting             | Description                               | Notes                               |
+| ------------------- | ----------------------------------------- | ------------------------------------- |
+| CLI tools installation — **System** | Install Docker CLI tools to `/usr/local/bin`. | |
+| CLI tools installation — **User** | Install Docker CLI tools to `$HOME/.docker/bin` | Add `$HOME/.docker/bin` to your PATH by appending `export PATH=$PATH:~/.docker/bin` to `~/.bashrc` or `~/.zshrc`, then restart your shell. |
+| **Allow the default Docker socket to be used** | Creates `/var/run/docker.sock` which some third party clients may use to communicate with Docker Desktop. For more information, see [permission requirements for macOS](/manuals/desktop/setup/install/mac-permission-requirements.md#installing-symlinks). | Requires password |
+| **Allow privileged port mapping** | Starts the privileged helper process which binds the ports that are between 1 and 1024. For more information, see [permission requirements for macOS](/manuals/desktop/setup/install/mac-permission-requirements.md#binding-privileged-ports). | Requires password |
 
-- **Allow the default Docker socket to be used (Requires password)**. Creates `/var/run/docker.sock` which some third party clients may use to communicate with Docker Desktop. For more information, see [permission requirements for macOS](/manuals/desktop/setup/install/mac-permission-requirements.md#installing-symlinks).
+## Docker Offload
 
-- **Allow privileged port mapping (Requires password)**. Starts the privileged helper process which binds the ports that are between 1 and 1024. For more information, see [permission requirements for macOS](/manuals/desktop/setup/install/mac-permission-requirements.md#binding-privileged-ports).
+Enable Docker Offload and configure idle timeout and GPU support for cloud-based workloads.
 
-For more information on each configuration and use case, see [Permission requirements](/manuals/desktop/setup/install/mac-permission-requirements.md).
+| Setting             | Description                               | Notes                                 |
+| ------------------- | ----------------------------------------- | ------------------------------------- |
+| **Enable Docker Offload** | Run your containers in the cloud.  | Requires sign-in and an Offload subscription |
+| **Idle timeout** | Set the duration of time between no activity and Docker Offload entering idle mode. For details about idle timeout, see [Session management and idle state](/manuals/offload/about.md#session-management-and-idle-state). | |
+| **Enable GPU support** | Let your workloads use cloud GPU if available. | |
diff --git a/content/manuals/desktop/setup/allow-list.md b/content/manuals/desktop/setup/allow-list.md
index 3858c242f36e..39cc4678e67d 100644
--- a/content/manuals/desktop/setup/allow-list.md
+++ b/content/manuals/desktop/setup/allow-list.md
@@ -17,18 +17,20 @@ This page contains the domain URLs that you need to add to a firewall allowlist
 
 | Domains                                                                              | Description                                  |
 | ------------------------------------------------------------------------------------ | -------------------------------------------- |
-| https://api.segment.io                                                               | Analytics                                    |
-| https://cdn.segment.com                                                              | Analytics                                    |
 | https://notify.bugsnag.com                                                           | Error reports                                |
 | https://sessions.bugsnag.com                                                         | Error reports                                |
 | https://auth.docker.io                                                               | Authentication                               |
 | https://cdn.auth0.com                                                                | Authentication                               |
 | https://login.docker.com                                                             | Authentication                               |
+| https://auth.docker.com                                                              | Authentication                               |
 | https://desktop.docker.com                                                           | Update                                       |
 | https://hub.docker.com                                                               | Docker Hub                                   |
 | https://registry-1.docker.io                                                         | Docker Pull/Push                             |
-| https://production.cloudflare.docker.com                                             | Docker Pull/Push (Paid plans)                |
-| https://docker-images-prod.6aa30f8b08e16409b46e0173d6de2f56.r2.cloudflarestorage.com | Docker Pull/Push (Personal plan / Anonymous) |
+| https://production.cloudfront.docker.com                                             | Docker Pull/Push                             |
 | https://docker-pinata-support.s3.amazonaws.com                                       | Troubleshooting                              |
 | https://api.dso.docker.com                                                           | Docker Scout service                         |
 | https://api.docker.com                                                               | New API                                      |
+| https://api.offload.docker.com                                                       | Docker Offload                               |
+| https://dhi.io                                                                       | Docker Hardened Images                       |
+| https://registry.scout.docker.com                                                    | Docker Scout registry for DHI attestations   |
+| https://ai-backend-service.docker.com                                                | [Gordon](/manuals/ai/gordon/_index.md)       |
diff --git a/content/manuals/desktop/setup/install/_index.md b/content/manuals/desktop/setup/install/_index.md
index 44d7b98a8cc7..186d97b05dd3 100644
--- a/content/manuals/desktop/setup/install/_index.md
+++ b/content/manuals/desktop/setup/install/_index.md
@@ -3,7 +3,4 @@ build:
   render: never
 title: Install
 weight: 10
-aliases:
-- /desktop/install/
-- /desktop/setup/install/
 ---
diff --git a/content/manuals/desktop/setup/install/enterprise-deployment/_index.md b/content/manuals/desktop/setup/install/enterprise-deployment/_index.md
deleted file mode 100644
index 588ccbcae81d..000000000000
--- a/content/manuals/desktop/setup/install/enterprise-deployment/_index.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: Enterprise deployment
-weight: 50
-description: If you're an IT admin, learn how to deploy Docker Desktop at scale
-keywords: msi, docker desktop, windows, installation, mac, pkg, enterprise 
-build:
-  render: never
----
\ No newline at end of file
diff --git a/content/manuals/desktop/setup/install/enterprise-deployment/faq.md b/content/manuals/desktop/setup/install/enterprise-deployment/faq.md
deleted file mode 100644
index 71e689bab4d2..000000000000
--- a/content/manuals/desktop/setup/install/enterprise-deployment/faq.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: Enterprise deployment FAQs
-linkTitle: FAQs
-description: Frequently asked questions for deploying Docker Desktop at scale
-keywords: msi, deploy, docker desktop, faqs, pkg, mdm, jamf, intune, windows, mac, enterprise, admin
-tags: [FAQ, admin]
-aliases:
-- /desktop/install/msi/faq/
-- /desktop/setup/install/msi/faq/
----
-
-## MSI
-
-Common questions about installing Docker Desktop using the MSI installer.
-
-### What happens to user data if they have an older Docker Desktop installation (i.e. `.exe`)?
-
-Users must [uninstall](/manuals/desktop/uninstall.md) older `.exe` installations before using the new MSI version. This deletes all Docker containers, images, volumes, and other Docker-related data local to the machine, and removes the files generated by Docker Desktop. 
-
-To preserve existing data before uninstalling, users should [backup](/manuals/desktop/settings-and-maintenance/backup-and-restore.md) their containers and volumes.
-
-For Docker Desktop 4.30 and later, the `.exe` installer includes a `-keep-data` flag that removes Docker Desktop while preserving underlying resources such as the container VMs:
-
-```powershell
-& 'C:\Program Files\Docker\Docker\Docker Desktop Installer.exe' uninstall -keep-data
-```
-
-### What happens if the user's machine has an older `.exe` installation?
-
-The MSI installer detects older `.exe` installations and blocks the installation until the previous version is uninstalled. It prompts the user to uninstall their current/old version first, before retrying to install the MSI version.
-
-### My installation failed, how do I find out what happened?
-
-MSI installations may fail silently, offering little diagnostic feedback.
-
-To debug a failed installation, run the install again with verbose logging enabled:
-
-```powershell
-msiexec /i "DockerDesktop.msi" /L*V ".\msi.log"
-```
-
-After the installation has failed, open the log file and search for occurrences of `value 3`. This is the exit code Windows Installer outputs when it has failed. Just above the line, you will find the reason for the failure.
-
-### Why does the installer prompt for a reboot at the end of every fresh installation?
-
-The installer prompts for a reboot because it assumes that changes have been made to the system that require a reboot to finish their configuration.
-
-For example, if you select the WSL engine, the installer adds the required Windows features. After these features are installed, the system reboots to complete configurations so the WSL engine is functional.
-
-You can suppress reboots by using the `/norestart` option when launching the installer from the command line:
-
-```powershell
-msiexec /i "DockerDesktop.msi" /L*V ".\msi.log" /norestart
-```
-
-### Why isn't the `docker-users` group populated when the MSI is installed with Intune or another MDM solution?
-
-It's common for MDM solutions to install applications in the context of the system account. This means that the `docker-users` group isn't populated with the user's account, as the system account doesn't have access to the user's context.
-
-As an example, you can reproduce this by running the installer with `psexec` in an elevated command prompt:
-
-```powershell
-psexec -i -s msiexec /i "DockerDesktop.msi"
-```
-The installation should complete successfully, but the `docker-users` group won't be populated.
-
-As a workaround, you can create a script that runs in the context of the user account. 
-
-The script would be responsible for creating the `docker-users` group and populating it with the correct user.
-
-Here's an example script that creates the `docker-users` group and adds the current user to it (requirements may vary depending on environment):
-
-```powershell
-$Group = "docker-users"
-$CurrentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
-
-# Create the group
-New-LocalGroup -Name $Group
-
-# Add the user to the group
-Add-LocalGroupMember -Group $Group -Member $CurrentUser
-```
-
-> [!NOTE]
->
-> After adding a new user to the `docker-users` group, the user must sign out and then sign back in for the changes to take effect.
\ No newline at end of file
diff --git a/content/manuals/desktop/setup/install/enterprise-deployment/msi-install-and-configure.md b/content/manuals/desktop/setup/install/enterprise-deployment/msi-install-and-configure.md
deleted file mode 100644
index 48750fc0845a..000000000000
--- a/content/manuals/desktop/setup/install/enterprise-deployment/msi-install-and-configure.md
+++ /dev/null
@@ -1,246 +0,0 @@
----
-title: MSI installer
-description: Understand how to use the MSI installer. Also explore additional configuration options.
-keywords: msi, windows, docker desktop, install, deploy, configure, admin, mdm
-tags: [admin]
-weight: 10
-aliases:
-- /desktop/install/msi/install-and-configure/
-- /desktop/setup/install/msi/install-and-configure/
-- /desktop/install/msi/
-- /desktop/setup/install/msi/
----
-
-{{< summary-bar feature_name="MSI installer" >}}
-
-The MSI package supports various MDM (Mobile Device Management) solutions, making it ideal for bulk installations and eliminating the need for manual setups by individual users. With this package, IT administrators can ensure standardized, policy-driven installations of Docker Desktop, enhancing efficiency and software management across their organizations.
-
-## Install interactively
-
-1. In the [Docker Admin Console](http://admin.docker.com/), navigate to your organization.
-2. Under **Docker Desktop**, select the **Deploy** page.
-3. From the **Windows OS** tab, select the **Download MSI installer** button.
-4. Once downloaded, double-click `Docker Desktop Installer.msi` to run the installer.
-5. After accepting the license agreement, choose the install location. By default, Docker Desktop is installed at `C:\Program Files\Docker\Docker`.
-6. Configure the Docker Desktop installation. You can:
-
-    - Create a desktop shortcut
-
-    - Set the Docker Desktop service startup type to automatic
-
-    - Disable Windows Container usage
-
-    - Select the Docker Desktop backend: WSL or Hyper-V. If only one is supported by your system, you won't be able to choose.
-7. Follow the instructions on the installation wizard to authorize the installer and proceed with the install.
-8. When the installation is successful, select **Finish** to complete the installation process.
-
-If your administrator account is different from your user account, you must add the user to the **docker-users** group:
-1. Run **Computer Management** as an **administrator**.
-2. Navigate to **Local Users and Groups** > **Groups** > **docker-users**.
-3. Right-click to add the user to the group.
-4. Sign out and sign back in for the changes to take effect.
-
-> [!NOTE]
->
-> When installing Docker Desktop with the MSI, in-app updates are automatically disabled. This ensures organizations can maintain version consistency and prevent unapproved updates. For Docker Desktop installed with the .exe installer, in-app updates remain supported.
->
-> Docker Desktop notifies you when an update is available. To update Docker Desktop, download the latest installer from the Docker Admin Console. Navigate to the  **Deploy** page > under **Docker Desktop**.
->
-> To keep up to date with new releases, check the [release notes](/manuals/desktop/release-notes.md) page.
-
-## Install from the command line
-
-This section covers command line installations of Docker Desktop using PowerShell. It provides common installation commands that you can run. You can also add additional arguments which are outlined in [configuration options](#configuration-options).
-
-When installing Docker Desktop, you can choose between interactive or non-interactive installations.
-
-Interactive installations, without specifying `/quiet` or `/qn`, display the user interface and let you select your own properties.
-
-When installing via the user interface it's possible to:
-
-- Choose the destination folder
-- Create a desktop shortcut
-- Configure the Docker Desktop service startup type
-- Disable Windows Containers
-- Choose between the WSL or Hyper-V engine
-
-Non-interactive installations are silent and any additional configuration must be passed as arguments.
-
-### Common installation commands
-
-> [!IMPORTANT]
->
-> Admin rights are required to run any of the following commands.
-
-#### Installing interactively with verbose logging
-
-```powershell
-msiexec /i "DockerDesktop.msi" /L*V ".\msi.log"
-```
-
-#### Installing interactively without verbose logging
-
-```powershell
-msiexec /i "DockerDesktop.msi"
-```
-
-#### Installing non-interactively with verbose logging
-
-```powershell
-msiexec /i "DockerDesktop.msi" /L*V ".\msi.log" /quiet
-```
-
-#### Installing non-interactively and suppressing reboots
-
-```powershell
-msiexec /i "DockerDesktop.msi" /L*V ".\msi.log" /quiet /norestart
-```
-
-#### Installing non-interactively with admin settings
-
-```powershell
-msiexec /i "DockerDesktop.msi" /L*V ".\msi.log" /quiet /norestart ADMINSETTINGS="{"configurationFileVersion":2,"enhancedContainerIsolation":{"value":true,"locked":false}}" ALLOWEDORG="docker"
-```
-
-#### Installing with the passive display option
-
-You can use the `/passive` display option instead of `/quiet` when you want to perform a non-interactive installation but show a progress dialog.
-
-In passive mode the installer doesn't display any prompts or error messages to the user and the installation cannot be cancelled.
-
-For example:
-
-```powershell
-msiexec /i "DockerDesktop.msi" /L*V ".\msi.log" /passive /norestart
-```
-
-> [!TIP]
->
-> When creating a value that expects a JSON string:
->
-> - The property expects a JSON formatted string
-> - The string should be wrapped in double quotes
-> - The string shouldn't contain any whitespace
-> - Property names are expected to be in double quotes
-
-### Common uninstall commands
-
-When uninstalling Docker Desktop, you need to use the same `.msi` file that was originally used to install the application.
-
-If you no longer have the original `.msi` file, you need to use the product code associated with the installation. To find the product code, run:
-
-```powershell
-Get-WmiObject Win32_Product | Select-Object IdentifyingNumber, Name | Where-Object {$_.Name -eq "Docker Desktop"}
-```
-
-It should return output similar to the following:
-
-```text
-IdentifyingNumber                      Name
------------------                      ----
-{10FC87E2-9145-4D7D-B493-2E99E8D8E103} Docker Desktop
-```
-> [!NOTE]
->
-> This command may take some time, depending on the number of installed applications.
-
-`IdentifyingNumber` is the applications product code and can be used to uninstall Docker Desktop. For example:
-
-```powershell
-msiexec /x {10FC87E2-9145-4D7D-B493-2E99E8D8E103} /L*V ".\msi.log" /quiet
-```
-
-#### Uninstalling interactively with verbose logging
-
-```powershell
-msiexec /x "DockerDesktop.msi" /L*V ".\msi.log"
-```
-
-#### Uninstalling interactively without verbose logging
-
-```powershell
-msiexec /x "DockerDesktop.msi"
-```
-
-#### Uninstalling non-interactively with verbose logging
-
-```powershell
-msiexec /x "DockerDesktop.msi" /L*V ".\msi.log" /quiet
-```
-
-#### Uninstalling non-interactively without verbose logging
-
-```powershell
-msiexec /x "DockerDesktop.msi" /quiet
-```
-
-### Configuration options
-
-> [!IMPORTANT]
->
-> In addition to the following custom properties, the Docker Desktop MSI installer also supports the standard [Windows Installer command line options](https://learn.microsoft.com/en-us/windows/win32/msi/standard-installer-command-line-options).
-
-| Property | Description | Default |
-| :--- | :--- | :--- |
-| `ENABLEDESKTOPSHORTCUT` | Creates a desktop shortcut. | 1 |
-| `INSTALLFOLDER` | Specifies a custom location where Docker Desktop will be installed. | C:\Program Files\Docker |
-| `ADMINSETTINGS` | Automatically creates an `admin-settings.json` file which is used to [control certain Docker Desktop settings](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md) on client machines within organizations. It must be used together with the `ALLOWEDORG` property. | None |
-| `ALLOWEDORG` | Requires the user to sign in and be part of the specified Docker Hub organization when running the application. This creates a registry key called `allowedOrgs` in `HKLM\Software\Policies\Docker\Docker Desktop`. | None |
-| `ALWAYSRUNSERVICE` | Lets users switch to Windows containers without needing admin rights | 0 |
-| `DISABLEWINDOWSCONTAINERS` | Disables the Windows containers integration | 0 |
-| `ENGINE` | Sets the Docker Engine that's used to run containers. This can be either `wsl` , `hyperv`, or `windows` | `wsl` |
-| `PROXYENABLEKERBEROSNTLM` | When set to 1, enables support for Kerberos and NTLM proxy authentication. Available with Docker Desktop 4.33 and later| 0 |
-| `PROXYHTTPMODE` | Sets the HTTP Proxy mode. This can be either `system` or `manual` | `system` |
-| `OVERRIDEPROXYHTTP` | Sets the URL of the HTTP proxy that must be used for outgoing HTTP requests. | None |
-| `OVERRIDEPROXYHTTPS` | Sets the URL of the HTTP proxy that must be used for outgoing HTTPS requests. | None |
-| `OVERRIDEPROXYEXCLUDE` | Bypasses proxy settings for the hosts and domains. Uses a comma-separated list. | None |
-| `HYPERVDEFAULTDATAROOT` | Specifies the default location for the Hyper-V VM disk. | None |
-| `WINDOWSCONTAINERSDEFAULTDATAROOT` | Specifies the default location for Windows containers. | None |
-| `WSLDEFAULTDATAROOT` | Specifies the default location for the WSL distribution disk. | None |
-| `DISABLEANALYTICS` | When set to 1, analytics collection will be disabled for the MSI. For more information, see [Analytics](#analytics). | 0 |
-
-
-Additionally, you can also use `/norestart` or `/forcerestart` to control reboot behaviour.
-
-By default, the installer reboots the machine after a successful installation. When run silently, the reboot is automatic and the user is not prompted.
-
-## Analytics
-
-The MSI installer collects anonymous usage statistics relating to installation only. This is to better understand user behaviour and to improve the user experience by identifying and addressing issues or optimizing popular features.
-
-### How to opt-out
-
-{{< tabs >}}
-{{< tab name="From the GUI" >}}
-
-When you install Docker Desktop from the default installer GUI, select the **Disable analytics** checkbox located on the bottom-left corner of the **Welcome** dialog.
-
-{{< /tab >}}
-{{< tab name="From the command line" >}}
-
-When you install Docker Desktop from the command line, use the `DISABLEANALYTICS` property.
-
-```powershell
-msiexec /i "win\msi\bin\en-US\DockerDesktop.msi" /L*V ".\msi.log" DISABLEANALYTICS=1
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Persistence
-
-If you decide to disable analytics for an installation, your choice is persisted in the registry and honoured across future upgrades and uninstalls.
-
-However, the key is removed when Docker Desktop is uninstalled and must be configured again via one of the previous methods.
-
-The registry key is as follows:
-
-```powershell
-SOFTWARE\Docker Inc.\Docker Desktop\DisableMsiAnalytics
-```
-
-When analytics is disabled, this key is set to `1`.
-
-## Additional resources
-
-- [Explore the FAQs](faq.md)
diff --git a/content/manuals/desktop/setup/install/linux/_index.md b/content/manuals/desktop/setup/install/linux/_index.md
index f034da1a6e1f..6440f2a6a943 100644
--- a/content/manuals/desktop/setup/install/linux/_index.md
+++ b/content/manuals/desktop/setup/install/linux/_index.md
@@ -1,41 +1,43 @@
 ---
-description: Install Docker on Linux with ease using our step-by-step installation
+description:
+  Install Docker on Linux with ease using our step-by-step installation
   guide covering system requirements, supported platforms, and where to go next.
-keywords: linux, docker linux install, docker linux, linux docker installation, docker
+keywords:
+  linux, docker linux install, docker linux, linux docker installation, docker
   for linux, docker desktop for linux, installing docker on linux, docker download
   linux, how to install docker on linux, linux vs docker engine, switch docker contexts
 title: Install Docker Desktop on Linux
 linkTitle: Linux
 weight: 60
 aliases:
-- /desktop/linux/install/
-- /desktop/install/linux-install/
-- /desktop/install/linux/
+  - /desktop/linux/install/
+  - /desktop/install/linux-install/
+  - /desktop/install/linux/
 ---
 
 > **Docker Desktop terms**
 >
 > Commercial use of Docker Desktop in larger enterprises (more than 250
 > employees or more than $10 million USD in annual revenue) requires a [paid
-> subscription](https://www.docker.com/pricing/).
+> subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopLinuxInstall).
 
 This page contains information about general system requirements, supported platforms, and instructions on how to install Docker Desktop for Linux.
 
 > [!IMPORTANT]
 >
->Docker Desktop on Linux runs a Virtual Machine (VM) which creates and uses a custom docker context, `desktop-linux`, on startup. 
+> Docker Desktop on Linux runs a Virtual Machine (VM) which creates and uses a custom docker context, `desktop-linux`, on startup.
 >
->This means images and containers deployed on the Linux Docker Engine (before installation) are not available in Docker Desktop for Linux. 
+> This means images and containers deployed on the Linux Docker Engine (before installation) are not available in Docker Desktop for Linux.
 >
 > {{< accordion title=" Docker Desktop vs Docker Engine: What's the difference?" >}}
 
 > [!IMPORTANT]
 >
-> For commercial use of Docker Engine obtained via Docker Desktop within larger enterprises (exceeding 250 employees or with annual revenue surpassing $10 million USD), a [paid subscription](https://www.docker.com/pricing/) is required.
+> For commercial use of Docker Engine obtained via Docker Desktop within larger enterprises (exceeding 250 employees or with annual revenue surpassing $10 million USD), a [paid subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopLinuxInstall) is required.
 
 Docker Desktop for Linux provides a user-friendly graphical interface that simplifies the management of containers and services. It includes Docker Engine as this is the core technology that powers Docker containers. Docker Desktop for Linux also comes with additional features like Docker Scout and Docker Extensions.
 
-#### Installing Docker Desktop and Docker Engine
+### Installing Docker Desktop and Docker Engine
 
 Docker Desktop for Linux and Docker Engine can be installed side-by-side on the
 same machine. Docker Desktop for Linux stores containers and images in an isolated
@@ -88,7 +90,7 @@ machine. The current context is indicated with an asterisk (`*`).
 $ docker context ls
 NAME            DESCRIPTION                               DOCKER ENDPOINT                                  ...
 default *       Current DOCKER_HOST based configuration   unix:///var/run/docker.sock                      ...
-desktop-linux                                             unix:///home/<user>/.docker/desktop/docker.sock  ...        
+desktop-linux                                             unix:///home/<user>/.docker/desktop/docker.sock  ...
 ```
 
 If you have both Docker Desktop and Docker Engine installed on the same machine,
@@ -101,14 +103,15 @@ $ docker context use default
 default
 Current context is now "default"
 ```
-  
+
 And use the `desktop-linux` context to interact with Docker Desktop:
- 
+
 ```console
 $ docker context use desktop-linux
 desktop-linux
 Current context is now "desktop-linux"
-``` 
+```
+
 Refer to the [Docker Context documentation](/manuals/engine/manage-resources/contexts.md) for more details.
 {{< /accordion >}}
 
@@ -117,17 +120,16 @@ Refer to the [Docker Context documentation](/manuals/engine/manage-resources/con
 Docker provides `.deb` and `.rpm` packages for the following Linux distributions
 and architectures:
 
-| Platform                | x86_64 / amd64          | 
-|:------------------------|:-----------------------:|
-| [Ubuntu](ubuntu.md)                         | ✅  |
-| [Debian](debian.md)                         | ✅  |
-| [Red Hat Enterprise Linux (RHEL)](rhel.md)  | ✅  |
-| [Fedora](fedora.md)                         | ✅  |
-
+| Platform                                   | x86_64 / amd64 |
+| :----------------------------------------- | :------------: |
+| [Ubuntu](ubuntu.md)                        |       ✅       |
+| [Debian](debian.md)                        |       ✅       |
+| [Red Hat Enterprise Linux (RHEL)](rhel.md) |       ✅       |
+| [Fedora](fedora.md)                        |       ✅       |
 
 An experimental package is available for [Arch](archlinux.md)-based distributions. Docker has not tested or verified the installation.
 
-Docker supports Docker Desktop on the current LTS release of the aforementioned distributions and the most recent version. As new versions are made available, Docker stops supporting the oldest version and supports the newest version.
+Docker supports Docker Desktop on the current and previous LTS releases of the aforementioned distributions, as well as the most recent version.
 
 ## General system requirements
 
@@ -137,7 +139,7 @@ To install Docker Desktop successfully, your Linux host must meet the following
 - KVM virtualization support. Follow the [KVM virtualization support instructions](#kvm-virtualization-support) to check if the KVM kernel modules are enabled and how to provide access to the KVM device.
 - QEMU must be version 5.2 or later. We recommend upgrading to the latest version.
 - systemd init system.
-- GNOME, KDE, or MATE desktop environment.
+- GNOME, KDE, or MATE desktop environments are supported but others may work.
   - For many Linux distributions, the GNOME environment does not support tray icons. To add support for tray icons, you need to install a GNOME extension. For example, [AppIndicator](https://extensions.gnome.org/extension/615/appindicator-support/).
 - At least 4 GB of RAM.
 - Enable configuring ID mapping in user namespaces, see [File sharing](/manuals/desktop/troubleshoot-and-support/faqs/linuxfaqs.md#how-do-i-enable-file-sharing). Note that for Docker Desktop version 4.35 and later, this is not required anymore.
@@ -151,7 +153,6 @@ Docker Desktop for Linux runs a Virtual Machine (VM). For more information on wh
 
 ### KVM virtualization support
 
-
 Docker Desktop runs a VM that requires [KVM support](https://www.linux-kvm.org).
 
 The `kvm` module should load automatically if the host has virtualization support. To load the module manually, run:
@@ -186,7 +187,6 @@ irqbypass              16384  1 kvm
 
 #### Set up KVM device user permissions
 
-
 To check ownership of `/dev/kvm`, run :
 
 ```console
@@ -201,13 +201,15 @@ $ sudo usermod -aG kvm $USER
 
 Sign out and sign back in so that your group membership is re-evaluated.
 
-## Where to go next
+## Using Docker SDKs with Docker Desktop
 
-- Install Docker Desktop for Linux for your specific Linux distribution:
-   - [Install on Ubuntu](ubuntu.md)
-   - [Install on Debian](debian.md)
-   - [Install on Red Hat Enterprise Linux (RHEL)](rhel.md)
-   - [Install on Fedora](fedora.md)
-   - [Install on Arch](archlinux.md)
+Docker Desktop for Linux uses a per-user socket instead of the system-wide `/var/run/docker.sock`. Docker SDKs and tools that connect directly to the Docker daemon need the `DOCKER_HOST` environment variable set to connect to Docker Desktop. For configuration details, see [How do I use Docker SDKs with Docker Desktop for Linux?](/manuals/desktop/troubleshoot-and-support/faqs/linuxfaqs.md#how-do-i-use-docker-sdks-with-docker-desktop-for-linux).
 
+## Where to go next
 
+- Install Docker Desktop for Linux for your specific Linux distribution:
+  - [Install on Ubuntu](ubuntu.md)
+  - [Install on Debian](debian.md)
+  - [Install on Red Hat Enterprise Linux (RHEL)](rhel.md)
+  - [Install on Fedora](fedora.md)
+  - [Install on Arch](archlinux.md)
diff --git a/content/manuals/desktop/setup/install/linux/archlinux.md b/content/manuals/desktop/setup/install/linux/archlinux.md
index 06ea014d235e..18d75e7252cd 100644
--- a/content/manuals/desktop/setup/install/linux/archlinux.md
+++ b/content/manuals/desktop/setup/install/linux/archlinux.md
@@ -6,7 +6,6 @@ keywords: Arch Linux, install, uninstall, upgrade, update, linux, desktop, docke
 title: Install Docker Desktop on Arch-based distributions
 linkTitle: Arch
 aliases:
-- /desktop/linux/install/archlinux/
 - /desktop/install/archlinux/
 - /desktop/install/linux/archlinux/
 ---
@@ -17,12 +16,10 @@ aliases:
 >
 > Commercial use of Docker Desktop in larger enterprises (more than 250
 > employees OR more than $10 million USD in annual revenue) requires a [paid
-> subscription](https://www.docker.com/pricing/).
+> subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopArchlinuxInstall).
 
 This page contains information on how to install, launch and upgrade Docker Desktop on an Arch-based distribution. 
 
-
-
 ## Prerequisites
 
 To install Docker Desktop successfully, you must meet the [general system requirements](_index.md#general-system-requirements).
@@ -33,7 +30,7 @@ To install Docker Desktop successfully, you must meet the [general system requir
 
    ```console
    $ wget https://download.docker.com/linux/static/stable/x86_64/docker-{{% param "docker_ce_version" %}}.tgz -qO- | tar xvfz - docker/docker --strip-components=1
-   $ mv ./docker /usr/local/bin
+   $ sudo cp -rp ./docker /usr/local/bin/ && rm -r ./docker
    ```
 
 2. Download the latest Arch package from the [Release notes](/manuals/desktop/release-notes.md).
@@ -52,8 +49,8 @@ To install Docker Desktop successfully, you must meet the [general system requir
 
 ## Next steps
 
-- Explore [Docker's subscriptions](https://www.docker.com/pricing/) to see what Docker can offer you.
-- Take a look at the [Docker workshop](/get-started/workshop/_index.md) to learn how to build an image and run it as a containerized application.
+- Explore [Docker's subscriptions](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopArchlinuxInstall) to see what Docker can offer you.
+- Take a look at [Get started with Docker](/get-started/introduction/_index.md) to learn how to build an image and run it as a containerized application.
 - [Explore Docker Desktop](/manuals/desktop/use-desktop/_index.md) and all its features.
 - [Troubleshooting](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md) describes common problems, workarounds, how to run and submit diagnostics, and submit issues.
 - [FAQs](/manuals/desktop/troubleshoot-and-support/faqs/general.md) provide answers to frequently asked questions.
diff --git a/content/manuals/desktop/setup/install/linux/debian.md b/content/manuals/desktop/setup/install/linux/debian.md
index 7938ea07b775..9fae050ab52a 100644
--- a/content/manuals/desktop/setup/install/linux/debian.md
+++ b/content/manuals/desktop/setup/install/linux/debian.md
@@ -7,7 +7,6 @@ linkTitle: Debian
 weight: 20
 toc_max: 4
 aliases:
-- /desktop/linux/install/debian/
 - /desktop/install/debian/
 - /desktop/install/linux/debian/
 ---
@@ -16,7 +15,7 @@ aliases:
 >
 > Commercial use of Docker Desktop in larger enterprises (more than 250
 > employees OR more than $10 million USD in annual revenue) requires a [paid
-> subscription](https://www.docker.com/pricing/).
+> subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopDebianInstall).
 
 This page contains information on how to install, launch, and upgrade Docker Desktop on a Debian distribution.
 
@@ -60,7 +59,7 @@ Recommended approach to install Docker Desktop on Debian:
 
    By default, Docker Desktop is installed at `/opt/docker-desktop`.
 
-The RPM package includes a post-install script that completes additional setup steps automatically.
+The DEB package includes a post-install script that completes additional setup steps automatically.
 
 The post-install script:
 
@@ -84,8 +83,8 @@ $ sudo apt-get install ./docker-desktop-amd64.deb
 
 ## Next steps
 
-- Explore [Docker's subscriptions](https://www.docker.com/pricing/) to see what Docker can offer you.
-- Take a look at the [Docker workshop](/get-started/workshop/_index.md) to learn how to build an image and run it as a containerized application.
+- Explore [Docker's subscriptions](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopDebianInstall) to see what Docker can offer you.
+- Take a look at [Get started with Docker](/get-started/introduction/_index.md) to learn how to build an image and run it as a containerized application.
 - [Explore Docker Desktop](/manuals/desktop/use-desktop/_index.md) and all its features.
 - [Troubleshooting](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md) describes common problems, workarounds, how to run and submit diagnostics, and submit issues.
 - [FAQs](/manuals/desktop/troubleshoot-and-support/faqs/general.md) provide answers to frequently asked questions.
diff --git a/content/manuals/desktop/setup/install/linux/fedora.md b/content/manuals/desktop/setup/install/linux/fedora.md
index 4148069837ff..ee55df2bb28d 100644
--- a/content/manuals/desktop/setup/install/linux/fedora.md
+++ b/content/manuals/desktop/setup/install/linux/fedora.md
@@ -7,7 +7,6 @@ linkTitle: Fedora
 weight: 30
 toc_max: 4
 aliases:
-- /desktop/linux/install/fedora/
 - /desktop/install/fedora/
 - /desktop/install/linux/fedora/
 ---
@@ -16,7 +15,7 @@ aliases:
 >
 > Commercial use of Docker Desktop in larger enterprises (more than 250
 > employees OR more than $10 million USD in annual revenue) requires a [paid
-> subscription](https://www.docker.com/pricing/).
+> subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopFedoraInstall).
 
 This page contains information on how to install, launch and upgrade Docker Desktop on a Fedora distribution.
 
@@ -25,7 +24,7 @@ This page contains information on how to install, launch and upgrade Docker Desk
 To install Docker Desktop successfully, you must:
 
 - Meet the [general system requirements](_index.md#general-system-requirements).
-- Have a 64-bit version of Fedora 40 or Fedora 41.
+- Have a 64-bit version of Fedora 43 or later.
 - For a GNOME desktop environment you must install AppIndicator and KStatusNotifierItem [GNOME extensions](https://extensions.gnome.org/extension/615/appindicator-support/).
 - If you're not using GNOME, you must install `gnome-terminal` to enable terminal access from Docker Desktop:
 
@@ -74,8 +73,8 @@ $ sudo dnf install ./docker-desktop-x86_64.rpm
 
 ## Next steps
 
-- Explore [Docker's subscriptions](https://www.docker.com/pricing/) to see what Docker can offer you.
-- Take a look at the [Docker workshop](/get-started/workshop/_index.md) to learn how to build an image and run it as a containerized application.
+- Explore [Docker's subscriptions](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopFedoraInstall) to see what Docker can offer you.
+- Take a look at [Get started with Docker](/get-started/introduction/_index.md) to learn how to build an image and run it as a containerized application.
 - [Explore Docker Desktop](/manuals/desktop/use-desktop/_index.md) and all its features.
 - [Troubleshooting](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md) describes common problems, workarounds, how to run and submit diagnostics, and submit issues.
 - [FAQs](/manuals/desktop/troubleshoot-and-support/faqs/general.md) provide answers to frequently asked questions.
diff --git a/content/manuals/desktop/setup/install/linux/rhel.md b/content/manuals/desktop/setup/install/linux/rhel.md
index 88f0ae7aad74..c45ac021a73e 100644
--- a/content/manuals/desktop/setup/install/linux/rhel.md
+++ b/content/manuals/desktop/setup/install/linux/rhel.md
@@ -14,7 +14,7 @@ aliases:
 >
 > Commercial use of Docker Desktop in larger enterprises (more than 250
 > employees or more than $10 million USD in annual revenue) requires a [paid
-> subscription](https://www.docker.com/pricing/).
+> subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopRhelInstall).
 
 This page contains information on how to install, launch and upgrade Docker Desktop on a Red Hat Enterprise Linux (RHEL) distribution.
 
@@ -23,24 +23,23 @@ This page contains information on how to install, launch and upgrade Docker Desk
 To install Docker Desktop successfully, you must:
 
 - Meet the [general system requirements](_index.md#general-system-requirements).
-- Have a 64-bit version of either RHEL 8 or RHEL 9.
-- Have a [Docker account](/manuals/accounts/create-account.md), as authentication is required for Docker Desktop on RHEL.
+- Have a 64-bit version of either RHEL 9 or RHEL 10.
 
 - If `pass` is not installed, or it can't be installed, you must enable [CodeReady Linux Builder (CRB) repository](https://access.redhat.com/articles/4348511) and [Extra Packages for Enterprise Linux (EPEL)](https://docs.fedoraproject.org/en-US/epel/).
 
    {{< tabs group="os_version" >}}
-   {{< tab name="RHEL 9" >}}
+   {{< tab name="RHEL 10" >}}
    ```console
-   $ sudo subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms
-   $ sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
+   $ sudo subscription-manager repos --enable codeready-builder-for-rhel-10-$(arch)-rpms
+   $ sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm
    $ sudo dnf install pass
    ```
 
    {{< /tab >}}
-   {{< tab name="RHEL 8" >}}
+   {{< tab name="RHEL 9" >}}
    ```console
-   $ sudo subscription-manager repos --enable codeready-builder-for-rhel-8-$(arch)-rpms
-   $ sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
+   $ sudo subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms
+   $ sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
    $ sudo dnf install pass
    ```
 
@@ -50,7 +49,7 @@ To install Docker Desktop successfully, you must:
 - For a GNOME desktop environment you must install AppIndicator and KStatusNotifierItem [GNOME extensions](https://extensions.gnome.org/extension/615/appindicator-support/). You must also enable EPEL.
 
    {{< tabs group="os_version" >}}
-   {{< tab name="RHEL 9" >}}
+   {{< tab name="RHEL 10" >}}
    ```console
    $ # enable EPEL as described above
    $ sudo dnf install gnome-shell-extension-appindicator
@@ -58,12 +57,11 @@ To install Docker Desktop successfully, you must:
    ```
 
    {{< /tab >}}
-   {{< tab name="RHEL 8" >}}
+   {{< tab name="RHEL 9" >}}
    ```console
    $ # enable EPEL as described above
    $ sudo dnf install gnome-shell-extension-appindicator
-   $ sudo dnf install gnome-shell-extension-desktop-icons
-   $ sudo gnome-shell-extension-tool -e appindicatorsupport@rgcjonas.gmail.com
+   $ sudo gnome-extensions enable appindicatorsupport@rgcjonas.gmail.com
    ```
 
    {{< /tab >}}
@@ -107,10 +105,6 @@ The post-install script:
 
 {{% include "desktop-linux-launch.md" %}}
 
-> [!IMPORTANT]
->
-> After launching Docker Desktop for RHEL, you must sign in to your Docker account to start using Docker Desktop.
-
 > [!TIP]
 >
 > To attach Red Hat subscription data to containers, see [Red Hat verified solution](https://access.redhat.com/solutions/5870841).
@@ -132,8 +126,8 @@ $ sudo dnf install ./docker-desktop-<arch>-rhel.rpm
 
 ## Next steps
 
-- Review [Docker's subscriptions](https://www.docker.com/pricing/) to see what Docker can offer you.
-- Take a look at the [Docker workshop](/get-started/workshop/_index.md) to learn how to build an image and run it as a containerized application.
+- Review [Docker's subscriptions](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopRhelInstall) to see what Docker can offer you.
+- Take a look at [Get started with Docker](/get-started/introduction/_index.md) to learn how to build an image and run it as a containerized application.
 - [Explore Docker Desktop](/manuals/desktop/use-desktop/_index.md) and all its features.
 - [Troubleshooting](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md) describes common problems, workarounds, how to run and submit diagnostics, and submit issues.
 - [FAQs](/manuals/desktop/troubleshoot-and-support/faqs/general.md) provide answers to frequently asked questions.
diff --git a/content/manuals/desktop/setup/install/linux/ubuntu.md b/content/manuals/desktop/setup/install/linux/ubuntu.md
index 282bb8d81849..53d6572aea16 100644
--- a/content/manuals/desktop/setup/install/linux/ubuntu.md
+++ b/content/manuals/desktop/setup/install/linux/ubuntu.md
@@ -1,7 +1,9 @@
 ---
-description: Learn how to install, launch, and upgrade Docker Desktop on Ubuntu. This
+description:
+  Learn how to install, launch, and upgrade Docker Desktop on Ubuntu. This
   quick guide will cover prerequisites, installation methods, and more.
-keywords: install docker ubuntu, ubuntu install docker, install docker on ubuntu,
+keywords:
+  install docker ubuntu, ubuntu install docker, install docker on ubuntu,
   docker install ubuntu, how to install docker on ubuntu, ubuntu docker install, docker
   installation on ubuntu, docker ubuntu install, docker installing ubuntu, installing
   docker on ubuntu, docker desktop for ubuntu
@@ -10,16 +12,15 @@ linkTitle: Ubuntu
 weight: 10
 toc_max: 4
 aliases:
-- /desktop/linux/install/ubuntu/
-- /desktop/install/ubuntu/
-- /desktop/install/linux/ubuntu/
+  - /desktop/install/ubuntu/
+  - /desktop/install/linux/ubuntu/
 ---
 
 > **Docker Desktop terms**
 >
 > Commercial use of Docker Desktop in larger enterprises (more than 250
 > employees or more than $10 million USD in annual revenue) requires a [paid
-> subscription](https://www.docker.com/pricing/).
+> subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopUbuntuInstall).
 
 This page contains information on how to install, launch and upgrade Docker Desktop on an Ubuntu distribution.
 
@@ -28,7 +29,8 @@ This page contains information on how to install, launch and upgrade Docker Desk
 To install Docker Desktop successfully, you must:
 
 - Meet the [general system requirements](_index.md#general-system-requirements).
-- Have an x86-64 system with Ubuntu 22.04, 24.04, or the latest non-LTS version.
+- Have an x86-64 system with Ubuntu 26.04 LTS or 24.04 LTS.
+- For a GNOME desktop environment, you must install AppIndicator and KStatusNotifierItem [GNOME extensions](https://extensions.gnome.org/extension/615/appindicator-support/).
 - If you're not using GNOME, you must install `gnome-terminal` to enable terminal access from Docker Desktop:
   ```console
   $ sudo apt install gnome-terminal
@@ -47,7 +49,7 @@ Recommended approach to install Docker Desktop on Ubuntu:
 
    ```console
    $ sudo apt-get update
-   $ sudo apt-get install ./docker-desktop-amd64.deb
+   $ sudo apt install ./docker-desktop-amd64.deb
    ```
 
    > [!NOTE]
@@ -68,7 +70,7 @@ The post-install script:
 - Sets the capability on the Docker Desktop binary to map privileged ports and set resource limits.
 - Adds a DNS name for Kubernetes to `/etc/hosts`.
 - Creates a symlink from `/usr/local/bin/com.docker.cli` to `/usr/bin/docker`.
-  This is because the classic Docker CLI is installed at `/usr/bin/docker`. The Docker Desktop installer also installs a Docker CLI binary that includes cloud-integration capabilities and is essentially a wrapper for the Compose CLI, at `/usr/local/bin/com.docker.cli`. The symlink ensures that the wrapper can access the classic Docker CLI. 
+  This is because the classic Docker CLI is installed at `/usr/bin/docker`. The Docker Desktop installer also installs a Docker CLI binary that includes cloud-integration capabilities and is essentially a wrapper for the Compose CLI, at `/usr/local/bin/com.docker.cli`. The symlink ensures that the wrapper can access the classic Docker CLI.
 
 ## Launch Docker Desktop
 
@@ -80,13 +82,13 @@ When a new version for Docker Desktop is released, the Docker UI shows a notific
 You need to download the new package each time you want to upgrade Docker Desktop and run:
 
 ```console
-$ sudo apt-get install ./docker-desktop-amd64.deb
+$ sudo apt install ./docker-desktop-amd64.deb
 ```
 
 ## Next steps
 
-- Review [Docker's subscriptions](https://www.docker.com/pricing/) to see what Docker can offer you.
-- Follow the [Docker workshop](/get-started/workshop/_index.md) to learn how to build an image and run it as a containerized application.
+- Review [Docker's subscriptions](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopUbuntuInstall) to see what Docker can offer you.
+- Follow [Get started with Docker](/get-started/introduction/_index.md) to learn how to build an image and run it as a containerized application.
 - [Explore Docker Desktop](/manuals/desktop/use-desktop/_index.md) and all its features.
 - [Troubleshooting](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md) describes common problems, workarounds, how to run and submit diagnostics, and submit issues.
 - [FAQs](/manuals/desktop/troubleshoot-and-support/faqs/general.md) provide answers to frequently asked questions.
diff --git a/content/manuals/desktop/setup/install/mac-install.md b/content/manuals/desktop/setup/install/mac-install.md
index 41940a299552..3c065841aa15 100644
--- a/content/manuals/desktop/setup/install/mac-install.md
+++ b/content/manuals/desktop/setup/install/mac-install.md
@@ -11,18 +11,15 @@ aliases:
 - /desktop/mac/install/
 - /docker-for-mac/install/
 - /engine/installation/mac/
-- /installation/mac/
-- /docker-for-mac/apple-m1/
-- /docker-for-mac/apple-silicon/
-- /desktop/mac/apple-silicon/
 - /desktop/install/mac-install/
+- /desktop/install/mac/
 ---
 
 > **Docker Desktop terms**
 >
 > Commercial use of Docker Desktop in larger enterprises (more than 250
 > employees or more than $10 million USD in annual revenue) requires a [paid
-> subscription](https://www.docker.com/pricing/).
+> subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopMacInstall).
 
 This page provides download links, system requirements, and step-by-step installation instructions for Docker Desktop on Mac.
 
@@ -31,14 +28,10 @@ This page provides download links, system requirements, and step-by-step install
 
 *For checksums, see [Release notes](/manuals/desktop/release-notes.md).*
 
-> [!WARNING]
->
-> If you're experiencing malware detection issues, follow the steps documented in [docker/for-mac#7527](https://github.com/docker/for-mac/issues/7527).
-
 ## System requirements
 
 {{< tabs >}}
-{{< tab name="Mac with Intel chip" >}}
+{{< tab name="Mac with Apple silicon" >}}
 
 - A supported version of macOS.
 
@@ -47,9 +40,13 @@ This page provides download links, system requirements, and step-by-step install
   > Docker Desktop is supported on the current and two previous major macOS releases. As new major versions of macOS are made generally available, Docker stops supporting the oldest version and supports the newest version of macOS (in addition to the previous two releases).
 
 - At least 4 GB of RAM.
+- For the best experience, it's recommended that you install Rosetta 2. Rosetta 2 is no longer strictly required, however there are a few optional command line tools that still require Rosetta 2 when using Darwin/AMD64. See [Known issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md). To install Rosetta 2 manually from the command line, run the following command:
 
+   ```console
+   $ softwareupdate --install-rosetta
+   ```
 {{< /tab >}}
-{{< tab name="Mac with Apple silicon" >}}
+{{< tab name="Mac with Intel chip" >}}
 
 - A supported version of macOS.
 
@@ -58,14 +55,20 @@ This page provides download links, system requirements, and step-by-step install
   > Docker Desktop is supported on the current and two previous major macOS releases. As new major versions of macOS are made generally available, Docker stops supporting the oldest version and supports the newest version of macOS (in addition to the previous two releases).
 
 - At least 4 GB of RAM.
-- For the best experience, it's recommended that you install Rosetta 2. Rosetta 2 is no longer strictly required, however there are a few optional command line tools that still require Rosetta 2 when using Darwin/AMD64. See [Known issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md). To install Rosetta 2 manually from the command line, run the following command:
 
-   ```console
-   $ softwareupdate --install-rosetta
-   ```
 {{< /tab >}}
 {{< /tabs >}}
 
+> **Before you install or update**
+>
+> - Quit tools that might call Docker in the background (Visual Studio Code, terminals, agent apps).
+>
+> - If you manage fleets or install via MDM, use the [**PKG installer**](/manuals/enterprise/enterprise-deployment/pkg-install-and-configure.md).
+>
+> - Keep the installer volume mounted until the installation completes.
+>
+> If you encounter a "Docker.app is damaged" dialog, see [Fix "Docker.app is damaged" on macOS](/manuals/desktop/troubleshoot-and-support/troubleshoot/mac-damaged-dialog.md).
+
 ## Install and run Docker Desktop on Mac
 
 > [!TIP]
@@ -124,7 +127,7 @@ The `install` command accepts the following flags:
 
 - `--allowed-org=<org name>`: Requires the user to sign in and be part of the specified Docker Hub organization when running the application
 - `--user=<username>`: Performs the privileged configurations once during installation. This removes the need for the user to grant root privileges on first run. For more information, see [Privileged helper permission requirements](/manuals/desktop/setup/install/mac-permission-requirements.md#permission-requirements). To find the username, enter `ls /Users` in the CLI.
-- `--admin-settings`: Automatically creates an `admin-settings.json` file which is used by administrators to control certain Docker Desktop settings on client machines within their organization. For more information, see [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md).
+- `--admin-settings`: Automatically creates an `admin-settings.json` file which is used by administrators to control certain Docker Desktop settings on client machines within their organization. For more information, see [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md).
   - It must be used together with the `--allowed-org=<org name>` flag. 
   - For example: `--allowed-org=<org name> --admin-settings="{'configurationFileVersion': 2, 'enhancedContainerIsolation': {'value': true, 'locked': false}}"`
 
@@ -134,10 +137,24 @@ The `install` command accepts the following flags:
 - `--override-proxy-http=<URL>`: Sets the URL of the HTTP proxy that must be used for outgoing HTTP requests. It requires `--proxy-http-mode` to be `manual`.
 - `--override-proxy-https=<URL>`: Sets the URL of the HTTP proxy that must be used for outgoing HTTPS requests, requires `--proxy-http-mode` to be `manual`
 - `--override-proxy-exclude=<hosts/domains>`: Bypasses proxy settings for the hosts and domains. It's a comma-separated list.
+- `--override-proxy-pac=<PAC file URL>`: Sets the PAC file URL. This setting takes effect only when using `manual` proxy mode.
+- `--override-proxy-embedded-pac=<PAC script>`: Specifies an embedded PAC (Proxy Auto-Config) script. This setting takes effect only when using `manual` proxy mode and has precedence over the `--override-proxy-pac` flag.
+
+###### Example of specifying PAC file
+
+```console
+$ sudo /Applications/Docker.app/Contents/MacOS/install --user testuser --proxy-http-mode="manual" --override-proxy-pac="http://localhost:8080/myproxy.pac"
+```
+
+###### Example of specifying PAC script
+
+```console
+$ sudo /Applications/Docker.app/Contents/MacOS/install --user testuser --proxy-http-mode="manual" --override-proxy-embedded-pac="function FindProxyForURL(url, host) { return \"DIRECT\"; }"
+```
 
 > [!TIP]
 >
-> As an IT administrator, you can use endpoint management (MDM) software to identify the number of Docker Desktop instances and their versions within your environment. This can provide accurate license reporting, help ensure your machines use the latest version of Docker Desktop, and enable you to [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md).
+> As an IT administrator, you can use endpoint management (MDM) software to identify the number of Docker Desktop instances and their versions within your environment. This can provide accurate license reporting, help ensure your machines use the latest version of Docker Desktop, and enable you to [enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md).
 > - [Intune](https://learn.microsoft.com/en-us/mem/intune/apps/app-discovered-apps)
 > - [Jamf](https://docs.jamf.com/10.25.0/jamf-pro/administrator-guide/Application_Usage.html)
 > - [Kandji](https://support.kandji.io/support/solutions/articles/72000559793-view-a-device-application-list)
@@ -146,7 +163,7 @@ The `install` command accepts the following flags:
 
 ## Where to go next
 
-- Explore [Docker's subscriptions](https://www.docker.com/pricing/) to see what Docker can offer you.
+- Explore [Docker's subscriptions](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopMacInstall) to see what Docker can offer you.
 - [Get started with Docker](/get-started/introduction/_index.md).
 - [Explore Docker Desktop](/manuals/desktop/use-desktop/_index.md) and all its features.
 - [Troubleshooting](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md) describes common problems, workarounds, how
diff --git a/content/manuals/desktop/setup/install/mac-permission-requirements.md b/content/manuals/desktop/setup/install/mac-permission-requirements.md
index 564f4e5be986..34bc7d7e2ff8 100644
--- a/content/manuals/desktop/setup/install/mac-permission-requirements.md
+++ b/content/manuals/desktop/setup/install/mac-permission-requirements.md
@@ -5,10 +5,7 @@ keywords: Docker Desktop, mac, security, install, permissions
 title: Understand permission requirements for Docker Desktop on Mac
 linkTitle: Mac permission requirements
 aliases:
-- /docker-for-mac/privileged-helper/
-- /desktop/mac/privileged-helper/
 - /desktop/mac/permission-requirements/
-- /desktop/install/mac-permission-requirements/
 weight: 20
 ---
 
@@ -93,6 +90,17 @@ $ rm /Library/LaunchDaemons/com.docker.vmnetd.plist
 $ rm /Library/PrivilegedHelperTools/com.docker.vmnetd
 ```
 
+## Backend helper socket
+
+Aside from the optional [privileged helper](#privileged-helper), the Docker
+Desktop backend process (`com.docker.backend`) uses an internal helper socket
+(`~/Library/Containers/com.docker.docker/Data/forkexecd.sock`) to fork and execute
+helper processes as part of running Docker Desktop.
+
+Unlike the privileged helper, this socket does not run as `root` and grants no
+elevated privileges. It is owned by, and accessible only to, the same macOS user
+running Docker Desktop, and is contained in Docker Desktop's application container.
+
 ## Containers running as root within the Linux VM
 
 With Docker Desktop, the Docker daemon and containers run in a lightweight Linux
@@ -105,7 +113,7 @@ retain their original permissions.
 ## Enhanced Container Isolation
 
 In addition, Docker Desktop supports [Enhanced Container Isolation
-mode](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md) (ECI),
+mode](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md) (ECI),
 available to Business customers only, which further secures containers without
 impacting developer workflows.
 
diff --git a/content/manuals/desktop/setup/install/windows-install.md b/content/manuals/desktop/setup/install/windows-install.md
index 259eab642863..af06573c64ba 100644
--- a/content/manuals/desktop/setup/install/windows-install.md
+++ b/content/manuals/desktop/setup/install/windows-install.md
@@ -9,15 +9,9 @@ linkTitle: Windows
 weight: 30
 aliases:
 - /desktop/windows/install/
-- /docker-ee-for-windows/install/
-- /docker-for-windows/install-windows-home/
 - /docker-for-windows/install/
-- /ee/docker-ee/windows/docker-ee/
 - /engine/installation/windows/
 - /engine/installation/windows/docker-ee/
-- /install/windows/docker-ee/
-- /install/windows/ee-preview/
-- /installation/windows/
 - /desktop/win/configuring-wsl/
 - /desktop/install/windows-install/
 ---
@@ -26,38 +20,56 @@ aliases:
 >
 > Commercial use of Docker Desktop in larger enterprises (more than 250
 > employees OR more than $10 million USD in annual revenue) requires a [paid
-> subscription](https://www.docker.com/pricing/).
+> subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopWindowsInstall).
 
 This page provides download links, system requirements, and step-by-step installation instructions for Docker Desktop on Windows.
 
 {{< button text="Docker Desktop for Windows - x86_64" url="https://desktop.docker.com/win/main/amd64/Docker%20Desktop%20Installer.exe?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-win-amd64" >}}
 {{< button text="Docker Desktop for Windows - x86_64 on the Microsoft Store" url="https://apps.microsoft.com/detail/xp8cbj40xlbwkx?hl=en-GB&gl=GB" >}}
-{{< button text="Docker Desktop for Windows - Arm (Beta)" url="https://desktop.docker.com/win/main/arm64/Docker%20Desktop%20Installer.exe?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-win-arm64" >}}
+{{< button text="Docker Desktop for Windows - Arm (Early Access)" url="https://desktop.docker.com/win/main/arm64/Docker%20Desktop%20Installer.exe?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-win-arm64" >}}
 
 _For checksums, see [Release notes](/manuals/desktop/release-notes.md)_
 
+## Installation modes
+ 
+Docker Desktop supports two installation modes. Per-user installation is recommended for most users and is selected by default in the installer. It does not require administrator privileges to install or update, and the WSL 2 backend it uses covers the needs of the vast majority of Docker Desktop users.
+ 
+| | Per-user (recommended) | All users |
+|---|---|---|
+| Install location | `%LOCALAPPDATA%\Programs\DockerDesktop` | `C:\Program Files\Docker\Docker` |
+| Registry keys | Current User (HKCU) | Local Machine (HKLM) |
+| Admin rights to install | Not required | Required |
+| Admin rights to update | Not required | Required |
+| Linux containers backend | WSL 2 or Docker VMM | WSL 2, Hyper-V, or Docker VMM |
+| Windows containers | Not supported | Supported |
+| Security | Smaller attack surface; no privileged system service installed | Requires privileged system service; broader access to host resources |
+
+For more information, see [Understand permission requirements for Windows](./windows-permission-requirements.md).
+
 ## System requirements
 
 > [!TIP]
 >
-> **Should I use Hyper-V or WSL?**
+> **Which backend should I use?**
 >
-> Docker Desktop's functionality remains consistent on both WSL and Hyper-V, without a preference for either architecture. Hyper-V and WSL have their own advantages and disadvantages, depending on your specific setup and your planned use case. 
+> Docker Desktop for Windows supports three backends: WSL 2, Hyper-V, and Docker VMM (Beta). WSL 2 is the default and works for most users without administrator privileges. Hyper-V is only available with all-users installation. Docker VMM is a container-optimized hypervisor that reclaims idle memory and improves file I/O. For more information, see [Virtual Machine Manager](/manuals/desktop/features/vmm.md).
 
 {{< tabs >}}
 {{< tab name="WSL 2 backend, x86_64" >}}
 
-- WSL version 1.1.3.0 or later.
-- Windows 11 64-bit: Home or Pro version 22H2 or higher, or Enterprise or Education version 22H2 or higher.
-- Windows 10 64-bit: Minimum required is Home or Pro 22H2 (build 19045) or higher, or Enterprise or Education 22H2 (build 19045) or higher. 
+- WSL version 2.1.5 or later. To check your version, see [WSL: Verification and setup](#wsl-verification-and-setup)
+- If you intend to use Enhanced Container Isolation, ensure you’re using WSL version 2.6 or later. This is required because ECI depends on a Linux kernel version of at least 6.3.0, and WSL 2.6+ bundles Linux kernel version 6.6.
+- Windows 10 64-bit: Enterprise, Pro, or Education version 22H2 (build 19045).
+- Windows 11 64-bit: Enterprise, Pro, or Education version 23H2 (build 22631) or higher.
+- The Windows Server service (LanmanServer) must be enabled and its start mode set to **Automatic**.
 - Turn on the WSL 2 feature on Windows. For detailed instructions, refer to the
   [Microsoft documentation](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
 - The following hardware prerequisites are required to successfully run
   WSL 2 on Windows 10 or Windows 11:
   - 64-bit processor with [Second Level Address Translation (SLAT)](https://en.wikipedia.org/wiki/Second_Level_Address_Translation)
-  - 4GB system RAM
+  - 8GB system RAM
   - Enable hardware virtualization in BIOS/UEFI. For more information, see
-    [Virtualization](/manuals/desktop/troubleshoot-and-support/troubleshoot/topics.md#virtualization).
+    [Virtualization](/manuals/desktop/troubleshoot-and-support/troubleshoot/topics.md#docker-desktop-fails-due-to-virtualization-not-working).
 
 For more information on setting up WSL 2 with Docker Desktop, see [WSL](/manuals/desktop/features/wsl/_index.md).
 
@@ -67,20 +79,21 @@ For more information on setting up WSL 2 with Docker Desktop, see [WSL](/manuals
 
 > [!IMPORTANT]
 >
-> To run Windows containers, you need Windows 10 or Windows 11 Professional or Enterprise edition.
+> To run [Windows containers](#windows-containers), you need Windows 10 or Windows 11 Professional or Enterprise edition.
 > Windows Home or Education editions only allow you to run Linux containers.
 
 {{< /tab >}}
 {{< tab name="Hyper-V backend, x86_64" >}}
 
-- Windows 11 64-bit: Enterprise, Pro, or Education version 22H2 or higher.
-- Windows 10 64-bit: Enterprise, Pro, or Education version 22H2 (build 19045) or higher.
+- Windows 10 64-bit: Enterprise, Pro, or Education version 22H2 (build 19045).
+- Windows 11 64-bit: Enterprise, Pro, or Education version 23H2 (build 22631) or higher.
+- The Windows Server service (LanmanServer) must be enabled and its start mode set to **Automatic**.
 - Turn on Hyper-V and Containers Windows features.
 - The following hardware prerequisites are required to successfully run Client
   Hyper-V on Windows 10:
 
   - 64 bit processor with [Second Level Address Translation (SLAT)](https://en.wikipedia.org/wiki/Second_Level_Address_Translation)
-  - 4GB system RAM
+  - 8GB system RAM
   - Turn on BIOS/UEFI-level hardware virtualization support in the
     BIOS/UEFI settings. For more information, see
     [Virtualization](/manuals/desktop/troubleshoot-and-support/troubleshoot/topics.md#virtualization).
@@ -91,21 +104,22 @@ For more information on setting up WSL 2 with Docker Desktop, see [WSL](/manuals
 
 > [!IMPORTANT]
 >
-> To run Windows containers, you need Windows 10 or Windows 11 Professional or Enterprise edition.
+> To run [Windows containers](#windows-containers), you need Windows 10 or Windows 11 Professional or Enterprise edition.
 > Windows Home or Education editions only allow you to run Linux containers.
 
 {{< /tab >}}
-{{< tab name="WSL 2 backend, Arm (Beta)" >}}
+{{< tab name="WSL 2 backend, Arm (Early Access)" >}}
 
-- WSL version 1.1.3.0 or later.
-- Windows 11 64-bit: Home or Pro version 22H2 or higher, or Enterprise or Education version 22H2 or higher.
-- Windows 10 64-bit: Minimum required is Home or Pro 22H2 (build 19045) or higher, or Enterprise or Education 22H2 (build 19045) or higher.
+- WSL version 2.1.5 or later. To check your version, see [WSL: Verification and setup](#wsl-verification-and-setup)
+- Windows 10 64-bit: Enterprise, Pro, or Education version 22H2 (build 19045).
+- Windows 11 64-bit: Enterprise, Pro, or Education version 23H2 (build 22631) or higher.
+- The Windows Server service (LanmanServer) must be enabled and its start mode set to **Automatic**.
 - Turn on the WSL 2 feature on Windows. For detailed instructions, refer to the
   [Microsoft documentation](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
 - The following hardware prerequisites are required to successfully run
   WSL 2 on Windows 10 or Windows 11:
   - 64-bit processor with [Second Level Address Translation (SLAT)](https://en.wikipedia.org/wiki/Second_Level_Address_Translation)
-  - 4GB system RAM
+  - 8GB system RAM
   - Enable hardware virtualization in BIOS/UEFI. For more information, see
     [Virtualization](/manuals/desktop/troubleshoot-and-support/troubleshoot/topics.md#virtualization).
 
@@ -124,53 +138,19 @@ Running Docker Desktop inside a VMware ESXi or Azure VM is supported for Docker
 It requires enabling nested virtualization on the hypervisor first.
 For more information, see [Running Docker Desktop in a VM or VDI environment](/manuals/desktop/setup/vm-vdi.md).
 
-{{< accordion title="How do I switch between Windows and Linux containers?" >}}
-
-From the Docker Desktop menu, you can toggle which daemon (Linux or Windows)
-the Docker CLI talks to. Select **Switch to Windows containers** to use Windows
-containers, or select **Switch to Linux containers** to use Linux containers
-(the default).
-
-For more information on Windows containers, refer to the following documentation:
-
-- Microsoft documentation on [Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/index).
-
-- [Build and Run Your First Windows Server Container (Blog Post)](https://www.docker.com/blog/build-your-first-docker-windows-server-container/)
-  gives a quick tour of how to build and run native Docker Windows containers on Windows 10 and Windows Server 2016 evaluation releases.
-
-- [Getting Started with Windows Containers (Lab)](https://github.com/docker/labs/blob/master/windows/windows-containers/README.md)
-  shows you how to use the [MusicStore](https://github.com/aspnet/MusicStore/)
-  application with Windows containers. The MusicStore is a standard .NET application and,
-  [forked here to use containers](https://github.com/friism/MusicStore), is a good example of a multi-container application.
-
-- To understand how to connect to Windows containers from the local host, see
-  [I want to connect to a container from Windows](/manuals/desktop/features/networking.md#i-want-to-connect-to-a-container-from-the-host)
-
-> [!NOTE]
->
-> When you switch to Windows containers, **Settings** only shows those tabs that are active and apply to your Windows containers.
-
-If you set proxies or daemon configuration in Windows containers mode, these
-apply only on Windows containers. If you switch back to Linux containers,
-proxies and daemon configurations return to what you had set for Linux
-containers. Your Windows container settings are retained and become available
-again when you switch back.
-
-{{< /accordion >}}
-
 ## Install Docker Desktop on Windows
 
-> [!TIP]
->
-> See the [FAQs](/manuals/desktop/troubleshoot-and-support/faqs/general.md#how-do-i-run-docker-desktop-without-administrator-privileges) on how to install and run Docker Desktop without needing administrator privileges.
-
 ### Install interactively
 
 1. Download the installer using the download button at the top of the page, or from the [release notes](/manuals/desktop/release-notes.md).
 
-2. Double-click `Docker Desktop Installer.exe` to run the installer. By default, Docker Desktop is installed at `C:\Program Files\Docker\Docker`.
+2. Double-click `Docker Desktop Installer.exe` to run the installer. The installer will ask which installation mode you prefer. Choosing per-user installs to `%LOCALAPPDATA%\Programs\DockerDesktop` and requires no administrator privileges. Choosing all users will prompt for elevation.
+
+   > [!NOTE]
+   >
+   >If you want to switch installation mode at a later date, you need to uninstall and reinstall Docker Desktop.
 
-3. When prompted, ensure the **Use WSL 2 instead of Hyper-V** option on the Configuration page is selected or not depending on your choice of backend.
+3. When prompted, select your backend on the Configuration page: **Use WSL 2 instead of Hyper-V** for WSL 2, or leave it unselected for Hyper-V. You can switch to Docker VMM after installation from **Settings** > **General**.
 
     On systems that support only one backend, Docker Desktop automatically selects the available option.
 
@@ -180,35 +160,118 @@ again when you switch back.
 
 6. [Start Docker Desktop](#start-docker-desktop).
 
-If your administrator account is different to your user account, you must add the user to the **docker-users** group:
-1. Run **Computer Management** as an **administrator**.
-2. Navigate to **Local Users and Groups** > **Groups** > **docker-users**. 
-3. Right-click to add the user to the group.
-4. Sign out and sign back in for the changes to take effect.
-
 ### Install from the command line
 
-After downloading `Docker Desktop Installer.exe`, run the following command in a terminal to install Docker Desktop:
+After downloading `Docker Desktop Installer.exe`, run the following command in a terminal to install Docker Desktop to `%LOCALAPPDATA%\Programs\DockerDesktop`.
+
+For per-user installation, run:
 
 ```console
-$ "Docker Desktop Installer.exe" install
+$ "Docker Desktop Installer.exe" install --user
 ```
 
-If you’re using PowerShell you should run it as:
+To install for all users on the machine (requires administrator privileges):
+ 
+```console
+$ "Docker Desktop Installer.exe" install
+```
 
+If you're using PowerShell you should run it as:
+ 
 ```powershell
+# Per-user installation (no admin required)
+Start-Process 'Docker Desktop Installer.exe' -Wait -ArgumentList 'install', '--user'
+ 
+# All-users installation (run as administrator)
 Start-Process 'Docker Desktop Installer.exe' -Wait install
 ```
 
 If using the Windows Command Prompt:
-
+ 
 ```sh
+# Per-user installation (no admin required)
+start /w "" "Docker Desktop Installer.exe" install --user
+ 
+# All-users installation (run as administrator)
 start /w "" "Docker Desktop Installer.exe" install
 ```
 
-By default, Docker Desktop is installed at `C:\Program Files\Docker\Docker`.
+If using all-users installation and your administrator account is different to your user account, you must add the user to the **docker-users** group to access features that require higher privileges, such as creating and managing the Hyper-V VM, or using Windows containers:
+
+```console
+$ net localgroup docker-users <user> /add
+```
+
+> [!WARNING]
+>
+> Membership in `docker-users` grants access to the Docker daemon socket, which is equivalent to granting administrative privileges on the host. Only add users who require access to Windows containers or Hyper-V VM management. For Linux containers using the WSL 2 backend, this group membership is not required. See [Protect the Docker daemon socket](/manuals/engine/security/protect-access.md) for more information.
+
+If you're deploying via MDM (such as Intune) and the `docker-users` group isn't populated automatically, see [Why isn't the `docker-users` group populated when the MSI is installed with Intune or another MDM solution?](/manuals/enterprise/enterprise-deployment/faq.md#why-isnt-the-docker-users-group-populated-when-the-msi-is-installed-with-intune-or-another-mdm-solution).
+
+See the [Installer flags](#installer-flags) section to see what flags the `install` command accepts.
+
+> [!NOTE]
+>
+>If you want to switch installation mode at a later date, you need to uninstall and reinstall Docker Desktop.
+
+## Start Docker Desktop
+
+Docker Desktop does not start automatically after installation. To start Docker Desktop:
+
+1. Search for Docker, and select **Docker Desktop** in the search results.
+
+2. The Docker menu ({{< inline-image src="images/whale-x.svg" alt="whale menu" >}}) displays the Docker Subscription Service Agreement.
+
+   {{% include "desktop-license-update.md" %}}
+
+3. Select **Accept** to continue. Docker Desktop starts after you accept the terms.
+
+   Note that Docker Desktop won't run if you do not agree to the terms. You can choose to accept the terms at a later date by opening Docker Desktop.
+
+   For more information, see [Docker Desktop Subscription Service Agreement](https://www.docker.com/legal/docker-subscription-service-agreement/). It is recommended that you read the [FAQs](https://www.docker.com/pricing/faq).
+
+> [!TIP]
+>
+> As an IT administrator, you can use endpoint management (MDM) software to identify the number of Docker Desktop instances and their versions within your environment. This can provide accurate license reporting, help ensure your machines use the latest version of Docker Desktop, and enable you to [enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md).
+> - [Intune](https://learn.microsoft.com/en-us/mem/intune/apps/app-discovered-apps)
+> - [Jamf](https://docs.jamf.com/10.25.0/jamf-pro/administrator-guide/Application_Usage.html)
+> - [Kandji](https://support.kandji.io/support/solutions/articles/72000559793-view-a-device-application-list)
+> - [Kolide](https://www.kolide.com/features/device-inventory/properties/mac-apps)
+> - [Workspace One](https://blogs.vmware.com/euc/2022/11/how-to-use-workspace-one-intelligence-to-manage-app-licenses-and-reduce-costs.html)
+
+
+## Advanced system configuration and installation options
+
+### WSL: Verification and setup
+
+If you have chosen to use WSL, first verify that your installed version meets system requirements by running the following command in your terminal:
+
+```console
+wsl --version
+```
+
+If version details do not appear, you are likely using the inbox version of WSL. This version does not support modern capabilities and must be updated.
+
+You can update or install WSL using one of the following methods:
+
+#### Option 1: Install or update WSL via the terminal
+
+1. Open PowerShell or Windows Command Prompt in administrator mode.
+2. Run either the install or update command. You may be prompted to restart your machine. For more information, refer to [Install WSL](https://learn.microsoft.com/en-us/windows/wsl/install).
+```console
+wsl --install
+
+wsl --update
+```
+
+#### Option 2: Install WSL via the MSI package
 
-#### Installer flags
+If Microsoft Store access is blocked due to security policies:
+1. Go to the official [WSL GitHub Releases page](https://github.com/microsoft/WSL/releases).
+2. Download the `.msi` installer from the latest stable release (under the Assets drop-down).
+3. Run the downloaded installer and follow the setup instructions.
+
+### Installer flags
 
 > [!NOTE]
 >
@@ -218,72 +281,101 @@ By default, Docker Desktop is installed at `C:\Program Files\Docker\Docker`.
 > Start-Process 'Docker Desktop Installer.exe' -Wait -ArgumentList 'install', '--accept-license'
 > ```
 
-If your admin account is different to your user account, you must add the user to the **docker-users** group:
-
-```console
-$ net localgroup docker-users <user> /add
-```
-
-The `install` command accepts the following flags:
+#### Installation behavior
 
-##### Installation behavior
 
+- `--user`: Installs Docker Desktop in per-user mode, to `%LOCALAPPDATA%\Programs\DockerDesktop`. No administrator privileges are required. This is the recommended mode for most users. See [Installation modes](#installation-modes).
 - `--quiet`: Suppresses information output when running the installer 
 - `--accept-license`: Accepts the [Docker Subscription Service Agreement](https://www.docker.com/legal/docker-subscription-service-agreement) now, rather than requiring it to be accepted when the application is first run
 - `--installation-dir=<path>`: Changes the default installation location (`C:\Program Files\Docker\Docker`)
 - `--backend=<backend name>`: Selects the default backend to use for Docker Desktop, `hyper-v`, `windows` or `wsl-2` (default)
 - `--always-run-service`: After installation completes, starts `com.docker.service` and sets the service startup type to Automatic. This circumvents the need for administrator privileges, which are otherwise necessary to start `com.docker.service`. `com.docker.service` is required by Windows containers and Hyper-V backend.
 
-##### Security and access control
+#### Security and access control
 
 - `--allowed-org=<org name>`: Requires the user to sign in and be part of the specified Docker Hub organization when running the application
-- `--admin-settings`: Automatically creates an `admin-settings.json` file which is used by admins to control certain Docker Desktop settings on client machines within their organization. For more information, see [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md).
+- `--admin-settings`: Automatically creates an `admin-settings.json` file which is used by admins to control certain Docker Desktop settings on client machines within their organization. For more information, see [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md).
   - It must be used together with the `--allowed-org=<org name>` flag. 
   - For example:`--allowed-org=<org name> --admin-settings="{'configurationFileVersion': 2, 'enhancedContainerIsolation': {'value': true, 'locked': false}}"`
 - `--no-windows-containers`: Disables the Windows containers integration. This can improve security. For more information, see [Windows containers](/manuals/desktop/setup/install/windows-permission-requirements.md#windows-containers).
 
-##### Proxy configuration
+#### Proxy configuration
 
 - `--proxy-http-mode=<mode>`: Sets the HTTP Proxy mode, `system` (default) or `manual`
 - `--override-proxy-http=<URL>`: Sets the URL of the HTTP proxy that must be used for outgoing HTTP requests, requires `--proxy-http-mode` to be `manual`
 - `--override-proxy-https=<URL>`: Sets the URL of the HTTP proxy that must be used for outgoing HTTPS requests, requires `--proxy-http-mode` to be `manual`
 - `--override-proxy-exclude=<hosts/domains>`: Bypasses proxy settings for the hosts and domains. Uses a comma-separated list.
 - `--proxy-enable-kerberosntlm`: Enables Kerberos and NTLM proxy authentication. If you are enabling this, ensure your proxy server is properly configured for Kerberos/NTLM authentication. Available with Docker Desktop 4.32 and later.
+- `--override-proxy-pac=<PAC file URL>`: Sets the PAC file URL. This setting takes effect only when using `manual` proxy mode.
+- `--override-proxy-embedded-pac=<PAC script>`: Specifies an embedded PAC (Proxy Auto-Config) script. This setting takes effect only when using `manual` proxy mode and has precedence over the `--override-proxy-pac` flag.
+
+##### Example of specifying PAC file
+
+```console
+"Docker Desktop Installer.exe" install --proxy-http-mode="manual" --override-proxy-pac="http://localhost:8080/myproxy.pac"
+```
 
-##### Data root and disk location
+##### Example of specifying PAC script
+
+```console
+"Docker Desktop Installer.exe" install --proxy-http-mode="manual" --override-proxy-embedded-pac="function FindProxyForURL(url, host) { return \"DIRECT\"; }"
+```
+
+#### Data root and disk location
 
 - `--hyper-v-default-data-root=<path>`: Specifies the default location for the Hyper-V VM disk. 
 - `--windows-containers-default-data-root=<path>`: Specifies the default location for the Windows containers.
 - `--wsl-default-data-root=<path>`: Specifies the default location for the WSL distribution disk.
 
-## Start Docker Desktop
+### Administrator privileges
 
-Docker Desktop does not start automatically after installation. To start Docker Desktop:
+In per-user mode, Docker Desktop can be installed and updated without administrator privileges. Some settings still require elevation and are marked **Requires password** in the Settings UI. Enabling WSL 2 for the first time also requires administrator privileges, but this is a one-time, per-machine operation.
 
-1. Search for Docker, and select **Docker Desktop** in the search results.
+In all-users mode, installing Docker Desktop requires administrator privileges. However, once installed, it can be used without administrative access. Some actions, though, still need elevated permissions. See [Understand permission requirements for Windows](./windows-permission-requirements.md) for more detail.
 
-2. The Docker menu ({{< inline-image src="images/whale-x.svg" alt="whale menu" >}}) displays the Docker Subscription Service Agreement.
+See the [FAQs](/manuals/desktop/troubleshoot-and-support/faqs/general.md#how-do-i-run-docker-desktop-without-administrator-privileges) on how to install and run Docker Desktop without needing administrator privileges.
 
-   {{% include "desktop-license-update.md" %}}
+If you're an IT admin and your users do not have administrator rights and plan to perform operations that require elevated privileges, be sure to install Docker Desktop using the `--always-run-service` installer flag. This ensures those actions can still be executed without prompting for User Account Control (UAC) elevation. See [Installer Flags](#installer-flags) for more detail.
 
-3. Select **Accept** to continue. Docker Desktop starts after you accept the terms.
+### Windows containers
 
-   Note that Docker Desktop won't run if you do not agree to the terms. You can choose to accept the terms at a later date by opening Docker Desktop.
+> [!NOTE]
+>
+> Windows containers are only supported in all-users installation mode. They are not available when Docker Desktop is installed per-user.
 
-   For more information, see [Docker Desktop Subscription Service Agreement](https://www.docker.com/legal/docker-subscription-service-agreement/). It is recommended that you read the [FAQs](https://www.docker.com/pricing/faq).
+From the Docker Desktop menu, you can toggle which daemon (Linux or Windows)
+the Docker CLI talks to. Select **Switch to Windows containers** to use Windows
+containers, or select **Switch to Linux containers** to use Linux containers
+(the default).
 
-> [!TIP]
+For more information on Windows containers, refer to the following documentation:
+
+- Microsoft documentation on [Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/index).
+
+- [Build and Run Your First Windows Server Container (Blog Post)](https://www.docker.com/blog/build-your-first-docker-windows-server-container/)
+  gives a quick tour of how to build and run native Docker Windows containers on Windows 10 and Windows Server 2016 evaluation releases.
+
+- [Getting Started with Windows Containers (Lab)](https://github.com/docker/labs/blob/master/windows/windows-containers/README.md)
+  shows you how to use the [MusicStore](https://github.com/aspnet/MusicStore/)
+  application with Windows containers. The MusicStore is a standard .NET application and,
+  [forked here to use containers](https://github.com/friism/MusicStore), is a good example of a multi-container application.
+
+- To understand how to connect to Windows containers from the local host, see
+  [I want to connect to a container from Windows](/manuals/desktop/features/networking.md#i-want-to-connect-to-a-container-from-the-host)
+
+> [!NOTE]
 >
-> As an IT administrator, you can use endpoint management (MDM) software to identify the number of Docker Desktop instances and their versions within your environment. This can provide accurate license reporting, help ensure your machines use the latest version of Docker Desktop, and enable you to [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md).
-> - [Intune](https://learn.microsoft.com/en-us/mem/intune/apps/app-discovered-apps)
-> - [Jamf](https://docs.jamf.com/10.25.0/jamf-pro/administrator-guide/Application_Usage.html)
-> - [Kandji](https://support.kandji.io/support/solutions/articles/72000559793-view-a-device-application-list)
-> - [Kolide](https://www.kolide.com/features/device-inventory/properties/mac-apps)
-> - [Workspace One](https://blogs.vmware.com/euc/2022/11/how-to-use-workspace-one-intelligence-to-manage-app-licenses-and-reduce-costs.html)
+> When you switch to Windows containers, **Settings** only shows those tabs that are active and apply to your Windows containers.
+
+If you set proxies or daemon configuration in Windows containers mode, these
+apply only on Windows containers. If you switch back to Linux containers,
+proxies and daemon configurations return to what you had set for Linux
+containers. Your Windows container settings are retained and become available
+again when you switch back.
 
 ## Where to go next
 
-- Explore [Docker's subscriptions](https://www.docker.com/pricing/) to see what Docker can offer you.
+- Explore [Docker's subscriptions](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopWindowsInstall) to see what Docker can offer you.
 - [Get started with Docker](/get-started/introduction/_index.md).
 - [Explore Docker Desktop](/manuals/desktop/use-desktop/_index.md) and all its features.
 - [Troubleshooting](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md) describes common problems, workarounds, and
diff --git a/content/manuals/desktop/setup/install/windows-permission-requirements.md b/content/manuals/desktop/setup/install/windows-permission-requirements.md
index 9ae094f312e6..c4b06f1be930 100644
--- a/content/manuals/desktop/setup/install/windows-permission-requirements.md
+++ b/content/manuals/desktop/setup/install/windows-permission-requirements.md
@@ -3,27 +3,63 @@ description: Understand permission requirements for Docker Desktop for Windows
 keywords: Docker Desktop, Windows, security, install
 title: Understand permission requirements for Windows
 linkTitle: Windows permission requirements
-aliases:
-- /desktop/windows/privileged-helper/
-- /desktop/windows/permission-requirements/
-- /desktop/install/windows-permission-requirements/
 weight: 40
+aliases:
+  - /desktop/windows/permission-requirements/
 ---
 
 This page contains information about the permission requirements for running and installing Docker Desktop on Windows, the functionality of the privileged helper process `com.docker.service`, and the reasoning behind this approach.
 
-It also provides clarity on running containers as `root` as opposed to having `Administrator` access on the host and the privileges of the Windows Docker engine and Windows containers.
+It also provides clarity on running containers as `root` as opposed to having `Administrator` access on the host and the privileges of Docker Engine and Windows containers.
 
 Docker Desktop on Windows is designed with security in mind. Administrative rights are only required when absolutely necessary.
 
 ## Permission requirements
 
-While Docker Desktop on Windows can be run without having `Administrator` privileges, it does require them during installation. On installation you receive a UAC prompt which allows a privileged helper service to be installed. After that, Docker Desktop can be run without administrator privileges, provided you are members of the `docker-users` group. If you performed the installation, you are automatically added to this group, but other users must be added manually. This allows the administrator to control who has access to Docker Desktop.
-
-The reason for this approach is that Docker Desktop needs to perform a limited set of privileged operations which are conducted by the privileged helper process `com.docker.service`. This approach allows, following the principle of least privilege, `Administrator` access to be used only for the operations for which it is absolutely necessary, while still being able to use Docker Desktop as an unprivileged user.
+The permissions required to install and run Docker Desktop depend on which [installation mode](/manuals/desktop/setup/install/windows-install.md#installation-modes) you use.
+ 
+### Per-user installation
+ 
+In per-user mode, Docker Desktop installs to `%LOCALAPPDATA%\Programs\DockerDesktop` and writes only to current-user registry keys (`HKCU`). This means:
+ 
+- No administrator privileges are required to install or update Docker Desktop.
+- After installation, Docker Desktop can be run without administrator privileges.
+- Some settings marked **Requires password** in **Settings** still require elevation. When you change one of these settings and select **Apply**, Docker Desktop opens a UAC prompt for administrator access.
+ 
+Per-user installation does not install the privileged helper service `com.docker.service` automatically. As a result, features that depend on it, such as the Hyper-V backend and Windows containers, are not available. Docker VMM (Beta) is available in per-user mode and does not require the privileged helper. For most users, the WSL 2 or Docker VMM backend covers the majority of use cases.
+ 
+### All-users installation
+ 
+In all-users mode, Docker Desktop installs to `C:\Program Files\Docker\Docker` and writes to Local Machine registry keys (`HKLM`). Both locations require administrator privileges to modify, so:
+ 
+- Administrator privileges are required to install and update Docker Desktop.
+- On installation you receive a UAC prompt which allows the privileged helper service `com.docker.service` to be installed.
+- After installation, Docker Desktop can be run without administrator privileges.
+ 
+Running Docker Desktop without the privileged helper does not require users to have `docker-users` group membership. However, some features that require privileged operations will have this requirement.
+ 
+If you performed the installation, you are automatically added to the `docker-users` group, but other users must be added manually. This allows the administrator to control who has access to features that require higher privileges, such as creating and managing the Hyper-V VM, or using Windows containers.
+ 
+When Docker Desktop launches, all non-privileged named pipes are created so that only the following users can access them:
+- The user that launched Docker Desktop.
+- Members of the local `Administrators` group.
+- The `LOCALSYSTEM` account.
+ 
+### Operations that always require elevation
+ 
+The following require administrator privileges regardless of installation mode.
+ 
+- Enabling WSL 2 for the first time: WSL 2 must be enabled on the machine before Docker Desktop can run. This is a one-time, per-machine operation. Once WSL 2 is enabled, it does not need to be enabled again for subsequent Docker Desktop installs or updates.
+- Settings marked **Requires password**: Certain Docker Desktop settings affect system-level configuration and require administrator credentials to apply. These are clearly marked **Requires password**. When you change one of these settings and select **Apply**, Docker Desktop prompts for administrator credentials.
 
 ## Privileged helper
 
+Docker Desktop needs to perform a limited set of privileged operations which are conducted by the privileged helper process `com.docker.service`. This approach allows, following the principle of least privilege, `Administrator` access to be used only for the operations for which it is absolutely necessary, while still being able to use Docker Desktop as an unprivileged user.
+
+> [!NOTE]
+>
+> `com.docker.service` is only installed in all-users installation mode. It is not used in per-user installation, which relies on the WSL 2 or Docker VMM backend and does not support Hyper-V or Windows containers.
+
 The privileged helper `com.docker.service` is a Windows service which runs in the background with `SYSTEM` privileges. It listens on the named pipe `//./pipe/dockerBackendV2`. The developer runs the Docker Desktop application, which connects to the named pipe and sends commands to the service. This named pipe is protected, and only users that are part of the `docker-users` group can have access to it.
 
 The service performs the following functionalities:
@@ -57,7 +93,7 @@ into Docker containers still retain their original permissions.  Containers don'
 ## Enhanced Container Isolation
 
 In addition, Docker Desktop supports [Enhanced Container Isolation
-mode](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md) (ECI),
+mode](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md) (ECI),
 available to Business customers only, which further secures containers without
 impacting developer workflows.
 
@@ -73,6 +109,10 @@ isolated from the Docker daemon and other services running inside the VM.
 >
 > Enabling Windows containers has important security implications.
 
+> [!NOTE]
+>
+> Windows containers are only supported in all-users installation mode. They are not available when Docker Desktop is installed per-user. See [Installation modes](/manuals/desktop/setup/install/windows-install.md#installation-modes).
+
 Unlike the Linux Docker Engine and containers which run in a VM, Windows containers are implemented using operating system features, and run directly on the Windows host. If you enable Windows containers during installation, the `ContainerAdministrator` user used for administration inside the container is a local administrator on the host machine. Enabling Windows containers during installation makes it so that members of the `docker-users` group are able to elevate to administrators on the host. For organizations who don't want their developers to run Windows containers, a `-–no-windows-containers` installer flag is available to disable their use.
 
 ## Networking
diff --git a/content/manuals/desktop/setup/sign-in.md b/content/manuals/desktop/setup/sign-in.md
index d05abf62592d..01b04cab60d5 100644
--- a/content/manuals/desktop/setup/sign-in.md
+++ b/content/manuals/desktop/setup/sign-in.md
@@ -8,35 +8,20 @@ linkTitle: Sign in
 weight: 40
 aliases:
 - /desktop/linux/
-- /desktop/linux/index/
 - /desktop/mac/
-- /desktop/mac/index/
 - /desktop/windows/
-- /desktop/windows/index/
 - /docker-for-mac/
-- /docker-for-mac/index/
-- /docker-for-mac/osx/
-- /docker-for-mac/started/
 - /docker-for-windows/
-- /docker-for-windows/index/
-- /docker-for-windows/started/
-- /mac/
-- /mackit/
-- /mackit/getting-started/
-- /win/
-- /windows/
-- /winkit/
-- /winkit/getting-started/
 - /desktop/get-started/
 ---
 
 Docker recommends signing in with the **Sign in** option in the top-right corner of the Docker Dashboard. 
 
-In large enterprises where admin access is restricted, administrators can [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md). 
+In large enterprises where admin access is restricted, administrators can [enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md). 
 
 > [!TIP]
 >
-> Explore [Docker's core subscriptions](https://www.docker.com/pricing/) to see what else Docker can offer you. 
+> Explore [Docker's core subscriptions](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopSignIn) to see what else Docker can offer you. 
 
 ## Benefits of signing in
 
@@ -44,7 +29,7 @@ In large enterprises where admin access is restricted, administrators can [enfor
 
 - Increase your pull rate limit compared to anonymous users. See [Usage and limits](/manuals/docker-hub/usage/_index.md).
 
-- Enhance your organization’s security posture for containerized development with [Hardened Desktop](/manuals/security/for-admins/hardened-desktop/_index.md).
+- Enhance your organization’s security posture for containerized development with [Hardened Desktop](/manuals/enterprise/security/hardened-desktop/_index.md).
 
 > [!NOTE]
 >
@@ -71,10 +56,10 @@ Docker Desktop displays a warning if `pass` is not configured.
     3ABCD1234EF56G78
    uid          Molly <molly@example.com>
    ```
-3. Copy the GPG ID and use it to initialize `pass`
+3. Copy the GPG ID and use it to initialize `pass`. For example
 
    ```console
-   $ pass init <your_generated_gpg-id_public_key>
+   $ pass init 3ABCD1234EF56G78
    ``` 
 
    You should see output similar to: 
diff --git a/content/manuals/desktop/setup/vm-vdi.md b/content/manuals/desktop/setup/vm-vdi.md
index 37333024258e..bfc5f4c495c1 100644
--- a/content/manuals/desktop/setup/vm-vdi.md
+++ b/content/manuals/desktop/setup/vm-vdi.md
@@ -4,26 +4,51 @@ keywords: nested virtualization, Docker Desktop, windows, VM, VDI environment
 title: Run Docker Desktop for Windows in a VM or VDI environment
 linkTitle: VM or VDI environments
 aliases:
- - /desktop/nested-virtualization/
- - /desktop/vm-vdi/
+  - /desktop/vm-vdi/
 weight: 30
 ---
 
-Docker recommends running Docker Desktop natively on Mac, Linux, or Windows.  However, Docker Desktop for Windows can run inside a virtual desktop provided the virtual desktop is properly configured. 
+Docker recommends running Docker Desktop natively on Mac, Linux, or Windows. However, Docker Desktop for Windows can run inside a virtual desktop provided the virtual desktop is properly configured.
 
-To run Docker Desktop in a virtual desktop environment, it is essential nested virtualization is enabled on the virtual machine that provides the virtual desktop. This is because, under the hood, Docker Desktop is using a Linux VM in which it runs Docker Engine and the containers.
+To run Docker Desktop in a virtual desktop environment, you have two options,
+depending on whether nested virtualization is supported:
 
-## Virtual desktop support
+- If your environment supports nested virtualization, you can run Docker Desktop
+  with its default local Linux VM.
+- If nested virtualization is not supported, Docker recommends subscribing to and using Docker Offload.
+
+## Use Docker Offload
+
+[Docker Offload](/offload/) lets you offload container workloads to a high-performance, fully hosted cloud environment,
+enabling a seamless hybrid experience.
+
+Docker Offload is useful in virtual desktop environments where nested virtualization isn't supported. In these
+environments, Docker Desktop can use Docker Offload to ensure you can still build and run containers without relying on
+local virtualization.
+
+Docker Offload decouples the Docker Desktop client from the Docker Engine,
+allowing the Docker CLI and Docker Desktop Dashboard to interact with
+cloud-based resources as if they were local. When you run a container, Docker
+provisions a secure, isolated, and ephemeral cloud environment connected to
+Docker Desktop via an SSH tunnel. Despite running remotely, features like bind
+mounts and port forwarding continue to work seamlessly, providing a local-like
+experience. To use Docker Offload:
+
+For more information, see the [Docker Offload product
+page](https://www.docker.com/products/docker-offload/) and the [Docker Offload
+documentation](/offload/).
+
+## Virtual desktop support when using nested virtualization
 
 > [!NOTE]
 >
 > Support for running Docker Desktop on a virtual desktop is available to Docker Business customers, on VMware ESXi or Azure VMs only.
 
-Docker support includes installing and running Docker Desktop within the VM, provided that nested virtualization is correctly enabled. The only hypervisors successfully tested are VMware ESXi and Azure, and there is no support for other VMs. For more information on Docker Desktop support, see [Get support](/manuals/desktop/troubleshoot-and-support/support.md).
+Docker support includes installing and running Docker Desktop within the VM, provided that nested virtualization is correctly enabled. The only hypervisors successfully tested are VMware ESXi and Azure, and there is no support for other VMs. For more information on Docker Desktop support, see [Get support](/manuals/support/_index.md).
 
 For troubleshooting problems and intermittent failures that are outside of Docker's control, you should contact your hypervisor vendor. Each hypervisor vendor offers different levels of support. For example, Microsoft supports running nested Hyper-V both on-prem and on Azure, with some version constraints. This may not be the case for VMware ESXi.
 
-Docker does not support running multiple instances of Docker Desktop on the same machine in a VM or VDI environment. 
+Docker does not support running multiple instances of Docker Desktop on the same machine in a VM or VDI environment.
 
 > [!TIP]
 >
@@ -33,13 +58,14 @@ Docker does not support running multiple instances of Docker Desktop on the same
 
 ## Turn on nested virtualization
 
-You must turn on nested virtualization before you install Docker Desktop on a virtual machine.
+You must turn on nested virtualization before you install Docker Desktop on a
+virtual machine that will not use Docker Cloud.
 
 ### Turn on nested virtualization on VMware ESXi
 
 Nested virtualization of other hypervisors like Hyper-V inside a vSphere VM [is not a supported scenario](https://kb.vmware.com/s/article/2009916). However, running Hyper-V VM in a VMware ESXi VM is technically possible and, depending on the version, ESXi includes hardware-assisted virtualization as a supported feature. A VM that had 1 CPU with 4 cores and 12GB of memory was used for internal testing.
 
-For steps on how to expose hardware-assisted virtualization to the guest OS, [see VMware's documentation](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-2A98801C-68E8-47AF-99ED-00C63E4857F6.html).
+For steps on how to expose hardware-assisted virtualization to the guest OS, [see VMware's documentation](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/7-0/expose-hardware-assisted-virtualization.html).
 
 ### Turn on nested virtualization on an Azure Virtual Machine
 
@@ -55,12 +81,16 @@ If using Windows container mode, confirm that the Nutanix environment supports H
 
 ### Supported configurations
 
-Docker Desktop follows the VDI support definitions outlined [previously](#virtual-desktop-support):
+Docker Desktop follows the VDI support definitions outlined [previously](#virtual-desktop-support-when-using-nested-virtualization):
 
- - Persistent VDI environments (Supported): You receive the same virtual desktop instance across sessions, preserving installed software and configurations.
+- Persistent VDI environments (Supported): You receive the same virtual desktop instance across sessions, preserving installed software and configurations.
 
- - Non-persistent VDI environments (Not supported): Docker Desktop does not support environments where the OS resets between sessions, requiring re-installation or reconfiguration each time. 
+- Non-persistent VDI environments (Not supported): Docker Desktop does not support environments where the OS resets between sessions, requiring re-installation or reconfiguration each time.
 
 ### Support scope and responsibilities
 
 For WSL 2-related issues, contact Nutanix support. For Docker Desktop-specific issues, contact Docker support.
+
+## Additional resources
+
+- [Docker Desktop on Microsoft Dev Box](/manuals/enterprise/enterprise-deployment/dev-box.md)
diff --git a/content/manuals/desktop/troubleshoot-and-support/faqs/general.md b/content/manuals/desktop/troubleshoot-and-support/faqs/general.md
index d21afd8e306f..d48c320f324d 100644
--- a/content/manuals/desktop/troubleshoot-and-support/faqs/general.md
+++ b/content/manuals/desktop/troubleshoot-and-support/faqs/general.md
@@ -5,10 +5,6 @@ title: General FAQs for Desktop
 linkTitle: General
 tags: [FAQ]
 aliases:
-- /mackit/faqs/
-- /docker-for-mac/faqs/
-- /docker-for-windows/faqs/
-- /desktop/faqs/
 - /desktop/faqs/general/
 weight: 10
 ---
@@ -18,27 +14,12 @@ weight: 10
 Yes, you can use Docker Desktop offline. However, you
 cannot access features that require an active internet
 connection. Additionally, any functionality that requires you to sign in won't work while using Docker Desktop offline or in air-gapped environments.
-This includes:
-
-- The resources in the [Learning Center](/manuals/desktop/use-desktop/_index.md)
-- Pulling or pushing an image to Docker Hub
-- [Image Access Management](/manuals/security/for-developers/access-tokens.md)
-- [Static vulnerability scanning](/manuals/docker-hub/repos/manage/vulnerability-scanning.md)
-- Viewing remote images in the Docker Dashboard
-- Setting up [Dev Environments](/manuals/desktop/features/dev-environments/_index.md)
-- Docker Build when using [BuildKit](/manuals/build/buildkit/_index.md#getting-started).
-  You can work around this by disabling BuildKit. Run `DOCKER_BUILDKIT=0 docker build .` to disable BuildKit.
-- [Kubernetes](/manuals/desktop/features/kubernetes.md) (Images are download when you enable Kubernetes for the first time)
-- Checking for updates
-- [In-app diagnostics](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md#diagnose-from-the-app) (including the [Self-diagnose tool](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md#diagnose-from-the-app))
-- Sending usage statistics
-- When `networkMode` is set to `mirrored`
 
 ### How do I connect to the remote Docker Engine API?
 
 To connect to the remote Engine API, you might need to provide the location of the Engine API for Docker clients and development tools.
 
-Mac and Windows WSL 2 users can connect to the Docker Engine through a Unix socket: `unix:///var/run/docker.sock`.
+Mac and Windows WSL 2 users can connect to the Docker Engine through a Unix socket: `unix:///var/run/docker.sock`. Docker Desktop for Linux uses a [per-user socket](linuxfaqs.md#how-do-i-use-docker-sdks-with-docker-desktop-for-linux) located at `~/.docker/desktop/docker.sock` instead of the system-wide `/var/run/docker.sock`.
 
 If you are working with applications like [Apache Maven](https://maven.apache.org/)
 that expect settings for `DOCKER_HOST` and `DOCKER_CERT_PATH` environment
@@ -61,12 +42,53 @@ The host has a changing IP address, or none if you have no network access.
 It is recommend that you connect to the special DNS name `host.docker.internal`,
 which resolves to the internal IP address used by the host.
 
-For more information and examples, see [how to connect from a container to a service on the host](/manuals/desktop/features/networking.md#i-want-to-connect-from-a-container-to-a-service-on-the-host).
+For more information and examples, see [how to connect from a container to a service on the host](/manuals/desktop/features/networking.md#connect-a-container-to-a-service-on-the-host).
 
 ### Can I pass through a USB device to a container?
 
 Docker Desktop does not support direct USB device passthrough. However, you can use USB over IP to connect common USB devices to the Docker Desktop VM and in turn be forwarded to a container. For more details, see [Using USB/IP with Docker Desktop](/manuals/desktop/features/usbip.md).
 
+### How do I verify Docker Desktop is using a proxy server ?
+
+To verify, look at the most recent events logged in `httpproxy.log`. This is located at `~/Library/Containers/com.docker.docker/Data/log/host` on macOS or `%LOCALAPPDATA%/Docker/log/host/` on Windows. 
+
+The following shows a few examples of what you can expect to see:
+
+- Docker Desktop using app level settings (proxy mode manual) for proxy:
+
+   ```console
+   host will use proxy: app settings http_proxy=http://172.211.16.3:3128 https_proxy=http://172.211.16.3:3128
+   Linux will use proxy: app settings http_proxy=http://172.211.16.3:3128 https_proxy=http://172.211.16.3:3128
+   ```
+
+- Docker Desktop using system level settings (proxy mode system) for proxy:
+
+   ```console
+   host will use proxy: static system http_proxy=http://172.211.16.3:3128 https_proxy=http://172.211.16.3:3128 no_proxy=
+   Linux will use proxy: static system http_proxy=http://172.211.16.3:3128 https_proxy=http://172.211.16.3:3128 no_proxy=
+   ```
+
+- Docker Desktop is not configured to use a proxy server:
+
+   ```console
+   host will use proxy: disabled
+   Linux will use proxy: disabled
+   ```
+
+- Docker Desktop is configured to use app level settings (proxy mode manual) and using a PAC file:
+
+   ```console
+   using a proxy PAC file: http://127.0.0.1:8081/proxy.pac
+   host will use proxy: app settings from PAC file http://127.0.0.1:8081/proxy.pac
+   Linux will use proxy: app settings from PAC file http://127.0.0.1:8081/proxy.pac
+   ```
+
+- Connect request using the configured proxy server:
+
+   ```console
+   CONNECT desktop.docker.com:443: host connecting via static system HTTPS proxy http://172.211.16.3:3128
+   ```
+
 ### How do I run Docker Desktop without administrator privileges?
 
 Docker Desktop requires administrator privileges only for installation. Once installed, administrator privileges are not needed to run it. However, for non-admin users to run Docker Desktop, it must be installed using a specific installer flag and meet certain prerequisites, which vary by platform.
@@ -74,7 +96,7 @@ Docker Desktop requires administrator privileges only for installation. Once ins
 {{< tabs >}}
 {{< tab name="Mac" >}}
 
-To run Docker Desktop on Mac without requiring administrator privileges, install via the command line and pass the `—user=<userid>` installer flag:
+To run Docker Desktop on Mac without requiring administrator privileges, install via the command line and pass the `--user=<userid>` installer flag:
 
 ```console
 $ /Applications/Docker.app/Contents/MacOS/install --user=<userid>
@@ -84,7 +106,7 @@ You can then sign in to your machine with the user ID specified, and launch Dock
 
 > [!NOTE]
 > 
-> Before launching Docker Desktop, if a `settings-store.json` file (or `settings.json` for Docker Desktop versions 4.34 and earlier) already exists in the `~/Library/Group Containers/group.com.docker/` directory, you will see a **Finish setting up Docker Desktop** window that prompts for administrator privileges when you select **Finish**. To avoid this, ensure you delete the `settings-store.json` file (or `settings.json` for Docker Desktop versions 4.34 and earlier) left behind from any previous installations before launching the application.
+> Before launching Docker Desktop, if a `settings-store.json` file already exists in the `~/Library/Group Containers/group.com.docker/` directory, you will see a **Finish setting up Docker Desktop** window that prompts for administrator privileges when you select **Finish**. To avoid this, ensure you delete the `settings-store.json` file left behind from any previous installations before launching the application.
 
 {{< /tab >}}
 {{< tab name="Windows" >}}
@@ -93,13 +115,12 @@ You can then sign in to your machine with the user ID specified, and launch Dock
 >
 > If you are using the WSL 2 backend, first make sure that you meet the [minimum required version](/manuals/desktop/features/wsl/best-practices.md) for WSL 2. Otherwise, update WSL 2 first.  
 
-To run Docker Desktop on Windows without requiring administrator privileges, install via the command line and pass the `—always-run-service` installer flag.
+To run Docker Desktop on Windows without requiring administrator privileges, install via the command line and pass the `--always-run-service` installer flag.
 
 ```console
-$ "Docker Desktop Installer.exe" install —always-run-service
+$ "Docker Desktop Installer.exe" install --always-run-service
 ```
 
 {{< /tab >}}
 {{< /tabs >}}
 
-
diff --git a/content/manuals/desktop/troubleshoot-and-support/faqs/linuxfaqs.md b/content/manuals/desktop/troubleshoot-and-support/faqs/linuxfaqs.md
index 5257cfb3206c..55ca9f8d27d1 100644
--- a/content/manuals/desktop/troubleshoot-and-support/faqs/linuxfaqs.md
+++ b/content/manuals/desktop/troubleshoot-and-support/faqs/linuxfaqs.md
@@ -5,8 +5,7 @@ title: FAQs for Docker Desktop for Linux
 linkTitle: Linux
 tags: [FAQ]
 aliases:
-- /desktop/linux/space/
-- /desktop/faqs/linuxfaqs/
+  - /desktop/faqs/linuxfaqs/
 weight: 40
 ---
 
@@ -16,32 +15,32 @@ Docker Desktop for Linux runs a Virtual Machine (VM) for the following reasons:
 
 1. To ensure that Docker Desktop provides a consistent experience across platforms.
 
-    During research, the most frequently cited reason for users wanting Docker Desktop for Linux was to ensure a consistent Docker Desktop
-    experience with feature parity across all major operating systems. Utilizing
-    a VM ensures that the Docker Desktop experience for Linux users will closely
-    match that of Windows and macOS.
+   During research, the most frequently cited reason for users wanting Docker Desktop for Linux was to ensure a consistent Docker Desktop
+   experience with feature parity across all major operating systems. Utilizing
+   a VM ensures that the Docker Desktop experience for Linux users will closely
+   match that of Windows and macOS.
 
 2. To make use of new kernel features.
 
-    Sometimes we want to make use of new operating system features. Because we control the kernel and the OS inside the VM, we can roll these out to all users immediately, even to users who are intentionally sticking on an LTS version of their machine OS.
+   Because Docker controls the kernel and the OS inside the VM, Docker can roll these out to all users immediately, even to users who are intentionally sticking on an LTS version of their machine OS.
 
 3. To enhance security.
 
-    Container image vulnerabilities pose a security risk for the host environment. There is a large number of unofficial images that are not guaranteed to be verified for known vulnerabilities. Malicious users can push images to public registries and use different methods to trick users into pulling and running them. The VM approach mitigates this threat as any malware that gains root privileges is restricted to the VM environment without access to the host.
+   Container image vulnerabilities pose a security risk for the host environment. There is a large number of unofficial images that are not guaranteed to be verified for known vulnerabilities. Malicious users can push images to public registries and use different methods to trick users into pulling and running them. The VM approach mitigates this threat as any malware that gains root privileges is restricted to the VM environment without access to the host.
 
-    Why not run rootless Docker? Although this has the benefit of superficially limiting access to the root user so everything looks safer in "top", it allows unprivileged users to gain `CAP_SYS_ADMIN` in their own user namespace and access kernel APIs which are not expecting to be used by unprivileged users, resulting in [vulnerabilities](https://www.openwall.com/lists/oss-security/2022/01/18/7).
+   Why not run rootless Docker? Although this has the benefit of superficially limiting access to the root user so everything looks safer in "top", it allows unprivileged users to gain `CAP_SYS_ADMIN` in their own user namespace and access kernel APIs which are not expecting to be used by unprivileged users, resulting in [vulnerabilities](https://www.openwall.com/lists/oss-security/2022/01/18/7).
 
 4. To provide the benefits of feature parity and enhanced security, with minimal impact on performance.
 
-    The VM utilized by Docker Desktop for Linux uses [`VirtioFS`](https://virtio-fs.gitlab.io), a shared file system that allows virtual machines to access a directory tree located on the host. Our internal benchmarking shows that with the right resource allocation to the VM, near native file system performance can be achieved with VirtioFS.
+   The VM utilized by Docker Desktop for Linux uses [`VirtioFS`](https://virtio-fs.gitlab.io), a shared file system that allows virtual machines to access a directory tree located on the host. Docker's internal benchmarking shows that with the right resource allocation to the VM, near native file system performance can be achieved with VirtioFS.
 
-    As such, we have adjusted the default memory available to the VM in Docker Desktop for Linux. You can tweak this setting to your specific needs by using the **Memory** slider within the **Settings** > **Resources** tab of Docker Desktop.
+   As such, the default memory available to the VM in Docker Desktop for Linux is adjusted. You can tweak this setting to your specific needs by using the **Memory** slider within the **Settings** > **Resources** tab of Docker Desktop.
 
 ### How do I enable file sharing?
 
 Docker Desktop for Linux uses [VirtioFS](https://virtio-fs.gitlab.io/) as the
 default (and currently only) mechanism to enable file sharing between the host
-and Docker Desktop VM. 
+and Docker Desktop VM.
 
 {{< accordion title="Additional information for Docker Desktop version 4.34 and earlier" >}}
 
@@ -59,7 +58,7 @@ mappings for IDs greater than 0 in the containers.
 
 | ID in container | ID on host                                                                       |
 | --------------- | -------------------------------------------------------------------------------- |
-| 0 (root)        | ID of the user running Docker Desktop (e.g. 1000)                                            |
+| 0 (root)        | ID of the user running Docker Desktop (e.g. 1000)                                |
 | 1               | 0 + beginning of ID range specified in `/etc/subuid`/`/etc/subgid` (e.g. 100000) |
 | 2               | 1 + beginning of ID range specified in `/etc/subuid`/`/etc/subgid` (e.g. 100001) |
 | 3               | 2 + beginning of ID range specified in `/etc/subuid`/`/etc/subgid` (e.g. 100002) |
@@ -95,6 +94,34 @@ ACL (see `setfacl(1)`) for folders shared with the Docker Desktop VM.
 
 {{< /accordion >}}
 
+### How do I use Docker SDKs with Docker Desktop for Linux?
+
+Docker Desktop for Linux uses a per-user socket located at `~/.docker/desktop/docker.sock` instead of the system-wide `/var/run/docker.sock`. The Docker CLI handles this automatically through the `desktop-linux` context, but Docker SDKs and other tools that connect directly to the Docker daemon also need the `DOCKER_HOST` environment variable set.
+
+Without setting `DOCKER_HOST`, SDKs attempt to connect to `/var/run/docker.sock` and fail with an error like:
+
+```text
+Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
+```
+
+To fix this, set the `DOCKER_HOST` environment variable before running your SDK-based application:
+
+```console
+export DOCKER_HOST=unix://$HOME/.docker/desktop/docker.sock
+```
+
+Or dynamically retrieve it from the `desktop-linux` context:
+
+```console
+export DOCKER_HOST=$(docker context inspect desktop-linux --format '{{ .Endpoints.docker.Host }}')
+```
+
+To make this permanent, add the export command to your shell profile (`~/.bashrc`, `~/.zshrc`, or similar):
+
+```console
+echo 'export DOCKER_HOST=unix://$HOME/.docker/desktop/docker.sock' >> ~/.bashrc
+```
+
 ### Where does Docker Desktop store Linux containers?
 
 Docker Desktop stores Linux containers and images in a single, large "disk image" file in the Linux filesystem. This is different from Docker on Linux, which usually stores containers and images in the `/var/lib/docker` directory on the host's filesystem.
@@ -117,11 +144,11 @@ If the disk image file is too large, you can:
 
 To move the disk image file to a different location:
 
-1. Select **Settings** then  **Advanced** from the **Resources** tab.
+1. Select **Settings** then **Advanced** from the **Resources** tab.
 
 2. In the **Disk image location** section, select **Browse** and choose a new location for the disk image.
 
-3. Select **Apply & Restart** for the changes to take effect.
+3. Select **Apply** for the changes to take effect.
 
 Do not move the file directly in Finder as this can cause Docker Desktop to lose track of the file.
 
@@ -183,6 +210,6 @@ To reduce the maximum size of the disk image file:
 
 2. The **Disk image size** section contains a slider that allows you to change the maximum size of the disk image. Adjust the slider to set a lower limit.
 
-3. Select **Apply & Restart**.
+3. Select **Apply**.
 
 When you reduce the maximum size, the current disk image file is deleted, and therefore, all containers and images are lost.
diff --git a/content/manuals/desktop/troubleshoot-and-support/faqs/macfaqs.md b/content/manuals/desktop/troubleshoot-and-support/faqs/macfaqs.md
index d11a00f7db21..b5bfda010c1a 100644
--- a/content/manuals/desktop/troubleshoot-and-support/faqs/macfaqs.md
+++ b/content/manuals/desktop/troubleshoot-and-support/faqs/macfaqs.md
@@ -6,21 +6,24 @@ linkTitle: Mac
 tags: [FAQ]
 aliases:
 - /desktop/mac/space/
-- /docker-for-mac/space/
 - /desktop/faqs/macfaqs/
 weight: 20
 ---
 
 ### What is HyperKit?
 
-HyperKit is a hypervisor built on top of the Hypervisor.framework in macOS. It runs entirely in userspace and has no other dependencies.
+HyperKit is a legacy hypervisor built on top of Hypervisor.framework in macOS.
+Previous versions of Docker Desktop for Mac used HyperKit to run the Linux VM.
 
-Docker uses HyperKit to eliminate the need for other VM products, such as Oracle
-VirtualBox or VMware Fusion.
+Current versions of Docker Desktop use the Apple Virtualization framework by
+default. HyperKit is retained here as historical context for older
+configurations.
 
 ### What is the benefit of HyperKit?
 
-HyperKit is thinner than VirtualBox and VMware fusion, and the version included is customized for Docker workloads on Mac.
+When HyperKit was the default hypervisor, it provided a lightweight
+virtualization layer customized for Docker workloads and eliminated the need
+for third-party VM products such as Oracle VirtualBox or VMware Fusion.
 
 ### Where does Docker Desktop store Linux containers and images? 
 
@@ -48,7 +51,7 @@ To move the disk image file to a different location:
 
 2. In the **Disk image location** section, select **Browse** and choose a new location for the disk image.
 
-3. Select **Apply & Restart** for the changes to take effect.
+3. Select **Apply** for the changes to take effect.
 
 > [!IMPORTANT]
 >
@@ -112,7 +115,7 @@ To reduce the maximum size of the disk image file:
 
 2. The **Disk image size** section contains a slider that allows you to change the maximum size of the disk image. Adjust the slider to set a lower limit.
 
-3. Select **Apply & Restart**.
+3. Select **Apply**.
 
 When you reduce the maximum size, the current disk image file is deleted, and therefore, all containers and images are lost.
 
diff --git a/content/manuals/desktop/troubleshoot-and-support/faqs/releases.md b/content/manuals/desktop/troubleshoot-and-support/faqs/releases.md
index ed4cf4ed76e9..da2270f5bae1 100644
--- a/content/manuals/desktop/troubleshoot-and-support/faqs/releases.md
+++ b/content/manuals/desktop/troubleshoot-and-support/faqs/releases.md
@@ -8,7 +8,7 @@ tags: [FAQ]
 
 ### How frequent will new releases be?
 
-New releases are available roughly every month, unless there are critical fixes that need to be released sooner. 
+New releases are available every week, unless there are critical fixes that need to be released sooner. 
 
 The **Automatically check for updates** setting in the **Software updates** tab is turned on by default. This means you receive notifications in the Docker menu and a notification badge on the Docker Desktop Dashboard when a new version is available. 
 
diff --git a/content/manuals/desktop/troubleshoot-and-support/faqs/windowsfaqs.md b/content/manuals/desktop/troubleshoot-and-support/faqs/windowsfaqs.md
index ea1da99fc25f..8349042948bc 100644
--- a/content/manuals/desktop/troubleshoot-and-support/faqs/windowsfaqs.md
+++ b/content/manuals/desktop/troubleshoot-and-support/faqs/windowsfaqs.md
@@ -48,8 +48,8 @@ in the Docker Engine topics.
 ### How do I add client certificates?
 
 You can add your client certificates
-in `~/.docker/certs.d/<MyRegistry><Port>/client.cert` and
-`~/.docker/certs.d/<MyRegistry><Port>/client.key`. You do not need to push your certificates with `git` commands.
+in `~/.docker/certs.d/<MyRegistry>:<Port>/client.cert` and
+`~/.docker/certs.d/<MyRegistry>:<Port>/client.key`. You do not need to push your certificates with `git` commands.
 
 When the Docker Desktop application starts, it copies the
 `~/.docker/certs.d` folder on your Windows system to the `/etc/docker/certs.d`
diff --git a/content/manuals/desktop/troubleshoot-and-support/feedback.md b/content/manuals/desktop/troubleshoot-and-support/feedback.md
index 6ab0af9cf893..b4bceb093be8 100644
--- a/content/manuals/desktop/troubleshoot-and-support/feedback.md
+++ b/content/manuals/desktop/troubleshoot-and-support/feedback.md
@@ -4,19 +4,13 @@ keywords: Feedback, Docker Desktop, Linux, Mac, Windows, Dev Environments, Exten
   Community forum, bugs, problems, issues
 title: Give feedback
 weight: 40
-aliases:
- - /desktop/feedback/
 ---
 
 There are many ways you can provide feedback on Docker Desktop or Docker Desktop features.
 
 ### In-product feedback
 
-On each Docker Desktop Dashboard view, there is a **Give feedback** link. This opens a feedback form where you can share ideas directly with the Docker team.
-
-You can also use the `docker feedback` command to submit feedback directly from the command line.
-
-<script async id="asciicast-KkC0fFrhV8nAzvXUGqay06UXx" src="https://asciinema.org/a/KkC0fFrhV8nAzvXUGqay06UXx.js"></script>
+On each Docker Desktop Dashboard view, there is a **Give feedback** link. This opens a feedback form where you can share ideas directly with the Docker Team.
 
 ### Feedback via Docker Community forums
 
@@ -30,12 +24,7 @@ discussion, sign in to the appropriate Docker forums:
 ### Report bugs or problems on GitHub
 
 To report bugs or problems, visit:
-- [Docker Desktop for Mac issues on
-GitHub](https://github.com/docker/for-mac/issues)
-- [Docker Desktop for Windows issues on GitHub](https://github.com/docker/for-win/issues)
-- [Docker Desktop for Linux issues on
-GitHub](https://github.com/docker/desktop-linux/issues)
-- [Dev Environments issues on GitHub](https://github.com/docker/dev-environments/issues)
+- [Docker Desktop issues on GitHub](https://github.com/docker/desktop-feedback)
 - [Docker Extensions issues on GitHub](https://github.com/docker/extensions-sdk/issues)
 
 ### Feedback via Community Slack channels
@@ -45,5 +34,4 @@ You can also provide feedback through the following [Docker Community Slack](htt
 - #docker-desktop-mac
 - #docker-desktop-windows
 - #docker-desktop-linux
-- #docker-dev-environments
 - #extensions
diff --git a/content/manuals/desktop/troubleshoot-and-support/support.md b/content/manuals/desktop/troubleshoot-and-support/support.md
deleted file mode 100644
index 02b7a8033a70..000000000000
--- a/content/manuals/desktop/troubleshoot-and-support/support.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-description: See what support is available for Docker Desktop
-keywords: Support, Docker Desktop, Linux, Mac, Windows
-title: Get support for Docker Desktop
-weight: 20
-aliases:
- - /desktop/support/
- - /support/
----
-
-> [!NOTE]
-> 
-> Docker Desktop offers support for developers with a [Pro, Team, or Business subscription](https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade_desktop_support).
-
-### How do I get Docker Desktop support?
-
-> [!TIP]
->
-> Before reaching out for support, follow the appropriate [Diagnose steps](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md#diagnose) in the troubleshooting documentation. 
-
-If you have a paid Docker subscription, you can [contact the Support team](https://hub.docker.com/support/contact/).
-
-All Docker users can seek support through the following resources, where Docker or the community respond on a best effort basis.
-- [Docker Desktop for Windows GitHub repo](https://github.com/docker/for-win) 
-- [Docker Desktop for Mac GitHub repo](https://github.com/docker/for-mac)
-- [Docker Desktop for Linux GitHub repo](https://github.com/docker/desktop-linux)
-- [Docker Community Forums](https://forums.docker.com/)
-- [Docker Community Slack](http://dockr.ly/comm-slack)
-
-
-### What support can I get?
-
-- Account management related issues
-- Automated builds
-- Basic product 'how to' questions
-- Billing or subscription issues
-- Configuration issues
-- Desktop installation issues
-   - Installation crashes
-   - Failure to launch Docker Desktop on first run
-- Desktop update issues
-- Sign-in issues in both the command line interface and Docker Hub user interface
-- Push or pull issues, including rate limiting
-- Usage issues
-   - Crash closing software
-   - Docker Desktop not behaving as expected
-
-For Windows users, you can also request support on:
-- Turning on virtualization in BIOS
-- Turning on Windows features
-- Running inside [certain VM or VDI environments](/manuals/desktop/setup/vm-vdi.md) (Docker Business customers only)
-
-### What is not supported?
-
-Docker Desktop excludes support for the following types of issues:
-
-- Use on or in conjunction with hardware or software other than that specified in the applicable documentation
-- Running on unsupported operating systems, including beta/preview versions of operating systems
-- Running containers of a different architecture using emulation
-- Support for Docker Engine, Docker CLI, or other bundled Linux components
-- Support for Kubernetes
-- Features labeled as experimental
-- System/Server administration activities
-- Supporting Desktop as a production runtime
-- Scale deployment/multi-machine installation of Desktop
-- Routine product maintenance (data backup, cleaning disk space and configuring log rotation)
-- Third-party applications not provided by Docker
-- Altered or modified Docker software
-- Defects in the Docker software due to hardware malfunction, abuse, or improper use
-- Any version of the Docker software other than the latest version
-- Reimbursing and expenses spent for third-party services not provided by Docker
-- Docker support excludes training, customization, and integration
-- Running multiple instances of Docker Desktop on a single machine
-
-> [!NOTE]
->
-> Support for [running Docker Desktop in a VM or VDI environment](/manuals/desktop/setup/vm-vdi.md) is only available to Docker Business customers.
-
-### What versions are supported?
-
-For Docker Business customers, Docker offers support for versions up to six months older than the latest version, although any fixes will be on the latest version.
-
-For Pro and Team customers, Docker only offers support for the latest version of Docker Desktop. If you are running an older version, Docker may ask you to update before investigating your support request.
-
-### How many machines can I get support for Docker Desktop on?
-
-As a Pro user you can get support for Docker Desktop on a single machine.
-As a Team, you can get support for Docker Desktop for the number of machines equal to the number of seats as part of your plan.
-
-### What OS’s are supported?
-
-Docker Desktop is available for Mac, Linux, and Windows. The supported version information can be found on the following pages:
-
-- [Mac system requirements](/manuals/desktop/setup/install/mac-install.md#system-requirements)
-- [Windows system requirements](/manuals/desktop/setup/install/windows-install.md#system-requirements)
-- [Linux system requirements](/manuals/desktop/setup/install/linux/_index.md#system-requirements)
-
-### How is personal diagnostic data handled in Docker Desktop when I'm getting support?
-
-When uploading diagnostics to help Docker with investigating issues, the uploaded diagnostics bundle may contain personal data such as usernames and IP addresses. The diagnostics bundles are only accessible to Docker, Inc.
-employees who are directly involved in diagnosing Docker Desktop issues.
-
-By default, Docker, Inc. will delete uploaded diagnostics bundles after 30 days. You may also request the removal of a diagnostics bundle by either specifying the diagnostics ID or via your GitHub ID (if the diagnostics ID is mentioned in a GitHub issue). Docker, Inc. will only use the data in the diagnostics bundle to investigate specific user issues but may derive high-level (non personal) metrics such as the rate of issues from it.
-
-For more information, see [Docker Data Processing Agreement](https://www.docker.com/legal/data-processing-agreement).
diff --git a/content/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md b/content/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md
index 38d82183113a..92905bcf363a 100644
--- a/content/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md
+++ b/content/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md
@@ -1,61 +1,48 @@
 ---
-description: Understand how to diagnose and troubleshoot Docker Desktop, and how to
+description:
+  Understand how to diagnose and troubleshoot Docker Desktop, and how to
   check the logs.
 keywords: Linux, Mac, Windows, troubleshooting, logs, issues, Docker Desktop
 toc_max: 2
 title: Troubleshoot Docker Desktop
 linkTitle: Troubleshoot and diagnose
 aliases:
- - /desktop/linux/troubleshoot/
- - /desktop/mac/troubleshoot/
- - /desktop/windows/troubleshoot/
- - /docker-for-mac/troubleshoot/
- - /mackit/troubleshoot/
- - /windows/troubleshoot/
- - /docker-for-win/troubleshoot/
- - /docker-for-windows/troubleshoot/
- - /desktop/troubleshoot/overview/
- - /desktop/troubleshoot/
-tags: [ Troubleshooting ]
+  - /desktop/troubleshoot/overview/
+  - /desktop/troubleshoot/
+tags: [Troubleshooting]
 weight: 10
 ---
 
 This page contains information on how to diagnose and troubleshoot Docker Desktop, and how to check the logs.
 
-> [!WARNING]
->
-> If you're experiencing malware detection issues on Mac, follow the steps documented in [docker/for-mac#7527](https://github.com/docker/for-mac/issues/7527).
-
 ## Troubleshoot menu
 
 To navigate to **Troubleshoot** either:
 
 - Select the Docker menu Docker menu {{< inline-image src="../../images/whale-x.svg" alt="whale menu" >}} and then **Troubleshoot**.
-- Select the **Troubleshoot** icon near the top-right corner of Docker Dashboard.
+- Select the **question mark** icon near the top-right corner of the Docker Desktop Dashboard.
+
+The **Troubleshoot** menu contains the following options:
 
-The **Troubleshooting** menu contains the following options:
+- **Restart Docker Desktop**
 
-- **Restart Docker Desktop**.
+- **Support**
 
 - **Reset Kubernetes cluster**. Select to delete all stacks and Kubernetes resources. For more information, see [Kubernetes](/manuals/desktop/settings-and-maintenance/settings.md#kubernetes).
 
-- **Clean / Purge data**. This option resets all Docker data without a
-reset to factory defaults. Selecting this option results in the loss of existing settings.
+- **Clean up data**. This option resets all Docker data without a
+  reset to factory defaults. Selecting this option results in the loss of existing settings.
 
 - **Reset to factory defaults**: Choose this option to reset all options on
-Docker Desktop to their initial state, the same as when Docker Desktop was first installed.
+  Docker Desktop to their initial state, the same as when Docker Desktop was first installed.
 
 If you are a Mac or Linux user, you also have the option to **Uninstall** Docker Desktop from your system.
 
 ## Diagnose
- 
-> [!TIP]
->
-> If you do not find a solution in troubleshooting, browse the GitHub repositories or create a new issue:
+
+> [!NOTE]
 >
-> - [docker/for-mac](https://github.com/docker/for-mac/issues)
-> - [docker/for-win](https://github.com/docker/for-win/issues)
-> - [docker/for-linux](https://github.com/docker/for-linux/issues)
+> Gathering diagnostics may take several minutes. Don't close Docker Desktop while the diagnostics are being collected.
 
 ### Diagnose from the app
 
@@ -63,27 +50,32 @@ If you are a Mac or Linux user, you also have the option to **Uninstall** Docker
 2. When the diagnostics collection process is complete, select **Upload to get a Diagnostic ID**.
 3. When the diagnostics are uploaded, Docker Desktop prints a diagnostic ID. Copy this ID.
 4. Use your diagnostics ID to get help:
-    - If you have a paid Docker subscription, select **Contact support**. This opens the Docker Desktop support form. Fill in the information required and add the ID you copied in step three to the **Diagnostics ID field**. Then, select **Submit ticket** to request Docker Desktop support.
-        > [!NOTE]
-        >
-        > You must be signed in to Docker Desktop to access the support form. For information on what's covered as part of Docker Desktop support, see [Support](/manuals/desktop/troubleshoot-and-support/support.md).
-    - If you don't have a paid Docker subscription, select **Report a Bug** to open a new Docker Desktop issue on GitHub. Complete the information required and ensure you add the diagnostic ID you copied in step three.
+   - If you have a Docker subscription and are signed in, select **Contact support**. This opens the Docker Desktop support form. Fill in the information required and add the ID you copied in step three to the **Diagnostics ID field**. Then, select **Submit ticket** to request Docker Desktop support.
+   - If you don't have a Docker subscription, select **Report a Bug** to open a new Docker Desktop issue on GitHub. Complete the information required and ensure you add the diagnostic ID you copied in step three.
 
-### Diagnose from an error message 
+### Diagnose from an error message
 
-1. When an error message appears, select **Gather diagnostics**.
+1. When an error message appears, select **Gather diagnostics**. Gathering diagnostics may take several minutes. Don't close Docker Desktop while the diagnostics are being collected.
 2. When the diagnostics are uploaded, Docker Desktop prints a diagnostic ID. Copy this ID.
 3. Use your diagnostics ID to get help:
-    - If you have a paid Docker subscription, select **Contact support**. This opens the Docker Desktop support form. Fill in the information required and add the ID you copied in step three to the **Diagnostics ID field**. Then, select **Submit ticket** to request Docker Desktop support.
-        > [!NOTE]
-        >
-        > You must be signed in to Docker Desktop to access the support form. For information on what's covered as part of Docker Desktop support, see [Support](/manuals/desktop/troubleshoot-and-support/support.md).
-    - If you don't have a paid Docker subscription, you can open a new Docker Desktop issue on GitHub for [Mac](https://github.com/docker/for-mac/issues), [Windows](https://github.com/docker/for-win/issues), or [Linux](https://github.com/docker/for-linux/issues). Complete the information required and ensure you add the diagnostic ID printed in step two. 
+   - If you have a Docker subscription and are signed in, select **Contact support**. This opens the Docker Desktop support form. Fill in the information required and add the ID you copied in step three to the **Diagnostics ID field**. Then, select **Submit ticket** to request Docker Desktop support.
+   - If you don't have a Docker subscription, you can open a new [Docker Desktop issue on GitHub](https://github.com/docker/desktop-feedback). Complete the information required and ensure you add the diagnostic ID printed in step two.
 
 ### Diagnose from the terminal
 
-In some cases, it's useful to run the diagnostics yourself, for instance, if
-Docker Desktop cannot start.
+In some cases, it's useful to run the diagnostics yourself, for instance, if the Docker Desktop Dashboard cannot start.
+
+Run the [`docker desktop diagnose`](/manuals/desktop/features/desktop-cli.md) command:
+
+```console
+$ docker desktop diagnose
+```
+
+Gathering diagnostics may take several minutes. Wait for the process to complete before closing the terminal.
+
+After the diagnostics have finished, the terminal displays your diagnostics ID and the path to the diagnostics file. The diagnostics ID is composed of your user ID and a timestamp. For example `BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051`.
+
+Alternatively, you can use the `com.docker.diagnose` tool:
 
 {{< tabs group="os" >}}
 {{< tab name="Windows" >}}
@@ -91,16 +83,24 @@ Docker Desktop cannot start.
 1. Locate the `com.docker.diagnose` tool:
 
    ```console
+   # For all-user installations
    $ C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe
+
+   # For per-user installations
+   $ %LOCALAPPDATA%\Programs\DockerDesktop\resources\com.docker.diagnose.exe
    ```
 
 2. Create and upload the diagnostics ID. In PowerShell, run:
 
    ```console
+   # For all-user installations
    $ & "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" gather -upload
+
+   # For per-user installations
+   $ & %LOCALAPPDATA%\Programs\DockerDesktop\resources\com.docker.diagnose.exe" gather -upload
    ```
 
-After the diagnostics have finished, the terminal displays your diagnostics ID and the path to the diagnostics file. The diagnostics ID is composed of your user ID and a timestamp. For example `BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051`. 
+After the diagnostics have finished, the terminal displays your diagnostics ID and the path to the diagnostics file. The diagnostics ID is composed of your user ID and a timestamp. For example `BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051`.
 
 {{< /tab >}}
 {{< tab name="Mac" >}}
@@ -117,7 +117,7 @@ After the diagnostics have finished, the terminal displays your diagnostics ID a
    $ /Applications/Docker.app/Contents/MacOS/com.docker.diagnose gather -upload
    ```
 
-After the diagnostics have finished, the terminal displays your diagnostics ID and the path to the diagnostics file. The diagnostics ID is composed of your user ID and a timestamp. For example `BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051`. 
+After the diagnostics have finished, the terminal displays your diagnostics ID and the path to the diagnostics file. The diagnostics ID is composed of your user ID and a timestamp. For example `BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051`.
 
 {{< /tab >}}
 {{< tab name="Linux" >}}
@@ -134,7 +134,7 @@ After the diagnostics have finished, the terminal displays your diagnostics ID a
    $ /opt/docker-desktop/bin/com.docker.diagnose gather -upload
    ```
 
-After the diagnostics have finished, the terminal displays your diagnostics ID and the path to the diagnostics file. The diagnostics ID is composed of your user ID and a timestamp. For example `BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051`. 
+After the diagnostics have finished, the terminal displays your diagnostics ID and the path to the diagnostics file. The diagnostics ID is composed of your user ID and a timestamp. For example `BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051`.
 
 {{< /tab >}}
 {{< /tabs >}}
@@ -148,7 +148,7 @@ To view the contents of the diagnostic file:
 
    ```powershell
    $ Expand-Archive -LiteralPath "C:\Users\testUser\AppData\Local\Temp\5DE9978A-3848-429E-8776-950FC869186F\20230607101602.zip" -DestinationPath "C:\Users\testuser\AppData\Local\Temp\5DE9978A-3848-429E-8776-950FC869186F\20230607101602"
-   ```  
+   ```
 
 2. Open the file in your preferred text editor. Run:
 
@@ -179,132 +179,20 @@ $ unzip –l /tmp/<your-diagnostics-ID>.zip
 
 #### Use your diagnostics ID to get help
 
-If you have a paid Docker subscription, select **Contact support**. This opens the Docker Desktop support form. Fill in the information required and add the ID you copied in step three to the **Diagnostics ID field**. Then, select **Submit ticket** to request Docker Desktop support.
-    
-If you don't have a paid Docker subscription, create an issue on GitHub:
-
-- [For Linux](https://github.com/docker/desktop-linux/issues)
-- [For Mac](https://github.com/docker/for-mac/issues)
-- [For Windows](https://github.com/docker/for-win/issues)
-
-### Self-diagnose tool
-
-Docker Desktop contains a self-diagnose tool which can help you identify some common problems. 
-
-{{< tabs group="os" >}}
-{{< tab name="Windows" >}}
-1. Locate the `com.docker.diagnose` tool. 
-     
-   ```console
-   $ C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe
-   ```
-
-2. In PowerShell, run the self-diagnose tool:
-
-   ```console
-   $ & "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" gather
-   ```
-
-{{< /tab >}}
-{{< tab name="Mac" >}}
-
-1. Locate the `com.docker.diagnose` tool. 
-
-   ```console
-   $ /Applications/Docker.app/Contents/MacOS/com.docker.diagnose
-   ```
-
-2. Run the self-diagnose tool:
-
-   ```console
-   $ /Applications/Docker.app/Contents/MacOS/com.docker.diagnose gather
-   ```
-
-{{< /tab >}}
-{{< tab name="Linux" >}}
+If you have a Docker subscription, [Contact support](https://app.docker.com/support/contact). Fill in the information required and add your diagnostics ID.
 
-1. Locate the `com.docker.diagnose` tool. 
-
-2. Run the self-diagnose tool:
-
-   ```console
-   $ /opt/docker-desktop/bin/com.docker.diagnose gather
-   ```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-The tool runs a suite of checks and displays **PASS** or **FAIL** next to each check. If there are any failures, it highlights the most relevant at the end of the report.
-
-You can then create an issue on GitHub:
-
-- [For Linux](https://github.com/docker/desktop-linux/issues)
-- [For Mac](https://github.com/docker/for-mac/issues)
-- [For Windows](https://github.com/docker/for-win/issues)
+If you don't have a Docker subscription, create an issue on [GitHub](https://github.com/docker/desktop-feedback).
 
 ## Check the logs
 
 In addition to using the diagnose option to submit logs, you can browse the logs yourself.
 
-{{< tabs group="os" >}}
-{{< tab name="Windows" >}}
-
-In PowerShell, run:
-
-```powershell
-$ code $Env:LOCALAPPDATA\Docker\log
-```
-
-This opens up all the logs in your preferred text editor for you to explore.
-
-{{< /tab >}}
-{{< tab name="Mac" >}}
-
-### From terminal
-
-To watch the live flow of Docker Desktop logs in the command line, run the following script from your preferred shell.
+To access Docker Desktop logs, run:
 
 ```console
-$ pred='process matches ".*(ocker|vpnkit).*" || (process in {"taskgated-helper", "launchservicesd", "kernel"} && eventMessage contains[c] "docker")'
-$ /usr/bin/log stream --style syslog --level=debug --color=always --predicate "$pred"
+$ docker desktop diagnose
 ```
 
-Alternatively, to collect the last day of logs (`1d`) in a file, run:
-
-```console
-$ /usr/bin/log show --debug --info --style syslog --last 1d --predicate "$pred" >/tmp/logs.txt
-```
-
-### From the Console app
-
-Mac provides a built-in log viewer, named **Console**, which you can use to check
-Docker logs.
-
-The Console lives in `/Applications/Utilities`. You can search for it with
-Spotlight Search.
-
-To read the Docker app log messages, type `docker` in the Console window search bar and press Enter. Then select `ANY` to expand the drop-down list next to your `docker` search entry, and select `Process`.
-
-![Mac Console search for Docker app](../../images/console.png)
-
-You can use the Console Log Query to search logs, filter the results in various
-ways, and create reports.
-
-{{< /tab >}}
-{{< tab name="Linux" >}}
-
-You can access Docker Desktop logs by running the following command:
-
-```console
-$ journalctl --user --unit=docker-desktop
-```
-
-You can also find the logs for the internal components included in Docker
-Desktop at `$HOME/.docker/desktop/log/`.
-
-{{< /tab >}}
-{{< /tabs >}}
-
 ## View the Docker daemon logs
 
 Refer to the [Read the daemon logs](/manuals/engine/daemon/logs.md) section
@@ -314,3 +202,5 @@ to learn how to view the Docker Daemon logs.
 
 - View specific [troubleshoot topics](topics.md).
 - View information on [known issues](known-issues.md)
+- [Fix "Docker.app is damaged" on macOS](mac-damaged-dialog.md) - Resolve macOS installation issues
+- [Get support for Docker products](/manuals/support/_index.md)
diff --git a/content/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md b/content/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md
index d4d6afc5638c..a1b8d29947ee 100644
--- a/content/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md
+++ b/content/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md
@@ -3,22 +3,24 @@ description: Find known issues for Docker Desktop
 keywords: mac, troubleshooting, known issues, Docker Desktop
 title: Known issues
 tags: [ Troubleshooting ]
-weight: 30
+weight: 20
 aliases:
  - /desktop/troubleshoot/known-issues/
 ---
 
 {{< tabs >}}
 {{< tab name="For Mac with Intel chip" >}}
-- The Mac Activity Monitor reports that Docker is using twice the amount of memory it's actually using. This is due to a [bug in macOS].(https://docs.google.com/document/d/17ZiQC1Tp9iH320K-uqVLyiJmk4DHJ3c4zgQetJiKYQM/edit?usp=sharing) on this.
+- The Mac Activity Monitor reports that Docker is using twice the amount of memory it's actually using. This is due to a [bug in macOS](https://docs.google.com/document/d/17ZiQC1Tp9iH320K-uqVLyiJmk4DHJ3c4zgQetJiKYQM/edit?usp=sharing).
+
+- **"Docker.app is damaged" dialog**: If you see a "Docker.app is damaged and can't be opened" dialog during installation or updates, this is typically caused by non-atomic copy operations when other applications are using the Docker CLI. See [Fix "Docker.app is damaged" on macOS](mac-damaged-dialog.md) for resolution steps.
 
 - Force-ejecting the `.dmg` after running `Docker.app` from it can cause the
   whale icon to become unresponsive, Docker tasks to show as not responding in the Activity Monitor, and for some processes to consume a large amount of CPU resources. Reboot and restart Docker to resolve these issues.
 
 - Docker Desktop uses the `HyperKit` hypervisor
-  (https://github.com/docker/hyperkit) in macOS 10.10 Yosemite and higher. If
-  you are developing with tools that have conflicts with `HyperKit`, such as
-  [Intel Hardware Accelerated Execution Manager
+  (https://github.com/docker/hyperkit). If you are developing with tools that
+  have conflicts with `HyperKit`, such as [Intel Hardware Accelerated Execution
+  Manager
   (HAXM)](https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager/),
   the current workaround is not to run them at the same time. You can pause
   `HyperKit` by quitting Docker Desktop temporarily while you work with HAXM.
@@ -37,15 +39,13 @@ aliases:
 {{< /tab >}}
 {{< tab name="For Mac with Apple silicon" >}}
 
-- Some command line tools do not work when Rosetta 2 is not installed.
-  - The old version 1.x of `docker-compose`. Use Compose V2 instead - type `docker compose`.
-  - The `docker-credential-ecr-login` credential helper.
+- **"Docker.app is damaged" dialog**: If you see a "Docker.app is damaged and can't be opened" dialog during installation or updates, this is typically caused by non-atomic copy operations when other applications are using the Docker CLI. See [Fix "Docker.app is damaged" on macOS](mac-damaged-dialog.md) for resolution steps.
+
 - Some images do not support the ARM64 architecture. You can add `--platform linux/amd64` to run (or build) an Intel image using emulation.
 
    However, attempts to run Intel-based containers on Apple silicon machines under emulation can crash as QEMU sometimes fails to run the container. In addition, filesystem change notification APIs (`inotify`) do not work under QEMU emulation. Even when the containers do run correctly under emulation, they will be slower and use more memory than the native equivalent.
 
    In summary, running Intel-based containers on Arm-based machines should be regarded as "best effort" only. We recommend running `arm64` containers on Apple silicon machines whenever possible, and encouraging container authors to produce `arm64`, or multi-arch, versions of their containers. This issue should become less common over time, as more and more images are rebuilt [supporting multiple architectures](https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/).
-- Users may occasionally experience data drop when a TCP stream is half-closed.
 
 {{< /tab >}}
 {{< /tabs >}}
diff --git a/content/manuals/desktop/troubleshoot-and-support/troubleshoot/mac-damaged-dialog.md b/content/manuals/desktop/troubleshoot-and-support/troubleshoot/mac-damaged-dialog.md
new file mode 100644
index 000000000000..68586e882401
--- /dev/null
+++ b/content/manuals/desktop/troubleshoot-and-support/troubleshoot/mac-damaged-dialog.md
@@ -0,0 +1,72 @@
+---
+description: Fix "Docker.app is damaged and can't be opened. You should move it to the Trash" dialog on macOS
+keywords: docker desktop mac, damaged app, move to trash, gatekeeper, installation issues, troubleshooting
+title: Fix "Docker.app is damaged and can't be opened" on macOS
+linkTitle: MacOS app damaged dialog
+tags: [Troubleshooting]
+weight: 30
+---
+
+## Error message
+
+macOS shows the following dialog when you try to open Docker Desktop:
+
+```text
+Docker.app is damaged and can't be opened. You should move it to the Trash.
+```
+
+This error prevents Docker Desktop from launching and can occur during installation or after updates.
+
+## Possible cause
+
+This issue occurs due to a non-atomic copy during a drag/drop installation. When you drag and drop `Docker.app` from a DMG file while another application, like VS Code, is invoking the Docker CLI through symlinks, the copy operation may be interrupted, leaving the app in a partially copied state that Gatekeeper marks as "damaged".
+
+## Solution
+
+Follow these steps to resolve the issue:
+
+### Step one: Quit third-party software
+
+Close any applications that might call Docker in the background:
+
+- Visual Studio Code and other IDEs
+- Terminal applications
+- Agent apps or development tools
+- Any scripts or processes that use the Docker CLI
+
+### Step two: Remove any partial installation
+
+1. Move `/Applications/Docker.app` to Trash and empty Trash.
+2. If you used a DMG installer, eject and re-mount the Docker DMG.
+
+### Step three: Reinstall Docker Desktop
+
+Follow the instructions in the [macOS installation guide](/manuals/desktop/setup/install/mac-install.md) to reinstall Docker Desktop.
+
+### If the dialog persists
+
+If you continue to see the "damaged" dialog after following the recovery steps:
+
+1. Gather diagnostics using the terminal. Follow the instructions in [Diagnose from the terminal](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md#diagnose-from-the-terminal).
+
+   - Note down the your diagnostics ID displayed in the terminal after running diagnostics.
+
+2. Get help:
+   - If you have a paid Docker subscription, [contact support](/manuals/support/_index.md) and include your diagnostics ID
+   - For community users, [open an issue on GitHub](https://github.com/docker/desktop-feedback) and include your diagnostics ID
+
+## Prevention
+
+To avoid this issue in the future:
+
+- If your organization allows, update Docker Desktop via the in-app update flow
+- Always quit applications that use Docker before installing Docker Desktop via the DMG installer drag-and-drop approach
+- In managed environments, use PKG installations over DMG drag-and-drop
+- Keep installer volumes mounted until installation is complete
+
+## Related information
+
+- [Install Docker Desktop on Mac](/manuals/desktop/setup/install/mac-install.md)
+- [PKG installer documentation](/manuals/enterprise/enterprise-deployment/pkg-install-and-configure.md)
+- [Troubleshoot Docker Desktop](/manuals/desktop/troubleshoot-and-support/troubleshoot/_index.md)
+- [Known issues](/manuals/desktop/troubleshoot-and-support/troubleshoot/known-issues.md)
diff --git a/content/manuals/desktop/troubleshoot-and-support/troubleshoot/topics.md b/content/manuals/desktop/troubleshoot-and-support/troubleshoot/topics.md
index ba3ff6953ae1..82d8cc41082a 100644
--- a/content/manuals/desktop/troubleshoot-and-support/troubleshoot/topics.md
+++ b/content/manuals/desktop/troubleshoot-and-support/troubleshoot/topics.md
@@ -8,16 +8,11 @@ tags: [ Troubleshooting ]
 weight: 10 
 aliases:
  - /desktop/troubleshoot/topics/
- - /manuals/desktop/troubleshoot-and-support/troubleshoot/workarounds/
 ---
 
 > [!TIP]
 >
-> If you do not find a solution in troubleshooting, browse the GitHub repositories or create a new issue:
->
-> - [docker/for-mac](https://github.com/docker/for-mac/issues)
-> - [docker/for-win](https://github.com/docker/for-win/issues)
-> - [docker/for-linux](https://github.com/docker/for-linux/issues)
+> If you do not find a solution in troubleshooting, browse the GitHub repositories or [create a new issue](https://github.com/docker/desktop-feedback).
 
 ## Topics for all platforms
 
@@ -59,7 +54,7 @@ Docker Desktop uses hardware-accelerated graphics by default, which may cause pr
 
 Disable hardware acceleration:
 
-1. Edit Docker Desktop's `settings-store.json` file (or `settings.json` for Docker Desktop versions 4.34 and earlier). You can find this file at:
+1. Edit Docker Desktop's `settings-store.json` file. You can find this file at:
 
    - Mac: `~/Library/Group Containers/group.com.docker/settings-store.json`
    - Windows: `C:\Users\[USERNAME]\AppData\Roaming\Docker\settings-store.json`
@@ -68,7 +63,7 @@ Disable hardware acceleration:
 2. Add the following entry:
 
    ```JSON
-   $ "disableHardwareAcceleration": true
+   "disableHardwareAcceleration": "always"
    ```
 
 3. Save the file and restart Docker Desktop.
@@ -156,6 +151,23 @@ Ensure your username is short enough to keep paths within the allowed limit:
 
 ## Topics for Mac
 
+### Upgrade requires administrator privileges
+
+#### Cause 
+
+On macOS, users without administrator privileges cannot perform in-app upgrades from the Docker Desktop Dashboard.
+
+#### Solution
+
+> [!IMPORTANT]
+>
+> Do not uninstall the current version before upgrading. Doing so deletes all local Docker containers, images, and volumes.
+
+To upgrade Docker Desktop:
+
+- Ask an administrator to install the newer version over the existing one.
+- Use the []`--user` install flag](/manuals/desktop/setup/install/mac-install.md#security-and-access) if appropriate for your setup.
+
 ### Persistent notification telling me an application has changed my Desktop configurations
 
 #### Cause 
@@ -203,24 +215,6 @@ See also, [Hypervisor Framework
 Reference](https://developer.apple.com/library/mac/documentation/DriversKernelHardware/Reference/Hypervisor/)
 in the Apple documentation, and Docker Desktop [Mac system requirements](/manuals/desktop/setup/install/mac-install.md#system-requirements).
 
-### VPNKit keeps breaking
-
-#### Cause
-
-In Docker Desktop version 4.19, gVisor replaced VPNKit to enhance the performance of VM networking when using the Virtualization framework on macOS 13 and later.
-
-#### Solution
-
-To continue using VPNKit:
-
-1. Open your `settings-store.json` file located at `~/Library/Group Containers/group.com.docker/settings-store.json`
-2. Add:
-
-   ```JSON
-   $ "networkType":"vpnkit"
-   ```
-3. Save the file and restart Docker Desktop.
-
 ## Topics for Windows
 
 ### Docker Desktop fails to start when anti-virus software is installed
@@ -228,7 +222,7 @@ To continue using VPNKit:
 #### Cause
 
 Some anti-virus software may be incompatible with Hyper-V and Microsoft
-Windows 10 builds. The conflict
+Windows builds. The conflict
 typically occurs after a Windows update and
 manifests as an error response from the Docker daemon and a Docker Desktop start failure.
 
@@ -343,13 +337,21 @@ Also, the `\` character has a special meaning in Git Bash.
 
 Portability of the scripts is not affected as Linux treats multiple `/` as a single entry.
 
-### Docker Desktop fails due to Virtualization settings
+### Docker Desktop fails due to Virtualization not working
+
+#### Error message
+
+A typical error message is "Docker Desktop - Unexpected WSL error" mentioning the error code
+`Wsl/Service/RegisterDistro/CreateVm/HCS/HCS_E_HYPERV_NOT_INSTALLED`. Manually executing `wsl` commands
+also fails with the same error code.
 
 #### Cause
 
 - Virtualization settings are disabled in the BIOS.
 - Windows Hyper-V or WSL 2 components are missing.
 
+Note some third-party software such as Android emulators will disable Hyper-V on install.
+
 #### Solutions
 
 Your machine must have the following features for Docker Desktop to function correctly:
@@ -364,6 +366,21 @@ Your machine must have the following features for Docker Desktop to function cor
 
 ![WSL 2 enabled](../../images/wsl2-enabled.png)
 
+It must be possible to run WSL 2 commands without error, for example:
+
+```console
+PS C:\users\> wsl -l -v
+  NAME              STATE           VERSION
+* Ubuntu            Running         2
+  docker-desktop    Stopped         2
+PS C:\users\> wsl -d docker-desktop echo WSL 2 is working
+WSL 2 is working
+```
+
+If the features are enabled but the commands are not working, first check [Virtualization is turned on](#virtualization-must-be-turned-on)
+then [enable the Hypervisor at Windows startup](#hypervisor-enabled-at-windows-startup) if required. If running Docker
+Desktop in a Virtual Machine, ensure [the hypervisor has nested virtualization enabled](#turn-on-nested-virtualization).
+
 ##### Hyper-V
 
 On Windows 10 Pro or Enterprise, you can also use Hyper-V with the following features enabled:
@@ -422,6 +439,38 @@ The Virtual Machine Management Service failed to start the virtual machine 'Dock
 
 Try [enabling nested virtualization](/manuals/desktop/setup/vm-vdi.md#turn-on-nested-virtualization).
 
+### Docker Desktop with Windows Containers fails with "The media is write protected""
+
+#### Error message
+
+`FSCTL_EXTEND_VOLUME \\?\Volume{GUID}: The media is write protected`
+
+#### Cause
+
+If you're encountering failures when running Docker Desktop with Windows Containers, it might be due to
+a specific Windows configuration policy: FDVDenyWriteAccess.
+
+This policy, when enabled, causes Windows to mount all fixed drives not encrypted by BitLocker-encrypted as read-only.
+This also affects virtual machine volumes and as a result, Docker Desktop may not be able to start or run containers
+correctly because it requires read-write access to these volumes.
+
+FDVDenyWriteAccess is a Windows Group Policy setting that, when enabled, prevents write access to fixed data drives that are not protected
+by BitLocker. This is often used in security-conscious environments but can interfere with development tools like Docker.
+In the Windows registry it can be found at `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE\FDVDenyWriteAccess`.
+
+#### Solutions
+
+Docker Desktop does not support running Windows Containers on systems where FDVDenyWriteAccess is enabled. This setting interferes with the
+ability of Docker to mount volumes correctly, which is critical for container functionality.
+
+To use Docker Desktop with Windows Containers, ensure that FDVDenyWriteAccess is disabled. You can check and change this setting in the registry or through Group Policy Editor (`gpedit.msc`) under:
+
+**Computer Configuration** > **Administrative Templates** > **Windows Components** > **BitLocker Drive Encryption** > **Fixed Data Drives** > **Deny write access to fixed drives not protected by BitLocker**
+
+> [!NOTE]
+>
+> Modifying Group Policy settings may require administrator privileges and should comply with your organization's IT policies. If the setting gets reset after some time this usually means that it was overridden by the centralized configuration of your IT department. Talk to them before making any changes.
+
 ### `Docker Desktop Access Denied` error message when starting Docker Desktop
 
 #### Error message
diff --git a/content/manuals/desktop/uninstall.md b/content/manuals/desktop/uninstall.md
index 921bdf2f1723..b3520295a408 100644
--- a/content/manuals/desktop/uninstall.md
+++ b/content/manuals/desktop/uninstall.md
@@ -10,7 +10,7 @@ weight: 210
 >
 > Uninstalling Docker Desktop destroys Docker containers, images, volumes, and
 > other Docker-related data local to the machine, and removes the files generated
-> by the application. To learn how to preserve important data before uninstalling, refer to the [back up and restore data](/manuals/desktop/settings-and-maintenance/backup-and-restore.md) section.
+> by the application. To preserve important data before uninstalling, refer to the [back up and restore data](/manuals/desktop/settings-and-maintenance/backup-and-restore.md) section.
 
 {{< tabs >}}
 {{< tab name="Windows" >}}
@@ -25,7 +25,11 @@ weight: 210
 
 1. Locate the installer:
    ```console
+   # all-user installation
    $ C:\Program Files\Docker\Docker\Docker Desktop Installer.exe
+
+   # per-user installation (Beta)
+   $ %LOCALAPPDATA%\Programs\DockerDesktop\Docker Desktop Installer.exe
    ```
 2. Uninstall Docker Desktop. 
  - In PowerShell, run:
@@ -91,13 +95,6 @@ $ rm -rf ~/Library/Group\ Containers/group.com.docker
 $ rm -rf ~/.docker
 ```
 
-With Docker Desktop version 4.36 and earlier, the following files may also be left on the file system. You can remove these with administrative privileges:
-
-```console
-/Library/PrivilegedHelperTools/com.docker.vmnetd
-/Library/PrivilegedHelperTools/com.docker.socket
-```
-
 {{< /tab >}}
 {{< tab name="Ubuntu" >}}
 
@@ -170,7 +167,7 @@ To uninstall Docker Desktop for Fedora:
    ```console
    $ rm -r $HOME/.docker/desktop
    $ sudo rm /usr/local/bin/com.docker.cli
-   $ sudo apt purge docker-desktop
+   $ sudo dnf remove docker-desktop
    ```
 
    This removes configuration and data files at `$HOME/.docker/desktop`, the symlink at `/usr/local/bin/com.docker.cli`, and purges the remaining systemd service files.
@@ -187,20 +184,18 @@ To uninstall Docker Desktop for Arch:
 1. Remove the Docker Desktop application. Run:
 
    ```console
-   $ sudo pacman remove docker-desktop
+   $ sudo pacman -Rns docker-desktop
    ```
 
-   This removes the Docker Desktop package itself but doesn’t delete all of its files or settings.
+   This removes the Docker Desktop package along with its configuration files and dependencies not required by other packages.
 
-2. Manually remove leftover file.
+2. Manually remove leftover files.
 
    ```console
    $ rm -r $HOME/.docker/desktop
-   $ sudo rm /usr/local/bin/com.docker.cli
-   $ sudo apt purge docker-desktop
    ```
 
-   This removes configuration and data files at `$HOME/.docker/desktop`, the symlink at `/usr/local/bin/com.docker.cli`, and purges the remaining systemd service files.
+   This removes configuration and data files at `$HOME/.docker/desktop`.
 
 3. Clean up Docker config settings. In `$HOME/.docker/config.json`, remove the `credsStore` and `currentContext` properties.
 
diff --git a/content/manuals/desktop/use-desktop/_index.md b/content/manuals/desktop/use-desktop/_index.md
index b12be1c3ef6e..1697050bc81b 100644
--- a/content/manuals/desktop/use-desktop/_index.md
+++ b/content/manuals/desktop/use-desktop/_index.md
@@ -10,13 +10,11 @@ aliases:
 
 When you open Docker Desktop, the Docker Desktop Dashboard displays.
 
-![Docker Desktop Dashboard on Containers view](../images/dashboard.png)
-
-It provides a centralized interface to manage your [containers](container.md), [images](images.md), [volumes](volumes.md), and [builds](builds.md).
+It provides a centralized interface to manage your [containers](container.md), [images](images.md), [volumes](volumes.md), [builds](builds.md), [Kubernetes resources](kubernetes.md), and [logs](logs.md).
 
 In addition, the Docker Desktop Dashboard lets you:
 
-- Use [Ask Gordon](/manuals/ai/gordon/_index.md), a personal AI assistant embedded in Docker Desktop and the Docker CLI. It's designed to streamline your workflow and help you make the most of the Docker ecosystem.
+- Use [Gordon](/manuals/ai/gordon/_index.md), a personal AI assistant embedded in Docker Desktop and the Docker CLI. It's designed to streamline your workflow and help you make the most of the Docker ecosystem.
 - Navigate to the **Settings** menu to configure your Docker Desktop settings. Select the **Settings** icon in the Dashboard header.
 - Access the **Troubleshoot** menu to debug and perform restart operations. Select the **Troubleshoot** icon in the Dashboard header.
 - Be notified of new releases, installation progress updates, and more in the **Notifications center**. Select the bell icon in the bottom-right corner of the Docker Desktop Dashboard to access the notification center.
@@ -25,8 +23,11 @@ In addition, the Docker Desktop Dashboard lets you:
   For a more detailed guide about getting started, see [Get started](/get-started/introduction/_index.md).
 - Access [Docker Hub](/manuals/docker-hub/_index.md) to search, browse, pull, run, or view details
   of images.
-- Get to the [Docker Scout](../../scout/_index.md) dashboard.
-- Navigate to [Docker Extensions](/manuals/extensions/_index.md).
+- Navigate to [Docker Extensions](/manuals/extensions/_index.md) if you have enabled it.
+
+> [!TIP]
+>
+> You can customize the left-hand navigation to show only the tabs that matter to you, and hide the ones that don’t. Right-click the left-hand navigation, select **Customize**, and then select, deselect, or re-order the tabs.
 
 ## Docker terminal
 
diff --git a/content/manuals/desktop/use-desktop/builds.md b/content/manuals/desktop/use-desktop/builds.md
index c31b1e611409..5a47b1332bb4 100644
--- a/content/manuals/desktop/use-desktop/builds.md
+++ b/content/manuals/desktop/use-desktop/builds.md
@@ -16,9 +16,7 @@ connected to the same cloud builder.
 
 > [!NOTE]
 >
-> When building Windows container images using the `docker build` command, the legacy builder is used which does not populate the **Builds** view. To switch to using BuildKit, you can either:
-> - Set `DOCKER_BUILDKIT=1` in the build command, such as `DOCKER_BUILDKIT=1 docker build .` or
-> - Use the `docker buildx build` command
+> Windows container image builds use the legacy builder and do not appear in the **Builds** view. Only BuildKit-powered builds are shown here.
 
 ## Show build list
 
@@ -37,8 +35,6 @@ Docker Desktop settings.
 
 ### Import builds
 
-{{< summary-bar feature_name="Import builds" >}}
-
 The **Import builds** button lets you import build records for builds by other
 people, or builds in a CI environment. When you've imported a build record, it
 gives you full access to the logs, traces, and other data for that build,
diff --git a/content/manuals/desktop/use-desktop/container.md b/content/manuals/desktop/use-desktop/container.md
index 2a4ff86a54eb..1017939ebce5 100644
--- a/content/manuals/desktop/use-desktop/container.md
+++ b/content/manuals/desktop/use-desktop/container.md
@@ -66,11 +66,11 @@ Using the **Exec** tab is the same as running one of the following commands:
 - `docker exec -it <container-id> /bin/sh`
 - `docker exec -it <container-id> cmd.exe` when accessing Windows containers
 
-For more details, see the [`docker exec` CLI reference](/reference/cli/docker/exec/).
+For more details, see the [`docker exec` CLI reference](/reference/cli/docker/container/exec/).
 
 If you have enabled Docker Debug in settings, or toggled on **Debug mode** to the right of the tab options, the **Debug** tab displays. 
 
-Debug mode requires a [Pro, Team, or Business subscription](/subscription/details/). Debug mode has several advantages, such as:
+Debug mode has several advantages, such as:
 
 - A customizable toolbox. The toolbox comes with many standard Linux tools
   pre-installed, such as `vim`, `nano`, `htop`, and `curl`. For more details, see the [`docker debug` CLI reference](/reference/cli/docker/debug/).
@@ -79,13 +79,9 @@ Debug mode requires a [Pro, Team, or Business subscription](/subscription/detail
 
 To use debug mode:
 
-1. Sign in to Docker Desktop with an account that has a Pro, Team, or Business
-   subscription.
-2. After you're signed in, either:
-
-   - Hover over your running container and under the **Actions** column, select the **Show container actions**
-     menu. From the drop-down menu, select **Use Docker Debug**.
-   - Or, select the container and then select the **Debug** tab. 
+- Hover over your running container and under the **Actions** column, select the **Show container actions**
+menu. From the drop-down menu, select **Use Docker Debug**.
+- Or, select the container and then select the **Debug** tab. 
 
 To use debug mode by default, navigate to
 the **General** tab in **Settings** and select the **Enable Docker Debug by
diff --git a/content/manuals/desktop/use-desktop/images.md b/content/manuals/desktop/use-desktop/images.md
index b99038c6d25f..bd398d242ebe 100644
--- a/content/manuals/desktop/use-desktop/images.md
+++ b/content/manuals/desktop/use-desktop/images.md
@@ -99,8 +99,7 @@ When signed in, it shows you a list of images in Docker Hub organizations and re
 Select an organization from the drop-down to view a list of repositories for that organization.
 
 If you have enabled [Docker Scout](../../scout/_index.md) on the repositories,
-image analysis results (and [health scores](/manuals/scout/policy/scores.md) if
-your Docker organization is eligible) appear next to the image tags.
+image analysis results appear next to the image tags.
 
 Hovering over an image tag reveals two options:
 
diff --git a/content/manuals/desktop/use-desktop/kubernetes.md b/content/manuals/desktop/use-desktop/kubernetes.md
new file mode 100644
index 000000000000..c5429aebc88d
--- /dev/null
+++ b/content/manuals/desktop/use-desktop/kubernetes.md
@@ -0,0 +1,215 @@
+---
+description: See how you can deploy to Kubernetes on Docker Desktop
+keywords: deploy, kubernetes, kubectl, orchestration, Docker Desktop
+title: Explore the Kubernetes view
+linkTitle: Kubernetes
+aliases:
+- /desktop/kubernetes/
+- /desktop/features/kubernetes/
+weight: 50
+---
+
+Docker Desktop includes a standalone Kubernetes server and client, as well as Docker CLI integration, enabling local Kubernetes development and testing directly on your machine.
+
+The Kubernetes server runs as a single or multi-node cluster, within Docker containers. This lightweight setup helps you explore Kubernetes features, test workloads, and work with container orchestration in parallel with other Docker features.
+
+## Enable Kubernetes
+
+With Docker Desktop version 4.51 and later, you can manage Kubernetes directly from the **Kubernetes** view in the Docker Desktop Dashboard.
+
+1. Open the Docker Desktop Dashboard and select the **Kubernetes** view. 
+2. Select **Create cluster**.
+3. Choose your cluster type:
+   - **Kubeadm** creates a single-node cluster and the version is set by Docker Desktop.
+   - **kind** creates a multi-node cluster and you can set the version and number of nodes.
+   For more detailed information on each cluster type, see [Cluster provisioning method](#cluster-provisioning-method).
+4. Optional: Select **Show system containers (advanced)** to view internal containers when using Docker commands.
+5. Select **Create**. 
+
+This sets up the images required to run the Kubernetes server as containers, and installs the `kubectl` command-line tool on your system at `/usr/local/bin/kubectl` (Mac) or `C:\Program Files\Docker\Docker\resources\bin\kubectl.exe`(all-user installations) or `%LOCALAPPDATA%\Programs\DockerDesktop\resources\bin\kubectl.exe` (per-user installations) (Windows). If you installed `kubectl` using Homebrew, or by some other method, and experience conflicts, remove `/usr/local/bin/kubectl`.
+
+   > [!NOTE]
+   >
+   > Docker Desktop for Linux does not include `kubectl` by default. You can install it separately by following the [Kubernetes installation guide](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/). Ensure the `kubectl` binary is installed at `/usr/local/bin/kubectl`.
+
+The following actions are also triggered in the Docker Desktop backend and VM:
+
+- Generation of certificates and cluster configuration
+- Download and installation of Kubernetes internal components
+- Cluster boot-up
+- Installation of additional controllers for networking and storage
+
+When Kubernetes is enabled, its status is displayed in the Docker Desktop Dashboard footer and the Docker menu.
+
+You can check which version of Kubernetes you're on with:
+
+```console
+$ kubectl version
+```
+
+### Cluster provisioning method
+
+Docker Desktop Kubernetes can be provisioned with either the `kubeadm` or `kind`
+provisioners.
+
+`kubeadm` is the older provisioner. It supports a single-node cluster, you can't select the kubernetes
+version, it's slower to provision than `kind`, and it's not supported by [Enhanced Container Isolation](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/index.md) (ECI),
+meaning that if ECI is enabled the cluster works but it's not protected by ECI.
+
+`kind` is the newer provisioner. It supports multi-node clusters (for
+a more realistic Kubernetes setup), you can choose the Kubernetes version, it's
+faster to provision than `kubeadm`, and it's supported by ECI - when ECI is
+enabled, the Kubernetes cluster runs in unprivileged Docker containers, thus
+making it more secure. 
+
+| Feature | `kubeadm` | `kind` |
+| :------ | :-----: | :--: |
+| Multi-node cluster support | No | Yes |
+| Kubernetes version selector | No | Yes |
+| Speed to provision | ~1 min | ~30 seconds |
+| Supported by ECI | No | Yes |
+| Works with containerd image store | Yes | Yes |
+| Works with Docker image store | Yes | No |
+
+## Dashboard view
+
+When a Kubernetes cluster is enabled, the **Kubernetes** view displays a live dashboard view showing:
+
+- A namespace selector at the top
+- A real-time list of resources - pods, services, deployments - in the selected namespace
+- Automatic updates when resources are created, deleted, or modified
+
+## Verify installation
+
+Confirm that your cluster is running:
+
+```console
+$ kubectl get nodes
+NAME                 STATUS    ROLES            AGE       VERSION
+docker-desktop       Ready     control-plane    3h        v1.29.1
+```
+
+If kubectl is pointing to another environment, switch to the Docker Desktop context:
+
+```console
+$ kubectl config use-context docker-desktop
+```
+
+>[!TIP]
+>
+> If no contexts appear, try:
+>
+> - Running the command in the Command Prompt or PowerShell.
+> - Setting the `KUBECONFIG` environment variable to point to your `.kube/config` file.
+
+
+For more information about `kubectl`, see the
+[`kubectl` documentation](https://kubernetes.io/docs/reference/kubectl/overview/).
+
+## Edit or stop your cluster
+
+When Kubernetes is enabled:
+
+- Select **Edit cluster** to modify configuration. For example, switch between **kubeadm** and **kind**, or change the number of nodes.
+- Select **Stop** to disable the cluster. Progress is displayed, and the **Kubernetes** view returns to the **Create cluster** screen. This stops and removes Kubernetes containers, and also removes the `/usr/local/bin/kubectl` command.
+
+## Upgrade your cluster
+
+Kubernetes clusters are not automatically upgraded with Docker Desktop updates. To upgrade the cluster, you must manually select **Reset cluster** in the **Kubernetes** settings.
+
+## Configuring a custom image registry for Kubernetes control plane images
+
+Docker Desktop uses containers to run the Kubernetes control plane. By default, Docker Desktop pulls
+the associated container images from Docker Hub. The images pulled depend on the [cluster provisioning mode](#cluster-provisioning-method).
+
+For example, in `kind` mode it requires the following images:
+
+```console
+docker.io/kindest/node:<tag>
+docker.io/envoyproxy/envoy:<tag>
+docker.io/docker/desktop-cloud-provider-kind:<tag>
+docker.io/docker/desktop-containerd-registry-mirror:<tag>
+```
+
+In `kubeadm` mode it requires the following images:
+
+```console
+docker.io/docker/desktop-kubernetes:<tag>
+docker.io/docker/desktop-storage-provisioner:<tag>
+docker.io/docker/desktop-vpnkit-controller:<tag>
+docker.io/docker/desktop-kubernetes-etcd:<tag>
+docker.io/docker/desktop-kubernetes-coredns:<tag>
+docker.io/docker/desktop-kubernetes-pause:<tag>
+docker.io/docker/desktop-kubernetes-apiserver:<tag>
+docker.io/docker/desktop-kubernetes-controller-manager:<tag>
+docker.io/docker/desktop-kubernetes-scheduler:<tag>
+docker.io/docker/desktop-kubernetes-proxy:<tag>
+```
+
+The image tags are automatically selected by Docker Desktop based on several
+factors, including the version of Kubernetes being used. The tags vary for each image and may change between Docker Desktop releases. To stay informed, monitor the Docker Desktop release notes.
+
+> [!NOTE]
+>
+> In Docker Desktop versions 4.44 or later you can run `docker desktop kubernetes images list` to list Kubernetes images used by the currently installed version of Docker Desktop.
+> For more information, see the [Docker Desktop CLI](/reference/cli/docker/desktop/kubernetes/images).
+
+To accommodate scenarios where access to Docker Hub is not allowed, admins can
+configure Docker Desktop to pull the above listed images from a different registry (e.g., a mirror)
+using the [KubernetesImagesRepository](/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md#kubernetes) setting as follows.
+
+An image name can be broken into `[registry[:port]/][namespace/]repository[:tag]` components.
+The `KubernetesImagesRepository` setting allows users to override the `[registry[:port]/][namespace]`
+portion of the image's name.
+
+For example, if Docker Desktop Kubernetes is configured in `kind` mode and
+`KubernetesImagesRepository` is set to `my-registry:5000/kind-images`, then
+Docker Desktop will pull the images from:
+
+```console
+my-registry:5000/kind-images/node:<tag>
+my-registry:5000/kind-images/envoy:<tag>
+my-registry:5000/kind-images/desktop-cloud-provider-kind:<tag>
+my-registry:5000/kind-images/desktop-containerd-registry-mirror:<tag>
+```
+
+These images should be cloned/mirrored from their respective images in Docker Hub. The tags must
+also match what Docker Desktop expects.
+
+The recommended approach to set this up is the following:
+
+1. Start Kubernetes using the desired cluster provisioning method: `kubeadm` or `kind`.
+2. After Kubernetes has started, use either:
+   - (Docker Desktop version 4.44 or later) `docker desktop kubernetes images list` to list the image tags that will be pulled by the current Docker Desktop installation
+   - `docker ps` to view the container images used by Docker Desktop for the Kubernetes control plane
+3. Clone or mirror those images (with matching tags) to your custom registry.
+4. Stop the Kubernetes cluster.
+5. Configure the `KubernetesImagesRepository` setting to point to your custom registry.
+6. Restart Docker Desktop.
+7. Verify that the Kubernetes cluster is using the custom registry images using the `docker ps` command.
+
+> [!NOTE]
+>
+> The `KubernetesImagesRepository` setting only applies to control plane images used by Docker Desktop
+> to set up the Kubernetes cluster. It has no effect on other Kubernetes pods.
+
+> [!NOTE]
+>
+> In Docker Desktop versions 4.43 or earlier, when using `KubernetesImagesRepository` and [Enhanced Container Isolation (ECI)](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md)
+> is enabled, add the following images to the [ECI Docker socket mount image list](/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md#enhanced-container-isolation):
+>
+> `[imagesRepository]/desktop-cloud-provider-kind:`
+> `[imagesRepository]/desktop-containerd-registry-mirror:`
+>
+> These containers mount the Docker socket, so you must add the images to the ECI images list. If not,
+> ECI will block the mount and Kubernetes won't start.
+
+## Troubleshooting
+
+- If Kubernetes fails to start, make sure Docker Desktop is running with enough allocated resources. Check **Settings** > **Resources**.
+- If the `kubectl` commands return errors, confirm the context is set to `docker-desktop`
+   ```console
+   $ kubectl config use-context docker-desktop
+   ```
+   You can then try checking the logs of the Kubernetes system containers if you have enabled that setting.
+- If you're experiencing cluster issues after updating, reset your Kubernetes cluster. Resetting a Kubernetes cluster can help resolve issues by essentially reverting the cluster to a clean state, and clearing out misconfigurations, corrupted data, or stuck resources that may be causing problems. If the issue still persists, you may need to clean and purge data, and then restart Docker Desktop.
diff --git a/content/manuals/desktop/use-desktop/logs.md b/content/manuals/desktop/use-desktop/logs.md
new file mode 100644
index 000000000000..0dc31e8aacbd
--- /dev/null
+++ b/content/manuals/desktop/use-desktop/logs.md
@@ -0,0 +1,58 @@
+---
+description: Understand what you can do with the Logs view on Docker Dashboard
+keywords: Docker Dashboard, manage, logs, gui, build logs, container logs, debugging, dashboard
+title: Explore the Logs view in Docker Desktop
+linkTitle: Logs
+weight: 60
+---
+
+{{< summary-bar feature_name="Desktop logs" >}}
+
+The **Logs** view provides a unified, real-time log stream from all containers and recent builds in Docker Desktop. Unlike the logs accessible from the [**Containers** view](container.md), the **Logs** view lets you monitor and search log output (up to a maximum of 100 000 entries) across your entire environment from a single interface. 
+
+## Log entries
+
+Each log entry in the table view shows:
+
+| Column        | Description                                                                    |
+| ------------- | ------------------------------------------------------------------------------ |
+| **Timestamp** | The date and time the log line was emitted, for example `2026-02-26 11:18:53`. |
+| **Object**    | The container or build that produced the log line.                             |
+| **Message**   | The full log message, including any status codes such as `[ OK ]`.             |
+
+Selecting the expand arrow to the right of a row reveals the full message for that entry.
+
+## Search, filter, and export logs
+
+Use the **Search** field at the top of the Logs view to find specific entries. The search bar supports:
+
+- Plain-text terms for exact match searches
+- Regular expressions (for example, `/error|warn/`)
+
+You can save your current filters as a preset for easy access later. Presets capture your container selection, build log visibility, and case sensitivity settings, as well as any active search terms. If no containers are selected, the preset is named all; otherwise it is named after the first selected container.
+
+To refine the log stream further, select the **Filter** icon in the toolbar to open the container filter panel. From here you can:
+
+- Check individual containers to show only their output
+- Check Compose stacks to show or hide entire groups
+- Toggle off **View build logs** to exclude build-related log output in the stream
+- Use **Select all** or **Clear container filters** to quickly toggle every container at once
+
+Use the **Export** button in the top-right corner (available with Docker Desktop version 4.77 and later) to export all logs or only the logs that match your filters.
+
+## Display settings
+
+Select the **Display settings** icon in the toolbar to toggle the following:
+- **Wrap lines**
+- **Show timestamps**
+
+You can also choose **Clear logs** to remove log entries from the view (available with Docker Desktop 4.79 and later). A dialog lets you choose between two options:
+
+- **Clear all logs**: Immediately hides all current log entries.
+- **Clear logs before**: Activates a date and time picker. Only entries at or before the selected timestamp are hidden.
+
+The cleared state persists across Docker Desktop restarts. Once entries are cleared, they cannot be restored.
+
+## Feedback
+
+Select **Give feedback** at the top of the view to share suggestions or report issues.
diff --git a/content/manuals/desktop/use-desktop/pause.md b/content/manuals/desktop/use-desktop/pause.md
index e7b882097f0b..14265255c558 100644
--- a/content/manuals/desktop/use-desktop/pause.md
+++ b/content/manuals/desktop/use-desktop/pause.md
@@ -2,7 +2,7 @@
 description: understand what pausing Docker Desktop Dashboard means
 keywords: Docker Desktop Dashboard, manage, containers, gui, dashboard, pause, user manual
 title: Pause Docker Desktop
-weight: 60
+weight: 80
 ---
 
 Pausing Docker Desktop temporarily suspends the Linux VM running Docker Engine. This saves the current state of all containers in memory and freezes all running processes, significantly reducing CPU and memory usage which is helpful for conserving battery on laptops.
diff --git a/content/manuals/desktop/use-desktop/resource-saver.md b/content/manuals/desktop/use-desktop/resource-saver.md
index 10162288b357..746db0ab3fa8 100644
--- a/content/manuals/desktop/use-desktop/resource-saver.md
+++ b/content/manuals/desktop/use-desktop/resource-saver.md
@@ -3,7 +3,7 @@ description: Understand what Docker Desktop Resource Saver mode is and how to co
 keywords: Docker Dashboard, resource saver, manage, containers, gui, dashboard, user manual
 title: Docker Desktop's Resource Saver mode
 linkTitle: Resource Saver mode
-weight: 50
+weight: 70
 ---
 
 Resource Saver mode significantly reduces Docker
@@ -20,7 +20,7 @@ experience.
 Resource Saver is enabled by default but can be disabled by navigating to the **Resources** tab, in **Settings**. You can also configure the idle
 timer as shown below.
 
-![Resource Saver Settings](../images/resource-saver-settings.png)
+![Resource Saver Settings](../images/resource-saver-settings.webp) 
 
 If the values available aren't sufficient for your
 needs, you can reconfigure it to any value, as long as the value is larger than 30 seconds, by
@@ -33,13 +33,9 @@ changing `autoPauseTimeoutSeconds` in the Docker Desktop `settings-store.json` f
 There's no need to restart Docker Desktop after reconfiguring. 
 
 When Docker Desktop enters Resource Saver mode: 
-- A leaf icon displays on the
+- A moon icon displays on the
 Docker Desktop status bar as well as on the Docker icon in
-the system tray. The following image shows the Linux VM CPU and memory utilization reduced
-to zero when Resource Saver mode is on. 
-
-   ![Resource Saver Status Bar](../images/resource-saver-status-bar.png)
-
+the system tray. 
 - Docker commands that don't run containers, for example listing container images or volumes, don't necessarily trigger an exit from Resource Saver mode as Docker Desktop can serve such commands without unnecessarily waking up the Linux VM.
 
 > [!NOTE]
diff --git a/content/manuals/desktop/use-desktop/volumes.md b/content/manuals/desktop/use-desktop/volumes.md
index 1486ff4f8dbf..6b3cafd7eec8 100644
--- a/content/manuals/desktop/use-desktop/volumes.md
+++ b/content/manuals/desktop/use-desktop/volumes.md
@@ -146,13 +146,13 @@ You can either [export a volume now](#export-a-volume-now) or [schedule a recurr
    {{< /tab >}}
    {{< tab name="External cloud storage" >}}
 
-   You must have a [Docker Business subscription](../../subscription/details.md) to export to an external cloud provider.
+   You must have a [Docker Business subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopVolumes) to export to an external cloud provider.
 
    Select your cloud provider and then specify the URL to upload to the storage.
    Refer to the following documentation for your cloud provider to learn how to
    obtain a URL.
 
-   - Amazon Web Services: [Create a presigned URL for Amazon S3 using an AWS SDK](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example_s3_Scenario_PresignedUrl_section.html)
+   - Amazon Web Services: [Create a presigned URL of Amazon S3 using an AWS SDK](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example_s3_Scenario_PresignedUrl_section.html)
    - Microsoft Azure: [Generate a SAS token and URL](https://learn.microsoft.com/en-us/azure/data-explorer/kusto/api/connection-strings/generate-sas-token)
    - Google Cloud: [Create a signed URL to upload an object](https://cloud.google.com/storage/docs/access-control/signing-urls-with-helpers#upload-object)
 
@@ -163,7 +163,7 @@ You can either [export a volume now](#export-a-volume-now) or [schedule a recurr
 
 ### Schedule a volume export
 
-1. Sign in to Docker Desktop. You must be signed in and have a paid [Docker subscription](../../subscription/details.md) to schedule a volume export.
+1. Sign in to Docker Desktop. You must be signed in and have a paid [Docker subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopVolumes) to schedule a volume export.
 2. In the **Volumes** view, select the volume you want to export.
 3. Select the **Exports** tab.
 4. Select **Schedule export**.
@@ -192,13 +192,13 @@ You can either [export a volume now](#export-a-volume-now) or [schedule a recurr
    {{< /tab >}}
    {{< tab name="External cloud storage" >}}
 
-   You must have a [Docker Business subscription](../../subscription/details.md) to export to an external cloud provider.
+   You must have a [Docker Business subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsDesktopVolumes) to export to an external cloud provider.
 
    Select your cloud provider and then specify the URL to upload to the storage.
    Refer to the following documentation for your cloud provider to learn how to
    obtain a URL.
 
-   - Amazon Web Services: [Create a presigned URL for Amazon S3 using an AWS SDK](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example_s3_Scenario_PresignedUrl_section.html)
+   - Amazon Web Services: [Create a presigned URL of Amazon S3 using an AWS SDK](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example_s3_Scenario_PresignedUrl_section.html)
    - Microsoft Azure: [Generate a SAS token and URL](https://learn.microsoft.com/en-us/azure/data-explorer/kusto/api/connection-strings/generate-sas-token)
    - Google Cloud: [Create a signed URL to upload an object](https://cloud.google.com/storage/docs/access-control/signing-urls-with-helpers#upload-object)
 
diff --git a/content/manuals/dhi/_index.md b/content/manuals/dhi/_index.md
new file mode 100644
index 000000000000..0e7d4386c7ef
--- /dev/null
+++ b/content/manuals/dhi/_index.md
@@ -0,0 +1,119 @@
+---
+title: Docker Hardened Images
+description: Secure, minimal, and production-ready base images
+weight: 8
+aliases:
+  - /dhi/features/
+  - /dhi/features/secure/
+  - /dhi/features/integration/
+  - /dhi/features/support/
+  - /dhi/features/patching/
+  - /dhi/features/flexible/
+  - /dhi/features/helm/
+params:
+  sidebar:
+    group: Supply chain security
+  grid_sections:
+    - title: Quickstart
+      description: Follow a step-by-step guide to explore and run a Docker Hardened Image.
+      icon: rocket-launch
+      link: /dhi/get-started/
+    - title: Explore
+      description: Learn what Docker Hardened Images are, how they're built, and what sets them apart from typical base images.
+      icon: information-circle
+      link: /dhi/explore/
+    - title: How-tos
+      description: Step-by-step guides for using, verifying, scanning, and migrating to Docker Hardened Images.
+      icon: play
+      link: /dhi/how-to/
+    - title: Security concepts
+      description: Understand the secure supply chain principles that make Docker Hardened Images production-ready.
+      icon: clipboard-document-check
+      link: /dhi/explore/security-concepts/
+    - title: Tools
+      description: Browse and manage Docker Hardened Images using Docker Hub, the CLI, MCP server, or Terraform.
+      icon: wrench-screwdriver
+      link: /dhi/tools/
+    - title: Resources and feedback
+      description: Guides, GitHub repositories, community channels, and how to give feedback.
+      icon: link
+      link: /dhi/resources/
+    - title: Release notes
+      description: New features, improvements, and changes in Docker Hardened Images.
+      icon: newspaper
+      link: /dhi/release-notes/platform/
+---
+
+Docker Hardened Images (DHI) provide minimal, secure, and production-ready
+container images, Helm charts, and system packages maintained by Docker.
+Designed to reduce vulnerabilities and simplify compliance, DHI integrates
+easily into your existing Docker-based workflows with little to no retooling
+required.
+
+DHI is available in the following three subscriptions.
+
+| Feature | Community | Select | Enterprise |
+|---|---|---|---|
+| Hardened, minimal images | ✅ | ✅ | ✅ |
+| Near-zero CVEs | ✅ | ✅ | ✅ |
+| Verifiable SBOMs & SLSA Build L3 provenance | ✅ | ✅ | ✅ |
+| Full, unsuppressed CVE visibility | ✅ | ✅ | ✅ |
+| Drop-in adoption, no workflow changes | ✅ | ✅ | ✅ |
+| Full catalog of open source images under Apache 2.0 | ✅ | ✅ | ✅ |
+| Built with Docker Hardened System Packages | ✅ | ✅ | ✅ |
+| Upstream cadence for Docker-released patches | ✅ | ✅ | ✅ |
+| FIPS/STIG variants | ❌ | ✅ | ✅ |
+| Critical CVE fixes < 7 days with SLA-backed continuous patching | ❌ | ✅ | ✅ |
+| Customizations | ❌ | ✅ Up to 5 | ✅ Unlimited |
+| Access to Hardened System Packages repository | ❌ | ❌ | ✅ |
+| Full catalog access available | ❌ | ❌ | ✅ |
+| Extended Lifecycle Support add-on available | ❌ | ❌ | ✅ +5 years of hardened updates |
+
+For pricing and more details, see the [Docker Hardened Images subscription
+comparison](https://www.docker.com/products/hardened-images/#compare).
+
+## Community features
+
+DHI's core features are free to use, share, and build on under Apache 2.0.
+
+- [Near-zero CVEs](/dhi/explore/security-concepts/cves/): continuously scanned and patched
+  to maintain minimal known vulnerabilities
+- [Distroless variants](/dhi/explore/security-concepts/distroless/): remove unnecessary
+  components, reducing attack surface by up to 95%
+- Non-root execution: containers run as non-root by default
+- [Hardened system packages](/dhi/how-to/hardened-packages/): system packages
+  built from source, cryptographically signed, and verified by Docker
+- [SLSA Build Level 3 provenance](/dhi/explore/security-concepts/slsa/), [signed
+  SBOMs](/dhi/explore/security-concepts/sbom/), [VEX statements](/dhi/explore/security-concepts/vex/),
+  and [cryptographic signatures](/dhi/explore/security-concepts/signatures/) on every image
+- Built on Alpine and Debian with [glibc and musl
+  variants](/dhi/explore/security-concepts/glibc-musl/); dev and runtime image variants
+  available
+- Works with existing Docker workflows, CI/CD pipelines, and tools with no
+  retooling required
+- [Helm charts](/dhi/how-to/helm/): Docker-provided charts built from upstream
+  sources, tested for compatibility with DHI, and available as OCI artifacts in
+  the DHI catalog; include SLSA Level 3 provenance, SBOMs, and cryptographic
+  signing
+
+## Select and Enterprise features
+
+For organizations with strict security or compliance requirements:
+
+- [7-day SLA](https://docs.docker.com/go/dhi-sla/) for critical and high
+  severity CVE remediation
+- [FIPS-enabled](/dhi/explore/security-concepts/fips/) and
+  [STIG-ready](/dhi/explore/security-concepts/stig/) compliance variants
+- [Customization](/dhi/how-to/customize/): add packages, tools, certificates,
+  and configurations (up to 5 with Select, unlimited with Enterprise)
+- [Enterprise package repository](/dhi/how-to/hardened-packages/) access and
+  full catalog access (Enterprise)
+- Extended Lifecycle Support: post-EOL security patches, updated SBOMs,
+  provenance, and signing (Enterprise add-on)
+
+## Get started
+
+Explore the sections below to get started with Docker Hardened Images, integrate
+them into your workflow, and learn what makes them secure and enterprise-ready.
+
+{{< grid items="grid_sections" >}}
diff --git a/content/manuals/dhi/explore/_index.md b/content/manuals/dhi/explore/_index.md
new file mode 100644
index 000000000000..8336abaa8159
--- /dev/null
+++ b/content/manuals/dhi/explore/_index.md
@@ -0,0 +1,58 @@
+---
+linktitle: Explore
+title: Explore Docker Hardened Images
+description: Learn about Docker Hardened Images, their purpose, how they are built and tested, and the shared responsibility model for security.
+weight: 10
+params:
+  grid_about:
+    - title: What are hardened images and why use them?
+      description: Learn what a hardened image is, how Docker Hardened Images are built, what sets them apart from typical base and application images, and why you should use them.
+      icon: information-circle
+      link: /dhi/explore/what/
+    - title: Build process
+      description: Learn how Docker builds, tests, and maintains Docker Hardened Images through an automated, security-focused pipeline.
+      icon: wrench-screwdriver
+      link: /dhi/explore/build-process/
+    - title: Image types
+      description: Learn about the different image types, distributions, and variants offered in the Docker Hardened Images catalog.
+      icon: squares-2x2
+      link: /dhi/explore/available/
+    - title: Scanner integrations
+      description: Discover which vulnerability scanners integrate with Docker Hardened Images and support open standards like OpenVEX.
+      icon: shield-check
+      link: /dhi/explore/scanner-integrations/
+    - title: Image testing
+      description: See how Docker Hardened Images are automatically tested for standards compliance, functionality, and security.
+      icon: beaker
+      link: /dhi/explore/test/
+    - title: Malware scanning
+      description: Learn how Docker scans Docker Hardened Images for viruses and malware, and how to view and verify the scan attestation.
+      icon: bug-ant
+      link: /dhi/explore/malware-scanning/
+    - title: Responsibility overview
+      description: Understand Docker's role and your responsibilities when using Docker Hardened Images as part of your secure software supply chain.
+      icon: user-group
+      link: /dhi/explore/responsibility/
+    - title: Security concepts
+      description: Learn the core concepts behind Docker Hardened Images — signed attestations, immutable digests, SLSA, VEX, and more.
+      icon: clipboard-document-check
+      link: /dhi/explore/security-concepts/
+
+aliases:
+  - /dhi/about/
+---
+
+Docker Hardened Images (DHI) are minimal, secure, and production-ready container
+base and application images maintained by Docker. Designed to reduce
+vulnerabilities and simplify compliance, DHI integrates easily into your
+existing Docker-based workflows with little to no retooling required.
+
+This section helps you understand what Docker Hardened Images are, how they're
+built and tested, the different types available, and how responsibility is
+shared between Docker and you as a user.
+
+## Learn more about Docker Hardened Images
+
+{{< grid
+  items="grid_about"
+>}}
diff --git a/content/manuals/dhi/explore/available.md b/content/manuals/dhi/explore/available.md
new file mode 100644
index 000000000000..3db9c8c5c539
--- /dev/null
+++ b/content/manuals/dhi/explore/available.md
@@ -0,0 +1,160 @@
+---
+linktitle: Image types
+title: Available types of Docker Hardened Images
+description: Learn about the different image types, distributions, and variants offered in the Docker Hardened Images catalog.
+keywords: docker hardened images, distroless containers, distroless images, docker distroless, alpine base image, debian base image, development containers, runtime containers, secure base image, multi-stage builds
+weight: 20
+aliases:
+  - /dhi/about/available/
+---
+
+Docker Hardened Images (DHI) is a comprehensive catalog of
+security-hardened container images built to meet diverse
+development and production needs.
+
+You can explore the DHI catalog on [Docker Hub](https://hub.docker.com/hardened-images/catalog) or use the [DHI CLI](../tools/cli.md) to browse
+available images, tags, and metadata from the command line.
+
+## Framework and application images
+
+DHI includes a selection of popular frameworks and application images, each
+hardened and maintained to ensure security and compliance. These images
+integrate seamlessly into existing workflows, allowing developers to focus on
+building applications without compromising on security.
+
+For example, you might find repositories like the following in the DHI catalog:
+
+- `node`: framework for Node.js applications
+- `python`: framework for Python applications
+- `nginx`: web server image
+
+## Base image distributions
+
+Docker Hardened Images are available in different base image options, giving you
+flexibility to choose the best match for your environment and workload
+requirements:
+
+- Debian-based images: A good fit if you're already working in glibc-based
+  environments. Debian is widely used and offers strong compatibility across
+  many language ecosystems and enterprise systems.
+
+- Alpine-based images: A smaller and more lightweight option using musl libc.
+  These images tend to be small and are therefore faster to pull and have a
+  reduced footprint.
+
+Each image maintains a minimal and secure runtime layer by removing
+non-essential components like shells, package managers, and debugging tools.
+This helps reduce the attack surface while retaining compatibility with common
+runtime environments. To maintain this lean, secure foundation, DHI standardizes
+on Debian for glibc-based images, which provides broad compatibility while
+minimizing complexity and maintenance overhead.
+
+Example tags include:
+
+- `3.9.23-alpine3.21`: Alpine-based image for Python 3.9.23
+- `3.9.23-debian12`: Debian-based image for Python 3.9.23
+
+If you're not sure which to choose, start with the base you're already familiar
+with. Debian tends to offer the broadest compatibility.
+
+## Development and runtime variants
+
+To accommodate different stages of the application lifecycle, DHI offers all
+language framework images and select application images in two variants:
+
+- Development (dev) images: Equipped with necessary development tools and
+libraries, these images facilitate the building and testing of applications in a
+secure environment. They include a shell, package manager, a root user, and
+other tools needed for development.
+
+- Runtime images: Stripped of development tools, these images contain only the
+essential components needed to run applications, ensuring a minimal attack
+surface in production.
+
+This separation supports multi-stage builds, enabling developers to compile code
+in a secure build environment and deploy it using a lean runtime image.
+
+For example, you might find tags like the following in a DHI repository:
+
+- `3.9.23-debian12`: runtime image for Python 3.9.23
+- `3.9.23-debian12-dev`: development image for Python 3.9.23
+
+## FIPs and STIG variants
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+Some Docker Hardened Images include a `-fips` variant. These variants use
+cryptographic modules that have been validated under [FIPS
+140](security-concepts/fips.md), a U.S. government standard for secure
+cryptographic operations.
+
+FIPS variants are designed to help organizations meet regulatory and compliance
+requirements related to cryptographic use in sensitive or regulated
+environments.
+
+You can recognize FIPS variants by their tag that includes `-fips`.
+
+For example:
+- `3.13-fips`: FIPS variant of the Python 3.13 image
+- `3.9.23-debian12-fips`: FIPS variant of the Debian-based Python 3.9.23 image
+
+FIPS variants can be used in the same way as any other Docker Hardened Image and
+are ideal for teams operating in regulated industries or under compliance
+frameworks that require cryptographic validation.
+
+In addition to FIPS variants, some Docker Hardened Images also include
+STIG-ready variants. These images are scanned against custom STIG-based
+profiles and come with signed STIG scan attestations to support audits and
+compliance reporting. To identify STIG-ready variants, look for the **STIG**
+in the **Compliance** column of the image tags list in the Docker Hub catalog.
+
+## Compatibility variants
+
+Some Docker Hardened Images include a compatibility variant. These variants
+provide additional tools and configurations for specific use cases without
+bloating the minimal base images.
+
+Compatibility variants are created to support:
+
+- Helm chart compatibility: Applications deployed via Helm charts and
+  Kubernetes that require specific runtime configurations or utilities for
+  seamless integration with popular Helm charts.
+
+- Special application use-cases: Applications that need optional tools not
+  included in the minimal image.
+
+By offering these as separate image flavors, DHI ensures that the minimal images
+remain lean and secure, while providing the tools you need in dedicated
+variants. This approach maintains a minimal attack surface for standard
+deployments while supporting specialized requirements when needed.
+
+You can recognize compatibility variants by their tag that includes `-compat`.
+
+Use compatibility variants when your deployment requires additional tools beyond
+the minimal runtime, such as when using Helm charts or applications with
+specific tooling requirements.
+
+## Socket Firewall variants
+
+Some Docker Hardened Images include Socket Firewall variants. These are `dev`
+variants that come with [Socket](https://socket.dev/) preinstalled to monitor
+package manager activity and block malicious packages during development and CI
+builds.
+
+Two tiers are available, identified by their tag suffix:
+
+- `-sfw-dev`: Socket Firewall Free. No API key required.
+- `-sfw-ent-dev`: Socket Firewall Enterprise. Requires an API key from Socket.
+
+Not all images offer both tiers.
+
+## Image-specific variants
+
+Some images include variants that go beyond the general `dev`, `compat`, and
+`sfw` patterns. These represent distinct editions, bundled tooling, or
+runtime configurations specific to that image. Examples include a PHP-FPM variant
+for web server integration, a native binary build for faster startup, or a
+specific edition of a database.
+
+You can identify these variants by their tag suffix. The image name in the tag
+suffix typically reflects what's included or different.
diff --git a/content/manuals/dhi/explore/build-process.md b/content/manuals/dhi/explore/build-process.md
new file mode 100644
index 000000000000..e2bcd2930ee4
--- /dev/null
+++ b/content/manuals/dhi/explore/build-process.md
@@ -0,0 +1,189 @@
+---
+title: How Docker Hardened Images are built
+linkTitle: Build process
+description: Learn how Docker builds, tests, and maintains Docker Hardened Images through an automated, security-focused pipeline.
+keywords: docker hardened images, slsa build level 3, automated patching, ai guardrail, build process, signed sbom, supply chain security
+weight: 15
+aliases:
+  - /dhi/about/build-process/
+---
+
+Docker Hardened Images are built through an automated pipeline that monitors
+upstream sources, applies security updates, and publishes signed artifacts.
+This page explains the build process for both base DHI images and customized
+images available with DHI Select and DHI Enterprise subscriptions.
+
+With DHI Select or DHI Enterprise subscriptions, the automated security update pipeline for
+both base and customized images is backed by [SLA commitments](https://docs.docker.com/go/dhi-sla/), including a 7-day
+SLA for critical and high severity vulnerabilities. DHI Community offers a secure baseline
+but no guaranteed remediation timelines.
+
+## Build transparency
+
+Docker Hardened Images provide transparency into how images are built through
+publicly available definitions and verifiable attestations.
+
+### Image definitions
+
+All image definitions are publicly available in the [catalog
+repository](https://github.com/docker-hardened-images/catalog).
+
+Each image definition is a declarative YAML specification that includes metadata,
+contents, build pipeline steps, security configurations, and runtime settings.
+
+### SLSA attestations
+
+Every Docker Hardened Image includes a SLSA Build Level 3 attestation that
+provides verifiable build provenance. For details on SLSA attestations and how to
+verify them, see [SLSA](security-concepts/slsa.md).
+
+## Build triggers
+
+Builds start automatically. You don't trigger them manually. The system monitors
+for changes and starts builds in two scenarios:
+
+- [Upstream updates](#upstream-updates)
+- [Customization changes](#customization-changes)
+
+### Upstream updates
+
+New releases, package updates, or CVE fixes from upstream projects trigger base
+image rebuilds. These builds go through quality checks to ensure security and
+reliability.
+
+#### Monitoring for updates
+
+Docker continuously monitors upstream projects for new releases, package
+updates, and security advisories. When changes are detected, the system
+automatically queues affected images for rebuild using a SLSA Build Level
+3-compliant build system.
+
+Docker uses three strategies to track updates:
+
+- GitHub releases: Monitors specific GitHub repositories for new releases and
+  automatically updates the image definition when a new version is published.
+- GitHub tags: Tracks tags in GitHub repositories to detect new versions.
+- Package repositories: Monitors Alpine Linux, Debian, and Ubuntu package
+  repositories through Docker Scout's package database to detect updated
+  packages.
+
+In addition to explicit upstream tracking, Docker also monitors transitive
+dependencies. When a package update is detected (for example, a security patch
+for a library), Docker automatically identifies and rebuilds all images within
+the support window that use that package.
+
+### Customization changes
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+Updates to your OCI artifact customizations trigger rebuilds of your customized
+images.
+
+When you customize a DHI image with DHI Select or DHI Enterprise, your changes are packaged as
+OCI artifacts that layer on top of the base image. Docker monitors your artifact
+repositories and automatically rebuilds your customized images whenever you push
+updates.
+
+The rebuild process fetches the current base image, applies your OCI artifacts,
+signs the result, and publishes it automatically. You don't need to manage
+builds or maintain CI pipelines for your customized images.
+
+Customized images are also rebuilt automatically when the base DHI image they
+depend on receives updates, ensuring your images always include the latest
+security patches.
+
+## Build pipeline
+
+The following sections describe the build pipeline architecture and workflow for
+Docker Hardened Images based on:
+
+- [Base image pipeline](#base-image-pipeline)
+- [Customized image pipeline](#customized-image-pipeline)
+
+### Base image pipeline
+
+Each Docker Hardened Image is built through an automated pipeline:
+
+1. Monitoring: Docker monitors upstream sources for updates (new releases,
+   package updates, security advisories).
+2. Rebuild trigger: When changes are detected, an automated rebuild starts.
+3. AI guardrail: An AI system fetches upstream diffs and scans them with
+   language-aware checks. The guardrail focuses on high-leverage issues that can
+   cause significant problems, such as inverted error checks, ignored failures,
+   resource mishandling, or suspicious contributor activity. When it spots
+   potential risks, it blocks the PR from auto-merging.
+4. Human review: If the AI identifies risks with high confidence,
+   Docker engineers review the flagged code, reproduce the issue, and decide on
+   the appropriate action. Engineers often contribute fixes back to upstream
+   projects, improving the code for the entire community. When fixes are accepted
+   upstream, the DHI build pipeline applies the patch immediately to protect
+   customers while the fix moves through the upstream release process.
+5. Testing and scanning: Images undergo comprehensive
+   [testing](test.md) for compatibility and functionality, and are
+   [scanned for malware](malware-scanning.md), secrets, and
+   vulnerabilities.
+6. Signing and attestations: Docker signs each image and generates
+   attestations (SBOMs, VEX documents, build provenance).
+7. Publishing: The signed image is published to the DHI registry and the
+   attestations are published to the Docker Scout registry.
+8. Cascade rebuilds: If any customized images use this base, their rebuilds
+   are automatically triggered.
+
+Docker responds quickly to critical vulnerabilities. By building essential
+components from source rather than waiting for packaged updates, Docker can
+patch critical and high severity CVEs within days of upstream fixes and publish
+updated images with new attestations. For DHI Enterprise subscriptions, this
+rapid response is backed by a [7-day SLA for critical and high severity
+vulnerabilities](https://docs.docker.com/go/dhi-sla/).
+
+The following diagram shows the base image build flow:
+
+```goat {class="text-sm"}
+.-------------------.      .-------------------.      .-------------------.      .-------------------.
+| Docker monitors   |----->| Trigger rebuild   |----->| AI guardrail      |----->| Human review      |
+| upstream sources  |      |                   |      | scans changes     |      |                   |
+'-------------------'      '-------------------'      '-------------------'      '-------------------'
+                                                                                           |
+                                                                                           v
+.-------------------.      .-------------------.      .-------------------.      .-------------------.
+| Cascade rebuilds  |<-----| Publish to        |<-----| Sign & generate   |<-----| Testing &         |
+| (if needed)       |      | DHI registry      |      | attestations      |      | scanning          |
+'-------------------'      '-------------------'      '-------------------'      '-------------------'
+```
+
+### Customized image pipeline
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+When you customize a DHI image with DHI Select or DHI Enterprise, the build process is simplified:
+
+1. Monitoring: Docker monitors your OCI artifact repositories for changes.
+2. Rebuild trigger: When you push updates to your OCI artifacts, or when the base
+   DHI image is updated, an automated rebuild starts.
+3. Fetch base image: The latest base DHI image is fetched.
+4. Apply customizations: Your OCI artifacts are applied to the base image.
+5. Scanning: The customized image is [scanned for
+   malware](malware-scanning.md), secrets, and vulnerabilities.
+6. Signing and attestations: Docker signs the customized image and generates
+   attestations (SBOMs, VEX documents, build provenance).
+7. Publishing: The signed customized image is published to Docker Hub and the
+   attestations are published to the Docker Scout registry.
+
+Docker handles the entire process automatically, so you don't need to manage
+builds for your customized images. However, you're responsible for testing your
+customized images and managing any CVEs introduced by your OCI artifacts.
+
+The following diagram shows the customized image build flow:
+
+```goat {class="text-sm"}
+.-------------------.      .-------------------.      .-------------------.      .-------------------.
+| Docker monitors   |----->| Trigger rebuild   |----->| Fetch base        |----->| Apply             |
+| OCI artifacts     |      |                   |      | DHI image         |      | customizations    |
+'-------------------'      '-------------------'      '-------------------'      '-------------------'
+                                                                                           |
+                                                                                           v
+                           .-------------------.      .-------------------.      .-------------------.
+                           | Publish to        |<-----| Sign & generate   |<-----| Scanning          |
+                           | Docker Hub        |      | attestations      |      |                   |
+                           '-------------------'      '-------------------'      '-------------------'
+```
diff --git a/content/manuals/dhi/explore/malware-scanning.md b/content/manuals/dhi/explore/malware-scanning.md
new file mode 100644
index 000000000000..60ab4c1b4743
--- /dev/null
+++ b/content/manuals/dhi/explore/malware-scanning.md
@@ -0,0 +1,94 @@
+---
+title: Malware scanning
+description: Learn how Docker scans Docker Hardened Images for viruses and malware using ClamAV, and how to view and verify the scan attestation.
+keywords: docker hardened images, malware scanning, virus scan, clamav, attestation, image security
+weight: 50
+---
+
+The Docker Hardened Image (DHI) pipeline scans for viruses and malware as part
+of the build process. The scan results are embedded as a signed attestation,
+which you can independently retrieve and verify.
+
+## How it works
+
+Docker uses [ClamAV](https://www.clamav.net/), an open source antivirus engine,
+to scan every layer of each image. The scan runs automatically during the build
+process and checks all files in the image, including files inside archives, for
+known viruses and malware signatures.
+
+The scan results are published as a signed attestation attached to the image.
+The attestation includes the full ClamAV scan report, including the number of
+files scanned, the virus signature database version, and whether any infected
+files were detected.
+
+## View the malware scan attestation
+
+You can retrieve the malware scan attestation using the Docker Scout CLI.
+
+1. Use the `docker scout attest get` command with the virus scan predicate type:
+
+   ```console
+   $ docker scout attest get \
+     --predicate-type https://scout.docker.com/virus/v0.1 \
+     --predicate \
+     dhi.io/<image>:<tag>
+   ```
+
+   > [!NOTE]
+   >
+   > If the image exists locally on your device, you must prefix the image name
+   > with `registry://`. For example, use `registry://dhi.io/python` instead of
+   > `dhi.io/python`.
+
+   For example:
+
+   ```console
+   $ docker scout attest get \
+     --predicate-type https://scout.docker.com/virus/v0.1 \
+     --predicate \
+     dhi.io/python:3.13
+   ```
+
+   The output is a JSON object containing the scanner used and the base64-encoded
+   scan report:
+
+   ```json
+   {
+     "scanner": {
+       "report": "<base64-encoded ClamAV report>",
+       "uri": "clamav/clamav:stable"
+     }
+   }
+   ```
+
+   Decoding the report shows the full ClamAV output, ending with a scan summary:
+
+   ```text
+   ----------- SCAN SUMMARY -----------
+   Known viruses: 3627833
+   Engine version: 1.5.2
+   Scanned directories: 4
+   Scanned files: 21
+   Infected files: 0
+   Data scanned: 44.90 MiB
+   Data read: 23.88 MiB (ratio 1.88:1)
+   Time: 11.473 sec (0 m 11 s)
+   Start Date: 2026:04:12 02:36:19
+   End Date:   2026:04:12 02:36:30
+   ```
+
+2. Verify the attestation signature. To ensure the attestation is authentic and
+   signed by Docker, run:
+
+   ```console
+   $ docker scout attest get \
+     --predicate-type https://scout.docker.com/virus/v0.1 \
+     --verify \
+     dhi.io/<image>:<tag> --platform <platform>
+   ```
+
+   If the attestation is valid, Docker Scout confirms the signature and shows
+   the matching `cosign verify` command.
+
+To view other attestations, such as SBOMs or test results, see [Verify
+an image](../how-to/verify.md).
diff --git a/content/manuals/dhi/explore/responsibility.md b/content/manuals/dhi/explore/responsibility.md
new file mode 100644
index 000000000000..92663ce716cf
--- /dev/null
+++ b/content/manuals/dhi/explore/responsibility.md
@@ -0,0 +1,83 @@
+---
+title: Understanding roles and responsibilities for Docker Hardened Images
+linkTitle: Responsibility overview
+description: Understand the division of responsibilities between Docker, upstream projects, and you when using Docker Hardened Images.
+keywords: software supply chain security, signed sbom, vex document, container provenance, image attestation
+weight: 46
+aliases:
+  - /dhi/about/responsibility/
+---
+
+Docker Hardened Images (DHIs) are curated and maintained by Docker, and built
+using upstream open source components. To deliver security, reliability, and
+compliance, responsibilities are shared among three groups:
+
+- Upstream maintainers: the developers and communities responsible for the
+  open source software included in each image.
+- Docker: the provider of hardened, signed, and maintained container images.
+- You (the customer): the consumer who runs and, optionally, customizes DHIs
+  in your environment.
+
+This topic outlines who handles what, so you can use DHIs effectively and
+securely.
+
+## Releases
+
+- Upstream: Publishes and maintains official releases of the software
+  components included in DHIs. This includes versioning, changelogs, and
+  deprecation notices.
+- Docker: Builds, hardens, and signs Docker Hardened Images based on
+  upstream versions. Docker maintains these images in line with upstream release
+  timelines and internal policies.
+- You: Ensure you're staying on supported versions of DHIs and upstream
+  projects. Using outdated or unsupported components can introduce security
+  risk.
+
+## Patching
+
+- Upstream: Maintains and updates the source code for each component,
+  including fixing vulnerabilities in libraries and dependencies.
+- Docker: Rebuilds and re-releases images with upstream patches applied. Docker
+  monitors for vulnerabilities and publishes updates to affected images. DHI Select
+  and DHI Enterprise include [SLA commitments](https://docs.docker.com/go/dhi-sla/). DHI Community offers a secure baseline but no
+  guaranteed remediation timelines.
+- You: Apply DHI updates in your environments and patch any software or
+  dependencies you install on top of the base image.
+
+## Testing
+
+- Upstream: Defines the behavior and functionality of the original software,
+  and is responsible for validating core features.
+- Docker: Validates that DHIs start, run, and behave consistently with
+  upstream expectations. Docker also runs security scans and includes a [testing
+  attestation](security-concepts/attestations.md) with each image.
+- You: Test your application on top of DHIs and validate that any changes or
+  customizations function as expected in your environment.
+
+## Security and compliance
+
+- Docker: Publishes signed SBOMs, VEX documents, provenance data, and CVE
+  scan results with each image to support compliance and supply chain security.
+  - For DHI Community users: All security metadata and transparency features are
+    included at no cost.
+  - For DHI Select and Enterprise users: Additional compliance variants (like FIPS and
+    STIG) and customization capabilities are available, with automatic rebuilds
+    when base images are patched.
+- You: Integrate DHIs into your security and compliance workflows, including
+  vulnerability management and auditing.
+
+## Support
+
+- Docker:
+  - For DHI Community users: Community support and public documentation are available.
+  - For DHI Select and DHI Enterprise users: Access to Docker's enterprise
+    support team for mission-critical applications.
+- You: Monitor Docker's release notes, security advisories, and documentation
+  for updates and best practices.
+
+## Summary
+
+Docker Hardened Images give you a secure foundation, complete with signed
+metadata and upstream transparency. Your role is to make informed use of these
+images, apply updates promptly, and validate that your configurations and
+applications meet your internal requirements.
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/scanner-integrations.md b/content/manuals/dhi/explore/scanner-integrations.md
new file mode 100644
index 000000000000..a2928ccde516
--- /dev/null
+++ b/content/manuals/dhi/explore/scanner-integrations.md
@@ -0,0 +1,171 @@
+---
+title: Scanner integrations
+description: Learn which vulnerability scanners work with Docker Hardened Images and how to choose the right scanner for accurate vulnerability assessment.
+keywords: scanner integration, vulnerability scanning, docker scout, trivy, grype, wiz, black duck, aikido, aws inspector, container security scanners
+weight: 40
+---
+
+Docker Hardened Images (DHI) work with various vulnerability scanners. However, to get
+accurate results that reflect the actual security posture of these images, your
+scanner needs to understand the VEX (Vulnerability Exploitability eXchange)
+attestations included with each image.
+
+## Scanners with VEX support
+
+The following scanners can read and apply VEX attestations included with Docker
+Hardened Images:
+
+| Scanner | VEX application |
+|---------|-----------------|
+| [Docker Scout](/scout/) | Automatic, zero configuration |
+| [Trivy](https://trivy.dev/) | VEX Hub (recommended) or local VEX file |
+| [Grype](https://github.com/anchore/grype) | Via `--vex` flag with local VEX file |
+| [Wiz](https://docs.wiz.io/) | Automatic, zero configuration |
+| [Mend.io](https://docs.mend.io/platform/latest/docker-hardened-images) | Automatic, zero configuration |
+| [Black Duck](https://documentation.blackduck.com/bundle/bd-hub/page/Reporting/vexReport_global.html) | Automatic, zero configuration |
+| [Aikido](https://help.aikido.dev/container-image-scanning/standalone-registries/docker-hub-images) | Automatic, zero configuration |
+| [AWS Inspector](https://docs.aws.amazon.com/inspector/latest/user/supported.html) | Automatic, zero configuration |
+
+For step-by-step instructions for Docker Scout, Trivy, and Grype, see [Scan Docker Hardened Images](/manuals/dhi/how-to/scan.md). For Wiz, Mend.io, Black Duck, Aikido, and AWS Inspector, refer to their respective documentation.
+
+## Choosing a scanner for Docker Hardened Images
+
+When selecting a scanner for use with Docker Hardened Images, whether it
+supports open standards like OpenVEX is the key differentiator.
+
+Docker Hardened Images include signed VEX attestations that follow the
+[OpenVEX standard](https://openvex.dev/). OpenVEX is an open standard that meets
+the minimum requirements for VEX defined by CISA (Cybersecurity and
+Infrastructure Security Agency), the U.S. government agency responsible for
+cybersecurity guidance. These attestations document which vulnerabilities don't
+apply to the image and why, helping you focus on real risks. To understand what
+VEX is and how it works, see the [VEX core concept](/manuals/dhi/explore/security-concepts/vex.md).
+
+Because OpenVEX is an open standard with government backing, it has strong
+industry momentum and any tool can implement it without vendor-specific
+integrations. This matters when you bring in third-party auditors with their own
+scanning tools, or when you want to use multiple security tools in your
+pipeline. With VEX, these tools can all read and verify the same vulnerability
+data directly from your images.
+
+Without open standards like VEX, vendors make exploitability decisions using
+proprietary methods, making it difficult to verify claims or compare results
+across tools. This fragments your security toolchain and creates inconsistent
+vulnerability assessments across different scanning tools.
+
+### Benefits of scanners with VEX support
+
+Scanners that support open standards like OpenVEX and can interpret VEX attestations
+from Docker Hardened Images offer the following benefits:
+
+- Accurate vulnerability counts: Automatically filter out vulnerabilities
+  that don't apply to your specific image, often reducing false positives
+  dramatically.
+- Transparency and auditability: Verify exactly why vulnerabilities are or
+  aren't flagged; security teams and compliance officers can review the reasoning
+  rather than trusting a vendor's black box.
+- Scanner flexibility: Switch between any VEX-enabled scanner (Docker Scout,
+  Trivy, Grype, etc.) without losing vulnerability context or rebuilding exclusion lists.
+- Consistent results: VEX-enabled scanners interpret the same data the
+  same way, eliminating discrepancies between tools.
+- Faster workflows: Focus on real risks rather than researching why reported
+  CVEs don't actually affect your deployment.
+
+### Scanners without VEX support
+
+Scanners that can't read VEX attestations will report vulnerabilities that don't
+apply to Docker Hardened Images. This creates operational challenges:
+
+- Manual filtering required: You'll need to maintain scanner-specific ignore
+  lists to replicate what VEX statements already document.
+- Higher false positive rates: Expect to see more reported vulnerabilities
+  that don't represent real risks.
+- Increased investigation time: Security teams spend time researching why
+  CVEs don't apply instead of addressing actual vulnerabilities. With Docker
+  Hardened Images, security experts at Docker manage this investigation for
+  you, thoroughly vetting each justification before adding it to a VEX statement.
+- CI/CD friction: Build pipelines may fail on vulnerabilities that aren't
+  exploitable in your images.
+
+### VEX-based vulnerability handling versus proprietary approaches
+
+Docker Hardened Images use VEX attestations based on the OpenVEX open standard to document vulnerability exploitability. OpenVEX is an open standard that is recognized by government agencies such as CISA. This open standards approach differs from how some other image vendors handle vulnerabilities using proprietary methods.
+
+#### Docker Hardened Images with VEX
+
+The image includes signed attestations that explain which vulnerabilities don't
+apply and why. Any VEX-enabled scanner can read these attestations, giving you:
+
+- Tool flexibility: Use any scanner that supports OpenVEX (Docker Scout,
+  Trivy, Grype, etc.)
+- Complete transparency: Review the exact reasoning for each vulnerability
+  assessment
+- Full auditability: Security teams and compliance officers can independently
+  verify all vulnerability assessments and reasoning
+- Historical visibility: VEX statements remain with the image, so you can
+  always check vulnerability status, even for older versions
+
+#### Proprietary vulnerability handling
+
+Some image vendors use proprietary advisory feeds or internal databases instead
+of VEX. While this may result in fewer reported vulnerabilities, it creates
+significant limitations:
+
+- Tool dependency: You must use the vendor's preferred scanning tools to see
+  their vulnerability filtering, while standard scanners will still report all
+  CVEs; scanners must implement proprietary feeds rather than using open
+  standards that work with all images
+- No transparency: Proprietary feeds act as "black boxes" - vulnerabilities
+  simply disappear from vendor tools with no explanation
+- Limited verifiability: Security teams have no way to independently verify
+  why vulnerabilities are excluded or whether the reasoning is sound
+- Maintenance challenges: If you scan older image versions with standard
+  tools, you can't determine which vulnerabilities actually applied at that
+  time, making long-term security tracking difficult
+- Ecosystem incompatibility: Your existing security tools (SCA, policy
+  engines, compliance scanners) can't access or verify the vendor's proprietary
+  vulnerability data
+
+The fundamental difference: VEX-based approaches explain vulnerability
+assessments using open standards that any tool can verify and audit. Proprietary
+approaches hide vulnerabilities in vendor-specific systems where the reasoning
+can't be independently validated.
+
+For Docker Hardened Images, use VEX-enabled scanners to get accurate results
+that work across your entire security toolchain.
+
+## What to expect from different scanners
+
+When scanning Docker Hardened Images with different tools, you'll see
+significant differences in reported vulnerability counts.
+
+### What VEX-enabled scanners filter automatically
+
+When you scan Docker Hardened Images with VEX-enabled scanners, they
+automatically exclude vulnerabilities that don't apply:
+
+- Hardware-specific vulnerabilities: Issues that only affect specific
+  hardware architectures (for example, Power10 processors) that are irrelevant to
+  containerized workloads.
+- Unreachable code paths: CVEs in code that exists in the package but isn't
+  executed in the image's runtime configuration.
+- Build-time only issues: Vulnerabilities in build tools or dependencies
+  that don't exist in the final runtime image.
+- Temporary identifiers: Placeholder vulnerability IDs (like Debian's
+  `TEMP-xxxxxxx`) that aren't intended for external tracking.
+
+### Using scanners without VEX support
+
+If your scanner doesn't support VEX, you'll need to manually exclude
+vulnerabilities through scanner-specific mechanisms like ignore lists or policy
+exceptions. This requires:
+
+- Reviewing VEX statements from Docker Hardened Images
+- Translating VEX justifications into your scanner's format
+- Maintaining these exclusions as new vulnerabilities are discovered
+- Repeating this process if you switch scanners or add additional scanning tools
+
+## What's next
+
+Learn how to [scan Docker Hardened Images](/manuals/dhi/how-to/scan.md) with
+VEX-compliant scanners.
diff --git a/content/manuals/dhi/explore/security-concepts/_index.md b/content/manuals/dhi/explore/security-concepts/_index.md
new file mode 100644
index 000000000000..03b7c1e1c6bd
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/_index.md
@@ -0,0 +1,115 @@
+---
+aliases:
+  - /dhi/core-concepts/
+title: Security concepts
+linkTitle: Security concepts
+description: Learn the core concepts behind Docker Hardened Images, including security metadata, vulnerability management, image structure, and verification.
+weight: 60
+params:
+  grid_concepts_metadata:
+    - title: Attestations
+      description: Review the full set of signed attestations included with each Docker Hardened Image, such as SBOMs, VEX, build provenance, and scan results.
+      icon: clipboard-document-list
+      link: /dhi/explore/security-concepts/attestations/
+    - title: Software Bill of Materials (SBOMs)
+      description: Learn what SBOMs are, why they matter, and how Docker Hardened Images include signed SBOMs to support transparency and compliance.
+      icon: list-bullet
+      link: /dhi/explore/security-concepts/sbom/
+    - title: Supply-chain Levels for Software Artifacts (SLSA)
+      description: Learn how Docker Hardened Images comply with SLSA Build Level 3 and how to verify provenance for secure, tamper-resistant builds.
+      icon: clipboard-document-check
+      link: /dhi/explore/security-concepts/slsa/
+    - title: Image provenance
+      description: Learn how build provenance metadata helps trace the origin of Docker Hardened Images and support compliance with SLSA.
+      icon: pencil-square
+      link: /dhi/explore/security-concepts/provenance/
+
+  grid_concepts_compliance:
+    - title: FIPS
+      description: Learn how Docker Hardened Images support FIPS 140 by using validated cryptographic modules and providing signed attestations for compliance audits.
+      icon: check-badge
+      link: /dhi/explore/security-concepts/fips/
+    - title: STIG
+      description: Learn how Docker Hardened Images provide STIG-ready container images with verifiable security scan attestations for government and enterprise compliance requirements.
+      icon: shield-check
+      link: /dhi/explore/security-concepts/stig/
+    - title: CIS Benchmarks
+      description: Learn how Docker Hardened Images help you meet Center for Internet Security (CIS) Docker Benchmark requirements for secure container configuration and deployment.
+      icon: check-circle
+      link: /dhi/explore/security-concepts/cis/
+
+  grid_concepts_risk:
+    - title: Common Vulnerabilities and Exposures (CVEs)
+      description: Understand what CVEs are, how Docker Hardened Images reduce exposure, and how to scan images for vulnerabilities using popular tools.
+      icon: exclamation-circle
+      link: /dhi/explore/security-concepts/cves/
+    - title: Vulnerability Exploitability eXchange (VEX)
+      description: Learn how VEX helps you prioritize real risks by identifying which vulnerabilities in Docker Hardened Images are actually exploitable.
+      icon: exclamation-triangle
+      link: /dhi/explore/security-concepts/vex/
+    - title: Software Supply Chain Security
+      description: Learn how Docker Hardened Images help secure every stage of your software supply chain with signed metadata, provenance, and minimal attack surface.
+      icon: shield-check
+      link: /dhi/explore/security-concepts/sscs/
+    - title: Secure Software Development Lifecycle (SSDLC)
+      description: See how Docker Hardened Images support a secure SDLC by integrating with scanning, signing, and debugging tools.
+      icon: wrench-screwdriver
+      link: /dhi/explore/security-concepts/ssdlc/
+
+  grid_concepts_structure:
+    - title: Distroless images
+      description: Learn how Docker Hardened Images use distroless variants to minimize attack surface and remove unnecessary components.
+      icon: squares-2x2
+      link: /dhi/explore/security-concepts/distroless/
+    - title: glibc and musl support in Docker Hardened Images
+      description: Compare glibc and musl variants of DHIs to choose the right base image for your application’s compatibility, size, and performance needs.
+      icon: arrows-up-down
+      link: /dhi/explore/security-concepts/glibc-musl/
+    - title: Image immutability
+      description: Understand how image digests, read-only containers, and signed metadata ensure Docker Hardened Images are tamper-resistant and immutable.
+      icon: minus-circle
+      link: /dhi/explore/security-concepts/immutability/
+    - title: Image hardening
+      description: Learn how Docker Hardened Images are designed for security, with minimal components, nonroot execution, and secure-by-default configurations.
+      icon: shield-check
+      link: /dhi/explore/security-concepts/hardening/
+
+  grid_concepts_verification:
+    - title: Digests
+      description: Learn how to use immutable image digests to guarantee consistency and verify the exact Docker Hardened Image you're running.
+      icon: finger-print
+      link: /dhi/explore/security-concepts/digests/
+    - title: Code signing
+      description: Understand how Docker Hardened Images are cryptographically signed using Cosign to verify authenticity, integrity, and secure provenance.
+      icon: key
+      link: /dhi/explore/security-concepts/signatures/
+---
+
+Docker Hardened Images (DHIs) are built on a foundation of secure software
+supply chain practices. This section explains the core concepts behind that
+foundation, from signed attestations and immutable digests to standards like SLSA
+and VEX.
+
+Start here if you want to understand how Docker Hardened Images support compliance,
+transparency, and security.
+
+
+## Security metadata and attestations
+
+{{< grid items="grid_concepts_metadata" >}}
+
+## Compliance standards
+
+{{< grid items="grid_concepts_compliance" >}}
+
+## Vulnerability and risk management
+
+{{< grid items="grid_concepts_risk" >}}
+
+## Image structure and behavior
+
+{{< grid items="grid_concepts_structure" >}}
+
+## Verification and traceability
+
+{{< grid items="grid_concepts_verification" >}}
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/attestations.md b/content/manuals/dhi/explore/security-concepts/attestations.md
new file mode 100644
index 000000000000..4686424631be
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/attestations.md
@@ -0,0 +1,160 @@
+---
+aliases:
+  - /dhi/core-concepts/attestations/
+title: Attestations
+description: Review the full set of signed attestations included with each Docker Hardened Image, such as SBOMs, VEX, build provenance, and scan results.
+keywords: container image attestations, signed sbom, build provenance, slsa compliance, vex document
+---
+
+Docker Hardened Images (DHIs) and charts include comprehensive, signed security
+attestations that verify the image's build process, contents, and security
+posture. These attestations are a core part of secure software supply chain
+practices and help users validate that an image is trustworthy and
+policy-compliant.
+
+## What is an attestation?
+
+An attestation is a signed statement that provides verifiable information
+about an image or chart, such as how it was built, what's inside it, and what security
+checks it has passed. Attestations are typically signed using Sigstore tooling
+(such as Cosign), making them tamper-evident and cryptographically verifiable.
+
+Attestations follow standardized formats (like [in-toto](https://in-toto.io/),
+[CycloneDX](https://cyclonedx.org/), and [SLSA](https://slsa.dev/)) and are
+attached to the image or chart as OCI-compliant metadata. They can be generated
+automatically during image builds or added manually to document extra tests,
+scan results, or custom provenance.
+
+## Why are attestations important?
+
+Attestations provide critical visibility into the software supply chain by:
+
+- Documenting *what* went into an image (e.g., SBOMs)
+- Verifying *how* it was built (e.g., build provenance)
+- Capturing *what security scans* it has passed or failed (e.g., CVE reports,
+  secrets scans, test results)
+- Helping organizations enforce compliance and security policies
+- Supporting runtime trust decisions and CI/CD policy gates
+
+They are essential for meeting industry standards such as SLSA,
+and help teams reduce the risk of supply chain attacks by making build and
+security data transparent and verifiable.
+
+## How Docker Hardened Images and charts use attestations
+
+All DHIs and charts are built using [SLSA Build Level
+3](https://slsa.dev/spec/latest/levels) practices, and each image variant is
+published with a full set of signed attestations. These attestations allow users
+to:
+
+- Verify that the image or chart was built from trusted sources in a secure environment
+- View SBOMs in multiple formats to understand component-level details
+- Review scan results to check for vulnerabilities or embedded secrets
+- Confirm the build and deployment history of each image
+
+Attestations are automatically published and associated with each  DHI
+and chart. They can be inspected using tools like [Docker
+Scout](../../how-to/verify.md) or
+[Cosign](https://docs.sigstore.dev/cosign/overview), and are consumable by CI/CD
+tooling or security platforms.
+
+## Image attestations
+
+While every DHI variant includes a set of attestations, the attestations may
+vary based on the image variant. For example, some images may include a STIG
+scan attestation. The following table lists attestations that may be included with a DHI; the
+actual set varies by image variant. To see which attestations are available
+for a specific image variant, including the specific predicate type URIs, use
+Docker Scout:
+
+```console
+$ docker scout attest list dhi.io/<image>:<tag>
+```
+
+For more details, see [Verify image attestations](../../how-to/verify.md#verify-image-attestations).
+
+| Attestation type           | Description                                                                                                                                                                                                                     |
+|----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| CycloneDX SBOM             | A software bill of materials in [CycloneDX](https://cyclonedx.org/) format, listing components, libraries, and versions.                                                                                                      |
+| STIG scan                  | Results of a STIG scan, with output in HTML and XCCDF formats.                                                                                                                           |
+| CVEs (In-Toto format)      | A list of known vulnerabilities (CVEs) affecting the image's components, based on package and distribution scanning.                                                                           |
+| VEX                        | A [Vulnerability Exploitability eXchange (VEX)](https://openvex.dev/) document that identifies vulnerabilities that do not apply to the image and explains why (e.g., not reachable or not present).                         |
+| Scout provenance           | Provenance metadata generated by Docker Scout, including the source Git commit, build parameters, and environment details.                                                               |
+| Scout SBOM                 | An SBOM generated and signed by Docker Scout, including additional Docker-specific metadata.                                                                                             |
+| Secrets scan               | Results of a scan for accidentally included secrets, such as credentials, tokens, or private keys.                                                                                       |
+| Tests                      | A record of automated tests run against the image, such as functional checks or validation scripts.                                                                                      |
+| Virus scan                 | Results of antivirus scans performed on the image layers. For details, see [Malware scanning](../malware-scanning.md).                                                            |
+| CVEs (Scout format)        | A vulnerability report generated by Docker Scout, listing known CVEs and severity data.                                                                                                  |
+| SLSA provenance            | A standard [SLSA](https://slsa.dev/) provenance statement describing how the image was built, including build tool, parameters, and source.                                               |
+| SLSA verification summary  | A summary attestation indicating the image's compliance with SLSA requirements.                                                                                                          |
+| SPDX SBOM                  | An SBOM in [SPDX](https://spdx.dev/) format, widely adopted in open-source ecosystems.                                                                                                   |
+| FIPS compliance            | An attestation that verifies the image uses FIPS 140-validated cryptographic modules.                              |
+| DHI Changelog              | A record of changes made to the image across versions. |
+| DHI Image Sources          | Links to a corresponding source image containing all materials used to build the image, including package source code, Git repositories, and local files, ensuring compliance with open source license requirements. |
+
+## Package attestations
+
+In addition to image-level attestations, Docker hardened packages also include
+their own attestations. These package-level attestations provide provenance and
+build information for individual packages within an image, allowing you to
+trace the supply chain at a granular level.
+
+Package attestations include similar information as image attestations, such as
+SLSA provenance, showing how each package was built and what materials were
+used. You can extract package information from an image's attestations and then
+retrieve the package's own attestations recursively.
+
+For detailed instructions on how to access and verify package attestations, see
+[Package attestations](../../how-to/hardened-packages.md#package-attestations).
+
+## Helm chart attestations
+
+Docker Hardened Image (DHI) charts also include comprehensive signed attestations
+that provide transparency and verification for your Kubernetes deployments. Like
+DHI container images, these charts are built following SLSA Build Level 3
+practices and include extensive security metadata.
+
+DHI Helm charts include the following attestations. To view the specific predicate
+type URIs for these attestations, use Docker Scout:
+
+```console
+$ docker scout attest list dhi.io/<chart>:<version>
+```
+
+For more details, see [Verify Helm chart attestations](../../how-to/verify.md#verify-helm-chart-attestations-with-docker-scout).
+
+| Attestation type           | Description                                                                                                                                                                                                                     |
+|----------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| CycloneDX SBOM             | A software bill of materials in [CycloneDX](https://cyclonedx.org/) format, listing the chart itself and all container images and tools referenced by the chart.                                                              |
+| CVEs (In-Toto format)      | A list of known vulnerabilities (CVEs) affecting the container images and components referenced by the chart.                                                                                                                   |
+| Scout provenance           | Provenance metadata generated by Docker Scout, including the chart source repository, build images used, and build parameters.                                                                                                  |
+| Scout SBOM                 | An SBOM generated and signed by Docker Scout, including the chart and container images it references, with additional Docker-specific metadata.                                                                                |
+| Secrets scan               | Results of a scan for accidentally included secrets, such as credentials, tokens, or private keys, in the chart package.                                                                                                       |
+| Tests                      | A record of automated tests run against the chart to validate functionality and compatibility with referenced images.                                                                                                          |
+| Virus scan                 | Results of antivirus scans performed on the chart package. For details, see [Malware scanning](../malware-scanning.md).                                                                                                |
+| CVEs (Scout format)        | A vulnerability report generated by Docker Scout, listing known CVEs and severity data for the chart's referenced images.                                                                                                      |
+| SLSA provenance            | A standard [SLSA](https://slsa.dev/) provenance statement describing how the chart was built, including build tool, source repository, referenced images, and build materials.                                                 |
+| SPDX SBOM                  | An SBOM in [SPDX](https://spdx.dev/) format, listing the chart and all container images and tools it references.                                                                                                              |
+
+## View and verify attestations
+
+To view and verify attestations, see [Verify a Docker Hardened
+Image](../../how-to/verify.md).
+
+## Add your own attestations
+
+In addition to the comprehensive attestations provided by Docker Hardened
+Images, you can add your own signed attestations when building derivative
+images. This is especially useful if you’re building new applications on top of
+a DHI and want to maintain transparency, traceability, and trust in your
+software supply chain.
+
+By attaching attestations such as SBOMs, build provenance, or custom metadata,
+you can meet compliance requirements, pass security audits, and support policy
+evaluation tools like Docker Scout.
+
+These attestations can then be verified downstream using tools
+like Cosign or Docker Scout.
+
+To learn how to attach custom attestations during the build process, see [Build
+attestations](/manuals/build/metadata/attestations.md).
diff --git a/content/manuals/dhi/explore/security-concepts/cis.md b/content/manuals/dhi/explore/security-concepts/cis.md
new file mode 100644
index 000000000000..a4aa644c4aa4
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/cis.md
@@ -0,0 +1,57 @@
+---
+aliases:
+  - /dhi/core-concepts/cis/
+title: CIS Benchmark
+description: Learn how Docker Hardened Images comply with the CIS Docker Benchmark to help organizations harden container images for secure deployments.
+keywords: docker cis benchmark, cis docker compliance, cis docker images, docker hardened images, secure container images
+---
+
+## What is the CIS Docker Benchmark?
+
+The [CIS Docker Benchmark](https://www.cisecurity.org/benchmark/docker) is part
+of the globally recognized CIS Benchmarks, developed by the [Center for
+Internet Security (CIS)](https://www.cisecurity.org/). It defines recommended secure
+configurations for all aspects of the Docker container ecosystem, including the
+container host, Docker daemon, container images, and the container runtime.
+
+## Why CIS Benchmark compliance matters
+
+Following the CIS Docker Benchmark helps organizations:
+
+- Reduce security risk with widely recognized hardening guidance.
+- Meet regulatory or contractual requirements that reference CIS controls.
+- Standardize image and Dockerfile practices across teams.
+- Demonstrate audit readiness with configuration decisions grounded in a public standard.
+
+## How Docker Hardened Images comply with the CIS Benchmark
+
+Docker Hardened Images (DHIs) are designed with security in mind and are
+verified to be compliant with the relevant controls from the CIS Docker
+Benchmark for the scope that applies to container images and Dockerfile
+configuration.
+
+CIS-compliant DHIs are compliant with all controls in Section 4, with the sole
+exception of the control requiring Docker Content Trust (DCT), which [Docker
+officially retired](https://www.docker.com/blog/retiring-docker-content-trust/).
+Instead, DHIs are [signed](/manuals/dhi/explore/security-concepts/signatures.md) using
+Cosign, providing an even higher level of authenticity and integrity. By
+starting from a CIS-compliant DHI, teams can adopt image-level best practices
+from the benchmark more quickly and confidently.
+
+> [!NOTE]
+>
+> The CIS Docker Benchmark also includes controls for the host, daemon, and
+> runtime. CIS-compliant DHIs address only the image and Dockerfile scope (Section
+> 4). Overall compliance still depends on how you configure and operate the
+> broader environment.
+
+## Identify CIS-compliant images
+
+CIS-compliant images are labeled as **CIS** in the Docker Hardened Images catalog.
+To find them, [search the catalog](../../how-to/search-evaluate.md) and look for the **CIS**
+designation on individual listings.
+
+## Get the benchmark
+
+Download the latest CIS Docker Benchmark directly from CIS:
+https://www.cisecurity.org/benchmark/docker
diff --git a/content/manuals/dhi/explore/security-concepts/cves.md b/content/manuals/dhi/explore/security-concepts/cves.md
new file mode 100644
index 000000000000..1d7f0576a22e
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/cves.md
@@ -0,0 +1,175 @@
+---
+aliases:
+  - /dhi/core-concepts/cves/
+title: Common Vulnerabilities and Exposures (CVEs)
+linktitle: CVEs
+description: Understand what CVEs are, how Docker Hardened Images reduce exposure, and how to scan images for vulnerabilities using popular tools.
+keywords: docker cve scan, grype vulnerability scanner, trivy image scan, vex attestation, secure container images
+---
+
+## What are CVEs?
+
+CVEs are publicly disclosed cybersecurity flaws in software or hardware. Each
+CVE is assigned a unique identifier (e.g., CVE-2024-12345) and includes a
+standardized description, allowing organizations to track and address
+vulnerabilities consistently.
+
+In the context of Docker, CVEs often pertain to issues within base images, or
+application dependencies. These vulnerabilities can range from minor bugs to
+critical security risks, such as remote code execution or privilege escalation.
+
+## Why are CVEs important?
+
+Regularly scanning and updating Docker images to mitigate CVEs is crucial for
+maintaining a secure and compliant environment. Ignoring CVEs can lead to severe
+security breaches, including:
+
+- Unauthorized access: Exploits can grant attackers unauthorized access to
+  systems.
+- Data breaches: Sensitive information can be exposed or stolen.
+- Service disruptions: Vulnerabilities can be leveraged to disrupt services or
+  cause downtime.
+- Compliance violations: Failure to address known vulnerabilities can lead to
+  non-compliance with industry regulations and standards.
+
+## How Docker Hardened Images help mitigate CVEs
+
+Docker Hardened Images (DHIs) are crafted to minimize the risk of CVEs from the
+outset. By adopting a security-first approach, DHIs offer several advantages in
+CVE mitigation:
+
+- Reduced attack surface: DHIs are built using a distroless approach, stripping
+  away unnecessary components and packages. This reduction in image size, up to
+  95% smaller than traditional images, limits the number of potential
+  vulnerabilities, making it harder for attackers to exploit unneeded software.
+
+- Faster CVE remediation: Maintained by Docker with an [enterprise-grade SLA](https://docs.docker.com/go/dhi-sla/),
+  DHIs are continuously updated to address known vulnerabilities. Critical and
+  high-severity CVEs are patched quickly, ensuring that your containers remain
+  secure without manual intervention.
+
+- Proactive vulnerability management: By utilizing DHIs, organizations can
+  proactively manage vulnerabilities. The images come with CVE and Vulnerability
+  Exposure (VEX) feeds, enabling teams to stay informed about potential threats
+  and take necessary actions promptly.
+
+## Scan images for CVEs
+
+Regularly scanning Docker images for CVEs is essential for maintaining a secure
+containerized environment. While Docker Scout is integrated into Docker Desktop
+and the Docker CLI, tools like Grype and Trivy offer alternative scanning
+capabilities. The following are instructions for using each tool to scan Docker
+images for CVEs.
+
+### Docker Scout
+
+Docker Scout is integrated into Docker Desktop and the Docker CLI. It provides
+vulnerability insights, CVE summaries, and direct links to remediation guidance.
+
+#### Scan a DHI using Docker Scout
+
+To scan a Docker Hardened Image using Docker Scout, run the following
+command:
+
+```console
+$ docker scout cves dhi.io/<image>:<tag> --platform <platform>
+```
+
+Example output:
+
+```plaintext
+    v SBOM obtained from attestation, 101 packages found
+    v Provenance obtained from attestation
+    v VEX statements obtained from attestation
+    v No vulnerable package detected
+    ...
+```
+
+For more detailed filtering and JSON output, see [Docker Scout CLI reference](/reference/cli/docker/scout/).
+
+### Grype
+
+[Grype](https://github.com/anchore/grype) is an open-source scanner that checks
+container images against vulnerability databases like the NVD and distro
+advisories.
+
+#### Scan a DHI using Grype
+
+After installing Grype, you can scan a Docker Hardened Image by pulling
+the image and running the scan command. Grype requires you to export the VEX
+attestation to a file first:
+
+```console
+$ docker pull dhi.io/<image>:<tag>
+$ docker scout vex get dhi.io/<image>:<tag> --output vex.json
+$ grype dhi.io/<image>:<tag> --vex vex.json
+```
+
+Example output:
+
+```plaintext
+NAME               INSTALLED              FIXED-IN     TYPE  VULNERABILITY     SEVERITY    EPSS%  RISK
+libperl5.36        5.36.0-7+deb12u2       (won't fix)  deb   CVE-2023-31484    High        79.45    1.1
+perl               5.36.0-7+deb12u2       (won't fix)  deb   CVE-2023-31484    High        79.45    1.1
+perl-base          5.36.0-7+deb12u2       (won't fix)  deb   CVE-2023-31484    High        79.45    1.1
+...
+```
+
+### Trivy
+
+[Trivy](https://github.com/aquasecurity/trivy) is an open-source vulnerability
+scanner for containers and other artifacts. It detects vulnerabilities in OS
+packages and application dependencies.
+
+#### Scan a DHI using Trivy
+
+After installing Trivy, you can scan a Docker Hardened Image by pulling
+the image and running the scan command:
+
+```console
+$ docker pull dhi.io/<image>:<tag>
+$ trivy image --scanners vuln --vex repo dhi.io/<image>:<tag>
+```
+
+Example output:
+
+```plaintext
+Report Summary
+
+┌──────────────────────────────────────────────────────────────────────────────┬────────────┬─────────────────┬─────────┐
+│                                    Target                                    │    Type    │ Vulnerabilities │ Secrets │
+├──────────────────────────────────────────────────────────────────────────────┼────────────┼─────────────────┼─────────┤
+│ dhi.io/<image>:<tag> (debian 12.11)                                          │   debian   │       66        │    -    │
+├──────────────────────────────────────────────────────────────────────────────┼────────────┼─────────────────┼─────────┤
+│ opt/python-3.13.4/lib/python3.13/site-packages/pip-25.1.1.dist-info/METADATA │ python-pkg │        0        │    -    │
+└──────────────────────────────────────────────────────────────────────────────┴────────────┴─────────────────┴─────────┘
+```
+
+## Use VEX to filter known non-exploitable CVEs
+
+Docker Hardened Images include signed [VEX (Vulnerability Exploitability
+eXchange)](./vex.md) attestations that identify vulnerabilities not relevant to the image’s
+runtime behavior.
+
+When using Docker Scout or Trivy, these VEX statements are automatically
+applied using the previous examples, and no manual configuration needed.
+
+To manually retrieve the VEX attestation for tools that support it:
+
+```console
+$ docker scout vex get dhi.io/<image>:<tag> --output vex.json
+```
+
+> [!NOTE]
+>
+> If the image exists locally on your device, you must prefix the image name with `registry://`. For example, use
+> `registry://dhi.io/python:3.13` instead of `dhi.io/python:3.13`.
+
+For example:
+
+```console
+$ docker scout vex get dhi.io/python:3.13 --output vex.json
+```
+
+This creates a `vex.json` file containing the VEX statements for the specified
+image. You can then use this file with tools that support VEX to filter out known non-exploitable CVEs.
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/digests.md b/content/manuals/dhi/explore/security-concepts/digests.md
new file mode 100644
index 000000000000..fe31aafd7c28
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/digests.md
@@ -0,0 +1,128 @@
+---
+aliases:
+  - /dhi/core-concepts/digests/
+title: Image digests
+description: Learn how Docker Hardened Images help secure every stage of your software supply chain with signed metadata, provenance, and minimal attack surface.
+keywords: docker image digest, pull image by digest, immutable container image, secure container reference, multi-platform manifest
+---
+
+## What are Docker image digests?
+
+A Docker image digest is a unique, cryptographic identifier (SHA-256 hash)
+representing the content of a Docker image. Unlike tags, which can be reused or
+changed, a digest is immutable and ensures that the exact same image is pulled
+every time. This guarantees consistency across different environments and
+deployments.
+
+For example, the digest for the `nginx:latest` image might look like:
+
+```text
+sha256:94a00394bc5a8ef503fb59db0a7d0ae9e1110866e8aee8ba40cd864cea69ea1a
+```
+
+This digest uniquely identifies the specific version of the `nginx:latest` image,
+ensuring that any changes to the image content result in a different digest.
+
+## Why are image digests important?
+
+Using image digests instead of tags offers several advantages:
+
+- Immutability: Once an image is built and its digest is generated, the content
+  tied to that digest cannot change. This means that if you pull an image using
+  its digest, you can be confident that you are retrieving exactly the same
+  image that was originally built.
+
+- Security: Digests help prevent supply chain attacks by ensuring that the image
+  content has not been tampered with. Even a small change in the image content
+  will result in a completely different digest.
+
+- Consistency: Using digests ensures that the same image is used across
+  different environments, reducing the risk of discrepancies between
+  development, staging, and production environments.
+
+## Docker Hardened Image digests
+
+By using image digests to reference DHIs, you can ensure that your applications are
+always using the exact same secure image version, enhancing security and
+compliance
+
+## View an image digest
+
+### Use the Docker CLI
+
+To view the image digest of a Docker image, you can use the following command. Replace
+`<image-name>:<tag>` with the image name and tag.
+
+```console
+$ docker buildx imagetools inspect <image-name>:<tag>
+```
+
+### Use the Docker Hub UI
+
+1. Go to [Docker Hub](https://hub.docker.com/) and sign in.
+2. Navigate to your organization's namespace and open the mirrored DHI repository.
+3. Select the **Tags** tab to view image variants.
+4. Each tag in the list includes a **Digest** field showing the image's SHA-256 value.
+
+## Pull an image by digest
+
+Pulling an image by digest ensures that you are pulling the exact image version
+identified by the specified digest.
+
+To pull a Docker image using its digest, use the following command. Replace
+`<image-name>` with the image name and `<digest>` with the image digest.
+
+```console
+$ docker pull <image-name>@sha256:<digest>
+```
+
+For example, to pull a `docs/dhi-python:3.13` image using its digest of
+`94a00394bc5a8ef503fb59db0a7d0ae9e1110866e8aee8ba40cd864cea69ea1a`, you would
+run:
+
+```console
+$ docker pull docs/dhi-python@sha256:94a00394bc5a8ef503fb59db0a7d0ae9e1110866e8aee8ba40cd864cea69ea1a
+```
+
+## Multi-platform images and manifests
+
+Docker Hardened Images are published as multi-platform images, which means
+a single image tag (like `docs/dhi-python:3.13`) can support multiple operating
+systems and CPU architectures, such as `linux/amd64`, `linux/arm64`, and more.
+
+Instead of pointing to a single image, a multi-platform tag points to a manifest
+list (also called an index), which is a higher-level object that references
+multiple image digests, one for each supported platform.
+
+When you inspect a multi-platform image using `docker buildx imagetools inspect`, you'll see something like this:
+
+```text
+Name:      docs/dhi-python:3.13
+MediaType: application/vnd.docker.distribution.manifest.list.v2+json
+Digest:    sha256:6e05...d231
+
+Manifests:
+  Name:        docs/dhi-python:3.13@sha256:94a0...ea1a
+  Platform:    linux/amd64
+  ...
+
+  Name:        docs/dhi-python:3.13@sha256:7f1d...bc43
+  Platform:    linux/arm64
+  ...
+```
+
+- The manifest list digest (`sha256:6e05...d231`) identifies the overall
+  multi-platform image.
+- Each platform-specific image has its own digest (e.g., `sha256:94a0...ea1a`
+  for `linux/amd64`).
+
+### Why this matters
+
+- Reproducibility: If you're building or running containers on different
+  architectures, using a tag alone will resolve to the appropriate image digest
+  for your platform.
+- Verification: You can pull and verify a specific image digest for your
+  platform to ensure you're using the exact image version, not just the manifest
+  list.
+- Policy enforcement: When enforcing digest-based policies with Docker Scout,
+  each platform variant is evaluated individually using its digest.
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/distroless.md b/content/manuals/dhi/explore/security-concepts/distroless.md
new file mode 100644
index 000000000000..e886b5e6e388
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/distroless.md
@@ -0,0 +1,75 @@
+---
+aliases:
+  - /dhi/core-concepts/distroless/
+title: Minimal or distroless images
+linktitle: Distroless images
+description: Learn how Docker Hardened Images use distroless variants to minimize attack surface and remove unnecessary components.
+keywords: distroless container image, minimal docker image, secure base image, no shell container, reduced attack surface
+---
+
+
+Minimal images, sometimes called distroless images, are container images
+stripped of unnecessary components such as package managers, shells, or even the
+underlying operating system distribution. Docker Hardened Images (DHI) embrace
+this minimal approach to reduce vulnerabilities and enforce secure software
+delivery. [Docker Official
+Images](../../../docker-hub/image-library/trusted-content.md#docker-official-images)
+and [Docker Verified Publisher
+Images](../../../docker-hub/image-library/trusted-content.md#verified-publisher-images)
+follow similar best practices for minimalism and security but may not be as
+stripped down to ensure compatibility with a wider range of use cases.
+
+## What are minimal or distroless images?
+
+Traditional container images include a full OS, often more than what is needed
+to run an application. In contrast, minimal or distroless images include only:
+
+- The application binary
+- Its runtime dependencies (e.g., libc, Java, Python)
+- Any explicitly required configuration or metadata
+
+They typically exclude:
+
+- OS tools (e.g., `ls`, `ps`, `cat`)
+- Shells (e.g., `sh`, `bash`)
+- Package managers (e.g., `apt`, `apk`)
+- Debugging utilities (e.g., `curl`, `wget`, `strace`)
+
+Docker Hardened Images are based on this model, ensuring a smaller and more
+secure runtime surface.
+
+## What you gain
+
+| Benefit                | Description                                                                   |
+|------------------------|-------------------------------------------------------------------------------|
+| Smaller attack surface | Fewer components mean fewer vulnerabilities and less exposure to CVEs         |
+| Faster startup         | Smaller image sizes result in faster pull and start times                     |
+| Improved security      | Lack of shell and package manager limits what attackers can do if compromised |
+| Better compliance      | Easier to audit and verify, especially with SBOMs and attestations            |
+
+## Addressing common tradeoffs
+
+Minimal and distroless images offer strong security benefits, but they can
+change how you work with containers. Docker Hardened Images are designed to
+maintain productivity while enhancing security.
+
+| Concern           | How Docker Hardened Images help                                                                                                                                                                                         |
+|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Debuggability | Hardened images exclude shells and CLI tools by default. Use [Docker Debug](/reference/cli/docker/debug/) to temporarily attach a debug sidecar for troubleshooting without modifying the original container. |
+| Familiarity   | DHI supports multiple base images, including Alpine and Debian variants, so you can choose a familiar environment while still benefiting from hardening practices.                                                        |
+| Flexibility   | Runtime immutability helps secure your containers. Use multi-stage builds and CI/CD to control changes, and optionally use dev-focused base images during development.                                                  |
+
+By balancing minimalism with practical tooling, Docker Hardened Images support
+modern development workflows without compromising on security or reliability.
+
+## Best practices for using minimal images
+
+- Use multi-stage builds to separate build-time and runtime environments
+- Validate image behavior using CI pipelines, not interactive inspection
+- Include runtime-specific dependencies explicitly in your Dockerfile
+- Use Docker Scout to continuously monitor for CVEs, even in minimal images
+
+By adopting minimal or distroless images through Docker Hardened Images, you
+gain a more secure, predictable, and production-ready container environment
+that's designed for automation, clarity, and reduced risk.
+
diff --git a/content/manuals/dhi/explore/security-concepts/fips.md b/content/manuals/dhi/explore/security-concepts/fips.md
new file mode 100644
index 000000000000..1929b5959dc0
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/fips.md
@@ -0,0 +1,124 @@
+---
+aliases:
+  - /dhi/core-concepts/fips/
+title: FIPS
+description: Learn how Docker Hardened Images support FIPS 140 through validated cryptographic modules to help organizations meet compliance requirements.
+keywords: docker fips, fips 140 images, fips docker images, docker compliance, secure container images
+---
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+## What is FIPS 140?
+
+[FIPS 140](https://csrc.nist.gov/publications/detail/fips/140/3/final) is a U.S.
+government standard that defines security requirements for cryptographic modules
+that protect sensitive information. It is widely used in regulated environments
+such as government, healthcare, and financial services.
+
+FIPS certification is managed by the [NIST Cryptographic Module Validation
+Program
+(CMVP)](https://csrc.nist.gov/projects/cryptographic-module-validation-program),
+which ensures cryptographic modules meet rigorous security standards.
+
+## Why FIPS compliance matters
+
+FIPS 140 compliance is required or strongly recommended in many regulated
+environments where sensitive data must be protected, such as government,
+healthcare, finance, and defense. These standards ensure that cryptographic
+operations are performed using vetted, trusted algorithms implemented in secure
+modules.
+
+Using software components that rely on validated cryptographic modules can help organizations:
+
+- Satisfy federal and industry mandates, such as FedRAMP, which require or
+  strongly recommend FIPS 140-validated cryptography.
+- Demonstrate audit readiness, with verifiable evidence of secure,
+  standards-based cryptographic practices.
+- Reduce security risk, by blocking unapproved or unsafe algorithms (e.g., MD5)
+  and ensuring consistent behavior across environments.
+
+## How Docker Hardened Images support FIPS compliance
+
+While Docker Hardened Images are available to all, the FIPS variant requires a
+paid Docker Hardened Images subscription.
+
+Docker Hardened Images (DHIs) include variants that use cryptographic modules
+validated under FIPS 140. These images are intended to help organizations meet
+compliance requirements by incorporating components that meet the standard.
+
+- FIPS image variants use cryptographic modules that are already validated under
+  FIPS 140.
+- These variants are built and maintained by Docker to support environments with
+  regulatory or compliance needs.
+- Docker provides signed test attestations that document the use of validated
+  cryptographic modules. These attestations can support internal audits and
+  compliance reporting.
+- Entropy sources (random number generation for cryptographic operations) vary
+  by base image. Debian-based images use the OpenSSL entropy source, while
+  Alpine-based images source entropy from the host kernel.
+
+> [!NOTE]
+>
+> Using a FIPS image variant helps meet compliance requirements but does not
+> make an application or system fully compliant. Compliance depends on how the
+> image is integrated and used within the broader system.
+
+## Identify images that support FIPS
+
+Docker Hardened Images that support FIPS are marked as **FIPS** compliant
+in the Docker Hardened Images catalog.
+
+To find DHI repositories with FIPS image variants, [search the catalog](../../how-to/search-evaluate.md) and:
+
+- Use the **FIPS** filter on the catalog page
+- Look for **FIPS** compliant on individual image listings
+
+These indicators help you quickly locate repositories that support FIPS-based
+compliance needs. Image variants that include FIPS support will have a tag
+ending with `-fips`, such as `3.13-fips`.
+
+## Use a FIPS variant
+
+To use a FIPS variant, you must [mirror](../../how-to/mirror.md) the repository
+and then pull the FIPS image from your mirrored repository.
+
+## View the FIPS attestation
+
+The FIPS variants of Docker Hardened Images contain a FIPS attestation that
+lists the actual cryptographic modules included in the image.
+
+You can retrieve and inspect the FIPS attestation using the Docker Scout CLI:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://docker.com/dhi/fips/v0.1 \
+  --predicate \
+  dhi.io/<image>:<tag>
+```
+
+For example:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://docker.com/dhi/fips/v0.1 \
+  --predicate \
+  dhi.io/python:3.13-fips
+```
+
+The attestation output is a JSON array describing the cryptographic modules
+included in the image and their compliance status. For example:
+
+```json
+[
+  {
+    "certification": "CMVP #4985",
+    "certificationUrl": "https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4985",
+    "name": "OpenSSL FIPS Provider",
+    "package": "pkg:dhi/openssl-provider-fips@3.1.2",
+    "standard": "FIPS 140-3",
+    "status": "active",
+    "sunsetDate": "2030-03-10",
+    "version": "3.1.2"
+  }
+]
+```
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/glibc-musl.md b/content/manuals/dhi/explore/security-concepts/glibc-musl.md
new file mode 100644
index 000000000000..9a6a865c32b5
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/glibc-musl.md
@@ -0,0 +1,60 @@
+---
+aliases:
+  - /dhi/core-concepts/glibc-musl/
+title: glibc and musl support in Docker Hardened Images
+linktitle: glibc and musl
+description: Compare glibc and musl variants of DHIs to choose the right base image for your application’s compatibility, size, and performance needs.
+keywords: glibc vs musl, alpine musl image, debian glibc container, docker hardened images compatibility, c library in containers
+---
+
+Docker Hardened Images (DHI) are built to prioritize security without
+sacrificing compatibility with the broader open source and enterprise software
+ecosystem. A key aspect of this compatibility is support for common Linux
+standard libraries: `glibc` and `musl`.
+
+## What are glibc and musl?
+
+When you run Linux-based containers, the image's C library plays a key role in
+how applications interact with the operating system. Most modern Linux
+distributions rely on one of the following standard C libraries:
+
+- `glibc` (GNU C Library): The standard C library on mainstream distributions
+  like Debian, Ubuntu, and Red Hat Enterprise Linux. It is widely supported and
+  typically considered the most compatible option across languages, frameworks,
+  and enterprise software.
+
+- `musl`: A lightweight alternative to `glibc`, commonly used in minimal
+  distributions like Alpine Linux. While it offers smaller image sizes and
+  performance benefits, `musl` is not always fully compatible with software that
+  expects `glibc`.
+
+## DHI compatibility
+
+DHI images are available in both `glibc`-based (e.g., Debian) and `musl`-based
+(e.g., Alpine) variants. For enterprise applications and language runtimes where
+compatibility is critical, we recommend using DHI images based on glibc.
+
+## What to choose, glibc or musl?
+
+Docker Hardened Images are available in both glibc-based (Debian) and musl-based
+(Alpine) variants, allowing you to choose the best fit for your workload.
+
+Choose Debian-based (`glibc`) images if:
+
+- You need broad compatibility with enterprise workloads, language runtimes, or
+  proprietary software.
+- You're using ecosystems like .NET, Java, or Python with native extensions that
+  depend on `glibc`.
+- You want to minimize the risk of runtime errors due to library
+  incompatibilities.
+
+Choose Alpine-based (`musl`) images if:
+
+- You want a minimal footprint with smaller image sizes and reduced surface
+  area.
+- You're building a custom or tightly controlled application stack where
+  dependencies are known and tested.
+- You prioritize startup speed and lean deployments over maximum compatibility.
+
+If you're unsure, start with a Debian-based image to ensure compatibility, and
+evaluate Alpine once you're confident in your application's dependencies.
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/hardening.md b/content/manuals/dhi/explore/security-concepts/hardening.md
new file mode 100644
index 000000000000..ddf6c7fb7067
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/hardening.md
@@ -0,0 +1,82 @@
+---
+aliases:
+  - /dhi/core-concepts/hardening/
+title: Base image hardening
+linktitle: Hardening
+description: Learn how Docker Hardened Images are designed for security, with minimal components, nonroot execution, and secure-by-default configurations.
+keywords: hardened base image, minimal container image, non-root containers, secure container configuration, remove package manager
+---
+
+## What is base image hardening?
+
+Base image hardening is the process of securing the foundational layers of a
+container image by minimizing what they include and configuring them with
+security-first defaults. A hardened base image removes unnecessary components,
+like shells, compilers, and package managers, which limits the available attack
+surface, making it more difficult for an attacker to gain control or escalate
+privileges inside the container.
+
+Hardening also involves applying best practices like running as a non-root user,
+reducing writable surfaces, and ensuring consistency through immutability. While
+[Docker Official
+Images](../../../docker-hub/image-library/trusted-content.md#docker-official-images)
+and [Docker Verified Publisher
+Images](../../../docker-hub/image-library/trusted-content.md#verified-publisher-images)
+follow best practices for security, they may not be as hardened as Docker
+Hardened Images, as they are designed to support a broader range of use cases.
+
+## Why is it important?
+
+Most containers inherit their security posture from the base image they use. If
+the base image includes unnecessary tools or runs with elevated privileges,
+every container built on top of it is exposed to those risks.
+
+Hardening the base image:
+
+- Reduces the attack surface by removing tools and libraries that could be exploited
+- Enforces least privilege by dropping root access and restricting what the container can do
+- Improves reliability and consistency by avoiding runtime changes and drift
+- Aligns with secure software supply chain practices and helps meet compliance standards
+
+Using hardened base images is a critical first step in securing the software you
+build and run in containers.
+
+## What's removed and why
+
+Hardened images typically exclude common components that are risky or unnecessary in secure production environments:
+
+| Removed component                                | Reason                                                                           |
+|--------------------------------------------------|----------------------------------------------------------------------------------|
+| Shells (e.g., `sh`, `bash`)                      | Prevents users or attackers from executing arbitrary commands inside containers  |
+| Package managers (e.g., `apt`, `apk`)            | Disables the ability to install software post-build, reducing drift and exposure |
+| Compilers and interpreters                       | Avoids introducing tools that could be used to run or inject malicious code      |
+| Debugging tools (e.g., `strace`, `curl`, `wget`) | Reduces risk of exploitation or information leakage                              |
+| Unused libraries or locales                      | Shrinks image size and minimizes attack vectors                                  |
+
+## How Docker Hardened Images apply base image hardening
+
+Docker Hardened Images (DHIs) apply base image hardening principles by design.
+Each image is constructed to include only what is necessary for its specific
+purpose, whether that’s building applications (with `-dev` or `-sdk` tags) or
+running them in production.
+
+### Docker Hardened Image traits
+
+Docker Hardened Images are built to be:
+
+- Minimal: Only essential libraries and binaries are included
+- Immutable: Images are fixed at build time—no runtime installations
+- Non-root by default: Containers run as an unprivileged user unless configured otherwise
+- Purpose-scoped: Different tags are available for development (`-dev`), SDK-based builds (`-sdk`), and production runtime
+
+These characteristics help enforce consistent, secure behavior across development, testing, and production environments.
+
+### Docker Hardened Image compatibility considerations
+
+Because Docker Hardened Images strip out many common tools, they may not work out of the box for all use cases. You may need to:
+
+- Use multi-stage builds to compile code or install dependencies in a `-dev` image and copy the output into a hardened runtime image
+- Replace shell scripts with equivalent entrypoint binaries or explicitly include a shell if needed
+- Use [Docker Debug](/reference/cli/docker/debug/) to temporarily inspect or troubleshoot containers without altering the base image
+
+These trade-offs are intentional and help support best practices for building secure, reproducible, and production-ready containers.
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/immutability.md b/content/manuals/dhi/explore/security-concepts/immutability.md
new file mode 100644
index 000000000000..f03f3261fc6c
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/immutability.md
@@ -0,0 +1,59 @@
+---
+aliases:
+  - /dhi/core-concepts/immutability/
+title: Immutable infrastructure
+linktitle: Immutability
+description: Understand how image digests, read-only containers, and signed metadata ensure Docker Hardened Images are tamper-resistant and immutable.
+keywords: immutable container image, read-only docker image, configuration drift prevention, secure redeployment, image digest verification
+---
+
+Immutable infrastructure is a security and operations model where components
+such as servers, containers, and images are never modified after deployment.
+Instead of patching or reconfiguring live systems, you replace them entirely
+with new versions.
+
+When using Docker Hardened Images, immutability is a best practice that
+reinforces the security posture of your software supply chain.
+
+## Why immutability matters
+
+Mutable systems are harder to secure and audit. Live patching or manual updates
+introduce risks such as:
+
+- Configuration drift
+- Untracked changes
+- Inconsistent environments
+- Increased attack surface
+
+Immutable infrastructure solves this by making changes only through controlled,
+repeatable builds and deployments.
+
+## How Docker Hardened Images support immutability
+
+Docker Hardened Images are built to be minimal, locked-down, and
+non-interactive, which discourages in-place modification. For example:
+
+- Many DHI images exclude shells, package managers, and debugging tools
+- DHI images are designed to be scanned and signed before deployment
+- DHI users are encouraged to rebuild and redeploy images rather than patch running containers
+
+This design aligns with immutable practices and ensures that:
+
+- Updates go through the CI/CD pipeline
+- All changes are versioned and auditable
+- Systems can be rolled back or reproduced consistently
+
+## Immutable patterns in practice
+
+Some common patterns that leverage immutability include:
+
+- Container replacement: Instead of logging into a container to fix a bug or
+  apply a patch, rebuild the image and redeploy it.
+- Infrastructure as Code (IaC): Define your infrastructure and image
+  configurations in version-controlled files.
+- Blue/Green or Canary deployments: Roll out new images alongside old ones and
+  gradually shift traffic to the new version.
+
+By combining immutable infrastructure principles with hardened images, you
+create a predictable and secure deployment workflow that resists tampering and
+minimizes long-term risk.
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/provenance.md b/content/manuals/dhi/explore/security-concepts/provenance.md
new file mode 100644
index 000000000000..7db3c9e72917
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/provenance.md
@@ -0,0 +1,73 @@
+---
+aliases:
+  - /dhi/core-concepts/provenance/
+title: Image provenance
+description: Learn how build provenance metadata helps trace the origin of Docker Hardened Images and support compliance with SLSA.
+keywords: image provenance, container build traceability, slsa compliance, signed container image, software supply chain trust
+---
+
+## What is image provenance?
+
+Image provenance refers to metadata that traces the origin, authorship, and
+integrity of a container image. It answers critical questions such as:
+
+- Where did this image come from?
+- Who built it?
+- Has it been tampered with?
+
+Provenance establishes a chain of custody, helping you verify that the image
+you're using is the result of a trusted and verifiable build process.
+
+## Why image provenance matters
+
+Provenance is foundational to securing your software supply chain. Without it, you risk:
+
+- Running unverified or malicious images
+- Failing to meet internal or regulatory compliance requirements
+- Losing visibility into the components and workflows that produce your containers
+
+With reliable provenance, you gain:
+
+- Trust: Know that your images are authentic and unchanged.
+- Traceability: Understand the full build process and source inputs.
+- Auditability: Provide verifiable evidence of compliance and build integrity.
+
+Provenance also supports automated policy enforcement and is a key requirement
+for frameworks like SLSA (Supply-chain Levels for Software Artifacts).
+
+## How Docker Hardened Images support provenance
+
+Docker Hardened Images (DHIs) are designed with built-in provenance to help you
+adopt secure-by-default practices and meet supply chain security standards.
+
+### Attestations
+
+DHIs include [attestations](./attestations.md)—machine-readable metadata that
+describe how, when, and where the image was built. These are generated using
+industry standards such as [in-toto](https://in-toto.io/) and align with [SLSA
+provenance](https://slsa.dev/spec/v1.0/provenance/).
+
+Attestations allow you to:
+
+- Validate that builds followed the expected steps
+- Confirm that inputs and environments meet policy
+- Trace the build process across systems and stages
+
+### Code signing
+
+Each Docker Hardened Image is cryptographically [signed](./signatures.md) and
+stored in the registry alongside its digest. These signatures are verifiable
+proofs of authenticity and are compatible with tools like `cosign`, Docker
+Scout, and Kubernetes admission controllers.
+
+With image signatures, you can:
+
+- Confirm that the image was published by Docker
+- Detect if an image has been modified or republished
+- Enforce signature validation in CI/CD or production deployments
+
+## Additional resources
+
+- [Provenance attestations](/build/metadata/attestations/slsa-provenance/)
+- [Image signatures](./signatures.md)
+- [Attestations overview](./attestations.md)
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/sbom.md b/content/manuals/dhi/explore/security-concepts/sbom.md
new file mode 100644
index 000000000000..07360ee072d6
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/sbom.md
@@ -0,0 +1,96 @@
+---
+aliases:
+  - /dhi/core-concepts/sbom/
+title: Software Bill of Materials (SBOMs)
+linktitle: SBOMs
+description: Learn what SBOMs are, why they matter, and how Docker Hardened Images include signed SBOMs to support transparency and compliance.
+keywords: sbom docker image, software bill of materials, signed sbom, container sbom verification, sbom compliance
+---
+
+## What is an SBOM?
+
+An SBOM is a detailed inventory that lists all components, libraries, and
+dependencies used in building a software application. It provides transparency
+into the software supply chain by documenting each component's version, origin,
+and relationship to other components. Think of it as a "recipe" for your
+software, detailing every ingredient and how they come together.
+
+Metadata included in an SBOM for describing software artifacts may include:
+
+- Name of the artifact
+- Version
+- License type
+- Authors
+- Unique package identifier
+
+## Why are SBOMs important?
+
+In today's software landscape, applications often comprise numerous components
+from various sources, including open-source libraries, third-party services, and
+proprietary code. This complexity can obscure visibility into potential
+vulnerabilities and complicate compliance efforts. SBOMs address these
+challenges by providing a detailed inventory of all components within an
+application.
+
+
+The significance of SBOMs is underscored by several key factors:
+
+- Enhanced transparency: SBOMs offer a comprehensive view of all components that
+  constitute an application, enabling organizations to identify and assess risks
+  associated with third-party libraries and dependencies.
+
+- Proactive vulnerability management: By maintaining an up-to-date SBOM,
+  organizations can swiftly identify and address vulnerabilities in software
+  components, reducing the window of exposure to potential exploits.
+
+- Regulatory compliance: Many regulations and industry standards now require
+  organizations to maintain control over the software components they use. An
+  SBOM facilitates compliance by providing a clear and accessible record.
+
+- Improved incident response: In the event of a security breach, an SBOM
+  enables organizations to quickly identify affected components and take
+  appropriate action, minimizing potential damage.
+
+## Docker Hardened Image SBOMs
+
+Docker Hardened Images have SBOMs, ensuring that every component
+in the image is documented and verifiable. These SBOMs are cryptographically
+signed, providing a tamper-evident record of the image's contents. This
+integration simplifies audits and enhances trust in the software supply chain.
+
+## View SBOMs in Docker Hardened Images
+
+To view the SBOM of a Docker Hardened Image, you can use the `docker scout sbom`
+command. Replace `<image-name>:<tag>` with the image name and tag.
+
+```console
+$ docker scout sbom dhi.io/<image-name>:<tag>
+```
+
+## Verify the SBOM of a Docker Hardened Image
+
+Since Docker Hardened Images come with signed SBOMs, you can use Docker Scout to
+verify the authenticity and integrity of the SBOM attached to the image. This
+ensures that the SBOM has not been tampered with and that the image's contents
+are trustworthy.
+
+To verify the SBOM of a Docker Hardened Image using Docker Scout, use the following command:
+
+```console
+$ docker scout attest get dhi.io/<image-name>:<tag> \
+   --predicate-type https://scout.docker.com/sbom/v0.1 --verify --platform <platform>
+```
+
+For example, to verify the SBOM attestation for the `node:20.19-debian12` image:
+
+```console
+$ docker scout attest get dhi.io/node:20.19-debian12 \
+   --predicate-type https://scout.docker.com/sbom/v0.1 --verify --platform linux/amd64
+```
+
+## Resources
+
+For more details about SBOM attestations and Docker Build, see [SBOM
+attestations](/build/metadata/attestations/sbom/).
+
+To learn more about Docker Scout and working with SBOMs, see [Docker Scout SBOMs](../../../scout/how-tos/view-create-sboms.md).
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/signatures.md b/content/manuals/dhi/explore/security-concepts/signatures.md
new file mode 100644
index 000000000000..d766d850ae2d
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/signatures.md
@@ -0,0 +1,106 @@
+---
+aliases:
+  - /dhi/core-concepts/signatures/
+title: Code signing
+description: Understand how Docker Hardened Images are cryptographically signed using Cosign to verify authenticity, integrity, and secure provenance.
+keywords: container image signing, cosign docker image, verify image signature, signed container image, sigstore cosign
+---
+
+## What is code signing?
+
+Code signing is the process of applying a cryptographic signature to software
+artifacts, such as Docker images, to verify their integrity and authenticity. By
+signing an image, you ensure that it has not been altered since it was signed
+and that it originates from a trusted source.
+
+In the context of Docker Hardened Images (DHIs), code signing is achieved using
+[Cosign](https://docs.sigstore.dev/), a tool developed by the Sigstore project.
+Cosign enables secure and verifiable signing of container images, enhancing
+trust and security in the software supply chain.
+
+## Why is code signing important?
+
+Code signing plays a crucial role in modern software development and
+cybersecurity:
+
+- Authenticity: Verifies that the image was created by a trusted source.
+- Integrity: Ensures that the image has not been tampered with since it was
+  signed.
+- Compliance: Helps meet regulatory and organizational security requirements.
+
+## Docker Hardened Image code signing
+
+Each DHI is cryptographically signed using Cosign, ensuring that the images have
+not been tampered with and originate from a trusted source.
+
+## Why sign your own images?
+
+Docker Hardened Images are signed by Docker to prove their origin and integrity,
+but if you're building application images that extend or use DHIs as a base, you
+should sign your own images as well.
+
+By signing your own images, you can:
+
+- Prove the image was built by your team or pipeline
+- Ensure your build hasn't been tampered with after it's pushed
+- Support software supply chain frameworks like SLSA
+- Enable image verification in deployment workflows
+
+This is especially important in CI/CD environments where you build and push
+images frequently, or in any scenario where image provenance must be auditable.
+
+## How to view and use code signatures
+
+### View signatures
+
+You can verify that a Docker Hardened Image is signed and trusted using either Docker Scout or Cosign.
+
+To lists all attestations, including signature metadata, attached to the image, use the following command:
+
+```console
+$ docker scout attest list <image-name>:<tag>
+```
+
+> [!NOTE]
+>
+> If the image exists locally on your device, you must prefix the image name with `registry://`. For example, use
+> `registry://dhi.io/python` instead of `dhi.io/python`.
+
+To verify a specific signed attestation (e.g., SBOM, VEX, provenance):
+
+```console
+$ docker scout attest get \
+  --predicate-type <predicate-uri> \
+  --verify \
+  <image-name>:<tag>
+```
+
+> [!NOTE]
+>
+> If the image exists locally on your device, you must prefix the image name with `registry://`. For example, use
+> `registry://dhi.io/python:3.13` instead of `dhi.io/python:3.13`.
+
+For example:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://openvex.dev/ns/v0.2.0 \
+  --verify \
+  dhi.io/python:3.13
+```
+
+If valid, Docker Scout will confirm the signature and display signature payload, as well as the equivalent Cosign command to verify the image.
+
+### Sign images
+
+To sign a Docker image, use [Cosign](https://docs.sigstore.dev/). Replace
+`<image-name>:<tag>` with the image name and tag.
+
+```console
+$ cosign sign <image-name>:<tag>
+```
+
+This command will prompt you to authenticate via an OIDC provider (such as
+GitHub, Google, or Microsoft). Upon successful authentication, Cosign will
+generate a short-lived certificate and sign the image. The signature will be
+stored in a transparency log and associated with the image in the registry.
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/slsa.md b/content/manuals/dhi/explore/security-concepts/slsa.md
new file mode 100644
index 000000000000..303da61f8ad0
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/slsa.md
@@ -0,0 +1,107 @@
+---
+aliases:
+  - /dhi/core-concepts/slsa/
+title: Supply-chain Levels for Software Artifacts (SLSA)
+linktitle: SLSA
+description: Learn how Docker Hardened Images comply with SLSA Build Level 3 and how to verify provenance for secure, tamper-resistant builds.
+keywords: slsa docker compliance, slsa build level 3, supply chain security, verified build provenance, secure container build
+---
+
+## What is SLSA?
+
+Supply-chain Levels for Software Artifacts (SLSA) is a security framework
+designed to enhance the integrity and security of software supply chains.
+Developed by Google and maintained by the Open Source Security Foundation
+(OpenSSF), SLSA provides a set of guidelines and best practices to prevent
+tampering, improve integrity, and secure packages and infrastructure in software
+projects.
+
+SLSA defines [four build levels (0–3)](https://slsa.dev/spec/latest/build-track-basics) of
+increasing security rigor, focusing on areas such as build provenance, source
+integrity, and build environment security. Each level builds upon the previous
+one, offering a structured approach to achieving higher levels of software
+supply chain security.
+
+## Why is SLSA important?
+
+SLSA is crucial for modern software development due to the increasing complexity
+and interconnectedness of software supply chains. Supply chain attacks, such as
+the SolarWinds breach, have highlighted the vulnerabilities in software
+development processes. By implementing SLSA, organizations can:
+
+- Ensure artifact integrity: Verify that software artifacts have not been
+  tampered with during the build and deployment processes.
+
+- Enhance build provenance: Maintain verifiable records of how and when software
+  artifacts were produced, providing transparency and accountability.
+
+- Secure build environments: Implement controls to protect build systems from
+  unauthorized access and modifications.
+
+- Mitigate supply chain risks: Reduce the risk of introducing vulnerabilities or
+  malicious code into the software supply chain.
+
+## What is SLSA Build Level 3?
+
+SLSA Build Level 3, Hardened Builds, is the highest of four progressive levels in
+the SLSA framework. It introduces strict requirements to ensure that software
+artifacts are built securely and traceably. To meet Level 3, a build must:
+
+- Be fully automated and scripted to prevent manual tampering
+- Use a trusted build service that enforces source and builder authentication
+- Generate a signed, tamper-resistant provenance record describing how the artifact was built
+- Capture metadata about the build environment, source repository, and build steps
+
+This level provides strong guarantees that the software was built from the
+expected source in a controlled, auditable environment, which significantly
+reduces the risk of supply chain attacks.
+
+## Docker Hardened Images and SLSA
+
+Docker Hardened Images (DHIs) are secure-by-default container images
+purpose-built for modern production environments. Each DHI is cryptographically
+signed and complies with the [SLSA Build Level 3
+standard](https://slsa.dev/spec/latest/build-track-basics#build-l3), ensuring
+verifiable build provenance and integrity.
+
+By integrating SLSA-compliant DHIs into your development and deployment processes, you can:
+
+- Achieve higher security levels: Utilize images that meet stringent security
+  standards, reducing the risk of vulnerabilities and attacks.
+
+- Simplify compliance: Leverage built-in features like signed Software Bills of
+  Materials (SBOMs) and vulnerability exception (VEX) statements to facilitate
+  compliance with regulations such as FedRAMP.
+
+- Enhance transparency: Access detailed information about the components and
+  build process of each image, promoting transparency and trust.
+
+- Streamline audits: Utilize verifiable build records and signatures to simplify
+  security audits and assessments.
+
+## Get and verify SLSA provenance for Docker Hardened Images
+
+Each Docker Hardened Image (DHI) is cryptographically signed and includes
+attestations. These attestations provide verifiable build provenance and
+demonstrate adherence to SLSA Build Level 3 standards.
+
+To get and verify SLSA provenance for a DHI, you can use Docker Scout.
+
+```console
+$ docker scout attest get dhi.io/<image>:<tag> \
+  --predicate-type https://slsa.dev/provenance/v0.2 \
+  --verify
+```
+
+For example:
+
+```console
+$ docker scout attest get dhi.io/node:20.19-debian12 \
+  --predicate-type https://slsa.dev/provenance/v0.2 \
+  --verify
+```
+
+## Resources
+
+For more details about SLSA definitions and Docker Build, see [SLSA
+definitions](/build/metadata/attestations/slsa-definitions/).
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/sscs.md b/content/manuals/dhi/explore/security-concepts/sscs.md
new file mode 100644
index 000000000000..fab3f1dafe5c
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/sscs.md
@@ -0,0 +1,54 @@
+---
+aliases:
+  - /dhi/core-concepts/sscs/
+title: Software Supply Chain Security
+linktitle: Software Supply Chain Security
+description: Learn how Docker Hardened Images help secure every stage of your software supply chain with signed metadata, provenance, and minimal attack surface.
+keywords: software supply chain security, secure container images, signed image provenance, docker sbom, distroless security
+---
+
+## What is Software Supply Chain Security (SSCS)?
+
+SSCS encompasses practices and strategies designed to safeguard the entire
+lifecycle of software development from initial code creation to deployment and
+maintenance. It focuses on securing all components. This includes code,
+dependencies, build processes, and distribution channels in order to prevent
+malicious actors from compromising the software supply chain. Given the
+increasing reliance on open-source libraries and third-party components,
+ensuring the integrity and security of these elements is paramount
+
+## Why is SSCS important?
+
+The significance of SSCS has escalated due to sophisticated cyberattacks
+targeting software supply chains. High-profile supply chain attacks and the
+exploitation of vulnerabilities in open-source components underscore the
+critical need for robust supply chain security measures. Compromises at any
+stage of the software lifecycle can lead to widespread vulnerabilities, data
+breaches, and significant financial losses.
+
+## How Docker Hardened Images contribute to SSCS
+
+Docker Hardened Images (DHI) are purpose-built container images designed with
+security at their core, addressing the challenges of modern software supply
+chain security. By integrating DHI into your development and deployment
+pipelines, you can enhance your organization's SSCS posture through the
+following features:
+
+- Minimal attack surface: DHIs are engineered to be ultra-minimal, stripping
+  away unnecessary components and reducing the attack surface by up to 95%. This
+  distroless approach minimizes potential entry points for malicious actors.
+
+- Cryptographic signing and provenance: Each DHI is cryptographically signed,
+  ensuring authenticity and integrity. Build provenance is maintained, providing
+  verifiable evidence of the image's origin and build process, aligning with
+  standards like SLSA (Supply-chain Levels for Software Artifacts).
+
+- Software Bill of Materials (SBOM): DHIs include a comprehensive SBOM,
+  detailing all components and dependencies within the image. This transparency
+  aids in vulnerability management and compliance tracking, enabling teams to
+  assess and mitigate risks effectively.
+
+- Continuous maintenance and rapid CVE remediation: Docker maintains DHIs with
+  regular updates and security patches, backed by an [SLA for addressing critical
+  and high-severity vulnerabilities](https://docs.docker.com/go/dhi-sla/). This proactive approach helps ensure that
+  images remain secure and compliant with enterprise standards.
diff --git a/content/manuals/dhi/explore/security-concepts/ssdlc.md b/content/manuals/dhi/explore/security-concepts/ssdlc.md
new file mode 100644
index 000000000000..88221ae0f3fd
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/ssdlc.md
@@ -0,0 +1,115 @@
+---
+aliases:
+  - /dhi/core-concepts/ssdlc/
+title: Secure Software Development Lifecycle
+linktitle: SSDLC
+description: See how Docker Hardened Images support a secure SDLC by integrating with scanning, signing, and debugging tools.
+keywords: secure software development, ssdlc containers, slsa compliance, docker scout integration, secure container debugging
+---
+
+## What is a Secure Software Development Lifecycle?
+
+A Secure Software Development Lifecycle (SSDLC) integrates security practices
+into every phase of software delivery, from design and development to deployment
+and monitoring. It’s not just about writing secure code, but about embedding
+security throughout the tools, environments, and workflows used to build and
+ship software.
+
+SSDLC practices are often guided by compliance frameworks, organizational
+policies, and supply chain security standards such as SLSA (Supply-chain Levels
+for Software Artifacts) or NIST SSDF.
+
+## Why SSDLC matters
+
+Modern applications depend on fast, iterative development, but rapid delivery
+often introduces security risks if protections aren’t built in early. An SSDLC
+helps:
+
+- Prevent vulnerabilities before they reach production
+- Ensure compliance through traceable and auditable workflows
+- Reduce operational risk by maintaining consistent security standards
+- Enable secure automation in CI/CD pipelines and cloud-native environments
+
+By making security a first-class citizen in each stage of software delivery,
+organizations can shift left and reduce both cost and complexity.
+
+## How Docker supports a secure SDLC
+
+Docker provides tools and secure content that make SSDLC practices easier to
+adopt across the container lifecycle. With [Docker Hardened
+Images](../_index.md) (DHIs), [Docker
+Debug](/reference/cli/docker/debug/), and [Docker
+Scout](../../../scout/_index.md), teams can add security without losing
+velocity.
+
+### Plan and design
+
+During planning, teams define architectural constraints, compliance goals, and
+threat models. Docker Hardened Images help at this stage by providing:
+
+- Secure-by-default base images for common languages and runtimes
+- Verified metadata including SBOMs, provenance, and VEX documents
+- Support for both glibc and musl across multiple Linux distributions
+
+You can use DHI metadata and attestations to support design reviews, threat
+modeling, or architecture sign-offs.
+
+### Develop
+
+In development, security should be transparent and easy to apply. Docker
+Hardened Images support secure-by-default development:
+
+- Dev variants include shells, package managers, and compilers for convenience
+- Minimal runtime variants reduce attack surface in final images
+- Multi-stage builds let you separate build-time tools from runtime environments
+
+[Docker Debug](/reference/cli/docker/debug/) helps developers:
+
+- Temporarily inject debugging tools into minimal containers
+- Avoid modifying base images during troubleshooting
+- Investigate issues securely, even in production-like environments
+
+### Build and test
+
+Build pipelines are an ideal place to catch issues early. Docker Scout
+integrates with Docker Hub and the CLI to:
+
+- Scan for known CVEs using multiple vulnerability databases
+- Trace vulnerabilities to specific layers and dependencies
+- Interpret signed VEX data to suppress known-irrelevant issues
+- Export JSON scan reports for CI/CD workflows
+
+Build pipelines that use Docker Hardened Images benefit from:
+
+- Reproducible, signed images
+- Minimal build surfaces to reduce exposure
+- Built-in compliance with SLSA Build Level 3 standards
+
+### Release and deploy
+
+Security automation is critical as you release software at scale. Docker
+supports this phase by enabling:
+
+- Signature verification and provenance validation before deployment
+- Policy enforcement gates using Docker Scout
+- Safe, non-invasive container inspection using Docker Debug
+
+DHIs ship with the metadata and signatures required to automate image
+verification during deployment.
+
+### Monitor and improve
+
+Security continues after release. With Docker tools, you can:
+
+- Continuously monitor image vulnerabilities through Docker Hub
+- Get CVE remediation guidance and patch visibility using Docker Scout
+- Receive updated DHI images with rebuilt and re-signed secure layers
+- Debug running workloads with Docker Debug without modifying the image
+
+## Summary
+
+Docker helps teams embed security throughout the SSDLC by combining secure
+content (DHIs) with developer-friendly tooling (Docker Scout and Docker Debug).
+These integrations promote secure practices without introducing friction, making
+it easier to adopt compliance and supply chain security across your software
+delivery lifecycle.
\ No newline at end of file
diff --git a/content/manuals/dhi/explore/security-concepts/stig.md b/content/manuals/dhi/explore/security-concepts/stig.md
new file mode 100644
index 000000000000..95349728ebc7
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/stig.md
@@ -0,0 +1,135 @@
+---
+aliases:
+  - /dhi/core-concepts/stig/
+title: STIG
+description: Learn how Docker Hardened Images provide STIG-ready container images with verifiable security scan attestations for government and enterprise compliance requirements.
+keywords: docker stig, stig-ready images, stig guidance, openscap docker, secure container images
+---
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+## What is STIG?
+
+[Security Technical Implementation Guides
+(STIGs)](https://public.cyber.mil/stigs/) are configuration standards published
+by the U.S. Defense Information Systems Agency (DISA). They define security
+requirements for operating systems, applications, databases, and other
+technologies used in U.S. Department of Defense (DoD) environments.
+
+STIGs help ensure that systems are configured securely and consistently to
+reduce vulnerabilities. They are often based on broader requirements like the
+DoD's General Purpose Operating System Security Requirements Guide (GPOS SRG).
+
+## Why STIG guidance matters
+
+Following STIG guidance is critical for organizations that work with or support
+U.S. government systems. It demonstrates alignment with DoD security standards
+and helps:
+
+- Accelerate Authority to Operate (ATO) processes for DoD systems
+- Reduce the risk of misconfiguration and exploitable weaknesses
+- Simplify audits and reporting through standardized baselines
+
+Even outside of federal environments, STIGs are used by security-conscious
+organizations as a benchmark for hardened system configurations.
+
+STIGs are derived from broader NIST guidance, particularly [NIST Special
+Publication 800-53](https://csrc.nist.gov/publications/sp800), which defines a
+catalog of security and privacy controls for federal systems. Organizations
+pursuing compliance with 800-53 or related frameworks (such as FedRAMP) can use
+STIGs as implementation guides that help meet applicable control requirements.
+
+## How Docker Hardened Images help apply STIG guidance
+
+Docker Hardened Images (DHIs) include STIG variants that are scanned against
+custom STIG-based profiles and include signed STIG scan attestations. These
+attestations can support audits and compliance reporting.
+
+While Docker Hardened Images are available to all, the STIG variant requires a
+Docker subscription.
+
+Docker creates custom STIG-based profiles for images based on the GPOS SRG and
+DoD Container Hardening Process Guide. Because DISA has not published a STIG
+specifically for containers, these profiles help apply STIG-like guidance to
+container environments in a consistent, reviewable way and are designed to
+reduce false positives common in container images.
+
+## Identify images that include STIG scan results
+
+Docker Hardened Images that include STIG scan results are labeled as **STIG** in
+the Docker Hardened Images catalog.
+
+To find DHI repositories with STIG image variants, [explore
+images](../../tools/hub.md#images-page) and:
+
+- Use the **STIG** filter on the catalog page
+- Look for **STIG** labels on individual image listings
+
+To find a STIG image variant within a repository, go to the **Tags** tab in the
+repository, and find images labeled with **STIG** in the **Compliance** column.
+
+## Use a STIG variant
+
+To use a STIG variant, you must [mirror](../../how-to/mirror.md) the repository
+and then pull the STIG image from your mirrored repository.
+
+## View and verify STIG scan results
+
+Docker provides a signed [STIG scan
+attestation](attestations.md) for each STIG-ready image.
+These attestations include:
+
+- A summary of the scan results, including the number of passed, failed, and not
+  applicable checks
+- The name and version of the STIG profile used
+- Full output in both HTML and XCCDF (XML) formats
+
+### View STIG scan attestations
+
+You can retrieve and inspect a STIG scan attestation using the Docker Scout CLI:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://docker.com/dhi/stig/v0.1 \
+  --verify \
+  --predicate \
+  dhi.io/<image>:<tag>
+```
+
+### Extract HTML report
+
+To extract and view the human-readable HTML report:
+
+```console
+$ docker scout attest get dhi.io/<image>:<tag> \
+  --predicate-type https://docker.com/dhi/stig/v0.1 \
+  --verify \
+  --predicate \
+  | jq -r '.[0].output[] | select(.format == "html").content | @base64d' > stig_report.html
+```
+
+### Extract XCCDF report
+
+To extract the XML (XCCDF) report for integration with other tools:
+
+```console
+$ docker scout attest get dhi.io/<image>:<tag> \
+  --predicate-type https://docker.com/dhi/stig/v0.1 \
+  --verify \
+  --predicate \
+  | jq -r '.[0].output[] | select(.format == "xccdf").content | @base64d' > stig_report.xml
+```
+
+### View STIG scan summary
+
+To view just the scan summary without the full reports:
+
+```console
+$ docker scout attest get dhi.io/<image>:<tag> \
+  --predicate-type https://docker.com/dhi/stig/v0.1 \
+  --verify \
+  --predicate \
+  | jq -r '.[0] | del(.output)'
+```
+
+
diff --git a/content/manuals/dhi/explore/security-concepts/vex.md b/content/manuals/dhi/explore/security-concepts/vex.md
new file mode 100644
index 000000000000..cd25e86b191a
--- /dev/null
+++ b/content/manuals/dhi/explore/security-concepts/vex.md
@@ -0,0 +1,62 @@
+---
+aliases:
+  - /dhi/core-concepts/vex/
+title: Vulnerability Exploitability eXchange (VEX)
+linktitle: VEX
+description: Learn how VEX helps you prioritize real risks by identifying which vulnerabilities in Docker Hardened Images are actually exploitable.
+keywords: vex container security, vulnerability exploitability, filter false positives, docker scout vex, cve prioritization
+---
+
+## What is VEX?
+
+Vulnerability Exploitability eXchange (VEX) is a specification for documenting
+the exploitability status of vulnerabilities within software components. VEX is
+primarily defined through industry standards such as CSAF (OASIS) and CycloneDX
+VEX, with the U.S. Cybersecurity and Infrastructure Security Agency (CISA)
+encouraging its adoption. VEX complements CVE (Common Vulnerabilities and
+Exposures) identifiers by adding producer-asserted status information,
+indicating whether a vulnerability is exploitable in the product as shipped.
+This helps organizations prioritize remediation efforts by identifying
+vulnerabilities that do not affect their specific product configurations.
+
+For how VEX affects vulnerability counts and scanner selection, see [Scanner
+integrations](/manuals/dhi/explore/scanner-integrations.md). To scan a DHI with
+VEX support, see [Scan Docker Hardened Images](/manuals/dhi/how-to/scan.md).
+
+## VEX status reference
+
+Each VEX statement includes a `status` field that records Docker's
+exploitability assessment for a given CVE and image. OpenVEX defines four
+status values. DHI uses three of them:
+
+| Status | Meaning |
+|---|---|
+| `not_affected` | The CVE was reported against a package in the image, but Docker has assessed it is not exploitable as shipped |
+| `under_investigation` | Docker is aware of the CVE and is actively evaluating whether it affects the image |
+| `affected` | Docker has confirmed the CVE is exploitable in the image and a fix is not yet available |
+| `fixed` | The vulnerability has been remediated in this version. DHI does not use this status (see below). |
+
+You can view the VEX statements for any DHI using Docker Scout. See [Scan Docker
+Hardened Images](/manuals/dhi/how-to/scan.md). To query suppressed CVEs
+programmatically by image digest, see [Query suppressed CVEs for a DHI by
+digest](/manuals/dhi/how-to/vex-api.md).
+
+### `not_affected` justification codes
+
+`not_affected` statements include a machine-readable `justification` field
+explaining why the vulnerability does not apply:
+
+| Justification | Meaning |
+|---|---|
+| `component_not_present` | The vulnerable component is not present in this image; the CVE matched by name against a different package |
+| `vulnerable_code_not_present` | The vulnerable code path was not compiled into this build |
+| `vulnerable_code_not_in_execute_path` | The vulnerable code exists in the package but is not called in this image's runtime configuration |
+| `vulnerable_code_cannot_be_controlled_by_adversary` | The vulnerable code exists but an attacker cannot trigger it in this configuration |
+| `inline_mitigations_already_exist` | Docker has applied a backport or patch that addresses the CVE |
+
+### Why DHI does not use `fixed`
+
+DHI does not use `fixed`. VEX-enabled scanners may not handle `fixed`
+consistently, so when Docker backports an upstream patch where the version
+number alone would not reflect the fix, it uses `not_affected` with
+`inline_mitigations_already_exist` justification instead.
diff --git a/content/manuals/dhi/explore/test.md b/content/manuals/dhi/explore/test.md
new file mode 100644
index 000000000000..a8c56f279744
--- /dev/null
+++ b/content/manuals/dhi/explore/test.md
@@ -0,0 +1,155 @@
+---
+title: How Docker Hardened Images are tested
+linktitle: Image testing
+description: See how Docker Hardened Images are automatically tested for standards compliance, functionality, and security.
+keywords: docker scout, test attestation, cosign verify, image testing, vulnerability scan
+weight: 45
+aliases:
+  - /dhi/about/test/
+---
+
+Docker Hardened Images (DHIs) are designed to be secure, minimal, and
+production-ready. To ensure their reliability and security, Docker employs a
+comprehensive testing strategy, which you can independently verify using signed
+attestations and open tooling.
+
+Every image is tested for standards compliance, functionality, and security. The
+results of this testing are embedded as signed attestations, which can be
+[inspected and verified](#view-and-verify-the-test-attestation) programmatically
+using the Docker Scout CLI.
+
+## Testing strategy overview
+
+The testing process for DHIs focuses on two main areas:
+
+- Image standards compliance: Ensuring that each image adheres to strict size,
+  security, and compatibility standards.
+- Application functionality: Verifying that applications within the images
+  function correctly.
+
+## Image standards compliance
+
+Each DHI undergoes rigorous checks to meet the following standards:
+
+- Minimal attack surface: Images are built to be as small as possible, removing
+  unnecessary components to reduce potential vulnerabilities.
+- Near-zero known CVEs: Images are scanned using tools like Docker Scout to
+  ensure they are free from known Common Vulnerabilities and Exposures (CVEs).
+- Multi-architecture support: DHIs are built for multiple architectures
+  (`linux/amd64` and `linux/arm64`) to ensure broad compatibility.
+- Kubernetes compatibility: Images are tested to run seamlessly within
+  Kubernetes clusters, ensuring they meet the requirements for container
+  orchestration environments.
+
+## Application functionality testing
+
+Docker tests Docker Hardened Images to ensure they behave as expected in typical
+usage scenarios. This includes verifying that:
+
+- Applications start and run successfully in containerized environments.
+- Runtime behavior aligns with upstream expectations.
+- Build variants (like `-dev` images) support common development and build tasks.
+
+The goal is to ensure that DHIs work out of the box for the most common use
+cases while maintaining the hardened, minimal design.
+
+## Automated testing and CI/CD integration
+
+Docker integrates automated testing into its Continuous Integration/Continuous
+Deployment (CI/CD) pipelines:
+
+- Automated scans: Each image build triggers automated scans for vulnerabilities
+  and compliance checks.
+- Reproducible builds: Build processes are designed to be reproducible, ensuring
+  consistency across different environments.
+- Continuous monitoring: Docker continuously monitors for new vulnerabilities
+  and updates images accordingly to maintain security standards.
+
+## Testing attestation
+
+Docker provides a test attestation that details the testing and validation
+processes each DHI has undergone.
+
+### View and verify the test attestation
+
+You can view and verify this attestation using the Docker Scout CLI.
+
+1. Use the `docker scout attest get` command with the test predicate type:
+
+   ```console
+   $ docker scout attest get \
+     --predicate-type https://scout.docker.com/tests/v0.1 \
+     --predicate \
+     dhi.io/<image>:<tag>
+   ```
+
+   > [!NOTE]
+   >
+   > If the image exists locally on your device, you must prefix the image name with `registry://`. For example, use
+   > `registry://dhi.io/python` instead of `dhi.io/python`.
+
+   For example:
+
+   ```console
+   $ docker scout attest get \
+     --predicate-type https://scout.docker.com/tests/v0.1 \
+     --predicate \
+     dhi.io/python:3.13
+   ```
+
+   This contains a list of tests and their results.
+
+   Example output:
+
+    ```console
+        v SBOM obtained from attestation, 101 packages found
+        v Provenance obtained from attestation
+        {
+          "reportFormat": "CTRF",
+          "results": {
+            "summary": {
+              "failed": 0,
+              "passed": 1,
+              "skipped": 0,
+              "start": 1749216533,
+              "stop": 1749216574,
+              "tests": 1
+            },
+            "tests": [
+              {
+                ...
+   ```
+
+2. Verify the test attestation signature. To ensure the attestation is authentic
+   and signed by Docker, run:
+
+   ```console
+   docker scout attest get \
+     --predicate-type https://scout.docker.com/tests/v0.1 \
+     --verify \
+     dhi.io/<image>:<tag> --platform <platform>
+   ```
+
+   Example output:
+   
+   ```console
+    v SBOM obtained from attestation, 101 packages found
+    v Provenance obtained from attestation
+    v cosign verify registry.scout.docker.com/docker/dhi-python@sha256:70c8299c4d3cb4d5432734773c45ae58d8acc2f2f07803435c65515f662136d5 \
+        --key https://registry.scout.docker.com/keyring/dhi/latest.pub --experimental-oci11
+
+      Verification for registry.scout.docker.com/docker/dhi-python@sha256:70c8299c4d3cb4d5432734773c45ae58d8acc2f2f07803435c65515f662136d5 --
+      The following checks were performed on each of these signatures:
+        - The cosign claims were validated
+        - Existence of the claims in the transparency log was verified offline
+        - The signatures were verified against the specified public key
+
+    i Signature payload
+    ...
+    ```
+
+If the attestation is valid, Docker Scout will confirm the signature and show
+the matching `cosign verify` command.
+
+To view other attestations, such as SBOMs or vulnerability reports, see [Verify
+an image](../how-to/verify.md).
diff --git a/content/manuals/dhi/explore/what.md b/content/manuals/dhi/explore/what.md
new file mode 100644
index 000000000000..962276f8858e
--- /dev/null
+++ b/content/manuals/dhi/explore/what.md
@@ -0,0 +1,98 @@
+---
+title: What are hardened images and why use them?
+linktitle: Hardened images
+description: Learn what a hardened image is, why it matters, and how Docker Hardened Images offer stronger security, compliance, and operational efficiency.
+keywords: hardened container image, docker hardened images, distroless container, slsa build level 3, signed sbom, vulnerability scan, compliance-ready container
+weight: 5
+aliases:
+  - /dhi/about/what/
+---
+
+In today’s diverse software environments, container images are often designed
+for flexibility and broad compatibility. While that makes them ideal for many
+use cases, it can also result in images that include more components than needed
+for specific workloads. Docker Hardened Images take a minimal-by-design approach
+to help reduce image size, limit the attack surface, and streamline security and
+compliance workflows.
+
+Hardened images solve this by minimizing what's in the container image. Less
+software means fewer vulnerabilities, faster deployments, and fewer red
+dashboards to chase down every week.
+
+For platform engineers and security teams, hardened images offer a way out of
+the CVE triage cycle, letting you focus on delivering secure, compliant
+infrastructure without constant firefighting.
+
+## What is a hardened image?
+
+A hardened image is a container image that has been deliberately minimized and
+secured to reduce vulnerabilities and meet stringent security and compliance
+requirements. Unlike standard images, which may include non-essential components
+that increase risk, hardened images are streamlined to include only what’s
+needed to run your application securely. For a deeper look at the techniques
+involved, see [Base image hardening](security-concepts/hardening.md).
+
+## Benefits of hardened images
+
+- Reduced attack surface: By removing non-essential components, hardened images
+  limit potential entry points for attackers.
+- Improved security posture: Regular updates and vulnerability scans help ensure
+  hardened images remain secure over time.
+- Compliance facilitation: Inclusion of signed metadata like SBOMs supports
+  meeting regulatory and organizational compliance standards.
+- Operational efficiency: Smaller image sizes lead to faster pulls, lower runtime overhead, and reduced cloud resource costs.
+
+## What is a Docker Hardened Image?
+
+Docker Hardened Images (DHIs) take hardened images even further by combining
+minimal, secure design with enterprise-grade support and tooling. Built with
+security at the core, these images are continuously maintained, tested, and
+validated to meet today’s toughest software supply chain and compliance
+standards.
+
+Docker Hardened Images are secure by default, minimal by design, and maintained
+so you don’t have to.
+
+## How Docker Hardened Images differ from generic hardened images
+
+- SLSA-compliant builds: Docker Hardened Images are built to meet [SLSA Build
+  Level 3](security-concepts/slsa.md), ensuring a tamper-resistant, verifiable,
+  and auditable build process that protects against supply chain threats.
+
+-  Distroless approach: Unlike traditional base images that bundle an entire OS
+   with shells, package managers, and debugging tools, [distroless
+   images](security-concepts/distroless.md) retain only the minimal OS components
+   required to run your application. By excluding unnecessary tooling and
+   libraries, they reduce the attack surface by up to 95% and can improve
+   performance and image size.
+
+- Continuous maintenance: All DHIs are continuously monitored and updated to
+  maintain near-zero known exploitable [CVEs](security-concepts/cves.md), helping
+  your teams avoid patch fatigue and surprise alerts.
+
+- Compliance-ready: Each image includes cryptographically signed metadata:
+  - [SBOMs](security-concepts/sbom.md) that show what's in the image
+  - [VEX documents](security-concepts/vex.md) to identify which vulnerabilities
+    are actually exploitable
+  - [Build provenance](security-concepts/provenance.md) that proves how and where
+    the image was built
+
+- Compatibility-focused design: Docker Hardened Images provide a minimal runtime
+  environment while maintaining compatibility with common Linux distributions.
+  They remove non-essential components like shells and package managers to
+  enhance security, yet retain a small base layer built on familiar distribution
+  standards. Images are typically available with musl libc (Alpine-based) and
+  glibc (Debian-based), supporting a broad range of application compatibility
+  needs.
+
+## Why use Docker Hardened Images?
+
+Docker Hardened Images (DHIs) are secure by default, minimal by design, and
+maintained so you don't have to. They offer:
+
+
+- Images built for peace of mind: Ultra-minimal and distroless, DHIs eliminate up to 95% of the traditional container attack surface.
+- No more patch panic: With continuous CVE scanning and [SLA-backed remediation](https://docs.docker.com/go/dhi-sla/), Docker helps you stay ahead of threats.
+- Audit-ready images: All DHIs include signed SBOMs, VEX, and provenance that support security and compliance workflows.
+- Images that work with your stack: Available in Alpine and Debian flavors, DHIs drop into your existing Dockerfiles and pipelines.
+- Images backed by enterprise support: Get peace of mind with Docker's support and rapid response to critical vulnerabilities.
diff --git a/content/manuals/dhi/get-started.md b/content/manuals/dhi/get-started.md
new file mode 100644
index 000000000000..00cedadc7135
--- /dev/null
+++ b/content/manuals/dhi/get-started.md
@@ -0,0 +1,153 @@
+---
+linktitle: Quickstart
+title: Docker Hardened Images quickstart
+description: Follow a quickstart guide to explore and run a Docker Hardened Image.
+weight: 2
+keywords: docker hardened images quickstart, run secure image
+---
+
+This guide shows you how to go from zero to running a Docker Hardened Image
+(DHI) using a real example. At the end, you'll compare the DHI to a standard
+Docker image to better understand the differences. While the steps use a
+specific image as an example, they can be applied to any DHI.
+
+This quickstart uses DHI Community images from `dhi.io`. You sign in with your
+Docker account, pull and run an image, and compare it with a Docker Official Image.
+
+> [!NOTE]
+>
+> If you have a DHI Select or Enterprise subscription, see [Get started with DHI
+> Select and Enterprise](./how-to/select-enterprise.md) instead. Select and
+> Enterprise use mirrored repositories in your organization namespace on Docker
+> Hub to enable customization, SLA-backed security updates, and access to
+> compliance variants.
+
+## Step 1: Find an image to use
+
+1. Go to the Hardened Images catalog in [Docker
+   Hub](https://hub.docker.com/hardened-images/catalog).
+2. Use the search bar or filters to find an image (for example, `python`,
+   `node`, or `golang`). For this example, search for `python`.
+3. Select the Python repository to view its details.
+
+Continue to the next step to pull and run the image. To dive deeper into searching
+and evaluating images, see [Search and evaluate Docker Hardened Images](./how-to/search-evaluate.md).
+
+## Step 2: Pull and run the image
+
+You can pull and run a DHI like any other Docker image. Note that Docker Hardened
+Images are designed to be minimal and secure, so they may not include all the
+tools or libraries you expect in a typical image. You can view the typical
+differences in [Considerations when adopting
+DHIs](./how-to/use.md#considerations-when-adopting-dhis).
+
+The following example demonstrates that you can run the Python image and execute
+a simple Python command just like you would with any other Docker image:
+
+1. Open a terminal and sign in to the Docker Hardened Images registry using your
+   Docker account credentials.
+
+   ```console
+   $ docker login dhi.io
+   ```
+
+   > [!TIP]
+   >
+   > If you don't have a Docker account, [create a free
+   > account](https://hub.docker.com/signup) to get started.
+
+2. Pull the image:
+
+   ```console
+   $ docker pull dhi.io/python:3.13
+   ```
+
+3. Run the image to confirm everything works:
+
+    ```console
+    $ docker run --rm dhi.io/python:3.13 python -c "print('Hello from DHI')"
+    ```
+
+    This starts a container from the `python:3.13` image and runs a simple
+    Python script that prints `Hello from DHI`.
+
+To dive deeper into using images, see:
+
+- [Use a Docker Hardened Image](./how-to/use.md) for general usage
+- [Use a Helm chart](./how-to/helm.md) for deploying with Helm
+
+## Step 3: Compare with other images
+
+You can quickly compare DHIs with other images to see the security
+improvements and differences. This comparison helps you understand the value of
+using hardened images.
+
+Run the following command to compare the Docker Hardened Image for Python with
+the non-hardened Docker Official Image for Python from Docker Hub. Look for the
+`## Overview` section in the output for a summary comparison.
+
+```console
+$ docker scout compare dhi.io/python:3.13 \
+    --to python:3.13 \
+    --platform linux/amd64 \
+    --ignore-unchanged
+```
+
+The `## Overview` section of the output looks similar to the following:
+
+```plaintext
+  ## Overview
+
+                      │                    Analyzed Image                     │               Comparison Image
+  ────────────────────┼───────────────────────────────────────────────────────┼───────────────────────────────────────────────
+    Target            │  dhi.io/python:3.13                                   │  python:3.13
+      digest          │  c215e9da9f84                                         │  7f48e892134c
+      tag             │  3.13                                                 │  3.13
+      platform        │ linux/amd64                                           │ linux/amd64
+      provenance      │ https://github.com/docker-hardened-images/definitions │ https://github.com/docker-library/python.git
+                      │  77a629b3d0db035700206c2a4e7ed904e5902ea8             │  3f2d7e4c339ab883455b81a873519f1d0f2cd80a
+      vulnerabilities │    0C     0H     0M     0L                            │    0C     1H     5M   141L     2?
+                      │           -1     -5   -141     -2                     │
+      size            │ 35 MB (-377 MB)                                       │ 412 MB
+      packages        │ 80 (-530)                                             │ 610
+                      │                                                       │
+```
+
+> [!NOTE]
+>
+> This is example output. Your results may vary depending on newly discovered
+> CVEs and image updates.
+
+Docker maintains near-zero CVEs in Docker Hardened Images. For DHI Select and
+Enterprise subscriptions, when new CVEs are discovered, the CVEs are remediated
+within the industry-leading SLA time frame. Learn more about the [SLA-backed
+security features](./_index.md#sla-backed-security).
+
+This comparison shows that the Docker Hardened Image:
+
+- Removes vulnerabilities: 1 high, 5 medium, 141 low, and 2 unspecified severity CVEs removed
+- Reduces size: From 412 MB down to 35 MB (91% reduction)
+- Minimizes packages: From 610 packages down to 80 (87% reduction)
+
+To dive deeper into comparing images see [Search and evaluate Docker Hardened Images](./how-to/search-evaluate.md#compare-and-evaluate-images).
+
+## What's next
+
+You've pulled and run your first Docker Hardened Image. Here are a few ways to keep going:
+
+- [Migrate existing applications to DHIs](./migration/migrate-with-ai.md): Use
+  Gordon to update your Dockerfiles to use Docker Hardened Images as the base.
+
+- [Start a trial](https://hub.docker.com/hardened-images/start-free-trial) to
+  explore the benefits of a DHI subscription, such as access to FIPS and STIG
+  variants, customized images, and SLA-backed updates.
+
+- [Get started with DHI Select and Enterprise](./how-to/select-enterprise.md):
+  After subscribing to a DHI subscription or starting a trial, learn how to
+  mirror repositories, customize images, and access compliance variants.
+
+- [Verify DHIs](./how-to/verify.md): Use tools like [Docker Scout](/scout/) or
+  Cosign to inspect and verify signed attestations, like SBOMs and provenance.
+
+- [Scan DHIs](./how-to/scan.md): Analyze the image with Docker Scout or other
+  scanners to identify known CVEs.
diff --git a/content/manuals/dhi/how-to/_index.md b/content/manuals/dhi/how-to/_index.md
new file mode 100644
index 000000000000..79c8d0af758d
--- /dev/null
+++ b/content/manuals/dhi/how-to/_index.md
@@ -0,0 +1,109 @@
+---
+title: How-tos
+description: Step-by-step guidance for working with Docker Hardened Images, from discovery to governance.
+weight: 20
+aliases:
+  - /dhi/how-to/manage/
+params:
+  grid_discover:
+    - title: Search and evaluate Docker Hardened Images
+      description: Learn how to find and compare image repositories, variants, and metadata in the DHI catalog.
+      icon: globe-alt
+      link: /dhi/how-to/search-evaluate/
+  grid_adopt:
+    - title: Get started with DHI Select and Enterprise
+      description: Learn how to mirror repositories, customize images, and access compliance variants with DHI Select and Enterprise subscriptions.
+      icon: rocket-launch
+      link: /dhi/how-to/select-enterprise/
+    - title: Mirror a Docker Hardened Image repository
+      description: Learn how to mirror an image into your organization's namespace and optionally push it to another private registry.
+      icon: arrows-right-left
+      link: /dhi/how-to/mirror/
+    - title: Customize a Docker Hardened Image or chart
+      description: Learn how to customize Docker Hardened Images and charts.
+      icon: cog-6-tooth
+      link: /dhi/how-to/customize/
+    - title: Use hardened system packages
+      description: Learn how to use Docker's hardened system packages in your images.
+      icon: archive-box
+      link: /dhi/how-to/hardened-packages/
+    - title: Use a Docker Hardened Image
+      description: Learn how to pull, run, and reference Docker Hardened Images in Dockerfiles, CI pipelines, and standard development workflows.
+      icon: play
+      link: /dhi/how-to/use/
+    - title: Use a Docker Hardened Image chart
+      description: Learn how to use a Docker Hardened Image chart.
+      icon: chart-bar
+      link: /dhi/how-to/helm/
+  grid_verify:
+    - title: Verify a Docker Hardened Image or chart
+      description: Use Docker Scout or cosign to verify signed attestations like SBOMs, provenance, and vulnerability data for Docker Hardened Images and charts.
+      icon: check-circle
+      link: /dhi/how-to/verify/
+    - title: Scan Docker Hardened Images
+      description: Learn how to scan Docker Hardened Images for known vulnerabilities using Docker Scout, Grype, or Trivy.
+      icon: bug-ant
+      link: /dhi/how-to/scan/
+    - title: Query VEX for a Docker Hardened Image
+      description: Use the DHI GraphQL API to fetch VEX statements and suppressed CVEs for a Docker Hardened Image by digest, at scale.
+      icon: bug-ant
+      link: /dhi/how-to/vex-api/
+  grid_govern:
+    - title: Apply Docker Hardened Image policies to your images
+      description: Learn how to hold your own images to Docker Hardened Image security and compliance standards using the Docker Scout CLI.
+      icon: shield-check
+      link: /dhi/how-to/policies/
+  grid_troubleshoot:
+    - title: Troubleshoot
+      description: Resolve common issues when building, running, or debugging Docker Hardened Images, such as non-root behavior, missing shells, and port access.
+      icon: question-mark-circle
+      link: /dhi/how-to/troubleshoot/
+---
+
+This section provides practical, task-based guidance for working with Docker
+Hardened Images (DHIs). Whether you're evaluating DHIs for the first time or
+integrating them into a production CI/CD pipeline, these topics cover the key
+tasks across the adoption journey: discover, adopt, verify, and govern.
+
+The topics are organized around the typical lifecycle of working with DHIs, but
+you can use them as needed based on your specific workflow.
+
+Explore the topics below that match your current needs.
+
+## Discover
+
+Explore available images and metadata in the DHI catalog.
+
+{{< grid
+  items="grid_discover"
+>}}
+
+## Adopt
+
+Mirror trusted images, customize as needed, and integrate into your workflows.
+
+{{< grid
+  items="grid_adopt"
+>}}
+
+## Verify
+
+Check signatures, SBOMs, and provenance, and scan for vulnerabilities.
+
+{{< grid
+  items="grid_verify"
+>}}
+
+## Govern
+
+Enforce policies to maintain security and compliance.
+
+{{< grid
+  items="grid_govern"
+>}}
+
+## Troubleshoot
+
+{{< grid
+  items="grid_troubleshoot"
+>}}
diff --git a/content/manuals/dhi/how-to/build.md b/content/manuals/dhi/how-to/build.md
new file mode 100644
index 000000000000..d8b4f141c9a2
--- /dev/null
+++ b/content/manuals/dhi/how-to/build.md
@@ -0,0 +1,843 @@
+---
+title: Create and build a Docker Hardened Image
+linktitle: Create and build an image
+description: Learn how to write a DHI definition file and build your own Docker Hardened Image from the declarative YAML schema.
+keywords: hardened images, DHI, build, yaml, security, sbom, provenance, declarative, catalog, definition file
+weight: 26
+---
+
+Docker Hardened Images (DHI) are built from declarative YAML definition files
+instead of traditional Dockerfiles. A single YAML file describes exactly what
+goes into an image: packages, users, environment variables, entrypoint, and
+metadata. The DHI build system produces a signed image containing only the required
+packages, with a Software Bill of Materials (SBOM) and SLSA Build Level 3
+provenance.
+
+This page explains how to write a DHI definition file, build images locally, and
+use advanced patterns such as build stages, third-party repositories, file
+paths, and dev variants.
+
+> [!IMPORTANT]
+>
+> The DHI build system pulls base images and build tools from `dhi.io`, so you
+> must authenticate to that registry before building a definition file. Use your
+> Docker ID credentials (the same username and password you use for Docker Hub)
+> when signing in.
+>
+> Run `docker login dhi.io` to authenticate.
+
+## How DHI builds differ from Dockerfiles
+
+A Dockerfile is a sequence of imperative instructions: `RUN`, `COPY`, `FROM`.
+A DHI definition file is a declarative specification. You describe the desired
+state of the image, and the build system figures out how to produce it.
+
+Every DHI definition starts with a syntax directive that tells BuildKit which
+DHI build frontend to use. The frontend is the component that parses and
+processes YAML definitions instead of the default Dockerfile parser:
+
+```yaml
+# syntax=dhi.io/build:2-alpine3.23
+```
+
+The frontend version corresponds to the base distribution:
+
+| Distribution        | Syntax directive                       |
+|---------------------|----------------------------------------|
+| Alpine 3.22         | `# syntax=dhi.io/build:2-alpine3.22`  |
+| Alpine 3.23         | `# syntax=dhi.io/build:2-alpine3.23`  |
+| Alpine 3.24         | `# syntax=dhi.io/build:2-alpine3.24`  |
+| Debian 12 (Bookworm)| `# syntax=dhi.io/build:2-debian12`    |
+| Debian 13 (Trixie)  | `# syntax=dhi.io/build:2-debian13`    |
+
+The DHI build system reads the YAML, resolves packages from the specified
+repositories, assembles the filesystem, creates user accounts, sets metadata,
+and produces a signed OCI image.
+
+## Explore the catalog for reference
+
+The [DHI catalog repository](https://github.com/docker-hardened-images/catalog)
+is open source under Apache 2.0 and contains every official image definition.
+Studying existing definitions is the best way to learn the YAML patterns for
+different image types.
+
+The catalog follows this directory structure:
+
+```text
+catalog/
+├── image/
+│   ├── alpine-base/
+│   │   ├── alpine-3.23/
+│   │   │   ├── 3.23.yaml            # runtime variant
+│   │   │   └── 3.23-dev.yaml        # dev variant
+│   │   ├── guides.md
+│   │   ├── info.yaml
+│   │   ├── logo.svg
+│   │   └── overview.md
+│   ├── nginx/
+│   │   ├── alpine-3.22/
+│   │   ├── alpine-3.23/
+│   │   │   ├── mainline.yaml
+│   │   │   ├── mainline-dev.yaml
+│   │   │   ├── stable.yaml
+│   │   │   └── stable-dev.yaml
+│   │   ├── debian-12/
+│   │   ├── debian-13/
+│   │   ├── bin/
+│   │   ├── guides.md
+│   │   ├── info.yaml
+│   │   ├── logo.svg
+│   │   └── overview.md
+│   └── redis/
+│       ├── debian-13/
+│       │   ├── 8.0.yaml              # runtime
+│       │   ├── 8.0-dev.yaml          # dev
+│       │   ├── 8.0-compat.yaml       # compat runtime
+│       │   └── 8.0-compat-dev.yaml   # compat dev
+│       ├── guides.md
+│       ├── info.yaml
+│       ├── logo.svg
+│       └── overview.md
+├── chart/
+└── package/
+```
+
+Each image organizes its variants by distribution. Images support multiple
+variant types:
+
+- A `runtime` variant is minimal and typically runs as a non-root user.
+- A `dev` variant adds a shell, package manager, and development tools.
+- A compatibility variant adds common shell utilities such as `bash`,
+  `coreutils`, `grep`, and `sed` for use with existing workflows. Compatibility
+  images use the `flavor: compat` field alongside a `runtime` or `dev` variant.
+- A compatibility-dev variant combines the compatibility packages with dev
+  tools.
+
+Some images also support additional flavors such as `sfw` (software framework)
+variants. Refer to the catalog for the full list of available variants for each
+image.
+
+## Try it: build a catalog image
+
+Before writing your own definition, try building an existing catalog image
+directly from GitHub:
+
+```console
+$ docker buildx build \
+    https://raw.githubusercontent.com/docker-hardened-images/catalog/refs/heads/main/image/alpine-base/alpine-3.23/3.23.yaml \
+    --sbom=generator=dhi.io/scout-sbom-indexer:1 \
+    --provenance=1 \
+    --tag my-alpine-base:3.23 \
+    --load
+```
+
+This downloads the definition file directly from GitHub and builds it locally.
+After the build completes, verify the image:
+
+```console
+$ docker images my-alpine-base
+```
+
+To modify an image, clone the catalog and edit the YAML files locally:
+
+```console
+$ git clone https://github.com/docker-hardened-images/catalog.git
+$ cd catalog
+```
+
+## YAML schema reference
+
+The following sections describe the fields available in a DHI definition file.
+
+### Required fields
+
+Every definition must include these top-level fields:
+
+| Field       | Description                                                         |
+|-------------|---------------------------------------------------------------------|
+| `name`      | Human-readable name for the image.                                  |
+| `image`     | Full registry path, such as `dhi.io/my-image`.                      |
+| `variant`   | Image variant type: `runtime` or `dev`.                             |
+| `tags`      | List of image tags.                                                 |
+| `platforms`  | Target architectures, such as `linux/amd64` and `linux/arm64`.     |
+| `contents`  | Package repositories and packages to install.                       |
+
+### Image metadata
+
+These fields add metadata to the image:
+
+| Field         | Description                                                       |
+|---------------|-------------------------------------------------------------------|
+| `os-release`  | Defines the `/etc/os-release` contents inside the image.          |
+| `annotations` | OCI image annotations such as description and license.            |
+| `dates`       | Release date and end-of-life date.                                |
+| `vars`        | Build-time variables for templating.                              |
+| `flavor`      | Image flavor modifier, such as `compat` for compatibility images.|
+
+### Container configuration
+
+These fields control how the container runs:
+
+| Field         | Description                                                       |
+|---------------|-------------------------------------------------------------------|
+| `accounts`    | Users, groups, and the `run-as` user.                             |
+| `environment` | Environment variables.                                            |
+| `entrypoint`  | Container entrypoint command.                                     |
+| `cmd`         | Default command arguments.                                        |
+| `work-dir`    | Working directory inside the container.                           |
+| `volumes`     | Volume mount points.                                              |
+| `ports`       | Exposed network ports.                                            |
+| `paths`       | Directories, files, and symlinks to create.                       |
+
+### Advanced fields
+
+These fields support more complex build patterns:
+
+| Field                | Description                                                  |
+|----------------------|--------------------------------------------------------------|
+| `contents.builds`    | Build stages with shell pipelines.                           |
+| `contents.keyring`   | Signing keys for third-party package repositories.           |
+| `contents.artifacts` | Pre-built OCI artifacts to include.                          |
+| `contents.mappings`  | Package URL (purl) mappings for SBOM accuracy.               |
+| `contents.files`     | Source files fetched from Git URLs with checksums.            |
+
+## Create a minimal image
+
+Start with the simplest possible definition: an Alpine base image with a
+non-root user.
+
+Create a directory for your project and add a file called `base.yaml`:
+
+```yaml
+# syntax=dhi.io/build:2-alpine3.23
+
+name: My Base Image
+image: my-registry/my-base
+variant: runtime
+tags:
+  - "1.0.0"
+  - "1.0"
+platforms:
+  - linux/amd64
+  - linux/arm64
+
+contents:
+  repositories:
+    - https://dl-cdn.alpinelinux.org/alpine/v3.23/main
+    - https://dl-cdn.alpinelinux.org/alpine/v3.23/community
+  packages:
+    - alpine-baselayout-data
+    - busybox
+    - ca-certificates-bundle
+
+accounts:
+  run-as: nonroot
+  users:
+    - name: nonroot
+      uid: 65532
+      gid: 65532
+  groups:
+    - name: nonroot
+      gid: 65532
+      members:
+        - nonroot
+
+os-release:
+  name: Docker Hardened Images (Alpine)
+  id: alpine
+  version-id: "3.23"
+  pretty-name: My Hardened Image
+  home-url: https://docker.com/products/hardened-images/
+  bug-report-url: https://docker.com/support/
+
+environment:
+  SSL_CERT_FILE: /etc/ssl/certs/ca-certificates.crt
+
+annotations:
+  org.opencontainers.image.description: A minimal Alpine base image
+
+cmd:
+  - /bin/sh
+```
+
+In this definition:
+
+- `contents.repositories` uses full URLs to Alpine package mirrors.
+- `contents.packages` lists exact Alpine package names.
+- The `accounts` block creates a `nonroot` user (UID 65532) and sets it as the
+  default user for the container.
+- The `os-release` block defines what appears in `/etc/os-release`. Always
+  include `bug-report-url` alongside `home-url`.
+- The `annotations` block adds OCI metadata visible in registries and Docker
+  Scout reports.
+
+Build the image:
+
+```console
+$ docker buildx build . -f base.yaml \
+    --sbom=generator=dhi.io/scout-sbom-indexer:1 \
+    --provenance=1 \
+    --tag my-base:latest \
+    --load
+```
+> [!NOTE]
+>
+> The `tags` field in the spec file defines the image metadata (variant and
+> version labels embedded in the image manifest). The `--tag` flag on the CLI
+> sets the OCI image reference used to push or load the image. These serve
+> different purposes - the spec file tags describe *what the image is*, while
+> the CLI tag determines *where it's stored*.
+
+## Use a Debian base with third-party repositories
+
+For applications that require Debian packages or third-party APT repositories,
+use the Debian syntax directive. The following example builds a Redis image
+from the official Redis APT repository.
+
+Create a file called `redis.yaml`:
+
+```yaml
+# syntax=dhi.io/build:2-debian13
+
+name: Redis 8.0.x
+image: my-registry/my-redis
+variant: runtime
+tags:
+  - "8.0"
+  - "8.0.5"
+platforms:
+  - linux/amd64
+  - linux/arm64
+
+contents:
+  repositories:
+    - deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb trixie main
+  keyring:
+    - https://packages.redis.io/gpg
+  packages:
+    - '!libelogind0'
+    - '!mawk'
+    - '!original-awk'
+    - base-files
+    - libpcre2-8-0
+    - libssl3t64
+    - libstdc++6
+    - libsystemd0
+    - redis=6:8.0.5-1rl1~trixie1
+    - redis-server=6:8.0.5-1rl1~trixie1
+    - redis-tools=6:8.0.5-1rl1~trixie1
+    - tini
+  mappings:
+    redis: pkg:deb/redis/redis@6:8.0.5-1rl1~trixie1?os_name=debian&os_version=13
+    redis-server: pkg:deb/redis/redis-server@6:8.0.5-1rl1~trixie1?os_name=debian&os_version=13
+    redis-tools: pkg:deb/redis/redis-tools@6:8.0.5-1rl1~trixie1?os_name=debian&os_version=13
+
+accounts:
+  run-as: nonroot
+  users:
+    - name: nonroot
+      uid: 65532
+      gid: 65532
+  groups:
+    - name: nonroot
+      gid: 65532
+      members:
+        - nonroot
+
+os-release:
+  name: Docker Hardened Images (Debian)
+  id: debian
+  version-id: "13"
+  version-codename: trixie
+  pretty-name: Docker Hardened Images/Debian GNU/Linux 13 (trixie)
+  home-url: https://docker.com/products/hardened-images/
+  bug-report-url: https://docker.com/support/
+
+work-dir: /data
+
+environment:
+  REDIS_VERSION: 8.0.5
+
+annotations:
+  org.opencontainers.image.description: A minimal Redis image
+  org.opencontainers.image.licenses: AGPL-3.0-only
+
+entrypoint:
+  - /usr/bin/tini
+  - --
+
+cmd:
+  - redis-server
+  - /etc/redis/redis.conf
+  - --include
+  - /etc/redis/conf.d/*.conf
+```
+
+This example introduces several patterns:
+
+- **Third-party repositories**: The `repositories` field uses the Debian
+  `deb [signed-by=...] URL suite component` format for APT sources.
+- **Keyring**: The `keyring` field downloads the GPG key used to verify packages
+  from the third-party repository.
+- **Package exclusions**: Prefix a package name with `!` to explicitly exclude
+  it. This prevents unwanted dependencies from being installed. In this case,
+  `!libelogind0`, `!mawk`, and `!original-awk` are excluded.
+- **Debian version pinning**: Use the full epoch format,
+  `redis-server=6:8.0.5-1rl1~trixie1`, to pin exact package versions.
+- **SBOM mappings**: The `mappings` field provides Package URL (purl) metadata
+  so that Docker Scout can accurately identify the software in the SBOM.
+- **Init process**: The `entrypoint` uses `tini` as a lightweight init process
+  (PID 1) to handle signal forwarding and zombie process reaping.
+- **Config includes**: The `cmd` uses `--include /etc/redis/conf.d/*.conf` so
+  that configuration files created in the `paths` section are loaded at startup.
+
+## Create paths
+
+Use the `paths` field to create directories, files with inline content, and
+symlinks inside the image. The following example extends the Redis definition
+with the paths required for operation:
+
+```yaml
+paths:
+  - type: directory
+    path: /var/lib/redis
+    uid: 65532
+    gid: 65532
+    mode: "0755"
+  - type: directory
+    path: /var/log/redis
+    uid: 65532
+    gid: 65532
+    mode: "0755"
+  - type: directory
+    path: /run/redis/
+    uid: 65532
+    gid: 65532
+    mode: "0755"
+  - type: directory
+    path: /data
+    uid: 65532
+    gid: 65532
+    mode: "0755"
+  - type: file
+    path: /etc/redis/conf.d/docker.conf
+    content: |
+      daemonize no
+      bind 0.0.0.0 -::1
+      logfile ""
+    uid: 0
+    gid: 0
+    mode: "0555"
+  - type: symlink
+    path: /usr/bin/redis-sentinel
+    uid: 0
+    gid: 0
+    source: /usr/bin/redis-check-rdb
+```
+
+Three path types are available:
+
+| Type        | Required fields                  | Description                          |
+|-------------|----------------------------------|--------------------------------------|
+| `directory` | `path`, `uid`, `gid`, `mode`     | Creates an empty directory.          |
+| `file`      | `path`, `content`, `uid`, `gid`, `mode` | Creates a file with inline content. |
+| `symlink`   | `path`, `source`, `uid`, `gid`   | Creates a symbolic link.             |
+
+The `mode` field uses a string representation of the octal permission bits,
+such as `"0755"` for read-write-execute by owner or `"0555"` for read-execute
+by all. Note that the `file` type supports inline `content` using a YAML
+multi-line string.
+
+## Add build stages
+
+For images that need to run shell commands during the build, such as
+configuring files, creating symlinks, or adjusting permissions, use the
+`contents.builds` field. Each build stage has its own packages, a pipeline
+of named steps, and output mappings.
+
+The following example configures Nginx during the build to run on an
+unprivileged port and disable server tokens:
+
+```yaml
+# syntax=dhi.io/build:2-alpine3.23
+
+name: Nginx mainline
+image: my-registry/my-nginx
+variant: runtime
+tags:
+  - "1.29"
+platforms:
+  - linux/amd64
+  - linux/arm64
+
+contents:
+  repositories:
+    - https://dl-cdn.alpinelinux.org/alpine/v3.23/main
+    - https://dl-cdn.alpinelinux.org/alpine/v3.23/community
+    - http://nginx.org/packages/mainline/alpine/v3.23/main
+  keyring:
+    - https://nginx.org/keys/nginx_signing.rsa.pub
+  packages:
+    - alpine-baselayout-data
+    - busybox
+    - musl-utils
+    - nginx=1.29.5-r1
+  builds:
+    - name: nginx
+      contents:
+        repositories:
+          - https://dl-cdn.alpinelinux.org/alpine/v3.23/main
+          - https://dl-cdn.alpinelinux.org/alpine/v3.23/community
+          - http://nginx.org/packages/mainline/alpine/v3.23/main
+        keyring:
+          - https://nginx.org/keys/nginx_signing.rsa.pub
+        packages:
+          - alpine-baselayout-data
+          - bash
+          - musl-utils
+          - nginx=1.29.5-r1
+      pipeline:
+        - name: install
+          runs: |
+            set -eux -o pipefail
+
+            ln -sf /dev/stdout /var/log/nginx/access.log
+            ln -sf /dev/stderr /var/log/nginx/error.log
+
+            sed -i "s,listen       80;,listen       8080;," /etc/nginx/conf.d/default.conf
+            sed -i "/user  nginx;/d" /etc/nginx/nginx.conf
+            sed -i "s,pid        /run/nginx.pid;,pid        /var/run/nginx.pid;," /etc/nginx/nginx.conf
+            sed -i '/^http {$/a\    server_tokens off;' /etc/nginx/nginx.conf
+
+            chown -R 65532:65532 /var/cache/nginx
+            chmod -R g+w /var/cache/nginx
+            chown -R 65532:65532 /etc/nginx
+            chmod -R g+w /etc/nginx
+            chown -R 65532:65532 /run
+            chown -R 65532:65532 /run/lock
+            chown -R 65532:65532 /var/run
+            chown -R 65532:65532 /var/log/nginx
+      outputs:
+        - source: /
+          target: /
+          uid: 0
+          gid: 0
+          diff: true
+
+accounts:
+  run-as: nginx
+  users:
+    - name: nginx
+      uid: 65532
+      gid: 65532
+  groups:
+    - name: nginx
+      gid: 65532
+      members:
+        - nginx
+    - name: www-data
+      gid: 82
+
+os-release:
+  name: Docker Hardened Images (Alpine)
+  id: alpine
+  version-id: "3.23"
+  pretty-name: Docker Hardened Images/Alpine Linux v3.23
+  home-url: https://docker.com/products/hardened-images/
+  bug-report-url: https://docker.com/support/
+
+environment:
+  NGINX_VERSION: 1.29.5-r1
+
+annotations:
+  org.opencontainers.image.description: A minimal Nginx image
+  org.opencontainers.image.licenses: BSD-2-Clause
+
+entrypoint:
+  - nginx
+
+cmd:
+  - -g
+  - daemon off;
+
+ports:
+  - 8080/tcp
+```
+
+Key patterns in this definition:
+
+| Element     | Description                                                                |
+|-------------|----------------------------------------------------------------------------|
+| `contents`  | Each build stage has its own `contents` section. Include packages needed only during the build, such as `bash`. |
+| `pipeline`  | Contains named steps that run shell commands. Always start scripts with `set -eux -o pipefail`. |
+| `outputs`   | Copies results from the build stage into the final image. Setting `diff: true` copies only files that changed, keeping the image minimal. |
+| `accounts`  | Nginx uses a dedicated `nginx` user (UID 65532) instead of `nonroot`. The `www-data` group (GID 82) is also created for web server compatibility. |
+| `musl-utils` | Required in both the main and build packages for Alpine-based Nginx images. |
+
+## Use OCI artifacts as package sources
+
+Instead of installing packages from Alpine or Debian repositories, you can pull
+pre-built binaries from DHI package artifacts. This is how the catalog builds
+images like Python and Node.js — the runtime is compiled separately and
+published as an OCI artifact, then referenced by digest in the image definition.
+
+Add the `artifacts` field under `contents`:
+
+```yaml
+contents:
+  repositories:
+    - https://dl-cdn.alpinelinux.org/alpine/v3.23/main
+    - https://dl-cdn.alpinelinux.org/alpine/v3.23/community
+  packages:
+    - alpine-baselayout-data
+    - bzip2
+    - ca-certificates-bundle
+    - expat
+    - gdbm
+    - libffi
+    - mpdecimal
+    - musl
+    - ncurses
+    - openssl
+    - readline
+    - sqlite-libs
+    - tzdata
+    - zlib
+  artifacts:
+    - name: dhi.io/pkg-python:3.13.12-alpine3.23@sha256:052b3b915055006a27c42470eed5c65d7ee92d2c3de47ecaedcc6bbd36077b95
+      includes:
+        - opt/**
+      uid: 0
+      gid: 0
+```
+
+| Field      | Description                                                                  |
+|------------|------------------------------------------------------------------------------|
+| `name`     | Full OCI reference with digest pin. Always use `@sha256:` for reproducibility. |
+| `includes` | Glob patterns for files to extract from the artifact. Paths are resolved from the filesystem root; `opt/**` includes everything under the `/opt` path. |
+| `excludes` | Glob patterns for files to skip. Useful for removing headers, docs, or unused binaries. |
+| `uid`, `gid` | Ownership for extracted files.                                             |
+
+Available DHI packages are in the
+[`package/`](https://github.com/docker-hardened-images/catalog/tree/main/package)
+directory of the catalog repository.
+
+## Create a dev variant
+
+A dev variant of an image adds a shell, package manager, and development tools.
+This is useful for debugging and for use as a build stage in multi-stage
+workflows.
+
+To create a dev variant, change the `variant` field and enable root access:
+
+```yaml
+# syntax=dhi.io/build:2-alpine3.23
+
+name: Alpine 3.23 Base (dev)
+image: my-registry/my-base
+variant: dev
+tags:
+  - "1.0-dev"
+platforms:
+  - linux/amd64
+  - linux/arm64
+
+contents:
+  repositories:
+    - https://dl-cdn.alpinelinux.org/alpine/v3.23/main
+    - https://dl-cdn.alpinelinux.org/alpine/v3.23/community
+  packages:
+    - alpine-baselayout-data
+    - apk-tools
+    - busybox
+    - ca-certificates-bundle
+
+accounts:
+  root: true
+  run-as: root
+  users:
+    - name: nonroot
+      uid: 65532
+      gid: 65532
+  groups:
+    - name: nonroot
+      gid: 65532
+      members:
+        - nonroot
+
+os-release:
+  name: Docker Hardened Images (Alpine)
+  id: alpine
+  version-id: "3.23"
+  pretty-name: Docker Hardened Images/Alpine Linux v3.23
+  home-url: https://docker.com/products/hardened-images/
+  bug-report-url: https://docker.com/support/
+
+environment:
+  SSL_CERT_FILE: /etc/ssl/certs/ca-certificates.crt
+
+annotations:
+  org.opencontainers.image.description: A minimal Alpine base image
+
+cmd:
+  - /bin/sh
+```
+
+The key differences from a runtime variant:
+
+- `variant: dev` instead of `variant: runtime`.
+- `accounts.root: true` enables the root account.
+- `run-as: root` sets root as the default user.
+- `apk-tools` is added to packages, giving the image a package manager.
+- The `nonroot` user is still defined so that applications can switch to an
+  unprivileged user at runtime.
+
+For Debian-based dev variants, add `apt` instead of `apk-tools` and include the
+`DEBIAN_FRONTEND: noninteractive` environment variable.
+
+## Create a compatibility variant
+
+A compatibility variant includes common shell utilities for use with
+scripts and automation tools that expect a standard Linux userland. Compatibility
+images use the `flavor` field:
+
+```yaml
+variant: runtime
+flavor: compat
+```
+
+A compatibility variant adds packages such as `bash`, `coreutils`, `findutils`,
+`grep`, `hostname`, `openssl`, `procps`, and `sed` alongside the application
+packages. A compatibility-dev variant combines both the compatibility packages
+and the dev tools:
+
+```yaml
+variant: dev
+flavor: compat
+```
+
+Refer to the Redis compatibility images in the catalog for a complete example of
+the compatibility pattern.
+
+## Set ports and volumes
+
+Use the `ports` field to declare which ports the container exposes. Always use
+unprivileged ports (higher than 1024) when the container runs as a non-root
+user.
+
+```yaml
+ports:
+  - 8080/tcp
+```
+
+Use the `volumes` field to declare volume mount points:
+
+```yaml
+volumes:
+  - /data
+```
+
+## Set annotations
+
+OCI annotations add machine-readable metadata to the image. Use the
+`annotations` field:
+
+```yaml
+annotations:
+  org.opencontainers.image.description: A minimal hardened application image
+  org.opencontainers.image.licenses: Apache-2.0
+```
+
+These annotations appear in Docker Scout reports and container registry
+interfaces.
+
+## Build and verify
+
+### Build the image
+
+Build a single-platform image for local testing:
+
+```console
+$ docker buildx build . -f my-image.yaml \
+    --sbom=generator=dhi.io/scout-sbom-indexer:1 \
+    --provenance=1 \
+    --tag my-image:latest \
+    --load
+```
+
+### Inspect the SBOM
+
+View the generated Software Bill of Materials:
+
+```console
+$ docker scout sbom my-image:latest
+```
+
+### Scan for vulnerabilities
+
+Check the image against known CVE databases:
+
+```console
+$ docker scout cves my-image:latest
+```
+
+### Compare with a non-hardened image
+
+Measure the security improvement against an equivalent non-hardened image:
+
+```console
+$ docker scout compare my-image:latest \
+    --to <non-hardened-equivalent>:<tag> \
+    --platform linux/amd64
+```
+
+Replace `<non-hardened-equivalent>` with the Docker Official Image or
+community image you're comparing against.
+
+### Inspect with Docker Debug
+
+Verify the os-release and entrypoint configuration:
+
+```console
+$ docker debug my-image:latest
+```
+
+The output shows the detected distribution name from your `os-release`
+configuration and runs an entrypoint lint check.
+
+## Push to a registry
+
+Tag and push the image to your container registry:
+
+```console
+$ docker tag my-image:latest <your-namespace>/my-image:latest
+```
+
+```console
+$ docker push <your-namespace>/my-image:latest
+```
+
+Replace `<your-namespace>` with your Docker Hub username or organization
+namespace.
+
+## Contribute to the catalog
+
+Docker Hardened Images is an open source project. You can contribute new image
+definitions or improve existing ones by submitting a pull request to the
+[catalog repository](https://github.com/docker-hardened-images/catalog).
+
+To contribute a new image:
+
+1. Fork the catalog repository.
+2. Create a directory under `image/` following the naming convention:
+   `image/<image-name>/<distribution>/`.
+3. Add your YAML definition files (one per variant).
+4. Add an `info.yaml` with display name, description, and categories.
+5. Add an `overview.md` describing the image.
+6. Add a `logo.svg` for the image icon.
+7. Add a `guides.md` with usage documentation.
+8. Open a pull request against the `main` branch.
+
+For more details, read the
+[contributing guide](https://github.com/docker-hardened-images/catalog/blob/main/CONTRIBUTING.md)
+in the catalog repository.
diff --git a/content/manuals/dhi/how-to/customize.md b/content/manuals/dhi/how-to/customize.md
new file mode 100644
index 000000000000..fbb17a2d4f89
--- /dev/null
+++ b/content/manuals/dhi/how-to/customize.md
@@ -0,0 +1,741 @@
+---
+title: Customize a Docker Hardened Image or chart
+linkTitle: Customize an image or chart
+weight: 25
+keywords: hardened images, DHI, customize, certificate, artifact, helm chart, terraform, infrastructure as code
+description: Learn how to customize Docker Hardened Images (DHI) and charts.
+toc_max: 4
+---
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+When you have a DHI Select or DHI Enterprise subscription, you can customize Docker
+Hardened Images (DHI) and charts to suit your specific needs using the Docker
+Hub web interface. For images, this lets you select a base image, add packages,
+add OCI artifacts (such as custom certificates or additional tools), and
+configure settings. For charts, this lets you customize the image references.
+
+Your customizations stay secure automatically. When the base Docker Hardened
+Image or chart receives a security patch or your OCI artifacts are updated,
+Docker automatically rebuilds your customizations in the background. This
+ensures continuous compliance and protection by default, with no manual work
+required. The rebuilt artifacts are signed and attested to the same SLSA Build
+Level 3 standard as the base images and charts, ensuring a secure and verifiable
+supply chain.
+
+## Customize a Docker Hardened Image
+
+To add a customized Docker Hardened Image to your organization, an organization
+owner must first [mirror](./mirror.md) the DHI repository to your organization
+on Docker Hub. Once the repository is mirrored, any user with access to the
+mirrored DHI repository can create a customized image.
+
+You can create customizations using either the DHI CLI or the Docker Hub web interface.
+
+{{< tabs >}}
+{{< tab name="Docker Hub" >}}
+
+1. Sign in to [Docker Hub](https://hub.docker.com).
+1. Select **My Hub**.
+1. In the namespace drop-down, select your organization that has a mirrored DHI
+   repository.
+1. Select **Hardened Images** > **Manage** > **Mirrored Images**.
+1. For the mirrored DHI repository you want to customize, select the menu icon in the far right column.
+1. Select **Customize**.
+
+   At this point, the on-screen instructions will guide you through the
+   customization process. You can continue with the following steps for more
+   details.
+
+1. Select one or more images or Helm charts and versions you want to customize.
+
+   When selecting multiple images and versions, all selections must share the
+   same distribution and distribution version. For example, you can select
+   `dhi-node:22_alpine3.23` and `dhi-python:3.13_alpine3.23` together (both
+   Alpine 3.23), but you cannot mix `dhi-node:22_debian` with Alpine images, or
+   mix different Alpine versions like `alpine3.23` and `alpine3.22`.
+
+   Alternatively, you can select multiple Helm chart versions to apply the same
+   customization to all of them. You cannot mix images and Helm charts in the
+   same customization.
+
+1. Select **Next**.
+1. Optional. Add packages.
+
+   1. In the packages drop-down, select the packages you want to add to the
+      image.
+
+      The packages available in the drop-down are OS system packages for the
+      selected image variant. For version 3.23 and later Alpine-based images,
+      these are hardened packages that have been built from source by Docker with
+      cryptographic signatures and full supply chain security. For version 3.22
+      Alpine-based images and Debian-based images, these are standard system
+      packages.
+
+   1. In the **OCI artifacts** drop-down, first, select the repository that
+      contains the OCI artifact image. Then, select the tag you want to use from
+      that repository. Finally, specify the specific paths you want to include
+      from the OCI artifact image.
+
+      The OCI artifacts are images that you have previously
+      built and pushed to a repository in the same namespace as the mirrored
+      DHI. For example, you can add a custom root CA certificate or another
+      image that contains a tool you need, like adding Python to a Node.js
+      image.
+
+      You can add multiple OCI artifact images to a single customization. When
+      you add more than one, they're applied in the order you add them in the
+      **OCI artifacts** drop-down. If multiple images contain directories or
+      files with the same path, images added later overwrite files from images
+      added earlier. To manage this, you must select paths to include and
+      optionally exclude from each OCI artifact image. This allows you to
+      control which files are included in the final customized image.
+
+      By default, no files are included from the OCI artifact image. You must
+      explicitly include the paths you want. After including a path, you can
+      then explicitly exclude files or directories underneath it.
+
+      > [!NOTE]
+      >
+      > When files necessary for runtime are overwritten by OCI artifacts, the
+      > image build still succeeds, but you may have issues when running the
+      > image.
+
+      For more details, see [OCI artifacts](#oci-artifacts).
+
+   1. In the **Scripts** section, you can add, edit, or remove scripts.
+
+      Scripts let you add files to the container image that you can access at runtime. They are not executed during
+      the build process. This is useful for services that require pre-start initialization, such as setup scripts or
+      file writes to directories like `/var/lock` or `/out`.
+
+      You must specify the following:
+
+      - The path where the script will be placed
+      - The script content
+      - The UID and GID ownership of the script
+      - The octal file permissions of the script
+
+1. Select **Next: Configure** to configure the following image settings:
+
+   > [!NOTE]
+   >
+   > When customizing multiple images at once, many of these configuration
+   > options are limited by default and may not be available.
+
+   1. Specify the [environment variables](/reference/dockerfile/#env) and their
+      values that the image will contain.
+   1. Add [labels](/reference/dockerfile/#label) to the image.
+   1. Add [annotations](/build/metadata/annotations/) to the image.
+   1. Specify the users to add to the image. When you add a user, a home
+      directory is automatically created for that user with 0755 permissions.
+   1. Specify the user groups to add to the image.
+   1. Select which [user](/reference/dockerfile/#user) to run the images as.
+   1. Add [`ENTRYPOINT`](/reference/dockerfile/#entrypoint) arguments to the
+      image. These arguments are appended to the base image's entrypoint.
+   1. Add [`CMD`](/reference/dockerfile/#cmd) arguments to the image. These
+      arguments are appended to the base image's command.
+   1. Override the default (`/`) [working
+      directory](/reference/dockerfile/#workdir) for the image.
+   1. Specify a suffix for the customization name that is appended to the
+      customized image's tag. For example, if you specify `custom` when
+      customizing the `dhi-python:3.13` image, the customized image will be
+      tagged as `dhi-python:3.13_custom`.
+   1. Select the compression format for the image layers. You can choose between
+      **ZSTD** (default) or **GZIP** compression. **ZSTD** typically provides
+      faster image pulls and better compression ratios, but may have
+      compatibility issues with older software. If you need compatibility with
+      older Docker versions, use **GZIP**.
+   1. Select the platforms you want to build the image for. You must select at
+      least one platform.
+
+1. Select **Next: Review customization**.
+
+1. Select **Create Customization**.
+
+   A summary of the customization appears. It may take some time for the image
+   to build. Once built, it will appear in the **Tags** tab of the repository,
+   and your team members can pull it like any other image.
+
+{{< /tab >}}
+{{< tab name="CLI" >}}
+
+Authenticate with `docker login` using your Docker credentials or a [personal
+access token (PAT)](../../security/access-tokens.md) with **Read & Write**
+permissions, or an [organization access token
+(OAT)](../../enterprise/security/access-tokens.md). When using an OAT, the
+available operations depend on the token's permission scope:
+
+- To list or get customizations, or to view build logs, the OAT must have read
+  (pull) access to the destination repository. Results are scoped to
+  repositories the OAT can access.
+- To create, update, or delete a customization, the OAT must have push access to
+  the destination repository. Bulk operations require push access to every
+  referenced destination repository.
+
+Use the [`docker dhi customization`](/reference/cli/docker/dhi/customization/) command:
+
+```console
+# Prepare a single customization scaffold
+$ docker dhi customization prepare golang 1.25 \
+  --org my-org \
+  --destination my-org/dhi-golang \
+  --name "golang with git" \
+  > my-customization.yaml
+
+# Prepare a bulk customization scaffold (pipe JSON array via stdin)
+$ echo '[{"destination":"my-org/dhi-golang","tag-definition-id":"golang/alpine-3.23/1.24-dev"}]' \
+  | docker dhi customization prepare --name "golang with git" --org my-org \
+  > my-customization.yaml
+
+# Create a customization
+$ docker dhi customization create my-customization.yaml --org my-org
+
+# List customizations
+$ docker dhi customization list --org my-org
+
+# Filter customizations by name, repository, or source
+$ docker dhi customization list --org my-org --filter git
+$ docker dhi customization list --org my-org --repo dhi-golang
+$ docker dhi customization list --org my-org --source golang
+
+# Get a customization by ID
+$ docker dhi customization get <id> --org my-org
+
+# Update a customization
+$ docker dhi customization edit my-customization.yaml --org my-org
+
+# Delete a customization by ID
+$ docker dhi customization delete <id> --org my-org
+
+# Delete without confirmation prompt
+$ docker dhi customization delete <id> --org my-org --force
+```
+
+For a complete reference of all YAML fields, see
+[Image customization YAML file](#image-customization-yaml-file).
+
+{{< /tab >}}
+{{< tab name="Terraform" >}}
+
+You can manage DHI customizations as infrastructure-as-code using the [DHI
+Terraform provider](/dhi/tools/terraform/). If you haven't configured the
+provider yet, see [DHI Terraform provider](/dhi/tools/terraform/) for setup
+instructions.
+
+Define a `dhi_customization` resource for each customization:
+
+```hcl
+resource "dhi_customization" "golang_with_git" {
+  repository = "dhi-golang"
+  name       = "golang with git"
+
+  contents {
+    packages = ["git", "curl"]
+  }
+
+  platform {
+    os           = "linux"
+    architecture = "amd64"
+  }
+}
+```
+
+The `dhi_customization` resource also supports optional configuration blocks
+for `accounts`, `files`, `labels`, `annotations`, `environment`, `entrypoint`,
+`cmd`, `user`, `workdir`, and `stop_signal`.
+
+Run `terraform apply` to create the customization.
+
+To edit a customization, update the resource configuration and run `terraform
+apply`. To delete a customization, remove the resource and run `terraform apply`.
+
+For the full list of resource attributes, see the [Terraform Registry
+documentation](https://registry.terraform.io/providers/docker-hardened-images/dhi/latest/docs/resources/customization).
+
+> [!NOTE]
+>
+> Monitoring customization builds is not available through the Terraform
+> provider. Use the Docker Hub web interface or the DHI CLI to monitor builds.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Image customization YAML file
+
+When using the CLI, customizations are defined in a YAML file. Use
+`docker dhi customization prepare` to generate a scaffold with all available
+fields and commented-out examples. Edit the file to describe what you want,
+then pass it to `docker dhi customization create`.
+
+The file has two parts: a preamble that identifies the customization and
+its targets, and a configuration section that specifies what to change.
+
+#### About the `id` field
+
+The `id` field is assigned automatically by Docker Hub when you run
+`docker dhi customization create`. When creating a new customization, omit
+`id` entirely. It is read-only.
+
+To find the ID of an existing customization, run:
+
+```console
+$ docker dhi customization list --org my-org
+```
+
+The `id` appears in the output and in files retrieved with
+`docker dhi customization get <id> --org my-org`. It lets
+`docker dhi customization edit` identify which customization to update.
+Scaffolds from `docker dhi customization prepare` do not include `id`, and
+that is expected.
+
+#### Set targets
+
+The `name` and `targets` fields are required in every customization file. The
+`targets` array specifies which image versions the customization applies to.
+Use a single entry for a single-image customization, or multiple entries for a
+bulk customization that applies the same configuration to several images at
+once.
+
+```yaml
+name: golang with git
+
+targets:
+  - destination: my-org/dhi-golang
+    tag_definition_id: golang/alpine-3.23/1.25
+```
+
+| Field | Description |
+|:---|:---|
+| `name` | Human-readable name. Converted to lowercase and hyphenated, it becomes the image tag suffix. For example, `golang with git` produces tags ending in `_golang-with-git`. |
+| `targets[].destination` | Destination repository in Docker Hub, such as `my-org/dhi-golang`. |
+| `targets[].tag_definition_id` | Tag definition to customize, such as `golang/alpine-3.23/1.25`. Use `docker dhi customization prepare` with tab completion to find valid values. |
+
+> [!NOTE]
+>
+> When `targets` has more than one entry, the fields `accounts`, `entrypoint`,
+> and `cmd` are not supported. Including them causes `docker dhi customization
+> create` to return an error.
+
+#### Add packages
+
+To install additional OS packages in your customized image, list them under
+`contents.packages`. Available packages depend on the base image variant.
+
+```yaml
+contents:
+  packages:
+    - git
+    - curl
+```
+
+#### Add OCI artifacts
+
+To layer additional files into your customized image, such as custom
+certificates, internal tools, or configuration files, list OCI artifact
+images under `contents.artifacts`.
+
+```yaml
+contents:
+  artifacts:
+    - name: my-org/my-certs:latest
+      includes:
+        - etc/ssl/certs
+      excludes:
+        - etc/ssl/certs/old
+```
+
+| Field | Description |
+|:---|:---|
+| `name` | Image reference of the OCI artifact. Must be in the same Docker Hub namespace as the mirrored DHI. |
+| `includes` | Paths to copy from the artifact. No files are included by default. You must list at least one path. |
+| `excludes` | Paths to exclude after applying `includes`. |
+
+To learn more about OCI artifacts, including how to create them, best
+practices, and how environment variables behave, see
+[OCI artifacts](#oci-artifacts).
+
+#### Inject files into the image
+
+To add static files at build time, such as configuration files or startup
+scripts, use the `paths` field. Files are added as static content and are not
+executed during the build.
+
+```yaml
+paths:
+  - path: /etc/myconfig
+    contents: |
+      key=value
+    mode: "0644"
+    uid: 0
+    gid: 0
+```
+
+| Field | Description |
+|:---|:---|
+| `path` | Absolute path where the file will be placed in the image. |
+| `contents` | File content. Use a YAML block scalar (`\|`) for multi-line content. |
+| `mode` | Octal file permissions, such as `"0644"`. Quote the value to prevent YAML from treating the leading zero as octal notation. |
+| `uid` | User ID of the file owner. |
+| `gid` | Group ID of the file owner. |
+
+#### Configure user accounts
+
+To add users or groups to the image, or to change which user the container
+runs as, use the `accounts` field.
+
+> [!NOTE]
+>
+> Not supported for bulk customizations (multiple `targets`).
+
+```yaml
+accounts:
+  root: true
+  runs-as: nonroot
+  users:
+    - name: nonroot
+      uid: 65532
+      gid: 65532
+  groups:
+    - name: nonroot
+      gid: 65532
+      members:
+        - nonroot
+```
+
+| Field | Description |
+|:---|:---|
+| `root` | Whether to enable the root user. Default is `false`. Required if `runs-as` is set to `root`. |
+| `runs-as` | The default user the container runs as. |
+| `users[].name` | Username. |
+| `users[].uid` | User ID. |
+| `users[].gid` | Primary group ID. Optional. |
+| `groups[].name` | Group name. |
+| `groups[].gid` | Group ID. |
+| `groups[].members` | Usernames to add to this group. Optional. |
+
+#### Set environment variables
+
+To add or override environment variables in the image, use the `environment`
+field. These are merged with the base image's existing environment and do not
+replace it.
+
+```yaml
+environment:
+  MY_VAR: my_value
+  DEBUG: "false"
+```
+
+Quote values that a YAML parser would interpret as non-string types, for
+example `"false"`, `"0"`, and `"null"`.
+
+#### Set labels and annotations
+
+To add OCI metadata to the image, use `labels` and `annotations`. Labels are
+stored in the image config; annotations are stored in the image manifest. Use
+[OCI standard keys](https://specs.opencontainers.org/image-spec/annotations/)
+where applicable.
+
+```yaml
+labels:
+  org.opencontainers.image.authors: your-email@example.com
+  org.opencontainers.image.version: "1.0.0"
+
+annotations:
+  org.opencontainers.image.title: Custom hardened image
+  org.opencontainers.image.description: Customized Docker Hardened Image
+```
+
+#### Override entrypoint and command
+
+To change how the container starts, use `entrypoint` and `cmd`. These arguments
+are appended to the base image's existing entrypoint and command.
+
+> [!NOTE]
+>
+> Not supported for bulk customizations (multiple `targets`).
+
+```yaml
+entrypoint:
+  - /docker-entrypoint.sh
+
+cmd:
+  - /bin/bash
+```
+
+#### Set platforms and compression
+
+To build for multiple architectures, list them under `platforms`. At least one
+platform is required.
+
+```yaml
+platforms:
+  - linux/amd64
+  - linux/arm64
+```
+
+To control layer compression, set `compression`. `ZSTD` (the default) offers
+better compression and faster pulls. Use `GZIP` for compatibility with older
+tooling.
+
+```yaml
+compression: ZSTD
+```
+
+## OCI artifacts
+
+In DHI customization, OCI artifacts are Docker images containing files you
+want to layer into your image, such as custom certificates, internal tools, or
+configuration files.
+
+### Create an OCI artifact image
+
+Keep artifact images as minimal as possible and include only the necessary
+files.
+
+For example, to distribute a custom root CA certificate as part of a trusted CA
+bundle, you can use a multi-stage build. This approach registers your
+certificate with the system and outputs an updated CA bundle, which can be
+extracted into a minimal final image:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+FROM dhi.io/bash:5-dev AS certs
+
+ENV DEBIAN_FRONTEND=noninteractive
+
+RUN mkdir -p /usr/local/share/ca-certificates/my-rootca
+COPY certs/rootCA.crt /usr/local/share/ca-certificates/my-rootca
+
+RUN update-ca-certificates
+
+FROM scratch
+COPY --from=certs /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
+```
+
+You can follow this pattern to create other OCI artifacts, such as images
+containing tools or libraries that you want to include in your customized DHI.
+Install the necessary tools or libraries in the first stage, and then copy the
+relevant files to the final stage that uses `FROM scratch`. This ensures that
+your OCI artifact is minimal and contains only the necessary files.
+
+In order for the OCI artifact to be available in a DHI customization, it must be built and
+pushed to a repository in the same namespace as the mirrored DHI repository.
+
+If you're customizing a DHI for multiple platforms (such as `linux/amd64` and
+`linux/arm64`), build your OCI artifact for all the platforms using the
+`--platform` flag:
+
+```console
+$ docker buildx build --platform linux/amd64,linux/arm64 \
+  -t <your-namespace>/my-oci-artifact:latest \
+  --push .
+```
+
+This creates a single image manifest that you can use for each platform. The
+customization build system automatically selects the correct platform variant
+when building each customized image.
+
+> [!IMPORTANT]
+>
+> The customization UI will only allow you to select platforms that are
+> available in all OCI artifacts you've added. If a platform is missing from
+> any OCI artifact, you won't be able to select that platform for your
+> customization.
+
+Once pushed to a repository in your organization's namespace, the OCI artifact
+automatically appears in the customization workflow when you select OCI
+artifacts to add to your customized Docker Hardened Image.
+
+### Environment variables
+
+When you include OCI artifacts in a customization, the environment variables
+defined in those artifacts are merged into the final image. The merge follows
+these rules:
+
+- Your customization's environment settings take precedence. An artifact's
+  variable is only applied if the corresponding key is absent or empty in your
+  customization.
+- `PATH` is an exception. Artifact `PATH` entries are added to the front of
+  the existing `PATH`, giving them runtime precedence.
+
+This differs from `COPY --from` in a Dockerfile, which copies files without
+inheriting environment variables from the source image. To avoid inheriting
+environment variables, build the artifact using a `FROM scratch` final stage.
+See [Create an OCI artifact image](#create-an-oci-artifact-image).
+
+### Best practices
+
+Follow these best practices when creating OCI artifacts for DHI customizations:
+
+- Use multi-stage builds: Build or install dependencies in a builder stage,
+  then copy only the necessary files to a `FROM scratch` final stage. This keeps
+  the OCI artifact minimal and avoids inheriting environment variables from the
+  builder image into your customization.
+
+- Include only essential files: OCI artifacts should contain only the files
+  you need to add to the customized image. Avoid including package managers,
+  shells, or other utilities that won't be used in the final image.
+
+- Match target platforms: Build your OCI artifact for all platforms you plan
+  to use in your customizations. Use `docker buildx build --platform` to create
+  multi-platform images when needed.
+
+- Use specific tags: Tag your OCI artifacts with specific versions or dates
+  (like `v1.0` or `20250101`) rather than relying solely on `latest`. This
+  ensures reproducible builds and makes it easier to track which artifacts are
+  used in which customizations.
+
+- Enable immutable tags: Consider enabling [immutable
+  tags](../../docker-hub/repos/manage/hub-images/immutable-tags.md) for your
+  OCI artifact repositories. This prevents accidental overwrites and ensures that
+  each version of your OCI artifact remains unchanged, improving reproducibility
+  and reliability of your customizations.
+
+## Customize a DHI Helm chart
+
+You can customize DHI Helm charts to meet your organization's specific needs.
+Via the Docker Hub web interface, you can modify the image references to
+reference mirrored images or customized images you've created. This lets you
+create a custom, securely-built chart with references to images stored in Docker
+Hub or other private registries. DHI securely packages customized Helm charts
+that reference your repositories, wherever they are stored, by default.
+
+To customize image references, an organization owner must [mirror](./mirror.md)
+the DHI chart repository to your organization on Docker Hub.
+
+You can create one chart customization per Helm chart repository. This is
+different from image customizations, where you can create multiple
+customizations per repository. If you need to make changes, you can edit your
+existing customization. Alternatively, you can mirror the same Helm chart
+repository again and add a new customization to the new mirror.
+
+> [!NOTE]
+>
+> You can customize Docker Hardened Image charts like any other Helm chart using
+> standard Helm tools and practices, such as a `values.yaml` file, outside of
+> Docker Hub. The following instructions describe how to customize image
+> references for the chart using the Docker Hub web interface.
+
+To customize a Docker Hardened Image Helm chart after it has been mirrored:
+
+1. Sign in to [Docker Hub](https://hub.docker.com).
+1. Select **My Hub**.
+1. In the namespace drop-down, select your organization that has a mirrored DHI
+   repository.
+1. Select **Hardened Images** > **Manage** > **Mirrored Helm charts**.
+1. For the mirrored DHI repository you want to customize, select the **Name**.
+1. Select the **Customizations** tab.
+1. Select **Create customization**.
+
+   At this point, the on-screen instructions will guide you through the
+   customization process.
+
+### Helm chart customization YAML file
+
+When using the CLI, Helm chart customizations use the same `prepare` / `create`
+workflow as image customizations, but the configuration section uses
+`reference_mappings` instead of image fields.
+
+Use `reference_mappings` to substitute image references within the chart, for
+example to point a chart's image references at your mirrored DHIs.
+
+```yaml
+name: use mirrored images
+
+targets:
+  - destination: my-org/dhi-haproxy-chart
+    tag_definition_id: haproxy/helm/1
+
+reference_mappings:
+  - from: dhi/haproxy
+    to: my-org/dhi-haproxy
+```
+
+| Field | Description |
+|:---|:---|
+| `reference_mappings[].from` | The image reference in the chart to replace. |
+| `reference_mappings[].to` | The replacement image reference, typically a mirrored DHI in your organization. |
+
+## Monitor customization builds
+
+After creating a customization, you can track build status and view logs
+through Docker Hub or the DHI CLI.
+
+{{< tabs >}}
+{{< tab name="Docker Hub" >}}
+
+1. Sign in to [Docker Hub](https://hub.docker.com).
+2. Select **My Hub**.
+3. In the namespace drop-down, select your organization.
+4. Select **Hardened Images** > **Manage**.
+5. Select the **Customizations** tab.
+
+{{< /tab >}}
+{{< tab name="CLI" >}}
+
+List builds for a customization:
+
+```console
+$ docker dhi customization build list <customization-id> --org my-org
+```
+
+Get details of a specific build:
+
+```console
+$ docker dhi customization build get <customization-id> <build-id> --org my-org
+```
+
+View build logs:
+
+```console
+$ docker dhi customization build logs <customization-id> <build-id> --org my-org
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Edit or delete a customization
+
+{{< tabs >}}
+{{< tab name="Docker Hub" >}}
+
+1. Sign in to [Docker Hub](https://hub.docker.com).
+2. Select **My Hub**.
+3. In the namespace drop-down, select your organization that has a mirrored repository.
+4. Select **Hardened Images** > **Manage**.
+5. Select **Customizations**.
+
+6. For the customized DHI repository you want to manage, select the menu icon in the far right column.
+   From here, you can:
+
+   - **Edit**: Edit the customization.
+   - **Create new**: Create a new customization based on the source repository.
+   - **Delete**: Delete the customization.
+
+7. Follow the on-screen instructions to complete the edit or deletion.
+
+{{< /tab >}}
+{{< tab name="CLI" >}}
+
+To edit a customization, update your YAML file and run:
+
+```console
+$ docker dhi customization edit my-customization.yaml --org my-org
+```
+
+The YAML file must include the `id` field to identify which customization to
+update. To find the ID, run `docker dhi customization list --org my-org`.
+
+To delete a customization by ID:
+
+```console
+$ docker dhi customization delete <id> --org my-org
+$ docker dhi customization delete <id> --org my-org --force
+```
+
+The `--force` flag skips the confirmation prompt.
+
+{{< /tab >}}
+{{< /tabs >}}
diff --git a/content/manuals/dhi/how-to/hardened-packages.md b/content/manuals/dhi/how-to/hardened-packages.md
new file mode 100644
index 000000000000..0cb0de1ebaa1
--- /dev/null
+++ b/content/manuals/dhi/how-to/hardened-packages.md
@@ -0,0 +1,443 @@
+---
+title: Use Hardened System Packages
+linkTitle: Use hardened packages
+weight: 32
+keywords: hardened images, DHI, hardened packages, packages, alpine, apk, debian, apt
+description: Learn how to use and verify Docker's hardened system packages in your images.
+---
+
+Docker Hardened System Packages are built from source by Docker. This ensures
+supply chain integrity throughout your entire image stack by eliminating risks
+from potentially compromised public packages.
+
+Access to hardened packages varies by subscription:
+
+- **DHI Community**: Includes hardened packages in base images. Can configure the
+  public package repository to access the same packages in custom images.
+- **DHI Select**: Includes all Community packages, plus access to additional
+  compliance-specific packages (such as FIPS variants) and Docker-patched
+  packages through the image customization UI.
+- **DHI Enterprise**: Includes all Select packages, plus the ability to configure
+  the enterprise package repository directly in your own images for full access
+  to compliance and security-patched packages.
+
+To browse the packages currently available in Docker's public hardened package
+repositories, see the following indexes:
+
+- [Debian package index](https://dhi.io/deb/debian/main/index.html)
+- [Alpine package index](https://dhi.io/apk/alpine/v3.24/main/index.html)
+
+Docker is constantly adding new hardened packages. If a package you need isn't
+available yet, you can [request it in the DHI catalog
+repository](https://github.com/docker-hardened-images/catalog/issues).
+
+## Built-in packages
+
+Supported distributions of Docker Hardened Images (DHI) automatically include
+hardened system packages. No additional configuration is required. Simply pull
+and use the images as normal.
+
+All packages in these images are built by Docker from source, maintaining
+the same security standards as the base images themselves.
+
+## Add hardened packages to your images
+
+You can add hardened packages to your own images in the following two ways.
+
+### Add packages through image customization
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+When customizing Docker Hardened Images with DHI Select or DHI Enterprise, you
+can add hardened packages for Alpine-based images through the customization
+interface. Follow the steps to [create an image
+customization](./customize.md#create-an-image-customization) and select hardened
+packages during the customization process.
+
+### Configure the package manager
+
+You can configure your package manager to pull from Docker's hardened package
+repositories. This lets you install hardened packages in your own images.
+
+#### Public repository
+
+To use Docker's public hardened package repository in your own images,
+configure your package manager in your Dockerfile to install the DHI signing
+key and add the DHI repository.
+
+The configuration process involves three steps:
+
+1. Install the [signing key](https://github.com/docker-hardened-images/keyring)
+2. Configure the package repository
+3. Update and install packages
+
+{{< tabs group="os" >}}
+{{< tab name="Alpine" >}}
+
+The following example shows how to configure the Alpine package manager in your
+Dockerfile to use Docker's public hardened package repository:
+
+```dockerfile
+FROM alpine:3.23
+
+# Install the signing key
+RUN cd /etc/apk/keys && \
+    wget https://dhi.io/keyring/dhi-apk@docker-0F81AD7700D99184.rsa.pub
+
+# Replace the default repositories with the hardened package repository
+RUN echo "https://dhi.io/apk/alpine/v3.23/main" > /etc/apk/repositories
+
+# Update and install packages
+RUN apk update && \
+    apk add libpng
+```
+
+Replace `3.23` with your Alpine version in both the base image tag and repository URL.
+Supported versions include Alpine 3.23 and 3.24.
+
+To verify the configuration, build and run the image:
+
+```console
+$ docker build -t myapp:latest .
+$ docker run -it myapp:latest sh
+```
+
+Inside the container, check the configured repositories:
+
+```console
+/ # cat /etc/apk/repositories
+https://dhi.io/apk/alpine/v3.23/main
+```
+
+This ensures all packages are installed from Docker's hardened repository.
+
+{{< /tab >}}
+{{< tab name="Debian" >}}
+
+The following example shows how to configure the Debian package manager in your
+Dockerfile to use Docker's public hardened package repository:
+
+```dockerfile
+FROM debian:trixie-slim
+
+# Install the signing key
+RUN apt-get update && apt-get install -y --no-install-recommends \
+    ca-certificates curl gnupg \
+    && rm -rf /var/lib/apt/lists/*
+RUN curl -fsSL https://dhi.io/keyring/dhi-deb-gpg.D46852F6925E9F71.key \
+    | gpg --dearmor -o /usr/share/keyrings/dhi-deb.gpg
+
+# Add the hardened package repository
+RUN echo "deb [signed-by=/usr/share/keyrings/dhi-deb.gpg] https://dhi.io/deb/debian/main trixie main" \
+    > /etc/apt/sources.list.d/dhi.list
+
+# Update and install packages
+RUN apt-get update && apt-get install -y jq \
+    && rm -rf /var/lib/apt/lists/*
+```
+
+To verify the configuration, build and run the image:
+
+```console
+$ docker build -t myapp:latest .
+$ docker run -it myapp:latest bash
+```
+
+Inside the container, check the configured repository:
+
+```console
+root@myapp:/# cat /etc/apt/sources.list.d/dhi.list
+deb [signed-by=/usr/share/keyrings/dhi-deb.gpg] https://dhi.io/deb/debian/main trixie main
+```
+
+When the DHI repository carries a hardened version of a package, `apt` prefers
+it over the upstream Debian version automatically. You can confirm this with
+`apt-cache policy <package>`, which shows a candidate with a `+dhi` or `dhi`
+version suffix sourced from `https://dhi.io/deb/debian/main`.
+
+Not every Debian package is available as a hardened system package. When a
+package is not in the DHI repository, `apt` transparently falls back to the
+upstream Debian mirrors configured in the base image.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+All packages installed from the Docker Hardened Images repository are built from
+source by Docker and include full provenance.
+
+#### Enterprise repository
+
+{{< summary-bar feature_name="Docker Hardened Images Enterprise" >}}
+
+With DHI Enterprise, you have access to an additional package
+repository that includes hardened packages for compliance variants such as FIPS,
+as well as additional security patches.
+
+The configuration process involves five steps:
+
+1. Install the [signing keys](https://github.com/docker-hardened-images/keyring)
+2. Configure the base package repository
+3. Add the enterprise security repository
+4. Configure package installation with authentication
+5. Build the image passing credentials as a secret using the DHI CLI
+
+{{< tabs group="os" >}}
+{{< tab name="Alpine" >}}
+
+The following example shows how to configure the Alpine package manager in your
+Dockerfile to use Docker's enterprise hardened package repository:
+
+```dockerfile
+FROM alpine:3.23
+
+# Install the signing key
+RUN cd /etc/apk/keys && \
+    wget https://dhi.io/keyring/dhi-apk@docker-0F81AD7700D99184.rsa.pub
+
+# Replace the default repositories with the hardened package repository
+RUN echo "https://dhi.io/apk/alpine/v3.23/main" > /etc/apk/repositories
+
+# Update and install the enterprise configuration package to add the security repository
+RUN apk update && \
+    apk add dhi-enterprise-conf
+
+# Install packages from the security repository with authentication
+RUN --mount=type=secret,id=http_auth \
+    HTTP_AUTH="$(cat /run/secrets/http_auth)" \
+    apk update && \
+    apk add openssl-fips
+```
+
+Build the image with authentication passed securely as a build secret:
+
+```console
+$ docker dhi auth apk > http_auth.txt
+$ docker build --secret id=http_auth,src=http_auth.txt -t myapp-enterprise:latest .
+$ rm http_auth.txt
+```
+
+The `--secret` flag securely mounts the authentication credentials during build
+without storing them in the image layers or metadata.
+
+{{< /tab >}}
+{{< tab name="Debian" >}}
+
+The following example shows how to configure the Debian package manager in your
+Dockerfile to use Docker's enterprise hardened package repository. Mount
+credentials at `/etc/apt/auth.conf.d/dhi.conf`; `apt` reads files in
+`/etc/apt/auth.conf.d/` automatically when they have mode `0600`:
+
+```dockerfile
+FROM debian:trixie-slim
+
+# Install the signing keys
+RUN apt-get update && apt-get install -y --no-install-recommends \
+    ca-certificates curl gnupg \
+    && rm -rf /var/lib/apt/lists/*
+RUN curl -fsSL https://dhi.io/keyring/dhi-deb-gpg.D46852F6925E9F71.key \
+    | gpg --dearmor -o /usr/share/keyrings/dhi-deb.gpg
+RUN curl -fsSL https://dhi.io/keyring/dhi-deb-sec-gpg.D46852F6925E9F71.key \
+    | gpg --dearmor -o /usr/share/keyrings/dhi-deb-sec.gpg
+
+# Add the hardened package repository and the enterprise security repository
+RUN echo "deb [signed-by=/usr/share/keyrings/dhi-deb.gpg] https://dhi.io/deb/debian/main trixie main" \
+    > /etc/apt/sources.list.d/dhi.list
+RUN echo "deb [signed-by=/usr/share/keyrings/dhi-deb-sec.gpg] https://dhi.io/deb/debian/security trixie main" \
+    > /etc/apt/sources.list.d/dhi-sec.list
+
+# Install packages from the security repository with authentication
+RUN --mount=type=secret,id=netrc,target=/etc/apt/auth.conf.d/dhi.conf,mode=0600 \
+    apt-get update && apt-get install -y openssl \
+    && rm -rf /var/lib/apt/lists/*
+```
+
+Build the image, passing credentials securely as a build secret through an
+environment variable:
+
+```console
+$ NETRC=$(docker dhi auth deb) docker build \
+    --secret id=netrc,env=NETRC \
+    -t myapp-enterprise:latest .
+```
+
+The `--secret id=netrc,env=NETRC` form securely mounts the authentication
+credentials during build without storing them in the image layers or metadata.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Verify packages
+
+Every hardened package is cryptographically signed and includes metadata that
+proves its provenance and build integrity. You can verify the signatures and
+view the metadata to ensure your packages come from Docker's trusted build
+infrastructure.
+
+### View package metadata
+
+To view information about a hardened package:
+
+{{< tabs group="os" >}}
+{{< tab name="Alpine" >}}
+
+```console
+$ apk info -L <package-name>
+```
+
+{{< /tab >}}
+{{< tab name="Debian" >}}
+
+```console
+$ dpkg -L <package-name>
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+This shows the files included in the package and its metadata.
+
+### Verify package signatures
+
+Hardened packages are cryptographically signed by Docker. When you install the
+signing keys and configure your package manager as described previously, the
+package manager automatically verifies signatures during installation.
+
+If a package fails signature verification, the package manager will refuse to
+install it, protecting you from tampered or compromised packages.
+
+### Build provenance and cryptographic verification
+
+Docker hardened packages are built by Docker's trusted infrastructure and include
+verifiable metadata and cryptographic signatures.
+
+To view this metadata for an installed package:
+
+{{< tabs group="os" >}}
+{{< tab name="Alpine" >}}
+
+```console
+$ apk info -a <package-name>
+```
+
+{{< /tab >}}
+{{< tab name="Debian" >}}
+
+```console
+$ apt-cache show <package-name>
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Or to view metadata for a package before installing:
+
+{{< tabs group="os" >}}
+{{< tab name="Alpine" >}}
+
+```console
+$ apk fetch --stdout <package-name> | tar -xzO .PKGINFO
+```
+
+{{< /tab >}}
+{{< tab name="Debian" >}}
+
+```console
+$ apt-get download <package-name>
+$ dpkg-deb -I <package-name>_*.deb
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+The package signing keys ensure that packages haven't been tampered with after
+being built. When you install the signing key and configure your package manager,
+all packages are automatically verified before installation.
+
+### Package attestations
+
+Each hardened package includes its own attestations, similar to [image
+attestations](./verify.md). These attestations provide provenance and build
+information for individual packages, allowing you to trace the supply chain down
+to the package level.
+
+You can retrieve package attestations by first extracting package information
+from the image's SLSA provenance, then using the package digest to access its
+attestations.
+
+#### Extract package information from image attestations
+
+To get provenance information for a specific package from an image's SLSA
+provenance attestation, you first need to retrieve the image's provenance and
+then filter for the specific package you're interested in.
+
+The SLSA provenance attestation includes a `materials` array that lists all
+build inputs, including packages. You can use `jq` to filter this array for a
+specific package:
+
+```console
+$ docker scout attest get dhi.io/golang:1.26-alpine3.23 \
+    --predicate-type https://slsa.dev/provenance/v0.2 | \
+    jq '.predicate.materials[] | select( .uri == "https://dhi.io/apk/alpine/v3.23/main/aarch64/golang-1.26-1.26.0-r0.apk" )'
+```
+
+Replace the package URI in the `select()` filter with the specific package
+you're looking for. You can find available packages by first running the command
+without the `select()` filter to see all materials.
+
+This returns the package URI and its SHA-256 digest:
+
+```json
+{
+  "uri": "https://dhi.io/apk/alpine/v3.23/main/aarch64/golang-1.26-1.26.0-r0.apk",
+  "digest": {
+    "sha256": "4082a2500abc2e7b8435f9398d3514d760044fa52ca3d10cf80015469124a838"
+  }
+}
+```
+
+#### List attestations for a package
+
+Using the package digest from the previous section, you can list all available
+attestations for that package:
+
+```console
+$ curl -s https://dhi.io/apk/alpine/v3.23/main/sha256:4082a2500abc2e7b8435f9398d3514d760044fa52ca3d10cf80015469124a838/attestations/list | jq .
+```
+
+This returns information about the package and its available attestations:
+
+```json
+{
+  "subject": {
+    "name": "pkg:apk/alpine/golang-1.26@1.26.0-r0?os_name=&os_version=",
+    "digest": {
+      "sha256": "4082a2500abc2e7b8435f9398d3514d760044fa52ca3d10cf80015469124a838"
+    }
+  },
+  "attestations": [
+    {
+      "predicate_type": "https://slsa.dev/provenance/v1",
+      "digest": {
+        "sha256": "97c919cf0edb27087739bbabeea4c1ef88d069cd41791476ba64b69280d63a32"
+      },
+      "url": "https://dhi.io/apk/alpine/v3.23/main/sha256:4082a2500abc2e7b8435f9398d3514d760044fa52ca3d10cf80015469124a838/attestations/sha256:97c919cf0edb27087739bbabeea4c1ef88d069cd41791476ba64b69280d63a32"
+    }
+  ]
+}
+```
+
+#### Retrieve package attestations
+
+To retrieve the actual attestation content, use the URL provided in the
+attestation list:
+
+```console
+$ curl -s https://dhi.io/apk/alpine/v3.23/main/sha256:4082a2500abc2e7b8435f9398d3514d760044fa52ca3d10cf80015469124a838/attestations/sha256:97c919cf0edb27087739bbabeea4c1ef88d069cd41791476ba64b69280d63a32 | jq .
+```
+
+This returns the full SLSA provenance attestation for the package, which
+includes information about how the package was built, its dependencies, and
+other build materials.
+
+You can continue this process recursively to trace the supply chain all the way
+down to the compiler and other build tools used to create the package.
diff --git a/content/manuals/dhi/how-to/helm.md b/content/manuals/dhi/how-to/helm.md
new file mode 100644
index 000000000000..0afdf0d80249
--- /dev/null
+++ b/content/manuals/dhi/how-to/helm.md
@@ -0,0 +1,126 @@
+---
+title: Use a Docker Hardened Image chart
+linktitle: Use a Helm chart
+description: Learn how to use a Docker Hardened Image chart.
+keywords: use hardened image, helm, k8s, kubernetes, dhi chart, chart
+weight: 31
+---
+
+Docker Hardened Image (DHI) charts are Docker-provided Helm charts built from upstream sources, designed for
+compatibility with Docker Hardened Images. These charts are available in the [DHI catalog on Docker Hub](https://hub.docker.com/hardened-images/catalog?types=helmChart).
+
+DHI charts incorporate multiple layers of supply chain security that aren't present in upstream charts:
+
+- SLSA Level 3 compliance: Each chart is built with SLSA Build Level 3 standards, including detailed build provenance
+- Software Bill of Materials (SBOMs): Comprehensive SBOMs detail all components referenced within the chart
+- Cryptographic signing: All associated metadata is cryptographically signed by Docker for integrity and authenticity
+- Hardened configuration: Charts automatically reference Docker Hardened Images for secure deployments
+- Tested compatibility: Charts are robustly tested to work out-of-the-box with Docker Hardened Images
+
+You can use a DHI chart like any other Helm chart stored in an OCI registry.
+When you have a Docker Hardened Images subscription, you can also customize DHI
+charts to reference customized images and mirrored repositories. The customized
+chart build pipeline ensures that your customizations are built securely, use
+the latest base charts, and include attestations.
+
+## Mirror a Helm chart and/or its images to a third-party registry
+
+If you want to mirror to your own third-party registry, you can follow the
+instructions in [Mirror a Docker Hardened Image repository](/dhi/how-to/mirror/) for either the
+chart, the image, or both.
+
+The same `regctl` tool that is used for mirroring container images can also be used for mirroring Helm charts, as Helm
+charts are OCI artifacts.
+
+For example:
+
+```console
+regctl image copy \
+    "${SRC_CHART_REPO}:${TAG}" \
+    "${DEST_REG}/${DEST_CHART_REPO}:${TAG}" \
+    --referrers \
+    --referrers-src "${SRC_ATT_REPO}" \
+    --referrers-tgt "${DEST_REG}/${DEST_CHART_REPO}" \
+    --force-recursive
+```
+
+## Create a Kubernetes secret for pulling images
+
+You need to create a Kubernetes secret for pulling images from `dhi.io`, Docker
+Hub, or your own registry. This is necessary because Docker Hardened Image
+repositories require authentication. If you mirror the images to your own
+registry, you still need to create this secret if the registry requires
+authentication.
+
+1. For `dhi.io` or Docker Hub, create a [personal access token
+   (PAT)](/security/access-tokens/) using your Docker account or an
+   [organization access token (OAT)](/enterprise/security/access-tokens/).
+   Ensure the token has at least read-only access to the Docker Hardened Image
+   repositories.
+2. Create a secret in Kubernetes using the following command. Replace `<your-secret-name>`, `<your-username>`,
+   `<your-personal-access-token>`, and `<your-email>` with your own values.
+
+   > [!NOTE]
+   >
+   > You need to create this secret in each Kubernetes namespace that uses a
+   > DHI. If you've mirror your DHIs to another registry, replace
+   > `dhi.io` with your registry's hostname. Replace
+   > `<your-username>`, `<your-access-token>`, and `<your-email>` with your own
+   > values. `<your-username>` is Docker ID if using a PAT or your organization
+   > name if using an OAT. `<your-secret-name>` is a name you choose for the
+   > secret.
+
+   ```console
+   $ kubectl create secret docker-registry <your-secret-name> \
+       --docker-server=dhi.io \
+       --docker-username=<your-username> \
+       --docker-password=<your-access-token> \
+       --docker-email=<your-email>
+   ```
+
+   For example:
+
+    ```console
+    $ kubectl create secret docker-registry dhi-pull-secret \
+        --docker-server=dhi.io \
+        --docker-username=docs \
+        --docker-password=dckr_pat_12345 \
+        --docker-email=moby@example.com
+   ```
+
+## Install a Helm chart
+
+To install a Helm chart from Docker Hardened Images:
+
+1. Sign in to the registry using Helm:
+
+   ```console
+   $ echo $ACCESS_TOKEN | helm registry login dhi.io --username <your-username> --password-stdin
+   ```
+
+    Replace `<your-username>` and set `$ACCESS_TOKEN`.
+
+2. Install the chart using `helm install`. Optionally, you can also use the `--dry-run` flag to test the installation without
+   actually installing anything.
+
+
+   ```console
+   $ helm install <release-name> oci://dhi.io/<helm-chart-repository> --version <chart-version> \
+     --set "imagePullSecrets[0].name=<your-secret-name>"
+   ```
+
+   Replace `<helm-chart-repository>` and `<chart-version>` accordingly. If the
+   chart is in your own registry or another repository, replace
+   `dhi.io/<helm-chart-repository>` with your own location. Replace
+   `<your-secret-name>` with the name of the image pull secret created
+   from [Create a Kubernetes secret for pulling images](#create-a-kubernetes-secret-for-pulling-images).
+
+## Customize a Helm chart
+
+You can customize Docker Hardened Image Helm charts to reference customized
+images and mirrored repositories. For more details, see [Customize Docker
+Hardened Images and charts](./customize.md).
+
+## Verify a Helm chart and view its attestations
+
+You can verify Helm charts. For more details, see [Verify Helm chart attestations](./verify.md#verify-helm-chart-attestations-with-docker-scout).
\ No newline at end of file
diff --git a/content/manuals/dhi/how-to/mirror.md b/content/manuals/dhi/how-to/mirror.md
new file mode 100644
index 000000000000..b942a01862a5
--- /dev/null
+++ b/content/manuals/dhi/how-to/mirror.md
@@ -0,0 +1,435 @@
+---
+title: Mirror a Docker Hardened Image repository
+linktitle: Mirror a repository
+description: Learn how to mirror an image into your organization's namespace and optionally push it to another private registry.
+weight: 20
+keywords: mirror docker image, private container registry, docker hub automation, webhook image sync, secure image distribution, internal registry, jfrog artifactory, harbor registry, amazon ecr, google artifact registry, github container registry, terraform, infrastructure as code
+---
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+Mirroring requires a DHI Select or Enterprise subscription. Without a
+subscription, you can pull Docker Hardened Images directly from `dhi.io` without
+mirroring. With a DHI Select or Enterprise subscription, you must mirror to your
+organization to get:
+
+- Compliance variants (FIPS-enabled or STIG-ready images)
+- Extended Lifecycle Support (ELS) variants (requires add-on)
+- Image or Helm chart customization
+- Air-gapped or restricted network environments
+- [SLA-backed security updates](https://docs.docker.com/go/dhi-sla/)
+
+## How to mirror
+
+This topic covers two types of mirroring for Docker Hardened Image (DHI)
+repositories:
+
+- [Mirror to your organization](#mirror-a-dhi-repository-to-your-organization):
+  Mirror a DHI repository to your organization's namespace on Docker Hub.
+
+- [Mirror to a third-party
+  registry](#mirror-a-dhi-repository-to-a-third-party-registry): Mirror a
+  repository to another container registry, such as Amazon ECR, Google Artifact
+  Registry, or a private Harbor instance.
+
+## Mirror a DHI repository to your organization
+
+Organization owners, editors, and members with a [custom role](../../enterprise/security/roles-and-permissions/custom-roles/_index.md)
+that includes the DHI mirroring permission can create, view, and manage mirrors.
+When using the CLI or Terraform, you can also mirror using an [organization
+access token (OAT)](../../enterprise/security/access-tokens.md) with the
+appropriate permission scopes, without requiring role-based access.
+
+When a member with a custom role that includes the DHI mirroring permission
+creates a mirror, Docker automatically creates and manages the
+`dhi-mirroring-admins` team in your organization, adds that member to it, and
+grants the team access to the new mirror. This lets the member manage mirrors
+they create without organization owner or editor access. Mirrors created by
+organization owners or editors don't use this team. Removing members from this
+team may affect their ability to view and manage mirrors.
+
+You can mirror image and chart repositories to your organization's namespace on
+Docker Hub. Mirroring makes the repositories available within your organization
+and lets you customize them for your environment:
+
+- Image repositories: Mirroring lets you customize images by adding packages,
+  OCI artifacts (such as custom certificates or additional tools), environment
+  variables, labels, and other configuration settings. For more details, see
+  [Customize a Docker Hardened Image](./customize.md#customize-a-docker-hardened-image).
+
+- Chart repositories: Mirroring lets you customize image references within
+  the chart. This is particularly useful when using customized images or when
+  you've mirrored images to a third-party registry and need the chart to
+  reference those custom locations. For more details, see [Customize a Docker
+  Hardened Helm chart](./customize.md#customize-a-docker-hardened-helm-chart).
+
+{{< tabs >}}
+{{< tab name="Docker Hub" >}}
+
+1. Go to [Docker Hub](https://hub.docker.com) and sign in.
+2. Select **My Hub**.
+3. In the namespace drop-down, select your organization.
+4. Select **Hardened Images** > **Catalog**.
+5. Select a DHI repository to view its details.
+6. Mirror the repository:
+    - To mirror an image repository, select **Use this image** > **Mirror
+      repository**, and then follow the on-screen instructions. If you have the ELS add-on, you can also
+      select **Enable support for end-of-life versions**.
+    - To mirror a Helm chart repository, select **Get Helm chart**, and then follow the on-screen instructions.
+
+It may take a few minutes for all the tags to finish mirroring.
+
+{{< /tab >}}
+{{< tab name="CLI" >}}
+
+Authenticate with `docker login` using your Docker credentials, a [personal
+access token (PAT)](../../security/access-tokens.md) with **Read & Write**
+permissions, or an [organization access token
+(OAT)](../../enterprise/security/access-tokens.md). When using an OAT, the
+available operations depend on the token's permission scope:
+
+- To list mirrored repositories, the OAT must have read (pull) access to the
+  relevant repositories. Results are scoped to repositories the OAT can access.
+- To create a mirror to an existing destination repository, the OAT must have
+  push access to that repository. To create a mirror to a new destination
+  repository that doesn't yet exist, the OAT must have org-wide repository
+  access (for example, `<org>/*` with pull or push). Repository-scoped access to
+  the future repository name is not sufficient.
+- To stop mirroring, the OAT must have push access to the relevant repository.
+- OATs with public repository read-only access cannot list or manage mirrored
+  repositories.
+
+Use the [`docker dhi mirror`](/reference/cli/docker/dhi/mirror/) command:
+
+```console
+$ docker dhi mirror start --org my-org \
+  dhi/golang,my-org/dhi-golang \
+  dhi/nginx,my-org/dhi-nginx \
+  dhi/prometheus-chart,my-org/dhi-prometheus-chart
+```
+
+Mirror with dependencies:
+
+```console
+$ docker dhi mirror start --org my-org dhi/golang,my-org/dhi-golang --dependencies
+```
+
+List mirrored images in your organization:
+
+```console
+$ docker dhi mirror list --org my-org
+```
+
+Filter mirrored images by name or type:
+
+```console
+$ docker dhi mirror list --org my-org --filter python
+$ docker dhi mirror list --org my-org --type image
+$ docker dhi mirror list --org my-org --type helm-chart
+```
+
+{{< /tab >}}
+{{< tab name="Terraform" >}}
+
+You can manage DHI mirrors as infrastructure-as-code using the [DHI Terraform
+provider](/dhi/tools/terraform/).
+
+Define a `dhi_mirror` resource for each repository you want to mirror:
+
+```hcl
+resource "dhi_mirror" "golang" {
+  source_namespace = "dhi"
+  source_name      = "golang"
+  destination_name = "dhi-golang"
+}
+
+resource "dhi_mirror" "nginx" {
+  source_namespace = "dhi"
+  source_name      = "nginx"
+  destination_name = "dhi-nginx"
+}
+```
+
+To enable Extended Lifecycle Support (ELS) variants, set the `els` attribute:
+
+```hcl
+resource "dhi_mirror" "golang" {
+  source_namespace = "dhi"
+  source_name      = "golang"
+  destination_name = "dhi-golang"
+  els              = true
+}
+```
+
+Run `terraform apply` to create the mirrors.
+
+For the full list of resource attributes, see the [Terraform Registry
+documentation](https://registry.terraform.io/providers/docker-hardened-images/dhi/latest/docs/resources/mirror).
+
+{{< /tab >}}
+{{< /tabs >}}
+
+After mirroring, the repository appears in your organization's repository list,
+prefixed by `dhi-`, and continues to receive updated images. It behaves like any
+other Docker Hub repository, so you can manage access and permissions, configure
+webhooks, and use other standard Hub features. See [Docker Hub
+repositories](/manuals/docker-hub/repos/_index.md) for details.
+
+### Stop mirroring a repository
+
+After you stop mirroring, the repository remains, but it no longer receives
+updates. You can still use the last images or charts that were mirrored.
+
+> [!NOTE]
+>
+> If you only want to stop mirroring ELS versions, you can clear the ELS
+> option in the mirrored repository's **Settings** tab.
+
+{{< tabs >}}
+{{< tab name="Docker Hub" >}}
+
+1. Go to [Docker Hub](https://hub.docker.com) and sign in.
+2. Select **My Hub**.
+3. In the namespace drop-down, select your organization that has access to DHI.
+4. Select **Hardened Images** > **Manage**.
+5. Select the **Mirrored Images** or **Mirrored Helm charts** tab.
+6. In the far right column of the repository you want to stop mirroring, select the menu icon.
+7. Select **Stop mirroring**.
+
+{{< /tab >}}
+{{< tab name="CLI" >}}
+
+Authenticate with `docker login` using your Docker credentials, a [personal
+access token (PAT)](../../security/access-tokens.md) with **Read & Write**
+permissions, or an [organization access token
+(OAT)](../../enterprise/security/access-tokens.md) with push access to the
+relevant repository.
+
+Use the [`docker dhi mirror`](/reference/cli/docker/dhi/mirror/) command:
+
+```console
+$ docker dhi mirror stop --org my-org dhi-golang
+```
+
+{{< /tab >}}
+{{< tab name="Terraform" >}}
+
+To stop mirroring, remove the `dhi_mirror` resource from your Terraform
+configuration and run `terraform apply`. The repository remains in your
+organization but no longer receives updates.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Mirror a DHI repository to a third-party registry
+
+After mirroring a DHI repository to your organization on Docker Hub, you can
+optionally mirror it to another container registry, such as Amazon ECR, Google
+Artifact Registry, GitHub Container Registry, or a private Harbor instance.
+
+You can use any standard workflow to mirror the image, such as the
+[Docker CLI](/reference/cli/docker/), [Docker Hub Registry
+API](/reference/api/registry/latest/), third-party registry tools, or CI/CD
+automation.
+
+However, to preserve the full security context, including attestations, you must
+also mirror its associated OCI artifacts. DHI repositories store the image
+layers on `dhi.io` (or `docker.io` for customized images) and the signed
+attestations in a separate registry (`registry.scout.docker.com`).
+
+To copy both, you can use [`regctl`](https://regclient.org/cli/regctl/), an
+OCI-aware CLI that supports mirroring images along with attached artifacts such
+as SBOMs, vulnerability reports, and SLSA provenance. For ongoing synchronization,
+you can use [`regsync`](https://regclient.org/cli/regsync/).
+
+### Automate syncing with webhooks
+
+To keep external registries or systems in sync with your mirrored Docker
+Hardened Images, and to receive notifications when updates occur, you can
+configure a [webhook](/docker-hub/repos/manage/webhooks/) on the mirrored
+repository in Docker Hub. A webhook sends a `POST` request to a URL you define
+whenever a new image tag is pushed or updated.
+
+For example, you might configure a webhook to call a CI/CD system at
+`https://ci.example.com/hooks/dhi-sync` whenever a new tag is mirrored. The
+automation triggered by this webhook can pull the updated image from Docker Hub
+and push it to an internal registry such as Amazon ECR, Google Artifact
+Registry, or GitHub Container Registry.
+
+Other common webhook use cases include:
+
+- Triggering validation or vulnerability scanning workflows
+- Signing or promoting images
+- Sending notifications to downstream systems
+
+#### Example webhook payload
+
+When a webhook is triggered, Docker Hub sends a JSON payload like the following:
+
+```json{collapse=true}
+{
+  "callback_url": "https://registry.hub.docker.com/u/exampleorg/dhi-python/hook/abc123/",
+  "push_data": {
+    "pushed_at": 1712345678,
+    "pusher": "trustedbuilder",
+    "tag": "3.13-alpine3.21"
+  },
+  "repository": {
+    "name": "dhi-python",
+    "namespace": "exampleorg",
+    "repo_name": "exampleorg/dhi-python",
+    "repo_url": "https://hub.docker.com/r/exampleorg/dhi-python",
+    "is_private": true,
+    "status": "Active",
+    ...
+  }
+}
+```
+
+### Example mirroring with `regctl`
+
+The following example shows how to mirror a specific tag of a Docker Hardened
+Image from Docker Hub to another registry, along with its associated
+attestations using `regctl`. You must [install
+`regctl`](https://github.com/regclient/regclient) first.
+
+The example assumes you have mirrored the DHI repository to your organization's
+namespace on Docker Hub as described in the previous section. You can apply the
+same steps to a non-mirrored image by updating the `SRC_ATT_REPO` and
+`SRC_REPO` variables accordingly.
+
+1. Set environment variables for your specific environment. Replace the
+   placeholders with your actual values.
+
+   In this example, you authenticate as your Docker organization using an
+   [organization access token
+   (OAT)](../../enterprise/security/access-tokens.md). The OAT must have at
+   least pull access to every DHI repository you want to mirror. Only
+   repositories in the token's scope are accessible. Alternatively, you can
+   authenticate as a Docker Hub user with a [personal access token
+   (PAT)](../../security/access-tokens.md) that has `read only` access.
+
+   > [!WARNING]
+   >
+   > The following examples export credentials directly on the command line for
+   > demonstration purposes. This exposes sensitive tokens in your shell history
+   > and process list. In production environments, use secure methods such as
+   > reading from files with restricted permissions, environment files loaded
+   > at runtime, or secret management tools.
+
+   ```console
+   $ export DOCKER_ORG="YOUR_DOCKER_ORG"
+   $ export DOCKER_OAT="YOUR_DOCKER_OAT"
+   $ export DEST_REG="registry.example.com"
+   $ export DEST_REPO="mirror/dhi-python"
+   $ export DEST_REG_USERNAME="YOUR_DESTINATION_REGISTRY_USERNAME"
+   $ export DEST_REG_TOKEN="YOUR_DESTINATION_REGISTRY_TOKEN"
+   $ export SRC_REPO="docker.io/${DOCKER_ORG}/dhi-python"
+   $ export SRC_ATT_REPO="registry.scout.docker.com/${DOCKER_ORG}/dhi-python"
+   $ export TAG="3.13-alpine3.21"
+   ```
+
+2. Sign in via `regctl` to Docker Hub, the Scout registry that contains
+   the attestations, and your destination registry.
+
+   ```console
+   $ echo $DOCKER_OAT | regctl registry login -u "$DOCKER_ORG" --pass-stdin docker.io
+   $ echo $DOCKER_OAT | regctl registry login -u "$DOCKER_ORG" --pass-stdin registry.scout.docker.com
+   $ echo $DEST_REG_TOKEN | regctl registry login -u "$DEST_REG_USERNAME" --pass-stdin "$DEST_REG"
+   ```
+
+3. Mirror the image and attestations using `--referrers` and referrer endpoints:
+
+   ```console
+   $ regctl image copy \
+        "${SRC_REPO}:${TAG}" \
+        "${DEST_REG}/${DEST_REPO}:${TAG}" \
+        --referrers \
+        --referrers-src "${SRC_ATT_REPO}" \
+        --referrers-tgt "${DEST_REG}/${DEST_REPO}" \
+        --force-recursive
+   ```
+
+4. Verify that artifacts were preserved.
+
+   First, get a digest for a specific tag and platform. For example, `linux/amd64`.
+
+   ```console
+   DIGEST="$(regctl manifest head "${DEST_REG}/${DEST_REPO}:${TAG}" --platform linux/amd64)"
+   ```
+
+   List attached artifacts (SBOM, provenance, VEX, vulnerability reports).
+
+   ```console
+   $ regctl artifact list "${DEST_REG}/${DEST_REPO}@${DIGEST}"
+   ```
+
+   Or, list attached artifacts with `docker scout`.
+
+   ```console
+   $ docker scout attest list "registry://${DEST_REG}/${DEST_REPO}@${DIGEST}"
+   ```
+
+### Example ongoing mirroring with `regsync`
+
+`regsync` automates pulling from your organizations mirrored DHI repositories on
+Docker Hub and pushing to your external registry including attestations. It
+reads a YAML configuration file and can filter tags.
+
+The following example uses a `regsync.yaml` file that syncs Node 24 and Python
+3.12 Debian 13 variants, excluding Alpine and Debian 12.
+
+```yaml{title="regsync.yaml",collapse=true}
+version: 1
+# Optional: inline creds if not relying on prior CLI logins
+# creds:
+#   - registry: docker.io
+#     user: <your-docker-org>
+#     pass: "{{file \"/run/secrets/docker_oat\"}}"
+#   - registry: registry.scout.docker.com
+#     user: <your-docker-org>
+#     pass: "{{file \"/run/secrets/docker_oat\"}}"
+#   - registry: registry.example.com
+#     user: <service-user>
+#     pass: "{{file \"/run/secrets/dest_token\"}}"
+
+sync:
+  - source: docker.io/<your-org>/dhi-node
+    target: registry.example.com/mirror/dhi-node
+    type: repository
+    fastCopy: true
+    referrers: true
+    referrerSource: registry.scout.docker.com/<your-org>/dhi-node
+    referrerTarget: registry.example.com/mirror/dhi-node
+    tags:
+      allow: [ "24.*" ]
+      deny: [ ".*alpine.*", ".*debian12.*" ]
+
+  - source: docker.io/<your-org>/dhi-python
+    target: registry.example.com/mirror/dhi-python
+    type: repository
+    fastCopy: true
+    referrers: true
+    referrerSource: registry.scout.docker.com/<your-org>/dhi-python
+    referrerTarget: registry.example.com/mirror/dhi-python
+    tags:
+      allow: [ "3.12.*" ]
+      deny: [ ".*alpine.*", ".*debian12.*" ]
+```
+
+To do a dry run with the configuration file, you can run the following command.
+You must [install `regsync`](https://github.com/regclient/regclient) first.
+
+```console
+$ regsync check -c regsync.yaml
+```
+
+To run the sync with the configuration file:
+
+```console
+$ regsync once -c regsync.yaml
+```
+
+## What next
+
+After mirroring, see [Pull a DHI](./use.md#pull-a-dhi) to learn how to pull and use mirrored images.
diff --git a/content/manuals/dhi/how-to/policies.md b/content/manuals/dhi/how-to/policies.md
new file mode 100644
index 000000000000..e909dfdfadc7
--- /dev/null
+++ b/content/manuals/dhi/how-to/policies.md
@@ -0,0 +1,227 @@
+---
+title: Apply Docker Hardened Image policies to your images
+linktitle: Apply image policies
+description: Learn how to hold your own images to Docker Hardened Image security and compliance standards using the Docker Scout CLI.
+weight: 50
+keywords: docker scout policies, image security policy, container compliance, dhi policies, vulnerability policy check
+---
+
+Docker publishes the set of security and compliance policies that Docker
+Hardened Images (DHIs) are built to meet, so you can hold your own images to the
+same standards. You evaluate images against these policies with the
+[`docker scout policy`](../../scout/policy/local.md) command.
+
+These policies encode requirements such as running as a non-root user, being
+free of fixable critical and high vulnerabilities, containing no embedded
+malware or secrets, and shipping signed supply chain attestations. They don't
+verify whether an image is a DHI or built on a DHI base image; they check
+whether an image meets the same bar that DHIs are held to.
+
+Unlike the built-in Docker Scout policies, the DHI policies aren't embedded in
+the CLI. They're maintained as Rego source in the
+[`docker-hardened-images/policies`](https://github.com/docker-hardened-images/policies)
+repository and published as an OCI policy bundle at
+[`dhi/policies`](https://hub.docker.com/repository/docker/dhi/policies/general).
+You pull the bundle at evaluation time with the `--policy-bundle` flag, so you
+can apply DHI standards locally, in CI, or both, without sending any data to the
+Docker Scout service.
+
+## Policies in the DHI bundle
+
+The `dhi/policies` bundle includes the following policies:
+
+| Policy | Policy name | What it checks |
+| --- | --- | --- |
+| No default root user for non-dev images | `dhi-default-non-root-user` | The image is configured to run as a non-root user. |
+| No fixable vulnerabilities past their remediation SLA | `fixable-vulnerabilities` | No fixable CVEs remain unaddressed past their remediation SLA (7 days for critical and high, 30 days for others). |
+| No high-profile vulnerabilities | `high-profile-vulnerabilities` | The image is free of a curated list of well-known CVEs, optionally including the CISA KEV catalog. |
+| No embedded malware | `dhi-no-embedded-malware` | A malware scan attestation is present and passing. |
+| No embedded secrets | `dhi-no-embedded-secrets` | A secret scan attestation is present and passing. |
+| No failing tests | `dhi-no-failing-tests` | A test attestation is present and passing. |
+| Signed supply chain attestations | `dhi-signed-supply-chain-attestations` | SBOM and provenance attestations are attached and signed. |
+| Unintentional shell or package manager | `dhi-unintentional-shell-or-package-manager` | No undeclared shell or package manager is present in the image. |
+| STIG scan | `dhi-stig-scan-score` | For FIPS-compliant images, the STIG scan meets the required score. |
+
+The **Policy name** is the stable ID you reference in a `--policy-config` file to
+enable, disable, or tune a policy.
+
+For the authoritative list and the Rego source for each policy, see the
+[`docker-hardened-images/policies`](https://github.com/docker-hardened-images/policies)
+repository.
+
+## Prerequisites
+
+- The [Docker Scout CLI plugin](/manuals/scout/install.md). It's included with
+  Docker Desktop.
+- Access to pull the `dhi/policies` bundle from Docker Hub. Authentication uses
+  your existing Docker registry credentials, so sign in first:
+
+  ```console
+  $ docker login
+  ```
+
+## Evaluate an image against the DHI policies
+
+To evaluate an image against the DHI policy bundle, pass the bundle reference to
+`docker scout policy` with the `--policy-bundle` flag:
+
+```console
+$ docker scout policy <image> --policy-bundle dhi/policies:latest
+```
+
+The CLI pulls the bundle, indexes the image into an SBOM, enriches it with CVE
+and VEX data, and evaluates each policy in the bundle against that data. Bundles
+are cached by digest, so re-running against the same bundle doesn't re-download
+it.
+
+### Example: Build and evaluate a DHI-based image
+
+The following example builds an image from a DHI base image and evaluates it
+against the DHI policy bundle.
+
+#### Step 1: Use a DHI base image in your Dockerfile
+
+Create a Dockerfile that uses a Docker Hardened Image from the DHI catalog as
+the base. For example:
+
+```dockerfile
+# Dockerfile
+FROM dhi.io/python:3.13
+
+ENTRYPOINT ["python", "-c", "print('Hello from a DHI-based image')"]
+```
+
+#### Step 2: Build the image
+
+Open a terminal and navigate to the directory containing your Dockerfile. Then,
+build the image and load it into your local image store:
+
+```console
+$ docker build --load -t my-dhi-app:v1 .
+```
+
+#### Step 3: Evaluate the image against the DHI policies
+
+Sign in and evaluate the local image against the DHI policy bundle:
+
+```console
+$ docker login
+$ docker scout policy my-dhi-app:v1 \
+  --policy-bundle dhi/policies:latest
+```
+
+The command prints a compliance result for each policy in the bundle, along with
+the details of any violations.
+
+## Customize the DHI policies
+
+You can tune which policies run and their thresholds with a `--policy-config`
+file. The
+[`docker-hardened-images/policies`](https://github.com/docker-hardened-images/policies)
+repository includes an example `config.json` you can start from.
+
+```console
+$ docker scout policy my-dhi-app:v1 \
+  --policy-bundle dhi/policies:latest \
+  --policy-config ./config.json
+```
+
+The config file matches policies by the **Policy name** listed in
+[Policies in the DHI bundle](#policies-in-the-dhi-bundle) and lets you disable
+individual policies or adjust their settings. For example, the following config
+disables the STIG scan policy and opts out of CISA KEV checks in the
+high-profile vulnerabilities policy:
+
+```json
+{
+  "policies": [
+    {
+      "name": "dhi-stig-scan-score",
+      "enabled": false
+    },
+    {
+      "name": "high-profile-vulnerabilities",
+      "config": {
+        "include_cisa_kev": false
+      }
+    }
+  ]
+}
+```
+
+For the full config file format, see
+[Configure built-in policies](../../scout/policy/local.md#configure-built-in-policies).
+
+You can also combine the DHI bundle with the built-in Docker Scout policies,
+additional bundles, or your own custom Rego files. `--policy-bundle`,
+`--policy-file`, and `--policy-dir` are all repeatable:
+
+```console
+$ docker scout policy my-dhi-app:v1 \
+  --policy-bundle dhi/policies:latest \
+  --policy-file ./custom.rego
+```
+
+For more on authoring custom policies and combining policy sources, see
+[Evaluate policies](../../scout/policy/local.md).
+
+## Enforce policy compliance in CI
+
+Use the [Docker Scout GitHub Action](https://github.com/docker/scout-action) to
+evaluate the DHI policies on every push and fail the workflow when an image
+doesn't meet them. The following workflow builds the image, then evaluates it
+against the DHI policy bundle:
+
+```yaml
+name: DHI policy check
+
+on:
+  push:
+
+env:
+  IMAGE_NAME: my-dhi-app:${{ github.sha }}
+
+jobs:
+  policy:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out the repository
+        uses: actions/checkout@v4
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
+      - name: Log in to Docker Hub
+        uses: docker/login-action@v3
+        with:
+          username: ${{ secrets.DOCKER_USER }}
+          password: ${{ secrets.DOCKER_PAT }}
+
+      - name: Build the image
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          load: true
+          tags: ${{ env.IMAGE_NAME }}
+
+      - name: Evaluate DHI policies
+        uses: docker/scout-action@v1.23.1
+        with:
+          command: policy
+          image: ${{ env.IMAGE_NAME }}
+          policy-bundle: dhi/policies:latest
+          exit-code: true
+```
+
+The `docker/login-action` step authenticates with Docker Hub so the runner can
+pull the DHI base image and the `dhi/policies` bundle. Store your Docker Hub
+username and a [personal access token](/manuals/security/access-tokens.md) as the
+`DOCKER_USER` and `DOCKER_PAT` repository secrets.
+
+Set `exit-code: true` to fail the step when any policy isn't met. The
+`policy-bundle` input accepts a comma-separated list of bundles, and you can
+combine it with the `policy-file`, `policy-dir`, and `policy-config` inputs, the
+same as the CLI flags.
+
+For more on running policy evaluation in CI, see
+[Evaluate policies](../../scout/policy/local.md#use-in-ci).
diff --git a/content/manuals/dhi/how-to/scan.md b/content/manuals/dhi/how-to/scan.md
new file mode 100644
index 000000000000..3f325b0fc552
--- /dev/null
+++ b/content/manuals/dhi/how-to/scan.md
@@ -0,0 +1,387 @@
+---
+title: Scan Docker Hardened Images
+linktitle: Scan an image
+description: Learn how to scan Docker Hardened Images for known vulnerabilities using Docker Scout, Grype, or Trivy.
+keywords: scan container image, docker scout cves, grype scanner, trivy container scanner, vex attestation
+weight: 46
+---
+
+Docker Hardened Images (DHIs) are designed to be secure by default, but like any
+container image, it's important to scan them regularly as part of your
+vulnerability management process.
+
+## Scan with OpenVEX-compliant scanners
+
+To get accurate vulnerability assessments, use scanners that support
+[VEX](/manuals/dhi/explore/security-concepts/vex.md) attestations. The following scanners can
+read and apply the VEX statements included with Docker Hardened Images:
+
+- [Docker Scout](#docker-scout): Automatically applies VEX statements with zero configuration
+- [Trivy](#trivy): Supports VEX through VEX Hub or local VEX files
+- [Grype](#grype): Supports VEX via the `--vex` flag
+
+For a full list of supported scanners, see [Scanner integrations](/manuals/dhi/explore/scanner-integrations.md).
+
+## Docker Scout
+
+Docker Scout is integrated into Docker Desktop and the Docker CLI. It provides
+vulnerability insights, CVE summaries, and direct links to remediation guidance.
+
+### Scan a DHI using Docker Scout
+
+To scan a Docker Hardened Image using Docker Scout, run the following
+command:
+
+```console
+$ docker login dhi.io
+$ docker scout cves dhi.io/<image>:<tag> --platform <platform>
+```
+
+Example output:
+
+```plaintext
+    v SBOM obtained from attestation, 101 packages found
+    v Provenance obtained from attestation
+    v VEX statements obtained from attestation
+    v No vulnerable package detected
+    ...
+```
+
+For more detailed filtering and JSON output, see [Docker Scout CLI reference](/reference/cli/docker/scout/).
+
+### Build child images with provenance attestations
+
+When you build a custom image that uses a Docker Hardened Image as its base, you must build with `--provenance=mode=max` and `--sbom=true` so that Docker Scout can trace the base image lineage and correctly apply VEX statements.
+
+Without these flags, Docker Scout cannot identify the DHI base image in
+the provenance chain. As a result, it reports CVEs that are already suppressed
+by VEX statements in the base image, producing false CVE positives in your
+scan results.
+
+> [!NOTE]
+> **Why provenance attestation is required**
+>
+> Docker Scout uses max-mode provenance attestations to identify the DHI base image
+> and track its lineage. A cryptographically signed provenance attestation ensures that
+> base image lineage is verified and tamper-resistant, giving Docker Scout the trust
+> anchor it needs to correctly apply VEX statements from the base image.
+
+To build with maximum provenance and SBOM attestations:
+
+```console
+$ docker build \
+    --provenance=mode=max \
+    --sbom=true \
+    --push \
+    -t docker.io/<namespace>/<image>:<tag> .
+```
+
+After building with these flags, Docker Scout reads the full provenance
+chain, matches the DHI base image, and applies its VEX statements. Scans of
+your child image then reflect the correct suppressed CVEs, giving you an
+accurate vulnerability assessment.
+
+### VEX attestations in child images
+
+If you introduce new layers in your child image and want to suppress CVEs in those layers, you can attach your own VEX attestation to the child image independently, you do not need to duplicate or aggregate the VEX statements from the DHI base image.
+
+When `docker scout cves` runs against your child image, Scout reads VEX attestations from the full provenance chain and applies them cumulatively:
+
+- **Base image VEX** - attached to the DHI, applied to CVEs in base image layers
+- **Child image VEX** - attached to your image, applied to CVEs in layers you introduced
+
+For example, if you add a `requests` layer to a DHI Python base image and attach a VEX statement suppressing `CVE-2024-47081`, Scout applies both VEX attestations independently and attributes each to its respective author:
+
+```text
+✓ VEX statements obtained from attestation
+CVE-2024-47081  VEX: not affected [vulnerable code not present] : <your-namespace>
+```
+
+Scout suppresses CVEs from the DHI base VEX and CVEs from your child VEX in the same scan - no aggregate VEX document is required.
+
+To create and attach a VEX attestation to your child image:
+
+```bash
+cat > child-vex.json << 'EOF'
+{
+  "@context": "https://openvex.dev/ns/v0.2.0",
+  "@id": "https://<your-namespace>/vex/<image-name>/1",
+  "author": "<your-namespace>",
+  "timestamp": "<timestamp>",
+  "version": 1,
+  "statements": [
+    {
+      "vulnerability": {
+        "name": "<CVE-ID>"
+      },
+      "products": [
+        {
+          "@id": "pkg:pypi/<package>@<version>"
+        }
+      ],
+      "status": "not_affected",
+      "justification": "vulnerable_code_not_present"
+    }
+  ]
+}
+EOF
+
+docker scout attestation add \
+  --file child-vex.json \
+  --predicate-type https://openvex.dev/ns/v0.2.0 \
+  docker.io/<your-namespace>/<image>:<tag>
+```
+
+> [!NOTE]
+> This is only possible because you built with `--provenance=mode=max`. Without the full
+> provenance chain, Scout cannot traverse back to the base image to retrieve its VEX attestations.
+
+### Automate DHI scanning in CI/CD with Docker Scout
+
+Integrating Docker Scout into your CI/CD pipeline enables you to automatically
+verify that images built from Docker Hardened Images remain free from known
+vulnerabilities during the build process. This proactive approach ensures the
+continued security integrity of your images throughout the development
+lifecycle.
+
+#### Example GitHub Actions workflow
+
+The following is a sample GitHub Actions workflow that builds an image, scans it and pushes to the registry only if the scan passes:
+
+```yaml {collapse="true"}
+name: DHI Vulnerability Scan
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+
+env:
+  REGISTRY: docker.io
+  IMAGE_NAME: ${{ github.repository }}
+  SHA: ${{ github.event.pull_request.head.sha || github.event.after }}
+
+jobs:
+  scan:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      packages: write
+      pull-requests: write
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@{{% param "checkout_action_version" %}}
+
+      - name: Set up Docker with containerd image store
+        uses: docker/setup-docker-action@{{% param "setup_docker_action_version" %}}
+        with:
+          daemon-config: |
+            {
+              "features": {
+                 "containerd-snapshotter": true
+              }
+            }
+
+      - name: Log in to Docker Hub
+        uses: docker/login-action@{{% param "login_action_version" %}}
+        with:
+          registry: ${{ env.REGISTRY }}
+          username: ${{ secrets.DOCKER_USERNAME }}
+          password: ${{ secrets.DOCKER_PASSWORD }}
+
+      - name: Build
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
+        with:
+          context: .
+          sbom: true
+          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ env.SHA }}
+      
+      - name: Run Docker Scout CVE scan
+        uses: docker/scout-action@v1
+        with:
+          command: cves
+          image: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ env.SHA }}
+          only-severities: critical,high
+          exit-code: true
+
+      - name: Push image
+        if: success()
+        run: |
+          docker push ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ env.SHA }}
+```
+
+The `exit-code: true` parameter ensures that the workflow fails if any critical or
+high-severity vulnerabilities are detected, preventing the deployment of
+insecure images.
+
+> [!NOTE]
+>
+> The `--provenance=mode=max` and `--sbom=true` flags are required so that
+> Docker Scout can trace the DHI base image lineage and correctly apply its
+> VEX statements. Enabling the containerd image store via
+> `docker/setup-docker-action` allows BuildKit to store attestations locally
+> without pushing to a registry first. Without the containerd image store,
+> Docker Engine rejects the build with: `Attestation is not supported for the docker driver. 
+> Switch to a different driver, or turn on the containerd image store, and try again.`
+> The `Push image` step runs only if the scan passes, using `if: success()`
+> to ensure images are only pushed to the registry when they are free of
+> critical or high-severity vulnerabilities.
+
+For more details on using Docker Scout in CI, see [Integrating Docker
+Scout with other systems](/manuals/scout/integrations/_index.md).
+
+## Grype
+
+[Grype](https://github.com/anchore/grype) is an open-source scanner that checks
+container images against vulnerability databases like the NVD and distro
+advisories.
+
+### Scan a DHI using Grype
+
+To scan a Docker Hardened Image using Grype with VEX filtering, first export
+the VEX attestation and then scan with the `--vex` flag:
+
+```console
+$ docker login dhi.io
+$ docker pull dhi.io/<image>:<tag>
+$ docker scout vex get dhi.io/<image>:<tag> --output vex.json
+$ grype dhi.io/<image>:<tag> --vex vex.json
+```
+
+The `--vex` flag applies VEX statements during the scan, filtering out known
+non-exploitable CVEs for accurate results.
+
+For more information on exporting VEX attestations, see [Export VEX
+attestations](#export-vex-attestations).
+
+## Trivy
+
+[Trivy](https://github.com/aquasecurity/trivy) is an open-source vulnerability
+scanner for containers and other artifacts. It detects vulnerabilities in OS
+packages and application dependencies.
+
+### Scan a DHI using Trivy
+
+After installing Trivy, you can scan a Docker Hardened Image by pulling
+the image and running the scan command:
+
+```console
+$ docker login dhi.io
+$ docker pull dhi.io/<image>:<tag>
+$ trivy image --scanners vuln dhi.io/<image>:<tag>
+```
+
+To filter vulnerabilities using VEX statements, Trivy supports multiple
+approaches. Docker recommends using VEX Hub, which provides a seamless workflow
+for automatically downloading and applying VEX statements from configured
+repositories.
+
+#### Using VEX Hub (recommended)
+
+Configure Trivy to download the Docker Hardened Images advisories repository
+from VEX Hub. Run the following commands to set up the VEX repository:
+
+```console
+$ trivy vex repo init
+$ cat << REPO > ~/.trivy/vex/repository.yaml
+repositories:
+  - name: default
+    url: https://github.com/aquasecurity/vexhub
+    enabled: true
+    username: ""
+    password: ""
+    token: ""
+  - name: dhi-vex
+    url: https://github.com/docker-hardened-images/advisories
+    enabled: true
+REPO
+$ trivy vex repo list
+$ trivy vex repo download
+```
+
+After setting up VEX Hub, you can scan a Docker Hardened Image with VEX filtering:
+
+```console
+$ docker login dhi.io
+$ docker pull dhi.io/<image>:<tag>
+$ trivy image --scanners vuln --vex repo dhi.io/<image>:<tag>
+```
+
+For example, scanning the `dhi.io/python:3.13` image:
+
+```console
+$ trivy image --scanners vuln --vex repo dhi.io/python:3.13
+```
+
+Example output:
+
+```plaintext
+Report Summary
+
+┌─────────────────────────────────────────────────────────────────────────────┬────────────┬─────────────────┐
+│                                   Target                                    │    Type    │ Vulnerabilities │
+├─────────────────────────────────────────────────────────────────────────────┼────────────┼─────────────────┤
+│ dhi.io/python:3.13 (debian 13.2)                                            │   debian   │        0        │
+├─────────────────────────────────────────────────────────────────────────────┼────────────┼─────────────────┤
+│ opt/python-3.13.11/lib/python3.13/site-packages/pip-25.3.dist-info/METADATA │ python-pkg │        0        │
+└─────────────────────────────────────────────────────────────────────────────┴────────────┴─────────────────┘
+Legend:
+- '-': Not scanned
+- '0': Clean (no security findings detected)
+```
+
+The `--vex repo` flag applies VEX statements from the configured repository during the scan,
+which filters out known non-exploitable CVEs.
+
+#### Using local VEX files
+
+In addition to VEX Hub, Trivy also supports the use of local VEX files for
+vulnerability filtering. You can download the VEX attestation that Docker
+Hardened Images provide and use it directly with Trivy.
+
+First, download the VEX attestation for your image:
+
+```console
+$ docker scout vex get dhi.io/<image>:<tag> --output vex.json
+```
+
+Then scan the image with the local VEX file:
+
+```console
+$ trivy image --scanners vuln --vex vex.json dhi.io/<image>:<tag>
+```
+
+## Export VEX attestations
+
+For scanners that need local VEX files (like Grype or Trivy with local files),
+you can export the VEX attestations from Docker Hardened Images.
+
+> [!NOTE]
+>
+> By default, VEX attestations are fetched from `registry.scout.docker.com`. Ensure that you can access this registry
+> if your network has outbound restrictions. You can also mirror the attestations to an alternate registry. For more
+> details, see [Mirror to a third-party registry](mirror.md#mirror-to-a-third-party-registry).
+
+Export VEX attestations to a JSON file:
+
+```console
+$ docker scout vex get dhi.io/<image>:<tag> --output vex.json
+```
+
+> [!NOTE]
+>
+> The `docker scout vex get` command requires [Docker Scout
+> CLI](https://github.com/docker/scout-cli/) version 1.18.3 or later.
+>
+> If the image exists locally on your device, you must prefix the image name with `registry://`. For example, use
+> `registry://docs/dhi-python:3.13` instead of `docs/dhi-python:3.13`.
+
+## Explore the VEX file
+
+After exporting the VEX attestation, you can inspect its contents to
+understand what each statement means and filter by status. For a guided
+walkthrough of the VEX document structure, status values, and `jq` filtering
+commands, see [Explore VEX statements in Docker Hardened
+Images](/guides/dhi-vex-walkthrough/).
+
diff --git a/content/manuals/dhi/how-to/search-evaluate.md b/content/manuals/dhi/how-to/search-evaluate.md
new file mode 100644
index 000000000000..6b2f1bd53ec8
--- /dev/null
+++ b/content/manuals/dhi/how-to/search-evaluate.md
@@ -0,0 +1,113 @@
+---
+title: Search and evaluate Docker Hardened Images
+linktitle: Search and evaluate
+description: Learn how to find, compare, and evaluate Docker Hardened Images using the Docker Hub catalog, DHI CLI, and Docker Scout.
+keywords: search docker images, image variants, docker hub catalog, compare docker images, docker scout compare, image comparison, vulnerability comparison
+weight: 10
+aliases:
+  - /dhi/how-to/compare/
+  - /dhi/how-to/explore/
+---
+
+## Search the catalog
+
+You can browse, search, or filter images by category in the [Docker Hub
+catalog](https://hub.docker.com/hardened-images/catalog). For details about
+the catalog interface, see [Docker Hub](/dhi/tools/hub/).
+
+Alternatively, use the [DHI MCP server](/dhi/tools/mcp/) to search and
+inspect the catalog directly from your AI assistant, or use the [DHI
+CLI](/dhi/tools/cli/) to browse the catalog from the command line:
+
+```console
+$ docker dhi catalog list
+```
+
+Filter by image type, name, or compliance requirements:
+
+```console
+$ docker dhi catalog list --type image
+$ docker dhi catalog list --filter python
+$ docker dhi catalog list --fips
+$ docker dhi catalog list --stig
+```
+
+To view repository details, including available tags and CVE counts:
+
+```console
+$ docker dhi catalog get python
+```
+
+## Compare and evaluate images
+
+Docker Scout lets you analyze the differences between two images. Comparing a
+DHI to a standard image helps you understand the security improvements, package
+differences, and overall benefits of adopting hardened images.
+
+Comparison is useful for:
+
+- Evaluating the security improvements when migrating from a standard image to a DHI
+- Understanding package and vulnerability differences between image variants
+- Assessing the impact of customizations or updates
+
+### Prerequisites
+
+Before comparing images:
+
+- Install [Docker Desktop](/desktop/) to use Docker Scout comparison features.
+- Sign in to `dhi.io` for Docker Hardened Images:
+
+  ```console
+  $ docker login dhi.io
+  ```
+
+### Basic comparison
+
+To compare a Docker Hardened Image with another image, use the [`docker scout
+compare`](/reference/cli/docker/scout/compare/) command:
+
+```console
+$ docker scout compare dhi.io/<image>:<tag> \
+    --to <comparison-image>:<tag> \
+    --platform <platform>
+```
+
+For example, to compare a DHI Node.js image with the official Node.js image:
+
+```console
+$ docker scout compare dhi.io/node:22-debian13 \
+    --to node:22 \
+    --platform linux/amd64
+```
+
+The output shows an overview at the top with key comparison metrics, followed by
+detailed package and vulnerability information. Example overview:
+
+```console
+  ## Overview
+
+                      │                    Analyzed Image                     │              Comparison Image
+  ────────────────────┼───────────────────────────────────────────────────────┼─────────────────────────────────────────────
+    Target            │  dhi.io/node:22-debian13                              │  node:22
+      digest          │  55d471f61608                                         │  9ee3220f602f
+      platform        │ linux/amd64                                           │ linux/amd64
+      vulnerabilities │    0C     0H     0M     0L                            │    0C     1H     3M   153L     4?
+                      │           -1     -3   -153     -4                     │
+      size            │ 41 MB (-367 MB)                                       │ 408 MB
+      packages        │ 19 (-726)                                             │ 745
+```
+
+### Filter unchanged packages
+
+To focus only on the differences and ignore unchanged packages, use the
+`--ignore-unchanged` flag:
+
+```console
+$ docker scout compare dhi.io/node:22-debian13 \
+    --to node:22 \
+    --platform linux/amd64 \
+    --ignore-unchanged
+```
+
+This output highlights only the packages and vulnerabilities that differ between
+the two images.
diff --git a/content/manuals/dhi/how-to/select-enterprise.md b/content/manuals/dhi/how-to/select-enterprise.md
new file mode 100644
index 000000000000..e108079f0254
--- /dev/null
+++ b/content/manuals/dhi/how-to/select-enterprise.md
@@ -0,0 +1,262 @@
+---
+title: Get started with DHI Select and Enterprise
+linkTitle: Use DHI Select & Enterprise
+description: Mirror a repository and start using Docker Hardened Images for Select and Enterprise subscriptions.
+keywords: docker hardened images, enterprise, select, mirror, quickstart
+---
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+This guide shows you how to get started with DHI Select and Enterprise
+subscriptions. Unlike DHI Community, this workflow lets you mirror repositories
+to your organization namespace on Docker Hub, access compliance variants (FIPS),
+customize images, and get SLA-backed updates.
+
+## Prerequisites
+
+To use this workflow, you need:
+
+- Organization owner access in your Docker Hub namespace.
+- One of the following:
+  - A DHI Select or Enterprise subscription. [Contact Docker
+    sales](https://www.docker.com/products/hardened-images/#compare) to purchase DHI Enterprise
+    or [learn more about DHI plans](../../subscription/plans/dhi.md).
+  - An active DHI trial. [Start a free DHI
+    trial](https://hub.docker.com/hardened-images/start-free-trial).
+- [Docker Desktop](../../desktop/release-notes.md) 4.65 or later to use the
+  `docker dhi` CLI.
+
+Each step, when applicable, shows Docker Hub and command line instructions. You
+can use either interface.
+
+## Step 1: Find an image to use
+
+{{< tabs group="interface" >}}
+{{< tab name="Docker Hub" >}}
+
+1. Go to [Docker Hub](https://hub.docker.com/) and sign in.
+2. Select your organization in the left sidebar.
+3. Navigate to **Hardened Images** > **Catalog**.
+4. Use the search bar or filters to find an image (for example, `python`,
+   `node`, or `golang`). For this example, search for `python`.
+
+   To search for an image with a compliance variant (FIPS or STIG), select
+   **Filter by** and select the relevant compliance option.
+
+5. Select the Python repository to view its details.
+
+6. Select **Images** to view available image variants.
+
+{{< /tab >}}
+{{< tab name="Command line" >}}
+
+1. List available image repositories:
+
+   ```console
+   $ docker dhi catalog list --type image
+   ```
+
+2. To filter by name and FIPS compliance, use the `--filter` and `--fips` flags:
+
+   ```console
+   $ docker dhi catalog list --filter python --fips
+   ```
+
+3. Get image details for the repository:
+
+   ```console
+   $ docker dhi catalog get python
+   ```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Continue to the next step to mirror the image. To dive deeper into exploring
+images see [Search and evaluate Docker Hardened Images](search-evaluate.md).
+
+## Step 2: Mirror the repository
+
+Mirroring copies a DHI repository into your organization namespace on Docker
+Hub. This lets you receive SLA-backed Docker security patches for your images
+and use customization as well as compliance variants. Only organization owners
+can mirror repositories.
+
+{{< tabs group="interface" >}}
+{{< tab name="Docker Hub" >}}
+
+1. In the image repository details page you found in the previous step, select
+   **Use this image** > **Mirror repository**. Note that you must be signed in
+   to Docker Hub to perform this action.
+2. Select **Mirror**.
+3. Wait for images to finish mirroring. This can take a few minutes.
+4. Verify the mirrored repository appears in your organization namespace with a
+   `dhi-` prefix (for example, `dhi-python`).
+
+{{< /tab >}}
+{{< tab name="Command line" >}}
+
+To use the following commands, you must authenticate or configure DHI CLI
+authentication using your Docker token. For details, see [Use the DHI
+CLI](../tools/cli.md#configuration).
+
+1. Start mirroring the repository to your organization namespace. Replace
+   `<your-org>` with your organization name.
+
+   ```console
+   $ docker dhi mirror start --org <your-org> dhi/python,<your-org>/dhi-python
+   ```
+
+2. Wait for images to finish mirroring. This can take a few minutes.
+
+3. Verify the mirrored repository. Replace `<your-org>` with your organization
+   name.
+
+   ```console
+   $ docker dhi mirror list --org <your-org>
+   ```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Continue to the next step to customize the image. To dive deeper into mirroring
+images see [Mirror a repository](mirror.md).
+
+## Step 3: Customize the image
+
+One of the key benefits of DHI Select and Enterprise is the ability to customize
+your mirrored images. You can add system packages, configure settings, or make other
+modifications to meet your organization's specific requirements.
+
+This example shows how to add the `curl` system package to your mirrored Python image.
+
+{{< tabs group="interface" >}}
+{{< tab name="Docker Hub" >}}
+
+1. Go to your organization namespace on Docker Hub.
+2. Navigate to your mirrored repository (for example, `dhi-python`).
+3. Select **Customizations**.
+4. Select **Create customization**.
+5. Search for `3-alpine3.23` and select any one of the images.
+6. In **Add packages**, select **curl**.
+7. Select **Next: Configure**.
+8. In **Customization name**, enter a name for your customization (for example, `curl`).
+9. Select **Next: Review customization**.
+10. Select **Create customization** to start the build.
+
+It can take a few minutes for the customization to build. Go to the
+**Customizations** tab of your mirrored repository and view the **Last build**
+column to monitor the build status.
+
+{{< /tab >}}
+{{< tab name="Command line" >}}
+
+To use the following commands, you must authenticate or configure DHI CLI
+authentication using your Docker token. For details, see [Use the DHI
+CLI](../tools/cli.md#configuration).
+
+1. Create a customization. Replace `<your-org>` with your organization name.
+   This creates a file called `my-customization.yaml` with the customization
+   details.
+
+   ```console
+   $ docker dhi customization prepare --org <your-org> python 3-alpine3.23 \
+       --destination <your-org>/dhi-python \
+       --name "python with curl" \
+       > my-customization.yaml
+   ```
+
+2. Add the `curl` package to the customization. You can edit the file with any
+   text or code editor. The following commands use `echo` to add the necessary
+   lines to the YAML file:
+
+   ```console
+   $ echo "contents:" >> my-customization.yaml
+   $ echo "  packages:" >> my-customization.yaml
+   $ echo "    - curl" >> my-customization.yaml
+   ```
+
+3. Apply the customization:
+
+   ```console
+   $ docker dhi customization create --org <your-org> my-customization.yaml
+   ```
+
+4. Verify the customization was created:
+
+   ```console
+   $ docker dhi customization list --org <your-org>
+   ```
+
+It can take a few minutes for the customization to build. To check the build status:
+
+1. Go to your organization namespace on Docker Hub.
+2. Navigate to your mirrored repository (for example, `dhi-python`).
+3. Select **Customizations**.
+4. View the **Last build** column to monitor the build status.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+To dive deeper into customization, see [Customize a Docker Hardened
+Image](customize.md).
+
+## Step 4: Pull and run your customized image
+
+After the customization build completes, you can pull and run the customized
+image from your organization namespace on Docker Hub.
+
+1. Sign in to Docker Hub:
+
+   ```console
+   $ docker login
+   ```
+
+2. Pull the customized image from your organization. Replace `<your-org>` with
+   your organization name. The customized tag includes the suffix based on your
+   customization name.
+
+   ```console
+   $ docker pull <your-org>/dhi-python:3-alpine3.23_python-with-curl
+   ```
+
+3. Run the image and test that `curl` is installed:
+
+   ```console
+   $ docker run --rm <your-org>/dhi-python:3-alpine3.23_python-with-curl curl --version
+   ```
+
+   This confirms that the `curl` package was successfully added to the image.
+
+To dive deeper into using images, see:
+
+- [Use a Docker Hardened Image](use.md) for general usage
+- [Use a Helm chart](helm.md) for deploying with Helm
+
+## Step 5: Remove customization and stop mirroring
+
+To remove the customization and stop mirroring the repository:
+
+1. Go to your organization namespace on Docker Hub.
+2. Navigate to your mirrored repository (for example, `dhi-python`).
+3. Select **Customizations**.
+4. Find the customization you want to delete (for example, `python with curl`).
+5. Select the trash can icon.
+6. Select **Delete customization** to confirm the deletion.
+7. To stop mirroring, go back to your organization's repositories list.
+8. Find the mirrored repository (for example, `dhi-python`).
+9. Select **Settings**.
+10. Select **Stop mirroring**.
+11. Select **Stop mirroring** to confirm.
+
+## What's next
+
+You've mirrored, customized, and run a Docker Hardened Image. Here are a few ways to keep going:
+
+- [Migrate existing applications to DHIs](../migration/migrate-with-ai.md): Use
+  Gordon to update your Dockerfiles to use Docker Hardened Images as the base.
+
+- [Verify DHIs](verify.md): Use tools like [Docker Scout](/scout/) or Cosign to
+  inspect and verify signed attestations, like SBOMs and provenance.
+
+- [Scan DHIs](scan.md): Analyze the image with Docker Scout or other scanners
+  to identify known CVEs.
diff --git a/content/manuals/dhi/how-to/troubleshoot.md b/content/manuals/dhi/how-to/troubleshoot.md
new file mode 100644
index 000000000000..42d2a51400b7
--- /dev/null
+++ b/content/manuals/dhi/how-to/troubleshoot.md
@@ -0,0 +1,187 @@
+---
+title: Troubleshoot
+description: Resolve common issues when building, running, or debugging Docker Hardened Images, such as non-root behavior, missing shells, and port access.
+weight: 100
+tags: [Troubleshooting]
+keywords: troubleshoot hardened image, docker debug container, non-root permission issue, missing shell error, no package manager, debug, hardened images, DHI, troubleshooting, ephemeral container, docker debug, non-root containers, hardened container image, debug secure container
+aliases:
+  - /dhi/how-to/debug/
+  - /dhi/troubleshoot/
+---
+
+This page covers debugging techniques and common issues you may encounter while
+migrating to or using Docker Hardened Images (DHIs).
+
+## General debugging
+
+Docker Hardened Images prioritize minimalism and security, which means
+they intentionally leave out many common debugging tools (like shells or package
+managers). This makes direct troubleshooting difficult without introducing risk.
+To address this, you can use [Docker
+Debug](/reference/cli/docker/debug/), a secure workflow that
+temporarily attaches an ephemeral debug container to a running service or image
+without modifying the original image.
+
+This section shows how to debug Docker Hardened Images locally during development.
+With Docker Debug, you can also debug containers remotely using the `--host`
+option.
+
+### Use Docker Debug
+
+#### Step 1: Run a container from a Hardened Image
+
+Start with a DHI-based container that simulates an issue:
+
+```console
+$ docker run -d --name myapp dhi.io/python:3.13 python -c "import time; time.sleep(300)"
+```
+
+This container doesn't include a shell or tools like `ps`, `top`, or `cat`.
+
+If you try:
+
+```console
+$ docker exec -it myapp sh
+```
+
+You'll see:
+
+```console
+exec: "sh": executable file not found in $PATH
+```
+
+#### Step 2: Use Docker Debug to inspect the container
+
+Use the `docker debug` command to attach a temporary, tool-rich debug container to the running instance.
+
+```console
+$ docker debug myapp
+```
+
+From here, you can inspect running processes, network status, or mounted files.
+
+For example, to check running processes:
+
+```console
+$ ps aux
+```
+
+Type `exit` to leave the container when done.
+
+### Alternative debugging approaches
+
+In addition to using Docker Debug, you can also use the following approaches for
+debugging DHI containers.
+
+#### Use the -dev variant
+
+Docker Hardened Images offer a `-dev` variant that includes a shell
+and a package manager to install debugging tools. Simply replace the image tag
+with `-dev`:
+
+```console
+$ docker run -it --rm dhi.io/python:3.13-dev sh
+```
+
+Type `exit` to leave the container when done. Note that using the `-dev` variant
+increases the attack surface and it is not recommended as a runtime for
+production environments.
+
+#### Mount debugging tools with image mounts
+
+You can use the image mount feature to mount debugging tools into your container
+without modifying the base image.
+
+##### Step 1: Run a container from a hardened image
+
+Start with a DHI-based container that simulates an issue:
+
+```console
+$ docker run -d --name myapp dhi.io/python:3.13 python -c "import time; time.sleep(300)"
+```
+
+##### Step 2: Mount debugging tools into the container
+
+Run a new container that mounts a tool-rich image (like `busybox`) into
+the running container's namespace:
+
+```console
+$ docker run --rm -it --pid container:myapp \
+  --mount type=image,source=busybox,destination=/dbg,ro \
+  dhi.io/python:3.13 /dbg/bin/sh
+```
+
+This mounts the BusyBox image at `/dbg`, giving you access to its tools while
+keeping your original container image unchanged. Since the hardened Python image
+doesn't include standard utilities, you need to use the full path to the mounted
+tools:
+
+```console
+$ /dbg/bin/ls /
+$ /dbg/bin/ps aux
+$ /dbg/bin/cat /etc/os-release
+```
+
+Type `exit` to leave the container when done.
+
+## Common issues
+
+The following are specific issues you may encounter when working with Docker
+Hardened Images, along with recommended solutions.
+
+### Permissions
+
+DHIs run as a nonroot user by default for enhanced security. This can result in
+permission issues when accessing files or directories. Ensure your application
+files and runtime directories are owned by the expected UID/GID or have
+appropriate permissions.
+
+To find out which user a DHI runs as, check the repository page for the image on
+Docker Hub. See [View image variant
+details](../tools/hub.md#image-variant-details-page) for more information.
+
+### Privileged ports
+
+Nonroot containers cannot bind to ports below 1024 by default. This is enforced
+by both the container runtime and the kernel (especially in Kubernetes and
+Docker Engine < 20.10).
+
+Inside the container, configure your application to listen on an unprivileged
+port (1025 or higher). For example `docker run -p 80:8080 my-image` maps
+port 8080 in the container to port 80 on the host, allowing you to access it
+without needing root privileges.
+
+### No shell
+
+Runtime DHIs omit interactive shells like `sh` or `bash`. If your build or
+tooling assumes a shell is present (e.g., for `RUN` instructions), use a `dev`
+variant of the image in an earlier build stage and copy the final artifact into
+the runtime image.
+
+To find out which shell, if any, a DHI has, check the repository page for the
+image on Docker Hub. See [View image variant
+details](../tools/hub.md#image-variant-details-page) for more information.
+
+Also, use Docker Debug when you need shell access to a running container. For
+more details, see [General debugging](#general-debugging).
+
+### Entry point differences
+
+DHIs may define different entry points compared to Docker Official Images (DOIs)
+or other community images.
+
+To find out the ENTRYPOINT or CMD for a DHI, check the repository page for the
+image on Docker Hub. See [View image variant
+details](../tools/hub.md#image-variant-details-page) for more information.
+
+### No package manager
+
+Runtime Docker Hardened Images are stripped down for security and minimal attack
+surface. As a result, they don't include a package manager such as `apk` or
+`apt`. This means you can't install additional software directly in the runtime
+image.
+
+If your build or application setup requires installing packages (for example, to
+compile code, install runtime dependencies, or add diagnostic tools), use a `dev`
+variant of the image in a build stage. Then, copy only the necessary artifacts
+into the final runtime image.
\ No newline at end of file
diff --git a/content/manuals/dhi/how-to/use.md b/content/manuals/dhi/how-to/use.md
new file mode 100644
index 000000000000..73bf38594ea0
--- /dev/null
+++ b/content/manuals/dhi/how-to/use.md
@@ -0,0 +1,354 @@
+---
+title: Use a Docker Hardened Image
+linktitle: Use an image
+description: Learn how to pull, run, and reference Docker Hardened Images in Dockerfiles, CI pipelines, and standard development workflows.
+keywords: use hardened image, docker pull secure image, non-root containers, multi-stage dockerfile, dev image variant
+weight: 30
+aliases:
+  - /dhi/how-to/els/
+  - /dhi/how-to/k8s/
+---
+
+You can use a Docker Hardened Image (DHI) just like any other image on Docker
+Hub. DHIs follow the same familiar usage patterns. Pull them with `docker pull`,
+reference them in your Dockerfile, and run containers with `docker run`.
+
+The key difference is that DHIs are security-focused and intentionally minimal
+to reduce the attack surface. This means some variants don't include a shell or
+package manager, and may run as a non-root user by default.
+
+> [!IMPORTANT]
+>
+> You must authenticate to the Docker Hardened Images registry (`dhi.io`) to
+> pull DHI Community images. You can authenticate using either of the following:
+>
+> - **Docker ID and password:** Use your Docker Hub username and password. If
+>   you don't have a Docker account, [create one](../../accounts/create-account.md)
+>   for free.
+> - **Access token:** Use a [personal access token
+>   (PAT)](../../security/access-tokens.md) for personal accounts, or an
+>   [organization access token
+>   (OAT)](../../enterprise/security/access-tokens.md) with your organization
+>   name as the username.
+>
+> Run `docker login dhi.io` to authenticate.
+
+## Considerations when adopting DHIs
+
+Docker Hardened Images are intentionally minimal to improve security. If you're
+updating existing Dockerfiles or frameworks to use DHIs, keep in mind that
+runtime images don't include shells or package managers, run as non-root users
+by default, and may have different configurations than images you're familiar
+with.
+
+For a comprehensive checklist of migration considerations and detailed guidance,
+see [Migrate to Docker Hardened Images](../migration/_index.md).
+
+## Pull, run, and reference DHIs
+
+Docker Hardened Images use different image references depending on your
+subscription:
+
+| Subscription        | Image reference            | Authentication        |
+|---------------------|----------------------------|-----------------------|
+| Community           | `dhi.io/<image>:<tag>`     | `docker login dhi.io` |
+| Select & Enterprise | `<your-org>/<image>:<tag>` | `docker login`        |
+
+Select and Enterprise users should [mirror](./mirror.md) repositories to their
+Docker Hub organization to access compliance variants and customization
+features.
+
+After authenticating, use the image reference in standard Docker commands and
+Dockerfiles. For example:
+
+```console
+$ docker pull dhi.io/python:3.13
+$ docker run --rm dhi.io/python:3.13 python -c "print('Hello from DHI')"
+```
+
+```dockerfile
+FROM dhi.io/python:3.13
+COPY . /app
+CMD ["python", "/app/main.py"]
+```
+
+For multi-stage builds:
+- Use a `-dev` tag for build stages that need a shell or package manager. See
+  [Use dev variants for framework-based
+  applications](#use-dev-variants-for-framework-based-applications).
+- Use the `static` image for compiled executables with minimal runtime
+  dependencies. See [Use a static image for compiled
+  executables](#use-a-static-image-for-compiled-executables).
+
+To learn how to search for available variants, see [Search and evaluate
+images](./search-evaluate.md).
+
+## Use a DHI in CI/CD pipelines
+
+Docker Hardened Images work just like any other image in your CI/CD pipelines.
+You can reference them in Dockerfiles, pull them as part of a pipeline step, or
+run containers based on them during builds and tests.
+
+Unlike typical container images, DHIs also include signed
+[attestations](../explore/security-concepts/attestations.md) such as SBOMs and provenance
+metadata. You can incorporate these into your pipeline to support supply chain
+security, policy checks, or audit requirements if your tooling supports it.
+
+To strengthen your software supply chain, consider adding your own attestations
+when building images from DHIs. This lets you document how the image was built,
+verify its integrity, and enable downstream validation and policy enforcement
+using tools like Docker Scout.
+
+To learn how to attach attestations during the build process, see [Docker Build
+Attestations](/manuals/build/metadata/attestations.md).
+
+### Discover attestations with ORAS
+
+You can use [ORAS](https://oras.land/) to discover and inspect the attestations
+attached to Docker Hardened Images. This is particularly useful in CI/CD
+pipelines for supply chain security validation and compliance checks.
+
+For automated workflows, authenticate using an [organization access token
+(OAT)](../../enterprise/security/access-tokens.md). OATs are owned by the
+organization rather than an individual user, making them better suited for CI/CD
+pipelines.
+
+To discover attestations with ORAS:
+
+1. [Generate an organization access
+   token](../../enterprise/security/access-tokens.md) with **Read public
+   repositories** scope.
+
+   The following example shows how to discover attestations on DHI community
+   images from `dhi.io`. If you're discovering attestations on images mirrored to
+   your organization, generate an OAT scoped to read from your mirrored repository
+   instead of **Read public repositories**.
+
+2. Sign in to `dhi.io` using your organization name as the username and the OAT
+   as the password.
+
+   > [!WARNING]
+   >
+   > The following examples export credentials directly on the command line for
+   > demonstration purposes. This exposes sensitive tokens in your shell history
+   > and process list. In production environments, use secure methods such as
+   > reading from files with restricted permissions, environment files loaded
+   > at runtime, or secret management tools.
+
+    ```console
+    $ oras login dhi.io -u <YOUR_ORGANIZATION_NAME>
+    ```
+
+   Or non-interactively in a CI/CD pipeline, set your organization name and token:
+
+   ```console
+   $ export DOCKER_ORG="YOUR_ORGANIZATION_NAME"
+   $ export OAT="YOUR_ORGANIZATION_ACCESS_TOKEN"
+   $ echo $OAT | oras login dhi.io -u "$DOCKER_ORG" --password-stdin
+   ```
+
+3. Discover attestations on a DHI image:
+
+   ```console
+   $ oras discover dhi.io/node:24-dev --platform linux/amd64
+   ```
+
+   > [!NOTE]
+   >
+   > The `--platform` flag is required. Without it, `oras discover` resolves to
+   > the multi-arch image index, which returns only an index-level signature
+   > rather than the full set of per-platform attestations.
+
+   A successful response lists the attestations attached to the image,
+   including SBOMs, provenance, vulnerability reports, and changelog metadata.
+
+## Use a static image for compiled executables
+
+Docker Hardened Images include a `static` image repository designed specifically
+for running compiled executables in an extremely minimal and secure runtime.
+Unlike a non-hardened `FROM scratch` image, the DHI `static` image includes
+attestations and essential packages like `ca-certificates`.
+
+Use a `-dev` or other builder image to compile your binary, then copy the output
+into a `static` image:
+
+```dockerfile
+FROM dhi.io/golang:1.22-dev AS build
+WORKDIR /app
+COPY . .
+RUN CGO_ENABLED=0 go build -o myapp
+
+FROM dhi.io/static:20230311
+COPY --from=build /app/myapp /myapp
+ENTRYPOINT ["/myapp"]
+```
+
+For more multi-stage build patterns, see the [Go migration
+example](../migration/examples/go.md).
+
+## Use dev variants for framework-based applications
+
+If you're building applications with frameworks that require package managers or
+build tools (such as Python, Node.js, or Go), use a `-dev` variant during the
+development or build stage. These variants include essential utilities like
+shells, compilers, and package managers to support local iteration and CI
+workflows.
+
+Use `-dev` images in your inner development loop or in isolated CI stages to
+maximize productivity. Once you're ready to produce artifacts for production,
+switch to a smaller runtime variant to reduce the attack surface and image size.
+
+For detailed multi-stage Dockerfile examples using dev variants, see the
+migration examples:
+- [Go](../migration/examples/go.md)
+- [Python](../migration/examples/python.md)
+- [Node.js](../migration/examples/node.md)
+
+## Use Socket Firewall variants to monitor package installations
+
+If you want supply chain protection during dependency installation, use a Socket
+Firewall variant in place of the standard `-dev` variant in your build stage.
+These variants come with [Socket](https://socket.dev/) preinstalled to monitor
+package manager activity and block malicious packages before they reach your
+image.
+
+Two tiers are available. Use `-sfw-dev` for Socket Firewall Free, or
+`-sfw-ent-dev` for Socket Firewall Enterprise (requires an API key from Socket).
+The runtime stage stays the same regardless of which build stage variant you
+use.
+
+```dockerfile
+FROM dhi.io/python:3.13-alpine3.23-sfw-dev AS build
+WORKDIR /app
+COPY requirements.txt .
+RUN pip install --no-cache-dir -r requirements.txt
+
+FROM dhi.io/python:3.13-alpine3.23
+COPY --from=build /app /app
+CMD ["python", "app.py"]
+```
+
+For more information on Socket Firewall variants, see [Available image
+types](../explore/available.md).
+
+## Use compliance and ELS variants
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+With a DHI Select or DHI Enterprise subscription, you can access additional
+image variants:
+
+- Compliance variants: FIPS-enabled and STIG-ready images for regulatory
+  requirements
+- ELS (Extended Lifecycle Support) variants (requires add-on): Security patches
+  for end-of-life image versions
+
+To access these variants, [mirror](./mirror.md) the repository to your Docker
+Hub organization. For ELS, enable **Mirror end-of-life images** when setting up
+mirroring. Once mirrored, use the compliance or EOL tags like any other image
+tag.
+
+## Use with Kubernetes
+
+When deploying Docker Hardened Images to Kubernetes, the process is similar to
+using any other container image with one key difference: you must configure
+image pull secrets to authenticate to the DHI registry. This applies whether
+you're pulling directly from `dhi.io`, from a mirror on Docker Hub, or from
+your own third-party registry.
+
+### Create an image pull secret
+
+You can create an image pull secret using either an access token or Docker Desktop credentials.
+
+For the `--docker-server` value:
+- Use `dhi.io` for community images pulled directly from Docker Hardened Images
+- Use `docker.io` for mirrored repositories on Docker Hub
+- Use your registry's hostname for third-party registries
+
+#### Using an access token
+
+Create a secret using a [Personal Access Token
+(PAT)](../../security/access-tokens.md) or [Organization Access Token
+(OAT)](../../enterprise/security/access-tokens.md). Ensure the token has at
+least read-only access to the repositories.
+
+```console
+$ kubectl create -n <kubernetes namespace> secret docker-registry <secret name> --docker-server=<registry server> \
+        --docker-username=<registry user> --docker-password=<access token> \
+        --docker-email=<registry email>
+```
+
+#### Using Docker Desktop credentials
+
+If you're already authenticated with Docker Desktop, you can create a secret
+using your stored credentials. This method works for registries you've
+authenticated to via Docker Desktop (using `docker login <registry>`).
+
+```console
+$ NS=<namespace>
+$ kubectl create -n ${NS} secret docker-registry dhi-pull-secret \
+    --docker-server=<registry server> \
+    --docker-username=<registry user> \
+    --docker-password="$(echo https://<registry server> | docker-credential-desktop get | jq -r .Secret)" \
+    --docker-email=<registry email>
+```
+
+This method extracts credentials from Docker Desktop's credential store, avoiding the need to create a separate access token for local development.
+
+### Test the image pull secret
+
+After creating the secret, verify it works by deploying a test pod that
+references the secret in its `imagePullSecrets` configuration.
+
+Create a test pod:
+
+```console
+kubectl apply --wait -f - <<EOF
+apiVersion: v1
+kind: Pod
+metadata:
+  name: dhi-test
+  namespace: <kubernetes namespace>
+spec:
+  containers:
+  - name: test
+    image: bash:5
+    command: [ "sh", "-c", "echo 'Hello from DHI in Kubernetes!'" ]
+  imagePullSecrets:
+  - name: <secret name>
+EOF
+```
+
+Check the pod status to ensure it completed successfully:
+
+```console
+$ kubectl get -n <kubernetes namespace> pods/dhi-test
+```
+
+A successful test shows `Completed` status:
+
+```console
+NAME       READY   STATUS      RESTARTS     AGE
+dhi-test   0/1     Completed   ...          ...
+```
+
+If you see `ErrImagePull` status instead, there's an issue with your secret
+configuration:
+
+```console
+NAME       READY   STATUS         RESTARTS   AGE
+dhi-test   0/1     ErrImagePull   0          ...
+```
+
+Verify the pod output matches the expected message:
+
+```console
+$ kubectl logs -n <kubernetes namespace> pods/dhi-test
+Hello from DHI in Kubernetes!
+```
+
+Clean up the test pod:
+
+```console
+$ kubectl delete -n <kubernetes namespace> pods/dhi-test
+```
diff --git a/content/manuals/dhi/how-to/verify.md b/content/manuals/dhi/how-to/verify.md
new file mode 100644
index 000000000000..ab4602e0deb7
--- /dev/null
+++ b/content/manuals/dhi/how-to/verify.md
@@ -0,0 +1,407 @@
+---
+title: Verify a Docker Hardened Image or chart
+linktitle: Verify an image or chart
+description: Use Docker Scout or cosign to verify signed attestations like SBOMs, provenance, and vulnerability data for Docker Hardened Images and charts.
+weight: 40
+keywords: verify container image, docker scout attest, cosign verify, sbom validation, signed container attestations, helm chart verification
+---
+
+Docker Hardened Images (DHI) and charts include signed attestations that verify
+the build process, contents, and security posture.
+
+Docker's public key for DHI images and charts is published at:
+
+- https://registry.scout.docker.com/keyring/dhi/latest.pub
+- https://github.com/docker-hardened-images/keyring
+
+Docker recommends using [Docker Scout](/scout/), but you can use
+[`regctl`](https://github.com/regclient/regclient) and
+[`cosign`](https://docs.sigstore.dev/) to retrieve and verify attestations.
+Docker Scout offers several key advantages: it understands DHI attestation
+structures, automatically resolves platforms, provides human-readable summaries,
+validates in one step with `--verify`, and integrates tightly with Docker's
+attestation infrastructure.
+
+> [!IMPORTANT]
+>
+> You must authenticate to the Docker Hardened Images registry (`dhi.io`) to
+> pull images. Use your Docker ID credentials (the same username and password
+> you use for Docker Hub) when signing in. If you don't have a Docker account,
+> [create one](../../accounts/create-account.md) for free.
+>
+> Run `docker login dhi.io` to authenticate.
+
+## Verify image attestations
+
+> [!NOTE]
+>
+> Before you run `docker scout attest` commands, ensure any image that you have
+> pulled locally is up to date with the remote image. You can do this by running
+> `docker pull`. If you don't do this, you may see `No attestation found`.
+
+### List available attestations
+
+To list attestations for a mirrored DHI image:
+
+{{< tabs group="tool" >}}
+{{< tab name="Docker Scout" >}}
+
+> [!NOTE]
+>
+> If the image exists locally on your device, you must prefix the image name with `registry://`. For example, use
+> `registry://dhi.io/python:3.13` instead of `dhi.io/python:3.13`.
+
+```console
+$ docker scout attest list dhi.io/<image>:<tag>
+```
+
+This command shows all available attestations, including SBOMs, provenance, vulnerability reports, and more.
+
+{{< /tab >}}
+{{< tab name="regctl" >}}
+
+First, authenticate to both registries. This example authenticates as your
+Docker organization using an [organization access token
+(OAT)](../../enterprise/security/access-tokens.md). The OAT must have at least
+pull access to the DHI repositories you want to verify. Only repositories in
+the token's scope are accessible. Alternatively, you can authenticate as a
+Docker Hub user with a [personal access token
+(PAT)](../../security/access-tokens.md) that has `read only` access.
+
+> [!WARNING]
+>
+> The following examples export credentials directly on the command line for
+> demonstration purposes. This exposes sensitive tokens in your shell history
+> and process list. In production environments, use secure methods such as
+> reading from files with restricted permissions, environment files loaded
+> at runtime, or secret management tools.
+
+```console
+$ export DOCKER_ORG="YOUR_DOCKER_ORG"
+$ export DOCKER_OAT="YOUR_DOCKER_OAT"
+$ echo $DOCKER_OAT | regctl registry login -u "$DOCKER_ORG" --pass-stdin docker.io
+$ echo $DOCKER_OAT | regctl registry login -u "$DOCKER_ORG" --pass-stdin registry.scout.docker.com
+```
+
+Then list attestations using the `--external` flag. DHI repositories store image
+layers on `dhi.io` (or `docker.io` for mirrored images) and signed attestations
+in `registry.scout.docker.com`:
+
+```console
+$ regctl artifact list docker.io/${DOCKER_ORG}/<image>:<tag> \
+  --external registry.scout.docker.com/${DOCKER_ORG}/<image> \
+  --platform linux/amd64
+```
+
+For example:
+
+```console
+$ regctl artifact list docker.io/${DOCKER_ORG}/dhi-node:22 \
+  --external registry.scout.docker.com/${DOCKER_ORG}/dhi-node \
+  --platform linux/amd64
+```
+
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Retrieve a specific attestation
+
+{{< tabs group="tool" >}}
+{{< tab name="Docker Scout" >}}
+
+To retrieve a specific attestation, use the `--predicate-type` flag with the full predicate type URI:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://cyclonedx.org/bom/v1.6 \
+  dhi.io/<image>:<tag>
+```
+
+> [!NOTE]
+>
+> If the image exists locally on your device, you must prefix the image name with `registry://`. For example, use
+> `registry://dhi.io/python:3.13` instead of `dhi.io/python:3.13`.
+
+For example:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://cyclonedx.org/bom/v1.6 \
+  dhi.io/python:3.13
+```
+
+To retrieve only the predicate body:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://cyclonedx.org/bom/v1.6 \
+  --predicate \
+  dhi.io/<image>:<tag>
+```
+
+{{< /tab >}}
+{{< tab name="regctl" >}}
+
+Once you've listed attestations, download the full attestation artifact using the digest from the `Name` field:
+
+```console
+$ regctl artifact get <attestation-digest> > attestation.json
+```
+
+For example, to save a SLSA provenance attestation:
+
+```console
+$ regctl artifact get registry.scout.docker.com/${DOCKER_ORG}/dhi-node@sha256:6cbf803796e281e535f2681de7cd33a1012202610322a50ee745d1bb02ac3c18 > slsa_provenance.json
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Validate the attestation
+
+{{< tabs >}}
+{{< tab name="Docker Scout" >}}
+
+To validate the attestation using Docker Scout, you can use the `--verify` flag:
+
+```console
+$ docker scout attest get dhi.io/<image>:<tag> \
+   --predicate-type https://scout.docker.com/sbom/v0.1 --verify
+```
+
+> [!NOTE]
+>
+> If the image exists locally on your device, you must prefix the image name
+> with `registry://`. For example, use `registry://dhi.io/node:20.19-debian12`
+> instead of `dhi.io/node:20.19-debian12`.
+
+
+For example, to verify the SBOM attestation for the `dhi.io/node:20.19-debian12` image:
+
+```console
+$ docker scout attest get dhi.io/node:20.19-debian12 \
+   --predicate-type https://scout.docker.com/sbom/v0.1 --verify
+```
+
+{{< /tab >}}
+{{< tab name="cosign" >}}
+
+Once you've listed the attestations and obtained the digest from the `Name` field, verify them using cosign:
+
+```console
+$ cosign verify \
+  <attestation-digest-from-name-field> \
+  --key https://registry.scout.docker.com/keyring/dhi/latest.pub \
+  --insecure-ignore-tlog=true
+```
+
+For example:
+
+```console
+$ cosign verify \
+  registry.scout.docker.com/${DOCKER_ORG}/dhi-node@sha256:6cbf803796e281e535f2681de7cd33a1012202610322a50ee745d1bb02ac3c18 \
+  --key https://registry.scout.docker.com/keyring/dhi/latest.pub \
+  --insecure-ignore-tlog=true
+```
+
+> [!NOTE]
+>
+> The `--insecure-ignore-tlog=true` flag is needed because DHI attestations
+> may not be recorded in the public Rekor transparency log to protect private
+> customer information. The attestation signature is still verified against
+> Docker's public key.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+#### Handle missing transparency log entries
+
+When using `--verify` with Docker Scout or `cosign verify`, you may sometimes
+see an error like:
+
+```text
+ERROR no matching signatures: signature not found in transparency log
+```
+
+This occurs because Docker Hardened Images don't always record attestations in
+the public [Rekor](https://docs.sigstore.dev/logging/overview/) transparency
+log. In cases where an attestation would contain private user information (for
+example, your organization's namespace in the image reference), writing it to
+Rekor would expose that information publicly.
+
+Even if the Rekor entry is missing, the attestation is still signed with
+Docker's public key and can be verified offline by skipping the Rekor
+transparency log check.
+
+To skip the transparency log check and validate against Docker's key, use the
+`--skip-tlog` flag:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://cyclonedx.org/bom/v1.6 \
+  dhi.io/<image>:<tag> \
+  --verify --skip-tlog
+```
+
+> [!NOTE]
+>
+> The `--skip-tlog` flag is only available in Docker Scout CLI version 1.18.2 and
+> later.
+>
+> If the image exists locally on your device, you must prefix the image name with `registry://`. For example, use
+> `registry://dhi.io/python:3.13` instead of `dhi.io/python:3.13`.
+
+
+This is equivalent to using `cosign` with the `--insecure-ignore-tlog=true`
+flag, which validates the signature against Docker's published public key, but
+ignores the transparency log check.
+
+### Show the equivalent cosign command
+
+When using the `--verify` flag, it also prints the corresponding
+[cosign](https://docs.sigstore.dev/) command to verify the image signature:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://cyclonedx.org/bom/v1.6 \
+  --verify \
+  dhi.io/<image>:<tag>
+```
+
+> [!NOTE]
+>
+> If the image exists locally on your device, you must prefix the image name with `registry://`. For example, use
+> `registry://dhi.io/python:3.13` instead of `dhi.io/python:3.13`.
+
+For example:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://cyclonedx.org/bom/v1.6 \
+  --verify \
+  dhi.io/python:3.13
+```
+
+If verification succeeds, Docker Scout prints the full `cosign verify` command.
+
+Example output:
+
+```console
+    v SBOM obtained from attestation, 101 packages found
+    v Provenance obtained from attestation
+    v cosign verify ...
+```
+
+> [!IMPORTANT]
+>
+> When using cosign, you must first authenticate to both the DHI registry
+> and the Docker Scout registry.
+>
+> For example:
+>
+> ```console
+> $ docker login dhi.io
+> $ docker login registry.scout.docker.com
+> $ cosign verify ...
+> ```
+
+## Verify package attestations
+
+In addition to image attestations, individual hardened packages have their own
+attestations. These package-level attestations allow you to verify the
+provenance and build information for specific packages within an image.
+
+For instructions on how to extract package information from image attestations
+and retrieve package-level attestations, see [Package
+attestations](./hardened-packages.md#package-attestations).
+
+## Verify Helm chart attestations with Docker Scout
+
+Docker Hardened Image Helm charts include the same comprehensive attestations
+as container images. The verification process for charts is identical to that
+for images, using the same Docker Scout CLI commands.
+
+### List available chart attestations
+
+To list attestations for a DHI Helm chart:
+
+```console
+$ docker scout attest list dhi.io/<chart>:<version>
+```
+
+For example, to list attestations for the external-dns chart:
+
+```console
+$ docker scout attest list dhi.io/external-dns-chart:1.20.0
+```
+
+This command shows all available chart attestations, including SBOMs, provenance, vulnerability reports, and more.
+
+### Retrieve a specific chart attestation
+
+To retrieve a specific attestation from a Helm chart, use the `--predicate-type` flag with the full predicate type URI:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://cyclonedx.org/bom/v1.6 \
+  dhi.io/<chart>:<version>
+```
+
+For example:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://cyclonedx.org/bom/v1.6 \
+  dhi.io/external-dns-chart:1.20.0
+```
+
+To retrieve only the predicate body:
+
+```console
+$ docker scout attest get \
+  --predicate-type https://cyclonedx.org/bom/v1.6 \
+  --predicate \
+  dhi.io/<chart>:<version>
+```
+
+### Validate chart attestations with Docker Scout
+
+To validate a chart attestation using Docker Scout, use the `--verify` flag:
+
+```console
+$ docker scout attest get dhi.io/<chart>:<version> \
+   --predicate-type https://scout.docker.com/sbom/v0.1 --verify
+```
+
+For example, to verify the SBOM attestation for the external-dns chart:
+
+```console
+$ docker scout attest get dhi.io/external-dns-chart:1.20.0 \
+   --predicate-type https://scout.docker.com/sbom/v0.1 --verify
+```
+
+The same `--skip-tlog` flag described in [Handle missing transparency log
+entries](#handle-missing-transparency-log-entries) can also be used with chart
+attestations when needed.
+
+## Available DHI attestations
+
+See [available
+attestations](../explore/security-concepts/attestations.md#image-attestations) for a list
+of attestations available for each DHI image and [Helm chart
+attestations](../explore/security-concepts/attestations.md#helm-chart-attestations) for a
+list of attestations available for each DHI chart.
+
+## Explore attestations on Docker Hub
+
+You can also browse attestations visually when [exploring an image
+variant](./search-evaluate.md#image-variant-details). The **Attestations** section
+lists each available attestation with its:
+
+- Type (e.g. SBOM, VEX)
+- Predicate type URI
+- Digest reference for use with `cosign`
+
+These attestations are generated and signed automatically as part of the Docker
+Hardened Image or chart build process.
\ No newline at end of file
diff --git a/content/manuals/dhi/how-to/vex-api.md b/content/manuals/dhi/how-to/vex-api.md
new file mode 100644
index 000000000000..9739e2a8ca34
--- /dev/null
+++ b/content/manuals/dhi/how-to/vex-api.md
@@ -0,0 +1,208 @@
+---
+title: Query VEX for a Docker Hardened Image
+linktitle: Query VEX suppressions via API
+description: Use the DHI GraphQL API to fetch VEX statements and suppressed CVEs for a Docker Hardened Image by digest.
+keywords: dhi vex api, graphql api, suppressed cves, base vex, image digest, docker hardened images
+weight: 47
+---
+
+This is a guided example of using the [DHI API](/manuals/dhi/tools/api.md)
+to fetch VEX statements and suppressed CVEs for a Docker Hardened Image (DHI)
+by digest, using the `imagePackagesForImageCoords` query. The query takes an
+image digest and returns every package, every CVE reported against it,
+whether Docker suppresses that CVE, and why.
+
+> [!NOTE]
+> For one-off lookups or local scanning workflows, [`docker scout vex
+> get`](/manuals/dhi/how-to/scan.md#export-vex-attestations) may be simpler.
+> Use the API described here when you need to query many images
+> programmatically.
+
+For the API endpoint and authentication, see [Use the DHI
+API](/manuals/dhi/tools/api.md). This page assumes you already have a valid
+token.
+
+## Query suppressed CVEs
+
+This is the `imagePackagesForImageCoords` query used in this example. It
+fetches every package in an image, every CVE reported against it, and
+whether Docker suppresses that CVE:
+
+```graphql
+query BaseVex($ctx: Context!, $q: IpImagePackagesForImageCoordsQuery!) {
+  imagePackagesForImageCoords(context: $ctx, query: $q) {
+    imagePackages {
+      packages {
+        package {
+          purl
+          name
+          version
+          vulnerabilities {
+            sourceId
+            isExcepted
+            fixedBy
+            cvss {
+              severity
+            }
+            vulnerabilityExceptions {
+              id
+              sourceType
+              type
+              justification
+              additionalDetails
+              isDhiStatement
+            }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+With variables:
+
+```json
+{
+  "ctx": { "organization": "your-org" },
+  "q": {
+    "digest": "sha256:<platform-manifest-digest>",
+    "hostName": "hub.docker.com",
+    "repoName": "your-org/your-repo",
+    "includeExcepted": true,
+    "includeNodsa": true
+  }
+}
+```
+
+For the full argument reference, see
+[`imagePackagesForImageCoords`](/manuals/dhi/tools/api.md#imagepackagesforimagecoords).
+
+### Get an access token
+
+Exchange your organization access token (OAT) or personal access token (PAT)
+for an access token, as described in [Use the DHI
+API](/manuals/dhi/tools/api.md#authentication):
+
+```console
+$ DHI_API_TOKEN=$(curl -s -X POST https://hub.docker.com/v2/auth/token \
+  -H "Content-Type: application/json" \
+  -d "{\"identifier\": \"<identifier>\", \"secret\": \"<token>\"}" \
+  | jq -r .access_token)
+```
+
+Use your Docker Hub username as `identifier` for a PAT, or your organization
+name for an OAT.
+
+### Send the request
+
+Combine the query and variables into the request body described in [Use the
+DHI API](/manuals/dhi/tools/api.md#request-format). The following example
+uses `jq` to build the body safely, since the query spans multiple lines:
+
+```console
+$ QUERY='query BaseVex($ctx: Context!, $q: IpImagePackagesForImageCoordsQuery!) {
+  imagePackagesForImageCoords(context: $ctx, query: $q) {
+    imagePackages {
+      packages {
+        package {
+          purl
+          name
+          version
+          vulnerabilities {
+            sourceId
+            isExcepted
+            fixedBy
+            cvss {
+              severity
+            }
+            vulnerabilityExceptions {
+              id
+              sourceType
+              type
+              justification
+              additionalDetails
+              isDhiStatement
+            }
+          }
+        }
+      }
+    }
+  }
+}'
+
+$ curl https://api.dso.docker.com/v1/graphql \
+  -H "Authorization: Bearer $DHI_API_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d "$(jq -n --arg query "$QUERY" '{
+    query: $query,
+    variables: {
+      ctx: { organization: "your-org" },
+      q: {
+        digest: "sha256:<platform-manifest-digest>",
+        hostName: "hub.docker.com",
+        repoName: "your-org/your-repo",
+        includeExcepted: true,
+        includeNodsa: true
+      }
+    }
+  }')"
+```
+
+Substitute your organization, digest, host, and repository.
+
+## Sample response
+
+The following example is trimmed to a single package:
+
+```json
+{
+  "package": {
+    "purl": "pkg:deb/debian/tar@1.35%2Bdfsg-3.1%2Bdhi1?os_distro=trixie&os_name=debian&os_version=13",
+    "name": "tar",
+    "version": "1.35+dfsg-3.1+dhi1",
+    "vulnerabilities": [
+      {
+        "sourceId": "CVE-2025-45582",
+        "cvss": { "severity": "MEDIUM" },
+        "fixedBy": null,
+        "isExcepted": false,
+        "vulnerabilityExceptions": []
+      },
+      {
+        "sourceId": "CVE-2026-18477",
+        "cvss": { "severity": "MEDIUM" },
+        "fixedBy": null,
+        "isExcepted": true,
+        "vulnerabilityExceptions": [
+          {
+            "id": "debian-nodsa-CVE-2026-18477",
+            "sourceType": "EXTERNAL",
+            "type": "FALSE_POSITIVE",
+            "justification": null,
+            "additionalDetails": "Debian NODSA",
+            "isDhiStatement": false
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+Use `isExcepted` to tell whether a CVE is suppressed. For the full response
+field reference and the OpenVEX mapping, see
+[`imagePackagesForImageCoords`](/manuals/dhi/tools/api.md#imagepackagesforimagecoords).
+
+## Query customization images
+
+DHI VEX statements apply directly to images built with the [customization
+feature](/manuals/dhi/how-to/customize.md). Query the customized image's own
+digest to get its packages, CVEs, and suppressions in a single call. You
+don't need to query the base image separately.
+
+## Caveats
+
+The suppression set for a given digest can change as new advisories and
+assessments are published. Cache results per digest with a short TTL rather
+than treating a response as permanent.
diff --git a/content/manuals/dhi/migration/_index.md b/content/manuals/dhi/migration/_index.md
new file mode 100644
index 000000000000..7cfc79d13882
--- /dev/null
+++ b/content/manuals/dhi/migration/_index.md
@@ -0,0 +1,53 @@
+---
+title: Migration
+description: Learn how to migrate your existing applications to Docker Hardened Images
+weight: 18
+keywords: migrate, docker hardened images, dhi, migration guide
+aliases:
+  - /dhi/how-to/migrate/
+params:
+  grid_migration_paths:
+    - title: Migrate with Gordon
+      description: Use Gordon to automatically migrate your Dockerfile to Docker Hardened Images with guidance and recommendations.
+      icon: sparkles
+      link: /dhi/migration/migrate-with-ai/
+    - title: Migrate from Alpine or Debian images
+      description: Manual migration guide for moving from Docker Official Images (Alpine or Debian-based) to Docker Hardened Images.
+      icon: code-bracket
+      link: /dhi/migration/migrate-from-doi/
+    - title: Migrate from Ubuntu
+      description: Manual migration guide for transitioning from Ubuntu-based images to Docker Hardened Images.
+      icon: arrow-up-circle
+      link: /dhi/migration/migrate-from-ubuntu/
+    - title: Migrate from Wolfi
+      description: Manual migration guide for transitioning from Wolfi-based images to Docker Hardened Images.
+      icon: arrow-path
+      link: /dhi/migration/migrate-from-wolfi/
+  
+  grid_migration_resources:
+    - title: Migration checklist
+      description: A comprehensive checklist of migration considerations to ensure successful transition to Docker Hardened Images.
+      icon: clipboard-document-check
+      link: /dhi/migration/checklist/
+    - title: Examples
+      description: Example Dockerfile migrations for different programming languages and frameworks to guide your migration process.
+      icon: eye
+      link: /dhi/migration/examples/
+---
+
+This section provides guidance for migrating your applications to Docker
+Hardened Images (DHI). Migrating to DHI enhances the security posture of your
+containerized applications by leveraging hardened base images with built-in
+security features.
+
+## Migration paths
+
+Choose the migration approach that best fits your needs:
+
+{{< grid items="grid_migration_paths" >}}
+
+## Resources
+
+{{< grid items="grid_migration_resources" >}}
+
+
diff --git a/content/manuals/dhi/migration/checklist.md b/content/manuals/dhi/migration/checklist.md
new file mode 100644
index 000000000000..fc6034356f58
--- /dev/null
+++ b/content/manuals/dhi/migration/checklist.md
@@ -0,0 +1,21 @@
+---
+title: Migration checklist
+description: A checklist of considerations when migrating to Docker Hardened Images
+weight: 10
+keywords: migration checklist, dhi, docker hardened images
+---
+
+Use this checklist to ensure you address key considerations when migrating to Docker Hardened Images.
+
+## Migration considerations
+
+| Item               | Action required                                                                                                                                                                                                                                                                                                                 |
+|:-------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Base image         | Update your Dockerfile `FROM` statements to reference a Docker Hardened Image instead of your current base image.                                                                                                                                                                                                                                                      |
+| Package management | Install packages only in `dev`-tagged images during build stages. Use `apk` for Alpine-based images or `apt` for Debian-based images. Copy the necessary artifacts to your runtime stage, as runtime images don't include package managers.                                                                                                                                                                        |
+| Non-root user      | Verify that all files and directories your application needs are readable and writable by the nonroot user (UID 65532), as runtime images run as nonroot by default.                                                                                                                                                                              |
+| Multi-stage build  | Use `dev` or `sdk`-tagged images for build stages where you need build tools and package managers. Use non-dev images for your final runtime stage.                                                                                                                                                                                                                                     |
+| TLS certificates   | Remove any steps that install ca-certificates, as DHIs include ca-certificates by default.                                                                                                                                                                                                                               |
+| Ports              | Configure your application to listen on port 1025 or higher inside the container, as the nonroot user can't bind to privileged ports (below 1024) in Kubernetes or Docker Engine versions older than 20.10. |
+| Entry point        | Check the entry point of your chosen DHI using `docker inspect` or the image documentation. Update your Dockerfile's `ENTRYPOINT` or `CMD` instructions if your application relies on a different entry point.                                                                                                                                                                        |
+| No shell           | Move any shell commands (`RUN`, `SHELL`) to build stages using `dev`-tagged images. Runtime images don't include a shell, so copy all necessary artifacts from the build stage.                                                                                                                                                                            |
diff --git a/content/manuals/dhi/migration/examples/_index.md b/content/manuals/dhi/migration/examples/_index.md
new file mode 100644
index 000000000000..fb35a8c58d37
--- /dev/null
+++ b/content/manuals/dhi/migration/examples/_index.md
@@ -0,0 +1,40 @@
+---
+title: Migration examples
+description: Real-world examples of migrating to Docker Hardened Images
+weight: 40
+keywords: migration examples, dhi, docker hardened images
+params:
+  grid_examples:
+    - title: Go
+      description: Learn how to migrate Go applications to Docker Hardened Images with practical examples and best practices.
+      icon: code-bracket
+      link: /dhi/migration/examples/go/
+    - title: Python
+      description: Learn how to migrate Python applications to Docker Hardened Images with practical examples and best practices.
+      icon: code-bracket
+      link: /dhi/migration/examples/python/
+    - title: Node.js
+      description: Learn how to migrate Node.js applications to Docker Hardened Images with practical examples and best practices.
+      icon: code-bracket
+      link: /dhi/migration/examples/node/
+    - title: .NET
+      description: Learn how to migrate .NET applications to Docker Hardened Images with practical examples and best practices.
+      icon: code-bracket
+      link: /dhi/migration/examples/dotnet/
+    - title: Java
+      description: Learn how to migrate Java applications to Docker Hardened Images with practical examples and best practices.
+      icon: code-bracket
+      link: /dhi/migration/examples/java/
+---
+
+This section provides detailed migration examples for common programming languages and frameworks.
+
+## Available examples
+
+{{< grid items="grid_examples" >}}
+
+In addition to this documentation, each Docker Hardened Image repository in
+the [Docker Hardened Images
+catalog](https://hub.docker.com/hardened-images/catalog) includes image-specific
+guidance and best practices for migrating applications built with that language
+or framework.
\ No newline at end of file
diff --git a/content/manuals/dhi/migration/examples/dotnet.md b/content/manuals/dhi/migration/examples/dotnet.md
new file mode 100644
index 000000000000..79cdee998e1a
--- /dev/null
+++ b/content/manuals/dhi/migration/examples/dotnet.md
@@ -0,0 +1,130 @@
+---
+title: .NET
+description: Migrate a .NET application to Docker Hardened Images
+weight: 40
+keywords: dotnet, .net, csharp, aspnet, migration, dhi
+---
+
+This example shows how to migrate a .NET application to Docker Hardened Images.
+
+The following examples show Dockerfiles before and after migration to Docker
+Hardened Images. Each example includes four variations:
+
+- Before (Wolfi): A sample Dockerfile using Wolfi distribution images, before migrating to DHI
+- Before (DOI): A sample Dockerfile using Docker Official Images, before migrating to DHI
+- After (multi-stage): A sample Dockerfile after migrating to DHI with multi-stage builds (recommended for minimal, secure images)
+- After (single-stage): A sample Dockerfile after migrating to DHI with single-stage builds (simpler but results in a larger image with a broader attack surface)
+
+> [!NOTE]
+>
+> Multi-stage builds are recommended for most use cases. Single-stage builds are
+> supported for simplicity, but come with tradeoffs in size and security.
+>
+> You must authenticate to `dhi.io` before you can pull Docker Hardened Images.
+> Use your Docker ID credentials (the same username and password you use for
+> Docker Hub). If you don't have a Docker account, [create
+> one](../../../accounts/create-account.md) for free.
+>
+> Run `docker login dhi.io` to authenticate.
+
+{{< tabs >}}
+{{< tab name="Before (Wolfi)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM cgr.dev/chainguard/dotnet-sdk:latest-dev AS builder
+
+WORKDIR /src
+COPY . ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache git
+
+RUN dotnet restore
+RUN dotnet publish -c Release -o /src/out --no-restore
+
+FROM cgr.dev/chainguard/aspnet-runtime:latest
+
+WORKDIR /app
+COPY --from=builder /src/out ./
+
+ENTRYPOINT ["dotnet", "app.dll"]
+```
+
+{{< /tab >}}
+{{< tab name="Before (DOI)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM mcr.microsoft.com/dotnet/sdk:8.0 AS builder
+
+WORKDIR /src
+COPY . ./
+
+# Install any additional packages if needed using apt
+# RUN apt-get update && apt-get install -y git && rm -rf /var/lib/apt/lists/*
+
+RUN dotnet restore
+RUN dotnet publish -c Release -o /app --no-restore
+
+FROM mcr.microsoft.com/dotnet/aspnet:8.0
+
+WORKDIR /app
+COPY --from=builder /app ./
+
+ENTRYPOINT ["dotnet", "app.dll"]
+```
+
+{{< /tab >}}
+{{< tab name="After (multi-stage)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+# === Build stage: Restore, build, and publish the .NET application ===
+FROM dhi.io/dotnet:8-sdk-alpine3.22 AS builder
+
+WORKDIR /src
+COPY . ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache git
+
+RUN dotnet restore
+RUN dotnet publish -c Release -o /app --no-restore
+
+# === Final stage: Create minimal runtime image ===
+FROM dhi.io/aspnetcore:8-alpine3.22
+
+WORKDIR /app
+COPY --from=builder /app ./
+
+ENTRYPOINT ["dotnet", "app.dll"]
+```
+
+{{< /tab >}}
+{{< tab name="After (single-stage)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM dhi.io/dotnet:8-sdk-alpine3.22
+
+WORKDIR /src
+COPY . ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache git
+
+RUN dotnet restore
+RUN dotnet publish -c Release -o /app --no-restore
+
+WORKDIR /app
+
+ENTRYPOINT ["dotnet", "/app/app.dll"]
+```
+
+{{< /tab >}}
+{{< /tabs >}}
diff --git a/content/manuals/dhi/migration/examples/go.md b/content/manuals/dhi/migration/examples/go.md
new file mode 100644
index 000000000000..3a42bdc50a9d
--- /dev/null
+++ b/content/manuals/dhi/migration/examples/go.md
@@ -0,0 +1,134 @@
+---
+title: Go
+description: Migrate a Go application to Docker Hardened Images
+weight: 10
+keywords: go, golang, migration, dhi
+---
+
+This example shows how to migrate a Go application to Docker Hardened Images.
+
+The following examples show Dockerfiles before and after migration to Docker
+Hardened Images. Each example includes five variations:
+
+- Before (Ubuntu): A sample Dockerfile using Ubuntu-based images, before migrating to DHI
+- Before (Wolfi): A sample Dockerfile using Wolfi distribution images, before migrating to DHI
+- Before (DOI): A sample Dockerfile using Docker Official Images, before migrating to DHI
+- After (multi-stage): A sample Dockerfile after migrating to DHI with multi-stage builds (recommended for minimal, secure images)
+- After (single-stage): A sample Dockerfile after migrating to DHI with single-stage builds (simpler but results in a larger image with a broader attack surface)
+
+> [!NOTE]
+>
+> Multi-stage builds are recommended for most use cases. Single-stage builds are
+> supported for simplicity, but come with tradeoffs in size and security.
+>
+> You must authenticate to `dhi.io` before you can pull Docker Hardened Images.
+> Use your Docker ID credentials (the same username and password you use for
+> Docker Hub). If you don't have a Docker account, [create
+> one](../../../accounts/create-account.md) for free.
+>
+> Run `docker login dhi.io` to authenticate.
+
+{{< tabs >}}
+{{< tab name="Before (Ubuntu)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM ubuntu/go:1.22-24.04
+
+WORKDIR /app
+ADD . ./
+
+# Install any additional packages if needed using apt
+# RUN apt-get update && apt-get install -y git && rm -rf /var/lib/apt/lists/*
+
+RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" --installsuffix cgo -o main .
+
+ENTRYPOINT ["/app/main"]
+```
+
+{{< /tab >}}
+{{< tab name="Before (Wolfi)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM cgr.dev/chainguard/go:latest-dev
+
+WORKDIR /app
+ADD . ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache git
+
+RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" --installsuffix cgo -o main .
+
+ENTRYPOINT ["/app/main"]
+```
+
+{{< /tab >}}
+{{< tab name="Before (DOI)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM golang:latest
+
+WORKDIR /app
+ADD . ./
+
+# Install any additional packages if needed using apt
+# RUN apt-get update && apt-get install -y git && rm -rf /var/lib/apt/lists/*
+
+RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" --installsuffix cgo -o main .
+
+ENTRYPOINT ["/app/main"]
+```
+
+{{< /tab >}}
+{{< tab name="After (multi-stage)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+# === Build stage: Compile Go application ===
+FROM dhi.io/golang:1.25-alpine3.23-dev AS builder
+
+WORKDIR /app
+ADD . ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache git
+
+RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" --installsuffix cgo -o main .
+
+# === Final stage: Create minimal runtime image ===
+FROM dhi.io/golang:1.25-alpine3.23
+
+WORKDIR /app
+COPY --from=builder /app/main  /app/main
+
+ENTRYPOINT ["/app/main"]
+```
+
+{{< /tab >}}
+{{< tab name="After (single-stage)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM dhi.io/golang:1.25-alpine3.23-dev
+
+WORKDIR /app
+ADD . ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache git
+
+RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" --installsuffix cgo -o main .
+
+ENTRYPOINT ["/app/main"]
+```
+
+{{< /tab >}}
+{{< /tabs >}}
diff --git a/content/manuals/dhi/migration/examples/java.md b/content/manuals/dhi/migration/examples/java.md
new file mode 100644
index 000000000000..bfae595dc48a
--- /dev/null
+++ b/content/manuals/dhi/migration/examples/java.md
@@ -0,0 +1,150 @@
+---
+title: Java
+description: Migrate a Java application to Docker Hardened Images
+weight: 50
+keywords: java, jvm, jdk, jre, maven, migration, dhi
+---
+
+This example shows how to migrate a Java application to Docker Hardened Images.
+
+The following examples show Dockerfiles before and after migration to Docker
+Hardened Images. Each example includes five variations:
+
+- Before (Ubuntu): A sample Dockerfile using Ubuntu-based images, before migrating to DHI
+- Before (Wolfi): A sample Dockerfile using Wolfi distribution images, before migrating to DHI
+- Before (DOI): A sample Dockerfile using Docker Official Images, before migrating to DHI
+- After (multi-stage): A sample Dockerfile after migrating to DHI with multi-stage builds (recommended for minimal, secure images)
+- After (single-stage): A sample Dockerfile after migrating to DHI with single-stage builds (simpler but results in a larger image with a broader attack surface)
+
+> [!NOTE]
+>
+> Multi-stage builds are recommended for most use cases. Single-stage builds are
+> supported for simplicity, but come with tradeoffs in size and security.
+>
+> You must authenticate to `dhi.io` before you can pull Docker Hardened Images.
+> Use your Docker ID credentials (the same username and password you use for
+> Docker Hub). If you don't have a Docker account, [create
+> one](../../../accounts/create-account.md) for free.
+>
+> Run `docker login dhi.io` to authenticate.
+
+{{< tabs >}}
+{{< tab name="Before (Ubuntu)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM ubuntu:24.04 AS builder
+
+WORKDIR /app
+COPY . ./
+
+RUN apt-get update && apt-get install -y default-jdk maven --no-install-recommends && rm -rf /var/lib/apt/lists/*
+
+RUN mvn -B package -DskipTests
+
+FROM ubuntu:24.04
+
+RUN apt-get update && apt-get install -y default-jre --no-install-recommends && rm -rf /var/lib/apt/lists/*
+
+WORKDIR /app
+COPY --from=builder /app/target/app.jar /app/app.jar
+
+ENTRYPOINT ["java", "-jar", "/app/app.jar"]
+```
+
+{{< /tab >}}
+{{< tab name="Before (Wolfi)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM cgr.dev/chainguard/maven:latest-dev AS builder
+
+WORKDIR /app
+COPY . ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache git
+
+RUN mvn -B package -DskipTests
+
+FROM cgr.dev/chainguard/jre:latest
+
+WORKDIR /app
+COPY --from=builder /app/target/app.jar /app/app.jar
+
+ENTRYPOINT ["java", "-jar", "/app/app.jar"]
+```
+
+{{< /tab >}}
+{{< tab name="Before (DOI)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM maven:3.9-eclipse-temurin-21 AS builder
+
+WORKDIR /app
+COPY . ./
+
+# Install any additional packages if needed using apt
+# RUN apt-get update && apt-get install -y git && rm -rf /var/lib/apt/lists/*
+
+RUN mvn -B package -DskipTests
+
+FROM eclipse-temurin:21-jre
+
+WORKDIR /app
+COPY --from=builder /app/target/app.jar /app/app.jar
+
+ENTRYPOINT ["java", "-jar", "/app/app.jar"]
+```
+
+{{< /tab >}}
+{{< tab name="After (multi-stage)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+# === Build stage: Compile and package the Java application with Maven ===
+FROM dhi.io/maven:3-jdk21-alpine3.22-dev AS builder
+
+WORKDIR /app
+COPY . ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache git
+
+RUN mvn -B package -DskipTests
+
+# === Final stage: Create minimal runtime image ===
+FROM dhi.io/eclipse-temurin:21-alpine3.22
+
+WORKDIR /app
+COPY --from=builder /app/target/app.jar /app/app.jar
+
+ENTRYPOINT ["java", "-jar", "/app/app.jar"]
+```
+
+{{< /tab >}}
+{{< tab name="After (single-stage)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM dhi.io/maven:3-jdk21-alpine3.22-dev
+
+WORKDIR /app
+COPY . ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache git
+
+RUN mvn -B package -DskipTests
+
+ENTRYPOINT ["java", "-jar", "/app/target/app.jar"]
+```
+
+{{< /tab >}}
+{{< /tabs >}}
diff --git a/content/manuals/dhi/migration/examples/node.md b/content/manuals/dhi/migration/examples/node.md
new file mode 100644
index 000000000000..3019df3f8d16
--- /dev/null
+++ b/content/manuals/dhi/migration/examples/node.md
@@ -0,0 +1,146 @@
+---
+title: Node.js
+description: Migrate a Node.js application to Docker Hardened Images
+weight: 30
+keywords: nodejs, node, migration, dhi
+---
+
+This example shows how to migrate a Node.js application to Docker Hardened Images.
+
+The following examples show Dockerfiles before and after migration to Docker
+Hardened Images. Each example includes five variations:
+
+- Before (Ubuntu): A sample Dockerfile using Ubuntu-based images, before migrating to DHI
+- Before (Wolfi): A sample Dockerfile using Wolfi distribution images, before migrating to DHI
+- Before (DOI): A sample Dockerfile using Docker Official Images, before migrating to DHI
+- After (multi-stage): A sample Dockerfile after migrating to DHI with multi-stage builds (recommended for minimal, secure images)
+- After (single-stage): A sample Dockerfile after migrating to DHI with single-stage builds (simpler but results in a larger image with a broader attack surface)
+
+> [!NOTE]
+>
+> Multi-stage builds are recommended for most use cases. Single-stage builds are
+> supported for simplicity, but come with tradeoffs in size and security.
+>
+> You must authenticate to `dhi.io` before you can pull Docker Hardened Images.
+> Use your Docker ID credentials (the same username and password you use for
+> Docker Hub). If you don't have a Docker account, [create
+> one](../../../accounts/create-account.md) for free.
+>
+> Run `docker login dhi.io` to authenticate.
+
+{{< tabs >}}
+{{< tab name="Before (Ubuntu)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM ubuntu:24.04
+
+RUN apt-get update && apt-get install -y nodejs npm --no-install-recommends && rm -rf /var/lib/apt/lists/*
+
+WORKDIR /usr/src/app
+
+COPY package*.json ./
+
+RUN npm install
+
+COPY . .
+
+CMD ["node", "index.js"]
+```
+
+{{< /tab >}}
+{{< tab name="Before (Wolfi)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM cgr.dev/chainguard/node:latest-dev
+WORKDIR /usr/src/app
+
+COPY package*.json ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache python3 make g++
+
+RUN npm install
+
+COPY . .
+
+CMD ["index.js"]
+```
+
+{{< /tab >}}
+{{< tab name="Before (DOI)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM node:latest
+WORKDIR /usr/src/app
+
+COPY package*.json ./
+
+# Install any additional packages if needed using apt
+# RUN apt-get update && apt-get install -y python3 make g++ && rm -rf /var/lib/apt/lists/*
+
+RUN npm install
+
+COPY . .
+
+CMD ["node", "index.js"]
+```
+
+{{< /tab >}}
+{{< tab name="After (multi-stage)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+# === Build stage: Install dependencies and build application ===
+FROM dhi.io/node:22-alpine3.23-dev AS builder
+WORKDIR /usr/src/app
+
+COPY package*.json ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache python3 make g++
+
+RUN npm install
+
+COPY . .
+
+# === Final stage: Create minimal runtime image ===
+FROM dhi.io/node:22-alpine3.23
+ENV PATH=/app/node_modules/.bin:$PATH
+
+COPY --from=builder --chown=node:node /usr/src/app /app
+
+WORKDIR /app
+
+CMD ["index.js"]
+```
+
+{{< /tab >}}
+{{< tab name="After (single-stage)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM dhi.io/node:22-alpine3.23-dev
+WORKDIR /usr/src/app
+
+COPY package*.json ./
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache python3 make g++
+
+RUN npm install
+
+COPY . .
+
+CMD ["node", "index.js"]
+```
+
+{{< /tab >}}
+{{< /tabs >}}
diff --git a/content/manuals/dhi/migration/examples/python.md b/content/manuals/dhi/migration/examples/python.md
new file mode 100644
index 000000000000..4ee4d327551c
--- /dev/null
+++ b/content/manuals/dhi/migration/examples/python.md
@@ -0,0 +1,207 @@
+---
+title: Python
+description: Migrate a Python application to Docker Hardened Images
+weight: 20
+keywords: python, migration, dhi
+---
+
+This example shows how to migrate a Python application to Docker Hardened Images.
+
+The following examples show Dockerfiles before and after migration to Docker
+Hardened Images. Each example includes five variations:
+
+- Before (Ubuntu): A sample Dockerfile using Ubuntu-based images, before migrating to DHI
+- Before (Wolfi): A sample Dockerfile using Wolfi distribution images, before migrating to DHI
+- Before (DOI): A sample Dockerfile using Docker Official Images, before migrating to DHI
+- After (multi-stage): A sample Dockerfile after migrating to DHI with multi-stage builds (recommended for minimal, secure images)
+- After (single-stage): A sample Dockerfile after migrating to DHI with single-stage builds (simpler but results in a larger image with a broader attack surface)
+
+> [!NOTE]
+>
+> Multi-stage builds are recommended for most use cases. Single-stage builds are
+> supported for simplicity, but come with tradeoffs in size and security.
+>
+> You must authenticate to `dhi.io` before you can pull Docker Hardened Images.
+> Use your Docker ID credentials (the same username and password you use for
+> Docker Hub). If you don't have a Docker account, [create
+> one](../../../accounts/create-account.md) for free.
+>
+> Run `docker login dhi.io` to authenticate.
+
+{{< tabs >}}
+{{< tab name="Before (Ubuntu)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM ubuntu:24.04 AS builder
+
+RUN apt-get update && apt-get install -y python3 python3-pip python3-venv --no-install-recommends && rm -rf /var/lib/apt/lists/*
+
+ENV LANG=C.UTF-8
+ENV PYTHONDONTWRITEBYTECODE=1
+ENV PYTHONUNBUFFERED=1
+ENV PATH="/app/venv/bin:$PATH"
+
+WORKDIR /app
+
+RUN python3 -m venv /app/venv
+COPY requirements.txt .
+
+RUN pip install --no-cache-dir -r requirements.txt
+
+FROM ubuntu:24.04
+
+RUN apt-get update && apt-get install -y python3 --no-install-recommends && rm -rf /var/lib/apt/lists/*
+
+WORKDIR /app
+
+ENV PYTHONUNBUFFERED=1
+ENV PATH="/app/venv/bin:$PATH"
+
+COPY app.py ./
+COPY --from=builder /app/venv /app/venv
+
+ENTRYPOINT [ "python3", "/app/app.py" ]
+```
+
+{{< /tab >}}
+{{< tab name="Before (Wolfi)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM cgr.dev/chainguard/python:latest-dev AS builder
+
+ENV LANG=C.UTF-8
+ENV PYTHONDONTWRITEBYTECODE=1
+ENV PYTHONUNBUFFERED=1
+ENV PATH="/app/venv/bin:$PATH"
+
+WORKDIR /app
+
+RUN python -m venv /app/venv
+COPY requirements.txt .
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache gcc musl-dev
+
+RUN pip install --no-cache-dir -r requirements.txt
+
+FROM cgr.dev/chainguard/python:latest
+
+WORKDIR /app
+
+ENV PYTHONUNBUFFERED=1
+ENV PATH="/app/venv/bin:$PATH"
+
+COPY app.py ./
+COPY --from=builder /app/venv /app/venv
+
+ENTRYPOINT [ "python", "/app/app.py" ]
+```
+
+{{< /tab >}}
+{{< tab name="Before (DOI)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM python:latest AS builder
+
+ENV LANG=C.UTF-8
+ENV PYTHONDONTWRITEBYTECODE=1
+ENV PYTHONUNBUFFERED=1
+ENV PATH="/app/venv/bin:$PATH"
+
+WORKDIR /app
+
+RUN python -m venv /app/venv
+COPY requirements.txt .
+
+# Install any additional packages if needed using apt
+# RUN apt-get update && apt-get install -y gcc && rm -rf /var/lib/apt/lists/*
+
+RUN pip install --no-cache-dir -r requirements.txt
+
+FROM python:latest
+
+WORKDIR /app
+
+ENV PYTHONUNBUFFERED=1
+ENV PATH="/app/venv/bin:$PATH"
+
+COPY app.py ./
+COPY --from=builder /app/venv /app/venv
+
+ENTRYPOINT [ "python", "/app/app.py" ]
+```
+
+{{< /tab >}}
+{{< tab name="After (multi-stage)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+# === Build stage: Install dependencies and create virtual environment ===
+FROM dhi.io/python:3.13-alpine3.23-dev AS builder
+
+ENV LANG=C.UTF-8
+ENV PYTHONDONTWRITEBYTECODE=1
+ENV PYTHONUNBUFFERED=1
+ENV PATH="/app/venv/bin:$PATH"
+
+WORKDIR /app
+
+RUN python -m venv /app/venv
+COPY requirements.txt .
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache gcc musl-dev
+
+RUN pip install --no-cache-dir -r requirements.txt
+
+# === Final stage: Create minimal runtime image ===
+FROM dhi.io/python:3.13-alpine3.23
+
+WORKDIR /app
+
+ENV PYTHONUNBUFFERED=1
+ENV PATH="/app/venv/bin:$PATH"
+
+COPY app.py ./
+COPY --from=builder /app/venv /app/venv
+
+ENTRYPOINT [ "python", "/app/app.py" ]
+```
+
+{{< /tab >}}
+{{< tab name="After (single-stage)" >}}
+
+```dockerfile
+#syntax=docker/dockerfile:1
+
+FROM dhi.io/python:3.13-alpine3.23-dev
+
+ENV LANG=C.UTF-8
+ENV PYTHONDONTWRITEBYTECODE=1
+ENV PYTHONUNBUFFERED=1
+ENV PATH="/app/venv/bin:$PATH"
+
+WORKDIR /app
+
+RUN python -m venv /app/venv
+COPY requirements.txt .
+
+# Install any additional packages if needed using apk
+# RUN apk add --no-cache gcc musl-dev
+
+RUN pip install --no-cache-dir -r requirements.txt
+
+COPY app.py ./
+
+ENTRYPOINT [ "python", "/app/app.py" ]
+```
+
+{{< /tab >}}
+{{< /tabs >}}
diff --git a/content/manuals/dhi/migration/migrate-from-doi.md b/content/manuals/dhi/migration/migrate-from-doi.md
new file mode 100644
index 000000000000..559967e003e2
--- /dev/null
+++ b/content/manuals/dhi/migration/migrate-from-doi.md
@@ -0,0 +1,114 @@
+---
+title: Migrate from Alpine or Debian
+description: Step-by-step guide to migrate from Docker Official Images to Docker Hardened Images
+weight: 20
+keywords: docker official images, doi, migration, dhi, alpine, debian
+---
+
+Docker Hardened Images (DHI) come in both [Alpine-based and Debian-based
+variants](../explore/available.md). In many cases, migrating from another image
+based on these distributions is as simple as changing the base image in your
+Dockerfile.
+
+This guide helps you migrate from an existing Alpine-based or Debian-based
+Docker Official Image (DOI) to DHI.
+
+If you're currently using a Debian-based Docker Official Image, migrate to the
+Debian-based DHI variant. If you're using an Alpine-based image, migrate to the
+Alpine-based DHI variant. This minimizes changes to package management and
+dependencies during migration.
+
+## Key differences
+
+When migrating from non-hardened images to DHI, be aware of these key differences:
+
+| Item               | Non-hardened images                                                                                                                                                                                                                                                                                                         | Docker Hardened Images                                                                                                                                                                                                                                                                                                         |
+|:-------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Package management | Package managers generally available in all images.                                                                                                                                                                                                                                  | Package managers generally only available in images with a `dev` tag. Runtime images don't contain package managers. Use multi-stage builds and copy necessary artifacts from the build stage to the runtime stage.                                                                  |
+| Non-root user      | Usually runs as root by default                                                                                                                                                                                                                                                                                                | Runtime variants run as the nonroot user by default. Ensure that necessary files and directories are accessible to the nonroot user.                                                                                                                                                                                                          |
+| Multi-stage build  | Optional                                                                                                                                                                                                                                                                                                                       | Recommended. Use images with a `dev` or `sdk` tags for build stages and non-dev images for runtime.                                                                                                                                                                                                                           |
+| TLS certificates   | May need to be installed                                                                                                                                                                                                                                                                                                       | Contain standard TLS certificates by default. There is no need to install TLS certificates.                                                                                                                                                                                                                                   |
+| Ports              | Can bind to privileged ports (below 1024) when running as root                                                                                                                                                                                                                                                                 | Run as a nonroot user by default. Applications can't bind to privileged ports (below 1024) when running in Kubernetes or in Docker Engine versions older than 20.10. Configure your application to listen on port 1025 or higher inside the container.                                                                        |
+| Entry point        | Varies by image                                                                                                                                                                                                                                                                                                                | May have different entry points than Docker Official Images. Inspect entry points and update your Dockerfile if necessary.                                                                                                                                                                                                    |
+| Shell           | Shell generally available in all images                                                                                                                                                                                                                                                                                                  | Runtime images don't contain a shell. Use `dev` images in build stages to run shell commands and then copy artifacts to the runtime stage.                                                                                                                                                                                      |
+
+## Migration steps
+
+### Step 1: Update the base image in your Dockerfile
+
+Update the base image in your application's Dockerfile to a hardened image. This
+is typically going to be an image tagged as `dev` or `sdk` because it has the tools
+needed to install packages and dependencies.
+
+The following example diff snippet from a Dockerfile shows the old base image
+replaced by the new hardened image.
+
+> [!NOTE]
+>
+> You must authenticate to `dhi.io` before you can pull Docker Hardened Images.
+> Use your Docker ID credentials (the same username and password you use for
+> Docker Hub). If you don't have a Docker account, [create
+> one](../../accounts/create-account.md) for free.
+>
+> Run `docker login dhi.io` to authenticate.
+
+
+```diff
+- ## Original base image
+- FROM golang:1.25
+
++ ## Updated to use hardened base image
++ FROM dhi.io/golang:1.25-debian13-dev
+```
+
+Note that DHI does not have a `latest` tag in order to promote best practices
+around image versioning. Ensure that you specify the appropriate version tag for
+your image. To find the right tag, explore the available tags in the [DHI
+Catalog](https://hub.docker.com/hardened-images/catalog/). In addition, the
+distribution base is specified in the tag (for example, `-alpine3.22` or
+`-debian12`), so be sure to select the correct variant for your application.
+
+### Step 2: Update the runtime image in your Dockerfile
+
+> [!NOTE]
+>
+> Multi-stage builds are recommended to keep your final image minimal and
+> secure. Single-stage builds are supported, but they include the full `dev` image
+> and therefore result in a larger image with a broader attack surface.
+
+To ensure that your final image is as minimal as possible, you should use a
+[multi-stage build](/manuals/build/building/multi-stage.md). All stages in your
+Dockerfile should use a hardened image. While intermediary stages will typically
+use images tagged as `dev` or `sdk`, your final runtime stage should use a runtime image.
+
+Utilize the build stage to compile your application and copy the resulting
+artifacts to the final runtime stage. This ensures that your final image is
+minimal and secure.
+
+The following example shows a multi-stage Dockerfile with a build stage and runtime stage:
+
+```dockerfile
+# Build stage
+FROM dhi.io/golang:1.25-debian13-dev AS builder
+WORKDIR /app
+COPY . .
+RUN go build -o myapp
+
+# Runtime stage
+FROM dhi.io/golang:1.25-debian13
+WORKDIR /app
+COPY --from=builder /app/myapp .
+ENTRYPOINT ["/app/myapp"]
+```
+
+After updating your Dockerfile, build and test your application. If you encounter
+issues, see the [Troubleshoot](/manuals/dhi/how-to/troubleshoot.md) guide for common
+problems and solutions.
+
+## Language-specific examples
+
+See the examples section for language-specific migration examples:
+
+- [Go](examples/go.md)
+- [Python](examples/python.md)
+- [Node.js](examples/node.md)
diff --git a/content/manuals/dhi/migration/migrate-from-ubuntu.md b/content/manuals/dhi/migration/migrate-from-ubuntu.md
new file mode 100644
index 000000000000..b061e791df46
--- /dev/null
+++ b/content/manuals/dhi/migration/migrate-from-ubuntu.md
@@ -0,0 +1,140 @@
+---
+title: Migrate from Ubuntu
+description: Step-by-step guide to migrate from Ubuntu-based images to Docker Hardened Images
+weight: 25
+keywords: ubuntu, migration, dhi, debian, docker hardened images
+---
+
+Docker Hardened Images (DHI) come in [Alpine-based and Debian-based
+variants](../explore/available.md). When migrating from an Ubuntu-based image,
+you should migrate to the Debian-based DHI variant, as both Ubuntu and Debian
+share the same package management system (APT) and underlying architecture,
+making migration straightforward.
+
+This guide helps you migrate from an existing Ubuntu-based image to DHI.
+
+## Key differences
+
+When migrating from Ubuntu-based images to DHI Debian, be aware of these key differences:
+
+| Item               | Ubuntu-based images                                                                                                                                                                                                                                                                                                         | Docker Hardened Images                                                                                                                                                                                                                                                                                                         |
+|:-------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Package management | Varies by image. Some include APT package manager, others don't                                                                                                                                                                                                  | Package managers generally only available in images with a `dev` tag. Runtime images don't contain package managers. Use multi-stage builds and copy necessary artifacts from the build stage to the runtime stage.                                                                  |
+| Non-root user      | Varies by image. Some run as root, others as non-root                                                                                                                                                                                                                                                                                                | Runtime variants run as the nonroot user by default. Ensure that necessary files and directories are accessible to the nonroot user.                                                                                                                                                                                                          |
+| Multi-stage build  | Recommended                                                                                                                                                                                                                                                                                                                       | Recommended. Use images with a `dev` or `sdk` tags for build stages and non-dev images for runtime.                                                                                                                                                                                                                           |
+| Ports              | Can bind to privileged ports (under 1024) when running as root                                                                                                                                                                                                                                                                 | Run as a nonroot user by default. Applications can't bind to privileged ports (under 1024) when running in Kubernetes or in Docker Engine versions older than 20.10. Configure your application to listen on port 1025 or higher inside the container.                                                                        |
+| Entry point        | Varies by image                                                                                                                                                                                                                                                                                                                | May have different entry points than Ubuntu-based images. Inspect entry points and update your Dockerfile if necessary.                                                                                                                                                                                                    |
+| Shell              | Varies by image. Some include a shell, others don't                                                                                                                                                                                                                                                                                                  | Runtime images don't contain a shell. Use `dev` images in build stages to run shell commands and then copy artifacts to the runtime stage.                                                                                                                                                                                      |
+| Package repositories | Uses Ubuntu package repositories                                                                                                                                                                                                                                                                                                  | Uses Debian package repositories. Most packages have similar names, but some may differ.                                                                                                                                                                                      |
+
+## Migration steps
+
+### Step 1: Update the base image in your Dockerfile
+
+Update the base image in your application's Dockerfile to a hardened image. This
+is typically going to be an image tagged as `dev` or `sdk` because it has the tools
+needed to install packages and dependencies.
+
+The following example diff snippet from a Dockerfile shows the old Ubuntu-based image
+replaced by the new DHI Debian image.
+
+> [!NOTE]
+>
+> You must authenticate to `dhi.io` before you can pull Docker Hardened Images.
+> Use your Docker ID credentials (the same username and password you use for
+> Docker Hub). If you don't have a Docker account, [create
+> one](../../accounts/create-account.md) for free.
+>
+> Run `docker login dhi.io` to authenticate.
+
+
+```diff
+- ## Original Ubuntu-based image
+- FROM ubuntu/go:1.22-24.04
+
++ ## Updated to use hardened Debian-based image
++ FROM dhi.io/golang:1.25-debian13-dev
+```
+
+To find the right tag, explore the available tags in the [DHI
+Catalog](https://hub.docker.com/hardened-images/catalog/).
+
+### Step 2: Update package installation commands
+
+Since Ubuntu and Debian both use APT for package management, most package
+installation commands remain similar. However, you need to ensure that package
+installations only occur in `dev` or `sdk` images, as runtime images don't
+contain package managers.
+
+```diff
+- ## Ubuntu: Installing packages
+- FROM ubuntu/go:1.22-24.04
+- RUN apt-get update && apt-get install -y \
+-     git \
+-     && rm -rf /var/lib/apt/lists/*
+
++ ## DHI: Use a language-specific dev image with package manager
++ FROM dhi.io/golang:1.25-debian13-dev
++ RUN apt-get update && apt-get install -y \
++     git \
++     && rm -rf /var/lib/apt/lists/*
+```
+
+Most Ubuntu packages are available in Debian with the same names. If you
+encounter missing packages, you can search for equivalent packages using the
+[Debian package search](https://packages.debian.org/) website.
+
+### Step 3: Update the runtime image in your Dockerfile
+
+> [!NOTE]
+>
+> Multi-stage builds are recommended to keep your final image minimal and
+> secure. Single-stage builds are supported, but they include the full `dev` image
+> and therefore result in a larger image with a broader attack surface.
+
+To ensure that your final image is as minimal as possible, you should use a
+[multi-stage build](/manuals/build/building/multi-stage.md). All stages in your
+Dockerfile should use a hardened image. While intermediary stages will typically
+use images tagged as `dev` or `sdk`, your final runtime stage should use a runtime image.
+
+Utilize the build stage to install dependencies and prepare your application,
+then copy the resulting artifacts to the final runtime stage. This ensures that
+your final image is minimal and secure.
+
+The following example shows a multi-stage Dockerfile migrating from Ubuntu to DHI Debian:
+
+```dockerfile
+# Build stage
+FROM dhi.io/golang:1.25-debian13-dev AS builder
+WORKDIR /app
+
+# Install system dependencies (only available in dev images)
+RUN apt-get update && apt-get install -y \
+    git \
+    && rm -rf /var/lib/apt/lists/*
+
+# Copy application files
+COPY go.mod go.sum ./
+RUN go mod download
+
+COPY . .
+RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" -o main .
+
+# Runtime stage
+FROM dhi.io/golang:1.25-debian13
+WORKDIR /app
+
+# Copy compiled binary from builder
+COPY --from=builder /app/main /app/main
+
+# Run the application
+ENTRYPOINT ["/app/main"]
+```
+
+## Language-specific examples
+
+See the examples section for language-specific migration examples:
+
+- [Go](examples/go.md)
+- [Python](examples/python.md)
+- [Node.js](examples/node.md)
diff --git a/content/manuals/dhi/migration/migrate-from-wolfi.md b/content/manuals/dhi/migration/migrate-from-wolfi.md
new file mode 100644
index 000000000000..d291653e2b40
--- /dev/null
+++ b/content/manuals/dhi/migration/migrate-from-wolfi.md
@@ -0,0 +1,95 @@
+---
+title: Migrate from Wolfi
+description: Step-by-step guide to migrate from Wolfi distribution images to Docker Hardened Images
+weight: 30
+keywords: wolfi, chainguard, migration, dhi
+---
+
+This guide helps you migrate from Wolfi-based images to Docker Hardened
+Images (DHI). Generally, the migration process is straightforward since Wolfi is
+Alpine-like and DHI provides an Alpine-based hardened image.
+
+Like other hardened images, DHI provides comprehensive
+[attestations](/dhi/explore/security-concepts/attestations/) including SBOMs and provenance,
+allowing you to [verify](/manuals/dhi/how-to/verify.md) image signatures and
+[scan](/manuals/dhi/how-to/scan.md) for vulnerabilities to ensure the security
+and integrity of your images.
+
+## Migration steps
+
+The following example demonstrates how to migrate a Dockerfile from a
+Wolfi-based image to an Alpine-based Docker Hardened Image.
+
+### Step 1: Update the base image in your Dockerfile
+
+Update the base image in your application's Dockerfile to a hardened image. This
+is typically going to be an image tagged as `dev` or `sdk` because it has the tools
+needed to install packages and dependencies.
+
+The following example diff snippet from a Dockerfile shows the old base image
+replaced by the new hardened image.
+
+> [!NOTE]
+>
+> You must authenticate to `dhi.io` before you can pull Docker Hardened Images.
+> Use your Docker ID credentials (the same username and password you use for
+> Docker Hub). If you don't have a Docker account, [create
+> one](../../accounts/create-account.md) for free.
+>
+> Run `docker login dhi.io` to authenticate.
+
+```diff
+- ## Original base image
+- FROM cgr.dev/chainguard/go:latest-dev
+
++ ## Updated to use hardened base image
++ FROM dhi.io/golang:1.25-alpine3.24-dev
+```
+
+Note that DHI does not have a `latest` tag in order to promote best practices
+around image versioning. Ensure that you specify the appropriate version tag for your image. To find the right tag, explore the available tags in the [DHI Catalog](https://hub.docker.com/hardened-images/catalog/).
+
+### Step 2: Update the runtime image in your Dockerfile
+
+> [!NOTE]
+>
+> Multi-stage builds are recommended to keep your final image minimal and
+> secure. Single-stage builds are supported, but they include the full `dev` image
+> and therefore result in a larger image with a broader attack surface.
+
+To ensure that your final image is as minimal as possible, you should use a
+[multi-stage build](/manuals/build/building/multi-stage.md). All stages in your
+Dockerfile should use a hardened image. While intermediary stages will typically
+use images tagged as `dev` or `sdk`, your final runtime stage should use a runtime image.
+
+Utilize the build stage to compile your application and copy the resulting
+artifacts to the final runtime stage. This ensures that your final image is
+minimal and secure.
+
+The following example shows a multi-stage Dockerfile with a build stage and runtime stage:
+
+```dockerfile
+# Build stage
+FROM dhi.io/golang:1.25-alpine3.24-dev AS builder
+WORKDIR /app
+COPY . .
+RUN go build -o myapp
+
+# Runtime stage
+FROM dhi.io/golang:1.25-alpine3.24
+WORKDIR /app
+COPY --from=builder /app/myapp .
+ENTRYPOINT ["/app/myapp"]
+```
+
+After updating your Dockerfile, build and test your application. If you encounter
+issues, see the [Troubleshoot](/manuals/dhi/how-to/troubleshoot.md) guide for common
+problems and solutions.
+
+## Language-specific examples
+
+See the examples section for language-specific migration examples:
+
+- [Go](examples/go.md)
+- [Python](examples/python.md)
+- [Node.js](examples/node.md)
diff --git a/content/manuals/dhi/migration/migrate-with-ai.md b/content/manuals/dhi/migration/migrate-with-ai.md
new file mode 100644
index 000000000000..edc075c03ea9
--- /dev/null
+++ b/content/manuals/dhi/migration/migrate-with-ai.md
@@ -0,0 +1,42 @@
+--- 
+title: Migrate using Gordon
+linktitle: AI-assisted migration
+description: Use Gordon to automatically migrate your Dockerfile to Docker Hardened Images
+weight: 15
+keywords: ai assistant, migrate dockerfile, docker hardened images, automated migration
+params:
+  sidebar:
+    badge:
+      color: violet
+      text: Experimental
+---
+
+{{< summary-bar feature_name="Gordon DHI migration" >}}
+
+You can use Gordon to automatically migrate your
+Dockerfile to use Docker Hardened Images (DHI).
+
+1. Ensure Gordon is [enabled](/manuals/ai/gordon.md#enable-ask-gordon).
+2. In the terminal, navigate to the directory containing your Dockerfile.
+3. Start a conversation with the assistant:
+   ```bash
+   docker ai
+   ```
+4. Type:
+   ```console
+   "Migrate my dockerfile to DHI"
+   ```
+5. Follow the conversation with the assistant. The assistant will edit your Dockerfile, so when
+   it requests access to the filesystem and more, type `yes` to allow the assistant to proceed.
+
+When the migration is complete, you see a success message:
+
+```text
+The migration to Docker Hardened Images (DHI) is complete. The updated Dockerfile
+successfully builds the image, and no vulnerabilities were detected in the final image.
+The functionality and optimizations of the original Dockerfile have been preserved.
+```
+
+> [!IMPORTANT]
+>
+> As with any AI tool, you must verify the assistant's edits and test your image.
diff --git a/content/manuals/dhi/release-notes/_index.md b/content/manuals/dhi/release-notes/_index.md
new file mode 100644
index 000000000000..851969c4d894
--- /dev/null
+++ b/content/manuals/dhi/release-notes/_index.md
@@ -0,0 +1,6 @@
+---
+build:
+  render: never
+title: Release notes
+weight: 999
+---
diff --git a/content/manuals/dhi/release-notes/cli.md b/content/manuals/dhi/release-notes/cli.md
new file mode 100644
index 000000000000..fb51db6e001c
--- /dev/null
+++ b/content/manuals/dhi/release-notes/cli.md
@@ -0,0 +1,112 @@
+---
+title: DHI CLI release notes
+linkTitle: CLI release notes
+description: New features, bug fixes, and changes in the DHI CLI
+keywords: docker hardened images, dhi, dhictl, cli, release notes, changelog
+toc_min: 1
+toc_max: 2
+tags:
+  - Release notes
+---
+
+This page lists changes in recent stable releases of the DHI CLI (`docker dhi`). For
+the full release history, including pre-releases and downloads, see the
+[dhictl releases on GitHub](https://github.com/docker-hardened-images/dhictl/releases).
+
+<!-- BEGIN GENERATED RELEASES -->
+
+## 0.0.7
+
+{{< release-date date="2026-07-21" >}}
+
+[GitHub release](https://github.com/docker-hardened-images/dhictl/releases/tag/v0.0.7)
+
+### Bug Fixes
+
+- Fixes JSON output incorrectly escaping ampersands as `\u0026` — values such as catalog categories containing `&` now appear as-is in output
+
+## 0.0.6
+
+{{< release-date date="2026-07-13" >}}
+
+[GitHub release](https://github.com/docker-hardened-images/dhictl/releases/tag/v0.0.6)
+
+This release fixes an issue that prevented customizations from being created via the CLI.
+
+### Bug Fixes
+
+- Fixes `dhictl customization create` failing when GraphQL rejected mutation inputs that incorrectly included the output-only `__typename` field from OCI artifact data
+
+## 0.0.5
+
+{{< release-date date="2026-06-29" >}}
+
+[GitHub release](https://github.com/docker-hardened-images/dhictl/releases/tag/v0.0.5)
+
+Maintenance release with dependency updates.
+
+## 0.0.4
+
+{{< release-date date="2026-05-25" >}}
+
+[GitHub release](https://github.com/docker-hardened-images/dhictl/releases/tag/v0.0.4)
+
+### What's New
+
+- Adds `deb` subcommand for DHI DEB repositories that emits netrc-style credentials for authenticating against DHI DEB repositories
+
+## 0.0.3
+
+{{< release-date date="2026-04-22" >}}
+
+[GitHub release](https://github.com/docker-hardened-images/dhictl/releases/tag/v0.0.3)
+
+### What's New
+
+- Adds attestation list and get commands for managing attestations
+- Adds SBOM subcommand for software bill of materials attestation
+- Adds bulk support to prepare command for customizations
+- Adds compression field support for customizations
+- Adds tag-definition-id column to catalog get output
+
+### Breaking change
+
+We removed the `--output` flags from the few commands that had it (`customization prepare` and `customization get`) in favor of stdout redirections.
+```console
+# before
+dhictl customization prepare --org my-org golang 1.25 --output my-customization.yaml
+
+# after 
+dhictl customization prepare --org my-org golang 1.25 > my-customization.yaml
+```
+
+## 0.0.2
+
+{{< release-date date="2026-03-19" >}}
+
+[GitHub release](https://github.com/docker-hardened-images/dhictl/releases/tag/v0.0.2)
+
+This is a maintenance release focused on build system improvements.
+
+### Technical Changes
+
+- Disables CGO globally to fix macOS 16 dyld crash and simplify build process
+
+## 0.0.1
+
+{{< release-date date="2026-03-12" >}}
+
+[GitHub release](https://github.com/docker-hardened-images/dhictl/releases/tag/v0.0.1)
+
+This release improves the mirroring functionality in dhictl by allowing command arguments.
+
+### Improvements
+
+- Mirror start command now accepts arguments for more flexible mirroring operations
+
+<!-- END GENERATED RELEASES -->
+
+## Earlier releases
+
+For older versions, see the
+[dhictl releases on GitHub](https://github.com/docker-hardened-images/dhictl/releases).
diff --git a/content/manuals/dhi/release-notes/platform.md b/content/manuals/dhi/release-notes/platform.md
new file mode 100644
index 000000000000..fe0702e86621
--- /dev/null
+++ b/content/manuals/dhi/release-notes/platform.md
@@ -0,0 +1,108 @@
+---
+title: Docker Hardened Images release notes
+linkTitle: Platform release notes
+description: Learn about the latest features and changes in Docker Hardened Images
+keywords: docker hardened images, dhi, release notes, changelog, features, changes, new, releases
+tags: [Release notes]
+---
+
+
+This page contains information about the new features, improvements, and changes
+in the Docker Hardened Images (DHI) platform. Release notes are aggregated by
+quarter and include only notable product changes.
+
+## Q3 2026
+
+New features and enhancements released in the third quarter of 2026.
+
+- DHI MCP server: The DHI catalog is now accessible via a remote MCP server at
+  `https://dhi.io/mcp`. Connect any MCP-capable AI assistant to search
+  repositories, inspect image metadata, retrieve SBOMs, check CVEs, and manage
+  mirrors using plain language. For more information, see [Use the DHI MCP
+  server](/dhi/tools/mcp/).
+- DHI API: VEX statements and suppressed CVEs for a Docker Hardened Image are
+  now available to query by digest through the DHI GraphQL API. For more
+  information, see [Use the DHI API](../tools/api.md).
+
+## Q2 2026
+
+New features and enhancements released in the second quarter of 2026.
+
+- Debian Hardened System Packages: Added support for Debian-based Docker
+  Hardened System Packages (HSP), including new CLI workflows for authenticating
+  to the Debian HSP repository.
+- Mend.io scanner integration: Mend.io is now a supported scanner for consuming
+  DHI VEX data.
+- Black Duck scanner integration: Black Duck is now a supported scanner for
+  consuming DHI VEX data.
+- DHI Select self-serve purchase: DHI Select is now available for self-serve
+  purchase directly through the Docker website.
+- Bulk customization: Apply customizations to multiple images in a single
+  operation through the Docker Hub UI and the CLI.
+- Terraform provider: Manage DHI resources, including customizations and
+  mirrors, using the official Terraform provider.
+
+## Q1 2026
+
+New features and enhancements released in the first quarter of 2026.
+
+- Docker Hardened System Packages (HSP): Announced Docker Hardened System
+  Packages, a new offering that provides individually hardened packages for use
+  in your own base images. For more information, see the [announcement blog
+  post](https://www.docker.com/blog/announcing-docker-hardened-system-packages/).
+- Wiz scanner integration: Wiz is now a supported scanner for consuming DHI VEX
+  data.
+
+## Q4 2025
+
+New features and enhancements released in the fourth quarter of 2025.
+
+- Docker Hardened Images Community (Free): Docker Hardened Images are now
+  available for every developer through a Community subscription tier. The
+  subscription tiers are now Community, Select, and Enterprise. For more
+  information, see the [announcement blog
+  post](https://www.docker.com/blog/docker-hardened-images-for-every-developer/).
+- Independent security validation by SRLabs: SRLabs published an independent
+  security validation of Docker Hardened Images. See the
+  [validation announcement](https://www.docker.com/blog/docker-hardened-images-security-independently-validated-by-srlabs/).
+- Docker Scout scoring for DHI: Docker Scout image scoring now accounts for the
+  security improvements provided by DHI.
+- Trivy VEX repository: VEX data for DHI is published in a Trivy-compatible OCI
+  VEX repository, making it easier for Trivy and other scanners to consume.
+- Docker Scout DHI policy: New Docker Scout policy that evaluates whether images
+  use Docker Hardened Images.
+- Hardened Helm charts (Beta): Beta release of Docker Hardened Helm Charts. For
+  more information, see the [announcement blog
+  post](https://www.docker.com/blog/docker-hardened-images-helm-charts-beta/).
+- Mirroring UX: Updated the mirroring experience in Docker Hub with a refreshed
+  UI and clearer flows.
+
+## Q3 2025
+
+New features and enhancements released in the third quarter of 2025.
+
+- Next evolution release: A major release that introduced customizations,
+  FedRAMP-ready images, the AI Migration Agent, and deeper scanner integrations.
+  See the [announcement blog
+  post](https://www.docker.com/blog/the-next-evolution-of-docker-hardened-images/)
+  and the [FedRAMP compliance blog
+  post](https://www.docker.com/blog/fedramp-compliance-with-hardened-images/).
+- DHI customizations: Customize DHI images directly from the Docker Hub UI,
+  with options for adding packages, files, and configuration on top of a base
+  hardened image.
+- AI Migration Agent: AI-assisted Dockerfile migration to help convert existing
+  Dockerfiles to use Docker Hardened Images.
+- CIS compliance attestations: CIS benchmark compliance attestations are now
+  included with DHI images.
+- STIG variants: STIG-hardened image variants for U.S. Department of Defense
+  compliance use cases.
+
+## Q2 2025
+
+New features and enhancements released in the second quarter of 2025.
+
+- Docker Hardened Images launch: Docker announced Docker Hardened Images, a new
+  family of secure, minimal, and production-ready container images maintained by
+  Docker. For more information, see the [launch blog
+  post](https://www.docker.com/blog/introducing-docker-hardened-images/).
+- FIPS variants: FIPS-validated image variants for Docker Hardened Images.
diff --git a/content/manuals/dhi/resources.md b/content/manuals/dhi/resources.md
new file mode 100644
index 000000000000..78619da5414d
--- /dev/null
+++ b/content/manuals/dhi/resources.md
@@ -0,0 +1,93 @@
+---
+title: Resources and feedback
+linktitle: Resources and feedback
+description: Additional resources, community links, GitHub repositories, and how to give feedback for Docker Hardened Images.
+keywords: docker hardened images resources, dhi feedback, dhi github, dhi community, report issue, dhi support
+weight: 999
+aliases:
+  - /dhi/about/feedback/
+  - /dhi/explore/feedback/
+---
+
+This page provides links to additional resources, community channels, and ways
+to give feedback on Docker Hardened Images (DHI).
+
+For product information and feature comparison, visit the [Docker Hardened
+Images product page](https://www.docker.com/products/hardened-images/).
+
+## Guides
+
+For guides that demonstrate how to use Docker Hardened Images in various
+scenarios, see the [guides section filtered by DHI](/guides/?tags=dhi).
+
+## Docker Hub
+
+Docker Hardened Images are available on Docker Hub:
+
+- [Docker Hardened Images Catalog](https://dhi.io): Browse and pull Docker
+  Hardened Images from the official catalog
+- [Docker Hub MCP Server](https://hub.docker.com/mcp/server/dockerhub/overview):
+  MCP server to list Docker Hardened Images (DHIs) available in your
+  organizations
+
+## GitHub repositories and resources
+
+Docker Hardened Images repositories are available in the
+[docker-hardened-images](https://github.com/docker-hardened-images) GitHub
+organization:
+
+- [Catalog](https://github.com/docker-hardened-images/catalog): DHI definition
+  files and catalog metadata
+- [Advisories](https://github.com/docker-hardened-images/advisories): CVE
+  advisories for OSS packages distributed with DHIs
+  - [Scanner vendor integration guide](https://github.com/docker-hardened-images/advisories/tree/main/integration):
+    Reference for scanner vendors integrating DHI VEX support
+- [Keyring](https://github.com/docker-hardened-images/keyring): Public signing
+  keys and verification tools
+- [Log](https://github.com/docker-hardened-images/log): Log of references (tag >
+  digest) for Docker Hardened Images
+- [Policies](https://github.com/docker-hardened-images/policies): Rego source
+  for the Docker Scout policies used to enforce DHI security and compliance
+  standards
+- [dhictl](https://github.com/docker-hardened-images/dhictl): Command-line
+  interface for managing and interacting with Docker Hardened Images
+- [Terraform Provider](https://github.com/docker-hardened-images/terraform-provider-dhi):
+  Terraform provider for managing DHI resources
+  ([Terraform Registry](https://registry.terraform.io/providers/docker-hardened-images/dhi/latest/docs))
+
+## Additional resources
+
+- [Start a free trial](https://hub.docker.com/hardened-images/start-free-trial):
+  Explore DHI Select and Enterprise features including FIPS/STIG variants, customization,
+  and SLA-backed support
+- [Support Service Level Agreement](https://docs.docker.com/go/dhi-sla/):
+  Review the SLA commitments for DHI Select and Enterprise subscriptions
+- [Request a demo](https://www.docker.com/products/hardened-images/#getstarted): Get a
+  personalized demo and information about DHI Select and Enterprise subscriptions
+- [Request an image](https://github.com/docker-hardened-images/catalog/issues):
+  Submit a request for a specific Docker Hardened Image
+- [Debian package index](https://dhi.io/deb/debian/main/index.html):
+  Browse hardened Debian packages in Docker's public repository
+- [Alpine package index](https://dhi.io/apk/alpine/v3.24/main/index.html):
+  Browse hardened Alpine packages in Docker's public repository
+- <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_dhi_resources" class="link" rel="noopener">Contact Sales</a>: Connect with
+  Docker sales team for enterprise inquiries
+- [Docker Support](https://www.docker.com/support/): Access support resources
+  for DHI Select and Enterprise customers
+
+## Feedback and community
+
+Use the [GitHub Discussions board](https://github.com/orgs/docker-hardened-images/discussions)
+to engage with the DHI team for general questions, best practices, security
+tips, and community announcements.
+
+To report a bug, request a feature, or suggest a documentation improvement,
+[open an issue](https://github.com/docker-hardened-images/catalog/issues) in
+the catalog repository.
+
+## Security disclosure
+
+Do not post details of vulnerabilities before coordinated disclosure and
+resolution. If you discover a security vulnerability, report it responsibly
+by following Docker's [security disclosure
+policy](https://www.docker.com/trust/vulnerability-disclosure-policy/).
diff --git a/content/manuals/dhi/tools/_index.md b/content/manuals/dhi/tools/_index.md
new file mode 100644
index 000000000000..32e39ce4aa32
--- /dev/null
+++ b/content/manuals/dhi/tools/_index.md
@@ -0,0 +1,32 @@
+---
+title: Tools
+description: Interfaces and tools for browsing, managing, and automating Docker Hardened Images.
+weight: 25
+params:
+  grid_tools:
+    - title: Use Docker Hub
+      description: Browse the DHI catalog on Docker Hub to search repositories, inspect image metadata, and view SBOMs, CVEs, and attestations.
+      icon: squares-2x2
+      link: /dhi/tools/hub/
+    - title: CLI
+      description: Install and use the `docker dhi` command-line interface to browse the catalog, inspect images, and manage mirrors from your terminal.
+      icon: command-line
+      link: /dhi/tools/cli/
+    - title: MCP server
+      description: Connect an AI assistant to the DHI catalog to search repositories, inspect images, retrieve SBOMs, and check CVEs using plain language.
+      icon: cpu-chip
+      link: /dhi/tools/mcp/
+    - title: Use the DHI Terraform provider
+      description: Use the DHI Terraform provider to manage mirrors and automate DHI configuration as infrastructure as code.
+      icon: wrench-screwdriver
+      link: /dhi/tools/terraform/
+    - title: Use the DHI API
+      description: Query Docker Hardened Images data programmatically using the DHI GraphQL API.
+      icon: code-bracket
+      link: /dhi/tools/api/
+---
+
+Docker Hardened Images can be accessed and managed through several interfaces.
+Choose the tool that fits your workflow.
+
+{{< grid items="grid_tools" >}}
diff --git a/content/manuals/dhi/tools/api.md b/content/manuals/dhi/tools/api.md
new file mode 100644
index 000000000000..be29c3ce9d6b
--- /dev/null
+++ b/content/manuals/dhi/tools/api.md
@@ -0,0 +1,142 @@
+---
+title: Use the DHI API
+linktitle: API
+description: Query Docker Hardened Images data programmatically using the DHI GraphQL API.
+weight: 50
+keywords: dhi api, docker hardened images api, graphql api, dhi endpoint, dhi authentication
+---
+
+The DHI API is a GraphQL API for querying Docker Hardened Images data
+programmatically, for use cases like building automation or dashboards on
+top of DHI data.
+
+## Endpoint
+
+Send requests as `POST` requests to:
+
+```text
+https://api.dso.docker.com/v1/graphql
+```
+
+## Request format
+
+The API accepts standard GraphQL requests: a JSON body with a `query` and,
+optionally, `variables`.
+
+```console
+$ curl https://api.dso.docker.com/v1/graphql \
+  -H "Authorization: Bearer <token>" \
+  -H "Content-Type: application/json" \
+  -d '{"query": "...", "variables": { ... }}'
+```
+
+Every query takes a `Context` argument (conventionally named `ctx` in the
+`variables` object) alongside its query-specific arguments:
+
+| Argument | Type | Required | Description |
+|---|---|---|---|
+| `ctx` | `Context` | Yes | Scopes the request to an organization. |
+| `ctx.organization` | `String` | Yes | The Docker organization the token belongs to. |
+
+## Authentication
+
+An [organization access token](/manuals/enterprise/security/access-tokens.md)
+(OAT) or personal access token (PAT) isn't used directly as the bearer
+token. Exchange it first for an access token:
+
+```console
+$ curl -X POST https://hub.docker.com/v2/auth/token \
+  -H "Content-Type: application/json" \
+  -d '{"identifier": "<identifier>", "secret": "<token>"}'
+```
+
+For `identifier`, use your Docker Hub username with a PAT, or the
+organization name with an OAT. The response contains the access token:
+
+```json
+{ "access_token": "..." }
+```
+
+Pass that `access_token` as `Authorization: Bearer <access_token>`. Also set
+`ctx.organization` in `variables` to the organization the token belongs to
+(see [Request format](#request-format)).
+
+## Response format
+
+Responses follow the standard GraphQL envelope:
+
+| Key | Description |
+|---|---|
+| `data` | The requested fields. A field is `null` if it couldn't be resolved, for example due to an authorization failure. |
+| `errors` | Present when a field failed to resolve. Includes a `message` and a `path` identifying which field failed. |
+| `extensions` | Metadata such as a `correlation_id`, useful when reporting an issue. |
+
+For example, an unauthenticated request, or a request for data your token
+can't access, returns a `null` result under `data` alongside an authorization
+error in `errors`, rather than an HTTP-level failure:
+
+```json
+{
+  "errors": [
+    {
+      "message": "You are not allowed to read data for this team",
+      "path": ["someQuery"],
+      "extensions": { "code": "DOWNSTREAM_SERVICE_ERROR", "status": 403 }
+    }
+  ],
+  "data": { "someQuery": null },
+  "extensions": { "correlation_id": "..." }
+}
+```
+
+## Queries
+
+### `imagePackagesForImageCoords`
+
+Fetches every package in an image, every CVE reported against it, and
+whether Docker suppresses that CVE, by digest. See [Query VEX for a Docker
+Hardened Image](/manuals/dhi/how-to/vex-api.md) for a guided example.
+
+| Argument | Type | Required | Description |
+|---|---|---|---|
+| `digest` | `String` | Yes | The image's platform manifest digest, not the multi-arch index digest. |
+| `hostName` | `String` | Yes | `hub.docker.com` or `docker.io`. |
+| `repoName` | `String` | Yes | Repository name, with or without the namespace prefix. |
+| `includeExcepted` | `Boolean` | No | Include suppressed CVEs in the response alongside the reason for suppression. Without it, the response only shows the netted list, with no visibility into what was suppressed. |
+| `includeNodsa` | `Boolean` | No | Include Debian NODSA exclusions, which make up most suppressions on a Debian-based image. |
+| `includePublic` | `Boolean` | No | Also include public images when `ctx.organization` scopes the request to an organization. Not needed for a typical lookup. |
+
+Keep the requested response fields limited to what you plan to render.
+Fields such as `locations`, `description`, `vulnerableRange`, and `epss`
+increase response size substantially and aren't needed for a CVE-count or
+suppressed-CVE view.
+
+#### Response fields
+
+`vulnerabilityExceptions` only contains records that actually suppress a
+CVE, so it always lines up with `isExcepted`: an empty array means the CVE
+is live. Use `isExcepted` as your filter for "is this CVE suppressed."
+
+| Field | Meaning |
+|---|---|
+| `isExcepted` | Docker suppresses this CVE for this image. Use this to filter. |
+| `sourceType` | `EXTERNAL` (Debian NODSA), `MANUAL_EXCEPTION` (Docker analyst exception), or `VEX_STATEMENT` (an ingested VEX document). |
+| `type` | `FALSE_POSITIVE` and `ACCEPTED_RISK` suppress the CVE. `UNDER_INVESTIGATION` and `AFFECTED` don't. |
+| `justification` | The OpenVEX justification value. Always `null` for NODSA exclusions. |
+| `additionalDetails` | Free-text rationale for the suppression. |
+| `isDhiStatement` | Whether the statement is inherited from the DHI base image. |
+| `id` | Stable identifier for the statement. |
+
+#### Mapping to OpenVEX
+
+If your pipeline consumes OpenVEX documents (for example, Trivy's `--vex`
+flag), each suppressed record maps as follows:
+
+| OpenVEX field | Source |
+|---|---|
+| `vulnerability.name` | `sourceId` |
+| `products[].@id` | The parent package's `purl` |
+| `status` | `not_affected` (from `type: FALSE_POSITIVE`) |
+| `justification` | `justification`, defaulting to `vulnerable_code_cannot_be_controlled_by_adversary` for NODSA exclusions |
+| `status_notes` | `additionalDetails` |
+| `@id` | `id` |
diff --git a/content/manuals/dhi/tools/cli.md b/content/manuals/dhi/tools/cli.md
new file mode 100644
index 000000000000..3350ee587355
--- /dev/null
+++ b/content/manuals/dhi/tools/cli.md
@@ -0,0 +1,277 @@
+---
+title: Use the DHI CLI
+linkTitle: CLI
+weight: 20
+keywords: docker dhi, CLI, command line, docker hardened images
+description: Learn how to install and use docker dhi, the command-line interface for managing Docker Hardened Images.
+aliases:
+  - /dhi/how-to/cli/
+---
+
+The `docker dhi` command-line interface (CLI) is a tool for managing Docker Hardened Images:
+- Browse the catalog of available DHI images and their metadata
+- View attestations for DHI images, including SBOMs and provenance
+- Mirror DHI images to your Docker Hub organization
+- Create and manage customizations of DHI images
+- Generate authentication for enterprise package repositories
+- Monitor customization builds
+
+## Installation
+
+The `docker dhi` CLI is available in [Docker Desktop](https://docs.docker.com/desktop/) version 4.65 and later.
+You can also install the standalone `dhictl` binary.
+
+### Docker Desktop
+
+The `docker dhi` command is included in Docker Desktop 4.65 and later. No additional installation is required.
+
+### Standalone binary
+
+1. Download the `dhictl` binary for your platform from the
+   [releases](https://github.com/docker-hardened-images/dhictl/releases) page.
+2. Move it to a directory in your `PATH`:
+    - `mv dhictl /usr/local/bin/` on _Linux_ and _macOS_
+    - Move `dhictl.exe` to a directory in your `PATH` on _Windows_
+
+## Usage
+
+Every command has built-in help accessible with the `--help` flag:
+
+```console
+$ docker dhi --help
+$ docker dhi catalog list --help
+```
+
+### Browse the DHI catalog
+
+List all available DHI images:
+
+```console
+$ docker dhi catalog list
+```
+
+Filter by type, name, or compliance:
+
+```console
+$ docker dhi catalog list --type image
+$ docker dhi catalog list --filter golang
+$ docker dhi catalog list --fips
+$ docker dhi catalog list --stig
+```
+
+Get details of a specific image, including available tags and CVE counts:
+
+```console
+$ docker dhi catalog get <image-name>
+```
+
+### View attestations
+
+List all attestations attached to a DHI image:
+
+```console
+$ docker dhi attestation list dhi/nginx:1.27
+$ docker dhi attestation list dhi/nginx:1.27 --platform linux/amd64
+$ docker dhi attestation list dhi/nginx:1.27 --predicate-type https://slsa.dev/provenance/v1
+$ docker dhi attestation list dhi/nginx:1.27 --json
+```
+
+Get a specific attestation by its referrer digest:
+
+```console
+$ docker dhi attestation get dhi/nginx:1.27 sha256:<digest>
+$ docker dhi attestation get dhi/nginx:1.27 sha256:<digest> -o provenance.json
+```
+
+Display the SPDX SBOM for an image:
+
+```console
+$ docker dhi attestation sbom dhi/nginx:1.27
+$ docker dhi attestation sbom dhi/nginx:1.27 --platform linux/amd64
+```
+
+### Mirror DHI images
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+Start mirroring one or more DHI images to your Docker Hub organization:
+
+```console
+$ docker dhi mirror start --org my-org \
+  dhi/golang,my-org/dhi-golang \
+  dhi/nginx,my-org/dhi-nginx \
+  dhi/prometheus-chart,my-org/dhi-prometheus-chart
+```
+
+Mirror with dependencies:
+
+```console
+$ docker dhi mirror start --org my-org dhi/golang,my-org/dhi-golang --dependencies
+```
+
+List mirrored images in your organization:
+
+```console
+$ docker dhi mirror list --org my-org
+```
+
+Filter mirrored images by name or type:
+
+```console
+$ docker dhi mirror list --org my-org --filter python
+$ docker dhi mirror list --org my-org --type image
+$ docker dhi mirror list --org my-org --type helm-chart
+```
+
+Stop mirroring one or more images:
+
+```console
+$ docker dhi mirror stop dhi-golang --org my-org
+$ docker dhi mirror stop dhi-python dhi-golang --org my-org
+```
+
+Stop mirroring and delete the repositories:
+
+```console
+$ docker dhi mirror stop dhi-golang --org my-org --delete
+$ docker dhi mirror stop dhi-golang --org my-org --delete --force
+```
+
+### Customize DHI images
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+The CLI can be used to create and manage DHI image customizations. For detailed
+instructions on creating customizations using the GUI, see [Customize a Docker
+Hardened Image](../how-to/customize.md).
+
+The following is a quick reference for CLI commands. For complete details on all
+options and flags, see the
+[CLI reference](/reference/cli/docker/dhi/).
+
+```console
+# Prepare a single customization scaffold
+$ docker dhi customization prepare golang 1.25 \
+  --org my-org \
+  --destination my-org/dhi-golang \
+  --name "golang with git" \
+  > my-customization.yaml
+
+# Prepare a bulk customization scaffold (pipe JSON array via stdin)
+$ echo '[{"destination":"my-org/dhi-golang","tag-definition-id":"golang/alpine-3.23/1.24-dev"}]' \
+  | docker dhi customization prepare --name "golang with git" --org my-org \
+  > my-customization.yaml
+
+# Create a customization
+$ docker dhi customization create my-customization.yaml --org my-org
+
+# Create with flag overrides (flags take precedence over the YAML file)
+$ docker dhi customization create my-customization.yaml --org my-org \
+  --destination my-org/dhi-golang \
+  --name "golang with git"
+
+# List customizations
+$ docker dhi customization list --org my-org
+
+# Filter customizations by name, repository, or source
+$ docker dhi customization list --org my-org --filter git
+$ docker dhi customization list --org my-org --repo dhi-golang
+$ docker dhi customization list --org my-org --source golang
+
+# Get a customization by ID
+$ docker dhi customization get <id> --org my-org
+
+# Update a customization
+# The YAML file must include the 'id' field to identify the customization to update
+$ docker dhi customization edit my-customization.yaml --org my-org
+
+# Delete a customization by ID
+$ docker dhi customization delete <id> --org my-org
+
+# Delete multiple customizations
+$ docker dhi customization delete <id1> <id2> --org my-org
+
+# Delete without confirmation prompt
+$ docker dhi customization delete <id> --org my-org --force
+```
+
+For a complete reference of all YAML fields, see
+[Image customization YAML file](/dhi/how-to/customize/#image-customization-yaml-file).
+
+### Enterprise package authentication
+
+{{< summary-bar feature_name="Docker Hardened Images Enterprise" >}}
+
+Generate authentication credentials for accessing the enterprise hardened
+package repository. These credentials are used when configuring your package
+manager to install compliance and security-patched packages in your own images. For detailed
+instructions, see [Enterprise
+repository](../how-to/hardened-packages.md#enterprise-repository).
+
+For Alpine-based images:
+
+```console
+$ docker dhi auth apk
+```
+
+For Debian-based images:
+
+```console
+$ docker dhi auth deb
+```
+
+### Monitor customization builds
+
+{{< summary-bar feature_name="Docker Hardened Images" >}}
+
+List builds for a customization:
+
+```console
+$ docker dhi customization build list <customization-id> --org my-org
+$ docker dhi customization build list <customization-id> --org my-org --json
+```
+
+Get details of a specific build:
+
+```console
+$ docker dhi customization build get <customization-id> <build-id> --org my-org
+$ docker dhi customization build get <customization-id> <build-id> --org my-org --json
+```
+
+View build logs:
+
+```console
+$ docker dhi customization build logs <customization-id> <build-id> --org my-org
+$ docker dhi customization build logs <customization-id> <build-id> --org my-org --json
+```
+
+### JSON output
+
+Most list and get commands support a `--json` flag for machine-readable output:
+
+```console
+$ docker dhi catalog list --json
+$ docker dhi catalog get golang --json
+$ docker dhi attestation list dhi/nginx:1.27 --json
+$ docker dhi mirror list --org my-org --json
+$ docker dhi mirror start --org my-org dhi/golang,my-org/dhi-golang --json
+$ docker dhi customization list --org my-org --json
+$ docker dhi customization build list <customization-id> --org my-org --json
+```
+
+## Configuration
+
+The `docker dhi` CLI can be configured with a YAML file located at:
+- `$HOME/.config/dhictl/config.yaml` on _Linux_ and _macOS_
+- `%USERPROFILE%\.config\dhictl\config.yaml` on _Windows_
+
+If `$XDG_CONFIG_HOME` is set, the configuration file is located at `$XDG_CONFIG_HOME/dhictl/config.yaml`.
+
+Available configuration options:
+
+| Option      | Environment Variable | Description                                                                                                               |
+|-------------|----------------------|---------------------------------------------------------------------------------------------------------------------------|
+| `org`       | `DHI_ORG`            | Default Docker Hub organization for mirror and customization commands.                                                    |
+| `api_token` | `DHI_API_TOKEN`      | Docker token for authentication. You can generate a token in your [Docker Hub account settings](https://hub.docker.com/). |
+
+Environment variables take precedence over configuration file values.
diff --git a/content/manuals/dhi/tools/hub.md b/content/manuals/dhi/tools/hub.md
new file mode 100644
index 000000000000..cab81039bfb5
--- /dev/null
+++ b/content/manuals/dhi/tools/hub.md
@@ -0,0 +1,103 @@
+---
+title: Use Docker Hub
+linktitle: Docker Hub
+description: Browse the DHI catalog on Docker Hub to search repositories, inspect image metadata, and view SBOMs, CVEs, and attestations.
+weight: 10
+keywords: docker hub dhi catalog, hardened images hub, dhi repository details, image variants hub
+---
+
+The [Docker Hardened Images catalog](https://hub.docker.com/hardened-images/catalog)
+on Docker Hub is the primary web interface for browsing, searching, and inspecting
+DHI repositories and their metadata.
+
+## Catalog page
+
+The catalog lists all available DHI repositories. You can filter by name,
+image type, or compliance requirements (FIPS, STIG) to find the image you need.
+
+## Repository details page
+
+When you select a repository from the catalog, the repository details page
+provides the following:
+
+- Overview: A brief explanation of the image.
+- Guides: Several guides on how to use the image and migrate your existing application.
+- Images: Select this option to [view image variants](#images-page).
+- Security summary: Select a tag name to view a quick security summary,
+  including package count and total known vulnerabilities.
+- Recently pushed tags: A list of recently updated image variants and when they
+  were last updated.
+- Use this image: After selecting an image variant, you can select this option to
+  view instructions on how to pull and use the image variant, or select **Mirror
+  repository** to mirror it to your organization.
+
+## Images page
+
+From the repository details page, select **Images** to see all available image
+variants for that repository. The table includes:
+
+- Image version: The image name with its base distribution (for example, `debian
+  13`) and associated tags.
+- Type: The support lifecycle status of the variant.
+- Compliance: Relevant compliance designations, for example `CIS`, `FIPS`, or
+  `STIG (100%)`.
+- Package manager: Whether a package manager is available. A checkmark indicates
+  a package manager is present (for example, `apt` or `apk`), a dash indicates
+  none.
+- Shell: Whether a shell is available. A checkmark indicates a shell is present
+  (for example, `bash` or `busybox`), a dash indicates none.
+- User: The user that the container runs as, for example `root` or `nonroot
+  (65532)`.
+- Last pushed: When the image variant was last updated.
+- Vulnerabilities: Vulnerability counts by severity level.
+
+## Image variant details page
+
+Select an image version from the Images table to view detailed information about
+that specific variant:
+
+- Packages: A list of all packages included in the image variant, with each
+  package's name, version, distribution, and licensing information.
+- Specifications:
+  - Source and build information: The Dockerfile and Git commit used to build the image.
+  - Build parameters, entrypoint, CMD, user, working directory, environment
+    variables, labels, and platform.
+- Vulnerabilities: A list of known CVEs for the image variant, including CVE ID,
+  severity, affected package, fix version, last detected date, status, and
+  suppressed CVEs.
+- Attestations: Signed security attestations covering the image's build process,
+  contents, and security posture. For the full list, see
+  [Attestations](/dhi/explore/security-concepts/attestations/).
+
+## Manage page
+
+The Manage page (**My Hub** > **Hardened Images** > **Manage**) is the central
+place for administering your organization's mirrored DHI repositories. It has
+two tabs:
+
+- Mirrored Images: Lists all image repositories currently mirrored to your
+  organization, with their source DHI repository, destination repository name,
+  and mirroring status. From here you can stop mirroring or open a repository's
+  settings.
+- Mirrored Helm charts: The same view for Helm chart repositories.
+
+Selecting a mirrored repository opens its settings, where you can enable or
+disable Extended Lifecycle Support (ELS) and access customizations.
+
+For step-by-step instructions, see [Mirror a Docker Hardened Image
+repository](/dhi/how-to/mirror/).
+
+## Customizations
+
+Customizations are accessible from **My Hub** > **Hardened Images** > **Manage** > **Mirrored Images**.
+Select the menu icon next to a mirrored repository and
+then **Customize**. Each customization defines
+additional packages, OCI artifacts, environment variables, or labels to layer
+onto the base DHI during a rebuild.
+
+The customizations view shows each customization's name, status, and last build
+time. Selecting a customization opens its configuration, where you can edit the
+definition, trigger a rebuild, or delete it.
+
+For step-by-step instructions, see [Customize a Docker Hardened
+Image](/dhi/how-to/customize/).
diff --git a/content/manuals/dhi/tools/mcp.md b/content/manuals/dhi/tools/mcp.md
new file mode 100644
index 000000000000..bc71dae76de6
--- /dev/null
+++ b/content/manuals/dhi/tools/mcp.md
@@ -0,0 +1,211 @@
+---
+title: Use the DHI MCP server
+linktitle: MCP server
+description: Connect an AI assistant to the Docker Hardened Images catalog using the DHI MCP server to search repositories, inspect images, view SBOMs, and check CVEs.
+weight: 30
+keywords: docker hardened images mcp, ai assistant dhi, mcp server docker, dhi catalog ai, claude cursor docker images, sbom mcp, cve mcp
+aliases:
+  - /dhi/how-to/mcp/
+---
+
+The Docker Hardened Images (DHI) MCP server exposes the DHI catalog through the
+Model Context Protocol (MCP), letting you query repositories, inspect image
+metadata, retrieve SBOMs, and check CVEs directly from your AI assistant in
+plain language.
+
+The MCP server is:
+
+- Remote. No local binary to install. Your AI assistant connects directly to
+  `https://dhi.io/mcp`.
+- Compatible with any MCP-capable AI assistant, including Claude,
+  Cursor, and others.
+
+Most tools are public and require no credentials. The mirror management tools
+(`dhi_list_mirrors`, `dhi_create_mirror`, `dhi_remove_mirror`) require a Docker
+Hub username and personal access token (PAT) with owner access to the target
+organization. Credentials are passed as an HTTP Basic auth header in the MCP
+client configuration — they are never passed as tool arguments.
+
+## Connect your AI assistant
+
+Configuration varies by client. Select the tab for your AI assistant.
+
+{{< tabs >}}
+{{< tab name="Claude Desktop" >}}
+
+Add the following to your Claude Desktop configuration file:
+
+```json
+{
+  "mcpServers": {
+    "dhi": {
+      "url": "https://dhi.io/mcp"
+    }
+  }
+}
+```
+
+The configuration file is located at:
+- macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`
+- Windows: `%APPDATA%\Claude\claude_desktop_config.json`
+
+{{< /tab >}}
+{{< tab name="Cursor" >}}
+
+Add the following to `.cursor/mcp.json` in your project, or
+`~/.cursor/mcp.json` globally:
+
+```json
+{
+  "mcpServers": {
+    "dhi": {
+      "url": "https://dhi.io/mcp"
+    }
+  }
+}
+```
+
+{{< /tab >}}
+{{< tab name="Claude Code" >}}
+
+Run the following command to add the DHI MCP server:
+
+```console
+$ claude mcp add dhi --url https://dhi.io/mcp
+```
+
+Or add it manually to `.claude/mcp.json` in your project:
+
+```json
+{
+  "mcpServers": {
+    "dhi": {
+      "url": "https://dhi.io/mcp"
+    }
+  }
+}
+```
+
+{{< /tab >}}
+{{< tab name="Docker Agent" >}}
+
+In your [Docker Agent](/manuals/ai/docker-agent/_index.md) YAML configuration, add the
+DHI MCP server as a remote toolset:
+
+```yaml
+toolsets:
+  - type: mcp
+    remote:
+      url: "https://dhi.io/mcp"
+      transport_type: streamable
+```
+
+For example, to create an agent that can answer questions about the DHI catalog:
+
+```yaml
+agents:
+  root:
+    model: anthropic/claude-sonnet-4-5
+    description: DHI catalog assistant
+    instruction: |
+      Help me find and evaluate Docker Hardened Images.
+      Search the DHI catalog, inspect image details, check CVEs,
+      and retrieve SBOMs and attestations as needed.
+    toolsets:
+      - type: mcp
+        remote:
+          url: "https://dhi.io/mcp"
+          transport_type: streamable
+```
+
+Run the agent with:
+
+```console
+$ docker agent run dhi-agent.yaml
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Available tools
+
+The DHI MCP server provides ten tools that your AI assistant calls automatically
+based on what you ask:
+
+| Tool | What it does |
+|------|-------------|
+| `dhi_list_repositories` | Search and filter the DHI catalog by name, type, category, FIPS, or STIG compliance |
+| `dhi_get_repository` | Get full details for a repository: tag definitions, build config, platforms, and per-manifest vulnerability counts |
+| `dhi_get_tag_definition` | Get the deep view of a single tag definition |
+| `dhi_get_image_details` | Get per-digest details: tags, platform, size, layer and package counts, vulnerability severity counts, and attestation types |
+| `dhi_get_image_packages` | Retrieve the full software bill of materials (SBOM): package name, version, type, purl, licenses, and file locations |
+| `dhi_get_image_cves` | List CVEs with severity, CVSS score, fix version, EPSS score, and CISA-exploited flag; filter by minimum severity or fixable-only |
+| `dhi_get_image_attestations` | List SBOM, provenance, signature, and other attestations for a specific image digest |
+| `dhi_list_mirrors` | List mirrored DHI repositories for a Docker Hub organization — requires authentication |
+| `dhi_create_mirror` | Start mirroring a DHI repository into a Docker Hub organization — requires authentication |
+| `dhi_remove_mirror` | Stop mirroring a repository by its mirror ID — requires authentication |
+
+## Authenticate for mirror tools
+
+The mirror tools require a Docker Hub username and [personal access token
+(PAT)](/security/access-tokens/) with owner access to the target organization,
+passed as an HTTP Basic auth header. Generate the value with:
+
+```console
+$ printf 'USERNAME:dckr_pat_...' | base64 | tr -d '\n'
+```
+
+Then add it to your MCP client configuration:
+
+> [!WARNING]
+> Base64 encoding is not encryption. The value in your configuration file
+> is effectively a plaintext password. Do not commit this file to version
+> control or share it.
+
+```json
+{
+  "mcpServers": {
+    "dhi": {
+      "url": "https://dhi.io/mcp",
+      "headers": {
+        "Authorization": "Basic <base64-value>"
+      }
+    }
+  }
+}
+```
+
+Without credentials, the read-only catalog tools work normally and the mirror
+tools return an authentication error.
+
+## What the tools return
+
+Each tool returns structured data that your AI assistant can summarize,
+compare, or act on:
+
+- `dhi_list_repositories` returns a list of repositories with display
+  name, distributions, platforms, FIPS/STIG flags, included tools, and category.
+- `dhi_get_repository` returns the full repository record, including all tag
+  definitions with their tags, build configuration, image indexes, and
+  per-platform manifest digests with vulnerability counts.
+- `dhi_get_tag_definition` returns tags, build parameters, entrypoint,
+  environment variables, run-as user, and per-platform manifests for a single
+  tag definition.
+- `dhi_get_image_details` returns the image platform, compressed size, layer
+  count, package count, vulnerability severity counts by level, labels, and
+  a list of attestation predicate types.
+- `dhi_get_image_packages` returns each package in the image with its name,
+  version, type (`deb`, `rpm`, `apk`, etc.), purl, licenses, and the file paths where
+  it was found.
+- `dhi_get_image_cves` returns each CVE affecting the image with its
+  severity, CVSS score and vector, affected package, fix version (if any), EPSS
+  probability score, and a flag indicating whether CISA lists it as
+  actively exploited.
+- `dhi_get_image_attestations` returns the predicate type and OCI reference
+  for each attestation attached to the image digest.
+- `dhi_list_mirrors` returns each mirror's ID, source DHI repository,
+  destination repository, and mirroring status for the given organization.
+- `dhi_create_mirror` starts mirroring a DHI source repository into the
+  specified organization and destination repository name.
+- `dhi_remove_mirror` stops mirroring for the given mirror ID. It does not
+  delete the destination repository — only stops new images from being synced.
diff --git a/content/manuals/dhi/tools/terraform.md b/content/manuals/dhi/tools/terraform.md
new file mode 100644
index 000000000000..176ad2f0ccd6
--- /dev/null
+++ b/content/manuals/dhi/tools/terraform.md
@@ -0,0 +1,65 @@
+---
+title: Use the DHI Terraform provider
+linktitle: Terraform
+description: Use the DHI Terraform provider to manage mirrors and customizations as infrastructure as code.
+weight: 40
+keywords: dhi terraform, docker hardened images terraform, infrastructure as code, dhi mirror terraform, dhi provider
+---
+
+The [DHI Terraform provider](https://registry.terraform.io/providers/docker-hardened-images/dhi/latest/docs)
+lets you manage Docker Hardened Image mirrors and customizations as
+infrastructure as code.
+
+## Install and configure the provider
+
+Add the provider to your Terraform configuration:
+
+```hcl
+terraform {
+  required_providers {
+    dhi = {
+      source = "docker-hardened-images/dhi"
+    }
+  }
+}
+
+provider "dhi" {
+  docker_hub_username = var.docker_username
+  docker_hub_password = var.docker_password
+  organization        = var.org_name
+}
+```
+
+Instead of specifying credentials in the provider block, you can set environment
+variables:
+
+| Variable | Description |
+|----------|-------------|
+| `DOCKER_USERNAME` | Docker Hub username or organization namespace |
+| `DOCKER_PASSWORD` | Docker Hub password or personal/organization access token |
+| `DHI_ORG` | Target organization namespace |
+
+You can authenticate using a personal access token (PAT) or an organization
+access token (OAT) in place of a password. When using an OAT, permission scopes
+apply:
+
+- Read (pull) access is required to list mirrors.
+- Push access is required to create or delete mirrors.
+
+## Resources
+
+### `dhi_mirror`
+
+Manages a mirrored DHI repository in your organization. See [Mirror a Docker
+Hardened Image repository](/dhi/how-to/mirror/) for task-based examples.
+
+For the full list of resource attributes, see the [Terraform Registry
+documentation](https://registry.terraform.io/providers/docker-hardened-images/dhi/latest/docs/resources/mirror).
+
+### `dhi_customization`
+
+Manages image customizations applied to a mirrored repository. See [Customize a
+Docker Hardened Image](/dhi/how-to/customize/) for task-based examples.
+
+For the full list of resource attributes, see the [Terraform Registry
+documentation](https://registry.terraform.io/providers/docker-hardened-images/dhi/latest/docs/resources/customization).
diff --git a/content/manuals/docker-hub/_index.md b/content/manuals/docker-hub/_index.md
index 71f8c076729d..da692cc9dc8d 100644
--- a/content/manuals/docker-hub/_index.md
+++ b/content/manuals/docker-hub/_index.md
@@ -5,32 +5,40 @@ title: Docker Hub
 weight: 30
 params:
   sidebar:
-    group: Products
+    group: Supply chain security
 grid:
 - title: Quickstart
   description: Step-by-step instructions on getting started on Docker Hub.
-  icon: explore
+  icon: magnifying-glass-plus
   link: /docker-hub/quickstart
 - title: Library
   description: Explore the content library, featuring millions of images for operating systems, frameworks, databases, and more.
-  icon: book
+  icon: book-open
   link: /docker-hub/image-library/
 - title: Repositories
   description: Create a repository to share your images with your team, customers,
     or the Docker community.
   icon: inbox
   link: /docker-hub/repos
+- title: Settings
+  description: Learn about settings in Docker Hub.
+  icon: cog-6-tooth
+  link: /docker-hub/settings
 - title: Organizations
   description: Learn about organization administration.
-  icon: store
+  icon: building-storefront
   link: /admin/
 - title: Usage and limits
   description: Explore usage limits and how to better utilize Docker Hub.
-  icon: leaderboard
+  icon: chart-bar
   link: /docker-hub/usage/
+- title: MCP server
+  description: Use the Docker Hub MCP server to access image metadata and manage repositories with AI agents.
+  icon: server-stack
+  link: /docker-hub/mcp-server/
 - title: Release notes
   description: Find out about new features, improvements, and bug fixes.
-  icon: note_add
+  icon: document-plus
   link: /docker-hub/release-notes
 aliases:
   - /docker-hub/overview/
@@ -52,7 +60,8 @@ Key features of Docker Hub:
 * Trusted content featuring high-quality, secure images
 
 In addition to the graphical interface, you can interact with Docker Hub using
-the [Docker Hub API](../../reference/api/hub/latest.md) or experimental [Docker
-Hub CLI tool](https://github.com/docker/hub-tool#readme).
+the [Docker Hub API](../../reference/api/hub/latest.md), the experimental [Docker
+Hub CLI tool](https://github.com/docker/hub-tool#readme), or the [Docker Hub
+MCP server](/docker-hub/mcp-server/) for AI agent integrations.
 
 {{< grid >}}
diff --git a/content/manuals/docker-hub/image-library/_index.md b/content/manuals/docker-hub/image-library/_index.md
index 3d41410ff1f3..7ba00b085400 100644
--- a/content/manuals/docker-hub/image-library/_index.md
+++ b/content/manuals/docker-hub/image-library/_index.md
@@ -14,9 +14,10 @@ workflows, making it easier to share and collaborate.
 In this section, learn about:
 
 - [Search](./search.md): Discover how to browse and search Docker Hub's extensive resources.
-- [Trusted content](./trusted-content.md): Dive into Docker Official Images,
-  Verified Publisher content, and Sponsored Open Source images, all vetted for
-  security and reliability to streamline your workflows.
-- [Catalogs](./catalogs.md): Explore specialized collections like the generative AI catalog.
+- [Trusted content](./trusted-content.md): Dive into Docker Hardened Images,
+  Docker Official Images, Verified Publisher content, and Docker-Sponsored Open
+  Source Software images, all vetted for security and reliability to streamline
+  your workflows.
+- [Catalogs](./catalogs.md): Explore specialized collections like the generative AI catalogs.
 - [Mirroring](./mirror.md): Learn how to create a mirror of Docker Hub's
-  container image library as a pull-through cache.
\ No newline at end of file
+  container image library as a pull-through cache.
diff --git a/content/manuals/docker-hub/image-library/catalogs.md b/content/manuals/docker-hub/image-library/catalogs.md
index 713df0628b26..104543ffe457 100644
--- a/content/manuals/docker-hub/image-library/catalogs.md
+++ b/content/manuals/docker-hub/image-library/catalogs.md
@@ -1,5 +1,5 @@
 ---
-description: Explore specialized Docker Hub collections like the Generative AI catalog.
+description: Explore specialized Docker Hub collections like the generative AI catalogs.
 keywords: Docker Hub, Hub, catalog
 title: Docker Hub catalogs
 linkTitle: Catalogs
@@ -19,48 +19,42 @@ Docker Hub:
 - Accelerate development: Quickly integrate advanced capabilities into your
   applications without the hassle of extensive research or setup.
 
-The generative AI catalog is the first catalog in Docker Hub, offering
-specialized content for AI development.
+The following sections provide an overview of the key catalogs available in Docker Hub.
 
-## Generative AI catalog
+## MCP Catalog
 
-The [generative AI catalog](https://hub.docker.com/catalogs/gen-ai) makes it
-easy to explore and add AI capabilities to your applications. With trusted,
-ready-to-use content and comprehensive documentation, you can skip the hassle of
-sorting through countless tools and configurations. Instead, focus your time and
-energy on creating innovative AI-powered applications.
+The [MCP Catalog](https://hub.docker.com/mcp/) is a centralized, trusted
+registry for discovering, sharing, and running Model Context Protocol
+(MCP)-compatible tools. Seamlessly integrated into Docker Hub, the catalog
+includes:
 
-The generative AI catalog provides a wide range of trusted content, organized
-into key areas to support diverse AI development needs:
+- Over 100 verified MCP servers packaged as Docker images
+- Tools from partners such as New Relic, Stripe, and Grafana
+- Versioned releases with publisher verification
+- Simplified pull-and-run support through Docker Desktop and Docker CLI
 
-- Demos: Ready-to-deploy examples showcasing generative AI capabilities. These
-  demos provide a hands-on way to explore AI tools and frameworks, making it
-  easier to understand how they can be integrated into real-world applications.
-- Model Context Protocol (MCP) servers: MCP servers provide reusable toolsets
-  that can be used across clients, like Claude Desktop.
-- Models: Pre-trained AI models for tasks like text generation,
-  Natural Language Processing (NLP), and conversational AI. These models
-  provide a foundation for
-  AI applications without requiring developers to train models from scratch.
-- Applications and end-to-end platforms: Comprehensive platforms and tools that
-  simplify AI application development, including low-code solutions and
-  frameworks for building multi-agent and Retrieval-Augmented Generation (RAG)
-  applications.
-- Model deployment and serving: Tools and frameworks that enable developers to
-  efficiently deploy and serve AI models in production environments. These
-  resources include pre-configured stacks for GPUs and other specialized
-  hardware, ensuring performance at scale.
-- Orchestration: Solutions for managing complex AI workflows, such as workflow
-  engines, Large Language Model (LLM) application frameworks, and lifecycle management
-  tools, to help streamline development and operations.
-- Machine learning frameworks: Popular frameworks like TensorFlow and PyTorch
-  that provide the building blocks for creating, training, and fine-tuning
-  machine learning models.
-- Databases: Databases optimized for AI workloads, including vector databases
-  for similarity search, time-series databases for analytics, and NoSQL
-  solutions for handling unstructured data.
+Each server runs in an isolated container to ensure consistent behavior and
+minimize configuration headaches. For developers working with Claude Desktop or
+other MCP clients, the catalog provides an easy way to extend functionality with
+drop-in tools.
 
-> [!NOTE]
->
-> For publishers, [contact us](https://www.docker.com/partners/programs/) to
-> join the generative AI catalog.
\ No newline at end of file
+To learn more about MCP servers, see [MCP Catalog and Toolkit](../../ai/mcp-catalog-and-toolkit/_index.md).
+
+## AI Models Catalog
+
+The [AI Models Catalog](https://hub.docker.com/catalogs/models/) provides
+curated, trusted models that work with [Docker Model
+Runner](../../ai/model-runner/_index.md). This catalog is designed to make AI
+development more accessible by offering pre-packaged, ready-to-use models that
+you can pull, run, and interact with using familiar Docker tools.
+
+With the AI Models Catalog and Docker Model Runner, you can:
+
+- Pull and serve models from Docker Hub or any OCI-compliant registry
+- Interact with models via OpenAI-compatible APIs
+- Run and test models locally using Docker Desktop or CLI
+- Package and publish models using the `docker model` CLI
+
+Whether you're building generative AI applications, integrating LLMs into your
+workflows, or experimenting with machine learning tools, the AI Models Catalog
+simplifies the model management experience.
diff --git a/content/manuals/docker-hub/image-library/search.md b/content/manuals/docker-hub/image-library/search.md
index a78f57a39c68..8a3152918f09 100644
--- a/content/manuals/docker-hub/image-library/search.md
+++ b/content/manuals/docker-hub/image-library/search.md
@@ -14,15 +14,21 @@ types of content.
 ## Filters
 
 The search functionality includes filters to narrow down
-results based on your requirements, such as products, categories, and trusted
-content. This ensures that you can quickly find and access the resources best
+results based on your requirements, such as products, categories, trusted
+content, and publishers. This ensures that you can quickly find and access the resources best
 suited to your project.
 
 ### Products
 
-Docker Hub's content library features three products, each designed to meet
-specific needs of developers and organizations. These products include images,
-plugins, and extensions.
+Docker Hub's content library features various products, each designed to meet
+specific needs of developers and organizations. These products include:
+
+- Images
+- Extensions
+- Helm charts
+- Compose files
+- AI models
+- Docker Engine plugins
 
 #### Images
 
@@ -42,26 +48,6 @@ reusable building blocks, reducing the need to start from scratch. Whether
 you're a beginner building your first container or an enterprise managing
 complex architectures, Docker Hub images provide a reliable foundation.
 
-#### Plugins
-
-Plugins in Docker Hub let you extend and customize Docker Engine to suit
-specialized requirements. Plugins integrate directly with the Docker Engine and
-provide capabilities such as:
-
-- Network plugins: Enhance networking functionality, enabling integration with
-  complex network infrastructures.
-- Volume plugins: Provide advanced storage options, supporting persistent and
-  distributed storage across various backends.
-- Authorization plugins: Offer fine-grained access control to secure Docker
-  environments.
-
-By leveraging Docker plugins, teams can tailor Docker Engine to meet their
-specific operational needs, ensuring compatibility with existing infrastructures
-and workflows.
-
-To learn more about plugins, see [Docker Engine managed plugin
-system](/manuals/engine/extend/_index.md).
-
 #### Extensions
 
 Docker Hub offers extensions for Docker Desktop, which enhance its core
@@ -85,6 +71,88 @@ Desktop's interface.
 To learn more about extensions, see [Docker
 Extensions](/manuals/extensions/_index.md).
 
+#### Helm charts
+
+Helm charts in Docker Hub provide a streamlined way to package, configure, and
+deploy Kubernetes applications. Helm is the package manager for Kubernetes, and
+charts are pre-configured templates that define the resources needed to run an
+application in a Kubernetes cluster. Docker Hub hosts a variety of Helm charts
+that provide:
+
+- Application packaging: Bundle Kubernetes manifests, configurations, and
+  dependencies into a single, reusable chart.
+- Version management: Track and manage different versions of your application
+  deployments.
+- Configuration templating: Customize deployments with values files, making it
+  easy to deploy the same application across different environments.
+- Dependency management: Automatically handle chart dependencies, ensuring all
+  required components are deployed together.
+
+Helm charts reduce the complexity of Kubernetes deployments, making it easier
+for teams to deploy, upgrade, and manage applications in production
+environments.
+
+#### Compose
+
+Docker Compose files in Docker Hub enable multi-container application
+orchestration through simple YAML configuration files. Compose is a tool for
+defining and running multi-container Docker applications, and Docker Hub hosts
+Compose files that help you:
+
+- Multi-container orchestration: Define and run applications consisting of
+  multiple interconnected containers with a single command.
+- Service configuration: Specify container images, environment variables,
+  networks, volumes, and dependencies in a declarative format.
+- Development and testing: Quickly spin up complete application stacks for local
+  development, testing, or demonstration purposes.
+- Environment consistency: Ensure consistent application behavior across
+  development, staging, and production environments.
+
+Compose files simplify the process of managing complex applications by
+providing a clear, version-controlled definition of your entire application
+stack.
+
+#### AI models
+
+Docker Hub hosts AI and machine learning models in containerized formats,
+making it easier to deploy, share, and run AI applications across different
+environments. These containerized AI models provide:
+
+- Pre-trained models: Access ready-to-use machine learning models for common
+  tasks such as image recognition, natural language processing, and predictive
+  analytics.
+- Model serving: Deploy models as containerized services that can be easily
+  integrated into applications and scaled as needed.
+- Reproducible environments: Package models with their dependencies, ensuring
+  consistent behavior across development and production environments.
+- Framework support: Find models built with popular frameworks like TensorFlow,
+  PyTorch, scikit-learn, and others.
+
+Containerized AI models remove the need to manage infrastructure dependencies,
+let you deploy models across different environments, and enable scaling as
+application demands change.
+
+#### Plugins
+
+Plugins in Docker Hub let you extend and customize Docker Engine to suit
+specialized requirements. Plugins integrate directly with the Docker Engine and
+provide capabilities such as:
+
+- Network plugins: Enhance networking functionality, enabling integration with
+  complex network infrastructures.
+- Volume plugins: Provide advanced storage options, supporting persistent and
+  distributed storage across various backends.
+- Authorization plugins: Offer fine-grained access control to secure Docker
+  environments.
+
+By leveraging Docker plugins, teams can tailor Docker Engine to meet their
+specific operational needs, ensuring compatibility with existing infrastructures
+and workflows.
+
+To learn more about plugins, see [Docker Engine managed plugin
+system](/manuals/engine/extend/_index.md).
+
+
 ### Trusted content
 
 Docker Hub's trusted content provides a curated selection of high-quality,
@@ -92,11 +160,19 @@ secure images designed to give developers confidence in the reliability and
 security of the resources they use. These images are stable, regularly updated,
 and adhere to industry best practices, making them a strong foundation for
 building and deploying applications. Docker Hub's trusted content includes,
-Docker Official Images, Verified Publisher images, and Docker-Sponsored Open
-Source Software images.
+Docker Hardened Images, Docker Official Images, Verified Publisher images, and
+Docker-Sponsored Open Source Software images.
 
 For more details, see [Trusted content](./trusted-content.md).
 
+### Publishers
+
+The **Publishers** filter lets you narrow image results by the organization
+that published the image.
+
+Publishers of trusted content appear first. Only a select number of publishers
+are shown.
+
 ### Categories
 
 Docker Hub makes it easy to find and explore container images with categories.
@@ -164,4 +240,4 @@ extension has been reviewed by Docker for quality and reliability.
 > [!NOTE]
 >
 > The **Reviewed by Docker** filter is only available for extensions. To make
-> the filter available, you must select only the **Extensions** filter in **Products**.
\ No newline at end of file
+> the filter available, you must select only the **Extensions** filter in **Products**.
diff --git a/content/manuals/docker-hub/image-library/trusted-content.md b/content/manuals/docker-hub/image-library/trusted-content.md
index 518ccfce6dbb..b13d0c6a4cdd 100644
--- a/content/manuals/docker-hub/image-library/trusted-content.md
+++ b/content/manuals/docker-hub/image-library/trusted-content.md
@@ -12,9 +12,9 @@ Docker Hub's trusted content provides a curated selection of high-quality,
 secure images designed to give developers confidence in the reliability and
 security of the resources they use. These images are stable, regularly updated,
 and adhere to industry best practices, making them a strong foundation for
-building and deploying applications. Docker Hub's trusted content includes,
-Docker Official Images, Verified Publisher images, and Docker-Sponsored Open
-Source Software images.
+building and deploying applications. Docker Hub's trusted content includes
+Docker Official Images, Docker Hardened Images and charts, Verified Publisher
+images, and Docker-Sponsored Open Source Software images.
 
 ## Docker Official Images
 
@@ -137,7 +137,7 @@ Docker Hub for examples on how to install packages if you are unfamiliar.
 ### Codenames
 
 Tags with words that look like Toy Story characters (for example, `bookworm`,
-`bullseye`, and `trixie`) or adjectives (such as `focal`, `jammy`, and
+`bullseye`, and `trixie`) or adjectives (such as `jammy`, and
 `noble`), indicate the codename of the Linux distribution they use as a base
 image. Debian release codenames are [based on Toy Story characters](https://en.wikipedia.org/wiki/Debian_version_history#Naming_convention),
 and Ubuntu's take the form of "Adjective Animal". For example, the
@@ -156,6 +156,37 @@ documentation. Reading through the "How to use this image" and
 "Image Variants" sections will help you to understand how to use these
 variants.
 
+### Troubleshooting failed pulls
+
+If you're experiencing failed pulls of Docker Official Images, check whether
+the `DOCKER_CONTENT_TRUST` environment variable is set to `1`. Docker Content
+Trust is being retired and the service is no longer reliable for pulls. To
+resolve pull failures, unset `DOCKER_CONTENT_TRUST`. For more information, see
+[Docker Content Trust (DCT)](/manuals/retired.md#docker-content-trust-dct).
+
+## Docker Hardened Images
+
+Docker Hardened Images (DHI) are minimal, secure, and production-ready
+container base and application images maintained by Docker. DHI also includes
+Docker-provided hardened Helm charts built from upstream sources and published
+as OCI artifacts in Docker Hub.
+
+DHI is designed to reduce vulnerabilities and simplify compliance while fitting
+into existing Docker workflows with little to no retooling required. Docker
+maintains near-zero CVEs in DHI images, and DHI images and charts include
+signed security metadata such as SBOMs and provenance attestations.
+
+Image and chart repositories have special badges
+on Docker Hub, making it easier to identify trusted DHI content.
+
+![Docker Hardened Image badge](../images/dhi-image-label.png)
+
+![Docker Hardened Chart badge](../images/dhi-chart-label.png)
+
+To browse available repositories, see the [Docker Hardened Images
+catalog](https://hub.docker.com/hardened-images/catalog). For implementation
+guidance, see [Docker Hardened Images](/dhi/).
+
 ## Verified Publisher images
 
 The Docker Verified Publisher program provides high-quality images from
@@ -169,7 +200,7 @@ Images that are part of this program have a special badge on Docker Hub making
 it easier for users to identify projects that Docker has verified as
 high-quality commercial publishers.
 
-![Docker-Sponsored Open Source badge](../images/verified-publisher-badge-iso.png)
+![Docker-Verified Publisher badge](../images/verified-publisher-badge-iso.png)
 
 ## Docker-Sponsored Open Source Software images
 
@@ -180,4 +211,4 @@ Images that are part of this program have a special badge on Docker Hub making
 it easier for users to identify projects that Docker has verified as trusted,
 secure, and active open-source projects.
 
-![Docker-Sponsored Open Source badge](../images/sponsored-badge-iso.png)
\ No newline at end of file
+![Docker-Sponsored Open Source badge](../images/sponsored-badge-iso.png)
diff --git a/content/manuals/docker-hub/images/azure-create-connection.png b/content/manuals/docker-hub/images/azure-create-connection.png
deleted file mode 100644
index 207a4d629c5d..000000000000
Binary files a/content/manuals/docker-hub/images/azure-create-connection.png and /dev/null differ
diff --git a/content/manuals/docker-hub/images/create-connection.png b/content/manuals/docker-hub/images/create-connection.png
deleted file mode 100644
index 30561e1ade28..000000000000
Binary files a/content/manuals/docker-hub/images/create-connection.png and /dev/null differ
diff --git a/content/manuals/docker-hub/images/dhi-chart-label.png b/content/manuals/docker-hub/images/dhi-chart-label.png
new file mode 100644
index 000000000000..abe3eb6b5f55
Binary files /dev/null and b/content/manuals/docker-hub/images/dhi-chart-label.png differ
diff --git a/content/manuals/docker-hub/images/dhi-image-label.png b/content/manuals/docker-hub/images/dhi-image-label.png
new file mode 100644
index 000000000000..b1bf81f0d0c4
Binary files /dev/null and b/content/manuals/docker-hub/images/dhi-image-label.png differ
diff --git a/content/manuals/docker-hub/images/official-image-badge-iso.png b/content/manuals/docker-hub/images/official-image-badge-iso.png
index 7f95fe185334..e700f1b6a4e3 100644
Binary files a/content/manuals/docker-hub/images/official-image-badge-iso.png and b/content/manuals/docker-hub/images/official-image-badge-iso.png differ
diff --git a/content/manuals/docker-hub/images/organization-tabs.png b/content/manuals/docker-hub/images/organization-tabs.png
deleted file mode 100644
index fa607aa1928e..000000000000
Binary files a/content/manuals/docker-hub/images/organization-tabs.png and /dev/null differ
diff --git a/content/manuals/docker-hub/images/saml-create-connection.png b/content/manuals/docker-hub/images/saml-create-connection.png
deleted file mode 100644
index 3a1e8dec5cbd..000000000000
Binary files a/content/manuals/docker-hub/images/saml-create-connection.png and /dev/null differ
diff --git a/content/manuals/docker-hub/images/sponsored-badge-iso.png b/content/manuals/docker-hub/images/sponsored-badge-iso.png
index 3281f86a5192..926ac801dad8 100644
Binary files a/content/manuals/docker-hub/images/sponsored-badge-iso.png and b/content/manuals/docker-hub/images/sponsored-badge-iso.png differ
diff --git a/content/manuals/docker-hub/images/verified-publisher-badge-iso.png b/content/manuals/docker-hub/images/verified-publisher-badge-iso.png
index 63721f3148d6..1e6620814bf9 100644
Binary files a/content/manuals/docker-hub/images/verified-publisher-badge-iso.png and b/content/manuals/docker-hub/images/verified-publisher-badge-iso.png differ
diff --git a/content/manuals/docker-hub/images/verified-publisher-badge.png b/content/manuals/docker-hub/images/verified-publisher-badge.png
index 27d99b87fcf4..2b7c19e02d61 100644
Binary files a/content/manuals/docker-hub/images/verified-publisher-badge.png and b/content/manuals/docker-hub/images/verified-publisher-badge.png differ
diff --git a/content/manuals/docker-hub/mcp-server.md b/content/manuals/docker-hub/mcp-server.md
new file mode 100644
index 000000000000..1ade9e51d983
--- /dev/null
+++ b/content/manuals/docker-hub/mcp-server.md
@@ -0,0 +1,264 @@
+---
+title: Docker Hub MCP server
+linkTitle: Hub MCP server
+description: The Docker Hub MCP Server makes Docker Hub image metadata accessible to LLMs for content discovery.
+keywords: Docker Hub MCP Server, Hub MCP server, Hub MCP
+weight: 60
+aliases:
+  - /ai/mcp-catalog-and-toolkit/hub-mcp/
+---
+
+The Docker Hub MCP Server is a Model Context Protocol (MCP) server that
+interfaces with Docker Hub APIs to make rich image metadata accessible to LLMs,
+enabling intelligent content discovery and repository management.
+
+For more information about MCP concepts and how MCP servers work, see the [Docker MCP Catalog and Toolkit](/ai/mcp-catalog-and-toolkit/) overview page.
+
+## Key features
+
+- Advanced LLM context: Docker's MCP Server provides LLMs with detailed, structured context for Docker Hub images, enabling smarter, more relevant recommendations for developers, whether they're choosing a base image or automating CI/CD workflows.
+- Natural language image discovery: Developers can find the right container image using natural language, no need to remember tags or repository names. Just describe what you need, and Docker Hub will return images that match your intent.
+- Simplified repository management: Hub MCP Server enables agents to manage repositories through natural language fetching image details, viewing stats, searching content, and performing key operations quickly and easily.
+
+## Install Docker Hub MCP server
+
+1. In Docker Desktop, select **MCP Toolkit** and select the **Profiles** tab,
+   then select **Create profile** to create a new profile, or select an existing
+   profile to use.
+2. Select the **Catalog** tab, search for **Docker Hub**, and select **Add to**
+   to add it to your profile.
+3. Select the **Profiles** tab, select the profile you added Docker Hub to, and
+   select the configuration icon on the Docker Hub MCP server. Enter your Docker
+   Hub username and personal access token (PAT).
+4. Under the **Clients** section of the same profile, if you already have a
+   client connected it connects automatically. Otherwise, select the plus icon
+   to add a client.
+
+For more details on setting up profiles and connecting clients, see
+[Get started with Docker MCP Toolkit](/ai/mcp-catalog-and-toolkit/get-started/).
+
+## Use Claude Desktop as a client
+
+1. Add the Docker Hub MCP Server configuration to your `claude_desktop_config.json`:
+
+   {{< tabs >}}
+   {{< tab name="For public repositories only">}}
+
+   ```json
+   {
+     "mcpServers": {
+       "docker-hub": {
+         "command": "node",
+         "args": ["/FULL/PATH/TO/YOUR/docker-hub-mcp-server/dist/index.js", "--transport=stdio"]
+       }
+     }
+   }
+   ```
+
+   Where :
+   - `/FULL/PATH/TO/YOUR/docker-hub-mcp-server` is the complete path to where you cloned the repository
+
+   {{< /tab >}}
+   {{< tab name="For authenticated access">}}
+
+   ```json
+   {
+     "mcpServers": {
+       "docker-hub": {
+         "command": "node",
+         "args": ["/FULL/PATH/TO/YOUR/docker-hub-mcp-server/dist/index.js", "--transport=stdio", "--username=YOUR_DOCKER_HUB_USERNAME"],
+         "env": {
+           "HUB_PAT_TOKEN": "YOUR_DOCKER_HUB_PERSONAL_ACCESS_TOKEN"
+         }
+       }
+     }
+   }
+   ```
+
+   Where :
+   - `YOUR_DOCKER_HUB_USERNAME` is your Docker Hub username.
+   - `YOUR_DOCKER_HUB_PERSONAL_ACCESS_TOKEN` is Docker Hub personal access token
+   - `/FULL/PATH/TO/YOUR/docker-hub-mcp-server` is the complete path to where you cloned the repository
+
+
+   {{< /tab >}}
+   {{</tabs >}}
+
+1. Save the configuration file and completely restart Claude Desktop for the changes to take effect.
+
+## Usage with Visual Studio Code
+
+1. Add the Docker Hub MCP Server configuration to your User Settings (JSON)
+   file in Visual Studio Code. You can do this by opening the `Command Palette` and
+   typing `Preferences: Open User Settings (JSON)`.
+
+
+   {{< tabs >}}
+   {{< tab name="For public repositories only">}}
+
+   ```json
+   {
+     "mcpServers": {
+       "docker-hub": {
+         "command": "node",
+         "args": ["/FULL/PATH/TO/YOUR/docker-hub-mcp-server/dist/index.js", "--transport=stdio"]
+       }
+     }
+   }
+   ```
+
+   Where :
+   - `/FULL/PATH/TO/YOUR/docker-hub-mcp-server` is the complete path to where you cloned the repository
+
+   {{< /tab >}}
+   {{< tab name="For authenticated access">}}
+
+   ```json
+   {
+     "mcpServers": {
+       "docker-hub": {
+         "command": "node",
+         "args": ["/FULL/PATH/TO/YOUR/docker-hub-mcp-server/dist/index.js", "--transport=stdio"],
+         "env": {
+           "HUB_USERNAME": "YOUR_DOCKER_HUB_USERNAME",
+           "HUB_PAT_TOKEN": "YOUR_DOCKER_HUB_PERSONAL_ACCESS_TOKEN"
+         }
+       }
+     }
+   }
+   ```
+
+   Where :
+   - `YOUR_DOCKER_HUB_USERNAME` is your Docker Hub username.
+   - `YOUR_DOCKER_HUB_PERSONAL_ACCESS_TOKEN` is Docker Hub personal access token
+   - `/FULL/PATH/TO/YOUR/docker-hub-mcp-server` is the complete path to where you cloned the repository
+
+
+   {{< /tab >}}
+   {{</tabs >}}
+
+1. Open the `Command Palette` and type `MCP: List Servers`.
+1. Select `docker-hub` and select `Start Server`.
+
+## Using other clients
+
+To integrate the Docker Hub MCP Server into your own development
+environment, see the source code and installation instructions on the
+[`hub-mcp` GitHub repository](https://github.com/docker/hub-mcp).
+
+
+## Usage examples
+
+This section provides task-oriented examples for common operations with Docker Hub
+tools.
+
+### Finding images
+
+
+```console
+# Search for official images
+$ docker ai "Search for official nginx images on Docker Hub"
+
+# Search for lightweight images to reduce deployment size and improve performance
+$ docker ai "Search for minimal Node.js images with small footprint"
+
+# Get the most recent tag of a base image
+$ docker ai "Show me the latest tag details for go"
+
+# Find a production-ready database with enterprise features and reliability
+$ docker ai "Search for production ready database images"
+
+# Compare Ubuntu versions to choose the right one for my project
+$ docker ai "Help me find the right Ubuntu version for my project"
+```
+
+### Repository management
+
+```console
+# Create a repository
+$ docker ai "Create a repository in my namespace"
+
+# List all repositories in my namespace
+$ docker ai "List all repositories in my namespace"
+
+# Find the largest repository in my namespace
+$ docker ai "Which of my repositories takes up the most space?"
+
+# Find repositories that haven't been updated recently
+$ docker ai "Which of my repositories haven't had any pushes in the last 60 days?"
+
+# Find which repositories are currently active and being used
+$ docker ai "Show me my most recently updated repositories"
+
+# Get details about a repository
+$ docker ai "Show me information about my '<repository-name>' repository"
+```
+
+### Pull/push images
+
+
+```console
+# Pull latest PostgreSQL version
+$ docker ai "Pull the latest postgres image"
+
+# Push image to your Docker Hub repository
+$ docker ai "Push my <image-name> to my <repository-name> repository"
+```
+
+### Tag management
+
+```console
+# List all tags for a repository
+$ $ docker ai "Show me all tags for my '<repository-name>' repository"
+
+# Find the most recently pushed tag
+$ docker ai "What's the most recent tag pushed to my '<repository-name>' repository?"
+
+# List tags with architecture filtering
+$ docker ai "List tags for in the '<repository-name>' repository that support amd64 architecture"
+
+# Get detailed information about a specific tag
+$ docker ai "Show me details about the '<tag-name>' tag in the '<repository-name>' repository"
+
+# Check if a specific tag exists
+$ docker ai "Check if version 'v1.2.0' exists for my 'my-web-app' repository"
+```
+
+### Docker Hardened Images
+
+```console
+# List available hardened images
+$ docker ai "What is the most secure image I can use to run a node.js application?"
+
+# Convert Dockerfile to use a hardened image
+$ docker ai "Can you help me update my Dockerfile to use a docker hardened image instead of the current one"
+```
+> [!NOTE]
+> To access Docker Hardened Images, a subscription is required. If you're interested in using Docker Hardened Images, visit [Docker Hardened Images](https://www.docker.com/products/hardened-images/).
+
+
+## Reference
+
+This section provides a comprehensive listing of the tools you can find
+in the Docker Hub MCP Server.
+
+### Docker Hub MCP server tools
+
+Tools to interact with your Docker repositories and discover content on Docker Hub.
+
+| Name | Description |
+|------|-------------|
+| `check-repository` | Check repository |
+| `check-repository-tag` | Check repository tag |
+| `check-repository-tags` | Check repository tags |
+| `create-repository` | Creates a new repository |
+| `docker-hardened-images` | Lists available [Docker Hardened Images](https://www.docker.com/products/hardened-images/) in specified namespace |
+| `get-namespaces` | Get organizations/namespaces for a user |
+| `get-repository-dockerfile` | Gets Dockerfile for repository |
+| `get-repository-info` | Gets repository info |
+| `list-repositories-by-namespace` | Lists repositories under namespace |
+| `list-repository-tags` | List repository tags |
+| `read-repository-tag` | Read repository tag |
+| `search` | Search content on Docker Hub |
+| `set-repository-dockerfile` | Sets Dockerfile for repository |
+| `update-repository-info` | Updates repository info |
diff --git a/content/manuals/docker-hub/quickstart.md b/content/manuals/docker-hub/quickstart.md
index 6d1f1d29fd0e..ab66eaae14c8 100644
--- a/content/manuals/docker-hub/quickstart.md
+++ b/content/manuals/docker-hub/quickstart.md
@@ -17,7 +17,7 @@ through creating a custom image and sharing it through Docker Hub.
 ## Prerequisites
 
 - [Download and install Docker](../../get-started/get-docker.md)
-- [Create a Docker account](https://app.docker.com/signup)
+- A verified [Docker](https://app.docker.com/signup) account
 
 ## Step 1: Find an image in Docker Hub's library
 
@@ -115,7 +115,7 @@ You can run images from Docker Hub using the CLI or Docker Desktop Dashboard.
    The container logs appear after the container starts.
 
 5. Select the **8080:80** link to open the server, or visit
-   [https://localhost:8080](https://localhost:8080) in your web browser.
+   [http://localhost:8080](http://localhost:8080) in your web browser.
 
 6. In the Docker Desktop Dashboard, select the **Stop** button to stop the
    container.
@@ -140,7 +140,7 @@ You can run images from Docker Hub using the CLI or Docker Desktop Dashboard.
    The `docker run` command automatically pulls and runs the image without the
    need to run `docker pull` first. To learn more about the command and its
    options, see the [`docker run` CLI
-   reference](../../reference/cli/docker/container/run.md). After running the
+   reference](/reference/cli/docker/container/run/). After running the
    command, you should see output similar to the following.
 
    ```console {collapse=true}
@@ -174,7 +174,7 @@ You can run images from Docker Hub using the CLI or Docker Desktop Dashboard.
    ...
    ```
 
-3. Visit [https://localhost:8080](https://localhost:8080) to view the default
+3. Visit [http://localhost:8080](http://localhost:8080) to view the default
    Nginx page and verify that the container is running.
 
 4. In the terminal, press <kdb>Ctrl+C</kbd> to stop the container.
@@ -216,7 +216,7 @@ customize your own images to suit specific needs.
    This command builds your image and tags it so that Docker understands which
    repository to push it to in Docker Hub. To learn more about the command and
    its options, see the [`docker build` CLI
-   reference](../../reference/cli/docker/buildx/build.md). After running the
+   reference](/reference/cli/docker/buildx/build/). After running the
    command, you should see output similar to the following.
 
    ```console {collapse=true}
@@ -241,7 +241,7 @@ customize your own images to suit specific needs.
    $ docker run -p 8080:80 --rm <YOUR-USERNAME>/nginx-custom
    ```
 
-4. Visit [https://localhost:8080](https://localhost:8080) to view the page. You
+4. Visit [http://localhost:8080](http://localhost:8080) to view the page. You
    should see `Hello world from Docker!`.
 
 5. In the terminal, press CTRL+C to stop the container.
@@ -262,7 +262,7 @@ customize your own images to suit specific needs.
    The command pushes the image to Docker Hub and automatically
    creates the repository if it doesn't exist. To learn more about the command,
    see the [`docker push` CLI
-   reference](../../reference/cli/docker/image/push.md). After running the
+   reference](/reference/cli/docker/image/push/). After running the
    command, you should see output similar to the following.
 
    ```console {collapse=true}
@@ -323,4 +323,3 @@ these options.
 
 Add [repository information](./repos/manage/information.md) to help users find and use
 your image.
-
diff --git a/content/manuals/docker-hub/release-notes.md b/content/manuals/docker-hub/release-notes.md
index 0f8e967863d8..4b45b5eb3b74 100644
--- a/content/manuals/docker-hub/release-notes.md
+++ b/content/manuals/docker-hub/release-notes.md
@@ -2,7 +2,8 @@
 title: Docker Hub release notes
 linkTitle: Release notes
 weight: 999
-description: Learn about the new features, bug fixes, and breaking changes for Docker
+description:
+  Learn about the new features, bug fixes, and breaking changes for Docker
   Hub
 keywords: docker hub, whats new, release notes
 toc_min: 1
@@ -13,6 +14,62 @@ tags: [Release notes]
 Here you can learn about the latest changes, new features, bug fixes, and
 known issues for each Docker Hub release.
 
+## 2026-08-20
+
+### New
+
+- The [Docker Verified Publisher Program](./repos/manage/trusted-content/dvp-program.md)
+  is now available via self-serve. Apply directly on the [DVP application
+  page](https://hub.docker.com/publisher-program/apply).
+
+## 2026-06-29
+
+### New
+
+- Docker Hub integrates with Cloudsmith, letting it handle authentication
+  for Docker Hub and Docker Hardened Images (DHI) upstreams using a managed
+  token. This removes the need to supply your own credentials during setup.
+  See Cloudsmith's announcement, [Set up Docker Hub and DHI upstreams with
+  Cloudsmith-managed
+  authentication](https://cloudsmith.com/changelog/set-up-docker-hub-and-dhi-upstreams-with-cloudsmith-managed-authentication),
+  for details.
+
+## 2026-05-20
+
+### Infrastructure updates
+
+- Docker Hub has added Amazon CloudFront as a CDN for image pushes and pulls,
+  improving reliability. You may see a new domain,
+  `production.cloudfront.docker.com`, in your network logs. TLS certificates for
+  this domain are issued by Amazon Trust Services.
+
+  Most users are unaffected. You may need to take action if your environment
+  uses an egress firewall with a domain allowlist, a TLS inspection proxy, or a
+  managed CA trust store. See the [Docker Desktop
+  allowlist](/manuals/desktop/setup/allow-list.md) for updated domain
+  requirements. If you see TLS errors, ensure your trust store includes the
+  [Amazon Trust Services Root CAs](https://www.amazontrust.com/repository/). If
+  you're a paid subscriber, you can [contact Docker
+  Support](https://hub.docker.com/support/contact/) if you need updated TLS
+  certificate details or the issue persists.
+
+## 2026-05-06
+
+### Deprecation notice
+
+- [Docker Hub Automated Builds](./repos/manage/builds/) 
+  is being deprecated. Existing accounts will have access until April 1, 2027. 
+  See [migration options](./repos/manage/builds/migrate/)
+  for guides on migrating to GitHub Actions or Bitbucket Pipelines.
+
+## 2026-02-13
+
+### New
+
+- Administrators can now prevent creating public repositories within
+  organization namespaces using the [Disable public
+  repositories](./settings.md#disable-creation-of-public-repos) setting.
+
 ## 2025-02-18
 
 ### New
@@ -29,7 +86,7 @@ known issues for each Docker Hub release.
 
 ### New
 
- - You can tag Docker Hub repositories with [categories](./repos/manage/information.md#repository-categories).
+- You can tag Docker Hub repositories with [categories](./repos/manage/information.md#repository-categories).
 
 ## 2023-12-11
 
@@ -47,13 +104,13 @@ known issues for each Docker Hub release.
 
 ## 2023-08-28
 
-- Organizations with SSO enabled can assign members to roles, organizations, and teams with [SCIM role mapping](scim.md#set-up-role-mapping). 
+- Organizations with SSO enabled can assign members to roles, organizations, and teams with [SCIM role mapping](scim.md#set-up-role-mapping).
 
 ## 2023-07-26
 
 ### New
 
-- Organizations can assign the [editor role](roles-and-permissions.md) to members to grant additional permissions without full administrative access.
+- Organizations can assign the [editor role](/manuals/enterprise/security/roles-and-permissions/_index.md) to members to grant additional permissions without full administrative access.
 
 ## 2023-05-09
 
@@ -65,7 +122,7 @@ known issues for each Docker Hub release.
 
 ### New
 
--  You can now automatically sync user updates with your Docker organizations and teams with [Group Mapping](group-mapping.md) for SSO and SCIM provisioning.
+- You can now automatically sync user updates with your Docker organizations and teams with [Group Mapping](group-mapping.md) for SSO and SCIM provisioning.
 
 ## 2022-12-12
 
@@ -73,7 +130,6 @@ known issues for each Docker Hub release.
 
 - The new domain audit feature lets you audit your domains for users who aren't a member of your organization.
 
-
 ## 2022-09-26
 
 ### New
@@ -84,13 +140,13 @@ known issues for each Docker Hub release.
 
 ### Bug fixes and enhancements
 
-- In Docker Hub, you can now download a [registry.json](../security/for-admins/enforce-sign-in/_index.md) file or copy the commands to create a registry.json file to enforce sign-in for your organization.
+- In Docker Hub, you can now download a [registry.json](/manuals/enterprise/security/enforce-sign-in/_index.md) file or copy the commands to create a registry.json file to enforce sign-in for your organization.
 
 ## 2022-09-19
 
 ### Bug fixes and enhancements
 
-- You can now [export a CSV file of members](../admin/organization//members.md#export-members) from organizations that you own.
+- You can now [export a CSV file of members](../admin/organization/manage/members.md#export-members-csv-file) from organizations that you own.
 
 ## 2022-07-22
 
@@ -114,7 +170,7 @@ known issues for each Docker Hub release.
 
 ### New
 
-- [Registry Access Management](/manuals/security/for-admins/hardened-desktop/registry-access-management.md) is now available for all Docker Business subscriptions. When enabled, your users can access specific registries in Docker Hub.
+- [Registry Access Management](/manuals/enterprise/security/hardened-desktop/registry-access-management.md) is now available for all Docker Business subscriptions. When enabled, your users can access specific registries in Docker Hub.
 
 ## 2022-05-03
 
@@ -126,7 +182,7 @@ known issues for each Docker Hub release.
 
 ### New
 
-- You can now purchase or upgrade to a Docker Business subscription using a credit card. To learn more, see [Upgrade your subscription](../subscription//change.md).
+- You can now purchase or upgrade to a Docker Business subscription using a credit card. To learn more, see [Upgrade your subscription](../subscription/plans/docker.md).
 
 ## 2021-08-31
 
@@ -143,7 +199,7 @@ The updated [Docker Subscription Service Agreement](https://www.docker.com/legal
 - The existing Docker Free subscription has been renamed **Docker Personal**.
 - **No changes** to Docker Engine or any other upstream **open source** Docker or Moby project.
 
-    To understand how these changes affect you, read the [FAQs](https://www.docker.com/pricing/faq). For more information, see [Docker subscription overview](../subscription/_index.md).
+  To understand how these changes affect you, read the [FAQs](https://www.docker.com/pricing/faq). For more information, see [Docker subscription overview](../subscription/_index.md).
 
 ## 2021-05-05
 
@@ -183,7 +239,7 @@ Docker introduces the Advanced Image Management dashboard that enables you to vi
 
 Docker introduces Audit logs, a new feature that allows team owners to view a list of activities that occur at organization and repository levels. This feature begins tracking the activities from the release date, that is, **from 25 January 2021**.
 
-For more information about this feature and for instructions on how to use it, see [Activity logs](../admin/organization/activity-logs.md).
+For more information about this feature and for instructions on how to use it, see [Activity logs](../admin/activity-logs.md).
 
 ## 2020-11-10
 
@@ -201,98 +257,94 @@ Docker introduces Hub Vulnerability Scanning which enables you to automatically
 
 ### New features
 
-* Docker has announced a new, per-seat pricing model to accelerate developer workflows for cloud-native development. The previous private repository/concurrent autobuild-based plans have been replaced with new **Pro** and **Team** plans that include unlimited private repositories. For more information, see [Docker subscription](../subscription/_index.md).
+- Docker has announced a new, per-seat pricing model to accelerate developer workflows for cloud-native development. The previous private repository/concurrent autobuild-based plans have been replaced with new **Pro** and **Team** plans that include unlimited private repositories. For more information, see [Docker subscription](../subscription/_index.md).
 
-* Docker has enabled download rate limits for downloads and pull requests on Docker Hub. This caps the number of objects that users can download within a specified timeframe. For more information, see [Usage and limits](/manuals/docker-hub/usage/_index.md).
+- Docker has enabled download rate limits for downloads and pull requests on Docker Hub. This caps the number of objects that users can download within a specified timeframe. For more information, see [Usage and limits](/manuals/docker-hub/usage/_index.md).
 
 ## 2019-11-04
 
 ### Enhancements
 
-* The [repositories page](repos/_index.md) and all
-related settings and tabs have been updated and moved from `cloud.docker.com`
-to `hub.docker.com`. You can access the page at its new URL: [https://hub.docker.com/repositories](https://hub.docker.com/repositories).
+- The [repositories page](repos/_index.md) and all
+  related settings and tabs have been updated and moved from `cloud.docker.com`
+  to `hub.docker.com`. You can access the page at its new URL: [https://hub.docker.com/repositories](https://hub.docker.com/repositories).
 
 ### Known Issues
 
-* Scan results don't appear for some official images.
+- Scan results don't appear for some official images.
 
 ## 2019-10-21
 
 ### New features
 
-* **Beta:** Docker Hub now supports two-factor authentication (2FA). Enable it in your account settings, under the **[Security](https://hub.docker.com/settings/security)** section.
+- **Beta:** Docker Hub now supports two-factor authentication (2FA). Enable it in your account settings, under the **[Security](https://hub.docker.com/settings/security)** section.
 
-    > If you lose both your 2FA authentication device and recovery code, you may
-    > not be able to recover your account.
+  > If you lose both your 2FA authentication device and recovery code, you may
+  > not be able to recover your account.
 
 ### Enhancements
 
-* As a security measure, when two-factor authentication is enabled, the Docker CLI requires a personal access token instead of a password to log in.
+- As a security measure, when two-factor authentication is enabled, the Docker CLI requires a personal access token instead of a password to log in.
 
 ### Known Issues
 
-* Scan results don't appear for some official images.
-
+- Scan results don't appear for some official images.
 
 ## 2019-10-02
 
 ### Enhancements
 
-* You can now manage teams and members straight from your [organization page](https://hub.docker.com/orgs).
-Each organization page now breaks down into these tabs:
-  * **New:** Members - manage your members directly from this page (delete,
-  add, or open their teams)
-  * **New:** Teams - search by team or username, and open up any team page to
-  manage the team
-  * **New:** Invitees (conditional tab, only if an invite exists) - resend or
-  remove invitations from this tab
-  * Repositories
-  * Settings
-  * Billing
+- You can now manage teams and members straight from your [organization page](https://hub.docker.com/orgs).
+  Each organization page now breaks down into these tabs:
+  - **New:** Members - manage your members directly from this page (delete,
+    add, or open their teams)
+  - **New:** Teams - search by team or username, and open up any team page to
+    manage the team
+  - **New:** Invitees (conditional tab, only if an invite exists) - resend or
+    remove invitations from this tab
+  - Repositories
+  - Settings
+  - Billing
 
 ### Bug fixes
 
-* Fixed an issue where Kinematic could not connect and log in to Docker Hub.
+- Fixed an issue where Kinematic could not connect and log in to Docker Hub.
 
 ### Known Issues
 
-* Scan results don't appear for some official images.
-
+- Scan results don't appear for some official images.
 
 ## 2019-09-19
 
 ### New features
 
-* You can now [create personal access tokens](/security/for-developers/access-tokens/) in Docker Hub and use them to authenticate from the Docker CLI. Find them in your account settings, under the new **[Security](https://hub.docker.com/settings/security)** section.
+- You can now [create personal access tokens](/security/access-tokens/) in Docker Hub and use them to authenticate from the Docker CLI. Find them in your account settings, under the new **[Security](https://hub.docker.com/settings/security)** section.
 
 ### Known Issues
 
-* Scan results don't appear for some official images.
-
+- Scan results don't appear for some official images.
 
 ## 2019-09-16
 
 ### Enhancements
 
-* The [billing page](../subscription/change.md) for personal accounts has been updated. You can access the page at its new URL: [https://hub.docker.com/billing/plan](https://hub.docker.com/billing/plan).
+- The [billing page](../subscription/plans/docker.md) for personal accounts has been updated. You can access the page at its new URL: [https://hub.docker.com/billing/plan](https://hub.docker.com/billing/plan).
 
 ### Known Issues
 
-* Scan results don't appear for some official images.
-
+- Scan results don't appear for some official images.
 
 ## 2019-09-05
 
 ### Enhancements
 
-* The `Tags` tab on an image page now provides additional information for each tag:
-  * A list of digests associated with the tag
-  * The architecture it was built on
-  * The OS
-  * The user who most recently updated an image for a specific tag
-* The security scan summary for Docker Official Images has been updated.
+- The `Tags` tab on an image page now provides additional information for each tag:
+  - A list of digests associated with the tag
+  - The architecture it was built on
+  - The OS
+  - The user who most recently updated an image for a specific tag
+- The security scan summary for Docker Official Images has been updated.
 
 ### Known Issues
 
-* Scan results don't appear for some official images.
+- Scan results don't appear for some official images.
diff --git a/content/manuals/docker-hub/repos/_index.md b/content/manuals/docker-hub/repos/_index.md
index 7554387ac2f5..a6dd3adeb86d 100644
--- a/content/manuals/docker-hub/repos/_index.md
+++ b/content/manuals/docker-hub/repos/_index.md
@@ -54,6 +54,3 @@ In this section, learn how to:
 
 - [Archive](./archive.md) an outdated or unsupported repository.
 - [Delete](./delete.md) a repository.
-- [Manage personal settings](./settings.md): For your account, you can set personal
-  settings for repositories, including default repository privacy and autobuild
-  notifications.
diff --git a/content/manuals/docker-hub/repos/create.md b/content/manuals/docker-hub/repos/create.md
index 8bbb8513b573..9e20df6710c0 100644
--- a/content/manuals/docker-hub/repos/create.md
+++ b/content/manuals/docker-hub/repos/create.md
@@ -39,7 +39,7 @@ weight: 20
      is only accessible to you and collaborators. In addition, if you selected
      an organization's namespace, then the repository is accessible to those
      with applicable roles or permissions. For more details, see [Roles and
-     permissions](../../security/for-admins/roles-and-permissions.md).
+     permissions](/manuals/enterprise/security/roles-and-permissions.md).
 
    > [!NOTE]
    >
diff --git a/content/manuals/docker-hub/repos/manage/access.md b/content/manuals/docker-hub/repos/manage/access.md
index 4dbf8f2d88d5..c88d3492cfb3 100644
--- a/content/manuals/docker-hub/repos/manage/access.md
+++ b/content/manuals/docker-hub/repos/manage/access.md
@@ -94,7 +94,7 @@ repository from that repository's **Settings** page.
 
 Organizations can use roles for individuals, giving them different
 permissions in the organization. For more details, see [Roles and
-permissions](/manuals/security/for-admins/roles-and-permissions.md).
+permissions](/manuals/enterprise/security/roles-and-permissions.md).
 
 ## Organization teams
 
@@ -105,7 +105,7 @@ access.
 
 You must create a team before you are able to configure repository permissions.
 For more details, see [Create and manage a
-team](/manuals/admin/organization/manage-a-team.md).
+team](/manuals/admin/organization/manage/manage-a-team.md).
 
 To configure team repository permissions:
 
@@ -131,4 +131,45 @@ To configure team repository permissions:
 
 Organizations can use OATs. OATs let you assign fine-grained repository access
 permissions to tokens. For more details, see [Organization access
-tokens](/manuals/security/for-admins/access-tokens.md).
+tokens](/manuals/enterprise/security/access-tokens.md).
+
+## Gated distribution
+
+{{< summary-bar feature_name="Gated distribution" >}}
+
+Gated distribution allows publishers to securely share private container images with external customers or partners, without giving them full organization access or visibility into your teams, collaborators, or other repositories.
+
+This feature is ideal for commercial software publishers who want to control who can pull specific images while preserving a clean separation between internal users and external consumers.
+
+If you are interested in Gated Distribution contact the <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_hub_gated_distribution" class="link" rel="noopener">Docker Sales Team</a> for more information.
+
+### Key features
+
+- **Private repository distribution**: Content is stored in private repositories and only accessible to explicitly invited users.
+
+- **External access without organization membership**: External users don't need to be added to your internal organization to pull images.
+
+- **Pull-only permissions**: External users receive pull-only access and cannot push or modify repository content.
+
+- **Invite-only access**: Access is granted through authenticated email invites, managed via API.
+
+### Invite distributor members via API
+
+> [!NOTE]
+> When you invite members, you assign them a role. See [Roles and permissions](/manuals/enterprise/security/roles-and-permissions.md) for details about the access permissions for each role.
+
+Distributor members (used for gated distribution) can only be invited using the Docker Hub API. UI-based invitations are not currently supported for this role. To invite distributor members, use the Bulk create invites API endpoint.
+
+To invite distributor members:
+
+1. Use the [Authentication API](https://docs.docker.com/reference/api/hub/latest/#tag/authentication-api/operation/AuthCreateAccessToken) to generate a bearer token for your Docker Hub account.
+
+2. Create a team in the Hub UI or use the [Teams API](https://docs.docker.com/reference/api/hub/latest/#tag/groups/paths/~1v2~1orgs~1%7Borg_name%7D~1groups/post).
+
+3. Grant repository access to the team:
+   - In the Hub UI: Navigate to your repository settings and add the team with "Read-only" permissions
+   - Using the [Repository Teams API](https://docs.docker.com/reference/api/hub/latest/#tag/repositories/paths/~1v2~1repositories~1%7Bnamespace%7D~1%7Brepository%7D~1groups/post): Assign the team to your repositories with "read-only" access level
+
+4. Use the [Bulk create invites endpoint](https://docs.docker.com/reference/api/hub/latest/#tag/invites/paths/~1v2~1invites~1bulk/post) to send email invites with the distributor member role. In the request body, set the "role" field to "distributor_member".
+
+5. The invited user will receive an email with a link to accept the invite. After signing in with their Docker ID, they'll be granted pull-only access to the specified private repository as a distributor member.
diff --git a/content/manuals/docker-hub/repos/manage/builds/_index.md b/content/manuals/docker-hub/repos/manage/builds/_index.md
index 9ce20e697d13..db9dc1836431 100644
--- a/content/manuals/docker-hub/repos/manage/builds/_index.md
+++ b/content/manuals/docker-hub/repos/manage/builds/_index.md
@@ -3,12 +3,21 @@ description: how automated builds work
 keywords: docker hub, automated builds
 title: Automated builds
 weight: 90
+params:
+  sidebar:
+    badge:
+      color: gray
+      text: Deprecated
 aliases:
 - /docker-hub/builds/how-builds-work/
 ---
 
 {{< summary-bar feature_name="Automated builds" >}}
 
+> [!WARNING]
+> Docker Hub Automated Builds is a deprecated feature.
+> It will be fully retired on April 1, 2027.
+
 Docker Hub can automatically build images from source code in an external
 repository and automatically push the built image to your Docker repositories.
 
@@ -30,7 +39,7 @@ pushing to the registry. You can use these tests to create a continuous
 integration workflow where a build that fails its tests doesn't push the built
 image. Automated tests don't push images to the registry on their own. [Learn about automated image testing](automated-testing.md).
 
-Depending on your [subscription](https://www.docker.com/pricing),
+Depending on your [subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsHubRepoBuilds),
 you may get concurrent builds, which means that `N` autobuilds can be run at the
 same time. `N` is configured according to your subscription. Once `N+1` builds
 are running, any additional builds go into a queue to be run later.
diff --git a/content/manuals/docker-hub/repos/manage/builds/advanced.md b/content/manuals/docker-hub/repos/manage/builds/advanced.md
index e34ef9deea24..5428e897af53 100644
--- a/content/manuals/docker-hub/repos/manage/builds/advanced.md
+++ b/content/manuals/docker-hub/repos/manage/builds/advanced.md
@@ -8,6 +8,11 @@ aliases:
 - /docker-hub/builds/advanced/
 ---
 
+
+> [!WARNING]
+> Docker Hub Automated Builds is a deprecated feature.
+> It will be fully retired on April 1, 2027.
+
 > [!NOTE]
 >
 > Automated builds require a
@@ -119,7 +124,7 @@ $ docker build --build-arg CUSTOM=$VAR -f $DOCKERFILE_PATH -t $IMAGE_NAME .
 > A `hooks/build` file overrides the basic `docker build` command used by the builder, so you must include a similar build command in the hook or
 the automated build fails.
 
-Refer to the [docker build documentation](/reference/cli/docker/buildx/build.md#build-arg)
+Refer to the [docker build documentation](/reference/cli/docker/buildx/build/#build-arg)
 to learn more about Docker build-time variables.
 
 #### Push to multiple repositories
diff --git a/content/manuals/docker-hub/repos/manage/builds/automated-testing.md b/content/manuals/docker-hub/repos/manage/builds/automated-testing.md
index 79d381757cf6..4dabaee04263 100644
--- a/content/manuals/docker-hub/repos/manage/builds/automated-testing.md
+++ b/content/manuals/docker-hub/repos/manage/builds/automated-testing.md
@@ -7,6 +7,10 @@ aliases:
 - /docker-hub/builds/automated-testing/
 ---
 
+> [!WARNING]
+> Docker Hub Automated Builds is a deprecated feature.
+> It will be fully retired on April 1, 2027.
+
 > [!NOTE]
 >
 > Automated builds require a
diff --git a/content/manuals/docker-hub/repos/manage/builds/images/autobuild-example.png b/content/manuals/docker-hub/repos/manage/builds/images/autobuild-example.png
new file mode 100644
index 000000000000..e1ee9af139b1
Binary files /dev/null and b/content/manuals/docker-hub/repos/manage/builds/images/autobuild-example.png differ
diff --git a/content/manuals/docker-hub/repos/manage/builds/link-source.md b/content/manuals/docker-hub/repos/manage/builds/link-source.md
index 61e270190cc7..2cabd76c0a34 100644
--- a/content/manuals/docker-hub/repos/manage/builds/link-source.md
+++ b/content/manuals/docker-hub/repos/manage/builds/link-source.md
@@ -11,6 +11,10 @@ aliases:
 - /docker-hub/builds/link-source/
 ---
 
+> [!WARNING]
+> Docker Hub Automated Builds is a deprecated feature.
+> It will be fully retired on April 1, 2027.
+
 > [!NOTE]
 >
 > Automated builds require a Docker Pro, Team, or Business subscription.
@@ -21,7 +25,7 @@ code service to Docker Hub so that it can access your source code
 repositories. You can configure this link for user accounts or
 organizations.
 
-If you are linking a source code provider to create autobuilds for a team, follow the instructions to [create a service account](index.md#service-users-for-team-autobuilds) for the team before linking the account as described below.
+If you are linking a source code provider to create autobuilds for a team, follow the instructions to [create a service account](setup.md#service-users-for-team-autobuilds) for the team before linking the account as described below.
 
 ## Link to a GitHub user account
 
diff --git a/content/manuals/docker-hub/repos/manage/builds/manage-builds.md b/content/manuals/docker-hub/repos/manage/builds/manage-builds.md
index d1951da03592..5bf33052290b 100644
--- a/content/manuals/docker-hub/repos/manage/builds/manage-builds.md
+++ b/content/manuals/docker-hub/repos/manage/builds/manage-builds.md
@@ -6,6 +6,10 @@ aliases:
 - /docker-hub/builds/manage-builds/
 ---
 
+> [!WARNING]
+> Docker Hub Automated Builds is a deprecated feature.
+> It will be fully retired on April 1, 2027.
+
 > [!NOTE]
 >
 > Automated builds require a Docker Pro, Team, or Business subscription.
diff --git a/content/manuals/docker-hub/repos/manage/builds/migrate.md b/content/manuals/docker-hub/repos/manage/builds/migrate.md
new file mode 100644
index 000000000000..c811015fc5b9
--- /dev/null
+++ b/content/manuals/docker-hub/repos/manage/builds/migrate.md
@@ -0,0 +1,192 @@
+---
+description: Migrate from Autobuilds to CI/CD workflows
+keywords: automated builds, autobuilds, migration, github actions, bitbucket pipelines
+title: Migrate from Autobuilds
+linkTitle: Migrate
+weight: 80
+---
+
+> [!WARNING]
+> Docker Hub Automated Builds is a deprecated feature.
+> It will be fully retired on April 1, 2027.
+
+This guide explains how to migrate your Docker Hub Autobuilds setup to
+Continuous Integration (CI) workflows, focusing on GitHub Actions and Bitbucket
+Pipelines as these are the built-in CI services for the two version control
+services supported via Autobuilds.
+
+## Step 1: Create access tokens
+
+To grant your CI workflows the ability to pull and push images to and from
+Docker Hub, you first need to create access tokens:
+
+- For a personal repository: Create a [Personal
+  Access Token](../../../../security/access-tokens.md) with **Read & Write**
+  permissions.
+
+- For an organization repository: Create an [Organization Access
+  Token](../../../../enterprise/security/access-tokens.md) with the following
+  permissions:
+  - **Read public repositories**
+  - **Image Pull** on any private repositories that the build needs to pull from
+  - **Image Push** on the repository that the built image will be pushed to
+
+The same token can be used for all CI workflows under the account's namespace
+provided it has adequate permissions to all relevant Docker Hub repositories.
+
+Store the token securely in a password manager or your CI/CD platform's secrets
+manager. Never commit tokens to source code repositories.
+
+## Step 2: Extract your Autobuilds configuration
+
+For each Docker Hub repository currently configured to use Autobuilds, you need
+to extract its configuration to set up your CI workflows to duplicate the
+existing functionality. The only way to extract the configuration is via the
+Docker Hub web interface.
+
+1. Sign in to [Docker Hub](https://hub.docker.com).
+
+2. Navigate to your repository by going to **My Hub** > ***Your namespace*** >
+   **Repositories** > ***Your Repository***.
+
+3. Go to the **Builds** tab and select **Configure automated builds**.
+
+   If there is no existing build configuration, then this repository is not
+   configured for Autobuilds.
+
+4. Note the following configuration details:
+
+   - **Source Repository**: The GitHub or Bitbucket repository. The organization
+     is the namespace and the repository is the repository name. This is where
+     you need to add your workflow.
+
+   - **Autotest**: If Autotest is enabled for Pull Requests (either internal
+     only or internal and external), then extra steps are needed in your
+     workflow to run the Autotest step.
+
+   - **Repository Links**: Not supported and can be ignored. If chain builds are
+     required, see the documentation for your CI service on how to chain builds
+     together.
+
+   - **Build Rules**: Specify the triggers, tags, and paths of your builds.
+     Ignore any entry where **Autobuild** is toggled off.
+
+   - **Build Environment Variables**: User-defined variables injected as
+     environment variables into your build. You need to add these to your
+     workflow. If the environment variables contain secrets, add them to your CI
+     service's secrets manager. Then update your Dockerfile or build scripts to
+     reference these secrets using your CI platform's syntax. See your CI
+     service documentation on how to handle secrets.
+
+### Example configuration
+
+The following image shows an example Autobuilds configuration.
+
+![Example Autobuilds configuration](./images/autobuild-example.png)
+
+Based on the pictured example, you would note the following items for this
+Autobuilds configuration:
+
+- Source code repository: GitHub repository `docker/docker-rust-hello`
+- Autotest: Disabled
+- Build rule 1: Build and push the image with tag `latest` when a new commit to
+  the `main` branch is detected. The Dockerfile is at `./Dockerfile` and the
+  build context is the root of the cloned code.
+- Build rule 2: Build and push the image with tag `v{\1}` when a new commit
+  to a tag matching the regex `^v([0-9.]+)$` is detected. The Dockerfile is at
+  `./Dockerfile` and the build context is the root of the cloned code.
+- Environment variable: Key `ENV_KEY` with value `ENV_VALUE`
+
+## Step 3: Migrate to your CI/CD platform
+
+Select the tab that matches your source code repository hosting platform.
+
+{{< tabs >}}
+{{< tab name="GitHub Actions" >}}
+
+If your source code repository is hosted on GitHub, see the [Docker
+Autobuilds example repository](https://github.com/docker/autobuilds-actions).
+
+All files except those under the `.github/workflows` directory are for example
+purposes only.
+
+The repository's readme details how to migrate from Autobuilds to GitHub Actions
+using one of the two provided workflows:
+
+- The `simple-build` workflow builds and pushes a Docker image to your Docker
+  Hub repository.
+- The `full-autobuilds` workflow contains all the steps commonly used within an
+  Autobuilds run, including building, tagging, running Docker Compose tests, and
+  running optional bash hook files.
+
+### Steps to migrate
+
+1. Follow the instructions in the [example repository
+   readme](https://github.com/docker/autobuilds-actions) to configure a CI GitHub
+   Action workflow in your GitHub repository.
+
+2. The workflows contain comments on what each step does and where changes
+   should be made. Important changes to make include:
+
+   - Set the `DOCKER_REPOSITORY_NAME` environment variable to the full name of your Docker Hub repository
+   - Set your image tagging policy
+   - Set the workflow triggers
+
+   Links to relevant documentation are provided in the readme and the workflow comments.
+
+3. After you have completed migrating to GitHub Actions, delete the build
+   configuration from your Docker Hub repository:
+
+   1. Navigate to the repository's **Builds** tab.
+
+   2. Select **Configure automated builds**.
+
+   3. Select **Delete Build Configuration**.
+
+{{< /tab >}}
+{{< tab name="Bitbucket Pipelines" >}}
+
+If your source code repository is hosted on Bitbucket, see the [Docker
+Autobuilds Bitbucket example
+repository](https://bitbucket.org/docker-io/autobuilds-pipeline).
+
+All files except the `bitbucket-pipelines.yml` file are for example purposes only.
+
+The repository's readme details how to migrate from Autobuilds to Bitbucket
+Pipelines using the provided example `bitbucket-pipelines.yml` configuration
+file.
+
+The pipeline example contains three separate pipelines:
+
+- `branches/main`: Shows how to build, test, and push an image on changes to a specific branch
+- `tags/*`: Shows how to build, test, and push an image on tag pushes, including
+  tagging the image the same as the Git tag
+- `pull-requests/*`: Shows how to build and test, but not push, an image from a pull request
+
+### Steps to migrate
+
+1. Follow the instructions in the [example repository
+   readme](https://bitbucket.org/docker-io/autobuilds-pipeline) to configure
+   a Bitbucket Pipeline in your Bitbucket repository.
+
+2. Comments in the pipeline configuration explain what each part does and where
+   changes need to be made. Important changes to make include:
+
+   - Set the `DOCKER_REPOSITORY_NAME` environment variable to the full name of
+     your Docker Hub repository
+   - Set your image tagging policy (see where the `DOCKER_TAG` variable is set in each pipeline)
+   - Set the pipeline triggers for branches, tags, and/or pull-requests
+
+   Links to relevant documentation are provided in the readme and the workflow comments.
+
+3. After you have completed migrating to Bitbucket Pipelines, delete the Build
+   configuration from your Docker Hub repository:
+
+   1. Navigate to the repository's **Builds** tab.
+
+   2. Select **Configure automated builds**.
+
+   3. Select **Delete Build Configuration**.
+
+{{< /tab >}}
+{{< /tabs >}}
diff --git a/content/manuals/docker-hub/repos/manage/builds/setup.md b/content/manuals/docker-hub/repos/manage/builds/setup.md
index 38a97f360eba..667480e2a643 100644
--- a/content/manuals/docker-hub/repos/manage/builds/setup.md
+++ b/content/manuals/docker-hub/repos/manage/builds/setup.md
@@ -10,6 +10,10 @@ aliases:
 - /docker-hub/builds/
 ---
 
+> [!WARNING]
+> Docker Hub Automated Builds is a deprecated feature.
+> It will be fully retired on April 1, 2027.
+
 > [!NOTE]
 >
 > Automated builds require a
@@ -30,8 +34,8 @@ when the tests succeed.
 
    > [!NOTE]
    >
-   > You may be redirected to the settings page to [link](link-source.md) the
-   > code repository service. Otherwise, if you are editing the build settings
+   > You may be redirected to the settings page to [link the code repository
+   > service](link-source.md). Otherwise, if you are editing the build settings
    > for an existing automated build, select **Configure automated builds**.
 
 4. Select the **source repository** to build the Docker images from.
@@ -154,7 +158,7 @@ each repository. In [Docker Hub](https://hub.docker.com), select **My Hub** > **
 
 ### Tag and branch builds
 
-You can configure your automated builds so that pushes to specific branches or tags triggers a build.
+You can configure your automated builds so that pushes to specific branches or tags trigger a build.
 
 1. In the **Build Rules** section, select the **plus** icon to add more sources to build.
 
@@ -170,7 +174,7 @@ You can configure your automated builds so that pushes to specific branches or t
     > [!NOTE]
     >
     > You can enter a name, or use a regex to match which source branch or tag
-    > names to build. To learn more, see [regexes](index.md#regexes-and-automated-builds).
+    > names to build. To learn more, see [regexes](#regexes-and-automated-builds).
 
 4. Enter the tag to apply to Docker images built from this source.
 
@@ -178,7 +182,7 @@ You can configure your automated builds so that pushes to specific branches or t
    >
    > If you configured a regex to select the source, you can reference the
    > capture groups and use its result as part of the tag. To learn more, see
-   > [regexes](index.md#regexes-and-automated-builds).
+   > [regexes](#regexes-and-automated-builds).
 
 5. Repeat steps 2 through 4 for each new build rule you set up.
 
diff --git a/content/manuals/docker-hub/repos/manage/builds/troubleshoot.md b/content/manuals/docker-hub/repos/manage/builds/troubleshoot.md
index 917ae4a17215..45774fe5d879 100644
--- a/content/manuals/docker-hub/repos/manage/builds/troubleshoot.md
+++ b/content/manuals/docker-hub/repos/manage/builds/troubleshoot.md
@@ -8,6 +8,10 @@ aliases:
 - /docker-hub/builds/troubleshoot/
 ---
 
+> [!WARNING]
+> Docker Hub Automated Builds is a deprecated feature.
+> It will be fully retired on April 1, 2027.
+
 > [!NOTE]
 >
 > Automated builds require a
@@ -61,7 +65,7 @@ system access to the repositories.
     This step is optional, but allows you to revoke the build-only keypair without removing other access.
 
 2. Copy the private half of the keypair to your clipboard.
-3. In Docker Hub, navigate to the build page for the repository that has linked private submodules. (If necessary, follow the steps [here](index.md#configure-automated-builds) to configure the automated build.)
+3. In Docker Hub, navigate to the build page for the repository that has linked private submodules. (If necessary, [follow the steps here](index.md#configure-automated-builds) to configure the automated build.)
 4. At the bottom of the screen, select the **plus** icon next to **Build Environment variables**.
 5. Enter `SSH_PRIVATE` as the name for the new environment variable.
 6. Paste the private half of the keypair into the **Value** field.
diff --git a/content/manuals/docker-hub/repos/manage/export.md b/content/manuals/docker-hub/repos/manage/export.md
new file mode 100644
index 000000000000..0dea2fe45dea
--- /dev/null
+++ b/content/manuals/docker-hub/repos/manage/export.md
@@ -0,0 +1,157 @@
+---
+title: Export organization repositories to CSV
+linkTitle: Export repositories
+description: Learn how to export a complete list of your organization's Docker Hub repositories using the API.
+keywords: docker hub, organization, repositories, export, csv, api, personal access token, pat
+---
+
+This guide shows you how to export a complete list of repositories from your
+Docker Hub organization, including private repositories. You'll use a
+Personal Access Token (PAT) from an administrator account to authenticate with
+the Docker Hub API and export repository details to a CSV file for reporting or
+analysis.
+
+The exported data includes repository name, visibility status, last updated
+date, pull count, and star count.
+
+## Prerequisites
+
+Before you begin, ensure you have:
+
+- Administrator access to a Docker Hub organization
+- `curl` installed for making API requests
+- `jq` installed for JSON parsing
+- A spreadsheet application to view the CSV
+
+## Create a personal access token
+
+[Create a personal access token](/security/access-tokens/) from
+a user account that has access to the organization's repositories. When creating
+the token, select at minimum **Read-only** access permissions to list
+repositories.
+
+> [!IMPORTANT]
+>
+> Use a PAT from a user account that is a member of the organization. Users
+> with owner roles can export all organization repositories. Members can only
+> export repositories they have permission to access.
+
+## Authenticate with the Docker Hub API
+
+Exchange your personal access token for a JWT bearer token that you'll use
+for subsequent API requests.
+
+1. Set your Docker Hub username, organization name, and personal access token as variables:
+
+   ```bash
+   USERNAME="<your-docker-username>"
+   ORG="<org-name>"
+   PAT="<your_personal_access_token>"
+   ```
+
+2. Call the authentication endpoint to get a JWT:
+
+   ```bash
+   TOKEN=$(
+     curl -s https://hub.docker.com/v2/auth/token \
+       -H 'Content-Type: application/json' \
+       -d "{\"identifier\":\"$USERNAME\",\"secret\":\"$PAT\"}" \
+     | jq -r '.access_token'
+   )
+   ```
+
+3. Verify the token was retrieved successfully:
+
+   ```console
+   $ echo "Got JWT: ${#TOKEN} chars"
+   ```
+
+You'll use this JWT as a Bearer token in the `Authorization` header for all
+subsequent API calls.
+
+## Retrieve all repositories
+
+The Docker Hub API paginates repository lists. This script retrieves all pages
+and combines the results.
+
+1. Set the page size and initial API endpoint:
+
+   ```bash
+   PAGE_SIZE=100
+   URL="https://hub.docker.com/v2/namespaces/$ORG/repositories?page_size=$PAGE_SIZE"
+   ```
+
+2. Paginate through all results:
+
+   ```bash
+   ALL=$(
+     while [ -n "$URL" ] && [ "$URL" != "null" ]; do
+       RESP=$(curl -s "$URL" -H "Authorization: Bearer $TOKEN")
+       echo "$RESP" | jq -c '.results[]'
+       URL=$(echo "$RESP" | jq -r '.next')
+     done | jq -s '.'
+   )
+   ```
+
+3. Verify the number of repositories retrieved:
+
+   ```console
+   $ echo "$ALL" | jq 'length'
+   ```
+
+The script continues requesting the `next` URL from each response until
+pagination is complete.
+
+## Export to CSV
+
+Generate a CSV file with repository details that you can open in
+spreadsheet applications.
+
+Run the following command to create `repos.csv`:
+
+```bash
+echo "$ALL" | jq -r '
+  (["namespace","name","is_private","last_updated","pull_count","star_count"] | @csv),
+  (.[] | [
+    .namespace, .name, .is_private, .last_updated, (.pull_count//0), (.star_count//0)
+  ] | @csv)
+' > repos.csv
+```
+
+Verify the export completed:
+
+```console
+$ echo "Rows:" $(wc -l < repos.csv)
+```
+
+Open the `repos.csv` file in your preferred
+spreadsheet application to view and analyze your repository data.
+
+## Troubleshooting
+
+### Only public repositories appear
+
+The Docker Hub account associated with your personal access token may not have
+access to private repositories in the organization.
+
+To fix this:
+
+1. Verify the account is a member of the organization
+2. Check that the account has appropriate permissions (owner or member role)
+3. Ensure the personal access token has sufficient access permissions
+4. Regenerate the JWT and retry the export
+
+### API returns 403 or missing fields
+
+Ensure you're using the JWT from the `/v2/auth/token` endpoint as a
+Bearer token in the `Authorization` header, not the personal access
+token directly.
+
+Verify your authentication:
+
+```console
+$ curl -s "https://hub.docker.com/v2/namespaces/$ORG/repositories?page_size=1" \
+  -H "Authorization: Bearer $TOKEN" | jq
+```
+
+If this returns an error, re-run the authentication step to get a fresh JWT.
diff --git a/content/manuals/docker-hub/repos/manage/hub-images/_index.md b/content/manuals/docker-hub/repos/manage/hub-images/_index.md
index 7d522bdc00ce..cf84f0389aa3 100644
--- a/content/manuals/docker-hub/repos/manage/hub-images/_index.md
+++ b/content/manuals/docker-hub/repos/manage/hub-images/_index.md
@@ -16,8 +16,8 @@ repositories, and supported software artifacts.
 - [Tags](./tags.md): Tags help you version and organize different iterations of
   your images within a single repository. This topic explains tagging and
   provides guidance on how to create, view, and delete tags in Docker Hub.
-- [Image Management](./manage.md): Manage your images and image indexes to
-  optimize your repository storage.
+- [Image Management](./manage.md): View, filter, and delete images and image
+  indexes in your repository.
 - [Software artifacts](./oci-artifacts.md): Docker Hub supports OCI (Open
   Container Initiative) artifacts, allowing you to store, manage, and distribute
   a range of content beyond standard Docker images, including Helm charts,
diff --git a/content/manuals/docker-hub/repos/manage/hub-images/bulk-migrate.md b/content/manuals/docker-hub/repos/manage/hub-images/bulk-migrate.md
new file mode 100644
index 000000000000..b2523ea78f78
--- /dev/null
+++ b/content/manuals/docker-hub/repos/manage/hub-images/bulk-migrate.md
@@ -0,0 +1,333 @@
+---
+title: Bulk migrate images
+description: Learn how to migrate multiple Docker images and tags between organizations using scripts and automation.
+keywords: docker hub, migration, bulk, images, tags, multi-arch
+---
+
+This guide shows you how to migrate Docker images in bulk between Docker Hub
+organizations or namespaces. Whether you're consolidating repositories, changing
+organization structure, or moving images to a new account, these techniques help
+you migrate efficiently while preserving image integrity.
+
+The topic is structured to build up in scale:
+
+1. [Migrate a single image tag](#migrate-a-single-image-tag)
+2. [Migrate all tags for a repository](#migrate-all-tags-for-a-repository)
+3. [Migrate multiple repositories](#migrate-multiple-repositories)
+
+The recommended tool for this workflow is `crane`. An equivalent alternative
+using `regctl` is also shown. Both tools perform registry-to-registry copies
+without pulling images locally and preserve multi-architecture images.
+
+`crane` is recommended for its simplicity and focused image-copying workflow.
+`regctl` is also a good choice, particularly if you already use it for broader
+registry management tasks beyond image copying.
+
+> [!NOTE]
+>
+> The main workflows in this topic operate on tagged images only. Untagged
+> manifests or content no longer reachable from tags are not migrated. In
+> practice, these are usually unused artifacts, but be aware of this limitation
+> before migration. While you can migrate specific untagged manifests using
+> [digest references](#migrate-by-digest), there is no API to enumerate untagged
+> manifests in a repository.
+
+## Prerequisites
+
+Before you begin, ensure you have:
+
+- One of the following installed and available in your `$PATH`:
+  - [`crane`](https://github.com/google/go-containerregistry)
+  - [`regctl`](https://regclient.org/usage/regctl/)
+- Push access to both the source and destination organizations
+- Registry authentication configured for your chosen tool
+
+## Authenticate to registries
+
+Both tools authenticate directly against registries:
+
+- `crane` uses Docker credential helpers and `~/.docker/config.json`. See the
+  [crane documentation](https://github.com/google/go-containerregistry/tree/main/cmd/crane/doc).
+- `regctl` uses its own configuration file and can import Docker credentials.
+  See the [regctl documentation](https://github.com/regclient/regclient/tree/main/docs).
+
+Follow the authentication instructions for your registry and tool of choice.
+
+## Migrate a single image tag
+
+This is the simplest and most common migration scenario.
+
+The following example script copies the image manifest directly between
+registries and preserves multi-architecture images when present. Repeat this
+process for each tag you want to migrate. Replace the environment variable
+values with your source and destination organization names, repository name, and
+tag.
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+SRC_ORG="oldorg"
+DEST_ORG="neworg"
+REPO="myapp"
+TAG="1.2.3"
+
+SRC_IMAGE="${SRC_ORG}/${REPO}:${TAG}"
+DEST_IMAGE="${DEST_ORG}/${REPO}:${TAG}"
+
+# Using crane (recommended)
+crane cp "${SRC_IMAGE}" "${DEST_IMAGE}"
+
+# Using regctl (alternative)
+# regctl image copy "${SRC_IMAGE}" "${DEST_IMAGE}"
+```
+
+### Migrate by digest
+
+To migrate a specific image by digest instead of tag, use the digest in the
+source reference. This is useful when you need to migrate an exact image
+version, even if the tag has been updated. Replace the environment variable
+values with your source and destination organization names, repository name,
+digest, and tag. You can choose between `crane` and `regctl` for the copy
+operation.
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+SRC_ORG="oldorg"
+DEST_ORG="neworg"
+REPO="myapp"
+DIGEST="sha256:abcd1234..."
+TAG="stable"
+
+SRC_IMAGE="${SRC_ORG}/${REPO}@${DIGEST}"
+DEST_IMAGE="${DEST_ORG}/${REPO}:${TAG}"
+
+# Using crane
+crane cp "${SRC_IMAGE}" "${DEST_IMAGE}"
+
+# Using regctl
+# regctl image copy "${SRC_IMAGE}" "${DEST_IMAGE}"
+```
+
+## Migrate all tags for a repository
+
+To migrate every tagged image in a repository, use the Docker Hub API to
+enumerate tags and copy each one. The following example script retrieves all
+tags for a given repository and migrates them in a loop. This approach scales to
+repositories with many tags without overwhelming local resources. Note that
+there is a rate limit on Docker Hub requests, so you may need to add delays or
+pagination handling for large repositories.
+
+Replace the environment variable values with your source and destination
+organization names and repository name. If your source repository is private,
+also set `HUB_USER` and `HUB_TOKEN` with credentials that have pull access. You
+can also choose between `crane` and `regctl` for the copy operation.
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Use environment variables if set, otherwise use defaults
+SRC_ORG="${SRC_ORG:-oldorg}"
+DEST_ORG="${DEST_ORG:-neworg}"
+REPO="${REPO:-myapp}"
+
+# Optional: for private repositories
+# HUB_USER="your-username"
+# HUB_TOKEN="your-access-token"
+# AUTH="-u ${HUB_USER}:${HUB_TOKEN}"
+AUTH=""
+
+TOOL="crane"   # or: TOOL="regctl"
+
+TAGS_URL="https://hub.docker.com/v2/repositories/${SRC_ORG}/${REPO}/tags?page_size=100"
+
+while [[ -n "${TAGS_URL}" && "${TAGS_URL}" != "null" ]]; do
+  RESP=$(curl -fsSL ${AUTH} "${TAGS_URL}")
+
+  echo "${RESP}" | jq -r '.results[].name' | while read -r TAG; do
+    [[ -z "${TAG}" ]] && continue
+
+    SRC_IMAGE="${SRC_ORG}/${REPO}:${TAG}"
+    DEST_IMAGE="${DEST_ORG}/${REPO}:${TAG}"
+
+    echo "Migrating ${SRC_IMAGE} → ${DEST_IMAGE}"
+
+    case "${TOOL}" in
+      crane)
+        crane cp "${SRC_IMAGE}" "${DEST_IMAGE}"
+        ;;
+      regctl)
+        regctl image copy "${SRC_IMAGE}" "${DEST_IMAGE}"
+        ;;
+    esac
+  done
+
+  TAGS_URL=$(echo "${RESP}" | jq -r '.next')
+done
+```
+
+> [!NOTE]
+>
+> Docker Hub automatically creates the destination repository on first push if
+> your account has permission.
+
+## Migrate multiple repositories
+
+To migrate several repositories, create a list and run the single-repository
+script for each one.
+
+For example, create a `repos.txt` file with repository names:
+
+```text
+api
+web
+worker
+```
+
+Save the script from the previous section as `migrate-single-repo.sh`. Then, run
+the following example script that processes each repository in the file. Replace
+the environment variable values with your source and destination organization
+names.
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+SRC_ORG="oldorg"
+DEST_ORG="neworg"
+
+while read -r REPO; do
+  [[ -z "${REPO}" ]] && continue
+  echo "==== Migrating repo: ${REPO}"
+  SRC_ORG="${SRC_ORG}" DEST_ORG="${DEST_ORG}" REPO="${REPO}" ./migrate-single-repo.sh
+done < repos.txt
+```
+
+## Verify migration integrity
+
+After copying, verify that source and destination match by comparing digests.
+
+### Basic digest verification
+
+The following example script retrieves the image digest for a specific tag from
+both source and destination and compares them. If the digests match, the
+migration is successful. Replace the environment variable values with your
+source and destination organization names, repository name, and tag. You can
+choose between `crane` and `regctl` for retrieving digests.
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+SRC_ORG="oldorg"
+DEST_ORG="neworg"
+REPO="myapp"
+TAG="1.2.3"
+
+SRC_IMAGE="${SRC_ORG}/${REPO}:${TAG}"
+DEST_IMAGE="${DEST_ORG}/${REPO}:${TAG}"
+
+# Using crane
+SRC_DIGEST=$(crane digest "${SRC_IMAGE}")
+DEST_DIGEST=$(crane digest "${DEST_IMAGE}")
+
+# Using regctl (alternative)
+# SRC_DIGEST=$(regctl image digest "${SRC_IMAGE}")
+# DEST_DIGEST=$(regctl image digest "${DEST_IMAGE}")
+
+echo "Source:      ${SRC_DIGEST}"
+echo "Destination: ${DEST_DIGEST}"
+
+if [[ "${SRC_DIGEST}" == "${DEST_DIGEST}" ]]; then
+  echo "✓ Migration verified: digests match"
+else
+  echo "✗ Migration failed: digests do not match"
+  exit 1
+fi
+```
+
+### Multi-arch verification
+
+For multi-architecture images, also verify the manifest list to ensure all
+platforms were copied correctly. Replace the environment variable values with
+your source and destination organization names, repository name, and tag. You
+can choose between `crane` and `regctl` for retrieving manifests.
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+SRC_ORG="oldorg"
+DEST_ORG="neworg"
+REPO="myapp"
+TAG="1.2.3"
+
+SRC_IMAGE="${SRC_ORG}/${REPO}:${TAG}"
+DEST_IMAGE="${DEST_ORG}/${REPO}:${TAG}"
+
+# Using crane
+SRC_MANIFEST=$(crane manifest "${SRC_IMAGE}")
+DEST_MANIFEST=$(crane manifest "${DEST_IMAGE}")
+
+# Using regctl (alternative)
+# SRC_MANIFEST=$(regctl image manifest --format raw-body "${SRC_IMAGE}")
+# DEST_MANIFEST=$(regctl image manifest --format raw-body "${DEST_IMAGE}")
+
+# Check if it's a manifest list (multi-arch)
+if echo "${SRC_MANIFEST}" | jq -e '.manifests' > /dev/null 2>&1; then
+  echo "Multi-arch image detected"
+  
+  # Compare platform list
+  SRC_PLATFORMS=$(echo "${SRC_MANIFEST}" | jq -r '.manifests[] | "\(.platform.os)/\(.platform.architecture)"' | sort)
+  DEST_PLATFORMS=$(echo "${DEST_MANIFEST}" | jq -r '.manifests[] | "\(.platform.os)/\(.platform.architecture)"' | sort)
+  
+  if [[ "${SRC_PLATFORMS}" == "${DEST_PLATFORMS}" ]]; then
+    echo "✓ Platform list matches:"
+    echo "${SRC_PLATFORMS}"
+  else
+    echo "✗ Platform lists do not match"
+    echo "Source platforms:"
+    echo "${SRC_PLATFORMS}"
+    echo "Destination platforms:"
+    echo "${DEST_PLATFORMS}"
+    exit 1
+  fi
+else
+  echo "Single-arch image"
+fi
+```
+
+## Complete the migration
+
+After migrating your images, complete these additional steps:
+
+1. Copy repository metadata in the Docker Hub UI or via API:
+
+   - README content
+   - Repository description
+   - Topics and tags
+
+2. Configure repository settings to match the source:
+
+   - Visibility (public or private)
+   - Team permissions and access controls
+
+3. Reconfigure integrations in the destination organization:
+
+   - Webhooks
+   - Automated builds
+   - Security scanners
+
+4. Update image references in your projects:
+
+   - Change `FROM oldorg/repo:tag` to `FROM neworg/repo:tag` in Dockerfiles
+   - Update deployment configurations
+   - Update documentation
+
+5. Deprecate the old location:
+   - Update the source repository description to point to the new location
+   - Consider adding a grace period before making the old repository private or
+     read-only
\ No newline at end of file
diff --git a/content/manuals/docker-hub/repos/manage/hub-images/immutable-tags.md b/content/manuals/docker-hub/repos/manage/hub-images/immutable-tags.md
new file mode 100644
index 000000000000..d01fee36c019
--- /dev/null
+++ b/content/manuals/docker-hub/repos/manage/hub-images/immutable-tags.md
@@ -0,0 +1,60 @@
+---
+description: Learn about immutable tags and how they help maintain image version consistency on Docker Hub.
+keywords: Docker Hub, Hub, repository content, tags, immutable tags, version control
+title: Immutable tags on Docker Hub
+linkTitle: Immutable tags
+weight: 11
+---
+{{< summary-bar feature_name="Immutable tags" >}}
+
+Immutable tags provide a way to ensure that specific image versions remain unchanged once they are published to Docker Hub. This feature helps maintain consistency and reliability in your container deployments by preventing accidental overwrites of important image versions.
+
+## What are immutable tags?
+
+Immutable tags are image tags that, once pushed to Docker Hub, cannot be overwritten or deleted. This ensures that a specific version of an image remains exactly the same throughout its lifecycle, providing:
+
+- Version consistency
+- Reproducible builds
+- Protection against accidental overwrites
+- Better security and compliance
+
+## Enable immutable tags
+
+To enable immutable tags for your repository:
+
+1. Sign in to [Docker Hub](https://hub.docker.com).
+2. Select **My Hub** > **Repositories**.
+3. Select the repository where you want to enable immutable tags.
+4. Go to **Settings** > **General**.
+5. Under **Tag mutability settings**, select one of the following options:
+   - **All tags are mutable (Default)**:  
+     Tags can be changed to reference a different image. This lets you retarget a tag without creating a new one.
+   - **All tags are immutable**:  
+     Tags cannot be updated to point to a different image after creation. This ensures consistency and prevents accidental changes. This includes the `latest` tag.
+   - **Specific tags are immutable**:  
+     Define specific tags that cannot be updated after creation using regex values.
+6. Select **Save**.
+
+Once enabled, all tags are locked to their specific images, ensuring that each tag always points to the same image version and cannot be modified.
+
+> [!NOTE]
+> This implementation of regular expressions follows the [Go regexp package](https://pkg.go.dev/regexp), which is based on the RE2 engine. For more information, visit [RE2 Regular Expression Syntax](https://github.com/google/re2/wiki/Syntax).
+
+## Working with immutable tags
+
+When immutable tags are enabled:
+
+- You cannot push a new image with the same tag name
+- You must use a new tag name for each new image version
+
+To push an image, create a new tag for your updated image and push it to the repository.
+
+
+
+
+
+
+
+
+
+
diff --git a/content/manuals/docker-hub/repos/manage/hub-images/manage.md b/content/manuals/docker-hub/repos/manage/hub-images/manage.md
index 7af6b2f21d90..b0744339dcf3 100644
--- a/content/manuals/docker-hub/repos/manage/hub-images/manage.md
+++ b/content/manuals/docker-hub/repos/manage/hub-images/manage.md
@@ -26,6 +26,10 @@ The following objects are shown in the diagram.
 
 ## Manage repository images and image indexes
 
+Use the following steps to delete one or more items via the graphical user
+interface. To delete in bulk, see the [deletion API
+endpoint](/reference/api/registry/latest/#tag/delete).
+
 1. Sign in to [Docker Hub](https://hub.docker.com).
 2. Select **My Hub** > **Repositories**.
 3. In the list, select a repository.
@@ -49,4 +53,11 @@ The following objects are shown in the diagram.
    2. Select **Preview and delete**.
    3. In the window that appears, verify the items that will be deleted and the
       amount of storage you will reclaim.
-   4. Select **Delete forever**.
\ No newline at end of file
+   4. Select **Delete forever**.
+
+   > [!NOTE]
+   >
+   > Deletion operations may take some time to complete. Timeout errors may
+   > occur during the deletion process. The system automatically retries the
+   > deletion in the background, and the items will be removed without requiring
+   > any action from you.
\ No newline at end of file
diff --git a/content/manuals/docker-hub/repos/manage/hub-images/move.md b/content/manuals/docker-hub/repos/manage/hub-images/move.md
index aa1ebd6273ba..aaebb824ad56 100644
--- a/content/manuals/docker-hub/repos/manage/hub-images/move.md
+++ b/content/manuals/docker-hub/repos/manage/hub-images/move.md
@@ -12,11 +12,16 @@ contributing to an organization. This topic explains how to move images between
 Docker Hub repositories, ensuring that your content remains accessible and
 organized under the correct accounts or namespaces.
 
+> [!NOTE]
+>
+> For bulk migrations, multi-arch images, or scripted workflows, see [Bulk
+> migrate Docker images](/manuals/docker-hub/repos/manage/hub-images/bulk-migrate.md).
+
 ## Personal to personal
 
 When consolidating personal repositories, you can pull private images from the initial repository and push them into another repository owned by you. To avoid losing your private images, perform the following steps:
 
-1. [Sign up](https://app.docker.com/signup) for a new Docker account with a personal subscription.
+1. [Sign up](https://app.docker.com/signup) for a new Docker account with a personal subscription. (Be sure to verify your account after you've signed up.)
 2. Sign in to [Docker](https://app.docker.com/login) using your original Docker account
 3. Pull your images:
 
@@ -29,6 +34,7 @@ When consolidating personal repositories, you can pull private images from the i
    ```console
    $ docker tag namespace1/docker101tutorial new_namespace/docker101tutorial
    ```
+
 5. Using `docker login` from the CLI, sign in with your newly created Docker account, and push your newly tagged private images to your new Docker account namespace:
 
    ```console
@@ -49,15 +55,17 @@ personal account and push them to an organization that's owned by you.
    ```console
    $ docker pull namespace1/docker101tutorial
    ```
+
 4. Tag your images with your new organization namespace:
 
    ```console
    $ docker tag namespace1/docker101tutorial <new_org>/docker101tutorial
    ```
+
 5. Push your newly tagged images to your new org namespace:
 
    ```console
    $ docker push new_org/docker101tutorial
    ```
 
-The private images that existed in your user account are now available for your organization.
\ No newline at end of file
+The private images that existed in your user account are now available for your organization.
diff --git a/content/manuals/docker-hub/repos/manage/hub-images/oci-artifacts.md b/content/manuals/docker-hub/repos/manage/hub-images/oci-artifacts.md
index bb7b786cf204..d8cd90ef6859 100644
--- a/content/manuals/docker-hub/repos/manage/hub-images/oci-artifacts.md
+++ b/content/manuals/docker-hub/repos/manage/hub-images/oci-artifacts.md
@@ -78,23 +78,24 @@ Steps:
 
    ```console
    $ helm package demo
-   Successfully packaged chart and saved it to: /Users/hubuser/demo-0.1.0.tgz
+   Successfully packaged chart and saved it to: demo-0.1.0.tgz
    ```
 
 3. Sign in to Docker Hub with Helm, using your Docker credentials.
 
    ```console
-   $ helm registry login registry-1.docker.io -u hubuser
+   $ helm registry login registry-1.docker.io -u <YOUR_DOCKER_USERNAME>
    ```
 
 4. Push the chart to a Docker Hub repository.
 
    ```console
-   $ helm push demo-0.1.0.tgz oci://registry-1.docker.io/docker
+   $ helm push demo-0.1.0.tgz oci://registry-1.docker.io/<YOUR_DOCKER_USERNAME>
    ```
 
-   This uploads the Helm chart tarball to a `demo` repository in the `docker`
-   namespace.
+   This uploads the Helm chart tarball to a `demo` repository in the `<YOUR_DOCKER_USERNAME>`
+   namespace. Running this command creates a `<YOUR_DOCKER_USERNAME>/demo` repository
+   if one does not already exist.
 
 5. Go to the repository page on Docker Hub. The **Tags** section of the page
    shows the Helm chart tag.
@@ -127,18 +128,18 @@ Steps:
 2. Sign in to Docker Hub using the ORAS CLI.
 
    ```console
-   $ oras login -u hubuser registry-1.docker.io
+   $ oras login -u <YOUR_DOCKER_USERNAME> registry-1.docker.io
    ```
 
 3. Push the file to Docker Hub.
 
    ```console
-   $ oras push registry-1.docker.io/docker/demo:0.0.1 \
+   $ oras push registry-1.docker.io/<YOUR_DOCKER_USERNAME>/demo:0.0.1 \
      --artifact-type=application/vnd.docker.volume.v1+tar.gz \
      myvolume.txt:text/plain
    ```
 
-   This uploads the volume to a `demo` repository in the `docker` namespace. The
+   This uploads the volume to a `demo` repository in the `<YOUR_DOCKER_USERNAME>` namespace. The
    `--artifact-type` flag specifies a special media type that makes Docker Hub
    recognize the artifact as a container volume.
 
@@ -166,13 +167,13 @@ Steps:
 2. Sign in to Docker Hub using the ORAS CLI.
 
    ```console
-   $ oras login -u hubuser registry-1.docker.io
+   $ oras login -u <YOUR_DOCKER_USERNAME> registry-1.docker.io
    ```
 
 3. Push the file to Docker Hub.
 
    ```console
-   $ oras push registry-1.docker.io/docker/demo:0.0.1 myartifact.txt:text/plain
+   $ oras push registry-1.docker.io/<YOUR_DOCKER_USERNAME>/demo:0.0.1 myartifact.txt:text/plain
    ```
 
 4. Go to the repository page on Docker Hub. The **Tags** section on that page
diff --git a/content/manuals/docker-hub/repos/manage/hub-images/push.md b/content/manuals/docker-hub/repos/manage/hub-images/push.md
index a9a1f0284529..bae15d2f735e 100644
--- a/content/manuals/docker-hub/repos/manage/hub-images/push.md
+++ b/content/manuals/docker-hub/repos/manage/hub-images/push.md
@@ -42,3 +42,7 @@ images with others or use them in different environments.
    This command pushes the image tagged `v1.0` to the `my-namespace/my-repo` repository.
 
 3. Verify the image on Docker Hub.
+
+   Sign in to [Docker Hub](https://hub.docker.com) and navigate to your
+   repository (`my-namespace/my-repo` in this example). Select the **Tags**
+   tab to confirm that your tag (`v1.0` in this example) appears in the list.
diff --git a/content/manuals/docker-hub/repos/manage/trusted-content/_index.md b/content/manuals/docker-hub/repos/manage/trusted-content/_index.md
index 0ae04840e94a..4a00bc2931a4 100644
--- a/content/manuals/docker-hub/repos/manage/trusted-content/_index.md
+++ b/content/manuals/docker-hub/repos/manage/trusted-content/_index.md
@@ -29,4 +29,8 @@ In this section, learn about:
   through vulnerability analysis.
 - [Insights and analytics](./insights-analytics.md): Access detailed metrics on
   image and extension usage, including pull counts, geolocation, and client
-  data, to understand user behavior and optimize your content.
\ No newline at end of file
+  data, to understand user behavior and optimize your content.
+
+For Docker Hardened Images guidance, including how to contribute, see
+[Contribute to the catalog](/dhi/how-to/build/#contribute-to-the-catalog) in the
+dedicated DHI docs section.
diff --git a/content/manuals/docker-hub/repos/manage/trusted-content/dsos-program.md b/content/manuals/docker-hub/repos/manage/trusted-content/dsos-program.md
index ee404d7db33c..9b68d9b785e9 100644
--- a/content/manuals/docker-hub/repos/manage/trusted-content/dsos-program.md
+++ b/content/manuals/docker-hub/repos/manage/trusted-content/dsos-program.md
@@ -7,7 +7,7 @@ aliases:
   - /trusted-content/dsos-program/
 ---
 
-[Docker-Sponsored Open Source images](https://hub.docker.com/search?q=&image_filter=open_source) are published and maintained by open-source projects sponsored by Docker through the program.
+[Docker-Sponsored Open Source images](https://hub.docker.com/search?badges=open_source) are published and maintained by open-source projects sponsored by Docker through the program.
 
 Images that are part of this program have a special badge on Docker Hub making it easier for users to identify projects that Docker has verified as trusted, secure, and active open-source projects.
 
@@ -31,8 +31,7 @@ These benefits are valid for one year and publishers can renew annually if the p
 DSOS organizations can upload custom images for individual repositories on Docker Hub.
 This lets you override the default organization-level logo on a per-repository basis.
 
-Only a user with administrative access (owner or team member with administrator permission)
-over the repository can change the repository logo.
+Only a user with an owner or editor role for the organization can change the repository logo.
 
 #### Image requirements
 
diff --git a/content/manuals/docker-hub/repos/manage/trusted-content/dvp-program.md b/content/manuals/docker-hub/repos/manage/trusted-content/dvp-program.md
index 39f75d10d30d..b7e2e89eab83 100644
--- a/content/manuals/docker-hub/repos/manage/trusted-content/dvp-program.md
+++ b/content/manuals/docker-hub/repos/manage/trusted-content/dvp-program.md
@@ -14,44 +14,138 @@ aliases:
 - /docker-hub/publish/repository-logos/
 - /docker-hub/dvp-program/
 - /trusted-content/dvp-program/
+toc_max: 2
 ---
 
-[The Docker Verified Publisher Program](https://hub.docker.com/search?q=&image_filter=store) provides high-quality images from commercial publishers verified by Docker.
+[The Docker Verified Publisher
+Program](https://hub.docker.com/search?badges=verified_publisher) is a paid
+subscription program that provides high-quality images from commercial
+publishers verified by Docker.
 
-These images help development teams build secure software supply chains, minimizing exposure to malicious content early in the process to save time and money later.
+These images help development teams build secure software supply chains,
+minimizing exposure to malicious content early in the process to save time and
+money later.
 
-Images that are part of this program have a special badge on Docker Hub making it easier for users to identify projects that Docker has verified as high-quality commercial publishers.
+## Who's eligible to become a verified publisher?
 
-![Docker-Sponsored Open Source badge](../../../images/verified-publisher-badge-iso.png)
+Any independent software vendor who distributes software on Docker Hub can join
+the Verified Publisher Program. To apply, see the [Verified Publisher Program
+application](https://hub.docker.com/publisher-program/apply).
+
+> [!NOTE]
+>
+> DVP entitlements are applied per namespace (organization). If you operate
+> multiple Docker Hub namespaces, each requires a separate DVP application and
+> verification process.
+
+## Program benefits
+
+The Docker Verified Publisher Program (DVP) provides several features and
+benefits to Docker Hub publishers. The program grants the following perks based
+on participation tier:
+
+- [Enterprise-grade infrastructure](#enterprise-grade-infrastructure): High
+  availability hosting with 99.9% uptime
+- [Verified publisher badge](#verified-publisher-badge): Special badge
+  identifying high-quality commercial publishers
+- [Repository logo](#repository-logo): Upload custom logos for individual
+  repositories
+- [Insights and analytics](#insights-and-analytics): Detailed usage metrics and
+  community engagement data
+- [Vulnerability analysis](#vulnerability-analysis): Automated security scanning
+  with Docker Scout
+- [Priority search ranking](#priority-search-ranking): Enhanced discoverability
+  in Docker Hub search results
+
+### Enterprise-grade infrastructure
+
+The Docker Verified Publisher Program runs on Docker Hub's enterprise-scale
+infrastructure, serving millions of developers globally. Your published content
+benefits from:
+
+- High availability and uptime: Docker's systems are designed for failover
+  across multiple availability zones, with load-balanced autoscaling, enabling
+  99.9% uptime.
+- Global delivery and fast downloads: Docker leverages a global CDN and caching
+  infrastructure to achieve cache hit ratios more than 99%, reducing reliance
+  on origin traffic and ensuring fast access for developers everywhere.
+- Durability: Docker maintains a documented backup policy and performs full
+  daily backups of production data.
+
+You simply push your images to Docker Hub as usual, and Docker takes care of the
+rest, serving your image to millions of developers worldwide.
+
+![DVP flow in Docker Hub](./images/dvp-hub-flow.svg)
+
+To learn more, see [Availability at
+Docker](https://www.docker.com/trust/availability/).
+
+### Verified publisher badge
 
-The Docker Verified Publisher Program (DVP) provides several features and benefits to Docker
-Hub publishers. The program grants the following perks based on participation tier:
+Images that are part of this program have a special badge on Docker Hub making
+it easier for users to identify projects that Docker has verified as
+high-quality commercial publishers.
 
-- Repository logo
-- Verified publisher badge
-- Priority search ranking in Docker Hub
-- Insights and analytics
-- Vulnerability analysis
-- Additional Docker Business seats
-- Removal of rate limiting for developers
-- Co-marketing opportunities
+![Docker-Sponsored Open Source
+badge](../../../images/verified-publisher-badge.png)
 
 ### Repository logo
 
-DVP organizations can upload custom images for individual repositories on Docker Hub.
-This lets you override the default organization-level logo on a per-repository basis.
+DVP organizations can upload custom images for individual repositories on Docker
+Hub. This lets you override the default organization-level logo on a
+per-repository basis.
+
+To manage the repository logo, see [Manage repository logo](#manage-repository-logo).
+
+### Vulnerability analysis
+
+[Docker Scout](/scout/) provides automatic vulnerability analysis
+for DVP images published to Docker Hub.
+Scanning images ensures that the published content is secure, and proves to
+developers that they can trust the image.
+
+You can enable analysis on a per-repository basis. For more about using this
+feature, see [Basic vulnerability
+scanning](/docker-hub/repos/manage/vulnerability-scanning/).
+
+### Priority search ranking
+
+Verified publisher images receive enhanced visibility in Docker Hub search
+results, making it easier for developers to discover your content. This improved
+discoverability helps drive adoption of your images within the developer
+community.
+
+### Insights and analytics
+
+The insights and analytics service provides usage metrics for how
+the community uses Docker images, granting insight into user behavior.
+
+There is both a [web interface](./insights-analytics.md) and an
+[API](/reference/api/dvp/latest/) for accessing the analytics data.
+
+The usage metrics show the number of image pulls by tag or by digest,
+geolocation, cloud provider, client, and more.
+
+## Support
+
+The program doesn't change support for your organization. Support follows your
+organization's Docker subscription, or your program tier if you don't have a paid
+Docker subscription. For details, see [support response
+times](/manuals/support/_index.md#support-response-times).
 
-Only a user with administrative access (owner or team member with administrator permission)
-over the repository can change the repository logo.
+## Manage repository logo
 
-#### Image requirements
+After joining the Docker Verified Publisher Program, you can set a custom logo
+for each repository in your organization. The following requirements apply:
 
 - The supported filetypes for the logo image are JPEG and PNG.
 - The minimum allowed image size in pixels is 120×120.
 - The maximum allowed image size in pixels is 1000×1000.
 - The maximum allowed image file size is 5MB.
 
-#### Set the repository logo
+Only a user with an owner or editor role for the organization can change the repository logo.
+
+### Set the repository logo
 
 1. Sign in to [Docker Hub](https://hub.docker.com).
 2. Go to the page of the repository that you want to change the logo for.
@@ -61,44 +155,12 @@ current repository logo.
 4. In the dialog that opens, select the PNG image that you want to upload to
    set it as the logo for the repository.
 
-#### Remove the logo
+### Remove the logo
 
 Select the **Clear** button ({{< inline-image src="../../../images/clear_logo_sm.png"
 alt="clear button" >}}) to remove a logo.
 
-Removing the logo makes the repository default to using the organization logo, if set, or the following default logo if not.
+Removing the logo makes the repository default to using the organization logo,
+if set, or the following default logo if not.
 
 ![Default logo which is a 3D grey cube](../../../images/default_logo_sm.png)
-
-### Verified publisher badge
-
-Images that are part of this program have a badge on Docker Hub making it easier for developers
-to identify projects that Docker has verified as high quality publishers and with content they can trust.
-
-![Docker, Inc. org with a verified publisher badge](../../../images/verified-publisher-badge.png)
-
-### Insights and analytics
-
-The [insights and analytics](./insights-analytics.md) service provides usage metrics for how
-the community uses Docker images, granting insight into user behavior.
-
-The usage metrics show the number of image pulls by tag or by digest, and breakdowns by
-geolocation, cloud provider, client, and more.
-
-You can select the time span for which you want to view analytics data. You can also export the data in either a summary or raw format.
-
-### Vulnerability analysis
-
-[Docker Scout](/scout/) provides automatic vulnerability analysis
-for DVP images published to Docker Hub.
-Scanning images ensures that the published content is secure, and proves to
-developers that they can trust the image.
-
-You can enable analysis on a per-repository
-basis. For more about using this feature, see [Basic vulnerability scanning](/docker-hub/repos/manage/vulnerability-scanning/).
-
-### Who's eligible to become a verified publisher?
-
-Any independent software vendor who distributes software on Docker Hub can join
-the Verified Publisher Program. Find out more by heading to the
-[Docker Verified Publisher Program](https://www.docker.com/partners/programs) page.
diff --git a/content/manuals/docker-hub/repos/manage/trusted-content/images/dvp-hub-flow.svg b/content/manuals/docker-hub/repos/manage/trusted-content/images/dvp-hub-flow.svg
new file mode 100644
index 000000000000..d3c73a7b93ce
--- /dev/null
+++ b/content/manuals/docker-hub/repos/manage/trusted-content/images/dvp-hub-flow.svg
@@ -0,0 +1,5 @@
+<?xml version="1.0" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg version="1.1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 2120 320" width="2120" height="320"><!-- svg-source:excalidraw --><metadata></metadata><defs><style class="style-fonts">
+      @font-face { font-family: Nunito; src: url(data:font/woff2;base64,d09GMgABAAAAAA5MAA8AAAAAHXAAAA3uAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGhwbiSwcgiYGYD9TVEFURACBLhEICqJcmwcLWgABNgIkA4EwBCAFhCQHIBs8GKOilLPGTvbXB9oRyu8KU+iAwnFBapLQGF1vnLKkON1dmbhiPUWHR2h+ZVryDe3RuOxn0x9Kxc8jJJmF5981+/uSzLSbaXkJpv0ACHKPR/ktKwaLCkETZYi29T94d3wPDGp3YC1KrMUGA5RdjGSxCKOIMog6LyL1qtWLyOd/GVkA/4jRmfaAcPo8cG0DCBAAGjoXTmUGpzLxAWV/0qKrEQwAeFv9tg8lMZRIS6JNxL/rcu//1lI7fzdbBh+SJEwBhakwFaouMzt3nZ/JhvaabAhgr7R3LSsgUJElQCHRodGVNaZa1/XVqmoMrkN6Iy4s6jSAvQgDnkIyy6Hxua/7HQcBYgCAQiGkCVkhQQBLW73p4SPHT4f3jW1dD+8Nbt8IjwFwDwFk3YqtG4kFBBAMiijKNMei9Hhmg755LqCMbZBrGlbmZvZ/8wqS7oAr+LNyG4i5x/SGGe4Ocb4Zbv9opZtXiYPTP2Phej9RwFhMmHeBziScVtFp0Osf7h7GEogxMrchoeW67U6QN7XbFqtx3VwFXN7PGA5cqBqNjuCttobw0q5wVg+XEJG5nPnrAbQ3zvKXHVPpFYlQ7Dgp7uMYOl69enxtGJlfwk8m5+ACuHIG8JlyBXdMZ9y/XwYGDPMd55VY1liQTIxALGSoZDsCjBjZ0JCqXYjvgXHwuIweiq2NVM3BWA1VptD4sCYxqhjE1ZyDDjWsedeLXtAXQUZjtB7igsr+FGZ1qpwqrZlmarTUZq3u2pZG7SAIimMQMMPBgCflVDeKxSfiq8jUB0L4tAKSJJC0NhKp1MGQQqk6fBRJlAzwUUsyAnwBFTlGAXEgCnDs86QVsxQRihn64UgZjmuJEreNk5ZVrcYkWYkXE6jEDaeHtoWgCEiBf0yNHGmhimv4nVaS6VPHhSy4hwEEhf74UjQrHnL5xk0byP83GY2RPe+y9byCb9pWMEjKCWDmM5M5xqWj1DlquwHLhTIyrW4sitB3Dx9Q5Fk0AhhtUWQEUeZZUKplVF82C53NkdJ8d1XHbbVaIQH7oxaV828mzaie8gseqFplBjDuciSykOSI2U4rsFftfmAeENpzX/4fgukheIjUA8i7PgShAUxYmQIKT6R5m12rVm8X4C+Ipoiq0rQ6lJIcAKHp4slqBGVpED2RtJZN6Gkhc3mwljrpY7haDSgtTOzcfKLG5sChLXSAYWp9ZKNBTkMCN+oBuDT27jtvvP7Sk08cvsBpAlQLbeu21UZrLccgQ9zzEQft7xRmA/SGdwwiHlAISunko+CUmx91WN49oCu1VXTIwL8qjYe0SSNlJgkThNy5gqyStISs69FxPEGaEJcgwcqknAQ+VkqRXCrISc5gieMqpQmlCYkJ2zBxg+vpNVnGrirYsJRNqLtPHEdvEWM9XuHl1X0xU+2yJ+VYvDtgrg9o3rKQOWKBoQnWCKK4gSwjBsPAHhLf4Bd6jBi4JsUs3VCTbvysABNaQt1yerGzwq424rZzWuY5qCcIbBJYDAZIRfeBB2QwFOZp0qeZQjDZd2hfLXsP39Xg1ab2NYXRkF7bb7vG83uQwsCApYEG8TfNmYCxHnf8hTXeM0JbtvtvVTru7N27D962UvqrKH81Ye7fvLJkJlUMQambnibjWBtGEs4MLOJ0eqWajPc5dUq43LGU+5xzYCLpBBpRXomIYbW1i+Awoh6ZLz4h3aLFS4F8LtYH1Zhyo1X5Tm3fvmnkJqsejcY8DEZf+bKgATza5i5FlwAfg3a+l62Qopf9mAAGq5rVQx9/ijJemDacVKZp14jVXsrrEMOEMtKpmNEOMw6JreTIcJd4XFU6bgUmmBT+RaqoO28FW6fFQZW3jQ6f5os1k4BkMBcz+x2xmAmWeqaGmiaMFqZdvmCPJ5XWGRl8FAJ2NX7Tlg1K490xNLImBrnVeYBnhYGHLpmHxrCpEdAag3VTGRbYqJ/LHKPwxisnkSe/jnYX+BxKvICFYXY1LZQ8QaftXjqpe3jmhaDX9pqG0AuoMGKCZlvZC00MkdHTYJlnnJ5pPHbF3e0bMJda5SGetQk32UyU6TNZs2jI7ukGNbB3LSmxNmTVbALPxnFrarAYDtW7k0fBWxOrqhzpiI903Gf9FOnvs2HSMFHGbcWd3Liceb6fiv+ILCcFZ680JxnsvvL1tA+HisN4pTU2J3NRY/BgKoTT8I09Mm88Llj96z9a07wrl95+n/fl1nFraq8cZE+0Td5xGZ8WyrS4frZzzpp5t+tj10zwLUeFdvlKrs+vLCzQq0dFi//a5xJe+Cu7jZ+n8xDK+Z1m5UIPocvrEJT/dSTVNfbmcp8YrCndw++9PZOHZ29dOW3IW9FtXplrmqC2VltF2iqRo2bd6jWrt4JVPtzDt/Ucxckr5HCLeOpvMg+CHa6Km8kpBMt9dB708qMojPKZu5nvPhDN9sJ5KB8WIrsR6ALRG7+MJXSeEwlCE4eddG66QCBEHQhiRMNIHZvVfG6qAIoQU/ujuOEa9LvAfK/dcTtL4MG30IU6r1BUbXU15f4proBuOrJ9RYIn4BllIaSfZpQAo7+Vx9I3DiZ6gsuBKl4w/ObIam8St9X2hE76bFOoncOtsj/ZKHxKZ23jwf7I26O2IA8Jhh/JQ2fyQ1bwcWxhSwZela3sXYIN55XLdeb4wrSMwXzZeGpWUPVLmaiG3fZZxyP0yVeuGjkysj0zq0MbC00Izwnr5oauEsmgLlbbS/5+zgydKBKFARhB0AgUMX/tJUhyQF3so3SKQL/aUJdDZEn0KrOuW4sTmeLb2+8BSRqHKssCVLmwu4Iwi0olOiR2uqPmu8HH/Xp++pphLpFj0A808CuXPd72XbF96vcmBMQgBtSKgI4q9rnzkmQv8SszBx0oGoEBGOV/su4jn/eROXU4kSUWRXJAQqj3O4vep67w6ZrVfo+mpoASLko2l7KEHGO5Jr44tX4Sz6/CJS0Kepehu1WoTfwkXfpf8a436F18ILnSBtc+vrLmg+qpG3q2tK62vnZ47uuAJLSDasVwfUmqebNeXEj2k6+fNcMIikTgXn/AH2XJiUxxc7Fe11WlPUmaFBTVDcJ0kn6hKfH1fWUVqqbsdANJh04UjUIamVRCNFNV3+SB8GxkDG7hz0PQefwt0I32JH3Dx75KSnkK4z/zhn3Il7I+Zgb7bgmXW5jy7vNPyj966914LZu35YeX+ZhbeeDD2CadueO3Vuf/vvho5twXwOEDCHe2eCkLRBFg90tDHNBwRNahUlU2lT+dgPZoKktqsyUdWjqMImgUxhC3i8u0VM1XEs9+pty9t6ftnG4kayLa80L17ooyv65c2FNBGsXKAviU3kUr3FcrfAuJojq5L+yA3Ud+6yW1ZL9a4aN0xYGpQMi9/kWjU39ONYyKW6o/h47xt6lCO+uH/FkxSpJF0mvrNF9BJ/hBhy7e2NRK6fvaa/Z6trQkKkqmnD2cdyuJInm+1iQpwyn0t2u26nfbHpt5kKp0izFaSQ+HiCfVxdUeCnCoqCyZvvw3glPIYhdwiBEYQVEHHBnjFrBZhdyx70peV3B3MpY+y01YPXM5An7rljnjrs/f9vRKTKlu1Gu/fX6qu/Nw1AlND8rMakCLe3ni5IYB1SCPrVmxf3ny4eVBPZctUi05tXHVDPi1FeZSeHyjpbufczbbmiX8DcsGB9gcH7luGbxa1j5WKR7vR81tM1zuTGjzmlz5gdBlcOMii8C9VXtkd65jkkNq/1//37XjFPhThwFR/7TLCPxvYjVQojFVyhf2dDKMipaOHEVlX5nSRlaVOe3lWkOopWLvSI9sQ2O/p0DSmU3IJFW4XKIl0rNzfpVq5bi06jdwWKdc0DyhvFw3hS/gKtVUY8r/6iU/J6vq6sqzdKQkR2/w2GpzbK3FstelT8pkT0olJzPST4IG2sK64u9KFi7ZvbCu+nvZQhCahbExLA1L/h7DPgQvUDn87LDm63d0aqgKaYD9E5aBxepgvZ9oY7HsiUCkzoErW0pEAq1XOfsRT9acnZdT25KhrO/UVaU/T1Ysp197ivd6U0KNTFzI4Sq4BYg5raky1uJ+l9nKYanuNLTA7ZFSTUOpAY/DXvqo4OWxhFahokHVV52dn8n7P+MF8E7PfL7sbVC4Ra6OD+DIol2LOl9XUbLo+cWtXX5HdWZ/c6Gypdtv92TgrAoidSuiLWoqaMRTDqPawmwDNCba2nyWoEtwmy+4IcBOCASn6uK3JAN82v2AHiEPKYeUFGDo/jjRB8KgYlJ3CKCbqnK3MGJRsv83Wn8CPC2ZfALwoutkDweFww0L8FEACPymxcmAQCy0b8/VPr/Qtcfo16/NaKsb+dsnft++hwPWWeKLZyG9CN3bREMeaP+iAihQodWM8S39dX/I0PxtlQ6MuQU0sfPamfZ9cINe3Vsd4nB/24NR9Sm9ZiSdo61qpiALEfo/OWcWEA/4TJ+I3ZDjDO4VBtwkPeBkArQ33xzWmm0KL14qoJZGTAFwzM9HkNDZ/SBFgotBmuEiTgMHeZSbH+jTUccGAjHyPohWDJ5mX1UOC0zlNWLQKB07G7ewEQ1CBg1zs/62r+nkEkKBoaPcZ/aqMU9IwKDm1FeOkGJkZwzyj3qNEuqmo54663oL289EepSaBYkMbehkHMa+gX6LFqbjC3uu4uUzJgAdq6vOuuguND0DuxdEnDxY18vDzpriEIChIek1MFWoNQb16Ivqluukk1X92rqEWeRaRjNjoPdS12mYnYMWDA1j3quboLwsmu3MHKoSAAAA); }
+      @font-face { font-family: Comic Shanns; src: url(data:font/woff2;base64,d09GMgABAAAAAAnUAAsAAAAAFAgAAAmJAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAABmAAdBEICo4IjAoLGAABNgIkAxoEIAWVGAcgGzESMwPCxgFAkg0m+y8S4inLlZdIJClprQCFQr9tSxOM+R6JN/hHc+OhZwz37+ZS52n+ultIC21EskklkQpZS1FPeIP7CTf9d0mANkG1Tc0YpeoUOnO7/O+weetTESAzkdWp3cZCkDUcBfD33ZwXAL6p86+rl0nt1I84Ms+G51Qh5Sy75FNrrzabpOA+CVP0iZCtqtIdH3gH253Xnf0FfAmr+1tAVb4rkDAkUaFQwA5ZN8Z2PAkpO77+9DWT3bkjK+cS5KPcE6XInR/ffQUNGYlmEIC8k20AHFzcTpwBRDdcLRvw74tfCvKxRuarEsIJanomA7i7qfEo3Y1R6P4JNACDSKhrUbp8jhyJwirm1F1P/Q02zMgqkFmi29+h3ta+2l2LamHNqZqqqgpIr6jSFB2dGT6wC+QNkD/ocMg8N5k0br9LRKn7JWkdqZIGJk2jkq5u2u04ZtzaSsShOlTHGTl/q3nLjvNNdasZj++qDth753a+8cKQnT7Gs38zj8ih9qmpC3BnPAewD3g+jatF25um+cFD82tqKgC3qAYcUgOY9QKG6vBy2i3/K6oW8zxacsTrpXE5LAAMPstrj67jWvP/8zljLVdXh/a102MM2Lxh+15uf2z1EjXvEa04DvF8MLdap3dXDKt5ZqvvomUutNrwnuFLorGXXXmS8RQdHnHG2nW7elcAVpery2m3dlk61L3Yjj1eFgM21KzdmeJhPFHLdfOjqoahuQ9gffmeE8lbOvQ2/6EgPxx/NdxOdl+TviOz0d/KP61O2jzc6eTevYaK6uoV6hXeq+nwuQdLZOLu1brVUVjOMH9QO/eOPRvMVcd5Pm7dru6Vh/x+44o9ajWNAS/0p1vdVQnfC57zI+6YK6fXZnfzl/frVjMcU6GpwNHl3uyVPt9BqNk+3XKb339ovdydfSFzAau9TS4Yd2tPuqne5ta729Z9Zy/obYEBJ6xtX66u2386bTvjYSrmzoX3Y031krFTqa1F3PUKLa99Zk3G6bl7arDPgAG/TbHKWLsoiN4SxofV7X7HO93RCucOLx+5a9864zw/4oLrEHfgz2SuBgzYZ5m7kvHwcXVcEOc37ja6eTU+gw9Wrvgg/wGZZqGw48R9tOL0SnVfSJJULGVjUonJKB+Z1DKVhN7ep51mqGo/ektNtKlViqOh9UlXlE+bjENaSJJMmz/KC4Nb54xoV79f/H5mLFT2V5WFRyBXVDP4S51IE7TAokUBiN7eRyDF1WsmKyoVh9qNEktmJFFoFdNq+lsfIlSfVRZL1If2i+yXUtopMlE0FZmoUqACusZ83UEzBFyKd+wH+T2BISKVdK///U8+gy+CADL3N5FeVBYaaXXo/9BPu5BIyn8NyYU2M+0SoG0s6Age/oZA8idPgrRQuFR/Zoku8Y4r1HRyW8KVGQQZfvN3Mw3/oJZDI4rtbGN2/vjvz/iH5zLSNus+zWYCuobPdVujVe/Wso1iRQEy0B+cbyoUWte8PjsQ1lXEzP47KVwknX1BWd8pihMI7uyEft6yIYwkocn0GGfDjpH2pIZlcCtt9rH77SmqAyStJ+YPzk8OyS1sHWrX2N9Mcsd7viT36FLK1reU6sb0e5FIknpHL2UzZQclRUqXPz0lBbIzJ6qFrefFzdpXoiuysO1/W0SO41OK7a49zbq9ANRBhzs0QqH069d+RNz5dkVLkjlo7QObkwwPVYotBgu0jV5oIFi3sjceuRWqAPT9Xi2rqW3oeCLJa5HT+KcItlVul5DkW7/0d1wx9uIzJ+IpMt3cJd3RIjotpoElo/DDrgypTDiwUfZwQtGIJFPnbSRcDN3aH5eRnt6bbCkUFLQfDPumWSQznvxf0TteIFj07lyPSHW2vfNhGyVe/nwkREqRBJKvji4Ks/7ODkIoFIvjA5syBDI8PiYjiDeX9Gh+CrTpxaL6jFSoUpzaaabhX7PxqXNzvcAZl3cJEgSRyBVhjRLr6AD9ErnygV4XzYRIJBGotKT4vTG+VcxRabEoArU2af5+o/ioDYXiDqJp0V+WpW8IpPj6Ne8NgKm6l2JiLls9j9yd5nLWr/iW5xU1feJRvFRSH/vFEw3rW3xpp9d098fxTMv6GjfjHsfjUDqTPATg6/6JxzvLsj8GMOQTwItA50AA3qeuYn5//XcmlzTOAFoRAAH+1tpEG2Ju/VH+VzMzGR/YMxLAFBunIiUaSteSAwI6lIPAPKAQQEDA6vwaQIt2SKgxEKDtIpxYFiPRFiwmSM1aTOrGdjJFLxagRTrh2Y8DGwYbqK/umuujq0EGGS5BMz31NtIAXQ2TyCqJlY3DYIOMmNwwMvbEsmevZWVipU5l56WwGbNIlCbh3tiM/Tx2yZzjI7VvQy4tsBrweCXoCGOK+w+rxFWRadpqg/TOOTiXhbWflF55YUsbh0fuqZcWKN6XD5y1bbHe+iWBflmhK5tZs6WAriEJWscsao7dHaGeEWmlrk+SRameVzaAUwCepXblbfxAimerKntHbjnLb4LrRBUyKmdo1QjbJhKSThZS621NgWL2AHyUchDyKi5xnqSm1FcslKdmvJEzOQWhrpQX8h6iDGfUs62eLZoorDqlAzCy1poiuwFJTuWXDzT5Hp9smEjDQ0XQwAYqKZ0iLZiQlDiQSSMbZ4+gbRLZ27cleFBRqJbDsfhHKtvYUU0ZpIr6b71MFtNBIcT0ZAQVh+J0pLMVeDkwHUbK6tUjv6ZhOwruVTcYDbTe6Hv22kZa7ZuVSB23NZNaL6mgoDQXTp19Fwf6wsSS+t7gydBguDd6mL1GjZC7XNhE2BqXRWAwCOTA8Ugvv17+p2Bf62QOZsWXVr2UneQr+8jqP8PwNS0vgCFaLJFbHVFdsJp2F0M2mJCMj2r+spOZUDdirR1bkJ6fWZfTxP3QjM3byvl5E7xJA1dUWn0JR3mn+I9C20vsjXNAedF4SXVBltBicrFTUWXSR166CzpcHk58fpPXHLCdXGmqfqsFoaWCj+Cmf1Qp5NaBYK4UCKKhQx2YdZOOiFx4KaA3KMESCiLNPB84QBRyUc6UIGPm3i92bdwrUBb8UdNsUKtD1TObKQfe+JUVdLTxlAw5Mvnpe2jezQeJvNKyrhA0U4Apa1Rov+ZzkawhGxKlEfnsv1OLMke1OkNThqFGhEp9E2wqY1hrnt9TugY/8iAok9HRCE9jNK1CUdu7SzqzJVl1JD0R3JPKzOUDQuRa5xSNYSv6rODrkXeW4kSogCM4PsoTku+qNsBy0Utnvys=); }</style></defs><g stroke-linecap="round" transform="translate(490 10) rotate(0 580 150)"><path d="M32 0 C410.05 11.34, 787.71 7.94, 1128 0 C1144.66 -2.79, 1155.42 14.03, 1160 32 C1161.57 97.96, 1163.98 160.57, 1160 268 C1156.1 292.6, 1149.79 305.1, 1128 300 C870.08 298.61, 612.52 300.57, 32 300 C10.91 298.04, -1.99 288.28, 0 268 C2.13 179.08, -0.92 96.77, 0 32 C3.18 10.96, 11.17 1.32, 32 0" stroke="none" stroke-width="0" fill="#f8f9fa"></path><path d="M32 0 C459.65 -5.96, 886.8 -6.11, 1128 0 M32 0 C284.91 2.63, 539.74 1.53, 1128 0 M1128 0 C1152.92 2.41, 1156.01 11.44, 1160 32 M1128 0 C1151.67 2.4, 1161.36 8.54, 1160 32 M1160 32 C1161.64 103.82, 1165.13 176.29, 1160 268 M1160 32 C1156.51 78.93, 1158.52 128.03, 1160 268 M1160 268 C1157.93 285.4, 1152.25 299.82, 1128 300 M1160 268 C1160.67 287.39, 1147.91 303.98, 1128 300 M1128 300 C831.53 303.2, 532.88 305.29, 32 300 M1128 300 C709.22 303.23, 291.76 302.98, 32 300 M32 300 C10.56 297.22, 2.89 287.81, 0 268 M32 300 C8.26 300.9, -4.06 292.59, 0 268 M0 268 C0.29 212.02, 0.23 151.89, 0 32 M0 268 C-4.82 198.4, -4.03 128.1, 0 32 M0 32 C-3.01 14.65, 10.68 3.18, 32 0 M0 32 C4.38 7.41, 14.05 -2.26, 32 0" stroke="#868e96" stroke-width="2" fill="none"></path></g><g stroke-linecap="round" transform="translate(10 10) rotate(0 170 150)"><path d="M32 0 C109.82 -2.67, 194.35 -1.11, 308 0 C324.83 1.94, 336.12 14.13, 340 32 C334.51 98.93, 337.47 159.13, 340 268 C338.47 288.29, 330.1 298.35, 308 300 C195.22 299.12, 91.53 297.1, 32 300 C13.89 295.73, -2.88 288.91, 0 268 C-2.3 199.85, 1.1 138.18, 0 32 C2.81 8.09, 7.64 -3.2, 32 0" stroke="none" stroke-width="0" fill="#e7f5ff"></path><path d="M32 0 C88.94 -5.08, 146.08 -2.52, 308 0 M32 0 C126.15 2.31, 223.64 3.61, 308 0 M308 0 C326.99 2.19, 341.22 11.18, 340 32 M308 0 C329.7 -1.39, 342.68 12.11, 340 32 M340 32 C338.15 127.35, 339.23 218.81, 340 268 M340 32 C340.55 121.56, 343.37 214.41, 340 268 M340 268 C341.14 289.33, 331.71 298.59, 308 300 M340 268 C337.56 287.75, 327.88 302.66, 308 300 M308 300 C242.03 302.48, 174.66 300.86, 32 300 M308 300 C203.5 296.65, 100.32 296.96, 32 300 M32 300 C12.82 297.19, 2.94 285.91, 0 268 M32 300 C12.17 297.16, 1.81 292.56, 0 268 M0 268 C0.99 206.68, 2.41 144.2, 0 32 M0 268 C2.76 190.83, 1.54 110.88, 0 32 M0 32 C-3.25 13.49, 10.52 -1.6, 32 0 M0 32 C-3.56 8.2, 9.49 -1.19, 32 0" stroke="#ced4da" stroke-width="2" fill="none"></path></g><g transform="translate(50 90) rotate(0 125.35714285714289 67.5)"><text x="125.35714285714297" y="25.758000000000013" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="27.000000000000014px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic"></text><text x="125.35714285714297" y="59.508000000000024" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="27.000000000000014px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">Write and package</text><text x="125.35714285714297" y="93.25800000000004" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="27.000000000000014px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">code as a Docker</text><text x="125.35714285714297" y="127.00800000000005" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="27.000000000000014px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">image</text></g><g stroke-linecap="round"><g transform="translate(351 159.40864617425336) rotate(0 69 -0.23813910940930327)"><path d="M0.01 1.18 C48.7 -1.39, 102.92 1.65, 134.14 -3.63 M1.48 -0.06 C36.8 -1.74, 71.38 0.16, 138.95 -0.97" stroke="#868e96" stroke-width="2" fill="none"></path></g><g transform="translate(351 159.40864617425336) rotate(0 69 -0.23813910940930327)"><path d="M115.52 8.34 C123.52 4.75, 134.25 3.22, 137.02 -2.55 M116.26 7.72 C122 5.16, 127.44 3.9, 139.42 -1.21" stroke="#868e96" stroke-width="2" fill="none"></path></g><g transform="translate(351 159.40864617425336) rotate(0 69 -0.23813910940930327)"><path d="M115.4 -8.76 C123.37 -6.2, 134.15 -1.59, 137.02 -2.55 M116.14 -9.38 C122.05 -7.5, 127.52 -4.31, 139.42 -1.21" stroke="#868e96" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round" transform="translate(1790 10) rotate(0 160 150)"><path d="M32 0 C89.92 -7.54, 148.1 -3.75, 288 0 C309.35 1.19, 321.22 14.74, 320 32 C319.89 91.01, 314.87 151.98, 320 268 C315.67 293.03, 303.86 301.42, 288 300 C200.41 300.06, 110.74 301.31, 32 300 C5.95 301.16, 1.02 291.55, 0 268 C8.15 216.49, 2.94 170.2, 0 32 C2.74 12.95, 5.19 -3.8, 32 0" stroke="none" stroke-width="0" fill="#e7f5ff"></path><path d="M32 0 C127.08 1.46, 224.31 -1.74, 288 0 M32 0 C87.33 3.23, 142.23 3.08, 288 0 M288 0 C305.48 -3.51, 322.35 8.09, 320 32 M288 0 C305.38 -1.61, 322.73 7.65, 320 32 M320 32 C321.42 104.73, 317.45 172.38, 320 268 M320 32 C320.07 116.29, 319.91 201.97, 320 268 M320 268 C318.49 293.2, 308.83 299.34, 288 300 M320 268 C322.76 287.51, 309.09 302.29, 288 300 M288 300 C230.3 298.37, 177.63 294.76, 32 300 M288 300 C205.61 304.86, 123.71 303.64, 32 300 M32 300 C10.28 299.89, -1.27 290.43, 0 268 M32 300 C8.11 296.88, 1.15 289.65, 0 268 M0 268 C3.63 218.68, 0.75 164.44, 0 32 M0 268 C-0.03 215.28, -0.99 163.45, 0 32 M0 32 C-1.83 12.31, 7.58 1.63, 32 0 M0 32 C3.08 7.34, 8.33 -2.06, 32 0" stroke="#ced4da" stroke-width="2" fill="none"></path></g><g stroke-linecap="round"><g transform="translate(1670 150.6206375576644) rotate(0 59.5 -0.6279086429339031)"><path d="M-2.22 -2.72 C36.37 -0.75, 67.62 -2.06, 116.83 2.29 M-1.57 0.6 C45 -0.04, 93.01 -1.68, 119.09 -2.17" stroke="#868e96" stroke-width="2" fill="none"></path></g><g transform="translate(1670 150.6206375576644) rotate(0 59.5 -0.6279086429339031)"><path d="M94.69 5.59 C103.25 4.31, 108.11 1.14, 118 -0.4 M95.02 7.25 C104.07 3.97, 113.85 -0.18, 119.13 -2.63" stroke="#868e96" stroke-width="2" fill="none"></path></g><g transform="translate(1670 150.6206375576644) rotate(0 59.5 -0.6279086429339031)"><path d="M94.28 -11.51 C102.91 -7.71, 107.89 -5.8, 118 -0.4 M94.61 -9.85 C103.83 -6.41, 113.77 -3.85, 119.13 -2.63" stroke="#868e96" stroke-width="2" fill="none"></path></g></g><mask></mask><g stroke-linecap="round" transform="translate(550 70) rotate(0 160 80)"><path d="M32 0 C88.03 3.31, 146.21 4.85, 288 0 C306.23 -5.03, 320.79 14.31, 320 32 C321.35 50.46, 317.37 70.54, 320 128 C316.62 153.96, 313.08 157.59, 288 160 C231.31 162.64, 183.2 167.3, 32 160 C14.95 158.19, 4.25 150.92, 0 128 C-0.84 92.49, 4.06 66.68, 0 32 C-0.19 14.02, 15.12 -0.13, 32 0" stroke="none" stroke-width="0" fill="#e7f5ff"></path><path d="M32 0 C111.7 -3.95, 194.64 1.44, 288 0 M32 0 C129.06 -0.01, 228.08 2.98, 288 0 M288 0 C310.78 0.79, 317.48 13.47, 320 32 M288 0 C310.01 -1.75, 323.58 6.66, 320 32 M320 32 C322.14 64.3, 318.24 105.19, 320 128 M320 32 C318.85 60.47, 317.19 93.19, 320 128 M320 128 C317.17 145.75, 307.33 157.9, 288 160 M320 128 C319.84 148.19, 311.3 160.43, 288 160 M288 160 C189.32 160.29, 83.49 156.23, 32 160 M288 160 C202.14 164.18, 115.23 162.36, 32 160 M32 160 C8.44 156.48, -3.12 151.33, 0 128 M32 160 C11.85 156.85, -1.82 151.85, 0 128 M0 128 C-1.68 96.38, -2.8 55.38, 0 32 M0 128 C-2.65 109.81, -0.58 89.97, 0 32 M0 32 C1.13 10.7, 9.53 -2.63, 32 0 M0 32 C-3.97 10.47, 8.69 -2.29, 32 0" stroke="#ced4da" stroke-width="2" fill="none"></path></g><g stroke-linecap="round" transform="translate(930 70) rotate(0 160 80)"><path d="M32 0 C79.95 -0.97, 139.03 -0.19, 288 0 C305.26 3.78, 324.98 12.57, 320 32 C318.04 54.23, 326.33 78.99, 320 128 C322.84 150.73, 313.52 164.04, 288 160 C202.54 166.5, 113.67 158.34, 32 160 C7.2 162.34, 4.58 147.12, 0 128 C-0.12 96.77, 1.53 63.7, 0 32 C-4.99 6.87, 10.75 -4.61, 32 0" stroke="none" stroke-width="0" fill="#e7f5ff"></path><path d="M32 0 C119.91 -6.01, 210.14 -2.46, 288 0 M32 0 C100.84 -1.11, 169.21 -0.61, 288 0 M288 0 C310.9 2.05, 323.46 13.1, 320 32 M288 0 C313.82 2.09, 323.75 10.18, 320 32 M320 32 C322.58 58.17, 321.7 76.57, 320 128 M320 32 C319.99 53.91, 320.71 77.7, 320 128 M320 128 C321.21 150.9, 306.44 156.13, 288 160 M320 128 C319.46 149.21, 308.16 156.17, 288 160 M288 160 C197.46 159.42, 111.22 154.7, 32 160 M288 160 C215.3 162.35, 139.98 160.7, 32 160 M32 160 C10.14 158.73, -2.45 151.47, 0 128 M32 160 C9.13 158.35, -2.22 148.93, 0 128 M0 128 C-3.55 101.3, -2.3 75.94, 0 32 M0 128 C1.39 100.35, 1.78 73.62, 0 32 M0 32 C-2.84 8.64, 10.58 -3.45, 32 0 M0 32 C4.19 13.86, 14.1 -0.62, 32 0" stroke="#ced4da" stroke-width="2" fill="none"></path></g><g stroke-linecap="round" transform="translate(1290 70) rotate(0 160 80)"><path d="M32 0 C130.85 2.2, 225.44 -1.93, 288 0 C309.92 -4.48, 319.64 7.12, 320 32 C325.32 70.05, 319.26 102.91, 320 128 C322.88 150.99, 309.64 164.86, 288 160 C188.03 161.18, 83.92 159.32, 32 160 C6.56 155.39, 5.14 150.14, 0 128 C-4.05 90.13, -3.89 61.18, 0 32 C-5.13 5.25, 9.05 4.6, 32 0" stroke="none" stroke-width="0" fill="#e7f5ff"></path><path d="M32 0 C123.42 3.45, 221.34 -2.1, 288 0 M32 0 C103.64 1.02, 179.07 0.48, 288 0 M288 0 C307.52 3.37, 320.9 7.64, 320 32 M288 0 C307.51 3.34, 318.43 13, 320 32 M320 32 C323.25 65.17, 322.96 97, 320 128 M320 32 C319.81 70.76, 322.68 107.06, 320 128 M320 128 C322.23 152.61, 313.07 161.49, 288 160 M320 128 C322.4 152.4, 312.61 155.9, 288 160 M288 160 C227.01 155.66, 167.43 155.16, 32 160 M288 160 C202.54 157.32, 115.81 156.42, 32 160 M32 160 C10.57 158.24, -2.2 148.28, 0 128 M32 160 C12.93 158.47, 3.49 147.52, 0 128 M0 128 C-0.14 97.85, 2.99 73.1, 0 32 M0 128 C-1.47 107.15, -1.57 83.63, 0 32 M0 32 C0.29 10.78, 9.79 1.16, 32 0 M0 32 C-2.1 14.8, 6.65 2.77, 32 0" stroke="#ced4da" stroke-width="2" fill="none"></path></g><g transform="translate(510 10) rotate(0 570 22.5)"><text x="570" y="31.5" font-family="Comic Shanns, monospace, Segoe UI Emoji" font-size="36px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">Docker Hub</text></g><g transform="translate(23.43415421786358 37.248527265963276) rotate(0 153.2829228910682 22.5)"><text x="153.2829228910682" y="34.344" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="36px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">DVP</text></g><g transform="translate(570 90) rotate(0 136.25148701428282 22.5)"><text x="136.25148701428284" y="34.344" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="36px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">High-availability</text></g><g transform="translate(1330 90) rotate(0 136.25148701428282 22.5)"><text x="136.25148701428284" y="34.344" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="36px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">CDN &amp; caching</text></g><g transform="translate(950 90) rotate(0 136.25148701428282 22.5)"><text x="136.25148701428284" y="34.344" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="36px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">Durability</text></g><g transform="translate(1790 30) rotate(0 153.2829228910682 22.5)"><text x="153.2829228910682" y="34.344" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="36px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">Developers / CI</text></g><g transform="translate(1830 110) rotate(0 125.357142857143 33.75)"><text x="125.35714285714297" y="25.758000000000013" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="27.000000000000014px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">Pull &amp; use your DVP</text><text x="125.35714285714297" y="59.508000000000024" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="27.000000000000014px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">images anywhere</text></g><g transform="translate(590 150) rotate(0 125.357142857143 16.875)"><text x="125.35714285714297" y="25.758000000000013" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="27.000000000000014px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">99.9% uptime</text></g><g transform="translate(1310 150) rotate(0 150 16.875)"><text x="149.99999999999997" y="25.758000000000013" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="27.000000000000014px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">Fast access everywhere</text></g><g transform="translate(970 150) rotate(0 125.357142857143 16.875)"><text x="125.35714285714297" y="25.758000000000013" font-family="Nunito, sans-serif, Segoe UI Emoji" font-size="27.000000000000014px" fill="#1e1e1e" text-anchor="middle" style="white-space: pre;" direction="ltr" dominant-baseline="alphabetic">Daily backups</text></g></svg>
\ No newline at end of file
diff --git a/content/manuals/docker-hub/repos/manage/trusted-content/insights-analytics.md b/content/manuals/docker-hub/repos/manage/trusted-content/insights-analytics.md
index 4adf8b19bbfb..2cb03e662649 100644
--- a/content/manuals/docker-hub/repos/manage/trusted-content/insights-analytics.md
+++ b/content/manuals/docker-hub/repos/manage/trusted-content/insights-analytics.md
@@ -3,27 +3,320 @@ title: Insights and analytics
 description: Discover how to access usage statistics of your images on Docker Hub
 keywords: docker hub, hub, insights, analytics, api, verified publisher
 aliases:
-- /docker-hub/publish/insights-analytics/
-- /docker-hub/insights-analytics/
-- /trusted-content/insights-analytics/
+  - /docker-hub/publish/insights-analytics/
+  - /docker-hub/insights-analytics/
+  - /trusted-content/insights-analytics/
+toc_max: 3
 ---
 
-Insights and analytics provides usage analytics for Docker Verified
-Publisher (DVP) and Docker-Sponsored Open Source (DSOS) images on Docker Hub. This includes self-serve access to image and extension usage metrics for a desired time span. You can also display the number of image pulls by tag or by digest, and get breakdowns by geolocation, cloud provider, client, and more.
+Insights and analytics provides usage analytics for [Docker Verified Publisher
+(DVP)](https://www.docker.com/partners/programs/) and [Docker-Sponsored Open
+Source (DSOS)](https://www.docker.com/community/open-source/application/#)
+images on Docker Hub. This includes self-serve access to image and extension
+usage metrics for a desired time span. You can see the number of image pulls by
+tag or by digest, geolocation, cloud provider, client, and more.
+
+- [DVP program](#dvp-program): Usage analytics for Docker Verified Publisher
+  organizations, including tiered reports and report configuration.
+- [DSOS & Legacy DVP programs](#dsos--legacy-dvp-programs): Usage analytics for
+  Docker-Sponsored Open Source publishers, and for existing customers on the
+  deprecated Legacy DVP program.
+
+The Legacy DVP program applies to existing customers who have not yet renewed
+to DVP Core. The DVP Legacy program is deprecated and will be retired. Contact
+your Docker sales representative or
+[Docker](https://www.docker.com/partners/programs/) for more information.
+
+## DVP program
+
+All members of an organization have access to the analytics data. Members can
+access analytics data in the [Docker Hub](https://hub.docker.com/) web interface.
+
+### Available reports
+
+The following reports are available for download as CSV files, based on your
+organization's DVP subscription tier:
+
+- Starter tier
+  - [Summary](#summary-report)
+- Growth tier
+  - [Summary](#summary-report)
+  - [Trends](#trends-report)
+  - [Domain-level reports](#domain-level-reports)
+  - [Benchmark](#benchmark-report)
+
+The Domain-level reports and Benchmark report each provide a different slice
+of reporting on consuming domains:
+
+- Domain-level reports show how those domains use your own images, and which
+  other images they use alongside yours.
+- Benchmark shows how those domains use the specific images you've configured to
+  benchmark against, such as a single repository.
+
+After your organization is provisioned for DVP analytics, it takes up to one
+week for the first reports to become available.
+
+#### Summary report
+
+The summary report provides high-level usage metrics aggregated across all your
+Docker Hub content, organized by namespace and repository. This report gives you
+a comprehensive overview of your image portfolio performance, helping you
+understand which repositories, tags, and specific image versions are most
+popular with your users.
+
+You can use this report to answer questions like:
+
+- Which of my repositories are getting the most usage?
+- How do different image tags compare in terms of adoption?
+- What's the ratio of actual downloads versus version checks across my
+  portfolio?
+- Which specific image digests are being pulled most frequently?
+- How has overall usage changed over time for my entire image collection?
+
+To access the report:
+
+1. Sign in to [Docker Hub](https://hub.docker.com/).
+2. Select **My Hub** in the top navigation.
+3. Select your organization in the left navigation.
+4. Select **Analytics** > **Overview** in the left navigation.
+5. Download the report by doing one of the following:
+   - Select **Download Weekly Summary**.
+   - Select the **Download Monthly Summary**.
+   - Expand the **Summary reports for the year** drop-down and then select
+     **Download report** for the desired week or month.
+
+The summary report is a CSV file that contains the following data points:
+
+| Field              | Description                                                                                                                                                           |
+| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `DATE_GRANULARITY` | Weekly or monthly granularity of the data. Indicates whether the data is aggregated by week or month.                                                                 |
+| `DATE_REFERENCE`   | The start date of the week or month in YYYY-MM-DD format (e.g., `2025-09-29` for the week starting September 29, 2025).                                               |
+| `PUBLISHER_NAME`   | The name of the Docker organization that owns the repository (e.g., `demonstrationorg`).                                                                              |
+| `LEVEL`            | The aggregation level of the data - either `repository` (summary for entire repository), `tag` (summary for specific tag), or `digest` (summary for specific digest). |
+| `REFERENCE`        | The specific reference being summarized - the repository name, tag name, or digest hash depending on the level.                                                       |
+| `DATA_DOWNLOADS`   | The number of actual image downloads.                                                                                                                                 |
+| `VERSION_CHECKS`   | The number of version checks performed (HEAD requests to check for updates without downloading the full image).                                                       |
+| `EVENT_COUNT`      | The total number of events, calculated as the sum of data downloads and version checks.                                                                               |
+
+#### Trends report
+
+The trends report helps you understand how adoption of your container images
+evolves over time. It provides visibility into pull activity across repositories
+and tags, enabling you to identify adoption patterns, version migration trends,
+and usage environments (e.g., local development, CI/CD, production).
+
+You can use this report to answer questions like:
+
+- Which versions are gaining or losing traction?
+- Is a new release being adopted?
+- How does usage vary across cloud providers?
+
+To access the report:
+
+1. Sign in to [Docker Hub](https://hub.docker.com/).
+2. Select **My Hub** in the top navigation.
+3. Select your organization in the left navigation.
+4. Select **Analytics** > **Trends** in the left navigation.
+5. Select **DATA BY WEEK** or **DATA BY MONTH** to choose the data granularity.
+6. Select **Download report** for the desired week or month.
+
+The trends report is a CSV file that contains the following data points:
+
+| Field                          | Description                                                                                                             |
+| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
+| `DATE_GRANULARITY`             | Weekly or monthly granularity of the data.                                                                              |
+| `DATE_REFERENCE`               | The start date of the week or month.                                                                                    |
+| `PUBLISHER_NAME`               | The name of the organization that owns the repository.                                                                  |
+| `IMAGE_REPOSITORY`             | The full name of the image repository (e.g., `demonstrationorg/scout-demo`).                                            |
+| `NAMESPACE`                    | The Docker organization or namespace that owns the repository.                                                          |
+| `IP_COUNTRY`                   | The country code (ISO 3166-1 alpha-2) where the pull request originated from (e.g., `US`, `CA`).                        |
+| `CLOUD_SERVICE_PROVIDER`       | The cloud service provider used for the pull request (e.g., `gcp`, `aws`, `azure`) or `no csp` for non-cloud providers. |
+| `USER_AGENT`                   | The client application or tool used to pull the image (e.g., `docker`, `docker-scout`, `node-fetch`, `regclient`).      |
+| `TAG`                          | The specific image tag that was pulled, or `\\N` if no specific tag was used.                                           |
+| `DATA_DOWNLOADS`               | The number of data downloads for the specified criteria.                                                                |
+| `VERSION_CHECKS`               | The number of version checks (HEAD requests) performed without downloading the full image.                              |
+| `PULLS`                        | The total number of pull requests (data downloads + version checks).                                                    |
+| `UNIQUE_AUTHENTICATED_USERS`   | The number of unique authenticated users who performed pulls.                                                           |
+| `UNIQUE_UNAUTHENTICATED_USERS` | The number of unique unauthenticated users who performed pulls.                                                         |
+
+#### Domain-level reports
+
+Domain-level reports provide detailed insights into how specific consuming
+domains use your Docker Verified Publisher (DVP) images, both on their own and
+alongside other container images. These reports help you understand usage
+patterns, deployment environments, adoption trends, and technology stack
+combinations across your customer base and potential prospects.
+
+You can use these reports to answer questions like:
+
+- How are specific consuming domains using my images across different
+  environments?
+- What deployment patterns do I see across local development, CI/CD, and
+  production?
+- Which consuming domains are heavy users of my images?
+- How does usage vary by geography and cloud providers for consuming domains?
+- Which consuming domains are using my image alongside specific complementary
+  technologies?
+- What technology stacks are adopted by enterprise customers in my target
+  market?
+- Which organizations might be good candidates for partnership discussions?
+- How can I identify potential customers who are already using related
+  technologies?
+
+##### Technographic report
+
+The technographic report provides a detailed view of which specific consuming
+domains are using your DVP images together with other container images. This
+report gives you visibility into the actual organizations adopting your
+technology stack combinations, enabling targeted business development and
+partnership opportunities.
+
+To access the report:
+
+1. Sign in to [Docker Hub](https://hub.docker.com/).
+2. Select **My Hub** in the top navigation.
+3. Select your organization in the left navigation.
+4. Select **Analytics** > **Technographic** in the left navigation.
+5. Select **DATA BY WEEK** or **DATA BY MONTH** to choose the data granularity.
+6. Select **Download report** for the desired week or month.
+
+The technographic report is a CSV file that contains the following
+data points:
+
+| Field              | Description                                                                                        |
+| ------------------ | ---------------------------------------------------------------------------------------------------- |
+| `DATE_GRANULARITY` | Weekly or monthly granularity of the data.                                                         |
+| `DATE_REFERENCE`   | The start date of the week or month in YYYY-MM-DD format.                                          |
+| `PUBLISHER_NAME`   | The name of the organization that owns the DVP repository.                                         |
+| `DOMAIN`           | The consuming domain that pulled both your DVP image and the paired image (e.g., `example.com`). |
+| `DVPP_IMAGE`       | Your Docker Verified Publisher image repository name.                                              |
+| `PAIRED_IMAGE`     | The other image repository that was used together with your DVP image by this domain.              |
+
+Each row represents a unique combination of a consuming domain, your DVP
+image, and another image that were used together during the specified time
+period.
+
+> [!NOTE]
+>
+> To protect privacy and ensure data quality, this report excludes personal
+> email domains, disposable email services, and university domains. Only
+> business and organizational domains are included in the analysis.
+
+##### Consuming domains report
+
+The consuming domains report provides detailed insights into how specific
+consuming domains use your Docker Verified Publisher (DVP) images. This
+report helps you understand usage patterns, deployment environments, and
+adoption trends across your customer base and potential prospects.
+
+To access the report:
+
+1. Sign in to [Docker Hub](https://hub.docker.com/).
+2. Select **My Hub** in the top navigation.
+3. Select your organization in the left navigation.
+4. Select **Analytics** > **Consuming Domains** in the left navigation.
+5. Select **DATA BY WEEK** or **DATA BY MONTH** to choose the data granularity.
+6. Select **Download report** for the desired week or month.
+
+The consuming domains report is a CSV file that contains the following data
+points:
+
+| Field                        | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
+| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `DATE_GRANULARITY`           | Weekly or monthly granularity of the data.                                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| `DATE_REFERENCE`             | The start date of the week or month in YYYY-MM-DD format.                                                                                                                                                                                                                                                                                                                                                                                                                               |
+| `PUBLISHER_NAME`             | The name of the organization that owns the DVP repository.                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| `DOMAIN`                     | The consuming domain (e.g., `docker.com`) associated with the image pulls.                                                                                                                                                                                                                                                                                                                                                                                                              |
+| `IP_COUNTRY`                 | The country code (ISO 3166-1 alpha-2) where the pull request originated from.                                                                                                                                                                                                                                                                                                                                                                                                           |
+| `CLOUD_SERVICE_PROVIDER`     | The cloud service provider used for the pull request or `no csp` for non-cloud providers.                                                                                                                                                                                                                                                                                                                                                                                               |
+| `USER_AGENT`                 | The client application or tool used to pull the image.                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| `INFERRED_USE_CASE`          | The inferred deployment environment based on user agent and cloud provider analysis. Values include: <br>• `Local Dev`: Local development environment (e.g., Docker Desktop, direct `docker` commands) <br>• `CI/CD`: Continuous integration/deployment pipelines (e.g., containerd, build tools, registry mirroring) <br>• `Prod`: Production environments (e.g., Kubernetes, container orchestration platforms) <br>• `Unknown`: Unable to determine the use case from available data |
+| `IMAGE_REPOSITORY`           | The specific DVP image repository that was pulled.                                                                                                                                                                                                                                                                                                                                                                                                                                      |
+| `DATA_DOWNLOADS`             | The number of actual image layer downloads for this combination.                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| `VERSION_CHECKS`             | The number of version checks (HEAD requests) performed without downloading the full image.                                                                                                                                                                                                                                                                                                                                                                                              |
+| `PULLS`                      | The total number of pull requests (data downloads + version checks).                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| `UNIQUE_AUTHENTICATED_USERS` | The number of unique authenticated users from this domain who performed pulls.                                                                                                                                                                                                                                                                                                                                                                                                          |
+
+> [!NOTE]
+>
+> Use case inference is determined by analyzing user agent patterns and cloud
+> service provider usage. Local development tools used on cloud infrastructure
+> are reclassified as CI/CD, and CI/CD tools used on cloud infrastructure are
+> reclassified as production to better reflect actual deployment patterns.
+
+#### Benchmark report
+
+The benchmark report shows how consuming domains interact with the specific
+images you've configured to benchmark against, such as a single repository.
+The report is generated per repository, so each benchmark repository
+you configure produces its own report.
+
+To access the report:
+
+1. Sign in to [Docker Hub](https://hub.docker.com/).
+2. Select **My Hub** in the top navigation.
+3. Select your organization in the left navigation.
+4. Select **Analytics** > **Benchmark** in the left navigation.
+5. Select **DATA BY WEEK** or **DATA BY MONTH** to choose the data granularity.
+6. Select **Download report** for the desired week or month.
+
+The benchmark report is a CSV file that contains the following data points:
+
+| Field                         | Description                                                                                 |
+| ----------------------------- | -------------------------------------------------------------------------------------------- |
+| `DATE_GRANULARITY`            | Weekly or monthly granularity of the data.                                                   |
+| `DATE_REFERENCE`              | The start date of the week or month in YYYY-MM-DD format.                                    |
+| `PUBLISHER_NAME`              | The name of the organization that owns the DVP repository.                                   |
+| `DOMAIN`                      | The consuming domain associated with the pulls.                                              |
+| `IP_COUNTRY`                  | The country code (ISO 3166-1 alpha-2) where the pull request originated from.                |
+| `CLOUD_SERVICE_PROVIDER`      | The cloud service provider used for the pull request, or `no csp` for non-cloud providers.    |
+| `USER_AGENT`                  | The client application or tool used to pull the image.                                       |
+| `INFERRED_USE_CASE`           | The inferred deployment environment, using the same rules as the [consuming domains report](#consuming-domains-report). |
+| `IMAGE_REPOSITORY`            | The benchmark-configured image repository that was pulled.                                   |
+| `DATA_DOWNLOADS`              | The number of actual image layer downloads for this combination.                             |
+| `VERSION_CHECKS`              | The number of version checks (HEAD requests) performed without downloading the full image.    |
+| `PULLS`                       | The total number of pull requests (data downloads + version checks).                         |
+| `UNIQUE_AUTHENTICATED_USERS`  | The number of unique authenticated users from this domain who performed pulls.               |
+
+To configure which repositories are benchmarked, see [Configure DVP analytics
+settings](#configure-dvp-analytics-settings).
+
+### Configure DVP analytics settings
+
+Organization owners and editors can configure DVP analytics settings through the
+Admin Console to control consuming domain and benchmark report allocations for
+your verified publisher namespaces.
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization.
+2. Select **Admin Console** > **Verified Publisher**.
+3. Configure the settings:
+   - **Consuming domains**: Set the number of consuming domains to track for
+     reporting purposes. This setting determines how many domains appear in
+     your [Domain-level reports](#domain-level-reports). You can only set this
+     number up to the maximum included in your DVP subscription.
+   - **Benchmark report allocations**: If your organization has benchmark
+     reports enabled, enter the number of consuming domains to include in the
+     benchmark report for each namespace listed.
+4. Select **Save** to apply your changes.
+
+Changes to your report configuration take effect at the next reporting
+cadence, either the next weekly or monthly report.
+
+## DSOS & Legacy DVP programs
 
-<!-- prettier-ignore -->
-> [!TIP]
+> [!IMPORTANT]
 >
-> Head to the
-[Docker Verified Publisher Program](https://www.docker.com/partners/programs/) or [Docker-Sponsored Open Source](https://www.docker.com/community/open-source/application/#) pages
-to learn more about the programs.
+> The Legacy DVP program applies to existing customers who have not yet renewed
+> to DVP Core. The DVP Legacy program is deprecated and will be retired. Contact
+> your Docker sales representative or
+> [Docker](https://www.docker.com/partners/programs/) for more information.
 
-## View the image's analytics data
+### View the image's analytics data
 
 You can find analytics data for your repositories on the **Insights and
 analytics** dashboard at the following URL:
-`https://hub.docker.com/orgs/{namespace}/insights/images`. The dashboard contains a
-visualization of the usage data and a table where you can download
+`https://hub.docker.com/orgs/{namespace}/insights/images`. The dashboard
+contains a visualization of the usage data and a table where you can download
 the data as CSV files.
 
 To view data in the chart:
@@ -34,16 +327,16 @@ To view data in the chart:
 
 ![Insights and analytics chart visualization](../../../images/chart.png)
 
-<!-- prettier-ignore -->
 > [!TIP]
 >
 > Hovering your cursor over the chart displays a tooltip, showing precise data
 > for points in time.
 
-### Share analytics data
+#### Share analytics data
 
-You can share the visualization with others using the **Share** icon above the chart.
-This is a convenient way to share statistics with others in your organization.
+You can share the visualization with others using the **Share** icon at the top
+of the chart. This is a convenient way to share statistics with others in your
+organization.
 
 ![Chart share icon](../../../images/chart-share-icon.png)
 
@@ -52,32 +345,36 @@ preserves the display selections you made. When someone follows the link, the
 **Insights and analytics** page opens and displays the chart with the same
 configuration as you had set up when creating the link.
 
-## Extension analytics data
+### Extension analytics data
 
-If you have published Docker Extensions in the Extension marketplace, you can also get analytics about your extension usage, available as CSV files.
-You can download extension CSV reports from the **Insights and analytics** dashboard at the following URL:
-`https://hub.docker.com/orgs/{namespace}/insights/extensions`. If your Docker namespace contains extensions known in the marketplace, you will see an **Extensions** tab listing CSV files for your extension(s).
+If you have published Docker Extensions in the Extension marketplace, you can
+also get analytics about your extension usage, available as CSV files. You can
+download extension CSV reports from the **Insights and analytics** dashboard at
+the following URL:
+`https://hub.docker.com/orgs/{namespace}/insights/extensions`. If your Docker
+namespace contains extensions known in the marketplace, you will see an
+**Extensions** tab listing CSV files for your extension(s).
 
-## Exporting analytics data
+### Exporting analytics data
 
 You can export the analytics data either from the web dashboard, or using the
-[DVP Data API](/reference/api/hub/dvp.md). All members of an organization have access to the analytics data.
+[DVP Data API](/reference/api/dvp/latest.md). All members of an organization
+have access to the analytics data.
 
 The data is available as a downloadable CSV file, in a weekly (Monday through
 Sunday) or monthly format. Monthly data is available from the first day of the
 following calendar month. You can import this data into your own systems, or you
 can analyze it manually as a spreadsheet.
 
-### Export data
+#### Export data
 
-Export usage data for your organization's images using the Docker Hub website by following these steps:
+Export usage data for your organization's images using the Docker Hub website by
+following these steps:
 
 1.  Sign in to [Docker Hub](https://hub.docker.com/) and select **My Hub**.
 
 2.  Choose your organization and select **Analytics**.
 
-    ![Organization overview page, with the Insights and Analytics tab](../../../images/organization-tabs.png)
-
 3.  Set the time span for which you want to export analytics data.
 
     The downloadable CSV files for summary and raw data appear on the right-hand
@@ -85,13 +382,13 @@ Export usage data for your organization's images using the Docker Hub website by
 
     ![Filtering options and download links for analytics data](../../../images/download-analytics-data.png)
 
-### Export data using the API
+#### Export data using the API
 
 The HTTP API endpoints are available at:
 `https://hub.docker.com/api/publisher/analytics/v1`. Learn how to export data
-using the API in the [DVP Data API documentation](/reference/api/hub/dvp.md).
+using the API in the [DVP Data API documentation](/reference/api/dvp/latest.md).
 
-## Data points
+### Data points
 
 Export data in either raw or summary format. Each format contains different data
 points and with different structure.
@@ -99,7 +396,7 @@ points and with different structure.
 The following sections describe the available data points for each format. The
 **Date added** column shows when the field was first introduced.
 
-### Image pulls raw data
+#### Image pulls raw data
 
 The raw data format contains the following data points. Each row in the CSV file
 represents an image pull.
@@ -107,7 +404,7 @@ represents an image pull.
 | Data point                    | Description                                                                                                  | Date added        |
 | ----------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------- |
 | Action                        | Request type, see [Action classification rules][1]. One of `pull_by_tag`, `pull_by_digest`, `version_check`. | January 1, 2022   |
-| Action day                    | The date part of the timestamp: `YYYY-MM-DD`.                                                                 | January 1, 2022   |
+| Action day                    | The date part of the timestamp: `YYYY-MM-DD`.                                                                | January 1, 2022   |
 | Country                       | Request origin country.                                                                                      | January 1, 2022   |
 | Digest                        | Image digest.                                                                                                | January 1, 2022   |
 | HTTP method                   | HTTP method used in the request, see [registry API documentation][2] for details.                            | January 1, 2022   |
@@ -116,8 +413,8 @@ represents an image pull.
 | Reference                     | Image digest or tag used in the request.                                                                     | January 1, 2022   |
 | Repository                    | Docker [repository][4] (image name).                                                                         | January 1, 2022   |
 | Tag (included when available) | Tag name that's only available if the request referred to a tag.                                             | January 1, 2022   |
-| Timestamp                     | Date and time of the request: `YYYY-MM-DD 00:00:00`.                                                          | January 1, 2022   |
-| Type                          | The industry from which the event originates. One of `business`, `isp`, `hosting`, `education`, `null`.       | January 1, 2022   |
+| Timestamp                     | Date and time of the request: `YYYY-MM-DD 00:00:00`.                                                         | January 1, 2022   |
+| Type                          | The industry from which the event originates. One of `business`, `isp`, `hosting`, `education`, `null`.      | January 1, 2022   |
 | User agent tool               | The application a user used to pull an image (for example, `docker` or `containerd`).                        | January 1, 2022   |
 | User agent version            | The version of the application used to pull an image.                                                        | January 1, 2022   |
 | Domain                        | Request origin domain, see [Privacy](#privacy).                                                              | October 11, 2022  |
@@ -125,10 +422,10 @@ represents an image pull.
 
 [1]: #image-pulls-action-classification-rules
 [2]: /registry/spec/api/
-[3]: /admin/organization/orgs/
+[3]: /admin/organization/setup/orgs/
 [4]: /docker-hub/repos/
 
-### Image pulls summary data
+#### Image pulls summary data
 
 There are two levels of summary data available:
 
@@ -147,7 +444,7 @@ span:
 | Version check     | HEAD by tag, not followed by a GET                      | January 1, 2022   |
 | Owner             | The name of the organization that owns the repository.  | December 19, 2022 |
 
-### Image pulls action classification rules
+#### Image pulls action classification rules
 
 An action represents the multiple request events associated with a
 `docker pull`. Pulls are grouped by category to make the data more meaningful
@@ -179,38 +476,40 @@ pulls. To provide feedback or ask questions about these rules,
 | HEAD           | digest    | GET by same digest                                              | Pull by digest   | Image is single-arch and/or image is multi-arch but some part of the image already exists on the local machine |                                                                                                                                                                                                                                                                                       |
 | HEAD           | digest    | GET by same digest, then a second GET by different digest       | Pull by Digest   | Image is multi-arch                                                                                            |                                                                                                                                                                                                                                                                                       |
 
-### Extension Summary data
+#### Extension Summary data
 
 There are two levels of extension summary data available:
 
-- Core summary, with basic extension usage information: number of extension installs, uninstalls, and total install all times
+- Core summary, with basic extension usage information: number of extension
+  installs, uninstalls, and total install all times
 
 The core-summary-data file contains the following data points for the selected time
 span:
 
-| Data point        | Description                                             | Date added        |
-| ----------------- | ------------------------------------------------------- | ----------------- |
-| Installs          | Number of installs for the extension                    | Feb 1, 2024       |
-| TotalInstalls     | Number of installs for the extension all times          | Feb 1, 2024       |
-| Uninstalls        | Number of uninstalls for the extension                  | Feb 1, 2024       |
-| TotalUninstalls   | Number of uninstalls for the extension all times        | Feb 1, 2024       |
-| Updates           | Number of updates for the extension                     | Feb 1, 2024       |
+| Data point      | Description                                      | Date added  |
+| --------------- | ------------------------------------------------ | ----------- |
+| Installs        | Number of installs for the extension             | Feb 1, 2024 |
+| TotalInstalls   | Number of installs for the extension all times   | Feb 1, 2024 |
+| Uninstalls      | Number of uninstalls for the extension           | Feb 1, 2024 |
+| TotalUninstalls | Number of uninstalls for the extension all times | Feb 1, 2024 |
+| Updates         | Number of updates for the extension              | Feb 1, 2024 |
 
-- Premium summary, with advanced extension usage information: installs, uninstalls by unique users, extension opening by unique users.
+- Premium summary, with advanced extension usage information: installs,
+  uninstalls by unique users, extension opening by unique users.
 
 The core-summary-data file contains the following data points for the selected time
 span:
 
-| Data point        | Description                                             | Date added        |
-| ----------------- | ------------------------------------------------------- | ----------------- |
-| Installs          | Number of installs for the extension                    | Feb 1, 2024       |
-| UniqueInstalls    | Number of unique users installing the extension         | Feb 1, 2024       |
-| Uninstalls        | Number of uninstalls for the extension                  | Feb 1, 2024       |
-| UniqueUninstalls  | Number of unique users uninstalling the extension       | Feb 1, 2024       |
-| Usage             | Number of openings of the extension tab                 | Feb 1, 2024       |
-| UniqueUsers       | Number of unique users openings the extension tab       | Feb 1, 2024       |
+| Data point       | Description                                       | Date added  |
+| ---------------- | ------------------------------------------------- | ----------- |
+| Installs         | Number of installs for the extension              | Feb 1, 2024 |
+| UniqueInstalls   | Number of unique users installing the extension   | Feb 1, 2024 |
+| Uninstalls       | Number of uninstalls for the extension            | Feb 1, 2024 |
+| UniqueUninstalls | Number of unique users uninstalling the extension | Feb 1, 2024 |
+| Usage            | Number of openings of the extension tab           | Feb 1, 2024 |
+| UniqueUsers      | Number of unique users openings the extension tab | Feb 1, 2024 |
 
-## Changes in data over time
+### Changes in data over time
 
 The insights and analytics service is continuously improved to increase the
 value it brings to publishers. Some changes might include adding new data
@@ -227,7 +526,6 @@ date a given data point is available.
 This section contains information about privacy-protecting measures that ensures
 consumers of content on Docker Hub remain completely anonymous.
 
-<!-- prettier-ignore -->
 > [!IMPORTANT]
 >
 > Docker never shares any Personally Identifiable Information (PII) as part of
@@ -237,10 +535,10 @@ The image pulls summary dataset includes unique IP address count. This data poin
 includes the number of distinct unique IP addresses that request an image.
 Individual IP addresses are never shared.
 
-The image pulls raw dataset includes user IP domains as a data point. This is the domain name
-associated with the IP address used to pull an image. If the IP type is
-`business`, the domain represents the company or organization associated with
-that IP address (for example, `docker.com`). For any other IP type that's not
-`business`, the domain represents the internet service provider or hosting
+The image pulls raw dataset includes user IP domains as a data point. This is
+the domain name associated with the IP address used to pull an image. If the IP
+type is `business`, the domain represents the company or organization associated
+with that IP address (for example, `docker.com`). For any other IP type that's
+not `business`, the domain represents the internet service provider or hosting
 provider used to make the request. On average, only about 30% of all pulls
 classify as the `business` IP type (this varies between publishers and images).
diff --git a/content/manuals/docker-hub/repos/manage/trusted-content/official-images.md b/content/manuals/docker-hub/repos/manage/trusted-content/official-images.md
index 206ee0eaa551..07f3e330628a 100644
--- a/content/manuals/docker-hub/repos/manage/trusted-content/official-images.md
+++ b/content/manuals/docker-hub/repos/manage/trusted-content/official-images.md
@@ -10,6 +10,18 @@ aliases:
 - /docker-hub/official_images/
 ---
 
+> [!NOTE]
+>
+> Docker is retiring Docker Content Trust (DCT) for Docker Official Images
+> (DOI). You should start planning to transition to a different image signing
+> and verification solution (like [Sigstore](https://www.sigstore.dev/) or
+> [Notation](https://github.com/notaryproject/notation#readme)). Docker will
+> publish migration guides soon to help you in that effort. Timelines for the
+> complete deprecation of DCT are being finalized and will be published soon.
+>
+> For more details, see
+> https://www.docker.com/blog/retiring-docker-content-trust/.
+
 Docker, Inc. sponsors a dedicated team that's responsible for reviewing and
 publishing all content in Docker Official Images. This team works in
 collaboration with upstream software maintainers, security experts, and the
diff --git a/content/manuals/docker-hub/repos/manage/webhooks.md b/content/manuals/docker-hub/repos/manage/webhooks.md
index 67928127f7d8..0090bf5381e7 100644
--- a/content/manuals/docker-hub/repos/manage/webhooks.md
+++ b/content/manuals/docker-hub/repos/manage/webhooks.md
@@ -14,7 +14,7 @@ You can use webhooks to cause an action in another service in response to a push
 To create a webhook:
 1. In your chosen repository, select the **Webhooks** tab.
 2. Provide a name for the webhook.
-3. Provide a destination webhook URL. This is where webhook POST requests are delivered.
+3. Provide a destination webhook URL. This is where webhook POST requests are delivered. The URL must be 255 characters or fewer.
 4. Select **Create**.
 
 ## View webhook delivery history
@@ -57,3 +57,7 @@ Webhook payloads have the following JSON format:
   }
 }
 ```
+
+> [!NOTE]
+>
+> The `callback_url` field is a legacy field and is no longer supported.
\ No newline at end of file
diff --git a/content/manuals/docker-hub/repos/settings.md b/content/manuals/docker-hub/repos/settings.md
deleted file mode 100644
index 3b0f917d1eb3..000000000000
--- a/content/manuals/docker-hub/repos/settings.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-description: Learn about personal repository settings in Docker Hub
-keywords: Docker Hub, Hub, repositories, settings
-title: Personal settings for repositories
-linkTitle: Personal settings
-toc_max: 3
-weight: 50
----
-
-For your account, you can set personal settings for repositories, including
-default repository privacy and autobuild notifications.
-
-## Default repository privacy
-
-When creating a new repository in Docker Hub, you are able to specify the
-repository visibility. You can also change the visibility at any time in Docker Hub.
-
-The default setting is useful if you use the `docker push` command to push to a
-repository that doesn't exist yet. In this case, Docker Hub automatically
-creates the repository with your default repository privacy.
-
-### Configure default repository privacy
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select **My Hub** > **Settings** > **Default privacy**.
-3. Select the **Default privacy** for any new repository created.
-
-   - **Public**: All new repositories appear in Docker Hub search results and can be
-     pulled by everyone.
-   - **Private**: All new repositories don't appear in Docker Hub search results
-     and are only accessible to you and collaborators. In addition, if the
-     repository is created in an organization's namespace, then the repository
-     is accessible to those with applicable roles or permissions.
-
-4. Select **Save**.
-
-## Autobuild notifications
-
-You can send notifications to your email for all your repositories using
-autobuilds.
-
-### Configure autobuild notifications
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select **My Hub** > **Repositories** > **Settings** > **Notifications**.
-3. Select the notifications to receive by email.
-
-   - **Off**: No notifications.
-   - **Only failures**: Only notifications about failed builds.
-   - **Everything**: Notifications for successful and failed builds.
-
-4. Select **Save**.
diff --git a/content/manuals/docker-hub/service-accounts.md b/content/manuals/docker-hub/service-accounts.md
deleted file mode 100644
index c8694214a1f6..000000000000
--- a/content/manuals/docker-hub/service-accounts.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-description: Docker Service accounts
-keywords: Docker, service, accounts, Docker Hub
-title: Service accounts
-weight: 50
----
-
-{{% include "new-plans.md" %}}
-
-> [!IMPORTANT]
->
-> As of December 10, 2024, Enhanced Service Account add-ons are no longer
-> available. Existing Service Account agreements will be honored until their
-> current term expires, but new purchases or renewals of Enhanced Service
-> Account add-ons are no longer available and customers must renew under a new
-> subscription plan.
->
-> Docker recommends transitioning to [Organization Access Tokens
-> (OATs)](../security/for-admins/access-tokens.md), which can provide similar
-> functionality.
-
-A service account is a Docker ID used for automated management of container images or containerized applications. Service accounts are typically used in automated workflows, and don't share Docker IDs with the members in the organization. Common use cases for service accounts include mirroring content on Docker Hub, or tying in image pulls from your CI/CD process.
-
-## Enhanced Service Account add-on tiers
-
-Refer to the following table for details on the Enhanced Service Account add-ons:
-
-| Tier | Pull Rates Per Day\* |
-| ------ | ------ |
-| 1 | 5,000-10,000 |
-| 2 | 10,000-25,000 |
-| 3 | 25,000-50,000 |
-| 4 | 50,000-100,000 |
-| 5 | 100,000+ |
-
-<sub>*The service account may exceed Pulls by up to 25% for up to 20 days during the year without incurring additional fees. Reports on consumption are available upon request.<sub>
\ No newline at end of file
diff --git a/content/manuals/docker-hub/settings.md b/content/manuals/docker-hub/settings.md
new file mode 100644
index 000000000000..9e0fccb3df7d
--- /dev/null
+++ b/content/manuals/docker-hub/settings.md
@@ -0,0 +1,98 @@
+---
+description: Learn about settings in Docker Hub
+keywords: Docker Hub, Hub, repositories, settings
+title: Settings
+weight: 25
+aliases:
+  - /docker-hub/repos/settings/
+---
+
+You can configure the following settings in Docker Hub:
+
+- [Default privacy](#default-privacy): Settings for all repositories within each
+  namespace
+- [Notifications](#notifications): Personal settings for autobuild notifications
+
+## Default privacy
+
+You can configure the following default privacy settings for all repositories in
+a namespace:
+
+- [Disable creation of public repos](#disable-creation-of-public-repos): Prevent
+  organization users from creating public repositories (organization namespaces
+  only)
+- [Configure default repository privacy](#configure-default-repository-privacy):
+  Set the default repository privacy for new repositories
+
+
+### Disable creation of public repos
+
+{{< summary-bar feature_name="Disable public repositories" >}}
+
+Organization owners and editors can prevent creating public repositories within
+organization namespaces. You cannot configure this setting for personal account
+namespaces.
+
+> [!NOTE]
+>
+> Enabling this feature does not affect existing public repositories. Any public
+> repositories that already exist will remain public. To make them private, you
+> must change their visibility in the individual repository settings.
+
+To configure the disable public repositories setting for an organization
+namespace:
+
+1. Sign in to [Docker Hub](https://hub.docker.com).
+2. Select **My Hub**.
+3. Select your organization from the top-left account drop-down.
+4. Select **Settings** > **Default privacy**.
+5. Toggle **Disable public repositories** to your desired setting.
+6. Select **Save**.
+
+### Configure default repository privacy
+
+Use the default repository privacy setting to automatically set privacy for
+repositories created via `docker push` commands when the repository doesn't
+exist yet. In this case, Docker Hub automatically creates the repository with
+the default repository privacy for that namespace.
+
+> [!NOTE]
+>
+> You cannot configure the default repository privacy setting when **Disable
+> public repositories** is enabled.
+
+To configure the default repository privacy for a namespace:
+
+1. Sign in to [Docker Hub](https://hub.docker.com).
+2. Select **My Hub**.
+3. Select your organization or account from the top-left account drop-down.
+4. Select **Settings** > **Default privacy**.
+5. In **Default repository privacy**, select the desired default privacy setting:
+
+   - **Public**: All new repositories appear in Docker Hub search results and can be
+     pulled by everyone.
+   - **Private**: All new repositories don't appear in Docker Hub search results
+     and are only accessible to you and collaborators. In addition, if the
+     repository is created in an organization's namespace, then the repository
+     is accessible to those with applicable roles or permissions.
+
+6. Select **Save**.
+
+## Notifications
+
+You can send notifications to your email for all your repositories using
+autobuilds.
+
+### Configure autobuild notifications
+
+1. Sign in to [Docker Hub](https://hub.docker.com).
+2. Select **My Hub**.
+3. Select your personal account from the top-left account drop-down.
+4. Select **Settings** > **Notifications**.
+5. Select the notifications to receive by email:
+
+   - **Off**: No notifications.
+   - **Only failures**: Only notifications about failed builds.
+   - **Everything**: Notifications for successful and failed builds.
+
+6. Select **Save**.
diff --git a/content/manuals/docker-hub/troubleshoot.md b/content/manuals/docker-hub/troubleshoot.md
index e0976f250d44..ddf772eba73c 100644
--- a/content/manuals/docker-hub/troubleshoot.md
+++ b/content/manuals/docker-hub/troubleshoot.md
@@ -33,7 +33,7 @@ You have reached your pull rate limit. You may increase the limit by authenticat
 You can use one of the following solutions:
 
 - [Authenticate](./usage/pulls.md#authentication) or
-  [upgrade](../subscription/change.md#upgrade-your-subscription) your Docker
+  [upgrade](../subscription/manage.md#upgrade-plans) your Docker
   account.
 - [View your pull rate limit](./usage/pulls.md#view-hourly-pull-rate-and-limit),
   wait until your pull rate limit decreases, and then try again.
@@ -79,4 +79,4 @@ Unexpected status code 500
 1. View the [Docker System Status Page](https://www.dockerstatus.com/) and
    verify that all services are operational.
 2. Try accessing Docker Hub again. It may be a temporary issue.
-3. [Contact Docker Support](https://www.docker.com/support/) to report the issue.
\ No newline at end of file
+3. [Contact Docker Support](https://www.docker.com/support/) to report the issue.
diff --git a/content/manuals/docker-hub/usage/pulls.md b/content/manuals/docker-hub/usage/pulls.md
index 2835edad9eaf..c04e64c82ec0 100644
--- a/content/manuals/docker-hub/usage/pulls.md
+++ b/content/manuals/docker-hub/usage/pulls.md
@@ -17,7 +17,7 @@ The following pull usage and limits apply based on your subscription, subject to
 fair use:
 
 | User type                | Pull rate limit per 6 hours             |
-|--------------------------|-----------------------------------------|
+| ------------------------ | --------------------------------------- |
 | Business (authenticated) | Unlimited                               |
 | Team (authenticated)     | Unlimited                               |
 | Pro (authenticated)      | Unlimited                               |
@@ -28,20 +28,20 @@ fair use:
 
 A pull is defined as the following:
 
- - A Docker pull includes both a version check and any download that
-   occurs as a result of the pull. Depending on the client, a `docker pull` can
-   verify the existence of an image or tag without downloading it by performing
-   a version check.
- - Version checks do not count towards usage pricing.
- - A pull for a normal image makes one pull for a [single
-   manifest](https://github.com/opencontainers/image-spec/blob/main/manifest.md).
- - A pull for a multi-arch image will count as one pull for each
-   different architecture.
+- A Docker pull includes both a version check and any download that
+  occurs as a result of the pull. Depending on the client, a `docker pull` can
+  verify the existence of an image or tag without downloading it by performing
+  a version check.
+- Version checks do not count towards usage pricing.
+- A pull for a normal image makes one pull for a [single
+  manifest](https://github.com/opencontainers/image-spec/blob/main/manifest.md).
+- A pull for a multi-arch image will count as one pull for each
+  different architecture.
 
 ## Pull attribution
 
 Pulls from authenticated users can be attributed to either a personal or an
-[organization namespace](/manuals/admin/faqs/general-faqs.md#whats-an-organization-name-or-namespace).
+[organization namespace](/manuals/accounts/general-faqs.md#whats-an-organization-name-or-namespace).
 
 Attribution is based on the following:
 
@@ -51,19 +51,18 @@ Attribution is based on the following:
   determined based on domain affiliation and organization membership.
 - Verified domain ownership: When pulling an image from an account linked to a
   verified domain, the attribution is set to be the owner of that
-  [domain](/manuals/security/faqs/single-sign-on/domain-faqs.md).
+  [domain](/manuals/enterprise/security/single-sign-on/faqs/domain-faqs.md).
 - Single organization membership:
-   - If the owner of the verified domain is a company and the user is part of
-     only one organization within that
-     [company](../../admin/faqs/company-faqs.md#what-features-are-supported-at-the-company-level),
-     the pull is attributed to that specific organization.
-   - If the user is part of only one organization, the pull is attributed to
-     that specific organization.
+  - If the owner of the verified domain is a company and the user is part of
+    only one organization within that
+    [company](../../admin/company/company-faqs.md),
+    the pull is attributed to that specific organization.
+  - If the user is part of only one organization, the pull is attributed to
+    that specific organization.
 - Multiple organization memberships: If the user is part of multiple
   organizations under the company, the pull is attributed to the user's personal
   namespace.
 
-
 ### Authentication
 
 To ensure correct attribution of your pulls, you must authenticate with Docker
@@ -82,15 +81,15 @@ the on-screen instructions to complete the sign-in process.
 
 If you're using a standalone version of Docker Engine, run the `docker login`
 command from a terminal to authenticate with Docker Hub. For information on how
-to use the command, see [docker login](/reference/cli/docker/login.md).
+to use the command, see [docker login](/reference/cli/docker/login/).
 
 #### Docker Swarm
 
 If you're running Docker Swarm, you must use the `--with-registry-auth` flag to
 authenticate with Docker Hub. For more information, see [Create a
-service](/reference/cli/docker/service/create.md#with-registry-auth). If you
+service](/reference/cli/docker/service/create/#with-registry-auth). If you
 are using a Docker Compose file to deploy an application stack, see [docker
-stack deploy](/reference/cli/docker/stack/deploy.md).
+stack deploy](/reference/cli/docker/stack/deploy/).
 
 #### GitHub Actions
 
@@ -120,9 +119,9 @@ If you're using any third-party platforms, follow your provider’s instructions
 - [Artifactory](https://www.jfrog.com/confluence/display/JFROG/Advanced+Settings#AdvancedSettings-RemoteCredentials)
 - [AWS CodeBuild](https://aws.amazon.com/blogs/devops/how-to-use-docker-images-from-a-private-registry-in-aws-codebuild-for-your-build-environment/)
 - [AWS ECS/Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html)
-- [Azure Pipelines](https://docs.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops&tabs=yaml#sep-docreg)
+- [Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops&tabs=yaml)
 - [Chipper CI](https://docs.chipperci.com/builds/docker/#rate-limit-auth)
-- [CircleCI](https://circleci.com/docs/2.0/private-images/)
+- [CircleCI](https://circleci.com/docs/guides/execution-managed/private-images/)
 - [Codefresh](https://codefresh.io/docs/docs/docker-registries/external-docker-registries/docker-hub/)
 - [Drone.io](https://docs.drone.io/pipeline/docker/syntax/images/#pulling-private-images)
 - [GitLab](https://docs.gitlab.com/ee/user/packages/container_registry/#authenticate-with-the-container-registry)
@@ -137,7 +136,7 @@ On that page, you can also send a report to your email that contains a comma
 separated file with the following detailed information.
 
 | CSV column           | Definition                                                                                                                                                                                                         | Usage guidance                                                                                                                                                                      |
-|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `datehour`           | The date and hour (`yyyy/mm/dd/hh`) of the pull that resulted in the data transfer.                                                                                                                                | This helps in identifying peak usage times and patterns.                                                                                                                            |
 | `user_name`          | The Docker ID of the user that pulled the image                                                                                                                                                                    | This lets organization owners track data consumption per user and manage resources effectively.                                                                                     |
 | `repository`         | The name of the repository of the image that was pulled.                                                                                                                                                           | This lets you identify which repositories are most frequently accessed and consume most of the data transfer.                                                                       |
@@ -147,7 +146,7 @@ separated file with the following detailed information.
 | `tag`                | The tag for the image. The tag is only available if the pull included a tag.                                                                                                                                       | This helps in identifying the image. Tags are often used to identify specific versions or variants of an image.                                                                     |
 | `digest`             | The unique image digest for the image.                                                                                                                                                                             | This helps in identifying the image.                                                                                                                                                |
 | `version_checks`     | The number of version checks accumulated for the date and hour of each image repository. Depending on the client, a pull can do a version check to verify the existence of an image or tag without downloading it. | This helps identify the frequency of version checks, which you can use to analyze usage trends and potential unexpected behaviors.                                                  |
-| `pulls`              | The number of pulls accumulated for the date and hour of each image repository.                                                                                                                                            | This helps identify the frequency of repository pulls, which you can use to analyze usage trends and potential unexpected behaviors.                                                |
+| `pulls`              | The number of pulls accumulated for the date and hour of each image repository.                                                                                                                                    | This helps identify the frequency of repository pulls, which you can use to analyze usage trends and potential unexpected behaviors.                                                |
 
 ## View pull rate and limit
 
@@ -169,28 +168,26 @@ To view your current pull rate and limit:
 
 > [!NOTE]
 >
-> To check your limits, you need `curl`, `grep`, and `jq` installed.
+> To check your limits, you need `curl` and `jq` installed.
 
 1. Get a token.
-
    - To get a token anonymously, if you are pulling anonymously:
 
-      ```console
-      $ TOKEN=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token)
-      ```
+     ```console
+     $ TOKEN=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token)
+     ```
 
    - To get a token with a user account, if you are authenticated, insert your
      username and password in the following command:
 
-      ```console
-      $ TOKEN=$(curl --user 'username:password' "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token)
-      ```
+     ```console
+     $ TOKEN=$(curl --user 'username:password' "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token)
+     ```
 
 2. Get the headers that contain your limits. These headers are returned on both
    GET and HEAD requests. Using GET emulates a real pull and counts towards the
    limit. Using HEAD won't.
 
-
    ```console
    $ curl --head -H "Authorization: Bearer $TOKEN" https://registry-1.docker.io/v2/ratelimitpreview/test/manifests/latest
    ```
@@ -209,6 +206,5 @@ To view your current pull rate and limit:
    If you don't see any `ratelimit` header, it could be because the image or your IP
    is unlimited in partnership with a publisher, provider, or an open source
    organization. It could also mean that the user you are pulling as is part of a
-   paid Docker plan. Pulling that image won't count toward pull rate limits if you
+   paid Docker subscription. Pulling that image won't count toward pull rate limits if you
    don't see these headers.
-
diff --git a/content/manuals/engine/_index.md b/content/manuals/engine/_index.md
index febf3717d814..2b4acc814fe3 100644
--- a/content/manuals/engine/_index.md
+++ b/content/manuals/engine/_index.md
@@ -5,43 +5,43 @@ description: Find a comprehensive overview of Docker Engine, including how to in
 keywords: Engine
 params:
   sidebar:
-    group: Open source
+    group: Application development
 grid:
 - title: Install Docker Engine
   description: Learn how to install the open source Docker Engine for your distribution.
-  icon: download
+  icon: arrow-down-tray
   link: /engine/install
 - title: Storage
   description: Use persistent data with Docker containers.
-  icon: database
+  icon: circle-stack
   link: /storage
 - title: Networking
   description: Manage network connections between containers.
-  icon: network_node
+  icon: server-stack
   link: /network
 - title: Container logs
   description: Learn how to view and read container logs.
-  icon: text_snippet
+  icon: document-text
   link: /config/containers/logging/
 - title: Prune
   description: Tidy up unused resources.
-  icon: content_cut
+  icon: scissors
   link: /config/pruning
 - title: Configure the daemon
   description: Delve into the configuration options of the Docker daemon.
-  icon: tune
+  icon: adjustments-horizontal
   link: /config/daemon
 - title: Rootless mode
   description: Run Docker without root privileges.
-  icon: security
+  icon: shield-check
   link: /engine/security/rootless
 - title: Deprecated features
   description: Find out what features of Docker Engine you should stop using.
-  icon: folder_delete
+  icon: folder-minus
   link: /engine/deprecated/
 - title: Release notes
   description: Read the release notes for the latest version.
-  icon: note_add
+  icon: document-plus
   link: /engine/release-notes
 aliases:
 - /edge/
@@ -74,8 +74,7 @@ For more details, see
 
 ## Licensing
 
-The Docker Engine is licensed under the Apache License, Version 2.0. See
-[LICENSE](https://github.com/moby/moby/blob/master/LICENSE) for the full license
-text. 
-
-However, for commercial use of Docker Engine obtained via Docker Desktop within larger enterprises (exceeding 250 employees OR with annual revenue surpassing $10 million USD), a [paid subscription](https://www.docker.com/pricing/) is required.
+Commercial use of Docker Engine obtained via Docker Desktop
+within larger enterprises (exceeding 250 employees OR with annual revenue surpassing
+$10 million USD), requires a [paid subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsEngine).
+Apache License, Version 2.0. See [LICENSE](https://github.com/moby/moby/blob/master/LICENSE) for the full license.
diff --git a/content/manuals/engine/cli/filter.md b/content/manuals/engine/cli/filter.md
index e51fb633470f..9943a400956a 100644
--- a/content/manuals/engine/cli/filter.md
+++ b/content/manuals/engine/cli/filter.md
@@ -30,15 +30,15 @@ output of the `docker images` command to only print `alpine` images.
 ```console
 $ docker images
 REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
-ubuntu       20.04     33a5cc25d22c   36 minutes ago   101MB
-ubuntu       18.04     152dc042452c   36 minutes ago   88.1MB
-alpine       3.16      a8cbb8c69ee7   40 minutes ago   8.67MB
+ubuntu       24.04     33a5cc25d22c   36 minutes ago   101MB
+ubuntu       22.04     152dc042452c   36 minutes ago   88.1MB
+alpine       3.21      a8cbb8c69ee7   40 minutes ago   8.67MB
 alpine       latest    7144f7bab3d4   40 minutes ago   11.7MB
 busybox      uclibc    3e516f71d880   48 minutes ago   2.4MB
 busybox      glibc     7338d0c72c65   48 minutes ago   6.09MB
 $ docker images --filter reference=alpine
 REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
-alpine       3.16      a8cbb8c69ee7   40 minutes ago   8.67MB
+alpine       3.21      a8cbb8c69ee7   40 minutes ago   8.67MB
 alpine       latest    7144f7bab3d4   40 minutes ago   11.7MB
 ```
 
@@ -58,9 +58,9 @@ following example shows how to print all images that match `alpine:latest` or
 ```console
 $ docker images
 REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
-ubuntu       20.04     33a5cc25d22c   2 hours ago   101MB
-ubuntu       18.04     152dc042452c   2 hours ago   88.1MB
-alpine       3.16      a8cbb8c69ee7   2 hours ago   8.67MB
+ubuntu       24.04     33a5cc25d22c   2 hours ago   101MB
+ubuntu       22.04     152dc042452c   2 hours ago   88.1MB
+alpine       3.21      a8cbb8c69ee7   2 hours ago   8.67MB
 alpine       latest    7144f7bab3d4   2 hours ago   11.7MB
 busybox      uclibc    3e516f71d880   2 hours ago   2.4MB
 busybox      glibc     7338d0c72c65   2 hours ago   6.09MB
@@ -95,21 +95,21 @@ $ docker container prune --filter "label!=foo" --filter "label!=bar"
 For more information about filtering commands, refer to the CLI reference
 description for commands that support the `--filter` flag:
 
-- [`docker config ls`](/reference/cli/docker/config/ls.md)
-- [`docker container prune`](/reference/cli/docker/container/prune.md)
-- [`docker image prune`](/reference/cli/docker/image/prune.md)
-- [`docker image ls`](/reference/cli/docker/image/ls.md)
-- [`docker network ls`](/reference/cli/docker/network/ls.md)
-- [`docker network prune`](/reference/cli/docker/network/prune.md)
-- [`docker node ls`](/reference/cli/docker/node/ls.md)
-- [`docker node ps`](/reference/cli/docker/node/ps.md)
-- [`docker plugin ls`](/reference/cli/docker/plugin/ls.md)
-- [`docker container ls`](/reference/cli/docker/container/ls.md)
-- [`docker search`](/reference/cli/docker/search.md)
-- [`docker secret ls`](/reference/cli/docker/secret/ls.md)
-- [`docker service ls`](/reference/cli/docker/service/ls.md)
-- [`docker service ps`](/reference/cli/docker/service/ps.md)
-- [`docker stack ps`](/reference/cli/docker/stack/ps.md)
-- [`docker system prune`](/reference/cli/docker/system/prune.md)
-- [`docker volume ls`](/reference/cli/docker/volume/ls.md)
-- [`docker volume prune`](/reference/cli/docker/volume/prune.md)
+- [`docker config ls`](/reference/cli/docker/config/ls/)
+- [`docker container prune`](/reference/cli/docker/container/prune/)
+- [`docker image prune`](/reference/cli/docker/image/prune/)
+- [`docker image ls`](/reference/cli/docker/image/ls/)
+- [`docker network ls`](/reference/cli/docker/network/ls/)
+- [`docker network prune`](/reference/cli/docker/network/prune/)
+- [`docker node ls`](/reference/cli/docker/node/ls/)
+- [`docker node ps`](/reference/cli/docker/node/ps/)
+- [`docker plugin ls`](/reference/cli/docker/plugin/ls/)
+- [`docker container ls`](/reference/cli/docker/container/ls/)
+- [`docker search`](/reference/cli/docker/search/)
+- [`docker secret ls`](/reference/cli/docker/secret/ls/)
+- [`docker service ls`](/reference/cli/docker/service/ls/)
+- [`docker service ps`](/reference/cli/docker/service/ps/)
+- [`docker stack ps`](/reference/cli/docker/stack/ps/)
+- [`docker system prune`](/reference/cli/docker/system/prune/)
+- [`docker volume ls`](/reference/cli/docker/volume/ls/)
+- [`docker volume prune`](/reference/cli/docker/volume/prune/)
diff --git a/content/manuals/engine/cli/formatting.md b/content/manuals/engine/cli/formatting.md
index ad20c8c1cd9b..498785c4c8ef 100644
--- a/content/manuals/engine/cli/formatting.md
+++ b/content/manuals/engine/cli/formatting.md
@@ -18,7 +18,7 @@ include examples of customizing the output format.
 
 > [!NOTE]
 >
-> When using the `--format` flag, you need observe your shell environment.
+> When using the `--format` flag, you need to observe your shell environment.
 > In a POSIX shell, you can run the following with a single quote:
 >
 > ```console
@@ -110,7 +110,7 @@ $ docker image list --format '{{truncate .Repository 15}}'
 
 This example displays the image repository name, truncating it to the first 15 characters if it's longer.
 
-## println
+## `println`
 
 `println` prints each value on a new line.
 
diff --git a/content/manuals/engine/cli/otel.md b/content/manuals/engine/cli/otel.md
index 8ec3bbf88b70..0a75441211dd 100644
--- a/content/manuals/engine/cli/otel.md
+++ b/content/manuals/engine/cli/otel.md
@@ -155,7 +155,7 @@ With these files in place:
 
 ## Available metrics
 
-Docker CLI currently exports a single metric, `command.time`, which measures
+Docker CLI exports a single metric, `command.time`, which measures
 the execution duration of a command in milliseconds. This metric has the
 following attributes:
 
diff --git a/content/manuals/engine/containers/gpu.md b/content/manuals/engine/containers/gpu.md
new file mode 100644
index 000000000000..09d73d4d5683
--- /dev/null
+++ b/content/manuals/engine/containers/gpu.md
@@ -0,0 +1,112 @@
+---
+title: GPU access
+weight: 40
+description: How to access NVIDIA GPUs from a container
+keywords: docker, GPU, NVIDIA, cuda, nvidia-smi, device, container toolkit
+---
+
+## Access an NVIDIA GPU
+
+### Prerequisites
+
+Visit the official [NVIDIA drivers page](https://www.nvidia.com/Download/index.aspx)
+to download and install the proper drivers. Reboot your system once you have
+done so.
+
+Verify that your GPU is running and accessible.
+
+### Install NVIDIA Container Toolkit
+
+Follow the official NVIDIA Container Toolkit [installation instructions](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html).
+
+### Expose GPUs for use
+
+Include the `--gpus` flag when you start a container to access GPU resources.
+
+To expose all available GPUs:
+
+```console
+$ docker run -it --rm --gpus all ubuntu nvidia-smi
+```
+
+The output looks like the following:
+
+```text
++---------------------------------------------------------------------------------------+
+| NVIDIA-SMI 535.288.01             Driver Version: 535.288.01   CUDA Version: 12.2     |
+|-----------------------------------------+----------------------+----------------------+
+| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
+| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
+|                                         |                      |               MIG M. |
+|=========================================+======================+======================|
+|   0  NVIDIA L4                      Off | 00000000:31:00.0 Off |                    0 |
+| N/A   40C    P0              27W /  72W |      0MiB / 23034MiB |      4%      Default |
+|                                         |                      |                  N/A |
++-----------------------------------------+----------------------+----------------------+
+
++---------------------------------------------------------------------------------------+
+| Processes:                                                                            |
+|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
+|        ID   ID                                                             Usage      |
+|=======================================================================================|
+|  No running processes found                                                           |
++---------------------------------------------------------------------------------------+
+```
+
+The leftmost column in the GPU table shows the index of each GPU (`0` for the
+NVIDIA L4 in the previous example). Use these index numbers to target specific GPUs
+with the `device` option.
+
+To expose a single GPU by index:
+
+```console
+$ docker run -it --rm --gpus device=0 ubuntu nvidia-smi
+```
+
+To expose a GPU by its UUID, first list UUIDs with `nvidia-smi -L`:
+
+```console
+$ nvidia-smi -L
+GPU 0: NVIDIA L4 (UUID: GPU-3a23c669-1f69-c64e-cf85-44e9b07e7a2a)
+```
+
+Then pass the UUID to `--gpus`:
+
+```console
+$ docker run -it --rm --gpus device=GPU-3a23c669-1f69-c64e-cf85-44e9b07e7a2a ubuntu nvidia-smi
+```
+
+On systems with multiple GPUs, you can expose several by index. The `device`
+value must be quoted because it contains a comma:
+
+```console
+$ docker run -it --rm --gpus '"device=0,2"' ubuntu nvidia-smi
+```
+
+This exposes the GPUs at index `0` and `2` — the first and third GPUs listed in
+`nvidia-smi` output.
+
+> [!NOTE]
+>
+> NVIDIA GPUs can only be accessed by systems running a single engine.
+
+### Set NVIDIA capabilities
+
+You can set capabilities manually. For example, on Ubuntu you can run the
+following:
+
+```console
+$ docker run --gpus 'all,capabilities=utility' --rm ubuntu nvidia-smi
+```
+
+This enables the `utility` driver capability which adds the `nvidia-smi` tool to
+the container.
+
+Capabilities and other configurations can be set in images via environment
+variables. For valid variables, see the
+[nvidia-container-toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html)
+documentation. These variables can be set in a Dockerfile.
+
+You can also use CUDA images, which set these variables automatically. See the
+official [CUDA images](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda)
+NGC catalog page.
diff --git a/content/manuals/engine/containers/resource_constraints.md b/content/manuals/engine/containers/resource_constraints.md
index 09e04a4a37e4..b8cc7b9dae5e 100644
--- a/content/manuals/engine/containers/resource_constraints.md
+++ b/content/manuals/engine/containers/resource_constraints.md
@@ -1,8 +1,8 @@
 ---
 title: Resource constraints
 weight: 30
-description: Specify the runtime options for a container
-keywords: docker, daemon, configuration, runtime
+description: Limit container memory and CPU usage with runtime configuration flags
+keywords: resource constraints, memory limits, CPU limits, cgroups, OOM, swap, docker run, memory swap
 aliases:
   - /engine/admin/resource_constraints/
   - /config/containers/resource_constraints/
@@ -16,7 +16,7 @@ on when you should set such limits and the possible implications of setting them
 
 Many of these features require your kernel to support Linux capabilities. To
 check for support, you can use the
-[`docker info`](/reference/cli/docker/system/info.md) command. If a capability
+[`docker info`](/reference/cli/docker/system/info/) command. If a capability
 is disabled in your kernel, you may see a warning at the end of the output like
 the following:
 
@@ -69,8 +69,8 @@ You can mitigate the risk of system instability due to OOME by:
 
 Docker can enforce hard or soft memory limits.
 
-- Hard limits lets the container use no more than a fixed amount of memory.
-- Soft limits lets the container use as much memory as it needs unless certain
+- Hard limits let the container use no more than a fixed amount of memory.
+- Soft limits let the container use as much memory as it needs unless certain
   conditions are met, such as when the kernel detects low memory or contention on
   the host machine.
 
@@ -86,7 +86,6 @@ Most of these options take a positive integer, followed by a suffix of `b`, `k`,
 | `--memory-swap`\*      | The amount of memory this container is allowed to swap to disk. See [`--memory-swap` details](#--memory-swap-details).                                                                                                                                                                                                                                                                          |
 | `--memory-swappiness`  | By default, the host kernel can swap out a percentage of anonymous pages used by a container. You can set `--memory-swappiness` to a value between 0 and 100, to tune this percentage. See [`--memory-swappiness` details](#--memory-swappiness-details).                                                                                                                                       |
 | `--memory-reservation` | Allows you to specify a soft limit smaller than `--memory` which is activated when Docker detects contention or low memory on the host machine. If you use `--memory-reservation`, it must be set lower than `--memory` for it to take precedence. Because it is a soft limit, it doesn't guarantee that the container doesn't exceed the limit.                                                |
-| `--kernel-memory`      | The maximum amount of kernel memory the container can use. The minimum allowed value is `6m`. Because kernel memory can't be swapped out, a container which is starved of kernel memory may block host machine resources, which can have side effects on the host machine and on other containers. See [`--kernel-memory` details](#--kernel-memory-details).                                   |
 | `--oom-kill-disable`   | By default, if an out-of-memory (OOM) error occurs, the kernel kills processes in a container. To change this behavior, use the `--oom-kill-disable` option. Only disable the OOM killer on containers where you have also set the `-m/--memory` option. If the `-m` flag isn't set, the host can run out of memory and the kernel may need to kill the host system's processes to free memory. |
 
 For more information about cgroups and memory in general, see the documentation
@@ -116,7 +115,7 @@ Its setting can have complicated effects:
   [Prevent a container from using swap](#prevent-a-container-from-using-swap).
 
 - If `--memory-swap` is unset, and `--memory` is set, the container can use
-  as much swap as the `--memory` setting, if the host container has swap
+  as much swap as the `--memory` setting, if the host has swap
   memory configured. For instance, if `--memory="300m"` and `--memory-swap` is
   not set, the container can use 600m in total of memory and swap.
 
@@ -139,34 +138,6 @@ of physical memory that can be used.
 - By default, if you don't set `--memory-swappiness`, the value is
   inherited from the host machine.
 
-### `--kernel-memory` details
-
-Kernel memory limits are expressed in terms of the overall memory allocated to
-a container. Consider the following scenarios:
-
-- **Unlimited memory, unlimited kernel memory**: This is the default
-  behavior.
-- **Unlimited memory, limited kernel memory**: This is appropriate when the
-  amount of memory needed by all cgroups is greater than the amount of
-  memory that actually exists on the host machine. You can configure the
-  kernel memory to never go over what's available on the host machine,
-  and containers which need more memory need to wait for it.
-- **Limited memory, unlimited kernel memory**: The overall memory is
-  limited, but the kernel memory isn't.
-- **Limited memory, limited kernel memory**: Limiting both user and kernel
-  memory can be useful for debugging memory-related problems. If a container
-  is using an unexpected amount of either type of memory, it runs out
-  of memory without affecting other containers or the host machine. Within
-  this setting, if the kernel memory limit is lower than the user memory
-  limit, running out of kernel memory causes the container to experience
-  an OOM error. If the kernel memory limit is higher than the user memory
-  limit, the kernel limit doesn't cause the container to experience an OOM.
-
-When you enable kernel memory limits, the host machine tracks "high water mark"
-statistics on a per-process basis, so you can track which processes (in this
-case, containers) are using excess memory. This can be seen per process by
-viewing `/proc/<PID>/status` on the host machine.
-
 ## CPU
 
 By default, each container's access to the host machine's CPU cycles is unlimited.
@@ -186,7 +157,7 @@ the container's cgroup on the host machine.
 | :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `--cpus=<value>`       | Specify how much of the available CPU resources a container can use. For instance, if the host machine has two CPUs and you set `--cpus="1.5"`, the container is guaranteed at most one and a half of the CPUs. This is the equivalent of setting `--cpu-period="100000"` and `--cpu-quota="150000"`.                                                                                                                                                                                                                                                                                              |
 | `--cpu-period=<value>` | Specify the CPU CFS scheduler period, which is used alongside `--cpu-quota`. Defaults to 100000 microseconds (100 milliseconds). Most users don't change this from the default. For most use-cases, `--cpus` is a more convenient alternative.                                                                                                                                                                                                                                                                                                                                                     |
-| `--cpu-quota=<value>`  | Impose a CPU CFS quota on the container. The number of microseconds per `--cpu-period` that the container is limited to before throttled. As such acting as the effective ceiling. For most use-cases, `--cpus` is a more convenient alternative.                                                                                                                                                                                                                                                                                                                                                  |
+| `--cpu-quota=<value>`  | Impose a CPU CFS quota on the container. The number of microseconds per `--cpu-period` that the container is limited to before being throttled. As such acting as the effective ceiling. For most use-cases, `--cpus` is a more convenient alternative.                                                                                                                                                                                                                                                                                                                                                  |
 | `--cpuset-cpus`        | Limit the specific CPUs or cores a container can use. A comma-separated list or hyphen-separated range of CPUs a container can use, if you have more than one CPU. The first CPU is numbered 0. A valid value might be `0-3` (to use the first, second, third, and fourth CPU) or `1,3` (to use the second and fourth CPU).                                                                                                                                                                                                                                                                        |
 | `--cpu-shares`         | Set this flag to a value greater or less than the default of 1024 to increase or reduce the container's weight, and give it access to a greater or lesser proportion of the host machine's CPU cycles. This is only enforced when CPU cycles are constrained. When plenty of CPU cycles are available, all containers use as much CPU as they need. In that way, this is a soft limit. `--cpu-shares` doesn't prevent containers from being scheduled in Swarm mode. It prioritizes container CPU resources for the available CPU cycles. It doesn't guarantee or reserve any specific CPU access. |
 
@@ -234,7 +205,7 @@ for real-time tasks per runtime period. For instance, with the default period of
 containers using the real-time scheduler can run for 950000 microseconds for every
 1000000-microsecond period, leaving at least 50000 microseconds available for
 non-real-time tasks. To make this configuration permanent on systems which use
-`systemd`, create a systemd unit file for the `docker` service. For an example,
+`systemd`, create a systemd unit file for the `docker` service. For example,
 see the instruction on how to configure the daemon to use a proxy with a
 [systemd unit file](../daemon/proxy.md#systemd-unit-file).
 
@@ -265,84 +236,5 @@ If the kernel or Docker daemon isn't configured correctly, an error occurs.
 
 ## GPU
 
-### Access an NVIDIA GPU
-
-#### Prerequisites
-
-Visit the official [NVIDIA drivers page](https://www.nvidia.com/Download/index.aspx)
-to download and install the proper drivers. Reboot your system once you have
-done so.
-
-Verify that your GPU is running and accessible.
-
-#### Install nvidia-container-toolkit
-
-Follow the official NVIDIA Container Toolkit [installation instructions](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html).
-
-#### Expose GPUs for use
-
-Include the `--gpus` flag when you start a container to access GPU resources.
-Specify how many GPUs to use. For example:
-
-```console
-$ docker run -it --rm --gpus all ubuntu nvidia-smi
-```
-
-Exposes all available GPUs and returns a result akin to the following:
-
-```bash
-+-------------------------------------------------------------------------------+
-| NVIDIA-SMI 384.130            	Driver Version: 384.130               	|
-|-------------------------------+----------------------+------------------------+
-| GPU  Name 	   Persistence-M| Bus-Id    	Disp.A | Volatile Uncorr. ECC   |
-| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M.   |
-|===============================+======================+========================|
-|   0  GRID K520       	Off  | 00000000:00:03.0 Off |                  N/A      |
-| N/A   36C	P0    39W / 125W |  	0MiB /  4036MiB |      0%  	Default |
-+-------------------------------+----------------------+------------------------+
-+-------------------------------------------------------------------------------+
-| Processes:                                                       GPU Memory   |
-|  GPU   	PID   Type   Process name                         	Usage  	|
-|===============================================================================|
-|  No running processes found                                                   |
-+-------------------------------------------------------------------------------+
-```
-
-Use the `device` option to specify GPUs. For example:
-
-```console
-$ docker run -it --rm --gpus device=GPU-3a23c669-1f69-c64e-cf85-44e9b07e7a2a ubuntu nvidia-smi
-```
-
-Exposes that specific GPU.
-
-```console
-$ docker run -it --rm --gpus '"device=0,2"' ubuntu nvidia-smi
-```
-
-Exposes the first and third GPUs.
-
-> [!NOTE]
->
-> NVIDIA GPUs can only be accessed by systems running a single engine.
-
-#### Set NVIDIA capabilities
-
-You can set capabilities manually. For example, on Ubuntu you can run the
-following:
-
-```console
-$ docker run --gpus 'all,capabilities=utility' --rm ubuntu nvidia-smi
-```
-
-This enables the `utility` driver capability which adds the `nvidia-smi` tool to
-the container.
-
-Capabilities as well as other configurations can be set in images via
-environment variables. More information on valid variables can be found in the
-[nvidia-container-toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html)
-documentation. These variables can be set in a Dockerfile.
-
-You can also use CUDA images which sets these variables automatically. See the
-official [CUDA images](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda)
-NGC catalog page.
+For information on how to access NVIDIA GPUs from a container, see
+[GPU access](gpu.md).
diff --git a/content/manuals/engine/containers/runmetrics.md b/content/manuals/engine/containers/runmetrics.md
index 22a9f3ba466f..6078bd8a4536 100644
--- a/content/manuals/engine/containers/runmetrics.md
+++ b/content/manuals/engine/containers/runmetrics.md
@@ -27,7 +27,7 @@ redis1              0.07%               796 KB / 64 MB        1.21%
 redis2              0.07%               2.746 MB / 64 MB      4.29%               1.266 KB / 648 B    12.4 MB / 0 B
 ```
 
-The [`docker stats`](/reference/cli/docker/container/stats.md) reference
+The [`docker stats`](/reference/cli/docker/container/stats/) reference
 page has more details about the `docker stats` command.
 
 ## Control groups
@@ -68,6 +68,14 @@ cgroup v2 is used by default on the following distributions:
 - Debian GNU/Linux (since 11)
 - Ubuntu (since 21.10)
 
+> [!IMPORTANT]
+>
+> The detailed metrics examples later in this page describe the cgroup v1 file
+> layout. On cgroup v2 hosts, use this page to find the container's cgroup
+> directory and then inspect the controller files in that directory (for
+> example, `memory.*`, `cpu.*`, and `io.*`). For controller semantics, refer to
+> the [cgroup v2 kernel documentation](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html).
+
 #### cgroup v1
 
 You can look into `/proc/cgroups` to see the different control group subsystems
@@ -114,7 +122,7 @@ Note that the cgroup v2 mode behaves slightly different from the cgroup v1 mode:
 
 - The default cgroup driver (`dockerd --exec-opt native.cgroupdriver`) is `systemd` on v2, `cgroupfs` on v1.
 - The default cgroup namespace mode (`docker run --cgroupns`) is `private` on v2, `host` on v1.
-- The `docker run` flags `--oom-kill-disable` and `--kernel-memory` are discarded on v2.
+- The `docker run` flag `--oom-kill-disable` is discarded on v2.
 
 ### Find the cgroup for a given container
 
@@ -137,12 +145,14 @@ container, take a look at the following paths:
 - `/sys/fs/cgroup/docker/<longid>/` on cgroup v2, `cgroupfs` driver
 - `/sys/fs/cgroup/system.slice/docker-<longid>.scope/` on cgroup v2, `systemd` driver
 
-### Metrics from cgroups: memory, CPU, block I/O
+### Metrics from cgroups: memory, CPU, block I/O (cgroup v1)
 
 > [!NOTE]
 >
-> This section isn't yet updated for cgroup v2.
-> For further information about cgroup v2, refer to [the kernel documentation](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html).
+> This section documents the cgroup v1 metric files and formats.
+> For cgroup v2, inspect the relevant controller files in the container's
+> cgroup directory and refer to
+> [the kernel documentation](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html).
 
 For each subsystem (memory, CPU, and block I/O), one or
 more pseudo-files exist and contain statistics.
@@ -200,74 +210,72 @@ indicates the number of page faults since the creation of the cgroup.
 
 `cache`
 : The amount of memory used by the processes of this control group that can be
-  associated precisely with a block on a block device. When you read from and
-  write to files on disk, this amount increases. This is the case if you use
-  "conventional" I/O (`open`, `read`, `write` syscalls) as well as mapped files
-  (with `mmap`). It also accounts for the memory used by `tmpfs` mounts, though
-  the reasons are unclear.
+associated precisely with a block on a block device. When you read from and
+write to files on disk, this amount increases. This is the case if you use
+"conventional" I/O (`open`, `read`, `write` syscalls) as well as mapped files
+(with `mmap`). It also accounts for the memory used by `tmpfs` mounts, though
+the reasons are unclear.
 
 `rss`
 : The amount of memory that doesn't correspond to anything on disk: stacks,
-  heaps, and anonymous memory maps.
+heaps, and anonymous memory maps.
 
 `mapped_file`
 : Indicates the amount of memory mapped by the processes in the control group.
-  It doesn't give you information about how much memory is used; it rather
-  tells you how it's used.
+It doesn't give you information about how much memory is used; it rather
+tells you how it's used.
 
 `pgfault`, `pgmajfault`
 : Indicate the number of times that a process of the cgroup triggered a "page
-  fault" and a "major fault", respectively. A page fault happens when a process
-  accesses a part of its virtual memory space which is nonexistent or protected.
-  The former can happen if the process is buggy and tries to access an invalid
-  address (it is sent a `SIGSEGV` signal, typically killing it with the famous
-  `Segmentation fault` message). The latter can happen when the process reads
-  from a memory zone which has been swapped out, or which corresponds to a mapped
-  file: in that case, the kernel loads the page from disk, and let the CPU
-  complete the memory access. It can also happen when the process writes to a
-  copy-on-write memory zone: likewise, the kernel preempts the process, duplicate
-  the memory page, and resume the write operation on the process's own copy of
-  the page. "Major" faults happen when the kernel actually needs to read the data
-  from disk. When it just duplicates an existing page, or allocate an empty page,
-  it's a regular (or "minor") fault.
+fault" and a "major fault", respectively. A page fault happens when a process
+accesses a virtual memory page that is not currently mapped to a physical
+memory frame. This is a normal part of memory management. For example, a page
+fault occurs when the process reads from a memory zone that has been swapped
+out, or that corresponds to a memory-mapped file: in that case, the kernel
+loads the page from disk and lets the CPU complete the memory access. It also
+happens when the process writes to a copy-on-write memory zone: the kernel
+duplicates the memory page and resumes the write operation on the process's
+own copy of the page. "Major" faults happen when the kernel needs to read
+data from disk. When it duplicates an existing page, or allocates an empty
+page, it's a regular (or "minor") fault.
 
 `swap`
 : The amount of swap currently used by the processes in this cgroup.
 
 `active_anon`, `inactive_anon`
 : The amount of anonymous memory that has been identified has respectively
-  _active_ and _inactive_ by the kernel. "Anonymous" memory is the memory that is
-  _not_ linked to disk pages. In other words, that's the equivalent of the rss
-  counter described above. In fact, the very definition of the rss counter is
-  `active_anon` + `inactive_anon` - `tmpfs` (where tmpfs is the amount of
-  memory used up by `tmpfs` filesystems mounted by this control group). Now,
-  what's the difference between "active" and "inactive"? Pages are initially
-  "active"; and at regular intervals, the kernel sweeps over the memory, and tags
-  some pages as "inactive". Whenever they're accessed again, they're
-  immediately re-tagged "active". When the kernel is almost out of memory, and
-  time comes to swap out to disk, the kernel swaps "inactive" pages.
+_active_ and _inactive_ by the kernel. "Anonymous" memory is the memory that is
+_not_ linked to disk pages. In other words, that's the equivalent of the rss
+counter described above. In fact, the very definition of the rss counter is
+`active_anon` + `inactive_anon` - `tmpfs` (where tmpfs is the amount of
+memory used up by `tmpfs` filesystems mounted by this control group). Now,
+what's the difference between "active" and "inactive"? Pages are initially
+"active"; and at regular intervals, the kernel sweeps over the memory, and tags
+some pages as "inactive". Whenever they're accessed again, they're
+immediately re-tagged "active". When the kernel is almost out of memory, and
+time comes to swap out to disk, the kernel swaps "inactive" pages.
 
 `active_file`, `inactive_file`
 : Cache memory, with _active_ and _inactive_ similar to the _anon_ memory
-  above. The exact formula is `cache` = `active_file` + `inactive_file` +
-  `tmpfs`. The exact rules used by the kernel to move memory pages between
-  active and inactive sets are different from the ones used for anonymous memory,
-  but the general principle is the same. When the kernel needs to reclaim memory,
-  it's cheaper to reclaim a clean (=non modified) page from this pool, since it
-  can be reclaimed immediately (while anonymous pages and dirty/modified pages
-  need to be written to disk first).
+above. The exact formula is `cache` = `active_file` + `inactive_file` +
+`tmpfs`. The exact rules used by the kernel to move memory pages between
+active and inactive sets are different from the ones used for anonymous memory,
+but the general principle is the same. When the kernel needs to reclaim memory,
+it's cheaper to reclaim a clean (=non modified) page from this pool, since it
+can be reclaimed immediately (while anonymous pages and dirty/modified pages
+need to be written to disk first).
 
 `unevictable`
 : The amount of memory that cannot be reclaimed; generally, it accounts for
-  memory that has been "locked" with `mlock`. It's often used by crypto
-  frameworks to make sure that secret keys and other sensitive material never
-  gets swapped out to disk.
+memory that has been "locked" with `mlock`. It's often used by crypto
+frameworks to make sure that secret keys and other sensitive material never
+gets swapped out to disk.
 
 `memory_limit`, `memsw_limit`
 : These aren't really metrics, but a reminder of the limits applied to this
-  cgroup. The first one indicates the maximum amount of physical memory that can
-  be used by the processes of this control group; the second one indicates the
-  maximum amount of RAM+swap.
+cgroup. The first one indicates the maximum amount of physical memory that can
+be used by the processes of this control group; the second one indicates the
+maximum amount of RAM+swap.
 
 Accounting for memory in the page cache is very complex. If two
 processes in different control groups both read the same file
@@ -309,28 +317,28 @@ relevant ones:
 
 `blkio.sectors`
 : Contains the number of 512-bytes sectors read and written by the processes
-  member of the cgroup, device by device. Reads and writes are merged in a single
-  counter.
+member of the cgroup, device by device. Reads and writes are merged in a single
+counter.
 
 `blkio.io_service_bytes`
 : Indicates the number of bytes read and written by the cgroup. It has 4
-  counters per device, because for each device, it differentiates between
-  synchronous vs. asynchronous I/O, and reads vs. writes.
+counters per device, because for each device, it differentiates between
+synchronous vs. asynchronous I/O, and reads vs. writes.
 
 `blkio.io_serviced`
 : The number of I/O operations performed, regardless of their size. It also has
-  4 counters per device.
+4 counters per device.
 
 `blkio.io_queued`
 : Indicates the number of I/O operations currently queued for this cgroup. In
-  other words, if the cgroup isn't doing any I/O, this is zero. The opposite is
-  not true. In other words, if there is no I/O queued, it doesn't mean that the
-  cgroup is idle (I/O-wise). It could be doing purely synchronous reads on an
-  otherwise quiescent device, which can therefore handle them immediately,
-  without queuing. Also, while it's helpful to figure out which cgroup is
-  putting stress on the I/O subsystem, keep in mind that it's a relative
-  quantity. Even if a process group doesn't perform more I/O, its queue size can
-  increase just because the device load increases because of other devices.
+other words, if the cgroup isn't doing any I/O, this is zero. The opposite is
+not true. In other words, if there is no I/O queued, it doesn't mean that the
+cgroup is idle (I/O-wise). It could be doing purely synchronous reads on an
+otherwise quiescent device, which can therefore handle them immediately,
+without queuing. Also, while it's helpful to figure out which cgroup is
+putting stress on the I/O subsystem, keep in mind that it's a relative
+quantity. Even if a process group doesn't perform more I/O, its queue size can
+increase just because the device load increases because of other devices.
 
 ### Network metrics
 
diff --git a/content/manuals/engine/containers/start-containers-automatically.md b/content/manuals/engine/containers/start-containers-automatically.md
index 213ae635c54a..79bcf9493769 100644
--- a/content/manuals/engine/containers/start-containers-automatically.md
+++ b/content/manuals/engine/containers/start-containers-automatically.md
@@ -10,19 +10,19 @@ aliases:
   - /config/containers/start-containers-automatically/
 ---
 
-Docker provides [restart policies](/manuals/engine/containers/run.md#restart-policies---restart)
+Docker provides [restart policies](/reference/cli/docker/container/run/#restart)
 to control whether your containers start automatically when they exit, or when
-Docker restarts. Restart policies start linked containers in the correct order.
+Docker restarts.
 Docker recommends that you use restart policies, and avoid using process
 managers to start containers.
 
 Restart policies are different from the `--live-restore` flag of the `dockerd`
-command. Using `--live-restore` lets you to keep your containers running during
+command. Using `--live-restore` lets you keep your containers running during
 a Docker upgrade, though networking and user input are interrupted.
 
 ## Use a restart policy
 
-To configure the restart policy for a container, use the `--restart` flag
+To configure the restart policy for a container, use the [`--restart`](/reference/cli/docker/container/run/#restart) flag
 when using the `docker run` command. The value of the `--restart` flag can be
 any of the following:
 
@@ -33,11 +33,12 @@ any of the following:
 | `always`                   | Always restart the container if it stops. If it's manually stopped, it's restarted only when Docker daemon restarts or the container itself is manually restarted. (See the second bullet listed in [restart policy details](#restart-policy-details))                                                                                                                |
 | `unless-stopped`           | Similar to `always`, except that when the container is stopped (manually or otherwise), it isn't restarted even after Docker daemon restarts.                                                                                                                                                                                                                         |
 
-The following command starts a Redis container and configures it to always
-restart, unless the container is explicitly stopped, or the daemon restarts.
+The following command starts a Redis container with the `unless-stopped`
+restart policy. Docker restarts the container if it exits or if the daemon
+restarts, but not if you stopped the container yourself.
 
 ```console
-$ docker run -d --restart unless-stopped redis
+$ docker run -d --name redis --restart unless-stopped redis
 ```
 
 The following command changes the restart policy for an already running
@@ -68,7 +69,7 @@ Keep the following in mind when using restart policies:
 
 - Restart policies only apply to containers. To configure restart policies for
   Swarm services, see
-  [flags related to service restart](/reference/cli/docker/service/create.md).
+  [flags related to service restart](/reference/cli/docker/service/create/).
 
 ### Restarting foreground containers
 
diff --git a/content/manuals/engine/daemon/_index.md b/content/manuals/engine/daemon/_index.md
index 3b1ee08307a0..fa9f30362b11 100644
--- a/content/manuals/engine/daemon/_index.md
+++ b/content/manuals/engine/daemon/_index.md
@@ -84,6 +84,33 @@ $ dockerd --debug \
   --host tcp://192.168.59.3:2376
 ```
 
+#### Listen on a Unix socket on Windows
+
+Starting with Docker Engine 29.5, you can configure `dockerd` on Windows to
+listen on a Unix socket. This setting is optional. The default Windows endpoint
+remains the `npipe` named pipe.
+
+Run `dockerd` from an elevated PowerShell session:
+
+```powershell
+PS C:\> dockerd -H unix://C:/Users/<USER>/docker.sock --group docker-users
+```
+
+Replace `<USER>` with the name of your Windows user profile directory.
+Without `--group`, only members of the Administrators group and the `SYSTEM`
+account can access the socket. Use a comma-separated list to grant access to
+multiple users or groups.
+
+Use a path in the user profile when granting access with `--group`. A socket
+created directly under `C:\` can inherit a high integrity level that blocks
+access for the configured users and groups.
+
+Configure the Docker client to use the same socket:
+
+```powershell
+PS C:\> docker -H unix://C:/Users/<USER>/docker.sock info
+```
+
 Learn about the available configuration options in the
 [dockerd reference docs](/reference/cli/dockerd.md), or by
 running:
@@ -98,13 +125,24 @@ The Docker daemon persists all data in a single directory. This tracks
 everything related to Docker, including containers, images, volumes, service
 definition, and secrets.
 
-By default this directory is:
+By default the daemon stores data in:
+
+- `/var/lib/docker` on Linux
+- `C:\ProgramData\docker` on Windows
+
+When using the [containerd image store](/manuals/engine/storage/containerd.md)
+(the default for Docker Engine 29.0 and later on fresh installations), image
+contents and container snapshots are stored in `/var/lib/containerd`. Other
+daemon data (volumes, configs) remains in `/var/lib/docker`.
 
-- `/var/lib/docker` on Linux.
-- `C:\ProgramData\docker` on Windows.
+When using [classic storage drivers](/manuals/engine/storage/drivers/_index.md)
+like `overlay2` (the default for upgraded installations), all data is stored in
+`/var/lib/docker`.
 
-You can configure the Docker daemon to use a different directory, using the
-`data-root` configuration option. For example:
+### Configure the data directory location
+
+You can configure the Docker daemon to use a different storage directory using
+the `data-root` configuration option.
 
 ```json
 {
@@ -112,10 +150,19 @@ You can configure the Docker daemon to use a different directory, using the
 }
 ```
 
-Since the state of a Docker daemon is kept on this directory, make sure you use
-a dedicated directory for each daemon. If two daemons share the same directory,
-for example, an NFS share, you are going to experience errors that are difficult
-to troubleshoot.
+The `data-root` option does not affect image and container data stored in
+`/var/lib/containerd` when using the containerd image store. To change the
+storage location of containerd snapshotters, use the system containerd
+configuration file:
+
+```toml {title="/etc/containerd/config.toml"}
+version = 2
+root = "/mnt/containerd-data"
+```
+
+Make sure you use a dedicated directory for each daemon. If two daemons share
+the same directory, for example an NFS share, you will experience errors that
+are difficult to troubleshoot.
 
 ## Next steps
 
diff --git a/content/manuals/engine/daemon/ipv6.md b/content/manuals/engine/daemon/ipv6.md
index 1ed5ca00b058..df7041aab87b 100644
--- a/content/manuals/engine/daemon/ipv6.md
+++ b/content/manuals/engine/daemon/ipv6.md
@@ -35,6 +35,13 @@ IPv6 is only supported on Docker daemons running on Linux hosts.
            - subnet: 2001:db8::/64
   ```
 
+> [!NOTE]
+>
+> The address `2001:db8::/64` in these examples is
+> [reserved for use in documentation][wikipedia-ipv6-reserved].
+> Replace it with a valid IPv6 network, for example a
+> [Unique Local Address (ULA)][wikipedia-ipv6-ula] subnet from `fd00::/8`.
+
 You can now run containers that attach to the `ip6net` network.
 
 ```console
@@ -74,6 +81,13 @@ The following steps show you how to use IPv6 on the default bridge network.
    }
    ```
 
+   > [!NOTE]
+   >
+   > The address `2001:db8:1::/64` in this example is
+   > [reserved for use in documentation][wikipedia-ipv6-reserved].
+   > Replace it with a valid IPv6 network, for example a
+   > [Unique Local Address (ULA)][wikipedia-ipv6-ula] subnet from `fd00::/8`.
+
    - `ipv6` enables IPv6 networking on the default network.
    - `fixed-cidr-v6` assigns a subnet to the default bridge network,
      enabling dynamic IPv6 address allocation.
@@ -126,42 +140,24 @@ will be used when IPv6 is enabled. These `/64` subnets include a 40-bit
 Global ID based on the Docker Engine's randomly generated ID, to give a
 high probability of uniqueness.
 
+The built-in default address pool configuration is shown in [Subnet allocation](../network/_index.md#subnet-allocation).
+It does not include any IPv6 pools.
+
 To use different pools of IPv6 subnets for dynamic address allocation,
 you must manually configure address pools of the daemon to include:
 
 - The default IPv4 address pools
 - One or more IPv6 pools of your own
 
-The default address pool configuration is:
+The following example shows a valid configuration with IPv4 and IPv6 pools,
+both pools provide 256 subnets. IPv4 subnets with prefix length `/24` will
+be allocated from a `/16` pool. IPv6 subnets with prefix length `/64` will
+be allocated from a `/56` pool.
 
 ```json
 {
   "default-address-pools": [
-    { "base": "172.17.0.0/16", "size": 16 },
-    { "base": "172.18.0.0/16", "size": 16 },
-    { "base": "172.19.0.0/16", "size": 16 },
-    { "base": "172.20.0.0/14", "size": 16 },
-    { "base": "172.24.0.0/14", "size": 16 },
-    { "base": "172.28.0.0/14", "size": 16 },
-    { "base": "192.168.0.0/16", "size": 20 }
-  ]
-}
-```
-
-The following example shows a valid configuration with the default values and
-an IPv6 pool. The IPv6 pool in the example provides up to 256 IPv6 subnets of
-size `/64`, from an IPv6 pool of prefix length `/56`.
-
-```json
-{
-  "default-address-pools": [
-    { "base": "172.17.0.0/16", "size": 16 },
-    { "base": "172.18.0.0/16", "size": 16 },
-    { "base": "172.19.0.0/16", "size": 16 },
-    { "base": "172.20.0.0/14", "size": 16 },
-    { "base": "172.24.0.0/14", "size": 16 },
-    { "base": "172.28.0.0/14", "size": 16 },
-    { "base": "192.168.0.0/16", "size": 20 },
+    { "base": "172.17.0.0/16", "size": 24 },
     { "base": "2001:db8::/56", "size": 64 }
   ]
 }
@@ -176,6 +172,9 @@ size `/64`, from an IPv6 pool of prefix length `/56`.
 > The default IPv4 pools are from the private address range,
 > similar to the default IPv6 [ULA][wikipedia-ipv6-ula] networks.
 
+See [Subnet allocation](../network/_index.md#subnet-allocation) for more information about
+`default-address-pools`.
+
 [wikipedia-ipv6-reserved]: https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv6
 [wikipedia-ipv6-ula]: https://en.wikipedia.org/wiki/Unique_local_address
 
diff --git a/content/manuals/engine/daemon/live-restore.md b/content/manuals/engine/daemon/live-restore.md
index 264afacf5c4e..ab27f50ec509 100644
--- a/content/manuals/engine/daemon/live-restore.md
+++ b/content/manuals/engine/daemon/live-restore.md
@@ -4,8 +4,9 @@ keywords: docker, upgrade, daemon, dockerd, live-restore, daemonless container
 title: Live restore
 weight: 40
 aliases:
-  - /engine/admin/live-restore/
   - /config/containers/live-restore/
+  - /engine/admin/live-restore/
+  - /engine/containers/live-restore/
 ---
 
 By default, when the Docker daemon terminates, it shuts down running containers.
diff --git a/content/manuals/engine/daemon/logs.md b/content/manuals/engine/daemon/logs.md
index 0b09f3e8e3b0..e5f810820944 100644
--- a/content/manuals/engine/daemon/logs.md
+++ b/content/manuals/engine/daemon/logs.md
@@ -1,7 +1,7 @@
 ---
 title: Read the daemon logs
-description: How to read the event logs for the Docker daemon
-keywords: docker, daemon, configuration, troubleshooting, logging
+description: How to read Docker daemon logs and force a stack trace using SIGUSR1 for debugging
+keywords: docker, daemon, configuration, troubleshooting, logging, debug, stack trace, SIGUSR1, signal, goroutine dump, crash diagnostics
 aliases:
   - /config/daemon/logs/
 ---
@@ -10,31 +10,33 @@ The daemon logs may help you diagnose problems. The logs may be saved in one of
 a few locations, depending on the operating system configuration and the logging
 subsystem used:
 
-| Operating system                   | Location                                                                                                                                 |
-| :--------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------- |
-| Linux                              | Use the command `journalctl -xu docker.service` (or read `/var/log/syslog` or `/var/log/messages`, depending on your Linux Distribution) |
-| macOS (`dockerd` logs)             | `~/Library/Containers/com.docker.docker/Data/log/vm/dockerd.log`                                                                         |
-| macOS (`containerd` logs)          | `~/Library/Containers/com.docker.docker/Data/log/vm/containerd.log`                                                                      |
-| Windows (WSL2) (`dockerd` logs)    | `%LOCALAPPDATA%\Docker\log\vm\dockerd.log`                                                                                               |
-| Windows (WSL2) (`containerd` logs) | `%LOCALAPPDATA%\Docker\log\vm\containerd.log`                                                                                            |
-| Windows (Windows containers)       | Logs are in the Windows Event Log                                                                                                        |
+| Operating system             | Location                                                                                                                                 |
+| :--------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------- |
+| Linux                        | Use the command `journalctl -xu docker.service` (or read `/var/log/syslog` or `/var/log/messages`, depending on your Linux Distribution) |
+| macOS (Docker Desktop)       | `~/Library/Containers/com.docker.docker/Data/log/vm/init.log`                                                                            |
+| Windows (WSL2)               | `%LOCALAPPDATA%\Docker\log\vm\init.log`                                                                                                  |
+| Windows (Windows containers) | Logs are in the Windows Event Log                                                                                                        |
 
-To view the `dockerd` logs on macOS, open a terminal Window, and use the `tail`
-command with the `-f` flag to "follow" the logs. Logs will be printed until you
-terminate the command using `CTRL+c`:
+On macOS and Windows (WSL2), Docker Desktop writes daemon logs (`dockerd`,
+`containerd`, and other VM services) to a single multiplexed `init.log` file
+in JSON format. Each line contains a `"component"` field identifying the
+service. To follow the logs, open a terminal and use the `tail` command with
+the `-f` flag. Logs print until you terminate the command using `CTRL+c`:
 
 ```console
-$ tail -f ~/Library/Containers/com.docker.docker/Data/log/vm/dockerd.log
-2021-07-28T10:21:21Z dockerd time="2021-07-28T10:21:21.497642089Z" level=debug msg="attach: stdout: begin"
-2021-07-28T10:21:21Z dockerd time="2021-07-28T10:21:21.497714291Z" level=debug msg="attach: stderr: begin"
-2021-07-28T10:21:21Z dockerd time="2021-07-28T10:21:21.499798390Z" level=debug msg="Calling POST /v1.41/containers/35fc5ec0ffe1ad492d0a4fbf51fd6286a087b89d4dd66367fa3b7aec70b46a40/wait?condition=removed"
-2021-07-28T10:21:21Z dockerd time="2021-07-28T10:21:21.518403686Z" level=debug msg="Calling GET /v1.41/containers/35fc5ec0ffe1ad492d0a4fbf51fd6286a087b89d4dd66367fa3b7aec70b46a40/json"
-2021-07-28T10:21:21Z dockerd time="2021-07-28T10:21:21.527074928Z" level=debug msg="Calling POST /v1.41/containers/35fc5ec0ffe1ad492d0a4fbf51fd6286a087b89d4dd66367fa3b7aec70b46a40/start"
-2021-07-28T10:21:21Z dockerd time="2021-07-28T10:21:21.528203579Z" level=debug msg="container mounted via layerStore: &{/var/lib/docker/overlay2/6e76ffecede030507fcaa576404e141e5f87fc4d7e1760e9ce5b52acb24
+$ tail -f ~/Library/Containers/com.docker.docker/Data/log/vm/init.log
+{"component":"dockerd","level":"debug","msg":"attach: stdout: begin","time":"2021-07-28T10:21:21.497642089Z"}
+{"component":"dockerd","level":"debug","msg":"attach: stderr: begin","time":"2021-07-28T10:21:21.497714291Z"}
 ...
 ^C
 ```
 
+To filter for `dockerd` output only:
+
+```console
+$ grep '"component":"dockerd"' ~/Library/Containers/com.docker.docker/Data/log/vm/init.log
+```
+
 ## Enable debugging
 
 There are two ways to enable debugging. The recommended approach is to set the
@@ -117,7 +119,7 @@ The Docker daemon log can be viewed by using one of the following methods:
 
 Look in the Docker logs for a message like the following:
 
-```none
+```text
 ...goroutine stacks written to /var/run/docker/goroutine-stacks-2017-06-02T193336z.log
 ```
 
diff --git a/content/manuals/engine/daemon/proxy.md b/content/manuals/engine/daemon/proxy.md
index d2a4a7ebfe2d..5f3ff0f609f7 100644
--- a/content/manuals/engine/daemon/proxy.md
+++ b/content/manuals/engine/daemon/proxy.md
@@ -45,7 +45,7 @@ or using CLI flags for the `--http-proxy` or `--https-proxy` flags for the
 {
   "proxies": {
     "http-proxy": "http://proxy.example.com:3128",
-    "https-proxy": "https://proxy.example.com:3129",
+    "https-proxy": "http://proxy.example.com:3128",
     "no-proxy": "*.test.example.com,.example.org,127.0.0.0/8"
   }
 }
@@ -101,21 +101,21 @@ systemd drop-in file that sets the variables for the `docker` service.
    Environment="HTTP_PROXY=http://proxy.example.com:3128"
    ```
 
-   If you are behind an HTTPS proxy server, set the `HTTPS_PROXY` environment
+   To proxy HTTPS requests, set the `HTTPS_PROXY` environment
    variable:
 
    ```systemd
    [Service]
-   Environment="HTTPS_PROXY=https://proxy.example.com:3129"
+   Environment="HTTPS_PROXY=http://proxy.example.com:3128"
    ```
 
-   Multiple environment variables can be set; to set both a non-HTTPS and a
-   HTTPs proxy;
+   Multiple environment variables can be set; to set both an HTTP and an
+   HTTPS proxy;
 
    ```systemd
    [Service]
    Environment="HTTP_PROXY=http://proxy.example.com:3128"
-   Environment="HTTPS_PROXY=https://proxy.example.com:3129"
+   Environment="HTTPS_PROXY=http://proxy.example.com:3128"
    ```
 
    > [!NOTE]
@@ -134,7 +134,6 @@ systemd drop-in file that sets the variables for the `docker` service.
    The `NO_PROXY` variable specifies a string that contains comma-separated
    values for hosts that should be excluded from proxying. These are the options
    you can specify to exclude hosts:
-
    - IP address prefix (`1.2.3.4`)
    - Domain name, or a special DNS label (`*`)
    - A domain name matches that name and all subdomains. A domain name with a
@@ -151,7 +150,7 @@ systemd drop-in file that sets the variables for the `docker` service.
    ```systemd
    [Service]
    Environment="HTTP_PROXY=http://proxy.example.com:3128"
-   Environment="HTTPS_PROXY=https://proxy.example.com:3129"
+   Environment="HTTPS_PROXY=http://proxy.example.com:3128"
    Environment="NO_PROXY=localhost,127.0.0.1,docker-registry.example.com,.corp"
    ```
 
@@ -168,7 +167,7 @@ systemd drop-in file that sets the variables for the `docker` service.
    ```console
    $ sudo systemctl show --property=Environment docker
 
-   Environment=HTTP_PROXY=http://proxy.example.com:3128 HTTPS_PROXY=https://proxy.example.com:3129 NO_PROXY=localhost,127.0.0.1,docker-registry.example.com,.corp
+   Environment=HTTP_PROXY=http://proxy.example.com:3128 HTTPS_PROXY=http://proxy.example.com:3128 NO_PROXY=localhost,127.0.0.1,docker-registry.example.com,.corp
    ```
 
 {{< /tab >}}
@@ -188,21 +187,21 @@ systemd drop-in file that sets the variables for the `docker` service.
    Environment="HTTP_PROXY=http://proxy.example.com:3128"
    ```
 
-   If you are behind an HTTPS proxy server, set the `HTTPS_PROXY` environment
+   To proxy HTTPS requests, set the `HTTPS_PROXY` environment
    variable:
 
    ```systemd
    [Service]
-   Environment="HTTPS_PROXY=https://proxy.example.com:3129"
+   Environment="HTTPS_PROXY=http://proxy.example.com:3128"
    ```
 
-   Multiple environment variables can be set; to set both a non-HTTPS and a
-   HTTPs proxy;
+   Multiple environment variables can be set; to set both an HTTP and an
+   HTTPS proxy;
 
    ```systemd
    [Service]
    Environment="HTTP_PROXY=http://proxy.example.com:3128"
-   Environment="HTTPS_PROXY=https://proxy.example.com:3129"
+   Environment="HTTPS_PROXY=http://proxy.example.com:3128"
    ```
 
    > [!NOTE]
@@ -221,7 +220,6 @@ systemd drop-in file that sets the variables for the `docker` service.
    The `NO_PROXY` variable specifies a string that contains comma-separated
    values for hosts that should be excluded from proxying. These are the options
    you can specify to exclude hosts:
-
    - IP address prefix (`1.2.3.4`)
    - Domain name, or a special DNS label (`*`)
    - A domain name matches that name and all subdomains. A domain name with a
@@ -238,7 +236,7 @@ systemd drop-in file that sets the variables for the `docker` service.
    ```systemd
    [Service]
    Environment="HTTP_PROXY=http://proxy.example.com:3128"
-   Environment="HTTPS_PROXY=https://proxy.example.com:3129"
+   Environment="HTTPS_PROXY=http://proxy.example.com:3128"
    Environment="NO_PROXY=localhost,127.0.0.1,docker-registry.example.com,.corp"
    ```
 
@@ -255,7 +253,7 @@ systemd drop-in file that sets the variables for the `docker` service.
    ```console
    $ systemctl --user show --property=Environment docker
 
-   Environment=HTTP_PROXY=http://proxy.example.com:3128 HTTPS_PROXY=https://proxy.example.com:3129 NO_PROXY=localhost,127.0.0.1,docker-registry.example.com,.corp
+   Environment=HTTP_PROXY=http://proxy.example.com:3128 HTTPS_PROXY=http://proxy.example.com:3128 NO_PROXY=localhost,127.0.0.1,docker-registry.example.com,.corp
    ```
 
 {{< /tab >}}
diff --git a/content/manuals/engine/daemon/troubleshoot.md b/content/manuals/engine/daemon/troubleshoot.md
index 7b68c88fb04a..770b2db6179d 100644
--- a/content/manuals/engine/daemon/troubleshoot.md
+++ b/content/manuals/engine/daemon/troubleshoot.md
@@ -545,7 +545,7 @@ all other running containers as filesystems within the container which mounts
 `/var/lib/docker/`. When you attempt to remove any of these containers, the
 removal attempt may fail with an error like the following:
 
-```none
+```text
 Error: Unable to remove filesystem for
 74bef250361c7817bee19349c93139621b272bc8f654ae112dd4eb9652af9515:
 remove /var/lib/docker/containers/74bef250361c7817bee19349c93139621b272bc8f654ae112dd4eb9652af9515/shm:
diff --git a/content/manuals/engine/install/_index.md b/content/manuals/engine/install/_index.md
index cf03b08c40ae..5b30fd279b62 100644
--- a/content/manuals/engine/install/_index.md
+++ b/content/manuals/engine/install/_index.md
@@ -31,6 +31,21 @@ aliases:
 - /engine/installation/oracle/
 - /enterprise/supported-platforms/
 - /install/linux/docker-ee/oracle/
+- /ee/docker-ee/sles/
+- /ee/docker-ee/suse/
+- /engine/installation/linux/docker-ce/sles/
+- /engine/installation/linux/docker-ee/sles/
+- /engine/installation/linux/docker-ee/suse/
+- /engine/installation/linux/sles/
+- /engine/installation/linux/SUSE/
+- /engine/installation/linux/suse/
+- /engine/installation/sles/
+- /engine/installation/SUSE/
+- /install/linux/docker-ce/sles/
+- /install/linux/docker-ee/sles/
+- /install/linux/docker-ee/suse/
+- /install/linux/sles/
+- /installation/sles/
 ---
 
 This section describes how to install Docker Engine on Linux, also known as
@@ -38,16 +53,17 @@ Docker CE. Docker Engine is also available for Windows, macOS, and Linux,
 through Docker Desktop. For instructions on how to install Docker Desktop,
 see: [Overview of Docker Desktop](/manuals/desktop/_index.md).
 
-## Supported platforms
+## Installation procedures for supported platforms
+
+Click on a platform's link to view the relevant installation procedure.
 
 | Platform                                       | x86_64 / amd64 | arm64 / aarch64 | arm (32-bit) | ppc64le | s390x |
 | :--------------------------------------------- | :------------: | :-------------: | :----------: | :-----: | :---: |
 | [CentOS](centos.md)                            |       ✅       |       ✅        |              |   ✅    |       |
 | [Debian](debian.md)                            |       ✅       |       ✅        |      ✅      |   ✅    |       |
 | [Fedora](fedora.md)                            |       ✅       |       ✅        |              |   ✅    |       |
-| [Raspberry Pi OS (32-bit)](raspberry-pi-os.md) |                |                 |      ✅      |         |       |
+| [Raspberry Pi OS (32-bit)](raspberry-pi-os.md) |                |                 |      ⚠️      |         |       |
 | [RHEL](rhel.md)                                |       ✅       |       ✅        |              |         |  ✅   |
-| [SLES](sles.md)                                |                |                 |              |         |  ✅   |
 | [Ubuntu](ubuntu.md)                            |       ✅       |       ✅        |      ✅      |   ✅    |  ✅   |
 | [Binaries](binaries.md)                        |       ✅       |       ✅        |      ✅      |         |       |
 
@@ -58,7 +74,7 @@ see: [Overview of Docker Desktop](/manuals/desktop/_index.md).
 > While the following instructions may work, Docker doesn't test or verify
 > installation on distribution derivatives.
 
-- If you use Debian derivatives such as "BunsenLabs Linux", "Kali Linux" or 
+- If you use Debian derivatives such as "BunsenLabs Linux", "Kali Linux" or
   "LMDE" (Debian-based Mint) should follow the installation instructions for
   [Debian](debian.md), substitute the version of your distribution for the
   corresponding Debian release. Refer to the documentation of your distribution to find
@@ -105,9 +121,10 @@ Patch releases are always backward compatible with its major and minor version.
 
 ### Licensing
 
-Docker Engine is licensed under the Apache License, Version 2.0. See
-[LICENSE](https://github.com/moby/moby/blob/master/LICENSE) for the full
-license text.
+Commercial use of Docker Engine obtained via Docker Desktop
+within larger enterprises (exceeding 250 employees OR with annual revenue surpassing
+$10 million USD), requires a [paid subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsEngineInstall).
+Apache License, Version 2.0. See [LICENSE](https://github.com/moby/moby/blob/master/LICENSE) for the full license.
 
 ## Reporting security issues
 
diff --git a/content/manuals/engine/install/centos.md b/content/manuals/engine/install/centos.md
index d01ae2aaef41..90d6212e97b0 100644
--- a/content/manuals/engine/install/centos.md
+++ b/content/manuals/engine/install/centos.md
@@ -29,7 +29,8 @@ To get started with Docker Engine on CentOS, make sure you
 To install Docker Engine, you need a maintained version of one of the following
 CentOS versions:
 
-- CentOS 9 (stream)
+- CentOS Stream 10
+- CentOS Stream 9
 
 The `centos-extras` repository must be enabled. This repository is enabled by
 default. If you have disabled it, you need to re-enable it.
@@ -75,6 +76,8 @@ You can install Docker Engine in different ways, depending on your needs:
 - In testing and development environments, you can use automated
   [convenience scripts](#install-using-the-convenience-script) to install Docker.
 
+{{% include "engine-license.md" %}}
+
 ### Install using the rpm repository {#install-using-the-repository}
 
 Before you install Docker Engine for the first time on a new host machine, you
diff --git a/content/manuals/engine/install/debian.md b/content/manuals/engine/install/debian.md
index 1ed65408d891..895925ed34df 100644
--- a/content/manuals/engine/install/debian.md
+++ b/content/manuals/engine/install/debian.md
@@ -39,14 +39,14 @@ To get started with Docker Engine on Debian, make sure you
 
 ### OS requirements
 
-To install Docker Engine, you need the 64-bit version of one of these Debian
-versions:
+To install Docker Engine, you need one of these Debian versions:
 
-- Debian Bookworm 12 (stable)
-- Debian Bullseye 11 (oldstable)
+- Debian Trixie 13 (stable)
+- Debian Bookworm 12 (oldstable)
+- Debian Bullseye 11 (oldoldstable)
 
-Docker Engine for Debian is compatible with x86_64 (or amd64), armhf, arm64,
-and ppc64le (ppc64el) architectures.
+Docker Engine for Debian is compatible with x86_64 (or amd64), armhf (arm/v7),
+arm64, and ppc64le (ppc64el) architectures.
 
 ### Uninstall old versions
 
@@ -61,6 +61,7 @@ The unofficial packages to uninstall are:
 - `docker.io`
 - `docker-compose`
 - `docker-doc`
+- `docker-buildx`
 - `podman-docker`
 
 Moreover, Docker Engine depends on `containerd` and `runc`. Docker Engine
@@ -71,10 +72,10 @@ conflicts with the versions bundled with Docker Engine.
 Run the following command to uninstall all conflicting packages:
 
 ```console
-$ for pkg in docker.io docker-doc docker-compose podman-docker containerd runc; do sudo apt-get remove $pkg; done
+$ sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-doc docker-buildx podman-docker containerd runc | cut -f1)
 ```
 
-`apt-get` might report that you have none of these packages installed.
+`apt` might report that you have none of these packages installed.
 
 Images, containers, volumes, and networks stored in `/var/lib/docker/` aren't
 automatically removed when you uninstall Docker. If you want to start with a
@@ -97,6 +98,8 @@ You can install Docker Engine in different ways, depending on your needs:
 - Use a [convenience script](#install-using-the-convenience-script). Only
   recommended for testing and development environments.
 
+{{% include "engine-license.md" %}}
+
 ### Install using the `apt` repository {#install-using-the-repository}
 
 Before you install Docker Engine for the first time on a new host machine, you
@@ -107,23 +110,28 @@ Docker from the repository.
 
    ```bash
    # Add Docker's official GPG key:
-   sudo apt-get update
-   sudo apt-get install ca-certificates curl
+   sudo apt update
+   sudo apt install ca-certificates curl
    sudo install -m 0755 -d /etc/apt/keyrings
    sudo curl -fsSL {{% param "download-url-base" %}}/gpg -o /etc/apt/keyrings/docker.asc
    sudo chmod a+r /etc/apt/keyrings/docker.asc
 
    # Add the repository to Apt sources:
-   echo \
-     "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] {{% param "download-url-base" %}} \
-     $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
-     sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
-   sudo apt-get update
+   sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
+   Types: deb
+   URIs: {{% param "download-url-base" %}}
+   Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
+   Components: stable
+   Architectures: $(dpkg --print-architecture)
+   Signed-By: /etc/apt/keyrings/docker.asc
+   EOF
+
+   sudo apt update
    ```
 
    > [!NOTE]
    >
-   > If you use a derivative distribution, such as Kali Linux,
+   > If you use Debian testing or a derivative distribution such as Kali Linux,
    > you may need to substitute the part of this command that's expected to
    > print the version codename:
    >
@@ -132,7 +140,7 @@ Docker from the repository.
    > ```
    >
    > Replace this part with the codename of the corresponding Debian release,
-   > such as `bookworm`.
+   > such as `trixie`.
 
 2. Install the Docker packages.
 
@@ -142,9 +150,9 @@ Docker from the repository.
    To install the latest version, run:
 
    ```console
-   $ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+   $ sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
    ```
-  
+
    {{< /tab >}}
    {{< tab name="Specific version" >}}
 
@@ -152,11 +160,10 @@ Docker from the repository.
    available versions in the repository:
 
    ```console
-   # List the available versions:
-   $ apt-cache madison docker-ce | awk '{ print $3 }'
+   $ apt list --all-versions docker-ce
 
-   5:{{% param "docker_ce_version" %}}-1~debian.12~bookworm
-   5:{{% param "docker_ce_version_prev" %}}-1~debian.12~bookworm
+   docker-ce/bookworm 5:{{% param "docker_ce_version" %}}-1~debian.12~bookworm <arch>
+   docker-ce/bookworm 5:{{% param "docker_ce_version_prev" %}}-1~debian.12~bookworm <arch>
    ...
    ```
 
@@ -164,12 +171,26 @@ Docker from the repository.
 
    ```console
    $ VERSION_STRING=5:{{% param "docker_ce_version" %}}-1~debian.12~bookworm
-   $ sudo apt-get install docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-buildx-plugin docker-compose-plugin
+   $ sudo apt install docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-buildx-plugin docker-compose-plugin
    ```
 
    {{< /tab >}}
    {{< /tabs >}}
 
+    > [!NOTE]
+    >
+    > After installation, verify that Docker is running:
+    >
+    > ```console
+    > $ sudo systemctl status docker
+    > ```
+    >
+    > If Docker is not running, start it manually:
+    >
+    > ```console
+    > $ sudo systemctl start docker
+    > ```
+
 3. Verify that the installation is successful by running the `hello-world` image:
 
    ```console
@@ -223,12 +244,23 @@ download a new file each time you want to upgrade Docker Engine.
      ./docker-compose-plugin_<version>_<arch>.deb
    ```
 
-   The Docker daemon starts automatically.
+    > [!NOTE]
+    >
+    > After installation, verify that Docker is running:
+    >
+    > ```console
+    > $ sudo systemctl status docker
+    > ```
+    >
+    > If Docker is not running, start it manually:
+    >
+    > ```console
+    > $ sudo systemctl start docker
+    > ```
 
 6. Verify that the installation is successful by running the `hello-world` image:
 
    ```console
-   $ sudo service docker start
    $ sudo docker run hello-world
    ```
 
@@ -251,7 +283,7 @@ To upgrade Docker Engine, download the newer package files and repeat the
 1. Uninstall the Docker Engine, CLI, containerd, and Docker Compose packages:
 
    ```console
-   $ sudo apt-get purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras
+   $ sudo apt purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras
    ```
 
 2. Images, containers, volumes, or custom configuration files on your host
@@ -265,7 +297,7 @@ To upgrade Docker Engine, download the newer package files and repeat the
 3. Remove source list and keyrings
 
    ```console
-   $ sudo rm /etc/apt/sources.list.d/docker.list
+   $ sudo rm /etc/apt/sources.list.d/docker.sources
    $ sudo rm /etc/apt/keyrings/docker.asc
    ```
 
diff --git a/content/manuals/engine/install/fedora.md b/content/manuals/engine/install/fedora.md
index 71a795db6ab0..9e9705ebcdfe 100644
--- a/content/manuals/engine/install/fedora.md
+++ b/content/manuals/engine/install/fedora.md
@@ -26,8 +26,8 @@ To get started with Docker Engine on Fedora, make sure you
 To install Docker Engine, you need a maintained version of one of the following
 Fedora versions:
 
-- Fedora 40
-- Fedora 41
+- Fedora 44
+- Fedora 43
 
 ### Uninstall old versions
 
@@ -72,6 +72,8 @@ You can install Docker Engine in different ways, depending on your needs:
 - In testing and development environments, you can use automated
   [convenience scripts](#install-using-the-convenience-script) to install Docker.
 
+{{% include "engine-license.md" %}}
+
 ### Install using the rpm repository {#install-using-the-repository}
 
 Before you install Docker Engine for the first time on a new host machine, you
@@ -80,12 +82,8 @@ Docker from the repository.
 
 #### Set up the repository
 
-Install the `dnf-plugins-core` package (which provides the commands to manage
-your DNF repositories) and set up the repository.
-
 ```console
-$ sudo dnf -y install dnf-plugins-core
-$ sudo dnf-3 config-manager --add-repo {{% param "download-url-base" %}}/docker-ce.repo
+$ sudo dnf config-manager addrepo --from-repofile {{% param "download-url-base" %}}/docker-ce.repo
 ```
 
 #### Install Docker Engine
@@ -151,6 +149,17 @@ $ sudo dnf-3 config-manager --add-repo {{% param "download-url-base" %}}/docker-
    boot your system. If you don't want Docker to start automatically, use `sudo
    systemctl start docker` instead.
 
+   > [!NOTE]
+   >
+   > If the Docker service fails to start and `journalctl -u docker`
+   > shows `failed to find iptables`, point the `iptables` command to
+   > `iptables-nft` using `alternatives` and restart the service:
+   >
+   > ```console
+   > $ sudo alternatives --set iptables /usr/bin/iptables-nft
+   > $ sudo systemctl restart docker
+   > ```
+
 3. Verify that the installation is successful by running the `hello-world` image:
 
    ```console
@@ -200,6 +209,17 @@ download a new file each time you want to upgrade Docker Engine.
    boot your system. If you don't want Docker to start automatically, use `sudo
    systemctl start docker` instead.
 
+   > [!NOTE]
+   >
+   > If the Docker service fails to start and `journalctl -u docker`
+   > shows `failed to find iptables`, point the `iptables` command to
+   > `iptables-nft` using `alternatives` and restart the service:
+   >
+   > ```console
+   > $ sudo alternatives --set iptables /usr/bin/iptables-nft
+   > $ sudo systemctl restart docker
+   > ```
+
 4. Verify that the installation is successful by running the `hello-world` image:
 
    ```console
diff --git a/content/manuals/engine/install/linux-postinstall.md b/content/manuals/engine/install/linux-postinstall.md
index 443185d632fc..7509a4eaed54 100644
--- a/content/manuals/engine/install/linux-postinstall.md
+++ b/content/manuals/engine/install/linux-postinstall.md
@@ -78,7 +78,7 @@ To create the `docker` group and add your user:
    If you initially ran Docker CLI commands using `sudo` before adding your user
    to the `docker` group, you may see the following error:
 
-   ```none
+   ```text
    WARNING: Error loading config file: /home/user/.docker/config.json -
    stat /home/user/.docker/config.json: permission denied
    ```
@@ -141,4 +141,4 @@ options:
 
 ## Next steps
 
-- Take a look at the [Docker workshop](/get-started/workshop/_index.md) to learn how to build an image and run it as a containerized application.
+- Take a look at [Get started with Docker](/get-started/introduction/_index.md) to learn how to build an image and run it as a containerized application.
diff --git a/content/manuals/engine/install/raspberry-pi-os.md b/content/manuals/engine/install/raspberry-pi-os.md
index 1399c73ce073..0593541a5192 100644
--- a/content/manuals/engine/install/raspberry-pi-os.md
+++ b/content/manuals/engine/install/raspberry-pi-os.md
@@ -1,10 +1,10 @@
 ---
 description: Learn how to install Docker Engine on a 32-bit Raspberry Pi OS system. These instructions cover
-  the different installation methods, how to uninstall, and next steps.
+  the different installation methods, how to uninstall, and next steps. Note that 32-bit support will be deprecated in Docker Engine v29 and later.
 keywords: requirements, apt, installation, install docker engine, Raspberry Pi OS, install, uninstall, upgrade,
-  update
-title: Install Docker Engine on Raspberry Pi OS (32-bit)
-linkTitle: Raspberry Pi OS (32-bit)
+  update, deprecated
+title: Install Docker Engine on Raspberry Pi OS (32-bit / armhf)
+linkTitle: Raspberry Pi OS (32-bit / armhf) 
 weight: 50
 toc_max: 4
 aliases:
@@ -13,6 +13,22 @@ aliases:
 download-url-base: https://download.docker.com/linux/raspbian
 ---
 
+> [!WARNING]
+>
+> **Raspberry Pi OS 32-bit (armhf) Deprecation**
+>
+> Docker Engine v28 will be the last major version to support Raspberry Pi OS 32-bit (armhf).
+> Starting with Docker Engine v29, new major versions will no longer provide packages for Raspberry Pi OS 32-bit (armhf).
+>
+> **Migration options**
+> - **64-bit ARM:** Install the Debian `arm64` packages (fully supported). See the
+>   [Debian installation instructions](debian.md).
+> - **32-bit ARM (v7):** Install the Debian `armhf` packages (targets ARMv7 CPUs).
+>
+> **Note:** Older devices based on the ARMv6 architecture are no longer supported by official packages, including:
+> - Raspberry Pi 1 (Model A/B/A+/B+)
+> - Raspberry Pi Zero and Zero W
+
 To get started with Docker Engine on Raspberry Pi OS, make sure you
 [meet the prerequisites](#prerequisites), and then follow the
 [installation steps](#installation-methods).
@@ -49,6 +65,18 @@ To install Docker Engine, you need one of the following OS versions:
 - 32-bit Raspberry Pi OS Bookworm 12 (stable)
 - 32-bit Raspberry Pi OS Bullseye 11 (oldstable)
 
+> [!WARNING]
+>
+> Docker Engine v28 is the last major version to support Raspberry Pi OS 32-bit (armhf). Starting with v29,
+> no new packages will be provided for 32-bit Raspberry Pi OS.
+>
+> Migration options:
+> - 64-bit ARM: use Debian `arm64` packages; see the [Debian installation instructions](debian.md).
+> - 32-bit ARM (v7): use Debian `armhf` packages (targets ARMv7 CPUs).
+>
+> Note: ARMv6-based devices (Raspberry Pi 1 models and Raspberry Pi Zero/Zero W) are not supported by
+> official packages.
+
 ### Uninstall old versions
 
 Before you can install Docker Engine, you need to uninstall any conflicting packages.
@@ -98,6 +126,8 @@ You can install Docker Engine in different ways, depending on your needs:
 - Use a [convenience script](#install-using-the-convenience-script). Only
   recommended for testing and development environments.
 
+{{% include "engine-license.md" %}}
+
 ### Install using the `apt` repository {#install-using-the-repository}
 
 Before you install Docker Engine for the first time on a new host machine, you
@@ -132,7 +162,7 @@ Docker from the repository.
    ```console
    $ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
    ```
-  
+
    {{< /tab >}}
    {{< tab name="Specific version" >}}
 
@@ -158,6 +188,20 @@ Docker from the repository.
    {{< /tab >}}
    {{< /tabs >}}
 
+    > [!NOTE]
+    >
+    > After installation, verify that Docker is running:
+    >
+    > ```console
+    > $ sudo systemctl status docker
+    > ```
+    >
+    > If Docker is not running, start it manually:
+    >
+    > ```console
+    > $ sudo systemctl start docker
+    > ```
+
 3. Verify that the installation is successful by running the `hello-world` image:
 
    ```console
@@ -211,12 +255,23 @@ download a new file each time you want to upgrade Docker Engine.
      ./docker-compose-plugin_<version>_<arch>.deb
    ```
 
-   The Docker daemon starts automatically.
+    > [!NOTE]
+    >
+    > After installation, verify that Docker is running:
+    >
+    > ```console
+    > $ sudo systemctl status docker
+    > ```
+    >
+    > If Docker is not running, start it manually:
+    >
+    > ```console
+    > $ sudo systemctl start docker
+    > ```
 
 6. Verify that the installation is successful by running the `hello-world` image:
 
    ```console
-   $ sudo service docker start
    $ sudo docker run hello-world
    ```
 
diff --git a/content/manuals/engine/install/rhel.md b/content/manuals/engine/install/rhel.md
index f76d01be5ce9..72c6f61540d5 100644
--- a/content/manuals/engine/install/rhel.md
+++ b/content/manuals/engine/install/rhel.md
@@ -31,6 +31,7 @@ RHEL versions:
 
 - RHEL 8
 - RHEL 9
+- RHEL 10
 
 ### Uninstall old versions
 
@@ -75,6 +76,8 @@ You can install Docker Engine in different ways, depending on your needs:
 - In testing and development environments, you can use automated
   [convenience scripts](#install-using-the-convenience-script) to install Docker.
 
+{{% include "engine-license.md" %}}
+
 ### Install using the rpm repository {#install-using-the-repository}
 
 Before you install Docker Engine for the first time on a new host machine, you
diff --git a/content/manuals/engine/install/sles.md b/content/manuals/engine/install/sles.md
deleted file mode 100644
index d32163c93faa..000000000000
--- a/content/manuals/engine/install/sles.md
+++ /dev/null
@@ -1,267 +0,0 @@
----
-description: Learn how to install Docker Engine on SLES. These instructions cover
-  the different installation methods, how to uninstall, and next steps.
-keywords: requirements, apt, installation, install docker engine, centos, rpm, sles, install, uninstall,
-  upgrade, update, s390x, ibm-z
-title: Install Docker Engine on SLES (s390x)
-linkTitle: SLES (s390x)
-weight: 70
-toc_max: 4
-aliases:
-- /ee/docker-ee/sles/
-- /ee/docker-ee/suse/
-- /engine/installation/linux/docker-ce/sles/
-- /engine/installation/linux/docker-ee/sles/
-- /engine/installation/linux/docker-ee/suse/
-- /engine/installation/linux/sles/
-- /engine/installation/linux/SUSE/
-- /engine/installation/linux/suse/
-- /engine/installation/sles/
-- /engine/installation/SUSE/
-- /install/linux/docker-ce/sles/
-- /install/linux/docker-ee/sles/
-- /install/linux/docker-ee/suse/
-- /install/linux/sles/
-- /installation/sles/
-download-url-base: https://download.docker.com/linux/sles
----
-
-> [!NOTE]
->
-> The installation instructions on this page refer to packages for SLES on the
-> **s390x** architecture (IBM Z). Other architectures, including x86_64, aren't
-> supported for SLES.
-
-To get started with Docker Engine on SLES, make sure you
-[meet the prerequisites](#prerequisites), and then follow the
-[installation steps](#installation-methods).
-
-## Prerequisites
-
-### OS requirements
-
-To install Docker Engine, you need a maintained version of one of the following
-SLES versions:
-
-- SLES 15-SP4 on s390x (IBM Z)
-- SLES 15-SP5 on s390x (IBM Z)
-
-You must enable the [`SCC SUSE`](https://scc.suse.com/packages?name=SUSE%20Linux%20Enterprise%20Server&version=15.5&arch=s390x)
-repositories.
-
-You must add the [OpenSUSE `SELinux` repository](https://download.opensuse.org/repositories/security:/SELinux/). This repository is not added by default. Run the following commands to add it:
-
-```console
-$ opensuse_repo="https://download.opensuse.org/repositories/security:/SELinux/openSUSE_Factory/security:SELinux.repo"
-$ sudo zypper addrepo $opensuse_repo
-```
-
-### Uninstall old versions
-
-Before you can install Docker Engine, you need to uninstall any conflicting packages.
-
-Your Linux distribution may provide unofficial Docker packages, which may conflict
-with the official packages provided by Docker. You must uninstall these packages
-before you install the official version of Docker Engine.
-
-```console
-$ sudo zypper remove docker \
-                  docker-client \
-                  docker-client-latest \
-                  docker-common \
-                  docker-latest \
-                  docker-latest-logrotate \
-                  docker-logrotate \
-                  docker-engine \
-                  runc
-```
-
-`zypper` might report that you have none of these packages installed.
-
-Images, containers, volumes, and networks stored in `/var/lib/docker/` aren't
-automatically removed when you uninstall Docker.
-
-## Installation methods
-
-You can install Docker Engine in different ways, depending on your needs:
-
-- You can
-  [set up Docker's repositories](#install-using-the-repository) and install
-  from them, for ease of installation and upgrade tasks. This is the
-  recommended approach.
-
-- You can download the RPM package,
-  [install it manually](#install-from-a-package), and manage
-  upgrades completely manually. This is useful in situations such as installing
-  Docker on air-gapped systems with no access to the internet.
-
-- In testing and development environments, you can use automated
-  [convenience scripts](#install-using-the-convenience-script) to install Docker.
-
-### Install using the rpm repository {#install-using-the-repository}
-
-Before you install Docker Engine for the first time on a new host machine, you
-need to set up the Docker repository. Afterward, you can install and update
-Docker from the repository.
-
-#### Set up the repository
-
-Set up the repository.
-
-```console
-$ sudo zypper addrepo {{% param "download-url-base" %}}/docker-ce.repo
-```
-
-#### Install Docker Engine
-
-1. Install the Docker packages.
-
-   {{< tabs >}}
-   {{< tab name="Latest" >}}
-
-   To install the latest version, run:
-
-   ```console
-   $ sudo zypper install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
-   ```
-
-   If prompted to accept the GPG key, verify that the fingerprint matches
-   `060A 61C5 1B55 8A7F 742B 77AA C52F EB6B 621E 9F35`, and if so, accept it.
-
-   This command installs Docker, but it doesn't start Docker. It also creates a
-   `docker` group, however, it doesn't add any users to the group by default.
-
-   {{< /tab >}}
-   {{< tab name="Specific version" >}}
-
-   To install a specific version, start by listing the available versions in
-   the repository:
-
-   ```console
-   $ sudo zypper search -s --match-exact docker-ce | sort -r
- 
-     v  | docker-ce | package | 3:{{% param "docker_ce_version" %}}-1 | s390x | Docker CE Stable - s390x
-     v  | docker-ce | package | 3:{{% param "docker_ce_version_prev" %}}-1 | s390x | Docker CE Stable - s390x
-   ```
-
-   The list returned depends on which repositories are enabled, and is specific
-   to your version of SLES.
-
-   Install a specific version by its fully qualified package name, which is
-   the package name (`docker-ce`) plus the version string (2nd column),
-   separated by a hyphen (`-`). For example, `docker-ce-3:{{% param "docker_ce_version" %}}`.
-
-   Replace `<VERSION_STRING>` with the desired version and then run the following
-   command to install:
-
-   ```console
-   $ sudo zypper install docker-ce-<VERSION_STRING> docker-ce-cli-<VERSION_STRING> containerd.io docker-buildx-plugin docker-compose-plugin
-   ```
-
-   This command installs Docker, but it doesn't start Docker. It also creates a
-   `docker` group, however, it doesn't add any users to the group by default.
-  
-   {{< /tab >}}
-   {{< /tabs >}}
-
-2. Start Docker Engine.
-
-   ```console
-   $ sudo systemctl enable --now docker
-   ```
-
-   This configures the Docker systemd service to start automatically when you
-   boot your system. If you don't want Docker to start automatically, use `sudo
-   systemctl start docker` instead.
-
-3. Verify that the installation is successful by running the `hello-world` image:
-
-   ```console
-   $ sudo docker run hello-world
-   ```
-
-   This command downloads a test image and runs it in a container. When the
-   container runs, it prints a confirmation message and exits.
-
-You have now successfully installed and started Docker Engine.
-
-{{% include "root-errors.md" %}}
-
-#### Upgrade Docker Engine
-
-To upgrade Docker Engine, follow the [installation instructions](#install-using-the-repository),
-choosing the new version you want to install.
-
-### Install from a package
-
-If you can't use Docker's `rpm` repository to install Docker Engine, you can
-download the `.rpm` file for your release and install it manually. You need to
-download a new file each time you want to upgrade Docker Engine.
-
-<!-- markdownlint-disable-next-line -->
-1. Go to [{{% param "download-url-base" %}}/]({{% param "download-url-base" %}}/)
-   and choose your version of SLES. Then browse to `s390x/stable/Packages/`
-   and download the `.rpm` file for the Docker version you want to install.
-
-2. Install Docker Engine, changing the following path to the path where you downloaded
-   the Docker package.
-
-   ```console
-   $ sudo zypper install /path/to/package.rpm
-   ```
-
-   Docker is installed but not started. The `docker` group is created, but no
-   users are added to the group.
-
-3. Start Docker Engine.
-
-   ```console
-   $ sudo systemctl enable --now docker
-   ```
-
-   This configures the Docker systemd service to start automatically when you
-   boot your system. If you don't want Docker to start automatically, use `sudo
-   systemctl start docker` instead.
-
-4. Verify that the installation is successful by running the `hello-world` image:
-
-   ```console
-   $ sudo docker run hello-world
-   ```
-
-   This command downloads a test image and runs it in a container. When the
-   container runs, it prints a confirmation message and exits.
-
-You have now successfully installed and started Docker Engine.
-
-{{% include "root-errors.md" %}}
-
-#### Upgrade Docker Engine
-
-To upgrade Docker Engine, download the newer package files and repeat the
-[installation procedure](#install-from-a-package), using `zypper -y upgrade`
-instead of `zypper -y install`, and point to the new files.
-
-{{% include "install-script.md" %}}
-
-## Uninstall Docker Engine
-
-1. Uninstall the Docker Engine, CLI, containerd, and Docker Compose packages:
-
-   ```console
-   $ sudo zypper remove docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras
-   ```
-
-2. Images, containers, volumes, or custom configuration files on your host
-   aren't automatically removed. To delete all images, containers, and volumes:
-
-   ```console
-   $ sudo rm -rf /var/lib/docker
-   $ sudo rm -rf /var/lib/containerd
-   ```
-
-You have to delete any edited configuration files manually.
-
-## Next steps
-
-- Continue to [Post-installation steps for Linux](linux-postinstall.md).
diff --git a/content/manuals/engine/install/ubuntu.md b/content/manuals/engine/install/ubuntu.md
index 2d1b920d9b64..810a7fa58af5 100644
--- a/content/manuals/engine/install/ubuntu.md
+++ b/content/manuals/engine/install/ubuntu.md
@@ -51,16 +51,15 @@ To get started with Docker Engine on Ubuntu, make sure you
 To install Docker Engine, you need the 64-bit version of one of these Ubuntu
 versions:
 
-- Ubuntu Oracular 24.10
+- Ubuntu Resolute 26.04 (LTS)
 - Ubuntu Noble 24.04 (LTS)
 - Ubuntu Jammy 22.04 (LTS)
-- Ubuntu Focal 20.04 (LTS)
 
 Docker Engine for Ubuntu is compatible with x86_64 (or amd64), armhf, arm64,
 s390x, and ppc64le (ppc64el) architectures.
 
 > [!NOTE]
-> 
+>
 > Installation on Ubuntu derivative distributions, such as Linux Mint, is not officially
 > supported (though it may work).
 
@@ -78,6 +77,7 @@ The unofficial packages to uninstall are:
 - `docker-compose`
 - `docker-compose-v2`
 - `docker-doc`
+- `docker-buildx`
 - `podman-docker`
 
 Moreover, Docker Engine depends on `containerd` and `runc`. Docker Engine
@@ -88,10 +88,10 @@ conflicts with the versions bundled with Docker Engine.
 Run the following command to uninstall all conflicting packages:
 
 ```console
-$ for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do sudo apt-get remove $pkg; done
+$ sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc docker-buildx podman-docker containerd runc | cut -f1)
 ```
 
-`apt-get` might report that you have none of these packages installed.
+`apt` might report that you have none of these packages installed.
 
 Images, containers, volumes, and networks stored in `/var/lib/docker/` aren't
 automatically removed when you uninstall Docker. If you want to start with a
@@ -114,6 +114,8 @@ You can install Docker Engine in different ways, depending on your needs:
 - Use a [convenience script](#install-using-the-convenience-script). Only
   recommended for testing and development environments.
 
+{{% include "engine-license.md" %}}
+
 ### Install using the `apt` repository {#install-using-the-repository}
 
 Before you install Docker Engine for the first time on a new host machine, you
@@ -124,18 +126,23 @@ Docker from the repository.
 
    ```bash
    # Add Docker's official GPG key:
-   sudo apt-get update
-   sudo apt-get install ca-certificates curl
+   sudo apt update
+   sudo apt install ca-certificates curl
    sudo install -m 0755 -d /etc/apt/keyrings
    sudo curl -fsSL {{% param "download-url-base" %}}/gpg -o /etc/apt/keyrings/docker.asc
    sudo chmod a+r /etc/apt/keyrings/docker.asc
 
    # Add the repository to Apt sources:
-   echo \
-     "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] {{% param "download-url-base" %}} \
-     $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
-     sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
-   sudo apt-get update
+   sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
+   Types: deb
+   URIs: {{% param "download-url-base" %}}
+   Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
+   Components: stable
+   Architectures: $(dpkg --print-architecture)
+   Signed-By: /etc/apt/keyrings/docker.asc
+   EOF
+
+   sudo apt update
    ```
 
 2. Install the Docker packages.
@@ -146,9 +153,9 @@ Docker from the repository.
    To install the latest version, run:
 
    ```console
-   $ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+   $ sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
    ```
-  
+
    {{< /tab >}}
    {{< tab name="Specific version" >}}
 
@@ -156,11 +163,10 @@ Docker from the repository.
    available versions in the repository:
 
    ```console
-   # List the available versions:
-   $ apt-cache madison docker-ce | awk '{ print $3 }'
+   $ apt list --all-versions docker-ce
 
-   5:{{% param "docker_ce_version" %}}-1~ubuntu.24.04~noble
-   5:{{% param "docker_ce_version_prev" %}}-1~ubuntu.24.04~noble
+   docker-ce/noble 5:{{% param "docker_ce_version" %}}-1~ubuntu.24.04~noble <arch>
+   docker-ce/noble 5:{{% param "docker_ce_version_prev" %}}-1~ubuntu.24.04~noble <arch>
    ...
    ```
 
@@ -168,12 +174,26 @@ Docker from the repository.
 
    ```console
    $ VERSION_STRING=5:{{% param "docker_ce_version" %}}-1~ubuntu.24.04~noble
-   $ sudo apt-get install docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-buildx-plugin docker-compose-plugin
+   $ sudo apt install docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-buildx-plugin docker-compose-plugin
    ```
 
    {{< /tab >}}
    {{< /tabs >}}
 
+    > [!NOTE]
+    >
+    > After installation, verify that Docker is running:
+    >
+    > ```console
+    > $ sudo systemctl status docker
+    > ```
+    >
+    > If Docker is not running, start it manually:
+    >
+    > ```console
+    > $ sudo systemctl start docker
+    > ```
+
 3. Verify that the installation is successful by running the `hello-world` image:
 
    ```console
@@ -227,12 +247,23 @@ download a new file each time you want to upgrade Docker Engine.
      ./docker-compose-plugin_<version>_<arch>.deb
    ```
 
-   The Docker daemon starts automatically.
+    > [!NOTE]
+    >
+    > After installation, verify that Docker is running:
+    >
+    > ```console
+    > $ sudo systemctl status docker
+    > ```
+    >
+    > If Docker is not running, start it manually:
+    >
+    > ```console
+    > $ sudo systemctl start docker
+    > ```
 
 6. Verify that the installation is successful by running the `hello-world` image:
 
    ```console
-   $ sudo service docker start
    $ sudo docker run hello-world
    ```
 
@@ -255,7 +286,7 @@ To upgrade Docker Engine, download the newer package files and repeat the
 1. Uninstall the Docker Engine, CLI, containerd, and Docker Compose packages:
 
    ```console
-   $ sudo apt-get purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras
+   $ sudo apt purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras
    ```
 
 2. Images, containers, volumes, or custom configuration files on your host
@@ -269,7 +300,7 @@ To upgrade Docker Engine, download the newer package files and repeat the
 3. Remove source list and keyrings
 
    ```console
-   $ sudo rm /etc/apt/sources.list.d/docker.list
+   $ sudo rm /etc/apt/sources.list.d/docker.sources
    $ sudo rm /etc/apt/keyrings/docker.asc
    ```
 
diff --git a/content/manuals/engine/logging/configure.md b/content/manuals/engine/logging/configure.md
index 596d27adb611..6fe295a2db75 100644
--- a/content/manuals/engine/logging/configure.md
+++ b/content/manuals/engine/logging/configure.md
@@ -26,7 +26,7 @@ included with Docker, you can also implement and use [logging driver plugins](pl
 > [!TIP]
 >
 > Use the `local` logging driver to prevent disk-exhaustion. By default, no log-rotation is performed. As a result, log-files stored by the
-> default [`json-file` logging driver](drivers/json-file.md) logging driver can cause
+> default [`json-file` logging driver](drivers/json-file.md) can cause
 > a significant amount of disk space to be used for containers that generate much
 > output, which can lead to disk space exhaustion.
 >
diff --git a/content/manuals/engine/logging/drivers/awslogs.md b/content/manuals/engine/logging/drivers/awslogs.md
index 189b892f5fe2..8839f6075cfd 100644
--- a/content/manuals/engine/logging/drivers/awslogs.md
+++ b/content/manuals/engine/logging/drivers/awslogs.md
@@ -17,11 +17,12 @@ and Command Line Tools](https://docs.aws.amazon.com/cli/latest/reference/logs/in
 ## Usage
 
 To use the `awslogs` driver as the default logging driver, set the `log-driver`
-and `log-opt` keys to appropriate values in the `daemon.json` file, which is
-located in `/etc/docker/` on Linux hosts or
-`C:\ProgramData\docker\config\daemon.json` on Windows Server. For more about
-configuring Docker using `daemon.json`, see
+and `log-opt` keys to appropriate values in the `daemon.json` file. For more
+about configuring Docker using `daemon.json`, see
 [daemon.json](/reference/cli/dockerd.md#daemon-configuration-file).
+
+{{% include "daemon-cfg-desktop.md" %}}
+
 The following example sets the log driver to `awslogs` and sets the
 `awslogs-region` option.
 
@@ -225,12 +226,17 @@ The following `strftime` codes are supported:
 | `%p` | AM or PM.                                                        | AM       |
 | `%M` | Minute as a zero-padded decimal number.                          | 57       |
 | `%S` | Second as a zero-padded decimal number.                          | 04       |
-| `%L` | Milliseconds as a zero-padded decimal number.                    | .123     |
 | `%f` | Microseconds as a zero-padded decimal number.                    | 000345   |
 | `%z` | UTC offset in the form +HHMM or -HHMM.                           | +1300    |
 | `%Z` | Time zone name.                                                  | PST      |
 | `%j` | Day of the year as a zero-padded decimal number.                 | 363      |
 
+In addition, the following non-`strftime` codes are supported:
+
+| Code | Meaning                                                              | Example  |
+| :--- | :------------------------------------------------------------------- | :------- |
+| `%L` | Milliseconds as a zero-padded decimal number preceded with a period. | .123     |
+
 ### awslogs-multiline-pattern
 
 The `awslogs-multiline-pattern` option defines a multi-line start pattern using a
@@ -332,6 +338,14 @@ default AWS shared credentials file (`~/.aws/credentials` of the root user), or
 if you are running the Docker daemon on an Amazon EC2 instance, the Amazon EC2
 instance profile.
 
+> [!NOTE]
+> Docker reads AWS credentials when the container starts.
+> If you use a shared AWS credentials file with temporary credentials,
+> updating the file later does not automatically update the credentials
+> used by the running container. When the temporary credentials expire,
+> log delivery to Amazon CloudWatch Logs can fail. Restart the container
+> after refreshing the credentials so Docker can load the updated values.
+
 Credentials must have a policy applied that allows the `logs:CreateLogStream`
 and `logs:PutLogEvents` actions, as shown in the following example.
 
diff --git a/content/manuals/engine/logging/drivers/etwlogs.md b/content/manuals/engine/logging/drivers/etwlogs.md
index 34a579973e85..98f3960ade70 100644
--- a/content/manuals/engine/logging/drivers/etwlogs.md
+++ b/content/manuals/engine/logging/drivers/etwlogs.md
@@ -25,7 +25,7 @@ before the provider has been registered with the system.
 Here is an example of how to listen to these events using the logman utility program
 included in most installations of Windows:
 
-1. `logman start -ets DockerContainerLogs -p {a3693192-9ed6-46d2-a981-f8226c8363bd} 0 0 -o trace.etl`
+1. `logman start -ets DockerContainerLogs -p "{a3693192-9ed6-46d2-a981-f8226c8363bd}" 0x0 -o trace.etl`
 2. Run your container(s) with the etwlogs driver, by adding
    `--log-driver=etwlogs` to the Docker run command, and generate log messages.
 3. `logman stop -ets DockerContainerLogs`
diff --git a/content/manuals/engine/logging/drivers/fluentd.md b/content/manuals/engine/logging/drivers/fluentd.md
index 4f44382affc4..4169bc8c04b4 100644
--- a/content/manuals/engine/logging/drivers/fluentd.md
+++ b/content/manuals/engine/logging/drivers/fluentd.md
@@ -33,10 +33,11 @@ Some options are supported by specifying `--log-opt` as many times as needed:
 - `tag`: specify a tag for Fluentd messages. Supports some Go template markup, ex `{{.ID}}`, `{{.FullID}}` or `{{.Name}}` `docker.{{.ID}}`.
 
 To use the `fluentd` driver as the default logging driver, set the `log-driver`
-and `log-opt` keys to appropriate values in the `daemon.json` file, which is
-located in `/etc/docker/` on Linux hosts or
-`C:\ProgramData\docker\config\daemon.json` on Windows Server. For more about
-configuring Docker using `daemon.json`, see [daemon.json](/reference/cli/dockerd.md#daemon-configuration-file).
+and `log-opt` keys to appropriate values in the `daemon.json` file. For more
+about configuring Docker using `daemon.json`, see
+[daemon.json](/reference/cli/dockerd.md#daemon-configuration-file).
+
+{{% include "daemon-cfg-desktop.md" %}}
 
 The following example sets the log driver to `fluentd` and sets the
 `fluentd-address` option.
@@ -143,6 +144,11 @@ The maximum number of retries. Defaults to `4294967295` (2\*\*32 - 1).
 
 Generates event logs in nanosecond resolution. Defaults to `false`.
 
+### fluentd-write-timeout
+
+Sets the timeout for the write call to the `fluentd` daemon. By default,
+writes have no timeout and will block indefinitely.
+
 ## Fluentd daemon management with Docker
 
 About `Fluentd` itself, see [the project webpage](https://www.fluentd.org)
diff --git a/content/manuals/engine/logging/drivers/gcplogs.md b/content/manuals/engine/logging/drivers/gcplogs.md
index cb574c3e4af9..61994ce817f9 100644
--- a/content/manuals/engine/logging/drivers/gcplogs.md
+++ b/content/manuals/engine/logging/drivers/gcplogs.md
@@ -14,12 +14,12 @@ Logging.
 ## Usage
 
 To use the `gcplogs` driver as the default logging driver, set the `log-driver`
-and `log-opt` keys to appropriate values in the `daemon.json` file, which is
-located in `/etc/docker/` on Linux hosts or
-`C:\ProgramData\docker\config\daemon.json` on Windows Server. For more about
-configuring Docker using `daemon.json`, see
+and `log-opt` keys to appropriate values in the `daemon.json` file. For more
+about configuring Docker using `daemon.json`, see
 [daemon.json](/reference/cli/dockerd.md#daemon-configuration-file).
 
+{{% include "daemon-cfg-desktop.md" %}}
+
 The following example sets the log driver to `gcplogs` and sets the
 `gcp-meta-name` option.
 
diff --git a/content/manuals/engine/logging/drivers/gelf.md b/content/manuals/engine/logging/drivers/gelf.md
index 5416bdc9463d..1baeb98d974f 100644
--- a/content/manuals/engine/logging/drivers/gelf.md
+++ b/content/manuals/engine/logging/drivers/gelf.md
@@ -23,11 +23,12 @@ In GELF, every log message is a dict with the following fields:
 ## Usage
 
 To use the `gelf` driver as the default logging driver, set the `log-driver` and
-`log-opt` keys to appropriate values in the `daemon.json` file, which is located
-in `/etc/docker/` on Linux hosts or `C:\ProgramData\docker\config\daemon.json`
-on Windows Server. For more about configuring Docker using `daemon.json`, see
+`log-opt` keys to appropriate values in the `daemon.json` file. For more about
+configuring Docker using `daemon.json`, see
 [daemon.json](/reference/cli/dockerd.md#daemon-configuration-file).
 
+{{% include "daemon-cfg-desktop.md" %}}
+
 The following example sets the log driver to `gelf` and sets the `gelf-address`
 option.
 
diff --git a/content/manuals/engine/logging/drivers/journald.md b/content/manuals/engine/logging/drivers/journald.md
index 8bd75043a563..071d736787ac 100644
--- a/content/manuals/engine/logging/drivers/journald.md
+++ b/content/manuals/engine/logging/drivers/journald.md
@@ -28,12 +28,12 @@ stores the following metadata in the journal with each message:
 ## Usage
 
 To use the `journald` driver as the default logging driver, set the `log-driver`
-and `log-opts` keys to appropriate values in the `daemon.json` file, which is
-located in `/etc/docker/` on Linux hosts or
-`C:\ProgramData\docker\config\daemon.json` on Windows Server. For more about
-configuring Docker using `daemon.json`, see
+and `log-opts` keys to appropriate values in the `daemon.json` file. For more
+about configuring Docker using `daemon.json`, see
 [daemon.json](/reference/cli/dockerd.md#daemon-configuration-file).
 
+{{% include "daemon-cfg-desktop.md" %}}
+
 The following example sets the log driver to `journald`:
 
 ```json
diff --git a/content/manuals/engine/logging/drivers/json-file.md b/content/manuals/engine/logging/drivers/json-file.md
index b275f6188664..834d6f6c14d6 100644
--- a/content/manuals/engine/logging/drivers/json-file.md
+++ b/content/manuals/engine/logging/drivers/json-file.md
@@ -31,12 +31,12 @@ only one container.
 ## Usage
 
 To use the `json-file` driver as the default logging driver, set the `log-driver`
-and `log-opts` keys to appropriate values in the `daemon.json` file, which is
-located in `/etc/docker/` on Linux hosts or
-`C:\ProgramData\docker\config\` on Windows Server. If the file does not exist, create it first. For more information about
-configuring Docker using `daemon.json`, see
+and `log-opts` keys to appropriate values in the `daemon.json` file. For more
+information about configuring Docker using `daemon.json`, see
 [daemon.json](/reference/cli/dockerd.md#daemon-configuration-file).
 
+{{% include "daemon-cfg-desktop.md" %}}
+
 The following example sets the log driver to `json-file` and sets the `max-size`
 and `max-file` options to enable automatic log-rotation.
 
@@ -74,13 +74,13 @@ The `json-file` logging driver supports the following logging options:
 
 | Option         | Description                                                                                                                                                                                                   | Example value                                      |
 | :------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------- |
-| `max-size`     | The maximum size of the log before it is rolled. A positive integer plus a modifier representing the unit of measure (`k`, `m`, or `g`). Defaults to -1 (unlimited).                                          | `--log-opt max-size=10m`                           |
+| `max-size`     | The maximum size of the log before it is rolled. A positive integer plus a unit modifier (`k`, `m`, or `g`; case-insensitive). Defaults to -1 (unlimited).                                          | `--log-opt max-size=10m`                           |
 | `max-file`     | The maximum number of log files that can be present. If rolling the logs creates excess files, the oldest file is removed. **Only effective when `max-size` is also set.** A positive integer. Defaults to 1. | `--log-opt max-file=3`                             |
 | `labels`       | Applies when starting the Docker daemon. A comma-separated list of logging-related labels this daemon accepts. Used for advanced [log tag options](log_tags.md).                                              | `--log-opt labels=production_status,geo`           |
 | `labels-regex` | Similar to and compatible with `labels`. A regular expression to match logging-related labels. Used for advanced [log tag options](log_tags.md).                                                              | `--log-opt labels-regex=^(production_status\|geo)` |
 | `env`          | Applies when starting the Docker daemon. A comma-separated list of logging-related environment variables this daemon accepts. Used for advanced [log tag options](log_tags.md).                               | `--log-opt env=os,customer`                        |
 | `env-regex`    | Similar to and compatible with `env`. A regular expression to match logging-related environment variables. Used for advanced [log tag options](log_tags.md).                                                  | `--log-opt env-regex=^(os\|customer)`              |
-| `compress`     | Toggles compression for rotated logs. Default is `disabled`.                                                                                                                                                  | `--log-opt compress=true`                          |
+| `compress`     | Toggles compression for rotated logs. Defaults to `false` (no compression).                                                                                                                                   | `--log-opt compress=true`                          |
 
 ### Examples
 
diff --git a/content/manuals/engine/logging/drivers/local.md b/content/manuals/engine/logging/drivers/local.md
index ba3292d4a865..93df55251b27 100644
--- a/content/manuals/engine/logging/drivers/local.md
+++ b/content/manuals/engine/logging/drivers/local.md
@@ -26,12 +26,12 @@ for each file and a default count of 5 for the number of such files (to account
 ## Usage
 
 To use the `local` driver as the default logging driver, set the `log-driver`
-and `log-opt` keys to appropriate values in the `daemon.json` file, which is
-located in `/etc/docker/` on Linux hosts or
-`C:\ProgramData\docker\config\daemon.json` on Windows Server. For more about
-configuring Docker using `daemon.json`, see
+and `log-opt` keys to appropriate values in the `daemon.json` file. For more
+about configuring Docker using `daemon.json`, see
 [daemon.json](/reference/cli/dockerd.md#daemon-configuration-file).
 
+{{% include "daemon-cfg-desktop.md" %}}
+
 The following example sets the log driver to `local` and sets the `max-size`
 option.
 
@@ -64,7 +64,7 @@ The `local` logging driver supports the following logging options:
 
 | Option     | Description                                                                                                                                                   | Example value              |
 | :--------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------- |
-| `max-size` | The maximum size of the log before it's rolled. A positive integer plus a modifier representing the unit of measure (`k`, `m`, or `g`). Defaults to 20m.      | `--log-opt max-size=10m`   |
+| `max-size` | The maximum size of the log before it's rolled. A positive integer plus a unit modifier (`k`, `m`, or `g`; case-insensitive). Defaults to 20m.      | `--log-opt max-size=10m`   |
 | `max-file` | The maximum number of log files that can be present. If rolling the logs creates excess files, the oldest file is removed. A positive integer. Defaults to 5. | `--log-opt max-file=3`     |
 | `compress` | Toggle compression of rotated log files. Enabled by default.                                                                                                  | `--log-opt compress=false` |
 
diff --git a/content/manuals/engine/logging/drivers/splunk.md b/content/manuals/engine/logging/drivers/splunk.md
index 97373d1198ac..5a4e99e211a4 100644
--- a/content/manuals/engine/logging/drivers/splunk.md
+++ b/content/manuals/engine/logging/drivers/splunk.md
@@ -32,11 +32,11 @@ configuration file and restart Docker. For example:
 }
 ```
 
-The daemon.json file is located in `/etc/docker/` on Linux hosts or
-`C:\ProgramData\docker\config\daemon.json` on Windows Server. For more about
-configuring Docker using `daemon.json`, see
+For more about configuring Docker using `daemon.json`, see
 [daemon.json](/reference/cli/dockerd.md#daemon-configuration-file).
 
+{{% include "daemon-cfg-desktop.md" %}}
+
 > [!NOTE]
 >
 > `log-opts` configuration options in the `daemon.json` configuration file must
diff --git a/content/manuals/engine/logging/drivers/syslog.md b/content/manuals/engine/logging/drivers/syslog.md
index 2cabe82bcda7..e27547b4dfa4 100644
--- a/content/manuals/engine/logging/drivers/syslog.md
+++ b/content/manuals/engine/logging/drivers/syslog.md
@@ -22,7 +22,7 @@ receiver can extract the following information:
 The format is defined in [RFC 5424](https://tools.ietf.org/html/rfc5424) and Docker's syslog driver implements the
 [ABNF reference](https://tools.ietf.org/html/rfc5424#section-6) in the following way:
 
-```none
+```text
                 TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID
                     +          +             +           |        +
                     |          |             |           |        |
@@ -35,12 +35,12 @@ The format is defined in [RFC 5424](https://tools.ietf.org/html/rfc5424) and Doc
 ## Usage
 
 To use the `syslog` driver as the default logging driver, set the `log-driver`
-and `log-opt` keys to appropriate values in the `daemon.json` file, which is
-located in `/etc/docker/` on Linux hosts or
-`C:\ProgramData\docker\config\daemon.json` on Windows Server. For more about
-configuring Docker using `daemon.json`, see
+and `log-opt` keys to appropriate values in the `daemon.json` file. For more
+about configuring Docker using `daemon.json`, see
 [daemon.json](/reference/cli/dockerd.md#daemon-configuration-file).
 
+{{% include "daemon-cfg-desktop.md" %}}
+
 The following example sets the log driver to `syslog` and sets the
 `syslog-address` option. The `syslog-address` options supports both UDP and TCP;
 this example uses UDP.
diff --git a/content/manuals/engine/logging/dual-logging.md b/content/manuals/engine/logging/dual-logging.md
index 15a1887f2a11..188211f79e3d 100644
--- a/content/manuals/engine/logging/dual-logging.md
+++ b/content/manuals/engine/logging/dual-logging.md
@@ -122,7 +122,7 @@ options described below to customize these defaults.
 | Option           | Default   | Description                                                                                                                                       |
 | :--------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------ |
 | `cache-disabled` | `"false"` | Disable local caching. Boolean value passed as a string (`true`, `1`, `0`, or `false`).                                                           |
-| `cache-max-size` | `"20m"`   | The maximum size of the cache before it is rotated. A positive integer plus a modifier representing the unit of measure (`k`, `m`, or `g`).       |
+| `cache-max-size` | `"20m"`   | The maximum size of the cache before it is rotated. A positive integer plus a unit modifier (`k`, `m`, or `g`; case-insensitive).       |
 | `cache-max-file` | `"5"`     | The maximum number of cache files that can be present. If rotating the logs creates excess files, the oldest file is removed. A positive integer. |
 | `cache-compress` | `"true"`  | Enable or disable compression of rotated log files. Boolean value passed as a string (`true`, `1`, `0`, or `false`).                              |
 
diff --git a/content/manuals/engine/logging/log_tags.md b/content/manuals/engine/logging/log_tags.md
index d0372fe5c25c..d9493abc2dbd 100644
--- a/content/manuals/engine/logging/log_tags.md
+++ b/content/manuals/engine/logging/log_tags.md
@@ -30,7 +30,7 @@ Docker supports some special template markup you can use when specifying a tag's
 
 For example, specifying a `--log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"` value yields `syslog` log lines like:
 
-```none
+```text
 Aug  7 18:33:19 HOSTNAME hello-world/foobar/5790672ab6a0[9103]: Hello from Docker.
 ```
 
diff --git a/content/manuals/engine/manage-resources/labels.md b/content/manuals/engine/manage-resources/labels.md
index 1cc915fa2e4e..87aa01f2c939 100644
--- a/content/manuals/engine/manage-resources/labels.md
+++ b/content/manuals/engine/manage-resources/labels.md
@@ -70,47 +70,122 @@ you build this functionality into third-party tooling.
 ## Manage labels on objects
 
 Each type of object with support for labels has mechanisms for adding and
-managing them and using them as they relate to that type of object. These links
-provide a good place to start learning about how you can use labels in your
-Docker deployments.
+managing them and using them as they relate to that type of object.
 
-Labels on images, containers, local daemons, volumes, and networks are static for
-the lifetime of the object. To change these labels you must recreate the object.
-Labels on Swarm nodes and services can be updated dynamically.
+Labels on images, containers, local daemons, volumes, and networks are static
+for the lifetime of the object. To change these labels you must recreate the
+object. Labels on Swarm nodes and services can be updated dynamically.
 
-- Images and containers
+### Images
 
-  - [Adding labels to images](/reference/dockerfile.md#label)
-  - [Overriding a container's labels at runtime](/reference/cli/docker/container/run.md#label)
-  - [Inspecting labels on images or containers](/reference/cli/docker/inspect.md)
-  - [Filtering images by label](/reference/cli/docker/image/ls.md#filter)
-  - [Filtering containers by label](/reference/cli/docker/container/ls.md#filter)
+Add labels to images using the [`LABEL` instruction](/reference/dockerfile.md#label) in a Dockerfile:
 
-- Local Docker daemons
+```dockerfile
+LABEL com.example.version="1.0"
+LABEL com.example.description="Web application"
+```
 
-  - [Adding labels to a Docker daemon at runtime](/reference/cli/dockerd.md)
-  - [Inspecting a Docker daemon's labels](/reference/cli/docker/system/info.md)
+You can also set labels at build time with the `--label` flag, without needing
+a `LABEL` instruction in the Dockerfile:
 
-- Volumes
+```console
+$ docker build --label "com.example.version=1.0" -t myapp .
+```
 
-  - [Adding labels to volumes](/reference/cli/docker/volume/create.md)
-  - [Inspecting a volume's labels](/reference/cli/docker/volume/inspect.md)
-  - [Filtering volumes by label](/reference/cli/docker/volume/ls.md#filter)
+Inspect labels on an image using `docker inspect`:
 
-- Networks
+```console
+$ docker inspect --format='{{json .Config.Labels}}' myapp
+```
 
-  - [Adding labels to a network](/reference/cli/docker/network/create.md)
-  - [Inspecting a network's labels](/reference/cli/docker/network/inspect.md)
-  - [Filtering networks by label](/reference/cli/docker/network/ls.md#filter)
+Filter images by label with [`docker image ls --filter`](/reference/cli/docker/image/ls/#filter):
 
-- Swarm nodes
+```console
+$ docker image ls --filter "label=com.example.version"
+```
 
-  - [Adding or updating a Swarm node's labels](/reference/cli/docker/node/update.md#label-add)
-  - [Inspecting a Swarm node's labels](/reference/cli/docker/node/inspect.md)
-  - [Filtering Swarm nodes by label](/reference/cli/docker/node/ls.md#filter)
+### Containers
 
-- Swarm services
-  - [Adding labels when creating a Swarm service](/reference/cli/docker/service/create.md#label)
-  - [Updating a Swarm service's labels](/reference/cli/docker/service/update.md)
-  - [Inspecting a Swarm service's labels](/reference/cli/docker/service/inspect.md)
-  - [Filtering Swarm services by label](/reference/cli/docker/service/ls.md#filter)
+Override or add labels when starting a container with
+[`docker run --label`](/reference/cli/docker/container/run/#label):
+
+```console
+$ docker run --label "com.example.env=prod" myapp
+```
+
+Inspect labels on a container:
+
+```console
+$ docker inspect --format='{{json .Config.Labels}}' mycontainer
+```
+
+Filter containers by label with [`docker container ls --filter`](/reference/cli/docker/container/ls/#filter):
+
+```console
+$ docker container ls --filter "label=com.example.env=prod"
+```
+
+### Local Docker daemons
+
+Add labels to the Docker daemon by passing `--label` flags when starting
+`dockerd`, or by setting `"labels"` in the
+[daemon configuration file](/reference/cli/dockerd.md#daemon-configuration-file):
+
+```json
+{
+  "labels": ["com.example.environment=production"]
+}
+```
+
+View daemon labels with `docker system info`.
+
+### Volumes
+
+Add labels when [creating a volume](/reference/cli/docker/volume/create/):
+
+```console
+$ docker volume create --label "com.example.purpose=database" myvolume
+```
+
+Inspect volume labels:
+
+```console
+$ docker volume inspect myvolume --format='{{json .Labels}}'
+```
+
+Filter volumes by label with [`docker volume ls --filter`](/reference/cli/docker/volume/ls/#filter):
+
+```console
+$ docker volume ls --filter "label=com.example.purpose"
+```
+
+### Networks
+
+Add labels when [creating a network](/reference/cli/docker/network/create/):
+
+```console
+$ docker network create --label "com.example.purpose=frontend" mynetwork
+```
+
+Inspect network labels:
+
+```console
+$ docker network inspect mynetwork --format='{{json .Labels}}'
+```
+
+Filter networks by label with [`docker network ls --filter`](/reference/cli/docker/network/ls/#filter):
+
+```console
+$ docker network ls --filter "label=com.example.purpose"
+```
+
+### Swarm nodes
+
+- [Adding or updating a Swarm node's labels](/reference/cli/docker/node/update/#label-add)
+- [Filtering Swarm nodes by label](/reference/cli/docker/node/ls/#filter)
+
+### Swarm services
+
+- [Adding labels when creating a Swarm service](/reference/cli/docker/service/create/#label)
+- [Updating a Swarm service's labels](/reference/cli/docker/service/update/)
+- [Filtering Swarm services by label](/reference/cli/docker/service/ls/#filter)
diff --git a/content/manuals/engine/manage-resources/pruning.md b/content/manuals/engine/manage-resources/pruning.md
index 56b5b4de9588..d5d6db2da9c9 100644
--- a/content/manuals/engine/manage-resources/pruning.md
+++ b/content/manuals/engine/manage-resources/pruning.md
@@ -1,20 +1,22 @@
 ---
 description: Free up disk space by removing unused resources with the prune command
-keywords: pruning, prune, images, volumes, containers, networks, disk, administration,
+keywords:
+  pruning, prune, images, volumes, containers, networks, disk, administration,
   garbage collection
 title: Prune unused Docker objects
 aliases:
-- /engine/admin/pruning/
-- /config/pruning/
+  - /engine/admin/pruning/
+  - /config/pruning/
 ---
 
 Docker takes a conservative approach to cleaning up unused objects (often
-referred to as "garbage collection"), such as images, containers, volumes, and
-networks. These objects are generally not removed unless you explicitly ask
-Docker to do so. This can cause Docker to use extra disk space. For each type of
-object, Docker provides a `prune` command. In addition, you can use `docker
-system prune` to clean up multiple types of objects at once. This topic shows
-how to use these `prune` commands.
+referred to as "garbage collection"), such as images, containers, volumes,
+networks, and build cache. These objects are generally not removed unless you
+explicitly ask Docker to do so. This can cause Docker to use extra disk space.
+For each type of object, Docker provides a `prune` command. In addition, you can
+use `docker system prune` to clean up multiple types of objects at once
+(including unused build cache). This topic shows how to use these `prune`
+commands.
 
 ## Prune images
 
@@ -52,7 +54,7 @@ $ docker image prune -a --filter "until=24h"
 ```
 
 Other filtering expressions are available. See the
-[`docker image prune` reference](/reference/cli/docker/image/prune.md)
+[`docker image prune` reference](/reference/cli/docker/image/prune/)
 for more examples.
 
 ## Prune containers
@@ -83,7 +85,7 @@ $ docker container prune --filter "until=24h"
 ```
 
 Other filtering expressions are available. See the
-[`docker container prune` reference](/reference/cli/docker/container/prune.md)
+[`docker container prune` reference](/reference/cli/docker/container/prune/)
 for more examples.
 
 ## Prune volumes
@@ -95,23 +97,25 @@ data.
 ```console
 $ docker volume prune
 
-WARNING! This will remove all volumes not used by at least one container.
+WARNING! This will remove anonymous local volumes not used by at least one container.
 Are you sure you want to continue? [y/N] y
 ```
 
 By default, you are prompted to continue. To bypass the prompt, use the `-f` or
 `--force` flag.
 
-By default, all unused volumes are removed. You can limit the scope using
-the `--filter` flag. For instance, the following command only removes
-volumes which aren't labelled with the `keep` label:
+By default, only **anonymous** unused volumes are removed. Named volumes that
+aren't attached to a container are left alone unless you pass `--all` / `-a`.
+You can also limit the scope with the `--filter` flag. For instance, the
+following command only removes volumes which aren't labelled with the `keep`
+label:
 
 ```console
 $ docker volume prune --filter "label!=keep"
 ```
 
 Other filtering expressions are available. See the
-[`docker volume prune` reference](/reference/cli/docker/volume/prune.md)
+[`docker volume prune` reference](/reference/cli/docker/volume/prune/)
 for more examples.
 
 ## Prune networks
@@ -140,14 +144,35 @@ $ docker network prune --filter "until=24h"
 ```
 
 Other filtering expressions are available. See the
-[`docker network prune` reference](/reference/cli/docker/network/prune.md)
+[`docker network prune` reference](/reference/cli/docker/network/prune/)
 for more examples.
 
+## Prune build cache
+
+`docker buildx prune` removes the build cache for the currently selected
+builder. If you use multiple builders, each builder maintains its own cache —
+use the `--builder` flag to target a specific builder instance.
+
+```console
+$ docker buildx prune
+
+WARNING! This will remove all dangling build cache.
+Are you sure you want to continue? [y/N] y
+```
+
+By default, you're prompted to continue. To bypass the prompt, use the `-f` or
+`--force` flag.
+
+See the [`docker buildx prune` reference](/reference/cli/docker/buildx/prune/)
+for all options, including `--all` to also remove internal and frontend images.
+
 ## Prune everything
 
 The `docker system prune` command is a shortcut that prunes images, containers,
-and networks. Volumes aren't pruned by default, and you must specify the
-`--volumes` flag for `docker system prune` to prune volumes.
+networks, and unused build cache (including BuildKit cache mounts). Volumes
+aren't pruned by default. Add `--volumes` to also remove unused **anonymous**
+volumes. Named unused volumes are left alone; use `docker volume prune --all`
+if you intend to delete those too.
 
 ```console
 $ docker system prune
@@ -161,7 +186,7 @@ WARNING! This will remove:
 Are you sure you want to continue? [y/N] y
 ```
 
-To also prune volumes, add the `--volumes` flag:
+To also prune unused anonymous volumes, add the `--volumes` flag:
 
 ```console
 $ docker system prune --volumes
@@ -169,9 +194,9 @@ $ docker system prune --volumes
 WARNING! This will remove:
         - all stopped containers
         - all networks not used by at least one container
-        - all volumes not used by at least one container
+        - all anonymous volumes not used by at least one container
         - all dangling images
-        - all build cache
+        - unused build cache
 
 Are you sure you want to continue? [y/N] y
 ```
@@ -179,14 +204,15 @@ Are you sure you want to continue? [y/N] y
 By default, you're prompted to continue. To bypass the prompt, use the `-f` or
 `--force` flag.
 
-By default, all unused containers, networks, and images are removed. You can
-limit the scope using the `--filter` flag. For instance, the following command
-removes items older than 24 hours:
+By default, unused containers and networks are removed, along with dangling
+images. Unused tagged images are kept unless you also pass `-a` / `--all`.
+You can further limit the scope with the `--filter` flag. For instance, the
+following command removes items older than 24 hours:
 
 ```console
 $ docker system prune --filter "until=24h"
 ```
 
 Other filtering expressions are available. See the
-[`docker system prune` reference](/reference/cli/docker/system/prune.md)
+[`docker system prune` reference](/reference/cli/docker/system/prune/)
 for more examples.
diff --git a/content/manuals/engine/network/_index.md b/content/manuals/engine/network/_index.md
index 048834851b57..e68950cc595b 100644
--- a/content/manuals/engine/network/_index.md
+++ b/content/manuals/engine/network/_index.md
@@ -5,68 +5,99 @@ weight: 30
 description: Learn how networking works from the container's point of view
 keywords: networking, container, standalone, IP address, DNS resolution
 aliases:
-- /articles/networking/
-- /config/containers/container-networking/
-- /engine/tutorials/networkingcontainers/
-- /engine/userguide/networking/
-- /engine/userguide/networking/configure-dns/
-- /engine/userguide/networking/default_network/binding/
-- /engine/userguide/networking/default_network/configure-dns/
-- /engine/userguide/networking/default_network/container-communication/
-- /engine/userguide/networking/dockernetworks/
-- /network/
+  - /articles/networking/
+  - /config/containers/container-networking/
+  - /engine/tutorials/networkingcontainers/
+  - /engine/userguide/networking/
+  - /engine/userguide/networking/configure-dns/
+  - /engine/userguide/networking/default_network/binding/
+  - /engine/userguide/networking/default_network/configure-dns/
+  - /engine/userguide/networking/default_network/container-communication/
+  - /engine/userguide/networking/dockernetworks/
+  - /network/
 ---
 
 Container networking refers to the ability for containers to connect to and
-communicate with each other, or to non-Docker workloads.
+communicate with each other, and with non-Docker network services.
 
 Containers have networking enabled by default, and they can make outgoing
 connections. A container has no information about what kind of network it's
-attached to, or whether their peers are also Docker workloads or not. A
+attached to, or whether its network peers are also Docker containers. A
 container only sees a network interface with an IP address, a gateway, a
-routing table, DNS services, and other networking details. That is, unless the
-container uses the `none` network driver.
+routing table, DNS services, and other networking details.
 
 This page describes networking from the point of view of the container,
 and the concepts around container networking.
-This page doesn't describe OS-specific details about how Docker networks work.
-For information about how Docker manipulates `iptables` rules on Linux,
-see [Packet filtering and firewalls](packet-filtering-firewalls.md).
+
+When Docker Engine on Linux starts for the first time, it has a single
+built-in network called the "default bridge" network. When you run a
+container without the `--network` option, it is connected to the default
+bridge.
+
+Containers attached to the default bridge have access to network services
+outside the Docker host. They use "masquerading" which means, if the
+Docker host has Internet access, no additional configuration is needed
+for the container to have Internet access.
+
+For example, to run a container on the default bridge network, and have
+it ping an Internet host:
+
+```console
+$ docker run --rm -ti busybox ping -c1 docker.com
+PING docker.com (23.185.0.4): 56 data bytes
+64 bytes from 23.185.0.4: seq=0 ttl=62 time=6.564 ms
+
+--- docker.com ping statistics ---
+1 packets transmitted, 1 packets received, 0% packet loss
+round-trip min/avg/max = 6.564/6.564/6.564 ms
+```
 
 ## User-defined networks
 
-You can create custom, user-defined networks, and connect multiple containers
-to the same network. Once connected to a user-defined network, containers can
-communicate with each other using container IP addresses or container names.
+With the default configuration, containers attached to the default
+bridge network have unrestricted network access to each other using
+container IP addresses. They cannot refer to each other by name.
+
+It can be useful to separate groups of containers that should have full
+access to each other, but restricted access to containers in other groups.
+
+You can create custom, user-defined networks, and connect groups of containers
+to the same network. Once connected to a user-defined network, containers
+can communicate with each other using container IP addresses or container names.
 
 The following example creates a network using the `bridge` network driver and
-running a container in the created network:
+runs a container in that network:
 
 ```console
 $ docker network create -d bridge my-net
-$ docker run --network=my-net -itd --name=container3 busybox
+$ docker run --network=my-net -it busybox
 ```
 
 ### Drivers
 
-The following network drivers are available by default, and provide core
-networking functionality:
+Docker Engine has a number of network drivers, as well as the default "bridge".
+On Linux, the following built-in network drivers are available:
 
-| Driver    | Description                                                              |
-| :-------- | :----------------------------------------------------------------------- |
-| `bridge`  | The default network driver.                                              |
-| `host`    | Remove network isolation between the container and the Docker host.      |
-| `none`    | Completely isolate a container from the host and other containers.       |
-| `overlay` | Overlay networks connect multiple Docker daemons together.               |
-| `ipvlan`  | IPvlan networks provide full control over both IPv4 and IPv6 addressing. |
-| `macvlan` | Assign a MAC address to a container.                                     |
+| Driver                          | Description                                                         |
+| :------------------------------ | :------------------------------------------------------------------ |
+| [bridge](./drivers/bridge.md)   | The default network driver.                                         |
+| [host](./drivers/host.md)       | Remove network isolation between the container and the Docker host. |
+| [none](./drivers/none.md)       | Completely isolate a container from the host and other containers.  |
+| [overlay](./drivers/overlay.md) | Swarm Overlay networks connect multiple Docker daemons together.    |
+| [ipvlan](./drivers/ipvlan.md)   | Connect containers to external VLANs.                               |
+| [macvlan](./drivers/macvlan.md) | Containers appear as devices on the host's network.                 |
 
-For more information about the different drivers, see [Network drivers
-overview](./drivers/_index.md).
+More information can be found in the network driver specific pages, including
+their configuration options and details about their functionality.
+
+Native Windows containers have a different set of drivers, see
+[Windows container network drivers](https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/network-drivers-topologies).
 
 ### Connecting to multiple networks
 
-A container can be connected to multiple networks.
+Connecting a container to a network can be compared to connecting an Ethernet
+cable to a physical host. Just as a host can be connected to multiple Ethernet
+networks, a container can be connected to multiple Docker networks.
 
 For example, a frontend container may be connected to a bridge network
 with external access, and a
@@ -78,6 +109,8 @@ A container may also be connected to different types of network. For example,
 an `ipvlan` network to provide internet access, and a `bridge` network for
 access to local services.
 
+Containers can also share networking stacks, see [Container networks](#container-networks).
+
 When sending packets, if the destination is an address in a directly connected
 network, packets are sent to that network. Otherwise, packets are sent to
 a default gateway for routing to their destination. In the example above,
@@ -87,8 +120,8 @@ The default gateway is selected by Docker, and may change whenever a
 container's network connections change.
 To make Docker choose a specific default gateway when creating the container
 or connecting a new network, set a gateway priority. See option `gw-priority`
-for the [`docker run`](/reference/cli/docker/container/run.md) and
-[`docker network connect`](/reference/cli/docker/network/connect.md) commands.
+for the [`docker run`](/reference/cli/docker/container/run/) and
+[`docker network connect`](/reference/cli/docker/network/connect/) commands.
 
 The default `gw-priority` is `0` and the gateway in the network with the
 highest priority is the default gateway. So, when a network should always
@@ -99,84 +132,20 @@ $ docker run --network name=gwnet,gw-priority=1 --network anet1 --name myctr myi
 $ docker network connect anet2 myctr
 ```
 
-## Container networks
-
-In addition to user-defined networks, you can attach a container to another
-container's networking stack directly, using the `--network
-container:<name|id>` flag format.
-
-The following flags aren't supported for containers using the `container:`
-networking mode:
-
-- `--add-host`
-- `--hostname`
-- `--dns`
-- `--dns-search`
-- `--dns-option`
-- `--mac-address`
-- `--publish`
-- `--publish-all`
-- `--expose`
-
-The following example runs a Redis container, with Redis binding to
-`localhost`, then running the `redis-cli` command and connecting to the Redis
-server over the `localhost` interface.
-
-```console
-$ docker run -d --name redis example/redis --bind 127.0.0.1
-$ docker run --rm -it --network container:redis example/redis-cli -h 127.0.0.1
-```
-
 ## Published ports
 
-By default, when you create or run a container using `docker create` or `docker run`,
-containers on bridge networks don't expose any ports to the outside world.
-Use the `--publish` or `-p` flag to make a port available to services
-outside the bridge network.
-This creates a firewall rule in the host,
-mapping a container port to a port on the Docker host to the outside world.
-Here are some examples:
-
-| Flag value                      | Description                                                                                                                                             |
-| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `-p 8080:80`                    | Map port `8080` on the Docker host to TCP port `80` in the container.                                                                                   |
-| `-p 192.168.1.100:8080:80`      | Map port `8080` on the Docker host IP `192.168.1.100` to TCP port `80` in the container.                                                                |
-| `-p 8080:80/udp`                | Map port `8080` on the Docker host to UDP port `80` in the container.                                                                                   |
-| `-p 8080:80/tcp -p 8080:80/udp` | Map TCP port `8080` on the Docker host to TCP port `80` in the container, and map UDP port `8080` on the Docker host to UDP port `80` in the container. |
-
-> [!IMPORTANT]
->
-> Publishing container ports is insecure by default. Meaning, when you publish
-> a container's ports it becomes available not only to the Docker host, but to
-> the outside world as well.
->
-> If you include the localhost IP address (`127.0.0.1`, or `::1`) with the
-> publish flag, only the Docker host and its containers can access the
-> published container port.
->
-> ```console
-> $ docker run -p 127.0.0.1:8080:80 -p '[::1]:8080:80' nginx
-> ```
->
-> > [!WARNING]
-> >
-> > Hosts within the same L2 segment (for example, hosts connected to the same
-> > network switch) can reach ports published to localhost.
-> > For more information, see
-> > [moby/moby#45610](https://github.com/moby/moby/issues/45610)
-
-If you want to make a container accessible to other containers,
-it isn't necessary to publish the container's ports.
-You can enable inter-container communication by connecting the containers to the
-same network, usually a [bridge network](./drivers/bridge.md).
-
-Ports on the host's IPv6 addresses will map to the container's IPv4 address
-if no host IP is given in a port mapping, the bridge network is IPv4-only,
-and `--userland-proxy=true` (default).
+When you create or run a container using `docker create` or `docker run`, all
+ports of containers on bridge networks are accessible from the Docker host and
+other containers connected to the same network. Ports are not accessible from
+outside the host or, with the default configuration, from containers in other
+networks.
+
+Use the `--publish` or `-p` flag to make a port available outside the host,
+and to containers in other bridge networks.
 
 For more information about port mapping, including how to disable it and use
 direct routing to containers, see
-[packet filtering and firewalls](./packet-filtering-firewalls.md).
+[port publishing](./port-publishing.md).
 
 ## IP address and hostname
 
@@ -203,6 +172,85 @@ You can override the hostname using `--hostname`.
 When connecting to an existing network using `docker network connect`,
 you can use the `--alias` flag to specify an additional network alias for the container on that network.
 
+### Subnet allocation
+
+Docker networks can use either explicitly configured subnets or automatically allocated ones from default pools.
+
+#### Explicit subnet configuration
+
+You can specify exact subnets when creating a network:
+
+```console
+$ docker network create --ipv6 --subnet 192.0.2.0/24 --subnet 2001:db8::/64 mynet
+```
+
+#### Automatic subnet allocation
+
+When no `--subnet` option is provided, Docker automatically selects a subnet from predefined "default address pools".
+These pools can be configured in `/etc/docker/daemon.json`. Docker's built-in default is equivalent to:
+
+```json
+{
+  "default-address-pools": [
+    { "base": "172.17.0.0/16", "size": 16 },
+    { "base": "172.18.0.0/16", "size": 16 },
+    { "base": "172.19.0.0/16", "size": 16 },
+    { "base": "172.20.0.0/14", "size": 16 },
+    { "base": "172.24.0.0/14", "size": 16 },
+    { "base": "172.28.0.0/14", "size": 16 },
+    { "base": "192.168.0.0/16", "size": 20 }
+  ]
+}
+```
+
+- `base`: The subnet that can be allocated from.
+- `size`: The prefix length used for each allocated subnet.
+
+When an IPv6 subnet is required and there are no IPv6 addresses in `default-address-pools`, Docker allocates
+subnets from a Unique Local Address (ULA) prefix. To use specific IPv6 subnets instead, add them to your
+`default-address-pools`. See [Dynamic IPv6 subnet allocation](../daemon/ipv6.md#dynamic-ipv6-subnet-allocation)
+for more information.
+
+Docker attempts to avoid address prefixes already in use on the host. However, you may need to customize
+`default-address-pools` to prevent routing conflicts in some network environments.
+
+The default pools use large subnets, which limits the number of networks you can create. You can divide base
+subnets into smaller pools to support more networks.
+
+For example, this configuration allows Docker to create 256 networks from `172.17.0.0/16`.
+Docker will allocate subnets `172.17.0.0/24`, `172.17.1.0/24`, and so on, up to `172.17.255.0/24`:
+
+```json
+{
+  "default-address-pools": [{ "base": "172.17.0.0/16", "size": 24 }]
+}
+```
+
+You can also request a subnet with a specific prefix length from the default pools by using unspecified
+addresses in the `--subnet` option:
+
+```console
+$ docker network create --ipv6 --subnet ::/56 --subnet 0.0.0.0/24 mynet
+6686a6746b17228f5052528113ddad0e6d68e2e3905d648e336b33409f2d3b64
+$ docker network inspect mynet -f '{{json .IPAM.Config}}' | jq .
+[
+  {
+    "Subnet": "172.19.0.0/24",
+    "Gateway": "172.19.0.1"
+  },
+  {
+    "Subnet": "fdd3:6f80:972c::/56",
+    "Gateway": "fdd3:6f80:972c::1"
+  }
+]
+```
+
+> [!NOTE]
+>
+> Support for unspecified addresses in `--subnet` was introduced in Docker 29.0.0.
+> If Docker is downgraded to an older version, networks created in this way will become unusable.
+> They can be removed and re-created, or will function again if the daemon is restored to 29.0.0 or later.
+
 ## DNS services
 
 Containers use the same DNS servers as the host by default, but you can
@@ -212,9 +260,21 @@ By default, containers inherit the DNS settings as defined in the
 `/etc/resolv.conf` configuration file.
 Containers that attach to the default `bridge` network receive a copy of this file.
 Containers that attach to a
-[custom network](tutorials/standalone.md#use-user-defined-bridge-networks)
+[custom network](drivers/bridge.md#use-user-defined-bridge-networks)
 use Docker's embedded DNS server.
 The embedded DNS server forwards external DNS lookups to the DNS servers configured on the host.
+The embedded DNS server address is `127.0.0.11`.
+There is no IPv6 equivalent; the IPv4 address works even in IPv6-only containers.
+If an application requires an explicit DNS server address, use `127.0.0.11`.
+
+> [!NOTE]
+>
+> When you configure multiple DNS servers for a container on the default
+> `bridge` network, the container's resolver library determines how it queries
+> them. Some resolvers query the servers in order. Others query them in parallel
+> and use the first response received, even if that response is `NXDOMAIN`.
+> On a custom network, Docker's embedded DNS server queries upstream servers in
+> order and stops after a successful response or an `NXDOMAIN` response.
 
 You can configure DNS resolution on a per-container basis, using flags for the
 `docker run` or `docker create` command used to start the container.
@@ -222,7 +282,7 @@ The following table describes the available `docker run` flags related to DNS
 configuration.
 
 | Flag           | Description                                                                                                                                                                                                                                           |
-| -------------- |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `--dns`        | The IP address of a DNS server. To specify multiple DNS servers, use multiple `--dns` flags. DNS requests will be forwarded from the container's network namespace so, for example, `--dns=127.0.0.1` refers to the container's own loopback address. |
 | `--dns-search` | A DNS search domain to search non-fully qualified hostnames. To specify multiple DNS search prefixes, use multiple `--dns-search` flags.                                                                                                              |
 | `--dns-opt`    | A key-value pair representing a DNS option and its value. See your operating system's documentation for `resolv.conf` for valid options.                                                                                                              |
@@ -234,10 +294,33 @@ Your container will have lines in `/etc/hosts` which define the hostname of the
 container itself, as well as `localhost` and a few other common things. Custom
 hosts, defined in `/etc/hosts` on the host machine, aren't inherited by
 containers. To pass additional hosts into a container, refer to [add entries to
-container hosts file](/reference/cli/docker/container/run.md#add-host) in the
+container hosts file](/reference/cli/docker/container/run/#add-host) in the
 `docker run` reference documentation.
 
-## Proxy server
+## Container networks
 
-If your container needs to use a proxy server, see
-[Use a proxy server](/manuals/engine/daemon/proxy.md).
+In addition to user-defined networks, you can attach a container to another
+container's networking stack directly, using the `--network
+container:<name|id>` flag format.
+
+The following flags aren't supported for containers using the `container:`
+networking mode:
+
+- `--add-host`
+- `--hostname`
+- `--dns`
+- `--dns-search`
+- `--dns-option`
+- `--mac-address`
+- `--publish`
+- `--publish-all`
+- `--expose`
+
+The following example runs a Redis container, with Redis binding to
+127.0.0.1, then running the `redis-cli` command and connecting to the Redis
+server over 127.0.0.1.
+
+```console
+$ docker run -d --name redis redis --bind 127.0.0.1
+$ docker run --rm -it --network container:redis redis redis-cli -h 127.0.0.1
+```
diff --git a/content/manuals/engine/network/drivers/_index.md b/content/manuals/engine/network/drivers/_index.md
index 3e9868995236..27b386ae19f3 100644
--- a/content/manuals/engine/network/drivers/_index.md
+++ b/content/manuals/engine/network/drivers/_index.md
@@ -66,12 +66,7 @@ exist by default, and provide core networking functionality:
 - Third-party network plugins allow you to integrate Docker with specialized
   network stacks.
 
-## Networking tutorials
+## Next steps
 
-Now that you understand the basics about Docker networks, deepen your
-understanding using the following tutorials:
-
-- [Standalone networking tutorial](/manuals/engine/network/tutorials/standalone.md)
-- [Host networking tutorial](/manuals/engine/network/tutorials/host.md)
-- [Overlay networking tutorial](/manuals/engine/network/tutorials/overlay.md)
-- [Macvlan networking tutorial](/manuals/engine/network/tutorials/macvlan.md)
+Each driver page includes detailed explanations, configuration options, and
+hands-on usage examples to help you work with that driver effectively.
diff --git a/content/manuals/engine/network/drivers/bridge.md b/content/manuals/engine/network/drivers/bridge.md
index 4f0b3268d368..74c452defd22 100644
--- a/content/manuals/engine/network/drivers/bridge.md
+++ b/content/manuals/engine/network/drivers/bridge.md
@@ -3,24 +3,35 @@ title: Bridge network driver
 description: All about using user-defined bridge networks and the default bridge
 keywords: network, bridge, user-defined, standalone
 aliases:
-- /config/containers/bridges/
-- /engine/userguide/networking/default_network/build-bridges/
-- /engine/userguide/networking/default_network/custom-docker0/
-- /engine/userguide/networking/work-with-networks/
-- /network/bridge/
-- /network/drivers/bridge/
+  - /config/containers/bridges/
+  - /engine/userguide/networking/default_network/build-bridges/
+  - /engine/userguide/networking/default_network/custom-docker0/
+  - /engine/userguide/networking/work-with-networks/
+  - /network/bridge/
+  - /network/drivers/bridge/
+  - /engine/network/tutorials/standalone/
 ---
 
-In terms of networking, a bridge network is a Link Layer device
-which forwards traffic between network segments. A bridge can be a hardware
-device or a software device running within a host machine's kernel.
+A Docker bridge network has an IPv4 subnet and, optionally, an IPv6 subnet.
+Each container connected to the bridge network has a network interface with
+addresses in the network's subnets. By default, it:
+
+- Allows unrestricted network access to containers in the network from
+  the host, and from other containers connected to the same bridge network.
+- Blocks access from containers in other networks and from outside the
+  Docker host.
+- Uses masquerading to give containers external network access. Devices on
+  the host's external networks only see the IP address of the Docker host.
+- Supports port publishing, where network traffic is forwarded between
+  container ports and ports on host IP addresses. The published ports
+  can be accessed from outside the Docker host, on its IP addresses.
 
 In terms of Docker, a bridge network uses a software bridge which lets
 containers connected to the same bridge network communicate, while providing
-isolation from containers that aren't connected to that bridge network. The
-Docker bridge driver automatically installs rules in the host machine so that
-containers on different bridge networks can't communicate directly with each
-other.
+isolation from containers that aren't connected to that bridge network. By
+default, the Docker bridge driver automatically installs rules in the host
+machine so that containers connected to different bridge networks can only
+communicate with each other using published ports.
 
 Bridge networks apply to containers running on the same Docker daemon host.
 For communication among containers running on different Docker daemon hosts, you
@@ -84,7 +95,6 @@ network.**
   was to link them using the [`--link` flag](../links.md). This type of
   variable sharing isn't possible with user-defined networks. However, there
   are superior ways to share environment variables. A few ideas:
-
   - Multiple containers can mount a file or directory containing the shared
     information, using a Docker volume.
 
@@ -105,16 +115,17 @@ flag.
 The following table describes the driver-specific options that you can pass to
 `--opt` when creating a custom network using the `bridge` driver.
 
-| Option                                                                                          | Default                     | Description                                                                                         |
-|-------------------------------------------------------------------------------------------------|-----------------------------|-----------------------------------------------------------------------------------------------------|
-| `com.docker.network.bridge.name`                                                                |                             | Interface name to use when creating the Linux bridge.                                               |
-| `com.docker.network.bridge.enable_ip_masquerade`                                                | `true`                      | Enable IP masquerading.                                                                             |
-| `com.docker.network.bridge.gateway_mode_ipv4`<br/>`com.docker.network.bridge.gateway_mode_ipv6` | `nat`                       | Control external connectivity. See [Packet filtering and firewalls](packet-filtering-firewalls.md). |
-| `com.docker.network.bridge.enable_icc`                                                          | `true`                      | Enable or Disable inter-container connectivity.                                                     |
-| `com.docker.network.bridge.host_binding_ipv4`                                                   | all IPv4 and IPv6 addresses | Default IP when binding container ports.                                                            |
-| `com.docker.network.driver.mtu`                                                                 | `0` (no limit)              | Set the containers network Maximum Transmission Unit (MTU).                                         |
-| `com.docker.network.container_iface_prefix`                                                     | `eth`                       | Set a custom prefix for container interfaces.                                                       |
-| `com.docker.network.bridge.inhibit_ipv4`                                                        | `false`                     | Prevent Docker from [assigning an IP address](#skip-bridge-ip-address-configuration) to the bridge. |
+| Option                                                                                          | Default                     | Description                                                                                                          |
+| ----------------------------------------------------------------------------------------------- | --------------------------- | -------------------------------------------------------------------------------------------------------------------- |
+| `com.docker.network.bridge.name`                                                                |                             | Interface name to use when creating the Linux bridge.                                                                |
+| `com.docker.network.bridge.enable_ip_masquerade`                                                | `true`                      | Enable IP masquerading.                                                                                              |
+| `com.docker.network.host_ipv4`<br/>`com.docker.network.host_ipv6`                               |                             | Address to use for source NAT. See [Port publishing](../port-publishing.md#masquerade-or-snat-for-outgoing-packets). |
+| `com.docker.network.bridge.gateway_mode_ipv4`<br/>`com.docker.network.bridge.gateway_mode_ipv6` | `nat`                       | Control external connectivity. See [Port publishing](../port-publishing.md#gateway-modes).                           |
+| `com.docker.network.bridge.enable_icc`                                                          | `true`                      | Enable or Disable inter-container connectivity.                                                                      |
+| `com.docker.network.bridge.host_binding_ipv4`                                                   | all IPv4 and IPv6 addresses | Default IP when binding container ports.                                                                             |
+| `com.docker.network.driver.mtu`                                                                 | `0` (no limit)              | Set the containers network Maximum Transmission Unit (MTU).                                                          |
+| `com.docker.network.container_iface_prefix`                                                     | `eth`                       | Set a custom prefix for container interfaces.                                                                        |
+| `com.docker.network.bridge.inhibit_ipv4`                                                        | `false`                     | Prevent Docker from [assigning an IP address](#skip-bridge-ip-address-configuration) to the bridge.                  |
 
 Some of these options are also available as flags to the `dockerd` CLI, and you
 can use them to configure the default `docker0` bridge when starting the Docker
@@ -167,7 +178,7 @@ $ docker network create my-net
 
 You can specify the subnet, the IP address range, the gateway, and other
 options. See the
-[docker network create](/reference/cli/docker/network/create.md#specify-advanced-options)
+[docker network create](/reference/cli/docker/network/create/#specify-advanced-options)
 reference or the output of `docker network create --help` for details.
 
 Use the `docker network rm` command to remove a user-defined bridge
@@ -269,7 +280,7 @@ the settings you need to customize.
   "fixed-cidr": "192.168.1.0/25",
   "mtu": 1500,
   "default-gateway": "192.168.1.254",
-  "dns": ["10.20.1.2","10.20.1.3"]
+  "dns": ["10.20.1.2", "10.20.1.3"]
 }
 ```
 
@@ -279,7 +290,6 @@ In this example:
 - The bridge network's subnet is "192.168.1.0/24" (from `bip`).
 - Container addresses will be allocated from "192.168.1.0/25" (from `fixed-cidr`).
 
-
 ### Use IPv6 with the default bridge network
 
 IPv6 can be enabled for the default bridge using the following options in
@@ -343,9 +353,326 @@ or a device attached to it.
 
 This option can only be used with user-defined bridge networks.
 
+## Usage examples
+
+This section provides hands-on examples for working with bridge networks.
+
+### Use the default bridge network
+
+This example shows how the default `bridge` network works. You start two
+`alpine` containers on the default bridge and test how they communicate.
+
+> [!NOTE]
+> The default `bridge` network is not recommended for production. Use
+> user-defined bridge networks instead.
+
+1. List current networks:
+
+   ```console
+   $ docker network ls
+
+   NETWORK ID          NAME                DRIVER              SCOPE
+   17e324f45964        bridge              bridge              local
+   6ed54d316334        host                host                local
+   7092879f2cc8        none                null                local
+   ```
+
+   The default `bridge` network is listed, along with `host` and `none`.
+
+2. Start two `alpine` containers running `ash`. The `-dit` flags mean detached,
+   interactive, and with a TTY. Since you haven't specified a `--network` flag,
+   the containers connect to the default `bridge` network.
+
+   ```console
+   $ docker run -dit --name alpine1 alpine ash
+   $ docker run -dit --name alpine2 alpine ash
+   ```
+
+   Verify both containers are running:
+
+   ```console
+   $ docker container ls
+
+   CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
+   602dbf1edc81        alpine              "ash"               4 seconds ago       Up 3 seconds                            alpine2
+   da33b7aa74b0        alpine              "ash"               17 seconds ago      Up 16 seconds                           alpine1
+   ```
+
+3. Inspect the `bridge` network to see connected containers:
+
+   ```console
+   $ docker network inspect bridge
+   ```
+
+   The output shows both containers connected, with their assigned IP addresses
+   (`172.17.0.2` for `alpine1` and `172.17.0.3` for `alpine2`).
+
+4. Connect to `alpine1`:
+
+   ```console
+   $ docker attach alpine1
+
+   / #
+   ```
+
+   Show the network interfaces for `alpine1` from within the container:
+
+   ```console
+   # ip addr show
+
+   1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
+       link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+       inet 127.0.0.1/8 scope host lo
+          valid_lft forever preferred_lft forever
+       inet6 ::1/128 scope host
+          valid_lft forever preferred_lft forever
+   27: eth0@if28: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
+       link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
+       inet 172.17.0.2/16 scope global eth0
+          valid_lft forever preferred_lft forever
+   ```
+
+   In this example, the `eth0` interface has the IP address `172.17.0.2`.
+
+5. From within `alpine1`, verify you can connect to the internet:
+
+   ```console
+   # ping -c 2 google.com
+
+   PING google.com (172.217.3.174): 56 data bytes
+   64 bytes from 172.217.3.174: seq=0 ttl=41 time=9.841 ms
+   64 bytes from 172.217.3.174: seq=1 ttl=41 time=9.897 ms
+
+   --- google.com ping statistics ---
+   2 packets transmitted, 2 packets received, 0% packet loss
+   round-trip min/avg/max = 9.841/9.869/9.897 ms
+   ```
+
+6. Ping the second container by its IP address:
+
+   ```console
+   # ping -c 2 172.17.0.3
+
+   PING 172.17.0.3 (172.17.0.3): 56 data bytes
+   64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.086 ms
+   64 bytes from 172.17.0.3: seq=1 ttl=64 time=0.094 ms
+
+   --- 172.17.0.3 ping statistics ---
+   2 packets transmitted, 2 packets received, 0% packet loss
+   round-trip min/avg/max = 0.086/0.090/0.094 ms
+   ```
+
+   This succeeds. Now try pinging by container name:
+
+   ```console
+   # ping -c 2 alpine2
+
+   ping: bad address 'alpine2'
+   ```
+
+   On the default bridge network, containers can't resolve each other by name.
+
+7. Detach from `alpine1` without stopping it using `CTRL+p CTRL+q`.
+
+8. Clean up: stop the containers and remove them.
+
+   ```console
+   $ docker container stop alpine1 alpine2
+   $ docker container rm alpine1 alpine2
+   ```
+
+   Stopped containers lose their IP addresses.
+
+### Use user-defined bridge networks
+
+This example shows how user-defined bridge networks provide better isolation
+and automatic DNS resolution between containers.
+
+1. Create the `alpine-net` network:
+
+   ```console
+   $ docker network create --driver bridge alpine-net
+   ```
+
+2. List Docker's networks:
+
+   ```console
+   $ docker network ls
+
+   NETWORK ID          NAME                DRIVER              SCOPE
+   e9261a8c9a19        alpine-net          bridge              local
+   17e324f45964        bridge              bridge              local
+   6ed54d316334        host                host                local
+   7092879f2cc8        none                null                local
+   ```
+
+   Inspect the `alpine-net` network:
+
+   ```console
+   $ docker network inspect alpine-net
+   ```
+
+   This shows the network's gateway (for example, `172.18.0.1`) and that no
+   containers are connected yet.
+
+3. Create four containers. Three connect to `alpine-net`, and one connects to
+   the default `bridge`. Then connect one container to both networks:
+
+   ```console
+   $ docker run -dit --name alpine1 --network alpine-net alpine ash
+   $ docker run -dit --name alpine2 --network alpine-net alpine ash
+   $ docker run -dit --name alpine3 alpine ash
+   $ docker run -dit --name alpine4 --network alpine-net alpine ash
+   $ docker network connect bridge alpine4
+   ```
+
+   Verify all containers are running:
+
+   ```console
+   $ docker container ls
+
+   CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
+   156849ccd902        alpine              "ash"               41 seconds ago       Up 41 seconds                           alpine4
+   fa1340b8d83e        alpine              "ash"               51 seconds ago       Up 51 seconds                           alpine3
+   a535d969081e        alpine              "ash"               About a minute ago   Up About a minute                       alpine2
+   0a02c449a6e9        alpine              "ash"               About a minute ago   Up About a minute                       alpine1
+   ```
+
+4. Inspect both networks again to see which containers are connected:
+
+   ```console
+   $ docker network inspect bridge
+   ```
+
+   Containers `alpine3` and `alpine4` are connected to the `bridge` network.
+
+   ```console
+   $ docker network inspect alpine-net
+   ```
+
+   Containers `alpine1`, `alpine2`, and `alpine4` are connected to
+   `alpine-net`.
+
+5. On user-defined networks, containers can resolve each other by name. Connect
+   to `alpine1` and test:
+
+   > [!NOTE]
+   > Automatic service discovery only resolves custom container names, not
+   > default automatically generated names.
+
+   ```console
+   $ docker container attach alpine1
+
+   # ping -c 2 alpine2
+
+   PING alpine2 (172.18.0.3): 56 data bytes
+   64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.085 ms
+   64 bytes from 172.18.0.3: seq=1 ttl=64 time=0.090 ms
+
+   --- alpine2 ping statistics ---
+   2 packets transmitted, 2 packets received, 0% packet loss
+   round-trip min/avg/max = 0.085/0.087/0.090 ms
+
+   # ping -c 2 alpine4
+
+   PING alpine4 (172.18.0.4): 56 data bytes
+   64 bytes from 172.18.0.4: seq=0 ttl=64 time=0.076 ms
+   64 bytes from 172.18.0.4: seq=1 ttl=64 time=0.091 ms
+
+   --- alpine4 ping statistics ---
+   2 packets transmitted, 2 packets received, 0% packet loss
+   round-trip min/avg/max = 0.076/0.083/0.091 ms
+   ```
+
+6. From `alpine1`, you can't connect to `alpine3` because it's on a different
+   network:
+
+   ```console
+   # ping -c 2 alpine3
+
+   ping: bad address 'alpine3'
+   ```
+
+   You also can't connect by IP address. If `alpine3`'s IP is `172.17.0.2`:
+
+   ```console
+   # ping -c 2 172.17.0.2
+
+   PING 172.17.0.2 (172.17.0.2): 56 data bytes
+
+   --- 172.17.0.2 ping statistics ---
+   2 packets transmitted, 0 packets received, 100% packet loss
+   ```
+
+   Detach from `alpine1` using `CTRL+p CTRL+q`.
+
+7. Since `alpine4` is connected to both networks, it can reach all containers.
+   However, you need to use `alpine3`'s IP address:
+
+   ```console
+   $ docker container attach alpine4
+
+   # ping -c 2 alpine1
+
+   PING alpine1 (172.18.0.2): 56 data bytes
+   64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.074 ms
+   64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.082 ms
+
+   --- alpine1 ping statistics ---
+   2 packets transmitted, 2 packets received, 0% packet loss
+   round-trip min/avg/max = 0.074/0.078/0.082 ms
+
+   # ping -c 2 alpine2
+
+   PING alpine2 (172.18.0.3): 56 data bytes
+   64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.075 ms
+   64 bytes from 172.18.0.3: seq=1 ttl=64 time=0.080 ms
+
+   --- alpine2 ping statistics ---
+   2 packets transmitted, 2 packets received, 0% packet loss
+   round-trip min/avg/max = 0.075/0.077/0.080 ms
+
+   # ping -c 2 alpine3
+   ping: bad address 'alpine3'
+
+   # ping -c 2 172.17.0.2
+
+   PING 172.17.0.2 (172.17.0.2): 56 data bytes
+   64 bytes from 172.17.0.2: seq=0 ttl=64 time=0.089 ms
+   64 bytes from 172.17.0.2: seq=1 ttl=64 time=0.075 ms
+
+   --- 172.17.0.2 ping statistics ---
+   2 packets transmitted, 2 packets received, 0% packet loss
+   round-trip min/avg/max = 0.075/0.082/0.089 ms
+   ```
+
+8. Verify all containers can connect to the internet:
+
+   ```console
+   # ping -c 2 google.com
+
+   PING google.com (172.217.3.174): 56 data bytes
+   64 bytes from 172.217.3.174: seq=0 ttl=41 time=9.778 ms
+   64 bytes from 172.217.3.174: seq=1 ttl=41 time=9.634 ms
+
+   --- google.com ping statistics ---
+   2 packets transmitted, 2 packets received, 0% packet loss
+   round-trip min/avg/max = 9.634/9.706/9.778 ms
+   ```
+
+   Detach with `CTRL+p CTRL+q` and repeat for `alpine3` and `alpine1` if
+   desired.
+
+9. Clean up:
+
+   ```console
+   $ docker container stop alpine1 alpine2 alpine3 alpine4
+   $ docker container rm alpine1 alpine2 alpine3 alpine4
+   $ docker network rm alpine-net
+   ```
+
 ## Next steps
 
-- Go through the [standalone networking tutorial](/manuals/engine/network/tutorials/standalone.md)
 - Learn about [networking from the container's point of view](../_index.md)
 - Learn about [overlay networks](./overlay.md)
 - Learn about [Macvlan networks](./macvlan.md)
diff --git a/content/manuals/engine/network/drivers/host.md b/content/manuals/engine/network/drivers/host.md
index 704fe5f095cf..50b94c03cabb 100644
--- a/content/manuals/engine/network/drivers/host.md
+++ b/content/manuals/engine/network/drivers/host.md
@@ -3,8 +3,9 @@ title: Host network driver
 description: All about exposing containers on the Docker host's network
 keywords: network, host, standalone, host mode networking
 aliases:
-- /network/host/
-- /network/drivers/host/
+  - /network/host/
+  - /network/drivers/host/
+  - /engine/network/tutorials/host/
 ---
 
 If you use the `host` network mode for a container, that container's network
@@ -17,8 +18,8 @@ address.
 > [!NOTE]
 >
 > Given that the container does not have its own IP-address when using
-> `host` mode networking, [port-mapping](overlay.md#publish-ports) doesn't
-> take effect, and the `-p`, `--publish`, `-P`, and `--publish-all` option are
+> `host` mode networking, [port mapping](../port-publishing.md) doesn't
+> take effect, and the `-p`, `--publish`, `-P`, and `--publish-all` options are
 > ignored, producing a warning instead:
 >
 > ```console
@@ -32,7 +33,17 @@ Host mode networking can be useful for the following use cases:
 
 This is because it doesn't require network address translation (NAT), and no "userland-proxy" is created for each port.
 
-The host networking driver is supported on Docker Engine (Linux only) and Docker Desktop version 4.34 and later.
+## Platform support
+
+The host networking driver is supported on:
+
+- Docker Engine on Linux
+- Docker Desktop version 4.34 and later (requires enabling the feature in
+  Settings)
+
+> [!NOTE]
+> For Docker Desktop users, see the [Docker Desktop section](#docker-desktop)
+> below for setup instructions.
 
 You can also use a `host` network for a swarm service, by passing `--network host`
 to the `docker service create` command. In this case, control traffic (traffic
@@ -93,19 +104,66 @@ $ nc localhost 80
 ### Limitations
 
 - Processes inside the container cannot bind to the IP addresses of the host
- because the container has no direct access to the interfaces of the host.
+  because the container has no direct access to the interfaces of the host.
 - The host network feature of Docker Desktop works on layer 4. This means that
-unlike with Docker on Linux, network protocols that operate below TCP or UDP are
-not supported.
+  unlike with Docker on Linux, network protocols that operate below TCP or UDP are
+  not supported.
 - This feature doesn't work with Enhanced Container Isolation enabled, since
-isolating your containers from the host and allowing them access to the host
-network contradict each other.
+  isolating your containers from the host and allowing them access to the host
+  network contradict each other.
 - Only Linux containers are supported. Host networking does not work with
   Windows containers.
 
+## Usage example
+
+This example shows how to start an Nginx container that binds directly to port
+80 on the Docker host. From a networking perspective, this provides the same
+level of isolation as if Nginx were running directly on the host, but the
+container remains isolated in all other aspects (storage, process namespace,
+user namespace).
+
+### Prerequisites
+
+- Port 80 must be available on the Docker host. To make Nginx listen on a
+  different port, see the [Nginx image documentation](https://hub.docker.com/_/nginx/).
+- The host networking driver only works on Linux hosts, and as an opt-in
+  feature in Docker Desktop version 4.34 and later.
+
+### Steps
+
+1. Create and start the container as a detached process. The `--rm` option
+   removes the container when it exits. The `-d` flag starts it in the
+   background:
+
+   ```console
+   $ docker run --rm -d --network host --name my_nginx nginx
+   ```
+
+2. Access Nginx by browsing to [http://localhost:80/](http://localhost:80/).
+
+3. Examine your network stack:
+
+   Check all network interfaces and verify that no new interface was created:
+
+   ```console
+   $ ip addr show
+   ```
+
+   Verify which process is bound to port 80 using `netstat`. You need `sudo`
+   because the process is owned by the Docker daemon user:
+
+   ```console
+   $ sudo netstat -tulpn | grep :80
+   ```
+
+4. Stop the container. It's removed automatically because of the `--rm` option:
+
+   ```console
+   $ docker container stop my_nginx
+   ```
+
 ## Next steps
 
-- Go through the [host networking tutorial](/manuals/engine/network/tutorials/host.md)
 - Learn about [networking from the container's point of view](../_index.md)
 - Learn about [bridge networks](./bridge.md)
 - Learn about [overlay networks](./overlay.md)
diff --git a/content/manuals/engine/network/drivers/ipvlan.md b/content/manuals/engine/network/drivers/ipvlan.md
index c5adad016eb9..f0547c49af68 100644
--- a/content/manuals/engine/network/drivers/ipvlan.md
+++ b/content/manuals/engine/network/drivers/ipvlan.md
@@ -1,18 +1,19 @@
 ---
 title: IPvlan network driver
-description: All about using IPvlan to make your containers appear like physical machines
+description:
+  All about using IPvlan to make your containers appear like physical machines
   on the network
-keywords: network, ipvlan, l2, l3, standalone
+keywords: network, ipvlan, l2, l3, standalone, ipv6, slaac
 aliases:
-- /network/ipvlan/
-- /network/drivers/ipvlan/
+  - /network/ipvlan/
+  - /network/drivers/ipvlan/
 ---
 
 The IPvlan driver gives users total control over both IPv4 and IPv6 addressing.
 The VLAN driver builds on top of that in giving operators complete control of
 layer 2 VLAN tagging and even IPvlan L3 routing for users interested in underlay
 network integration. For overlay deployments that abstract away physical constraints
-see the [multi-host overlay](/manuals/engine/network/tutorials/overlay.md) driver.
+see the [multi-host overlay](overlay.md) driver.
 
 IPvlan is a new twist on the tried and true network virtualization technique.
 The Linux implementations are extremely lightweight because rather than using
@@ -52,7 +53,7 @@ The following table describes the driver-specific options that you can pass to
   `docker network create` all together and the driver will create a `dummy`
   interface that will enable local host connectivity to perform the examples.
 - Kernel requirements:
-    - IPvlan Linux kernel v4.2+ (support for earlier kernels exists but is buggy). To check your current kernel version, use `uname -r`
+  - IPvlan Linux kernel v4.2+ (support for earlier kernels exists but is buggy). To check your current kernel version, use `uname -r`
 
 ### IPvlan L2 mode example usage
 
@@ -292,11 +293,11 @@ as parent interfaces. Example mappings from NetOps to Docker network commands
 are as follows:
 
 - VLAN: 10, Subnet: 172.16.80.0/24, Gateway: 172.16.80.1
-    - `--subnet=172.16.80.0/24 --gateway=172.16.80.1 -o parent=eth0.10`
+  - `--subnet=172.16.80.0/24 --gateway=172.16.80.1 -o parent=eth0.10`
 - VLAN: 20, IP subnet: 172.16.50.0/22, Gateway: 172.16.50.1
-    - `--subnet=172.16.50.0/22 --gateway=172.16.50.1 -o parent=eth0.20`
+  - `--subnet=172.16.50.0/22 --gateway=172.16.50.1 -o parent=eth0.20`
 - VLAN: 30, Subnet: 10.1.100.0/16, Gateway: 10.1.100.1
-    - `--subnet=10.1.100.0/16 --gateway=10.1.100.1 -o parent=eth0.30`
+  - `--subnet=10.1.100.0/16 --gateway=10.1.100.1 -o parent=eth0.30`
 
 ### IPvlan L3 mode example
 
@@ -511,6 +512,30 @@ $ docker run --net=ipvlan140 --ip=192.168.140.10 -it --rm alpine /bin/sh
 > subnet. However, IPvlan `L3` will route the unicast traffic between disparate
 > subnets as long as they share the same `-o parent` parent link.
 
+### Use router-assigned IPv6 addresses
+
+The previous examples assign IPv6 addresses from a subnet managed by Docker's
+IPAM. On an `ipvlan` network, you can instead let containers receive IPv6
+addresses directly from a router on the parent network, using stateless
+address autoconfiguration (SLAAC).
+
+When an `ipvlan` network has no IPv6 subnet, Docker disables IPv6 on the
+container's interface, so it can't accept the router advertisements that SLAAC
+relies on. To re-enable IPv6 on the interface, set its `disable_ipv6` sysctl
+to `0` when you connect the container to the network:
+
+```console
+$ docker network connect \
+    --driver-opt="com.docker.network.endpoint.sysctls=net.ipv6.conf.IFNAME.disable_ipv6=0" \
+    my-ipvlan-net my-container
+```
+
+Use the literal string `IFNAME` in the sysctl name. Docker replaces it with
+the name of the container's interface on this network. `disable_ipv6` is a
+per-interface sysctl, so it must be set with the `endpoint.sysctls`
+driver option rather than `docker run --sysctl`. For more details, see
+[`docker network connect`](/reference/cli/docker/network/connect/#sysctl).
+
 ### Dual stack IPv4 IPv6 IPvlan L3 mode
 
 Example: IPvlan L3 Mode Dual Stack IPv4/IPv6, Multi-Subnet w/ 802.1Q VLAN Tag:118
@@ -533,7 +558,7 @@ in order to forward broadcast and multicast packets.
 $ docker network create -d ipvlan \
     --subnet=192.168.110.0/24 \
     --subnet=192.168.112.0/24 \
-    --subnet=2001:db8:abc6::/64 \
+    --ipv6 --subnet=2001:db8:abc6::/64 \
     -o parent=eth0 \
     -o ipvlan_mode=l3 ipnet110
 
diff --git a/content/manuals/engine/network/drivers/macvlan.md b/content/manuals/engine/network/drivers/macvlan.md
index 43e67a7a04e3..2a65e19fc3ee 100644
--- a/content/manuals/engine/network/drivers/macvlan.md
+++ b/content/manuals/engine/network/drivers/macvlan.md
@@ -1,13 +1,15 @@
 ---
 title: Macvlan network driver
-description: All about using Macvlan to make your containers appear like physical
+description:
+  All about using Macvlan to make your containers appear like physical
   machines on the network
-keywords: network, macvlan, standalone
+keywords: network, macvlan, standalone, ipv6, slaac
 aliases:
-- /config/containers/macvlan/
-- /engine/userguide/networking/get-started-macvlan/
-- /network/macvlan/
-- /network/drivers/macvlan/
+  - /config/containers/macvlan/
+  - /engine/userguide/networking/get-started-macvlan/
+  - /network/macvlan/
+  - /network/drivers/macvlan/
+  - /engine/network/tutorials/macvlan/
 ---
 
 Some applications, especially legacy applications or applications which monitor
@@ -19,7 +21,17 @@ case, you need to designate a physical interface on your Docker host to use for
 the Macvlan, as well as the subnet and gateway of the network. You can even
 isolate your Macvlan networks using different physical network interfaces.
 
-Keep the following things in mind:
+## Platform support and requirements
+
+- The macvlan driver only works on Linux hosts. It is not supported on
+  Docker Desktop for Mac or Windows, or Docker Engine on Windows.
+- Most cloud providers block macvlan networking. You may need physical access to
+  your networking equipment.
+- Requires at least Linux kernel version 3.9 (version 4.0 or later is
+  recommended).
+- The macvlan driver is not supported in rootless mode.
+
+## Considerations
 
 - You may unintentionally degrade your network due to IP address
   exhaustion or to "VLAN spread", a situation that occurs when you have an
@@ -32,6 +44,13 @@ Keep the following things in mind:
   overlay (to communicate across multiple Docker hosts), these solutions may be
   better in the long term.
 
+- Containers attached to a macvlan network cannot communicate with the host
+  directly, this is a restriction in the Linux kernel. If you need communication
+  between the host and the containers, you can connect the containers to a
+  bridge network as well as the macvlan. It is also possible to create a
+  macvlan interface on the host with the same parent interface, and assign it
+  an IP address in the Docker network's subnet.
+
 ## Options
 
 The following table describes the driver-specific options that you can pass to
@@ -94,15 +113,23 @@ $ docker network create -d macvlan \
 
 ### Use an IPvlan instead of Macvlan
 
-In the above example, you are still using a L3 bridge. You can use `ipvlan`
-instead, and get an L2 bridge. Specify `-o ipvlan_mode=l2`.
+An `ipvlan` network created with option `-o ipvlan_mode=l2` is similar
+to a macvlan network. The main difference is that the `ipvlan` driver
+doesn't assign a MAC address to each container, the layer-2 network stack
+is shared by devices in the ipvlan network. So, containers use the parent
+interface's MAC address.
+
+The network will see fewer MAC addresses, and the host's MAC address will be
+associated with the IP address of each container.
+
+The choice of network type depends on your environment and requirements.
+There are some notes about the trade-offs in the [Linux kernel
+documentation](https://docs.kernel.org/networking/ipvlan.html#what-to-choose-macvlan-vs-ipvlan).
 
 ```console
 $ docker network create -d ipvlan \
     --subnet=192.168.210.0/24 \
-    --subnet=192.168.212.0/24 \
     --gateway=192.168.210.254 \
-    --gateway=192.168.212.254 \
      -o ipvlan_mode=l2 -o parent=eth0 ipvlan210
 ```
 
@@ -120,7 +147,191 @@ $ docker network create -d macvlan \
      -o macvlan_mode=bridge macvlan216
 ```
 
-## Next steps
+### Use router-assigned IPv6 addresses
+
+The previous example assigns IPv6 addresses from a subnet managed by Docker's
+IPAM. On a `macvlan` network, you can instead let containers receive IPv6
+addresses directly from a router on the parent network, using stateless
+address autoconfiguration (SLAAC).
+
+When a `macvlan` network has no IPv6 subnet, Docker disables IPv6 on the
+container's interface, so it can't accept the router advertisements that SLAAC
+relies on. To re-enable IPv6 on the interface, set its `disable_ipv6` sysctl
+to `0` when you connect the container to the network:
+
+```console
+$ docker network connect \
+    --driver-opt="com.docker.network.endpoint.sysctls=net.ipv6.conf.IFNAME.disable_ipv6=0" \
+    my-macvlan-net my-container
+```
+
+Use the literal string `IFNAME` in the sysctl name. Docker replaces it with
+the name of the container's interface on this network. `disable_ipv6` is a
+per-interface sysctl, so it must be set with the `endpoint.sysctls`
+driver option rather than `docker run --sysctl`. For more details, see
+[`docker network connect`](/reference/cli/docker/network/connect/#sysctl).
+
+## Usage examples
+
+This section provides hands-on examples for working with macvlan networks,
+including bridge mode and 802.1Q trunk bridge mode.
+
+> [!NOTE]
+> These examples assume your ethernet interface is `eth0`. If your device has a
+> different name, use that instead.
+
+### Bridge mode example
+
+In bridge mode, your traffic flows through `eth0` and Docker routes traffic to
+your container using its MAC address. To network devices on your network, your
+container appears to be physically attached to the network.
+
+1. Create a macvlan network called `my-macvlan-net`. Modify the `subnet`,
+   `gateway`, and `parent` values to match your environment:
+
+   ```console
+   $ docker network create -d macvlan \
+     --subnet=172.16.86.0/24 \
+     --gateway=172.16.86.1 \
+     -o parent=eth0 \
+     my-macvlan-net
+   ```
+
+   Verify the network was created:
+
+   ```console
+   $ docker network ls
+   $ docker network inspect my-macvlan-net
+   ```
+
+2. Start an `alpine` container and attach it to the `my-macvlan-net` network.
+   The `-dit` flags start the container in the background. The `--rm` flag
+   removes the container when it stops:
+
+   ```console
+   $ docker run --rm -dit \
+     --network my-macvlan-net \
+     --name my-macvlan-alpine \
+     alpine:latest \
+     ash
+   ```
+
+3. Inspect the container and notice the `MacAddress` key within the `Networks`
+   section:
+
+   ```console
+   $ docker container inspect my-macvlan-alpine
+   ```
+
+   Look for output similar to:
+
+   ```json
+   "Networks": {
+     "my-macvlan-net": {
+       "Gateway": "172.16.86.1",
+       "IPAddress": "172.16.86.2",
+       "IPPrefixLen": 24,
+       "MacAddress": "02:42:ac:10:56:02",
+       ...
+     }
+   }
+   ```
+
+4. Check how the container sees its own network interfaces:
+
+   ```console
+   $ docker exec my-macvlan-alpine ip addr show eth0
+
+   9: eth0@tunl0: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
+   link/ether 02:42:ac:10:56:02 brd ff:ff:ff:ff:ff:ff
+   inet 172.16.86.2/24 brd 172.16.86.255 scope global eth0
+      valid_lft forever preferred_lft forever
+   ```
+
+   Check the routing table:
+
+   ```console
+   $ docker exec my-macvlan-alpine ip route
+
+   default via 172.16.86.1 dev eth0
+   172.16.86.0/24 dev eth0 scope link  src 172.16.86.2
+   ```
+
+5. Stop the container (Docker removes it automatically) and remove the network:
+
+   ```console
+   $ docker container stop my-macvlan-alpine
+   $ docker network rm my-macvlan-net
+   ```
+
+### 802.1Q trunked bridge mode example
+
+In 802.1Q trunk bridge mode, your traffic flows through a sub-interface of
+`eth0` (called `eth0.10`) and Docker routes traffic to your container using its
+MAC address. To network devices on your network, your container appears to be
+physically attached to the network.
+
+1. Create a macvlan network called `my-8021q-macvlan-net`. Modify the `subnet`,
+   `gateway`, and `parent` values to match your environment:
+
+   ```console
+   $ docker network create -d macvlan \
+     --subnet=172.16.86.0/24 \
+     --gateway=172.16.86.1 \
+     -o parent=eth0.10 \
+     my-8021q-macvlan-net
+   ```
+
+   Verify the network was created and has parent `eth0.10`. You can use `ip addr
+show` on the Docker host to verify that the interface `eth0.10` exists:
+
+   ```console
+   $ docker network ls
+   $ docker network inspect my-8021q-macvlan-net
+   ```
+
+2. Start an `alpine` container and attach it to the `my-8021q-macvlan-net`
+   network:
+
+   ```console
+   $ docker run --rm -itd \
+     --network my-8021q-macvlan-net \
+     --name my-second-macvlan-alpine \
+     alpine:latest \
+     ash
+   ```
+
+3. Inspect the container and notice the `MacAddress` key:
+
+   ```console
+   $ docker container inspect my-second-macvlan-alpine
+   ```
+
+   Look for the `Networks` section with the MAC address.
+
+4. Check how the container sees its own network interfaces:
+
+   ```console
+   $ docker exec my-second-macvlan-alpine ip addr show eth0
+
+   11: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
+   link/ether 02:42:ac:10:56:02 brd ff:ff:ff:ff:ff:ff
+   inet 172.16.86.2/24 brd 172.16.86.255 scope global eth0
+      valid_lft forever preferred_lft forever
+   ```
+
+   Check the routing table:
+
+   ```console
+   $ docker exec my-second-macvlan-alpine ip route
+
+   default via 172.16.86.1 dev eth0
+   172.16.86.0/24 dev eth0 scope link  src 172.16.86.2
+   ```
+
+5. Stop the container and remove the network:
 
-Learn how to use the Macvlan driver in the
-[Macvlan networking tutorial](/manuals/engine/network/tutorials/macvlan.md).
+   ```console
+   $ docker container stop my-second-macvlan-alpine
+   $ docker network rm my-8021q-macvlan-net
+   ```
diff --git a/content/manuals/engine/network/drivers/none.md b/content/manuals/engine/network/drivers/none.md
index 9a42ca3cb3c2..d0715b1ff4f3 100644
--- a/content/manuals/engine/network/drivers/none.md
+++ b/content/manuals/engine/network/drivers/none.md
@@ -3,8 +3,8 @@ title: None network driver
 description: How to isolate the networking stack of a container using the none driver
 keywords: network, none, standalone
 aliases:
-- /network/none/
-- /network/drivers/none/
+  - /network/none/
+  - /network/drivers/none/
 ---
 
 If you want to completely isolate the networking stack of a container, you can
@@ -32,8 +32,8 @@ $ docker run --rm --network none --name no-net-alpine alpine:latest ip addr show
 
 ## Next steps
 
-- Go through the [host networking tutorial](/manuals/engine/network/tutorials/host.md)
 - Learn about [networking from the container's point of view](../_index.md)
+- Learn about [host networking](host.md)
 - Learn about [bridge networks](bridge.md)
 - Learn about [overlay networks](overlay.md)
 - Learn about [Macvlan networks](macvlan.md)
diff --git a/content/manuals/engine/network/drivers/overlay.md b/content/manuals/engine/network/drivers/overlay.md
index 043e2ddc3ec0..da5e72fd2b3c 100644
--- a/content/manuals/engine/network/drivers/overlay.md
+++ b/content/manuals/engine/network/drivers/overlay.md
@@ -3,10 +3,13 @@ title: Overlay network driver
 description: All about using overlay networks
 keywords: network, overlay, user-defined, swarm, service
 aliases:
-- /config/containers/overlay/
-- /engine/userguide/networking/overlay-security-model/
-- /network/overlay/
-- /network/drivers/overlay/
+  - /config/containers/overlay/
+  - /engine/userguide/networking/overlay-security-model/
+  - /network/overlay/
+  - /network/drivers/overlay/
+  - /network/network-tutorial-overlay/
+  - /engine/network/tutorials/overlay/
+  - /engine/userguide/networking/get-started-overlay/
 ---
 
 The `overlay` network driver creates a distributed network among multiple
@@ -29,16 +32,19 @@ This page describes overlay networks in general, and when used with standalone
 containers. For information about overlay for Swarm services, see
 [Manage Swarm service networks](/manuals/engine/swarm/networking.md).
 
-## Create an overlay network
+## Requirements
+
+Docker hosts must be part of a swarm to use overlay networks, even when
+connecting standalone containers. The following ports must be open between
+participating hosts:
 
-Before you start, you must ensure that participating nodes can communicate over the network.
-The following table lists ports that need to be open to each host participating in an overlay network:
+| Ports                  | Description                                                                                                                                             |
+| :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `2377/tcp`             | The default Swarm control plane port, is configurable with [`docker swarm join --listen-addr`](/reference/cli/docker/swarm/join/#listen-addr) |
+| `4789/udp`             | The default overlay traffic port, configurable with [`docker swarm init --data-path-port`](/reference/cli/docker/swarm/init/#data-path-port)          |
+| `7946/tcp`, `7946/udp` | Used for communication among nodes, not configurable                                                                                                    |
 
-| Ports                  | Description                                                                                                                                                          |
-| :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `2377/tcp`             | The default Swarm control plane port, is configurable with [`docker swarm join --listen-addr`](/reference/cli/docker/swarm/join.md#--listen-addr-value) |
-| `4789/udp`             | The default overlay traffic port, configurable with [`docker swarm init --data-path-addr`](/reference/cli/docker/swarm/init.md#data-path-port)          |
-| `7946/tcp`, `7946/udp` | Used for communication among nodes, not configurable                                                                                                                 |
+## Create an overlay network
 
 To create an overlay network that containers on other Docker hosts can connect to,
 run the following command:
@@ -122,9 +128,357 @@ the same host.
 For more information about this limitation, see
 [moby/moby#44973](https://github.com/moby/moby/issues/44973#issuecomment-1543747718).
 
+## Usage examples
+
+This section provides hands-on examples for working with overlay networks. These
+examples cover swarm services and standalone containers on multiple Docker hosts.
+
+### Prerequisites
+
+All examples require at least a single-node swarm. Initialize one by running
+`docker swarm init` on the host. You can run these examples on multi-node
+swarms as well.
+
+### Use the default overlay network
+
+This example shows how the default overlay network works with swarm services.
+You'll create an `nginx` service and examine the network from the service
+containers' perspective.
+
+#### Prerequisites for multi-node setup
+
+This walkthrough requires three Docker hosts that can communicate with each
+other on the same network with no firewall blocking traffic between them:
+
+- `manager`: Functions as both manager and worker
+- `worker-1`: Functions as worker only
+- `worker-2`: Functions as worker only
+
+If you don't have three hosts available, you can set up three virtual machines
+on a cloud provider with Docker installed.
+
+#### Create the swarm
+
+1. On `manager`, initialize the swarm. If the host has one network interface,
+   the `--advertise-addr` flag is optional:
+
+   ```console
+   $ docker swarm init --advertise-addr=<IP-ADDRESS-OF-MANAGER>
+   ```
+
+   Save the join token displayed for use with workers.
+
+2. On `worker-1`, join the swarm:
+
+   ```console
+   $ docker swarm join --token <TOKEN> \
+     --advertise-addr <IP-ADDRESS-OF-WORKER-1> \
+     <IP-ADDRESS-OF-MANAGER>:2377
+   ```
+
+3. On `worker-2`, join the swarm:
+
+   ```console
+   $ docker swarm join --token <TOKEN> \
+     --advertise-addr <IP-ADDRESS-OF-WORKER-2> \
+     <IP-ADDRESS-OF-MANAGER>:2377
+   ```
+
+4. On `manager`, list all nodes:
+
+   ```console
+   $ docker node ls
+
+   ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS
+   d68ace5iraw6whp7llvgjpu48 *   ip-172-31-34-146    Ready               Active              Leader
+   nvp5rwavvb8lhdggo8fcf7plg     ip-172-31-35-151    Ready               Active
+   ouvx2l7qfcxisoyms8mtkgahw     ip-172-31-36-89     Ready               Active
+   ```
+
+   Filter by role if needed:
+
+   ```console
+   $ docker node ls --filter role=manager
+   $ docker node ls --filter role=worker
+   ```
+
+5. List Docker networks on all hosts. Each now has an overlay network called
+   `ingress` and a bridge network called `docker_gwbridge`:
+
+   ```console
+   $ docker network ls
+
+   NETWORK ID          NAME                DRIVER              SCOPE
+   495c570066be        bridge              bridge              local
+   961c6cae9945        docker_gwbridge     bridge              local
+   ff35ceda3643        host                host                local
+   trtnl4tqnc3n        ingress             overlay             swarm
+   c8357deec9cb        none                null                local
+   ```
+
+The `docker_gwbridge` connects the `ingress` network to the Docker host's
+network interface. If you create services without specifying a network, they
+connect to `ingress`. It's recommended to use separate overlay networks for each
+application or group of related applications.
+
+#### Create the services
+
+1. On `manager`, create a new overlay network:
+
+   ```console
+   $ docker network create -d overlay nginx-net
+   ```
+
+   The overlay network is automatically created on worker nodes when they run
+   service tasks that need it.
+
+2. On `manager`, create a 5-replica Nginx service connected to `nginx-net`:
+
+   > [!NOTE]
+   > Services can only be created on a manager.
+
+   ```console
+   $ docker service create \
+     --name my-nginx \
+     --publish target=80,published=80 \
+     --replicas=5 \
+     --network nginx-net \
+     nginx
+   ```
+
+   The default `ingress` publish mode means you can browse to port 80 on any
+   node and connect to one of the 5 service tasks, even if no tasks run on that
+   node.
+
+3. Monitor service creation progress:
+
+   ```console
+   $ docker service ls
+   ```
+
+4. Inspect the `nginx-net` network on all hosts. The `Containers` section lists
+   all service tasks connected to the overlay network from that host.
+
+5. From `manager`, inspect the service:
+
+   ```console
+   $ docker service inspect my-nginx
+   ```
+
+   Notice the information about ports and endpoints.
+
+6. Create a second network and update the service to use it:
+
+   ```console
+   $ docker network create -d overlay nginx-net-2
+   $ docker service update \
+     --network-add nginx-net-2 \
+     --network-rm nginx-net \
+     my-nginx
+   ```
+
+7. Verify the update completed:
+
+   ```console
+   $ docker service ls
+   ```
+
+   Inspect both networks to verify containers moved from `nginx-net` to
+   `nginx-net-2`.
+
+   > [!NOTE]
+   > Overlay networks are automatically created on swarm worker nodes as needed,
+   > but aren't automatically removed.
+
+8. Clean up:
+
+   ```console
+   $ docker service rm my-nginx
+   $ docker network rm nginx-net nginx-net-2
+   ```
+
+### Use a user-defined overlay network
+
+This example shows the recommended approach for production services using custom
+overlay networks.
+
+#### Prerequisites
+
+This assumes the swarm is already set up and you're on a manager node.
+
+#### Steps
+
+1. Create a user-defined overlay network:
+
+   ```console
+   $ docker network create -d overlay my-overlay
+   ```
+
+2. Start a service using the overlay network, publishing port 80 to port 8080:
+
+   ```console
+   $ docker service create \
+     --name my-nginx \
+     --network my-overlay \
+     --replicas 1 \
+     --publish published=8080,target=80 \
+     nginx:latest
+   ```
+
+3. Verify the service task is connected to the network:
+
+   ```console
+   $ docker network inspect my-overlay
+   ```
+
+   Check the `Containers` section for the `my-nginx` service task.
+
+4. Clean up:
+
+   ```console
+   $ docker service rm my-nginx
+   $ docker network rm my-overlay
+   ```
+
+### Use an overlay network for standalone containers
+
+This example demonstrates DNS container discovery between standalone containers
+on different Docker hosts using an overlay network.
+
+#### Prerequisites
+
+You need two Docker hosts that can communicate with each other with the
+following ports open between them:
+
+- TCP port 2377
+- TCP and UDP port 7946
+- UDP port 4789
+
+This example refers to the hosts as `host1` and `host2`.
+
+#### Steps
+
+1. Set up the swarm:
+
+   On `host1`, initialize a swarm:
+
+   ```console
+   $ docker swarm init
+   Swarm initialized: current node (vz1mm9am11qcmo979tlrlox42) is now a manager.
+
+   To add a worker to this swarm, run the following command:
+
+       docker swarm join --token SWMTKN-1-5g90q48weqrtqryq4kj6ow0e8xm9wmv9o6vgqc5j320ymybd5c-8ex8j0bc40s6hgvy5ui5gl4gy 172.31.47.252:2377
+   ```
+
+   On `host2`, join the swarm using the token from the previous output:
+
+   ```console
+   $ docker swarm join --token <your_token> <your_ip_address>:2377
+   This node joined a swarm as a worker.
+   ```
+
+   If the join fails, run `docker swarm leave --force` on `host2`, verify
+   network and firewall settings, and try again.
+
+2. On `host1`, create an attachable overlay network:
+
+   ```console
+   $ docker network create --driver=overlay --attachable test-net
+   uqsof8phj3ak0rq9k86zta6ht
+   ```
+
+   Note the returned network ID.
+
+3. On `host1`, start an interactive container that connects to `test-net`:
+
+   ```console
+   $ docker run -it --name alpine1 --network test-net alpine
+   / #
+   ```
+
+4. On `host2`, list available networks. Notice that `test-net` doesn't exist yet:
+
+   ```console
+   $ docker network ls
+   NETWORK ID          NAME                DRIVER              SCOPE
+   ec299350b504        bridge              bridge              local
+   66e77d0d0e9a        docker_gwbridge     bridge              local
+   9f6ae26ccb82        host                host                local
+   omvdxqrda80z        ingress             overlay             swarm
+   b65c952a4b2b        none                null                local
+   ```
+
+5. On `host2`, start a detached, interactive container that connects to
+   `test-net`:
+
+   ```console
+   $ docker run -dit --name alpine2 --network test-net alpine
+   fb635f5ece59563e7b8b99556f816d24e6949a5f6a5b1fbd92ca244db17a4342
+   ```
+
+   > [!NOTE]
+   > Automatic DNS container discovery only works with unique container names.
+
+6. On `host2`, verify that `test-net` was created with the same network ID as on
+   `host1`:
+
+   ```console
+   $ docker network ls
+   NETWORK ID          NAME                DRIVER              SCOPE
+   ...
+   uqsof8phj3ak        test-net            overlay             swarm
+   ```
+
+7. On `host1`, ping `alpine2` from within `alpine1`:
+
+   ```console
+   / # ping -c 2 alpine2
+   PING alpine2 (10.0.0.5): 56 data bytes
+   64 bytes from 10.0.0.5: seq=0 ttl=64 time=0.600 ms
+   64 bytes from 10.0.0.5: seq=1 ttl=64 time=0.555 ms
+
+   --- alpine2 ping statistics ---
+   2 packets transmitted, 2 packets received, 0% packet loss
+   round-trip min/avg/max = 0.555/0.577/0.600 ms
+   ```
+
+   The two containers communicate over the overlay network connecting the two
+   hosts. You can also run another container on `host2` and ping `alpine1`:
+
+   ```console
+   $ docker run -it --rm --name alpine3 --network test-net alpine
+   / # ping -c 2 alpine1
+   / # exit
+   ```
+
+8. On `host1`, close the `alpine1` session (which stops the container):
+
+   ```console
+   / # exit
+   ```
+
+9. Clean up. You must stop and remove containers on each host independently:
+
+   On `host2`:
+
+   ```console
+   $ docker container stop alpine2
+   $ docker network ls
+   $ docker container rm alpine2
+   ```
+
+   When you stop `alpine2`, `test-net` disappears from `host2`.
+
+   On `host1`:
+
+   ```console
+   $ docker container rm alpine1
+   $ docker network rm test-net
+   ```
+
 ## Next steps
 
-- Go through the [overlay networking tutorial](/manuals/engine/network/tutorials/overlay.md)
 - Learn about [networking from the container's point of view](../_index.md)
 - Learn about [standalone bridge networks](bridge.md)
 - Learn about [Macvlan networks](macvlan.md)
diff --git a/content/manuals/engine/network/firewall-iptables.md b/content/manuals/engine/network/firewall-iptables.md
new file mode 100644
index 000000000000..b66c653dcc82
--- /dev/null
+++ b/content/manuals/engine/network/firewall-iptables.md
@@ -0,0 +1,157 @@
+---
+title: Docker with iptables
+weight: 10
+description: How Docker works with iptables
+keywords: network, iptables, firewall
+---
+
+Docker creates iptables rules in the host's network namespace for bridge
+networks. For bridge and other network types, iptables rules for DNS are
+also created in the container's network namespace.
+
+Creation of iptables rules can be disabled using daemon options `iptables`
+and `ip6tables`, see [Prevent Docker from manipulating firewall rules](packet-filtering-firewalls.md#prevent-docker-from-manipulating-firewall-rules).
+However, this is not recommended for most users as it will likely break
+container networking.
+
+### Docker and iptables chains
+
+To support bridge and overlay networks, Docker creates the following custom
+`iptables` chains in the `filter` table:
+
+* `DOCKER-USER`
+    * A placeholder for user-defined rules that will be processed before rules
+      in the `DOCKER-FORWARD` and `DOCKER` chains.
+* `DOCKER-FORWARD`
+    * The first stage of processing for Docker's networks. Rules that pass packets
+      that are not related to established connections to the other Docker chains,
+      as well as rules to accept packets that are part of established connections.
+* `DOCKER`, `DOCKER-BRIDGE`, `DOCKER-INTERNAL`
+    * Rules that determine whether a packet that is not part of an established 
+      connection should be accepted, based on the port forwarding configuration
+      of running containers.
+* `DOCKER-CT`
+    * Per-bridge connection tracking rules.
+* `DOCKER-INGRESS`
+    * Rules related to Swarm networking.
+
+In the `FORWARD` chain, Docker adds rules that unconditionally jump to the
+`DOCKER-USER`, `DOCKER-FORWARD` and `DOCKER-INGRESS` chains.
+
+In the `nat` table, Docker creates chain `DOCKER` and adds rules to implement
+masquerading and port-mapping.
+
+Docker requires IP Forwarding to be enabled on the host for its default
+bridge network configuration. If it enables IP Forwarding, it also sets the
+default policy of the iptables `FORWARD` chain in the `filter` table to `DROP`.
+
+### Add iptables policies before Docker's rules
+
+Packets that get accepted or rejected by rules in these custom chains will not
+be seen by user-defined rules appended to the `FORWARD` chain. So, to add
+additional rules to filter these packets, use the `DOCKER-USER` chain.
+
+Rules appended to the `FORWARD` chain will be processed after Docker's rules.
+
+> [!NOTE]
+>
+> By default, remote hosts can only reach a container through a port published
+> to one of the Docker host's addresses. Sending packets to the container's own
+> IP address instead ("direct routed" access) is not allowed.
+>
+> These packets are dropped by a rule in the `raw` table's `PREROUTING` chain,
+> which is processed before the `filter` table. So, they never reach the
+> `DOCKER-USER` chain, and a rule in `DOCKER-USER` cannot allow them.
+>
+> Any packet that reaches the host's firewall rules already addressed to a
+> container is treated this way. For example, a Kubernetes CNI plugin may
+> translate a Service address to a container address before the packet reaches
+> the host's `PREROUTING` rules. Docker cannot distinguish the result from a
+> packet routed to the container by a remote host. Which host interface these
+> packets arrive on depends on the plugin's data path — for an overlay network
+> it is normally the tunnel device.
+>
+> To allow direct routed access to a container's *published* ports, use network
+> option `com.docker.network.bridge.trusted_host_interfaces`, or daemon option
+> `allow-direct-routing`. Unpublished ports are still protected. See
+> [Direct routing to containers in bridge networks](./port-publishing.md#direct-routing-to-containers-in-bridge-networks).
+> To allow direct routed access to all container ports, published or not, see
+> [Gateway modes](./port-publishing.md#gateway-modes).
+
+### Match the original IP and ports for requests
+
+When packets arrive to the `DOCKER-USER` chain, they have already passed through
+a Destination Network Address Translation (DNAT) filter. That means that the
+`iptables` flags you use can only match internal IP addresses and ports of
+containers.
+
+If you want to match traffic based on the original IP and port in the network
+request, you must use the
+[`conntrack` iptables extension](https://ipset.netfilter.org/iptables-extensions.man.html#lbAO).
+For example:
+
+```console
+$ sudo iptables -I DOCKER-USER -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
+$ sudo iptables -I DOCKER-USER -p tcp -m conntrack --ctorigdst 198.51.100.2 --ctorigdstport 80 -j ACCEPT
+```
+
+> [!IMPORTANT]
+>
+> Using the `conntrack` extension may result in degraded performance.
+
+### Allow forwarding between host interfaces
+
+If Docker has set the default policy of the `FORWARD` chain in the `filter`
+table to `DROP`, a rule in `DOCKER-USER` can be used to allow forwarding
+between host interfaces. For example:
+
+```console
+$ iptables -I DOCKER-USER -i src_if -o dst_if -j ACCEPT
+```
+
+### Restrict external connections to containers
+
+By default, all external source IPs are allowed to connect to ports that have
+been published to the Docker host's addresses.
+
+To allow only a specific IP or network to access the containers, insert a
+negated rule at the top of the `DOCKER-USER` filter chain. For example, the
+following rule drops packets from all IP addresses except `192.0.2.2`:
+
+```console
+$ iptables -I DOCKER-USER -i ext_if ! -s 192.0.2.2 -j DROP
+```
+
+You will need to change `ext_if` to correspond with your
+host's actual external interface. You could instead allow connections from a
+source subnet. The following rule only allows access from the subnet `192.0.2.0/24`:
+
+```console
+$ iptables -I DOCKER-USER -i ext_if ! -s 192.0.2.0/24 -j DROP
+```
+
+Finally, you can specify a range of IP addresses to accept using `--src-range`
+(Remember to also add `-m iprange` when using `--src-range` or `--dst-range`):
+
+```console
+$ iptables -I DOCKER-USER -m iprange -i ext_if ! --src-range 192.0.2.1-192.0.2.3 -j DROP
+```
+
+You can combine `-s` or `--src-range` with `-d` or `--dst-range` to control both
+the source and destination. For example, if the Docker host has addresses
+`2001:db8:1111::2` and `2001:db8:2222::2`, you can make rules specific to
+`2001:db8:1111::2` and leave `2001:db8:2222::2` open.
+
+You may need to allow responses from servers outside the permitted external address
+ranges. For example, containers may send DNS or HTTP requests to hosts that are
+not allowed to access the container's services. The following rule accepts any
+incoming or outgoing packet belonging to a flow that has already been accepted
+by other rules. It must be placed before `DROP` rules that restrict access from
+external address ranges.
+
+```console
+$ iptables -I DOCKER-USER -m state --state RELATED,ESTABLISHED -j ACCEPT
+```
+
+For more information about iptables configuration and advanced usage,
+refer to the [Netfilter.org HOWTO](https://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html).
diff --git a/content/manuals/engine/network/firewall-nftables.md b/content/manuals/engine/network/firewall-nftables.md
new file mode 100644
index 000000000000..b3440a1f23de
--- /dev/null
+++ b/content/manuals/engine/network/firewall-nftables.md
@@ -0,0 +1,302 @@
+---
+title: Docker with nftables
+weight: 10
+description: How Docker works with nftables
+keywords: network, nftables, firewall
+---
+
+> [!WARNING]
+>
+> Support for nftables introduced in Docker 29.0.0 is experimental, configuration
+> options, behavior and implementation may all change in future releases.
+> The rules for overlay networks have not yet been migrated from iptables.
+> Therefore, nftables cannot be enabled when the Docker daemon is running in
+> Swarm mode.
+
+To use nftables instead of iptables, use Docker Engine option
+`--firewall-backend=nftables` on its command line, or `"firewall-backend": "nftables"`
+in its configuration file. You may also need to modify IP forwarding configuration
+on the host, and migrate rules from the iptables `DOCKER-USER` chain, see
+[migrating from iptables to nftables](#migrating-from-iptables-to-nftables).
+
+For bridge networks, Docker creates nftables rules in the host's network
+namespace. For bridge and other network types, nftables rules for DNS are
+also created in the container's network namespace.
+
+Creation of nftables rules can be disabled using daemon options `iptables`
+and `ip6tables`. _These options apply to both iptables and nftables._
+See [Prevent Docker from manipulating firewall rules](packet-filtering-firewalls.md#prevent-docker-from-manipulating-firewall-rules).
+However, this is not recommended for most users as it will likely break
+container networking.
+
+## Docker's nftables tables
+
+For bridge networks, Docker creates two tables, `ip docker-bridges` and
+`ip6 docker-bridges`.
+
+Each table contains a number of [base chains](https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Adding_base_chains),
+and further chains are added for each bridge network. The moby project
+has some [internal documentation](https://github.com/moby/moby/blob/master/integration/network/bridge/nftablesdoc/index.md)
+describing its nftables, and how they depend on network and container
+configuration. However, the tables and their rules are likely to change
+between Docker Engine releases.
+
+> [!NOTE]
+>
+> Do not modify Docker's tables directly as the modifications are likely to
+> be lost, Docker expects to have full ownership of its tables.
+
+> [!NOTE]
+>
+> Because iptables has a fixed set of chains, equivalent to nftables base
+> chains, all rules are included in those chains. The `DOCKER-USER` chain
+> is supplied as a way to insert rules into the `filter` table's `FORWARD`
+> chain, to run before Docker's rules.
+> In Docker's nftables implementation, there is no `DOCKER-USER` chain.
+> Instead, rules can be added in separate tables, with base chains that
+> have the same types and hook points as Docker's base chains. If necessary,
+> [base chain priority](https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_priority)
+> can be used to tell nftables which order to call the chains in.
+> Docker uses well known [priority values](https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks#Priority_within_hook) for each of its base chains.
+
+## Migrating from iptables to nftables
+
+If the Docker daemon has been running with the iptables firewall backend,
+restarting it with the nftables backend will delete most of Docker's iptables
+chains and rules, and create nftables rules instead.
+
+If IP forwarding is not enabled, Docker will report an error when creating
+a bridge network that needs it. Because of the default bridge, if IPv4
+forwarding is disabled, the error will be reported during daemon startup.
+See [IP forwarding](#ip-forwarding).
+
+If you have rules in the `DOCKER-USER` chain, see [Migrating
+`DOCKER-USER`](#migrating-docker-user).
+
+You may need to manually update the iptables `FORWARD` policy if it has
+been set to `DROP` by Docker with iptables, or as part of your host's
+firewall configuration. See [FORWARD policy in iptables](#forward-policy-in-iptables).
+
+### IP forwarding
+
+IP forwarding on the Docker host enables Docker functionality including port
+publishing, communication between bridge networks, and direct routing from
+outside the host to containers in bridge networks.
+
+When running with iptables, depending on network and daemon configuration,
+Docker may enable IPv4 and IPv6 forwarding on the host.
+
+With its nftables firewall backend enabled, Docker will not enable IP forwarding
+itself. It will report an error if forwarding is needed, but not already enabled.
+To disable Docker's check for IP forwarding, letting it start and create networks
+when it determines that forwarding is disabled, use Daemon option `--ip-forward=false`,
+or `"ip-forward": false` in its configuration file.
+
+> [!WARNING]
+>
+> When enabling IP forwarding, make sure you have firewall rules to block
+> unwanted forwarding between non-Docker interfaces.
+
+> [!NOTE]
+>
+> If you stop Docker to migrate to nftables, Docker may have already enabled
+> IP forwarding on your system. After a reboot, if no other service re-enables
+> forwarding, Docker will fail to start.
+
+If Docker is in a VM that has a single network interface and no other
+software running, there is probably no unwanted forwarding to block.
+But, on a physical host with multiple network interfaces, forwarding
+between those interfaces should probably be blocked with nftables rules
+unless the host is acting as a router.
+
+To enable IP forwarding on the host, set the following sysctls:
+
+- `net.ipv4.ip_forward=1`
+- `net.ipv6.conf.all.forwarding=1`
+
+If your host uses `systemd`, you may be able to use `systemd-sysctl`. For
+example, by editing `/etc/sysctl.d/99-sysctl.conf`.
+
+If the host is running `firewalld`, you may be able to use it to block
+unwanted forwarding. Docker's bridges are in a firewalld zone called
+`docker`, it creates a forwarding policy called `docker-forwarding` that
+accepts forwarding from `ANY` zone to the `docker` zone.
+
+For example, to use nftables to block forwarding between interfaces `eth0`
+and `eth1`, you could use:
+
+```console
+table inet no-ext-forwarding {
+	chain no-ext-forwarding {
+		type filter hook forward priority filter; policy accept;
+		iifname "eth0" oifname "eth1" drop
+		iifname "eth1" oifname "eth0" drop
+	}
+}
+```
+
+### FORWARD policy in iptables
+
+An iptables chain with `FORWARD` policy `DROP` will drop packets that have
+been accepted by Docker's nftables rules, because the packet will be processed
+by the iptables chains as well as Docker's nftables chains.
+
+Some features, including port publishing, will not work unless the `DROP`
+policy is removed, or additional iptables rules are added to the iptables
+`FORWARD` chain to accept Docker-related traffic.
+
+When Docker is using iptables, and it enables IP forwarding on the host,
+it sets the default policy of the iptables `FORWARD` chain to `DROP`. So,
+if you stop Docker to migrate to nftables, it may have set a `DROP` that
+you need to remove. It will be removed anyway on reboot.
+
+To keep using rules in `DOCKER-USER` that rely on the chain having policy
+`DROP`, you must add explicit `ACCEPT` rules for Docker related traffic.
+
+To check the current iptables `FORWARD` policy, use:
+
+```console
+$ iptables -L FORWARD
+Chain FORWARD (policy DROP)
+target     prot opt source               destination
+$ ip6tables -L FORWARD
+Chain FORWARD (policy ACCEPT)
+target     prot opt source               destination
+```
+
+To set the iptables policies to `ACCEPT` for IPv4 and IPv6:
+
+```console
+$ iptables -P FORWARD ACCEPT
+$ ip6tables -P FORWARD ACCEPT
+```
+
+### Migrating `DOCKER-USER`
+
+With firewall backend "iptables", rules added to the iptables `DOCKER-USER`
+are processed before Docker's rules in the filter table's `FORWARD` chain.
+
+When starting the daemon with nftables after running with iptables, Docker
+will not remove the jump from the `FORWARD` chain to `DOCKER-USER`. So,
+rules created in `DOCKER-USER` will continue to run until the jump is
+removed or the host is rebooted.
+
+When starting with nftables, the daemon will not add the jump. So, unless
+there is an existing jump, rules in `DOCKER-USER` will be ignored.
+
+#### Migrating ACCEPT rules
+
+Some rules in the `DOCKER-USER` chain will continue to work. For example, if a
+packet is dropped, it will be dropped before or after the nftables rules in
+Docker's `filter-FORWARD` chain. But other rules, particularly `ACCEPT` rules
+to override Docker's `DROP` rules, will not work.
+
+In nftables, an "accept" rule is not final. It terminates processing
+for its base chain, but the accepted packet will still be processed by
+other base chains, which may drop it.
+
+To override Docker's `drop` rule, you must use a firewall mark. Select a
+mark not already in use on your host, and use Docker Engine option
+`--bridge-accept-fwmark`.
+
+For example, `--bridge-accept-fwmark=1` tells the daemon to accept any
+packet with an `fwmark` value of `1`. Optionally, you can supply a mask
+to match specific bits in the mark, `--bridge-accept-fwmark=0x1/0x3`.
+
+Then, instead of accepting the packet in `DOCKER-USER`, add the firewall
+mark you have chosen and Docker will not drop it.
+
+The firewall mark must be added before Docker's rules run. So if the mark
+is added in a chain with type `filter` and hook `forward`, it must have
+priority `filter - 1` or lower.
+
+> [!NOTE]
+>
+> By default, remote hosts can only reach a container through a port published
+> to one of the Docker host's addresses. Sending packets to the container's own
+> IP address instead ("direct routed" access) is not allowed.
+>
+> These packets are dropped by a rule in the `raw-PREROUTING` chain of the
+> `docker-bridges` tables. Because a drop is final, a rule in one of your own
+> tables cannot allow them. And, because that chain runs at the `prerouting`
+> hook, before Docker's `filter-FORWARD` rules, a firewall mark added with
+> `--bridge-accept-fwmark` has no effect on it.
+>
+> Any packet that reaches the host's firewall rules already addressed to a
+> container is treated this way. For example, a Kubernetes CNI plugin may
+> translate a Service address to a container address before the packet reaches
+> the host's pre-routing rules. Docker cannot distinguish the result from a
+> packet routed to the container by a remote host. Which host interface these
+> packets arrive on depends on the plugin's data path — for an overlay network
+> it is normally the tunnel device.
+>
+> To allow direct routed access to a container's *published* ports, use network
+> option `com.docker.network.bridge.trusted_host_interfaces`, or daemon option
+> `allow-direct-routing`. Unpublished ports are still protected. See
+> [Direct routing to containers in bridge networks](./port-publishing.md#direct-routing-to-containers-in-bridge-networks).
+> To allow direct routed access to all container ports, published or not, see
+> [Gateway modes](./port-publishing.md#gateway-modes).
+
+#### Replacing `DOCKER-USER` with an nftables table
+
+Because nftables doesn't have pre-defined chains, to replace the `DOCKER-USER`
+chain you can create your own table and add chains and rules to it.
+
+The `DOCKER-USER` chain has type `filter` and hook `forward`, so it can
+only have rules in the filter forward chain. The base chains in your
+table can have any `type` or `hook`. If your rules need to run before
+Docker's rules, give the base chains a lower `priority` number than
+Docker's chain. Or, a higher priority to make sure they run after Docker's
+rules.
+
+Docker's base chains use the priority values defined at
+[priority values](https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks#Priority_within_hook)
+
+#### Example: restricting external connections to containers
+
+By default, any remote host can connect to ports published to the Docker
+host's external addresses.
+
+To allow only a specific IP or network to access the containers, create a
+table with a base chain that has a drop rule. For example, the
+following table drops packets from all IP addresses except `192.0.2.2`:
+
+```console
+table ip my-table {
+	chain my-filter-forward {
+		type filter hook forward priority filter; policy accept;
+		iifname "ext_if" ip saddr != 192.0.2.2 counter drop
+	}
+}
+```
+
+You will need to change `ext_if` to your host's external interface name.
+
+You could instead accept connections from a source subnet. The following
+table only accepts access from the subnet `192.0.2.0/24`:
+
+```console
+table ip my-table {
+	chain my-filter-forward {
+		type filter hook forward priority filter; policy accept;
+		iifname "ext_if" ip saddr != 192.0.2.0/24 counter drop
+	}
+}
+```
+
+If you are running other services on the host that use IP forwarding
+and need to be accessed by different external hosts, you will need more
+specific filters. For example, to match the default prefix `br-` of
+bridge devices belonging to Docker's user-defined bridge networks:
+
+```console
+table ip my-table {
+	chain my-filter-forward {
+		type filter hook forward priority filter; policy accept;
+		iifname "ext_if" oifname "br-*" ip saddr != 192.0.2.0/24 counter drop
+	}
+}
+```
+
+For more information about nftables configuration and advanced usage,
+refer to the [nftables wiki](https://wiki.nftables.org/wiki-nftables/index.php/Main_Page).
diff --git a/content/manuals/engine/network/links.md b/content/manuals/engine/network/links.md
index 0f97ccd40ab1..e34c215ce760 100644
--- a/content/manuals/engine/network/links.md
+++ b/content/manuals/engine/network/links.md
@@ -38,18 +38,16 @@ detail on container linking in default `bridge` network.
 
 ## Connect using network port mapping
 
+Publishing a port with `-p` or `-P` is not container linking. It exposes a
+container port on the host. For the current reference, see
+[Published ports](port-publishing.md).
+
 Let's say you used this command to run a simple Python Flask application:
 
 ```console
 $ docker run -d -P training/webapp python app.py
 ```
 
-> [!NOTE]
->
-> Containers have an internal network and an IP address.
-> Docker can have a variety of network configurations. You can see more
-> information on Docker networking [here](index.md).
-
 When that container was created, the `-P` flag was used to automatically map
 any network port inside it to a random high port within an *ephemeral port
 range* on your Docker host. Next, when `docker ps` was run, you saw that port
@@ -176,7 +174,7 @@ You can also use `docker inspect` to return the container's name.
 > [!NOTE]
 >
 > Container names must be unique. That means you can only call
-> one container `web`. If you want to re-use a container name you must delete
+> one container `web`. If you want to reuse a container name you must delete
 > the old container (with `docker container rm`) before you can create a new
 > container with the same name. As an alternative you can use the `--rm`
 > flag with the `docker run` command. This deletes the container
@@ -295,9 +293,9 @@ Docker uses this prefix format to define three distinct environment variables:
 
 * The `prefix_ADDR` variable contains the IP Address from the URL, for
 example `WEBDB_PORT_5432_TCP_ADDR=172.17.0.82`.
-* The `prefix_PORT` variable contains just the port number from the URL for
+* The `prefix_PORT` variable contains just the port number from the URL of
 example `WEBDB_PORT_5432_TCP_PORT=5432`.
-* The `prefix_PROTO` variable contains just the protocol from the URL for
+* The `prefix_PROTO` variable contains just the protocol from the URL of
 example `WEBDB_PORT_5432_TCP_PROTO=tcp`.
 
 If the container exposes multiple ports, an environment variable set is
diff --git a/content/manuals/engine/network/packet-filtering-firewalls.md b/content/manuals/engine/network/packet-filtering-firewalls.md
index 2ca6cea12a1d..dfeabeedf116 100644
--- a/content/manuals/engine/network/packet-filtering-firewalls.md
+++ b/content/manuals/engine/network/packet-filtering-firewalls.md
@@ -8,358 +8,81 @@ aliases:
 - /network/packet-filtering-firewalls/
 ---
 
-On Linux, Docker creates `iptables` and `ip6tables` rules to implement network
-isolation, port publishing and filtering.
+On Linux, Docker creates firewall rules to implement network
+isolation, [port publishing](./port-publishing.md) and filtering.
 
 Because these rules are required for the correct functioning of Docker bridge
 networks, you should not modify the rules created by Docker.
 
-But, if you are running Docker on a host exposed to the internet, you will
-probably want to add iptables policies that prevent unauthorized access to
-containers or other services running on your host. This page describes how
-to achieve that, and the caveats you need to be aware of.
+This page describes options that control Docker's firewall rules to
+implement functionality including port publishing, and NAT/masquerading.
 
 > [!NOTE]
 > 
-> Docker creates `iptables` rules for bridge networks.
+> Docker creates firewall rules for bridge networks.
 > 
-> No `iptables` rules are created for `ipvlan`, `macvlan` or `host` networking.
+> No rules are created for `ipvlan`, `macvlan` or `host` networking.
 
-## Docker and iptables chains
+## Firewall backend
 
-In the `filter` table, Docker sets the default policy to `DROP`, and creates the
-following custom `iptables` chains:
+By default, Docker Engine creates its firewall rules using iptables,
+see [Docker with iptables](./firewall-iptables.md). It also has
+support for nftables, see [Docker with nftables](./firewall-nftables.md).
 
-* `DOCKER-USER`
-  * A placeholder for user-defined rules that will be processed before rules
-    in the `DOCKER-FORWARD` and `DOCKER` chains.
-* `DOCKER-FORWARD`
-  * The first stage of processing for Docker's networks. Rules that pass packets
-    that are not related to established connections to the other Docker chains,
-    as well as rules to accept packets that are part of established connections.
-* `DOCKER`
-  * Rules that determine whether a packet that is not part of an established
-    connection should be accepted, based on the port forwarding configuration
-    of running containers.
-* `DOCKER-ISOLATION-STAGE-1` and `DOCKER-ISOLATION-STAGE-2`
-  * Rules to isolate Docker networks from each other.
-* `DOCKER-INGRESS`
-  * Rules related to Swarm networking. 
+For bridge networks, iptables and nftables have the same functionality.
 
-In the `FORWARD` chain, Docker adds rules that unconditionally jump to the
-`DOCKER-USER`, `DOCKER-FORWARD` and `DOCKER-INGRESS` chains.
-
-In the `nat` table, Docker creates chain `DOCKER` and adds rules to implement
-masquerading and port-mapping.
-
-### Add iptables policies before Docker's rules
-
-Packets that get accepted or rejected by rules in these custom chains will not
-be seen by user-defined rules appended to the `FORWARD` chain. So, to add
-additional rules to filter these packets, use the `DOCKER-USER` chain.
-
-Rules appended to the `FORWARD` chain will be processed after Docker's rules.
-
-### Match the original IP and ports for requests
-
-When packets arrive to the `DOCKER-USER` chain, they have already passed through
-a Destination Network Address Translation (DNAT) filter. That means that the
-`iptables` flags you use can only match internal IP addresses and ports of
-containers.
-
-If you want to match traffic based on the original IP and port in the network
-request, you must use the
-[`conntrack` iptables extension](https://ipset.netfilter.org/iptables-extensions.man.html#lbAO).
-For example:
-
-```console
-$ sudo iptables -I DOCKER-USER -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-$ sudo iptables -I DOCKER-USER -p tcp -m conntrack --ctorigdst 198.51.100.2 --ctorigdstport 80 -j ACCEPT
-```
-
-> [!IMPORTANT]
->
-> Using the `conntrack` extension may result in degraded performance.
-
-## Port publishing and mapping
-
-By default, for both IPv4 and IPv6, the daemon blocks access to ports that have not
-been published. Published container ports are mapped to host IP addresses.
-To do this, it uses iptables to perform Network Address Translation (NAT),
-Port Address Translation (PAT), and masquerading.
-
-For example, `docker run -p 8080:80 [...]` creates a mapping
-between port 8080 on any address on the Docker host, and the container's
-port 80. Outgoing connections from the container will masquerade, using
-the Docker host's IP address.
-
-### Restrict external connections to containers
-
-By default, all external source IPs are allowed to connect to ports that have
-been published to the Docker host's addresses.
-
-To allow only a specific IP or network to access the containers, insert a
-negated rule at the top of the `DOCKER-USER` filter chain. For example, the
-following rule drops packets from all IP addresses except `192.0.2.2`:
-
-```console
-$ iptables -I DOCKER-USER -i ext_if ! -s 192.0.2.2 -j DROP
-```
-
-You will need to change `ext_if` to correspond with your
-host's actual external interface. You could instead allow connections from a
-source subnet. The following rule only allows access from the subnet `192.0.2.0/24`:
-
-```console
-$ iptables -I DOCKER-USER -i ext_if ! -s 192.0.2.0/24 -j DROP
-```
-
-Finally, you can specify a range of IP addresses to accept using `--src-range`
-(Remember to also add `-m iprange` when using `--src-range` or `--dst-range`):
-
-```console
-$ iptables -I DOCKER-USER -m iprange -i ext_if ! --src-range 192.0.2.1-192.0.2.3 -j DROP
-```
-
-You can combine `-s` or `--src-range` with `-d` or `--dst-range` to control both
-the source and destination. For instance, if the Docker host has addresses
-`2001:db8:1111::2` and `2001:db8:2222::2`, you can make rules specific to
-`2001:db8:1111::2` and leave `2001:db8:2222::2` open.
-
-`iptables` is complicated. There is a lot more information at [Netfilter.org HOWTO](https://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html).
-
-### Direct routing
-
-Port mapping ensures that published ports are accessible on the host's
-network addresses, which are likely to be routable for any external
-clients. No routes are normally set up in the host's network for container
-addresses that exist within a host.
-
-But, particularly with IPv6 you may prefer to avoid using NAT and instead
-arrange for external routing to container addresses ("direct routing").
-
-To access containers on a bridge network from outside the Docker host,
-you must set up routing to the bridge network via an address on the Docker
-host. This can be achieved using static routes, Border Gateway Protocol
-(BGP), or any other means appropriate for your network.
-
-Within a local layer 2 network, remote hosts can set up static routes
-to a container network using the Docker daemon host's address on the local
-network. Those hosts can access containers directly. For remote hosts
-outside the local network, direct access to containers requires router
-configuration to enable the necessary routing.
-
-#### Gateway modes
-
-The bridge network driver has the following options:
-- `com.docker.network.bridge.gateway_mode_ipv6`
-- `com.docker.network.bridge.gateway_mode_ipv4`
-
-Each of these can be set to one of the gateway modes:
-- `nat`
-- `nat-unprotected`
-- `routed`
-- `isolated`
-
-The default is `nat`, NAT and masquerading rules are set up for each
-published container port. Packets leaving the host will use a host address.
-
-With mode `routed`, no NAT or masquerading rules are set up, but `iptables`
-are still set up so that only published container ports are accessible.
-Outgoing packets from the container will use the container's address,
-not a host address.
-
-In `nat` mode, when a port is published to a specific host address, that
-port is only accessible via the host interface with that address. So,
-for example, publishing a port to an address on the loopback interface
-means remote hosts cannot access it.
-
-However, using direct routing, published container ports are always
-accessible from remote hosts, unless the Docker host's firewall has
-additional restrictions. Hosts on the local layer-2 network can set up
-direct routing without needing any additional network configuration.
-Hosts outside the local network can only use direct routing to the
-container if the network's routers are configured to enable it.
-
-In `nat-unprotected` mode, unpublished container ports are also
-accessible using direct routing, no port filtering rules are set up.
-This mode is included for compatibility with legacy default behaviour.
-
-The gateway mode also affects communication between containers that
-are connected to different Docker networks on the same host.
-- In `nat` and `nat-unprotected` modes, containers in other bridge
-  networks can only access published ports via the host addresses they
-  are published to. Direct routing from other networks is not allowed.
-- In `routed` mode containers in other networks can use direct
-  routing to access ports, without going via a host address.
-
-In `routed` mode, a host port in a `-p` or `--publish` port mapping is
-not used, and the host address is only used to decide whether to apply
-the mapping to IPv4 or IPv6. So, when a mapping only applies to `routed`
-mode, only addresses `0.0.0.0` or `::` should be used, and a host port
-should not be given. If a specific address or port is given, it will
-have no effect on the published port and a warning message will be
-logged.
-
-Mode `isolated` can only be used when the network is also created with
-CLI flag `--internal`, or equivalent. An address is normally assigned to the
-bridge device in an `internal` network. So, processes on the docker host can
-access the network, and containers in the network can access host services
-listening on that bridge address (including services listening on "any" host
-address, `0.0.0.0` or `::`). No address is assigned to the bridge when the
-network is created with gateway mode `isolated`.
-
-#### Example
-
-Create a network suitable for direct routing for IPv6, with NAT enabled
-for IPv4:
-```console
-$ docker network create --ipv6 --subnet 2001:db8::/64 -o com.docker.network.bridge.gateway_mode_ipv6=routed mynet
-```
-
-Create a container with a published port:
-```console
-$ docker run --network=mynet -p 8080:80 myimage
-```
-
-Then:
-- Only container port 80 will be open, for IPv4 and IPv6. It is accessible
-  from anywhere, if there is routing to the container's address, and access
-  is not blocked by the host's firewall.
-- For IPv6, using `routed` mode, port 80 will be open on the container's IP
-  address. Port 8080 will not be opened on the host's IP addresses, and
-  outgoing packets will use the container's IP address.
-- For IPv4, using the default `nat` mode, the container's port 80 will be
-  accessible via port 8080 on the host's IP addresses, as well as directly.
-  Connections originating from the container will masquerade, using the 
-  host's IP address.
-
-In `docker inspect`, this port mapping will be shown as follows. Note that
-there is no `HostPort` for IPv6, because it is using `routed` mode:
-```console
-$ docker container inspect <id> --format "{{json .NetworkSettings.Ports}}"
-{"80/tcp":[{"HostIp":"0.0.0.0","HostPort":"8080"},{"HostIp":"::","HostPort":""}]}
-```
-
-Alternatively, to make the mapping IPv6-only, disabling IPv4 access to the
-container's port 80, use the unspecified IPv6 address `[::]` and do not
-include a host port number:
-```console
-$ docker run --network mynet -p '[::]::80'
-```
-
-### Setting the default bind address for containers
-
-By default, when a container's ports are mapped without any specific host
-address, the Docker daemon binds published container ports to all host
-addresses (`0.0.0.0` and `[::]`).
-
-For example, the following command publishes port 8080 to all network
-interfaces on the host, on both IPv4 and IPv6 addresses, potentially
-making them available to the outside world.
-
-```console
-docker run -p 8080:80 nginx
-```
-
-You can change the default binding address for published container ports so that
-they're only accessible to the Docker host by default. To do that, you can
-configure the daemon to use the loopback address (`127.0.0.1`) instead.
-
-> [!WARNING]
->
-> In releases older than 28.0.0, hosts within the same L2 segment (for example,
-> hosts connected to the same network switch) can reach ports published to
-> localhost. For more information, see
-> [moby/moby#45610](https://github.com/moby/moby/issues/45610)
-
-To configure this setting for user-defined bridge networks, use
-the `com.docker.network.bridge.host_binding_ipv4`
-[driver option](./drivers/bridge.md#options) when you create the network.
-
-```console
-$ docker network create mybridge \
-  -o "com.docker.network.bridge.host_binding_ipv4=127.0.0.1"
-```
-
-> [!NOTE]
->
-> - Setting the default binding address to `::` means port bindings with no host
->   address specified will work for any IPv6 address on the host. But, `0.0.0.0`
->   means any IPv4 or IPv6 address.
-> - Changing the default bind address doesn't have any effect on Swarm services.
->   Swarm services are always exposed on the `0.0.0.0` network interface.
-
-#### Default bridge
-
-To set the default binding for the default bridge network, configure the `"ip"`
-key in the `daemon.json` configuration file:
-
-```json
-{
-  "ip": "127.0.0.1"
-}
-```
-
-This changes the default binding address to `127.0.0.1` for published container
-ports on the default bridge network.
-Restart the daemon for this change to take effect.
-Alternatively, you can use the `dockerd --ip` flag when starting the daemon.
+Docker Engine option `firewall-backend` can be used to select whether
+iptables or nftables is used. See
+[daemon configuration](https://docs.docker.com/reference/cli/dockerd/).
 
 ## Docker on a router
 
 On Linux, Docker needs "IP Forwarding" enabled on the host. So, it enables
 the `sysctl` settings `net.ipv4.ip_forward` and `net.ipv6.conf.all.forwarding`
-it they are not already enabled when it starts. When it does that, it also
-sets the policy of the iptables `FORWARD` chain to `DROP`.
+if they are not already enabled when it starts. When it does that, it also
+configures the firewall to drop forwarded packets unless they are explicitly
+accepted.
 
-If Docker sets the policy for the `FORWARD` chain to `DROP`. This will prevent
-your Docker host from acting as a router, it is the recommended setting when
-IP Forwarding is enabled.
+When Docker sets the default forwarding policy to "drop", it will prevent
+your Docker host from acting as a router. This is the recommended setting when
+IP Forwarding is enabled, unless router functionality is required.
 
-To stop Docker from setting the `FORWARD` chain's policy to `DROP`, include
+To stop Docker from setting the forwarding policy to "drop", include
 `"ip-forward-no-drop": true` in `/etc/docker/daemon.json`, or add option
 `--ip-forward-no-drop` to the `dockerd` command line.
 
-Alternatively, you may add `ACCEPT` rules to the `DOCKER-USER` chain for the
-packets you want to forward. For example:
-
-```console
-$ iptables -I DOCKER-USER -i src_if -o dst_if -j ACCEPT
-```
-
-> [!WARNING]
->
-> In releases older than 28.0.0, Docker always set the default policy of the
-> IPv6 `FORWARD` chain to `DROP`. In release 28.0.0 and newer, it will only
-> set that policy if it enables IPv6 forwarding itself. This has always been
-> the behaviour for IPv4 forwarding.
+> [!NOTE]
 >
-> If IPv6 forwarding is enabled on your host before Docker starts, check your
-> host's configuration to make sure it is still secure.
+> With the experimental nftables backend, Docker does not enable IP forwarding
+> itself, and it will not create a default "drop" nftables policy. See
+> [Migrating from iptables to nftables](./firewall-nftables.md#migrating-from-iptables-to-nftables).
 
-## Prevent Docker from manipulating iptables
+## Prevent Docker from manipulating firewall rules
 
-It is possible to set the `iptables` or `ip6tables` keys to `false` in
-[daemon configuration](https://docs.docker.com/reference/cli/dockerd/), but
-this option is not appropriate for most users. It is likely to break
+Setting the `iptables` or `ip6tables` keys to `false` in
+[daemon configuration](https://docs.docker.com/reference/cli/dockerd/), will
+prevent Docker from creating most of its `iptables` or `nftables` rules. But,
+this option is not appropriate for most users, it is likely to break
 container networking for the Docker Engine.
 
-All ports of all containers will be accessible from the network, and none
-will be mapped from Docker host IP addresses.
+For example, with Docker's firewalling disabled and no replacement
+rules, containers in bridge networks will not be able to access
+internet hosts by masquerading, but all of their ports will be accessible
+to hosts on the local network.
 
-It is not possible to completely prevent Docker from creating `iptables`
+It is not possible to completely prevent Docker from creating firewall
 rules, and creating rules after-the-fact is extremely involved and beyond
 the scope of these instructions.
 
 ## Integration with firewalld
 
-If you are running Docker with the `iptables` option set to `true`, and
-[firewalld](https://firewalld.org) is enabled on your system, Docker
-automatically creates a `firewalld` zone called `docker`, with target `ACCEPT`.
+If you are running Docker with the `iptables` or `ip6tables` options set to
+`true`, and [firewalld](https://firewalld.org) is enabled on your system, in
+addition to its usual iptables or nftables rules, Docker creates a `firewalld`
+zone called `docker`, with target `ACCEPT`.
 
-All network interfaces created by Docker (for example, `docker0`) are inserted
-into the `docker` zone.
+All bridge network interfaces created by Docker (for example, `docker0`) are
+inserted into the `docker` zone.
 
 Docker also creates a forwarding policy called `docker-forwarding` that allows
 forwarding from `ANY` zone to the `docker` zone.
@@ -368,8 +91,8 @@ forwarding from `ANY` zone to the `docker` zone.
 
 [Uncomplicated Firewall](https://launchpad.net/ufw)
 (ufw) is a frontend that ships with Debian and Ubuntu,
-and it lets you manage firewall rules. Docker and ufw use iptables in ways
-that make them incompatible with each other.
+and it lets you manage firewall rules. Docker and ufw use firewall rules in
+ways that make them incompatible with each other.
 
 When you publish a container's ports using Docker, traffic to and from that
 container gets diverted before it goes through the ufw firewall settings.
diff --git a/content/manuals/engine/network/port-publishing.md b/content/manuals/engine/network/port-publishing.md
new file mode 100644
index 000000000000..c51d7d2b3ac2
--- /dev/null
+++ b/content/manuals/engine/network/port-publishing.md
@@ -0,0 +1,328 @@
+---
+title: Port publishing and mapping
+weight: 10
+description: Accessing container ports
+keywords: network, iptables, firewall
+---
+
+By default, for both IPv4 and IPv6, the Docker daemon blocks access to ports that
+have not been published. Published container ports are mapped to host IP addresses.
+To do this, it uses firewall rules to perform Network Address Translation (NAT),
+Port Address Translation (PAT), and masquerading.
+
+For example, `docker run -p 8080:80 [...]` creates a mapping
+between port 8080 on any address on the Docker host, and the container's
+port 80. Outgoing connections from the container will masquerade, using
+the Docker host's IP address.
+
+## Publishing ports
+
+When you create or run a container using `docker create` or `docker run`, all
+ports of containers on bridge networks are accessible from the Docker host and
+other containers connected to the same network. Ports are not accessible from
+outside the host or, with the default configuration, from containers in other
+networks.
+
+Use the `--publish` or `-p` flag to make a port available outside the host,
+and to containers in other bridge networks.
+
+This creates a firewall rule in the host,
+mapping a container port to a port on the Docker host to the outside world.
+Here are some examples:
+
+| Flag value                      | Description                                                                                                                                             |
+| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `-p 8080:80`                    | Map port `8080` on the Docker host to TCP port `80` in the container.                                                                                   |
+| `-p 192.168.1.100:8080:80`      | Map port `8080` on the Docker host IP `192.168.1.100` to TCP port `80` in the container.                                                                |
+| `-p 8080:80/udp`                | Map port `8080` on the Docker host to UDP port `80` in the container.                                                                                   |
+| `-p 8080:80/tcp -p 8080:80/udp` | Map TCP port `8080` on the Docker host to TCP port `80` in the container, and map UDP port `8080` on the Docker host to UDP port `80` in the container. |
+
+> [!IMPORTANT]
+>
+> Publishing container ports is insecure by default. Meaning, when you publish
+> a container's ports it becomes available not only to the Docker host, but to
+> the outside world as well.
+>
+> If you include the localhost IP address (`127.0.0.1`, or `::1`) with the
+> publish flag, only the Docker host can access the published container port.
+>
+> ```console
+> $ docker run -p 127.0.0.1:8080:80 -p '[::1]:8080:80' nginx
+> ```
+>
+> > [!WARNING]
+> >
+> > In releases older than 28.0.0, hosts within the same L2 segment (for example,
+> > hosts connected to the same network switch) can reach ports published to localhost.
+> > For more information, see
+> > [moby/moby#45610](https://github.com/moby/moby/issues/45610)
+
+Ports on the host's IPv6 addresses will map to the container's IPv4 address
+if no host IP is given in a port mapping, the bridge network is IPv4-only,
+and `--userland-proxy=true` (default).
+
+## Direct routing
+
+Port mapping ensures that published ports are accessible on the host's
+network addresses, which are likely to be routable for any external
+clients. No routes are normally set up in the host's network for container
+addresses that exist within a host.
+
+But, particularly with IPv6 you may prefer to avoid using NAT and instead
+arrange for external routing to container addresses ("direct routing").
+
+To access containers on a bridge network from outside the Docker host,
+you must first set up routing to the bridge network via an address on the
+Docker host. This can be achieved using static routes, Border Gateway Protocol (BGP),
+or any other means appropriate for your network. For example, within
+a local layer 2 network, remote hosts can set up static routes to a container
+network via the Docker daemon host's address on the local network.
+
+### Direct routing to containers in bridge networks
+
+By default, remote hosts are not allowed direct access to container IP
+addresses in Docker's Linux bridge networks. They can only access ports
+published to host IP addresses.
+
+To allow direct access to any published port, on any container, in any
+Linux bridge network, use daemon option `"allow-direct-routing": true`
+in `/etc/docker/daemon.json` or the equivalent `--allow-direct-routing`.
+
+To allow direct routing from anywhere to containers in a specific bridge
+network, see [Gateway modes](#gateway-modes).
+
+Or, to allow direct routing via specific host interfaces, to a specific
+bridge network, use the following option when creating the network:
+- `com.docker.network.bridge.trusted_host_interfaces`
+
+#### Example
+
+Create a network where published ports on container IP addresses can be
+accessed directly from interfaces `vxlan.1` and `eth3`:
+
+```console
+$ docker network create --subnet 192.0.2.0/24 --ip-range 192.0.2.0/29 -o com.docker.network.bridge.trusted_host_interfaces="vxlan.1:eth3" mynet
+```
+
+Run a container in that network, publishing its port 80 to port 8080 on
+the host's loopback interface:
+
+```console
+$ docker run -d --ip 192.0.2.100 -p 127.0.0.1:8080:80 nginx
+```
+
+The web server running on the container's port 80 can now be accessed
+from the Docker host at `http://127.0.0.1:8080`, or directly at
+`http://192.0.2.100:80`. If remote hosts on networks connected to
+interfaces `vxlan.1` and `eth3` have a route to the `192.0.2.0/24`
+network inside the Docker host, they can also access the web server
+via `http://192.0.2.100:80`.
+
+## Gateway modes
+
+The bridge network driver has the following options:
+- `com.docker.network.bridge.gateway_mode_ipv6`
+- `com.docker.network.bridge.gateway_mode_ipv4`
+
+Each of these can be set to one of the gateway modes:
+- `nat`
+- `nat-unprotected`
+- `routed`
+- `isolated`
+
+The default is `nat`, NAT and masquerading rules are set up for each
+published container port. Packets leaving the host will use a host address.
+
+With mode `routed`, no NAT or masquerading rules are set up, but firewall
+rules are still set up so that only published container ports are accessible.
+Outgoing packets from the container will use the container's address,
+not a host address.
+
+To access a published port in a `routed` network, remote hosts must have
+a route to the container network via an external address on the Docker
+host ("direct routing"). Hosts on the local layer-2 network can set up
+direct routing without needing any additional network configuration.
+Hosts outside the local network can only use direct routing to the
+container if the network's routers are configured to enable it.
+
+In a `nat` mode network, publishing a port to an address on the loopback
+interface means remote hosts cannot access it. Other published container
+ports in `routed` and `nat` networks are always accessible from remote
+hosts using direct routing, unless the Docker host's firewall has additional
+restrictions.
+
+> [!NOTE]
+>
+> When a port is published to a specific host address in `nat` mode, if
+> IP forwarding is enabled on the Docker host, the published port can be
+> accessed via other host interfaces using direct routing to the host
+> address.
+>
+> For example, a Docker host with IP forwarding enabled has two NICs with
+> addresses `192.168.100.10/24` and `10.0.0.10/24`.
+> When a port is published to `192.168.100.10`, a host in the `10.0.0.0/24`
+> subnet can access that port by routing to `192.168.100.10` via `10.0.0.10`.
+
+In `nat-unprotected` mode, unpublished container ports are also
+accessible using direct routing, no port filtering rules are set up.
+This mode is included for compatibility with legacy default behaviour.
+
+The gateway mode also affects communication between containers that
+are connected to different Docker networks on the same host.
+- In `nat` and `nat-unprotected` modes, containers in other bridge
+  networks can only access published ports via the host addresses they
+  are published to. Direct routing from other networks is not allowed.
+- In `routed` mode containers in other networks can use direct
+  routing to access ports, without going via a host address.
+
+In `routed` mode, a host port in a `-p` or `--publish` port mapping is
+not used, and the host address is only used to decide whether to apply
+the mapping to IPv4 or IPv6. So, when a mapping only applies to `routed`
+mode, only addresses `0.0.0.0` or `::` should be used, and a host port
+should not be given. If a specific address or port is given, it will
+have no effect on the published port and a warning message will be
+logged.
+
+Mode `isolated` can only be used when the network is also created with
+CLI flag `--internal`, or equivalent. An address is normally assigned to the
+bridge device in an `internal` network. So, processes on the Docker host can
+access the network, and containers in the network can access host services
+listening on that bridge address (including services listening on "any" host
+address, `0.0.0.0` or `::`). No address is assigned to the bridge when the
+network is created with gateway mode `isolated`.
+
+### Example
+
+Create a network suitable for direct routing for IPv6, with NAT enabled
+for IPv4:
+```console
+$ docker network create --ipv6 --subnet 2001:db8::/64 -o com.docker.network.bridge.gateway_mode_ipv6=routed mynet
+```
+
+Create a container with a published port:
+```console
+$ docker run --network=mynet -p 8080:80 myimage
+```
+
+Then:
+- Only container port 80 will be open, for IPv4 and IPv6.
+- For IPv6, using `routed` mode, port 80 will be open on the container's IP
+  address. Port 8080 will not be opened on the host's IP addresses, and
+  outgoing packets will use the container's IP address.
+- For IPv4, using the default `nat` mode, the container's port 80 will be
+  accessible via port 8080 on the host's IP addresses, as well as directly
+  from within the Docker host. But, container port 80 cannot be accessed
+  directly from outside the host.
+  Connections originating from the container will masquerade, using the
+  host's IP address.
+
+In `docker inspect`, this port mapping will be shown as follows. Note that
+there is no `HostPort` for IPv6, because it is using `routed` mode:
+```console
+$ docker container inspect <id> --format "{{json .NetworkSettings.Ports}}"
+{"80/tcp":[{"HostIp":"0.0.0.0","HostPort":"8080"},{"HostIp":"::","HostPort":""}]}
+```
+
+Alternatively, to make the mapping IPv6-only, disabling IPv4 access to the
+container's port 80, use the unspecified IPv6 address `[::]` and do not
+include a host port number:
+```console
+$ docker run --network mynet -p '[::]::80'
+```
+
+## Setting the default bind address for containers
+
+By default, when a container's ports are mapped without any specific host
+address, the Docker daemon publishes ports to all host addresses
+(`0.0.0.0` and `[::]`).
+
+For example, the following command publishes port 8080 to all network
+interfaces on the host, on both IPv4 and IPv6 addresses, potentially
+making them available to the outside world.
+
+```console
+docker run -p 8080:80 nginx
+```
+
+You can change the default binding address for published container ports so that
+they're only accessible to the Docker host by default. To do that, you can
+configure the daemon to use the loopback address (`127.0.0.1`) instead.
+
+> [!WARNING]
+>
+> In releases older than 28.0.0, hosts within the same L2 segment (for example,
+> hosts connected to the same network switch) can reach ports published to
+> localhost. For more information, see
+> [moby/moby#45610](https://github.com/moby/moby/issues/45610)
+
+To configure this setting for user-defined bridge networks, use
+the `com.docker.network.bridge.host_binding_ipv4`
+[driver option](./drivers/bridge.md#default-host-binding-address) when you
+create the network. Despite the option name, it is possible to specify an
+IPv6 address.
+
+```console
+$ docker network create mybridge \
+  -o "com.docker.network.bridge.host_binding_ipv4=127.0.0.1"
+```
+
+Or, to set the default binding address for containers in all user-defined
+bridge networks, use daemon configuration option `default-network-opts`.
+For example:
+
+```json
+{
+  "default-network-opts": {
+    "bridge": {
+      "com.docker.network.bridge.host_binding_ipv4": "127.0.0.1"
+    }
+  }
+}
+```
+
+> [!NOTE]
+>
+> Setting the default binding address to `::` means port bindings with no host
+> address specified will work for any IPv6 address on the host. But, `0.0.0.0`
+> means any IPv4 or IPv6 address.
+>
+> Changing the default bind address doesn't have any effect on Swarm services.
+> Swarm services are always exposed on the `0.0.0.0` network interface.
+
+### Masquerade or SNAT for outgoing packets
+
+NAT is enabled by default for bridge networks, meaning outgoing packets
+from containers are masqueraded. The source address of packets leaving
+the Docker host is changed to an address on the host interface the packet
+is sent on.
+
+Masquerading can be disabled for a user-defined bridge network by using
+the `com.docker.network.bridge.enable_ip_masquerade` driver option when
+creating the network. For example:
+```console
+$ docker network create mybridge \
+  -o com.docker.network.bridge.enable_ip_masquerade=false ...
+```
+
+To use a specific source address for outgoing packets for a user-defined
+network, instead of letting masquerading select an address, use options
+`com.docker.network.host_ipv4` and `com.docker.network.host_ipv6` to
+specify the Source NAT (SNAT) address to use. The
+`com.docker.network.bridge.enable_ip_masquerade` option must
+be `true`, the default, for these options to have any effect.
+
+### Default bridge
+
+To set the default binding for the default bridge network, configure the `"ip"`
+key in the `daemon.json` configuration file:
+
+```json
+{
+  "ip": "127.0.0.1"
+}
+```
+
+This changes the default binding address to `127.0.0.1` for published container
+ports on the default bridge network.
+Restart the daemon for this change to take effect.
+Alternatively, you can use the `dockerd --ip` flag when starting the daemon.
diff --git a/content/manuals/engine/network/tutorials/_index.md b/content/manuals/engine/network/tutorials/_index.md
deleted file mode 100644
index 9b3fccaf423e..000000000000
--- a/content/manuals/engine/network/tutorials/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-build:
-  render: never
-title: Tutorials
-weight: 30
----
diff --git a/content/manuals/engine/network/tutorials/host.md b/content/manuals/engine/network/tutorials/host.md
deleted file mode 100644
index 61a46b63cf60..000000000000
--- a/content/manuals/engine/network/tutorials/host.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: Networking using the host network
-description: Tutorials for networking using the host network, disabling network isolation
-keywords: networking, host, standalone
-aliases:
-  - /network/network-tutorial-host/
----
-
-This series of tutorials deals with networking standalone containers which bind
-directly to the Docker host's network, with no network isolation. For other
-networking topics, see the [overview](/manuals/engine/network/_index.md).
-
-## Goal
-
-The goal of this tutorial is to start a `nginx` container which binds directly
-to port 80 on the Docker host. From a networking point of view, this is the
-same level of isolation as if the `nginx` process were running directly on the
-Docker host and not in a container. However, in all other ways, such as storage,
-process namespace, and user namespace, the `nginx` process is isolated from the
-host.
-
-## Prerequisites
-
-- This procedure requires port 80 to be available on the Docker host. To make
-  Nginx listen on a different port, see the
-  [documentation for the `nginx` image](https://hub.docker.com/_/nginx/)
-
-- The `host` networking driver only works on Linux hosts, and as an opt-in
-  feature in Docker Desktop version 4.34 and later. To enable this feature in
-  Docker Desktop, navigate to the **Resources** tab in **Settings**, and then
-  under **Network** select **Enable host networking**.
-
-## Procedure
-
-1.  Create and start the container as a detached process. The `--rm` option means to remove the container once it exits/stops. The `-d` flag means to start the container detached (in the background). 
-
-    ```console
-    $ docker run --rm -d --network host --name my_nginx nginx
-    ```
-
-2.  Access Nginx by browsing to
-    [http://localhost:80/](http://localhost:80/).
-
-3.  Examine your network stack using the following commands:
-
-    - Examine all network interfaces and verify that a new one was not created.
-
-      ```console
-      $ ip addr show
-      ```
-
-    - Verify which process is bound to port 80, using the `netstat` command. You
-      need to use `sudo` because the process is owned by the Docker daemon user
-      and you otherwise won't be able to see its name or PID.
-
-      ```console
-      $ sudo netstat -tulpn | grep :80
-      ```
-
-4.  Stop the container. It will be removed automatically as it was started using the `--rm` option.
-
-    ```console
-    docker container stop my_nginx
-    ```
-
-## Other networking tutorials
-
-- [Standalone networking tutorial](/manuals/engine/network/tutorials/standalone.md)
-- [Overlay networking tutorial](/manuals/engine/network/tutorials/overlay.md)
-- [Macvlan networking tutorial](/manuals/engine/network/tutorials/macvlan.md)
diff --git a/content/manuals/engine/network/tutorials/macvlan.md b/content/manuals/engine/network/tutorials/macvlan.md
deleted file mode 100644
index 12f9719c9c2c..000000000000
--- a/content/manuals/engine/network/tutorials/macvlan.md
+++ /dev/null
@@ -1,225 +0,0 @@
----
-title: Networking using a macvlan network
-description: Tutorials for networking using a macvlan bridge network and 802.1Q trunk
-  bridge network
-keywords: networking, macvlan, 802.1Q, standalone
-aliases:
-  - /network/network-tutorial-macvlan/
----
-
-This series of tutorials deals with networking standalone containers which
-connect to `macvlan` networks. In this type of network, the Docker host accepts
-requests for multiple MAC addresses at its IP address, and routes those requests
-to the appropriate container. For other networking topics, see the
-[overview](/manuals/engine/network/_index.md).
-
-## Goal
-
-The goal of these tutorials is to set up a bridged `macvlan` network and attach
-a container to it, then set up an 802.1Q trunked `macvlan` network and attach a
-container to it.
-
-## Prerequisites
-
-- Most cloud providers block `macvlan` networking. You may need physical access
-  to your networking equipment.
-
-- The `macvlan` networking driver only works on Linux hosts, and is not supported
-  on Docker Desktop or Docker Engine on Windows.
-
-- You need at least version 3.9 of the Linux kernel, and version 4.0 or higher
-  is recommended.
-
-- The examples assume your ethernet interface is `eth0`. If your device has a
-  different name, use that instead.
-
-- The `macvlan` driver is not supported in rootless mode.
-
-## Bridge example
-
-In the simple bridge example, your traffic flows through `eth0` and Docker
-routes traffic to your container using its MAC address. To network devices
-on your network, your container appears to be physically attached to the network.
-
-1.  Create a `macvlan` network called `my-macvlan-net`. Modify the `subnet`, `gateway`,
-    and `parent` values to values that make sense in your environment.
-
-    ```console
-    $ docker network create -d macvlan \
-      --subnet=172.16.86.0/24 \
-      --gateway=172.16.86.1 \
-      -o parent=eth0 \
-      my-macvlan-net
-    ```
-
-    You can use `docker network ls` and `docker network inspect my-macvlan-net`
-    commands to verify that the network exists and is a `macvlan` network.
-
-2.  Start an `alpine` container and attach it to the `my-macvlan-net` network. The
-    `-dit` flags start the container in the background but allow you to attach
-    to it. The `--rm` flag means the container is removed when it is stopped.
-
-    ```console
-    $ docker run --rm -dit \
-      --network my-macvlan-net \
-      --name my-macvlan-alpine \
-      alpine:latest \
-      ash
-    ```
-
-3.  Inspect the `my-macvlan-alpine` container and notice the `MacAddress` key
-    within the `Networks` key:
-
-    ```console
-    $ docker container inspect my-macvlan-alpine
-
-    ...truncated...
-    "Networks": {
-      "my-macvlan-net": {
-          "IPAMConfig": null,
-          "Links": null,
-          "Aliases": [
-              "bec64291cd4c"
-          ],
-          "NetworkID": "5e3ec79625d388dbcc03dcf4a6dc4548644eb99d58864cf8eee2252dcfc0cc9f",
-          "EndpointID": "8caf93c862b22f379b60515975acf96f7b54b7cf0ba0fb4a33cf18ae9e5c1d89",
-          "Gateway": "172.16.86.1",
-          "IPAddress": "172.16.86.2",
-          "IPPrefixLen": 24,
-          "IPv6Gateway": "",
-          "GlobalIPv6Address": "",
-          "GlobalIPv6PrefixLen": 0,
-          "MacAddress": "02:42:ac:10:56:02",
-          "DriverOpts": null
-      }
-    }
-    ...truncated
-    ```
-
-4.  Check out how the container sees its own network interfaces by running a
-    couple of `docker exec` commands.
-
-    ```console
-    $ docker exec my-macvlan-alpine ip addr show eth0
-
-    9: eth0@tunl0: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
-    link/ether 02:42:ac:10:56:02 brd ff:ff:ff:ff:ff:ff
-    inet 172.16.86.2/24 brd 172.16.86.255 scope global eth0
-       valid_lft forever preferred_lft forever
-    ```
-
-    ```console
-    $ docker exec my-macvlan-alpine ip route
-
-    default via 172.16.86.1 dev eth0
-    172.16.86.0/24 dev eth0 scope link  src 172.16.86.2
-    ```
-
-5.  Stop the container (Docker removes it because of the `--rm` flag), and remove
-    the network.
-
-    ```console
-    $ docker container stop my-macvlan-alpine
-
-    $ docker network rm my-macvlan-net
-    ```
-
-## 802.1Q trunked bridge example
-
-In the 802.1Q trunked bridge example, your traffic flows through a sub-interface
-of `eth0` (called `eth0.10`) and Docker routes traffic to your container using
-its MAC address. To network devices on your network, your container appears to
-be physically attached to the network.
-
-1.  Create a `macvlan` network called `my-8021q-macvlan-net`. Modify the
-    `subnet`, `gateway`, and `parent` values to values that make sense in your
-    environment.
-
-    ```console
-    $ docker network create -d macvlan \
-      --subnet=172.16.86.0/24 \
-      --gateway=172.16.86.1 \
-      -o parent=eth0.10 \
-      my-8021q-macvlan-net
-    ```
-
-    You can use `docker network ls` and `docker network inspect my-8021q-macvlan-net`
-    commands to verify that the network exists, is a `macvlan` network, and
-    has parent `eth0.10`. You can use `ip addr show` on the Docker host to
-    verify that the interface `eth0.10` exists and has a separate IP address
-
-2.  Start an `alpine` container and attach it to the `my-8021q-macvlan-net`
-    network. The `-dit` flags start the container in the background but allow
-    you to attach to it. The `--rm` flag means the container is removed when it
-    is stopped.
-
-    ```console
-    $ docker run --rm -itd \
-      --network my-8021q-macvlan-net \
-      --name my-second-macvlan-alpine \
-      alpine:latest \
-      ash
-    ```
-
-3.  Inspect the `my-second-macvlan-alpine` container and notice the `MacAddress`
-    key within the `Networks` key:
-
-    ```console
-    $ docker container inspect my-second-macvlan-alpine
-
-    ...truncated...
-    "Networks": {
-      "my-8021q-macvlan-net": {
-          "IPAMConfig": null,
-          "Links": null,
-          "Aliases": [
-              "12f5c3c9ba5c"
-          ],
-          "NetworkID": "c6203997842e654dd5086abb1133b7e6df627784fec063afcbee5893b2bb64db",
-          "EndpointID": "aa08d9aa2353c68e8d2ae0bf0e11ed426ea31ed0dd71c868d22ed0dcf9fc8ae6",
-          "Gateway": "172.16.86.1",
-          "IPAddress": "172.16.86.2",
-          "IPPrefixLen": 24,
-          "IPv6Gateway": "",
-          "GlobalIPv6Address": "",
-          "GlobalIPv6PrefixLen": 0,
-          "MacAddress": "02:42:ac:10:56:02",
-          "DriverOpts": null
-      }
-    }
-    ...truncated
-    ```
-
-4.  Check out how the container sees its own network interfaces by running a
-    couple of `docker exec` commands.
-
-    ```console
-    $ docker exec my-second-macvlan-alpine ip addr show eth0
-
-    11: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
-    link/ether 02:42:ac:10:56:02 brd ff:ff:ff:ff:ff:ff
-    inet 172.16.86.2/24 brd 172.16.86.255 scope global eth0
-       valid_lft forever preferred_lft forever
-    ```
-
-    ```console
-    $ docker exec my-second-macvlan-alpine ip route
-
-    default via 172.16.86.1 dev eth0
-    172.16.86.0/24 dev eth0 scope link  src 172.16.86.2
-    ```
-
-5.  Stop the container (Docker removes it because of the `--rm` flag), and remove
-    the network.
-
-    ```console
-    $ docker container stop my-second-macvlan-alpine
-
-    $ docker network rm my-8021q-macvlan-net
-    ```
-
-## Other networking tutorials
-
-- [Standalone networking tutorial](/manuals/engine/network/tutorials/standalone.md)
-- [Overlay networking tutorial](/manuals/engine/network/tutorials/overlay.md)
-- [Host networking tutorial](/manuals/engine/network/tutorials/host.md)
diff --git a/content/manuals/engine/network/tutorials/overlay.md b/content/manuals/engine/network/tutorials/overlay.md
deleted file mode 100644
index 0fbcc7d2ae85..000000000000
--- a/content/manuals/engine/network/tutorials/overlay.md
+++ /dev/null
@@ -1,442 +0,0 @@
----
-title: Networking with overlay networks
-description: Tutorials for networking with swarm services and standalone containers
-  on multiple Docker daemons
-keywords: networking, bridge, routing, ports, swarm, overlay
-aliases:
-- /engine/userguide/networking/get-started-overlay/
-- /network/network-tutorial-overlay/
----
-
-This series of tutorials deals with networking for swarm services.
-For networking with standalone containers, see
-[Networking with standalone containers](/manuals/engine/network/tutorials/standalone.md). If you need to
-learn more about Docker networking in general, see the [overview](/manuals/engine/network/_index.md).
-
-This page includes the following tutorials. You can run each of them on
-Linux, Windows, or a Mac, but for the last one, you need a second Docker
-host running elsewhere.
-
-- [Use the default overlay network](#use-the-default-overlay-network) demonstrates
-  how to use the default overlay network that Docker sets up for you
-  automatically when you initialize or join a swarm. This network is not the
-  best choice for production systems.
-
-- [Use user-defined overlay networks](#use-a-user-defined-overlay-network) shows
-  how to create and use your own custom overlay networks, to connect services.
-  This is recommended for services running in production.
-
-- [Use an overlay network for standalone containers](#use-an-overlay-network-for-standalone-containers)
-  shows how to communicate between standalone containers on different Docker
-  daemons using an overlay network.
-
-## Prerequisites
-
-These require you to have at least a single-node swarm, which means that
-you have started Docker and run `docker swarm init` on the host. You can run
-the examples on a multi-node swarm as well.
-
-## Use the default overlay network
-
-In this example, you start an `alpine` service and examine the characteristics
-of the network from the point of view of the individual service containers.
-
-This tutorial does not go into operation-system-specific details about how
-overlay networks are implemented, but focuses on how the overlay functions from
-the point of view of a service.
-
-### Prerequisites
-
-This tutorial requires three physical or virtual Docker hosts which can all
-communicate with one another. This tutorial assumes that the three hosts are
-running on the same network with no firewall involved.
-
-These hosts will be referred to as `manager`, `worker-1`, and `worker-2`. The
-`manager` host will function as both a manager and a worker, which means it can
-both run service tasks and manage the swarm. `worker-1` and `worker-2` will
-function as workers only,
-
-If you don't have three hosts handy, an easy solution is to set up three
-Ubuntu hosts on a cloud provider such as Amazon EC2, all on the same network
-with all communications allowed to all hosts on that network (using a mechanism
-such as EC2 security groups), and then to follow the
-[installation instructions for Docker Engine - Community on Ubuntu](/manuals/engine/install/ubuntu.md).
-
-### Walkthrough
-
-#### Create the swarm
-
-At the end of this procedure, all three Docker hosts will be joined to the swarm
-and will be connected together using an overlay network called `ingress`.
-
-1.  On `manager`. initialize the swarm. If the host only has one network
-    interface, the `--advertise-addr` flag is optional.
-
-    ```console
-    $ docker swarm init --advertise-addr=<IP-ADDRESS-OF-MANAGER>
-    ```
-
-    Make a note of the text that is printed, as this contains the token that
-    you will use to join `worker-1` and `worker-2` to the swarm. It is a good
-    idea to store the token in a password manager.
-
-2.  On `worker-1`, join the swarm. If the host only has one network interface,
-    the `--advertise-addr` flag is optional.
-
-    ```console
-    $ docker swarm join --token <TOKEN> \
-      --advertise-addr <IP-ADDRESS-OF-WORKER-1> \
-      <IP-ADDRESS-OF-MANAGER>:2377
-    ```
-
-3.  On `worker-2`, join the swarm. If the host only has one network interface,
-    the `--advertise-addr` flag is optional.
-
-    ```console
-    $ docker swarm join --token <TOKEN> \
-      --advertise-addr <IP-ADDRESS-OF-WORKER-2> \
-      <IP-ADDRESS-OF-MANAGER>:2377
-    ```
-
-4.  On `manager`, list all the nodes. This command can only be done from a
-    manager.
-
-    ```console
-    $ docker node ls
-
-    ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS
-    d68ace5iraw6whp7llvgjpu48 *   ip-172-31-34-146    Ready               Active              Leader
-    nvp5rwavvb8lhdggo8fcf7plg     ip-172-31-35-151    Ready               Active
-    ouvx2l7qfcxisoyms8mtkgahw     ip-172-31-36-89     Ready               Active
-    ```
-
-    You can also use the `--filter` flag to filter by role:
-
-    ```console
-    $ docker node ls --filter role=manager
-
-    ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS
-    d68ace5iraw6whp7llvgjpu48 *   ip-172-31-34-146    Ready               Active              Leader
-
-    $ docker node ls --filter role=worker
-
-    ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS
-    nvp5rwavvb8lhdggo8fcf7plg     ip-172-31-35-151    Ready               Active
-    ouvx2l7qfcxisoyms8mtkgahw     ip-172-31-36-89     Ready               Active
-    ```
-
-5.  List the Docker networks on `manager`, `worker-1`, and `worker-2` and notice
-    that each of them now has an overlay network called `ingress` and a bridge
-    network called `docker_gwbridge`. Only the listing for `manager` is shown
-    here:
-
-    ```console
-    $ docker network ls
-
-    NETWORK ID          NAME                DRIVER              SCOPE
-    495c570066be        bridge              bridge              local
-    961c6cae9945        docker_gwbridge     bridge              local
-    ff35ceda3643        host                host                local
-    trtnl4tqnc3n        ingress             overlay             swarm
-    c8357deec9cb        none                null                local
-    ```
-
-The `docker_gwbridge` connects the `ingress` network to the Docker host's
-network interface so that traffic can flow to and from swarm managers and
-workers. If you create swarm services and do not specify a network, they are
-connected to the `ingress` network. It is recommended that you use separate
-overlay networks for each application or group of applications which will work
-together. In the next procedure, you will create two overlay networks and
-connect a service to each of them.
-
-#### Create the services
-
-1.  On `manager`, create a new overlay network called `nginx-net`:
-
-    ```console
-    $ docker network create -d overlay nginx-net
-    ```
-
-    You don't need to create the overlay network on the other nodes, because it
-    will be automatically created when one of those nodes starts running a
-    service task which requires it.
-
-2.  On `manager`, create a 5-replica Nginx service connected to `nginx-net`. The
-    service will publish port 80 to the outside world. All of the service
-    task containers can communicate with each other without opening any ports.
-
-    > [!NOTE]
-    >
-    > Services can only be created on a manager.
-
-    ```console
-    $ docker service create \
-      --name my-nginx \
-      --publish target=80,published=80 \
-      --replicas=5 \
-      --network nginx-net \
-      nginx
-      ```
-
-      The default publish mode of `ingress`, which is used when you do not
-      specify a `mode` for the `--publish` flag, means that if you browse to
-      port 80 on `manager`, `worker-1`, or `worker-2`, you will be connected to
-      port 80 on one of the 5 service tasks, even if no tasks are currently
-      running on the node you browse to. If you want to publish the port using
-      `host` mode, you can add `mode=host` to the `--publish` output. However,
-      you should also use `--mode global` instead of `--replicas=5` in this case,
-      since only one service task can bind a given port on a given node.
-
-3.  Run `docker service ls` to monitor the progress of service bring-up, which
-    may take a few seconds.
-
-4.  Inspect the `nginx-net` network on `manager`, `worker-1`, and `worker-2`.
-    Remember that you did not need to create it manually on `worker-1` and
-    `worker-2` because Docker created it for you. The output will be long, but
-    notice the `Containers` and `Peers` sections. `Containers` lists all
-    service tasks (or standalone containers) connected to the overlay network
-    from that host.
-
-5.  From `manager`, inspect the service using `docker service inspect my-nginx`
-    and notice the information about the ports and endpoints used by the
-    service.
-
-6.  Create a new network `nginx-net-2`, then update the service to use this
-    network instead of `nginx-net`:
-
-    ```console
-    $ docker network create -d overlay nginx-net-2
-    ```
-
-    ```console
-    $ docker service update \
-      --network-add nginx-net-2 \
-      --network-rm nginx-net \
-      my-nginx
-    ```
-
-7.  Run `docker service ls` to verify that the service has been updated and all
-    tasks have been redeployed. Run `docker network inspect nginx-net` to verify
-    that no containers are connected to it. Run the same command for
-    `nginx-net-2` and notice that all the service task containers are connected
-    to it.
-
-    > [!NOTE]
-    >
-    > Even though overlay networks are automatically created on swarm
-    > worker nodes as needed, they are not automatically removed.
-
-8.  Clean up the service and the networks. From `manager`, run the following
-    commands. The manager will direct the workers to remove the networks
-    automatically.
-
-    ```console
-    $ docker service rm my-nginx
-    $ docker network rm nginx-net nginx-net-2
-    ```
-
-## Use a user-defined overlay network
-
-### Prerequisites
-
-This tutorial assumes the swarm is already set up and you are on a manager.
-
-### Walkthrough
-
-1.  Create the user-defined overlay network.
-
-    ```console
-    $ docker network create -d overlay my-overlay
-    ```
-
-2.  Start a service using the overlay network and publishing port 80 to port
-    8080 on the Docker host.
-
-    ```console
-    $ docker service create \
-      --name my-nginx \
-      --network my-overlay \
-      --replicas 1 \
-      --publish published=8080,target=80 \
-      nginx:latest
-    ```
-
-3.  Run `docker network inspect my-overlay` and verify that the `my-nginx`
-    service task is connected to it, by looking at the `Containers` section.
-
-4.  Remove the service and the network.
-
-    ```console
-    $ docker service rm my-nginx
-
-    $ docker network rm my-overlay
-    ```
-
-## Use an overlay network for standalone containers
-
-This example demonstrates DNS container discovery -- specifically, how to
-communicate between standalone containers on different Docker daemons using an
-overlay network. Steps are:
-
-- On `host1`, initialize the node as a swarm (manager).
-- On `host2`, join the node to the swarm (worker).
-- On `host1`, create an attachable overlay network (`test-net`).
-- On `host1`, run an interactive [alpine](https://hub.docker.com/_/alpine/) container (`alpine1`) on `test-net`.
-- On `host2`, run an interactive, and detached, [alpine](https://hub.docker.com/_/alpine/) container (`alpine2`) on `test-net`.
-- On `host1`, from within a session of `alpine1`, ping `alpine2`.
-
-### Prerequisites
-
-For this test, you need two different Docker hosts that can communicate with
-each other. Each host must have the following ports open between the two Docker
-hosts:
-
-- TCP port 2377
-- TCP and UDP port 7946
-- UDP port 4789
-
-One easy way to set this up is to have two VMs (either local or on a cloud
-provider like AWS), each with Docker installed and running. If you're using AWS
-or a similar cloud computing platform, the easiest configuration is to use a
-security group that opens all incoming ports between the two hosts and the SSH
-port from your client's IP address.
-
-This example refers to the two nodes in our swarm as `host1` and `host2`. This
-example also uses Linux hosts, but the same commands work on Windows.
-
-### Walk-through
-
-1.  Set up the swarm.
-
-    a.  On `host1`, initialize a swarm (and if prompted, use `--advertise-addr`
-        to specify the IP address for the interface that communicates with other
-        hosts in the swarm, for instance, the private IP address on AWS):
-
-
-    ```console
-    $ docker swarm init
-    Swarm initialized: current node (vz1mm9am11qcmo979tlrlox42) is now a manager.
-
-    To add a worker to this swarm, run the following command:
-
-        docker swarm join --token SWMTKN-1-5g90q48weqrtqryq4kj6ow0e8xm9wmv9o6vgqc5j320ymybd5c-8ex8j0bc40s6hgvy5ui5gl4gy 172.31.47.252:2377
-
-    To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
-    ```
-
-    b.  On `host2`, join the swarm as instructed above:
-
-    ```console
-    $ docker swarm join --token <your_token> <your_ip_address>:2377
-    This node joined a swarm as a worker.
-    ```
-
-    If the node fails to join the swarm, the `docker swarm join` command times
-    out. To resolve, run `docker swarm leave --force` on `host2`, verify your
-    network and firewall settings, and try again.
-
-2.  On `host1`, create an attachable overlay network called `test-net`:
-
-    ```console
-    $ docker network create --driver=overlay --attachable test-net
-    uqsof8phj3ak0rq9k86zta6ht
-    ```
-
-    > Notice the returned **NETWORK ID** -- you will see it again when you connect to it from `host2`.
-
-3.  On `host1`, start an interactive (`-it`) container (`alpine1`) that connects to `test-net`:
-
-    ```console
-    $ docker run -it --name alpine1 --network test-net alpine
-    / #
-    ```
-
-4.  On `host2`, list the available networks -- notice that `test-net` does not yet exist:
-
-    ```console
-    $ docker network ls
-    NETWORK ID          NAME                DRIVER              SCOPE
-    ec299350b504        bridge              bridge              local
-    66e77d0d0e9a        docker_gwbridge     bridge              local
-    9f6ae26ccb82        host                host                local
-    omvdxqrda80z        ingress             overlay             swarm
-    b65c952a4b2b        none                null                local
-    ```
-
-5.  On `host2`, start a detached (`-d`) and interactive (`-it`) container (`alpine2`) that connects to `test-net`:
-
-    ```console
-    $ docker run -dit --name alpine2 --network test-net alpine
-    fb635f5ece59563e7b8b99556f816d24e6949a5f6a5b1fbd92ca244db17a4342
-    ```
-
-    > [!NOTE]
-    >
-    > Automatic DNS container discovery only works with unique container names.
-
-6. On `host2`, verify that `test-net` was created (and has the same NETWORK ID as `test-net` on `host1`):
-
-    ```console
-    $ docker network ls
-    NETWORK ID          NAME                DRIVER              SCOPE
-    ...
-    uqsof8phj3ak        test-net            overlay             swarm
-    ```
-
-7.  On `host1`, ping `alpine2` within the interactive terminal of `alpine1`:
-
-    ```console
-    / # ping -c 2 alpine2
-    PING alpine2 (10.0.0.5): 56 data bytes
-    64 bytes from 10.0.0.5: seq=0 ttl=64 time=0.600 ms
-    64 bytes from 10.0.0.5: seq=1 ttl=64 time=0.555 ms
-
-    --- alpine2 ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 0.555/0.577/0.600 ms
-    ```
-
-    The two containers communicate with the overlay network connecting the two
-    hosts. If you run another alpine container on `host2` that is _not detached_,
-    you can ping `alpine1` from `host2` (and here we add the
-    [remove option](/reference/cli/docker/container/run/#rm) for automatic container cleanup):
-
-    ```sh
-    $ docker run -it --rm --name alpine3 --network test-net alpine
-    / # ping -c 2 alpine1
-    / # exit
-    ```
-
-8.  On `host1`, close the `alpine1` session (which also stops the container):
-
-    ```console
-    / # exit
-    ```
-
-9.  Clean up your containers and networks:
-
-    You must stop and remove the containers on each host independently because
-    Docker daemons operate independently and these are standalone containers.
-    You only have to remove the network on `host1` because when you stop
-    `alpine2` on `host2`, `test-net` disappears.
-
-    a.  On `host2`, stop `alpine2`, check that `test-net` was removed, then remove `alpine2`:
-
-    ```console
-    $ docker container stop alpine2
-    $ docker network ls
-    $ docker container rm alpine2
-    ```
-
-    a.  On `host1`, remove `alpine1` and `test-net`:
-
-    ```console
-    $ docker container rm alpine1
-    $ docker network rm test-net
-    ```
-
-## Other networking tutorials
-
-- [Host networking tutorial](/manuals/engine/network/tutorials/host.md)
-- [Standalone networking tutorial](/manuals/engine/network/tutorials/standalone.md)
-- [Macvlan networking tutorial](/manuals/engine/network/tutorials/macvlan.md)
diff --git a/content/manuals/engine/network/tutorials/standalone.md b/content/manuals/engine/network/tutorials/standalone.md
deleted file mode 100644
index 3e4c4a09d2a8..000000000000
--- a/content/manuals/engine/network/tutorials/standalone.md
+++ /dev/null
@@ -1,622 +0,0 @@
----
-title: Networking with standalone containers
-description: Tutorials for networking with standalone containers
-keywords: networking, bridge, routing, ports, overlay
-aliases:
-  - /network/network-tutorial-standalone/
----
-
-This series of tutorials deals with networking for standalone Docker containers.
-For networking with swarm services, see
-[Networking with swarm services](/manuals/engine/network/tutorials/overlay.md). If you need to
-learn more about Docker networking in general, see the [overview](/manuals/engine/network/_index.md).
-
-This topic includes two different tutorials. You can run each of them on
-Linux, Windows, or a Mac, but for the last one, you need a second Docker
-host running elsewhere.
-
-- [Use the default bridge network](#use-the-default-bridge-network) demonstrates
-  how to use the default `bridge` network that Docker sets up for you
-  automatically. This network is not the best choice for production systems.
-
-- [Use user-defined bridge networks](#use-user-defined-bridge-networks) shows
-  how to create and use your own custom bridge networks, to connect containers
-  running on the same Docker host. This is recommended for standalone containers
-  running in production.
-
-Although [overlay networks](/manuals/engine/network/drivers/overlay.md) are generally used for swarm services,
-you can also use an overlay network for standalone containers. That's covered as
-part of the [tutorial on using overlay networks](/manuals/engine/network/tutorials/overlay.md#use-an-overlay-network-for-standalone-containers).
-
-## Use the default bridge network
-
-In this example, you start two different `alpine` containers on the same Docker
-host and do some tests to understand how they communicate with each other. You
-need to have Docker installed and running.
-
-1.  Open a terminal window. List current networks before you do anything else.
-    Here's what you should see if you've never added a network or initialized a
-    swarm on this Docker daemon. You may see different networks, but you should
-    at least see these (the network IDs will be different):
-
-    ```console
-    $ docker network ls
-
-    NETWORK ID          NAME                DRIVER              SCOPE
-    17e324f45964        bridge              bridge              local
-    6ed54d316334        host                host                local
-    7092879f2cc8        none                null                local
-    ```
-
-    The default `bridge` network is listed, along with `host` and `none`. The
-    latter two are not fully-fledged networks, but are used to start a container
-    connected directly to the Docker daemon host's networking stack, or to start
-    a container with no network devices. This tutorial will connect two
-    containers to the `bridge` network.
-
-2.  Start two `alpine` containers running `ash`, which is Alpine's default shell
-    rather than `bash`. The `-dit` flags mean to start the container detached
-    (in the background), interactive (with the ability to type into it), and
-    with a TTY (so you can see the input and output). Since you are starting it
-    detached, you won't be connected to the container right away. Instead, the
-    container's ID will be printed. Because you have not specified any
-    `--network` flags, the containers connect to the default `bridge` network.
-
-    ```console
-    $ docker run -dit --name alpine1 alpine ash
-
-    $ docker run -dit --name alpine2 alpine ash
-    ```
-
-    Check that both containers are actually started:
-
-    ```console
-    $ docker container ls
-
-    CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
-    602dbf1edc81        alpine              "ash"               4 seconds ago       Up 3 seconds                            alpine2
-    da33b7aa74b0        alpine              "ash"               17 seconds ago      Up 16 seconds                           alpine1
-    ```
-
-3.  Inspect the `bridge` network to see what containers are connected to it.
-
-    ```console
-    $ docker network inspect bridge
-
-    [
-        {
-            "Name": "bridge",
-            "Id": "17e324f459648a9baaea32b248d3884da102dde19396c25b30ec800068ce6b10",
-            "Created": "2017-06-22T20:27:43.826654485Z",
-            "Scope": "local",
-            "Driver": "bridge",
-            "EnableIPv6": false,
-            "IPAM": {
-                "Driver": "default",
-                "Options": null,
-                "Config": [
-                    {
-                        "Subnet": "172.17.0.0/16",
-                        "Gateway": "172.17.0.1"
-                    }
-                ]
-            },
-            "Internal": false,
-            "Attachable": false,
-            "Containers": {
-                "602dbf1edc81813304b6cf0a647e65333dc6fe6ee6ed572dc0f686a3307c6a2c": {
-                    "Name": "alpine2",
-                    "EndpointID": "03b6aafb7ca4d7e531e292901b43719c0e34cc7eef565b38a6bf84acf50f38cd",
-                    "MacAddress": "02:42:ac:11:00:03",
-                    "IPv4Address": "172.17.0.3/16",
-                    "IPv6Address": ""
-                },
-                "da33b7aa74b0bf3bda3ebd502d404320ca112a268aafe05b4851d1e3312ed168": {
-                    "Name": "alpine1",
-                    "EndpointID": "46c044a645d6afc42ddd7857d19e9dcfb89ad790afb5c239a35ac0af5e8a5bc5",
-                    "MacAddress": "02:42:ac:11:00:02",
-                    "IPv4Address": "172.17.0.2/16",
-                    "IPv6Address": ""
-                }
-            },
-            "Options": {
-                "com.docker.network.bridge.default_bridge": "true",
-                "com.docker.network.bridge.enable_icc": "true",
-                "com.docker.network.bridge.enable_ip_masquerade": "true",
-                "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
-                "com.docker.network.bridge.name": "docker0",
-                "com.docker.network.driver.mtu": "1500"
-            },
-            "Labels": {}
-        }
-    ]
-    ```
-
-    Near the top, information about the `bridge` network is listed, including
-    the IP address of the gateway between the Docker host and the `bridge`
-    network (`172.17.0.1`). Under the `Containers` key, each connected container
-    is listed, along with information about its IP address (`172.17.0.2` for
-    `alpine1` and `172.17.0.3` for `alpine2`).
-
-4.  The containers are running in the background. Use the `docker attach`
-    command to connect to `alpine1`.
-
-    ```console
-    $ docker attach alpine1
-
-    / #
-    ```
-
-    The prompt changes to `#` to indicate that you are the `root` user within
-    the container. Use the `ip addr show` command to show the network interfaces
-    for `alpine1` as they look from within the container:
-
-    ```console
-    # ip addr show
-
-    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
-        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
-        inet 127.0.0.1/8 scope host lo
-           valid_lft forever preferred_lft forever
-        inet6 ::1/128 scope host
-           valid_lft forever preferred_lft forever
-    27: eth0@if28: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
-        link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
-        inet 172.17.0.2/16 scope global eth0
-           valid_lft forever preferred_lft forever
-        inet6 fe80::42:acff:fe11:2/64 scope link
-           valid_lft forever preferred_lft forever
-    ```
-
-    The first interface is the loopback device. Ignore it for now. Notice that
-    the second interface has the IP address `172.17.0.2`, which is the same
-    address shown for `alpine1` in the previous step.
-
-5.  From within `alpine1`, make sure you can connect to the internet by
-    pinging `google.com`. The `-c 2` flag limits the command to two `ping`
-    attempts.
-
-    ```console
-    # ping -c 2 google.com
-
-    PING google.com (172.217.3.174): 56 data bytes
-    64 bytes from 172.217.3.174: seq=0 ttl=41 time=9.841 ms
-    64 bytes from 172.217.3.174: seq=1 ttl=41 time=9.897 ms
-
-    --- google.com ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 9.841/9.869/9.897 ms
-    ```
-
-6.  Now try to ping the second container. First, ping it by its IP address,
-    `172.17.0.3`:
-
-    ```console
-    # ping -c 2 172.17.0.3
-
-    PING 172.17.0.3 (172.17.0.3): 56 data bytes
-    64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.086 ms
-    64 bytes from 172.17.0.3: seq=1 ttl=64 time=0.094 ms
-
-    --- 172.17.0.3 ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 0.086/0.090/0.094 ms
-    ```
-
-    This succeeds. Next, try pinging the `alpine2` container by container
-    name. This will fail.
-
-    ```console
-    # ping -c 2 alpine2
-
-    ping: bad address 'alpine2'
-    ```
-
-7.  Detach from `alpine1` without stopping it by using the detach sequence,
-    `CTRL` + `p` `CTRL` + `q` (hold down `CTRL` and type `p` followed by `q`).
-    If you wish, attach to `alpine2` and repeat steps 4, 5, and 6 there,
-    substituting `alpine1` for `alpine2`.
-
-8.  Stop and remove both containers.
-
-    ```console
-    $ docker container stop alpine1 alpine2
-    $ docker container rm alpine1 alpine2
-    ```
-
-Remember, the default `bridge` network is not recommended for production. To
-learn about user-defined bridge networks, continue to the
-[next tutorial](#use-user-defined-bridge-networks).
-
-## Use user-defined bridge networks
-
-In this example, we again start two `alpine` containers, but attach them to a
-user-defined network called `alpine-net` which we have already created. These
-containers are not connected to the default `bridge` network at all. We then
-start a third `alpine` container which is connected to the `bridge` network but
-not connected to `alpine-net`, and a fourth `alpine` container which is
-connected to both networks.
-
-1.  Create the `alpine-net` network. You do not need the `--driver bridge` flag
-    since it's the default, but this example shows how to specify it.
-
-    ```console
-    $ docker network create --driver bridge alpine-net
-    ```
-
-2.  List Docker's networks:
-
-    ```console
-    $ docker network ls
-
-    NETWORK ID          NAME                DRIVER              SCOPE
-    e9261a8c9a19        alpine-net          bridge              local
-    17e324f45964        bridge              bridge              local
-    6ed54d316334        host                host                local
-    7092879f2cc8        none                null                local
-    ```
-
-    Inspect the `alpine-net` network. This shows you its IP address and the fact
-    that no containers are connected to it:
-
-    ```console
-    $ docker network inspect alpine-net
-
-    [
-        {
-            "Name": "alpine-net",
-            "Id": "e9261a8c9a19eabf2bf1488bf5f208b99b1608f330cff585c273d39481c9b0ec",
-            "Created": "2017-09-25T21:38:12.620046142Z",
-            "Scope": "local",
-            "Driver": "bridge",
-            "EnableIPv6": false,
-            "IPAM": {
-                "Driver": "default",
-                "Options": {},
-                "Config": [
-                    {
-                        "Subnet": "172.18.0.0/16",
-                        "Gateway": "172.18.0.1"
-                    }
-                ]
-            },
-            "Internal": false,
-            "Attachable": false,
-            "Containers": {},
-            "Options": {},
-            "Labels": {}
-        }
-    ]
-    ```
-
-    Notice that this network's gateway is `172.18.0.1`, as opposed to the
-    default bridge network, whose gateway is `172.17.0.1`. The exact IP address
-    may be different on your system.
-
-3.  Create your four containers. Notice the `--network` flags. You can only
-    connect to one network during the `docker run` command, so you need to use
-    `docker network connect` afterward to connect `alpine4` to the `bridge`
-    network as well.
-
-    ```console
-    $ docker run -dit --name alpine1 --network alpine-net alpine ash
-
-    $ docker run -dit --name alpine2 --network alpine-net alpine ash
-
-    $ docker run -dit --name alpine3 alpine ash
-
-    $ docker run -dit --name alpine4 --network alpine-net alpine ash
-
-    $ docker network connect bridge alpine4
-    ```
-
-    Verify that all containers are running:
-
-    ```console
-    $ docker container ls
-
-    CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
-    156849ccd902        alpine              "ash"               41 seconds ago       Up 41 seconds                           alpine4
-    fa1340b8d83e        alpine              "ash"               51 seconds ago       Up 51 seconds                           alpine3
-    a535d969081e        alpine              "ash"               About a minute ago   Up About a minute                       alpine2
-    0a02c449a6e9        alpine              "ash"               About a minute ago   Up About a minute                       alpine1
-    ```
-
-4.  Inspect the `bridge` network and the `alpine-net` network again:
-
-    ```console
-    $ docker network inspect bridge
-
-    [
-        {
-            "Name": "bridge",
-            "Id": "17e324f459648a9baaea32b248d3884da102dde19396c25b30ec800068ce6b10",
-            "Created": "2017-06-22T20:27:43.826654485Z",
-            "Scope": "local",
-            "Driver": "bridge",
-            "EnableIPv6": false,
-            "IPAM": {
-                "Driver": "default",
-                "Options": null,
-                "Config": [
-                    {
-                        "Subnet": "172.17.0.0/16",
-                        "Gateway": "172.17.0.1"
-                    }
-                ]
-            },
-            "Internal": false,
-            "Attachable": false,
-            "Containers": {
-                "156849ccd902b812b7d17f05d2d81532ccebe5bf788c9a79de63e12bb92fc621": {
-                    "Name": "alpine4",
-                    "EndpointID": "7277c5183f0da5148b33d05f329371fce7befc5282d2619cfb23690b2adf467d",
-                    "MacAddress": "02:42:ac:11:00:03",
-                    "IPv4Address": "172.17.0.3/16",
-                    "IPv6Address": ""
-                },
-                "fa1340b8d83eef5497166951184ad3691eb48678a3664608ec448a687b047c53": {
-                    "Name": "alpine3",
-                    "EndpointID": "5ae767367dcbebc712c02d49556285e888819d4da6b69d88cd1b0d52a83af95f",
-                    "MacAddress": "02:42:ac:11:00:02",
-                    "IPv4Address": "172.17.0.2/16",
-                    "IPv6Address": ""
-                }
-            },
-            "Options": {
-                "com.docker.network.bridge.default_bridge": "true",
-                "com.docker.network.bridge.enable_icc": "true",
-                "com.docker.network.bridge.enable_ip_masquerade": "true",
-                "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
-                "com.docker.network.bridge.name": "docker0",
-                "com.docker.network.driver.mtu": "1500"
-            },
-            "Labels": {}
-        }
-    ]
-    ```
-
-    Containers `alpine3` and `alpine4` are connected to the `bridge` network.
-
-    ```console
-    $ docker network inspect alpine-net
-
-    [
-        {
-            "Name": "alpine-net",
-            "Id": "e9261a8c9a19eabf2bf1488bf5f208b99b1608f330cff585c273d39481c9b0ec",
-            "Created": "2017-09-25T21:38:12.620046142Z",
-            "Scope": "local",
-            "Driver": "bridge",
-            "EnableIPv6": false,
-            "IPAM": {
-                "Driver": "default",
-                "Options": {},
-                "Config": [
-                    {
-                        "Subnet": "172.18.0.0/16",
-                        "Gateway": "172.18.0.1"
-                    }
-                ]
-            },
-            "Internal": false,
-            "Attachable": false,
-            "Containers": {
-                "0a02c449a6e9a15113c51ab2681d72749548fb9f78fae4493e3b2e4e74199c4a": {
-                    "Name": "alpine1",
-                    "EndpointID": "c83621678eff9628f4e2d52baf82c49f974c36c05cba152db4c131e8e7a64673",
-                    "MacAddress": "02:42:ac:12:00:02",
-                    "IPv4Address": "172.18.0.2/16",
-                    "IPv6Address": ""
-                },
-                "156849ccd902b812b7d17f05d2d81532ccebe5bf788c9a79de63e12bb92fc621": {
-                    "Name": "alpine4",
-                    "EndpointID": "058bc6a5e9272b532ef9a6ea6d7f3db4c37527ae2625d1cd1421580fd0731954",
-                    "MacAddress": "02:42:ac:12:00:04",
-                    "IPv4Address": "172.18.0.4/16",
-                    "IPv6Address": ""
-                },
-                "a535d969081e003a149be8917631215616d9401edcb4d35d53f00e75ea1db653": {
-                    "Name": "alpine2",
-                    "EndpointID": "198f3141ccf2e7dba67bce358d7b71a07c5488e3867d8b7ad55a4c695ebb8740",
-                    "MacAddress": "02:42:ac:12:00:03",
-                    "IPv4Address": "172.18.0.3/16",
-                    "IPv6Address": ""
-                }
-            },
-            "Options": {},
-            "Labels": {}
-        }
-    ]
-    ```
-
-    Containers `alpine1`, `alpine2`, and `alpine4` are connected to the
-    `alpine-net` network.
-
-5.  On user-defined networks like `alpine-net`, containers can not only
-    communicate by IP address, but can also resolve a container name to an IP
-    address. This capability is called automatic service discovery. Let's
-    connect to `alpine1` and test this out. `alpine1` should be able to resolve
-    `alpine2` and `alpine4` (and `alpine1`, itself) to IP addresses.
-    
-    > [!NOTE]
-    > 
-    > Automatic service discovery can only resolve custom container names, not default automatically generated container names,
-
-    ```console
-    $ docker container attach alpine1
-
-    # ping -c 2 alpine2
-
-    PING alpine2 (172.18.0.3): 56 data bytes
-    64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.085 ms
-    64 bytes from 172.18.0.3: seq=1 ttl=64 time=0.090 ms
-
-    --- alpine2 ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 0.085/0.087/0.090 ms
-
-    # ping -c 2 alpine4
-
-    PING alpine4 (172.18.0.4): 56 data bytes
-    64 bytes from 172.18.0.4: seq=0 ttl=64 time=0.076 ms
-    64 bytes from 172.18.0.4: seq=1 ttl=64 time=0.091 ms
-
-    --- alpine4 ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 0.076/0.083/0.091 ms
-
-    # ping -c 2 alpine1
-
-    PING alpine1 (172.18.0.2): 56 data bytes
-    64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.026 ms
-    64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.054 ms
-
-    --- alpine1 ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 0.026/0.040/0.054 ms
-    ```
-
-6.  From `alpine1`, you should not be able to connect to `alpine3` at all, since
-    it is not on the `alpine-net` network.
-
-    ```console
-    # ping -c 2 alpine3
-
-    ping: bad address 'alpine3'
-    ```
-
-    Not only that, but you can't connect to `alpine3` from `alpine1` by its IP
-    address either. Look back at the `docker network inspect` output for the
-    `bridge` network and find `alpine3`'s IP address: `172.17.0.2` Try to ping
-    it.
-
-    ```console
-    # ping -c 2 172.17.0.2
-
-    PING 172.17.0.2 (172.17.0.2): 56 data bytes
-
-    --- 172.17.0.2 ping statistics ---
-    2 packets transmitted, 0 packets received, 100% packet loss
-    ```
-
-    Detach from `alpine1` using detach sequence,
-    `CTRL` + `p` `CTRL` + `q` (hold down `CTRL` and type `p` followed by `q`).
-
-7.  Remember that `alpine4` is connected to both the default `bridge` network
-    and `alpine-net`. It should be able to reach all of the other containers.
-    However, you will need to address `alpine3` by its IP address. Attach to it
-    and run the tests.
-
-    ```console
-    $ docker container attach alpine4
-
-    # ping -c 2 alpine1
-
-    PING alpine1 (172.18.0.2): 56 data bytes
-    64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.074 ms
-    64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.082 ms
-
-    --- alpine1 ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 0.074/0.078/0.082 ms
-
-    # ping -c 2 alpine2
-
-    PING alpine2 (172.18.0.3): 56 data bytes
-    64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.075 ms
-    64 bytes from 172.18.0.3: seq=1 ttl=64 time=0.080 ms
-
-    --- alpine2 ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 0.075/0.077/0.080 ms
-
-    # ping -c 2 alpine3
-    ping: bad address 'alpine3'
-
-    # ping -c 2 172.17.0.2
-
-    PING 172.17.0.2 (172.17.0.2): 56 data bytes
-    64 bytes from 172.17.0.2: seq=0 ttl=64 time=0.089 ms
-    64 bytes from 172.17.0.2: seq=1 ttl=64 time=0.075 ms
-
-    --- 172.17.0.2 ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 0.075/0.082/0.089 ms
-
-    # ping -c 2 alpine4
-
-    PING alpine4 (172.18.0.4): 56 data bytes
-    64 bytes from 172.18.0.4: seq=0 ttl=64 time=0.033 ms
-    64 bytes from 172.18.0.4: seq=1 ttl=64 time=0.064 ms
-
-    --- alpine4 ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 0.033/0.048/0.064 ms
-    ```
-
-8.  As a final test, make sure your containers can all connect to the internet
-    by pinging `google.com`. You are already attached to `alpine4` so start by
-    trying from there. Next, detach from `alpine4` and connect to `alpine3`
-    (which is only attached to the `bridge` network) and try again. Finally,
-    connect to `alpine1` (which is only connected to the `alpine-net` network)
-    and try again.
-
-    ```console
-    # ping -c 2 google.com
-
-    PING google.com (172.217.3.174): 56 data bytes
-    64 bytes from 172.217.3.174: seq=0 ttl=41 time=9.778 ms
-    64 bytes from 172.217.3.174: seq=1 ttl=41 time=9.634 ms
-
-    --- google.com ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 9.634/9.706/9.778 ms
-
-    CTRL+p CTRL+q
-
-    $ docker container attach alpine3
-
-    # ping -c 2 google.com
-
-    PING google.com (172.217.3.174): 56 data bytes
-    64 bytes from 172.217.3.174: seq=0 ttl=41 time=9.706 ms
-    64 bytes from 172.217.3.174: seq=1 ttl=41 time=9.851 ms
-
-    --- google.com ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 9.706/9.778/9.851 ms
-
-    CTRL+p CTRL+q
-
-    $ docker container attach alpine1
-
-    # ping -c 2 google.com
-
-    PING google.com (172.217.3.174): 56 data bytes
-    64 bytes from 172.217.3.174: seq=0 ttl=41 time=9.606 ms
-    64 bytes from 172.217.3.174: seq=1 ttl=41 time=9.603 ms
-
-    --- google.com ping statistics ---
-    2 packets transmitted, 2 packets received, 0% packet loss
-    round-trip min/avg/max = 9.603/9.604/9.606 ms
-
-    CTRL+p CTRL+q
-    ```
-
-9.  Stop and remove all containers and the `alpine-net` network.
-
-    ```console
-    $ docker container stop alpine1 alpine2 alpine3 alpine4
-
-    $ docker container rm alpine1 alpine2 alpine3 alpine4
-
-    $ docker network rm alpine-net
-    ```
-
-
-## Other networking tutorials
-
-- [Host networking tutorial](/manuals/engine/network/tutorials/host.md)
-- [Overlay networking tutorial](/manuals/engine/network/tutorials/overlay.md)
-- [Macvlan networking tutorial](/manuals/engine/network/tutorials/macvlan.md)
diff --git a/content/manuals/engine/release-notes/17.07.md b/content/manuals/engine/release-notes/17.07.md
index 156a9970d9b4..bce33a98a7e2 100644
--- a/content/manuals/engine/release-notes/17.07.md
+++ b/content/manuals/engine/release-notes/17.07.md
@@ -61,7 +61,7 @@ toc_max: 2
 
 ### Swarm mode
 
-* Initial support for plugable secret backends [moby/moby#34157](https://github.com/moby/moby/pull/34157) [moby/moby#34123](https://github.com/moby/moby/pull/34123)
+* Initial support for pluggable secret backends [moby/moby#34157](https://github.com/moby/moby/pull/34157) [moby/moby#34123](https://github.com/moby/moby/pull/34123)
 * Sort swarm stacks and nodes using natural sorting [docker/cli#315](https://github.com/docker/cli/pull/315)
 * Make engine support cluster config event [moby/moby#34032](https://github.com/moby/moby/pull/34032)
 * Only pass a join address when in the process of joining a cluster [moby/moby#33361](https://github.com/moby/moby/pull/33361)
diff --git a/content/manuals/engine/release-notes/23.0.md b/content/manuals/engine/release-notes/23.0.md
index c8536229d672..ae0b40abefb0 100644
--- a/content/manuals/engine/release-notes/23.0.md
+++ b/content/manuals/engine/release-notes/23.0.md
@@ -29,7 +29,7 @@ This page describes the latest changes, additions, known issues, and fixes for D
 For more information about:
 
 - Deprecated and removed features, see [Deprecated Engine Features](../deprecated.md).
-- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history.md).
+- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history/).
 
 Starting with the 23.0.0 release, Docker Engine moves away from using CalVer versioning,
 and starts using the [SemVer versioning format](https://semver.org/).
diff --git a/content/manuals/engine/release-notes/24.0.md b/content/manuals/engine/release-notes/24.0.md
index afd7c4ba4cfc..16e20d36308e 100644
--- a/content/manuals/engine/release-notes/24.0.md
+++ b/content/manuals/engine/release-notes/24.0.md
@@ -13,7 +13,7 @@ This page describes the latest changes, additions, known issues, and fixes for D
 For more information about:
 
 - Deprecated and removed features, see [Deprecated Engine Features](../deprecated.md).
-- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history.md).
+- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history/).
 
 ## 24.0.9
 
diff --git a/content/manuals/engine/release-notes/25.0.md b/content/manuals/engine/release-notes/25.0.md
index d000b7ab9c70..0d1f92823924 100644
--- a/content/manuals/engine/release-notes/25.0.md
+++ b/content/manuals/engine/release-notes/25.0.md
@@ -12,7 +12,7 @@ This page describes the latest changes, additions, known issues, and fixes for D
 For more information about:
 
 - Deprecated and removed features, see [Deprecated Engine Features](../deprecated.md).
-- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history.md).
+- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history/).
 
 ## 25.0.5
 
@@ -217,9 +217,9 @@ For a full list of pull requests and changes in this release, refer to the relev
   `LimitNOFILE=1048576`.
 
   This change currently only affects build containers created with `docker
-  build` when using BuildKit with the `docker` driver. Future versions of
-  containerd will also use this limit, which will cause this behavior to affect
-  all containers, not only build containers.
+  build` when using BuildKit with the `docker` driver. Starting with Docker
+  Engine v29.0 (containerd v2.1.5), this limit applies to all containers, not
+  only build containers.
 
   If you're experiencing issues with the higher ulimit in systemd v240 or later,
   consider adding a system `drop-in` or `override` file to configure the ulimit
diff --git a/content/manuals/engine/release-notes/26.0.md b/content/manuals/engine/release-notes/26.0.md
index eaf1150b13a7..7654b2455a0b 100644
--- a/content/manuals/engine/release-notes/26.0.md
+++ b/content/manuals/engine/release-notes/26.0.md
@@ -12,7 +12,7 @@ This page describes the latest changes, additions, known issues, and fixes for D
 For more information about:
 
 - Deprecated and removed features, see [Deprecated Engine Features](../deprecated.md).
-- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history.md).
+- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history/).
 
 ## 26.0.2
 
diff --git a/content/manuals/engine/release-notes/26.1.md b/content/manuals/engine/release-notes/26.1.md
index 8762b1e07aae..aad9d59cc50b 100644
--- a/content/manuals/engine/release-notes/26.1.md
+++ b/content/manuals/engine/release-notes/26.1.md
@@ -12,7 +12,7 @@ This page describes the latest changes, additions, known issues, and fixes for D
 For more information about:
 
 - Deprecated and removed features, see [Deprecated Engine Features](../deprecated.md).
-- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history.md).
+- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history/).
 
 ## 26.1.4
 
diff --git a/content/manuals/engine/release-notes/27.md b/content/manuals/engine/release-notes/27.md
index a90a7b73dc70..70c4bd0168a2 100644
--- a/content/manuals/engine/release-notes/27.md
+++ b/content/manuals/engine/release-notes/27.md
@@ -9,7 +9,10 @@ tags:
   - Release notes
 aliases:
 - /engine/release-notes/27.1/
-- /engine/release-notes/27.0/
+- /engine/release-notes/27.2/
+- /engine/release-notes/27.3/
+- /engine/release-notes/27.4/
+- /engine/release-notes/27.5/
 ---
 
 This page describes the latest changes, additions, known issues, and fixes for Docker Engine version 27.
@@ -17,7 +20,7 @@ This page describes the latest changes, additions, known issues, and fixes for D
 For more information about:
 
 - Deprecated and removed features, see [Deprecated Engine Features](../deprecated.md).
-- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history.md).
+- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history/).
 
 ## 27.5
 
diff --git a/content/manuals/engine/release-notes/28.md b/content/manuals/engine/release-notes/28.md
index 015be60b89b6..a3134166bcf1 100644
--- a/content/manuals/engine/release-notes/28.md
+++ b/content/manuals/engine/release-notes/28.md
@@ -8,12 +8,12 @@ toc_max: 2
 tags:
   - Release notes
 aliases:
-- /engine/release-notes/
-- /engine/release-notes/latest/
-- /release-notes/docker-ce/
-- /release-notes/docker-engine/
 - /engine/release-notes/28.0/
 - /engine/release-notes/28.1/
+- /engine/release-notes/28.2/
+- /engine/release-notes/28.3/
+- /engine/release-notes/28.4/
+- /engine/release-notes/28.5/
 ---
 
 This page describes the latest changes, additions, known issues, and fixes for Docker Engine version 28.
@@ -21,7 +21,465 @@ This page describes the latest changes, additions, known issues, and fixes for D
 For more information about:
 
 - Deprecated and removed features, see [Deprecated Engine Features](../deprecated.md).
-- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history.md).
+- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history/).
+
+## 28.5.2
+
+{{< release-date date="2025-11-05" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 28.5.2 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A28.5.2)
+- [moby/moby, 28.5.2 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A28.5.2)
+
+> [!CAUTION]
+> This release contains fixes for three high-severity security vulnerabilities in runc:
+> - [CVE-2025-31133](https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2)
+> - [CVE-2025-52565](https://github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r)
+> - [CVE-2025-52881](https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm)
+> 
+> All three vulnerabilities ultimately allow (through different methods) for full container breakouts by bypassing runc's restrictions for writing to arbitrary `/proc` files.
+
+### Bug fixes and enhancements
+
+- dockerd-rootless.sh: if slirp4netns is not installed, try using pasta (passt). [moby/moby#51162](https://github.com/moby/moby/pull/51162)
+
+### Packaging updates
+
+- Update BuildKit to [v0.25.2](https://github.com/moby/buildkit/releases/tag/v0.25.2). [moby/moby#51398](https://github.com/moby/moby/pull/51398)
+- Update Go runtime to [1.24.9](https://go.dev/doc/devel/release#go1.24.9). [moby/moby#51387](https://github.com/moby/moby/pull/51387), [docker/cli#6613](https://github.com/docker/cli/pull/6613)
+- Update runc to [v1.3.3](https://github.com/opencontainers/runc/releases/tag/v1.3.3). [moby/moby#51394](https://github.com/moby/moby/pull/51394)
+
+### Deprecations
+
+- Go-SDK: cli/command/image/build: deprecate `DefaultDockerfileName`, `DetectArchiveReader`, `WriteTempDockerfile`, `ResolveAndValidateContextPath`. These utilities were only used internally and will be removed in the next release. [docker/cli#6610](https://github.com/docker/cli/pull/6610)
+- Go-SDK: cli/command/image/build: deprecate IsArchive utility. [docker/cli#6560](https://github.com/docker/cli/pull/6560)
+- Go-SDK: opts: deprecate `ValidateMACAddress`. [docker/cli#6560](https://github.com/docker/cli/pull/6560)
+- Go-SDK: opts: deprecate ListOpts.Delete(). [docker/cli#6560](https://github.com/docker/cli/pull/6560)
+
+## 28.5.1
+
+{{< release-date date="2025-10-08" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 28.5.1 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A28.5.1)
+- [moby/moby, 28.5.1 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A28.5.1)
+
+### Bug fixes and enhancements
+
+- Update BuildKit to v0.25.1. [moby/moby#51137](https://github.com/moby/moby/pull/51137)
+- Update Go runtime to [1.24.8](https://go.dev/doc/devel/release#go1.24.8). [moby/moby#51133](https://github.com/moby/moby/pull/51133), [docker/cli#6541](https://github.com/docker/cli/pull/6541)
+
+### Deprecations
+
+- api/types/image: InspectResponse: deprecate `Parent` and `DockerVersion` fields. [moby/moby#51105](https://github.com/moby/moby/pull/51105)
+- api/types/plugin: deprecate `Config.DockerVersion` field. [moby/moby#51110](https://github.com/moby/moby/pull/51110)
+
+## 28.5.0
+
+{{< release-date date="2025-10-02" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 28.5.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A28.5.0)
+- [moby/moby, 28.5.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A28.5.0)
+
+> [!WARNING]
+> **Raspberry Pi OS 32-bit (armhf) Deprecation**
+>
+> Docker Engine v28 will be the last major version to support Raspberry Pi OS 32-bit (armhf).
+> Starting with Docker Engine v29, new major versions will **no longer provide packages** for Raspberry Pi OS 32-bit (armhf).
+>
+> #### Migration options
+> - **64-bit ARM:** Install the Debian `arm64` packages (fully supported).
+> - **32-bit ARM (v7):** Install the Debian `armhf` packages (targets ARMv7 CPUs).
+>
+> **Note:** Older devices based on the ARMv6 architecture are no longer supported by official packages, including:
+> - Raspberry Pi 1 (Model A/B/A+/B+)
+> - Raspberry Pi Zero and Zero W
+
+### Bug fixes and enhancements
+
+- Don't print warnings in `docker info` for broken symlinks in CLI-plugin directories. [docker/cli#6476](https://github.com/docker/cli/pull/6476)
+- Fix a panic during `stats` on empty event `Actor.ID`. [docker/cli#6471](https://github.com/docker/cli/pull/6471)
+
+### Packaging updates
+
+- Remove support for legacy CBC cipher suites. [docker/cli#6474](https://github.com/docker/cli/pull/6474)
+- Update Buildkit to [v0.25.0](https://github.com/moby/buildkit/releases/tag/v0.25.0). [moby/moby#51075](https://github.com/moby/moby/pull/51075)
+- Update Dockerfile syntax to [v1.19.0](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.19.0). [moby/moby#51075](https://github.com/moby/moby/pull/51075)
+
+### Networking
+
+- Eliminated harmless warning about deletion of `endpoint_count` from the data store. [moby/moby#51064](https://github.com/moby/moby/pull/51064)
+- Fix a bug causing IPAM plugins to not be loaded on Windows. [moby/moby#51035](https://github.com/moby/moby/pull/51035)
+
+### API
+
+- Deprecate support for kernel memory TCP accounting (`KernelMemoryTCP`). [moby/moby#51067](https://github.com/moby/moby/pull/51067)
+- Fix `GET containers/{name}/checkpoints` returning `null` instead of empty JSON array when there are no checkpoints. [moby/moby#51052](https://github.com/moby/moby/pull/51052)
+
+### Go SDK
+
+- cli-plugins/plugin: Run: allow customizing the CLI. [docker/cli#6481](https://github.com/docker/cli/pull/6481)
+- cli/command: add `WithUserAgent` option. [docker/cli#6477](https://github.com/docker/cli/pull/6477)
+
+### Deprecations
+
+- Go-SDK: cli/command: deprecate `DockerCli.Apply`. This method is no longer used and will be removed in the next release if there are no remaining uses. [docker/cli#6497](https://github.com/docker/cli/pull/6497)
+- Go-SDK: cli/command: deprecate `DockerCli.ContentTrustEnabled`. This method is no longer used and will be removed in the next release. [docker/cli#6495](https://github.com/docker/cli/pull/6495)
+- Go-SDK: cli/command: deprecate `DockerCli.DefaultVersion`. This method is no longer used and will be removed in the next release. [docker/cli#6491](https://github.com/docker/cli/pull/6491)
+- Go-SDK: cli/command: deprecate `ResolveDefaultContext` utility. [docker/cli#6529](https://github.com/docker/cli/pull/6529)
+- Go-SDK: cli/command: deprecate `WithContentTrustFromEnv`, `WithContentTrust` options. These options were used internally, and will be removed in the next release.. [docker/cli#6489](https://github.com/docker/cli/pull/6489)
+- Go-SDK: cli/manifest/store: deprecate `IsNotFound()`. [docker/cli#6514](https://github.com/docker/cli/pull/6514)
+- Go-SDK: templates: deprecate NewParse() function. [docker/cli#6469](https://github.com/docker/cli/pull/6469)
+
+## 28.4.0
+
+{{< release-date date="2025-09-03" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 28.4.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A28.4.0)
+- [moby/moby, 28.4.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A28.4.0)
+
+### New
+
+- Allow Docker CLI to set the `GODEBUG` environment variable when the key-value pair (`"GODEBUG":"..."`) exists inside the docker context metadata. [docker/cli#6399](https://github.com/docker/cli/pull/6399)
+
+### Bug fixes and enhancements
+
+- Add shell completion for `docker pull` and `docker image pull`. [docker/cli#6420](https://github.com/docker/cli/pull/6420)
+- Fix a regression in v28.3.3 that could cause a panic on `docker push` if the client did not send an `X-Registry-Auth` header. [moby/moby#50738](https://github.com/moby/moby/pull/50738)
+- Windows: Potentially fix an issue with "access denied" error when pulling images. [moby/moby#50871](https://github.com/moby/moby/pull/50871)
+- containerd image store: Fix `docker history` failing with `snapshot X does not exist` when calling on a non-native image that was built locally. [moby/moby#50875](https://github.com/moby/moby/pull/50875)
+- containerd image store: Fix `docker image prune` to emit correct `untag` and `delete` events and list only the deleted images root digests instead of every blob. [moby/moby#50837](https://github.com/moby/moby/pull/50837)
+- Remove interactive login prompt from `docker push` and `docker pull` after a failure caused by missing authentication. [docker/cli#6256](https://github.com/docker/cli/pull/6256)
+
+### Packaging updates
+
+- Update BuildKit to [v0.24.0](https://github.com/moby/buildkit/releases/tag/v0.24.0). [moby#50888](https://github.com/moby/moby/pull/50888)
+- Update Go runtime to [1.24.7](https://go.dev/doc/devel/release#go1.24.6). [moby/moby#50889](https://github.com/moby/moby/pull/50889), [docker/cli#6422](https://github.com/docker/cli/pull/6422)
+- Update `runc` to [v1.3.0](https://github.com/opencontainers/runc/releases/tag/v1.3.0). [moby/moby#50699](https://github.com/moby/moby/pull/50699)
+- Update containerd (static binaries only) to [v1.7.28](https://github.com/containerd/containerd/releases/tag/v1.7.28). [moby/moby#50700](https://github.com/moby/moby/pull/50700)
+
+### Networking
+
+- Fix an issue that could cause slow container restart on live-restore. [moby/moby#50829](https://github.com/moby/moby/pull/50829)
+
+### API
+
+- Update deprecation message for `AuthConfig.Email` field. [moby/moby#50797](https://github.com/moby/moby/pull/50797)
+
+### Go SDK
+
+- Deprecate profiles package which got migrated to [github.com/moby/profiles](https://github.com/moby/profiles). [moby/moby#50513](https://github.com/moby/moby/pull/50513)
+
+### Deprecations
+
+- Deprecate special handling for quoted values for the `--tlscacert`, `--tlscert`, and `--tlskey` command-line flags. [docker/cli#6291](https://github.com/docker/cli/pull/6291)
+- Mark legacy links environment variables (`DOCKER_KEEP_DEPRECATED_LEGACY_LINKS_ENV_VARS`) as deprecated in v28.4 and set for removal in v30.0. [docker/cli#6309](https://github.com/docker/cli/pull/6309)
+- Go-SDK: Deprecate field `NetworkSettingsBase.Bridge`, struct `NetworkSettingsBase`, all the fields of `DefaultNetworkSettings`, and struct `DefaultNetworkSettings`. [moby/moby#50839](https://github.com/moby/moby/pull/50839)
+- Go-SDK: api/types: `build.CacheDiskUsage`,  `container.DiskUsage`, `images.DiskUsage` and `volumes.DiskUsage` are now deprecated and will be removed in the next major release. [moby/moby#50768](https://github.com/moby/moby/pull/50768)
+- Go-SDK: cli-plugins/manager: deprecate `ReexecEnvvar`. [docker/cli#6411](https://github.com/docker/cli/pull/6411)
+- Go-SDK: cli-plugins/manager: deprecate annotation aliases (`CommandAnnotationPlugin`, `CommandAnnotationPluginVendor`, `CommandAnnotationPluginVersion`, `CommandAnnotationPluginInvalid`, `CommandAnnotationPluginCommandPath`) in favor of their equivalent in `cli-plugins/manager/metadata`. [docker/cli#6298](https://github.com/docker/cli/pull/6298)
+- Go-SDK: cli-plugins/manager: deprecate metadata aliases (`NamePrefix`, `MetadataSubcommandName`, `HookSubcommandName`, `Metadata`, `ReexecEnvvar`) in favor of their equivalent in `cli-plugins/manager/metadata`. [docker/cli#6269](https://github.com/docker/cli/pull/6269)
+- Go-SDK: cli-plugins/manager: remove `Candidate` interface, which was only for internal use. [docker/cli#6269](https://github.com/docker/cli/pull/6269)
+- Go-SDK: cli-plugins/manager: remove `NewPluginError` function, which was only for internal use. [docker/cli#6269](https://github.com/docker/cli/pull/6269)
+- Go-SDK: cli-plugins/manager: remove deprecated `ResourceAttributesEnvvar` const. [docker/cli#6269](https://github.com/docker/cli/pull/6269)
+- Go-SDK: cli/command/builder: deprecate `NewBuilderCommand` and `NewBakeStubCommand`. These functions will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/builder: deprecate `NewPruneCommand`. [docker/cli#6343](https://github.com/docker/cli/pull/6343)
+- Go-SDK: cli/command/checkpoint: deprecate `NewCheckpointCommand`. This function will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/checkpoint: deprecate `NewFormat`, `FormatWrite`. [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/completion: deprecate `NoComplete`. [docker/cli#6405](https://github.com/docker/cli/pull/6405)
+- Go-SDK: cli/command/completion: remove deprecated `ValidArgsFn`. [docker/cli#6259](https://github.com/docker/cli/pull/6259)
+- Go-SDK: cli/command/config: deprecate `NewConfigCommand`. This function will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/config: deprecate `NewFormat`, `FormatWrite`, `InspectFormatWrite`. [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/config: deprecate `RunConfigCreate`,  `CreateOptions`, `RunConfigInspect`, `InspectOptions`, `RunConfigList`, `ListOptions`, `RunConfigRemove`, and `RemoveOptions`. [docker/cli#6369](https://github.com/docker/cli/pull/6369)
+- Go-SDK: cli/command/container: deprecate `NewBuildCommand`, `NewPullCommand`, `NewPushCommand`, `NewImagesCommand`, `NewImageCommand`, `NewHistoryCommand`, `NewImportCommand`, `NewLoadCommand`, `NewRemoveCommand`, `NewSaveCommand`, `NewTagCommand`, `NewPruneCommand`. These functions will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/container: deprecate `NewDiffFormat`, `DiffFormatWrite`. These functions were only used internally and will be removed in the next release. [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/container: deprecate `NewRunCommand`, `NewExecCommand`, `NewPsCommand`, `NewContainerCommand`, `NewAttachCommand`, `NewCommitCommand`, `NewCopyCommand`, `NewCreateCommand`, `NewDiffCommand`, `NewExportCommand`, `NewKillCommand`, `NewLogsCommand`, `NewPauseCommand`, `NewPortCommand`, `NewRenameCommand`, `NewRestartCommand`, `NewRmCommand`, `NewStartCommand`, `NewStatsCommand`, `NewStopCommand`, `NewTopCommand`, `NewUnpauseCommand`, `NewUpdateCommand`, `NewWaitCommand`, `NewPruneCommand`. These functions will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/context: deprecate `NewContextCommand`. This function will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/context: deprecate `RunCreate` and `CreateOptions`. [docker/cli#6403](https://github.com/docker/cli/pull/6403)
+- Go-SDK: cli/command/context: deprecate `RunExport` and `ExportOptions`. [docker/cli#6403](https://github.com/docker/cli/pull/6403)
+- Go-SDK: cli/command/context: deprecate `RunImport`. [docker/cli#6403](https://github.com/docker/cli/pull/6403)
+- Go-SDK: cli/command/context: deprecate `RunRemove` and `RemoveOptions`. [docker/cli#6403](https://github.com/docker/cli/pull/6403)
+- Go-SDK: cli/command/context: deprecate `RunUpdate` and `UpdateOptions`. [docker/cli#6403](https://github.com/docker/cli/pull/6403)
+- Go-SDK: cli/command/context: deprecate `RunUse`. [docker/cli#6403](https://github.com/docker/cli/pull/6403)
+- Go-SDK: cli/command/image: deprecate `AuthResolver` utility. [docker/cli#6357](https://github.com/docker/cli/pull/6357)
+- Go-SDK: cli/command/image: deprecate `NewHistoryFormat`, `HistoryWrite`. [docker/cli#6341](https://github.com/docker/cli/pull/6341), [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/manifest: deprecate `NewManifestCommand`. This functions will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/network: deprecate `NewFormat`, `FormatWrite`. [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/network: deprecate `NewNetworkCommand`. These functions will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/node: deprecate `NewFormat`, `FormatWrite`, `InspectFormatWrite`. [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/node: deprecate `NewNodeCommand`. This functions will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/plugin: deprecate `NewFormat`, `FormatWrite`. [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/plugin: deprecate `NewPluginCommand`. This function will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/registry: deprecate `NewLoginCommand`, `NewLogoutCommand`, `NewSearchCommand`. These functions will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/registry: deprecate `NewSearchFormat`, `SearchWrite`. [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/registry: deprecate `OauthLoginEscapeHatchEnvVar` const. [docker/cli#6413](https://github.com/docker/cli/pull/6413)
+- Go-SDK: cli/command/secret: deprecate `NewFormat`, `FormatWrite`, `InspectFormatWrite`. [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/secret: deprecate `NewSecretCommand`. This functions will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/service: deprecate `NewFormat`, `InspectFormatWrite`. [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/service: deprecate `NewServiceCommand`. This function will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/stack: deprecate `NewStackCommand`. This function will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/stack: deprecate `RunList`, `RunServices`. [docker/cli#6391](https://github.com/docker/cli/pull/6391)
+- Go-SDK: cli/command/swarm: deprecate `NewSwarmCommand`. This function will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/system: deprecate `NewVersionCommand`, `NewInfoCommand`, `NewSystemCommand`, `NewEventsCommand`, `NewInspectCommand`. These functions will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/task: deprecate `NewTaskFormat`, `FormatWrite`. [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/trust: deprecate `NewTrustCommand`. This function will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command/trust: deprecate `SignedTagInfo`, `SignerInfo`, `NewTrustTagFormat`, `NewSignerInfoFormat`, `TagWrite`, `SignerInfoWrite`. [docker/cli#6341](https://github.com/docker/cli/pull/6341)
+- Go-SDK: cli/command/volume: deprecate `NewVolumeCommand`, `NewPruneCommand`. These functions will be removed in the next release. [docker/cli#6312](https://github.com/docker/cli/pull/6312)
+- Go-SDK: cli/command: remove `AddTrustSigningFlags`,  `AddTrustVerificationFlags`, and `AddPlatformFlag` utilities, which were only used internally. [docker/cli#6311](https://github.com/docker/cli/pull/6311)
+- Go-SDK: cli/command: remove deprecated `ConfigureAuth` utility. [docker/cli#6257](https://github.com/docker/cli/pull/6257)
+- Go-SDK: cli/command: remove deprecated `CopyToFile` utility. [docker/cli#6257](https://github.com/docker/cli/pull/6257)
+- Go-SDK: cli/config/types: update deprecation message for `AuthConfig.Email` field. [docker/cli#6392](https://github.com/docker/cli/pull/6392)
+- Go-SDK: cli: deprecate `VisitAll`, `DisableFlagsInUseLine` utilities. These utilities were only used internally and will be removed in the next release. [docker/cli#6276](https://github.com/docker/cli/pull/6276)
+- Go-SDK: cli: remove `HasCompletionArg` utility. This utility was only used internally. [docker/cli#6276](https://github.com/docker/cli/pull/6276)
+- Go-SDK: deprecate `cli/command.RegistryAuthenticationPrivilegedFunc`. [docker/cli#6256](https://github.com/docker/cli/pull/6256)
+- Go-SDK: deprecate cli/command/stack/formatter. [docker/cli#6391](https://github.com/docker/cli/pull/6391)
+- Go-SDK: deprecate cli/command/stack/loader. [docker/cli#6391](https://github.com/docker/cli/pull/6391)
+- Go-SDK: deprecate cli/command/stack/options. [docker/cli#6391](https://github.com/docker/cli/pull/6391)
+- Go-SDK: deprecate cli/command/stack/swarm. [docker/cli#6391](https://github.com/docker/cli/pull/6391)
+- Go-SDK: opts: deprecate `NewNamedListOptsRef`, `NewNamedMapOpts`, `NamedListOpts`, `NamedMapOpts`, and `NamedOption`. These types and functions are no longer used and will be removed in the next release. [docker/cli#6292](https://github.com/docker/cli/pull/6292)
+- Go-SDK: opts: deprecate `ParseEnvFile` in favor of `kvfile.Parse`. [docker/cli#6381](https://github.com/docker/cli/pull/6381)
+- Go-SDK: opts: deprecate `QuotedString`. This utility is no longer used, and will be removed in the next release. [docker/cli#6275](https://github.com/docker/cli/pull/6275)
+- Go-SDK: opts: deprecate `ValidateHost` utility. This function is no longer used, and will be removed in the next release. [docker/cli#6280](https://github.com/docker/cli/pull/6280)
+- Go-SDK: pkg/jsonmessage: deprecate the `JSONMessage.From`, `JSONMessage.Time`, and `JSONMessage.TimeNano` fields, as they are no longer returned by the API for progress messages. Use the `events.Message` type instead to unmarshal the `/events` response. [moby/moby#50762](https://github.com/moby/moby/pull/50762)
+- Go-SDK: the cli/registry/client package is deprecated and will be removed in the next release. [docker/cli#6313](https://github.com/docker/cli/pull/6313)
+
+## 28.3.3
+
+{{< release-date date="2025-07-29" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 28.3.3 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A28.3.3)
+- [moby/moby, 28.3.3 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A28.3.3)
+
+### Security
+
+This release fixes an issue where, after a firewalld reload, published container ports could be accessed directly from the local network, even when they were intended to be accessible only via a loopback address. [CVE-2025-54388](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-54388) /  [GHSA-x4rx-4gw3-53p4](https://github.com/moby/moby/security/advisories/GHSA-x4rx-4gw3-53p4) / [moby/moby#50506](https://github.com/moby/moby/pull/50506).
+
+### Packaging updates
+
+- Update Buildx to [v0.26.1](https://github.com/docker/buildx/releases/tag/v0.26.1). [docker/docker-ce-packaging#1230](https://github.com/docker/docker-ce-packaging/pull/1230)
+- Update Compose to [v2.39.1](https://github.com/docker/compose/releases/tag/v2.39.1). [docker/docker-ce-packaging#1234](https://github.com/docker/docker-ce-packaging/pull/1234)
+- Update Docker Model CLI plugin to [v0.1.36](https://github.com/docker/model-cli/releases/tag/v0.1.36). [docker/docker-ce-packaging#1233](https://github.com/docker/docker-ce-packaging/pull/1233)
+
+## 28.3.2
+
+{{< release-date date="2025-07-09" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 28.3.2 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A28.3.2)
+- [moby/moby, 28.3.2 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A28.3.2)
+
+### Bug fixes and enhancements
+
+- Fix `--use-api-socket` not working correctly when targeting a remote daemon. [docker/cli#6157](https://github.com/docker/cli/pull/6157)
+- Fix stray "otel error" logs being printed if debug logging is enabled. [docker/cli#6160](https://github.com/docker/cli/pull/6160)
+- Quote SSH arguments when connecting to a remote daemon over an SSH connection to avoid unexpected expansion. [docker/cli#6147](https://github.com/docker/cli/pull/6147)
+- Warn when `DOCKER_AUTH_CONFIG` is set during `docker login` and `docker logout`. [docker/cli#6163](https://github.com/docker/cli/pull/6163)
+
+### Packaging updates
+
+- Update Compose to [v2.38.2](https://github.com/docker/compose/releases/tag/v2.38.2). [docker/docker-ce-packaging#1225](https://github.com/docker/docker-ce-packaging/pull/1225)
+- Update Docker Model CLI plugin to [v0.1.33](https://github.com/docker/model-cli/releases/tag/v0.1.33). [docker/docker-ce-packaging#1227](https://github.com/docker/docker-ce-packaging/pull/1227)
+- Update Go runtime to 1.24.5. [moby/moby#50354](https://github.com/moby/moby/pull/50354)
+
+## 28.3.1
+
+{{< release-date date="2025-07-02" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 28.3.1 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A28.3.1)
+- [moby/moby, 28.3.1 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A28.3.1)
+
+### Packaging updates
+
+- Update BuildKit to [v0.23.2](https://github.com/moby/buildkit/releases/tag/v0.23.2). [moby/moby#50309](https://github.com/moby/moby/pull/50309)
+- Update Compose to [v2.38.1](https://github.com/docker/compose/releases/tag/v2.38.1). [docker/docker-ce-packaging#1221](https://github.com/docker/docker-ce-packaging/pull/1221)
+- Update Model to v0.1.32 which adds the support for the new top-level `models:` key in Docker Compose. [docker/docker-ce-packaging#1222](https://github.com/docker/docker-ce-packaging/pull/1222)
+
+## 28.3.0
+
+{{< release-date date="2025-06-24" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 28.3.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A28.3.0)
+- [moby/moby, 28.3.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A28.3.0)
+
+### New
+
+- Add support for AMD GPUs in `docker run --gpus`. [moby/moby#49952](https://github.com/moby/moby/pull/49952)
+- Use `DOCKER_AUTH_CONFIG` as a credential store. [docker/cli#6008](https://github.com/docker/cli/pull/6008)
+
+### Bug fixes and enhancements
+
+- Ensure that the state of the container in the daemon database (used by [/containers/json](https://docs.docker.com/reference/api/engine/version/v1.49/#tag/Container/operation/ContainerList) API) is up to date when the container is stopped using the [/containers/{id}/stop](https://docs.docker.com/reference/api/engine/version/v1.49/#tag/Container/operation/ContainerStop) API (before response of API). [moby/moby#50136](https://github.com/moby/moby/pull/50136)
+- Fix `docker image inspect inspect` omitting empty fields. [moby/moby#50135](https://github.com/moby/moby/pull/50135)
+- Fix `docker images --tree` not marking images as in-use when the containerd image store is disabled. [docker/cli#6140](https://github.com/docker/cli/pull/6140)
+- Fix `docker pull/push` hang in non-interactive when authentication is required caused by prompting for login credentials. [docker/cli#6141](https://github.com/docker/cli/pull/6141)
+- Fix a potential resource leak when a node leaves a Swarm. [moby/moby#50115](https://github.com/moby/moby/pull/50115)
+- Fix a regression where a login prompt on `docker pull` would show Docker Hub-specific hints when logging in on other registries. [docker/cli#6135](https://github.com/docker/cli/pull/6135)
+- Fix an issue where all new tasks in the Swarm could get stuck in the PENDING state forever after scaling up a service with placement preferences. [moby/moby#50211](https://github.com/moby/moby/pull/50211)
+- Remove an undocumented, hidden, top-level `docker remove` command that was accidentally introduced in Docker 23.0. [docker/cli#6144](https://github.com/docker/cli/pull/6144)
+- Validate registry-mirrors configuration as part of `dockerd --validate` and improve error messages for invalid mirrors. [moby/moby#50240](https://github.com/moby/moby/pull/50240)
+- `dockerd-rootless-setuptool.sh`: Fix the script from silently returning with no error message when subuid/subgid system requirements are not satisfied. [moby/moby#50059](https://github.com/moby/moby/pull/50059)
+- containerd image store: Fix `docker push` not creating a tag on the remote repository. [moby/moby#50199](https://github.com/moby/moby/pull/50199)
+- containerd image store: Improve handling of errors returned by the token server during `docker pull/push`. [moby/moby#50176](https://github.com/moby/moby/pull/50176)
+
+### Packaging updates
+
+- Allow customizing containerd service name for OpenRC. [moby/moby#50156](https://github.com/moby/moby/pull/50156)
+- Update BuildKit to [v0.23.1](https://github.com/moby/buildkit/releases/tag/v0.23.1). [moby/moby#50243](https://github.com/moby/moby/pull/50243)
+- Update Buildx to [v0.25.0](https://github.com/docker/buildx/releases/tag/v0.25.0). [docker/docker-ce-packaging#1217](https://github.com/docker/docker-ce-packaging/pull/1217)
+- Update Compose to [v2.37.2](https://github.com/docker/compose/releases/tag/v2.37.2). [docker/docker-ce-packaging#1219](https://github.com/docker/docker-ce-packaging/pull/1219)
+- Update Docker Model CLI plugin to [v0.1.30](https://github.com/docker/model-cli/releases/tag/v0.1.30). [docker/docker-ce-packaging#1218](https://github.com/docker/docker-ce-packaging/pull/1218)
+- Update Go runtime to [1.24.4](https://go.dev/doc/devel/release#go1.24.4). [docker/docker-ce-packaging#1213](https://github.com/docker/docker-ce-packaging/pull/1213), [moby/moby#50153](https://github.com/moby/moby/pull/50153), [docker/cli#6124](https://github.com/docker/cli/pull/6124)
+
+### Networking
+
+- Revert Swarm related changes added in 28.2.x builds, due to a regression reported in https://github.com/moby/moby/issues/50129. [moby/moby#50169](https://github.com/moby/moby/pull/50169)
+  * Revert: Fix an issue where `docker network inspect --verbose` could sometimes crash the daemon (https://github.com/moby/moby/pull/49937). 
+  * Revert: Fix an issue where the load-balancer IP address for an overlay network would not be released in certain cases if the Swarm was lacking an ingress network (https://github.com/moby/moby/pull/49948). 
+  * Revert: Improve the reliability of NetworkDB in busy clusters and lossy networks (https://github.com/moby/moby/pull/49932). 
+  * Revert: Improvements to the reliability and convergence speed of NetworkDB (https://github.com/moby/moby/pull/49939). 
+- Fix an issue that could cause container startup to fail, or lead to failed UDP port mappings, when some container ports are mapped to `0.0.0.0` and others are mapped to specific host addresses. [moby/moby#50054](https://github.com/moby/moby/pull/50054)
+- The `network inspect` response for an overlay network now reports that `EnableIPv4` is true. [moby/moby#50147](https://github.com/moby/moby/pull/50147)
+- Windows: Improve daemon startup time in cases where the host has networks of type `"Mirrored"`. [moby/moby#50155](https://github.com/moby/moby/pull/50155)
+- Windows: Make sure `docker system prune` and `docker network prune` only remove networks created by Docker. [moby/moby#50154](https://github.com/moby/moby/pull/50154)
+
+### API
+
+- Update API version to 1.51. [moby/moby#50145](https://github.com/moby/moby/pull/50145)
+- `GET /images/json` now sets the value of the `Containers` field for all images to the count of containers using the image. [moby/moby#50146](https://github.com/moby/moby/pull/50146)
+
+### Deprecations
+
+- Empty/nil image config fields in the `GET /images/{name}/json` response are now deprecated and will be removed in v29.0. [docker/cli#6129](https://github.com/docker/cli/pull/6129)
+- api/types/container: deprecate `ExecOptions.Detach`. This field is not used, and will be removed in a future release. [moby/moby#50219](https://github.com/moby/moby/pull/50219)
+- pkg/idtools: deprecate `IdentityMapping` and `Identity.Chown`. [moby/moby#50210](https://github.com/moby/moby/pull/50210)
+
+## 28.2.2
+
+{{< release-date date="2025-05-30" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 28.2.2 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A28.2.2)
+- [moby/moby, 28.2.2 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A28.2.2)
+
+### Bug fixes and enhancements
+
+- containerd image store: Fix a regression causing `docker build --push` to fail. This reverts [the fix](https://github.com/moby/moby/pull/49702) for `docker build` not persisting overridden images as dangling. [moby/moby#50105](https://github.com/moby/moby/pull/50105)
+
+### Networking
+
+- When creating the iptables `DOCKER-USER` chain, do not add an explicit `RETURN` rule, allowing users to append as well as insert their own rules. Existing rules are not removed on upgrade, but it won't be replaced after a reboot. [moby/moby#50098](https://github.com/moby/moby/pull/50098)
+
+## 28.2.1
+
+{{< release-date date="2025-05-29" >}}
+
+### Packaging updates
+
+- Fix packaging regression in [v28.2.0](https://github.com/moby/moby/releases/tag/v28.2.0) which broke creating the `docker` group/user on fresh installations. [docker-ce-packaging#1209](https://github.com/docker/docker-ce-packaging/issues/1209)
+
+## 28.2.0
+
+{{< release-date date="2025-05-28" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 28.2.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A28.2.0)
+- [moby/moby, 28.2.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A28.2.0)
+
+> [!NOTE]
+> RHEL packages are currently not available and will be released later.
+
+### New
+
+- Add `{{.Platform}}` as formatting option for `docker ps` to show the platform of the image the container is running. [docker/cli#6042](https://github.com/docker/cli/pull/6042)
+- Add support for relative parent paths (`../`) on bind mount sources when using `docker run/create` with `-v/--volume` or `--mount type=bind` options. [docker/cli#4966](https://github.com/docker/cli/pull/4966)
+- CDI is now enabled by default. [moby/moby#49963](https://github.com/moby/moby/pull/49963)
+- Show discovered CDI devices in `docker info`. [docker/cli#6078](https://github.com/docker/cli/pull/6078)
+- `docker image rm`: add `--platform` option to remove a variant from multi-platform images. [docker/cli#6109](https://github.com/docker/cli/pull/6109)
+- containerd image store: Initial BuildKit support for building Windows container images on Windows (requires an opt-in with `DOCKER_BUILDKIT=1`). [moby/moby#49740](https://github.com/moby/moby/pull/49740)
+
+### Bug fixes and enhancements
+
+- Add a new log option for fluentd log driver (`fluentd-write-timeout`), which enables specifying write timeouts for fluentd connections. [moby/moby#49911](https://github.com/moby/moby/pull/49911)
+- Add support for `DOCKER_AUTH_CONFIG` for the experimental `--use-api-socket` option. [docker/cli#6019](https://github.com/docker/cli/pull/6019)
+- Fix `docker exec` waiting for 10 seconds if a non-existing user or group was specified. [moby/moby#49868](https://github.com/moby/moby/pull/49868)
+- Fix `docker swarm init` ignoring `cacert` option of `--external-ca`. [docker/cli#5995](https://github.com/docker/cli/pull/5995)
+- Fix an issue where the CLI would not correctly save the configuration file (`~/.docker/config.json`) if it was a relative symbolic link. [docker/cli#5282](https://github.com/docker/cli/pull/5282)
+- Fix containers with `--restart always` policy using CDI devices failing to start on daemon restart. [moby/moby#49990](https://github.com/moby/moby/pull/49990)
+- Fix shell-completion to only complete some flags once, even though they can be set multiple times. [docker/cli#6030](https://github.com/docker/cli/pull/6030)
+- Fix the `plugin does not implement PluginAddr interface` error for Swarm CSI drivers. [moby/moby#49961](https://github.com/moby/moby/pull/49961)
+- Improve `docker login` error messages for invalid options. [docker/cli#6036](https://github.com/docker/cli/pull/6036)
+- Make sure the terminal state is restored if the CLI is forcefully terminated. [docker/cli#6058](https://github.com/docker/cli/pull/6058)
+- Update the default seccomp profile to match the libseccomp v2.6.0. The new syscalls are: `listmount`, `statmount`, `lsm_get_self_attr`, `lsm_list_modules`, `lsm_set_self_attr`, `mseal`, `uretprobe`, `riscv_hwprobe`, `getxattrat`, `listxattrat`, `removexattrat`, and `setxattrat`. This prevents containers from receiving EPERM errors when using them. [moby/moby#50077](https://github.com/moby/moby/pull/50077)
+- `docker inspect`: add shell completion, improve flag-description for `--type` and improve validation. [docker/cli#6052](https://github.com/docker/cli/pull/6052)
+- containerd image store: Enable BuildKit garbage collector by default. [moby/moby#49899](https://github.com/moby/moby/pull/49899)
+- containerd image store: Fix `docker build` not persisting overridden images as dangling. [moby/moby#49702](https://github.com/moby/moby/pull/49702)
+- containerd image store: Fix `docker system df` reporting a negative reclaimable space amount. [moby/moby#49707](https://github.com/moby/moby/pull/49707)
+- containerd image store: Fix duplicate `PUT` requests when pushing a multi-platform image. [moby/moby#49949](https://github.com/moby/moby/pull/49949)
+
+### Packaging updates
+
+- Drop Ubuntu 20.04 "Focal" packages as it reached end of life. [docker/docker-ce-packaging#1200](https://github.com/docker/docker-ce-packaging/pull/1200)
+- Fix install location for RPM-based `docker-ce` man-pages. [docker/docker-ce-packaging#1203](https://github.com/docker/docker-ce-packaging/pull/1203)
+- Update BuildKit to [v0.22.0](https://github.com/moby/buildkit/releases/tag/v0.22.0). [moby/moby#50046](https://github.com/moby/moby/pull/50046)
+- Update Buildx to [v0.24.0](https://github.com/docker/buildx/releases/tag/v0.24.0). [docker/docker-ce-packaging#1205](https://github.com/docker/docker-ce-packaging/pull/1205)
+- Update Compose to [v2.36.2](https://github.com/docker/compose/releases/tag/v2.36.2). [docker/docker-ce-packaging#1208](https://github.com/docker/docker-ce-packaging/pull/1208)
+- Update Go runtime to [1.24.3](https://go.dev/doc/devel/release#go1.24.3). [docker/docker-ce-packaging#1192](https://github.com/docker/docker-ce-packaging/pull/1192), [docker/cli#6060](https://github.com/docker/cli/pull/6060), [moby/moby#49174](https://github.com/moby/moby/pull/49174)
+
+### Networking
+
+- Add bridge network option `"com.docker.network.bridge.trusted_host_interfaces"`, accepting a colon-separated list of interface names. These interfaces have direct access to published ports on container IP addresses. [moby/moby#49832](https://github.com/moby/moby/pull/49832)
+- Add daemon option `"allow-direct-routing"` to disable filtering of packets from outside the host addressed directly to containers. [moby/moby#49832](https://github.com/moby/moby/pull/49832)
+- Do not display network options `com.docker.network.enable_ipv4` or `com.docker.network.enable_ipv6` in inspect output if they have been overridden by `EnableIPv4` or `EnableIPv6` in the network create request. [moby/moby#49866](https://github.com/moby/moby/pull/49866)
+- Fix an issue that could cause network deletion to fail after a daemon restart, with error "has active endpoints" listing empty endpoint names. [moby/moby#49901](https://github.com/moby/moby/pull/49901)
+- Fix an issue where `docker network inspect --verbose` could sometimes crash the daemon. [moby/moby#49937](https://github.com/moby/moby/pull/49937)
+- Fix an issue where the load-balancer IP address for an overlay network would not be released in certain cases if the Swarm was lacking an ingress network. [moby/moby#49948](https://github.com/moby/moby/pull/49948)
+- Improve the reliability of NetworkDB in busy clusters and lossy networks. [moby/moby#49932](https://github.com/moby/moby/pull/49932)
+- Improvements to the reliability and convergence speed of NetworkDB. [moby/moby#49939](https://github.com/moby/moby/pull/49939)
+
+### API
+
+- `DELETE /images/{name}` now supports a `platforms` query parameter. It accepts an array of JSON-encoded OCI Platform objects, allowing for selecting a specific platforms to delete content for. [moby/moby#49982](https://github.com/moby/moby/pull/49982)
+- `GET /info` now includes a `DiscoveredDevices` field. This is an array of `DeviceInfo` objects, each providing details about a device discovered by a device driver. [moby/moby#49980](https://github.com/moby/moby/pull/49980)
+
+### Go SDK
+
+- `api/types/container`: add `ContainerState` and constants for container state. [moby/moby#49965](https://github.com/moby/moby/pull/49965)
+- `api/types/container`: change `Summary.State` to a `ContainerState`. [moby/moby#49991](https://github.com/moby/moby/pull/49991)
+- `api/types/container`: define `HealthStatus` type for health-status constants. [moby/moby#49876](https://github.com/moby/moby/pull/49876)
+- `api/types`: deprecate `BuildResult`, `ImageBuildOptions`, `ImageBuildOutput`, `ImageBuildResponse`, `BuilderVersion`, `BuilderV1`, and `BuilderBuildKi` which were moved to `api/types/build`. [moby/moby#50025](https://github.com/moby/moby/pull/50025)
+
+### Deprecations
+
+- API: Deprecated: `GET /images/{name}/json` no longer returns the following fields: `Config`, `Hostname`, `Domainname`, `AttachStdin`, `AttachStdout`, `AttachStderr`, `Tty`, `OpenStdin`, `StdinOnce`, `Image`, `NetworkDisabled` (already omitted unless set), `MacAddress` (already omitted unless set), `StopTimeout` (already omitted unless set). These additional fields were included in the response due to an implementation detail but not part of the image's Configuration, were marked deprecated in API v1.46, and are now omitted. [moby/moby#48457](https://github.com/moby/moby/pull/48457)
+- Go-SDK: Deprecate builder/remotecontext.Rel(). This function was needed on older versions of Go, but can now be replaced by `filepath.Rel()`. [moby/moby#49843](https://github.com/moby/moby/pull/49843)
+- Go-SDK: api/types: deprecate `BuildCachePruneOptions` in favor of `api/types/builder.CachePruneOptions`. [moby/moby#50015](https://github.com/moby/moby/pull/50015)
+- Go-SDK: api/types: deprecate `BuildCachePruneReport` in favor of `api/types/builder.CachePruneReport`. [moby/moby#50015](https://github.com/moby/moby/pull/50015)
+- Go-SDK: api/types: deprecate `NodeListOptions`, `NodeRemoveOptions`, `ServiceCreateOptions`, `ServiceUpdateOptions`, `RegistryAuthFromSpec`, `RegistryAuthFromPreviousSpec`, `ServiceListOptions`, `ServiceInspectOptions`, and `SwarmUnlockKeyResponse` which were moved to `api/types/swarm`. [moby/moby#50027](https://github.com/moby/moby/pull/50027)
+- Go-SDK: api/types: deprecate `SecretCreateResponse`, `SecretListOptions`, `ConfigCreateResponse`, `ConfigListOptions` which were moved to api/types/swarm. [moby/moby#50024](https://github.com/moby/moby/pull/50024)
+- Go-SDK: client: deprecate `IsErrNotFound`. [moby/moby#50012](https://github.com/moby/moby/pull/50012)
+- Go-SDK: container: deprecate `IsValidHealthString` in favor of `api/types/container.ValidateHealthStatus`. [moby/moby#49893](https://github.com/moby/moby/pull/49893)
+- Go-SDK: container: deprecate `StateStatus`, `WaitCondition`, and the related  `WaitConditionNotRunning`, `WaitConditionNextExit`, and `WaitConditionRemoved` consts in favor of their equivalents in `api/types/container`. [moby/moby#49874](https://github.com/moby/moby/pull/49874)
+- Go-SDK: opts: deprecate `ListOpts.GetAll` in favor of `ListOpts.GetSlice`. [docker/cli#6032](https://github.com/docker/cli/pull/6032)
+- Remove deprecated `IsAutomated` formatting placeholder from `docker search`. [docker/cli#6091](https://github.com/docker/cli/pull/6091)
+- Remove fallback for pulling images from non-OCI-compliant `docker.pkg.github.com` registry. [moby/moby#50094](https://github.com/moby/moby/pull/50094)
+- Remove support for pulling legacy v2, schema 1 images and remove `DOCKER_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE` environment-variable. [moby/moby#50036](https://github.com/moby/moby/pull/50036), [moby/moby#42300](https://github.com/moby/moby/pull/42300)
+- The `BridgeNfIptables` and `BridgeNfIp6tables` fields in the `GET /info` response were deprecated in API v1.48, and are now omitted in API v1.50. [moby/moby#49904](https://github.com/moby/moby/pull/49904)
+- errdefs: Deprecate `errdefs.FromStatusCode`. Use containerd's `errhttp.ToNative` instead. [moby/moby#50030](https://github.com/moby/moby/pull/50030)
 
 ## 28.1.1
 
diff --git a/content/manuals/engine/release-notes/29.md b/content/manuals/engine/release-notes/29.md
new file mode 100644
index 000000000000..f661e171ced1
--- /dev/null
+++ b/content/manuals/engine/release-notes/29.md
@@ -0,0 +1,1192 @@
+---
+title: Docker Engine version 29 release notes
+linkTitle: Engine v29
+description: Learn about the new features, bug fixes, and breaking changes for Docker Engine
+keywords: docker, docker engine, ce, whats new, release notes
+toc_min: 1
+toc_max: 2
+tags:
+  - Release notes
+aliases:
+  - /engine/release-notes/
+  - /engine/release-notes/latest/
+  - /release-notes/docker-ce/
+  - /release-notes/docker-engine/
+  - /engine/release-notes/29.0/
+---
+
+This page describes the latest changes, additions, known issues, and fixes for Docker Engine version 29.
+
+For more information about:
+
+- Deprecated and removed features, see [Deprecated Engine Features](../deprecated.md).
+- Changes to the Engine API, see [Engine API version history](/reference/api/engine/version-history/).
+
+## 29.7.2
+
+{{< release-date date="2026-08-05" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.7.2 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.7.2)
+- [moby/moby, 29.7.2 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.7.2)
+
+### Bug fixes and enhancements
+
+- Fix `docker service create` and `docker service update` panicking when the same environment variable is passed more than once. [docker/cli#7145](https://github.com/docker/cli/pull/7145)
+- Fix a regression introduced in Docker Engine 29.7.0 that caused image pulls to reject images containing absolute hardlink targets, as produced by some image builders. [moby/moby#53305](https://github.com/moby/moby/pull/53305)
+- Fix a regression introduced in Docker Engine 29.7.0 that could cause image pulls and `docker cp` to fail on older Linux kernels when applying file permissions, including for device nodes. [moby/moby#53305](https://github.com/moby/moby/pull/53305)
+
+### Packaging updates
+
+- Update BuildKit to [v0.32.2](https://github.com/moby/buildkit/releases/tag/v0.32.2). [moby/moby#53300](https://github.com/moby/moby/pull/53300)
+
+### Networking
+
+- Improve compatibility with more nftables releases by terminating base-chain policies with a semicolon. [moby/moby#53303](https://github.com/moby/moby/pull/53303)
+
+## 29.7.1
+
+{{< release-date date="2026-07-31" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.7.1 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.7.1)
+- [moby/moby, 29.7.1 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.7.1)
+
+### Bug fixes and enhancements
+
+- Fix a regression that prevented pulling images whose layers contain directories without explicit parent directory entries. [moby/moby#53260](https://github.com/moby/moby/pull/53260)
+- Fix a regression where the `CopyToContainer` rejects container paths that traverse absolute symlinks, such as `/var/run` -> `/run`. [moby/moby#53261](https://github.com/moby/moby/pull/53261)
+
+## 29.7.0
+
+{{< release-date date="2026-07-30" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.7.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.7.0)
+- [moby/moby, 29.7.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.7.0)
+
+### New
+
+- Add an experimental `embedded-containerd` feature that runs containerd inside the daemon process instead of as a separate managed process. [moby/moby#52898](https://github.com/moby/moby/pull/52898)
+- Mount type `image` is no longer experimental. [moby/moby#52998](https://github.com/moby/moby/pull/52998)
+- Add the `default-stop-timeout` daemon option to configure the stop timeout assigned to containers without an explicit timeout. [moby/moby#53146](https://github.com/moby/moby/pull/53146)
+
+### Security
+
+This release includes a fix for a security vulnerability affecting Docker Engine and related components.
+
+- Update github.com/moby/go-archive to v0.3.0 to fix [CVE-2026-17106](https://www.cve.org/CVERecord?id=CVE-2026-17106) / [GHSA-hfg8-hc9c-6c3h](https://github.com/moby/go-archive/security/advisories/GHSA-hfg8-hc9c-6c3h). [moby/moby#53247](https://github.com/moby/moby/pull/53247), [docker/cli#7139](https://github.com/docker/cli/pull/7139)
+
+### Networking
+
+- Fix a daemon panic when cleanup of a container's network interface fails while the container is being disconnected from a network. [moby/moby#53237](https://github.com/moby/moby/pull/53237)
+- Fix a daemon panic when removing swarm ingress ports after failing to bind an ingress proxy listener. [moby/moby#53022](https://github.com/moby/moby/pull/53022)
+
+### Rootless
+
+- Keep the cgroup mount for containers with `--net=host`. [moby/moby#52318](https://github.com/moby/moby/pull/52318)
+
+### Bug fixes and enhancements
+
+
+- Add shell completion for `--filter` names and known values to `docker service ls`, `docker service ps`, and `docker node ps`. [docker/cli#7124](https://github.com/docker/cli/pull/7124)
+- containerd image store: Fix daemon-wide concurrent download and upload limits for pulls and pushes not being honored. [moby/moby#53081](https://github.com/moby/moby/pull/53081)
+  - To preserve the previous unlimited startup behavior, configure "max-concurrent-downloads" and "max-concurrent-uploads" to 0
+- Fix `docker cp -a` using the wrong file owner when copying files into containers with user namespace remapping enabled. [moby/moby#53084](https://github.com/moby/moby/pull/53084)
+- Fix `docker cp` from a Windows container silently returning a file instead of an error when the source path ends with a separator but is not a directory. [moby/moby#53123](https://github.com/moby/moby/pull/53123)
+- Fix `docker stats` reporting all zeros for running Windows containers when using the containerd runtime. [moby/moby#53101](https://github.com/moby/moby/pull/53101)
+- Fix `docker stats` reporting empty network stats for running Windows containers when using the containerd runtime. [moby/moby#53219](https://github.com/moby/moby/pull/53219)
+- Fix a typo in the `docker create --pull` flag description. [docker/cli#7103](https://github.com/docker/cli/pull/7103)
+- Fix Swarm service updates failing due to "file exists" errors when a VIP IP alias already exists on the LB endpoint interface. [moby/moby#51657](https://github.com/moby/moby/pull/51657)
+- Fix Swarm tasks being rejected when their image could not be pulled from the registry but was already present on the node. [moby/moby#53212](https://github.com/moby/moby/pull/53212)
+- Improve the error returned when a container hostname exceeds Linux's 64-byte limit. [moby/moby#53121](https://github.com/moby/moby/pull/53121)
+- Prevent live-restored volumes from retaining active mount references when containers exit during daemon startup. [moby/moby#53115](https://github.com/moby/moby/pull/53115)
+- Suppress the “No such container” error when `docker rm --force` succeeds for a nonexistent container. [docker/cli#7110](https://github.com/docker/cli/pull/7110)
+
+### Packaging updates
+
+- Update Go runtime to [1.26.5](https://go.dev/doc/devel/release#go1.26.5). [docker/cli#7087](https://github.com/docker/cli/pull/7087)
+- Update BuildKit to [v0.32.0](https://github.com/moby/buildkit/releases/tag/v0.32.0). [moby/moby#53234](https://github.com/moby/moby/pull/53234)
+- Update containerd (static binaries) to [v2.3.3](https://github.com/containerd/containerd/releases/tag/v2.3.3). [moby/moby#53050](https://github.com/moby/moby/pull/53050)
+- Update runc (in static binaries) to [v1.4.3](https://github.com/opencontainers/runc/releases/tag/v1.4.3). [moby/moby#50960](https://github.com/moby/moby/pull/50960)
+
+## 29.6.2
+
+{{< release-date date="2026-07-16" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.6.2 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.6.2)
+- [moby/moby, 29.6.2 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.6.2)
+
+### Security
+
+This release includes fixes for multiple security vulnerabilities affecting Docker Engine.
+
+- **CVE-2026-15793**: Git source checkout from a bundle file could lead to command injection. [GHSA-hw3h-2gp9-cxpv](https://github.com/moby/buildkit/security/advisories/GHSA-hw3h-2gp9-cxpv)
+- **CVE-2026-15792**: Incorrect parameters sent from a frontend could cause a panic. [GHSA-qx3x-mv6r-52p6](https://github.com/moby/buildkit/security/advisories/GHSA-qx3x-mv6r-52p6)
+- **CVE-2026-15791**: An LLB file operation could be tricked into removing the contents of the `/tmp` directory. [GHSA-32pv-7hq5-qhwq](https://github.com/moby/buildkit/security/advisories/GHSA-32pv-7hq5-qhwq)
+- **CVE-2026-15789**: A malicious client could bypass destination directory validation when uploading local sources. [GHSA-g2h8-426c-7976](https://github.com/moby/buildkit/security/advisories/GHSA-g2h8-426c-7976)
+- **CVE-2026-15788**: A WCOW cache mount source selector could resolve NTFS junctions outside of the cache root. [GHSA-388v-wmr2-g2v2](https://github.com/moby/buildkit/security/advisories/GHSA-388v-wmr2-g2v2)
+
+### Packaging updates
+
+- Update containerd (static binaries) to [v2.2.6](https://github.com/containerd/containerd/releases/tag/v2.2.6). [moby/moby#53051](https://github.com/moby/moby/pull/53051)
+- Update Go runtime to [1.26.5](https://go.dev/doc/devel/release#go1.26.5). [moby/moby#53027](https://github.com/moby/moby/pull/53027)
+
+### Rootless
+
+- Update RootlessKit to [v3.0.2](https://github.com/rootless-containers/rootlesskit/releases/tag/v3.0.2). [moby/moby#53054](https://github.com/moby/moby/pull/53054)
+
+## 29.6.1
+
+{{< release-date date="2026-06-26" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.6.1 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.6.1)
+- [moby/moby, 29.6.1 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.6.1)
+
+### Security
+
+This release includes fixes for multiple security vulnerabilities affecting Docker Engine.
+
+- A malicious image could supply a malicious `/etc/passwd` or `/etc/group`-style file causing excessive memory consumption, potentially resulting in process termination due to Out Of Memory (OOM) conditions. [GHSA-mjcv-p78q-w5fw](https://github.com/moby/sys/security/advisories/GHSA-mjcv-p78q-w5fw), [GHSA-jpcc-p29g-p8mq](https://github.com/containerd/containerd/security/advisories/GHSA-jpcc-p29g-p8mq), [GHSA-72x6-4j93-7w86](https://github.com/moby/buildkit/security/advisories/GHSA-72x6-4j93-7w86)
+- A custom frontend could send a crafted build request that disabled Seccomp and AppArmor protections for the build container, even if the user did not explicitly allow the security.insecure entitlement. Other security measures, like Linux capabilities were still applied to these containers. [GHSA-7236-3392-c5c6](https://github.com/moby/buildkit/security/advisories/GHSA-7236-3392-c5c6)
+
+### Bug fixes and enhancements
+
+- Update containerd (static binaries) to [v2.2.5](https://github.com/containerd/containerd/releases/tag/v2.2.5). [moby/moby#52950](https://github.com/moby/moby/pull/52950)
+
+### Packaging updates
+
+- Update BuildKit to [v0.31.1](https://github.com/moby/buildkit/releases/tag/v0.31.1). [moby/moby#52954](https://github.com/moby/moby/pull/52954)
+
+## 29.6.0
+
+{{< release-date date="2026-06-18" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.6.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.6.0)
+- [moby/moby, 29.6.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.6.0)
+
+### New
+
+- `POST /containers/{id}/update` now supports per-device blkio resource settingss. [moby/moby#52651](https://github.com/moby/moby/pull/52651)
+- Add `GET /images/{name}/attestations` endpoint to retrieve in-toto attestation statements (such as SLSA provenance and SPDX SBOM) attached to an image. Supports optional platform selection, predicate type filtering, and a statement query parameter for verbatim statement bodies.
+
+### Bug fixes and enhancements
+
+- `docker image push` now respects `NO_COLOR`. [docker/cli#6957](https://github.com/docker/cli/pull/6957)
+- containerd image store: Fix `docker system prune` to include unpacked image data when reporting reclaimed space. [moby/moby#52905](https://github.com/moby/moby/pull/52905)
+- Fix `docker system df` image size reporting to count only snapshots directly used by images. [moby/moby#52901](https://github.com/moby/moby/pull/52901)
+- Fix a bug where registry authentication failures during worker image pulls were reported as a misleading “No such image” error. [moby/moby#52698](https://github.com/moby/moby/pull/52698)
+- Fix default BuildKit GC policy to prune reproducible cache types as intended. [moby/moby#52814](https://github.com/moby/moby/pull/52814)
+- Fix explicit file modes being filtered by the daemon umask, including `COPY --chmod` permissions. [moby/moby#52892](https://github.com/moby/moby/pull/52892)
+- Fix image selection with the containerd image store on amd64 hosts when images provide amd64 variant-specific manifests. [moby/moby#52773](https://github.com/moby/moby/pull/52773)
+- The `--password` flag on `docker login` now accepts `-` to pass the password through STDIN as alternative to `--password-stdin`. [docker/cli#7029](https://github.com/docker/cli/pull/7029)
+
+### Packaging updates
+
+- Update runc (in static binaries) to [v1.3.6](https://github.com/opencontainers/runc/releases/tag/v1.3.6). [moby/moby#52883](https://github.com/moby/moby/pull/52883)
+- Update BuildKit to [v0.31.0](https://github.com/moby/buildkit/releases/tag/v0.31.0). [moby/moby#52904](https://github.com/moby/moby/pull/52904)
+
+### Networking
+
+- Allow the nftables firewall mode to be used with a daemon that is linked against libnftables when the `nft` command is not installed on the system. [moby/moby#52820](https://github.com/moby/moby/pull/52820)
+- Don't publish container ports on host ports listed in `net.ipv4.ip_local_reserved_ports` when dynamically allocating ports. [moby/moby#52818](https://github.com/moby/moby/pull/52818)
+- Fix a race condition in overlay network bulk sync that caused ~30s DNS resolution delays on newly joined swarm nodes. [moby/moby#52862](https://github.com/moby/moby/pull/52862)
+- Mitigate a crash in libnftables when using nftables as the firewall backend by changing the default build option to execute the `nft` command instead. Users building dockerd from source can opt into linking against libnftables by building with the `libnftables` build tag. [moby/moby#52886](https://github.com/moby/moby/pull/52886)
+
+### Rootless
+
+- Silence the spurious warning "IPv4 forwarding is disabled". [moby/moby#52742](https://github.com/moby/moby/pull/52742)
+
+### Deprecations
+
+- The Engine now returns a deprecation warning when a container connected to the default bridge is created with links specified. [moby/moby#47427](https://github.com/moby/moby/pull/47427)
+
+## 29.5.3
+
+{{< release-date date="2026-06-03" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.5.3 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.5.3)
+- [moby/moby, 29.5.3 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.5.3)
+
+### Bug fixes and enhancements
+
+- Reduce `docker system df` errors when images are pruned at the same time with the containerd image store. [moby/moby#52672](https://github.com/moby/moby/pull/52672)
+
+### Packaging updates
+
+- Update containerd (static binaries only) to [v2.2.4](https://github.com/containerd/containerd/releases/tag/v2.2.4). [moby/moby#52683](https://github.com/moby/moby/pull/52683)
+- Update Go runtime to [1.26.4](https://go.dev/doc/devel/release#go1.26.4). [moby/moby#52753](https://github.com/moby/moby/pull/52753), [docker/cli#7025](https://github.com/docker/cli/pull/7025)
+
+### Rootless
+
+- Fix AWS IMDS access with `gvisor-tap-vsock` and UDP port forwarding for non-loopback clients. [moby/moby#52710](https://github.com/moby/moby/pull/52710)
+- Fix installation of plugins that require host networking. [moby/moby#52735](https://github.com/moby/moby/pull/52735)
+- Update RootlessKit to [v3.0.1](https://github.com/rootless-containers/rootlesskit/releases/tag/v3.0.1). [moby/moby#52710](https://github.com/moby/moby/pull/52710)
+
+## 29.5.2
+
+{{< release-date date="2026-05-20" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.5.2 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.5.2)
+- [moby/moby, 29.5.2 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.5.2)
+
+### Bug fixes and enhancements
+
+- Fix a regression introduced in 29.5.1 where `docker cp` failed with "mkdirat: file exists" when a container had a bind mount whose target traversed an in-container symlink (e.g. `/var/run -> /run`). [moby/moby#52655](https://github.com/moby/moby/pull/52655)
+
+## 29.5.1
+
+{{< release-date date="2026-05-18" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.5.1 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.5.1)
+- [moby/moby, 29.5.1 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.5.1)
+
+### Security
+
+This release includes fixes for multiple security vulnerabilities affecting Docker Engine.
+
+- **CVE-2026-41567** Fix a vulnerability in `docker cp` where archive decompression binaries (e.g. `xz`, `unpigz`) were resolved via `PATH` inside the container filesystem while running as host root, allowing a malicious container to execute arbitrary binaries with host root privileges.  
+  [GHSA-x86f-5xw2-fm2r](https://github.com/moby/moby/security/advisories/GHSA-x86f-5xw2-fm2r)
+
+- **CVE-2026-41568** Fix a TOCTOU vulnerability in `docker cp` that allowed a container process to create files or directories at arbitrary locations on the host filesystem.  
+  [GHSA-vp62-88p7-qqf5](https://github.com/moby/moby/security/advisories/GHSA-vp62-88p7-qqf5)
+
+- **CVE-2026-42306** Fix a TOCTOU vulnerability in `docker cp` that allowed a container process to redirect a bind mount to an arbitrary location on the host filesystem.  
+  [GHSA-rg2x-37c3-w2rh](https://github.com/moby/moby/security/advisories/GHSA-rg2x-37c3-w2rh)
+
+### Networking
+
+- Fix UDP conntrack entries not being deleted when not bound to a specific IP address. [moby/moby#52640](https://github.com/moby/moby/pull/52640)
+
+## 29.5.0
+
+{{< release-date date="2026-05-14" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.5.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.5.0)
+- [moby/moby, 29.5.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.5.0)
+
+> [!NOTE]
+> Rootless: `gvisor-tap-vsock` is now the new default rootless network driver and should be preferred over `slirp4netns` which is no longer installed via Docker packaging.
+
+### New
+
+- Rootless: Add new default  `gvisor-tap-vsock` network driver. [moby/moby#52319](https://github.com/moby/moby/pull/52319)
+- Enable private time namespace for containers by default on supported kernels. [moby/moby#52326](https://github.com/moby/moby/pull/52326)
+- The `local` logging driver now has support for custom attributes, adding support for the `label`, `label-regex`, `env`, `env-regex`, and `tag` log options. [moby/moby#52348](https://github.com/moby/moby/pull/52348)
+- Windows: The daemon now supports listening on a Unix socket (`-H unix://...`), with optional group-based access control via `--group`. [moby/moby#52365](https://github.com/moby/moby/pull/52365)
+
+### Security
+
+- CVE-2026-32288: Fix a denial of service where pulling a maliciously crafted image could cause the daemon to allocate unbounded memory when processing sparse tar archives. [GHSA-x4jj-h2v8-hqqv](https://github.com/advisories/GHSA-x4jj-h2v8-hqqv). [moby/moby#52478](https://github.com/moby/moby/pull/52478)
+
+### Bug fixes and enhancements
+
+- `docker ps --format` now supports a `.HealthStatus` placeholder to print container health state (`starting`, `healthy`, `unhealthy`) as a dedicated field. [docker/cli#6913](https://github.com/docker/cli/pull/6913)
+- Add "time-namespaces" feature flag to disable time-namespaces. [moby/moby#52577](https://github.com/moby/moby/pull/52577)
+- containerd integration: Fix auth token requests ignoring per-host TLS settings (custom CAs, insecure-registries). [moby/moby#52600](https://github.com/moby/moby/pull/52600)
+- Daemon reload events now signify that the daemon reload has fully completed. [moby/moby#52589](https://github.com/moby/moby/pull/52589)
+- Expose diagnostic data about userland proxy in `docker info`. [moby/moby#52321](https://github.com/moby/moby/pull/52321)
+- Fix `docker image ls --filter reference=...` (`GET /images/json`) to also match fully qualified canonical image names (e.g. `docker.io/library/alpine`), not only the familiar short form. [moby/moby#52333](https://github.com/moby/moby/pull/52333)
+- Fix a bug where leaving an autolock-enabled swarm could leave orphaned state, causing subsequent swarm init to fail with "Swarm is encrypted and needs to be unlocked". [moby/moby#52479](https://github.com/moby/moby/pull/52479)
+- Fix an issue where logging errors appeared as empty strings in the daemon log instead of the message that failed to write. [moby/moby#52442](https://github.com/moby/moby/pull/52442)
+- Fix incorrect SHARED SIZE and UNIQUE SIZE reporting in `docker system df -v` by including shared content blobs in size calculation. [moby/moby#52482](https://github.com/moby/moby/pull/52482)
+- Fix support for CDI specifications that request additional group IDs. [moby/moby#52579](https://github.com/moby/moby/pull/52579)
+- Fix volume subpath file mounts over an existing file in the image failing container creation with "not a directory". [moby/moby#52584](https://github.com/moby/moby/pull/52584)
+- Sort labels in `volume`, `network`, `config`, and `secret` formatters for deterministic output. [docker/cli#6954](https://github.com/docker/cli/pull/6954)
+- Swarm: Prevent corruption of Raft snapshots when swarm state is large. [moby/moby#52441](https://github.com/moby/moby/pull/52441)
+
+### Packaging updates
+
+- Update BuildKit to [v0.30.0](https://github.com/moby/buildkit/releases/tag/v0.30.0). [moby/moby#52618](https://github.com/moby/moby/pull/52618)
+- Update Go runtime to [1.26.3](https://go.dev/doc/devel/release#go1.26.3). [moby/moby#52572](https://github.com/moby/moby/pull/52572), [docker/cli#6967](https://github.com/docker/cli/pull/6967)
+
+### Networking
+
+- Fix conntrack entries being incorrectly deleted for UDP containers sharing the same port on different IPs when one container is restarted. [moby/moby#52423](https://github.com/moby/moby/pull/52423)
+- Fix stale VIP DNS records for swarm service network aliases not being removed during rolling updates. [moby/moby#52236](https://github.com/moby/moby/pull/52236)
+- Fix the userland proxy silently dropping UDP datagrams when a previous write to an unavailable backend left a stale ECONNREFUSED error on the socket. [moby/moby#52483](https://github.com/moby/moby/pull/52483)
+- Rootless: Properly support `--net=host` and localhost registries. [moby/moby#47103](https://github.com/moby/moby/pull/47103)
+
+### Rootless
+
+- Update RootlessKit to [v3.0.0](https://github.com/rootless-containers/rootlesskit/releases/tag/v3.0.0). [moby/moby#52319](https://github.com/moby/moby/pull/52319)
+
+### Go SDK
+
+- cli/config/configfile: `GetAuthConfig`, `GetCredentialsStore`: normalize hostname when resolving auth. [docker/cli#6846](https://github.com/docker/cli/pull/6846)
+
+### Deprecations
+
+- cli/command/image/build: remove deprecated `DefaultDockerfileName` const. [docker/cli#6737](https://github.com/docker/cli/pull/6737)
+- cli/command/image/build: remove deprecated `DetectArchiveReader` util. [docker/cli#6737](https://github.com/docker/cli/pull/6737)
+- cli/command/image/build: remove deprecated `IsArchive` utility. [docker/cli#6737](https://github.com/docker/cli/pull/6737)
+- cli/command/image/build: remove deprecated `ResolveAndValidateContextPath` util. [docker/cli#6737](https://github.com/docker/cli/pull/6737)
+- cli/command/image/build: remove deprecated `WriteTempDockerfile` util. [docker/cli#6737](https://github.com/docker/cli/pull/6737)
+
+## 29.4.3
+
+{{< release-date date="2026-05-06" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.4.3 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.4.3)
+- [moby/moby, 29.4.3 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.4.3)
+
+### Security
+
+- **CVE-2026-31431**: Replace the socketcall(2) seccomp deny that broke 32-bit programs with targeted AppArmor (deny network alg) and SELinux (alg_socket) rules that block AF_ALG at the LSM layer, covering both socket(2) and socketcall(2) paths without disrupting legitimate 32-bit workloads. [moby/moby#52537](https://github.com/moby/moby/pull/52537)
+
+  On SELinux-based systems, the SELinux mitigation requires the daemon to be configured with `selinux-enabled: true` (via `daemon.json` or the `--selinux-enabled` CLI flag). This option is not enabled by default.
+
+- Fix the default AppArmor profile not being updated on daemon restart, requiring a system reboot to pick up profile changes from daemon upgrades. [moby/moby#52537](https://github.com/moby/moby/pull/52537)
+
+## 29.4.2
+
+{{< release-date date="2026-05-01" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.4.2 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.4.2)
+- [moby/moby, 29.4.2 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.4.2)
+
+### Security
+
+This release includes hardening for **CVE-2026-31431**.
+
+- Block `AF_ALG` sockets and the `socketcall(2)` multiplexer in the default seccomp profile to prevent in-container privilege escalation via the kernel crypto API ("Copy Fail"). [moby/moby#52501](https://github.com/moby/moby/pull/52501)
+
+### Known issues
+
+The hardening can break 32-bit programs and i386 images, including SteamCMD and some Wine-based workloads. [moby/moby#52506](https://github.com/moby/moby/issues/52506)
+
+#### Workaround
+
+> [!WARNING]
+> Don't use `--security-opt seccomp=unconfined` to work around this issue.  
+> Don't use the `seccomp/v0.2.0` profile.
+
+If you need a workaround, use the `seccomp/v0.2.1` profile from `moby/profiles`.
+Make sure you use a kernel that includes the fix for CVE-2026-31431.
+
+This profile unblocks `socketcall` while keeping `AF_ALG` blocked for `socket`.
+
+> [!IMPORTANT]
+> Use this workaround only for containers that require it.  
+> Containers that use this profile can still exploit CVE-2026-31431 through the `socketcall` syscall.
+
+Download the `seccomp/v0.2.1` profile:
+
+```console
+$ curl -fsSL https://raw.githubusercontent.com/moby/profiles/refs/tags/seccomp/v0.2.1/seccomp/default.json \
+  -o /etc/docker/seccomp-profile-v0.2.1.json
+```
+
+Use one of these options. You don't need both.
+
+1. To use the profile for a specific container when you control the `docker run` command, use `--security-opt`:
+
+  ```console
+  $ docker run --security-opt seccomp=<path> ...
+  ```
+
+2. To use the profile as the default for containers created by the daemon, add `seccomp-profile` to your `daemon.json`:
+
+  ```json
+  {
+    "seccomp-profile": "/etc/docker/seccomp-profile-v0.2.1.json"
+  }
+  ```
+
+## 29.4.1
+
+{{< release-date date="2026-04-20" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.4.1 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.4.1)
+- [moby/moby, 29.4.1 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.4.1)
+
+### Bug fixes and enhancements
+
+- containerd image store: Fix `docker image prune --filter label!=key=value` incorrectly skipping images that don't have the specified label. [moby/moby#52338](https://github.com/moby/moby/pull/52338)
+- Fix `--log-opt "tag={{.ImageID}}"` not stripping the digest's algorithm. [moby/moby#52343](https://github.com/moby/moby/pull/52343)
+- Fix intermittent container start failures (`EBUSY` on secrets/configs remount) on busy Swarm nodes by retrying the read-only remount. [moby/moby#52235](https://github.com/moby/moby/pull/52235)
+
+### Packaging updates
+
+- Update containerd (static binaries only) to [v2.2.3](https://github.com/containerd/containerd/releases/tag/v2.2.3). [moby/moby#52360](https://github.com/moby/moby/pull/52360)
+- Update Go runtime to [1.26.2](https://go.dev/doc/devel/release#go1.26.2). [docker/cli#6920](https://github.com/docker/cli/pull/6920), [moby/moby#52329](https://github.com/moby/moby/pull/52329)
+
+### Networking
+
+- if a container has an IPv4-only or an IPv6-only endpoint with higher "gateway priority" than a dual stack endpoint, the single stack endpoint will now be used as the default gateway for its address family. [moby/moby#52328](https://github.com/moby/moby/pull/52328)
+
+
+## 29.4.0
+
+{{< release-date date="2026-04-07" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.4.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.4.0)
+- [moby/moby, 29.4.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.4.0)
+
+### Bug fixes and enhancements
+
+- docker cp: report both content size and transferred size. [docker/cli#6800](https://github.com/docker/cli/pull/6800)
+- Fix `docker stats --all` still showing containers that were removed. [docker/cli#6863](https://github.com/docker/cli/pull/6863)
+- Fix a rare bug that could cause containers to become unremovable. [moby/moby#51724](https://github.com/moby/moby/pull/51724)
+- Fixed privileged containers losing their explicit AppArmor profile (`--security-opt apparmor=<profile>`) after a container restart. [moby/moby#52215](https://github.com/moby/moby/pull/52215)
+- Improved duplicate container-exit handling by using live containerd task state (not timestamps). [moby/moby#52156](https://github.com/moby/moby/pull/52156)
+- Improved image pull and push performance by enabling HTTP keep-alive for registry connections, avoiding redundant TCP and TLS handshakes. [moby/moby#52198](https://github.com/moby/moby/pull/52198)
+- shell completions: add shell completion for `docker rm --link` and exclude legacy links for container names. [docker/cli#6872](https://github.com/docker/cli/pull/6872)
+- shell completions: don't provide completions that were already used. [docker/cli#6871](https://github.com/docker/cli/pull/6871)
+- Update runc (in static binaries) to [v1.3.5](https://github.com/opencontainers/runc/releases/tag/v1.3.5). [moby/moby#52244](https://github.com/moby/moby/pull/52244)
+- Windows: Fix `DOCKER_TMPDIR` not being respected. [moby/moby#52181](https://github.com/moby/moby/pull/52181)
+
+### Packaging updates
+
+- Update BuildKit to [v0.29.0](https://github.com/moby/buildkit/releases/tag/v0.29.0). [moby/moby#52272](https://github.com/moby/moby/pull/52272)
+
+### Networking
+
+- Prevent a daemon crash during startup after upgrading if a container config containers a malformed IP-address. [moby/moby#52275](https://github.com/moby/moby/pull/52275)
+
+### Go SDK
+
+- cli/streams: Out, In: preserve original os.File when available. [docker/cli#6906](https://github.com/docker/cli/pull/6906)
+- Update minimum go version to go1.25. [docker/cli#6897](https://github.com/docker/cli/pull/6897)
+
+### Deprecations
+
+- Go SDK: cli-plugins/hooks: deprecate `HookMessage ` and rename to `cli-plugins/hooks.Response`. [docker/cli#6859](https://github.com/docker/cli/pull/6859)
+- Go SDK: cli-plugins/hooks: deprecate `HookType` and rename to `cli-plugins/hooks.ResponseType`. [docker/cli#6859](https://github.com/docker/cli/pull/6859)
+- Go SDK: cli-plugins/manager: deprecate `HookPluginData` and move to `cli-plugins/hooks.Request`. [docker/cli#6859](https://github.com/docker/cli/pull/6859)
+
+## 29.3.1
+
+{{< release-date date="2026-03-25" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.3.1 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.3.1)
+- [moby/moby, 29.3.1 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.3.1)
+
+### Security
+
+This release includes fixes for multiple security vulnerabilities affecting Docker Engine and related components.
+
+- **CVE-2026-34040** Fix an authorization bypass in AuthZ plugins that could allow authorization plugins to be bypassed under specific conditions.
+  [GHSA-x744-4wpc-v9h2](https://github.com/moby/moby/security/advisories/GHSA-x744-4wpc-v9h2)
+
+- **CVE-2026-33997** Fix a flaw in `docker plugin install` where privilege validation could be partially bypassed, potentially leading to unauthorized privilege escalation.
+  [GHSA-pxq6-2prw-chj9](https://github.com/moby/moby/security/advisories/GHSA-pxq6-2prw-chj9)
+
+- **CVE-2026-33748** Fix insufficient validation of Git URL `#ref:subdir` fragments in BuildKit, which could allow access to files outside the intended repository scope.
+  [GHSA-4vrq-3vrq-g6gg](https://github.com/moby/buildkit/security/advisories/GHSA-4vrq-3vrq-g6gg)
+
+- **CVE-2026-33747** Fix a vulnerability in BuildKit where an untrusted frontend could cause files to be written outside the BuildKit state directory.
+  [GHSA-3c29-8rgm-jvjj](https://github.com/moby/buildkit/security/advisories/GHSA-4c29-8rgm-jvjj)
+
+### Bug fixes and enhancements
+
+- Fix a daemon crash during docker build if `.dockerignore` contained an invalid pattern. [moby/moby#52214](https://github.com/moby/moby/pull/52214)
+- Fix a panic when the containerd client uses a closed stream. [moby/moby#52211](https://github.com/moby/moby/pull/52211)
+
+### Packaging updates
+
+- Update containerd (static binaries) to [v2.2.2](https://github.com/containerd/containerd/releases/tag/v2.2.2). [moby/moby#52213](https://github.com/moby/moby/pull/52213)
+- Update Go runtime to [1.25.8](https://go.dev/doc/devel/release#go1.25.8). [moby/moby#52210](https://github.com/moby/moby/pull/52210), [docker/cli#6883](https://github.com/docker/cli/pull/6883)
+
+### Go SDK
+
+- Add missing build-tag, which could cause `cannot range over 10 (untyped int constant)`  when importing the `cli/command` package. [docker/cli#6884](https://github.com/docker/cli/pull/6884)
+
+## 29.3.0
+
+{{< release-date date="2026-03-05" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.3.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.3.0)
+- [moby/moby, 29.3.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.3.0)
+
+### New
+
+- Add `bind-create-src` option to `--mount` flag for bind mounts. [docker/cli#6792](https://github.com/docker/cli/pull/6792)
+- CLI plugin hooks now fire on command failure (not just success), and plugins can use "error-hooks" to show hints only when commands fail. [docker/cli#6794](https://github.com/docker/cli/pull/6794)
+- Lower minimum API version from v1.44 to v1.40 (Docker 19.03). [moby/moby#52067](https://github.com/moby/moby/pull/52067)
+
+### Packaging updates
+
+- Update BuildKit to [v0.28.0](https://github.com/moby/buildkit/releases/tag/v0.28.0). [moby/moby#52135](https://github.com/moby/moby/pull/52135)
+
+### Networking
+
+- Fix DNS config corruption on daemon reload. [moby/moby#52060](https://github.com/moby/moby/pull/52060)
+
+### API
+
+- `POST /networks/{id}/connect` now correctly applies the `MacAddress` field in `EndpointSettings`. This field was added in API v1.44, but was previously ignored. [moby/moby#52040](https://github.com/moby/moby/pull/52040)
+- `GET /images/json` now supports an `identity` query parameter. When set, the response includes manifest summaries and may include an `Identity` field for each manifest with trusted identity and origin information. [moby/moby#52030](https://github.com/moby/moby/pull/52030)
+
+### Bug fixes and enhancements
+
+- The `--gpus` option now uses CDI-based injection for AMD GPUs. [moby/moby#52048](https://github.com/moby/moby/pull/52048)
+- Add `sd_notify` ["RELOADING"](https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html#RELOADING=1) notifications when signalling the daemon to reload its configuration. [moby/moby#52041](https://github.com/moby/moby/pull/52041)
+- Send `sd_notify` ["READY"](https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html#READY=1) and ["STOPPING"](https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html#STOPPING=1) synchronously to make sure they are sent before we proceed. [moby/moby#52041](https://github.com/moby/moby/pull/52041)
+- Add support for the systemd 253 `Type=notify-reload` service reload protocol. [moby/moby#52041](https://github.com/moby/moby/pull/52041)
+- Don't log "failed to determine if container is already mounted" warnings for stopped containers during startup. [moby/moby#52076](https://github.com/moby/moby/pull/52076)
+- Fix `docker system prune` failing with "rw layer snapshot not found" when a container is concurrently removed. [moby/moby#52090](https://github.com/moby/moby/pull/52090)
+- Fix a panic when running `docker top` on a non-running Windows container. [moby/moby#52025](https://github.com/moby/moby/pull/52025)
+- Fix a regression in v29.2.0 that prevented registering the dockerd service on Windows if system requirements were not yet installed. [moby/moby#52006](https://github.com/moby/moby/pull/52006)
+- Fix shared mount detection for paths mounted multiple times, which caused "not a shared mount" errors when using bind propagation. [moby/moby#51787](https://github.com/moby/moby/pull/51787)
+- Fix spurious "ShouldRestart failed" warning on shutdown. [moby/moby#52079](https://github.com/moby/moby/pull/52079)
+- Preserve leading and trailing whitespace when storing registry passwords. [docker/cli#6784](https://github.com/docker/cli/pull/6784)
+- Prevent logging "not found" warnings when calculating volume sizes. [moby/moby#52018](https://github.com/moby/moby/pull/52018)
+- Update Go runtime to [1.25.7](https://go.dev/doc/devel/release#go1.25.7). [moby/moby#52003](https://github.com/moby/moby/pull/52003), [docker/cli#6780](https://github.com/docker/cli/pull/6780)
+
+## 29.2.1
+
+{{< release-date date="2026-02-02" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.2.1 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.2.1)
+- [moby/moby, 29.2.1 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.2.1)
+
+### Bug fixes and enhancements
+
+- Update BuildKit to [v0.27.1](https://github.com/moby/buildkit/releases/tag/v0.27.1). [moby/moby#51962](https://github.com/moby/moby/pull/51962)
+- Fix `docker system df` failing when run concurrently with `docker system prune`. [moby/moby#51979](https://github.com/moby/moby/pull/51979)
+- Fix daemon handling of duplicate container exit events to avoid repeated cleanup and state transitions. [moby/moby#51925](https://github.com/moby/moby/pull/51925)
+- Fix panic after failed daemon initialization. [moby/moby#51943](https://github.com/moby/moby/pull/51943)
+- Fix encrypted overlay networks not passing traffic to containers on v28 and older Engines. Encrypted overlay networks will no longer pass traffic to containers on v29.2.0 thru v29.0.0, v28.2.2, v25.0.14 or v25.0.13. [moby/moby#51951](https://github.com/moby/moby/pull/51951)
+- Fix potential panic on `docker network prune`. [moby/moby#51966](https://github.com/moby/moby/pull/51966)
+
+## 29.2.0
+
+{{< release-date date="2026-01-26" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.2.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.2.0)
+- [moby/moby, 29.2.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.2.0)
+
+### New
+
+- `docker info` now includes `NRI` section. [docker/cli#6710](https://github.com/docker/cli/pull/6710)
+- Add experimental NRI support. [moby/moby#51711](https://github.com/moby/moby/pull/51711), [moby/moby#51712](https://github.com/moby/moby/pull/51712), [moby/moby#51675](https://github.com/moby/moby/pull/51675), [moby/moby#51674](https://github.com/moby/moby/pull/51674), [moby/moby#51636](https://github.com/moby/moby/pull/51636), [moby/moby#51634](https://github.com/moby/moby/pull/51634)
+- New `Identity` field has been added to the inspect endpoint to show trusted origin information about the image. This includes build ref for locally built images, remote registry repository for pulled images, and verified signature information for images that contain a valid signed provenance attestation. [moby/moby#51737](https://github.com/moby/moby/pull/51737)
+
+### Bug fixes and enhancements
+
+- Improve validation of `--detach-keys` command-line options. [docker/cli#6742](https://github.com/docker/cli/pull/6742)
+- Prevent a potential panic on daemon shutdown after an incomplete initialization. [moby/moby#51797](https://github.com/moby/moby/pull/51797)
+- Remove restriction on anonymous read-only volumes. [moby/moby#51682](https://github.com/moby/moby/pull/51682)
+- The `--validate` flag on dockerd now also verifies system requirements, allowing for system requirements to be checked before starting the daemon. [moby/moby#51868](https://github.com/moby/moby/pull/51868)
+- Handle `--gpus` requests for NVIDIA devices using CDI if possible. [moby/moby#50228](https://github.com/moby/moby/pull/50228)
+
+### Packaging updates
+
+- Update BuildKit to [v0.27.0](https://github.com/moby/buildkit/releases/tag/v0.27.0). [moby/moby#51886](https://github.com/moby/moby/pull/51886)
+- Update containerd (static binaries only) to [v2.2.1](https://github.com/containerd/containerd/releases/tag/v2.2.1). [moby/moby#51765](https://github.com/moby/moby/pull/51765)
+
+### Rootless
+
+- Rootless: Consider `$XDG_CONFIG_HOME/cdi` and `$XDG_RUNTIME_DIR/cdi` when looking for CDI devices. [moby/moby#51624](https://github.com/moby/moby/pull/51624)
+- Update RootlessKit to [v2.3.6](https://github.com/rootless-containers/rootlesskit/releases/tag/v2.3.6). [moby/moby#51757](https://github.com/moby/moby/pull/51757)
+
+### API
+
+- Natively support gRPC on the listening socket. [moby/moby#50744](https://github.com/moby/moby/pull/50744)
+
+### Go SDK
+
+- cli/command: add WithAPIClientOptions option. [docker/cli#6740](https://github.com/docker/cli/pull/6740)
+
+### Deprecations
+
+- Remove `%PROGRAMDATA%\Docker\cli-plugins` from the list of paths used for CLI plugins on Windows. This path was present for backward compatibility with old installation, but replaced by `%ProgramFiles%\Docker\cli-plugins`. [docker/cli#6713](https://github.com/docker/cli/pull/6713)
+
+## 29.1.5
+
+{{< release-date date="2026-01-16" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.1.5 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.1.5)
+- [moby/moby, 29.1.5 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.1.5)
+
+### Packaging updates
+
+- Update Go runtime to [1.25.6](https://go.dev/doc/devel/release#go1.25.6). [moby/moby#51860](https://github.com/moby/moby/pull/51860), [docker/cli#6750](https://github.com/docker/cli/pull/6750)
+
+### Networking
+
+- Fixed a regression where established network connections could be disrupted during a container's shutdown grace period. [moby/moby#51843](https://github.com/moby/moby/pull/51843)
+
+## 29.1.4
+
+{{< release-date date="2026-01-08" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.1.4 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.1.4)
+- [moby/moby, 29.1.4 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.1.4)
+
+### Bug fixes and enhancements
+
+- Fix `docker run --network none` panic on Windows. [moby/moby#51830](https://github.com/moby/moby/pull/51830)
+- Fix image mounts failing with "file name too long" for long mount paths. [moby/moby#51829](https://github.com/moby/moby/pull/51829)
+- Fix potential creation of orphaned overlay2 layers. [moby/moby#51826](https://github.com/moby/moby/pull/51826), [moby/moby#51824](https://github.com/moby/moby/pull/51824)
+
+### Packaging updates
+
+- Update BuildKit to [v0.26.3](https://github.com/moby/buildkit/releases/tag/v0.26.3). [moby/moby#51821](https://github.com/moby/moby/pull/51821)
+
+## 29.1.3
+
+{{< release-date date="2025-12-12" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.1.3 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.1.3)
+- [moby/moby, 29.1.3 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.1.3)
+
+### Bug fixes and enhancements
+
+- Add shell completion for `docker stack deploy --compose-file`. [docker/cli#6690](https://github.com/docker/cli/pull/6690)
+- containerd image store: Fix a bug causing `docker build` to ignore the explicitly set `unpack` image exporter option. [moby/moby#51514](https://github.com/moby/moby/pull/51514)
+- Fix `docker image ls` dangling image handling. [docker/cli#6704](https://github.com/docker/cli/pull/6704)
+- Fix a bug that could cause the Engine to leave containers with autoremove set in 'dead' state on shutdown, and never reclaim them. [moby/moby#51693](https://github.com/moby/moby/pull/51693)
+- Fix build on i386. [moby/moby#51528](https://github.com/moby/moby/pull/51528)
+- Fix explicit graphdriver configuration (`"storage-driver"`) being treated as containerd snapshotter when prior graphdriver state exists. [moby/moby#51516](https://github.com/moby/moby/pull/51516)
+- Fix potential creation of orphaned overlay2 layers. [moby/moby#51703](https://github.com/moby/moby/pull/51703)
+
+### Networking
+
+- Allow creation of a container with a specific IP address when its networks were not configured with a specific subnet. [moby/moby#51583](https://github.com/moby/moby/pull/51583)
+- Don't crash when starting a container created via the API before upgrade to v29.1.2, with `PublishAll` and a nil `PortBindings` map. [moby/moby#51691](https://github.com/moby/moby/pull/51691)
+- Fix a bug preventing DNS resolution of containers attached to non swarm-scoped networks once the node has joined a Swarm cluster. [moby/moby#51515](https://github.com/moby/moby/pull/51515)
+- Fix an issue that caused daemon crash when using a remote network driver plugin. [moby/moby#51558](https://github.com/moby/moby/pull/51558)
+- Fix an issue that could lead to an "endpoint not found" error when creating a container with multiple network connections, when one of the networks is non-internal but does not have its own external IP connectivity. [moby/moby#51538](https://github.com/moby/moby/pull/51538)
+- Fix an issue that prevented rootless Docker from starting on a host with IPv6 disabled. [moby/moby#51543](https://github.com/moby/moby/pull/51543)
+- Return an error when a container is created with a port-mapping pointing to container port 0. [moby/moby#51695](https://github.com/moby/moby/pull/51695)
+
+## 29.1.2
+
+{{< release-date date="2025-12-02" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.1.2 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.1.2)
+- [moby/moby, 29.1.2 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.1.2)
+
+### Security
+
+- Update Go runtime to [1.25.5](https://go.dev/doc/devel/release#go1.25.5). [moby/moby#51648](https://github.com/moby/moby/pull/51648), [docker/cli#6688](https://github.com/docker/cli/pull/6688)
+  - Fixes a potential DoS via excessive resource usage when formatting hostname validation errors [**CVE-2025-61729**](https://nvd.nist.gov/vuln/detail/CVE-2025-61729)
+  - Fixes incorrect enforcement of excluded subdomain constraints for wildcard SANs, which could allow improperly trusted certificates [**CVE-2025-61727**](https://nvd.nist.gov/vuln/detail/CVE-2025-22874)
+
+### Bug fixes and enhancements
+
+- containerd image store: Fix `docker image inspect` failing to return available image data in case where not all distributable blobs are available locally. [moby/moby#51629](https://github.com/moby/moby/pull/51629)
+- dockerd-rootless-setuptool.sh: fix `nsenter: no namespace specified`. [moby/moby#51622](https://github.com/moby/moby/pull/51622)
+- Fix `docker system df` showing `N/A` for shared size and unique size when using graph-drivers as storage. [moby/moby#51631](https://github.com/moby/moby/pull/51631)
+
+### Packaging updates
+
+- Update runc (in static binaries) to [v1.3.4](https://github.com/opencontainers/runc/releases/tag/v1.3.4). [moby/moby#51633](https://github.com/moby/moby/pull/51633)
+
+### Networking
+
+- Fix a bug preventing port mappings in rootless mode when slirp4netns is used. [moby/moby#51616](https://github.com/moby/moby/pull/51616)
+- Prevent a crash when making an API request with `HostConfig.PublishAllPorts` set (`-P`), and no port bindings. [moby/moby#51621](https://github.com/moby/moby/pull/51621)
+
+## 29.1.1
+
+{{< release-date date="2025-11-28" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.1.1 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.1.1)
+- [moby/moby, 29.1.1 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.1.1)
+
+### Networking
+
+- Revert a PR breaking external DNS resolution on all custom bridge networks. [moby/moby#51615](https://github.com/moby/moby/pull/51615)
+
+## 29.1.0
+
+{{< release-date date="2025-11-27" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.1.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.1.0)
+- [moby/moby, 29.1.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.1.0)
+
+### Packaging updates
+
+- Update BuildKit to [v0.26.1](https://github.com/moby/buildkit/releases/tag/v0.26.1). [moby/moby#51551](https://github.com/moby/moby/pull/51551)
+- Update containerd binary to v2.2.0 (static binaries). [moby/moby#51271](https://github.com/moby/moby/pull/51271)
+
+### Networking
+
+- Do not overwrite user-modified `/etc/resolv.conf` across container restarts. [moby/moby#51507](https://github.com/moby/moby/pull/51507)
+- fix `--publish-all` / `-P` for Windows containers. [moby/moby#51586](https://github.com/moby/moby/pull/51586)
+- Fix an issue that prevented container restart or network reconnection when gateway configuration failed during container stop or network disconnect. [moby/moby#51592](https://github.com/moby/moby/pull/51592)
+- Windows containers: don't display an IPv6-mapped IPv4 address in port mappings. For example, `[::ffff:0.0.0.0]:8080->80/tcp` instead of `0.0.0.0:8080->80/tcp`. [moby/moby#51587](https://github.com/moby/moby/pull/51587)
+
+## 29.0.4
+
+{{< release-date date="2025-11-24" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.0.4 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.0.4)
+- [moby/moby, 29.0.4 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.0.4)
+
+### Bug fixes and enhancements
+
+- `docker image ls` no longer truncates the image names. [docker/cli#6675](https://github.com/docker/cli/pull/6675)
+
+### Networking
+
+- Allow creation of a container with a specific IP address when its networks were not configured with a specific subnet. [moby/moby#51583](https://github.com/moby/moby/pull/51583)
+
+## 29.0.3
+
+{{< release-date date="2025-11-24" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.0.3 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.0.3)
+- [moby/moby, 29.0.3 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.0.3)
+
+### Bug fixes and enhancements
+
+- `docker version --format json`: restore top-level `BuildTime` field to use RFC3339Nano format. [docker/cli#6668](https://github.com/docker/cli/pull/6668)
+- Fix `docker image ls` ignoring a custom `imageFormat` from `docker.json`. [docker/cli#6667](https://github.com/docker/cli/pull/6667)
+
+### Networking
+
+- Fix an issue that caused daemon crash when using a remote network driver plugin. [moby/moby#51558](https://github.com/moby/moby/pull/51558)
+
+## 29.0.2
+
+{{< release-date date="2025-11-17" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.0.2 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.0.2)
+- [moby/moby, 29.0.2 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.0.2)
+
+### Networking
+
+- Fix an issue that could lead to an "endpoint not found" error when creating a container with multiple network connections, when one of the networks is non-internal but does not have its own external IP connectivity. [moby/moby#51538](https://github.com/moby/moby/pull/51538)
+- Fix an issue that prevented rootless Docker from starting on a host with IPv6 disabled. [moby/moby#51543](https://github.com/moby/moby/pull/51543)
+
+## 29.0.1
+
+{{< release-date date="2025-11-14" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.0.1 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.0.1)
+- [moby/moby, 29.0.1 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.0.1)
+
+### Bug fixes and enhancements
+
+- `docker image ls` no longer truncates the name width when output is redirect (e.g. for `grep`). [docker/cli#6656](https://github.com/docker/cli/pull/6656)
+- `docker image ls` now considers the `NO_COLOR` environment variable for choosing the colored output. [docker/cli#6654](https://github.com/docker/cli/pull/6654)
+- containerd image store: Fix a bug causing `docker build` to ignore the explicitly set `unpack` image exporter option. [moby/moby#51514](https://github.com/moby/moby/pull/51514)
+- Fix a bug causing `docker image ls --all` to not show untagged/dangling images. [docker/cli#6657](https://github.com/docker/cli/pull/6657)
+- Fix build on i386. [moby/moby#51528](https://github.com/moby/moby/pull/51528)
+- Fix explicit graphdriver configuration (`"storage-driver"`) being treated as containerd snapshotter when prior graphdriver state exists. [moby/moby#51516](https://github.com/moby/moby/pull/51516)
+- Fix output format of the `ApiVersion` and `MinApiVersion` fields in  `docker version --format=json` to align with previous versions. [docker/cli#6648](https://github.com/docker/cli/pull/6648)
+
+### Networking
+
+- Fix a bug preventing DNS resolution of containers attached to non swarm-scoped networks once the node has joined a Swarm cluster. [moby/moby#51515](https://github.com/moby/moby/pull/51515)
+
+## 29.0.0
+
+{{< release-date date="2025-11-10" >}}
+
+For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:
+
+- [docker/cli, 29.0.0 milestone](https://github.com/docker/cli/issues?q=is%3Aclosed+milestone%3A29.0.0)
+- [moby/moby, 29.0.0 milestone](https://github.com/moby/moby/issues?q=is%3Aclosed+milestone%3A29.0.0)
+
+> [!CAUTION]
+> This release includes several breaking changes and deprecations. Review the release notes carefully before upgrading.
+
+- Experimental support for nftables can now be enabled by setting Docker daemon's `firewall-backend` option to `nftables`. For more information, see [Docker Engine docs](https://docs.docker.com/engine/network/firewall-nftables/).
+- containerd image store is now the default for **fresh installs**. This doesn't apply to daemons configured with `userns-remap` (see [moby#47377](https://github.com/moby/moby/issues/47377)).
+
+### Breaking Changes
+
+- The Go module `github.com/docker/docker` is deprecated in favor of `github.com/moby/moby/client` and `github.com/moby/moby/api`. The `github.com/moby/moby` module is considered an **internal implementation detail** - the only supported public modules are `client` and `api`.
+  Starting with v29, releases are tagged with the `docker-` prefix (e.g., `docker-v29.0.0`). **This only affects Go module users and package maintainers.**
+- The daemon now requires API version `v1.44` or later (Docker v25.0+).
+- Debian armhf (32-bit) packages now target ARMv7 CPUs and will not work on ARMv6 devices.
+- Official Raspbian (32-bit) packages are no longer provided. Use Debian arm64 packages for 64-bit devices, or Debian armhf packages for 32-bit ARMv7 devices.
+- **cgroup v1 is deprecated.** Support continues until at least May 2029, but migrate to cgroup v2 as soon as possible. See [moby#51111](https://github.com/moby/moby/issues/51111).
+- Docker Content Trust was removed from the Docker CLI. Can be built as a separate plugin: https://github.com/docker/cli/blob/v29.0.0/cmd/docker-trust/main.go
+
+---
+
+### New
+
+- `docker image load` and `docker image save` now supports multiple platform selection via `--platform` flag (e.g., `docker image load --platform linux/amd64,linux/arm64 -i image.tar`). [docker/cli#6126](https://github.com/docker/cli/pull/6126)
+- `docker image ls` now uses the new view (like `--tree` but collapsed) by default. [docker/cli#6566](https://github.com/docker/cli/pull/6566)
+- `docker run --runtime <...>` is now supported on Windows. [moby/moby#50546](https://github.com/moby/moby/pull/50546)
+- `GET /containers/json` now includes a `Health` field describing container healthcheck status. [moby/moby#50281](https://github.com/moby/moby/pull/50281)
+- Add `device` entitlement to builder configuration. [moby/moby#50386](https://github.com/moby/moby/pull/50386)
+- Add support for `memory-swap` and `memory-swappiness` flags to `docker service create` and `docker service update` commands. [docker/cli#6619](https://github.com/docker/cli/pull/6619)
+- Allow Docker CLI to set the `GODEBUG` environment variable when the key-value pair (`"GODEBUG":"..."`) exists inside the Docker context metadata. [docker/cli#6371](https://github.com/docker/cli/pull/6371)
+
+### Bug fixes and enhancements
+
+- `docker image ls --tree` now sorts images alphabetically by name instead of by creation date. [docker/cli#6595](https://github.com/docker/cli/pull/6595)
+- `docker image ls` no longer shows untagged images by default if no `--all` flag is provided. [docker/cli#6574](https://github.com/docker/cli/pull/6574)
+- `docker save`: Fixed inconsistent tar member timestamps when exporting images with the overlay2 storage driver. [moby/moby#51365](https://github.com/moby/moby/pull/51365)
+- Add a new log option for fluentd log driver (`fluentd-read-timeout`), which enables specifying read timeouts for reading acks from fluentd connections. [moby/moby#50249](https://github.com/moby/moby/pull/50249)
+- Add image name completion for `docker images`. [docker/cli#6452](https://github.com/docker/cli/pull/6452)
+- Add shell completion for `docker inspect` if a `--type` is set. [docker/cli#6444](https://github.com/docker/cli/pull/6444)
+- Add shell completion for `docker plugin` subcommands. [docker/cli#6445](https://github.com/docker/cli/pull/6445)
+- api/types/container: make ContainerState, HealthStatus concrete types. [moby/moby#51439](https://github.com/moby/moby/pull/51439)
+- containerd image store is temporarily not available when userns remapping is enabled as a workaround for [moby#47377](https://github.com/moby/moby/issues/47377). [moby/moby#51042](https://github.com/moby/moby/pull/51042)
+- contrib: remove contrib/httpserver, which was only used for integration tests. [moby/moby#50654](https://github.com/moby/moby/pull/50654)
+- daemon: improve validation of the `--dns` option and corresponding `"dns"` field in `daemon.json`. [moby/moby#50600](https://github.com/moby/moby/pull/50600)
+- dockerd-rootless.sh: if slirp4netns is not installed, try using pasta (passt). [moby/moby#51149](https://github.com/moby/moby/pull/51149)
+- Fix `--mount type=image` failure when mounting the same image multiple times to a different destinations. [moby/moby#50268](https://github.com/moby/moby/pull/50268)
+- Fix `docker stats <container>` not exiting gracefully. [docker/cli#6582](https://github.com/docker/cli/pull/6582)
+- Fix a bug preventing the API server from shutting down quickly when there's an open connection to the `/events` endpoint. [moby/moby#51448](https://github.com/moby/moby/pull/51448)
+- Fix a bug where collecting container stats in "one-shot" mode would not include the container's ID and Name. [moby/moby#51302](https://github.com/moby/moby/pull/51302)
+- Fix an issue where all new tasks in the Swarm could get stuck in the PENDING state forever after scaling up a service with placement preferences. [moby/moby#50202](https://github.com/moby/moby/pull/50202)
+- Fix issue where custom meta-headers were not passed through when using the containerd image store. [moby/moby#51024](https://github.com/moby/moby/pull/51024)
+- Fix requests not being logged when running the daemon with `--log-level=trace`. [moby/moby#50986](https://github.com/moby/moby/pull/50986)
+- Fix Swarm services becoming unreachable from published ports after a firewalld reload. [moby/moby#50443](https://github.com/moby/moby/pull/50443)
+- Improve errors when failing to connect to the API to provide more context to the user. [moby/moby#50285](https://github.com/moby/moby/pull/50285)
+- Improve shell completion for `docker secret` and `docker config` subcommands. [docker/cli#6446](https://github.com/docker/cli/pull/6446)
+- Prefer explicit device driver name over GPU capabilities when selecting the device driver with `docker run --gpus`. [moby/moby#50717](https://github.com/moby/moby/pull/50717)
+- Update runc to [v1.3.3](https://github.com/opencontainers/runc/releases/tag/v1.3.3). [moby/moby#51393](https://github.com/moby/moby/pull/51393)
+- Update SwarmKit internal TLS configuration to exclude known insecure cipher suites. [moby/moby#51139](https://github.com/moby/moby/pull/51139)
+- Windows: Fix BuildKit creating containers which isolation mode is inconsistent with the daemon's config. [moby/moby#50942](https://github.com/moby/moby/pull/50942)
+
+### Packaging updates
+
+- client: remove legacy CBC cipher suites from client config. [moby/moby#50126](https://github.com/moby/moby/pull/50126)
+- contrib: remove `editorconfig` as it was unmaintained. [moby/moby#50607](https://github.com/moby/moby/pull/50607)
+- contrib: remove Dockerfile syntax highlighting files for `nano` and TextMate (`tmbundle`) as they were unmaintained and outdated. [moby/moby#50606](https://github.com/moby/moby/pull/50606)
+- contrib: remove mkimage-xxx scripts as they were unmaintained and not tested. [moby/moby#50297](https://github.com/moby/moby/pull/50297)
+- If Docker is downgraded to a version that does not have this support the network will become unusable, it must be deleted and re-created. [moby/moby#50114](https://github.com/moby/moby/pull/50114)
+- The Windows overlay network driver now supports option `--dns`. [moby/moby#51229](https://github.com/moby/moby/pull/51229)
+- Update BuildKit to [v0.25.2](https://github.com/moby/buildkit/releases/tag/v0.25.2). [moby/moby#51397](https://github.com/moby/moby/pull/51397)
+- Update containerd to [v2.1.5](https://github.com/containerd/containerd/releases/tag/v2.1.5). [moby/moby#51409](https://github.com/moby/moby/pull/51409)
+
+  containerd v2.1.5 now uses systemd's default `LimitNOFILE` for containers,
+  changing the open file descriptor limit (`ulimit -n`) from `1048576` to
+  `1024`. This extends a change introduced in Docker Engine v25.0 for build
+  containers to all containers.
+
+  This prevents programs that adjust behavior based on ulimits from consuming
+  excessive memory when the limit is set to `infinity`. Containers now behave
+  the same way as programs running on the host.
+
+  If your workload needs a higher limit, use `--ulimit` with `docker run`, or
+  set defaults in `/etc/docker/daemon.json`:
+
+  ```json
+  {
+    "default-ulimits": {
+      "nofile": {
+        "Name": "nofile",
+        "Soft": 1048576,
+        "Hard": 1048576
+      }
+    }
+  }
+  ```
+
+  For more information, see [moby#51485](https://github.com/moby/moby/issues/51485).
+- Update Go runtime to [1.25.4](https://go.dev/doc/devel/release#go1.25.4). [moby/moby#51418](https://github.com/moby/moby/pull/51418), [docker/cli#6632](https://github.com/docker/cli/pull/6632)
+- Users can request a specific prefix size for networks allocated from the default pools by using the unspecified address, for example `--subnet 0.0.0.0/24 --subnet ::/96`. [moby/moby#50114](https://github.com/moby/moby/pull/50114)
+
+### Networking
+
+- Add daemon option `--bridge-accept-fwmark`. Packets with this firewall mark will accepted by bridge networks, overriding Docker's iptables or nftables "drop" rules. [moby/moby#50476](https://github.com/moby/moby/pull/50476)
+- api/types/system: deprecated top level `DiskUsage` fields for type specific fields. [moby/moby#51235](https://github.com/moby/moby/pull/51235)
+- Ensure bridge devices are removed when bridge network creation fails. [moby/moby#51147](https://github.com/moby/moby/pull/51147)
+- Ensure that Windows NAT networks are recreated with their original labels when the Engine restarts. [moby/moby#50447](https://github.com/moby/moby/pull/50447)
+- Environment variables set on a container using legacy links are deprecated and aren't added automatically anymore. [moby/moby#50719](https://github.com/moby/moby/pull/50719)
+  - The daemon can be started with `DOCKER_KEEP_DEPRECATED_LEGACY_LINKS_ENV_VARS=1` to get them back
+  - Users are encouraged to stop relying on these as they're deprecated, and the escape hatch will be removed in a later version
+- Fix a bug in NetworkDB which would sometimes cause entries to get stuck deleted on some of the nodes, leading to connectivity issues between containers on overlay networks. [moby/moby#50342](https://github.com/moby/moby/pull/50342)
+- Fix a bug that could cause the Engine and another host process to bind the same UDP port. [moby/moby#50669](https://github.com/moby/moby/pull/50669)
+- Fix a deadlock that could happen if a firewalld reload was processed while the bridge networking driver was starting up, or creating or deleting a network, or creating port-mappings. [moby/moby#50620](https://github.com/moby/moby/pull/50620)
+- Fix an issue preventing container startup or selection of its network gateway when IPv6 is only disabled on a specific interface. [moby/moby#48971](https://github.com/moby/moby/pull/48971)
+- For Linux, `docker info` now reports the firewall backend if available. [docker/cli#6191](https://github.com/docker/cli/pull/6191)
+- Greatly improve the reliability of overlay networking and the Swarm routing mesh. [moby/moby#50393](https://github.com/moby/moby/pull/50393)
+- Improve the convergence rate of NetworkDB, part of the management plane for overlay networking, after bursts of updates. [moby/moby#50193](https://github.com/moby/moby/pull/50193)
+- Improve the reliability of the overlay network driver. [moby/moby#50260](https://github.com/moby/moby/pull/50260)
+- Improved error handling for connection of a container to a network. [moby/moby#50945](https://github.com/moby/moby/pull/50945)
+- macvlan and IPvlan-l2 networks: no default gateway will be configured unless a `--gateway` is explicitly included in IPAM configuration. This addresses an issue which could cause container startup to fail in networks with IPv6 auto-configuration enabled. [moby/moby#50929](https://github.com/moby/moby/pull/50929)
+- nftables: Docker will not enable IP forwarding on the host. If forwarding is needed by a bridge network, but not enabled, daemon startup or network creation will fail with an error. You must either enable forwarding and ensure firewall rules are in place to prevent unwanted forwarding between non-Docker interfaces. Or, use daemon option `--ip-forward=false` to disable the check, but some bridge network functionality including port forwarding may not work. See [Engine Docs](https://docs.docker.com/engine/network/firewall-nftables) for more information about migration from iptables to nftables. [moby/moby#50646](https://github.com/moby/moby/pull/50646)
+- On daemon startup, restart containers that share their network stacks before containers that need those stacks. [moby/moby#50327](https://github.com/moby/moby/pull/50327)
+- Published ports are now always accessible in networks with gateway mode "routed". Previously, rules to open those ports were only added when the routed mode network was selected as the container's default gateway. [moby/moby#50140](https://github.com/moby/moby/pull/50140)
+- Since 28.0.0, an `iptables` mangle rule for checksumming SCTP was only added if environment variable `DOCKER_IPTABLES_SCTP_CHECKSUM=1` was set. The rule has now been removed, the environment variable now has no effect. [moby/moby#50539](https://github.com/moby/moby/pull/50539)
+- The iptables rules for bridge networks have been updated, including removal of the `DOCKER-ISOLATION-STAGE-1` and `DOCKER-ISOLATION-STAGE-2` chains. With these changes:. [moby/moby#49981](https://github.com/moby/moby/pull/49981)
+  - Containers can now access ports published to host addresses by containers in other networks when the userland-proxy is not running
+  - Containers can now access ports on container addresses in other networks that have gateway mode "nat-unprotected"
+- When dynamically linked, the Docker daemon now depends on libnftables. [moby/moby#51033](https://github.com/moby/moby/pull/51033)
+- Windows: `network inspect`: the HNS network name is now reported in option `com.docker.network.windowsshim.networkname` rather than the Docker network name, which was only reported after a daemon restart. [moby/moby#50961](https://github.com/moby/moby/pull/50961)
+- Windows: when restoring networks on daemon restart, preserve their association with non-default IPAM drivers. [moby/moby#50649](https://github.com/moby/moby/pull/50649)
+
+### API
+
+- `events` API now reports content-type as `application/x-ndjson` for newline-delimited JSON event stream. [moby/moby#50953](https://github.com/moby/moby/pull/50953)
+- `GET /images/{name}/get` and `POST /images/load` now accept multiple `platform` query parameters, allowing export and load of images for multiple platforms. [moby/moby#50166](https://github.com/moby/moby/pull/50166)
+- `GET /images/{name}/json` now omits the following fields if their value is empty: `Parent`, `Comment`, `DockerVersion`, `Author`. [moby/moby#51072](https://github.com/moby/moby/pull/51072)
+- `GET /images/{name}/json`: omit empty `Config` fields when not set. [moby/moby#50915](https://github.com/moby/moby/pull/50915)
+- `POST /images/{name:}/push`: remove compatibility with API v1.4 auth-config in body. [moby/moby#50371](https://github.com/moby/moby/pull/50371)
+- Add support for memory swappiness in Swarm services. [moby/moby#51114](https://github.com/moby/moby/pull/51114)
+  - `GET /services` now returns `SwapBytes` and `MemorySwappiness` fields as part of the `Resource` requirements
+  - `GET /services/{id}` now returns `SwapBytes` and `MemorySwappiness` fields as part of the `Resource` requirements
+  - `POST /services/create` now accepts `SwapBytes` and `MemorySwappiness` fields as part of the `Resource` requirements
+  - `POST /services/{id}/update` now accepts `SwapBytes` and `MemorySwappiness` fields as part of the `Resource` requirements
+  - `GET /tasks` now returns `SwapBytes` and `MemorySwappiness` fields as part of the `Resource` requirements
+  - `GET /tasks/{id}` now returns `SwapBytes` and `MemorySwappiness` fields as part of the `Resource` requirements
+- api/types/build: move `CachePruneOptions` type to `client.BuildCachePruneOptions`. [moby/moby#50772](https://github.com/moby/moby/pull/50772)
+- api/types/checkpoint: move checkpoint options to client module. [moby/moby#50905](https://github.com/moby/moby/pull/50905)
+- api/types/container: `OnBuild` will now be omitted if its value is empty or zero. [moby/moby#51154](https://github.com/moby/moby/pull/51154)
+- api/types/container: make the container config `MacAddress` obsolete for v1.52 and onwards. Use network endpoint settings instead. [moby/moby#51189](https://github.com/moby/moby/pull/51189)
+- api/types/container: move `ResizeOptions` type to `ContainerResizeOptions` in the client. [moby/moby#50773](https://github.com/moby/moby/pull/50773)
+- api/types/events: move `ListOptions` type to the client `EventsListOptions`. [moby/moby#50774](https://github.com/moby/moby/pull/50774)
+- api/types/image: move image options out to the client. [moby/moby#50776](https://github.com/moby/moby/pull/50776)
+- api/types/network: move `CreateOptions`, `ConnectOptions` and `DisconnectOptions` to the client module. [moby/moby#50817](https://github.com/moby/moby/pull/50817)
+- api/types/network: move the `ListOptions` and `InspectOptions` types to the client. [moby/moby#50786](https://github.com/moby/moby/pull/50786)
+- api/types/plugin: change `ListResponse` to a non-pointer slice. [moby/moby#51440](https://github.com/moby/moby/pull/51440)
+- api/types/plugin: remove deprecated `Config.DockerVersion`. [moby/moby#51458](https://github.com/moby/moby/pull/51458)
+- api/types/registry: move `SearchOptions` to `ImageSearchOptions` in the client. [moby/moby#50787](https://github.com/moby/moby/pull/50787)
+- api/types/registry: moved `ServiceConfig` legacy field marshaling support into daemon backend. [moby/moby#50826](https://github.com/moby/moby/pull/50826)
+- api/types/registry: moved encode/decode auth config functions into reference utility package. [moby/moby#50785](https://github.com/moby/moby/pull/50785)
+- api/types/storage: add `Storage` type and integrate in container inspect. [moby/moby#50857](https://github.com/moby/moby/pull/50857)
+- api/types/swarm: deprecated and dropped support for `PortConfigProtocol`; use `network.IPProtocol` instead. [moby/moby#51094](https://github.com/moby/moby/pull/51094)
+- api/types/swarm: move option types to the client module. [moby/moby#50794](https://github.com/moby/moby/pull/50794)
+- api/types/swarm: move the `SecretListOptions` type to the client module. [moby/moby#50816](https://github.com/moby/moby/pull/50816)
+- api/types/system: move `DiskUsageOptions` to the client. [moby/moby#50788](https://github.com/moby/moby/pull/50788)
+- api/types/system: move `SecurityOpt` and `DecodeSecurityOptions` to client module. [moby/moby#50825](https://github.com/moby/moby/pull/50825)
+- api/types/volume: change ListResponse.Volumes to a non-pointer slice. [moby/moby#51454](https://github.com/moby/moby/pull/51454)
+- api/types/volume: move the `ListOptions` type to the client module. [moby/moby#50789](https://github.com/moby/moby/pull/50789)
+- api/types/volume: moved `UpdateOptions` into client module. [moby/moby#51205](https://github.com/moby/moby/pull/51205)
+- api/types: daemon: move the disk usage structs to the backend server. [moby/moby#50764](https://github.com/moby/moby/pull/50764)
+- api: make `GraphDriver` field in `image.InspectResponse` optional. This field will continue to be emitted when using the legacy graph drivers and will be omitted when using the containerd image backend. [moby/moby#50893](https://github.com/moby/moby/pull/50893)
+- api: redefine container network port types. [moby/moby#50710](https://github.com/moby/moby/pull/50710)
+- client: PluginListResult: change Items field to a non-pointer slice. [moby/moby#51440](https://github.com/moby/moby/pull/51440)
+- Inspecting networks with API v1.52 and newer provides statistics about IPAM allocations for the subnets assigned to the network. [moby/moby#50917](https://github.com/moby/moby/pull/50917)
+- MAC address fields are represented as byte slices compatible with the standard library net.HardwareAddr type instead of strings. [moby/moby#51355](https://github.com/moby/moby/pull/51355)
+- Swagger definitions for `NetworkSummary` and `NetworkInspect` have been added to the Swagger spec describing the Engine API. [moby/moby#50855](https://github.com/moby/moby/pull/50855)
+- Update API version to 1.52. [moby/moby#50418](https://github.com/moby/moby/pull/50418)
+
+### Go SDK
+
+- `api/pkg/progress` and `api/pkg/streamformatter` have been removed. [moby/moby#51153](https://github.com/moby/moby/pull/51153)
+- `api/types/registry`: `EncodeAuthConfig`: use empty string for zero value. [moby/moby#50426](https://github.com/moby/moby/pull/50426)
+- `api/types/versions` has moved to the client and daemon. [moby/moby#51284](https://github.com/moby/moby/pull/51284)
+- `client.ConfigCreate`, `client.ConfigList`, `client.ConfigInspectWithRaw`, `client.ConfigUpdate`, and `client.ConfigRemove` methods now accept option structs instead of positional arguments, and return dedicated result structs. [moby/moby#51078](https://github.com/moby/moby/pull/51078)
+- `client.ImageBuild`, `client.BuildCancel`, `client.ImageList`, `client.ImageRemove`, `client.ImageTag`, and `client.ImageSearch` methods now accept option structs instead of positional arguments, and return dedicated result structs. [moby/moby#51227](https://github.com/moby/moby/pull/51227)
+- `client`: `ContainerExec...` methods were renamed to `Exec...`. [moby/moby#51262](https://github.com/moby/moby/pull/51262)
+- `client`: Wrap return values of `ImageInspect`, `ImageHistory`, `ImageLoad` and `ImageSave` in a struct. [moby/moby#51236](https://github.com/moby/moby/pull/51236)
+- `ImagePull` now returns an object with `JSONMessages` method returning iterator over the message objects. [moby/moby#50935](https://github.com/moby/moby/pull/50935)
+- `ImagePush` now returns an object with `JSONMessages` method returning iterator over the message objects. [moby/moby#51148](https://github.com/moby/moby/pull/51148)
+- api/types/container: move `StatsResponseReader` to `client` package. [moby/moby#50521](https://github.com/moby/moby/pull/50521)
+- api/types/container: move container options to client. [moby/moby#50897](https://github.com/moby/moby/pull/50897)
+- api/types/container: rename `Port` to `PortSummary`. [moby/moby#50711](https://github.com/moby/moby/pull/50711)
+- api/types/container: StatsResponse: add `OSType` field. [moby/moby#51305](https://github.com/moby/moby/pull/51305)
+- api/types: move `ErrorResponse` to `common/ErrorResponse`. [moby/moby#50632](https://github.com/moby/moby/pull/50632)
+- api: remove unused `DefaultVersion`, `MinSupportedAPIVersion` consts. [moby/moby#50587](https://github.com/moby/moby/pull/50587)
+- cli/command: add `WithUserAgent` option. [docker/cli#4574](https://github.com/docker/cli/pull/4574)
+- client: `ContainerCommitOptions`: remove `Pause` field in favor of `NoPause`. [moby/moby#51019](https://github.com/moby/moby/pull/51019)
+- client: add `DefaultAPIVersion` const, which defines the default (and maximum) API version supported by the client. [moby/moby#50433](https://github.com/moby/moby/pull/50433)
+- client: add `ExecAPIClient` interface for exec methods provided by the client. [moby/moby#50997](https://github.com/moby/moby/pull/50997)
+- client: Client.PluginList: add options-struct. [moby/moby#51207](https://github.com/moby/moby/pull/51207)
+- client: ContainersPrune: rewrite to use option structs and result. [moby/moby#51200](https://github.com/moby/moby/pull/51200)
+- client: ImagesPrune: rewrite to use option structs and result. [moby/moby#51200](https://github.com/moby/moby/pull/51200)
+- client: NetworksPrune: rewrite to use option structs and result. [moby/moby#51200](https://github.com/moby/moby/pull/51200)
+- client: remove `client.ContainerStatsResult.OSType` field. [moby/moby#51305](https://github.com/moby/moby/pull/51305)
+- client: VolumesPrune: rewrite to use option structs and result. [moby/moby#51200](https://github.com/moby/moby/pull/51200)
+- daemon/config: add `DefaultAPIVersion` const, which defines the default (and maximum) API version supported by the daemon. [moby/moby#50436](https://github.com/moby/moby/pull/50436)
+- Fix data race in `ContainerExecStart`, `ContainerList`, and `Events`. [moby/moby#50448](https://github.com/moby/moby/pull/50448)
+- IP addresses and subnets are now of type `netip.Addr` and `netip.Prefix`, respectively. [moby/moby#50956](https://github.com/moby/moby/pull/50956)
+- Remove structs `NetworkSettingsBase` and `DefaultNetworkSettings`. Fields in `NetworkSettingsBase` that were not deprecated are now directly in `NetworkSettings`. [moby/moby#50846](https://github.com/moby/moby/pull/50846)
+- the client now uses its own `client.Filters` type for filtering API requests, with a more ergonomic interface. Users of the `github.com/docker/docker/api/types/filters` package will need to refactor when they upgrade to the v29 client. [moby/moby#51115](https://github.com/moby/moby/pull/51115)
+- Types `"github.com/moby/moby/api/types/network".Summary` and `"github.com/moby/moby/api/types/network".Inspect` are no longer aliases, and most of their fields have been moved into an embedded struct. Engine API clients may require some source-level changes when migrating to the new github.com/moby/moby/api module. [moby/moby#50878](https://github.com/moby/moby/pull/50878)
+- Update minimum Go version to 1.24. [docker/cli#6624](https://github.com/docker/cli/pull/6624)
+
+### Deprecations
+
+- `client/pkg/jsonmessage`: remove deprecated `ProgressMessage`, `ErrorMessage`, `DisplayJSONMessagesToStream` and `Stream` interface. [moby/moby#49264](https://github.com/moby/moby/pull/49264)
+- `GET /events` no longer includes the deprecated `status`, `id`, and `from` fields. These fields were removed in API v1.22, but still included in the response. These fields are now omitted when using API v1.52 or later. [moby/moby#50832](https://github.com/moby/moby/pull/50832)
+- api/types/network: CreateRequest: remove deprecated CheckDuplicate field. [moby/moby#50998](https://github.com/moby/moby/pull/50998)
+- api/types/plugin: deprecate `Config.DockerVersion` field. [moby/moby#51109](https://github.com/moby/moby/pull/51109)
+- api/types/registry: remove deprecated AuthConfig.Email field. [moby/moby#51059](https://github.com/moby/moby/pull/51059)
+- api/types/strslice: deprecate StrSlice in favor of using a regular `[]string`. [moby/moby#50292](https://github.com/moby/moby/pull/50292)
+- api/types/system: remove deprecated `DiskUsage.BuilderSize`. [moby/moby#51180](https://github.com/moby/moby/pull/51180)
+- api/types: move plugin types to api/types/plugin. [moby/moby#48114](https://github.com/moby/moby/pull/48114)
+- API: Deprecation: the Engine was automatically backfilling empty `PortBindings` lists with a PortBinding with an empty HostIP and HostPort when starting a container. This behavior is deprecated for API 1.52, and will be dropped in API 1.53. [moby/moby#50874](https://github.com/moby/moby/pull/50874)
+- build: remove DCT support for classic builder. [docker/cli#6195](https://github.com/docker/cli/pull/6195)
+- cli/command: Remove deprecated `ResolveDefaultContext`. [docker/cli#6555](https://github.com/docker/cli/pull/6555)
+- client: ImageBuildResponse: remove OSType field. [moby/moby#50995](https://github.com/moby/moby/pull/50995)
+- client: Remove `ImageCreate` method - use`ImagePull` or `ImageImport` instead. [moby/moby#51366](https://github.com/moby/moby/pull/51366)
+- client: remove deprecated `ImageListOptions.ContainerCount`. [moby/moby#51006](https://github.com/moby/moby/pull/51006)
+- client: remove support for negotiating API version < v1.44 (docker 25.0). [moby/moby#51119](https://github.com/moby/moby/pull/51119)
+- client: remove unused `Client.HTTPClient()` method. [moby/moby#51011](https://github.com/moby/moby/pull/51011)
+- daemon/graphdriver: remove deprecated `GetDriver()`. [moby/moby#50377](https://github.com/moby/moby/pull/50377)
+- daemon: raise minimum API version to v1.44. [moby/moby#51186](https://github.com/moby/moby/pull/51186)
+- Deprecate the `--pause` flag on `docker commit` in favor of `--no-pause`. [docker/cli#6460](https://github.com/docker/cli/pull/6460)
+- Deprecate cgroup v1. [moby/moby#51360](https://github.com/moby/moby/pull/51360), [docker/cli#6598](https://github.com/docker/cli/pull/6598)
+- Go SDK: `cli-plugins/manager`: deprecate metadata aliases in favor of their equivalent in `cli-plugins/manager/metadata`. [docker/cli#6237](https://github.com/docker/cli/pull/6237)
+- Go SDK: `cli-plugins/manager`: remove `Candidate` interface, which was only for internal use. [docker/cli#6237](https://github.com/docker/cli/pull/6237)
+- Go SDK: `cli-plugins/manager`: remove `NewPluginError` function, which was only for internal use. [docker/cli#6237](https://github.com/docker/cli/pull/6237)
+- Go SDK: `cli-plugins/manager`: remove deprecated `ResourceAttributesEnvvar` const. [docker/cli#6237](https://github.com/docker/cli/pull/6237)
+- Go SDK: `cli/command`: remove the `ErrPromptTerminated`, `DisableInputEcho`, `PromptForInput`, and `PromptForConfirmation` utilities. These utilities were for internal use and are no longer used. [docker/cli#6243](https://github.com/docker/cli/pull/6243)
+- Go SDK: `cli/registry/client`: remove deprecated `RepoNameForReference`. [docker/cli#6206](https://github.com/docker/cli/pull/6206)
+- Go SDK: api/types/build: remove deprecated BuildCache.Parent field. [moby/moby#51185](https://github.com/moby/moby/pull/51185)
+- Go SDK: api/types/container: remove deprecated `ContainerTopOKBody` alias. [moby/moby#50400](https://github.com/moby/moby/pull/50400)
+- Go SDK: api/types/container: remove deprecated `ContainerUpdateOKBody` alias. [moby/moby#50400](https://github.com/moby/moby/pull/50400)
+- Go SDK: api/types/container: remove deprecated `Stats` type. [moby/moby#50492](https://github.com/moby/moby/pull/50492)
+- Go SDK: api/types/filters: remove deprecated `ToParamWithVersion`. [moby/moby#50561](https://github.com/moby/moby/pull/50561)
+- Go SDK: api/types/image: `InspectResponse`: remove deprecated `VirtualSize`, `Container`, `ContainerConfig`, `Parent`, and `DockerVersion` fields. [moby/moby#51103](https://github.com/moby/moby/pull/51103)
+- Go SDK: api/types/image: remove deprecated Summary.VirtualSize field. [moby/moby#51190](https://github.com/moby/moby/pull/51190)
+- Go SDK: api/types/registry: remove deprecated `ServiceConfig.AllowNondistributableArtifactsCIDRs` and `ServiceConfig.AllowNondistributableArtifactsHostnames` fields. [moby/moby#50375](https://github.com/moby/moby/pull/50375)
+- Go SDK: api/types/swarm: remove deprecated ServiceSpec.Networks field. [moby/moby#51184](https://github.com/moby/moby/pull/51184)
+- GO SDK: api/types/system: remove deprecated `Commit.Expected` field. [moby/moby#51127](https://github.com/moby/moby/pull/51127)
+- Go SDK: api/types: remove deprecated aliases. [moby/moby#50452](https://github.com/moby/moby/pull/50452)
+- Go SDK: api: deprecate `NoBaseImageSpecifier` const. This const is no longer used and will be removed in the next release. [moby/moby#50437](https://github.com/moby/moby/pull/50437)
+- Go SDK: api: remove `NoBaseImageSpecifier`. [moby/moby#50574](https://github.com/moby/moby/pull/50574)
+- Go SDK: cli/command/builder: remove `CachePrune()`, which was no longer used. [docker/cli#6236](https://github.com/docker/cli/pull/6236)
+- Go SDK: cli/command/builder: remove `NewBuilderCommand` and `NewBakeStubCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/checkpoint: remove `NewCheckpointCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/checkpoint: remove deprecated `NewFormat`, `FormatWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/completion: remove deprecated `NoComplete`. [docker/cli#6408](https://github.com/docker/cli/pull/6408)
+- Go SDK: cli/command/config: remove `NewConfigCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/config: remove deprecated `NewFormat`, `FormatWrite`, `InspectFormatWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/config: remove deprecated `RunConfigCreate`, `CreateOptions`, `RunConfigInspect`, `InspectOptions`, `RunConfigList`, `ListOptions`, `RunConfigRemove`, and `RemoveOptions`. [docker/cli#6370](https://github.com/docker/cli/pull/6370)
+- Go SDK: cli/command/container: deprecate `NewDiffFormat`, `DiffFormatWrite`. These functions were only used internally and will be removed in the next release. [docker/cli#6187](https://github.com/docker/cli/pull/6187)
+- Go SDK: cli/command/container: remove `NewBuildCommand`, `NewPullCommand`, `NewPushCommand`, `NewImagesCommand`, `NewImageCommand`, `NewHistoryCommand`, `NewImportCommand`, `NewLoadCommand`, `NewRemoveCommand`, `NewSaveCommand`, `NewTagCommand`, `NewPruneCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/container: remove `NewRunCommand`, `NewExecCommand`, `NewPsCommand`, `NewContainerCommand`, `NewAttachCommand`, `NewCommitCommand`, `NewCopyCommand`, `NewCreateCommand`, `NewDiffCommand`, `NewExportCommand`, `NewKillCommand`, `NewLogsCommand`, `NewPauseCommand`, `NewPortCommand`, `NewRenameCommand`, `NewRestartCommand`, `NewRmCommand`, `NewStartCommand`, `NewStatsCommand`, `NewStopCommand`, `NewTopCommand`, `NewUnpauseCommand`, `NewUpdateCommand`, `NewWaitCommand`, `NewPruneCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/container: remove `RunPrune()`, which was no longer used. [docker/cli#6236](https://github.com/docker/cli/pull/6236)
+- Go SDK: cli/command/container: remove deprecated `NewDiffFormat`, `DiffFormatWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/context: remove `NewContextCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/context: remove deprecated `RunCreate` and `CreateOptions`. [docker/cli#6407](https://github.com/docker/cli/pull/6407)
+- Go SDK: cli/command/context: remove deprecated `RunExport` and `ExportOptions`. [docker/cli#6407](https://github.com/docker/cli/pull/6407)
+- Go SDK: cli/command/context: remove deprecated `RunImport`. [docker/cli#6407](https://github.com/docker/cli/pull/6407)
+- Go SDK: cli/command/context: remove deprecated `RunRemove` and `RemoveOptions`. [docker/cli#6407](https://github.com/docker/cli/pull/6407)
+- Go SDK: cli/command/context: remove deprecated `RunUpdate` and `UpdateOptions`. [docker/cli#6407](https://github.com/docker/cli/pull/6407)
+- Go SDK: cli/command/context: remove deprecated `RunUse`. [docker/cli#6407](https://github.com/docker/cli/pull/6407)
+- Go SDK: cli/command/formatter/swarm: remove deprecated `GetStacks` function. [docker/cli#6406](https://github.com/docker/cli/pull/6406)
+- Go SDK: cli/command/image/build: deprecate `DefaultDockerfileName`, `DetectArchiveReader`, `WriteTempDockerfile`, `ResolveAndValidateContextPath`. These utilities were only used internally and will be removed in the next release. [docker/cli#6561](https://github.com/docker/cli/pull/6561)
+- Go SDK: cli/command/image: remove `RunPrune()`, which was no longer used. [docker/cli#6236](https://github.com/docker/cli/pull/6236)
+- Go SDK: cli/command/image: remove deprecated `AuthResolver` utility. [docker/cli#6373](https://github.com/docker/cli/pull/6373)
+- Go SDK: cli/command/image: remove deprecated `NewHistoryFormat`, `HistoryWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339), [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/manifest: remove `NewManifestCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/network: remove `NewNetworkCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/network: remove `RunPrune()`, which was no longer used. [docker/cli#6236](https://github.com/docker/cli/pull/6236)
+- Go SDK: cli/command/network: remove deprecated `NewFormat`, `FormatWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/node: remove `NewNodeCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/node: remove deprecated `NewFormat`, `FormatWrite`, `InspectFormatWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/plugin: remove `NewPluginCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/plugin: remove deprecated `NewFormat`, `FormatWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/registry: remove `NewLoginCommand`, `NewLogoutCommand`, `NewSearchCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/registry: remove deprecated `NewSearchFormat`, `SearchWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/registry: remove deprecated `OauthLoginEscapeHatchEnvVar` const. [docker/cli#6463](https://github.com/docker/cli/pull/6463)
+- Go SDK: cli/command/secret: remove `NewSecretCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/secret: remove deprecated `NewFormat`, `FormatWrite`, `InspectFormatWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/service: remove `NewServiceCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/service: remove deprecated `NewFormat`, `InspectFormatWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/stack/swarm: remove deprecated RunPS and options.PS. [docker/cli#6398](https://github.com/docker/cli/pull/6398)
+- Go SDK: cli/command/stack: remove `NewStackCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/stack: remove deprecated RunList and options.List. [docker/cli#6398](https://github.com/docker/cli/pull/6398)
+- Go SDK: cli/command/stack: remove deprecated RunServices and swarm.GetServices. [docker/cli#6398](https://github.com/docker/cli/pull/6398)
+- Go SDK: cli/command/swarm: remove `NewSwarmCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/system: remove `NewVersionCommand`, `NewInfoCommand`, `NewSystemCommand`, `NewEventsCommand`, `NewInspectCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/task: remove deprecated `NewTaskFormat`, `FormatWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/trust: remove `NewTrustCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/trust: remove deprecated `NewPruneCommand`. [docker/cli#6344](https://github.com/docker/cli/pull/6344)
+- Go SDK: cli/command/trust: remove deprecated `SignedTagInfo`, `SignerInfo`, `NewTrustTagFormat`, `NewSignerInfoFormat`, `TagWrite`, `SignerInfoWrite`. [docker/cli#6339](https://github.com/docker/cli/pull/6339)
+- Go SDK: cli/command/volume: remove `NewVolumeCommand`, `NewPruneCommand`. [docker/cli#6335](https://github.com/docker/cli/pull/6335)
+- Go SDK: cli/command/volume: remove `RunPrune()`, which was no longer used. [docker/cli#6236](https://github.com/docker/cli/pull/6236)
+- Go SDK: cli/command: remove `AddTrustSigningFlags`, `AddTrustVerificationFlags`, and `AddPlatformFlag` utilities, which were only used internally. [docker/cli#6244](https://github.com/docker/cli/pull/6244)
+- Go SDK: cli/command: remove deprecated `DockerCli.Apply`. [docker/cli#6503](https://github.com/docker/cli/pull/6503)
+- Go SDK: cli/command: remove deprecated `DockerCli.ContentTrustEnabled`. [docker/cli#6502](https://github.com/docker/cli/pull/6502)
+- Go SDK: cli/command: remove deprecated `DockerCli.DefaultVersion`. [docker/cli#6502](https://github.com/docker/cli/pull/6502)
+- Go SDK: cli/command: remove deprecated `RegistryAuthenticationPrivilegedFunc`. [docker/cli#6349](https://github.com/docker/cli/pull/6349)
+- Go SDK: cli/command: remove deprecated `WithContentTrustFromEnv`, `WithContentTrust` options. [docker/cli#6502](https://github.com/docker/cli/pull/6502)
+- Go SDK: cli/config/configfile: remove deprecated `ConfigFile.Experimental` field. [docker/cli#6464](https://github.com/docker/cli/pull/6464)
+- Go SDK: cli/config/types: remove deprecated `AuthConfig.Email` field. [docker/cli#6515](https://github.com/docker/cli/pull/6515)
+- Go SDK: cli/manifest/store: remove deprecated `IsNotFound`. [docker/cli#6523](https://github.com/docker/cli/pull/6523)
+- Go SDK: cli: remove deprecated `VisitAll`, `DisableFlagsInUseLine` utilities. [docker/cli#6296](https://github.com/docker/cli/pull/6296)
+- Go SDK: client: remove `APIClient.ImageInspectWithRaw` from the `APIClient` interface. [moby/moby#50485](https://github.com/moby/moby/pull/50485)
+- Go SDK: client: remove `ImageAPIClient.ImageInspectWithRaw` from the `ImageAPIClient` interface. [moby/moby#50485](https://github.com/moby/moby/pull/50485)
+- Go SDK: client: remove `ImageAPIClientDeprecated.ImageInspectWithRaw` from the `ImageAPIClientDeprecated`. [moby/moby#50485](https://github.com/moby/moby/pull/50485)
+- Go SDK: client: remove deprecated `ErrorConnectionFailed` and `IsErrNotFound` functions. [moby/moby#50485](https://github.com/moby/moby/pull/50485)
+- Go SDK: client: remove deprecated `NewClient` and `NewEnvClient` functions. [moby/moby#50485](https://github.com/moby/moby/pull/50485)
+- Go SDK: client: remove the `CommonAPIClient` interface. [moby/moby#50485](https://github.com/moby/moby/pull/50485)
+- Go SDK: client: remove the `ImageAPIClientDeprecated` interface. [moby/moby#50485](https://github.com/moby/moby/pull/50485)
+- Go SDK: client: remove the deprecated `Client.ImageInspectWithRaw` method. [moby/moby#50485](https://github.com/moby/moby/pull/50485)
+- Go SDK: container: remove deprecated `IsValidHealthString`. [moby/moby#50378](https://github.com/moby/moby/pull/50378)
+- Go SDK: container: remove deprecated `IsValidStateString`. [moby/moby#50378](https://github.com/moby/moby/pull/50378)
+- Go SDK: container: remove deprecated `StateStatus`, `WaitCondition`, and the related `WaitConditionNotRunning`, `WaitConditionNextExit`, and `WaitConditionRemoved` consts. [moby/moby#50378](https://github.com/moby/moby/pull/50378)
+- Go SDK: deprecate `pkg/stdcopy`, which was moved to `api/pkg/stdcopy`. [moby/moby#50462](https://github.com/moby/moby/pull/50462)
+- Go SDK: Deprecate field `NetworkSettingsBase.Bridge`, struct `NetworkSettingsBase`, all the fields of `DefaultNetworkSettings`, and struct `DefaultNetworkSettings`. [moby/moby#50848](https://github.com/moby/moby/pull/50848)
+- Go SDK: deprecate pkg/stringid in favour of `github.com/moby/moby/client/pkg/stringid`. [moby/moby#50504](https://github.com/moby/moby/pull/50504)
+- Go SDK: deprecate profiles package which got migrated to `github.com/moby/profiles`. [moby/moby#50481](https://github.com/moby/moby/pull/50481)
+- Go SDK: oci: deprecate SetCapabilities, and some minor cleanups/fixes. [moby/moby#50461](https://github.com/moby/moby/pull/50461)
+- Go SDK: opts: remove deprecated `ListOpts.GetAll`. It's no longer used and replaced by `ListOpts.GetSlice`. [docker/cli#6293](https://github.com/docker/cli/pull/6293)
+- Go SDK: opts: remove deprecated `NewNamedListOptsRef`, `NewNamedMapOpts`, `NamedListOpts`, `NamedMapOpts`, and `NamedOption`. These types and functions are no longer used and will be removed in the next release. [docker/cli#6293](https://github.com/docker/cli/pull/6293)
+- Go SDK: opts: remove deprecated `ParseEnvFile` in favour of `kvfile.Parse`. [docker/cli#6382](https://github.com/docker/cli/pull/6382)
+- Go SDK: opts: remove deprecated `QuotedString`. [docker/cli#6293](https://github.com/docker/cli/pull/6293)
+- Go SDK: opts: remove deprecated `ValidateHost`. [docker/cli#6293](https://github.com/docker/cli/pull/6293)
+- Go SDK: pkg/system was removed, and is now an internal package. [moby/moby#50559](https://github.com/moby/moby/pull/50559)
+- Go SDK: pkg/system: deprecate `EscapeArgs()` and `IsAbs`. These functions were only used internally and will be removed in the next release. [moby/moby#50399](https://github.com/moby/moby/pull/50399)
+- Go SDK: registry: remove deprecated `APIEndpoint.TrimHostName`, `APIEndpoint.Official`, and `APIEndpoint.AllowNondistributableArtifacts` fields. [moby/moby#50376](https://github.com/moby/moby/pull/50376)
+- Go SDK: registry: remove deprecated `HostCertsDir()` and `SetCertsDir()` functions. [moby/moby#50373](https://github.com/moby/moby/pull/50373)
+- Go SDK: registry: remove deprecated `RepositoryInfo.Official` and `RepositoryInfo.Class` field. [moby/moby#50498](https://github.com/moby/moby/pull/50498)
+- Go SDK: registry: remove deprecated `Service.ResolveRepository()`. [moby/moby#50374](https://github.com/moby/moby/pull/50374)
+- Go SDK: Remove `buildkit.ClientOpts`. [moby/moby#50318](https://github.com/moby/moby/pull/50318)
+- Go SDK: remove `pkg/fileutils`. [moby/moby#50558](https://github.com/moby/moby/pull/50558)
+- Go SDK: Remove deprecated `IsNotFound`, `CommandAnnotationPlugin`, `CommandAnnotationPluginVendor`, `CommandAnnotationPluginVersion`, `CommandAnnotationPluginInvalid`, `CommandAnnotationPluginCommandPath`, `NamePrefix`, `MetadataSubcommandName`, `HookSubcommandName`, `Metadata`, and `ReexecEnvvar` from `cli-plugins/manager` in favor of their `cli-plugins/manager/metadata` equivalents. [docker/cli#6414](https://github.com/docker/cli/pull/6414)
+- Go SDK: remove deprecated `types/plugins/logdriver` and `types/swarm/runtime` packages; plugin-runtime spec is now exposed as `types/swarm.RuntimeSpec` and `types/swarm.RuntimePrivilege`. [moby/moby#50554](https://github.com/moby/moby/pull/50554)
+- Go SDK: remove deprecated `cli/command/formatter` package. [docker/cli#6406](https://github.com/docker/cli/pull/6406)
+- Go SDK: remove deprecated `cli/registry/client` package. [docker/cli#6462](https://github.com/docker/cli/pull/6462)
+- Go SDK: remove deprecated `pkg/idtools` package. [moby/moby#50456](https://github.com/moby/moby/pull/50456)
+- Go SDK: templates: remove deprecated `NewParse` function. [docker/cli#6453](https://github.com/docker/cli/pull/6453)
+- Hide the `--kernel-memory` option on `docker run` and `docker create`, and produce a warning when used as it's no longer supported by the daemon and kernel. [docker/cli#6455](https://github.com/docker/cli/pull/6455)
+- Remove `VirtualSize` field from `docker image ls` output when using JSON format. [docker/cli#6524](https://github.com/docker/cli/pull/6524)
+- Remove `VirtualSize` formatting options and output. [docker/cli#6524](https://github.com/docker/cli/pull/6524)
+- Remove API version compatibility for API version < v1.44 (Docker v24.0 and older). [docker/cli#6551](https://github.com/docker/cli/pull/6551)
+- Remove deprecated `bind-nonrecursive` option for `--mount`. [docker/cli#6241](https://github.com/docker/cli/pull/6241)
+- Remove deprecated packages (`pkg/archive`, `pkg/chrootarchive`, `pkg/atomicwriter`, `pkg/reexec`, `pkg/platform`, `pkg/parsers`), `pkg/system.MkdirAll`. For replacements, see `github.com/moby/go-archive`, `github.com/moby/sys` and the standard library. [moby/moby#50208](https://github.com/moby/moby/pull/50208)
+- Remove special handling for quoted values for the `--tlscacert`, `--tlscert`, and `--tlskey` command-line flags. [docker/cli#6306](https://github.com/docker/cli/pull/6306)
+- Remove support for AutoRemove (`--rm`) on API < 1.30. [docker/cli#6525](https://github.com/docker/cli/pull/6525)
+- Remove support for loading legacy (pre-Docker 1.10) images. [moby/moby#50324](https://github.com/moby/moby/pull/50324)
diff --git a/content/manuals/engine/release-notes/prior-releases.md b/content/manuals/engine/release-notes/prior-releases.md
index ffe5dac7966e..68a53b1ec048 100644
--- a/content/manuals/engine/release-notes/prior-releases.md
+++ b/content/manuals/engine/release-notes/prior-releases.md
@@ -328,7 +328,7 @@ If you are currently using the `--ipv6` option _without_ specifying the
 `--fixed-cidr-v6` option, the Docker daemon will refuse to start with the
 following message:
 
-```none
+```text
 Error starting daemon: Error initializing network controller: Error creating
                        default "bridge" network: failed to parse pool request
                        for address space "LocalDefault" pool " subpool ":
@@ -344,7 +344,7 @@ In a similar way, if you specify the `--ipv6` flag when creating a network
 with the default IPAM driver, without providing an IPv6 `--subnet`, network
 creation will fail with the following message:
 
-```none
+```text
 Error response from daemon: failed to parse pool request for address space
                             "LocalDefault" pool "" subpool "": could not find an
                             available, non-overlapping IPv6 address pool among
@@ -397,7 +397,7 @@ If you are currently using the `--ipv6` option _without_ specifying the
 `--fixed-cidr-v6` option, the Docker daemon will refuse to start with the
 following message:
 
-```none
+```text
 Error starting daemon: Error initializing network controller: Error creating
                        default "bridge" network: failed to parse pool request
                        for address space "LocalDefault" pool " subpool ":
@@ -413,7 +413,7 @@ In a similar way, if you specify the `--ipv6` flag when creating a network
 with the default IPAM driver, without providing an IPv6 `--subnet`, network
 creation will fail with the following message:
 
-```none
+```text
 Error response from daemon: failed to parse pool request for address space
                             "LocalDefault" pool "" subpool "": could not find an
                             available, non-overlapping IPv6 address pool among
@@ -1041,7 +1041,7 @@ additional binaries; `dockerd`, and `docker-proxy`. If you have scripts for inst
 * Support for AAAA Records (aka IPv6 Service Discovery) in embedded DNS Server ([#21396](https://github.com/docker/docker/pull/21396))
 - Fix to not forward docker domain IPv6 queries to external servers ([#21396](https://github.com/docker/docker/pull/21396))
 * Multiple A/AAAA records from embedded DNS Server for DNS Round robin ([#21019](https://github.com/docker/docker/pull/21019))
-- Fix endpoint count inconsistency after an ungraceful dameon restart ([#21261](https://github.com/docker/docker/pull/21261))
+- Fix endpoint count inconsistency after an ungraceful daemon restart ([#21261](https://github.com/docker/docker/pull/21261))
 - Move the ownership of exposed ports and port-mapping options from Endpoint to Sandbox ([#21019](https://github.com/docker/docker/pull/21019))
 - Fixed a bug which prevents docker reload when host is configured with ipv6.disable=1 ([#21019](https://github.com/docker/docker/pull/21019))
 - Added inbuilt nil IPAM driver ([#21019](https://github.com/docker/docker/pull/21019))
diff --git a/content/manuals/engine/security/_index.md b/content/manuals/engine/security/_index.md
index 0929142d8176..2c949d2ffd9e 100644
--- a/content/manuals/engine/security/_index.md
+++ b/content/manuals/engine/security/_index.md
@@ -194,7 +194,7 @@ to the host.
 This doesn't affect regular web apps, but reduces the vectors of attack by
 malicious users considerably. By default Docker
 drops all capabilities except [those
-needed](https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19),
+needed](https://github.com/moby/moby/blob/master/daemon/pkg/oci/caps/defaults.go#L6-L19),
 an allowlist instead of a denylist approach. You can see a full list of
 available capabilities in [Linux
 manpages](https://man7.org/linux/man-pages/man7/capabilities.7.html).
diff --git a/content/manuals/engine/security/apparmor.md b/content/manuals/engine/security/apparmor.md
index f56bf9abad23..8b6b1e0433dd 100644
--- a/content/manuals/engine/security/apparmor.md
+++ b/content/manuals/engine/security/apparmor.md
@@ -28,7 +28,7 @@ in the Docker Engine source repository.
 The `docker-default` profile is the default for running containers. It is
 moderately protective while providing wide application compatibility. The
 profile is generated from the following
-[template](https://github.com/moby/moby/blob/master/profiles/apparmor/template.go).
+[template](https://github.com/moby/profiles/blob/main/apparmor/template.go).
 
 When you run a container, it uses the `docker-default` policy unless you
 override it with the `security-opt` option. For example, the following
@@ -280,4 +280,4 @@ Advanced users and package managers can find a profile for `/usr/bin/docker`
 in the Docker Engine source repository.
 
 The `docker-default` profile for containers lives in
-[profiles/apparmor](https://github.com/moby/moby/tree/master/profiles/apparmor).
+[profiles/apparmor](https://github.com/moby/profiles/blob/main/apparmor).
diff --git a/content/manuals/engine/security/certificates.md b/content/manuals/engine/security/certificates.md
index c55596f37738..43bc434d0c5e 100644
--- a/content/manuals/engine/security/certificates.md
+++ b/content/manuals/engine/security/certificates.md
@@ -21,10 +21,26 @@ for the registry and how to set the client TLS certificate for verification.
 
 ## Understand the configuration
 
-A custom certificate is configured by creating a directory under
-`/etc/docker/certs.d` using the same name as the registry's hostname, such as
+A custom certificate is configured by creating a directory under the daemon's
+certificate root using the same name as the registry's hostname, such as
 `localhost`. All `*.crt` files are added to this directory as CA roots.
 
+Where that certificate root lives depends on the platform:
+
+- Native Linux Engine: `/etc/docker/certs.d/`
+- Rootless Linux: `$XDG_CONFIG_HOME/docker/certs.d` (defaults to
+  `~/.config/docker/certs.d`), not `/etc/docker/certs.d`
+- Native Windows Engine (Windows containers):
+  `%PROGRAMDATA%\docker\certs.d` (normally `C:\ProgramData\docker\certs.d`).
+  If the registry address includes a port, strip the colon from the directory
+  name because Windows filenames cannot contain `:`. For example,
+  `registry.example.com:5000` becomes `registry.example.com5000`.
+- Docker Desktop with Linux containers: put client certificates in
+  `~/.docker/certs.d` on the host. Docker Desktop copies them into the VM;
+  don't configure `/etc/docker/certs.d` inside the VM yourself. Trusted CAs
+  can also come from the host certificate store (on Windows, the Windows
+  certificate store).
+
 > [!NOTE]
 >
 > On Linux any root certificates authorities are merged with the system defaults,
diff --git a/content/manuals/engine/security/https/README.md b/content/manuals/engine/security/https/README.md
index 3ba704938797..ea427151c222 100644
--- a/content/manuals/engine/security/https/README.md
+++ b/content/manuals/engine/security/https/README.md
@@ -1,5 +1,5 @@
 ---
-_build:
+build:
   list: never
   publishResources: false
   render: never
diff --git a/content/manuals/engine/security/rootless.md b/content/manuals/engine/security/rootless.md
deleted file mode 100644
index f267d59f4c52..000000000000
--- a/content/manuals/engine/security/rootless.md
+++ /dev/null
@@ -1,709 +0,0 @@
----
-description: Run the Docker daemon as a non-root user (Rootless mode)
-keywords: security, namespaces, rootless
-title: Rootless mode
-weight: 10
----
-
-Rootless mode allows running the Docker daemon and containers as a non-root
-user to mitigate potential vulnerabilities in the daemon and
-the container runtime.
-
-Rootless mode does not require root privileges even during the installation of
-the Docker daemon, as long as the [prerequisites](#prerequisites) are met.
-
-## How it works
-
-Rootless mode executes the Docker daemon and containers inside a user namespace.
-This is very similar to [`userns-remap` mode](userns-remap.md), except that
-with `userns-remap` mode, the daemon itself is running with root privileges,
-whereas in rootless mode, both the daemon and the container are running without
-root privileges.
-
-Rootless mode does not use binaries with `SETUID` bits or file capabilities,
-except `newuidmap` and `newgidmap`, which are needed to allow multiple
-UIDs/GIDs to be used in the user namespace.
-
-## Prerequisites
-
--  You must install `newuidmap` and `newgidmap` on the host. These commands
-  are provided by the `uidmap` package on most distributions.
-
-- `/etc/subuid` and `/etc/subgid` should contain at least 65,536 subordinate
-  UIDs/GIDs for the user. In the following example, the user `testuser` has
-  65,536 subordinate UIDs/GIDs (231072-296607).
-
-```console
-$ id -u
-1001
-$ whoami
-testuser
-$ grep ^$(whoami): /etc/subuid
-testuser:231072:65536
-$ grep ^$(whoami): /etc/subgid
-testuser:231072:65536
-```
-
-### Distribution-specific hint
-
-> [!TIP]
->
-> We recommend that you use the Ubuntu kernel.
-
-{{< tabs >}}
-{{< tab name="Ubuntu" >}}
-- Install `dbus-user-session` package if not installed. Run `sudo apt-get install -y dbus-user-session` and relogin.
-- Install `uidmap` package if not installed.  Run `sudo apt-get install -y uidmap`.
-- If running in a terminal where the user was not directly logged into, you will need to install `systemd-container` with `sudo apt-get install -y systemd-container`, then switch to TheUser with the command `sudo machinectl shell TheUser@`.
-
-- `overlay2` storage driver  is enabled by default
-  ([Ubuntu-specific kernel patch](https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/commit/fs/overlayfs?id=3b7da90f28fe1ed4b79ef2d994c81efbc58f1144)).
-
-- Ubuntu 24.04 and later enables restricted unprivileged user namespaces by
-  default, which prevents unprivileged processes in creating user namespaces
-  unless an AppArmor profile is configured to allow programs to use
-  unprivileged user namespaces.
-
-  If you install `docker-ce-rootless-extras` using the deb package (`apt-get
-  install docker-ce-rootless-extras`), then the AppArmor profile for
-  `rootlesskit` is already bundled with the `apparmor` deb package. With this
-  installation method, you don't need to add any manual the AppArmor
-  configuration. If you install the rootless extras using the [installation
-  script](https://get.docker.com/rootless), however, you must add an AppArmor
-  profile for `rootlesskit` manually:
-
-  1. Create and install the currently logged-in user's AppArmor profile:
-
-     ```console
-     $ filename=$(echo $HOME/bin/rootlesskit | sed -e s@^/@@ -e s@/@.@g)
-     $ cat <<EOF > ~/${filename}
-     abi <abi/4.0>,
-     include <tunables/global>
-
-     "$HOME/bin/rootlesskit" flags=(unconfined) {
-       userns,
-
-       include if exists <local/${filename}>
-     }
-     EOF
-     $ sudo mv ~/${filename} /etc/apparmor.d/${filename}
-     ```
-  2. Restart AppArmor.
-
-     ```console
-     $ systemctl restart apparmor.service
-     ```
-
-{{< /tab >}}
-{{< tab name="Debian GNU/Linux" >}}
-- Install `dbus-user-session` package if not installed. Run `sudo apt-get install -y dbus-user-session` and relogin.
-
-- For Debian 11, installing `fuse-overlayfs` is recommended. Run `sudo apt-get install -y fuse-overlayfs`.
-  This step is not required on Debian 12.
-
-- Rootless docker requires version of `slirp4netns` greater than `v0.4.0` (when `vpnkit` is not installed).
-  Check you have this with 
-  
-  ```console
-  $ slirp4netns --version
-  ```
-  If you do not have this download and install with `sudo apt-get install -y slirp4netns` or download the latest [release](https://github.com/rootless-containers/slirp4netns/releases).
-{{< /tab >}}
-{{< tab name="Arch Linux" >}}
-- Installing `fuse-overlayfs` is recommended. Run `sudo pacman -S fuse-overlayfs`.
-
-- Add `kernel.unprivileged_userns_clone=1` to `/etc/sysctl.conf` (or
-  `/etc/sysctl.d`) and run `sudo sysctl --system`
-{{< /tab >}}
-{{< tab name="openSUSE and SLES" >}}
-- For openSUSE 15 and SLES 15, Installing `fuse-overlayfs` is recommended. Run `sudo zypper install -y fuse-overlayfs`.
-  This step is not required on openSUSE Tumbleweed.
-
-- `sudo modprobe ip_tables iptable_mangle iptable_nat iptable_filter` is required.
-  This might be required on other distributions as well depending on the configuration.
-
-- Known to work on openSUSE 15 and SLES 15.
-{{< /tab >}}
-{{< tab name="CentOS, RHEL, and Fedora" >}}
-- For RHEL 8 and similar distributions, installing `fuse-overlayfs` is recommended. Run `sudo dnf install -y fuse-overlayfs`.
-  This step is not required on RHEL 9 and similar distributions.
-
-- You might need `sudo dnf install -y iptables`.
-{{< /tab >}}
-{{< /tabs >}}
-
-## Known limitations
-
-- Only the following storage drivers are supported:
-  - `overlay2` (only if running with kernel 5.11 or later, or Ubuntu-flavored kernel)
-  - `fuse-overlayfs` (only if running with kernel 4.18 or later, and `fuse-overlayfs` is installed)
-  - `btrfs` (only if running with kernel 4.18 or later, or `~/.local/share/docker` is mounted with `user_subvol_rm_allowed` mount option)
-  - `vfs`
-- Cgroup is supported only when running with cgroup v2 and systemd. See [Limiting resources](#limiting-resources).
-- Following features are not supported:
-  - AppArmor
-  - Checkpoint
-  - Overlay network
-  - Exposing SCTP ports
-- To use the `ping` command, see [Routing ping packets](#routing-ping-packets).
-- To expose privileged TCP/UDP ports (< 1024), see [Exposing privileged ports](#exposing-privileged-ports).
-- `IPAddress` shown in `docker inspect` is namespaced inside RootlessKit's network namespace.
-  This means the IP address is not reachable from the host without `nsenter`-ing into the network namespace.
-- Host network (`docker run --net=host`) is also namespaced inside RootlessKit.
-- NFS mounts as the docker "data-root" is not supported. This limitation is not specific to rootless mode.
-
-## Install
-
-> [!NOTE]
->
-> If the system-wide Docker daemon is already running, consider disabling it:
->```console
->$ sudo systemctl disable --now docker.service docker.socket
->$ sudo rm /var/run/docker.sock
->```
-> Should you choose not to shut down the `docker` service and socket, you will need to use the `--force`
-> parameter in the next section. There are no known issues, but until you shutdown and disable you're
-> still running rootful Docker. 
-
-{{< tabs >}}
-{{< tab name="With packages (RPM/DEB)" >}}
-
-If you installed Docker 20.10 or later with [RPM/DEB packages](/engine/install), you should have `dockerd-rootless-setuptool.sh` in `/usr/bin`.
-
-Run `dockerd-rootless-setuptool.sh install` as a non-root user to set up the daemon:
-
-```console
-$ dockerd-rootless-setuptool.sh install
-[INFO] Creating /home/testuser/.config/systemd/user/docker.service
-...
-[INFO] Installed docker.service successfully.
-[INFO] To control docker.service, run: `systemctl --user (start|stop|restart) docker.service`
-[INFO] To run docker.service on system startup, run: `sudo loginctl enable-linger testuser`
-
-[INFO] Make sure the following environment variables are set (or add them to ~/.bashrc):
-
-export PATH=/usr/bin:$PATH
-export DOCKER_HOST=unix:///run/user/1000/docker.sock
-```
-
-If `dockerd-rootless-setuptool.sh` is not present, you may need to install the `docker-ce-rootless-extras` package manually, e.g.,
-
-```console
-$ sudo apt-get install -y docker-ce-rootless-extras
-```
-
-{{< /tab >}}
-{{< tab name="Without packages" >}}
-
-If you do not have permission to run package managers like `apt-get` and `dnf`,
-consider using the installation script available at [https://get.docker.com/rootless](https://get.docker.com/rootless).
-Since static packages are not available for `s390x`, hence it is not supported for `s390x`.
-
-```console
-$ curl -fsSL https://get.docker.com/rootless | sh
-...
-[INFO] Creating /home/testuser/.config/systemd/user/docker.service
-...
-[INFO] Installed docker.service successfully.
-[INFO] To control docker.service, run: `systemctl --user (start|stop|restart) docker.service`
-[INFO] To run docker.service on system startup, run: `sudo loginctl enable-linger testuser`
-
-[INFO] Make sure the following environment variables are set (or add them to ~/.bashrc):
-
-export PATH=/home/testuser/bin:$PATH
-export DOCKER_HOST=unix:///run/user/1000/docker.sock
-```
-
-The binaries will be installed at `~/bin`.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-See [Troubleshooting](#troubleshooting) if you faced an error.
-
-## Uninstall
-
-To remove the systemd service of the Docker daemon, run `dockerd-rootless-setuptool.sh uninstall`:
-
-```console
-$ dockerd-rootless-setuptool.sh uninstall
-+ systemctl --user stop docker.service
-+ systemctl --user disable docker.service
-Removed /home/testuser/.config/systemd/user/default.target.wants/docker.service.
-[INFO] Uninstalled docker.service
-[INFO] This uninstallation tool does NOT remove Docker binaries and data.
-[INFO] To remove data, run: `/usr/bin/rootlesskit rm -rf /home/testuser/.local/share/docker`
-```
-
-Unset environment variables PATH and DOCKER_HOST if you have added them to `~/.bashrc`.
-
-To remove the data directory, run `rootlesskit rm -rf ~/.local/share/docker`.
-
-To remove the binaries, remove `docker-ce-rootless-extras` package if you installed Docker with package managers.
-If you installed Docker with https://get.docker.com/rootless ([Install without packages](#install)),
-remove the binary files under `~/bin`:
-```console
-$ cd ~/bin
-$ rm -f containerd containerd-shim containerd-shim-runc-v2 ctr docker docker-init docker-proxy dockerd dockerd-rootless-setuptool.sh dockerd-rootless.sh rootlesskit rootlesskit-docker-proxy runc vpnkit
-```
-
-## Usage
-
-### Daemon
-
-{{< tabs >}}
-{{< tab name="With systemd (Highly recommended)" >}}
-
-The systemd unit file is installed as  `~/.config/systemd/user/docker.service`.
-
-Use `systemctl --user` to manage the lifecycle of the daemon:
-
-```console
-$ systemctl --user start docker
-```
-
-To launch the daemon on system startup, enable the systemd service and lingering:
-
-```console
-$ systemctl --user enable docker
-$ sudo loginctl enable-linger $(whoami)
-```
-
-Starting Rootless Docker as a systemd-wide service (`/etc/systemd/system/docker.service`)
-is not supported, even with the `User=` directive.
-
-{{< /tab >}}
-{{< tab name="Without systemd" >}}
-
-To run the daemon directly without systemd, you need to run `dockerd-rootless.sh` instead of `dockerd`.
-
-The following environment variables must be set:
-- `$HOME`: the home directory
-- `$XDG_RUNTIME_DIR`: an ephemeral directory that is only accessible by the expected user, e,g, `~/.docker/run`.
-  The directory should be removed on every host shutdown.
-  The directory can be on tmpfs, however, should not be under `/tmp`.
-  Locating this directory under `/tmp` might be vulnerable to TOCTOU attack.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-Remarks about directory paths:
-
-- The socket path is set to `$XDG_RUNTIME_DIR/docker.sock` by default.
-  `$XDG_RUNTIME_DIR` is typically set to `/run/user/$UID`.
-- The data dir is set to `~/.local/share/docker` by default.
-  The data dir should not be on NFS.
-- The daemon config dir is set to `~/.config/docker` by default.
-  This directory is different from `~/.docker` that is used by the client.
-
-### Client
-
-You need to specify either the socket path or the CLI context explicitly.
-
-To specify the socket path using `$DOCKER_HOST`:
-
-```console
-$ export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock
-$ docker run -d -p 8080:80 nginx
-```
-
-To specify the CLI context using `docker context`:
-
-```console
-$ docker context use rootless
-rootless
-Current context is now "rootless"
-$ docker run -d -p 8080:80 nginx
-```
-
-## Best practices
-
-### Rootless Docker in Docker
-
-To run Rootless Docker inside "rootful" Docker, use the `docker:<version>-dind-rootless`
-image instead of `docker:<version>-dind`.
-
-```console
-$ docker run -d --name dind-rootless --privileged docker:25.0-dind-rootless
-```
-
-The `docker:<version>-dind-rootless` image runs as a non-root user (UID 1000).
-However, `--privileged` is required for disabling seccomp, AppArmor, and mount
-masks.
-
-### Expose Docker API socket through TCP
-
-To expose the Docker API socket through TCP, you need to launch `dockerd-rootless.sh`
-with `DOCKERD_ROOTLESS_ROOTLESSKIT_FLAGS="-p 0.0.0.0:2376:2376/tcp"`.
-
-```console
-$ DOCKERD_ROOTLESS_ROOTLESSKIT_FLAGS="-p 0.0.0.0:2376:2376/tcp" \
-  dockerd-rootless.sh \
-  -H tcp://0.0.0.0:2376 \
-  --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem
-```
-
-### Expose Docker API socket through SSH
-
-To expose the Docker API socket through SSH, you need to make sure `$DOCKER_HOST`
-is set on the remote host.
-
-```console
-$ ssh -l <REMOTEUSER> <REMOTEHOST> 'echo $DOCKER_HOST'
-unix:///run/user/1001/docker.sock
-$ docker -H ssh://<REMOTEUSER>@<REMOTEHOST> run ...
-```
-
-### Routing ping packets
-
-On some distributions, `ping` does not work by default.
-
-Add `net.ipv4.ping_group_range = 0   2147483647` to `/etc/sysctl.conf` (or
-`/etc/sysctl.d`) and run `sudo sysctl --system` to allow using `ping`.
-
-### Exposing privileged ports
-
-To expose privileged ports (< 1024), set `CAP_NET_BIND_SERVICE` on `rootlesskit` binary and restart the daemon.
-
-```console
-$ sudo setcap cap_net_bind_service=ep $(which rootlesskit)
-$ systemctl --user restart docker
-```
-
-Or add `net.ipv4.ip_unprivileged_port_start=0` to `/etc/sysctl.conf` (or
-`/etc/sysctl.d`) and run `sudo sysctl --system`.
-
-### Limiting resources
-
-Limiting resources with cgroup-related `docker run` flags such as `--cpus`, `--memory`, `--pids-limit`
-is supported only when running with cgroup v2 and systemd.
-See [Changing cgroup version](/manuals/engine/containers/runmetrics.md) to enable cgroup v2.
-
-If `docker info` shows `none` as `Cgroup Driver`, the conditions are not satisfied.
-When these conditions are not satisfied, rootless mode ignores the cgroup-related `docker run` flags.
-See [Limiting resources without cgroup](#limiting-resources-without-cgroup) for workarounds.
-
-If `docker info` shows `systemd` as `Cgroup Driver`, the conditions are satisfied.
-However, typically, only `memory` and `pids` controllers are delegated to non-root users by default.
-
-```console
-$ cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllers
-memory pids
-```
-
-To allow delegation of all controllers, you need to change the systemd configuration as follows:
-
-```console
-# mkdir -p /etc/systemd/system/user@.service.d
-# cat > /etc/systemd/system/user@.service.d/delegate.conf << EOF
-[Service]
-Delegate=cpu cpuset io memory pids
-EOF
-# systemctl daemon-reload
-```
-
-> [!NOTE]
->
-> Delegating `cpuset` requires systemd 244 or later.
-
-#### Limiting resources without cgroup
-
-Even when cgroup is not available, you can still use the traditional `ulimit` and [`cpulimit`](https://github.com/opsengine/cpulimit),
-though they work in process-granularity rather than in container-granularity,
-and can be arbitrarily disabled by the container process.
-
-For example:
-
-- To limit CPU usage to 0.5 cores (similar to `docker run --cpus 0.5`):
-  `docker run <IMAGE> cpulimit --limit=50 --include-children <COMMAND>`
-- To limit max VSZ to 64MiB (similar to `docker run --memory 64m`):
-  `docker run <IMAGE> sh -c "ulimit -v 65536; <COMMAND>"`
-
-- To limit max number of processes to 100 per namespaced UID 2000
-  (similar to `docker run --pids-limit=100`):
-  `docker run --user 2000 --ulimit nproc=100 <IMAGE> <COMMAND>`
-
-## Troubleshooting
-
-### Unable to install with systemd when systemd is present on the system
-
-``` console
-$ dockerd-rootless-setuptool.sh install
-[INFO] systemd not detected, dockerd-rootless.sh needs to be started manually:
-...
-```
-`rootlesskit` cannot detect systemd properly if you switch to your user via `sudo su`. For users which cannot be logged-in, you must use the `machinectl` command which is part of the `systemd-container` package. After installing `systemd-container` switch to `myuser` with the following command:
-``` console
-$ sudo machinectl shell myuser@
-```
-Where `myuser@` is your desired username and @ signifies this machine.
-
-### Errors when starting the Docker daemon
-
-**\[rootlesskit:parent\] error: failed to start the child: fork/exec /proc/self/exe: operation not permitted**
-
-This error occurs mostly when the value of `/proc/sys/kernel/unprivileged_userns_clone` is set to 0:
-
-```console
-$ cat /proc/sys/kernel/unprivileged_userns_clone
-0
-```
-
-To fix this issue, add  `kernel.unprivileged_userns_clone=1` to
-`/etc/sysctl.conf` (or `/etc/sysctl.d`) and run `sudo sysctl --system`.
-
-**\[rootlesskit:parent\] error: failed to start the child: fork/exec /proc/self/exe: no space left on device**
-
-This error occurs mostly when the value of `/proc/sys/user/max_user_namespaces` is too small:
-
-```console
-$ cat /proc/sys/user/max_user_namespaces
-0
-```
-
-To fix this issue, add  `user.max_user_namespaces=28633` to
-`/etc/sysctl.conf` (or `/etc/sysctl.d`) and run `sudo sysctl --system`.
-
-**\[rootlesskit:parent\] error: failed to setup UID/GID map: failed to compute uid/gid map: No subuid ranges found for user 1001 ("testuser")**
-
-This error occurs when `/etc/subuid` and `/etc/subgid` are not configured. See [Prerequisites](#prerequisites).
-
-**could not get XDG_RUNTIME_DIR**
-
-This error occurs when `$XDG_RUNTIME_DIR` is not set.
-
-On a non-systemd host, you need to create a directory and then set the path:
-
-```console
-$ export XDG_RUNTIME_DIR=$HOME/.docker/xrd
-$ rm -rf $XDG_RUNTIME_DIR
-$ mkdir -p $XDG_RUNTIME_DIR
-$ dockerd-rootless.sh
-```
-
-> [!NOTE]
->
-> You must remove the directory every time you log out.
-
-On a systemd host, log into the host using `pam_systemd` (see below).
-The value is automatically set to `/run/user/$UID` and cleaned up on every logout.
-
-**`systemctl --user` fails with "Failed to connect to bus: No such file or directory"**
-
-This error occurs mostly when you switch from the root user to a non-root user with `sudo`:
-
-```console
-# sudo -iu testuser
-$ systemctl --user start docker
-Failed to connect to bus: No such file or directory
-```
-
-Instead of `sudo -iu <USERNAME>`, you need to log in using `pam_systemd`. For example:
-
-- Log in through the graphic console
-- `ssh <USERNAME>@localhost`
-- `machinectl shell <USERNAME>@`
-
-**The daemon does not start up automatically**
-
-You need `sudo loginctl enable-linger $(whoami)` to enable the daemon to start
-up automatically. See [Usage](#usage).
-
-**iptables failed: iptables -t nat -N DOCKER: Fatal: can't open lock file /run/xtables.lock: Permission denied**
-
-This error may happen with an older version of Docker when SELinux is enabled on the host.
-
-The issue has been fixed in Docker 20.10.8.
-A known workaround for older version of Docker is to run the following commands to disable SELinux for `iptables`:
-```console
-$ sudo dnf install -y policycoreutils-python-utils && sudo semanage permissive -a iptables_t
-```
-
-### `docker pull` errors
-
-**docker: failed to register layer: Error processing tar file(exit status 1): lchown &lt;FILE&gt;: invalid argument**
-
-This error occurs when the number of available entries in `/etc/subuid` or
-`/etc/subgid` is not sufficient. The number of entries required vary across
-images. However, 65,536 entries are sufficient for most images. See
-[Prerequisites](#prerequisites).
-
-**docker: failed to register layer: ApplyLayer exit status 1 stdout:  stderr: lchown &lt;FILE&gt;: operation not permitted**
-
-This error occurs mostly when `~/.local/share/docker` is located on NFS.
-
-A workaround is to specify non-NFS `data-root` directory in `~/.config/docker/daemon.json` as follows:
-```json
-{"data-root":"/somewhere-out-of-nfs"}
-```
-
-### `docker run` errors
-
-**docker: Error response from daemon: OCI runtime create failed: ...: read unix @-&gt;/run/systemd/private: read: connection reset by peer: unknown.**
-
-This error occurs on cgroup v2 hosts mostly when the dbus daemon is not running for the user.
-
-```console
-$ systemctl --user is-active dbus
-inactive
-
-$ docker run hello-world
-docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:385: applying cgroup configuration for process caused: error while starting unit "docker
--931c15729b5a968ce803784d04c7421f791d87e5ca1891f34387bb9f694c488e.scope" with properties [{Name:Description Value:"libcontainer container 931c15729b5a968ce803784d04c7421f791d87e5ca1891f34387bb9f694c488e"} {Name:Slice Value:"use
-r.slice"} {Name:PIDs Value:@au [4529]} {Name:Delegate Value:true} {Name:MemoryAccounting Value:true} {Name:CPUAccounting Value:true} {Name:IOAccounting Value:true} {Name:TasksAccounting Value:true} {Name:DefaultDependencies Val
-ue:false}]: read unix @->/run/systemd/private: read: connection reset by peer: unknown.
-```
-
-To fix the issue, run `sudo apt-get install -y dbus-user-session` or `sudo dnf install -y dbus-daemon`, and then relogin.
-
-If the error still occurs, try running `systemctl --user enable --now dbus` (without sudo).
-
-**`--cpus`, `--memory`, and `--pids-limit` are ignored**
-
-This is an expected behavior on cgroup v1 mode.
-To use these flags, the host needs to be configured for enabling cgroup v2.
-For more information, see [Limiting resources](#limiting-resources).
-
-### Networking errors
-
-This section provides troubleshooting tips for networking in rootless mode.
-
-Networking in rootless mode is supported via network and port drivers in
-RootlessKit. Network performance and characteristics depend on the combination
-of network and port driver you use. If you're experiencing unexpected behavior
-or performance related to networking, review the following table which shows
-the configurations supported by RootlessKit, and how they compare:
-
-| Network driver | Port driver    | Net throughput | Port throughput | Source IP propagation | No SUID | Note                                                                         |
-| -------------- | -------------- | -------------- | --------------- | --------------------- | ------- | ---------------------------------------------------------------------------- |
-| `slirp4netns`  | `builtin`      | Slow           | Fast ✅         | ❌                    | ✅      | Default in a typical setup                                                   |
-| `vpnkit`       | `builtin`      | Slow           | Fast ✅         | ❌                    | ✅      | Default when `slirp4netns` isn't installed                                   |
-| `slirp4netns`  | `slirp4netns`  | Slow           | Slow            | ✅                    | ✅      |                                                                              |
-| `pasta`        | `implicit`     | Slow           | Fast ✅         | ✅                    | ✅      | Experimental; Needs pasta version 2023_12_04 or later                        |
-| `lxc-user-nic` | `builtin`      | Fast ✅        | Fast ✅         | ❌                    | ❌      | Experimental                                                                 |
-| `bypass4netns` | `bypass4netns` | Fast ✅        | Fast ✅         | ✅                    | ✅      | **Note:** Not integrated to RootlessKit as it needs a custom seccomp profile |
-
-For information about troubleshooting specific networking issues, see:
-
-- [`docker run -p` fails with `cannot expose privileged port`](#docker-run--p-fails-with-cannot-expose-privileged-port)
-- [Ping doesn't work](#ping-doesnt-work)
-- [`IPAddress` shown in `docker inspect` is unreachable](#ipaddress-shown-in-docker-inspect-is-unreachable)
-- [`--net=host` doesn't listen ports on the host network namespace](#--nethost-doesnt-listen-ports-on-the-host-network-namespace)
-- [Network is slow](#network-is-slow)
-- [`docker run -p` does not propagate source IP addresses](#docker-run--p-does-not-propagate-source-ip-addresses)
-
-#### `docker run -p` fails with `cannot expose privileged port`
-
-`docker run -p` fails with this error when a privileged port (< 1024) is specified as the host port.
-
-```console
-$ docker run -p 80:80 nginx:alpine
-docker: Error response from daemon: driver failed programming external connectivity on endpoint focused_swanson (9e2e139a9d8fc92b37c36edfa6214a6e986fa2028c0cc359812f685173fa6df7): Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 80, you might need to add "net.ipv4.ip_unprivileged_port_start=0" (currently 1024) to /etc/sysctl.conf, or set CAP_NET_BIND_SERVICE on rootlesskit binary, or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied.
-```
-
-When you experience this error, consider using an unprivileged port instead. For example, 8080 instead of 80.
-
-```console
-$ docker run -p 8080:80 nginx:alpine
-```
-
-To allow exposing privileged ports, see [Exposing privileged ports](#exposing-privileged-ports).
-
-#### Ping doesn't work
-
-Ping does not work when `/proc/sys/net/ipv4/ping_group_range` is set to `1 0`:
-
-```console
-$ cat /proc/sys/net/ipv4/ping_group_range
-1       0
-```
-
-For details, see [Routing ping packets](#routing-ping-packets).
-
-#### `IPAddress` shown in `docker inspect` is unreachable
-
-This is an expected behavior, as the daemon is namespaced inside RootlessKit's
-network namespace. Use `docker run -p` instead.
-
-#### `--net=host` doesn't listen ports on the host network namespace
-
-This is an expected behavior, as the daemon is namespaced inside RootlessKit's
-network namespace. Use `docker run -p` instead.
-
-#### Network is slow
-
-Docker with rootless mode uses [slirp4netns](https://github.com/rootless-containers/slirp4netns) as the default network stack if slirp4netns v0.4.0 or later is installed.
-If slirp4netns is not installed, Docker falls back to [VPNKit](https://github.com/moby/vpnkit).
-Installing slirp4netns may improve the network throughput.
-
-For more information about network drivers for RootlessKit, see
-[RootlessKit documentation](https://github.com/rootless-containers/rootlesskit/blob/v2.0.0/docs/network.md).
-
-Also, changing MTU value may improve the throughput.
-The MTU value can be specified by creating `~/.config/systemd/user/docker.service.d/override.conf` with the following content:
-
-```systemd
-[Service]
-Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_MTU=<INTEGER>"
-```
-
-And then restart the daemon:
-```console
-$ systemctl --user daemon-reload
-$ systemctl --user restart docker
-```
-
-#### `docker run -p` does not propagate source IP addresses
-
-This is because Docker in rootless mode uses RootlessKit's `builtin` port
-driver by default, which doesn't support source IP propagation. To enable
-source IP propagation, you can:
-
-- Use the `slirp4netns` RootlessKit port driver
-- Use the `pasta` RootlessKit network driver, with the `implicit` port driver
-
-The `pasta` network driver is experimental, but provides improved throughput
-performance compared to the `slirp4netns` port driver. The `pasta` driver
-requires Docker Engine version 25.0 or later.
-
-To change the RootlessKit networking configuration:
-
-1. Create a file at `~/.config/systemd/user/docker.service.d/override.conf`.
-2. Add the following contents, depending on which configuration you would like to use:
-
-   - `slirp4netns`
-
-      ```systemd
-      [Service]
-      Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_NET=slirp4netns"
-      Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=slirp4netns"
-      ```
-
-   - `pasta` network driver with `implicit` port driver
-
-      ```systemd
-      [Service]
-      Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_NET=pasta"
-      Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=implicit"
-      ```
-
-3. Restart the daemon:
-
-   ```console
-   $ systemctl --user daemon-reload
-   $ systemctl --user restart docker
-   ```
-
-For more information about networking options for RootlessKit, see:
-
-- [Network drivers](https://github.com/rootless-containers/rootlesskit/blob/v2.0.0/docs/network.md)
-- [Port drivers](https://github.com/rootless-containers/rootlesskit/blob/v2.0.0/docs/port.md)
-
-### Tips for debugging
-
-**Entering into `dockerd` namespaces**
-
-The `dockerd-rootless.sh` script executes `dockerd` in its own user, mount, and network namespaces.
-
-For debugging, you can enter the namespaces by running
-`nsenter -U --preserve-credentials -n -m -t $(cat $XDG_RUNTIME_DIR/docker.pid)`.
diff --git a/content/manuals/engine/security/rootless/_index.md b/content/manuals/engine/security/rootless/_index.md
new file mode 100644
index 000000000000..e8cc2dfb7046
--- /dev/null
+++ b/content/manuals/engine/security/rootless/_index.md
@@ -0,0 +1,150 @@
+---
+description: Run the Docker daemon as a non-root user (Rootless mode)
+keywords: security, namespaces, rootless
+title: Rootless mode
+weight: 10
+---
+
+Rootless mode lets you run the Docker daemon and containers as a non-root
+user to mitigate potential vulnerabilities in the daemon and
+the container runtime.
+
+Rootless mode does not require root privileges even during the installation of
+the Docker daemon, as long as the [prerequisites](#prerequisites) are met.
+
+## How it works
+
+Rootless mode executes the Docker daemon and containers inside a user namespace.
+This is similar to [`userns-remap` mode](../userns-remap.md), except that
+with `userns-remap` mode, the daemon itself is running with root privileges,
+whereas in rootless mode, both the daemon and the container are running without
+root privileges.
+
+The two modes also differ in how they map container UIDs and GIDs to the
+host: see [UID/GID mapping](uid-gid-mapping/) for details.
+
+Rootless mode does not use binaries with `SETUID` bits or file capabilities,
+except `newuidmap` and `newgidmap`, which are needed to allow multiple
+UIDs/GIDs to be used in the user namespace.
+
+
+## Prerequisites
+
+-  You must install `newuidmap` and `newgidmap` on the host. These commands
+  are provided by the `uidmap` package on most distributions.
+
+- `/etc/subuid` and `/etc/subgid` should contain at least 65,536 subordinate
+  UIDs/GIDs for the user. In the following example, the user `testuser` has
+  65,536 subordinate UIDs/GIDs (231072-296607).
+
+```console
+$ id -u
+1001
+$ whoami
+testuser
+$ grep ^$(whoami): /etc/subuid
+testuser:231072:65536
+$ grep ^$(whoami): /etc/subgid
+testuser:231072:65536
+```
+
+The `dockerd-rootless-setuptool.sh install` script (see following) automatically shows help
+when the prerequisites are not satisfied.
+
+## Install
+
+> [!NOTE]
+>
+> If the system-wide Docker daemon is already running, consider disabling it:
+>```console
+>$ sudo systemctl disable --now docker.service docker.socket
+>$ sudo rm /var/run/docker.sock
+>```
+> Should you choose not to shut down the `docker` service and socket, you will need to use the `--force`
+> parameter in the next section. There are no known issues, but until you shutdown and disable you're
+> still running rootful Docker. 
+
+{{< tabs >}}
+{{< tab name="With packages (RPM/DEB)" >}}
+
+If you installed Docker 20.10 or later with [RPM/DEB packages](/engine/install), you should have `dockerd-rootless-setuptool.sh` in `/usr/bin`.
+
+Run `dockerd-rootless-setuptool.sh install` as a non-root user to set up the daemon:
+
+```console
+$ dockerd-rootless-setuptool.sh install
+[INFO] Creating /home/testuser/.config/systemd/user/docker.service
+...
+[INFO] Installed docker.service successfully.
+[INFO] To control docker.service, run: `systemctl --user (start|stop|restart) docker.service`
+[INFO] To run docker.service on system startup, run: `sudo loginctl enable-linger testuser`
+
+[INFO] Creating CLI context "rootless"
+Successfully created context "rootless"
+[INFO] Using CLI context "rootless"
+Current context is now "rootless"
+
+[INFO] Make sure the following environment variable(s) are set (or add them to ~/.bashrc):
+export PATH=/usr/bin:$PATH
+
+[INFO] Some applications may require the following environment variable too:
+export DOCKER_HOST=unix:///run/user/1000/docker.sock
+```
+
+If `dockerd-rootless-setuptool.sh` is not present, you may need to install the `docker-ce-rootless-extras` package manually, e.g.,
+
+```console
+$ sudo apt-get install -y docker-ce-rootless-extras
+```
+
+{{< /tab >}}
+{{< tab name="Without packages" >}}
+
+If you do not have permission to run package managers like `apt-get` and `dnf`,
+consider using the installation script available at [https://get.docker.com/rootless](https://get.docker.com/rootless).
+Since static packages are not available for `s390x`, hence it is not supported for `s390x`.
+
+```console
+$ curl -fsSL https://get.docker.com/rootless | sh
+...
+[INFO] Creating /home/testuser/.config/systemd/user/docker.service
+...
+[INFO] Installed docker.service successfully.
+[INFO] To control docker.service, run: `systemctl --user (start|stop|restart) docker.service`
+[INFO] To run docker.service on system startup, run: `sudo loginctl enable-linger testuser`
+
+[INFO] Creating CLI context "rootless"
+Successfully created context "rootless"
+[INFO] Using CLI context "rootless"
+Current context is now "rootless"
+
+[INFO] Make sure the following environment variable(s) are set (or add them to ~/.bashrc):
+export PATH=/home/testuser/bin:$PATH
+
+[INFO] Some applications may require the following environment variable too:
+export DOCKER_HOST=unix:///run/user/1000/docker.sock
+```
+
+The binaries will be installed at `~/bin`.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Run `docker info` to confirm that the `docker` client is connecting to the Rootless daemon:
+```console
+$ docker info
+Client: Docker Engine - Community
+ Version:    28.3.3
+ Context:    rootless
+...
+Server:
+...
+ Security Options:
+  seccomp
+   Profile: builtin
+  rootless
+  cgroupns
+...
+```
+
+See [Troubleshooting](./troubleshoot.md) if you faced an error.
\ No newline at end of file
diff --git a/content/manuals/engine/security/rootless/tips.md b/content/manuals/engine/security/rootless/tips.md
new file mode 100644
index 000000000000..82eef156c4aa
--- /dev/null
+++ b/content/manuals/engine/security/rootless/tips.md
@@ -0,0 +1,193 @@
+---
+description: Tips for the Rootless mode
+keywords: security, namespaces, rootless
+title: Tips
+weight: 20
+---
+
+## Advanced usage
+
+### Daemon
+
+{{< tabs >}}
+{{< tab name="With systemd (Highly recommended)" >}}
+
+The systemd unit file is installed as  `~/.config/systemd/user/docker.service`.
+
+Use `systemctl --user` to manage the lifecycle of the daemon:
+
+```console
+$ systemctl --user start docker
+```
+
+To launch the daemon on system startup, enable the systemd service and lingering:
+
+```console
+$ systemctl --user enable docker
+$ sudo loginctl enable-linger $(whoami)
+```
+
+Starting Rootless Docker as a systemd-wide service (`/etc/systemd/system/docker.service`)
+is not supported, even with the `User=` directive.
+
+{{< /tab >}}
+{{< tab name="Without systemd" >}}
+
+To run the daemon directly without systemd, you need to run `dockerd-rootless.sh` instead of `dockerd`.
+
+The following environment variables must be set:
+- `$HOME`: the home directory
+- `$XDG_RUNTIME_DIR`: an ephemeral directory that is only accessible by the expected user, e,g, `~/.docker/run`.
+  The directory should be removed on every host shutdown.
+  The directory can be on tmpfs, however, should not be under `/tmp`.
+  Locating this directory under `/tmp` might be vulnerable to TOCTOU attack.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+It's important to note that with directory paths:
+
+- The socket path is set to `$XDG_RUNTIME_DIR/docker.sock` by default.
+  `$XDG_RUNTIME_DIR` is typically set to `/run/user/$UID`.
+- The data dir is set to `~/.local/share/docker` by default.
+  The data dir should not be on NFS.
+- The daemon config dir is set to `~/.config/docker` by default.
+  This directory is different from `~/.docker` that is used by the client.
+
+### Client
+
+Since Docker Engine v23.0, `dockerd-rootless-setuptool.sh install` automatically configures
+the `docker` CLI to use the `rootless` context.
+
+Prior to Docker Engine v23.0, a user had to specify either the socket path or the CLI context explicitly.
+
+To specify the socket path using `$DOCKER_HOST`:
+
+```console
+$ export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock
+$ docker run -d -p 8080:80 nginx
+```
+
+To specify the CLI context using `docker context`:
+
+```console
+$ docker context use rootless
+rootless
+Current context is now "rootless"
+$ docker run -d -p 8080:80 nginx
+```
+
+## Best practices
+
+### Rootless Docker in Docker
+
+To run Rootless Docker inside "rootful" Docker, use the `docker:<version>-dind-rootless`
+image instead of `docker:<version>-dind`.
+
+```console
+$ docker run -d --name dind-rootless --privileged docker:25.0-dind-rootless
+```
+
+The `docker:<version>-dind-rootless` image runs as a non-root user (UID 1000).
+However, `--privileged` is required for disabling seccomp, AppArmor, and mount
+masks.
+
+### Expose Docker API socket through TCP
+
+To expose the Docker API socket through TCP, you need to launch `dockerd-rootless.sh`
+with `DOCKERD_ROOTLESS_ROOTLESSKIT_FLAGS="-p 0.0.0.0:2376:2376/tcp"`.
+
+```console
+$ DOCKERD_ROOTLESS_ROOTLESSKIT_FLAGS="-p 0.0.0.0:2376:2376/tcp" \
+  dockerd-rootless.sh \
+  -H tcp://0.0.0.0:2376 \
+  --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem
+```
+
+### Expose Docker API socket through SSH
+
+To expose the Docker API socket through SSH, you need to make sure `$DOCKER_HOST`
+is set on the remote host.
+
+```console
+$ ssh -l <REMOTEUSER> <REMOTEHOST> 'echo $DOCKER_HOST'
+unix:///run/user/1001/docker.sock
+$ docker -H ssh://<REMOTEUSER>@<REMOTEHOST> run ...
+```
+
+### Routing ping packets
+
+On some distributions, `ping` does not work by default.
+
+Add `net.ipv4.ping_group_range = 0   2147483647` to `/etc/sysctl.conf` (or
+`/etc/sysctl.d`) and run `sudo sysctl --system` to allow using `ping`.
+
+### Exposing privileged ports
+
+To expose privileged ports (< 1024), set `CAP_NET_BIND_SERVICE` on `rootlesskit` binary and restart the daemon.
+
+```console
+$ sudo setcap cap_net_bind_service=ep $(which rootlesskit)
+$ systemctl --user restart docker
+```
+
+Or add `net.ipv4.ip_unprivileged_port_start=0` to `/etc/sysctl.conf` (or
+`/etc/sysctl.d`) and run `sudo sysctl --system`.
+
+### Limiting resources
+
+Limiting resources with cgroup-related `docker run` flags such as `--cpus`, `--memory`, `--pids-limit`
+is supported only when running with cgroup v2 and systemd.
+See [Changing cgroup version](/manuals/engine/containers/runmetrics.md) to enable cgroup v2.
+
+If `docker info` shows `none` as `Cgroup Driver`, the conditions are not satisfied.
+When these conditions are not satisfied, rootless mode ignores the cgroup-related `docker run` flags.
+See [Limiting resources without cgroup](#limiting-resources-without-cgroup) for workarounds.
+
+If `docker info` shows `systemd` as `Cgroup Driver`, the conditions are satisfied.
+However, typically, only `memory` and `pids` controllers are delegated to non-root users by default.
+
+```console
+$ cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllers
+memory pids
+```
+
+To allow delegation of all controllers, change the systemd configuration:
+
+```console
+$ sudo mkdir -p /etc/systemd/system/user@.service.d
+```
+
+Create `/etc/systemd/system/user@.service.d/delegate.conf`:
+
+```ini
+[Service]
+Delegate=cpu cpuset io memory pids
+```
+
+Then reload systemd:
+
+```console
+$ sudo systemctl daemon-reload
+```
+
+> [!NOTE]
+>
+> Delegating `cpuset` requires systemd 244 or later.
+
+#### Limiting resources without cgroup
+
+Even when cgroup is not available, you can still use the traditional `ulimit` and [`cpulimit`](https://github.com/opsengine/cpulimit),
+though they work in process-granularity rather than in container-granularity,
+and can be arbitrarily disabled by the container process.
+
+For example:
+
+- To limit CPU usage to 0.5 cores (similar to `docker run --cpus 0.5`):
+  `docker run <IMAGE> cpulimit --limit=50 --include-children <COMMAND>`
+- To limit max VSZ to 64MiB (similar to `docker run --memory 64m`):
+  `docker run <IMAGE> sh -c "ulimit -v 65536; <COMMAND>"`
+
+- To limit max number of processes to 100 per namespaced UID 2000
+  (similar to `docker run --pids-limit=100`):
+  `docker run --user 2000 --ulimit nproc=100 <IMAGE> <COMMAND>`
diff --git a/content/manuals/engine/security/rootless/troubleshoot.md b/content/manuals/engine/security/rootless/troubleshoot.md
new file mode 100644
index 000000000000..ef1c9567e4fe
--- /dev/null
+++ b/content/manuals/engine/security/rootless/troubleshoot.md
@@ -0,0 +1,463 @@
+---
+description: Troubleshooting the Rootless mode
+keywords: security, namespaces, rootless, troubleshooting
+title: Troubleshooting
+weight: 30
+---
+
+### Distribution-specific hint
+
+{{< tabs >}}
+{{< tab name="Ubuntu" >}}
+- Ubuntu 24.04 and later enables restricted unprivileged user namespaces by
+  default, which prevents unprivileged processes in creating user namespaces
+  unless an AppArmor profile is configured to allow programs to use
+  unprivileged user namespaces.
+
+  If you install `docker-ce-rootless-extras` using the deb package (`apt-get
+  install docker-ce-rootless-extras`), then the AppArmor profile for
+  `rootlesskit` is already bundled with the `apparmor` deb package. With this
+  installation method, you don't need to add any manual the AppArmor
+  configuration. If you install the rootless extras using the [installation
+  script](https://get.docker.com/rootless), however, you must add an AppArmor
+  profile for `rootlesskit` manually:
+
+  1. Create and install the currently logged-in user's AppArmor profile:
+
+     ```console
+     $ filename=$(echo $HOME/bin/rootlesskit | sed -e 's@^/@@' -e 's@/@.@g')
+     $ [ ! -z "${filename}" ] && sudo cat <<EOF > /etc/apparmor.d/${filename}
+     abi <abi/4.0>,
+     include <tunables/global>
+
+     "$HOME/bin/rootlesskit" flags=(unconfined) {
+       userns,
+
+       include if exists <local/${filename}>
+     }
+     EOF
+     ```
+  2. Restart AppArmor.
+
+     ```console
+     $ systemctl restart apparmor.service
+     ```
+
+{{< /tab >}}
+{{< tab name="Arch Linux" >}}
+- Add `kernel.unprivileged_userns_clone=1` to `/etc/sysctl.conf` (or
+  `/etc/sysctl.d`) and run `sudo sysctl --system`
+{{< /tab >}}
+{{< tab name="openSUSE and SLES" >}}
+- `sudo modprobe ip_tables iptable_mangle iptable_nat iptable_filter` is required.
+  This might be required on other distributions as well depending on the configuration.
+
+- Known to work on openSUSE 15 and SLES 15.
+{{< /tab >}}
+{{< tab name="CentOS, RHEL, and Fedora" >}}
+- For RHEL 8 and similar distributions, installing `fuse-overlayfs` is recommended. Run `sudo dnf install -y fuse-overlayfs`.
+  This step is not required on RHEL 9 and similar distributions.
+
+- You might need `sudo dnf install -y iptables`.
+{{< /tab >}}
+{{< /tabs >}}
+
+## Known limitations
+
+- Only the following storage drivers are supported:
+  - `overlay2` (only if running with kernel 5.11 or later)
+  - `fuse-overlayfs` (only if running with kernel 4.18 or later, and `fuse-overlayfs` is installed)
+  - `btrfs` (only if running with kernel 4.18 or later, or `~/.local/share/docker` is mounted with `user_subvol_rm_allowed` mount option)
+  - `vfs`
+- cgroup is supported only when running with cgroup v2 and systemd. See [Limiting resources](./tips.md#limiting-resources).
+- Following features are not supported:
+  - AppArmor
+  - Checkpoint
+  - Overlay network
+  - Exposing SCTP ports
+- To use the `ping` command, see [Routing ping packets](./tips.md#routing-ping-packets).
+- To expose privileged TCP/UDP ports (< 1024), see [Exposing privileged ports](./tips.md#exposing-privileged-ports).
+- `IPAddress` shown in `docker inspect` is namespaced inside RootlessKit's network namespace.
+  This means the IP address is not reachable from the host without `nsenter`-ing into the network namespace.
+- Port forwarding with `docker run -p` does not propagate source IP addresses by default.
+  See [`docker run -p` does not propagate source IP addresses](#docker-run--p-does-not-propagate-source-ip-addresses) to enable source IP propagation.
+- NFS mounts as the docker "data-root" is not supported. This limitation is not specific to rootless mode.
+- Capabilities added with `--cap-add` apply only to resources governed by the
+  container's user namespace. They don't grant privileges over host or other
+  global resources. As a result, operations that require capabilities in the
+  [initial user namespace](https://man7.org/linux/man-pages/man7/user_namespaces.7.html)
+  can still fail.
+
+### Historical limitations
+
+#### Until Docker Engine v29.5
+
+- Host network (`docker run --net=host`) was namespaced inside RootlessKit.
+  This meant that ports listened by containers with `--net=host` were not reachable from the real host network namespace.
+
+## Troubleshooting
+
+### Unable to install with systemd when systemd is present on the system
+
+``` console
+$ dockerd-rootless-setuptool.sh install
+[INFO] systemd not detected, dockerd-rootless.sh needs to be started manually:
+...
+```
+`rootlesskit` cannot detect systemd properly if you switch to your user via `sudo su`. For users which cannot be logged-in, you must use the `machinectl` command which is part of the `systemd-container` package. After installing `systemd-container` switch to `myuser` with the following command:
+``` console
+$ sudo machinectl shell myuser@
+```
+Where `myuser@` is your desired username and @ signifies this machine.
+
+### Errors when starting the Docker daemon
+
+**\[rootlesskit:parent\] error: failed to start the child: fork/exec /proc/self/exe: operation not permitted**
+
+This error occurs mostly when the value of `/proc/sys/kernel/unprivileged_userns_clone` is set to 0:
+
+```console
+$ cat /proc/sys/kernel/unprivileged_userns_clone
+0
+```
+
+To fix this issue, add  `kernel.unprivileged_userns_clone=1` to
+`/etc/sysctl.conf` (or `/etc/sysctl.d`) and run `sudo sysctl --system`.
+
+**\[rootlesskit:parent\] error: failed to start the child: fork/exec /proc/self/exe: no space left on device**
+
+This error occurs mostly when the value of `/proc/sys/user/max_user_namespaces` is too small:
+
+```console
+$ cat /proc/sys/user/max_user_namespaces
+0
+```
+
+To fix this issue, add  `user.max_user_namespaces=28633` to
+`/etc/sysctl.conf` (or `/etc/sysctl.d`) and run `sudo sysctl --system`.
+
+**\[rootlesskit:parent\] error: failed to setup UID/GID map: failed to compute uid/gid map: No subuid ranges found for user 1001 ("testuser")**
+
+This error occurs when `/etc/subuid` and `/etc/subgid` are not configured. See [Prerequisites](./_index.md#prerequisites).
+
+**could not get XDG_RUNTIME_DIR**
+
+This error occurs when `$XDG_RUNTIME_DIR` is not set.
+
+On a non-systemd host, you need to create a directory and then set the path:
+
+```console
+$ export XDG_RUNTIME_DIR=$HOME/.docker/xrd
+$ rm -rf $XDG_RUNTIME_DIR
+$ mkdir -p $XDG_RUNTIME_DIR
+$ dockerd-rootless.sh
+```
+
+> [!NOTE]
+>
+> You must remove the directory every time you log out.
+
+On a systemd host, log into the host using `pam_systemd` (see below).
+The value is automatically set to `/run/user/$UID` and cleaned up on every logout.
+
+**`systemctl --user` fails with "Failed to connect to bus: No such file or directory"**
+
+This error occurs mostly when you switch from the root user to a non-root user with `sudo`:
+
+```console
+# sudo -iu testuser
+$ systemctl --user start docker
+Failed to connect to bus: No such file or directory
+```
+
+Instead of `sudo -iu <USERNAME>`, you need to log in using `pam_systemd`. For example:
+
+- Log in through the graphic console
+- `ssh <USERNAME>@localhost`
+- `machinectl shell <USERNAME>@`
+
+**The daemon does not start up automatically**
+
+You need `sudo loginctl enable-linger $(whoami)` to enable the daemon to start
+up automatically. See [Advanced Usage](./tips.md/#advanced-usage).
+
+### `docker pull` errors
+
+**docker: failed to register layer: Error processing tar file(exit status 1): lchown &lt;FILE&gt;: invalid argument**
+
+This error occurs when the number of available entries in `/etc/subuid` or
+`/etc/subgid` is not sufficient. The number of entries required vary across
+images. However, 65,536 entries are sufficient for most images. See
+[Prerequisites](./_index.md#prerequisites).
+
+**docker: failed to register layer: ApplyLayer exit status 1 stdout:  stderr: lchown &lt;FILE&gt;: operation not permitted**
+
+This error occurs mostly when `~/.local/share/docker` is located on NFS.
+
+A workaround is to specify non-NFS `data-root` directory in `~/.config/docker/daemon.json` as follows:
+```json
+{"data-root":"/somewhere-out-of-nfs"}
+```
+
+### `docker run` errors
+
+**docker: Error response from daemon: OCI runtime create failed: ...: read unix @-&gt;/run/systemd/private: read: connection reset by peer: unknown.**
+
+This error occurs on cgroup v2 hosts mostly when the dbus daemon is not running for the user.
+
+```console
+$ systemctl --user is-active dbus
+inactive
+
+$ docker run hello-world
+docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:385: applying cgroup configuration for process caused: error while starting unit "docker
+-931c15729b5a968ce803784d04c7421f791d87e5ca1891f34387bb9f694c488e.scope" with properties [{Name:Description Value:"libcontainer container 931c15729b5a968ce803784d04c7421f791d87e5ca1891f34387bb9f694c488e"} {Name:Slice Value:"use
+r.slice"} {Name:PIDs Value:@au [4529]} {Name:Delegate Value:true} {Name:MemoryAccounting Value:true} {Name:CPUAccounting Value:true} {Name:IOAccounting Value:true} {Name:TasksAccounting Value:true} {Name:DefaultDependencies Val
+ue:false}]: read unix @->/run/systemd/private: read: connection reset by peer: unknown.
+```
+
+To fix the issue, run `sudo apt-get install -y dbus-user-session` or `sudo dnf install -y dbus-daemon`, and then relogin.
+
+If the error still occurs, try running `systemctl --user enable --now dbus` (without sudo).
+
+**`--cpus`, `--memory`, and `--pids-limit` are ignored**
+
+This is an expected behavior on cgroup v1 mode.
+To use these flags, the host needs to be configured for enabling cgroup v2.
+For more information, see [Limiting resources](./tips.md#limiting-resources).
+
+### Networking errors
+
+This section provides troubleshooting tips for networking in rootless mode.
+
+Networking in rootless mode is supported via network and port drivers in
+RootlessKit. Network performance and characteristics depend on the combination
+of network and port driver you use. If you're experiencing unexpected behavior
+or performance related to networking, review the following table which shows
+the configurations supported by RootlessKit, and how they compare:
+
+| Network driver | Port driver          | Net throughput | Port throughput | Source IP propagation | No SUID | Note                                                                         |
+| -------------- | -------------------- | -------------- | --------------- | --------------------- | ------- | ---------------------------------------------------------------------------- |
+| `gvisor-tap-vsock`| `builtin`         | Slow           | Fast ✅         | ✅ (*)                | ✅      | Default when slirp4netns is not installed                                    |
+| `slirp4netns`     | `builtin`         | Slow           | Fast ✅         | ✅ (*)                | ✅      | Default when slirp4netns is installed                                        |
+| `vpnkit`          | `builtin`         | Slow           | Fast ✅         | ✅ (*)                | ✅      | Legacy                                                                       |
+| `gvisor-tap-vsock`| `gvisor-tap-vsock`| Slow           | Slow            | ❌                    | ✅      | Not recommended. Use `builtin` port driver instead.                          |
+| `slirp4netns`     | `slirp4netns`     | Slow           | Slow            | ✅                    | ✅      |                                                                              |
+| `pasta`           | `implicit`        | Slow           | Fast ✅         | ✅                    | ✅      | Experimental; Needs pasta version 2023_12_04 or later                        |
+| `lxc-user-nic`    | `builtin`         | Fast ✅        | Fast ✅         | ✅ (*)                | ❌      | Experimental                                                                 |
+| `bypass4netns`    | `bypass4netns`    | Fast ✅        | Fast ✅         | ✅                    | ✅      | **Note:** Not integrated to RootlessKit as it needs a custom seccomp profile |
+
+(*) Applicable since RootlessKit v3.0. Also requires `userland-proxy` to be disabled.
+
+For information about troubleshooting specific networking issues, see:
+
+- [`docker run -p` fails with `cannot expose privileged port`](#docker-run--p-fails-with-cannot-expose-privileged-port)
+- [Ping doesn't work](#ping-doesnt-work)
+- [`IPAddress` shown in `docker inspect` is unreachable](#ipaddress-shown-in-docker-inspect-is-unreachable)
+- [`--net=host` doesn't listen ports on the host network namespace](#--nethost-doesnt-listen-ports-on-the-host-network-namespace)
+- [Network is slow](#network-is-slow)
+- [`docker run -p` does not propagate source IP addresses](#docker-run--p-does-not-propagate-source-ip-addresses)
+
+#### `docker run -p` fails with `cannot expose privileged port`
+
+`docker run -p` fails with this error when a privileged port (< 1024) is specified as the host port.
+
+```console
+$ docker run -p 80:80 nginx:alpine
+docker: Error response from daemon: driver failed programming external connectivity on endpoint focused_swanson (9e2e139a9d8fc92b37c36edfa6214a6e986fa2028c0cc359812f685173fa6df7): Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 80, you might need to add "net.ipv4.ip_unprivileged_port_start=0" (currently 1024) to /etc/sysctl.conf, or set CAP_NET_BIND_SERVICE on rootlesskit binary, or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied.
+```
+
+When you experience this error, consider using an unprivileged port instead. For example, 8080 instead of 80.
+
+```console
+$ docker run -p 8080:80 nginx:alpine
+```
+
+To allow exposing privileged ports, see [Exposing privileged ports](./tips.md#exposing-privileged-ports).
+
+#### Ping doesn't work
+
+Ping does not work when `/proc/sys/net/ipv4/ping_group_range` is set to `1 0`:
+
+```console
+$ cat /proc/sys/net/ipv4/ping_group_range
+1       0
+```
+
+For details, see [Routing ping packets](./tips.md#routing-ping-packets).
+
+#### `IPAddress` shown in `docker inspect` is unreachable
+
+This is an expected behavior, as the daemon is namespaced inside RootlessKit's
+network namespace. Use `docker run -p` instead.
+
+#### `--net=host` doesn't listen ports on the host network namespace
+
+This was an expected behavior until Docker Engine v29.5, as the daemon was namespaced inside RootlessKit's
+network namespace. Use `docker run -p` instead, or upgrade to Docker Engine v29.5 or later.
+
+#### Network is slow
+
+Docker with rootless mode uses a TCP/IP stack running in user mode, such as:
+- [slirp4netns](https://github.com/rootless-containers/slirp4netns) (default when slirp4netns is installed)
+- [pasta](https://passt.top/passt/about/)
+- [VPNKit](https://github.com/moby/vpnkit)
+- [gvisor-tap-vsock](https://github.com/containers/gvisor-tap-vsock) (default when none of the above is installed)
+
+The TCP/IP stack in user mode is generally slower than the one in kernel mode, and the performance may vary depending on the network driver used.
+
+See [RootlessKit documentation](https://github.com/rootless-containers/rootlesskit/blob/v3.0.0/docs/network.md)
+for more information.
+
+##### Workaround 1: bypass user-mode TCP/IP stack
+
+Use `docker run --net=host` to bypass the user-mode TCP/IP stack.
+This is applicable since Docker Engine v29.5.
+However, this requires the container to share the host network namespace, which may not be desirable for security reasons.
+
+##### Workaround 2: disable user-mode TCP/IP stack
+
+Alternatively, you can use the `lxc-user-nic` network driver (experimental) to disable the user-mode TCP/IP stack entirely.
+However, this requires configuring `/etc/lxc/lxc-usernet` for enabling the privileged helper.
+
+```bash
+sudo apt-get install -y lxc
+sudo mkdir -p /etc/lxc
+cat <<EOF | sudo tee /etc/lxc/lxc-usernet
+# USERNAME TYPE BRIDGE COUNT
+$USER veth lxcbr0 10
+EOF
+```
+
+Also, make sure that the rootful daemon is not running, as its iptables rules may interfere with the `lxc-user-nic` driver.
+```console
+$ systemctl is-active docker.service
+inactive
+
+$ systemctl is-active docker.socket
+inactive
+```
+
+The network driver can be specified by creating `~/.config/systemd/user/docker.service.d/override.conf` with the following content:
+
+```systemd
+[Service]
+Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_NET=lxc-user-nic"
+# Optional: specify MTU (may affect throughput)
+# Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_MTU=<INTEGER>"
+```
+
+And then restart the daemon:
+```bash
+systemctl --user daemon-reload
+systemctl --user restart docker
+```
+
+#### `docker run -p` does not propagate source IP addresses
+
+{{< tabs >}}
+{{< tab name="RootlessKit v3.0 or later" >}}
+This is because Docker Engine's `userland-proxy` is incompatible with RootlessKit's source IP propagation.
+
+To disable userland-proxy, add the following configuration to `~/.config/docker/daemon.json`:
+
+```json
+{"userland-proxy": false}
+```
+
+Then restart the daemon:
+
+```bash
+systemctl --user restart docker
+```
+
+You may also need to load `br_netfilter` kernel module:
+
+```bash
+sudo tee /etc/modules-load.d/docker.conf <<EOF >/dev/null
+br_netfilter
+EOF
+
+sudo systemctl restart systemd-modules-load.service
+```
+{{< /tab >}}
+{{< tab name="Prior versions" >}}
+This is because RootlessKit's `builtin` port didn't support source IP propagation until v3.0. To enable
+source IP propagation, you can:
+
+- Use the `slirp4netns` RootlessKit port driver
+- Use the `pasta` RootlessKit network driver, with the `implicit` port driver
+
+The `pasta` network driver is experimental, but provides improved throughput
+performance compared to the `slirp4netns` port driver. The `pasta` driver
+requires Docker Engine version 25.0 or later.
+
+To change the RootlessKit networking configuration:
+
+1. Create a file at `~/.config/systemd/user/docker.service.d/override.conf`.
+2. Add the following contents, depending on which configuration you would like to use:
+
+   - `slirp4netns`
+
+      ```systemd
+      [Service]
+      Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_NET=slirp4netns"
+      Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=slirp4netns"
+      ```
+
+   - `pasta` network driver with `implicit` port driver
+
+      ```systemd
+      [Service]
+      Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_NET=pasta"
+      Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=implicit"
+      ```
+
+3. Restart the daemon:
+
+   ```console
+   $ systemctl --user daemon-reload
+   $ systemctl --user restart docker
+   ```
+{{< /tab >}}
+{{< /tabs >}}
+
+For more information about networking options for RootlessKit, see:
+
+- [Network drivers](https://github.com/rootless-containers/rootlesskit/blob/v3.0.0/docs/network.md)
+- [Port drivers](https://github.com/rootless-containers/rootlesskit/blob/v3.0.0/docs/port.md)
+
+### Tips for debugging
+
+**Entering into `dockerd` namespaces**
+
+The `dockerd-rootless.sh` script executes `dockerd` in its own user, mount, and network namespaces.
+
+For debugging, you can enter the namespaces by running
+`nsenter -U --preserve-credentials -n -m -t $(cat $XDG_RUNTIME_DIR/docker.pid)`.
+
+## Uninstall
+
+To remove the systemd service of the Docker daemon, run `dockerd-rootless-setuptool.sh uninstall`:
+
+```console
+$ dockerd-rootless-setuptool.sh uninstall
++ systemctl --user stop docker.service
++ systemctl --user disable docker.service
+Removed /home/testuser/.config/systemd/user/default.target.wants/docker.service.
+[INFO] Uninstalled docker.service
+[INFO] This uninstallation tool does NOT remove Docker binaries and data.
+[INFO] To remove data, run: `/usr/bin/rootlesskit rm -rf /home/testuser/.local/share/docker`
+```
+
+Unset environment variables PATH and DOCKER_HOST if you have added them to `~/.bashrc`.
+
+To remove the data directory, run `rootlesskit rm -rf ~/.local/share/docker`.
+
+To remove the binaries, remove `docker-ce-rootless-extras` package if you installed Docker with package managers.
+If you installed Docker with https://get.docker.com/rootless ([Install without packages](./_index.md#install)),
+remove the binary files under `~/bin`:
+```console
+$ cd ~/bin
+$ rm -f containerd containerd-shim containerd-shim-runc-v2 ctr docker docker-init docker-proxy dockerd dockerd-rootless-setuptool.sh dockerd-rootless.sh rootlesskit rootlesskit-docker-proxy runc vpnkit
+```
diff --git a/content/manuals/engine/security/rootless/uid-gid-mapping.md b/content/manuals/engine/security/rootless/uid-gid-mapping.md
new file mode 100644
index 000000000000..8d90f7ad5216
--- /dev/null
+++ b/content/manuals/engine/security/rootless/uid-gid-mapping.md
@@ -0,0 +1,22 @@
+---
+description: How container UIDs and GIDs are mapped to the host in rootless mode
+keywords: security, namespaces, rootless, uid, gid, subuid, subgid
+title: UID/GID mapping
+weight: 15
+---
+
+Rootless mode and [`userns-remap` mode](../userns-remap.md) map container UIDs
+and GIDs to the host differently.
+
+- In `userns-remap` mode, container UID `0` is mapped to the first subordinate
+  UID listed in `/etc/subuid` for the remap user, and container UID `n` is
+  mapped to `subuid + n`.
+- In rootless mode, container UID `0` is mapped to the host UID of the user
+  running rootless Docker (the result of `id -u`); container UID `n` (for
+  `n >= 1`) is mapped to `subuid + (n - 1)`.
+
+GIDs follow the same rules using `/etc/subgid`.
+
+This difference matters when setting file permissions on bind-mounted
+directories: in rootless mode, files owned by your host user appear as owned
+by `root` inside the container.
diff --git a/content/manuals/engine/security/seccomp.md b/content/manuals/engine/security/seccomp.md
index 094bdbffe0a0..8f165589ac33 100644
--- a/content/manuals/engine/security/seccomp.md
+++ b/content/manuals/engine/security/seccomp.md
@@ -20,11 +20,10 @@ CONFIG_SECCOMP=y
 
 ## Pass a profile for a container
 
-The default `seccomp` profile provides a sane default for running containers with
-seccomp and disables around 44 system calls out of 300+. It is moderately
-protective while providing wide application compatibility. The default Docker
-profile can be found
-[here](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json).
+The [default `seccomp` profile](https://github.com/moby/profiles/blob/main/seccomp/default.json)
+provides a sane default for running containers with seccomp and disables around
+44 system calls out of 300+. It is moderately protective while providing wide
+application compatibility.
 
 In effect, the profile is an allowlist that denies access to system calls by
 default and then allows specific system calls. The profile works by defining a
@@ -49,6 +48,11 @@ $ docker run --rm \
              hello-world
 ```
 
+The Docker CLI resolves a relative profile path from the working directory
+where you invoke `docker`. The CLI reads the profile and sends its contents to
+the daemon, so the profile must be available on the client host when the client
+and daemon run on separate hosts.
+
 ### Significant syscalls blocked by the default profile
 
 Docker's default seccomp profile is an allowlist which specifies the calls that
@@ -72,6 +76,9 @@ the reason each syscall is blocked rather than white-listed.
 | `init_module`       | Deny manipulation and functions on kernel modules. Also gated by `CAP_SYS_MODULE`.                                                                                                                                                             |
 | `ioperm`            | Prevent containers from modifying kernel I/O privilege levels. Already gated by `CAP_SYS_RAWIO`.                                                                                                                                               |
 | `iopl`              | Prevent containers from modifying kernel I/O privilege levels. Already gated by `CAP_SYS_RAWIO`.                                                                                                                                               |
+| `io_uring_enter`    | Blocked due to security vulnerabilities that can be exploited to break out of containers. See [moby/moby#46762](https://github.com/moby/moby/pull/46762).                                                                                      |
+| `io_uring_register` | Blocked due to security vulnerabilities that can be exploited to break out of containers. See [moby/moby#46762](https://github.com/moby/moby/pull/46762).                                                                                      |
+| `io_uring_setup`    | Blocked due to security vulnerabilities that can be exploited to break out of containers. See [moby/moby#46762](https://github.com/moby/moby/pull/46762).                                                                                      |
 | `kcmp`              | Restrict process inspection capabilities, already blocked by dropping `CAP_SYS_PTRACE`.                                                                                                                                                        |
 | `kexec_file_load`   | Sister syscall of `kexec_load` that does the same thing, slightly different arguments. Also gated by `CAP_SYS_BOOT`.                                                                                                                           |
 | `kexec_load`        | Deny loading a new kernel for later execution. Also gated by `CAP_SYS_BOOT`.                                                                                                                                                                   |
@@ -96,6 +103,7 @@ the reason each syscall is blocked rather than white-listed.
 | `setns`             | Deny associating a thread with a namespace. Also gated by `CAP_SYS_ADMIN`.                                                                                                                                                                     |
 | `settimeofday`      | Time/date is not namespaced. Also gated by `CAP_SYS_TIME`.                                                                                                                                                                                     |
 | `stime`             | Time/date is not namespaced. Also gated by `CAP_SYS_TIME`.                                                                                                                                                                                     |
+| `socket`            | Blocked for `AF_ALG` to prevent in-container privilege escalation via the kernel cryptographic API ([CVE-2026-31431](https://nvd.nist.gov/vuln/detail/CVE-2026-31431)). Also blocked for `AF_VSOCK`. These do not cover `socketcall(2)`, which can be easily bypassed. `AF_ALG` is denied on both paths by the default AppArmor profile (`deny network alg,`) or the SELinux policy module; `AF_VSOCK` has no equivalent LSM rule. See [moby/moby#52494](https://github.com/moby/moby/pull/52494). |
 | `swapon`            | Deny start/stop swapping to file/device. Also gated by `CAP_SYS_ADMIN`.                                                                                                                                                                        |
 | `swapoff`           | Deny start/stop swapping to file/device. Also gated by `CAP_SYS_ADMIN`.                                                                                                                                                                        |
 | `sysfs`             | Obsolete syscall.                                                                                                                                                                                                                              |
diff --git a/content/manuals/engine/security/trust/_index.md b/content/manuals/engine/security/trust/_index.md
index 8ac5f3f21924..62f79a91f00c 100644
--- a/content/manuals/engine/security/trust/_index.md
+++ b/content/manuals/engine/security/trust/_index.md
@@ -35,6 +35,12 @@ ensure that the images they pull are signed. Publishers could be individuals
 or organizations manually signing their content or automated software supply
 chains signing content as part of their release process.
 
+> [!WARNING]
+>
+> Docker Content Trust (DCT) is being retired. The Notary v1 service at
+> `notary.docker.io` will shut down on December 8, 2026. For more information, see
+> [Docker Content Trust (DCT)](/manuals/retired.md#docker-content-trust-dct).
+
 ### Image tags and DCT
 
 An individual image record has the following identifier:
@@ -53,7 +59,7 @@ have discretion on which tags they sign.
 
 An image repository can contain an image with one tag that is signed and another
 tag that is not. For example, consider [the Mongo image
-repository](https://hub.docker.com/r/library/mongo/tags/). The `latest`
+repository](https://hub.docker.com/_/mongo/tags/). The `latest`
 tag could be unsigned while the `3.1.6` tag could be signed. It is the
 responsibility of the image publisher to decide if an image tag is signed or
 not. In this representation, some image tags are signed, others are not:
@@ -111,9 +117,8 @@ Within the Docker CLI we can sign and push a container image with the
 `$ docker trust` command syntax. This is built on top of the Notary feature
 set. For more information, see the [Notary GitHub repository](https://github.com/theupdateframework/notary).
 
-A prerequisite for signing an image is a Docker Registry with a Notary server
-attached (Such as the Docker Hub ). Instructions for
-standing up a self-hosted environment can be found [here](/engine/security/trust/deploying_notary/).
+A prerequisite for signing an image is a Docker Registry with a Notary server (such as Docker Hub) attached.
+Refer to [Deploying Notary](/engine/security/trust/deploying_notary/) for instructions.
 
 To sign a Docker Image you will need a delegation key pair. These keys
 can be generated locally using `$ docker trust key generate` or generated
diff --git a/content/manuals/engine/security/trust/deploying_notary.md b/content/manuals/engine/security/trust/deploying_notary.md
index 21de96527a71..4a24c04b84a1 100644
--- a/content/manuals/engine/security/trust/deploying_notary.md
+++ b/content/manuals/engine/security/trust/deploying_notary.md
@@ -27,6 +27,7 @@ for [Notary](https://github.com/docker/notary#using-notary) depending on which o
 
 ## If you want to use Notary in production
 
-Check back here for instructions after Notary Server has an official
-stable release. To get a head start on deploying Notary in production, see
-[the Notary repository](https://github.com/theupdateframework/notary).
+The Compose sample on this page is for local testing and uses sample
+certificates. For a production deployment, follow the upstream
+[instructions to run a Notary service](https://github.com/theupdateframework/notary/blob/master/docs/running_a_service.md)
+and the rest of [the Notary repository](https://github.com/theupdateframework/notary).
diff --git a/content/manuals/engine/security/trust/images/tag_signing.png b/content/manuals/engine/security/trust/images/tag_signing.png
index 4dfdfb6709c7..52fa2952452d 100644
Binary files a/content/manuals/engine/security/trust/images/tag_signing.png and b/content/manuals/engine/security/trust/images/tag_signing.png differ
diff --git a/content/manuals/engine/security/trust/images/trust_components.png b/content/manuals/engine/security/trust/images/trust_components.png
index cf3913308f5f..4e7b90254f6e 100644
Binary files a/content/manuals/engine/security/trust/images/trust_components.png and b/content/manuals/engine/security/trust/images/trust_components.png differ
diff --git a/content/manuals/engine/security/trust/images/trust_view.png b/content/manuals/engine/security/trust/images/trust_view.png
index ea431ebfd964..f7eb7537eede 100644
Binary files a/content/manuals/engine/security/trust/images/trust_view.png and b/content/manuals/engine/security/trust/images/trust_view.png differ
diff --git a/content/manuals/engine/security/trust/trust_automation.md b/content/manuals/engine/security/trust/trust_automation.md
index 311840d8d139..8d06240d7eef 100644
--- a/content/manuals/engine/security/trust/trust_automation.md
+++ b/content/manuals/engine/security/trust/trust_automation.md
@@ -16,8 +16,8 @@ When working directly with the Notary client, it uses its [own set of environmen
 ## Add a delegation private key
 
 To automate importing a delegation private key to the local Docker trust store, we 
-need to pass a passphrase for the new key. This passphrase will be required 
-everytime that delegation signs a tag. 
+need to pass a passphrase for the new key. This passphrase will be required
+every time that delegation signs a tag.
 
 ```console
 $ export DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE="mypassphrase123"
diff --git a/content/manuals/engine/security/trust/trust_delegation.md b/content/manuals/engine/security/trust/trust_delegation.md
index df4b8d933ada..8c7a003eb3bc 100644
--- a/content/manuals/engine/security/trust/trust_delegation.md
+++ b/content/manuals/engine/security/trust/trust_delegation.md
@@ -26,7 +26,7 @@ same as the registry URL specified in the image tag (following a similar logic t
 `$ docker push`). When using Docker Hub or DTR, the notary
 server URL is the same as the registry URL. However, for self-hosted
 environments or 3rd party registries, you will need to specify an alternative
-URL for the notary server. This is done with:
+URL of the notary server. This is done with:
 
 ```console
 $ export DOCKER_CONTENT_TRUST_SERVER=https://<URL>:<PORT>
@@ -96,8 +96,7 @@ configure the Notary CLI:
 The newly created configuration file contains information about the location of your local Docker trust data and the notary server URL.
 
 For more detailed information about how to use notary outside of the
-Docker Content Trust use cases, refer to the Notary CLI documentation
-[here](https://github.com/theupdateframework/notary/blob/master/docs/command_reference.md) 
+Docker Content Trust use cases, refer to the [Notary CLI documentation](https://github.com/theupdateframework/notary/blob/master/docs/command_reference.md) 
 
 ## Creating delegation keys
 
@@ -189,8 +188,8 @@ jeff                                    9deed251daa1aa6f9d5f9b752847647cf8d705da
 When the first delegation is added to the Notary Server using `$ docker trust`,
 we automatically initiate trust data for the repository. This includes creating 
 the notary target and snapshots keys, and rotating the snapshot key to be 
-managed by the notary server. More information on these keys can be found 
-[here](trust_key_mng.md)
+managed by the notary server. More information on these keys can be found in
+[Manage keys for content trust](trust_key_mng.md).
 
 When initiating a repository, you will need the key and the passphrase of a local
 Notary Canonical Root Key. If you have not initiated a repository before, and 
@@ -361,7 +360,7 @@ Successfully removed ben from registry.example.com/admin/demo
    ```
 
 2) If you have added additional delegations already and are seeing an error 
-   message that there are no valid signatures in `targest/releases`, you will need
+   message that there are no valid signatures in `targets/releases`, you will need
    to resign the `targets/releases` delegation file with the Notary CLI.
 
    ```text
@@ -374,8 +373,8 @@ Successfully removed ben from registry.example.com/admin/demo
    $ notary witness registry.example.com/admin/demo targets/releases --publish
    ```
 
-   More information on the `$ notary witness` command can be found 
-   [here](https://github.com/theupdateframework/notary/blob/master/docs/advanced_usage.md#recovering-a-delegation)
+   For more information on the `notary witness` command, refer to the
+   [Notary client advanced usage guide](https://github.com/theupdateframework/notary/blob/master/docs/advanced_usage.md#recovering-a-delegation)
 
 ### Removing a contributor's key from a delegation
 
diff --git a/content/manuals/engine/security/trust/trust_sandbox.md b/content/manuals/engine/security/trust/trust_sandbox.md
index 8b159b8691cf..290a7e7e8bdc 100644
--- a/content/manuals/engine/security/trust/trust_sandbox.md
+++ b/content/manuals/engine/security/trust/trust_sandbox.md
@@ -19,11 +19,11 @@ These instructions assume you are running in Linux or macOS. You can run
 this sandbox on a local machine or on a virtual machine. You need to
 have privileges to run docker commands on your local machine or in the VM.
 
-This sandbox requires you to install two Docker tools: Docker Engine >= 1.10.0
-and Docker Compose >= 1.6.0. To install the Docker Engine, choose from the
-[list of supported platforms](../../install/_index.md). To install
-Docker Compose, see the
-[detailed instructions here](/manuals/compose/install/_index.md).
+This sandbox requires a current Docker Engine and Docker Compose install. To
+install Docker Engine, choose from the
+[list of supported platforms](../../install/_index.md). To install Docker
+Compose, see the
+[Compose install instructions](/manuals/compose/install/_index.md).
 
 ## What is in the sandbox?
 
@@ -51,7 +51,7 @@ sandbox is configured to store all the keys and files inside the `trustsandbox`
 container. Since the keys you create in the sandbox are for play only,
 destroying the container destroys them as well.
 
-By using a docker-in-docker image for the `trustsandbox` container, you also
+By using a `docker-in-docker` image for the `trustsandbox` container, you also
 don't pollute your real Docker daemon cache with any images you push and pull.
 The images are stored in an anonymous volume attached to this container,
 and can be destroyed after you destroy the container.
@@ -64,61 +64,68 @@ the `trustsandbox` container, the Notary server, and the Registry server.
 
 1. Create a new `trustsandbox` directory and change into it.
 
-        $ mkdir trustsandbox
-        $ cd trustsandbox
+   ```console
+   $ mkdir trustsandbox
+   $ cd trustsandbox
+   ```
 
 2. Create a file called `compose.yaml` with your favorite editor.  For example, using vim:
 
-        $ touch compose.yaml
-        $ vim compose.yaml
+   ```console
+   $ touch compose.yaml
+   $ vim compose.yaml
+   ```
 
 3. Add the following to the new file.
 
-        version: "2"
-        services:
-          notaryserver:
-            image: dockersecurity/notary_autobuilds:server-v0.5.1
-            volumes:
-              - notarycerts:/var/lib/notary/fixtures
-            networks:
-              - sandbox
-            environment:
-              - NOTARY_SERVER_STORAGE_TYPE=memory
-              - NOTARY_SERVER_TRUST_SERVICE_TYPE=local
-          sandboxregistry:
-            image: registry:2.4.1
-            networks:
-              - sandbox
-            container_name: sandboxregistry
-          trustsandbox:
-            image: docker:dind
-            networks:
-              - sandbox
-            volumes:
-              - notarycerts:/notarycerts
-            privileged: true
-            container_name: trustsandbox
-            entrypoint: ""
-            command: |-
-                sh -c '
-                    cp /notarycerts/root-ca.crt /usr/local/share/ca-certificates/root-ca.crt &&
-                    update-ca-certificates &&
-                    dockerd-entrypoint.sh --insecure-registry sandboxregistry:5000'
-        volumes:
-          notarycerts:
-            external: false
-        networks:
-          sandbox:
-            external: false
-
+   ```yaml
+   version: "2"
+   services:
+     notaryserver:
+       image: dockersecurity/notary_autobuilds:server-v0.5.1
+       volumes:
+         - notarycerts:/var/lib/notary/fixtures
+       networks:
+         - sandbox
+       environment:
+         - NOTARY_SERVER_STORAGE_TYPE=memory
+         - NOTARY_SERVER_TRUST_SERVICE_TYPE=local
+     sandboxregistry:
+       image: registry:3
+       networks:
+         - sandbox
+       container_name: sandboxregistry
+     trustsandbox:
+       image: docker:dind
+       networks:
+         - sandbox
+       volumes:
+         - notarycerts:/notarycerts
+       privileged: true
+       container_name: trustsandbox
+       entrypoint: ""
+       command: |-
+           sh -c '
+               cp /notarycerts/root-ca.crt /usr/local/share/ca-certificates/root-ca.crt &&
+               update-ca-certificates &&
+               dockerd-entrypoint.sh --insecure-registry sandboxregistry:5000'
+   volumes:
+     notarycerts:
+       external: false
+   networks:
+     sandbox:
+       external: false
+   ```
 4. Save and close the file.
 
 5. Run the containers on your local system.
 
-        $ docker compose up -d
+   ```console
+   $ docker compose up -d
+   ```
 
-    The first time you run this, the docker-in-docker, Notary server, and registry
-    images are downloaded from Docker Hub.
+   The first time you run this, the `docker-in-docker`, Notary server, and registry
+   images are downloaded from Docker Hub.
 
 
 ## Play in the sandbox
@@ -127,8 +134,10 @@ Now that everything is setup, you can go into your `trustsandbox` container and
 start testing Docker content trust. From your host machine, obtain a shell
 in the `trustsandbox` container.
 
-    $ docker container exec -it trustsandbox sh
-    / #
+```console
+$ docker container exec -it trustsandbox sh
+/ #
+```
 
 ### Test some trust operations
 
@@ -136,59 +145,68 @@ Now, pull some images from within the `trustsandbox` container.
 
 1. Download a `docker` image to test with.
 
-        / # docker pull docker/trusttest
-        docker pull docker/trusttest
-        Using default tag: latest
-        latest: Pulling from docker/trusttest
-
-        b3dbab3810fc: Pull complete
-        a9539b34a6ab: Pull complete
-        Digest: sha256:d149ab53f8718e987c3a3024bb8aa0e2caadf6c0328f1d9d850b2a2a67f2819a
-        Status: Downloaded newer image for docker/trusttest:latest
+   ```console
+   / # docker pull docker/trusttest
+   docker pull docker/trusttest
+   Using default tag: latest
+   latest: Pulling from docker/trusttest   
+   b3dbab3810fc: Pull complete
+   a9539b34a6ab: Pull complete
+   Digest: sha256:d149ab53f8718e987c3a3024bb8aa0e2caadf6c0328f1d9d850b2a2a67f2819a
+   Status: Downloaded newer image for docker/trusttest:latest
+   ```
 
-2. Tag it to be pushed to our sandbox registry:
+2. Tag it to be pushed to your sandbox registry:
 
-        / # docker tag docker/trusttest sandboxregistry:5000/test/trusttest:latest
+   ```console
+   / # docker tag docker/trusttest sandboxregistry:5000/test/trusttest:latest
+   ```
 
 3. Enable content trust.
 
-        / # export DOCKER_CONTENT_TRUST=1
+   ```console
+   / # export DOCKER_CONTENT_TRUST=1
+   ```
 
 4. Identify the trust server.
 
-        / # export DOCKER_CONTENT_TRUST_SERVER=https://notaryserver:4443
+   ```console
+   / # export DOCKER_CONTENT_TRUST_SERVER=https://notaryserver:4443
+   ```
 
     This step is only necessary because the sandbox is using its own server.
     Normally, if you are using the Docker Public Hub this step isn't necessary.
 
 5. Pull the test image.
 
-        / # docker pull sandboxregistry:5000/test/trusttest
-        Using default tag: latest
-        Error: remote trust data does not exist for sandboxregistry:5000/test/trusttest: notaryserver:4443 does not have trust data for sandboxregistry:5000/test/trusttest
-
+   ```console
+   / # docker pull sandboxregistry:5000/test/trusttest
+   Using default tag: latest
+   Error: remote trust data does not exist for sandboxregistry:5000/test/trusttest: notaryserver:4443 does not have trust data for      sandboxregistry:5000/test/trusttest
+   ```
       You see an error, because this content doesn't exist on the `notaryserver` yet.
 
 6. Push and sign the trusted image.
-
-        / # docker push sandboxregistry:5000/test/trusttest:latest
-        The push refers to a repository [sandboxregistry:5000/test/trusttest]
-        5f70bf18a086: Pushed
-        c22f7bc058a9: Pushed
-        latest: digest: sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926 size: 734
-        Signing and pushing trust metadata
-        You are about to create a new root signing key passphrase. This passphrase
-        will be used to protect the most sensitive key in your signing system. Please
-        choose a long, complex passphrase and be careful to keep the password and the
-        key file itself secure and backed up. It is highly recommended that you use a
-        password manager to generate the passphrase and keep it safe. There will be no
-        way to recover this key. You can find the key in your config directory.
-        Enter passphrase for new root key with ID 27ec255:
-        Repeat passphrase for new root key with ID 27ec255:
-        Enter passphrase for new repository key with ID 58233f9 (sandboxregistry:5000/test/trusttest):
-        Repeat passphrase for new repository key with ID 58233f9 (sandboxregistry:5000/test/trusttest):
-        Finished initializing "sandboxregistry:5000/test/trusttest"
-        Successfully signed "sandboxregistry:5000/test/trusttest":latest
+   ```console
+   / # docker push sandboxregistry:5000/test/trusttest:latest
+   The push refers to a repository [sandboxregistry:5000/test/trusttest]
+   5f70bf18a086: Pushed
+   c22f7bc058a9: Pushed
+   latest: digest: sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926 size: 734
+   Signing and pushing trust metadata
+   You are about to create a new root signing key passphrase. This passphrase
+   will be used to protect the most sensitive key in your signing system. Please
+   choose a long, complex passphrase and be careful to keep the password and the
+   key file itself secure and backed up. It is highly recommended that you use a
+   password manager to generate the passphrase and keep it safe. There will be no
+   way to recover this key. You can find the key in your config directory.
+   Enter passphrase for new root key with ID 27ec255:
+   Repeat passphrase for new root key with ID 27ec255:
+   Enter passphrase for new repository key with ID 58233f9 (sandboxregistry:5000/test/trusttest):
+   Repeat passphrase for new repository key with ID 58233f9 (sandboxregistry:5000/test/trusttest):
+   Finished initializing "sandboxregistry:5000/test/trusttest"
+   Successfully signed "sandboxregistry:5000/test/trusttest":latest
+   ```
 
     Because you are pushing this repository for the first time, Docker creates
     new root and repository keys and asks you for passphrases with which to
@@ -197,13 +215,15 @@ Now, pull some images from within the `trustsandbox` container.
 
 7. Try pulling the image you just pushed:
 
-        / # docker pull sandboxregistry:5000/test/trusttest
-        Using default tag: latest
-        Pull (1 of 1): sandboxregistry:5000/test/trusttest:latest@sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926
-        sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926: Pulling from test/trusttest
-        Digest: sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926
-        Status: Downloaded newer image for sandboxregistry:5000/test/trusttest@sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926
-        Tagging sandboxregistry:5000/test/trusttest@sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926 as sandboxregistry:5000/test/trusttest:latest
+   ```console
+   / # docker pull sandboxregistry:5000/test/trusttest
+   Using default tag: latest
+   Pull (1 of 1): sandboxregistry:5000/test/trusttest:latest@sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926
+   sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926: Pulling from test/trusttest
+   Digest: sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926
+   Status: Downloaded newer image for sandboxregistry:5000/test/trusttest@sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926
+   Tagging sandboxregistry:5000/test/trusttest@sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926 as sandboxregistry:5000   test/trusttest:latest
+   ```
 
 
 ### Test with malicious images
@@ -212,15 +232,17 @@ What happens when data is corrupted and you try to pull it when trust is
 enabled? In this section, you go into the `sandboxregistry` and tamper with some
 data. Then, you try and pull it.
 
-1.  Leave the `trustsandbox` shell and container running.
+1. Leave the `trustsandbox` shell and container running.
 
-2.  Open a new interactive terminal from your host, and obtain a shell into the
-    `sandboxregistry` container.
+2. Open a new interactive terminal from your host, and obtain a shell into the
+   `sandboxregistry` container.
 
-        $ docker container exec -it sandboxregistry bash
-        root@65084fc6f047:/#
+   ```console
+   $ docker container exec -it sandboxregistry bash
+   root@65084fc6f047:/#
+   ```
 
-3.  List the layers for the `test/trusttest` image you pushed:
+3. List the layers for the `test/trusttest` image you pushed:
 
     ```console
     root@65084fc6f047:/# ls -l /var/lib/registry/docker/registry/v2/repositories/test/trusttest/_layers/sha256
@@ -230,51 +252,61 @@ data. Then, you try and pull it.
     drwxr-xr-x 2 root root 4096 Jun 10 17:26 cc7629d1331a7362b5e5126beb5bf15ca0bf67eb41eab994c719a45de53255cd
     ```
 
-4.  Change into the registry storage for one of those layers (this is in a different directory):
+4. Change into the registry storage for one of those layers (this is in a different directory):
 
-        root@65084fc6f047:/# cd /var/lib/registry/docker/registry/v2/blobs/sha256/aa/aac0c133338db2b18ff054943cee3267fe50c75cdee969aed88b1992539ed042
+   ```console
+   root@65084fc6f047:/# cd /var/lib/registry/docker/registry/v2/blobs/sha256/aa/aac0c133338db2b18ff054943cee3267fe50c75cdee969aed88b1992539ed042
+   ```
 
-5.  Add malicious data to one of the `trusttest` layers:
+5. Add malicious data to one of the `trusttest` layers:
 
-        root@65084fc6f047:/# echo "Malicious data" > data
+   ```console
+   root@65084fc6f047:/# echo "Malicious data" > data
+   ```
 
-6.  Go back to your `trustsandbox` terminal.
+6. Go back to your `trustsandbox` terminal.
 
-7.  List the `trusttest` image.
+7. List the `trusttest` image.
 
-        / # docker image ls | grep trusttest
-        REPOSITORY                            TAG                 IMAGE ID            CREATED             SIZE
-        docker/trusttest                      latest              cc7629d1331a        11 months ago       5.025 MB
-        sandboxregistry:5000/test/trusttest   latest              cc7629d1331a        11 months ago       5.025 MB
-        sandboxregistry:5000/test/trusttest   <none>              cc7629d1331a        11 months ago       5.025 MB
+   ```console
+   / # docker image ls | grep trusttest
+   REPOSITORY                            TAG                 IMAGE ID            CREATED             SIZE
+   docker/trusttest                      latest              cc7629d1331a        11 months ago       5.025 MB
+   sandboxregistry:5000/test/trusttest   latest              cc7629d1331a        11 months ago       5.025 MB
+   sandboxregistry:5000/test/trusttest   <none>              cc7629d1331a        11 months ago       5.025 MB
+   ```
 
-8.  Remove the `trusttest:latest` image from our local cache.
+8. Remove the `trusttest:latest` image from your local cache.
 
-        / # docker image rm -f cc7629d1331a
-        Untagged: docker/trusttest:latest
-        Untagged: sandboxregistry:5000/test/trusttest:latest
-        Untagged: sandboxregistry:5000/test/trusttest@sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926
-        Deleted: sha256:cc7629d1331a7362b5e5126beb5bf15ca0bf67eb41eab994c719a45de53255cd
-        Deleted: sha256:2a1f6535dc6816ffadcdbe20590045e6cbf048d63fd4cc753a684c9bc01abeea
-        Deleted: sha256:c22f7bc058a9a8ffeb32989b5d3338787e73855bf224af7aa162823da015d44c
+   ```console
+   / # docker image rm -f cc7629d1331a
+   Untagged: docker/trusttest:latest
+   Untagged: sandboxregistry:5000/test/trusttest:latest
+   Untagged: sandboxregistry:5000/test/trusttest@sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926
+   Deleted: sha256:cc7629d1331a7362b5e5126beb5bf15ca0bf67eb41eab994c719a45de53255cd
+   Deleted: sha256:2a1f6535dc6816ffadcdbe20590045e6cbf048d63fd4cc753a684c9bc01abeea
+   Deleted: sha256:c22f7bc058a9a8ffeb32989b5d3338787e73855bf224af7aa162823da015d44c
+   ```
 
-    Docker does not re-download images that it already has cached, but we want
-    Docker to attempt to download the tampered image from the registry and reject
-    it because it is invalid.
+   Docker does not re-download images that it already has cached, but you want
+   Docker to attempt to download the tampered image from the registry and reject
+   it because it is invalid.
 
-9.  Pull the image again. This downloads the image from the registry, because we don't have it cached.
+9. Pull the image again. This downloads the image from the registry, because you don't have it cached.
 
-        / # docker pull sandboxregistry:5000/test/trusttest
-        Using default tag: latest
-        Pull (1 of 1): sandboxregistry:5000/test/trusttest:latest@sha256:35d5bc26fd358da8320c137784fe590d8fcf9417263ef261653e8e1c7f15672e
-        sha256:35d5bc26fd358da8320c137784fe590d8fcf9417263ef261653e8e1c7f15672e: Pulling from test/trusttest
+   ```console
+   / # docker pull sandboxregistry:5000/test/trusttest
+   Using default tag: latest
+   Pull (1 of 1): sandboxregistry:5000/test/trusttest:latest@sha256:35d5bc26fd358da8320c137784fe590d8fcf9417263ef261653e8e1c7f15672e
+   sha256:35d5bc26fd358da8320c137784fe590d8fcf9417263ef261653e8e1c7f15672e: Pulling from test/trusttest
 
-        aac0c133338d: Retrying in 5 seconds
-        a3ed95caeb02: Download complete
-        error pulling image configuration: unexpected EOF
+   aac0c133338d: Retrying in 5 seconds
+   a3ed95caeb02: Download complete
+   error pulling image configuration: unexpected EOF
+   ```
 
-      The pull did not complete because the trust system couldn't verify the
-      image.
+   The pull did not complete because the trust system couldn't verify the
+   image.
 
 ## More play in the sandbox
 
@@ -289,4 +321,6 @@ When you are done, and want to clean up all the services you've started and any
 anonymous volumes that have been created, just run the following command in the
 directory where you've created your Docker Compose file:
 
-        $ docker compose down -v
+   ```console
+   $ docker compose down -v
+   ```
diff --git a/content/manuals/engine/security/userns-remap.md b/content/manuals/engine/security/userns-remap.md
index 57dfe29986bc..c04d8afcb503 100644
--- a/content/manuals/engine/security/userns-remap.md
+++ b/content/manuals/engine/security/userns-remap.md
@@ -16,13 +16,19 @@ can re-map this user to a less-privileged user on the Docker host. The mapped
 user is assigned a range of UIDs which function within the namespace as normal
 UIDs from 0 to 65536, but have no privileges on the host machine itself.
 
+> [!NOTE]
+>
+> With `userns-remap`, the Docker daemon still runs as root. To run both the
+> daemon and containers without root privileges, see [Rootless mode](rootless/_index.md)
+> instead.
+
 ## About remapping and subordinate user and group IDs
 
 The remapping itself is handled by two files: `/etc/subuid` and `/etc/subgid`.
 Each file works the same, but one is concerned with the user ID range, and the
 other with the group ID range. Consider the following entry in `/etc/subuid`:
 
-```none
+```text
 testuser:231072:65536
 ```
 
@@ -50,7 +56,7 @@ purpose.
 > [!WARNING]
 >
 > Some distributions do not automatically add the new group to the
-> `/etc/subuid` and `/etc/subgid` files. If that's the case, you are may have
+> `/etc/subuid` and `/etc/subgid` files. If that's the case, you may have
 > to manually edit these files and assign non-overlapping ranges. This step is
 > covered in [Prerequisites](#prerequisites).
 
@@ -93,7 +99,7 @@ avoid these situations.
     and a maximum number of UIDs or GIDs available to the user. For instance,
     given the following entry:
 
-    ```none
+    ```text
     testuser:231072:65536
     ```
 
diff --git a/content/manuals/engine/storage/_index.md b/content/manuals/engine/storage/_index.md
index d616e3028672..f6c63bfb5ac2 100644
--- a/content/manuals/engine/storage/_index.md
+++ b/content/manuals/engine/storage/_index.md
@@ -8,6 +8,22 @@ aliases:
   - /storage/
 ---
 
+Docker storage covers two different concepts:
+
+**Container data persistence** (this page): How to store application data
+outside containers using volumes, bind mounts, and tmpfs mounts. This data
+persists independently of container lifecycle.
+
+**Daemon storage backends** ([containerd image store](containerd.md) and
+[storage drivers](drivers/)): How the daemon stores image layers and container
+writable layers on disk.
+
+This page focuses on container data persistence. For information about how
+Docker stores images and container layers, see
+[containerd image store](containerd.md) or [Storage drivers](drivers/).
+
+## Container layer basics
+
 By default all files created inside a container are stored on a writable
 container layer that sits on top of the read-only, immutable image layers.
 
@@ -26,6 +42,7 @@ of the writable layer of the container:
 - [Volume mounts](#volume-mounts)
 - [Bind mounts](#bind-mounts)
 - [tmpfs mounts](#tmpfs-mounts)
+- [Image mounts](#image-mounts)
 - [Named pipes](#named-pipes)
 
 No matter which type of mount you choose to use, the data looks the same from
@@ -69,6 +86,18 @@ such as caching intermediate data, handling sensitive information like
 credentials, or reducing disk I/O. Use tmpfs mounts only when the data does not
 need to persist beyond the current container session.
 
+### Image mounts
+
+An image mount makes the contents of another image available inside a container
+at a path you choose. The mounted image is read-only and isn't part of the
+container's own image, so you can bring in tools or assets from one image
+without rebuilding another.
+
+Use image mounts when you need to consume files packaged as an image, such as
+mounting a tool-rich image to debug a minimal container, or sharing read-only
+assets across containers running different images. Image mounts require the
+[containerd image store](containerd.md).
+
 ### Named pipes
 
 [Named pipes](https://docs.microsoft.com/en-us/windows/desktop/ipc/named-pipes)
@@ -78,9 +107,14 @@ Docker Engine API using a named pipe.
 
 ## Next steps
 
-- Learn more about [volumes](./volumes.md).
-- Learn more about [bind mounts](./bind-mounts.md).
-- Learn more about [tmpfs mounts](./tmpfs.md).
-- Learn more about [storage drivers](/engine/storage/drivers/), which
-  are not related to bind mounts or volumes, but allow you to store data in a
-  container's writable layer.
+Learn more about container data persistence:
+
+- [Volumes](./volumes.md)
+- [Bind mounts](./bind-mounts.md)
+- [tmpfs mounts](./tmpfs.md)
+- [Image mounts](./image-mounts.md)
+
+Learn more about daemon storage backends:
+
+- [containerd image store](containerd.md)
+- [Storage drivers](drivers/)
diff --git a/content/manuals/engine/storage/bind-mounts.md b/content/manuals/engine/storage/bind-mounts.md
index 4b5d07c09d90..e32c87137ad7 100644
--- a/content/manuals/engine/storage/bind-mounts.md
+++ b/content/manuals/engine/storage/bind-mounts.md
@@ -10,8 +10,9 @@ aliases:
 
 When you use a bind mount, a file or directory on the host machine is mounted
 from the host into a container. By contrast, when you use a volume, a new
-directory is created within Docker's storage directory on the host machine, and
-Docker manages that directory's contents.
+directory is created within Docker's storage directory on the host machine.
+Docker creates and maintains this storage location, but containers access it
+directly using standard filesystem operations.
 
 ## When to use bind mounts
 
@@ -85,9 +86,11 @@ flag is more explicit and supports all the available options.
 
 If you use `--volume` to bind-mount a file or directory that does not yet
 exist on the Docker host, Docker automatically creates the directory on the
-host for you. It's always created as a directory.
+host for you. It's always created as a directory. If the Docker daemon doesn't
+have permission to create the source directory, create it before starting the
+container.
 
-`--mount` does not automatically create a directory if the specified mount
+By default, `--mount` does not automatically create a directory if the specified mount
 path does not exist on the host. Instead, it produces an error:
 
 ```console
@@ -95,6 +98,13 @@ $ docker run --mount type=bind,src=/dev/noexist,dst=/mnt/foo alpine
 docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /dev/noexist.
 ```
 
+You can use the `bind-create-src` option to automatically create the source directory
+on the host if it doesn't exist:
+
+```console
+$ docker run --mount type=bind,src=/home/user/mydir,dst=/mnt/foo,bind-create-src alpine
+```
+
 ### Options for --mount
 
 The `--mount` flag consists of multiple key-value pairs, separated by commas
@@ -107,12 +117,13 @@ $ docker run --mount type=bind,src=<host-path>,dst=<container-path>[,<key>=<valu
 
 Valid options for `--mount type=bind` include:
 
-| Option                         | Description                                                                                                     |
-| ------------------------------ | --------------------------------------------------------------------------------------------------------------- |
-| `source`, `src`                | The location of the file or directory on the host. This can be an absolute or relative path.                    |
-| `destination`, `dst`, `target` | The path where the file or directory is mounted in the container. Must be an absolute path.                     |
-| `readonly`, `ro`               | If present, causes the bind mount to be [mounted into the container as read-only](#use-a-read-only-bind-mount). |
-| `bind-propagation`             | If present, changes the [bind propagation](#configure-bind-propagation).                                        |
+| Option                         | Description                                                                                                                                                         |
+| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `source`, `src`                | The location of the file or directory on the host. This can be an absolute or relative path.                                                                        |
+| `destination`, `dst`, `target` | The path where the file or directory is mounted in the container. Must be an absolute path.                                                                         |
+| `readonly`, `ro`               | If present, causes the bind mount to be [mounted into the container as read-only](#use-a-read-only-bind-mount).                                                     |
+| `bind-propagation`             | If present, changes the [bind propagation](#configure-bind-propagation).                                                                                            |
+| `bind-create-src`              | Automatically creates the source directory on the host if it doesn't exist. By default, `--mount` produces an error if the source path doesn't exist on the daemon. |
 
 ```console {title="Example"}
 $ docker run --mount type=bind,src=.,dst=/project,ro,bind-propagation=rshared
@@ -469,12 +480,13 @@ volumes:
 ```
 
 For more information about using volumes of the `bind` type with Compose, see
-[Compose reference on volumes](/reference/compose-file/services.md#volumes).
+[Compose reference on the volumes top-level element](/reference/compose-file/volumes.md).
 and
-[Compose reference on volume configuration](/reference/compose-file/services.md#volumes).
+[Compose reference on the volume attribute](/reference/compose-file/services.md#volumes).
 
 ## Next steps
 
 - Learn about [volumes](./volumes.md).
 - Learn about [tmpfs mounts](./tmpfs.md).
+- Learn about [image mounts](./image-mounts.md).
 - Learn about [storage drivers](/engine/storage/drivers/).
diff --git a/content/manuals/engine/storage/containerd.md b/content/manuals/engine/storage/containerd.md
index 00ceed979dd8..64bacd22b080 100644
--- a/content/manuals/engine/storage/containerd.md
+++ b/content/manuals/engine/storage/containerd.md
@@ -3,50 +3,101 @@ title: containerd image store with Docker Engine
 linkTitle: containerd image store
 weight: 50
 keywords: containerd, snapshotters, image store, docker engine
-description: Learn how to enable the containerd image store on Docker Engine
+description: Learn about the containerd image store
 aliases:
   - /storage/containerd/
 ---
 
-{{< summary-bar feature_name="containerd" >}}
+The containerd image store is the default storage backend for Docker Engine
+29.0 and later on fresh installations. If you upgraded from an earlier version,
+your daemon continues using the legacy graph drivers (overlay2) until you
+enable the containerd image store.
 
 containerd, the industry-standard container runtime, uses snapshotters instead
-of the classic storage drivers for storing image and container data.
-While the `overlay2` driver still remains the default driver for Docker Engine,
-you can opt in to using containerd snapshotters as an experimental feature.
+of classic storage drivers for storing image and container data.
 
-To learn more about the containerd image store and its benefits, refer to
-[containerd image store on Docker Desktop](/manuals/desktop/features/containerd.md).
+> [!NOTE]
+> The containerd image store is not available when using user namespace
+> remapping (`userns-remap`). See
+> [moby#47377](https://github.com/moby/moby/issues/47377) for details.
+
+## Why use the containerd image store
+
+The containerd image store uses snapshotters to manage how image layers are
+stored and accessed on the filesystem. This differs from the classic graph
+drivers like overlay2.
+
+The containerd image store enables:
+
+- Building and storing multi-platform images locally. With classic storage
+  drivers, you need external builders for multi-platform images.
+- Working with images that include attestations (provenance, SBOM). These use
+  image indices that the classic store doesn't support.
+- Running Wasm containers. The containerd image store supports WebAssembly
+  workloads.
+- Using advanced snapshotters. containerd supports pluggable snapshotters that
+  provide features like lazy-pulling of images (stargz) or peer-to-peer image
+  distribution (nydus, dragonfly).
+
+For most users, switching to the containerd image store is transparent. The
+storage backend changes, but your workflows remain the same.
+
+## Disk space usage
+
+The containerd image store uses more disk space than the legacy storage
+drivers for the same images. This is because containerd stores images in both
+compressed and uncompressed formats, while the legacy drivers stored only the
+uncompressed layers.
+
+When you pull an image, containerd keeps the compressed layers (as received
+from the registry) and also extracts them to disk. This dual storage means
+each layer occupies more space. The compressed format enables faster pulls and
+pushes, but requires additional disk capacity.
+
+> [!IMPORTANT]
+> containerd uses a separate storage path from the Docker data directory.
+> If you previously configured a custom data directory for Docker (for example,
+> to use a different partition), containerd's storage is not automatically
+> moved to that location. You need to configure containerd's data directory
+> separately to avoid filling your root partition.
+>
+> To configure containerd's data directory, see
+> [Configure the data directory location](../daemon/_index.md#configure-the-data-directory-location).
+
+If disk space is constrained, consider the following:
+
+- Regularly prune unused images with `docker image prune`
+- Use `docker system df` to monitor disk usage
+- [Configure the data directory](../daemon/_index.md#configure-the-data-directory-location)
+  to use a partition with adequate space
 
 ## Enable containerd image store on Docker Engine
 
-Switching to containerd snapshotters causes you to temporarily lose images and
-containers created using the classic storage drivers.
-Those resources still exist on your filesystem, and you can retrieve them by
-turning off the containerd snapshotters feature.
+If you're upgrading from an earlier Docker Engine version, you need to manually
+enable the containerd image store.
 
-The following steps explain how to enable the containerd snapshotters feature.
+> [!IMPORTANT]
+> Switching storage backends temporarily hides images and containers created
+> with the other backend. Your data remains on disk. To access the old images
+> again, switch back to your previous storage configuration.
 
-1. Add the following configuration to your `/etc/docker/daemon.json`
-   configuration file:
+Add the following configuration to your `/etc/docker/daemon.json` file:
 
-   ```json
-   {
-     "features": {
-       "containerd-snapshotter": true
-     }
-   }
-   ```
+```json
+{
+  "features": {
+    "containerd-snapshotter": true
+  }
+}
+```
 
-2. Save the file.
-3. Restart the daemon for the changes to take effect.
+Save the file and restart the daemon:
 
-   ```console
-   $ sudo systemctl restart docker
-   ```
+```console
+$ sudo systemctl restart docker
+```
 
-After restarting the daemon, running `docker info` shows that you're using
-containerd snapshotter storage drivers.
+After restarting the daemon, verify you're using the containerd image store:
 
 ```console
 $ docker info -f '{{ .DriverStatus }}'
@@ -54,3 +105,58 @@ $ docker info -f '{{ .DriverStatus }}'
 ```
 
 Docker Engine uses the `overlayfs` containerd snapshotter by default.
+
+> [!NOTE]
+> When you enable the containerd image store, existing images and containers
+> from the overlay2 driver remain on disk but become hidden. They reappear if
+> you switch back to overlay2. To use your existing images with the containerd
+> image store, push them to a registry first, or use `docker save` to export
+> them.
+
+## Experimental automatic migration
+
+Docker Engine includes an experimental feature that can automatically switch to
+the containerd image store under certain conditions. **This feature is
+experimental**. It's provided for those who want to test it, but [starting
+fresh](#enable-containerd-image-store-on-docker-engine) is the recommended
+approach.
+
+> [!CAUTION]
+> The automatic migration feature is experimental and may not work reliably in
+> all scenarios. Create backups before attempting to use it.
+
+To enable automatic migration, add the `containerd-migration` feature to your
+`/etc/docker/daemon.json`:
+
+```json
+{
+  "features": {
+    "containerd-migration": true
+  }
+}
+```
+
+You can also set the `DOCKER_MIGRATE_SNAPSHOTTER_THRESHOLD` environment
+variable to make the daemon switch automatically if you have no containers and
+your image count is at or below the threshold. For systemd:
+
+```console
+$ sudo systemctl edit docker.service
+```
+
+Add:
+
+```ini
+[Service]
+Environment="DOCKER_MIGRATE_SNAPSHOTTER_THRESHOLD=5"
+```
+
+If you have no running or stopped containers and 5 or fewer images, the daemon
+switches to the containerd image store on restart. Your overlay2 data remains
+on disk but becomes hidden.
+
+## Additional resources
+
+To learn more about the containerd image store and its capabilities in Docker
+Desktop, see
+[containerd image store on Docker Desktop](/manuals/desktop/features/containerd.md).
diff --git a/content/manuals/engine/storage/drivers/_index.md b/content/manuals/engine/storage/drivers/_index.md
index c6241730936c..9c407581d09c 100644
--- a/content/manuals/engine/storage/drivers/_index.md
+++ b/content/manuals/engine/storage/drivers/_index.md
@@ -1,6 +1,6 @@
 ---
 description: Learn the technologies that support storage drivers.
-keywords: container, storage, driver, btrfs, overlayfs, vfs, zfs
+keywords: container, storage, driver, btrfs, overlayfs, vfs, zfs, containerd
 title: Storage drivers
 weight: 40
 aliases:
@@ -9,6 +9,16 @@ aliases:
   - /engine/userguide/storagedriver/imagesandcontainers/
 ---
 
+> [!NOTE]
+> This page describes the classic storage drivers, such as `overlay2`. Docker
+> Engine 29.0 and later uses the [containerd image store](../containerd.md) by
+> default for fresh installations, which uses snapshotters instead of classic
+> storage drivers. If you're running a fresh installation of Docker Engine 29.0
+> or later, or if you've migrated to the containerd image store, the concepts on
+> this page still explain how image layers work, but the commands and examples
+> won't reflect how your system stores images. For operational guidance, see
+> [containerd image store](../containerd.md).
+
 To use storage drivers effectively, it's important to know how Docker builds and
 stores images, and how these images are used by containers. You can use this
 information to make informed choices about the best way to persist data from
@@ -170,7 +180,7 @@ docker.io/library/ubuntu:22.04
 
 Each of these layers is stored in its own directory inside the Docker host's
 local storage area. To examine the layers on the filesystem, list the contents
-of `/var/lib/docker/<storage-driver>`. This example uses the `overlay2` 
+of `/var/lib/docker/<storage-driver>`. This example uses the `overlay2`
 storage driver:
 
 ```console
@@ -326,7 +336,7 @@ layers are the same.
    Before BuildKit, the "classic" builder would produce a new "intermediate"
    image for each step for caching purposes, and the `IMAGE` column would show
    the ID of that image.
-   
+
    BuildKit uses its own caching mechanism, and no longer requires intermediate
    images for caching. Refer to [BuildKit](/manuals/build/buildkit/_index.md)
    to learn more about other enhancements made in BuildKit.
@@ -343,7 +353,7 @@ layers are the same.
      "sha256:07b4a9068b6af337e8b8f1f1dae3dd14185b2c0003a9a1f0a6fd2587495b204a"
    ]
    ```
-   
+
    ```console
    $ docker image inspect --format "{{json .RootFS.Layers}}" acme/my-final-image:1.0
    [
@@ -363,7 +373,7 @@ layers are the same.
    > [!TIP]
    >
    > Format output of Docker commands with the `--format` option.
-   > 
+   >
    > The examples above use the `docker image inspect` command with the `--format`
    > option to view the layer IDs, formatted as a JSON array. The `--format`
    > option on Docker commands can be a powerful feature that allows you to
@@ -383,16 +393,16 @@ layer. This means that the writable layer is as small as possible.
 
 When an existing file in a container is modified, the storage driver performs a
 copy-on-write operation. The specific steps involved depend on the specific
-storage driver. For the `overlay2` driver, the  copy-on-write operation follows
+storage driver. For the `overlay2` driver, the copy-on-write operation follows
 this rough sequence:
 
-*  Search through the image layers for the file to update. The process starts
-   at the newest layer and works down to the base layer one layer at a time.
-   When results are found, they're added to a cache to speed future operations.
-*  Perform a `copy_up` operation on the first copy of the file that's found, to
-   copy the file to the container's writable layer.
-*  Any modifications are made to this copy of the file, and the container can't
-   see the read-only copy of the file that exists in the lower layer.
+- Search through the image layers for the file to update. The process starts
+  at the newest layer and works down to the base layer one layer at a time.
+  When results are found, they're added to a cache to speed future operations.
+- Perform a `copy_up` operation on the first copy of the file that's found, to
+  copy the file to the container's writable layer.
+- Any modifications are made to this copy of the file, and the container can't
+  see the read-only copy of the file that exists in the lower layer.
 
 Btrfs, ZFS, and other drivers handle the copy-on-write differently. You can
 read more about the methods of these drivers later in their detailed
@@ -412,7 +422,7 @@ in a `copy_up` operation, therefore duplicating the file to the writable layer.
 > applications, for example write-intensive databases, are known to be
 > problematic particularly when pre-existing data exists in the read-only
 > layer.
-> 
+>
 > Instead, use Docker volumes, which are independent of the running container,
 > and designed to be efficient for I/O. In addition, volumes can be shared
 > among containers and don't increase the size of your container's writable
@@ -449,7 +459,6 @@ examines how much room they take up.
 2. Run the `docker ps` command with the `--size` option to verify the 5 containers
    are running, and to see each container's size.
 
-   
    ```console
    $ docker ps --size --format "table {{.ID}}\t{{.Image}}\t{{.Names}}\t{{.Size}}"
 
@@ -460,35 +469,35 @@ examines how much room they take up.
    a5ff32e2b551   acme/my-final-image:1.0   my_container_2   0B (virtual 7.75MB)
    40ebdd763416   acme/my-final-image:1.0   my_container_1   0B (virtual 7.75MB)
    ```
-   
+
    The output above shows that all containers share the image's read-only layers
    (7.75MB), but no data was written to the container's filesystem, so no additional
    storage is used for the containers.
 
    {{< accordion title="Advanced: metadata and logs storage used for containers" >}}
-   
+
    > [!NOTE]
    >
    > This step requires a Linux machine, and doesn't work on Docker Desktop, as
    > it requires access to the Docker Daemon's file storage.
-   
+
    While the output of `docker ps` provides you information about disk space
    consumed by a container's writable layer, it doesn't include information
    about metadata and log-files stored for each container.
-   
+
    More details can be obtained by exploring the Docker Daemon's storage
    location (`/var/lib/docker` by default).
-   
+
    ```console
    $ sudo du -sh /var/lib/docker/containers/*
-   
+
    36K  /var/lib/docker/containers/3ed3c1a10430e09f253704116965b01ca920202d52f3bf381fbb833b8ae356bc
    36K  /var/lib/docker/containers/40ebdd7634162eb42bdb1ba76a395095527e9c0aa40348e6c325bd0aa289423c
    36K  /var/lib/docker/containers/939b3bf9e7ece24bcffec57d974c939da2bdcc6a5077b5459c897c1e2fa37a39
    36K  /var/lib/docker/containers/a5ff32e2b551168b9498870faf16c9cd0af820edf8a5c157f7b80da59d01a107
    36K  /var/lib/docker/containers/cddae31c314fbab3f7eabeb9b26733838187abc9a2ed53f97bd5b04cd7984a5a
    ```
-   
+
    Each of these containers only takes up 36k of space on the filesystem.
 
    {{< /accordion >}}
@@ -502,13 +511,12 @@ examines how much room they take up.
    ```console
    $ for i in {1..3}; do docker exec my_container_$i sh -c 'printf hello > /out.txt'; done
    ```
-   
+
    Running the `docker ps` command again afterward shows that those containers
    now consume 5 bytes each. This data is unique to each container, and not
    shared. The read-only layers of the containers aren't affected, and are still
    shared by all containers.
 
-   
    ```console
    $ docker ps --size --format "table {{.ID}}\t{{.Image}}\t{{.Names}}\t{{.Size}}"
 
@@ -535,5 +543,5 @@ driver, a full copy of the image's data is created for each container.
 
 ## Related information
 
-* [Volumes](../volumes.md)
-* [Select a storage driver](select-storage-driver.md)
+- [Volumes](../volumes.md)
+- [Select a storage driver](select-storage-driver.md)
diff --git a/content/manuals/engine/storage/drivers/btrfs-driver.md b/content/manuals/engine/storage/drivers/btrfs-driver.md
index 720f6d59be8f..ecfa3179ea34 100644
--- a/content/manuals/engine/storage/drivers/btrfs-driver.md
+++ b/content/manuals/engine/storage/drivers/btrfs-driver.md
@@ -6,6 +6,15 @@ aliases:
   - /storage/storagedriver/btrfs-driver/
 ---
 
+> [!IMPORTANT]
+>
+> In most cases you should use the `overlay2` storage driver - it's not
+> required to use the `btrfs` storage driver simply because your system uses
+> Btrfs as its root filesystem.
+>
+> Btrfs driver has known issues. See [Moby issue #27653](https://github.com/moby/moby/issues/27653)
+> for more information.
+
 Btrfs is a copy-on-write filesystem that supports many advanced storage
 technologies, making it a good fit for Docker. Btrfs is included in the
 mainline Linux kernel.
diff --git a/content/manuals/engine/storage/drivers/device-mapper-driver.md b/content/manuals/engine/storage/drivers/device-mapper-driver.md
index 7eb9de9bb6ab..c9aa3f7d655c 100644
--- a/content/manuals/engine/storage/drivers/device-mapper-driver.md
+++ b/content/manuals/engine/storage/drivers/device-mapper-driver.md
@@ -297,7 +297,7 @@ assumes that the Docker daemon is in the `stopped` state.
     The example below adds 20% more capacity when the disk usage reaches
     80%.
 
-    ```none
+    ```text
     activation {
       thin_pool_autoextend_threshold=80
       thin_pool_autoextend_percent=20
diff --git a/content/manuals/engine/storage/drivers/overlayfs-driver.md b/content/manuals/engine/storage/drivers/overlayfs-driver.md
index 5064fb0c32b9..cdec2f68258f 100644
--- a/content/manuals/engine/storage/drivers/overlayfs-driver.md
+++ b/content/manuals/engine/storage/drivers/overlayfs-driver.md
@@ -12,13 +12,18 @@ This page refers to the Linux kernel driver as `OverlayFS` and to the Docker
 storage driver as `overlay2`.
 
 > [!NOTE]
->
+> Docker Engine 29.0 and later uses the
+> [containerd image store](/manuals/engine/storage/containerd.md) by default.
+> The `overlay2` driver is a legacy storage driver that is superseded by the
+> `overlayfs` containerd snapshotter. For more information, see
+> [Select a storage driver](/manuals/engine/storage/drivers/select-storage-driver.md).
+
+> [!NOTE]
 > For `fuse-overlayfs` driver, check [Rootless mode documentation](/manuals/engine/security/rootless.md).
 
 ## Prerequisites
 
-OverlayFS is the recommended storage driver, and supported if you meet the following
-prerequisites:
+The `overlay2` driver is supported if you meet the following prerequisites:
 
 - Version 4.0 or higher of the Linux kernel, or RHEL or CentOS using
   version 3.10.0-514 of the kernel or higher.
@@ -219,7 +224,7 @@ the image's top layer plus a new directory for the container. The image's
 layers are the `lowerdirs` in the overlay and are read-only. The new directory for
 the container is the `upperdir` and is writable.
 
-### Image and container layers on-disk
+### Image and container layers on-disk (legacy overlay driver)
 
 The following `docker pull` command shows a Docker host downloading a Docker
 image comprising five layers.
@@ -437,25 +442,25 @@ filesystems:
 
 [`open(2)`](https://linux.die.net/man/2/open)
 : OverlayFS only implements a subset of the POSIX standards.
-  This can result in certain OverlayFS operations breaking POSIX standards. One
-  such operation is the copy-up operation. Suppose that your application calls
-  `fd1=open("foo", O_RDONLY)` and then `fd2=open("foo", O_RDWR)`. In this case,
-  your application expects `fd1` and `fd2` to refer to the same file. However, due
-  to a copy-up operation that occurs after the second calling to `open(2)`, the
-  descriptors refer to different files. The `fd1` continues to reference the file
-  in the image (`lowerdir`) and the `fd2` references the file in the container
-  (`upperdir`). A workaround for this is to `touch` the files which causes the
-  copy-up operation to happen. All subsequent `open(2)` operations regardless of
-  read-only or read-write access mode reference the file in the
-  container (`upperdir`).
-
-  `yum` is known to be affected unless the `yum-plugin-ovl` package is installed.
-  If the `yum-plugin-ovl` package is not available in your distribution such as
-  RHEL/CentOS prior to 6.8 or 7.2, you may need to run `touch /var/lib/rpm/*`
-  before running `yum install`. This package implements the `touch` workaround
-  referenced above for `yum`.
+This can result in certain OverlayFS operations breaking POSIX standards. One
+such operation is the copy-up operation. Suppose that your application calls
+`fd1=open("foo", O_RDONLY)` and then `fd2=open("foo", O_RDWR)`. In this case,
+your application expects `fd1` and `fd2` to refer to the same file. However, due
+to a copy-up operation that occurs after the second calling to `open(2)`, the
+descriptors refer to different files. The `fd1` continues to reference the file
+in the image (`lowerdir`) and the `fd2` references the file in the container
+(`upperdir`). A workaround for this is to `touch` the files which causes the
+copy-up operation to happen. All subsequent `open(2)` operations regardless of
+read-only or read-write access mode reference the file in the
+container (`upperdir`).
+
+`yum` is known to be affected unless the `yum-plugin-ovl` package is installed.
+If the `yum-plugin-ovl` package is not available in your distribution such as
+RHEL/CentOS prior to 6.8 or 7.2, you may need to run `touch /var/lib/rpm/*`
+before running `yum install`. This package implements the `touch` workaround
+referenced above for `yum`.
 
 [`rename(2)`](https://linux.die.net/man/2/rename)
 : OverlayFS does not fully support the `rename(2)` system call. Your
-  application needs to detect its failure and fall back to a "copy and unlink"
-  strategy.
+application needs to detect its failure and fall back to a "copy and unlink"
+strategy.
diff --git a/content/manuals/engine/storage/drivers/select-storage-driver.md b/content/manuals/engine/storage/drivers/select-storage-driver.md
index fe441ce5fc83..0367e6456fde 100644
--- a/content/manuals/engine/storage/drivers/select-storage-driver.md
+++ b/content/manuals/engine/storage/drivers/select-storage-driver.md
@@ -2,7 +2,7 @@
 title: Select a storage driver
 weight: 10
 description: Learn how to select the proper storage driver for your container.
-keywords: container, storage, driver, btrfs, zfs, overlay, overlay2
+keywords: container, storage, driver, btrfs, zfs, overlay, overlay2, containerd
 aliases:
   - /storage/storagedriver/selectadriver/
   - /storage/storagedriver/select-storage-driver/
@@ -13,6 +13,14 @@ use Docker volumes to write data. However, some workloads require you to be able
 to write to the container's writable layer. This is where storage drivers come
 in.
 
+> [!NOTE]
+> Docker Engine 29.0 and later uses the
+> [containerd image store](../containerd.md) by default for fresh installations.
+> If you upgraded from an earlier version, your daemon continues using the
+> classic storage drivers described on this page. You can migrate to the
+> containerd image store following the instructions in the
+> [containerd image store](../containerd.md) documentation.
+
 Docker supports several storage drivers, using a pluggable architecture. The
 storage driver controls how images and containers are stored and managed on your
 Docker host. After you have read the [storage driver overview](./_index.md), the
@@ -25,21 +33,22 @@ driver with the best overall performance and stability in the most usual scenari
 > storage driver is windowsfilter. For more information, see
 > [windowsfilter](windowsfilter-driver.md).
 
-The Docker Engine provides the following storage drivers on Linux:
+The Docker Engine provides the following storage backends on Linux:
 
-| Driver            | Description                                                                                                                                                                                                                                                                                                                                          |
-| :---------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `overlay2`        | `overlay2` is the preferred storage driver for all currently supported Linux distributions, and requires no extra configuration.                                                                                                                                                                                                                     |
-| `fuse-overlayfs`  | `fuse-overlayfs`is preferred only for running Rootless Docker on an old host that does not provide support for rootless `overlay2`. The `fuse-overlayfs` driver does not need to be used since Linux kernel 5.11, and `overlay2` works even in rootless mode. Refer to the [rootless mode documentation](/manuals/engine/security/rootless.md) for details. |
-| `btrfs` and `zfs` | The `btrfs` and `zfs` storage drivers allow for advanced options, such as creating "snapshots", but require more maintenance and setup. Each of these relies on the backing filesystem being configured correctly.                                                                                                                                   |
-| `vfs`             | The `vfs` storage driver is intended for testing purposes, and for situations where no copy-on-write filesystem can be used. Performance of this storage driver is poor, and is not generally recommended for production use.                                                                                                                        |
+| Backend                     | Description                                                                                                                                                                                                                                                |
+| :-------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `containerd` (snapshotters) | The default for Docker Engine 29.0 and later. Uses containerd snapshotters for image storage. Supports multi-platform images and attestations. See [containerd image store](../containerd.md) for details.                                                 |
+| `overlay2`                  | Classic storage driver. Most widely compatible across all currently supported Linux distributions, and requires no extra configuration.                                                                                                                    |
+| `fuse-overlayfs`            | Preferred only for running Rootless Docker on hosts that don't support rootless `overlay2`. Not needed since Linux kernel 5.11, as `overlay2` works in rootless mode. See [rootless mode documentation](/manuals/engine/security/rootless.md) for details. |
+| `btrfs` and `zfs`           | Allow for advanced options, such as creating snapshots, but require more maintenance and setup. Each relies on the backing filesystem being configured correctly.                                                                                          |
+| `vfs`                       | Intended for testing purposes, and for situations where no copy-on-write filesystem can be used. Performance is poor, and not generally recommended for production use.                                                                                    |
 
 <!-- markdownlint-disable reference-links-images -->
 
 The Docker Engine has a prioritized list of which storage driver to use if no
 storage driver is explicitly configured, assuming that the storage driver meets
 the prerequisites, and automatically selects a compatible storage driver. You
-can see the order in the [source code for Docker Engine {{% param "docker_ce_version" %}}](https://github.com/moby/moby/blob/v{{% param "docker_ce_version" %}}/daemon/graphdriver/driver_linux.go#L52-L53).
+can see the order in the [source code for Docker Engine {{% param "docker_ce_version" %}}](https://github.com/moby/moby/blob/docker-v{{% param "docker_ce_version" %}}/daemon/graphdriver/driver_linux.go).
 { #storage-driver-order }
 
 <!-- markdownlint-enable reference-links-images -->
@@ -56,32 +65,35 @@ the final decision.
 ## Supported storage drivers per Linux distribution
 
 > [!NOTE]
->
 > Modifying the storage driver by editing the daemon configuration file isn't
-> supported on Docker Desktop. Only the default `overlay2` driver or the
-> [containerd storage](/manuals/desktop/features/containerd.md) are supported. The
-> following table is also not applicable for the Docker Engine in rootless
-> mode. For the drivers available in rootless mode, see the [Rootless mode
-> documentation](/manuals/engine/security/rootless.md).
-
-Your operating system and kernel may not support every storage driver. For
-example, `btrfs` is only supported if your system uses `btrfs` as storage. In
-general, the following configurations work on recent versions of the Linux
+> supported on Docker Desktop. Docker Desktop uses the
+> [containerd image store](/manuals/desktop/features/containerd.md) by default
+> (version 4.34 and later for clean installs). The following table is also not
+> applicable for the Docker Engine in rootless mode. For the drivers available
+> in rootless mode, see the
+> [Rootless mode documentation](/manuals/engine/security/rootless.md).
+
+This section applies to classic storage drivers only. If you're using the
+containerd image store (the default for Docker Engine 29.0+), see the
+[containerd image store documentation](../containerd.md) instead.
+
+Your operating system and kernel may not support every classic storage driver.
+For example, `btrfs` is only supported if your system uses `btrfs` as storage.
+In general, the following configurations work on recent versions of the Linux
 distribution:
 
-| Linux distribution   | Recommended storage drivers  | Alternative drivers  |
-| :------------------- | :--------------------------- | :------------------- |
-| Ubuntu               | `overlay2`                   | `zfs`, `vfs`         |
-| Debian               | `overlay2`                   | `vfs`                |
-| CentOS               | `overlay2`                   | `zfs`, `vfs`         |
-| Fedora               | `overlay2`                   | `zfs`, `vfs`         |
-| SLES 15              | `overlay2`                   | `vfs`                |
-| RHEL                 | `overlay2`                   | `vfs`                |
+| Linux distribution   | Default classic driver  | Alternative drivers  |
+| :------------------- | :---------------------- | :------------------- |
+| Ubuntu               | `overlay2`              | `zfs`, `vfs`         |
+| Debian               | `overlay2`              | `vfs`                |
+| CentOS               | `overlay2`              | `zfs`, `vfs`         |
+| Fedora               | `overlay2`              | `zfs`, `vfs`         |
+| SLES 15              | `overlay2`              | `vfs`                |
+| RHEL                 | `overlay2`              | `vfs`                |
 
-When in doubt, the best all-around configuration is to use a modern Linux
-distribution with a kernel that supports the `overlay2` storage driver, and to
-use Docker volumes for write-heavy workloads instead of relying on writing data
-to the container's writable layer.
+For systems using classic storage drivers, `overlay2` provides broad
+compatibility across Linux distributions. Use Docker volumes for write-heavy
+workloads instead of relying on writing data to the container's writable layer.
 
 The `vfs` storage driver is usually not the best choice, and primarily intended
 for debugging purposes in situations where no other storage-driver is supported.
@@ -108,13 +120,20 @@ With regard to Docker, the backing filesystem is the filesystem where
 `/var/lib/docker/` is located. Some storage drivers only work with specific
 backing filesystems.
 
-| Storage driver   | Supported backing filesystems |
-| :--------------- | :---------------------------- |
-| `overlay2`       | `xfs` with ftype=1, `ext4`    |
-| `fuse-overlayfs` | any filesystem                |
-| `btrfs`          | `btrfs`                       |
-| `zfs`            | `zfs`                         |
-| `vfs`            | any filesystem                |
+| Storage driver   | Supported backing filesystems                         |
+| :--------------- | :-----------------------------------------------------|
+| `overlay2`       | `xfs` with ftype=1, `ext4`, `btrfs`, (and more)     |
+| `fuse-overlayfs` | any filesystem                                        |
+| `btrfs`          | `btrfs`                                               |
+| `zfs`            | `zfs`                                                 |
+| `vfs`            | any filesystem                                        |
+
+> [!NOTE]
+>
+> Most filesystems should work if they have the required features.
+> Consult [OverlayFS](https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html)
+> for more information.
+
 
 ## Other considerations
 
diff --git a/content/manuals/engine/storage/image-mounts.md b/content/manuals/engine/storage/image-mounts.md
new file mode 100644
index 000000000000..0d616670ff60
--- /dev/null
+++ b/content/manuals/engine/storage/image-mounts.md
@@ -0,0 +1,208 @@
+---
+description: Using image mounts
+title: Image mounts
+weight: 40
+keywords: storage, mounts, image mounts, image mount
+---
+
+[Volumes](volumes.md), [bind mounts](bind-mounts.md), and [tmpfs mounts](tmpfs.md)
+all give a container a place to read and write data. An image mount is
+different: instead of mounting a directory or a memory-backed filesystem, it
+mounts the contents of another image into the container.
+
+When you use an image mount, the filesystem of a second image is mounted into
+the container at a path you choose. The container can read the files from that
+image alongside its own filesystem, without those files being part of the
+container's own image. This is useful when you want to bring the tools or assets
+from one image into a container that's running a different image.
+
+Image mounts are read-only. The mounted image is never modified, and the
+container can't write to the mount.
+
+> [!NOTE]
+> Image mounts require the [containerd image store](containerd.md).
+
+## When to use image mounts
+
+Image mounts are appropriate for the following types of use case:
+
+- Debugging a minimal or hardened image that doesn't include a shell or common
+  utilities. You can mount a tool-rich image, such as `busybox`, into the
+  running container's namespace and run those tools without changing the
+  original image. For a worked example, see
+  [Debug with Docker Hardened Images](/manuals/dhi/how-to/troubleshoot.md).
+
+- Sharing read-only assets, such as datasets, models, or static content, that
+  are distributed as an image and consumed by containers running a different
+  image.
+
+- Keeping application images small by packaging optional tooling in a separate
+  image and mounting it only when needed.
+
+## Mounting over existing data
+
+If you mount an image into a directory in the container in which files or
+directories exist, the pre-existing files are obscured by the mount. This is
+similar to if you were to save files into `/mnt` on a Linux host, and then
+mounted a USB drive into `/mnt`. The contents of `/mnt` would be obscured by the
+contents of the USB drive until the USB drive was unmounted.
+
+With containers, there's no straightforward way of removing a mount to reveal
+the obscured files again. Your best option is to recreate the container without
+the mount.
+
+## Considerations and constraints
+
+- Image mounts are always read-only. The container can't modify the mounted
+  image, and changes aren't persisted anywhere.
+
+- The source image must already exist in the daemon's image store. Docker
+  doesn't pull the source image automatically when you create the mount. If the
+  image isn't present, the command fails:
+
+  ```console
+  $ docker run --mount type=image,source=busybox:musl,destination=/dbg alpine
+  docker: Error response from daemon: No such image: busybox:musl
+  ```
+
+  Pull the image first with `docker pull`, then create the mount.
+
+- Image mounts require the [containerd image store](containerd.md). They aren't
+  available when the daemon uses the classic storage drivers.
+
+- You can only create an image mount with the `--mount` flag. There is no
+  `--volume` (`-v`) equivalent.
+
+- Running an executable from a mounted image requires a compatible runtime in
+  the container. A dynamically linked binary only runs if the container provides
+  a matching dynamic linker and shared libraries. For example, a glibc-based
+  binary fails in a musl-based image such as Alpine. Statically linked binaries,
+  or mounting only data from an image, avoid this constraint.
+
+## Syntax
+
+To mount an image with the `docker run` command, use the `--mount` flag with
+`type=image`.
+
+```console
+$ docker run --mount type=image,src=<image-reference>,dst=<container-path>
+```
+
+The `--mount` flag consists of multiple key-value pairs, separated by commas and
+each consisting of a `<key>=<value>` tuple. The order of the keys isn't
+significant.
+
+```console
+$ docker run --mount type=image,src=<image-reference>,dst=<container-path>[,<key>=<value>...]
+```
+
+### Options for --mount
+
+Valid options for `--mount type=image` include:
+
+| Option                         | Description                                                                                                                       |
+| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- |
+| `source`, `src`                | The reference of the image to mount, for example `busybox` or `busybox:musl`. The image must exist locally.                       |
+| `destination`, `dst`, `target` | The path where the image is mounted in the container. Must be an absolute path.                                                   |
+| `image-subpath`                | Path inside the source image to mount instead of the image root. See [Mount a subpath of an image](#mount-a-subpath-of-an-image). |
+
+```console {title="Example"}
+$ docker run --mount type=image,src=busybox,dst=/dbg,image-subpath=bin
+```
+
+## Use an image mount in a container
+
+The following example runs an Alpine container and mounts the `busybox:musl`
+image at `/dbg`. Pull the source image first, since Docker doesn't pull it for
+you when creating the mount. This example uses the musl-based BusyBox image so
+its binaries are compatible with the musl-based Alpine container.
+
+```console
+$ docker pull busybox:musl
+$ docker run -d \
+  -it \
+  --name imgtest \
+  --mount type=image,source=busybox:musl,destination=/dbg \
+  alpine:latest
+```
+
+The container can now read the BusyBox tools from `/dbg` while running the Alpine
+image:
+
+```console
+$ docker exec imgtest /dbg/bin/echo "hello from busybox"
+hello from busybox
+```
+
+Verify that the mount is an `image` mount by looking in the `Mounts` section of
+the `docker inspect` output:
+
+```console
+$ docker inspect imgtest --format '{{ json .Mounts }}'
+[{"Type":"image","Name":"busybox:musl","Source":"/var/lib/docker/rootfs/overlayfs/...","Destination":"/dbg","Mode":"","RW":false,"Propagation":"rprivate"}]
+```
+
+This shows that the mount is an `image` mount, that its source is the
+`busybox:musl` image, and that it's read-only (`"RW":false`).
+
+Stop and remove the container:
+
+```console
+$ docker container rm -fv imgtest
+```
+
+## Mount a subpath of an image
+
+Use the `image-subpath` option to mount a specific directory from the source
+image instead of its root. For example, to mount only the `bin` directory of the
+`busybox` image at `/tools`:
+
+```console
+$ docker run -d \
+  -it \
+  --name imgtest \
+  --mount type=image,source=busybox,destination=/tools,image-subpath=bin \
+  alpine:latest
+```
+
+The container sees the contents of the image's `bin` directory at `/tools`.
+
+## Use an image mount with Docker Compose
+
+A single Docker Compose service with an image mount looks like this:
+
+```yaml
+services:
+  app:
+    image: alpine:latest
+    volumes:
+      - type: image
+        source: busybox
+        target: /dbg
+```
+
+To mount a subpath of the image, use the `subpath` option under `image`:
+
+```yaml
+services:
+  app:
+    image: alpine:latest
+    volumes:
+      - type: image
+        source: busybox
+        target: /tools
+        image:
+          subpath: bin
+```
+
+The `image.subpath` option is available in Docker Compose version 2.35.0 and
+later. For more information about using mounts of the `image` type with Compose,
+see the
+[Compose reference on the volume attribute](/reference/compose-file/services.md#volumes).
+
+## Next steps
+
+- Learn about [volumes](./volumes.md).
+- Learn about [bind mounts](./bind-mounts.md).
+- Learn about [tmpfs mounts](./tmpfs.md).
+- Learn about [storage drivers](/engine/storage/drivers/).
diff --git a/content/manuals/engine/storage/tmpfs.md b/content/manuals/engine/storage/tmpfs.md
index 29473ada2bad..b942b417706d 100644
--- a/content/manuals/engine/storage/tmpfs.md
+++ b/content/manuals/engine/storage/tmpfs.md
@@ -20,6 +20,13 @@ As opposed to volumes and bind mounts, a tmpfs mount is temporary, and only
 persisted in the host memory. When the container stops, the tmpfs mount is
 removed, and files written there won't be persisted.
 
+Because tmpfs stores data in memory, that usage counts against the container's
+memory cgroup limit (`--memory` / Compose `mem_limit`). Setting a large
+`tmpfs-size` (or host-mounted tmpfs) does not give the container extra RAM
+outside that limit — filling the mount can still OOM the container. Memory
+metrics for the container include tmpfs usage; see
+[runtime metrics](/manuals/engine/containers/runmetrics.md).
+
 tmpfs mounts are best used for cases when you do not want the data to persist
 either on the host machine or within the container. This may be for security
 reasons or to protect the performance of the container when your application
@@ -47,6 +54,8 @@ the mount.
 
 - Unlike volumes and bind mounts, you can't share tmpfs mounts between containers.
 - This functionality is only available if you're running Docker on Linux.
+- Data on a tmpfs mount counts toward the container memory limit. A large
+  `size=` value does not raise that limit.
 - Setting permissions on tmpfs may cause them to [reset after container restart](https://github.com/docker/for-linux/issues/138). In some cases [setting the uid/gid](https://github.com/docker/compose/issues/3425#issuecomment-423091370) can serve as a workaround.
 
 ## Syntax
@@ -203,4 +212,5 @@ $ docker rm tmptest
 
 - Learn about [volumes](volumes.md)
 - Learn about [bind mounts](bind-mounts.md)
+- Learn about [image mounts](image-mounts.md)
 - Learn about [storage drivers](/engine/storage/drivers/)
diff --git a/content/manuals/engine/storage/volumes.md b/content/manuals/engine/storage/volumes.md
index a62ca6f0facd..1a7184c1ba92 100644
--- a/content/manuals/engine/storage/volumes.md
+++ b/content/manuals/engine/storage/volumes.md
@@ -403,9 +403,8 @@ $ docker volume rm nginx-vol
 
 ## Use a read-only volume
 
-For some development applications, the container needs to write into the bind
-mount so that changes are propagated back to the Docker host. At other times,
-the container only needs read access to the data. Multiple
+For some applications, the container needs to write to the volume. At other
+times, the container only needs read access to the data. Multiple
 containers can mount the same volume. You can simultaneously mount a
 single volume as `read-write` for some containers and as `read-only` for others.
 
@@ -625,7 +624,7 @@ $ docker volume create \
 	--opt type=cifs \
 	--opt device=//uxxxxx.your-server.de/backup \
 	--opt o=addr=uxxxxx.your-server.de,username=uxxxxxxx,password=*****,file_mode=0777,dir_mode=0777 \
-	--name cif-volume
+	--name cifs-volume
 ```
 
 The `addr` option is required if you specify a hostname instead of an IP.
@@ -775,8 +774,8 @@ testing using your preferred tools.
 A Docker data volume persists after you delete a container. There are two types
 of volumes to consider:
 
-- Named volumes have a specific source from outside the container, for example, `awesome:/bar`.
-- Anonymous volumes have no specific source. Therefore, when the container is deleted, you can instruct the Docker Engine daemon to remove them.
+- Named volumes have a specific name, for example, `awesome:/bar`, where `awesome` is the name.
+- Anonymous volumes have no specific name. Therefore, when the container is deleted, you can instruct the Docker Engine daemon to remove them.
 
 ### Remove anonymous volumes
 
@@ -784,6 +783,9 @@ To automatically remove anonymous volumes, use the `--rm` option. For example,
 this command creates an anonymous `/foo` volume. When you remove the container,
 the Docker Engine removes the `/foo` volume but not the `awesome` volume.
 
+The `--rm` option works with both foreground and detached (`-d`) containers.
+The anonymous volumes are cleaned up when the container exits.
+
 ```console
 $ docker run --rm -v /foo -v awesome:/bar busybox top
 ```
@@ -806,5 +808,6 @@ $ docker volume prune
 
 - Learn about [bind mounts](bind-mounts.md).
 - Learn about [tmpfs mounts](tmpfs.md).
+- Learn about [image mounts](image-mounts.md).
 - Learn about [storage drivers](/engine/storage/drivers/).
 - Learn about [third-party volume driver plugins](/engine/extend/legacy_plugins/).
diff --git a/content/manuals/engine/swarm/_index.md b/content/manuals/engine/swarm/_index.md
index 0635ed1ce453..d7859f7a9940 100644
--- a/content/manuals/engine/swarm/_index.md
+++ b/content/manuals/engine/swarm/_index.md
@@ -130,12 +130,12 @@ roll back to a previous version of the service.
 * Learn Swarm mode [key concepts](key-concepts.md).
 * Get started with the [Swarm mode tutorial](swarm-tutorial/_index.md).
 * Explore Swarm mode CLI commands
-  * [swarm init](/reference/cli/docker/swarm/init.md)
-  * [swarm join](/reference/cli/docker/swarm/join.md)
-  * [service create](/reference/cli/docker/service/create.md)
-  * [service inspect](/reference/cli/docker/service/inspect.md)
-  * [service ls](/reference/cli/docker/service/ls.md)
-  * [service rm](/reference/cli/docker/service/rm.md)
-  * [service scale](/reference/cli/docker/service/scale.md)
-  * [service ps](/reference/cli/docker/service/ps.md)
-  * [service update](/reference/cli/docker/service/update.md)
+  * [swarm init](/reference/cli/docker/swarm/init/)
+  * [swarm join](/reference/cli/docker/swarm/join/)
+  * [service create](/reference/cli/docker/service/create/)
+  * [service inspect](/reference/cli/docker/service/inspect/)
+  * [service ls](/reference/cli/docker/service/ls/)
+  * [service rm](/reference/cli/docker/service/rm/)
+  * [service scale](/reference/cli/docker/service/scale/)
+  * [service ps](/reference/cli/docker/service/ps/)
+  * [service update](/reference/cli/docker/service/update/)
diff --git a/content/manuals/engine/swarm/admin_guide.md b/content/manuals/engine/swarm/admin_guide.md
index d63579a8442f..777812222a9a 100644
--- a/content/manuals/engine/swarm/admin_guide.md
+++ b/content/manuals/engine/swarm/admin_guide.md
@@ -154,7 +154,7 @@ worker nodes that do not meet these requirements cannot run these tasks.
 
 You can monitor the health of manager nodes by querying the docker `nodes` API
 in JSON format through the `/nodes` HTTP endpoint. Refer to the
-[nodes API documentation](/reference/api/engine/v1.25/#tag/Node)
+[nodes API documentation](/reference/api/engine/version/v1.25/#tag/Node)
 for more information.
 
 From the command line, run `docker node inspect <id-node>` to query the nodes.
@@ -221,7 +221,7 @@ the `docker node rm` command. If a node becomes unreachable, unresponsive, or
 compromised you can forcefully remove the node without shutting it down by
 passing the `--force` flag. For instance, if `node9` becomes compromised:
 
-```none
+```console
 $ docker node rm node9
 
 Error response from daemon: rpc error: code = 9 desc = node node9 is not down and can't be removed
@@ -338,7 +338,7 @@ If you lose the quorum of managers, you cannot administer the swarm. If you have
 lost the quorum and you attempt to perform any management operation on the swarm,
 an error occurs:
 
-```none
+```text
 Error response from daemon: rpc error: code = 4 desc = context deadline exceeded
 ```
 
@@ -395,5 +395,5 @@ down to the original scale. You can use `docker service ps` to assess the curren
 balance of your service across nodes.
 
 See also
-[`docker service scale`](/reference/cli/docker/service/scale.md) and
-[`docker service ps`](/reference/cli/docker/service/ps.md).
+[`docker service scale`](/reference/cli/docker/service/scale/) and
+[`docker service ps`](/reference/cli/docker/service/ps/).
diff --git a/content/manuals/engine/swarm/configs.md b/content/manuals/engine/swarm/configs.md
index 7d2d5acba889..76502e97ef57 100644
--- a/content/manuals/engine/swarm/configs.md
+++ b/content/manuals/engine/swarm/configs.md
@@ -113,10 +113,10 @@ those remaining after a `docker service update --config-rm`.
 Use these links to read about specific commands, or continue to the
 [example about using configs with a service](#advanced-example-use-configs-with-a-nginx-service).
 
-- [`docker config create`](/reference/cli/docker/config/create.md)
-- [`docker config inspect`](/reference/cli/docker/config/inspect.md)
-- [`docker config ls`](/reference/cli/docker/config/ls.md)
-- [`docker config rm`](/reference/cli/docker/config/rm.md)
+- [`docker config create`](/reference/cli/docker/config/create/)
+- [`docker config inspect`](/reference/cli/docker/config/inspect/)
+- [`docker config ls`](/reference/cli/docker/config/ls/)
+- [`docker config rm`](/reference/cli/docker/config/rm/)
 
 ## Examples
 
@@ -133,7 +133,7 @@ Docker configs.
 
 The `docker stack` command supports defining configs in a Compose file.
 However, the `configs` key is not supported for `docker compose`. See
-[the Compose file reference](/reference/compose-file/legacy-versions.md) for details.
+[the Compose file reference](/reference/compose-file/configs.md) for details.
 
 ### Simple example: Get started with configs
 
@@ -216,7 +216,7 @@ real-world example, continue to
     to the config. The container ID is different, because the
     `service update` command redeploys the service.
 
-    ```none
+    ```console
     $ docker container exec -it $(docker ps --filter name=redis -q) cat /my-config
 
     cat: can't open '/my-config': No such file or directory
@@ -248,7 +248,7 @@ This example assumes that you have PowerShell installed.
       </body>
     </html>
     ```
- 
+
 2.  If you have not already done so, initialize or join the swarm.
 
     ```powershell
@@ -373,7 +373,7 @@ generate the site key and certificate, name the files `site.key` and
     the following contents into it. This constrains the root CA to only sign
     leaf certificates and not intermediate CAs.
 
-    ```none
+    ```ini
     [root_ca]
     basicConstraints = critical,CA:TRUE,pathlen:1
     keyUsage = critical, nonRepudiation, cRLSign, keyCertSign
@@ -407,7 +407,7 @@ generate the site key and certificate, name the files `site.key` and
     certificate so that it can only be used to authenticate a server and
     can't be used to sign certificates.
 
-    ```none
+    ```ini
     [server]
     authorityKeyIdentifier=keyid,issuer
     basicConstraints = critical,CA:FALSE
@@ -438,7 +438,7 @@ generate the site key and certificate, name the files `site.key` and
     In the current directory, create a new file called `site.conf` with the
     following contents:
 
-    ```none
+    ```nginx
     server {
         listen                443 ssl;
         server_name           localhost;
@@ -616,7 +616,7 @@ configuration file.
 1.  Edit the `site.conf` file locally. Add `index.php` to the `index` line, and
     save the file.
 
-    ```none
+    ```nginx
     server {
         listen                443 ssl;
         server_name           localhost;
diff --git a/content/manuals/engine/swarm/how-swarm-mode-works/nodes.md b/content/manuals/engine/swarm/how-swarm-mode-works/nodes.md
index 10aae0ee09cd..fc0117186539 100644
--- a/content/manuals/engine/swarm/how-swarm-mode-works/nodes.md
+++ b/content/manuals/engine/swarm/how-swarm-mode-works/nodes.md
@@ -67,17 +67,17 @@ gracefully stops tasks on nodes in `Drain` mode and schedules the tasks on an
 `Active` node. The scheduler does not assign new tasks to nodes with `Drain`
 availability.
 
-Refer to the [`docker node update`](/reference/cli/docker/node/update.md)
+Refer to the [`docker node update`](/reference/cli/docker/node/update/)
 command line reference to see how to change node availability.
 
 ## Change roles
 
 You can promote a worker node to be a manager by running `docker node promote`.
 For example, you may want to promote a worker node when you
-take a manager node offline for maintenance. See [node promote](/reference/cli/docker/node/promote.md).
+take a manager node offline for maintenance. See [node promote](/reference/cli/docker/node/promote/).
 
 You can also demote a manager node to a worker node. See
-[node demote](/reference/cli/docker/node/demote.md).
+[node demote](/reference/cli/docker/node/demote/).
 
 
 ## Learn more
diff --git a/content/manuals/engine/swarm/how-swarm-mode-works/pki.md b/content/manuals/engine/swarm/how-swarm-mode-works/pki.md
index d0ba71f22a40..67dbb9cdd985 100644
--- a/content/manuals/engine/swarm/how-swarm-mode-works/pki.md
+++ b/content/manuals/engine/swarm/how-swarm-mode-works/pki.md
@@ -14,7 +14,7 @@ as a manager node. By default, the manager node generates a new root Certificate
 Authority (CA) along with a key pair, which are used to secure communications
 with other nodes that join the swarm. If you prefer, you can specify your own
 externally-generated root CA, using the `--external-ca` flag of the
-[docker swarm init](/reference/cli/docker/swarm/init.md) command.
+[docker swarm init](/reference/cli/docker/swarm/init/) command.
 
 The manager node also generates two tokens to use when you join additional nodes
 to the swarm: one worker token and one manager token. Each token
@@ -36,7 +36,7 @@ communications using a minimum of TLS 1.2.
 
 The example below shows the information from a certificate from a worker node:
 
-```none
+```text
 Certificate:
     Data:
         Version: 3 (0x2)
@@ -55,7 +55,7 @@ By default, each node in the swarm renews its certificate every three months.
 You can configure this interval by running the `docker swarm update
 --cert-expiry <TIME PERIOD>` command. The minimum rotation value is 1 hour.
 Refer to the
-[docker swarm update](/reference/cli/docker/swarm/update.md) CLI
+[docker swarm update](/reference/cli/docker/swarm/update/) CLI
 reference for details.
 
 ## Rotating the CA certificate
diff --git a/content/manuals/engine/swarm/how-swarm-mode-works/services.md b/content/manuals/engine/swarm/how-swarm-mode-works/services.md
index 1e75b9d11265..9983832e6c63 100644
--- a/content/manuals/engine/swarm/how-swarm-mode-works/services.md
+++ b/content/manuals/engine/swarm/how-swarm-mode-works/services.md
@@ -15,11 +15,11 @@ When you create a service, you specify which container image to use and which
 commands to execute inside running containers. You also define options for the
 service including:
 
-* The port where the swarm makes the service available outside the swarm
-* An overlay network for the service to connect to other services in the swarm
-* CPU and memory limits and reservations
-* A rolling update policy
-* The number of replicas of the image to run in the swarm
+- The port where the swarm makes the service available outside the swarm
+- An overlay network for the service to connect to other services in the swarm
+- CPU and memory limits and reservations
+- A rolling update policy
+- The number of replicas of the image to run in the swarm
 
 ## Services, tasks, and containers
 
@@ -32,7 +32,7 @@ For example, imagine you want to load balance between three instances of an HTTP
 listener. The diagram below shows an HTTP listener service with three replicas.
 Each of the three instances of the listener is a task in the swarm.
 
-![ HTTP listener service with three replicas](../images/services-diagram.webp?w=550)
+![HTTP listener service with three replicas](../images/services-diagram.webp?w=550)
 
 A container is an isolated process. In the Swarm mode model, each task invokes
 exactly one container. A task is analogous to a “slot” where the scheduler
@@ -53,7 +53,7 @@ fails its health check or crashes, the orchestrator creates a new replica task
 that spawns a new container.
 
 A task is a one-directional mechanism. It progresses monotonically through a
-series of states: assigned, prepared, running, etc. If the task fails, the
+series of states: `ASSIGNED`, `PREPARING`, `RUNNING`, etc. If the task fails, the
 orchestrator removes the task and its container and then creates a new task to
 replace it according to the desired state specified by the service.
 
@@ -61,8 +61,7 @@ The underlying logic of Docker's Swarm mode is a general purpose scheduler and
 orchestrator. The service and task abstractions themselves are unaware of the
 containers they implement. Hypothetically, you could implement other types of
 tasks such as virtual machine tasks or non-containerized process tasks. The
-scheduler and orchestrator are agnostic about the type of the task. However, the
-current version of Docker only supports container tasks.
+scheduler and orchestrator are agnostic about the type of the task. However, Docker only supports container tasks.
 
 The diagram below shows how Swarm mode accepts service create requests and
 schedules tasks to worker nodes.
@@ -121,5 +120,5 @@ in black.
 
 ## Learn more
 
-* Read about how Swarm mode [nodes](nodes.md) work.
-* Learn how [PKI](pki.md) works in Swarm mode.
+- Read about how Swarm mode [nodes](nodes.md) work.
+- Learn how [PKI](pki.md) works in Swarm mode.
diff --git a/content/manuals/engine/swarm/how-swarm-mode-works/swarm-task-states.md b/content/manuals/engine/swarm/how-swarm-mode-works/swarm-task-states.md
index 06ccbce3d869..38e8ab9e0781 100644
--- a/content/manuals/engine/swarm/how-swarm-mode-works/swarm-task-states.md
+++ b/content/manuals/engine/swarm/how-swarm-mode-works/swarm-task-states.md
@@ -59,4 +59,4 @@ j91iahr8s74p    \_ webserver.1   nginx    UbuntuVM    Shutdown       Failed 50 s
 
 ## Where to go next
 
-- [Learn about swarm tasks](https://github.com/docker/swarmkit/blob/master/design/task_model.md)
+- [Learn about swarm tasks](https://github.com/moby/swarmkit/blob/master/design/task_model.md)
diff --git a/content/manuals/engine/swarm/join-nodes.md b/content/manuals/engine/swarm/join-nodes.md
index c66588a930e0..42e8e6d2e4d8 100644
--- a/content/manuals/engine/swarm/join-nodes.md
+++ b/content/manuals/engine/swarm/join-nodes.md
@@ -98,5 +98,5 @@ This node joined a swarm as a manager.
 
 ## Learn More
 
-* `swarm join` [command line reference](/reference/cli/docker/swarm/join.md)
+* `swarm join` [command line reference](/reference/cli/docker/swarm/join/)
 * [Swarm mode tutorial](swarm-tutorial/_index.md)
diff --git a/content/manuals/engine/swarm/manage-nodes.md b/content/manuals/engine/swarm/manage-nodes.md
index bd50e2070838..151ee84934cb 100644
--- a/content/manuals/engine/swarm/manage-nodes.md
+++ b/content/manuals/engine/swarm/manage-nodes.md
@@ -148,7 +148,7 @@ decentralized manner. For instance, an engine could have a label to indicate
 that it has a certain type of disk device, which may not be relevant to security
 directly. These labels are more easily "trusted" by the swarm orchestrator.
 
-Refer to the `docker service create` [CLI reference](/reference/cli/docker/service/create.md)
+Refer to the `docker service create` [CLI reference](/reference/cli/docker/service/create/)
 for more information about service constraints.
 
 ### Promote or demote a node
diff --git a/content/manuals/engine/swarm/networking.md b/content/manuals/engine/swarm/networking.md
index 6f78b2b391c1..d4257fc7a2ed 100644
--- a/content/manuals/engine/swarm/networking.md
+++ b/content/manuals/engine/swarm/networking.md
@@ -243,6 +243,26 @@ If you need more than 256 IP addresses, do not increase the IP block size. You c
 endpoint mode with an external load balancer, or use multiple smaller overlay networks. See 
 [Configure service discovery](#configure-service-discovery) for more information about different endpoint modes.
 
+#### Use direct server return
+
+Direct server return (DSR) changes east-west overlay load balancing so that
+IPVS routes packets by changing the destination MAC address. The source IP and
+destination virtual IP (VIP) remain unchanged.
+
+Create an overlay network that uses DSR:
+
+```console
+$ docker network create \
+  --driver overlay \
+  --opt dsr \
+  dsr-net
+```
+
+> [!NOTE]
+>
+> DSR is supported only for traffic between services on Linux nodes. The
+> ingress routing mesh does not use DSR.
+
 #### Configure encryption of application data {#encryption}
 
 Management and control plane data related to a swarm is always encrypted.
@@ -290,8 +310,7 @@ service's external clients to an individual swarm node, without the client
 needing to know how many nodes are participating in the service or their
 IP addresses or ports. You don't need to publish ports which are used between
 services on the same network. For instance, if you have a
-[WordPress service that stores its data in a MySQL service](https://training.play-with-docker.com/swarm-service-discovery/),
-and they are connected to the same overlay network, you do not need to publish
+WordPress service that stores its data in a MySQL service, and they are connected to the same overlay network, you do not need to publish
 the MySQL port to the client, only the WordPress HTTP port.
 
 Service discovery can work in two different ways: internal connection-based
@@ -315,6 +334,14 @@ round robin (DNSRR). You can configure this per service.
   `--endpoint-mode dnsrr` when creating a new service or updating an existing
   one.
 
+### Container discovery
+
+For most situations, connect to the service name. Docker load-balances
+requests across all running tasks ("containers") backing the service. To
+resolve the IP addresses of all individual tasks backing a service directly,
+perform a DNS lookup for `tasks.<service-name>`. Docker returns a list of
+all task IP addresses for that service, one per running replica.
+
 ## Customize the ingress network {#customize-ingress}
 
 Most users never need to configure the `ingress` network, but Docker allows you
@@ -395,7 +422,7 @@ order to delete an existing bridge. The package name is `bridge-utils`.
 
 4.  Create or re-create the `docker_gwbridge` bridge with your custom settings.
     This example uses the subnet `10.11.0.0/16`. For a full list of customizable
-    options, see [Bridge driver options](/reference/cli/docker/network/create.md#bridge-driver-options).
+    options, see [Bridge driver options](/reference/cli/docker/network/create/#bridge-driver-options).
 
     ```console
     $ docker network create \
diff --git a/content/manuals/engine/swarm/secrets.md b/content/manuals/engine/swarm/secrets.md
index 51a25279ed47..00a5116ffa86 100644
--- a/content/manuals/engine/swarm/secrets.md
+++ b/content/manuals/engine/swarm/secrets.md
@@ -118,12 +118,41 @@ the mount point of the secret within a given container.
 Use these links to read about specific commands, or continue to the
 [example about using secrets with a service](secrets.md#simple-example-get-started-with-secrets).
 
-- [`docker secret create`](/reference/cli/docker/secret/create.md)
-- [`docker secret inspect`](/reference/cli/docker/secret/inspect.md)
-- [`docker secret ls`](/reference/cli/docker/secret/ls.md)
-- [`docker secret rm`](/reference/cli/docker/secret/rm.md)
-- [`--secret`](/reference/cli/docker/service/create.md#secret) flag for `docker service create`
-- [`--secret-add` and `--secret-rm`](/reference/cli/docker/service/update.md#secret-add) flags for `docker service update`
+- [`docker secret create`](/reference/cli/docker/secret/create/)
+- [`docker secret inspect`](/reference/cli/docker/secret/inspect/)
+- [`docker secret ls`](/reference/cli/docker/secret/ls/)
+- [`docker secret rm`](/reference/cli/docker/secret/rm/)
+- [`--secret`](/reference/cli/docker/service/create/#secret) flag for `docker service create`
+- [`--secret-add` and `--secret-rm`](/reference/cli/docker/service/update/#secret-add) flags for `docker service update`
+
+## Defining and using secrets in Compose files
+
+Using secrets in a Compose file alongside Docker Swarm is as simple as defining a secret
+using `docker secret create`.
+
+```console
+$ printf "my-secret" | docker secret create some_secret -
+```
+
+In the `compose.yml` file you can declare the secret as `external` in the top-level `secrets` attribute.
+
+```yaml
+services:
+    api:
+        image: my-web-app
+        environment:
+            MY_ENV: /run/secrets/some_secret
+        secrets:
+            - some_secret
+
+secrets:
+    some_secret:
+        external: true
+```
+
+Both the `docker compose` and `docker stack` commands support defining secrets
+in a Compose file. See
+[the Compose file reference](/reference/compose-file/secrets.md) for details.
 
 ## Examples
 
@@ -139,12 +168,6 @@ a similar way, see
 > simplicity. The examples use Linux containers, but Windows containers also
 > support secrets. See [Windows support](#windows-support).
 
-### Defining and using secrets in compose files
-
-Both the `docker-compose` and `docker stack` commands support defining secrets
-in a compose file. See
-[the Compose file reference](/reference/compose-file/legacy-versions.md) for details.
-
 ### Simple example: Get started with secrets
 
 This simple example shows how secrets work in just a few commands. For a
diff --git a/content/manuals/engine/swarm/services.md b/content/manuals/engine/swarm/services.md
index 5c737f87881f..0688aad94200 100644
--- a/content/manuals/engine/swarm/services.md
+++ b/content/manuals/engine/swarm/services.md
@@ -213,8 +213,8 @@ define a configuration at service creation, you can also update an existing
 service's configuration in a similar way.
 
 See the command-line references for
-[`docker service create`](/reference/cli/docker/service/create.md) and
-[`docker service update`](/reference/cli/docker/service/update.md), or run
+[`docker service create`](/reference/cli/docker/service/create/) and
+[`docker service update`](/reference/cli/docker/service/update/), or run
 one of those commands with the `--help` flag.
 
 ### Configure the runtime environment
@@ -318,7 +318,7 @@ node is responsible for resolving the tag to a digest, and different nodes may
 use different versions of the image. If this happens, a warning like the
 following is logged, substituting the placeholders for real information.
 
-```none
+```text
 unable to pin image <IMAGE-NAME> to digest: <REASON>
 ```
 
@@ -670,7 +670,7 @@ Service constraints let you set criteria for a node to meet before the scheduler
 deploys a service to the node. You can apply constraints to the
 service based upon node attributes and metadata or engine metadata. For more
 information on constraints, refer to the `docker service create`
-[CLI reference](/reference/cli/docker/service/create.md).
+[CLI reference](/reference/cli/docker/service/create/).
 
 #### Reserve memory or CPUs for a service
 
@@ -733,7 +733,7 @@ and CPU/memory constraints. Be careful not to use settings that are not
 possible to fulfill.
 
 For more information on constraints, refer to the `docker service create`
-[CLI reference](/reference/cli/docker/service/create.md).
+[CLI reference](/reference/cli/docker/service/create/).
 
 #### Placement preferences
 
diff --git a/content/manuals/engine/swarm/stack-deploy.md b/content/manuals/engine/swarm/stack-deploy.md
index 0c8cd37490df..373193f883bc 100644
--- a/content/manuals/engine/swarm/stack-deploy.md
+++ b/content/manuals/engine/swarm/stack-deploy.md
@@ -95,7 +95,7 @@ counter whenever you visit it.
 
 3.  Create a file called `requirements.txt` and paste these two lines in:
 
-    ```none
+    ```text
     flask
     redis
     ```
diff --git a/content/manuals/engine/swarm/swarm-mode.md b/content/manuals/engine/swarm/swarm-mode.md
index aba6ddde2a0f..4ca1cb347522 100644
--- a/content/manuals/engine/swarm/swarm-mode.md
+++ b/content/manuals/engine/swarm/swarm-mode.md
@@ -28,7 +28,7 @@ and try the [Swarm mode tutorial](swarm-tutorial/_index.md).
 
 When you run the command to create a swarm, Docker Engine starts running in Swarm mode.
 
-Run [`docker swarm init`](/reference/cli/docker/swarm/init.md)
+Run [`docker swarm init`](/reference/cli/docker/swarm/init/)
 to create a single-node swarm on the current node. The engine sets up the swarm
 as follows:
 
@@ -107,7 +107,7 @@ all the subnets are exhausted.
 
 Refer to the following pages for more information:
 - [Swarm networking](./networking.md) for more information about the default address pool usage
-- `docker swarm init` [CLI reference](/reference/cli/docker/swarm/init.md) for more detail on the `--default-addr-pool` flag.
+- `docker swarm init` [CLI reference](/reference/cli/docker/swarm/init/) for more detail on the `--default-addr-pool` flag.
 
 ### Configure the advertise address
 
@@ -133,7 +133,7 @@ you use for access from outside that region. In this case, specify the external
 address with `--advertise-addr` so that the node can propagate that information
 to other nodes that subsequently connect to it.
 
-Refer to the `docker swarm init` [CLI reference](/reference/cli/docker/swarm/init.md)
+Refer to the `docker swarm init` [CLI reference](/reference/cli/docker/swarm/init/)
 for more detail on the advertise address.
 
 ### View the join command or update a swarm join token
@@ -214,5 +214,5 @@ To add a worker to this swarm, run the following command:
 ## Learn more
 
 * [Join nodes to a swarm](join-nodes.md)
-* `swarm init` [command line reference](/reference/cli/docker/swarm/init.md)
+* `swarm init` [command line reference](/reference/cli/docker/swarm/init/)
 * [Swarm mode tutorial](swarm-tutorial/_index.md)
diff --git a/content/manuals/engine/swarm/swarm-tutorial/_index.md b/content/manuals/engine/swarm/swarm-tutorial/_index.md
index 88c8ab6f9a87..492b920b7fd7 100644
--- a/content/manuals/engine/swarm/swarm-tutorial/_index.md
+++ b/content/manuals/engine/swarm/swarm-tutorial/_index.md
@@ -25,16 +25,18 @@ If you are brand new to Docker, see [About Docker Engine](../../_index.md).
 
 To run this tutorial, you need:
 
-* [Three Linux hosts which can communicate over a network, with Docker installed](#three-networked-host-machines)
-* [The IP address of the manager machine](#the-ip-address-of-the-manager-machine)
-* [Open ports between the hosts](#open-protocols-and-ports-between-the-hosts)
+- [Set up](#set-up)
+  - [Three networked host machines](#three-networked-host-machines)
+    - [Install Docker Engine on Linux machines](#install-docker-engine-on-linux-machines)
+  - [The IP address of the manager machine](#the-ip-address-of-the-manager-machine)
+  - [Open protocols and ports between the hosts](#open-protocols-and-ports-between-the-hosts)
+- [Next steps](#next-steps)
 
 ### Three networked host machines
 
 This tutorial requires three Linux hosts which have Docker installed and can
 communicate over a network. These can be physical machines, virtual machines,
-Amazon EC2 instances, or hosted in some other way. Check out
-[Deploy to Swarm](/guides/swarm-deploy.md#prerequisites) for one possible set-up for the hosts.
+Amazon EC2 instances, or hosted in some other way.
 
 One of these machines is a manager (called `manager1`) and two of them are
 workers (`worker1` and `worker2`).
@@ -59,7 +61,7 @@ the IP address.
 Because other nodes contact the manager node on its IP address, you should use a
 fixed IP address.
 
-You can run `ifconfig` on Linux or macOS to see a list of the
+You can run `ip addr` on Linux, or `ifconfig` on macOS, to see a list of the
 available network interfaces.
 
 The tutorial uses `manager1` : `192.168.99.100`.
diff --git a/content/manuals/enterprise/enterprise-deployment/_index.md b/content/manuals/enterprise/enterprise-deployment/_index.md
new file mode 100644
index 000000000000..8324d70ef201
--- /dev/null
+++ b/content/manuals/enterprise/enterprise-deployment/_index.md
@@ -0,0 +1,35 @@
+---
+title: Deploy Docker Desktop 
+weight: 10
+description: If you're an IT admin, learn how to deploy Docker Desktop at scale
+keywords: msi, docker desktop, windows, installation, mac, pkg, enterprise 
+params:
+  sidebar:
+    group: Enterprise
+grid:
+- title: MSI installer
+  description: Learn how to install Docker Desktop with the MSI installer.
+  link: /enterprise/enterprise-deployment/msi-install-and-configure/
+- title: PKG installer
+  description: Learn how to install Docker Desktop with the PKG installer.
+  link: /enterprise/enterprise-deployment/pkg-install-and-configure/
+- title: MS Store
+  description: Learn how to install Docker Desktop through the Microsoft Store.
+  link: /enterprise/enterprise-deployment/ms-store/
+- title: Deploy with Intune
+  description: Learn how to deploy Docker Desktop on Windows and macOS devices using Microsoft Intune.
+  link: /enterprise/enterprise-deployment/use-intune/
+- title: Deploy with Jamf Pro
+  description: Learn how to deploy Docker Desktop for Mac using Jamf Pro
+  link: /enterprise/enterprise-deployment/use-jamf-pro/
+- title: Docker Desktop for Microsoft Dev Box
+  description: Install Docker Desktop for Microsoft Dev Box via the Microsoft Azure Marketlplace
+  link: /enterprise/enterprise-deployment/dev-box/
+- title: FAQs
+  description: Common questions when deploying Docker Desktop 
+  link: /enterprise/enterprise-deployment/faq/
+---
+
+Docker Desktop supports scalable deployment options tailored for enterprise IT environments. Whether you're rolling out Docker across hundreds of developer workstations or enforcing consistent configuration through MDM solutions like Intune or Jamf, this section provides everything you need to install, configure, and manage Docker Desktop in a secure, repeatable way. Learn how to use MSI and PKG installers, configure default settings, control updates, and ensure compliance with your organization's policies—across Windows, macOS, and Linux systems.
+
+{{< grid >}}
\ No newline at end of file
diff --git a/content/manuals/enterprise/enterprise-deployment/dev-box.md b/content/manuals/enterprise/enterprise-deployment/dev-box.md
new file mode 100644
index 000000000000..c376eb18a7d7
--- /dev/null
+++ b/content/manuals/enterprise/enterprise-deployment/dev-box.md
@@ -0,0 +1,57 @@
+---
+Title: Docker Desktop in Microsoft Dev Box
+linkTitle: Microsoft Dev Box
+description: Learn about the benefits of and  how to setup Docker Desktop in Microsoft Dev Box
+keywords: desktop, docker, windows, microsoft dev box
+weight: 60
+---
+
+Docker Desktop is available as a pre-configured image in the Microsoft Azure Marketplace for use with Microsoft Dev Box, allowing developers to quickly set up consistent development environments in the cloud.
+
+Microsoft Dev Box provides cloud-based, pre-configured developer workstations that allow you to code, build, and test applications without configuring a local development environment. The Docker Desktop image for Microsoft Dev Box comes with Docker Desktop and its dependencies pre-installed, giving you a ready-to-use containerized development environment.
+
+## Key benefits
+
+- Docker Desktop, WSL2, and dependencies pre-installed
+- Identical environment for every team member
+- More compute and storage than a typical local machine
+- Session state persists between uses
+- Works with your existing Docker subscription
+
+## Setup
+
+### Prerequisites
+
+- An Azure subscription
+- Access to Microsoft Dev Box
+- A Docker subscription (Pro, Team, or Business). You can use Docker Desktop in Microsoft Dev Box with any of the following subscription options:
+  - An existing or new Docker subscription
+  - A new Docker subscription purchased through Azure Marketplace
+  - A Docker Business subscription with SSO configured for your organization
+
+### Set up Docker Desktop in Dev Box
+
+1. Navigate to the [Docker Desktop for Microsoft Dev Box](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/dockerinc1694120899427.devbox_azuremachine?tab=Overview) listing in Azure Marketplace.
+2. Select **Get It Now** to add the virtual machine image to your subscription.
+3. Follow the Azure workflow to complete the setup.
+4. Use the image to create VMs, assign to Dev Centers, or create Dev Box Pools according to your organization's setup.
+
+### Activate Docker Desktop
+
+Once your Dev Box is provisioned with the Docker Desktop image:
+
+1. Start your Dev Box instance.
+2. Launch Docker Desktop.
+3. Sign in with your Docker ID.
+
+## Support
+
+For issues related to:
+
+- Docker Desktop configuration, usage, or licensing: Create a support ticket through [Docker Support](https://hub.docker.com/support).
+- Dev Box creation, Azure portal configuration, or networking: Contact Azure Support.
+
+## Limitations
+
+- Microsoft Dev Box is only available on Windows 10 and 11 (Linux VMs are not supported).
+- Performance may vary based on your Dev Box configuration and network conditions.
diff --git a/content/manuals/enterprise/enterprise-deployment/faq.md b/content/manuals/enterprise/enterprise-deployment/faq.md
new file mode 100644
index 000000000000..156a631f1157
--- /dev/null
+++ b/content/manuals/enterprise/enterprise-deployment/faq.md
@@ -0,0 +1,105 @@
+---
+title: Enterprise deployment FAQs
+linkTitle: FAQs
+description: Frequently asked questions for deploying Docker Desktop at scale
+keywords: msi, deploy, docker desktop, faqs, pkg, mdm, jamf, intune, windows, mac, enterprise, admin
+tags: [FAQ, admin]
+weight: 70
+---
+
+## MSI
+
+Common questions about installing Docker Desktop using the MSI installer.
+
+### What happens to user data if they have an older Docker Desktop installation (i.e. `.exe`)?
+
+Users must [uninstall](/manuals/desktop/uninstall.md) older `.exe` installations before using the new MSI version. The `.exe` installer includes a `-keep-data` flag that removes Docker Desktop while preserving underlying resources such as the container VMs:
+
+```powershell
+# For all-user installations
+& 'C:\Program Files\Docker\Docker\Docker Desktop Installer.exe' uninstall -keep-data
+
+# For per-user installations
+& '%LOCALAPPDATA%\Programs\DockerDesktop\Docker Desktop Installer.exe' uninstall -keep-data
+
+```
+
+### What happens if the user's machine has an older `.exe` installation?
+
+The MSI installer detects older `.exe` installations and blocks the installation until the previous version is uninstalled. It prompts the user to uninstall their current/old version first, before retrying to install the MSI version.
+
+### My installation failed, how do I find out what happened?
+
+MSI installations may fail silently, offering little diagnostic feedback.
+
+To debug a failed installation, run the install again with verbose logging enabled:
+
+```powershell
+msiexec /i "DockerDesktop.msi" /L*V ".\msi.log"
+```
+
+After the installation has failed, open the log file and search for occurrences of `value 3`. This is the exit code Windows Installer outputs when it has failed. Just above the line, you will find the reason for the failure.
+
+### Why does the installer prompt for a reboot at the end of every fresh installation?
+
+The installer prompts for a reboot because it assumes that changes have been made to the system that require a reboot to finish their configuration.
+
+For example, if you select the WSL engine, the installer adds the required Windows features. After these features are installed, the system reboots to complete configurations so the WSL engine is functional.
+
+You can suppress reboots by using the `/norestart` option when launching the installer from the command line:
+
+```powershell
+msiexec /i "DockerDesktop.msi" /L*V ".\msi.log" /norestart
+```
+
+### Why isn't the `docker-users` group populated when the MSI is installed with Intune or another MDM solution?
+
+It's common for MDM solutions to install applications in the context of the system account. This means that the `docker-users` group isn't populated with the user's account, as the system account doesn't have access to the user's context.
+
+As an example, you can reproduce this by running the installer with `psexec` in an elevated command prompt:
+
+```powershell
+psexec -i -s msiexec /i "DockerDesktop.msi"
+```
+The installation should complete successfully, but the `docker-users` group won't be populated.
+
+As a workaround, you can create a script that runs in the context of the user account.
+
+The script would be responsible for ensuring the `docker-users` group exists and populating it with the correct user.
+
+> [!WARNING]
+>
+> Membership in `docker-users` grants access to the Docker daemon socket, which is equivalent to granting administrative privileges on the host. Only add users who require access to Windows containers or Hyper-V VM management. For Linux containers using the WSL 2 backend, this group membership is not required. See [Protect the Docker daemon socket](/manuals/engine/security/protect-access.md) for further information.
+
+Here's an example script that creates the `docker-users` group if needed and adds the current user to it (requirements may vary depending on environment):
+
+```powershell
+$Group = "docker-users"
+$CurrentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
+
+# Create the group if it doesn't exist
+if (-not (Get-LocalGroup -Name $Group -ErrorAction SilentlyContinue)) {
+    New-LocalGroup -Name $Group
+}
+
+# Add the user to the group
+Add-LocalGroupMember -Group $Group -Member $CurrentUser
+```
+
+> [!NOTE]
+>
+> After adding a new user to the `docker-users` group, the user must sign out and then sign back in for the changes to take effect.
+
+## MDM
+
+Common questions about deploying Docker Desktop using mobile device management
+(MDM) tools such as Jamf, Intune, or Workspace ONE.
+
+### Why doesn't my MDM tool apply all Docker Desktop configuration settings at once?
+
+Some MDM tools, such as Workspace ONE, may not support applying multiple
+configuration settings in a single XML file. In these cases, you may need to
+deploy each setting in a separate XML file.
+
+Refer to your MDM provider's documentation for specific deployment
+requirements or limitations.
diff --git a/content/manuals/enterprise/enterprise-deployment/ms-store.md b/content/manuals/enterprise/enterprise-deployment/ms-store.md
new file mode 100644
index 000000000000..9011934183ee
--- /dev/null
+++ b/content/manuals/enterprise/enterprise-deployment/ms-store.md
@@ -0,0 +1,45 @@
+---
+title: Install Docker Desktop from the Microsoft Store on Windows
+linkTitle: MS Store
+description: Install Docker Desktop for Windows through the Microsoft Store. Understand its update behavior and limitations. 
+keywords: microsoft store, windows, docker desktop, install, deploy, configure, admin, mdm, intune, winget
+tags: [admin]
+weight: 30
+---
+
+You can deploy Docker Desktop for Windows through the [Microsoft app store](https://apps.microsoft.com/detail/xp8cbj40xlbwkx?hl=en-GB&gl=GB).
+
+The Microsoft Store version of Docker Desktop provides the same functionality as the standard installer but has a different update behavior depending on whether your developers install it themselves or if installation is handled by an MDM tool such as Intune. This is described in the following section. 
+
+Choose the installation method that best aligns with your environment's requirements and management practices.
+
+## Update behavior
+
+### Developer-managed installations
+
+For developers who install Docker Desktop directly:
+
+- The Microsoft Store does not automatically update Win32 apps like Docker Desktop for most users.
+- Only a subset of users (approximately 20%) may receive update notifications on the Microsoft Store page.
+- Most users must manually check for and apply updates within the Store.
+
+### Intune-managed installations
+
+In environments managed with Intune:
+- Intune checks for updates approximately every 8 hours.
+- When a new version is detected, Intune triggers a `winget` upgrade.  
+- If appropriate policies are configured, updates can occur automatically without user intervention. 
+- Updates are handled by Intune's management infrastructure rather than the Microsoft Store itself.
+
+## WSL considerations
+
+Docker Desktop for Windows integrates closely with WSL. When updating Docker Desktop installed from the Microsoft Store:
+- Make sure you have quit Docker Desktop and that it is no longer running so updates can complete successfully
+- In some environments, virtual hard disk (VHDX) file locks may prevent the update from completing.
+
+## Recommendations for Intune management
+
+If using Intune to manage Docker Desktop for Windows:
+- Ensure your Intune policies are configured to handle application updates
+- Be aware that the update process uses WinGet APIs rather than direct Store mechanisms
+- Consider testing the update process in a controlled environment to verify proper functionality
diff --git a/content/manuals/enterprise/enterprise-deployment/msi-install-and-configure.md b/content/manuals/enterprise/enterprise-deployment/msi-install-and-configure.md
new file mode 100644
index 000000000000..68fe0a96f0c6
--- /dev/null
+++ b/content/manuals/enterprise/enterprise-deployment/msi-install-and-configure.md
@@ -0,0 +1,264 @@
+---
+title: MSI installer
+description: Understand how to use the MSI installer. Also explore additional configuration options.
+keywords: msi, windows, docker desktop, install, deploy, configure, admin, mdm
+tags: [admin]
+weight: 10
+aliases:
+  - /desktop/setup/install/enterprise-deployment/msi-install-and-configure/
+---
+
+{{< summary-bar feature_name="MSI installer" >}}
+
+The MSI package supports various MDM (Mobile Device Management) solutions, making it ideal for bulk installations and eliminating the need for manual setups by individual users. With this package, IT administrators can ensure standardized, policy-driven installations of Docker Desktop, enhancing efficiency and software management across their organizations.
+
+## Install interactively
+
+1. In [Docker Home](http://app.docker.com), choose your organization.
+2. Select **Docker Desktop**, then **Deploy**.
+3. From the **Windows OS** tab, select the **Download MSI installer** button.
+4. Once downloaded, double-click `Docker Desktop Installer.msi` to run the installer.
+5. After accepting the license agreement, choose the install location. By default, Docker Desktop is installed at `C:\Program Files\Docker\Docker`(all-user installations) or `%LOCALAPPDATA%\Programs\DockerDesktop` (per-user installations)
+6. Configure the Docker Desktop installation. You can:
+   - Create a desktop shortcut
+
+   - Set the Docker Desktop service startup type to automatic
+
+   - Disable Windows Container usage
+
+   - Select the Docker Desktop backend: WSL or Hyper-V. If only one is supported by your system, you won't be able to choose.
+
+7. Follow the instructions on the installation wizard to authorize the installer and proceed with the install.
+8. When the installation is successful, select **Finish** to complete the installation process.
+
+If your administrator account is different from your user account, you must add the user to the **docker-users** group to access features that require higher privileges, such as creating and managing the Hyper-V VM, or using Windows containers:
+
+1. Run **Computer Management** as an **administrator**.
+2. Navigate to **Local Users and Groups** > **Groups** > **docker-users**.
+3. Right-click to add the user to the group.
+4. Sign out and sign back in for the changes to take effect.
+
+> [!NOTE]
+>
+> When installing Docker Desktop with the MSI, in-app updates are automatically disabled by default. This ensures organizations can maintain version consistency and prevent unapproved updates.
+> Starting with Docker Desktop version 4.60 and later, in-app updates from an MSI installation can be enabled by changing the `disableUpdate` setting to `false` through [Settings Management](../security/hardened-desktop/settings-management/).
+>
+> Docker Desktop notifies you when an update is available. To update Docker Desktop, download the latest installer from Docker Home. Navigate to the **Deploy** page.
+>
+> To keep up to date with new releases, check the [release notes](/manuals/desktop/release-notes.md) page.
+
+## Install from the command line
+
+This section covers command line installations of Docker Desktop using PowerShell. It provides common installation commands that you can run. You can also add additional arguments which are outlined in [configuration options](#configuration-options).
+
+When installing Docker Desktop, you can choose between interactive or non-interactive installations.
+
+Interactive installations, without specifying `/quiet` or `/qn`, display the user interface and let you select your own properties.
+
+When installing via the user interface it's possible to:
+
+- Choose the destination folder
+- Create a desktop shortcut
+- Configure the Docker Desktop service startup type
+- Disable Windows Containers
+- Choose between the WSL or Hyper-V engine
+
+Non-interactive installations are silent and any additional configuration must be passed as arguments.
+
+### Common installation commands
+
+Admin rights are required to run any of the following commands.
+
+#### Install interactively with verbose logging
+
+```powershell
+msiexec /i "DockerDesktop.msi" /L*V ".\msi.log"
+```
+
+#### Install interactively without verbose logging
+
+```powershell
+msiexec /i "DockerDesktop.msi"
+```
+
+#### Install non-interactively with verbose logging
+
+```powershell
+msiexec /i "DockerDesktop.msi" /L*V ".\msi.log" /quiet
+```
+
+#### Install non-interactively and suppressing reboots
+
+```powershell
+msiexec /i "DockerDesktop.msi" /L*V ".\msi.log" /quiet /norestart
+```
+
+#### Install non-interactively with admin settings
+
+```powershell
+msiexec /i "DockerDesktop.msi" /L*V ".\msi.log" /quiet /norestart ADMINSETTINGS="{""configurationFileVersion"":2,""enhancedContainerIsolation"":{""value"":true,""locked"":false}}" ALLOWEDORG="your-organization"
+```
+
+#### Install interactively and allow users to switch to Windows containers without admin rights
+
+```powershell
+msiexec /i "DockerDesktop.msi" /L*V ".\msi.log" /quiet /norestart ALLOWEDORG="your-organization" ALWAYSRUNSERVICE=1
+```
+
+#### Install interactively specifying a PAC file
+
+```powershell
+PowerShell
+ msiexec --% /i "DockerDesktop.msi" /L*V ".\msi.log"  PROXYHTTPMODE="manual" OVERRIDEPROXYPAC="http://localhost:8080/myproxy.pac"
+```
+
+#### Install interactively specifying a PAC script
+
+```powershell
+PowerShell
+ msiexec --% /i "DockerDesktop.msi" /L*V ".\msi.log"  PROXYHTTPMODE="manual" OVERRIDEPROXYEMBEDDEDPAC="function FindProxyForURL(url,host) {return ""DIRECT"" ;; }"
+```
+
+#### Install with the passive display option
+
+You can use the `/passive` display option instead of `/quiet` when you want to perform a non-interactive installation but show a progress dialog.
+
+In passive mode the installer doesn't display any prompts or error messages to the user and the installation cannot be cancelled.
+
+For example:
+
+```powershell
+msiexec /i "DockerDesktop.msi" /L*V ".\msi.log" /passive /norestart
+```
+
+> [!TIP]
+>
+> When creating a value that expects a JSON string:
+>
+> - The property expects a JSON formatted string
+> - The string should be wrapped in double quotes
+> - The string shouldn't contain any whitespace
+> - Property names are expected to be in double quotes
+
+### Common uninstall commands
+
+When uninstalling Docker Desktop, you need to use the same `.msi` file that was originally used to install the application.
+
+If you no longer have the original `.msi` file, you need to use the product code associated with the installation. To find the product code, run:
+
+```powershell
+Get-WmiObject Win32_Product | Select-Object IdentifyingNumber, Name | Where-Object {$_.Name -eq "Docker Desktop"}
+```
+
+It should return output similar to the following:
+
+```text
+IdentifyingNumber                      Name
+-----------------                      ----
+{10FC87E2-9145-4D7D-B493-2E99E8D8E103} Docker Desktop
+```
+
+> [!NOTE]
+>
+> This command may take some time, depending on the number of installed applications.
+
+`IdentifyingNumber` is the applications product code and can be used to uninstall Docker Desktop. For example:
+
+```powershell
+msiexec /x {10FC87E2-9145-4D7D-B493-2E99E8D8E103} /L*V ".\msi.log" /quiet
+```
+
+#### Uninstall interactively with verbose logging
+
+```powershell
+msiexec /x "DockerDesktop.msi" /L*V ".\msi.log"
+```
+
+#### Uninstall interactively without verbose logging
+
+```powershell
+msiexec /x "DockerDesktop.msi"
+```
+
+#### Uninstall non-interactively with verbose logging
+
+```powershell
+msiexec /x "DockerDesktop.msi" /L*V ".\msi.log" /quiet
+```
+
+#### Uninstall non-interactively without verbose logging
+
+```powershell
+msiexec /x "DockerDesktop.msi" /quiet
+```
+
+### Configuration options
+
+In addition to the following custom properties, the Docker Desktop MSI installer also supports the standard [Windows Installer command line options](https://learn.microsoft.com/en-us/windows/win32/msi/standard-installer-command-line-options).
+
+| Property                           | Description                                                                                                                                                                                                                                                                                   | Default                 |
+| :--------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------- |
+| `ENABLEDESKTOPSHORTCUT`            | Creates a desktop shortcut.                                                                                                                                                                                                                                                                   | 1                       |
+| `INSTALLFOLDER`                    | Specifies a custom location where Docker Desktop will be installed.                                                                                                                                                                                                                           | C:\Program Files\Docker |
+| `ADMINSETTINGS`                    | Automatically creates an `admin-settings.json` file which is used to [control certain Docker Desktop settings](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md) on client machines within organizations. It must be used together with the `ALLOWEDORG` property. | None                    |
+| `ALLOWEDORG`                       | Requires the user to sign in and be part of the specified Docker Hub organization when running the application. This creates a registry key called `allowedOrgs` in `HKLM\Software\Policies\Docker\Docker Desktop`.                                                                           | None                    |
+| `ALWAYSRUNSERVICE`                 | Lets users switch to Windows containers without needing admin rights                                                                                                                                                                                                                          | 0                       |
+| `DISABLEWINDOWSCONTAINERS`         | Disables the Windows containers integration                                                                                                                                                                                                                                                   | 0                       |
+| `ENGINE`                           | Sets the Docker Engine that's used to run containers. This can be either `wsl` , `hyperv`, or `windows`                                                                                                                                                                                       | `wsl`                   |
+| `PROXYENABLEKERBEROSNTLM`          | When set to 1, enables support for Kerberos and NTLM proxy authentication.                                                                                                                                                                                                                    | 0                       |
+| `PROXYHTTPMODE`                    | Sets the HTTP Proxy mode. This can be either `system` or `manual`                                                                                                                                                                                                                             | `system`                |
+| `OVERRIDEPROXYHTTP`                | Sets the URL of the HTTP proxy that must be used for outgoing HTTP requests.                                                                                                                                                                                                                  | None                    |
+| `OVERRIDEPROXYHTTPS`               | Sets the URL of the HTTP proxy that must be used for outgoing HTTPS requests.                                                                                                                                                                                                                 | None                    |
+| `OVERRIDEPROXYEXCLUDE`             | Bypasses proxy settings for the hosts and domains. Uses a comma-separated list.                                                                                                                                                                                                               | None                    |
+| `OVERRIDEPROXYPAC`                 | Sets the PAC file URL. This setting takes effect only when using `manual` proxy mode.                                                                                                                                                                                                         | None                    |
+| `OVERRIDEPROXYEMBEDDEDPAC`         | Specifies an embedded PAC (Proxy Auto-config) script. This setting takes effect only when using `manual` proxy mode and has precedence over the `OVERRIDEPROXYPAC` flag.                                                                                                                      | None                    |
+| `HYPERVDEFAULTDATAROOT`            | Specifies the default location for the Hyper-V VM disk.                                                                                                                                                                                                                                       | None                    |
+| `WINDOWSCONTAINERSDEFAULTDATAROOT` | Specifies the default location for Windows containers.                                                                                                                                                                                                                                        | None                    |
+| `WSLDEFAULTDATAROOT`               | Specifies the default location for the WSL distribution disk.                                                                                                                                                                                                                                 | None                    |
+| `DISABLEANALYTICS`                 | When set to 1, analytics collection will be disabled for the MSI. For more information, see [Analytics](#analytics).                                                                                                                                                                          | 0                       |
+| `REMOVEEXISTINGINSTALL`            | When set to 1, any existing EXE installations are removed. Existing settings and content are preserved. Available with Docker Desktop version 4.61 and later.   | 1 |
+
+Additionally, you can also use `/norestart` or `/forcerestart` to control reboot behaviour.
+
+By default, the installer reboots the machine after a successful installation. When run silently, the reboot is automatic and the user is not prompted.
+
+## Analytics
+
+The MSI installer collects anonymous usage statistics relating to installation only. This is to better understand user behaviour and to improve the user experience by identifying and addressing issues or optimizing popular features.
+
+### How to opt-out
+
+{{< tabs >}}
+{{< tab name="From the GUI" >}}
+
+When you install Docker Desktop from the default installer GUI, select the **Disable analytics** checkbox located on the bottom-left corner of the **Welcome** dialog.
+
+{{< /tab >}}
+{{< tab name="From the command line" >}}
+
+When you install Docker Desktop from the command line, use the `DISABLEANALYTICS` property.
+
+```powershell
+msiexec /i "win\msi\bin\en-US\DockerDesktop.msi" /L*V ".\msi.log" DISABLEANALYTICS=1
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Persistence
+
+If you decide to disable analytics for an installation, your choice is persisted in the registry and honoured across future upgrades and uninstalls.
+
+However, the key is removed when Docker Desktop is uninstalled and must be configured again via one of the previous methods.
+
+The registry key is as follows:
+
+```powershell
+SOFTWARE\Docker Inc.\Docker Desktop\DisableMsiAnalytics
+```
+
+When analytics is disabled, this key is set to `1`.
+
+## Additional resources
+
+- [Explore the FAQs](/manuals/enterprise/enterprise-deployment/faq.md)
diff --git a/content/manuals/desktop/setup/install/enterprise-deployment/pkg-install-and-configure.md b/content/manuals/enterprise/enterprise-deployment/pkg-install-and-configure.md
similarity index 83%
rename from content/manuals/desktop/setup/install/enterprise-deployment/pkg-install-and-configure.md
rename to content/manuals/enterprise/enterprise-deployment/pkg-install-and-configure.md
index 94f0ec00e16a..cd9b6cc618f4 100644
--- a/content/manuals/desktop/setup/install/enterprise-deployment/pkg-install-and-configure.md
+++ b/content/manuals/enterprise/enterprise-deployment/pkg-install-and-configure.md
@@ -12,8 +12,8 @@ The PKG package supports various MDM (Mobile Device Management) solutions, makin
 
 ## Install interactively
 
-1. In the [Docker Admin Console](http://admin.docker.com/), navigate to your organization.
-2. Under **Docker Desktop**, select the **Deploy** page.
+1. In [Docker Home](http://app.docker.com), choose your organization.
+2. Select **Docker Desktop**, then **Deploy**.
 3. From the **macOS** tab, select the **Download PKG installer** button.
 4. Once downloaded, double-click `Docker.pkg` to run the installer.
 5. Follow the instructions on the installation wizard to authorize the installer and proceed with the installation.
@@ -28,14 +28,14 @@ The PKG package supports various MDM (Mobile Device Management) solutions, makin
 >
 > When installing Docker Desktop with the PKG, in-app updates are automatically disabled. This ensures organizations can maintain version consistency and prevent unapproved updates. For Docker Desktop installed with the `.dmg` installer, in-app updates remain supported.
 >
-> Docker Desktop notifies you when an update is available. To update Docker Desktop, download the latest installer from the Docker Admin Console. Navigate to the  **Deploy** page > under **Docker Desktop**.
+> Docker Desktop notifies you when an update is available. To update Docker Desktop, download the latest installer from the Docker Home. Navigate to the **Deploy** page.
 >
 > To keep up to date with new releases, check the [release notes](/manuals/desktop/release-notes.md) page.
 
 ## Install from the command line
 
-1. In the [Docker Admin Console](http://admin.docker.com/), navigate to your organization.
-2. Under **Security and access**, select the **Deploy Docker Desktop** page.
+1. In [Docker Home](http://app.docker.com), choose your organization.
+2. Select **Docker Desktop**, then **Deploy**.
 3. From the **macOS** tab, select the **Download PKG installer** button.
 4. From your terminal, run the following command:
 
@@ -46,4 +46,4 @@ The PKG package supports various MDM (Mobile Device Management) solutions, makin
 ## Additional resources
 
 - See how you can deploy Docker Desktop for Mac using [Intune](use-intune.md) or [Jamf Pro](use-jamf-pro.md)
-- Explore how to [Enforce sign-in](/manuals/security/for-admins/enforce-sign-in/methods.md#plist-method-mac-only) for your users.
\ No newline at end of file
+- Explore how to [Enforce sign-in](/manuals/enterprise/security/enforce-sign-in/methods.md#plist-method-mac-only) for your users.
\ No newline at end of file
diff --git a/content/manuals/desktop/setup/install/enterprise-deployment/use-intune.md b/content/manuals/enterprise/enterprise-deployment/use-intune.md
similarity index 93%
rename from content/manuals/desktop/setup/install/enterprise-deployment/use-intune.md
rename to content/manuals/enterprise/enterprise-deployment/use-intune.md
index 7c3a137ebdea..25fb74f7b7f4 100644
--- a/content/manuals/desktop/setup/install/enterprise-deployment/use-intune.md
+++ b/content/manuals/enterprise/enterprise-deployment/use-intune.md
@@ -3,10 +3,7 @@ title: Deploy with Intune
 description: Use Intune, Microsoft's cloud-based device management tool, to deploy Docker Desktop
 keywords: microsoft, windows, docker desktop, deploy, mdm, enterprise, administrator, mac, pkg, dmg
 tags: [admin]
-weight: 30
-aliases:
-- /desktop/install/msi/use-intune/
-- /desktop/setup/install/msi/use-intune/
+weight: 40
 ---
 
 {{< summary-bar feature_name="Intune" >}}
@@ -55,4 +52,4 @@ Next, assign the app:
 ## Additional resources
 
 - [Explore the FAQs](faq.md).
-- Learn how to [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) for your users.
\ No newline at end of file
+- Learn how to [enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) for your users.
\ No newline at end of file
diff --git a/content/manuals/desktop/setup/install/enterprise-deployment/use-jamf-pro.md b/content/manuals/enterprise/enterprise-deployment/use-jamf-pro.md
similarity index 94%
rename from content/manuals/desktop/setup/install/enterprise-deployment/use-jamf-pro.md
rename to content/manuals/enterprise/enterprise-deployment/use-jamf-pro.md
index 7443d259afa0..d2e4104f43b2 100644
--- a/content/manuals/desktop/setup/install/enterprise-deployment/use-jamf-pro.md
+++ b/content/manuals/enterprise/enterprise-deployment/use-jamf-pro.md
@@ -3,7 +3,7 @@ title: Deploy with Jamf Pro
 description: Use Jamf Pro to deploy Docker Desktop for Mac
 keywords: jamf, mac, docker desktop, deploy, mdm, enterprise, administrator, pkg
 tags: [admin]
-weight: 40
+weight: 50
 ---
 
 {{< summary-bar feature_name="Jamf Pro" >}}
@@ -29,4 +29,4 @@ For more information, see [Jamf Pro's official documentation](https://learn.jamf
 
 ## Additional resources
 
-- Learn how to [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) for your users.
\ No newline at end of file
+- Learn how to [enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) for your users.
\ No newline at end of file
diff --git a/content/manuals/enterprise/security/_index.md b/content/manuals/enterprise/security/_index.md
new file mode 100644
index 000000000000..410dab7878b9
--- /dev/null
+++ b/content/manuals/enterprise/security/_index.md
@@ -0,0 +1,78 @@
+---
+linkTitle: Security
+title: Security for enterprises
+description: Learn about enterprise level security features Docker has to offer and explore best practices
+keywords: docker, docker hub, docker desktop, security, enterprises, scale
+weight: 10
+params:
+  sidebar:
+    group: Enterprise
+grid_admins:
+  - title: Settings Management
+    description: Learn how Settings Management can secure your developers' workflows.
+    icon: shield-check
+    link: /enterprise/security/hardened-desktop/settings-management/
+  - title: Enhanced Container Isolation
+    description: Understand how Enhanced Container Isolation can prevent container attacks.
+    icon: shield-check
+    link: /enterprise/security/hardened-desktop/enhanced-container-isolation/
+  - title: Registry Access Management
+    description: Control the registries developers can access while using Docker Desktop.
+    icon: server
+    link: /enterprise/security/hardened-desktop/registry-access-management/
+  - title: Image Access Management
+    description: Control the images developers can pull from Docker Hub.
+    icon: photo
+    link: /enterprise/security/hardened-desktop/image-access-management/
+  - title: "Air-Gapped Containers"
+    description: Restrict containers from accessing unwanted network resources.
+    icon: lock-closed
+    link: /enterprise/security/hardened-desktop/air-gapped-containers/
+  - title: Enforce sign-in
+    description: Configure sign-in for members of your teams and organizations.
+    link: /enterprise/security/enforce-sign-in/
+    icon: finger-print
+  - title: OIDC connections
+    description: Configure OpenID Connect connections for automated workload authentication.
+    link: /enterprise/security/oidc-connections/
+    icon: link
+  - title: Domain management
+    description: Identify uncaptured users in your organization.
+    link: /enterprise/security/domain-management/
+    icon: magnifying-glass
+  - title: Docker Scout
+    description: Explore how Docker Scout can help you create a more secure software supply chain.
+    icon: chart-bar
+    link: /scout/
+  - title: SSO
+    description: Learn how to configure SSO for your company or organization.
+    icon: key
+    link: /enterprise/security/single-sign-on/
+  - title: SCIM
+    description: Set up SCIM to automatically provision and deprovision users.
+    icon: clipboard-document-check
+    link: /enterprise/security/provisioning/scim/
+  - title: Roles and permissions
+    description: Assign roles to individuals giving them different permissions within an organization.
+    icon: identification
+    link: /enterprise/security/roles-and-permissions/
+  - title: Private marketplace for Extensions (Beta)
+    description: Learn how to configure and set up a private marketplace with a curated list of extensions for your Docker Desktop users.
+    icon: building-storefront
+    link: /extensions/private-marketplace/
+  - title: Organization access tokens
+    description: Create organization access tokens as an alternative to a password.
+    link: /enterprise/security/access-tokens/
+    icon: lock-closed
+---
+
+Docker provides security guardrails for both administrators and developers.
+
+If you're an administrator, you can enforce sign-in across Docker products for your developers, and
+scale, manage, and secure your instances of Docker Desktop with DevOps security controls like Enhanced Container Isolation and Registry Access Management.
+
+## For administrators
+
+Explore the security features Docker offers to satisfy your company's security policies.
+
+{{< grid items="grid_admins" >}}
diff --git a/content/manuals/enterprise/security/access-tokens.md b/content/manuals/enterprise/security/access-tokens.md
new file mode 100644
index 000000000000..a65b78499397
--- /dev/null
+++ b/content/manuals/enterprise/security/access-tokens.md
@@ -0,0 +1,205 @@
+---
+title: Organization access tokens
+linkTitle: Organization access tokens
+description: Create and manage organization access tokens to securely authenticate automated systems and CI/CD pipelines with Docker Hub
+keywords: organization access tokens, OAT, docker hub security, programmatic access, automation
+aliases:
+ - /security/for-admins/access-tokens/
+---
+
+{{< summary-bar feature_name="OATs" >}}
+
+Organization access tokens (OATs) provide secure, programmatic access to Docker Hub for automated systems, CI/CD pipelines, and other business-critical tasks. Unlike personal access tokens tied to individual users, OATs are associated with your organization and can be managed by any organization owner.
+
+> [!WARNING]
+>
+> Organization access tokens are incompatible with Docker Desktop and Image Access Management. If you use these features, use [personal access tokens](/manuals/security/access-tokens.md) instead.
+
+## Who should use organization access tokens?
+
+Use OATs for automated systems that need Docker Hub access without depending on individual user accounts:
+
+- CI/CD pipelines: Build and deployment systems that push and pull images
+- Production systems: Applications that pull images during deployment
+- Monitoring tools: Systems that need to check repository status or pull images
+- Backup systems: Tools that periodically pull images for archival
+- Integration services: Third-party tools that integrate with your Docker Hub repositories
+
+## Key benefits
+
+Benefits of using organization access tokens include:
+
+- Organizational ownership: Not tied to individual users who might leave the company
+- Shared management: All organization owners can create and manage OATs
+- Separate usage limits: OATs have their own Docker Hub rate limits, not counting against personal accounts
+- Better security audit: Track when tokens were last used and identify suspicious activity
+- Granular permissions: Limit access to specific repositories and operations
+
+## Prerequisites
+
+To create and use organization access tokens, you must have:
+
+- A Docker Team or Business subscription
+- Owner permissions
+- Repositories you want to grant access to
+
+## Create an organization access token
+
+Owners can create tokens with these limits:
+
+- Team subscription: Up to 10 OATs per organization
+- Business subscription: Up to 100 OATs per organization
+
+Expired tokens count toward your total limit.
+
+To create an OAT:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+organization.
+1. Select **Identity & auth**, then **Access tokens**.
+1. Select **Generate access token**.
+1. Configure token details:
+    - Label: Descriptive name indicating the token's purpose
+    - Description (optional): Additional details
+    - Expiration date: When the token should expire
+1. Expand the **Repository** drop-down to set per-repository access permissions:
+    - Optional. Select **Read public repositories** for access to public repositories.
+    - Select **Add repository** and choose a repository from the drop-down.
+    - Set the permission level for each repository. Available scopes range from
+       pulling and pushing images to managing tags, webhooks, repository groups,
+       and immutable tag settings. See [Repository scopes](#repository-scopes)
+       for the full list.
+    - Add up to 50 repositories as needed.
+1. Optional. Configure organization-level permissions by expanding the **Organization** drop-down and selecting **Allow management access to this organization's resources**:
+    - **Member Edit**: Edit members of the organization
+    - **Member Read**: Read members of the organization
+    - **Invite Edit**: Invite members to the organization
+    - **Invite Read**: Read invites to the organization
+    - **Group Edit**: Edit groups of the organization
+    - **Group Read**: Read groups of the organization
+    - **Repository List**: List all repositories, including private ones (`scope-repository-list`)
+    - **Repository Create**: Create new repositories (`scope-repository-create`)
+    - **Registry Usage Read**: Read namespace-level registry usage metrics (`scope-registry-usage-read`)
+1. Select **Generate token**. Copy the token that appears on the screen and save it. You won't be able to retrieve the token once you exit the screen.
+
+> [!IMPORTANT]
+>
+> Treat organization access tokens like passwords. Store them securely in a credential manager and never commit them to source code repositories.
+
+## Use organization access tokens
+
+Sign in to the Docker CLI using your organization access token:
+
+```console
+$ docker login --username <YOUR_ORGANIZATION_NAME>
+Password: [paste your OAT here]
+```
+
+When prompted for a password, enter your organization access token.
+
+## Modify existing tokens
+
+To manage existing tokens:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+organization.
+1. Select **Identity & auth**, then **Access tokens**.
+1. Select the actions menu in the token row, you can:
+    - **Edit**
+    - **Deactivate**
+    - **Delete**
+1. Select **Save** after making changes to a token.
+
+## Available scopes
+
+Scopes control what an OAT can do. Repository-level scopes are assigned per
+repository when you create the token. Organization-level scopes apply to the
+whole organization.
+
+Higher scopes include the permissions of lower ones where noted.
+
+### Repository scopes
+
+| Scope | Description | Includes |
+|---|---|---|
+| `scope-image-pull` | Pull images from the registry | — |
+| `scope-image-push` | Push images to the registry | `scope-image-pull` |
+| `scope-image-delete` | Delete images and tags via registry endpoints | `scope-image-push` |
+| `scope-repository-read` | Read repository metadata, Dockerfile, and stars | — |
+| `scope-repository-edit` | Edit repository privacy, categories, Dockerfile, description, and stars | `scope-repository-read` |
+| `scope-repository-admin` | Delete the repository | `scope-repository-edit` |
+| `scope-tag-read` | List and read tags, image lists, attestations, and compose files | — |
+| `scope-tag-admin` | Delete tags | `scope-tag-read` |
+| `scope-webhook-read` | List webhook pipelines and delivery history | — |
+| `scope-webhook-edit` | Create webhook pipelines | `scope-webhook-read` |
+| `scope-webhook-admin` | Delete webhook pipelines | `scope-webhook-edit` |
+| `scope-repo-group-read` | List and read repository group assignments | — |
+| `scope-repo-group-edit` | Create and update repository group assignments | `scope-repo-group-read` |
+| `scope-repo-group-admin` | Delete repository group assignments | `scope-repo-group-edit` |
+| `scope-repository-settings-admin` | Configure immutable tag rules | — |
+
+### Organization scopes
+
+| Scope | Description |
+|---|---|
+| `scope-repository-list` | List all repositories in the namespace, including private ones |
+| `scope-repository-create` | Create new repositories |
+| `scope-registry-usage-read` | Read namespace-level registry usage metrics |
+
+Creating a repository requires the organization-level `scope-repository-create`
+permission. No repository-level scope, including admin scopes on existing
+repositories, grants this permission.
+
+## Hub API support
+
+OATs can authenticate requests to most Docker Hub API endpoints under
+`/v2/namespaces/{namespace}/repositories/`. Pass the token as a Bearer token
+in the `Authorization` header with your organization name as the username.
+
+### Supported endpoints
+
+The following endpoint categories accept OAT authentication:
+
+- Repository management: list, create, get, update, and delete repositories
+- Tags: list, get, and delete tags; get tag images, attestations, and compose files
+- Dockerfile: get and update a repository's linked Dockerfile
+- Repository groups: list, get, create, update, and delete group assignments
+- Stars: list, count, add, and remove repository stars
+- Immutable tags: update and verify immutable tag policies
+- Repository categories, privacy, and webhook pipeline settings
+- Namespace metrics
+
+### Listing behavior
+
+`GET /v2/namespaces/{namespace}/repositories` returns results based on the
+token's configured scopes:
+
+- **With `scope-repository-list` scope** (or equivalent): all repositories are
+  returned, including private ones.
+- **Without that scope**: only public repositories are returned.
+
+This filtering is silent: the response is a normal `200`, with no error or
+indicator that private repositories were withheld.
+
+### Unsupported legacy endpoints
+
+OATs only authenticate requests to the namespace-scoped routes documented
+above. The following legacy repository paths are OAT unsupported and reject
+every OAT with `403 token issued from organization access token is not
+allowed`, regardless of the token's scopes. Use the linked replacement
+endpoints instead:
+
+- `GET /v2/repositories/{namespace}/{repository}` — use
+  [Get repository](/reference/api/hub/latest/#tag/repositories/operation/GetRepository).
+- `GET /v2/repositories/{namespace}` — use
+  [List repositories](/reference/api/hub/latest/#tag/repositories/operation/listNamespaceRepositories).
+- `GET /v2/users/{username}/repositories` — use
+  [List repositories](/reference/api/hub/latest/#tag/repositories/operation/listNamespaceRepositories).
+
+## Organization access token best practices
+
+- Regular token rotation: Set reasonable expiration dates and rotate tokens regularly to minimize security risks.
+- Principle of least privilege: Grant only the minimum repository access and permissions needed for each use case.
+- Monitor token usage: Regularly review when tokens were last used to identify unused or suspicious tokens.
+- Secure storage: Store tokens in secure credential management systems, never in plain text or source code.
+- Immediate revocation: Deactivate or delete tokens immediately if they're compromised or no longer needed.
diff --git a/content/manuals/enterprise/security/domain-management.md b/content/manuals/enterprise/security/domain-management.md
new file mode 100644
index 000000000000..767f58deaa27
--- /dev/null
+++ b/content/manuals/enterprise/security/domain-management.md
@@ -0,0 +1,138 @@
+---
+title: Add and manage domains
+description: Add, verify, and manage domains to control user access and enable auto-provisioning in Docker organizations
+keywords: domain management, domain verification, auto-provisioning, user management, DNS, TXT record, Docker Home
+weight: 10
+aliases:
+  - /security/for-admins/domain-management/
+---
+
+{{< summary-bar feature_name="Domain management" >}}
+
+Domain management lets you add and verify domains for your organization, then enable auto-provisioning to automatically add users when they sign in with email addresses that match your verified domains. This approach simplifies user management, ensures consistent security settings, and reduces the risk of unmanaged users accessing Docker without visibility or control.
+
+This page provides steps to add and delete domains, configure auto-provisioning, and audit uncaptured users.
+
+## Add and verify a domain
+
+Adding a domain requires verification to confirm ownership. The verification process uses DNS records to prove you control the domain.
+
+### Add a domain
+
+1. Sign in to [Docker Home](https://app.docker.com) and select
+   your organization. If your organization is part of a company, select the company
+   and configure the domain for the organization at the company level.
+1. Select **Identity & auth**, then **Domain management**.
+1. Select **Add a domain**.
+1. Enter your domain and select **Add domain**.
+1. In the pop-up modal, copy the **TXT Record Value** to verify your domain.
+
+### Verify a domain
+
+Verification confirms that you own the domain by adding a TXT record to your Domain Name System (DNS) host. It can take up to 72 hours for the DNS change to propagate. Docker automatically checks for the record and confirms ownership once the change is recognized.
+
+> [!TIP]
+>
+> The record name field determines where the TXT record is added in your domain (root or subdomain). For root domains like `example.com`, use `@` or leave the record name empty, depending on your provider. Don't enter values like docker, `docker-verification`, `www`, or your domain name, as these may direct to the wrong place. Check your DNS provider's documentation to verify record name requirements.
+
+Follow the steps for your DNS provider to add the **TXT Record Value**. If
+your provider isn't listed, use the steps for "Other providers":
+
+{{< tabs >}}
+{{< tab name="AWS Route 53" >}}
+
+1. Add your TXT record to AWS by following [Creating records by using the Amazon Route 53 console](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html).
+1. Wait up to 72 hours for TXT record verification.
+1. Return to the **Domain management** page of the
+   **Identity & auth**, then **Domain management**, and select **Verify** next to
+   your domain name.
+
+{{< /tab >}}
+{{< tab name="Google Cloud DNS" >}}
+
+1. Add your TXT record to Google Cloud DNS by following [Verifying your domain with a TXT record](https://cloud.google.com/identity/docs/verify-domain-txt).
+1. Wait up to 72 hours for TXT record verification.
+1. Return to the **Domain management** page of the
+   **Identity & auth**, then **Domain management**, and select **Verify** next to
+   your domain name.
+
+{{< /tab >}}
+{{< tab name="GoDaddy" >}}
+
+1. Add your TXT record to GoDaddy by following [Add a TXT record](https://www.godaddy.com/help/add-a-txt-record-19232).
+1. Wait up to 72 hours for TXT record verification.
+1. Return to the **Domain management** page of the
+   **Identity & auth**, then **Domain management**, and select **Verify** next to
+   your domain name.
+
+{{< /tab >}}
+{{< tab name="Other providers" >}}
+
+1. Sign in to your domain host.
+1. Add a TXT record to your DNS settings using the **TXT Record Value** from Docker.
+1. Wait up to 72 hours for TXT record verification.
+1. Return to the **Domain management** page of the
+   **Identity & auth**, then **Domain management**, and select **Verify** next to
+   your domain name.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Audit domains for uncaptured users
+
+Domain audit identifies uncaptured users. Uncaptured users are Docker users who have authenticated using an email address associated with your verified domains but aren't members of your Docker organization.
+
+### Limitations
+
+Domain audit can't identify:
+
+- Users who access Docker Desktop without authenticating
+- Users who authenticate using an account that doesn't have an
+  email address associated with one of your verified domains
+
+To prevent unidentifiable users from accessing Docker Desktop, [enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md).
+
+### Run a domain audit
+
+1. Sign in to [Docker Home](https://app.docker.com) and choose your
+   company.
+1. Select **Identity & auth**, then **Domain management**.
+1. In **Domain audit**, select **Export Users** to export a CSV file
+   of uncaptured users.
+
+The CSV file contains the following columns:
+
+- Name: Docker user's display name
+- Username: Docker ID of the user
+- Email: Email address of the user
+
+### Invite uncaptured users
+
+You can bulk invite uncaptured users to your organization using the exported
+CSV file. For more information on bulk inviting users, see
+[Manage organization members](/manuals/admin/organization/manage/members.md).
+
+## Auto-provisioning
+
+[Auto-provisioning](/manuals/enterprise/security/provisioning/auto-provisioning.md) uses verified domains to associate organization members with email address that match the verified domains. To override auto-provisioning, you can configure one of the two alternative methods:
+
+- [Just-in-Time (JIT)](/manuals/enterprise/security/provisioning/just-in-time.md) provisioning
+- [System for Cross-domain Identity Management (SCIM)](/manuals/enterprise/security/provisioning/scim/_index.md)
+
+## Delete a domain
+
+Deleting a domain removes its TXT record value and disables any associated auto-provisioning.
+
+> [!WARNING]
+>
+> Deleting a domain will disable auto-provisioning for that domain and remove verification. This action cannot be undone.
+
+To delete a domain:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select
+   your organization. If your organization is part of a company, select the company
+   and configure the domain for the organization at the company level.
+1. Select **Identity & auth**, then **Domain management**.
+1. For the domain you want to delete, select the **Actions** menu, then
+   **Delete domain**.
+1. To confirm, select **Delete domain** in the pop-up modal.
diff --git a/content/manuals/enterprise/security/enforce-sign-in/_index.md b/content/manuals/enterprise/security/enforce-sign-in/_index.md
new file mode 100644
index 000000000000..82497c724f6f
--- /dev/null
+++ b/content/manuals/enterprise/security/enforce-sign-in/_index.md
@@ -0,0 +1,71 @@
+---
+title: Enforce sign-in for Docker Desktop
+linkTitle: Enforce sign-in
+description: Require users to sign in to Docker Desktop to access organization benefits and security features
+toc_max: 2
+keywords: authentication, registry.json, configure, enforce sign-in, docker desktop, security, .plist, registry key, mac, windows, organization
+tags: [admin]
+aliases:
+ - /security/for-admins/configure-sign-in/
+ - /security/for-admins/enforce-sign-in/
+weight: 30
+---
+
+{{< summary-bar feature_name="Enforce sign-in" >}}
+
+By default, users can access Docker Desktop without signing in to your organization.
+When users don't sign in as organization members, they miss out on subscription benefits and can bypass security features configured for your organization.
+
+You can enforce sign-in using several methods, depending on your setup:
+
+- [Registry key method (Windows only)](methods.md#registry-key-method-windows-only)
+- [Configuration profiles method (Mac only)](methods.md#configuration-profiles-method-mac-only)
+- [`.plist` method (Mac only)](methods.md#plist-method-mac-only)
+- [`registry.json` method (All)](methods.md#registryjson-method-all)
+
+This page provides an overview of how sign-in enforcement works.
+
+## How sign-in enforcement works
+
+When Docker Desktop detects a registry key, `.plist` file, or
+`registry.json` file:
+
+- A **Sign in required!** prompt appears, requiring users to sign
+  in as organization members to use Docker Desktop.
+- If users sign in with accounts that aren't organization members, they're
+  automatically signed out and can't use Docker Desktop. They can select **Sign in**
+  to try again with a different account.
+- When users sign in with organization member accounts, they can use Docker
+  Desktop normally.
+- When users sign out, the **Sign in required!** prompt reappears and they can
+  no longer use Docker Desktop unless they sign back in.
+
+> [!NOTE]
+>
+> Enforcing sign-in for Docker Desktop doesn't affect Docker CLI access. CLI access is only restricted for organizations that enforce single sign-on (SSO).
+
+### Impact on already-signed-in users
+
+When enforcement is first deployed, users who are already running Docker Desktop are not immediately affected. Docker Desktop only re-evaluates enforcement on restart.
+
+On the next Docker Desktop restart:
+
+- Users signed in with an organization member account are automatically re-authenticated and continue working uninterrupted.
+- Users signed in with a non-member account are immediately signed out on startup and see the **Sign in required!** prompt. 
+
+## Enforcing sign-in versus enforcing single sign-on (SSO)
+
+Enforcing Docker Desktop sign-in and [enforcing SSO](/manuals/enterprise/security/single-sign-on/connect.md#optional-enforce-sso) are different features that serve different purposes:
+
+
+| Enforcement                       | Description                                                     | Benefits                                                                                                                                                                                                                                                   |
+|:----------------------------------|:----------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Enforce sign-in only              | Users must sign in before using Docker Desktop                 | Ensures users receive the benefits of your subscription and ensures security features are applied. In addition, you gain insights into users’ activity.                                                                                                    |
+| Enforce single sign-on (SSO) only | If users sign in, they must sign in using SSO                  | Centralizes authentication and enforces unified policies set by the identity provider.                                                                                                                                                                     |
+| Enforce both                      | Users must sign in using SSO before using Docker Desktop       | Ensures users receive the benefits of your subscription and ensures security features are applied. In addition, you gain insights into users’ activity. It also centralizes authentication and enforces unified policies set by the identity provider. |
+| Enforce neither                   | If users sign in, they can use SSO or their Docker credentials | Lets users access Docker Desktop without barriers, at the cost of reduced security and insights.                                                                                                                                                  |
+
+## Next steps
+
+- To set up sign-in enforcement, see [Configure sign-in enforcement](/manuals/enterprise/security/enforce-sign-in/methods.md).
+- To configure SSO enforcement, see [Enforce SSO](/manuals/enterprise/security/single-sign-on/connect.md).
diff --git a/content/manuals/enterprise/security/enforce-sign-in/methods.md b/content/manuals/enterprise/security/enforce-sign-in/methods.md
new file mode 100644
index 000000000000..09648085c141
--- /dev/null
+++ b/content/manuals/enterprise/security/enforce-sign-in/methods.md
@@ -0,0 +1,316 @@
+---
+title: Configure sign-in enforcement
+linkTitle: Configure
+description: Configure sign-in enforcement for Docker Desktop using registry keys, configuration profiles, plist files, or registry.json files
+keywords: authentication, registry.json, configure, enforce sign-in, docker desktop, security, .plist, registry key, mac, windows, linux
+tags: [admin]
+aliases:
+ - /security/for-admins/enforce-sign-in/methods/
+---
+
+{{< summary-bar feature_name="Enforce sign-in" >}}
+
+You can enforce sign-in for Docker Desktop using several methods. Choose the method that best fits your organization's infrastructure and security requirements.
+
+## Choose your method
+
+| Method | Platform |
+|:-------|:---------|
+| Registry key | Windows only |
+| Configuration profiles | Mac only |
+| `plist` file | Mac only |
+| `registry.json` | All platforms |
+
+> [!TIP]
+>
+> For Mac, configuration profiles offer the highest security because they're
+protected by Apple's System Integrity Protection (SIP).
+
+## Windows: Registry key method
+
+{{< tabs >}}
+{{< tab name="Manual setup" >}}
+
+To configure the registry key method manually:
+
+1. Create the registry key:
+
+   ```console
+   $ HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Docker\Docker Desktop
+   ```
+1. Create a multi-string value name `allowedOrgs`.
+1. Use your organization names as string data. You can add multiple organizations:
+   - Use lowercase letters only
+   - Add each organization on a separate line
+   - Do not use spaces or commas as separators
+1. Restart Docker Desktop.
+1. Verify the **Sign in required!** prompt appears in Docker Desktop.
+
+{{< /tab >}}
+{{< tab name="Group Policy deployment" >}}
+
+Deploy the registry key across your organization using Group Policy:
+
+1. Create a registry script with the following structure:
+   - Path: `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Docker\Docker Desktop`
+   - Value name: `allowedOrgs` (multi-string)
+   - Value data: Your organization names, one per line, in lowercase only
+1. In Group Policy Management, create or edit a GPO.
+1. Navigate to **Computer Configuration** > **Preferences** > **Windows Settings** > **Registry**.
+1. Right-click **Registry** > **New** > **Registry Item**.
+1. Configure the registry item:
+   - Action: **Update**
+   - Path: `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Docker\Docker Desktop`
+   - Value name: `allowedOrgs`
+   - Value data: Your organization names
+1. Link the GPO to the target Organizational Unit.
+1. Test on a small group using `gpupdate/force`.
+1. Deploy organization-wide after verification.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Mac: Configuration profiles method (recommended)
+
+Configuration profiles provide the most secure enforcement method for Mac, as they're protected by Apple's System Integrity Protection.
+
+The payload is a dictionary of key-values. Docker Desktop supports the following keys:
+
+- `allowedOrgs`: Sets a list of organizations in one single string, where each organization is in lowercase only and is separated by a semi-colon. 
+- `overrideProxyHTTP`: Sets the URL of the HTTP proxy that must be used for outgoing HTTP requests.
+- `overrideProxyHTTPS`: Sets the URL of the HTTP proxy that must be used for outgoing HTTPS requests.
+- `overrideProxyExclude`: Bypasses proxy settings for the specified hosts and domains. Uses a comma-separated list.
+- `overrideProxyPAC`: Sets the file path where the PAC file is located. It has precedence over the remote PAC file on the selected proxy.
+- `overrideProxyEmbeddedPAC`: Sets the content of an in-memory PAC file. It has precedence over `overrideProxyPAC`.
+
+Overriding at least one of the proxy settings via Configuration profiles will automatically lock the settings as they're managed by Mac.
+
+
+1. Create a file named `docker.mobileconfig` and include the following content:
+   ```xml
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+   <plist version="1.0">
+   <dict>
+      <key>PayloadContent</key>
+      <array>
+         <dict>
+            <key>PayloadType</key>
+            <string>com.docker.config</string>
+            <key>PayloadVersion</key>
+            <integer>1</integer>
+            <key>PayloadIdentifier</key>
+            <string>com.docker.config</string>
+            <key>PayloadUUID</key>
+            <string>eed295b0-a650-40b0-9dda-90efb12be3c7</string>
+            <key>PayloadDisplayName</key>
+            <string>Docker Desktop Configuration</string>
+            <key>PayloadDescription</key>
+            <string>Configuration profile to manage Docker Desktop settings.</string>
+            <key>PayloadOrganization</key>
+            <string>Your company name</string>
+            <key>allowedOrgs</key>
+            <string>first_org;second_org</string>
+            <key>overrideProxyHTTP</key>
+            <string>http://company.proxy:port</string>
+            <key>overrideProxyHTTPS</key>
+            <string>https://company.proxy:port</string>
+         </dict>
+      </array>
+      <key>PayloadType</key>
+      <string>Configuration</string>
+      <key>PayloadVersion</key>
+      <integer>1</integer>
+      <key>PayloadIdentifier</key>
+      <string>com.yourcompany.docker.config</string>
+      <key>PayloadUUID</key>
+      <string>0deedb64-7dc9-46e5-b6bf-69d64a9561ce</string>
+      <key>PayloadDisplayName</key>
+      <string>Docker Desktop Config Profile</string>
+      <key>PayloadDescription</key>
+      <string>Config profile to enforce Docker Desktop settings for allowed organizations.</string>
+      <key>PayloadOrganization</key>
+      <string>Your company name</string>
+   </dict>
+   </plist>
+   ```
+1. Replace placeholders:
+   - Change `com.yourcompany.docker.config` to your company identifier
+   - Replace `Your company name` with your organization name making sure it is all lowercase
+   - Replace `PayloadUUID` with a randomly generated UUID
+   - Update the `allowedOrgs` value with your organization names (separated by semicolons)
+   - Replace `company.proxy:port` with http/https proxy server host(or IP address) and port
+1. Deploy the profile using your MDM solution.
+1. Verify the profile appears in **System Settings** > **General** > **Device Management** under **Device (Managed)**. Ensure the profile is listed with the correct name and settings.
+
+Some MDM solutions let you specify the payload as a plain dictionary of key-value settings without the full `.mobileconfig` wrapper:
+
+```xml
+<dict>
+   <key>allowedOrgs</key>
+   <string>first_org;second_org</string>
+   <key>overrideProxyHTTP</key>
+   <string>http://company.proxy:port</string>
+   <key>overrideProxyHTTPS</key>
+   <string>https://company.proxy:port</string>
+</dict>
+```
+
+## Mac: plist file method
+
+{{< tabs >}}
+{{< tab name="Manual creation" >}}
+
+1. Create the file `/Library/Application Support/com.docker.docker/desktop.plist`.
+1. Add this content, replacing `myorg1` and `myorg2` with your organization names and making sure they have lowercase letters only:
+   ```xml
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+   <plist version="1.0">
+     <dict>
+	     <key>allowedOrgs</key>
+	     <array>
+             <string>myorg1</string>
+             <string>myorg2</string>
+         </array>
+     </dict>
+   </plist>
+   ```
+1. Set file permissions to prevent editing by non-administrator users.
+1. Restart Docker Desktop.
+1. Verify the `Sign in required!` prompt appears in Docker Desktop.
+
+{{< /tab >}}
+{{< tab name="Shell script deployment" >}}
+
+Create and deploy a script for organization-wide distribution:
+
+```bash
+#!/bin/bash
+
+# Create directory if it doesn't exist
+sudo mkdir -p "/Library/Application Support/com.docker.docker"
+
+# Write the plist file
+sudo defaults write "/Library/Application Support/com.docker.docker/desktop.plist" allowedOrgs -array "myorg1" "myorg2"
+
+# Set appropriate permissions
+sudo chmod 644 "/Library/Application Support/com.docker.docker/desktop.plist"
+sudo chown root:admin "/Library/Application Support/com.docker.docker/desktop.plist"
+```
+
+Deploy this script using SSH, remote support tools, or your preferred deployment method.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## All platforms: registry.json method
+
+The registry.json method works across all platforms and offers flexible deployment options.
+
+### File locations
+
+Create the `registry.json` file (UTF-8 without BOM) at the appropriate location:
+
+| Platform | Location |
+| --- | --- |
+| Windows | `/ProgramData/DockerDesktop/registry.json` |
+| Mac | `/Library/Application Support/com.docker.docker/registry.json` |
+| Linux | `/usr/share/docker-desktop/registry/registry.json` |
+
+### Basic setup
+
+{{< tabs >}}
+{{< tab name="Manual creation" >}}
+
+1. Ensure users are members of your Docker organization.
+1. Create the `registry.json` file at the appropriate location for your platform.
+1. Add this content, replacing organization names with your own and making sure they have lowercase letters only:
+      ```json
+      {
+         "allowedOrgs": ["myorg1", "myorg2"]
+      }
+      ```
+1. Set file permissions to prevent user editing.
+1. Restart Docker Desktop.
+1. Verify the `Sign in required!` prompt appears in Docker Desktop.
+
+> [!TIP]
+>
+> If users have issues starting Docker Desktop after enforcing sign-in,
+> they may need to update to the latest version.
+
+{{< /tab >}}
+{{< tab name="Command line setup" >}}
+
+#### Windows (PowerShell as Administrator)
+
+```shell
+Set-Content /ProgramData/DockerDesktop/registry.json '{"allowedOrgs":["myorg1","myorg2"]}'
+```
+
+#### Mac
+
+```console
+sudo mkdir -p "/Library/Application Support/com.docker.docker"
+echo '{"allowedOrgs":["myorg1","myorg2"]}' | sudo tee "/Library/Application Support/com.docker.docker/registry.json"
+```
+
+#### Linux
+
+```console
+sudo mkdir -p /usr/share/docker-desktop/registry
+echo '{"allowedOrgs":["myorg1","myorg2"]}' | sudo tee /usr/share/docker-desktop/registry/registry.json
+```
+
+{{< /tab >}}
+{{< tab name="Installation-time setup" >}}
+
+Create the registry.json file during Docker Desktop installation:
+
+#### Windows
+
+```shell
+# PowerShell
+Start-Process '.\Docker Desktop Installer.exe' -Wait 'install --allowed-org=myorg'
+
+# Command Prompt
+"Docker Desktop Installer.exe" install --allowed-org=myorg1
+```
+
+> [!NOTE]
+>
+> The `--allowed-org` flag accepts only one organization. To enforce sign-in for multiple organizations on Mac, configure the `registry.json` file after installation.
+
+#### Mac
+
+```console
+sudo hdiutil attach Docker.dmg
+sudo /Volumes/Docker/Docker.app/Contents/MacOS/install --allowed-org=myorg
+sudo hdiutil detach /Volumes/Docker
+```
+> [!NOTE]
+>
+> The `--allowed-org` flag accepts only one organization. To enforce sign-in for multiple organizations on Mac, configure the `registry.json` file after installation.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Method precedence
+
+When multiple configuration methods exist on the same system, Docker Desktop uses this precedence order:
+
+1. Registry key (Windows only)
+1. Configuration profiles (Mac only)
+1. plist file (Mac only)
+1. registry.json file
+
+## Troubleshoot sign-in enforcement
+
+If sign-in enforcement doesn't work:
+
+- Verify file locations and permissions
+- Check that organization names use lowercase letters
+- Restart Docker Desktop or reboot the system
+- Confirm users are members of the specified organizations
+- Update Docker Desktop to the latest version
diff --git a/content/manuals/enterprise/security/hardened-desktop/_index.md b/content/manuals/enterprise/security/hardened-desktop/_index.md
new file mode 100644
index 000000000000..6fb7a7ae9749
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/_index.md
@@ -0,0 +1,65 @@
+---
+title: Hardened Docker Desktop
+linkTitle: Hardened Docker Desktop
+description: Security features that help organizations secure developer environments without impacting productivity
+keywords: security, hardened desktop, enhanced container isolation, registry access management, settings management, admins, docker desktop, image access management, air-gapped containers
+tags: [admin]
+aliases:
+ - /security/for-admins/hardened-desktop/
+grid:
+  - title: "Settings Management"
+    description: Learn how Settings Management can secure your developers' workflows.
+    icon: shield-check
+    link: /enterprise/security/hardened-desktop/settings-management/
+  - title: "Enhanced Container Isolation"
+    description: Understand how Enhanced Container Isolation can prevent container attacks.
+    icon: shield-check
+    link: /enterprise/security/hardened-desktop/enhanced-container-isolation/
+  - title: "Registry Access Management"
+    description: Control the registries developers can access while using Docker Desktop.
+    icon: server
+    link: /enterprise/security/hardened-desktop/registry-access-management/
+  - title: "Image Access Management"
+    description: Control the images developers can pull from Docker Hub.
+    icon: photo
+    link: /enterprise/security/hardened-desktop/image-access-management/
+  - title: "Air-Gapped Containers"
+    description: Restrict containers from accessing unwanted network resources.
+    icon: lock-closed
+    link: /enterprise/security/hardened-desktop/air-gapped-containers/
+  - title: "Namespace access"
+    description: Control whether organization members can push content to their personal namespaces.
+    icon: folder-open
+    link: /enterprise/security/hardened-desktop/namespace-access/
+weight: 60
+---
+
+{{< summary-bar feature_name="Hardened Docker Desktop" >}}
+
+Hardened Docker Desktop provides a collection of security features designed to strengthen developer environments without compromising productivity or developer experience.
+
+With Hardened Docker Desktop, you can enforce strict security policies that prevent developers and containers from bypassing organizational controls. You can also enhance container isolation to protect against security threats like malicious payloads that might breach the Docker Desktop Linux VM or underlying host system.
+
+## Who should use Hardened Docker Desktop?
+
+Hardened Docker Desktop is ideal for security-focused organizations that:
+
+- Don't provide root or administrator access to developers' machines
+- Want centralized control over Docker Desktop configurations
+- Must meet specific compliance requirements
+
+## How Hardened Docker Desktop works
+
+Hardened Docker Desktop features work independently and together to create a defense-in-depth security strategy. They protect developer workstations against attacks across multiple layers, including Docker Desktop configuration, container image management, and container runtime security:
+
+- Registry Access Management and Image Access Management prevent access to unauthorized container registries and image types, reducing exposure to malicious payloads
+- Enhanced Container Isolation runs containers without root privileges inside a Linux user namespace, limiting the impact of malicious containers
+- Air-gapped containers let you configure network restrictions for containers, preventing malicious containers from accessing your organization's internal network resources
+- Namespace access controls whether organization members can push content to their personal Docker Hub namespaces, preventing accidental publication of images outside approved locations
+- Settings Management locks down Docker Desktop configurations to enforce company policies and prevent developers from introducing insecure settings, whether intentionally or accidentally
+
+## Next steps
+
+Explore Hardened Docker Desktop features to understand how they can strengthen your organization's security posture:
+
+{{< grid >}}
diff --git a/content/manuals/enterprise/security/hardened-desktop/air-gapped-containers.md b/content/manuals/enterprise/security/hardened-desktop/air-gapped-containers.md
new file mode 100644
index 000000000000..36eb900d1e10
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/air-gapped-containers.md
@@ -0,0 +1,231 @@
+---
+title: Air-gapped containers
+description: Restrict outbound container traffic using proxy rules, PAC files, and network isolation with Docker Desktop air-gapped containers
+keywords: air gapped containers, network security, proxy configuration, container isolation, docker desktop, PAC file, network isolation
+aliases:
+ - /security/for-admins/hardened-desktop/air-gapped-containers/
+weight: 30
+---
+
+{{< summary-bar feature_name="Air-gapped containers" >}}
+
+Air-gapped containers let you restrict container network access by controlling where containers can send and receive data. This feature applies custom proxy rules to container network traffic, helping secure environments where containers shouldn't have unrestricted internet access.
+
+Docker Desktop can configure container network traffic to accept connections, reject connections, or tunnel through HTTP or SOCKS proxies. You control which TCP ports the policy applies to and whether to use a single proxy or per-destination policies via Proxy Auto-Configuration (PAC) files.
+
+## Who should use air-gapped containers?
+
+Use air-gapped containers if:
+
+- Your organization requires containers to communicate only with approved internal services
+- You need to meet compliance standards that mandate network isolation (such as SOC 2, ISO 27001, or PCI DSS)
+- You want to prevent containers from leaking data or reaching unapproved external endpoints during builds or at runtime
+
+## How air-gapped containers work
+
+`containersProxy` governs two distinct traffic paths:
+
+- Image pulls (always enforced): Docker Desktop hardwires `http.docker.internal:3128` as the daemon's proxy in `daemon.json` at VM startup, so all `docker pull` and Compose pull operations always go through `containersProxy`, including any PAC file rules.
+- Running container outbound traffic (opt-in): Docker Desktop intercepts container TCP connections and applies proxy rules only for ports listed in `transparentPorts`. Without it, running container traffic bypasses `containersProxy` entirely.
+
+> [!IMPORTANT]
+>
+> If you configure a PAC file under `containersProxy`, the PAC file must return an appropriate proxy server to connect to the registries where your images are hosted.
+
+Other considerations:
+
+- If PAC file download fails, containers block requests to target URLs
+- Hostname is available for ports 80 and 443, but only IP addresses for other ports
+
+## Prerequisites
+
+Before configuring air-gapped containers, you must have:
+
+- [Enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) enabled to ensure users authenticate with your organization
+- A Docker Business subscription
+- Configured [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md) with the `admin-settings.json` file to manage organization policies
+
+## Configure air-gapped containers
+
+Add the container proxy to your [`admin-settings.json` file](/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md). For example:
+
+```json
+{
+  "configurationFileVersion": 2,
+  "containersProxy": {
+    "locked": true,
+    "mode": "manual",
+    "http": "",
+    "https": "",
+    "exclude": [],
+    "pac": "http://192.168.1.16:62039/proxy.pac",
+    "transparentPorts": "*"
+  }
+}
+```
+
+### Configuration parameters
+
+The `containersProxy` setting controls network policies applied to `docker image pull` and, when `transparentPorts` is configured, running container outbound traffic:
+
+| Parameter | Description | Value |
+|-----------|-------------|-------|
+| `locked` | Prevents developers from overriding settings | `true` (locked), `false` (default) |
+| `mode` | Proxy configuration method | `system` (use system proxy), `manual` (custom) |
+| `http` | HTTP proxy server | URL (e.g., `"http://proxy.company.com:8080"`) |
+| `https` | HTTPS proxy server | URL (e.g., `"https://proxy.company.com:8080"`) |
+| `exclude` | Bypass proxy for these addresses | Array of hostnames/IPs |
+| `pac` | Proxy Auto-Configuration file URL | URL to PAC file |
+| `transparentPorts` | Ports subject to proxy rules | Comma-separated ports or wildcard (`"*"`) |
+
+### Configuration examples
+
+Block all external access:
+
+```json
+"containersProxy": {
+  "locked": true,
+  "mode": "manual",
+  "http": "",
+  "https": "",
+  "exclude": [],
+  "transparentPorts": "*"
+}
+```
+
+Allow specific internal services:
+
+```json
+"containersProxy": {
+  "locked": true,
+  "mode": "manual",
+  "http": "",
+  "https": "",
+  "exclude": ["internal.company.com", "10.0.0.0/8"],
+  "transparentPorts": "80,443"
+}
+```
+
+Route through corporate proxy:
+
+```json
+"containersProxy": {
+  "locked": true,
+  "mode": "manual",
+  "http": "http://corporate-proxy.company.com:8080",
+  "https": "http://corporate-proxy.company.com:8080",
+  "exclude": ["localhost", "*.company.local"],
+  "transparentPorts": "*"
+}
+```
+
+## Proxy Auto-Configuration (PAC) files
+
+PAC files provide fine-grained control over container network access by defining rules for different destinations.
+
+### Basic PAC file structure
+
+```javascript
+function FindProxyForURL(url, host) {
+	if (localHostOrDomainIs(host, 'internal.corp')) {
+		return "PROXY 10.0.0.1:3128";
+	}
+	if (isInNet(host, "192.168.0.0", "255.255.255.0")) {
+	    return "DIRECT";
+	}
+    return "PROXY reject.docker.internal:1234";
+}
+```
+
+### General considerations
+
+ - `FindProxyForURL` function URL parameter format is `http://host_or_ip:port` or `https://host_or_ip:port`
+ - If you have an internal container trying to access `https://docs.docker.com/enterprise/security/hardened-desktop/air-gapped-containers` the Docker proxy service will submit docs.docker.com for the host value and https://docs.docker.com:443 for the url value to `FindProxyForURL`, if you are using `shExpMatch` function in your PAC file as follows:
+
+   ```console
+   if(shExpMatch(url, "https://docs.docker.com:443/enterprise/security/*")) return "DIRECT";
+   ```
+
+   `shExpMatch` function will fail, instead use:
+
+   ```console
+   if (host == docs.docker.com && url.indexOf(":443") > 0) return "DIRECT";
+   ```
+
+### PAC file return values
+
+| Return value | Action |
+|--------------|--------|
+| `PROXY host:port` | Route through HTTP proxy at specified host and port |
+| `SOCKS5 host:port` | Route through SOCKS5 proxy at specified host and port |
+| `DIRECT` | Allow direct connection without proxy |
+| `PROXY reject.docker.internal:any_port` | Block the request completely |
+
+### Advanced PAC file example
+
+```javascript
+function FindProxyForURL(url, host) {
+  // Allow access to Docker Hub for approved base images
+  if (dnsDomainIs(host, ".docker.io") || host === "docker.io") {
+    return "PROXY corporate-proxy.company.com:8080";
+  }
+
+  // Allow internal package repositories
+  if (localHostOrDomainIs(host, 'nexus.company.com') ||
+      localHostOrDomainIs(host, 'artifactory.company.com')) {
+    return "DIRECT";
+  }
+
+  // Allow development tools on specific ports
+  if (url.indexOf(":3000") > 0 || url.indexOf(":8080") > 0) {
+    if (isInNet(host, "10.0.0.0", "255.0.0.0")) {
+      return "DIRECT";
+    }
+  }
+
+  // Block access to developer's localhost
+  if (host === "host.docker.internal" || host === "localhost") {
+    return "PROXY reject.docker.internal:1234";
+  }
+
+  // Block all other external access
+  return "PROXY reject.docker.internal:1234";
+}
+```
+
+## Verify air-gapped container configuration
+
+After applying the configuration, test that container network restrictions work:
+
+Test blocked access:
+
+```console
+$ docker run --rm alpine wget -O- https://www.google.com
+# Should fail or timeout based on your proxy rules
+```
+
+Test allowed access:
+
+```console
+$ docker run --rm alpine wget -O- https://internal.company.com
+# Should succeed if internal.company.com is in your exclude list or PAC rules
+```
+
+Test proxy routing:
+
+```console
+$ docker run --rm alpine wget -O- https://docker.io
+# Should succeed if routed through approved proxy
+```
+
+## Security considerations
+
+- Network policy enforcement: Air-gapped containers work at the Docker Desktop level. Advanced users might bypass restrictions through various means, so consider additional network-level controls for high-security environments.
+- Development workflow impact: Overly restrictive policies can break legitimate development workflows. Test thoroughly and provide clear exceptions for necessary services.
+- PAC file management: Host PAC files on reliable internal infrastructure. Failed PAC downloads result in blocked container network access.
+- Performance considerations: Complex PAC files with many rules may impact container network performance. Keep rules simple and efficient.
+
+## Next steps
+
+- [Explore Enhanced Container Isolation](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md) to further restrict what containers can do at runtime
+- [Understand how Docker Desktop handles host and container networking](/manuals/desktop/features/networking/_index.md)
\ No newline at end of file
diff --git a/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md b/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md
new file mode 100644
index 000000000000..6651dcd4f208
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md
@@ -0,0 +1,215 @@
+---
+title: Enhanced Container Isolation
+linkTitle: Enhanced Container Isolation
+description: Enhanced Container Isolation provides additional security for Docker Desktop by preventing malicious containers from compromising the host
+keywords: enhanced container isolation, container security, sysbox runtime, linux user namespaces, hardened desktop
+aliases:
+ - /desktop/hardened-desktop/enhanced-container-isolation/
+ - /security/for-admins/hardened-desktop/enhanced-container-isolation/
+weight: 10
+---
+
+{{< summary-bar feature_name="Hardened Docker Desktop" >}}
+
+Enhanced Container Isolation (ECI) prevents malicious containers from compromising Docker Desktop or the host system. It applies advanced security techniques automatically while maintaining full developer productivity and workflow compatibility.
+
+- ECI strengthens container isolation and locks in security configurations created by administrators, such as [Registry Access Management policies](/manuals/enterprise/security/hardened-desktop/registry-access-management.md) and [Settings Management](../settings-management/_index.md) controls. 
+- ECI works alongside other Docker security features like reduced Linux capabilities, seccomp, and AppArmor.
+
+If you are using WSL2 backend, ensure you’re running WSL version 2.6 or later. This is required because ECI depends on a Linux kernel version of at least 6.3.0, and WSL 2.6+ includes kernel version 6.6.
+
+## Who should use Enhanced Container Isolation?
+
+ECI is designed for:
+
+- Organizations that want to prevent container-based attacks and reduce security vulnerabilities in developer environments
+- Security teams that need stronger container isolation without impacting developer workflows
+- Enterprises that require additional protection when running untrusted or third-party container images
+
+## How Enhanced Container Isolation works
+
+Docker implements ECI using the [Sysbox container runtime](https://github.com/nestybox/sysbox), a
+security-enhanced fork of the standard OCI runc runtime. When ECI is turned on, containers created through `docker run` or `docker create` automatically use Sysbox instead of runc without requiring any changes to developer workflows. Docker's default runtime remains runc, but all user containers
+implicitly launch with Sysbox. 
+
+When ECI is turned on, the Docker CLI `--runtime` flag is ignored. Even containers using the `--privileged` flag run securely with ECI, preventing them from breaching the Docker Desktop virtual machine or other containers.
+
+## Key security features
+
+### Linux user namespace isolation
+
+With Enhanced Container Isolation, all containers leverage Linux user namespaces for stronger isolation. Container root users map to unprivileged users in the Docker Desktop VM:
+
+```console
+$ docker run -it --rm --name=first alpine
+/ # cat /proc/self/uid_map
+         0     100000      65536
+```
+
+This output shows that container root (0) maps to unprivileged user 100000 in the VM, with a range of 64K user IDs. Each container gets exclusive mappings:
+
+```console
+$ docker run -it --rm --name=second alpine
+/ # cat /proc/self/uid_map
+         0     165536      65536
+```
+
+Without Enhanced Container Isolation, containers run as true root:
+
+```console
+$ docker run -it --rm alpine
+/ # cat /proc/self/uid_map
+         0       0     4294967295
+```
+
+By using Linux user namespaces, ECI ensures container processes never run with valid user IDs in the Linux VM, constraining their capabilities to resources within the container only.
+
+### Secured privileged containers
+
+Privileged containers (`docker run --privileged`) normally pose significant security risks because they provide unrestricted access to the Linux kernel. Without ECI, privileged containers can:
+
+- Run as true root with all capabilities
+- Bypass seccomp and AppArmor restrictions
+- Access all hardware devices
+- Modify global kernel settings
+
+Organizations securing developer environments face challenges with privileged containers because they can gain control of the Docker Desktop VM and alter security settings like registry access management and network proxies.
+
+Enhanced Container Isolation transforms privileged containers by ensuring they can only access resources within their container boundary. For example, privileged containers can't access Docker Desktop's network configuration:
+
+```console
+$ docker run --privileged djs55/bpftool map show
+Error: can't get next map: Operation not permitted
+```
+
+Without ECI, privileged containers can easily access and modify these settings:
+
+```console
+$ docker run --privileged djs55/bpftool map show
+17: ringbuf  name blocked_packets  flags 0x0
+        key 0B  value 0B  max_entries 16777216  memlock 0B
+18: hash  name allowed_map  flags 0x0
+        key 4B  value 4B  max_entries 10000  memlock 81920B
+```
+
+Advanced container workloads like Docker-in-Docker and Kubernetes-in-Docker still work with ECI but run much more securely.
+
+> [!NOTE]
+>
+> ECI doesn't prevent users from running privileged containers, but makes them secure by containing their access. Privileged workloads that modify global kernel settings (loading kernel modules, changing Berkeley Packet Filter settings) receive "permission denied" errors.
+
+### Namespace isolation enforcement
+
+Enhanced Container Isolation prevents containers from sharing Linux namespaces with the Docker Desktop VM, maintaining isolation boundaries:
+
+**PID namespace sharing blocked:**
+
+```console
+$ docker run -it --rm --pid=host alpine
+docker: Error response from daemon: failed to create shim task: OCI runtime create failed: error in the container spec: invalid or unsupported container spec: sysbox containers can't share namespaces [pid] with the host (because they use the linux user-namespace for isolation): unknown.
+```
+
+**Network namespace sharing blocked:**
+
+```console
+$ docker run -it --rm --network=host alpine
+docker: Error response from daemon: failed to create shim task: OCI runtime create failed: error in the container spec: invalid or unsupported container spec: sysbox containers can't share a network namespace with the host (because they use the linux user-namespace for isolation): unknown.
+```
+
+**User namespace override ignored:**
+
+```console
+$ docker run -it --rm --userns=host alpine
+/ # cat /proc/self/uid_map
+         0     100000      65536
+```
+
+Docker build operations using `--network-host` and Docker buildx entitlements (`network.host`,
+`security.insecure`) are also blocked.
+
+### Protected bind mounts
+
+Enhanced Container Isolation maintains support for standard file sharing while preventing access to sensitive VM directories:
+
+Host directory mounts continue to work:
+
+```console
+$ docker run -it --rm -v $HOME:/mnt alpine
+/ # ls /mnt
+# Successfully lists home directory contents
+```
+
+VM configuration mounts are blocked:
+
+```console
+$ docker run -it --rm -v /etc/docker/daemon.json:/mnt/daemon.json alpine
+docker: Error response from daemon: failed to create shim task: OCI runtime create failed: error in the container spec: can't mount /etc/docker/daemon.json because it's configured as a restricted host mount: unknown
+```
+
+This prevents containers from reading or modifying Docker Engine configurations, registry access management settings, proxy configurations, and other security-related VM files.
+
+> [!NOTE]
+>
+> By default, ECI blocks bind mounting the Docker Engine socket (/var/run/docker.sock) as this would grant containers control over Docker Engine. Administrators can create exceptions for trusted container images.
+
+### Advanced system call protection
+
+Enhanced Container Isolation intercepts sensitive system calls to prevent containers from using legitimate capabilities maliciously:
+
+```console
+$ docker run -it --rm --cap-add SYS_ADMIN -v $HOME:/mnt:ro alpine
+/ # mount -o remount,rw /mnt /mnt
+mount: permission denied (are you root?)
+```
+
+Even with `CAP_SYS_ADMIN` capability, containers can't change read-only bind mounts to read-write, ensuring they can't breach container boundaries.
+
+Containers can still create internal mounts within their filesystem:
+
+```console
+/ # mkdir /root/tmpfs
+/ # mount -t tmpfs tmpfs /root/tmpfs
+/ # mount -o remount,ro /root/tmpfs /root/tmpfs
+/ # findmnt | grep tmpfs
+├─/root/tmpfs    tmpfs      tmpfs    ro,relatime,uid=100000,gid=100000
+```
+
+ECI performs system call filtering efficiently by intercepting only control-path system calls (rarely used) while leaving data-path system calls unaffected, maintaining container performance.
+
+### Automatic filesystem user ID mapping
+
+Enhanced Container Isolation solves file sharing challenges between containers with different user ID ranges through automatic filesystem mapping.
+
+Each container gets exclusive user ID mappings, but Sysbox uses filesystem user ID remapping via Linux kernel ID-mapped mounts (added in 2021) or alternative shiftsfs module. This maps filesystem accesses from containers' real user IDs to standard ranges, enabling:
+
+- Volume sharing across containers with different user ID ranges
+- Consistent file ownership regardless of container user ID mappings
+- Transparent file access without user intervention
+
+### Information hiding through filesystem emulation
+
+ECI emulates portions of `/proc` and `/sys` filesystems within containers to hide sensitive host information and provide per-container views of kernel resources:
+
+```console
+$ docker run -it --rm alpine
+/ # cat /proc/uptime
+5.86 5.86
+```
+
+This shows container uptime instead of Docker Desktop VM uptime, preventing system information from leaking into containers.
+
+Several `/proc/sys` resources that aren't namespaced by the Linux kernel are emulated per-container, with Sysbox coordinating values when programming kernel settings. This enables container workloads that normally require privileged access to run securely.
+
+## Performance and compatibility
+
+Enhanced Container Isolation maintains optimized performance and full compatibility:
+
+- No performance impact: System call filtering targets only control-path calls, leaving data-path operations unaffected
+- Full workflow compatibility: Existing development processes, tools, and container images work unchanged
+- Advanced workload support: Docker-in-Docker, Kubernetes-in-Docker, and other complex scenarios work securely
+- Automatic management: User ID mappings, filesystem access, and security policies are handled automatically
+- Standard image support: No special container images or modifications required
+
+> [!IMPORTANT]
+>
+> ECI protection varies by Docker Desktop version and doesn't yet protect extension containers. Docker builds and Kubernetes in Docker Desktop have varying protection levels depending on the version. For details, see [Enhanced Container Isolation limitations](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/limitations.md).
diff --git a/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md b/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md
new file mode 100644
index 000000000000..2ce32c791dd2
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md
@@ -0,0 +1,282 @@
+---
+title: Configure Docker socket exceptions and advanced settings
+linkTitle: Configure advanced settings
+description: Configure Docker socket exceptions and advanced settings for Enhanced Container Isolation
+keywords: enhanced container isolation, docker socket, configuration, testcontainers, admin settings
+aliases:
+ - /security/for-admins/hardened-desktop/enhanced-container-isolation/config/
+weight: 20
+---
+
+{{< summary-bar feature_name="Hardened Docker Desktop" >}}
+
+This page shows you how to configure Docker socket exceptions and other advanced settings for Enhanced Container Isolation (ECI). These configurations enable trusted tools like Testcontainers to work with ECI while maintaining security.
+
+## Docker socket mount permissions
+
+By default, Enhanced Container Isolation blocks containers from mounting the Docker socket to prevent malicious access to Docker Engine. However, some tools require Docker socket access.
+
+Common scenarios requiring Docker socket access include:
+
+- Testing frameworks: Testcontainers, which manages test containers
+- Build tools: Paketo buildpacks that create ephemeral build containers
+- CI/CD tools: Tools that manage containers as part of deployment pipelines
+- Development utilities: Docker CLI containers for container management
+
+## Configure socket exceptions
+
+Configure Docker socket exceptions using Settings Management:
+
+{{< tabs >}}
+{{< tab name="Docker Home" >}}
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization from the top-left account drop-down.
+1. Select **Docker Desktop**, then **Settings Management**.
+1. [Create or edit a setting policy](/manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console.md).
+1. Find **Enhanced Container Isolation** settings.
+1. Configure **Docker socket access control** with your trusted images and
+command restrictions.
+
+{{< /tab >}}
+{{< tab name="JSON file" >}}
+
+Create an [`admin-settings.json` file](/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md) and add:
+
+```json
+{
+  "configurationFileVersion": 2,
+  "enhancedContainerIsolation": {
+    "locked": true,
+    "value": true,
+    "dockerSocketMount": {
+      "imageList": {
+        "images": [
+          "docker.io/localstack/localstack:*",
+          "docker.io/testcontainers/ryuk:*",
+          "docker:cli"
+        ],
+        "allowDerivedImages": true
+      },
+      "commandList": {
+        "type": "deny",
+        "commands": ["push", "build"]
+      }
+    }
+  }
+}
+```
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Image allowlist configuration
+
+The `imageList` defines which container images can mount the Docker socket.
+
+### Image reference formats
+
+| Format  | Description |
+| :---------------------- | :---------- |
+| `<image_name>[:<tag>]`  | Name of the image, with optional tag. If the tag is omitted, the `:latest` tag is used. If the tag is the wildcard `*`, then it means "any tag for that image." |
+| `<image_name>@<digest>` | Name of the image, with a specific repository digest (e.g., as reported by `docker buildx imagetools inspect <image>`). This means only the image that matches that name and digest is allowed. |
+
+### Example configurations
+
+Basic allowlist for testing tools:
+
+```json
+"imageList": {
+  "images": [
+    "docker.io/testcontainers/ryuk:*",
+    "docker:cli",
+    "alpine:latest"
+  ]
+}
+```
+
+Wildcard allowlist (Docker Desktop 4.36 and later):
+
+```json
+"imageList": {
+  "images": ["*"]
+}
+```
+
+> [!WARNING]
+>
+> Using `"*"` allows all containers to mount the Docker socket, which reduces security. Only use this when explicitly listing allowed images isn't feasible.
+
+### Security validation
+
+Docker Desktop validates allowed images by:
+
+1. Downloading image digests from registries for allowed images
+1. Comparing container image digests against the allowlist when containers start
+1. Blocking containers whose digests don't match allowed images
+
+This prevents bypassing restrictions by re-tagging unauthorized images:
+
+```console
+$ docker tag malicious-image docker:cli
+$ docker run -v /var/run/docker.sock:/var/run/docker.sock docker:cli
+# This fails because the digest doesn't match the real docker:cli image
+```
+
+## Derived images support
+
+For tools like Paketo buildpacks that create ephemeral local images, you can
+allow images derived from trusted base images.
+
+### Enable derived images
+
+```json
+"imageList": {
+  "images": [
+    "paketobuildpacks/builder:base"
+  ],
+  "allowDerivedImages": true
+}
+```
+
+When `allowDerivedImages` is true, local images built from allowed base images (using `FROM` in Dockerfile) also gain Docker socket access.
+
+### Derived images requirements
+
+- Local images only: Derived images must not exist in remote registries
+- Base image available: The parent image must be pulled locally first
+- Performance impact: Adds up to 1 second to container startup for validation
+- Version compatibility: Full wildcard support requires Docker Desktop 4.36+
+
+## Command restrictions
+
+### Deny list (recommended)
+
+Blocks specified commands while allowing all others:
+
+```json
+"commandList": {
+  "type": "deny",
+  "commands": ["push", "build", "image*"]
+}
+```
+
+### Allow list
+
+Only allows specified commands while blocking all others:
+
+```json
+"commandList": {
+  "type": "allow",
+  "commands": ["ps", "container*", "volume*"]
+}
+```
+
+### Command wildcards
+
+| Wildcard | Blocks/allows |
+| :---------------- | :---------- |
+| `"container\*"`     | All "docker container ..." commands |
+| `"image\*"`         | All "docker image ..." commands |
+| `"volume\*"`        | All "docker volume ..." commands |
+| `"network\*"`       | All "docker network ..." commands |
+| `"build\*"`         | All "docker build ..." commands |
+| `"system\*"`        | All "docker system ..." commands |
+
+### Command blocking example
+
+When a blocked command is executed:
+
+```console
+/ # docker push myimage
+Error response from daemon: enhanced container isolation: docker command "/v1.43/images/myimage/push?tag=latest" is blocked; if you wish to allow it, configure the docker socket command list in the Docker Desktop settings.
+```
+
+## Common configuration examples
+
+### Testcontainers setup
+
+For Java/Python testing with Testcontainers:
+
+```json
+"dockerSocketMount": {
+  "imageList": {
+    "images": [
+      "docker.io/testcontainers/ryuk:*",
+      "testcontainers/*:*"
+    ]
+  },
+  "commandList": {
+    "type": "deny",
+    "commands": ["push", "build"]
+  }
+}
+```
+
+### CI/CD pipeline tools
+
+For controlled CI/CD container management:
+
+```json
+"dockerSocketMount": {
+  "imageList": {
+    "images": [
+      "docker:cli",
+      "your-registry.com/ci-tools/*:*"
+    ]
+  },
+  "commandList": {
+    "type": "allow",
+    "commands": ["ps", "container*", "image*"]
+  }
+}
+```
+
+### Development environments
+
+For local development with Docker-in-Docker:
+
+```json
+"dockerSocketMount": {
+  "imageList": {
+    "images": [
+      "docker:dind",
+      "docker:cli"
+    ]
+  },
+  "commandList": {
+    "type": "deny",
+    "commands": ["system*"]
+  }
+}
+```
+
+## Security recommendations
+
+### Image allowlist best practices
+
+- Be restrictive: Only allow images you absolutely trust and need
+- Use wildcards carefully: Tag wildcards (`*`) are convenient but less secure than specific tags
+- Regular reviews: Periodically review and update your allowlist
+- Digest pinning: Use digest references for maximum security in critical environments
+
+### Command restrictions
+
+- Default to deny: Start with a deny list blocking dangerous commands like `push` and `build`
+- Principle of least privilege: Only allow commands your tools actually need
+- Monitor usage: Track which commands are being blocked to refine your configuration
+
+### Monitoring and maintenance
+
+- Regular validation: Test your configuration after Docker Desktop updates, as image digests may change.
+- Handle digest mismatches: If allowed images are unexpectedly blocked:
+    ```console
+    $ docker image rm <image>
+    $ docker pull <image>
+    ```
+
+This resolves digest mismatches when upstream images are updated.
+
+## Next steps
+
+- Review [Enhanced Container Isolation limitations](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/limitations.md).
+- Review [Enhanced Container Isolation FAQs](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/faq.md).
diff --git a/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/enable-eci.md b/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/enable-eci.md
new file mode 100644
index 000000000000..6b554f4b28a2
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/enable-eci.md
@@ -0,0 +1,168 @@
+---
+title: Enable Enhanced Container Isolation
+linkTitle: Enable ECI
+description: Enable Enhanced Container Isolation to secure containers in Docker Desktop
+keywords: enhanced container isolation, enable eci, container security, docker desktop setup
+weight: 15
+---
+
+{{< summary-bar feature_name="Hardened Docker Desktop" >}}
+
+ECI prevents malicious containers from compromising Docker Desktop while maintaining full developer productivity.
+
+This page shows you how to turn on Enhanced Container Isolation (ECI) and verify it's working correctly.
+
+## Prerequisites
+
+Before you begin, you must have:
+
+- A Docker Business subscription
+- [Enforced sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) (for administrators managing organization-wide settings only)
+
+## Enable Enhanced Container Isolation
+
+### For developers
+
+Turn on ECI in your Docker Desktop settings:
+
+1. Sign in to your organization in Docker Desktop. Your organization must have
+a Docker Business subscription.
+1. Stop and remove all existing containers:
+
+    ```console
+    $ docker stop $(docker ps -q)
+    $ docker rm $(docker ps -aq)
+    ```
+
+1. In Docker Desktop, go to **Settings** > **General**.
+1. Select the **Use Enhanced Container Isolation** checkbox.
+1. Select **Apply and restart**.
+
+> [!IMPORTANT]
+>
+> ECI doesn't protect containers created before turning on the feature. Remove existing containers before turning on ECI.
+
+### For administrators
+
+Configure Enhanced Container Isolation organization-wide using Settings Management:
+
+{{< tabs >}}
+{{< tab name="Docker Home" >}}
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization from the top-left account drop-down.
+1. Select **Docker Desktop**, then **Settings Management**.
+1. [Create or edit a setting policy](/manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console.md).
+1. Set **Enhanced Container Isolation** to **Always enabled**.
+
+{{< /tab >}}
+{{< tab name="JSON file" >}}
+
+1. Create an [`admin-settings.json` file](/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md) and add:
+
+      ```json
+      {
+        "configurationFileVersion": 2,
+        "enhancedContainerIsolation": {
+          "value": true,
+          "locked": true
+        }
+      }
+      ```
+
+1. Configure the following as needed:
+    - `"value": true`: Turns on ECI by default (required)
+    - `"locked": true`: Prevents developers from turning off ECI
+    - `"locked": false`: Allows developers to control the setting
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Apply the configuration
+
+For ECI settings to take effect:
+
+- New installations: Users launch Docker Desktop and sign in
+- Existing installations: Users must fully quit Docker Desktop and relaunch
+
+> [!IMPORTANT]
+>
+> Restarting from the Docker Desktop menu isn't sufficient. Users must completely quit and reopen Docker Desktop.
+
+You can also configure [Docker socket mount permissions](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md) for trusted images that need Docker API access.
+
+## Verify Enhanced Container Isolation is active
+
+After turning on ECI, verify it's working correctly using these methods.
+
+### Check user namespace mapping
+
+Run a container and examine the user namespace mapping:
+
+```console
+$ docker run --rm alpine cat /proc/self/uid_map
+```
+
+With ECI turned on:
+
+```text
+0     100000      65536
+```
+
+This shows the container's root user (0) maps to an unprivileged user (100000) in the Docker Desktop VM, with a range of 64K user IDs. Each container gets an exclusive user ID range for isolation.
+
+With ECI turned off:
+
+```text
+0          0 4294967295
+```
+
+This shows the container root user (0) maps directly to the VM root user (0), providing less isolation.
+
+### Check container runtime
+
+Verify the container runtime being used:
+
+```console
+$ docker inspect --format='{{.HostConfig.Runtime}}' <container_name>
+```
+
+With ECI turned on, it turns `sysbox-runc`. With ECI turned off, it returns
+`runc`.
+
+### Test security restrictions
+
+Verify that ECI security restrictions are active.
+
+Test namespace sharing:
+
+```console
+$ docker run -it --rm --pid=host alpine
+```
+
+With ECI turned on, this command fails with an error about Sysbox containers
+not being able to share namespaces with the host.
+
+Test Docker socket access:
+
+```console
+$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock alpine
+```
+
+With ECI turned on, this command fails unless you've configured Docker socket exceptions for trusted images.
+
+## What users see with enforced ECI
+
+When administrators enforce Enhanced Container Isolation through
+Settings Management:
+
+- The **Use Enhanced Container Isolation** setting appears turned on in
+Docker Desktop settings.
+- If set to `"locked": true`, the setting is locked and greyed out.
+- All new containers automatically use Linux user namespaces.
+- Existing development workflows continue to work without modification.
+- Users see `sysbox-runc` as the container runtime in `docker inspect` output.
+
+## Next steps
+
+- Review [Configure Docker socket exceptions and advanced settings](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md).
+- Review [Enhanced Container Isolation limitations](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/limitations.md).
diff --git a/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/faq.md b/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/faq.md
new file mode 100644
index 000000000000..3dee031d634c
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/faq.md
@@ -0,0 +1,85 @@
+---
+title: Enhanced Container Isolation FAQs
+linkTitle: FAQs
+description: Frequently asked questions about Enhanced Container Isolation
+keywords: enhanced container isolation, faq, troubleshooting, docker desktop
+toc_max: 2
+aliases:
+ - /security/for-admins/hardened-desktop/enhanced-container-isolation/faq/
+weight: 40
+---
+
+{{< summary-bar feature_name="Hardened Docker Desktop" >}}
+
+This page answers common questions about Enhanced Container Isolation (ECI) that aren't covered in the main documentation.
+
+## Do I need to change the way I use Docker when ECI is switched on?
+
+No. ECI works automatically in the background by creating more secure containers. You can continue using all your existing Docker commands, workflows, and development tools without any changes.
+
+## Do all container workloads work well with ECI?
+
+Most container workloads run without issues when ECI is turned on. However, some advanced workloads that require specific kernel-level access may not work. For details about which workloads are affected, see [ECI limitations](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/limitations.md).
+
+## Why not just restrict usage of the `--privileged` flag?
+
+Privileged containers serve legitimate purposes like Docker-in-Docker, Kubernetes-in-Docker, and accessing hardware devices. ECI provides a better solution by allowing these advanced workloads to run securely while preventing them from compromising the Docker Desktop VM.
+
+## Does ECI affect container performance?
+
+ECI has minimal impact on container performance. The only exception is containers that perform many `mount` and `umount` system calls, as these are inspected by the Sysbox runtime for security. Most development workloads see no noticeable performance difference.
+
+## Can I override the container runtime with ECI turned on?
+
+
+No. When ECI is turned on, all containers use the Sysbox runtime regardless of any `--runtime` flags:
+
+```console
+$ docker run --runtime=runc alpine echo "test"
+# This still uses sysbox-runc, not runc
+```
+
+The `--runtime` flag is ignored to prevent users from bypassing ECI security by running containers as true root in the Docker Desktop VM.
+
+## Does ECI protect containers created before turning it on?
+
+No. ECI only protects containers created after it's turned on. Remove existing containers before turning on ECI:
+
+```console
+$ docker stop $(docker ps -q)
+$ docker rm $(docker ps -aq)
+```
+
+For more details, see [Enable Enhanced Container Isolation](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/enable-eci.md).
+
+## Which containers does ECI protect?
+
+ECI protection varies by container type and Docker Desktop version:
+
+### Always protected
+
+- Containers created with `docker run` and `docker create`
+- Containers using the `docker-container` build driver
+- Kubernetes with the Kind provisioner
+
+### Platform dependent
+
+- Docker Build: Protected in Docker Desktop for Mac, Linux, and Windows with Hyper-V backend
+
+### Not protected
+
+- Docker Extensions
+- Docker Debug containers
+- Kubernetes with Kubeadm provisioner
+
+For complete details, see [ECI limitations](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/limitations.md).
+
+## Can I mount the Docker socket with ECI turned on?
+
+By default, no. ECI blocks Docker socket bind mounts for security. However, you can configure exceptions for trusted images like Testcontainers.
+
+For configuration details, see [Configure Docker socket exceptions](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md).
+
+## What bind mounts does ECI restrict?
+
+ECI restricts bind mounts of Docker Desktop VM directories but allows host directory mounts configured in Docker Desktop Settings.
diff --git a/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/limitations.md b/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/limitations.md
new file mode 100644
index 000000000000..e7a2f63736b4
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/limitations.md
@@ -0,0 +1,156 @@
+---
+linkTitle: Limitations
+title: Enhanced Container Isolation limitations
+description: Known limitations and platform-specific considerations for Enhanced Container Isolation
+keywords: enhanced container isolation, limitations, wsl, hyper-v, kubernetes, docker build
+toc_max: 3
+weight: 30
+aliases:
+ - /security/for-admins/hardened-desktop/enhanced-container-isolation/limitations/
+---
+
+{{< summary-bar feature_name="Hardened Docker Desktop" >}}
+
+Enhanced Container Isolation has some platform-specific limitations and feature constraints. Understanding these limitations helps you plan your security strategy and set appropriate expectations.
+
+## WSL 2 security considerations
+
+> [!NOTE]
+>
+> Docker Desktop requires WSL 2 version 2.1.5 or later. ECI on the WSL 2 backend
+> requires WSL version 2.6 or later because ECI depends on a Linux kernel version
+> of at least 6.3.0. Check your version with `wsl --version` and update with
+> `wsl --update` if needed.
+
+Enhanced Container Isolation provides different security levels depending on your Windows backend configuration.
+
+The following table compares ECI on WSL 2 and ECI on Hyper-V:
+
+| Security feature                                   | ECI on WSL   | ECI on Hyper-V   | Comment               |
+| -------------------------------------------------- | ------------ | ---------------- | --------------------- |
+| Strongly secure containers                         | Yes          | Yes              | Makes it harder for malicious container workloads to breach the Docker Desktop Linux VM and host. |
+| Docker Desktop Linux VM protected from user access | No           | Yes              | On WSL, users can access Docker Engine directly or bypass Docker Desktop security settings. |
+| Docker Desktop Linux VM has a dedicated kernel     | No           | Yes              | On WSL, Docker Desktop can't guarantee the integrity of kernel level configs. |
+
+WSL 2 security gaps include:
+
+- Direct VM access: Users can bypass Docker Desktop security by accessing the VM directly: `wsl -d docker-desktop`. This gives users root access to modify Docker Engine settings and bypass
+Settings Management configurations.
+- Shared kernel vulnerability: All WSL 2 distributions share the same Linux kernel instance. Other WSL distributions can modify kernel settings that affect Docker Desktop's security.
+
+### Recommendation
+
+Use Hyper-V backend for maximum security. WSL 2 offers better performance and resource
+utilization, but provides reduced security isolation.
+
+## Windows containers not supported
+
+ECI only works with Linux containers (Docker Desktop's default mode). Native Windows
+containers mode isn't supported.
+
+## Docker Build protection varies
+
+Docker Build protection depends on the driver and Docker Desktop version:
+
+| Build drive | Protection | Version requirements |
+|:------------|:-----------|:---------------------|
+| `docker` (default) | Protected | Docker Desktop 4.30 and later (except WSL 2) |
+| `docker` (legacy) | Not protected | Docker Desktop versions before 4.30 |
+| `docker-container` | Always protected | All Docker Desktop versions |
+
+The following Docker Build features don't work with ECI:
+
+- `docker build --network=host`
+- Docker Buildx entitlements: `network.host`, `security.insecure`
+
+### Recommendation
+
+Use `docker-container` build driver for builds requiring these features:
+
+```console
+$ docker buildx create --driver docker-container --use
+$ docker buildx build --network=host .
+```
+
+## Docker Desktop Kubernetes not protected in Kubeadm mode
+
+The integrated Kubernetes feature, when used with the legacy Kubeadm provisioner, doesn't benefit from ECI protection. Malicious or privileged pods can compromise the Docker Desktop VM and bypass security controls.
+
+### Recommendation
+
+Use the newer Docker Desktop Kubernetes "KinD" provisioner (see [Cluster provisioning method](/manuals/desktop/use-desktop/kubernetes.md#cluster-provisioning-method)). In this mode, and with ECI turned on, each Kubernetes node runs in an ECI-protected container, providing stronger isolation from the Docker Desktop VM. The KinD provisioner is also faster and allows for multi-node Kubernetes clusters.
+
+## Unprotected container types
+
+These container types currently don't benefit from ECI protection:
+
+- Docker Extensions: Extension containers run without ECI protection
+- Kubernetes pods: When using Docker Desktop's integrated Kubernetes with the old Kubeadm provisioner.
+
+### Recommendation
+
+Only use extensions from trusted sources in security-sensitive environments.
+
+## Global command restrictions
+
+Command lists apply to all containers allowed to mount the Docker socket. You can't configure different command restrictions per container image.
+
+## Local-only images not supported
+
+You can't allow arbitrary local-only images (images not in a registry) to mount the Docker socket, unless they're:
+
+- Derived from an allowed base image (with `allowDerivedImages: true`)
+- Using the wildcard allowlist (`"*"`, Docker Desktop 4.36 and later)
+
+## Unsupported Docker commands
+
+These Docker commands aren't yet supported in command list restrictions:
+
+- `compose`: Docker Compose commands
+- `dev`: Development environment commands
+- `extension`: Docker Extensions management
+- `feedback`: Docker feedback submission
+- `init`: Docker initialization commands
+- `manifest`: Image manifest management
+- `plugin`: Plugin management
+- `sbom`: Software Bill of Materials
+- `scout`: Docker Scout commands
+- `trust`: Image trust management
+
+## Performance considerations
+
+### Derived images impact
+
+Enabling `allowDerivedImages: true` adds approximately 1 second to container startup time for image validation.
+
+### Registry dependencies
+
+- Docker Desktop periodically fetches image digests from registries for validation
+- Initial container starts require registry access to validate allowed images
+- Network connectivity issues may cause delays in container startup
+
+### Image digest validation
+
+When allowed images are updated in registries, local containers may be unexpectedly blocked until you refresh the local image:
+
+```console
+$ docker image rm <image>
+$ docker pull <image>
+```
+
+## Production compatibility
+
+### Container behavior differences
+
+Most containers run identically with and without ECI. However, some advanced workloads may behave differently:
+
+- Containers requiring kernel module loading
+- Workloads modifying global kernel settings (BPF, sysctl)
+- Applications expecting specific privilege escalation behavior
+- Tools requiring direct hardware device access
+
+Test advanced workloads with ECI in development environments before production deployment to ensure compatibility.
+
+### Runtime considerations
+
+Containers using the Sysbox runtime (with ECI) may have subtle differences compared to standard OCI runc runtime in production. These differences typically only affect privileged or system-level operations.
diff --git a/content/manuals/enterprise/security/hardened-desktop/image-access-management.md b/content/manuals/enterprise/security/hardened-desktop/image-access-management.md
new file mode 100644
index 000000000000..e77af278b2a3
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/image-access-management.md
@@ -0,0 +1,118 @@
+---
+title: Image Access Management
+description: Control which Docker Hub images developers can access with Image Access Management for enhanced supply chain security
+keywords: image access management, docker official images, verified publisher, supply chain security, docker business, allow list, image restrictions, pull restrictions
+tags: [admin]
+aliases:
+ - /admin/organization/image-access/
+ - /security/for-admins/image-access-management/
+ - /security/for-admins/hardened-desktop/image-access-management/
+weight: 50
+---
+
+{{< summary-bar feature_name="Hardened Docker Desktop" >}}
+
+Image Access Management lets administrators control which types of images developers can pull from Docker Hub. This prevents developers from accidentally using untrusted community images that could pose security risks to your organization.
+
+With Image Access Management, you can restrict access to:
+
+- Docker Official Images: Curated images maintained by Docker
+- Docker Verified Publisher Images: Images from trusted commercial publishers
+- Organization images: Your organization's private repositories
+- Community images: Public images from individual developers
+
+You can also use a repository allowlist to approve specific repositories that bypass all other access controls.
+
+## Who should use Image Access Management?
+
+Image Access Management helps prevent supply chain attacks by ensuring developers only use trusted container images. For example, a developer building a new application might accidentally use a malicious community image as a component. Image Access Management prevents this by restricting access to only approved image types.
+
+Common security scenarios include:
+
+- Prevent use of unmaintained or malicious community images
+- Ensure developers use only vetted, official base images
+- Control access to commercial third-party images
+- Maintain consistent security standards across development teams
+
+Use the repository allowlist when you need to:
+
+- Grant access to specific vetted community images
+- Allow essential third-party tools that don't fall under official categories
+- Provide exceptions to general image access policies for specific business requirements
+
+## Prerequisites
+
+Before configuring Image Access Management, you must:
+
+- [Enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md). Image Access Management only takes effect when users are signed in to Docker Desktop with organization credentials.
+- Use [personal access tokens (PATs)](/manuals/security/access-tokens.md) for authentication (Organization access tokens aren't supported)
+- Have a Docker Business subscription
+
+## Configure image access
+
+> [!NOTE]
+>
+> Image Access Management is turned off by default for organization members. Organization owners always have access to all images regardless of policy settings.
+
+To configure Image Access Management:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization from the top-left account drop-down.
+1. Select **Docker Desktop**, then **Image Access**.
+1. Use the **toggle** to enable image access.
+1. Select which image types to allow:
+    - **Organization images**: Images from your organization (always allowed by default). These can be public or private images created by members within your organization.
+    - **Community images**: Images contributed by various users that may pose security risks. This category includes Docker-Sponsored Open Source images and is turned off by default.
+    - **Docker Verified Publisher Images**: Images from Docker partners in the Verified Publisher program, qualified for secure supply chains.
+    - **Docker Official Images**: Curated Docker repositories that provide OS repositories, best practices for Dockerfiles, drop-in solutions, and timely security updates.
+    - **Repository allowlist**: A list of specific repositories that should be
+      allowed. Configure in the next step.
+1. If **Repository allowlist** is enabled in the previous step,
+   you can add or remove specific repositories in the allow list:
+    - To add repositories, in the **Repository allowlist** section, select
+      **Add repositories to allowlist** and follow the on-screen instructions.
+    - To remove a repository, in the **Repository allowlist** section, select
+      the trashcan icon next to it.
+
+    Repositories in the allow list are accessible to all organization members regardless of the image type restrictions configured in the previous steps.
+
+After restrictions are applied, organization members can view the permissions page in read-only format.
+
+## Verify access restrictions
+
+After configuring Image Access Management, test that restrictions work correctly.
+
+When developers pull allowed image types:
+
+```console
+$ docker pull nginx  # Docker Official Image
+# Pull succeeds if Docker Official Images are allowed
+```
+
+When developers pull blocked image types:
+
+```console
+$ docker pull someuser/custom-image  # Community image
+Error response from daemon: image access denied: community images not allowed
+```
+
+Image access restrictions apply to all Docker Hub operations including pulls, builds using `FROM` instructions, and Docker Compose services.
+
+## Best practices
+
+- Start with the most restrictive policy and gradually expand based on legitimate business needs:
+   1. Start with Docker Official Images and Organization images
+   2. If needed, add Docker Verified Publisher Images for commercial tools
+   3. Carefully evaluate community images only for specific, vetted use cases
+   4. Use the repository allowlist sparingly. Only add repositories that have been thoroughly vetted and approved through your organization's security review process
+- Monitor usage patterns: Review which images developers are attempting to pull, identify legitimate requests for additional image types, regularly audit approved image categories for continued relevance, and use Docker Desktop analytics to monitor usage patterns.
+- Regularly review the repository allow list: Periodically audit the repositories in your allowlist to ensure they remain necessary and trustworthy, and remove any that are no longer needed or maintained.
+
+## Scope and bypass considerations
+
+- Image Access Management only controls access to Docker Hub images. Images from other registries aren't affected by these policies. Use [Registry Access Management](/manuals/enterprise/security/hardened-desktop/registry-access-management.md) to control access to other registries.
+- Users can potentially bypass Image Access Management by signing out of Docker Desktop (unless sign-in is enforced), using images from other registries that aren't restricted, or using registry mirrors or proxies. Enforce sign-in and combine with Registry Access Management for comprehensive control.
+- Image restrictions apply to Dockerfile `FROM` instructions, Docker Compose services using restricted images will fail, multi-stage builds may be affected if intermediate images are restricted, and CI/CD pipelines using diverse image types may be impacted.
+
+## Next steps
+
+- Layer security controls: Image Access Management works best with [Registry Access Management](registry-access-management.md) to control which registries developers can access, [Enhanced Container Isolation](enhanced-container-isolation/_index.md) to secure containers at runtime, and [Settings Management](settings-management/_index.md) to control Docker Desktop configuration.
\ No newline at end of file
diff --git a/content/manuals/enterprise/security/hardened-desktop/namespace-access.md b/content/manuals/enterprise/security/hardened-desktop/namespace-access.md
new file mode 100644
index 000000000000..14c81e03fe51
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/namespace-access.md
@@ -0,0 +1,53 @@
+---
+title: Namespace access control
+linkTitle: Namespace access
+description: Control whether organization members can push content to their personal namespaces on Docker Hub
+keywords: namespace access, docker hub, personal namespace, organization security, docker business
+tags: [admin]
+weight: 60
+---
+
+{{< summary-bar feature_name="Namespace access" >}}
+
+Namespace access control lets organization administrators control whether all
+members of an organization can push content to their personal namespaces on
+Docker Hub. This prevents organizations from accidentally publishing images
+outside of approved, governed locations.
+
+When namespace access control is enabled, organization members can still view and pull images
+from their personal namespaces and continue accessing all existing repositories
+and content. However, they're unable to create new repositories or
+push new images to their personal namespace.
+
+> [!IMPORTANT]
+>
+> For users in multiple organizations, if namespace access control is enabled in
+> any organization, that user cannot push to their personal namespace and cannot
+> create new repositories in their personal namespace.
+
+### Configure namespace access control
+
+To configure namespace access control:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your
+   organization from the top-left account drop-down.
+2. Select **Docker Desktop**, then **Namespace access**.
+3. Use the toggle to enable or disable namespace access control.
+4. Select **Save changes**.
+
+Once namespace access control is enabled, organization members can still view their
+personal namespace and existing repositories but they are not able to create
+any new repositories or push any new images to existing repositories.
+
+### Verify access restrictions
+
+After configuring namespace access control, test that restrictions work correctly.
+
+After any attempt to push to an existing repository in your personal namespace,
+you'll see an error message like the following:
+
+```console
+$ docker push <personal-namespace>/<image>:<tag>
+Unavailable
+authentication required - namespace access restriction from an organization you belong to prevents pushing new content in your personal namespace. Restriction applied by: <organizations>. Please contact your organization administrator
+```
\ No newline at end of file
diff --git a/content/manuals/enterprise/security/hardened-desktop/registry-access-management.md b/content/manuals/enterprise/security/hardened-desktop/registry-access-management.md
new file mode 100644
index 000000000000..c4bd8e2dd60e
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/registry-access-management.md
@@ -0,0 +1,168 @@
+---
+title: Registry Access Management
+linkTitle: Registry Access Management
+description: Control which container registries developers can access through
+  Docker Desktop with Registry Access Management.
+keywords: registry access management, RAM, container registry allowlist, Docker
+  Desktop security, Docker Business, admin controls, DNS filtering, registry
+  permissions, hardened desktop
+tags: [admin]
+aliases:
+  - /admin/organization/registry-access/
+  - /security/for-admins/registry-access-management/
+  - /security/for-admins/hardened-desktop/registry-access-management/
+  - /docker-hub/registry-access-management/
+weight: 40
+---
+
+{{< summary-bar feature_name="Registry access management" >}}
+
+Registry Access Management (RAM) lets administrators control which container
+registries developers can access through Docker Desktop. This DNS-level
+filtering limits pulls and pushes to approved registries.
+
+RAM works with cloud registries, on-premises registries, and registry mirrors.
+You can allow any hostname or domain, but you must also include redirect
+domains (for example, `s3.amazonaws.com` for some registries) in your
+allowlist.
+
+## Supported registries
+
+Registry Access Management works with any container registry, including:
+
+- Docker Hub (allowed by default)
+- Cloud registries: Amazon ECR, Google Artifact Registry, Azure Container
+  Registry
+- Git-based registries: GitHub Container Registry, GitLab Container Registry
+- On-premises solutions: Nexus, Artifactory, Harbor
+- Registry mirrors: Including Docker Hub mirrors
+
+## Prerequisites
+
+Before configuring Registry Access Management, you must:
+
+- [Enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md).
+  Registry Access Management only takes effect when users are signed in to
+  Docker Desktop with organization credentials.
+- Use
+  [Organization access tokens (OATs)](/manuals/enterprise/security/access-tokens.md)
+  for authentication
+- Have a Docker Business subscription
+
+## Configure registry permissions
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+   organization from the top-left account drop-down.
+1. Select **Docker Desktop**, then **Registry Access**.
+1. Use the toggle to turn on registry access. By default, Docker Hub is
+   enabled in the registry list.
+1. To add registries, select **Add registry** and provide a **Registry
+   address** and **Registry nickname**.
+1. Select **Create**. You can add up to 100 registries.
+1. Verify your registry appears in the registry list and select **Save
+   changes**.
+
+> [!NOTE]
+>
+> Policy changes can take up to 24 hours to propagate. To apply changes
+> immediately, ask developers to sign out and back in to Docker Desktop.
+
+If a developer belongs to multiple organizations with different RAM policies,
+only the policy for the first organization in the configuration file is
+enforced.
+
+> [!TIP]
+>
+> RAM restrictions also apply to Dockerfile `ADD` instructions that fetch
+> content by URL. Include trusted registry domains in your allowlist when
+> using `ADD` with URLs.
+>
+> RAM is designed for container registries, not general-purpose URLs such as
+> package mirrors or storage services. Adding too many domains may cause
+> errors or hit system limits.
+
+## Verify restrictions are working
+
+After users sign in to Docker Desktop with their organization credentials,
+Registry Access Management takes effect immediately.
+
+When users try to pull from a blocked registry:
+
+```console
+$ docker pull blocked-registry.com/image:tag
+Error response from daemon: registry access to blocked-registry.com is not allowed
+```
+
+Allowed registry access works normally:
+
+```console
+$ docker pull allowed-registry.com/image:tag
+# Pull succeeds
+```
+
+Registry restrictions apply to all Docker operations including pulls, pushes,
+and builds that reference external registries.
+
+## Registry limits and platform constraints
+
+Registry Access Management has these limits and platform-specific behaviors:
+
+- Maximum allowlist size: 100 registries or domains per organization
+- DNS-based filtering: Restrictions work at the hostname level, not IP
+  addresses
+- Redirect domains required: Include all domains a registry redirects to (CDN
+  endpoints, storage services)
+- Windows containers: Windows image operations aren't restricted by default.
+  Turn on **Use proxy for Windows Docker daemon** in Docker Desktop settings
+  to apply restrictions
+- WSL 2 requirements: Requires Linux kernel 5.4 or later. Restrictions apply
+  to all WSL 2 distributions
+
+## Build and deployment restrictions
+
+These scenarios aren't restricted by Registry Access Management:
+
+- Docker buildx with the Kubernetes driver
+- Docker buildx with a custom Docker-container driver
+- Some Docker Debug and Kubernetes image pulls (even if Docker Hub is blocked)
+- Images previously cached by registry mirrors may still be blocked if the
+  source registry is restricted
+
+## Security bypass considerations
+
+Users can potentially bypass Registry Access Management through:
+
+- Local proxies or DNS manipulation
+- Signing out of Docker Desktop (unless sign-in is enforced)
+- Network-level modifications outside Docker Desktop's control
+
+To maximize security effectiveness:
+
+- [Enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) to
+  prevent bypass through sign-out
+- Implement additional network-level controls for complete protection
+- Use Registry Access Management as part of a broader security strategy
+
+## Registry allowlist best practices
+
+- Include all registry domains. Some registries redirect to multiple domains.
+  For AWS ECR, include:
+
+  ```text
+  your-account.dkr.ecr.us-west-2.amazonaws.com
+  amazonaws.com
+  s3.amazonaws.com
+  ```
+
+- Maintain the allowlist regularly:
+  - Remove unused registries periodically
+  - Add newly approved registries as needed
+  - Update domain names that may have changed
+  - Monitor registry usage through Docker Desktop analytics
+- Test configuration changes:
+  - Verify registry access after allowlist updates
+  - Confirm all necessary redirect domains are included
+  - Ensure development workflows aren't disrupted
+- Combine with
+  [Enhanced Container Isolation](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md)
+  for broader Desktop security
\ No newline at end of file
diff --git a/content/manuals/enterprise/security/hardened-desktop/settings-management/_index.md b/content/manuals/enterprise/security/hardened-desktop/settings-management/_index.md
new file mode 100644
index 000000000000..86915d861306
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/settings-management/_index.md
@@ -0,0 +1,119 @@
+---
+description: Understand how Settings Management works, who it's for, and the benefits it provides
+keywords: Settings Management, rootless, docker desktop, hardened desktop, admin control, enterprise
+tags: [admin]
+title: Settings Management
+linkTitle: Settings Management
+aliases:
+  - /security/for-admins/hardened-desktop/settings-management/
+weight: 10
+---
+
+{{< summary-bar feature_name="Hardened Docker Desktop" >}}
+
+Settings Management lets administrators configure and enforce Docker Desktop settings across end-user machines. It helps maintain consistent configurations and enhances security within your organization.
+
+## Who should use Settings Management?
+
+Settings Management is designed for organizations that:
+
+- Need centralized control over Docker Desktop configurations
+- Want to standardize Docker Desktop environments across teams
+- Operate in regulated environments and must enforce compliance policies
+
+## How Settings Management works
+
+Administrators can define settings using one of these methods:
+
+- [Docker Home](/manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console.md): Create and assign settings policies via Docker Home. This provides a web-based interface for managing settings
+  across your organization.
+- [`admin-settings.json` file](/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md): Place a configuration file on the
+  user's machine to enforce settings. This method works well for automated
+  deployments and scripted installations.
+
+Enforced settings override user-defined configurations and can't be modified by developers.
+
+## Configurable settings
+
+Settings Management supports a wide range of Docker Desktop features, including:
+
+- Proxy configurations
+- Network settings
+- Container isolation options
+- Registry access controls
+- Resource limits
+- Security policies
+- Cloud policies
+
+For a complete list of settings you can enforce, see the [Settings reference](/manuals/enterprise/security/hardened-desktop/settings-management/settings-reference.md).
+
+## Policy precedence
+
+When multiple policies exist, Docker Desktop applies them in this order:
+
+1. User-specific policies: Highest priority
+1. Organization default policy: Applied when no user-specific policy exists
+1. Local `admin-settings.json` file: Lowest priority, overridden by Docker Home policies
+1. [Configuration profiles](/manuals/enterprise/security/enforce-sign-in/methods.md#configuration-profiles-method-mac-only) when used to control proxy settings
+
+## Set up Settings Management
+
+You can create settings management policies at any time, but your organization needs to verify a domain before the policies take effect.
+
+1. Check that you have [added and verified](/manuals/enterprise/security/domain-management.md#add-and-verify-a-domain) your organization's domain.
+2. [Enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) to
+   ensure all developers authenticate with your organization.
+3. Choose a configuration method:
+   - Use the `--admin-settings` installer flag on [macOS](/manuals/desktop/setup/install/mac-install.md#install-from-the-command-line) or [Windows](/manuals/desktop/setup/install/windows-install.md#install-from-the-command-line) to automatically create the `admin-settings.json`.
+   - Manually create and configure the [`admin-settings.json` file](/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md).
+   - Create a settings policy in the [Docker Home](configure-admin-console.md).
+
+After configuration, developers receive the enforced settings when they:
+
+- Quit and relaunch Docker Desktop, then sign in
+- Launch and sign in to Docker Desktop for the first time
+
+> [!NOTE]
+>
+> Docker Desktop doesn't automatically prompt users to restart or re-authenticate after a settings change. You may need to communicate these requirements to your developers.
+
+## Developer experience
+
+When settings are enforced:
+
+- Settings options appear grayed out in Docker Desktop and can't be modified through the Dashboard, CLI, or configuration files
+- If Enhanced Container Isolation is enabled, developers can't use privileged containers or similar methods to alter enforced settings within the Docker Desktop Linux VM
+
+This ensures consistent environments while maintaining a clear visual indication of which settings are managed by administrators.
+
+## View applied settings
+
+When administrators apply Settings Management policies, Docker Desktop greys out most enforced settings in the GUI.
+
+The Docker Desktop GUI doesn't currently display all centralized settings,
+particularly Enhanced Container Isolation (ECI) settings that administrators
+apply via Docker Home.
+
+As a workaround, you can check the `settings-store.json` file to view all
+applied settings:
+
+- Mac: `~/Library/Application Support/Docker/settings-store.json`
+- Windows: `%APPDATA%\Docker\settings-store.json`
+- Linux: `~/.docker/desktop/settings-store.json`
+
+The `settings-store.json` file contains all settings, including those that
+may not appear in the Docker Desktop GUI.
+
+## Limitations
+
+Settings Management has the following limitations:
+
+- Doesn't work in air-gapped or offline environments
+- Not compatible with environments that restrict authentication with Docker Hub
+
+## Next steps
+
+Get started with Settings Management:
+
+- [Configure Settings Management with the `admin-settings.json` file](configure-json-file.md)
+- [Configure Settings Management with Docker Home](configure-admin-console.md)
diff --git a/content/manuals/enterprise/security/hardened-desktop/settings-management/compliance-reporting.md b/content/manuals/enterprise/security/hardened-desktop/settings-management/compliance-reporting.md
new file mode 100644
index 000000000000..95bba780115c
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/settings-management/compliance-reporting.md
@@ -0,0 +1,121 @@
+---
+title: Desktop settings reporting
+linkTitle: Desktop settings reporting
+description: Track and monitor user compliance with Docker Desktop settings policies using the reporting dashboard
+keywords: settings management, compliance reporting, docker home, policy enforcement, docker desktop
+weight: 30
+aliases:
+ - /security/for-admins/hardened-desktop/settings-management/compliance-reporting/
+---
+
+{{< summary-bar feature_name="Compliance reporting" >}}
+
+Desktop settings reporting tracks user compliance with Docker Desktop settings policies. Use this feature to monitor policy application across your organization and identify users who need assistance with compliance.
+
+## Prerequisites
+
+Before you can use Docker Desktop settings reporting, make sure you have:
+
+- [Docker Desktop](/manuals/desktop/release-notes.md) installed across your organization
+- [A verified domain](/manuals/enterprise/security/single-sign-on/connect.md)
+- [Enforced sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) for your organization
+- A Docker Business subscription
+- At least one settings policy configured
+
+## Access the reporting dashboard
+
+To view compliance reporting:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select
+your organization.
+1. Select **Docker Desktop**, then **Settings Reporting**.
+
+The reporting dashboard provides these tools:
+
+- A search field to find users by username or email address
+- Filter options to show users assigned to specific policies
+- Toggles to hide or un-hide compliant users
+- Compliance status indicators
+- CSV export option to download compliance data
+
+## User compliance statuses
+
+Docker Desktop evaluates three types of status to determine overall compliance:
+
+### Compliance status
+
+This is the primary status shown in the dashboard:
+
+| Compliance status | What it means |
+|-------------------|---------------|
+| Compliant | The user fetched and applied the latest assigned policy. |
+| Non-compliant | The user fetched the correct policy, but hasn't applied it. |
+| Outdated | The user fetched a previous version of the policy. |
+| No policy assigned | The user does not have any policy assigned to them. |
+| Uncontrolled domain | The user's email domain is not verified. |
+
+### Domain status
+
+Shows how the user's email domain relates to your organization:
+
+| Domain status | What it means |
+|---------------|---------------|
+| Verified | The user’s email domain is verified. |
+| Guest user | The user's email domain is not verified. |
+| Domainless | Your organization has no verified domains, and the user's domain is unknown. |
+
+### Settings status
+
+Indicates the user's policy assignment:
+
+| Settings status | What it means |
+|-----------------|---------------|
+| Global policy | The user is assigned your organization's default policy. |
+| User policy | The user is assigned a specific custom policy. |
+| No policy assigned | The user is not assigned to any policy. |
+
+## Monitor compliance
+
+From the **Desktop settings reporting** dashboard, you can:
+
+- Review organization-wide compliance at a glance
+- Turn on **Hide compliant users** to focus on issues
+- Filter by specific policies to check targeted compliance
+- Export compliance data
+- Select any user's name for detailed status and resolution steps
+
+When you select a user's name, you'll see their detailed compliance information including current status, domain verification, assigned policy, last policy fetch time, and Docker Desktop version.
+
+## Resolve compliance issues
+
+You can select a non-compliant user's name in the dashboard for recommended status resolution steps. The following sections are general resolution steps for non-compliant statuses:
+
+### Non-compliant or outdated users
+
+- Ask the user to fully quit and relaunch Docker Desktop
+- Verify the user is signed in to Docker Desktop
+- Confirm the user has Docker Desktop 4.40 or later
+
+### Uncontrolled domain users
+
+- Verify the user's email domain in your organization settings
+- If the domain should be controlled, add and verify it, then wait for verification
+- If the user is a guest and shouldn't be controlled, no action is needed
+
+### No policy assigned users
+
+- Assign the user to an existing policy
+- Create a new user-specific policy for them
+- Verify they're included in your organization's default policy scope
+
+After users take corrective action, refresh the reporting dashboard to verify status changes.
+
+## Policy update timing
+
+Docker Desktop checks for policy updates:
+
+- At startup
+- Every 60 minutes while Docker Desktop is running
+- When users restart Docker Desktop
+
+Changes to policies in Docker Home are available immediately, but users must restart Docker Desktop to apply them.
diff --git a/content/manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console.md b/content/manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console.md
new file mode 100644
index 000000000000..e787818cd0ab
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console.md
@@ -0,0 +1,112 @@
+---
+title: Configure Settings Management in Docker Home
+linkTitle: Use Docker Home
+description: Configure and enforce Docker Desktop settings across your organization in Docker Home
+keywords: docker home, settings management, policy configuration, enterprise controls, docker desktop
+weight: 20
+aliases:
+  - /security/for-admins/hardened-desktop/settings-management/configure-admin-console/
+---
+
+{{< summary-bar feature_name="Admin Console" >}}
+
+Use Docker Home to create and manage settings policies for Docker Desktop across your organization. Settings policies let you standardize configurations, enforce security requirements, and maintain consistent Docker Desktop environments.
+
+## Prerequisites
+
+Before you begin, make sure you have:
+
+- [Docker Desktop](/manuals/desktop/release-notes.md) installed
+- [A verified domain](/enterprise/security/single-sign-on/connect/#step-1-add-a-domain)
+- [Enforced sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) for your organization
+- A Docker Business subscription
+
+> [!IMPORTANT]
+>
+> You can create settings management policies at any time, but your organization needs to verify a domain before the policies take effect.
+
+## Create a settings policy
+
+To create a new settings policy:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select
+   your organization.
+1. Select **Docker Desktop**, then **Settings Management**.
+1. Select **Create a settings policy**.
+1. Provide a name and optional description.
+
+   > [!TIP]
+   >
+   > You can upload an existing `admin-settings.json` file to pre-fill the form.
+   > Docker Home policies override local `admin-settings.json` files.
+
+1. Choose who the policy applies to:
+   - All users
+   - Specific users
+
+     > [!NOTE]
+     >
+     > User-specific policies override global default policies. Test your policy with a small group before applying it organization-wide.
+
+1. Configure each setting using a state:
+
+     | Docker Home state | Description                        | `admin-settings.json` equivalent   |
+     | :------------------ | :--------------------------------- |:---------------------------------- |
+     | **User-defined**    | Users can change the setting       | Omit the setting                   |
+     | **Always enabled**  | Setting is on and locked           | `"value": true`, `"locked": true`  |
+     | **Enabled**         | Setting is on but can be changed   | `"value": true`, `"locked": false` |
+     | **Always disabled** | Setting is off and locked          | `"value": false`, `"locked": true` |
+     | **Disabled**        | Setting is off but can be changed  | `"value": false`, `"locked": false`|
+
+     > [!TIP]
+     >
+     > For a complete list of configurable settings, supported platforms, and configuration methods, see the [Settings reference](settings-reference.md).
+
+1. Select **Create** to save your policy.
+
+## Apply the policy
+
+Settings policies take effect after Docker Desktop restarts and users sign in.
+
+For new installations:
+
+1. Launch Docker Desktop.
+1. Sign in with your Docker account.
+
+For existing installations:
+
+1. Quit Docker Desktop completely.
+1. Relaunch Docker Desktop.
+
+> [!IMPORTANT]
+>
+> Users must fully quit and reopen Docker Desktop. Restarting from the Docker Desktop menu isn't sufficient.
+
+Docker Desktop checks for policy updates when it launches and every 60 minutes while running.
+
+## Verify applied settings
+
+After you apply policies:
+
+- Docker Desktop displays most settings as greyed out
+- Some settings, particularly Enhanced Container Isolation configurations,
+  may not appear in the GUI
+- You can verify all applied settings by checking the [`settings-store.json`
+  file](/manuals/desktop/settings-and-maintenance/settings.md) on your system
+
+## Manage existing policies
+
+From the **Desktop Settings Management** page in Docker Home, use the **Actions** menu to:
+
+- Edit or delete an existing settings policy
+- Export a settings policy as an `admin-settings.json` file
+- Promote a user-specific policy to be the new global default
+
+## Roll back policies
+
+To roll back a settings policy:
+
+- Complete rollback: Delete the entire policy.
+- Partial rollback: Set specific settings to **User-defined**.
+
+When you roll back settings, users regain control over those settings configurations.
diff --git a/content/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md b/content/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md
new file mode 100644
index 000000000000..8426e587b7ee
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/settings-management/configure-json-file.md
@@ -0,0 +1,419 @@
+---
+title: Configure Settings Management with a JSON file
+linkTitle: Use a JSON file
+description: Configure and enforce Docker Desktop settings using an admin-settings.json file
+keywords: admin controls, settings management, configuration, enterprise, docker desktop, json file
+weight: 10
+aliases:
+  - /security/for-admins/hardened-desktop/settings-management/configure/
+  - /security/for-admins/hardened-desktop/settings-management/configure-json-file/
+---
+
+{{< summary-bar feature_name="Hardened Docker Desktop" >}}
+
+Settings Management lets you configure and enforce Docker Desktop settings across your organization using an `admin-settings.json` file. This standardizes Docker Desktop environments and ensures consistent configurations for all users.
+
+## Prerequisites
+
+Before you begin, make sure you have:
+
+- [Enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) for
+  your organization
+- A Docker Business subscription
+
+The presence of the `admin-settings.json` file enforces sign-in on Docker Desktop. This is intended for business features that require authentication.
+
+Users must be signed in and part of a Docker Business organization. If either condition isn't met, the settings file is ignored.
+
+## Step one: Create the settings file
+
+You can create the `admin-settings.json` file in two ways:
+
+- Use the `--admin-settings` installer flag to auto-generate the file:
+  - [Mac](/manuals/desktop/setup/install/mac-install.md#install-from-the-command-line) installation guide
+  - [Windows](/manuals/desktop/setup/install/windows-install.md#install-from-the-command-line) installation guide
+- Create it manually (UTF-8 without BOM) and place it in the following locations:
+  - Mac: `/Library/Application Support/com.docker.docker/admin-settings.json`
+  - Windows: `C:\ProgramData\DockerDesktop\admin-settings.json`
+  - Linux: `/usr/share/docker-desktop/admin-settings.json`
+
+> [!IMPORTANT]
+>
+> Place the file in a protected directory to prevent unauthorized changes. Use Mobile Device Management (MDM) tools like Jamf to distribute the file at scale across your organization.
+
+## Step two: Configure settings
+
+> [!TIP]
+>
+> For a complete list of available settings, their supported platforms, and which configuration methods they work with, see the [Settings reference](settings-reference.md).
+
+The `admin-settings.json` file uses structured keys to define configurable settings and whether values are enforced.
+
+Each setting supports a `locked` field that controls user permissions:
+
+- When `locked` is set to `true`, users can't change that value in Docker Desktop, the CLI, or config files.
+- When `locked` is set to `false`, the value acts like a default suggestion and users
+  can still update it.
+
+Settings where `locked` is set to `false` are ignored on existing installs if
+a user has already customized that value in `settings-store.json`,
+`settings.json`, or `daemon.json`.
+
+### Grouped settings
+
+Docker Desktop groups some settings together with a single toggle that controls
+the entire section. These include:
+
+- Enhanced Container Isolation (ECI): Uses a main toggle (`enhancedContainerIsolation`) that enables/disables the entire feature, with sub-settings for specific configurations
+- Kubernetes: Uses a main toggle (`kubernetes.enabled`) with sub-settings for cluster configuration
+- Docker Scout: Groups settings under the `scout` object
+
+When configuring grouped settings:
+
+1. Set the main toggle to enable the feature
+1. Configure sub-settings within that group
+1. When you lock the main toggle, users cannot modify any settings in that group
+
+Example for `enhancedContainerIsolation`:
+
+```json
+"enhancedContainerIsolation": {
+  "locked": true,  // This locks the entire ECI section
+  "value": true,   // This enables ECI
+  "dockerSocketMount": {  // These are sub-settings
+    "imageList": {
+      "images": ["docker.io/testcontainers/ryuk:*"]
+    }
+  }
+}
+```
+
+### Example `admin-settings.json` file
+
+The following sample is an `admin-settings.json` file with common enterprise settings configured. You can use this example as a template with the [`admin-settings.json` configurations](#admin-settingsjson-configurations):
+
+```json {collapse=true}
+{
+  "configurationFileVersion": 2,
+  "exposeDockerAPIOnTCP2375": {
+    "locked": true,
+    "value": false
+  },
+  "proxy": {
+    "locked": true,
+    "mode": "system",
+    "http": "",
+    "https": "",
+    "exclude": [],
+    "windowsDockerdPort": 65000,
+    "enableKerberosNtlm": false,
+    "pac": "",
+    "embeddedPac": ""
+  },
+  "containersProxy": {
+    "locked": true,
+    "mode": "manual",
+    "http": "",
+    "https": "",
+    "exclude": [],
+    "pac": "",
+    "embeddedPac": "",
+    "transparentPorts": ""
+  },
+  "enhancedContainerIsolation": {
+    "locked": true,
+    "value": true,
+    "dockerSocketMount": {
+      "imageList": {
+        "images": [
+          "docker.io/localstack/localstack:*",
+          "docker.io/testcontainers/ryuk:*"
+        ]
+      },
+      "commandList": {
+        "type": "deny",
+        "commands": ["push"]
+      }
+    }
+  },
+  "linuxVM": {
+    "wslEngineEnabled": {
+      "locked": false,
+      "value": false
+    },
+    "dockerDaemonOptions": {
+      "locked": false,
+      "value": "{\"debug\": false}"
+    },
+    "vpnkitCIDR": {
+      "locked": false,
+      "value": "192.168.65.0/24"
+    }
+  },
+  "kubernetes": {
+    "locked": false,
+    "enabled": false,
+    "showSystemContainers": false,
+    "imagesRepository": ""
+  },
+  "windowsContainers": {
+    "dockerDaemonOptions": {
+      "locked": false,
+      "value": "{\"debug\": false}"
+    }
+  },
+  "disableUpdate": {
+    "locked": false,
+    "value": false
+  },
+  "analyticsEnabled": {
+    "locked": false,
+    "value": true
+  },
+  "extensionsEnabled": {
+    "locked": true,
+    "value": false
+  },
+  "scout": {
+    "locked": false,
+    "sbomIndexing": true,
+    "useBackgroundIndexing": true
+  },
+  "allowBetaFeatures": {
+    "locked": false,
+    "value": false
+  },
+  "blockDockerLoad": {
+    "locked": false,
+    "value": true
+  },
+  "filesharingAllowedDirectories": [
+    {
+      "path": "$HOME",
+      "sharedByDefault": true
+    },
+    {
+      "path": "$TMP",
+      "sharedByDefault": false
+    }
+  ],
+  "useVirtualizationFrameworkVirtioFS": {
+    "locked": true,
+    "value": true
+  },
+  "useVirtualizationFrameworkRosetta": {
+    "locked": true,
+    "value": true
+  },
+  "useGrpcfuse": {
+    "locked": true,
+    "value": true
+  },
+  "displayedOnboarding": {
+    "locked": true,
+    "value": true
+  },
+  "desktopTerminalEnabled": {
+    "locked": false,
+    "value": false
+  },
+  "enableInference": {
+    "locked": false,
+    "value": true
+  },
+  "enableInferenceTCP": {
+    "locked": false,
+    "value": true
+  },
+  "enableInferenceTCPPort": {
+    "locked": true,
+    "value": 12434
+  },
+  "enableInferenceCORS": {
+    "locked": true,
+    "value": ""
+  },
+  "enableInferenceGPUVariant": {
+    "locked": true,
+    "value": true
+  },
+  "portBindingBehavior": {
+    "locked": true,
+    "value": "default-port-binding"
+  }
+}
+```
+
+## Step three: Apply the settings
+
+Settings take effect after Docker Desktop restarts and the user signs in.
+
+For new installations:
+
+1. Launch Docker Desktop.
+1. Sign in with your Docker account.
+
+For existing installations:
+
+1. Quit Docker Desktop completely.
+1. Relaunch Docker Desktop.
+
+> [!IMPORTANT]
+>
+> You must fully quit and reopen Docker Desktop. Restarting from the menu isn't sufficient.
+
+## `admin-settings.json` configurations
+
+The following tables describe all available settings in the `admin-settings.json` file.
+
+> [!NOTE]
+>
+> Some settings are platform-specific or require minimum Docker Desktop versions. Check the Version column for requirements.
+
+### General settings
+
+| Parameter                  | OS           | Description                                                                                                                                                                                                      | Version                                |
+| :------------------------- | ------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
+| `configurationFileVersion` |              | Specifies the version of the configuration file format.                                                                                                                                                          |                                        |
+| `analyticsEnabled`         |              | If `value` is set to false, Docker Desktop doesn't send usage statistics to Docker.                                                                                                                              |                                        |
+| `disableUpdate`            |              | If `value` is set to true, checking for and notifications about Docker Desktop updates is disabled.                                                                                                              |                                        |
+| `blockDockerLoad`          |              | If `value` is set to `true`, users are no longer able to run [`docker load`](/reference/cli/docker/image/load/) and receive an error if they try to.                                                             |                                        |
+| `displayedOnboarding`      |              | If `value` is set to `true`, the onboarding survey will not be displayed to new users. Setting `value` to `false` has no effect.                                                                                 |  |
+| `desktopTerminalEnabled`   |              | If `value` is set to `false`, developers cannot use the Docker terminal to interact with the host machine and execute commands directly from Docker Desktop.                                                     |                                        |
+| `exposeDockerAPIOnTCP2375` | Windows only | Exposes the Docker API on a specified port. If `value` is set to true, the Docker API is exposed on port 2375. Note: This is unauthenticated and should only be enabled if protected by suitable firewall rules. |                                        |
+| `silentModulesUpdate`      |              | If `value` is set to `true`, Docker Desktop automatically updates components that don't require a restart. For example, the Docker CLI or Docker Scout components.                                               | |
+
+### Extensions
+
+| Parameter                                     | OS  | Description                                                                                                                                                                                                    | Version |
+| :-------------------------------------------- | --- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
+| `extensionsEnabled`                           |     | If `value` is set to false, Docker Extensions are disabled.                                                                                                                                                    |         |
+| `onlyMarketplaceExtensions`                   |     | If `value` is set to true, developers are blocked from installing other extensions via the command line.                                                                                                       |         |
+| `extensionsPrivateMarketplace`                |     | If `value` is set to true, activates the private marketplace is enabled which ensures Docker Desktop connects to content defined and controlled by the administrator instead of the public Docker marketplace. |         |
+| `extensionsPrivateMarketplaceAdminContactURL` |     | Defines a contact link for developers to request new extensions in the private marketplace.                                                                                                                    |         |
+
+### File sharing and emulation
+
+| Parameter                            | OS         | Description                                                                                                                                                                                                                                                                                                                                               | Version                                |
+| :----------------------------------- | ---------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
+| `filesharingAllowedDirectories`      |            | Specify which paths your developers can add file shares to. Also accepts `$HOME`, `$TMP`, or `$TEMP` as `path` variables. When a path is added, its subdirectories are allowed. If `sharedByDefault` is set to `true`, that path will be added upon factory reset or when Docker Desktop first starts.                                                    |                                        |
+| `useVirtualizationFrameworkVirtioFS` | macOS only | If `value` is set to `true`, VirtioFS is set as the file sharing mechanism. Note: If both `useVirtualizationFrameworkVirtioFS` and `useGrpcfuse` have `value` set to `true`, VirtioFS takes precedence. If both are set to `false`, Docker Desktop fails to start with an error, as at least one file sharing mechanism must be enabled. |                                        |
+| `useGrpcfuse`                        | macOS only | If `value` is set to `true`, gRPC Fuse is set as the file sharing mechanism.                                                                                                                                                                                                                                                                              |                                        |
+| `useVirtualizationFrameworkRosetta`  | macOS only | If `value` is set to `true`, Docker Desktop turns on Rosetta to accelerate x86_64/amd64 binary emulation on Apple Silicon. Note: This also automatically enables `Use Virtualization framework`.                                                                                                                                                          |  |
+
+### Docker Scout
+
+| Parameter | OS  | Description                                                                                                                                                                                                                                                            | Version |
+| :-------- | --- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
+| `scout`   |     | Setting `useBackgroundIndexing` to `false` disables automatic indexing of images loaded to the image store. Setting `sbomIndexing` to `false` prevents users from being able to index image by inspecting them in Docker Desktop or using `docker scout` CLI commands. |         |
+
+### Proxy settings
+
+Docker Desktop has two distinct proxy settings with different scopes:
+
+- `proxy` (App Proxy): Governs Docker Desktop host-level traffic — the Desktop application, Docker CLI, and extensions. It also serves as a fallback for the daemon when `containersProxy` is not explicitly configured. Once `containersProxy` is set, `proxy` plays no role in daemon or container traffic.
+- [`containersProxy`](#container-proxy): Always governs `docker image pull`. All `docker image pull` and Compose pull operations go through `containersProxy`, including any PAC file rules. It also governs running container outbound traffic when `transparentPorts` is configured.
+
+| Parameter            | OS           | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                             | Version                                |
+| :------------------- | ------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
+| `proxy`              |              | If `mode` is set to `system` instead of `manual`, Docker Desktop gets the proxy values from the system and ignores any values set for `http`, `https` and `exclude`. Change `mode` to `manual` to manually configure proxy servers. If the proxy port is custom, specify it in the `http` or `https` property, for example `"https": "http://myotherproxy.com:4321"`. The `exclude` property specifies a comma-separated list of hosts and domains to bypass the proxy. |                                        |
+| `windowsDockerdPort` | Windows only | Exposes Docker Desktop's internal proxy locally on this port for the Windows Docker daemon to connect to. If it is set to 0, a random free port is chosen. If the value is greater than 0, use that exact value for the port. The default value is -1 which disables the option.                                                                                                                                                                                        |                                        |
+| `enableKerberosNtlm` |              | When set to `true`, Kerberos and NTLM authentication is enabled. Default is `false`. For more information, see the settings documentation.                                                                                                                                                                                                                                                                                                                              | |
+| `pac`                |              | Specifies a PAC file URL. For example, `"pac": "http://proxy/proxy.pac"`.                                                                                                                                                                                                                                                                                                                                                                                               |                                        |
+| `embeddedPac`        |              | Specifies an embedded PAC (Proxy Auto-config) script. For example, `"embeddedPac": "function FindProxyForURL(url, host) { return \"DIRECT\"; }"`. This setting takes precedence over HTTP, HTTPS, Proxy bypass and PAC server URL.                                                                                                                                                                                                                                      |  |
+
+> [!NOTE]
+>
+> Proxy configuration is a special case because it must be configured in two places:
+>
+> 1. In Docker Home for your organization.
+> 2. On the user's system where Docker Desktop is installed.
+>
+> On the user's machine, configure the proxy either through the `admin-settings.json` file or by using installer flags during Docker Desktop installation. For detailed instructions, refer to the [installation guide](/manuals/desktop/setup/install/windows-install.md#proxy-configuration).
+> 
+> This additional configuration is required because Docker Desktop must know which proxy server to use before it can complete user sign-in and retrieve organization settings from Docker Home.
+
+### Container proxy
+
+| Parameter         | OS  | Description                                                                                                                                                                                                                                         | Version                                |
+| :---------------- | --- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
+| `containersProxy` |     | Configures the proxy for `docker image pull` (always enforced) and running container outbound traffic (enforced when `transparentPorts` is set). For more information see [Air-Gapped Containers](../air-gapped-containers.md). |  |
+| `pac`             |     | Specifies a PAC file URL. For example, `"pac": "http://containerproxy/proxy.pac"`.                                                                                                                                                                  |                                        |
+| `embeddedPac`     |     | Specifies an embedded PAC (Proxy Auto-config) script. For example, `"embeddedPac": "function FindProxyForURL(url, host) { return \"PROXY 192.168.92.1:2003\"; }"`. This setting takes precedence over HTTP, HTTPS, Proxy bypass and PAC server URL. |  |
+
+### Linux VM settings
+
+| Parameter                                        | OS           | Description                                                                                                                                                                                                                                                                                                | Version |
+| :----------------------------------------------- | ------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
+| `linuxVM`                                        |              | Parameters and settings related to Linux VM options - grouped together here for convenience.                                                                                                                                                                                                               |         |
+| &nbsp; &nbsp; &nbsp; &nbsp;`wslEngineEnabled`    | Windows only | If `value` is set to true, Docker Desktop uses the WSL 2 based engine. This overrides anything that may have been set at installation using the `--backend=<backend name>` flag.                                                                                                                           |         |
+| &nbsp; &nbsp; &nbsp; &nbsp;`dockerDaemonOptions` |              | If `value` is set to true, it overrides the options in the Docker Engine config file. See the [Docker Engine reference](/reference/cli/dockerd.md#daemon-configuration-file). Note that for added security, a few of the config attributes may be overridden when Enhanced Container Isolation is enabled. |         |
+| &nbsp; &nbsp; &nbsp; &nbsp;`vpnkitCIDR`          |              | Overrides the network range used for vpnkit DHCP/DNS for `*.docker.internal`                                                                                                                                                                                                                               |         |
+
+### Windows containers
+
+| Parameter                                        | OS  | Description                                                                                                                                    | Version |
+| :----------------------------------------------- | --- | :--------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
+| `windowsContainers`                              |     | Parameters and settings related to `windowsContainers` options - grouped together here for convenience.                                        |         |
+| &nbsp; &nbsp; &nbsp; &nbsp;`dockerDaemonOptions` |     | Overrides the options in the Linux daemon config file. See the [Docker Engine reference](/reference/cli/dockerd.md#daemon-configuration-file). |         |
+
+> [!NOTE]
+>
+> This setting is not available to configure via Docker Home.
+
+### Kubernetes settings
+
+| Parameter    | OS  | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | Version |
+| :----------- | --- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
+| `kubernetes` |     | If `enabled` is set to true, a Kubernetes single-node cluster is started when Docker Desktop starts. If `showSystemContainers` is set to true, Kubernetes containers are displayed in the Docker Desktop Dashboard and when you run `docker ps`. The [imagesRepository](/manuals/desktop/use-desktop/kubernetes.md#configuring-a-custom-image-registry-for-kubernetes-control-plane-images) setting lets you specify which repository Docker Desktop pulls control-plane Kubernetes images from. |         |
+
+> [!NOTE]
+>
+> When using `imagesRepository` with Enhanced Container Isolation (ECI), add these images to the [ECI Docker socket mount image list](#enhanced-container-isolation):
+>
+> `[imagesRepository]/desktop-cloud-provider-kind:`
+> `[imagesRepository]/desktop-containerd-registry-mirror:`
+>
+> These containers mount the Docker socket, so you must add them to the ECI images list. Otherwise, ECI blocks the mount and Kubernetes won't start.
+
+### Networking settings
+
+| Parameter               | OS                          | Description                                                                                                                                                                                                                 | Version                                |
+| :---------------------- | --------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
+| `defaultNetworkingMode` | Windows and Mac only        | Defines the default IP protocol for new Docker networks: `dual-stack` (IPv4 + IPv6, default), `ipv4only`, or `ipv6only`.                                                                                                    | |
+| `dnsInhibition`         | Windows and Mac only        | Controls DNS record filtering returned to containers. Options: `auto` (recommended), `ipv4`, `ipv6`, `none`                                                                                                                 | |
+| `portBindingBehavior`   | Linux-based containers only | Defines port binding restrictions and default behavior, allowing admins to control how a user exposes ports from their containers. Options: `default-port-binding`, `default-local-port-binding`, `local-only-port-binding` | Docker Desktop version 4.52 and later. |
+
+For more information, see [Networking](/manuals/desktop/features/networking.md#networking-mode-and-dns-behaviour-for-mac-and-windows).
+
+### AI settings
+
+| Parameter                   | OS           | Description                                                                                                                                                                                                                        | Version |
+| :-------------------------- | ------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
+| `enableInference`           |              | Setting `enableInference` to `true` enables [Docker Model Runner](/manuals/ai/model-runner/_index.md).                                                                                                                             |         |
+| `enableInferenceTCP`        |              | Enable host-side TCP support. This setting requires the Docker Model Runner setting to be enabled first.                                                                                                                           |         |
+| `enableInferenceTCPPort`    |              | Specifies the exposed TCP port. This setting requires the Docker Model Runner and Enable host-side TCP support settings to be enabled first.                                                                                       |         |
+| `enableInferenceCORS`       |              | Specifies the allowed CORS origins. Empty string to deny all,`*` to accept all, or a list of comma-separated values. This setting requires the Docker Model Runner and Enable host-side TCP support settings to be enabled first.  |         |
+| `enableInferenceGPUVariant` | Windows only | Setting `enableInferenceGPUVariant` to `true` enables GPU-backed inference. The additional components required for this don't come by default with Docker Desktop, therefore they will be downloaded to `~/.docker/bin/inference`. |         |
+
+### Beta features
+
+> [!IMPORTANT]
+>
+> For Docker Desktop versions 4.41 and earlier, some of these settings lived under the **Experimental features** tab on the **Features in development** page.
+
+| Parameter                   | OS  | Description                                                                                                                                                                                                                                               | Version                                 |
+| :-------------------------- | --- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- |
+| `allowBetaFeatures`         |     | If `value` is set to `true`, beta features are enabled.                                                                                                                                                                                                   |                                         |
+| `enableDockerAI`            |     | If `allowBetaFeatures` is true, setting `enableDockerAI` to `true` enables [Gordon](/manuals/ai/gordon/_index.md) by default. You can independently control this setting from the `allowBetaFeatures` setting.                                            |                                         |
+| `enableDockerMCPToolkit`    |     | If `allowBetaFeatures` is true, setting `enableDockerMCPToolkit` to `true` enables the [MCP Toolkit feature](/manuals/ai/mcp-catalog-and-toolkit/toolkit.md) by default. You can independently control this setting from the `allowBetaFeatures` setting. |                                         |
+| `allowExperimentalFeatures` |     | If `value` is set to `true`, experimental features are enabled.                                                                                                                                                                                           |  |
+
+### Enhanced Container Isolation
+
+| Parameter                                                      | OS  | Description                                                                                                                                                                                                                                                                                                                                               | Version |
+| :------------------------------------------------------------- | --- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
+| `enhancedContainerIsolation`                                   |     | If `value` is set to true, Docker Desktop runs all containers as unprivileged, via the Linux user-namespace, prevents them from modifying sensitive configurations inside the Docker Desktop VM, and uses other advanced techniques to isolate them. For more information, see [Enhanced Container Isolation](../enhanced-container-isolation/_index.md). |         |
+| &nbsp; &nbsp; &nbsp; &nbsp;`dockerSocketMount`                 |     | By default, enhanced container isolation blocks bind-mounting the Docker Engine socket into containers (e.g., `docker run -v /var/run/docker.sock:/var/run/docker.sock ...`). This lets you relax this in a controlled way. See [ECI Configuration](../enhanced-container-isolation/config.md) for more info.                                             |         |
+| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; `imageList`   |     | Indicates which container images are allowed to bind-mount the Docker Engine socket.                                                                                                                                                                                                                                                                      |         |
+| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; `commandList` |     | Restricts the commands that containers can issue via the bind-mounted Docker Engine socket.                                                                                                                                                                                                                                                               |         |
diff --git a/content/manuals/enterprise/security/hardened-desktop/settings-management/settings-reference.md b/content/manuals/enterprise/security/hardened-desktop/settings-management/settings-reference.md
new file mode 100644
index 000000000000..80b254341fcc
--- /dev/null
+++ b/content/manuals/enterprise/security/hardened-desktop/settings-management/settings-reference.md
@@ -0,0 +1,695 @@
+---
+title: Settings reference
+linkTitle: Settings reference
+description: Complete reference for all Docker Desktop settings and configuration options
+keywords: docker desktop settings, configuration reference, admin controls, settings management
+toc_max: 2
+aliases:
+ - /security/for-admins/hardened-desktop/settings-management/settings-reference/
+---
+
+This reference documents Docker Desktop settings that administrators can configure using [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md). Use this page to understand which settings are available, their accepted values, platform compatibility, and which configuration methods apply.
+ 
+> [!NOTE]
+>
+> This page only covers configurable settings for administrators who are deploying Docker Desktop to their organization. For the full list of Docker Desktop user-facing settings, see [Change settings](/manuals/desktop/settings-and-maintenance/settings.md).
+
+## General
+
+### Send usage statistics
+
+Controls whether Docker Desktop collects and sends local usage statistics and crash reports to Docker. Does not affect server-side telemetry collected via Docker Hub or other backend services such
+as sign in timestamps, pulls, or builds.
+
+| Property | Value |
+|---|---|
+| Default | `true` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `analyticsEnabled` |
+| Docker Home | **Send usage statistics** |
+
+> [!NOTE]
+>
+> Organizations using the Insights Dashboard may need this setting enabled to
+ensure that developer activity is fully visible. If users opt out and the
+setting is not locked, their activity may be excluded from analytics
+views.
+
+### Automatically check for updates
+
+Controls whether Docker Desktop checks for and notifies users about available updates. When set to `true`, update checks and notifications are disabled.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `disableUpdate` |
+| Docker Home | **Disable update** |
+
+> [!NOTE]
+>
+> In hardened environments, enable this setting and lock it. This guarantees that
+only internally vetted versions are installed.
+
+### Automatically update components
+
+Allows Docker Desktop to automatically update components that do not require a restart, such as Docker Compose, Docker Scout, and the Docker CLI.
+
+| Property | Value |
+|---|---|
+| Default | `true` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `silentModulesUpdate` |
+| Docker Home | **Automatically update components** |
+
+### Enable Gordon
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values (individuals) | `true`, `false` |
+| Accepted values (Business tier) | `"Disabled"`, `"Enabled"`, `"Always Enabled"` |
+| JSON key | `enableDockerAI` |
+| Docker Home | **Enable Gordon** |
+
+> [!IMPORTANT]
+>
+> Docker Business customers must set this to `"Enabled"` or `"Always Enabled"` in Docker Home. Setting to `"User Defined"` alone will not activate Gordon.
+
+### Block `docker load`
+
+Prevents users from loading local Docker images using the `docker load` command, enforcing image provenance by requiring all images to come from registries.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `blockDockerLoad` |
+| Docker Home | **Block Docker Load** |
+
+> [!NOTE]
+>
+> In hardened environments, enable and lock this setting. This forces all images
+to come from your secure, scanned registry.
+
+### Hide onboarding survey
+
+Prevents the onboarding survey from being shown to new users.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `displayedOnboarding` |
+| Docker Home | **Hide onboarding survey** |
+
+### Enable Docker terminal
+
+Allows or restricts access to the built-in terminal for host system interaction. When set to `false`, users cannot use the Docker terminal to interact with the host machine or execute commands directly from Docker Desktop.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| Docker Desktop GUI | **General** tab |
+| JSON key | `desktopTerminalEnabled` |
+| Docker Home | Not available |
+
+### Expose Docker API on TCP 2375 {{< badge color=blue text="Windows only" >}}
+
+Exposes the Docker API over an unauthenticated TCP socket on port 2375. Only recommended for isolated and protected environments. Supports legacy integrations that require TCP API access.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `exposeDockerAPIOnTCP2375` |
+| Docker Home | **Expose Docker API** |
+
+> [!NOTE]
+>
+> In hardened environments, disable and lock this setting. This ensures the
+Docker API is only reachable via the secure internal socket.
+
+## Extensions 
+
+### Enable Docker extensions
+
+Controls whether users can install and run Docker Extensions.
+
+| Property | Value |
+|---|---|
+| Default | `true` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `extensionsEnabled` |
+| Docker Home | **Allow Extensions** |
+
+> [!NOTE]
+>
+> In hardened environments, disable and lock this setting. This prevents
+third-party or unverified plugins from being installed.
+
+### Allow only extensions distributed through the Docker Marketplace
+
+Prevents installation of third-party or locally developed extensions.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `onlyMarketplaceExtensions` |
+| Docker Home | **Only marketplace extensions** |
+
+### Enable a private marketplace
+
+Ensures Docker Desktop connects to content defined and controlled by the administrator instead of the public Docker Marketplace.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `extensionsPrivateMarketplace` |
+| Docker Home | **Extensions private marketplace** |
+
+## AI
+
+### Enable Docker Model Runner
+
+Enables Docker Model Runner functionality for running AI models in containers.
+
+| Property | Value |
+|---|---|
+| Default | `true` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `enableInference` |
+| Docker Home | **Enable Docker Model Runner** |
+
+#### Enable host-side TCP support
+
+Enables TCP connectivity for Docker Model Runner services, allowing external applications to connect to Model Runner via TCP.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `enableInferenceTCP` |
+| Docker Home | **Host-side TCP support** |
+| Requires | Docker Model Runner enabled |
+
+##### Port
+
+Specifies the port used for Model Runner TCP connections.
+
+| Property | Value |
+|---|---|
+| Default | `12434` |
+| Accepted values | Integer |
+| Format | Integer |
+| JSON key | `enableInferenceTCPPort` |
+| Docker Home | **Host-side TCP port** |
+| Requires | Docker Model Runner and host-side TCP support enabled |
+
+##### CORS Allowed Origins 
+
+Controls cross-origin resource sharing for Model Runner web integration.
+
+| Property | Value |
+|---|---|
+| Default | Empty string |
+| Accepted values | Empty string (deny all), `*` (accept all), or comma-separated list of origins |
+| Format | String |
+| JSON key | `enableInferenceCORS` |
+| Docker Home | **CORS Allowed Origins** |
+| Requires | Docker Model Runner and host-side TCP support enabled |
+
+### Enable GPU-backed inference {{< badge color=blue text="Windows only" >}}
+
+Enables GPU-backed inference. Additional components will be downloaded to `~/.docker/bin/inference`.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `enableInferenceGPUVariant` |
+| Docker Home | **Enable GPU-backed inference** |
+
+## File sharing and emulation 
+
+### File sharing directories 
+
+Defines which host directories containers can access for development workflows.
+
+| Property | Value |
+|---|---|
+| Default | Varies by OS |
+| Accepted values | List of file paths |
+| Format | Array of strings |
+| JSON key | `filesharingAllowedDirectories` |
+| Docker Home | Yes — **Allowed file sharing directories** |
+
+### VirtioFS {{< badge color=blue text="Mac only" >}}
+
+Uses VirtioFS for fast, native file sharing between host and containers. If both VirtioFS and gRPC FUSE are set to `true`, VirtioFS takes precedence.
+
+| Property | Value |
+|---|---|
+| Default | `true` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `useVirtualizationFrameworkVirtioFS` |
+| Docker Home | **Use VirtioFS for file sharing** tab |
+
+### gRPC FUSE {{< badge color=blue text="Mac only" >}}
+
+Enables gRPC FUSE for macOS file sharing.
+
+| Property | Value |
+|---|---|
+| Default | `true` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `useGrpcfuse` |
+| Docker Home | **Use gRPC FUSE for file sharing** |
+
+### Rosetta {{< badge color=blue text="Mac only" >}}
+
+Uses Rosetta for x86_64/amd64 emulation on Apple Silicon.
+
+| Property | Value |
+|---|---|
+| Default | `true` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `useVirtualizationFrameworkRosetta` |
+| Docker Home | **Use Rosetta for x86_64/amd64 emulation on Apple Silicon** |
+
+## Scout
+
+### Enable Scout image analysis
+
+Turns on vulnerability scanning and software bill of materials (SBOM) analysis for container images.
+
+| Property | Value |
+|---|---|
+| Default | `true` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `sbomIndexing` |
+| Docker Home | **SBOM indexing** |
+
+### Enable background Scout SBOM indexing 
+
+Keeps image metadata current by indexing during idle time or after image operations.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `useBackgroundIndexing` |
+| Docker Home | **Background indexing** |
+
+## Proxy
+
+> [!NOTE]
+>
+> Proxy configuration is a special case because it must be configured in two places:
+>
+> 1. In the Docker Home for your organization.
+> 2. On the user's system where Docker Desktop is installed.
+>
+> On the user's machine, configure the proxy either through the `admin-settings.json` file or by using installer flags during Docker Desktop installation. For detailed instructions, refer to the [installation guide](/manuals/desktop/setup/install/windows-install.md#proxy-configuration).
+> 
+> This additional configuration is required because Docker Desktop must know which proxy server to use before it can complete user sign-in and retrieve organization settings from the Docker Home.
+
+### Embedded PAC script 
+
+Specifies an embedded Proxy Auto-Config (PAC) script. For example: `"embeddedPac": "function FindProxyForURL(url, host) { return \"DIRECT\"; }"`.
+
+| Property | Value |
+|---|---|
+| Default | `""` |
+| Accepted values | Embedded PAC script content |
+| Format | String |
+| JSON key | `embeddedPac` |
+| Docker Home | Yes **Embedded PAC script** |
+
+### PAC file URL 
+
+Specifies a PAC file URL for Docker Desktop to use when routing network traffic. For example: `"pac": "http://proxy/proxy.pac"`.
+
+| Property | Value |
+|---|---|
+| Default | `""` |
+| Accepted values | PAC file URL |
+| Format | String |
+| JSON key | `pac` |
+| Docker Home | **PAC file** |
+
+### Override Windows "dockerd" port {{< badge color=blue text="Windows only" >}}
+
+Exposes Docker Desktop's internal proxy locally on this port for the Windows Docker daemon to connect to. If it is set to 0, a random free port is chosen. If the value is greater than 0, use that exact value for the port.
+
+| Property | Value |
+|---|---|
+| Default | `-1` |
+| Accepted values | `-1` `0` |
+| Format | String |
+| JSON key | `windowsDockerdPort` |
+| Docker Home | **Override Windows “dockerd” port** |
+
+### Enable Kerberos and NTLM authentication 
+
+Enables enterprise proxy authentication support for Kerberos and NTLM protocols.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `proxy.enableKerberosNtlm` |
+| Docker Home | **Kerberos NTLM** |
+
+### Proxy bypass
+
+Defines network addresses that containers should bypass when using proxy settings.
+
+| Property | Value |
+|---|---|
+| Default | `""` |
+| Accepted values | List of addresses |
+| Format | String |
+| Docker Desktop GUI | **Proxies** tab |
+| JSON key | `proxy` (with `manual` and `exclude` modes) |
+| Docker Home | Yes — **Proxy** section |
+
+## Containers proxy
+
+### Air-gapped container proxy
+
+Configures an HTTP/HTTPS proxy that governs two distinct traffic paths:
+
+- Daemon image pulls (always enforced): Docker Desktop always injects `http.docker.internal:3128` as the daemon's proxy in `daemon.json` at VM startup. All `docker pull` and Compose pull operations are routed through `containersProxy`, including any PAC file rules. This applies regardless of whether `transparentPorts` is configured.
+- Running container outbound traffic (opt-in): Container TCP traffic is only subject to `containersProxy` rules when `transparentPorts` is configured. Without it, running containers connect directly and PAC file rules do not apply to their outbound traffic.
+
+> [!IMPORTANT]
+>
+> If you configure a PAC file under `containersProxy`, the PAC file must return an appropriate proxy server to connect to the registries where your images are hosted.
+
+The [`proxy`](#proxy) setting governs Docker Desktop host-level traffic: the Desktop application, Docker CLI, and extensions. It serves as a fallback for the daemon only when `containersProxy` is not explicitly configured. Once `containersProxy` is set, `proxy` plays no role in daemon or container traffic.
+
+| Property | Value |
+|---|---|
+| Default | See example below |
+| Accepted values | JSON object |
+| Format | JSON object |
+| JSON key | `containersProxy` |
+| Docker Home | **Containers proxy** section |
+
+```json
+"containersProxy": {
+  "locked": true,
+  "mode": "manual",
+  "http": "",
+  "https": "",
+  "exclude": [],
+  "pac": "",
+  "transparentPorts": ""
+}
+```
+
+For more information, see [Air-gapped containers](/manuals/enterprise/security/hardened-desktop/air-gapped-containers.md).
+
+## LinuxVM
+
+### Enable WSL engine {{< badge color=blue text="Windows only" >}}
+
+When set to `true`, Docker Desktop uses the WSL 2 based engine. Overrides any backend flag set at installation using `--backend=<backend name>`.
+
+| Property | Value |
+|---|---|
+| Default | `true` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `wslEngineEnabled` |
+| Docker Home | **Windows Subsystem for Linux (WSL) Engine** |
+
+### Docker daemon options 
+
+Overrides the Docker daemon configuration used in containers, without modifying local configuration files.
+
+| Property | Value |
+|---|---|
+| Default | `{}` |
+| Accepted values | JSON object |
+| Format | Stringified JSON |
+| JSON key | `linuxVM.dockerDaemonOptions` |
+| Docker Home | **Docker Daemon options** in the LinuxVM dropdown |
+
+### VPNKit CIDR {{< badge color=blue text="Mac only" >}}
+
+Sets the network subnet used for Docker Desktop's internal VPNKit DHCP/DNS services. Prevents IP address conflicts in environments with overlapping network subnets.
+
+| Property | Value |
+|---|---|
+| Default | `192.168.65.0/24` |
+| Accepted values | CIDR notation |
+| Format | String |
+| JSON key | `vpnkitCIDR` |
+| Docker Home | **VPNKit CIDR** |
+
+## Windows containers
+
+### Docker daemon options 
+
+Overrides the Docker daemon configuration used in Windows containers, without modifying local configuration files.
+
+| Property | Value |
+|---|---|
+| Default | `{}` |
+| Accepted values | JSON object |
+| Format | Stringified JSON |
+| JSON key | `windowsContainers.dockerDaemonOptions` |
+| Docker Home | **Docker Daemon options** in the **Windows containers dropdown** |
+
+## Kubernetes
+
+### Enable Kubernetes
+
+Enables the local Kubernetes cluster integration with Docker Desktop.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `kubernetes` |
+| Docker Home | **Enable Kubernetes** |
+
+### Show system containers
+
+Controls visibility of Kubernetes system containers in the Docker Desktop Dashboard.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| Docker Home | **Show system containers** |
+
+### Kubernetes image repository 
+
+Specifies a registry used for Kubernetes control plane images instead of Docker Hub. Overrides the `[registry[:port]/][namespace]` portion of image names. Images must be mirrored from Docker Hub with matching tags.
+
+| Property | Value |
+|---|---|
+| Default | `""` |
+| Accepted values | Registry URL |
+| Format | String |
+| JSON key | `KubernetesImagesRepository` |
+| Docker Home | **Kubernetes Images Repository** |
+
+> [!NOTE]
+>
+> Images must be mirrored from Docker Hub with matching tags. Required images depend on the cluster provisioning method.
+
+> [!IMPORTANT]
+>
+> When using custom image repositories with Enhanced Container Isolation, add these images to the ECI allowlist: `[imagesRepository]/desktop-cloud-provider-kind:*` and `[imagesRepository]/desktop-containerd-registry-mirror:*`.
+
+### Cluster provisioning method 
+
+Controls Kubernetes cluster topology and node configuration.
+
+| Property | Value |
+|---|---|
+| Default | `kubeadm` |
+| Accepted values | `kubeadm`, `kind` |
+| Format | String |
+| Docker Home | **Kubernetes mode** |
+
+### Node version
+
+Pins the Kubernetes version used for cluster nodes.
+
+| Property | Value |
+|---|---|
+| Default | `1.31.1` |
+| Accepted values | Semantic version (e.g. `1.29.1`) |
+| Format | String |
+| Docker Home | **Node version** tab |
+
+### Nodes count
+
+Sets the number of nodes in multi-node Kubernetes clusters.
+
+| Property | Value |
+|---|---|
+| Default | `1` |
+| Accepted values | Integer |
+| Format | Integer |
+| Docker Home | **Nodes count** |
+
+## Features in development
+
+### Access beta features
+
+Controls whether users can access all Docker Desktop features that are in public beta.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `allowBetaFeatures` |
+| Docker Home | **Access beta features** |
+
+### Enable Docker MCP Toolkit (Beta)
+
+Enables [Docker MCP Toolkit](/manuals/ai/mcp-catalog-and-toolkit/_index.md) in Docker Desktop for AI model development workflows.
+
+| Property | Value |
+|---|---|
+| Default | `true` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `enableDockerMCPToolkit` |
+| Docker Home | Not available |
+
+## Enhance container isolation
+
+### Enable Enhanced Container Isolation 
+
+Prevents containers from modifying Docker Desktop VM configuration or accessing sensitive host areas.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `enhancedContainerIsolation` |
+| Docker Home | **Enable enhanced container isolation** |
+
+### Docker socket access control (ECI exceptions)
+
+Defines specific images and commands allowed to use the Docker socket when Enhanced Container Isolation is active. Supports tools like Testcontainers, LocalStack, or CI systems that need Docker socket access while maintaining security.
+
+| Property | Value |
+|---|---|
+| Accepted values | JSON object |
+| Format | JSON object |
+| JSON key | ``dockerSocketMount` |
+| Docker Home | **Image list**, **Command list** |
+
+```json
+"enhancedContainerIsolation": {
+  "locked": true,
+  "value": true,
+  "dockerSocketMount": {
+    "imageList": {
+      "images": [
+        "docker.io/localstack/localstack:*",
+        "docker.io/testcontainers/ryuk:*"
+      ]
+    },
+    "commandList": {
+      "type": "deny",
+      "commands": ["push"]
+    }
+  }
+}
+```
+
+## Network
+
+### Networking mode 
+
+Sets the default IP protocol used when Docker creates new networks.
+
+| Property | Value |
+|---|---|
+| Default | `dual-stack` |
+| Accepted values | `ipv4only`, `ipv6only` |
+| Format | String |
+| JSON key | `defaultNetworkingMode` |
+| Docker Home | **Default network IP mode** |
+
+For more information, see [Networking](/manuals/desktop/features/networking.md#networking-mode-and-dns-behaviour-for-mac-and-windows).
+
+### Inhibit DNS resolution for IPv4/IPv6 
+
+Filters unsupported DNS record types to improve reliability in environments where only IPv4 or IPv6 is supported. Requires Docker Desktop 4.43 and later.
+
+| Property | Value |
+|---|---|
+| Default | `auto` |
+| Accepted values | `ipv4`, `ipv6`, `none` |
+| Format | String |
+| JSON key | `dnsInhibition` |
+| Docker Home | **DNS filtering behavior** |
+
+For more information, see [Networking](/manuals/desktop/features/networking.md#networking-mode-and-dns-behaviour-for-mac-and-windows).
+
+### Port binding behavior
+
+Specify how port bindings are handled for new containers.
+
+| Property | Value |
+|---|---|
+| Default | `default-port-binding` |
+| Accepted values | `default-local-port-binding`, `local-only-port-binding`, `default-port-binding` |
+| Format | String |
+| JSON key | `portBindingBehavior` |
+| Docker Home | **Port binding behavior** |
+
+## Other
+
+### Enable Docker Offload 
+
+Controls Docker Offload availability. When enabled, users see the Docker Offload toggle in the Docker Desktop header.
+
+| Property | Value |
+|---|---|
+| Default | `false` |
+| Accepted values | `true`, `false` |
+| Format | Boolean |
+| JSON key | `enableCloud` |
+| Docker Home | **Enable Docker Offload** |
+
+> [!NOTE]
+>
+> This setting is only available when Docker Offload capability is enabled for
+> the organization.
diff --git a/content/manuals/security/images/jit-disabled-flow.svg b/content/manuals/enterprise/security/images/jit-disabled-flow.svg
similarity index 100%
rename from content/manuals/security/images/jit-disabled-flow.svg
rename to content/manuals/enterprise/security/images/jit-disabled-flow.svg
diff --git a/content/manuals/security/images/jit-enabled-flow.svg b/content/manuals/enterprise/security/images/jit-enabled-flow.svg
similarity index 100%
rename from content/manuals/security/images/jit-enabled-flow.svg
rename to content/manuals/enterprise/security/images/jit-enabled-flow.svg
diff --git a/content/manuals/enterprise/security/oidc-connections/_index.md b/content/manuals/enterprise/security/oidc-connections/_index.md
new file mode 100644
index 000000000000..72d19efd3019
--- /dev/null
+++ b/content/manuals/enterprise/security/oidc-connections/_index.md
@@ -0,0 +1,52 @@
+---
+title: OIDC connections overview
+linkTitle: OIDC connections
+description: Authenticate GitHub Actions to Docker with short-lived OpenID Connect tokens
+keywords: oidc connections, openid connect, github actions, jwt, subject claims, rulesets, enterprise security, workload authentication
+tags: [admin]
+weight: 35
+---
+
+{{< summary-bar feature_name="OIDC connections" >}}
+
+OIDC connections create a trust relationship between Docker and a trusted
+third party so you don't have to maintain long-lived credentials. When you
+create an OIDC connection, Docker exchanges short-lived tokens with another
+vendor that can grant fine-grained access to your Docker resources.
+
+## How OIDC connections work
+
+OIDC connections follow the OpenID Connect (OIDC) standard. Establishing a
+trust relationship involves creating the connection, configuring a
+workflow, and testing. For example, a trust relationship between Docker and
+GitHub follows these steps:
+
+- GitHub issues a JWT ID token for the workflow run.
+- During authentication, Docker:
+  - Verifies the token against GitHub's public key registry
+  - Matches subject claims against rulesets created in
+    [Docker Home](https://app.docker.com/)
+- Docker returns an access token so the GitHub Action can sign in to Docker
+  and access resources.
+
+All tokens created and exchanged during an OIDC workflow are short-lived
+and issued on a per-workflow basis.
+
+## OIDC connections and OATs
+
+[Organization access tokens (OATs)](/manuals/enterprise/security/access-tokens.md)
+provide programmatic access to your Docker resources at the organization
+level. Unlike personal access tokens, OATs aren't tied to individual
+members, so access continues when membership changes.
+
+OIDC connections don't replace OATs. OIDC connections authenticate a
+workflow as if it were a user, then authorize access after authentication.
+
+While OATs govern access to your Docker resources through organization
+membership, OIDC connections authenticate GitHub Actions workflows when
+they request a change to your Docker resources.
+
+## Next steps
+
+- [Create an OIDC connection](/manuals/enterprise/security/oidc-connections/create-manage.md)
+- [OIDC rulesets and subject claims](/manuals/enterprise/security/oidc-connections/rulesets-claims.md)
diff --git a/content/manuals/enterprise/security/oidc-connections/create-manage.md b/content/manuals/enterprise/security/oidc-connections/create-manage.md
new file mode 100644
index 000000000000..f87c9823e604
--- /dev/null
+++ b/content/manuals/enterprise/security/oidc-connections/create-manage.md
@@ -0,0 +1,93 @@
+---
+title: Create and manage OIDC connections
+linkTitle: Create and manage connections
+description: Create and manage OIDC connections in Docker Home, then authenticate GitHub Actions to Docker Hub with docker/login-action and short-lived tokens
+keywords: oidc connections, create oidc connection, github actions, docker/login-action, DOCKERHUB_OIDC_CONNECTIONID, openid connect, docker hub, enterprise security, admin
+tags: [admin]
+weight: 10
+---
+
+{{< summary-bar feature_name="OIDC connections" >}}
+
+Organization owners and editors create and manage OIDC connections from
+**OIDC connections** in Docker Home. After you create a connection,
+configure your GitHub Actions workflow so it can sign in to Docker Hub
+with a short-lived token.
+
+> [!NOTE]
+> OIDC connections support only GitHub as a trusted third party.
+
+## Create an OIDC connection
+
+1. Sign in to [Docker Home](https://app.docker.com/), select your
+   organization, then go to **Identity & auth**.
+1. Select **OIDC connections**.
+1. Select **Create OIDC connection** and fill in the OIDC connection form.
+   - Provide rulesets and subject claims. Other values are optional.
+   - For rulesets, subject claims, and resources, see
+     [OIDC connections rulesets and subject claims](/manuals/enterprise/security/oidc-connections/rulesets-claims.md).
+1. Select **Create connection**.
+1. Copy your OIDC connection ID.
+
+## Configure a GitHub Actions workflow
+
+Use `docker/login-action` version 4.5.0 or later. The action exchanges
+the GitHub OIDC token and signs in to Docker Hub in a single step.
+
+1. Add the following to your workflow YAML. Replace `<YOUR_ORG_NAME>`
+   with your Docker organization name and `<YOUR_CONNECTION_ID>` with
+   the ID you copied from Docker Home:
+
+   ```yaml
+   permissions:
+     contents: read
+     id-token: write
+
+   jobs:
+     build:
+       runs-on: ubuntu-latest
+       steps:
+         - name: Docker login
+           uses: docker/login-action@v4 # v4.5.0+
+           with:
+             username: <YOUR_ORG_NAME>
+           env:
+             DOCKERHUB_OIDC_CONNECTIONID: <YOUR_CONNECTION_ID>
+   ```
+
+   The `username` value must be a Docker organization name. Only
+   organization accounts can sign in using OIDC.
+
+1. Run the workflow and confirm it can sign in to Docker.
+
+## Manage OIDC connections
+
+You can view, edit, deactivate, or delete connections from the **OIDC
+connections** page.
+
+1. Select **Identity & auth**, then **OIDC connections**.
+1. Find the row with your target connection ID.
+1. Select the action menu icon for your options.
+   - **Edit** opens the **Edit OIDC connection** page where you can copy
+     your connection ID, update rulesets, or view the **Failures** table.
+   - **Deactivate** temporarily disables access to your GitHub workflow.
+   - **Activate** restores access to your GitHub workflow.
+   - **Delete** permanently deletes a connection.
+
+## Deactivate or delete a connection
+
+Deactivate an OIDC connection to pause GitHub workflow access to your
+Docker resources without deleting the connection. A deactivated
+connection does not issue Docker access tokens, so `docker/login-action`
+fails at the token-exchange step until you activate the connection.
+
+> [!WARNING]
+> Deleting an OIDC connection is permanent. Any workflow that still sets
+> `DOCKERHUB_OIDC_CONNECTIONID` to the deleted ID fails at the
+> token-exchange step. Update that environment variable with a
+> replacement connection ID in every affected workflow before it runs
+> again.
+
+## Next steps
+
+- [OIDC connections rulesets and subject claims](/manuals/enterprise/security/oidc-connections/rulesets-claims.md)
diff --git a/content/manuals/enterprise/security/oidc-connections/rulesets-claims.md b/content/manuals/enterprise/security/oidc-connections/rulesets-claims.md
new file mode 100644
index 000000000000..6e14e038bc48
--- /dev/null
+++ b/content/manuals/enterprise/security/oidc-connections/rulesets-claims.md
@@ -0,0 +1,95 @@
+---
+title: OIDC connections rulesets and subject claims
+linkTitle: Rulesets and subject claims
+description: Configure rulesets and subject claims to control OIDC workflow access
+keywords: oidc connections, rulesets, subject claims, github actions, jwt claims, access control, wildcards, enterprise security
+tags: [admin]
+weight: 20
+---
+
+{{< summary-bar feature_name="OIDC connections" >}}
+
+Rulesets and subject claims define what actions your GitHub workflows can
+take with your Docker resources. Use them to authorize GitHub workflow
+behaviors for an OIDC connection.
+
+## Rulesets
+
+A ruleset is a set of conditions that Docker evaluates against an incoming
+GitHub ID token. When a workflow triggers an OIDC exchange, Docker checks
+the token against every ruleset defined in your connection. If a ruleset's
+conditions are satisfied, Docker grants access based on the parameters set
+by that ruleset.
+
+Each ruleset contains the following fields:
+
+- Label: A name for the ruleset.
+- Rules: One or more conditions based on OIDC token claims, such as the
+  repository name, branch, or workflow path.
+  - These are expressed as subject claim strings.
+  - See [Subject claims](#subject-claims).
+- Resources: The Docker resources a workflow can access when the ruleset
+  matches. See [Resources](#resources).
+- Scopes: The permissions granted on those resources, such as read or write
+  access.
+
+You can define between 1 and 5 rulesets per connection. Use multiple
+rulesets to apply different access levels across different workflows or
+branches. If more than one ruleset matches an incoming token, Docker merges
+the resources from all matching rulesets and grants access to the combined
+set.
+
+## Subject claims
+
+A subject claim is the `sub` field in a GitHub-issued JWT ID token. It
+encodes details of a workflow into a single string, identifying the
+workflow by organization, repository, branch, environment, and so on.
+
+Docker uses the subject claim as the primary condition when evaluating your
+ruleset rules. The default subject claim format is:
+
+```text
+repo:<org>/<repo>:ref:refs/heads/<branch>
+```
+
+For example:
+
+```text
+repo:octo-org/octo-repo:ref:refs/heads/main
+```
+
+The exact format varies and depends on what triggered the workflow.
+
+- A branch push, pull request, tag, or environment deployment each produces
+  a different `sub` value.
+- Refer to
+  [GitHub's OpenID Connect reference](https://docs.github.com/en/actions/reference/security/oidc)
+  for the full list of formats.
+
+> [!NOTE]
+> GitHub repositories created after July 15, 2026 use immutable
+> identifiers for default subject claims. For example:
+> `repo:octocat@123456/my-repo@456789:ref:refs/heads/main`. See the
+> [GitHub changelog](https://github.blog/changelog/2026-04-23-immutable-subject-claims-for-github-actions-oidc-tokens/)
+> for more details.
+
+You can use wildcards to match across repositories or branches:
+
+| Pattern                                        | Matches                                         |
+| :--------------------------------------------- | :---------------------------------------------- |
+| `repo:my-org/my-repo:ref:refs/heads/main`      | Only the `main` branch of a specific repository |
+| `repo:my-org/*`                                | All repos in the organization                   |
+| `repo:my-org/my-repo:ref:refs/heads/release-*` | All branches starting with `release-`           |
+
+## Resources
+
+Resources define the Docker resources a workflow can access when a ruleset
+matches. You specify resources per ruleset, alongside the scopes that
+determine the level of access granted.
+
+Docker Hub repositories and Docker Build Cloud are supported resources.
+
+## Next steps
+
+- [OIDC connections overview](/manuals/enterprise/security/oidc-connections/_index.md)
+- [Create or manage OIDC connections](/manuals/enterprise/security/oidc-connections/create-manage.md)
diff --git a/content/manuals/enterprise/security/provisioning/_index.md b/content/manuals/enterprise/security/provisioning/_index.md
new file mode 100644
index 000000000000..923731988856
--- /dev/null
+++ b/content/manuals/enterprise/security/provisioning/_index.md
@@ -0,0 +1,81 @@
+---
+description: Learn about provisioning users for your SSO configuration.
+keywords: provision users, provisioning, JIT, SCIM, group mapping, sso, docker admin, admin, security
+title: Provision users
+linkTitle: Provision
+weight: 20
+aliases:
+ - /security/for-admins/provisioning/
+grid:
+  - title: "SCIM provisioning"
+    description: "Enable continuous user data synchronization between your IdP and Docker. Best for larger organizations."
+    icon: arrow-path
+    link: "scim/"
+  - title: "Just-in-Time (JIT) provisioning"
+    description: "Set up automatic user creation on first sign-in. Ideal for smaller teams with minimal setup requirements."
+    icon: clock
+    link: "just-in-time/"
+  - title: "Auto-provisioning"
+    description: "Associate members to an organization when email addresses match a verified domain."
+    icon: user-group
+    link: "auto-provisioning/"
+---
+
+{{< summary-bar feature_name="SSO" >}}
+
+After configuring your SSO connection, the next step is to provision users. This process ensures that users can access your organization through automated user management.
+
+This page provides an overview of user provisioning and the supported provisioning methods.
+
+## What is provisioning?
+
+Provisioning helps manage users by automating tasks like account creation, updates, and deactivation based on data from your identity provider (IdP). There are several methods for user provisioning, each offering benefits for different organizational needs:
+
+| Provisioning method | Description | Default setting in Docker | Recommended for |
+| :--- | :--- | :------------- | :--- |
+| System for Cross-domain Identity Management (SCIM) | Continuously syncs user data between your IdP and Docker, ensuring user attributes remain updated without manual intervention | Disabled by default | Larger organizations or environments with frequent changes in user information or roles |
+| Group mapping | Maps user groups from your IdP to specific roles and permissions within Docker, enabling fine-grained access control based on group membership | Disabled by default | Organizations requiring strict access control and role-based user management |
+| Just-in-Time (JIT) | Automatically creates and provisions user accounts when they first sign in via SSO | Enabled by default | Organizations needing minimal setup, smaller teams, or low-security environments |
+| Auto-provision | Adds users when email addresses match a verified domain | Disabled by default | Orgs without SSO that need to add existing Docker users by domain |
+
+## Default provisioning setup
+
+By default, Docker enables JIT provisioning when you configure an SSO connection. With JIT enabled, user accounts are automatically created the first time a user signs in using your SSO flow.
+
+JIT provisioning may not provide sufficient control or security for some organizations. In such cases, SCIM or group mapping can be configured to give administrators more control over user access and attributes.
+
+## SSO attributes
+
+When a user signs in through SSO, Docker obtains several attributes from your IdP to manage the user's identity and permissions. These attributes include:
+
+- Email address: The unique identifier for the user
+- Full name: The user's complete name
+- Groups: Optional. Used for group-based access control
+- Docker Org: Optional. Specifies the organization the user belongs to
+- Docker Team: Optional. Defines the team the user belongs to within the organization
+- Docker Role: Optional. Determines the user's permissions within Docker
+- Docker session minutes: Optional. Sets the session duration before users must re-authenticate with their IdP. Must be a positive integer greater than 0. If not provided, default session timeouts apply
+
+> [!NOTE]
+>
+> Default session timeouts apply when Docker session minutes is not specified. Docker Desktop sessions expire after 90 days or 30 days of inactivity. Docker Hub and Docker Home sessions expire after 24 hours.
+
+## SAML attribute mapping
+
+If your organization uses SAML for SSO, Docker retrieves these attributes from the SAML assertion message. Different IdPs may use different names for these attributes.
+
+| SSO Attribute	| SAML Assertion Message Attributes |
+| :--- | :--- |
+| Email address |	`"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"`, `"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"`, `"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"`, `email` |
+| Full name	| `"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"`, `name`, `"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"`, `"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"` |
+| Groups (optional) |	`"http://schemas.xmlsoap.org/claims/Group"`, `"http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"`, `Groups`, `groups` |
+| Docker Org (optional)	| `dockerOrg` |
+| Docker Team (optional) |	`dockerTeam` |
+| Docker Role (optional) |	`dockerRole` |
+| Docker session minutes (optional) | `dockerSessionMinutes`, must be a positive integer > 0 |
+
+## Next steps
+
+Choose the provisioning method that best fits your organization's needs:
+
+{{< grid >}}
\ No newline at end of file
diff --git a/content/manuals/enterprise/security/provisioning/auto-provisioning.md b/content/manuals/enterprise/security/provisioning/auto-provisioning.md
new file mode 100644
index 000000000000..a0ab4c209362
--- /dev/null
+++ b/content/manuals/enterprise/security/provisioning/auto-provisioning.md
@@ -0,0 +1,58 @@
+---
+title: Auto-provisioning
+linkTitle: Auto-provision
+description: Auto-provision users by associating members to your organization when email addresses match a verified domain.
+keywords: user provisioning, just-in-time provisioning, JIT, autoprovision, Docker Admin, admin, security
+weight: 30
+---
+
+Auto-provisioning automatically adds users to your organization when they sign in with email addresses that match your verified domains. You must verify a domain before enabling auto-provisioning.
+
+> [!IMPORTANT]
+>
+> For domains that are part of an SSO connection, Just-in-Time (JIT) provisioning takes precedence over auto-provisioning when adding users to an organization.
+
+### Overview
+
+When auto-provisioning is enabled for a verified domain:
+
+- Users who sign in to Docker with matching email addresses are automatically added to your organization.
+- Auto-provisioning only adds existing Docker users to your organization, it doesn't create new accounts.
+- Users experience no changes to their sign-in process.
+- Company and organization owners receive email notifications when new users are added.
+- You may need to [manage seats](/manuals/admin/organization/manage/manage-seats.md) to accommodate new users.
+
+### Enable auto-provisioning
+
+Auto-provisioning is configured per domain. To enable it:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select
+   your company or organization.
+1. Select **Identity & auth**, then **Domain management**.
+1. Select the **Actions menu** next to the domain you want to enable
+   auto-provisioning for.
+1. Select **Enable auto-provisioning**.
+1. Optional. If enabling auto-provisioning at the company level, select an
+   organization.
+1. Select **Enable** to confirm.
+
+The **Auto-provisioning** column will update to **Enabled** for the domain.
+
+### Disable auto-provisioning
+
+To disable auto-provisioning for a user:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select
+   your organization. If your organization is part of a company, select the company
+   and configure the domain for the organization at the company level.
+1. Select **Identity & auth**, then **Domain management**.
+1. Select the **Actions menu** next to your domain.
+1. Select **Disable auto-provisioning**.
+1. Select **Disable** to confirm.
+
+## Next steps
+
+To choose a different method to provision users, you can set up:
+
+- [SCIM provisioning](/manuals/enterprise/security/provisioning/scim/_index.md) for advanced user management.
+- [Group mapping](/manuals/enterprise/security/provisioning/scim/group-mapping.md) to assign users to teams automatically.
diff --git a/content/manuals/enterprise/security/provisioning/just-in-time.md b/content/manuals/enterprise/security/provisioning/just-in-time.md
new file mode 100644
index 000000000000..e2ed13bf3f8e
--- /dev/null
+++ b/content/manuals/enterprise/security/provisioning/just-in-time.md
@@ -0,0 +1,84 @@
+---
+description: Learn how Just-in-Time provisioning works with your SSO connection.
+keywords: user provisioning, just-in-time provisioning, JIT, autoprovision, Docker Admin, admin, security
+title: Just-in-Time provisioning
+linkTitle: Just-in-Time
+weight: 20
+aliases:
+  - /security/for-admins/provisioning/just-in-time/
+---
+
+{{< summary-bar feature_name="SSO" >}}
+
+Just-in-Time (JIT) provisioning streamlines user onboarding by automatically creating and updating user accounts during SSO authentication. This eliminates manual account creation and ensures users have immediate access to your organization's resources. JIT verifies that users belong to the organization and assigns them to the appropriate teams based on your identity provider (IdP) configuration. When you create your SSO connection, JIT provisioning is turned on by default.
+
+This page explains how JIT provisioning works, SSO authentication flows, and how to disable JIT provisioning.
+
+## Prerequisites
+
+Before you begin, you must have:
+
+- SSO configured for your organization
+- Administrator access to Docker Home and your identity provider
+
+## SSO authentication with JIT provisioning enabled
+
+When a user signs in with SSO and you have JIT provisioning enabled, the following steps occur automatically:
+
+1. The system checks if a Docker account exists for the user's email address.
+   - If an account exists: The system uses the existing account and updates the user's full name if necessary.
+   - If no account exists: A new Docker account is created using basic user attributes (email, name, and surname). A unique username is generated based on the user's email, name, and random numbers to ensure all usernames are unique across the platform.
+
+2. The system checks for any pending invitations to the SSO organization.
+   - Invitation found: The invitation is automatically accepted.
+   - Invitation includes a specific group: The user is added to that group within the SSO organization.
+
+3. The system verifies if the IdP has shared group mappings during authentication.
+   - Group mappings provided: The user is assigned to the relevant organizations and teams.
+   - No group mappings provided: The system checks if the user is already part of the organization. If not, the user is added to the default organization and team configured in the SSO connection.
+
+The following graphic provides an overview of SSO authentication with JIT enabled:
+
+![JIT provisioning enabled workflow](../images/jit-enabled-flow.svg)
+
+## SSO authentication with JIT provisioning disabled
+
+When JIT provisioning is disabled, the following actions occur during SSO authentication:
+
+1. The system checks if a Docker account exists for the user's email address.
+   - If an account exists: The system uses the existing account and updates the user's full name if necessary.
+   - If no account exists: A new Docker account is created using basic user attributes (email, name, and surname). A unique username is generated based on the user's email, name, and random numbers to ensure all usernames are unique across the platform.
+
+2. The system checks for any pending invitations to the SSO organization.
+   - Invitation found: If the user is a member of the organization or has a pending invitation, sign-in is successful, and the invitation is automatically accepted.
+   - No invitation found: If the user is not a member of the organization and has no pending invitation, the sign-in fails, and an `Access denied` error appears. The user must contact an administrator to be invited to the organization.
+
+With JIT disabled, group mapping is only available if you have [SCIM enabled](scim/#enable-scim-in-docker). If SCIM is not enabled, users won't be auto-provisioned to groups.
+
+The following graphic provides an overview of SSO authentication with JIT disabled:
+
+![JIT provisioning disabled workflow](../images/jit-disabled-flow.svg)
+
+## Disable JIT provisioning
+
+> [!WARNING]
+>
+> Disabling JIT provisioning may disrupt your users' access and workflows. With JIT disabled, users will not be automatically added to your organization. Users must already be a member of the organization or have a pending invitation to successfully sign in through SSO. To auto-provision users with JIT disabled, [use SCIM](./scim.md).
+
+You may want to disable JIT provisioning for reasons such as the following:
+
+- You have multiple organizations, have SCIM enabled, and want SCIM to be the source of truth for provisioning
+- You want to control and restrict usage based on your organization's security configuration, and want to use SCIM to provision access
+
+Users are provisioned with JIT by default. If you enable SCIM, you can disable JIT:
+
+1. Go to [Docker Home](https://app.docker.com/) and select your organization from the top-left account drop-down.
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. In the **SSO connections** table, select the **Action** icon, then select **Disable JIT provisioning**.
+1. Select **Disable** to confirm.
+
+## Next steps
+
+- Configure [SCIM provisioning](/manuals/enterprise/security/provisioning/scim/_index.md) for advanced user management.
+- Set up [group mapping](/manuals/enterprise/security/provisioning/scim/group-mapping.md) to automatically assign users to teams.
+- Review [Troubleshoot provisioning](/manuals/enterprise/security/provisioning/troubleshoot-provisioning.md).
diff --git a/content/manuals/enterprise/security/provisioning/scim/_index.md b/content/manuals/enterprise/security/provisioning/scim/_index.md
new file mode 100644
index 000000000000..ace0770e759d
--- /dev/null
+++ b/content/manuals/enterprise/security/provisioning/scim/_index.md
@@ -0,0 +1,64 @@
+---
+title: SCIM overview
+linkTitle: SCIM
+weight: 10
+description: Learn how System for Cross-domain Identity Management works and how to set it up.
+keywords: SCIM, SSO, user provisioning, de-provisioning, role mapping, assign users
+aliases:
+  - /security/for-admins/scim/
+  - /security/for-admins/provisioning/scim/
+---
+
+{{< summary-bar feature_name="SSO" >}}
+
+Automate user management for your Docker organization using System for
+Cross-domain Identity Management (SCIM). SCIM automatically provisions and
+de-provisions users, synchronizes team memberships, and keeps your Docker
+organization in sync with your identity provider.
+
+This page shows you how to automate user provisioning and de-provisioning for
+Docker using SCIM.
+
+## Prerequisites
+
+Before you begin, you must have:
+
+- SSO configured for your organization
+- Administrator access to Docker Home and your identity provider
+
+## How SCIM works
+
+SCIM automates user provisioning and de-provisioning for Docker through your
+identity provider. After you enable SCIM, any user assigned to your
+Docker application in your identity provider is automatically provisioned and
+added to your Docker organization. When a user is removed from the Docker
+application in your identity provider, SCIM deactivates and removes them from
+your Docker organization.
+
+In addition to provisioning and removal, SCIM also syncs profile updates like
+name changes made in your identity provider. You can use SCIM alongside Docker's
+default Just-in-Time (JIT) provisioning or on its own with JIT disabled.
+
+SCIM automates:
+
+- Creating users
+- Updating user profiles
+- Removing and deactivating users
+- Re-activating users
+- Group mapping
+
+> [!NOTE]
+>
+> SCIM only manages users provisioned through your identity provider after
+> SCIM is enabled. It cannot remove users who were manually added to your Docker
+> organization before SCIM was set up.
+>
+> To remove those users, delete them manually from your Docker organization.
+> For more information, see
+> [Manage organization members](/manuals/admin/organization/manage/members.md).
+
+## Next steps
+
+- [Migrate JIT to SCIM](/manuals/enterprise/security/provisioning/scim/migrate-scim.md) if users were provisioned with Just-in-Time (JIT) before you enabled SCIM.
+- [Group mapping](/manuals/enterprise/security/provisioning/scim/group-mapping.md) to sync identity provider groups with members.
+- [Troubleshoot provisioning](/manuals/enterprise/security/provisioning/troubleshoot-provisioning.md) for SCIM, JIT, and attribute issues.
diff --git a/content/manuals/enterprise/security/provisioning/scim/group-mapping.md b/content/manuals/enterprise/security/provisioning/scim/group-mapping.md
new file mode 100644
index 000000000000..308cad4a8e7e
--- /dev/null
+++ b/content/manuals/enterprise/security/provisioning/scim/group-mapping.md
@@ -0,0 +1,198 @@
+---
+title: Group mapping
+description: Automate team membership by syncing identity provider groups with Docker Teams
+keywords: Group Mapping, SCIM, Docker Admin, admin, security, team management, user provisioning, identity provider
+aliases:
+- /admin/company/settings/group-mapping/
+- /admin/organization/security-settings/group-mapping/
+- /security/for-admins/group-mapping/
+- /security/for-admins/provisioning/scim/group-mapping/
+- /enterprise/security/provisioning/group-mapping/
+weight: 20
+---
+
+{{< summary-bar feature_name="SSO" >}}
+
+Group mapping automatically synchronizes user groups from your identity provider (IdP) with teams in your Docker organization. For example, when you add a developer to the "backend-team" group in your IdP, they're automatically added to the corresponding team in Docker
+
+This page explains how group mapping works, and how to set up group mapping.
+
+> [!TIP]
+>
+> Group mapping is ideal for adding users to multiple organizations or multiple teams within one organization. If you don't need to set up multi-organization or multi-team assignment, SCIM [user-level attributes](provision-scim.md#set-up-role-mapping) may be a better fit for your needs.
+
+## Prerequisites
+
+Before you begin, you must have:
+
+- SSO configured for your organization
+- Administrator access to Docker Home and your identity provider
+
+## How group mapping works
+
+Group mapping keeps your Docker Teams synchronized with your IdP groups through these key components:
+
+- Authentication flow: When users sign in through SSO, your IdP shares user attributes with Docker including email, name, and group memberships.
+- Automatic updates: Docker uses these attributes to create or update user profiles and manage team assignments based on IdP group changes.
+- Unique identification: Docker uses email addresses as unique identifiers, so each Docker account must have a unique email address.
+- Team synchronization: Users' team memberships in Docker automatically reflect changes made in your IdP groups.
+
+## Set up group mapping
+
+Group mapping setup involves configuring your identity provider to share group
+information with Docker. This requires:
+
+- Creating groups in your IdP using Docker's naming format
+- Configuring attributes so your IdP sends group data during authentication
+- Adding users to the appropriate groups
+- Testing the connection to ensure groups sync properly
+
+You can use group mapping with SSO only, or with both SSO and SCIM for enhanced
+user lifecycle management.
+
+### Group naming format
+
+Create groups in your IdP using the format: `organization:team`.
+
+For example:
+
+- For the "developers" team in the "moby" organization: `moby:developers`
+- For multi-organization access: `moby:backend` and `whale:desktop`
+
+Docker creates teams automatically if they don't already exist when groups sync.
+
+### Supported attributes
+
+| Attribute | Description |
+|:--------- | :---------- |
+| `id` | Unique ID of the group in UUID format. This attribute is read-only. |
+| `displayName` | Name of the group following the group mapping format: `organization:team`. |
+| `members` | A list of users that are members of this group. |
+| `members(x).value` | Unique ID of the user that is a member of this group. Members are referenced by ID. |
+
+## Configure group mapping with SSO
+
+Use group mapping with SSO connections that use the SAML authentication method.
+
+> [!NOTE]
+>
+> Group mapping with SSO isn't supported with the Azure AD (OIDC) authentication method. SCIM isn't required for these configurations.
+
+{{< tabs >}}
+{{< tab name="Okta" >}}
+
+The user interface for your IdP may differ slightly from the following steps. Refer to the [Okta documentation](https://help.okta.com/oie/en-us/content/topics/apps/define-group-attribute-statements.htm) to verify.
+
+To set up group mapping:
+
+1. Sign in to Okta and open your application.
+1. Navigate to the **SAML Settings** page for your application.
+1. In the **Group Attribute Statements (optional)** section, configure like the following:
+   - **Name**: `groups`
+   - **Name format**: `Unspecified`
+   - **Filter**: `Starts with` + `organization:` where `organization` is the name of your organization
+   The filter option will filter out the groups that aren't affiliated with your Docker organization.
+1. Create your groups by selecting **Directory**, then **Groups**.
+1. Add your groups using the format `organization:team` that matches the names of your organization(s) and team(s) in Docker.
+1. Assign users to the group(s) that you create.
+
+The next time you sync your groups with Docker, your users will map to the Docker groups you defined.
+
+{{< /tab >}}
+{{< tab name="Entra ID" >}}
+
+The user interface for your IdP may differ slightly from the following steps. Refer to the [Entra ID documentation](https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/customize-application-attributes) to verify.
+
+To set up group mapping:
+
+1. Sign in to Entra ID and open your application.
+1. Select **Manage**, then **Single sign-on**.
+1. Select **Add a group claim**.
+1. In the Group Claims section, select **Groups assigned to the application** with the source attribute **Cloud-only group display names (Preview)**.
+1. Select **Advanced options**, then the **Filter groups** option.
+1. Configure the attribute like the following:
+   - **Attribute to match**: `Display name`
+   - **Match with**: `Contains`
+   - **String**: `:`
+1. Select **Save**.
+1. Select **Groups**, **All groups**, then **New group** to create your group(s).
+1. Assign users to the group(s) that you create.
+
+The next time you sync your groups with Docker, your users will map to the Docker groups you defined.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Configure group mapping with SCIM
+
+Use group mapping with SCIM for more advanced user lifecycle management. Before you begin, make sure you [set up SCIM](./provision-scim.md#enable-scim) first.
+
+{{< tabs >}}
+{{< tab name="Okta" >}}
+
+The user interface for your IdP may differ slightly from the following steps. Refer to the [Okta documentation](https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-enable-group-push.htm) to verify.
+
+To set up your groups:
+
+1. Sign in to Okta and open your application.
+1. Select **Applications**, then **Provisioning**, and **Integration**.
+1. Select **Edit** to enable groups on your connection, then select **Push groups**.
+1. Select **Save**. Saving this configuration will add the **Push Groups** tab to your application.
+1. Create your groups by navigating to **Directory** and selecting **Groups**.
+1. Add your groups using the format `organization:team` that matches the names of your organization(s) and team(s) in Docker.
+1. Assign users to the group(s) that you create.
+1. Return to the **Integration** page, then select the **Push Groups** tab to open the view where you can control and manage how groups are provisioned.
+1. Select **Push Groups**, then **Find groups by rule**.
+1. Configure the groups by rule like the following:
+    - Enter a rule name, for example `Sync groups with Docker Hub`
+    - Match group by name, for example starts with `docker:` or contains `:` for multi-organization
+    - If you enable **Immediately push groups by rule**, sync will happen as soon as there's a change to the group or group assignments. Enable this if you don't want to manually push groups.
+
+Find your new rule under **By rule** in the **Pushed Groups** column. The groups that match that rule are listed in the groups table on the right-hand side.
+
+To push the groups from this table:
+
+1. Select **Group in Okta**.
+1. Select the **Push Status** drop-down.
+1. Select **Push Now**.
+
+{{< /tab >}}
+{{< tab name="Entra ID" >}}
+
+The user interface for your IdP may differ slightly from the following steps. Refer to the [Entra ID documentation](https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/customize-application-attributes) to verify.
+
+Complete the following before configuring group mapping:
+
+1. Sign in to Entra ID and go to your application.
+1. In your application, select **Provisioning**, then **Mappings**.
+1. Select **Provision Microsoft Entra ID Groups**.
+1. Select **Show advanced options**, then **Edit attribute list**.
+1. Update the `externalId` type to `reference`, then select the **Multi-Value** checkbox and choose the referenced object attribute `urn:ietf:params:scim:schemas:core:2.0:Group`.
+1. Select **Save**, then **Yes** to confirm.
+1. Go to **Provisioning**.
+1. Toggle **Provision Status** to **On**, then select **Save**.
+
+Next, set up group mapping:
+
+1. Go to the application overview page.
+1. Under **Provision user accounts**, select **Get started**.
+1. Select **Add user/group**.
+1. Create your group(s) using the `organization:team` format.
+1. Assign the group to the provisioning group.
+1. Select **Start provisioning** to start the sync.
+
+To verify, select **Monitor**, then **Provisioning logs** to see that your groups were provisioned successfully. In your Docker organization, you can check that the groups were correctly provisioned and the members were added to the appropriate teams.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+Once complete, a user who signs in to Docker through SSO is automatically added to the organizations and teams mapped in the IdP.
+
+> [!TIP]
+>
+> [Enable SCIM](provision-scim.md) to take advantage of automatic user provisioning and de-provisioning. If you don't enable SCIM users are only automatically provisioned. You have to de-provision them manually.
+
+## Next steps
+
+- [Assign roles](/manuals/enterprise/security/roles-and-permissions/core-roles.md) to members of your org.
+- [Enforce sign in](/manuals/enterprise/security/enforce-sign-in.md), if needed.
diff --git a/content/manuals/enterprise/security/provisioning/scim/migrate-scim.md b/content/manuals/enterprise/security/provisioning/scim/migrate-scim.md
new file mode 100644
index 000000000000..00b62c4f3bbf
--- /dev/null
+++ b/content/manuals/enterprise/security/provisioning/scim/migrate-scim.md
@@ -0,0 +1,180 @@
+---
+title: Migrate JIT to SCIM
+linkTitle: Migrate
+description: Learn how to migrate from just-in-time (JIT) to SCIM.
+weight: 30
+---
+
+If you already have users provisioned through Just-in-Time (JIT) and want to
+enable full SCIM lifecycle management, you need to migrate them. Users
+originally created by JIT cannot be automatically de-provisioned through SCIM,
+even after SCIM is enabled.
+
+## Why migrate
+
+Organizations using JIT provisioning may encounter limitations with user
+lifecycle management, particularly around de-provisioning. Migrating to SCIM
+provides:
+
+- Automatic user de-provisioning when users leave your organization. This is
+  the primary benefit for large organizations that need full automation.
+- Continuous synchronization of user attributes
+- Centralized user management through your identity provider
+- Enhanced security through automated access control
+
+> [!IMPORTANT]
+>
+> Users originally created through JIT provisioning cannot be automatically
+> de-provisioned by SCIM, even after SCIM is enabled. To enable full lifecycle
+> management including automatic de-provisioning through your identity provider,
+> you must manually remove these users so SCIM can re-create them with proper
+> lifecycle management capabilities.
+
+This migration is most critical for larger organizations that require fully
+automated user de-provisioning when employees leave the company.
+
+## Prerequisites
+
+Before migrating, ensure you have:
+
+- SCIM configured and tested in your organization
+- A maintenance window for the migration
+
+> [!WARNING]
+>
+> This migration temporarily disrupts user access. Plan to perform this
+> migration during a low-usage window and communicate the timeline to affected
+> users.
+
+## Prepare for migration
+
+### Transfer ownership
+
+Before removing users, ensure that any repositories, teams, or organization
+resources they own are transferred to another administrator or service account.
+When a user is removed from the organization, any resources they own may
+become inaccessible.
+
+1. Review repositories, organization resources, and team ownership for affected
+   users.
+2. Transfer ownership to another administrator.
+
+> [!WARNING]
+>
+> If ownership is not transferred, repositories owned by removed users may
+> become inaccessible when the user is removed. Ensure all critical resources
+> are transferred before proceeding.
+
+### Verify identity provider configuration
+
+1. Confirm all JIT-provisioned users are assigned to the Docker application in
+   your identity provider.
+2. Verify identity provider group to Docker Team mappings are configured and
+   tested.
+
+Users not assigned to the Docker application in your identity provider are not
+re-created by SCIM after removal.
+
+### Export user records
+
+Export a list of JIT-provisioned users from Docker Home:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your
+   organization.
+2. Select **Members**.
+3. Select **Export members** to download the member list as CSV for backup and
+   reference.
+
+Keep this CSV list of JIT-provisioned users as a rollback reference if needed.
+
+## Complete the migration
+
+### Disable JIT provisioning
+
+> [!IMPORTANT]
+>
+> Before disabling JIT, ensure SCIM is fully configured and tested in your
+> organization. Do not disable JIT until you have verified SCIM is working
+> correctly.
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization.
+2. Select **Identity & auth**, then **SSO and SCIM**.
+3. In the SSO connections table, select the **Actions** menu for your connection.
+4. Select **Disable JIT provisioning**.
+5. Select **Disable** to confirm.
+
+Disabling JIT prevents new users from being automatically added through SSO
+during the migration.
+
+### Remove JIT-origin users
+
+> [!IMPORTANT]
+>
+> Users originally created through JIT provisioning cannot be automatically
+> de-provisioned by SCIM, even after SCIM is enabled. To enable full lifecycle
+> management including automatic de-provisioning through your identity provider,
+> you must manually remove these users so SCIM can re-create them with proper
+> lifecycle management capabilities.
+
+This step is most critical for large organizations that require fully automated
+user de-provisioning when employees leave the company.
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization.
+2. Select **Members**.
+3. Identify and remove JIT-provisioned users in manageable batches.
+4. Monitor for any errors during removal.
+
+> [!TIP]
+>
+> To efficiently identify JIT users, compare the member list exported before
+> SCIM was enabled with the current member list. Users who existed before SCIM
+> was enabled were likely provisioned via JIT.
+
+### Verify SCIM re-provisioning
+
+After removing JIT users, SCIM automatically re-creates user accounts:
+
+1. In your identity provider system log, confirm "create app user" events for
+   Docker.
+2. In Docker Home under **Members**, confirm users reappear with SCIM provisioning.
+3. Verify users are added to the correct teams via group mapping.
+
+### Validate user access
+
+Perform post-migration validation:
+
+1. Select a subset of migrated users to test sign-in and access.
+2. Verify team membership matches identity provider group assignments.
+3. Confirm repository access is restored.
+4. Test that de-provisioning works correctly by removing a test user from your
+   identity provider.
+
+Keep audit exports and logs for compliance purposes.
+
+## Migration results
+
+After completing the migration:
+
+- All users in your organization are SCIM-provisioned
+- User de-provisioning works reliably through your identity provider
+- No new JIT users are created
+- Consistent identity lifecycle management is maintained
+
+## Troubleshoot migration issues
+
+If a user fails to reappear after removal:
+
+1. Check that the user is assigned to the Docker application in your identity
+   provider.
+2. Verify SCIM is enabled in both Docker and your identity provider.
+3. Trigger a manual SCIM sync in your identity provider.
+4. Check provisioning logs in your identity provider for errors.
+
+For more troubleshooting guidance, see
+[Troubleshoot provisioning](/manuals/enterprise/security/provisioning/troubleshoot-provisioning.md).
+
+## Next steps
+
+- Set up [Group mapping](/manuals/enterprise/security/provisioning/scim/group-mapping.md).
+- [Assign roles](/manuals/enterprise/security/roles-and-permissions/core-roles.md) to members of your org.
+- [Enforce sign in](/manuals/enterprise/security/enforce-sign-in.md), if needed.
diff --git a/content/manuals/enterprise/security/provisioning/scim/provision-scim.md b/content/manuals/enterprise/security/provisioning/scim/provision-scim.md
new file mode 100644
index 000000000000..5f7a24703547
--- /dev/null
+++ b/content/manuals/enterprise/security/provisioning/scim/provision-scim.md
@@ -0,0 +1,374 @@
+---
+title: Set up SCIM provisioning
+linkTitle: Setup
+description: Learn how System for Cross-domain Identity Management works and how to set it up.
+weight: 10
+aliases:
+  - /enterprise/security/provisioning/scim/
+---
+
+{{< summary-bar feature_name="SSO" >}}
+
+## Supported attributes
+
+SCIM uses attributes (name, email, etc.) to sync user information between your
+identity provider and Docker. Properly mapping these attributes in your identity
+provider ensures that user provisioning works smoothly and prevents issues like
+duplicate user accounts
+when using single sign-on.
+
+Docker supports the following SCIM attributes:
+
+| Attribute         | Description                                                                       |
+| :---------------- | :-------------------------------------------------------------------------------- |
+| `userName`        | User's primary email address, used as the unique identifier                       |
+| `name.givenName`  | User's first name                                                                 |
+| `name.familyName` | User's surname                                                                    |
+| `active`          | Indicates if a user is enabled or disabled, set to "false" to de-provision a user |
+
+For additional details about supported attributes and SCIM, see
+[Docker Hub API SCIM reference](/reference/api/hub/latest.md#tag/scim).
+
+> [!IMPORTANT]
+>
+> By default, Docker uses Just-in-Time (JIT) provisioning for SSO. If SCIM is
+> enabled, JIT values still take precedence and will overwrite attribute values
+> set by SCIM. To avoid conflicts, make sure your JIT attribute values match
+> your SCIM values.
+>
+> Alternatively, you can disable JIT provisioning to rely solely on SCIM.
+> For details, see [Just-in-Time](/manuals/enterprise/security/provisioning/just-in-time.md).
+
+## Enable SCIM in Docker
+
+To enable SCIM:
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. In the **SSO connections** table, select the **Actions** icon for your
+   connection, then select **Setup SCIM**.
+1. Copy the **SCIM Base URL** and **API Token** and paste the values into your
+   IdP.
+
+## Enable SCIM in your IdP
+
+The user interface for your identity provider may differ slightly from the
+following steps. You can refer to the documentation for your identity provider
+to verify. For additional details, see the documentation for your identity
+provider:
+
+- [Okta](https://help.okta.com/en-us/Content/Topics/Apps/Apps_App_Integration_Wizard_SCIM.htm)
+- [Entra ID/Azure AD SAML 2.0](https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/user-provisioning)
+
+> [!NOTE]
+>
+> Microsoft does not currently support SCIM and OIDC in the same non-gallery
+> application in Entra ID. This page provides a verified workaround using a
+> separate non-gallery app for SCIM provisioning. While Microsoft does not
+> officially document this setup, it is widely used and supported in practice.
+
+{{< tabs >}}
+{{< tab name="Okta" >}}
+
+### Step one: Enable SCIM
+
+1. Sign in to Okta and select **Admin** to open the admin portal.
+1. Open the application you created when you configured your SSO connection.
+1. On the application page, select the **General** tab, then
+   **Edit App Settings**.
+1. Enable SCIM provisioning, then select **Save**.
+1. Navigate to the **Provisioning**, then select **Edit SCIM Connection**.
+1. To configure SCIM in Okta, set up your connection using the following
+   values and settings:
+   - SCIM Base URL: SCIM connector base URL (copied from Docker Home)
+   - Unique identifier field for users: `email`
+   - Supported provisioning actions: **Push New Users** and
+     **Push Profile Updates**
+   - Authentication Mode: HTTP Header
+   - SCIM Bearer Token: HTTP Header Authorization Bearer Token
+     (copied from Docker Home)
+1. Select **Test Connector Configuration**.
+1. Review the test results and select **Save**.
+
+### Step two: Enable synchronization
+
+1. In Okta, select **Provisioning**.
+1. Select **To App**, then **Edit**.
+1. Enable **Create Users**, **Update User Attributes**, and **Deactivate Users**.
+1. Select **Save**.
+1. Remove unnecessary mappings. The necessary mappings are:
+   - Username
+   - Given name
+   - Family name
+   - Email
+
+Next, [set up role mapping](#set-up-role-mapping).
+
+{{< /tab >}}
+{{< tab name="Entra ID (OIDC)" >}}
+
+Microsoft does not support SCIM and OIDC in the same non-gallery application.
+You must create a second non-gallery application in Entra ID for SCIM
+provisioning.
+
+### Step one: Create a separate SCIM app
+
+1. In the Azure Portal, go to **Microsoft Entra ID** >
+   **Enterprise Applications** > **New application**.
+1. Select **Create your own application**.
+1. Name your application and choose
+   **Integrate any other application you don't find in the gallery**.
+1. Select **Create**.
+
+### Step two: Configure SCIM provisioning
+
+1. In your new SCIM application, go to **Provisioning** > **Get started**.
+1. Set **Provisioning Mode** to **Automatic**.
+1. Under **Admin Credentials**:
+   - **Tenant URL**: Paste the **SCIM Base URL** from Docker Home.
+   - **Secret Token**: Paste the **SCIM API token** from Docker Home.
+1. Select **Test Connection** to verify.
+1. Select **Save** to store credentials.
+
+Next, [set up role mapping](#set-up-role-mapping).
+
+{{< /tab >}}
+{{< tab name="Entra ID (SAML 2.0)" >}}
+
+1. In the Azure Portal, go to **Microsoft Entra ID** >
+   **Enterprise Applications**, and select your Docker SAML app.
+1. Select **Provisioning** > **Get started**.
+1. Set **Provisioning Mode** to **Automatic**.
+1. Under **Admin Credentials**:
+   - **Tenant URL**: Paste the **SCIM Base URL** from Docker Home.
+   - **Secret Token**: Paste the **SCIM API token** from Docker Home.
+1. Select **Test Connection** to verify.
+1. Select **Save** to store credentials.
+
+Next, [set up role mapping](#set-up-role-mapping).
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Set up role mapping
+
+You can assign [Docker roles](/manuals/enterprise/security/roles-and-permissions/_index.md) to
+users by adding optional SCIM attributes in your IdP. These attributes override
+default role and team values set in your SSO configuration.
+
+> [!NOTE]
+>
+> Role mappings are supported for both SCIM and Just-in-Time (JIT)
+> provisioning. For JIT, role mapping applies only when the user is first
+> provisioned.
+
+The following table lists the supported optional user-level attributes:
+
+| Attribute    | Possible values                          | Notes                                                                                                                                                                                                                                                            |
+| ------------ | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `dockerRole` | `member`, `editor`, or `owner`           | If not set, the user defaults to the `member` role. Setting this attribute overrides the default.<br><br>For role definitions, see [Roles and permissions](/manuals/enterprise/security/roles-and-permissions/_index.md).                                        |
+| `dockerOrg`  | Docker `organizationName` (e.g., `moby`) | Overrides the default organization configured in your SSO connection.<br><br>If unset, the user is provisioned to the default organization. If `dockerOrg` and `dockerTeam` are both set, the user is provisioned to the team within the specified organization. |
+| `dockerTeam` | Docker `teamName` (e.g., `developers`)   | Provisions the user to the specified team in the default or specified organization. If the team doesn't exist, it is automatically created.<br><br>You can still use [group mapping](group-mapping.md) to assign users to multiple teams across organizations.   |
+
+The external namespace used for these attributes is: `urn:ietf:params:scim:schemas:extension:docker:2.0:User`.
+This value is required in your identity provider when creating custom SCIM attributes for Docker.
+
+{{< tabs >}}
+{{< tab name="Okta" >}}
+
+### Step one: Set up role mapping in Okta
+
+1. Setup [SSO](/manuals/enterprise/security/single-sign-on/connect.md) and SCIM first.
+1. In the Okta admin portal, go to **Directory**, select **Profile Editor**,
+   and then **User (Default)**.
+1. Select **Add Attribute** and configure the values for the role, organization,
+   or team you want to add. Exact naming isn't required.
+1. Return to the **Profile Editor** and select your application.
+1. Select **Add Attribute** and enter the required values. The **External Name**
+   and **External Namespace** must be exact.
+   - The external name values for organization/team/role mapping are
+     `dockerOrg`, `dockerTeam`, and `dockerRole` respectively, as listed in the previous table.
+   - The external namespace is the same for all of them:
+     `urn:ietf:params:scim:schemas:extension:docker:2.0:User`.
+1. After creating the attributes, navigate to the top of the page and select
+   **Mappings**, then **Okta User to YOUR APP**.
+1. Go to the newly created attributes and map the variable names to the external
+   names, then select **Save Mappings**. If you're using JIT provisioning, continue
+   to the following steps.
+1. Navigate to **Applications** and select **YOUR APP**.
+1. Select **General**, then **SAML Settings**, and **Edit**.
+1. Select **Step 2** and configure the mapping from the user attribute to the
+   Docker variables.
+
+### Step two: Assign roles by user
+
+1. In the Okta Admin portal, select **Directory**, then **People**.
+1. Select **Profile**, then **Edit**.
+1. Select **Attributes** and update the attributes to the desired values.
+
+### Step three: Assign roles by group
+
+1. In the Okta Admin portal, select **Directory**, then **People**.
+1. Select **YOUR GROUP**, then **Applications**.
+1. Open **YOUR APPLICATION** and select the **Edit** icon.
+1. Update the attributes to the desired values.
+
+If a user doesn't already have attributes set up, users who are added to the
+group will inherit these attributes upon provisioning.
+
+{{< /tab >}}
+{{< tab name="Entra ID/Azure AD (SAML 2.0 and OIDC)" >}}
+
+### Step one: Configure attribute mappings
+
+1. Complete the [SCIM provisioning setup](/manuals/enterprise/security/provisioning/scim/provision-scim.md#enable-scim-in-docker).
+1. In the Azure Portal, open **Microsoft Entra ID** >
+   **Enterprise Applications**, and select your SCIM application.
+1. Go to **Provisioning** > **Mappings** >
+   **Provision Azure Active Directory Users**.
+1. Add or update the following mappings:
+   - `userPrincipalName` -> `userName`
+   - `mail` -> `emails.value`
+   - Optional. Map `dockerRole`, `dockerOrg`, or `dockerTeam` using one of the
+     [mapping methods](/manuals/enterprise/security/provisioning/scim/provision-scim.md#set-up-role-mapping).
+1. Remove any unsupported attributes to prevent sync errors.
+1. Optional. Go to **Mappings** > **Provision Azure Active Directory Groups**:
+   - If group provisioning causes errors, set **Enabled** to **No**.
+   - If enabling, test group mappings carefully.
+1. Select **Save** to apply mappings.
+
+### Step two: Choose a role mapping method
+
+You can map `dockerRole`, `dockerOrg`, or `dockerTeam` using one of the
+following methods:
+
+#### Expression mapping
+
+Use this method if you only need to assign Docker roles like `member`, `editor`,
+or `owner`.
+
+1. In the **Edit Attribute** view, set the mapping type to **Expression**.
+1. In the **Expression** field:
+   1. If your App Roles match Docker roles exactly, use:
+      SingleAppRoleAssignment([appRoleAssignments])
+   1. If they don't match, use a switch expression: `Switch(SingleAppRoleAssignment([appRoleAssignments]), "My Corp Admins", "owner", "My Corp Editors", "editor", "My Corp Users", "member")`
+1. Set:
+   - **Target attribute**: `urn:ietf:params:scim:schemas:extension:docker:2.0:User:dockerRole`
+   - **Match objects using this attribute**: No
+   - **Apply this mapping**: Always
+1. Save your changes.
+
+> [!WARNING]
+>
+> You can't use `dockerOrg` or `dockerTeam` with this method. Expression mapping
+> is only compatible with one attribute.
+
+#### Direct mapping
+
+Use this method if you need to map multiple attributes (`dockerRole` +
+`dockerTeam`).
+
+1. For each Docker attribute, choose a unique Entra extension attribute
+   (`extensionAttribute1`, `extensionAttribute2`, etc.).
+1. In the **Edit Attribute** view:
+   - Set mapping type to **Direct**.
+   - Set **Source attribute** to your selected extension attribute.
+   - Set **Target attribute** to one of:
+     - `dockerRole: urn:ietf:params:scim:schemas:extension:docker:2.0:User:dockerRole`
+     - `dockerOrg: urn:ietf:params:scim:schemas:extension:docker:2.0:User:dockerOrg`
+     - `dockerTeam: urn:ietf:params:scim:schemas:extension:docker:2.0:User:dockerTeam`
+   - Set **Apply this mapping** to **Always**.
+1. Save your changes.
+
+To assign values, you'll need to use the Microsoft Graph API.
+
+### Step three: Assign users and groups
+
+For either mapping method:
+
+1. In the SCIM app, go to **Users and Groups** > **Add user/group**.
+1. Select the users or groups to provision to Docker.
+1. Select **Assign**.
+
+If you're using expression mapping:
+
+1. Go to **App registrations** > your SCIM app > **App Roles**.
+1. Create App Roles that match Docker roles.
+1. Assign users or groups to App Roles under **Users and Groups**.
+
+If you're using direct mapping:
+
+1. Go to [Microsoft Graph Explorer](https://developer.microsoft.com/en-us/graph/graph-explorer)
+   and sign in as a tenant admin.
+1. Use Microsoft Graph API to assign attribute values. Example PATCH request:
+
+```bash
+PATCH https://graph.microsoft.com/v1.0/users/{user-id}
+Content-Type: application/json
+
+{
+  "extensionAttribute1": "owner",
+  "extensionAttribute2": "moby",
+  "extensionAttribute3": "developers"
+}
+```
+
+> [!NOTE]
+>
+> You must use a different extension attribute for each SCIM field.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+See the documentation for your IdP for additional details:
+
+- [Okta](https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-add-custom-user-attributes.htm)
+- [Entra ID/Azure AD](https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/customize-application-attributes#provisioning-a-custom-extension-attribute-to-a-scim-compliant-application)
+
+## Test SCIM provisioning
+
+After completing role mapping, you can test the configuration manually.
+
+{{< tabs >}}
+{{< tab name="Okta" >}}
+
+1. In the Okta admin portal, go to **Directory > People**.
+1. Select a user you've assigned to your SCIM application.
+1. Select **Provision User**.
+1. Wait a few seconds, then check the Docker
+   **Members** in [Docker Home](https://app.docker.com).
+1. If the user doesn't appear, review logs in **Reports > System Log** and
+   confirm SCIM settings in the app.
+
+{{< /tab >}}
+{{< tab name="Entra ID/Azure AD (OIDC and SAML 2.0)" >}}
+
+1. In the Azure Portal, go to **Microsoft Entra ID** > **Enterprise Applications**,
+   and select your SCIM app.
+1. Go to **Provisioning** > **Provision on demand**.
+1. Select a user or group and choose **Provision**.
+1. Confirm that the user appears in the Docker
+   **Members** in [Docker Home](https://app.docker.com).
+1. If needed, check **Provisioning logs** for errors.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Disable SCIM
+
+If SCIM is disabled, any user provisioned through SCIM will remain in the
+organization. Future changes for your users will not sync from your IdP.
+User de-provisioning is only possible when manually removing the user from the
+organization.
+
+To disable SCIM:
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. In the **SSO connections** table, select the **Actions** icon.
+1. Select **Disable SCIM**.
+
+## Next steps
+
+- Set up [Group mapping](/manuals/enterprise/security/provisioning/scim/group-mapping.md).
+- [Troubleshoot provisioning](/manuals/enterprise/security/provisioning/troubleshoot-provisioning.md).
diff --git a/content/manuals/enterprise/security/provisioning/troubleshoot-provisioning.md b/content/manuals/enterprise/security/provisioning/troubleshoot-provisioning.md
new file mode 100644
index 000000000000..d682ac63cecf
--- /dev/null
+++ b/content/manuals/enterprise/security/provisioning/troubleshoot-provisioning.md
@@ -0,0 +1,86 @@
+---
+title: Troubleshoot provisioning
+linkTitle: Troubleshoot
+description: Troubleshoot common user provisioning issues with SCIM and Just-in-Time provisioning
+keywords: SCIM troubleshooting, user provisioning, JIT provisioning, group mapping, attribute conflicts
+tags: [Troubleshooting]
+toc_max: 2
+aliases:
+    - /enterprise/troubleshoot/troubleshoot-provisioning/
+---
+
+This page helps troubleshoot common user provisioning issues including user roles, attributes, and unexpected account behavior with SCIM and Just-in-Time (JIT) provisioning.
+
+## SCIM attribute values are overwritten or ignored
+
+### Error message
+
+Typically, this scenario does not produce an error message in Docker or your
+IdP. This issue usually surfaces as incorrect role or team assignment.
+
+### Causes
+
+- JIT provisioning is enabled, and Docker is using values from your IdP's
+  SSO sign in flow to provision the user, which overrides
+  SCIM-provided attributes.
+- SCIM was enabled after the user was already provisioned via JIT, so SCIM
+  updates don't take effect.
+
+### Affected environments
+
+- Docker organizations using SCIM with SSO
+- Users provisioned via JIT prior to SCIM setup
+
+### Steps to replicate
+
+1. Enable JIT and SSO for your Docker organization.
+1. Sign in to Docker as a user via SSO.
+1. Enable SCIM and set role/team attributes for that user.
+1. SCIM attempts to update the user's attributes, but the role or team
+   assignment does not reflect changes.
+
+### Solutions
+
+#### Disable JIT provisioning (recommended)
+
+1. Sign in to [Docker Home](https://app.docker.com/).
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. Find the relevant SSO connection.
+1. Select the **actions menu** and choose **Edit**.
+1. Disable **Just-in-Time provisioning**.
+1. Save your changes.
+
+With JIT disabled, Docker uses SCIM as the source of truth for user creation
+and role assignment.
+
+**Keep JIT enabled and match attributes**
+
+If you prefer to keep JIT enabled:
+
+- Make sure your IdP's SSO attribute mappings match the values being sent
+  by SCIM.
+- Avoid configuring SCIM to override attributes already set via JIT.
+
+This option requires strict coordination between SSO and SCIM attributes
+in your IdP configuration.
+
+## SCIM updates don't apply to existing users
+
+### Causes
+
+User accounts were originally created manually or via JIT, and SCIM is not
+linked to manage them.
+
+### Solution
+
+SCIM only manages users that it provisions. To allow SCIM to manage an
+existing user:
+
+1. Remove the user manually from [Docker Home](https://app.docker.com) under **Members**.
+1. Trigger provisioning from your IdP.
+1. SCIM will re-create the user with correct attributes.
+
+> [!WARNING]
+>
+> Deleting a user removes their resource ownership (e.g., repositories).
+> Transfer ownership before removing the user.
diff --git a/content/manuals/enterprise/security/roles-and-permissions/_index.md b/content/manuals/enterprise/security/roles-and-permissions/_index.md
new file mode 100644
index 000000000000..54d7e0239879
--- /dev/null
+++ b/content/manuals/enterprise/security/roles-and-permissions/_index.md
@@ -0,0 +1,68 @@
+---
+title: Docker organization roles and permissions
+linkTitle: Roles and permissions
+description: >-
+  Choose core or custom roles to control access to repositories, teams, and
+  organization settings
+keywords: >-
+  Docker organization roles, permissions, core roles, custom roles, Member,
+  Editor, Owner, access control, least privilege, Docker Business, security
+tags: [admin]
+aliases:
+  - /admin/organization/roles/
+  - /security/for-admins/roles-and-permissions/
+  - /docker-hub/roles-and-permissions/
+grid:
+  - title: Core roles
+    description: >-
+      Compare permissions for the built-in Member, Editor, and Owner roles.
+    icon: shield-check
+    link: /enterprise/security/roles-and-permissions/core-roles/
+  - title: Custom roles
+    description: >-
+      Build permission sets that match your organization's access control needs.
+    icon: adjustments-horizontal
+    link: /enterprise/security/roles-and-permissions/custom-roles/
+  - title: Custom roles permissions
+    description: >-
+      Review every permission you can assign to a custom role.
+    icon: list-bullet
+    link: /enterprise/security/roles-and-permissions/custom-roles/permissions-reference/
+weight: 40
+---
+
+{{< summary-bar feature_name="General admin" >}}
+
+Roles determine what members can do in your Docker organization. When you
+invite a user or create a team, you assign a role that grants permissions
+for repositories, teams, and organization settings.
+
+Docker provides two role types. Users and teams get either a core role or a
+custom role, but not both.
+
+## Core roles
+
+Core roles are Docker's built-in Member, Editor, and Owner roles. Their
+permissions are predefined. Use core roles when Docker's permission sets match
+your organization's needs.
+
+## Custom roles
+
+Custom roles are permission sets you build by selecting individual
+permissions, such as billing or team management. Use custom roles when you
+need a combination that core roles don't offer. For example, you may create a custom role for a billing
+administrator or a security auditor, or when you want to grant
+least-privilege access.
+
+Custom roles require a Docker Business subscription.
+
+## Roles and team permissions
+
+Roles apply organization-wide. Team permissions apply to specific
+repositories. The two systems work together: a user's role sets their
+organization-wide access and team membership can extend their access to
+individual repositories.
+
+## Next steps
+
+{{< grid >}}
diff --git a/content/manuals/enterprise/security/roles-and-permissions/core-roles.md b/content/manuals/enterprise/security/roles-and-permissions/core-roles.md
new file mode 100644
index 000000000000..fe2036836c77
--- /dev/null
+++ b/content/manuals/enterprise/security/roles-and-permissions/core-roles.md
@@ -0,0 +1,137 @@
+---
+title: Docker core roles and permissions
+linkTitle: Core roles
+description: >-
+  Compare Member, Editor, and Owner permissions across Docker products
+keywords: >-
+  Docker roles, core roles, Member role, Editor role, Owner role, organization
+  permissions, company owner, Docker Hub, Docker Scout, Docker Build Cloud,
+  OIDC, teams, access control, Docker Business, custom roles
+weight: 10
+---
+
+{{< summary-bar feature_name="General admin" >}}
+
+Docker organizations use built-in Member, Editor, and Owner roles with
+predefined permissions. This reference compares their permissions across
+Docker products. To assign a different combination of permissions, use
+[custom roles](/manuals/enterprise/security/roles-and-permissions/custom-roles/_index.md)
+instead.
+
+## Core roles
+
+Docker organizations have three core roles:
+
+- Owner provides full administrative access. Owners can manage all
+  organization settings, including repositories, teams, members, billing,
+  and security features.
+- Editor has partial administrative access. Editors can create, edit, and
+  delete repositories. They can also manage team permissions for
+  repositories.
+- Member has basic, non-administrative access. Members can view
+  other organization members and pull images from repositories they have
+  access to.
+
+A company owner has the same organization-management permissions as an
+organization owner. Content and registry permissions, such as repository
+pull and push, don't apply to company owners. For more information, see
+[Company overview](/manuals/admin/company/_index.md).
+
+## Permissions reference
+
+### Content and registry
+
+These permissions apply organization-wide.
+
+| Permission                                            | Member | Editor | Owner |
+| :---------------------------------------------------- | :----- | :----- | :---- |
+| Explore images and extensions                         | ✅     | ✅     | ✅    |
+| Star, favorite, vote, and comment on content          | ✅     | ✅     | ✅    |
+| Pull images                                           | ✅     | ✅     | ✅    |
+| Create and publish an extension                       | ✅     | ✅     | ✅    |
+| Become a Verified, Official, or Open Source publisher | ❌     | ❌     | ✅    |
+| Edit and delete publisher repository logos            | ❌     | ✅     | ✅    |
+| Configure DVP analytics settings                      | ❌     | ✅     | ✅    |
+| Observe content engagement as a publisher             | ❌     | ❌     | ✅    |
+| Create public and private repositories                | ❌     | ✅     | ✅    |
+| Disable public repositories                           | ❌     | ✅     | ✅    |
+| Edit and delete repositories                          | ❌     | ✅     | ✅    |
+| Manage tags                                           | ❌     | ✅     | ✅    |
+| View repository activity                              | ❌     | ❌     | ✅    |
+| Set up Automated builds                               | ❌     | ❌     | ✅    |
+| Edit build settings                                   | ❌     | ❌     | ✅    |
+| View teams                                            | ✅     | ✅     | ✅    |
+| Assign team permissions to repositories               | ❌     | ✅     | ✅    |
+| Manage OIDC connections                               | ❌     | ✅     | ✅    |
+
+You can grant repository permissions beyond a member's organization role:
+
+- Role permissions: Applied organization-wide (member or editor)
+- Team permissions: Additional permissions for specific repositories
+
+To extend access to private repositories, configure team permissions.
+Custom roles can grant organization-wide permissions to manage repositories
+(create, edit, delete) but don't grant pull access to private repositories.
+Use team permissions for that.
+
+### Organization management
+
+| Permission                                                        | Member | Editor | Owner |
+| :---------------------------------------------------------------- | :----- | :----- | :---- |
+| Create teams                                                      | ❌     | ❌     | ✅    |
+| Manage teams (including delete)                                   | ❌     | ❌     | ✅    |
+| Configure the organization's settings (including linked services) | ❌     | ❌     | ✅    |
+| Add organizations to a company                                    | ❌     | ❌     | ✅    |
+| Invite members                                                    | ❌     | ❌     | ✅    |
+| Manage members                                                    | ❌     | ❌     | ✅    |
+| Manage member roles and permissions                               | ❌     | ❌     | ✅    |
+| View member activity                                              | ❌     | ❌     | ✅    |
+| Export and reporting                                              | ❌     | ❌     | ✅    |
+| Image Access Management                                           | ❌     | ❌     | ✅    |
+| Registry Access Management                                        | ❌     | ❌     | ✅    |
+| Namespace access control                                          | ❌     | ❌     | ✅    |
+| Set up Single Sign-On (SSO) and SCIM                              | ❌     | ❌     | ✅ \* |
+| Require Docker Desktop sign-in                                    | ❌     | ❌     | ✅ \* |
+| Manage billing information (for example, billing address)         | ❌     | ❌     | ✅    |
+| Manage payment methods (for example, credit card or invoice)      | ❌     | ❌     | ✅    |
+| View billing history                                              | ❌     | ❌     | ✅    |
+| Manage subscriptions                                              | ❌     | ❌     | ✅    |
+| Manage seats                                                      | ❌     | ❌     | ✅    |
+| Upgrade and downgrade plans                                       | ❌     | ❌     | ✅    |
+
+> [!TIP]
+>
+> For more granular access control,
+> [upgrade to a Docker Business plan](https://www.docker.com/pricing?ref=Docs&refAction=DocsEnterpriseCoreRoles)
+> to use [custom roles](/manuals/enterprise/security/roles-and-permissions/custom-roles/_index.md).
+
+_\* If not part of a company_
+
+### Docker Scout
+
+| Permission                                            | Member | Editor | Owner |
+| :---------------------------------------------------- | :----- | :----- | :---- |
+| View and compare analysis results                     | ✅     | ✅     | ✅    |
+| Upload analysis records                               | ✅     | ✅     | ✅    |
+| Activate and deactivate Docker Scout for a repository | ❌     | ✅     | ✅    |
+| Create environments                                   | ❌     | ❌     | ✅    |
+| Manage registry integrations                          | ❌     | ❌     | ✅    |
+
+### Docker Build Cloud
+
+| Permission                 | Member | Editor | Owner |
+| -------------------------- | :----- | :----- | :---- |
+| Use a cloud builder        | ✅     | ✅     | ✅    |
+| Create and remove builders | ✅     | ✅     | ✅    |
+| Configure builder settings | ✅     | ✅     | ✅    |
+| Buy minutes                | ❌     | ❌     | ✅    |
+| Manage subscription        | ❌     | ❌     | ✅    |
+
+## Next steps
+
+- [Custom roles](/manuals/enterprise/security/roles-and-permissions/custom-roles/_index.md):
+  Create tailored permission sets on a Docker Business plan
+- [Manage organization members](/manuals/admin/organization/manage/members.md):
+  Invite users and assign roles
+- [Company overview](/manuals/admin/company/_index.md): Understand company
+  owner permissions versus organization owner permissions
diff --git a/content/manuals/enterprise/security/roles-and-permissions/custom-roles/_index.md b/content/manuals/enterprise/security/roles-and-permissions/custom-roles/_index.md
new file mode 100644
index 000000000000..5df1b9ac6ef5
--- /dev/null
+++ b/content/manuals/enterprise/security/roles-and-permissions/custom-roles/_index.md
@@ -0,0 +1,53 @@
+---
+title: Custom roles and permissions overview
+linkTitle: Custom roles
+description: >-
+  Use custom roles to assign tailored permissions to users and teams in
+  your Docker organization
+keywords: >-
+  custom roles, custom permissions, permission sets, access control,
+  least privilege, Docker Business, Docker Home, organization
+  management, role assignment, teams, AI Governance, Docker Offload,
+  security
+weight: 20
+grid:
+  - title: Manage custom roles
+    description: Create, edit, assign, and delete custom roles for users and teams.
+    icon: adjustments-horizontal
+    link: /enterprise/security/roles-and-permissions/custom-roles/manage/
+  - title: Permissions reference
+    description: Review every permission you can assign when building a custom role.
+    icon: list-bullet
+    link: /enterprise/security/roles-and-permissions/custom-roles/permissions-reference/
+---
+
+{{< summary-bar feature_name="Custom roles" >}}
+
+Custom roles are permission sets that you choose to grant access to users or teams based on specific use cases. Use custom roles when you need:
+
+- Specialized roles such as billing administrators, security auditors, or
+  repository managers
+- Department-specific access control
+- Least-privilege access with precise permission grants
+
+If Docker's predefined
+permission sets meet your needs, use
+[core roles](/manuals/enterprise/security/roles-and-permissions/core-roles.md)
+instead.
+
+## Prerequisites
+
+- A Docker Business subscription
+- Owner permissions in your Docker organization
+
+## Creating custom roles
+
+To create a custom role, you select permissions from organization management,
+Docker Hub, billing, AI Governance, Docker Hardened Images, and Docker
+Offload. You then assign custom roles you created to individual users or to teams.
+
+Users and teams get either a core role or a custom role, but not both.
+
+## Next steps
+
+{{< grid >}}
diff --git a/content/manuals/enterprise/security/roles-and-permissions/custom-roles/manage.md b/content/manuals/enterprise/security/roles-and-permissions/custom-roles/manage.md
new file mode 100644
index 000000000000..3dbf85e77731
--- /dev/null
+++ b/content/manuals/enterprise/security/roles-and-permissions/custom-roles/manage.md
@@ -0,0 +1,164 @@
+---
+title: Manage custom roles in Docker Home
+linkTitle: Manage
+description: >-
+  Create, edit, assign, reassign, and delete custom roles in Docker Home
+  for organization users and teams
+keywords: >-
+  custom roles, manage custom roles, role assignments, access control,
+  Docker Home, Docker Business, organization roles, permissions, teams
+weight: 10
+---
+
+{{< summary-bar feature_name="Custom roles" >}}
+
+Create custom roles, manage their permissions, and assign them to users
+and teams. Use a custom role to grant only the permissions a user or
+team needs. For a full list of permissions, see the
+[custom roles permissions reference](permissions-reference.md).
+
+## Create a custom role
+
+Before you can assign a custom role, create one:
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Roles**, then **Create role**.
+1. Define the role:
+   - Provide a **Label**
+   - Enter a unique **Name** identifier. The identifier is permanent.
+   - Add an optional **Description**
+1. Set permissions for the role by expanding permission categories and
+   selecting the checkboxes for permissions. For a full list of available
+   permissions, see the
+   [custom roles permissions reference](permissions-reference.md).
+1. Select **Review** to review the configuration and selected permissions.
+1. Select **Create**.
+
+After you create a custom role, you can
+[assign it to users or teams](#assign-custom-roles).
+
+## Edit a custom role
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Roles**.
+1. Find your custom role in the list, then select the **Actions** menu.
+1. Select **Edit**.
+1. Edit any of the following settings:
+   - **Label**
+   - **Description**
+   - **Permissions**
+1. Select **Save**.
+
+## Assign custom roles
+
+{{< tabs >}}
+{{< tab name="Individual users" >}}
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Members**.
+1. Locate the member you want to assign a custom role to, then select the
+   **Actions** menu.
+1. Select **Change role**.
+1. From the **Select a role** drop-down list, select your custom role.
+1. Select **Save**.
+
+{{< /tab >}}
+{{< tab name="Bulk users" >}}
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Members**.
+1. Use the checkboxes in the username column to select the users you want
+   to assign a custom role to.
+1. Select **Change role**.
+1. From the **Select a role** drop-down list, select your custom role or
+   a core role.
+1. Select **Save**.
+
+{{< /tab >}}
+{{< tab name="Teams" >}}
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Teams**.
+1. Locate the team you want to assign a custom role to, then select the
+   **Actions** menu.
+1. Select **Assign role**.
+1. Select your custom role, then select **Assign**.
+
+The role column updates to the newly assigned role.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## View role assignments
+
+To see which users and teams are assigned to roles:
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Roles**.
+1. In the roles list, view the **Users** and **Teams** columns for
+   assignment counts.
+1. Select a role to view its permissions and assignments in detail.
+
+## Reassign custom roles
+
+{{< tabs >}}
+{{< tab name="Individual users" >}}
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Members**.
+1. Locate the member you want to reassign, then select the **Actions**
+   menu.
+1. Select **Change role**.
+1. From the **Select a role** drop-down list, select the new role.
+1. Select **Save**.
+
+{{< /tab >}}
+{{< tab name="Bulk users" >}}
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Members**.
+1. Use the checkboxes in the username column to select the users you want
+   to reassign.
+1. Select **Change role**.
+1. From the **Select a role** drop-down list, select the new role.
+1. Select **Save**.
+
+{{< /tab >}}
+{{< tab name="Teams" >}}
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Teams**.
+1. Locate the team, then select the **Actions** menu.
+1. Select **Change role**.
+1. From the drop-down list, select a role, then select **Save**.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+## Delete a custom role
+
+> [!IMPORTANT]
+>
+> Before you delete a custom role, reassign every user and team that uses
+> it to a different role.
+
+1. Sign in to [Docker Home](https://app.docker.com).
+1. Select **Roles**.
+1. Find your custom role in the list, then select the **Actions** menu.
+1. If the role has assigned users or teams:
+   - On the **Members** page, change the role for every user assigned to
+     this custom role
+   - On the **Teams** page, reassign every team that has this custom role
+1. When no users or teams are assigned, return to **Roles**.
+1. Find your custom role and select the **Actions** menu.
+1. Select **Delete**.
+1. In the confirmation window, select **Delete** to confirm.
+
+## Next steps
+
+- [Custom roles permissions reference](permissions-reference.md): Review
+  permissions you can grant to a custom role
+- [Core roles and permissions](/manuals/enterprise/security/roles-and-permissions/core-roles.md):
+  Compare built-in Member, Editor, and Owner permissions
+- [Manage organization members](/manuals/admin/organization/manage/members.md):
+  Invite and manage users in your organization
diff --git a/content/manuals/enterprise/security/roles-and-permissions/custom-roles/permissions-reference.md b/content/manuals/enterprise/security/roles-and-permissions/custom-roles/permissions-reference.md
new file mode 100644
index 000000000000..fe210416c740
--- /dev/null
+++ b/content/manuals/enterprise/security/roles-and-permissions/custom-roles/permissions-reference.md
@@ -0,0 +1,85 @@
+---
+title: Custom role permissions reference
+linkTitle: Permissions reference
+description: >-
+  Permissions available for Docker custom roles across organization management,
+  Docker Hub, billing, AI Governance, Docker Hardened Images, and Docker
+  Offload.
+keywords: >-
+  custom roles, custom role permissions, Docker, Docker Hub, organization
+  management, billing, AI Governance, access tokens, SSO, SCIM, OIDC, DHI,
+  Docker Offload, security
+weight: 20
+---
+
+{{< summary-bar feature_name="Custom roles" >}}
+
+Custom roles use permissions from organization management, Docker Hub,
+billing, AI Governance, Docker Hardened Images, and Docker Offload. Use
+the following tables to [create or edit a custom role](manage.md).
+
+## Organization management
+
+| Permission                        | Description                                                                                     |
+| :-------------------------------- | :---------------------------------------------------------------------------------------------- |
+| View teams                        | View teams and team members                                                                     |
+| Manage teams                      | Create, update, and delete teams and team members                                               |
+| Manage registry access            | Control which registries members can access                                                     |
+| Manage image access               | Set policies for which images members can pull and use                                          |
+| Update organization information   | Update organization information such as name and location                                       |
+| Member management                 | Manage organization members, invites, and roles                                                 |
+| View custom roles                 | View existing custom roles and their permissions                                                |
+| Manage custom roles               | Full access to custom role management and assignment                                            |
+| Manage organization access tokens | Create, update, and delete repositories in this org. Push/pull or registry actions not included |
+| View activity logs                | Access organization audit logs and activity history                                             |
+| View usage reports                | Download organization usage reports (pulls, storage)                                            |
+| View domains                      | View domains and domain audit settings                                                          |
+| Manage domains                    | Manage verified domains and domain audit settings                                               |
+| View SSO and SCIM                 | View single sign-on and user provisioning configurations                                        |
+| Manage SSO and SCIM               | Full access to SSO and SCIM management                                                          |
+| Manage Desktop settings           | Configure Docker Desktop settings policies and view usage reports                               |
+| View OIDC connections             | View OIDC connections and their configuration                                                   |
+| Manage OIDC connections           | View, create, edit, and delete OIDC connections                                                 |
+
+## Docker Hub
+
+| Permission                         | Description                                                                                  |
+| :--------------------------------- | :------------------------------------------------------------------------------------------- |
+| View repositories                  | View repository details and contents                                                         |
+| Manage repositories                | Full repository management including settings, webhooks, privacy, Dockerfile, immutable tags |
+| Manage repository team permissions | Add and remove teams from a repository, and manage team access level                         |
+
+## Billing
+
+| Permission     | Description                                      |
+| :------------- | :----------------------------------------------- |
+| View billing   | View organization billing information            |
+| Manage billing | Complete access to managing organization billing |
+
+## AI Governance
+
+| Permission            | Description                                          |
+| :-------------------- | :--------------------------------------------------- |
+| View policies         | View existing AI Governance policies and their rules |
+| Manage policies       | Full access to AI Governance policy management       |
+| View audit logs       | View audit events for the organization               |
+| Manage audit settings | Update audit configuration for the organization      |
+
+## DHI (Docker Hardened Images)
+
+| Permission         | Description                                      |
+| :----------------- | :----------------------------------------------- |
+| Create DHI mirrors | Create Docker Hardened Image mirror repositories |
+
+## Docker Offload
+
+| Permission        | Description                                    |
+| :---------------- | :--------------------------------------------- |
+| Offload Read-Only | View Offload account status, leases, and zones |
+
+## Next steps
+
+- [Manage custom roles](manage.md): Create, assign, and delete custom
+  roles
+- [Core roles and permissions](/manuals/enterprise/security/roles-and-permissions/core-roles.md):
+  Compare built-in Member, Editor, and Owner permissions
diff --git a/content/manuals/enterprise/security/single-sign-on/FAQs/_index.md b/content/manuals/enterprise/security/single-sign-on/FAQs/_index.md
new file mode 100644
index 000000000000..224304008d4e
--- /dev/null
+++ b/content/manuals/enterprise/security/single-sign-on/FAQs/_index.md
@@ -0,0 +1,6 @@
+---
+build:
+  render: never
+title: FAQs
+weight: 50
+---
\ No newline at end of file
diff --git a/content/manuals/enterprise/security/single-sign-on/FAQs/domain-faqs.md b/content/manuals/enterprise/security/single-sign-on/FAQs/domain-faqs.md
new file mode 100644
index 000000000000..ace6b06cad66
--- /dev/null
+++ b/content/manuals/enterprise/security/single-sign-on/FAQs/domain-faqs.md
@@ -0,0 +1,23 @@
+---
+title: SSO domain FAQs
+linkTitle: Domains
+description: Frequently asked questions about domain verification and management for Docker single sign-on
+keywords: SSO domains, domain verification, DNS, TXT records, single sign-on
+tags: [FAQ]
+aliases:
+- /single-sign-on/domain-faqs/
+- /faq/security/single-sign-on/domain-faqs/
+- /security/faqs/single-sign-on/domain-faqs/
+---
+
+## Can I add sub-domains?
+
+Yes, you can add sub-domains to your SSO connection. All email addresses must use domains you've added to the connection. Verify that your DNS provider supports multiple TXT records for the same domain.
+
+## Do I need to keep the DNS TXT record permanently?
+
+You can remove the TXT record after one-time verification to add the domain. However, if your organization changes identity providers and needs to set up SSO again, you'll need to verify the domain again.
+
+## Can I verify the same domain for multiple organizations?
+
+You can't verify the same domain for multiple organizations at the organization level. To verify one domain for multiple organizations, you must have a Docker Business subscription and create a company. Companies allow centralized management of organizations and domain verification at the company level.
diff --git a/content/manuals/enterprise/security/single-sign-on/FAQs/enforcement-faqs.md b/content/manuals/enterprise/security/single-sign-on/FAQs/enforcement-faqs.md
new file mode 100644
index 000000000000..39e87fbb471c
--- /dev/null
+++ b/content/manuals/enterprise/security/single-sign-on/FAQs/enforcement-faqs.md
@@ -0,0 +1,42 @@
+---
+title: SSO enforcement FAQs
+linkTitle: Enforcement
+description: Frequently asked questions about Docker single sign-on enforcement and its effects on users
+keywords: SSO enforcement, single sign-on, personal access tokens, CLI authentication, guest users
+tags: [FAQ]
+aliases:
+  - /single-sign-on/enforcement-faqs/
+  - /faq/security/single-sign-on/enforcement-faqs/
+  - /security/faqs/single-sign-on/enforcement-faqs/
+---
+
+## Does Docker SSO support authenticating through the command line?
+
+When SSO is enforced, [passwords are prevented from accessing the Docker CLI](/manuals/security/security-announcements.md#deprecation-of-password-logins-on-cli-when-sso-enforced). You must use a personal access token (PAT) for CLI authentication instead.
+
+Each user must create a PAT to access the CLI. To learn how to create a PAT, see [Manage personal access tokens](/manuals/security/access-tokens.md). Users who already used a PAT before SSO enforcement can continue using that PAT.
+
+## How does SSO affect automation systems and CI/CD pipelines?
+
+Before enforcing SSO, you must [create personal access tokens](/manuals/security/access-tokens.md) to replace passwords in automation systems and CI/CD pipelines.
+
+## Can I turn on SSO without enforcing it immediately?
+
+Yes, you can turn on SSO without enforcement. Users can choose between Docker ID (standard email and password) or domain-verified email address (SSO) at the sign-in screen.
+
+## SSO is enforced, but a user can sign in using a username and password. Why is this happening?
+
+Guest users who aren't part of your registered domain but have been invited to your organization don't sign in through your SSO identity provider. SSO enforcement only applies to users who belong to your verified domain.
+
+## Can I test SSO functionality before going to production?
+
+Yes, you can create a test organization with a 5-seat Business subscription. When testing, turn on SSO but don't enforce it, or all domain email users will be forced to sign in to the test environment.
+
+## What is enforcing SSO versus enforcing sign-in?
+
+These are separate features you can use independently or together:
+
+- Enforcing SSO ensures users sign in using SSO credentials instead of their Docker ID, enabling better credential management.
+- Enforcing sign-in to Docker Desktop ensures users always sign in to accounts that are members of your organization, so security settings and subscription benefits are always applied.
+
+For more details, see [Enforce sign-in for Desktop](/manuals/enterprise/security/enforce-sign-in/_index.md#enforcing-sign-in-versus-enforcing-single-sign-on-sso).
diff --git a/content/manuals/enterprise/security/single-sign-on/FAQs/general.md b/content/manuals/enterprise/security/single-sign-on/FAQs/general.md
new file mode 100644
index 000000000000..ce25481d4df8
--- /dev/null
+++ b/content/manuals/enterprise/security/single-sign-on/FAQs/general.md
@@ -0,0 +1,35 @@
+---
+description: Frequently asked questions about Docker single sign-on
+keywords: Docker, Docker Hub, SSO FAQs, single sign-on, administration, security
+title: General SSO FAQs
+linkTitle: General
+weight: 20
+tags: [FAQ]
+aliases:
+- /single-sign-on/faqs/
+- /faq/security/single-sign-on/faqs/
+- /single-sign-on/saml-faqs/
+- /faq/security/single-sign-on/saml-faqs/
+- /security/faqs/single-sign-on/saml-faqs/
+- /security/faqs/single-sign-on/faqs/
+---
+
+## What SSO flows does Docker support?
+
+Docker supports Service Provider Initiated (SP-initiated) SSO flow. Users must sign in to Docker Hub or Docker Desktop to initiate the SSO authentication process.
+
+## Does Docker SSO support multi-factor authentication?
+
+When an organization uses SSO, multi-factor authentication is controlled at the identity provider level, not on the Docker platform.
+
+## Can I retain my Docker ID when using SSO?
+
+Users with personal Docker IDs retain ownership of their repositories, images, and assets. When SSO is enforced, existing accounts with company domain emails are connected to the organization. Users signing in without existing accounts automatically have new accounts and Docker IDs created.
+
+## Are there any firewall rules required for SSO configuration?
+
+No specific firewall rules are required as long as `login.docker.com` is accessible. This domain is commonly accessible by default, but some organizations may need to allow it in their firewall settings if SSO setup encounters issues.
+
+## Does Docker use my IdP's default session timeout?
+
+Yes, Docker supports your IdP's session timeout using a custom `dockerSessionMinutes` SAML attribute instead of the standard `SessionNotOnOrAfter` element. See [SSO attributes](/manuals/enterprise/security/provisioning/_index.md#sso-attributes) for more information.
diff --git a/content/manuals/enterprise/security/single-sign-on/FAQs/idp-faqs.md b/content/manuals/enterprise/security/single-sign-on/FAQs/idp-faqs.md
new file mode 100644
index 000000000000..9559a972da18
--- /dev/null
+++ b/content/manuals/enterprise/security/single-sign-on/FAQs/idp-faqs.md
@@ -0,0 +1,53 @@
+---
+title: SSO identity provider FAQs
+linkTitle: Identity providers
+description: Frequently asked questions about Docker SSO and identity provider configuration
+keywords: identity providers, SSO IdP, SAML, Azure AD, Entra ID, certificate management
+tags: [FAQ]
+aliases:
+  - /single-sign-on/idp-faqs/
+  - /faq/security/single-sign-on/idp-faqs/
+  - /security/faqs/single-sign-on/idp-faqs/
+---
+
+## Can I use multiple identity providers with Docker SSO?
+
+Yes, Docker supports multiple IdP configurations. A domain can be associated with multiple IdPs. Docker supports Entra ID (formerly Azure AD) and identity providers that support SAML 2.0.
+
+## Can I change my identity provider after configuring SSO?
+
+Yes. Delete your existing IdP configuration in your Docker SSO connection, then [configure SSO using your new IdP](/manuals/enterprise/security/single-sign-on/connect.md). If you had already turned on enforcement, turn off enforcement before updating the provider connection.
+
+## What information do I need from my identity provider to configure SSO?
+
+To turn on SSO in Docker, you need the following from your IdP:
+
+- SAML: Entity ID, ACS URL, Single Logout URL, and the public X.509 certificate
+- Entra ID (formerly Azure AD): Client ID, Client Secret, AD Domain
+
+## What happens if my existing certificate expires?
+
+Contact your identity provider to retrieve a new X.509 certificate. Update with the new certificate in [SSO configuration settings](/manuals/enterprise/security/single-sign-on/manage.md#manage-sso-connections) from Docker Home.
+
+- If your organization enforces SSO, username and password credentials won't work.
+- If your organization doesn't enforce SSO, users can sign in with their username and password credentials.
+
+If you need additional help, contact [Docker support](https://app.docker.com/support/contact).
+
+## What happens if my IdP goes down when SSO is turned on?
+
+If SSO is enforced, users can't access Docker Hub when your IdP is down. Users can still access Docker Hub images from the CLI using personal access tokens.
+
+If SSO is turned on but not enforced, users can fall back to username/password authentication.
+
+## Do bot accounts need seats to access organizations using SSO?
+
+Yes, bot accounts need seats like regular users, requiring a non-aliased domain email in the IdP and using a seat in Docker Hub. You can add bot accounts to your IdP and create access tokens to replace other credentials.
+
+## Does SAML SSO use Just-in-Time provisioning?
+
+The SSO implementation uses Just-in-Time (JIT) provisioning by default. You can optionally turn off JIT in Docker Home if you turn on auto-provisioning using SCIM. See [Just-in-Time provisioning](/manuals/enterprise/security/provisioning/just-in-time.md).
+
+## My Entra ID SSO connection isn't working and shows an error. How can I troubleshoot this?
+
+Confirm that you've configured the necessary API permissions in Entra ID for your SSO connection. You need to grant administrator consent within your Entra ID tenant. See [Entra ID (formerly Azure AD) documentation](https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent?pivots=portal#grant-admin-consent-in-app-registrations).
diff --git a/content/manuals/enterprise/security/single-sign-on/FAQs/users-faqs.md b/content/manuals/enterprise/security/single-sign-on/FAQs/users-faqs.md
new file mode 100644
index 000000000000..a89bbe4ca5f8
--- /dev/null
+++ b/content/manuals/enterprise/security/single-sign-on/FAQs/users-faqs.md
@@ -0,0 +1,62 @@
+---
+title: SSO user management FAQs
+linkTitle: User management
+description: Frequently asked questions about managing users with Docker single sign-ons
+keywords: SSO user management, user provisioning, SCIM, just-in-time provisioning, organization members
+tags: [FAQ]
+aliases:
+  - /single-sign-on/users-faqs/
+  - /faq/security/single-sign-on/users-faqs/
+  - /security/faqs/single-sign-on/users-faqs/
+---
+
+## Do I need to manually add users to my organization?
+
+No, you don't need to manually add users to your organization. Just ensure user accounts exist in your IdP. When users sign in to Docker with their domain email address, they're automatically added to the organization after successful authentication.
+
+## Can users use different email addresses to authenticate through SSO?
+
+All users must authenticate using the email domain specified during SSO setup. Users with email addresses that don't match the verified domain can sign in as guests with username and password if SSO isn't enforced, but only if they've been invited.
+
+## How will users know they're being added to a Docker organization?
+
+When SSO is turned on, users are prompted to authenticate through SSO the next time they sign in to Docker Hub or Docker Desktop. The system detects their domain email and prompts them to sign in with SSO credentials instead.
+
+For CLI access, users must authenticate using personal access tokens.
+
+## Can I convert existing users from non-SSO to SSO accounts?
+
+Yes, you can convert existing users to SSO accounts. Ensure users have:
+
+- Company domain email addresses and accounts in your IdP
+- Docker Desktop version 4.4.2 or later
+- Personal access tokens created to replace passwords for CLI access
+- CI/CD pipelines updated to use PATs instead of passwords
+
+For detailed instructions, see [Configure single sign-on](/manuals/enterprise/security/single-sign-on/connect.md).
+
+## Is Docker SSO fully synced with the IdP?
+
+Docker SSO provides Just-in-Time (JIT) provisioning by default. Users are provisioned when they authenticate with SSO. If users leave the organization, administrators must manually [remove the user](/manuals/admin/organization/manage/members.md#remove-members-from-teams) from the organization.
+
+[SCIM](/manuals/enterprise/security/provisioning/scim/_index.md) provides full synchronization with users and groups. When using SCIM, the recommended configuration is to turn off JIT so all auto-provisioning is handled by SCIM.
+
+Additionally, you can use the [Docker Hub API](/reference/api/hub/latest.md) to complete this process.
+
+## How does turning off Just-in-Time provisioning affect user sign-in?
+
+When JIT is turned off (available with SCIM in Docker Home), users must be organization members or have pending invitations to access Docker. Users who don't meet these criteria get an "Access denied" error and need administrator invitations.
+
+See [SSO authentication with JIT provisioning disabled](/manuals/enterprise/security/provisioning/just-in-time.md#sso-authentication-with-jit-provisioning-disabled).
+
+## Can someone join an organization without an invitation?
+
+Not without SSO. Joining requires an invite from an organization owner. When SSO is enforced, users with verified domain emails can automatically join the organization when they sign in.
+
+## What happens to existing licensed users when SCIM is turned on?
+
+Turning on SCIM doesn't immediately remove or modify existing licensed users. They retain current access and roles, but you'll manage them through your IdP after SCIM is active. If SCIM is later turned off, previously SCIM-managed users remain in Docker but are no longer automatically updated based on your IdP.
+
+## Is user information visible in Docker Hub?
+
+All Docker accounts have public profiles associated with their namespace. If you don't want user information (like full names) to be visible, remove those attributes from your SSO and SCIM mappings, or use different identifiers to replace users' full names.
diff --git a/content/manuals/enterprise/security/single-sign-on/_index.md b/content/manuals/enterprise/security/single-sign-on/_index.md
new file mode 100644
index 000000000000..c7cfa70db0b7
--- /dev/null
+++ b/content/manuals/enterprise/security/single-sign-on/_index.md
@@ -0,0 +1,59 @@
+---
+title: Single sign-on overview
+linkTitle: Single sign-on
+description: Learn how single sign-on works, how to set it up, and the required SSO attributes.
+keywords: Single Sign-On, SSO, sign-in, admin, docker hub, docker home, security, identity provider, SSO configuration, enterprise login, Docker Business, user authentication
+aliases:
+  - /single-sign-on/
+  - /admin/company/settings/sso/
+  - /admin/organization/security-settings/sso-management/
+  - /security/for-admins/single-sign-on/
+weight: 10
+---
+
+{{< summary-bar feature_name="SSO" >}}
+
+Single sign-on (SSO) lets users access Docker by authenticating through their
+identity providers (IdPs). SSO can be configured for an entire company,
+including all associated organizations, or for a single organization that has a
+Docker Business subscription.
+
+## How SSO works
+
+When SSO is enabled, Docker supports a non-IdP-initiated flow for user sign-in.
+Instead of signing in with a Docker username and password, users are redirected
+to your IdP’s sign-in page. Users must initiate the SSO authentication process
+by signing in to Docker Hub or Docker Desktop.
+
+The following diagram illustrates how SSO operates and is managed between
+Docker Hub, Docker Desktop, and your IdP.
+
+![SSO architecture](images/SSO.png)
+
+## Set up SSO
+
+To configure SSO in Docker, follow these steps:
+
+1. [Configure your domain](connect.md) by creating and verifying it.
+1. [Create your SSO connection](connect.md) in Docker and your IdP.
+1. Link Docker to your identity provider.
+1. Test your SSO connection.
+1. Provision users in Docker.
+1. Optional. [Enforce sign-in](../enforce-sign-in/_index.md).
+1. [Manage your SSO configuration](manage.md).
+
+Once configuration is complete, users can sign in to Docker services using
+their company email address. After signing in, users are added to your company,
+assigned to an organization, and added to a team.
+
+> [!IMPORTANT]
+>
+> When SSO is enforced, CLI password-based sign-in is no longer supported.
+> Use a personal access token (PAT) for CLI access. For more information, see the
+> [security announcement](/manuals/security/security-announcements.md#deprecation-of-password-logins-on-cli-when-sso-enforced).
+
+## Next steps
+
+- Start [configuring SSO](connect.md).
+- Read the [FAQs](/manuals/enterprise/security/single-sign-on/FAQs/general.md).
+- [Troubleshoot](/manuals/enterprise/security/single-sign-on/troubleshoot-sso.md) SSO issues.
diff --git a/content/manuals/enterprise/security/single-sign-on/connect.md b/content/manuals/enterprise/security/single-sign-on/connect.md
new file mode 100644
index 000000000000..52630a29786f
--- /dev/null
+++ b/content/manuals/enterprise/security/single-sign-on/connect.md
@@ -0,0 +1,262 @@
+---
+title: Set up single sign-on
+linkTitle: Setup
+weight: 20
+description: Connect Docker and your identity provider, test the setup, and enable enforcement
+keywords: configure sso, set up sso, docker sso setup, docker identity provider, sso enforcement, docker hub, security
+aliases:
+  - /security/for-admins/single-sign-on/connect/
+  - /docker-hub/domains/
+  - /docker-hub/sso-connection/
+  - /docker-hub/enforcing-sso/
+  - /single-sign-on/configure/
+  - /admin/company/settings/sso-configuration/
+  - /admin/organization/security-settings/sso-configuration/
+  - /security/for-admins/single-sign-on/configure/
+  - /enterprise/security/single-sign-on/configure
+---
+
+{{< summary-bar feature_name="SSO" >}}
+
+To set up a single sign-on (SSO), you need to establish a connection between Docker
+and your identity provider (IdP). While this guide
+uses Okta and Microsoft Entra ID as a working example, the general process remains the same for other IdPs.
+
+If you're unfamiliar with the SSO process, first review [SSO overview](/manuals/enterprise/security/single-sign-on/_index.md) to learn about how SSO works.
+
+## Prerequisites
+
+Docker supports any SAML 2.0 or OIDC-compatible identity provider. Before you begin, make sure the following conditions are met:
+
+- Notify your company about the upcoming SSO sign-in process.
+- Confirm that each Docker user has a valid IdP account using the same
+  email address as their Unique Primary Identifier (UPN).
+- Ensure CI/CD pipelines use PATs or OATs instead of passwords.
+
+## Set up an SSO connection
+
+> [!TIP]
+> These procedures have you copy and paste values between Docker and your IdP. Complete this guide in one session with separate browser windows open for Docker and your IdP.
+
+### Step 1: Add a domain
+
+To add a domain:
+
+1. Sign in to [app.docker.com](https://app.docker.com), then choose your
+   organization. If your organization is part of a company, then select the company to manage
+   the domain at the company level.
+1. Select **Identity & auth**, then **Domain management**.
+1. Select **Add a domain**.
+1. Enter your domain in the text box and select **Add domain**.
+1. In the modal, copy the **TXT Record Value** provided for domain verification.
+
+### Step 2: Verify your domain
+
+To confirm domain ownership, add a TXT record to your Domain Name System (DNS)
+host using the TXT Record Value from Docker. DNS propagation can take up to
+72 hours. Docker automatically checks for the record during this time.
+
+> [!TIP]
+>
+> When adding a record name, use `@` or leave it empty for root domains like `example.com`. Avoid common values like `docker`, `docker-verification`, `www`, or your domain name itself. Always check your DNS provider's documentation to verify their specific record name requirements.
+
+{{< tabs >}}
+{{< tab name="AWS Route 53" >}}
+
+1. To add your TXT record to AWS, see [Creating records by using the Amazon Route 53 console](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html).
+1. Wait up to 72 hours for TXT record verification.
+1. After the record is live, go to **Identity & auth**, then **Domain management**, and select **Verify**.
+
+{{< /tab >}}
+{{< tab name="Google Cloud DNS" >}}
+
+1. To add your TXT record to Google Cloud DNS, see [Verifying your domain with a TXT record](https://cloud.google.com/identity/docs/verify-domain-txt).
+1. Wait up to 72 hours for TXT record verification.
+1. After the record is live, go to **Identity & auth**, then **Domain management**, and select **Verify**.
+
+{{< /tab >}}
+{{< tab name="GoDaddy" >}}
+
+1. To add your TXT record to GoDaddy, see [Add a TXT record](https://www.godaddy.com/help/add-a-txt-record-19232).
+1. Wait up to 72 hours for TXT record verification.
+1. After the record is live, go to **Identity & auth**, then **Domain management**, and select **Verify**.
+
+{{< /tab >}}
+{{< tab name="Other providers" >}}
+
+1. Sign in to your domain host.
+1. Add a TXT record to your DNS settings and save the record.
+1. Wait up to 72 hours for TXT record verification.
+1. After the record is live, go to **Identity & auth**, then **Domain management**, and select **Verify**.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Step 3: Create an SSO connection in Docker
+
+1. From [app.docker.com](https://app.docker.com), choose your
+   organization.
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. Select **Create Connection**. Name the connection, then choose **SAML 2.0**.
+1. Keep this window open. You need to copy and paste these values in your Okta window:
+   - **Entity ID**
+   - **ACS URL**
+   - **Connection ID**
+
+You will return here to finish connecting after creating an SSO connection in your IdP.
+
+### Step 4: Create an SSO connection in your IdP
+
+Use the following tabs based on your IdP provider.
+
+{{< tabs >}}
+{{< tab name="Okta SAML" >}}
+
+You need [super admin permissions](https://help.okta.com/en-us/content/topics/security/administrators-super-admin.htm) for the Okta org.
+
+1. Sign in to your Okta Admin account. From the top nav, select the **Admin** button to go to Okta's Admin Console.
+1. From the **Applications** section in the left nav, choose **Applications**. Select **Create App Integration**.
+1. Choose SAML 2.0 to match your selection from Docker Home.
+1. For **General Settings**, name your app "Docker." Uploading a logo is optional.
+1. For **Configure SAML**, input the following values:
+   - For the **Single Sign On URL** value, paste the Docker ACS URL.
+   - For the **Audience URI (SP Entity ID)** value, paste the Docker Entity ID.
+   - For **Name ID format**, choose `EmailAddress`
+   - For **Application username**, choose `Email`
+   - For **Update application username on**, choose `Create and update`
+   - Optional. Add [SAML attributes](/manuals/enterprise/security/provisioning/_index.md#sso-attributes), if required by your org.
+1. For **Feedback**, choose **This is an internal app that we have created** checkbox before finishing.
+
+Keep your Okta window open for the next step.
+
+{{< /tab >}}
+{{< tab name="Entra ID SAML 2.0" >}}
+
+To enable SSO with Microsoft Entra, you need [Cloud Application Administrator](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#cloud-application-administrator) permissions.
+
+1. From Microsoft Entra admin center, select **Entra ID**, then go to **Enterprise apps**. Select **All applications**.
+1. Choose **Create your own application** and name your app "Docker". Select **Non-gallery**.
+1. After creating your app, go to **Single Sign-On** and select **SAML**.
+1. Select **Edit** on the **Basic SAML configuration** section. From **Basic SAML configuration**, choose **Edit** and paste the values you copied from creating an SSO connection in Docker:
+   - For the **Identifier** value, paste the Docker Entity ID.
+   - For the **Reply URL** value, paste Docker ACS URL.
+1. Optional. Add [SAML attributes](/manuals/enterprise/security/provisioning/_index.md#sso-attributes), if required by your org.
+1. From the **SAML Signing Certificate** section, download your **Certificate (Base64)**.
+
+{{< /tab >}}
+{{< tab name="Azure OpenID Connect (OIDC)" >}}
+
+#### Register the app
+
+1. Sign in to [Microsoft Entra admin center](https://entra.microsoft.com/).
+1. Go to **App Registration** and select **New Registration**.
+1. Name the application "Docker".
+1. Set account types and paste the **Redirect URI** from Docker.
+1. Select **Register**.
+1. Copy the **Client ID**.
+
+#### Create client secrets
+
+1. In your app, go to **Certificates & secrets**.
+1. Select **New client secret**, describe and configure duration, then **Add**.
+1. Copy the **value** of the new secret.
+
+#### Set API permissions
+
+1. In your app, go to **API permissions**.
+1. Select **Grant admin consent** and confirm.
+1. Select **Add a permissions** > **Delegated permissions**.
+1. Search and select `User.Read`.
+1. Confirm that admin consent is granted.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Step 5: Connect Docker to your IdP
+
+Complete the integration by pasting your IdP values into Docker.
+
+> [!IMPORTANT]
+> When prompted to copy a certificate, copy the entire certificate starting with
+> `----BEGIN CERTIFICATE----` and including the `----END CERTIFICATE----` lines.
+
+{{< tabs >}}
+{{< tab name="Okta SAML" >}}
+
+1. Go to **Applications** and choose **Applications**. Choose your app from the **ACTIVE** table.
+1. From **Sign on**, go to **View SAML setup instructions**. This page contains the **SAML Sign-in URL** and **x509 Certificate**. Keep this page open.
+1. Return to your opened Docker window for the **Create single sign-on connection** step. Paste in the **SAML Sign-in URL** and **x509 Certificate** values.
+1. Optional. Select a default team, if required by your org.
+1. Review and select **Create connection**.
+
+{{< /tab >}}
+{{< tab name="Entra ID SAML 2.0" >}}
+
+1. Open your downloaded **Certificate (Base64)** in a text editor.
+1. Copy the following values:
+   - From Azure AD: **Login URL**
+   - **Certificate (Base64)** contents
+1. Return to Docker Home, then paste the **Login URL** and **Certificate (Base64)** values.
+1. Choose your domain from the drop-down.
+1. Optional. Select a default team, if required by your org.
+1. Review and select **Create connection**.
+
+{{< /tab >}}
+{{< tab name="Azure OpenID Connect (OIDC)" >}}
+
+1. Return to Docker Home.
+1. Paste the following values:
+   - **Client ID**
+   - **Client Secret**
+   - **Azure AD Domain**
+1. Optional. Select a default team, if required by your org.
+1. Review and select **Create connection**.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Step 6: Test the connection
+
+IdPs like Microsoft Entra and Okta may require that you assign a user to an application before testing SSO. You can review [Microsoft Entra](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/add-application-portal-setup-sso#test-single-sign-on)'s documentation and [Okta](https://help.okta.com/wf/en-us/content/topics/workflows/connector-reference/okta/actions/assignusertoapplicationforsso.htm)'s documentation to learn how to assign yourself or other users to an app.
+
+After assigning yourself to an app:
+
+1. Open an incognito browser window and sign in to Docker Home using your domain email address.
+1. When redirected to your IdP's sign in page, authenticate with your domain email instead of using your Docker ID.
+
+If you have multiple IdPs, choose the sign-in option **Continue with SSO**. If you're using the CLI, you must authenticate using a personal access token.
+
+## Configure multiple IdPs
+
+Docker supports multiple identity provider (IdP) configurations by letting you associate one domain with more than one IdP. Each connection must use the same domain, which lets users choose their IdP when they select **Continue with SSO** at sign in.
+
+To add multiple IdPs:
+
+1. Use the same domain for each connection.
+1. Repeat steps 3-6 from the [Set up an SSO connection](/manuals/enterprise/security/single-sign-on/connect.md#set-up-an-sso-connection) procedures on this page. Repeat these steps for each IdP your organization intends to use.
+
+Because you must use the same domain for each IdP, you won't need to repeat steps to add and verify your domains.
+
+## Enforce SSO
+
+If SSO is not enforced, users can still sign in using Docker usernames and passwords. Enforcing SSO requires users to use SSO when signing into Docker, which centralizes authentication and enforces policies set by the IdP.
+
+Before enforcing SSO, users accessing Docker through the CLI must [create a personal access token (PAT)](/manuals/security/access-tokens.md). The PAT replaces their username and password for authentication.
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select
+   your organization or company.
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. In the SSO connections table, select the **Action** menu, then **Enable enforcement**.
+1. Follow the on-screen instructions.
+1. Select **Turn on enforcement**.
+
+When you enforce SSO, your users cannot modify their email address and
+password, convert a user account to an organization, or set up 2FA through
+Docker Hub. If you want to use 2FA, you must enable 2FA through your IdP.
+
+## Next steps
+
+- [Provision users](/manuals/enterprise/security/provisioning/_index.md).
+- [Enforce sign-in](../enforce-sign-in/_index.md).
+- [Create personal access tokens](/manuals/security/access-tokens.md).
+- [Troubleshoot SSO](/manuals/enterprise/security/single-sign-on/troubleshoot-sso.md) issues.
diff --git a/content/manuals/security/for-admins/single-sign-on/images/SSO.png b/content/manuals/enterprise/security/single-sign-on/images/SSO.png
similarity index 100%
rename from content/manuals/security/for-admins/single-sign-on/images/SSO.png
rename to content/manuals/enterprise/security/single-sign-on/images/SSO.png
diff --git a/content/manuals/enterprise/security/single-sign-on/manage.md b/content/manuals/enterprise/security/single-sign-on/manage.md
new file mode 100644
index 000000000000..c5f71844e459
--- /dev/null
+++ b/content/manuals/enterprise/security/single-sign-on/manage.md
@@ -0,0 +1,134 @@
+---
+title: Manage SSO domains and connections
+linkTitle: Manage connections
+weight: 30
+description: Learn how to manage Single Sign-On for your organization or company.
+keywords: manage, single sign-on, SSO, sign-on, docker home, admin, security, domains, connections, users, provisioning
+aliases:
+- /admin/company/settings/sso-management/
+- /single-sign-on/manage/
+- /security/for-admins/single-sign-on/manage/
+---
+
+{{< summary-bar feature_name="SSO" >}}
+
+This page covers how to manage single sign-on (SSO) after initial setup,
+including managing domains, connections, users, and provisioning
+settings.
+
+## Manage domains
+
+### Add a domain
+
+To add a domain to an existing SSO connection:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your company or
+organization from the top-left account drop-down.
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. In the SSO connections table, select the **Actions** menu for your
+connection, then select **Edit connection**.
+1. Select **Next** to navigate to the domains section.
+1. In the **Domains** section, select **Add domain**.
+1. Enter the domain you want to add to the connection.
+1. Select **Next** to confirm or change the connected organizations.
+1. Select **Next** to confirm or change the default organization and
+team provisioning selections.
+1. Review the connection details and select **Update connection**.
+
+### Remove a domain from an SSO connection
+
+> [!IMPORTANT]
+>
+> If you use multiple identity providers with the same domain, you must remove the domain from each SSO connection individually.
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your company or organization from the top-left account drop-down.
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. In the **SSO connections** table, select the **Actions** menu for your connection, then
+**Edit connection**.
+1. Select **Next** to navigate to the domains section.
+1. In the **Domain** section, select the **X** icon next to the domain
+you want to remove.
+1. Select **Next** to confirm or change the connected organizations.
+1. Select **Next** to confirm or change the default organization and
+team provisioning selections.
+1. Review the connection details and select **Update connection**.
+
+> [!NOTE]
+>
+> When you re-add a domain, Docker assigns a new TXT record value. You must complete domain verification again with the new TXT record.
+
+## Manage SSO connections
+
+### View connections
+
+To view all configured SSO connections:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your company or organization from the top-left account drop-down.
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. View all configured connections in the **SSO connections** table.
+
+### Edit a connection
+
+To modify an existing SSO connection:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your company or organization from the top-left account drop-down.
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. In the **SSO connections** table, select the **Actions** menu for your connection, then
+**Edit connection**.
+1. Follow the on-screen instructions to modify your connection settings.
+
+### Delete a connection
+
+To remove an SSO connection:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your company or organization from the top-left account drop-down.
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. In the **SSO connections** table, select the **Actions** menu for your connection, then
+**Delete connection**.
+1. Follow the on-screen instructions to confirm the deletion.
+
+> [!WARNING]
+>
+> Deleting an SSO connection removes access for all users who authenticate through
+that connection.
+
+## Manage users and provisioning
+
+Docker automatically provisions users through Just-in-Time (JIT) provisioning when they sign in via SSO. You can also manually manage users and configure different provisioning methods.
+
+### How provisioning works
+
+Docker supports the following provisioning methods:
+
+- JIT provisioning (default): Users are automatically added to your organization
+when they sign in via SSO
+- SCIM provisioning: Sync users and groups from your identity provider to Docker
+- Group mapping: Sync user groups from your identity provider with teams in your Docker organization
+- Manual provisioning: Turn off automatic provisioning and manually invite users
+
+For more information on provisioning methods, see [Provision users](/manuals/enterprise/security/provisioning/_index.md).
+
+### Add guest users
+
+To invite users who don't authenticate through your identity provider:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select
+your organization.
+1. Select **Members**.
+1. Select **Invite**.
+1. Follow the on-screen instructions to invite the user.
+
+The user receives an email invitation and can create a Docker account or sign
+in with their existing account.
+
+### Remove users
+
+To remove a user from your organization:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select
+your organization.
+1. Select **Members**.
+1. Find the user you want to remove and select the **Actions** menu next to their name.
+1. Select **Remove** and confirm the removal.
+
+The user loses access to your organization immediately upon removal.
diff --git a/content/manuals/enterprise/security/single-sign-on/troubleshoot-sso.md b/content/manuals/enterprise/security/single-sign-on/troubleshoot-sso.md
new file mode 100644
index 000000000000..ebd616e7f6c4
--- /dev/null
+++ b/content/manuals/enterprise/security/single-sign-on/troubleshoot-sso.md
@@ -0,0 +1,246 @@
+---
+title: Troubleshoot single sign-on
+linkTitle: Troubleshoot
+description: Troubleshoot common Docker single sign-on configuration and authentication issues
+weight: 40
+keywords: sso troubleshooting, single sign-on errors, authentication issues, identity provider problems
+tags: [Troubleshooting]
+toc_max: 2
+aliases:
+  - /security/for-admins/single-sign-on/troubleshoot/
+  - /security/troubleshoot/troubleshoot-sso/
+  - /enterprise/troubleshoot/troubleshoot-sso/
+---
+
+This page describes common single sign-on (SSO) errors and their solutions. Issues can stem from your identity provider (IdP) configuration or Docker settings.
+
+## Check for errors
+
+If you experience SSO issues, check both Docker and your identity provider for errors first.
+
+### Check Docker error logs
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your organization from the top-left account drop-down.
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. In the SSO connections table, select the **Action** menu and then **View error logs**.
+1. For more details on specific errors, select **View error details** next to an error message.
+1. Note any errors you see on this page for further troubleshooting.
+
+### Check identity provider errors
+
+1. Review your IdP’s logs or audit trails for any failed authentication or provisioning attempts.
+2. Confirm that your IdP’s SSO settings match the values provided in Docker.
+3. If applicable, confirm that you have configured user provisioning correctly and that it is enabled in your IdP.
+4. If applicable, verify that your IdP correctly maps Docker's required user attributes.
+5. Try provisioning a test user from your IdP and verify if they appear in Docker.
+
+For further troubleshooting, check your IdP's documentation or contact their support team.
+
+## Groups are not formatted correctly
+
+### Error message
+
+When this issue occurs, the following error message is common:
+
+```text
+Some of the groups assigned to the user are not formatted as '<organization name>:<team name>'. Directory groups will be ignored and user will be provisioned into the default organization and team.
+```
+
+### Causes
+
+- Incorrect group name formatting in your identity provider (IdP): Docker requires groups to follow the format `<organization>:<team>`. If the groups assigned to a user do not follow this format, they will be ignored.
+- Non-matching groups between IdP and Docker organization: If a group in your IdP does not have a corresponding team in Docker, it will not be recognized, and the user will be placed in the default organization and team.
+
+### Affected environments
+
+- Docker single sign-on setup using IdPs such as Okta or Azure AD
+- Organizations using group-based role assignments in Docker
+
+### Steps to replicate
+
+To replicate this issue:
+
+1. Attempt to sign in to Docker using SSO.
+2. The user is assigned groups in the IdP but does not get placed in the expected Docker Team.
+3. Review Docker logs or IdP logs to find the error message.
+
+### Solutions
+
+Update group names in your IdP:
+
+1. Go to your IdP's group management section.
+2. Check the groups assigned to the affected user.
+3. Ensure each group follows the required format: `<organization>:<team>`
+4. Update any incorrectly formatted groups to match this pattern.
+5. Save changes and retry signing in with SSO.
+
+## User is not assigned to the organization
+
+### Error message
+
+When this issue occurs, the following error message is common:
+
+```text
+User '$username' is not assigned to this SSO organization. Contact your administrator. TraceID: XXXXXXXXXXXXX
+```
+
+### Causes
+
+- User is not assigned to the organization: If Just-in-Time (JIT) provisioning is disabled, the user may not be assigned to your organization.
+- User is not invited to the organization: If JIT is disabled and you do not want to enable it, the user must be manually invited.
+- SCIM provisioning is misconfigured: If you use SCIM for user provisioning, it may not be correctly syncing users from your IdP.
+
+### Solutions
+
+**Enable JIT provisioning**
+
+JIT is enabled by default when you enable SSO. If you have JIT disabled and need
+to re-enable it:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your organization from the top-left account drop-down.
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. In the SSO connections table, select the **Action** menu and then **Enable JIT provisioning**.
+1. Select **Enable** to confirm.
+
+**Manually invite users**
+
+When JIT is disabled, users are not automatically added to your organization when they authenticate through SSO.
+To manually invite users, see [Invite members](/manuals/admin/organization/manage/members.md#invite-members).
+
+**Configure SCIM provisioning**
+
+If you have SCIM enabled, troubleshoot your SCIM connection using the following steps:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and select your organization from the top-left account drop-down.
+1. Select **Identity & auth**, then **SSO and SCIM**.
+1. In the SSO connections table, select the **Action** menu and then **View error logs**. For more details on specific errors, select **View error details** next to an error message. Note any errors you see on this page.
+1. Navigate back to **Identity & auth**, then **SSO and SCIM**, and verify your SCIM configuration:
+   - Ensure that the SCIM Base URL and API Token in your IdP match those provided in Docker.
+   - Verify that SCIM is enabled in both Docker and your IdP.
+1. Ensure that the attributes being synced from your IdP match Docker's [supported attributes](/manuals/enterprise/security/provisioning/scim/provision-scim.md#supported-attributes) for SCIM.
+1. Test user provisioning by trying to provision a test user through your IdP and verify if they appear in Docker.
+
+## IdP-initiated sign in is not enabled for connection
+
+### Error message
+
+When this issue occurs, the following error message is common:
+
+```text
+IdP-Initiated sign in is not enabled for connection '$ssoConnection'.
+```
+
+### Causes
+
+Docker does not support an IdP-initiated SAML flow. This error occurs when a user attempts to authenticate from your IdP, such as using the Docker SSO app tile on the sign in page.
+
+### Solutions
+
+**Authenticate from Docker apps**
+
+The user must initiate authentication from Docker applications (Hub, Desktop, etc). The user needs to enter their email address in a Docker app and they will get redirected to the configured SSO IdP for their domain.
+
+**Hide the Docker SSO app**
+
+You can hide the Docker SSO app from users in your IdP. This prevents users from attempting to start authentication from the IdP dashboard. You must hide and configure this in your IdP.
+
+## Not enough seats in organization
+
+### Error message
+
+When this issue occurs, the following error message is common:
+
+```text
+Not enough seats in organization '$orgName'. Add more seats or contact your administrator.
+```
+
+### Causes
+
+This error occurs when the organization has no available seats for the user when provisioning via Just-in-Time (JIT) provisioning or SCIM.
+
+### Solutions
+
+**Add more seats to the organization**
+
+Purchase additional Docker Business subscription seats. For details, see [Manage subscription seats](/manuals/admin/organization/manage/manage-seats.md).
+
+**Remove users or pending invitations**
+
+Review your organization members and pending invitations. Remove inactive users or pending invitations to free up seats. For more details, see [Manage organization members](/manuals/admin/organization/manage/members.md).
+
+## Domain is not verified for SSO connection
+
+### Error message
+
+When this issue occurs, the following error message is common:
+
+```text
+Domain '$emailDomain' is not verified for your SSO connection. Contact your company administrator. TraceID: XXXXXXXXXXXXXX
+```
+
+### Causes
+
+This error occurs if the IdP authenticated a user through SSO and the User Principal Name (UPN)
+returned to Docker doesn’t match any of the verified domains associated to the
+SSO connection configured in Docker.
+
+### Solutions
+
+**Verify UPN attribute mapping**
+
+Ensure that the IdP SSO connection is returning the correct UPN value in the assertion attributes.
+
+**Add and verify all domains**
+
+Add and verify all domains and subdomains used as UPN by your IdP and associate them with your Docker SSO connection. For details, see [Configure single sign-on](/manuals/enterprise/security/single-sign-on/connect.md).
+
+## Unable to find session
+
+### Error message
+
+When this issue occurs, the following error message is common:
+
+```text
+We couldn't find your session. You may have pressed the back button, refreshed the page, opened too many sign-in dialogs, or there is some issue with cookies. Try signing in again. If the issue persists, contact your administrator.
+```
+
+### Causes
+
+The following causes may create this issue:
+
+- The user pressed the back or refresh button during authentication.
+- The authentication flow lost track of the initial request, preventing completion.
+
+### Solutions
+
+**Do not disrupt the authentication flow**
+
+Do not press the back or refresh button during sign-in.
+
+**Restart authentication**
+
+Close the browser tab and restart the authentication flow from the Docker application (Desktop, Hub, etc).
+
+## Name ID is not an email address
+
+### Error message
+
+When this issue occurs, the following error message is common:
+
+```text
+The name ID sent by the identity provider is not an email address. Contact your company administrator.
+```
+
+### Causes
+
+The following causes may create this issue:
+
+- The IdP sends a Name ID (UPN) that does not comply with the email format required by Docker.
+- Docker SSO requires the Name ID to be the primary email address of the user.
+
+### Solutions
+
+In your IdP, ensure the Name ID attribute format is correct:
+
+1. Verify that the Name ID attribute format in your IdP is set to `EmailAddress`.
+2. Adjust your IdP settings to return the correct Name ID format.
diff --git a/content/manuals/extensions/_index.md b/content/manuals/extensions/_index.md
index 92beb943cb36..0e0cf3da144c 100644
--- a/content/manuals/extensions/_index.md
+++ b/content/manuals/extensions/_index.md
@@ -5,7 +5,7 @@ description: Extensions
 keywords: Docker Extensions, Docker Desktop, Linux, Mac, Windows
 params:
   sidebar:
-    group: Products
+    group: Application development
 aliases:
  - /desktop/extensions/
 ---
@@ -23,6 +23,10 @@ Anyone can use Docker Extensions and there is no limit to the number of extensio
 There is a mix of partner and community-built extensions and Docker-built extensions.
 You can explore the list of available extensions in [Docker Hub](https://hub.docker.com/search?q=&type=extension) or in the Extensions Marketplace within Docker Desktop.
 
-To find out more about Docker Extensions, we recommend the video walkthrough from DockerCon 2022:
+## Security and trust
 
-<iframe width="750" height="315" src="https://www.youtube.com/embed/3rAGXS8pszQ" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+Docker Extensions run with elevated privileges on your host machine. They have direct access to the Docker Engine, can read and write files on your filesystem, and can install and run native binaries. 
+
+Docker reviews extensions submitted to the Marketplace, but does not guarantee the security of any extension. Extensions installed outside the Marketplace have not been reviewed at all. Only install extensions from publishers you trust. 
+
+If you're an organization admin, see [Configure a private marketplace](private-marketplace.md) to control which extensions your team can install.
\ No newline at end of file
diff --git a/content/manuals/extensions/extensions-sdk/_index.md b/content/manuals/extensions/extensions-sdk/_index.md
index a7ed4c91842d..18ce40b39ed1 100644
--- a/content/manuals/extensions/extensions-sdk/_index.md
+++ b/content/manuals/extensions/extensions-sdk/_index.md
@@ -9,30 +9,34 @@ aliases:
 grid:
   - title: "The build and publish process"
     description: Understand the process for building and publishing an extension.
-    icon: "checklist"
+    icon: clipboard-document-check
     link: "/extensions/extensions-sdk/process/"
   - title: "Quickstart guide"
     description: Follow the quickstart guide to create a basic Docker extension quickly.
-    icon: "explore"
+    icon: magnifying-glass-plus
     link: "/extensions/extensions-sdk/quickstart/"
   - title: "View the design guidelines"
     description: Ensure your extension aligns to Docker's design guidelines and principles.
-    icon: "design_services"
+    icon: paint-brush
     link: "/extensions/extensions-sdk/design/design-guidelines/"
   - title: "Publish your extension"
     description: Understand how to publish your extension to the Marketplace.
-    icon: "publish"
+    icon: arrow-up-tray
     link: "/extensions/extensions-sdk/extensions/"
   - title: "Interacting with Kubernetes"
     description: Find information on how to interact indirectly with a Kubernetes cluster from your Docker extension.
-    icon: "multiple_stop"
+    icon: arrows-right-left
     link: "/extensions/extensions-sdk/guides/kubernetes/"
   - title: "Multi-arch extensions"
     description: Build your extension for multiple architectures.
-    icon: "content_copy"
+    icon: document-duplicate
     link: "/extensions/extensions-sdk/extensions/multi-arch/"
 ---
 
+> [!IMPORTANT]
+>
+> New submissions to the Docker Extensions Marketplace are paused while Docker reviews Marketplace security. You can still update existing extensions, and private Marketplace extensions are unaffected. Contact extensions@docker.com if you have additional questions.
+
 The resources in this section help you create your own Docker extension.
 
 The Docker CLI tool provides a set of commands to help you build and publish your extension, packaged as a 
diff --git a/content/manuals/extensions/extensions-sdk/architecture/_index.md b/content/manuals/extensions/extensions-sdk/architecture/_index.md
index 15e2ff1a02a5..1153323bd2ec 100644
--- a/content/manuals/extensions/extensions-sdk/architecture/_index.md
+++ b/content/manuals/extensions/extensions-sdk/architecture/_index.md
@@ -62,7 +62,7 @@ file
 
 Usually, the backend is made of one container that runs within the Docker Desktop VM. Internally, Docker Desktop creates
 a Docker Compose project, creates the container from the `image` option of the `vm` section of the `metadata.json`, and
-attaches it to the Compose project. See the [ui metadata section](metadata.md#vm-section) for more details.
+attaches it to the Compose project. See the [`vm` metadata section](metadata.md#vm-section) for more details.
 
 In some cases, a `compose.yaml` file can be used instead of an `image`. This is useful when the backend container
 needs more specific options, such as mounting volumes or requesting [capabilities](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
@@ -97,7 +97,7 @@ Shipping those executables with the extension ensure that the CLI tool is always
 the users' machine.
 
 When Docker Desktop installs the extension, it copies the executables on the host as defined by the `host` section in
-the `metadata.json`. See the [ui metadata section](metadata.md#host-section) for more details.
+the `metadata.json`. See the [`host` metadata section](metadata.md#host-section) for more details.
 
 ![Executable and frontend communication](images/extensions-arch-3.png?w=250h=300)
 
diff --git a/content/manuals/extensions/extensions-sdk/architecture/security.md b/content/manuals/extensions/extensions-sdk/architecture/security.md
index 926545e56325..a208273c002f 100644
--- a/content/manuals/extensions/extensions-sdk/architecture/security.md
+++ b/content/manuals/extensions/extensions-sdk/architecture/security.md
@@ -16,6 +16,7 @@ An extension can have the following optional parts:
 * Executables deployed on the host machine.
 
 Extensions are executed with the same permissions as the Docker Desktop user. Extension capabilities include running any Docker commands (including running containers and mounting folders), running extension binaries, and accessing files on your machine that are accessible by the user running Docker Desktop.
+Note that extensions are not restricted to execute binaries that they list in the [host section](../architecture/metadata.md#host-section) of the extension metadata: since these binaries can contain any code running as user, they can in turn execute any other commands as long as the user has rights to execute them.
 
 The Extensions SDK provides a set of JavaScript APIs to invoke commands or invoke these binaries from the extension UI code. Extensions can also provide a backend part that starts a long-lived running container in the background.
 
diff --git a/content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md b/content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md
index 137464b4a231..7a6ab8dd8ea6 100644
--- a/content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md
+++ b/content/manuals/extensions/extensions-sdk/build/backend-extension-tutorial.md
@@ -190,13 +190,9 @@ FROM node:17.7-alpine3.14 AS client-builder
 FROM golang:1.17-alpine AS builder
 ENV CGO_ENABLED=0
 WORKDIR /backend
-COPY vm/go.* .
-RUN --mount=type=cache,target=/go/pkg/mod \
-    --mount=type=cache,target=/root/.cache/go-build \
-    go mod download
-COPY vm/. .
 RUN --mount=type=cache,target=/go/pkg/mod \
     --mount=type=cache,target=/root/.cache/go-build \
+    --mount=type=bind,source=vm/.,target=. \
     go build -trimpath -ldflags="-s -w" -o bin/service
 
 FROM alpine:3.15
@@ -279,14 +275,13 @@ Replace the `ui/src/App.tsx` file with the following code:
 ```tsx
 
 // ui/src/App.tsx
-import React, { useEffect } from 'react';
+import React, { useEffect, useState } from 'react';
 import { createDockerDesktopClient } from "@docker/extension-api-client";
 
 //obtain docker desktop extension client
 const ddClient = createDockerDesktopClient();
 
 export function App() {
-  const ddClient = createDockerDesktopClient();
   const [hello, setHello] = useState<string>();
 
   useEffect(() => {
diff --git a/content/manuals/extensions/extensions-sdk/design/_index.md b/content/manuals/extensions/extensions-sdk/design/_index.md
index bcf79856238b..f1dd94ca71eb 100644
--- a/content/manuals/extensions/extensions-sdk/design/_index.md
+++ b/content/manuals/extensions/extensions-sdk/design/_index.md
@@ -20,7 +20,7 @@ To get started on your UI, follow the steps below.
 
 ### Recommended: React+MUI, using our theme
 
-Docker Desktop's UI is written in React and [MUI](https://mui.com/) (using Material UI to specific). This is the only officially supported framework for building extensions, and the one that our `init` command automatically configures for you. Using it brings significant benefits to authors:
+Docker Desktop's UI is written in React and [MUI](https://mui.com/) (using Material UI specifically). This is the only officially supported framework for building extensions, and the one that the `init` command automatically configures for you. Using it brings significant benefits to authors:
 
 - You can use our [Material UI theme](https://www.npmjs.com/package/@docker/docker-mui-theme) to automatically replicate Docker Desktop's look and feel.
 - In future, we'll release utilities and components specifically targeting this combination (e.g. custom MUI components, or React hooks for interacting with Docker).
diff --git a/content/manuals/extensions/extensions-sdk/design/mui-best-practices.md b/content/manuals/extensions/extensions-sdk/design/mui-best-practices.md
index f0f44bb3013f..f08eb905399d 100644
--- a/content/manuals/extensions/extensions-sdk/design/mui-best-practices.md
+++ b/content/manuals/extensions/extensions-sdk/design/mui-best-practices.md
@@ -38,11 +38,11 @@ The best way to build your UI, so that it’s robust against future theming chan
 
 Sometimes you’ll need a piece of UI that doesn’t exist in our design system. If so, we recommend that you first reach out to us. We may already have something in our internal design system, or we may be able to expand our design system to accommodate your use case.
 
-If you still decide to build it yourself after contacting us, try and define the new UI in a reuseable fashion. If you define your custom UI in just one place, it’ll make it easier to change in the future if our core theme changes. You could use:
+If you still decide to build it yourself after contacting us, try and define the new UI in a reusable fashion. If you define your custom UI in just one place, it’ll make it easier to change in the future if our core theme changes. You could use:
 
 -  A new `variant` of an existing component - see [MUI docs](https://mui.com/material-ui/customization/theme-components/#creating-new-component-variants)
--  A MUI mixin (a freeform bundle of reuseable styling rules defined inside a theme)
--  A new [reuseable component](https://mui.com/material-ui/customization/how-to-customize/#2-reusable-component)
+-  A MUI mixin (a freeform bundle of reusable styling rules defined inside a theme)
+-  A new [reusable component](https://mui.com/material-ui/customization/how-to-customize/#2-reusable-component)
 
 Some of the above options require you to extend our MUI theme. See the MUI documentation on [theme composition](https://mui.com/material-ui/customization/theming/#nesting-the-theme).
 
diff --git a/content/manuals/extensions/extensions-sdk/dev/api/backend.md b/content/manuals/extensions/extensions-sdk/dev/api/backend.md
index 56825ca7caf0..30bbb8326801 100644
--- a/content/manuals/extensions/extensions-sdk/dev/api/backend.md
+++ b/content/manuals/extensions/extensions-sdk/dev/api/backend.md
@@ -20,7 +20,7 @@ ddClient.extension.vm.service
  .then((value: any) => console.log(value)
 ```
 
-See [Service API Reference](/reference/api/extensions-sdk/HttpService.md) for other methods such as POST, UPDATE, and DELETE.
+See [Service API Reference](/reference/api/extensions-sdk/HttpService.md) for other HTTP methods.
 
 > Deprecated extension backend communication
 >
@@ -110,8 +110,7 @@ console.log(output);
 
 ## Invoke an extension binary on the host
 
-You can run binaries defined in the [host section](../../architecture/metadata.md#host-section)
-of the extension metadata.
+Invoke a binary on the host. The binary is typically shipped with your extension using the [host section](../../architecture/metadata.md#host-section) in the extension metadata. Note that extensions run with user access rights, this API is not restricted to binaries listed in the [host section](../../architecture/metadata.md#host-section) of the extension metadata (some extensions might install software during user interaction, and invoke newly installed binaries even if not listed in the extension metadata).
 
 For example, execute the shipped binary `kubectl -h` command in the host:
 
diff --git a/content/manuals/extensions/extensions-sdk/dev/api/dashboard.md b/content/manuals/extensions/extensions-sdk/dev/api/dashboard.md
index f9d626b945db..f8c33001accd 100644
--- a/content/manuals/extensions/extensions-sdk/dev/api/dashboard.md
+++ b/content/manuals/extensions/extensions-sdk/dev/api/dashboard.md
@@ -84,7 +84,7 @@ ddClient.host.openExternal("https://docker.com");
 
 For more details about method parameters and the return types available, see [Desktop host API reference](/reference/api/extensions-sdk/Host.md).
 
-> Deprecated user notifications
+> Deprecated external URL opening
 >
 > This method is deprecated and will be removed in a future version. Use the methods specified above.
 
diff --git a/content/manuals/extensions/extensions-sdk/dev/api/overview.md b/content/manuals/extensions/extensions-sdk/dev/api/overview.md
index 730a78619296..ac90e8dcd11d 100644
--- a/content/manuals/extensions/extensions-sdk/dev/api/overview.md
+++ b/content/manuals/extensions/extensions-sdk/dev/api/overview.md
@@ -14,7 +14,7 @@ and communicate with the Docker Desktop dashboard or the underlying system.
 
 JavaScript API libraries, with Typescript support, are available in order to get all the API definitions in to your extension code.
 
-- [@docker/extension-api-client](https://www.npmjs.com/package/@docker/extension-api-client) gives access to the extension API entrypoint `DockerDesktopCLient`.
+- [@docker/extension-api-client](https://www.npmjs.com/package/@docker/extension-api-client) gives access to the extension API entrypoint `DockerDesktopClient`.
 - [@docker/extension-api-client-types](https://www.npmjs.com/package/@docker/extension-api-client-types) can be added as a dev dependency in order to get types auto-completion in your IDE.
 
 ```Typescript
@@ -34,4 +34,4 @@ The `ddClient` object gives access to various APIs:
 - [Dashboard](dashboard.md)
 - [Navigation](dashboard-routes-navigation.md)
 
-Find the Extensions API reference [here](reference/api/extensions-sdk/_index.md).
+See also the [Extensions API reference](/reference/api/extensions-sdk/_index.md).
diff --git a/content/manuals/extensions/extensions-sdk/dev/continuous-integration.md b/content/manuals/extensions/extensions-sdk/dev/continuous-integration.md
index 1c33ca15e51a..370c92313c3d 100644
--- a/content/manuals/extensions/extensions-sdk/dev/continuous-integration.md
+++ b/content/manuals/extensions/extensions-sdk/dev/continuous-integration.md
@@ -26,7 +26,7 @@ steps:
 
 > [!NOTE]
 >
-> This action supports only Github Action macOS runners at the moment. You need to specify `runs-on: macOS-latest` for your end to end tests.
+> This action supports only GitHub Actions macOS runners at the moment. You need to specify `runs-on: macOS-latest` for your end to end tests.
 
 Once the step has executed, the next steps use Docker Desktop and the Docker CLI to install and test the extension.
 
diff --git a/content/manuals/extensions/extensions-sdk/extensions/multi-arch.md b/content/manuals/extensions/extensions-sdk/extensions/multi-arch.md
index da2d07b890c3..b1f71af50a37 100644
--- a/content/manuals/extensions/extensions-sdk/extensions/multi-arch.md
+++ b/content/manuals/extensions/extensions-sdk/extensions/multi-arch.md
@@ -36,7 +36,7 @@ $ docker buildx build --push --platform=linux/amd64,linux/arm64 --tag=username/m
 ```
 
 You can then check the image manifest to see if the image is available for both
-architectures using the [`docker buildx imagetools` command](/reference/cli/docker/buildx/imagetools/_index.md):
+architectures using the [`docker buildx imagetools` command](/reference/cli/docker/buildx/imagetools/):
 
 ```console
 $ docker buildx imagetools inspect username/my-extension:0.0.1
diff --git a/content/manuals/extensions/extensions-sdk/extensions/publish.md b/content/manuals/extensions/extensions-sdk/extensions/publish.md
index a10b1f5cb5c1..522c53430375 100644
--- a/content/manuals/extensions/extensions-sdk/extensions/publish.md
+++ b/content/manuals/extensions/extensions-sdk/extensions/publish.md
@@ -7,6 +7,10 @@ aliases:
 weight: 50
 ---
 
+> [!IMPORTANT]
+>
+> New submissions to the Docker Extensions Marketplace are paused while Docker reviews Marketplace security. You can still update existing extensions, and private Marketplace extensions are unaffected. Contact extensions@docker.com if you have additional questions.
+
 ## Submit your extension to the Marketplace
 
 Docker Desktop displays published extensions in the Extensions Marketplace on [Docker Desktop](https://open.docker.com/extensions/marketplace) and [Docker Hub](https://hub.docker.com/search?q=&type=extension).
diff --git a/content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md b/content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md
index 73c657bdf266..55e471e15aab 100644
--- a/content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md
+++ b/content/manuals/extensions/extensions-sdk/guides/invoke-host-binaries.md
@@ -13,15 +13,14 @@ provides, or even a shell script that you want to run on the host.
 
 You could do that by executing the CLI from a container with the extension SDK. But this CLI needs to access the host's filesystem, which isn't easy nor fast if it runs in a container.
 
-However host binaries invoke from the extension executables (as binaries, shell scripts)
-shipped as part of your extension and deployed to the host. As extensions can run on multiple platforms, this
+This page describes how to run executables on the host (binaries, shell scripts) that are shipped as part of your extension and deployed to the host. As extensions can run on multiple platforms, this
 means that you need to ship the executables for all the platforms you want to support.
 
 Learn more about extensions [architecture](../architecture/_index.md).
 
 > [!NOTE]
 >
-> Only executables shipped as part of the extension can be invoked with the SDK. 
+>  Note that extensions run with user access rights, this API is not restricted to binaries listed in the [host section](../architecture/metadata.md#host-section) of the extension metadata (some extensions might install software during user interaction, and invoke newly installed binaries even if not listed in the extension metadata).
 
 In this example, the CLI is a simple `Hello world` script that must be invoked with a parameter and returns a 
 string.
diff --git a/content/manuals/extensions/extensions-sdk/process.md b/content/manuals/extensions/extensions-sdk/process.md
index d48f63698cf9..26e1e9a0ef6b 100644
--- a/content/manuals/extensions/extensions-sdk/process.md
+++ b/content/manuals/extensions/extensions-sdk/process.md
@@ -38,6 +38,10 @@ For further inspiration, see the other examples in the [samples folder](https://
 
 ## Part two: Publish and distribute your extension
 
+> [!IMPORTANT]
+>
+> New submissions to the Docker Extensions Marketplace are paused while Docker reviews Marketplace security. You can still update existing extensions, and private Marketplace extensions are unaffected. Contact extensions@docker.com if you have additional questions.
+
 Docker Desktop displays published extensions in the Extensions Marketplace. The Extensions Marketplace is a curated space where developers can discover extensions to improve their developer experience and upload their own extension to share with the world.
 
 If you want your extension published in the Marketplace, read the [publish documentation](extensions/publish.md).
diff --git a/content/manuals/extensions/extensions-sdk/quickstart.md b/content/manuals/extensions/extensions-sdk/quickstart.md
index 2ddc031c9b41..c03704977056 100644
--- a/content/manuals/extensions/extensions-sdk/quickstart.md
+++ b/content/manuals/extensions/extensions-sdk/quickstart.md
@@ -77,6 +77,10 @@ hidden from the Docker Dashboard. You can change this in **Settings**, see
 
 ## Step four: Submit and publish your extension to the Marketplace
 
+> [!IMPORTANT]
+>
+> New submissions to the Docker Extensions Marketplace are paused while Docker reviews Marketplace security. You can still update existing extensions, and private Marketplace extensions are unaffected. Contact extensions@docker.com if you have additional questions.
+
 If you want to make your extension available to all Docker Desktop users, you can submit it for publication in the Marketplace. For more information, see [Publish](extensions/_index.md).
 
 ## Clean up
diff --git a/content/manuals/extensions/marketplace.md b/content/manuals/extensions/marketplace.md
index 4683e7a58d79..1b44f00073aa 100644
--- a/content/manuals/extensions/marketplace.md
+++ b/content/manuals/extensions/marketplace.md
@@ -16,6 +16,10 @@ and quality. They appear as **Reviewed** in the Marketplace.
 
 Self-published extensions are autonomously published by extension developers and go through an automated validation process. They appear as **Not reviewed** in the Marketplace.
 
+> [!IMPORTANT]
+>
+> Marketplace extensions are reviewed by Docker, but are not subject to a full security audit. Extensions run with host-level privileges. They can install binaries, access Docker Engine, invoke commands, and access files on your machine. Only install extensions from publishers you trust.
+
 ## Install an extension
 
 > [!NOTE]
diff --git a/content/manuals/extensions/non-marketplace.md b/content/manuals/extensions/non-marketplace.md
index 9f7de62fd34e..af042e22ccf9 100644
--- a/content/manuals/extensions/non-marketplace.md
+++ b/content/manuals/extensions/non-marketplace.md
@@ -3,16 +3,13 @@ description: Extensions
 keywords: Docker Extensions, Docker Desktop, Linux, Mac, Windows,
 title: Non-marketplace extensions
 weight: 20
-aliases:
- - /desktop/extensions/non-marketplace/
 ---
 
 ## Install an extension not available in the Marketplace
 
 > [!WARNING]
 >
-> Docker Extensions that are not in the Marketplace haven't gone through Docker's review process.
-> Extensions can install binaries, invoke commands and access files on your machine. Installing them is at your own risk.
+> Extensions installed outside the Marketplace have not gone through Docker's review process. Like all Docker extensions, they run with host-level privileges. They can install binaries, access Docker Engine, invoke commands, and access files on your machine. Install only if you trust the publisher and have verified the source.
 
 The Extensions Marketplace is the trusted and official place to install extensions from within Docker Desktop. These extensions have gone through a review process by Docker. However, other extensions can also be installed in Docker Desktop if you trust the extension author.
 
diff --git a/content/manuals/extensions/private-marketplace.md b/content/manuals/extensions/private-marketplace.md
index f75cb862a756..593546e67d40 100644
--- a/content/manuals/extensions/private-marketplace.md
+++ b/content/manuals/extensions/private-marketplace.md
@@ -5,19 +5,17 @@ title: Configure a private marketplace for extensions
 tags: [admin]
 linkTitle: Configure a private marketplace
 weight: 30
-aliases:
- - /desktop/extensions/private-marketplace/
 ---
 
 {{< summary-bar feature_name="Private marketplace" >}}
 
 Learn how to configure and set up a private marketplace with a curated list of extensions for your Docker Desktop users.
 
-Docker Extensions' private marketplace is designed specifically for organizations who don’t give developers root access to their machines. It makes use of [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md) so administrators have complete control over the private marketplace.
+Docker Extensions' private marketplace is designed specifically for organizations who don’t give developers root access to their machines. It makes use of [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md) so administrators have complete control over the private marketplace.
 
 ## Prerequisites
 
-- [Download and install Docker Desktop 4.26.0 or later](https://docs.docker.com/desktop/release-notes/).
+- [Download and install Docker Desktop](https://docs.docker.com/desktop/release-notes/).
 - You must be an administrator for your organization.
 - You have the ability to push the `extension-marketplace` folder and `admin-settings.json` file to the locations specified below through device management software such as [Jamf](https://www.jamf.com/).
 
@@ -43,7 +41,11 @@ Docker Extensions' private marketplace is designed specifically for organization
    {{< tab name="Windows" >}}
 
    ```console
+   # For all-user installations
    $ C:\Program Files\Docker\Docker\resources\bin\extension-admin init
+
+   # For per-user installations
+   $ %LOCALAPPDATA%\Programs\DockerDesktop\resources\bin\extension-admin init
    ```
 
    {{< /tab >}}
@@ -61,10 +63,18 @@ This creates 2 files:
 - `admin-settings.json`, which activates the private marketplace feature once it’s applied to Docker Desktop on your developers’ machines.
 - `extensions.txt`, which determines which extensions to list in your private marketplace.
 
+> [!IMPORTANT]
+>
+> If your org is using [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md) via [Docker Home](manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console/_index.md), you will not need the `admin-settings.json` file. Delete the generated file and keep only the `extensions.txt` file.
+
 ## Step two: Set the behaviour
 
 The generated `admin-settings.json` file includes various settings you can modify.
 
+> [!IMPORTANT]
+>
+> If your org is managing settings via [Docker Home](manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console/_index.md), you will define the same settings in Docker Home instead of the `admin-settings.json` file.
+
 Each setting has a `value` that you can set, including a `locked` field that lets you lock the setting and make it unchangeable by your developers.
 
 - `extensionsEnabled` enables Docker Extensions.
@@ -79,7 +89,7 @@ Each setting has a `value` that you can set, including a `locked` field that let
   }
   ```
 
-To find out more information about the `admin-settings.json` file, see [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md).
+To find out more information about the `admin-settings.json` file, see [Settings Management](/manuals/enterprise/security/hardened-desktop/settings-management/_index.md).
 
 ## Step three: List allowed extensions
 
@@ -120,7 +130,11 @@ $ /Applications/Docker.app/Contents/Resources/bin/extension-admin generate
 {{< tab name="Windows" >}}
 
 ```console
+# For all-user installations
 $ C:\Program Files\Docker\Docker\resources\bin\extension-admin generate
+
+# For per-user installations
+$ %LOCALAPPDATA%\Programs\DockerDesktop\resources\bin\extension-admin generate
 ```
 
 {{< /tab >}}
@@ -158,7 +172,11 @@ It's recommended that you try the private marketplace on your Docker Desktop ins
    {{< tab name="Windows (run as admin)" >}}
 
    ```console
+   # For all-user installations
    $ C:\Program Files\Docker\Docker\resources\bin\extension-admin apply
+
+   # For per-user installations
+   $ %LOCALAPPDATA%\Programs\DockerDesktop\resources\bin\extension-admin apply
    ```
 
    {{< /tab >}}
@@ -174,6 +192,10 @@ It's recommended that you try the private marketplace on your Docker Desktop ins
 2. Quit and re-open Docker Desktop. 
 3. Sign in with a Docker account.
 
+> [!IMPORTANT]
+>
+> > If your org is managing settings via [Docker Home](manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console/_index.md), in Docker Desktop 4.59 and earlier, you must manually delete the `admin-settings.json` file created in the target folder by the `apply` command before step 2. In Docker Desktop 4.60 and later, this step is no longer necessary. 
+
 When you select the **Extensions** tab, you should see the private marketplace listing only the extensions you have allowed in `extensions.txt`.
 
 ![Extensions Private Marketplace](/assets/images/extensions-private-marketplace.webp)
@@ -183,7 +205,7 @@ When you select the **Extensions** tab, you should see the private marketplace l
 Once you’ve confirmed that the private marketplace configuration works, the final step is to distribute the files to the developers’ machines with the MDM software your organization uses. For example, [Jamf](https://www.jamf.com/).
 
 The files to distribute are:
-* `admin-settings.json`
+* `admin-settings.json` (except if your org is managing settings via [Docker Home](manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console/_index.md))
 * the entire `extension-marketplace` folder and its subfolders
 
 These files must be placed on developer's machines. Depending on your operating system, the target location is (as mentioned above):
@@ -192,7 +214,7 @@ These files must be placed on developer's machines. Depending on your operating
 - Windows: `C:\ProgramData\DockerDesktop`
 - Linux: `/usr/share/docker-desktop`
 
-Make sure your developers are signed in to Docker Desktop in order for the private marketplace configuration to take effect. As an administrator, you should [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md).
+Make sure your developers are signed in to Docker Desktop in order for the private marketplace configuration to take effect. As an administrator, you should [enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md).
 
 ## Feedback
 
diff --git a/content/manuals/extensions/settings-feedback.md b/content/manuals/extensions/settings-feedback.md
index e1f672489abd..c585fd009eaf 100644
--- a/content/manuals/extensions/settings-feedback.md
+++ b/content/manuals/extensions/settings-feedback.md
@@ -4,29 +4,27 @@ keywords: Docker Extensions, Docker Desktop, Linux, Mac, Windows, feedback
 title: Settings and feedback for Docker Extensions
 linkTitle: Settings and feedback
 weight: 40
-aliases:
- - /desktop/extensions/settings-feedback/
 ---
 
 ## Settings
 
 ### Turn on or turn off extensions
 
-Docker Extensions is switched on by default. To change your settings:
+Docker Extensions is switched off by default. To change your settings:
 
 1. Navigate to **Settings**.
 2. Select the **Extensions** tab.
 3. Next to **Enable Docker Extensions**, select or clear the checkbox to set your desired state.
-4. In the bottom-right corner, select **Apply & Restart**.
+4. In the bottom-right corner, select **Apply**.
 
 > [!NOTE]
 >
-> If you are an [organization owner](/manuals/admin/organization/manage-a-team.md#organization-owner), you can turn off extensions for your users. Open the `settings-store.json` file, and set `"extensionsEnabled"` to `false`.
-> The `settings-store.json` file (or `settings.json` for Docker Desktop versions 4.34 and earlier) is located at:
+> If you are an [organization owner](/manuals/admin/organization/manage/manage-a-team.md#what-is-an-organization-owner), you can turn off extensions for your users. Open the `settings-store.json` file, and set `"extensionsEnabled"` to `false`.
+> The `settings-store.json` file is located at:
 >   - `~/Library/Group Containers/group.com.docker/settings-store.json` on Mac
 >   - `C:\Users\[USERNAME]\AppData\Roaming\Docker\settings-store.json` on Windows
 >
-> This can also be done with [Hardened Docker Desktop](/manuals/security/for-admins/hardened-desktop/_index.md)
+> This can also be done with [Hardened Docker Desktop](/manuals/enterprise/security/hardened-desktop/_index.md)
 
 ### Turn on or turn off extensions not available in the Marketplace
 
@@ -35,7 +33,7 @@ You can install extensions through the Marketplace or through the Extensions SDK
 1. Navigate to **Settings**.
 2. Select the **Extensions** tab.
 3. Next to **Allow only extensions distributed through the Docker Marketplace**, select or clear the checkbox to set your desired state.
-4. In the bottom-right corner, select **Apply & Restart**.
+4. In the bottom-right corner, select **Apply**.
 
 ### See containers created by extensions
 
@@ -45,7 +43,7 @@ update your settings:
 1. Navigate to **Settings**.
 2. Select the **Extensions** tab.
 3. Next to **Show Docker Extensions system containers**, select or clear the checkbox to set your desired state.
-4. In the bottom-right corner, select **Apply & Restart**.
+4. In the bottom-right corner, select **Apply**.
 
 > [!NOTE]
 >
diff --git a/content/manuals/harmonia/_index.md b/content/manuals/harmonia/_index.md
deleted file mode 100644
index b3a6b88d5f45..000000000000
--- a/content/manuals/harmonia/_index.md
+++ /dev/null
@@ -1,271 +0,0 @@
----
-title: Project Harmonia
-description: Learn how you can run your applications in the cloud with Project Harmonia
-keywords: run, cloud, docker desktop, resources
-sitemap: false
-params:
-  sidebar:
-    group: Products
-aliases:
-- /run-cloud/
----
-
-{{% restricted title="Private preview" %}}
-Project Harmonia is in Private preview.
-{{% /restricted %}}
-
-Project Harmonia brings the power of the cloud to your local development workflow. You can now run your applications in the cloud whilst continuing to use your existing tools and workflows and without worrying about local resource limitations. Project Harmonia also lets you share previews of your cloud-based applications for real-time feedback. 
-
-## Set up 
-
-To get started with Project Harmonia, you need to:
-
-- Have a Docker account that's part of a Docker organization
-- Email `run.cloud@docker.com` to get help with onboarding
-
-## Quickstart
-
-You can use Project Harmonia from the Docker Desktop Dashboard or from the CLI. 
-
-This guide introduces you to essential commands and steps for creating, managing, and sharing a cloud engine. 
-
-### Step one: Create a cloud engine
-
-{{< tabs group="method" >}}
-{{< tab name="Docker Desktop">}}
-
-1. In the Docker Desktop Dashboard, navigate to the **Project Harmonia** tab. 
-2. In the top right-hand corner, select **Create Cloud Engine**.
-3. Fill out the creation form:
-   - Enter `cloudengine` as the name
-   - Choose an organization to associate the cloud engine with
-   - Select the engine size and architecture
-
-   Note that the **Switch Docker Context to use remote engine** is selected by default. The automatically switches you to your new cloud engine once it has been created. 
-4. Select **Create**.
-
-To verify creation, check the context switcher in the top-left corner of the Docker Desktop Dashboard; it should display `cloudengine`. You’re now ready to use it.
-
-{{< /tab >}}
-{{< tab name="CLI">}}
-
-Run the following command: 
-
-```console
-$ docker harmonia engine create cloudengine --type "standard-amd64"  --use
-```
-
-This creates an engine called `cloudengine` and:
-- Immediately switches you to the new cloud engine with the `--use` flag.
-- Sets the engine size to standard and the engine's CPU architecture to amd64 with the `--type` flag. 
-
-Project Harmonia supports the following values for `--type`:
-- `standard-arm64`
-- `standard-amd64` (default)
-- `large-arm64`
-- `large-amd64`
-- `aiml-amd64`
-
-Standard size engines have 2 CPU cores and 4GB RAM, large and AI/ML engines have 4 CPU cores and 8GB RAM.
-
-To verify you're using the newly created cloud engine, run:
-
-```console
-$ docker context inspect
-```
-
-You should see the following:
-
-```text
-[
-    {
-        "Name": "cloudengine2",
-...
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Step two: Run and remove containers with the newly created cloud engine 
-
-1.  Run an Nginx container in the cloud engine:
-    ```console
-    $ docker run -d --name cloudnginx -p 8080:80 nginx
-    ```
-    This maps the container's port `80` to the host's port `8080`. If port `8080` is already in use on your host, you can specify a different port.
-2.  View the Nginx welcome page. Navigate to [`http://localhost:8080/`](http://localhost:8080/).
-3.  Verify the running container:
-    -   In the **Containers** tab in the Docker Desktop Dashboard, you should see your Nginx container listed.
-    -   Alternatively, list all running containers in the cloud engine via the terminal:
-        ```console
-        $ docker ps
-        ```
-4.  Shut down the container:
-    ```console
-    $ docker kill cloudnginx
-    ```
-
-Running a container with a cloud engine is just as straightforward as running it locally.
-
-### Step three: Create and switch to a new cloud engine
-
-{{< tabs group="method" >}}
-{{< tab name="Docker Desktop">}}
-
-1. Create a new cloud engine:
-   - Enter `cloudengine2` as the name
-   - Choose an organization to associate the cloud engine with
-   - Select the **Standard** engine size with the **AMD-64** architecture
-   In the **Project Harmonia** view you should now see both `cloudengine` and `cloudengine2`. 
-2. Switch between engines, also known as your Docker contexts. Use the context switcher in the top-left corner of the Docker Desktop Dashboard to toggle between your cloud engines or switch from your local engine (`desktop-linux`) to a cloud engine. 
-
-{{< /tab >}}
-{{< tab name="CLI">}}
-
-1. Create a new cloud engine. Run:
-   ```console
-   $ docker harmonia engine create cloudengine2
-   ```
-   Docker automatically switches you to your new cloud engine. 
-2. Switch between engines, also known as your Docker contexts. Either switch to your first cloud engine:
-   ```console
-   $ docker context use cloudengine
-   ``` 
-   Or switch back to your local engine: 
-   ```console
-   $ docker context use desktop-linux
-   ```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Step four: Use a file sync for your cloud engine
-
-Project Harmonia takes advantage of [Synchronized file shares](/manuals/desktop/features/synchronized-file-sharing.md) to enable local-to-remote file shares and port mappings. 
-
-{{< tabs group="method" >}}
-{{< tab name="Docker Desktop">}}
-
-1. Clone the [Awesome Compose](https://github.com/docker/awesome-compose) repository.
-2. In the Docker Desktop Dashboard, navigate to the **Project Harmonia** view.
-3. For the `cloudengine` cloud engine, select the **Actions** menu and then **Manage file syncs**.
-4. Select **Create file sync**.
-5. Navigate to the `awesome-compose/react-express-mysql` folder and select **Open**.
-6. In your terminal, navigate to the `awesome-compose/react-express-mysql` directory.
-7. Run the project in the cloud engine with:
-   ```console
-   $ docker compose up -d
-   ```
-8. Test the application by visiting [`http://localhost:3000`](http://localhost:3000/).
-   You should see the home page. The code for this page is located in `react-express-mysql/frontend/src/App.js`.
-9. In an IDE or text editor, open the `App.js` file, change some text, and save. Watch as the code reloads live in your browser.
-
-{{< /tab >}}
-{{< tab name="CLI">}}
-
-1. Clone the [Awesome Compose](https://github.com/docker/awesome-compose) repository.
-2. In your terminal, change into the `awesome-compose/react-express-mysql` directory.
-3. Create a file sync for `cloudengine`:
-   ```console
-   $ docker harmonia file-sync create --engine cloudengine $PWD
-4. Run the project in the cloud engine with:
-   ```console
-   $ docker compose up -d
-   ```
-5. Test the application by visiting [`http://localhost:3000`](http://localhost:3000/).
-   You should see the home page. The code for this page is located in `react-express-mysql/frontend/src/App.js`.
-6. In an IDE or text editor, open the `App.js` file, change some text, and save. Watch as the code reloads live in your browser.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Step five: Share a container port
-
-{{< tabs group="method" >}}
-{{< tab name="Docker Desktop">}}
-
-1.  Make sure your Docker context is set to `cloudengine`.
-2.  In the Docker Desktop Dashboard, navigate to the **Containers** view.
-3.  If necessary, expand the application listing to show all of its containers.
-4.  Select the **lock** icon in the **Ports** column of your running container next to `3000:3000`.
-    This creates a publicly accessible URL that you can share with teammates.
-5.  Select the **copy** icon, to copy this URL.
-
-To view all shared ports for your Docker context, select the **Shared ports** icon in the bottom-right corner of the Docker Desktop Dashboard.
-
-{{< /tab >}}
-{{< tab name="CLI">}}
-
-To share a container port, make sure your Docker context is set to `cloudengine` and then run: 
-``` console
-$ docker harmonia engine share create cloudengine 3000
-```
-This returns a publicly accessible URL for your React app hosted on port `3000`, that you can share with teammates.
-
-To see a list of all your shared ports, run:
-
-```console
-$ docker harmonia engine share list 
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Step six: Clean up 
-
-{{< tabs group="method" >}}
-{{< tab name="Docker Desktop">}}
-
-To stop the running project:
-
-```console
-$ docker compose down
-```
-
-To remove a file sync session:
-1. Navigate to your cloud engine in the **Project Harmonia** view.
-2. Select the **Actions** menu and then **Manage file syncs**.
-3. Select the **drop-down** icon on the file sync.
-4. Select **Delete**.
-
-To remove a cloud engine, navigate to the **Project Harmonia** view and then select the **delete** icon.
-
-{{< /tab >}}
-{{< tab name="CLI">}}
-
-To stop the running project:
-
-```console
-$ docker compose down
-```
-
-To remove the file sync session, run:
-
-```console
-$ docker harmonia file-sync delete --engine cloudengine $PWD
-```
-
-To remove a cloud engine, run:
-
-```console
-$ docker harmonia engine delete <name-of-engine>
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Troubleshoot
-
-Run `docker harmonia doctor` to print helpful troubleshooting information. 
-
-## Known issues
-
-- KinD does not run on Project Harmonia due to some hard-coded assumptions to ensure it's running in a privileged container. K3d is a good alternative.
-- Containers cannot access host through DNS `host.docker.internal`.
-- File binds (non-directory binds) are currently static, meaning changes will not be reflected until the container is restarted. This also affects Compose configs and secrets directives.
-- Bind _mounts_, such as `-v /localpath:/incontainer` in the `docker run` command, require creating a file-sync.
-- Creating a [synchronized file share](/manuals/desktop/features/synchronized-file-sharing.md) for a directory with a large amount of may take extra time to sync and become ready for use in a container.
-- Bind _volumes_, such as those created with `docker volume create --driver local --opt type=none --opt o=bind --opt device=/some/host/path myvolname` or via the compose equivalent, are not supported.
-- Port-forwarding for UDP is not supported. 
-- Docker Compose projects relying on `watch` in `sync` mode are not working with the `tar` synchronizer. Configure it to use `docker cp` instead, disable tar sync by setting `COMPOSE_EXPERIMENTAL_WATCH_TAR=0` in your environment.
-- Some Docker Engine features that let you access the underlying host, such as `--pid=host`, `--network=host`, and `--ipc=host`, are currently disabled.
diff --git a/content/manuals/offload/_index.md b/content/manuals/offload/_index.md
new file mode 100644
index 000000000000..86d33414f050
--- /dev/null
+++ b/content/manuals/offload/_index.md
@@ -0,0 +1,61 @@
+---
+title: Docker Offload
+weight: 15
+description: Find documentation on Docker Offload to help you offload containers to the cloud.
+keywords: build, cloud, cloud build, remote builder
+params:
+  sidebar:
+    group: Application development
+
+grid:
+
+- title: Quickstart
+  description: Get up and running with Docker Offload in just a few steps.
+  icon: rocket-launch
+  link: /offload/quickstart/
+
+- title: About
+  description: Learn about Docker Offload and how it works.
+  icon: information-circle
+  link: /offload/about/
+
+- title: Configure
+  description: Configure Docker Offload settings for your organization and Docker Desktop.
+  icon: adjustments-horizontal
+  link: /offload/configuration/
+
+- title: Usage
+  description: Learn about Docker Offload usage and how to monitor your cloud resources.
+  icon: heart
+  link: /offload/usage/
+
+- title: Optimize
+  description: Improve performance and cost efficiency in Docker Offload.
+  icon: bolt
+  link: /offload/optimize/
+
+- title: Troubleshoot
+  description: Learn how to troubleshoot issues with Docker Offload.
+  icon: bug-ant
+  link: /offload/troubleshoot/
+
+- title: Feedback
+  description: Provide feedback on Docker Offload.
+  icon: chat-bubble-left
+  link: /offload/feedback/
+
+aliases:
+- /harmonia/
+---
+
+{{< summary-bar feature_name="Docker Offload" >}}
+
+Docker Offload is a fully managed service that lets you offload building and
+running containers to the cloud using the Docker tools you already know. It
+enables developers to work efficiently in virtual desktop infrastructure (VDI)
+environments or systems that don't support nested virtualization.
+
+In the following topics, learn about Docker Offload, how to set it up, use it
+for your workflows, and troubleshoot common issues.
+
+{{< grid >}}
\ No newline at end of file
diff --git a/content/manuals/offload/about.md b/content/manuals/offload/about.md
new file mode 100644
index 000000000000..8fc82da8b0c3
--- /dev/null
+++ b/content/manuals/offload/about.md
@@ -0,0 +1,107 @@
+---
+title: About Docker Offload
+linktitle: About
+weight: 15
+description: Learn about Docker Offload, its features, and how it works.
+keywords: cloud, offload, vdi
+---
+
+{{< summary-bar feature_name="Docker Offload" >}}
+
+Docker Offload is a fully managed service for building and running containers in
+the cloud using the Docker tools you already know, including Docker Desktop, the
+Docker CLI, and Docker Compose. It extends your local development workflow into a
+scalable, cloud-powered environment, enabling developers to work efficiently even
+in virtual desktop infrastructure (VDI) environments or systems that don't support
+nested virtualization.
+
+## Key features
+
+Docker Offload includes the following capabilities to support modern container
+workflows:
+
+- Ephemeral cloud runners: Automatically provision and tear down cloud
+  environments for each container session.
+- Secure communication: Use encrypted tunnels between Docker Desktop and cloud
+  environments with support for secure secrets and image pulling.
+- Port forwarding and bind mounts: Retain a local development experience even
+  when running containers in the cloud.
+- VDI-friendly: [Use Docker Desktop](../desktop/setup/vm-vdi.md) in virtual
+  desktop environments or systems that don't support nested virtualization.
+
+For more information, see the [Docker Offload product
+page](https://www.docker.com/products/docker-offload/).
+
+## How Docker Offload works
+
+Docker Offload replaces the need to build or run containers locally by connecting
+Docker Desktop to secure, dedicated cloud resources.
+
+### Running containers with Docker Offload
+
+When you use Docker Offload to build or run containers, Docker Desktop creates a secure
+SSH tunnel to a Docker daemon running in the cloud. Your containers are started
+and managed entirely in that remote environment.
+
+Here's what happens:
+
+1. Docker Desktop connects to the cloud and triggers container creation.
+2. Docker Offload builds or pulls the required images and starts containers in the cloud.
+3. The connection stays open while the containers run and you remain active.
+4. When the containers stop running, the environment shuts down and is cleaned
+   up automatically.
+
+This setup avoids the overhead of running containers locally and enables fast,
+reliable containers even on low-powered machines, including machines that do not
+support nested virtualization. This makes Docker Offload ideal for developers
+using environments such as virtual desktops, cloud-hosted development machines,
+or older hardware.
+
+Despite running remotely, features like bind mounts and port forwarding continue
+to work seamlessly, providing a local-like experience from within Docker Desktop
+and the CLI.
+
+### Cloud resources
+
+Docker Offload uses cloud hosts with 4 vCPUs and 8 GiB of memory. If you have
+different requirements, <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_offload_about" class="link" rel="noopener">contact Docker</a> to explore options.
+
+### Session management and idle state
+
+Docker Offload uses session management and idle state policies to ensure fair use of cloud resources across all users, see [Fair use](#fair-use).
+
+Each user can run one Docker Offload session at a time. When Docker Desktop is in an **Offload idle** state, it waits for activity on the Docker API and only connects to a cloud environment when needed. Once connected, the session moves to an **Offload running** state and stays connected as long as Docker detects activity. Activity includes any Docker API call, a running container, or an active build.
+
+#### When you'll see a prompt
+
+While Docker Offload is running, Docker Desktop shows prompts in the Dashboard to check if you're still active. Prompts appear in two cases:
+
+1. No activity is detected for more than 3 minutes.
+2. The session has been running for a long time.
+
+When a prompt appears, you can:
+   - Select **Ask me again later** to confirm you're still active and continue your session.
+   - Select **Idle now** to return to an idle state immediately.
+   - Do nothing, and the session returns to an idle state automatically.
+
+#### What happens when your session goes idle
+
+After your session returns to an idle state, there is a 5-minute grace period. You can resume the session during this time by running any Docker command.
+
+> [!IMPORTANT]
+> If the idle period exceeds 5 minutes without activity, the session is terminated. Docker Offload environments are ephemeral, so the remote environment and any containers, images, or volumes in it are deleted. To keep work between sessions, push images to a registry such as [Docker Hub](/docker-hub/) before your session ends.
+
+#### Long session prompts
+
+Long session prompts appear every 3 hours during a session. After 8 hours of cumulative usage in a day, prompts appear every hour. The 8-hour counter resets at the start of each day.
+
+## Fair use
+
+Docker Offload enforces a fair use policy to prevent resource abuse. Fair use is
+defined as up to 8 compute hours per named user per day, totaled across all user
+sessions. Usage in excess of this threshold may be subject to session management
+at Docker's discretion.
+
+## What's next
+
+Get hands-on with Docker Offload by following the [Docker Offload quickstart](/offload/quickstart/).
\ No newline at end of file
diff --git a/content/manuals/offload/configuration.md b/content/manuals/offload/configuration.md
new file mode 100644
index 000000000000..f0275bebbde5
--- /dev/null
+++ b/content/manuals/offload/configuration.md
@@ -0,0 +1,31 @@
+---
+title: Configure Docker Offload
+linktitle: Configure
+weight: 20
+description: Learn how to configure build settings for Docker Offload.
+keywords: cloud, configuration, settings, offload
+---
+
+{{< summary-bar feature_name="Docker Offload" >}}
+
+You can configure Docker Offload settings at different levels depending on your
+role. Organization owners can manage settings for all users in their
+organization, while individual developers can configure their own Docker Desktop
+settings when allowed by their organization.
+
+## Manage settings for your organization
+
+For organization owners, you can manage Docker Offload settings for all users in
+your organization. For more details, see [Manage Docker
+products](../admin/organization/manage/manage-products.md). To view usage for Docker
+Offload, see [Docker Offload usage](/offload/usage/).
+
+## Configure settings in Docker Desktop
+
+For developers, you can enable or disable Docker Offload in Docker Desktop if
+allowed by your organization. To manage this setting:
+
+1. Open the Docker Desktop Dashboard and sign in.
+2. Select the settings icon in the Docker Desktop Dashboard header.
+3. In **Settings**, select **Docker Offload**.
+4. Toggle **Enable Docker Offload**. When enabled, you can start Offload sessions.
\ No newline at end of file
diff --git a/content/manuals/offload/feedback.md b/content/manuals/offload/feedback.md
new file mode 100644
index 000000000000..6b12f8ba540d
--- /dev/null
+++ b/content/manuals/offload/feedback.md
@@ -0,0 +1,24 @@
+---
+description: Find a way to provide feedback that's right for you
+keywords: Feedback, Docker Offload, bugs, problems, issues
+title: Give feedback
+weight: 900
+---
+
+There are several ways you can provide feedback on Docker Offload.
+
+## Quick survey
+
+The fastest way to share your thoughts is to fill out this short
+[Docker Offload feedback
+survey](https://docker.qualtrics.com/jfe/form/SV_br8Ki4CCdqeIYl0). It only takes
+a minute and helps the Docker Team improve your experience.
+
+## In-product feedback
+
+On each Docker Desktop Dashboard view, there is a **Give feedback** link. This
+opens a feedback form where you can share ideas directly with the Docker Team.
+
+## Report bugs or problems on GitHub
+
+To report bugs or problems, visit the [Docker Desktop issue tracker](https://github.com/docker/desktop-feedback).
diff --git a/content/manuals/offload/images/cloud-mode.png b/content/manuals/offload/images/cloud-mode.png
new file mode 100644
index 000000000000..f8b1ceb60d25
Binary files /dev/null and b/content/manuals/offload/images/cloud-mode.png differ
diff --git a/content/manuals/offload/images/hourglass-icon.png b/content/manuals/offload/images/hourglass-icon.png
new file mode 100644
index 000000000000..64f989fd0f50
Binary files /dev/null and b/content/manuals/offload/images/hourglass-icon.png differ
diff --git a/content/manuals/offload/images/offload-toggle.png b/content/manuals/offload/images/offload-toggle.png
new file mode 100644
index 000000000000..4342a5003ad2
Binary files /dev/null and b/content/manuals/offload/images/offload-toggle.png differ
diff --git a/content/manuals/offload/optimize.md b/content/manuals/offload/optimize.md
new file mode 100644
index 000000000000..e73c6b9744f5
--- /dev/null
+++ b/content/manuals/offload/optimize.md
@@ -0,0 +1,78 @@
+---
+title: Optimize Docker Offload usage
+linktitle: Optimize usage
+weight: 40
+description: Learn how to optimize your Docker Offload usage.
+keywords: cloud, optimize, performance, offload
+---
+
+Docker Offload builds and runs your containers remotely, not on the machine where you invoke the
+commands. This means that files must be transferred from your local system to the
+cloud over the network.
+
+Transferring files over the network introduces higher latency and lower
+bandwidth compared to local transfers.
+
+Even with optimizations, large projects or slower network connections can lead to longer transfer times. Here are
+several ways to optimize your setup for Docker Offload:
+
+- [Use `.dockerignore` files](#dockerignore-files)
+- [Choose slim base images](#slim-base-images)
+- [Use multi-stage builds](#multi-stage-builds)
+- [Fetch remote files during the build](#fetch-remote-files-in-build)
+- [Leverage multi-threaded tools](#multi-threaded-tools)
+
+For general Dockerfile tips, see [Building best practices](/manuals/build/building/best-practices.md).
+
+## dockerignore files
+
+A [`.dockerignore` file](/manuals/build/concepts/context.md#dockerignore-files)
+lets you specify which local files should *not* be included in the build
+context. Files excluded by these patterns won’t be uploaded to Docker Offload
+during a build.
+
+Typical items to ignore:
+
+- `.git` – avoids transferring your version history. (Note: you won’t be able to run `git` commands in the build.)
+- Build artifacts or locally generated binaries.
+- Dependency folders such as `node_modules`, if those are restored in the build
+  process.
+
+As a rule of thumb, your `.dockerignore` should be similar to your `.gitignore`.
+
+## Slim base images
+
+Smaller base images in your `FROM` instructions can reduce final image size and
+improve build performance. The [`alpine`](https://hub.docker.com/_/alpine) image
+is a good example of a minimal base.
+
+For fully static binaries, you can use [`scratch`](https://hub.docker.com/_/scratch), which is an empty base image.
+
+## Multi-stage builds
+
+[Multi-stage builds](/build/building/multi-stage/) let you separate build-time
+and runtime environments in your Dockerfile. This not only reduces the size of
+the final image but also allows for parallel stage execution during the build.
+
+Use `COPY --from` to copy files from earlier stages or external images. This
+approach helps minimize unnecessary layers and reduce final image size.
+
+## Fetch remote files in build
+
+When possible, download large files from the internet during the build itself
+instead of bundling them in your local context. This avoids network transfer
+from your client to Docker Offload.
+
+You can do this using:
+
+- The Dockerfile [`ADD` instruction](/reference/dockerfile/#add)
+- `RUN` commands like `wget`, `curl`, or `rsync`
+
+### Multi-threaded tools
+
+Some build tools, such as `make`, are single-threaded by default. If the tool
+supports it, configure it to run in parallel. For example, use `make --jobs=4`
+to run four jobs simultaneously.
+
+Taking advantage of available CPU resources in the cloud can significantly
+improve build time.
diff --git a/content/manuals/offload/quickstart.md b/content/manuals/offload/quickstart.md
new file mode 100644
index 000000000000..27b864a2e132
--- /dev/null
+++ b/content/manuals/offload/quickstart.md
@@ -0,0 +1,120 @@
+---
+title: Docker Offload quickstart
+linktitle: Quickstart
+weight: 10
+description: Learn how to use Docker Offload to build and run your container images in the cloud.
+keywords: cloud, quickstart, Docker Desktop, offload
+---
+
+{{< summary-bar feature_name="Docker Offload" >}}
+
+[Docker Offload](./about.md) lets you build and run containers in the cloud
+while using your local Docker Desktop tools and workflow. This means faster
+builds, access to powerful cloud resources, and a seamless development
+experience.
+
+This quickstart covers the steps developers need to get started with Docker Offload.
+
+> [!NOTE]
+>
+> If you're an organization owner, to get started you must <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_offload_quickstart" class="link" rel="noopener">contact sales</a> and subscribe your
+> organization to use Docker Offload. After subscribing, see [Manage Docker
+> products](../admin/organization/manage/manage-products.md) to learn how to manage
+> access for the developers in your organization.
+
+
+## Prerequisites
+
+- You must have [Docker Desktop](/desktop/) installed. Docker recommends using
+  the latest version of Docker Desktop to access the newest features and
+  improvements in Docker Offload.
+- You must have a Docker Business subscription and a Docker Offload subscription.
+
+## Step 1: Verify access to Docker Offload
+
+To access Docker Offload, you must be part of an organization that has
+subscribed to Docker Offload. As a developer, you can verify this by checking if
+the Docker Offload toggle appears in the Docker Desktop Dashboard header.
+
+1. Start Docker Desktop and sign in.
+2. In the Docker Desktop Dashboard header, look for the Docker Offload toggle.
+
+![Offload toggle](./images/offload-toggle.png)
+
+If you see the Docker Offload toggle, you have access to Docker Offload and can
+proceed to the next step. If you don't see the Docker Offload toggle, check if
+Docker Offload is disabled in your [Docker Desktop
+settings](./configuration.md), and then contact your administrator to verify
+that your organization has subscribed to Docker Offload and that they have
+enabled access for your organization.
+
+## Step 2: Start Docker Offload
+
+You can start Docker Offload from the CLI or in the header of the Docker Desktop
+Dashboard. The following steps describe how to start Docker Offload using the
+CLI.
+
+1. Start Docker Desktop and sign in.
+2. Open a terminal and run the following command to start Docker Offload:
+
+   ```console
+   $ docker offload start
+   ```
+
+   > [!TIP]
+   >
+   > To learn more about the Docker Offload CLI commands, see the [Docker Offload CLI
+   > reference](/reference/cli/docker/offload/).
+
+3. If you are a member of multiple organizations that have access to Docker
+   Offload, you have the option to select a profile. Your usage will be
+   associated with the organization of the selected profile.
+
+
+When Docker Offload is started, you'll see a cloud icon ({{< inline-image
+src="./images/cloud-mode.png" alt="Offload mode icon" >}}) in the Docker Desktop
+Dashboard header, and the Docker Desktop Dashboard appears purple. You can run
+`docker offload status` in a terminal to check the status of Docker Offload.
+
+## Step 3: Run a container with Docker Offload
+
+After starting Docker Offload, Docker Desktop connects to a secure cloud
+environment that mirrors your local experience. When you run builds or
+containers, they execute remotely, but behave just like local ones.
+
+To verify that Docker Offload is working, run a container:
+
+```console
+$ docker run --rm hello-world
+```
+
+If Docker Offload is working, you'll see `Hello from Docker!` in the terminal output.
+
+## Step 4: Monitor your Offload session
+
+When Docker Offload is started and you have started session (for example, you've
+ran a container), then you can see current session duration estimate in the
+Docker Desktop Dashboard footer next to the hourglass icon ({{< inline-image
+src="./images/hourglass-icon.png" alt="Offload session duration" >}}).
+
+Also, when Docker Offload is started, you can view detailed session information
+by selecting **Docker Offload** > **Insights** in the left navigation of the
+Docker Desktop Dashboard.
+
+## Step 5: Stop Docker Offload
+
+Docker Offload automatically
+[idles](./about.md#session-management-and-idle-state) if you do not respond to
+periodic prompts that appear in the Docker Desktop Dashboard. You can stop your
+Docker Offload session at any time. To stop Docker Offload:
+
+```console
+$ docker offload stop
+```
+
+When you stop Docker Offload, the cloud environment is terminated and all
+running containers and images are removed. When Docker Offload has been idle for
+5 minutes, the environment is also terminated and all running containers and
+images are removed.
+
+To start Docker Offload again, run the `docker offload start` command.
diff --git a/content/manuals/offload/troubleshoot.md b/content/manuals/offload/troubleshoot.md
new file mode 100644
index 000000000000..2e58cad16d96
--- /dev/null
+++ b/content/manuals/offload/troubleshoot.md
@@ -0,0 +1,57 @@
+---
+title: Troubleshoot Docker Offload
+linktitle: Troubleshoot
+weight: 800
+description: Learn how to troubleshoot issues with Docker Offload.
+keywords: cloud, troubleshooting, cloud mode, Docker Desktop, cloud builder, usage
+tags: [Troubleshooting]
+---
+
+{{< summary-bar feature_name="Docker Offload" >}}
+
+Docker Offload requires:
+
+- Authentication
+- An active internet connection
+- No restrictive proxy or firewall blocking traffic to Docker Cloud
+- Access to Docker Offload
+- Docker Desktop 4.68 or later
+
+Docker Desktop uses Offload to run both builds and containers in the cloud.
+If builds or containers are failing to run, falling back to local, or reporting
+session errors, use the following steps to help resolve the issue.
+
+1. Ensure Docker Offload is enabled in Docker Desktop:
+
+   1. Open Docker Desktop and sign in.
+   2. Go to **Settings** > **Docker Offload**.
+   3. Ensure that **Enable Docker Offload** is toggled on.
+
+2. Use the following command to check if the connection is active:
+
+   ```console
+   $ docker offload status
+   ```
+
+3. To get more information, run the following command:
+
+   ```console
+   $ docker offload diagnose
+   ```
+
+4. If you're not connected, start a new session:
+
+   ```console
+   $ docker offload start
+   ```
+
+5. Verify authentication with `docker login`.
+
+6. If needed, you can sign out and then sign in again:
+
+   ```console
+   $ docker logout
+   $ docker login
+   ```
+
+7. Verify your usage. For more information, see [Docker Offload usage](/offload/usage/).
\ No newline at end of file
diff --git a/content/manuals/offload/usage.md b/content/manuals/offload/usage.md
new file mode 100644
index 000000000000..734b902183cd
--- /dev/null
+++ b/content/manuals/offload/usage.md
@@ -0,0 +1,79 @@
+---
+title: Docker Offload usage
+linktitle: Usage
+weight: 30
+description: Learn about Docker Offload usage and how to monitor your cloud resources.
+keywords: cloud, usage, Offload
+---
+
+{{< summary-bar feature_name="Docker Offload" >}}
+
+
+The **Offload activity** page in Docker Home provides visibility into user
+activity and session metrics for Docker Offload.
+
+To monitor your usage:
+
+1. Sign in to [Docker Home](https://app.docker.com/).
+2. If you have access to multiple organizations, select the organization
+   associated with your Docker Offload subscription.
+3. Select **Offload** > **Offload activity**.
+
+### Overview metrics
+
+Key metrics at the top of the page summarize your Docker Offload usage:
+
+- **Total duration**: The total time spent in Offload sessions
+- **Average duration**: The average time per Offload session
+- **Total sessions**: The total number of Offload sessions
+- **Unique images used**: The number of distinct container images used across
+  sessions
+- **Unique users**: The number of different users in Docker Offload sessions
+
+### Filter and export your data
+
+You can filter the Offload activity data by:
+
+- **Period**: Select a preset time period or choose a custom date range
+- **Users**: Organization owners and members with analytics permissions can
+  filter by specific users
+- **Additional Filters**: Filter by active sessions and session duration.
+
+Export your session data by selecting the **Download CSV** button. The exported
+file includes:
+
+- Session ID
+- Username
+- Image
+- Started time
+- Ended time
+- Duration (in seconds)
+- Status
+- Container count
+
+The CSV export includes data for your selected date range and user filters,
+letting you download exactly what you're viewing.
+
+### Activity cards
+
+The following cards provide insights into your Docker Offload usage:
+
+- **Offload usage**: Shows your usage trends over time and cloud resource
+  consumption patterns.
+- **Popular images**: Shows the top 4 most frequently used container images in
+  your Docker Offload sessions. Select the card to see more images.
+- **Top Offload users**: Shows the top 4 users by session count and duration. Select
+  the card to see more users.
+
+### Offload sessions
+
+A detailed list of Offload sessions appears following the activity cards. The list:
+
+- Starts with any currently active sessions
+- Shows session details including start time, duration, images used, and user
+  information
+- Can be filtered using the date and user filters described previously
+- Displays **Offload sessions** if you have organization-wide analytics
+  permissions, or **My Offload sessions** if viewing only your own data
+
+Select any session to view more details in a side panel.
\ No newline at end of file
diff --git a/content/manuals/platform-release-notes.md b/content/manuals/platform-release-notes.md
index fa0dbb2e8d4b..dc7026bcf64d 100644
--- a/content/manuals/platform-release-notes.md
+++ b/content/manuals/platform-release-notes.md
@@ -1,8 +1,8 @@
 ---
 title: Release notes for Docker Home, the Admin Console, billing, security, and subscription features
 linkTitle: Release notes
-description: Learn about the new features, bug fixes, and breaking changes for Docker Home, the Admin Console, and billing and subscription features
-keywords: Docker Home, Docker Admin Console, billing, subscription, security, admin, releases, what's new
+description: Learn about the new features, bug fixes, and breaking changes for Docker Home and billing and subscription features
+keywords: Docker Home, billing, subscription, security, admin, releases, what's new
 weight: 60
 params:
   sidebar:
@@ -12,6 +12,25 @@ tags: [Release notes, admin]
 
 This page provides details on new features, enhancements, known issues, and bug fixes across Docker Home, the Admin Console, billing, security, and subscription functionalities.
 
+## 2026-02-13
+
+### New
+
+- Administrators can now control whether organization members can push content
+  to their personal namespaces on Docker Hub with [namespace access
+  control](/manuals/enterprise/security/hardened-desktop/namespace-access.md).
+- Administrators can now prevent creating public repositories within
+  organization namespaces using the [Disable public
+  repositories](/manuals/docker-hub/settings.md#disable-creation-of-public-repos) setting.
+
+## 2026-01-27
+
+### New
+
+- Administrators can now use an allow list with [Image Access
+  Management](/manuals/enterprise/security/hardened-desktop/image-access-management.md)
+  to approve specific repositories that bypass image access controls.
+
 ## 2025-01-30
 
 ### New
@@ -24,7 +43,7 @@ This page provides details on new features, enhancements, known issues, and bug
 ### New
 
 - New Docker subscriptions are now available. For more information, see [Docker
-  subscriptions and features](/manuals/subscription/details.md) and [Announcing
+  subscriptions and features](https://www.docker.com/pricing?ref=Docs&refAction=DocsPlatformReleaseNotes) and [Announcing
   Upgraded Docker Plans: Simpler, More Value, Better Development and
   Productivity](https://www.docker.com/blog/november-2024-updated-plans-announcement/).
 
@@ -33,22 +52,22 @@ This page provides details on new features, enhancements, known issues, and bug
 ### New
 
 - Administrators can now:
-  - Enforce sign-in with [configuration profiles](/manuals/security/for-admins/enforce-sign-in/methods.md#configuration-profiles-method-mac-only) (Early Access).
+  - Enforce sign-in with [configuration profiles](/manuals/enterprise/security/enforce-sign-in/methods.md#configuration-profiles-method-mac-only) (Early Access).
   - Enforce sign-in for more than one organization at a time (Early Access).
-  - Deploy Docker Desktop for Mac in bulk with the [PKG installer](/manuals/desktop/setup/install/enterprise-deployment/pkg-install-and-configure.md) (Early Access).
-  - [Use Desktop Settings Management via the Docker Admin Console](/manuals/security/for-admins/hardened-desktop/settings-management/configure-admin-console.md) (Early Access).
+  - Deploy Docker Desktop for Mac in bulk with the [PKG installer](/manuals/enterprise/enterprise-deployment/pkg-install-and-configure.md) (Early Access).
+  - [Use Desktop Settings Management via the Docker Admin Console](/manuals/enterprise/security/hardened-desktop/settings-management/configure-admin-console.md) (Early Access).
 
 ### Bug fixes and enhancements
 
 - Enhance Container Isolation (ECI) has been improved to:
-  - Permit admins to [turn off Docker socket mount restrictions](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md#allowing-all-containers-to-mount-the-docker-socket).
-  - Support wildcard tags when using the [`allowedDerivedImages` setting](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md#docker-socket-mount-permissions-for-derived-images).
+  - Permit admins to [turn off Docker socket mount restrictions](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md#allowing-all-containers-to-mount-the-docker-socket).
+  - Support wildcard tags when using the [`allowedDerivedImages` setting](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/config.md#docker-socket-mount-permissions-for-derived-images).
 
 ## 2024-11-11
 
 ### New
 
-- [Personal access tokens](/security/for-developers/access-tokens/) (PATs) now support expiration dates.
+- [Personal access tokens](/security/access-tokens/) (PATs) now support expiration dates.
 
 ## 2024-10-15
 
@@ -60,17 +79,17 @@ This page provides details on new features, enhancements, known issues, and bug
 
 ### New
 
-- Deploying Docker Desktop via the [MSI installer](/manuals/desktop/setup/install/enterprise-deployment/msi-install-and-configure.md) is now generally available.
-- Two new methods to [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) (Windows registry key and `.plist` file) are now generally available.
+- Deploying Docker Desktop via the [MSI installer](/manuals/enterprise/enterprise-deployment/msi-install-and-configure.md) is now generally available.
+- Two new methods to [enforce sign-in](/manuals/enterprise/security/enforce-sign-in/_index.md) (Windows registry key and `.plist` file) are now generally available.
 
 ## 2024-08-24
 
 ### New
 
-- Administrators can now view [organization insights](/manuals/admin/organization/insights.md) (Early Access).
+- Administrators can now view [organization Insights](/manuals/admin/insights.md).
 
 ## 2024-07-17
 
 ### New
 
-- You can now centrally access and manage Docker products in [Docker Home](https://app.docker.com) (Early Access).
\ No newline at end of file
+- You can now centrally access and manage Docker products in [Docker Home](https://app.docker.com).
\ No newline at end of file
diff --git a/content/manuals/release-lifecycle.md b/content/manuals/release-lifecycle.md
index 4b54d2cc3c3d..fc90321ae5d1 100644
--- a/content/manuals/release-lifecycle.md
+++ b/content/manuals/release-lifecycle.md
@@ -6,7 +6,7 @@ description: Describes the various stages of feature lifecycle from beta
 keywords: beta, GA, Early Access,
 params:
   sidebar:
-    group: Products
+    group: Application development
 ---
 
 This page details Docker's product release lifecycle and how Docker defines each stage. It also provides information on the product retirement process. Features and products may progress through some or all of these phases. 
diff --git a/content/manuals/retired.md b/content/manuals/retired.md
index 1a2a083fb1e6..2b5401bfd6b7 100644
--- a/content/manuals/retired.md
+++ b/content/manuals/retired.md
@@ -4,18 +4,18 @@ linkTitle: Deprecated products and features
 description: |
   Explore deprecated and retired Docker features, products, and open source
   projects, including details on transitioned tools and archived initiatives.
+keywords: deprecated, retired, docker products, docker features, legacy
 params:
   sidebar:
-    group: Products
+    group: Application development
 aliases:
+  - /docker-hub/service-accounts/
   - /cloud/
-  - /cloud/aci-compose-features/
   - /cloud/aci-container-features/
   - /cloud/aci-integration/
   - /cloud/ecs-architecture/
-  - /cloud/ecs-compose-examples/
-  - /cloud/ecs-compose-features/
   - /cloud/ecs-integration/
+  - /compose/migrate/
   - /engine/context/aci-integration/
   - /engine/context/ecs-integration/
   - /machine/
@@ -62,6 +62,9 @@ aliases:
   - /toolbox/overview/
   - /toolbox/toolbox_install_mac/
   - /toolbox/toolbox_install_windows/
+  - /desktop/features/dev-environments/
+  - /scout/policy/scores/
+  - /scout/integrations/environment/sysdig/
 ---
 
 This document provides an overview of Docker features, products, and
@@ -118,9 +121,9 @@ Mirantis Kubernetes Engine or other products offered by Mirantis. Much of the
 technology and features found in Docker EE have been absorbed into the Mirantis
 product line.
 
-> [!NOTE]  
+> [!TIP]  
 > For information about enterprise-level features offered by Docker today,
-> see the [Docker Business subscription](/manuals/subscription/details.md#docker-business).
+> see the [Docker Business subscription](https://www.docker.com/pricing?ref=Docs&refAction=DocsRetired).
 
 ### Docker Data Center and Docker Trusted Registry
 
@@ -135,11 +138,87 @@ guidance on modern equivalents.
 ### Dev Environments
 
 Dev Environments was a feature introduced in Docker Desktop that allowed
-developers to spin up development environments quickly. This feature is no
-longer under active development. Similar workflows can be achieved through
+developers to spin up development environments quickly. It was deprecated and removed from Docker Desktop version 4.42 and later. Similar workflows can be achieved through
 Docker Compose or by creating custom configurations tailored to specific
 project requirements.
 
+### Docker Desktop sandboxes
+
+Docker Desktop sandboxes let users run AI coding agents in isolated microVMs
+through the `docker sandbox` command. The `docker sandbox` plugin was removed
+in Docker Desktop 4.80.0. Use the standalone
+[`sbx` CLI](/manuals/ai/sandboxes/_index.md) instead.
+
+### Docker Scout features
+
+The following Docker Scout features have been retired or deprecated. For
+details, see the [Scout platform release notes](/manuals/scout/release-notes/platform.md).
+
+- Health scores and Scout Everywhere: graded Docker Hub images from A to F
+  based on policy compliance, surfaced across Docker Hub. Retired July 1, 2026.
+- Sysdig integration: detected images running in your cluster via the Sysdig API.
+  Retired July 1, 2026.
+- GitHub source code management integration: linked images to their source
+  repository and automated base-image updates via PRs. Retired July 1, 2026.
+  For migration options, see
+  [GitHub integration](/manuals/scout/integrations/source-code-management/github.md).
+- Notifications: alerted users to newly disclosed CVEs in-product and by email.
+  Deprecated, retiring September 1, 2026.
+- Slack integration: sent vulnerability and policy compliance notifications to
+  Slack channels. Deprecated, retiring July 30, 2026. For more information,
+  see [Slack integration](/manuals/scout/integrations/team-collaboration/slack.md).
+- Amazon ECR integration: automatically analyzed images pushed to ECR
+  registries. Deprecated, retiring September 1, 2026. For migration options, see
+  [ECR integration](/manuals/scout/integrations/registry/ecr.md).
+- Azure Container Registry integration: automatically analyzed images pushed to
+  ACR registries. Deprecated, retiring September 1, 2026. For migration options,
+  see [ACR integration](/manuals/scout/integrations/registry/acr.md).
+- Policies page in the Dashboard: the `docker scout policy`
+  CLI continues to work. Deprecated, retiring September 1, 2026. See
+  [Evaluate policies](/manuals/scout/policy/local.md).
+- SonarQube integration: surfaced SonarQube quality gate results as a Docker Scout policy. Deprecated, retiring September 1, 2026.
+
+### GitHub Copilot extension
+
+The Docker for GitHub Copilot extension integrated Docker capabilities with
+GitHub Copilot Chat, helping developers containerize applications, generate
+Docker assets, and analyze vulnerabilities through conversational prompts. The
+extension was available in early access on the GitHub Marketplace. GitHub
+[deprecated Copilot Extensions](https://github.blog/changelog/2025-09-24-deprecate-github-copilot-extensions-github-apps/)
+which led to the retirement of the Docker for GitHub Copilot extension. If
+you're looking for AI-assisted Docker workflows, explore the Docker MCP Toolkit
+and MCP Catalog, or use Gordon in Docker Desktop and the Docker CLI.
+
+### Enhanced Service Account add-ons
+
+Enhanced Service Account add-ons provided tiered pull rate limits for automated
+workflows and service accounts accessing Docker Hub.
+
+Docker recommends transitioning to [Organization Access Tokens
+(OATs)](/manuals/enterprise/security/access-tokens.md), which provide secure,
+programmatic access to Docker Hub with granular repository permissions, token
+expiration, and better security auditing. OATs are included with Docker Team
+and Business subscriptions and offer similar functionality without requiring
+separate add-on purchases.
+
+### Docker Hub Automated Builds
+
+Docker Hub Automated Builds was a feature of Docker Hub that allowed building
+Docker images from source code in an external repository and automatically pushing
+the built image to your Docker repositories. This feature has been deprecated and
+will be removed on April 1, 2027.
+
+### Docker Content Trust (DCT)
+
+Docker Content Trust (DCT) and the Notary v1 service at `notary.docker.io` are
+being fully retired. If you've never set `DOCKER_CONTENT_TRUST=1` or used
+`docker trust` commands, this change doesn't affect you. The service shuts down
+completely on December 8, 2026, following brownout windows in July and August.
+For the timeline, migration guidance, and modern alternatives such as
+Sigstore/Cosign and Notation, see the [Docker Content Trust retirement and
+migration blog post](https://www.docker.com/blog/docker-content-trust-retirement-and-migration-guidance/).
+
+
 ## Open source projects
 
 Several open-source projects originally maintained by Docker have been
@@ -163,6 +242,15 @@ v1 is no longer maintained, and users should migrate to Compose v2.
 
 [Compose v2 Documentation](/manuals/compose/_index.md)
 
+### Docker SBOM CLI plugin
+
+The Docker SBOM CLI plugin provided the `docker sbom` command for generating
+and viewing software bill of materials (SBOMs) for container images. The plugin
+is discontinued. Use [`docker scout sbom`](/reference/cli/docker/scout/sbom/)
+for SBOM generation and inspection.
+
+[See Docker SBOM CLI plugin release notes for migration guidance](https://github.com/docker/sbom-cli-plugin/releases/tag/v0.7.0)
+
 ### InfraKit
 
 InfraKit was an open-source toolkit designed to manage declarative
diff --git a/content/manuals/scout/_index.md b/content/manuals/scout/_index.md
index a7e3c3b3cd69..2de739f7f90a 100644
--- a/content/manuals/scout/_index.md
+++ b/content/manuals/scout/_index.md
@@ -8,40 +8,40 @@ aliases:
   - /engine/scan/
 params:
   sidebar:
-    group: Products
+    group: Supply chain security
 grid:
   - title: Quickstart
     link: /scout/quickstart/
     description: Learn what Docker Scout can do, and how to get started.
-    icon: explore
+    icon: magnifying-glass-plus
   - title: Image analysis
     link: /scout/image-analysis/
     description: Reveal and dig into the composition of your images.
-    icon: radar
+    icon: signal
   - title: Advisory database
     link: /scout/advisory-db-sources/
     description: Learn about the information sources that Docker Scout uses.
-    icon: database
+    icon: circle-stack
   - title: Integrations
     description: |
       Connect Docker Scout with your CI, registries, and other third-party services.
     link: /scout/integrations/
-    icon: multiple_stop
+    icon: arrows-right-left
   - title: Dashboard
     link: /scout/dashboard/
     description: |
       The web interface for Docker Scout.
-    icon: dashboard
+    icon: squares-2x2
   - title: Policy
     link: /scout/policy/
     description: |
       Ensure that your artifacts align with supply chain best practices.
-    icon: policy
+    icon: shield-check
   - title: Upgrade
     link: /subscription/change/
     description: |
-      The free plan includes up to 1 repository. Upgrade for more.
-    icon: upgrade
+      A Personal subscription includes up to 1 repository. Upgrade for more.
+    icon: arrow-up-circle
 ---
 
 Container images consist of layers and software packages, which are susceptible to vulnerabilities.
@@ -52,7 +52,6 @@ By analyzing your images, Docker Scout compiles an inventory of components, also
 The SBOM is matched against a continuously updated vulnerability database to pinpoint security weaknesses.
 
 Docker Scout is a standalone service and platform that you can interact with
-using Docker Desktop, Docker Hub, the Docker CLI, and the Docker Scout Dashboard.
-Docker Scout also facilitates integrations with third-party systems, such as container registries and CI platforms.
+using Docker Hub, the Docker CLI, and the Docker Scout Dashboard.
 
 {{< grid >}}
diff --git a/content/manuals/scout/deep-dive/advisory-db-sources.md b/content/manuals/scout/deep-dive/advisory-db-sources.md
index ee85f2039f22..3e10c52cadc4 100644
--- a/content/manuals/scout/deep-dive/advisory-db-sources.md
+++ b/content/manuals/scout/deep-dive/advisory-db-sources.md
@@ -58,6 +58,27 @@ your SBOM is cross-referenced with the CVE information to detect how it affects
 
 For more details on how image analysis works, see the [image analysis page](/manuals/scout/explore/analysis.md).
 
+## Severity and scoring priority
+
+Docker Scout uses two main principles when determining severity and scoring for
+CVEs:
+
+   - Source priority
+   - CVSS version preference
+
+For source priority, Docker Scout follows this order:
+
+  1. Vendor advisories: Scout always uses the severity and scoring data from the
+     source that matches the package and version. For example, Debian data for
+     Debian packages.
+
+  2. NIST scoring data: If the vendor doesn't provide scoring data for a CVE,
+     Scout falls back to NIST scoring data.
+
+For CVSS version preference, once Scout has selected a source, it prefers CVSS
+v4 over v3 when both are available, as v4 is the more modern and precise scoring
+model.
+
 ## Vulnerability matching
 
 Traditional tools often rely on broad [Common Product Enumeration (CPE)](https://en.wikipedia.org/wiki/Common_Platform_Enumeration) matching,
diff --git a/content/manuals/scout/deep-dive/data-handling.md b/content/manuals/scout/deep-dive/data-handling.md
index 92ae3d4af8b3..9811d4ebc1e7 100644
--- a/content/manuals/scout/deep-dive/data-handling.md
+++ b/content/manuals/scout/deep-dive/data-handling.md
@@ -70,7 +70,7 @@ and packages, and application-level packages such as maven, npm, and so on.
 ### Environment metadata
 
 If you integrate Docker Scout with your runtime environment via the
-[Sysdig integration](/manuals/scout/integrations/environment/sysdig.md),
+[CLI integration](/manuals/scout/integrations/environment/cli.md),
 Docker Scout collects the following data points about your deployments:
 
 - Kubernetes namespace
diff --git a/content/manuals/scout/explore/analysis.md b/content/manuals/scout/explore/analysis.md
index a4f16b2ef37a..87d1d4b3ea0d 100644
--- a/content/manuals/scout/explore/analysis.md
+++ b/content/manuals/scout/explore/analysis.md
@@ -29,11 +29,8 @@ see [Integrating Docker Scout with other systems](/manuals/scout/integrations/_i
 
 ## Activate Docker Scout on a repository
 
-Docker Personal comes with 1 Scout-enabled repository. You can upgrade your
-Docker subscription if you need additional repositories.
-See [Subscriptions and features](../../subscription/details.md)
-to learn how many Scout-enabled
-repositories come with each subscription tier.
+See [Subscriptions and features](https://www.docker.com/pricing?ref=Docs&refAction=DocsScoutAnalysis)
+to learn how many Scout-enabled repositories come with each subscription tier.
 
 Before you can activate image analysis on a repository in a third-party registry,
 the registry must be integrated with Docker Scout for your Docker organization.
@@ -183,8 +180,8 @@ $ docker scout cves --format only-packages --only-vuln-packages \
 For more information about these commands and how to use them, refer to the CLI
 reference documentation:
 
-- [`docker scout quickview`](/reference/cli/docker/scout/quickview.md)
-- [`docker scout cves`](/reference/cli/docker/scout/cves.md)
+- [`docker scout quickview`](/reference/cli/docker/scout/quickview/)
+- [`docker scout cves`](/reference/cli/docker/scout/cves/)
 
 ## Vulnerability severity assessment
 
@@ -208,9 +205,10 @@ categorized as **Unspecified** (U).
 
 Docker Scout doesn't implement a proprietary vulnerability metrics system. All
 metrics are inherited from security advisories that Docker Scout integrates
-with. Advisories may use different thresholds for classifying vulnerabilities,
-but most of them adhere to the CVSS v3.0 specification, which maps CVSS scores
-to severity ratings according to the following table:
+with. Advisories may use different thresholds for classifying vulnerabilities.
+When the selected advisory source provides both CVSS v4 and v3 data, Docker
+Scout prefers CVSS v4. The qualitative severity ratings defined by CVSS v3.x
+and v4.0 use the same score ranges:
 
 | CVSS score | Severity rating  |
 | ---------- | ---------------- |
@@ -229,10 +227,7 @@ rating system.
 
 Image analysis on the Docker Scout platform, and analysis triggered by background
 indexing in Docker Desktop, has an image file size limit of 10 GB (uncompressed).
-To analyze images larger than that, you can either:
+To analyze images larger than that:
 
-- Attach [SBOM attestations](/manuals/build/metadata/attestations/sbom.md) at build-time
-- Use the [CLI](#cli) to analyze the image locally
-
-Images analyzed locally with the CLI and images with SBOM attestations
-have no maximum file size.
+- Attach an [SBOM attestation](/manuals/build/metadata/attestations/sbom.md) at build-time. When an image includes an SBOM attestation, Docker Scout uses it instead of generating one, so the 10 GB limit doesn’t apply.
+- Alternatively, you can use the [CLI](#cli) to analyze the image locally. The 10 GB limit doesn’t apply when using the CLI. If the image includes an SBOM attestation, the CLI uses it to complete the analysis faster.
diff --git a/content/manuals/scout/explore/dashboard.md b/content/manuals/scout/explore/dashboard.md
index af6d75e4e658..6608452eeee0 100644
--- a/content/manuals/scout/explore/dashboard.md
+++ b/content/manuals/scout/explore/dashboard.md
@@ -1,20 +1,21 @@
 ---
 description: The Docker Scout Dashboard helps review and share the analysis of images.
-keywords: scout, scanning, analysis, vulnerabilities, Hub, supply chain, security, report,
+keywords:
+  scout, scanning, analysis, vulnerabilities, Hub, supply chain, security, report,
   reports, dashboard
 title: Dashboard
 aliases:
-- /scout/reports/
-- /scout/web-app/
-- /scout/dashboard/
+  - /scout/reports/
+  - /scout/web-app/
+  - /scout/dashboard/
 ---
 
 The [Docker Scout Dashboard](https://scout.docker.com/) helps you share the
-analysis of images in an organization with your team. Developers can now see an
-overview of their security status across all their images from both Docker Hub
-and Artifactory, and get remediation advice at their fingertips. It helps team
-members in roles such as security, compliance, and operations to know what
-vulnerabilities and issues they need to focus on.
+analysis of images in an organization with your team. Developers can see an
+overview of their security status across all their images from Docker Hub, and
+get remediation advice at their fingertips. It helps team members in roles such
+as security, compliance, and operations to know what vulnerabilities and issues
+they need to focus on.
 
 ## Overview
 
@@ -27,11 +28,6 @@ At the top of this page, you can select which **Environment** to view.
 By default, the most recently pushed images are shown. To learn more about
 environments, see [Environment monitoring](/manuals/scout/integrations/environment/_index.md).
 
-The **Policy** boxes show your current compliance rating for each policy, and a
-trend indication for the selected environment. The trend describes the policy
-delta for the most recent images compared to the previous version.
-For more information about policies, see [Policy Evaluation](/manuals/scout/policy/_index.md).
-
 The vulnerability chart shows the total number of vulnerabilities for images in
 the selected environment over time. You can configure the timescale for the
 chart using the drop-down menu.
@@ -39,22 +35,12 @@ chart using the drop-down menu.
 Use the header menu at the top of the website to access the different main
 sections of the Docker Scout Dashboard:
 
-- **Policies**: shows the policy compliance for the organization, see [Policies](#policies)
 - **Images**: lists all Docker Scout-enabled repositories in the organization, see [Images](#images)
 - **Base images**: lists all base images used by repositories in an organization
 - **Packages**: lists all packages across repositories in the organization
 - **Vulnerabilities**: lists all CVEs in the organization's images, see [Vulnerabilities](#vulnerabilities)
-- **Integrations**: create and manage third-party integrations, see [Integrations](#integrations)
 - **Settings**: manage repository settings, see [Settings](#settings)
 
-## Policies
-
-The **Policies** view shows a breakdown of policy compliance for all of the
-images in the selected organization and environment. You can use the **Image**
-drop-down menu to view a policy breakdown for a specific environment.
-
-For more information about policies, see [Policy Evaluation](/manuals/scout/policy/_index.md).
-
 ## Images
 
 The **Images** view shows all images in Scout-enabled repositories for the selected environment.
@@ -68,23 +54,15 @@ For each repository, the list displays the following details:
 - The most recent tag of the image in the selected environment
 - Operating systems and architectures for the most recent tag
 - Vulnerabilities status for the most recent tag
-- Policy status for the most recent tag
 
 Selecting a repository link takes you to a list of all images in that repository that have been analyzed.
 From here you can view the full analysis results for a specific image,
 and compare tags to view the differences in packages and vulnerabilities
 
 Selecting an image link takes you to a details view for the selected tag or digest.
-This view contains two tabs that detail the composition and policy compliance for the image:
-
-- **Policy status** shows the policy evaluation results for the selected image.
-  Here you also have links for details about the policy violations.
-
-  For more information about policy, see [Policy Evaluation](/manuals/scout/policy/_index.md).
-
-- **Image layers** shows a breakdown of the image analysis results.
-  You can get a complete view of the vulnerabilities your image contains
-  and understand how they got in.
+The **Image layers** tab shows a breakdown of the image analysis results.
+You can get a complete view of the vulnerabilities your image contains
+and understand how they got in.
 
 ## Vulnerabilities
 
@@ -101,19 +79,12 @@ even if they're not a member of your Docker organization or signed in to Docker
 If you are signed in, the **My images** tab on this page lists all of your images
 affected by the CVE.
 
-## Integrations
-
-The **Integrations** page lets you create and manage your Docker Scout
-integrations, such as environment integrations and registry integrations. For
-more information on how to get started with integrations, see
-[Integrating Docker Scout with other systems](/manuals/scout/integrations/_index.md).
-
 ## Settings
 
 The settings menu in the Docker Scout Dashboard contains:
 
-- [**Repository settings**](#repository-settings) for enabling and disabling repositories
-- [**Notifications**](#notification-settings) for managing your notification preferences for Docker Scout.
+- [**Repository settings**](#repository-settings) for enabling and disabling repositories.
+- [**Notifications**](#notification-settings) for managing your notification preferences.
 
 ### Repository settings
 
@@ -125,57 +96,34 @@ See [Container registry integrations](/manuals/scout/integrations/_index.md#cont
 
 ### Notification settings
 
+> [!IMPORTANT]
+>
+> Docker Scout notifications are deprecated and will be retired on
+> July 30, 2026. To surface CVE and policy results without push notifications,
+> integrate `docker scout cves` or `docker scout policy` into your CI pipeline.
+> See [CI integrations](/manuals/scout/integrations/_index.md#continuous-integration).
+> For details, see the
+> [Scout platform release notes](/manuals/scout/release-notes/platform.md).
+
 The [Notification settings](https://scout.docker.com/settings/notifications)
 page is where you can change the preferences for receiving notifications from
 Docker Scout. Notification settings are personal, and changing notification
 settings only affects your personal account, not the entire organization.
 
-The purpose of notifications in Docker Scout is to raise awareness about
-upstream changes that affect you. Docker Scout will notify you about when a new
-vulnerability is disclosed in a security advisory, and it affects one or more
-of your images. You will not receive notifications about changes to
-vulnerability exposure or policy compliance as a result of pushing a new image.
-
-> [!NOTE]
->
-> Notifications are only triggered for the *last pushed* image tags for each
-> repository. "Last pushed" refers to the image tag that was most recently
-> pushed to the registry and analyzed by Docker Scout. If the last pushed image
-> is not affected by a newly disclosed CVE, then no notification will be
-> triggered.
+Docker Scout notifies you when a new vulnerability is disclosed in a security
+advisory and it affects one or more of your images. Notifications are only
+triggered for the _last pushed_ image tags for each repository.
 
 The available notification settings are:
 
-- **Repository scope**
-
-  Here you can select whether you want to enable notifications for all
-  repositories, or only for specific repositories. These settings apply to the
-  currently selected organization, and can be changed for each organization you
-  are a member of.
-
-  - **All repositories**: select this option to receive notifications for all
-    repositories that you have access to.
-  - **Specific repositories**: select this option to receive notifications for
-    specific repositories. You can then enter the names of repositories you
-    want to receive notifications for.
-
-- **Delivery preferences**
-
-  These settings control how you receive notifications from Docker Scout. They
-  apply to all organizations that you're a member of.
-
-  - **Notification pop-ups**: select this check-box to receive notification
-    pop-up messages in the Docker Scout Dashboard.
-  - **OS notifications**: select this check-box to receive OS-level notifications
-    from your browser if you have the Docker Scout Dashboard open in a browser
-    tab.
-  
-  To enable OS notifications, Docker Scout needs permissions to send
-  notifications using the browser API.
-
-From this page, you can also go to the settings for Team collaboration
-integrations, such as the [Slack](/manuals/scout/integrations/team-collaboration/slack.md)
-integration.
+- **Repository scope**: select whether you want notifications for all
+  repositories or only specific ones.
+- **Delivery preferences**: choose between in-product notification pop-ups
+  and OS-level browser notifications.
 
 You can also configure your notification settings in Docker Desktop by going
 to **Settings** > **Notifications**.
+
+From this page, you can also go to the settings for
+[Team collaboration integrations](/manuals/scout/integrations/team-collaboration/slack.md).
+
diff --git a/content/manuals/scout/explore/metrics-exporter.md b/content/manuals/scout/explore/metrics-exporter.md
index 5426d265a8b1..8141eef331a4 100644
--- a/content/manuals/scout/explore/metrics-exporter.md
+++ b/content/manuals/scout/explore/metrics-exporter.md
@@ -40,7 +40,7 @@ To export metrics from your organization, first make sure your organization is e
 Then, create a Personal Access Token (PAT) - a secret token that allows the exporter to authenticate with the Docker Scout API.
 
 The PAT does not require any specific permissions, but it must be created by a user who is an owner of the Docker organization.
-To create a PAT, follow the steps in [Create an access token](/security/for-developers/access-tokens/#create-an-access-token).
+To create a PAT, follow the steps in [Create an access token](/manuals/security/access-tokens.md).
 
 Once you have created the PAT, store it in a secure location.
 You will need to provide this token to the exporter when scraping metrics.
@@ -108,7 +108,7 @@ alongside Grafana with a pre-configured dashboard to visualize the vulnerability
    $ cd scout-metrics-exporter/prometheus
    ```
 
-2. [Create a Docker access token](/security/for-developers/access-tokens/#create-an-access-token)
+2. [Create a Docker access token](/manuals/security/access-tokens.md)
    and store it in a plain text file at `/prometheus/prometheus/token` under the template directory.
 
    ```plaintext {title=token}
@@ -118,7 +118,7 @@ alongside Grafana with a pre-configured dashboard to visualize the vulnerability
 3. In the Prometheus configuration file at `/prometheus/prometheus/prometheus.yml`,
    replace `ORG` in the `metrics_path` property on line 6 with the namespace of your Docker organization.
 
-   ```yaml {title="prometheus/prometheus.yml",hl_lines="6",linenos=1}
+   ```yaml {title="prometheus/prometheus.yml",hl_lines="6",linenos=true}
    global:
      scrape_interval: 60s
      scrape_timeout: 40s
@@ -241,7 +241,7 @@ and a Datadog site.
    $ cd scout-metrics-exporter/datadog
    ```
 
-2. [Create a Docker access token](/security/for-developers/access-tokens/#create-an-access-token)
+2. [Create a Docker access token](/manuals/security/access-tokens.md)
    and store it in a plain text file at `/datadog/token` under the template directory.
 
    ```plaintext {title=token}
@@ -347,7 +347,7 @@ To change the scrape interval:
 ## Revoke an access token
 
 If you suspect that your PAT has been compromised or is no longer needed, you can revoke it at any time.
-To revoke a PAT, follow the steps in the [Create and manage access tokens](/security/for-developers/access-tokens/#modify-existing-tokens).
+To revoke a PAT, follow the steps in the [Create and manage access tokens](/manuals/security/access-tokens.md).
 
 Revoking a PAT immediately invalidates the token, and prevents Prometheus from scraping metrics using that token.
 You will need to create a new PAT and update the Prometheus configuration to use the new token.
diff --git a/content/manuals/scout/how-tos/artifact-types.md b/content/manuals/scout/how-tos/artifact-types.md
index e62a1452dffc..b7ecac47d074 100644
--- a/content/manuals/scout/how-tos/artifact-types.md
+++ b/content/manuals/scout/how-tos/artifact-types.md
@@ -176,6 +176,6 @@ $ docker scout sbom --format spdx -o sbom.spdx.json archive://scout-cli.tar
 
 Read about the commands and supported flags in the CLI reference documentation:
 
-- [`docker scout quickview`](/reference/cli/docker/scout/quickview.md)
-- [`docker scout cves`](/reference/cli/docker/scout/cves.md)
-- [`docker scout compare`](/reference/cli/docker/scout/compare.md)
+- [`docker scout quickview`](/reference/cli/docker/scout/quickview/)
+- [`docker scout cves`](/reference/cli/docker/scout/cves/)
+- [`docker scout compare`](/reference/cli/docker/scout/compare/)
diff --git a/content/manuals/scout/how-tos/create-exceptions-vex.md b/content/manuals/scout/how-tos/create-exceptions-vex.md
index 5f420ae2f007..8034abe001c3 100644
--- a/content/manuals/scout/how-tos/create-exceptions-vex.md
+++ b/content/manuals/scout/how-tos/create-exceptions-vex.md
@@ -24,8 +24,13 @@ To create exceptions using OpenVEX documents, you need:
 
 - The latest version of Docker Desktop or the Docker Scout CLI plugin
 - The [`vexctl`](https://github.com/openvex/vexctl) command line tool.
-- The [containerd image store](/manuals/desktop/features/containerd.md) must be enabled
+
+Additional requirements depend on how you attach the VEX document:
+
+- The [containerd image store](/manuals/desktop/features/containerd.md)
+  must be enabled to attach the document as an attestation.
 - Write permissions to the registry repository where the image is stored
+  are required to attach the document as an attestation.
 
 ## Introduction to VEX
 
@@ -246,7 +251,9 @@ change the VEX document.
 
 To attach VEX documents as an attestation, you can use the `docker scout
 attestation add` CLI command. Using attestations is the recommended option for
-attaching exceptions to images when using VEX.
+attaching exceptions to images when using VEX. This method requires the
+[containerd image store](/manuals/desktop/features/containerd.md) and write
+access to the registry repository where the image is stored.
 
 You can attach attestations to images that have already been pushed to a
 registry. You don't need to build or push the image again. Additionally, having
@@ -280,6 +287,8 @@ To attach an attestation to an image:
 Embedding VEX documents directly on the image filesystem is a good option if
 you know the exceptions ahead of time, before you build the image. And it's
 relatively easy; just `COPY` the VEX document to the image in your Dockerfile.
+Unlike attestations, this method doesn't require the containerd image store or
+write access to a registry before the image is pushed.
 
 The downside with this approach is that you can't change or update the
 exception later. Image layers are immutable, so anything you put in the image's
@@ -315,4 +324,3 @@ It doesn't matter where on the image's filesystem you store the file.
 
 Note that the copied files must be part of the filesystem of the final image,
 For multi-stage builds, the documents must persist in the final stage.
-
diff --git a/content/manuals/scout/how-tos/view-create-sboms.md b/content/manuals/scout/how-tos/view-create-sboms.md
index c05cdc838dd5..16b45ed8aa28 100644
--- a/content/manuals/scout/how-tos/view-create-sboms.md
+++ b/content/manuals/scout/how-tos/view-create-sboms.md
@@ -57,7 +57,7 @@ $ docker scout sbom --format list alpine
 ```
 
 For more information about the `docker scout sbom` command, refer to the [CLI
-reference](/reference/cli/docker/scout/sbom.md).
+reference](/reference/cli/docker/scout/sbom/).
 
 ## Attach as build attestation {#attest}
 
diff --git a/content/manuals/scout/images/policy-detailed-results.webp b/content/manuals/scout/images/policy-detailed-results.webp
deleted file mode 100644
index c74365a73a8b..000000000000
Binary files a/content/manuals/scout/images/policy-detailed-results.webp and /dev/null differ
diff --git a/content/manuals/scout/images/policy-image-list.webp b/content/manuals/scout/images/policy-image-list.webp
deleted file mode 100644
index fd9d512d21ba..000000000000
Binary files a/content/manuals/scout/images/policy-image-list.webp and /dev/null differ
diff --git a/content/manuals/scout/images/policy-overview.webp b/content/manuals/scout/images/policy-overview.webp
deleted file mode 100644
index 5ea82e2e05b7..000000000000
Binary files a/content/manuals/scout/images/policy-overview.webp and /dev/null differ
diff --git a/content/manuals/scout/images/policy-tag-view.webp b/content/manuals/scout/images/policy-tag-view.webp
deleted file mode 100644
index 7c7ec91fd865..000000000000
Binary files a/content/manuals/scout/images/policy-tag-view.webp and /dev/null differ
diff --git a/content/manuals/scout/images/release-notes/artifactory-agent.gif b/content/manuals/scout/images/release-notes/artifactory-agent.gif
deleted file mode 100644
index eaa7b6c3f9e9..000000000000
Binary files a/content/manuals/scout/images/release-notes/artifactory-agent.gif and /dev/null differ
diff --git a/content/manuals/scout/images/remediation.png b/content/manuals/scout/images/remediation.png
deleted file mode 100644
index 1ea18e46439f..000000000000
Binary files a/content/manuals/scout/images/remediation.png and /dev/null differ
diff --git a/content/manuals/scout/images/score-a-shiny.png b/content/manuals/scout/images/score-a-shiny.png
deleted file mode 100644
index 5db0254ecff5..000000000000
Binary files a/content/manuals/scout/images/score-a-shiny.png and /dev/null differ
diff --git a/content/manuals/scout/images/score-badges-dd.png b/content/manuals/scout/images/score-badges-dd.png
deleted file mode 100644
index f33374c1ec93..000000000000
Binary files a/content/manuals/scout/images/score-badges-dd.png and /dev/null differ
diff --git a/content/manuals/scout/images/score-badges-repolist.png b/content/manuals/scout/images/score-badges-repolist.png
deleted file mode 100644
index dcfb016bbb4e..000000000000
Binary files a/content/manuals/scout/images/score-badges-repolist.png and /dev/null differ
diff --git a/content/manuals/scout/images/scout-policy-eval-ci.webp b/content/manuals/scout/images/scout-policy-eval-ci.webp
deleted file mode 100644
index 6643e3232553..000000000000
Binary files a/content/manuals/scout/images/scout-policy-eval-ci.webp and /dev/null differ
diff --git a/content/manuals/scout/images/scout-sq-commit-sha.webp b/content/manuals/scout/images/scout-sq-commit-sha.webp
deleted file mode 100644
index 5d0170979664..000000000000
Binary files a/content/manuals/scout/images/scout-sq-commit-sha.webp and /dev/null differ
diff --git a/content/manuals/scout/install.md b/content/manuals/scout/install.md
index 078f5db791a8..72a20e15113e 100644
--- a/content/manuals/scout/install.md
+++ b/content/manuals/scout/install.md
@@ -76,7 +76,7 @@ $ sh install-scout.sh
 5. Authorize the binary to be executable on macOS:
 
    ```console
-   xattr -d com.apple.quarantine $HOME/.docker/scout/docker-scout.
+   xattr -d com.apple.quarantine $HOME/.docker/scout/docker-scout
    ```
 
 6. Add the `scout` subdirectory to your `.docker/config.json` as a plugin directory:
diff --git a/content/manuals/scout/integrations/_index.md b/content/manuals/scout/integrations/_index.md
index ce945300e096..a37b83a68d29 100644
--- a/content/manuals/scout/integrations/_index.md
+++ b/content/manuals/scout/integrations/_index.md
@@ -1,5 +1,5 @@
 ---
-description: How to setup Docker Scout with other systems.
+description: How to set up Docker Scout with other systems.
 keywords: supply chain, security, integrations, registries, ci, environments
 title: Integrating Docker Scout with other systems
 linkTitle: Integrations
@@ -25,14 +25,14 @@ aren't hosted on Docker Hub.
 
 The following container registry integrations are available:
 
-- [Artifactory](./registry/artifactory.md)
-- [Amazon Elastic Container Registry](./registry/ecr.md)
-- [Azure Container Registry](./registry/acr.md)
+- [Amazon Elastic Container Registry](./registry/ecr.md) (deprecated, retiring September 1, 2026)
+- [Azure Container Registry](./registry/acr.md) (deprecated, retiring September 1, 2026)
+- [JFrog Artifactory](./registry/artifactory.md)
 
 ### Continuous Integration
 
-Integrating Docker Scout with Continuous Integration (CI) systems is a great
-way to get instant, automatic feedback about your security posture in your inner
+Integrating Docker Scout with Continuous Integration (CI) systems is a great way
+to get instant, automatic feedback about your security posture in your inner
 loop. Analysis running in CI also gets the benefit of additional context that's
 useful for getting even more insights.
 
@@ -52,9 +52,9 @@ This can give you information in real-time about your running container workload
 Integrating with environments lets you compare production workloads to other
 versions, in your image repositories or in your other environments.
 
-The following environment monitoring integrations are available
+The following environment monitoring integrations are available:
 
-- [Sysdig](./environment/sysdig.md)
+- [Generic CLI integration](./environment/cli.md)
 
 For more information about environment integrations, see
 [Environments](./environment/_index.md).
@@ -73,7 +73,7 @@ you've enabled the integration.
 
 The following code quality integrations are available:
 
-- [SonarQube](sonarqube.md)
+- [SonarQube](./code-quality/sonarqube.md) (deprecated, retiring September 1, 2026)
 
 ### Source code management
 
@@ -83,7 +83,7 @@ analysis, directly in your repositories.
 
 The following source code management integrations are available:
 
-- [GitHub](source-code-management/github.md) {{< badge color=blue text=Beta >}}
+- [GitHub](source-code-management/github.md) (retired)
 
 ### Team collaboration
 
@@ -93,4 +93,4 @@ real-time to team communication platforms.
 
 The following team collaboration integrations are available:
 
-- [Slack](./team-collaboration/slack.md)
+- [Slack](./team-collaboration/slack.md) (deprecated, retiring September 1, 2026)
diff --git a/content/manuals/scout/integrations/ci/_index.md b/content/manuals/scout/integrations/ci/_index.md
index 965de3e16c4f..07b3298c2538 100644
--- a/content/manuals/scout/integrations/ci/_index.md
+++ b/content/manuals/scout/integrations/ci/_index.md
@@ -1,5 +1,5 @@
 ---
-description: How to setup Docker Scout in continuous integration pipelines
+description: How to set up Docker Scout in continuous integration pipelines
 keywords: scanning, vulnerabilities, Hub, supply chain, security, ci, continuous integration,
   github actions, gitlab
 title: Using Docker Scout in continuous integration
diff --git a/content/manuals/scout/integrations/ci/circle-ci.md b/content/manuals/scout/integrations/ci/circle-ci.md
index 81123abe37da..ae8cbc2f2496 100644
--- a/content/manuals/scout/integrations/ci/circle-ci.md
+++ b/content/manuals/scout/integrations/ci/circle-ci.md
@@ -55,7 +55,7 @@ steps:
   - run:
       name: Scan image for CVEs
       command: |
-        docker-scout cves $IMAGE_TAG --exit-code --only-severity critical,high
+        docker scout cves $IMAGE_TAG --exit-code --only-severity critical,high
 ```
 
 This checks out the repository files and then sets up a separate Docker
diff --git a/content/manuals/scout/integrations/ci/gha.md b/content/manuals/scout/integrations/ci/gha.md
index 9b1ad746455f..7fe6ea486c11 100644
--- a/content/manuals/scout/integrations/ci/gha.md
+++ b/content/manuals/scout/integrations/ci/gha.md
@@ -58,19 +58,19 @@ jobs:
     steps:
       # Authenticate to the container registry
       - name: Authenticate to registry ${{ env.REGISTRY }}
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           registry: ${{ env.REGISTRY }}
           username: ${{ secrets.REGISTRY_USER }}
           password: ${{ secrets.REGISTRY_TOKEN }}
       
       - name: Setup Docker buildx
-        uses: docker/setup-buildx-action@v3
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
 
       # Extract metadata (tags, labels) for Docker
       - name: Extract Docker metadata
         id: meta
-        uses: docker/metadata-action@v5
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
         with:
           images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
           labels: |
@@ -84,7 +84,7 @@ jobs:
       # (don't push on PR, load instead)
       - name: Build and push Docker image
         id: build-and-push
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
         with:
           sbom: ${{ github.event_name != 'pull_request' }}
           provenance: ${{ github.event_name != 'pull_request' }}
@@ -121,7 +121,7 @@ image comparison:
       # You can skip this step if Docker Hub is your registry
       # and you already authenticated before
       - name: Authenticate to Docker
-        uses: docker/login-action@v3
+        uses: docker/login-action@{{% param "login_action_version" %}}
         with:
           username: ${{ secrets.DOCKER_USER }}
           password: ${{ secrets.DOCKER_PAT }}
diff --git a/content/manuals/scout/integrations/ci/jenkins.md b/content/manuals/scout/integrations/ci/jenkins.md
index ed836c197680..be88742b3b1c 100644
--- a/content/manuals/scout/integrations/ci/jenkins.md
+++ b/content/manuals/scout/integrations/ci/jenkins.md
@@ -31,7 +31,7 @@ pipeline {
                 sh 'echo $DOCKER_HUB_PSW | docker login -u $DOCKER_HUB_USR --password-stdin'
 
                 // Analyze and fail on critical or high vulnerabilities
-                sh 'docker-scout cves $IMAGE_TAG --exit-code --only-severity critical,high'
+                sh 'docker scout cves $IMAGE_TAG --exit-code --only-severity critical,high'
             }
         }
     }
diff --git a/content/manuals/scout/integrations/code-quality/sonarqube.md b/content/manuals/scout/integrations/code-quality/sonarqube.md
index ba1b552ba41b..0d2bb019732a 100644
--- a/content/manuals/scout/integrations/code-quality/sonarqube.md
+++ b/content/manuals/scout/integrations/code-quality/sonarqube.md
@@ -3,8 +3,19 @@ title: Integrate Docker Scout with SonarQube
 linkTitle: SonarQube
 description: Evaluate your images with the SonarQube quality gates defined in your projects
 keywords: scout, supply chain, integration, code quality
+params:
+  sidebar:
+    badge:
+      color: gray
+      text: Deprecated
 ---
 
+> [!IMPORTANT]
+>
+> The Docker Scout SonarQube integration is deprecated and will be retired on
+> September 1, 2026. Migration guidance will be provided. For details, see the
+> [Scout platform release notes](/manuals/scout/release-notes/platform.md).
+
 The SonarQube integration enables Docker Scout to surface SonarQube quality
 gate checks through Policy Evaluation, under a new [SonarQube Quality Gates
 Policy](/manuals/scout/policy/_index.md#sonarqube-quality-gates-policy).
diff --git a/content/manuals/scout/integrations/environment/_index.md b/content/manuals/scout/integrations/environment/_index.md
index 81c32a9f637a..61b80e0d907d 100644
--- a/content/manuals/scout/integrations/environment/_index.md
+++ b/content/manuals/scout/integrations/environment/_index.md
@@ -37,7 +37,6 @@ Docker Scout supports the following runtime integrations:
 
 - [Docker Scout GitHub Action](https://github.com/marketplace/actions/docker-scout#record-an-image-deployed-to-an-environment)
 - [CLI client](./cli.md)
-- [Sysdig integration](./sysdig.md)
 
 > [!NOTE]
 >
@@ -79,7 +78,7 @@ comparing the image built from the code in the PR to the corresponding image in
 staging or production.
 
 You can also compare with streams using the `--to-env` flag on the
-[`docker scout compare`](/reference/cli/docker/scout/compare.md)
+[`docker scout compare`](/reference/cli/docker/scout/compare/)
 CLI command:
 
 ```console
diff --git a/content/manuals/scout/integrations/environment/cli.md b/content/manuals/scout/integrations/environment/cli.md
index 1cb0cd66eb76..bf63fb23dadb 100644
--- a/content/manuals/scout/integrations/environment/cli.md
+++ b/content/manuals/scout/integrations/environment/cli.md
@@ -5,15 +5,13 @@ title: Generic environment integration with CLI
 linkTitle: Generic (CLI)
 ---
 
-{{% include "scout-early-access.md" %}}
-
 You can create a generic environment integration by running the Docker Scout
 CLI client in your CI workflows. The CLI client is available as a binary on
 GitHub and as a container image on Docker Hub. Use the client to invoke the
 `docker scout environment` command to assign your images to environments.
 
 For more information about how to use the `docker scout environment` command,
-refer to the [CLI reference](/reference/cli/docker/scout/environment.md).
+refer to the [CLI reference](/reference/cli/docker/scout/environment/).
 
 ## Examples
 
@@ -38,12 +36,12 @@ jobs:
     steps:
       - run: |
           if [[ -z "$CIRCLE_TAG" ]]; then
+            tag="$CIRCLE_BRANCH"
+            echo "Running on branch '$CIRCLE_BRANCH'"
+          else
             tag="$CIRCLE_TAG"
             echo "Running tag '$CIRCLE_TAG'"
-          else
-            tag="$CIRCLE_BRANCH"
-            echo "Running on branch '$CI_COMMIT_BRANCH'"
-          fi    
+          fi
           echo "tag = $tag"
       - run: docker run -it \
           -e DOCKER_SCOUT_HUB_USER=$DOCKER_SCOUT_HUB_USER \
@@ -67,12 +65,12 @@ record_environment:
   script:
     - |
       if [[ -z "$CI_COMMIT_TAG" ]]; then
-        tag="latest"
-        echo "Running tag '$CI_COMMIT_TAG'"
-      else
         tag="$CI_COMMIT_REF_SLUG"
         echo "Running on branch '$CI_COMMIT_BRANCH'"
-      fi    
+      else
+        tag="$CI_COMMIT_TAG"
+        echo "Running tag '$CI_COMMIT_TAG'"
+      fi
       echo "tag = $tag"
     - environment --org <MY_DOCKER_ORG> "PRODUCTION" ${image}:${tag}
 ```
@@ -100,7 +98,6 @@ stages:
         pool:
           vmImage: ubuntu-latest
         steps:
-          - task: Docker@2
           - script: docker run -it \
               -e DOCKER_SCOUT_HUB_USER=$DOCKER_SCOUT_HUB_USER \
               -e DOCKER_SCOUT_HUB_PASSWORD=$DOCKER_SCOUT_HUB_PASSWORD \
@@ -113,7 +110,7 @@ stages:
 {{< tab name="Jenkins" >}}
 
 ```groovy
-stage('Analyze image') {
+stage('Record environment') {
     steps {
         // Install Docker Scout
         sh 'curl -sSfL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh | sh -s -- -b /usr/local/bin'
@@ -121,8 +118,8 @@ stage('Analyze image') {
         // Log into Docker Hub
         sh 'echo $DOCKER_SCOUT_HUB_PASSWORD | docker login -u $DOCKER_SCOUT_HUB_USER --password-stdin'
 
-        // Analyze and fail on critical or high vulnerabilities
-        sh 'docker-scout environment --org "<MY_DOCKER_ORG>" "<ENVIRONMENT>" $IMAGE_TAG
+        // Record image to environment
+        sh 'docker-scout environment --org "<MY_DOCKER_ORG>" "<ENVIRONMENT>" $IMAGE_TAG'
     }
 }
 ```
diff --git a/content/manuals/scout/integrations/environment/sysdig.md b/content/manuals/scout/integrations/environment/sysdig.md
deleted file mode 100644
index 84415426b2f5..000000000000
--- a/content/manuals/scout/integrations/environment/sysdig.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-title: Integrate Docker Scout with Sysdig
-linkTitle: Sysdig
-description: Integrate your runtime environments with Docker Scout using Sysdig
-keywords: scout, sysdig, integration, image analysis, environments, supply chain
----
-
-{{% include "scout-early-access.md" %}}
-
-The Sysdig integration enables Docker Scout to automatically detect the images
-you're using for your running workloads. Activating this integration gives you
-real-time insights about your security posture, and lets you compare your
-builds with what's running in production.
-
-## How it works
-
-The Sysdig Agent captures the images of your container workloads. Docker Scout
-integrates with the Sysdig API to discover the images in your cluster. This
-integration uses Sysdig's Risk Spotlight feature. For more information, see
-[Risk Spotlight Integrations (Sysdig docs)](https://docs.sysdig.com/en/docs/sysdig-secure/integrations-for-sysdig-secure/risk-spotlight-integrations/).
-
-> [!TIP]
->
-> Sysdig offers a free trial for Docker users to try out the new Docker Scout integration.
->
-> {{< button url=`https://sysdig.com/free-trial-for-docker-customers/` text="Sign up" >}}
-
-Each Sysdig integration maps to an environment. When you enable a Sysdig
-integration, you specify the environment name for that cluster, such as
-`production` or `staging`. Docker Scout assigns the images in the cluster to
-the corresponding environment. This lets you use the environment filters to see
-vulnerability status and policy compliance for an environment.
-
-Only images analyzed by Docker Scout can be assigned to an environment. The
-Sysdig runtime integration doesn't trigger image analysis by itself. To analyze
-images automatically, enable a [registry integration](../_index.md#container-registries).
-
-Image analysis must not necessarily precede the runtime integration, but the
-environment assignment only takes place once Docker Scout has analyzed the
-image.
-
-## Prerequisites
-
-- Install the Sysdig Agent in the cluster that you want to integrate, see [Install Sysdig Agent (Sysdig docs)](https://docs.sysdig.com/en/docs/installation/sysdig-monitor/install-sysdig-agent/).
-- Enable profiling for Risk Spotlight Integrations in Sysdig, see [Profiling (Sysdig docs)](https://docs.sysdig.com/en/docs/sysdig-secure/policies/profiling/#enablement).
-- You must be an organization owner to enable the integration in the Docker Scout Dashboard.
-
-## Integrate an environment
-
-1. Go to the [Sysdig integration page](https://scout.docker.com/settings/integrations/sysdig/)
-   on the Docker Scout Dashboard.
-2. In the **How to integrate** section, enter a configuration name for this
-   integration. Docker Scout uses this label as a display name for the
-   integration.
-
-3. Select **Next**.
-
-4. Enter a Risk Spotlight API token and select the region in the drop-down list.
-
-   The Risk Spotlight API token is the Sysdig token that Docker Scout needs to
-   integrate with Sysdig. For more instructions on how to generate a Risk
-   Spotlight token, See [Risk Spotlight Integrations (Sysdig docs)](https://docs.sysdig.com/en/docs/sysdig-secure/integrations-for-sysdig-secure/risk-spotlight-integrations/docker-scout/#generate-a-token-for-the-integration).
-
-   The region corresponds to the `global.sysdig.region` configuration parameter
-   set when deploying the Sysdig Agent.
-
-5. Select **Next**.
-
-   After selecting **Next**, Docker Scout connects to Sysdig and retrieves the
-   cluster names for your Sysdig account. Cluster names correspond to the
-   `global.clusterConfig.name` configuration parameter set when deploying
-   Sysdig Agents.
-
-   An error displays if Docker Scout fails to connect to Sysdig using the
-   provided token. If there's an error, you won't be able to continue the
-   integration. Go back and verify that the configuration details are correct.
-
-6. Select a cluster name in the drop-down list.
-
-7. Select **Next**.
-
-8. Assign an environment name for this cluster.
-
-    You can reuse an existing environment or create a new one.
-
-9. Select **Enable integration**.
-
-After enabling the integration, Docker Scout automatically detects images
-running in the cluster, and assigns those images to the environment associated
-with the cluster. For more information about environments, see [Environment
-monitoring](./_index.md).
-
-> [!NOTE]
->
-> Docker Scout only detects images that have been analyzed. To trigger an image
-> analysis, enable a [registry integration](../_index.md#container-registries)
-> and push an image to your registry.
->
-> If you created a new environment for this integration, the environment
-> appears in Docker Scout when at least one image has been analyzed.
-
-To integrate more clusters, go to the [Sysdig integrations page](https://scout.docker.com/settings/integrations/sysdig/)
-and select the **Add** button.
diff --git a/content/manuals/scout/integrations/registry/acr.md b/content/manuals/scout/integrations/registry/acr.md
index 745d04e85b96..c0dc9b4d813c 100644
--- a/content/manuals/scout/integrations/registry/acr.md
+++ b/content/manuals/scout/integrations/registry/acr.md
@@ -3,8 +3,20 @@ description: Integrate Azure Container Registry with Docker Scout
 keywords: docker scout, acr, azure, integration, image analysis, security, cves
 title: Integrate Docker Scout with Azure Container Registry
 linkTitle: Azure Container Registry
+params:
+  sidebar:
+    badge:
+      color: gray
+      text: Deprecated
 ---
 
+> [!IMPORTANT]
+>
+> The Docker Scout Azure Container Registry integration is deprecated and will be retired on September 1, 2026.
+> Migrate to [`docker scout watch`](/reference/cli/docker/scout/watch/) for
+> continuous analysis, or integrate Scout into your CI pipeline.
+> See [Migrate from the ACR integration](#migrate-from-the-acr-integration).
+
 Integrating Docker Scout with Azure Container Registry (ACR) lets you view
 image insights for images hosted in ACR repositories. After integrating Docker
 Scout with ACR and activating Docker Scout for a repository, pushing an image
@@ -136,3 +148,105 @@ To remove an ACR integration:
 
    - The `docker-scout-readonly-token` token for the container registry.
    - The `docker-scout-repository` Event Grid System Topic.
+
+## Migrate from the ACR integration
+
+Two migration paths are available.
+
+### Continuous polling
+
+Best for teams that want ongoing, registry-wide analysis without changing
+their build pipelines. `docker scout watch` runs as a long-running process
+that polls your ACR registry and pushes results to Docker Scout, replicating
+what the integration provided.
+
+1. Pick a host on which to run `docker scout watch`.
+
+   The host must have network access to your ACR registry and be able to
+   access the Scout API (`https://api.scout.docker.com`) over the internet.
+
+2. Ensure you are running the latest version of Scout.
+
+   ```console
+   $ docker scout version
+   ```
+
+   If necessary, [install the latest version of Scout](https://docs.docker.com/scout/install/).
+
+3. Authenticate Docker to your ACR registry.
+
+   ```console
+   $ docker login <registry-name>.azurecr.io \
+     --username <username> \
+     --password <password-or-access-token>
+   ```
+
+   > [!TIP]
+   >
+   > As a best practice, create a dedicated service principal or token with
+   > read-only (pull) access to the registry.
+
+4. Set up your Scout credentials.
+
+   1. Generate an organization access token. For more details, see
+      [Create an organization access token](/enterprise/security/access-tokens/#create-an-organization-access-token).
+   2. Sign in to Docker using the organization access token.
+
+      ```console
+      $ docker login --username <your_organization_name>
+      ```
+
+      When prompted for a password, paste the organization access token.
+
+   3. Connect your local Docker environment to your organization's Docker Scout service.
+
+      ```console
+      $ docker scout enroll <your_organization_name>
+      ```
+
+5. Index existing images. You only need to do this once.
+
+   Run `docker scout watch` with the `--all-images` flag to backfill all
+   existing images in the registry.
+
+   ```console
+   $ docker scout watch \
+     --org <your-org> \
+     --registry <registry-name>.azurecr.io \
+     --all-images
+   ```
+
+6. Confirm the images have been indexed by viewing them on the
+   [Scout Dashboard](https://scout.docker.com/).
+
+7. Continuously watch for new images.
+
+   Run `docker scout watch` to poll for new images going forward. Use
+   `--interval` (default 60 seconds) to control polling frequency, and
+   `--repository` and `--tag` to narrow scope.
+
+   ```console
+   $ docker scout watch \
+     --org <your-org> \
+     --registry <registry-name>.azurecr.io \
+     --refresh-registry
+   ```
+
+   `docker scout watch` is a long-running process. Run it as a system
+   service, for example using `systemd` or `nohup`, to ensure it continues
+   running in the background.
+
+Reference: [`docker scout watch`](/reference/cli/docker/scout/watch/)
+
+### Build-time analysis in CI
+
+Best for teams that already have CI pipelines and want analysis scoped to
+images they actively build and push. No long-running process required.
+
+After `docker build` in your pipeline, run:
+
+- `docker scout quickview` or `docker scout cves` to analyze the image.
+- `docker scout compare --to-env <env>` for PR gating against policy.
+- `docker scout environment` to record the image to an environment.
+
+See [Integrating Docker Scout with CI](../_index.md#continuous-integration).
diff --git a/content/manuals/scout/integrations/registry/artifactory.md b/content/manuals/scout/integrations/registry/artifactory.md
index cc0d1774e5f4..36cb7f2ffcb1 100644
--- a/content/manuals/scout/integrations/registry/artifactory.md
+++ b/content/manuals/scout/integrations/registry/artifactory.md
@@ -1,191 +1,167 @@
 ---
-description: Integrate JFrog Artifactory and JFrog Container Registry with Docker Scout
-keywords: docker scout, jfrog, artifactory, jcr, integration, image analysis, security, cves
-title: Integrate Docker Scout with Artifactory
-linkTitle: Artifactory
+description: Integrate Artifactory Container Registry with Docker Scout
+keywords: docker scout, artifactory, integration, image analysis, security, cves
+title: Integrate Docker Scout with Artifactory Container Registry
+linkTitle: Artifactory Container Registry
 aliases:
   - /scout/artifactory/
 ---
 
-Integrating Docker Scout with JFrog Artifactory lets you run image analysis
-automatically on images in Artifactory registries.
+Integrating Docker Scout with JFrog Artifactory lets you index and analyze
+images from Artifactory. This integration is powered by a long-running
+`docker scout watch` process. It pulls images from your selected repositories
+(optionally filtered), can receive webhook callbacks from Artifactory, and
+pushes image data to Docker Scout. View results in the Docker Scout Dashboard or
+with `docker scout` CLI.
 
-## Local image analysis
+## How it works
 
-You can analyze Artifactory images for vulnerabilities locally using Docker Desktop or the Docker CLI. You first need to authenticate with JFrog Artifactory using the [`docker login`](/reference/cli/docker/login/) command. For example:
+You run [`docker scout watch`](/reference/cli/docker/scout/watch/) on a host you
+control and configure the Artifactory-specific registry string via `--registry
+"key=value,..."`. The watch process can:
 
-```bash
-docker login {URL}
-```
+- Watch specific repositories or an entire registry
+- Optionally ingest all existing images once
+- Periodically refresh repository lists
+- Receive webhook callbacks from Artifactory on a local port you choose
 
-> [!TIP]
->
-> For cloud-hosted Artifactory you can find the credentials for your Artifactory repository by
-> selecting it in the Artifactory UI and then the **Set Me Up** button.
-
-## Remote image analysis
-
-To automatically analyze images running in remote environments you need to deploy the Docker Scout Artifactory agent. The agent is a
-standalone service that analyzes images and uploads the result to Docker Scout.
-You can view the results using the
-[Docker Scout Dashboard](https://scout.docker.com/).
-
-### How the agent works
-
-The Docker Scout Artifactory agent is available as an
-[image on Docker Hub](https://hub.docker.com/r/docker/artifactory-agent). The agent works by continuously polling
-Artifactory for new images. When it finds a new image, it performs the following
-steps:
-
-1. Pull the image from Artifactory
-2. Analyze the image
-3. Upload the analysis result to Docker Scout
-
-The agent records the Software Bill of Materials (SBOM) for the image, and the
-SBOMs for all of its base images. The recorded SBOMs include both Operating
-System (OS)-level and application-level programs or dependencies that the image
-contains.
-
-Additionally, the agent sends the following metadata about the image to Docker Scout:
-
-- The source repository URL and commit SHA for the image
-- Build instructions
-- Build date
-- Tags and digest
-- Target platforms
-- Layer sizes
-
-The agent never transacts the image
-itself, nor any data inside the image, such as code, binaries, and layer blobs.
-
-The agent doesn't detect and analyze pre-existing images. It only analyzes
-images that appear in the registry while the agent is running.
-
-### Deploy the agent
-
-This section describes the steps for deploying the Artifactory agent.
-
-#### Prerequisites
-
-Before you deploy the agent, ensure that you meet the prerequisites:
-
-- The server where you host the agent can access the following resources over
-  the network:
-  - Your JFrog Artifactory instance
-  - `hub.docker.com`, port 443, for authenticating with Docker
-  - `api.dso.docker.com`, port 443, for transacting data to Docker Scout
-- The registries are Docker V2 registries. V1 registries aren't supported.
-
-The agent supports all versions of JFrog Artifactory and JFrog Container
-Registry.
-
-#### Create the configuration file
-
-You configure the agent using a JSON file. The agent expects the configuration
-file to be in `/opt/artifactory-agent/data/config.json` on startup.
-
-The configuration file includes the following properties:
-
-| Property                    | Description                                                                     |
-| --------------------------- | ------------------------------------------------------------------------------- |
-| `agent_id`                  | Unique identifier for the agent.                                                |
-| `docker.organization_name`  | Name of the Docker organization.                                                |
-| `docker.username`           | Username of the admin user in the Docker organization.                          |
-| `docker.pat`                | Personal access token of the admin user with read and write permissions.        |
-| `artifactory.base_url`      | Base URL of the Artifactory instance.                                           |
-| `artifactory.username`      | Username of the Artifactory user with read permissions that the agent will use. |
-| `artifactory.password`      | Password or API token for the Artifactory user.                                 |
-| `artifactory.image_filters` | Optional: List of repositories and images to analyze.                           |
-
-If you don't specify any repositories in `artifactory.image_filters`, the agent
-runs image analysis on all images in your Artifactory instance.
-
-The following snippet shows a sample configuration:
-
-```json
-{
-  "agent_id": "acme-prod-agent",
-  "docker": {
-    "organization_name": "acme",
-    "username": "mobythewhale",
-    "pat": "dckr_pat__dsaCAs_xL3kNyupAa7dwO1alwg"
-  },
-  "artifactory": [
-    {
-      "base_url": "https://acme.jfrog.io",
-      "username": "acmeagent",
-      "password": "hayKMvFKkFp42RAwKz2K",
-      "image_filters": [
-        {
-          "repository": "dev-local",
-          "images": ["internal/repo1", "internal/repo2"]
-        },
-        {
-          "repository": "prod-local",
-          "images": ["staging/repo1", "prod/repo1"]
-        }
-      ]
-    }
-  ]
-}
-```
-
-Create a configuration file and save it somewhere on the server where you plan
-to run the agent. For example, `/var/opt/artifactory-agent/config.json`.
-
-#### Run the agent
-
-The following example shows how to run the Docker Scout Artifactory agent using
-`docker run`. This command creates a bind mount for the directory containing the
-JSON configuration file created earlier at `/opt/artifactory-agent/data` inside
-the container. Make sure the mount path you use is the directory containing the
-`config.json` file.
-
-<!-- prettier-ignore -->
-> [!IMPORTANT]
->
-> Use the `v1` tag of the Artifactory agent image. Don't use the `latest` tag as
-> doing so may incur breaking changes.
-
-```console
-$ docker run \
-  --mount type=bind,src=/var/opt/artifactory-agent,target=/opt/artifactory-agent/data \
-  docker/artifactory-agent:v1
-```
-
-#### Analyzing pre-existing data
-
-By default the agent detects and analyzes images as they're created and
-updated. If you want to use the agent to analyze pre-existing images, you
-can use backfill mode. Use the `--backfill-from=TIME` command line option,
-where `TIME` is an ISO 8601 formatted time, to run the agent in backfill mode.
-If you use this option, the agent analyzes all images pushed between that
-time and the current time when the agent starts, then exits.
-
-For example:
-
-```console
-$ docker run \
-  --mount type=bind,src=/var/opt/artifactory-agent,target=/opt/artifactory-agent/data \
-  docker/artifactory-agent:v1 --backfill-from=2022-04-10T10:00:00Z
-```
-
-When running a backfill multiple times, the agent won't analyze images that
-it's already analyzed. To force re-analysis, provide the `--force` command
-line flag.
-
-### View analysis results
-
-You can view the image analysis results in the Docker Scout Dashboard.
-
-1. Go to [Images page](https://scout.docker.com/reports/images/) in the Docker Scout Dashboard.
-
-   This page displays the Docker Scout-enabled repositories in your organization.
-
-2. Select the image in the list.
-3. Select the tag.
-
-When you have selected a tag, you're taken to the vulnerability report for that
-tag. Here, you can select if you want to view all vulnerabilities in the image,
-or vulnerabilities introduced in a specific layer. You can also filter
-vulnerabilities by severity, and whether or not there's a fix version available.
+After the integration, Docker Scout automatically pulls and analyzes images
+that you push to the Artifactory registry. Metadata about your images are stored on the
+Docker Scout platform, but Docker Scout doesn't store the container images
+themselves. For more information about how Docker Scout handles image data, see
+[Data handling](/manuals/scout/deep-dive/data-handling.md).
+
+### Artifactory-specific registry string options
+
+These `type=artifactory` options override the generic registry handling for the `--registry` option:
+
+| Key              | Required | Description                                                                            |
+|------------------|:--------:|----------------------------------------------------------------------------------------|
+| `type`           |   Yes    | Must be `artifactory`.                                                                 |
+| `registry`       |   Yes    | Docker/OCI registry hostname (e.g., `example.jfrog.io`).                               |
+| `api`            |   Yes    | Artifactory REST API base URL (e.g., `https://example.jfrog.io/artifactory`).          |
+| `repository`     |   Yes    | Repository to watch (replaces `--repository`).                                         |
+| `includes`       |    No    | Globs to include (e.g., `*/frontend*`).                                                |
+| `excludes`       |    No    | Globs to exclude (e.g., `*/legacy/*`).                                                 |
+| `port`           |    No    | Local port to listen on for webhook callbacks.                                         |
+| `subdomain-mode` |    No    | `true` or `false`; matches Artifactory’s Docker layout (subdomain versus repository-path). |
+
+## Integrate an Artifactory registry
+
+Use the following steps to integrate your Artifactory registry with Docker
+Scout.
+
+1. Pick the host on which to run `docker scout watch`.
+
+   The host must have local or network access to your private registry and be able
+   to access the Scout API (`https://api.scout.docker.com`) over the internet. If
+   you're using webhook callbacks, Artifactory must also be able to reach the Scout
+   client host on the configured port.
+   Override the `--workers` option (default: `3`) for optimal performance based on
+   the size of the host and the expected workload.
+
+2. Ensure you are running the latest version of Scout.
+
+   Check your current version:
+
+   ```console
+   $ docker scout version
+   ```
+
+   If necessary, [install the latest version of Scout](https://docs.docker.com/scout/install/).
+
+3. Set up your Artifactory credentials.
+
+   Store the credentials that the Scout client will use to authenticate with
+   Artifactory. The following is an example using environment variables. Replace
+   `<user>` and `<password-or-access-token>` with your actual values.
+
+   ```console
+   $ export DOCKER_SCOUT_ARTIFACTORY_API_USER=<user>
+   $ export DOCKER_SCOUT_ARTIFACTORY_API_PASSWORD=<password-or-access-token>
+   ```
+
+   > [!TIP]
+   >
+   > As a best practice, create a dedicated user with read-only access and use
+   > an access token instead of a password.
+
+   Store the credential that Artifactory will use to authenticate webhook
+   callbacks. The following is an example using an environment variable. Replace
+   `<random-64-128-character-secret>` with an actual secret.
+
+   ```console
+   $ export DOCKER_SCOUT_ARTIFACTORY_WEBHOOK_SECRET=<random-64-128-character-secret>
+   ````
+
+   > [!TIP]
+   >
+   > As a best practice, generate a high-entropy random string of 64-128 characters.
+
+4. Set up your Scout credentials.
+
+   1. Generate an organization access token for accessing Scout. For more
+      details, see [Create an organization access
+      token](/enterprise/security/access-tokens/#create-an-organization-access-token).
+   2. Sign in to Docker using the organization access token.
+
+       ```console
+       $ docker login --username <your_organization_name>
+       ```
+
+       When prompted for a password, paste the organization access token you
+       generated.
+
+   3. Connect your local Docker environment to your organization's Docker Scout service.
+
+       ```console
+       $ docker scout enroll <your_organization_name>
+       ```
+
+5. Index existing images. You only need to do this once.
+
+    Run `docker scout watch` with the `--all-images` option to index all images in the specified Artifactory repository. The following is an example command:
+
+   ```console
+   $ docker scout watch --registry \
+   "type=artifactory,registry=example.jfrog.io,api=https://example.jfrog.io/artifactory,include=*/frontend*,exclude=*/dta/*,repository=docker-local,port=9000,subdomain-mode=true" \
+   --all-images
+   ```
+
+6. Confirm the images have been indexed by viewing them on the [Scout
+   Dashboard](https://scout.docker.com/).
+
+7. Configure Artifactory callbacks.
+
+   In your Artifactory UI or via REST API, configure webhooks for image
+   push/update events. Set the endpoint to your `docker scout watch` host and
+   port, and include the `DOCKER_SCOUT_ARTIFACTORY_WEBHOOK_SECRET` for
+   authentication.
+
+   For more information, see the [JFrog Artifactory Webhooks
+   documentation](https://jfrog.com/help/r/jfrog-platform-administration-documentation/webhooks)
+   or the [JFrog Artifactory REST API Webhooks
+   documentation](https://jfrog.com/help/r/jfrog-rest-apis/webhooks).
+
+8. Continuously watch for new or updated images.
+
+   Run `docker scout watch` with the `--refresh-registry` option to watch for
+   new images to index.
+
+   The `docker scout watch` command is a long-running process that must
+   continue running indefinitely in the background to receive webhooks and
+   watch for new images. If you run it directly in a terminal and close the
+   session, the process will stop.
+
+   The following is an example command. You can run the process as a system
+   service, for example using `systemd` or `nohup`, to ensure it continues
+   running in the background.
+
+   ```console
+   $ docker scout watch --registry \
+   "type=artifactory,registry=example.jfrog.io,api=https://example.jfrog.io/artifactory,include=*/frontend*,exclude=*/dta/*,repository=docker-local,port=9000,subdomain-mode=true" \
+   --refresh-registry
+   ```
+
+9. Optional. Set up Scout integration for real-time notifications from popular
+   collaboration platforms.
\ No newline at end of file
diff --git a/content/manuals/scout/integrations/registry/ecr.md b/content/manuals/scout/integrations/registry/ecr.md
index db5096ebab45..a326e485434e 100644
--- a/content/manuals/scout/integrations/registry/ecr.md
+++ b/content/manuals/scout/integrations/registry/ecr.md
@@ -3,8 +3,20 @@ description: Integrate Amazon Elastic Container Registry with Docker Scout
 keywords: docker scout, ecr, integration, image analysis, security, cves
 title: Integrate Docker Scout with Amazon ECR
 linkTitle: Amazon ECR
+params:
+  sidebar:
+    badge:
+      color: gray
+      text: Deprecated
 ---
 
+> [!IMPORTANT]
+>
+> The Docker Scout Amazon ECR integration is deprecated and will be retired on September 1, 2026.
+> Migrate to [`docker scout watch`](/reference/cli/docker/scout/watch/) for
+> continuous analysis, or integrate Scout into your CI pipeline.
+> See [Migrate from the ECR integration](#migrate-from-the-ecr-integration).
+
 Integrating Docker Scout with Amazon Elastic Container Registry (ECR) lets you
 view image insights for images hosted in ECR repositories. After integrating
 Docker Scout with ECR and activating Docker Scout for a repository, pushing an
@@ -172,3 +184,108 @@ Scout Dashboard:
 
   The account ID and region are included in the registry hostname:
   `<aws_account_id>.dkr.ecr.<region>.amazonaws.com/<image>`
+
+## Migrate from the ECR integration
+
+Two migration paths are available.
+
+### Continuous polling
+
+Best for teams that want ongoing, registry-wide analysis without changing
+their build pipelines. `docker scout watch` runs as a long-running process
+that polls your ECR registry and pushes results to Docker Scout, replicating
+what the integration provided.
+
+1. Pick a host on which to run `docker scout watch`.
+
+   The host must have network access to your ECR registry and be able to
+   access the Scout API (`https://api.scout.docker.com`) over the internet.
+
+2. Ensure you are running the latest version of Scout.
+
+   ```console
+   $ docker scout version
+   ```
+
+   If necessary, [install the latest version of Scout](https://docs.docker.com/scout/install/).
+
+3. Authenticate Docker to your ECR registry using the AWS CLI.
+
+   ```console
+   $ aws ecr get-login-password --region <region> | \
+     docker login --username AWS --password-stdin \
+     <aws_account_id>.dkr.ecr.<region>.amazonaws.com
+   ```
+
+   The AWS identity used must have at least `ecr:GetAuthorizationToken` and
+   `ecr:BatchGetImage` permissions on the target registry.
+
+   > [!TIP]
+   >
+   > As a best practice, use a dedicated IAM role or user with read-only
+   > access to the registry.
+
+4. Set up your Scout credentials.
+
+   1. Generate an organization access token. For more details, see
+      [Create an organization access token](/enterprise/security/access-tokens/#create-an-organization-access-token).
+   2. Sign in to Docker using the organization access token.
+
+      ```console
+      $ docker login --username <your_organization_name>
+      ```
+
+      When prompted for a password, paste the organization access token.
+
+   3. Connect your local Docker environment to your organization's Docker Scout service.
+
+      ```console
+      $ docker scout enroll <your_organization_name>
+      ```
+
+5. Index existing images. You only need to do this once.
+
+   Run `docker scout watch` with the `--all-images` flag to backfill all
+   existing images in the registry.
+
+   ```console
+   $ docker scout watch \
+     --org <your-org> \
+     --registry <aws_account_id>.dkr.ecr.<region>.amazonaws.com \
+     --all-images
+   ```
+
+6. Confirm the images have been indexed by viewing them on the
+   [Scout Dashboard](https://scout.docker.com/).
+
+7. Continuously watch for new images.
+
+   Run `docker scout watch` to poll for new images going forward. Use
+   `--interval` (default 60 seconds) to control polling frequency, and
+   `--repository` and `--tag` to narrow scope.
+
+   ```console
+   $ docker scout watch \
+     --org <your-org> \
+     --registry <aws_account_id>.dkr.ecr.<region>.amazonaws.com \
+     --refresh-registry
+   ```
+
+   `docker scout watch` is a long-running process. Run it as a system
+   service, for example using `systemd` or `nohup`, to ensure it continues
+   running in the background.
+
+Reference: [`docker scout watch`](/reference/cli/docker/scout/watch/)
+
+### Build-time analysis in CI
+
+Best for teams that already have CI pipelines and want analysis scoped to
+images they actively build and push. No long-running process required.
+
+After `docker build` in your pipeline, run:
+
+- `docker scout quickview` or `docker scout cves` to analyze the image.
+- `docker scout compare --to-env <env>` for PR gating against policy.
+- `docker scout environment` to record the image to an environment.
+
+See [Integrating Docker Scout with CI](../_index.md#continuous-integration).
diff --git a/content/manuals/scout/integrations/source-code-management/github.md b/content/manuals/scout/integrations/source-code-management/github.md
index cb9350ec2d22..7f771fda4b61 100644
--- a/content/manuals/scout/integrations/source-code-management/github.md
+++ b/content/manuals/scout/integrations/source-code-management/github.md
@@ -3,55 +3,57 @@ title: Integrate Docker Scout with GitHub
 linkTitle: GitHub
 description: Integrate Docker Scout using the GitHub app to get remediation advice directly in your repositories
 keywords: scout, github, integration, image analysis, supply chain, remediation, source code
+params:
+  sidebar:
+    badge:
+      color: gray
+      text: Retired
 ---
 
-{{< summary-bar feature_name="Docker Scout GitHub" >}}
+> [!IMPORTANT]
+>
+> The Docker Scout GitHub integration was retired on July 1, 2026. For base-image updates, use
+> GitHub Dependabot with `package-ecosystem: "docker"`. For image-to-source
+> linkage, build with `--provenance=mode=max`.
 
-The GitHub app integration for Docker Scout grants Docker Scout access to your
-source code repository on GitHub. This improved visibility into how your image
-gets created means Docker Scout can give you automated and contextual
-remediation advice.
+> [!NOTE]
+>
+> This retirement applies only to the Docker Scout GitHub App integration.
+> The [`docker/scout-action`](https://github.com/docker/scout-action) GitHub
+> Action for CI pipelines is not affected and continues to work.
 
-## How it works
+## Migrate from the GitHub integration
 
-When you enable the GitHub integration, Docker Scout can make a direct link
-between the image analysis results and the source.
+The integration provided two capabilities, each with an alternative.
 
-When analyzing your image, Docker Scout checks for [provenance
-attestations](/manuals/build/metadata/attestations/slsa-provenance.md) to detect the
-location of the source code repository for the image. If the source location is
-found, and you've enabled the GitHub app, Docker Scout parses the Dockerfile
-used to create the image.
+### Base-image digest repinning
 
-Parsing the Dockerfile reveals the base image tag used to build the image. By
-knowing the base image tags used, Docker Scout can detect whether the tag is
-outdated, meaning it's been changed to a different image digest. For example,
-say you're using `alpine:3.18` as your base image, and at a later point in
-time, the image maintainers release a patch version for version `3.18`,
-containing security fixes. The `alpine:3.18` tag you've been using becomes
-out-of-date; the `alpine:3.18` you're using is no longer the latest.
+Use GitHub Dependabot with `package-ecosystem: "docker"`. Dependabot opens
+PRs to update base image tags and digests on a schedule. When you pin as
+`FROM image:tag@sha256:...`, both the tag and digest are updated. The Scout
+integration updated only the digest.
 
-When this happens, Docker Scout detects the discrepancy and surfaces it through
-the [Up-to-Date Base Images policy](/manuals/scout/policy/_index.md#up-to-date-base-images-policy).
-When the GitHub integration's enabled, you'll also get automated suggestions on
-how to update your base image. For more information about how Docker Scout can
-help you automatically improve your supply chain conduct and security posture,
-see [Remediation](../../policy/remediation.md).
+Minimal `.github/dependabot.yml`:
 
-## Setup
+```yaml
+version: 2
+updates:
+  - package-ecosystem: "docker"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+```
 
-To integrate Docker Scout with your GitHub organization:
+See [Configuring Dependabot version updates](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates).
 
-1. Go to [GitHub integration](https://scout.docker.com/settings/integrations/github/)
-   on the Docker Scout Dashboard.
-2. Select the **Integrate GitHub app** button to open GitHub.
-3. Select the organization that you want to integrate.
-4. Select whether you want to integrate all repositories in the GitHub
-   organization or a manual selection of repositories.
-5. Select **Install & Authorize** to add the Docker Scout app to the
-   organization.
+### Image-to-source linkage
 
-   This redirects you back to the Docker Scout Dashboard, which lists your
-   active GitHub integrations.
+Build with `--provenance=mode=max`. Docker Scout reads the resulting provenance
+attestation to link an image back to its source repository without requiring
+the GitHub app.
 
-The GitHub integration is now active.
+```console
+$ docker build --provenance=mode=max -t myimage:tag .
+```
+
+See [SLSA provenance attestations](/manuals/build/metadata/attestations/slsa-provenance.md).
diff --git a/content/manuals/scout/integrations/team-collaboration/slack.md b/content/manuals/scout/integrations/team-collaboration/slack.md
index d33dbf76758c..6cd8210352ad 100644
--- a/content/manuals/scout/integrations/team-collaboration/slack.md
+++ b/content/manuals/scout/integrations/team-collaboration/slack.md
@@ -5,8 +5,22 @@ description: |
   Integrate Docker Scout with Slack to receive real-time updates
   about vulnerabilities and policy compliance in Slack channels
 keywords: scout, team collaboration, slack, notifications, updates
+params:
+  sidebar:
+    badge:
+      color: gray
+      text: Deprecated
 ---
 
+> [!IMPORTANT]
+>
+> The Docker Scout Slack integration is deprecated and will be retired on
+> July 30, 2026. To surface CVE and policy results without push notifications,
+> integrate `docker scout cves` or `docker scout policy` into your CI pipeline.
+> See [CI integrations](/manuals/scout/integrations/_index.md#continuous-integration).
+> For details, see the
+> [Scout platform release notes](/manuals/scout/release-notes/platform.md).
+
 You can integrate Docker Scout with Slack by creating a Slack webhook and
 adding it to the Docker Scout Dashboard. Docker Scout will notify you about
 when a new vulnerability is disclosed, and it affects one or more of your
@@ -25,10 +39,10 @@ to the Slack channels associated with the webhook.
 > Notifications are only triggered for the *last pushed* image tags for each
 > repository. "Last pushed" refers to the image tag that was most recently
 > pushed to the registry and analyzed by Docker Scout. If the last pushed image
-> is not by a newly disclosed CVE, then no notification will be triggered.
+> is not affected by a newly disclosed CVE, then no notification will be triggered.
 
 For more information about Docker Scout notifications,
-see [Notification settings](/manuals/scout/explore/dashboard.md#notification-settings)
+see [Notification settings](/manuals/scout/explore/dashboard.md#notification-settings).
 
 ## Setup
 
@@ -49,7 +63,7 @@ To add a Slack integration:
    or enter the names of the repositories that you want to send notifications for.
 6. When you're ready to enable the integration, select **Create**.
 
-After creating the webhook, Docker Scout begins to send notifications updates
+After creating the webhook, Docker Scout begins to send notification updates
 to the Slack channels associated with the webhook.
 
 ## Remove a Slack integration
diff --git a/content/manuals/scout/policy/_index.md b/content/manuals/scout/policy/_index.md
index bba14157e98b..4465ea9f41bd 100644
--- a/content/manuals/scout/policy/_index.md
+++ b/content/manuals/scout/policy/_index.md
@@ -1,59 +1,33 @@
 ---
-title: Get started with Policy Evaluation in Docker Scout
+title: Policy Evaluation
 linkTitle: Policy Evaluation
 weight: 70
 keywords: scout, supply chain, vulnerabilities, packages, cves, policy
 description: |
-  Policies in Docker Scout let you define supply chain rules and thresholds
-  for your artifacts, and track how your artifacts perform against those
-  requirements over time
+  Policy Evaluation in Docker Scout lets you define supply chain rules for your
+  artifacts and evaluate image compliance
 ---
 
-In software supply chain management, maintaining the security and reliability
-of artifacts is a top priority. Policy Evaluation in Docker Scout introduces a
-layer of control, on top of existing analysis capabilities. It lets you define
-supply chain rules for your artifacts, and helps you track how your artifacts
-perform, relative to your rules and thresholds, over time.
-
-Learn how you can use Policy Evaluation to ensure that your artifacts align
-with established best practices.
+Policy Evaluation in Docker Scout lets you define supply chain rules for your
+artifacts and evaluate compliance using the `docker scout policy` command. Run
+evaluations locally, in CI pipelines, with custom Rego policies, or using OCI
+bundles. See [Evaluate policies](./local.md).
 
 ## How Policy Evaluation works
 
-When you activate Docker Scout for a repository, images that you push are
-[automatically analyzed](/manuals/scout/explore/analysis.md). The analysis gives you insights
-about the composition of your images, including what packages they contain and
-what vulnerabilities they're exposed to. Policy Evaluation builds on top of the
-image analysis feature, interpreting the analysis results against the rules
-defined by policies.
-
-A policy defines image quality criteria that your artifacts should fulfill.
-For example, the **No AGPL v3 licenses** policy flags any image containing packages distributed under the AGPL v3 license.
-If an image contains such a package, that image is non-compliant with this policy.
-Some policies, such as the **No AGPL v3 licenses** policy, are configurable.
-Configurable policies let you adjust the criteria to better match your organization's needs.
-
-In Docker Scout, policies are designed to help you ratchet forward your
-security and supply chain stature. Where other tools focus on providing a pass
-or fail status, Docker Scout policies visualizes how small, incremental changes
-affect policy status, even when your artifacts don't meet the policy
-requirements (yet). By tracking how the fail gap changes over time, you more
-easily see whether your artifact is improving or deteriorating relative to
-policy.
-
-Policies don't necessarily have to be related to application security and
-vulnerabilities. You can use policies to measure and track other aspects of
-supply chain management as well, such as open-source license usage and base
-image up-to-dateness.
+When you run `docker scout policy`, the CLI indexes the image into an SBOM and
+enriches it with CVE and VEX data. It then evaluates each configured policy
+in-process against that data. No data is sent to the Scout service, and an
+organization is not required for most use cases.
 
-## Policy types
+A policy defines image quality criteria your artifacts should meet. For
+example, the **No copyleft licenses** policy flags any image containing
+packages distributed under a copyleft license. If an image contains such a
+package, it's non-compliant with that policy.
 
-In Docker Scout, a *policy* is derived from a *policy type*. Policy types are
-templates that define the core parameters of a policy. You can compare policy
-types to classes in object-oriented programming, with each policy acting as an
-instance created from its corresponding policy type.
+## Policy types
 
-Docker Scout supports the following policy types:
+Docker Scout includes the following built-in policy types:
 
 - [Severity-Based Vulnerability](#severity-based-vulnerability)
 - [Compliant Licenses](#compliant-licenses)
@@ -62,315 +36,101 @@ Docker Scout supports the following policy types:
 - [Supply Chain Attestations](#supply-chain-attestations)
 - [Default Non-Root User](#default-non-root-user)
 - [Approved Base Images](#approved-base-images)
-- [SonarQube Quality Gates](#sonarqube-quality-gates)
 
-Docker Scout automatically provides default policies for repositories where it
-is enabled, except for the SonarQube Quality Gates policy, which requires
-[integration with SonarQube](/manuals/scout/integrations/code-quality/sonarqube.md)
-before use.
-
-You can create custom policies from any of the supported policy types, or
-delete a default policy if it isn't applicable to your project. For more
-information, refer to [Configure policies](./configure.md).
+For configuration options for each policy type, see
+[Evaluate policies](./local.md#configure-built-in-policies).
 
 <!-- vale Docker.HeadingSentenceCase = NO -->
 
 ### Severity-Based Vulnerability
 
-The **Severity-Based Vulnerability** policy type checks whether your
-artifacts are exposed to known vulnerabilities.
-
-By default, this policy only flags critical and high severity vulnerabilities
-where there's a fix version available. Essentially, this means that there's an
-easy fix that you can deploy for images that fail this policy: upgrade the
-vulnerable package to a version containing a fix for the vulnerability.
-
-Images are deemed non-compliant with this policy if they contain one or more
-vulnerabilities that fall outside the specified policy criteria.
-
-You can configure the parameters of this policy by creating a custom version of the policy.
-The following policy parameters are configurable in a custom version:
-
-- **Age**: The minimum number of days since the vulnerability was first published
-
-  The rationale for only flagging vulnerabilities of a certain minimum age is
-  that newly discovered vulnerabilities shouldn't cause your evaluations to
-  fail until you've had a chance to address them.
+The **Severity-Based Vulnerability** policy type checks whether your artifacts
+are exposed to known vulnerabilities. By default, it flags critical and high
+severity vulnerabilities where a fix version is available.
 
-<!-- vale Vale.Spelling = NO -->
-- **Severities**: Severity levels to consider (default: `Critical, High`)
-<!-- vale Vale.Spelling = YES -->
-
-- **Fixable vulnerabilities only**: Whether or not to only report
-  vulnerabilities with a fix version available (enabled by default).
-
-- **Package types**: List of package types to consider.
-
-  This option lets you specify the package types, as [PURL package type definitions](https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst),
-  that you want to include in the policy evaluation. By default, the policy
-  considers all package types.
-
-For more information about configuring policies, see [Configure policies](./configure.md).
+Configurable parameters include severity levels, a grace period for newly
+disclosed CVEs, fixable-only filtering, and package type filtering.
 
 ### Compliant Licenses
 
 The **Compliant Licenses** policy type checks whether your images contain
-packages distributed under an inappropriate license. Images are considered
-non-compliant if they contain one or more packages with such a license.
-
-You can configure the list of licenses that this policy should look out for,
-and add exceptions by specifying an allow-list (in the form of PURLs).
-See [Configure policies](./configure.md).
+packages distributed under an inappropriate license. You can configure the
+list of licenses to flag and add package-level exceptions.
 
 ### Up-to-Date Base Images
 
 The **Up-to-Date Base Images** policy type checks whether the base images you
-use are up-to-date.
+use are current. Images are non-compliant if the tag you built from points to
+a different digest than what you're using.
 
-Images are considered non-compliant with this policy if the tag you used to
-build your image points to a different digest than what you're using. If
-there's a mismatch in digests, that means the base image you're using is out of
-date.
-
-Your images need provenance attestations for this policy to successfully
-evaluate. For more information, see [No base image data](#no-base-image-data).
+Your images need provenance attestations for this policy to evaluate
+successfully. For more information, see [No base image data](#no-base-image-data).
 
 ### High-Profile Vulnerabilities
 
 The **High-Profile Vulnerabilities** policy type checks whether your images
-contain vulnerabilities from Docker Scout’s curated list. This list is kept
-up-to-date with newly disclosed vulnerabilities that are widely recognized to
-be risky.
-
-The list includes the following vulnerabilities:
-
-- [CVE-2014-0160 (OpenSSL Heartbleed)](https://scout.docker.com/v/CVE-2014-0160)
-- [CVE-2021-44228 (Log4Shell)](https://scout.docker.com/v/CVE-2021-44228)
-- [CVE-2023-38545 (cURL SOCKS5 heap buffer overflow)](https://scout.docker.com/v/CVE-2023-38545)
-- [CVE-2023-44487 (HTTP/2 Rapid Reset)](https://scout.docker.com/v/CVE-2023-44487)
-- [CVE-2024-3094 (XZ backdoor)](https://scout.docker.com/v/CVE-2024-3094)
-- [CVE-2024-47176 (OpenPrinting - `cups-browsed`)](https://scout.docker.com/v/CVE-2024-47176)
-- [CVE-2024-47076 (OpenPrinting - `libcupsfilters`)](https://scout.docker.com/v/CVE-2024-47076)
-- [CVE-2024-47175 (OpenPrinting - `libppd`)](https://scout.docker.com/v/CVE-2024-47175)
-- [CVE-2024-47177 (OpenPrinting - `cups-filters`)](https://scout.docker.com/v/CVE-2024-47177)
-
-You can customize this policy to change which CVEs that are considered
-high-profile by configuring the policy. Custom configuration options include:
+contain vulnerabilities from a [curated list of widely recognized, high-impact
+CVEs](./local.md#default-high-profile-cves), including Log4Shell, Spring4Shell,
+and XZ backdoor. The list is updated as new high-profile vulnerabilities are
+disclosed.
 
-- **Excluded CVEs**: Specify the CVEs that you want this policy to ignore.
-
-  Default: `[]` (none of the high-profile CVEs are ignored)
-
-- **CISA KEV**: Enable tracking of vulnerabilities from CISA's Known Exploited Vulnerabilities (KEV) catalog
-
-  The [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
-  includes vulnerabilities that are actively exploited in the wild. When enabled,
-  the policy flags images that contain vulnerabilities from the CISA KEV catalog.
-
-  Enabled by default.
-
-For more information on policy configuration, see [Configure policies](./configure.md).
+You can configure which CVEs are considered high-profile and enable tracking
+of CISA's Known Exploited Vulnerabilities catalog.
 
 ### Supply Chain Attestations
 
 The **Supply Chain Attestations** policy type checks whether your images have
 [SBOM](/manuals/build/metadata/attestations/sbom.md) and
-[provenance](/manuals/build/metadata/attestations/slsa-provenance.md) attestations.
+[provenance](/manuals/build/metadata/attestations/slsa-provenance.md)
+attestations. Images are non-compliant if they lack either attestation type.
 
-Images are considered non-compliant if they lack either an SBOM attestation or
-a provenance attestation with *max mode* provenance. To ensure compliance,
-update your build command to attach these attestations at build-time:
+To ensure compliance, build with attestations:
 
 ```console
 $ docker buildx build --provenance=true --sbom=true -t <IMAGE> --push .
 ```
 
-For more information about building with attestations, see
-[Attestations](/manuals/build/metadata/attestations/_index.md).
-
-If you're using GitHub Actions to build and push your images,
-learn how you can [configure the action](/manuals/build/ci/github-actions/attestations.md)
-to apply SBOM and provenance attestations.
-
 ### Default Non-Root User
 
-By default, containers run as the `root` superuser with full system
-administration privileges inside the container, unless the Dockerfile specifies
-a different default user. Running containers as a privileged user weakens their
-runtime security, as it means any code that runs in the container can perform
-administrative actions.
-
-The **Default Non-Root User** policy type detects images that are set to run as
-the default `root` user. To comply with this policy, images must specify a
-non-root user in the image configuration. Images are non-compliant with this
-policy if they don't specify a non-root default user for the runtime stage.
-
-For non-compliant images, evaluation results show whether or not the `root`
-user was set explicitly for the image. This helps you distinguish between
-policy violations caused by images where the `root` user is implicit, and
-images where `root` is set on purpose.
-
-The following Dockerfile runs as `root` by default despite not being explicitly set:
-
-```Dockerfile
-FROM alpine
-RUN echo "Hi"
-```
-
-Whereas in the following case, the `root` user is explicitly set:
-
-```Dockerfile
-FROM alpine
-USER root
-RUN echo "Hi"
-```
-
-> [!NOTE]
->
-> This policy only checks for the default user of the image, as set in the
-> image configuration blob. Even if you do specify a non-root default user,
-> it's still possible to override the default user at runtime, for example by
-> using the `--user` flag for the `docker run` command.
-
-To make your images compliant with this policy, use the
-[`USER`](/reference/dockerfile.md#user) Dockerfile instruction to set
-a default user that doesn't have root privileges for the runtime stage.
-
-The following Dockerfile snippets shows the difference between a compliant and
-non-compliant image.
-
-{{< tabs >}}
-{{< tab name="Non-compliant" >}}
-
-```dockerfile
-FROM alpine AS builder
-COPY Makefile ./src /
-RUN make build
-
-FROM alpine AS runtime
-COPY --from=builder bin/production /app
-ENTRYPOINT ["/app/production"]
-```
-
-{{< /tab >}}
-{{< tab name="Compliant" >}}
-
-```dockerfile {hl_lines=7}
-FROM alpine AS builder
-COPY Makefile ./src /
-RUN make build
-
-FROM alpine AS runtime
-COPY --from=builder bin/production /app
-USER nonroot
-ENTRYPOINT ["/app/production"]
-```
-
-{{< /tab >}}
-{{< /tabs >}}
+The **Default Non-Root User** policy type detects images configured to run as
+the `root` user. Use the
+[`USER`](/reference/dockerfile.md#user) Dockerfile instruction to set a
+non-root default user for the runtime stage.
 
 ### Approved Base Images
 
-The **Approved Base Images** policy type ensures that the base images you use
-in your builds are maintained and secure.
-
-This policy checks whether the base images used in your builds match any of the
-patterns specified in the policy configuration. The following table shows a few
-example patterns for this policy.
-
-| Use case                                                        | Pattern                          |
-| --------------------------------------------------------------- | -------------------------------- |
-| Allow all images from Docker Hub                                | `docker.io/*`                    |
-| Allow all Docker Official Images                                | `docker.io/library/*`            |
-| Allow images from a specific organization                       | `docker.io/orgname/*`            |
-| Allow tags of a specific repository                             | `docker.io/orgname/repository:*` |
-| Allow images on a registry with hostname `registry.example.com` | `registry.example.com/*`         |
-| Allow slim tags of NodeJS images                                | `docker.io/library/node:*-slim`  |
-
-An asterisk (`*`) matches up until the character that follows, or until the end
-of the image reference. Note that the `docker.io` prefix is required in order
-to match Docker Hub images. This is the registry hostname of Docker Hub.
-
-This policy is configurable with the following options:
-
-- **Approved base image sources**
-
-  Specify the image reference patterns that you want to allow. The policy
-  evaluates the base image references against these patterns.
-
-  Default: `[*]` (any reference is an allowed base image)
-
-- **Only supported tags**
+The **Approved Base Images** policy type ensures the base images you use match
+a configurable allowlist of glob patterns. Images are non-compliant if the
+base image reference doesn't match any of the allowed patterns.
 
-  Allow only supported tags when using Docker Official Images.
+Your images need provenance attestations for this policy to evaluate
+successfully. For more information, see [No base image data](#no-base-image-data).
 
-  When this option is enabled, images using unsupported tags of official images
-  as their base image trigger a policy violation. Supported tags for official
-  images are listed in the **Supported tags** section of the repository
-  overview on Docker Hub.
+<!-- vale Docker.HeadingSentenceCase = YES -->
 
-  Enabled by default.
-
-- **Only supported OS distributions**
-
-  Allow only Docker Official Images of supported Linux distribution versions.
-
-  When this option is enabled, images using unsupported Linux distributions
-  that have reached end of life (such as `ubuntu:18.04`) trigger a policy violation.
-
-  Enabling this option may cause the policy to report no data
-  if the operating system version cannot be determined.
-
-  Enabled by default.
-
-Your images need provenance attestations for this policy to successfully
-evaluate. For more information, see [No base image data](#no-base-image-data).
-
-### SonarQube Quality Gates
-
-The **SonarQube Quality Gates** policy type builds on the [SonarQube
-integration](../integrations/code-quality/sonarqube.md) to assess the quality
-of your source code. This policy works by ingesting the SonarQube code analysis
-results into Docker Scout.
+## No base image data
 
-You define the criteria for this policy using SonarQube's [quality
-gates](https://docs.sonarsource.com/sonarqube/latest/user-guide/quality-gates/).
-SonarQube evaluates your source code against the quality gates you've defined
-in SonarQube. Docker Scout surfaces the SonarQube assessment as a Docker Scout
-policy.
+The **Up-to-Date Base Images** and **Approved Base Images** policies require
+provenance attestations to determine the base image used in your build. Without
+them, these policies report **No data**.
 
-Docker Scout uses [provenance](/manuals/build/metadata/attestations/slsa-provenance.md)
-attestations or the `org.opencontainers.image.revision` OCI annotation to link
-SonarQube analysis results with container images. In addition to enabling the
-SonarQube integration, you must also make sure that your images have either the
-attestation or the label.
+To ensure Docker Scout always has base image information, attach provenance
+attestations at build time:
 
-![Git commit SHA links image with SonarQube analysis](../images/scout-sq-commit-sha.webp)
+```console
+$ docker buildx build --provenance=true -t <IMAGE> --push .
+```
 
-Once you push an image and policy evaluation completes, the results from the
-SonarQube quality gates display as a policy in the Docker Scout Dashboard, and
-in the CLI.
+## Policies page in the Dashboard
 
-> [!NOTE]
+> [!IMPORTANT]
 >
-> Docker Scout can only access SonarQube analyses created after the integration
-> is enabled. Docker Scout doesn't have access to historic evaluations. Trigger
-> a SonarQube analysis and policy evaluation after enabling the integration to
-> view the results in Docker Scout.
-
-## No base image data
-
-There are cases when it's not possible to determine information about the base
-images used in your builds. In such cases, the **Up-to-Date Base Images** and
-**Approved Base Images** policies get flagged as having **No data**.
-
-This "no data" state occurs when:
-
-- Docker Scout doesn't know what base image tag you used
-- The base image version you used has multiple tags, but not all tags are out
-  of date
-
-To make sure that Docker Scout always knows about your base image, you can
-attach [provenance attestations](/manuals/build/metadata/attestations/slsa-provenance.md)
-at build-time. Docker Scout uses provenance attestations to find out the base
-image version.
+> The `docker scout policy` command brings policy evaluation directly to your
+> CLI so you can evaluate any image locally, in CI, or with custom policies
+> without needing the Dashboard. The Policies page in the Dashboard is
+> deprecated and will be retired on September 1, 2026. See
+> [Evaluate policies](./local.md).
+
+The Docker Scout Dashboard previously provided a visual interface for tracking
+policy compliance across your organization's images. See
+[Use the Policies page in the Dashboard](./dashboard.md).
diff --git a/content/manuals/scout/policy/ci.md b/content/manuals/scout/policy/ci.md
deleted file mode 100644
index 1d50a6b149e6..000000000000
--- a/content/manuals/scout/policy/ci.md
+++ /dev/null
@@ -1,153 +0,0 @@
----
-title: Evaluate policy compliance in CI
-description: |
-  Configure your continuous integration pipelines to fail
-  when Policy Evaluation for an image is worse compared to baseline
-keywords: scout, supply chain, policy, ci
----
-
-Adding Policy Evaluation to your continuous integration pipelines helps you
-detect and prevent cases where code changes would cause policy compliance to
-become worse compared to your baseline.
-
-The recommended strategy for Policy Evaluation in a CI setting involves
-evaluating a local image and comparing the results to a baseline. If the policy
-compliance for the local image is worse than the specified baseline, the CI run
-fails with an error. If policy compliance is better or unchanged, the CI run
-succeeds.
-
-This comparison is relative, meaning that it's only concerned with whether your
-CI image is better or worse than your baseline. It's not an absolute check to
-pass or fail all policies. By measuring relative to a baseline that you define,
-you can quickly see if a change has a positive or negative impact on policy
-compliance.
-
-## How it works
-
-When you do Policy Evaluation in CI, you run a local policy evaluation on the
-image you build in your CI pipeline. To run a local evaluation, the image that
-you evaluate must exist in the image store where your CI workflow is being run.
-Either build or pull the image, and then run the evaluation.
-
-To run policy evaluation and trigger failure if compliance for your local image
-is worse than your comparison baseline, you need to specify the image version
-to use as a baseline. You can hard-code a specific image reference, but a
-better solution is to use [environments](../integrations/environment/_index.md)
-to automatically infer the image version from an environment. The example that
-follows uses environments to compare the CI image with the image in the
-`production` environment.
-
-## Example
-
-The following example on how to run policy evaluation in CI uses the [Docker
-Scout GitHub Action](https://github.com/marketplace/actions/docker-scout) to
-execute the `compare` command on an image built in CI. The compare command has
-a `to-env` input, which will run the comparison against an environment called
-`production`. The `exit-on` input is set to `policy`, meaning that the
-comparison fails only if policy compliance has worsened.
-
-This example doesn't assume that you're using Docker Hub as your container
-registry. As a result, this workflow uses the `docker/login-action` twice:
-
-- Once for authenticating to your container registry.
-- Once more for authenticating to Docker to pull the analysis results of your
-  `production` image.
-
-If you use Docker Hub as your container registry, you only need to authenticate
-once.
-
-> [!NOTE]
->
-> Due to a limitation in the Docker Engine, loading multi-platform images or
-> images with attestations to the image store isn't supported.
->
-> For the policy evaluation to work, you must load the image to the local image
-> store of the runner. Ensure that you're building a single-platform image
-> without attestations, and that you're loading the build results. Otherwise,
-> the policy evaluation fails.
-
-Also note the `pull-requests: write` permission for the job. The Docker Scout
-GitHub Action adds a pull request comment with the evaluation results by
-default, which requires this permission. For details, see
-[Pull Request Comments](https://github.com/docker/scout-action#pull-request-comments).
-
-```yaml
-name: Docker
-
-on:
-  push:
-    tags: ["*"]
-    branches:
-      - "main"
-  pull_request:
-    branches: ["**"]
-
-env:
-  REGISTRY: docker.io
-  IMAGE_NAME: <IMAGE_NAME>
-  DOCKER_ORG: <ORG>
-
-jobs:
-  build:
-    permissions:
-      pull-requests: write
-
-    runs-on: ubuntu-latest
-    steps:
-      - name: Log into registry ${{ env.REGISTRY }}
-        uses: docker/login-action@v3
-        with:
-          registry: ${{ env.REGISTRY }}
-          username: ${{ secrets.REGISTRY_USER }}
-          password: ${{ secrets.REGISTRY_TOKEN }}
-      
-      - name: Setup Docker buildx
-        uses: docker/setup-buildx-action@v3
-
-      - name: Extract metadata
-        id: meta
-        uses: docker/metadata-action@v5
-        with:
-          images: ${{ env.IMAGE_NAME }}
-
-      - name: Build image
-        id: build-and-push
-        uses: docker/build-push-action@v4
-        with:
-          tags: ${{ steps.meta.outputs.tags }}
-          labels: ${{ steps.meta.outputs.labels }}
-          sbom: ${{ github.event_name != 'pull_request' }}
-          provenance: ${{ github.event_name != 'pull_request' }}
-          push: ${{ github.event_name != 'pull_request' }}
-          load: ${{ github.event_name == 'pull_request' }}
-
-      - name: Authenticate with Docker
-        uses: docker/login-action@v3
-        with:
-          username: ${{ secrets.DOCKER_USER }}
-          password: ${{ secrets.DOCKER_PAT }}
-
-      - name: Compare
-        if: ${{ github.event_name == 'pull_request' }}
-        uses: docker/scout-action@v1
-        with:
-          command: compare
-          image: ${{ steps.meta.outputs.tags }}
-          to-env: production
-          platform: "linux/amd64"
-          ignore-unchanged: true
-          only-severities: critical,high
-          organization: ${{ env.DOCKER_ORG }}
-          exit-on: policy
-```
-
-The following screenshot shows what the GitHub PR comment looks like when a
-policy evaluation check fails because policy has become worse in the PR image
-compared to baseline.
-
-![Policy evaluation comment in GitHub PR](../images/scout-policy-eval-ci.webp)
-
-This example has demonstrated how to run policy evaluation in CI with GitHub
-Actions. Docker Scout also supports other CI platforms. For more information,
-see [Docker Scout CI
-integrations](../integrations/_index.md#continuous-integration).
diff --git a/content/manuals/scout/policy/configure.md b/content/manuals/scout/policy/configure.md
deleted file mode 100644
index 98d23fb4ca79..000000000000
--- a/content/manuals/scout/policy/configure.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: Configure policies
-description: Learn how to configure, disable, or delete policies in Docker Scout
-keywords: scout, policy, configure, delete, enable, parametrize, thresholds
----
-
-Some policy types are configurable. This means that you can create new,
-customized version of that policy type with your own configuration parameters.
-You can also disable a policy if you need to temporarily disregard it, or
-delete a policy altogether if it doesn't match your needs.
-
-> [!NOTE]
-> Historic evaluation results for the default policy configuration are removed
-> if you delete or customize a policy.
-
-## Add a policy
-
-To add a new policy, select the policy type that you want to customize. All
-custom policies use a policy type as a base.
-
-You can edit the display name and description of the new policy to help
-better communicate the compliant and non-compliant states of the policy.
-You can not change the name of the policy type, only its display names.
-
-The available configuration parameters for a policy depends on the
-policy type that you're editing. For more information, refer to
-[Policy types](/manuals/scout/policy/_index.md#policy-types).
-
-To add a policy:
-
-1. Go to the [Policies page](https://scout.docker.com/reports/policy) in the Docker Scout Dashboard.
-2. Select the **Add policy** button to open the policy configuration screen.
-3. On the policy configuration screen, locate the policy type that you want to
-   configure, and select **Configure** to open the policy configuration page.
-
-   - If the **Configure** button is grayed out, it means the current policy
-     has no configurable parameters.
-   - If the button reads **Integrate**, it indicates that setup is required
-     before the policy can be enabled. Selecting **Integrate** will direct you
-     to the integration's setup guide.
-
-4. Update the policy parameters.
-5. Save the changes:
-
-   - Select **Save policy** to commit the changes and enable the policy for
-     your current organization.
-   - Select **Save and disable** to save the policy configuration without enabling
-     it.
-
-## Edit a policy
-
-Editing a policy lets you to modify its configuration without creating 
-a new one from scratch. This can be useful when policy parameters need adjustments 
-due to evolving requirements or changes in your organization's compliance goals.
-
-To edit a policy:
-
-1. Go to the [Policies page](https://scout.docker.com/reports/policy) in the Docker Scout Dashboard.
-2. Select the policy you want to edit.
-3. Select the **Edit** button.
-4. Update the policy parameters.
-5. Save the changes.
-
-## Disable a policy
-
-When you disable a policy, evaluation results for that policy are hidden, and
-no longer appear in the Docker Scout Dashboard or in the CLI. Historic
-evaluation results aren't deleted if you disable a policy, so if you change
-your mind and re-enable a policy later, results from earlier evaluations will
-still be available.
-
-To disable a policy:
-
-1. Go to the [Policies page](https://scout.docker.com/reports/policy) in the Docker Scout Dashboard.
-2. Select the policy you want to disable.
-3. Select the **Disable** button.
-
-## Delete a policy
-
-When you delete a policy, evaluation results for that policy are deleted as
-well, and no longer appear in the Docker Scout Dashboard or in the CLI.
-
-To delete a policy:
-
-1. Go to the [Policies page](https://scout.docker.com/reports/policy) in the Docker Scout Dashboard.
-2. Select the policy you want to delete.
-3. Select the **Delete** button.
-
-## Recover a deleted policy
-
-If you've deleted a policy, you can recreate it by following the steps in [Add
-a policy](#add-a-policy). On the policy configuration screen, select
-**Configure** on the deleted policy that you wish to recreate.
diff --git a/content/manuals/scout/policy/dashboard.md b/content/manuals/scout/policy/dashboard.md
new file mode 100644
index 000000000000..0426c3a40863
--- /dev/null
+++ b/content/manuals/scout/policy/dashboard.md
@@ -0,0 +1,233 @@
+---
+title: Use the Policies page in the Dashboard
+linkTitle: Use the Dashboard
+description: View policy status, configure policies, and get remediation advice using the Docker Scout Dashboard
+keywords: scout, policy, dashboard, configure, remediation, status
+params:
+  sidebar:
+    badge:
+      color: gray
+      text: Deprecated
+aliases:
+  - /scout/policy/ci/
+  - /scout/policy/view/
+  - /scout/policy/configure/
+  - /scout/policy/remediation/
+---
+
+> [!IMPORTANT]
+>
+> The Policies page is deprecated and will be retired on September 1, 2026.
+> The `docker scout policy` command replaces this with more options for
+> evaluating policies. You can run evaluations locally, in CI, against custom
+> Rego policies, or using OCI bundles. See
+> [Evaluate policies](./local.md).
+
+## View policy status
+
+The **Overview** tab of the [Docker Scout Dashboard](https://scout.docker.com/)
+displays a summary of recent changes in policy for your repositories.
+This summary shows images that have seen the most change in their policy
+evaluation between the most recent image and the previous image.
+
+### Policy status per repository
+
+The **Images** tab shows the current policy status, and recent policy trend,
+for all images in the selected environment. The **Policy status** column shows:
+
+- Number of fulfilled policies versus the total number of policies
+- Recent policy trends
+
+The policy trend, denoted by the directional arrows, indicates whether an image
+is better, worse, or unchanged compared to the previous image in the same
+environment.
+
+- The green arrow pointing upwards shows the number of policies that improved.
+- The red arrow pointing downwards shows the number of policies that worsened.
+- The bidirectional gray arrow shows the number of policies that were unchanged.
+
+### Detailed results
+
+To view the full evaluation results for an image, navigate to the image tag in
+the Docker Scout Dashboard and open the **Policy** tab.
+
+For vulnerability-related policies, the details view shows the fix version when
+one is available. For licensing-related policies, the list shows all packages
+whose license doesn't meet the policy criteria.
+
+## Configure policies
+
+Some policy types are configurable. You can create customized versions with
+your own parameters, disable a policy, or delete it.
+
+> [!NOTE]
+> Historic evaluation results for the default policy configuration are removed
+> if you delete or customize a policy.
+
+### Add a policy
+
+1. Go to the [Policies page](https://scout.docker.com/reports/policy) in the Docker Scout Dashboard.
+2. Select **Add policy**.
+3. Locate the policy type you want to configure and select **Configure**.
+
+   - If **Configure** is grayed out, the policy has no configurable parameters.
+   - If the button reads **Integrate**, setup is required before the policy can be enabled.
+
+4. Update the policy parameters.
+5. Select **Save policy** to enable, or **Save and disable** to save without enabling.
+
+### Edit a policy
+
+1. Go to the [Policies page](https://scout.docker.com/reports/policy).
+2. Select the policy and then select **Edit**.
+3. Update the parameters and save.
+
+### Disable a policy
+
+Disabling a policy hides its results but doesn't delete historic data.
+
+1. Go to the [Policies page](https://scout.docker.com/reports/policy).
+2. Select the policy and then select **Disable**.
+
+### Delete a policy
+
+Deleting a policy removes its evaluation results.
+
+1. Go to the [Policies page](https://scout.docker.com/reports/policy).
+2. Select the policy and then select **Delete**.
+
+To recreate a deleted policy, follow [Add a policy](#add-a-policy) and select
+**Configure** on the deleted policy type.
+
+## Remediation
+
+Docker Scout provides remediation recommendations based on policy evaluation
+results. Recommendations are available for the following policy types:
+
+- [Up-to-Date Base Images](#up-to-date-base-images)
+- [Supply Chain Attestations](#supply-chain-attestations)
+
+To view recommendations:
+
+1. Go to the [Policies page](https://scout.docker.com/reports/policy).
+2. Select a policy.
+3. Hover over an image in the list and select **View fixes**.
+
+If more than one recommendation is available, the primary recommendation
+displays as the **Recommended fix**. Additional recommendations are listed as
+**Quick fixes**.
+
+### Up-to-Date Base Images
+
+Without provenance attestations, compliance is undeterminable. Add
+[provenance attestations](/manuals/build/metadata/attestations/slsa-provenance.md)
+so Docker Scout can detect the base image version you're using.
+
+With provenance attestations, the recommended action shows how to update your
+base image to the latest version and pin it to a specific digest. See
+[Pin base image versions](/manuals/build/building/best-practices.md#pin-base-image-versions).
+
+With the GitHub integration enabled, you can raise a pull request directly from
+the remediation panel to update the base image version in your Dockerfile.
+
+### Supply Chain Attestations
+
+The **Supply Chain Attestations** policy requires SBOM and provenance
+attestations. The remediation panel shows what's missing. For example, if your
+image has a provenance attestation without enough information, rebuild with
+[`mode=max`](/manuals/build/metadata/attestations/slsa-provenance.md#max) provenance.
+
+## Evaluate policy compliance in CI
+
+Adding policy evaluation to your CI pipelines helps you detect and prevent
+cases where a change would cause policy compliance to worsen compared to your
+baseline.
+
+The recommended strategy involves evaluating a local image and comparing the
+results to a baseline using an [environment](../integrations/environment/_index.md).
+If policy compliance for the new image is worse than the baseline, the CI run
+fails. If compliance is better or unchanged, the run succeeds.
+
+The following GitHub Actions example uses the [Docker Scout GitHub Action](https://github.com/marketplace/actions/docker-scout)
+to compare a pull request image against the `production` environment. The
+`exit-on` input is set to `policy`, so the step fails only if policy compliance
+has worsened.
+
+> [!NOTE]
+>
+> Due to a limitation in Docker Engine, loading multi-platform images or images
+> with attestations to the image store isn't supported. Build a single-platform
+> image without attestations and load it for the policy evaluation to work.
+
+```yaml
+name: Docker
+
+on:
+  push:
+    tags: ["*"]
+    branches:
+      - "main"
+  pull_request:
+    branches: ["**"]
+
+env:
+  REGISTRY: docker.io
+  IMAGE_NAME: <IMAGE_NAME>
+  DOCKER_ORG: <ORG>
+
+jobs:
+  build:
+    permissions:
+      pull-requests: write
+
+    runs-on: ubuntu-latest
+    steps:
+      - name: Log into registry ${{ env.REGISTRY }}
+        uses: docker/login-action@{{% param "login_action_version" %}}
+        with:
+          registry: ${{ env.REGISTRY }}
+          username: ${{ secrets.REGISTRY_USER }}
+          password: ${{ secrets.REGISTRY_TOKEN }}
+
+      - name: Setup Docker buildx
+        uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}}
+
+      - name: Extract metadata
+        id: meta
+        uses: docker/metadata-action@{{% param "metadata_action_version" %}}
+        with:
+          images: ${{ env.IMAGE_NAME }}
+
+      - name: Build image
+        id: build-and-push
+        uses: docker/build-push-action@{{% param "build_push_action_version" %}}
+        with:
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
+          sbom: ${{ github.event_name != 'pull_request' }}
+          provenance: ${{ github.event_name != 'pull_request' }}
+          push: ${{ github.event_name != 'pull_request' }}
+          load: ${{ github.event_name == 'pull_request' }}
+
+      - name: Authenticate with Docker
+        uses: docker/login-action@{{% param "login_action_version" %}}
+        with:
+          username: ${{ secrets.DOCKER_USER }}
+          password: ${{ secrets.DOCKER_PAT }}
+
+      - name: Compare
+        if: ${{ github.event_name == 'pull_request' }}
+        uses: docker/scout-action@v1
+        with:
+          command: compare
+          image: ${{ steps.meta.outputs.tags }}
+          to-env: production
+          platform: "linux/amd64"
+          ignore-unchanged: true
+          only-severities: critical,high
+          organization: ${{ env.DOCKER_ORG }}
+          exit-on: policy
+```
+
+For other CI platforms, see
+[Docker Scout CI integrations](../integrations/_index.md#continuous-integration).
diff --git a/content/manuals/scout/policy/local.md b/content/manuals/scout/policy/local.md
new file mode 100644
index 000000000000..1a14ab68a480
--- /dev/null
+++ b/content/manuals/scout/policy/local.md
@@ -0,0 +1,539 @@
+---
+title: Evaluate policies
+description: Evaluate Docker Scout policies using the CLI, with built-in and custom Rego policies
+keywords: scout, policy, rego, opa, cli, custom policies, policy bundle
+---
+
+{{< summary-bar feature_name="Evaluate policies" >}}
+
+`docker scout policy` lets you evaluate images against a configurable policy
+set using the CLI. You can use the built-in defaults, adjust thresholds to
+match your requirements, or write custom policies in
+[Rego](https://www.openpolicyagent.org/docs/latest/policy-language/).
+
+## How it works
+
+When you run `docker scout policy`, the CLI indexes the image into an SBOM,
+enriches it with CVE and VEX data, then evaluates each configured policy
+in-process. No data is sent to the Scout service, and an
+organization is not required for most use cases.
+
+Policies come from three sources, which can be combined:
+
+- Built-in defaults: a curated set embedded in the CLI, used when no other
+  source is given.
+- OCI policy bundles: Rego packaged as an OCI artifact and pulled from a
+  registry with `--policy-bundle`.
+- Local `.rego` files: for authoring and iterating on custom policies with
+  `--policy-file` or `--policy-dir`.
+
+## Migrate from Policy Evaluation in the Dashboard
+
+If you used the Policies page in the Docker Scout Dashboard, `docker scout
+policy` provides the same capability from the CLI. The built-in policies are
+the same set. To evaluate an image:
+
+```console
+$ docker scout policy <image>
+```
+
+If you had customized policies in the dashboard, such as adjusted severity
+thresholds or disabled policies, you can replicate those settings with a
+`--policy-config` file. See [Configure built-in policies](#configure-built-in-policies).
+
+### Use in CI
+
+Use the [Docker Scout GitHub Action](https://github.com/marketplace/actions/docker-scout)
+to evaluate policies as part of your workflow:
+
+```yaml
+- name: Evaluate policies
+  uses: docker/scout-action@v1
+  with:
+    command: policy
+    image: ${{ env.IMAGE_NAME }}
+    organization: <ORG>
+```
+
+For other CI platforms, install the
+[Docker Scout CLI plugin](/manuals/scout/install.md) on your runner and run
+`docker scout policy <image> --exit-code`.
+
+### Migrate the GitHub Action from dashboard-based policy evaluation
+
+The Docker Scout GitHub Action now supports the same local policy configuration
+flags as `docker scout policy`. If you used `compare --exit-on policy` with
+dashboard-managed policy settings, replicate those settings locally with
+`--policy-config`:
+
+```yaml
+- uses: docker/scout-action@v1.23.0
+  with:
+    command: compare
+    image: ${{ env.IMAGE_NAME }}
+    to-env: production
+    exit-on: policy
+    policy-config: policies.json
+    organization: <ORG>
+```
+
+See [Configure built-in policies](#configure-built-in-policies) for the
+`policy-config` file format.
+
+## Examples
+
+Evaluate an image against the built-in policy set:
+
+```console
+$ docker scout policy myorg/app:latest
+```
+
+Use `--exit-code` to fail the pipeline when any policy is not met:
+
+```console
+$ docker scout policy myorg/app:latest --exit-code
+```
+
+To customize which policies run and their thresholds, pass a policy-config
+file:
+
+```console
+$ docker scout policy myorg/app:latest --policy-config policies.json
+```
+
+Policy results are also surfaced by `docker scout quickview` and
+`docker scout compare`, which accept the same `--policy-file`,
+`--policy-dir`, `--policy-bundle`, and `--policy-config` flags.
+
+Other useful flags:
+
+```console
+# Evaluate a specific platform for a multi-platform image
+$ docker scout policy myorg/app:latest --platform linux/arm64
+
+# Show results for a specific policy only
+$ docker scout policy myorg/app:latest --only-policy "No copyleft licenses"
+
+# Write the report to a file
+$ docker scout policy myorg/app:latest --output report.txt
+```
+
+## Health score
+
+`docker scout policy`, `docker scout quickview`, and `docker scout compare` also
+report a health score alongside the policy results: a numeric percentage and an
+A-F letter grade, computed entirely from the local policy evaluation. No data is
+sent to the Scout service to compute it.
+
+```console
+$ docker scout policy myorg/app:latest
+...
+Health score  B (83%)
+```
+
+`docker scout compare` shows the score for both images:
+
+```console
+Health score  Analyzed B (83%)  Comparison C (65%)
+```
+
+### How the score is calculated
+
+The score is a weighted pass ratio:
+
+- Each policy contributes a weight to the total, taken from its `custom.weight`
+  metadata annotation (see [Metadata annotations](#metadata-annotations)) or a
+  `weight` override in the policy-config file. Policies without a declared
+  weight default to `10`.
+- A policy that passes (reports zero violations) contributes its full weight to
+  the scored points.
+- A policy that fails still counts its weight toward the total, but contributes
+  nothing to the scored points, which lowers the score.
+- A policy with no data to evaluate (unknown) also counts toward the total
+  without contributing to the scored points.
+- A policy with a weight of `0` is excluded from the score entirely.
+
+The percentage is `scored / total * 100`, mapped to a letter grade using strict
+greater-than thresholds:
+
+| Score | Grade |
+| --- | --- |
+| > 90% | A |
+| > 70% | B |
+| > 50% | C |
+| > 30% | D |
+| > 10% | E |
+| <= 10% | F |
+
+Thresholds are exclusive of their lower bound, so an exact boundary value
+grades down: a score of exactly 90% is a B, not an A; exactly 70% is a C, and
+so on.
+
+If every policy is excluded from the score (for example, all policies are
+configured with `weight: 0`), no health score is shown at all.
+
+To change a policy's contribution to the score, set `custom.weight` in the
+policy's Rego metadata, or override it per policy in the policy-config file:
+
+```json
+{
+  "policies": [
+    {
+      "name": "no-copyleft-licenses",
+      "weight": 0
+    }
+  ]
+}
+```
+
+## Built-in policies
+
+The following policies are available by default:
+
+| Policy | What it checks |
+| --- | --- |
+| No fixable critical or high vulnerabilities | Critical/high CVEs that have a fix available |
+| No high-profile vulnerabilities | Curated list of well-known CVEs (Log4Shell, XZ backdoor, and others) |
+| No copyleft licenses | Packages under AGPL, GPL, LGPL, MPL, and similar licenses |
+| No outdated base images | Base image is behind the latest digest of its tag |
+| Supply chain attestations | Provenance and SBOM attestations are attached |
+| Default non-root user | Image is configured to run as a non-root user |
+| No unapproved base images | Base image matches a configurable allowlist |
+
+## Configure built-in policies
+
+A JSON policy-config file controls which policies run and their thresholds.
+Pass it with `--policy-config`.
+
+```json
+{
+  "policies": [
+    {
+      "name": "fixable-vulnerabilities",
+      "config": {
+        "severities": ["CRITICAL"],
+        "grace_period_days": 14
+      }
+    },
+    {
+      "name": "no-stale-base-images",
+      "enabled": false
+    }
+  ]
+}
+```
+
+- `policies[].name`: the policy's stable ID (see the following table).
+- `policies[].enabled`: set to `false` to skip the policy. Policies not listed are enabled by default.
+- `policies[].weight`: overrides the policy's `custom.weight` metadata annotation,
+  which determines its contribution to the [health score](#health-score). A
+  weight of `0` excludes the policy from the score. When omitted, the policy's
+  own annotation is used, or `10` if it has none.
+- `policies[].config`: an object passed to the policy as `data.config`.
+
+### Configuration reference
+
+The following table lists the configurable keys for each built-in policy.
+
+| Policy (stable ID) | config key | Default | Description |
+| --- | --- | --- | --- |
+| `fixable-vulnerabilities` | `severities` | `["CRITICAL","HIGH"]` | Severity levels that count as a violation |
+| `fixable-vulnerabilities` | `fixable_only` | `true` | When `true`, only vulnerabilities with a known fix count |
+| `fixable-vulnerabilities` | `package_types` | `[]` | Allowlist of PURL package types to consider; empty means all |
+| `fixable-vulnerabilities` | `grace_period_days` | `0` | Days a newly disclosed CVE is exempt |
+| `high-profile-vulnerabilities` | `cves` | [Default high-profile CVEs](#default-high-profile-cves) | CVE IDs considered high-profile |
+| `high-profile-vulnerabilities` | `ignored_cves` | `[]` | CVE IDs excluded from causing a failure |
+| `high-profile-vulnerabilities` | `include_cisa_kev` | `true` | Also flag vulnerabilities in the CISA KEV catalog |
+| `copyleft-license` | `licenses` | AGPL/GPL/LGPL/MPL/… | SPDX license IDs treated as copyleft |
+| `copyleft-license` | `ignored_packages` | `[]` | Package URLs exempted from the check |
+| `approved-base-images` | `allowed_base_images` | `["*"]` | Glob patterns of allowed base image references |
+| `approved-base-images` | `allowed_distros_only` | `true` | When enabled, base image must use an allowed OS distribution |
+| `approved-base-images` | `allowed_distros` | curated list | OS distributions considered allowed |
+| `supply-chain-attestations` | `required_attestations` | provenance and SBOM predicate types | Attestation predicate types that must be present |
+
+#### Default high-profile CVEs
+
+The built-in `cves` list includes the following CVEs. Docker updates this list
+as new high-profile vulnerabilities are disclosed.
+
+| CVE ID | Common name |
+| --- | --- |
+| CVE-2014-0160 | Heartbleed |
+| CVE-2014-6271 | Shellshock |
+| CVE-2021-44228 | Log4Shell |
+| CVE-2021-45046 | Log4j follow-up |
+| CVE-2022-22965 | Spring4Shell |
+| CVE-2023-38545 | curl SOCKS5 heap overflow |
+| CVE-2023-44487 | HTTP/2 Rapid Reset |
+| CVE-2024-3094 | XZ Utils backdoor |
+
+To override the list, set `cves` in your policy-config file:
+
+```json
+{
+  "policies": [
+    {
+      "name": "high-profile-vulnerabilities",
+      "config": {
+        "cves": ["CVE-2021-44228", "CVE-2024-3094"]
+      }
+    }
+  ]
+}
+```
+
+## Write custom policies
+
+Policies are Rego modules in the `docker.scout` package. A policy declares a
+boolean `pass` rule and a `violation` set. Use `--policy-file` for a single
+file or `--policy-dir` to load a directory recursively.
+
+```rego
+# METADATA
+# title: No packages from internal registry
+# description: Flags packages sourced from registry.internal.example.com.
+# custom:
+#   name: no-internal-registry
+#   result_type: generic
+#   weight: 5
+#   not_compliant_title: Packages from internal registry found
+#   details_order:
+#   - purl
+#   - reason
+package docker.scout
+
+import rego.v1
+
+default pass := false
+
+pass if {
+    count(violation) == 0
+}
+
+violation contains v if {
+    att := oci.referrer("https://scout.docker.com/sbom/v0.1")
+    some pkg in att.statement.predicate.artifacts
+    contains(pkg.purl, "registry.internal.example.com")
+    v := {
+        "message": sprintf("Package %s sourced from internal registry", [pkg.purl]),
+        "detail": {
+            "purl": pkg.purl,
+            "reason": "matches registry.internal.example.com",
+        },
+    }
+}
+```
+
+```console
+# Single file
+$ docker scout policy myorg/app:latest --policy-file ./no-internal-registry.rego
+
+# Directory of policies
+$ docker scout policy myorg/app:latest --policy-dir ./rego
+
+# Custom policies combined with a config file
+$ docker scout policy myorg/app:latest \
+  --policy-dir ./rego \
+  --policy-config ./policies.json
+```
+
+Both `--policy-file` and `--policy-dir` are repeatable. When either is
+provided, the built-in defaults are not loaded automatically. To run both
+built-in and custom policies together, publish the built-in set to a registry
+with `docker scout policy publish`, then pass both bundles using
+`--policy-bundle`:
+
+```console
+$ docker scout policy myorg/app:latest \
+  --policy-bundle registry.example.com/default-policies:latest \
+  --policy-bundle registry.example.com/dhi-policies:latest \
+  --policy-file ./custom.rego
+```
+
+`--policy-bundle` is repeatable, so you can combine as many bundles as needed
+alongside local policy files.
+
+### Metadata annotations
+
+The CLI reads [OPA metadata annotations](https://www.openpolicyagent.org/docs/latest/annotations/)
+to render results. Place them in a `# METADATA` block immediately above the
+`package` declaration.
+
+| Annotation | Purpose |
+| --- | --- |
+| `title` | Human-readable policy name shown in the report |
+| `description` | Longer explanation |
+| `custom.name` | Stable ID used to match `--policy-config` entries. Defaults to the package path if omitted |
+| `custom.result_type` | How violations are rendered: `vulnerability`, `license`, `boolean`, or `generic` (default) |
+| `custom.weight` | Scoring weight and display sort order. Higher weights sort first in the report and contribute more to the [health score](#health-score). Defaults to `10` when omitted; a weight of `0` excludes the policy from the score |
+| `custom.not_compliant_title` | Status label shown when the policy fails |
+| `custom.details_order` | Ordered list of `detail` keys to display as columns |
+
+### Output contract
+
+- `pass`: `true` when the policy is met. The standard form is `pass if { count(violation) == 0 }`.
+- `violation`: a set of objects. Each object should have a `message` string and
+  a `detail` object whose keys match `custom.details_order`. An optional
+  `remediation` string is shown as remediation guidance.
+
+### Input and built-in functions
+
+The evaluation input is the enriched SBOM. Key entry points:
+
+- `input.source.image`: image metadata, including `input.source.image.config.config.User`,
+  `input.source.image.name`, and `input.source.image.digest`.
+- `data.config`: the per-policy `config` object from the policy-config file.
+
+The following built-in functions are available in policy Rego:
+
+| Function | Description |
+| --- | --- |
+| `oci.referrer(predicateType)` | Retrieve an attestation by predicate type |
+| `oci.canonical_name(ref)` | Normalize an image reference, for example `"node:25"` to `"docker.io/library/node"` |
+| `oci.image_digest(ref)` | Resolve the current digest of a tag from its registry |
+| `oci.index(ref, digest)` | Get the OCI image index for an image |
+| `oci.referrer_index(ref, digest)` | Get the OCI referrer index for an image |
+| `oci.referrer_by_digest(ref, digest)` | Get a referrer for an image by digest |
+| `scout.parse_purl(purl)` | Parse a PURL into its components |
+| `scout.package_provenance(purl)` | Provenance of a package from the SBOM |
+| `scout.vulnerabilities(purls)` | Vulnerabilities for the given PURLs |
+| `scout.package_recommendation(purl)` | Recommended (fixed) version for a package |
+| `scout.base_image()` | Base image matches recorded in the SBOM |
+| `cosign.verify_dsse(envelope, opts)` | Verify an in-toto DSSE envelope's cosign signature |
+| `cosign.verify_image(ref, opts)` | Verify an image's cosign signature |
+| `gpg.verify_commit(...)` | Verify a detached commit signature |
+
+Common predicate types for `oci.referrer`:
+
+| Predicate type | Content |
+| --- | --- |
+| `https://scout.docker.com/vulnerabilities/v0.1` | CVEs per package |
+| `https://scout.docker.com/sbom/v0.1` | SBOM artifacts, with `purl` and `licenses` |
+| `https://scout.docker.com/provenance/v0.1` | Build provenance, including `base_image` |
+| `https://openvex.dev/ns/v0.2.0` | VEX statements |
+
+## Debug policies
+
+Add `print()` statements to your Rego and enable debug output by setting
+`"debug": true` in the policy-config file:
+
+```rego
+violation contains v if {
+    att := oci.referrer("https://scout.docker.com/sbom/v0.1")
+    some pkg in att.statement.predicate.artifacts
+    print("checking", pkg.purl)
+    contains(pkg.purl, blocked)
+    # ...
+}
+```
+
+```json
+{
+  "debug": true,
+  "policies": [
+    { "name": "no-internal-registry" }
+  ]
+}
+```
+
+Output is prefixed with the policy name and source line:
+
+```text
+no-internal-registry#28: checking pkg:deb/debian/curl@7.88.1
+```
+
+> [!NOTE]
+>
+> The `debug` field in the policy-config controls `print()` output from your
+> Rego. The global `--debug` flag is separate: it enables CLI-level debug
+> logging for bundle loading, registry resolution, and similar internals.
+
+### Inspect raw evaluation results
+
+Use `--result-file` to write the full evaluation result for every policy to a
+JSON file. This is useful when iterating on a custom policy to inspect
+intermediate values.
+
+```console
+$ docker scout policy myorg/app:latest \
+  --policy-file ./no-internal-registry.rego \
+  --result-file result.json
+```
+
+Each entry in the output contains:
+
+- `pass`: the policy's boolean outcome.
+- `violations`: the `detail` object of each reported violation.
+- `bindings`: the raw `data.docker.scout` document, including the `violation`
+  set and any other complete rules, for inspecting intermediate values.
+- `metrics`: OPA evaluation metrics (timers and counters).
+
+```json
+{
+  "no-internal-registry": {
+    "pass": false,
+    "violations": [
+      { "purl": "pkg:deb/debian/curl@7.88.1", "reason": "matches \"registry.internal.example.com\"" }
+    ],
+    "bindings": {
+      "blocked": "registry.internal.example.com",
+      "violation": [
+        {
+          "message": "Package pkg:deb/debian/curl@7.88.1 sourced from internal registry",
+          "detail": {
+            "purl": "pkg:deb/debian/curl@7.88.1",
+            "reason": "matches \"registry.internal.example.com\""
+          }
+        }
+      ]
+    },
+    "metrics": {
+      "timer_rego_query_eval_ns": 1234567
+    }
+  }
+}
+```
+
+## Share policies as OCI bundles
+
+Package `.rego` files as an OCI artifact and distribute them through any
+registry.
+
+### Publish a bundle
+
+```console
+# Publish a directory of policies
+$ docker scout policy publish \
+  --policy-dir ./rego \
+  registry.example.com/my-policies:latest
+
+# Publish specific files
+$ docker scout policy publish \
+  --policy-file fixable.rego \
+  --policy-file licenses.rego \
+  registry.example.com/my-policies:latest
+
+# Publish the built-in default set
+$ docker scout policy publish registry.example.com/my-policies:latest
+```
+
+Each module's metadata is validated before publishing. The command prints the
+resulting digest and the list of bundled policies.
+
+### Use a bundle
+
+```console
+$ docker scout policy myorg/app:latest \
+  --policy-bundle registry.example.com/my-policies:latest
+
+# Combine a bundle with local files and a config
+$ docker scout policy myorg/app:latest \
+  --policy-bundle registry.example.com/my-policies:latest \
+  --policy-file ./extra.rego \
+  --policy-config ./policies.json
+```
+
+`--policy-bundle` is repeatable. Authentication uses your existing Docker
+registry credentials. Bundles are cached by digest, so re-running against the
+same bundle does not re-download it. A new digest (for example, after
+re-publishing `:latest`) is fetched automatically.
diff --git a/content/manuals/scout/policy/remediation.md b/content/manuals/scout/policy/remediation.md
deleted file mode 100644
index 48701160381f..000000000000
--- a/content/manuals/scout/policy/remediation.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: Remediation with Docker Scout
-description: Learn how Docker Scout can help you improve your software quality automatically, using remediation
-keywords: scout, supply chain, security, remediation, automation
----
-
-{{< summary-bar feature_name="Remediation with Docker Scout" >}}
-
-Docker Scout helps you remediate supply chain or security issues by providing
-recommendations based on policy evaluation results. Recommendations are
-suggested actions you can take that improve policy compliance, or that add
-metadata to images which enables Docker Scout to provide better evaluation
-results and recommendations.
-
-Docker Scout provides remediation advice for the default policies of the
-following policy types:
-
-- [Up-to-Date Base Images](#up-to-date-base-images-remediation)
-- [Supply Chain Attestations](#supply-chain-attestations-remediation)
-
-<!-- TODO(dvdksn): verify the following -->
-> [!NOTE]
-> Guided remediation is not supported for custom policies.
-
-For images that violate policy, the recommendations focus on addressing
-compliance issues and fixing violations. For images where Docker Scout is
-unable to determine compliance, recommendations show you how to meet the
-prerequisites that ensure Docker Scout can successfully evaluate the policy.
-
-## View recommendations
-
-Recommendations appear on the policy details pages of the Docker Scout
-Dashboard. To get to this page:
-
-1. Go to the [Policies page](https://scout.docker.com/reports/policy) in the Docker Scout Dashboard.
-2. Select a policy in the list.
-
-The policy details page groups evaluation results into two different tabs
-depending on the policy status:
-
-- Violations
-- Compliance unknown
-
-The **Violations** tab lists images that don't comply with the selected policy.
-The **Compliance unknown** tab lists images that Docker Scout is unable to
-determine the compliance status for. When compliance is unknown, Docker Scout
-needs more information about the image.
-
-To view recommended actions for an image, hover over one of the images in the
-list to reveal a **View fixes** button.
-
-![Remediation for policy violations](../images/remediation.png)
-
-Select the **View fixes** button to opens the remediation side panel containing
-recommended actions for your image.
-
-If there are more than one recommendations available, the primary
-recommendation displays as the **Recommended fix**. Additional recommendations
-are listed as **Quick fixes**. Quick fixes are usually actions that provide a
-temporary solution.
-
-The side panel may also contain one or more help sections related to the
-available recommendations.
-
-## Up-to-Date Base Images remediation
-
-The **Up-to-Date Base Images** policy checks whether the base image you use is
-up-to-date. The recommended actions displayed in the remediation side panel
-depend on how much information Docker Scout has about your image. The more
-information that's available, the better the recommendations.
-
-The following scenarios outline the different recommendations depending on the
-information available about the image.
-
-### No provenance attestations
-
-For Docker Scout to be able to evaluate this policy, you must add [provenance
-attestations](/manuals/build/metadata/attestations/slsa-provenance.md) to your image. If
-your image doesn't have provenance attestations, compliance is undeterminable.
-
-<!--
-  TODO(dvdksn): no support for the following, yet
-
-  When provenance attestations are unavailable, Docker Scout provides generic,
-  best-effort recommendations in the remediation side panel. These
-  recommendations estimate your base using information from image analysis
-  results. The base image version is unknown, but you can manually select the
-  version you use in the remediation side panel. This lets Docker Scout evaluate
-  whether the base image detected in the image analysis is up-to-date with the
-  version you selected.
-
-  https://github.com/docker/docs/pull/18961#discussion_r1447186845
--->
-
-### Provenance attestations available
-
-With provenance attestations added, Docker Scout can correctly detect the base
-image version that you're using. The version found in the attestations is
-cross-referenced against the current version of the corresponding tag to
-determine if it's up-to-date.
-
-If there's a policy violation, the recommended actions show how to update your
-base image version to the latest version, while also pinning the base image
-version to a specific digest. For more information, see [Pin base image
-versions](/manuals/build/building/best-practices.md#pin-base-image-versions).
-
-### GitHub integration enabled
-
-If you're hosting the source code for your image on GitHub, you can enable the
-[GitHub integration](../integrations/source-code-management/github.md). This
-integration enables Docker Scout to provide even more useful remediation
-advice, and lets you initiate remediation for violations directly from the
-Docker Scout Dashboard.
-
-With the GitHub integration enabled, you can use the remediation side panel to
-raise a pull request on the GitHub repository of the image. The pull request
-automatically updates the base image version in your Dockerfile to the
-up-to-date version.
-
-This automated remediation pins your base image to a specific digest, while
-helping you stay up-to-date as new versions become available. Pinning the base
-image to a digest is important for reproducibility, and helps avoid unwanted
-changes from making their way into your supply chain.
-
-For more information about base image pinning, see [Pin base image
-versions](/manuals/build/building/best-practices.md#pin-base-image-versions).
-
-<!--
-  TODO(dvdksn): no support for the following, yet
-
-  Enabling the GitHub integration also allows Docker Scout to visualize the
-  remediation workflow in the Docker Scout Dashboard. Each step, from the pull
-  request being raised to the image being deployed to an environment, is
-  displayed in the remediation sidebar when inspecting the image.
-
-  https://github.com/docker/docs/pull/18961#discussion_r1447189475
--->
-
-## Supply Chain Attestations remediation
-
-The default **Supply Chain Attestations** policy requires full provenance and
-SBOM attestations on images. If your image is missing an attestation, or if an
-attestation doesn't contain enough information, the policy is violated.
-
-The recommendations available in the remediation side panel helps guide you to
-what action you need to take to address the issues. For example, if your image
-has a provenance attestation, but the attestation doesn't contain enough
-information, you're recommended to re-build your image with
-[`mode=max`](/manuals/build/metadata/attestations/slsa-provenance.md#max) provenance.
diff --git a/content/manuals/scout/policy/scores.md b/content/manuals/scout/policy/scores.md
deleted file mode 100644
index e6b2d7af80c1..000000000000
--- a/content/manuals/scout/policy/scores.md
+++ /dev/null
@@ -1,180 +0,0 @@
----
-title: Docker Scout health scores
-description: |
-  Docker Scout health scores provide a supply chain assessment for Docker Hub
-  images, grading them from A to F based on various security policies.
-keywords: scout, health scores, evaluation, checks, grades, docker hub
----
-
-{{< summary-bar feature_name="Docker Scout health scores" >}}
-
-Docker Scout health scores provide a security assessment, and overall supply
-chain health, of images on Docker Hub, helping you determine whether an image
-meets established security best practices. The scores range from A to F, where
-A represents the highest level of security and F the lowest, offering an
-at-a-glance view of the security posture of your images.
-
-Only users who are members of the organization that owns the repository, and
-have at least “read” access to the repository, can view the health score. The
-score is not visible to users outside the organization or members without
-"read" access.
-
-## Viewing health scores
-
-{{< tabs >}}
-{{< tab name="Docker Hub" >}}
-
-To view the health score of an image in Docker Hub:
-
-1. Go to Docker Hub and sign in.
-2. Navigate to your organization's page.
-
-In the list of repositories, you can see the health score of each repository
-based on the latest pushed tag.
-
-![Repository health score](../images/score-badges-repolist.png)
-
-{{< /tab >}}
-{{< tab name="Docker Desktop" >}}
-
-To view the health score of an image in Docker Desktop:
-
-1. Open Docker Desktop and sign in to your Docker account.
-2. Navigate to the **Images** view and select the **Hub** tab.
-
-In the list of repositories, the **Health** column displays the scores of the
-different tags that have been pushed to Docker Hub.
-
-![Repository health score](../images/score-badges-dd.png)
-
-{{< /tab >}}
-{{< /tabs >}}
-
-The health score badge is color-coded to indicate the overall health of the
-repository:
-
-- **Green**: A score of A or B.
-- **Yellow**: A score of C.
-- **Orange**: A score of D.
-- **Red**: A score of E or F.
-- **Gray**: An `N/A` score.
-
-The score is also displayed on the Docker Hub page for a given repository,
-along with each policy that contributed to the score.
-
-![Scout "A" health score](../images/score-a-shiny.png?w=450px)
-
-## Scoring system
-
-Health scores are determined by evaluating images against Docker Scout
-[policies](./_index.md). These policies align with best practices for the
-software supply chain.
-
-If your image repositories are already enrolled with Docker Scout, the health
-score is calculated automatically based on the policies that are enabled for
-your organization. This also includes any custom policies that you have
-configured.
-
-If you're not using Docker Scout, the health scores show the compliance of your
-images with the default policies, a set of supply chain rules recommended by
-Docker as foundational standards for images. You can enable Docker Scout for
-your organization and edit the policy configurations to get a more relevant
-health score based on your specific policies.
-
-### Scoring process
-
-Each policy is assigned a points value based on its
-[type](/manuals/scout/policy/_index.md#policy-types). If the image is compliant
-with a policy, it is awarded the points value for that policy type. The health
-score of an image is calculated based on the percentage of points achieved
-relative to the total possible points.
-
-1. Policy compliance is evaluated for the image.
-2. Points are awarded based on compliance with policies.
-3. The points achieved percentage is calculated:
-
-   ```text
-   Percentage = (Points / Total) * 100
-   ```
-
-4. The final score is assigned based on the percentage of points achieved, as
-   shown in the following table:
-
-   | Points percentage (awarded out of total) | Score |
-   | ---------------------------------------- | ----- |
-   | More than 90%                            | A     |
-   | 71% to 90%                               | B     |
-   | 51% to 70%                               | C     |
-   | 31% to 50%                               | D     |
-   | 11% to 30%                               | E     |
-   | Less than 10%                            | F     |
-
-### N/A scores
-
-Images can also be assigned an `N/A` score, which can happen when:
-
-- The image is larger than 4GB (compressed size).
-- The image architecture is not `linux/amd64` or `linux/arm64`.
-- The image is too old and does not have fresh data for evaluation.
-
-If you see an `N/A` score, consider the following:
-
-- If the image is too large, try reducing the size of the image.
-- If the image has an unsupported architecture, rebuild the image for a
-  supported architecture.
-- If the image is too old, push a new tag to trigger a fresh evaluation.
-
-### Policy weights
-
-Different policy types carry varying weights, which impact the score assigned
-to an image during evaluation, as shown in the following table.
-
-| Policy type                                                                                  | Points |
-| -------------------------------------------------------------------------------------------- | ------ |
-| [Severity-Based Vulnerability](/manuals/scout/policy/_index.md#severity-based-vulnerability) | 20     |
-| [High-Profile Vulnerabilities](/manuals/scout/policy/_index.md#high-profile-vulnerabilities) | 20     |
-| [Supply Chain Attestations](/manuals/scout/policy/_index.md#supply-chain-attestations)       | 15     |
-| [Approved Base Images](/manuals/scout/policy/_index.md#approved-base-images)                 | 15     |
-| [Up-to-Date Base Images](/manuals/scout/policy/_index.md#up-to-date-base-images)             | 10     |
-| [SonarQube Quality Gates](/manuals/scout/policy/_index.md#sonarqube-quality-gates) \*        | 10     |
-| [Default Non-Root User](/manuals/scout/policy/_index.md#default-non-root-user)               | 5      |
-| [Compliant Licenses](/manuals/scout/policy/_index.md#compliant-licenses)                     | 5      |
-
-\* _This policy is not enabled by default and must be configured by the user._
-
-### Evaluation
-
-Health scores are calculated for new images pushed to Docker Hub after the
-feature is enabled. The health scores help you maintain high security standards
-and ensure your applications are built on secure and reliable images.
-
-### Repository scores
-
-In addition to individual image scores (per tag or digest), each repository
-receives a health score based on the latest pushed tag, providing an overall
-view of the repository's security status.
-
-### Example
-
-For an image with a total possible score of 100 points:
-
-- If the image only deviates from one policy, worth 5 points, its score will be
-  95 out of 100. Since this score is above the 90th percentile, the image
-  receives an A health score.
-- If the image is non-compliant with more policies and scores 65 out of 100, it
-  receives a C health score, reflecting its lower compliance.
-
-## Improving your health score
-
-To improve the health score of an image, take steps to ensure that the image is
-compliant with the Docker Scout recommended [policies](./_index.md).
-
-1. Go to the [Docker Scout Dashboard](https://scout.docker.com/).
-2. Sign in using your Docker ID.
-3. Go to [Repository settings](https://scout.docker.com/settings/repos) and
-   enable Docker Scout for your Docker Hub image repositories.
-4. Analyze the [policy compliance](./_index.md) for your repositories,
-   and take actions to ensure your images are policy-compliant.
-
-Since policies are weighted differently, prioritize the policies with the
-highest scores for a greater impact on your image's overall score.
diff --git a/content/manuals/scout/policy/view.md b/content/manuals/scout/policy/view.md
deleted file mode 100644
index 71fdd018e75d..000000000000
--- a/content/manuals/scout/policy/view.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: View Docker Scout policy status
-description: |
-  The Docker Scout Dashboard and the `docker scout policy` command lets you
-  view policy status of images.
-keywords: scout, policy, status, vulnerabilities, supply chain, cves, licenses
----
-
-You can track policy status for your artifacts from the [Docker Scout
-Dashboard](#dashboard), or using the [CLI](#cli).
-
-## Dashboard
-
-The **Overview** tab of the [Docker Scout Dashboard](https://scout.docker.com/)
-displays a summary of recent changes in policy for your repositories.
-This summary shows images that have seen the most change in their policy
-evaluation between the most recent image and the previous image.
-
-![Policy overview](../images/policy-overview.webp)
-
-### Policy status per repository
-
-The **Images** tab shows the current policy status, and recent policy trend,
-for all images in the selected environment. The **Policy status** column in the
-list shows:
-
-- Number of fulfilled policies versus the total number of policies
-- Recent policy trends
-
-![Policy status in the image list](../images/policy-image-list.webp)
-
-The policy trend, denoted by the directional arrows, indicates whether an image
-is better, worse, or unchanged in terms of policy, compared to the previous
-image in the same environment.
-
-- The green arrow pointing upwards shows the number of policies that got better
-  in the latest pushed image.
-- The red arrow pointing downwards shows the number of policies that got worse
-  in the latest pushed image.
-- The bidirectional gray arrow shows the number of policies that were unchanged
-  in the latest version of this image.
-
-If you select a repository, you can open the **Policy** tab for a detailed
-description of the policy delta for the most recently analyzed image and its
-predecessor.
-
-### Detailed results and remediation
-
-To view the full evaluation results for an image, navigate to the image tag in
-the Docker Scout Dashboard and open the **Policy** tab. This shows a breakdown
-for all policy violations for the current image.
-
-![Detailed Policy Evaluation results](../images/policy-detailed-results.webp)
-
-This view also provides recommendations on how to improve improve policy status
-for violated policies.
-
-![Policy details in the tag view](../images/policy-tag-view.webp)
-
-For vulnerability-related policies, the policy details view displays the fix
-version that removes the vulnerability, when a fix version is available. To fix
-the issue, upgrade the package version to the fix version.
-
-For licensing-related policies, the list shows all packages whose license
-doesn't meet the policy criteria. To fix the issue, find a way to remove the
-dependency to the violating package, for example by looking for an alternative
-package distributed under a more appropriate license.
-
-## CLI
-
-To view policy status for an image from the CLI, use the `docker scout policy`
-command.
-
-```console
-$ docker scout policy \
-  --org dockerscoutpolicy \
-  --platform linux/amd64 \
-  dockerscoutpolicy/email-api-service:0.0.2
-
-    ✓ Pulled
-    ✓ Policy evaluation results found
-
-
-​## Overview
-​
-​             │               Analyzed Image
-​─────────────┼──────────────────────────────────────────────
-​  Target     │  dockerscoutpolicy/email-api-service:0.0.2
-​    digest   │  17b1fde0329c
-​    platform │ linux/amd64
-​
-​
-​## Policies
-​
-​Policy status  FAILED  (2/8 policies met, 3 missing data)
-​
-​  Status │                  Policy                             │           Results
-​─────────┼─────────────────────────────────────────────────────┼──────────────────────────────
-​  ✓      │ No copyleft licenses                                │    0 packages
-​  !      │ Default non-root user                               │
-​  !      │ No fixable critical or high vulnerabilities         │    2C     1H     0M     0L
-​  ✓      │ No high-profile vulnerabilities                     │    0C     0H     0M     0L
-​  ?      │ No outdated base images                             │    No data
-​         │                                                     │    Learn more ↗
-​  ?      │ SonarQube quality gates passed                      │    No data
-​         │                                                     │    Learn more ↗
-​  !      │ Supply chain attestations                           │    2 deviations
-​  ?      │ No unapproved base images                           │    No data
-
-...
-```
-
-For more information about the command, refer to the [CLI
-reference](/reference/cli/docker/scout/policy.md).
diff --git a/content/manuals/scout/quickstart.md b/content/manuals/scout/quickstart.md
index 7a1da8ae022c..f473d07047f0 100644
--- a/content/manuals/scout/quickstart.md
+++ b/content/manuals/scout/quickstart.md
@@ -207,7 +207,7 @@ The classic image store doesn't support manifest lists,
 which is how the provenance attestations are attached to an image.
 
 Open **Settings** in Docker Desktop. Under the **General** section, make sure
-that the **Use containerd for pulling and storing images** option is checked, then select **Apply & Restart**.
+that the **Use containerd for pulling and storing images** option is checked, then select **Apply**.
 Note that changing image stores temporarily hides images and containers of the
 inactive image store until you switch back.
 
@@ -248,15 +248,9 @@ because the example image uses an old version `alpine` as a base image.
 
 Close the **Recommended fixes for base image** modal. In the policy listing, select **View fixes** button, next to the policy name for details about the violation, and recommendations on how to address it.
 
-In this case, the recommended action is to enable
-[Docker Scout's GitHub integration](./integrations/source-code-management/github.md),
-which helps keep your base images up-to-date automatically.
-
-> [!TIP]
->
-> You can't enable this integration for the demo app used in this guide.
-> Feel free to push the code to a GitHub repository that you own,
-> and try out the integration there!
+In this case, the recommended action is to update the base image to a newer
+version. You can use GitHub Dependabot with `package-ecosystem: "docker"` to
+automate base image updates.
 
 ## Summary
 
diff --git a/content/manuals/scout/release-notes/cli.md b/content/manuals/scout/release-notes/cli.md
index 1ed667573f57..03286f631c8b 100644
--- a/content/manuals/scout/release-notes/cli.md
+++ b/content/manuals/scout/release-notes/cli.md
@@ -1,421 +1,6 @@
 ---
-title: Docker Scout CLI release notes
-linkTitle: CLI release notes
-description: Learn about the latest features of the Docker Scout CLI plugin
-keywords: docker scout, release notes, changelog, cli, features, changes, delta, new, releases, github actions
----
-
-This page contains information about the new features, improvements, known
-issues, and bug fixes in the Docker Scout [CLI plugin](https://github.com/docker/scout-cli/)
-and the `docker/scout-action` [GitHub Action](https://github.com/docker/scout-action).
-
-## 1.15.0
-
-{{< release-date date="2024-10-31" >}}
-
-### New
-
-- New `--format=cyclonedx` flag for the `docker scout sbom` to output the SBOM in CycloneDX format.
-
-### Enhancements
-
-- Use high-to-low sort order for CVE summary.
-- Support for enabling and disabling repositories that enabled by `docker scout push` or `docker scout watch`.
-
-### Bug fixes
-
-- Improve messaging when analyzing `oci` directories without attestations.
-  Only single-platform images and multi-platform image _with attestations_ are supported.
-  Multi-platform images without attestations are not supported.
-- Improve classifiers and SBOM indexer:
-  - Add classifier for Liquibase `lpm`.
-  - Add Rakudo Star/MoarVM binary classifier.
-  - Add binary classifiers for silverpeas utilities.
-- Improve reading and caching of attestations with the containerd image store.
-
-## 1.14.0
-
-{{< release-date date="2024-09-24" >}}
-
-### New
-
-- Add suppression information at the CVE level in the `docker scout cves` command.
-
-### Bug fixes
-
-- Fix listing CVEs for dangling images, for example: `local://sha256:...`
-- Fix panic when analysing a file system input, for instance with `docker scout cves fs://.`
-
-## 1.13.0
-
-{{< release-date date="2024-08-05" >}}
-
-### New
-
-- Add `--only-policy` filter option to the `docker scout quickview`, `docker scout policy` and `docker scout compare` commands.
-- Add `--ignore-suppressed` filter option to `docker scout cves` and `docker scout quickview`  commands to filter out CVEs affected by [exceptions](/scout/explore/exceptions/).
-
-### Bug fixes and enhancements
-
-- Use conditional policy name in checks.
-- Add support for detecting the version of a Go project set using linker flags,
-  for example:
-
-  ```console
-  $ go build -ldflags "-X main.Version=1.2.3"
-  ```
-
-## 1.12.0
-
-{{< release-date date="2024-07-31" >}}
-
-### New
-
-- Only display vulnerabilities from the base image:
-
-  ```console {title="CLI"}
-  $ docker scout cves --only-base IMAGE
-  ```
-
-  ```yaml {title="GitHub Action"}
-  uses: docker/scout-action@v1
-  with:
-    command: cves
-    image: [IMAGE]
-    only-base: true
-  ```
-
-- Account for VEX in `quickview` command.
-
-  ```console {title="CLI"}
-  $ docker scout quickview IMAGE --only-vex-affected --vex-location ./path/to/my.vex.json
-  ```
-
-  ```yaml {title="GitHub Action"}
-  uses: docker/scout-action@v1
-  with:
-    command: quickview
-    image: [IMAGE]
-    only-vex-affected: true
-    vex-location: ./path/to/my.vex.json
-  ```
-
-- Account for VEX in `cves` command (GitHub Actions).
-
-  ```yaml {title="GitHub Action"}
-  uses: docker/scout-action@v1
-  with:
-    command: cves
-    image: [IMAGE]
-    only-vex-affected: true
-    vex-location: ./path/to/my.vex.json
-  ```
-
-### Bug fixes and enhancements
-
-- Update `github.com/docker/docker` to `v26.1.5+incompatible` to fix CVE-2024-41110.
-- Update Syft to 1.10.0.
-
-## 1.11.0
-
-{{< release-date date="2024-07-25" >}}
-
-### New
-
-- Filter CVEs listed in the CISA Known Exploited Vulnerabilities catalog.
-
-  ```console {title="CLI"}
-  $ docker scout cves [IMAGE] --only-cisa-kev
-
-  ... (cropped output) ...
-  ## Packages and Vulnerabilities
-
-  0C     1H     0M     0L  io.netty/netty-codec-http2 4.1.97.Final
-  pkg:maven/io.netty/netty-codec-http2@4.1.97.Final
-
-  ✗ HIGH CVE-2023-44487  CISA KEV  [OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities]
-    https://scout.docker.com/v/CVE-2023-44487
-    Affected range  : <4.1.100
-    Fixed version   : 4.1.100.Final
-    CVSS Score      : 7.5
-    CVSS Vector     : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
-  ... (cropped output) ...
-  ```
-
-  ```yaml {title="GitHub Action"}
-  uses: docker/scout-action@v1
-  with:
-    command: cves
-    image: [IMAGE]
-    only-cisa-kev: true
-  ```
-
-- Add new classifiers:
-  - `spiped`
-  - `swift`
-  - `eclipse-mosquitto`
-  - `znc`
-
-### Bug fixes and enhancements
-
-- Allow VEX matching when no subcomponents.
-- Fix panic when attaching an invalid VEX document.
-- Fix SPDX document root.
-- Fix base image detection when image uses SCRATCH as the base image.
-
-## 1.10.0
-
-{{< release-date date="2024-06-26" >}}
-
-### Bug fixes and enhancements
-
-- Add new classifiers:
-  - `irssi`
-  - `Backdrop`
-  - `CrateDB CLI (Crash)`
-  - `monica`
-  - `Openliberty`
-  - `dumb-init`
-  - `friendica`
-  - `redmine`
-- Fix whitespace-only originator on package breaking BuildKit exporters
-- Fix parsing image references in SPDX statement for images with a digest
-- Support `sbom://` prefix for image comparison:
-
-  ```console {title="CLI"}
-  $ docker scout compare sbom://image1.json --to sbom://image2.json
-  ```
-
-  ```yaml {title="GitHub Action"}
-  uses: docker/scout-action@v1
-  with:
-    command: compare
-    image: sbom://image1.json
-    to: sbom://image2.json
-  ```
-
-## 1.9.3
-
-{{< release-date date="2024-05-28" >}}
-
-### Bug fix
-
-- Fix a panic while retrieving cached SBOMs.
-
-## 1.9.1
-
-{{< release-date date="2024-05-27" >}}
-
-### New
-
-- Add support for the [GitLab container scanning file format](https://docs.gitlab.com/ee/development/integrations/secure.html#container-scanning) with `--format gitlab` on `docker scout cves` command.
-
-  Here is an example pipeline:
-
-  ```yaml
-     docker-build:
-    # Use the official docker image.
-    image: docker:cli
-    stage: build
-    services:
-      - docker:dind
-    variables:
-      DOCKER_IMAGE_NAME: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
-    before_script:
-      - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
-
-      # Install curl and the Docker Scout CLI
-      - |
-        apk add --update curl
-        curl -sSfL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh | sh -s --
-        apk del curl
-        rm -rf /var/cache/apk/*
-      # Login to Docker Hub required for Docker Scout CLI
-      - echo "$DOCKER_HUB_PAT" | docker login --username "$DOCKER_HUB_USER" --password-stdin
-
-    # All branches are tagged with $DOCKER_IMAGE_NAME (defaults to commit ref slug)
-    # Default branch is also tagged with `latest`
-    script:
-      - docker buildx b --pull -t "$DOCKER_IMAGE_NAME" .
-      - docker scout cves "$DOCKER_IMAGE_NAME" --format gitlab --output gl-container-scanning-report.json
-      - docker push "$DOCKER_IMAGE_NAME"
-      - |
-        if [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then
-          docker tag "$DOCKER_IMAGE_NAME" "$CI_REGISTRY_IMAGE:latest"
-          docker push "$CI_REGISTRY_IMAGE:latest"
-        fi
-    # Run this job in a branch where a Dockerfile exists
-    rules:
-      - if: $CI_COMMIT_BRANCH
-        exists:
-          - Dockerfile
-    artifacts:
-      reports:
-        container_scanning: gl-container-scanning-report.json
-  ```
-
-### Bug fixes and enhancements
-
-- Support single-architecture images for `docker scout attest add` command
-- Indicate on the `docker scout quickview` and `docker scout recommendations` commands if image provenance was not created using `mode=max`.
-  Without `mode=max`, base images may be incorrectly detected, resulting in less accurate results.
-
-## 1.9.0
-
-{{< release-date date="2024-05-24" >}}
-
-Discarded in favor of [1.9.1](#191).
-
-## 1.8.0
-
-{{< release-date date="2024-04-25" >}}
-
-### Bug fixes and enhancements
-
-- Improve format of EPSS score and percentile.
-
-  Before:
-
-  ```text
-  EPSS Score      : 0.000440
-  EPSS Percentile : 0.092510
-  ```
-
-  After:
-
-  ```text
-  EPSS Score      : 0.04%
-  EPSS Percentile : 9th percentile
-  ```
-
-- Fix markdown output of the `docker scout cves` command when analyzing local filesystem. [docker/scout-cli#113](https://github.com/docker/scout-cli/issues/113)
-
-## 1.7.0
-
-{{< release-date date="2024-04-15" >}}
-
-### New
-
-- The [`docker scout push` command](/reference/cli/docker/scout/push/) is now fully available: analyze images locally and push the SBOM to Docker Scout.
-
-### Bug fixes and enhancements
-
-- Fix adding attestations with `docker scout attestation add` to images in private repositories
-- Fix image processing for images based on the empty `scratch` base image
-- A new `sbom://` protocol for Docker Scout CLI commands let you read a Docker Scout SBOM from standard input.
-
-  ```console
-  $ docker scout sbom IMAGE | docker scout qv sbom://
-  ```
-
-- Add classifier for Joomla packages
-
-## 1.6.4
-
-{{< release-date date="2024-03-26" >}}
-
-### Bug fixes and enhancements
-
-- Fix epoch handling for RPM-based Linux distributions
-
-## 1.6.3
-
-{{< release-date date="2024-03-22" >}}
-
-### Bug fixes and enhancements
-
-- Improve package detection to ignore referenced but not installed packages.
-
-## 1.6.2
-
-{{< release-date date="2024-03-22" >}}
-
-### Bug fixes and enhancements
-
-- EPSS data is now fetched via the backend, as opposed to via the CLI client.
-- Fix an issue when rendering markdown output using the `sbom://` prefix.
-
-### Removed
-
-- The `docker scout cves --epss-date` and `docker scout cache prune --epss` flags have been removed.
-
-## 1.6.1
-
-{{< release-date date="2024-03-20" >}}
-
-> [!NOTE]
->
-> This release only affects the `docker/scout-action` GitHub Action.
-
-### New
-
-- Add support for passing in SBOM files in SDPX or in-toto SDPX format
-
-  ```yaml
-  uses: docker/scout-action@v1
-  with:
-      command: cves
-      image: sbom://alpine.spdx.json
-  ```
-
-- Add support for SBOM files in `syft-json` format
-
-  ```yaml
-  uses: docker/scout-action@v1
-  with:
-      command: cves
-      image: sbom://alpine.syft.json
-  ```
-
-## 1.6.0
-
-{{< release-date date="2024-03-19" >}}
-
-> [!NOTE]
->
-> This release only affects the CLI plugin, not the GitHub Action
-
-### New
-
-- Add support for passing in SBOM files in SDPX or in-toto SDPX format
-
-  ```console
-  $ docker scout cves sbom://path/to/sbom.spdx.json
-  ```
-
-- Add support for SBOM files in `syft-json` format
-
-  ```console
-  $ docker scout cves sbom://path/to/sbom.syft.json
-  ```
-
-- Reads SBOM files from standard input
-
-  ```console
-  $ syft -o json alpine | docker scout cves sbom://
-  ```
-
-- Prioritize CVEs by EPSS score
-
-  - `--epss` to display and prioritise the CVEs
-  - `--epss-score` and `--epss-percentile` to filter by score and percentile
-  - Prune cached EPSS files with `docker scout cache prune --epss`
-
-### Bug fixes and enhancements
-
-- Use Windows cache from WSL2
-
-  When inside WSL2 with Docker Desktop running, the Docker Scout CLI plugin now
-  uses the cache from Windows. That way, if an image has been indexed for
-  instance by Docker Desktop there's no need anymore to re-index it on WSL2
-  side.
-- Indexing is now blocked in the CLI if it has been disabled using
-  [Settings Management](/manuals/security/for-admins/hardened-desktop/settings-management/_index.md) feature.
-
-- Fix a panic that would occur when analyzing a single-image `oci-dir` input
-- Improve local attestation support with the containerd image store
-
-## Earlier versions
-
-Release notes for earlier versions of the Docker Scout CLI plugin are available
-on [GitHub](https://github.com/docker/scout-cli/releases).
+title: CLI release notes
+params:
+  sidebar:
+    goto: "https://github.com/docker/scout-cli/releases"
+---
\ No newline at end of file
diff --git a/content/manuals/scout/release-notes/platform.md b/content/manuals/scout/release-notes/platform.md
index 67fe74e87824..e2d9e856b5b4 100644
--- a/content/manuals/scout/release-notes/platform.md
+++ b/content/manuals/scout/release-notes/platform.md
@@ -15,13 +15,57 @@ issues, and bug fixes in Docker Scout releases. These release notes cover the
 Docker Scout platform, including the Dashboard. For CLI release notes, refer to
 [Docker Scout CLI release notes](./cli.md).
 
+## Q2 2026
+
+### 2026-07-01
+
+The following Docker Scout features were retired:
+
+- Health scores and Scout Everywhere: Docker Hub and Docker Desktop no longer
+  display health scores or the always-on Scout experience. Use
+  `docker scout quickview` for a quick vulnerability and policy summary. This is
+  unrelated to the health score reported locally by `docker scout policy`,
+  `docker scout quickview`, and `docker scout compare`. See
+  [Health score](../policy/local.md#health-score).
+- Sysdig integration: The Sysdig runtime environment integration has been removed.
+- GitHub source code management integration: Migrate to GitHub Dependabot for
+  base-image updates and build with `--provenance=mode=max` for
+  image-to-source linkage. See
+  [GitHub integration](../integrations/source-code-management/github.md)
+  for a migration guide.
+
+The following is deprecated and will be retired on July 30, 2026:
+
+- Slack integration: Vulnerability and policy compliance notifications to Slack
+  channels. Integrate `docker scout cves` or `docker scout policy` into your CI
+  pipeline as an alternative. See
+  [Slack integration](../integrations/team-collaboration/slack.md).
+
+The following are deprecated and will be retired on September 1, 2026:
+
+- Notifications: In-product and email notifications about newly disclosed CVEs.
+  Integrate `docker scout cves` or `docker scout policy` into your CI pipeline
+  to surface vulnerability and policy results without push notifications.
+
+- Amazon ECR integration: Migrate to
+  [`docker scout watch`](/reference/cli/docker/scout/watch/) for continuous
+  polling or integrate Scout into your CI pipeline. See
+  [ECR integration](../integrations/registry/ecr.md) for a migration guide.
+- Azure Container Registry integration: Same migration options as ECR. See
+  [ACR integration](../integrations/registry/acr.md) for a migration guide.
+- Policies page in the Dashboard: The `docker scout policy`
+  command replaces this with more options for evaluating policies. You can run
+  evaluations locally, in CI, against custom Rego policies, or using OCI
+  bundles. See [Evaluate policies](../policy/local.md).
+- SonarQube integration.
+
 ## Q4 2024
 
 New features and enhancements released in the fourth quarter of 2024.
 
 ### 2024-10-09
 
-Policy Evaluation has graduated form Early Access to General Availability.
+Policy Evaluation has graduated from Early Access to General Availability.
 
 Docker Scout Dashboard UI changes:
 
@@ -43,11 +87,11 @@ customize policies either by editing the default policy from a **policy type**
 which acts as a template. The default policies in Docker Scout are also
 implemented based on these types.
 
-For more information, refer to [policy types](/manuals/scout/policy/_index.md#policy-types).
+For more information, refer to [policy types](../policy/_index.md#policy-types).
 
 ### 2024-09-09
 
-This release changes how [health scores](/manuals/scout/policy/scores.md) are
+This release changes how health scores are
 calculated in Docker Scout. The health score calculation now considers optional
 and custom policies that you have configured for your organization.
 
@@ -61,7 +105,7 @@ calculation will be based on the out-of-the-box policies.
 ### 2024-08-13
 
 This release changes the out-of-the-box policies to align with the policy
-configurations used to evaluate Docker Scout [health scores](/manuals/scout/policy/scores.md).
+configurations used to evaluate Docker Scout health scores.
 
 The default out-of-the-box policies are now:
 
@@ -132,7 +176,7 @@ making the now-removed **All critical vulnerabilities** policy redundant.
 
 **Azure Container Registry** integration graduated from
 [Early Access](../../release-lifecycle.md#early-access-ea) to
-[General Availability](../../release-lifecycle.md#genera-availability-ga).
+[General Availability](../../release-lifecycle.md#general-availability-ga).
 
 For more information and setup instructions, see
 [Integrate Azure Container Registry](../integrations/registry/acr.md).
@@ -168,7 +212,7 @@ more precise recommendations.
 
 For more information about the types of recommendations that Docker Scout can
 provide to help you improve policy compliance, see
-[Remediation](../policy/remediation.md).
+[Use the Dashboard](../policy/dashboard.md).
 
 For more information about how to authorize the Docker Scout GitHub app on your
 source repositories, see
@@ -216,7 +260,7 @@ policies for your organization include:
 - Customize the list of "high-profile vulnerabilities"
 - Add or remove software licenses to flag as "copyleft"
 
-For more information, see [Configurable policies](../policy/configure.md).
+For more information, see [Configurable policies](../policy/dashboard.md).
 
 ### 2023-11-10
 
@@ -289,20 +333,16 @@ used to run your production workloads. It also helps reduce monitoring noise,
 by automatically excluding vulnerabilities in programs that are never loaded
 into memory, using VEX documents.
 
-For more information and getting started, see [Sysdig integration
-documentation](../integrations/environment/sysdig.md).
+For more information, see the [Scout platform release notes](#2026-07-01).
 
 #### JFrog Artifactory integration
 
 The new JFrog Artifactory integration enables automatic image analysis on
 Artifactory registries.
 
-![Animation of how to integrate Artifactory](../images/release-notes/artifactory-agent.gif)
-
 The integration involves deploying a Docker Scout Artifactory agent that polls
 for new images, performs analysis, and uploads results to Docker Scout, all
-while preserving the integrity of image data. Learn more in the [Artifactory
-integration documentation](../integrations/registry/artifactory.md)
+while preserving the integrity of image data.
 
 #### Known limitations
 
diff --git a/content/manuals/security/2fa/_index.md b/content/manuals/security/2fa/_index.md
new file mode 100644
index 000000000000..688c3449d800
--- /dev/null
+++ b/content/manuals/security/2fa/_index.md
@@ -0,0 +1,59 @@
+---
+title: Enable two-factor authentication for your Docker account
+linkTitle: Two-factor authentication
+description: Enable or disable two-factor authentication on your Docker account for enhanced security and account protection
+keywords: two-factor authentication, 2FA, docker hub security, account security, TOTP, authenticator app, disable 2FA
+weight: 20
+aliases:
+ - /docker-hub/2fa/
+ - /security/2fa/disable-2fa/
+ - /security/for-developers/2fa/
+ - /security/for-developers/2fa/disable-2fa/
+---
+
+Two-factor authentication (2FA) adds an essential security layer to your Docker account by requiring a unique security code in addition to your password when signing in. This prevents unauthorized access even if your password is compromised.
+
+When you turn on two-factor authentication, Docker provides a unique recovery code specific to your account. Store this code securely as it lets you recover your account if you lose access to your authenticator app.
+
+## Key benefits
+
+Two-factor authentication significantly improves your account security:
+
+- Protection against password breaches: Even if your password is stolen or leaked, attackers can't access your account without your second factor.
+- Secure CLI access: Required for Docker CLI authentication when 2FA is turned on, ensuring automated tools use personal access tokens instead of passwords.
+- Compliance requirements: Many organizations require 2FA for accessing development and production resources.
+- Peace of mind: Know that your Docker repositories, images, and account settings are protected by industry-standard security practices.
+
+## Prerequisites
+
+Before turning on two-factor authentication, you need:
+
+- A smartphone or device with a Time-based One-time password (TOTP) authenticator app installed
+- Access to your Docker account password
+
+## Enable two-factor authentication
+
+To turn on 2FA for your Docker account:
+
+1. Sign in to your [Docker account](https://app.docker.com/login).
+1. Select your avatar and then from the drop-down menu, select **Account settings**.
+1. Select **2FA**.
+1. Enter your account password, then select **Confirm**.
+1. Save your recovery code and store it somewhere safe. You can use your recovery code to recover your account in the event you lose access to your authenticator app.
+1. Use a TOTP mobile app to scan the QR code or enter the text code.
+1. Once you've linked your authenticator app, enter the six-digit code in the text-field.
+1. Select **Enable 2FA**.
+
+Two-factor authentication is now active on your account. You'll need to enter a security code from your authenticator app each time you sign in.
+
+## Disable two-factor authentication
+
+> [!WARNING]
+>
+> Disabling two-factor authentication results in decreased security for your Docker account.
+
+1. Sign in to your [Docker account](https://app.docker.com/login).
+2. Select your avatar and then from the drop-down menu, select **Account settings**.
+3. Select **2FA**.
+4. Enter your password, then select **Confirm**.
+5. Select **Disable 2FA**.
diff --git a/content/manuals/security/2fa/recover-hub-account.md b/content/manuals/security/2fa/recover-hub-account.md
new file mode 100644
index 000000000000..4535b6b77741
--- /dev/null
+++ b/content/manuals/security/2fa/recover-hub-account.md
@@ -0,0 +1,34 @@
+---
+title: Recover your Docker account
+description: Recover your Docker account and manage two-factor authentication recovery codes
+keywords: account recovery, two-factor authentication, 2FA, recovery code, docker hub security
+aliases:
+ - /docker-hub/2fa/recover-hub-account/
+ - /security/for-developers/2fa/recover-hub-account/
+ - /security/2fa/new-recovery-code/
+weight: 20
+---
+
+This page explains how to recover your Docker account and manage recovery codes for two-factor authentication.
+
+## Generate a new recovery code
+
+If you lost your two-factor authentication recovery code but still have access to your Docker Hub account, you can generate a new recovery code.
+
+1. Sign in to your [Docker account](https://app.docker.com/login) with your username and password.
+1. Select your avatar and from the drop-down menu, select **Account settings**.
+1. Select **2FA**.
+1. Enter your password, then select **Confirm**.
+1. Select **Generate new code**.
+
+This generates a new code. Select the visibility icon to view the code. Save your recovery code and store it somewhere safe.
+
+## Recover your account without access
+
+If you lost access to both your two-factor authentication application and your recovery code:
+
+1. Sign in to your [Docker account](https://app.docker.com/login) with your username and password.
+1. Select **I've lost my authentication device** and **I've lost my recovery code**.
+1. Complete the [Contact Support form](https://hub.docker.com/support/contact/?category=2fa-lockout).
+
+You must enter the primary email address associated with your Docker ID in the Contact Support form for recovery instructions.
diff --git a/content/manuals/security/_index.md b/content/manuals/security/_index.md
index dca9ab57f16c..e8a3f9e8ad9c 100644
--- a/content/manuals/security/_index.md
+++ b/content/manuals/security/_index.md
@@ -1,123 +1,66 @@
 ---
-title: Security
-description: Learn about security features Docker has to offer and explore best practices
-keywords: docker, docker hub, docker desktop, security
+title: Security for developers
+linkTitle: Security
+description: Learn about developer-level security features like 2FA and access tokens
+keywords: docker, docker hub, docker desktop, security, developer security, 2FA, access tokens
 weight: 40
 params:
   sidebar:
     group: Platform
-grid_admins:
-- title: Settings Management
-  description: Learn how Settings Management can secure your developers' workflows.
-  icon: shield_locked
-  link: /security/for-admins/hardened-desktop/settings-management/
-- title: Enhanced Container Isolation
-  description: Understand how Enhanced Container Isolation can prevent container attacks.
-  icon: security
-  link: /security/for-admins/hardened-desktop/enhanced-container-isolation/
-- title: Registry Access Management
-  description: Control the registries developers can access while using Docker Desktop.
-  icon: home_storage
-  link: /security/for-admins/hardened-desktop/registry-access-management/
-- title: Image Access Management
-  description: Control the images developers can pull from Docker Hub.
-  icon: photo_library
-  link: /security/for-admins/hardened-desktop/image-access-management/
-- title: "Air-Gapped Containers"
-  description: Restrict containers from accessing unwanted network resources.
-  icon: "vpn_lock"
-  link: /security/for-admins/hardened-desktop/air-gapped-containers/
-- title: Enforce sign-in
-  description: Configure sign-in for members of your teams and organizations.
-  link: /security/for-admins/enforce-sign-in/
-  icon: passkey
-- title: Domain audit
-  description: Identify uncaptured users in your organization.
-  link: /security/for-admins/domain-audit/
-  icon: person_search
-- title: Docker Scout
-  description: Explore how Docker Scout can help you create a more secure software supply chain.
-  icon: query_stats
-  link: /scout/
-- title: SSO
-  description: Learn how to configure SSO for your company or organization.
-  icon: key
-  link: /security/for-admins/single-sign-on/
-- title: SCIM
-  description: Set up SCIM to automatically provision and deprovision users.
-  icon: checklist
-  link: /security/for-admins/provisioning/scim/
-- title: Roles and permissions
-  description: Assign roles to individuals giving them different permissions within an organization.
-  icon: badge
-  link: /security/for-admins/roles-and-permissions/
-- title: Private marketplace for Extensions (Beta)
-  description: Learn how to configure and set up a private marketplace with a curated list of extensions for your Docker Desktop users.
-  icon: storefront
-  link: /desktop/extensions/private-marketplace/
-- title: Organization access tokens
-  description: Create organization access tokens as an alternative to a password.
-  link: /security/for-admins/access-tokens/
-  icon: password
-- title: Enforce sign-in
-  description: Enforce your users to sign in to Docker Desktop.
-  link: /security/for-admins/enforce-sign-in/
-  icon: login
 grid_developers:
 - title: Set up two-factor authentication
   description: Add an extra layer of authentication to your Docker account.
-  link: /security/for-developers/2fa/
-  icon: phonelink_lock
+  link: /security/2fa/
+  icon: device-phone-mobile
 - title: Manage access tokens
   description: Create personal access tokens as an alternative to your password.
-  icon: password
-  link: /security/for-developers/access-tokens/
+  icon: lock-closed
+  link: /security/access-tokens/
 - title: Static vulnerability scanning
   description: Automatically run a point-in-time scan on your Docker images for vulnerabilities.
-  icon: image_search
+  icon: magnifying-glass
   link: /docker-hub/repos/manage/vulnerability-scanning/
 - title: Docker Engine security
   description: Understand how to keep Docker Engine secure.
-  icon: security
+  icon: shield-check
   link: /engine/security/
 - title: Secrets in Docker Compose
   description: Learn how to use secrets in Docker Compose.
-  icon: privacy_tip
+  icon: shield-exclamation
   link: /compose/how-tos/use-secrets/
 grid_resources:
 - title: Security FAQs
   description: Explore common security FAQs.
-  icon: help
+  icon: question-mark-circle
   link: /faq/security/general/
 - title: Security best practices
   description: Understand the steps you can take to improve the security of your container.
-  icon: category
+  icon: squares-2x2
   link: /develop/security-best-practices/
 - title: Suppress CVEs with VEX
   description: Learn how to suppress non-applicable or fixed vulnerabilities found in your images.
-  icon: query_stats
+  icon: chart-bar
   link: /scout/guides/vex/
+- title: Docker Hardened Images
+  description: Learn how to use Docker Hardened Images to enhance your software supply security.
+  icon: lock-closed
+  link: /dhi/
 ---
 
-Docker provides security guardrails for both administrators and developers.
+Docker helps you protect your local environments, infrastructure, and networks
+with its developer-level security features.
 
-If you're an administrator, you can enforce sign-in across Docker products for your developers, and
-scale, manage, and secure your instances of Docker Desktop with DevOps security controls like Enhanced Container Isolation and Registry Access Management.
+Use tools like two-factor authentication (2FA), personal access tokens, and
+Docker Scout to manage access and detect vulnerabilities early in your workflow.
+You can also integrate secrets securely into your development stack using Docker Compose,
+or enhance your software supply security with Docker Hardened Images.
 
-For both administrators and developers, Docker provides security-specific products such as Docker Scout, for securing your software supply chain with proactive image vulnerability monitoring and remediation strategies.
-
-## For administrators
-
-Explore the security features Docker offers to satisfy your company's security policies.
-
-{{< grid items="grid_admins" >}}
+Explore the following sections to learn more.
 
 ## For developers
 
-See how you can protect your local environments, infrastructure, and networks without impeding productivity.
-
 {{< grid items="grid_developers" >}}
 
-## Further resources
+## More resources
 
 {{< grid items="grid_resources" >}}
diff --git a/content/manuals/security/access-tokens.md b/content/manuals/security/access-tokens.md
new file mode 100644
index 000000000000..380b93383dd6
--- /dev/null
+++ b/content/manuals/security/access-tokens.md
@@ -0,0 +1,105 @@
+---
+title: Personal access tokens
+linkTitle: Personal access tokens
+description: Create and manage personal Docker access tokens for secure CLI authentication and automation
+keywords: personal access tokens, PAT, docker cli authentication, docker hub security, programmatic access
+weight: 10
+aliases:
+ - /docker-hub/access-tokens/
+ - /security/for-developers/access-tokens/
+---
+
+Personal access tokens (PATs) provide a secure alternative to passwords for Docker CLI authentication. Use PATs to authenticate automated systems, CI/CD pipelines, and development tools without exposing your Docker Hub password.
+
+## Key benefits
+
+PATs offer significant security advantages over password authentication:
+
+- Enhanced security: Investigate token usage, disable suspicious tokens, and prevent administrative actions that could compromise your account if your system is compromised.
+- Better automation: Issue multiple tokens for different integrations, each with specific permissions, and revoke them independently when no longer needed.
+- Two-factor authentication compatibility: Required when you have two-factor authentication turned on, providing secure CLI access without bypassing 2FA protection.
+- Usage tracking: Monitor when and how tokens are used to identify potential security issues or unused automation.
+
+## Who should use personal access tokens?
+
+Use PATs for these common scenarios:
+
+- Development workflows: Authenticate Docker CLI during local development
+- CI/CD pipelines: Automate image builds and deployments in continuous integration systems
+- Automation scripts: Push and pull images in automated deployment or backup scripts
+- Development tools: Integrate Docker Hub access with IDEs, container management tools, or monitoring systems
+- Two-factor authentication: Required for CLI access when 2FA is turned on
+
+> [!NOTE]
+>
+> For organization-wide automation, consider [organization access tokens](/manuals/enterprise/security/access-tokens.md) which aren't tied to individual user accounts.
+
+## Create a personal access token
+
+> [!IMPORTANT]
+>
+> Treat access tokens like passwords and keep them secure. Store tokens in credential managers and never commit them to source code repositories.
+
+To create a personal access token:
+
+1. Sign in to [Docker Home](https://app.docker.com/).
+1. Select your avatar in the top-right corner and from the drop-down menu select **Account settings**.
+1. Select **Personal access tokens**.
+1. Select **Generate new token**.
+1. Configure your token:
+   - **Description:** Use a descriptive name that indicates the token's purpose
+   - **Expiration date:** Set an expiration date based on your security policies
+   - **Access permissions:** **Read**, **Write**, or **Delete**.
+1. Select **Generate**. Copy the token that appears on the screen and save it. You won't be able to retrieve the token once you exit the screen.
+
+## Use personal access tokens
+
+Sign in to the Docker CLI using your personal access token:
+
+```console
+$ docker login --username <YOUR_USERNAME>
+Password: [paste your PAT here]
+```
+
+When prompted for a password, enter your personal access token instead of your Docker Hub password.
+
+## Modify personal access tokens
+
+> [!NOTE]
+>
+> You can't edit the expiration date on an existing personal access token. You must create a new PAT if you need to set a new expiration date.
+
+You can rename, activate, deactivate, or delete a token as needed. You can manage your tokens in your account settings.
+
+1. Sign in to [Docker Home](https://app.docker.com/login).
+1. Select your avatar in the top-right corner and from the drop-down menu select **Account settings**.
+1. Select **Personal access tokens**.
+      - This page shows an overview of all your tokens, and lists if the token was generated manually or if it was
+   [auto-generated](#auto-generated-tokens). You can also view the scope of the
+   tokens, which tokens are activate and inactive, when they were created, when
+   they were last used, and their expiration date.
+1. Select the actions menu on the far right of a token row, then select **Deactivate** or **Activate**, **Edit**, or **Delete** to modify the token.
+1. After editing the token, select **Save token**.
+
+## Auto-generated tokens
+
+Docker Desktop automatically creates authentication tokens when you sign in, with these characteristics:
+
+- Automatic creation: Generated when you sign in to Docker Desktop
+- Full permissions: Include Read, Write, and Delete access
+- Session-based: Automatically removed when Docker Desktop session expires
+- Account limits: Up to 5 auto-generated tokens per account
+- Automatic cleanup: Older tokens are deleted when new ones are created
+
+You can manually delete auto-generated tokens if needed, but they'll be recreated when you use Docker Desktop.
+
+## Fair use policy
+
+When using personal access tokens, be aware that excessive token creation may result in throttling or additional charges. Docker reserves the right to impose restrictions on accounts with excessive PAT usage to ensure fair resource allocation and maintain service quality.
+
+Best practices for fair use include:
+
+- Reuse tokens across similar use cases instead of creating many single-purpose tokens
+- Delete unused tokens regularly
+- Use [organization access tokens](/manuals/enterprise/security/access-tokens.md) for organization-wide automation
+- Monitor token usage to identify optimization opportunities
diff --git a/content/manuals/security/faqs/_index.md b/content/manuals/security/faqs/_index.md
index 3a881d91a410..4aebbca68bbb 100644
--- a/content/manuals/security/faqs/_index.md
+++ b/content/manuals/security/faqs/_index.md
@@ -2,5 +2,5 @@
 build:
   render: never
 title: FAQs
-weight: 30
+weight: 70
 ---
diff --git a/content/manuals/security/faqs/containers.md b/content/manuals/security/faqs/containers.md
index 340099d0e2fd..5c3496f338eb 100644
--- a/content/manuals/security/faqs/containers.md
+++ b/content/manuals/security/faqs/containers.md
@@ -1,53 +1,33 @@
 ---
-description: Find the answers to container security related FAQs
-keywords: Docker, Docker Hub, Docker Desktop security FAQs, platform, Docker Scout, admin, security
 title: Container security FAQs
 linkTitle: Container
+description: Frequently asked questions about Docker container security and isolation
+keywords: container security, docker desktop isolation, enhanced container isolation, file sharing
 weight: 20
 tags: [FAQ]
 aliases:
 - /faq/security/containers/
 ---
 
-### How are containers isolated from the host in Docker Desktop?
+## How are containers isolated from the host in Docker Desktop?
 
-Docker Desktop runs all containers inside a customized / minimal Linux virtual
-machine (except for native Windows containers). This adds a strong layer of
-isolation between containers and the host the machine, even if containers are
-running rootful.
+Docker Desktop runs all containers inside a customized Linux virtual machine (except for native Windows containers). This adds strong isolation between containers and the host machine, even when containers run as root.
 
-However note the following:
+Important considerations include:
 
-* Containers have access to host files configured for file sharing via Settings
-  -> Resources -> File Sharing (see the next FAQ question below for more info).
+- Containers have access to host files configured for file sharing via Docker Desktop settings
+- Containers run as root with limited capabilities inside the Docker Desktop VM by default
+- Privileged containers (`--privileged`, `--pid=host`, `--cap-add`) run with elevated privileges inside the VM, giving them access to VM internals and Docker Engine
 
-* By default, containers run as root but with limited capabilities inside the
-  Docker Desktop VM. Containers running with elevated privileges (e.g.,
-  `--privileged`, `--pid=host`, `--cap-add`, etc.) run as root with elevated
-  privileges inside the Docker Desktop VM which gives them access to Docker
-  Desktop VM internals, including the Docker Engine. Thus, users must be careful
-  which containers they run with such privileges to avoid security breaches by
-  malicious container images.
+With Enhanced Container Isolation turned on, each container runs in a dedicated Linux user namespace inside the Docker Desktop VM. Even privileged containers only have privileges within their container boundary, not the VM. ECI uses advanced techniques to prevent containers from breaching the Docker Desktop VM and Docker Engine.
 
-* If [Enhanced Container Isolation (ECI)](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md)
-  mode is enabled, then each container runs within a dedicated Linux User
-  Namespace inside the Docker Desktop VM, which means the container has no
-  privileges within the Docker Desktop VM. Even when using the `--privileged`
-  flag or similar, the container processes will only be privileged within the
-  container's logical boundary, but unprivileged otherwise. In addition, ECI protects
-  uses other advanced techniques to ensure they can't easily breach
-  the Docker Desktop VM and Docker Engine within (see the ECI section for more
-  info). No changes to the containers or user workflows are required as the
-  extra protection is added under the covers.
+## Which portions of the host filesystem can containers access?
 
-### To which portions of the host filesystem do containers have read and write access?
+Containers can only access host files that are:
 
-Containers can only access host files if these are shared via Settings -> Resources -> File Sharing,
-and only when such files are bind-mounted into the container (e.g., `docker run -v /path/to/host/file:/mnt ...`).
+1. Shared using Docker Desktop settings
+1. Explicitly bind-mounted into the container (e.g., `docker run -v /path/to/host/file:/mnt`)
 
-### Can containers running as root gain access to admin-owned files or directories on the host?
+## Can containers running as root access admin-owned files on the host?
 
-No; host file sharing (bind mount from the host filesystem) uses a user-space crafted
-file server (running in `com.docker.backend` as the user running Docker
-Desktop), so containers can’t gain any access that the user on the host doesn’t
-already have.
+No. Host file sharing uses a user-space file server (running in `com.docker.backend` as the Docker Desktop user), so containers can only access files that the Docker Desktop user already has permission to access.
diff --git a/content/manuals/security/faqs/general.md b/content/manuals/security/faqs/general.md
index 341c76c2a714..89ed07dfabde 100644
--- a/content/manuals/security/faqs/general.md
+++ b/content/manuals/security/faqs/general.md
@@ -1,87 +1,69 @@
 ---
-description: Find the answers to common security related FAQs
-keywords: Docker, Docker Hub, Docker Desktop security FAQs, platform, Docker Scout, admin, security
+description: Frequently asked questions about Docker security, authentication, and organization management
+keywords: Docker security, FAQs, authentication, SSO, vulnerability reporting, session management
 title: General security FAQs
-linkTitle: General 
+linkTitle: General
 weight: 10
 tags: [FAQ]
 aliases:
 - /faq/security/general/
 ---
 
-### How do I report a vulnerability?
+## How do I report a vulnerability?
 
-If you’ve discovered a security vulnerability in Docker, we encourage you to report it responsibly. Report security issues to security@docker.com so that they can be quickly addressed by our team.
+If you've discovered a security vulnerability in Docker, report it responsibly to security@docker.com so Docker can quickly address it.
 
-### How are passwords managed when SSO isn't used?
+## Does Docker lockout users after failed sign-ins?
 
-Passwords are encrypted and salt-hashed. If you use application-level passwords instead of SSO, you are responsible for ensuring that your employees know how to pick strong passwords, don't share passwords, and don't reuse passwords across multiple systems.
+Docker Hub locks out users after 10 failed sign-in attempts within 5 minutes. The lockout duration is 5 minutes. This policy applies to Docker Hub, Docker Desktop, and Docker Scout authentication.
 
-### Does Docker require password resets when SSO isn't used?
+## Do you support physical multi-factor authentication (MFA) with YubiKeys?
 
-Passwords aren't required to be periodically reset. NIST no longer recommends password resets as part of best practice.
+You can configure physical multi-factor authentication (MFA) through SSO using your identity provider (IdP). Check with your IdP if they support physical MFA devices like YubiKeys.
 
-### Does Docker lockout users after failed sign-ins?
+## How are sessions managed and do they expire?
 
-Docker Hub’s global setting for system lockout is after 10 failed sign in attempts in a period of 5 minutes, and the lockout duration is 5 minutes. The same global policy applies to authenticated Docker Desktop users and Docker Scout, both of which use Docker Hub for authentication.
+Docker uses tokens to manage user sessions with different expiration periods:
 
-### Do you support physical MFA with YubiKeys?
+- Docker Desktop: Signs you out after 90 days, or 30 days of inactivity
+- Docker Hub and Docker Home: Sign you out after 24 hours
 
-You can configure this through SSO using your IdP. Check with your IdP if they support physical MFA.
+Docker also supports your IdP's default session timeout through SAML attributes. For more information, see [SSO attributes](/manuals/enterprise/security/provisioning/_index.md#sso-attributes).
 
-### How are sessions managed and do they expire?
+## How does Docker distinguish between employee users and contractor users?
 
-By default, Docker uses tokens to manage sessions after a user signs in:
+Organizations use verified domains to distinguish user types. Team members with email domains other than verified domains appear as "Guest" users in the organization.
 
-- Docker Desktop signs you out after 90 days, or 30 days of inactivity.
-- Docker Hub and Docker Home sign you out after 24 hours.
+## How long are activity logs available?
 
-Docker also supports your IdP's default session timeout. You can configure this by setting a Docker session minutes SAML attribute. For more information, see [SSO attributes](/manuals/security/for-admins/provisioning/_index.md#sso-attributes).
+Docker activity logs are available for 90 days. You're responsible for exporting logs or setting up drivers to send logs to your internal systems for longer retention.
 
-### How does Docker attribute downloads to us and what data is used to classify or verify the user is part of our organization?
+## Can I export a list of users with their roles and privileges?
 
-Docker Desktop downloads are linked to a specific organization by the user's email containing the customer's domain. Additionally, we use IP addresses to correlate users with organizations.
+Yes, use the [Export Members](../../admin/organization/manage/members.md#export-members-csv-file) feature to export a CSV file containing your organization's users with role and team information.
 
-### How do you attribute that number of downloads to us from IP data if most of our engineers work from home and aren’t allowed to use VPNs?
+## How does Docker Desktop handle authentication information?
 
-We attribute users and their IP addresses to domains using 3rd party data enrichment software, where our provider analyzes activity from public and private data sources related to that specific IP address, then uses that activity to identify the domain and map it to the IP address.
+Docker Desktop uses the host operating system's secure key management to store authentication tokens:
 
-Some users authenticate by signing in to Docker Desktop and joining their domain's Docker organization, which allows us to map them with a much higher degree of accuracy and report on direct feature usage for you. We highly encourage you to get your users authenticated so we can provide you with the most accurate data.
+- macOS: [Keychain](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web)
+- Windows: [Security and Identity API via Wincred](https://learn.microsoft.com/en-us/windows/win32/api/wincred/)
+- Linux: [Pass](https://www.passwordstore.org/).
 
-### How does Docker distinguish between employee users and contractor users?
+## How do I remove users who aren't part of my IdP when using SSO without SCIM?
 
-Organizations set up in Docker use verified domains and any team member with an email domain other than what's verified is noted as a "Guest" in that organization.
+If SCIM isn't turned on, you must manually remove users from the organization. SCIM can automate user removal, but only for users added after SCIM is turned on. Users added before SCIM was turned on must be removed manually.
 
-### How long are activity logs available?
+For more information, see [Manage organization members](/manuals/admin/organization/manage/members.md).
 
-Docker provides various types of audit logs and log retention varies. For example, Docker activity logs are available for 90 days. You are responsible for exporting logs or setting up drivers to their own internal systems.
+## What metadata does Scout collect from container images?
 
-### Can I export a list of all users with their assigned roles and privileges and if so, in what format?
+For information about metadata stored by Docker Scout, see [Data handling](/manuals/scout/deep-dive/data-handling.md).
 
-Using the [Export Members](../../admin/organization/members.md#export-members) feature, you can export to CSV a list of your organization's users with role and team information.
+## How are Marketplace extensions vetted for security?
 
-### How does Docker Desktop handle and store authentication information?
+Security vetting for extensions isn't implemented. Extensions aren't covered as part of Docker's Third-Party Risk Management Program.
 
-Docker Desktop utilizes the host operating system's secure key management for handling and storing authentication tokens necessary for authenticating with image registries. On macOS, this is [Keychain](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web); on Windows, this is [Security and Identity API via Wincred](https://learn.microsoft.com/en-us/windows/win32/api/wincred/); and on Linux, this is [Pass](https://www.passwordstore.org/).
+## Can I prevent users from pushing images to Docker Hub private repositories?
 
-### How does Docker Hub secure passwords in storage and in transit?
-
-This is applicable only when using Docker Hub's application-level password versus SSO/SAML. For users created through SSO Just-in-Time or SCIM provisioning, Docker Hub doesn't store passwords. For all other users, application-level passwords are salt-hashed in storage (SHA-256) and encrypted in transit (TLS).
-
-### How do we de-provision users who are not part of our IdP? We use SSO but not SCIM
-
-If SCIM isn't enabled, you have to manually remove users from the organization in our system. Using SCIM automates this.
-
-### What metadata is collected from container images that Scout analyzes?
-
-For information about the metadata stored by Docker Scout, see [Data handling](/manuals/scout/deep-dive/data-handling.md).
-
-### How are extensions within the Marketplace vetted for security prior to placement?
-
-Security vetting for extensions is on our roadmap however this vetting isn't currently done.
-
-Extensions are not covered as part of Docker’s Third-Party Risk Management Program.
-
-### Can I disable private repos in my organization via a setting to make sure nobody is pushing images into Docker Hub?
-
-No. With [Registry Access Management](/manuals/security/for-admins/hardened-desktop/registry-access-management.md) (RAM), administrators can ensure that their developers using Docker Desktop only access allowed registries. This is done through the Registry Access Management dashboard in the Admin Console.
+No direct setting exists to disable private repositories. However, [Registry Access Management](/manuals/enterprise/security/hardened-desktop/registry-access-management.md) lets administrators control which registries developers can access through Docker Desktop via Docker Home.
diff --git a/content/manuals/security/faqs/networking-and-vms.md b/content/manuals/security/faqs/networking-and-vms.md
index 39df4646213b..668697d482a5 100644
--- a/content/manuals/security/faqs/networking-and-vms.md
+++ b/content/manuals/security/faqs/networking-and-vms.md
@@ -1,38 +1,30 @@
 ---
-description: Find the answers to FAQs related to networking and virtualization
-keywords: Docker, Docker Hub, Docker Desktop security FAQs, security, platform, networks, vms
 title: Network and VM FAQs
 linkTitle: Network and VM
+description: Frequently asked questions about Docker Desktop networking and virtualization security
+keywords: docker desktop networking, virtualization, hyper-v, wsl2, network security, firewall
 weight: 30
 tags: [FAQ]
 aliases:
 - /faq/security/networking-and-vms/
 ---
 
-### How can I limit the type of internet access allowed by the container when it runs, to prevent it from being able to exfiltrate data or download malicious code?
+## How can I limit container internet access?
 
-There is no built-in mechanism for that but it can be addressed by process-level firewall on the host. Hook into the `com.docker.vpnkit` user-space process and apply rules where it can connect to (DNS URL white list; packet/payload filter) and which ports/protocols it is allowed to use.
+Docker Desktop doesn't have a built-in mechanism for this, but you can use process-level firewalls on the host. Apply rules to the `com.docker.vpnkit` user-space process to control where it can connect (DNS allowlists, packet filters) and which ports/protocols it can use.
 
-### Can I prevent users binding ports on 0.0.0.0?
+For enterprise environments, consider [Air-gapped containers](/manuals/enterprise/security/hardened-desktop/air-gapped-containers.md) which provide network access controls for containers.
 
-There is no direct way to enforce that through Docker Desktop but it would inherit any firewall rules enforced on the host.
+## Can I apply firewall rules to container network traffic?
 
-### What options exist to lock containerized network settings to a system? If not supported, are there any consequences to manipulating the settings?
+Yes. Docker Desktop uses a user-space process (`com.docker.vpnkit`) for network connectivity, which inherits constraints like firewall rules, VPN settings, and HTTP proxy properties from the user that launched it.
 
-The Docker network settings are entirely local within the VM and have no effect on the system.
+## Does Docker Desktop for Windows with Hyper-V allow users to create other VMs?
 
-### Can I apply rules on container network traffic via a local firewall or VPN client?
+No. The `DockerDesktopVM` name is hard-coded in the service, so you cannot use Docker Desktop to create or manipulate other virtual machines.
 
-For network connectivity, Docker Desktop uses a user-space process (`com.docker.vpnkit`), which inherits constraints like firewall rules, VPN, HTTP proxy properties etc, from the user that launched it.
+## How does Docker Desktop achieve network isolation with Hyper-V and WSL 2?
 
-### Does running Docker Desktop for Windows with Hyper-V backend allow users to create arbitrary VMs?
+Docker Desktop uses the same VM processes for both WSL 2 (in the `docker-desktop` distribution) and Hyper-V (in `DockerDesktopVM`). Host/VM communication uses `AF_VSOCK` hypervisor sockets (shared memory) rather than network switches or interfaces. All host networking is performed using standard TCP/IP sockets from the `com.docker.vpnkit.exe` and `com.docker.backend.exe` processes.
 
-No. The `DockerDesktopVM` name is hard coded in the service code, so you cannot use Docker Desktop to create or manipulate any other VM.
-
-### Can I prevent our users creating other VMs when using Docker Desktop on Mac?
-
-On Mac it is an unprivileged operation to start a VM, so that is not enforced by Docker Desktop.
-
-### How does Docker Desktop achieve network level isolation when Hyper-V and/or WSL2 is used?
-
-The VM processes are the same for both WSL 2 (running inside the `docker-desktop` distribution) and Hyper-V (running inside the `DockerDesktopVM`). Host/VM communication uses `AF_VSOCK` hypervisor sockets (shared memory). It does not use Hyper-V network switches or network interfaces. All host networking is performed using normal TCP/IP sockets from the `com.docker.vpnkit.exe` and `com.docker.backend.exe` processes. For more information see [How Docker Desktop networking works under the hood](https://www.docker.com/blog/how-docker-desktop-networking-works-under-the-hood/).
+For more information, see [How Docker Desktop networking works under the hood](https://www.docker.com/blog/how-docker-desktop-networking-works-under-the-hood/).
diff --git a/content/manuals/security/faqs/single-sign-on/_index.md b/content/manuals/security/faqs/single-sign-on/_index.md
deleted file mode 100644
index d7fd803591bb..000000000000
--- a/content/manuals/security/faqs/single-sign-on/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-build:
-  render: never
-title: Single sign-on
----
diff --git a/content/manuals/security/faqs/single-sign-on/domain-faqs.md b/content/manuals/security/faqs/single-sign-on/domain-faqs.md
deleted file mode 100644
index 642e54006ada..000000000000
--- a/content/manuals/security/faqs/single-sign-on/domain-faqs.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-description: Single sign-on domain FAQs
-keywords: Docker, Docker Hub, SSO FAQs, single sign-on, domains, domain verification, domain management
-title: FAQs for SSO and domains
-linkTitle: Domains
-tags: [FAQ]
-aliases:
-- /single-sign-on/domain-faqs/
-- /faq/security/single-sign-on/domain-faqs/
----
-
-### Can I add sub-domains?
-
-Yes, you can add sub-domains to your SSO connection, however all email addresses should also be on that domain. Verify that your DNS provider supports multiple TXT records for the same domain.
-
-### Can the DNS provider configure it once for one-time verification and remove it later or will it be needed permanently?
-
-You can do it one time to add the domain to a connection. If your organization ever changes IdPs and has to set up SSO again, your DNS provider will need to verify again.
-
-### Is adding domain required to configure SSO? What domains should I be adding? And how do I add it?
-
-Adding and verifying a domain is required to enable and enforce SSO. See [Configure single sign-on](/manuals/security/for-admins/single-sign-on/configure.md) for more information. This should include all email domains users will use to access Docker. Public domains, for example `gmail.com` or `outlook.com`, are not permitted. Also, the email domain should be set as the primary email.
-
-### Is IdP-initiated authentication supported?
-
-IdP-initiated authentication isn't supported by Docker SSO. Users must initiate sign-in through Docker Desktop or Hub.
-
-### Can I verify the same domain on multiple organizations?
-
-You can't verify the same domain for multiple orgnaizations at the organization level. If you want to verify one domain for multiple organizations, you must have a Docker Business subscription, and [create a company](/manuals/admin/company/new-company.md). A company enables centralized management of organizations and allows domain verification at the company level.
diff --git a/content/manuals/security/faqs/single-sign-on/enforcement-faqs.md b/content/manuals/security/faqs/single-sign-on/enforcement-faqs.md
deleted file mode 100644
index f77b93ac6152..000000000000
--- a/content/manuals/security/faqs/single-sign-on/enforcement-faqs.md
+++ /dev/null
@@ -1,57 +0,0 @@
----
-description: Single sign-on enforcement FAQs
-keywords: Docker, Docker Hub, SSO FAQs, single sign-on, enforce SSO, SSO enforcement
-title: FAQs for SSO and enforcement
-linkTitle: Enforcement
-tags: [FAQ]
-aliases:
-- /single-sign-on/enforcement-faqs/
-- /faq/security/single-sign-on/enforcement-faqs/
----
-
-### I currently have a Docker Team subscription. How do I enable SSO?
-
-SSO is available with a Docker Business subscription. To enable SSO, you must first upgrade your subscription to a Docker Business subscription. To learn how to upgrade your existing account, see [Upgrade your subscription](../../../subscription/change.md).
-
-### Is DNS verification required to enable SSO?
-
-Yes. You must verify a domain before using it with an SSO connection.
-
-### Does Docker SSO support authenticating through the command line?
-
-When SSO is enforced, [passwords are prevented from accessing the Docker CLI](/security/security-announcements/#deprecation-of-password-logins-on-cli-when-sso-enforced). You can still access the Docker CLI using a personal access token (PAT) for authentication.
-
-Each user must create a PAT to access the CLI. To learn how to create a PAT, see [Manage access tokens](/security/for-developers/access-tokens/). Users who already used a PAT to sign in before SSO enforcement will still be able to use that PAT to authenticate.
-
-### How does SSO affect automation systems and CI/CD pipelines?
-
-Before enforcing SSO, you must [create PATs](/security/for-developers/access-tokens/). These PATs are used instead of passwords for signing into automation systems and CI/CD pipelines.
-
-### What can organization users who authenticated with personal emails prior to enforcement expect?
-
-Ensure your users have their organization email on their account, so that the accounts will be migrated to SSO for authentication.
-
-### Can I enable SSO and hold off on the enforcement option?
-
-Yes, you can choose to not enforce, and users have the option to use either Docker ID (standard email and password) or domain-verified email address (SSO) at the sign-in screen.
-
-### SSO is enforced, but a user can sign in using a username and password. Why is this happening?
-
-Guest users who are not part of your registered domain but have been invited to your organization do not sign in through your SSO Identity Provider. SSO enforcement only requires that users which do belong to your domain, must go through the SSO IdP.
-
-### Is there a way to test this functionality in a test tenant with Okta before going to production?
-
-Yes, you can create a test organization. Companies can set up a new 5 seat Business plan on a new organization to test with. To do this, make sure to only enable SSO, not enforce it, or all domain email users will be forced to sign in to that test tenant.
-
-### Is the sign in required tracking at runtime or install time?
-
-For Docker Desktop, if it's configured to require authentication to the organization, it tracks at runtime.
-
-### What is enforcing SSO versus enforcing sign-in?
-
-Enforcing SSO and enforcing sign-in to Docker Desktop are different features that you can use separately or together.
-
-Enforcing SSO ensures that users sign in using their SSO credentials instead of their Docker ID. One of the benefits is that SSO enables you to better manage user credentials.
-
-Enforcing sign-in to Docker Desktop ensures that users always sign in to an account that's a member of your organization. The benefits are that your organization's security settings are always applied to the user's session and your users always receive the benefits of your subscription. For more details, see [Enforce sign-in for Desktop](../../../security/for-admins/enforce-sign-in/_index.md#enforcing-sign-in-versus-enforcing-single-sign-on-sso).
-
diff --git a/content/manuals/security/faqs/single-sign-on/faqs.md b/content/manuals/security/faqs/single-sign-on/faqs.md
deleted file mode 100644
index 19432ae17260..000000000000
--- a/content/manuals/security/faqs/single-sign-on/faqs.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-description: Single sign-on FAQs
-keywords: Docker, Docker Hub, SSO FAQs, single sign-on, administration, security
-title: General FAQs on SSO
-linkTitle: General
-weight: 10
-tags: [FAQ]
-aliases:
-- /single-sign-on/faqs/
-- /faq/security/single-sign-on/faqs/
-- /single-sign-on/saml-faqs/
-- /faq/security/single-sign-on/saml-faqs/
-- /security/faqs/single-sign-on/saml-faqs/
----
-
-### Is Docker SSO available for all paid subscriptions?
-
-Docker single sign-on (SSO) is only available with the Docker Business subscription. [Upgrade your existing subscription](../../../subscription/change.md) to start using Docker SSO.
-
-### How does Docker SSO work?
-
-Docker SSO lets users authenticate using their identity providers (IdPs) to access Docker. Docker supports Entra ID (formerly Azure AD) and any SAML 2.0 identity providers. When you enable SSO, this redirects users to your provider’s authentication page to authenticate using their email and password.
-
-### What SSO flows does Docker support?
-
-Docker supports Service Provider Initiated (SP-initiated) SSO flow. This means users must sign in to Docker Hub or Docker Desktop to initiate the SSO authentication process.
-
-### Where can I find detailed instructions on how to configure Docker SSO?
-
-You first need to establish an SSO connection with your identity provider, and the company email domain needs to be verified prior to establishing an SSO connection for your users. For detailed step-by-step instructions on how to configure Docker SSO, see [Single Sign-on](../../../security/for-admins/single-sign-on/configure/_index.md).
-
-### Does Docker SSO support multi-factor authentication (MFA)?
-
-When an organization uses SSO, MFA is determined on the IdP level, not on the Docker platform.
-
-### Do I need a specific version of Docker Desktop for SSO?
-
-Yes, all users in your organization must upgrade to Docker Desktop version 4.4.2 or later. Users on older versions of Docker Desktop won't be able to sign in after SSO is enforced if the company domain email is used to sign in or as the primary email associated with an existing Docker account. Your users with existing accounts can't sign in with their username and password.
-
-### Can I retain my Docker ID when using SSO?
-
-For a personal Docker ID, a user is the account owner. A Docker ID is associated with access to the user's repositories, images, assets. A user can choose to have a company domain email on the Docker account. When enforcing SSO, the account is connected to the organization account. When enforcing SSO for an organization(s) or company, any user logging in without an existing account using verified company domain email will automatically have an account provisioned, and a new Docker ID created.
-
-### Does SAML authentication require additional attributes?
-
-You must provide an email address as an attribute to authenticate through SAML. The ‘Name’ attribute is optional.
-
-### Does the application recognize the NameID/Unique Identifier in the `SAMLResponse` subject?
-
-The preferred format is your email address, which should also be your Name ID.
-
-### Can I use group mapping with SSO and the Azure AD (OIDC) authentication method?
-
-No. Group mapping with SSO isn't supported with the Azure AD (OIDC)
-authentication method because it requires granting the OIDC app the
-Directory.Read.All permission, which provides access to all users, groups, and
-other sensitive data in the directory. Due to potential security risks, Docker
-doesn't support this configuration. Instead, Docker recommends [configuring SCIM
-to enable group sync
-securely](/security/for-admins/provisioning/group-mapping/#use-group-mapping-with-scim).
-
-### Are there any firewall rules required for SSO configuration?
-
-No. There are no specific firewall rules required for configuring SSO, as long as the domain `login.docker.com` is accessible. This domain is commonly accessible by default. However, in rare cases, some organizations may have firewall restrictions in place that block this domain. If you encounter issues during SSO setup, ensure that `login.docker.com` is allowed in your network's firewall settings.
-
-### Does Docker use my IdP's default session timeout?
-
-Yes, Docker supports your IdP's default session timeout using a custom SAML attribute.
-Instead of relying on the standard `SessionNotOnOrAfter` element from the SAML spec, Docker uses a custom `dockerSessionMinutes` attribute to control session duration. See [SSO attributes](/manuals/security/for-admins/provisioning/_index.md#sso-attributes) for more information.
\ No newline at end of file
diff --git a/content/manuals/security/faqs/single-sign-on/idp-faqs.md b/content/manuals/security/faqs/single-sign-on/idp-faqs.md
deleted file mode 100644
index 2b456e005540..000000000000
--- a/content/manuals/security/faqs/single-sign-on/idp-faqs.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-description: Single sign-on IdP FAQs
-keywords: Docker, Docker Hub, SSO FAQs, single sign-on, IdP
-title: FAQs for SSO and identity providers
-linkTitle: Identity providers
-tags: [FAQ]
-aliases:
-- /single-sign-on/idp-faqs/
-- /faq/security/single-sign-on/idp-faqs/
----
-
-### Is it possible to use more than one IdP with Docker SSO?
-
-No. You can only configure Docker SSO to work with a single IdP. A domain can only be associated with a single IdP. Docker supports Entra ID (formerly Azure AD) and identity providers that support SAML 2.0.
-
-### Is it possible to change my identity provider after configuring SSO?
-
-Yes. You must delete your existing IdP configuration in your Docker SSO connection and then [configure SSO using your new IdP](/manuals/security/for-admins/single-sign-on/connect.md). If you had already turned on enforcement, you should turn off enforcement before updating the provider SSO connection.
-
-### What information do I need from my identity provider to configure SSO?
-
-To enable SSO in Docker, you need the following from your IdP:
-
-* **SAML**: Entity ID, ACS URL, Single Logout URL and the public X.509 certificate
-
-* **Entra ID (formerly Azure AD)**: Client ID, Client Secret, AD Domain.
-
-### What happens if my existing certificate expires?
-
-If your existing certificate has expired, you may need to contact your identity provider to retrieve a new X.509 certificate. Then, you need to update the certificate in the [SSO configuration settings](/security/for-admins/single-sign-on/manage/#manage-sso-connections) in Docker Hub or Docker Admin Console.
-
-### What happens if my IdP goes down when SSO is enabled?
-
-If SSO is enforced, then it is not possible to access Docker Hub when your IdP is down. You can still access Docker Hub images from the CLI using your Personal Access Token.
-
-If SSO is enabled but not enforced, then users could fallback to authenticate with username/password and trigger a reset password flow (if necessary).
-
-### How do I handle accounts using Docker Hub as a secondary registry? Do I need a bot account?
-
-You can add a bot account to your IdP and create an access token for it to replace the other credentials.
-
-### Does a bot account need a seat to access an organization using SSO?
-
-Yes, bot accounts need a seat, similar to a regular end user, having a non-aliased domain email enabled in the IdP and using a seat in Hub.
-
-### Does SAML SSO use Just-in-Time provisioning?
-
-The SSO implementation uses Just-in-Time (JIT) provisioning by default. You can optionally disable JIT in the Admin Console if you enable auto-provisioning using SCIM. See [Just-in-Time provisioning](/security/for-admins/provisioning/just-in-time/).
-
-### Is IdP-initiated sign-in available?
-
-Docker SSO doesn't support IdP-initiated sign-in, only Service Provider Initiated (SP-initiated) sign-in.
-
-### Is it possible to connect Docker Hub directly with a Microsoft Entra (formerly Azure AD) group?
-
-Yes, Entra ID (formerly Azure AD) is supported with SSO for Docker Business, both through a direct integration and through SAML.
-
-### My SSO connection with Entra ID isn't working and I receive an error that the application is misconfigured. How can I troubleshoot this?
-
-Confirm that you've configured the necessary API permissions in Entra ID (formerly Azure AD) for your SSO connection. You need to grant admin consent within your Entra ID (formerly Azure AD) tenant. See [Entra ID (formerly Azure AD) documentation](https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent?pivots=portal#grant-admin-consent-in-app-registrations).
diff --git a/content/manuals/security/faqs/single-sign-on/users-faqs.md b/content/manuals/security/faqs/single-sign-on/users-faqs.md
deleted file mode 100644
index 8deb9adb440e..000000000000
--- a/content/manuals/security/faqs/single-sign-on/users-faqs.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-description: Single sign-on user management FAQs
-keywords: Docker, Docker Hub, SSO FAQs, single sign-on
-title: FAQs for SSO and user management
-linkTitle: User management
-tags: [FAQ]
-aliases:
-- /single-sign-on/users-faqs/
-- /faq/security/single-sign-on/users-faqs/
----
-
-### How do I manage users when using SSO?
-
-You can manage users through organizations in Docker Hub or Admin Console. When you configure SSO in Docker, you need to make sure an account exists for each user in your IdP account. When a user signs in to Docker for the first time using their domain email address, they will be automatically added to the organization after a successful authentication.
-
-### Do I need to manually add users to my organization?
-
-No, you don’t need to manually add users to your organization in Docker or Admin Console. You just need to make sure an account for your users exists in your IdP. When users sign in to Docker, they're automatically assigned to the organization using their domain email address.
-
-When a user signs in to Docker for the first time using their domain email address, they will be automatically added to the organization after a successful authentication.
-
-### Can users in my organization use different email addresses to authenticate through SSO?
-
-During the SSO setup, you’ll have to specify the company email domains that are allowed to authenticate. All users in your organization must authenticate using the email domain specified during SSO setup. Some of your users may want to maintain a different account for their personal projects.
-
-If SSO isn't enforced, users with an email address that doesn't match the verified email domain can sign in with username and password to join the organization as guests.
-
-### Can Docker organization and company owners approve users to join an organization and use a seat, rather than having them automatically added when SSO is enabled?
-
-Organization owners and company owners can approve users by configuring their permissions through their IdP. If the user account is configured in the IdP, the user will be automatically added to the organization in Docker Hub as long as there’s an available seat.
-
-### How will users be made aware that they're being made a part of a Docker organization?
-
-When SSO is enabled, users will be prompted to authenticate through SSO the next time they try to sign in to Docker Hub or Docker Desktop. The system will see the end-user has a domain email associated with the Docker ID they're trying to authenticate with, and prompts them to sign in with SSO email and credentials instead.
-
-If users attempt to sign in through the CLI, they must authenticate using a personal access token (PAT).
-
-### Is it possible to force users of Docker Desktop to authenticate, and/or authenticate using their company’s domain?
-
-Yes. Admins can [force users to authenticate with Docker Desktop](../../for-admins/enforce-sign-in/_index.md) using a registry key, `.plist` file, or `registry.json` file. 
-
-Once SSO enforcement is set up on their Docker Business organization or company on Hub, when the user is forced to authenticate with Docker Desktop, the SSO enforcement will also force users to authenticate through SSO with their IdP (instead of authenticating using their username and password).
-
-Users may still be able to authenticate as a guest account using an email address that doesn't match the verified domain. However, they can only authenticate as guests if that non-domain email was invited.
-
-### Is it possible to convert existing users from non-SSO to SSO accounts?
-
-Yes, you can convert existing users to an SSO account. To convert users from a non-SSO account:
-
-- Ensure your users have a company domain email address and they have an account in your IdP.
-- Verify that all users have Docker Desktop version 4.4.2 or later installed on their machines.
-- Each user has created a PAT to replace their passwords to allow them to sign in through Docker CLI.
-- Confirm that all CI/CD pipelines automation systems have replaced their passwords with PATs.
-
-For detailed prerequisites and instructions on how to enable SSO, see [Configure Single Sign-on](../../../security/for-admins/single-sign-on/configure/_index.md).
-
-### What impact can users expect once we start onboarding them to SSO accounts?
-
-When SSO is enabled and enforced, your users just have to sign in using the verified domain email address.
-
-### Is Docker SSO fully synced with the IdP?
-
-Docker SSO provides Just-in-Time (JIT) provisioning by default, with an option to disable JIT. Users are provisioned when a user authenticates with SSO. If a user leaves the organization, administrators must sign in to Docker and manually [remove the user](../../../admin/organization/members.md#remove-a-member-or-invitee) from the organization.
-
-[SCIM](../../../security/for-admins/provisioning/scim/) is available to provide full synchronization with users and groups. When you auto-provision users with SCIM, the recommended configuration is to disable JIT so that all auto-provisioning is handled by SCIM.
-
-Additionally, you can use the [Docker Hub API](/reference/api/hub/latest/) to complete this process.
-
-### How does disabling Just-in-Time provisioning impact user sign-in?
-
-The option to disable JIT is available when you use the Admin Console and enable SCIM. If a user attempts to sign in to Docker using an email address that is a verified domain for your SSO connection, they need to be a member of the organization to access it, or have a pending invitation to the organization. Users who don't meet these criteria will encounter an `Access denied` error, and will need an administrator to invite them to the organization.
-
-See [SSO authentication with JIT provisioning disabled](/security/for-admins/provisioning/just-in-time/#sso-authentication-with-jit-provisioning-disabled).
-
-To auto-provision users without JIT provisioning, you can use [SCIM](/security/for-admins/provisioning/scim/).
-
-### What's the best way to provision the Docker subscription without SSO?
-
-Company or organization owners can invite users through Docker Hub or Admin Console, by email address (for any user) or by Docker ID (assuming the user has an existing Docker account).
-
-### Can someone join an organization without an invitation? Is it possible to add specific users to an organization with existing email accounts?
-
-Not without SSO. Joining requires an invite from an organization owner. When SSO is enforced, then the domains verified through SSO will let users automatically join the organization the next time they sign in as a user that has a domain email assigned.
-
-### When we send an invitation to the user, will the existing account be consolidated and retained?
-
-Yes, the existing user account will join the organization with all assets retained.
-
-### How can I view, update, and remove multiple email addresses for my users?
-
-We only support one email per user on the Docker platform.
-
-### How can I remove invitees to the organization who haven't signed in?
-
-You can go to the **Members** page for your organization in Docker Hub or Admin Console, view pending invites, and remove invitees as needed.
-
-### Is the flow for service account authentication different from a UI user account?
-
-No, we don't differentiate the two in product.
-
-### Is user information visible in Docker Hub?
-
-All Docker accounts have a public profile associated with their namespace. If you don't want user information (for example, full name) to be visible, you can remove those attributes from your SSO and SCIM mappings. Alternatively, you can use a different identifier to replace a user's full name.
-
-### What happens to existing licensed users when SCIM is enabled?
-
-Enabling SCIM does not immediately remove or modify existing licensed users in your Docker organization. They retain their current access and roles, but after enabling SCIM, you will manage them in your identity provider (IdP). If SCIM is later disabled, previously SCIM-managed users remain in Docker but are no longer automatically updated or removed based on your IdP.
\ No newline at end of file
diff --git a/content/manuals/security/for-admins/_index.md b/content/manuals/security/for-admins/_index.md
deleted file mode 100644
index 7e60da1fad8d..000000000000
--- a/content/manuals/security/for-admins/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-build:
-  render: never
-title: For admins
-weight: 10
----
diff --git a/content/manuals/security/for-admins/access-tokens.md b/content/manuals/security/for-admins/access-tokens.md
deleted file mode 100644
index b5f028f66d0a..000000000000
--- a/content/manuals/security/for-admins/access-tokens.md
+++ /dev/null
@@ -1,133 +0,0 @@
----
-title: Organization access tokens
-description: Learn how to create and manage organization access tokens
-  to securely push and pull images programmatically.
-keywords: docker hub, security, OAT, organization access token
-linkTitle: Organization access tokens
----
-
-{{< summary-bar feature_name="OATs" >}}
-
-> [!WARNING]
->
-> Organization access tokens (OATs) are not intended to be used with Docker
-> Desktop or Docker Scout, and are incompatible.
->
-> If you use Docker Desktop or Docker Scout, you must use personal
-> access tokens instead.
-
-An organization access token (OAT) is like a [personal access token
-(PAT)](/security/for-developers/access-tokens/), but an OAT is associated with
-an organization and not a single user account. Use an OAT instead of a PAT to
-let business-critical tasks access Docker Hub repositories without connecting
-the token to single user. You must have a [Docker Team or Business
-subscription](/subscription/core-subscription/details/) to use OATs.
-
-OATs provide the following advantages:
-
-- You can investigate when the OAT was last used and then disable or delete it
-  if you find any suspicious activity.
-- You can limit what each OAT has access to, which limits the impact if an OAT
-  is compromised.
-- All company or organization owners can manage OATs. If one owner leaves the
-  organization, the remaining owners can still manage the OATs.
-- OATs have their own Docker Hub usage limits that don't count towards your
-  personal account's limits.
-
-If you have existing [service accounts](/docker-hub/service-accounts/),
-Docker recommends that you replace the service accounts with OATs. OATs offer
-the following advantages over service accounts:
-
-- Access permissions are easier to manage with OATs. You can assign access
-  permissions to OATs, while service accounts require using teams for access
-  permissions.
-- OATs are easier to manage. OATs are centrally managed in the Admin Console.
-  For service accounts, you may need to sign in to that service account to
-  manage it. If using single sign-on enforcement and the service account is not
-  in your IdP, you may not be able to sign in to the service account to manage
-  it.
-- OATs are not associated with a single user. If a user with access to the
-  service account leaves your organization, you may lose access to the service
-  account. OATs can be managed by any company or organization owner.
-
-## Create an organization access token
-
-> [!IMPORTANT]
->
-> Treat access tokens like a password and keep them secret. Store your tokens
-> securely in a credential manager for example.
-
-Company or organization owners can create up to:
-- 10 OATs for organizations with a Team subscription
-- 100 OATs for organizations with a Business subscription
-
-Expired tokens count towards the total amount of tokens.
-
-To create an OAT:
-
-1. Sign in to the [Admin Console](https://app.docker.com/admin).
-
-2. Select the organization you want to create an access token for.
-
-3. Under **Security and access**, select **Access tokens**.
-
-4. Select **Generate access token**.
-
-5. Add a label and optional description for your token. Use something that
-indicates the use case or purpose of the token.
-
-6. Select the expiration date for the token.
-
-7. Expand the **Repository** drop-down to set access permission
-scopes for your token. To set Repository access scopes:
-    1. Optional. Select **Read public repositories**.
-    2. Select **Add repository** and choose a repository from the drop-down.
-    3. Set the scopes for your repository &mdash; **Image Push** or
-    **Image Pull**.
-    4. Add more repositories as needed. You can add up to 50 repositories.
-
-8. Optional. Expand the **Organization** drop-down and select the
-**Allow management access to this organization's resources** checkbox. This
-setting enables organization management scopes for your token. The following
-organization management scopes are available:
-    - **Member Edit**: Edit members of the organization
-    - **Member Read**: Read members of the organization
-    - **Invite Edit**: Invite members to the organization
-    - **Invite Read**: Read invites to the organization
-    - **Group Edit**: Edit groups of the organization
-    - **Group Read**: Read groups of the organization
-
-9. Select **Generate token**. Copy the token that appears on the screen
-   and save it. You won't be able to retrieve the token once you exit the
-   screen.
-
-## Use an organization access token
-
-You can use an organization access token when you sign in using Docker CLI.
-
-Sign in from your Docker CLI client with the following command, replacing
-`YOUR_ORG` with your organization name:
-
-```console
-$ docker login --username <YOUR_ORG>
-```
-
-When prompted for a password, enter your organization access token instead of a
-password.
-
-## Modify existing tokens
-
-You can rename, update the description, update the repository access,
-deactivate, or delete a token as needed.
-
-1. Sign in to the [Admin Console](https://app.docker.com/admin).
-
-2. Select the organization you want to modify an access token for.
-
-3. Under **Security and access**, select **Access tokens**.
-
-4. Select the actions menu in the token row, then select
-   **Deactivate**, **Edit**, or **Delete** to modify the token. For **Inactive**
-   tokens, you can only select **Delete**.
-
-5. If editing a token, select **Save** after specifying your modifications.
diff --git a/content/manuals/security/for-admins/domain-audit.md b/content/manuals/security/for-admins/domain-audit.md
deleted file mode 100644
index ac9f13b920d5..000000000000
--- a/content/manuals/security/for-admins/domain-audit.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-description: Learn how to audit your domains for uncaptured users.
-keywords: domain audit, security, identify users, manage users
-title: Domain audit
-aliases:
-- /docker-hub/domain-audit/
-- /admin/company/settings/domains/
-- /admin/organization/security-settings/domains/
-weight: 50
----
-
-{{< summary-bar feature_name="Domain audit" >}}
-
-Domain audit identifies uncaptured users in an organization. Uncaptured users are Docker users who have authenticated to Docker using an email address associated with one of your verified domains, but they're not a member of your organization in Docker. You can audit domains on organizations that are part of the Docker Business subscription. To upgrade your existing account to a Docker Business subscription, see [Upgrade your subscription](/subscription/upgrade/).
-
-Uncaptured users who access Docker Desktop in your environment may pose a security risk because your organization's security settings, like Image Access Management and Registry Access Management, aren't applied to a user's session. In addition, you won't have visibility into the activity of uncaptured users. You can add uncaptured users to your organization to gain visibility into their activity and apply your organization's security settings.
-
-Domain audit can't identify the following Docker users in your environment:
-
-- Users who access Docker Desktop without authenticating
-- Users who authenticate using an account that doesn't have an email address associated with one of your verified domains
-
-Although domain audit can't identify all Docker users in your environment, you can enforce sign-in to prevent unidentifiable users from accessing Docker Desktop in your environment. For more details about enforcing sign-in, see [Configure registry.json to enforce sign-in](../for-admins/enforce-sign-in/_index.md).
-
-> [!TIP]
->
-> You can use endpoint management (MDM) software to identify the number of Docker Desktop instances and their versions within your environment. This can provide accurate license reporting, help ensure your machines use the latest version of Docker Desktop, and enable you to [enforce sign-in](enforce-sign-in/_index.md).
-> - [Intune](https://learn.microsoft.com/en-us/mem/intune/apps/app-discovered-apps)
-> - [Jamf](https://docs.jamf.com/10.25.0/jamf-pro/administrator-guide/Application_Usage.html)
-> - [Kandji](https://support.kandji.io/support/solutions/articles/72000559793-view-a-device-application-list)
-> - [Kolide](https://www.kolide.com/features/device-inventory/properties/mac-apps)
-> - [Workspace One](https://blogs.vmware.com/euc/2022/11/how-to-use-workspace-one-intelligence-to-manage-app-licenses-and-reduce-costs.html)
-
-## Prerequisites
-
-Before you audit your domains, review the following required prerequisites:
-
-- Your organization must be part of a Docker Business subscription. To upgrade your existing account to a Docker Business subscription, see [Upgrade your subscription](../../subscription/change.md).
-- You must [add and verify your domains](./single-sign-on/configure/_index.md#step-one-add-and-verify-your-domain).
-
-> [!IMPORTANT]
->
-> Domain audit is not supported for companies or organizations within a company.
-
-## Audit your domains for uncaptured users
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-{{% admin-domain-audit product="admin" %}}
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-{{% admin-domain-audit product="hub" %}}
-
-{{< /tab >}}
-{{< /tabs >}}
-
diff --git a/content/manuals/security/for-admins/enforce-sign-in/_index.md b/content/manuals/security/for-admins/enforce-sign-in/_index.md
deleted file mode 100644
index 5ee35def4989..000000000000
--- a/content/manuals/security/for-admins/enforce-sign-in/_index.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-description: Understand what happens when you force users to sign in to Docker Desktop
-toc_max: 2
-keywords: authentication, registry.json, configure, enforce sign-in, docker desktop, security, .plist, registry key, mac, windows
-title: Enforce sign-in for Docker Desktop
-linkTitle: Enforce sign-in
-tags: [admin]
-aliases:
- - /security/for-admins/configure-sign-in/
- - /docker-hub/configure-sign-in/
-weight: 30
----
-
-{{< summary-bar feature_name="Enforce sign-in" >}}
-
-By default, members of your organization can use Docker Desktop without signing
-in. When users don’t sign in as a member of your organization, they don’t
-receive the [benefits of your organization’s
-subscription](../../../subscription/details.md) and they can circumvent [Docker’s
-security features](/manuals/security/for-admins/hardened-desktop/_index.md) for your organization.
-
-There are multiple methods for enforcing sign-in, depending on your companies' set up and preferences:
-- [Registry key method (Windows only)](methods.md#registry-key-method-windows-only){{< badge color=green text="New" >}}
-- [Configuration profiles method (Mac only)](methods.md#configuration-profiles-method-mac-only){{< badge color=green text="New" >}}
-- [`.plist` method (Mac only)](methods.md#plist-method-mac-only){{< badge color=green text="New" >}}
-- [`registry.json` method (All)](methods.md#registryjson-method-all)
-
-## How is sign-in enforced?
-
-When Docker Desktop starts and it detects a registry key, `.plist` file, or `registry.json` file, the following occurs:
-
-- A **Sign in required!** prompt appears requiring the user to sign
-  in as a member of your organization to use Docker Desktop. ![Enforce Sign-in
-  Prompt](../../images/enforce-sign-in.png?w=400)
-- When a user signs in to an account that isn’t a member of your organization,
-  they are automatically signed out and can’t use Docker Desktop. The user
-  can select **Sign in** and try again.
-- When a user signs in to an account that is a member of your organization, they
- can use Docker Desktop.
-- When a user signs out, the **Sign in required!** prompt appears and they can
-  no longer use Docker Desktop.
-
-> [!NOTE]
->
-> Enforcing sign-in for Docker Desktop does not impact accessing the Docker CLI. CLI access is only impacted for organizations that enforce single sign-on.
-
-## Enforcing sign-in versus enforcing single sign-on (SSO)
-
-[Enforcing SSO](/manuals/security/for-admins/single-sign-on/connect.md#optional-enforce-sso) and enforcing sign-in are different features. The following table provides a
-description and benefits when using each feature.
-
-| Enforcement                       | Description                                                     | Benefits                                                                                                                                                                                                                                                   |
-|:----------------------------------|:----------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Enforce sign-in only              | Users must sign in before using Docker Desktop.                 | Ensures users receive the benefits of your subscription and ensures security features are applied. In addition, you gain insights into users’ activity.                                                                                                    |
-| Enforce single sign-on (SSO) only | If users sign in, they must sign in using SSO.                  | Centralizes authentication and enforces unified policies set by the identity provider.                                                                                                                                                                     |
-| Enforce both                      | Users must sign in using SSO before using Docker Desktop.       | Ensures users receive the benefits of your subscription and ensures security features are applied. In addition, you gain insights into users’ activity. Finally, it centralizes authentication and enforces unified policies set by the identity provider. |
-| Enforce neither                   | If users sign in, they can use SSO or their Docker credentials. | Lets users access Docker Desktop without barriers, but at the cost of reduced security and insights.                                                                                                                                                  |
-
-## What's next?
-
-- To enforce sign-in, review the [Methods](/manuals/security/for-admins/enforce-sign-in/methods.md) guide.
-- To enforce SSO, review the [Enforce SSO](/manuals/security/for-admins/single-sign-on/connect.md) steps.
\ No newline at end of file
diff --git a/content/manuals/security/for-admins/enforce-sign-in/methods.md b/content/manuals/security/for-admins/enforce-sign-in/methods.md
deleted file mode 100644
index 2f590b64c442..000000000000
--- a/content/manuals/security/for-admins/enforce-sign-in/methods.md
+++ /dev/null
@@ -1,396 +0,0 @@
----
-description: Learn about the different ways you can force your developers to sign in to Docker Desktop
-keywords: authentication, registry.json, configure, enforce sign-in, docker desktop, security, .plist. registry key, mac, windows
-title: Ways to enforce sign-in for Docker Desktop
-tags: [admin]
-linkTitle: Methods
----
-
-{{< summary-bar feature_name="Enforce sign-in" >}}
-
-This page outlines the different methods for enforcing sign-in for Docker Desktop.
-
-## Registry key method (Windows only)
-
-> [!NOTE]
->
-> The registry key method is available with Docker Desktop version 4.32 and later.
-
-To enforce sign-in for Docker Desktop on Windows, you can configure a registry key that specifies your organization's allowed users. The following steps guide you through creating and deploying the registry key to enforce this policy:
-
-1. Create the registry key. Your new key should look like the following:
-
-   ```console
-   $ HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Docker\Docker Desktop
-   ```
-2. Create a multi-string value `allowedOrgs`.
-   > [!IMPORTANT]
-   >
-   > As of Docker Desktop version 4.36 and later, you can add more than one organization. With Docker Desktop version 4.35 and earlier, if you add more than one organization sign-in enforcement silently fails.
-3. Use your organization's name, all lowercase as string data. If you're adding more than one organization, make sure there is an empty space between each organization name.
-4. Restart Docker Desktop.
-5. When Docker Desktop restarts, verify that the **Sign in required!** prompt appears.
-
-In some cases, a system reboot may be necessary for enforcement to take effect.
-
-> [!NOTE]
->
-> If a registry key and a `registry.json` file both exist, the registry key takes precedence.
-
-### Example deployment via Group Policy
-
-The following example outlines how to deploy a registry key to enforce sign-in on Docker Desktop using Group Policy. There are multiple ways to deploy this configuration depending on your organization's infrastructure, security policies, and management tools.
-
-1. Create the registry script. Write a script to create the `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Docker\Docker Desktop` key, add the `allowedOrgs` multi-string, and then set the value to your organization’s name.
-2. Within Group Policy, create or edit a Group Policy Objective (GPO) that applies to the machines or users you want to target.
-3. Within the GPO, navigate to **Computer Configuration** and select **Preferences**.
-4. Select **Windows Settings** then **Registry**.
-5. To add the registry item, right-click on the **Registry** node, select **New**, and then **Registry Item**.
-6. Configure the new registry item to match the registry script you created, specifying the action as **Update**. Make sure you input the correct path, value name (`allowedOrgs`), and value data (your organization names).
-7. Link the GPO to an Organizational Unit (OU) that contains the machines you want to apply this setting to.
-8. Test the GPO on a small set of machines first to ensure it behaves as expected. You can use the `gpupdate /force` command on a test machine to manually refresh its group policy settings and check the registry to confirm the changes.
-9. Once verified, you can proceed with broader deployment. Monitor the deployment to ensure the settings are applied correctly across the organization's computers.
-
-## Configuration profiles method (Mac only)
-
-{{< summary-bar feature_name="Config profiles" >}}
-
-Configuration profiles are a feature of macOS that let you distribute
-configuration information to the Macs you manage. It is the safest method to
-enforce sign-in on macOS because the installed configuration profiles are
-protected by Apples' System Integrity Protection (SIP) and therefore can't be
-tampered with by the users.
-
-1. Save the following XML file with the extension `.mobileconfig`, for example
-   `docker.mobileconfig`:
-
-   ```xml
-    <?xml version="1.0" encoding="UTF-8"?>
-    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
-    <plist version="1.0">
-      <dict>
-        <key>PayloadContent</key>
-        <array>
-          <dict>
-            <key>PayloadType</key>
-            <string>com.docker.config</string>
-            <key>PayloadVersion</key>
-            <integer>1</integer>
-            <key>PayloadIdentifier</key>
-            <string>com.docker.config</string>
-            <key>PayloadUUID</key>
-            <string>eed295b0-a650-40b0-9dda-90efb12be3c7</string>
-            <key>PayloadDisplayName</key>
-            <string>Docker Desktop Configuration</string>
-            <key>PayloadDescription</key>
-            <string>Configuration profile to manage Docker Desktop settings.</string>
-            <key>PayloadOrganization</key>
-            <string>Your Company Name</string>
-            <key>allowedOrgs</key>
-            <string>first_org;second_org</string>
-          </dict>
-        </array>
-        <key>PayloadType</key>
-        <string>Configuration</string>
-        <key>PayloadVersion</key>
-        <integer>1</integer>
-        <key>PayloadIdentifier</key>
-        <string>com.yourcompany.docker.config</string>
-        <key>PayloadUUID</key>
-        <string>0deedb64-7dc9-46e5-b6bf-69d64a9561ce</string>
-        <key>PayloadDisplayName</key>
-        <string>Docker Desktop Config Profile</string>
-        <key>PayloadDescription</key>
-        <string>Config profile to enforce Docker Desktop settings for allowed organizations.</string>
-        <key>PayloadOrganization</key>
-        <string>Your Company Name</string>
-      </dict>
-    </plist>
-   ```
-
-2. Change the placeholders `com.yourcompany.docker.config` and `Your Company Name` to the name of your company.
-
-3. Add your organization name. The names of the allowed organizations are stored in the `allowedOrgs`
-   property. It can contain either the name of a single organization or a list of organization names,
-   separated by a semicolon:
-
-   ```xml
-            <key>allowedOrgs</key>
-            <string>first_org;second_org</string>
-   ```
-
-4. Use a MDM solution to distribute your modified `.mobileconfig` file to your macOS clients. 
-
-5. Verify that the profile is added to **Device (Managed)** profiles list (**System Settings** > **General** > **Device Management**) on your macOS clients.
-
-## plist method (Mac only)
-
-> [!NOTE]
->
-> The `plist` method is available with Docker Desktop version 4.32 and later.
-
-To enforce sign-in for Docker Desktop on macOS, you can use a `plist` file that defines the required settings. The following steps guide you through the process of creating and deploying the necessary `plist` file to enforce this policy:
-
-1. Create the file `/Library/Application Support/com.docker.docker/desktop.plist`.
-2. Open `desktop.plist` in a text editor and add the following content, where `myorg` is replaced with your organization’s name all lowercase:
-
-   ```xml
-   <?xml version="1.0" encoding="UTF-8"?>
-   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
-   <plist version="1.0">
-     <dict>
-	     <key>allowedOrgs</key>
-	     <array>
-             <string>myorg1</string>
-             <string>myorg2</string>
-         </array>
-     </dict>
-   </plist>
-   ```
-   > [!IMPORTANT]
-   >
-   > As of Docker Desktop version 4.36 and later, you can add more than one organization. With Docker Desktop version 4.35 and earlier, sign-in enforcement silently fails if you add more than one organization.
-
-3. Modify the file permissions to ensure the file cannot be edited by any non-administrator users.
-4. Restart Docker Desktop.
-5. When Docker Desktop restarts, verify that the **Sign in required!** prompt appears.
-
-> [!NOTE]
->
-> If a `plist` and `registry.json` file both exist, the `plist` file takes precedence.
-
-### Example deployment
-
-The following example outlines how to create and distribute the `plist` file to enforce sign-in on Docker Desktop. There are multiple ways to deploy this configuration depending on your organization's infrastructure, security policies, and management tools.
-
-{{< tabs >}}
-{{< tab name="MDM" >}}
-
-1. Follow the steps previously outlined to create the `desktop.plist` file.
-2. Use an MDM tool like Jamf or Fleet to distribute the `desktop.plist` file to `/Library/Application Support/com.docker.docker/` on target macOS devices.
-3. Through the MDM tool, set the file permissions to permit editing by administrators only.
-
-{{< /tab >}}
-{{< tab name="Shell script" >}}
-
-1. Create a Bash script that can check for the existence of the `.plist` file in the correct directory, create or modify it as needed, and set the appropriate permissions.
-   Include commands in your script to:
-    - Navigate to the `/Library/Application Support/com.docker.docker/` directory or create it if it doesn't exist.
-    - Use the `defaults` command to write the required keys and values to the `desktop.plist` file. For example:
-       ```console
-       $ defaults write /Library/Application\ Support/com.docker.docker/desktop.plist allowedOrgs -string "myorg"
-       ```
-    - Change permissions of the `plist` file to restrict editing, using `chmod` and possibly `chown` to set the owner to root or another administrator account, ensuring it can't be easily modified by unauthorized users.
-2. Before deploying the script across the organization, test it on a local macOS machine to ensure it behaves as expected. Pay attention to directory paths, permissions, and the successful application of `plist` settings.
-3. Ensure that you have the capability to execute scripts remotely on macOS devices. This might involve setting up SSH access or using a remote support tool that supports macOS.
-4.  Use a method of remote script execution that fits your organization's infrastructure. Options include:
-    - SSH: If SSH is enabled on the target machines, you can use it to execute the script remotely. This method requires knowledge of the device's IP address and appropriate credentials.
-    - Remote support tool: For organizations using a remote support tool, you can add the script to a task and execute it across all selected machines.
-5. Ensure the script is running as expected on all targeted devices. You may have to check log files or implement logging within the script itself to report its success or failure.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## registry.json method (All)
-
-The following instructions explain how to create and deploy a `registry.json` file to a single device. There are many ways to deploy the `registry.json` file. You can follow the example deployments outlined in the `.plist` file section. The method you choose is dependent on your organization's infrastructure, security policies, and the administrative rights of the end-users.
-
-### Option 1: Create a registry.json file to enforce sign-in
-
-1. Ensure the user is a member of your organization in Docker. For more
-details, see [Manage members](/admin/organization/members/).
-2. Create the `registry.json` file.
-
-    Based on the user's operating system, create a file named `registry.json` at the following location and make sure the file can't be edited by the user.
-
-    | Platform | Location |
-    | --- | --- |
-    | Windows | `/ProgramData/DockerDesktop/registry.json` |
-    | Mac | `/Library/Application Support/com.docker.docker/registry.json` |
-    | Linux | `/usr/share/docker-desktop/registry/registry.json` |
-
-3. Specify your organization in the `registry.json` file.
-
-    Open the `registry.json` file in a text editor and add the following contents, where `myorg` is replaced with your organization’s name. The file contents are case-sensitive and you must use lowercase letters for your organization's name.
-
-
-    ```json
-    {
-    "allowedOrgs": ["myorg1", "myorg2"]
-    }
-    ```
-   > [!IMPORTANT]
-   >
-   > As of Docker Desktop version 4.36 and later, you can add more than one organization. With Docker Desktop version 4.35 and earlier, if you add more than one organization sign-in enforcement silently fails.
-
-4. Verify that sign-in is enforced.
-
-    To activate the `registry.json` file, restart Docker Desktop on the user’s machine. When Docker Desktop starts, verify that the **Sign in
-    required!** prompt appears.
-
-    In some cases, a system reboot may be necessary for the enforcement to take effect.
-
-    > [!TIP]
-    >
-    > If your users have issues starting Docker Desktop after you enforce sign-in, they may need to update to the latest version.
-
-### Option 2: Create a registry.json file when installing Docker Desktop
-
-To create a `registry.json` file when installing Docker Desktop, use the following instructions based on your user's operating system.
-
-{{< tabs >}}
-{{< tab name="Windows" >}}
-
-To automatically create a `registry.json` file when installing Docker Desktop,
-download `Docker Desktop Installer.exe` and run one of the following commands
-from the directory containing `Docker Desktop Installer.exe`. Replace `myorg`
-with your organization's name. You must use lowercase letters for your
-organization's name.
-
-If you're using PowerShell:
-
-```powershell
-PS> Start-Process '.\Docker Desktop Installer.exe' -Wait 'install --allowed-org=myorg'
-```
-
-If you're using the Windows Command Prompt:
-
-```console
-C:\Users\Admin> "Docker Desktop Installer.exe" install --allowed-org=myorg
-```
-> [!IMPORTANT]
->
-> As of Docker Desktop version 4.36 and later, you can add more than one organization to a single `registry.json` file. With Docker Desktop version 4.35 and earlier, if you add more than one organization sign-in enforcement silently fails.
-
-{{< /tab >}}
-{{< tab name="Mac" >}}
-
-To automatically create a `registry.json` file when installing Docker Desktop,
-download `Docker.dmg` and run the following commands in a terminal from the
-directory containing `Docker.dmg`. Replace `myorg` with your organization's name. You must use lowercase letters for your organization's name.
-
-```console
-$ sudo hdiutil attach Docker.dmg
-$ sudo /Volumes/Docker/Docker.app/Contents/MacOS/install --allowed-org=myorg
-$ sudo hdiutil detach /Volumes/Docker
-```
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Option 3: Create a registry.json file using the command line
-
-To create a `registry.json` using the command line, use the following instructions based on your user's operating system.
-
-{{< tabs >}}
-{{< tab name="Windows" >}}
-
-To use the CLI to create a `registry.json` file, run the following PowerShell
-command as an administrator and replace `myorg` with your organization's name. The file
-contents are case-sensitive and you must use lowercase letters for your
-organization's name.
-
-```powershell
-PS>  Set-Content /ProgramData/DockerDesktop/registry.json '{"allowedOrgs":["myorg"]}'
-```
-
-This creates the `registry.json` file at
-`C:\ProgramData\DockerDesktop\registry.json` and includes the organization
-information the user belongs to. Make sure that the user can't edit this file, but only the administrator can:
-
-```console
-PS C:\ProgramData\DockerDesktop> Get-Acl .\registry.json
-
-
-    Directory: C:\ProgramData\DockerDesktop
-
-
-Path          Owner                  Access
-----          -----                  ------
-registry.json BUILTIN\Administrators NT AUTHORITY\SYSTEM Allow  FullControl...
-```
-
-> [!IMPORTANT]
->
-> As of Docker Desktop version 4.36 and later, you can add more than one organization to a single `registry.json` file. With Docker Desktop version 4.35 and earlier, if you add more than one organization sign-in enforcement silently fails.
-
-{{< /tab >}}
-{{< tab name="Mac" >}}
-
-To use the CLI to create a `registry.json` file, run the following commands in a
-terminal and replace `myorg` with your organization's name. The file contents
-are case-sensitive and you must use lowercase letters for your organization's
-name.
-
-```console
-$ sudo mkdir -p "/Library/Application Support/com.docker.docker"
-$ echo '{"allowedOrgs":["myorg"]}' | sudo tee "/Library/Application Support/com.docker.docker/registry.json"
-```
-
-This creates (or updates, if the file already exists) the `registry.json` file
-at `/Library/Application Support/com.docker.docker/registry.json` and includes
-the organization information the user belongs to. Make sure that the file has the
-expected content, and that the user can't edit this file, but only the administrator can.
-
-Verify that the content of the file contains the correct information:
-
-```console
-$ sudo cat "/Library/Application Support/com.docker.docker/registry.json"
-{"allowedOrgs":["myorg"]}
-```
-
-Verify that the file has the expected permissions (`-rw-r--r--`) and ownership
-(`root` and `admin`):
-
-```console
-$ sudo ls -l "/Library/Application Support/com.docker.docker/registry.json"
--rw-r--r--  1 root  admin  26 Jul 27 22:01 /Library/Application Support/com.docker.docker/registry.json
-```
-
-> [!IMPORTANT]
->
-> As of Docker Desktop version 4.36 and later, you can add more than one organization to a single `registry.json` file. With Docker Desktop version 4.35 and earlier, if you add more than one organization sign-in enforcement silently fails.
-
-{{< /tab >}}
-{{< tab name="Linux" >}}
-
-To use the CLI to create a `registry.json` file, run the following commands in a
-terminal and replace `myorg` with your organization's name. The file contents
-are case-sensitive and you must use lowercase letters for your organization's
-name.
-
-```console
-$ sudo mkdir -p /usr/share/docker-desktop/registry
-$ echo '{"allowedOrgs":["myorg"]}' | sudo tee /usr/share/docker-desktop/registry/registry.json
-```
-
-This creates (or updates, if the file already exists) the `registry.json` file
-at `/usr/share/docker-desktop/registry/registry.json` and includes the
-organization information to which the user belongs. Make sure the file has the
-expected content and that the user can't edit this file, only the root can.
-
-Verify that the content of the file contains the correct information:
-
-```console
-$ sudo cat /usr/share/docker-desktop/registry/registry.json
-{"allowedOrgs":["myorg"]}
-```
-
-Verify that the file has the expected permissions (`-rw-r--r--`) and ownership
-(`root`):
-
-```console
-$ sudo ls -l /usr/share/docker-desktop/registry/registry.json
--rw-r--r--  1 root  root  26 Jul 27 22:01 /usr/share/docker-desktop/registry/registry.json
-```
-
-> [!IMPORTANT]
->
-> As of Docker Desktop version 4.36 and later, you can add more than one organization to a single `registry.json` file. With Docker Desktop version 4.35 and earlier, if you add more than one organization sign-in enforcement silently fails.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## More resources
-
-- [Video: Enforce sign-in with a registry.json](https://www.youtube.com/watch?v=CIOQ6wDnJnM)
diff --git a/content/manuals/security/for-admins/hardened-desktop/_index.md b/content/manuals/security/for-admins/hardened-desktop/_index.md
deleted file mode 100644
index bdbbe71c02d9..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/_index.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-title: Overview of Hardened Docker Desktop
-linkTitle: Hardened Docker Desktop
-description: Overview of what Hardened Docker Desktop is and its key features
-keywords: security, hardened desktop, enhanced container isolation, registry access
-  management, settings management root access, admins, docker desktop, image access
-  management
-tags: [admin]
-aliases:
- - /desktop/hardened-desktop/
-grid:
-  - title: "Settings Management"
-    description: Learn how Settings Management can secure your developers' workflows.
-    icon: shield_locked
-    link: /security/for-admins/hardened-desktop/settings-management/
-  - title: "Enhanced Container Isolation"
-    description: Understand how Enhanced Container Isolation can prevent container attacks.
-    icon: "security"
-    link: /security/for-admins/hardened-desktop/enhanced-container-isolation/
-  - title: "Registry Access Management"
-    description: Control the registries developers can access while using Docker Desktop.
-    icon: "home_storage"
-    link: /security/for-admins/hardened-desktop/registry-access-management/
-  - title: "Image Access Management"
-    description: Control the images developers can pull from Docker Hub.
-    icon: "photo_library"
-    link: /security/for-admins/hardened-desktop/image-access-management/
-  - title: "Air-Gapped Containers"
-    description: Restrict containers from accessing unwanted network resources.
-    icon: "vpn_lock"
-    link: /security/for-admins/hardened-desktop/air-gapped-containers/
-weight: 60
----
-
-{{< summary-bar feature_name="Hardened Docker Desktop" >}}
-
-Hardened Docker Desktop is a group of security features, designed to improve the security of developer environments with minimal impact on developer experience or productivity.
-
-It lets you enforce strict security settings, preventing developers and their containers from bypassing these controls, either intentionally or unintentionally. Additionally, you can enhance container isolation, to mitigate potential security threats such as malicious payloads breaching the Docker Desktop Linux VM and the underlying host.
-
-Hardened Docker Desktop moves the ownership boundary for Docker Desktop configuration to the organization, meaning that any security controls you set cannot be altered by the user of Docker Desktop. 
-
-It is for security conscious organizations who:
-- Don’t give their users root or administrator access on their machines
-- Would like Docker Desktop to be within their organization’s centralized control
-- Have certain compliance obligations
-
-### How does it help my organization?
-
-Hardened Desktop features work independently but collectively to create a defense-in-depth strategy, safeguarding developer workstations against potential attacks across various functional layers, such as configuring Docker Desktop, pulling container images, and running container images. This multi-layered defense approach ensures comprehensive security. It helps mitigate against threats such as:
-
- - Malware and supply chain attacks: Registry Access Management and Image Access Management prevent developers from accessing certain container registries and image types, significantly lowering the risk of malicious payloads. Additionally, Enhanced Container Isolation (ECI) restricts the impact of containers with malicious payloads by running them without root privileges inside a Linux user namespace.
- - Lateral movement: Air-gapped containers lets you configure network access restrictions for containers, thereby preventing malicious containers from performing lateral movement within the organization's network.
- - Insider threats: Settings Management configures and locks various Docker Desktop settings so you can enforce company policies and prevent developers from introducing insecure configurations, intentionally or unintentionally.
-
-{{< grid >}}
diff --git a/content/manuals/security/for-admins/hardened-desktop/air-gapped-containers.md b/content/manuals/security/for-admins/hardened-desktop/air-gapped-containers.md
deleted file mode 100644
index 595493ef4d92..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/air-gapped-containers.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: Air-gapped containers
-description: Air-gapped containers - What it is, benefits, and how to configure it.
-keywords: air gapped, security, Docker Desktop, configuration, proxy, network
-aliases:
- - /desktop/hardened-desktop/settings-management/air-gapped-containers/
- - /desktop/hardened-desktop/air-gapped-containers/
----
-
-{{< summary-bar feature_name="Air-gapped containers" >}}
-
-Air-gapped containers let you restrict containers from accessing network resources, limiting where data can be uploaded to or downloaded from.
-
-Docker Desktop can apply a custom set of proxy rules to network traffic from containers. The proxy can be configured to:
-
-- Accept network connections
-- Reject network connections
-- Tunnel through an HTTP or SOCKS proxy
-
-You can choose:
-
-- Which outgoing TCP ports the policy applies to. For example, only certain ports, `80`, `443` or all with `*`.
-- Whether to forward to a single HTTP or SOCKS proxy, or to have a policy per destination via a Proxy Auto-Configuration (PAC) file.
-
-## Configuration
-
-Assuming [enforced sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) and [Settings Management](settings-management/_index.md) are enabled, add the new proxy configuration to the `admin-settings.json` file. For example:
-
-```json
-{
-  "configurationFileVersion": 2,
-  "containersProxy": {
-    "locked": true,
-    "mode": "manual",
-    "http": "",
-    "https": "",
-    "exclude": [],
-    "pac": "http://192.168.1.16:62039/proxy.pac",
-    "transparentPorts": "*"
-  }
-}
-```
-
-The `containersProxy` setting describes the policy which is applied to traffic from containers. The valid fields are:
-
-- `locked`: If true, it is not possible for developers to override these settings. If false the settings are interpreted as default values which the developer can change.
-- `mode`: Same meaning as with the existing `proxy` setting. Possible values are `system` and `manual`.
-- `http`, `https`, `exclude`: Same meaning as with the `proxy` setting. Only takes effect if `mode` is set to `manual`.
-- `pac` : URL for a PAC file. Only takes effect if `mode` is `manual`, and is considered higher priority than `http`, `https`, `exclude`.
-- `transparentPorts`: A comma-separated list of ports (e.g. `"80,443,8080"`) or a wildcard (`*`) indicating which ports should be proxied.
-
-> [!IMPORTANT]
->
-> Any existing `proxy` setting in the `admin-settings.json` file continues to apply to traffic from the app on the host.
-> If the PAC file download fails, the Docker Desktop app and its containers do not block the request; instead, they attempt to connect directly to the target URL.
-
-## Example PAC file
-
-For general information about PAC files, see the [MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file).
-
-The following is an example PAC file:
-
-```javascript
-function FindProxyForURL(url, host) {
-	if (localHostOrDomainIs(host, 'internal.corp')) {
-		return "PROXY 10.0.0.1:3128";
-	}
-	if (isInNet(host, "192.168.0.0", "255.255.255.0")) {
-	    return "DIRECT";
-	}
-    return "PROXY reject.docker.internal:1234";
-}
-```
-
-The `url` parameter is either `http://host_or_ip:port` or `https://host_or_ip:port`.
-
-The hostname is normally available for outgoing requests on port `80` and `443`, but for other cases there is only an IP address.
-
-The `FindProxyForURL` can return the following values:
-
-- `PROXY host_or_ip:port`: Tunnels this request through the HTTP proxy `host_or_ip:port`
-- `SOCKS5 host_or_ip:port`: Tunnels this request through the SOCKS proxy `host_or_ip:port`
-- `DIRECT`: Lets this request go direct, without a proxy
-- `PROXY reject.docker.internal:any_port`: Rejects this request
-
-In this particular example, HTTP and HTTPS requests for `internal.corp` are sent via the HTTP proxy `10.0.0.1:3128`. Requests to connect to IPs on the subnet `192.168.0.0/24` connect directly. All other requests are blocked.
-
-To restrict traffic connecting to ports on the developers local machine, [match the special hostname `host.docker.internal`](/manuals/desktop/features/networking.md#i-want-to-connect-from-a-container-to-a-service-on-the-host).
diff --git a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md b/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md
deleted file mode 100644
index 5b4740019404..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md
+++ /dev/null
@@ -1,165 +0,0 @@
----
-description: Enhanced Container Isolation - benefits, why use it, how it differs to
-  Docker rootless, who it is for
-keywords: containers, rootless, security, sysbox, runtime
-title: What is Enhanced Container Isolation?
-linkTitle: Enhanced Container Isolation
-aliases:
- - /desktop/hardened-desktop/enhanced-container-isolation/
-weight: 20
----
-
-{{< summary-bar feature_name="Hardened Docker Desktop" >}}
-
-Enhanced Container Isolation (ECI) provides an additional layer of security to prevent malicious workloads running in containers from compromising Docker Desktop or the host.
-
-It uses a variety of advanced techniques to harden container isolation, but without impacting developer productivity.
-
-Enhanced Container Isolation ensures stronger container isolation and also locks in any security configurations that have been created by administrators, for instance through [Registry Access Management policies](/manuals/security/for-admins/hardened-desktop/registry-access-management.md) or with [Settings Management](../settings-management/_index.md).
-
-> [!NOTE]
->
-> ECI is in addition to other container security techniques used by Docker. For example, reduced Linux Capabilities, seccomp, and AppArmor.
-
-## Who is it for?
-
-- For organizations and developers that want to prevent container attacks and reduce vulnerabilities in developer environments.
-- For organizations that want to ensure stronger container isolation that is easy and intuitive to implement on developers' machines.
-
-## What happens when Enhanced Container Isolation is turned on?
-
-When Enhanced Container Isolation is turned on, the following features and security techniques are enabled:
-
-- All user containers are automatically run in Linux user namespaces which ensures stronger isolation. Each container runs in a dedicated Linux user-namespace.
-- The root user in the container maps to an unprivileged user inside the Docker Desktop Linux VM.
-- Containers become harder to breach. For example, sensitive system calls are vetted and portions of `/proc` and `/sys` are emulated inside the container.
-- Users can continue using containers as usual, including bind mounting host directories, volumes, etc.
-- No change in the way developers run containers, and no special container images are required.
-- Privileged containers (e.g., `--privileged` flag) work, but they are only privileged within the container's Linux user namespace, not in the Docker Desktop VM. Therefore they can't be used to breach the Docker Desktop VM.
-- Docker-in-Docker and even Kubernetes-in-Docker works, but run unprivileged inside the Docker Desktop Linux VM.
-
-In addition, the following restrictions are imposed:
-
-- Containers can no longer share namespaces with the Docker Desktop VM (e.g., `--network=host`, `--pid=host` are disallowed).
-- Containers can no longer modify configuration files inside the Docker Desktop VM (e.g., mounting any VM directory into the container is disallowed).
-- Containers can no longer access the Docker Engine. For example, mounting the Docker Engine's socket into the container is restricted which prevents malicious containers from gaining control of the Docker Engine. Administrators can relax this for [trusted container images](config.md).
-- Console access to the Docker Desktop VM is forbidden for all users.
-
-These features and restrictions ensure that containers are better secured at runtime, with minimal impact to developer experience and productivity. Developers can continue to use Docker Desktop as usual, but the containers they launch are more strongly isolated.
-
-For more information on how Enhanced Container Isolation work, see [How does it work](how-eci-works.md).
-
-> [!IMPORTANT]
->
-> ECI protection for Docker builds and [Kubernetes in Docker Desktop](/manuals/desktop/features/kubernetes.md) varies according to the
-> Docker Desktop version. Later versions include more protection than earlier versions. Also, ECI does not yet
-> protect extension containers. For more information on known limitations and workarounds, see [FAQs](faq.md).
-
-## How do I enable Enhanced Container Isolation?
-
-### As a developer
-
-To enable Enhanced Container Isolation as a developer:
-1. Ensure your organization has a Docker Business subscription.
-2. Sign in to your organization in Docker Desktop. This will ensure the ECI feature is available to you in Docker Desktop's Settings menu.
-3. Stop and remove all existing containers.
-4. Navigate to **Settings** > **General** in Docker Desktop.
-5. Next to **Use Enhanced Container Isolation**, select the checkbox.
-6. Select **Apply and restart** to save your settings.
-
-> [!IMPORTANT]
->
-> Enhanced Container Isolation does not protect containers created prior to enabling ECI. For more information on known limitations and workarounds, see [FAQs](faq.md).
-
-### As an administrator
-
-#### Prerequisite
-
-You first need to [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) to ensure that all Docker Desktop developers authenticate with your organization. Since Settings Management requires a Docker Business subscription, enforced sign-in guarantees that only authenticated users have access and that the feature consistently takes effect across all users, even though it may still work without enforced sign-in.
-
-#### Setup
-
-[Create and configure the `admin-settings.json` file](/manuals/security/for-admins/hardened-desktop/settings-management/configure-json-file.md) and specify:
-
-```json
-{
-  "configurationFileVersion": 2,
-  "enhancedContainerIsolation": {
-    "value": true,
-    "locked": true
-  }
-}
-```
-
-Setting `"value": true` ensures ECI is enabled by default. By
-setting `"locked": true`, ECI can't be disabled by
-developers. If you want to give developers the ability to disable the feature,
-set `"locked": false`.
-
-In addition, you can also [configure Docker
-socket mount permissions for containers](config.md).
-
-For this to take effect:
-
-- On a new install, developers need to launch Docker Desktop and authenticate to their organization.
-- On an existing install, developers need to quit Docker Desktop through the Docker menu, and then relaunch Docker Desktop. If they are already signed in, they don’t need to sign in again for the changes to take effect.
-
-> [!IMPORTANT]
->
-> Selecting **Restart** from the Docker menu isn't enough as it only restarts some components of Docker Desktop.
-
-## What do users see when this setting is enforced by an administrator?
-
-> [!TIP]
->
-> You can now also configure these settings in the [Docker Admin Console](/manuals/security/for-admins/hardened-desktop/settings-management/configure-admin-console.md).
-
-When Enhanced Container Isolation is enabled, users see:
-- **Use Enhanced Container Isolation** toggled on in **Settings** > **General**.
-- Containers run within a Linux user namespace.
-
-To check, run:
-
-```console
-$ docker run --rm alpine cat /proc/self/uid_map
-```
-
-The following output displays:
-
-```text
-         0     100000      65536
-```
-
-This indicates that the container's root user (0) maps to unprivileged user
-(100000) in the Docker Desktop VM, and that the mapping extends for a range of
-64K user-IDs. If a container process were to escape the container, it would
-find itself without privileges at the VM level. The user-ID mapping varies with
-each new container, as each container gets an exclusive range of host User-IDs
-for isolation. User-ID mapping is automatically managed by Docker Desktop. For
-further details, see [How Enhanced Container Isolation works](how-eci-works.md).
-
-In contrast, without ECI the Linux user namespace is not used for containers, the following displays:
-
-```text
-         0          0 4294967295
-```
-
-This means that the root user in the container (0) is in fact the root user in the Docker Desktop VM (0) which reduces container isolation.
-
-Since Enhanced Container Isolation [uses the Sysbox container runtime](how-eci-works.md) embedded in the Docker Desktop Linux VM, another way to determine if a container is running with Enhanced Container Isolation is by using `docker inspect`:
-
-```console
-$ docker inspect --format='{{.HostConfig.Runtime}}' my_container
-```
-
-It outputs:
-
-```text
-sysbox-runc
-```
-
-Without Enhanced Container Isolation, `docker inspect` outputs `runc`, which is the standard OCI runtime.
-
-## More resources
-
-- [Video: Enhanced Container Isolation](https://www.youtube.com/watch?v=oA1WQZWnTAk)
diff --git a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md b/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md
deleted file mode 100644
index 6719541d764a..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md
+++ /dev/null
@@ -1,362 +0,0 @@
----
-description: Advanced Configuration for Enhanced Container Isolation
-title: Advanced configuration options for ECI
-linkTitle: Advanced configuration
-keywords: enhanced container isolation, Docker Desktop, Docker socket, bind mount, configuration
-aliases:
- - /desktop/hardened-desktop/enhanced-container-isolation/config/
-weight: 30
----
-
-{{< summary-bar feature_name="Hardened Docker Desktop" >}}
-
-## Docker socket mount permissions
-
-By default, when Enhanced Container Isolation (ECI) is enabled, Docker Desktop does not allow bind-mounting the
-Docker Engine socket into containers:
-
-```console
-$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock docker:cli
-docker: Error response from daemon: enhanced container isolation: docker socket mount denied for container with image "docker.io/library/docker"; image is not in the allowed list; if you wish to allow it, configure the docker socket image list in the Docker Desktop settings.
-```
-This prevents malicious containers from gaining access to the Docker Engine, as
-such access could allow them to perform supply chain attacks. For example, build and
-push malicious images into the organization's repositories or similar.
-
-However, some legitimate use cases require containers to have access to the
-Docker Engine socket. For example, the popular [Testcontainers](https://testcontainers.com/)
-framework sometimes bind-mounts the Docker Engine socket into containers to
-manage them or perform post-test cleanup. Similarly, some Buildpack frameworks,
-for example [Paketo](https://paketo.io/), require Docker socket bind-mounts into
-containers.
-
-Administrators can optionally configure ECI to allow
-bind mounting the Docker Engine socket into containers, but in a controlled way.
-
-This can be done via the Docker Socket mount permissions section in the
-[`admin-settings.json`](../settings-management/configure-json-file.md) file. For example:
-
-
-```json
-{
-  "configurationFileVersion": 2,
-  "enhancedContainerIsolation": {
-    "locked": true,
-    "value": true,
-    "dockerSocketMount": {
-      "imageList": {
-        "images": [
-          "docker.io/localstack/localstack:*",
-          "docker.io/testcontainers/ryuk:*",
-          "docker:cli"
-        ],
-        "allowDerivedImages": true
-      },
-      "commandList": {
-        "type": "deny",
-        "commands": ["push"]
-      }
-    }
-  }
-}
-```
-
-> [!TIP]
->
-> You can now also configure these settings in the [Docker Admin Console](/manuals/security/for-admins/hardened-desktop/settings-management/configure-admin-console.md).
-
-As shown above, there are two configurations for bind-mounting the Docker
-socket into containers: the `imageList` and the `commandList`. These are
-described below.
-
-### Image list
-
-The `imageList` is a list of container images that are allowed to bind-mount the
-Docker socket. By default the list is empty, no containers are allowed to
-bind-mount the Docker socket when ECI is enabled. However, an administrator can add
-images to the list, using either of these formats:
-
-| Image Reference Format  | Description |
-| :---------------------- | :---------- |
-| `<image_name>[:<tag>]`  | Name of the image, with optional tag. If the tag is omitted, the `:latest` tag is used. If the tag is the wildcard `*`, then it means "any tag for that image." |
-| `<image_name>@<digest>` | Name of the image, with a specific repository digest (e.g., as reported by `docker buildx imagetools inspect <image>`). This means only the image that matches that name and digest is allowed. |
-
-The image name follows the standard convention, so it can point to any registry
-and repository.
-
-In the previous example, the image list was configured with three images:
-
-```json
-"imageList": {
-  "images": [
-    "docker.io/localstack/localstack:*",
-    "docker.io/testcontainers/ryuk:*",
-    "docker:cli"
-  ]
-}
-```
-
-This means that containers that use either the `docker.io/localstack/localstack`
-or the `docker.io/testcontainers/ryuk` image (with any tag), or the `docker:cli`
-image, are allowed to bind-mount the Docker socket when ECI is enabled. Thus,
-the following works:
-
-```console
-$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker:cli sh
-/ #
-```
-
-> [!TIP]
->
-> Be restrictive with the images you allow, as described in [Recommendations](#recommendations).
-
-In general, it's easier to specify the image using the tag wildcard format, for example `<image-name>:*`, because then `imageList` doesn't need to be updated whenever a new version of the
-image is used. Alternatively, you can use an immutable tag, for example `:latest`,
-but it does not always work as well as the wildcard because, for example,
-Testcontainers uses specific versions of the image, not necessarily the latest
-one.
-
-When ECI is enabled, Docker Desktop periodically downloads the image digests
-for the allowed images from the appropriate registry and stores them in
-memory. Then, when a container is started with a Docker socket bind-mount,
-Docker Desktop checks if the container's image digest matches one of the allowed
-digests. If so, the container is allowed to start, otherwise it's blocked.
-
-Due to the digest comparison, it's not possible to bypass the Docker socket
-mount permissions by re-tagging a disallowed image to the name of an allowed
-one. In other words, if a user does:
-
-```console
-$ docker image rm <allowed_image>
-$ docker tag <disallowed_image> <allowed_image>
-$ docker run -v /var/run/docker.sock:/var/run/docker.sock <allowed_image>
-```
-
-then the tag operation succeeds, but the `docker run` command fails
-because the image digest of the disallowed image won't match that of the allowed
-ones in the repository.
-
-### Docker Socket Mount Permissions for derived images
-
-{{< summary-bar feature_name="Docker Scout Mount Permissions" >}}
-
-As described in the prior section, administrators can configure the list of container
-images that are allowed to mount the Docker socket via the `imageList`.
-
-This works for most scenarios, but not always, because it requires knowing upfront
-the name of the image(s) on which the Docker socket mounts should be allowed.
-Some container tools such as [Paketo](https://paketo.io/) buildpacks,
-build ephemeral local images that require Docker socket bind mounts. Since the name of
-those ephemeral images is not known upfront, the `imageList` is not sufficient.
-
-To overcome this, starting with Docker Desktop version 4.34, the Docker Socket
-mount permissions not only apply to the images listed in the `imageList`; they
-also apply to any local images derived (i.e., built from) an image in the
-`imageList`.
-
-That is, if a local image called "myLocalImage" is built from "myBaseImage"
-(i.e., has a Dockerfile with a `FROM myBaseImage`), then if "myBaseImage" is in
-the `imageList`, both "myBaseImage" and "myLocalImage" are allowed to mount the
-Docker socket.
-
-For example, to enable Paketo buildpacks to work with Docker Desktop and ECI,
-simply add the following image to the `imageList`:
-
-```json
-"imageList": {
-  "images": [
-    "paketobuildpacks/builder:base"
-  ],
-  "allowDerivedImages": true
-}
-```
-
-When the buildpack runs, it will create an ephemeral image derived from
-`paketobuildpacks/builder:base` and mount the Docker socket to it. ECI will
-allow this because it will notice that the ephemeral image is derived from an
-allowed image.
-
-The behavior is disabled by default and must be explicitly enabled by setting
-`"allowDerivedImages": true` as shown above. In general it is recommended that
-you disable this setting unless you know it's required.
-
-A few caveats:
-
-* Setting `"allowedDerivedImages" :true` will impact the startup time of
-  containers by up to 1 extra second, as Docker Desktop needs to perform
-  some more checks on the container image.
-
-* The `allowDerivedImages` setting only applies to local-only images built from
-  an allowed image. That is, the derived image must not be present in a remote
-  repository because if it were, you would just list its name in the `imageList`.
-
-* For derived image checking to work, the parent image (i.e., the image in the
-  `imageList`) must be present locally (i.e., must have been explicitly pulled
-  from a repository). This is usually not a problem as the tools that need this
-  feature (e.g., Paketo buildpacks) will do the pre-pull of the parent image.
-
-* For Docker Desktop versions 4.34 and 4.35 only: The `allowDerivedImages` setting
-  applies to all images in the `imageList` specified with an explicit tag (e.g.,
-  `<name>:<tag>`). It does not apply to images specified using the tag wildcard
-  (e.g., `<name>:*`) described in the prior section. In Docker Desktop 4.36 and
-  later, this caveat no longer applies, meaning that the `allowDerivedImages`
-  settings applies to images specified with or without a wildcard tag. This
-  makes it easier to manage the ECI Docker socket image list.
-
-### Allowing all containers to mount the Docker socket
-
-In Docker Desktop version 4.36 and later, it's possible to configure the image
-list to allow any container to mount the Docker socket. You do this by adding
-`"*"` to the `imageList`:
-
-```json
-"imageList": {
-  "images": [
-    "*"
-  ]
-}
-```
-
-This tells Docker Desktop to allow all containers to mount the Docker socket
-which increases flexibility but reduces security. It also improves container
-startup time when using Enhanced Container Isolation.
-
-It is recommended that you use this only in scenarios where explicitly listing
-allowed container images is not flexible enough.
-
-### Command list
-
-In addition to the `imageList` described in the prior sections, ECI can further
-restrict the commands that a container can issue via a bind mounted Docker
-socket. This is done via the Docker socket mount permission `commandList`, and
-acts as a complementary security mechanism to the `imageList` (i.e., like a
-second line of defense).
-
-For example, say the `imageList` is configured to allow image `docker:cli` to
-mount the Docker socket, and a container is started with it:
-
-```console
-$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock sh
-/ #
-```
-
-By default, this allows the container to issue any command via that Docker
-socket (e.g., build and push images to the organization's repositories), which
-is generally not desirable.
-
-To improve security, the `commandList` can be configured to restrict the
-commands that the processes inside the container can issue on the bind-mounted
-Docker socket. The `commandList` can be configured as a "deny" list (default) or
-an "allow" list, depending on your preference.
-
-Each command in the list is specified by its name, as reported by `docker
---help` (e.g., "ps", "build", "pull", "push", etc.) In addition, the following
-command wildcards are allowed to block an entire group of commands:
-
-| Command wildcard  | Description |
-| :---------------- | :---------- |
-| "container\*"     | Refers to all "docker container ..." commands |
-| "image\*"         | Refers to all "docker image ..." commands |
-| "volume\*"        | Refers to all "docker volume ..." commands |
-| "network\*"       | Refers to all "docker network ..." commands |
-| "build\*"         | Refers to all "docker build ..." commands |
-| "system\*"        | Refers to all "docker system ..." commands |
-
-For example, the following configuration blocks the `build` and `push` commands
-on the Docker socket:
-
-```json
-"commandList": {
-  "type": "deny",
-  "commands": ["build", "push"]
-}
-```
-
-Thus, if inside the container, you issue either of those commands on the
-bind-mounted Docker socket, they will be blocked:
-
-```console
-/ # docker push myimage
-Error response from daemon: enhanced container isolation: docker command "/v1.43/images/myimage/push?tag=latest" is blocked; if you wish to allow it, configure the docker socket command list in the Docker Desktop settings or admin-settings.
-```
-
-Similarly:
-
-```console
-/ # curl --unix-socket /var/run/docker.sock -XPOST http://localhost/v1.43/images/myimage/push?tag=latest
-Error response from daemon: enhanced container isolation: docker command "/v1.43/images/myimage/push?tag=latest" is blocked; if you wish to allow it, configure the docker socket command list in the Docker Desktop settings or admin-settings.
-```
-
-Note that if the `commandList` had been configured as an "allow" list, then the
-effect would be the opposite: only the listed commands would have been allowed.
-Whether to configure the list as an allow or deny list depends on the use case.
-
-### Recommendations
-
-* Be restrictive on the list of container images for which you allow bind-mounting
-  of the Docker socket (i.e., the `imageList`). Generally, only allow this for
-  images that are absolutely needed and that you trust.
-
-* Use the tag wildcard format if possible in the `imageList`
-  (e.g., `<image_name>:*`), as this eliminates the need to update the
-  `admin-settings.json` file due to image tag changes.
-
-* In the `commandList`, block commands that you don't expect the container to
-  execute. For example, for local testing (e.g., Testcontainers), containers
-  that bind-mount the Docker socket typically create / run / remove containers,
-  volumes, and networks, but don't typically build images or push them into
-  repositories (though some may legitimately do this). What commands to allow or
-  block depends on the use case.
-
-  - Note that all "docker" commands issued by the container via the bind-mounted
-    Docker socket will also execute under enhanced container isolation (i.e.,
-    the resulting container uses a the Linux user-namespace, sensitive system
-    calls are vetted, etc.)
-
-### Caveats and limitations
-
-* When Docker Desktop is restarted, it's possible that an image that is allowed
-  to mount the Docker socket is unexpectedly blocked from doing so. This can
-  happen when the image digest changes in the remote repository (e.g., a
-  ":latest" image was updated) and the local copy of that image (e.g., from a
-  prior `docker pull`) no longer matches the digest in the remote repository. In
-  this case, remove the local image and pull it again (e.g., `docker rm <image>`
-  and `docker pull <image>`).
-
-* It's not possible to allow Docker socket bind-mounts on containers using
-  local-only images (i.e., images that are not on a registry) unless they are
-  [derived from an allowed image](#docker-socket-mount-permissions-for-derived-images)
-  or you've [allowed all containers to mount the Docker socket](#allowing-all-containers-to-mount-the-docker-socket).
-  That is because Docker Desktop pulls the digests for the allowed images from
-  the registry, and then uses that to compare against the local copy of the
-  image.
-
-* The `commandList` configuration applies to all containers that are allowed to
-  bind-mount the Docker socket. Therefore it can't be configured differently per
-  container.
-
-* The following commands are not yet supported in the `commandList`:
-
-| Unsupported command  | Description |
-| :------------------- | :---------- |
-| `compose`              | Docker Compose |
-| `dev`                  | Dev environments |
-| `extension`            | Manages Docker Extensions |
-| `feedback`             | Send feedback to Docker |
-| `init`                 | Creates Docker-related starter files |
-| `manifest`             | Manages Docker image manifests |
-| `plugin`              | Manages plugins |
-| `sbom`                 | View Software Bill of Materials (SBOM) |
-| `scout`                | Docker Scout |
-| `trust`                | Manage trust on Docker images |
-
-> [!NOTE]
->
-> Docker socket mount permissions do not apply when running "true"
-> Docker-in-Docker (i.e., when running the Docker Engine inside a container). In
-> this case there's no bind-mount of the host's Docker socket into the
-> container, and therefore no risk of the container leveraging the configuration
-> and credentials of the host's Docker Engine to perform malicious activity.
-> Enhanced Container Isolation is capable of running Docker-in-Docker securely,
-> without giving the outer container true root permissions in the Docker Desktop
-> VM.
diff --git a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/faq.md b/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/faq.md
deleted file mode 100644
index f3d58009e9eb..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/faq.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: Enhanced Container Isolation FAQs
-linkTitle: FAQs
-description: Frequently asked questions for Enhanced Container Isolation
-keywords: enhanced container isolation, security, faq, sysbox, Docker Desktop
-toc_max: 2
-aliases:
- - /desktop/hardened-desktop/enhanced-container-isolation/faq/
-weight: 40
----
-
-### Do I need to change the way I use Docker when ECI is switched on?
-
-No, you can continue to use Docker as usual. ECI works under the covers by
-creating a more secure container.
-
-### Do all container workloads work well with ECI?
-
-The great majority of container workloads run fine with ECI enabled, but a few
-do not (yet). For the few workloads that don't yet work with Enhanced Container
-Isolation, Docker is continuing to improve the feature to reduce this to a
-minimum.
-
-### Can I run privileged containers with ECI?
-
-Yes, you can use the `--privileged` flag in containers but unlike privileged
-containers without ECI, the container can only use it's elevated privileges to
-access resources assigned to the container. It can't access global kernel
-resources in the Docker Desktop Linux VM. This lets you run privileged
-containers securely (including Docker-in-Docker). For more information, see [Key features and benefits](features-benefits.md#privileged-containers-are-also-secured).
-
-### Will all privileged container workloads run with ECI?
-
-No. Privileged container workloads that want to access global kernel resources
-inside the Docker Desktop Linux VM won't work. For example, you can't use a
-privileged container to load a kernel module.
-
-### Why not just restrict usage of the `--privileged` flag?
-
-Privileged containers are typically used to run advanced workloads in
-containers, for example Docker-in-Docker or Kubernetes-in-Docker, to
-perform kernel operations such as loading modules, or to access hardware
-devices.
-
-ECI allows the running of advanced workloads, but denies the ability to perform
-kernel operations or access hardware devices.
-
-### Does ECI restrict bind mounts inside the container?
-
-Yes, it restricts bind mounts of directories located in the Docker Desktop Linux
-VM into the container.
-
-It doesn't restrict bind mounts of your host machine files into the container,
-as configured via Docker Desktop's **Settings** > **Resources** > **File Sharing**.
-
-### Can I mount the host's Docker Socket into a container when ECI is enabled?
-
-By default, ECI blocks bind-mounting the host's Docker socket into containers,
-for security reasons. However, there are legitimate use cases for this, such as
-when using [Testcontainers](https://testcontainers.com/) for local testing.
-
-To enable such use cases, it's possible to configure ECI to allow Docker socket
-mounts into containers, but only for your chosen (i.e,. trusted) container images, and
-even restrict what commands the container can send to the Docker Engine via the socket.
-See [ECI Docker socket mount permissions](config.md#docker-socket-mount-permissions).
-
-### Does ECI protect all containers launched with Docker Desktop?
-
-Not yet. It protects all containers launched by users via `docker create` and
-`docker run`.
-
-For containers implicitly created by `docker build` as well as Docker
-Desktop's integrated Kubernetes, protection varies depending on the Docker
-Desktop version (see the following two FAQs).
-
-ECI does not yet protect Docker Desktop Extension containers and
-[Dev Environments containers](/manuals/desktop/features/dev-environments/_index.md).
-
-### Does ECI protect containers implicitly used by `docker build`?
-
-Prior to Docker Desktop 4.19, ECI did not protect containers used implicitly
-by `docker build` during the build process.
-
-Since Docker Desktop 4.19, ECI protects containers used by `docker build`
-when using the [Docker container driver](/manuals/build/builders/drivers/_index.md).
-
-In addition, since Docker Desktop 4.30, ECI also protects containers used by
-`docker build` when using the default "docker" build driver, on all
-platforms supported by Docker Desktop except Windows with WSL 2.
-
-### Does ECI protect Kubernetes in Docker Desktop?
-
-Prior to Docker Desktop 4.38, ECI did not protect the Kubernetes cluster
-integrated in Docker Desktop.
-
-Since Docker Desktop 4.38, ECI protects the integrated Kubernetes cluster
-when using the new **kind** provisioner (see [Deploy On Kubernetes](/manuals/desktop/features/kubernetes.md)).
-In this case, each node in the multi-node Kubernetes cluster is actually an ECI
-protected container. With ECI disabled, each node in the Kubernetes cluster is
-a less-secure fully privileged container.
-
-ECI does not protect the integrated Kubernetes cluster when using the
-older **Kubeadm** single-node cluster provisioner.
-
-### Does ECI protect containers launched prior to enabling ECI?
-
-No. Containers created prior to switching on ECI are not protected. Therefore, it is
-recommended you remove all containers prior to switching on ECI.
-
-### Does ECI affect the performance of containers?
-
-ECI has little impact on the performance of
-containers. The exception is for containers that perform lots of `mount` and
-`umount` system calls, as these are trapped and vetted by the Sysbox container
-runtime to ensure they are not being used to breach the container's filesystem.
-
-### With ECI, can the user still override the `--runtime` flag from the CLI ?
-
-No. With ECI enabled, Sysbox is set as the default (and only) runtime for
-containers deployed by Docker Desktop users. If a user attempts to override the
-runtime (e.g., `docker run --runtime=runc`), this request is ignored and the
-container is created through the Sysbox runtime.
-
-The reason `runc` is disallowed is it lets users run as "true
-root" on the Docker Desktop Linux VM, thereby providing them with implicit
-control of the VM and the ability to modify the administrative configurations
-for Docker Desktop.
-
-### How is ECI different from Docker Engine's userns-remap mode?
-
-See [How does it work](how-eci-works.md#enhanced-container-isolation-vs-docker-userns-remap-mode).
-
-### How is ECI different from Rootless Docker?
-
-See [How does it work](how-eci-works.md#enhanced-container-isolation-vs-rootless-docker)
diff --git a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/features-benefits.md b/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/features-benefits.md
deleted file mode 100644
index 832b5ee30841..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/features-benefits.md
+++ /dev/null
@@ -1,291 +0,0 @@
----
-description: The benefits of enhanced container isolation
-title: Key features and benefits
-keywords: set up, enhanced container isolation, rootless, security, features, Docker Desktop
-aliases:
- - /desktop/hardened-desktop/enhanced-container-isolation/features-benefits/
-weight: 20
----
-
-{{< summary-bar feature_name="Hardened Docker Desktop" >}}
-
-## Linux user namespace on all containers
-
-With Enhanced Container Isolation, all user containers leverage the [Linux user namespace](https://man7.org/linux/man-pages/man7/user_namespaces.7.html)
-for extra isolation. This means that the root user in the container maps to an unprivileged
-user in the Docker Desktop Linux VM.
-
-For example:
-
-```console
-$ docker run -it --rm --name=first alpine
-/ # cat /proc/self/uid_map
-         0     100000      65536
-```
-
-The output `0 100000 65536` is the signature of the Linux user namespace. It
-means that the root user (0) in the container is mapped to unprivileged user
-100000 in the Docker Desktop Linux VM, and the mapping extends for a continuous
-range of 64K user IDs. The same applies to group IDs.
-
-Each container gets an exclusive range of mappings, managed by Sysbox. For
-example, if a second container is launched the mapping range is different:
-
-```console
-$ docker run -it --rm --name=second alpine
-/ # cat /proc/self/uid_map
-         0     165536      65536
-```
-
-In contrast, without Enhanced Container Isolation, the container's root user is
-in fact root on the host (aka "true root") and this applies to all containers:
-
-```console
-$ docker run -it --rm alpine
-/ # cat /proc/self/uid_map
-         0       0     4294967295
-```
-
-By virtue of using the Linux user namespace, Enhanced Container Isolation
-ensures the container processes never run as user ID 0 (true root) in the Linux
-VM. In fact they never run with any valid user-ID in the Linux VM. Thus, their
-Linux capabilities are constrained to resources within the container only,
-increasing isolation significantly compared to regular containers, both
-container-to-host and cross-container isolation.
-
-## Privileged containers are also secured
-
-Privileged containers `docker run --privileged ...` are insecure because they
-give the container full access to the Linux kernel. That is, the container runs
-as true root with all capabilities enabled, seccomp and AppArmor restrictions
-are disabled, all hardware devices are exposed, for example.
-
-Organizations aiming to secure Docker Desktop on developers' machines face challenges with privileged containers. These containers, whether running benign or malicious workloads, can gain control of the Linux kernel within the Docker Desktop VM, potentially altering security related settings, for example registry
-access management, and network proxies.
-
-With Enhanced Container Isolation, privileged containers can no longer do
-this. The combination of the Linux user namespace and other security techniques
-used by Sysbox ensures that processes inside a privileged container can only
-access resources assigned to the container.
-
-> [!NOTE]
->
-> Enhanced Container Isolation does not prevent users from launching privileged
-> containers, but rather runs them securely by ensuring that they can only
-> modify resources associated with the container. Privileged workloads that
-> modify global kernel settings, for example loading a kernel module or changing Berkeley Packet Filters (BPF)
-> settings will not work properly as they will receive "permission
-> denied" error when attempting such operations.
-
-For example, Enhanced Container Isolation ensures privileged containers can't
-access Docker Desktop network settings in the Linux VM configured via BPF:
-
-```console
-$ docker run --privileged djs55/bpftool map show
-Error: can't get next map: Operation not permitted
-```
-
-In contrast, without Enhanced Container Isolation, privileged containers
-can easily do this:
-
-```console
-$ docker run --privileged djs55/bpftool map show
-17: ringbuf  name blocked_packets  flags 0x0
-        key 0B  value 0B  max_entries 16777216  memlock 0B
-18: hash  name allowed_map  flags 0x0
-        key 4B  value 4B  max_entries 10000  memlock 81920B
-20: lpm_trie  name allowed_trie  flags 0x1
-        key 8B  value 8B  max_entries 1024  memlock 16384B
-```
-
-Note that some advanced container workloads require privileged containers, for
-example Docker-in-Docker, Kubernetes-in-Docker, etc. With Enhanced Container
-Isolation you can still run such workloads but do so much more securely than
-before.
-
-## Containers can't share namespaces with the Linux VM
-
-When Enhanced Container Isolation is enabled, containers can't share Linux
-namespaces with the host (e.g., PID, network, uts, etc.) as that essentially
-breaks isolation.
-
-For example, sharing the PID namespace fails:
-
-```console
-$ docker run -it --rm --pid=host alpine
-docker: Error response from daemon: failed to create shim task: OCI runtime create failed: error in the container spec: invalid or unsupported container spec: sysbox containers can't share namespaces [pid] with the host (because they use the linux user-namespace for isolation): unknown.
-```
-
-Similarly sharing the network namespace fails:
-
-```console
-$ docker run -it --rm --network=host alpine
-docker: Error response from daemon: failed to create shim task: OCI runtime create failed: error in the container spec: invalid or unsupported container spec: sysbox containers can't share a network namespace with the host (because they use the linux user-namespace for isolation): unknown.
-```
-
-In addition, the `--userns=host` flag, used to disable the user namespace on the
-container, is ignored:
-
-```console
-$ docker run -it --rm --userns=host alpine
-/ # cat /proc/self/uid_map
-         0     100000      65536
-```
-
-Finally, Docker build `--network=host` and Docker buildx entitlements
-(`network.host`, `security.insecure`) are not allowed. Builds that require these
-won't work properly.
-
-## Bind mount restrictions
-
-When Enhanced Container Isolation is enabled, Docker Desktop users can continue
-to bind mount host directories into containers as configured via **Settings** >
-**Resources** > **File sharing**, but they are no longer allowed to bind mount
-arbitrary Linux VM directories into containers.
-
-This prevents containers from modifying sensitive files inside the Docker
-Desktop Linux VM, files that can hold configurations for registry access
-management, proxies, Docker Engine configurations, and more.
-
-For example, the following bind mount of the Docker Engine's configuration file
-(`/etc/docker/daemon.json` inside the Linux VM) into a container is restricted
-and therefore fails:
-
-```console
-$ docker run -it --rm -v /etc/docker/daemon.json:/mnt/daemon.json alpine
-docker: Error response from daemon: failed to create shim task: OCI runtime create failed: error in the container spec: can't mount /etc/docker/daemon.json because it's configured as a restricted host mount: unknown
-```
-
-In contrast, without Enhanced Container Isolation this mount works and gives the
-container full read and write access to the Docker Engine's configuration.
-
-Of course, bind mounts of host files continue to work as usual. For example,
-assuming a user configures Docker Desktop to file share her `$HOME` directory,
-she can bind mount it into the container:
-
-```console
-$ docker run -it --rm -v $HOME:/mnt alpine
-/ #
-```
-
-> [!NOTE]
->
-> By default, Enhanced Container Isolation won't allow bind mounting the Docker Engine socket
-> (`/var/run/docker.sock`) into a container, as doing so essentially grants the
-> container control of Docker Engine, thus breaking container isolation. However,
-> as some legitimate use cases require this, it's possible to relax
-> this restriction for trusted container images. See [Docker socket mount permissions](config.md#docker-socket-mount-permissions).
-
-## Vetting sensitive system calls
-
-Another feature of Enhanced Container Isolation is that it intercepts and vets a
-few highly sensitive system calls inside containers, such as `mount` and
-`umount`. This ensures that processes that have capabilities to execute these
-system calls can't use them to breach the container.
-
-For example, a container that has `CAP_SYS_ADMIN` (required to execute the
-`mount` system call) can't use that capability to change a read-only bind mount
-into a read-write mount:
-
-```console
-$ docker run -it --rm --cap-add SYS_ADMIN -v $HOME:/mnt:ro alpine
-/ # mount -o remount,rw /mnt /mnt
-mount: permission denied (are you root?)
-```
-
-Since the `$HOME` directory was mounted into the container's `/mnt` directory as
-read-only, it can't be changed from within the container to read-write, even if the container process has the capability to do so. This
-ensures container processes can't use `mount`, or `umount`, to breach the container's
-root filesystem.
-
-Note however that in the previous example the container can still create mounts
-within the container, and mount them read-only or read-write as needed. Those
-mounts are allowed since they occur within the container, and therefore don't
-breach it's root filesystem:
-
-```text
-/ # mkdir /root/tmpfs
-/ # mount -t tmpfs tmpfs /root/tmpfs
-/ # mount -o remount,ro /root/tmpfs /root/tmpfs
-
-/ # findmnt | grep tmpfs
-├─/root/tmpfs    tmpfs      tmpfs    ro,relatime,uid=100000,gid=100000
-
-/ # mount -o remount,rw /root/tmpfs /root/tmpfs
-/ # findmnt | grep tmpfs
-├─/root/tmpfs    tmpfs      tmpfs    rw,relatime,uid=100000,gid=100000
-```
-
-This feature, together with the user-namespace, ensures that even if a container
-process has all Linux capabilities they can't be used to breach the container.
-
-Finally, Enhanced Container Isolation does system call vetting in such a way
-that it does not affect the performance of containers in the great majority of
-cases. It intercepts control-path system calls that are rarely used in most
-container workloads but data-path system calls are not intercepted.
-
-## Filesystem user-ID mappings
-
-As mentioned, ECI enables the Linux
-user namespace on all containers. This ensures that the container's user-ID
-range (0->64K) maps to an unprivileged range of "real" user-IDs in the Docker
-Desktop Linux VM (e.g., 100000->165535).
-
-Moreover, each container gets an exclusive range of real user-IDs in the Linux
-VM (e.g., container 0 could get mapped to 100000->165535, container 2 to
-165536->231071, container 3 to 231072->296607, and so on). The same applies to
-group-IDs. In addition, if a container is stopped and restarted, there is no
-guarantee it will receive the same mapping as before. This is by design and
-further improves security.
-
-However this presents a problem when mounting Docker volumes into
-containers. Files written to such volumes have the real
-user/group-IDs and therefore won't be accessible across a container's
-start/stop/restart, or between containers due to the different real
-user-ID/group-ID of each container.
-
-To solve this problem, Sysbox uses "filesystem user-ID remapping" via the Linux
-Kernel's ID-mapped mounts feature (added in 2021) or an alternative `shiftsfs` module. These technologies map filesystem accesses from the container's
-real user-ID (e.g., range 100000->165535) to the range (0->65535) inside Docker
-Desktop's Linux VM. This way, volumes can now be mounted or shared across
-containers, even if each container uses an exclusive range of user-IDs. Users
-need not worry about the container's real user-IDs.
-
-Although filesystem user-ID remapping may cause containers to access
-Linux VM files mounted into the container with real user-ID 0, the
-[restricted mounts feature](#bind-mount-restrictions) ensures
-that sensitive Linux VM files can't be mounted into the container.
-
-## Procfs & sysfs emulation
-
-Another feature of Enhanced Container Isolation is that inside each container,
-the `/proc` and `/sys` filesystems are partially emulated. This
-serves several purposes, such as hiding sensitive host information inside the
-container and namespacing host kernel resources that are not yet namespaced by
-the Linux kernel itself.
-
-As a simple example, when Enhanced Container Isolation is enabled the
-`/proc/uptime` file shows the uptime of the container itself, not that of the
-Docker Desktop Linux VM:
-
-```console
-$ docker run -it --rm alpine
-/ # cat /proc/uptime
-5.86 5.86
-```
-
-In contrast, without Enhanced Container Isolation you see the uptime of
-the Docker Desktop Linux VM. Though this is a trivial example, it shows how
-Enhanced Container Isolation aims to prevent the Linux VM's configuration and
-information from leaking into the container so as to make it more difficult to
-breach the VM.
-
-In addition several other resources under `/proc/sys` that are not namespaced by
-the Linux Kernel are also emulated inside the container. Each container
-sees a separate view of each such resource and Sysbox reconciles the values
-across the containers when programming the corresponding Linux kernel setting.
-
-This has the advantage of enabling container workloads that would otherwise
-require truly privileged containers to access such non-namespaced kernel
-resources to run with Enhanced Container Isolation enabled, thereby improving
-security.
diff --git a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/how-eci-works.md b/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/how-eci-works.md
deleted file mode 100644
index 2a1c6c8b86e7..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/how-eci-works.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-description: How Enhanced Container Isolation works
-title: How does it work?
-keywords: set up, enhanced container isolation, rootless, security
-aliases:
- - /desktop/hardened-desktop/enhanced-container-isolation/how-eci-works/
-weight: 10
----
-
-{{< summary-bar feature_name="Hardened Docker Desktop" >}}
-
-Docker implements Enhanced Container Isolation by using the [Sysbox
-container runtime](https://github.com/nestybox/sysbox). Sysbox is a fork of the
-standard OCI runc runtime that was modified to enhance standard container isolation and
-workloads. For more details see [Under the hood](#under-the-hood).
-
-When [Enhanced Container Isolation is enabled](index.md#how-do-i-enable-enhanced-container-isolation), containers
-created by users through `docker run` or `docker create` are automatically
-launched using Sysbox instead of the standard OCI runc runtime. Users need not
-do anything else and can continue to use containers as usual. For exceptions,
-see [FAQs](faq.md).
-
-Even containers that use the insecure `--privileged` flag can now be run
-securely with Enhanced Container Isolation, such that they can no longer be used
-to breach the Docker Desktop Virtual Machine (VM) or other containers.
-
-> [!NOTE]
->
-> When Enhanced Container Isolation is enabled in Docker Desktop, the Docker CLI
-> `--runtime` flag is ignored. Docker's default runtime continues to be `runc`,
-> but all user containers are implicitly launched with Sysbox.
-
-Enhanced Container Isolation is not the same as [Docker Engine's userns-remap mode or Rootless Docker](#enhanced-container-isolation-versus-user-namespace-remapping).
-
-### Under the hood
-
-Sysbox enhances container isolation by using techniques such as:
-
-* Enabling the Linux user-namespace on all containers (root user in the container maps to an unprivileged user in the Linux VM).
-* Restricting the container from mounting sensitive VM directories.
-* Vetting sensitive system-calls between the container and the Linux kernel.
-* Mapping filesystem user/group IDs between the container's user-namespace and the Linux VM.
-* Emulating portions of the `/proc` and `/sys` filesystems inside the container.
-
-Some of these are made possible by recent advances in the Linux kernel which
-Docker Desktop now incorporates. Sysbox applies these techniques with minimal
-functional or performance impact to containers.
-
-These techniques complement Docker's traditional container security mechanisms
-such as using other Linux namespaces, cgroups, restricted Linux Capabilities,
-Seccomp, and AppArmor. They add a strong layer of isolation between the
-container and the Linux kernel inside the Docker Desktop VM.
-
-For more information, see [Key features and benefits](features-benefits.md).
-
-### Enhanced Container Isolation versus user namespace remapping
-
-The Docker Engine includes a feature called [userns-remap mode](/engine/security/userns-remap/)
-that enables the user namespace in all containers. However it suffers from a few
-[limitations](/engine/security/userns-remap/) and it's
-not supported within Docker Desktop.
-
-Userns-remap mode is similar to Enhanced Container Isolation in that both improve
-container isolation by leveraging the Linux user-namespace.
-
-However, Enhanced Container Isolation is much more advanced since it assigns
-exclusive user-namespace mappings per container automatically and adds several
-other [container isolation features](#under-the-hood) meant to secure Docker
-Desktop in organizations with stringent security requirements.
-
-### Enhanced Container Isolation versus Rootless Docker
-
-[Rootless Docker](/engine/security/rootless/) lets Docker Engine, and by
-extension the containers, to run without root privileges natively on a Linux host. This
-lets non-root users to install and run Docker natively on Linux.
-
-Rootless Docker is not supported within Docker Desktop. While it's a valuable
-feature when running Docker natively on Linux, its value within Docker Desktop
-is reduced since Docker Desktop runs the Docker Engine within a Linux VM. That
-is, Docker Desktop already lets non-root host users to run Docker and
-isolates the Docker Engine from the host using a virtual machine.
-
-Unlike Rootless Docker, Enhanced Container Isolation does not run Docker Engine
-within a Linux user-namespace. Rather it runs the containers generated by that
-engine within a user-namespace. This has the advantage of bypassing [the
-limitations](/engine/security/rootless/#known-limitations) of Rootless Docker
-and creates a stronger boundary between the containers and the Docker Engine.
-
-Enhanced Container Isolation is meant to ensure containers launched with Docker
-Desktop can't easily breach the Docker Desktop Linux VM and therefore modify
-security settings within it.
diff --git a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/limitations.md b/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/limitations.md
deleted file mode 100644
index 758e5389701d..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/limitations.md
+++ /dev/null
@@ -1,111 +0,0 @@
----
-title: Limitations
-description: Limitations of Enhanced Container Isolation
-keywords: enhanced container isolation, security, sysbox, known issues, Docker Desktop
-toc_max: 2
-weight: 50
----
-
-### ECI support for WSL
-
-> [!NOTE]
->
-> Docker Desktop requires WSL 2 version 1.1.3.0 or later. To get the current
-> version of WSL on your host, type `wsl --version`. If the command fails or if
-> it returns a version number prior to 1.1.3.0, update WSL to the latest version
-> by typing `wsl --update` in a Windows command or PowerShell terminal.
-
-ECI on WSL is not as secure as on Hyper-V because:
-
-- While ECI on WSL still hardens containers so that malicious workloads can't
-  easily breach Docker Desktop's Linux VM, ECI on WSL can't prevent Docker
-  Desktop users from breaching the Docker Desktop Linux VM. Such users can
-  trivially access that VM (as root) with the `wsl -d docker-desktop` command,
-  and use that access to modify Docker Engine settings inside the VM. This gives
-  Docker Desktop users control of the Docker Desktop VM and lets them bypass Docker Desktop configs set by administrators via the
-  [settings-management](../settings-management/_index.md) feature. In contrast,
-  ECI on Hyper-V does not let Docker Desktop users to breach the Docker
-  Desktop Linux VM.
-
-- With WSL 2, all WSL 2 distributions on the same Windows host share the same instance
-  of the Linux kernel. As a result, Docker Desktop can't ensure the integrity of
-  the kernel in the Docker Desktop Linux VM since another WSL 2 distribution could
-  modify shared kernel settings. In contrast, when using Hyper-V, the Docker
-  Desktop Linux VM has a dedicated kernel that is solely under the control of
-  Docker Desktop.
-
-The following table summarizes this.
-
-| Security feature                                   | ECI on WSL   | ECI on Hyper-V   | Comment               |
-| -------------------------------------------------- | ------------ | ---------------- | --------------------- |
-| Strongly secure containers                         | Yes          | Yes              | Makes it harder for malicious container workloads to breach the Docker Desktop Linux VM and host. |
-| Docker Desktop Linux VM protected from user access | No           | Yes              | On WSL, users can access Docker Engine directly or bypass Docker Desktop security settings. |
-| Docker Desktop Linux VM has a dedicated kernel     | No           | Yes              | On WSL, Docker Desktop can't guarantee the integrity of kernel level configs. |
-
-In general, using ECI with Hyper-V is more secure than with WSL 2. But WSL 2
-offers advantages for performance and resource utilization on the host machine,
-and it's an excellent way for users to run their favorite Linux distribution on
-Windows hosts and access Docker from within.
-
-### ECI protection for Docker builds with the "docker" driver
-
-Prior to Docker Desktop 4.30, `docker build` commands that use the buildx
-`docker` driver (the default) are not protected by ECI, in other words the build runs
-rootful inside the Docker Desktop VM.
-
-Starting with Docker Desktop 4.30, `docker build` commands that use the buildx
-`docker` driver are protected by ECI, except when Docker Desktop is configured to use WSL 2
-(on Windows hosts).
-
-Note that `docker build` commands that use the `docker-container` driver are
-always protected by ECI. 
-
-### Docker Build and Buildx have some restrictions
-
-With ECI enabled, Docker build `--network=host` and Docker Buildx entitlements
-(`network.host`, `security.insecure`) are not allowed. Builds that require
-these won't work properly.
-
-### Kubernetes pods are not yet protected
-
-When using the Docker Desktop integrated Kubernetes, pods are not yet protected
-by ECI. Therefore a malicious or privileged pod can compromise the Docker
-Desktop Linux VM and bypass security controls.
-
-As an alternative, you can use the [K8s.io KinD](https://kind.sigs.k8s.io/) tool
-with ECI. In this case, each Kubernetes node runs inside an ECI-protected
-container, thereby more strongly isolating the Kubernetes cluster away from the
-underlying Docker Desktop Linux VM (and Docker Engine within). No special
-arrangements are needed, just enable ECI and run the KinD tool as usual.
-
-### Extension containers are not yet protected
-
-Extension containers are also not yet protected by ECI. Ensure you extension
-containers come from trusted entities to avoid issues.
-
-### Docker Desktop Dev Environments are not yet protected
-
-Containers launched by the Docker Desktop Dev Environments feature are not yet
-protected.
-
-### Docker Debug containers are not yet protected
-
-[Docker Debug](https://docs.docker.com/reference/cli/docker/debug/) containers
-are not yet protected by ECI. 
-
-### Native Windows containers are not supported
-
-ECI only works when Docker Desktop is in Linux containers mode (the default,
-most common mode). It's not supported when Docker Desktop is configured in
-native Windows containers mode (i.e., it's not supported on Windows hosts, when
-Docker Desktop is switched from its default Linux mode to native Windows mode).
-
-### Use in production
-
-In general users should not experience differences between running a container
-in Docker Desktop with ECI enabled, which uses the Sysbox runtime, and running
-that same container in production, through the standard OCI `runc` runtime.
-
-However in some cases, typically when running advanced or privileged workloads in
-containers, users may experience some differences. In particular, the container
-may run with ECI but not with `runc`, or vice-versa.
diff --git a/content/manuals/security/for-admins/hardened-desktop/image-access-management.md b/content/manuals/security/for-admins/hardened-desktop/image-access-management.md
deleted file mode 100644
index 8dfaaddf22a1..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/image-access-management.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-description: Manage Docker Hub image access with Image Access Management, restricting developers to trusted images for enhanced security
-keywords: image, access, management, trusted content, permissions, Docker Business feature, security, admin
-title: Image Access Management
-tags: [admin]
-aliases:
- - /docker-hub/image-access-management/
- - /desktop/hardened-desktop/image-access-management/
- - /admin/organization/image-access/
- - /security/for-admins/image-access-management/
-weight: 40
----
-
-{{< summary-bar feature_name="Hardened Docker Desktop" >}}
-
-Image Access Management gives you control over which types of images, such as Docker Official Images, Docker Verified Publisher Images, or community images, your developers can pull from Docker Hub.
-
-For example, a developer, who is part of an organization, building a new containerized application could accidentally use an untrusted, community image as a component of their application. This image could be malicious and pose a security risk to the company. Using Image Access Management, the organization owner can ensure that the developer can only access trusted content like Docker Official Images, Docker Verified Publisher Images, or the organization’s own images, preventing such a risk.
-
-## Prerequisites
-
-You first need to [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) to ensure that all Docker Desktop developers authenticate with your organization. Since Image Access Management requires a Docker Business subscription, enforced sign-in guarantees that only authenticated users have access and that the feature consistently takes effect across all users, even though it may still work without enforced sign-in.
-
-## Configure
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-{{% admin-image-access product="admin" %}}
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-{{% admin-image-access product="hub" %}}
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## More resources
-
-- [Video: Hardened Desktop Image Access Management](https://www.youtube.com/watch?v=r3QRKHA1A5U)
diff --git a/content/manuals/security/for-admins/hardened-desktop/registry-access-management.md b/content/manuals/security/for-admins/hardened-desktop/registry-access-management.md
deleted file mode 100644
index 75f194954906..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/registry-access-management.md
+++ /dev/null
@@ -1,102 +0,0 @@
----
-description: Control access to approved registries with Registry Access Management, ensuring secure Docker Desktop usage
-keywords: registry, access, management, permissions, Docker Business feature, security, admin
-title: Registry Access Management
-tags: [admin]
-aliases:
- - /desktop/hardened-desktop/registry-access-management/
- - /admin/organization/registry-access/
- - /docker-hub/registry-access-management/
- - /security/for-admins/registry-access-management/
-weight: 30
----
-
-{{< summary-bar feature_name="Registry access management" >}}
-
-With Registry Access Management (RAM), administrators can ensure that their
-developers using Docker Desktop only access allowed registries. This is done
-through the Registry Access Management dashboard in Docker Hub or the
-Docker Admin Console.
-
-Registry Access Management supports both cloud and on-prem registries. This
-feature operates at the DNS level and therefore is compatible with all
-registries. You can add any hostname or domain name you’d like to include in the
-list of allowed registries. However, if the registry redirects to other domains
-such as `s3.amazon.com`, then you must add those domains to the list.
-
-Example registries administrators can allow include:
-
- - Docker Hub. This is enabled by default.
- - Amazon ECR
- - GitHub Container Registry
- - Google Container Registry
- - GitLab Container Registry
- - Nexus
- - Artifactory
-
-## Prerequisites
-
-You must [enforce sign-in](../enforce-sign-in/_index.md). For Registry Access
-Management to take effect, Docker Desktop users must authenticate to your
-organization. Enforcing sign-in ensures that your Docker Desktop developers
-always authenticate to your organization, even though they can authenticate
-without it and the feature will take effect. Enforcing sign-in guarantees the
-feature always takes effect.
-
-## Configure Registry Access Management permissions
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-{{% admin-registry-access product="admin" %}}
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-{{% admin-registry-access product="hub" %}}
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Verify the restrictions
-
-The new Registry Access Management policy takes effect after the developer
-successfully authenticates to Docker Desktop using their organization
-credentials. If a developer attempts to pull an image from a disallowed
-registry via the Docker CLI, they receive an error message that the organization
-has disallowed this registry.
-
-## Caveats
-
-There are certain limitations when using Registry Access Management:
-
-- You can add up to 100 registries/domains.
-- Windows image pulls and image builds are not restricted by default. For
-Registry Access Management to take effect on Windows Container mode, you must
-allow the Windows Docker daemon to use Docker Desktop's internal proxy by
-selecting the [Use proxy for Windows Docker daemon](/manuals/desktop/settings-and-maintenance/settings.md#proxies)
-setting.
-- Builds such as `docker buildx` using a Kubernetes driver are not restricted.
-- Builds such as `docker buildx` using a custom docker-container driver are not
-restricted.
-- Blocking is DNS-based. You must use a registry's access control mechanisms to
-distinguish between “push” and “pull”.
-- WSL 2 requires at least a 5.4 series Linux kernel (this does not apply to
-earlier Linux kernel series).
-- Under the WSL 2 network, traffic from all Linux distributions is restricted.
-This will be resolved in the updated 5.15 series Linux kernel.
-- Images pulled by Docker Desktop when Docker Debug or Kubernetes is enabled,
-are not restricted by default even if Docker Hub is blocked by RAM.
-- If Docker Hub access is restricted by RAM, pulls on images originating from Docker Hub are restricted even if the image has been previously cached by a registry mirror. See [Using Registry Access Management (RAM) with a registry mirror](/manuals/docker-hub/image-library/mirror.md).
-
-Also, Registry Access Management operates on the level of hosts, not IP
-addresses. Developers can bypass this restriction within their domain
-resolution, for example by running Docker against a local proxy or modifying
-their operating system's `sts` file. Blocking these forms of manipulation is
-outside the remit of Docker Desktop.
-
-## More resources
-
-- [Video: Hardened Desktop Registry Access Management](https://www.youtube.com/watch?v=l9Z6WJdJC9A)
diff --git a/content/manuals/security/for-admins/hardened-desktop/settings-management/_index.md b/content/manuals/security/for-admins/hardened-desktop/settings-management/_index.md
deleted file mode 100644
index 48fc13100a01..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/settings-management/_index.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-description: Understand how Settings Management works, who it is for, and what the
-  benefits are
-keywords: Settings Management, rootless, docker desktop, hardened desktop
-tags: [admin]
-title: What is Settings Management?
-linkTitle: Settings Management
-aliases:
- - /desktop/hardened-desktop/settings-management/
-weight: 10
----
-
-{{< summary-bar feature_name="Hardened Docker Desktop" >}}
-
-Settings Management helps you control key Docker Desktop settings, like proxies and network configurations, on your developers' machines within your organization.
-
-For an extra layer of security, you can also use Settings Management to enable and lock in [Enhanced Container Isolation](../enhanced-container-isolation/_index.md), which prevents containers from modifying any Settings Management configurations.
-
-## Who is it for?
-
-- For organizations that want to configure Docker Desktop to be within their organization's centralized control.
-- For organizations that want to create a standardized Docker Desktop environment at scale.
-- For Docker Business customers who want to confidently manage their use of Docker Desktop within tightly regulated environments.
-
-## How does it work?
-
-You can configure several Docker Desktop settings using either:
-
- - An `admin-settings.json` file. This file is located on the Docker Desktop host and can only be accessed by developers with root or administrator privileges.
- - Creating a settings policy in the Docker Admin Console.
-
-Settings that are defined by an administrator override any previous values set by developers and ensure that these cannot be modified.
-
-## What features can I configure with Settings Management?
-
-Using the `admin-settings.json` file, you can:
-
-- Turn on and lock in [Enhanced Container Isolation](../enhanced-container-isolation/_index.md)
-- Configure HTTP proxies
-- Configure network settings
-- Configure Kubernetes settings
-- Enforce the use of WSL 2 based engine or Hyper-V
-- Enforce the use of Rosetta for x86_64/amd64 emulation on Apple Silicon
-- Configure Docker Engine
-- Turn off Docker Desktop's ability to checks for updates
-- Turn off Docker Extensions
-- Turn off Docker Scout SBOM indexing
-- Turn off beta and experimental features
-- Turn off Docker AI ([Ask Gordon](/manuals/ai/gordon/_index.md))
-- Turn off Docker Desktop's onboarding survey
-- Control whether developers can use the Docker terminal
-- Control the file sharing implementation for your developers on macOS
-- Specify which paths your developers can add file shares to
-- Configure Air-gapped containers
-
-For more details on the syntax and options, see [Configure Settings Management](configure-json-file.md).
-
-## How do I set up and enforce Settings Management?
-
-You first need to [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) to ensure that all Docker Desktop developers authenticate with your organization. Since the Settings Management feature requires a Docker Business subscription, enforced sign-in guarantees that only authenticated users have access and that the feature consistently takes effect across all users, even though it may still work without enforced sign-in.
-
-Next, you must either:
- - Manually [create and configure the `admin-settings.json` file](configure-json-file.md), or use the `--admin-settings` installer flag on [macOS](/manuals/desktop/setup/install/mac-install.md#install-from-the-command-line) or [Windows](/manuals/desktop/setup/install/windows-install.md#install-from-the-command-line) to automatically create the `admin-settings.json` and save it in the correct location.
- - Fill out the **Settings policy** creation form in the [Docker Admin Console](configure-admin-console.md).
-
-Once this is done, Docker Desktop developers receive the changed settings when they either:
-- Quit, re-launch, and sign in to Docker Desktop
-- Launch and sign in to Docker Desktop for the first time
-
-To avoid disrupting your developers' workflows, Docker doesn't automatically require that developers re-launch and re-authenticate once a change has been made.
-
-## What do developers see when the settings are enforced?
-
-Enforced settings appear grayed out in Docker Desktop. They can't be edited via the Docker Desktop Dashboard, CLI, or `settings-store.json` (or `settings.json` for Docker Desktop 4.34 and earlier).
-
-In addition, if Enhanced Container Isolation is enforced, developers can't use privileged containers or similar techniques to modify enforced settings within the Docker Desktop Linux VM. For example, they can't reconfigure proxy and networking, or Docker Engine.
-
-## What's next?
-
-- [Configure Settings Management with a `.json` file](configure-json-file.md)
-- [Configure Settings Management with the Docker Admin Console](configure-admin-console.md)
diff --git a/content/manuals/security/for-admins/hardened-desktop/settings-management/compliance-reporting.md b/content/manuals/security/for-admins/hardened-desktop/settings-management/compliance-reporting.md
deleted file mode 100644
index f7304b448455..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/settings-management/compliance-reporting.md
+++ /dev/null
@@ -1,147 +0,0 @@
----
-description: Understand how to use the Desktop settings reporting dashboard
-keywords: Settings Management, docker desktop, hardened desktop, reporting, compliance
-title: Desktop settings reporting
-linkTitle: Desktop settings reporting
-weight: 30
-params:
-  sidebar:
-    badge:
-      color: violet
-      text: EA
----
-
-{{< summary-bar feature_name="Compliance reporting" >}}
-
-Desktop settings reporting is a feature of Desktop Settings Management that
-tracks and reports user compliance with the settings policies that are assigned
-to them. This lets administrators track the application of settings and
-monitor what actions they need to take to make users compliant.
-
-This guide provides steps for accessing Desktop settings reporting, viewing
-compliance status, and resolving non-compliant users.
-
-## Access Desktop settings reporting
-
-> [!IMPORTANT]
->
-> Desktop settings reporting is in Early Access and is being rolled out
-> gradually. You may not see this setting in the Admin Console yet.
-
-1. Sign in to the [Admin Console](https://app.docker.com/admin).
-2. Select your organization or company from the **Choose profile** page.
-3. Under Docker Desktop, select **Reporting**.
-
-This opens the Desktop settings reporting page. From here you can:
-
-- Use the **Search** field to search by username or email address
-- Filter by policies
-- Hide or un-hide compliant users
-- View a user’s compliance status and what policy is assigned to the user
-- Download a CSV file of user compliance information
-
-## View compliance status
-
-> [!WARNING]
->
-> Users on Docker Desktop versions older than 4.40 may appear non-compliant
-> because older versions can't report compliance. To ensure accurate
-> compliance status, users must update to Docker Desktop version 4.40 and later.
-
-1. Sign in to the [Admin Console](https://app.docker.com/admin).
-2. Select your organization or company from the **Choose profile** page.
-3. Under **Docker Desktop**, select **Reporting**. By default, non-compliant users
-are displayed.
-4. Optional. Select the **Hide compliant users** checkbox to show both compliant
-and non-compliant users.
-5. Use the **Search** field to search by username or email address.
-6. Hover over a user’s compliance status indicator to quickly view their status.
-7. Select a username to view more details about their compliance status, and for
-steps to resolve non-compliant users.
-
-## Understand compliance status
-
-Docker evaluates compliance status based on:
-
-- Compliance status: Whether a user has fetched and applied the latest settings. This is the primary label shown on the reporting page.
-- Domain status: Whether the user's email matches a verified domain.
-- Settings status: Whether a settings policy is applied to the user.
-
-The combination of these statuses determines what actions you need to take.
-
-### Compliance status reference
-
-This reference explains how each status is determined in the reporting dashboard
-based on user domain and settings data. The Admin Console displays the
-highest-priority applicable status according to the following rules.
-
-**Compliance status**
-
-| Compliance status | What it means |
-|-------------------|---------------|
-| Uncontrolled domain | The user's email domain is not verified. |
-| No policy assigned | The user does not have any policy assigned to them. |
-| Non-compliant | The user fetched the correct policy, but hasn't applied it. |
-| Outdated | The user fetched a previous version of the policy. |
-| Unknown | The user hasn't fetched any policy yet, or their compliance can't be determined. |
-| Compliant | The user fetched and applied the latest assigned policy. |
-
-**Domain status**
-
-This reflects how the user’s email domain is evaluated based on the organization’s domain setup.
-
-| Domain status | What it means |
-|---------------|---------------|
-| Verified | The user’s email domain is verified. |
-| Guest user | The user's email domain is not verified. |
-| Domainless | Your organization has no verified domains, and the user's domain is unknown. |
-| Unknown user | Your organization has verified domains, but the user's domain is unknown. |
-
-**Settings status**
-
-This shows whether and how the user is assigned a settings policy.
-
-| Settings status | What it means |
-|-----------------|---------------|
-| Global policy | The user is assigned your organzation's default policy. |
-| User policy | The user is assigned a specific custom policy. |
-| No policy assigned | The user is not assigned to any policy. |
-
-## Resolve compliance status
-
-To resolve compliance status, you must view a user's compliance status details
-by selecting their username from the Desktop settings reporting page.
-These details include the following information:
-
-- **Compliance status**: Indicates whether the user is compliant with the
-settings applied to them
-- **Domain status**: Indicates whether the user’s email address is associated
-with a verified domain
-- **Settings status**: Indicates whether the user has settings applied to them
-- **Resolution steps**: If a user is non-compliant, this provides information
-on how to resolve the user’s compliance status
-
-### Compliant
-
-When a user is compliant, a **Compliant** icon appears next to their name on the
-Desktop settings reporting dashboard. Select a compliant user to open their
-compliance status details. Compliant users have the following status details:
-
-- **Compliance status**: Compliant
-- **Domain status**: Verified
-- **Settings status**: Global policy or user policy
-- **User is compliant** indicator
-
-No resolution steps are needed for compliant users.
-
-### Non-compliant
-
-When a user is non-compliant, a **Non-compliant** or **Unknown** icon appears
-next to their name on the Desktop settings reporting dashboard. Non-compliant
-users must have their compliance status resolved:
-
-1. Select a username from the Desktop settings reporting dashboard.
-2. On the compliance status details page, follow the resolution steps provided
-to resolve the compliance status.
-3. Refresh the page to ensure the resolution steps resolved the compliance
-status.
diff --git a/content/manuals/security/for-admins/hardened-desktop/settings-management/configure-admin-console.md b/content/manuals/security/for-admins/hardened-desktop/settings-management/configure-admin-console.md
deleted file mode 100644
index 646685fc950a..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/settings-management/configure-admin-console.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-description: How to configure Settings Management for Docker Desktop using the Docker Admin Console
-keywords: admin, controls, rootless, enhanced container isolation
-title: Configure Settings Management with the Admin Console
-linkTitle: Use the Admin Console
-weight: 20
----
-
-{{< summary-bar feature_name="Admin Console" >}}
-
-This page contains information for administrators on how to configure Settings Management with the Docker Admin Console. You can specify and lock configuration parameters to create a standardized Docker Desktop environment across your Docker company or organization.
-
-## Prerequisites
-
-- [Download and install Docker Desktop 4.36.0 or later](/manuals/desktop/release-notes.md).
-- [Verify your domain](/manuals/security/for-admins/single-sign-on/configure.md#step-one-add-and-verify-your-domain).
-- [Enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md). The Settings Management feature requires a Docker Business
-subscription, therefore your Docker Desktop users must authenticate to your
-organization for configurations to take effect.
-
-## Create a settings policy
-
-1. Within the [Docker Admin Console](https://app.docker.com/admin) navigate to the company or organization you want to define a settings policy for.
-2. Under the **Docker Desktop** section, select **Settings Management**.
-3. Select **Create a settings policy**.
-4. Give your settings policy a name and an optional description.
-
-   > [!TIP]
-   >
-   > If you have already configured Settings Management with an `admin-settings.json` file for an organization, you can upload it using the **Upload existing settings** button which then automatically populates the form for you.
-   >
-   > Settings policies deployed via the Docker Admin Console take precedence over manually deployed `admin-settings.json` files.
-
-5. Assign the setting policy to all your users within the company or organization, or specific users.
-
-   > [!NOTE]
-   >
-   > If a settings policy is assigned to all users, it sets the policy as the global default policy. You can only have one global settings policy at a time.
-   > If a user already has a user-specific settings policy assigned, the user-specific policy takes precedence over a global policy.
-
-   > [!TIP]
-   >
-   > Before setting a global settings policy, it is recommended that you first test it as a user-specific policy to make sure you're happy with the changes before proceeding.
-
-6. Configure the settings for the policy. Go through each setting and select your chosen setting state. You can choose:
-   - **User-defined**. Your developers are able to control and change this setting.
-   - **Always enabled**. This means the setting is turned on and your users won't be able to edit this setting from Docker Desktop or the CLI.
-   - **Enabled**. The setting is turned on and users can edit this setting from Docker Desktop or the CLI.
-   - **Always disabled**. This means the setting is turned off and your users won't be able to edit this setting from Docker Desktop or the CLI.
-   - **Disabled**. The setting is turned off and users can edit this setting from Docker Desktop or the CLI.
-7. Select **Create**
-
-For the settings policy to take effect:
-- On a new install, users need to launch Docker Desktop and authenticate to their organization.
-- On an existing install, users need to quit Docker Desktop through the Docker menu, and then re-launch Docker Desktop. If they are already signed in, they don't need to sign in again for the changes to take effect.
-
-  > [!IMPORTANT]
-  >
-  > Selecting **Restart** from the Docker menu isn't enough as it only restarts some components of Docker Desktop.
-
-To avoid disrupting your users' workflows, Docker doesn't automatically require that users re-launch once a change has been made.
-
-> [!NOTE]
->
-> Settings are synced to Docker Desktop and the CLI when a user is signed in and starts Docker Desktop, and then every 60 minutes.
-
-If your settings policy needs to be rolled back, either delete the policy or edit the policy to set individual settings to **User-defined**.
-
-## Settings policy actions
-
-From the **Actions** menu on the **Settings Management** page in the Docker Admin Console, you can:
-
-- Edit or delete an existing settings policy.
-- Export a settings policy as an `admin-settings.json` file.
-- Promote a policy that is applied to a select group of users, to be the new global default policy for all users.
\ No newline at end of file
diff --git a/content/manuals/security/for-admins/hardened-desktop/settings-management/configure-json-file.md b/content/manuals/security/for-admins/hardened-desktop/settings-management/configure-json-file.md
deleted file mode 100644
index 0096692d5a89..000000000000
--- a/content/manuals/security/for-admins/hardened-desktop/settings-management/configure-json-file.md
+++ /dev/null
@@ -1,310 +0,0 @@
----
-description: How to configure Settings Management for Docker Desktop
-keywords: admin, controls, rootless, enhanced container isolation
-title: Configure Settings Management with a JSON file
-linkTitle: Use a JSON file
-weight: 10
-aliases:
- - /desktop/hardened-desktop/settings-management/configure/
- - /security/for-admins/hardened-desktop/settings-management/configure/
----
-
-{{< summary-bar feature_name="Hardened Docker Desktop" >}}
-
-This page contains information on how to configure Settings Management with an `admin-settings.json` file. You can specify and lock configuration parameters to create a standardized Docker Desktop environment across your company or organization.
-
-Settings Management is designed specifically for organizations who don’t give developers root access to their machines.
-
-## Prerequisites
-
-You must [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) to ensure that all Docker Desktop users authenticate with your organization.
-
-Settings management requires a Docker Business subscription. Docker Desktop verifies the user's authentication and licensing before applying any settings from the `admin-settings.json` file. The settings file will not take effect unless both authentication and license checks pass. These checks ensure that only licensed users receive managed settings.
-
-> [!IMPORTANT]
->
-> If a user is not signed in, or their Docker ID does not belong to an organization with a Docker Business subscription, Docker Desktop ignores the `admin-settings.json` file.
-
-
-## Known limitations
-
-The `admin-settings.json` file requires users to authenticate with Docker Hub and be a member
-of an organization with a Docker Business subscription. This means the file does not work in:
-
-- Air-grapped or offline environments where Docker Desktop can't authenticate with Docker Hub.
-- Restricted environments where SSO and cloud-based authentication are not permitted.
-
-
-## Step one: Create the `admin-settings.json` file and save it in the correct location
-
-You can either use the `--admin-settings` installer flag on [macOS](/manuals/desktop/setup/install/mac-install.md#install-from-the-command-line) or [Windows](/manuals/desktop/setup/install/windows-install.md#install-from-the-command-line) to automatically create the `admin-settings.json` and save it in the correct location, or set it up manually.
-
-To set it up manually:
-1. Create a new, empty JSON file and name it `admin-settings.json`.
-2. Save the `admin-settings.json` file on your developers' machines in the following locations:
-   - Mac: `/Library/Application\ Support/com.docker.docker/admin-settings.json`
-   - Windows: `C:\ProgramData\DockerDesktop\admin-settings.json`
-   - Linux: `/usr/share/docker-desktop/admin-settings.json`
-
-   By placing this file in a protected directory, developers are unable to modify it.
-
-   > [!IMPORTANT]
-   >
-   > It is assumed that you have the ability to push the `admin-settings.json` settings file to the locations specified through a device management software such as [Jamf](https://www.jamf.com/lp/en-gb/apple-mobile-device-management-mdm-jamf-shared/?attr=google_ads-brand-search-shared&gclid=CjwKCAjw1ICZBhAzEiwAFfvFhEXjayUAi8FHHv1JJitFPb47C_q_RCySTmF86twF1qJc_6GST-YDmhoCuJsQAvD_BwE).
-
-## Step two: Configure the settings you want to lock in
-
-> [!NOTE]
->
-> Some of the configuration parameters only apply to certain platforms or to specific Docker Desktop versions. This is highlighted in the following table.
-
-The `admin-settings.json` file requires a nested list of configuration parameters, each of which must contain the `locked` parameter. You can add or remove configuration parameters as per your requirements.
-
-If `locked: true`, users aren't able to edit this setting from Docker Desktop or the CLI.
-
-If `locked: false`, it's similar to setting a factory default in that:
-   - For new installs, `locked: false` pre-populates the relevant settings in the Docker Desktop Dashboard, but users are able to modify it.
-
-   - If Docker Desktop is already installed and being used, `locked: false` is ignored. This is because existing users of Docker Desktop may have already updated a setting, which in turn will have been written to the relevant config file, for example the `settings-store.json` (or `settings.json` for Docker Desktop versions 4.34 and earlier) or `daemon.json`. In these instances, the user's preferences are respected and the values aren't altered. These can be controlled by setting `locked: true`.
-
-The following `admin-settings.json` code and table provides an example of the required syntax and descriptions for parameters and values:
-
-```json {collapse=true}
-{
-  "configurationFileVersion": 2,
-  "exposeDockerAPIOnTCP2375": {
-    "locked": true,
-    "value": false
-  },
-  "proxy": {
-    "locked": true,
-    "mode": "system",
-    "http": "",
-    "https": "",
-    "exclude": [],
-    "windowsDockerdPort": 65000,
-    "enableKerberosNtlm": false
-  },
-  "containersProxy": {
-    "locked": true,
-    "mode": "manual",
-    "http": "",
-    "https": "",
-    "exclude": [],
-    "pac":"",
-    "transparentPorts": ""
-  },
-  "enhancedContainerIsolation": {
-    "locked": true,
-    "value": true,
-    "dockerSocketMount": {
-      "imageList": {
-        "images": [
-          "docker.io/localstack/localstack:*",
-          "docker.io/testcontainers/ryuk:*"
-        ]
-      },
-      "commandList": {
-        "type": "deny",
-        "commands": ["push"]
-      }
-    }
-  },
-  "linuxVM": {
-    "wslEngineEnabled": {
-      "locked": false,
-      "value": false
-    },
-    "dockerDaemonOptions": {
-      "locked": false,
-      "value":"{\"debug\": false}"
-    },
-    "vpnkitCIDR": {
-      "locked": false,
-      "value":"192.168.65.0/24"
-    }
-  },
-  "kubernetes": {
-     "locked": false,
-     "enabled": false,
-     "showSystemContainers": false,
-     "imagesRepository": ""
-  },
-  "windowsContainers": {
-    "dockerDaemonOptions": {
-      "locked": false,
-      "value":"{\"debug\": false}"
-    }
-  },
-  "disableUpdate": {
-    "locked": false,
-    "value": false
-  },
-  "analyticsEnabled": {
-    "locked": false,
-    "value": true
-  },
-  "extensionsEnabled": {
-    "locked": true,
-    "value": false
-  },
-  "scout": {
-    "locked": false,
-    "sbomIndexing": true,
-    "useBackgroundIndexing": true
-  },
-  "allowExperimentalFeatures": {
-    "locked": false,
-    "value": false
-  },
-  "allowBetaFeatures": {
-    "locked": false,
-    "value": false
-  },
-  "blockDockerLoad": {
-    "locked": false,
-    "value": true
-  },
-  "filesharingAllowedDirectories": [
-    {
-      "path": "$HOME",
-      "sharedByDefault": true
-    },
-    {
-      "path":"$TMP",
-      "sharedByDefault": false
-    }
-  ],
-  "useVirtualizationFrameworkVirtioFS": {
-    "locked": true,
-    "value": true
-  },
-  "useVirtualizationFrameworkRosetta": {
-    "locked": true,
-    "value": true
-  },
-  "useGrpcfuse": {
-    "locked": true,
-    "value": true
-  },
-  "displayedOnboarding": {
-    "locked": true,
-    "value": true
-  },
-  "desktopTerminalEnabled": {
-    "locked": false,
-    "value": false
-  }
-}
-```
-
-### General
-
-|Parameter|OS|Description|Version|
-|:-------------------------------|---|:-------------------------------|---|
-|`configurationFileVersion`|   |Specifies the version of the configuration file format.|   |
-|`analyticsEnabled`|  |If `value` is set to false, Docker Desktop doesn't send usage statistics to Docker. |  |
-|`disableUpdate`|  |If `value` is set to true, checking for and notifications about Docker Desktop updates is disabled.|  |
-|`extensionsEnabled`|  |If `value` is set to false, Docker extensions are disabled. |  |
-| `blockDockerLoad` | | If `value` is set to `true`, users are no longer able to run [`docker load`](/reference/cli/docker/image/load/) and receive an error if they try to.|  |
-| `displayedOnboarding` |  | If `value` is set to `true`, the onboarding survey will not be displayed to new users. Setting `value` to `false` has no effect. |  Docker Desktop version 4.30 and later |
-| `desktopTerminalEnabled` |  | If `value` is set to `false`, developers cannot use the Docker terminal to interact with the host machine and execute commands directly from Docker Desktop. |  |
-|`exposeDockerAPIOnTCP2375`| Windows only| Exposes the Docker API on a specified port. If `value` is set to true, the Docker API is exposed on port 2375. Note: This is unauthenticated and should only be enabled if protected by suitable firewall rules.|  |
-
-### File sharing and emulation
-
-|Parameter|OS|Description|Version|
-|:-------------------------------|---|:-------------------------------|---|
-| `filesharingAllowedDirectories` |  | Specify which paths your developers can add file shares to. Also accepts `$HOME`, `$TMP`, or `$TEMP` as `path` variables. When a path is added, its subdirectories are allowed. If `sharedByDefault` is set to `true`, that path will be added upon factory reset or when Docker Desktop first starts. |  |
-| `useVirtualizationFrameworkVirtioFS`|  macOS only | If `value` is set to `true`, VirtioFS is set as the file sharing mechanism. Note: If both `useVirtualizationFrameworkVirtioFS` and `useGrpcfuse` have `value` set to `true`, VirtioFS takes precedence. Likewise, if both `useVirtualizationFrameworkVirtioFS` and `useGrpcfuse` have `value` set to `false`, osxfs is set as the file sharing mechanism. |  |
-| `useGrpcfuse` | macOS only | If `value` is set to `true`, gRPC Fuse is set as the file sharing mechanism. |  |
-| `useVirtualizationFrameworkRosetta`|  macOS only | If `value` is set to `true`, Docker Desktop turns on Rosetta to accelerate x86_64/amd64 binary emulation on Apple Silicon. Note: This also automatically enables `Use Virtualization framework`. | Docker Desktop version 4.29 and later. |
-
-### Docker Scout
-
-|Parameter|OS|Description|Version|
-|:-------------------------------|---|:-------------------------------|---|
-|`scout`| | Setting `useBackgroundIndexing` to `false` disables automatic indexing of images loaded to the image store. Setting `sbomIndexing` to `false` prevents users from being able to index image by inspecting them in Docker Desktop or using `docker scout` CLI commands. |  |
-
-### Proxy
-
-|Parameter|OS|Description|Version|
-|:-------------------------------|---|:-------------------------------|---|
-|`proxy`|   |If `mode` is set to `system` instead of `manual`, Docker Desktop gets the proxy values from the system and ignores and values set for `http`, `https` and `exclude`. Change `mode` to `manual` to manually configure proxy servers. If the proxy port is custom, specify it in the `http` or `https` property, for example `"https": "http://myotherproxy.com:4321"`. The `exclude` property specifies a comma-separated list of hosts and domains to bypass the proxy. |  |
-|&nbsp; &nbsp; &nbsp; &nbsp;`windowsDockerdPort`| Windows only | Exposes Docker Desktop's internal proxy locally on this port for the Windows Docker daemon to connect to. If it is set to 0, a random free port is chosen. If the value is greater than 0, use that exact value for the port. The default value is -1 which disables the option. |  |
-|&nbsp; &nbsp; &nbsp; &nbsp;`enableKerberosNtlm`|  |When set to `true`, Kerberos and NTLM authentication is enabled. Default is `false`. For more information, see the settings documentation. | Docker Desktop version 4.32 and later. |
-
-### Container proxy
-
-|Parameter|OS|Description|Version|
-|:-------------------------------|---|:-------------------------------|---|
-|`containersProxy` | | Creates air-gapped containers. For more information see [Air-Gapped Containers](../air-gapped-containers.md).| Docker Desktop version 4.29 and later. |
-
-### Linux VM
-
-|Parameter|OS|Description|Version|
-|:-------------------------------|---|:-------------------------------|---|
-| `linuxVM` |   |Parameters and settings related to Linux VM options - grouped together here for convenience. |  |
-| &nbsp; &nbsp; &nbsp; &nbsp;`wslEngineEnabled`  | Windows only | If `value` is set to true, Docker Desktop uses the WSL 2 based engine. This overrides anything that may have been set at installation using the `--backend=<backend name>` flag. |  |
-| &nbsp; &nbsp; &nbsp; &nbsp;`dockerDaemonOptions` |  |If `value` is set to true, it overrides the options in the Docker Engine config file. See the [Docker Engine reference](/reference/cli/dockerd/#daemon-configuration-file). Note that for added security, a few of the config attributes may be overridden when Enhanced Container Isolation is enabled. |  |
-| &nbsp; &nbsp; &nbsp; &nbsp;`vpnkitCIDR` |  |Overrides the network range used for vpnkit DHCP/DNS for `*.docker.internal`  |  |
-
-### Windows containers
-
-|Parameter|OS|Description|Version|
-|:-------------------------------|---|:-------------------------------|---|
-| `windowsContainers` |  | Parameters and settings related to `windowsContainers` options - grouped together here for convenience.  |  |
-| &nbsp; &nbsp; &nbsp; &nbsp;`dockerDaemonOptions` |  | Overrides the options in the Linux daemon config file. See the [Docker Engine reference](/reference/cli/dockerd/#daemon-configuration-file).|  |
-
-> [!NOTE]
->
-> This setting is not available to configure via the Docker Admin Console.
-
-### Kubernetes
-
-|Parameter|OS|Description|Version|
-|:-------------------------------|---|:-------------------------------|---|
-|`kubernetes`|  | If `enabled` is set to true, a Kubernetes single-node cluster is started when Docker Desktop starts. If `showSystemContainers` is set to true, Kubernetes containers are displayed in the Docker Desktop Dashboard and when you run `docker ps`.  `imagesRepository` lets you specify which repository Docker Desktop pulls the Kubernetes images from. For example, `"imagesRepository": "registry-1.docker.io/docker"`.  |  |
-
-> [!NOTE]
->
-> When using the `imagesRepository` setting and Enhanced Container Isolation (ECI), add the following images to the [ECI Docker socket mount image list](#enhanced-container-isolation):
->
-> `<custom-image-repo>/desktop-cloud-provider-kind:*`
-> `<custom-image-repo>/desktop-containerd-registry-mirror:*`
->
-> These containers mount the Docker socket, so you must add the images to the ECI images list. If not, ECI will block the mount and Kubernetes won't start.
-
-### Features in development
-
-|Parameter|OS|Description|Version|
-|:-------------------------------|---|:-------------------------------|---|
-| `allowExperimentalFeatures`| | If `value` is set to `false`, experimental features are disabled.|  |
-| `allowBetaFeatures`| | If `value` is set to `false`, beta features are disabled.|  |
-| `enableDockerAI` | | If `value` is set to `false`, Docker AI (Ask Gordon) features are disabled. |  |
-
-### Enhanced Container Isolation
-
-|Parameter|OS|Description|Version|
-|:-------------------------------|---|:-------------------------------|---|
-|`enhancedContainerIsolation`|  | If `value` is set to true, Docker Desktop runs all containers as unprivileged, via the Linux user-namespace, prevents them from modifying sensitive configurations inside the Docker Desktop VM, and uses other advanced techniques to isolate them. For more information, see [Enhanced Container Isolation](../enhanced-container-isolation/_index.md).|  |
-| &nbsp; &nbsp; &nbsp; &nbsp;`dockerSocketMount` |  | By default, enhanced container isolation blocks bind-mounting the Docker Engine socket into containers (e.g., `docker run -v /var/run/docker.sock:/var/run/docker.sock ...`). This lets you relax this in a controlled way. See [ECI Configuration](../enhanced-container-isolation/config.md) for more info. |  |
-| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; `imageList` |  | Indicates which container images are allowed to bind-mount the Docker Engine socket. |  |
-| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; `commandList` |  | Restricts the commands that containers can issue via the bind-mounted Docker Engine socket. |  |
-
-## Step three: Re-launch Docker Desktop
-
-> [!NOTE]
->
-> Test the changes made through the `admin-settings.json` file locally to see if the settings work as expected.
-
-For settings to take effect:
-- On a new install, developers need to launch Docker Desktop and authenticate to their organization.
-- On an existing install, developers need to quit Docker Desktop through the Docker menu, and then re-launch Docker Desktop. If they are already signed in, they don't need to sign in again for the changes to take effect.
-  > [!IMPORTANT]
-  >
-  > Selecting **Restart** from the Docker menu isn't enough as it only restarts some components of Docker Desktop.
-
-So as not to disrupt your developers' workflow, Docker doesn't automatically mandate that developers re-launch and re-authenticate once a change has been made.
-
-In Docker Desktop, developers see the relevant settings grayed out.
diff --git a/content/manuals/security/for-admins/provisioning/_index.md b/content/manuals/security/for-admins/provisioning/_index.md
deleted file mode 100644
index 70f69fdcc649..000000000000
--- a/content/manuals/security/for-admins/provisioning/_index.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-description: Learn about provisioning users for your SSO configuration.
-keywords: provision users, provisioning, JIT, SCIM, group mapping, sso, docker hub, hub, docker admin, admin, security
-title: Provision users
-linkTitle: Provision
-weight: 20
----
-
-{{< summary-bar feature_name="SSO" >}}
-
-Once you've configured your SSO connection, the next step is to provision users. This process ensures that users can access your organization.
-This guide provides an overview of user provisioning and supported provisioning methods.
-
-## What is provisioning?
-
-Provisioning helps manage users by automating tasks like creating, updating, and deactivating users based
-on data from your identity provider (IdP). There are three methods for user provisioning, with benefits for
-different organization needs:
-
-| Provisioning method | Description | Default setting in Docker | Recommended for |
-| :--- | :--- | :------------- | :--- |
-| Just-in-Time (JIT) | Automatically create and provisions user accounts when they first sign in via SSO | Enabled by default | Best for organizations who need minimal setup, who have smaller teams, or low-security environments |
-| System for Cross-domain Identity Management (SCIM) | Continuously syncs user data between your IdP and Docker, ensuring user attributes remain updated without requiring manual updates | Disabled by default | Best for larger organizations or environments with frequent changes in user information or roles |
-| Group mapping | Maps user groups from your IdP to specific roles and permissions within Docker, enabling fine-tuned access control based on group membership | Disabled by default | Best for organizations that require strict access control and for managing users based on their roles and permissions |
-
-## Default provisioning setup
-
-By default, Docker enables JIT provisioning when you configure an SSO connection. With JIT enabled, user accounts are automatically created the first time a user signs in using your SSO flow.
-
-JIT provisioning may not provide the level of control or security some organizations need. In such cases, SCIM or group mapping can be configured to give administrators more control over user access and attributes.
-
-## SSO attributes
-
-When a user signs in through SSO, Docker obtains several attributes from your IdP to manage the user's identity and permissions. These attributes include:
-- **Email address**: The unique identifier for the user
-- **Full name**: The user's complete name
-- **Groups**: Optional. Used for group-based access control
-- **Docker Org**: Optional. Specifies the organization the user belongs to
-- **Docker Team**: Optional. Defines the team the user belongs to within the organization
-- **Docker Role**: Optional. Determines the user's permission within Docker
-- **Docker session minutes**: Optional. Sets the duration of a user’s session before they must re-authenticate with their identity provider (IdP). The value must be a positive integer greater than 0.
-If this is attribute is not provided, by default:
-    - Docker Desktop signs you out after 90 days, or 30 days of inactivity.
-    - Docker Hub and Docker Home sign you out after 24 hours.
-
-If your organization uses SAML for SSO, Docker retrieves these attributes from the SAML assertion message. Keep in mind that different IdPs may use different names for these attributes. The following reference table outlines possible SAML attributes used by Docker:
-
-| SSO Attribute	| SAML Assertion Message Attributes |
-| :--- | :--- |
-| Email address |	`"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"`, `"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"`, `"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"`, `email` |
-| Full name	| `"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"`, `name`, `"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"`, `"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"` |
-| Groups (optional) |	`"http://schemas.xmlsoap.org/claims/Group"`, `"http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"`, `Groups`, `groups` |
-| Docker Org (optional)	| `dockerOrg` |
-| Docker Team (optional) |	`dockerTeam` |
-| Docker Role (optional) |	`dockerRole` |
-| Docker session minutes (optional) | `dockerSessionMinutes`, must be a positive integer > 0 |
-
-## What's next?
-
-Review the provisioning method guides for steps on configuring provisioning methods:
-- [JIT](/manuals/security/for-admins/provisioning/just-in-time.md)
-- [SCIM](/manuals/security/for-admins/provisioning/scim.md)
-- [Group mapping](/manuals/security/for-admins/provisioning/group-mapping.md)
\ No newline at end of file
diff --git a/content/manuals/security/for-admins/provisioning/group-mapping.md b/content/manuals/security/for-admins/provisioning/group-mapping.md
deleted file mode 100644
index 595087318200..000000000000
--- a/content/manuals/security/for-admins/provisioning/group-mapping.md
+++ /dev/null
@@ -1,182 +0,0 @@
----
-description: Group mapping for administrators
-keywords: Group Mapping, SCIM, Docker Hub, Docker Admin, admin, security
-title: Group mapping
-aliases:
-- /admin/company/settings/group-mapping/
-- /admin/organization/security-settings/group-mapping/
-- /docker-hub/group-mapping/
-- /security/for-admins/group-mapping/
-weight: 40
----
-
-{{< summary-bar feature_name="SSO" >}}
-
-Group mapping lets you sync user groups from your identity provider (IdP) with teams in your Docker organization. This automates team membership management, keeping your Docker teams up to date based on changes in your IdP. You can use group mapping once you have configured [single sign-on (SSO)](../single-sign-on/_index.md).
-
-> [!TIP]
->
-> Group mapping is ideal for adding users to multiple organizations or multiple teams within one organization. If you don't need to set up multi-organization or multi-team assignment, you can use SCIM [user-level attributes](scim.md#set-up-role-mapping).
-
-## How group mapping works
-
-With group mapping enabled, when a user authenticates through SSO, your IdP shares key attributes with Docker, such as the user's email address, name, and groups. Docker uses these attributes to create or update the user's profile, as well as to manage their team and organization assignments. With group mapping, users’ team memberships in Docker automatically reflect changes made in your IdP groups.
-
-It's important to note that Docker uses the user's email address as a unique identifier. Each Docker account must always have a unique email address.
-
-## Use group mapping
-
-To assign users to Docker teams through your IdP, you must create groups in your IdP following the naming pattern: `organization:team`. For example, if your organization is called "moby" and you want to manage the "developers" team, the group name in your IdP should be `moby:developers`. In this example, any user added to this group in your IdP is automatically assigned to the "developers" team in Docker.
-
-You can also use this format to assign users to multiple organizations. For example, to add a user to the "backend" team in the "moby" organization and the "desktop" team in the "whale" organization, the group names would be `moby:backend` and `whale:desktop`.
-
-> [!TIP]
->
-> Match the group names in your IdP with your Docker teams. When groups are synced, Docker creates a team if it doesn’t already exist.
-
-The following lists the supported group mapping attributes:
-
-| Attribute | Description |
-|:--------- | :---------- |
-| id | Unique ID of the group in UUID format. This attribute is read-only. |
-| displayName | Name of the group following the group mapping format: `organization:team`. |
-| members | A list of users that are members of this group. |
-| members(x).value | Unique ID of the user that is a member of this group. Members are referenced by ID. |
-
-The general steps to use group mapping are:
-
-1. In your IdP, create groups with the `organization:team` format.
-2. Add users to the group.
-3. Add the Docker application that you created in your IdP to the group.
-4. Add attributes in the IdP.
-5. Push groups to Docker.
-
-The exact configuration may vary depending on your IdP. You can use [group mapping with SSO](#use-group-mapping-with-sso), or with SSO and [SCIM enabled](#use-group-mapping-with-scim).
-
-### Use group mapping with SSO
-
-The following steps describe how to set up and use group mapping with SSO
-connections that use the SAML authentication method. Note that group mapping
-with SSO isn't supported with the Azure AD (OIDC) authentication method.
-Additionally, SCIM isn't required for these configurations.
-
-{{< tabs >}}
-{{< tab name="Okta" >}}
-
-The user interface for your IdP may differ slightly from the following steps. You can refer to the [Okta documentation](https://help.okta.com/oie/en-us/content/topics/apps/define-group-attribute-statements.htm) to verify.
-
-To set up group mapping:
-
-1. Sign in to Okta and open your application.
-2. Navigate to the **SAML Settings** page for your application.
-3. In the **Group Attribute Statements (optional)** section, configure like the following:
-   - **Name**: `groups`
-   - **Name format**: `Unspecified`
-   - **Filter**: `Starts with` + `organization:` where `organization` is the name of your organization
-   The filter option will filter out the groups that aren't affiliated with your Docker organization.
-4. Create your groups by selecting **Directory**, then **Groups**.
-5. Add your groups using the format `organization:team` that matches the names of your organization(s) and team(s) in Docker.
-6. Assign users to the group(s) that you create.
-
-The next time you sync your groups with Docker, your users will map to the Docker groups you defined.
-
-{{< /tab >}}
-{{< tab name="Entra ID" >}}
-
-The user interface for your IdP may differ slightly from the following steps. You can refer to the [Entra ID documentation](https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/customize-application-attributes) to verify.
-
-To set up group mapping:
-
-1. Sign in to Entra ID and open your application.
-2. Select **Manage**, then **Single sign-on**.
-3. Select **Add a group claim**.
-4. In the Group Claims section, select **Groups assigned to the application** with the source attribute **Cloud-only group display names (Preview)**.
-5. Select **Advanced options**, then the **Filter groups** option.
-6. Configure the attribute like the following:
-   - **Attribute to match**: `Display name`
-   - **Match with**: `Contains`
-   - **String**: `:`
-7. Select **Save**.
-8. Select **Groups**, **All groups**, then **New group** to create your group(s).
-9. Assign users to the group(s) that you create.
-
-The next time you sync your groups with Docker, your users will map to the Docker groups you defined.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Use group mapping with SCIM
-
-The following steps describe how to set up and use group mapping with SCIM. Before you begin, make sure you [set up SCIM](./scim.md#enable-scim) first.
-
-{{< tabs >}}
-{{< tab name="Okta" >}}
-
-The user interface for your IdP may differ slightly from the following steps. You can refer to the [Okta documentation](https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-enable-group-push.htm) to verify.
-
-To set up your groups:
-
-1. Sign in to Okta and open your application.
-2. Select **Applications**, then **Provisioning**, and **Integration**.
-3. Select **Edit** to enable groups on your connection, then select **Push groups**.
-4. Select **Save**. Saving this configuration will add the **Push Groups** tab to your application.
-5. Create your groups by navigating to **Directory** and selecting **Groups**.
-6. Add your groups using the format `organization:team` that matches the names of your organization(s) and team(s) in Docker.
-7. Assign users to the group(s) that you create.
-8. Return to the **Integration** page, then select the **Push Groups** tab to open the view where you can control and manage how groups are provisioned.
-9. Select **Push Groups**, then **Find groups by rule**.
-10. Configure the groups by rule like the following:
-    - Enter a rule name, for example `Sync groups with Docker Hub`
-    - Match group by name, for example starts with `docker:` or contains `:` for multi-organization
-    - If you enable **Immediately push groups by rule**, sync will happen as soon as there's a change to the group or group assignments. Enable this if you don't want to manually push groups.
-
-Find your new rule under **By rule** in the **Pushed Groups** column. The groups that match that rule are listed in the groups table on the right-hand side.
-
-To push the groups from this table:
-
-1. Select **Group in Okta**.
-2. Select the **Push Status** drop-down.
-3. Select **Push Now**.
-
-{{< /tab >}}
-{{< tab name="Entra ID" >}}
-
-The user interface for your IdP may differ slightly from the following steps. You can refer to the [Entra ID documentation](https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/customize-application-attributes) to verify.
-
-Complete the following before configuring group mapping:
-
-1. Sign in to Entra ID and go to your application.
-2. In your application, select **Provisioning**, then **Mappings**.
-3. Select **Provision Microsoft Entra ID Groups**.
-4. Select **Show advanced options**, then **Edit attribute list**.
-5. Update the `externalId` type to `reference`, then select the **Multi-Value** checkbox and choose the referenced object attribute `urn:ietf:params:scim:schemas:core:2.0:Group`.
-6. Select **Save**, then **Yes** to confirm.
-7. Go to **Provisioning**.
-8. Toggle **Provision Status** to **On**, then select **Save**.
-
-Next, set up group mapping:
-
-1. Go to the application overview page.
-2. Under **Provision user accounts**, select **Get started**.
-3. Select **Add user/group**.
-4. Create your group(s) using the `organization:team` format.
-5. Assign the group to the provisioning group.
-6. Select **Start provisioning** to start the sync.
-
-To verify, select **Monitor**, then **Provisioning logs** to see that your groups were provisioned successfully. In your Docker organization, you can check that the groups were correctly provisioned and the members were added to the appropriate teams.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-Once complete, a user who signs in to Docker through SSO is automatically added to the organizations and teams mapped in the IdP.
-
-> [!TIP]
->
-> [Enable SCIM](scim.md) to take advantage of automatic user provisioning and de-provisioning. If you don't enable SCIM users are only automatically provisioned. You have to de-provision them manually.
-
-## More resources
-
-The following videos demonstrate how to use group mapping with your IdP with SCIM enabled:
-
-- [Video: Group mapping with Okta](https://youtu.be/c56YECO4YP4?feature=shared&t=3023)
-- [Video: Attribute and group mapping with Entra ID (Azure)](https://youtu.be/bGquA8qR9jU?feature=shared&t=2039)
diff --git a/content/manuals/security/for-admins/provisioning/just-in-time.md b/content/manuals/security/for-admins/provisioning/just-in-time.md
deleted file mode 100644
index 597a636ae80a..000000000000
--- a/content/manuals/security/for-admins/provisioning/just-in-time.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-description: Learn how Just-in-Time provisioning works with your SSO connection.
-keywords: user provisioning, just-in-time provisioning, JIT, autoprovision, Docker Hub, Docker Admin, admin, security
-title: Just-in-Time provisioning
-linkTitle: Just-in-Time
----
-
-{{< summary-bar feature_name="SSO" >}}
-
-Just-in-Time (JIT) provisioning automatically creates and updates user accounts after every successful single sign-on (SSO) authentication. JIT verifies that the user signing in belongs to the organization and the teams assigned to them in your identity provider (IdP). When you [create your SSO connection](../single-sign-on/_index.md), JIT provisioning is turned on by default.
-
-## SSO authentication with JIT provisioning enabled
-
-When a user signs in with SSO and your SSO configuration has JIT provisioning enabled, the following steps occur automatically:
-
-1. The system checks if a Docker account exists for the user's email address.
-
-    - If an account exists: The system uses the existing account and updates the user's full name if necessary.
-    - If no account exists: A new Docker account is created using basic user attributes (email, name, and surname). A unique username is generated based on the user's email, name, and random numbers to ensure all usernames are unique across the platform.
-
-2. The system checks for any pending invitations to the SSO organization.
-
-    - Invitation found: The invitation is automatically accepted.
-    - Invitation includes a specific group: The user is added to that group within the SSO organization.
-
-3. The system verifies if the IdP has shared group mappings during authentication.
-
-    - Group mappings provided: The user is assigned to the relevant organizations and teams.
-    - No group mappings provided: The system checks if the user is already part of the organization. If not, the user is added to the default organization and team configured in the SSO connection.
-
-The following graphic provides an overview of SSO authentication with JIT enabled:
-
-   ![JIT provisioning enabled](../../images/jit-enabled-flow.svg)
-
-## SSO authentication with JIT provisioning disabled
-
-When JIT provisioning is disabled in your SSO connection, the following actions occur during authentication:
-
-1. The system checks if a Docker account exists for the user's email address.
-
-    - If an account exists: The system uses the existing account and updates the user's full name if necessary.
-    - If no account exists: A new Docker account is created using basic user attributes (email, name, and surname). A unique username is generated based on the user's email, name, and random numbers to ensure all usernames are unique across the platform.
-
-2. The system checks for any pending invitations to the SSO organization.
-
-   - Invitation found: If the user is a member of the organization or has a pending invitation, sign-in is successful, and the invitation is automatically accepted.
-   - No invitation found: If the user is not a member of the organization and has no pending invitation, the sign-in fails, and an `Access denied` error appears. The user must contact an administrator to be invited to the organization.
-
-With JIT disabled, group mapping is only available if you have [SCIM enabled](/security/for-admins/provisioning/scim/#enable-scim-in-docker). If SCIM is not enabled, users won't be auto-provisioned to groups.
-
-The following graphic provides an overview of SSO authentication with JIT disabled:
-
-![JIT provisioning disabled](../../images/jit-disabled-flow.svg)
-
-## Disable JIT provisioning
-
-> [!WARNING]
->
-> Disabling JIT provisioning may disrupt your users' access and workflows. With JIT disabled, users will not be automatically added to your organization. Users must already be a member of the organization or have a pending invitation to successfully sign in through SSO. To auto-provision users with JIT disabled, [use SCIM](./scim.md).
-
-You may want to disable JIT provisioning for reasons such as the following:
-
-- You have multiple organizations, have SCIM enabled, and want SCIM to be the source of truth for provisioning
-- You want to control and restrict usage based on your organization's security configuration, and want to use SCIM to provision access
-
-Users are provisioned with JIT by default. If you enable SCIM, you can disable JIT:
-
-1. In the [Admin Console](https://app.docker.com/admin), select your organization.
-2. Select **SSO and SCIM**.
-3. In the SSO connections table, select the **Action** icon and then **Disable JIT provisioning**.
-4. Select **Disable** to confirm.
diff --git a/content/manuals/security/for-admins/provisioning/scim.md b/content/manuals/security/for-admins/provisioning/scim.md
deleted file mode 100644
index a76de476b39a..000000000000
--- a/content/manuals/security/for-admins/provisioning/scim.md
+++ /dev/null
@@ -1,267 +0,0 @@
----
-keywords: SCIM, SSO, user provisioning, de-provisioning, role mapping, assign users
-title: SCIM provisioning
-linkTitle: SCIM
-description: Learn how System for Cross-domain Identity Management works and how to set it up.
-aliases:
-  - /security/for-admins/scim/
-  - /docker-hub/scim/
-weight: 30
----
-
-{{< summary-bar feature_name="SSO" >}}
-
-System for Cross-domain Identity Management (SCIM) is available for Docker Business customers. This guide provides an overview of SCIM provisioning.
-
-## How SCIM works
-
-SCIM offers automated user provisioning and de-provisioning for Docker through your identity provider (IdP). Once SCIM is enabled, users assigned to the Docker application in your IdP are automatically provisioned and added to your Docker organization. If a user is unassigned, they are removed from Docker.
-
-SCIM also syncs user profile updates, such as name changes, made in your IdP. SCIM can be used with Docker’s default Just-in-Time (JIT) provisioning configuration, or on its own with JIT disabled.
-
-SCIM supports the automation of:
-- Creating users
-- Updating user profiles
-- Removing and deactivating users
-- Re-activating users
-- Group mapping
-
-## Supported attributes
-
-> [!IMPORTANT]
->
-> Docker uses JIT provisioning by default for SSO configurations. If you enable SCIM, JIT values still overwrite the attribute
-values set by SCIM provisioning. To avoid conflicts, your JIT attribute values must match your SCIM attribute values. To avoid conflicts between SCIM and JIT, you can also disable JIT provisioning. See [Just-in-Time](/manuals/security/for-admins/provisioning/just-in-time.md) for more information.
-
-Attributes are pieces of user information, such as name and email, that are synchronized between your IdP and Docker when using SCIM. Proper mapping of these attributes is essential for seamless user provisioning and to prevent duplicate entries when using SSO.
-
-The following table lists the supported attributes for SCIM:
-
-| Attribute    | Description |
-|:---------------------------------------------------------------|:-------------------------------------------------------------------------------------------|
-| userName             | User’s primary email address, used as the unique identifier |
-| name.givenName | User’s first name |
-| name.familyName | User’s surname |
-| active | Indicates if a user is enabled or disabled, set to “false” to de-provision a user |
-
-For additional details about supported attributes and SCIM, see [Docker Hub API SCIM reference](/reference/api/hub/latest/#tag/scim).
-
-## Enable SCIM in Docker
-
-You must [configure SSO](../single-sign-on/configure/_index.md) before you enable SCIM. Enforcing SSO isn't required to use SCIM.
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-{{% admin-scim product="admin" %}}
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-{{% admin-scim %}}
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Enable SCIM in your IdP
-
-The user interface for your IdP may differ slightly from the following steps. You can refer to the documentation for your IdP to verify. For additional details, see the documentation for your IdP:
-
-- [Okta](https://help.okta.com/en-us/Content/Topics/Apps/Apps_App_Integration_Wizard_SCIM.htm)
-- [Entra ID (formerly Azure AD)](https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/user-provisioning)
-
-{{< tabs >}}
-{{< tab name="Okta" >}}
-
-### Enable SCIM
-
-1. Sign in to Okta and select **Admin** to open the admin portal.
-2. Open the application you created when you configured your SSO connection.
-3. On the application page, select the **General** tab, then **Edit App Settings**.
-4. Enable SCIM provisioning, then select **Save**.
-5. Now you can access the **Provisioning** tab in Okta. Navigate to this tab, then select **Edit SCIM Connection**.
-6. To configure SCIM in Okta, set up your connection using the following values and settings:
-    - SCIM Base URL: SCIM connector base URL (copied from Docker Hub)
-    - Unique identifier field for users: `email`
-    - Supported provisioning actions: **Push New Users** and **Push Profile Updates**
-    - Authentication Mode: HTTP Header
-    - SCIM Bearer Token: HTTP Header Authorization Bearer Token (copied from Docker Hub)
-7. Select **Test Connector Configuration**.
-8. Review the test results and select **Save**.
-
-### Enable synchronization
-
-1. In Okta, select **Provisioning**.
-2. Select **To App**, then **Edit**.
-3. Enable **Create Users**, **Update User Attributes**, and **Deactivate Users**.
-4. Select **Save**.
-5. Remove unnecessary mappings. The necessary mappings are:
-    - Username
-    - Given name
-    - Family name
-    - Email
-
-{{< /tab >}}
-{{< tab name="Entra ID SAML 2.0" >}}
-
-1. In the Azure admin portal, go to **Enterprise Applications**, then select the **Docker** application you created when you set up your SSO connection.
-2. Select **Provisioning**, then **Get Started**.
-3. Select **Automatic** provisioning mode.
-4. Enter the **SCIM Base URL** and **API Token** from Docker into the **Admin Credentials** form.
-5. Test the connection, then select **Save**.
-6. Go to  **Mappings**, then select **Provision Azure Active Directory Groups**.
-7. Set the **Enabled** value to **No**.
-8. Select **Provision Azure Active Directory Users**.
-9. Remove all unsupported attributes.
-10. Select **Save**.
-11. Set the provisioning status to **On**.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Set up role mapping
-
-You can assign [roles](/security/for-admins/roles-and-permissions/) to members in your organization in your IdP. To set up a role, you can use optional user-level attributes for the person you want to assign a role. In addition to roles, you can set an organization or team to override the default provisioning values set by the SSO connection.
-
-> [!NOTE]
->
-> Role mappings are supported for both SCIM and JIT provisioning. With JIT provisioning, role mapping only applies when a user is initially provisioned to the organization.
-
-The following table lists the supported optional user-level attributes.
-
-| Attribute | Possible values    | Considerations |
-| --------- | ------------------ | -------------- |
-| `dockerRole` | `member`, `editor`, or `owner`, for a list of permissions for each role, see [Roles and permissions](/security/for-admins/roles-and-permissions/) | If you don't assign a role in the IdP, the value of the `dockerRole` attribute defaults to `member`. When you set the attribute, this overrides the default value. |
-| `dockerOrg` | `organizationName`, for example, an organization named "moby" would be `moby` | Setting this attribute overrides the default organization configured by the SSO connection. Also, this won't add the user to the default team. If this attribute isn't set, the user is provisioned to the default organization and the default team. If set and `dockerTeam` is also set, this provisions the user to the team within that organization. |
-| `dockerTeam` | `teamName`, for example, a team named "developers" would be `developers` | Setting this attribute provisions the user to the default organization and to the specified team, instead of the SSO connection's default team. This also creates the team if it doesn't exist. You can still use group mapping to provision users to teams in multiple organizations. See [Group mapping](/security/for-admins/provisioning/group-mapping/) for more details. |
-
-After you set the role in the IdP, you must initiate a sync in your IdP to push the changes to Docker.
-
-The external namespace to use to set up these attributes is `urn:ietf:params:scim:schemas:extension:docker:2.0:User`.
-
-{{< tabs >}}
-{{< tab name="Okta" >}}
-
-### Set up role mapping in Okta
-
-1. Setup [SSO](../single-sign-on/configure/_index.md) and SCIM first.
-2. In the Okta admin portal, go to **Directory**, select **Profile Editor**, and then **User (Default)**.
-3. Select **Add Attribute** and configure the values for the role, organization, or team you want to add. Exact naming isn't required.
-4. Return to the **Profile Editor** and select your application.
-5. Select **Add Attribute** and enter the required values. The **External Name** and **External Namespace** must be exact. The external name values for organization/team/role mapping are `dockerOrg`, `dockerTeam`, and `dockerRole` respectively, as listed in the previous table. The external namespace is the same for all of them: `urn:ietf:params:scim:schemas:extension:docker:2.0:User`.
-6. After creating the attributes, navigate to the top of the page and select **Mappings**, then **Okta User to YOUR APP**.
-7. Go to the newly created attributes and map the variable names to the external names, then select **Save Mappings**. If you’re using JIT provisioning, continue to the following steps.
-8. Navigate to **Applications** and select **YOUR APP**.
-9. Select **General**, then **SAML Settings**, and **Edit**.
-10. Select **Step 2** and configure the mapping from the user attribute to the Docker variables.
-
-### Assign roles by user
-
-1. In the Okta admin portal, select **Directory**, then **People**.
-2. Select **Profile**, then **Edit**.
-3. Select **Attributes** and update the attributes to the desired values.
-
-### Assign roles by group
-
-1. In the Okta admin portal, select **Directory**, then **People**.
-2. Select **YOUR GROUP**, then **Applications**.
-3. Open **YOUR APPLICATION** and select the **Edit** icon.
-4. Update the attributes to the desired values.
-
-If a user doesn't already have attributes set up, users who are added to the group will inherit these attributes upon provisioning.
-
-{{< /tab >}}
-{{< tab name="Entra ID SAML 2.0" >}}
-
-### Set up role mapping in Azure AD
-
-1. Setup [SSO](../single-sign-on/configure/_index.md) and SCIM first.
-2. In the Azure AD admin portal, open **Enterprise Apps** and select **YOUR APP**.
-3. Select **Provisioning**, then **Mappings**, and **Provision Azure Active Directory Users**.
-4. To set up the new mapping, check **Show advanced options**, then select **Edit attribute options**.
-5. Create new entries with the desired mapping for role, organization, or group (for example, `urn:ietf:params:scim:schemas:extension:docker:2.0:User:dockerRole`) as a string type.
-6. Navigate back to **Attribute Mapping** for users and select **Add new mapping**.
-
-### Expression mapping
-
-This implementation works best for roles, but can't be used along with organization and team mapping using the same method. With this approach, you can assign attributes at a group level, which members can inherit. This is the recommended approach for role mapping.
-
-1. In the **Edit Attribute** view, select the **Expression** mapping type.
-2. If you can create app roles named as the role directly (for example, `owner` or `editor`), in the **Expression** field, you can use `SingleAppRoleAssignment([appRoleAssignments])`.
-
-   Alternatively, if you’re restricted to using app roles you have already defined (for example, `My Corp Administrators`) you’ll need to setup a switch for these roles. For example:
-
-    ```text
-    Switch(SingleAppRoleAssignment([appRoleAssignments]), "member", "My Corp Administrator", "owner", "My Corp Editor", "editor")`
-    ```
-3. Set the following fields:
-    - **Target attribute**: `urn:ietf:params:scim:schemas:extension:docker:2.0:User:dockerRole`
-    - **Match objects using this attribute**: No
-    - **Apply this mapping**: Always
-4. Save your configuration.
-
-### Direct mapping
-
-Direct mapping is an alternative to expression mapping. This implementation works for all three mapping types at the same time. In order to assign users, you'll need to use the Microsoft Graph API.
-
-1. In the **Edit Attribute** view, select the **Direct** mapping type.
-2. Set the following fields:
-    - **Source attribute**: choose one of the allowed extension attributes in Entra (for example, `extensionAttribute1`)
-    - **Target attribute**: `urn:ietf:params:scim:schemas:extension:docker:2.0:User:dockerRole`
-    - **Match objects using this attribute**: No
-    - **Apply this mapping**: Always
-
-    If you're setting more than one attribute, for example role and organization, you need to choose a different extension attribute for each one.
-3. Save your configuration.
-
-### Assign users
-
-If you used expression mapping in the previous step, navigate to **App registrations**, select **YOUR APP**, and **App Roles**. Create an app role for each Docker role. If possible, create it with a display name that is directly equivalent to the role in Docker, for example, `owner` instead of `Owner`. If set up this way, then you can use expression mapping to `SingleAppRoleAssignment([appRoleAssignments])`. Otherwise, a custom switch will have to be used. See [Expression mapping](#expression-mapping).
-
-To add a user:
-1. Select **YOUR APP**, then **Users and groups**.
-2. Select **Add user/groups**, select the user you want to add, then **Select** their desired role.
-
-To add a group:
-1. Select **YOUR APP**, then **Users and groups**.
-2. Select **Add user/groups**, select the user you want to add, then **Select** their desired role.
-
-If you used direct mapping in the previous step, go to **Microsoft Graph Explorer** and sign in to your tenant. You need to be a tenant admin to use this feature. Use the Microsoft Graph API to assign the extension attribute to the user with the value that corresponds to what the attribute was mapped to. See the [Microsoft Graph API documentation](https://learn.microsoft.com/en-us/graph/extensibility-overview?tabs=http) on adding or updating data in extension attributes.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-See the documentation for your IdP for additional details:
-
-- [Okta](https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-add-custom-user-attributes.htm)
-- [Entra ID (formerly Azure AD)](https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/customize-application-attributes#provisioning-a-custom-extension-attribute-to-a-scim-compliant-application)
-
-## Disable SCIM
-
-If SCIM is disabled, any user provisioned through SCIM will remain in the organization. Future changes for your users will not sync from your IdP. User de-provisioning is only possible when manually removing the user from the organization.
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-{{% admin-scim-disable product="admin" %}}
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-{{% admin-scim-disable %}}
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## More resources
-
-The following videos demonstrate how to configure SCIM for your IdP:
-
-- [Video: Configure SCIM with Okta](https://youtu.be/c56YECO4YP4?feature=shared&t=1314)
-- [Video: Attribute mapping with Okta](https://youtu.be/c56YECO4YP4?feature=shared&t=1998)
-- [Video: Configure SCIM with Entra ID (Azure)](https://youtu.be/bGquA8qR9jU?feature=shared&t=1668)
-- [Video: Attribute and group mapping with Entra ID (Azure)](https://youtu.be/bGquA8qR9jU?feature=shared&t=2039)
diff --git a/content/manuals/security/for-admins/roles-and-permissions.md b/content/manuals/security/for-admins/roles-and-permissions.md
deleted file mode 100644
index f2464db71f09..000000000000
--- a/content/manuals/security/for-admins/roles-and-permissions.md
+++ /dev/null
@@ -1,117 +0,0 @@
----
-description: >
-  Use roles in your organization to control who has access to content,
-  registry, and organization management permissions.
-keywords: members, teams, organization, company, roles, access, docker hub, admin console, security
-title: Roles and permissions
-aliases:
-- /docker-hub/roles-and-permissions/
-weight: 40
----
-
-{{< summary-bar feature_name="General admin" >}}
-
-Organization and company owners can assign roles to individuals giving them different permissions in the organization. This guide outlines Docker's organization roles and their permission scopes.
-
-## Roles
-
-When you invite users to your organization, you assign them a role. A role is a collection of permissions. Roles define whether users can create repositories, pull images, create teams, and configure organization settings.
-
-The following roles are available to assign:
-
-- Member: Non-administrative role. Members can view other members that are in the same organization.
-- Editor: Partial administrative access to the organization. Editors can create, edit, and delete repositories. They can also edit an existing team's access permissions.
-- Organization owner: Full organization administrative access. Organization owners can manage organization repositories, teams, members, settings, and billing.
-- Company owner: In addition to the permissions of an organization owner, company owners can configure settings for their associated organizations.
-
-Owners can manage roles for members of an organization using Docker Hub or the Admin Console:
-- Update a member role in [Docker Hub](/manuals/admin/organization/members.md#update-a-member-role)
-- Update an organization's members or company in the [Admin Console](/manuals/admin/company/users.md#update-a-member-role)
-- Learn more about [organizations and companies](/manuals/admin/_index.md)
-
-## Permissions
-
-> [!NOTE]
->
-> Company owners have the same access as organization owners for all associated organizations. For more information, see [Company overview](/admin/company/).
-
-The following sections describe the permissions for each role.
-
-### Content and registry permissions
-
-The following table outlines content and registry permissions for member, editor, and organization owner roles. These permissions and roles apply to the entire organization, including all the repositories in the namespace for the organization.
-
-| Permission                                            | Member | Editor | Organization owner |
-| :---------------------------------------------------- | :----- | :----- | :----------------- |
-| Explore images and extensions                         | ✅     | ✅     | ✅                 |
-| Star, favorite, vote, and comment on content          | ✅     | ✅     | ✅                 |
-| Pull images                                           | ✅     | ✅     | ✅                 |
-| Create and publish an extension                       | ✅     | ✅     | ✅                 |
-| Become a Verified, Official, or Open Source publisher | ❌     | ❌     | ✅                 |
-| Observe content engagement as a publisher             | ❌     | ❌     | ✅                 |
-| Create public and private repositories                | ❌     | ✅     | ✅                 |
-| Edit and delete repositories                          | ❌     | ✅     | ✅                 |
-| Manage tags                                           | ❌     | ✅     | ✅                 |
-| View repository activity                              | ❌     | ❌     | ✅                 |
-| Set up Automated builds                               | ❌     | ❌     | ✅                 |
-| Edit build settings                                   | ❌     | ❌     | ✅                 |
-| View teams                                            | ✅     | ✅     | ✅                 |
-| Assign team permissions to repositories               | ❌     | ✅     | ✅                 |
-
-When you add members to a team, you can manage their repository permissions. For team repository permissions, see [Create and manage a team permissions reference](/manuals/admin/organization/manage-a-team.md#permissions-reference).
-
-The following diagram provides an example of how permissions may work for a user. In this example, the first permission check is for the role: member or editor. Editors have administrative permissions for repositories across the namespace of the organization. Members may have administrative permissions for a repository if they're a member of a team that grants those permissions.
-
-![User repository permissions within an organization](../images/roles-and-permissions-member-editor-roles.png)
-
-### Organization management permissions
-
-The following table outlines organization management permissions for member, editor, organization owner, and company owner roles.
-
-| Permission                                                        | Member | Editor | Organization owner | Company owner |
-| :---------------------------------------------------------------- | :----- | :----- | :----------------- | :------------ |
-| Create teams                                                      | ❌     | ❌     | ✅                 | ✅            |
-| Manage teams (including delete)                                   | ❌     | ❌     | ✅                 | ✅            |
-| Configure the organization's settings (including linked services) | ❌     | ❌     | ✅                 | ✅            |
-| Add organizations to a company                                    | ❌     | ❌     | ✅                 | ✅            |
-| Invite members                                                    | ❌     | ❌     | ✅                 | ✅            |
-| Manage members                                                    | ❌     | ❌     | ✅                 | ✅            |
-| Manage member roles and permissions                               | ❌     | ❌     | ✅                 | ✅            |
-| View member activity                                              | ❌     | ❌     | ✅                 | ✅            |
-| Export and reporting                                              | ❌     | ❌     | ✅                 | ✅            |
-| Image Access Management                                           | ❌     | ❌     | ✅                 | ✅            |
-| Registry Access Management                                        | ❌     | ❌     | ✅                 | ✅            |
-| Set up Single Sign-On (SSO) and SCIM                              | ❌     | ❌     | ✅ \*              | ✅            |
-| Require Docker Desktop sign-in                                    | ❌     | ❌     | ✅ \*              | ✅            |
-| Manage billing information (for example, billing address)                 | ❌     | ❌     | ✅                 | ✅            |
-| Manage payment methods (for example, credit card or invoice)              | ❌     | ❌     | ✅                 | ✅            |
-| View billing history                                              | ❌     | ❌     | ✅                 | ✅            |
-| Manage subscriptions                                              | ❌     | ❌     | ✅                 | ✅            |
-| Manage seats                                                      | ❌     | ❌     | ✅                 | ✅            |
-| Upgrade and downgrade plans                                       | ❌     | ❌     | ✅                 | ✅            |
-
-_\* If not part of a company_
-
-### Docker Scout permissions
-
-The following table outlines Docker Scout management permissions for member, editor, and organization owner roles.
-
-| Permission                                            | Member | Editor | Organization owner |
-| :---------------------------------------------------- | :----- | :----- | :----------------- |
-| View and compare analysis results                     | ✅     | ✅     | ✅                 |
-| Upload analysis records                               | ✅     | ✅     | ✅                 |
-| Activate and deactivate Docker Scout for a repository | ❌     | ✅     | ✅                 |
-| Create environments                                   | ❌     | ❌     | ✅                 |
-| Manage registry integrations                          | ❌     | ❌     | ✅                 |
-
-### Docker Build Cloud permissions
-
-The following table outlines Docker Build Cloud management permissions for member, editor, and organization owner roles.
-
-| Permission                   | Member | Editor | Organization owner |
-| ---------------------------- | :----- | :----- | :----------------- |
-| Use a cloud builder          | ✅     | ✅     | ✅                 |
-| Create and remove builders   | ✅     | ✅     | ✅                 |
-| Configure builder settings   | ✅     | ✅     | ✅                 |
-| Buy minutes                  | ❌     | ❌     | ✅                 |
-| Manage subscription          | ❌     | ❌     | ✅                 |
diff --git a/content/manuals/security/for-admins/single-sign-on/_index.md b/content/manuals/security/for-admins/single-sign-on/_index.md
deleted file mode 100644
index 5977b7990a31..000000000000
--- a/content/manuals/security/for-admins/single-sign-on/_index.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-description: Learn how single sign-on works, how to set it up, and the required SSO attributes.
-keywords: Single Sign-On, SSO, sign-on, admin, docker hub, admin console, security
-title: Single sign-on overview
-linkTitle: Single sign-on
-aliases:
-- /single-sign-on/
-- /admin/company/settings/sso/
-- /admin/organization/security-settings/sso-management/
-weight: 10
----
-
-{{< summary-bar feature_name="SSO" >}}
-
-Single sign-on (SSO) lets users access Docker by authenticating using their identity providers (IdPs). SSO is available for a whole company, and all associated organizations within that company, or an individual organization that has a Docker Business subscription. To upgrade your existing account to a Docker Business subscription, see [Upgrade your subscription](/subscription/upgrade/).
-
-## How SSO works
-
-When you enable SSO, Docker supports a non-IdP-initiated SSO flow for user login. Instead of users authenticating using their Docker username and password, they are redirected to your identity provider's authentication page to sign in. Users must sign in to Docker Hub or Docker Desktop to initiate the SSO authentication process.
-
-The following diagram shows how SSO operates and is managed in Docker Hub and Docker Desktop. In addition, it provides information on how to authenticate between your IdP.
-
-![SSO architecture](images/SSO.png)
-
-## How to set it up
-
-SSO is configured using the following steps:
-1. [Configure SSO](../single-sign-on/configure.md) by creating and verifying a domain in Docker.
-2. [Create your SSO connection](../single-sign-on/connect.md) in Docker and your IdP.
-3. Cross-connect Docker and your IdP.
-4. Test your connection.
-5. Provision users.
-6. Optional. [Enforce sign-in](../enforce-sign-in/_index.md).
-7. [Manage your SSO configuration](../single-sign-on/manage.md).
-
-Once your SSO configuration is complete, a first-time user can sign in to Docker Hub or Docker Desktop using their company's domain email address. Once they sign in, they are added to your company, assigned to an organization, and if necessary, assigned to a team.
-
-## Prerequisites
-
-Before configuring SSO, ensure you meet the following prerequisites:
-* Notify your company about the new SSO sign in procedures.
-* Verify that all users have Docker Desktop version 4.4.2 or later installed.
-* If your organization is planning to [enforce SSO](/manuals/security/for-admins/single-sign-on/connect.md#optional-enforce-sso), members using the Docker CLI are required to [create a Personal Access Token (PAT)](/docker-hub/access-tokens/). The PAT will be used instead of their username and password. Docker plans to deprecate signing in to the CLI with a password in the future, so using a PAT will be required to prevent issues with authentication. For more details see the [security announcement](/security/security-announcements/#deprecation-of-password-logins-on-cli-when-sso-enforced).
-* Ensure all your Docker users have a valid user on your IdP with the same email address as their Unique Primary Identifier (UPN).
-* Confirm that all CI/CD pipelines have replaced their passwords with PATs.
-* For your service accounts, add your additional domains or enable it in your IdP.
-
-## What's next?
-
-- Start [configuring SSO](../../for-admins/single-sign-on/configure.md) in Docker
-- Explore the [FAQs](../../../security/faqs/single-sign-on/_index.md)
diff --git a/content/manuals/security/for-admins/single-sign-on/configure.md b/content/manuals/security/for-admins/single-sign-on/configure.md
deleted file mode 100644
index b0304d8b6f9b..000000000000
--- a/content/manuals/security/for-admins/single-sign-on/configure.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-description: Learn how to configure single sign-on for your organization or company.
-keywords: configure, sso, docker hub, hub, docker admin, admin, security
-title: Configure single sign-on
-linkTitle: Configure
-aliases:
-  - /docker-hub/domains/
-  - /docker-hub/sso-connection/
-  - /docker-hub/enforcing-sso/
-  - /single-sign-on/configure/
-  - /admin/company/settings/sso-configuration/
-  - /admin/organization/security-settings/sso-configuration/
----
-
-{{< summary-bar feature_name="SSO" >}}
-
-Get started creating a single sign-on (SSO) connection for your organization or company. This guide walks through the steps to add and verify the domains your members use to sign in to Docker.
-
-## Step one: Add your domain
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-1. Sign in to the [Admin Console](https://admin.docker.com/).
-2. Select your organization or company from the **Choose profile** page. Note that when an organization is part of a company, you must select the company and configure the domain for the organization at the company level.
-3. Under **Security and access**, select **Domain management**.
-4. Select **Add a domain**.
-5. Enter your domain in the text box and select **Add domain**.
-6. The pop-up modal will prompt you with steps to verify your domain. Copy the **TXT Record Value**.
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-1. Sign in to [Docker Hub](https://hub.docker.com/).
-2. Select **My Hub** and then your organization from the list.
-3. On your organization page, select **Settings** and then **Security**.
-4. Select **Add a domain**.
-5. Enter your domain in the text box and select **Add domain**.
-6. The pop-up modal will prompt you with steps to verify your domain. Copy the **TXT Record Value**.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Step two: Verify your domain
-
-Verifying your domain ensures Docker knows you own it. To verify, you add a TXT record to your Domain Name System (DNS) host using the value Docker provides. The TXT Record Value proves ownership, which signals the DNS to add this record. It can take up to 72 hours for DNS to recognize the change. When the change is reflected in DNS, Docker automatically checks the record to confirm your ownership.
-
-Use the **TXT Record Value** provided by Docker and follow the steps based on your DNS host. If your provider isn't listed, use the instructions for other providers.
-
-> [!TIP]
->
-> The record name field controls where the TXT record is applied in your domain, for example root or subdomain. In general, refer to the following tips for adding a record name:
->
-> - Use `@` or leave the record name empty for root domains like `example.com`, depending on your provider.
-> - Don't enter values like `docker`, `docker-verification`, `www`, or your domain name. These values may direct to the wrong place.
->
-> Check your DNS provider's documentation to verify record name requirements.
-
-{{< tabs >}}
-{{< tab name="AWS Route 53" >}}
-
-1. To add your TXT record to AWS, see [Creating records by using the Amazon Route 53 console](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html).
-2. TXT record verification can take 72 hours. Once you have waited for TXT record verification, return to the **Domain management** page of the [Admin Console](https://app.docker.com/admin) and select **Verify** next to your domain name.
-
-{{< /tab >}}
-{{< tab name="Google Cloud DNS" >}}
-
-1. To add your TXT record to Google Cloud DNS, see [Verifying your domain with a TXT record](https://cloud.google.com/identity/docs/verify-domain-txt).
-2. TXT record verification can take 72 hours. Once you have waited for TXT record verification, return to the **Domain management** page of the [Admin Console](https://app.docker.com/admin) and select **Verify** next to your domain name.
-
-{{< /tab >}}
-{{< tab name="GoDaddy" >}}
-
-1. To add your TXT record to GoDaddy, see [Add a TXT record](https://www.godaddy.com/help/add-a-txt-record-19232).
-2. TXT record verification can take 72 hours. Once you have waited for TXT record verification, return to the **Domain management** page of the [Admin Console](https://app.docker.com/admin) and select **Verify** next to your domain name.
-
-{{< /tab >}}
-{{< tab name="Other providers" >}}
-
-1. Sign in to your domain host.
-2. Add a TXT record to your DNS settings and save the record.
-3. TXT record verification can take 72 hours. Once you have waited for TXT record verification, return to the **Domain management** page of the [Admin Console](https://app.docker.com/admin) and select **Verify** next to your domain name.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-Once you have added and verified your domain, you are ready to create an SSO connection between Docker and your identity provider (IdP).
-
-## More resources
-
-The following videos walk through verifying your domain to create your SSO connection in Docker.
-
-- [Video: Verify your domain for SSO with Okta](https://youtu.be/c56YECO4YP4?feature=shared&t=529)
-- [Video: Verify your domain for SSO with Azure AD (OIDC)](https://youtu.be/bGquA8qR9jU?feature=shared&t=496)
-
-## What's next?
-
-[Connect Docker and your IdP](../single-sign-on/connect.md).
diff --git a/content/manuals/security/for-admins/single-sign-on/connect.md b/content/manuals/security/for-admins/single-sign-on/connect.md
deleted file mode 100644
index a5aaf812f76e..000000000000
--- a/content/manuals/security/for-admins/single-sign-on/connect.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-description: Learn how to complete your single-sign on connection and next steps for enabling SSO.
-keywords: configure, sso, docker hub, hub, docker admin, admin, security
-title: Create an SSO connection
-linkTitle: Connect
----
-
-{{< summary-bar feature_name="SSO" >}}
-
-Creating a single sign-on (SSO) connection requires setting up the connection in Docker first, followed by setting up the connection in your identity provider (IdP). This guide provides steps for setting up your SSO connection in Docker and your IdP.
-
-> [!TIP]
->
-> This guide requires copying and pasting values in both Docker and your IdP. To ensure a seamless connection process, complete all the steps in this guide in one session and keep separate browsers open for both Docker and your IdP.
-
-## Prerequisites
-
-Make sure you have completed the following before you begin:
-
-- Your domain is verified
-- You have an account set up with an IdP
-- You have completed the steps in the [Configure single sign-on](../single-sign-on/configure.md) guide
-
-## Step one: Create an SSO connection in Docker
-
->[!NOTE]
->
-> Before creating an SSO connection in Docker, you must verify at least one domain.
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-1. Sign in to the [Admin Console](https://admin.docker.com/).
-2. Select your organization or company from the **Choose profile** page. Note that when an organization is part of a company, you must select the company and configure the domain for the organization at the company level.
-3. Under Security and access, select **SSO and SCIM**.
-4. Select **Create Connection** and provide a name for the connection.
-5. Select an authentication method, **SAML** or **Azure AD (OIDC)**.
-6. Copy the following fields to add to your IdP:
-    - Okta SAML: **Entity ID**, **ACS URL**
-    - Azure OIDC: **Redirect URL**
-7. Keep this window open so you can paste the connection information from your IdP here at the end of this guide.
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-1. Sign in to Docker Hub.
-2. Select **My Hub** and then your organization from the list.
-3. On your organization page, select **Settings** and then **Security**.
-4. In the SSO connection table, select **Create Connection** and provide a name for the connection.
-5. Select an authentication method, **SAML** or **Azure AD (OIDC)**.
-6. Copy the following fields to add to your IdP:
-    - Okta SAML: **Entity ID**, **ACS URL**
-    - Azure OIDC: **Redirect URL**
-7. Keep this window open so you can paste the connection information from your IdP here at the end of this guide.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Step two: Create an SSO connection in your IdP
-
-The user interface for your IdP may differ slightly from the following steps. Refer to the documentation for your IdP to verify.
-
-{{< tabs >}}
-{{< tab name="Okta SAML" >}}
-
-1. Sign in to your Okta account.
-2. Select **Admin** to open the Okta Admin portal.
-3. From the left-hand navigation, select **Administration**.
-4. Select **Administration** and then **Create App Integration**.
-5. Select **SAML 2.0** and then **Next**.
-6. Enter "Docker Hub" as your **App Name**.
-7. Optional. Upload a logo.
-8. Select **Next**.
-9. Enter the following values from Docker into their corresponding Okta fields:
-    - Docker ACS URL: **Single Sign On URL**
-    - Docker Entity ID: **Audience URI (SP Entity ID)**
-10. Configure the following settings in Okta:
-    - Name ID format: `EmailAddress`
-    - Application username: `Email`
-    - Update application on: `Create and update`
-11. Optional. Add SAML attributes. See [SSO attributes](/manuals/security/for-admins/provisioning/_index.md#sso-attributes) for a table of SSO attributes.
-12. Select **Next**.
-13. Select the **This is an internal app that we have created** checkbox.
-14. Select **Finish**.
-
-{{< /tab >}}
-{{< tab name="Entra ID SAML 2.0" >}}
-
-1. Sign in to your Azure AD admin portal.
-2. Select **Default Directory** and then **Add**.
-3. Choose **Enterprise Application** and select **Create your own application**.
-4. Enter "Docker" for application name and select the **non-gallery** option.
-5. After the application is created, go to **Single Sign-On** and select **SAML**.
-6. Select **Edit** on the **Basic SAML configuration** section.
-7. Enter the following values from Docker into their corresponding Azure fields:
-    - Docker Entity ID: **Identifier**
-    - Docker ACS URL: **Reply URL**
-8. Optional. Add SAML attributes. See [SSO attributes](/manuals/security/for-admins/provisioning/_index.md#sso-attributes) for a table of SSO attributes.
-9. Save configuration.
-10. From the **SAML Signing Certificate** section, download your **Certificate (Base64)**.
-
-{{< /tab >}}
-{{< tab name="Azure Connect (OIDC)" >}}
-
-To create an Azure Connect (OIDC) connection, you must create an app registration, client secrets, and configure API permissions for Docker:
-
-### Create app registration
-
-1. Sign in to your Azure AD admin portal.
-2. Select **App Registration** and then **New Registration**.
-3. Enter "Docker Hub SSO" or similar for application name.
-4. Under **Supported account types**, specify who can use this application or access the app.
-5. In the **Redirect URI** section, select **Web** from the drop-down menu and paste the **Redirect URI** value from the Docker console into this field.
-6. Select **Register** to register the app.
-7. Copy the **Client ID** from the app's overview page. You need this information to continue configuring SSO in Docker.
-
-### Create client secrets
-
-1. Open your app in Azure AD and select **Certificates & secrets**.
-2. Select **+ New client secret**.
-3. Specify the description of the secret and set how long keys can be used.
-4. Select **Add** to continue.
-5. Copy the secret **Value** field. You need this to continue configuring SSO in Docker.
-
-### Configure API permissions
-
-1. Open your app in Azure AD and navigate to your app settings.
-2. Select **API permission** and then **Grant admin consent for [your tenant name]**.
-3. Select **Yes** to confirm.
-4. After confirming, select **Add a permission** and then **Delegated permissions**.
-5. Search for `User.Read` and select this option.
-6. Select **Add permissions** to confirm.
-7. Verify admin consent was granted for each permission by checking the **Status** column.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Step three: Connect Docker and your IdP
-
-After creating your connection in Docker and your IdP, you can cross-connect them to complete your SSO connection:
-
-{{< tabs >}}
-{{< tab name="Okta SAML" >}}
-
-1. Open your app you created in Okta and select **View SAML setup instructions**.
-2. Copy the following values from the Okta SAML setup instruction page:
-    - **SAML Sign-in URL**
-    - **x509 Certificate**
-
-        > [!IMPORTANT]
-        >
-        > You must copy the entire contents of your **x509 Certificate**,
-        including the `----BEGIN CERTIFICATE----` and `----END CERTIFICATE----` lines.
-
-3. Open Docker Hub or the Admin Console. Your SSO configuration page should still be open from Step one of this guide.
-4. Select **Next** to open the **Update single-sign on connection** page.
-5. Paste your Okta **SAML Sign-in URL** and **x509 Certificate** values in Docker.
-6. Select **Next**.
-7. Optional. Select a default team to provision users to and select **Next**.
-8. Verify your SSO connection details and select **Create Connection**.
-
-{{< /tab >}}
-{{< tab name="Entra ID SAML 2.0" >}}
-
-1. Open your app in Azure AD.
-2. Open your downloaded **Certificate (Base64)** in a text editor.
-3. Copy the following values:
-    - From Azure AD: **Login URL**
-    - Copy the contents of your **Certificate (Base64)** file from your text editor
-
-        > [!IMPORTANT]
-        >
-        > You must copy the entire contents of your **Certificate (base64)**,
-        including the `----BEGIN CERTIFICATE----` and `----END CERTIFICATE----` lines.
-
-4. Open Docker Hub or the Admin Console. Your SSO configuration page should still be open from Step one of this guide.
-5. Paste your **Login URL** and **Certificate (Base64)** values in Docker.
-6. Select **Next**.
-7. Optional. Select a default team to provision users to and select **Next**.
-8. Verify your SSO connection details and select **Create Connection**.
-
-{{< /tab >}}
-{{< tab name="Azure Connect (OIDC)" >}}
-
-1. Open Docker Hub or the Admin Console. Your SSO configuration page should still be open from Step one of this guide.
-2. Paste the following values from Azure AD in to Docker:
-    - **Client ID**
-    - **Client Secret**
-    - **Azure AD Domain**
-3. Select **Next**.
-4. Optional. Select a default team to provision users to and select **Next**.
-5. Verify your SSO connection details and select **Create Connection**.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Step four: Test your connection
-
-After you've completed the SSO connection process in Docker, we recommend testing it:
-
-1. Open an incognito browser.
-2. Sign in to the Admin Console using your **domain email address**.
-3. The browser will redirect to your IdP's login page to authenticate.
-4. Authenticate through your domain email instead of using your Docker ID.
-
-You can also test your SSO connection through the command-line interface (CLI). If you want to test through the CLI, your users must have a personal access token (PAT).
-
-
-## Optional: Enforce SSO
-
->[!IMPORTANT]
->
-> If SSO isn't enforced, users can choose to sign in with either their Docker username and password or SSO.
-
-Enforcing SSO requires users to use SSO when signing into Docker. This centralizes authentication and enforces policies set by the IdP.
-
-1. Sign in to the [Admin Console](https://admin.docker.com/).
-2. Select your organization or company from the **Choose profile** page. Note that when an organization is part of a company, you must select the company and configure the domain for the organization at the company level.
-3. Under Security and access, select **SSO and SCIM**.
-4. In the SSO connections table, select the **Action** icon and then **Enable enforcement**. When SSO is enforced, your users are unable to modify their email address and password, convert a user account to an organization, or set up 2FA through Docker Hub. If you want to use 2FA, you must enable 2FA through your IdP.
-5. Continue with the on-screen instructions and verify you've completed all tasks.
-6. Select **Turn on enforcement** to complete.
-
-Your users must now sign in to Docker with SSO.
-
-> [!NOTE]
->
-> When SSO is enforced, [users can't use passwords to access the Docker CLI](/security/security-announcements/#deprecation-of-password-logins-on-cli-when-sso-enforced). Users must use a [personal access token](/manuals/security/for-admins/access-tokens.md) (PAT) for authentication to access the Docker CLI.
-
-## More resources
-
-The following videos demonstrate how to enforce SSO.
-
-- [Video: Enforce SSO with Okta SAML](https://youtu.be/c56YECO4YP4?feature=shared&t=1072)
-- [Video: Enforce SSO with Azure AD (OIDC)](https://youtu.be/bGquA8qR9jU?feature=shared&t=1087)
-
-
-## What's next
-
-- [Provision users](/manuals/security/for-admins/provisioning/_index.md)
-- [Enforce sign-in](../enforce-sign-in/_index.md)
-- [Create access tokens](/manuals/security/for-admins/access-tokens.md)
diff --git a/content/manuals/security/for-admins/single-sign-on/manage.md b/content/manuals/security/for-admins/single-sign-on/manage.md
deleted file mode 100644
index 4c188a3e5ea8..000000000000
--- a/content/manuals/security/for-admins/single-sign-on/manage.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-description: Learn how to manage Single Sign-On for your organization or company.
-keywords: manage, single sign-on, SSO, sign-on, docker hub, admin console, admin, security
-title: Manage single sign-on
-linkTitle: Manage
-aliases:
-- /admin/company/settings/sso-management/
-- /single-sign-on/manage/
----
-
-{{< summary-bar feature_name="SSO" >}}
-
-## Manage organizations
-
-> [!NOTE]
->
-> You must have a [company](/admin/company/) to manage more than one organization.
-
-{{% admin-sso-management-orgs product="admin" %}}
-
-## Manage domains
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-{{% admin-sso-management product="admin" %}}
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-{{% admin-sso-management product="hub" %}}
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Manage SSO connections
-
-{{< tabs >}}
-{{< tab name="Admin Console" >}}
-
-{{% admin-sso-management-connections product="admin" %}}
-
-{{< /tab >}}
-{{< tab name="Docker Hub" >}}
-
-{{% include "hub-org-management.md" %}}
-
-{{% admin-sso-management-connections product="hub" %}}
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Manage users
-
-> [!IMPORTANT]
->
-> SSO has Just-In-Time (JIT) Provisioning enabled by default unless you have [disabled it](/security/for-admins/provisioning/just-in-time/#sso-authentication-with-jit-provisioning-disabled). This means your users are auto-provisioned to your organization.
->
-> You can change this on a per-app basis. To prevent auto-provisioning users, you can create a security group in your IdP and configure the SSO app to authenticate and authorize only those users that are in the security group. Follow the instructions provided by your IdP:
->
-> - [Okta](https://help.okta.com/en-us/Content/Topics/Security/policies/configure-app-signon-policies.htm)
-> - [Entra ID (formerly Azure AD)](https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-restrict-your-app-to-a-set-of-users)
->
-> Alternatively, see the [Provisioning overview](/manuals/security/for-admins/provisioning/_index.md) guide.
-
-
-### Add guest users when SSO is enabled
-
-To add a guest that isn't verified through your IdP:
-
-1. Sign in to the [Admin Console](https://app.docker.com/admin).
-2. Select your organization or company from the **Choose profile** page, then select **Members**.
-3. Select **Invite**.
-4. Follow the on-screen instructions to invite the user.
-
-### Remove users from the SSO company
-
-To remove a user:
-
-1. Sign in to [Admin Console](https://app.docker.com/admin).
-2. Select your organization or company from the **Choose profile** page, then select **Members**.
-3. Select the action icon next to a user’s name, and then select **Remove member**, if you're an organization, or **Remove user**, if you're a company.
-4. Follow the on-screen instructions to remove the user.
-
-## Manage provisioning
-
-Users are provisioned with Just-in-Time (JIT) provisioning by default. If you enable SCIM, you can disable JIT. For more information, see the [Provisioning overview](/manuals/security/for-admins/provisioning/_index.md) guide.
-
-## What's next?
-
-- [Set up SCIM](../provisioning/scim.md)
-- [Enable Group mapping](../provisioning/group-mapping.md)
-
diff --git a/content/manuals/security/for-developers/2fa/_index.md b/content/manuals/security/for-developers/2fa/_index.md
deleted file mode 100644
index 89ba99f6a42e..000000000000
--- a/content/manuals/security/for-developers/2fa/_index.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-description: Learn how to enable two-factor authentication on your Docker account
-keywords: Docker, docker, registry, security, Docker Hub, authentication, two-factor
-  authentication, account security
-title: Enable two-factor authentication for your Docker account
-linkTitle: Two-factor authentication
-aliases:
-- /docker-hub/2fa/
----
-
-Two-factor authentication adds an extra layer of security to your Docker
-account by requiring a unique security code when you sign in to your account. The
-security code is required in addition to your password.
-
-When you enable two-factor authentication, you are also provided with a recovery
-code. Each recovery code is unique and specific to your account. You can use
-this code to recover your account in case you lose access to your authenticator
-app. See [Recover your Docker account](recover-hub-account/).
-
-## Prerequisites
-
-You need a mobile phone with a time-based one-time password (TOTP) authenticator
-application installed. Common examples include Google Authenticator or Yubico
-Authenticator with a registered YubiKey.
-
-## Enable two-factor authentication
-
-1. Sign in to your [Docker account](https://app.docker.com/login).
-2. Select your avatar and then from the drop-down menu, select **Account settings**.
-3. Select **2FA**.
-4. Enter your account password, then select **Confirm**.
-5. Save your recovery code and store it somewhere safe. You can use your recovery code to recover your account in the event you lose access to your authenticator app.
-6. Use a Time-based One-time password (TOTP) mobile app to scan the QR code or enter the text code.
-7. Once you've linked your authenticator app, enter the six-digit code in the text-field.
-8. Select **Enable 2FA**.
-
-Two-factor authentication is now enabled. The next time you sign
-in to your Docker account, you will need to enter a security code.
diff --git a/content/manuals/security/for-developers/2fa/disable-2fa.md b/content/manuals/security/for-developers/2fa/disable-2fa.md
deleted file mode 100644
index 213e1f679d28..000000000000
--- a/content/manuals/security/for-developers/2fa/disable-2fa.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-description: Disable two-factor authentication on your Docker account
-keywords: Docker, docker, registry, security, Docker Hub, authentication, two-factor
-  authentication, account security,
-title: Disable two-factor authentication on your Docker account
-linkTitle: Disable two-factor authentication
-aliases:
-- /docker-hub/2fa/disable-2fa/
-weight: 30
----
-
-> [!WARNING]
->
-> Disabling two-factor authentication results in decreased security for your
-> Docker account.
-
-1. Sign in to your [Docker account](https://app.docker.com/login).
-2. Select your avatar and then from the drop-down menu, select **Account settings**.
-3. Select **2FA**.
-4. Enter your password, then select **Confirm**.
-5. Select **Disable 2FA**.
diff --git a/content/manuals/security/for-developers/2fa/new-recovery-code.md b/content/manuals/security/for-developers/2fa/new-recovery-code.md
deleted file mode 100644
index 5c19cda2258a..000000000000
--- a/content/manuals/security/for-developers/2fa/new-recovery-code.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-description: Generate a new 2fa recovery code
-keywords: Docker, docker, registry, security, Docker Hub, authentication, two-factor
-  authentication, account security
-title: Generate a new recovery code
-aliases:
-- /docker-hub/2fa/new-recovery-code/
-weight: 10
----
-
-If you have lost your two-factor authentication recovery code and still have
-access to your Docker Hub account, you can generate a new recovery code.
-
-1. Sign in to your [Docker account](https://app.docker.com/login).
-2. Select your avatar and then from the drop-down menu, select **Account settings**.
-3. Select **2FA**.
-4. Enter your password, then select **Confirm**.
-5. Select **Generate new code**.
-
-This generates a new code. Select the visibility icon to view the code. Remember to save your recovery code
-and store it somewhere safe.
\ No newline at end of file
diff --git a/content/manuals/security/for-developers/2fa/recover-hub-account.md b/content/manuals/security/for-developers/2fa/recover-hub-account.md
deleted file mode 100644
index e8424ccd43a4..000000000000
--- a/content/manuals/security/for-developers/2fa/recover-hub-account.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-description: Recover your Docker account
-keywords: Docker, docker, registry, security, Docker Hub, authentication, two-factor
-  authentication
-title: Recover your Docker account
-aliases:
-- /docker-hub/2fa/recover-hub-account/
-weight: 20
----
-
-If you have lost access to both your two-factor authentication application and your recovery code:
-
-1. Sign in to your [Docker account](https://app.docker.com/login) with your username and password.
-2. Select **I've lost my authentication device** and **I've lost my recovery code**.
-3. Complete the [Contact Support form](https://hub.docker.com/support/contact/?category=2fa-lockout).
-    You must enter the primary email address associated with your Docker ID in the **Contact Support** form for recovery instructions.
diff --git a/content/manuals/security/for-developers/_index.md b/content/manuals/security/for-developers/_index.md
deleted file mode 100644
index 72aff1827fac..000000000000
--- a/content/manuals/security/for-developers/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-build:
-  render: never
-title: For developers
-weight: 20
----
diff --git a/content/manuals/security/for-developers/access-tokens.md b/content/manuals/security/for-developers/access-tokens.md
deleted file mode 100644
index 1c61509edfda..000000000000
--- a/content/manuals/security/for-developers/access-tokens.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: Create and manage access tokens
-linkTitle: Access tokens
-description: Learn how to create and manage your personal Docker access tokens
-  to securely push and pull images programmatically.
-keywords: docker hub, hub, security, PAT, personal access token
-aliases:
-- /docker-hub/access-tokens/
----
-
-You can create a personal access token (PAT) to use as an alternative to your password for Docker CLI authentication.
-
-Compared to passwords, PATs provide the following advantages:
-
-- You can investigate when the PAT was last used and then disable or delete it if you find any suspicious activity.
-- When using an access token, you can't perform any administrative activity on the account, including changing the password. It protects your account if your computer is compromised.
-- Access tokens are valuable for building integrations, as you can issue multiple tokens, one for each integration, and revoke them at
-any time.
-
-## Create an access token
-
-> [!IMPORTANT]
->
-> Treat access tokens like your password and keep them secret. Store your tokens securely in a credential manager for example.
-
-Use the Docker Admin Console to create an access token.
-
-1. Sign in to your [Docker account](https://app.docker.com/login).
-
-2. Select your avatar in the top-right corner and from the drop-down menu select **Account settings**.
-
-3. Select **Personal access tokens**.
-
-4. Select **Generate new token**.
-
-5. Add a description for your token. Use something that indicates the use case or purpose of the token.
-
-6. Select the expiration date for the token.
-
-7. Set the access permissions.
-   The access permissions are scopes that set restrictions in your
-   repositories. For example, for Read & Write permissions, an automation
-   pipeline can build an image and then push it to a repository. However, it
-   can't delete the repository.
-
-8. Select **Generate** and then copy the token that appears on the screen and save it. You won't be able to retrieve the token once you close this prompt.
-
-## Use an access token
-
-You can use an access token in place of your password when you sign in using Docker CLI.
-
-Sign in from your Docker CLI client with the following command, replacing `YOUR_USERNAME` with your Docker ID:
-
-```console
-$ docker login --username <YOUR_USERNAME>
-```
-
-When prompted for a password, enter your personal access token instead of a password.
-
-> [!NOTE]
->
-> If you have [two-factor authentication (2FA)](2fa/_index.md) enabled, you must
-> use a personal access token when logging in from the Docker CLI. 2FA is an
-> optional, but more secure method of authentication.
-
-### Fair use
-
-When utilizing PATs, users should be aware that excessive creation of PATs could lead to throttling, or additional charges. To ensure fair resource usage and maintain service quality, Docker reserves the right to impose restrictions or apply additional charges to accounts exhibiting excessive use of PATs.
-
-## Modify existing tokens
-
-> [!NOTE]
->
-> You can't edit the expiration date on an existing token. You must create a new PAT if you need to set a new expiration date.
-
-You can rename, activate, deactivate, or delete a token as needed. You can manage your tokens in your account settings.
-
-1. Sign in to your [Docker account](https://app.docker.com/login).
-
-2. Select your avatar in the top-right corner and from the drop-down menu select **Account settings**.
-
-3. Select **Personal access tokens**.
-
-   This page shows an overview of all your
-   tokens, and lists if the token was generated manually or if it was
-   [auto-generated](#auto-generated-tokens). You can also view the scope of the
-   tokens, which tokens are activate and inactive, when they were created, when
-   they were last used, and their expiration date.
-
-4. Select the actions menu on the far right of a token row, then select **Deactivate** or **Activate**, **Edit**, or **Delete** to modify the token.
-
-5. After editing the token, select **Save token**.
-
-## Auto-generated tokens
-
-When you sign in to your Docker account with Docker Desktop, Docker Desktop generates an authentication token on your behalf. When you interact with Docker Hub using the Docker CLI, the CLI uses this token for authentication. The token scope has Read, Write, and Delete access. If your Docker Desktop session expires, the token is automatically removed locally.
-
-You can have up to 5 auto-generated tokens associated with your account. These are deleted and created automatically based on usage and creation dates. You can also delete your auto-generated tokens as needed. For more information, see [Modify existing tokens](#modify-existing-tokens).
diff --git a/content/manuals/security/images/enforce-sign-in.png b/content/manuals/security/images/enforce-sign-in.png
deleted file mode 100644
index e60e12f39f48..000000000000
Binary files a/content/manuals/security/images/enforce-sign-in.png and /dev/null differ
diff --git a/content/manuals/security/images/roles-and-permissions-member-editor-roles.png b/content/manuals/security/images/roles-and-permissions-member-editor-roles.png
deleted file mode 100644
index c46f44074c22..000000000000
Binary files a/content/manuals/security/images/roles-and-permissions-member-editor-roles.png and /dev/null differ
diff --git a/content/manuals/security/security-announcements.md b/content/manuals/security/security-announcements.md
index 32918133b4f5..ec3536d9945b 100644
--- a/content/manuals/security/security-announcements.md
+++ b/content/manuals/security/security-announcements.md
@@ -3,30 +3,123 @@ description: Docker security announcements
 keywords: Docker, CVEs, security, notice, Log4J 2, Log4Shell, Text4Shell, announcements
 title: Docker security announcements
 linkTitle: Security announcements
+outputs: ["HTML", "markdown", "RSS"]
+layout: security-announcements
+weight: 80
 toc_min: 1
 toc_max: 2
 ---
 
+[Subscribe to security RSS feed](/security/security-announcements/index.xml)
+
+## Docker Desktop 4.86.0 security update: CVE-2026-17106
+
+A vulnerability in Docker Desktop was fixed on August 10 in the [4.86.0](/manuals/desktop/release-notes.md#4860) release:
+
+- Addressed CVE-2026-17106, a destination-escape flaw in `docker container cp`. 
+
+## Docker Desktop 4.71.0 security update: CVE-2026-5843
+
+A vulnerability in Docker Desktop was fixed on April 27 in the [4.71.0](/manuals/desktop/release-notes.md#4710) release:
+
+- Addressed [CVE-2026-5843](https://www.cve.org/cverecord?id=CVE-2026-5843), container-to-host code execution in the Docker Model Runner MLX inference backend.
+
+## Docker Desktop 4.68.0 security update: CVE-2026-5817
+
+A vulnerability in Docker Desktop was fixed on April 7 in the [4.68.0](/manuals/desktop/release-notes.md#4680) release:
+
+- Addressed [CVE-2026-5817](https://www.cve.org/cverecord?id=CVE-2026-5817), container-to-host code execution in the Docker Model Runner vllm-metal inference backend.
+
+## Docker Desktop 4.67.0 security update: CVE-2026-33990
+
+A vulnerability in Docker Desktop was fixed on March 30 in the [4.67.0](/manuals/desktop/release-notes.md#4670) release:
+
+- Addressed [CVE-2026-33990](https://www.cve.org/cverecord?id=CVE-2026-33990), SSRF in Docker Model Runner OCI Registry Client
+
+## Docker Desktop 4.62.0 security update: CVE-2026-28400
+
+A vulnerability in Docker Desktop was fixed on February 23 in the [4.62.0](/manuals/desktop/release-notes.md#4620) release:
+
+- Addressed [CVE-2026-28400](https://www.cve.org/cverecord?id=CVE-2026-28400), runtime flag injection in Docker Model Runner.
+
+## Docker Desktop 4.62.0 security update: CVE-2026-2664
+
+A vulnerability in Docker Desktop was fixed on February 23 in the [4.62.0](/manuals/desktop/release-notes.md#4620) release:
+
+- Fixed [CVE-2026-2664](https://www.cve.org/cverecord?id=CVE-2026-2664), out of bounds read in gRPC-FUSE kernel module.
+
+## Docker Desktop 4.54.0 security update: CVE-2025-13743
+
+A vulnerability in Docker Desktop was fixed on December 4 in the [4.54.0](/manuals/desktop/release-notes.md#4540) release:
+
+- Fixed [CVE-2025-13743](https://www.cve.org/cverecord?id=CVE-2025-13743) where Docker Desktop diagnostics bundles were found to include expired Hub PATs in log output due to error object serialization.
+
+## Docker Desktop 4.49.0 security update: CVE-2025-9164
+
+A vulnerability in Docker Desktop for Windows was fixed on October 23 in the [4.49.0](/manuals/desktop/release-notes.md#4490) release:
+
+- Fixed [CVE-2025-9164](https://www.cve.org/cverecord?id=CVE-2025-9164) where the Docker Desktop for Windows installer was vulnerable to DLL hijacking due to insecure DLL search order. The installer searches for required DLLs in the user's Downloads folder before checking system directories, allowing local privilege escalation through malicious DLL placement.
+
+## Docker Desktop 4.47.0 security update: CVE-2025-10657
+
+A vulnerability in Docker Desktop was fixed on September 25 in the [4.47.0](/manuals/desktop/release-notes.md#4470) release:
+
+- Fixed [CVE-2025-10657](https://www.cve.org/CVERecord?id=CVE-2025-10657) where the Enhanced Container Isolation [Docker Socket command restrictions](../enterprise/security/hardened-desktop/enhanced-container-isolation/config.md#command-restrictions) feature was not working properly in Docker Desktop 4.46.0 only (the configuration for it was being ignored).
+
+## Docker Desktop 4.44.3 security update: CVE-2025-9074
+
+_Last updated August 20, 2025_
+
+A vulnerability in Docker Desktop was fixed on August 20 in the [4.44.3](/manuals/desktop/release-notes.md#4443) release:
+
+- Fixed [CVE-2025-9074](https://www.cve.org/CVERecord?id=CVE-2025-9074) where a malicious container running on Docker Desktop could access the Docker Engine and launch additional containers without requiring the Docker socket to be mounted. This could allow unauthorized access to user files on the host system. Enhanced Container Isolation (ECI) does not mitigate this vulnerability.
+
+## Docker Desktop 4.44.0 security update: CVE-2025-23266
+
+_Last updated July 31, 2025_
+
+We are aware of [CVE-2025-23266](https://nvd.nist.gov/vuln/detail/CVE-2025-23266), a critical vulnerability affecting the NVIDIA Container Toolkit in CDI mode up to version 1.17.7. Docker Desktop includes version 1.17.8, which is not impacted. However, older versions of Docker Desktop that bundled earlier toolkit versions may be affected if CDI mode was manually enabled. Upgrade to Docker Desktop 4.44 or later to ensure you're using the patched version.
+
+## Docker Desktop 4.43.0 security update: CVE-2025-6587
+
+_Last updated July 03, 2025_
+
+A vulnerability in Docker Desktop was fixed on July 03 in the [4.43.0](/manuals/desktop/release-notes.md#4430) release:
+
+- Fixed [CVE-2025-6587](https://www.cve.org/CVERecord?id=CVE-2025-6587) where sensitive system environment variables were included in Docker Desktop diagnostic logs, allowing for potential secret exposure.
+
+## Docker Desktop 4.41.0 Security Update: CVE-2025-3224, CVE-2025-4095, and CVE-2025-3911
+
+_Last updated May 15, 2025_
+
+Three vulnerabilities in Docker Desktop were fixed on April 28 in the [4.41.0](/manuals/desktop/release-notes.md#4410) release.
+
+- Fixed [CVE-2025-3224](https://www.cve.org/CVERecord?id=CVE-2025-3224) allowing an attacker with access to a user machine to perform an elevation of privilege when Docker Desktop updates.
+- Fixed [CVE-2025-4095](https://www.cve.org/CVERecord?id=CVE-2025-4095) where Registry Access Management (RAM) policies were not enforced when using a MacOS configuration profile, allowing users to pull images from unapproved registries.
+- Fixed [CVE-2025-3911](https://www.cve.org/CVERecord?id=CVE-2025-3911) allowing an attacker with read access to a user's machine to obtain sensitive information from Docker Desktop log files, including environment variables configured for running containers.
+
+We strongly encourage you to update to Docker Desktop [4.41.0](/manuals/desktop/release-notes.md#4410).
+
 ## Docker Desktop 4.34.2 Security Update: CVE-2024-8695 and CVE-2024-8696
 
 _Last updated September 13, 2024_
 
-Two remote code execution (RCE) vulnerabilities in Docker Desktop related to Docker Extensions were reported by [Cure53](https://cure53.de/) and were fixed on September 12 in the [4.34.2](https://docs.docker.com/desktop/release-notes/#4342) release.
+Two remote code execution (RCE) vulnerabilities in Docker Desktop related to Docker Extensions were reported by [Cure53](https://cure53.de/) and were fixed on September 12 in the [4.34.2](/manuals/desktop/release-notes.md#4342) release.
 
 - [CVE-2024-8695](https://www.cve.org/cverecord?id=CVE-2024-8695): A remote code execution (RCE) vulnerability via crafted extension description/changelog could be abused by a malicious extension in Docker Desktop before 4.34.2. [Critical]
 - [CVE-2024-8696](https://www.cve.org/cverecord?id=CVE-2024-8696): A remote code execution (RCE) vulnerability via crafted extension publisher-url/additional-urls could be abused by a malicious extension in Docker Desktop before 4.34.2. [High]
 
-No existing extensions exploiting the vulnerabilities were found in the Extensions Marketplace. The Docker team will be closely monitoring and diligently reviewing any requests for publishing new extensions.
+No existing extensions exploiting the vulnerabilities were found in the Extensions Marketplace. The Docker Team will be closely monitoring and diligently reviewing any requests for publishing new extensions.
 
-We strongly encourage you to update to Docker Desktop [4.34.2](https://docs.docker.com/desktop/release-notes/#4342). If you are unable to update promptly, you can [disable Docker Extensions](https://docs.docker.com/extensions/settings-feedback/#turn-on-or-turn-off-extensions) as a workaround.
+We strongly encourage you to update to Docker Desktop [4.34.2](/manuals/desktop/release-notes.md#4342). If you are unable to update promptly, you can [disable Docker Extensions](/manuals/extensions/settings-feedback.md#turn-on-or-turn-off-extensions) as a workaround.
 
 ## Deprecation of password logins on CLI when SSO enforced
 
 _Last updated July, 2024_
 
-When [SSO enforcement](/manuals/security/for-admins/single-sign-on/connect.md) was first introduced, Docker provided a grace period to continue to let passwords be used on the Docker CLI when authenticating to Docker Hub. This was allowed so organizations could more easily use SSO enforcement. It is recommended that administrators configuring SSO encourage users using the CLI [to switch over to Personal Access Tokens](/security/for-admins/single-sign-on/#prerequisites) in anticipation of this grace period ending.
+When [SSO enforcement](/manuals/enterprise/security/single-sign-on/connect.md) was first introduced, Docker provided a grace period to continue to let passwords be used on the Docker CLI when authenticating to Docker Hub. This was allowed so organizations could more easily use SSO enforcement. It is recommended that administrators configuring SSO encourage users using the CLI [to switch over to Personal Access Tokens](/manuals/enterprise/security/single-sign-on/_index.md#prerequisites) in anticipation of this grace period ending.
 
-On September 16, 2024 the grace period will end and passwords will no longer be able to authenticate to Docker Hub via the Docker CLI when SSO is enforced. Affected users are required to switch over to using PATs to continue signing in.
+On September 16, 2024, the grace period ended and passwords can no longer authenticate to Docker Hub via the Docker CLI when SSO is enforced. Affected users are required to switch over to using PATs to continue signing in.
 
 At Docker, we want the experience to be the most secure for our developers and organizations and this deprecation is an essential step in that direction.
 
@@ -34,9 +127,9 @@ At Docker, we want the experience to be the most secure for our developers and o
 
 _Last updated June, 2024_
 
-Docker is pleased to announce that we have received our SOC 2 Type 2 attestation and ISO 27001 certification with no exceptions or major non-conformities. 
+Docker is pleased to announce that we have received our SOC 2 Type 2 attestation and ISO 27001 certification with no exceptions or major non-conformities.
 
-Security is a fundamental pillar to Docker’s operations, which is embedded into our overall mission and company strategy. Docker’s products are core to our user community and our SOC 2 Type 2 attestation and ISO 27001 certification demonstrate Docker’s ongoing commitment to security to our user base.
+Security is a fundamental pillar to Docker's operations, which is embedded into our overall mission and company strategy. Docker's products are core to our user community and our SOC 2 Type 2 attestation and ISO 27001 certification demonstrate Docker's ongoing commitment to security to our user base.
 
 For more information, see the [Blog announcement](https://www.docker.com/blog/docker-announces-soc-2-type-2-attestation-iso-27001-certification/).
 
@@ -46,36 +139,35 @@ _Last updated February 2, 2024_
 
 We at Docker prioritize the security and integrity of our software and the trust of our users. Security researchers at Snyk Labs identified and reported four security vulnerabilities in the container ecosystem. One of the vulnerabilities, [CVE-2024-21626](https://scout.docker.com/v/CVE-2024-21626), concerns the runc container runtime, and the other three affect BuildKit ([CVE-2024-23651](https://scout.docker.com/v/CVE-2024-23651), [CVE-2024-23652](https://scout.docker.com/v/CVE-2024-23652), and [CVE-2024-23653](https://scout.docker.com/v/CVE-2024-23653)). We want to assure our community that our team, in collaboration with the reporters and open source maintainers, has been diligently working on coordinating and implementing necessary remediations.
 
-We are committed to maintaining the highest security standards. We have published patched versions of runc, BuildKit, and Moby on January 31 and released an update for Docker Desktop on February 1 to address these vulnerabilities.  Additionally, our latest BuildKit and Moby releases included fixes for [CVE-2024-23650](https://scout.docker.com/v/CVE-2024-23650) and [CVE-2024-24557](https://scout.docker.com/v/CVE-2024-24557), discovered respectively by an independent researcher and through Docker’s internal research initiatives.
+We are committed to maintaining the highest security standards. We have published patched versions of runc, BuildKit, and Moby on January 31 and released an update for Docker Desktop on February 1 to address these vulnerabilities. Additionally, our latest BuildKit and Moby releases included fixes for [CVE-2024-23650](https://scout.docker.com/v/CVE-2024-23650) and [CVE-2024-24557](https://scout.docker.com/v/CVE-2024-24557), discovered respectively by an independent researcher and through Docker's internal research initiatives.
 
-|                        | Versions Impacted         |
-|:-----------------------|:--------------------------|
-| `runc`                 | <= 1.1.11                 |
-| `BuildKit`             | <= 0.12.4                 |
-| `Moby (Docker Engine)` | <= 25.0.1 and <= 24.0.8   |
-| `Docker Desktop`       | <= 4.27.0                 |
+|                        | Versions Impacted       |
+| :--------------------- | :---------------------- |
+| `runc`                 | <= 1.1.11               |
+| `BuildKit`             | <= 0.12.4               |
+| `Moby (Docker Engine)` | <= 25.0.1 and <= 24.0.8 |
+| `Docker Desktop`       | <= 4.27.0               |
 
-### What should I do if I’m on an affected version?
+### What should I do if I'm on an affected version?
 
 If you are using affected versions of runc, BuildKit, Moby, or Docker Desktop, make sure to update to the latest versions, linked in the following table:
 
-|                        | Patched Versions          |
-|:-----------------------|:--------------------------|
-| `runc`                 | >= [1.1.12](https://github.com/opencontainers/runc/releases/tag/v1.1.12)                 |
-| `BuildKit`             | >= [0.12.5](https://github.com/moby/buildkit/releases/tag/v0.12.5)                 |
-| `Moby (Docker Engine)` | >= [25.0.2](https://github.com/moby/moby/releases/tag/v25.0.2) and >= [24.0.9](https://github.com/moby/moby/releases/tag/v24.0.9)   |
-| `Docker Desktop`       | >= [4.27.1](/manuals/desktop/release-notes.md#4271)                 |
-
+|                        | Patched Versions                                                                                                                  |
+| :--------------------- | :-------------------------------------------------------------------------------------------------------------------------------- |
+| `runc`                 | >= [1.1.12](https://github.com/opencontainers/runc/releases/tag/v1.1.12)                                                          |
+| `BuildKit`             | >= [0.12.5](https://github.com/moby/buildkit/releases/tag/v0.12.5)                                                                |
+| `Moby (Docker Engine)` | >= [25.0.2](https://github.com/moby/moby/releases/tag/v25.0.2) and >= [24.0.9](https://github.com/moby/moby/releases/tag/v24.0.9) |
+| `Docker Desktop`       | >= [4.27.1](/manuals/desktop/release-notes.md#4271)                                                                               |
 
-If you are unable to update to an unaffected version promptly, follow these best practices to mitigate risk: 
+If you are unable to update to an unaffected version promptly, follow these best practices to mitigate risk:
 
-* Only use trusted Docker images (such as [Docker Official Images](../docker-hub/image-library/trusted-content.md#docker-official-images)).
-* Don’t build Docker images from untrusted sources or untrusted Dockerfiles.
-* If you are a Docker Business customer using Docker Desktop and unable to update to v4.27.1, make sure to enable [Hardened Docker Desktop](/manuals/security/for-admins/hardened-desktop/_index.md) features such as:
-  * [Enhanced Container Isolation](/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md), which mitigates the impact of CVE-2024-21626 in the case of running containers from malicious images.
-  * [Image Access Management](for-admins/hardened-desktop/image-access-management.md), and [Registry Access Management](/manuals/security/for-admins/hardened-desktop/registry-access-management.md), which give organizations control over which images and repositories their users can access.
-* For CVE-2024-23650, CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653, avoid using BuildKit frontend from an untrusted source. A frontend image is usually specified as the #syntax line on your Dockerfile, or with `--frontend` flag when using the `buildctl build` command.
-* To mitigate CVE-2024-24557, make sure to either use BuildKit or disable caching when building images. From the CLI this can be done via the `DOCKER_BUILDKIT=1` environment variable (default for Moby >= v23.0 if the buildx plugin is installed) or the `--no-cache flag`. If you are using the HTTP API directly or through a client, the same can be done by setting `nocache` to `true` or `version` to `2` for the [/build API endpoint](https://docs.docker.com/engine/api/v1.44/#tag/Image/operation/ImageBuild).
+- Only use trusted Docker images (such as [Docker Official Images](../docker-hub/image-library/trusted-content.md#docker-official-images)).
+- Don't build Docker images from untrusted sources or untrusted Dockerfiles.
+- If you are a Docker Business customer using Docker Desktop and unable to update to v4.27.1, make sure to enable [Hardened Docker Desktop](/manuals/enterprise/security/hardened-desktop/_index.md) features such as:
+  - [Enhanced Container Isolation](/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/_index.md), which mitigates the impact of CVE-2024-21626 in the case of running containers from malicious images.
+  - [Image Access Management](/manuals/enterprise/security/hardened-desktop/image-access-management.md), and [Registry Access Management](/manuals/enterprise/security/hardened-desktop/registry-access-management.md), which give organizations control over which images and repositories their users can access.
+- For CVE-2024-23650, CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653, avoid using BuildKit frontend from an untrusted source. A frontend image is usually specified as the #syntax line on your Dockerfile, or with `--frontend` flag when using the `buildctl build` command.
+- To mitigate CVE-2024-24557, make sure to either use BuildKit or disable caching when building images. From the CLI this can be done via the `DOCKER_BUILDKIT=1` environment variable (default for Moby >= v23.0 if the buildx plugin is installed) or the `--no-cache flag`. If you are using the HTTP API directly or through a client, the same can be done by setting `nocache` to `true` or `version` to `2` for the [/build API endpoint](https://docs.docker.com/reference/api/engine/version/v1.44/#tag/Image/operation/ImageBuild).
 
 ### Technical details and impact
 
@@ -115,7 +207,7 @@ In Moby <= v25.0.1 and <= v24.0.8, the classic builder cache system is prone to
 
 _The issue has been fixed in Moby >= v25.0.2 and >= v24.0.9._
 
-### How are Docker products affected? 
+### How are Docker products affected?
 
 #### Docker Desktop
 
@@ -131,15 +223,15 @@ _No other Docker products are affected by these vulnerabilities._
 
 ### Advisory links
 
-* Runc
-  * [CVE-2024-21626](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv)
-* BuildKit
-  * [CVE-2024-23650](https://github.com/moby/buildkit/security/advisories/GHSA-9p26-698r-w4hx)
-  * [CVE-2024-23651](https://github.com/moby/buildkit/security/advisories/GHSA-m3r6-h7wv-7xxv)
-  * [CVE-2024-23652](https://github.com/moby/buildkit/security/advisories/GHSA-4v98-7qmw-rqr8)
-  * [CVE-2024-23653](https://github.com/moby/buildkit/security/advisories/GHSA-wr6v-9f75-vh2g)
-* Moby
-  * [CVE-2024-24557](https://github.com/moby/moby/security/advisories/GHSA-xw73-rw38-6vjc)
+- Runc
+  - [CVE-2024-21626](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv)
+- BuildKit
+  - [CVE-2024-23650](https://github.com/moby/buildkit/security/advisories/GHSA-9p26-698r-w4hx)
+  - [CVE-2024-23651](https://github.com/moby/buildkit/security/advisories/GHSA-m3r6-h7wv-7xxv)
+  - [CVE-2024-23652](https://github.com/moby/buildkit/security/advisories/GHSA-4v98-7qmw-rqr8)
+  - [CVE-2024-23653](https://github.com/moby/buildkit/security/advisories/GHSA-wr6v-9f75-vh2g)
+- Moby
+  - [CVE-2024-24557](https://github.com/moby/moby/security/advisories/GHSA-xw73-rw38-6vjc)
 
 ## Text4Shell CVE-2022-42889
 
@@ -147,7 +239,7 @@ _Last updated October 2022_
 
 [CVE-2022-42889](https://nvd.nist.gov/vuln/detail/CVE-2022-42889) has been discovered in the popular Apache Commons Text library. Versions of this library up to but not including 1.10.0 are affected by this vulnerability.
 
-We strongly encourage you to update to the latest version of [Apache Commons Text](https://commons.apache.org/proper/commons-text/download_text.cgi). 
+We strongly encourage you to update to the latest version of [Apache Commons Text](https://commons.apache.org/proper/commons-text/download_text.cgi).
 
 ### Scan images on Docker Hub
 
@@ -163,13 +255,13 @@ A number of [Docker Official Images](../docker-hub/image-library/trusted-content
 Apache Commons Text. The following lists Docker Official Images that
 may contain the vulnerable versions of Apache Commons Text:
 
-- [bonita](https://hub.docker.com/_/bonita) 
+- [bonita](https://hub.docker.com/_/bonita)
 - [Couchbase](https://hub.docker.com/_/couchbase)
-- [Geonetwork](https://hub.docker.com/_/geonetwork) 
+- [Geonetwork](https://hub.docker.com/_/geonetwork)
 - [neo4j](https://hub.docker.com/_/neo4j)
 - [sliverpeas](https://hub.docker.com/_/sliverpeas)
-- [solr](https://hub.docker.com/_/solr) 
-- [xwiki](https://hub.docker.com/_/xwiki) 
+- [solr](https://hub.docker.com/_/solr)
+- [xwiki](https://hub.docker.com/_/xwiki)
 
 We have updated
 Apache Commons Text in these images to the latest version. Some of these images may not be
@@ -216,23 +308,23 @@ Log4j 2 CVE-2021-44228. The following table lists Docker Official Images that
 may contained the vulnerable versions of Log4j 2. We updated Log4j 2 in these images to the latest version. Some of these images may not be
 vulnerable for other reasons. We recommend that you also review the guidelines published on the upstream websites.
 
-| Repository                | Patched version         | Additional documentation       |
-|:------------------------|:-----------------------|:-----------------------|
-| [couchbase](https://hub.docker.com/_/couchbase)    | 7.0.3 | [Couchbase blog](https://blog.couchbase.com/what-to-know-about-the-log4j-vulnerability-cve-2021-44228/) |
-| [Elasticsearch](https://hub.docker.com/_/elasticsearch)    | 6.8.22, 7.16.2 | [Elasticsearch announcement](https://www.elastic.co/blog/new-elasticsearch-and-logstash-releases-upgrade-apache-log4j2) |
-| [Flink](https://hub.docker.com/_/flink)    | 1.11.6, 1.12.7, 1.13.5, 1.14.2  | [Flink advice on Log4j CVE](https://flink.apache.org/2021/12/10/log4j-cve.html) |
-| [Geonetwork](https://hub.docker.com/_/geonetwork)    | 3.10.10 | [Geonetwork GitHub discussion](https://github.com/geonetwork/core-geonetwork/issues/6076) |
-| [lightstreamer](https://hub.docker.com/_/lightstreamer)     | Awaiting info | Awaiting info  |
-| [logstash](https://hub.docker.com/_/logstash)    | 6.8.22, 7.16.2 | [Elasticsearch announcement](https://www.elastic.co/blog/new-elasticsearch-and-logstash-releases-upgrade-apache-log4j2) |
-| [neo4j](https://hub.docker.com/_/neo4j)     | 4.4.2 | [Neo4j announcement](https://community.neo4j.com/t/log4j-cve-mitigation-for-neo4j/48856) |
-| [solr](https://hub.docker.com/_/solr)    | 8.11.1 | [Solr security news](https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228) |
-| [sonarqube](https://hub.docker.com/_/sonarqube)    | 8.9.5, 9.2.2 | [SonarQube announcement](https://community.sonarsource.com/t/sonarqube-sonarcloud-and-the-log4j-vulnerability/54721) |
-| [storm](https://hub.docker.com/_/storm)    | Awaiting info | Awaiting info |
+| Repository                                              | Patched version                | Additional documentation                                                                                                |
+| :------------------------------------------------------ | :----------------------------- | :---------------------------------------------------------------------------------------------------------------------- |
+| [couchbase](https://hub.docker.com/_/couchbase)         | 7.0.3                          | [Couchbase blog](https://blog.couchbase.com/what-to-know-about-the-log4j-vulnerability-cve-2021-44228/)                 |
+| [Elasticsearch](https://hub.docker.com/_/elasticsearch) | 6.8.22, 7.16.2                 | [Elasticsearch announcement](https://www.elastic.co/blog/new-elasticsearch-and-logstash-releases-upgrade-apache-log4j2) |
+| [Flink](https://hub.docker.com/_/flink)                 | 1.11.6, 1.12.7, 1.13.5, 1.14.2 | [Flink advice on Log4j CVE](https://flink.apache.org/2021/12/10/log4j-cve.html)                                         |
+| [Geonetwork](https://hub.docker.com/_/geonetwork)       | 3.10.10                        | [Geonetwork GitHub discussion](https://github.com/geonetwork/core-geonetwork/issues/6076)                               |
+| [lightstreamer](https://hub.docker.com/_/lightstreamer) | Awaiting info                  | Awaiting info                                                                                                           |
+| [logstash](https://hub.docker.com/_/logstash)           | 6.8.22, 7.16.2                 | [Elasticsearch announcement](https://www.elastic.co/blog/new-elasticsearch-and-logstash-releases-upgrade-apache-log4j2) |
+| [neo4j](https://hub.docker.com/_/neo4j)                 | 4.4.2                          | [Neo4j announcement](https://community.neo4j.com/t/log4j-cve-mitigation-for-neo4j/48856)                                |
+| [solr](https://hub.docker.com/_/solr)                   | 8.11.1                         | [Solr security news](https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228)         |
+| [sonarqube](https://hub.docker.com/_/sonarqube)         | 8.9.5, 9.2.2                   | [SonarQube announcement](https://community.sonarsource.com/t/sonarqube-sonarcloud-and-the-log4j-vulnerability/54721)    |
+| [storm](https://hub.docker.com/_/storm)                 | Awaiting info                  | Awaiting info                                                                                                           |
 
 > [!NOTE]
 >
 > Although [xwiki](https://hub.docker.com/_/xwiki) images may be detected as vulnerable
-by some scanners, the authors believe the images are not vulnerable by Log4j 2
-CVE as the API jars do not contain the vulnerability.
+> by some scanners, the authors believe the images are not vulnerable by Log4j 2
+> CVE as the API jars do not contain the vulnerability.
 > The [Nuxeo](https://hub.docker.com/_/nuxeo)
 > image is deprecated and will not be updated.
diff --git a/content/manuals/security/troubleshoot/_index.md b/content/manuals/security/troubleshoot/_index.md
deleted file mode 100644
index bcb88e4c1841..000000000000
--- a/content/manuals/security/troubleshoot/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-build:
-  render: never
-title: Troubleshoot
-weight: 40
----
\ No newline at end of file
diff --git a/content/manuals/security/troubleshoot/troubleshoot-sso.md b/content/manuals/security/troubleshoot/troubleshoot-sso.md
deleted file mode 100644
index ceae9fea46c2..000000000000
--- a/content/manuals/security/troubleshoot/troubleshoot-sso.md
+++ /dev/null
@@ -1,233 +0,0 @@
----
-description: Learn how to troubleshoot common SSO issues.
-keywords: sso, troubleshoot, single sign-on
-title: Troubleshoot single sign-on
-linkTitle: Troubleshoot SSO
-tags: [Troubleshooting]
-toc_max: 2
-aliases:
-    - "/security/for-admins/single-sign-on/troubleshoot/"
----
-
-While configuring or using single sign-on (SSO), you may encounter issues that
-can stem from your identity provider (IdP) or Docker configuration. The
-following sections describe some common SSO errors and possible solutions.
-
-## Check for errors
-
-If you experience issues with SSO, check both the Docker Admin Console and your identity provider (IdP) for errors first.
-
-### Check Docker error logs
-
-1. Sign in to the [Admin Console](https://app.docker.com/admin/) and select your organization.
-2. Select **SSO and SCIM**.
-3. In the SSO connections table, select the **Action** menu and then **View error logs**.
-4. For more details on specific errors, select **View error details** next to an error message.
-5. Note any errors you see on this page for further troubleshooting.
-
-### Check for errors in your IdP
-
-1. Review your IdP’s logs or audit trails for any failed authentication or provisioning attempts.
-2. Confirm that your IdP’s SSO settings match the values provided in Docker.
-3. If applicable, confirm that you have configured user provisioning correctly and that it is enabled in your IdP.
-4. If applicable, verify that your IdP correctly maps Docker's required user attributes.
-5. Try provisioning a test user from your IdP and verify if they appear in Docker.
-
-For further troubleshooting, check your IdP’s documentation. You can also contact their support team for guidance on error messages.
-
-## Groups are not formatted correctly
-
-### Error message
-
-When this issue occurs, the following error message is common:
-```text
-Some of the groups assigned to the user are not formatted as '<organization name>:<team name>'. Directory groups will be ignored and user will be provisioned into the default organization and team.
-```
-
-### Possible causes
-
-- Incorrect group name formatting in your identity provider (IdP): Docker requires groups to follow the format `<organization>:<team>`. If the groups assigned to a user do not follow this format, they will be ignored.
-- Non-matching groups between IdP and Docker organization: If a group in your IdP does not have a corresponding team in Docker, it will not be recognized, and the user will be placed in the default organization and team.
-
-### Affected environments
-
-- Docker single sign-on setup using IdPs such as Okta or Azure AD
-- Organizations using group-based role assignments in Docker
-
-### Steps to replicate
-
-To replicate this issue:
-1. Attempt to sign in to Docker using SSO.
-2. The user is assigned groups in the IdP but does not get placed in the expected Docker Team.
-3. Review Docker logs or IdP logs to find the error message.
-
-### Solutions
-
-Update group names in your IdP:
-1. Go to your IdP's group management section.
-2. Check the groups assigned to the affected user.
-3. Ensure each group follows the required format: `<organization>:<team>`
-4. Update any incorrectly formatted groups to match this pattern.
-5. Save changes and retry signing in with SSO.
-
-## User is not assigned to the organization
-
-### Error message
-
-When this issue occurs, the following error message is common:
-```text
-User '$username' is not assigned to this SSO organization. Contact your administrator. TraceID: XXXXXXXXXXXXX
-```
-
-### Possible causes
-
-- User is not assigned to the organization: If Just-in-Time (JIT) provisioning is disabled, the user may not be assigned to your organization.
-- User is not invited to the organization: If JIT is disabled and you do not want to enable it, the user must be manually invited.
-- SCIM provisioning is misconfigured: If you use SCIM for user provisioning, it may not be correctly syncing users from your IdP.
-
-### Solutions
-
-**Enable JIT provisioning**
-
-JIT is enabled by default when you enable SSO. If you have JIT disabled and need
-to re-enable it:
-
-1. Sign in to the [Admin Console](https://app.docker.com/admin) and select your organization.
-2. Select **SSO and SCIM**.
-3. In the SSO connections table, select the **Action** menu and then **Enable JIT provisioning**.
-4. Select **Enable** to confirm.
-
-**Manually invite users**
-
-When JIT is disabled, users are not automatically added to your organization when they authenticate through SSO.
-To manually invite users, see [Invite members](/manuals/admin/organization/members.md#invite-members)
-
-**Configure SCIM provisioning**
-
-If you have SCIM enabled, troubleshoot your SCIM connection using the following steps:
-
-1. Sign in to the [Admin Console](https://app.docker.com/admin) and select your organization.
-2. Select **SSO and SCIM**.
-3. In the SSO connections table, select the **Action** menu and then **View error logs**. For more details on specific errors, select **View error details** next to an error message. Note any errors you see on this page.
-4. Navigate back to the **SSO and SCIM** page of the Admin Console and verify your SCIM configuration:
-    - Ensure that the SCIM Base URL and API Token in your IdP match those provided in the Docker Admin Console.
-    - Verify that SCIM is enabled in both Docker and your IdP.
-5. Ensure that the attributes being synced from your IdP match Docker's [supported attributes](/manuals/security/for-admins/provisioning/scim.md#supported-attributes) for SCIM.
-6. Test user provisioning by trying to provision a test user through your IdP and verify if they appear in Docker.
-
-## IdP-initiated sign in is not enabled for connection
-
-### Error message
-
-When this issue occurs, the following error message is common:
-```text
-IdP-Initiated sign in is not enabled for connection '$ssoConnection'.
-```
-
-### Possible causes
-
-Docker does not support an IdP-initiated SAML flow. This error occurs when a user attempts to authenticate from your IdP, such as using the Docker SSO app tile on the sign in page.
-
-### Solutions
-
-**Authenticate from Docker apps**
-
-The user must initiate authentication from Docker applications (Hub, Desktop, etc). The user needs to enter their email address in a Docker app and they will get redirected to the configured SSO IdP for their domain.
-
-**Hide the Docker SSO app**
-
-You can hide the Docker SSO app from users in your IdP. This prevents users from attempting to start authentication from the IdP dashboard. You must hide and configure this in your IdP.
-
-## Not enough seats in organization
-
-### Error message
-
-When this issue occurs, the following error message is common:
-```text
-Not enough seats in organization '$orgName'. Add more seats or contact your administrator.
-```
-
-### Possible causes
-
-This error occurs when the organization has no available seats for the user when provisioning via Just-in-Time (JIT) provisioning or SCIM.
-
-### Solutions
-
-**Add more seats to the organization**
-
-Purchase additional Docker Business subscription seats. For details, see [Manage subscription seats](/manuals/subscription/manage-seats.md).
-
-**Remove users or pending invitations**
-
-Review your organization members and pending invitations. Remove inactive users or pending invitations to free up seats. For more details, see [Manage organization members](/manuals/admin/organization/members.md).
-
-## Domain is not verified for SSO connection
-
-### Error message
-
-When this issue occurs, the following error message is common:
-```text
-Domain '$emailDomain' is not verified for your SSO connection. Contact your company administrator. TraceID: XXXXXXXXXXXXXX
-```
-
-### Possible causes
-
-This error occurs if the IdP authenticated a user through SSO and the User Principal Name (UPN)
-returned to Docker doesn’t match any of the verified domains associated to the
-SSO connection configured in Docker.
-
-### Solutions
-
-**Verify UPN attribute mapping**
-
-Ensure that the IdP SSO connection is returning the correct UPN value in the assertion attributes.
-
-**Add and verify all domains**
-
-Add and verify all domains and subdomains used as UPN by your IdP and associate them with your Docker SSO connection. For details, see [Configure single sign-on](/manuals/security/for-admins/single-sign-on/configure.md).
-
-## Unable to find session
-
-### Error message
-
-When this issue occurs, the following error message is common:
-```text
-We couldn't find your session. You may have pressed the back button, refreshed the page, opened too many sign-in dialogs, or there is some issue with cookies. Try signing in again. If the issue persists, contact your administrator.
-```
-
-### Possible causes
-
-The following causes may create this issue:
-- The user pressed the back or refresh button during authentication.
-- The authentication flow lost track of the initial request, preventing completion.
-
-### Solutions
-
-**Do not disrupt the authentication flow**
-
-Do not press the back or refresh button during sign-in.
-
-**Restart authentication**
-
-Close the browser tab and restart the authentication flow from the Docker application (Desktop, Hub, etc).
-
-## Name ID is not an email address
-
-### Error message
-
-When this issue occurs, the following error message is common:
-```text
-The name ID sent by the identity provider is not an email address. Contact your company administrator.
-```
-
-### Possible causes
-
-The following causes may create this issue:
-- The IdP sends a Name ID (UPN) that does not comply with the email format required by Docker.
-- Docker SSO requires the Name ID to be the primary email address of the user.
-
-### Solutions
-
-In your IdP, ensure the Name ID attribute format is correct:
-1. Verify that the Name ID attribute format in your IdP is set to `EmailAddress`.
-2. Adjust your IdP settings to return the correct Name ID format.
\ No newline at end of file
diff --git a/content/manuals/subscription/_index.md b/content/manuals/subscription/_index.md
index 7cfa0d8d1f16..58e84d922711 100644
--- a/content/manuals/subscription/_index.md
+++ b/content/manuals/subscription/_index.md
@@ -1,49 +1,76 @@
 ---
-title: Subscription
-description: Learn about subscription features and how to manage your subscription
-keywords: Docker, pricing, billing, Pro, Team, business, subscription, tier, plan
-weight: 50
+title: Overview
+linkTitle: Subscription
+description: Learn about Docker plans, like how to subscribe to product-based plans and how they apply to personal and organization accounts.
+keywords:
+  docker subscription, pricing, billing, subscription types, subscription
+  plans, docker hardened images, gordon, cloud sandboxes, subscription
+  management
+weight: 20
 params:
   sidebar:
     group: Platform
 grid_subscriptions:
-- title: Docker subscriptions and features
-  description: Explore what you can do with your Docker subscription.
-  link: /subscription/details/
-  icon: feature_search
-- title: Set up your subscription
-  description: Get started setting up a personal or organization subscription.
-  link: /subscription/setup/
-  icon: shopping_cart
-- title: Scale your subscription
-  description: Scale your subscription to fit your needs.
-  link: /subscription/scale/
-  icon: leaderboard
-- title: Change your subscription
-  description: Learn how to upgrade or downgrade your plan.
-  link: /subscription/change/
-  icon: upgrade
-- title: Manage seats
-  description: Learn how to add or remove seats from your subscription.
-  link: /subscription/manage-seats/
-  icon: group_add
-- title: Docker Desktop license agreement
-  description: Review the terms of the Docker Subscription Service Agreement.
-  link: /subscription/desktop-license/
-  icon: license
-- title: Subscription FAQs
-  description: Find the answers you need and explore common questions.
-  link: /subscription/faq/
-  icon: help
+  - title: Compare Docker plans
+    description: Visit the pricing page to see what's included in different Docker plans.
+    link: "https://www.docker.com/pricing?ref=Docs&refAction=DocsSubscription"
+    icon: magnifying-glass
+  - title: Manage plans
+    description: Add a new plan, upgrade an active plan, or cancel auto-renewal.
+    link: /subscription/manage/
+    icon: shopping-cart
+  - title: Explore plans
+    description: Browse available Docker plans and add-ons for individuals, teams, and organizations.
+    link: /subscription/plans/
+    icon: chart-bar
+  - title: Docker Desktop license agreement
+    description: Review the terms of the Docker Subscription Service Agreement.
+    link: /subscription/desktop-license/
+    icon: document-text
+  - title: Plan FAQs
+    description: Find the answers you need and explore common questions.
+    link: /subscription/faq/
+    icon: question-mark-circle
 aliases:
-- /docker-hub/billing/
-- /docker-hub/billing/faq/
+  - /docker-hub/billing/
+  - /docker-hub/billing/faq/
 ---
 
-A Docker subscription includes licensing for commercial use of Docker products
-including Docker Desktop, Docker Hub, Docker Build Cloud, Docker Scout, and
-Testcontainers Cloud.
+You can subscribe to several Docker plans that range from free to paid plans. When you upgrade a plan, you expand your usage entitlements and feature sets for Docker products. You can also top up some plans, extending usage to more users without changing your plan type.
 
-Use the resources here to decide what subscription you need, or manage an existing subscription.
+## Docker plans
+
+You can subscribe to plans for individual or organization accounts, or plans for specific products. The following table summarizes the available plans.
+
+| Plans                                                                  | Billing model                                             | Types                                                     |
+| ---------------------------------------------------------------------- | --------------------------------------------------------- | --------------------------------------------------------- |
+| [Docker](/manuals/subscription/plans/docker.md)                        | Flat-rate plans for personal and organization accounts    | Docker Personal, Docker Pro, Docker Team, Docker Business |
+| [Docker Agentic Platform](/manuals/subscription/plans/docker-agentic-platform.md) | Pay-as-you-go (PayGo) for cloud sandbox usage             | Docker Agentic Platform                          |
+| [Docker Hardened Images (DHI)](/manuals/subscription/plans/dhi.md)     | Graduated security features for hardened container images | DHI Community, DHI Select, DHI Enterprise                 |
+| [Gordon](/manuals/subscription/plans/gordon.md)                        | Prepaid usage for the Gordon AI agent                     | Gordon Plus, Gordon Max, Gordon Ultra                     |
+| [AI Governance](/manuals/subscription/plans/ai-governance.md)          | Purchase set amount of licenses                           | AI Governance                                             |
+| [Docker Verified Publisher (DVP)](/manuals/subscription/plans/docker-verified-publisher.md)  | Annual plans based on consuming domains                   | DVP Starter, DVP Growth                                   |
+
+Docker plans that upgrade your account (Docker Pro or Docker Team and Business) can provide a foundation for most use cases. Some product plans may require an upgraded Docker account while other product plans let you subscribe without an upgraded account. To learn more, see [Docker plans](/manuals/subscription/plans/_index.md).
+
+## Top up your plan
+
+Plans come with usage entitlements that can be extended without upgrading to a different plan.
+
+| Unit              | Description                                                                           | Examples                      |
+| ----------------- | ------------------------------------------------------------------------------------- | ----------------------------- |
+| Seats             | Each seat extends entitlements to one more member.                                    | Docker Team, Docker Business  |
+| Licenses          | Access to specific products or features.                                              | AI Governance, Docker Offload |
+| Minutes           | Cloud build capacity, sold in blocks and consumed within the billing period.          | Docker Build Cloud            |
+| Repositories      | Additional container repositories covered by security scanning and analysis features. | DHI                           |
+| Consuming domains | Additional consuming domains tracked in publisher analytics, sold in blocks of 25.    | DVP Starter, DVP Growth       |
+
+## Manage your plans
+
+To subscribe to a new plan, you can self-serve through **Billing** in [Docker Home](https://app.docker.com), or by <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_index_sales" class="link" rel="noopener">contacting sales</a>.
+
+To learn more about adding a new plan or upgrading an active plan, see [Manage plans](/manuals/subscription/manage.md).
+
+## Next steps
 
 {{< grid items="grid_subscriptions" >}}
diff --git a/content/manuals/subscription/change.md b/content/manuals/subscription/change.md
deleted file mode 100644
index 5844598f1ba2..000000000000
--- a/content/manuals/subscription/change.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-description: Learn how to change your Docker subscription
-keywords: Docker Hub, upgrade, downgrade, subscription, Pro, Team, business, pricing plan
-title: Change your subscription
-aliases:
-- /docker-hub/upgrade/
-- /docker-hub/billing/upgrade/
-- /subscription/upgrade/
-- /subscription/downgrade/
-- /subscription/core-subscription/upgrade/
-- /subscription/core-subscription/downgrade/
-- /docker-hub/cancel-downgrade/
-- /docker-hub/billing/downgrade/
-- /billing/scout-billing/
-weight: 30
----
-
-{{% include "tax-compliance.md" %}}
-
-The following sections describe how to change plans when you have a Docker
-subscription plan or legacy Docker subscription plan.
-
-> [!NOTE]
->
-> Legacy Docker plans apply to Docker subscribers who last purchased or renewed
-> their subscription before December 10, 2024. These subscribers will keep
-> their current plan and pricing until their next renewal date that falls on or
-> after December 10, 2024. To see purchase or renewal history, view your
-> [billing history](../billing/history.md). For more details about legacy
-> subscriptions, see [Announcing Upgraded Docker
-> Plans](https://www.docker.com/blog/november-2024-updated-plans-announcement/).
-
-## Upgrade your subscription
-
-When you upgrade a Docker plan, you immediately have access to all the features and entitlements available in your Docker subscription plan. For detailed information on features available in each subscription, see [Docker Pricing](https://www.docker.com/pricing).
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-To upgrade your Docker subscription:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Optional. If you're upgrading from a free Personal plan to a Team plan and want to keep your username, [convert your user account into an organization](../admin/organization/convert-account.md).
-4. Select the account you want to upgrade in the drop-down at the top-left of the page.
-5. Select **Upgrade**.
-6. Follow the on-screen instructions to complete your upgrade.
-
-> [!NOTE]
->
-> If you choose to pay using a US bank account, you must verify the account. For
-> more information, see [Verify a bank account](manuals/billing/payment-method.md#verify-a-bank-account).
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-You can upgrade a legacy Docker Core, Docker Build Cloud, or Docker Scout subscription plan to a Docker subscription plan that includes access to all tools.
-
-Contact [Docker sales](https://www.docker.com/pricing/contact-sales/) to upgrade your legacy Docker plan.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Downgrade your subscription
-
-You can downgrade your Docker subscription at anytime before the renewal date. The unused portion of the subscription isn't refundable or creditable.
-
-When you downgrade your subscription, access to paid features is available until the next billing cycle. The downgrade takes effect on the next billing cycle.
-
-> [!IMPORTANT]
->
-> If you downgrade your personal account from a Pro subscription to a Personal subscription, note that [Personal subscriptions](details.md#docker-personal) don't include collaborators for private repositories. Only one private repository is included with a Personal subscription. When you downgrade, all collaborators will be removed and additional private repositories are locked.
-> Before you downgrade, consider the following:
-> - Team size: You may need to reduce the number of team members and convert any private repositories to public repositories or delete them. For information on features available in each tier, see [Docker Pricing](https://www.docker.com/pricing).
-> - SSO and SCIM: If you want to downgrade a Docker Business subscription and your organization uses single sign-on (SSO) for user authentication, you need to remove your SSO connection and verified domains before downgrading. After removing the SSO connection, any organization members that were auto-provisioned (for example, with SCIM) need to set up a password to sign in without SSO. To do this, users can [reset their password at sign in](/accounts/create-account/#reset-your-password-at-sign-in).
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-If you have a [sales-assisted Docker Business subscription](details.md#sales-assisted), contact your account manager to downgrade your subscription.
-
-To downgrade your Docker subscription:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Select the account you want to downgrade in the drop-down at the top-left of the page.
-4. Select the action icon and then **Cancel subscription**.
-5. Fill out the feedback survey to continue with cancellation.
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-If you have a [sales-assisted Docker Business subscription](details.md#sales-assisted), contact your account manager to downgrade your subscription.
-
-### Downgrade Legacy Docker plan
-
-To downgrade your legacy Docker subscription:
-
-1. Sign in to [Docker Hub Billing](https://hub.docker.com/billing).
-2. Select the account you want to downgrade in the drop-down at the top-left of the page.
-3. Select the link to **Manage this account on Docker Hub**.
-4. In the plan section, select **Change plan**.
-5. Follow the on-screen instructions to complete your downgrade.
-
-### Downgrade Docker Build Cloud subscription
-
-To downgrade your Docker Build Cloud subscription:
-
-1. Sign in to [Docker Home](https://app.docker.com) and open **Docker Build Cloud**.
-2. Select **Account settings**, then **Downgrade**.
-3. To confirm your downgrade, type **DOWNGRADE** in the text field and select **Yes, continue**.
-4. The account settings page will update with a notification bar notifying you of your downgrade date (start of next billing cycle).
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Pause a subscription
-
-You can't pause or delay a subscription. If a subscription invoice hasn't been paid on the due date, there's a 15 day grace period, including the due date.
\ No newline at end of file
diff --git a/content/manuals/subscription/desktop-license.md b/content/manuals/subscription/desktop-license.md
index a0c129a2ab97..4b23bbf19ed2 100644
--- a/content/manuals/subscription/desktop-license.md
+++ b/content/manuals/subscription/desktop-license.md
@@ -1,20 +1,35 @@
 ---
 title: Docker Desktop license agreement
-description: Information about Docker Desktop's license agreement
-keywords: license agreement, docker desktop, subscription
+description: Information about Docker Desktop's license agreement and commercial use requirements
+keywords: docker desktop license, subscription service agreement, commercial use, licensing terms
 weight: 40
+aliases:
+  - /subscription/products/desktop-license/
+  - /subscription/plans/desktop-license/
 ---
 
-Docker Desktop is licensed under the Docker Subscription Service Agreement. When you download and install Docker Desktop, you will be asked to agree to the updated terms.
+Docker Desktop is licensed under the [Docker Subscription Service Agreement](https://www.docker.com/legal/docker-subscription-service-agreement). When you download and install Docker Desktop, you're asked to agree to these terms.
 
-Our [Docker Subscription Service Agreement](https://www.docker.com/legal/docker-subscription-service-agreement) states:
+The Docker Subscription Service Agreement states:
 
- - Docker Desktop is free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.
- - Otherwise, it requires a paid subscription for professional use.
-- Paid subscriptions are also required for government entities.
-- The Docker Pro, Team, and Business subscriptions include commercial use of Docker Desktop.
+- Docker Desktop is free for:
+  - Small businesses (fewer than 250 employees AND less than $10 million in annual revenue)
+  - Personal use
+  - Education
+  - Non-commercial open source projects
+- Docker Desktop requires a paid subscription for:
+  - Professional use in larger organizations
+  - Government entities
+  - Commercial use beyond the free tier limits
+- Paid subscriptions that include Docker Desktop:
+  - Docker Pro, Team, and Business subscriptions
 
-Read the [Blog](https://www.docker.com/blog/updating-product-subscriptions/) and [Docker subscription FAQs](https://www.docker.com/pricing/faq) to learn how this may affect companies using Docker Desktop.
+## Understanding licensing terms
+
+For detailed information about how these terms may affect your organization, see:
+
+- [Subscription updates blog post](https://www.docker.com/blog/updating-product-subscriptions/)
+- [Docker subscription FAQs](https://www.docker.com/pricing/faq) to learn how this may affect companies using Docker Desktop.
 
 > [!NOTE]
 >
@@ -22,9 +37,7 @@ Read the [Blog](https://www.docker.com/blog/updating-product-subscriptions/) and
 
 Docker Desktop is built using open-source software. For information about the licensing of open-source components in Docker Desktop, select the whale menu > **About Docker Desktop** > **Acknowledgements**.
 
-Docker Desktop distributes some components that are licensed under the
-GNU General Public License. Select [here](https://download.docker.com/opensource/License.tar.gz) to download the source for these components.
+## Open source components
 
-> [!TIP]
->
-> Explore [Docker subscriptions](https://www.docker.com/pricing/) to see what else Docker can offer you.
+Docker Desktop distributes some components that are licensed under the
+GNU General Public License. [Download the source code for these components here](https://download.docker.com/opensource/License.tar.gz).
diff --git a/content/manuals/subscription/details.md b/content/manuals/subscription/details.md
deleted file mode 100644
index 593be8efe66b..000000000000
--- a/content/manuals/subscription/details.md
+++ /dev/null
@@ -1,397 +0,0 @@
----
-title: Docker subscriptions and features
-linkTitle: Subscriptions and features
-description: Learn about Docker subscription tiers and their features
-keywords: subscription, personal, pro, team, business, features, docker subscription
-aliases:
-- /subscription/core-subscription/details/
-weight: 10
----
-
-Docker subscription plans empower development teams by providing the tools they need to ship secure, high-quality apps — fast. These plans include access to Docker's suite of products:
-
-- [Docker Desktop](../desktop/_index.md): The industry-leading container-first
-  development solution that includes, Docker Engine, Docker CLI, Docker Compose,
-  Docker Build/BuildKit, and Kubernetes.
-- [Docker Hub](../docker-hub/_index.md): The world's largest cloud-based
-  container registry.
-- [Docker Build Cloud](../build-cloud/_index.md): Powerful cloud-based builders that accelerate build times by up to 39x.
-- [Docker Scout](../scout/_index.md): Tooling for software supply chain security
-  that lets you quickly assess image health and accelerate security improvements.
-- [Testcontainers Cloud](https://testcontainers.com/cloud/docs): Container-based
-  testing automation that provides faster tests, a unified developer experience,
-  and more.
-
-The following sections describe some of the key features included with your
-Docker subscription plan or Legacy Docker plan.
-
-> [!NOTE]
->
-> Legacy Docker plans apply to Docker subscribers who last purchased or renewed their subscription before December 10, 2024. These subscribers will keep their current plan and pricing until their next renewal date that falls on or after December 10, 2024. To see purchase or renewal history, view your [billing history](../billing/history.md). For more details about Docker legacy plans, see [Announcing Upgraded Docker Plans](https://www.docker.com/blog/november-2024-updated-plans-announcement/).
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-## Docker Personal
-
-**Docker Personal** is ideal for open source communities, individual developers,
-education, and small businesses. It includes the free use of essential Docker
-tools as well as trials for powerful tools that'll level up your development loops.
-
-Docker Personal includes:
-
-- 1 included repository with continuous vulnerability analysis in Docker Scout
-- Unlimited public Docker Hub repositories
-- 200 pulls per 6 hours Docker Hub image pull rate limit for authenticated users
-- 7-day Docker Build Cloud trial
-- 7-day Testcontainers Cloud trial
-
-Docker Personal users who want to continue using Docker Build Cloud or Docker
-Testcontainers Cloud after their trial can upgrade to a Docker Pro plan at any
-time.
-
-All unauthenticated users, including unauthenticated Docker Personal users, get
-100 pulls per 6 hours per IPv4 address or IPv6 /64 subnet.
-
-For a list of features available in each tier, see [Docker Pricing](https://www.docker.com/pricing/).
-
-## Docker Pro
-
-**Docker Pro** enables individual developers to get more control of their
-development environment and provides an integrated and reliable developer
-experience. It reduces the amount of time developers spend on mundane and
-repetitive tasks and empowers developers to spend more time creating value for
-their customers. A Docker Pro subscription includes access to all tools,
-including Docker Desktop, Docker Hub, Docker Scout, Docker Build Cloud, and
-Testcontainers Cloud.
-
-Docker Pro includes:
-
-- 200 Docker Build Cloud build minutes per month. Docker Build Cloud minutes do not
-rollover month to month.
-- 2 included repositories with continuous vulnerability analysis in Docker Scout.
-- 100 Testcontainers Cloud runtime minutes per month for use either in Docker Desktop or for CI. Testcontainers Cloud runtime minutes do not rollover month to month.
-- No Docker Hub image pull rate limits.
-
-For a list of features available in each tier, see [Docker
-Pricing](https://www.docker.com/pricing/).
-
-## Docker Team
-
-**Docker Team** offers capabilities for collaboration, productivity, and
-security across organizations. It enables groups of developers to unlock the
-full power of collaboration and sharing combined with essential security
-features and team management capabilities. A Docker Team subscription includes
-licensing for commercial use of Docker components including Docker Desktop,
-Docker Hub, Docker Scout, Docker Build Cloud, and Testcontainers Cloud.
-
-Docker Team includes:
-
-- 500 Docker Build Cloud build minutes per month. Docker Build Cloud minutes do not
-rollover month to month.
-- Unlimited Docker Scout repositories with continuous vulnerability analysis.
-- 500 Testcontainers Cloud runtime minutes per month for use either in Docker Desktop or for CI. Testcontainers Cloud runtime minutes do not rollover month to month.
-- No Docker Hub image pull rate limits.
-
-There are also advanced collaboration and management tools, including
-organization and team management with [Role Based Access Control
-(RBAC)](/security/for-admins/roles-and-permissions/), [activity logs](/admin/organization/activity-logs/), and more.
-
-For a list of features available in each tier, see [Docker
-Pricing](https://www.docker.com/pricing/).
-
-## Docker Business
-
-**Docker Business** offers centralized management and advanced security features
-for enterprises that use Docker at scale. It empowers leaders to manage their
-Docker development environments and speed up their secure software supply chain
-initiatives. A Docker Business subscription includes licensing for commercial use of
-Docker components including Docker Desktop, Docker Hub, Docker Scout, Docker
-Build Cloud, and Testcontainers Cloud.
-
-Docker Business includes:
-
-- 1500 Docker Build Cloud build minutes per month. Docker Build Cloud minutes do not
-rollover month to month.
-- Unlimited Docker Scout repositories with continuous vulnerability analysis.
-- 1500 Testcontainers Cloud runtime minutes per month for use either in Docker Desktop or for CI. Testcontainers Cloud runtime minutes do not rollover month to month.
-- No Docker Hub image pull rate limits.
-
-In addition, you gain access to enterprise-grade features, such as:
-- [Hardened Docker Desktop](../security/for-admins/hardened-desktop/_index.md)
-- [Image Access
-  Management](../security/for-admins/hardened-desktop/image-access-management.md)
-  which lets admins control what content developers can access
-- [Registry Access
-  Management](../security/for-admins/hardened-desktop/registry-access-management.md)
-  which lets admins control what registries developers can access
-- [Company layer](/admin/company/) to manage multiple organizations and settings
-- [Single sign-on](/security/for-admins/single-sign-on/)
-- [System for Cross-domain Identity
-  Management](/security/for-admins/provisioning/scim/)
-
-For a list of features available in each tier, see [Docker
-Pricing](https://www.docker.com/pricing/).
-
-## Self-serve
-
-A self-serve Docker subscription is where everything is set up by you.
-You can:
-
-- Manage your own invoices
-- Add or remove seats
-- Update billing and payment information
-- Downgrade your subscription at any time
-
-## Sales-assisted
-
-A sales-assisted plan refers to a Docker Business or Team subscription where everything is set up and
-managed by a dedicated Docker account manager.
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plans" >}}
-
-> [!IMPORTANT]
->
-> As of December 10, 2024, Docker Core, Docker Build Cloud, and Docker Scout
-> subscription plans are no longer available and have been replaced by Docker subscription
-> plans that provide access to all tools. If you subscribed or renewed
-> your subscriptions before December 10, 2024, your legacy Docker
-> plans still apply to your account until you renew. For more details,
-> see [Announcing Upgraded Docker
-> Plans](https://www.docker.com/blog/november-2024-updated-plans-announcement/).
-The following describes some of the key features included with your Legacy Docker plans:
-
-![Docker Core subscription diagram](./images/subscription-diagram.webp)
-
-## Legacy Docker plans
-
-### Legacy Docker Pro
-
-**Legacy Docker Pro** enables individual developers to get more control of their
-development environment and provides an integrated and reliable developer
-experience. It reduces the amount of time developers spend on mundane and
-repetitive tasks and empowers developers to spend more time creating value for
-their customers.
-
-Legacy Docker Pro includes:
-- Unlimited public repositories
-- Unlimited [Scoped Access Tokens](/security/for-developers/access-tokens/)
-- Unlimited [collaborators](/docker-hub/repos/manage/access/#collaborators) for public repositories at no cost per month.
-- Access to [Legacy Docker Scout Free](#legacy-docker-scout-free) to get started with software supply chain security.
-- Unlimited private repositories
-- 5000 image [pulls per day](/manuals/docker-hub/usage/pulls.md)
-- [Auto Builds](/docker-hub/builds/) with 5 concurrent builds
-- 300 [Vulnerability Scans](/docker-hub/vulnerability-scanning/)
-
-For a list of features available in each legacy tier, see [Legacy Docker Pricing](https://www.docker.com/legacy-pricing/).
-
-#### Upgrade your Legacy Docker Pro plan
-
-When you upgrade your Legacy Docker Pro plan to a Docker Pro subscription plan, your plan includes the following changes:
-
-- Docker Build Cloud build minutes increased from 100/month to 200/month and no monthly fee. Docker Build Cloud minutes do not rollover month to month.
-- 2 included repositories with continuous vulnerability analysis in Docker Scout.
-- 100 Testcontainers Cloud runtime minutes are now included for use either in Docker Desktop or for CI. Testcontainers Cloud runtime minutes do not rollover month to month.
-- Docker Hub image pull rate limits are removed.
-
-For a list of features available in each tier, see [Docker Pricing](https://www.docker.com/pricing/).
-
-### Legacy Docker Team
-
-**Legacy Docker Team** offers capabilities for collaboration, productivity, and
-security across organizations. It enables groups of developers to unlock the
-full power of collaboration and sharing combined with essential security
-features and team management capabilities. A Docker Team subscription includes
-licensing for commercial use of Docker components including Docker Desktop and
-Docker Hub.
-
-Legacy Docker Team includes:
-- Everything included in legacy Docker Pro
-- Unlimited teams
-- [Auto Builds](/docker-hub/builds/) with 15 concurrent builds
-- Unlimited [Vulnerability Scanning](/docker-hub/vulnerability-scanning/)
-- 5000 image [pulls per day](/manuals/docker-hub/usage/pulls.md) for each team member
-
-There are also advanced collaboration and management tools, including organization and team management with [Role Based Access Control (RBAC)](/security/for-admins/roles-and-permissions/), [activity logs](/admin/organization/activity-logs/), and more.
-
-For a list of features available in each legacy tier, see [Legacy Docker Pricing](https://www.docker.com/legacy-pricing/).
-
-#### Upgrade your Legacy Docker Team plan
-
-When you upgrade your Legacy Docker Team plan to a Docker Team subscription plan, your plan includes the following changes:
-
-- Instead of paying an additional per-seat fee, Docker Build Cloud is now available to all users in your Docker plan.
-- Docker Build Cloud build minutes increase from 400/mo to 500/mo. Docker Build Cloud minutes do not rollover month to month.
-- Docker Scout now includes unlimited repositories with continuous vulnerability analysis, an increase from 3.
-- 500 Testcontainers Cloud runtime minutes are now included for use either in Docker Desktop or for CI. Testcontainers Cloud runtime minutes do not rollover month to month.
-- Docker Hub image pull rate limits are removed.
-- The minimum number of users is 1 (lowered from 5).
-
-For a list of features available in each tier, see [Docker Pricing](https://www.docker.com/pricing/).
-
-### Legacy Docker Business
-
-**Legacy Docker Business** offers centralized management and advanced security features
-for enterprises that use Docker at scale. It empowers leaders to manage their
-Docker development environments and speed up their secure software supply chain
-initiatives. A Docker Business subscription includes licensing for commercial
-use of Docker components including Docker Desktop and Docker Hub.
-
-Legacy Docker Business includes:
-- Everything included in legacy Docker Team
-- [Hardened Docker Desktop](../security/for-admins/hardened-desktop/_index.md)
-- [Image Access Management](../security/for-admins/hardened-desktop/image-access-management.md) which lets admins control what content developers can access
-- [Registry Access Management](../security/for-admins/hardened-desktop/registry-access-management.md) which lets admins control what registries developers can access
-- [Company layer](/admin/company/) to manage multiple organizations and settings
-- [Single Sign-On](/security/for-admins/single-sign-on/)
-- [System for Cross-domain Identity Management](/security/for-admins/provisioning/scim/) and more.
-
-For a list of features available in each tier, see [Legacy Docker Pricing](https://www.docker.com/legacy-pricing/).
-
-#### Upgrade your Legacy Docker Business plan
-
-When you upgrade your Legacy Docker Business plan to a Docker Business subscription plan, your plan includes the following changes:
-
-- Instead of paying an additional per-seat fee, Docker Build Cloud is now available to all users in your Docker plan.
-- Docker Build Cloud included minutes increase from 800/mo to 1500/mo. Docker Build Cloud minutes do not rollover month to month.
-- Docker Scout now includes unlimited repositories with continuous vulnerability analysis, an increase from 3.
-- 1500 Testcontainers Cloud runtime minutes are now included for use either in Docker Desktop or for CI. Testcontainers Cloud runtime minutes do not rollover month to month.
-- Docker Hub image pull rate limits are removed.
-
-For a list of features available in each tier, see [Docker Pricing](https://www.docker.com/pricing/).
-
-#### Self-serve
-
-A self-serve Docker Business subscription is where everything is set up by you. You can:
-
-- Manage your own invoices
-- Add or remove seats
-- Update billing and payment information
-- Downgrade your subscription at any time
-
-#### Sales-assisted
-
-A sales-assisted Docker Business subscription where everything is set up and managed by a dedicated Docker account manager.
-
-## Legacy Docker Scout subscriptions
-
-This section provides an overview of the legacy subscription plans for Docker
-Scout.
-
-> [!IMPORTANT]
->
-> As of December 10, 2024, Docker Scout subscriptions are no longer available
-> and have been replaced by Docker subscription plans that provide access to
-> all tools. If you subscribed or renewed your subscriptions before December 10, 2024, your legacy Docker subscriptions still apply to your account until
-> you renew. For more details, see [Announcing Upgraded Docker
-> Plans](https://www.docker.com/blog/november-2024-updated-plans-announcement/).
-
-### Legacy Docker Scout Free
-
-Legacy Docker Scout Free is available for organizations. If you have a Legacy Docker plan, you automatically have access to legacy Docker Scout Free.
-
-Legacy Docker Scout Free includes:
-
-- Unlimited local image analysis
-- Up to 3 Docker Scout-enabled repositories
-- SDLC integration, including policy evaluation and workload integration
-- On-prem and cloud container registry integrations
-- Security posture reporting
-
-### Legacy Docker Scout Team
-
-Legacy Docker Scout Team includes:
-
-- All the features available in legacy Docker Scout Free
-- In addition to 3 Docker Scout-enabled repositories, add up to 100 repositories when you buy your subscription
-
-### Legacy Docker Scout Business
-
-Legacy Docker Scout Business includes:
-
-- All the features available in legacy Docker Scout Team
-- Unlimited Docker Scout-enabled repositories
-
-### Upgrade your Legacy Docker Scout plan
-
-When you upgrade your Legacy Docker Scout plan to a Docker subscription plan, your
-plan includes the following changes:
-
-- Docker Business: Unlimited repositories with continuous vulnerability analysis, an increase from 3.
-- Docker Team: Unlimited repositories with continuous vulnerability analysis, an increase from 3
-- Docker Pro: 2 included repositories with continuous vulnerability analysis.
-- Docker Personal: 1 included repository with continuous vulnerability analysis.
-
-For a list of features available in each tier, see [Docker Pricing](https://www.docker.com/pricing/).
-
-## Legacy Docker Build Cloud subscriptions
-
- This section describes the features available for the different legacy Docker
- Build Cloud subscription tiers.
-
-> [!IMPORTANT]
->
-> As of December 10, 2024, Docker Build Cloud is only available with the
-> new Docker Pro, Team, and Business plans. When your plan renews on or after
-> December 10, 2024, you will see an increase in your included Build Cloud
-> minutes each month. For more details, see [Announcing Upgraded Docker
-> Plans](https://www.docker.com/blog/november-2024-updated-plans-announcement/).
-
-### Legacy Docker Build Cloud Starter
-
-If you have a Legacy Docker plan, a base level of Build Cloud
-minutes and cache are included. The features available vary depending on your
-Legacy Docker plan subscription tier.
-
-#### Legacy Docker Pro
-
-- 100 build minutes every month
-- Available for one user
-- 4 parallel builds
-
-#### Legacy Docker Team
-
-- 400 build minutes every month shared across your organization
-- Option to onboard up to 100 members
-- Can buy additional seats to add more minutes
-
-#### Legacy Docker Business
-
-- All the features listed for Docker Team
-- 800 build minutes every month shared across your organization
-
-### Legacy Docker Build Cloud Team
-
-Legacy Docker Build Cloud Team offers the following features:
-
-- 200 additional build minutes per seat
-- Option to buy reserve minutes
-- Increased shared cache
-
-The legacy Docker Build Cloud Team subscription is tied to a Docker
-[organization](/admin/organization/). To use the build minutes or
-shared cache of a legacy Docker Build Cloud Team subscription, users must be a part of
-the organization associated with the subscription. See Manage seats and invites.
-
-### Legacy Docker Build Cloud Enterprise
-
-For more details about your enterprise subscription, [contact sales](https://www.docker.com/products/build-cloud/#contact_sales).
-
-### Upgrade your Legacy Docker Build Cloud plan
-
-You no longer need to subscribe to a separate Docker Build Cloud plan to access
-Docker Build Cloud or to scale your minutes. When you upgrade your Legacy Docker plan to
-a Docker subscription plan, your plan includes the following changes:
-
-- Docker Business: Included minutes are increased from 800/mo to 1500/mo with the option to scale more minutes.
-- Docker Team: Included minutes are increased from 400/mo to 500/mo with the option to scale more minutes.
-- Docker Pro: Included minutes are increased from 100/mo to 200/mo with the option to scale more minutes.
-- Docker Personal: You receive a 7-day trial.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-## Support for subscriptions
-
-All Docker Pro, Team, and Business subscribers receive email support for their subscriptions.
\ No newline at end of file
diff --git a/content/manuals/subscription/faq.md b/content/manuals/subscription/faq.md
index b4713d9b6326..8e009b0a99a7 100644
--- a/content/manuals/subscription/faq.md
+++ b/content/manuals/subscription/faq.md
@@ -1,30 +1,35 @@
 ---
-description: FAQs on Docker subscriptions
-keywords: Docker, Docker Hub, subscription FAQs, subscription, platform
-title: Subscription FAQs
+title: Plan FAQs
 linkTitle: FAQs
+description: Frequently asked questions about Docker subscriptions and billing
+keywords: subscription faqs, docker billing, subscription transfer, academic pricing, docker programs
 tags: [FAQ]
-weight: 50
+weight: 30
 ---
 
-For more information on Docker subscriptions, see [Docker subscription overview](_index.md).
+For more information on Docker subscriptions, see [Docker subscription overview](_index.md).  
 
-### Can I transfer my subscription from one user or organization account to another?
+## Can I transfer my subscription from one user or organization account to another?
 
-Subscriptions are non-transferable.
+Subscriptions are non-transferable between accounts or organizations.
 
-### Can I pause or delay my Docker subscription?
+## Can I pause or delay my Docker subscription?
 
-You can't pause or delay a subscription, but you can [downgrade](change.md). If a subscription invoice hasn't been paid on the due date, there's a 15 day grace period, including the due date.
+You can't pause or delay a subscription, but you can downgrade your subscription. If a subscription invoice isn't paid by the due date, there's a 15-day grace period starting from the due date.
 
-### Does Docker offer academic pricing?
+## Does Docker offer academic pricing?
 
-Contact the [Docker Sales Team](https://www.docker.com/company/contact).
+Contact the [Docker Sales Team](https://www.docker.com/company/contact) for information about academic pricing options.
 
-### What ways can I contribute to Docker content?
+## How can I contribute to Docker content?
 
-Docker offers two programs:
-- [Docker-Sponsored Open Source Program (DSOS)](../docker-hub/repos/manage/trusted-content/dsos-program.md)
-- [Docker Verified Publisher (DVP)](../docker-hub/repos/manage/trusted-content/dvp-program.md)
+Docker offers two content contribution programs:
 
-You can also join the [Developer Preview Program](https://www.docker.com/community/get-involved/developer-preview/) or sign up for early access programs for specific products to participate in research and try out new features.
+- [Docker-Sponsored Open Source Program (DSOS)](../docker-hub/repos/manage/trusted-content/dsos-program.md) for open source projects
+- [Docker Verified Publisher (DVP)](../docker-hub/repos/manage/trusted-content/dvp-program.md) for commercial publishers
+
+You can also join the [Developer Preview Program](https://www.docker.com/community/get-involved/developer-preview/) or sign up for early access programs to participate in research and try new features.
+
+> [!TIP]
+> 
+> Need to upgrade? <a href="https://www.docker.com/pricing?ref=Docs&refAction=DocsSubscriptionFaq" id="pricing-link" class="link" rel="noopener">Compare Docker Team and Docker Business</a> to choose the plan that best fits your team's needs.
\ No newline at end of file
diff --git a/content/manuals/subscription/images/subscription-diagram.webp b/content/manuals/subscription/images/subscription-diagram.webp
deleted file mode 100644
index 58ef49cc4acd..000000000000
Binary files a/content/manuals/subscription/images/subscription-diagram.webp and /dev/null differ
diff --git a/content/manuals/subscription/manage-seats.md b/content/manuals/subscription/manage-seats.md
deleted file mode 100644
index bfe663080969..000000000000
--- a/content/manuals/subscription/manage-seats.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-description: Learn how to add or remove seats for an existing subscription
-keywords: Docker, Docker Hub, subscription, update, add, seats, pricing
-title: Manage subscription seats
-linkTitle: Manage seats
-aliases:
-- /docker-hub/billing/add-seats/
-- /subscription/add-seats/
-- /docker-hub/billing/remove-seats/
-- /subscription/remove-seats/
-- /subscription/core-subscription/add-seats/
-- /subscription/core-subscription/remove-seats/
-weight: 20
----
-
-You can add seats at anytime to your existing subscription.
-
-When you add seats to your subscription in the middle of your billing cycle, you are charged a prorated amount for the additional seats.
-
-{{% include "tax-compliance.md" %}}
-
-## Add seats
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-> [!IMPORTANT]
->
-> If you have a [sales-assisted Docker Business subscription](details.md#sales-assisted), contact your account manager to add seats to your subscription.
-
-To add seats to your subscription:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Select your account from the drop-down menu in the top-left.
-4. Select **Add seats**.
-5. Follow the on-screen instructions to complete adding seats.
-
-> [!NOTE]
->
-> If you choose to pay using a US bank account, you must verify the account. For
-> more information, see [Verify a bank account](manuals/billing/payment-method.md#verify-a-bank-account).
-
-You can now add more members to your organization. For more information, see [Manage organization members](../admin/organization/members.md).
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-> [!IMPORTANT]
->
-> If you have a [sales-assisted Docker Business subscription](details.md#sales-assisted), contact your account manager to add seats to your subscription.
-
-### Add seats to Legacy Docker plan
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your avatar in the top-left, and select **Billing** from the drop-down menu.
-3. On the Billing page, select **Add seats**.
-4. Select the number of seats you want to add, then select **Purchase**.
-
-### Add seats to Docker Build Cloud
-
-1. Sign in to Docker Build Cloud.
-2. Select **Account settings**, then **Add seats**.
-3. Select the number of seats you want to add, then select **Add seats**.
-
-{{< /tab >}}
-{{< /tabs >}}
-
-### Volume pricing
-
-Docker offers volume pricing for Docker Business subscriptions starting at 25 seats. Contact the [Docker Sales Team](https://www.docker.com/pricing/contact-sales/) for more information.
-
-## Remove seats
-
-You can remove seats from your Team or Business subscription at anytime.
-
-If you remove seats in the middle of the billing cycle, changes apply in the next billing cycle. Any unused portion of the subscription for removed seats isn't refundable or creditable.
-
-For example, if you receive your billing on the 8th of every month for 10 seats and you want to remove 2 seats on the 15th of the month, the 2 seats will be removed from your subscription the next month. Your payment for 8 seats begins on the next billing cycle. If you're on the annual subscription, the 2 seats are still available until the next year, and your payment for the 8 seats begins on the next billing cycle.
-
-{{< tabs >}}
-{{< tab name="Docker plan" >}}
-
-> [!IMPORTANT]
->
-> If you have a [sales-assisted Docker Business subscription](details.md#sales-assisted), contact your account manager to remove seats from your subscription.
-
-To remove seats:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. Select your account from the drop-down menu in the top-left.
-4. Select the action icon and then select **Remove seats**.
-5. Follow the on-screen instructions to complete removing seats.
-
-You can cancel the removal of seats before your next billing cycle. To do so, select **Cancel change**.
-
-{{< /tab >}}
-{{< tab name="Legacy Docker plan" >}}
-
-> [!IMPORTANT]
->
-> If you have a [sales-assisted Docker Business subscription](details.md#sales-assisted), contact your account manager to remove seats from your subscription.
-
-### Remove seats from Legacy Docker plan
-
-1. Sign in to [Docker Hub](https://hub.docker.com).
-2. Select your avatar in the top-left, and select **Billing** from the drop-down menu.
-3. On the Billing page, select **Remove seats**.
-4. Follow the on-screen instructions to complete removing seats.
-
-### Remove seats from Docker Build Cloud
-
-1. Sign in to [Docker Build Cloud](https://app.docker.com/build).
-2. Select **Account settings**, then **Remove seats**.
-3. Follow the on-screen instructions to complete removing seats.
-
-{{< /tab >}}
-{{< /tabs >}}
\ No newline at end of file
diff --git a/content/manuals/subscription/manage.md b/content/manuals/subscription/manage.md
new file mode 100644
index 000000000000..33d8d961e25c
--- /dev/null
+++ b/content/manuals/subscription/manage.md
@@ -0,0 +1,88 @@
+---
+title: Manage plans
+linkTitle: Manage
+description: >
+  Learn how to set up, upgrade, downgrade, or cancel plans, and how to
+  manage auto-renewal and credits.
+keywords:
+  purchase subscription, buy docker subscription, product catalog, browse
+  products, upgrade subscription, downgrade subscription, docker billing, cancel auto-renewal, cancel, top up, manage
+weight: 20
+aliases:
+  - /subscription/change/
+  - /subscription/setup/
+  - /docker-hub/upgrade/
+  - /docker-hub/billing/upgrade/
+  - /subscription/upgrade/
+  - /subscription/core-subscription/upgrade/
+  - /billing/scout-billing/
+  - /billing/subscription-management/
+---
+
+You can add and manage your plans from the billing portal in Docker Home. Within the billing portal, you use the product catalog to view
+self-serve Docker products, while the Overview page shows your active plans with options to upgrade or cancel.
+
+## Set up a new plan
+
+You can purchase Docker plans through the product catalog:
+
+1. Sign in to [Docker Home](https://app.docker.com/), then choose your personal
+   account or your organization account.
+1. Go to **Billing**.
+1. Select **Browse products**.
+   - The **Products** page contains products and upgrades available for self-serve.
+   - Some products in the catalog may apply to personal accounts, organization accounts, or both.
+   - Each product tile uses an account-type flag so you know the difference.
+1. Select **View plans**, then choose the plan you want to add to your Docker subscription.
+1. Verify your billing details, continue to payment, and complete checkout.
+   - Optional. To add a VAT number, select the **I'm purchasing as a business**
+     checkbox and enter your Tax ID.
+   - Your VAT number must include your country prefix. For example, enter
+     `DE123456789` for a German VAT number.
+
+## Upgrade plans
+
+You can upgrade active plans from the billing Overview page.
+
+1. Sign in to [Docker Home](https://app.docker.com/), then choose your personal
+   account or your organization account.
+1. Go to **Billing** to view the Overview page.
+   - The Overview page contains your active plans and payment details.
+   - **Active plans** contains information about plan type, renewal cadence, and usage.
+1. Top up or upgrade from the **Active plans** section.
+   - **Active plans** is where you complete all management actions.
+   - Depending on the plan type, you can select the action menu button or the **Manage** button to choose from available actions.
+1. Verify your billing details, continue to payment, and complete checkout.
+
+> [!TIP]
+> Billing cycle details vary from plan to plan. Learn more about usage, downgrading, or canceling plans
+> from the relevant
+> [product page](/manuals/subscription/plans/_index.md).
+
+## View your credits
+
+Docker displays available account credits in the billing portal. Credits
+offset eligible usage automatically before Docker charges your payment
+method. To review credit balance and applied credits, see
+[Credits](/manuals/billing/_index.md#credits).
+
+Credits apply to
+[Docker Agentic Platform](/manuals/subscription/plans/docker-agentic-platform.md).
+When you sign up for Docker Agentic Platform, Docker adds a one-time
+promotional credit to your account. This credit is non-recurring,
+doesn't expire, and applies to cloud compute usage only. It doesn't
+apply to inference, which you pay for through your own API keys.
+
+## Sales-led products
+
+Some products are sales-led. You must
+<a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_plans_manage" class="link" rel="noopener">contact sales</a> to opt in.
+
+## Next steps
+
+- [Learn about available plans](/manuals/subscription/plans/_index.md)
+- [Set up payment information](/manuals/billing/payment-method.md)
+- [View invoices](/manuals/billing/history.md)
+- To learn more about managing your billing details, see [Billing](/manuals/billing/_index.md).
+- To learn about sales tax and VAT, see
+  [Taxes](/manuals/billing/tax-certificate.md).
diff --git a/content/manuals/subscription/plans/_index.md b/content/manuals/subscription/plans/_index.md
new file mode 100644
index 000000000000..dacd056981eb
--- /dev/null
+++ b/content/manuals/subscription/plans/_index.md
@@ -0,0 +1,53 @@
+---
+title: Plans
+linkTitle: Plans
+description:
+  Browse available Docker plans and add-ons for individuals, teams, and
+  organizations.
+keywords:
+  docker products, docker subscriptions, docker core, ai governance, dhi select,
+  docker build cloud, gordon plans, docker agentic platform, product catalog
+weight: 10
+aliases:
+  - /subscription/products/
+  - /subscription/scale/
+  - /subscription/details/
+  - /subscription/downgrade/
+  - /docker-hub/cancel-downgrade/
+  - /docker-hub/billing/downgrade/
+grid:
+  - title: Docker
+    description: Personal and organization plans, including build and runtime minutes.
+    link: /subscription/plans/docker/
+    icon: credit-card
+  - title: Gordon plans
+    description: Usage plans that increase your Gordon allowance.
+    link: /subscription/plans/gordon/
+    icon: /icons/gordon.svg
+  - title: Docker Hardened Images (DHI)
+    description: Hardened image repositories for organization accounts.
+    link: /subscription/plans/dhi/
+    icon: /icons/dhi.svg
+  - title: AI Governance
+    description: Licenses for organization-wide AI policy enforcement.
+    link: /subscription/plans/ai-governance/
+    icon: shield-check
+  - title: Docker Verified Publisher (DVP)
+    description: Publisher analytics and reporting plans for organization accounts.
+    link: /subscription/plans/docker-verified-publisher/
+    icon: check-badge
+---
+
+> [!TIP]
+> Interested in pricing details? Check out the
+> <a href="https://www.docker.com/pricing/" id="dkr_docs_index_pricing" class="link" rel="noopener">pricing page</a> to compare plans.
+
+You can subscribe to plans on a self-serve basis when you go to the Docker product catalog from the billing portal. Plans can be tied to personal or organization account types, and include options to extend usage limits.
+
+This section covers usage entitlements, billing cycle, and plan management options for each available plan.
+
+To manage your plans by adding a new plan or upgrading an active plan, see [Manage plans](/manuals/subscription/manage.md).
+
+## Product catalog
+
+{{< grid >}}
diff --git a/content/manuals/subscription/plans/ai-governance.md b/content/manuals/subscription/plans/ai-governance.md
new file mode 100644
index 000000000000..486e9f12a1be
--- /dev/null
+++ b/content/manuals/subscription/plans/ai-governance.md
@@ -0,0 +1,29 @@
+---
+title: AI Governance plan
+linkTitle: AI Governance
+description:
+  Manage AI Governance licenses for your organization, including purchasing,
+  assigning, and deactivating
+keywords:
+  ai governance, licenses, organization licenses, ai policy, docker sandbox,
+  subscription management
+weight: 50
+aliases:
+  - /subscription/products/ai-governance/
+  - /subscription/ai-governance/
+---
+
+[AI Governance](/manuals/ai/sandboxes/governance/_index.md) lets organization owners enforce policies for members across supported Docker AI products, like [Docker Sandbox](/manuals/ai/sandboxes/_index.md). When you add an AI Governance plan, you work with your Docker sales representative to determine the number of licenses needed, which are applied to your account.
+
+> [!TIP]
+> To subscribe to AI Governance, <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_plans_aigov" class="link" rel="noopener">contact sales</a>.
+
+## Usage
+
+AI Governance lets organization owners enforce [organization policies](/manuals/ai/sandboxes/governance/access-controls/organization.md) for license-holding members. Organization policies override a license-holding member's local policies.
+
+You can [assign AI Governance licenses](/manuals/admin/organization/manage/manage-licenses.md) to any organization member, even if they don't occupy a Docker Team or Docker Business seat. For best practice, review available licenses as you add new members since members without an AI Governance license can still use Docker AI products.
+
+## Billing cycle
+
+AI Governance plan pricing is based on the number of licenses purchased. To add or remove licenses, contact your Docker sales representative.
diff --git a/content/manuals/subscription/plans/dhi.md b/content/manuals/subscription/plans/dhi.md
new file mode 100644
index 000000000000..443ea3ea023d
--- /dev/null
+++ b/content/manuals/subscription/plans/dhi.md
@@ -0,0 +1,59 @@
+---
+title: DHI plans
+linkTitle: Docker Hardened Images
+description:
+  Manage Docker Hardened Images Select and Enterprise repositories for
+  organization accounts, including purchasing, adding repositories, and
+  deactivating
+keywords: dhi select, dhi enterprise, docker hardened images, hardened images,
+  repositories, organization subscription, secure images
+weight: 40
+aliases:
+  - /subscription/products/dhi-select/
+  - /subscription/dhi-select/
+  - /subscription/plans/dhi-select/
+---
+
+[Docker Hardened Images (DHI)](/manuals/dhi/_index.md) are secure, minimal, production-ready container images maintained by Docker.
+
+- DHI Community is free and available to every developer.
+- DHI Select is a paid plan for organizations that need compliance-ready images and SLA-backed patching. You can self-serve it in the billing portal.
+- DHI Enterprise is for organizations with advanced security and customization requirements. To subscribe, <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_plans_dhi_enterprise" class="link" rel="noopener">contact sales</a>.
+
+For a full plan comparison, see the [Docker pricing page](https://www.docker.com/pricing/).
+
+## Usage
+
+DHI Community gives you access to hardened base images from a public registry at no cost or additional setup. Any organization can pull hardened base images directly from `dhi.io`.
+
+When you upgrade from DHI Community to DHI Select, you purchase a set number of repositories that are mirrored into your organization's namespace. Entitlements are scoped to the organization account that you assign them to during checkout. All organization members can then pull from those mirrored repositories.
+
+DHI Enterprise extends DHI Select with unlimited customizations, optional full catalog access, the Hardened System Packages repository, and an Extended Lifecycle Support add-on.
+
+For details on setting up and managing repositories, see [Get started with DHI Select and Enterprise](/manuals/dhi/how-to/select-enterprise.md).
+
+## Billing cycle
+
+DHI Select is an annual plan billed per repository from the date your plan starts. Repositories added mid-cycle are prorated for the remainder of the billing period. You can add more repositories to your DHI Select plan by going to **Active plans** in the billing portal. For steps, see [Manage plans](../manage.md#upgrade-plans).
+
+## Disable auto-renewal
+
+If you want to revert your plan to DHI Community, you must disable auto-renewal. Disabling auto-renewal is deferred to the end of the current billing cycle and your repository access remains active until then. To disable auto-renewal:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and go to **Billing**.
+1. From **Active plans**, select **Manage** next to **Hardened Images**.
+1. Select **Disable auto-renewal**.
+
+## Remove repositories
+
+You may also remove repositories from your plan. Repository removals are deferred to the end of the current billing cycle. You can remove repositories at any time, but you cannot stop a plan mid-cycle to receive a partial refund. Repository access remains active until the cycle ends.
+
+To remove repositories:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and go to **Billing**.
+1. From **Active plans**, select **Manage** next to **Hardened Images**.
+    - Select **Remove repositories** to adjust your repository count.
+    - To keep your current repository count after renewal, select **Cancel scheduled change**. 
+    - Cancellations and repository removals take effect at the end of the current annual billing cycle.
+
+If you're subscribed to DHI Enterprise, reach out to your sales representative to change your DHI plan.
diff --git a/content/manuals/subscription/plans/docker-agentic-platform.md b/content/manuals/subscription/plans/docker-agentic-platform.md
new file mode 100644
index 000000000000..e0ad92e9a802
--- /dev/null
+++ b/content/manuals/subscription/plans/docker-agentic-platform.md
@@ -0,0 +1,82 @@
+---
+title: Docker Agentic Platform plans
+linkTitle: Docker Agentic Platform
+description: >
+  Learn about Docker Agentic Platform for individual developers,
+  including usage, pay-as-you-go billing cycle, and cancellation.
+keywords:
+  docker agentic platform, cloud sandboxes, mcp gateway,
+  pay-as-you-go, paygo, metered billing, billing cycle, personal
+  subscription, promotional credit, cancel subscription, sandbox
+  compute, usage and billing
+weight: 20
+sitemap: false
+---
+
+> [!TIP]
+> Docker Agentic Platform signups receive a one-time promotional
+> credit toward cloud compute usage. To review your balance, see
+> [Credits](/manuals/billing/_index.md#credits).
+
+[Docker Agentic Platform](https://agentic-platform.docker.com/) is a
+pay-as-you-go plan for running agent and tool workloads in isolated
+sandboxes with Docker-managed cloud infrastructure. You pay for the usage you accrue without a recurring
+subscription fee.
+
+## Usage
+
+> [!NOTE]
+> Docker Agentic Platform is available only on Docker Personal and
+> Docker Pro accounts.
+
+Docker Agentic Platform requires bringing your own API keys for inference. Your inference provider
+handles those costs.
+
+After you subscribe, your invoice reflects metered, pay-as-you-go
+compute usage. Docker meters compute usage in seconds, based on sandbox
+runtime and the vCPU plus memory configuration you choose at setup.
+Different sandbox configurations can produce different costs.
+
+You can track usage and pricing from the
+[Usage & billing](https://agentic-platform.docker.com/usage) page in Agentic Platform.
+
+To track usage for Docker Agentic Platform from Docker Home:
+
+1. Sign in to [Docker Home](https://app.docker.com/), then choose your
+   account.
+1. Go to **Billing** to view the Overview page, then go to **Active
+   plans**.
+1. Select **Manage** next to **Docker Agentic Platform**.
+1. View the estimated totals and usage for the current pay period.
+
+## Billing cycle
+
+Docker Agentic Platform is billed monthly on the day you subscribe.
+Your invoice reflects compute usage accrued during the previous period.
+For example:
+
+- If you subscribed on September 10, you are billed on October 10.
+- Your invoice from October 10 reflects accrued usage from September 10
+  through October 9.
+- Your invoice can take up to 24 hours after your billing date to
+  appear.
+
+## Cancel a plan
+
+Canceling Docker Agentic Platform disables subscription renewal at the
+start of the next plan period. Docker bills you for usage at the end of
+the plan period.
+
+1. Sign in to [Docker Home](https://app.docker.com/) and go to
+   **Billing**.
+1. From **Active plans**, select **Manage** next to
+   **Docker Agentic Platform**.
+1. Select **Cancel subscription**.
+1. Review your usage, then select **Cancel subscription** to confirm.
+
+## Next steps
+
+- To add or cancel a plan, see
+  [Manage plans](/manuals/subscription/manage.md)
+- To track usage across plans, see
+  [Usage](/manuals/billing/_index.md#usage)
diff --git a/content/manuals/subscription/plans/docker-verified-publisher.md b/content/manuals/subscription/plans/docker-verified-publisher.md
new file mode 100644
index 000000000000..f72ce0140475
--- /dev/null
+++ b/content/manuals/subscription/plans/docker-verified-publisher.md
@@ -0,0 +1,112 @@
+---
+title: Docker Verified Publisher plans
+linkTitle: Docker Verified Publisher
+description:
+  Manage DVP Starter and DVP Growth for organization accounts,
+  including how to apply, add consuming domains, and handle billing.
+keywords:
+  docker verified publisher, dvp, dvp starter, dvp growth, consuming
+  domains, publisher analytics, organization subscription, apply
+  for dvp, auto-renewal, billing portal, docker hub
+weight: 60
+---
+
+[Docker Verified Publisher (DVP)](/manuals/docker-hub/repos/manage/trusted-content/dvp-program.md)
+is a program for commercial publishers who distribute content on Docker
+Hub. DVP Starter and DVP Growth are paid organization plans that add
+publisher analytics and reporting to verified publisher status.
+
+- DVP Starter includes a verified publisher badge, prioritized search
+  ranking, [Docker Scout](/manuals/scout/_index.md) vulnerability
+  scanning, and weekly and monthly summary reports.
+- DVP Growth includes everything in DVP Starter, plus trends,
+  domain-level reports, and benchmark reports, with 25 consuming
+  domains included.
+
+For a plan comparison, see the
+[DVP landing page](https://hub.docker.com/publisher-program).
+
+> [!TIP]
+> DVP plans require an approved application before you can subscribe.
+> See [Apply for DVP Starter or Growth](#apply-for-dvp-starter-or-growth).
+
+## Usage
+
+Organizations can hold a DVP plan and DVP entitlements apply per organization
+namespace. If you operate multiple namespaces, each one needs its own DVP
+application. If you only have a Docker Personal or Docker Pro account, you can
+create an organization when you apply.
+
+Consuming domains are unique company domains that pull your images.
+On DVP Growth, you can add more consuming domains in increments of
+25 from the billing portal. For steps, see
+[Add consuming domains](#add-consuming-domains).
+
+For details on the reports available to verified publishers, see
+[Insights and analytics](/manuals/docker-hub/repos/manage/trusted-content/insights-analytics.md).
+
+## Apply for DVP Starter or Growth
+
+To add DVP Starter or DVP Growth, you must apply for a DVP plan. After Docker
+approves your application, complete checkout to subscribe.
+
+1. Go to the [DVP landing page](https://hub.docker.com/publisher-program).
+   The page contains information about DVP Starter and DVP Growth.
+1. Select **Apply for DVP**. Sign in if prompted.
+1. Select an existing organization namespace, or create a new one if
+   needed.
+1. Fill in the content you want to publish and select DVP Starter or
+   DVP Growth.
+1. Submit your application for review with **Submit application**.
+1. After approval, Docker emails you a checkout link. Open the link,
+   then select DVP Starter or DVP Growth.
+1. Verify your billing details, continue to payment, and complete
+   checkout.
+
+> [!IMPORTANT]
+> Docker emails a checkout link after it approves your application.
+> You're charged when you complete payment.
+
+## Add consuming domains
+
+On a DVP Growth plan, you can add consuming domains from the billing
+portal:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and go to
+   **Billing**.
+1. From **Active plans**, select **Manage** next to **Docker Verified
+   Publisher**.
+1. Select **Add consuming domains** under **Consuming Domains**.
+1. Select the number of consuming domains you want to add to your
+   subscription.
+1. Verify your billing details, continue to payment, and complete
+   checkout.
+
+## Billing cycle
+
+DVP Starter and DVP Growth are billed annually. You can upgrade from
+DVP Starter to DVP Growth without a new application. Upgrades take
+effect immediately.
+
+On DVP Growth, consuming domain add-ons are prorated from the purchase
+date through the rest of your billing period, and they expire at the
+end of your annual subscription. You can reduce your add-on count at
+any time. Removals take effect at the end of the current billing cycle.
+
+> [!IMPORTANT]
+> No mid-cycle refunds are issued when you reduce consuming domain
+> add-ons or end a DVP plan.
+
+## Disable auto-renewal
+
+To end a DVP plan, disable automatic renewal. Your plan stays active
+until the end of the billing period and then expires. To disable
+auto-renewal:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and go to
+   **Billing**.
+1. From **Active plans**, select **Manage** next to **Docker Verified
+   Publisher**.
+1. Select **Disable auto-renewal**.
+1. Optional. To remove consuming domains, select **Remove consuming
+   domains**, then choose the number to remove.
diff --git a/content/manuals/subscription/plans/docker.md b/content/manuals/subscription/plans/docker.md
new file mode 100644
index 000000000000..bb72f83445c6
--- /dev/null
+++ b/content/manuals/subscription/plans/docker.md
@@ -0,0 +1,121 @@
+---
+title: Docker plans
+linkTitle: Docker
+description:
+  Learn about Docker plans that upgrade personal and organization accounts,
+  including usage entitlements, billing cycle, and downgrade options.
+keywords:
+  docker core, docker team, docker business, docker pro, docker personal,
+  subscription seats, upgrade subscription, downgrade subscription, docker
+  pricing, subscription changes, build cloud minutes, testcontainers minutes
+weight: 10
+aliases:
+  - /subscription/plans/core/
+  - /subscription/products/core/
+  - /subscription/core/
+  - /subscription/testcontainers-cloud/
+  - /subscription/products/testcontainers-cloud/
+  - /subscription/products/build-cloud/
+  - /subscription/build-cloud/
+  - /subscription/core-subscription/downgrade/
+---
+
+Docker plans refer to plans that upgrade your account type from the basic free plan to a paid plan. Paid Docker plans come with higher usage limits, commercial
+licensing, and expanded feature sets.
+
+- Docker Personal is free for individual developers. Docker Pro adds unlimited private repositories, Docker Build Cloud, and commercial Docker Desktop use.
+- Docker Team and Docker Business are plans for organizations, with Team adding audit logs and role-based access control, and Business adding SSO, SCIM, hardened Docker Desktop, and image access management.
+
+To upgrade your free Docker plan in the billing portal, see [Manage plans](../manage.md).
+
+## Usage
+
+Docker Personal and Docker Pro are Docker plans for individual account types while Docker Team and Docker Business are Docker plans for organization account types. For a full feature and pricing breakdown, see the
+<a href="https://www.docker.com/pricing/" id="dkr_docs_index_pricing_docker_plans" class="link" rel="noopener">Docker pricing page</a>. 
+
+> [!TIP]
+> If you're upgrading from a Personal plan to a Team plan
+> and want to keep your username,
+> [convert your user account into an organization](/manuals/admin/organization/setup/convert-account.md).
+
+## Billing cycle
+
+Docker individual and organization plans are billed at a flat rate per user per month, with monthly or
+annual billing options.
+Upgrading your plan immediately extends access to all features
+and entitlements.
+
+### Organization seats
+
+For Docker Team and Docker Business, you can purchase more seats for new members to extend access to your paid Docker plan. To add or remove seats from your Docker plan:
+
+1. Sign in to [Docker Home](https://app.docker.com/), then choose your organization account.
+1. Go to **Billing** to view the Overview page, then go to **Active plans**.
+1. From the Docker Team or Docker Business tile, select the action menu.
+   - Select **Add seats** or **Remove seats** from the drop-down menu.
+   - When you add or remove seats, review your current seats against your new total seats.
+   - When you remove seats, you must remove members from your organization.
+1. Verify your billing details, continue to payment, and complete checkout.
+
+To learn how to manage seats from Docker Home, see
+[Manage seats](/manuals/admin/organization/manage/manage-seats.md).
+
+### Docker Offload licenses
+
+[Docker Offload](/manuals/offload/_index.md) licenses are available for Docker Team and Docker Business plans. Once assigned to your account, organization owners can [manage license assignments](/manuals/admin/organization/manage/manage-licenses.md) in Docker Home.
+
+To add Docker Offload licenses, you must <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_plans_docker_offload" class="link" rel="noopener">contact sales</a>.
+
+### Docker Build Cloud minutes
+
+Each plan includes a base allocation of [Docker Build Cloud](/manuals/build-cloud/_index.md) build minutes per
+month. Base minutes reset on an annual or monthly cadence, and don't accumulate. Additional purchased
+minutes expire at the end of your billing period.
+
+To purchase additional minutes:
+
+1. From [Docker Home](https://app.docker.com/), choose your organization.
+1. Select Build Cloud, then Build minutes.
+1. From the **Minute breakdown** table, select **Add minutes**.
+1. Choose your additional minute amount.
+1. Verify your billing details, continue to payment, and complete checkout.
+
+Your additional minutes appear on the Build minutes page immediately.
+
+### Testcontainers Cloud minutes
+
+Each plan includes a base allocation of Testcontainers Cloud runtime minutes
+per month. Base minutes reset monthly and don't accumulate.
+
+You can add Testcontainers Cloud runtime minutes in two ways:
+
+- <a href="https://www.docker.com/pricing/contact-sales/" id="dkr_docs_cs_plans_docker_testcontainers" class="link" rel="noopener">Contact sales</a> to
+  pre-purchase runtime minutes at $3 per 100 minutes. Pre-purchased minutes
+  expire at the end of your billing period.
+- Use on-demand runtime minutes at $4 per 100 minutes, billed at the end of
+  each monthly cycle.
+
+## Cancel a Docker plan
+
+> [!NOTE]
+> If you have a sales-assisted Docker Business plan,
+> you must contact your account manager to cancel.
+
+You can cancel at any time before your renewal date, but you can't pause or delay a plan. If an invoice isn't paid by the due date, there's a 15-day grace period starting from the due date. While the unused portion is not refundable, you still retain access to paid features until the end of the current billing cycle. 
+
+> [!NOTE]
+>
+> Billing periods are calculated in UTC (Coordinated Universal Time). If you're in a timezone behind UTC, for example US Pacific Time is UTC−7/−8, canceling or making changes late in your local day may fall into the next billing day in UTC.
+
+Canceling your paid plans may have implications for collaborators or organization members:
+
+- Docker Pro private repository collaborators are removed and additional private repositories are locked.
+- Docker Team or Docker Business members provisioned through SCIM without a password will be locked out. Remove SSO connections and verified domains if your organization uses single sign-on.
+- For paid individual and organization plans, you must convert private repositories to fit your new plan limits.
+
+Canceling a paid plan returns your account to Docker Personal or a basic organization account.
+To cancel your plan:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and go to **Billing**.
+2. From **Active plans**, select the action menu next to your Docker plan.
+3. Select **Cancel plan** and complete the feedback survey.
diff --git a/content/manuals/subscription/plans/gordon.md b/content/manuals/subscription/plans/gordon.md
new file mode 100644
index 000000000000..321ae886bf34
--- /dev/null
+++ b/content/manuals/subscription/plans/gordon.md
@@ -0,0 +1,53 @@
+---
+title: Gordon plans
+linkTitle: Gordon
+description:
+  Manage Gordon Plus, Max, and Ultra plans for personal accounts, including
+  purchasing, upgrading, and deactivating
+keywords:
+  gordon, gordon plus, gordon max, gordon ultra, gordon usage, gordon plan,
+  personal subscription, ai assistant, usage allowance
+weight: 30
+aliases:
+  - /subscription/products/gordon/
+  - /subscription/gordon/
+---
+
+[Gordon](/manuals/ai/gordon/_index.md) is an AI assistant for Docker workflows. For pricing details, see the [Gordon product page](https://www.docker.com/products/gordon/).
+
+- Gordon Base is included at no cost with Docker plans. It covers everyday Docker workflow questions with a baseline monthly usage allowance.
+- Gordon Plus is for developers who use Gordon regularly. It increases your monthly usage allowance above Base.
+- Gordon Max is for power users who rely on Gordon throughout their workflow. It offers a significantly higher usage allowance than Plus.
+- Gordon Ultra is for developers with the highest usage needs. It provides the maximum monthly allowance available on a self-serve plan.
+
+To upgrade to a Gordon paid plan, see [Manage plans](/manuals/subscription/manage.md).
+
+## Usage
+
+Gordon usage is measured in questions. When you upgrade from Gordon Base to a paid plan, your usage multiplies the Base allowance. Usage is capped across three time windows: 4-hour, daily, and monthly. For full limit details, see [Gordon usage limits](/manuals/ai/gordon/usage-limits.md).
+
+> [!IMPORTANT]
+> Gordon plans apply to personal Docker accounts only. If you purchase a Gordon
+> plan while signed in with an organization account, the plan applies
+> to your personal account automatically.
+
+## Billing cycle
+
+Gordon plans are billed monthly at the first of the month. If you purchase after the first of the month, your invoice reflects prorated charges for the remaining days in the cycle. Subscribing to a Gordon plan charges you at the time of purchase. When you upgrade your Gordon plan, usage limits are immediately effective after payment. 
+
+## Downgrade or disable auto-renewal
+
+When you downgrade a Gordon plan, the change takes effect on the 1st of the following month. Disabling auto-renewal for a Gordon plan returns your paid Gordon plan to Gordon Base in the same pattern. For example, if you downgrade from Gordon Ultra to Gordon Plus on April 15:
+
+- From April 15 through April 30, you retain Ultra access and usage limits.
+- On May 1, you are charged the Gordon Plus plan rate and Gordon Plus usage limits take effect.
+
+To downgrade or disable auto-renewal:
+
+1. Sign in to [Docker Home](https://app.docker.com/) and go to **Billing**.
+1. From **Active plans**, select **Manage** next to your Gordon plan.
+1. Select **Downgrade plan** to switch to a lower tier, or **Disable auto renewal** to end your plan after the current billing cycle.
+
+> [!IMPORTANT]
+> Docker does not issue refunds or credits
+> for remaining days in the current cycle.
diff --git a/content/manuals/subscription/scale.md b/content/manuals/subscription/scale.md
deleted file mode 100644
index ca5c411b98fb..000000000000
--- a/content/manuals/subscription/scale.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-description: Learn how to scale your Docker subscription
-keywords: subscription, Pro, Team, business, pricing plan, build minutes, test container minutes, pull limit
-title: Scale your subscription
-weight: 17
----
-
-> [!NOTE]
->
-> Owners of legacy Docker subscription plans must upgrade their subscription to a new
-> Docker subscription plan in order to scale their subscription.
->
-> Legacy Docker plans apply to Docker subscribers who last purchased or renewed
-> their subscription before December 10, 2024. These subscribers will keep
-> their current plan and pricing until their next renewal date that falls on or
-> after December 10, 2024. To see purchase or renewal history, view your
-> [billing history](../billing/history.md). For more details about legacy
-> after December 10, 2024. For more details about legacy
-> subscriptions, see [Announcing Upgraded Docker
-> Plans](https://www.docker.com/blog/november-2024-updated-plans-announcement/).
-
-Docker subscriptions let you scale your consumption as your needs evolve. Except
-for legacy Docker subscription plans, all paid Docker subscriptions come with
-access to Docker Hub, Docker Build Cloud, and Testcontainers Cloud with a base
-amount of consumption. See [Docker subscriptions and features](./details.md) to
-learn how much base consumption comes with each subscription. You can scale your
-consumption at any time during your subscription period.
-
-You can scale consumption for the following:
-
-- Docker Build Cloud build minutes
-- Docker Testcontainers Cloud runtime minutes
-
-To better understand your needs, you can view your consumption at any time. For
-more details, see [View Docker product
-usage](../admin/organization/manage-products.md#view-docker-product-usage).
-
-> [!WARNING]
->
-> The number of Docker Build Cloud and Testcontainers minutes included in your
-subscription do not rollover. Additional minutes expire at the end of your
-subscription period (monthly or annually). For example, if you have an annual
-Docker Team subscription with 500 included minutes, and purchase 500 additional
-minutes, only the 500 additional minutes rollover until the end of your annual
-subscription period.
-
-## Add Docker Build Cloud build minutes
-
-You can pre-purchase Docker Build Cloud build minutes in the Docker Build Cloud Dashboard:
-
-1. Sign in to [Docker Home](https://app.docker.com/).
-2. Under Settings and administration, select **Billing**.
-3. On the plans and usage page, select **View build minutes**.
-    This will launch the Docker Build Cloud settings page.
-4. Select **Add minutes**.
-5. Select your additional minute amount, then **Continue to payment**.
-6. Enter your payment details and billing address.
-7. Review your order and select **Pay**.
-
-Your additional minutes will now display on the Build minutes page.
-
-## Add Docker Testcontainers Cloud runtime minutes
-
-You can pre-purchase Testcontainers Cloud runtime minutes by [contacting
- sales](https://www.docker.com/pricing/contact-sales/). In addition to
-pre-purchase, you are able to use as many minutes as you need on-demand. The
-usage will be billed at the end of each monthly billing cycle. On-demand usage
-is billed at a higher rate than pre-purchased capacity. To avoid on-demand
-charges, pre-purchase additional minutes.
\ No newline at end of file
diff --git a/content/manuals/subscription/setup.md b/content/manuals/subscription/setup.md
deleted file mode 100644
index 40ab1b2c1347..000000000000
--- a/content/manuals/subscription/setup.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-description: Learn how to set up your Docker subscription
-keywords: subscription, Pro, Team, Business, pricing plan
-title: Set up your subscription
-weight: 15
----
-
-Docker subscriptions offer features and benefits to support both new and professional developers, as well as plans for individuals, teams, and enterprise businesses. To learn more about what's included with each tier, see [Docker subscriptions and features](./details.md) and [Docker Pricing](https://www.docker.com/pricing/).
-
-In this section, learn how to get started with a Docker subscription for individuals or for organizations. Before you begin, make sure you have a [Docker ID](../accounts/create-account.md).
-
-{{% include "tax-compliance.md" %}}
-
-## Set up a Docker subscription for a personal account
-
-After you [create your Docker ID](../accounts/create-account.md), you have a Docker Personal subscription. To continue using this plan, no further action is necessary. For additional features, you can upgrade to a Docker Pro plan.
-
-To upgrade from Docker Personal to Docker Pro, see [Upgrade your subscription](./change.md#upgrade-your-subscription).
-
-## Set up a Docker subscription for an organization
-
-You can subscribe a new or existing organization to a Docker plan. Only organization owners can manage billing for the organization.
-
-After you [create your Docker ID](../accounts/create-account.md), you have a Docker Personal plan. You must then create an organization and choose a subscription for it. For more details, see [Create your organization](../admin/organization/orgs.md).
-
-To learn how to upgrade a Docker subscription for an existing organization, see [Upgrade your subscription](./change.md#upgrade-your-subscription).
\ No newline at end of file
diff --git a/content/manuals/support/_index.md b/content/manuals/support/_index.md
new file mode 100644
index 000000000000..6364b9ba9eb2
--- /dev/null
+++ b/content/manuals/support/_index.md
@@ -0,0 +1,139 @@
+---
+title: Get support for Docker products
+linkTitle: Support
+description: Learn about support options for Docker products including paid subscriptions and community resources
+keywords: support, help, docker desktop, subscriptions, community, troubleshooting
+weight: 50
+params:
+  sidebar:
+    group: Platform
+---
+
+Docker offers multiple support channels depending on your subscription level and needs.
+
+## Paid subscription support
+
+All Docker Pro, Team, and Business subscribers receive email support for Docker products.
+
+### Support response times
+
+- Docker Pro: 3 business day response
+- Docker Team: 2 business day response, 24×5 availability
+- Docker Business: 1 business day response, 24×5 availability
+
+Docker Verified Publisher (DVP) organizations follow the response times for their
+Docker Pro, Team, or Business subscription. Without one of those subscriptions,
+the following response times apply:
+
+- DVP Starter: 3 business day response
+- DVP Growth: 2 business day response, 24×5 availability
+
+> [!TIP]
+>
+> Premium Support with faster response times and 24×7 availability is available as an add-on for [Docker Business subscribers](https://www.docker.com/pricing?ref=Docs&refAction=DocsSupport).
+
+### Support severity levels
+
+| Level    | Description                                                                                                                                                                |
+| :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Critical | Widespread or company-wide service outage affecting many customers or all users within a single organization. Business operations are halted with no workaround available. |
+| High     | Team or department-level impact preventing significant users from accessing core functionality. Severe business impact with no workaround exists.                          |
+| Medium   | Individual user or small group impact causing partial loss of functionality. Business operations continue, often with workarounds available but reduced productivity.      |
+
+### Request support
+
+> [!TIP]
+>
+> Before reaching out for support, review the troubleshooting documentation for your product.
+
+If you have a paid Docker subscription, [contact the Support team](https://hub.docker.com/support/contact/).
+
+## Community support
+
+All Docker users can seek support through community resources, where Docker or the community respond on a best effort basis:
+
+- [Docker Community Forums](https://forums.docker.com/)
+- [Docker Community Slack](http://dockr.ly/comm-slack)
+
+## Docker Desktop support
+
+Docker Desktop support is available with a paid subscription.
+
+### Scope of support
+
+{{< tabs >}}
+{{< tab name="Covered">}}
+
+Docker Desktop support includes:
+
+- Account management and billing
+- Configuration and installation issues
+- Desktop updates
+- Sign-in issues
+- Push or pull issues, including rate limiting
+- Application crashes or unexpected behavior
+- Automated builds
+- Basic product 'how to' questions
+
+**Windows-specific:**
+
+- Turning on virtualization in BIOS
+- Turning on Windows features
+- Running inside [certain VM or VDI environments](/manuals/desktop/setup/vm-vdi.md) (Docker Business only)
+
+{{< /tab >}}
+{{< tab name="Not covered">}}
+
+Docker Desktop support excludes:
+
+- Unsupported operating systems, including beta/preview versions
+- Running containers of a different architecture using emulation
+- Docker Engine, Docker CLI, or other bundled Linux components
+- Kubernetes
+- Features labeled as experimental
+- System/Server administration activities
+- Desktop as a production runtime
+- Scale deployment/multi-machine installation
+- Routine product maintenance (data backup, disk space, log rotation)
+- Third-party applications not provided by Docker
+- Altered or modified Docker software
+- Hardware malfunction, abuse, or improper use
+- Versions older than the latest release (except Docker Business)
+- Training, customization, and integration
+- Running multiple instances on a single machine
+
+> [!NOTE]
+>
+> Support for [running Docker Desktop in a VM or VDI environment](/manuals/desktop/setup/vm-vdi.md) is only available to Docker Business customers.
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### Supported versions
+
+- Docker Business: Versions up to six months older than the latest version (fixes applied to latest version only)
+- Docker Pro and Team: Latest version only
+
+### Number of machines
+
+- Docker Pro: One machine
+- Docker Team: Number of machines equal to subscription seats
+- Docker Business: Unlimited machines
+
+### Supported operating systems
+
+- [Mac system requirements](/manuals/desktop/setup/install/mac-install.md#system-requirements)
+- [Windows system requirements](/manuals/desktop/setup/install/windows-install.md#system-requirements)
+- [Linux system requirements](/manuals/desktop/setup/install/linux/_index.md#system-requirements)
+
+### Community resources
+
+- [Docker Desktop issue tracker](https://github.com/docker/desktop-feedback)
+
+### Diagnostic data and privacy
+
+When uploading diagnostics, the bundle may contain personal data such as usernames and IP addresses. Diagnostics bundles are only accessible to Docker, Inc. employees directly involved in diagnosing issues.
+
+By default, Docker, Inc. deletes uploaded diagnostics bundles after 30 days. You may request removal of a diagnostics bundle by specifying the diagnostics ID or your GitHub ID. Docker, Inc. only uses the data to investigate specific user issues but may derive high-level (non-personal) metrics.
+
+For more information, see [Docker Data Processing Agreement](https://www.docker.com/legal/data-processing-agreement).
diff --git a/content/manuals/testcontainers.md b/content/manuals/testcontainers.md
index 73b538a27506..3107688a0499 100644
--- a/content/manuals/testcontainers.md
+++ b/content/manuals/testcontainers.md
@@ -1,29 +1,31 @@
 ---
 title: Testcontainers
+weight: 40
 description: Learn how to use Testcontainers to run containers programmatically in your preferred programming language.
-keywords: docker APIs, docker, testcontainers documentation, testcontainers, testcontainers oss, testcontainers oss documentation,
+keywords:
+  docker APIs, docker, testcontainers documentation, testcontainers, testcontainers oss, testcontainers oss documentation,
   docker compose, docker-compose, java, golang, go
 params:
   sidebar:
     group: Open source
 intro:
-- title: What is Testcontainers?
-  description: Learn about what Testcontainers does and its key benefits
-  icon: feature_search
-  link: https://testcontainers.com/getting-started/#what-is-testcontainers
-- title: The Testcontainers workflow
-  description: Understand the Testcontainers workflow 
-  icon: explore
-  link: https://testcontainers.com/getting-started/#testcontainers-workflow
+  - title: What is Testcontainers?
+    description: Learn about what Testcontainers does and its key benefits
+    icon: magnifying-glass
+    link: https://testcontainers.com/getting-started/#what-is-testcontainers
+  - title: The Testcontainers workflow
+    description: Understand the Testcontainers workflow
+    icon: magnifying-glass-plus
+    link: https://testcontainers.com/getting-started/#testcontainers-workflow
 quickstart:
-- title: Testcontainers for Go
-  description: A Go package that makes it simple to create and clean up container-based dependencies for automated integration/smoke tests.
-  icon: /assets/icons/go.svg
-  link: https://golang.testcontainers.org/quickstart/
-- title: Testcontainers for Java
-  description: A Java library that supports JUnit tests, providing lightweight, throwaway instances of anything that can run in a Docker container.
-  icon: /assets/icons/java.svg
-  link: https://java.testcontainers.org/
+  - title: Testcontainers for Go
+    description: A Go package that makes it simple to create and clean up container-based dependencies for automated integration/smoke tests.
+    icon: /icons/go.svg
+    link: https://golang.testcontainers.org/quickstart/
+  - title: Testcontainers for Java
+    description: A Java library that supports JUnit tests, providing lightweight, throwaway instances of anything that can run in a Docker container.
+    icon: /icons/java.svg
+    link: https://java.testcontainers.org/
 ---
 
 Testcontainers is a set of open source libraries that provides easy and lightweight APIs for bootstrapping local development and test dependencies with real services wrapped in Docker containers.
@@ -44,8 +46,8 @@ The rest are community-driven and maintained by independent contributors.
 
 ### Prerequisites
 
-Testcontainers requires a Docker-API compatible container runtime. 
-During development, Testcontainers is actively tested against recent versions of Docker on Linux, as well as against Docker Desktop on Mac and Windows. 
+Testcontainers requires a Docker-API compatible container runtime.
+During development, Testcontainers is actively tested against recent versions of Docker on Linux, as well as against Docker Desktop on Mac and Windows.
 These Docker environments are automatically detected and used by Testcontainers without any additional configuration being necessary.
 
 It is possible to configure Testcontainers to work for other Docker setups, such as a remote Docker host or Docker alternatives.
@@ -53,6 +55,31 @@ However, these are not actively tested in the main development workflow, so not
 and additional manual configuration might be necessary.
 
 If you have further questions about configuration details for your setup or whether it supports running Testcontainers-based tests,
- contact the Testcontainers team and other users from the Testcontainers community on [Slack](https://slack.testcontainers.org/).
+contact the Testcontainers team and other users from the Testcontainers community on [Slack](https://slack.testcontainers.org/).
 
- {{< grid items=quickstart >}}
+{{< grid items=quickstart >}}
+
+## Guides
+
+Explore hands-on Testcontainers guides to learn how to use Testcontainers
+with different languages and popular frameworks:
+
+- [Getting started with Testcontainers for .NET](/guides/testcontainers-dotnet-getting-started/)
+- [Getting started with Testcontainers for Go](/guides/testcontainers-go-getting-started/)
+- [Getting started with Testcontainers for Java](/guides/testcontainers-java-getting-started/)
+- [Getting started with Testcontainers for Node.js](/guides/testcontainers-nodejs-getting-started/)
+- [Getting started with Testcontainers for Python](/guides/testcontainers-python-getting-started/)
+- [Testing a Spring Boot REST API with Testcontainers](/guides/testcontainers-java-spring-boot-rest-api/)
+- [Testcontainers container lifecycle management](/guides/testcontainers-java-lifecycle/)
+- [Replace H2 with a real database for testing](/guides/testcontainers-java-replace-h2/)
+- [Configuration of services running in a container](/guides/testcontainers-java-service-configuration/)
+- [Testing an ASP.NET Core web app](/guides/testcontainers-dotnet-aspnet-core/)
+- [Testing Spring Boot Kafka Listener](/guides/testcontainers-java-spring-boot-kafka/)
+- [Testing REST API integrations using MockServer](/guides/testcontainers-java-mockserver/)
+- [Testing AWS service integrations using LocalStack](/guides/testcontainers-java-aws-localstack/)
+- [Testing Quarkus applications with Testcontainers](/guides/testcontainers-java-quarkus/)
+- [Working with jOOQ and Flyway using Testcontainers](/guides/testcontainers-java-jooq-flyway/)
+- [Testing REST API integrations using WireMock](/guides/testcontainers-java-wiremock/)
+- [Securing Spring Boot with Keycloak and Testcontainers](/guides/testcontainers-java-keycloak-spring-boot/)
+- [Testing Micronaut REST API with WireMock](/guides/testcontainers-java-micronaut-wiremock/)
+- [Testing Micronaut Kafka Listener](/guides/testcontainers-java-micronaut-kafka/)
diff --git a/content/manuals/unassociated-machines/_index.md b/content/manuals/unassociated-machines/_index.md
new file mode 100644
index 000000000000..48e7e9986adb
--- /dev/null
+++ b/content/manuals/unassociated-machines/_index.md
@@ -0,0 +1,215 @@
+---
+title: Manage unassociated machines
+description: Learn how to manage unassociated machines in Docker Home
+keywords: unassociated machines, insights, manage users, enforce sign-in
+sitemap: false
+pagefind_exclude: true
+noindex: true
+params:
+  sidebar:
+    group: Enterprise
+---
+
+{{< restricted title="About unassociated machines" >}}
+Unassociated machines is a private feature that may not be available to all
+accounts.
+{{< /restricted >}}
+
+Docker administrators can identify, view, and manage Docker Desktop machines
+that are likely associated with their organization but aren't currently linked
+to user accounts. This self-service capability helps you understand Docker
+Desktop usage across your organization and streamline user onboarding without
+IT involvement.
+
+## Prerequisites
+
+- Docker Business or Team subscription
+- Organization owner access to your Docker organization
+
+## About unassociated machines
+
+Unassociated machines are Docker Desktop instances that Docker has identified
+as likely belonging to your organization based on usage patterns, but the users
+are not signed in to Docker Desktop with an account that is part of your
+organization.
+
+## How Docker identifies unassociated machines
+
+Docker uses telemetry data to identify which machines likely belong to your
+organization:
+
+- Domain matching: Users signed in with email domains associated with your
+  organization
+- Registry patterns: Analysis of container registry access patterns that
+  indicate organizational usage
+
+## View unassociated machines
+
+To see detailed information about unassociated machines:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization.
+1. Select **Docker Desktop**, then **Unassociated**.
+
+The machine list displays:
+
+- Machine ID (Docker-generated identifier)
+- The registry address used to predict whether a user is part of your
+  organization
+- User email (only displays if the user is signed into Docker Desktop while
+  using it)
+- Docker Desktop version
+- Operating system (OS)
+- Last activity date
+- Sign-in enforced status
+
+You can:
+
+- Export the list as CSV
+- Take actions on individual or multiple machines
+
+## Enable sign-in enforcement for unassociated machines
+
+> [!NOTE]
+>
+> Sign-in enforcement for unassociated machines is different from
+> the [organization-level sign-in enforcement](/enterprise/security/enforce-sign-in/)
+> available through `registry.json` and configuration profiles. This sign-in
+> enforcement only requires users to sign in so admins can identify who is
+> using the machine, meaning users can sign in with any email address. For more
+> stringent security controls that limit sign-ins to users who are already part
+> of your organization, see [Enforce sign-in](/enterprise/security/enforce-sign-in/).
+
+Sign-in enforcement helps you identify who is using unassociated machines in
+your organization. When you enable enforcement, users on these machines will
+be required to sign in to Docker Desktop. Once they sign in, their email
+addresses will appear in the Unassociated list, allowing you to then add them
+to your organization.
+
+You can enable sign-in enforcement using two methods:
+
+- For all unassociated machines in your organization
+- For individual unassociated machines
+
+> [!IMPORTANT]
+>
+> Sign-in enforcement only takes effect after Docker Desktop is restarted.
+> Users can continue using Docker Desktop until their next restart.
+
+### Enable sign-in enforcement for all unassociated machines
+
+To enable sign-in enforcement for all unassociated machines:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization.
+1. Select **Docker Desktop**, then **Unassociated**.
+1. Turn on the **Enforce sign-in** toggle.
+1. In the pop-up modal, select **Require sign-in** to confirm.
+
+The **Sign-in required** status will update for all unassociated machines to
+**Yes**.
+
+> [!NOTE]
+>
+> When you enable sign-in enforcement for all unassociated machines, any new
+> machines detected in the future will automatically have sign-in enforcement
+> enabled. Sign-in enforcement requires Docker Desktop version 4.41 or later.
+> Users with older versions will not be prompted to sign in and can continue
+> using Docker Desktop normally until they update. Their status shows
+> as **Pending** until they update to version 4.41 or later.
+
+### Enable sign-in enforcement for individual unassociated machines
+
+To enable sign-in enforcement for individual unassociated machines:
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization.
+1. Select **Docker Desktop**, then **Unassociated**.
+1. Locate the machine you want to enable sign-in enforcement for.
+1. Select the **Actions** menu and choose **Turn on sign-in enforcement**.
+1. In the pop-up modal, select **Require sign-in** to confirm.
+
+The **Sign-in required** status will update for the individual machine to
+**Yes**.
+
+> [!NOTE]
+>
+> Sign-in enforcement requires Docker Desktop version 4.41 or later. Users
+> with older versions will not be prompted to sign in and can continue using
+> Docker Desktop normally until they update. Their status shows as **Pending**
+> until they update to version 4.41 or later.
+
+### What happens when users sign in
+
+After you enable sign-in enforcement:
+
+1. Users must restart Docker Desktop. Enforcement only takes effect after
+   restart.
+1. When users open Docker Desktop, they see a sign-in prompt. They must sign
+   in to continue using Docker Desktop.
+1. User email addresses appear in the **Unassociated** list.
+1. You can add users to your organization.
+
+Users can continue using Docker Desktop immediately after signing in, even
+before being added to your organization.
+
+## Add unassociated machines to your organization
+
+When users in your organization use Docker without signing in, their machines
+appear in the **Unassociated** list. You can add these users to your
+organization in two ways:
+
+- Automatic addition:
+  - Auto-provisioning: If you have verified domains with auto-provisioning
+    enabled, users who sign in with a matching email domain will automatically
+    be added to your organization. For more information on verifying domains and
+    auto-provisioning, see [Domain management](/enterprise/security/domain-management).
+  - SSO user provisioning: If you have SSO configured with
+    [Just-in-Time provisioning](/manuals/enterprise/security/provisioning/just-in-time.md),
+    users who sign in through your SSO connection will automatically be added
+    to your organization.
+- Manual addition: If you don't have auto-provisioning or SSO set up, or if a
+  user's email domain doesn't match your configured domains, their email will
+  appear in the **Unassociated** list where you can choose to add them directly.
+
+> [!NOTE]
+>
+> If you add users and do not have enough seats in your organization, a
+> pop-up will appear prompting you to **Get more seats**.
+
+### Add individual users
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization.
+1. Select **Docker Desktop**, then **Unassociated**.
+1. Locate the machine you want to add to your organization.
+1. Select the **Actions** menu and choose **Add to organization**.
+1. In the pop-up modal, select **Add user**.
+
+### Bulk add users
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization.
+1. Select **Docker Desktop**, then **Unassociated**.
+1. Use the **checkboxes** to select the machines you want to add to your
+   organizations.
+1. Select the **Add to organization** button.
+1. In the pop-up modal, select **Add users** to confirm.
+
+## Disable sign-in enforcement
+
+### Disable for all unassociated machines
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization.
+1. Select **Docker Desktop**, then **Unassociated**.
+1. Turn off the **Enforce sign-in** toggle.
+1. In the pop-up modal, select **Turn off sign-in requirement** to confirm.
+
+The **Sign-in required** status will update for all unassociated machines to
+**No**.
+
+### Disable for specific unassociated machines
+
+1. Sign in to [Docker Home](https://app.docker.com) and select your organization.
+1. Select **Docker Desktop**, then **Unassociated**.
+1. Locate the machine you want to disable sign-in enforcement for.
+1. Select the **Actions** menu and choose **Turn off sign-in enforcement**.
+1. In the pop-up modal, select **Turn off sign-in requirement** to confirm.
+
+The **Sign-in required** status will update for the individual machine to
+**No**.
diff --git a/content/reference/_index.md b/content/reference/_index.md
index b0b093cd702d..67c45581e6cf 100644
--- a/content/reference/_index.md
+++ b/content/reference/_index.md
@@ -4,44 +4,48 @@ linkTitle: Reference
 layout: wide
 description: Find reference documentation for the Docker platform’s various APIs, CLIs, and file formats
 params:
-  icon: terminal
+  icon: command-line
   notoc: true
   grid_files:
   - title: Dockerfile
     description: Defines the contents and startup behavior of a single container.
-    icon: edit_document
+    icon: pencil-square
     link: /reference/dockerfile/
   - title: Compose file
     description: Defines a multi-container application.
-    icon: polyline
+    icon: rectangle-stack
     link: /reference/compose-file/
   grid_clis:
   - title: Docker CLI
     description: The main Docker CLI, includes all `docker` commands.
-    icon: terminal
+    icon: command-line
     link: /reference/cli/docker/
   - title: Compose CLI
     description: The CLI for Docker Compose, for building and running multi-container
       applications.
-    icon: subtitles
+    icon: server-stack
     link: /reference/cli/docker/compose/
   - title: Daemon CLI (dockerd)
     description: Persistent process that manages containers.
-    icon: developer_board
+    icon: cpu-chip
     link: /reference/cli/dockerd/
   grid_apis:
   - title: Engine API
     description: The main API for Docker, provides programmatic access to a daemon.
-    icon: api
+    icon: code-bracket
     link: /reference/api/engine/
   - title: Docker Hub API
     description: API to interact with Docker Hub.
-    icon: communities
+    icon: cloud
     link: /reference/api/hub/latest/
   - title: DVP Data API
     description: API for Docker Verified Publishers to fetch analytics data.
-    icon: area_chart
-    link: /reference/api/hub/dvp/
+    icon: chart-bar
+    link: /reference/api/dvp/latest/
+  - title: Registry API
+    description: API for Docker Registry.
+    icon: circle-stack
+    link: /reference/api/registry/latest/
 ---
 
 This section includes the reference documentation for the Docker platform's
diff --git a/content/reference/api/ai-governance/api.yaml b/content/reference/api/ai-governance/api.yaml
new file mode 100644
index 000000000000..e552b2d7b6c9
--- /dev/null
+++ b/content/reference/api/ai-governance/api.yaml
@@ -0,0 +1,972 @@
+openapi: "3.1.0"
+
+info:
+  title: Docker AI Governance Policy API
+  version: "1"
+  description: |
+    HTTP+JSON API for managing Docker governance policies and rules.
+
+    **Resource model.** An organization owns one or more policies. Each policy
+    contains a list of rules grouped into a single domain: either `network` or
+    `filesystem`. A policy's domain is derived from its rule actions; mixing
+    domains within a single policy is not permitted.
+
+    **Lifecycle.** Create a policy with CreatePolicy, then add rules with
+    CreateRule. Rules can be updated in place with UpdateRule or removed with
+    DeleteRule. Deleting all rules does not delete the policy itself.
+
+    **Rule evaluation.** All rules in a policy are tested against every request.
+    `deny` always wins: if any rule matches with `decision: deny`, the request
+    is denied regardless of any `allow` rules.
+
+    **Enforcement.** Organization policies take precedence over local sandbox
+    policies and cannot be overridden by individual users.
+
+    **Propagation.** Policy changes take up to five minutes to reach developer
+    machines after being written.
+
+    See https://docs.docker.com/ai/sandboxes/governance/ for product
+    documentation.
+  contact:
+    name: Docker
+    url: https://www.docker.com/products/ai-governance/
+
+tags:
+  - name: policies
+    description: Policy lifecycle management
+  - name: rules
+    description: Rule management within an allowlist policy
+
+servers:
+  - url: https://hub.docker.com/v2
+
+security:
+  - bearerAuth: []
+
+paths:
+  /orgs/{org_name}/governance/policies:
+    parameters:
+      - $ref: "#/components/parameters/OrgName"
+    get:
+      operationId: listPolicies
+      tags: [policies]
+      summary: List policies
+      description: >
+        Returns a shallow summary of all policies for the org.
+        The rule set is not included; use GetPolicy to fetch the full object.
+      responses:
+        "200":
+          description: Object wrapping an array of policy summaries under `data`. Rule sets are not included; use GetPolicy to fetch a full policy.
+          content:
+            application/json:
+              schema:
+                type: object
+                required: [data]
+                properties:
+                  data:
+                    type: array
+                    items:
+                      $ref: "#/components/schemas/PolicySummary"
+              examples:
+                default:
+                  value:
+                    data:
+                      - id: pol_06evsmp24r1pg71cm8500546pkbn
+                        name: "Security Research — hardened"
+                        org: my-org
+                        scope:
+                          teams: [d290f1ee-6c54-4b01-90e6-d701748f0851]
+                        created_at: "2026-04-22T00:00:00Z"
+                        updated_at: "2026-04-22T00:00:00Z"
+                        type: allowlist_v0
+        "401":
+          $ref: "#/components/responses/Unauthenticated"
+        "403":
+          $ref: "#/components/responses/PermissionDenied"
+        "404":
+          $ref: "#/components/responses/NotFound"
+        "500":
+          $ref: "#/components/responses/InternalError"
+
+    post:
+      operationId: createPolicy
+      tags: [policies]
+      summary: Create policy
+      description: >
+        Creates a new policy with an empty rule set. Rules are added separately
+        via the rules sub-resource.
+      requestBody:
+        description: Policy name and optional scope.
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: "#/components/schemas/CreatePolicyRequest"
+            examples:
+              default:
+                value:
+                  name: "Security Research — hardened"
+                  scope:
+                    teams: [d290f1ee-6c54-4b01-90e6-d701748f0851]
+      responses:
+        "201":
+          description: Policy created. Returns the new policy without its rule set.
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Policy"
+              examples:
+                default:
+                  value:
+                    id: pol_06evsmp24r1pg71cm8500546pkbn
+                    name: "Security Research — hardened"
+                    org: my-org
+                    scope:
+                      teams: [d290f1ee-6c54-4b01-90e6-d701748f0851]
+                    created_at: "2026-04-22T00:00:00Z"
+                    updated_at: "2026-04-22T00:00:00Z"
+        "400":
+          $ref: "#/components/responses/InvalidArgument"
+        "401":
+          $ref: "#/components/responses/Unauthenticated"
+        "403":
+          $ref: "#/components/responses/Forbidden"
+        "404":
+          $ref: "#/components/responses/NotFound"
+        "409":
+          $ref: "#/components/responses/Conflict"
+        "500":
+          $ref: "#/components/responses/InternalError"
+
+  /orgs/{org_name}/governance/policies/{policy_id}:
+    parameters:
+      - $ref: "#/components/parameters/OrgName"
+      - $ref: "#/components/parameters/PolicyID"
+    get:
+      operationId: getPolicy
+      tags: [policies]
+      summary: Get policy
+      description: Returns the full policy including its `allowlist_v0` rule set.
+      responses:
+        "200":
+          description: Full policy including its `allowlist_v0` rule set.
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Policy"
+              examples:
+                default:
+                  value:
+                    id: pol_06evsmp24r1pg71cm8500546pkbn
+                    name: "Security Research — hardened"
+                    org: my-org
+                    scope:
+                      teams: [d290f1ee-6c54-4b01-90e6-d701748f0851]
+                    created_at: "2026-04-22T00:00:00Z"
+                    updated_at: "2026-04-22T00:00:00Z"
+                    allowlist_v0:
+                      domain: network
+                      rules:
+                        - id: rule_06evsm9qjm1pdsk0a8nkfaxy7jna
+                          name: allow research mirrors
+                          actions: [connect:tcp, connect:udp]
+                          resources: [research.mitre.org, cve.mitre.org]
+                          decision: allow
+        "401":
+          $ref: "#/components/responses/Unauthenticated"
+        "403":
+          $ref: "#/components/responses/PermissionDenied"
+        "404":
+          $ref: "#/components/responses/NotFound"
+        "500":
+          $ref: "#/components/responses/InternalError"
+    patch:
+      operationId: updatePolicy
+      tags: [policies]
+      summary: Update policy
+      description: |
+        Partially updates a policy's metadata. Only fields present in the
+        request body are updated; absent fields are left unchanged. The `scope`
+        object is patched per sub-field: sending `teams` replaces that list,
+        while an omitted sub-field is left untouched and an empty list clears
+        it (org-wide).
+
+        The rule set is not modified here — use the rule endpoints for that.
+        At least one field must be present. Returns the policy in both its old
+        and new states. Changes may take up to five minutes to reach developer
+        machines.
+      requestBody:
+        description: Fields to update. Absent fields are left unchanged.
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: "#/components/schemas/UpdatePolicyRequest"
+            examples:
+              rename:
+                summary: Rename the policy
+                value:
+                  name: Security Research
+              scope:
+                summary: Restrict to a team
+                value:
+                  scope:
+                    teams: [d290f1ee-6c54-4b01-90e6-d701748f0851]
+      responses:
+        "200":
+          description: Policy updated, returns old and new states.
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/UpdatePolicyResponse"
+              examples:
+                default:
+                  value:
+                    old:
+                      id: pol_06evsmp24r1pg71cm8500546pkbn
+                      name: "Security Research — hardened"
+                      org: my-org
+                      scope:
+                        teams: [d290f1ee-6c54-4b01-90e6-d701748f0851]
+                      created_at: "2026-04-22T00:00:00Z"
+                      updated_at: "2026-04-22T00:00:00Z"
+                      allowlist_v0:
+                        domain: network
+                        rules:
+                          - id: rule_06evsm9qjm1pdsk0a8nkfaxy7jna
+                            name: allow research mirrors
+                            actions: [connect:tcp, connect:udp]
+                            resources: [research.mitre.org, cve.mitre.org]
+                            decision: allow
+                    new:
+                      id: pol_06evsmp24r1pg71cm8500546pkbn
+                      name: Security Research
+                      org: my-org
+                      scope:
+                        teams: [d290f1ee-6c54-4b01-90e6-d701748f0851]
+                      created_at: "2026-04-22T00:00:00Z"
+                      updated_at: "2026-04-22T10:00:00Z"
+                      allowlist_v0:
+                        domain: network
+                        rules:
+                          - id: rule_06evsm9qjm1pdsk0a8nkfaxy7jna
+                            name: allow research mirrors
+                            actions: [connect:tcp, connect:udp]
+                            resources: [research.mitre.org, cve.mitre.org]
+                            decision: allow
+        "400":
+          $ref: "#/components/responses/InvalidArgument"
+        "401":
+          $ref: "#/components/responses/Unauthenticated"
+        "403":
+          $ref: "#/components/responses/Forbidden"
+        "404":
+          $ref: "#/components/responses/NotFound"
+        "409":
+          $ref: "#/components/responses/Conflict"
+        "500":
+          $ref: "#/components/responses/InternalError"
+    delete:
+      operationId: deletePolicy
+      tags: [policies]
+      summary: Delete policy
+      description: |
+        Permanently deletes the policy and its rule set. Returns the deleted
+        policy as a courtesy; its `updated_at` is unchanged by the deletion.
+        Changes may take up to five minutes to reach developer machines.
+      responses:
+        "200":
+          description: Policy deleted, returns the deleted policy.
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/DeletePolicyResponse"
+              examples:
+                default:
+                  value:
+                    deleted:
+                      id: pol_06evsmp24r1pg71cm8500546pkbn
+                      name: "Security Research — hardened"
+                      org: my-org
+                      scope:
+                        teams: [d290f1ee-6c54-4b01-90e6-d701748f0851]
+                      created_at: "2026-04-22T00:00:00Z"
+                      updated_at: "2026-04-22T00:00:00Z"
+                      allowlist_v0:
+                        domain: network
+                        rules:
+                          - id: rule_06evsm9qjm1pdsk0a8nkfaxy7jna
+                            name: allow research mirrors
+                            actions: [connect:tcp, connect:udp]
+                            resources: [research.mitre.org, cve.mitre.org]
+                            decision: allow
+        "401":
+          $ref: "#/components/responses/Unauthenticated"
+        "403":
+          $ref: "#/components/responses/PermissionDenied"
+        "404":
+          $ref: "#/components/responses/NotFound"
+        "500":
+          $ref: "#/components/responses/InternalError"
+
+  /orgs/{org_name}/governance/policies/{policy_id}/rules:
+    parameters:
+      - $ref: "#/components/parameters/OrgName"
+      - $ref: "#/components/parameters/PolicyID"
+    post:
+      operationId: createRule
+      tags: [rules]
+      summary: Create rule
+      description: |
+        Adds a rule to the policy's rule set. All rules in a policy must share
+        the same domain (network or filesystem); mixing domains is rejected.
+
+        **Network** actions: `connect:tcp`, `connect:udp`. Resources are
+        hostnames (for example, `example.com`), wildcard subdomains (`*.example.com`
+        for one level, `**.example.com` for any depth), hostnames with an optional
+        port (for example, `example.com:443`), or CIDRs in IPv4 or IPv6 notation
+        (for example, `10.0.0.0/8` or `2001:db8::/32`).
+
+        **Filesystem** actions: `read`, `write`. Resources are paths (for example,
+        `/data`). Use `*` to match within a single path segment and `**` to match
+        recursively across segments (for example, `/data/**`).
+
+        Changes may take up to five minutes to reach developer machines.
+      requestBody:
+        description: Rule definition including actions, resources, and decision.
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: "#/components/schemas/CreateRuleRequest"
+            examples:
+              network:
+                summary: Network rule
+                value:
+                  name: allow research mirrors
+                  actions: [connect:tcp, connect:udp]
+                  resources: [research.mitre.org, cve.mitre.org]
+                  decision: allow
+              filesystem:
+                summary: Filesystem rule
+                value:
+                  name: allow data directory
+                  actions: [read, write]
+                  resources: [/data]
+                  decision: allow
+      responses:
+        "201":
+          description: Rule created and added to the policy's rule set.
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Rule"
+              examples:
+                network:
+                  summary: Network rule
+                  value:
+                    id: rule_06evsm9qjm1pdsk0a8nkfaxy7jna
+                    name: allow research mirrors
+                    actions: [connect:tcp, connect:udp]
+                    resources: [research.mitre.org, cve.mitre.org]
+                    decision: allow
+                filesystem:
+                  summary: Filesystem rule
+                  value:
+                    id: rule_07fwtnr0kn2qetl1b9olfbyz8kob
+                    name: allow data directory
+                    actions: [read, write]
+                    resources: [/data]
+                    decision: allow
+        "400":
+          $ref: "#/components/responses/InvalidArgument"
+        "401":
+          $ref: "#/components/responses/Unauthenticated"
+        "403":
+          $ref: "#/components/responses/Forbidden"
+        "404":
+          $ref: "#/components/responses/NotFound"
+        "409":
+          $ref: "#/components/responses/Conflict"
+        "500":
+          $ref: "#/components/responses/InternalError"
+
+  /orgs/{org_name}/governance/policies/{policy_id}/rules/{rule_id}:
+    parameters:
+      - $ref: "#/components/parameters/OrgName"
+      - $ref: "#/components/parameters/PolicyID"
+      - $ref: "#/components/parameters/RuleID"
+    patch:
+      operationId: updateRule
+      tags: [rules]
+      summary: Update rule
+      description: |
+        Partially updates a rule. Only fields present in the request body are
+        updated; absent fields are left unchanged. Returns the rule in both its
+        old and new states.
+
+        Changing `actions` across domains (for example, from network actions to
+        filesystem actions) is rejected. Changes may take up to five minutes to
+        reach developer machines.
+      requestBody:
+        description: Fields to update. Absent fields are left unchanged.
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: "#/components/schemas/UpdateRuleRequest"
+            examples:
+              default:
+                value:
+                  resources: ["research.mitre.org"]
+      responses:
+        "200":
+          description: Rule updated, returns old and new states.
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/UpdateRuleResponse"
+              examples:
+                default:
+                  value:
+                    old:
+                      id: rule_06evsm9qjm1pdsk0a8nkfaxy7jna
+                      name: allow research mirrors
+                      actions: [connect:tcp, connect:udp]
+                      resources: [research.mitre.org, cve.mitre.org]
+                      decision: allow
+                    new:
+                      id: rule_06evsm9qjm1pdsk0a8nkfaxy7jna
+                      name: allow research mirrors
+                      actions: [connect:tcp, connect:udp]
+                      resources: [research.mitre.org]
+                      decision: allow
+        "400":
+          $ref: "#/components/responses/InvalidArgument"
+        "401":
+          $ref: "#/components/responses/Unauthenticated"
+        "403":
+          $ref: "#/components/responses/PermissionDenied"
+        "404":
+          $ref: "#/components/responses/NotFound"
+        "409":
+          $ref: "#/components/responses/Conflict"
+        "500":
+          $ref: "#/components/responses/InternalError"
+
+    delete:
+      operationId: deleteRule
+      tags: [rules]
+      summary: Delete rule
+      description: |
+        Deletes a rule from the policy. Returns the deleted rule. Changes may
+        take up to five minutes to reach developer machines.
+      responses:
+        "200":
+          description: Rule deleted, returns the deleted rule.
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/DeleteRuleResponse"
+              examples:
+                default:
+                  value:
+                    deleted:
+                      id: rule_06evsm9qjm1pdsk0a8nkfaxy7jna
+                      name: allow research mirrors
+                      actions: [connect:tcp, connect:udp]
+                      resources: [research.mitre.org, cve.mitre.org]
+                      decision: allow
+        "401":
+          $ref: "#/components/responses/Unauthenticated"
+        "403":
+          $ref: "#/components/responses/PermissionDenied"
+        "404":
+          $ref: "#/components/responses/NotFound"
+        "500":
+          $ref: "#/components/responses/InternalError"
+
+components:
+  securitySchemes:
+    bearerAuth:
+      type: http
+      scheme: bearer
+      bearerFormat: JWT
+      description: |
+        Short-lived JWT obtained by exchanging Docker Hub credentials at
+        `POST https://hub.docker.com/v2/auth/token`. Pass the JWT in the
+        `Authorization: Bearer <token>` header. Tokens expire after a short
+        period; request a fresh one when you receive a `401`.
+
+        The `password` field of the token request accepts any of the following
+        credential types:
+
+        | Type | Format | Notes |
+        |------|--------|-------|
+        | Password | Plain text | Your Docker Hub account password. |
+        | Personal Access Token (PAT) | `dckr_pat_*` | Recommended over passwords. Create one under Account Settings → Security. |
+        | Organization Access Token (OAT) | `dckr_oat_*` | Scoped to an organization. Create one under Organization Settings → Access Tokens. |
+
+        PAT and OAT strings can't be used directly as a bearer token. They must
+        be exchanged at the token endpoint first.
+
+        See [Docker Hub authentication](https://docs.docker.com/reference/api/hub/latest/#tag/authentication-api/operation/AuthCreateAccessToken)
+        for full details.
+
+  parameters:
+    OrgName:
+      name: org_name
+      in: path
+      required: true
+      description: Docker Hub organization name.
+      schema:
+        type: string
+      examples:
+        default:
+          value: my-org
+
+    PolicyID:
+      name: policy_id
+      in: path
+      required: true
+      description: Unique policy identifier.
+      schema:
+        type: string
+      examples:
+        default:
+          value: pol_06evsmp24r1pg71cm8500546pkbn
+
+    RuleID:
+      name: rule_id
+      in: path
+      required: true
+      description: Unique rule identifier within the policy.
+      schema:
+        type: string
+      examples:
+        default:
+          value: rule_06evsm9qjm1pdsk0a8nkfaxy7jna
+
+  schemas:
+    PolicySummary:
+      type: object
+      description: Shallow policy representation returned by ListPolicies. Excludes the rule set.
+      required: [id, name, org, scope, created_at, updated_at, type]
+      properties:
+        id:
+          type: string
+          examples:
+            - pol_06evsmp24r1pg71cm8500546pkbn
+        name:
+          type: string
+          description: Human-readable label, unique within the organization.
+          examples:
+            - "Security Research — hardened"
+        org:
+          type: string
+          examples:
+            - my-org
+        scope:
+          $ref: "#/components/schemas/Scope"
+        created_at:
+          type: string
+          format: date-time
+          examples:
+            - "2026-04-22T00:00:00Z"
+        updated_at:
+          type: string
+          format: date-time
+          examples:
+            - "2026-04-22T00:00:00Z"
+        type:
+          type: string
+          description: >
+            Identifies the rule-set format. Always `allowlist_v0`, corresponding
+            to the `allowlist_v0` property on the full Policy object.
+          examples:
+            - allowlist_v0
+
+    Policy:
+      type: object
+      description: Full policy representation including the allowlist rule set.
+      required: [id, name, org, scope, created_at, updated_at]
+      properties:
+        id:
+          type: string
+          examples:
+            - pol_06evsmp24r1pg71cm8500546pkbn
+        name:
+          type: string
+          description: Human-readable label, unique within the organization.
+          examples:
+            - "Security Research — hardened"
+        org:
+          type: string
+          examples:
+            - my-org
+        scope:
+          $ref: "#/components/schemas/Scope"
+        created_at:
+          type: string
+          format: date-time
+          examples:
+            - "2026-04-22T00:00:00Z"
+        updated_at:
+          type: string
+          format: date-time
+          examples:
+            - "2026-04-22T00:00:00Z"
+        allowlist_v0:
+          $ref: "#/components/schemas/AllowlistV0"
+
+    Scope:
+      type: object
+      description: Restricts the policy to specific teams. An empty or absent list means the policy applies org-wide.
+      properties:
+        teams:
+          type: array
+          items:
+            type: string
+          description: Team UUIDs the policy applies to. Each must be a valid team in the org.
+          examples:
+            - ["d290f1ee-6c54-4b01-90e6-d701748f0851"]
+
+    AllowlistV0:
+      type: object
+      description: |
+        Network or filesystem allowlist containing a list of rules. Present on
+        Policy when `PolicySummary.type` is `allowlist_v0`; omitted when the
+        policy has no rules yet. All rules in an allowlist share the same domain.
+        All rules are evaluated on every request: `deny` always wins over `allow`.
+      required: [rules]
+      properties:
+        domain:
+          type: string
+          description: >
+            The access-control domain shared by all rules in this allowlist.
+            Derived from rule actions: network actions (`connect:tcp`,
+            `connect:udp`) produce `network`; filesystem actions (`read`,
+            `write`) produce `filesystem`. Present when `rules` is non-empty;
+            absent when the allowlist has no rules.
+          enum: [network, filesystem]
+          examples:
+            - network
+        rules:
+          type: array
+          items:
+            $ref: "#/components/schemas/Rule"
+
+    Rule:
+      type: object
+      description: A single allow or deny rule within an allowlist policy.
+      required: [id, name, actions, resources, decision]
+      properties:
+        id:
+          type: string
+          examples:
+            - rule_06evsm9qjm1pdsk0a8nkfaxy7jna
+        name:
+          type: string
+          description: Human-readable label for the rule.
+          examples:
+            - allow research mirrors
+        actions:
+          $ref: "#/components/schemas/RuleActions"
+        resources:
+          $ref: "#/components/schemas/RuleResources"
+        decision:
+          $ref: "#/components/schemas/RuleDecision"
+
+    CreatePolicyRequest:
+      type: object
+      description: Fields required to create a new policy.
+      required: [name]
+      properties:
+        name:
+          type: string
+          description: Policy name, unique within the organization.
+          examples:
+            - "Security Research — hardened"
+        scope:
+          $ref: "#/components/schemas/Scope"
+
+    CreateRuleRequest:
+      type: object
+      description: Fields required to create a new rule within a policy's rule set.
+      required: [name, actions, resources, decision]
+      properties:
+        name:
+          type: string
+          description: Human-readable label for the rule.
+          examples:
+            - allow research mirrors
+        actions:
+          $ref: "#/components/schemas/RuleActions"
+        resources:
+          $ref: "#/components/schemas/RuleResources"
+        decision:
+          $ref: "#/components/schemas/RuleDecision"
+
+    UpdateRuleRequest:
+      type: object
+      description: Partial update. Only fields present in the body are updated; absent fields are left unchanged.
+      properties:
+        name:
+          type: string
+          description: Human-readable label for the rule.
+          examples:
+            - allow research mirrors
+        actions:
+          $ref: "#/components/schemas/RuleActions"
+        resources:
+          $ref: "#/components/schemas/RuleResources"
+        decision:
+          $ref: "#/components/schemas/RuleDecision"
+
+    UpdateRuleResponse:
+      type: object
+      description: The rule state before and after the update.
+      required: [old, new]
+      properties:
+        old:
+          $ref: "#/components/schemas/Rule"
+        new:
+          $ref: "#/components/schemas/Rule"
+
+    DeleteRuleResponse:
+      type: object
+      description: The deleted rule.
+      required: [deleted]
+      properties:
+        deleted:
+          $ref: "#/components/schemas/Rule"
+
+    UpdatePolicyRequest:
+      type: object
+      description: >
+        Partial update of a policy's metadata. Only fields present in the body
+        are updated; the rule set is not modified here. At least one field must
+        be present.
+      properties:
+        name:
+          type: string
+          minLength: 1
+          description: Policy name, unique within the organization.
+          examples:
+            - Security Research
+        scope:
+          $ref: "#/components/schemas/ScopePatch"
+
+    ScopePatch:
+      type: object
+      description: >
+        Per-sub-field patch of a policy's scope. An omitted sub-field is left
+        unchanged; a present list replaces that dimension, and an empty list
+        clears it (making the policy org-wide for that dimension).
+      properties:
+        teams:
+          type: array
+          items:
+            type: string
+          examples:
+            - ["d290f1ee-6c54-4b01-90e6-d701748f0851"]
+
+    UpdatePolicyResponse:
+      type: object
+      description: The full policy before and after the update.
+      required: [old, new]
+      properties:
+        old:
+          $ref: "#/components/schemas/Policy"
+        new:
+          $ref: "#/components/schemas/Policy"
+
+    DeletePolicyResponse:
+      type: object
+      description: The full deleted policy.
+      required: [deleted]
+      properties:
+        deleted:
+          $ref: "#/components/schemas/Policy"
+
+    RuleActions:
+      type: array
+      items:
+        type: string
+        enum: [connect:tcp, connect:udp, read, write]
+      minItems: 1
+      description: >
+        Network actions: `connect:tcp`, `connect:udp`.
+        Filesystem actions: `read`, `write`.
+        All actions in a rule must belong to the same domain; mixing network
+        and filesystem actions in one rule is rejected.
+      examples:
+        - ["connect:tcp", "connect:udp"]
+
+    RuleResources:
+      type: array
+      items:
+        type: string
+      minItems: 1
+      description: >
+        Network domain: hostnames (for example, `example.com`), wildcard
+        subdomains (`*.example.com` or `**.example.com`), hostnames with port
+        (for example, `example.com:443`), or CIDRs in IPv4 or IPv6 notation
+        (for example, `10.0.0.0/8` or `2001:db8::/32`). Filesystem domain:
+        paths (for example, `/data`); `*` matches within one path segment,
+        `**` matches recursively (for example, `/data/**`).
+      examples:
+        - ["research.mitre.org", "cve.mitre.org"]
+
+    RuleDecision:
+      type: string
+      enum: [allow, deny]
+      description: >
+        Outcome applied when this rule matches a request. `deny` always
+        wins: if any rule in the policy matches with `decision: deny`, the
+        request is denied even if other rules match with `decision: allow`.
+      examples:
+        - allow
+
+    Error:
+      type: object
+      description: Error envelope returned on all non-2xx responses.
+      required: [error]
+      properties:
+        error:
+          type: object
+          description: Error detail.
+          required: [code, message]
+          examples:
+            - code: not_found
+              message: policy not found
+          properties:
+            code:
+              type: string
+              description: >
+                Machine-readable error code. `not_found`: the requested resource
+                does not exist, the org does not exist, or the caller is not a
+                member of the org (the org's existence is not revealed to callers
+                who cannot access it). `conflict`: a resource with the same name
+                already exists. `invalid_argument`: the request body is malformed
+                or fails validation. `unauthenticated`: missing or invalid
+                credentials. `permission_denied`: the org is not entitled to use
+                governance. `limit_exceeded`: the org has reached its maximum
+                number of policies, or the policy has reached its maximum number
+                of rules. `unimplemented`: the endpoint or feature is not yet
+                available. `internal`: unexpected server error.
+              enum:
+                - not_found
+                - conflict
+                - invalid_argument
+                - unauthenticated
+                - permission_denied
+                - limit_exceeded
+                - unimplemented
+                - internal
+            message:
+              type: string
+
+  responses:
+    NotFound:
+      description: Not found
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/Error"
+          examples:
+            default:
+              value:
+                error:
+                  code: not_found
+                  message: policy not found
+
+    Conflict:
+      description: Conflict
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/Error"
+          examples:
+            default:
+              value:
+                error:
+                  code: conflict
+                  message: policy name already in use
+
+    InvalidArgument:
+      description: Bad request
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/Error"
+          examples:
+            default:
+              value:
+                error:
+                  code: invalid_argument
+                  message: "name is required"
+
+    Unauthenticated:
+      description: Missing or invalid credentials
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/Error"
+          examples:
+            default:
+              value:
+                error:
+                  code: unauthenticated
+                  message: unauthenticated
+
+    PermissionDenied:
+      description: >
+        Caller lacks the required permission for this org, or the org is not
+        entitled to use governance.
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/Error"
+          examples:
+            default:
+              value:
+                error:
+                  code: permission_denied
+                  message: permission denied
+
+    Forbidden:
+      description: >
+        Caller lacks the required permission for this org, the org is not
+        entitled to use governance (`permission_denied`), or a creation limit
+        has been reached (`limit_exceeded`): the org already has the maximum
+        number of policies, or the policy already has the maximum number of
+        rules.
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/Error"
+          examples:
+            permission_denied:
+              value:
+                error:
+                  code: permission_denied
+                  message: permission denied
+            limit_exceeded:
+              value:
+                error:
+                  code: limit_exceeded
+                  message: organization has reached the maximum of 100 policies
+
+    InternalError:
+      description: Internal server error
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/Error"
+          examples:
+            default:
+              value:
+                error:
+                  code: internal
+                  message: internal error
diff --git a/content/reference/api/ai-governance/index.md b/content/reference/api/ai-governance/index.md
new file mode 100644
index 000000000000..e9b5bc793612
--- /dev/null
+++ b/content/reference/api/ai-governance/index.md
@@ -0,0 +1,9 @@
+---
+layout: api-reference
+title: Docker AI Governance API
+linkTitle: AI Governance
+description: HTTP API reference for managing Docker AI Governance policies and rules programmatically.
+keywords: docker sandboxes, governance API, policy API, organization policy, REST API, openapi
+aliases:
+  - /ai/sandboxes/governance/api/
+---
diff --git a/content/reference/api/dvp/_index.md b/content/reference/api/dvp/_index.md
new file mode 100644
index 000000000000..18f6030ead2c
--- /dev/null
+++ b/content/reference/api/dvp/_index.md
@@ -0,0 +1,6 @@
+---
+title: DVP Data API
+build:
+  render: never
+---
+
diff --git a/content/reference/api/dvp/changelog.md b/content/reference/api/dvp/changelog.md
new file mode 100644
index 000000000000..0fc5f5b9dd89
--- /dev/null
+++ b/content/reference/api/dvp/changelog.md
@@ -0,0 +1,20 @@
+---
+description: Docker Verified Publisher API changelog
+title: Docker Verified Publisher API changelog
+linkTitle: Changelog
+keywords: docker dvp, dvp, whats new, release notes, api, changelog
+weight: 2
+toc_min: 1
+toc_max: 2
+---
+
+Here you can learn about the latest changes, new features, bug fixes, and known
+issues for Docker Verified Publisher API.
+
+---
+
+## 2025-06-27
+
+### New
+
+- Create changelog
diff --git a/content/reference/api/dvp/deprecated.md b/content/reference/api/dvp/deprecated.md
new file mode 100644
index 000000000000..a9d1330344b0
--- /dev/null
+++ b/content/reference/api/dvp/deprecated.md
@@ -0,0 +1,37 @@
+---
+description: Deprecated Docker Verified Publisher API endpoints
+keywords: deprecated
+title: Deprecated Docker Verified Publisher API endpoints
+linkTitle: Deprecated
+weight: 3
+---
+
+This page provides an overview of endpoints that are deprecated in Docker Verified Publisher API.
+
+## Endpoint deprecation policy
+
+As changes are made to Docker there may be times when existing endpoints need to be removed or replaced with newer endpoints. Before an existing endpoint is removed it is labeled as "deprecated" within the documentation. After some time it may be removed.
+
+## Deprecated endpoints
+
+The following table provides an overview of the current status of deprecated endpoints:
+
+**Deprecated**: the endpoint is marked "deprecated" and should no longer be used.
+
+The endpoint may be removed, disabled, or change behavior in a future release.
+
+**Removed**: the endpoint was removed, disabled, or hidden.
+
+---
+
+| Status | Feature                                                       | Date       |
+|--------|---------------------------------------------------------------|------------|
+|        | [Create deprecation log table](#create-deprecation-log-table) | 2025-06-27 |
+
+---
+
+### Create deprecation log table
+
+Reformat page
+
+---
\ No newline at end of file
diff --git a/content/reference/api/dvp/latest.md b/content/reference/api/dvp/latest.md
new file mode 100644
index 000000000000..1ef4fdf075ba
--- /dev/null
+++ b/content/reference/api/dvp/latest.md
@@ -0,0 +1,9 @@
+---
+layout: api
+description: Reference documentation and Swagger (OpenAPI) specification for the Docker Verified Publisher API.
+title: Docker Verified Publisher API reference
+linkTitle: Latest
+weight: 1
+aliases:
+  - /reference/api/hub/dvp/
+---
diff --git a/content/reference/api/dvp/latest.yaml b/content/reference/api/dvp/latest.yaml
new file mode 100644
index 000000000000..01811d55bc7c
--- /dev/null
+++ b/content/reference/api/dvp/latest.yaml
@@ -0,0 +1,696 @@
+openapi: 3.0.0
+info:
+  title: DVP Data API
+  version: 1.0.0
+  x-logo:
+    url: https://docs.docker.com/assets/images/logo-docker-main.png
+    href: /reference
+  description: |
+     The Docker DVP Data API allows [Docker Verified Publishers](https://docs.docker.com/docker-hub/publish/) to view image pull analytics data for their namespaces. Analytics data can be retrieved in a CSV as raw data, or in a summary format.
+       
+     #### Summary data
+
+     In your summary data CSV, you will have access to the data points listed below. You can request summary data for a complete week (Monday through Sunday) or for a complete month (available on the first day of the following month). 
+
+     There are two levels of summary data:
+
+     - Repository-level, a summary of every namespace and repository
+     - Tag- or digest-level, a summary of every namespace, repository, and reference
+       (tag or digest)
+
+     The summary data formats contain the following data points:
+
+     - Unique IP address count
+     - Pulls by tag count
+     - Pulls by digest count
+     - Version check count
+
+     #### Raw data
+
+     In your raw data CSV you will have access to the data points listed below. You can request raw data for a complete week (Monday through Sunday) or for a complete month (available on the first day of the following month). **Note:** each action is represented as a single row.
+
+     - Type (industry)
+     - Host (cloud provider)
+     - Country (geolocation)
+     - Timestamp
+     - Namespace
+     - Repository
+     - Reference (digest is always included, tag is provided when available)
+     - HTTP request method
+     - Action, one of the following:
+       - Pull by tag
+       - Pull by digest
+       - Version check
+     - User-Agent
+
+servers:
+  - url: https://hub.docker.com/api/publisher/analytics/v1
+security:
+  - HubAuth: []
+
+features.openapi:
+  schemaDefinitionsTagName: Schemas
+
+tags:
+  - name: authentication
+    x-displayName: Authentication Endpoints
+  - name: namespaces
+    x-displayName: Namespace data
+  - name: discovery
+    x-displayName: Discovery
+  - name: responseDataFile
+    x-displayName: ResponseDataFile
+    description: |
+      <SchemaDefinition schemaRef="#/components/schemas/ResponseDataFile" />
+  - name: yearModel
+    x-displayName: Year Data Model
+    description: |
+      <SchemaDefinition schemaRef="#/components/schemas/YearModel" />
+  - name: monthModel
+    x-displayName: Month Data Model
+    description: |
+      <SchemaDefinition schemaRef="#/components/schemas/MonthModel" />
+  - name: weekModel
+    x-displayName: Week Data Model
+    description: |
+      <SchemaDefinition schemaRef="#/components/schemas/WeekModel" />
+
+x-tagGroups:
+  - name: API
+    tags:
+      - authentication
+      - discovery
+      - namespaces
+  - name: Models
+    tags:
+      - responseDataFile
+      - yearModel
+      - monthModel
+      - weekModel
+
+paths:
+  /v2/users/login:
+    security: []
+    servers:
+      - url: https://hub.docker.com
+    post:
+      security: []
+      tags:
+        - authentication
+      summary: Create an authentication token
+      operationId: PostUsersLogin
+      description: |
+        Creates and returns a bearer token in JWT format that you can use to
+        authenticate with Docker Hub APIs.
+
+        The returned token is used in the HTTP Authorization header like `Authorization: Bearer {TOKEN}`.
+
+        Most Docker Hub APIs require this token either to consume or to get detailed information. For example, to list images in a private repository.
+      requestBody:
+        content:
+          application/json:
+            schema:
+              $ref: "#/components/schemas/UsersLoginRequest"
+        description: Login details.
+        required: true
+      responses:
+        200:
+          description: Authentication successful
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/PostUsersLoginSuccessResponse"
+        401:
+          description: Authentication failed or second factor required
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/PostUsersLoginErrorResponse"
+  /v2/users/2fa-login:
+    security: []
+    servers:
+      - url: https://hub.docker.com
+    post:
+      security: []
+      tags:
+        - authentication
+      summary: Second factor authentication
+      operationId: PostUsers2FALogin
+      description: |
+        When a user has 2FA enabled, this is the second call to perform after
+        `/v2/users/login` call.
+
+        Creates and returns a bearer token in JWT format that you can use to authenticate with Docker Hub APIs.
+
+        The returned token is used in the HTTP Authorization header like `Authorization: Bearer {TOKEN}`.
+
+        Most Docker Hub APIs require this token either to consume or to get detailed information. For example, to list images in a private repository.
+      requestBody:
+        content:
+          application/json:
+            schema:
+              $ref: "#/components/schemas/Users2FALoginRequest"
+        description: Login details.
+        required: true
+      responses:
+        200:
+          description: Authentication successful
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/PostUsersLoginSuccessResponse"
+        401:
+          description: Authentication failed or second factor required
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/PostUsers2FALoginErrorResponse"
+
+
+  /:
+    get:
+      tags: [discovery]
+      summary: Get namespaces and repos
+      description: Gets a list of your namespaces and repos which have data available.
+      operationId: getNamespaces
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/NamespaceData'
+  /namespaces:
+    get:
+      tags: [discovery]
+      summary: Get user's namespaces
+      description: Get metadata associated with the namespaces the user has access to, including extra repos associated with the namespaces.
+      operationId: getUserNamespaces
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                type: array
+                items:
+                  $ref: '#/components/schemas/NamespaceMetadata'
+        '401':
+          description: Authentication failed or second factor required
+  /namespaces/{namespace}:
+    get:
+      tags: [discovery]
+      summary: Get namespace
+      description: Gets metadata associated with specified namespace, including extra repos associated with the namespace.
+      operationId: getNamespace
+      parameters:
+        - in: path
+          name: namespace
+          schema:
+            type: string
+          required: true
+          description: Namespace to fetch data for
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/NamespaceMetadata'
+  /namespaces/{namespace}/pulls:
+    get:
+      tags: [namespaces]
+      summary: Get pull data
+      description: Gets pulls for the given namespace.
+      operationId: getNamespacePulls
+      parameters:
+        - in: path
+          name: namespace
+          schema:
+            type: string
+          required: true
+          description: Namespace to fetch data for
+        - in: query
+          name: timespan
+          schema:
+            $ref: '#/components/schemas/TimespanType'
+          required: false
+          description: Timespan type for fetching data
+        - in: query
+          name: period
+          schema:
+            $ref: '#/components/schemas/PeriodType'
+          required: false
+          description: Relative period of the period to fetch data
+        - in: query
+          name: group
+          schema:
+            $ref: '#/components/schemas/GroupType'
+          required: false
+          description: Field to group the data by
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/PullData'
+        '404':
+          description: Not found - namespace doesn't exist or user does not have permission to access it
+  /namespaces/{namespace}/repos/{repo}/pulls:
+    get:
+      tags: [namespaces]
+      summary: Get pull data
+      description: Gets pulls for the given repo.
+      operationId: getRepoPulls
+      parameters:
+        - in: path
+          name: namespace
+          schema:
+            type: string
+          required: true
+          description: Namespace to fetch data for
+        - in: path
+          name: repo
+          schema:
+            type: string
+          required: true
+          description: Repository to fetch data for
+        - in: query
+          name: timespan
+          schema:
+            $ref: '#/components/schemas/TimespanType'
+          required: false
+          description: Timespan type for fetching data
+        - in: query
+          name: period
+          schema:
+            $ref: '#/components/schemas/PeriodType'
+          required: false
+          description: Relative period of the period to fetch data
+        - in: query
+          name: group
+          schema:
+            $ref: '#/components/schemas/GroupType'
+          required: false
+          description: Field to group the data by
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/PullData'
+        '404':
+          description: Not found - repo doesn't exist or user does not have permission to access it
+  /namespaces/{namespace}/pulls/exports/years:
+    get:
+      tags: [namespaces]
+      summary: Get years with data
+      description: Gets a list of years that have data for the given namespace.
+      operationId: getNamespaceYears
+      parameters:
+        - in: path
+          name: namespace
+          schema:
+            type: string
+          required: true
+          description: Namespace to fetch data for
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/YearData'
+  /namespaces/{namespace}/pulls/exports/years/{year}/{timespantype}:
+    get:
+      tags: [namespaces]
+      summary: Get timespans with data
+      description: Gets a list of timespans of the given type that have data for the given namespace and year.
+      operationId: getNamespaceTimespans
+      parameters:
+        - in: path
+          name: namespace
+          schema:
+            type: string
+          required: true
+          description: Namespace to fetch data for
+        - in: path
+          name: year
+          schema:
+            type: integer
+          required: true
+          description: Year to fetch data for
+        - in: path
+          name: timespantype
+          schema:
+            $ref: '#/components/schemas/TimespanType'
+          required: true
+          description: Type of timespan to fetch data for
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/TimespanData'
+  /namespaces/{namespace}/pulls/exports/years/{year}/{timespantype}/{timespan}:
+    get:
+      tags: [namespaces]
+      summary: Get namespace metadata for timespan
+      description: Gets info about data for the given namespace and timespan.
+      operationId: getNamespaceTimespanMetadata
+      parameters:
+        - in: path
+          name: namespace
+          schema:
+            type: string
+          required: true
+          description: Namespace to fetch data for
+        - in: path
+          name: year
+          schema:
+            type: integer
+          required: true
+          description: Year to fetch data for
+        - in: path
+          name: timespantype
+          schema:
+            $ref: '#/components/schemas/TimespanType'
+          required: true
+          description: Type of timespan to fetch data for
+        - in: path
+          name: timespan
+          schema:
+            type: integer
+          required: true
+          description: Timespan to fetch data for
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/TimespanModel'
+        '404':
+          description: Not Found
+  /namespaces/{namespace}/pulls/exports/years/{year}/{timespantype}/{timespan}/{dataview}:
+    get:
+      tags: [namespaces]
+      summary: Get namespace data for timespan
+      description: Gets a list of URLs that can be used to download the pull data for the given namespace and timespan.
+      operationId: getNamespaceDataByTimespan
+      parameters:
+        - in: path
+          name: namespace
+          schema:
+            type: string
+          required: true
+          description: Namespace to fetch data for
+        - in: path
+          name: year
+          schema:
+            type: integer
+          required: true
+          description: Year to fetch data for
+        - in: path
+          name: timespantype
+          schema:
+            $ref: '#/components/schemas/TimespanType'
+          required: true
+          description: Type of timespan to fetch data for
+        - in: path
+          name: timespan
+          schema:
+            type: integer
+          required: true
+          description: Timespan to fetch data for
+        - in: path
+          name: dataview
+          schema:
+            $ref: '#/components/schemas/DataviewType'
+          required: true
+          description: Type of data to fetch
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/ResponseData'
+  /repos/pulls:
+    get:
+      tags: [namespaces]
+      summary: Get pull data for multiple repos
+      description: Gets pull for the given repos.
+      operationId: getManyReposPulls
+      parameters:
+        - in: query
+          name: repos
+          schema:
+            type: array
+            items:
+              type: string
+          required: true
+          description: Repositories to fetch data for (maximum of 50 repositories per request).
+        - in: query
+          name: timespan
+          schema:
+            $ref: '#/components/schemas/TimespanType'
+          required: false
+          description: Timespan type for fetching data
+        - in: query
+          name: period
+          schema:
+            $ref: '#/components/schemas/PeriodType'
+          required: false
+          description: Relative period of the period to fetch data
+        - in: query
+          name: group
+          schema:
+            $ref: '#/components/schemas/GroupType'
+          required: false
+          description: Field to group the data by
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/ReposPullData'
+
+components:
+  schemas:
+    UsersLoginRequest:
+      description: User login details
+      type: object
+      required:
+        - username
+        - password
+      properties:
+        username:
+          description: The username of the Docker Hub account to authenticate with.
+          type: string
+          example: myusername
+        password:
+          description:
+            The password or personal access token (PAT) of the Docker Hub
+            account to authenticate with.
+          type: string
+          example: hunter2
+    PostUsersLoginSuccessResponse:
+      description: successful user login response
+      type: object
+      properties:
+        token:
+          description: |
+            Created authentication token.
+
+            This token can be used in the HTTP Authorization header as a JWT to authenticate with the Docker Hub APIs.
+          type: string
+          example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
+          nullable: false
+    PostUsersLoginErrorResponse:
+      description: failed user login response or second factor required
+      type: object
+      required:
+        - detail
+      properties:
+        detail:
+          description: Description of the error.
+          type: string
+          example: Incorrect authentication credentials
+          nullable: false
+        login_2fa_token:
+          description:
+            Short-lived token to be used on `/v2/users/2fa-login` to
+            complete the authentication. This field is present only if 2FA is
+            enabled.
+          type: string
+          example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
+          nullable: true
+    Users2FALoginRequest:
+      description: Second factor user login details
+      type: object
+      required:
+        - login_2fa_token
+        - code
+      properties:
+        login_2fa_token:
+          description: The intermediate 2FA token returned from `/v2/users/login` API.
+          type: string
+          example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
+        code:
+          description:
+            The Time-based One-Time Password of the Docker Hub account to
+            authenticate with.
+          type: string
+          example: 123456
+    PostUsers2FALoginErrorResponse:
+      description: failed second factor login response.
+      type: object
+      properties:
+        detail:
+          description: Description of the error.
+          type: string
+          example: Incorrect authentication credentials
+          nullable: false
+
+    ResponseData:
+      properties:
+        data:
+          type: array
+          description: |
+            List of urls to download the data. When the data is large, the data will be split into multiple files.
+          items: 
+            $ref: '#/components/schemas/ResponseDataFile'
+    ResponseDataFile:
+      properties:
+        url:
+          type: string
+        size:
+          type: integer
+          format: int64
+    NamespaceData:
+      properties:
+        namespaces:
+          type: array
+          items:
+            type: string
+    NamespaceMetadata:
+      properties:
+        namespace:
+          type: string
+        extraRepos:
+          type: array
+          items:
+            type: string
+        datasets:
+          type: array
+          items:
+            $ref: '#/components/schemas/DatasetModel'
+    DatasetModel:
+      properties:
+        name:
+          $ref: '#/components/schemas/DatasetType'
+        views:
+          type: array
+          items:
+            $ref: '#/components/schemas/DataviewType'
+        timespans:
+          type: array
+          items:
+            $ref: '#/components/schemas/TimespanType'
+    PullData:
+      properties:
+        pulls:
+          type: array
+          items:
+            $ref: '#/components/schemas/PullModel'
+    ReposPullData:
+      properties:
+        repos:
+          type: object
+          additionalProperties:
+            $ref: '#/components/schemas/PullData'
+    PullModel:
+      properties:
+        start:
+          type: string
+        end:
+          type: string
+        repo:
+          type: string
+        namespace:
+          type: string
+        pullCount:
+          type: integer
+        ipCount:
+          type: integer
+        country:
+          type: string
+    
+    YearData:
+      properties:
+        years:
+          type: array
+          items:
+            $ref: '#/components/schemas/YearModel'
+    YearModel:
+      properties:
+        year:
+          type: integer
+    MonthData:
+      properties:
+        months:
+          type: array
+          items:
+            $ref: '#/components/schemas/MonthModel'
+    MonthModel:
+      properties:
+        month:
+          type: integer
+    WeekData:
+      properties:
+        weeks:
+          type: array
+          items:
+            $ref: '#/components/schemas/WeekModel'
+    WeekModel:
+      properties:
+        week:
+          type: integer
+    TimespanType:
+      type: string
+      enum: [months,weeks]
+    PeriodType:
+      type: string
+      enum: [last-2-months,last-3-months,last-6-months,last-12-months]
+    DataviewType:
+      type: string
+      enum: [raw,summary,repo-summary,namespace-summary]
+    DatasetType:
+      type: string
+      enum: [pulls]
+    TimespanModel:
+      oneOf:
+        - $ref: '#/components/schemas/MonthModel'
+        - $ref: '#/components/schemas/WeekModel'
+    TimespanData:
+      oneOf:
+        - $ref: '#/components/schemas/MonthData'
+        - $ref: '#/components/schemas/WeekData'
+    GroupType:
+      type: string
+      enum: [repo,namespace]
+  securitySchemes:
+    HubAuth:
+      type: https
+      scheme: bearer
+      bearerFormat: JWT
+      description: |
+        JWT Bearer Authentication is required to access the Docker DVP Data API.  
+          
+        This authentication documentation is duplicated from the [Hub API Authentication docs](https://docs.docker.com/reference/api/hub/latest/#tag/authentication)
+      x-displayName: Docker Hub Authentication
diff --git a/content/reference/api/engine/_index.md b/content/reference/api/engine/_index.md
index 438e1ea723b0..a00b90374afe 100644
--- a/content/reference/api/engine/_index.md
+++ b/content/reference/api/engine/_index.md
@@ -41,7 +41,7 @@ The Docker Engine API is a RESTful API accessed by an HTTP client such as `wget`
 
 You can
 [view the reference for the latest version of the API](/reference/api/engine/version/v{{% param latest_engine_api_version %}}.md)
-or [choose a specific version](/reference/api/engine/version-history/).
+or [choose a specific version](/reference/api/engine/#api-version-matrix).
 
 ## Versioned API and SDK
 
@@ -67,28 +67,20 @@ A new version of the API is released when new features are added. The Docker API
 is backward-compatible, so you don't need to update code that uses the API
 unless you need to take advantage of new features.
 
-To see the highest version of the API your Docker daemon and client support, use
-`docker version`:
+To see the highest and lowest version of the API your Docker daemon and client
+support, use `docker version`:
 
 ```console
 $ docker version
 Client: Docker Engine - Community
- Version:           28.0.0
- API version:       1.48
- Go version:        go1.23.6
- Git commit:        f9ced58
- Built:             Wed Feb 19 22:11:04 2025
- OS/Arch:           linux/amd64
- Context:           default
+ Version:           {{% param "docker_ce_version" %}}
+ API version:       {{% param "latest_engine_api_version" %}}
+ ...
 
 Server: Docker Engine - Community
  Engine:
-  Version:          28.0.0
-  API version:      1.48 (minimum version 1.24)
-  Go version:       go1.23.6
-  Git commit:       af898ab
-  Built:            Wed Feb 19 22:11:04 2025
-  OS/Arch:          linux/amd64
+  Version:          {{% param "docker_ce_version" %}}
+  API version:      {{% param "latest_engine_api_version" %}} (minimum version 1.40)
   ...
 ```
 
@@ -102,7 +94,7 @@ You can specify the API version to use in any of the following ways:
 - To force the Docker CLI or the Docker Engine SDKs to use an older version
   of the API than the version reported by `docker version`, set the
   environment variable `DOCKER_API_VERSION` to the correct version. This works
-  on Linux, Windows, or macOS clients.
+  on Linux, Windows, and macOS clients.
 
   {{% apiVersionPrevious.inline %}}
   {{- $version := site.Params.latest_engine_api_version }}
@@ -128,49 +120,107 @@ You can specify the API version to use in any of the following ways:
   or the
   [Python SDK documentation for `client`](https://docker-py.readthedocs.io/en/stable/client.html).
 
+### Minimum API version
+
+The Docker Engine API server and client support API-version negotiation. If
+a client connects to an older version of the Docker Engine, it negotiates
+the highest version of the API supported by both the client and daemon,
+downgrading to an older version of the API if necessary.
+
+When downgrading to an older API version, features introduced in later API
+versions are disabled, and API requests and responses are adjusted for the
+API version negotiated.
+
+API version negotiation allows tools that have not been upgraded yet to the
+latest API version specification to communicate with newer Docker Engines
+(and vice versa), but compatibility is "best effort"; while Docker strives
+to provide full compatibility, some functionality may not be available.
+
 ### API version matrix
 
-| Docker version | Maximum API version                          | Change log                                                         |
-|:---------------|:---------------------------------------------|:-------------------------------------------------------------------|
-| 28.0           | [1.48](/reference/api/engine/version/v1.48/) | [changes](/reference/api/engine/version-history/#v148-api-changes) |
-| 27.5           | [1.47](/reference/api/engine/version/v1.47/) | [changes](/reference/api/engine/version-history/#v147-api-changes) |
-| 27.4           | [1.47](/reference/api/engine/version/v1.47/) | [changes](/reference/api/engine/version-history/#v147-api-changes) |
-| 27.3           | [1.47](/reference/api/engine/version/v1.47/) | [changes](/reference/api/engine/version-history/#v147-api-changes) |
-| 27.2           | [1.47](/reference/api/engine/version/v1.47/) | [changes](/reference/api/engine/version-history/#v147-api-changes) |
-| 27.1           | [1.46](/reference/api/engine/version/v1.46/) | [changes](/reference/api/engine/version-history/#v146-api-changes) |
-| 27.0           | [1.46](/reference/api/engine/version/v1.46/) | [changes](/reference/api/engine/version-history/#v146-api-changes) |
-| 26.1           | [1.45](/reference/api/engine/version/v1.45/) | [changes](/reference/api/engine/version-history/#v145-api-changes) |
-| 26.0           | [1.45](/reference/api/engine/version/v1.45/) | [changes](/reference/api/engine/version-history/#v145-api-changes) |
-| 25.0           | [1.44](/reference/api/engine/version/v1.44/) | [changes](/reference/api/engine/version-history/#v144-api-changes) |
-| 24.0           | [1.43](/reference/api/engine/version/v1.43/) | [changes](/reference/api/engine/version-history/#v143-api-changes) |
-| 23.0           | [1.42](/reference/api/engine/version/v1.42/) | [changes](/reference/api/engine/version-history/#v142-api-changes) |
-| 20.10          | [1.41](/reference/api/engine/version/v1.41/) | [changes](/reference/api/engine/version-history/#v141-api-changes) |
-| 19.03          | [1.40](/reference/api/engine/version/v1.40/) | [changes](/reference/api/engine/version-history/#v140-api-changes) |
-| 18.09          | [1.39](/reference/api/engine/version/v1.39/) | [changes](/reference/api/engine/version-history/#v139-api-changes) |
-| 18.06          | [1.38](/reference/api/engine/version/v1.38/) | [changes](/reference/api/engine/version-history/#v138-api-changes) |
-| 18.05          | [1.37](/reference/api/engine/version/v1.37/) | [changes](/reference/api/engine/version-history/#v137-api-changes) |
-| 18.04          | [1.37](/reference/api/engine/version/v1.37/) | [changes](/reference/api/engine/version-history/#v137-api-changes) |
-| 18.03          | [1.37](/reference/api/engine/version/v1.37/) | [changes](/reference/api/engine/version-history/#v137-api-changes) |
-| 18.02          | [1.36](/reference/api/engine/version/v1.36/) | [changes](/reference/api/engine/version-history/#v136-api-changes) |
-| 17.12          | [1.35](/reference/api/engine/version/v1.35/) | [changes](/reference/api/engine/version-history/#v135-api-changes) |
-| 17.11          | [1.34](/reference/api/engine/version/v1.34/) | [changes](/reference/api/engine/version-history/#v134-api-changes) |
-| 17.10          | [1.33](/reference/api/engine/version/v1.33/) | [changes](/reference/api/engine/version-history/#v133-api-changes) |
-| 17.09          | [1.32](/reference/api/engine/version/v1.32/) | [changes](/reference/api/engine/version-history/#v132-api-changes) |
-| 17.07          | [1.31](/reference/api/engine/version/v1.31/) | [changes](/reference/api/engine/version-history/#v131-api-changes) |
-| 17.06          | [1.30](/reference/api/engine/version/v1.30/) | [changes](/reference/api/engine/version-history/#v130-api-changes) |
-| 17.05          | [1.29](/reference/api/engine/version/v1.29/) | [changes](/reference/api/engine/version-history/#v129-api-changes) |
-| 17.04          | [1.28](/reference/api/engine/version/v1.28/) | [changes](/reference/api/engine/version-history/#v128-api-changes) |
-| 17.03.1        | [1.27](/reference/api/engine/version/v1.27/) | [changes](/reference/api/engine/version-history/#v127-api-changes) |
-| 17.03          | [1.26](/reference/api/engine/version/v1.27/) | [changes](/reference/api/engine/version-history/#v126-api-changes) |
-| 1.13.1         | [1.26](/reference/api/engine/version/v1.26/) | [changes](/reference/api/engine/version-history/#v126-api-changes) |
-| 1.13           | [1.25](/reference/api/engine/version/v1.26/) | [changes](/reference/api/engine/version-history/#v125-api-changes) |
-| 1.12           | [1.24](/reference/api/engine/version/v1.24/) | [changes](/reference/api/engine/version-history/#v124-api-changes) |
+| Docker version | Maximum API version                          | Minimum API version                          | Change log                                                         |
+|:---------------|:---------------------------------------------|:---------------------------------------------|:-------------------------------------------------------------------|
+| 29.7           | [1.55](/reference/api/engine/version/v1.55/) | [1.40](/reference/api/engine/version/v1.40/) | [changes](/reference/api/engine/version-history/#v155-api-changes) |
+| 29.6           | [1.55](/reference/api/engine/version/v1.55/) | [1.40](/reference/api/engine/version/v1.40/) | [changes](/reference/api/engine/version-history/#v155-api-changes) |
+| 29.5           | [1.54](/reference/api/engine/version/v1.54/) | [1.40](/reference/api/engine/version/v1.40/) | [changes](/reference/api/engine/version-history/#v154-api-changes) |
+| 29.4           | [1.54](/reference/api/engine/version/v1.54/) | [1.40](/reference/api/engine/version/v1.40/) | [changes](/reference/api/engine/version-history/#v154-api-changes) |
+| 29.3           | [1.54](/reference/api/engine/version/v1.54/) | [1.40](/reference/api/engine/version/v1.40/) | [changes](/reference/api/engine/version-history/#v154-api-changes) |
+| 29.2           | [1.53](/reference/api/engine/version/v1.53/) | [1.44](/reference/api/engine/version/v1.44/) | [changes](/reference/api/engine/version-history/#v153-api-changes) |
+| 29.1           | [1.52](/reference/api/engine/version/v1.52/) | [1.44](/reference/api/engine/version/v1.44/) | [changes](/reference/api/engine/version-history/#v152-api-changes) |
+| 29.0           | [1.52](/reference/api/engine/version/v1.52/) | [1.44](/reference/api/engine/version/v1.44/) | [changes](/reference/api/engine/version-history/#v152-api-changes) |
+| 28.5           | [1.51](/reference/api/engine/version/v1.51/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v151-api-changes) |
+| 28.4           | [1.51](/reference/api/engine/version/v1.51/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v151-api-changes) |
+| 28.3           | [1.51](/reference/api/engine/version/v1.51/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v151-api-changes) |
+| 28.2           | [1.50](/reference/api/engine/version/v1.50/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v150-api-changes) |
+| 28.1           | [1.49](/reference/api/engine/version/v1.49/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v149-api-changes) |
+| 28.0           | [1.48](/reference/api/engine/version/v1.48/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v148-api-changes) |
+| 27.5           | [1.47](/reference/api/engine/version/v1.47/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v147-api-changes) |
+| 27.4           | [1.47](/reference/api/engine/version/v1.47/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v147-api-changes) |
+| 27.3           | [1.47](/reference/api/engine/version/v1.47/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v147-api-changes) |
+| 27.2           | [1.47](/reference/api/engine/version/v1.47/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v147-api-changes) |
+| 27.1           | [1.46](/reference/api/engine/version/v1.46/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v146-api-changes) |
+| 27.0           | [1.46](/reference/api/engine/version/v1.46/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v146-api-changes) |
+| 26.1           | [1.45](/reference/api/engine/version/v1.45/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v145-api-changes) |
+| 26.0           | [1.45](/reference/api/engine/version/v1.45/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v145-api-changes) |
+| 25.0           | [1.44](/reference/api/engine/version/v1.44/) | 1.24                                         | [changes](/reference/api/engine/version-history/#v144-api-changes) |
+| 24.0           | [1.43](/reference/api/engine/version/v1.43/) | 1.12                                         | [changes](/reference/api/engine/version-history/#v143-api-changes) |
+| 23.0           | [1.42](/reference/api/engine/version/v1.42/) | 1.12                                         | [changes](/reference/api/engine/version-history/#v142-api-changes) |
+| 20.10          | [1.41](/reference/api/engine/version/v1.41/) | 1.12                                         | [changes](/reference/api/engine/version-history/#v141-api-changes) |
+| 19.03          | [1.40](/reference/api/engine/version/v1.40/) | 1.12                                         | [changes](/reference/api/engine/version-history/#v140-api-changes) |
 
 ### Deprecated API versions
 
-API versions before v1.24 are [deprecated](/engine/deprecated/#deprecate-legacy-api-versions).
-You can find archived documentation for deprecated versions of the API in the
-code repository on GitHub:
-
-- [Documentation for API versions 1.23 and before](https://github.com/moby/moby/tree/v25.0.0/docs/api).
-- [Documentation for API versions 1.17 and before](https://github.com/moby/moby/tree/v1.9.1/docs/reference/api).
+API versions before v1.40 are deprecated and no longer supported by current
+versions of the Docker Engine and CLI. You can find archived documentation
+for deprecated versions of the API [in the code repository on GitHub](https://github.com/moby/moby/tree/docker-v{{% param "docker_ce_version" %}}/api/docs):
+
+| Docker version | Maximum API version | Minimum API version | Change log                                                         |
+|:---------------|:--------------------|:--------------------|:-------------------------------------------------------------------|
+| 18.09          | 1.39                | 1.12                | [changes](/reference/api/engine/version-history/#v139-api-changes) |
+| 18.06          | 1.38                | 1.12                | [changes](/reference/api/engine/version-history/#v138-api-changes) |
+| 18.05          | 1.37                | 1.12                | [changes](/reference/api/engine/version-history/#v137-api-changes) |
+| 18.04          | 1.37                | 1.12                | [changes](/reference/api/engine/version-history/#v137-api-changes) |
+| 18.03          | 1.37                | 1.12                | [changes](/reference/api/engine/version-history/#v137-api-changes) |
+| 18.02          | 1.36                | 1.12                | [changes](/reference/api/engine/version-history/#v136-api-changes) |
+| 17.12          | 1.35                | 1.12                | [changes](/reference/api/engine/version-history/#v135-api-changes) |
+| 17.11          | 1.34                | 1.12                | [changes](/reference/api/engine/version-history/#v134-api-changes) |
+| 17.10          | 1.33                | 1.12                | [changes](/reference/api/engine/version-history/#v133-api-changes) |
+| 17.09          | 1.32                | 1.12                | [changes](/reference/api/engine/version-history/#v132-api-changes) |
+| 17.07          | 1.31                | 1.12                | [changes](/reference/api/engine/version-history/#v131-api-changes) |
+| 17.06          | 1.30                | 1.12                | [changes](/reference/api/engine/version-history/#v130-api-changes) |
+| 17.05          | 1.29                | 1.12                | [changes](/reference/api/engine/version-history/#v129-api-changes) |
+| 17.04          | 1.28                | 1.12                | [changes](/reference/api/engine/version-history/#v128-api-changes) |
+| 17.03.1        | 1.27                | 1.12                | [changes](/reference/api/engine/version-history/#v127-api-changes) |
+| 17.03          | 1.26                | 1.12                | [changes](/reference/api/engine/version-history/#v126-api-changes) |
+| 1.13.1         | 1.26                | 1.12                | [changes](/reference/api/engine/version-history/#v126-api-changes) |
+| 1.13           | 1.25                | 1.12                | [changes](/reference/api/engine/version-history/#v125-api-changes) |
+| 1.12           | 1.24                | 1.12                | [changes](/reference/api/engine/version-history/#v124-api-changes) |
+| 1.11           | 1.23                | 1.12                | [changes](/reference/api/engine/version-history/#v123-api-changes) |
+| 1.10           | 1.22                | 1.12                | [changes](/reference/api/engine/version-history/#v122-api-changes) |
+| 1.9            | 1.21                | 1.12                | [changes](/reference/api/engine/version-history/#v121-api-changes) |
+| 1.8            | 1.20                | 1.12                | [changes](/reference/api/engine/version-history/#v120-api-changes) |
+| 1.7            | 1.19                | 1.0                 | [changes](/reference/api/engine/version-history/#v119-api-changes) |
+| 1.6            | 1.18                | 1.0                 | [changes](/reference/api/engine/version-history/#v118-api-changes) |
+| 1.5            | 1.17                | 1.0                 | [changes](/reference/api/engine/version-history/#v117-api-changes) |
+| 1.4            | 1.16                | 1.0                 | [changes](/reference/api/engine/version-history/#v116-api-changes) |
+| 1.3            | 1.15                | 1.0                 | [changes](/reference/api/engine/version-history/#v115-api-changes) |
+| 1.2            | 1.14                | 1.0                 | [changes](/reference/api/engine/version-history/#v114-api-changes) |
+| 1.1            | 1.13                | 1.0                 | [changes](/reference/api/engine/version-history/#v113-api-changes) |
+| 1.0            | 1.12                | 1.0                 | [changes](/reference/api/engine/version-history/#v112-api-changes) |
+| 0.12           | 1.12                | 1.0                 | [changes](/reference/api/engine/version-history/#v112-api-changes) |
+| 0.11           | 1.11                | 1.0                 | [changes](/reference/api/engine/version-history/#v111-api-changes) |
+| 0.10           | 1.10                | 1.0                 | [changes](/reference/api/engine/version-history/#v110-api-changes) |
+| 0.9            | 1.10                | 1.0                 | [changes](/reference/api/engine/version-history/#v110-api-changes) |
+| 0.8            | 1.9                 | 1.0                 | [changes](/reference/api/engine/version-history/#v19-api-changes)  |
+| 0.7.1          | 1.8                 | 1.0                 | [changes](/reference/api/engine/version-history/#v18-api-changes)  |
+| 0.7            | 1.7                 | 1.0                 | [changes](/reference/api/engine/version-history/#v17-api-changes)  |
+| 0.6.4          | 1.6                 | 1.0                 | [changes](/reference/api/engine/version-history/#v16-api-changes)  |
+| 0.6.2          | 1.5                 | 1.0                 | [changes](/reference/api/engine/version-history/#v15-api-changes)  |
+| 0.6            | 1.4                 | 1.0                 | [changes](/reference/api/engine/version-history/#v14-api-changes)  |
+| 0.5            | 1.3                 | 1.0                 | [changes](/reference/api/engine/version-history/#v13-api-changes)  |
+| 0.4.1          | 1.2                 | 1.0                 | [changes](/reference/api/engine/version-history/#v12-api-changes)  |
+| 0.3.4          | 1.1                 | 1.0                 | [changes](/reference/api/engine/version-history/#v11-api-changes)  |
+| 0.3.3          | 1.0                 | 1.0                 | [changes](/reference/api/engine/version-history/#v10-api-changes)  |
+| 0.3.2          | -                   | -                   |                                                                    |
+| 0.2            | -                   | -                   |                                                                    |
+| 0.1            | -                   | -                   |                                                                    |
diff --git a/content/reference/api/engine/sdk/_index.md b/content/reference/api/engine/sdk/_index.md
index 902d8447aee5..183119b94977 100644
--- a/content/reference/api/engine/sdk/_index.md
+++ b/content/reference/api/engine/sdk/_index.md
@@ -26,31 +26,40 @@ installed and coexist together.
 ### Go SDK
 
 ```console
-$ go get github.com/docker/docker/client
+$ go get github.com/moby/moby/client
 ```
 
 The client requires a recent version of Go. Run `go version` and ensure that you're running a currently supported version of Go.
 
-
-For more information, see [Docker Engine Go SDK reference](https://godoc.org/github.com/docker/docker/client).
+For more information, see [Go client reference](https://pkg.go.dev/github.com/moby/moby/client).
 
 ### Python SDK
 
 - Recommended: Run `pip install docker`.
 
 - If you can't use `pip`:
-
   1.  [Download the package directly](https://pypi.python.org/pypi/docker/).
   2.  Extract it and change to the extracted directory.
   3.  Run `python setup.py install`.
 
 For more information, see [Docker Engine Python SDK reference](https://docker-py.readthedocs.io/).
 
+> [!NOTE]
+> Docker Desktop for Linux users
+>
+> Docker Desktop for Linux uses a per-user socket instead of the system-wide `/var/run/docker.sock`. To use Docker SDKs with Docker Desktop for Linux, set the `DOCKER_HOST` environment variable:
+>
+> ```bash
+> export DOCKER_HOST=unix://$HOME/.docker/desktop/docker.sock
+> ```
+>
+> For more details, see [the Linux FAQs](/manuals/desktop/troubleshoot-and-support/faqs/linuxfaqs.md#how-do-i-use-docker-sdks-with-docker-desktop-for-linux).
+
 ## View the API reference
 
 You can
 [view the reference for the latest version of the API](/reference/api/engine/latest/)
-or [choose a specific version](/reference/api/engine/version-history/).
+or [choose a specific version](/reference/api/engine/#api-version-matrix).
 
 ## Versioned API and SDK
 
@@ -84,53 +93,54 @@ import (
 	"io"
 	"os"
 
-	"github.com/docker/docker/api/types/container"
-        "github.com/docker/docker/api/types/image"
-	"github.com/docker/docker/client"
-	"github.com/docker/docker/pkg/stdcopy"
+	"github.com/moby/moby/api/pkg/stdcopy"
+	"github.com/moby/moby/api/types/container"
+	"github.com/moby/moby/client"
 )
 
 func main() {
-    ctx := context.Background()
-    cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
-    if err != nil {
-        panic(err)
-    }
-    defer cli.Close()
-
-    reader, err := cli.ImagePull(ctx, "docker.io/library/alpine", image.PullOptions{})
-    if err != nil {
-        panic(err)
-    }
-    io.Copy(os.Stdout, reader)
-
-    resp, err := cli.ContainerCreate(ctx, &container.Config{
-        Image: "alpine",
-        Cmd:   []string{"echo", "hello world"},
-    }, nil, nil, nil, "")
-    if err != nil {
-        panic(err)
-    }
-
-    if err := cli.ContainerStart(ctx, resp.ID, container.StartOptions{}); err != nil {
-        panic(err)
-    }
-
-    statusCh, errCh := cli.ContainerWait(ctx, resp.ID, container.WaitConditionNotRunning)
-    select {
-    case err := <-errCh:
-        if err != nil {
-            panic(err)
-        }
-    case <-statusCh:
-    }
-
-    out, err := cli.ContainerLogs(ctx, resp.ID, container.LogsOptions{ShowStdout: true})
-    if err != nil {
-        panic(err)
-    }
-
-    stdcopy.StdCopy(os.Stdout, os.Stderr, out)
+	ctx := context.Background()
+	apiClient, err := client.New(client.FromEnv)
+	if err != nil {
+		panic(err)
+	}
+	defer apiClient.Close()
+
+	reader, err := apiClient.ImagePull(ctx, "docker.io/library/alpine", client.ImagePullOptions{})
+	if err != nil {
+		panic(err)
+	}
+	io.Copy(os.Stdout, reader)
+
+	resp, err := apiClient.ContainerCreate(ctx, client.ContainerCreateOptions{
+		Image: "alpine",
+		Config: &container.Config{
+			Cmd: []string{"echo", "hello world"},
+		},
+	})
+	if err != nil {
+		panic(err)
+	}
+
+	if _, err := apiClient.ContainerStart(ctx, resp.ID, client.ContainerStartOptions{}); err != nil {
+		panic(err)
+	}
+
+	wait := apiClient.ContainerWait(ctx, resp.ID, client.ContainerWaitOptions{})
+	select {
+	case err := <-wait.Error:
+		if err != nil {
+			panic(err)
+		}
+	case <-wait.Result:
+	}
+
+	out, err := apiClient.ContainerLogs(ctx, resp.ID, client.ContainerLogsOptions{ShowStdout: true})
+	if err != nil {
+		panic(err)
+	}
+
+	stdcopy.StdCopy(os.Stdout, os.Stderr, out)
 }
 ```
 
@@ -184,31 +194,31 @@ There are a number of community supported libraries available for other
 languages. They haven't been tested by Docker, so if you run into any issues,
 file them with the library maintainers.
 
-| Language              | Library                                                                     |
-|:----------------------|:----------------------------------------------------------------------------|
-| C                     | [libdocker](https://github.com/danielsuo/libdocker)                         |
-| C#                    | [Docker.DotNet](https://github.com/ahmetalpbalkan/Docker.DotNet)            |
-| C++                   | [lasote/docker_client](https://github.com/lasote/docker_client)             |
-| Clojure               | [clj-docker-client](https://github.com/into-docker/clj-docker-client)       |
-| Clojure               | [contajners](https://github.com/lispyclouds/contajners)                     |
-| Dart                  | [bwu_docker](https://github.com/bwu-dart/bwu_docker)                        |
-| Erlang                | [erldocker](https://github.com/proger/erldocker)                            |
-| Gradle                | [gradle-docker-plugin](https://github.com/gesellix/gradle-docker-plugin)    |
-| Groovy                | [docker-client](https://github.com/gesellix/docker-client)                  |
-| Haskell               | [docker-hs](https://github.com/denibertovic/docker-hs)                      |
-| Java                  | [docker-client](https://github.com/spotify/docker-client)                   |
-| Java                  | [docker-java](https://github.com/docker-java/docker-java)                   |
-| Java                  | [docker-java-api](https://github.com/amihaiemil/docker-java-api)            |
-| Java                  | [jocker](https://github.com/ndeloof/jocker)                                 |
-| NodeJS                | [dockerode](https://github.com/apocas/dockerode)                            |
-| NodeJS                | [harbor-master](https://github.com/arhea/harbor-master)                     |
-| NodeJS                | [the-moby-effect](https://github.com/leonitousconforti/the-moby-effect)     |
-| Perl                  | [Eixo::Docker](https://github.com/alambike/eixo-docker)                     |
-| PHP                   | [Docker-PHP](https://github.com/docker-php/docker-php)                      |
-| Ruby                  | [docker-api](https://github.com/swipely/docker-api)                         |
-| Rust                  | [bollard](https://github.com/fussybeaver/bollard)                           |
-| Rust                  | [docker-rust](https://github.com/abh1nav/docker-rust)                       |
-| Rust                  | [shiplift](https://github.com/softprops/shiplift)                           |
-| Scala                 | [tugboat](https://github.com/softprops/tugboat)                             |
-| Scala                 | [reactive-docker](https://github.com/almoehi/reactive-docker)               |
-| Swift                 | [docker-client-swift](https://github.com/valeriomazzeo/docker-client-swift) |
+| Language | Library                                                                     |
+| :------- | :-------------------------------------------------------------------------- |
+| C        | [libdocker](https://github.com/danielsuo/libdocker)                         |
+| C#       | [Docker.DotNet](https://github.com/testcontainers/Docker.DotNet)            |
+| C++      | [lasote/docker_client](https://github.com/lasote/docker_client)             |
+| Clojure  | [clj-docker-client](https://github.com/into-docker/clj-docker-client)       |
+| Clojure  | [contajners](https://github.com/lispyclouds/contajners)                     |
+| Dart     | [bwu_docker](https://github.com/bwu-dart/bwu_docker)                        |
+| Erlang   | [erldocker](https://github.com/proger/erldocker)                            |
+| Gradle   | [gradle-docker-plugin](https://github.com/gesellix/gradle-docker-plugin)    |
+| Groovy   | [docker-client](https://github.com/gesellix/docker-client)                  |
+| Haskell  | [docker-hs](https://github.com/denibertovic/docker-hs)                      |
+| Java     | [docker-client](https://github.com/spotify/docker-client)                   |
+| Java     | [docker-java](https://github.com/docker-java/docker-java)                   |
+| Java     | [docker-java-api](https://github.com/amihaiemil/docker-java-api)            |
+| Java     | [jocker](https://github.com/ndeloof/jocker)                                 |
+| NodeJS   | [dockerode](https://github.com/apocas/dockerode)                            |
+| NodeJS   | [harbor-master](https://github.com/arhea/harbor-master)                     |
+| NodeJS   | [the-moby-effect](https://github.com/leonitousconforti/the-moby-effect)     |
+| Perl     | [Eixo::Docker](https://github.com/alambike/eixo-docker)                     |
+| PHP      | [Docker-PHP](https://github.com/docker-php/docker-php)                      |
+| Ruby     | [docker-api](https://github.com/swipely/docker-api)                         |
+| Rust     | [bollard](https://github.com/fussybeaver/bollard)                           |
+| Rust     | [docker-rust](https://github.com/abh1nav/docker-rust)                       |
+| Rust     | [shiplift](https://github.com/softprops/shiplift)                           |
+| Scala    | [tugboat](https://github.com/softprops/tugboat)                             |
+| Scala    | [reactive-docker](https://github.com/almoehi/reactive-docker)               |
+| Swift    | [docker-client-swift](https://github.com/valeriomazzeo/docker-client-swift) |
diff --git a/content/reference/api/engine/sdk/examples.md b/content/reference/api/engine/sdk/examples.md
index 366a9cbfc251..ec334af59ee3 100644
--- a/content/reference/api/engine/sdk/examples.md
+++ b/content/reference/api/engine/sdk/examples.md
@@ -39,25 +39,25 @@ package main
 import (
 	"context"
 	"io"
+	"log"
 	"os"
 
-	"github.com/docker/docker/api/types/container"
-	"github.com/docker/docker/api/types/image"
-	"github.com/docker/docker/client"
-	"github.com/docker/docker/pkg/stdcopy"
+	"github.com/moby/moby/api/pkg/stdcopy"
+	"github.com/moby/moby/api/types/container"
+	"github.com/moby/moby/client"
 )
 
 func main() {
 	ctx := context.Background()
-	cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
+	apiClient, err := client.New(client.FromEnv, client.WithUserAgent("my-application/1.0.0"))
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-	defer cli.Close()
+	defer apiClient.Close()
 
-	reader, err := cli.ImagePull(ctx, "docker.io/library/alpine", image.PullOptions{})
+	reader, err := apiClient.ImagePull(ctx, "docker.io/library/alpine", client.ImagePullOptions{})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
 
 	defer reader.Close()
@@ -66,31 +66,33 @@ func main() {
 	// If stdout is not required, consider using io.Discard instead of os.Stdout.
 	io.Copy(os.Stdout, reader)
 
-	resp, err := cli.ContainerCreate(ctx, &container.Config{
+	resp, err := apiClient.ContainerCreate(ctx, client.ContainerCreateOptions{
+		Config: &container.Config{
+			Cmd: []string{"echo", "hello world"},
+			Tty: false,
+		},
 		Image: "alpine",
-		Cmd:   []string{"echo", "hello world"},
-		Tty:   false,
-	}, nil, nil, nil, "")
+	})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
 
-	if err := cli.ContainerStart(ctx, resp.ID, container.StartOptions{}); err != nil {
-		panic(err)
+	if _, err := apiClient.ContainerStart(ctx, resp.ID, client.ContainerStartOptions{}); err != nil {
+		log.Fatal(err)
 	}
 
-	statusCh, errCh := cli.ContainerWait(ctx, resp.ID, container.WaitConditionNotRunning)
+	wait := apiClient.ContainerWait(ctx, resp.ID, client.ContainerWaitOptions{})
 	select {
-	case err := <-errCh:
+	case err := <-wait.Error:
 		if err != nil {
-			panic(err)
+			log.Fatal(err)
 		}
-	case <-statusCh:
+	case <-wait.Result:
 	}
 
-	out, err := cli.ContainerLogs(ctx, resp.ID, container.LogsOptions{ShowStdout: true})
+	out, err := apiClient.ContainerLogs(ctx, resp.ID, client.ContainerLogsOptions{ShowStdout: true})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
 
 	stdcopy.StdCopy(os.Stdout, os.Stderr, out)
@@ -154,39 +156,39 @@ import (
 	"context"
 	"fmt"
 	"io"
+	"log"
 	"os"
 
-	"github.com/docker/docker/api/types/container"
-	"github.com/docker/docker/api/types/image"
-	"github.com/docker/docker/client"
+	"github.com/moby/moby/client"
 )
 
 func main() {
 	ctx := context.Background()
-	cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
+	apiClient, err := client.New(client.FromEnv, client.WithUserAgent("my-application/1.0.0"))
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-	defer cli.Close()
+	defer apiClient.Close()
 
 	imageName := "bfirsh/reticulate-splines"
 
-	out, err := cli.ImagePull(ctx, imageName, image.PullOptions{})
+	out, err := apiClient.ImagePull(ctx, imageName, client.ImagePullOptions{})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
 	defer out.Close()
+
 	io.Copy(os.Stdout, out)
 
-	resp, err := cli.ContainerCreate(ctx, &container.Config{
+	resp, err := apiClient.ContainerCreate(ctx, client.ContainerCreateOptions{
 		Image: imageName,
-	}, nil, nil, nil, "")
+	})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
 
-	if err := cli.ContainerStart(ctx, resp.ID, container.StartOptions{}); err != nil {
-		panic(err)
+	if _, err := apiClient.ContainerStart(ctx, resp.ID, client.ContainerStartOptions{}); err != nil {
+		log.Fatal(err)
 	}
 
 	fmt.Println(resp.ID)
@@ -232,25 +234,25 @@ package main
 import (
 	"context"
 	"fmt"
+	"log"
 
-	containertypes "github.com/docker/docker/api/types/container"
-	"github.com/docker/docker/client"
+	"github.com/moby/moby/client"
 )
 
 func main() {
 	ctx := context.Background()
-	cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
+	apiClient, err := client.New(client.FromEnv, client.WithUserAgent("my-application/1.0.0"))
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-	defer cli.Close()
+	defer apiClient.Close()
 
-	containers, err := cli.ContainerList(ctx, containertypes.ListOptions{})
+	containers, err := apiClient.ContainerList(ctx, client.ContainerListOptions{})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
 
-	for _, container := range containers {
+	for _, container := range containers.Items {
 		fmt.Println(container.ID)
 	}
 }
@@ -302,29 +304,29 @@ package main
 import (
 	"context"
 	"fmt"
+	"log"
 
-	containertypes "github.com/docker/docker/api/types/container"
-	"github.com/docker/docker/client"
+	"github.com/moby/moby/client"
 )
 
 func main() {
 	ctx := context.Background()
-	cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
+	apiClient, err := client.New(client.FromEnv, client.WithUserAgent("my-application/1.0.0"))
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-	defer cli.Close()
+	defer apiClient.Close()
 
-	containers, err := cli.ContainerList(ctx, containertypes.ListOptions{})
+	containers, err := apiClient.ContainerList(ctx, client.ContainerListOptions{})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
 
-	for _, container := range containers {
+	for _, container := range containers.Items {
 		fmt.Print("Stopping container ", container.ID[:10], "... ")
 		noWaitTimeout := 0 // to not wait for the container to exit gracefully
-		if err := cli.ContainerStop(ctx, container.ID, containertypes.StopOptions{Timeout: &noWaitTimeout}); err != nil {
-			panic(err)
+		if _, err := apiClient.ContainerStop(ctx, container.ID, client.ContainerStopOptions{Timeout: &noWaitTimeout}); err != nil {
+			log.Fatal(err)
 		}
 		fmt.Println("Success")
 	}
@@ -375,25 +377,25 @@ package main
 import (
 	"context"
 	"io"
+	"log"
 	"os"
 
-	"github.com/docker/docker/api/types/container"
-	"github.com/docker/docker/client"
+	"github.com/moby/moby/client"
 )
 
 func main() {
 	ctx := context.Background()
-	cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
+	apiClient, err := client.New(client.FromEnv, client.WithUserAgent("my-application/1.0.0"))
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-	defer cli.Close()
+	defer apiClient.Close()
 
-	options := container.LogsOptions{ShowStdout: true}
+	options := client.ContainerLogsOptions{ShowStdout: true}
 	// Replace this ID with a container that really exists
-	out, err := cli.ContainerLogs(ctx, "f1064a8a4c82", options)
+	out, err := apiClient.ContainerLogs(ctx, "f1064a8a4c82", options)
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
 
 	io.Copy(os.Stdout, out)
@@ -438,25 +440,25 @@ package main
 import (
 	"context"
 	"fmt"
+	"log"
 
-	"github.com/docker/docker/api/types/image"
-	"github.com/docker/docker/client"
+	"github.com/moby/moby/client"
 )
 
 func main() {
 	ctx := context.Background()
-	cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
+	apiClient, err := client.New(client.FromEnv, client.WithUserAgent("my-application/1.0.0"))
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-	defer cli.Close()
+	defer apiClient.Close()
 
-	images, err := cli.ImageList(ctx, image.ListOptions{})
+	images, err := apiClient.ImageList(ctx, client.ImageListOptions{})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
 
-	for _, image := range images {
+	for _, image := range images.Items {
 		fmt.Println(image.ID)
 	}
 }
@@ -500,25 +502,24 @@ package main
 import (
 	"context"
 	"io"
+	"log"
 	"os"
 
-	"github.com/docker/docker/api/types/image"
-	"github.com/docker/docker/client"
+	"github.com/moby/moby/client"
 )
 
 func main() {
 	ctx := context.Background()
-	cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
+	apiClient, err := client.New(client.FromEnv, client.WithUserAgent("my-application/1.0.0"))
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-	defer cli.Close()
+	defer apiClient.Close()
 
-	out, err := cli.ImagePull(ctx, "alpine", image.PullOptions{})
+	out, err := apiClient.ImagePull(ctx, "alpine", client.ImagePullOptions{})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-
 	defer out.Close()
 
 	io.Copy(os.Stdout, out)
@@ -567,40 +568,37 @@ package main
 
 import (
 	"context"
-	"encoding/base64"
-	"encoding/json"
 	"io"
+	"log"
 	"os"
 
-	"github.com/docker/docker/api/types/image"
-	"github.com/docker/docker/api/types/registry"
-	"github.com/docker/docker/client"
+	"github.com/moby/moby/api/pkg/authconfig"
+	"github.com/moby/moby/api/types/registry"
+	"github.com/moby/moby/client"
 )
 
 func main() {
 	ctx := context.Background()
-	cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
+	apiClient, err := client.New(client.FromEnv, client.WithUserAgent("my-application/1.0.0"))
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-	defer cli.Close()
+	defer apiClient.Close()
 
-	authConfig := registry.AuthConfig{
+	authStr, err := authconfig.Encode(registry.AuthConfig{
 		Username: "username",
 		Password: "password",
-	}
-	encodedJSON, err := json.Marshal(authConfig)
+	})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-	authStr := base64.URLEncoding.EncodeToString(encodedJSON)
 
-	out, err := cli.ImagePull(ctx, "alpine", image.PullOptions{RegistryAuth: authStr})
+	out, err := apiClient.ImagePull(ctx, "alpine", client.ImagePullOptions{RegistryAuth: authStr})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-
 	defer out.Close()
+
 	io.Copy(os.Stdout, out)
 }
 ```
@@ -659,43 +657,46 @@ package main
 import (
 	"context"
 	"fmt"
+	"log"
 
-	"github.com/docker/docker/api/types/container"
-	"github.com/docker/docker/client"
+	"github.com/moby/moby/api/types/container"
+	"github.com/moby/moby/client"
 )
 
 func main() {
 	ctx := context.Background()
-	cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
+	apiClient, err := client.New(client.FromEnv, client.WithUserAgent("my-application/1.0.0"))
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
-	defer cli.Close()
+	defer apiClient.Close()
 
-	createResp, err := cli.ContainerCreate(ctx, &container.Config{
+	createResp, err := apiClient.ContainerCreate(ctx, client.ContainerCreateOptions{
+		Config: &container.Config{
+			Cmd: []string{"touch", "/helloworld"},
+		},
 		Image: "alpine",
-		Cmd:   []string{"touch", "/helloworld"},
-	}, nil, nil, nil, "")
+	})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
 
-	if err := cli.ContainerStart(ctx, createResp.ID, container.StartOptions{}); err != nil {
-		panic(err)
+	if _, err := apiClient.ContainerStart(ctx, createResp.ID, client.ContainerStartOptions{}); err != nil {
+		log.Fatal(err)
 	}
 
-	statusCh, errCh := cli.ContainerWait(ctx, createResp.ID, container.WaitConditionNotRunning)
+	wait := apiClient.ContainerWait(ctx, createResp.ID, client.ContainerWaitOptions{})
 	select {
-	case err := <-errCh:
+	case err := <-wait.Error:
 		if err != nil {
-			panic(err)
+			log.Fatal(err)
 		}
-	case <-statusCh:
+	case <-wait.Result:
 	}
 
-	commitResp, err := cli.ContainerCommit(ctx, createResp.ID, container.CommitOptions{Reference: "helloworld"})
+	commitResp, err := apiClient.ContainerCommit(ctx, createResp.ID, client.ContainerCommitOptions{Reference: "helloworld"})
 	if err != nil {
-		panic(err)
+		log.Fatal(err)
 	}
 
 	fmt.Println(commitResp.ID)
diff --git a/content/reference/api/engine/version/_index.md b/content/reference/api/engine/version/_index.md
index e4e7ebd82467..b32c67b24e55 100644
--- a/content/reference/api/engine/version/_index.md
+++ b/content/reference/api/engine/version/_index.md
@@ -5,10 +5,10 @@ build:
 sidebar:
   reverse: true
 cascade:
-  - _target:
+  - target:
       path: /reference/api/engine/version/v1.24
     layout: default
-  - _target:
+  - target:
       path: /reference/api/engine/version/**
     description: Reference documentation and Swagger (OpenAPI) specification for the Docker Engine API.
     layout: api
diff --git a/content/reference/api/engine/version/v1.25.md b/content/reference/api/engine/version/v1.25.md
deleted file mode 100644
index df231bd2732b..000000000000
--- a/content/reference/api/engine/version/v1.25.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: Docker Engine API v1.25 reference
-linkTitle: v1.25
-aliases:
-- /engine/api/v1.25/
----
diff --git a/content/reference/api/engine/version/v1.26.md b/content/reference/api/engine/version/v1.26.md
deleted file mode 100644
index a6d9f65fd374..000000000000
--- a/content/reference/api/engine/version/v1.26.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.26
-title: Docker Engine API v1.26 reference
-aliases:
-- /engine/api/v1.26/
----
diff --git a/content/reference/api/engine/version/v1.27.md b/content/reference/api/engine/version/v1.27.md
deleted file mode 100644
index 787d4248caab..000000000000
--- a/content/reference/api/engine/version/v1.27.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.27
-title: Docker Engine API v1.27 reference
-aliases:
-- /engine/api/v1.27/
----
diff --git a/content/reference/api/engine/version/v1.28.md b/content/reference/api/engine/version/v1.28.md
deleted file mode 100644
index 83370e18a077..000000000000
--- a/content/reference/api/engine/version/v1.28.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.28
-title: Docker Engine API v1.28 reference
-aliases:
-- /engine/api/v1.28/
----
diff --git a/content/reference/api/engine/version/v1.29.md b/content/reference/api/engine/version/v1.29.md
deleted file mode 100644
index 9ea6a23017d5..000000000000
--- a/content/reference/api/engine/version/v1.29.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.29
-title: Docker Engine API v1.29 reference
-aliases:
-  - /engine/api/v1.29/
----
diff --git a/content/reference/api/engine/version/v1.30.md b/content/reference/api/engine/version/v1.30.md
deleted file mode 100644
index 8a3985bf89d9..000000000000
--- a/content/reference/api/engine/version/v1.30.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.30
-title: Docker Engine API v1.30 reference
-aliases:
-  - /engine/api/v1.30/
----
diff --git a/content/reference/api/engine/version/v1.31.md b/content/reference/api/engine/version/v1.31.md
deleted file mode 100644
index c12fd9706949..000000000000
--- a/content/reference/api/engine/version/v1.31.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.31
-title: Docker Engine API v1.31 reference
-aliases:
-  - /engine/api/v1.31/
----
diff --git a/content/reference/api/engine/version/v1.32.md b/content/reference/api/engine/version/v1.32.md
deleted file mode 100644
index bbd5cce05875..000000000000
--- a/content/reference/api/engine/version/v1.32.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.32
-title: Docker Engine API v1.32 reference
-aliases:
-  - /engine/api/v1.32/
----
diff --git a/content/reference/api/engine/version/v1.33.md b/content/reference/api/engine/version/v1.33.md
deleted file mode 100644
index 515ffca7ca61..000000000000
--- a/content/reference/api/engine/version/v1.33.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.33
-title: Docker Engine API v1.33 reference
-aliases:
-  - /engine/api/v1.33/
----
diff --git a/content/reference/api/engine/version/v1.34.md b/content/reference/api/engine/version/v1.34.md
deleted file mode 100644
index b2fb6e96f6ad..000000000000
--- a/content/reference/api/engine/version/v1.34.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.34
-title: Docker Engine API v1.34 reference
-aliases:
-  - /engine/api/v1.34/
----
diff --git a/content/reference/api/engine/version/v1.35.md b/content/reference/api/engine/version/v1.35.md
deleted file mode 100644
index 521e6fb8977e..000000000000
--- a/content/reference/api/engine/version/v1.35.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.35
-title: Docker Engine API v1.35 reference
-aliases:
-  - /engine/api/v1.35/
----
diff --git a/content/reference/api/engine/version/v1.36.md b/content/reference/api/engine/version/v1.36.md
deleted file mode 100644
index 712265a9b880..000000000000
--- a/content/reference/api/engine/version/v1.36.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.36
-title: Docker Engine API v1.36 reference
-aliases:
-  - /engine/api/v1.36/
----
diff --git a/content/reference/api/engine/version/v1.37.md b/content/reference/api/engine/version/v1.37.md
deleted file mode 100644
index 2fc4ecc3dce5..000000000000
--- a/content/reference/api/engine/version/v1.37.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.37
-title: Docker Engine API v1.37 reference
-aliases:
-  - /engine/api/v1.37/
----
diff --git a/content/reference/api/engine/version/v1.38.md b/content/reference/api/engine/version/v1.38.md
deleted file mode 100644
index dcc3f0fab28a..000000000000
--- a/content/reference/api/engine/version/v1.38.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.38
-title: Docker Engine API v1.38 reference
-aliases:
-  - /engine/api/v1.38/
----
diff --git a/content/reference/api/engine/version/v1.39.md b/content/reference/api/engine/version/v1.39.md
deleted file mode 100644
index 7cb3cba4f4f1..000000000000
--- a/content/reference/api/engine/version/v1.39.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-linkTitle: v1.39
-title: Docker Engine API v1.39 reference
-aliases:
-  - /engine/api/v1.39/
----
diff --git a/content/reference/api/engine/version/v1.49.md b/content/reference/api/engine/version/v1.49.md
index 394722071d33..ba8a5007cf5c 100644
--- a/content/reference/api/engine/version/v1.49.md
+++ b/content/reference/api/engine/version/v1.49.md
@@ -3,6 +3,4 @@ linkTitle: v1.49
 title: Docker Engine API v1.49 reference
 aliases:
   - /engine/api/v1.49/
-  - /engine/api/latest/
-  - /reference/api/engine/latest/
 ---
diff --git a/content/reference/api/engine/version/v1.50.md b/content/reference/api/engine/version/v1.50.md
new file mode 100644
index 000000000000..eb6246ccb9b5
--- /dev/null
+++ b/content/reference/api/engine/version/v1.50.md
@@ -0,0 +1,6 @@
+---
+linkTitle: v1.50
+title: Docker Engine API v1.50 reference
+aliases:
+  - /engine/api/v1.50/
+---
diff --git a/content/reference/api/engine/version/v1.51.md b/content/reference/api/engine/version/v1.51.md
new file mode 100644
index 000000000000..4a49a179f9f7
--- /dev/null
+++ b/content/reference/api/engine/version/v1.51.md
@@ -0,0 +1,6 @@
+---
+linkTitle: v1.51
+title: Docker Engine API v1.51 reference
+aliases:
+  - /engine/api/v1.51/
+---
diff --git a/content/reference/api/engine/version/v1.52.md b/content/reference/api/engine/version/v1.52.md
new file mode 100644
index 000000000000..70aaeb88831b
--- /dev/null
+++ b/content/reference/api/engine/version/v1.52.md
@@ -0,0 +1,4 @@
+---
+linkTitle: v1.52
+title: Docker Engine API v1.52 reference
+---
diff --git a/content/reference/api/engine/version/v1.53.md b/content/reference/api/engine/version/v1.53.md
new file mode 100644
index 000000000000..8aeb763e58bd
--- /dev/null
+++ b/content/reference/api/engine/version/v1.53.md
@@ -0,0 +1,4 @@
+---
+linkTitle: v1.53
+title: Docker Engine API v1.53 reference
+---
diff --git a/content/reference/api/engine/version/v1.54.md b/content/reference/api/engine/version/v1.54.md
new file mode 100644
index 000000000000..ae3eca37cc08
--- /dev/null
+++ b/content/reference/api/engine/version/v1.54.md
@@ -0,0 +1,4 @@
+---
+linkTitle: v1.54
+title: Docker Engine API v1.54 reference
+---
diff --git a/content/reference/api/engine/version/v1.55.md b/content/reference/api/engine/version/v1.55.md
new file mode 100644
index 000000000000..6f9db0671027
--- /dev/null
+++ b/content/reference/api/engine/version/v1.55.md
@@ -0,0 +1,7 @@
+---
+linkTitle: v1.55
+title: Docker Engine API v1.55 reference
+aliases:
+  - /engine/api/latest/
+  - /reference/api/engine/latest/
+---
diff --git a/content/reference/api/extensions-sdk/Docker.md b/content/reference/api/extensions-sdk/Docker.md
index 3a21f8ddeaf2..a5f2e2d32847 100644
--- a/content/reference/api/extensions-sdk/Docker.md
+++ b/content/reference/api/extensions-sdk/Docker.md
@@ -86,7 +86,7 @@ const containers = await ddClient.docker.listContainers();
 
 | Name | Type | Description |
 | :------ | :------ | :------ |
-| `options?` | `any` | (Optional). A JSON like `{ "all": true, "limit": 10, "size": true, "filters": JSON.stringify({ status: ["exited"] }), }` For more information about the different properties see [the Docker API endpoint documentation](https://docs.docker.com/engine/api/v1.41/#operation/ContainerList). |
+| `options?` | `any` | (Optional). A JSON like `{ "all": true, "limit": 10, "size": true, "filters": JSON.stringify({ status: ["exited"] }), }` For more information about the different properties see [the Docker API endpoint documentation](https://docs.docker.com/reference/api/engine/version/v1.52/#operation/ContainerList). |
 
 #### Returns
 
@@ -108,7 +108,7 @@ const images = await ddClient.docker.listImages();
 
 | Name | Type | Description |
 | :------ | :------ | :------ |
-| `options?` | `any` | (Optional). A JSON like `{ "all": true, "filters": JSON.stringify({ dangling: ["true"] }), "digests": true * }` For more information about the different properties see [the Docker API endpoint documentation](https://docs.docker.com/engine/api/v1.41/#tag/Image). |
+| `options?` | `any` | (Optional). A JSON like `{ "all": true, "filters": JSON.stringify({ dangling: ["true"] }), "digests": true * }` For more information about the different properties see [the Docker API endpoint documentation](https://docs.docker.com/reference/api/engine/version/v1.52/#tag/Image). |
 
 #### Returns
 
diff --git a/content/reference/api/extensions-sdk/DockerDesktopClient.md b/content/reference/api/extensions-sdk/DockerDesktopClient.md
index 9ab538f8f2f8..f27617819792 100644
--- a/content/reference/api/extensions-sdk/DockerDesktopClient.md
+++ b/content/reference/api/extensions-sdk/DockerDesktopClient.md
@@ -96,7 +96,7 @@ const containers = await window.ddClient.listContainers();
 
 | Name | Type | Description |
 | :------ | :------ | :------ |
-| `options` | `never` | (Optional). A JSON like `{ "all": true, "limit": 10, "size": true, "filters": JSON.stringify({ status: ["exited"] }), }` For more information about the different properties see [the Docker API endpoint documentation](https://docs.docker.com/engine/api/v1.41/#operation/ContainerList). |
+| `options` | `never` | (Optional). A JSON like `{ "all": true, "limit": 10, "size": true, "filters": JSON.stringify({ status: ["exited"] }), }` For more information about the different properties see [the Docker API endpoint documentation](https://docs.docker.com/reference/api/engine/version/v1.52/#operation/ContainerList). |
 
 #### Returns
 
@@ -128,7 +128,7 @@ const images = await window.ddClient.listImages();
 
 | Name | Type | Description |
 | :------ | :------ | :------ |
-| `options` | `never` | (Optional). A JSON like `{ "all": true, "filters": JSON.stringify({ dangling: ["true"] }), "digests": true }` For more information about the different properties see [the Docker API endpoint documentation](https://docs.docker.com/engine/api/v1.41/#tag/Image). |
+| `options` | `never` | (Optional). A JSON like `{ "all": true, "filters": JSON.stringify({ dangling: ["true"] }), "digests": true }` For more information about the different properties see [the Docker API endpoint documentation](https://docs.docker.com/reference/api/engine/version/v1.52/#tag/Image). |
 
 #### Returns
 
@@ -401,37 +401,13 @@ DockerDesktopClientV0.navigateToVolume
 
 ___
 
-### navigateToDevEnvironments
-
-▸ **navigateToDevEnvironments**(): `void`
-
-Navigate to the Dev Environments window in Docker Desktop.
-
-```typescript
-window.ddClient.navigateToDevEnvironments();
-```
-
-> [!WARNING]
->
-> It will be removed in a future version. Use [viewDevEnvironments](NavigationIntents.md#viewdevenvironments) instead.
-
-#### Returns
-
-`void`
-
-#### Inherited from
-
-DockerDesktopClientV0.navigateToDevEnvironments
-
-___
-
 ## Other Methods
 
 ### execHostCmd
 
 ▸ **execHostCmd**(`cmd`): `Promise`<[`ExecResultV0`](ExecResultV0.md)\>
 
-You can run binaries defined in the host section in the extension metadata.
+Invoke a binary on the host. The binary is typically shipped with your extension using the host section in the extension metadata. Note that extensions run with user access rights, this API is not restricted to binaries listed in the host section of the extension metadata (some extensions might install software during user interaction, and invoke newly installed binaries even if not listed in the extension metadata) 
 
 ```typescript
 window.ddClient.execHostCmd(`cliShippedOnHost xxx`).then((cmdResult: any) => {
diff --git a/content/reference/api/extensions-sdk/NavigationIntents.md b/content/reference/api/extensions-sdk/NavigationIntents.md
index 6868a8c8d9dc..743b78462110 100644
--- a/content/reference/api/extensions-sdk/NavigationIntents.md
+++ b/content/reference/api/extensions-sdk/NavigationIntents.md
@@ -197,24 +197,6 @@ A promise that fails if the image doesn't exist.
 
 ___
 
-## Other Methods
-
-### viewDevEnvironments
-
-▸ **viewDevEnvironments**(): `Promise`<`void`\>
-
-Navigate to the Dev Environments window in Docker Desktop.
-
-```typescript
-ddClient.desktopUI.navigate.viewDevEnvironments()
-```
-
-#### Returns
-
-`Promise`<`void`\>
-
-___
-
 ## Volume Methods
 
 ### viewVolumes
diff --git a/content/reference/api/hub/changelog.md b/content/reference/api/hub/changelog.md
new file mode 100644
index 000000000000..4ace5936cf61
--- /dev/null
+++ b/content/reference/api/hub/changelog.md
@@ -0,0 +1,95 @@
+---
+description: Docker Hub API changelog
+title: Docker Hub API changelog
+linkTitle: Changelog
+keywords: docker hub, hub, whats new, release notes, api, changelog
+weight: 2
+toc_min: 1
+toc_max: 2
+aliases:
+  - /reference/api/hub/latest-changelog/
+---
+
+Here you can learn about the latest changes, new features, bug fixes, and known
+issues for Docker Service APIs.
+
+---
+
+## 2026-08-27
+
+### Updates
+
+- Document organization access token (OAT) support for
+  [repository management](/reference/api/hub/latest/#tag/repositories)
+  endpoints, the scope-dependent behavior of
+  [List repositories](/reference/api/hub/latest/#tag/repositories/operation/listNamespaceRepositories),
+  and legacy paths that are OAT unsupported.
+
+---
+
+## 2025-11-21
+
+### Updates
+
+- Add missing `expires_at` fields on [PAT management](/reference/api/hub/latest/#tag/access-tokens) endpoints.
+
+## 2025-09-25
+
+### Updates
+
+- Fix [Assign repository group](/reference/api/hub/latest/#tag/repositories/operation/CreateRepositoryGroup) endpoints request/response
+
+---
+
+## 2025-09-19
+
+### New
+
+- Add [Create repository](/reference/api/hub/latest/#tag/repositories/operation/CreateRepository) endpoints for a given `namespace`.
+- Add [Get repository](/reference/api/hub/latest/#tag/repositories/operation/GetRepository) endpoints for a given `namespace`.
+- Add [Check repository](/reference/api/hub/latest/#tag/repositories/operation/CheckRepository) endpoints for a given `namespace`.
+
+### Deprecations
+
+- [Deprecate POST /v2/repositories](/reference/api/hub/deprecated/#deprecate-legacy-createrepository)
+- [Deprecate POST /v2/repositories/{namespace}](/reference/api/hub/deprecated/#deprecate-legacy-createrepository)
+- [Deprecate GET /v2/repositories/{namespace}/{repository}](/reference/api/hub/deprecated/#deprecate-legacy-getrepository)
+- [Deprecate HEAD /v2/repositories/{namespace}/{repository}](/reference/api/hub/deprecated/#deprecate-legacy-getrepository)
+
+---
+
+## 2025-07-29
+
+### New
+
+- Add [Update repository immutable tags settings](/reference/api/hub/latest/#tag/repositories/operation/UpdateRepositoryImmutableTags) endpoints for a given `namespace` and `repository`.
+- Add [Verify repository immutable tags](/reference/api/hub/latest/#tag/repositories/operation/VerifyRepositoryImmutableTags) endpoints for a given `namespace` and `repository`.
+
+---
+
+## 2025-06-27
+
+### New
+
+- Add [List repositories](/reference/api/hub/latest/#tag/repositories/operation/listNamespaceRepositories) endpoints for a given `namespace`.
+
+### Deprecations
+
+- [Deprecate /v2/repositories/{namespace}](/reference/api/hub/deprecated/#deprecate-legacy-listnamespacerepositories)
+
+---
+
+## 2025-03-25
+
+### New
+
+- Add [APIs](/reference/api/hub/latest/#tag/org-access-tokens) for organization access token (OATs) management.
+
+---
+
+## 2025-03-18
+
+### New
+
+- Add access to [audit logs](/reference/api/hub/latest/#tag/audit-logs) for org
+  access tokens.
diff --git a/content/reference/api/hub/deprecated.md b/content/reference/api/hub/deprecated.md
index cd32c0d2c049..a803afb1d6f9 100644
--- a/content/reference/api/hub/deprecated.md
+++ b/content/reference/api/hub/deprecated.md
@@ -1,15 +1,64 @@
 ---
-description: Docker Hub API v1 (deprecated)
-keywords: kitematic, deprecated
-title: Docker Hub API v1 (deprecated)
+description: Deprecated Docker Hub API endpoints
+keywords: deprecated
+title: Deprecated Docker Hub API endpoints
+linkTitle: Deprecated
 weight: 3
 aliases:
-  - /docker-hub/api/deprecated/
+    - /docker-hub/api/deprecated/
 ---
 
-> **Deprecated**
->
-> Docker Hub API v1 has been deprecated. Please use Docker Hub API v2 instead.
+This page provides an overview of endpoints that are deprecated in Docker Hub API.
+
+## Endpoint deprecation policy
+
+As changes are made to Docker there may be times when existing endpoints need to be removed or replaced with newer endpoints. Before an existing endpoint is removed it is labeled as "deprecated" within the documentation. After some time it may be removed.
+
+## Deprecated endpoints
+
+The following table provides an overview of the current status of deprecated endpoints:
+
+**Deprecated**: the endpoint is marked "deprecated" and should no longer be used.
+
+The endpoint may be removed, disabled, or change behavior in a future release.
+
+**Removed**: the endpoint was removed, disabled, or hidden.
+
+---
+
+| Status     | Feature                                                                                              | Date       |
+|------------|------------------------------------------------------------------------------------------------------|------------|
+| Deprecated | [Deprecate undocumented create/get repository](#deprecate-legacy-createrepository-and-getrepository) | 2025-09-19 |
+| Deprecated | [Deprecate /v2/repositories/{namespace}](#deprecate-legacy-listnamespacerepositories)                | 2025-06-27 |
+|            | [Create deprecation log table](#create-deprecation-log-table)                                        | 2025-06-27 |
+| Removed    | [Docker Hub API v1 deprecation](#docker-hub-api-v1-deprecation)                                      | 2022-08-23 |
+
+---
+
+### Deprecate legacy CreateRepository and GetRepository
+
+Deprecate undocumented endpoints :
+- `POST /v2/repositories` and `POST /v2/repositories/{namespace}` replaced by [Create repository](/reference/api/hub/latest/#tag/repositories/operation/CreateRepository).
+- `GET /v2/repositories/{namespace}/{repository}` replaced by [Get repository](/reference/api/hub/latest/#tag/repositories/operation/GetRepository).
+- `HEAD /v2/repositories/{namespace}/{repository}` replaced by [Check repository](/reference/api/hub/latest/#tag/repositories/operation/CheckRepository).
+
+---
+
+### Deprecate legacy ListNamespaceRepositories
+
+Deprecate undocumented endpoint `GET /v2/repositories/{namespace}` replaced by [List repositories](/reference/api/hub/latest/#tag/repositories/operation/listNamespaceRepositories).
+
+---
+
+### Create deprecation log table
+
+Reformat page
+
+---
+
+### Docker Hub API v1 deprecation
+
+Docker Hub API v1 has been deprecated. Use Docker Hub API v2 instead.
 
 The following API routes within the v1 path will no longer work and will return a 410 status code:
 * `/v1/repositories/{name}/images`
@@ -21,11 +70,11 @@ The following API routes within the v1 path will no longer work and will return
 
 If you want to continue using the Docker Hub API in your current applications, update your clients to use v2 endpoints.
 
-| **OLD**                                                                                                                                                              | **NEW**                                                                                                                                                                                                              |
-|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [/v1/repositories/{name}/images](https://github.com/moby/moby/blob/v1.3.0/docs/sources/reference/api/docker-io_api.md#list-user-repository-images)                   | [/v2/namespaces/{namespace}/repositories/{repository}/images](/reference/api/hub/latest.md#tag/images/operation/GetNamespacesRepositoriesImages)                                                              |
-| [/v1/repositories/{namespace}/{name}/images](https://github.com/moby/moby/blob/v1.3.0/docs/sources/reference/api/docker-io_api.md#list-user-repository-images)       | [/v2/namespaces/{namespace}/repositories/{repository}/images](/reference/api/hub/latest.md#tag/images/operation/GetNamespacesRepositoriesImages)                                                              |
-| [/v1/repositories/{name}/tags](https://github.com/moby/moby/blob/v1.8.3/docs/reference/api/registry_api.md#list-repository-tags)                                     | [/v2/namespaces/{namespace}/repositories/{repository}/tags](/reference/api/hub/latest.md#tag/repositories/paths/~1v2~1namespaces~1%7Bnamespace%7D~1repositories~1%7Brepository%7D~1tags/get)                  |
-| [/v1/repositories/{namespace}/{name}/tags](https://github.com/moby/moby/blob/v1.8.3/docs/reference/api/registry_api.md#list-repository-tags)                         | [/v2/namespaces/{namespace}/repositories/{repository}/tags](/reference/api/hub/latest.md#tag/repositories/paths/~1v2~1namespaces~1%7Bnamespace%7D~1repositories~1%7Brepository%7D~1tags/get)                  |
-| [/v1/repositories/{namespace}/{name}/tags](https://github.com/moby/moby/blob/v1.8.3/docs/reference/api/registry_api.md#get-image-id-for-a-particular-tag)            | [/v2/namespaces/{namespace}/repositories/{repository}/tags/{tag}](/reference/api/hub/latest.md#tag/repositories/paths/~1v2~1namespaces~1%7Bnamespace%7D~1repositories~1%7Brepository%7D~1tags~1%7Btag%7D/get) |
-| [/v1/repositories/{namespace}/{name}/tags/{tag_name}](https://github.com/moby/moby/blob/v1.8.3/docs/reference/api/registry_api.md#get-image-id-for-a-particular-tag) | [/v2/namespaces/{namespace}/repositories/{repository}/tags/{tag}](/reference/api/hub/latest.md#tag/repositories/paths/~1v2~1namespaces~1%7Bnamespace%7D~1repositories~1%7Brepository%7D~1tags~1%7Btag%7D/get) |
+| **OLD**                                                                                                                                                              | **NEW**                                                                                                                                   |
+|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------|
+| [/v1/repositories/{name}/tags](https://github.com/moby/moby/blob/v1.8.3/docs/reference/api/registry_api.md#list-repository-tags)                                     | [/v2/namespaces/{namespace}/repositories/{repository}/tags](/reference/api/hub/latest/#tag/repositories/operation/ListRepositoryTags)     |
+| [/v1/repositories/{namespace}/{name}/tags](https://github.com/moby/moby/blob/v1.8.3/docs/reference/api/registry_api.md#list-repository-tags)                         | [/v2/namespaces/{namespace}/repositories/{repository}/tags](/reference/api/hub/latest.md/#tag/repositories/operation/ListRepositoryTags)  |
+| [/v1/repositories/{namespace}/{name}/tags](https://github.com/moby/moby/blob/v1.8.3/docs/reference/api/registry_api.md#get-image-id-for-a-particular-tag)            | [/v2/namespaces/{namespace}/repositories/{repository}/tags/{tag}](/reference/api/hub/latest/#tag/repositories/operation/GetRepositoryTag) |
+| [/v1/repositories/{namespace}/{name}/tags/{tag_name}](https://github.com/moby/moby/blob/v1.8.3/docs/reference/api/registry_api.md#get-image-id-for-a-particular-tag) | [/v2/namespaces/{namespace}/repositories/{repository}/tags/{tag}](/reference/api/hub/latest/#tag/repositories/operation/GetRepositoryTag) |
+
+---
\ No newline at end of file
diff --git a/content/reference/api/hub/dvp.md b/content/reference/api/hub/dvp.md
deleted file mode 100644
index c4cc61554cae..000000000000
--- a/content/reference/api/hub/dvp.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: api
-description: Reference documentation and Swagger (OpenAPI) specification for the Docker Verified Publisher API.
-linkTitle: DVP Data API
-title: Docker Verified Publisher API reference
-weight: 4
----
diff --git a/content/reference/api/hub/dvp.yaml b/content/reference/api/hub/dvp.yaml
index 8ff2030acab3..3a561a7be5c9 100644
--- a/content/reference/api/hub/dvp.yaml
+++ b/content/reference/api/hub/dvp.yaml
@@ -1,696 +1,5 @@
-openapi: 3.0.0
-info:
-  title: DVP Data API
-  version: 1.0.0
-  x-logo:
-    url: https://docs.docker.com/assets/images/logo-docker-main.png
-    href: /reference
-  description: |
-     The Docker DVP Data API allows [Docker Verified Publishers](https://docs.docker.com/docker-hub/publish/) to view image pull analytics data for their namespaces. Analytics data can be retrieved as raw data, or in a summary format.
-       
-     #### Summary data
-
-     In your summary data CSV, you will have access to the data points listed below. You can request summary data for a complete week (Monday through Sunday) or for a complete month (available on the first day of the following month). 
-
-     There are two levels of summary data:
-
-     - Repository-level, a summary of every namespace and repository
-     - Tag- or digest-level, a summary of every namespace, repository, and reference
-       (tag or digest)
-
-     The summary data formats contain the following data points:
-
-     - Unique IP address count
-     - Pulls by tag count
-     - Pulls by digest count
-     - Version check count
-
-     #### Raw data
-
-     In your raw data CSV you will have access to the data points listed below. You can request raw data for a complete week (Monday through Sunday) or for a complete month (available on the first day of the following month). **Note:** each action is represented as a single row.
-
-     - Type (industry)
-     - Host (cloud provider)
-     - Country (geolocation)
-     - Timestamp
-     - Namespace
-     - Repository
-     - Reference (digest is always included, tag is provided when available)
-     - HTTP request method
-     - Action, one of the following:
-       - Pull by tag
-       - Pull by digest
-       - Version check
-     - User-Agent
-
-servers:
-  - url: https://hub.docker.com/api/publisher/analytics/v1
-security:
-  - HubAuth: []
-
-features.openapi:
-  schemaDefinitionsTagName: Schemas
-
-tags:
-  - name: authentication
-    x-displayName: Authentication Endpoints
-  - name: namespaces
-    x-displayName: Namespace data
-  - name: discovery
-    x-displayName: Discovery
-  - name: responseDataFile
-    x-displayName: ResponseDataFile
-    description: |
-      <SchemaDefinition schemaRef="#/components/schemas/ResponseDataFile" />
-  - name: yearModel
-    x-displayName: Year Data Model
-    description: |
-      <SchemaDefinition schemaRef="#/components/schemas/YearModel" />
-  - name: monthModel
-    x-displayName: Month Data Model
-    description: |
-      <SchemaDefinition schemaRef="#/components/schemas/MonthModel" />
-  - name: weekModel
-    x-displayName: Week Data Model
-    description: |
-      <SchemaDefinition schemaRef="#/components/schemas/WeekModel" />
-
-x-tagGroups:
-  - name: API
-    tags:
-      - authentication
-      - discovery
-      - namespaces
-  - name: Models
-    tags:
-      - responseDataFile
-      - yearModel
-      - monthModel
-      - weekModel
-
-paths:
-  /v2/users/login:
-    security: []
-    servers:
-      - url: https://hub.docker.com
-    post:
-      security: []
-      tags:
-        - authentication
-      summary: Create an authentication token
-      operationId: PostUsersLogin
-      description: |
-        Creates and returns a bearer token in JWT format that you can use to
-        authenticate with Docker Hub APIs.
-
-        The returned token is used in the HTTP Authorization header like `Authorization: Bearer {TOKEN}`.
-
-        Most Docker Hub APIs require this token either to consume or to get detailed information. For example, to list images in a private repository.
-      requestBody:
-        content:
-          application/json:
-            schema:
-              $ref: "#/components/schemas/UsersLoginRequest"
-        description: Login details.
-        required: true
-      responses:
-        200:
-          description: Authentication successful
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/PostUsersLoginSuccessResponse"
-        401:
-          description: Authentication failed or second factor required
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/PostUsersLoginErrorResponse"
-  /v2/users/2fa-login:
-    security: []
-    servers:
-      - url: https://hub.docker.com
-    post:
-      security: []
-      tags:
-        - authentication
-      summary: Second factor authentication
-      operationId: PostUsers2FALogin
-      description: |
-        When a user has 2FA enabled, this is the second call to perform after
-        `/v2/users/login` call.
-
-        Creates and returns a bearer token in JWT format that you can use to authenticate with Docker Hub APIs.
-
-        The returned token is used in the HTTP Authorization header like `Authorization: Bearer {TOKEN}`.
-
-        Most Docker Hub APIs require this token either to consume or to get detailed information. For example, to list images in a private repository.
-      requestBody:
-        content:
-          application/json:
-            schema:
-              $ref: "#/components/schemas/Users2FALoginRequest"
-        description: Login details.
-        required: true
-      responses:
-        200:
-          description: Authentication successful
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/PostUsersLoginSuccessResponse"
-        401:
-          description: Authentication failed or second factor required
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/PostUsers2FALoginErrorResponse"
-
-
-  /:
-    get:
-      tags: [discovery]
-      summary: Get namespaces and repos
-      description: Gets a list of your namespaces and repos which have data available.
-      operationId: getNamespaces
-      responses:
-        '200':
-          description: Success
-          content:
-            application/json:
-              schema:
-                $ref: '#/components/schemas/NamespaceData'
-  /namespaces:
-    get:
-      tags: [discovery]
-      summary: Get user's namespaces
-      description: Get metadata associated with the namespaces the user has access to, including extra repos associated with the namespaces.
-      operationId: getUserNamespaces
-      responses:
-        '200':
-          description: Success
-          content:
-            application/json:
-              schema:
-                type: array
-                items:
-                  $ref: '#/components/schemas/NamespaceMetadata'
-        '401':
-          description: Authentication failed or second factor required
-  /namespaces/{namespace}:
-    get:
-      tags: [discovery]
-      summary: Get namespace
-      description: Gets metadata associated with specified namespace, including extra repos associated with the namespace.
-      operationId: getNamespace
-      parameters:
-        - in: path
-          name: namespace
-          schema:
-            type: string
-          required: true
-          description: Namespace to fetch data for
-      responses:
-        '200':
-          description: Success
-          content:
-            application/json:
-              schema:
-                $ref: '#/components/schemas/NamespaceMetadata'
-  /namespaces/{namespace}/pulls:
-    get:
-      tags: [namespaces]
-      summary: Get pull data
-      description: Gets pulls for the given namespace.
-      operationId: getNamespacePulls
-      parameters:
-        - in: path
-          name: namespace
-          schema:
-            type: string
-          required: true
-          description: Namespace to fetch data for
-        - in: query
-          name: timespan
-          schema:
-            $ref: '#/components/schemas/TimespanType'
-          required: false
-          description: Timespan type for fetching data
-        - in: query
-          name: period
-          schema:
-            $ref: '#/components/schemas/PeriodType'
-          required: false
-          description: Relative period of the period to fetch data
-        - in: query
-          name: group
-          schema:
-            $ref: '#/components/schemas/GroupType'
-          required: false
-          description: Field to group the data by
-      responses:
-        '200':
-          description: Success
-          content:
-            application/json:
-              schema:
-                $ref: '#/components/schemas/PullData'
-        '404':
-          description: Not found - namespace doesn't exist or user does not have permission to access it
-  /namespaces/{namespace}/repos/{repo}/pulls:
-    get:
-      tags: [namespaces]
-      summary: Get pull data
-      description: Gets pulls for the given repo.
-      operationId: getRepoPulls
-      parameters:
-        - in: path
-          name: namespace
-          schema:
-            type: string
-          required: true
-          description: Namespace to fetch data for
-        - in: path
-          name: repo
-          schema:
-            type: string
-          required: true
-          description: Repository to fetch data for
-        - in: query
-          name: timespan
-          schema:
-            $ref: '#/components/schemas/TimespanType'
-          required: false
-          description: Timespan type for fetching data
-        - in: query
-          name: period
-          schema:
-            $ref: '#/components/schemas/PeriodType'
-          required: false
-          description: Relative period of the period to fetch data
-        - in: query
-          name: group
-          schema:
-            $ref: '#/components/schemas/GroupType'
-          required: false
-          description: Field to group the data by
-      responses:
-        '200':
-          description: Success
-          content:
-            application/json:
-              schema:
-                $ref: '#/components/schemas/PullData'
-        '404':
-          description: Not found - repo doesn't exist or user does not have permission to access it
-  /namespaces/{namespace}/pulls/exports/years:
-    get:
-      tags: [namespaces]
-      summary: Get years with data
-      description: Gets a list of years that have data for the given namespace.
-      operationId: getNamespaceYears
-      parameters:
-        - in: path
-          name: namespace
-          schema:
-            type: string
-          required: true
-          description: Namespace to fetch data for
-      responses:
-        '200':
-          description: Success
-          content:
-            application/json:
-              schema:
-                $ref: '#/components/schemas/YearData'
-  /namespaces/{namespace}/pulls/exports/years/{year}/{timespantype}:
-    get:
-      tags: [namespaces]
-      summary: Get timespans with data
-      description: Gets a list of timespans of the given type that have data for the given namespace and year.
-      operationId: getNamespaceTimespans
-      parameters:
-        - in: path
-          name: namespace
-          schema:
-            type: string
-          required: true
-          description: Namespace to fetch data for
-        - in: path
-          name: year
-          schema:
-            type: integer
-          required: true
-          description: Year to fetch data for
-        - in: path
-          name: timespantype
-          schema:
-            $ref: '#/components/schemas/TimespanType'
-          required: true
-          description: Type of timespan to fetch data for
-      responses:
-        '200':
-          description: Success
-          content:
-            application/json:
-              schema:
-                $ref: '#/components/schemas/TimespanData'
-  /namespaces/{namespace}/pulls/exports/years/{year}/{timespantype}/{timespan}:
-    get:
-      tags: [namespaces]
-      summary: Get namespace metadata for timespan
-      description: Gets info about data for the given namespace and timespan.
-      operationId: getNamespaceTimespanMetadata
-      parameters:
-        - in: path
-          name: namespace
-          schema:
-            type: string
-          required: true
-          description: Namespace to fetch data for
-        - in: path
-          name: year
-          schema:
-            type: integer
-          required: true
-          description: Year to fetch data for
-        - in: path
-          name: timespantype
-          schema:
-            $ref: '#/components/schemas/TimespanType'
-          required: true
-          description: Type of timespan to fetch data for
-        - in: path
-          name: timespan
-          schema:
-            type: integer
-          required: true
-          description: Timespan to fetch data for
-      responses:
-        '200':
-          description: Success
-          content:
-            application/json:
-              schema:
-                $ref: '#/components/schemas/TimespanModel'
-        '404':
-          description: Not Found
-  /namespaces/{namespace}/pulls/exports/years/{year}/{timespantype}/{timespan}/{dataview}:
-    get:
-      tags: [namespaces]
-      summary: Get namespace data for timespan
-      description: Gets a list of URLs that can be used to download the pull data for the given namespace and timespan.
-      operationId: getNamespaceDataByTimespan
-      parameters:
-        - in: path
-          name: namespace
-          schema:
-            type: string
-          required: true
-          description: Namespace to fetch data for
-        - in: path
-          name: year
-          schema:
-            type: integer
-          required: true
-          description: Year to fetch data for
-        - in: path
-          name: timespantype
-          schema:
-            $ref: '#/components/schemas/TimespanType'
-          required: true
-          description: Type of timespan to fetch data for
-        - in: path
-          name: timespan
-          schema:
-            type: integer
-          required: true
-          description: Timespan to fetch data for
-        - in: path
-          name: dataview
-          schema:
-            $ref: '#/components/schemas/DataviewType'
-          required: true
-          description: Type of data to fetch
-      responses:
-        '200':
-          description: Success
-          content:
-            application/json:
-              schema:
-                $ref: '#/components/schemas/ResponseData'
-  /repos/pulls:
-    get:
-      tags: [namespaces]
-      summary: Get pull data for multiple repos
-      description: Gets pull for the given repos.
-      operationId: getManyReposPulls
-      parameters:
-        - in: query
-          name: repos
-          schema:
-            type: array
-            items:
-              type: string
-          required: true
-          description: Repositories to fetch data for (maximum of 50 repositories per request).
-        - in: query
-          name: timespan
-          schema:
-            $ref: '#/components/schemas/TimespanType'
-          required: false
-          description: Timespan type for fetching data
-        - in: query
-          name: period
-          schema:
-            $ref: '#/components/schemas/PeriodType'
-          required: false
-          description: Relative period of the period to fetch data
-        - in: query
-          name: group
-          schema:
-            $ref: '#/components/schemas/GroupType'
-          required: false
-          description: Field to group the data by
-      responses:
-        '200':
-          description: Success
-          content:
-            application/json:
-              schema:
-                $ref: '#/components/schemas/ReposPullData'
-
-components:
-  schemas:
-    UsersLoginRequest:
-      description: User login details
-      type: object
-      required:
-        - username
-        - password
-      properties:
-        username:
-          description: The username of the Docker Hub account to authenticate with.
-          type: string
-          example: myusername
-        password:
-          description:
-            The password or personal access token (PAT) of the Docker Hub
-            account to authenticate with.
-          type: string
-          example: hunter2
-    PostUsersLoginSuccessResponse:
-      description: successful user login response
-      type: object
-      properties:
-        token:
-          description: |
-            Created authentication token.
-
-            This token can be used in the HTTP Authorization header as a JWT to authenticate with the Docker Hub APIs.
-          type: string
-          example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
-          nullable: false
-    PostUsersLoginErrorResponse:
-      description: failed user login response or second factor required
-      type: object
-      required:
-        - detail
-      properties:
-        detail:
-          description: Description of the error.
-          type: string
-          example: Incorrect authentication credentials
-          nullable: false
-        login_2fa_token:
-          description:
-            Short-lived token to be used on `/v2/users/2fa-login` to
-            complete the authentication. This field is present only if 2FA is
-            enabled.
-          type: string
-          example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
-          nullable: true
-    Users2FALoginRequest:
-      description: Second factor user login details
-      type: object
-      required:
-        - login_2fa_token
-        - code
-      properties:
-        login_2fa_token:
-          description: The intermediate 2FA token returned from `/v2/users/login` API.
-          type: string
-          example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
-        code:
-          description:
-            The Time-based One-Time Password of the Docker Hub account to
-            authenticate with.
-          type: string
-          example: 123456
-    PostUsers2FALoginErrorResponse:
-      description: failed second factor login response.
-      type: object
-      properties:
-        detail:
-          description: Description of the error.
-          type: string
-          example: Incorrect authentication credentials
-          nullable: false
-
-    ResponseData:
-      properties:
-        data:
-          type: array
-          description: |
-            List of urls to download the data. When the data is large, the data will be split into multiple files.
-          items: 
-            $ref: '#/components/schemas/ResponseDataFile'
-    ResponseDataFile:
-      properties:
-        url:
-          type: string
-        size:
-          type: integer
-          format: int64
-    NamespaceData:
-      properties:
-        namespaces:
-          type: array
-          items:
-            type: string
-    NamespaceMetadata:
-      properties:
-        namespace:
-          type: string
-        extraRepos:
-          type: array
-          items:
-            type: string
-        datasets:
-          type: array
-          items:
-            $ref: '#/components/schemas/DatasetModel'
-    DatasetModel:
-      properties:
-        name:
-          $ref: '#/components/schemas/DatasetType'
-        views:
-          type: array
-          items:
-            $ref: '#/components/schemas/DataviewType'
-        timespans:
-          type: array
-          items:
-            $ref: '#/components/schemas/TimespanType'
-    PullData:
-      properties:
-        pulls:
-          type: array
-          items:
-            $ref: '#/components/schemas/PullModel'
-    ReposPullData:
-      properties:
-        repos:
-          type: object
-          additionalProperties:
-            $ref: '#/components/schemas/PullData'
-    PullModel:
-      properties:
-        start:
-          type: string
-        end:
-          type: string
-        repo:
-          type: string
-        namespace:
-          type: string
-        pullCount:
-          type: integer
-        ipCount:
-          type: integer
-        country:
-          type: string
-    
-    YearData:
-      properties:
-        years:
-          type: array
-          items:
-            $ref: '#/components/schemas/YearModel'
-    YearModel:
-      properties:
-        year:
-          type: integer
-    MonthData:
-      properties:
-        months:
-          type: array
-          items:
-            $ref: '#/components/schemas/MonthModel'
-    MonthModel:
-      properties:
-        month:
-          type: integer
-    WeekData:
-      properties:
-        weeks:
-          type: array
-          items:
-            $ref: '#/components/schemas/WeekModel'
-    WeekModel:
-      properties:
-        week:
-          type: integer
-    TimespanType:
-      type: string
-      enum: [months,weeks]
-    PeriodType:
-      type: string
-      enum: [last-2-months,last-3-months,last-6-months,last-12-months]
-    DataviewType:
-      type: string
-      enum: [raw,summary,repo-summary,namespace-summary]
-    DatasetType:
-      type: string
-      enum: [pulls]
-    TimespanModel:
-      oneOf:
-        - $ref: '#/components/schemas/MonthModel'
-        - $ref: '#/components/schemas/WeekModel'
-    TimespanData:
-      oneOf:
-        - $ref: '#/components/schemas/MonthData'
-        - $ref: '#/components/schemas/WeekData'
-    GroupType:
-      type: string
-      enum: [repo,namespace]
-  securitySchemes:
-    HubAuth:
-      type: https
-      scheme: bearer
-      bearerFormat: JWT
-      description: |
-        JWT Bearer Authentication is required to access the Docker DVP Data API.  
-          
-        This authentication documentation is duplicated from the [Hub API Authentication docs](https://docs.docker.com/reference/api/hub/#tag/authentication)
-      x-displayName: Docker Hub Authentication
+---
+outputs: 
+  - redirect
+url: /reference/api/dvp/latest.yaml
+---
diff --git a/content/reference/api/hub/latest-changelog.md b/content/reference/api/hub/latest-changelog.md
deleted file mode 100644
index c1c8d7ed42c1..000000000000
--- a/content/reference/api/hub/latest-changelog.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-description: Docker Hub API Changelog
-keywords: hub, api, changelog
-title: Docker Hub API Changelog
-keywords: docker hub, whats new, release notes, api, changelog
-weight: 2
-toc_min: 1
-toc_max: 2
----
-
-Here you can learn about the latest changes, new features, bug fixes, and known
-issues for Docker Service APIs.
-
-## 2025-03-25
-
-### New
-
-- Add [APIs](/reference/api/hub/latest/#tag/org-access-tokens) for organization access token (OATs) management.
-
-## 2025-03-18
-
-### New
-
-- Add access to [audit logs](/reference/api/hub/latest/#tag/audit-logs) for org
-  access tokens.
diff --git a/content/reference/api/hub/latest.md b/content/reference/api/hub/latest.md
index f70a8cc07eb7..15fd57a3db7f 100644
--- a/content/reference/api/hub/latest.md
+++ b/content/reference/api/hub/latest.md
@@ -1,7 +1,7 @@
 ---
 layout: api
-description: Reference documentation and OpenAPI specification for the Docker Hub API.
+description: Reference documentation and Swagger (OpenAPI) specification for the Docker Hub API.
 title: Docker Hub API reference
-linkTitle: Docker Hub API
+linkTitle: Latest
 weight: 1
 ---
diff --git a/content/reference/api/hub/latest.yaml b/content/reference/api/hub/latest.yaml
index f01d2d0bc39c..23a3a63defeb 100644
--- a/content/reference/api/hub/latest.yaml
+++ b/content/reference/api/hub/latest.yaml
@@ -23,7 +23,7 @@ tags:
   - name: changelog
     x-displayName: Changelog
     description: |
-      See the [Changelog](/reference/api/hub/latest-changelog) for a summary of changes across Docker Hub API versions.
+      See the [Changelog](/reference/api/hub/changelog) for a summary of changes across Docker Hub API versions.
   - name: resources
     x-displayName: Resources
     description: |
@@ -40,9 +40,9 @@ tags:
       - `X-RateLimit-Remaining` - The remaining amount of calls within the limit period.
       - `X-RateLimit-Reset` - The unix timestamp of when the remaining resets.
 
-      If you have hit the limit, you will receive a response status of `429` and the `X-Retry-After` header in the response.
+      If you have hit the limit, you will receive a response status of `429` and the `Retry-After` header in the response.
 
-      The `X-Retry-After` header is a unix timestamp of when you can call the API again.
+      The [`Retry-After` header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Retry-After) specifies the number of seconds to wait until you can call the API again.
 
       **Note**: These rate limits are separate from anti-abuse and Docker Hub download, or pull rate limiting.
       To learn more about Docker Hub pull rate limiting, see [Usage and limits](https://docs.docker.com/docker-hub/usage/).
@@ -51,9 +51,9 @@ tags:
     description: |
       Most Docker Hub API endpoints require you to authenticate using your Docker credentials before using them.
 
-      Additionally, similar to the Docker Hub UI features, API endpoint responses may vary depending on your plan (Personal, Pro, or Team) and your account's permissions.
+      Additionally, similar to the Docker Hub UI features, API endpoint responses may vary depending on your subscription (Personal, Pro, or Team) and your account's permissions.
 
-      To learn more about the features available in each plan and to upgrade your existing plan, see [Docker Pricing](https://www.docker.com/pricing).
+      To learn more about the features available in each subscription and to upgrade your existing subscription, see [Docker Pricing](https://www.docker.com/pricing?ref=Docs&refAction=DocsApiHub).
 
       # Types
 
@@ -101,7 +101,7 @@ tags:
   - name: access-tokens
     x-displayName: Personal Access Tokens
     description: |
-      The Personal Access Token endpoints lets you manage personal access tokens. For more information, see [Access Tokens](https://docs.docker.com/security/for-developers/access-tokens/).
+      The Personal Access Token endpoints lets you manage personal access tokens. For more information, see [Access Tokens](https://docs.docker.com/security/access-tokens/).
 
       You can use a personal access token instead of a password in the [Docker CLI](https://docs.docker.com/engine/reference/commandline/cli/) or in the [Create an authentication token](#operation/PostUsersLogin) route to obtain a bearer token.
 
@@ -117,7 +117,7 @@ tags:
     description: |
       The Audit Logs API endpoints allow you to query audit log events across a namespace.
 
-      For more information, see [Audit Logs](https://docs.docker.com/admin/organization/activity-logs/).
+      For more information, see [Audit Logs](https://docs.docker.com/admin/activity-logs/).
   - name: org-settings
     x-displayName: Org Settings
     description: |
@@ -139,14 +139,14 @@ tags:
     description: |
       The groups endpoints allow you to manage your organization's teams and their members.
 
-      For more information, seee [Create and manage a team](https://docs.docker.com/admin/organization/manage-a-team/).
+      For more information, see [Create and manage a team](https://docs.docker.com/admin/organization/manage/manage-a-team/).
   - name: invites
     x-displayName: Invites
     x-audience: public
     description: |
       The invites endpoints allow you to manage invites for users to join your Docker organization.
 
-      For more information, see [Invite members](https://docs.docker.com/admin/organization/members/#invite-members).
+      For more information, see [Invite members](https://docs.docker.com/admin/organization/manage/members/#invite-members).
   - name: scim
     x-displayName: SCIM
     x-audience: public
@@ -159,6 +159,12 @@ tags:
     x-audience: public
     description: |
       The organization access token endpoints allow you to manage organization access tokens (OATs). See [Organization access tokens](https://docs.docker.com/security/for-admins/access-tokens/) for more information.
+
+      OATs only authenticate requests to the modern namespace-scoped routes under `/v2/namespaces/{namespace}/repositories/`. Legacy repository paths are OAT unsupported, regardless of the token's scopes, and reject every OAT with `403 token issued from organization access token is not allowed`:
+
+      - `GET /v2/repositories/{namespace}/{repository}` — use [Get repository](#tag/repositories/operation/GetRepository) instead.
+      - `GET /v2/repositories/{namespace}` — use [List repositories](#tag/repositories/operation/listNamespaceRepositories) instead.
+      - `GET /v2/users/{username}/repositories` — use [List repositories](#tag/repositories/operation/listNamespaceRepositories) instead.
 paths:
   /v2/users/login:
     post:
@@ -425,46 +431,247 @@ paths:
                 response:
                   value:
                     actions:
+                      billing:
+                        actions:
+                          - name: plan.upgrade
+                            description: Occurs when your organization’s billing plan is upgraded to a higher tier plan.
+                            label: Plan Upgraded
+                          - name: plan.downgrade
+                            description: Occurs when your organization’s billing plan is downgraded to a lower tier plan.
+                            label: Plan Downgraded
+                          - name: plan.seat_add
+                            description: Occurs when a seat is added to your organization’s billing plan.
+                            label: Seat Added
+                          - name: plan.seat_remove
+                            description: Occurs when a seat is removed from your organization’s billing plan.
+                            label: Seat Removed
+                          - name: plan.cycle_change
+                            description: Occurs when there is a change in the recurring interval that your organization is charged.
+                            label: Billing Cycle Changed
+                          - name: plan.downgrade_cancel
+                            description: Occurs when a scheduled plan downgrade for your organization is canceled.
+                            label: Plan Downgrade Canceled
+                          - name: plan.seat_removal_cancel
+                            description: Occurs when a scheduled seat removal for an organization’s billing plan is canceled.
+                            label: Seat Removal Canceled
+                          - name: plan.upgrade.request
+                            description: Occurs when a user in your organization requests a plan upgrade.
+                            label: Plan Upgrade Requested
+                          - name: plan.downgrade.request
+                            description: Occurs when a user in your organization requests a plan downgrade.
+                            label: Plan Downgrade Requested
+                          - name: plan.seat_add.request
+                            description: Occurs when a user in your organization requests an increase in the number of seats.
+                            label: Seat Addition Requested
+                          - name: plan.seat_removal.request
+                            description: Occurs when a user in your organization requests a decrease in the number of seats.
+                            label: Seat Removal Requested
+                          - name: plan.cycle_change.request
+                            description: Occurs when a user in your organization requests a change in the billing cycle.
+                            label: Billing Cycle Change Requested
+                          - name: plan.downgrade_cancel.request
+                            description: Occurs when a user in your organization requests a cancellation of a scheduled plan downgrade.
+                            label: Plan Downgrade Cancellation Requested
+                          - name: plan.seat_removal_cancel.request
+                            description: Occurs when a user in your organization requests a cancellation of a scheduled seat removal.
+                            label: Seat Removal Cancellation Requested
+                          - name: plan.product_change
+                            description: Occurs when there is a change in the product that your organization subscribes to.
+                            label: Billing Product Changed
+                        label: Billing
+                      enterprise:
+                        actions:
+                          - name: setting.policy.create
+                            description: Details of adding an admin settings policy
+                            label: Policy created
+                          - name: setting.policy.update
+                            description: Details of updating an admin settings policy
+                            label: Policy updated
+                          - name: setting.policy.delete
+                            description: Details of deleting an admin settings policy
+                            label: Policy deleted
+                          - name: setting.policy.transfer
+                            description: Details of transferring an admin settings policy to another owner
+                            label: Policy transferred
+                          - name: sso.connection.create
+                            description: Details of creating a new org/company SSO connection
+                            label: Create SSO Connection
+                          - name: sso.connection.update
+                            description: Details of updating an existing org/company SSO connection
+                            label: Update SSO Connection
+                          - name: sso.connection.delete
+                            description: Details of deleting an existing org/company SSO connection
+                            label: Delete SSO Connection
+                          - name: sso.connection.enforcement_toggle
+                            description: Details of toggling enforcement on an existing org/company SSO connection
+                            label: Enforce SSO
+                          - name: sso.connection.scim_toggle
+                            description: Details of toggling SCIM on an existing org/company SSO connection
+                            label: Enforce SCIM
+                          - name: sso.connection.scim_token_refresh
+                            description: Details of a SCIM token refresh on an existing org/company SSO connection
+                            label: Refresh SCIM Token
+                          - name: sso.connection.connection_type_change
+                            description: Details of a connection type change on an existing org/company SSO connection
+                            label: Change SSO Connection Type
+                          - name: sso.connection.jit_toggle
+                            description: Details of a JIT toggle on an existing org/company SSO connection
+                            label: Toggle JIT provisioning
+                        label: Enterprise
+                      offload:
+                        actions:
+                          - name: lease.start
+                            description: Details of the started Offload lease.
+                            label: Offload lease start
+                          - name: lease.end
+                            description: Details of the ended Offload lease.
+                            label: Offload lease end
+                        label: Offload
+                      oidc:
+                        actions:
+                          - name: connection.create
+                            description: Details of creating an OIDC connection.
+                            label: OIDC connection created
+                          - name: connection.update
+                            description: Details of updating an OIDC connection.
+                            label: OIDC connection updated
+                          - name: connection.delete
+                            description: Details of deleting an OIDC connection.
+                            label: OIDC connection deleted
+                        label: OIDC
                       org:
                         actions:
+                          - name: create
+                            description: Activities related to the creation of a new organization
+                            label: Organization Created
+                          - name: member.add
+                            description: Details of the member added to your organization
+                            label: Organization Member Added
+                          - name: member.remove
+                            description: Details about the member removed from your organization
+                            label: Organization Member Removed
+                          - name: member.role.change
+                            description: Details about the role changed for a member in your organization
+                            label: Member Role Changed
+                          - name: member.invite.send
+                            description: Details of the member invited to your organization
+                            label: Org Member Invited
                           - name: team.create
-                            description: contains team create events
-                            label: Team Created
+                            description: Activities related to the creation of a team
+                            label: Organization Created
+                          - name: team.update
+                            description: Activities related to the modification of a team
+                            label: Organization Deleted
                           - name: team.delete
-                            description: contains team delete events
-                            label: Team Deleted
+                            description: Activities related to the deletion of a team
+                            label: Organization Deleted
                           - name: team.member.add
-                            description: contains team member add events
+                            description: Details of the member added to your team
                             label: Team Member Added
                           - name: team.member.remove
-                            description: contains team member remove events
+                            description: Details of the member removed from your team
                             label: Team Member Removed
-                          - name: team.member.invite
-                            description: contains team member invite events
-                            label: Team Member Invited
-                          - name: member.removed
-                            description: contains org member remove events
-                            label: Organization Member Removed
-                          - name: create
-                            description: contains organization create events
-                            label: Organization Created
+                          - name: domain.create
+                            description: Details of the single sign-on domain added to your organization
+                            label: Single Sign-On domain added
+                          - name: domain.verify
+                            description: Details of the single sign-on domain verified for your organization
+                            label: Single Sign-On domain verified
+                          - name: domain.delete
+                            description: Details of the single sign-on domain removed from your organization
+                            label: Single Sign-On domain deleted
+                          - name: domain.auto-provisioning.toggle
+                            description: Details of toggling the Auto-Provisioning feature on a domain on or off
+                            label: Organization Auto-Provisioning Toggled
+                          - name: settings.update
+                            description: Details related to the organization setting that was updated
+                            label: Organization Settings Updated
+                          - name: registry_access.enabled
+                            description: Activities related to enabling Registry Access Management
+                            label: Registry Access Management enabled
+                          - name: registry_access.disabled
+                            description: Activities related to disabling Registry Access Management
+                            label: Registry Access Management disabled
+                          - name: registry_access.registry_added
+                            description: Activities related to the addition of a registry
+                            label: Registry Access Management registry added
+                          - name: registry_access.registry_updated
+                            description: Details related to the registry that was updated
+                            label: Registry Access Management registry updated
+                          - name: registry_access.registry_removed
+                            description: Activities related to the removal of a registry
+                            label: Registry Access Management registry removed
+                          - name: access_token.create
+                            description: Access token created in organization
+                            label: Access token created
+                          - name: access_token.update
+                            description: Access token updated in organization
+                            label: Access token updated
+                          - name: access_token.delete
+                            description: Access token deleted in organization
+                            label: Access token deleted
+                          - name: customrole.create
+                            description: A custom role was created
+                            label: Custom role created
+                          - name: customrole.update
+                            description: An existing custom role was updated
+                            label: Custom role updated
+                          - name: customrole.delete
+                            description: A custom role was deleted
+                            label: Custom role deleted
+                          - name: securepolicyconfigure.create
+                            description: A secure policy configuration was created
+                            label: Secure Policy Configuration created
+                          - name: securepolicyconfigure.update
+                            description: A secure policy configuration was updated
+                            label: Secure Policy Configuration updated
+                          - name: securepolicyconfigure.delete
+                            description: A secure policy configuration was deleted
+                            label: Secure Policy Configuration deleted
+                          - name: securepolicyclient.create
+                            description: A secure policy client was created
+                            label: Secure Policy Client created
+                          - name: securepolicyclient.update
+                            description: A secure policy client was updated
+                            label: Secure Policy Client updated
+                          - name: securepolicyclient.delete
+                            description: A secure policy client was deleted
+                            label: Secure Policy Client deleted
+                          - name: securepolicyprofile.create
+                            description: A secure policy profile was created
+                            label: Secure Policy Profile created
+                          - name: securepolicyprofile.update
+                            description: A secure policy profile was updated
+                            label: Secure Policy Profile updated
+                          - name: securepolicyprofile.delete
+                            description: A secure policy profile was deleted
+                            label: Secure Policy Profile deleted
                         label: Organization
                       repo:
                         actions:
                           - name: create
-                            description: contains repository create events
+                            description: Activities related to the creation of a new repository
                             label: Repository Created
+                          - name: update
+                            description: Activities related to the modification of a repository
+                            label: Repository Updated
                           - name: delete
-                            description: contains repository delete events
+                            description: Activities related to the deletion of a repository
                             label: Repository Deleted
                           - name: change_privacy
-                            description: contains repository privacy change events
+                            description: Details related to the privacy policies that were updated
                             label: Privacy Changed
+                          - name: category.updated
+                            description: Details related to updating a repository categories
+                            label: Categories updated
+                          - name: immutable.tags.updated
+                            description: Details related to updating tag immutability of a repository
+                            label: Tag immutability updated
                           - name: tag.push
-                            description: contains image tag push events
+                            description: Activities related to the tags pushed
                             label: Tag Pushed
                           - name: tag.delete
-                            description: contains image tag delete events
+                            description: Activities related to the tags deleted
                             label: Tag Deleted
                         label: Repository
         "429":
@@ -528,6 +735,19 @@ paths:
                         timestamp: "2021-02-19T01:34:35Z"
                         action_description: |
                           pushed the tag latest with the digest sha256:c1ae9c435032a to the repository docker/example
+                      - account: docker
+                        action: offload.lease.end
+                        name: docker
+                        actor: docker
+                        data:
+                          lease_id: l_3EgPuRCjtUqT279CFPOQWcO8zOf
+                          resource_type: run_4cpu_8mem
+                          started_at: "2026-06-04T18:24:21Z"
+                          updated_at: "2026-06-04T18:36:43Z"
+                          org_id: b908ca6e-b9a9-4a53-a9a5-6bec96f72432
+                          user_id: ecae6747-e42c-43cb-925d-cfce1ab32b02
+                        timestamp: "2026-06-04T18:36:43Z"
+                        action_description: "offload lease 'l_3EgPuRCjtUqT279CFPOQWcO8zOf' ended, ran for '12m22s'"
         "429":
           description: ""
           content:
@@ -641,11 +861,11 @@ paths:
     put:
       summary: Update organization settings
       description: |
-        Updates an organization's settings. Some settings are only used when the organization is on a business plan.
+        Updates an organization's settings. Some settings are only used when the organization is on a business subscription.
 
         ***Only users with administrative privileges for the organization (owner role) can modify these settings.***
 
-        The following settings are only used on a business plan:
+        The following settings are only used on a business subscription:
         - `restricted_images`
       tags:
         - org-settings
@@ -823,7 +1043,12 @@ paths:
       - $ref: "#/components/parameters/namespace"
       - $ref: "#/components/parameters/repository"
     get:
+      operationId: ListRepositoryTags
       summary: List repository tags
+      description: |
+        Returns the list of tags for the specified repository.
+
+        <span class="oat"></span>
       tags:
         - repositories
       security:
@@ -850,6 +1075,10 @@ paths:
           $ref: "#/components/responses/NotFound"
     head:
       summary: Check repository tags
+      description: |
+        Checks whether the repository has any tags.
+
+        <span class="oat"></span>
       tags:
         - repositories
       security:
@@ -867,7 +1096,12 @@ paths:
       - $ref: "#/components/parameters/repository"
       - $ref: "#/components/parameters/tag"
     get:
+      operationId: GetRepositoryTag
       summary: Read repository tag
+      description: |
+        Returns details for a specific tag in the specified repository.
+
+        <span class="oat"></span>
       tags:
         - repositories
       security:
@@ -881,6 +1115,10 @@ paths:
           $ref: "#/components/responses/NotFound"
     head:
       summary: Check repository tag
+      description: |
+        Checks whether the specified tag exists in the repository.
+
+        <span class="oat"></span>
       tags:
         - repositories
       security:
@@ -892,42 +1130,442 @@ paths:
           $ref: "#/components/responses/Forbidden"
         "404":
           $ref: "#/components/responses/NotFound"
+  /v2/namespaces/{namespace}/repositories/{repository}/immutabletags:
+    parameters:
+      - $ref: "#/components/parameters/namespace"
+      - $ref: "#/components/parameters/repository"
+    patch:
+      operationId: UpdateRepositoryImmutableTags
+      summary: "Update repository immutable tags"
+      description: |
+        Updates the immutable tags configuration for this repository.
+
+        **Only users with administrative privileges for the repository can modify these settings.**
+
+        <span class="oat"></span>
+      tags:
+        - repositories
+      security:
+        - bearerAuth: []
+      requestBody:
+        $ref: "#/components/requestBodies/update_repository_immutable_tags_request"
+      responses:
+        200:
+          $ref: "#/components/responses/update_repository_immutable_tags_response"
+        400:
+          $ref: "#/components/responses/bad_request"
+        401:
+          $ref: "#/components/responses/unauthorized"
+        403:
+          $ref: "#/components/responses/forbidden"
+        404:
+          $ref: "#/components/responses/not_found"
+  /v2/namespaces/{namespace}/repositories/{repository}/immutabletags/verify:
+    parameters:
+      - $ref: "#/components/parameters/namespace"
+      - $ref: "#/components/parameters/repository"
+    post:
+      operationId: VerifyRepositoryImmutableTags
+      summary: "Verify repository immutable tags"
+      description: |
+        Validates the immutable tags regex passed in the request body and returns a list of tags matching it in this repository.
+
+        **Only users with administrative privileges for the repository can call this endpoint.**
+
+        <span class="oat"></span>
+      tags:
+        - repositories
+      security:
+        - bearerAuth: []
+      requestBody:
+        $ref: "#/components/requestBodies/immutable_tags_verify_request"
+      responses:
+        200:
+          $ref: "#/components/responses/immutable_tags_verify_response"
+        400:
+          $ref: "#/components/responses/bad_request"
+        401:
+          $ref: "#/components/responses/unauthorized"
+        403:
+          $ref: "#/components/responses/forbidden"
+        404:
+          $ref: "#/components/responses/not_found"
   /v2/repositories/{namespace}/{repository}/groups:
     parameters:
       - $ref: "#/components/parameters/namespace"
       - $ref: "#/components/parameters/repository"
     post:
       summary: Assign a group (Team) to a repository for access
+      description: |
+        Assigns an organization group (team) to a repository with a specified permission level.
+
+        <span class="oat"></span>
+      tags:
+        - repositories
+      operationId: CreateRepositoryGroup
+      security:
+        - bearerAuth: []
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: "#/components/schemas/RepositoryGroupCreationRequest"
+            example:
+              group_id: 12345
+              permission: "write"
+      responses:
+        "200":
+          description: Repository group permission created successfully
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/RepositoryGroup"
+              example:
+                group_name: "developers"
+                permission: "write"
+                group_id: 12345
+        "400":
+          description: Bad Request - Invalid request parameters
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/error"
+        "401":
+          $ref: "#/components/responses/unauthorized"
+        "403":
+          $ref: "#/components/responses/forbidden"
+        "404":
+          $ref: "#/components/responses/NotFound"
+  /v2/namespaces/{namespace}/repositories:
+    parameters:
+      - $ref: "#/components/parameters/namespace"
+    get:
+      operationId: listNamespaceRepositories
+      summary: List repositories in a namespace
+      description: |
+        Returns a list of repositories within the specified namespace (organization or user).
+
+        Public repositories are accessible to everyone, while private repositories require appropriate authentication and permissions.
+
+        <span class="oat"></span>
+
+        **OAT listing behavior**: an OAT with the `scope-repository-list` scope sees all repositories including private ones. An OAT without that scope only sees public repositories. This filtering is silent: the response is a normal `200` with no indication that private repositories were withheld.
       tags:
         - repositories
       security:
         - bearerAuth: []
+        - {} # Allow anonymous access for public repositories
       parameters:
         - in: query
-          name: group_name
-          required: true
+          name: page
+          required: false
+          schema:
+            type: integer
+            minimum: 1
+            default: 1
+          description: Page number to get. Defaults to 1.
+        - in: query
+          name: page_size
+          required: false
+          schema:
+            type: integer
+            minimum: 1
+            maximum: 100
+            default: 10
+          description: Number of repositories to get per page. Defaults to 10. Max of 100.
+        - in: query
+          name: name
+          required: false
           schema:
             type: string
-          description: Name of the group (team) in the organization.
+          description: Filter repositories by name (partial match).
         - in: query
-          name: permission
-          required: true
+          name: ordering
+          required: false
           schema:
             type: string
-            description: |
-              Access level for the group. Possible values:
-              - `read`
-              - `write`
-              - `admin`
+            enum:
+              - name
+              - -name
+              - last_updated
+              - -last_updated
+              - pull_count
+              - -pull_count
+          description: |
+            Order repositories by the specified field. Prefix with '-' for descending order.
+            Available options:
+            - `name` / `-name`: Repository name (ascending/descending)
+            - `last_updated` / `-last_updated`: Last update time (ascending/descending)
+            - `pull_count` / `-pull_count`: Number of pulls (ascending/descending)
       responses:
         "200":
-          $ref: "#/components/responses/team_repo"
+          description: List of repositories
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/list_repositories_response"
+              examples:
+                repositories_list:
+                  value:
+                    count: 287
+                    next: "https://hub.docker.com/v2/namespaces/docker/repositories?page=2&page_size=2"
+                    previous: null
+                    results:
+                      - name: "highland_builder"
+                        namespace: "docker"
+                        repository_type: "image"
+                        status: 1
+                        status_description: "active"
+                        description: "Image for performing Docker build requests"
+                        is_private: false
+                        star_count: 7
+                        pull_count: 15722123
+                        last_updated: "2023-06-20T10:44:45.459826Z"
+                        last_modified: "2024-10-16T13:48:34.145251Z"
+                        date_registered: "2015-05-19T21:13:35.937763Z"
+                        affiliation: ""
+                        media_types:
+                          - "application/octet-stream"
+                          - "application/vnd.docker.container.image.v1+json"
+                          - "application/vnd.docker.distribution.manifest.v1+prettyjws"
+                        content_types:
+                          - "unrecognized"
+                          - "image"
+                        categories:
+                          - name: "Languages & frameworks"
+                            slug: "languages-and-frameworks"
+                          - name: "Integration & delivery"
+                            slug: "integration-and-delivery"
+                          - name: "Operating systems"
+                            slug: "operating-systems"
+                        storage_size: 488723114800
+                      - name: "whalesay"
+                        namespace: "docker"
+                        repository_type: null
+                        status: 1
+                        status_description: "active"
+                        description: "An image for use in the Docker demo tutorial"
+                        is_private: false
+                        star_count: 757
+                        pull_count: 130737682
+                        last_updated: "2015-06-19T19:06:27.388123Z"
+                        last_modified: "2024-10-16T13:48:34.145251Z"
+                        date_registered: "2015-06-09T18:16:36.527329Z"
+                        affiliation: ""
+                        media_types:
+                          - "application/vnd.docker.distribution.manifest.v1+prettyjws"
+                        content_types:
+                          - "image"
+                        categories:
+                          - name: "Languages & frameworks"
+                            slug: "languages-and-frameworks"
+                          - name: "Integration & delivery"
+                            slug: "integration-and-delivery"
+                        storage_size: 103666708
+        "400":
+          description: Bad Request - Invalid request parameters
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/error"
+              examples:
+                invalid_ordering:
+                  summary: Invalid ordering value
+                  value:
+                    fields:
+                      ordering:
+                        [
+                          "Invalid ordering value. Must be one of: name, -name, last_updated, -last_updated, pull_count, -pull_count",
+                        ]
+                    text: "Invalid ordering value"
+        "401":
+          $ref: "#/components/responses/unauthorized"
         "403":
           $ref: "#/components/responses/forbidden"
         "404":
-          $ref: "#/components/responses/NotFound"
+          description: Page not found - occurs when requesting a page number `>1` that exceeds the available results
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/error"
+    post:
+      summary: Create a new repository
+      description: |
+        Creates a new repository within the specified namespace. The repository will be created
+        with the provided metadata including name, description, and privacy settings.
+
+        <span class="oat"></span>
+      operationId: CreateRepository
+      tags:
+        - repositories
+      security:
+        - BearerAuth: []
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: "#/components/schemas/repo_creation_request"
+            example:
+              name: "my-app"
+              namespace: "myorganization"
+              description: "A sample application repository"
+              full_description: "This is a comprehensive description of my application repository that contains additional details about the project."
+              registry: "docker.io"
+              is_private: false
+      responses:
+        201:
+          description: Repository created successfully
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/repository_info"
+              example:
+                name: "my-app"
+                namespace: "myorganization"
+                repository_type: "image"
+                status: 1
+                status_description: "Active"
+                description: "A sample application repository"
+                is_private: false
+                is_automated: false
+                star_count: 0
+                pull_count: 0
+                last_updated: "2025-01-20T10:30:00Z"
+                date_registered: "2025-01-20T10:30:00Z"
+                collaborator_count: 0
+                hub_user: "myorganization"
+                has_starred: false
+                full_description: "This is a comprehensive description of my application repository that contains additional details about the project."
+                media_types: []
+                content_types: []
+                categories: []
+                immutable_tags_settings:
+                  enabled: false
+                  rules: []
+                storage_size: null
+                source: null
+        400:
+          $ref: "#/components/responses/bad_request"
+        401:
+          $ref: "#/components/responses/unauthorized"
+        403:
+          $ref: "#/components/responses/forbidden"
+        404:
+          $ref: "#/components/responses/not_found"
+        500:
+          $ref: "#/components/responses/internal_error"
+  /v2/namespaces/{namespace}/repositories/{repository}:
+    parameters:
+      - $ref: "#/components/parameters/namespace"
+      - $ref: "#/components/parameters/repository"
+    get:
+      operationId: GetRepository
+      summary: Get repository in a namespace
+      description: |
+        Returns a repository within the specified namespace (organization or user).
+
+        Public repositories are accessible to everyone, while private repositories require appropriate authentication and permissions.
+
+        <span class="oat"></span>
+      tags:
+        - repositories
+      security:
+        - bearerAuth: []
+        - {} # Allow anonymous access for public repositories
+      responses:
+        200:
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/repository_info"
+              example:
+                name: "my-app"
+                namespace: "myorganization"
+                repository_type: "image"
+                status: 1
+                status_description: "Active"
+                description: "A sample application repository"
+                is_private: false
+                is_automated: false
+                star_count: 0
+                pull_count: 0
+                last_updated: "2025-01-20T10:30:00Z"
+                date_registered: "2025-01-20T10:30:00Z"
+                collaborator_count: 0
+                hub_user: "myorganization"
+                has_starred: false
+                full_description: "This is a comprehensive description of my application repository that contains additional details about the project."
+                media_types: []
+                content_types: []
+                categories: []
+                immutable_tags_settings:
+                  enabled: false
+                  rules: []
+                storage_size: null
+                source: null
+        401:
+          $ref: "#/components/responses/unauthorized"
+        403:
+          $ref: "#/components/responses/forbidden"
+        404:
+          $ref: "#/components/responses/not_found"
+        500:
+          $ref: "#/components/responses/internal_error"
+    head:
+      operationId: CheckRepository
+      summary: Check repository in a namespace
+      description: |
+        Check a repository within the specified namespace (organization or user).
+
+        Public repositories are accessible to everyone, while private repositories require appropriate authentication and permissions.
 
-          
+        <span class="oat"></span>
+      tags:
+        - repositories
+      security:
+        - bearerAuth: []
+        - {} # Allow anonymous access for public repositories
+      responses:
+        200:
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/repository_info"
+              example:
+                name: "my-app"
+                namespace: "myorganization"
+                repository_type: "image"
+                status: 1
+                status_description: "Active"
+                description: "A sample application repository"
+                is_private: false
+                is_automated: false
+                star_count: 0
+                pull_count: 0
+                last_updated: "2025-01-20T10:30:00Z"
+                date_registered: "2025-01-20T10:30:00Z"
+                collaborator_count: 0
+                hub_user: "myorganization"
+                has_starred: false
+                full_description: "This is a comprehensive description of my application repository that contains additional details about the project."
+                media_types: []
+                content_types: []
+                categories: []
+                immutable_tags_settings:
+                  enabled: false
+                  rules: []
+                storage_size: null
+                source: null
+        401:
+          $ref: "#/components/responses/unauthorized"
+        403:
+          $ref: "#/components/responses/forbidden"
+        404:
+          $ref: "#/components/responses/not_found"
+        500:
+          $ref: "#/components/responses/internal_error"
   /v2/orgs/{org_name}/members:
     parameters:
       - $ref: "#/components/parameters/org_name"
@@ -948,7 +1586,7 @@ paths:
         - `last_seen_at`
         - `last_desktop_version`
 
-        To make visible, please see [View Insights for organization users](https://docs.docker.com/admin/organization/insights/#view-insights-for-organization-users).
+        To make visible, please see [View Insights for organization users](https://docs.docker.com/admin/insights/#view-insights-for-organization-users).
 
         <span class="oat"></span>
       tags:
@@ -2008,7 +2646,412 @@ components:
         application/scim+json:
           schema:
             $ref: "#/components/schemas/scim_user"
+    update_repository_immutable_tags_response:
+      description: ""
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/repository_info"
+    immutable_tags_verify_response:
+      description: ""
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/immutable_tags_verify_response"
   schemas:
+    update_repository_immutable_tags_request:
+      type: object
+      properties:
+        immutable_tags:
+          type: boolean
+          description: Whether immutable tags are enabled
+        immutable_tags_rules:
+          type: array
+          items:
+            type: string
+          description: List of immutable tag rules
+          example:
+            - "v.*"
+            - ".*-RELEASE"
+      required:
+        - immutable_tags
+        - immutable_tags_rules
+    repo_creation_request:
+      type: object
+      required:
+        - name
+        - namespace
+      properties:
+        name:
+          type: string
+          description: |
+            The name of the repository. Must be 2-255 characters long and may only include 
+            alphanumeric characters, periods (.), underscores (_), or hyphens (-). 
+            Letters must be lowercase.
+          minLength: 2
+          maxLength: 255
+          pattern: "^[a-z0-9]+(?:[._-][a-z0-9]+)*$"
+          example: "my-app"
+        namespace:
+          type: string
+          description: The namespace where the repository will be created
+          example: "myorganization"
+        description:
+          type: string
+          description: Short description of the repository
+          maxLength: 100
+          example: "A sample application repository"
+        full_description:
+          type: string
+          description: Detailed description of the repository
+          maxLength: 25000
+          example: "This is a comprehensive description of my application repository that contains additional details about the project, its purpose, usage instructions, and other relevant information."
+        registry:
+          type: string
+          description: The registry where the repository will be hosted
+          example: "docker.io"
+        is_private:
+          type: boolean
+          description: Whether the repository should be private
+          default: false
+          example: false
+    RepositoryGroupCreationRequest:
+      type: object
+      required:
+        - group_id
+        - permission
+      properties:
+        group_id:
+          type: integer
+          format: int64
+          description: The ID of the organization group to grant access to
+          example: 12345
+        permission:
+          type: string
+          description: |
+            The permission level to grant to the group:
+            - read: Can view and pull from the repository
+            - write: Can view, pull, and push to the repository
+            - admin: Can view, pull, push, and manage repository settings
+          enum: ["read", "write", "admin"]
+          example: "write"
+    RepositoryGroup:
+      type: object
+      properties:
+        group_name:
+          type: string
+          description: The name of the group
+          example: "developers"
+        permission:
+          type: string
+          description: The permission level granted to the group
+          enum: ["read", "write", "admin"]
+          example: "write"
+        group_id:
+          type: integer
+          format: int64
+          description: The ID of the group
+          example: 12345
+    repository_info:
+      type: object
+      properties:
+        user:
+          type: string
+          description: Username of the repository owner
+        name:
+          type: string
+          description: Repository name
+        namespace:
+          type: string
+          description: Repository namespace
+        repository_type:
+          type: string
+          nullable: true
+          description: Type of the repository
+        status:
+          type: integer
+          description: Repository status code
+        status_description:
+          type: string
+          description: Description of the repository status
+        description:
+          type: string
+          description: Short description of the repository
+        is_private:
+          type: boolean
+          description: Whether the repository is private
+        is_automated:
+          type: boolean
+          description: Whether the repository has automated builds
+        star_count:
+          type: integer
+          format: int64
+          description: Number of stars
+        pull_count:
+          type: integer
+          format: int64
+          description: Number of pulls
+        last_updated:
+          type: string
+          format: date-time
+          example: "2021-01-05T21:06:53.506400Z"
+          description: ISO 8601 timestamp of when repository was last updated
+        last_modified:
+          type: string
+          format: date-time
+          example: "2021-01-05T21:06:53.506400Z"
+          nullable: true
+          description: ISO 8601 timestamp of when repository was last modified
+        date_registered:
+          type: string
+          format: date-time
+          example: "2021-01-05T21:06:53.506400Z"
+          description: ISO 8601 timestamp of when repository was created
+        collaborator_count:
+          type: integer
+          format: int64
+          description: Number of collaborators
+        affiliation:
+          type: string
+          nullable: true
+          description: Repository affiliation
+        hub_user:
+          type: string
+          nullable: true
+          description: Hub user information
+        has_starred:
+          type: boolean
+          description: Whether the current user has starred this repository
+        full_description:
+          type: string
+          nullable: true
+          description: Full description of the repository
+        permissions:
+          $ref: "#/components/schemas/repo_permissions"
+        media_types:
+          type: array
+          items:
+            type: string
+            nullable: true
+          description: Supported media types
+        content_types:
+          type: array
+          items:
+            type: string
+          description: Supported content types
+        categories:
+          type: array
+          items:
+            $ref: "#/components/schemas/category"
+          description: Repository categories
+        immutable_tags_settings:
+          $ref: "#/components/schemas/immutable_tags_settings"
+        storage_size:
+          type: integer
+          format: int64
+          nullable: true
+          description: Storage size in bytes
+        source:
+          type: string
+          nullable: true
+          description: Source of the repository, where it was created from
+      required:
+        - user
+        - name
+        - namespace
+        - status
+        - status_description
+        - description
+        - is_private
+        - is_automated
+        - star_count
+        - pull_count
+        - last_updated
+        - date_registered
+        - collaborator_count
+        - has_starred
+        - permissions
+        - media_types
+        - content_types
+        - categories
+        - immutable_tags_settings
+    repo_permissions:
+      type: object
+      properties:
+        read:
+          type: boolean
+          description: Read permission
+        write:
+          type: boolean
+          description: Write permission
+        admin:
+          type: boolean
+          description: Admin permission
+      required:
+        - read
+        - write
+        - admin
+    immutable_tags_settings:
+      type: object
+      properties:
+        enabled:
+          type: boolean
+          description: Whether immutable tags are enabled
+        rules:
+          type: array
+          items:
+            type: string
+          description: List of immutable tag rules
+      required:
+        - enabled
+        - rules
+    immutable_tags_verify_request:
+      type: object
+      properties:
+        regex:
+          type: string
+          pattern: '^[a-z0-9]+((\\.|_|__|-+)[a-z0-9]+)*(\\/[a-z0-9]+((\\.|_|__|-+)[a-z0-9]+)*)*$'
+          description: 'Immutable tags rule regex pattern. Must match format: [a-z0-9]+((\\.|_|__|-+)[a-z0-9]+)*(\\/[a-z0-9]+((\\.|_|__|-+)[a-z0-9]+)*)*'
+          example: "v.*"
+      required:
+        - regex
+    immutable_tags_verify_response:
+      type: object
+      properties:
+        tags:
+          type: array
+          items:
+            type: string
+          description: List of tags that match the provided regex pattern
+          example:
+            - "v1.0.0"
+            - "v2.1.3"
+            - "latest"
+      required:
+        - tags
+    repository_list_entry:
+      type: object
+      properties:
+        name:
+          type: string
+          description: Name of the repository
+          example: "hello-world"
+        namespace:
+          type: string
+          description: Namespace (organization or username) that owns the repository
+          example: "docker"
+        repository_type:
+          type: string
+          description: Type of repository
+          enum:
+            - image
+            - plugin
+            - null
+          example: "image"
+          nullable: true
+        status:
+          type: integer
+          description: Repository status code
+          example: 1
+        status_description:
+          type: string
+          description: Human-readable repository status
+          enum:
+            - active
+            - inactive
+          example: "active"
+        description:
+          type: string
+          description: Repository description
+          nullable: true
+          example: "Hello World! (an example of minimal Dockerization)"
+        is_private:
+          type: boolean
+          description: Whether the repository is private
+          example: false
+        star_count:
+          type: integer
+          description: Number of users who starred this repository
+          minimum: 0
+          example: 1234
+        pull_count:
+          type: integer
+          description: Total number of pulls for this repository
+          minimum: 0
+          example: 50000000
+        last_updated:
+          type: string
+          format: date-time
+          description: ISO 8601 timestamp of when the repository was last updated
+          example: "2023-12-01T10:30:00Z"
+          nullable: true
+        last_modified:
+          type: string
+          format: date-time
+          description: ISO 8601 timestamp of when the repository was last modified
+          example: "2023-12-01T10:30:00Z"
+          nullable: true
+        date_registered:
+          type: string
+          format: date-time
+          description: ISO 8601 timestamp of when the repository was created
+          example: "2013-06-19T19:07:54Z"
+        affiliation:
+          type: string
+          description: User's affiliation with the repository (empty string if no affiliation)
+          example: ""
+        media_types:
+          type: array
+          description: Media types supported by this repository
+          items:
+            type: string
+          example:
+            - "application/vnd.docker.plugin.v1+json"
+        content_types:
+          type: array
+          description: Content types supported by this repository
+          items:
+            type: string
+          example:
+            - "plugin"
+        categories:
+          type: array
+          description: Categories associated with this repository
+          items:
+            $ref: "#/components/schemas/category"
+          example: []
+        storage_size:
+          type: integer
+          description: Storage size in bytes used by this repository
+          minimum: 0
+          example: 232719127
+    category:
+      type: object
+      required:
+        - name
+        - slug
+      properties:
+        name:
+          type: string
+          description: Human-readable name of the category
+          example: "Databases"
+          minLength: 1
+        slug:
+          type: string
+          description: URL-friendly identifier for the category
+          example: "databases"
+          minLength: 1
+          pattern: "^[a-z0-9]+(?:-[a-z0-9]+)*$"
+      description: Repository category for classification and discovery
+    list_repositories_response:
+      allOf:
+        - $ref: "#/components/schemas/page"
+        - type: object
+          properties:
+            results:
+              type: array
+              items:
+                $ref: "#/components/schemas/repository_list_entry"
     UsersLoginRequest:
       description: User login details
       type: object
@@ -2226,6 +3269,10 @@ components:
             - repo:read
           items:
             type: string
+        expires_at:
+          type: string
+          format: date-time
+          example: "2021-10-28T18:30:19.520861Z"
     createAccessTokenRequest:
       type: object
       required:
@@ -2503,7 +3550,7 @@ components:
           example: moby
         invitee:
           type: string
-          description: can either be a dockerID for registred users or an email for non-registred users
+          description: can either be a dockerID for registered users or an email for non-registered users
           example: invitee@docker.com
         org:
           type: string
@@ -2633,7 +3680,7 @@ components:
             - owners
         is_guest:
           type: boolean
-          description: If the organization has verfied domains, members that have email addresses outside of those domains will be flagged as guests.
+          description: If the organization has verified domains, members that have email addresses outside of those domains will be flagged as guests.
           example: false
         primary_email:
           type: string
@@ -2645,20 +3692,20 @@ components:
           format: date-time
           description: |
             Last time the user logged in. To access this field, you must have insights visible for your organization. See 
-            [Insights](https://docs.docker.com/admin/organization/insights/#view-insights-for-organization-users).
+            [Insights](https://docs.docker.com/admin/insights/#view-insights-for-organization-users).
           example: "2021-01-05T21:06:53.506400Z"
         last_seen_at:
           type: string
           format: date-time
           description: |
             Last time the user was seen. To access this field, you must have insights visible for your organization. See 
-            [Insights](https://docs.docker.com/admin/organization/insights/#view-insights-for-organization-users).
+            [Insights](https://docs.docker.com/admin/insights/#view-insights-for-organization-users).
           example: "2021-01-05T21:06:53.506400Z"
         last_desktop_version:
           type: string
           description: |
             Last desktop version the user used. To access this field, you must have insights visible for your organization. See 
-            [Insights](https://docs.docker.com/admin/organization/insights/#view-insights-for-organization-users).
+            [Insights](https://docs.docker.com/admin/insights/#view-insights-for-organization-users).
           example: 4.29.0
 
     org_member_paginated:
@@ -3020,14 +4067,20 @@ components:
         path:
           type: string
           example: "myorg/myrepo"
-          description: The path of the resource. The format of this will change depending on the type of resource.
+          description: |
+            The path of the resource. The format of this will change depending on the type of resource.
+
+            For TYPE_REPO resources:
+            - Must be an existing repository name (e.g., "myorg/myrepo")
+            - Can use glob patterns (e.g., "myorg/*" for all repositories in the organization)
+            - Use "*/*/public" to reference all public repositories
           required: true
         scopes:
           type: array
           description: The scopes this token has access to
           items:
             type: string
-            example: "repo-pull"
+            example: "scope-image-pull"
           required: true
     getOrgAccessTokensResponse:
       type: object
@@ -3081,7 +4134,31 @@ components:
     createOrgAccessTokenResponse:
       type: object
       allOf:
-        - $ref: "#/components/schemas/orgAccessToken"
+        - type: object
+          properties:
+            id:
+              type: string
+              example: "a7a5ef25-8889-43a0-8cc7-f2a94268e861"
+            label:
+              type: string
+              example: "My organization token"
+            is_active:
+              type: boolean
+              example: true
+            created_at:
+              type: string
+              format: date-time
+              example: "2022-05-20T00:54:18Z"
+            expires_at:
+              type: string
+              format: date-time
+              example: "2023-05-20T00:54:18Z"
+              nullable: true
+            last_used_at:
+              type: string
+              format: date-time
+              example: "2022-06-15T12:30:45Z"
+              nullable: true
         - type: object
           properties:
             token:
@@ -3329,6 +4406,18 @@ components:
               member:
                 type: string
                 example: jonsnow
+    update_repository_immutable_tags_request:
+      required: true
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/update_repository_immutable_tags_request"
+    immutable_tags_verify_request:
+      required: true
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/immutable_tags_verify_request"
   securitySchemes:
     bearerAuth:
       type: http
diff --git a/content/reference/api/registry/_index.md b/content/reference/api/registry/_index.md
new file mode 100644
index 000000000000..0d376d4a28ec
--- /dev/null
+++ b/content/reference/api/registry/_index.md
@@ -0,0 +1,5 @@
+---
+title: Registry API
+build:
+  render: never
+---
\ No newline at end of file
diff --git a/content/reference/api/registry/auth.md b/content/reference/api/registry/auth.md
new file mode 100644
index 000000000000..601d50e4a6bc
--- /dev/null
+++ b/content/reference/api/registry/auth.md
@@ -0,0 +1,221 @@
+---
+title: Registry authentication
+description: "Specifies the Docker Registry v2 authentication"
+keywords: registry, images, tags, repository, distribution, Bearer authentication, advanced
+---
+
+This document outlines the registry authentication scheme:
+
+![v2 registry auth](./images/v2-registry-auth.png)
+
+1. Attempt to begin a push/pull operation with the registry.
+2. If the registry requires authorization it will return a `401 Unauthorized`
+   HTTP response with information on how to authenticate.
+3. The registry client makes a request to the authorization service for a
+   Bearer token.
+4. The authorization service returns an opaque Bearer token representing the
+   client's authorized access.
+5. The client retries the original request with the Bearer token embedded in
+   the request's Authorization header.
+6. The Registry authorizes the client by validating the Bearer token and the
+   claim set embedded within it and begins the push/pull session as usual.
+
+## Requirements
+
+- Registry clients which can understand and respond to token auth challenges
+  returned by the resource server.
+- An authorization server capable of managing access controls to their
+  resources hosted by any given service (such as repositories in a Docker
+  Registry).
+- A Docker Registry capable of trusting the authorization server to sign tokens
+  which clients can use for authorization and the ability to verify these
+  tokens for single use or for use during a sufficiently short period of time.
+
+## Authorization server endpoint descriptions
+
+The described server is meant to serve as a standalone access control manager
+for resources hosted by other services which want to authenticate and manage
+authorizations using a separate access control manager.
+
+A service like this is used by the official Docker Registry to authenticate
+clients and verify their authorization to Docker image repositories.
+
+As of Docker 1.6, the registry client within the Docker Engine has been updated
+to handle such an authorization workflow.
+
+## How to authenticate
+
+Registry V1 clients first contact the index to initiate a push or pull. Under
+the Registry V2 workflow, clients should contact the registry first. If the
+registry server requires authentication it will return a `401 Unauthorized`
+response with a `WWW-Authenticate` header detailing how to authenticate to this
+registry.
+
+For example, say I (username `jlhawn`) am attempting to push an image to the
+repository `samalba/my-app`. For the registry to authorize this, I will need
+`push` access to the `samalba/my-app` repository. The registry will first
+return this response:
+
+```text
+HTTP/1.1 401 Unauthorized
+Content-Type: application/json; charset=utf-8
+Docker-Distribution-Api-Version: registry/2.0
+Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:samalba/my-app:pull,push"
+Date: Thu, 10 Sep 2015 19:32:31 GMT
+Content-Length: 235
+Strict-Transport-Security: max-age=31536000
+
+{"errors":[{"code":"UNAUTHORIZED","message":"access to the requested resource is not authorized","detail":[{"Type":"repository","Name":"samalba/my-app","Action":"pull"},{"Type":"repository","Name":"samalba/my-app","Action":"push"}]}]}
+```
+
+Note the HTTP Response Header indicating the auth challenge:
+
+```text
+Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:samalba/my-app:pull,push"
+```
+
+This format is documented in [Section 3 of RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-3)
+
+This challenge indicates that the registry requires a token issued by the
+specified token server and that the request the client is attempting will
+need to include sufficient access entries in its claim set. To respond to this
+challenge, the client will need to make a `GET` request to the URL
+`https://auth.docker.io/token` using the `service` and `scope` values from the
+`WWW-Authenticate` header.
+
+## Requesting a token
+
+Defines getting a bearer and refresh token using the token endpoint.
+
+### Query parameters
+
+#### `service`
+
+The name of the service which hosts the resource.
+
+#### `offline_token`
+
+Whether to return a refresh token along with the bearer token. A refresh token
+is capable of getting additional bearer tokens for the same subject with
+different scopes. The refresh token does not have an expiration and should be
+considered completely opaque to the client.
+
+#### `client_id`
+
+String identifying the client. This `client_id` does not need to be registered
+with the authorization server but should be set to a meaningful value in order
+to allow auditing keys created by unregistered clients. Accepted syntax is
+defined in [RFC6749 Appendix
+A.1](https://tools.ietf.org/html/rfc6749#appendix-A.1).
+
+#### `scope`
+
+The resource in question, formatted as one of the space-delimited entries from
+the `scope` parameters from the `WWW-Authenticate` header shown previously. This
+query parameter should be specified multiple times if there is more than one
+`scope` entry from the `WWW-Authenticate` header. The previous example would be
+specified as: `scope=repository:samalba/my-app:push`. The scope field may be
+empty to request a refresh token without providing any resource permissions to
+the returned bearer token.
+
+### Token response fields
+
+#### `token`
+
+An opaque `Bearer` token that clients should supply to subsequent
+requests in the `Authorization` header.
+
+#### `access_token`
+
+For compatibility with OAuth 2.0, the `token` under the name `access_token` is
+also accepted. At least one of these fields must be specified, but both may
+also appear (for compatibility with older clients). When both are specified,
+they should be equivalent; if they differ the client's choice is undefined.
+
+#### `expires_in`
+
+(Optional) The duration in seconds since the token was issued that it will
+remain valid. When omitted, this defaults to 60 seconds. For compatibility
+with older clients, a token should never be returned with less than 60 seconds
+to live.
+
+#### `issued_at`
+
+(Optional) The [RFC3339](https://www.ietf.org/rfc/rfc3339.txt)-serialized UTC
+standard time at which a given token was issued. If `issued_at` is omitted, the
+expiration is from when the token exchange completed.
+
+#### `refresh_token`
+
+(Optional) Token which can be used to get additional access tokens for
+the same subject with different scopes. This token should be kept secure
+by the client and only sent to the authorization server which issues
+bearer tokens. This field will only be set when `offline_token=true` is
+provided in the request.
+
+### Example
+
+For this example, the client makes an HTTP GET request to the following URL:
+
+```text
+https://auth.docker.io/token?service=registry.docker.io&scope=repository:samalba/my-app:pull,push
+```
+
+The token server should first attempt to authenticate the client using any
+authentication credentials provided with the request. From Docker 1.11 the
+Docker Engine supports both Basic Authentication and OAuth2 for
+getting tokens. Docker 1.10 and before, the registry client in the Docker Engine
+only supports Basic Authentication. If an attempt to authenticate to the token
+server fails, the token server should return a `401 Unauthorized` response
+indicating that the provided credentials are invalid.
+
+Whether the token server requires authentication is up to the policy of that
+access control provider. Some requests may require authentication to determine
+access (such as pushing or pulling a private repository) while others may not
+(such as pulling from a public repository).
+
+After authenticating the client (which may simply be an anonymous client if
+no attempt was made to authenticate), the token server must next query its
+access control list to determine whether the client has the requested scope. In
+this example request, if I have authenticated as user `jlhawn`, the token
+server will determine what access I have to the repository `samalba/my-app`
+hosted by the entity `registry.docker.io`.
+
+Once the token server has determined what access the client has to the
+resources requested in the `scope` parameter, it will take the intersection of
+the set of requested actions on each resource and the set of actions that the
+client has in fact been granted. If the client only has a subset of the
+requested access **it must not be considered an error** as it is not the
+responsibility of the token server to indicate authorization errors as part of
+this workflow.
+
+Continuing with the example request, the token server will find that the
+client's set of granted access to the repository is `[pull, push]` which when
+intersected with the requested access `[pull, push]` yields an equal set. If
+the granted access set was found only to be `[pull]` then the intersected set
+would only be `[pull]`. If the client has no access to the repository then the
+intersected set would be empty, `[]`.
+
+It is this intersected set of access which is placed in the returned token.
+
+The server then constructs an implementation-specific token with this
+intersected set of access, and returns it to the Docker client to use to
+authenticate to the audience service (within the indicated window of time):
+
+```text
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+{"token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IlBZWU86VEVXVTpWN0pIOjI2SlY6QVFUWjpMSkMzOlNYVko6WEdIQTozNEYyOjJMQVE6WlJNSzpaN1E2In0.eyJpc3MiOiJhdXRoLmRvY2tlci5jb20iLCJzdWIiOiJqbGhhd24iLCJhdWQiOiJyZWdpc3RyeS5kb2NrZXIuY29tIiwiZXhwIjoxNDE1Mzg3MzE1LCJuYmYiOjE0MTUzODcwMTUsImlhdCI6MTQxNTM4NzAxNSwianRpIjoidFlKQ08xYzZjbnl5N2tBbjBjN3JLUGdiVjFIMWJGd3MiLCJhY2Nlc3MiOlt7InR5cGUiOiJyZXBvc2l0b3J5IiwibmFtZSI6InNhbWFsYmEvbXktYXBwIiwiYWN0aW9ucyI6WyJwdXNoIl19XX0.QhflHPfbd6eVF4lM9bwYpFZIV0PfikbyXuLx959ykRTBpe3CYnzs6YBK8FToVb5R47920PVLrh8zuLzdCr9t3w", "expires_in": 3600,"issued_at": "2009-11-10T23:00:00Z"}
+```
+
+## Using the Bearer token
+
+Once the client has a token, it will try the registry request again with the
+token placed in the HTTP `Authorization` header like so:
+
+```text
+Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IkJWM0Q6MkFWWjpVQjVaOktJQVA6SU5QTDo1RU42Ok40SjQ6Nk1XTzpEUktFOkJWUUs6M0ZKTDpQT1RMIn0.eyJpc3MiOiJhdXRoLmRvY2tlci5jb20iLCJzdWIiOiJCQ0NZOk9VNlo6UUVKNTpXTjJDOjJBVkM6WTdZRDpBM0xZOjQ1VVc6NE9HRDpLQUxMOkNOSjU6NUlVTCIsImF1ZCI6InJlZ2lzdHJ5LmRvY2tlci5jb20iLCJleHAiOjE0MTUzODczMTUsIm5iZiI6MTQxNTM4NzAxNSwiaWF0IjoxNDE1Mzg3MDE1LCJqdGkiOiJ0WUpDTzFjNmNueXk3a0FuMGM3cktQZ2JWMUgxYkZ3cyIsInNjb3BlIjoiamxoYXduOnJlcG9zaXRvcnk6c2FtYWxiYS9teS1hcHA6cHVzaCxwdWxsIGpsaGF3bjpuYW1lc3BhY2U6c2FtYWxiYTpwdWxsIn0.Y3zZSwaZPqy4y9oRBVRImZyv3m_S9XDHF1tWwN7mL52C_IiA73SJkWVNsvNqpJIn5h7A2F8biv_S2ppQ1lgkbw
+```
+
+This is also described in [Section 2.1 of RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-2.1)
\ No newline at end of file
diff --git a/content/reference/api/registry/images/v2-registry-auth.png b/content/reference/api/registry/images/v2-registry-auth.png
new file mode 100644
index 000000000000..0ea8a4205bc3
Binary files /dev/null and b/content/reference/api/registry/images/v2-registry-auth.png differ
diff --git a/content/reference/api/registry/latest.md b/content/reference/api/registry/latest.md
new file mode 100644
index 000000000000..7df6e5971659
--- /dev/null
+++ b/content/reference/api/registry/latest.md
@@ -0,0 +1,7 @@
+---
+layout: api
+title: Supported registry API for Docker Hub
+linktitle: Latest
+description: "Supported registry API endpoints."
+keywords: registry, on-prem, images, tags, repository, distribution, api, advanced
+---
diff --git a/content/reference/api/registry/latest.yaml b/content/reference/api/registry/latest.yaml
new file mode 100644
index 000000000000..445cc7f98f95
--- /dev/null
+++ b/content/reference/api/registry/latest.yaml
@@ -0,0 +1,1353 @@
+openapi: 3.0.3
+info:
+  title: Supported registry API for Docker Hub
+  description: |
+    Docker Hub is an OCI-compliant registry, which means it adheres to the open
+    standards defined by the Open Container Initiative (OCI) for distributing
+    container images. This ensures compatibility with a wide range of tools and
+    platforms in the container ecosystem.
+
+    This reference documents the Docker Hub-supported subset of the Registry HTTP API V2.
+    It focuses on pulling, pushing, and deleting images. It does not cover the full OCI Distribution Specification.
+
+    For the complete OCI specification, see [OCI Distribution Specification](https://github.com/opencontainers/distribution-spec).
+servers:
+  - description: Docker Hub registry API
+    x-audience: public
+    url: https://registry-1.docker.io
+
+tags:
+  - name: overview
+    x-displayName: Overview
+    description: |
+      All endpoints in this API are prefixed by the version and repository name, for example:
+
+      ```
+      /v2/<name>/
+      ```
+
+      This format provides structured access control and URI-based scoping of image operations.
+
+      For example, to interact with the `library/ubuntu` repository, use:
+
+      ```
+      /v2/library/ubuntu/
+      ```
+
+      Repository names must meet these requirements:
+      1. Consist of path components matching `[a-z0-9]+(?:[._-][a-z0-9]+)*`
+      2. If more than one component, they must be separated by `/`
+      3. Full repository name must be fewer than 256 characters
+
+
+  - name: authentication
+    x-displayName: Authentication
+    description: |
+      Specifies registry authentication.
+    externalDocs:
+      description: Detailed authentication workflow and token usage
+      url: https://docs.docker.com/reference/api/registry/auth/
+
+  - name: Manifests
+    x-displayName: Manifests
+    description: |
+      Image manifests are JSON documents that describe an image: its configuration blob, the digests of each layer blob, and metadata such as media‑types and annotations.
+
+  - name: Blobs
+    x-displayName: Blobs
+    description: |
+      Blobs are the binary objects referenced from manifests:
+      the config JSON and one or more compressed layer tarballs.
+
+  - name: pull
+    x-displayName: Pulling Images
+    description: |
+      Pulling an image involves retrieving the manifest and downloading each of the image's layer blobs. This section outlines the general steps followed by a working example.
+
+      1. [Get a bearer token for the repository](https://docs.docker.com/reference/api/registry/auth/).
+      2. [Get the image manifest](#operation/GetImageManifest).
+      3. If the response in the previous step is a multi-architecture manifest list, you must do the following:
+         - Parse the `manifests[]` array to locate the digest for your target platform (e.g., `linux/amd64`).
+         - [Get the image manifest](#operation/GetImageManifest) using the located digest.
+      4. [Check if the blob exists](#operation/CheckBlobExists) before downloading. The client should send a `HEAD` request for each layer digest.
+      5. [Download each layer blob](#operation/GetBlob) using the digest obtained from the manifest. The client should send a `GET` request for each layer digest.
+
+      The following bash script example pulls `library/ubuntu:latest` from Docker Hub.
+
+      ```bash
+      #!/bin/bash
+
+      # Step 1: Get a bearer token
+      TOKEN=$(curl -s "https://auth.docker.io/token?service=registry.docker.io&scope=repository:library/ubuntu:pull" | jq -r .token)
+  
+      # Step 2: Get the image manifest. In this example, an image manifest list is returned.
+      curl -s -H "Authorization: Bearer $TOKEN" \
+           -H "Accept: application/vnd.docker.distribution.manifest.list.v2+json" \
+           https://registry-1.docker.io/v2/library/ubuntu/manifests/latest \
+           -o manifest-list.json
+  
+      # Step 3a: Parse the `manifests[]` array to locate the digest for your target platform (e.g., `linux/amd64`).
+      IMAGE_MANIFEST_DIGEST=$(jq -r '.manifests[] | select(.platform.architecture == "amd64" and .platform.os == "linux") | .digest' manifest-list.json)
+  
+      # Step 3b: Get the platform-specific image manifest
+      curl -s -H "Authorization: Bearer $TOKEN" \
+           -H "Accept: application/vnd.docker.distribution.manifest.v2+json" \
+           https://registry-1.docker.io/v2/library/ubuntu/manifests/$IMAGE_MANIFEST_DIGEST \
+           -o manifest.json
+  
+      # Step 4: Send a HEAD request to check if the layer blob exists
+      DIGEST=$(jq -r '.layers[0].digest' manifest.json)
+      curl -I -H "Authorization: Bearer $TOKEN" \
+           https://registry-1.docker.io/v2/library/ubuntu/blobs/$DIGEST
+  
+      # Step 5: Download the layer blob
+      curl -L -H "Authorization: Bearer $TOKEN" \
+           https://registry-1.docker.io/v2/library/ubuntu/blobs/$DIGEST
+      ```
+    
+      This example pulls the manifest and the first layer for the `ubuntu:latest` image on the `linux/amd64` platform. Repeat steps 4 and 5 for each digest in the `.layers[]` array in the manifest.
+
+
+  - name: push
+    x-displayName: Pushing Images
+    description: |
+      Pushing an image involves uploading any image blobs (such as the config or layers), and then uploading the manifest that references those blobs.
+  
+      This section outlines the basic steps to push an image using the registry API.
+  
+      1. [Get a bearer token for the repository](https://docs.docker.com/reference/api/registry/auth/)
+  
+      2. [Check if the blob exists](#operation/CheckBlobExists) using a `HEAD` request for each blob digest.
+  
+      3. If the blob does not exist, [upload the blob](#operation/CompleteBlobUpload) using a monolithic `PUT` request:
+          - First, [initiate the upload](#operation/InitiateBlobUpload) with `POST`.
+          - Then [upload and complete](#operation/CompleteBlobUpload) with `PUT`.
+
+          **Note**:  Alternatively, you can upload the blob in multiple chunks by using `PATCH` requests to send each chunk, followed by a final `PUT` request to complete the upload. This is known as a [chunked upload](#operation/UploadBlobChunk) and is useful for large blobs or when resuming interrupted uploads.
+
+  
+      4. [Upload the image manifest](#operation/PutImageManifest) using a `PUT` request to associate the config and layers.
+  
+      The following bash script example pushes a dummy config blob and manifest to `yourusername/helloworld:latest` on Docker Hub. You can replace `yourusername` with your Docker Hub username and `dckr_pat` with your Docker Hub personal access token.
+  
+      ```bash
+      #!/bin/bash
+  
+      USERNAME=yourusername
+      PASSWORD=dckr_pat
+      REPO=yourusername/helloworld
+      TAG=latest
+      CONFIG=config.json
+      MIME_TYPE=application/vnd.docker.container.image.v1+json
+  
+      # Step 1: Get a bearer token
+      TOKEN=$(curl -s -u "$USERNAME:$PASSWORD" \
+      "https://auth.docker.io/token?service=registry.docker.io&scope=repository:$REPO:push,pull" \
+      | jq -r .token)
+  
+      # Create a dummy config blob and compute its digest
+      echo '{"architecture":"amd64","os":"linux","config":{},"rootfs":{"type":"layers","diff_ids":[]}}' > $CONFIG
+      DIGEST="sha256:$(sha256sum $CONFIG | awk '{print $1}')"
+  
+      # Step 2: Check if the blob exists
+      STATUS=$(curl -s -o /dev/null -w "%{http_code}" -I \
+        -H "Authorization: Bearer $TOKEN" \
+        https://registry-1.docker.io/v2/$REPO/blobs/$DIGEST)
+  
+      if [ "$STATUS" != "200" ]; then
+        # Step 3: Upload blob using monolithic upload
+        LOCATION=$(curl -sI -X POST \
+          -H "Authorization: Bearer $TOKEN" \
+          https://registry-1.docker.io/v2/$REPO/blobs/uploads/ \
+          | grep -i Location | tr -d '\r' | awk '{print $2}')
+  
+        curl -s -X PUT "$LOCATION&digest=$DIGEST" \
+          -H "Authorization: Bearer $TOKEN" \
+          -H "Content-Type: application/octet-stream" \
+          --data-binary @$CONFIG
+      fi
+  
+      # Step 4: Upload the manifest that references the config blob
+      MANIFEST=$(cat <<EOF
+      {
+        "schemaVersion": 2,
+        "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
+        "config": {
+          "mediaType": "$MIME_TYPE",
+          "size": $(stat -c%s $CONFIG),
+          "digest": "$DIGEST"
+        },
+        "layers": []
+      }
+      EOF
+      )
+
+      curl -s -X PUT \
+        -H "Authorization: Bearer $TOKEN" \
+        -H "Content-Type: application/vnd.docker.distribution.manifest.v2+json" \
+        -d "$MANIFEST" \
+        https://registry-1.docker.io/v2/$REPO/manifests/$TAG
+  
+      echo "Pushed image to $REPO:$TAG"
+      ```
+
+      This example pushes a minimal image with no layers. To push a complete image, repeat steps 2–3 for each layer and include the layer digests in the `layers[]` field of the manifest.
+
+  - name: delete
+    x-displayName: Deleting Images
+    description: |
+      Deleting an image involves removing its manifest by digest. You must first retrieve the manifest digest, then issue a `DELETE` request using that digest.
+
+      Only untagged manifests (or those not referenced by other tags or images) can be deleted. If a manifest is still referenced, the registry returns `403 Forbidden`.
+
+      > **Note**
+      >
+      > Manifest deletion operations may experience latency and could return a `500 Internal Server Error` during deletion. The system automatically retries the deletion in the background, so the manifest will eventually be removed. You do not need to manually retry the request.
+
+      This section outlines the basic steps to delete an image using the registry API.
+
+      1. [Get a bearer token for the repository](https://docs.docker.com/reference/api/registry/auth/).
+      2. [Get the manifest](#operation/GetImageManifest) using the image's tag.
+      3. Retrieve the `Docker-Content-Digest` header from the manifest response. This digest uniquely identifies the manifest.
+      4. [Delete the manifest](#operation/DeleteImageManifest) using a `DELETE` request and the digest.
+
+      The following bash script example deletes the `latest` tag from `yourusername/helloworld` on Docker Hub. Replace `yourusername` with your Docker Hub username and `dckr_pat` with your Docker Hub personal access token.
+
+      ```bash
+      #!/bin/bash
+  
+      USERNAME=yourusername
+      PASSWORD=dckr_pat
+      REPO=yourusername/helloworld
+      TAG=latest
+  
+      # Step 1: Get a bearer token
+      TOKEN=$(curl -s -u "$USERNAME:$PASSWORD" \
+        "https://auth.docker.io/token?service=registry.docker.io&scope=repository:$REPO:pull,push,delete" \
+        | jq -r .token)
+  
+      # Step 2 and 3: Get the manifest and extract the digest from response headers
+      DIGEST=$(curl -sI -H "Authorization: Bearer $TOKEN" \
+        -H "Accept: application/vnd.docker.distribution.manifest.v2+json" \
+        https://registry-1.docker.io/v2/$REPO/manifests/$TAG \
+        | grep -i Docker-Content-Digest | tr -d '\r' | awk '{print $2}')
+  
+      echo "Deleting manifest with digest: $DIGEST"
+  
+      # Step 4: Delete the manifest by digest
+      curl -s -X DELETE \
+        -H "Authorization: Bearer $TOKEN" \
+        https://registry-1.docker.io/v2/$REPO/manifests/$DIGEST
+  
+      echo "Deleted image: $REPO@$DIGEST"
+      ```
+  
+      This example deletes the manifest for the `latest` tag. To fully delete all references to an image, ensure no other tags or referrers point to the same manifest digest.
+
+
+paths:
+  /v2/{name}/manifests/{reference}:
+    get:
+      tags:
+        - Manifests
+      x-displayName: Manifests
+      summary: Get image manifest
+      operationId: GetImageManifest
+      description: |
+        Fetch the manifest identified by `name` and `reference`, where `reference` can be a tag (e.g., `latest`) or a digest (e.g., `sha256:...`).
+
+        The manifest contains metadata about the image, including configuration and layer digests. It is required for pulling images from the registry.
+
+        This endpoint requires authentication. Use the `Authorization: Bearer <token>` header.
+  
+      x-codeSamples:
+        - lang: Bash
+          label: cURL
+          source: |
+            # GET a manifest (by tag or digest)
+            curl -H "Authorization: Bearer $TOKEN" \
+                 -H "Accept: application/vnd.docker.distribution.manifest.v2+json" \
+                 https://registry-1.docker.io/v2/library/ubuntu/manifests/latest
+      parameters:
+        - name: name
+          in: path
+          required: true
+          description: Name of the target repository
+          example: library/ubuntu
+          schema:
+            type: string
+        - name: reference
+          in: path
+          required: true
+          description: Tag or digest of the target manifest
+          examples:
+            by-tag:
+              summary: Tag
+              value: latest
+            by-digest:
+              summary: Digest
+              value: sha256:abc123def456...
+          schema:
+            type: string
+        - name: Authorization
+          in: header
+          required: true
+          description: RFC7235-compliant authorization header (e.g., `Bearer <token>`).
+          schema:
+            type: string
+        - name: Accept
+          in: header
+          required: false
+          description: |
+            Media type(s) the client supports for the manifest.
+        
+            The registry supports the following media types:
+            - application/vnd.docker.distribution.manifest.v2+json
+            - application/vnd.docker.distribution.manifest.list.v2+json
+            - application/vnd.oci.image.manifest.v1+json
+            - application/vnd.oci.image.index.v1+json
+          schema:
+            type: string
+
+      responses:
+        "200":
+          description: Manifest fetched successfully.
+          headers:
+            Docker-Content-Digest:
+              description: Digest of the returned manifest content.
+              schema:
+                type: string
+            Content-Type:
+              description: Media type of the returned manifest.
+              schema:
+                type: string
+          content:
+            application/vnd.docker.distribution.manifest.v2+json:
+              schema:
+                type: object
+                required:
+                  - schemaVersion
+                  - mediaType
+                  - config
+                  - layers
+                properties:
+                  schemaVersion:
+                    type: integer
+                    example: 2
+                  mediaType:
+                    type: string
+                    example: application/vnd.docker.distribution.manifest.v2+json
+                  config:
+                    type: object
+                    properties:
+                      mediaType:
+                        type: string
+                        example: application/vnd.docker.container.image.v1+json
+                      size:
+                        type: integer
+                        example: 7023
+                      digest:
+                        type: string
+                        example: sha256:a3f3e...c1234
+                  layers:
+                    type: array
+                    items:
+                      type: object
+                      properties:
+                        mediaType:
+                          type: string
+                          example: application/vnd.docker.image.rootfs.diff.tar.gzip
+                        size:
+                          type: integer
+                          example: 32654
+                        digest:
+                          type: string
+                          example: sha256:bcf2...78901
+              examples:
+                docker-manifest:
+                  summary: Docker image manifest (schema v2)
+                  value:
+                    {
+                      "schemaVersion": 2,
+                      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
+                      "config": {
+                        "mediaType": "application/vnd.docker.container.image.v1+json",
+                        "size": 7023,
+                        "digest": "sha256:123456abcdef..."
+                      },
+                      "layers": [
+                        {
+                          "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
+                          "size": 32654,
+                          "digest": "sha256:abcdef123456..."
+                        },
+                        {
+                          "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
+                          "size": 16724,
+                          "digest": "sha256:7890abcdef12..."
+                        }
+                      ]
+                    }
+
+        "400":
+          description: Invalid name or reference.
+        "401":
+          description: Authentication required.
+        "403":
+          description: Access denied.
+        "404":
+          description: Repository or manifest not found.
+        "429":
+          description: Too many requests.
+
+
+    put:
+      tags:
+        - Manifests
+      summary: Put image manifest
+      operationId: PutImageManifest
+      description: |
+        Upload an image manifest for a given tag or digest. This operation registers a manifest in a repository, allowing it to be pulled using the specified reference.
+
+        This endpoint is typically used after all layer and config blobs have been uploaded to the registry.
+
+        The manifest must conform to the expected schema and media type. For Docker image manifest schema version 2, use:
+        `application/vnd.docker.distribution.manifest.v2+json`
+
+        Requires authentication via a bearer token with `push` scope for the target repository.
+      x-codeSamples:
+        - lang: Bash
+          label: cURL
+          source: |
+            # PUT a manifest (tag = latest)
+            curl -X PUT \
+              -H "Authorization: Bearer $TOKEN" \
+              -H "Content-Type: application/vnd.docker.distribution.manifest.v2+json" \
+              --data-binary @manifest.json \
+              https://registry-1.docker.io/v2/library/ubuntu/manifests/latest
+      parameters:
+        - name: name
+          in: path
+          required: true
+          description: Name of the target Repository
+          example: library/ubuntu
+          schema:
+            type: string
+        - name: reference
+          in: path
+          required: true
+          description: Tag or digest to associate with the uploaded Manifest
+          examples:
+            by-tag:
+              summary: Tag
+              value: latest
+            by-digest:
+              summary: Digest
+              value: sha256:abc123def456...
+          schema:
+            type: string
+        - name: Authorization
+          in: header
+          required: true
+          description: RFC7235-compliant authorization header (e.g., `Bearer <token>`).
+          schema:
+            type: string
+        - name: Content-Type
+          in: header
+          required: true
+          description: Media type of the manifest being uploaded.
+          schema:
+            type: string
+            example: application/vnd.docker.distribution.manifest.v2+json
+
+      requestBody:
+        required: true
+        content:
+          application/vnd.docker.distribution.manifest.v2+json:
+            schema:
+              type: object
+              required:
+                - schemaVersion
+                - mediaType
+                - config
+                - layers
+              properties:
+                schemaVersion:
+                  type: integer
+                  example: 2
+                mediaType:
+                  type: string
+                  example: application/vnd.docker.distribution.manifest.v2+json
+                config:
+                  type: object
+                  required:
+                    - mediaType
+                    - size
+                    - digest
+                  properties:
+                    mediaType:
+                      type: string
+                      example: application/vnd.docker.container.image.v1+json
+                    size:
+                      type: integer
+                      example: 7023
+                    digest:
+                      type: string
+                      example: sha256:123456abcdef...
+                layers:
+                  type: array
+                  items:
+                    type: object
+                    required:
+                      - mediaType
+                      - size
+                      - digest
+                    properties:
+                      mediaType:
+                        type: string
+                        example: application/vnd.docker.image.rootfs.diff.tar.gzip
+                      size:
+                        type: integer
+                        example: 32654
+                      digest:
+                        type: string
+                        example: sha256:abcdef123456...
+
+            examples:
+              sample-manifest:
+                summary: Sample Docker image manifest (schema v2)
+                value:
+                  {
+                    "schemaVersion": 2,
+                    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
+                    "config": {
+                      "mediaType": "application/vnd.docker.container.image.v1+json",
+                      "size": 7023,
+                      "digest": "sha256:123456abcdef..."
+                    },
+                    "layers": [
+                      {
+                        "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
+                        "size": 32654,
+                        "digest": "sha256:abcdef123456..."
+                      }
+                    ]
+                  }
+
+      responses:
+        "201":
+          description: Manifest created successfully.
+          headers:
+            Docker-Content-Digest:
+              description: Digest of the stored manifest.
+              schema:
+                type: string
+              example: sha256:abcdef123456...
+            Location:
+              description: Canonical location of the uploaded manifest.
+              schema:
+                type: string
+              example: /v2/library/ubuntu/manifests/latest
+            Content-Length:
+              description: Always zero.
+              schema:
+                type: integer
+              example: 0
+        "400":
+          description: Invalid name, reference, or manifest.
+        "401":
+          description: Authentication required.
+        "403":
+          description: Access denied.
+        "404":
+          description: Repository not found.
+        "405":
+          description: Operation not allowed.
+        "429":
+          description: Too many requests.
+    head:
+      tags:
+        - Manifests
+      summary: Check if manifest exists
+      operationId: HeadImageManifest
+      description: |
+        Use this endpoint to verify whether a manifest exists by tag or digest.
+
+        This is a lightweight operation that returns only headers (no body). It is useful for:
+        - Checking for the existence of a specific image version
+        - Determining the digest or size of a manifest before downloading or deleting
+
+        This endpoint requires authentication with pull scope.
+
+      parameters:
+        - name: name
+          in: path
+          required: true
+          description: Name of the Repository
+          example: library/ubuntu
+          schema:
+            type: string
+        - name: reference
+          in: path
+          required: true
+          description: Tag or digest to check
+          examples:
+            by-tag:
+              summary: Tag
+              value: latest
+            by-digest:
+              summary: Digest
+              value: sha256:abc123def456...
+          schema:
+            type: string
+        - name: Authorization
+          in: header
+          required: true
+          schema:
+            type: string
+          description: Bearer token for authentication
+        - name: Accept
+          in: header
+          required: false
+          schema:
+            type: string
+            example: application/vnd.docker.distribution.manifest.v2+json
+          description: |
+            Media type of the manifest to check. The response will match one of the accepted types.
+      x-codeSamples:
+        - lang: Bash
+          label: cURL
+          source: |
+            # HEAD /v2/{name}/manifests/{reference}
+            curl -I \
+              -H "Authorization: Bearer $TOKEN" \
+              -H "Accept: application/vnd.docker.distribution.manifest.v2+json" \
+              https://registry-1.docker.io/v2/library/ubuntu/manifests/latest
+      responses:
+        "200":
+          description: Manifest exists.
+          headers:
+            Content-Length:
+              description: Size of the manifest in bytes
+              schema:
+                type: integer
+              example: 7082
+            Docker-Content-Digest:
+              description: Digest of the manifest
+              schema:
+                type: string
+              example: sha256:abc123...
+            Content-Type:
+              description: Media type of the manifest
+              schema:
+                type: string
+              example: application/vnd.docker.distribution.manifest.v2+json
+        "404":
+          description: Manifest not found.
+        "401":
+          description: Authentication required.
+        "403":
+          description: Access denied.
+        "429":
+          description: Too many requests.
+    delete:
+      tags:
+        - Manifests
+      summary: Delete image manifest
+      operationId: DeleteImageManifest
+      description: |
+        Delete an image manifest from a repository by digest.
+
+        Only untagged or unreferenced manifests can be deleted. If the manifest is still referenced by a tag or another image, the registry will return `403 Forbidden`.
+
+        This operation requires `delete` access to the repository.
+
+        > **Note**
+        >
+        > Manifest deletion operations may take some time and could return a `500 Internal Server Error`. The system automatically retries the deletion in the background. Manual intervention is not required.
+      parameters:
+        - name: name
+          in: path
+          required: true
+          description: Name of the repository
+          example: yourusername/helloworld
+          schema:
+            type: string
+        - name: reference
+          in: path
+          required: true
+          description: Digest of the manifest to delete (e.g., `sha256:...`)
+          example: sha256:abc123def456...
+          schema:
+            type: string
+        - name: Authorization
+          in: header
+          required: true
+          description: Bearer token with `delete` access
+          schema:
+            type: string
+      x-codeSamples:
+        - lang: Bash
+          label: cURL
+          source: |
+            # DELETE a manifest by digest
+            curl -X DELETE \
+              -H "Authorization: Bearer $TOKEN" \
+              https://registry-1.docker.io/v2/yourusername/helloworld/manifests/sha256:abc123def456...
+      responses:
+        "202":
+          description: Manifest deleted successfully. No content returned.
+        "401":
+          description: Authentication required.
+        "403":
+          description: Access denied. The manifest may still be referenced.
+        "404":
+          description: Manifest or repository not found.
+        "405":
+          description: Only digest-based deletion is allowed.
+        "429":
+          description: Too many requests.
+  /v2/{name}/blobs/uploads/:
+    post:
+      tags:
+        - Blobs
+      summary: Initiate blob upload or attempt cross-repository blob mount
+      operationId: InitiateBlobUpload
+      description: |
+        Initiate an upload session for a blob (layer or config) in a repository.
+
+        This is the first step in uploading a blob. It returns a `Location` URL where the blob can be uploaded using `PATCH` (chunked) or `PUT` (monolithic).
+
+        Instead of uploading a blob, a client may attempt to mount a blob from another repository (if it has read access) by including the `mount` and `from` query parameters.
+
+        If successful, the registry responds with `201 Created` and the blob is reused without re-upload.
+
+        If the mount fails, the upload proceeds as usual and returns a `202 Accepted`.
+
+        You must authenticate with `push` access to the target repository.
+      x-codeSamples:
+        - lang: Bash
+          label: cURL (Initiate Standard Upload)
+          source: |
+            # Initiate a standard blob upload session
+            curl -i -X POST \
+              -H "Authorization: Bearer $TOKEN" \
+              https://registry-1.docker.io/v2/library/ubuntu/blobs/uploads/
+
+        - lang: Bash
+          label: cURL (Cross-Repository Blob Mount)
+          source: |
+            # Attempt a cross-repository blob mount
+            curl -i -X POST \
+              -H "Authorization: Bearer $TOKEN" \
+              "https://registry-1.docker.io/v2/library/ubuntu/blobs/uploads/?mount=sha256:abc123def456...&from=library/busybox"
+
+      parameters:
+        - name: name
+          in: path
+          required: true
+          description: Name of the target repository
+          example: library/ubuntu
+          schema:
+            type: string
+        - name: mount
+          in: query
+          required: false
+          description: Digest of the blob to mount from another repository
+          schema:
+            type: string
+          example: sha256:abc123def456...
+        - name: from
+          in: query
+          required: false
+          description: Source repository to mount the blob from
+          schema:
+            type: string
+          example: library/busybox
+        - name: Authorization
+          in: header
+          required: true
+          schema:
+            type: string
+          description: Bearer token for authentication with `push` scope
+
+      responses:
+        "201":
+          description: Blob successfully mounted from another repository.
+          headers:
+            Location:
+              description: URL where the mounted blob is accessible
+              schema:
+                type: string
+              example: /v2/library/ubuntu/blobs/sha256:abc123...
+            Docker-Content-Digest:
+              description: Canonical digest of the mounted blob
+              schema:
+                type: string
+              example: sha256:abc123...
+            Content-Length:
+              description: Always zero
+              schema:
+                type: integer
+              example: 0
+        "202":
+          description: Upload initiated successfully (fallback if mount fails).
+          headers:
+            Location:
+              description: Upload location URL for `PATCH` or `PUT` requests
+              schema:
+                type: string
+              example: /v2/library/ubuntu/blobs/uploads/abc123
+            Docker-Upload-UUID:
+              description: Server-generated UUID for the upload session
+              schema:
+                type: string
+              example: abc123
+            Range:
+              description: Current upload byte range (typically `0-0` at init)
+              schema:
+                type: string
+              example: 0-0
+            Content-Length:
+              description: Always zero
+              schema:
+                type: integer
+              example: 0
+        "401":
+          description: Authentication required.
+        "403":
+          description: Access denied.
+        "404":
+          description: Repository not found.
+        "429":
+          description: Too many requests.
+  /v2/{name}/blobs/{digest}:
+    head:
+      tags:
+        - Blobs
+      summary: Check existence of blob
+      operationId: CheckBlobExists
+      description: |
+        Check whether a blob (layer or config) exists in the registry.
+
+        This is useful before uploading a blob to avoid duplicates.
+
+        If the blob is present, the registry returns a `200 OK` response with headers like `Content-Length` and `Docker-Content-Digest`.
+
+        If the blob does not exist, the response will be `404 Not Found`.
+      x-codeSamples:
+        - lang: Bash
+          label: cURL
+          source: |
+            # HEAD to check if a blob exists
+            curl -I \
+              -H "Authorization: Bearer $TOKEN" \
+              https://registry-1.docker.io/v2/library/ubuntu/blobs/sha256:abc123...
+      parameters:
+        - name: name
+          in: path
+          required: true
+          description: Name of the Repository
+          example: library/ubuntu
+          schema:
+            type: string
+        - name: digest
+          in: path
+          required: true
+          description: Digest of the blob
+          schema:
+            type: string
+          example: sha256:abc123def4567890...
+        - name: Authorization
+          in: header
+          required: true
+          description: Bearer token with pull or push scope
+          schema:
+            type: string
+          example: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6...
+
+      responses:
+        "200":
+          description: Blob exists
+          headers:
+            Content-Length:
+              description: Size of the blob in bytes
+              schema:
+                type: integer
+              example: 32654
+            Docker-Content-Digest:
+              description: Digest of the blob
+              schema:
+                type: string
+              example: sha256:abc123def4567890...
+            Content-Type:
+              description: MIME type of the blob content
+              schema:
+                type: string
+              example: application/octet-stream
+          content:
+            application/json:
+              examples:
+                blob-check-request:
+                  summary: Sample request
+                  value:
+                    method: HEAD
+                    url: /v2/library/ubuntu/blobs/sha256:abc123def4567890...
+                    headers:
+                      Authorization: Bearer <token>
+                      Accept: '*/*'
+                blob-check-response:
+                  summary: Sample 200 response headers
+                  value:
+                    status: 200 OK
+                    headers:
+                      Docker-Content-Digest: sha256:abc123def4567890...
+                      Content-Length: 32654
+                      Content-Type: application/octet-stream
+
+        "404":
+          description: Blob not found
+        "401":
+          description: Authentication required
+        "403":
+          description: Access denied
+        "429":
+          description: Too many requests
+    get:
+      tags:
+        - Blobs
+      summary: Retrieve blob
+      operationId: GetBlob
+      description: |
+        Download the blob identified by digest from the registry.
+
+        Blobs include image layers and configuration objects. Clients must use the digest from the manifest to retrieve a blob.
+
+        This endpoint may return a `307 Temporary Redirect` to a CDN or storage location. Clients must follow the redirect to obtain the actual blob content.
+
+        The blob content is typically a gzipped tarball (for layers) or JSON (for configs). The MIME type is usually `application/octet-stream`.
+      x-codeSamples:
+        - lang: Bash
+          label: cURL
+          source: |
+            # GET (download) a blob
+            curl -L \
+              -H "Authorization: Bearer $TOKEN" \
+              https://registry-1.docker.io/v2/library/ubuntu/blobs/sha256:abc123... \
+              -o layer.tar.gz
+      parameters:
+        - name: name
+          in: path
+          required: true
+          description: Repository Name
+          example: library/ubuntu
+          schema:
+            type: string
+        - name: digest
+          in: path
+          required: true
+          description: Digest of the Blob
+          schema:
+            type: string
+          example: sha256:abc123def456...
+        - name: Authorization
+          in: header
+          required: true
+          schema:
+            type: string
+          description: Bearer token with pull scope
+          example: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6...
+
+      responses:
+        "200":
+          description: Blob content returned directly
+          headers:
+            Content-Length:
+              description: Size of the blob in bytes
+              schema:
+                type: integer
+              example: 32768
+            Content-Type:
+              description: MIME type of the blob
+              schema:
+                type: string
+              example: application/octet-stream
+            Docker-Content-Digest:
+              description: Digest of the returned blob
+              schema:
+                type: string
+              example: sha256:abc123def456...
+          content:
+            application/octet-stream:
+              schema:
+                type: string
+                format: binary
+              examples:
+                small-layer:
+                  summary: Example binary blob (gzipped tar layer)
+                  value: "<binary data not shown>"
+
+        "307":
+          description: Temporary redirect to blob location
+          headers:
+            Location:
+              description: Redirect URL for blob download (e.g., S3 or CDN)
+              schema:
+                type: string
+              example: https://cdn.docker.io/blobs/library/ubuntu/abc123...
+        "401":
+          description: Authentication required
+        "403":
+          description: Access denied
+        "404":
+          description: Blob not found
+        "429":
+          description: Too many requests
+  /v2/{name}/blobs/uploads/{uuid}:
+    get:
+      tags:
+        - Blobs
+      summary: Get blob upload status
+      operationId: GetBlobUploadStatus
+      description: |
+        Retrieve the current status of an in-progress blob upload.
+
+        This is useful for:
+        - Resuming an interrupted upload
+        - Determining how many bytes have been accepted so far
+        - Retrying from the correct offset in chunked uploads
+
+        The response includes the `Range` header indicating the byte range received so far, and a `Docker-Upload-UUID` for identifying the session.
+      x-codeSamples:
+        - lang: Bash
+          label: cURL
+          source: |
+            # GET upload status
+            curl -I \
+              -H "Authorization: Bearer $TOKEN" \
+              https://registry-1.docker.io/v2/library/ubuntu/blobs/uploads/abc123
+      parameters:
+        - name: name
+          in: path
+          required: true
+          description: Repository Name
+          example : library/ubuntu
+          schema:
+            type: string
+        - name: uuid
+          in: path
+          required: true
+          description: Upload session UUID
+          schema:
+            type: string
+          example: abc123
+        - name: Authorization
+          in: header
+          required: true
+          schema:
+            type: string
+          example: Bearer eyJhbGciOi...
+
+      responses:
+        "204":
+          description: Upload in progress. No body is returned.
+          headers:
+            Range:
+              description: Current byte range uploaded (inclusive)
+              schema:
+                type: string
+              example: 0-16383
+            Docker-Upload-UUID:
+              description: UUID of the upload session
+              schema:
+                type: string
+              example: abc123
+            Location:
+              description: URL to continue or complete the upload
+              schema:
+                type: string
+              example: /v2/library/ubuntu/blobs/uploads/abc123
+        "401":
+          description: Authentication required
+        "403":
+          description: Access denied
+        "404":
+          description: Upload session not found
+        "429":
+          description: Too many requests
+
+    put:
+      tags:
+        - Blobs
+      summary: Complete blob upload
+      operationId: CompleteBlobUpload
+      description: |
+        Complete the upload of a blob by finalizing an upload session.
+
+        This request must include the `digest` query parameter and optionally the last chunk of data. When the registry receives this request, it verifies the digest and stores the blob.
+
+        This endpoint supports:
+        - Monolithic uploads (upload entire blob in this request)
+        - Finalizing chunked uploads (last chunk plus `digest`)
+
+      x-codeSamples:
+        - lang: Bash
+          label: cURL
+          source: |
+            # PUT – complete upload (monolithic or final chunk)
+            curl -X PUT \
+              -H "Authorization: Bearer $TOKEN" \
+              -H "Content-Type: application/octet-stream" \
+              --data-binary @layer.tar.gz \
+              "https://registry-1.docker.io/v2/library/ubuntu/blobs/uploads/abc123?digest=sha256:abcd1234..."
+
+
+      parameters:
+        - name: name
+          in: path
+          required: true
+          description: Repository name
+          schema:
+            type: string
+          example: library/ubuntu
+        - name: uuid
+          in: path
+          required: true
+          description: Upload session UUID returned from the POST request
+          schema:
+            type: string
+          example: abc123
+        - name: digest
+          in: query
+          required: true
+          description: Digest of the uploaded blob
+          schema:
+            type: string
+          example: sha256:abcd1234...
+        - name: Authorization
+          in: header
+          required: true
+          schema:
+            type: string
+          example: Bearer eyJhbGciOi...
+
+      requestBody:
+        required: false
+        content:
+          application/octet-stream:
+            schema:
+              type: string
+              format: binary
+            examples:
+              layer-upload:
+                summary: Layer tarball blob
+                value: "<binary data not shown>"
+
+      responses:
+        "201":
+          description: Upload completed successfully
+          headers:
+            Docker-Content-Digest:
+              description: Canonical digest of the stored blob
+              schema:
+                type: string
+              example: sha256:abcd1234...
+            Location:
+              description: URL where the blob is now accessible
+              schema:
+                type: string
+              example: /v2/library/ubuntu/blobs/sha256:abcd1234...
+            Content-Length:
+              description: Always zero for completed uploads
+              schema:
+                type: integer
+              example: 0
+        "400":
+          description: Invalid digest or missing parameters
+        "401":
+          description: Authentication required
+        "403":
+          description: Access denied
+        "404":
+          description: Upload session not found
+        "416":
+          description: Requested range not satisfiable (if used in chunked mode)
+        "429":
+          description: Too many requests
+
+    patch:
+      tags:
+        - Blobs
+      summary: Upload blob chunk
+      operationId: UploadBlobChunk
+      description: |
+        Upload a chunk of a blob to an active upload session.
+
+        Use this method for **chunked uploads**, especially for large blobs or when resuming interrupted uploads.
+
+        The client sends binary data using `PATCH`, optionally including a `Content-Range` header.
+
+        After each chunk is accepted, the registry returns a `202 Accepted` response with:
+        - `Range`: current byte range stored
+        - `Docker-Upload-UUID`: identifier for the upload session
+        - `Location`: URL to continue the upload or finalize with `PUT`
+      x-codeSamples:
+        - lang: Bash
+          label: cURL
+          source: |
+            # PATCH – upload a chunk (first 64 KiB)
+            curl -X PATCH \
+              -H "Authorization: Bearer $TOKEN" \
+              -H "Content-Type: application/octet-stream" \
+              --data-binary @chunk-0.bin \
+              "https://registry-1.docker.io/v2/library/ubuntu/blobs/uploads/abc123"
+      parameters:
+        - name: name
+          in: path
+          required: true
+          description: Repository name
+          schema:
+            type: string
+          example: library/ubuntu
+        - name: uuid
+          in: path
+          required: true
+          description: Upload session UUID
+          schema:
+            type: string
+          example: abc123
+        - name: Authorization
+          in: header
+          required: true
+          schema:
+            type: string
+          example: Bearer eyJhbGciOi...
+        - name: Content-Range
+          in: header
+          required: false
+          schema:
+            type: string
+          example: bytes 0-65535
+          description: Optional. Byte range of the chunk being sent
+
+      requestBody:
+        required: true
+        content:
+          application/octet-stream:
+            schema:
+              type: string
+              format: binary
+            examples:
+              chunk-0:
+                summary: Upload chunk 0 of a blob
+                value: "<binary data not shown>"
+
+      responses:
+        "202":
+          description: Chunk accepted and stored
+          headers:
+            Location:
+              description: URL to continue or finalize the upload
+              schema:
+                type: string
+              example: /v2/library/ubuntu/blobs/uploads/abc123
+            Range:
+              description: Byte range uploaded so far (inclusive)
+              schema:
+                type: string
+              example: 0-65535
+            Docker-Upload-UUID:
+              description: Upload session UUID
+              schema:
+                type: string
+              example: abc123
+        "400":
+          description: Malformed content or range
+        "401":
+          description: Authentication required
+        "403":
+          description: Access denied
+        "404":
+          description: Upload session not found
+        "416":
+          description: Range error (e.g., chunk out of order)
+        "429":
+          description: Too many requests
+    delete:
+      tags:
+        - Blobs
+      summary: Cancel blob upload
+      operationId: CancelBlobUpload
+      description: |
+        Cancel an in-progress blob upload session.
+
+        This operation discards any data that has been uploaded and invalidates the upload session.
+
+        Use this when:
+        - An upload fails or is aborted mid-process
+        - The client wants to clean up unused upload sessions
+
+        After cancellation, the UUID is no longer valid and a new `POST` must be issued to restart the upload.
+
+      x-codeSamples:
+        - lang: Bash
+          label: cURL
+          source: |
+            # DELETE – cancel an upload session
+            curl -X DELETE \
+              -H "Authorization: Bearer $TOKEN" \
+              https://registry-1.docker.io/v2/library/ubuntu/blobs/uploads/abc123`
+
+      parameters:
+        - name: name
+          in: path
+          required: true
+          description: Name of the repository
+          schema:
+            type: string
+          example: library/ubuntu
+        - name: uuid
+          in: path
+          required: true
+          description: Upload session UUID
+          schema:
+            type: string
+          example: abc123
+        - name: Authorization
+          in: header
+          required: true
+          schema:
+            type: string
+          example: Bearer eyJhbGciOi...
+
+      responses:
+        "204":
+          description: Upload session cancelled successfully. No body is returned.
+          headers:
+            Content-Length:
+              description: Always zero
+              schema:
+                type: integer
+              example: 0
+        "401":
+          description: Authentication required
+        "403":
+          description: Access denied
+        "404":
+          description: Upload session not found
+        "429":
+          description: Too many requests
+
+
+x-tagGroups:
+  - name: General
+    tags:
+      - overview
+      - authentication
+      - pull
+      - push
+      - delete
+  - name: API
+    tags:
+      - Manifests
+      - Blobs
diff --git a/content/reference/cli/_content.gotmpl b/content/reference/cli/_content.gotmpl
new file mode 100644
index 000000000000..d54d0d9037f9
--- /dev/null
+++ b/content/reference/cli/_content.gotmpl
@@ -0,0 +1,80 @@
+{{- /*
+  Content adapter for CLI reference pages.
+
+  Generates pages from YAML data files in hugo.Data, replacing the ~386 stub
+  Markdown files that previously lived under content/reference/cli/docker/.
+
+  For each data file it creates a page at the command path (spaces → slashes).
+  Files with `cname` (subcommands list) become Hugo sections; others become
+  regular pages.
+
+  Skips:
+  - Alias/shortcut commands — if any alias is longer (more words) than the
+    command itself, a canonical version exists elsewhere (e.g. `docker ps`
+    is a shortcut for `docker container ls`).
+  - Hidden commands (hidden: true in the YAML).
+
+  Also creates 8 sidebar-redirect pages for common shortcuts (ps, run, …)
+  so they still appear in the sidebar navigation.
+*/ -}}
+
+{{- range $folder, $files := hugo.Data.cli -}}
+  {{- range $name, $data := $files -}}
+    {{- /* Skip hidden commands */ -}}
+    {{- if $data.hidden -}}
+      {{- continue -}}
+    {{- end -}}
+
+    {{- /* Skip alias/shortcut commands: if any alias has more words than
+           the command, a longer canonical form exists elsewhere. */ -}}
+    {{- $cmdWords := len (split $data.command " ") -}}
+    {{- $isAlias := false -}}
+    {{- with $data.aliases -}}
+      {{- range (split . ", ") -}}
+        {{- if gt (len (split . " ")) $cmdWords -}}
+          {{- $isAlias = true -}}
+        {{- end -}}
+      {{- end -}}
+    {{- end -}}
+    {{- if $isAlias -}}
+      {{- continue -}}
+    {{- end -}}
+
+    {{- $path := replace $data.command " " "/" -}}
+    {{- $kind := "page" -}}
+    {{- with $data.cname -}}
+      {{- $kind = "section" -}}
+    {{- end -}}
+
+    {{- $.AddPage (dict
+      "path" $path
+      "title" $data.command
+      "kind" $kind
+      "params" (dict "datafolder" $folder "datafile" $name)
+    ) -}}
+  {{- end -}}
+{{- end -}}
+
+{{- /* Sidebar redirect pages for common shortcuts.
+       These aren't rendered — they exist so the sidebar can display entries
+       like "docker ps" linking to the canonical page. */ -}}
+{{- $redirects := dict
+  "docker/ps"     "/reference/cli/docker/container/ls/"
+  "docker/run"    "/reference/cli/docker/container/run/"
+  "docker/exec"   "/reference/cli/docker/container/exec/"
+  "docker/build"  "/reference/cli/docker/buildx/build/"
+  "docker/images" "/reference/cli/docker/image/ls/"
+  "docker/pull"   "/reference/cli/docker/image/pull/"
+  "docker/push"   "/reference/cli/docker/image/push/"
+  "docker/info"   "/reference/cli/docker/system/info/"
+-}}
+
+{{- range $path, $goto := $redirects -}}
+  {{- $title := replace $path "/" " " -}}
+  {{- $.AddPage (dict
+    "path" $path
+    "title" $title
+    "params" (dict "sidebar" (dict "goto" $goto))
+    "build" (dict "render" "link" "list" "always")
+  ) -}}
+{{- end -}}
diff --git a/content/reference/cli/docker/README.md b/content/reference/cli/docker/README.md
deleted file mode 100644
index 4fcc5bb1c6a6..000000000000
--- a/content/reference/cli/docker/README.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-_build:
-  list: never
-  publishResources: false
-  render: never
----
-
-# About these files
-
-The files in this directory are stub files which include the file
-`/_includes/cli.md`, which parses YAML files generated from the
-[`docker/cli`](https://github.com/docker/cli) repository. The YAML files
-are parsed into output files like
-</reference/cli/docker/build/>.
-
-## How the output is generated
-
-The output files are composed from two sources:
-
-- The **Description** and **Usage** sections comes directly from
-  the CLI source code in that repository.
-
-- The **Extended Description** and **Examples** sections are pulled into the
-  YAML from the files in [https://github.com/docker/cli/tree/master/docs/reference/commandline](https://github.com/docker/cli/tree/master/docs/reference/commandline) for Docker CLI commands and [https://github.com/docker/compose/tree/v2/docs/reference](https://github.com/docker/compose/tree/v2/docs/reference) for Docker Compose commands.
-  Specifically, the Markdown inside the `## Description` and `## Examples`
-  headings are parsed. Submit corrections to the text in those repositories.
-
-## Updating the YAML files
-
-The process for generating the YAML files is still in flux. Check with
-@thaJeztah. Be sure to generate the YAML files with the correct
-release branch of `docker/cli`, for example, the `19.03` branch.
-
-After generating the YAML files, replace the YAML files in
-[https://github.com/docker/docs/tree/main/_data/engine-cli](https://github.com/docker/docs/tree/main/_data/engine-cli)
-with the newly-generated files. Submit a pull request.
diff --git a/content/reference/cli/docker/_index.md b/content/reference/cli/docker/_index.md
deleted file mode 100644
index 58127c1067fb..000000000000
--- a/content/reference/cli/docker/_index.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker
-title: docker
-aliases:
-- /edge/engine/reference/commandline/
-- /engine/reference/commandline/
-- /engine/reference/commandline/docker/
-- /engine/reference/commandline/cli/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/build-legacy.md b/content/reference/cli/docker/build-legacy.md
deleted file mode 100644
index bb89d2ee5f8e..000000000000
--- a/content/reference/cli/docker/build-legacy.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_build
-title: docker build (legacy builder)
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/build.md b/content/reference/cli/docker/build.md
deleted file mode 100644
index 79ec94656e78..000000000000
--- a/content/reference/cli/docker/build.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: docker build
-build:
-  render: never
-sidebar:
-  goto: /reference/cli/docker/buildx/build/
----
diff --git a/content/reference/cli/docker/builder/_index.md b/content/reference/cli/docker/builder/_index.md
deleted file mode 100644
index 553634e68639..000000000000
--- a/content/reference/cli/docker/builder/_index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_builder
-title: docker builder
-layout: cli
-aliases:
-- /engine/reference/commandline/builder/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/builder/prune.md b/content/reference/cli/docker/builder/prune.md
deleted file mode 100644
index 9ae1858bc149..000000000000
--- a/content/reference/cli/docker/builder/prune.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_builder_prune
-title: docker builder prune
-layout: cli
-aliases:
-- /engine/reference/commandline/builder_prune/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/buildx/_index.md b/content/reference/cli/docker/buildx/_index.md
deleted file mode 100644
index e3c33d5b7ac5..000000000000
--- a/content/reference/cli/docker/buildx/_index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx
-title: docker buildx
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/bake.md b/content/reference/cli/docker/buildx/bake.md
deleted file mode 100644
index 67331871f308..000000000000
--- a/content/reference/cli/docker/buildx/bake.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_bake
-title: docker buildx bake
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_bake/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/build.md b/content/reference/cli/docker/buildx/build.md
deleted file mode 100644
index b6e22f0d2fd2..000000000000
--- a/content/reference/cli/docker/buildx/build.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_build
-title: docker buildx build
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_build/
-- /edge/engine/reference/commandline/image_build/
-- /engine/reference/commandline/image_build/
-- /engine/reference/commandline/build/
-- /engine/reference/commandline/builder_build/
-- /reference/cli/docker/build/
-- /reference/cli/docker/builder/build/
-- /reference/cli/docker/image/build/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/create.md b/content/reference/cli/docker/buildx/create.md
deleted file mode 100644
index 1196ef5c980f..000000000000
--- a/content/reference/cli/docker/buildx/create.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_create
-title: docker buildx create
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_create
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/debug/_index.md b/content/reference/cli/docker/buildx/debug/_index.md
deleted file mode 100644
index ed93347af8e4..000000000000
--- a/content/reference/cli/docker/buildx/debug/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_debug
-title: docker buildx debug
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_debug-shell/
-- /engine/reference/commandline/buildx_debug/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/debug/build.md b/content/reference/cli/docker/buildx/debug/build.md
deleted file mode 100644
index 182dd32018a8..000000000000
--- a/content/reference/cli/docker/buildx/debug/build.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_debug_build
-title: docker buildx debug build
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_debug_build/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/du.md b/content/reference/cli/docker/buildx/du.md
deleted file mode 100644
index e1a5475804bd..000000000000
--- a/content/reference/cli/docker/buildx/du.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_du
-title: docker buildx du
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_du/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/history/_index.md b/content/reference/cli/docker/buildx/history/_index.md
deleted file mode 100644
index cf0454729c0b..000000000000
--- a/content/reference/cli/docker/buildx/history/_index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_history
-title: docker buildx history
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_history/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/history/export.md b/content/reference/cli/docker/buildx/history/export.md
deleted file mode 100644
index 6f38ca206415..000000000000
--- a/content/reference/cli/docker/buildx/history/export.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_history_export
-title: docker buildx history export
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_history_export/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/history/import.md b/content/reference/cli/docker/buildx/history/import.md
deleted file mode 100644
index cd918893cdda..000000000000
--- a/content/reference/cli/docker/buildx/history/import.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_history_import
-title: docker buildx history import
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_history_import/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/history/inspect/_index.md b/content/reference/cli/docker/buildx/history/inspect/_index.md
deleted file mode 100644
index 533b40c6c4a6..000000000000
--- a/content/reference/cli/docker/buildx/history/inspect/_index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_history_inspect
-title: docker buildx history inspect
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_history_inspect/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/history/inspect/attachment.md b/content/reference/cli/docker/buildx/history/inspect/attachment.md
deleted file mode 100644
index 49a17b2f8b8a..000000000000
--- a/content/reference/cli/docker/buildx/history/inspect/attachment.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_history_inspect_attachment
-title: docker buildx history inspect attachment
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_history_inspect_attachment/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/history/logs.md b/content/reference/cli/docker/buildx/history/logs.md
deleted file mode 100644
index c859717f04a3..000000000000
--- a/content/reference/cli/docker/buildx/history/logs.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_history_logs
-title: docker buildx history logs
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_history_logs/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/history/ls.md b/content/reference/cli/docker/buildx/history/ls.md
deleted file mode 100644
index 5bb38651bd17..000000000000
--- a/content/reference/cli/docker/buildx/history/ls.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_history_ls
-title: docker buildx history ls
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_history_ls/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/history/open.md b/content/reference/cli/docker/buildx/history/open.md
deleted file mode 100644
index e7b98ef293dd..000000000000
--- a/content/reference/cli/docker/buildx/history/open.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_history_open
-title: docker buildx history open
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_history_open/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/history/rm.md b/content/reference/cli/docker/buildx/history/rm.md
deleted file mode 100644
index 744a68175a97..000000000000
--- a/content/reference/cli/docker/buildx/history/rm.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_history_rm
-title: docker buildx history rm
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_history_rm/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/history/trace.md b/content/reference/cli/docker/buildx/history/trace.md
deleted file mode 100644
index 4814477d6534..000000000000
--- a/content/reference/cli/docker/buildx/history/trace.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_history_trace
-title: docker buildx history trace
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_history_trace/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/imagetools/_index.md b/content/reference/cli/docker/buildx/imagetools/_index.md
deleted file mode 100644
index 2d1b16bc9438..000000000000
--- a/content/reference/cli/docker/buildx/imagetools/_index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_imagetools
-title: docker buildx imagetools
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_imagetools/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/imagetools/create.md b/content/reference/cli/docker/buildx/imagetools/create.md
deleted file mode 100644
index bbc252a08bf6..000000000000
--- a/content/reference/cli/docker/buildx/imagetools/create.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_imagetools_create
-title: docker buildx imagetools create
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_imagetools_create/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/imagetools/inspect.md b/content/reference/cli/docker/buildx/imagetools/inspect.md
deleted file mode 100644
index b6d7da95585b..000000000000
--- a/content/reference/cli/docker/buildx/imagetools/inspect.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_imagetools_inspect
-title: docker buildx imagetools inspect
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_imagetools_inspect/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/inspect.md b/content/reference/cli/docker/buildx/inspect.md
deleted file mode 100644
index 32e4ac35f527..000000000000
--- a/content/reference/cli/docker/buildx/inspect.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_inspect
-title: docker buildx inspect
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_inspect/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/ls.md b/content/reference/cli/docker/buildx/ls.md
deleted file mode 100644
index 4a32545427ee..000000000000
--- a/content/reference/cli/docker/buildx/ls.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_ls
-title: docker buildx ls
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_ls/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/prune.md b/content/reference/cli/docker/buildx/prune.md
deleted file mode 100644
index be4f9d63b67f..000000000000
--- a/content/reference/cli/docker/buildx/prune.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_prune
-title: docker buildx prune
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_prune/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/rm.md b/content/reference/cli/docker/buildx/rm.md
deleted file mode 100644
index dd65cec5a3d8..000000000000
--- a/content/reference/cli/docker/buildx/rm.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_rm
-title: docker buildx rm
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_rm/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/stop.md b/content/reference/cli/docker/buildx/stop.md
deleted file mode 100644
index f9a64997697b..000000000000
--- a/content/reference/cli/docker/buildx/stop.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_stop
-title: docker buildx stop
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_stop/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/use.md b/content/reference/cli/docker/buildx/use.md
deleted file mode 100644
index 5fd8c26505ab..000000000000
--- a/content/reference/cli/docker/buildx/use.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_use
-title: docker buildx use
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_use/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/buildx/version.md b/content/reference/cli/docker/buildx/version.md
deleted file mode 100644
index 8d277daa47ff..000000000000
--- a/content/reference/cli/docker/buildx/version.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: buildx
-datafile: docker_buildx_version
-title: docker buildx version
-layout: cli
-aliases:
-- /engine/reference/commandline/buildx_version/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/buildx
--->
diff --git a/content/reference/cli/docker/checkpoint/_index.md b/content/reference/cli/docker/checkpoint/_index.md
deleted file mode 100644
index b72162d2028d..000000000000
--- a/content/reference/cli/docker/checkpoint/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_checkpoint
-title: docker checkpoint
-aliases:
-- /edge/engine/reference/commandline/checkpoint/
-- /engine/reference/commandline/checkpoint/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/checkpoint/create.md b/content/reference/cli/docker/checkpoint/create.md
deleted file mode 100644
index ebb12e781f84..000000000000
--- a/content/reference/cli/docker/checkpoint/create.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_checkpoint_create
-title: docker checkpoint create
-aliases:
-- /edge/engine/reference/commandline/checkpoint_create/
-- /engine/reference/commandline/checkpoint_create/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/checkpoint/ls.md b/content/reference/cli/docker/checkpoint/ls.md
deleted file mode 100644
index 625a0898a122..000000000000
--- a/content/reference/cli/docker/checkpoint/ls.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_checkpoint_ls
-title: docker checkpoint ls
-aliases:
-- /edge/engine/reference/commandline/checkpoint_ls/
-- /engine/reference/commandline/checkpoint_ls/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/checkpoint/rm.md b/content/reference/cli/docker/checkpoint/rm.md
deleted file mode 100644
index cd85f87d6fd9..000000000000
--- a/content/reference/cli/docker/checkpoint/rm.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_checkpoint_rm
-title: docker checkpoint rm
-aliases:
-- /edge/engine/reference/commandline/checkpoint_rm/
-- /engine/reference/commandline/checkpoint_rm/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/compose/_index.md b/content/reference/cli/docker/compose/_index.md
deleted file mode 100644
index 680385642e12..000000000000
--- a/content/reference/cli/docker/compose/_index.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose
-title: docker compose
-aliases:
-- /compose/reference/docker-compose/
-- /compose/reference/help/
-- /engine/reference/commandline/compose/
-- /compose/reference/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/alpha/_index.md b/content/reference/cli/docker/compose/alpha/_index.md
deleted file mode 100644
index 09afd97e0856..000000000000
--- a/content/reference/cli/docker/compose/alpha/_index.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_alpha
-title: docker compose alpha
-layout: cli
-aliases:
-- /engine/reference/commandline/compose_alpha
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/alpha/dry-run.md b/content/reference/cli/docker/compose/alpha/dry-run.md
deleted file mode 100644
index bce00ab6a595..000000000000
--- a/content/reference/cli/docker/compose/alpha/dry-run.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_alpha_dry-run
-title: docker compose alpha dry-run
-layout: cli
-aliases:
-- /engine/reference/commandline/compose_alpha_dry-run
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/alpha/publish.md b/content/reference/cli/docker/compose/alpha/publish.md
deleted file mode 100644
index 34d713568728..000000000000
--- a/content/reference/cli/docker/compose/alpha/publish.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_alpha_publish
-title: docker compose alpha publish
-layout: cli
-aliases:
-- /engine/reference/commandline/compose_alpha_publish/
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/alpha/scale.md b/content/reference/cli/docker/compose/alpha/scale.md
deleted file mode 100644
index 0b7a64c52102..000000000000
--- a/content/reference/cli/docker/compose/alpha/scale.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_alpha_scale
-title: docker compose alpha scale
-layout: cli
-aliases:
-- /engine/reference/commandline/compose_alpha_scale/
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/alpha/viz.md b/content/reference/cli/docker/compose/alpha/viz.md
deleted file mode 100644
index bb5a2ac3f391..000000000000
--- a/content/reference/cli/docker/compose/alpha/viz.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_alpha_viz
-title: docker compose alpha viz
-layout: cli
-aliases:
-- /engine/reference/commandline/compose_alpha_viz/
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/build.md b/content/reference/cli/docker/compose/build.md
deleted file mode 100644
index 3b30fa887d19..000000000000
--- a/content/reference/cli/docker/compose/build.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_build
-title: docker compose build
-aliases:
-- /compose/reference/build/
-- /engine/reference/commandline/compose_build/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/config.md b/content/reference/cli/docker/compose/config.md
deleted file mode 100644
index 60ed541a15e3..000000000000
--- a/content/reference/cli/docker/compose/config.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_config
-title: docker compose config
-aliases:
-- /compose/reference/config/
-- /engine/reference/commandline/compose_convert/
-- /engine/reference/commandline/compose_config/
-- /compose/config/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/cp.md b/content/reference/cli/docker/compose/cp.md
deleted file mode 100644
index db30f7ca4d22..000000000000
--- a/content/reference/cli/docker/compose/cp.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_cp
-title: docker compose cp
-layout: cli
-aliases:
-- /engine/reference/commandline/compose_cp/
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/create.md b/content/reference/cli/docker/compose/create.md
deleted file mode 100644
index a1006635f04c..000000000000
--- a/content/reference/cli/docker/compose/create.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_create
-title: docker compose create
-aliases:
-- /compose/reference/create/
-- /engine/reference/commandline/compose_create/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/down.md b/content/reference/cli/docker/compose/down.md
deleted file mode 100644
index 88e2910b9109..000000000000
--- a/content/reference/cli/docker/compose/down.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_down
-title: docker compose down
-aliases:
-- /compose/reference/down/
-- /engine/reference/commandline/compose_down/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/events.md b/content/reference/cli/docker/compose/events.md
deleted file mode 100644
index 309cbff0c24f..000000000000
--- a/content/reference/cli/docker/compose/events.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_events
-title: docker compose events
-aliases:
-- /compose/reference/events/
-- /engine/reference/commandline/compose_events/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/exec.md b/content/reference/cli/docker/compose/exec.md
deleted file mode 100644
index 1d9bb8d171a8..000000000000
--- a/content/reference/cli/docker/compose/exec.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_exec
-title: docker compose exec
-aliases:
-- /compose/reference/exec/
-- /engine/reference/commandline/compose_exec/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/images.md b/content/reference/cli/docker/compose/images.md
deleted file mode 100644
index 3e70eca54657..000000000000
--- a/content/reference/cli/docker/compose/images.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_images
-title: docker compose images
-aliases:
-- /compose/reference/images/
-- /engine/reference/commandline/compose_images/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/kill.md b/content/reference/cli/docker/compose/kill.md
deleted file mode 100644
index 127807e24ba8..000000000000
--- a/content/reference/cli/docker/compose/kill.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_kill
-title: docker compose kill
-aliases:
-- /compose/reference/kill/
-- /engine/reference/commandline/compose_kill/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/logs.md b/content/reference/cli/docker/compose/logs.md
deleted file mode 100644
index 4eb9cc32d3a9..000000000000
--- a/content/reference/cli/docker/compose/logs.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_logs
-title: docker compose logs
-aliases:
-- /compose/reference/logs/
-- /engine/reference/commandline/compose_logs/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/ls.md b/content/reference/cli/docker/compose/ls.md
deleted file mode 100644
index 6b31d314e6b5..000000000000
--- a/content/reference/cli/docker/compose/ls.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_ls
-title: docker compose ls
-layout: cli
-aliases:
-- /engine/reference/commandline/compose_ls/
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/pause.md b/content/reference/cli/docker/compose/pause.md
deleted file mode 100644
index 2b03df62f4a3..000000000000
--- a/content/reference/cli/docker/compose/pause.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_pause
-title: docker compose pause
-aliases:
-- /compose/reference/pause/
-- /engine/reference/commandline/compose_pause/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/port.md b/content/reference/cli/docker/compose/port.md
deleted file mode 100644
index ec75e96fecaf..000000000000
--- a/content/reference/cli/docker/compose/port.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_port
-title: docker compose port
-aliases:
-- /compose/reference/port/
-- /engine/reference/commandline/compose_port/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/ps.md b/content/reference/cli/docker/compose/ps.md
deleted file mode 100644
index 34daf4b00d2d..000000000000
--- a/content/reference/cli/docker/compose/ps.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_ps
-title: docker compose ps
-aliases:
-- /compose/reference/ps/
-- /engine/reference/commandline/compose_ps/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/pull.md b/content/reference/cli/docker/compose/pull.md
deleted file mode 100644
index d3cca547467a..000000000000
--- a/content/reference/cli/docker/compose/pull.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_pull
-title: docker compose pull
-aliases:
-- /compose/reference/pull/
-- /engine/reference/commandline/compose_pull/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/push.md b/content/reference/cli/docker/compose/push.md
deleted file mode 100644
index 87a540e67e4f..000000000000
--- a/content/reference/cli/docker/compose/push.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_push
-title: docker compose push
-aliases:
-- /compose/reference/push/
-- /engine/reference/commandline/compose_push/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/restart.md b/content/reference/cli/docker/compose/restart.md
deleted file mode 100644
index c63b1044bb0c..000000000000
--- a/content/reference/cli/docker/compose/restart.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_restart
-title: docker compose restart
-aliases:
-- /compose/reference/restart/
-- /engine/reference/commandline/compose_restart/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/rm.md b/content/reference/cli/docker/compose/rm.md
deleted file mode 100644
index bab1f57b9593..000000000000
--- a/content/reference/cli/docker/compose/rm.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_rm
-title: docker compose rm
-aliases:
-- /compose/reference/rm/
-- /engine/reference/commandline/compose_rm/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/run.md b/content/reference/cli/docker/compose/run.md
deleted file mode 100644
index f04058db94e3..000000000000
--- a/content/reference/cli/docker/compose/run.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_run
-title: docker compose run
-aliases:
-- /compose/reference/run/
-- /engine/reference/commandline/compose_run/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/start.md b/content/reference/cli/docker/compose/start.md
deleted file mode 100644
index f1e41feeabb0..000000000000
--- a/content/reference/cli/docker/compose/start.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_start
-title: docker compose start
-aliases:
-- /compose/reference/start/
-- /engine/reference/commandline/compose_start/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/stop.md b/content/reference/cli/docker/compose/stop.md
deleted file mode 100644
index f24d6d918f37..000000000000
--- a/content/reference/cli/docker/compose/stop.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_stop
-title: docker compose stop
-aliases:
-- /compose/reference/stop/
-- /engine/reference/commandline/compose_stop/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/top.md b/content/reference/cli/docker/compose/top.md
deleted file mode 100644
index 6b0896d28d05..000000000000
--- a/content/reference/cli/docker/compose/top.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_top
-title: docker compose top
-aliases:
-- /compose/reference/top/
-- /engine/reference/commandline/compose_top/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/unpause.md b/content/reference/cli/docker/compose/unpause.md
deleted file mode 100644
index b818cba42b45..000000000000
--- a/content/reference/cli/docker/compose/unpause.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_unpause
-title: docker compose unpause
-aliases:
-- /compose/reference/unpause/
-- /engine/reference/commandline/compose_unpause/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/up.md b/content/reference/cli/docker/compose/up.md
deleted file mode 100644
index 988f3e04a486..000000000000
--- a/content/reference/cli/docker/compose/up.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_up
-title: docker compose up
-aliases:
-- /compose/reference/up/
-- /compose/reference/scale/
-- /engine/reference/commandline/compose_up/
-layout: cli
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/version.md b/content/reference/cli/docker/compose/version.md
deleted file mode 100644
index 5c6d8f22acaf..000000000000
--- a/content/reference/cli/docker/compose/version.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_version
-title: docker compose version
-layout: cli
-aliases:
-- /engine/reference/commandline/compose_version/
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/wait.md b/content/reference/cli/docker/compose/wait.md
deleted file mode 100644
index 399a7d872434..000000000000
--- a/content/reference/cli/docker/compose/wait.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_wait
-title: docker compose wait
-layout: cli
-aliases:
-- /engine/reference/commandline/compose_wait/
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/compose/watch.md b/content/reference/cli/docker/compose/watch.md
deleted file mode 100644
index 644a6c6a4d5a..000000000000
--- a/content/reference/cli/docker/compose/watch.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-datafolder: compose-cli
-datafile: docker_compose_watch
-title: docker compose watch
-layout: cli
-aliases:
-- /engine/reference/commandline/compose_watch/
----
-
-<!--
-Sorry, but the contents of this page are automatically generated from
-Docker's source code. If you want to suggest a change to the text that appears
-here, you'll need to find the string by searching this repo:
-https://github.com/docker/compose
--->
diff --git a/content/reference/cli/docker/config/_index.md b/content/reference/cli/docker/config/_index.md
deleted file mode 100644
index adaa8bd70d46..000000000000
--- a/content/reference/cli/docker/config/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_config
-title: docker config
-aliases:
-- /edge/engine/reference/commandline/config/
-- /engine/reference/commandline/config/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/config/create.md b/content/reference/cli/docker/config/create.md
deleted file mode 100644
index fc2e244e6f5e..000000000000
--- a/content/reference/cli/docker/config/create.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_config_create
-title: docker config create
-aliases:
-- /edge/engine/reference/commandline/config_create/
-- /engine/reference/commandline/config_create/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/config/inspect.md b/content/reference/cli/docker/config/inspect.md
deleted file mode 100644
index ba344886620d..000000000000
--- a/content/reference/cli/docker/config/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_config_inspect
-title: docker config inspect
-aliases:
-- /edge/engine/reference/commandline/config_inspect/
-- /engine/reference/commandline/config_inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/config/ls.md b/content/reference/cli/docker/config/ls.md
deleted file mode 100644
index ac93c7973618..000000000000
--- a/content/reference/cli/docker/config/ls.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_config_ls
-title: docker config ls
-aliases:
-- /edge/engine/reference/commandline/config_ls/
-- /engine/reference/commandline/config_ls/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/config/rm.md b/content/reference/cli/docker/config/rm.md
deleted file mode 100644
index e6604edd0633..000000000000
--- a/content/reference/cli/docker/config/rm.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_config_rm
-title: docker config rm
-aliases:
-- /edge/engine/reference/commandline/config_rm/
-- /engine/reference/commandline/config_rm/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/_index.md b/content/reference/cli/docker/container/_index.md
deleted file mode 100644
index ebfccc29f929..000000000000
--- a/content/reference/cli/docker/container/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container
-title: docker container
-aliases:
-- /edge/engine/reference/commandline/container/
-- /engine/reference/commandline/container/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/attach.md b/content/reference/cli/docker/container/attach.md
deleted file mode 100644
index 0efedf86e8c0..000000000000
--- a/content/reference/cli/docker/container/attach.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_attach
-title: docker container attach
-aliases:
-- /edge/engine/reference/commandline/container_attach/
-- /engine/reference/commandline/attach/
-- /engine/reference/commandline/container_attach/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/commit.md b/content/reference/cli/docker/container/commit.md
deleted file mode 100644
index e583e9f19d06..000000000000
--- a/content/reference/cli/docker/container/commit.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_commit
-title: docker container commit
-aliases:
-- /edge/engine/reference/commandline/container_commit/
-- /engine/reference/commandline/container_commit/
-- /engine/reference/commandline/commit/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/cp.md b/content/reference/cli/docker/container/cp.md
deleted file mode 100644
index bc4e49fd71a1..000000000000
--- a/content/reference/cli/docker/container/cp.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_cp
-title: docker container cp
-aliases:
-- /edge/engine/reference/commandline/container_cp/
-- /engine/reference/commandline/container_cp/
-- /engine/reference/commandline/cp/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/create.md b/content/reference/cli/docker/container/create.md
deleted file mode 100644
index f63959d0dba2..000000000000
--- a/content/reference/cli/docker/container/create.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_create
-title: docker container create
-aliases:
-- /edge/engine/reference/commandline/container_create/
-- /engine/reference/commandline/container_create/
-- /engine/reference/commandline/create/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/diff.md b/content/reference/cli/docker/container/diff.md
deleted file mode 100644
index 2ae8cb3d5a18..000000000000
--- a/content/reference/cli/docker/container/diff.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_diff
-title: docker container diff
-aliases:
-- /edge/engine/reference/commandline/container_diff/
-- /engine/reference/commandline/container_diff/
-- /engine/reference/commandline/diff/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/exec.md b/content/reference/cli/docker/container/exec.md
deleted file mode 100644
index 4b583fb18af1..000000000000
--- a/content/reference/cli/docker/container/exec.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_exec
-title: docker container exec
-aliases:
-- /edge/engine/reference/commandline/container_exec/
-- /engine/reference/commandline/container_exec/
-- /engine/reference/commandline/exec/
-- /reference/cli/docker/exec/
-layout: cli
----
-
-> **Introducing Docker Debug**
->
-> To easily get a debug shell into any container, use `docker debug`. Docker
-> Debug is a replacement for debugging with `docker exec`. With it, you can get
-> a shell into any container or image, even slim ones, without modifications.
-> Plus, you can bring along your favorite debugging tools in its customizable
-> toolbox.
->
-> Explore [Docker Debug](../debug.md) now.
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/export.md b/content/reference/cli/docker/container/export.md
deleted file mode 100644
index cf81bff3e9be..000000000000
--- a/content/reference/cli/docker/container/export.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_export
-title: docker container export
-aliases:
-- /edge/engine/reference/commandline/container_export/
-- /engine/reference/commandline/container_export/
-- /engine/reference/commandline/export/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/inspect.md b/content/reference/cli/docker/container/inspect.md
deleted file mode 100644
index 21a2829fca1b..000000000000
--- a/content/reference/cli/docker/container/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_inspect
-title: docker container inspect
-aliases:
-- /edge/engine/reference/commandline/container_inspect/
-- /engine/reference/commandline/container_inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/kill.md b/content/reference/cli/docker/container/kill.md
deleted file mode 100644
index 1d8a24ebd5bf..000000000000
--- a/content/reference/cli/docker/container/kill.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_kill
-title: docker container kill
-aliases:
-- /edge/engine/reference/commandline/container_kill/
-- /engine/reference/commandline/container_kill/
-- /engine/reference/commandline/kill/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/logs.md b/content/reference/cli/docker/container/logs.md
deleted file mode 100644
index a4806e4f0624..000000000000
--- a/content/reference/cli/docker/container/logs.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_logs
-title: docker container logs
-aliases:
-- /edge/engine/reference/commandline/container_logs/
-- /engine/reference/commandline/container_logs/
-- /engine/reference/commandline/logs/
-- /reference/cli/docker/logs/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/ls.md b/content/reference/cli/docker/container/ls.md
deleted file mode 100644
index d9a42e15fd26..000000000000
--- a/content/reference/cli/docker/container/ls.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_ls
-title: docker container ls
-aliases:
-- /edge/engine/reference/commandline/container_ls/
-- /engine/reference/commandline/container_ls/
-- /engine/reference/commandline/ps/
-- /reference/cli/docker/ps/
-- /reference/cli/docker/container/ps/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/pause.md b/content/reference/cli/docker/container/pause.md
deleted file mode 100644
index 68f3a3b94037..000000000000
--- a/content/reference/cli/docker/container/pause.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_pause
-title: docker container pause
-aliases:
-- /edge/engine/reference/commandline/container_pause/
-- /engine/reference/commandline/container_pause/
-- /engine/reference/commandline/pause/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/port.md b/content/reference/cli/docker/container/port.md
deleted file mode 100644
index 1d62b0a7eb84..000000000000
--- a/content/reference/cli/docker/container/port.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_port
-title: docker container port
-aliases:
-- /edge/engine/reference/commandline/container_port/
-- /engine/reference/commandline/container_port/
-- /engine/reference/commandline/port/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/prune.md b/content/reference/cli/docker/container/prune.md
deleted file mode 100644
index 2dda78d42c0b..000000000000
--- a/content/reference/cli/docker/container/prune.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_prune
-title: docker container prune
-aliases:
-- /edge/engine/reference/commandline/container_prune/
-- /engine/reference/commandline/container_prune/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/rename.md b/content/reference/cli/docker/container/rename.md
deleted file mode 100644
index b924a105ae6b..000000000000
--- a/content/reference/cli/docker/container/rename.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_rename
-title: docker container rename
-aliases:
-- /edge/engine/reference/commandline/container_rename/
-- /engine/reference/commandline/container_rename/
-- /engine/reference/commandline/rename/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/restart.md b/content/reference/cli/docker/container/restart.md
deleted file mode 100644
index c0455c74ad34..000000000000
--- a/content/reference/cli/docker/container/restart.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_restart
-title: docker container restart
-aliases:
-- /edge/engine/reference/commandline/container_restart/
-- /engine/reference/commandline/container_restart/
-- /engine/reference/commandline/restart/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/rm.md b/content/reference/cli/docker/container/rm.md
deleted file mode 100644
index 86227d121ab6..000000000000
--- a/content/reference/cli/docker/container/rm.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_rm
-title: docker container rm
-aliases:
-- /edge/engine/reference/commandline/container_rm/
-- /engine/reference/commandline/container_rm/
-- /engine/reference/commandline/rm/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/run.md b/content/reference/cli/docker/container/run.md
deleted file mode 100644
index e2af79445ee0..000000000000
--- a/content/reference/cli/docker/container/run.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_run
-title: docker container run
-aliases:
-- /engine/reference/commandline/container_run/
-- /engine/reference/commandline/run/
-- /reference/cli/docker/run/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/start.md b/content/reference/cli/docker/container/start.md
deleted file mode 100644
index 65f979cd9b0f..000000000000
--- a/content/reference/cli/docker/container/start.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_start
-title: docker container start
-aliases:
-- /edge/engine/reference/commandline/container_start/
-- /engine/reference/commandline/container_start/
-- /engine/reference/commandline/start/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/stats.md b/content/reference/cli/docker/container/stats.md
deleted file mode 100644
index c942ba66e84e..000000000000
--- a/content/reference/cli/docker/container/stats.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_stats
-title: docker container stats
-aliases:
-- /edge/engine/reference/commandline/container_stats/
-- /engine/reference/commandline/container_stats/
-- /engine/reference/commandline/stats/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/stop.md b/content/reference/cli/docker/container/stop.md
deleted file mode 100644
index 6332deae6871..000000000000
--- a/content/reference/cli/docker/container/stop.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_stop
-title: docker container stop
-aliases:
-- /edge/engine/reference/commandline/container_stop/
-- /engine/reference/commandline/container_stop/
-- /engine/reference/commandline/stop/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/top.md b/content/reference/cli/docker/container/top.md
deleted file mode 100644
index 4dbf57a0e7e2..000000000000
--- a/content/reference/cli/docker/container/top.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_top
-title: docker container top
-aliases:
-- /edge/engine/reference/commandline/container_top/
-- /engine/reference/commandline/container_top/
-- /engine/reference/commandline/top/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/unpause.md b/content/reference/cli/docker/container/unpause.md
deleted file mode 100644
index bced1bebca75..000000000000
--- a/content/reference/cli/docker/container/unpause.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_unpause
-title: docker container unpause
-aliases:
-- /edge/engine/reference/commandline/container_unpause/
-- /engine/reference/commandline/container_unpause/
-- /engine/reference/commandline/unpause/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/update.md b/content/reference/cli/docker/container/update.md
deleted file mode 100644
index 259e0844c547..000000000000
--- a/content/reference/cli/docker/container/update.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_update
-title: docker container update
-aliases:
-- /edge/engine/reference/commandline/container_update/
-- /engine/reference/commandline/container_update/
-- /engine/reference/commandline/update/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/container/wait.md b/content/reference/cli/docker/container/wait.md
deleted file mode 100644
index a179d31a249e..000000000000
--- a/content/reference/cli/docker/container/wait.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_container_wait
-title: docker container wait
-aliases:
-- /edge/engine/reference/commandline/container_wait/
-- /engine/reference/commandline/container_wait/
-- /engine/reference/commandline/wait/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/context/_index.md b/content/reference/cli/docker/context/_index.md
deleted file mode 100644
index e97820ffc746..000000000000
--- a/content/reference/cli/docker/context/_index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_context
-title: docker context
-layout: cli
-aliases:
-- /engine/reference/commandline/context/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/context/create.md b/content/reference/cli/docker/context/create.md
deleted file mode 100644
index 84c6e77d7889..000000000000
--- a/content/reference/cli/docker/context/create.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_context_create
-title: docker context create
-layout: cli
-aliases:
-- /engine/reference/commandline/context_create/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/context/export.md b/content/reference/cli/docker/context/export.md
deleted file mode 100644
index aa6e3b3c62e0..000000000000
--- a/content/reference/cli/docker/context/export.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_context_export
-title: docker context export
-layout: cli
-aliases:
-- /engine/reference/commandline/context_export/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/context/import.md b/content/reference/cli/docker/context/import.md
deleted file mode 100644
index 50fec18bc112..000000000000
--- a/content/reference/cli/docker/context/import.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_context_import
-title: docker context import
-layout: cli
-aliases:
-- /engine/reference/commandline/context_import/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/context/inspect.md b/content/reference/cli/docker/context/inspect.md
deleted file mode 100644
index a163d2af8ac7..000000000000
--- a/content/reference/cli/docker/context/inspect.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_context_inspect
-title: docker context inspect
-layout: cli
-aliases:
-- /engine/reference/commandline/context_inspect/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/context/ls.md b/content/reference/cli/docker/context/ls.md
deleted file mode 100644
index a10a137bc7d5..000000000000
--- a/content/reference/cli/docker/context/ls.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_context_ls
-title: docker context ls
-layout: cli
-aliases:
-- /engine/reference/commandline/context_ls/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/context/rm.md b/content/reference/cli/docker/context/rm.md
deleted file mode 100644
index 489be0e34614..000000000000
--- a/content/reference/cli/docker/context/rm.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_context_rm
-title: docker context rm
-layout: cli
-aliases:
-- /engine/reference/commandline/context_rm/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/context/show.md b/content/reference/cli/docker/context/show.md
deleted file mode 100644
index ded06d7fffc3..000000000000
--- a/content/reference/cli/docker/context/show.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_context_show
-title: docker context show
-layout: cli
-aliases:
-- /engine/reference/commandline/context_show/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/context/update.md b/content/reference/cli/docker/context/update.md
deleted file mode 100644
index 03485b2ff822..000000000000
--- a/content/reference/cli/docker/context/update.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_context_update
-title: docker context update
-layout: cli
-aliases:
-- /engine/reference/commandline/context_update/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/context/use.md b/content/reference/cli/docker/context/use.md
deleted file mode 100644
index 44c12497ad40..000000000000
--- a/content/reference/cli/docker/context/use.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_context_use
-title: docker context use
-layout: cli
-aliases:
-- /engine/reference/commandline/context_use/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/debug.md b/content/reference/cli/docker/debug.md
deleted file mode 100644
index 669c8d4d0b3d..000000000000
--- a/content/reference/cli/docker/debug.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-datafolder: debug-cli
-datafile: docker_debug
-title: docker debug
-layout: cli
-aliases:
-- /engine/reference/commandline/debug/
----
-
-{{< summary-bar feature_name="Docker Debug" >}}
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/_index.md b/content/reference/cli/docker/desktop/_index.md
deleted file mode 100644
index 785fd1b3a354..000000000000
--- a/content/reference/cli/docker/desktop/_index.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop
-title: docker desktop (Beta)
-layout: cli
----
-
-{{< summary-bar feature_name="Docker Desktop CLI" >}}
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/disable/_index.md b/content/reference/cli/docker/desktop/disable/_index.md
deleted file mode 100644
index 74a81e6c355e..000000000000
--- a/content/reference/cli/docker/desktop/disable/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_disable
-title: docker desktop disable
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/disable/model-runner.md b/content/reference/cli/docker/desktop/disable/model-runner.md
deleted file mode 100644
index 40a825ee10fd..000000000000
--- a/content/reference/cli/docker/desktop/disable/model-runner.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_disable_model_runner
-title: docker desktop disable model-runner
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/enable/_index.md b/content/reference/cli/docker/desktop/enable/_index.md
deleted file mode 100644
index f1213c9c8d2f..000000000000
--- a/content/reference/cli/docker/desktop/enable/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_enable
-title: docker desktop enable
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/enable/model-runner.md b/content/reference/cli/docker/desktop/enable/model-runner.md
deleted file mode 100644
index 6ffbb9c21792..000000000000
--- a/content/reference/cli/docker/desktop/enable/model-runner.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_enable_model_runner
-title: docker desktop enable model-runner
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/engine/_index.md b/content/reference/cli/docker/desktop/engine/_index.md
deleted file mode 100644
index 97950535974d..000000000000
--- a/content/reference/cli/docker/desktop/engine/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_engine
-title: docker desktop engine
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/engine/ls.md b/content/reference/cli/docker/desktop/engine/ls.md
deleted file mode 100644
index a8499b1385e2..000000000000
--- a/content/reference/cli/docker/desktop/engine/ls.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_engine_ls
-title: docker desktop engine ls
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/engine/use.md b/content/reference/cli/docker/desktop/engine/use.md
deleted file mode 100644
index 56f58a966557..000000000000
--- a/content/reference/cli/docker/desktop/engine/use.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_engine_use
-title: docker desktop engine use
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/logs.md b/content/reference/cli/docker/desktop/logs.md
deleted file mode 100644
index fefe6c7e7ef4..000000000000
--- a/content/reference/cli/docker/desktop/logs.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_logs
-title: docker desktop logs
-layout: cli
----
-
-{{< summary-bar feature_name="Docker Desktop CLI logs" >}}
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/module/_index.md b/content/reference/cli/docker/desktop/module/_index.md
deleted file mode 100644
index 88f9fc9266f7..000000000000
--- a/content/reference/cli/docker/desktop/module/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_module
-title: docker desktop module
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/module/ls.md b/content/reference/cli/docker/desktop/module/ls.md
deleted file mode 100644
index cb9dec4e7074..000000000000
--- a/content/reference/cli/docker/desktop/module/ls.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_module_ls
-title: docker desktop module ls
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/module/reset.md b/content/reference/cli/docker/desktop/module/reset.md
deleted file mode 100644
index d9de96ebb514..000000000000
--- a/content/reference/cli/docker/desktop/module/reset.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_module_reset
-title: docker desktop reset
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/module/update.md b/content/reference/cli/docker/desktop/module/update.md
deleted file mode 100644
index e57056863d21..000000000000
--- a/content/reference/cli/docker/desktop/module/update.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_module_update
-title: docker desktop module_update
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/restart.md b/content/reference/cli/docker/desktop/restart.md
deleted file mode 100644
index 75ef78eeb494..000000000000
--- a/content/reference/cli/docker/desktop/restart.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_restart
-title: docker desktop restart
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/start.md b/content/reference/cli/docker/desktop/start.md
deleted file mode 100644
index e9eccd116e27..000000000000
--- a/content/reference/cli/docker/desktop/start.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_start
-title: docker desktop start
-layout: cli
----
-
-> [!NOTE]
->
-> `docker desktop start` doesn't work when executed via SSH on Windows due to a limitation in how WinCred stores credentials securely.
diff --git a/content/reference/cli/docker/desktop/status.md b/content/reference/cli/docker/desktop/status.md
deleted file mode 100644
index b0b868c579b0..000000000000
--- a/content/reference/cli/docker/desktop/status.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_status
-title: docker desktop status
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/stop.md b/content/reference/cli/docker/desktop/stop.md
deleted file mode 100644
index 203bdef5669b..000000000000
--- a/content/reference/cli/docker/desktop/stop.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_stop
-title: docker desktop stop
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/update.md b/content/reference/cli/docker/desktop/update.md
deleted file mode 100644
index 0f67e2ed171a..000000000000
--- a/content/reference/cli/docker/desktop/update.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_update
-title: docker desktop update
-layout: cli
----
-
-{{< summary-bar feature_name="Docker Desktop CLI update" >}}
\ No newline at end of file
diff --git a/content/reference/cli/docker/desktop/version.md b/content/reference/cli/docker/desktop/version.md
deleted file mode 100644
index 26a5c856198a..000000000000
--- a/content/reference/cli/docker/desktop/version.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-datafolder: desktop-cli
-datafile: docker_desktop_version
-title: docker desktop version
-layout: cli
----
\ No newline at end of file
diff --git a/content/reference/cli/docker/exec.md b/content/reference/cli/docker/exec.md
deleted file mode 100644
index 68acf6d726d3..000000000000
--- a/content/reference/cli/docker/exec.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: docker exec
-build:
-  render: never
-sidebar:
-  goto: /reference/cli/docker/container/exec/
----
diff --git a/content/reference/cli/docker/image/_index.md b/content/reference/cli/docker/image/_index.md
deleted file mode 100644
index 798321af1bb0..000000000000
--- a/content/reference/cli/docker/image/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image
-title: docker image
-aliases:
-- /edge/engine/reference/commandline/image/
-- /engine/reference/commandline/image/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/image/history.md b/content/reference/cli/docker/image/history.md
deleted file mode 100644
index 55bc31c850fd..000000000000
--- a/content/reference/cli/docker/image/history.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_history
-title: docker image history
-aliases:
-- /edge/engine/reference/commandline/image_history/
-- /engine/reference/commandline/image_history/
-- /engine/reference/commandline/history/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/image/import.md b/content/reference/cli/docker/image/import.md
deleted file mode 100644
index bb2aac6a008e..000000000000
--- a/content/reference/cli/docker/image/import.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_import
-title: docker image import
-aliases:
-- /edge/engine/reference/commandline/image_import/
-- /engine/reference/commandline/image_import/
-- /engine/reference/commandline/import/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/image/inspect.md b/content/reference/cli/docker/image/inspect.md
deleted file mode 100644
index 53c835e91be3..000000000000
--- a/content/reference/cli/docker/image/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_inspect
-title: docker image inspect
-aliases:
-- /edge/engine/reference/commandline/image_inspect/
-- /engine/reference/commandline/image_inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/image/load.md b/content/reference/cli/docker/image/load.md
deleted file mode 100644
index 1bc2a5dd0870..000000000000
--- a/content/reference/cli/docker/image/load.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_load
-title: docker image load
-aliases:
-- /edge/engine/reference/commandline/image_load/
-- /engine/reference/commandline/image_load/
-- /engine/reference/commandline/load/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/image/ls.md b/content/reference/cli/docker/image/ls.md
deleted file mode 100644
index 582e31738974..000000000000
--- a/content/reference/cli/docker/image/ls.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_ls
-title: docker image ls
-aliases:
-- /edge/engine/reference/commandline/image_ls/
-- /engine/reference/commandline/image_ls/
-- /engine/reference/commandline/images/
-- /reference/cli/docker/images/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/image/prune.md b/content/reference/cli/docker/image/prune.md
deleted file mode 100644
index 4b859369e87b..000000000000
--- a/content/reference/cli/docker/image/prune.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_prune
-title: docker image prune
-aliases:
-- /edge/engine/reference/commandline/image_prune/
-- /engine/reference/commandline/image_prune/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/image/pull.md b/content/reference/cli/docker/image/pull.md
deleted file mode 100644
index 7de6d4396e35..000000000000
--- a/content/reference/cli/docker/image/pull.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_pull
-title: docker image pull
-aliases:
-- /edge/engine/reference/commandline/image_pull/
-- /engine/reference/commandline/image_pull/
-- /engine/reference/commandline/pull/
-- /reference/cli/docker/pull/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/image/push.md b/content/reference/cli/docker/image/push.md
deleted file mode 100644
index c80f932d29b6..000000000000
--- a/content/reference/cli/docker/image/push.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_push
-title: docker image push
-aliases:
-- /edge/engine/reference/commandline/image_push/
-- /engine/reference/commandline/image_push/
-- /engine/reference/commandline/push/
-- /reference/cli/docker/push/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/image/rm.md b/content/reference/cli/docker/image/rm.md
deleted file mode 100644
index ea620fbe9129..000000000000
--- a/content/reference/cli/docker/image/rm.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_rm
-title: docker image rm
-aliases:
-- /edge/engine/reference/commandline/image_rm/
-- /engine/reference/commandline/image_rm/
-- /engine/reference/commandline/rmi/
-- /reference/cli/docker/rmi/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/image/save.md b/content/reference/cli/docker/image/save.md
deleted file mode 100644
index b9bd595ac2b1..000000000000
--- a/content/reference/cli/docker/image/save.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_save
-title: docker image save
-aliases:
-- /edge/engine/reference/commandline/image_save/
-- /engine/reference/commandline/image_save/
-- /engine/reference/commandline/save/
-- /reference/cli/docker/save/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/image/tag.md b/content/reference/cli/docker/image/tag.md
deleted file mode 100644
index eda8a4a0aef7..000000000000
--- a/content/reference/cli/docker/image/tag.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_image_tag
-title: docker image tag
-aliases:
-- /edge/engine/reference/commandline/image_tag/
-- /engine/reference/commandline/image_tag/
-- /engine/reference/commandline/tag/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/images.md b/content/reference/cli/docker/images.md
deleted file mode 100644
index abaefb6a2511..000000000000
--- a/content/reference/cli/docker/images.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: docker images
-build:
-  render: never
-sidebar:
-  goto: /reference/cli/docker/image/ls/
----
diff --git a/content/reference/cli/docker/info.md b/content/reference/cli/docker/info.md
deleted file mode 100644
index f15fb7de2a12..000000000000
--- a/content/reference/cli/docker/info.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: docker info
-build:
-  render: never
-sidebar:
-  goto: /reference/cli/docker/system/info/
----
diff --git a/content/reference/cli/docker/init.md b/content/reference/cli/docker/init.md
deleted file mode 100644
index ca0f9279465f..000000000000
--- a/content/reference/cli/docker/init.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-datafolder: init-cli
-datafile: docker_init
-title: docker init
-layout: cli
-aliases:
-- /engine/reference/commandline/init/
----
-
-{{< summary-bar feature_name="Docker Init" >}}
diff --git a/content/reference/cli/docker/inspect.md b/content/reference/cli/docker/inspect.md
deleted file mode 100644
index 5a537ef4c198..000000000000
--- a/content/reference/cli/docker/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_inspect
-title: docker inspect
-aliases:
-- /edge/engine/reference/commandline/inspect/
-- /engine/reference/commandline/inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/login.md b/content/reference/cli/docker/login.md
deleted file mode 100644
index a31f2353ce74..000000000000
--- a/content/reference/cli/docker/login.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_login
-title: docker login
-aliases:
-- /edge/engine/reference/commandline/login/
-- /engine/reference/commandline/login/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/logout.md b/content/reference/cli/docker/logout.md
deleted file mode 100644
index 7b449f251f55..000000000000
--- a/content/reference/cli/docker/logout.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_logout
-title: docker logout
-aliases:
-- /edge/engine/reference/commandline/logout/
-- /engine/reference/commandline/logout/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/manifest/_index.md b/content/reference/cli/docker/manifest/_index.md
deleted file mode 100644
index bb1f0099096b..000000000000
--- a/content/reference/cli/docker/manifest/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_manifest
-title: docker manifest
-aliases:
-- /edge/engine/reference/commandline/manifest/
-- /engine/reference/commandline/manifest/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/manifest/annotate.md b/content/reference/cli/docker/manifest/annotate.md
deleted file mode 100644
index aa5c33c65676..000000000000
--- a/content/reference/cli/docker/manifest/annotate.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_manifest_annotate
-title: docker manifest annotate
-aliases:
-- /edge/engine/reference/commandline/manifest_annotate/
-- /engine/reference/commandline/manifest_annotate/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/manifest/create.md b/content/reference/cli/docker/manifest/create.md
deleted file mode 100644
index 856fd8b3528b..000000000000
--- a/content/reference/cli/docker/manifest/create.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_manifest_create
-title: docker manifest create
-aliases:
-- /edge/engine/reference/commandline/manifest_create/
-- /engine/reference/commandline/manifest_create/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/manifest/inspect.md b/content/reference/cli/docker/manifest/inspect.md
deleted file mode 100644
index 2d95e1502ac8..000000000000
--- a/content/reference/cli/docker/manifest/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_manifest_inspect
-title: docker manifest inspect
-aliases:
-- /edge/engine/reference/commandline/manifest_inspect/
-- /engine/reference/commandline/manifest_inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/manifest/push.md b/content/reference/cli/docker/manifest/push.md
deleted file mode 100644
index f0c2098fb60e..000000000000
--- a/content/reference/cli/docker/manifest/push.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_manifest_push
-title: docker manifest push
-aliases:
-- /edge/engine/reference/commandline/manifest_push/
-- /engine/reference/commandline/manifest_push/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/manifest/rm.md b/content/reference/cli/docker/manifest/rm.md
deleted file mode 100644
index efe0e90320e4..000000000000
--- a/content/reference/cli/docker/manifest/rm.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_manifest_rm
-title: docker manifest rm
-layout: cli
-aliases:
-- /engine/reference/commandline/manifest_rm/
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/network/_index.md b/content/reference/cli/docker/network/_index.md
deleted file mode 100644
index ad36c1abc339..000000000000
--- a/content/reference/cli/docker/network/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_network
-title: docker network
-aliases:
-- /edge/engine/reference/commandline/network/
-- /engine/reference/commandline/network/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/network/connect.md b/content/reference/cli/docker/network/connect.md
deleted file mode 100644
index 3cf65664582b..000000000000
--- a/content/reference/cli/docker/network/connect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_network_connect
-title: docker network connect
-aliases:
-- /edge/engine/reference/commandline/network_connect/
-- /engine/reference/commandline/network_connect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/network/create.md b/content/reference/cli/docker/network/create.md
deleted file mode 100644
index 118a3068496f..000000000000
--- a/content/reference/cli/docker/network/create.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_network_create
-title: docker network create
-aliases:
-- /edge/engine/reference/commandline/network_create/
-- /engine/reference/commandline/network_create/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/network/disconnect.md b/content/reference/cli/docker/network/disconnect.md
deleted file mode 100644
index 96ab52f576b8..000000000000
--- a/content/reference/cli/docker/network/disconnect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_network_disconnect
-title: docker network disconnect
-aliases:
-- /edge/engine/reference/commandline/network_disconnect/
-- /engine/reference/commandline/network_disconnect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/network/inspect.md b/content/reference/cli/docker/network/inspect.md
deleted file mode 100644
index 2498f15e964a..000000000000
--- a/content/reference/cli/docker/network/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_network_inspect
-title: docker network inspect
-aliases:
-- /edge/engine/reference/commandline/network_inspect/
-- /engine/reference/commandline/network_inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/network/ls.md b/content/reference/cli/docker/network/ls.md
deleted file mode 100644
index 7625ea72d406..000000000000
--- a/content/reference/cli/docker/network/ls.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_network_ls
-title: docker network ls
-aliases:
-- /edge/engine/reference/commandline/network_ls/
-- /engine/reference/commandline/network_ls/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/network/prune.md b/content/reference/cli/docker/network/prune.md
deleted file mode 100644
index b4d4b75f3186..000000000000
--- a/content/reference/cli/docker/network/prune.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_network_prune
-title: docker network prune
-aliases:
-- /edge/engine/reference/commandline/network_prune/
-- /engine/reference/commandline/network_prune/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/network/rm.md b/content/reference/cli/docker/network/rm.md
deleted file mode 100644
index 55bc2daa5be1..000000000000
--- a/content/reference/cli/docker/network/rm.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_network_rm
-title: docker network rm
-aliases:
-- /edge/engine/reference/commandline/network_rm/
-- /engine/reference/commandline/network_rm/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/node/_index.md b/content/reference/cli/docker/node/_index.md
deleted file mode 100644
index 5ea0da76162c..000000000000
--- a/content/reference/cli/docker/node/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_node
-title: docker node
-aliases:
-- /edge/engine/reference/commandline/node/
-- /engine/reference/commandline/node/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/node/demote.md b/content/reference/cli/docker/node/demote.md
deleted file mode 100644
index c20727e8df6d..000000000000
--- a/content/reference/cli/docker/node/demote.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_node_demote
-title: docker node demote
-aliases:
-- /edge/engine/reference/commandline/node_demote/
-- /engine/reference/commandline/node_demote/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/node/inspect.md b/content/reference/cli/docker/node/inspect.md
deleted file mode 100644
index 9940f4e4f8cc..000000000000
--- a/content/reference/cli/docker/node/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_node_inspect
-title: docker node inspect
-aliases:
-- /edge/engine/reference/commandline/node_inspect/
-- /engine/reference/commandline/node_inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/node/ls.md b/content/reference/cli/docker/node/ls.md
deleted file mode 100644
index d8fd4830fb86..000000000000
--- a/content/reference/cli/docker/node/ls.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_node_ls
-title: docker node ls
-aliases:
-- /edge/engine/reference/commandline/node_ls/
-- /engine/reference/commandline/node_ls/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/node/promote.md b/content/reference/cli/docker/node/promote.md
deleted file mode 100644
index edddc3bec686..000000000000
--- a/content/reference/cli/docker/node/promote.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_node_promote
-title: docker node promote
-aliases:
-- /edge/engine/reference/commandline/node_promote/
-- /engine/reference/commandline/node_promote/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/node/ps.md b/content/reference/cli/docker/node/ps.md
deleted file mode 100644
index 7082576d2c32..000000000000
--- a/content/reference/cli/docker/node/ps.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_node_ps
-title: docker node ps
-aliases:
-- /edge/engine/reference/commandline/node_ps/
-- /engine/reference/commandline/node_ps/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/node/rm.md b/content/reference/cli/docker/node/rm.md
deleted file mode 100644
index 5be535e72c69..000000000000
--- a/content/reference/cli/docker/node/rm.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_node_rm
-title: docker node rm
-aliases:
-- /edge/engine/reference/commandline/node_rm/
-- /engine/reference/commandline/node_rm/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/node/update.md b/content/reference/cli/docker/node/update.md
deleted file mode 100644
index 4223adce6282..000000000000
--- a/content/reference/cli/docker/node/update.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_node_update
-title: docker node update
-aliases:
-- /edge/engine/reference/commandline/node_update/
-- /engine/reference/commandline/node_update/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/plugin/_index.md b/content/reference/cli/docker/plugin/_index.md
deleted file mode 100644
index d89a333f8b2d..000000000000
--- a/content/reference/cli/docker/plugin/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_plugin
-title: docker plugin
-aliases:
-- /edge/engine/reference/commandline/plugin/
-- /engine/reference/commandline/plugin/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/plugin/create.md b/content/reference/cli/docker/plugin/create.md
deleted file mode 100644
index 89f8d47b2b5d..000000000000
--- a/content/reference/cli/docker/plugin/create.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_plugin_create
-title: docker plugin create
-aliases:
-- /edge/engine/reference/commandline/plugin_create/
-- /engine/reference/commandline/plugin_create/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/plugin/disable.md b/content/reference/cli/docker/plugin/disable.md
deleted file mode 100644
index 6a8ce1df86bb..000000000000
--- a/content/reference/cli/docker/plugin/disable.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_plugin_disable
-title: docker plugin disable
-aliases:
-- /edge/engine/reference/commandline/plugin_disable/
-- /engine/reference/commandline/plugin_disable/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/plugin/enable.md b/content/reference/cli/docker/plugin/enable.md
deleted file mode 100644
index a3fd5d4806e1..000000000000
--- a/content/reference/cli/docker/plugin/enable.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_plugin_enable
-title: docker plugin enable
-aliases:
-- /edge/engine/reference/commandline/plugin_enable/
-- /engine/reference/commandline/plugin_enable/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/plugin/inspect.md b/content/reference/cli/docker/plugin/inspect.md
deleted file mode 100644
index 1dab0934ebc9..000000000000
--- a/content/reference/cli/docker/plugin/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_plugin_inspect
-title: docker plugin inspect
-aliases:
-- /edge/engine/reference/commandline/plugin_inspect/
-- /engine/reference/commandline/plugin_inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/plugin/install.md b/content/reference/cli/docker/plugin/install.md
deleted file mode 100644
index 5f3d558819cf..000000000000
--- a/content/reference/cli/docker/plugin/install.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_plugin_install
-title: docker plugin install
-aliases:
-- /edge/engine/reference/commandline/plugin_install/
-- /engine/reference/commandline/plugin_install/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/plugin/ls.md b/content/reference/cli/docker/plugin/ls.md
deleted file mode 100644
index 9a44b6e41682..000000000000
--- a/content/reference/cli/docker/plugin/ls.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_plugin_ls
-title: docker plugin ls
-aliases:
-- /edge/engine/reference/commandline/plugin_ls/
-- /engine/reference/commandline/plugin_ls/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/plugin/push.md b/content/reference/cli/docker/plugin/push.md
deleted file mode 100644
index 494e10392c40..000000000000
--- a/content/reference/cli/docker/plugin/push.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_plugin_push
-title: docker plugin push
-aliases:
-- /edge/engine/reference/commandline/plugin_push/
-- /engine/reference/commandline/plugin_push/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/plugin/rm.md b/content/reference/cli/docker/plugin/rm.md
deleted file mode 100644
index bb7be4eaa430..000000000000
--- a/content/reference/cli/docker/plugin/rm.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_plugin_rm
-title: docker plugin rm
-aliases:
-- /edge/engine/reference/commandline/plugin_rm/
-- /engine/reference/commandline/plugin_rm/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/plugin/set.md b/content/reference/cli/docker/plugin/set.md
deleted file mode 100644
index c95ede1f2b4e..000000000000
--- a/content/reference/cli/docker/plugin/set.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_plugin_set
-title: docker plugin set
-aliases:
-- /edge/engine/reference/commandline/plugin_set/
-- /engine/reference/commandline/plugin_set/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/plugin/upgrade.md b/content/reference/cli/docker/plugin/upgrade.md
deleted file mode 100644
index 5bba3eb72eee..000000000000
--- a/content/reference/cli/docker/plugin/upgrade.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_plugin_upgrade
-title: docker plugin upgrade
-aliases:
-- /edge/engine/reference/commandline/plugin_upgrade/
-- /engine/reference/commandline/plugin_upgrade/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/ps.md b/content/reference/cli/docker/ps.md
deleted file mode 100644
index 3e6d2f90040e..000000000000
--- a/content/reference/cli/docker/ps.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: docker ps
-build:
-  render: never
-sidebar:
-  goto: /reference/cli/docker/container/ls/
----
diff --git a/content/reference/cli/docker/pull.md b/content/reference/cli/docker/pull.md
deleted file mode 100644
index 9173e78dff69..000000000000
--- a/content/reference/cli/docker/pull.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: docker pull
-build:
-  render: never
-sidebar:
-  goto: /reference/cli/docker/image/pull/
----
diff --git a/content/reference/cli/docker/push.md b/content/reference/cli/docker/push.md
deleted file mode 100644
index 735816235bf4..000000000000
--- a/content/reference/cli/docker/push.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: docker push
-build:
-  render: never
-sidebar:
-  goto: /reference/cli/docker/image/push/
----
diff --git a/content/reference/cli/docker/run.md b/content/reference/cli/docker/run.md
deleted file mode 100644
index a577ccf651db..000000000000
--- a/content/reference/cli/docker/run.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: docker run
-build:
-  render: never
-sidebar:
-  goto: /reference/cli/docker/container/run/
----
diff --git a/content/reference/cli/docker/scout/_index.md b/content/reference/cli/docker/scout/_index.md
deleted file mode 100644
index 3248f76e7960..000000000000
--- a/content/reference/cli/docker/scout/_index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout
-aliases:
-- /engine/reference/commandline/scout
-title: docker scout
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/attestation/_index.md b/content/reference/cli/docker/scout/attestation/_index.md
deleted file mode 100644
index e84afacef64f..000000000000
--- a/content/reference/cli/docker/scout/attestation/_index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_attestation
-aliases:
-- /engine/reference/commandline/scout_attestation
-title: docker scout attestation
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/attestation/add.md b/content/reference/cli/docker/scout/attestation/add.md
deleted file mode 100644
index 5ed848d9e11d..000000000000
--- a/content/reference/cli/docker/scout/attestation/add.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_attestation_add
-aliases:
-- /engine/reference/commandline/scout_attestation_add
-title: docker scout attestation add
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/cache/_index.md b/content/reference/cli/docker/scout/cache/_index.md
deleted file mode 100644
index dba1d3a423ba..000000000000
--- a/content/reference/cli/docker/scout/cache/_index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_cache
-aliases:
-- /engine/reference/commandline/scout_cache/
-title: docker scout cache
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/cache/df.md b/content/reference/cli/docker/scout/cache/df.md
deleted file mode 100644
index 6daa4fdc5685..000000000000
--- a/content/reference/cli/docker/scout/cache/df.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_cache_df
-aliases:
-- /engine/reference/commandline/scout_cache_df/
-title: docker scout cache df
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/cache/prune.md b/content/reference/cli/docker/scout/cache/prune.md
deleted file mode 100644
index ef77d27a7fde..000000000000
--- a/content/reference/cli/docker/scout/cache/prune.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_cache_prune
-aliases:
-- /engine/reference/commandline/scout_cache_prune/
-title: docker scout cache prune
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/compare.md b/content/reference/cli/docker/scout/compare.md
deleted file mode 100644
index d1892821369e..000000000000
--- a/content/reference/cli/docker/scout/compare.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_compare
-aliases:
-- /engine/reference/commandline/scout_compare
-title: docker scout compare
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/config.md b/content/reference/cli/docker/scout/config.md
deleted file mode 100644
index ab7d39949031..000000000000
--- a/content/reference/cli/docker/scout/config.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_config
-aliases:
-- /engine/reference/commandline/scout_config
-title: docker scout config
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/cves.md b/content/reference/cli/docker/scout/cves.md
deleted file mode 100644
index fd39d4b361fc..000000000000
--- a/content/reference/cli/docker/scout/cves.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_cves
-aliases:
-- /engine/reference/commandline/scout_cves
-title: docker scout cves
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/enroll.md b/content/reference/cli/docker/scout/enroll.md
deleted file mode 100644
index a0de9097c4f5..000000000000
--- a/content/reference/cli/docker/scout/enroll.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_enroll
-aliases:
-- /engine/reference/commandline/scout_enroll
-title: docker scout enroll
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/environment.md b/content/reference/cli/docker/scout/environment.md
deleted file mode 100644
index e45bb1782390..000000000000
--- a/content/reference/cli/docker/scout/environment.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_environment
-aliases:
-- /engine/reference/commandline/scout_environment
-title: docker scout environment
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/integration/_index.md b/content/reference/cli/docker/scout/integration/_index.md
deleted file mode 100644
index 17e602764404..000000000000
--- a/content/reference/cli/docker/scout/integration/_index.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_integration
-aliases:
-- /engine/reference/commandline/scout_integration
-title: docker scout integration
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
-
-{{% include "scout-early-access.md" %}}
diff --git a/content/reference/cli/docker/scout/integration/configure.md b/content/reference/cli/docker/scout/integration/configure.md
deleted file mode 100644
index 200efd02ee0e..000000000000
--- a/content/reference/cli/docker/scout/integration/configure.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_integration_configure
-aliases:
-- /engine/reference/commandline/scout_integration_configure
-title: docker scout integration configure
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
-
-{{% include "scout-early-access.md" %}}
diff --git a/content/reference/cli/docker/scout/integration/delete.md b/content/reference/cli/docker/scout/integration/delete.md
deleted file mode 100644
index 2de746e00289..000000000000
--- a/content/reference/cli/docker/scout/integration/delete.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_integration_delete
-aliases:
-- /engine/reference/commandline/scout_integration_delete
-title: docker scout integration delete
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
-
-{{% include "scout-early-access.md" %}}
diff --git a/content/reference/cli/docker/scout/integration/list.md b/content/reference/cli/docker/scout/integration/list.md
deleted file mode 100644
index 4271284acb1b..000000000000
--- a/content/reference/cli/docker/scout/integration/list.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_integration_list
-aliases:
-- /engine/reference/commandline/scout_integration_list
-title: docker scout integration list
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
-
-{{% include "scout-early-access.md" %}}
diff --git a/content/reference/cli/docker/scout/policy.md b/content/reference/cli/docker/scout/policy.md
deleted file mode 100644
index 51ea360b2d24..000000000000
--- a/content/reference/cli/docker/scout/policy.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_policy
-aliases:
-- /engine/reference/commandline/scout_policy
-title: docker scout policy
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/push.md b/content/reference/cli/docker/scout/push.md
deleted file mode 100644
index c090835e1cb5..000000000000
--- a/content/reference/cli/docker/scout/push.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_push
-title: docker scout push
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/quickview.md b/content/reference/cli/docker/scout/quickview.md
deleted file mode 100644
index 64199f09bc7d..000000000000
--- a/content/reference/cli/docker/scout/quickview.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_quickview
-aliases:
-- /engine/reference/commandline/scout_quickview
-title: docker scout quickview
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/recommendations.md b/content/reference/cli/docker/scout/recommendations.md
deleted file mode 100644
index 072326445158..000000000000
--- a/content/reference/cli/docker/scout/recommendations.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_recommendations
-aliases:
-- /engine/reference/commandline/scout_recommendations
-title: docker scout recommendations
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/repo/_index.md b/content/reference/cli/docker/scout/repo/_index.md
deleted file mode 100644
index 6443bd75f20f..000000000000
--- a/content/reference/cli/docker/scout/repo/_index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_repo
-aliases:
-- /engine/reference/commandline/scout_repo
-title: docker scout repo
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/repo/disable.md b/content/reference/cli/docker/scout/repo/disable.md
deleted file mode 100644
index 3ed102a0d52c..000000000000
--- a/content/reference/cli/docker/scout/repo/disable.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_repo_disable
-aliases:
-- /engine/reference/commandline/scout_repo_disable
-title: docker scout repo disable
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/repo/enable.md b/content/reference/cli/docker/scout/repo/enable.md
deleted file mode 100644
index c89bdbb22485..000000000000
--- a/content/reference/cli/docker/scout/repo/enable.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_repo_enable
-aliases:
-- /engine/reference/commandline/scout_repo_enable
-title: docker scout repo enable
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/repo/list.md b/content/reference/cli/docker/scout/repo/list.md
deleted file mode 100644
index e2d2ccbf250e..000000000000
--- a/content/reference/cli/docker/scout/repo/list.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_repo_list
-aliases:
-- /engine/reference/commandline/scout_repo_list
-title: docker scout repo list
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/sbom.md b/content/reference/cli/docker/scout/sbom.md
deleted file mode 100644
index 82c0845da7c9..000000000000
--- a/content/reference/cli/docker/scout/sbom.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_sbom
-aliases:
-- /engine/reference/commandline/scout_sbom
-title: docker scout sbom
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/stream.md b/content/reference/cli/docker/scout/stream.md
deleted file mode 100644
index 967e5e321a9d..000000000000
--- a/content/reference/cli/docker/scout/stream.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_stream
-aliases:
-- /engine/reference/commandline/scout_stream
-title: docker scout stream
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/version.md b/content/reference/cli/docker/scout/version.md
deleted file mode 100644
index defacf3c22b3..000000000000
--- a/content/reference/cli/docker/scout/version.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_version
-aliases:
-- /engine/reference/commandline/scout_version
-title: docker scout version
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/scout/watch.md b/content/reference/cli/docker/scout/watch.md
deleted file mode 100644
index ec817aaaa35f..000000000000
--- a/content/reference/cli/docker/scout/watch.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: scout-cli
-datafile: docker_scout_watch
-aliases:
-- /engine/reference/commandline/scout_watch
-title: docker scout watch
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket in the source
-repository on GitHub:
-
-https://github.com/docker/scout-cli
--->
diff --git a/content/reference/cli/docker/search.md b/content/reference/cli/docker/search.md
deleted file mode 100644
index 74c897401266..000000000000
--- a/content/reference/cli/docker/search.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_search
-title: docker search
-aliases:
-- /edge/engine/reference/commandline/search/
-- /engine/reference/commandline/search/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/secret/_index.md b/content/reference/cli/docker/secret/_index.md
deleted file mode 100644
index bec5640ae097..000000000000
--- a/content/reference/cli/docker/secret/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_secret
-title: docker secret
-aliases:
-- /edge/engine/reference/commandline/secret/
-- /engine/reference/commandline/secret/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/secret/create.md b/content/reference/cli/docker/secret/create.md
deleted file mode 100644
index e8c3a1865900..000000000000
--- a/content/reference/cli/docker/secret/create.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_secret_create
-title: docker secret create
-aliases:
-- /edge/engine/reference/commandline/secret_create/
-- /engine/reference/commandline/secret_create/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/secret/inspect.md b/content/reference/cli/docker/secret/inspect.md
deleted file mode 100644
index 92429e82b5af..000000000000
--- a/content/reference/cli/docker/secret/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_secret_inspect
-title: docker secret inspect
-aliases:
-- /edge/engine/reference/commandline/secret_inspect/
-- /engine/reference/commandline/secret_inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/secret/ls.md b/content/reference/cli/docker/secret/ls.md
deleted file mode 100644
index 73d40f393ae8..000000000000
--- a/content/reference/cli/docker/secret/ls.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_secret_ls
-title: docker secret ls
-aliases:
-- /edge/engine/reference/commandline/secret_ls/
-- /engine/reference/commandline/secret_ls/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/secret/rm.md b/content/reference/cli/docker/secret/rm.md
deleted file mode 100644
index c86ca4d93c69..000000000000
--- a/content/reference/cli/docker/secret/rm.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_secret_rm
-title: docker secret rm
-aliases:
-- /edge/engine/reference/commandline/secret_rm/
-- /engine/reference/commandline/secret_rm/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/service/_index.md b/content/reference/cli/docker/service/_index.md
deleted file mode 100644
index 11b054e42e34..000000000000
--- a/content/reference/cli/docker/service/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_service
-title: docker service
-aliases:
-- /edge/engine/reference/commandline/service/
-- /engine/reference/commandline/service/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/service/create.md b/content/reference/cli/docker/service/create.md
deleted file mode 100644
index 6a5f9cfd71a1..000000000000
--- a/content/reference/cli/docker/service/create.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_service_create
-title: docker service create
-aliases:
-- /edge/engine/reference/commandline/service_create/
-- /engine/reference/commandline/service_create/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/service/inspect.md b/content/reference/cli/docker/service/inspect.md
deleted file mode 100644
index aad0c13e038a..000000000000
--- a/content/reference/cli/docker/service/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_service_inspect
-title: docker service inspect
-aliases:
-- /edge/engine/reference/commandline/service_inspect/
-- /engine/reference/commandline/service_inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/service/logs.md b/content/reference/cli/docker/service/logs.md
deleted file mode 100644
index f99acf98ec57..000000000000
--- a/content/reference/cli/docker/service/logs.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_service_logs
-title: docker service logs
-aliases:
-- /edge/engine/reference/commandline/service_logs/
-- /engine/reference/commandline/service_logs/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/service/ls.md b/content/reference/cli/docker/service/ls.md
deleted file mode 100644
index 1d70d46cceb8..000000000000
--- a/content/reference/cli/docker/service/ls.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_service_ls
-title: docker service ls
-aliases:
-- /edge/engine/reference/commandline/service_ls/
-- /engine/reference/commandline/service_ls/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/service/ps.md b/content/reference/cli/docker/service/ps.md
deleted file mode 100644
index f551b1fe6f46..000000000000
--- a/content/reference/cli/docker/service/ps.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_service_ps
-title: docker service ps
-aliases:
-- /edge/engine/reference/commandline/service_ps/
-- /engine/reference/commandline/service_ps/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/service/rm.md b/content/reference/cli/docker/service/rm.md
deleted file mode 100644
index 482ad1d2c306..000000000000
--- a/content/reference/cli/docker/service/rm.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_service_rm
-title: docker service rm
-aliases:
-- /edge/engine/reference/commandline/service_rm/
-- /engine/reference/commandline/service_rm/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/service/rollback.md b/content/reference/cli/docker/service/rollback.md
deleted file mode 100644
index 98acea5e87e8..000000000000
--- a/content/reference/cli/docker/service/rollback.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_service_rollback
-title: docker service rollback
-aliases:
-- /edge/engine/reference/commandline/service_rollback/
-- /engine/reference/commandline/service_rollback/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/service/scale.md b/content/reference/cli/docker/service/scale.md
deleted file mode 100644
index a2492a757949..000000000000
--- a/content/reference/cli/docker/service/scale.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_service_scale
-title: docker service scale
-aliases:
-- /edge/engine/reference/commandline/service_scale/
-- /engine/reference/commandline/service_scale/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/service/update.md b/content/reference/cli/docker/service/update.md
deleted file mode 100644
index 87ae38bbc397..000000000000
--- a/content/reference/cli/docker/service/update.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_service_update
-title: docker service update
-aliases:
-- /edge/engine/reference/commandline/service_update/
-- /engine/reference/commandline/service_update/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/stack/_index.md b/content/reference/cli/docker/stack/_index.md
deleted file mode 100644
index d9863a514fe9..000000000000
--- a/content/reference/cli/docker/stack/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_stack
-title: docker stack
-aliases:
-- /edge/engine/reference/commandline/stack/
-- /engine/reference/commandline/stack/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/stack/config.md b/content/reference/cli/docker/stack/config.md
deleted file mode 100644
index 26f208fbaa71..000000000000
--- a/content/reference/cli/docker/stack/config.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_stack_config
-aliases:
-- /engine/reference/commandline/stack_config
-title: docker stack config
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/stack/deploy.md b/content/reference/cli/docker/stack/deploy.md
deleted file mode 100644
index 37ad8fe21443..000000000000
--- a/content/reference/cli/docker/stack/deploy.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_stack_deploy
-title: docker stack deploy
-aliases:
-- /compose/bundles/
-- /engine/reference/commandline/deploy/
-- /edge/engine/reference/commandline/deploy/
-- /edge/engine/reference/commandline/stack_deploy/
-- /engine/reference/commandline/stack_deploy/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/stack/ls.md b/content/reference/cli/docker/stack/ls.md
deleted file mode 100644
index a13651863b68..000000000000
--- a/content/reference/cli/docker/stack/ls.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_stack_ls
-title: docker stack ls
-aliases:
-- /edge/engine/reference/commandline/stack_ls/
-- /engine/reference/commandline/stack_ls/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/stack/ps.md b/content/reference/cli/docker/stack/ps.md
deleted file mode 100644
index 1f33f720d29d..000000000000
--- a/content/reference/cli/docker/stack/ps.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_stack_ps
-title: docker stack ps
-aliases:
-- /edge/engine/reference/commandline/stack_ps/
-- /edge/engine/reference/commandline/stack_tasks/
-- /engine/reference/commandline/stack_tasks/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/stack/rm.md b/content/reference/cli/docker/stack/rm.md
deleted file mode 100644
index e0a0ede2db58..000000000000
--- a/content/reference/cli/docker/stack/rm.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_stack_rm
-title: docker stack rm
-aliases:
-- /edge/engine/reference/commandline/stack_rm/
-- /engine/reference/commandline/stack_rm/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/stack/services.md b/content/reference/cli/docker/stack/services.md
deleted file mode 100644
index 53da56760c90..000000000000
--- a/content/reference/cli/docker/stack/services.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_stack_services
-title: docker stack services
-aliases:
-- /edge/engine/reference/commandline/stack_services/
-- /engine/reference/commandline/stack_services/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/swarm/_index.md b/content/reference/cli/docker/swarm/_index.md
deleted file mode 100644
index af4c6e7ca56c..000000000000
--- a/content/reference/cli/docker/swarm/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_swarm
-title: docker swarm
-aliases:
-- /edge/engine/reference/commandline/swarm/
-- /engine/reference/commandline/swarm/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/swarm/ca.md b/content/reference/cli/docker/swarm/ca.md
deleted file mode 100644
index d120ef4d3acc..000000000000
--- a/content/reference/cli/docker/swarm/ca.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_swarm_ca
-title: docker swarm ca
-aliases:
-- /edge/engine/reference/commandline/swarm_ca/
-- /engine/reference/commandline/swarm_ca/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/swarm/init.md b/content/reference/cli/docker/swarm/init.md
deleted file mode 100644
index 726e9b407f33..000000000000
--- a/content/reference/cli/docker/swarm/init.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_swarm_init
-title: docker swarm init
-aliases:
-- /edge/engine/reference/commandline/swarm_init/
-- /engine/reference/commandline/swarm_init/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/swarm/join-token.md b/content/reference/cli/docker/swarm/join-token.md
deleted file mode 100644
index b10d6f2608b6..000000000000
--- a/content/reference/cli/docker/swarm/join-token.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_swarm_join-token
-title: docker swarm join-token
-aliases:
-- /engine/reference/commandline/swarm_join_token/
-- /edge/engine/reference/commandline/swarm_join_token/
-- /edge/engine/reference/commandline/swarm_join-token/
-- /engine/reference/commandline/swarm_join-token/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/swarm/join.md b/content/reference/cli/docker/swarm/join.md
deleted file mode 100644
index ddf0845a71fc..000000000000
--- a/content/reference/cli/docker/swarm/join.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_swarm_join
-title: docker swarm join
-aliases:
-- /edge/engine/reference/commandline/swarm_join/
-- /engine/reference/commandline/swarm_join/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/swarm/leave.md b/content/reference/cli/docker/swarm/leave.md
deleted file mode 100644
index ddb3c1b35a20..000000000000
--- a/content/reference/cli/docker/swarm/leave.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_swarm_leave
-title: docker swarm leave
-aliases:
-- /edge/engine/reference/commandline/swarm_leave/
-- /engine/reference/commandline/swarm_leave/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/swarm/unlock-key.md b/content/reference/cli/docker/swarm/unlock-key.md
deleted file mode 100644
index f30ec750c561..000000000000
--- a/content/reference/cli/docker/swarm/unlock-key.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_swarm_unlock-key
-title: docker swarm unlock-key
-aliases:
-- /edge/engine/reference/commandline/swarm_unlock-key/
-- /engine/reference/commandline/swarm_unlock-key/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/swarm/unlock.md b/content/reference/cli/docker/swarm/unlock.md
deleted file mode 100644
index 51724ed76119..000000000000
--- a/content/reference/cli/docker/swarm/unlock.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_swarm_unlock
-title: docker swarm unlock
-aliases:
-- /edge/engine/reference/commandline/swarm_unlock/
-- /engine/reference/commandline/swarm_unlock/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/swarm/update.md b/content/reference/cli/docker/swarm/update.md
deleted file mode 100644
index f0cf8ea4b626..000000000000
--- a/content/reference/cli/docker/swarm/update.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_swarm_update
-title: docker swarm update
-aliases:
-- /edge/engine/reference/commandline/swarm_update/
-- /engine/reference/commandline/swarm_update/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/system/_index.md b/content/reference/cli/docker/system/_index.md
deleted file mode 100644
index c1157808a3c6..000000000000
--- a/content/reference/cli/docker/system/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_system
-title: docker system
-aliases:
-- /edge/engine/reference/commandline/system/
-- /engine/reference/commandline/system/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/system/df.md b/content/reference/cli/docker/system/df.md
deleted file mode 100644
index 1a94e94b7894..000000000000
--- a/content/reference/cli/docker/system/df.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_system_df
-title: docker system df
-aliases:
-- /edge/engine/reference/commandline/system_df/
-- /engine/reference/commandline/system_df/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/system/events.md b/content/reference/cli/docker/system/events.md
deleted file mode 100644
index d371aeed7d94..000000000000
--- a/content/reference/cli/docker/system/events.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_system_events
-title: docker system events
-aliases:
-- /edge/engine/reference/commandline/system_events/
-- /engine/reference/commandline/system_events/
-- /engine/reference/commandline/events/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/system/info.md b/content/reference/cli/docker/system/info.md
deleted file mode 100644
index 65adda3d3af0..000000000000
--- a/content/reference/cli/docker/system/info.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_system_info
-title: docker system info
-aliases:
-- /edge/engine/reference/commandline/system_info/
-- /engine/reference/commandline/system_info/
-- /engine/reference/commandline/info/
-- /reference/cli/docker/info/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/system/prune.md b/content/reference/cli/docker/system/prune.md
deleted file mode 100644
index ff26aeb36610..000000000000
--- a/content/reference/cli/docker/system/prune.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_system_prune
-title: docker system prune
-aliases:
-- /edge/engine/reference/commandline/system_prune/
-- /engine/reference/commandline/system_prune/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/trust/_index.md b/content/reference/cli/docker/trust/_index.md
deleted file mode 100644
index faa98c2fb767..000000000000
--- a/content/reference/cli/docker/trust/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_trust
-title: docker trust
-aliases:
-- /edge/engine/reference/commandline/trust/
-- /engine/reference/commandline/trust/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/trust/inspect.md b/content/reference/cli/docker/trust/inspect.md
deleted file mode 100644
index 0813f8ce8255..000000000000
--- a/content/reference/cli/docker/trust/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_trust_inspect
-title: docker trust inspect
-aliases:
-- /edge/engine/reference/commandline/trust_inspect/
-- /engine/reference/commandline/trust_inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/trust/key/_index.md b/content/reference/cli/docker/trust/key/_index.md
deleted file mode 100644
index 3540e7e93925..000000000000
--- a/content/reference/cli/docker/trust/key/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_trust_key
-title: docker trust key
-aliases:
-- /edge/engine/reference/commandline/trust_key/
-- /engine/reference/commandline/trust_key/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/trust/key/generate.md b/content/reference/cli/docker/trust/key/generate.md
deleted file mode 100644
index 909995a4d963..000000000000
--- a/content/reference/cli/docker/trust/key/generate.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_trust_key_generate
-title: docker trust key generate
-aliases:
-- /edge/engine/reference/commandline/trust_key_generate/
-- /engine/reference/commandline/trust_key_generate/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/trust/key/load.md b/content/reference/cli/docker/trust/key/load.md
deleted file mode 100644
index 4f13ce52dc35..000000000000
--- a/content/reference/cli/docker/trust/key/load.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_trust_key_load
-title: docker trust key load
-aliases:
-- /edge/engine/reference/commandline/trust_key_load/
-- /engine/reference/commandline/trust_key_load/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/trust/revoke.md b/content/reference/cli/docker/trust/revoke.md
deleted file mode 100644
index 0412a7377bb8..000000000000
--- a/content/reference/cli/docker/trust/revoke.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_trust_revoke
-title: docker trust revoke
-aliases:
-- /edge/engine/reference/commandline/trust_revoke/
-- /engine/reference/commandline/trust_revoke/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/trust/sign.md b/content/reference/cli/docker/trust/sign.md
deleted file mode 100644
index 030fcc22eab5..000000000000
--- a/content/reference/cli/docker/trust/sign.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_trust_sign
-title: docker trust sign
-aliases:
-- /edge/engine/reference/commandline/trust_sign/
-- /engine/reference/commandline/trust_sign/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/trust/signer/_index.md b/content/reference/cli/docker/trust/signer/_index.md
deleted file mode 100644
index 5721d2cf699a..000000000000
--- a/content/reference/cli/docker/trust/signer/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_trust_signer
-title: docker trust signer
-aliases:
-- /edge/engine/reference/commandline/trust_signer/
-- /engine/reference/commandline/trust_signer/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/trust/signer/add.md b/content/reference/cli/docker/trust/signer/add.md
deleted file mode 100644
index 47d9c0507fd5..000000000000
--- a/content/reference/cli/docker/trust/signer/add.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_trust_signer_add
-title: docker trust signer add
-aliases:
-- /edge/engine/reference/commandline/trust_signer_add/
-- /engine/reference/commandline/trust_signer_add/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/trust/signer/remove.md b/content/reference/cli/docker/trust/signer/remove.md
deleted file mode 100644
index d1610c5fcd46..000000000000
--- a/content/reference/cli/docker/trust/signer/remove.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_trust_signer_remove
-title: docker trust signer remove
-aliases:
-- /edge/engine/reference/commandline/trust_signer_remove/
-- /engine/reference/commandline/trust_signer_remove/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/version.md b/content/reference/cli/docker/version.md
deleted file mode 100644
index 342ce41b40d2..000000000000
--- a/content/reference/cli/docker/version.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_version
-title: docker version
-aliases:
-- /edge/engine/reference/commandline/version/
-- /engine/reference/commandline/version/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/volume/_index.md b/content/reference/cli/docker/volume/_index.md
deleted file mode 100644
index 70c9a27707d5..000000000000
--- a/content/reference/cli/docker/volume/_index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_volume
-title: docker volume
-aliases:
-- /edge/engine/reference/commandline/volume/
-- /engine/reference/commandline/volume/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/volume/create.md b/content/reference/cli/docker/volume/create.md
deleted file mode 100644
index ca37e9785a5d..000000000000
--- a/content/reference/cli/docker/volume/create.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_volume_create
-title: docker volume create
-aliases:
-- /edge/engine/reference/commandline/volume_create/
-- /engine/reference/commandline/volume_create/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/volume/inspect.md b/content/reference/cli/docker/volume/inspect.md
deleted file mode 100644
index da72454aeab9..000000000000
--- a/content/reference/cli/docker/volume/inspect.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_volume_inspect
-title: docker volume inspect
-aliases:
-- /edge/engine/reference/commandline/volume_inspect/
-- /engine/reference/commandline/volume_inspect/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/volume/ls.md b/content/reference/cli/docker/volume/ls.md
deleted file mode 100644
index 6fad7cd68233..000000000000
--- a/content/reference/cli/docker/volume/ls.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_volume_ls
-title: docker volume ls
-aliases:
-- /edge/engine/reference/commandline/volume_ls/
-- /engine/reference/commandline/volume_ls/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/volume/prune.md b/content/reference/cli/docker/volume/prune.md
deleted file mode 100644
index 2713f03e227a..000000000000
--- a/content/reference/cli/docker/volume/prune.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_volume_prune
-title: docker volume prune
-aliases:
-- /edge/engine/reference/commandline/volume_prune/
-- /engine/reference/commandline/volume_prune/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/volume/rm.md b/content/reference/cli/docker/volume/rm.md
deleted file mode 100644
index 3c6ac9e30494..000000000000
--- a/content/reference/cli/docker/volume/rm.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_volume_rm
-title: docker volume rm
-aliases:
-- /edge/engine/reference/commandline/volume_rm/
-- /engine/reference/commandline/volume_rm/
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/docker/volume/update.md b/content/reference/cli/docker/volume/update.md
deleted file mode 100644
index fcb11be0b052..000000000000
--- a/content/reference/cli/docker/volume/update.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-datafolder: engine-cli
-datafile: docker_volume_update
-aliases:
-- /engine/reference/commandline/volume_update
-title: docker volume update
-layout: cli
----
-
-<!--
-This page is automatically generated from Docker's source code. If you want to
-suggest a change to the text that appears here, open a ticket or pull request
-in the source repository on GitHub:
-
-https://github.com/docker/cli
--->
diff --git a/content/reference/cli/sbx/_content.gotmpl b/content/reference/cli/sbx/_content.gotmpl
new file mode 100644
index 000000000000..da859fcfaea8
--- /dev/null
+++ b/content/reference/cli/sbx/_content.gotmpl
@@ -0,0 +1,48 @@
+{{- /*
+  Content adapter for sbx CLI reference pages.
+
+  Generates pages from YAML data files in hugo.Data.sbx_cli (cobra/doc format).
+  For each YAML file it creates a page at the command path (spaces → slashes).
+  Commands with child entries in see_also become Hugo sections; others become
+  regular pages.
+*/ -}}
+
+{{- range $name, $data := hugo.Data.sbx_cli -}}
+  {{- if not $data.name -}}
+    {{- continue -}}
+  {{- end -}}
+
+  {{- /* Determine if this command has child commands (from see_also) */ -}}
+  {{- $hasChildren := false -}}
+  {{- $prefix := printf "%s " $data.name -}}
+  {{- with $data.see_also -}}
+    {{- range . -}}
+      {{- $cmd := index (split . " - ") 0 -}}
+      {{- if strings.HasPrefix $cmd $prefix -}}
+        {{- $hasChildren = true -}}
+      {{- end -}}
+    {{- end -}}
+  {{- end -}}
+
+  {{- /* Compute path relative to this adapter (strip "sbx/" prefix) */ -}}
+  {{- $fullPath := replace $data.name " " "/" -}}
+  {{- $kind := cond $hasChildren "section" "page" -}}
+
+  {{- if eq $data.name "sbx" -}}
+    {{- /* Root command is the section index */ -}}
+    {{- $.AddPage (dict
+      "path" "."
+      "title" $data.name
+      "kind" "section"
+      "params" (dict "datafile" $name)
+    ) -}}
+  {{- else -}}
+    {{- $relPath := strings.TrimPrefix "sbx/" $fullPath -}}
+    {{- $.AddPage (dict
+      "path" $relPath
+      "title" $data.name
+      "kind" $kind
+      "params" (dict "datafile" $name)
+    ) -}}
+  {{- end -}}
+{{- end -}}
diff --git a/content/reference/compose-file/_index.md b/content/reference/compose-file/_index.md
index b9624cb6ef01..b4dd9bb29397 100644
--- a/content/reference/compose-file/_index.md
+++ b/content/reference/compose-file/_index.md
@@ -1,59 +1,59 @@
 ---
-description: Find the latest recommended version of the Docker Compose file format
+description:
+  Find the latest recommended version of the Docker Compose file format
   for defining multi-container applications.
-keywords: docker compose file, docker compose yml, docker compose reference, docker
+keywords:
+  docker compose file, docker compose yml, docker compose reference, docker
   compose cmd, docker compose user, docker compose image, yaml spec, docker compose
   syntax, yaml specification, docker compose specification
 title: Compose file reference
 toc_max: 4
 toc_min: 1
 grid:
-- title: Version and name top-level element
-  description: Understand version and name attributes for Compose.
-  icon: text_snippet
-  link: /reference/compose-file/version-and-name/
-- title: Services top-level element
-  description: Explore all services attributes for Compose.
-  icon: construction
-  link: /reference/compose-file/services/
-- title: Networks top-level element
-  description: Find all networks attributes for Compose.
-  icon: lan
-  link: /reference/compose-file/networks/
-- title: Volumes top-level element
-  description: Explore all volumes attributes for Compose.
-  icon: database
-  link: /reference/compose-file/volumes/
-- title: Configs top-level element
-  description: Find out about configs in Compose.
-  icon: settings
-  link: /reference/compose-file/configs/
-- title: Secrets top-level element
-  description: Learn about secrets in Compose.
-  icon: lock
-  link: /reference/compose-file/secrets/
+  - title: Version and name top-level element
+    description: Understand version and name attributes for Compose.
+    icon: document-text
+    link: /reference/compose-file/version-and-name/
+  - title: Services top-level element
+    description: Explore all services attributes for Compose.
+    icon: wrench-screwdriver
+    link: /reference/compose-file/services/
+  - title: Networks top-level element
+    description: Find all networks attributes for Compose.
+    icon: server-stack
+    link: /reference/compose-file/networks/
+  - title: Volumes top-level element
+    description: Explore all volumes attributes for Compose.
+    icon: circle-stack
+    link: /reference/compose-file/volumes/
+  - title: Configs top-level element
+    description: Find out about configs in Compose.
+    icon: cog-6-tooth
+    link: /reference/compose-file/configs/
+  - title: Secrets top-level element
+    description: Learn about secrets in Compose.
+    icon: lock-closed
+    link: /reference/compose-file/secrets/
 aliases:
- - /compose/yaml/
- - /compose/compose-file/compose-file-v1/
- - /compose/compose-file/
- - /compose/reference/overview/
+  - /compose/compose-file/
+  - /compose/reference/overview/
 ---
 
->**New to Docker Compose?**
+> **New to Docker Compose?**
 >
 > Find more information about the [key features and use cases of Docker Compose](/manuals/compose/intro/features-uses.md) or [try the quickstart guide](/manuals/compose/gettingstarted.md).
 
 The Compose Specification is the latest and recommended version of the Compose file format. It helps you define a [Compose file](/manuals/compose/intro/compose-application-model.md) which is used to configure your Docker application’s services, networks, volumes, and more.
 
-Legacy versions 2.x and 3.x of the Compose file format were merged into the Compose Specification. It is implemented in versions 1.27.0 and above (also known as Compose V2) of the Docker Compose CLI.
+Legacy versions 2.x and 3.x of the Compose file format were merged into the Compose Specification. It is implemented in versions 1.27.0 and above (also known as Compose v2) of the Docker Compose CLI.
 
 The Compose Specification on Docker Docs is the Docker Compose implementation. If you wish to implement your own version of the Compose Specification, see the [Compose Specification repository](https://github.com/compose-spec/compose-spec).
 
-Use the following links to navigate key sections of the Compose Specification. 
+Use the following links to navigate key sections of the Compose Specification.
 
 > [!TIP]
 >
 > Want a better editing experience for Compose files in VS Code?
-> Check out the [Docker VS Code Extension (Beta)](https://marketplace.visualstudio.com/items?itemName=docker.docker) for linting, code navigation, and vulnerability scanning.
+> Check out the [Docker DX](https://marketplace.visualstudio.com/items?itemName=docker.docker) extension for linting, code navigation, and vulnerability scanning.
 
 {{< grid >}}
diff --git a/content/reference/compose-file/build.md b/content/reference/compose-file/build.md
index 0d8706611c7c..1d49b79f0e4c 100644
--- a/content/reference/compose-file/build.md
+++ b/content/reference/compose-file/build.md
@@ -2,26 +2,30 @@
 title: Compose Build Specification
 description: Learn about the Compose Build Specification
 keywords: compose, compose specification, compose file reference, compose build specification
-aliases: 
- - /compose/compose-file/build/
+aliases:
+  - /compose/compose-file/build/
 weight: 130
 ---
 
 {{% include "compose/build.md" %}}
 
-In the former case, the whole path is used as a Docker context to execute a Docker build, looking for a canonical
-`Dockerfile` at the root of the directory. The path can be absolute or relative. If it is relative, it is resolved
-from the directory containing your Compose file. If it is absolute, the path prevents the Compose file from being portable so Compose displays a warning. 
+When `build` is specified as a string, the whole path is used as a
+Docker context to execute a Docker build, looking for a canonical
+`Dockerfile` at the root of the directory.
 
-In the latter case, build arguments can be specified, including an alternate `Dockerfile` location. The path can be absolute or relative. If it is relative, it is resolved
-from the directory containing your Compose file. If it is absolute, the path prevents the Compose file from being portable so Compose displays a warning.
+When `build` is specified as a detailed structure, build arguments can
+be specified, including an alternate `Dockerfile` location.
 
-## Using `build` and `image`
+In both cases, the path can be absolute or relative. If it is relative,
+it is resolved from the directory containing your Compose file. If it is
+absolute, the path prevents the Compose file from being portable so
+Compose displays a warning.
 
-When Compose is confronted with both a `build` subsection for a service and an `image` attribute, it follows the rules defined by the [`pull_policy`](services.md#pull_policy) attribute. 
+## Using `build` and `image`
 
-If `pull_policy` is missing from the service definition, Compose attempts to pull the image first and then builds from source if the image isn't found in the registry or platform cache. 
+When Compose is confronted with both a `build` subsection for a service and an `image` attribute, it follows the rules defined by the [`pull_policy`](services.md#pull_policy) attribute.
 
+If `pull_policy` is missing from the service definition, Compose attempts to pull the image first and then builds from source if the image isn't found in the registry or platform cache.
 
 ## Publishing built images
 
@@ -49,9 +53,9 @@ services:
 
 When used to build service images from source, the Compose file creates three Docker images:
 
-* `example/webapp`: A Docker image is built using `webapp` sub-directory, within the Compose file's parent folder, as the Docker build context. Lack of a `Dockerfile` within this folder throws an error.
-* `example/database`: A Docker image is built using `backend` sub-directory within the Compose file parent folder. `backend.Dockerfile` file is used to define build steps, this file is searched relative to the context path, which means `..` resolves to the Compose file's parent folder, so `backend.Dockerfile` is a sibling file.
-* A Docker image is built using the `custom` directory with the user's `$HOME` as the Docker context. Compose displays a warning about the non-portable path used to build image.
+- `example/webapp`: A Docker image is built using `webapp` sub-directory, within the Compose file's folder, as the Docker build context. Lack of a `Dockerfile` within this folder returns an error.
+- `example/database`: A Docker image is built using `backend` sub-directory within the Compose file's folder. `backend.Dockerfile` file is used to define build steps, this file is searched relative to the context path, which means `..` resolves to the Compose file's folder, so `backend.Dockerfile` is a sibling file.
+- A Docker image is built using the `custom` directory with the user's `$HOME` as the Docker context. Compose displays a warning about the non-portable path used to build image.
 
 On push, both `example/webapp` and `example/database` Docker images are pushed to the default registry. The `custom` service image is skipped as no `image` attribute is set and Compose displays a warning about this missing attribute.
 
@@ -61,7 +65,8 @@ The `build` subsection defines configuration options that are applied by Compose
 `build` can be specified either as a string containing a path to the build context or as a detailed structure:
 
 Using the string syntax, only the build context can be configured as either:
-- A relative path to the Compose file's parent folder. This path must be a directory and must contain a `Dockerfile`
+
+- A relative path to the Compose file's folder. This path must be a directory and must contain a `Dockerfile`
 
   ```yml
   services:
@@ -70,8 +75,8 @@ Using the string syntax, only the build context can be configured as either:
   ```
 
 - A Git repository URL. Git URLs accept context configuration in their fragment section, separated by a colon (`:`).
-The first part represents the reference that Git checks out, and can be either a branch, a tag, or a remote reference.
-The second part represents a subdirectory inside the repository that is used as a build context.
+  The first part represents the reference that Git checks out, and can be either a branch, a tag, or a remote reference.
+  The second part represents a subdirectory inside the repository that is used as a build context.
 
   ```yml
   services:
@@ -115,8 +120,8 @@ must be prefixed to avoid ambiguity with a `type://` prefix.
 Compose warns you if the image builder does not support additional contexts and may list
 the unused contexts.
 
-Illustrative examples of how this is used in Buildx can be found
-[here](https://github.com/docker/buildx/blob/master/docs/reference/buildx_build.md#-additional-build-contexts---build-context).
+Refer to the reference documentation for [`docker buildx build --build-context`](https://github.com/docker/buildx/blob/master/docs/reference/buildx_build.md#-additional-build-contexts---build-context)
+for example usage.
 
 `additional_contexts` can also refer to an image built by another service.
 This allows a service image to be built using another service image as a base image, and to share
@@ -124,20 +129,20 @@ layers between service images.
 
 ```yaml
 services:
- base:
-  build:
-    context: .
-    dockerfile_inline: |
-      FROM alpine
-      RUN ...
- my-service:
-  build:
-    context: .
-    dockerfile_inline: |
-      FROM base # image built for service base
-      RUN ...
-    additional_contexts:
-      base: service:base
+  base:
+    build:
+      context: .
+      dockerfile_inline: |
+        FROM alpine
+        RUN ...
+  my-service:
+    build:
+      context: .
+      dockerfile_inline: |
+        FROM base # image built for service base
+        RUN ...
+      additional_contexts:
+        base: service:base
 ```
 
 ### `args`
@@ -175,27 +180,6 @@ args:
   - GIT_COMMIT
 ```
 
-### `context`
-
-`context` defines either a path to a directory containing a Dockerfile, or a URL to a Git repository.
-
-When the value supplied is a relative path, it is interpreted as relative to the project directory.
-Compose warns you about the absolute path used to define the build context as those prevent the Compose file
-from being portable.
-
-```yml
-build:
-  context: ./dir
-```
-
-```yml
-services:
-  webapp:
-    build: https://github.com/mycompany/webapp.git
-```
-
-If not set explicitly, `context` defaults to project directory (`.`). 
-
 ### `cache_from`
 
 `cache_from` defines a list of sources the image builder should use for cache resolution.
@@ -206,7 +190,6 @@ Compose Build implementations may support custom types, the Compose Specificatio
 
 - `registry` to retrieve build cache from an OCI image set by key `ref`
 
-
 ```yml
 build:
   context: .
@@ -226,14 +209,35 @@ Unsupported caches are ignored and don't prevent you from building images.
 build:
   context: .
   cache_to:
-   - user/app:cache
-   - type=local,dest=path/to/cache
+    - user/app:cache
+    - type=local,dest=path/to/cache
 ```
 
 Cache target is defined using the same `type=TYPE[,KEY=VALUE]` syntax defined by [`cache_from`](#cache_from).
 
 Unsupported caches are ignored and don't prevent you from building images.
 
+### `context`
+
+`context` defines either a path to a directory containing a Dockerfile, or a URL to a Git repository.
+
+When the value supplied is a relative path, it is interpreted as relative to the project directory.
+Compose warns you about the absolute path used to define the build context as those prevent the Compose file
+from being portable.
+
+```yml
+build:
+  context: ./dir
+```
+
+```yml
+services:
+  webapp:
+    build: https://github.com/mycompany/webapp.git
+```
+
+If not set explicitly, `context` defaults to project directory (`.`).
+
 ### `dockerfile`
 
 `dockerfile` sets an alternate Dockerfile. A relative path is resolved from the build context.
@@ -272,11 +276,11 @@ build:
 
 `entitlements` defines extra privileged entitlements to be allowed during the build.
 
- ```yaml
- entitlements:
-   - network.host
-   - security.insecure
- ```
+```yaml
+entitlements:
+  - network.host
+  - security.insecure
+```
 
 ### `extra_hosts`
 
@@ -288,6 +292,7 @@ extra_hosts:
   - "otherhost=50.31.209.229"
   - "myhostv6=::1"
 ```
+
 IPv6 addresses can be enclosed in square brackets, for example:
 
 ```yml
@@ -295,7 +300,7 @@ extra_hosts:
   - "myhostv6=[::1]"
 ```
 
-The separator `=` is preferred, but `:` can also be used. Introduced in Docker Compose version [2.24.1](/manuals/compose/releases/release-notes.md#2241). For example:
+The separator `=` is preferred, but `:` can also be used. Introduced in Docker Compose version [2.24.1](https://github.com/docker/compose/releases/tag/v2.24.1). For example:
 
 ```yml
 extra_hosts:
@@ -343,21 +348,19 @@ build:
 
 ### `network`
 
-Set the network containers connect to for the `RUN` instructions during build.
+Set the networking mode for `RUN` instructions during the build. This is
+the same as [`docker build --network`](/reference/cli/docker/buildx/build/#network).
+It is not a Compose network from the top-level [`networks`](networks.md) key.
 
-```yaml
-build:
-  context: .
-  network: host
-```  
+The value is a mode (`default`, `none`, or `host`), not a network name:
 
 ```yaml
 build:
   context: .
-  network: custom_network_1
+  network: host
 ```
 
-Use `none` to disable networking during build:
+Use `none` to disable networking during the build:
 
 ```yaml
 build:
@@ -390,6 +393,7 @@ When the `platforms` attribute is defined, Compose includes the service's
 platform, otherwise users won't be able to run images they built.
 
 Composes reports an error in the following cases:
+
 - When the list contains multiple platforms but the implementation is incapable of storing multi-platform images.
 - When the list contains an unsupported platform.
 
@@ -400,6 +404,7 @@ Composes reports an error in the following cases:
       - "linux/amd64"
       - "unsupported/unsupported"
   ```
+
 - When the list is non-empty and does not contain the service's platform.
 
   ```yml
@@ -424,11 +429,52 @@ build:
   privileged: true
 ```
 
+### `provenance`
+
+{{< summary-bar feature_name="Compose provenance" >}}
+
+`provenance` configures the builder to add a [provenance attestation](https://slsa.dev/provenance/v0.2#schema) to the published image.
+
+The value can be either a boolean to enable/disable provenance attestation, or a key=value string to set provenance configuration. You can
+use this to select the level of detail to be included in the provenance attestation by setting the `mode` parameter.
+
+```yaml
+build:
+  context: .
+  provenance: true
+```
+
+```yaml
+build:
+  context: .
+  provenance: mode=max
+```
+
 ### `pull`
 
 `pull` requires the image builder to pull referenced images (`FROM` Dockerfile directive), even if those are already
 available in the local image store.
 
+### `sbom`
+
+{{< summary-bar feature_name="Compose sbom" >}}
+
+`sbom` configures the builder to add a [provenance attestation](https://slsa.dev/provenance/v0.2#schema) to the published image.
+The value can be either a boolean to enable/disable sbom attestation, or a key=value string to set SBOM generator configuration. This let you
+select an alternative SBOM generator image (see https://github.com/moby/buildkit/blob/master/docs/attestations/sbom-protocol.md)
+
+```yaml
+build:
+  context: .
+  sbom: true
+```
+
+```yaml
+build:
+  context: .
+  sbom: generator=docker/scout-sbom-indexer:latest # Use an alternative SBOM generator
+```
+
 ### `secrets`
 
 `secrets` grants access to sensitive data defined by [secrets](services.md#secrets) on a per-service build basis. Two
@@ -466,8 +512,7 @@ The long syntax provides more granularity in how the secret is created within
 the service's containers.
 
 - `source`: The name of the secret as it exists on the platform.
-- `target`: The name of the file to be mounted in `/run/secrets/` in the
-  service's task containers. Defaults to `source` if not specified.
+- `target`: The ID of the secret as declared in the Dockerfile. Defaults to `source` if not specified.
 - `uid` and `gid`: The numeric uid or gid that owns the file within
   `/run/secrets/` in the service's task containers. Default value is `USER`.
 - `mode`: The [permissions](https://wintelguy.com/permissions-calc.pl) for the file to be mounted in `/run/secrets/`
@@ -487,7 +532,7 @@ services:
       context: .
       secrets:
         - source: server-certificate
-          target: server.cert
+          target: cert # secret ID in Dockerfile
           uid: "103"
           gid: "103"
           mode: 0440
@@ -496,6 +541,12 @@ secrets:
     external: true
 ```
 
+```dockerfile
+# Dockerfile
+FROM nginx
+RUN --mount=type=secret,id=cert,required=true,target=/root/cert ...
+```
+
 Service builds may be granted access to multiple secrets. Long and short syntax for secrets may be used in the
 same Compose file. Defining a secret in the top-level `secrets` must not imply granting any service build access to it.
 Such grant must be explicit within service specification as [secrets](services.md#secrets) service element.
@@ -505,23 +556,27 @@ Such grant must be explicit within service specification as [secrets](services.m
 `ssh` defines SSH authentications that the image builder should use during image build (e.g., cloning private repository).
 
 `ssh` property syntax can be either:
-* `default`: Let the builder connect to the SSH-agent.
-* `ID=path`: A key/value definition of an ID and the associated path. It can be either a [PEM](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) file, or path to ssh-agent socket.
+
+- `default`: Let the builder connect to the SSH-agent.
+- `ID=path`: A key/value definition of an ID and the associated path. It can be either a [PEM](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) file, or path to ssh-agent socket.
 
 ```yaml
 build:
   context: .
   ssh:
-    - default   # mount the default SSH agent
+    - default # mount the default SSH agent
 ```
+
 or
+
 ```yaml
 build:
   context: .
-  ssh: ["default"]   # mount the default SSH agent
+  ssh: ["default"] # mount the default SSH agent
 ```
 
 Using a custom id `myproject` with path to a local SSH key:
+
 ```yaml
 build:
   context: .
@@ -545,7 +600,7 @@ as an integer value representing the number of bytes or as a string expressing a
 ```yml
 build:
   context: .
-  shm_size: '2gb'
+  shm_size: "2gb"
 ```
 
 ```yaml
diff --git a/content/reference/compose-file/configs.md b/content/reference/compose-file/configs.md
index c8251406beb0..860f16895e90 100644
--- a/content/reference/compose-file/configs.md
+++ b/content/reference/compose-file/configs.md
@@ -1,6 +1,7 @@
 ---
-title: Configs top-level elements
-description: Explore all the attributes the configs top-level element can have.
+linkTitle: Configs 
+title: Configs top-level element
+description: Manage and share configuration data using the configs element in Docker Compose.
 keywords: compose, compose specification, configs, compose file reference
 aliases: 
  - /compose/compose-file/08-configs/
@@ -15,11 +16,11 @@ By default, the config:
 - Is owned by the user running the container command but can be overridden by service configuration.
 - Has world-readable permissions (mode 0444), unless the service is configured to override this.
 
-The top-level `configs` declaration defines or references configuration data that is granted to services in your Compose application. The source of the config is either `file` or `external`.
+The top-level `configs` declaration defines or references configuration data that is granted to services in your Compose application. The source of the config is either `file`, `environment`, `content`, or `external`.
 
 - `file`: The config is created with the contents of the file at the specified path.
-- `environment`: The config content is created with the value of an environment variable. Introduced in Docker Compose version [2.23.1](/manuals/compose/releases/release-notes.md#2231).
-- `content`: The content is created with the inlined value. Introduced in Docker Compose version [2.23.1](/manuals/compose/releases/release-notes.md#2231).
+- `environment`: The config content is created with the value of an environment variable. Introduced in Docker Compose version [2.23.1](https://github.com/docker/compose/releases/tag/v2.23.1).
+- `content`: The content is created with the inlined value. Introduced in Docker Compose version [2.23.1](https://github.com/docker/compose/releases/tag/v2.23.1).
 - `external`: If set to true, `external` specifies that this config has already been created. Compose does not
   attempt to create it, and if it does not exist, an error occurs.
 - `name`: The name of the config object in the container engine to look up. This field can be used to
@@ -47,6 +48,21 @@ configs:
 
 ## Example 2
 
+External configs lookup can also use a distinct key by specifying a `name`.
+
+The following
+example modifies the previous one to look up a config using the parameter `HTTP_CONFIG_KEY`. The actual lookup key is set at deployment time by the [interpolation](interpolation.md) of
+variables, but exposed to containers as hard-coded ID `http_config`.
+
+```yml
+configs:
+  http_config:
+    external: true
+    name: "${HTTP_CONFIG_KEY}"
+```
+
+## Example 3
+
 `<project_name>_app_config` is created when the application is deployed,
 by registering the inlined content as the configuration data. This means Compose infers variables when creating the config, which allows you to
 adjust content according to service configuration:
@@ -60,19 +76,15 @@ configs:
       spring.application.name=${COMPOSE_PROJECT_NAME}
 ```
 
-## Example 3
+## Example 4
 
-External configs lookup can also use a distinct key by specifying a `name`. 
-
-The following
-example modifies the previous one to look up a config using the parameter `HTTP_CONFIG_KEY`. The actual lookup key is set at deployment time by the [interpolation](interpolation.md) of
-variables, but exposed to containers as hard-coded ID `http_config`.
+`<project_name>_simple_config` is created when the application is deployed,
+using the value of an environment variable as the configuration data. This is useful for simple configuration values that don’t require interpolation:
 
 ```yml
 configs:
-  http_config:
-    external: true
-    name: "${HTTP_CONFIG_KEY}"
+  simple_config:
+    environment: "SIMPLE_CONFIG_VALUE"
 ```
 
 If `external` is set to `true`, all other attributes apart from `name` are irrelevant. If Compose detects any other attribute, it rejects the Compose file as invalid.
diff --git a/content/reference/compose-file/deploy.md b/content/reference/compose-file/deploy.md
index 602a4af09a49..4388267e104b 100644
--- a/content/reference/compose-file/deploy.md
+++ b/content/reference/compose-file/deploy.md
@@ -84,7 +84,7 @@ services:
 > - Completed tasks remain until explicitly removed.
 > - Options like `max-concurrent` for controlling concurrency are supported only via the CLI and are not available in Compose.
 
-For more detailed information about job options and behavior, see the [Docker CLI documentation](/reference/cli/docker/service/create.md#running-as-a-job)
+For more detailed information about job options and behavior, see the [Docker CLI documentation](/reference/cli/docker/service/create/#running-as-a-job)
 
 ### `placement`
 
@@ -92,19 +92,19 @@ For more detailed information about job options and behavior, see the [Docker CL
 
 #### `constraints`
 
-`constraints` defines a required property the platform's node must fulfill to run the service container. For a further example, see the [CLI reference docs](/reference/cli/docker/service/create.md#constraint).
+`constraints` defines a required property the platform's node must fulfill to run the service container. For a further example, see the [CLI reference docs](/reference/cli/docker/service/create/#constraint).
 
 ```yml
 deploy:
   placement:
     constraints:
-      - disktype=ssd
+      - node.labels.disktype==ssd
 ```
 
 #### `preferences`
 
 `preferences` defines a strategy (currently `spread` is the only supported strategy) to spread tasks evenly 
-over the values of the datacenter node label. For a further example, see the [CLI reference docs](/reference/cli/docker/service/create.md#placement-pref)
+over the values of the datacenter node label. For a further example, see the [CLI reference docs](/reference/cli/docker/service/create/#placement-pref)
 
 ```yml
 deploy:
@@ -132,7 +132,7 @@ services:
 `resources` configures physical resource constraints for container to run on platform. Those constraints can be configured
 as:
 
-- `limits`: The platform must prevent the container to allocate more.
+- `limits`: The platform must prevent the container from allocating more resources.
 - `reservations`: The platform must guarantee the container can allocate at least the configured amount.
 
 ```yml
@@ -270,7 +270,7 @@ deploy:
 
 ### `rollback_config`
 
-`rollback_config` configures how the service should be rollbacked in case of a failing update.
+`rollback_config` configures how the service should be rolled back in case of a failing update.
 
 - `parallelism`: The number of containers to rollback at a time. If set to 0, all containers rollback simultaneously.
 - `delay`: The time to wait between each container group's rollback (default 0s).
diff --git a/content/reference/compose-file/develop.md b/content/reference/compose-file/develop.md
index ba4c5c0c32d4..4fd1edab779c 100644
--- a/content/reference/compose-file/develop.md
+++ b/content/reference/compose-file/develop.md
@@ -11,7 +11,7 @@ weight: 150
 >
 > Develop is an optional part of the Compose Specification. It is available with Docker Compose version 2.22.0 and later.
 
-{{% include "compose/develop.md" %}}
+{{% include "compose/services-develop.md" %}}
 
 This page defines how Compose behaves to efficiently assist you and defines the development constraints and workflows set by Compose. Only a subset of Compose file services may require a `develop` subsection.
 
@@ -43,8 +43,6 @@ services:
 
 ## Attributes
 
-<!-- vale Docker.HeadingSentenceCase = NO ) -->
-
 The `develop` subsection defines configuration options that are applied by Compose to assist you during development of a service with optimized workflows.
 
 ### `watch`
@@ -90,7 +88,7 @@ services:
 
 #### `ignore`
 
-The `ignore` attribute can be used to define a list of patterns for paths to be ignored. Any updated file
+The `ignore` attribute is used to define a list of patterns for paths to be ignored. Any updated file
 that matches a pattern, or belongs to a folder that matches a pattern, won't trigger services to be re-created. 
 The syntax is the same as `.dockerignore` file: 
 
@@ -106,7 +104,7 @@ for the `ignores` file, and values set in the Compose model are appended.
 
 It is sometimes easier to select files to be watched instead of declaring those that shouldn't be watched with `ignore`.
 
-The `include` attribute can be used to define a pattern, or a list of patterns, for paths to be considered for watching.
+The `include` attribute is used to define a pattern, or a list of patterns, for paths to be considered for watching.
 Only files that match these patterns will be considered when applying a watch rule. The syntax is the same as `ignore`.
 
 ```yaml
@@ -117,10 +115,21 @@ services:
       watch: 
         # rebuild image and recreate service
         - path: ./src
-          include: *.go  
+          include: "*.go"  
           action: rebuild
 ```
 
+> [!NOTE]
+> 
+> In many cases `include` patterns start with a wildcard (`*`) character. This has special meaning in YAML syntax
+> to define an [alias node](https://yaml.org/spec/1.2.2/#alias-nodes) so you have to wrap pattern expression with quotes.
+
+#### `initial_sync`
+
+When using `sync+x` actions, it can be useful to ensure that files inside containers are up to date at the start of a new watch session.
+
+The `initial_sync` attribute instructs the Compose runtime, if containers for the service already exist, to check that the files from the path attribute are in sync within the service containers.
+
 #### `path`
 
 `path` attribute defines the path to source code (relative to the project directory) to monitor for changes. Updates to any file
diff --git a/content/reference/compose-file/extension.md b/content/reference/compose-file/extension.md
index 9ad4fee12fad..b7dde48cd9df 100644
--- a/content/reference/compose-file/extension.md
+++ b/content/reference/compose-file/extension.md
@@ -1,6 +1,6 @@
 ---
 title: Extensions
-description: Understand how to use extensions
+description: Define and reuse custom fragments with extensions in Docker Compose
 keywords: compose, compose specification, extensions, compose file reference
 aliases: 
  - /compose/compose-file/11-extension/
@@ -117,7 +117,7 @@ services:
 >
 > In the example above, the environment variables are declared using the `FOO: BAR` mapping syntax, while the sequence syntax `- FOO=BAR` is only valid when no fragments are involved.
 
-## Informative Historical Notes
+## Informative historical notes
 
 This section is informative. At the time of writing, the following prefixes are known to exist:
 
diff --git a/content/reference/compose-file/fragments.md b/content/reference/compose-file/fragments.md
index 29cc060f9814..d69e639a4546 100644
--- a/content/reference/compose-file/fragments.md
+++ b/content/reference/compose-file/fragments.md
@@ -1,6 +1,6 @@
 ---
 title: Fragments
-description: Understand how to use fragments
+description: Reuse configuration with YAML anchors and fragments
 keywords: compose, compose specification, fragments, compose file reference
 aliases: 
  - /compose/compose-file/10-fragments/
diff --git a/content/reference/compose-file/include.md b/content/reference/compose-file/include.md
index a04edb353004..f1a01d925318 100644
--- a/content/reference/compose-file/include.md
+++ b/content/reference/compose-file/include.md
@@ -1,6 +1,7 @@
 ---
-title: Include
-description: Learn about include
+linkTitle: Include
+title: Use include to modularize Compose files
+description: Reference external Compose files using the include top-level element
 keywords: compose, compose specification, include, compose file reference
 aliases:
  - /compose/compose-file/14-include/
@@ -9,10 +10,10 @@ weight: 110
 
 {{< summary-bar feature_name="Composefile include" >}}
 
-A Compose application can declare dependency on another Compose application. This is useful if:
+You can reuse and modularize Docker Compose configurations by including other Compose files. This is useful if:
 - You want to reuse other Compose files.
 - You need to factor out parts of your application model into separate Compose files so they can be managed separately or shared with others.
-- Teams need to keep a Compose file reasonably complicated for the limited amount of resources it has to declare for its own sub-domain within a larger deployment.
+- Teams need to maintain a Compose file with only necessary complexity for the limited amount of resources it has to declare for its own sub-domain within a larger deployment.
 
 The `include` top-level section is used to define the dependency on another Compose application, or sub-domain.
 Each path listed in the `include` section is loaded as an individual Compose application model, with its own project directory, in order to resolve relative paths.
diff --git a/content/reference/compose-file/interpolation.md b/content/reference/compose-file/interpolation.md
index 23b3fd585237..24727daf3f81 100644
--- a/content/reference/compose-file/interpolation.md
+++ b/content/reference/compose-file/interpolation.md
@@ -1,6 +1,6 @@
 ---
 title: Interpolation
-description: Learn about interpolation
+description: Substitute environment variables in Docker Compose files using interpolation syntax.
 keywords: compose, compose specification, interpolation, compose file reference
 aliases: 
  - /compose/compose-file/12-interpolation/
diff --git a/content/reference/compose-file/legacy-versions.md b/content/reference/compose-file/legacy-versions.md
index d604311e1577..d95e4531a2bf 100644
--- a/content/reference/compose-file/legacy-versions.md
+++ b/content/reference/compose-file/legacy-versions.md
@@ -6,7 +6,6 @@ aliases:
  - /compose/compose-file/compose-versioning/
  - /compose/compose-file/compose-file-v3/
  - /compose/compose-file/compose-file-v2/
- - /compose/compose-file/legacy-versions/
 ---
 
 The legacy versions of the Compose file reference has moved to the [V1 branch of the Compose repository](https://github.com/docker/compose/tree/v1/docs). They are no longer being actively maintained. 
diff --git a/content/reference/compose-file/merge.md b/content/reference/compose-file/merge.md
index 7b9a5784831d..3c1cb1f41164 100644
--- a/content/reference/compose-file/merge.md
+++ b/content/reference/compose-file/merge.md
@@ -1,6 +1,7 @@
 ---
-title: Merge
-description: Learn about merging rules
+linkTitle: Merge
+title: Merge Compose files
+description: Understand how Docker Compose merges multiple files and resolves conflicts
 keywords: compose, compose specification, merge, compose file reference
 aliases: 
  - /compose/compose-file/13-merge/
diff --git a/content/reference/compose-file/models.md b/content/reference/compose-file/models.md
new file mode 100644
index 000000000000..631bdf8e6113
--- /dev/null
+++ b/content/reference/compose-file/models.md
@@ -0,0 +1,69 @@
+---
+title: Models
+description: Learn about the models top-level element
+keywords: compose, compose specification, models, compose file reference
+weight: 120
+---
+
+{{< summary-bar feature_name="Compose models" >}}
+
+The top-level `models` section declares AI models that are used by your Compose application. These models are typically pulled as OCI artifacts, run by a model runner, and exposed as an API that your service containers can consume.
+
+Services can only access models when explicitly granted by a [`models` attribute](services.md#models) within the `services` top-level element.
+
+## Examples
+
+### Example 1
+
+```yaml
+services:
+  app:
+    image: app
+    models:
+      - ai_model
+
+
+models:
+  ai_model:
+    model: ai/model
+```
+
+In this basic example:
+
+ - The app service uses the `ai_model`.
+ - The `ai_model` is defined as an OCI artifact (`ai/model`) that is pulled and served by the model runner.
+ - Docker Compose injects connection info, for example `AI_MODEL_URL`, into the container. 
+
+### Example 2
+
+```yaml
+services:
+  app:
+    image: app
+    models:
+      my_model:
+        endpoint_var: MODEL_URL
+
+models:
+  my_model:
+    model: ai/model
+    context_size: 1024
+    runtime_flags: 
+      - "--a-flag"
+      - "--another-flag=42"
+```
+
+In this advanced setup:
+
+ - The service app references `my_model` using the long syntax.
+ - Compose injects the model runner's URL as the environment variable `MODEL_URL`.
+
+## Attributes
+
+- `model` (required): The OCI artifact identifier for the model. This is what Compose pulls and runs via the model runner. 
+- `context_size`: Defines the maximum token context size for the model.
+- `runtime_flags`: A list of raw command-line flags passed to the inference engine when the model is started.
+
+## Additional resources
+
+For more examples and information on using `model`, see [Use AI models in Compose](/manuals/ai/compose/models-and-compose.md)
\ No newline at end of file
diff --git a/content/reference/compose-file/networks.md b/content/reference/compose-file/networks.md
index c8c30a3e1b58..bc1ea51c8690 100644
--- a/content/reference/compose-file/networks.md
+++ b/content/reference/compose-file/networks.md
@@ -1,6 +1,7 @@
 ---
-title: Networks top-level elements
-description: Explore all the attributes the networks top-level element can have.
+linkTitle: Networks
+title: Define and manage networks in Docker Compose
+description: Learn how to configure and control networks using the top-level networks element in Docker Compose.
 keywords: compose, compose specification, networks, compose file reference
 aliases:
  - /compose/compose-file/06-networks/
@@ -45,7 +46,7 @@ services:
       - frontend
       - backend
   db:
-    image: postgres
+    image: postgres:18
     networks:
       - backend
 
@@ -60,7 +61,7 @@ networks:
     driver: custom-driver
 ```
 
-The advanced example shows a Compose file which defines two custom networks. The `proxy` service is isolated from the `db` service, because they do not share a network in common. Only `app` can talk to both.
+This example shows a Compose file which defines two custom networks. The `proxy` service is isolated from the `db` service, because they do not share a network in common. Only `app` can talk to both.
 
 ## The default network
 
@@ -98,6 +99,19 @@ For options, see the [Docker Engine docs](https://docs.docker.com/engine/network
 
 ## Attributes
 
+### `attachable`
+
+If `attachable` is set to `true`, then standalone containers should be able to attach to this network, in addition to services.
+If a standalone container attaches to the network, it can communicate with services and other standalone containers
+that are also attached to the network.
+
+```yml
+networks:
+  mynet1:
+    driver: overlay
+    attachable: true
+```
+
 ### `driver`
 
 `driver` specifies which driver should be used for this network. Compose returns an error if the
@@ -126,19 +140,6 @@ networks:
 
 Consult the [network drivers documentation](/manuals/engine/network/_index.md) for more information.
 
-### `attachable`
-
-If `attachable` is set to `true`, then standalone containers should be able to attach to this network, in addition to services.
-If a standalone container attaches to the network, it can communicate with services and other standalone containers
-that are also attached to the network.
-
-```yml
-networks:
-  mynet1:
-    driver: overlay
-    attachable: true
-```
-
 ### `enable_ipv4`
 
 {{< summary-bar feature_name="Compose enable ipv4" >}}
@@ -170,7 +171,7 @@ Compose doesn't attempt to create these networks, and returns an error if one do
  - All other attributes apart from name are irrelevant. If Compose detects any other attribute, it rejects the Compose file as invalid.
 
 In the following example, `proxy` is the gateway to the outside world. Instead of attempting to create a network, Compose
-queries the platform for an existing network simply called `outside` and connects the
+queries the platform for an existing network called `outside` and connects the
 `proxy` service's containers to it.
 
 ```yml
diff --git a/content/reference/compose-file/profiles.md b/content/reference/compose-file/profiles.md
index 144c6fd75628..37acdcf00580 100644
--- a/content/reference/compose-file/profiles.md
+++ b/content/reference/compose-file/profiles.md
@@ -1,5 +1,6 @@
 ---
-title: Profiles
+linkTitle: Profiles
+title: Learn how to use profiles in Docker Compose
 description: Learn about profiles
 keywords: compose, compose specification, profiles, compose file reference
 aliases: 
@@ -52,7 +53,7 @@ services:
 
 In the above example:
 
-- If the Compose application model is parsed with no profile enabled, it only contains the `web` service.
+- If the Compose application model is parsed when no profile is enabled, it only contains the `web` service.
 - If the profile `test` is enabled, the model contains the services `test_lib` and `coverage_lib`, and service `web`, which is always enabled.
 - If the profile `debug` is enabled, the model contains both `web` and `debug_lib` services, but not `test_lib` and `coverage_lib`,
   and as such the model is invalid regarding the `depends_on` constraint of `debug_lib`.
@@ -68,4 +69,4 @@ In the above example:
   profile `debug` is automatically enabled and service `test_lib` is pulled in as a dependency starting both
   services `debug_lib` and `test_lib`.
 
-See how you can use `profiles` in [Docker Compose](/manuals/compose/how-tos/profiles.md).
+Learn how to use `profiles` in [Docker Compose](/manuals/compose/how-tos/profiles.md).
diff --git a/content/reference/compose-file/secrets.md b/content/reference/compose-file/secrets.md
index 5fe118b77b20..07870fbbf96d 100644
--- a/content/reference/compose-file/secrets.md
+++ b/content/reference/compose-file/secrets.md
@@ -1,13 +1,13 @@
 ---
-title: Secrets top-level elements
+title: Secrets
 description: Explore all the attributes the secrets top-level element can have.
 keywords: compose, compose specification, secrets, compose file reference
-aliases: 
+aliases:
  - /compose/compose-file/09-secrets/
 weight: 60
 ---
 
-Secrets are a flavor of [Configs](configs.md) focusing on sensitive data, with specific constraint for this usage. 
+Secrets are a flavor of [Configs](configs.md) focusing on sensitive data, with specific constraint for this usage.
 
 Services can only access secrets when explicitly granted by a [`secrets` attribute](services.md#secrets) within the `services` top-level element.
 
@@ -15,7 +15,8 @@ The top-level `secrets` declaration defines or references sensitive data that is
 application. The source of the secret is either `file` or `environment`.
 
 - `file`: The secret is created with the contents of the file at the specified path.
-- `environment`: The secret is created with the value of an environment variable on the host.
+- `environment`: The secret is created with the value of an environment variable on the host. This is only supported by Docker Compose. It is not supported when deploying with [`docker stack deploy`](/manuals/engine/swarm/stack-deploy.md).
+ 
 
 ## Example 1
 
@@ -28,9 +29,9 @@ secrets:
     file: ./server.cert
 ```
 
-## Example 2 
+## Example 2
 
-`token` secret  is created as `<project_name>_token` when the application is deployed,
+`token` secret is created as `<project_name>_token` when the application is deployed,
 by registering the content of the `OAUTH_TOKEN` environment variable as a platform secret.
 
 ```yml
@@ -39,6 +40,10 @@ secrets:
     environment: "OAUTH_TOKEN"
 ```
 
+> [!NOTE]
+> `environment` secrets are not supported when deploying with `docker stack deploy`.
+> Use `file` or `external` as the secret source instead.
+
 ## Additional resources
 
 For more information, see [How to use secrets in Compose](/manuals/compose/how-tos/use-secrets.md).
diff --git a/content/reference/compose-file/services.md b/content/reference/compose-file/services.md
index 56eb4e95f3d9..59ceb4e44fe7 100644
--- a/content/reference/compose-file/services.md
+++ b/content/reference/compose-file/services.md
@@ -1,5 +1,6 @@
 ---
-title: Services top-level elements
+linkTitle: Services
+title: Define services in Docker Compose
 description: Explore all the attributes the services top-level element can have.
 keywords: compose, compose specification, services, compose file reference
 aliases:
@@ -37,15 +38,15 @@ services:
       - "8080:80"
 
   db:
-    image: postgres:13
+    image: postgres:18
     environment:
       POSTGRES_USER: example
       POSTGRES_DB: exampledb
 ```
 
-### Advanced example 
+### Advanced example
 
-In the following example, the `proxy` service uses the Nginx image, mounts a local Nginx configuration file into the container, exposes port `80` and depends on the `backend` service. 
+In the following example, the `proxy` service uses the Nginx image, mounts a local Nginx configuration file into the container, exposes port `80` and depends on the `backend` service.
 
 The `backend` service builds an image from the Dockerfile located in the `backend` directory that is set to build at stage `builder`.
 
@@ -318,7 +319,7 @@ The long syntax provides more granularity in how the config is created within th
 - `target`: The path and name of the file to be mounted in the service's
   task containers. Defaults to `/<source>` if not specified.
 - `uid` and `gid`: The numeric uid or gid that owns the mounted config file
-  within the service's task containers. Default value when not specified is `USER`.
+  within the service's task containers.
 - `mode`: The [permissions](https://wintelguy.com/permissions-calc.pl) for the file that is mounted within the service's
   task containers, in octal notation. Default value is world-readable (`0444`).
   Writable bit must be ignored. The executable bit can be set.
@@ -376,7 +377,9 @@ credential_spec:
 When using `registry:`, the credential spec is read from the Windows registry on
 the daemon's host. A registry value with the given name must be located in:
 
-    HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs
+```bash
+HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs
+```
 
 The following example loads the credential spec from a value named `my-credential-spec`
 in the registry:
@@ -430,12 +433,12 @@ services:
   redis:
     image: redis
   db:
-    image: postgres
+    image: postgres:18
 ```
 
 Compose guarantees dependency services have been started before
 starting a dependent service.
-Compose waits for dependency services to be "ready" before
+With short syntax, Compose does not wait for dependency services to be "healthy" before
 starting a dependent service.
 
 #### Long syntax
@@ -445,7 +448,7 @@ expressed in the short form.
 
 - `restart`: When set to `true` Compose restarts this service after it updates the dependency service.
   This applies to an explicit restart controlled by a Compose operation, and excludes automated restart by the container runtime
-  after the container dies. Introduced in Docker Compose version [2.17.0](/manuals/compose/releases/release-notes.md#2170).
+  after the container dies. Introduced in Docker Compose version [2.17.0](https://github.com/docker/compose/releases/tag/v2.17.0).
 
 - `condition`: Sets the condition under which dependency is considered satisfied
   - `service_started`: An equivalent of the short syntax described previously
@@ -455,7 +458,7 @@ expressed in the short form.
   - `service_completed_successfully`: Specifies that a dependency is expected to run
     to successful completion before starting a dependent service.
 - `required`: When set to `false` Compose only warns you when the dependency service isn't started or available. If it's not defined
-    the default value of `required` is `true`. Introduced in Docker Compose version [2.20.0](/manuals/compose/releases/release-notes.md#2200).
+    the default value of `required` is `true`. Introduced in Docker Compose version [2.20.0](https://github.com/docker/compose/releases/tag/v2.20.0).
 
 Service dependencies cause the following behaviors:
 
@@ -482,7 +485,7 @@ services:
   redis:
     image: redis
   db:
-    image: postgres
+    image: postgres:18
 ```
 
 Compose guarantees dependency services are started before
@@ -668,7 +671,7 @@ env_file:
 
 The `format` attribute lets you use an alternative file format for the `env_file`. When not set, `env_file` is parsed according to the Compose rules outlined in [`Env_file` format](#env_file-format).
 
-`raw` format lets you use an `env_file` with key=value items, but without any attempt from Compose to parse the value for interpolation. 
+`raw` format lets you use an `env_file` with key=value items, but without any attempt from Compose to parse the value for interpolation.
 This let you pass values as-is, including quotes and `$` signs.
 
 ```yml
@@ -685,9 +688,13 @@ Each line in an `.env` file must be in `VAR[=[VAL]]` format. The following synta
 - Blank lines are ignored.
 - Unquoted and double-quoted (`"`) values have [Interpolation](interpolation.md) applied.
 - Each line represents a key-value pair. Values can optionally be quoted.
+- Delimiter separating key and value can be either `=` or `:`.
+- Spaces before and after value are ignored.
   - `VAR=VAL` -> `VAL`
   - `VAR="VAL"` -> `VAL`
   - `VAR='VAL'` -> `VAL`
+  - `VAR: VAL` -> `VAL`
+  - `VAR = VAL  ` -> `VAL` <!-- markdownlint-disable-line no-space-in-code -->
 - Inline comments for unquoted values must be preceded with a space.
   - `VAR=VAL # comment` -> `VAL`
   - `VAR=VAL# not a comment` -> `VAL# not a comment`
@@ -760,7 +767,7 @@ expose:
 
 > [!NOTE]
 >
-> If the Dockerfile for the image already exposes ports, it is visible to other containers on the network even if `expose` is not set in your Compose file. 
+> If the Dockerfile for the image already exposes ports, it is visible to other containers on the network even if `expose` is not set in your Compose file.
 
 ### `extends`
 
@@ -778,7 +785,9 @@ extends:
 - `service`: Defines the name of the service being referenced as a base, for example `web` or `database`.
 - `file`: The location of a Compose configuration file defining that service.
 
-#### Restrictions 
+`extends` is not supported when deploying with `docker stack deploy`.
+
+#### Restrictions
 
 When a service is referenced using `extends`, it can declare dependencies on other resources. These dependencies may be explicitly defined through attributes like `volumes`, `networks`, `configs`, `secrets`, `links`, `volumes_from`, or `depends_on`. Alternatively, dependencies can reference another service using the `service:{name}` syntax in namespace declarations such as `ipc`, `pid`, or `network_mode`.
 
@@ -984,7 +993,7 @@ extra_hosts:
   - "myhostv6=[::1]"
 ```
 
-The separator `=` is preferred, but `:` can also be used. Introduced in Docker Compose version [2.24.1](/manuals/compose/releases/release-notes.md#2241). For example:
+The separator `=` is preferred, but `:` can also be used. Introduced in Docker Compose version [2.24.1](https://github.com/docker/compose/releases/tag/v2.24.1). For example:
 
 ```yml
 extra_hosts:
@@ -1022,7 +1031,7 @@ an implicit `gpu` capability.
 ```yaml
 services:
   model:
-    gpus: 
+    gpus:
       - driver: 3dfx
         count: 2
 ```
@@ -1070,7 +1079,7 @@ healthcheck:
   start_interval: 5s
 ```
 
-`interval`, `timeout`, `start_period`, and `start_interval` are [specified as durations](extension.md#specifying-durations). Introduced in Docker Compose version [2.20.2](/manuals/compose/releases/release-notes.md#2202)
+`interval`, `timeout`, `start_period`, and `start_interval` are [specified as durations](extension.md#specifying-durations). Introduced in Docker Compose version [2.20.2](https://github.com/docker/compose/releases/tag/v2.20.2)
 
 `test` defines the command Compose runs to check container health. It can be
 either a string or a list. If it's a list, the first item must be either `NONE`, `CMD` or `CMD-SHELL`.
@@ -1285,21 +1294,60 @@ There is a performance penalty for applications that swap memory to disk often.
 - If `memswap_limit` is set to a positive integer, then both `memory` and `memswap_limit` must be set. `memswap_limit` represents the total amount of memory and swap that can be used, and `memory` controls the amount used by non-swap memory. So if `memory`="300m" and `memswap_limit`="1g", the container can use 300m of memory and 700m (1g - 300m) swap.
 - If `memswap_limit` is set to 0, the setting is ignored, and the value is treated as unset.
 - If `memswap_limit` is set to the same value as `memory`, and `memory` is set to a positive integer, the container does not have access to swap.
-- If `memswap_limit` is unset, and `memory` is set, the container can use as much swap as the `memory` setting, if the host container has swap memory configured. For instance, if `memory`="300m" and `memswap_limit` is not set, the container can use 600m in total of memory and swap.
+- If `memswap_limit` is unset, and `memory` is set, the container can use as much swap as the `memory` setting, if the host has swap memory configured. For instance, if `memory`="300m" and `memswap_limit` is not set, the container can use 600m in total of memory and swap.
 - If `memswap_limit` is explicitly set to -1, the container is allowed to use unlimited swap, up to the amount available on the host system.
 
+### `models`
+
+{{< summary-bar feature_name="Compose models" >}}
+
+`models` defines which AI models the service should use at runtime. Each referenced model must be defined under the [`models` top-level element](models.md).
+
+```yaml
+services:
+  short_syntax:
+    image: app
+    models:
+      - my_model
+  long_syntax:
+    image: app
+    models:
+      my_model:
+        endpoint_var: MODEL_URL
+        model_var: MODEL
+```
+
+When a service is linked to a model, Docker Compose injects environment variables to pass connection details and model identifiers to the container. This allows the application to locate and communicate with the model dynamically at runtime, without hard-coding values.
+
+#### Long syntax
+
+The long syntax gives you more control over the environment variable names.
+
+- `endpoint_var` sets the name of the environment variable that holds the model runner’s URL.
+- `model_var` sets the name of the environment variable that holds the model identifier.
+
+If either is omitted, Compose automatically generates the environment variable names based on the model key using the following rules:
+
+ - Convert the model key to uppercase
+ - Replace any '-' characters with '_'
+ - Append `_URL` for the endpoint variable
+
 ### `network_mode`
 
-`network_mode` sets a service container's network mode. 
+`network_mode` sets a service container's network mode.
 
+- `bridge`: Connects the container to Docker's default bridge network instead of
+  a project-specific network. Containers on the default bridge network cannot
+  resolve each other by service name . Instead, use a user-defined network for DNS resolution.
 - `none`: Turns off all container networking.
 - `host`: Gives the container raw access to the host's network interface.
-- `service:{name}`: Gives the container access to the specified container by referring to its service name. 
-- `container:{name}`: Gives the container access to the specified container by referring to its container ID. 
+- `service:{name}`: Gives the container access to the specified container by referring to its service name.
+- `container:{name}`: Gives the container access to the specified container by referring to its container ID.
 
 For more information container networks, see the [Docker Engine documentation](/manuals/engine/network/_index.md#container-networks).
 
 ```yml
+    network_mode: "bridge"
     network_mode: "host"
     network_mode: "none"
     network_mode: "service:[service name]"
@@ -1321,10 +1369,10 @@ services:
 ```
 For more information about the `networks` top-level element, see [Networks](networks.md).
 
-### Implicit default network
+#### Implicit default network
 
 If `networks` is empty or absent from the Compose file, Compose considers an implicit definition for the service to be
-connected to the `default` network: 
+connected to the `default` network:
 
 ```yml
 services:
@@ -1336,9 +1384,9 @@ This example is actually equivalent to:
 ```yml
 services:
   some-service:
-    image: foo  
+    image: foo
     networks:
-      default: {}  
+      default: {}
 ```
 
 If you want the service to not be connected a network, you must set [`network_mode: none`](#network_mode).
@@ -1395,9 +1443,31 @@ services:
           - mysql
 
 networks:
-  front-tier:
-  back-tier:
-  admin:
+  front-tier: {}
+  back-tier: {}
+  admin: {}
+```
+
+#### `interface_name`
+
+{{< summary-bar feature_name="Compose interface-name" >}}
+
+`interface_name` lets you specify the name of the network interface used to connect a service to a given network. This ensures consistent and predictable interface naming across services and networks.
+
+```yaml
+services:
+  backend:
+    image: alpine
+    command: ip link show
+    networks:
+      back-tier:
+        interface_name: eth0
+```
+
+Running the example Compose application shows:
+
+```console
+backend-1  | 11: eth0@if64: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
 ```
 
 #### `ipv4_address`, `ipv6_address`
@@ -1454,6 +1524,21 @@ networks:
 
 `mac_address` sets the Mac address used by the service container when connecting to this particular network.
 
+#### `driver_opts`
+
+`driver_opts` specifies a list of options as key-value pairs to pass to the driver. These options are
+driver-dependent. Consult the driver's documentation for more information.
+
+```yml
+services:
+  app:
+    networks:
+      app_net:
+        driver_opts:
+          foo: "bar"
+          baz: 1
+```
+
 #### `gw_priority`
 
 {{< summary-bar feature_name="Compose gw priority" >}}
@@ -1568,11 +1653,15 @@ in the form:
 
 `[HOST:]CONTAINER[/PROTOCOL]` where:
 
-- `HOST` is `[IP:](port | range)` (optional). If it is not set, it binds to all network interfaces (`0.0.0.0`). 
+- `HOST` is `[IP:](port | range)` (optional). If it is not set, it binds to all network interfaces (`0.0.0.0`).
 - `CONTAINER` is `port | range`.
 - `PROTOCOL` restricts ports to a specified protocol either `tcp` or `udp`(optional). Default is `tcp`.
 
-Ports can be either a single value or a range. `HOST` and `CONTAINER` must use equivalent ranges. 
+> [!WARNING]
+>
+> If you do not specify a host IP (such as `127.0.0.1`), Docker binds to all interfaces (`0.0.0.0`), bypassing host firewall rules. This can expose the container directly to the internet if the host has a public IP address. For more information, see [Port publishing and mapping](/manuals/engine/network/port-publishing.md).
+
+Ports can be either a single value or a range. `HOST` and `CONTAINER` must use equivalent ranges.
 
 You can either specify both ports (`HOST:CONTAINER`), or just the container port. In the latter case,
 the container runtime automatically allocates any unassigned port of the host.
@@ -1580,6 +1669,8 @@ the container runtime automatically allocates any unassigned port of the host.
 `HOST:CONTAINER` should always be specified as a (quoted) string, to avoid conflicts
 with [YAML base-60 float](https://yaml.org/type/float.html).
 
+
+
 IPv6 addresses can be enclosed in square brackets.
 
 Examples:
@@ -1593,10 +1684,10 @@ ports:
   - "49100:22"
   - "8000-9000:80"
   - "127.0.0.1:8001:8001"
-  - "127.0.0.1:5000-5010:5000-5010"  
-  - "::1:6000:6000"   
-  - "[::1]:6001:6001" 
-  - "6060:6060/udp"    
+  - "127.0.0.1:5000-5010:5000-5010"
+  - "::1:6000:6000"
+  - "[::1]:6001:6001"
+  - "6060:6060/udp"
 ```
 
 > [!NOTE]
@@ -1613,9 +1704,9 @@ expressed in the short form.
 - `published`: The publicly exposed port. It is defined as a string and can be set as a range using syntax `start-end`. It means the actual port is assigned a remaining available port, within the set range.
 - `host_ip`: The host IP mapping. If it is not set, it binds to all network interfaces (`0.0.0.0`).
 - `protocol`: The port protocol (`tcp` or `udp`). Defaults to `tcp`.
-- `app_protocol`: The application protocol (TCP/IP level 4 / OSI level 7) this port is used for. This is optional and can be used as a hint for Compose to offer richer behavior for protocols that it understands. Introduced in Docker Compose version [2.26.0](/manuals/compose/releases/release-notes.md#2260).
+- `app_protocol`: The application protocol (TCP/IP level 4 / OSI level 7) this port is used for. This is optional and can be used as a hint for Compose to offer richer behavior for protocols that it understands. Introduced in Docker Compose version [2.26.0](https://github.com/docker/compose/releases/tag/v2.26.0).
 - `mode`: Specifies how the port is published in a Swarm setup. If set to `host`, it publishes the port on every node in Swarm. If set to `ingress`, it allows load balancing across the nodes in Swarm. Defaults to `ingress`.
-- `name`: A human-readable name for the port, used to document it's usage within the service.
+- `name`: A human-readable name for the port, used to document its usage within the service.
 
 ```yml
 ports:
@@ -1661,13 +1752,56 @@ services:
 
 For more information, see [Use lifecycle hooks](/manuals/compose/how-tos/lifecycle.md).
 
+### pre_start
+
+{{< summary-bar feature_name="Compose pre_start" >}}
+
+`pre_start` defines a sequence of init containers to run before the service container is started. Each step runs to completion, in declared order, and the service container only starts once every step has exited `0`. A non-zero exit fails the bring-up of the service and its dependents.
+
+Unlike `post_start` and `pre_stop`, which run a command inside the running service container, each `pre_start` step runs in its own ephemeral container, created after the service container is created but before it is started. Possible values are:
+
+- `command`: The command to run. Optional when the chosen image's entrypoint already runs the intended command.
+- `image`: The image used for the ephemeral container. If omitted, the parent service's image is used.
+- `user`: The user to run the command. If not set, defaults to the user declared in `image` (or to the main service command's user when `image` is omitted).
+- `privileged`: Lets the `pre_start` command run with privileged access.
+- `working_dir`: The working directory in which to run the command. If not set, it is run in the same working directory as the main service command.
+- `environment`: Sets the environment variables to run the `pre_start` command. The command inherits the `environment` set for the service's main command, and this section lets you append or override values.
+- `per_replica: false`: Whether the step runs once for the service as a whole before any replica starts.
+
+`pre_start` steps only run once the service's `depends_on` conditions have been satisfied, so a step can rely on those dependencies the same way the main service command does. A`pre_start` container joins the same networks as the service, so it can reach services declared in `depends_on`, and shares the service's declared volume mounts so files it produces in a shared volume are visible to the service. 
+
+With `per_replica: false` and a scaled service, only mounts that are shared across replicas (named volumes, bind mounts) are usable. Per-instance mounts (`tmpfs`, anonymous volumes) cannot be addressed by a single run. This is not an error. The steps run without access to per-instance mounts. Data a `per_replica: false` step must share with the service belongs in a named volume or bind mount.
+
+A `pre_start` step that has already succeeded for its current definition is not re-run on a subsequent `up`, nor when the service container restarts under its `restart` policy. A step runs again when its definition changes, when the previous run did not succeed, or when the service is recreated. For example, after a change to the service configuration or an explicit forced recreation.
+
+```yaml
+services:
+  app:
+    image: myapp:latest
+    depends_on:
+      db:
+        condition: service_healthy
+    pre_start:
+      - command: ["./manage.py", "migrate"]
+      - image: busybox
+        command: sh -c 'chown -R 1000:1000 /data'
+    volumes:
+      - data:/data
+
+  db:
+    image: postgres:16
+
+volumes:
+  data:
+```
+
 ### `pre_stop`
 
 {{< summary-bar feature_name="Compose pre stop" >}}
 
 `pre_stop` defines a sequence of lifecycle hooks to run before the container is stopped. These hooks won't run if the container stops by itself or is terminated suddenly.
 
-Configuration is equivalent to [post_start](#post_start).
+Configuration is equivalent to [`post_start`](#post_start).
 
 ### `privileged`
 
@@ -1693,6 +1827,46 @@ services:
       - debug
 ```
 
+### `provider`
+
+{{< summary-bar feature_name="Compose provider services" >}}
+
+`provider` can be used to define a service that Compose won't manage directly. Compose delegated the service lifecycle to a dedicated or third-party component.
+
+```yaml
+  database:
+    provider:
+      type: awesomecloud
+      options:
+        type: mysql
+        foo: bar
+  app:
+    image: myapp
+    depends_on:
+       - database
+```
+
+As Compose runs the application, the `awesomecloud` binary is used to manage the `database` service setup.
+Dependent service `app` receives additional environment variables prefixed by the service name so it can access the resource.
+
+For illustration, assuming `awesomecloud` execution produced variables `URL` and `API_KEY`, the `app` service
+runs with environment variables `DATABASE_URL` and `DATABASE_API_KEY`.
+
+As Compose stops the application, the `awesomecloud` binary is used to manage the `database` service tear down.
+
+The mechanism used by Compose to delegate the service lifecycle to an external binary is described in the [Compose extensibility documentation](https://github.com/docker/compose/tree/main/docs/extension.md).
+
+For more information on using the `provider` attribute, see [Use provider services](/manuals/compose/how-tos/provider-services.md).
+
+#### `type`
+
+`type` attribute is required. It defines the external component used by Compose to manage setup and tear down lifecycle
+events.
+
+#### `options`
+
+`options` are specific to the selected provider and not validated by the compose specification
+
 ### `pull_policy`
 
 `pull_policy` defines the decisions Compose makes when it starts to pull images. Possible values are:
@@ -1702,7 +1876,7 @@ services:
    If there is no cached image, a failure is reported.
 - `missing`: Compose pulls the image only if it's not available in the platform cache.
    This is the default option if you are not also using the [Compose Build Specification](build.md).
-  `if_not_present` is considered an alias for this value for backward compatibility.
+  `if_not_present` is considered an alias for this value for backward compatibility. The `latest` tag is always pulled even when the `missing` pull policy is used.
 - `build`: Compose builds the image. Compose rebuilds the image if it's already present.
 - `daily`: Compose checks the registry for image updates if the last pull took place more than 24 hours ago.
 - `weekly`: Compose checks the registry for image updates if the last pull took place more than 7 days ago.
@@ -1739,7 +1913,7 @@ Optionally, limit the number of restart retries the Docker daemon attempts.
 ```
 
 You can find more detailed information on restart policies in the
-[Restart Policies (--restart)](/reference/cli/docker/container/run.md#restart)
+[Restart Policies (--restart)](/reference/cli/docker/container/run/#restart)
 section of the Docker run reference page.
 
 ### `runtime`
@@ -1805,45 +1979,54 @@ the service's containers.
 - `target`: The name of the file to be mounted in `/run/secrets/` in the
   service's task container, or absolute path of the file if an alternate location is required. Defaults to `source` if not specified.
 - `uid` and `gid`: The numeric uid or gid that owns the file within
-  `/run/secrets/` in the service's task containers. Default value is `USER`.
+  `/run/secrets/` in the service's task containers.
 - `mode`: The [permissions](https://wintelguy.com/permissions-calc.pl) for the file to be mounted in `/run/secrets/`
   in the service's task containers, in octal notation.
   The default value is world-readable permissions (mode `0444`).
-  The writable bit must be ignored if set. The executable bit may be set. 
+  The writable bit must be ignored if set. The executable bit may be set.
 
-Note that support for `uid`, `gid`, and `mode` attributes are not implemented in Docker Compose when the source of the secret is a [`file`](secrets.md). This is because bind-mounts used under the hood don't allow uid remapping.
+Note that support for `uid`, `gid`, and `mode` attributes are only implemented in Docker Compose when the source of the secret is [`environment`](secrets.md). When the source is a [`file`](secrets.md), Compose uses a bind-mount under the hood which doesn't allow `uid` remapping, and these attributes are silently ignored.
 
-The following example sets the name of the `server-certificate` secret file to `server.cert`
-within the container, sets the mode to `0440` (group-readable), and sets the user and group
-to `103`. The value of `server-certificate` is set
-to the contents of the file `./server.cert`.
+The following example sets the name of the `my-token` secret file within the container,
+sets the mode to `0440` (group-readable), and sets the user and group to `103`.
+The value of `my-token` is read from the `MY_TOKEN` environment variable.
 
 ```yml
 services:
   frontend:
     image: example/webapp
     secrets:
-      - source: server-certificate
-        target: server.cert
+      - source: my-token
         uid: "103"
         gid: "103"
-        mode: "0o440"
+        mode: 0o440
 secrets:
-  server-certificate:
-    file: ./server.cert
+  my-token:
+    environment: "MY_TOKEN"
 ```
 
 ### `security_opt`
 
 `security_opt` overrides the default labeling scheme for each container.
 
+Options accept either `option=value` or `option:value` syntax. For boolean options
+such as `no-new-privileges`, the value may be omitted entirely, in which case the
+option is treated as enabled. The following syntaxes are all equivalent:
+
+```yml
+security_opt:
+  - no-new-privileges
+  - no-new-privileges=true
+  - no-new-privileges:true
+```
+
 ```yml
 security_opt:
   - label=user:USER
   - label=role:ROLE
 ```
 
-For further default labeling schemes you can override, see [Security configuration](/reference/cli/docker/container/run.md#security-opt).
+For further default labeling schemes you can override, see [Security configuration](/reference/cli/docker/container/run/#security-opt).
 
 ### `shm_size`
 
@@ -1852,8 +2035,8 @@ It's specified as a [byte value](extension.md#specifying-byte-values).
 
 ### `stdin_open`
 
-`stdin_open` configures a service's container to run with an allocated stdin. This is the same as running a container with the 
-`-i` flag. For more information, see [Keep stdin open](/reference/cli/docker/container/run.md#interactive).
+`stdin_open` configures a service's container to run with an allocated stdin. This is the same as running a container with the
+`-i` flag. For more information, see [Keep stdin open](/reference/cli/docker/container/run/#interactive).
 
 Supported values are `true` or `false`.
 
@@ -1908,7 +2091,7 @@ sysctls:
 You can only use sysctls that are namespaced in the kernel. Docker does not
 support changing sysctls inside a container that also modify the host system.
 For an overview of supported sysctls, refer to [configure namespaced kernel
-parameters (sysctls) at runtime](/reference/cli/docker/container/run.md#sysctl).
+parameters (sysctls) at runtime](/reference/cli/docker/container/run/#sysctl).
 
 ### `tmpfs`
 
@@ -1939,8 +2122,8 @@ services:
 
 ### `tty`
 
-`tty` configures a service's container to run with a TTY. This is the same as running a container with the 
-`-t` or `--tty` flag. For more information, see [Allocate a pseudo-TTY](/reference/cli/docker/container/run.md#tty).
+`tty` configures a service's container to run with a TTY. This is the same as running a container with the
+`-t` or `--tty` flag. For more information, see [Allocate a pseudo-TTY](/reference/cli/docker/container/run/#tty).
 
 Supported values are `true` or `false`.
 
@@ -1957,6 +2140,12 @@ ulimits:
     hard: 40000
 ```
 
+### `use_api_socket`
+
+When `use_api_socket` is set, the container is able to interact with the underlying container engine through the API socket.
+Your credentials are mounted inside the container so the container acts as a pure delegate for your commands relating to the container engine.
+Typically, commands ran by container can `pull` and `push` to your registry.
+
 ### `user`
 
 `user` overrides the user used to run the container process. The default is set by the image, for example Dockerfile `USER`. If it's not set, then `root`.
@@ -2035,6 +2224,11 @@ The short syntax uses a single string with colon-separated values to specify a v
 > platform it rejects Compose files which use relative host paths with an error. To avoid ambiguities
 > with named volumes, relative paths should always begin with `.` or `..`.
 
+> [!NOTE]
+>
+> For bind mounts, the short syntax creates a directory at the source path on the host if it doesn't exist. This is for backward compatibility with `docker-compose` legacy.
+> It can be prevented by using long syntax and setting `create_host_path` to `false`.
+
 #### Long syntax
 
 The long form syntax lets you configure additional fields that can't be
@@ -2048,24 +2242,22 @@ expressed in the short form.
 - `read_only`: Flag to set the volume as read-only.
 - `bind`: Used to configure additional bind options:
   - `propagation`: The propagation mode used for the bind.
-  - `create_host_path`: Creates a directory at the source path on host if there is nothing present.
-    Compose does nothing if there is something present at the path. This is automatically implied by short syntax
-    for backward compatibility with `docker-compose` legacy.
+  - `create_host_path`: Creates a directory at the source path on host if there is nothing present. Defaults to `true`.
   - `selinux`: The SELinux re-labeling option `z` (shared) or `Z` (private)
 - `volume`: Configures additional volume options:
   - `nocopy`: Flag to disable copying of data from a container when a volume is created.
   - `subpath`: Path inside a volume to mount instead of the volume root.
 - `tmpfs`: Configures additional tmpfs options:
   - `size`: The size for the tmpfs mount in bytes (either numeric or as bytes unit).
-  - `mode`: The file mode for the tmpfs mount as Unix permission bits as an octal number. Introduced in Docker Compose version [2.14.0](/manuals/compose/releases/release-notes.md#2260).
+  - `mode`: The file mode for the tmpfs mount as Unix permission bits as an octal number. Introduced in Docker Compose version [2.14.0](https://github.com/docker/compose/releases/tag/v2.14.0).
 - `image`: Configures additional image options:
-  - `subpath`: Path inside the source image to mount instead of the image root. Available in [Docker Compose version 2.35.0](/manuals/compose/releases/release-notes.md#2350)
+  - `subpath`: Path inside the source image to mount instead of the image root. Available in [Docker Compose version 2.35.0](https://github.com/docker/compose/releases/tag/v2.35.0)
 - `consistency`: The consistency requirements of the mount. Available values are platform specific.
 
 > [!TIP]
 >
-> Working with large repositories or monorepos, or with virtual file systems that are no longer scaling with your codebase? 
-> Compose now takes advantage of [Synchronized file shares](/manuals/desktop/features/synchronized-file-sharing.md) and automatically creates file shares for bind mounts. 
+> Working with large repositories or monorepos, or with virtual file systems that are no longer scaling with your codebase?
+> Compose now takes advantage of [Synchronized file shares](/manuals/desktop/features/synchronized-file-sharing.md) and automatically creates file shares for bind mounts.
 > Ensure you're signed in to Docker with a paid subscription and have enabled both **Access experimental features** and **Manage Synchronized file shares with Compose** in Docker Desktop's settings.
 
 ### `volumes_from`
diff --git a/content/reference/compose-file/version-and-name.md b/content/reference/compose-file/version-and-name.md
index cb5bd689ab3d..aaf992c56b65 100644
--- a/content/reference/compose-file/version-and-name.md
+++ b/content/reference/compose-file/version-and-name.md
@@ -9,10 +9,11 @@ weight: 10
 
 ## Version top-level element (obsolete)
 
-The top-level `version` property is defined by the Compose Specification for backward compatibility. It is only informative and you'll receive a warning message that it is obsolete if used. 
+> [!IMPORTANT]
+>
+> The top-level `version` property is defined by the Compose Specification for backward compatibility. It is only informative and you'll receive a warning message that it is obsolete if used. 
 
-Compose doesn't use `version` to select an exact schema to validate the Compose file, but
-prefers the most recent schema when it's implemented.
+Compose always uses the most recent schema to validate the Compose file, regardless of the `version` field.
 
 Compose validates whether it can fully parse the Compose file. If some fields are unknown, typically
 because the Compose file was written with fields defined by a newer version of the Specification, you'll receive a warning message. 
@@ -20,6 +21,7 @@ because the Compose file was written with fields defined by a newer version of t
 ## Name top-level element
 
 The top-level `name` property is defined by the Compose Specification as the project name to be used if you don't set one explicitly.
+
 Compose offers a way for you to override this name, and sets a
 default project name to be used if the top-level `name` element is not set.
 
diff --git a/content/reference/compose-file/volumes.md b/content/reference/compose-file/volumes.md
index 2003f488761a..dbe67321b723 100644
--- a/content/reference/compose-file/volumes.md
+++ b/content/reference/compose-file/volumes.md
@@ -1,6 +1,7 @@
 ---
-title: Volumes top-level element
-description: Explore all the attributes the volumes top-level element can have.
+linkTitle: Volumes 
+title: Define and manage volumes in Docker Compose
+description: Control how volumes are declared and shared between services using the top-level volumes element.
 keywords: compose, compose specification, volumes, compose file reference
 aliases: 
  - /compose/compose-file/07-volumes/
@@ -70,6 +71,20 @@ volumes:
       device: ":/docker/example"
 ```
 
+If you want a named bind mount, use the `local` driver with `driver_opts`. This pattern gives a Compose volume a stable name while mapping it to a specific host path:
+
+```yaml
+volumes:
+  app-data:
+    driver: local
+    driver_opts:
+      type: none
+      o: bind
+      device: /srv/app-data # must be the absolute host path and already exist
+```
+
+The `type`, `o`, and `device` keys are passed through to the local driver. For a one-off host-path mount on a single service, see [bind mounts](/manuals/engine/storage/bind-mounts.md).
+
 ### `external`
 
 If set to `true`:
@@ -119,6 +134,10 @@ volumes:
 
 Compose sets `com.docker.compose.project` and `com.docker.compose.volume` labels.
 
+> [!NOTE]
+>
+> Labels defined here apply to named volumes only. They’re stored on the volume resource and visible via `docker volume inspect`. They do not apply to bind mounts and do not change mount semantics.
+
 ### `name`
 
 `name` sets a custom name for a volume. The name field can be used to reference volumes that contain special
diff --git a/content/reference/glossary.md b/content/reference/glossary.md
index 333da26ad87e..a720dc28610a 100644
--- a/content/reference/glossary.md
+++ b/content/reference/glossary.md
@@ -5,19 +5,11 @@ keywords: glossary, docker, terms, definitions
 notoc: true
 layout: glossary
 aliases:
-- /engine/reference/glossary/
-- /glossary/
+  - /engine/reference/glossary/
+  - /glossary/
 ---
 
-> [!TIP]
->
-> Looking for a definition that's not listed or need a more context-aware
-> explanation?
->
-> Try <a role="button" tabindex="0" class="open-kapa-widget">Ask AI</a>.
-
-
 <!--
 To edit/add/remove glossary entries, visit the YAML file at:
 https://github.com/docker/docs/blob/main/data/glossary.yaml
--->
\ No newline at end of file
+-->
diff --git a/content/reference/samples/_index.md b/content/reference/samples/_index.md
index 49c769ba4bce..883c464c2830 100644
--- a/content/reference/samples/_index.md
+++ b/content/reference/samples/_index.md
@@ -3,9 +3,6 @@ linkTitle: Samples
 title: Samples overview
 description: Learn how to containerize different types of services by walking through
   Official Docker samples.
-cascade:
-  layout: samples
-  type: samples
 aliases:
 - /en/latest/examples/
 - /engine/examples/
@@ -35,4 +32,4 @@ Learn how to containerize different types of services by walking through Officia
 
 ## Other samples
 
-[AI/ML](../samples/ai-ml.md) \| [Cloudflared](../samples/cloudflared.md) \| [Elasticsearch / Logstash / Kibana](../samples/elasticsearch.md) \| [Minecraft](../samples/minecraft.md) \| [NGINX](../samples/nginx.md) \| [Pi-hole](../samples/pi-hole.md) \| [Plex](../samples/plex.md) \| [Traefik](../samples/traefik.md) \| [WireGuard](../samples/wireguard.md)
+[Agentic AI](../samples/agentic-ai.md) \| [AI/ML](../samples/ai-ml.md) \| [Cloudflared](../samples/cloudflared.md) \| [Elasticsearch / Logstash / Kibana](../samples/elasticsearch.md) \| [Minecraft](../samples/minecraft.md) \| [NGINX](../samples/nginx.md) \| [Pi-hole](../samples/pi-hole.md) \| [Plex](../samples/plex.md) \| [Traefik](../samples/traefik.md) \| [WireGuard](../samples/wireguard.md)
diff --git a/content/reference/samples/agentic-ai.md b/content/reference/samples/agentic-ai.md
new file mode 100644
index 000000000000..58421ca486f8
--- /dev/null
+++ b/content/reference/samples/agentic-ai.md
@@ -0,0 +1,5 @@
+---
+title: Agentic AI samples
+description: Docker samples for agentic AI.
+service: agentic-ai
+---
diff --git a/content/search.md b/content/search.md
deleted file mode 100644
index 59f5903bbb33..000000000000
--- a/content/search.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Search
-layout: search
-params:
-  sitemap: false
-  icon: search
----
diff --git a/content/tags/_index.md b/content/tags/_index.md
deleted file mode 100644
index 1568ead9fe61..000000000000
--- a/content/tags/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Tags
-params:
-  icon: tag
----
-
-Here you can browse Docker docs by tag.
diff --git a/content/tags/admin/_index.md b/content/tags/admin/_index.md
deleted file mode 100644
index 9f7ab9b1a95d..000000000000
--- a/content/tags/admin/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: Administration
----
diff --git a/content/tags/ai/_index.md b/content/tags/ai/_index.md
deleted file mode 100644
index d16578aa0f98..000000000000
--- a/content/tags/ai/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: AI
----
diff --git a/content/tags/app-dev/_index.md b/content/tags/app-dev/_index.md
deleted file mode 100644
index 2bea4fc70cbf..000000000000
--- a/content/tags/app-dev/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: App development
----
diff --git a/content/tags/best-practices/_index.md b/content/tags/best-practices/_index.md
deleted file mode 100644
index ada8e2b9f66c..000000000000
--- a/content/tags/best-practices/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Best practices
-description: Optimal patterns for Docker
----
-
-Best practices articles describe methods and techniques that are generally
-the most idiomatic and optimized way to do something.
diff --git a/content/tags/cloud-services/_index.md b/content/tags/cloud-services/_index.md
deleted file mode 100644
index 2f57b23d5ac1..000000000000
--- a/content/tags/cloud-services/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: Cloud services
----
diff --git a/content/tags/data-science/_index.md b/content/tags/data-science/_index.md
deleted file mode 100644
index 7926e09730b4..000000000000
--- a/content/tags/data-science/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: Data science
----
diff --git a/content/tags/databases/_index.md b/content/tags/databases/_index.md
deleted file mode 100644
index 51607bd69168..000000000000
--- a/content/tags/databases/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: Databases
----
diff --git a/content/tags/deploy/_index.md b/content/tags/deploy/_index.md
deleted file mode 100644
index d93db5d49147..000000000000
--- a/content/tags/deploy/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: Deployment
----
diff --git a/content/tags/devops/_index.md b/content/tags/devops/_index.md
deleted file mode 100644
index 2d9ad1867487..000000000000
--- a/content/tags/devops/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: DevOps
----
diff --git a/content/tags/distributed-systems/_index.md b/content/tags/distributed-systems/_index.md
deleted file mode 100644
index ce0470da6d53..000000000000
--- a/content/tags/distributed-systems/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: Distributed systems
----
diff --git a/content/tags/faq/_index.md b/content/tags/faq/_index.md
deleted file mode 100644
index 861ac6583043..000000000000
--- a/content/tags/faq/_index.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: FAQ
-description: Frequently asked questions
----
-
-FAQs contain frequently asked questions about all things Docker, from accounts
-and administration to organization management, Docker Desktop, Docker Compose,
-and more.
diff --git a/content/tags/frameworks/_index.md b/content/tags/frameworks/_index.md
deleted file mode 100644
index e8bd2590f9d9..000000000000
--- a/content/tags/frameworks/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: Frameworks
----
diff --git a/content/tags/networking/_index.md b/content/tags/networking/_index.md
deleted file mode 100644
index e5573002b601..000000000000
--- a/content/tags/networking/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: Networking
----
diff --git a/content/tags/product-demo/_index.md b/content/tags/product-demo/_index.md
deleted file mode 100644
index de46c1a3776e..000000000000
--- a/content/tags/product-demo/_index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-title: Product demo
----
diff --git a/content/tags/release-notes/_index.md b/content/tags/release-notes/_index.md
deleted file mode 100644
index 3cafaa0a4f84..000000000000
--- a/content/tags/release-notes/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Release notes
-icon: note_stack_add
-description: Find out about the latest features
-aliases:
-- /release-notes/
----
-
-Release notes describe corrections, changes or enhancements made to a product
-product in a given release.
diff --git a/content/tags/secrets/_index.md b/content/tags/secrets/_index.md
deleted file mode 100644
index f1e037529031..000000000000
--- a/content/tags/secrets/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Secrets
-description: Use sensitive information in containers securely
----
-
-A secret is a piece of data, such as a password, SSH private key, SSL
-certificate, or anything that should not be transmitted over a network or
-stored unencrypted in a Dockerfile or in your application's source code.
-
-Docker provides specially designated features for managing secrets.
diff --git a/content/tags/troubleshooting/_index.md b/content/tags/troubleshooting/_index.md
deleted file mode 100644
index 47f17d79c31a..000000000000
--- a/content/tags/troubleshooting/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Troubleshooting
-description: Fix common issues
----
-
-Troubleshooting articles contain guidelines for solving common problems and
-pitfalls that you might encounter with Docker products.
diff --git a/data/buildx/docker_buildx_bake.yaml b/data/buildx/docker_buildx_bake.yaml
deleted file mode 100644
index 066d67119da0..000000000000
--- a/data/buildx/docker_buildx_bake.yaml
+++ /dev/null
@@ -1,569 +0,0 @@
-command: docker buildx bake
-aliases: docker buildx bake, docker buildx f
-short: Build from a file
-long: |-
-    Bake is a high-level build command. Each specified target runs in parallel
-    as part of the build.
-
-    Read [High-level build options with Bake](/build/bake/)
-    guide for introduction to writing bake files.
-
-    > [!NOTE]
-    > `buildx bake` command may receive backwards incompatible features in the future
-    > if needed. We are looking for feedback on improving the command and extending
-    > the functionality further.
-usage: docker buildx bake [OPTIONS] [TARGET...]
-pname: docker buildx
-plink: docker_buildx.yaml
-options:
-    - option: allow
-      value_type: stringArray
-      default_value: '[]'
-      description: Allow build to access specified resources
-      details_url: '#allow'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: call
-      value_type: string
-      default_value: build
-      description: Set method for evaluating build (`check`, `outline`, `targets`)
-      details_url: '#call'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: check
-      value_type: bool
-      description: Shorthand for `--call=check`
-      details_url: '#check'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: file
-      shorthand: f
-      value_type: stringArray
-      default_value: '[]'
-      description: Build definition file
-      details_url: '#file'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: list
-      value_type: string
-      description: List targets or variables
-      details_url: '#list'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: list-targets
-      value_type: bool
-      default_value: "false"
-      description: List available targets
-      deprecated: true
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: list-variables
-      value_type: bool
-      default_value: "false"
-      description: List defined variables
-      deprecated: true
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: load
-      value_type: bool
-      default_value: "false"
-      description: Shorthand for `--set=*.output=type=docker`
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: metadata-file
-      value_type: string
-      description: Write build result metadata to a file
-      details_url: '#metadata-file'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: no-cache
-      value_type: bool
-      default_value: "false"
-      description: Do not use cache when building the image
-      details_url: '#no-cache'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: print
-      value_type: bool
-      default_value: "false"
-      description: Print the options without building
-      details_url: '#print'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: progress
-      value_type: string
-      default_value: auto
-      description: |
-        Set type of progress output (`auto`, `quiet`, `plain`, `tty`, `rawjson`). Use plain to show container output
-      details_url: '#progress'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: provenance
-      value_type: string
-      description: Shorthand for `--set=*.attest=type=provenance`
-      details_url: '#provenance'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: pull
-      value_type: bool
-      default_value: "false"
-      description: Always attempt to pull all referenced images
-      details_url: '#pull'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: push
-      value_type: bool
-      default_value: "false"
-      description: Shorthand for `--set=*.output=type=registry`
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: sbom
-      value_type: string
-      description: Shorthand for `--set=*.attest=type=sbom`
-      details_url: '#sbom'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: set
-      value_type: stringArray
-      default_value: '[]'
-      description: Override target value (e.g., `targetpattern.key=value`)
-      details_url: '#set'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      details_url: '#builder'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-examples: |-
-    ### Allow extra privileged entitlement (--allow) {#allow}
-
-    ```text
-    --allow=ENTITLEMENT[=VALUE]
-    ```
-
-    Entitlements are designed to provide controlled access to privileged
-    operations. By default, Buildx and BuildKit operates with restricted
-    permissions to protect users and their systems from unintended side effects or
-    security risks. The `--allow` flag explicitly grants access to additional
-    entitlements, making it clear when a build or bake operation requires elevated
-    privileges.
-
-    In addition to BuildKit's `network.host` and `security.insecure` entitlements
-    (see [`docker buildx build --allow`](/reference/cli/docker/buildx/build/#allow),
-    Bake supports file system entitlements that grant granular control over file
-    system access. These are particularly useful when working with builds that need
-    access to files outside the default working directory.
-
-    Bake supports the following filesystem entitlements:
-
-    - `--allow fs=<path|*>` - Grant read and write access to files outside of the
-      working directory.
-    - `--allow fs.read=<path|*>` - Grant read access to files outside of the
-      working directory.
-    - `--allow fs.write=<path|*>` - Grant write access to files outside of the
-      working directory.
-
-    The `fs` entitlements take a path value (relative or absolute) to a directory
-    on the filesystem. Alternatively, you can pass a wildcard (`*`) to allow Bake
-    to access the entire filesystem.
-
-    ### Example: fs.read
-
-    Given the following Bake configuration, Bake would need to access the parent
-    directory, relative to the Bake file.
-
-    ```hcl
-    target "app" {
-      context = "../src"
-    }
-    ```
-
-    Assuming `docker buildx bake app` is executed in the same directory as the
-    `docker-bake.hcl` file, you would need to explicitly allow Bake to read from
-    the `../src` directory. In this case, the following invocations all work:
-
-    ```console
-    $ docker buildx bake --allow fs.read=* app
-    $ docker buildx bake --allow fs.read=../src app
-    $ docker buildx bake --allow fs=* app
-    ```
-
-    ### Example: fs.write
-
-    The following `docker-bake.hcl` file requires write access to the `/tmp`
-    directory.
-
-    ```hcl
-    target "app" {
-      output = "/tmp"
-    }
-    ```
-
-    Assuming `docker buildx bake app` is executed outside of the `/tmp` directory,
-    you would need to allow the `fs.write` entitlement, either by specifying the
-    path or using a wildcard:
-
-    ```console
-    $ docker buildx bake --allow fs=/tmp app
-    $ docker buildx bake --allow fs.write=/tmp app
-    $ docker buildx bake --allow fs.write=* app
-    ```
-
-    ### Override the configured builder instance (--builder) {#builder}
-
-    Same as [`buildx --builder`](/reference/cli/docker/buildx/#builder).
-
-    ### Invoke a frontend method (--call) {#call}
-
-    Same as [`build --call`](/reference/cli/docker/buildx/build/#call).
-
-    #### Call: check (--check) {#check}
-
-    Same as [`build --check`](/reference/cli/docker/buildx/build/#check).
-
-    ### Specify a build definition file (-f, --file) {#file}
-
-    Use the `-f` / `--file` option to specify the build definition file to use.
-    The file can be an HCL, JSON or Compose file. If multiple files are specified,
-    all are read and the build configurations are combined.
-
-    You can pass the names of the targets to build, to build only specific target(s).
-    The following example builds the `db` and `webapp-release` targets that are
-    defined in the `docker-bake.dev.hcl` file:
-
-    ```hcl
-    # docker-bake.dev.hcl
-    group "default" {
-      targets = ["db", "webapp-dev"]
-    }
-
-    target "webapp-dev" {
-      dockerfile = "Dockerfile.webapp"
-      tags = ["docker.io/username/webapp"]
-    }
-
-    target "webapp-release" {
-      inherits = ["webapp-dev"]
-      platforms = ["linux/amd64", "linux/arm64"]
-    }
-
-    target "db" {
-      dockerfile = "Dockerfile.db"
-      tags = ["docker.io/username/db"]
-    }
-    ```
-
-    ```console
-    $ docker buildx bake -f docker-bake.dev.hcl db webapp-release
-    ```
-
-    See the [Bake file reference](/build/bake/reference/)
-    for more details.
-
-    ### List targets and variables (--list) {#list}
-
-    The `--list` flag displays all available targets or variables in the Bake
-    configuration, along with a description (if set using the `description`
-    property in the Bake file).
-
-    To list all targets:
-
-    ```console {title="List targets"}
-    $ docker buildx bake --list=targets
-    TARGET              DESCRIPTION
-    binaries
-    default             binaries
-    update-docs
-    validate
-    validate-golangci   Validate .golangci.yml schema (does not run Go linter)
-    ```
-
-    To list variables:
-
-    ```console
-    $ docker buildx bake --list=variables
-    VARIABLE      VALUE                DESCRIPTION
-    REGISTRY      docker.io/username   Registry and namespace
-    IMAGE_NAME    my-app               Image name
-    GO_VERSION    <null>
-    ```
-
-    By default, the output of `docker buildx bake --list` is presented in a table
-    format. Alternatively, you can use a long-form CSV syntax and specify a
-    `format` attribute to output the list in JSON.
-
-    ```console
-    $ docker buildx bake --list=type=targets,format=json
-    ```
-
-    ### Write build results metadata to a file (--metadata-file) {#metadata-file}
-
-    Similar to [`buildx build --metadata-file`](/reference/cli/docker/buildx/build/#metadata-file) but
-    writes a map of results for each target such as:
-
-    ```hcl
-    # docker-bake.hcl
-    group "default" {
-      targets = ["db", "webapp-dev"]
-    }
-
-    target "db" {
-      dockerfile = "Dockerfile.db"
-      tags = ["docker.io/username/db"]
-    }
-
-    target "webapp-dev" {
-      dockerfile = "Dockerfile.webapp"
-      tags = ["docker.io/username/webapp"]
-    }
-    ```
-
-    ```console
-    $ docker buildx bake --load --metadata-file metadata.json .
-    $ cat metadata.json
-    ```
-
-    ```json
-    {
-      "buildx.build.warnings": {},
-      "db": {
-        "buildx.build.provenance": {},
-        "buildx.build.ref": "mybuilder/mybuilder0/0fjb6ubs52xx3vygf6fgdl611",
-        "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66",
-        "containerimage.descriptor": {
-          "annotations": {
-            "config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66",
-            "org.opencontainers.image.created": "2022-02-08T21:28:03Z"
-          },
-          "digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3",
-          "mediaType": "application/vnd.oci.image.manifest.v1+json",
-          "size": 506
-        },
-        "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"
-      },
-      "webapp-dev": {
-        "buildx.build.provenance": {},
-        "buildx.build.ref": "mybuilder/mybuilder0/kamngmcgyzebqxwu98b4lfv3n",
-        "containerimage.config.digest": "sha256:9651cc2b3c508f697c9c43b67b64c8359c2865c019e680aac1c11f4b875b67e0",
-        "containerimage.descriptor": {
-          "annotations": {
-            "config.digest": "sha256:9651cc2b3c508f697c9c43b67b64c8359c2865c019e680aac1c11f4b875b67e0",
-            "org.opencontainers.image.created": "2022-02-08T21:28:15Z"
-          },
-          "digest": "sha256:6d9ac9237a84afe1516540f40a0fafdc86859b2141954b4d643af7066d598b74",
-          "mediaType": "application/vnd.oci.image.manifest.v1+json",
-          "size": 506
-        },
-        "containerimage.digest": "sha256:6d9ac9237a84afe1516540f40a0fafdc86859b2141954b4d643af7066d598b74"
-      }
-    }
-    ```
-
-    > [!NOTE]
-    > Build record [provenance](/build/metadata/attestations/slsa-provenance/#provenance-attestation-example)
-    > (`buildx.build.provenance`) includes minimal provenance by default. Set the
-    > `BUILDX_METADATA_PROVENANCE` environment variable to customize this behavior:
-    > * `min` sets minimal provenance (default).
-    > * `max` sets full provenance.
-    > * `disabled`, `false` or `0` does not set any provenance.
-
-    > [!NOTE]
-    > Build warnings (`buildx.build.warnings`) are not included by default. Set the
-    > `BUILDX_METADATA_WARNINGS` environment variable to `1` or `true` to
-    > include them.
-
-    ### Don't use cache when building the image (--no-cache) {#no-cache}
-
-    Same as `build --no-cache`. Don't use cache when building the image.
-
-    ### Print the options without building (--print) {#print}
-
-    Prints the resulting options of the targets desired to be built, in a JSON
-    format, without starting a build.
-
-    ```console
-    $ docker buildx bake -f docker-bake.hcl --print db
-    {
-      "group": {
-        "default": {
-          "targets": [
-            "db"
-          ]
-        }
-      },
-      "target": {
-        "db": {
-          "context": "./",
-          "dockerfile": "Dockerfile",
-          "tags": [
-            "docker.io/tiborvass/db"
-          ]
-        }
-      }
-    }
-    ```
-
-    ### Set type of progress output (--progress) {#progress}
-
-    Same as [`build --progress`](/reference/cli/docker/buildx/build/#progress).
-
-    ### Create provenance attestations (--provenance) {#provenance}
-
-    Same as [`build --provenance`](/reference/cli/docker/buildx/build/#provenance).
-
-    ### Always attempt to pull a newer version of the image (--pull) {#pull}
-
-    Same as `build --pull`.
-
-    ### Create SBOM attestations (--sbom) {#sbom}
-
-    Same as [`build --sbom`](/reference/cli/docker/buildx/build/#sbom).
-
-    ### Override target configurations from command line (--set) {#set}
-
-    ```
-    --set targetpattern.key[.subkey]=value
-    ```
-
-    Override target configurations from command line. The pattern matching syntax
-    is defined in https://golang.org/pkg/path/#Match.
-
-    ```console
-    $ docker buildx bake --set target.args.mybuildarg=value
-    $ docker buildx bake --set target.platform=linux/arm64
-    $ docker buildx bake --set foo*.args.mybuildarg=value   # overrides build arg for all targets starting with 'foo'
-    $ docker buildx bake --set *.platform=linux/arm64       # overrides platform for all targets
-    $ docker buildx bake --set foo*.no-cache                # bypass caching only for targets starting with 'foo'
-    $ docker buildx bake --set target.platform+=linux/arm64 # appends 'linux/arm64' to the platform list
-    ```
-
-    You can override the following fields:
-
-    * `annotations`
-    * `attest`
-    * `args`
-    * `cache-from`
-    * `cache-to`
-    * `context`
-    * `dockerfile`
-    * `entitlements`
-    * `labels`
-    * `load`
-    * `no-cache`
-    * `no-cache-filter`
-    * `output`
-    * `platform`
-    * `pull`
-    * `push`
-    * `secrets`
-    * `ssh`
-    * `tags`
-    * `target`
-
-    You can append using `+=` operator for the following fields:
-
-    * `annotations`¹
-    * `attest`¹
-    * `cache-from`
-    * `cache-to`
-    * `entitlements`¹
-    * `no-cache-filter`
-    * `output`
-    * `platform`
-    * `secrets`
-    * `ssh`
-    * `tags`
-
-    > [!NOTE]
-    > ¹ These fields already append by default.
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_debug.yaml b/data/buildx/docker_buildx_debug.yaml
deleted file mode 100644
index 90e6d0e8756a..000000000000
--- a/data/buildx/docker_buildx_debug.yaml
+++ /dev/null
@@ -1,98 +0,0 @@
-command: docker buildx debug
-short: Start debugger
-long: Start debugger
-usage: docker buildx debug
-pname: docker buildx
-plink: docker_buildx.yaml
-cname:
-    - docker buildx debug build
-clink:
-    - docker_buildx_debug_build.yaml
-options:
-    - option: detach
-      value_type: bool
-      default_value: "true"
-      description: Detach buildx server for the monitor (supported only on linux)
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: true
-      kubernetes: false
-      swarm: false
-    - option: invoke
-      value_type: string
-      description: Launch a monitor with executing specified command
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: true
-      kubernetes: false
-      swarm: false
-    - option: "on"
-      value_type: string
-      default_value: error
-      description: When to launch the monitor ([always, error])
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: true
-      kubernetes: false
-      swarm: false
-    - option: progress
-      value_type: string
-      default_value: auto
-      description: |
-        Set type of progress output (`auto`, `plain`, `tty`, `rawjson`) for the monitor. Use plain to show container output
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: root
-      value_type: string
-      description: Specify root directory of server to connect for the monitor
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: true
-      kubernetes: false
-      swarm: false
-    - option: server-config
-      value_type: string
-      description: |
-        Specify buildx server config file for the monitor (used only when launching new server)
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: true
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: true
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_du.yaml b/data/buildx/docker_buildx_du.yaml
deleted file mode 100644
index a390b95b2076..000000000000
--- a/data/buildx/docker_buildx_du.yaml
+++ /dev/null
@@ -1,153 +0,0 @@
-command: docker buildx du
-short: Disk usage
-long: Disk usage
-usage: docker buildx du
-pname: docker buildx
-plink: docker_buildx.yaml
-options:
-    - option: filter
-      value_type: filter
-      description: Provide filter values
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: verbose
-      value_type: bool
-      default_value: "false"
-      description: Provide a more verbose output
-      details_url: '#verbose'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      details_url: '#builder'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-examples: |-
-    ### Show disk usage
-
-    The `docker buildx du` command shows the disk usage for the currently selected
-    builder.
-
-    ```console
-    $ docker buildx du
-    ID                                RECLAIMABLE    SIZE          LAST ACCESSED
-    12wgll9os87pazzft8lt0yztp*        true           1.704GB       13 days ago
-    iupsv3it5ubh92aweb7c1wojc*        true           1.297GB       36 minutes ago
-    ek4ve8h4obyv5kld6vicmtqyn         true           811.7MB       13 days ago
-    isovrfnmkelzhtdx942w9vjcb*        true           811.7MB       13 days ago
-    0jty7mjrndi1yo7xkv1baralh         true           810.5MB       13 days ago
-    jyzkefmsysqiaakgwmjgxjpcz*        true           810.5MB       13 days ago
-    z8w1y95jn93gvj92jtaj6uhwk         true           318MB         2 weeks ago
-    rz2zgfcwlfxsxd7d41w2sz2tt         true           8.224kB*      43 hours ago
-    n5bkzpewmk2eiu6hn9tzx18jd         true           8.224kB*      43 hours ago
-    ao94g6vtbzdl6k5zgdmrmnwpt         true           8.224kB*      43 hours ago
-    2pyjep7njm0wh39vcingxb97i         true           8.224kB*      43 hours ago
-    Shared:        115.5MB
-    Private:       10.25GB
-    Reclaimable:   10.36GB
-    Total:         10.36GB
-    ```
-
-    If `RECLAIMABLE` is false, the `docker buildx du prune` command won't delete
-    the record, even if you use `--all`. That's because the record is actively in
-    use by some component of the builder.
-
-    The asterisks (\*) in the default output indicate the following:
-
-    - An asterisk next to an ID (`zu7m6evdpebh5h8kfkpw9dlf2*`) indicates that the record
-      is mutable. The size of the record may change, or another build can take ownership of
-      it and change or commit to it. If you run the `du` command again, this item may
-      not be there anymore, or the size might be different.
-    - An asterisk next to a size (`8.288kB*`) indicates that the record is shared.
-      Storage of the record is shared with some other resource, typically an image.
-      If you prune such a record then you will lose build cache but only metadata
-      will be deleted as the image still needs to actual storage layers.
-
-    ### Use verbose output (--verbose) {#verbose}
-
-    The verbose output of the `docker buildx du` command is useful for inspecting
-    the disk usage records in more detail. The verbose output shows the mutable and
-    shared states more clearly, as well as additional information about the
-    corresponding layer.
-
-    ```console
-    $ docker buildx du --verbose
-    ...
-    Last used:      2 days ago
-    Type:           regular
-
-    ID:             05d0elirb4mmvpmnzbrp3ssrg
-    Parent:         e8sfdn4mygrg7msi9ak1dy6op
-    Created at:     2023-11-20 09:53:30.881558721 +0000 UTC
-    Mutable:        false
-    Reclaimable:    true
-    Shared:         false
-    Size:           0B
-    Description:    [gobase 3/3] WORKDIR /src
-    Usage count:    3
-    Last used:      24 hours ago
-    Type:           regular
-
-    Reclaimable:    4.453GB
-    Total:          4.453GB
-    ```
-
-    ### Override the configured builder instance (--builder) {#builder}
-
-    Use the `--builder` flag to inspect the disk usage of a particular builder.
-
-    ```console
-    $ docker buildx du --builder youthful_shtern
-    ID                                RECLAIMABLE    SIZE          LAST ACCESSED
-    g41agepgdczekxg2mtw0dujsv*        true           1.312GB       47 hours ago
-    e6ycrsa0bn9akigqgzu0sc6kr         true           318MB         47 hours ago
-    our9zg4ndly65ze1ccczdksiz         true           204.9MB       45 hours ago
-    b7xv3xpxnwupc81tc9ya3mgq6*        true           120.6MB       47 hours ago
-    zihgye15ss6vum3wmck9egdoy*        true           79.81MB       2 days ago
-    aaydharssv1ug98yhuwclkfrh*        true           79.81MB       2 days ago
-    ta1r4vmnjug5dhub76as4kkol*        true           74.51MB       47 hours ago
-    murma9f83j9h8miifbq68udjf*        true           74.51MB       47 hours ago
-    47f961866a49g5y8myz80ixw1*        true           74.51MB       47 hours ago
-    tzh99xtzlaf6txllh3cobag8t         true           74.49MB       47 hours ago
-    ld6laoeuo1kwapysu6afwqybl*        true           59.89MB       47 hours ago
-    yitxizi5kaplpyomqpos2cryp*        true           59.83MB       47 hours ago
-    iy8aa4b7qjn0qmy9wiga9cj8w         true           33.65MB       47 hours ago
-    mci7okeijyp8aqqk16j80dy09         true           19.86MB       47 hours ago
-    lqvj091he652slxdla4wom3pz         true           14.08MB       47 hours ago
-    fkt31oiv793nd26h42llsjcw7*        true           11.87MB       2 days ago
-    uj802yxtvkcjysnjb4kgwvn2v         true           11.68MB       45 hours ago
-    Reclaimable:    2.627GB
-    Total:          2.627GB
-    ```
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_history_export.yaml b/data/buildx/docker_buildx_history_export.yaml
deleted file mode 100644
index e70b8f8fba95..000000000000
--- a/data/buildx/docker_buildx_history_export.yaml
+++ /dev/null
@@ -1,55 +0,0 @@
-command: docker buildx history export
-short: Export a build into Docker Desktop bundle
-long: Export a build into Docker Desktop bundle
-usage: docker buildx history export [OPTIONS] [REF]
-pname: docker buildx history
-plink: docker_buildx_history.yaml
-options:
-    - option: all
-      value_type: bool
-      default_value: "false"
-      description: Export all records for the builder
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: output
-      shorthand: o
-      value_type: string
-      description: Output file path
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_history_import.yaml b/data/buildx/docker_buildx_history_import.yaml
deleted file mode 100644
index 089a7b328da0..000000000000
--- a/data/buildx/docker_buildx_history_import.yaml
+++ /dev/null
@@ -1,46 +0,0 @@
-command: docker buildx history import
-short: Import a build into Docker Desktop
-long: Import a build into Docker Desktop
-usage: docker buildx history import [OPTIONS] < bundle.dockerbuild
-pname: docker buildx history
-plink: docker_buildx_history.yaml
-options:
-    - option: file
-      shorthand: f
-      value_type: stringArray
-      default_value: '[]'
-      description: Import from a file path
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_history_inspect.yaml b/data/buildx/docker_buildx_history_inspect.yaml
deleted file mode 100644
index 65bbe11d597f..000000000000
--- a/data/buildx/docker_buildx_history_inspect.yaml
+++ /dev/null
@@ -1,143 +0,0 @@
-command: docker buildx history inspect
-short: Inspect a build
-long: Inspect a build
-usage: docker buildx history inspect [OPTIONS] [REF]
-pname: docker buildx history
-plink: docker_buildx_history.yaml
-cname:
-    - docker buildx history inspect attachment
-clink:
-    - docker_buildx_history_inspect_attachment.yaml
-options:
-    - option: format
-      value_type: string
-      default_value: pretty
-      description: Format the output
-      details_url: '#format'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-examples: |-
-    ### Format the output (--format) {#format}
-
-    The formatting options (`--format`) pretty-prints the output to `pretty` (default),
-    `json` or using a Go template.
-
-    ```console
-    $ docker buildx history inspect
-    Name:           buildx (binaries)
-    Context:        .
-    Dockerfile:     Dockerfile
-    VCS Repository: https://github.com/crazy-max/buildx.git
-    VCS Revision:   f15eaa1ee324ffbbab29605600d27a84cab86361
-    Target:         binaries
-    Platforms:      linux/amd64
-    Keep Git Dir:   true
-
-    Started:        2025-02-07 11:56:24
-    Duration:       1m  1s
-    Build Steps:    16/16 (25% cached)
-
-    Image Resolve Mode:     local
-
-    Materials:
-    URI                                                             DIGEST
-    pkg:docker/docker/dockerfile@1                                  sha256:93bfd3b68c109427185cd78b4779fc82b484b0b7618e36d0f104d4d801e66d25
-    pkg:docker/golang@1.23-alpine3.21?platform=linux%2Famd64        sha256:2c49857f2295e89b23b28386e57e018a86620a8fede5003900f2d138ba9c4037
-    pkg:docker/tonistiigi/xx@1.6.1?platform=linux%2Famd64           sha256:923441d7c25f1e2eb5789f82d987693c47b8ed987c4ab3b075d6ed2b5d6779a3
-
-    Attachments:
-    DIGEST                                                                  PLATFORM        TYPE
-    sha256:217329d2af959d4f02e3a96dcbe62bf100cab1feb8006a047ddfe51a5397f7e3                 https://slsa.dev/provenance/v0.2
-
-    Print build logs: docker buildx history logs g9808bwrjrlkbhdamxklx660b
-    ```
-
-    ```console
-    $ docker buildx history inspect --format json
-    {
-      "Name": "buildx (binaries)",
-      "Ref": "5w7vkqfi0rf59hw4hnmn627r9",
-      "Context": ".",
-      "Dockerfile": "Dockerfile",
-      "VCSRepository": "https://github.com/crazy-max/buildx.git",
-      "VCSRevision": "f15eaa1ee324ffbbab29605600d27a84cab86361",
-      "Target": "binaries",
-      "Platform": [
-        "linux/amd64"
-      ],
-      "KeepGitDir": true,
-      "StartedAt": "2025-02-07T12:01:05.75807272+01:00",
-      "CompletedAt": "2025-02-07T12:02:07.991778875+01:00",
-      "Duration": 62233706155,
-      "Status": "completed",
-      "NumCompletedSteps": 16,
-      "NumTotalSteps": 16,
-      "NumCachedSteps": 4,
-      "Config": {
-        "ImageResolveMode": "local"
-      },
-      "Materials": [
-        {
-          "URI": "pkg:docker/docker/dockerfile@1",
-          "Digests": [
-            "sha256:93bfd3b68c109427185cd78b4779fc82b484b0b7618e36d0f104d4d801e66d25"
-          ]
-        },
-        {
-          "URI": "pkg:docker/golang@1.23-alpine3.21?platform=linux%2Famd64",
-          "Digests": [
-            "sha256:2c49857f2295e89b23b28386e57e018a86620a8fede5003900f2d138ba9c4037"
-          ]
-        },
-        {
-          "URI": "pkg:docker/tonistiigi/xx@1.6.1?platform=linux%2Famd64",
-          "Digests": [
-            "sha256:923441d7c25f1e2eb5789f82d987693c47b8ed987c4ab3b075d6ed2b5d6779a3"
-          ]
-        }
-      ],
-      "Attachments": [
-        {
-          "Digest": "sha256:450fdd2e6b868fecd69e9891c2c404ba461aa38a47663b4805edeb8d2baf80b1",
-          "Type": "https://slsa.dev/provenance/v0.2"
-        }
-      ]
-    }
-    ```
-
-    ```console
-    $ docker buildx history inspect --format "{{.Name}}: {{.VCSRepository}} ({{.VCSRevision}})"
-    buildx (binaries): https://github.com/crazy-max/buildx.git (f15eaa1ee324ffbbab29605600d27a84cab86361)
-    ```
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_history_inspect_attachment.yaml b/data/buildx/docker_buildx_history_inspect_attachment.yaml
deleted file mode 100644
index c43308120bba..000000000000
--- a/data/buildx/docker_buildx_history_inspect_attachment.yaml
+++ /dev/null
@@ -1,53 +0,0 @@
-command: docker buildx history inspect attachment
-short: Inspect a build attachment
-long: Inspect a build attachment
-usage: docker buildx history inspect attachment [OPTIONS] REF [DIGEST]
-pname: docker buildx history inspect
-plink: docker_buildx_history_inspect.yaml
-options:
-    - option: platform
-      value_type: string
-      description: Platform of attachment
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: type
-      value_type: string
-      description: Type of attachment
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_history_logs.yaml b/data/buildx/docker_buildx_history_logs.yaml
deleted file mode 100644
index c6afba47cda9..000000000000
--- a/data/buildx/docker_buildx_history_logs.yaml
+++ /dev/null
@@ -1,45 +0,0 @@
-command: docker buildx history logs
-short: Print the logs of a build
-long: Print the logs of a build
-usage: docker buildx history logs [OPTIONS] [REF]
-pname: docker buildx history
-plink: docker_buildx_history.yaml
-options:
-    - option: progress
-      value_type: string
-      default_value: plain
-      description: Set type of progress output (plain, rawjson, tty)
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_history_ls.yaml b/data/buildx/docker_buildx_history_ls.yaml
deleted file mode 100644
index ab7a3abbb3b1..000000000000
--- a/data/buildx/docker_buildx_history_ls.yaml
+++ /dev/null
@@ -1,75 +0,0 @@
-command: docker buildx history ls
-short: List build records
-long: List build records
-usage: docker buildx history ls
-pname: docker buildx history
-plink: docker_buildx_history.yaml
-options:
-    - option: filter
-      value_type: stringArray
-      default_value: '[]'
-      description: Provide filter values (e.g., `status=error`)
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: format
-      value_type: string
-      default_value: table
-      description: Format the output
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: local
-      value_type: bool
-      default_value: "false"
-      description: List records for current repository only
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: no-trunc
-      value_type: bool
-      default_value: "false"
-      description: Don't truncate output
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_history_open.yaml b/data/buildx/docker_buildx_history_open.yaml
deleted file mode 100644
index e79b0ba56997..000000000000
--- a/data/buildx/docker_buildx_history_open.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
-command: docker buildx history open
-short: Open a build in Docker Desktop
-long: Open a build in Docker Desktop
-usage: docker buildx history open [OPTIONS] [REF]
-pname: docker buildx history
-plink: docker_buildx_history.yaml
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_history_rm.yaml b/data/buildx/docker_buildx_history_rm.yaml
deleted file mode 100644
index aa3ddd173cbb..000000000000
--- a/data/buildx/docker_buildx_history_rm.yaml
+++ /dev/null
@@ -1,45 +0,0 @@
-command: docker buildx history rm
-short: Remove build records
-long: Remove build records
-usage: docker buildx history rm [OPTIONS] [REF...]
-pname: docker buildx history
-plink: docker_buildx_history.yaml
-options:
-    - option: all
-      value_type: bool
-      default_value: "false"
-      description: Remove all build records
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_history_trace.yaml b/data/buildx/docker_buildx_history_trace.yaml
deleted file mode 100644
index 54a4f4cd7873..000000000000
--- a/data/buildx/docker_buildx_history_trace.yaml
+++ /dev/null
@@ -1,54 +0,0 @@
-command: docker buildx history trace
-short: Show the OpenTelemetry trace of a build record
-long: Show the OpenTelemetry trace of a build record
-usage: docker buildx history trace [OPTIONS] [REF]
-pname: docker buildx history
-plink: docker_buildx_history.yaml
-options:
-    - option: addr
-      value_type: string
-      default_value: 127.0.0.1:0
-      description: Address to bind the UI server
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: compare
-      value_type: string
-      description: Compare with another build reference
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx_prune.yaml b/data/buildx/docker_buildx_prune.yaml
deleted file mode 100644
index 9accff771c23..000000000000
--- a/data/buildx/docker_buildx_prune.yaml
+++ /dev/null
@@ -1,138 +0,0 @@
-command: docker buildx prune
-short: Remove build cache
-long: |-
-    Clears the build cache of the selected builder.
-
-    You can finely control what cache data is kept using:
-
-    - The `--filter=until=<duration>` flag to keep images that have been used in
-      the last `<duration>` time.
-
-      `<duration>` is a duration string, e.g. `24h` or `2h30m`, with allowable
-      units of `(h)ours`, `(m)inutes` and `(s)econds`.
-
-    - The `--keep-storage=<size>` flag to keep `<size>` bytes of data in the cache.
-
-      `<size>` is a human-readable memory string, e.g. `128mb`, `2gb`, etc. Units
-      are case-insensitive.
-
-    - The `--all` flag to allow clearing internal helper images and frontend images
-      set using the `#syntax=` directive or the `BUILDKIT_SYNTAX` build argument.
-usage: docker buildx prune
-pname: docker buildx
-plink: docker_buildx.yaml
-options:
-    - option: all
-      shorthand: a
-      value_type: bool
-      default_value: "false"
-      description: Include internal/frontend images
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: filter
-      value_type: filter
-      description: Provide filter values (e.g., `until=24h`)
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: force
-      shorthand: f
-      value_type: bool
-      default_value: "false"
-      description: Do not prompt for confirmation
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: keep-storage
-      value_type: bytes
-      default_value: "0"
-      description: Amount of disk space to keep for cache
-      deprecated: true
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: max-used-space
-      value_type: bytes
-      default_value: "0"
-      description: Maximum amount of disk space allowed to keep for cache
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: min-free-space
-      value_type: bytes
-      default_value: "0"
-      description: Target amount of free disk space after pruning
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: reserved-space
-      value_type: bytes
-      default_value: "0"
-      description: Amount of disk space always allowed to keep for cache
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: verbose
-      value_type: bool
-      default_value: "false"
-      description: Provide a more verbose output
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: builder
-      value_type: string
-      description: Override the configured builder instance
-      details_url: '#builder'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: debug
-      shorthand: D
-      value_type: bool
-      default_value: "false"
-      description: Enable debug logging
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-examples: |-
-    ### Override the configured builder instance (--builder) {#builder}
-
-    Same as [`buildx --builder`](/reference/cli/docker/buildx/#builder).
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/buildx/docker_buildx.yaml b/data/cli/buildx/docker_buildx.yaml
similarity index 77%
rename from data/buildx/docker_buildx.yaml
rename to data/cli/buildx/docker_buildx.yaml
index 4c786feff7d9..abdde0bd4573 100644
--- a/data/buildx/docker_buildx.yaml
+++ b/data/cli/buildx/docker_buildx.yaml
@@ -8,6 +8,7 @@ cname:
     - docker buildx bake
     - docker buildx build
     - docker buildx create
+    - docker buildx dap
     - docker buildx debug
     - docker buildx dial-stdio
     - docker buildx du
@@ -15,6 +16,7 @@ cname:
     - docker buildx imagetools
     - docker buildx inspect
     - docker buildx ls
+    - docker buildx policy
     - docker buildx prune
     - docker buildx rm
     - docker buildx stop
@@ -24,6 +26,7 @@ clink:
     - docker_buildx_bake.yaml
     - docker_buildx_build.yaml
     - docker_buildx_create.yaml
+    - docker_buildx_dap.yaml
     - docker_buildx_debug.yaml
     - docker_buildx_dial-stdio.yaml
     - docker_buildx_du.yaml
@@ -31,6 +34,7 @@ clink:
     - docker_buildx_imagetools.yaml
     - docker_buildx_inspect.yaml
     - docker_buildx_ls.yaml
+    - docker_buildx_policy.yaml
     - docker_buildx_prune.yaml
     - docker_buildx_rm.yaml
     - docker_buildx_stop.yaml
@@ -62,6 +66,14 @@ examples: |-
     ### Override the configured builder instance (--builder) {#builder}
 
     You can also use the `BUILDX_BUILDER` environment variable.
+
+    ### Enable the default policy
+
+    Set `BUILDX_DEFAULT_POLICY=1` to enable Buildx's built-in source policy. The
+    policy verifies signed tags for images managed by Docker, including BuildKit
+    builder images and Dockerfile frontends. Untagged digest references and images
+    outside the managed repositories are allowed unchanged. Tagged references
+    that also contain a digest still have their release identity verified.
 deprecated: false
 hidden: false
 experimental: false
diff --git a/data/cli/buildx/docker_buildx_bake.yaml b/data/cli/buildx/docker_buildx_bake.yaml
new file mode 100644
index 000000000000..8ff6ec6a5af7
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_bake.yaml
@@ -0,0 +1,729 @@
+command: docker buildx bake
+aliases: docker buildx bake, docker buildx f
+short: Build from a file
+long: |-
+    Bake is a high-level build command. Each specified target runs in parallel
+    as part of the build.
+
+    Read [High-level build options with Bake](/build/bake/)
+    guide for introduction to writing bake files.
+
+    > [!NOTE]
+    > `buildx bake` command may receive backwards incompatible features in the future
+    > if needed. We are looking for feedback on improving the command and extending
+    > the functionality further.
+usage: docker buildx bake [OPTIONS] [TARGET...]
+pname: docker buildx
+plink: docker_buildx.yaml
+options:
+    - option: allow
+      value_type: stringArray
+      default_value: '[]'
+      description: Allow build to access specified resources
+      details_url: '#allow'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: call
+      value_type: string
+      default_value: build
+      description: Set method for evaluating build (`check`, `outline`, `targets`)
+      details_url: '#call'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: check
+      value_type: bool
+      description: Shorthand for `--call=check`
+      details_url: '#check'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: file
+      shorthand: f
+      value_type: stringArray
+      default_value: '[]'
+      description: Build definition file
+      details_url: '#file'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: list
+      value_type: string
+      description: List targets or variables
+      details_url: '#list'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: list-targets
+      value_type: bool
+      default_value: "false"
+      description: List available targets
+      deprecated: true
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: list-variables
+      value_type: bool
+      default_value: "false"
+      description: List defined variables
+      deprecated: true
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: load
+      value_type: bool
+      default_value: "false"
+      description: Shorthand for `--set=*.output=type=docker`. Conditional.
+      details_url: '#load'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: metadata-file
+      value_type: string
+      description: Write build result metadata to a file
+      details_url: '#metadata-file'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: no-cache
+      value_type: bool
+      default_value: "false"
+      description: Do not use cache when building the image
+      details_url: '#no-cache'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Global policy evaluation options (format: `[disabled=true|false][,strict=true|false][,log-level=level]`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: print
+      value_type: bool
+      default_value: "false"
+      description: Print the options without building
+      details_url: '#print'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: progress
+      value_type: string
+      default_value: auto
+      description: |
+        Set type of progress output (`auto`, `none`,  `plain`, `quiet`, `rawjson`, `tty`). Use plain to show container output
+      details_url: '#progress'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: provenance
+      value_type: string
+      description: Shorthand for `--set=*.attest=type=provenance`
+      details_url: '#provenance'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: pull
+      value_type: bool
+      default_value: "false"
+      description: Always attempt to pull all referenced images
+      details_url: '#pull'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: push
+      value_type: bool
+      default_value: "false"
+      description: Shorthand for `--set=*.output=type=registry`. Conditional.
+      details_url: '#push'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: sbom
+      value_type: string
+      description: Shorthand for `--set=*.attest=type=sbom`
+      details_url: '#sbom'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: set
+      value_type: stringArray
+      default_value: '[]'
+      description: Override target value (e.g., `targetpattern.key=value`)
+      details_url: '#set'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: var
+      value_type: stringArray
+      default_value: '[]'
+      description: Set a variable value (e.g., `name=value`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      details_url: '#builder'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Allow extra privileged entitlement (--allow) {#allow}
+
+    ```text
+    --allow=ENTITLEMENT[=VALUE]
+    ```
+
+    Entitlements are designed to provide controlled access to privileged
+    operations. By default, Buildx and BuildKit operates with restricted
+    permissions to protect users and their systems from unintended side effects or
+    security risks. The `--allow` flag explicitly grants access to additional
+    entitlements, making it clear when a build or bake operation requires elevated
+    privileges.
+
+    In addition to BuildKit's `network.host` and `security.insecure` entitlements
+    (see [`docker buildx build --allow`](/reference/cli/docker/buildx/build/#allow)),
+    Bake supports file system entitlements that grant granular control over file
+    system access. These are particularly useful when working with builds that need
+    access to files outside the default working directory.
+
+    Bake supports the following filesystem entitlements:
+
+    - `--allow fs=<path|*>` - Grant read and write access to files outside of the
+      working directory.
+    - `--allow fs.read=<path|*>` - Grant read access to files outside of the
+      working directory.
+    - `--allow fs.write=<path|*>` - Grant write access to files outside of the
+      working directory.
+
+    The `fs` entitlements take a path value (relative or absolute) to a directory
+    on the filesystem. Alternatively, you can pass a wildcard (`*`) to allow Bake
+    to access the entire filesystem.
+
+    Bake also supports `--allow=buildx.local.delete` to grant local outputs
+    permission to delete stale files when `mode=delete` is set.
+
+    ### Example: fs.read
+
+    Given the following Bake configuration, Bake would need to access the parent
+    directory, relative to the Bake file.
+
+    ```hcl
+    target "app" {
+      context = "../src"
+    }
+    ```
+
+    Assuming `docker buildx bake app` is executed in the same directory as the
+    `docker-bake.hcl` file, you would need to explicitly allow Bake to read from
+    the `../src` directory. In this case, the following invocations all work:
+
+    ```console
+    $ docker buildx bake --allow fs.read=* app
+    $ docker buildx bake --allow fs.read=../src app
+    $ docker buildx bake --allow fs=* app
+    ```
+
+    ### Example: fs.write
+
+    The following `docker-bake.hcl` file requires write access to the `/tmp`
+    directory.
+
+    ```hcl
+    target "app" {
+      output = "/tmp"
+    }
+    ```
+
+    Assuming `docker buildx bake app` is executed outside of the `/tmp` directory,
+    you would need to allow the `fs.write` entitlement, either by specifying the
+    path or using a wildcard:
+
+    ```console
+    $ docker buildx bake --allow fs=/tmp app
+    $ docker buildx bake --allow fs.write=/tmp app
+    $ docker buildx bake --allow fs.write=* app
+    ```
+
+    ### Override the configured builder instance (--builder) {#builder}
+
+    Same as [`buildx --builder`](/reference/cli/docker/buildx/#builder).
+
+    ### Invoke a frontend method (--call) {#call}
+
+    Same as [`build --call`](/reference/cli/docker/buildx/build/#call).
+
+    #### Call: check (--check) {#check}
+
+    Same as [`build --check`](/reference/cli/docker/buildx/build/#check).
+
+    ### Specify a build definition file (-f, --file) {#file}
+
+    Use the `-f` / `--file` option to specify the build definition file to use.
+    The file can be an HCL, JSON or Compose file. If multiple files are specified,
+    all are read and the build configurations are combined.
+
+    Alternatively, the environment variable `BUILDX_BAKE_FILE` can be used to specify the build definition to use.
+    This is mutually exclusive with `-f` / `--file`; if both are specified, the environment variable is ignored.
+    Multiple definitions can be specified by separating them with the system's path separator
+    (typically `;` on Windows and `:` elsewhere), but can be changed with `BUILDX_BAKE_PATH_SEPARATOR`.
+
+    By default, local directory build contexts in Bake files are resolved from the
+    current working directory. To opt in to resolving local directory build contexts
+    from the Bake file that defines each path, set
+    `BUILDX_BAKE_FILE_RELATIVE_PATHS=1`. Compose files use the first Compose file
+    directory as the base, which matches Compose project directory semantics. Use
+    the `cwd://` prefix for paths that should remain relative to the current working
+    directory.
+
+    You can pass the names of the targets to build, to build only specific target(s).
+    The following example builds the `db` and `webapp-release` targets that are
+    defined in the `docker-bake.dev.hcl` file:
+
+    ```hcl
+    # docker-bake.dev.hcl
+    group "default" {
+      targets = ["db", "webapp-dev"]
+    }
+
+    target "webapp-dev" {
+      dockerfile = "Dockerfile.webapp"
+      tags = ["docker.io/username/webapp"]
+    }
+
+    target "webapp-release" {
+      inherits = ["webapp-dev"]
+      platforms = ["linux/amd64", "linux/arm64"]
+    }
+
+    target "db" {
+      dockerfile = "Dockerfile.db"
+      tags = ["docker.io/username/db"]
+    }
+    ```
+
+    ```console
+    $ docker buildx bake -f docker-bake.dev.hcl db webapp-release
+    ```
+
+    See the [Bake file reference](/build/bake/reference/)
+    for more details.
+
+    ### List targets and variables (--list) {#list}
+
+    The `--list` flag displays all available targets or variables in the Bake
+    configuration, along with a description (if set using the `description`
+    property in the Bake file).
+
+    To list all targets:
+
+    ```console {title="List targets"}
+    $ docker buildx bake --list=targets
+    TARGET              DESCRIPTION
+    binaries
+    default             binaries
+    update-docs
+    validate
+    validate-golangci   Validate .golangci.yml schema (does not run Go linter)
+    ```
+
+    To list variables:
+
+    ```console
+    $ docker buildx bake --list=variables
+    VARIABLE      TYPE      VALUE                DESCRIPTION
+    REGISTRY      string    docker.io/username   Registry and namespace
+    IMAGE_NAME    string    my-app               Image name
+    GO_VERSION              <null>
+    DEBUG         bool      false                Add debug symbols
+    ```
+
+    Variable types will be shown when set using the `type` property in the Bake file.
+
+    The `--list=variables` option displays variables defined in the Bake file, including their descriptions and default values.
+
+    ### Example: listing variables with descriptions
+
+    ```hcl
+    variable "GO_VERSION" {
+      default     = "1.22"
+      description = "Go version used for building the application"
+    }
+    ```
+
+    ```console
+    $ docker buildx bake --list=variables
+
+    NAME          DESCRIPTION                                      DEFAULT
+    GO_VERSION    Go version used for building the application     1.22
+    ```
+
+    By default, the output of `docker buildx bake --list` is presented in a table
+    format. Alternatively, you can use a long-form CSV syntax and specify a
+    `format` attribute to output the list in JSON.
+
+    ```console
+    $ docker buildx bake --list=type=targets,format=json
+    ```
+
+    ### Load images into Docker (--load) {#load}
+
+    The `--load` flag is a convenience shorthand for adding an image export of type
+    `docker`:
+
+    ```console
+    --load   ≈   --set=*.output=type=docker
+    ```
+
+    However, its behavior is conditional:
+
+    - If the build definition has no output defined, `--load` adds
+    `type=docker`.
+    - If the build definition’s outputs are `docker`, `image`, `registry`,
+    `oci`, `--load` will add a `type=docker` export if one is not already present.
+    - If the build definition contains `local` or `tar` outputs,
+    `--load` does nothing. It will not override those outputs.
+
+    For example, with the following bake file:
+
+    ```hcl
+    target "default" {
+      output = ["type=tar,dest=hi.tar"]
+    }
+    ```
+
+    With `--load`:
+
+    ```console
+    $ docker buildx bake --load --print
+    ...
+    "output": [
+      {
+        "dest": "hi.tar"
+        "type": "tar",
+       }
+    ]
+    ```
+
+    The `tar` output remains unchanged.
+
+    ### Write build results metadata to a file (--metadata-file) {#metadata-file}
+
+    Similar to [`buildx build --metadata-file`](/reference/cli/docker/buildx/build/#metadata-file) but
+    writes a map of results for each target such as:
+
+    ```hcl
+    # docker-bake.hcl
+    group "default" {
+      targets = ["db", "webapp-dev"]
+    }
+
+    target "db" {
+      dockerfile = "Dockerfile.db"
+      tags = ["docker.io/username/db"]
+    }
+
+    target "webapp-dev" {
+      dockerfile = "Dockerfile.webapp"
+      tags = ["docker.io/username/webapp"]
+    }
+    ```
+
+    ```console
+    $ docker buildx bake --load --metadata-file metadata.json .
+    $ cat metadata.json
+    ```
+
+    ```json
+    {
+      "buildx.build.warnings": {},
+      "db": {
+        "buildx.build.provenance": {},
+        "buildx.build.ref": "mybuilder/mybuilder0/0fjb6ubs52xx3vygf6fgdl611",
+        "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66",
+        "containerimage.descriptor": {
+          "annotations": {
+            "config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66",
+            "org.opencontainers.image.created": "2022-02-08T21:28:03Z"
+          },
+          "digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3",
+          "mediaType": "application/vnd.oci.image.manifest.v1+json",
+          "size": 506
+        },
+        "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"
+      },
+      "webapp-dev": {
+        "buildx.build.provenance": {},
+        "buildx.build.ref": "mybuilder/mybuilder0/kamngmcgyzebqxwu98b4lfv3n",
+        "containerimage.config.digest": "sha256:9651cc2b3c508f697c9c43b67b64c8359c2865c019e680aac1c11f4b875b67e0",
+        "containerimage.descriptor": {
+          "annotations": {
+            "config.digest": "sha256:9651cc2b3c508f697c9c43b67b64c8359c2865c019e680aac1c11f4b875b67e0",
+            "org.opencontainers.image.created": "2022-02-08T21:28:15Z"
+          },
+          "digest": "sha256:6d9ac9237a84afe1516540f40a0fafdc86859b2141954b4d643af7066d598b74",
+          "mediaType": "application/vnd.oci.image.manifest.v1+json",
+          "size": 506
+        },
+        "containerimage.digest": "sha256:6d9ac9237a84afe1516540f40a0fafdc86859b2141954b4d643af7066d598b74"
+      }
+    }
+    ```
+
+    > [!NOTE]
+    > Build record [provenance](/build/metadata/attestations/slsa-provenance/#provenance-attestation-example)
+    > (`buildx.build.provenance`) includes minimal provenance by default. Set the
+    > `BUILDX_METADATA_PROVENANCE` environment variable to customize this behavior:
+    > * `min` sets minimal provenance (default).
+    > * `max` sets full provenance.
+    > * `disabled`, `false` or `0` does not set any provenance.
+
+    > [!NOTE]
+    > Build warnings (`buildx.build.warnings`) are not included by default. Set the
+    > `BUILDX_METADATA_WARNINGS` environment variable to `1` or `true` to
+    > include them.
+
+    ### Don't use cache when building the image (--no-cache) {#no-cache}
+
+    Same as `build --no-cache`. Don't use cache when building the image.
+
+    ### Print the options without building (--print) {#print}
+
+    Prints the resulting options of the targets desired to be built, in a JSON
+    format, without starting a build.
+
+    ```console
+    $ docker buildx bake -f docker-bake.hcl --print db
+    {
+      "group": {
+        "default": {
+          "targets": [
+            "db"
+          ]
+        }
+      },
+      "target": {
+        "db": {
+          "context": "./",
+          "dockerfile": "Dockerfile",
+          "tags": [
+            "docker.io/tiborvass/db"
+          ]
+        }
+      }
+    }
+    ```
+
+    ### Set type of progress output (--progress) {#progress}
+
+    Same as [`build --progress`](/reference/cli/docker/buildx/build/#progress).
+
+    ### Create provenance attestations (--provenance) {#provenance}
+
+    Same as [`build --provenance`](/reference/cli/docker/buildx/build/#provenance).
+
+    ### Always attempt to pull a newer version of the image (--pull) {#pull}
+
+    Same as `build --pull`.
+
+    ### Push images to a registry (--push) {#push}
+
+    The `--push` flag follows the same logic as `--load`:
+
+    - If no outputs are defined, it adds a `type=image,push=true` export.
+    - For existing `image` outputs, it sets `push=true`.
+    - If outputs are set to `local` or `tar`, it does not override them.
+
+    ### Create SBOM attestations (--sbom) {#sbom}
+
+    Same as [`build --sbom`](/reference/cli/docker/buildx/build/#sbom).
+
+    ### Override target configurations from command line (--set) {#set}
+
+    ```
+    --set targetpattern.key[.subkey]=value
+    ```
+
+    Override target configurations from command line. The pattern matching syntax
+    is defined in https://golang.org/pkg/path/#Match.
+
+    ```console
+    $ docker buildx bake --set target.args.mybuildarg=value
+    $ docker buildx bake --set target.platform=linux/arm64
+    $ docker buildx bake --set foo*.args.mybuildarg=value   # overrides build arg for all targets starting with 'foo'
+    $ docker buildx bake --set *.platform=linux/arm64       # overrides platform for all targets
+    $ docker buildx bake --set foo*.no-cache                # bypass caching only for targets starting with 'foo'
+    $ docker buildx bake --set target.platform+=linux/arm64 # appends 'linux/arm64' to the platform list
+    $ docker buildx bake --set target.contexts.bar=../bar   # overrides 'bar' named context
+    $ docker buildx bake --set target.resources.memory=2g   # overrides memory resource limit
+    $ docker buildx bake --set target.secret.aws=env=AWS    # overrides source for an existing secret
+    ```
+
+    > [!NOTE]
+    >
+    > `--set` is a repeatable flag. For array fields such as `tags`, repeat `--set`
+    > to provide multiple values or use the `+=` operator to append without
+    > replacing. Array literal syntax like `--set target.tags=[a,b]` is not
+    > supported.
+
+    You can override the following fields:
+
+    * `annotations`
+    * `attest`
+    * `args`
+    * `cache-from`
+    * `cache-to`
+    * `call`
+    * `context`
+    * `contexts`
+    * `dockerfile`
+    * `entitlements`
+    * `extra-hosts`
+    * `labels`
+    * `load`
+    * `no-cache`
+    * `no-cache-filter`
+    * `output`
+    * `platform`
+    * `pull`
+    * `push`
+    * `resources`
+    * `secret.<id>`
+    * `secrets`
+    * `ssh`
+    * `tags`
+    * `target`
+
+    You can append using `+=` operator for the following fields:
+
+    * `annotations`¹
+    * `attest`¹
+    * `cache-from`
+    * `cache-to`
+    * `entitlements`¹
+    * `no-cache-filter`
+    * `output`
+    * `platform`
+    * `secrets`
+    * `ssh`
+    * `tags`
+
+    > [!NOTE]
+    > ¹ These fields already append by default.
+
+    #### Inline values for composable attributes
+
+    Some fields, such as `ssh`, `secret`, `output`, `cache-to`, `cache-from`,
+    `attest`, and `annotations`, are composable attributes that accept a list of
+    object values in a Bake file. When you override these fields with `--set`, you
+    provide each value using the same inline string syntax as the corresponding
+    build flag, not the HCL object form. The `--set` override replaces or appends
+    to the list as a whole; it doesn't address individual sub-fields with a
+    sub-selector. Only the map-valued fields `args`, `contexts`, `labels`, and
+    `extra-hosts` support targeting a specific entry with a sub-key (for example
+    `--set target.args.MYARG=value`).
+
+    For example, to set the SSH agent socket or key for a target, use the same
+    `id=path` form accepted by [`build --ssh`](/reference/cli/docker/buildx/build/#ssh):
+
+    ```console
+    $ docker buildx bake --set "*.ssh=default=$HOME/.ssh/id_ed25519"
+    ```
+
+    To expose multiple paths for the same `id`, separate them with commas in the
+    second part:
+
+    ```console
+    $ docker buildx bake --set "*.ssh=default=$HOME/.ssh/id_ed25519,$HOME/.ssh/id_rsa"
+    ```
+
+    Your shell expands `$HOME` before buildx sees the value. The equivalent Bake
+    file definition uses the
+    [`homedir`](/build/bake/stdlib/#homedir) HCL function:
+
+    ```hcl
+    target "default" {
+      ssh = [{ id = "default", paths = ["${homedir()}/.ssh/id_ed25519", "${homedir()}/.ssh/id_rsa"] }]
+    }
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/buildx/docker_buildx_build.yaml b/data/cli/buildx/docker_buildx_build.yaml
similarity index 88%
rename from data/buildx/docker_buildx_build.yaml
rename to data/cli/buildx/docker_buildx_build.yaml
index 57a0d8cbfeac..650ddb52a978 100644
--- a/data/buildx/docker_buildx_build.yaml
+++ b/data/cli/buildx/docker_buildx_build.yaml
@@ -21,7 +21,7 @@ options:
       value_type: stringArray
       default_value: '[]'
       description: |
-        Allow extra privileged entitlement (e.g., `network.host`, `security.insecure`)
+        Allow extra privileged entitlement (e.g., `network.host`, `security.insecure`, `device`, `buildx.local.delete`)
       details_url: '#allow'
       deprecated: false
       hidden: false
@@ -139,8 +139,7 @@ options:
       kubernetes: false
       swarm: false
     - option: cpu-period
-      value_type: int64
-      default_value: "0"
+      value_type: string
       description: Limit the CPU CFS (Completely Fair Scheduler) period
       deprecated: false
       hidden: true
@@ -149,8 +148,7 @@ options:
       kubernetes: false
       swarm: false
     - option: cpu-quota
-      value_type: int64
-      default_value: "0"
+      value_type: string
       description: Limit the CPU CFS (Completely Fair Scheduler) quota
       deprecated: false
       hidden: true
@@ -160,8 +158,7 @@ options:
       swarm: false
     - option: cpu-shares
       shorthand: c
-      value_type: int64
-      default_value: "0"
+      value_type: string
       description: CPU shares (relative weight)
       deprecated: false
       hidden: true
@@ -187,16 +184,6 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
-    - option: detach
-      value_type: bool
-      default_value: "false"
-      description: Detach buildx server (supported only on linux)
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: true
-      kubernetes: false
-      swarm: false
     - option: file
       shorthand: f
       value_type: string
@@ -342,6 +329,17 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: policy
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Policy configuration (format: `filename=path[,filename=path][,reset=true|false][,disabled=true|false][,strict=true|false][,log-level=level]`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: print
       value_type: string
       description: Print result of information request (e.g., outline, targets)
@@ -355,7 +353,7 @@ options:
       value_type: string
       default_value: auto
       description: |
-        Set type of progress output (`auto`, `quiet`, `plain`, `tty`, `rawjson`). Use plain to show container output
+        Set type of progress output (`auto`, `none`,  `plain`, `quiet`, `rawjson`, `tty`). Use plain to show container output
       details_url: '#progress'
       deprecated: false
       hidden: false
@@ -386,7 +384,7 @@ options:
     - option: push
       value_type: bool
       default_value: "false"
-      description: Shorthand for `--output=type=registry`
+      description: Shorthand for `--output=type=registry,unpack=false`
       details_url: '#push'
       deprecated: false
       hidden: false
@@ -405,6 +403,18 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: resource
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Resource limits for build containers (format: `memory=2g`, `cpu-quota=50000`)
+      details_url: '#resource'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: rm
       value_type: bool
       default_value: "true"
@@ -415,15 +425,6 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
-    - option: root
-      value_type: string
-      description: Specify root directory of server to connect
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: true
-      kubernetes: false
-      swarm: false
     - option: sbom
       value_type: string
       description: Shorthand for `--attest=type=sbom`
@@ -456,16 +457,6 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
-    - option: server-config
-      value_type: string
-      description: |
-        Specify buildx server config file (used only when launching new server)
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: true
-      kubernetes: false
-      swarm: false
     - option: shm-size
       value_type: bytes
       default_value: "0"
@@ -503,7 +494,7 @@ options:
       shorthand: t
       value_type: stringArray
       default_value: '[]'
-      description: 'Name and optionally a tag (format: `name:tag`)'
+      description: 'Image identifier (format: `[registry/]repository[:tag]`)'
       details_url: '#tag'
       deprecated: false
       hidden: false
@@ -665,9 +656,18 @@ examples: |-
     - `network.host` - Allows executions with host networking.
     - `security.insecure` - Allows executions without sandbox. See
       [related Dockerfile extensions](/reference/dockerfile/#run---security).
-
-    For entitlements to be enabled, the BuildKit daemon also needs to allow them
-    with `--allow-insecure-entitlement` (see [`create --buildkitd-flags`](/reference/cli/docker/buildx/create/#buildkitd-flags)).
+    - `device` - Allows access to Container Device Interface (CDI) devices.
+       - `--allow device` - Grants access to all devices.
+       - `--allow device=kind|name` - Grants access to a specific device.
+       - `--allow device=kind|name,alias=kind|name` - Grants access to a specific device, with optional aliasing.
+    - `buildx.local.delete` - Allows local outputs using `mode=delete` to delete
+      stale destination files when the destination is the current working directory
+      or outside it.
+
+    For BuildKit entitlements to be enabled, the BuildKit daemon also needs to allow
+    them with `--allow-insecure-entitlement` (see [`create --buildkitd-flags`](/reference/cli/docker/buildx/create/#buildkitd-flags)).
+    The `buildx.local.delete` entitlement is checked by Buildx and isn't sent to the
+    BuildKit daemon.
 
     ```console
     $ docker buildx create --use --name insecure-builder --buildkitd-flags '--allow-insecure-entitlement security.insecure'
@@ -729,16 +729,23 @@ examples: |-
     --build-context=name=VALUE
     ```
 
-    Define additional build context with specified contents. In Dockerfile the context can be accessed when `FROM name` or `--from=name` is used.
-    When Dockerfile defines a stage with the same name it is overwritten.
+    Define additional build context with specified contents.
 
-    The value can be a local source directory, [local OCI layout compliant directory](https://github.com/opencontainers/image-spec/blob/main/image-layout.md), container image (with docker-image:// prefix), Git or HTTP URL.
+    In a Dockerfile:
 
-    Replace `alpine:latest` with a pinned one:
+    - the context can be accessed when `FROM name` or `--from=name` is used
+    - the context overrides a stage called `name` when used as `FROM ... AS name`
+    - the context overrides a `#syntax` directive when used as `#syntax=name`
 
-    ```console
-    $ docker buildx build --build-context alpine=docker-image://alpine@sha256:0123456789 .
-    ```
+    The value can be a:
+
+    - local source directory
+    - [local OCI layout compliant directory](https://github.com/opencontainers/image-spec/blob/main/image-layout.md)
+    - container image
+    - Git URL
+    - HTTP URL
+
+    #### Use a local path {#local-path}
 
     Expose a secondary local source directory:
 
@@ -747,6 +754,16 @@ examples: |-
     # docker buildx build --build-context project=https://github.com/myuser/project.git .
     ```
 
+    #### Use a container image {#docker-image}
+
+    Use the `docker-image://` scheme.
+
+    Replace `alpine:latest` with a pinned one:
+
+    ```console
+    $ docker buildx build --build-context alpine=docker-image://alpine@sha256:0123456789 .
+    ```
+
     ```dockerfile
     # syntax=docker/dockerfile:1
     FROM alpine
@@ -755,7 +772,10 @@ examples: |-
 
     #### Use an OCI layout directory as build context {#source-oci-layout}
 
-    Source an image from a local [OCI layout compliant directory](https://github.com/opencontainers/image-spec/blob/main/image-layout.md),
+    Use the `oci-layout:///` scheme.
+
+    Source an image from a local
+    [OCI layout compliant directory](https://github.com/opencontainers/image-spec/blob/main/image-layout.md),
     either by tag, or by digest:
 
     ```console
@@ -773,7 +793,6 @@ examples: |-
     ```
 
     The OCI layout directory must be compliant with the [OCI layout specification](https://github.com/opencontainers/image-spec/blob/main/image-layout.md).
-    You can reference an image in the layout using either tags, or the exact digest.
 
     ### Override the configured builder instance (--builder) {#builder}
 
@@ -785,25 +804,25 @@ examples: |-
     --cache-from=[NAME|type=TYPE[,KEY=VALUE]]
     ```
 
-    Use an external cache source for a build. Supported types are `registry`,
-    `local`, `gha` and `s3`.
+    Use an external cache source for a build. Supported types are:
 
-    - [`registry` source](https://github.com/moby/buildkit#registry-push-image-and-cache-separately)
+    - [`registry`](/build/cache/backends/registry/)
       can import cache from a cache manifest or (special) image configuration on the
       registry.
-    - [`local` source](https://github.com/moby/buildkit#local-directory-1) can
+    - [`local`](/build/cache/backends/local/) can
       import cache from local files previously exported with `--cache-to`.
-    - [`gha` source](https://github.com/moby/buildkit#github-actions-cache-experimental)
+    - [`gha`](/build/cache/backends/gha/)
       can import cache from a previously exported cache with `--cache-to` in your
-      GitHub repository
-    - [`s3` source](https://github.com/moby/buildkit#s3-cache-experimental)
+      GitHub repository.
+    - [`s3`](/build/cache/backends/s3/)
       can import cache from a previously exported cache with `--cache-to` in your
-      S3 bucket
+      S3 bucket.
+    - [`azblob`](/build/cache/backends/azblob/)
+      can import cache from a previously exported cache with `--cache-to` in your
+      Azure bucket.
 
     If no type is specified, `registry` exporter is used with a specified reference.
 
-    `docker` driver currently only supports importing build cache from the registry.
-
     ```console
     $ docker buildx build --cache-from=user/app:cache .
     $ docker buildx build --cache-from=user/app .
@@ -813,7 +832,43 @@ examples: |-
     $ docker buildx build --cache-from=type=s3,region=eu-west-1,bucket=mybucket .
     ```
 
-    More info about cache exporters and available attributes: https://github.com/moby/buildkit#export-cache
+    > [!NOTE]
+    > More info about cache exporters and available attributes can be found in the
+    > [Cache storage backends documentation](/build/cache/backends/)
+
+    ### Export build cache to an external cache destination (--cache-to) {#cache-to}
+
+    ```text
+    --cache-to=[NAME|type=TYPE[,KEY=VALUE]]
+    ```
+
+    Export build cache to an external cache destination. Supported types are:
+
+    - [`registry`](/build/cache/backends/registry/) exports
+      build cache to a cache manifest in the registry.
+    - [`local`](/build/cache/backends/local/) exports
+      cache to a local directory on the client.
+    - [`inline`](/build/cache/backends/inline/) writes the
+      cache metadata into the image configuration.
+    - [`gha`](/build/cache/backends/gha/) exports cache
+      through the GitHub Actions Cache service API.
+    - [`s3`](/build/cache/backends/s3/) exports cache to a
+      S3 bucket.
+    - [`azblob`](/build/cache/backends/azblob/) exports
+      cache to an Azure bucket.
+
+    ```console
+    $ docker buildx build --cache-to=user/app:cache .
+    $ docker buildx build --cache-to=type=inline .
+    $ docker buildx build --cache-to=type=registry,ref=user/app .
+    $ docker buildx build --cache-to=type=local,dest=path/to/cache .
+    $ docker buildx build --cache-to=type=gha .
+    $ docker buildx build --cache-to=type=s3,region=eu-west-1,bucket=mybucket .
+    ```
+
+    > [!NOTE]
+    > More info about cache exporters and available attributes can be found in the
+    > [Cache storage backends documentation](/build/cache/backends/)
 
     ### Invoke a frontend method (--call) {#call}
 
@@ -976,61 +1031,46 @@ examples: |-
     release (default) is an empty scratch image with only compiled assets
     ```
 
-    ### Export build cache to an external cache destination (--cache-to) {#cache-to}
+    ### Use a custom parent cgroup (--cgroup-parent) {#cgroup-parent}
 
-    ```text
-    --cache-to=[NAME|type=TYPE[,KEY=VALUE]]
+    When you run `docker buildx build` with the `--cgroup-parent` option,
+    the daemon runs the containers used in the build with the
+    [corresponding `docker run` flag](/reference/cli/docker/container/run/#cgroup-parent).
+
+    ### Specify a Dockerfile (-f, --file) {#file}
+
+    ```console
+    $ docker buildx build -f [PATH|URL|-] .
     ```
 
-    Export build cache to an external cache destination. Supported types are
-    `registry`, `local`, `inline`, `gha` and `s3`.
+    Specifies the location of the Dockerfile to use.
+    If unspecified, a file named `Dockerfile` at the root of the build context is used by default.
 
-    - [`registry` type](https://github.com/moby/buildkit#registry-push-image-and-cache-separately) exports build cache to a cache manifest in the registry.
-    - [`local` type](https://github.com/moby/buildkit#local-directory-1) exports
-      cache to a local directory on the client.
-    - [`inline` type](https://github.com/moby/buildkit#inline-push-image-and-cache-together)
-      writes the cache metadata into the image configuration.
-    - [`gha` type](https://github.com/moby/buildkit#github-actions-cache-experimental)
-      exports cache through the [GitHub Actions Cache service API](https://github.com/tonistiigi/go-actions-cache/blob/master/api.md#authentication).
-    - [`s3` type](https://github.com/moby/buildkit#s3-cache-experimental) exports
-      cache to a S3 bucket.
+    The supported inputs formats are:
 
-    The `docker` driver only supports cache exports using the `inline` and `local`
-    cache backends.
+    - [`Local file path`](#local-file-path)
+    - [`Remote URL`](#remote-url)
+    - [`Standard input`](#standard-input)
 
-    Attribute key:
+    #### Local file path
 
-    - `mode` - Specifies how many layers are exported with the cache. `min` on only
-      exports layers already in the final build stage, `max` exports layers for
-      all stages. Metadata is always exported for the whole build.
+    To specify a path to a local Dockerfile:
 
     ```console
-    $ docker buildx build --cache-to=user/app:cache .
-    $ docker buildx build --cache-to=type=inline .
-    $ docker buildx build --cache-to=type=registry,ref=user/app .
-    $ docker buildx build --cache-to=type=local,dest=path/to/cache .
-    $ docker buildx build --cache-to=type=gha .
-    $ docker buildx build --cache-to=type=s3,region=eu-west-1,bucket=mybucket .
+    $ docker buildx build -f path/to/Dockerfile .
     ```
 
-    More info about cache exporters and available attributes: https://github.com/moby/buildkit#export-cache
+    #### Remote URL
 
-    ### Use a custom parent cgroup (--cgroup-parent) {#cgroup-parent}
-
-    When you run `docker buildx build` with the `--cgroup-parent` option,
-    the daemon runs the containers used in the build with the
-    [corresponding `docker run` flag](/reference/cli/docker/container/run/#cgroup-parent).
-
-    ### Specify a Dockerfile (-f, --file) {#file}
+    To specify a URL to a remote Dockerfile:
 
     ```console
-    $ docker buildx build -f <filepath> .
+    $ docker buildx build -f https://raw.githubusercontent.com/docker/buildx/refs/tags/v0.29.0/Dockerfile .
     ```
 
-    Specifies the filepath of the Dockerfile to use.
-    If unspecified, a file named `Dockerfile` at the root of the build context is used by default.
+    #### Standard input
 
-    To read a Dockerfile from stdin, you can use `-` as the argument for `--file`.
+    To read a Dockerfile from stdin, use `-` as the argument:
 
     ```console
     $ cat Dockerfile | docker buildx build -f - .
@@ -1199,6 +1239,11 @@ examples: |-
     Attribute key:
 
     - `dest` - destination directory where files will be written
+    - `mode` - write mode, either `copy` or `delete`. The default is `copy`.
+      `delete` removes stale files from the destination after exporting the build
+      result. It can be used without `--allow` when `dest` resolves to a
+      subdirectory of the current working directory. If `dest` is the current working
+      directory or resolves outside it, pass `--allow=buildx.local.delete`.
 
     For more information, see
     [Local and tar exporters](/build/exporters/local-tar/).
@@ -1605,6 +1650,43 @@ examples: |-
     > In most cases, it is recommended to let the builder automatically determine
     > the appropriate configurations. Manual adjustments should only be considered
     > when specific performance tuning is required for complex build scenarios.
+
+    ### Set CPU and memory limits for build containers (--resource) {#resource}
+
+    The `--resource` flag constrains the resources available to the containers that
+    run your `RUN` instructions during the build. It's repeatable and takes
+    `key=value` pairs, where `key` is one of:
+
+    | Key           | Description                                                                  |
+    |:--------------|:-----------------------------------------------------------------------------|
+    | `memory`      | Memory limit (format: `<number><unit>`, e.g. `512m`, `2g`).                  |
+    | `memory-swap` | Total memory plus swap limit. Set to `-1` to allow unlimited swap.           |
+    | `cpu-shares`  | CPU shares (relative weight).                                                |
+    | `cpu-period`  | Length of a CPU CFS (Completely Fair Scheduler) period, in microseconds.     |
+    | `cpu-quota`   | CPU CFS quota, in microseconds, within each `cpu-period`.                    |
+    | `cpuset-cpus` | CPUs in which to allow execution (`0-3`, `0,1`).                             |
+    | `cpuset-mems` | Memory nodes (MEMs) in which to allow execution (`0-3`, `0,1`).              |
+
+    ```console
+    $ docker buildx build --resource memory=2g --resource cpu-quota=50000 --resource cpu-period=100000 .
+    ```
+
+    These map to the cgroup resource limits of the legacy `docker build` API and
+    only apply to individual build steps. They don't affect the build cache key.
+
+    > [!NOTE]
+    > These limits require a BuildKit daemon that supports per-step resource limits
+    > (the `exec.meta.linux.resources` capability) and only take effect on Linux.
+
+    > [!NOTE]
+    > Because BuildKit can run build steps in parallel, these limits apply to each
+    > step in isolation rather than to the build as a whole. When the same step is
+    > requested with different limits, the most relaxed limits are used.
+
+    > [!NOTE]
+    > In most cases, it is recommended to let the builder automatically determine
+    > the appropriate configurations. Manual adjustments should only be considered
+    > when specific performance tuning is required for complex build scenarios.
 deprecated: false
 hidden: false
 experimental: false
diff --git a/data/buildx/docker_buildx_create.yaml b/data/cli/buildx/docker_buildx_create.yaml
similarity index 93%
rename from data/buildx/docker_buildx_create.yaml
rename to data/cli/buildx/docker_buildx_create.yaml
index c94e26f8b298..c2ada008bd70 100644
--- a/data/buildx/docker_buildx_create.yaml
+++ b/data/cli/buildx/docker_buildx_create.yaml
@@ -136,6 +136,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: timeout
+      value_type: duration
+      default_value: 20s
+      description: Override the default timeout for loading builder status
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: use
       value_type: bool
       default_value: "false"
@@ -290,6 +300,18 @@ examples: |-
     * [`kubernetes` driver](/build/builders/drivers/kubernetes/)
     * [`remote` driver](/build/builders/drivers/remote/)
 
+    With `BUILDX_DEFAULT_POLICY=1`, the `docker-container` driver verifies signed
+    `moby/buildkit` builder image tags before creating the builder. To explicitly
+    bypass this verification, set `allow-untrusted-image=true`. For example:
+
+    ```console
+    $ BUILDX_DEFAULT_POLICY=1 docker buildx create --driver docker-container \
+        --driver-opt allow-untrusted-image=true
+    ```
+
+    Only use this option for an image that you trust. It disables builder image
+    verification for the new builder node.
+
     ### Remove a node from a builder (--leave) {#leave}
 
     The `--leave` flag changes the action of the command to remove a node from a
diff --git a/data/cli/buildx/docker_buildx_dap.yaml b/data/cli/buildx/docker_buildx_dap.yaml
new file mode 100644
index 000000000000..f9c25d12cc69
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_dap.yaml
@@ -0,0 +1,37 @@
+command: docker buildx dap
+short: Start debug adapter protocol compatible debugger
+long: Start debug adapter protocol compatible debugger
+pname: docker buildx
+plink: docker_buildx.yaml
+cname:
+    - docker buildx dap build
+clink:
+    - docker_buildx_dap_build.yaml
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_dap_attach.yaml b/data/cli/buildx/docker_buildx_dap_attach.yaml
new file mode 100644
index 000000000000..d80dbbb746c9
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_dap_attach.yaml
@@ -0,0 +1,34 @@
+command: docker buildx dap attach
+short: Attach to a container created by the dap evaluate request
+long: Attach to a container created by the dap evaluate request
+usage: docker buildx dap attach PATH
+pname: docker buildx dap
+plink: docker_buildx_dap.yaml
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: true
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_dap_build.yaml b/data/cli/buildx/docker_buildx_dap_build.yaml
new file mode 100644
index 000000000000..21050c9dac06
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_dap_build.yaml
@@ -0,0 +1,560 @@
+command: docker buildx dap build
+short: Start a build
+long: |-
+    Start a debug session using the [debug adapter protocol](https://microsoft.github.io/debug-adapter-protocol/overview) to communicate with the debugger UI.
+
+    Arguments are the same as the `build`
+
+    > [!NOTE]
+    > `buildx dap build` command may receive backwards incompatible features in the future
+    > if needed. We are looking for feedback on improving the command and extending
+    > the functionality further.
+usage: docker buildx dap build [OPTIONS] PATH | URL | -
+pname: docker buildx dap
+plink: docker_buildx_dap.yaml
+options:
+    - option: add-host
+      value_type: stringSlice
+      default_value: '[]'
+      description: 'Add a custom host-to-IP mapping (format: `host:ip`)'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: allow
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Allow extra privileged entitlement (e.g., `network.host`, `security.insecure`, `device`, `buildx.local.delete`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: annotation
+      value_type: stringArray
+      default_value: '[]'
+      description: Add annotation to the image
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: attest
+      value_type: stringArray
+      default_value: '[]'
+      description: 'Attestation parameters (format: `type=sbom,generator=image`)'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: build-arg
+      value_type: stringArray
+      default_value: '[]'
+      description: Set build-time variables
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: build-context
+      value_type: stringArray
+      default_value: '[]'
+      description: Additional build contexts (e.g., name=path)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: cache-from
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        External cache sources (e.g., `user/app:cache`, `type=local,src=path/to/dir`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: cache-to
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Cache export destinations (e.g., `user/app:cache`, `type=local,dest=path/to/dir`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: call
+      value_type: string
+      default_value: build
+      description: Set method for evaluating build (`check`, `outline`, `targets`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: cgroup-parent
+      value_type: string
+      description: Set the parent cgroup for the `RUN` instructions during build
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: check
+      value_type: bool
+      description: Shorthand for `--call=check`
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: compress
+      value_type: bool
+      default_value: "false"
+      description: Compress the build context using gzip
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: cpu-period
+      value_type: string
+      description: Limit the CPU CFS (Completely Fair Scheduler) period
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: cpu-quota
+      value_type: string
+      description: Limit the CPU CFS (Completely Fair Scheduler) quota
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: cpu-shares
+      shorthand: c
+      value_type: string
+      description: CPU shares (relative weight)
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: cpuset-cpus
+      value_type: string
+      description: CPUs in which to allow execution (`0-3`, `0,1`)
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: cpuset-mems
+      value_type: string
+      description: MEMs in which to allow execution (`0-3`, `0,1`)
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: file
+      shorthand: f
+      value_type: string
+      description: 'Name of the Dockerfile (default: `PATH/Dockerfile`)'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: force-rm
+      value_type: bool
+      default_value: "false"
+      description: Always remove intermediate containers
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: iidfile
+      value_type: string
+      description: Write the image ID to a file
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: isolation
+      value_type: string
+      description: Container isolation technology
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: label
+      value_type: stringArray
+      default_value: '[]'
+      description: Set metadata for an image
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: load
+      value_type: bool
+      default_value: "false"
+      description: Shorthand for `--output=type=docker`
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: memory
+      shorthand: m
+      value_type: string
+      description: Memory limit
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: memory-swap
+      value_type: string
+      description: |
+        Swap limit equal to memory plus swap: `-1` to enable unlimited swap
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: metadata-file
+      value_type: string
+      description: Write build result metadata to a file
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: network
+      value_type: string
+      default_value: default
+      description: Set the networking mode for the `RUN` instructions during build
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: no-cache
+      value_type: bool
+      default_value: "false"
+      description: Do not use cache when building the image
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: no-cache-filter
+      value_type: stringArray
+      default_value: '[]'
+      description: Do not cache specified stages
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: output
+      shorthand: o
+      value_type: stringArray
+      default_value: '[]'
+      description: 'Output destination (format: `type=local,dest=path`)'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: platform
+      value_type: stringArray
+      default_value: '[]'
+      description: Set target platform for build
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Policy configuration (format: `filename=path[,filename=path][,reset=true|false][,disabled=true|false][,strict=true|false][,log-level=level]`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: print
+      value_type: string
+      description: Print result of information request (e.g., outline, targets)
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: true
+      kubernetes: false
+      swarm: false
+    - option: progress
+      value_type: string
+      default_value: auto
+      description: |
+        Set type of progress output (`auto`, `none`,  `plain`, `quiet`, `rawjson`, `tty`). Use plain to show container output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: provenance
+      value_type: string
+      description: Shorthand for `--attest=type=provenance`
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: pull
+      value_type: bool
+      default_value: "false"
+      description: Always attempt to pull all referenced images
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: push
+      value_type: bool
+      default_value: "false"
+      description: Shorthand for `--output=type=registry,unpack=false`
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: quiet
+      shorthand: q
+      value_type: bool
+      default_value: "false"
+      description: Suppress the build output and print image ID on success
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: resource
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Resource limits for build containers (format: `memory=2g`, `cpu-quota=50000`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: rm
+      value_type: bool
+      default_value: "true"
+      description: Remove intermediate containers after a successful build
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: sbom
+      value_type: string
+      description: Shorthand for `--attest=type=sbom`
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: secret
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Secret to expose to the build (format: `id=mysecret[,src=/local/secret]`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: security-opt
+      value_type: stringSlice
+      default_value: '[]'
+      description: Security options
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: shm-size
+      value_type: bytes
+      default_value: "0"
+      description: Shared memory size for build containers
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: squash
+      value_type: bool
+      default_value: "false"
+      description: Squash newly built layers into a single new layer
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: true
+      kubernetes: false
+      swarm: false
+    - option: ssh
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        SSH agent socket or keys to expose to the build (format: `default|<id>[=<socket>|<key>[,<key>]]`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tag
+      shorthand: t
+      value_type: stringArray
+      default_value: '[]'
+      description: 'Image identifier (format: `[registry/]repository[:tag]`)'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: target
+      value_type: string
+      description: Set the target build stage to build
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: ulimit
+      value_type: ulimit
+      default_value: '[]'
+      description: Ulimit options
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Launch request arguments {#launch-config}
+
+    The following [launch request arguments](https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Launch) are supported. These are sent as a JSON body as part of the launch request.
+
+    | Name                | Type          | Default      | Description                                                                  |
+    |:--------------------|:--------------|:-------------|:-----------------------------------------------------------------------------|
+    | `dockerfile`        | `string`      | `Dockerfile` | Name of the Dockerfile                                                       |
+    | `contextPath`       | `string`      | `.`          | Set the context path for the build (normally the first positional argument)  |
+    | `target`            | `string`      |              | Set the target build stage to build                                          |
+    | `stopOnEntry`       | `boolean`     | `false`      | Stop on the first instruction                                                |
+
+    ### Additional Arguments {#additional-args}
+
+    Command line arguments may be passed to the debug adapter the same way they would be passed to the normal build command and they will set the value.
+    Launch request arguments that are set will override command line arguments if they are present.
+
+    A debug extension should include an `args` and `builder` entry in the launch configuration. These will modify the arguments passed to the binary for the tool invocation.
+    `builder` will add `--builder <arg>` directly after the executable and `args` will append to the end of the tool invocation.
+    For example, a launch configuration in Visual Studio Code with the following:
+
+    ```json
+    {
+        "args": ["--build-arg", "FOO=AAA"]
+        "builder": ["mybuilder"]
+    }
+    ```
+
+    This should cause the debug adapter to be invoked as `docker buildx --builder mybuilder dap build --build-arg FOO=AAA`.
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_debug.yaml b/data/cli/buildx/docker_buildx_debug.yaml
new file mode 100644
index 000000000000..fd8647c3eca2
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_debug.yaml
@@ -0,0 +1,57 @@
+command: docker buildx debug
+short: Start debugger
+long: Start debugger
+pname: docker buildx
+plink: docker_buildx.yaml
+cname:
+    - docker buildx debug build
+clink:
+    - docker_buildx_debug_build.yaml
+options:
+    - option: invoke
+      value_type: string
+      description: Launch a monitor with executing specified command
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: true
+      kubernetes: false
+      swarm: false
+    - option: "on"
+      value_type: string
+      default_value: error
+      description: When to launch the monitor ([always, error])
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: true
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: true
+kubernetes: false
+swarm: false
+
diff --git a/data/buildx/docker_buildx_debug_build.yaml b/data/cli/buildx/docker_buildx_debug_build.yaml
similarity index 93%
rename from data/buildx/docker_buildx_debug_build.yaml
rename to data/cli/buildx/docker_buildx_debug_build.yaml
index e5e1b934a0ba..942cdaca3930 100644
--- a/data/buildx/docker_buildx_debug_build.yaml
+++ b/data/cli/buildx/docker_buildx_debug_build.yaml
@@ -20,7 +20,7 @@ options:
       value_type: stringArray
       default_value: '[]'
       description: |
-        Allow extra privileged entitlement (e.g., `network.host`, `security.insecure`)
+        Allow extra privileged entitlement (e.g., `network.host`, `security.insecure`, `device`, `buildx.local.delete`)
       deprecated: false
       hidden: false
       experimental: false
@@ -128,8 +128,7 @@ options:
       kubernetes: false
       swarm: false
     - option: cpu-period
-      value_type: int64
-      default_value: "0"
+      value_type: string
       description: Limit the CPU CFS (Completely Fair Scheduler) period
       deprecated: false
       hidden: true
@@ -138,8 +137,7 @@ options:
       kubernetes: false
       swarm: false
     - option: cpu-quota
-      value_type: int64
-      default_value: "0"
+      value_type: string
       description: Limit the CPU CFS (Completely Fair Scheduler) quota
       deprecated: false
       hidden: true
@@ -149,8 +147,7 @@ options:
       swarm: false
     - option: cpu-shares
       shorthand: c
-      value_type: int64
-      default_value: "0"
+      value_type: string
       description: CPU shares (relative weight)
       deprecated: false
       hidden: true
@@ -176,16 +173,6 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
-    - option: detach
-      value_type: bool
-      default_value: "false"
-      description: Detach buildx server (supported only on linux)
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: true
-      kubernetes: false
-      swarm: false
     - option: file
       shorthand: f
       value_type: string
@@ -324,6 +311,17 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: policy
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Policy configuration (format: `filename=path[,filename=path][,reset=true|false][,disabled=true|false][,strict=true|false][,log-level=level]`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: print
       value_type: string
       description: Print result of information request (e.g., outline, targets)
@@ -337,7 +335,7 @@ options:
       value_type: string
       default_value: auto
       description: |
-        Set type of progress output (`auto`, `quiet`, `plain`, `tty`, `rawjson`). Use plain to show container output
+        Set type of progress output (`auto`, `none`,  `plain`, `quiet`, `rawjson`, `tty`). Use plain to show container output
       deprecated: false
       hidden: false
       experimental: false
@@ -366,7 +364,7 @@ options:
     - option: push
       value_type: bool
       default_value: "false"
-      description: Shorthand for `--output=type=registry`
+      description: Shorthand for `--output=type=registry,unpack=false`
       deprecated: false
       hidden: false
       experimental: false
@@ -384,6 +382,17 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: resource
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Resource limits for build containers (format: `memory=2g`, `cpu-quota=50000`)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: rm
       value_type: bool
       default_value: "true"
@@ -394,15 +403,6 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
-    - option: root
-      value_type: string
-      description: Specify root directory of server to connect
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: true
-      kubernetes: false
-      swarm: false
     - option: sbom
       value_type: string
       description: Shorthand for `--attest=type=sbom`
@@ -433,16 +433,6 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
-    - option: server-config
-      value_type: string
-      description: |
-        Specify buildx server config file (used only when launching new server)
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: true
-      kubernetes: false
-      swarm: false
     - option: shm-size
       value_type: bytes
       default_value: "0"
@@ -478,7 +468,7 @@ options:
       shorthand: t
       value_type: stringArray
       default_value: '[]'
-      description: 'Name and optionally a tag (format: `name:tag`)'
+      description: 'Image identifier (format: `[registry/]repository[:tag]`)'
       deprecated: false
       hidden: false
       experimental: false
diff --git a/data/buildx/docker_buildx_dial-stdio.yaml b/data/cli/buildx/docker_buildx_dial-stdio.yaml
similarity index 82%
rename from data/buildx/docker_buildx_dial-stdio.yaml
rename to data/cli/buildx/docker_buildx_dial-stdio.yaml
index ca47c5afd741..c4a8d34e2600 100644
--- a/data/buildx/docker_buildx_dial-stdio.yaml
+++ b/data/cli/buildx/docker_buildx_dial-stdio.yaml
@@ -1,8 +1,10 @@
 command: docker buildx dial-stdio
 short: Proxy current stdio streams to builder instance
 long: |-
-    dial-stdio uses the stdin and stdout streams of the command to proxy to the configured builder instance.
-    It is not intended to be used by humans, but rather by other tools that want to interact with the builder instance via BuildKit API.
+    dial-stdio uses the stdin and stdout streams of the command to proxy to the
+    configured builder instance. It is not intended to be used by humans, but
+    rather by other tools that want to interact with the builder instance via
+    BuildKit API.
 usage: docker buildx dial-stdio
 pname: docker buildx
 plink: docker_buildx.yaml
@@ -18,9 +20,9 @@ options:
       swarm: false
     - option: progress
       value_type: string
-      default_value: quiet
+      default_value: none
       description: |
-        Set type of progress output (`auto`, `plain`, `tty`, `rawjson`). Use plain to show container output
+        Set type of progress output (`auto`, `plain`, `rawjson`, `tty`). Use plain to show container output
       deprecated: false
       hidden: false
       experimental: false
@@ -50,7 +52,7 @@ inherited_options:
       swarm: false
 examples: |-
     Example go program that uses the dial-stdio command wire up a buildkit client.
-    This is for example use only and may not be suitable for production use.
+    This is, for example, use only and may not be suitable for production use.
 
     ```go
     client.New(ctx, "", client.WithContextDialer(func(context.Context, string) (net.Conn, error) {
diff --git a/data/cli/buildx/docker_buildx_du.yaml b/data/cli/buildx/docker_buildx_du.yaml
new file mode 100644
index 000000000000..307fbc5b2665
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_du.yaml
@@ -0,0 +1,297 @@
+command: docker buildx du
+short: Disk usage
+long: Disk usage
+usage: docker buildx du
+pname: docker buildx
+plink: docker_buildx.yaml
+options:
+    - option: filter
+      value_type: filter
+      description: Provide filter values
+      details_url: '#filter'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: format
+      value_type: string
+      description: Format the output
+      details_url: '#format'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: timeout
+      value_type: duration
+      default_value: 20s
+      description: Override the default timeout for loading builder status
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose
+      value_type: bool
+      default_value: "false"
+      description: Shorthand for `--format=pretty`
+      details_url: '#verbose'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      details_url: '#builder'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Show disk usage
+
+    The `docker buildx du` command shows the disk usage for the currently selected
+    builder.
+
+    ```console
+    $ docker buildx du
+    ID                                RECLAIMABLE    SIZE          LAST ACCESSED
+    12wgll9os87pazzft8lt0yztp*        true           1.704GB       13 days ago
+    iupsv3it5ubh92aweb7c1wojc*        true           1.297GB       36 minutes ago
+    ek4ve8h4obyv5kld6vicmtqyn         true           811.7MB       13 days ago
+    isovrfnmkelzhtdx942w9vjcb*        true           811.7MB       13 days ago
+    0jty7mjrndi1yo7xkv1baralh         true           810.5MB       13 days ago
+    jyzkefmsysqiaakgwmjgxjpcz*        true           810.5MB       13 days ago
+    z8w1y95jn93gvj92jtaj6uhwk         true           318MB         2 weeks ago
+    rz2zgfcwlfxsxd7d41w2sz2tt         true           8.224kB*      43 hours ago
+    n5bkzpewmk2eiu6hn9tzx18jd         true           8.224kB*      43 hours ago
+    ao94g6vtbzdl6k5zgdmrmnwpt         true           8.224kB*      43 hours ago
+    2pyjep7njm0wh39vcingxb97i         true           8.224kB*      43 hours ago
+    Shared:        115.5MB
+    Private:       10.25GB
+    Reclaimable:   10.36GB
+    Total:         10.36GB
+    ```
+
+    If `RECLAIMABLE` is false, the `docker buildx du prune` command won't delete
+    the record, even if you use `--all`. That's because the record is actively in
+    use by some component of the builder.
+
+    The asterisks (\*) in the default output format indicate the following:
+
+    - An asterisk next to an ID (`zu7m6evdpebh5h8kfkpw9dlf2*`) indicates that the record
+      is mutable. The size of the record may change, or another build can take ownership of
+      it and change or commit to it. If you run the `du` command again, this item may
+      not be there anymore, or the size might be different.
+    - An asterisk next to a size (`8.288kB*`) indicates that the record is shared.
+      Storage of the record is shared with some other resource, typically an image.
+      If you prune such a record then you will lose build cache but only metadata
+      will be deleted as the image still needs to actual storage layers.
+
+    ### Provide filter values (--filter) {#filter}
+
+    Same as [`buildx prune --filter`](/reference/cli/docker/buildx/prune/#filter).
+
+    ### Format the output (--format) {#format}
+
+    The formatting options (`--format`) pretty-prints usage information output
+    using a Go template.
+
+    Valid placeholders for the Go template are:
+
+    * `.ID`
+    * `.Parents`
+    * `.CreatedAt`
+    * `.Mutable`
+    * `.Reclaimable`
+    * `.Shared`
+    * `.Size`
+    * `.Description`
+    * `.UsageCount`
+    * `.LastUsedAt`
+    * `.Type`
+
+    When using the `--format` option, the `du` command will either output the data
+    exactly as the template declares or, when using the `table` directive, includes
+    column headers as well.
+
+    The `pretty` format is useful for inspecting the disk usage records in more
+    detail. It shows the mutable and shared states more clearly, as well as
+    additional information about the corresponding layer:
+
+    ```console
+    $ docker buildx du --format=pretty
+    ...
+    ID:           6wqu0v6hjdwvhh8yjozrepaof
+    Parents:
+     - bqx15bcewecz4wcg14b7iodvp
+    Created at:   2025-06-12 15:44:02.715795569 +0000 UTC
+    Mutable:      false
+    Reclaimable:  true
+    Shared:       true
+    Size:         1.653GB
+    Description:  [build-base 4/4] COPY . .
+    Usage count:  1
+    Last used:    2 months ago
+    Type:         regular
+
+    Shared:         35.57GB
+    Private:        97.94GB
+    Reclaimable:    131.5GB
+    Total:          133.5GB
+    ```
+
+    The following example uses a template without headers and outputs the
+    `ID` and `Size` entries separated by a colon (`:`):
+
+    ```console
+    $ docker buildx du --format "{{.ID}}: {{.Size}}"
+    6wqu0v6hjdwvhh8yjozrepaof: 1.653GB
+    4m8061kctvjyh9qleus8rgpgx: 1.723GB
+    fcm9mlz2641u8r5eicjqdhy1l: 1.841GB
+    z2qu1swvo3afzd9mhihi3l5k0: 1.873GB
+    nmi6asc00aa3ja6xnt6o7wbrr: 2.027GB
+    0qlam41jxqsq6i27yqllgxed3: 2.495GB
+    3w9qhzzskq5jc262snfu90bfz: 2.617GB
+    ```
+
+    The following example uses a `table` template and outputs the `ID` and
+    `Description`:
+
+    ```console
+    $ docker buildx du --format "table {{.ID}}    {{.Description}}"
+    ID                           DESCRIPTION
+    03bbhchaib8cygqs68um6hfnl    [binaries-linux 2/5] LINK COPY --link --from=binfmt-filter /out/ /
+    2h8un0tyg57oj64xvbas6mzea    [cni-plugins-export 2/4] LINK COPY --link --from=cni-plugins /opt/cni/bin/loopback /buildkit-cni-loopback
+    evckox33t07ob9dmollhn4h4j    [cni-plugins-export 3/4] LINK COPY --link --from=cni-plugins /opt/cni/bin/host-local /buildkit-cni-host-local
+    jlxzwcw6xaomxj8irerow9bhb    [binaries-linux 4/5] LINK COPY --link --from=buildctl /usr/bin/buildctl /
+    ov2oetgebkhpsw39rv1sbh5w1    [buildkit-linux 1/1] LINK COPY --link --from=binaries / /usr/bin/
+    ruoczhyq25n5v9ld7n231zalx    [binaries-linux 3/5] LINK COPY --link --from=cni-plugins-export-squashed / /
+    ax7cov6kizxi9ufvcwsef4occ*   local source for context
+    ```
+
+    JSON output is also supported and will print as newline delimited JSON:
+
+    ```console
+    $ docker buildx du --format=json
+    {"CreatedAt":"2025-07-29T12:36:01Z","Description":"pulled from docker.io/library/rust:1.85.1-bookworm@sha256:e51d0265072d2d9d5d320f6a44dde6b9ef13653b035098febd68cce8fa7c0bc4","ID":"ic1gfidvev5nciupzz53alel4","LastUsedAt":"2025-07-29T12:36:01Z","Mutable":false,"Parents":["hmpdhm4sjrfpmae4xm2y3m0ra"],"Reclaimable":true,"Shared":false,"Size":"829889526","Type":"regular","UsageCount":1}
+    {"CreatedAt":"2025-08-05T09:24:09Z","Description":"pulled from docker.io/library/node:22@sha256:3218f0d1b9e4b63def322e9ae362d581fbeac1ef21b51fc502ef91386667ce92","ID":"jsw7fx09l5zsda3bri1z4mwk5","LastUsedAt":"2025-08-05T09:24:09Z","Mutable":false,"Parents":["098jsj5ebbv1w47ikqigeuurs"],"Reclaimable":true,"Shared":true,"Size":"829898832","Type":"regular","UsageCount":1}
+    ```
+
+    You can use `jq` to pretty-print the JSON output:
+
+    ```console
+    $ docker buildx du --format=json | jq .
+    {
+      "CreatedAt": "2025-07-29T12:36:01Z",
+      "Description": "pulled from docker.io/library/rust:1.85.1-bookworm@sha256:e51d0265072d2d9d5d320f6a44dde6b9ef13653b035098febd68cce8fa7c0bc4",
+      "ID": "ic1gfidvev5nciupzz53alel4",
+      "LastUsedAt": "2025-07-29T12:36:01Z",
+      "Mutable": false,
+      "Parents": [
+        "hmpdhm4sjrfpmae4xm2y3m0ra"
+      ],
+      "Reclaimable": true,
+      "Shared": false,
+      "Size": "829889526",
+      "Type": "regular",
+      "UsageCount": 1
+    }
+    {
+      "CreatedAt": "2025-08-05T09:24:09Z",
+      "Description": "pulled from docker.io/library/node:22@sha256:3218f0d1b9e4b63def322e9ae362d581fbeac1ef21b51fc502ef91386667ce92",
+      "ID": "jsw7fx09l5zsda3bri1z4mwk5",
+      "LastUsedAt": "2025-08-05T09:24:09Z",
+      "Mutable": false,
+      "Parents": [
+        "098jsj5ebbv1w47ikqigeuurs"
+      ],
+      "Reclaimable": true,
+      "Shared": true,
+      "Size": "829898832",
+      "Type": "regular",
+      "UsageCount": 1
+    }
+    ```
+
+    ### Use verbose output (--verbose) {#verbose}
+
+    Shorthand for [`--format=pretty`](#format):
+
+    ```console
+    $ docker buildx du --verbose
+    ...
+    ID:           6wqu0v6hjdwvhh8yjozrepaof
+    Parents:
+     - bqx15bcewecz4wcg14b7iodvp
+    Created at:   2025-06-12 15:44:02.715795569 +0000 UTC
+    Mutable:      false
+    Reclaimable:  true
+    Shared:       true
+    Size:         1.653GB
+    Description:  [build-base 4/4] COPY . .
+    Usage count:  1
+    Last used:    2 months ago
+    Type:         regular
+
+    Shared:         35.57GB
+    Private:        97.94GB
+    Reclaimable:    131.5GB
+    Total:          133.5GB
+    ```
+
+    ### Override the configured builder instance (--builder) {#builder}
+
+    Use the `--builder` flag to inspect the disk usage of a particular builder.
+
+    ```console
+    $ docker buildx du --builder mybuilder
+    ID                                RECLAIMABLE    SIZE          LAST ACCESSED
+    g41agepgdczekxg2mtw0dujsv*        true           1.312GB       47 hours ago
+    e6ycrsa0bn9akigqgzu0sc6kr         true           318MB         47 hours ago
+    our9zg4ndly65ze1ccczdksiz         true           204.9MB       45 hours ago
+    b7xv3xpxnwupc81tc9ya3mgq6*        true           120.6MB       47 hours ago
+    zihgye15ss6vum3wmck9egdoy*        true           79.81MB       2 days ago
+    aaydharssv1ug98yhuwclkfrh*        true           79.81MB       2 days ago
+    ta1r4vmnjug5dhub76as4kkol*        true           74.51MB       47 hours ago
+    murma9f83j9h8miifbq68udjf*        true           74.51MB       47 hours ago
+    47f961866a49g5y8myz80ixw1*        true           74.51MB       47 hours ago
+    tzh99xtzlaf6txllh3cobag8t         true           74.49MB       47 hours ago
+    ld6laoeuo1kwapysu6afwqybl*        true           59.89MB       47 hours ago
+    yitxizi5kaplpyomqpos2cryp*        true           59.83MB       47 hours ago
+    iy8aa4b7qjn0qmy9wiga9cj8w         true           33.65MB       47 hours ago
+    mci7okeijyp8aqqk16j80dy09         true           19.86MB       47 hours ago
+    lqvj091he652slxdla4wom3pz         true           14.08MB       47 hours ago
+    fkt31oiv793nd26h42llsjcw7*        true           11.87MB       2 days ago
+    uj802yxtvkcjysnjb4kgwvn2v         true           11.68MB       45 hours ago
+    Reclaimable:    2.627GB
+    Total:          2.627GB
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/buildx/docker_buildx_history.yaml b/data/cli/buildx/docker_buildx_history.yaml
similarity index 100%
rename from data/buildx/docker_buildx_history.yaml
rename to data/cli/buildx/docker_buildx_history.yaml
diff --git a/data/cli/buildx/docker_buildx_history_export.yaml b/data/cli/buildx/docker_buildx_history_export.yaml
new file mode 100644
index 000000000000..214ebd004d20
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_history_export.yaml
@@ -0,0 +1,138 @@
+command: docker buildx history export
+short: Export build records into Docker Desktop bundle
+long: |-
+    Export one or more build records to `.dockerbuild` archive files. These archives
+    contain metadata, logs, and build outputs, and can be imported into Docker
+    Desktop or shared across environments.
+usage: docker buildx history export [OPTIONS] [REF...]
+pname: docker buildx history
+plink: docker_buildx_history.yaml
+options:
+    - option: all
+      value_type: bool
+      default_value: "false"
+      description: Export all build records for the builder
+      details_url: '#all'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: finalize
+      value_type: bool
+      default_value: "false"
+      description: Ensure build records are finalized before exporting
+      details_url: '#finalize'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: output
+      shorthand: o
+      value_type: string
+      description: Output file path
+      details_url: '#output'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      details_url: '#builder'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      details_url: '#debug'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Export all build records to a file (--all) {#all}
+
+    Use the `--all` flag and redirect the output:
+
+    ```console
+    docker buildx history export --all > all-builds.dockerbuild
+    ```
+
+    Or use the `--output` flag:
+
+    ```console
+    docker buildx history export --all -o all-builds.dockerbuild
+    ```
+
+    ### Use a specific builder instance (--builder) {#builder}
+
+    ```console
+    docker buildx history export --builder builder0 ^1 -o builder0-build.dockerbuild
+    ```
+
+    ### Enable debug logging (--debug) {#debug}
+
+    ```console
+    docker buildx history export --debug qu2gsuo8ejqrwdfii23xkkckt -o debug-build.dockerbuild
+    ```
+
+    ### Ensure build records are finalized before exporting (--finalize) {#finalize}
+
+    Clients can report their own traces concurrently, and not all traces may be
+    saved yet by the time of the export. Use the `--finalize` flag to ensure all
+    traces are finalized before exporting.
+
+    ```console
+    docker buildx history export --finalize qu2gsuo8ejqrwdfii23xkkckt -o finalized-build.dockerbuild
+    ```
+
+    ### Export a single build to a custom file (--output) {#output}
+
+    ```console
+    docker buildx history export qu2gsuo8ejqrwdfii23xkkckt --output mybuild.dockerbuild
+    ```
+
+    You can find build IDs by running:
+
+    ```console
+    docker buildx history ls
+    ```
+
+    To export two builds to separate files:
+
+    ```console
+    # Using build IDs
+    docker buildx history export qu2gsuo8ejqrwdfii23xkkckt qsiifiuf1ad9pa9qvppc0z1l3 -o multi.dockerbuild
+
+    # Or using relative offsets
+    docker buildx history export ^1 ^2 -o multi.dockerbuild
+    ```
+
+    Or use shell redirection:
+
+    ```console
+    docker buildx history export ^1 > mybuild.dockerbuild
+    docker buildx history export ^2 > backend-build.dockerbuild
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_history_import.yaml b/data/cli/buildx/docker_buildx_history_import.yaml
new file mode 100644
index 000000000000..bf6e2ac1fd07
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_history_import.yaml
@@ -0,0 +1,74 @@
+command: docker buildx history import
+short: Import build records into Docker Desktop
+long: |-
+    Import a build record from a `.dockerbuild` archive into Docker Desktop. This
+    lets you view, inspect, and analyze builds created in other environments or CI
+    pipelines.
+usage: docker buildx history import [OPTIONS] -
+pname: docker buildx history
+plink: docker_buildx_history.yaml
+options:
+    - option: file
+      shorthand: f
+      value_type: stringArray
+      default_value: '[]'
+      description: Import from a file path
+      details_url: '#file'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Import a `.dockerbuild` archive from standard input
+
+    ```console
+    docker buildx history import < mybuild.dockerbuild
+    ```
+
+    ### Import a build archive from a file (--file) {#file}
+
+    ```console
+    docker buildx history import --file ./artifacts/backend-build.dockerbuild
+    ```
+
+    ### Open a build manually
+
+    By default, the `import` command automatically opens the imported build in Docker
+    Desktop. You don't need to run `open` unless you're opening a specific build
+    or re-opening it later.
+
+    If you've imported multiple builds, you can open one manually:
+
+    ```console
+    docker buildx history open ci-build
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_history_inspect.yaml b/data/cli/buildx/docker_buildx_history_inspect.yaml
new file mode 100644
index 000000000000..23c5ee37b4eb
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_history_inspect.yaml
@@ -0,0 +1,192 @@
+command: docker buildx history inspect
+short: Inspect a build record
+long: |-
+    Inspect a build record to view metadata such as duration, status, build inputs,
+    platforms, outputs, and attached artifacts. You can also use flags to extract
+    provenance, SBOMs, or other detailed information.
+usage: docker buildx history inspect [OPTIONS] [REF]
+pname: docker buildx history
+plink: docker_buildx_history.yaml
+cname:
+    - docker buildx history inspect attachment
+clink:
+    - docker_buildx_history_inspect_attachment.yaml
+options:
+    - option: format
+      value_type: string
+      default_value: pretty
+      description: Format the output
+      details_url: '#format'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Inspect the most recent build
+
+    ```console
+    $ docker buildx history inspect
+    Name:           buildx (binaries)
+    Context:        .
+    Dockerfile:     Dockerfile
+    VCS Repository: https://github.com/crazy-max/buildx.git
+    VCS Revision:   f15eaa1ee324ffbbab29605600d27a84cab86361
+    Target:         binaries
+    Platforms:      linux/amd64
+    Keep Git Dir:   true
+
+    Started:        2025-02-07 11:56:24
+    Duration:       1m  1s
+    Build Steps:    16/16 (25% cached)
+
+    Image Resolve Mode:     local
+
+    Materials:
+    URI                                                             DIGEST
+    pkg:docker/docker/dockerfile@1                                  sha256:93bfd3b68c109427185cd78b4779fc82b484b0b7618e36d0f104d4d801e66d25
+    pkg:docker/golang@1.23-alpine3.21?platform=linux%2Famd64        sha256:2c49857f2295e89b23b28386e57e018a86620a8fede5003900f2d138ba9c4037
+    pkg:docker/tonistiigi/xx@1.6.1?platform=linux%2Famd64           sha256:923441d7c25f1e2eb5789f82d987693c47b8ed987c4ab3b075d6ed2b5d6779a3
+
+    Attachments:
+    DIGEST                                                                  PLATFORM        TYPE
+    sha256:217329d2af959d4f02e3a96dcbe62bf100cab1feb8006a047ddfe51a5397f7e3                 https://slsa.dev/provenance/v0.2
+    ```
+
+    ### Inspect a specific build
+
+    ```console
+    # Using a build ID
+    docker buildx history inspect qu2gsuo8ejqrwdfii23xkkckt
+
+    # Or using a relative offset
+    docker buildx history inspect ^1
+    ```
+
+    ### Format the output (--format) {#format}
+
+    The formatting options (`--format`) pretty-prints the output to `pretty` (default),
+    `json` or using a Go template.
+
+    #### Pretty output
+
+    ```console
+    $ docker buildx history inspect
+    Name:           buildx (binaries)
+    Context:        .
+    Dockerfile:     Dockerfile
+    VCS Repository: https://github.com/crazy-max/buildx.git
+    VCS Revision:   f15eaa1ee324ffbbab29605600d27a84cab86361
+    Target:         binaries
+    Platforms:      linux/amd64
+    Keep Git Dir:   true
+
+    Started:        2025-02-07 11:56:24
+    Duration:       1m  1s
+    Build Steps:    16/16 (25% cached)
+
+    Image Resolve Mode:     local
+
+    Materials:
+    URI                                                             DIGEST
+    pkg:docker/docker/dockerfile@1                                  sha256:93bfd3b68c109427185cd78b4779fc82b484b0b7618e36d0f104d4d801e66d25
+    pkg:docker/golang@1.23-alpine3.21?platform=linux%2Famd64        sha256:2c49857f2295e89b23b28386e57e018a86620a8fede5003900f2d138ba9c4037
+    pkg:docker/tonistiigi/xx@1.6.1?platform=linux%2Famd64           sha256:923441d7c25f1e2eb5789f82d987693c47b8ed987c4ab3b075d6ed2b5d6779a3
+
+    Attachments:
+    DIGEST                                                                  PLATFORM        TYPE
+    sha256:217329d2af959d4f02e3a96dcbe62bf100cab1feb8006a047ddfe51a5397f7e3                 https://slsa.dev/provenance/v0.2
+
+    Print build logs: docker buildx history logs g9808bwrjrlkbhdamxklx660b
+    ```
+
+    #### JSON output
+
+    ```console
+    $ docker buildx history inspect --format json
+    {
+      "Name": "buildx (binaries)",
+      "Ref": "5w7vkqfi0rf59hw4hnmn627r9",
+      "Context": ".",
+      "Dockerfile": "Dockerfile",
+      "VCSRepository": "https://github.com/crazy-max/buildx.git",
+      "VCSRevision": "f15eaa1ee324ffbbab29605600d27a84cab86361",
+      "Target": "binaries",
+      "Platform": [
+        "linux/amd64"
+      ],
+      "KeepGitDir": true,
+      "StartedAt": "2025-02-07T12:01:05.75807272+01:00",
+      "CompletedAt": "2025-02-07T12:02:07.991778875+01:00",
+      "Duration": 62233706155,
+      "Status": "completed",
+      "NumCompletedSteps": 16,
+      "NumTotalSteps": 16,
+      "NumCachedSteps": 4,
+      "Config": {
+        "ImageResolveMode": "local"
+      },
+      "Materials": [
+        {
+          "URI": "pkg:docker/docker/dockerfile@1",
+          "Digests": [
+            "sha256:93bfd3b68c109427185cd78b4779fc82b484b0b7618e36d0f104d4d801e66d25"
+          ]
+        },
+        {
+          "URI": "pkg:docker/golang@1.23-alpine3.21?platform=linux%2Famd64",
+          "Digests": [
+            "sha256:2c49857f2295e89b23b28386e57e018a86620a8fede5003900f2d138ba9c4037"
+          ]
+        },
+        {
+          "URI": "pkg:docker/tonistiigi/xx@1.6.1?platform=linux%2Famd64",
+          "Digests": [
+            "sha256:923441d7c25f1e2eb5789f82d987693c47b8ed987c4ab3b075d6ed2b5d6779a3"
+          ]
+        }
+      ],
+      "Attachments": [
+        {
+          "Digest": "sha256:450fdd2e6b868fecd69e9891c2c404ba461aa38a47663b4805edeb8d2baf80b1",
+          "Type": "https://slsa.dev/provenance/v0.2"
+        }
+      ]
+    }
+    ```
+
+    #### Go template output
+
+    ```console
+    $ docker buildx history inspect --format "{{.Name}}: {{.VCSRepository}} ({{.VCSRevision}})"
+    buildx (binaries): https://github.com/crazy-max/buildx.git (f15eaa1ee324ffbbab29605600d27a84cab86361)
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_history_inspect_attachment.yaml b/data/cli/buildx/docker_buildx_history_inspect_attachment.yaml
new file mode 100644
index 000000000000..d1ca968e3678
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_history_inspect_attachment.yaml
@@ -0,0 +1,228 @@
+command: docker buildx history inspect attachment
+short: Inspect a build record attachment
+long: |-
+    Inspect a specific attachment from a build record, such as a provenance file or
+    SBOM. Attachments are optional artifacts stored with the build and may be
+    platform-specific.
+usage: docker buildx history inspect attachment [OPTIONS] [REF [DIGEST]]
+pname: docker buildx history inspect
+plink: docker_buildx_history_inspect.yaml
+options:
+    - option: platform
+      value_type: string
+      description: Platform of attachment
+      details_url: '#platform'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: type
+      value_type: string
+      description: Type of attachment
+      details_url: '#type'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Inspect an attachment by platform (--platform) {#platform}
+
+    ```console
+    $ docker buildx history inspect attachment --platform linux/amd64
+    {
+      "schemaVersion": 2,
+      "mediaType": "application/vnd.oci.image.manifest.v1+json",
+      "config": {
+        "mediaType": "application/vnd.oci.image.config.v1+json",
+        "digest": "sha256:814e63f06465bc78123775714e4df1ebdda37e6403e0b4f481df74947c047163",
+        "size": 600
+      },
+      "layers": [
+        {
+          "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
+          "digest": "sha256:36537f3920ae948ce3e12b4ae34c21190280e6e7d58eeabde0dff3fdfb43b6b0",
+          "size": 21664137
+        }
+      ]
+    }
+    ```
+
+    ### Inspect an attachment by type (--type) {#type}
+
+    Supported types include:
+    * `index`
+    * `manifest`
+    * `image`
+    * `provenance`
+    * `sbom`
+
+    #### Index
+
+    ```console
+    $ docker buildx history inspect attachment --type index
+    {
+      "schemaVersion": 2,
+      "mediaType": "application/vnd.oci.image.index.v1+json",
+      "manifests": [
+        {
+          "mediaType": "application/vnd.oci.image.manifest.v1+json",
+          "digest": "sha256:a194e24f47dc6d0e65992c09577b9bc4e7bd0cd5cc4f81e7738918f868aa397b",
+          "size": 481,
+          "platform": {
+            "architecture": "amd64",
+            "os": "linux"
+          }
+        },
+        {
+          "mediaType": "application/vnd.oci.image.manifest.v1+json",
+          "digest": "sha256:49e40223d6a96ea0667a12737fd3dde004cf217eb48cb28c9191288cd44c6ace",
+          "size": 839,
+          "annotations": {
+            "vnd.docker.reference.digest": "sha256:a194e24f47dc6d0e65992c09577b9bc4e7bd0cd5cc4f81e7738918f868aa397b",
+            "vnd.docker.reference.type": "attestation-manifest"
+          },
+          "platform": {
+            "architecture": "unknown",
+            "os": "unknown"
+          }
+        }
+      ]
+    }
+    ```
+
+    #### Manifest
+
+    ```console
+    $ docker buildx history inspect attachment --type manifest
+    {
+      "schemaVersion": 2,
+      "mediaType": "application/vnd.oci.image.manifest.v1+json",
+      "config": {
+        "mediaType": "application/vnd.oci.image.config.v1+json",
+        "digest": "sha256:814e63f06465bc78123775714e4df1ebdda37e6403e0b4f481df74947c047163",
+        "size": 600
+      },
+      "layers": [
+        {
+          "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
+          "digest": "sha256:36537f3920ae948ce3e12b4ae34c21190280e6e7d58eeabde0dff3fdfb43b6b0",
+          "size": 21664137
+        }
+      ]
+    }
+    ```
+
+    #### Provenance
+
+    ```console
+    $ docker buildx history inspect attachment --type provenance
+    {
+      "builder": {
+        "id": ""
+      },
+      "buildType": "https://mobyproject.org/buildkit@v1",
+      "materials": [
+        {
+          "uri": "pkg:docker/docker/dockerfile@1",
+          "digest": {
+            "sha256": "9ba7531bd80fb0a858632727cf7a112fbfd19b17e94c4e84ced81e24ef1a0dbc"
+          }
+        },
+        {
+          "uri": "pkg:docker/golang@1.19.4-alpine?platform=linux%2Farm64",
+          "digest": {
+            "sha256": "a9b24b67dc83b3383d22a14941c2b2b2ca6a103d805cac6820fd1355943beaf1"
+          }
+        }
+      ],
+      "invocation": {
+        "configSource": {
+          "entryPoint": "Dockerfile"
+        },
+        "parameters": {
+          "frontend": "gateway.v0",
+          "args": {
+            "cmdline": "docker/dockerfile:1",
+            "source": "docker/dockerfile:1",
+            "target": "binaries"
+          },
+          "locals": [
+            {
+              "name": "context"
+            },
+            {
+              "name": "dockerfile"
+            }
+          ]
+        },
+        "environment": {
+          "platform": "linux/arm64"
+        }
+      },
+      "metadata": {
+        "buildInvocationID": "c4a87v0sxhliuewig10gnsb6v",
+        "buildStartedOn": "2022-12-16T08:26:28.651359794Z",
+        "buildFinishedOn": "2022-12-16T08:26:29.625483253Z",
+        "reproducible": false,
+        "completeness": {
+          "parameters": true,
+          "environment": true,
+          "materials": false
+        },
+        "https://mobyproject.org/buildkit@v1#metadata": {
+          "vcs": {
+            "revision": "a9ba846486420e07d30db1107411ac3697ecab68",
+            "source": "git@github.com:<org>/<repo>.git"
+          }
+        }
+      }
+    }
+    ```
+
+    ### Inspect an attachment by digest
+
+    You can inspect an attachment directly using its digest, which you can get from
+    the `inspect` output:
+
+    ```console
+    # Using a build ID
+    docker buildx history inspect attachment qu2gsuo8ejqrwdfii23xkkckt sha256:abcdef123456...
+
+    # Or using a relative offset
+    docker buildx history inspect attachment ^0 sha256:abcdef123456...
+    ```
+
+    Use `--type sbom` or `--type provenance` to filter attachments by type. To
+    inspect a specific attachment by digest, omit the `--type` flag.
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_history_logs.yaml b/data/cli/buildx/docker_buildx_history_logs.yaml
new file mode 100644
index 000000000000..3a15e9efd24d
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_history_logs.yaml
@@ -0,0 +1,91 @@
+command: docker buildx history logs
+short: Print the logs of a build record
+long: |-
+    Print the logs for a completed build. The output appears in the same format as
+    `--progress=plain`, showing the full logs for each step.
+
+    By default, this shows logs for the most recent build on the current builder.
+
+    You can also specify an earlier build using an offset. For example:
+
+    - `^1` shows logs for the build before the most recent
+    - `^2` shows logs for the build two steps back
+usage: docker buildx history logs [OPTIONS] [REF]
+pname: docker buildx history
+plink: docker_buildx_history.yaml
+options:
+    - option: progress
+      value_type: string
+      default_value: plain
+      description: Set type of progress output (plain, rawjson, tty)
+      details_url: '#progress'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Print logs for the most recent build
+
+    ```console
+    $ docker buildx history logs
+    #1 [internal] load build definition from Dockerfile
+    #1 transferring dockerfile: 31B done
+    #1 DONE 0.0s
+    #2 [internal] load .dockerignore
+    #2 transferring context: 2B done
+    #2 DONE 0.0s
+    ...
+    ```
+
+    By default, this shows logs for the most recent build on the current builder.
+
+    ### Print logs for a specific build
+
+    To print logs for a specific build, use a build ID or offset:
+
+    ```console
+    # Using a build ID
+    docker buildx history logs qu2gsuo8ejqrwdfii23xkkckt
+
+    # Or using a relative offset
+    docker buildx history logs ^1
+    ```
+
+    ### Set type of progress output (--progress) {#progress}
+
+    ```console
+    $ docker buildx history logs ^1 --progress rawjson
+    {"id":"buildx_step_1","status":"START","timestamp":"2024-05-01T12:34:56.789Z","detail":"[internal] load build definition from Dockerfile"}
+    {"id":"buildx_step_1","status":"COMPLETE","timestamp":"2024-05-01T12:34:57.001Z","duration":212000000}
+    ...
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_history_ls.yaml b/data/cli/buildx/docker_buildx_history_ls.yaml
new file mode 100644
index 000000000000..d49eec62ce7b
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_history_ls.yaml
@@ -0,0 +1,158 @@
+command: docker buildx history ls
+short: List build records
+long: |-
+    List completed builds recorded by the active builder. Each entry includes the
+    build ID, name, status, timestamp, and duration.
+
+    By default, only records for the current builder are shown. You can filter
+    results using flags.
+usage: docker buildx history ls [OPTIONS]
+pname: docker buildx history
+plink: docker_buildx_history.yaml
+options:
+    - option: filter
+      value_type: stringArray
+      default_value: '[]'
+      description: Provide filter values (e.g., `status=error`)
+      details_url: '#filter'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: format
+      value_type: string
+      default_value: table
+      description: Format the output
+      details_url: '#format'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: local
+      value_type: bool
+      default_value: "false"
+      description: List records for current repository only
+      details_url: '#local'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: no-trunc
+      value_type: bool
+      default_value: "false"
+      description: Don't truncate output
+      details_url: '#no-trunc'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### List all build records for the current builder
+
+    ```console
+    $ docker buildx history ls
+    BUILD ID                    NAME           STATUS     CREATED AT        DURATION
+    qu2gsuo8ejqrwdfii23xkkckt   .dev/2850      Completed  3 days ago        1.4s
+    qsiifiuf1ad9pa9qvppc0z1l3   .dev/2850      Completed  3 days ago        1.3s
+    g9808bwrjrlkbhdamxklx660b   .dev/3120      Completed  5 days ago        2.1s
+    ```
+
+    ### List failed builds (--filter) {#filter}
+
+    ```console
+    docker buildx history ls --filter status=error
+    ```
+
+    You can filter the list using the `--filter` flag. Supported filters include:
+
+    | Filter                                 | Supported comparisons                            | Example                    |
+    |:---------------------------------------|:-------------------------------------------------|:---------------------------|
+    | `ref`, `repository`, `status`          | Support `=` and `!=` comparisons                 | `--filter status!=success` |
+    | `startedAt`, `completedAt`, `duration` | Support `<` and `>` comparisons with time values | `--filter duration>30s`    |
+
+    You can combine multiple filters by repeating the `--filter` flag:
+
+    ```console
+    docker buildx history ls --filter status=error --filter duration>30s
+    ```
+
+    ### List builds from the current project (--local) {#local}
+
+    ```console
+    docker buildx history ls --local
+    ```
+
+    ### Display full output without truncation (--no-trunc) {#no-trunc}
+
+    ```console
+    docker buildx history ls --no-trunc
+    ```
+
+    ### Format output (--format) {#format}
+
+    #### JSON output
+
+    ```console
+    $ docker buildx history ls --format json
+    [
+      {
+        "ID": "qu2gsuo8ejqrwdfii23xkkckt",
+        "Name": ".dev/2850",
+        "Status": "Completed",
+        "CreatedAt": "2025-04-15T12:33:00Z",
+        "Duration": "1.4s"
+      },
+      {
+        "ID": "qsiifiuf1ad9pa9qvppc0z1l3",
+        "Name": ".dev/2850",
+        "Status": "Completed",
+        "CreatedAt": "2025-04-15T12:29:00Z",
+        "Duration": "1.3s"
+      }
+    ]
+    ```
+
+    #### Go template output
+
+    ```console
+    $ docker buildx history ls --format '{{.Name}} - {{.Duration}}'
+    .dev/2850 - 1.4s
+    .dev/2850 - 1.3s
+    .dev/3120 - 2.1s
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_history_open.yaml b/data/cli/buildx/docker_buildx_history_open.yaml
new file mode 100644
index 000000000000..1b760fcf6456
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_history_open.yaml
@@ -0,0 +1,54 @@
+command: docker buildx history open
+short: Open a build record in Docker Desktop
+long: |-
+    Open a build record in Docker Desktop for visual inspection. This requires
+    Docker Desktop to be installed and running on the host machine.
+usage: docker buildx history open [OPTIONS] [REF]
+pname: docker buildx history
+plink: docker_buildx_history.yaml
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Open the most recent build in Docker Desktop
+
+    ```console
+    docker buildx history open
+    ```
+
+    By default, this opens the most recent build on the current builder.
+
+    ### Open a specific build
+
+    ```console
+    # Using a build ID
+    docker buildx history open qu2gsuo8ejqrwdfii23xkkckt
+
+    # Or using a relative offset
+    docker buildx history open ^1
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_history_rm.yaml b/data/cli/buildx/docker_buildx_history_rm.yaml
new file mode 100644
index 000000000000..2c35a7277587
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_history_rm.yaml
@@ -0,0 +1,75 @@
+command: docker buildx history rm
+short: Remove build records
+long: |-
+    Remove one or more build records from the current builder’s history. You can
+    remove specific builds by ID or offset, or delete all records at once using
+    the `--all` flag.
+usage: docker buildx history rm [OPTIONS] [REF...]
+pname: docker buildx history
+plink: docker_buildx_history.yaml
+options:
+    - option: all
+      value_type: bool
+      default_value: "false"
+      description: Remove all build records
+      details_url: '#all'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Remove a specific build
+
+    ```console
+    # Using a build ID
+    docker buildx history rm qu2gsuo8ejqrwdfii23xkkckt
+
+    # Or using a relative offset
+    docker buildx history rm ^1
+    ```
+
+    ### Remove multiple builds
+
+    ```console
+    # Using build IDs
+    docker buildx history rm qu2gsuo8ejqrwdfii23xkkckt qsiifiuf1ad9pa9qvppc0z1l3
+
+    # Or using relative offsets
+    docker buildx history rm ^1 ^2
+    ```
+
+    ### Remove all build records from the current builder (--all) {#all}
+
+    ```console
+    docker buildx history rm --all
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_history_trace.yaml b/data/cli/buildx/docker_buildx_history_trace.yaml
new file mode 100644
index 000000000000..866f7673843d
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_history_trace.yaml
@@ -0,0 +1,104 @@
+command: docker buildx history trace
+short: Show the OpenTelemetry trace of a build record
+long: |-
+    View the OpenTelemetry trace for a completed build. This command loads the
+    trace into a Jaeger UI viewer and opens it in your browser.
+
+    This helps analyze build performance, step timing, and internal execution flows.
+usage: docker buildx history trace [OPTIONS] [REF]
+pname: docker buildx history
+plink: docker_buildx_history.yaml
+options:
+    - option: addr
+      value_type: string
+      default_value: 127.0.0.1:0
+      description: Address to bind the UI server
+      details_url: '#addr'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: compare
+      value_type: string
+      description: Compare with another build record
+      details_url: '#compare'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Open the OpenTelemetry trace for the most recent build
+
+    This command starts a temporary Jaeger UI server and opens your default browser
+    to view the trace.
+
+    ```console
+    docker buildx history trace
+    ```
+
+    ### Open the trace for a specific build
+
+    ```console
+    # Using a build ID
+    docker buildx history trace qu2gsuo8ejqrwdfii23xkkckt
+
+    # Or using a relative offset
+    docker buildx history trace ^1
+    ```
+
+    ### Run the Jaeger UI on a specific port (--addr) {#addr}
+
+    ```console
+    # Using a build ID
+    docker buildx history trace qu2gsuo8ejqrwdfii23xkkckt --addr 127.0.0.1:16686
+
+    # Or using a relative offset
+    docker buildx history trace ^1 --addr 127.0.0.1:16686
+    ```
+
+    ### Compare two build traces (--compare) {#compare}
+
+    Compare two specific builds by name:
+
+    ```console
+    # Using build IDs
+    docker buildx history trace --compare=qu2gsuo8ejqrwdfii23xkkckt qsiifiuf1ad9pa9qvppc0z1l3
+
+    # Or using a single relative offset
+    docker buildx history trace --compare=^1
+    ```
+
+    When you use a single reference with `--compare`, it compares that build
+    against the most recent one.
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/buildx/docker_buildx_imagetools.yaml b/data/cli/buildx/docker_buildx_imagetools.yaml
similarity index 100%
rename from data/buildx/docker_buildx_imagetools.yaml
rename to data/cli/buildx/docker_buildx_imagetools.yaml
diff --git a/data/buildx/docker_buildx_imagetools_create.yaml b/data/cli/buildx/docker_buildx_imagetools_create.yaml
similarity index 80%
rename from data/buildx/docker_buildx_imagetools_create.yaml
rename to data/cli/buildx/docker_buildx_imagetools_create.yaml
index 4bcb085db3dd..2e7aa46e1f43 100644
--- a/data/buildx/docker_buildx_imagetools_create.yaml
+++ b/data/cli/buildx/docker_buildx_imagetools_create.yaml
@@ -10,7 +10,7 @@ long: |-
     a list or index, the output will be a manifest list, however you can disable this
     behavior with `--prefer-index=false` which attempts to preserve the source manifest
     format in the output.
-usage: docker buildx imagetools create [OPTIONS] [SOURCE] [SOURCE...]
+usage: docker buildx imagetools create [OPTIONS] [SOURCE...]
 pname: docker buildx imagetools
 plink: docker_buildx_imagetools.yaml
 options:
@@ -59,6 +59,27 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: metadata-file
+      value_type: string
+      description: Write create result metadata to a file
+      details_url: '#metadata-file'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: platform
+      shorthand: p
+      value_type: stringArray
+      default_value: '[]'
+      description: Filter specified platforms of target image
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: prefer-index
       value_type: bool
       default_value: "true"
@@ -74,7 +95,7 @@ options:
       value_type: string
       default_value: auto
       description: |
-        Set type of progress output (`auto`, `plain`, `tty`, `rawjson`). Use plain to show container output
+        Set type of progress output (`auto`, `none`, `plain`, `rawjson`, `tty`). Use plain to show container output
       deprecated: false
       hidden: false
       experimental: false
@@ -177,6 +198,28 @@ examples: |-
 
     The supported fields for the descriptor are defined in [OCI spec](https://github.com/opencontainers/image-spec/blob/master/descriptor.md#properties) .
 
+    ### Write create result metadata to a file (--metadata-file) {#metadata-file}
+
+    To output metadata such as the image digest, pass the `--metadata-file` flag.
+    The metadata will be written as a JSON object to the specified file. The
+    directory of the specified file must already exist and be writable.
+
+    ```console
+    $ docker buildx imagetools create -t user/app:latest -f image1 -f image2 --metadata-file metadata.json
+    $ cat metadata.json
+    ```
+
+    ```json
+    {
+      "containerimage.descriptor": {
+        "mediaType": "application/vnd.oci.image.index.v1+json",
+        "digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3",
+        "size": 4654
+      },
+      "image.name": "docker.io/user/app"
+    }
+    ```
+
     ### Set reference for new image  (-t, --tag) {#tag}
 
     ```text
diff --git a/data/buildx/docker_buildx_imagetools_inspect.yaml b/data/cli/buildx/docker_buildx_imagetools_inspect.yaml
similarity index 100%
rename from data/buildx/docker_buildx_imagetools_inspect.yaml
rename to data/cli/buildx/docker_buildx_imagetools_inspect.yaml
diff --git a/data/buildx/docker_buildx_inspect.yaml b/data/cli/buildx/docker_buildx_inspect.yaml
similarity index 93%
rename from data/buildx/docker_buildx_inspect.yaml
rename to data/cli/buildx/docker_buildx_inspect.yaml
index 72711fd22cac..51eccaf0914b 100644
--- a/data/buildx/docker_buildx_inspect.yaml
+++ b/data/cli/buildx/docker_buildx_inspect.yaml
@@ -16,6 +16,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: timeout
+      value_type: duration
+      default_value: 20s
+      description: Override the default timeout for loading builder status
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
 inherited_options:
     - option: builder
       value_type: string
diff --git a/data/buildx/docker_buildx_install.yaml b/data/cli/buildx/docker_buildx_install.yaml
similarity index 97%
rename from data/buildx/docker_buildx_install.yaml
rename to data/cli/buildx/docker_buildx_install.yaml
index 39072f3cfed6..b06139b0fafa 100644
--- a/data/buildx/docker_buildx_install.yaml
+++ b/data/cli/buildx/docker_buildx_install.yaml
@@ -25,7 +25,7 @@ inherited_options:
       experimentalcli: false
       kubernetes: false
       swarm: false
-deprecated: false
+deprecated: true
 hidden: true
 experimental: false
 experimentalcli: false
diff --git a/data/buildx/docker_buildx_ls.yaml b/data/cli/buildx/docker_buildx_ls.yaml
similarity index 93%
rename from data/buildx/docker_buildx_ls.yaml
rename to data/cli/buildx/docker_buildx_ls.yaml
index 29cdd2ceb5d2..9da96809ec40 100644
--- a/data/buildx/docker_buildx_ls.yaml
+++ b/data/cli/buildx/docker_buildx_ls.yaml
@@ -49,6 +49,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: timeout
+      value_type: duration
+      default_value: 20s
+      description: Override the default timeout for loading builder status
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
 inherited_options:
     - option: debug
       shorthand: D
diff --git a/data/cli/buildx/docker_buildx_policy.yaml b/data/cli/buildx/docker_buildx_policy.yaml
new file mode 100644
index 000000000000..a905cbc376a5
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_policy.yaml
@@ -0,0 +1,39 @@
+command: docker buildx policy
+short: Commands for working with build policies
+long: Commands for working with build policies
+pname: docker buildx
+plink: docker_buildx.yaml
+cname:
+    - docker buildx policy eval
+    - docker buildx policy test
+clink:
+    - docker_buildx_policy_eval.yaml
+    - docker_buildx_policy_test.yaml
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_policy_eval.yaml b/data/cli/buildx/docker_buildx_policy_eval.yaml
new file mode 100644
index 000000000000..8887abef9d4b
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_policy_eval.yaml
@@ -0,0 +1,85 @@
+command: docker buildx policy eval
+short: Evaluate policy for a source
+long: Evaluate policy for a source
+usage: docker buildx policy eval [OPTIONS] source
+pname: docker buildx policy
+plink: docker_buildx_policy.yaml
+options:
+    - option: fields
+      value_type: stringSlice
+      default_value: '[]'
+      description: Fields to evaluate
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: file
+      shorthand: f
+      value_type: string
+      default_value: Dockerfile
+      description: Policy filename to evaluate
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: filename
+      value_type: string
+      default_value: Dockerfile
+      description: Policy filename to evaluate
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: platform
+      value_type: string
+      description: Target platform for policy evaluation
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: print
+      value_type: bool
+      default_value: "false"
+      description: Print policy output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_policy_test.yaml b/data/cli/buildx/docker_buildx_policy_test.yaml
new file mode 100644
index 000000000000..7a18fbc86537
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_policy_test.yaml
@@ -0,0 +1,54 @@
+command: docker buildx policy test
+short: Run policy tests
+long: Run policy tests
+usage: docker buildx policy test <path>
+pname: docker buildx policy
+plink: docker_buildx_policy.yaml
+options:
+    - option: filename
+      value_type: string
+      default_value: Dockerfile
+      description: Name of the Dockerfile to validate
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: run
+      value_type: string
+      description: Run only tests with name containing this substring
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/buildx/docker_buildx_prune.yaml b/data/cli/buildx/docker_buildx_prune.yaml
new file mode 100644
index 000000000000..1763e571ef0e
--- /dev/null
+++ b/data/cli/buildx/docker_buildx_prune.yaml
@@ -0,0 +1,217 @@
+command: docker buildx prune
+short: Remove build cache
+long: Clears the build cache of the selected builder.
+usage: docker buildx prune
+pname: docker buildx
+plink: docker_buildx.yaml
+options:
+    - option: all
+      shorthand: a
+      value_type: bool
+      default_value: "false"
+      description: Include internal/frontend images
+      details_url: '#all'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: filter
+      value_type: filter
+      description: Provide filter values
+      details_url: '#filter'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: force
+      shorthand: f
+      value_type: bool
+      default_value: "false"
+      description: Do not prompt for confirmation
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: keep-storage
+      value_type: bytes
+      default_value: "0"
+      description: Amount of disk space to keep for cache
+      deprecated: true
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: max-used-space
+      value_type: bytes
+      default_value: "0"
+      description: Maximum amount of disk space allowed to keep for cache
+      details_url: '#max-used-space'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: min-free-space
+      value_type: bytes
+      default_value: "0"
+      description: Target amount of free disk space after pruning
+      details_url: '#min-free-space'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: reserved-space
+      value_type: bytes
+      default_value: "0"
+      description: Amount of disk space always allowed to keep for cache
+      details_url: '#reserved-space'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: timeout
+      value_type: duration
+      default_value: 20s
+      description: Override the default timeout for loading builder status
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose
+      value_type: bool
+      default_value: "false"
+      description: Provide a more verbose output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: builder
+      value_type: string
+      description: Override the configured builder instance
+      details_url: '#builder'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug
+      shorthand: D
+      value_type: bool
+      default_value: "false"
+      description: Enable debug logging
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Include internal/frontend images (--all) {#all}
+
+    The `--all` flag to allow clearing internal helper images and frontend images
+    set using the `#syntax=` directive or the `BUILDKIT_SYNTAX` build argument.
+
+    ### Provide filter values (--filter) {#filter}
+
+    You can finely control which cache records to delete using the `--filter` flag.
+
+    The filter format is in the form of `<key><op><value>`, known as selectors. All
+    selectors must match the target object for the filter to be true. We define the
+    operators `=` for equality, `!=` for not equal and `~=` for a regular
+    expression.
+
+    Valid filter keys are:
+    - `until` flag to keep records that have been used in the last duration time.
+      Value is a duration string, e.g. `24h` or `2h30m`, with allowable units of
+      `(h)ours`, `(m)inutes` and `(s)econds`.
+    - `id` flag to target a specific image ID.
+    - `parents` flag to target records that are parents of the
+      specified image ID. Multiple parent IDs are separated by a semicolon (`;`).
+    - `description` flag to target records whose description is the specified
+      substring.
+    - `inuse` flag to target records that are actively in use and therefore not
+      reclaimable.
+    - `mutable` flag to target records that are mutable.
+    - `immutable` flag to target records that are immutable.
+    - `shared` flag to target records that are shared with other resources,
+      typically images.
+    - `private` flag to target records that are not shared.
+    - `type` flag to target records by type. Valid types are:
+      - `internal`
+      - `frontend`
+      - `source.local`
+      - `source.git.checkout`
+      - `exec.cachemount`
+      - `regular`
+
+    Examples:
+
+    ```console
+    docker buildx prune --filter "until=24h"
+    docker buildx prune --filter "description~=golang"
+    docker buildx prune --filter "parents=dpetmoi6n0yqanxjqrbnofz9n;kgoj0q6g57i35gdyrv546alz7"
+    docker buildx prune --filter "type=source.local"
+    docker buildx prune --filter "type!=exec.cachemount"
+    ```
+
+    > [!NOTE]
+    > Multiple `--filter` flags are ANDed together.
+
+    ### Maximum amount of disk space allowed to keep for cache (--max-used-space) {#max-used-space}
+
+    The `--max-used-space` flag allows setting a maximum amount of disk space
+    that the build cache can use. If the cache is using more disk space than this
+    value, the least recently used cache records are deleted until the total
+    used space is less than or equal to the specified value.
+
+    The value is specified in bytes. You can use a human-readable memory string,
+    e.g. `128mb`, `2gb`, etc. Units are case-insensitive.
+
+    ### Target amount of free disk space after pruning (--min-free-space) {#min-free-space}
+
+    The `--min-free-space` flag allows setting a target amount of free disk space
+    that should be available after pruning. If the available disk space is less
+    than this value, the least recently used cache records are deleted until
+    the available free space is greater than or equal to the specified value.
+
+    The value is specified in bytes. You can use a human-readable memory string,
+    e.g. `128mb`, `2gb`, etc. Units are case-insensitive.
+
+    ### Amount of disk space always allowed to keep for cache (--reserved-space) {#reserved-space}
+
+    The `--reserved-space` flag allows setting an amount of disk space that
+    should always be kept for the build cache. If the available disk space is less
+    than this value, the least recently used cache records are deleted until
+    the available free space is greater than or equal to the specified value.
+
+    The value is specified in bytes. You can use a human-readable memory string,
+    e.g. `128mb`, `2gb`, etc. Units are case-insensitive.
+
+    ### Override the configured builder instance (--builder) {#builder}
+
+    Same as [`buildx --builder`](/reference/cli/docker/buildx/#builder).
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/buildx/docker_buildx_rm.yaml b/data/cli/buildx/docker_buildx_rm.yaml
similarity index 91%
rename from data/buildx/docker_buildx_rm.yaml
rename to data/cli/buildx/docker_buildx_rm.yaml
index 94eed6c8da39..b25c9c23ca35 100644
--- a/data/buildx/docker_buildx_rm.yaml
+++ b/data/cli/buildx/docker_buildx_rm.yaml
@@ -3,7 +3,7 @@ short: Remove one or more builder instances
 long: |-
     Removes the specified or current builder. It is a no-op attempting to remove the
     default builder.
-usage: docker buildx rm [OPTIONS] [NAME] [NAME...]
+usage: docker buildx rm [OPTIONS] [NAME...]
 pname: docker buildx
 plink: docker_buildx.yaml
 options:
@@ -52,6 +52,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: timeout
+      value_type: duration
+      default_value: 20s
+      description: Override the default timeout for loading builder status
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
 inherited_options:
     - option: builder
       value_type: string
diff --git a/data/buildx/docker_buildx_stop.yaml b/data/cli/buildx/docker_buildx_stop.yaml
similarity index 100%
rename from data/buildx/docker_buildx_stop.yaml
rename to data/cli/buildx/docker_buildx_stop.yaml
diff --git a/data/buildx/docker_buildx_uninstall.yaml b/data/cli/buildx/docker_buildx_uninstall.yaml
similarity index 97%
rename from data/buildx/docker_buildx_uninstall.yaml
rename to data/cli/buildx/docker_buildx_uninstall.yaml
index 5b7661324834..5351b82d7377 100644
--- a/data/buildx/docker_buildx_uninstall.yaml
+++ b/data/cli/buildx/docker_buildx_uninstall.yaml
@@ -25,7 +25,7 @@ inherited_options:
       experimentalcli: false
       kubernetes: false
       swarm: false
-deprecated: false
+deprecated: true
 hidden: true
 experimental: false
 experimentalcli: false
diff --git a/data/buildx/docker_buildx_use.yaml b/data/cli/buildx/docker_buildx_use.yaml
similarity index 100%
rename from data/buildx/docker_buildx_use.yaml
rename to data/cli/buildx/docker_buildx_use.yaml
diff --git a/data/buildx/docker_buildx_version.yaml b/data/cli/buildx/docker_buildx_version.yaml
similarity index 100%
rename from data/buildx/docker_buildx_version.yaml
rename to data/cli/buildx/docker_buildx_version.yaml
diff --git a/data/debug-cli/docker_debug.yaml b/data/cli/debug/docker_debug.yaml
similarity index 100%
rename from data/debug-cli/docker_debug.yaml
rename to data/cli/debug/docker_debug.yaml
diff --git a/data/desktop-cli/docker_desktop.yaml b/data/cli/desktop/docker_desktop.yaml
similarity index 96%
rename from data/desktop-cli/docker_desktop.yaml
rename to data/cli/desktop/docker_desktop.yaml
index f65ec5666d19..6339c6b2e262 100644
--- a/data/desktop-cli/docker_desktop.yaml
+++ b/data/cli/desktop/docker_desktop.yaml
@@ -27,8 +27,8 @@ clink:
     - docker_desktop_enable.yaml
     - docker_desktop_version.yaml
 deprecated: false
-hidden: true
+hidden: false
 experimental: false
 experimentalcli: false
 kubernetes: false
-swarm: false
\ No newline at end of file
+swarm: false
diff --git a/data/cli/desktop/docker_desktop_diagnose.yaml b/data/cli/desktop/docker_desktop_diagnose.yaml
new file mode 100644
index 000000000000..9e7fddea2a78
--- /dev/null
+++ b/data/cli/desktop/docker_desktop_diagnose.yaml
@@ -0,0 +1,22 @@
+command: docker desktop diagnose
+short: Diagnose Docker Desktop issues
+usage: docker desktop diagnose [OPTIONS]
+pname: docker desktop diagnose
+plink: docker_desktop_diagnose.yaml
+options:
+    - option: upload
+      shorthand: u
+      value_type: bool
+      default_value: "false"
+      description: Uploads the diagnostic ID.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
\ No newline at end of file
diff --git a/data/desktop-cli/docker_desktop_disable.yaml b/data/cli/desktop/docker_desktop_disable.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_disable.yaml
rename to data/cli/desktop/docker_desktop_disable.yaml
diff --git a/data/desktop-cli/docker_desktop_disable_model_runner.yaml b/data/cli/desktop/docker_desktop_disable_model_runner.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_disable_model_runner.yaml
rename to data/cli/desktop/docker_desktop_disable_model_runner.yaml
diff --git a/data/desktop-cli/docker_desktop_enable.yaml b/data/cli/desktop/docker_desktop_enable.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_enable.yaml
rename to data/cli/desktop/docker_desktop_enable.yaml
diff --git a/data/cli/desktop/docker_desktop_enable_model_runner.yaml b/data/cli/desktop/docker_desktop_enable_model_runner.yaml
new file mode 100644
index 000000000000..3c1c5332e4b2
--- /dev/null
+++ b/data/cli/desktop/docker_desktop_enable_model_runner.yaml
@@ -0,0 +1,48 @@
+command: docker desktop enable model-runner
+short: Manage Docker Model Runner settings
+long: Enable and manage Docker Model Runner settings used by 'docker model'
+usage: docker desktop enable model-runner [OPTIONS]
+pname: docker desktop enable
+plink: docker_desktop_enable.yaml
+options:
+    - option: no-tcp
+      value_type: bool
+      default_value: "false"
+      description: Disable TCP connection. Cannot be used with --tcp.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tcp
+      value_type: port
+      default_value: "12434"
+      description: |
+        Enable or change TCP port for connection (1-65535). Cannot be used with --no-tcp.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: cors
+      value_type: bool
+      default_value: "all"
+      description: CORS configuration. Can be `all`, `none`, or comma-separated list of allowed origins.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gpu
+      value_type: bool
+      default_value: "false"
+      description: Enable GPU support for Model Runner (Windows only).
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
\ No newline at end of file
diff --git a/data/desktop-cli/docker_desktop_engine.yaml b/data/cli/desktop/docker_desktop_engine.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_engine.yaml
rename to data/cli/desktop/docker_desktop_engine.yaml
diff --git a/data/desktop-cli/docker_desktop_engine_ls.yaml b/data/cli/desktop/docker_desktop_engine_ls.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_engine_ls.yaml
rename to data/cli/desktop/docker_desktop_engine_ls.yaml
diff --git a/data/desktop-cli/docker_desktop_engine_use.yaml b/data/cli/desktop/docker_desktop_engine_use.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_engine_use.yaml
rename to data/cli/desktop/docker_desktop_engine_use.yaml
diff --git a/data/cli/desktop/docker_desktop_kubernetes.yaml b/data/cli/desktop/docker_desktop_kubernetes.yaml
new file mode 100644
index 000000000000..4beff946dbdd
--- /dev/null
+++ b/data/cli/desktop/docker_desktop_kubernetes.yaml
@@ -0,0 +1,15 @@
+command: docker desktop kubernetes
+short: Manage Kubernetes settings
+usage: docker desktop kubernetes
+pname: docker desktop
+plink: docker_desktop.yaml
+cname:
+    - docker desktop kubernetes images
+clink:
+    - docker_desktop_engine_images.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
\ No newline at end of file
diff --git a/data/cli/desktop/docker_desktop_kubernetes_images.yaml b/data/cli/desktop/docker_desktop_kubernetes_images.yaml
new file mode 100644
index 000000000000..7daa67faf8d8
--- /dev/null
+++ b/data/cli/desktop/docker_desktop_kubernetes_images.yaml
@@ -0,0 +1,22 @@
+command: docker desktop kubernetes images
+short: List Kubernetes images used by Docker Desktop
+usage: docker desktop kubernetes images
+pname: docker desktop kubernetes
+plink: docker_desktop_kubernetes.yaml
+options:
+    - option: format
+      value_type: string
+      default_value: pretty
+      description: 'Format the output. Accepted values are: pretty, json'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
\ No newline at end of file
diff --git a/data/desktop-cli/docker_desktop_logs.yaml b/data/cli/desktop/docker_desktop_logs.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_logs.yaml
rename to data/cli/desktop/docker_desktop_logs.yaml
diff --git a/data/desktop-cli/docker_desktop_restart.yaml b/data/cli/desktop/docker_desktop_restart.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_restart.yaml
rename to data/cli/desktop/docker_desktop_restart.yaml
diff --git a/data/desktop-cli/docker_desktop_start.yaml b/data/cli/desktop/docker_desktop_start.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_start.yaml
rename to data/cli/desktop/docker_desktop_start.yaml
diff --git a/data/desktop-cli/docker_desktop_status.yaml b/data/cli/desktop/docker_desktop_status.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_status.yaml
rename to data/cli/desktop/docker_desktop_status.yaml
diff --git a/data/desktop-cli/docker_desktop_stop.yaml b/data/cli/desktop/docker_desktop_stop.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_stop.yaml
rename to data/cli/desktop/docker_desktop_stop.yaml
diff --git a/data/desktop-cli/docker_desktop_update.yaml b/data/cli/desktop/docker_desktop_update.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_update.yaml
rename to data/cli/desktop/docker_desktop_update.yaml
diff --git a/data/desktop-cli/docker_desktop_version.yaml b/data/cli/desktop/docker_desktop_version.yaml
similarity index 100%
rename from data/desktop-cli/docker_desktop_version.yaml
rename to data/cli/desktop/docker_desktop_version.yaml
diff --git a/data/cli/dhi/docker_dhi.yaml b/data/cli/dhi/docker_dhi.yaml
new file mode 100644
index 000000000000..d43887bd2de5
--- /dev/null
+++ b/data/cli/dhi/docker_dhi.yaml
@@ -0,0 +1,26 @@
+command: docker dhi
+short: CLI for managing Docker Hardened Images
+long: |-
+    command-line interface for administering Docker Hardened Images.
+    It provides commands to browse the DHI catalog, mirror images into your organisations and manage customizations.
+pname: docker
+plink: docker.yaml
+cname:
+    - docker dhi attestation
+    - docker dhi auth
+    - docker dhi catalog
+    - docker dhi customization
+    - docker dhi mirror
+clink:
+    - docker_dhi_attestation.yaml
+    - docker_dhi_auth.yaml
+    - docker_dhi_catalog.yaml
+    - docker_dhi_customization.yaml
+    - docker_dhi_mirror.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_attestation.yaml b/data/cli/dhi/docker_dhi_attestation.yaml
new file mode 100644
index 000000000000..272160106e27
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_attestation.yaml
@@ -0,0 +1,31 @@
+command: docker dhi attestation
+aliases: docker dhi attestation, docker dhi attest, docker dhi a
+short: View attestations for Docker Hardened Images
+long: |
+    Commands to list and inspect attestations attached to Docker Hardened Images
+pname: docker dhi
+plink: docker_dhi.yaml
+cname:
+    - docker dhi attestation get
+    - docker dhi attestation list
+    - docker dhi attestation sbom
+clink:
+    - docker_dhi_attestation_get.yaml
+    - docker_dhi_attestation_list.yaml
+    - docker_dhi_attestation_sbom.yaml
+options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/dhi/docker_dhi_attestation_get.yaml b/data/cli/dhi/docker_dhi_attestation_get.yaml
new file mode 100644
index 000000000000..9c0e4309598b
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_attestation_get.yaml
@@ -0,0 +1,53 @@
+command: docker dhi attestation get
+short: Get attestation for a Docker Hardened Image
+long: |-
+    Get an attestation attached to a Docker Hardened Image.
+
+    Returns the in-toto statement extracted from the attestation referrer.
+    The referrer digest must be provided to select which attestation to retrieve.
+    Use 'docker dhi attestation list' to discover available attestation digests.
+
+    The image can be specified as:
+      - name:tag (e.g., nginx:1.27)
+      - namespace/name:tag (e.g., dhi/nginx:1.27)
+      - name@sha256:digest (e.g., nginx@sha256:abc123...)
+
+    Examples:
+      # Get attestation by referrer digest
+      docker dhi attestation get dhi/nginx:1.27 sha256:abc123...
+
+      # Save attestation to a file
+      docker dhi attestation get dhi/nginx:1.27 sha256:abc123... -o provenance.json
+
+      # Extract only the predicate using jq
+      docker dhi attestation get dhi/nginx:1.27 sha256:abc123... | jq .predicate
+usage: docker dhi attestation get <image> <digest>
+pname: docker dhi attestation
+plink: docker_dhi_attestation.yaml
+options:
+    - option: output
+      shorthand: o
+      value_type: string
+      description: Write output to file instead of stdout
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/dhi/docker_dhi_attestation_list.yaml b/data/cli/dhi/docker_dhi_attestation_list.yaml
new file mode 100644
index 000000000000..d53af551430d
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_attestation_list.yaml
@@ -0,0 +1,83 @@
+command: docker dhi attestation list
+short: List attestations for a Docker Hardened Image
+long: |-
+    List all attestations attached to a Docker Hardened Image.
+
+    The image can be specified as:
+      - name:tag (e.g., nginx:1.27)
+      - namespace/name:tag (e.g., dhi/nginx:1.27)
+      - name@sha256:digest (e.g., nginx@sha256:abc123...)
+
+    When a tag is provided, the digest is resolved from the container registry.
+    Use --platform to select a specific platform manifest when the image is a multi-platform index.
+
+    Attestations are retrieved via the OCI Referrers API from the Docker Scout referrer registry.
+
+    Examples:
+      # List attestations for an image by tag
+      docker dhi attestation list dhi/nginx:1.27
+
+      # List attestations for a specific platform
+      docker dhi attestation list dhi/nginx:1.27 --platform linux/amd64
+
+      # List attestations for an image by digest
+      docker dhi attestation list dhi/nginx@sha256:abc123...
+
+      # Filter by predicate type
+      docker dhi attestation list dhi/nginx:1.27 --predicate-type https://spdx.dev/Document
+
+      # Filter by multiple predicate types
+      docker dhi attestation list dhi/nginx:1.27 --predicate-type https://spdx.dev/Document --predicate-type https://slsa.dev/provenance/v1
+
+      # Output in JSON format
+      docker dhi attestation list dhi/nginx:1.27 --json
+usage: docker dhi attestation list <image>
+pname: docker dhi attestation
+plink: docker_dhi_attestation.yaml
+options:
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: platform
+      value_type: string
+      description: |
+        Platform to filter by (e.g., linux/amd64). Defaults to the Docker daemon platform
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: predicate-type
+      value_type: stringArray
+      default_value: '[]'
+      description: Filter by predicate type (can be specified multiple times)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/dhi/docker_dhi_attestation_sbom.yaml b/data/cli/dhi/docker_dhi_attestation_sbom.yaml
new file mode 100644
index 000000000000..8938ee07a1f7
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_attestation_sbom.yaml
@@ -0,0 +1,50 @@
+command: docker dhi attestation sbom
+short: Display the SPDX SBOM for a Docker Hardened Image
+long: |-
+    Display the SPDX SBOM attestation attached to a Docker Hardened Image
+    in a human-readable format.
+
+    The command fetches the SPDX SBOM attestation from the OCI Referrers API,
+    extracts the SPDX document, and displays a summary with a package table.
+
+    The image can be specified as:
+      - name:tag (e.g., nginx:1.27)
+      - namespace/name:tag (e.g., dhi/nginx:1.27)
+      - name@sha256:digest (e.g., nginx@sha256:abc123...)
+
+    Examples:
+      # Display the SBOM for an image
+      docker dhi attestation sbom dhi/nginx:1.27
+
+      # Display the SBOM for a specific platform
+      docker dhi attestation sbom dhi/nginx:1.27 --platform linux/amd64
+usage: docker dhi attestation sbom <image>
+pname: docker dhi attestation
+plink: docker_dhi_attestation.yaml
+options:
+    - option: platform
+      value_type: string
+      description: |
+        Platform to filter by (e.g., linux/amd64). Defaults to the Docker daemon platform
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/dhi/docker_dhi_auth.yaml b/data/cli/dhi/docker_dhi_auth.yaml
new file mode 100644
index 000000000000..27dee8b87229
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_auth.yaml
@@ -0,0 +1,18 @@
+command: docker dhi auth
+short: Authenticate with Docker Hub
+long: Commands to authenticate with Docker Hub
+pname: docker dhi
+plink: docker_dhi.yaml
+cname:
+    - docker dhi auth apk
+    - docker dhi auth deb
+clink:
+    - docker_dhi_auth_apk.yaml
+    - docker_dhi_auth_deb.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_auth_apk.yaml b/data/cli/dhi/docker_dhi_auth_apk.yaml
new file mode 100644
index 000000000000..6eed620942a0
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_auth_apk.yaml
@@ -0,0 +1,13 @@
+command: docker dhi auth apk
+short: Create authentication details for DHI APK repositories
+long: Create authentication details for DHI APK repositories
+usage: docker dhi auth apk
+pname: docker dhi auth
+plink: docker_dhi_auth.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_auth_deb.yaml b/data/cli/dhi/docker_dhi_auth_deb.yaml
new file mode 100644
index 000000000000..2d3de88303b3
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_auth_deb.yaml
@@ -0,0 +1,13 @@
+command: docker dhi auth deb
+short: Create authentication details for DHI DEB repositories
+long: Create authentication details for DHI DEB repositories
+usage: docker dhi auth deb
+pname: docker dhi auth
+plink: docker_dhi_auth.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_catalog.yaml b/data/cli/dhi/docker_dhi_catalog.yaml
new file mode 100644
index 000000000000..ab3c3b720501
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_catalog.yaml
@@ -0,0 +1,28 @@
+command: docker dhi catalog
+short: Browse the Docker Hardened Images catalog
+long: Commands to browse available Docker Hardened Images and Helm charts
+pname: docker dhi
+plink: docker_dhi.yaml
+cname:
+    - docker dhi catalog get
+    - docker dhi catalog list
+clink:
+    - docker_dhi_catalog_get.yaml
+    - docker_dhi_catalog_list.yaml
+options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_catalog_get.yaml b/data/cli/dhi/docker_dhi_catalog_get.yaml
new file mode 100644
index 000000000000..9bbdd17ca611
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_catalog_get.yaml
@@ -0,0 +1,35 @@
+command: docker dhi catalog get
+short: Get details of a Docker Hardened Image
+long: |
+    Get detailed information about a Docker Hardened Image or Helm chart, including available tags and CVE counts
+usage: docker dhi catalog get <name>
+pname: docker dhi catalog
+plink: docker_dhi_catalog.yaml
+options:
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_catalog_list.yaml b/data/cli/dhi/docker_dhi_catalog_list.yaml
new file mode 100644
index 000000000000..a98e2625d1e6
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_catalog_list.yaml
@@ -0,0 +1,73 @@
+command: docker dhi catalog list
+short: List available Docker Hardened Images
+long: List all available Docker Hardened Images and Helm charts in the catalog
+usage: docker dhi catalog list
+pname: docker dhi catalog
+plink: docker_dhi_catalog.yaml
+options:
+    - option: filter
+      shorthand: f
+      value_type: string
+      description: Filter by name (case-insensitive substring match)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: fips
+      value_type: bool
+      default_value: "false"
+      description: Filter to FIPS compliant images (use --fips=false to exclude)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: stig
+      value_type: bool
+      default_value: "false"
+      description: Filter to STIG certified images (use --stig=false to exclude)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: type
+      value_type: string
+      description: Filter by type (image, helm, chart, or helm-chart)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_customization.yaml b/data/cli/dhi/docker_dhi_customization.yaml
new file mode 100644
index 000000000000..48117cd15dc3
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_customization.yaml
@@ -0,0 +1,40 @@
+command: docker dhi customization
+aliases: docker dhi customization, docker dhi c, docker dhi custo
+short: Manage Docker Hardened Images customizations
+long: |
+    Commands to list, create, edit, and delete Docker Hardened Images customizations
+pname: docker dhi
+plink: docker_dhi.yaml
+cname:
+    - docker dhi customization build
+    - docker dhi customization create
+    - docker dhi customization delete
+    - docker dhi customization edit
+    - docker dhi customization get
+    - docker dhi customization list
+    - docker dhi customization prepare
+clink:
+    - docker_dhi_customization_build.yaml
+    - docker_dhi_customization_create.yaml
+    - docker_dhi_customization_delete.yaml
+    - docker_dhi_customization_edit.yaml
+    - docker_dhi_customization_get.yaml
+    - docker_dhi_customization_list.yaml
+    - docker_dhi_customization_prepare.yaml
+options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_customization_build.yaml b/data/cli/dhi/docker_dhi_customization_build.yaml
new file mode 100644
index 000000000000..5cab2fd36f7b
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_customization_build.yaml
@@ -0,0 +1,30 @@
+command: docker dhi customization build
+short: Manage customization builds
+long: Commands to manage Docker Hardened Images customization builds
+pname: docker dhi customization
+plink: docker_dhi_customization.yaml
+cname:
+    - docker dhi customization build get
+    - docker dhi customization build list
+    - docker dhi customization build logs
+clink:
+    - docker_dhi_customization_build_get.yaml
+    - docker_dhi_customization_build_list.yaml
+    - docker_dhi_customization_build_logs.yaml
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_customization_build_get.yaml b/data/cli/dhi/docker_dhi_customization_build_get.yaml
new file mode 100644
index 000000000000..5c4555040da8
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_customization_build_get.yaml
@@ -0,0 +1,35 @@
+command: docker dhi customization build get
+short: Get details of a build
+long: |
+    Get detailed information about a Docker Hardened Images customization build
+usage: docker dhi customization build get <customization-id> <build-id>
+pname: docker dhi customization build
+plink: docker_dhi_customization_build.yaml
+options:
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_customization_build_list.yaml b/data/cli/dhi/docker_dhi_customization_build_list.yaml
new file mode 100644
index 000000000000..e98e5e59fda4
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_customization_build_list.yaml
@@ -0,0 +1,34 @@
+command: docker dhi customization build list
+short: List builds of a customization
+long: List all builds of a Docker Hardened Images customization by its ID
+usage: docker dhi customization build list <customization-id>
+pname: docker dhi customization build
+plink: docker_dhi_customization_build.yaml
+options:
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_customization_build_logs.yaml b/data/cli/dhi/docker_dhi_customization_build_logs.yaml
new file mode 100644
index 000000000000..88b24c351319
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_customization_build_logs.yaml
@@ -0,0 +1,34 @@
+command: docker dhi customization build logs
+short: Get logs of a build
+long: Get the logs of a Docker Hardened Images customization build
+usage: docker dhi customization build logs <customization-id> <build-id>
+pname: docker dhi customization build
+plink: docker_dhi_customization_build.yaml
+options:
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_customization_create.yaml b/data/cli/dhi/docker_dhi_customization_create.yaml
new file mode 100644
index 000000000000..7207487a8af0
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_customization_create.yaml
@@ -0,0 +1,69 @@
+command: docker dhi customization create
+short: Create a new customization from YAML file
+long: |-
+    Create a new Docker Hardened Images customization using a YAML file as input.
+    The file should contain the complete customization structure without an 'id' field.
+
+    Flags can override values from the YAML file (see --help for details).
+    Shell completions are available for --destination and --tag-definition-id flags.
+    Run 'docker dhi completion --help' to set up shell completions.
+usage: docker dhi customization create <file>
+pname: docker dhi customization
+plink: docker_dhi_customization.yaml
+options:
+    - option: destination
+      shorthand: d
+      value_type: string
+      description: Override the destination repository (e.g. myorg/dhi-golang)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: name
+      shorthand: "n"
+      value_type: string
+      description: Override the customization name from the YAML file
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tag-definition-id
+      shorthand: t
+      value_type: string
+      description: Override the tag definition ID (single-target only)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/dhi/docker_dhi_customization_delete.yaml b/data/cli/dhi/docker_dhi_customization_delete.yaml
new file mode 100644
index 000000000000..4fb69b2f6ba9
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_customization_delete.yaml
@@ -0,0 +1,47 @@
+command: docker dhi customization delete
+short: Delete one or more customizations
+long: |-
+    Delete one or more Docker Hardened Images customizations by their IDs.
+
+    Multiple IDs can be specified as positional arguments.
+
+    Examples:
+      # Delete a single customization
+      docker dhi customization delete abc123
+
+      # Delete multiple customizations
+      docker dhi customization delete abc123 def456 ghi789
+
+      # Delete without confirmation prompt
+      docker dhi customization delete abc123 def456 --force
+usage: docker dhi customization delete <id> [id...]
+pname: docker dhi customization
+plink: docker_dhi_customization.yaml
+options:
+    - option: force
+      shorthand: f
+      value_type: bool
+      default_value: "false"
+      description: Skip the confirmation prompt; aborts if any ID does not exist
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/dhi/docker_dhi_customization_edit.yaml b/data/cli/dhi/docker_dhi_customization_edit.yaml
new file mode 100644
index 000000000000..139bc474b46d
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_customization_edit.yaml
@@ -0,0 +1,36 @@
+command: docker dhi customization edit
+aliases: docker dhi customization edit, docker dhi customization update
+short: Edit an existing customization from YAML file
+long: |
+    Edit an existing Docker Hardened Images customization using a YAML file as input. The file should contain the complete customization structure with an 'id' field to identify which customization to update.
+usage: docker dhi customization edit <file>
+pname: docker dhi customization
+plink: docker_dhi_customization.yaml
+options:
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_customization_get.yaml b/data/cli/dhi/docker_dhi_customization_get.yaml
new file mode 100644
index 000000000000..22035d4dca27
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_customization_get.yaml
@@ -0,0 +1,23 @@
+command: docker dhi customization get
+short: Get details of a specific customization
+long: |
+    Get detailed information about a Docker Hardened Images customization by its ID.
+usage: docker dhi customization get <id>
+pname: docker dhi customization
+plink: docker_dhi_customization.yaml
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/dhi/docker_dhi_customization_list.yaml b/data/cli/dhi/docker_dhi_customization_list.yaml
new file mode 100644
index 000000000000..bf714d6e140a
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_customization_list.yaml
@@ -0,0 +1,73 @@
+command: docker dhi customization list
+short: List all customizations
+long: List all Docker Hardened Images customizations
+usage: docker dhi customization list
+pname: docker dhi customization
+plink: docker_dhi_customization.yaml
+options:
+    - option: bulk-id
+      value_type: string
+      description: Filter by bulk customization ID (exact match)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: filter
+      shorthand: f
+      value_type: string
+      description: Filter by customization name (case-insensitive substring match)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: repo
+      shorthand: r
+      value_type: string
+      description: |
+        Filter by destination repository (case-insensitive substring match)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: source
+      value_type: string
+      description: Filter by DHI source repository (case-insensitive substring match)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_customization_prepare.yaml b/data/cli/dhi/docker_dhi_customization_prepare.yaml
new file mode 100644
index 000000000000..5f5a552ce6ab
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_customization_prepare.yaml
@@ -0,0 +1,58 @@
+command: docker dhi customization prepare
+short: Prepare a new customization YAML file from a DHI base image tag
+long: |-
+    Prepare a new single or bulk customization YAML file by fetching tag details from Docker Hardened Images.
+    This creates a scaffold YAML file that can be used with the create command.
+
+    Single customization — provide the DHI source repository and tag as positional arguments:
+      docker dhi customization prepare golang 1.24-dev --destination myorg/dhi-golang
+
+    Bulk customization — pipe a JSON array of {destination, tag-definition-id} objects via stdin:
+      echo '[{"destination":"myorg/dhi-golang","tag-definition-id":"golang/alpine-3.23/1.24-dev"}]' \
+        | docker dhi customization prepare --name my-custo
+
+    The scaffold is written to stdout; redirect to a file if needed:
+      docker dhi customization prepare golang 1.24-dev > customization.yaml
+
+    Run 'docker dhi customization list' to see available source repositories,
+    or use shell completion to discover repository names and tags.
+usage: docker dhi customization prepare <dhi-repository> <tag>
+pname: docker dhi customization
+plink: docker_dhi_customization.yaml
+options:
+    - option: destination
+      shorthand: d
+      value_type: string
+      description: Destination repository (e.g. myorg/dhi-golang)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: name
+      shorthand: "n"
+      value_type: string
+      description: Name for the customization
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/dhi/docker_dhi_mirror.yaml b/data/cli/dhi/docker_dhi_mirror.yaml
new file mode 100644
index 000000000000..2df250c938c4
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_mirror.yaml
@@ -0,0 +1,30 @@
+command: docker dhi mirror
+short: Mirror Docker Hardened Images to your organization
+long: Commands to mirror Docker Hardened Images to your organization's registry
+pname: docker dhi
+plink: docker_dhi.yaml
+cname:
+    - docker dhi mirror list
+    - docker dhi mirror start
+    - docker dhi mirror stop
+clink:
+    - docker_dhi_mirror_list.yaml
+    - docker_dhi_mirror_start.yaml
+    - docker_dhi_mirror_stop.yaml
+options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_mirror_list.yaml b/data/cli/dhi/docker_dhi_mirror_list.yaml
new file mode 100644
index 000000000000..cb3cb21b0843
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_mirror_list.yaml
@@ -0,0 +1,72 @@
+command: docker dhi mirror list
+short: List all mirrored Docker Hardened Images
+long: |-
+    List all Docker Hardened Images currently being mirrored to your organization's registry.
+
+    Shows the source repositories, destination repositories, and mirroring status.
+
+    Examples:
+      # List all mirrored repositories
+      docker dhi mirror list --org myorg
+
+      # List only image repositories
+      docker dhi mirror list --org myorg --type image
+
+      # List only helm chart repositories
+      docker dhi mirror list --org myorg --type helm-chart
+
+      # Search for a specific repository by name
+      docker dhi mirror list --org myorg --filter dhi-python
+
+      # Output in JSON format
+      docker dhi mirror list --org myorg --json
+usage: docker dhi mirror list
+pname: docker dhi mirror
+plink: docker_dhi_mirror.yaml
+options:
+    - option: filter
+      shorthand: f
+      value_type: string
+      description: Filter by repository name (partial match)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: type
+      value_type: string
+      description: Filter by repository type (image or helm-chart)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/dhi/docker_dhi_mirror_start.yaml b/data/cli/dhi/docker_dhi_mirror_start.yaml
new file mode 100644
index 000000000000..5dc5e7bb7674
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_mirror_start.yaml
@@ -0,0 +1,60 @@
+command: docker dhi mirror start
+short: Start mirroring Docker Hardened Images
+long: |-
+    Start mirroring one or more Docker Hardened Images to your organization's registry.
+
+    Repository mappings are specified as arguments. The following formats are supported:
+
+      source                  Only the source repository; destination is auto-generated as
+                              <org>/dhi-<source-name>
+      source,destination      Source and destination; the destination namespace is filled from config if omitted
+      ns/source,ns/dest       Fully qualified source and destination
+
+    The source namespace defaults to "dhi" when not specified.
+    The destination namespace defaults to the configured organization (--org or config).
+
+    Examples:
+      docker dhi mirror start --org myorg dhi/golang,myorg/dhi-golang dhi/node,myorg/dhi-node
+      docker dhi mirror start --org myorg golang,dhi-golang node,dhi-node
+      docker dhi mirror start --org myorg golang node
+usage: docker dhi mirror start
+pname: docker dhi mirror
+plink: docker_dhi_mirror.yaml
+options:
+    - option: dependencies
+      shorthand: d
+      value_type: bool
+      default_value: "false"
+      description: Mirrors any existing dependencies
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Output in JSON format
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/dhi/docker_dhi_mirror_stop.yaml b/data/cli/dhi/docker_dhi_mirror_stop.yaml
new file mode 100644
index 000000000000..ce69dd0db39e
--- /dev/null
+++ b/data/cli/dhi/docker_dhi_mirror_stop.yaml
@@ -0,0 +1,72 @@
+command: docker dhi mirror stop
+short: Stop mirroring one or more Docker Hardened Images
+long: |-
+    Stop mirroring one or more Docker Hardened Image repositories.
+
+    Multiple repositories can be specified as positional arguments.
+
+    Each repository can be specified as:
+      - namespace/name (e.g., myorg/dhi-python) - org must match --org flag or config
+      - name only (e.g., dhi-python) - the namespace can be omitted for simplicity
+        and the command will default to the current org automatically
+
+    Examples:
+      # Stop mirroring a single repository
+      docker dhi mirror stop myorg/dhi-python --org myorg
+
+      # Stop mirroring using just the name (defaults to current org)
+      docker dhi mirror stop dhi-python --org myorg
+
+      # Stop mirroring multiple repositories
+      docker dhi mirror stop dhi-python dhi-golang dhi-node --org myorg
+
+      # Stop mirroring and delete the repositories
+      docker dhi mirror stop dhi-python dhi-golang --org myorg --delete
+
+      # Stop mirroring, delete without confirmation prompt
+      docker dhi mirror stop dhi-python dhi-golang --org myorg --delete --force
+
+      # Stop mirroring all repositories matching a filter (using shell substitution)
+      docker dhi mirror stop $(docker dhi mirror list --org myorg --filter golang --json | jq -r '.[].repository') --org myorg
+usage: docker dhi mirror stop <repository> [repository...]
+pname: docker dhi mirror
+plink: docker_dhi_mirror.yaml
+options:
+    - option: delete
+      value_type: bool
+      default_value: "false"
+      description: Delete the repositories after stopping mirroring
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: force
+      shorthand: f
+      value_type: bool
+      default_value: "false"
+      description: Skip confirmation prompt when deleting repositories
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: org
+      value_type: string
+      description: Docker Hub organization (overrides config)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/engine-cli/docker.yaml b/data/cli/engine/docker.yaml
similarity index 96%
rename from data/engine-cli/docker.yaml
rename to data/cli/engine/docker.yaml
index 4f19fed062fd..81db02ea6eb1 100644
--- a/data/engine-cli/docker.yaml
+++ b/data/cli/engine/docker.yaml
@@ -29,16 +29,13 @@ long: |-
 
     ### Environment variables
 
-    The following list of environment variables are supported by the `docker` command
-    line:
+    The following environment variables control the behavior of the `docker` command-line client:
 
     | Variable                      | Description                                                                                                                                                                                                                                                       |
     | :---------------------------- |:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
     | `DOCKER_API_VERSION`          | Override the negotiated API version to use for debugging (e.g. `1.19`)                                                                                                                                                                                            |
     | `DOCKER_CERT_PATH`            | Location of your authentication keys. This variable is used both by the `docker` CLI and the [`dockerd` daemon](/reference/cli/dockerd/)                                                                                                   |
     | `DOCKER_CONFIG`               | The location of your client configuration files.                                                                                                                                                                                                                  |
-    | `DOCKER_CONTENT_TRUST_SERVER` | The URL of the Notary server to use. Defaults to the same URL as the registry.                                                                                                                                                                                    |
-    | `DOCKER_CONTENT_TRUST`        | When set Docker uses notary to sign and verify images. Equates to `--disable-content-trust=false` for build, create, pull, push, run.                                                                                                                             |
     | `DOCKER_CONTEXT`              | Name of the `docker context` to use (overrides `DOCKER_HOST` env var and default context set with `docker context use`)                                                                                                                                           |
     | `DOCKER_CUSTOM_HEADERS`       | (Experimental) Configure [custom HTTP headers](#custom-http-headers) to be sent by the client. Headers must be provided as a comma-separated list of `name=value` pairs. This is the equivalent to the `HttpHeaders` field in the configuration file.             |
     | `DOCKER_DEFAULT_PLATFORM`     | Default platform for commands that take the `--platform` flag.                                                                                                                                                                                                    |
@@ -47,6 +44,8 @@ long: |-
     | `DOCKER_TLS`                  | Enable TLS for connections made by the `docker` CLI (equivalent of the `--tls` command-line option). Set to a non-empty value to enable TLS. Note that TLS is enabled automatically if any of the other TLS options are set.                                      |
     | `DOCKER_TLS_VERIFY`           | When set Docker uses TLS and verifies the remote. This variable is used both by the `docker` CLI and the [`dockerd` daemon](/reference/cli/dockerd/)                                                                                       |
     | `BUILDKIT_PROGRESS`           | Set type of progress output (`auto`, `plain`, `tty`, `rawjson`) when [building](/reference/cli/docker/image/build/) with [BuildKit backend](/build/buildkit/). Use plain to show container output (default `auto`). |
+    | `NO_COLOR`                    | Disable any ANSI escape codes in the output in accordance with https://no-color.org/
+                                                                                                                 |
 
     Because Docker is developed using Go, you can also use any environment
     variables used by the Go runtime. In particular, you may find these useful:
@@ -234,8 +233,8 @@ long: |-
 
     These settings are used to configure proxy settings for containers only, and not
     used as proxy settings for the `docker` CLI or the `dockerd` daemon. Refer to the
-    [environment variables](#environment-variables) and [HTTP/HTTPS proxy](/engine/daemon/proxy/#httphttps-proxy)
-    sections for configuring proxy settings for the CLI and daemon.
+    [environment variables](#environment-variables) section and the [Daemon proxy configuration](/engine/daemon/proxy/)
+    guide for configuring proxy settings for the CLI and daemon.
 
     > [!WARNING]
     > Proxy settings may contain sensitive information (for example, if the proxy
@@ -339,6 +338,7 @@ long: |-
     list of root Certificate Authorities.
 cname:
     - docker attach
+    - docker bake
     - docker build
     - docker builder
     - docker checkpoint
@@ -389,7 +389,6 @@ cname:
     - docker system
     - docker tag
     - docker top
-    - docker trust
     - docker unpause
     - docker update
     - docker version
@@ -397,6 +396,7 @@ cname:
     - docker wait
 clink:
     - docker_attach.yaml
+    - docker_bake.yaml
     - docker_build.yaml
     - docker_builder.yaml
     - docker_checkpoint.yaml
@@ -447,7 +447,6 @@ clink:
     - docker_system.yaml
     - docker_tag.yaml
     - docker_top.yaml
-    - docker_trust.yaml
     - docker_unpause.yaml
     - docker_update.yaml
     - docker_version.yaml
@@ -498,7 +497,7 @@ options:
       swarm: false
     - option: host
       shorthand: H
-      value_type: list
+      value_type: string
       description: Daemon socket to connect to
       details_url: '#host'
       deprecated: false
@@ -576,7 +575,7 @@ examples: |-
 
     | Scheme                                 | Description               | Example                          |
     |----------------------------------------|---------------------------|----------------------------------|
-    | `unix://[<path>]`                      | Unix socket (Linux only)  | `unix:///var/run/docker.sock`    |
+    | `unix://[<path>]`                      | Unix socket               | `unix:///var/run/docker.sock`    |
     | `tcp://[<IP or host>[:port]]`          | TCP connection            | `tcp://174.17.0.1:2376`          |
     | `ssh://[username@]<IP or host>[:port]` | SSH connection            | `ssh://user@192.168.64.5`        |
     | `npipe://[<name>]`                     | Named pipe (Windows only) | `npipe:////./pipe/docker_engine` |
diff --git a/data/engine-cli/docker_attach.yaml b/data/cli/engine/docker_attach.yaml
similarity index 100%
rename from data/engine-cli/docker_attach.yaml
rename to data/cli/engine/docker_attach.yaml
diff --git a/data/cli/engine/docker_bake.yaml b/data/cli/engine/docker_bake.yaml
new file mode 100644
index 000000000000..14f8ab4c6845
--- /dev/null
+++ b/data/cli/engine/docker_bake.yaml
@@ -0,0 +1,26 @@
+command: docker bake
+aliases: docker buildx bake
+short: Build from a file
+long: Build from a file
+usage: docker bake [OPTIONS] [TARGET...]
+pname: docker
+plink: docker.yaml
+inherited_options:
+    - option: help
+      value_type: bool
+      default_value: "false"
+      description: Print usage
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+min_api_version: "1.31"
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/engine-cli/docker_build.yaml b/data/cli/engine/docker_build.yaml
similarity index 98%
rename from data/engine-cli/docker_build.yaml
rename to data/cli/engine/docker_build.yaml
index 6cc13ead6f70..fc9886436827 100644
--- a/data/engine-cli/docker_build.yaml
+++ b/data/cli/engine/docker_build.yaml
@@ -108,9 +108,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image verification
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
diff --git a/data/engine-cli/docker_builder.yaml b/data/cli/engine/docker_builder.yaml
similarity index 100%
rename from data/engine-cli/docker_builder.yaml
rename to data/cli/engine/docker_builder.yaml
diff --git a/data/engine-cli/docker_builder_build.yaml b/data/cli/engine/docker_builder_build.yaml
similarity index 98%
rename from data/engine-cli/docker_builder_build.yaml
rename to data/cli/engine/docker_builder_build.yaml
index 1a8075d93d2c..c1a67392e7e6 100644
--- a/data/engine-cli/docker_builder_build.yaml
+++ b/data/cli/engine/docker_builder_build.yaml
@@ -109,9 +109,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image verification
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
diff --git a/data/engine-cli/docker_builder_prune.yaml b/data/cli/engine/docker_builder_prune.yaml
similarity index 100%
rename from data/engine-cli/docker_builder_prune.yaml
rename to data/cli/engine/docker_builder_prune.yaml
diff --git a/data/engine-cli/docker_checkpoint.yaml b/data/cli/engine/docker_checkpoint.yaml
similarity index 100%
rename from data/engine-cli/docker_checkpoint.yaml
rename to data/cli/engine/docker_checkpoint.yaml
diff --git a/data/engine-cli/docker_checkpoint_create.yaml b/data/cli/engine/docker_checkpoint_create.yaml
similarity index 100%
rename from data/engine-cli/docker_checkpoint_create.yaml
rename to data/cli/engine/docker_checkpoint_create.yaml
diff --git a/data/engine-cli/docker_checkpoint_ls.yaml b/data/cli/engine/docker_checkpoint_ls.yaml
similarity index 100%
rename from data/engine-cli/docker_checkpoint_ls.yaml
rename to data/cli/engine/docker_checkpoint_ls.yaml
diff --git a/data/engine-cli/docker_checkpoint_rm.yaml b/data/cli/engine/docker_checkpoint_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_checkpoint_rm.yaml
rename to data/cli/engine/docker_checkpoint_rm.yaml
diff --git a/data/engine-cli/docker_commit.yaml b/data/cli/engine/docker_commit.yaml
similarity index 82%
rename from data/engine-cli/docker_commit.yaml
rename to data/cli/engine/docker_commit.yaml
index c86e3d2deef8..c5490e67b06a 100644
--- a/data/engine-cli/docker_commit.yaml
+++ b/data/cli/engine/docker_commit.yaml
@@ -36,13 +36,23 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: no-pause
+      value_type: bool
+      default_value: "false"
+      description: Disable pausing container during commit
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: pause
       shorthand: p
       value_type: bool
       default_value: "true"
-      description: Pause container during commit
-      deprecated: false
-      hidden: false
+      description: 'Pause container during commit (deprecated: use --no-pause instead)'
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
diff --git a/data/engine-cli/docker_config.yaml b/data/cli/engine/docker_config.yaml
similarity index 100%
rename from data/engine-cli/docker_config.yaml
rename to data/cli/engine/docker_config.yaml
diff --git a/data/engine-cli/docker_config_create.yaml b/data/cli/engine/docker_config_create.yaml
similarity index 100%
rename from data/engine-cli/docker_config_create.yaml
rename to data/cli/engine/docker_config_create.yaml
diff --git a/data/engine-cli/docker_config_inspect.yaml b/data/cli/engine/docker_config_inspect.yaml
similarity index 100%
rename from data/engine-cli/docker_config_inspect.yaml
rename to data/cli/engine/docker_config_inspect.yaml
diff --git a/data/engine-cli/docker_config_ls.yaml b/data/cli/engine/docker_config_ls.yaml
similarity index 98%
rename from data/engine-cli/docker_config_ls.yaml
rename to data/cli/engine/docker_config_ls.yaml
index bb5842cdbd67..8559f7c5bdc4 100644
--- a/data/engine-cli/docker_config_ls.yaml
+++ b/data/cli/engine/docker_config_ls.yaml
@@ -115,7 +115,7 @@ examples: |-
     `project-a` value.
 
     ```console
-    $ docker service ls --filter label=project=test
+    $ docker config ls --filter label=project=project-a
 
     ID                          NAME                        CREATED             UPDATED
     mem02h8n73mybpgqjf0kfi1n0   test_config                 About an hour ago   About an hour ago
@@ -128,7 +128,7 @@ examples: |-
     The following filter matches config with a name containing a prefix of `test`.
 
     ```console
-    $ docker config ls --filter name=test_config
+    $ docker config ls --filter name=test
 
     ID                          NAME                        CREATED             UPDATED
     mem02h8n73mybpgqjf0kfi1n0   test_config                 About an hour ago   About an hour ago
diff --git a/data/engine-cli/docker_config_rm.yaml b/data/cli/engine/docker_config_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_config_rm.yaml
rename to data/cli/engine/docker_config_rm.yaml
diff --git a/data/engine-cli/docker_container.yaml b/data/cli/engine/docker_container.yaml
similarity index 100%
rename from data/engine-cli/docker_container.yaml
rename to data/cli/engine/docker_container.yaml
diff --git a/data/engine-cli/docker_container_attach.yaml b/data/cli/engine/docker_container_attach.yaml
similarity index 100%
rename from data/engine-cli/docker_container_attach.yaml
rename to data/cli/engine/docker_container_attach.yaml
diff --git a/data/engine-cli/docker_container_commit.yaml b/data/cli/engine/docker_container_commit.yaml
similarity index 93%
rename from data/engine-cli/docker_container_commit.yaml
rename to data/cli/engine/docker_container_commit.yaml
index 0f9397187798..523e7d9e4e0f 100644
--- a/data/engine-cli/docker_container_commit.yaml
+++ b/data/cli/engine/docker_container_commit.yaml
@@ -51,13 +51,23 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: no-pause
+      value_type: bool
+      default_value: "false"
+      description: Disable pausing container during commit
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: pause
       shorthand: p
       value_type: bool
       default_value: "true"
-      description: Pause container during commit
-      deprecated: false
-      hidden: false
+      description: 'Pause container during commit (deprecated: use --no-pause instead)'
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
diff --git a/data/engine-cli/docker_container_cp.yaml b/data/cli/engine/docker_container_cp.yaml
similarity index 99%
rename from data/engine-cli/docker_container_cp.yaml
rename to data/cli/engine/docker_container_cp.yaml
index 3dd4181795fe..5ff5b80eddbd 100644
--- a/data/engine-cli/docker_container_cp.yaml
+++ b/data/cli/engine/docker_container_cp.yaml
@@ -86,7 +86,7 @@ options:
       shorthand: L
       value_type: bool
       default_value: "false"
-      description: Always follow symbol link in SRC_PATH
+      description: Always follow symlinks in SRC_PATH
       deprecated: false
       hidden: false
       experimental: false
diff --git a/data/engine-cli/docker_container_create.yaml b/data/cli/engine/docker_container_create.yaml
similarity index 98%
rename from data/engine-cli/docker_container_create.yaml
rename to data/cli/engine/docker_container_create.yaml
index ed89811b8398..97c3a47b6bfa 100644
--- a/data/engine-cli/docker_container_create.yaml
+++ b/data/cli/engine/docker_container_create.yaml
@@ -290,9 +290,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image verification
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -527,7 +527,8 @@ options:
       swarm: false
       os_type: windows
     - option: ip
-      value_type: string
+      value_type: ip
+      default_value: <nil>
       description: IPv4 address (e.g., 172.30.100.104)
       deprecated: false
       hidden: false
@@ -536,7 +537,8 @@ options:
       kubernetes: false
       swarm: false
     - option: ip6
-      value_type: string
+      value_type: ip
+      default_value: <nil>
       description: IPv6 address (e.g., 2001:db8::33)
       deprecated: false
       hidden: false
@@ -565,9 +567,9 @@ options:
     - option: kernel-memory
       value_type: bytes
       default_value: "0"
-      description: Kernel memory limit
-      deprecated: false
-      hidden: false
+      description: Kernel memory limit (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -825,7 +827,7 @@ options:
     - option: pull
       value_type: string
       default_value: missing
-      description: Pull image before creating (`always`, `|missing`, `never`)
+      description: Pull image before creating (`always`, `missing`, `never`)
       deprecated: false
       hidden: false
       experimental: false
@@ -971,6 +973,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: use-api-socket
+      value_type: bool
+      default_value: "false"
+      description: Bind mount Docker API socket and required auth
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: true
+      kubernetes: false
+      swarm: false
     - option: user
       shorthand: u
       value_type: string
diff --git a/data/engine-cli/docker_container_diff.yaml b/data/cli/engine/docker_container_diff.yaml
similarity index 100%
rename from data/engine-cli/docker_container_diff.yaml
rename to data/cli/engine/docker_container_diff.yaml
diff --git a/data/engine-cli/docker_container_exec.yaml b/data/cli/engine/docker_container_exec.yaml
similarity index 100%
rename from data/engine-cli/docker_container_exec.yaml
rename to data/cli/engine/docker_container_exec.yaml
diff --git a/data/engine-cli/docker_container_export.yaml b/data/cli/engine/docker_container_export.yaml
similarity index 100%
rename from data/engine-cli/docker_container_export.yaml
rename to data/cli/engine/docker_container_export.yaml
diff --git a/data/engine-cli/docker_container_inspect.yaml b/data/cli/engine/docker_container_inspect.yaml
similarity index 100%
rename from data/engine-cli/docker_container_inspect.yaml
rename to data/cli/engine/docker_container_inspect.yaml
diff --git a/data/engine-cli/docker_container_kill.yaml b/data/cli/engine/docker_container_kill.yaml
similarity index 100%
rename from data/engine-cli/docker_container_kill.yaml
rename to data/cli/engine/docker_container_kill.yaml
diff --git a/data/engine-cli/docker_container_logs.yaml b/data/cli/engine/docker_container_logs.yaml
similarity index 90%
rename from data/engine-cli/docker_container_logs.yaml
rename to data/cli/engine/docker_container_logs.yaml
index a920e7251982..971e7e307f37 100644
--- a/data/engine-cli/docker_container_logs.yaml
+++ b/data/cli/engine/docker_container_logs.yaml
@@ -6,34 +6,6 @@ long: |-
 
     For more information about selecting and configuring logging drivers, refer to
     [Configure logging drivers](/engine/logging/configure/).
-
-    The `docker logs --follow` command will continue streaming the new output from
-    the container's `STDOUT` and `STDERR`.
-
-    Passing a negative number or a non-integer to `--tail` is invalid and the
-    value is set to `all` in that case.
-
-    The `docker logs --timestamps` command will add an [RFC3339Nano timestamp](https://pkg.go.dev/time#RFC3339Nano)
-    , for example `2014-09-16T06:17:46.000000000Z`, to each
-    log entry. To ensure that the timestamps are aligned the
-    nano-second part of the timestamp will be padded with zero when necessary.
-
-    The `docker logs --details` command will add on extra attributes, such as
-    environment variables and labels, provided to `--log-opt` when creating the
-    container.
-
-    The `--since` option shows only the container logs generated after
-    a given date. You can specify the date as an RFC 3339 date, a UNIX
-    timestamp, or a Go duration string (e.g. `1m30s`, `3h`). Besides RFC3339 date
-    format you may also use RFC3339Nano, `2006-01-02T15:04:05`,
-    `2006-01-02T15:04:05.999999999`, `2006-01-02T07:00`, and `2006-01-02`. The local
-    timezone on the client will be used if you do not provide either a `Z` or a
-    `+-00:00` timezone offset at the end of the timestamp. When providing Unix
-    timestamps enter seconds[.nanoseconds], where seconds is the number of seconds
-    that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap
-    seconds (aka Unix epoch or Unix time), and the optional .nanoseconds field is a
-    fraction of a second no more than nine digits long. You can combine the
-    `--since` option with either or both of the `--follow` or `--tail` options.
 usage: docker container logs [OPTIONS] CONTAINER
 pname: docker container
 plink: docker_container.yaml
@@ -42,6 +14,7 @@ options:
       value_type: bool
       default_value: "false"
       description: Show extra details provided to logs
+      details_url: '#details'
       deprecated: false
       hidden: false
       experimental: false
@@ -53,6 +26,7 @@ options:
       value_type: bool
       default_value: "false"
       description: Follow log output
+      details_url: '#follow'
       deprecated: false
       hidden: false
       experimental: false
@@ -63,6 +37,7 @@ options:
       value_type: string
       description: |
         Show logs since timestamp (e.g. `2013-01-02T13:23:37Z`) or relative (e.g. `42m` for 42 minutes)
+      details_url: '#since'
       deprecated: false
       hidden: false
       experimental: false
@@ -74,6 +49,7 @@ options:
       value_type: string
       default_value: all
       description: Number of lines to show from the end of the logs
+      details_url: '#tail'
       deprecated: false
       hidden: false
       experimental: false
@@ -85,6 +61,7 @@ options:
       value_type: bool
       default_value: "false"
       description: Show timestamps
+      details_url: '#timestamps'
       deprecated: false
       hidden: false
       experimental: false
@@ -115,6 +92,46 @@ inherited_options:
       kubernetes: false
       swarm: false
 examples: |-
+    ### Stream log output  (-f, --follow) {#follow}
+
+    The `docker logs --follow` command will continue streaming the new output from
+    the container's `STDOUT` and `STDERR`.
+
+    ### Retrieve the last logs (-n, --tail) {#tail}
+
+    Passing a negative number or a non-integer to `--tail` is invalid and the
+    value is set to `all` in that case.
+
+
+    ### Retrieve logs with timestamps (-t, --timestamps) {#timestamps}
+
+    The `docker logs --timestamps` command will add an [RFC3339Nano timestamp](https://pkg.go.dev/time#RFC3339Nano)
+    , for example `2014-09-16T06:17:46.000000000Z`, to each
+    log entry. To ensure that the timestamps are aligned the
+    nano-second part of the timestamp will be padded with zero when necessary.
+
+    ### Retrieve logs with additional attributes (--details) {#details}
+
+    The `docker logs --details` command will add on extra attributes, such as
+    environment variables and labels, provided to `--log-opt` when creating the
+    container.
+
+    ### Retrieve logs generated since a specific point in time (--since) {#since}
+
+    The `--since` option shows only the container logs generated after
+    a given date. You can specify the date as an RFC 3339 date, a UNIX
+    timestamp, or a Go duration string (e.g. `1m30s`, `3h`). Besides RFC3339 date
+    format you may also use RFC3339Nano, `2006-01-02T15:04:05`,
+    `2006-01-02T15:04:05.999999999`, `2006-01-02T07:00`, and `2006-01-02`. The local
+    timezone on the client will be used if you do not provide either a `Z` or a
+    `+-00:00` timezone offset at the end of the timestamp. When providing Unix
+    timestamps enter seconds[.nanoseconds], where seconds is the number of seconds
+    that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap
+    seconds (aka Unix epoch or Unix time), and the optional .nanoseconds field is a
+    fraction of a second no more than nine digits long. You can combine the
+    `--since` option with either or both of the `--follow` or `--tail` options.
+
+
     ### Retrieve logs until a specific point in time (--until) {#until}
 
     In order to retrieve logs before a specific point in time, run:
diff --git a/data/engine-cli/docker_container_ls.yaml b/data/cli/engine/docker_container_ls.yaml
similarity index 92%
rename from data/engine-cli/docker_container_ls.yaml
rename to data/cli/engine/docker_container_ls.yaml
index e61f3fd39528..24648b6f9400 100644
--- a/data/engine-cli/docker_container_ls.yaml
+++ b/data/cli/engine/docker_container_ls.yaml
@@ -216,7 +216,7 @@ examples: |-
     9b6247364a03        busybox             "top"               2 minutes ago       Up 2 minutes                            nostalgic_stallman
     ```
 
-    You can also filter for a substring in a name as this shows:
+    You can filter for a substring in a name as this shows:
 
     ```console
     $ docker ps --filter "name=nostalgic"
@@ -483,22 +483,23 @@ examples: |-
 
     Valid placeholders for the Go template are listed below:
 
-    | Placeholder   | Description                                                                                     |
-    |:--------------|:------------------------------------------------------------------------------------------------|
-    | `.ID`         | Container ID                                                                                    |
-    | `.Image`      | Image ID                                                                                        |
-    | `.Command`    | Quoted command                                                                                  |
-    | `.CreatedAt`  | Time when the container was created.                                                            |
-    | `.RunningFor` | Elapsed time since the container was started.                                                   |
-    | `.Ports`      | Exposed ports.                                                                                  |
-    | `.State`      | Container status (for example; "created", "running", "exited").                                 |
-    | `.Status`     | Container status with details about duration and health-status.                                 |
-    | `.Size`       | Container disk size.                                                                            |
-    | `.Names`      | Container names.                                                                                |
-    | `.Labels`     | All labels assigned to the container.                                                           |
-    | `.Label`      | Value of a specific label for this container. For example `'{{.Label "com.docker.swarm.cpu"}}'` |
-    | `.Mounts`     | Names of the volumes mounted in this container.                                                 |
-    | `.Networks`   | Names of the networks attached to this container.                                               |
+    | Placeholder     | Description                                                                                     |
+    |:----------------|:------------------------------------------------------------------------------------------------|
+    | `.ID`           | Container ID                                                                                    |
+    | `.Image`        | Image ID                                                                                        |
+    | `.Command`      | Quoted command                                                                                  |
+    | `.CreatedAt`    | Time when the container was created.                                                            |
+    | `.RunningFor`   | Elapsed time since the container was started.                                                   |
+    | `.Ports`        | Exposed ports.                                                                                  |
+    | `.State`        | Container status (for example; "created", "running", "exited").                                 |
+    | `.Status`       | Container status with details about duration and health-status.                                 |
+    | `.HealthStatus` | Container health status ("starting", "healthy", "unhealthy"; empty when unavailable).           |
+    | `.Size`         | Container disk size.                                                                            |
+    | `.Names`        | Container names.                                                                                |
+    | `.Labels`       | All labels assigned to the container.                                                           |
+    | `.Label`        | Value of a specific label for this container. For example `'{{.Label "com.docker.swarm.cpu"}}'` |
+    | `.Mounts`       | Names of the volumes mounted in this container.                                                 |
+    | `.Networks`     | Names of the networks attached to this container.                                               |
 
     When using the `--format` option, the `ps` command will either output the data
     exactly as the template declares or, when using the `table` directive, includes
diff --git a/data/engine-cli/docker_container_pause.yaml b/data/cli/engine/docker_container_pause.yaml
similarity index 100%
rename from data/engine-cli/docker_container_pause.yaml
rename to data/cli/engine/docker_container_pause.yaml
diff --git a/data/engine-cli/docker_container_port.yaml b/data/cli/engine/docker_container_port.yaml
similarity index 100%
rename from data/engine-cli/docker_container_port.yaml
rename to data/cli/engine/docker_container_port.yaml
diff --git a/data/engine-cli/docker_container_prune.yaml b/data/cli/engine/docker_container_prune.yaml
similarity index 88%
rename from data/engine-cli/docker_container_prune.yaml
rename to data/cli/engine/docker_container_prune.yaml
index c595b3e6f867..469a7f72ddef 100644
--- a/data/engine-cli/docker_container_prune.yaml
+++ b/data/cli/engine/docker_container_prune.yaml
@@ -54,7 +54,19 @@ examples: |-
     ### Filtering (--filter) {#filter}
 
     The filtering flag (`--filter`) format is of "key=value". If there is more
-    than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`)
+    than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`).
+
+    When multiple filters are provided, they are combined as follows:
+
+    - Multiple filters with **different keys** are combined using AND logic.
+      A container must satisfy all filter conditions to be pruned.
+    - Multiple filters with the **same key** are combined using OR logic.
+      A container is pruned if it matches any of the values for that key.
+
+    For example, `--filter "label=foo" --filter "until=24h"` prunes containers
+    that have the `foo` label **and** were created more than 24 hours ago.
+    Conversely, `--filter "label=foo" --filter "label=bar"` prunes containers
+    that have **either** the `foo` **or** `bar` label.
 
     The currently supported filters are:
 
diff --git a/data/engine-cli/docker_container_rename.yaml b/data/cli/engine/docker_container_rename.yaml
similarity index 100%
rename from data/engine-cli/docker_container_rename.yaml
rename to data/cli/engine/docker_container_rename.yaml
diff --git a/data/engine-cli/docker_container_restart.yaml b/data/cli/engine/docker_container_restart.yaml
similarity index 100%
rename from data/engine-cli/docker_container_restart.yaml
rename to data/cli/engine/docker_container_restart.yaml
diff --git a/data/engine-cli/docker_container_rm.yaml b/data/cli/engine/docker_container_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_container_rm.yaml
rename to data/cli/engine/docker_container_rm.yaml
diff --git a/data/engine-cli/docker_container_run.yaml b/data/cli/engine/docker_container_run.yaml
similarity index 98%
rename from data/engine-cli/docker_container_run.yaml
rename to data/cli/engine/docker_container_run.yaml
index 913e4978f3d9..1d8363edbf47 100644
--- a/data/engine-cli/docker_container_run.yaml
+++ b/data/cli/engine/docker_container_run.yaml
@@ -305,9 +305,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image verification
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -546,7 +546,8 @@ options:
       swarm: false
       os_type: windows
     - option: ip
-      value_type: string
+      value_type: ip
+      default_value: <nil>
       description: IPv4 address (e.g., 172.30.100.104)
       deprecated: false
       hidden: false
@@ -555,7 +556,8 @@ options:
       kubernetes: false
       swarm: false
     - option: ip6
-      value_type: string
+      value_type: ip
+      default_value: <nil>
       description: IPv6 address (e.g., 2001:db8::33)
       deprecated: false
       hidden: false
@@ -586,9 +588,9 @@ options:
     - option: kernel-memory
       value_type: bytes
       default_value: "0"
-      description: Kernel memory limit
-      deprecated: false
-      hidden: false
+      description: Kernel memory limit (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -1024,6 +1026,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: use-api-socket
+      value_type: bool
+      default_value: "false"
+      description: Bind mount Docker API socket and required auth
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: user
       shorthand: u
       value_type: string
@@ -1356,7 +1368,7 @@ examples: |-
     ### Set working directory (-w, --workdir) {#workdir}
 
     ```console
-    $ docker run -w /path/to/dir/ -i -t ubuntu pwd
+    $ docker run -w /path/to/dir/ ubuntu pwd
     ```
 
     The `-w` option runs the command executed inside the directory specified, in this example,
@@ -1905,15 +1917,14 @@ examples: |-
 
     #### CDI devices
 
-    > [!NOTE]
-    > The CDI feature is experimental, and potentially subject to change.
-    > CDI is currently only supported for Linux containers.
-
     [Container Device Interface
     (CDI)](https://github.com/cncf-tags/container-device-interface/blob/main/SPEC.md)
     is a standardized mechanism for container runtimes to create containers which
     are able to interact with third party devices.
 
+    CDI is currently only supported for Linux containers and is enabled by default
+    since Docker Engine 28.3.0.
+
     With CDI, device configurations are declaratively defined using a JSON or YAML
     file. In addition to enabling the container to interact with the device node,
     it also lets you specify additional configuration for the device, such as
@@ -1934,7 +1945,7 @@ examples: |-
       available on the system running the daemon, in one of the configured CDI
       specification directories.
     - The CDI feature has been enabled in the daemon; see [Enable CDI
-      devices](/reference/cli/dockerd/#enable-cdi-devices).
+      devices](/reference/cli/dockerd/#configure-cdi-devices).
 
     ### Attach to STDIN/STDOUT/STDERR (-a, --attach) {#attach}
 
@@ -2204,7 +2215,7 @@ examples: |-
     `--rm` flag:
 
     ```text
-    --rm: Automatically remove the container when it exits
+    --rm: Automatically remove the container and its associated anonymous volumes when it exits
     ```
 
     > [!NOTE]
@@ -2253,7 +2264,9 @@ examples: |-
 
     It's conventional to use `host.docker.internal` as the hostname referring to
     `host-gateway`. Docker Desktop automatically resolves this hostname, see
-    [Explore networking features](/desktop/features/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host).
+    [Explore networking how-tos on Docker Desktop](/desktop/features/networking/networking-how-tos/#connect-a-container-to-a-service-on-the-host)
+    and
+    [Configure host gateway IP](/reference/cli/dockerd/#configure-host-gateway-ip).
 
     The following example shows how the special `host-gateway` value works. The
     example runs an HTTP server that serves a file from host to container over the
diff --git a/data/engine-cli/docker_container_start.yaml b/data/cli/engine/docker_container_start.yaml
similarity index 100%
rename from data/engine-cli/docker_container_start.yaml
rename to data/cli/engine/docker_container_start.yaml
diff --git a/data/engine-cli/docker_container_stats.yaml b/data/cli/engine/docker_container_stats.yaml
similarity index 100%
rename from data/engine-cli/docker_container_stats.yaml
rename to data/cli/engine/docker_container_stats.yaml
diff --git a/data/engine-cli/docker_container_stop.yaml b/data/cli/engine/docker_container_stop.yaml
similarity index 100%
rename from data/engine-cli/docker_container_stop.yaml
rename to data/cli/engine/docker_container_stop.yaml
diff --git a/data/engine-cli/docker_container_top.yaml b/data/cli/engine/docker_container_top.yaml
similarity index 100%
rename from data/engine-cli/docker_container_top.yaml
rename to data/cli/engine/docker_container_top.yaml
diff --git a/data/engine-cli/docker_container_unpause.yaml b/data/cli/engine/docker_container_unpause.yaml
similarity index 100%
rename from data/engine-cli/docker_container_unpause.yaml
rename to data/cli/engine/docker_container_unpause.yaml
diff --git a/data/engine-cli/docker_container_update.yaml b/data/cli/engine/docker_container_update.yaml
similarity index 80%
rename from data/engine-cli/docker_container_update.yaml
rename to data/cli/engine/docker_container_update.yaml
index a0dc5196ae67..0fd29551a198 100644
--- a/data/engine-cli/docker_container_update.yaml
+++ b/data/cli/engine/docker_container_update.yaml
@@ -8,11 +8,6 @@ long: |-
     limits on a single container or on many. To specify more than one container,
     provide space-separated list of container names or IDs.
 
-    With the exception of the `--kernel-memory` option, you can specify these
-    options on a running or a stopped container. On kernel version older than
-    4.6, you can only update `--kernel-memory` on a stopped container or on
-    a running container with kernel memory initialized.
-
     > [!WARNING]
     > The `docker update` and `docker container update` commands are not supported
     > for Windows containers.
@@ -118,7 +113,6 @@ options:
       value_type: bytes
       default_value: "0"
       description: Kernel memory limit (deprecated)
-      details_url: '#kernel-memory'
       deprecated: true
       hidden: true
       experimental: false
@@ -210,42 +204,6 @@ examples: |-
     $ docker update --cpu-shares 512 -m 300M abebf7571666 hopeful_morse
     ```
 
-    ### Update a container's kernel memory constraints (--kernel-memory) {#kernel-memory}
-
-    You can update a container's kernel memory limit using the `--kernel-memory`
-    option. On kernel version older than 4.6, this option can be updated on a
-    running container only if the container was started with `--kernel-memory`.
-    If the container was started without `--kernel-memory` you need to stop
-    the container before updating kernel memory.
-
-    > [!NOTE]
-    > The `--kernel-memory` option has been deprecated since Docker 20.10.
-
-    For example, if you started a container with this command:
-
-    ```console
-    $ docker run -dit --name test --kernel-memory 50M ubuntu bash
-    ```
-
-    You can update kernel memory while the container is running:
-
-    ```console
-    $ docker update --kernel-memory 80M test
-    ```
-
-    If you started a container without kernel memory initialized:
-
-    ```console
-    $ docker run -dit --name test2 --memory 300M ubuntu bash
-    ```
-
-    Update kernel memory of running container `test2` will fail. You need to stop
-    the container before updating the `--kernel-memory` setting. The next time you
-    start it, the container uses the new value.
-
-    Kernel version newer than (include) 4.6 does not have this limitation, you
-    can use `--kernel-memory` the same way as other options.
-
     ### Update a container's restart policy (--restart) {#restart}
 
     You can change a container's restart policy on a running container. The new
diff --git a/data/engine-cli/docker_container_wait.yaml b/data/cli/engine/docker_container_wait.yaml
similarity index 100%
rename from data/engine-cli/docker_container_wait.yaml
rename to data/cli/engine/docker_container_wait.yaml
diff --git a/data/engine-cli/docker_context.yaml b/data/cli/engine/docker_context.yaml
similarity index 100%
rename from data/engine-cli/docker_context.yaml
rename to data/cli/engine/docker_context.yaml
diff --git a/data/engine-cli/docker_context_create.yaml b/data/cli/engine/docker_context_create.yaml
similarity index 100%
rename from data/engine-cli/docker_context_create.yaml
rename to data/cli/engine/docker_context_create.yaml
diff --git a/data/engine-cli/docker_context_export.yaml b/data/cli/engine/docker_context_export.yaml
similarity index 100%
rename from data/engine-cli/docker_context_export.yaml
rename to data/cli/engine/docker_context_export.yaml
diff --git a/data/engine-cli/docker_context_import.yaml b/data/cli/engine/docker_context_import.yaml
similarity index 100%
rename from data/engine-cli/docker_context_import.yaml
rename to data/cli/engine/docker_context_import.yaml
diff --git a/data/engine-cli/docker_context_inspect.yaml b/data/cli/engine/docker_context_inspect.yaml
similarity index 100%
rename from data/engine-cli/docker_context_inspect.yaml
rename to data/cli/engine/docker_context_inspect.yaml
diff --git a/data/engine-cli/docker_context_ls.yaml b/data/cli/engine/docker_context_ls.yaml
similarity index 100%
rename from data/engine-cli/docker_context_ls.yaml
rename to data/cli/engine/docker_context_ls.yaml
diff --git a/data/engine-cli/docker_context_rm.yaml b/data/cli/engine/docker_context_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_context_rm.yaml
rename to data/cli/engine/docker_context_rm.yaml
diff --git a/data/engine-cli/docker_context_show.yaml b/data/cli/engine/docker_context_show.yaml
similarity index 100%
rename from data/engine-cli/docker_context_show.yaml
rename to data/cli/engine/docker_context_show.yaml
diff --git a/data/engine-cli/docker_context_update.yaml b/data/cli/engine/docker_context_update.yaml
similarity index 100%
rename from data/engine-cli/docker_context_update.yaml
rename to data/cli/engine/docker_context_update.yaml
diff --git a/data/cli/engine/docker_context_use.yaml b/data/cli/engine/docker_context_use.yaml
new file mode 100644
index 000000000000..c169a483ed70
--- /dev/null
+++ b/data/cli/engine/docker_context_use.yaml
@@ -0,0 +1,75 @@
+command: docker context use
+short: Set the default docker context
+long: |-
+    The `docker context use` command sets the default context for the Docker CLI.
+
+    The `docker context use` command sets the Docker CLI’s default context by updating
+    your CLI config (`~/.docker/config.json`). This change is persistent, affecting
+    all shells and sessions that share that config, not just the current terminal.
+
+    For one-off commands or per-shell usage, use `--context` or the `DOCKER_CONTEXT`
+    environment variable instead.
+usage: docker context use CONTEXT
+pname: docker context
+plink: docker_context.yaml
+inherited_options:
+    - option: help
+      value_type: bool
+      default_value: "false"
+      description: Print usage
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Set the default (sticky) context
+
+    This updates the CLI configuration and applies to new terminal sessions:
+
+    ```bash
+    $ docker context use my-context
+    my-context
+
+    $ docker context show
+    my-context
+    ```
+
+    ### Use a context for a single command
+
+    Use the global `--context` flag to avoid changing the default:
+
+    ```bash
+    $ docker --context my-context ps
+    ```
+
+    ### Use a context for the current shell session
+
+    Set `DOCKER_CONTEXT` to override the configured default in the current shell:
+
+    ```bash
+    $ export DOCKER_CONTEXT=my-context
+    $ docker context show
+    my-context
+    ```
+
+    To stop overriding:
+
+    ```bash
+    $ unset DOCKER_CONTEXT
+    ```
+
+    ### Switch back to the default context
+
+    ```bash
+    $ docker context use default
+    default
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/engine-cli/docker_cp.yaml b/data/cli/engine/docker_cp.yaml
similarity index 97%
rename from data/engine-cli/docker_cp.yaml
rename to data/cli/engine/docker_cp.yaml
index d702c8d0fb15..f69bfd0dcea2 100644
--- a/data/engine-cli/docker_cp.yaml
+++ b/data/cli/engine/docker_cp.yaml
@@ -29,7 +29,7 @@ options:
       shorthand: L
       value_type: bool
       default_value: "false"
-      description: Always follow symbol link in SRC_PATH
+      description: Always follow symlinks in SRC_PATH
       deprecated: false
       hidden: false
       experimental: false
diff --git a/data/engine-cli/docker_create.yaml b/data/cli/engine/docker_create.yaml
similarity index 97%
rename from data/engine-cli/docker_create.yaml
rename to data/cli/engine/docker_create.yaml
index 883160b59ba7..cebfc3d9ad17 100644
--- a/data/engine-cli/docker_create.yaml
+++ b/data/cli/engine/docker_create.yaml
@@ -273,9 +273,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image verification
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -510,7 +510,8 @@ options:
       swarm: false
       os_type: windows
     - option: ip
-      value_type: string
+      value_type: ip
+      default_value: <nil>
       description: IPv4 address (e.g., 172.30.100.104)
       deprecated: false
       hidden: false
@@ -519,7 +520,8 @@ options:
       kubernetes: false
       swarm: false
     - option: ip6
-      value_type: string
+      value_type: ip
+      default_value: <nil>
       description: IPv6 address (e.g., 2001:db8::33)
       deprecated: false
       hidden: false
@@ -548,9 +550,9 @@ options:
     - option: kernel-memory
       value_type: bytes
       default_value: "0"
-      description: Kernel memory limit
-      deprecated: false
-      hidden: false
+      description: Kernel memory limit (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -808,7 +810,7 @@ options:
     - option: pull
       value_type: string
       default_value: missing
-      description: Pull image before creating (`always`, `|missing`, `never`)
+      description: Pull image before creating (`always`, `missing`, `never`)
       deprecated: false
       hidden: false
       experimental: false
@@ -954,6 +956,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: use-api-socket
+      value_type: bool
+      default_value: "false"
+      description: Bind mount Docker API socket and required auth
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: true
+      kubernetes: false
+      swarm: false
     - option: user
       shorthand: u
       value_type: string
diff --git a/data/engine-cli/docker_diff.yaml b/data/cli/engine/docker_diff.yaml
similarity index 100%
rename from data/engine-cli/docker_diff.yaml
rename to data/cli/engine/docker_diff.yaml
diff --git a/data/engine-cli/docker_events.yaml b/data/cli/engine/docker_events.yaml
similarity index 100%
rename from data/engine-cli/docker_events.yaml
rename to data/cli/engine/docker_events.yaml
diff --git a/data/engine-cli/docker_exec.yaml b/data/cli/engine/docker_exec.yaml
similarity index 100%
rename from data/engine-cli/docker_exec.yaml
rename to data/cli/engine/docker_exec.yaml
diff --git a/data/engine-cli/docker_export.yaml b/data/cli/engine/docker_export.yaml
similarity index 100%
rename from data/engine-cli/docker_export.yaml
rename to data/cli/engine/docker_export.yaml
diff --git a/data/engine-cli/docker_history.yaml b/data/cli/engine/docker_history.yaml
similarity index 100%
rename from data/engine-cli/docker_history.yaml
rename to data/cli/engine/docker_history.yaml
diff --git a/data/engine-cli/docker_image.yaml b/data/cli/engine/docker_image.yaml
similarity index 100%
rename from data/engine-cli/docker_image.yaml
rename to data/cli/engine/docker_image.yaml
diff --git a/data/engine-cli/docker_image_build.yaml b/data/cli/engine/docker_image_build.yaml
similarity index 96%
rename from data/engine-cli/docker_image_build.yaml
rename to data/cli/engine/docker_image_build.yaml
index eb62cfecb37c..09accf261784 100644
--- a/data/engine-cli/docker_image_build.yaml
+++ b/data/cli/engine/docker_image_build.yaml
@@ -8,7 +8,7 @@ long: |-
     > This configuration is only relevant if you're building Windows containers.
     >
     > For information about the default `docker build`, using Buildx,
-    > see [`docker buildx build`](/reference/cli/docker/build/).
+    > see [`docker buildx build`](/reference/cli/docker/buildx/build/).
 
     When building with legacy builder, images are created from a Dockerfile by
     running a sequence of [commits](/reference/cli/docker/container/commit/). This process is
@@ -51,7 +51,7 @@ long: |-
     file to exclude files and directories that you don't require in your build from
     being sent as part of the build context.
 
-    #### Access paths outside the build context
+    #### Accessing paths outside the build context
 
     The legacy builder will error out if you try to access files outside of the
     build context using relative paths in your Dockerfile.
@@ -69,7 +69,7 @@ long: |-
     ```
 
     BuildKit on the other hand strips leading relative paths that traverse outside
-    of the build context. Re-using the previous example, the path `COPY
+    of the build context. Reusing the previous example, the path `COPY
     ../../some-dir .` evaluates to `COPY some-dir .` with BuildKit.
 usage: docker image build [OPTIONS] PATH | URL | -
 pname: docker image
@@ -177,9 +177,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image verification
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -470,22 +470,22 @@ examples: |-
 
     ```console
     Client: Docker Engine - Community
-     Version:           23.0.3
-     API version:       1.42
-     Go version:        go1.19.7
-     Git commit:        3e7cbfd
-     Built:             Tue Apr  4 22:05:41 2023
-     OS/Arch:           darwin/amd64
-     Context:           default
+     Version:           28.5.1
+     API version:       1.51
+     Go version:        go1.24.8
+     Git commit:        e180ab8
+     Built:             Wed Oct  8 12:16:17 2025
+     OS/Arch:           darwin/arm64
+     Context:           desktop-linux
 
     Server: Docker Engine - Community
      Engine:
-      Version:          23.0.3
-      API version:      1.42 (minimum version 1.12)
-      Go version:       go1.19.7
-      Git commit:       59118bf
-      Built:            Tue Apr  4 22:05:41 2023
-      OS/Arch:          linux/amd64
+      Version:          28.5.1
+      API version:      1.51 (minimum version 1.24)
+      Go version:       go1.24.8
+      Git commit:       f8215cc
+      Built:            Wed Oct  8 12:18:25 2025
+      OS/Arch:          linux/arm64
       Experimental:     true
      [...]
     ```
diff --git a/data/engine-cli/docker_image_history.yaml b/data/cli/engine/docker_image_history.yaml
similarity index 100%
rename from data/engine-cli/docker_image_history.yaml
rename to data/cli/engine/docker_image_history.yaml
diff --git a/data/cli/engine/docker_image_import.yaml b/data/cli/engine/docker_image_import.yaml
new file mode 100644
index 000000000000..4c95de8351dc
--- /dev/null
+++ b/data/cli/engine/docker_image_import.yaml
@@ -0,0 +1,198 @@
+command: docker image import
+aliases: docker image import, docker import
+short: Import the contents from a tarball to create a filesystem image
+long: |-
+    You can specify a `URL` or `-` (dash) to take data directly from `STDIN`. The
+    `URL` can point to an archive (.tar, .tar.gz, .tgz, .bzip, .tar.xz, or .txz)
+    containing a filesystem or to an individual file on the Docker host.  If you
+    specify an archive, Docker untars it in the container relative to the `/`
+    (root). If you specify an individual file, you must specify the full path within
+    the host. To import from a remote location, specify a `URI` that begins with the
+    `http://` or `https://` protocol.
+usage: docker image import [OPTIONS] file|URL|- [REPOSITORY[:TAG]]
+pname: docker image
+plink: docker_image.yaml
+options:
+    - option: change
+      shorthand: c
+      value_type: list
+      description: Apply Dockerfile instruction to the created image
+      details_url: '#change'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: message
+      shorthand: m
+      value_type: string
+      description: Set commit message for imported image
+      details_url: '#message'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: platform
+      value_type: string
+      description: Set platform if server is multi-platform capable
+      details_url: '#platform'
+      deprecated: false
+      hidden: false
+      min_api_version: "1.32"
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: help
+      value_type: bool
+      default_value: "false"
+      description: Print usage
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Import from a remote location
+
+    This creates a new untagged image.
+
+    ```console
+    $ docker import https://example.com/exampleimage.tgz
+    ```
+
+    ### Import from a local file
+
+    Import to docker via pipe and `STDIN`.
+
+    ```console
+    $ cat exampleimage.tgz | docker import - exampleimagelocal:new
+    ```
+
+    Import to docker from a local archive.
+
+    ```console
+    $ docker import /path/to/exampleimage.tgz
+    ```
+
+    ### Import from a local directory
+
+    ```console
+    $ sudo tar -c . | docker import - exampleimagedir
+    ```
+
+    Note the `sudo` in this example – you must preserve
+    the ownership of the files (especially root ownership) during the
+    archiving with tar. If you are not root (or the sudo command) when you
+    tar, then the ownerships might not get preserved.
+
+    ### Import with new configurations (-c, --change) {#change}
+
+    The `--change` option applies `Dockerfile` instructions to the image that is
+    created. Not all `Dockerfile` instructions are supported; the list of instructions
+    is limited to metadata (configuration) changes. The following `Dockerfile`
+    instructions are supported:
+
+    - [`CMD`](/reference/dockerfile/#cmd)
+    - [`ENTRYPOINT`](/reference/dockerfile/#entrypoint)
+    - [`ENV`](/reference/dockerfile/#env)
+    - [`EXPOSE`](/reference/dockerfile/#expose)
+    - [`HEALTHCHECK`](/reference/dockerfile/#healthcheck)
+    - [`LABEL`](/reference/dockerfile/#label)
+    - [`ONBUILD`](/reference/dockerfile/#onbuild)
+    - [`STOPSIGNAL`](/reference/dockerfile/#stopsignal)
+    - [`USER`](/reference/dockerfile/#user)
+    - [`VOLUME`](/reference/dockerfile/#volume)
+    - [`WORKDIR`](/reference/dockerfile/#workdir)
+
+    The following example imports an image from a TAR-file containing a root-filesystem,
+    and sets the `DEBUG` environment-variable in the resulting image:
+
+    ```console
+    $ docker import --change "ENV DEBUG=true" ./rootfs.tgz exampleimagedir
+    ```
+
+    The `--change` option can be set multiple times to apply multiple `Dockerfile`
+    instructions. The example below sets the `LABEL1` and `LABEL2` labels on
+    the imported image, in addition to the `DEBUG` environment variable from
+    the previous example:
+
+    ```console
+    $ docker import \
+        --change "ENV DEBUG=true" \
+        --change "LABEL LABEL1=hello" \
+        --change "LABEL LABEL2=world" \
+        ./rootfs.tgz exampleimagedir
+    ```
+
+    ### Import with a commit message (-m, --message) {#message}
+
+    The `--message`  (or `-m`) option allows you to set a custom comment in
+    the image's metadata. The following example imports an image from a local
+    archive and sets a custom message.
+
+    ```console
+    $ docker import --message "New image imported from tarball" ./rootfs.tgz exampleimagelocal:new
+    sha256:25e54c0df7dc49da9093d50541e0ed4508a6b78705057f1a9bebf1d564e2cb00
+    ```
+
+    After importing, the message is set in the "Comment" field of the image's
+    configuration, which is shown when viewing the image's history:
+
+    ```console
+    $ docker image history exampleimagelocal:new
+
+    IMAGE          CREATED         CREATED BY   SIZE      COMMENT
+    25e54c0df7dc   2 minutes ago                53.6MB    New image imported from tarball
+    ```
+
+    ### When the daemon supports multiple operating systems
+
+    If the daemon supports multiple operating systems, and the image being imported
+    does not match the default operating system, it may be necessary to add
+    `--platform`. This would be necessary when importing a Linux image into a Windows
+    daemon.
+
+    ```console
+    $ docker import --platform=linux .\linuximage.tar
+    ```
+
+    ### Set the platform for the imported image (--platform) {#platform}
+
+    The `--platform` option allows you to specify the platform for the imported
+    image. By default, the daemon's native platform is used as platform, but
+    the `--platform` option allows you to override the default, for example, in
+    situations where the imported root filesystem is for a different architecture
+    or operating system.
+
+    The platform option takes the `os[/arch[/variant]]` format; for example,
+    `linux/amd64` or `linux/arm64/v8`. Architecture and variant are optional,
+    and default to the daemon's native architecture if omitted.
+
+    The following example imports an image from a root-filesystem in `rootfs.tgz`,
+    and sets the image's platform to `linux/amd64`;
+
+    ```console
+    $ docker image import --platform=linux/amd64  ./rootfs.tgz imported:latest
+    sha256:44a8b44157dad5edcff85f0c93a3e455f3b20a046d025af4ec50ed990d7ebc09
+    ```
+
+    After importing the image, the image's platform is set in the image's
+    configuration;
+
+    ```console
+    $ docker image inspect --format '{{.Os}}/{{.Architecture}}' imported:latest
+    linux/amd64
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/engine/docker_image_inspect.yaml b/data/cli/engine/docker_image_inspect.yaml
new file mode 100644
index 000000000000..c80082132510
--- /dev/null
+++ b/data/cli/engine/docker_image_inspect.yaml
@@ -0,0 +1,52 @@
+command: docker image inspect
+short: Display detailed information on one or more images
+long: Display detailed information on one or more images
+usage: docker image inspect [OPTIONS] IMAGE [IMAGE...]
+pname: docker image
+plink: docker_image.yaml
+options:
+    - option: format
+      shorthand: f
+      value_type: string
+      description: |-
+        Format output using a custom template:
+        'json':             Print in JSON format
+        'TEMPLATE':         Print output using the given Go template.
+        Refer to https://docs.docker.com/go/formatting/ for more information about formatting output with templates
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: platform
+      value_type: string
+      description: |-
+        Inspect a specific platform of the multi-platform image.
+        If the image or the server is not multi-platform capable, the command will error out if the platform does not match.
+        'os[/arch[/variant]]': Explicit platform (eg. linux/amd64)
+      deprecated: false
+      hidden: false
+      min_api_version: "1.49"
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: help
+      value_type: bool
+      default_value: "false"
+      description: Print usage
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/engine-cli/docker_image_load.yaml b/data/cli/engine/docker_image_load.yaml
similarity index 95%
rename from data/engine-cli/docker_image_load.yaml
rename to data/cli/engine/docker_image_load.yaml
index c4b82bb93c52..d6312cf270b1 100644
--- a/data/engine-cli/docker_image_load.yaml
+++ b/data/cli/engine/docker_image_load.yaml
@@ -20,9 +20,10 @@ options:
       kubernetes: false
       swarm: false
     - option: platform
-      value_type: string
+      value_type: stringSlice
+      default_value: '[]'
       description: |
-        Load only the given platform variant. Formatted as `os[/arch[/variant]]` (e.g., `linux/amd64`)
+        Load only the given platform(s). Formatted as a comma-separated list of `os[/arch[/variant]]` (e.g., `linux/amd64,linux/arm64/v8`).
       details_url: '#platform'
       deprecated: false
       hidden: false
diff --git a/data/engine-cli/docker_image_ls.yaml b/data/cli/engine/docker_image_ls.yaml
similarity index 98%
rename from data/engine-cli/docker_image_ls.yaml
rename to data/cli/engine/docker_image_ls.yaml
index bdad55e3a5a3..b870d29ac127 100644
--- a/data/engine-cli/docker_image_ls.yaml
+++ b/data/cli/engine/docker_image_ls.yaml
@@ -10,6 +10,9 @@ long: |-
     allowing each step to be cached. These intermediate layers are not shown
     by default.
 
+    Untagged (dangling) images are also hidden by default. Use the `-a` (`--all`)
+    flag to show intermediate layers and dangling images.
+
     The `SIZE` is the cumulative space taken up by the image and all
     its parent images. This is also the disk space used by the contents of the
     Tar file created when you `docker save` an image.
@@ -25,7 +28,7 @@ options:
       shorthand: a
       value_type: bool
       default_value: "false"
-      description: Show all images (default hides intermediate images)
+      description: Show all images (default hides intermediate and dangling images)
       deprecated: false
       hidden: false
       experimental: false
@@ -415,8 +418,8 @@ examples: |-
 
     ```console
     $ docker images --format json
-    {"Containers":"N/A","CreatedAt":"2021-03-04 03:24:42 +0100 CET","CreatedSince":"5 days ago","Digest":"\u003cnone\u003e","ID":"4dd97cefde62","Repository":"ubuntu","SharedSize":"N/A","Size":"72.9MB","Tag":"latest","UniqueSize":"N/A","VirtualSize":"72.9MB"}
-    {"Containers":"N/A","CreatedAt":"2021-02-17 22:19:54 +0100 CET","CreatedSince":"2 weeks ago","Digest":"\u003cnone\u003e","ID":"28f6e2705743","Repository":"alpine","SharedSize":"N/A","Size":"5.61MB","Tag":"latest","UniqueSize":"N/A","VirtualSize":"5.613MB"}
+    {"Containers":"N/A","CreatedAt":"2021-03-04 03:24:42 +0100 CET","CreatedSince":"5 days ago","Digest":"\u003cnone\u003e","ID":"4dd97cefde62","Repository":"ubuntu","SharedSize":"N/A","Size":"72.9MB","Tag":"latest","UniqueSize":"N/A"}
+    {"Containers":"N/A","CreatedAt":"2021-02-17 22:19:54 +0100 CET","CreatedSince":"2 weeks ago","Digest":"\u003cnone\u003e","ID":"28f6e2705743","Repository":"alpine","SharedSize":"N/A","Size":"5.61MB","Tag":"latest","UniqueSize":"N/A"}
     ```
 deprecated: false
 hidden: false
diff --git a/data/engine-cli/docker_image_prune.yaml b/data/cli/engine/docker_image_prune.yaml
similarity index 94%
rename from data/engine-cli/docker_image_prune.yaml
rename to data/cli/engine/docker_image_prune.yaml
index 2cae8c59072c..524a318118ea 100644
--- a/data/engine-cli/docker_image_prune.yaml
+++ b/data/cli/engine/docker_image_prune.yaml
@@ -88,7 +88,19 @@ examples: |-
     ### Filtering (--filter) {#filter}
 
     The filtering flag (`--filter`) format is of "key=value". If there is more
-    than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`)
+    than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`).
+
+    When multiple filters are provided, they are combined as follows:
+
+    - Multiple filters with **different keys** are combined using AND logic.
+      An image must satisfy all filter conditions to be pruned.
+    - Multiple filters with the **same key** are combined using OR logic.
+      An image is pruned if it matches any of the values for that key.
+
+    For example, `--filter "label=foo" --filter "until=24h"` prunes images
+    that have the `foo` label **and** were created more than 24 hours ago.
+    Conversely, `--filter "label=foo" --filter "label=bar"` prunes images
+    that have **either** the `foo` **or** `bar` label.
 
     The currently supported filters are:
 
diff --git a/data/engine-cli/docker_image_pull.yaml b/data/cli/engine/docker_image_pull.yaml
similarity index 96%
rename from data/engine-cli/docker_image_pull.yaml
rename to data/cli/engine/docker_image_pull.yaml
index 7c42bc5fdc44..d1dda47d76d5 100644
--- a/data/engine-cli/docker_image_pull.yaml
+++ b/data/cli/engine/docker_image_pull.yaml
@@ -14,13 +14,13 @@ long: |-
     ### Proxy configuration
 
     If you are behind an HTTP proxy server, for example in corporate settings,
-    before open a connect to registry, you may need to configure the Docker
-    daemon's proxy settings, refer to the [dockerd command-line reference](/reference/cli/dockerd/#proxy-configuration)
-    for details.
+    you may have to configure the Docker daemon to use the proxy server for
+    operations such as pulling and pushing images. Refer to the
+    [dockerd command-line reference](/reference/cli/dockerd/#proxy-configuration) for details.
 
     ### Concurrent downloads
 
-    By default the Docker daemon will pull three layers of an image at a time.
+    By default the Docker daemon downloads three layers of an image at a time.
     If you are on a low bandwidth connection this may cause timeout issues and you may want to lower
     this via the `--max-concurrent-downloads` daemon option. See the
     [daemon documentation](/reference/cli/dockerd/) for more details.
@@ -43,9 +43,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image verification
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
diff --git a/data/engine-cli/docker_image_push.yaml b/data/cli/engine/docker_image_push.yaml
similarity index 98%
rename from data/engine-cli/docker_image_push.yaml
rename to data/cli/engine/docker_image_push.yaml
index 89777eedede2..e0bb7e3177e8 100644
--- a/data/engine-cli/docker_image_push.yaml
+++ b/data/cli/engine/docker_image_push.yaml
@@ -42,9 +42,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image signing
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
diff --git a/data/cli/engine/docker_image_rm.yaml b/data/cli/engine/docker_image_rm.yaml
new file mode 100644
index 000000000000..373333c5427c
--- /dev/null
+++ b/data/cli/engine/docker_image_rm.yaml
@@ -0,0 +1,214 @@
+command: docker image rm
+aliases: docker image rm, docker image remove, docker rmi
+short: Remove one or more images
+long: |-
+    Removes (and un-tags) one or more images from the host node. If an image has
+    multiple tags, using this command with the tag as a parameter only removes the
+    tag. If the tag is the only one for the image, both the image and the tag are
+    removed.
+
+    This does not remove images from a registry. You cannot remove an image of a
+    running container unless you use the `-f` option. To see all images on a host
+    use the [`docker image ls`](/reference/cli/docker/image/ls/) command.
+usage: docker image rm [OPTIONS] IMAGE [IMAGE...]
+pname: docker image
+plink: docker_image.yaml
+options:
+    - option: force
+      shorthand: f
+      value_type: bool
+      default_value: "false"
+      description: Force removal of the image
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: no-prune
+      value_type: bool
+      default_value: "false"
+      description: Do not delete untagged parents
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: platform
+      value_type: stringSlice
+      default_value: '[]'
+      description: |
+        Remove only the given platform variant. Formatted as `os[/arch[/variant]]` (e.g., `linux/amd64`)
+      details_url: '#platform'
+      deprecated: false
+      hidden: false
+      min_api_version: "1.50"
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: help
+      value_type: bool
+      default_value: "false"
+      description: Print usage
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    You can remove an image using its short or long ID, its tag, or its digest. If
+    an image has one or more tags referencing it, you must remove all of them before
+    the image is removed. Digest references are removed automatically when an image
+    is removed by tag.
+
+    ```console
+    $ docker images
+
+    REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
+    test1                     latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
+    test                      latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
+    test2                     latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
+
+    $ docker rmi fd484f19954f
+
+    Error: Conflict, cannot delete image fd484f19954f because it is tagged in multiple repositories, use -f to force
+    2013/12/11 05:47:16 Error: failed to remove one or more images
+
+    $ docker rmi test1:latest
+
+    Untagged: test1:latest
+
+    $ docker rmi test2:latest
+
+    Untagged: test2:latest
+
+
+    $ docker images
+
+    REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
+    test                      latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
+
+    $ docker rmi test:latest
+
+    Untagged: test:latest
+    Deleted: fd484f19954f4920da7ff372b5067f5b7ddb2fd3830cecd17b96ea9e286ba5b8
+    ```
+
+    If you use the `-f` flag and specify the image's short or long ID, then this
+    command untags and removes all images that match the specified ID.
+
+    ```console
+    $ docker images
+
+    REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
+    test1                     latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
+    test                      latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
+    test2                     latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
+
+    $ docker rmi -f fd484f19954f
+
+    Untagged: test1:latest
+    Untagged: test:latest
+    Untagged: test2:latest
+    Deleted: fd484f19954f4920da7ff372b5067f5b7ddb2fd3830cecd17b96ea9e286ba5b8
+    ```
+
+    An image pulled by digest has no tag associated with it:
+
+    ```console
+    $ docker images --digests
+
+    REPOSITORY                     TAG       DIGEST                                                                    IMAGE ID        CREATED         SIZE
+    localhost:5000/test/busybox    <none>    sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf   4986bf8c1536    9 weeks ago     2.43 MB
+    ```
+
+    To remove an image using its digest:
+
+    ```console
+    $ docker rmi localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
+    Untagged: localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
+    Deleted: 4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125
+    Deleted: ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2
+    Deleted: df7546f9f060a2268024c8a230d8639878585defcc1bc6f79d2728a13957871b
+    ```
+
+    ### Remove specific platforms (`--platform`) {#platform}
+
+    The `--platform` option allows you to specify which platform variants of the
+    image to remove. By default, `docker image remove` removes all platform variants
+    that are present. Use the `--platform` option to specify which platform variant
+    of the image to remove.
+
+    Removing a specific platform removes the image from all images that reference
+    the same content, and requires the `--force` option to be used. Omitting the
+    `--force` option produces a warning, and the remove is canceled:
+
+    ```console
+    $ docker image rm --platform=linux/amd64 alpine
+    Error response from daemon: Content will be removed from all images referencing this variant. Use —-force to force delete.
+    ```
+
+    The platform option takes the `os[/arch[/variant]]` format; for example,
+    `linux/amd64` or `linux/arm64/v8`. Architecture and variant are optional,
+    and default to the daemon's native architecture if omitted.
+
+    You can pass multiple platforms either by passing the `--platform` flag
+    multiple times, or by passing a comma-separated list of platforms to remove.
+    The following uses of this option are equivalent;
+
+    ```console
+    $ docker image rm --platform linux/amd64 --platform linux/ppc64le myimage
+    $ docker image rm --platform linux/amd64,linux/ppc64le myimage
+    ```
+
+    The following example removes the `linux/amd64` and `linux/ppc64le` variants
+    of an `alpine` image that contains multiple platform variants in the image
+    cache:
+
+    ```console
+    $ docker image ls --tree
+
+    IMAGE                   ID             DISK USAGE   CONTENT SIZE   EXTRA
+    alpine:latest           a8560b36e8b8       37.8MB         11.2MB    U
+    ├─ linux/amd64          1c4eef651f65       12.1MB         3.64MB    U
+    ├─ linux/arm/v6         903bfe2ae994           0B             0B
+    ├─ linux/arm/v7         9c2d245b3c01           0B             0B
+    ├─ linux/arm64/v8       757d680068d7       12.8MB         3.99MB
+    ├─ linux/386            2436f2b3b7d2           0B             0B
+    ├─ linux/ppc64le        9ed53fd3b831       12.8MB         3.58MB
+    ├─ linux/riscv64        1de5eb4a9a67           0B             0B
+    └─ linux/s390x          fe0dcdd1f783           0B             0B
+
+    $ docker image --platform=linux/amd64,linux/ppc64le --force alpine
+    Deleted: sha256:1c4eef651f65e2f7daee7ee785882ac164b02b78fb74503052a26dc061c90474
+    Deleted: sha256:9ed53fd3b83120f78b33685d930ce9bf5aa481f6e2d165c42cbbddbeaa196f6f
+    ```
+
+    After the command completes, the given variants of the `alpine` image are removed
+    from the image cache:
+
+    ```console
+    $ docker image ls --tree
+
+    IMAGE                   ID             DISK USAGE   CONTENT SIZE   EXTRA
+    alpine:latest           a8560b36e8b8       12.8MB         3.99MB
+    ├─ linux/amd64          1c4eef651f65           0B             0B
+    ├─ linux/arm/v6         903bfe2ae994           0B             0B
+    ├─ linux/arm/v7         9c2d245b3c01           0B             0B
+    ├─ linux/arm64/v8       757d680068d7       12.8MB         3.99MB
+    ├─ linux/386            2436f2b3b7d2           0B             0B
+    ├─ linux/ppc64le        9ed53fd3b831           0B             0B
+    ├─ linux/riscv64        1de5eb4a9a67           0B             0B
+    └─ linux/s390x          fe0dcdd1f783           0B             0B
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/engine-cli/docker_image_save.yaml b/data/cli/engine/docker_image_save.yaml
similarity index 95%
rename from data/engine-cli/docker_image_save.yaml
rename to data/cli/engine/docker_image_save.yaml
index bbec0590cb8d..3d242060281e 100644
--- a/data/engine-cli/docker_image_save.yaml
+++ b/data/cli/engine/docker_image_save.yaml
@@ -20,9 +20,10 @@ options:
       kubernetes: false
       swarm: false
     - option: platform
-      value_type: string
+      value_type: stringSlice
+      default_value: '[]'
       description: |
-        Save only the given platform variant. Formatted as `os[/arch[/variant]]` (e.g., `linux/amd64`)
+        Save only the given platform(s). Formatted as a comma-separated list of `os[/arch[/variant]]` (e.g., `linux/amd64,linux/arm64/v8`)
       details_url: '#platform'
       deprecated: false
       hidden: false
diff --git a/data/engine-cli/docker_image_tag.yaml b/data/cli/engine/docker_image_tag.yaml
similarity index 100%
rename from data/engine-cli/docker_image_tag.yaml
rename to data/cli/engine/docker_image_tag.yaml
diff --git a/data/engine-cli/docker_images.yaml b/data/cli/engine/docker_images.yaml
similarity index 97%
rename from data/engine-cli/docker_images.yaml
rename to data/cli/engine/docker_images.yaml
index 2cd119d0c057..52b190ed2e45 100644
--- a/data/engine-cli/docker_images.yaml
+++ b/data/cli/engine/docker_images.yaml
@@ -10,7 +10,7 @@ options:
       shorthand: a
       value_type: bool
       default_value: "false"
-      description: Show all images (default hides intermediate images)
+      description: Show all images (default hides intermediate and dangling images)
       deprecated: false
       hidden: false
       experimental: false
diff --git a/data/engine-cli/docker_import.yaml b/data/cli/engine/docker_import.yaml
similarity index 100%
rename from data/engine-cli/docker_import.yaml
rename to data/cli/engine/docker_import.yaml
diff --git a/data/engine-cli/docker_info.yaml b/data/cli/engine/docker_info.yaml
similarity index 100%
rename from data/engine-cli/docker_info.yaml
rename to data/cli/engine/docker_info.yaml
diff --git a/data/engine-cli/docker_inspect.yaml b/data/cli/engine/docker_inspect.yaml
similarity index 95%
rename from data/engine-cli/docker_inspect.yaml
rename to data/cli/engine/docker_inspect.yaml
index db7125116ad1..f750741bf5f5 100644
--- a/data/engine-cli/docker_inspect.yaml
+++ b/data/cli/engine/docker_inspect.yaml
@@ -4,7 +4,59 @@ long: |-
     Docker inspect provides detailed information on constructs controlled by Docker.
 
     By default, `docker inspect` will render results in a JSON array.
-
+usage: docker inspect [OPTIONS] NAME|ID [NAME|ID...]
+pname: docker
+plink: docker.yaml
+options:
+    - option: format
+      shorthand: f
+      value_type: string
+      description: |-
+        Format output using a custom template:
+        'json':             Print in JSON format
+        'TEMPLATE':         Print output using the given Go template.
+        Refer to https://docs.docker.com/go/formatting/ for more information about formatting output with templates
+      details_url: '#format'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: size
+      shorthand: s
+      value_type: bool
+      default_value: "false"
+      description: Display total file sizes if the type is container
+      details_url: '#size'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: type
+      value_type: string
+      description: Only inspect objects of the given type
+      details_url: '#type'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: help
+      value_type: bool
+      default_value: "false"
+      description: Print usage
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
     ### Format the output (--format) {#format}
 
     If a format is specified, the given template will be executed for each result.
@@ -57,56 +109,7 @@ long: |-
     $ docker inspect --size database -f '{{ .SizeRw }}'
     12288
     ```
-usage: docker inspect [OPTIONS] NAME|ID [NAME|ID...]
-pname: docker
-plink: docker.yaml
-options:
-    - option: format
-      shorthand: f
-      value_type: string
-      description: |-
-        Format output using a custom template:
-        'json':             Print in JSON format
-        'TEMPLATE':         Print output using the given Go template.
-        Refer to https://docs.docker.com/go/formatting/ for more information about formatting output with templates
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: size
-      shorthand: s
-      value_type: bool
-      default_value: "false"
-      description: Display total file sizes if the type is container
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: type
-      value_type: string
-      description: Return JSON for specified type
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: help
-      value_type: bool
-      default_value: "false"
-      description: Print usage
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-examples: |-
+
     ### Get an instance's IP address
 
     For the most part, you can pick out any field from the JSON in a fairly
@@ -139,7 +142,7 @@ examples: |-
     You can loop over arrays and maps in the results to produce simple text output:
 
     ```console
-    $ docker inspect --format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -> {{(index $conf 0).HostPort}} {{end}}' $INSTANCE_ID
+    $ docker inspect --format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -> {{with $conf}}{{(index . 0).HostPort}}{{else}}none{{end}} {{end}}' $INSTANCE_ID
     ```
 
     ### Find a specific port mapping
diff --git a/data/engine-cli/docker_kill.yaml b/data/cli/engine/docker_kill.yaml
similarity index 100%
rename from data/engine-cli/docker_kill.yaml
rename to data/cli/engine/docker_kill.yaml
diff --git a/data/engine-cli/docker_load.yaml b/data/cli/engine/docker_load.yaml
similarity index 87%
rename from data/engine-cli/docker_load.yaml
rename to data/cli/engine/docker_load.yaml
index 3f7d02e1954c..6a80993f0031 100644
--- a/data/engine-cli/docker_load.yaml
+++ b/data/cli/engine/docker_load.yaml
@@ -17,9 +17,10 @@ options:
       kubernetes: false
       swarm: false
     - option: platform
-      value_type: string
+      value_type: stringSlice
+      default_value: '[]'
       description: |
-        Load only the given platform variant. Formatted as `os[/arch[/variant]]` (e.g., `linux/amd64`)
+        Load only the given platform(s). Formatted as a comma-separated list of `os[/arch[/variant]]` (e.g., `linux/amd64,linux/arm64/v8`).
       deprecated: false
       hidden: false
       min_api_version: "1.48"
diff --git a/data/engine-cli/docker_login.yaml b/data/cli/engine/docker_login.yaml
similarity index 97%
rename from data/engine-cli/docker_login.yaml
rename to data/cli/engine/docker_login.yaml
index d8d0c93eb75d..96f9545b230d 100644
--- a/data/engine-cli/docker_login.yaml
+++ b/data/cli/engine/docker_login.yaml
@@ -158,7 +158,7 @@ options:
     - option: password
       shorthand: p
       value_type: string
-      description: Password or Personal Access Token (PAT)
+      description: Password or Personal Access Token (PAT), or `-` to read from stdin
       deprecated: false
       hidden: false
       experimental: false
@@ -272,6 +272,13 @@ examples: |-
     ```console
     $ cat ~/my_password.txt | docker login --username foo --password-stdin
     ```
+
+    You can also pass `-` as the value for `--password` or `-p` to read the
+    password from `STDIN`.
+
+    ```console
+    $ cat ~/my_password.txt | docker login --username foo --password -
+    ```
 deprecated: false
 hidden: false
 experimental: false
diff --git a/data/engine-cli/docker_logout.yaml b/data/cli/engine/docker_logout.yaml
similarity index 100%
rename from data/engine-cli/docker_logout.yaml
rename to data/cli/engine/docker_logout.yaml
diff --git a/data/engine-cli/docker_logs.yaml b/data/cli/engine/docker_logs.yaml
similarity index 100%
rename from data/engine-cli/docker_logs.yaml
rename to data/cli/engine/docker_logs.yaml
diff --git a/data/engine-cli/docker_manifest.yaml b/data/cli/engine/docker_manifest.yaml
similarity index 100%
rename from data/engine-cli/docker_manifest.yaml
rename to data/cli/engine/docker_manifest.yaml
diff --git a/data/engine-cli/docker_manifest_annotate.yaml b/data/cli/engine/docker_manifest_annotate.yaml
similarity index 100%
rename from data/engine-cli/docker_manifest_annotate.yaml
rename to data/cli/engine/docker_manifest_annotate.yaml
diff --git a/data/engine-cli/docker_manifest_create.yaml b/data/cli/engine/docker_manifest_create.yaml
similarity index 100%
rename from data/engine-cli/docker_manifest_create.yaml
rename to data/cli/engine/docker_manifest_create.yaml
diff --git a/data/engine-cli/docker_manifest_inspect.yaml b/data/cli/engine/docker_manifest_inspect.yaml
similarity index 100%
rename from data/engine-cli/docker_manifest_inspect.yaml
rename to data/cli/engine/docker_manifest_inspect.yaml
diff --git a/data/engine-cli/docker_manifest_push.yaml b/data/cli/engine/docker_manifest_push.yaml
similarity index 100%
rename from data/engine-cli/docker_manifest_push.yaml
rename to data/cli/engine/docker_manifest_push.yaml
diff --git a/data/engine-cli/docker_manifest_rm.yaml b/data/cli/engine/docker_manifest_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_manifest_rm.yaml
rename to data/cli/engine/docker_manifest_rm.yaml
diff --git a/data/engine-cli/docker_network.yaml b/data/cli/engine/docker_network.yaml
similarity index 100%
rename from data/engine-cli/docker_network.yaml
rename to data/cli/engine/docker_network.yaml
diff --git a/data/engine-cli/docker_network_connect.yaml b/data/cli/engine/docker_network_connect.yaml
similarity index 98%
rename from data/engine-cli/docker_network_connect.yaml
rename to data/cli/engine/docker_network_connect.yaml
index 7fc8ba9eb997..5285a834d4d4 100644
--- a/data/engine-cli/docker_network_connect.yaml
+++ b/data/cli/engine/docker_network_connect.yaml
@@ -41,7 +41,8 @@ options:
       kubernetes: false
       swarm: false
     - option: ip
-      value_type: string
+      value_type: ip
+      default_value: <nil>
       description: IPv4 address (e.g., `172.30.100.104`)
       details_url: '#ip'
       deprecated: false
@@ -51,7 +52,8 @@ options:
       kubernetes: false
       swarm: false
     - option: ip6
-      value_type: string
+      value_type: ip
+      default_value: <nil>
       description: IPv6 address (e.g., `2001:db8::33`)
       deprecated: false
       hidden: false
@@ -70,7 +72,7 @@ options:
       kubernetes: false
       swarm: false
     - option: link-local-ip
-      value_type: stringSlice
+      value_type: ipSlice
       default_value: '[]'
       description: Add a link-local address for the container
       deprecated: false
diff --git a/data/engine-cli/docker_network_create.yaml b/data/cli/engine/docker_network_create.yaml
similarity index 99%
rename from data/engine-cli/docker_network_create.yaml
rename to data/cli/engine/docker_network_create.yaml
index 99706e3d55dd..12254577d942 100644
--- a/data/engine-cli/docker_network_create.yaml
+++ b/data/cli/engine/docker_network_create.yaml
@@ -108,7 +108,7 @@ options:
       kubernetes: false
       swarm: false
     - option: gateway
-      value_type: stringSlice
+      value_type: ipSlice
       default_value: '[]'
       description: IPv4 or IPv6 Gateway for the master subnet
       deprecated: false
@@ -141,7 +141,7 @@ options:
       kubernetes: false
       swarm: false
     - option: ip-range
-      value_type: stringSlice
+      value_type: ipNetSlice
       default_value: '[]'
       description: Allocate container ip from a sub-range
       deprecated: false
diff --git a/data/engine-cli/docker_network_disconnect.yaml b/data/cli/engine/docker_network_disconnect.yaml
similarity index 100%
rename from data/engine-cli/docker_network_disconnect.yaml
rename to data/cli/engine/docker_network_disconnect.yaml
diff --git a/data/engine-cli/docker_network_inspect.yaml b/data/cli/engine/docker_network_inspect.yaml
similarity index 100%
rename from data/engine-cli/docker_network_inspect.yaml
rename to data/cli/engine/docker_network_inspect.yaml
diff --git a/data/engine-cli/docker_network_ls.yaml b/data/cli/engine/docker_network_ls.yaml
similarity index 100%
rename from data/engine-cli/docker_network_ls.yaml
rename to data/cli/engine/docker_network_ls.yaml
diff --git a/data/engine-cli/docker_network_prune.yaml b/data/cli/engine/docker_network_prune.yaml
similarity index 86%
rename from data/engine-cli/docker_network_prune.yaml
rename to data/cli/engine/docker_network_prune.yaml
index 01b9e8ff9a5e..7010ff8e9f10 100644
--- a/data/engine-cli/docker_network_prune.yaml
+++ b/data/cli/engine/docker_network_prune.yaml
@@ -53,7 +53,19 @@ examples: |-
     ### Filtering (--filter) {#filter}
 
     The filtering flag (`--filter`) format is of "key=value". If there is more
-    than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`)
+    than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`).
+
+    When multiple filters are provided, they are combined as follows:
+
+    - Multiple filters with **different keys** are combined using AND logic.
+      A network must satisfy all filter conditions to be pruned.
+    - Multiple filters with the **same key** are combined using OR logic.
+      A network is pruned if it matches any of the values for that key.
+
+    For example, `--filter "label=foo" --filter "until=24h"` prunes networks
+    that have the `foo` label **and** were created more than 24 hours ago.
+    Conversely, `--filter "label=foo" --filter "label=bar"` prunes networks
+    that have **either** the `foo` **or** `bar` label.
 
     The currently supported filters are:
 
diff --git a/data/engine-cli/docker_network_rm.yaml b/data/cli/engine/docker_network_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_network_rm.yaml
rename to data/cli/engine/docker_network_rm.yaml
diff --git a/data/engine-cli/docker_node.yaml b/data/cli/engine/docker_node.yaml
similarity index 100%
rename from data/engine-cli/docker_node.yaml
rename to data/cli/engine/docker_node.yaml
diff --git a/data/engine-cli/docker_node_demote.yaml b/data/cli/engine/docker_node_demote.yaml
similarity index 100%
rename from data/engine-cli/docker_node_demote.yaml
rename to data/cli/engine/docker_node_demote.yaml
diff --git a/data/engine-cli/docker_node_inspect.yaml b/data/cli/engine/docker_node_inspect.yaml
similarity index 100%
rename from data/engine-cli/docker_node_inspect.yaml
rename to data/cli/engine/docker_node_inspect.yaml
diff --git a/data/engine-cli/docker_node_ls.yaml b/data/cli/engine/docker_node_ls.yaml
similarity index 100%
rename from data/engine-cli/docker_node_ls.yaml
rename to data/cli/engine/docker_node_ls.yaml
diff --git a/data/engine-cli/docker_node_promote.yaml b/data/cli/engine/docker_node_promote.yaml
similarity index 100%
rename from data/engine-cli/docker_node_promote.yaml
rename to data/cli/engine/docker_node_promote.yaml
diff --git a/data/engine-cli/docker_node_ps.yaml b/data/cli/engine/docker_node_ps.yaml
similarity index 100%
rename from data/engine-cli/docker_node_ps.yaml
rename to data/cli/engine/docker_node_ps.yaml
diff --git a/data/engine-cli/docker_node_rm.yaml b/data/cli/engine/docker_node_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_node_rm.yaml
rename to data/cli/engine/docker_node_rm.yaml
diff --git a/data/engine-cli/docker_node_update.yaml b/data/cli/engine/docker_node_update.yaml
similarity index 100%
rename from data/engine-cli/docker_node_update.yaml
rename to data/cli/engine/docker_node_update.yaml
diff --git a/data/engine-cli/docker_pause.yaml b/data/cli/engine/docker_pause.yaml
similarity index 100%
rename from data/engine-cli/docker_pause.yaml
rename to data/cli/engine/docker_pause.yaml
diff --git a/data/engine-cli/docker_plugin.yaml b/data/cli/engine/docker_plugin.yaml
similarity index 100%
rename from data/engine-cli/docker_plugin.yaml
rename to data/cli/engine/docker_plugin.yaml
diff --git a/data/engine-cli/docker_plugin_create.yaml b/data/cli/engine/docker_plugin_create.yaml
similarity index 100%
rename from data/engine-cli/docker_plugin_create.yaml
rename to data/cli/engine/docker_plugin_create.yaml
diff --git a/data/engine-cli/docker_plugin_disable.yaml b/data/cli/engine/docker_plugin_disable.yaml
similarity index 100%
rename from data/engine-cli/docker_plugin_disable.yaml
rename to data/cli/engine/docker_plugin_disable.yaml
diff --git a/data/engine-cli/docker_plugin_enable.yaml b/data/cli/engine/docker_plugin_enable.yaml
similarity index 100%
rename from data/engine-cli/docker_plugin_enable.yaml
rename to data/cli/engine/docker_plugin_enable.yaml
diff --git a/data/engine-cli/docker_plugin_inspect.yaml b/data/cli/engine/docker_plugin_inspect.yaml
similarity index 100%
rename from data/engine-cli/docker_plugin_inspect.yaml
rename to data/cli/engine/docker_plugin_inspect.yaml
diff --git a/data/engine-cli/docker_plugin_install.yaml b/data/cli/engine/docker_plugin_install.yaml
similarity index 96%
rename from data/engine-cli/docker_plugin_install.yaml
rename to data/cli/engine/docker_plugin_install.yaml
index e558715cd4ef..95ab5360cbf9 100644
--- a/data/engine-cli/docker_plugin_install.yaml
+++ b/data/cli/engine/docker_plugin_install.yaml
@@ -31,9 +31,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image verification
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
diff --git a/data/engine-cli/docker_plugin_ls.yaml b/data/cli/engine/docker_plugin_ls.yaml
similarity index 100%
rename from data/engine-cli/docker_plugin_ls.yaml
rename to data/cli/engine/docker_plugin_ls.yaml
diff --git a/data/engine-cli/docker_plugin_push.yaml b/data/cli/engine/docker_plugin_push.yaml
similarity index 93%
rename from data/engine-cli/docker_plugin_push.yaml
rename to data/cli/engine/docker_plugin_push.yaml
index dc2902ecdc0f..7c67d85d5e05 100644
--- a/data/engine-cli/docker_plugin_push.yaml
+++ b/data/cli/engine/docker_plugin_push.yaml
@@ -13,9 +13,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image signing
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
diff --git a/data/engine-cli/docker_plugin_rm.yaml b/data/cli/engine/docker_plugin_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_plugin_rm.yaml
rename to data/cli/engine/docker_plugin_rm.yaml
diff --git a/data/engine-cli/docker_plugin_set.yaml b/data/cli/engine/docker_plugin_set.yaml
similarity index 100%
rename from data/engine-cli/docker_plugin_set.yaml
rename to data/cli/engine/docker_plugin_set.yaml
diff --git a/data/engine-cli/docker_plugin_upgrade.yaml b/data/cli/engine/docker_plugin_upgrade.yaml
similarity index 96%
rename from data/engine-cli/docker_plugin_upgrade.yaml
rename to data/cli/engine/docker_plugin_upgrade.yaml
index 31f3a7cdf769..42ba812357f5 100644
--- a/data/engine-cli/docker_plugin_upgrade.yaml
+++ b/data/cli/engine/docker_plugin_upgrade.yaml
@@ -12,9 +12,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image verification
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
diff --git a/data/engine-cli/docker_port.yaml b/data/cli/engine/docker_port.yaml
similarity index 100%
rename from data/engine-cli/docker_port.yaml
rename to data/cli/engine/docker_port.yaml
diff --git a/data/engine-cli/docker_ps.yaml b/data/cli/engine/docker_ps.yaml
similarity index 100%
rename from data/engine-cli/docker_ps.yaml
rename to data/cli/engine/docker_ps.yaml
diff --git a/data/engine-cli/docker_pull.yaml b/data/cli/engine/docker_pull.yaml
similarity index 94%
rename from data/engine-cli/docker_pull.yaml
rename to data/cli/engine/docker_pull.yaml
index 8cd15e99e47e..ef853850fb93 100644
--- a/data/engine-cli/docker_pull.yaml
+++ b/data/cli/engine/docker_pull.yaml
@@ -20,9 +20,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image verification
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
diff --git a/data/engine-cli/docker_push.yaml b/data/cli/engine/docker_push.yaml
similarity index 94%
rename from data/engine-cli/docker_push.yaml
rename to data/cli/engine/docker_push.yaml
index dcd3095f86c3..26e4ccbfe793 100644
--- a/data/engine-cli/docker_push.yaml
+++ b/data/cli/engine/docker_push.yaml
@@ -20,9 +20,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image signing
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
diff --git a/data/engine-cli/docker_rename.yaml b/data/cli/engine/docker_rename.yaml
similarity index 100%
rename from data/engine-cli/docker_rename.yaml
rename to data/cli/engine/docker_rename.yaml
diff --git a/data/engine-cli/docker_restart.yaml b/data/cli/engine/docker_restart.yaml
similarity index 100%
rename from data/engine-cli/docker_restart.yaml
rename to data/cli/engine/docker_restart.yaml
diff --git a/data/engine-cli/docker_rm.yaml b/data/cli/engine/docker_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_rm.yaml
rename to data/cli/engine/docker_rm.yaml
diff --git a/data/engine-cli/docker_rmi.yaml b/data/cli/engine/docker_rmi.yaml
similarity index 75%
rename from data/engine-cli/docker_rmi.yaml
rename to data/cli/engine/docker_rmi.yaml
index 312aaf1f4fa0..624e99639b95 100644
--- a/data/engine-cli/docker_rmi.yaml
+++ b/data/cli/engine/docker_rmi.yaml
@@ -27,6 +27,18 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: platform
+      value_type: stringSlice
+      default_value: '[]'
+      description: |
+        Remove only the given platform variant. Formatted as `os[/arch[/variant]]` (e.g., `linux/amd64`)
+      deprecated: false
+      hidden: false
+      min_api_version: "1.50"
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
 inherited_options:
     - option: help
       value_type: bool
diff --git a/data/engine-cli/docker_run.yaml b/data/cli/engine/docker_run.yaml
similarity index 98%
rename from data/engine-cli/docker_run.yaml
rename to data/cli/engine/docker_run.yaml
index 26cefcd309e0..b2f27bca7365 100644
--- a/data/engine-cli/docker_run.yaml
+++ b/data/cli/engine/docker_run.yaml
@@ -293,9 +293,9 @@ options:
     - option: disable-content-trust
       value_type: bool
       default_value: "true"
-      description: Skip image verification
-      deprecated: false
-      hidden: false
+      description: Skip image verification (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -530,7 +530,8 @@ options:
       swarm: false
       os_type: windows
     - option: ip
-      value_type: string
+      value_type: ip
+      default_value: <nil>
       description: IPv4 address (e.g., 172.30.100.104)
       deprecated: false
       hidden: false
@@ -539,7 +540,8 @@ options:
       kubernetes: false
       swarm: false
     - option: ip6
-      value_type: string
+      value_type: ip
+      default_value: <nil>
       description: IPv6 address (e.g., 2001:db8::33)
       deprecated: false
       hidden: false
@@ -568,9 +570,9 @@ options:
     - option: kernel-memory
       value_type: bytes
       default_value: "0"
-      description: Kernel memory limit
-      deprecated: false
-      hidden: false
+      description: Kernel memory limit (deprecated)
+      deprecated: true
+      hidden: true
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -984,6 +986,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: use-api-socket
+      value_type: bool
+      default_value: "false"
+      description: Bind mount Docker API socket and required auth
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: user
       shorthand: u
       value_type: string
diff --git a/data/engine-cli/docker_save.yaml b/data/cli/engine/docker_save.yaml
similarity index 85%
rename from data/engine-cli/docker_save.yaml
rename to data/cli/engine/docker_save.yaml
index f8876441f3e1..a983497a8007 100644
--- a/data/engine-cli/docker_save.yaml
+++ b/data/cli/engine/docker_save.yaml
@@ -17,9 +17,10 @@ options:
       kubernetes: false
       swarm: false
     - option: platform
-      value_type: string
+      value_type: stringSlice
+      default_value: '[]'
       description: |
-        Save only the given platform variant. Formatted as `os[/arch[/variant]]` (e.g., `linux/amd64`)
+        Save only the given platform(s). Formatted as a comma-separated list of `os[/arch[/variant]]` (e.g., `linux/amd64,linux/arm64/v8`)
       deprecated: false
       hidden: false
       min_api_version: "1.48"
diff --git a/data/engine-cli/docker_search.yaml b/data/cli/engine/docker_search.yaml
similarity index 99%
rename from data/engine-cli/docker_search.yaml
rename to data/cli/engine/docker_search.yaml
index f2b379e7c595..7df5eba91a16 100644
--- a/data/engine-cli/docker_search.yaml
+++ b/data/cli/engine/docker_search.yaml
@@ -164,7 +164,6 @@ examples: |-
     | `.Description` | Image description                              |
     | `.StarCount`   | Number of stars for the image                  |
     | `.IsOfficial`  | "OK" if image is official                      |
-    | `.IsAutomated` | "OK" if image build was automated (deprecated) |
 
     When you use the `--format` option, the `search` command will
     output the data exactly as the template declares. If you use the
diff --git a/data/engine-cli/docker_secret.yaml b/data/cli/engine/docker_secret.yaml
similarity index 100%
rename from data/engine-cli/docker_secret.yaml
rename to data/cli/engine/docker_secret.yaml
diff --git a/data/engine-cli/docker_secret_create.yaml b/data/cli/engine/docker_secret_create.yaml
similarity index 100%
rename from data/engine-cli/docker_secret_create.yaml
rename to data/cli/engine/docker_secret_create.yaml
diff --git a/data/engine-cli/docker_secret_inspect.yaml b/data/cli/engine/docker_secret_inspect.yaml
similarity index 100%
rename from data/engine-cli/docker_secret_inspect.yaml
rename to data/cli/engine/docker_secret_inspect.yaml
diff --git a/data/engine-cli/docker_secret_ls.yaml b/data/cli/engine/docker_secret_ls.yaml
similarity index 98%
rename from data/engine-cli/docker_secret_ls.yaml
rename to data/cli/engine/docker_secret_ls.yaml
index f31cd265b7b2..ce75105f05a1 100644
--- a/data/engine-cli/docker_secret_ls.yaml
+++ b/data/cli/engine/docker_secret_ls.yaml
@@ -115,7 +115,7 @@ examples: |-
     `project-a` value.
 
     ```console
-    $ docker service ls --filter label=project=test
+    $ docker secret ls --filter label=project=project-a
 
     ID                          NAME                        CREATED             UPDATED
     mem02h8n73mybpgqjf0kfi1n0   test_secret                 About an hour ago   About an hour ago
@@ -128,7 +128,7 @@ examples: |-
     The following filter matches secret with a name containing a prefix of `test`.
 
     ```console
-    $ docker secret ls --filter name=test_secret
+    $ docker secret ls --filter name=test
 
     ID                          NAME                        CREATED             UPDATED
     mem02h8n73mybpgqjf0kfi1n0   test_secret                 About an hour ago   About an hour ago
diff --git a/data/engine-cli/docker_secret_rm.yaml b/data/cli/engine/docker_secret_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_secret_rm.yaml
rename to data/cli/engine/docker_secret_rm.yaml
diff --git a/data/engine-cli/docker_service.yaml b/data/cli/engine/docker_service.yaml
similarity index 100%
rename from data/engine-cli/docker_service.yaml
rename to data/cli/engine/docker_service.yaml
diff --git a/data/engine-cli/docker_service_create.yaml b/data/cli/engine/docker_service_create.yaml
similarity index 97%
rename from data/engine-cli/docker_service_create.yaml
rename to data/cli/engine/docker_service_create.yaml
index 4a88cdc0f118..7653d2b94ab1 100644
--- a/data/engine-cli/docker_service_create.yaml
+++ b/data/cli/engine/docker_service_create.yaml
@@ -348,6 +348,28 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: memory-swap
+      value_type: bytes
+      default_value: "0"
+      description: Swap Bytes (-1 for unlimited)
+      deprecated: false
+      hidden: false
+      min_api_version: "1.52"
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: memory-swappiness
+      value_type: int64
+      default_value: "-1"
+      description: Tune memory swappiness (0-100), -1 to reset to default
+      deprecated: false
+      hidden: false
+      min_api_version: "1.52"
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: mode
       value_type: string
       default_value: replicated
@@ -1140,20 +1162,22 @@ examples: |-
             Read-only mounts are made recursively read-only if kernel is v5.12 or later.
             Otherwise the Engine raises an error.</li>
           </ul>
-          When the option is not specified, the default behavior correponds to setting <tt>enabled</tt>.
+          When the option is not specified, the default behavior corresponds to setting <tt>enabled</tt>.
         </td>
       </tr>
       <tr>
-        <td><b>bind-nonrecursive</b></td>
+        <td><b>bind-create-src</b></td>
         <td>
-          <tt>bind-nonrecursive</tt> is deprecated since Docker Engine v25.0.
-          Use <tt>bind-recursive</tt>instead.<br />
+          By default, bind mounts require the source path to exist on the daemon host. This is a significant difference
+          from the <tt>-v</tt> flag, which creates the source path if it doesn't exist.<br />
+          <br />
+          Set <tt>bind-create-src</tt> to create the source path on the daemon host if it doesn't exist.<br />
           <br />
           A value is optional:<br />
           <br />
           <ul>
-            <li><tt>true</tt> or <tt>1</tt>:  Equivalent to <tt>bind-recursive=disabled</tt>.</li>
-            <li><tt>false</tt> or <tt>0</tt>: Equivalent to <tt>bind-recursive=enabled</tt>.</li>
+            <li><tt>true</tt> or <tt>1</tt>: Create path on the daemon host if it doesn't exist.</li>
+            <li><tt>false</tt> or <tt>0</tt>: Default behavior. Produces an error if the source path doesn't exist on the daemon host.</li>
           </ul>
         </td>
       </tr>
@@ -1291,7 +1315,8 @@ examples: |-
 
     - When you use `--mount` with `type=bind`, the host-path must refer to an *existing*
       path on the host. The path will not be created for you and the service will fail
-      with an error if the path does not exist.
+      with an error if the path does not exist. You can use `bind-create-src` to
+      create the host path if it doesn't exist.
 
     - The `--mount` flag does not allow you to relabel a volume with `Z` or `z` flags,
       which are used for `selinux` labeling.
diff --git a/data/engine-cli/docker_service_inspect.yaml b/data/cli/engine/docker_service_inspect.yaml
similarity index 100%
rename from data/engine-cli/docker_service_inspect.yaml
rename to data/cli/engine/docker_service_inspect.yaml
diff --git a/data/engine-cli/docker_service_logs.yaml b/data/cli/engine/docker_service_logs.yaml
similarity index 100%
rename from data/engine-cli/docker_service_logs.yaml
rename to data/cli/engine/docker_service_logs.yaml
diff --git a/data/engine-cli/docker_service_ls.yaml b/data/cli/engine/docker_service_ls.yaml
similarity index 100%
rename from data/engine-cli/docker_service_ls.yaml
rename to data/cli/engine/docker_service_ls.yaml
diff --git a/data/engine-cli/docker_service_ps.yaml b/data/cli/engine/docker_service_ps.yaml
similarity index 100%
rename from data/engine-cli/docker_service_ps.yaml
rename to data/cli/engine/docker_service_ps.yaml
diff --git a/data/engine-cli/docker_service_rm.yaml b/data/cli/engine/docker_service_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_service_rm.yaml
rename to data/cli/engine/docker_service_rm.yaml
diff --git a/data/engine-cli/docker_service_rollback.yaml b/data/cli/engine/docker_service_rollback.yaml
similarity index 100%
rename from data/engine-cli/docker_service_rollback.yaml
rename to data/cli/engine/docker_service_rollback.yaml
diff --git a/data/engine-cli/docker_service_scale.yaml b/data/cli/engine/docker_service_scale.yaml
similarity index 100%
rename from data/engine-cli/docker_service_scale.yaml
rename to data/cli/engine/docker_service_scale.yaml
diff --git a/data/engine-cli/docker_service_update.yaml b/data/cli/engine/docker_service_update.yaml
similarity index 98%
rename from data/engine-cli/docker_service_update.yaml
rename to data/cli/engine/docker_service_update.yaml
index 72eabe4417c4..177ebd0f050c 100644
--- a/data/engine-cli/docker_service_update.yaml
+++ b/data/cli/engine/docker_service_update.yaml
@@ -239,6 +239,7 @@ options:
       description: Add a Generic resource
       deprecated: false
       hidden: false
+      min_api_version: "1.32"
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -248,6 +249,7 @@ options:
       description: Remove a Generic resource
       deprecated: false
       hidden: false
+      min_api_version: "1.32"
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -340,7 +342,7 @@ options:
       description: Add a custom host-to-IP mapping (`host:ip`)
       deprecated: false
       hidden: false
-      min_api_version: "1.32"
+      min_api_version: "1.25"
       experimental: false
       experimentalcli: false
       kubernetes: false
@@ -474,6 +476,28 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: memory-swap
+      value_type: bytes
+      default_value: "0"
+      description: Swap Bytes (-1 for unlimited)
+      deprecated: false
+      hidden: false
+      min_api_version: "1.52"
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: memory-swappiness
+      value_type: int64
+      default_value: "-1"
+      description: Tune memory swappiness (0-100), -1 to reset to default
+      deprecated: false
+      hidden: false
+      min_api_version: "1.52"
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: mount-add
       value_type: mount
       description: Add or update a mount on a service
diff --git a/data/engine-cli/docker_stack.yaml b/data/cli/engine/docker_stack.yaml
similarity index 100%
rename from data/engine-cli/docker_stack.yaml
rename to data/cli/engine/docker_stack.yaml
diff --git a/data/engine-cli/docker_stack_config.yaml b/data/cli/engine/docker_stack_config.yaml
similarity index 100%
rename from data/engine-cli/docker_stack_config.yaml
rename to data/cli/engine/docker_stack_config.yaml
diff --git a/data/engine-cli/docker_stack_deploy.yaml b/data/cli/engine/docker_stack_deploy.yaml
similarity index 100%
rename from data/engine-cli/docker_stack_deploy.yaml
rename to data/cli/engine/docker_stack_deploy.yaml
diff --git a/data/engine-cli/docker_stack_ls.yaml b/data/cli/engine/docker_stack_ls.yaml
similarity index 100%
rename from data/engine-cli/docker_stack_ls.yaml
rename to data/cli/engine/docker_stack_ls.yaml
diff --git a/data/engine-cli/docker_stack_ps.yaml b/data/cli/engine/docker_stack_ps.yaml
similarity index 98%
rename from data/engine-cli/docker_stack_ps.yaml
rename to data/cli/engine/docker_stack_ps.yaml
index daaee38f6254..7cb116cc9d20 100644
--- a/data/engine-cli/docker_stack_ps.yaml
+++ b/data/cli/engine/docker_stack_ps.yaml
@@ -255,14 +255,14 @@ examples: |-
     $ docker stack ps --no-trunc voting
 
     ID                          NAME                  IMAGE                                                                                                                 NODE   DESIRED STATE  CURREN STATE           ERROR  PORTS
-    xim5bcqtgk1bxqz91jzo4a1s5   voting_worker.1       dockersamples/examplevotingapp_worker:latest@sha256:3e4ddf59c15f432280a2c0679c4fc5a2ee5a797023c8ef0d3baf7b1385e9fed   node2  Running        Runnin 32 minutes ago
-    q7yik0ks1in6kv32gg6y6yjf7   voting_result.1       dockersamples/examplevotingapp_result:before@sha256:83b56996e930c292a6ae5187fda84dd6568a19d97cdb933720be15c757b7463   node1  Running        Runnin 32 minutes ago
-    rx5yo0866nfxc58zf4irsss6n   voting_vote.1         dockersamples/examplevotingapp_vote:before@sha256:8e64b182c87de902f2b72321c89b4af4e2b942d76d0b772532ff27ec4c6ebf6     node3  Running        Runnin 32 minutes ago
-    tz6j82jnwrx7n2offljp3mn03   voting_db.1           postgres:9.4@sha256:6046af499eae34d2074c0b53f9a8b404716d415e4a03e68bc1d2f8064f2b027                                   node1  Running        Runnin 32 minutes ago
-    w48spazhbmxcmbjfi54gs7x90   voting_redis.1        redis:alpine@sha256:9cd405cd1ec1410eaab064a1383d0d8854d1ef74a54e1e4a92fb4ec7bdc3ee7                                   node2  Running        Runnin 32 minutes ago
-    6jj1m02freg1n3z9n1evrzsbl   voting_visualizer.1   dockersamples/visualizer:stable@sha256:f924ad66c8e94b10baaf7bdb9cd491ef4e982a1d048a56a17e02bf5945401e5                node1  Running        Runnin 32 minutes ago
-    kqgdmededccbhz2wuc0e9hx7g   voting_vote.2         dockersamples/examplevotingapp_vote:before@sha256:8e64b182c87de902f2b72321c89b4af4e2b942d76d0b772532ff27ec4c6ebf6     node2  Running        Runnin 32 minutes ago
-    t72q3z038jehe1wbh9gdum076   voting_redis.2        redis:alpine@sha256:9cd405cd1ec1410eaab064a1383d0d8854d1ef74a54e1e4a92fb4ec7bdc3ee7                                   node3  Running        Runnin 32 minutes ago
+    xim5bcqtgk1bxqz91jzo4a1s5   voting_worker.1       dockersamples/examplevotingapp_worker:latest@sha256:3e4ddf59c15f432280a2c0679c4fc5a2ee5a797023c8ef0d3baf7b1385e9fed   node2  Running        Running 32 minutes ago
+    q7yik0ks1in6kv32gg6y6yjf7   voting_result.1       dockersamples/examplevotingapp_result:before@sha256:83b56996e930c292a6ae5187fda84dd6568a19d97cdb933720be15c757b7463   node1  Running        Running 32 minutes ago
+    rx5yo0866nfxc58zf4irsss6n   voting_vote.1         dockersamples/examplevotingapp_vote:before@sha256:8e64b182c87de902f2b72321c89b4af4e2b942d76d0b772532ff27ec4c6ebf6     node3  Running        Running 32 minutes ago
+    tz6j82jnwrx7n2offljp3mn03   voting_db.1           postgres:9.4@sha256:6046af499eae34d2074c0b53f9a8b404716d415e4a03e68bc1d2f8064f2b027                                   node1  Running        Running 32 minutes ago
+    w48spazhbmxcmbjfi54gs7x90   voting_redis.1        redis:alpine@sha256:9cd405cd1ec1410eaab064a1383d0d8854d1ef74a54e1e4a92fb4ec7bdc3ee7                                   node2  Running        Running 32 minutes ago
+    6jj1m02freg1n3z9n1evrzsbl   voting_visualizer.1   dockersamples/visualizer:stable@sha256:f924ad66c8e94b10baaf7bdb9cd491ef4e982a1d048a56a17e02bf5945401e5                node1  Running        Running 32 minutes ago
+    kqgdmededccbhz2wuc0e9hx7g   voting_vote.2         dockersamples/examplevotingapp_vote:before@sha256:8e64b182c87de902f2b72321c89b4af4e2b942d76d0b772532ff27ec4c6ebf6     node2  Running        Running 32 minutes ago
+    t72q3z038jehe1wbh9gdum076   voting_redis.2        redis:alpine@sha256:9cd405cd1ec1410eaab064a1383d0d8854d1ef74a54e1e4a92fb4ec7bdc3ee7                                   node3  Running        Running 32 minutes ago
     ```
 
     ### Only display task IDs (-q, --quiet) {#quiet}
diff --git a/data/engine-cli/docker_stack_rm.yaml b/data/cli/engine/docker_stack_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_stack_rm.yaml
rename to data/cli/engine/docker_stack_rm.yaml
diff --git a/data/engine-cli/docker_stack_services.yaml b/data/cli/engine/docker_stack_services.yaml
similarity index 100%
rename from data/engine-cli/docker_stack_services.yaml
rename to data/cli/engine/docker_stack_services.yaml
diff --git a/data/engine-cli/docker_start.yaml b/data/cli/engine/docker_start.yaml
similarity index 100%
rename from data/engine-cli/docker_start.yaml
rename to data/cli/engine/docker_start.yaml
diff --git a/data/engine-cli/docker_stats.yaml b/data/cli/engine/docker_stats.yaml
similarity index 100%
rename from data/engine-cli/docker_stats.yaml
rename to data/cli/engine/docker_stats.yaml
diff --git a/data/engine-cli/docker_stop.yaml b/data/cli/engine/docker_stop.yaml
similarity index 100%
rename from data/engine-cli/docker_stop.yaml
rename to data/cli/engine/docker_stop.yaml
diff --git a/data/engine-cli/docker_swarm.yaml b/data/cli/engine/docker_swarm.yaml
similarity index 100%
rename from data/engine-cli/docker_swarm.yaml
rename to data/cli/engine/docker_swarm.yaml
diff --git a/data/engine-cli/docker_swarm_ca.yaml b/data/cli/engine/docker_swarm_ca.yaml
similarity index 99%
rename from data/engine-cli/docker_swarm_ca.yaml
rename to data/cli/engine/docker_swarm_ca.yaml
index feaa95d8334a..a7fdad254c04 100644
--- a/data/engine-cli/docker_swarm_ca.yaml
+++ b/data/cli/engine/docker_swarm_ca.yaml
@@ -126,7 +126,7 @@ examples: |-
       rotated CA certificates:   [>                                                  ] 0/2 nodes
     ```
 
-    Once the rotation os finished (all the progress bars have completed) the now-current
+    Once the rotation is finished (all the progress bars have completed) the now-current
     CA certificate will be printed:
 
     ```console
diff --git a/data/engine-cli/docker_swarm_init.yaml b/data/cli/engine/docker_swarm_init.yaml
similarity index 98%
rename from data/engine-cli/docker_swarm_init.yaml
rename to data/cli/engine/docker_swarm_init.yaml
index 3344dd81ddc4..46fe99404668 100644
--- a/data/engine-cli/docker_swarm_init.yaml
+++ b/data/cli/engine/docker_swarm_init.yaml
@@ -194,7 +194,7 @@ examples: |-
 
     To add a worker to this swarm, run the following command:
 
-        docker swarm join --token SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx 172.17.0.2:2377
+        docker swarm join --token SWMTKN-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233... 172.17.0.2:2377
 
     To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
     ```
diff --git a/data/engine-cli/docker_swarm_join-token.yaml b/data/cli/engine/docker_swarm_join-token.yaml
similarity index 90%
rename from data/engine-cli/docker_swarm_join-token.yaml
rename to data/cli/engine/docker_swarm_join-token.yaml
index 69a69bb5cab2..3757d07ad1ed 100644
--- a/data/engine-cli/docker_swarm_join-token.yaml
+++ b/data/cli/engine/docker_swarm_join-token.yaml
@@ -63,7 +63,7 @@ examples: |-
     To add a worker to this swarm, run the following command:
 
         docker swarm join \
-        --token SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx \
+        --token SWMTKN-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233... \
         172.17.0.2:2377
 
     $ docker swarm join-token manager
@@ -71,7 +71,7 @@ examples: |-
     To add a manager to this swarm, run the following command:
 
         docker swarm join \
-        --token SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2 \
+        --token SWMTKN-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233... \
         172.17.0.2:2377
     ```
 
@@ -85,7 +85,7 @@ examples: |-
     To add a worker to this swarm, run the following command:
 
         docker swarm join \
-        --token SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-b30ljddcqhef9b9v4rs7mel7t \
+        --token SWMTKN-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233... \
         172.17.0.2:2377
     ```
 
@@ -96,7 +96,7 @@ examples: |-
     ```console
     $ docker swarm join-token -q worker
 
-    SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-b30ljddcqhef9b9v4rs7mel7t
+    SWMTKN-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233...
     ```
 
     ### `--rotate` {#rotate}
diff --git a/data/engine-cli/docker_swarm_join.yaml b/data/cli/engine/docker_swarm_join.yaml
similarity index 95%
rename from data/engine-cli/docker_swarm_join.yaml
rename to data/cli/engine/docker_swarm_join.yaml
index cab96ffe3db1..f1fa56196466 100644
--- a/data/engine-cli/docker_swarm_join.yaml
+++ b/data/cli/engine/docker_swarm_join.yaml
@@ -79,7 +79,7 @@ examples: |-
     The example below demonstrates joining a manager node using a manager token.
 
     ```console
-    $ docker swarm join --token SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2 192.168.99.121:2377
+    $ docker swarm join --token SWMTKN-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233... 192.168.99.121:2377
     This node joined a swarm as a manager.
 
     $ docker node ls
@@ -97,7 +97,7 @@ examples: |-
     The example below demonstrates joining a worker node using a worker token.
 
     ```console
-    $ docker swarm join --token SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx 192.168.99.121:2377
+    $ docker swarm join --token SWMTKN-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233... 192.168.99.121:2377
     This node joined a swarm as a worker.
 
     $ docker node ls
diff --git a/data/engine-cli/docker_swarm_leave.yaml b/data/cli/engine/docker_swarm_leave.yaml
similarity index 100%
rename from data/engine-cli/docker_swarm_leave.yaml
rename to data/cli/engine/docker_swarm_leave.yaml
diff --git a/data/engine-cli/docker_swarm_unlock-key.yaml b/data/cli/engine/docker_swarm_unlock-key.yaml
similarity index 91%
rename from data/engine-cli/docker_swarm_unlock-key.yaml
rename to data/cli/engine/docker_swarm_unlock-key.yaml
index 93ab3496fa47..0d0708202c93 100644
--- a/data/engine-cli/docker_swarm_unlock-key.yaml
+++ b/data/cli/engine/docker_swarm_unlock-key.yaml
@@ -58,7 +58,7 @@ examples: |-
     To unlock a swarm manager after it restarts, run the `docker swarm unlock`
     command and provide the following key:
 
-        SWMKEY-1-fySn8TY4w5lKcWcJPIpKufejh9hxx5KYwx6XZigx3Q4
+        SWMKEY-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233...
 
     Remember to store this key in a password manager, since without it you
     will not be able to restart the manager.
@@ -75,7 +75,7 @@ examples: |-
     To unlock a swarm manager after it restarts, run the `docker swarm unlock`
     command and provide the following key:
 
-        SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8
+        SWMKEY-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233...
 
     Remember to store this key in a password manager, since without it you
     will not be able to restart the manager.
@@ -86,7 +86,7 @@ examples: |-
     ```console
     $ docker swarm unlock-key -q
 
-    SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8
+    SWMKEY-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233...
     ```
 
     ### `--rotate` {#rotate}
diff --git a/data/engine-cli/docker_swarm_unlock.yaml b/data/cli/engine/docker_swarm_unlock.yaml
similarity index 100%
rename from data/engine-cli/docker_swarm_unlock.yaml
rename to data/cli/engine/docker_swarm_unlock.yaml
diff --git a/data/engine-cli/docker_swarm_update.yaml b/data/cli/engine/docker_swarm_update.yaml
similarity index 100%
rename from data/engine-cli/docker_swarm_update.yaml
rename to data/cli/engine/docker_swarm_update.yaml
diff --git a/data/engine-cli/docker_system.yaml b/data/cli/engine/docker_system.yaml
similarity index 100%
rename from data/engine-cli/docker_system.yaml
rename to data/cli/engine/docker_system.yaml
diff --git a/data/engine-cli/docker_system_df.yaml b/data/cli/engine/docker_system_df.yaml
similarity index 100%
rename from data/engine-cli/docker_system_df.yaml
rename to data/cli/engine/docker_system_df.yaml
diff --git a/data/engine-cli/docker_system_dial-stdio.yaml b/data/cli/engine/docker_system_dial-stdio.yaml
similarity index 100%
rename from data/engine-cli/docker_system_dial-stdio.yaml
rename to data/cli/engine/docker_system_dial-stdio.yaml
diff --git a/data/engine-cli/docker_system_events.yaml b/data/cli/engine/docker_system_events.yaml
similarity index 100%
rename from data/engine-cli/docker_system_events.yaml
rename to data/cli/engine/docker_system_events.yaml
diff --git a/data/engine-cli/docker_system_info.yaml b/data/cli/engine/docker_system_info.yaml
similarity index 100%
rename from data/engine-cli/docker_system_info.yaml
rename to data/cli/engine/docker_system_info.yaml
diff --git a/data/engine-cli/docker_system_prune.yaml b/data/cli/engine/docker_system_prune.yaml
similarity index 88%
rename from data/engine-cli/docker_system_prune.yaml
rename to data/cli/engine/docker_system_prune.yaml
index 1ae98cdc2e68..a3995b276f48 100644
--- a/data/engine-cli/docker_system_prune.yaml
+++ b/data/cli/engine/docker_system_prune.yaml
@@ -112,7 +112,8 @@ examples: |-
     my-network-b
 
     Deleted Volumes:
-    named-vol
+    1e31bcd425e913d9f65ec0c3841e9c4ebb543aead2a1cfe0d95a7c5e88bb5026
+    6a6ab3d6b8d740a1c1d4dbe36a9c5f043dd4bac5f78abfa7d1f2ae5789fe60b0
 
     Deleted Images:
     untagged: my-curl:latest
@@ -136,7 +137,19 @@ examples: |-
     ### Filtering (--filter) {#filter}
 
     The filtering flag (`--filter`) format is of "key=value". If there is more
-    than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`)
+    than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`).
+
+    When multiple filters are provided, they are combined as follows:
+
+    - Multiple filters with **different keys** are combined using AND logic.
+      An item must satisfy all filter conditions to be pruned.
+    - Multiple filters with the **same key** are combined using OR logic.
+      An item is pruned if it matches any of the values for that key.
+
+    For example, `--filter "label=foo" --filter "until=24h"` prunes items
+    that have the `foo` label **and** were created more than 24 hours ago.
+    Conversely, `--filter "label=foo" --filter "label=bar"` prunes items
+    that have **either** the `foo` **or** `bar` label.
 
     The currently supported filters are:
 
diff --git a/data/engine-cli/docker_tag.yaml b/data/cli/engine/docker_tag.yaml
similarity index 100%
rename from data/engine-cli/docker_tag.yaml
rename to data/cli/engine/docker_tag.yaml
diff --git a/data/engine-cli/docker_top.yaml b/data/cli/engine/docker_top.yaml
similarity index 100%
rename from data/engine-cli/docker_top.yaml
rename to data/cli/engine/docker_top.yaml
diff --git a/data/engine-cli/docker_trust.yaml b/data/cli/engine/docker_trust.yaml
similarity index 100%
rename from data/engine-cli/docker_trust.yaml
rename to data/cli/engine/docker_trust.yaml
diff --git a/data/engine-cli/docker_trust_inspect.yaml b/data/cli/engine/docker_trust_inspect.yaml
similarity index 100%
rename from data/engine-cli/docker_trust_inspect.yaml
rename to data/cli/engine/docker_trust_inspect.yaml
diff --git a/data/engine-cli/docker_trust_key.yaml b/data/cli/engine/docker_trust_key.yaml
similarity index 100%
rename from data/engine-cli/docker_trust_key.yaml
rename to data/cli/engine/docker_trust_key.yaml
diff --git a/data/engine-cli/docker_trust_key_generate.yaml b/data/cli/engine/docker_trust_key_generate.yaml
similarity index 100%
rename from data/engine-cli/docker_trust_key_generate.yaml
rename to data/cli/engine/docker_trust_key_generate.yaml
diff --git a/data/engine-cli/docker_trust_key_load.yaml b/data/cli/engine/docker_trust_key_load.yaml
similarity index 100%
rename from data/engine-cli/docker_trust_key_load.yaml
rename to data/cli/engine/docker_trust_key_load.yaml
diff --git a/data/engine-cli/docker_trust_revoke.yaml b/data/cli/engine/docker_trust_revoke.yaml
similarity index 100%
rename from data/engine-cli/docker_trust_revoke.yaml
rename to data/cli/engine/docker_trust_revoke.yaml
diff --git a/data/engine-cli/docker_trust_sign.yaml b/data/cli/engine/docker_trust_sign.yaml
similarity index 100%
rename from data/engine-cli/docker_trust_sign.yaml
rename to data/cli/engine/docker_trust_sign.yaml
diff --git a/data/engine-cli/docker_trust_signer.yaml b/data/cli/engine/docker_trust_signer.yaml
similarity index 100%
rename from data/engine-cli/docker_trust_signer.yaml
rename to data/cli/engine/docker_trust_signer.yaml
diff --git a/data/engine-cli/docker_trust_signer_add.yaml b/data/cli/engine/docker_trust_signer_add.yaml
similarity index 100%
rename from data/engine-cli/docker_trust_signer_add.yaml
rename to data/cli/engine/docker_trust_signer_add.yaml
diff --git a/data/engine-cli/docker_trust_signer_remove.yaml b/data/cli/engine/docker_trust_signer_remove.yaml
similarity index 100%
rename from data/engine-cli/docker_trust_signer_remove.yaml
rename to data/cli/engine/docker_trust_signer_remove.yaml
diff --git a/data/engine-cli/docker_unpause.yaml b/data/cli/engine/docker_unpause.yaml
similarity index 100%
rename from data/engine-cli/docker_unpause.yaml
rename to data/cli/engine/docker_unpause.yaml
diff --git a/data/engine-cli/docker_update.yaml b/data/cli/engine/docker_update.yaml
similarity index 100%
rename from data/engine-cli/docker_update.yaml
rename to data/cli/engine/docker_update.yaml
diff --git a/data/engine-cli/docker_version.yaml b/data/cli/engine/docker_version.yaml
similarity index 77%
rename from data/engine-cli/docker_version.yaml
rename to data/cli/engine/docker_version.yaml
index 88e35e84ee83..beff37ceb1f5 100644
--- a/data/engine-cli/docker_version.yaml
+++ b/data/cli/engine/docker_version.yaml
@@ -25,29 +25,29 @@ long: |-
     $ docker version
 
     Client: Docker Engine - Community
-     Version:           23.0.3
-     API version:       1.42
-     Go version:        go1.19.7
-     Git commit:        3e7cbfd
-     Built:             Tue Apr  4 22:05:41 2023
-     OS/Arch:           darwin/amd64
-     Context:           default
+     Version:           28.5.1
+     API version:       1.51
+     Go version:        go1.24.8
+     Git commit:        e180ab8
+     Built:             Wed Oct  8 12:16:17 2025
+     OS/Arch:           darwin/arm64
+     Context:           remote-test-server
 
     Server: Docker Desktop 4.19.0 (12345)
      Engine:
-      Version:          23.0.3
-      API version:      1.42 (minimum version 1.12)
-      Go version:       go1.19.7
-      Git commit:       59118bf
-      Built:            Tue Apr  4 22:05:41 2023
+      Version:          27.5.1
+      API version:      1.47 (minimum version 1.24)
+      Go version:       go1.22.11
+      Git commit:       4c9b3b0
+      Built:            Wed Jan 22 13:41:24 2025
       OS/Arch:          linux/amd64
-      Experimental:     false
+      Experimental:     true
      containerd:
-      Version:          1.6.20
-      GitCommit:        2806fc1057397dbaeefbea0e4e17bddfbd388f38
+      Version:          v1.7.25
+      GitCommit:        bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
      runc:
-      Version:          1.1.5
-      GitCommit:        v1.1.5-0-gf19387a
+      Version:          1.2.4
+      GitCommit:        v1.2.4-0-g6c52b3f
      docker-init:
       Version:          0.19.0
       GitCommit:        de40ad0
@@ -70,31 +70,32 @@ long: |-
     $ docker version
 
     Client: Docker Engine - Community
-     Version:           23.0.3
-     API version:       1.40 (downgraded from 1.42)
-     Go version:        go1.19.7
-     Git commit:        3e7cbfd
-     Built:             Tue Apr  4 22:05:41 2023
-     OS/Arch:           darwin/amd64
+     Version:           28.5.1
+     API version:       1.51
+     Go version:        go1.24.8
+     Git commit:        e180ab8
+     Built:             Wed Oct  8 12:16:17 2025
+     OS/Arch:           darwin/arm64
      Context:           remote-test-server
 
     Server: Docker Engine - Community
      Engine:
-      Version:          19.03.8
-      API version:      1.40 (minimum version 1.12)
-      Go version:       go1.12.17
-      Git commit:       afacb8b
-      Built:            Wed Mar 11 01:29:16 2020
+      Version:          27.5.1
+      API version:      1.47 (minimum version 1.24)
+      Go version:       go1.22.11
+      Git commit:       4c9b3b0
+      Built:            Wed Jan 22 13:41:24 2025
       OS/Arch:          linux/amd64
+      Experimental:     true
      containerd:
-      Version:          v1.2.13
-      GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
+      Version:          v1.7.25
+      GitCommit:        bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
      runc:
-      Version:          1.0.0-rc10
-      GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
+      Version:          1.2.4
+      GitCommit:        v1.2.4-0-g6c52b3f
      docker-init:
-      Version:          0.18.0
-      GitCommit:        fec3683
+      Version:          0.19.0
+      GitCommit:        de40ad0
     ```
 
     ### API version and version negotiation
@@ -104,14 +105,14 @@ long: |-
     and Docker Engine perform API version negotiation, and select the highest API
     version that is supported by both the Docker CLI and the Docker Engine.
 
-    For example, if the CLI is connecting with Docker Engine version 19.03, it downgrades
-    to API version 1.40 (refer to the [API version matrix](/reference/api/engine/#api-version-matrix)
+    For example, if the CLI is connecting with Docker Engine version 27.5, it downgrades
+    to API version 1.47 (refer to the [API version matrix](/reference/api/engine/#api-version-matrix)
     to learn about the supported API versions for Docker Engine):
 
     ```console
     $ docker version --format '{{.Client.APIVersion}}'
 
-    1.40
+    1.47
     ```
 
     Be aware that API version can also be overridden using the `DOCKER_API_VERSION`
@@ -122,14 +123,14 @@ long: |-
 
     ```console
     $ env | grep DOCKER_API_VERSION
-    DOCKER_API_VERSION=1.39
+    DOCKER_API_VERSION=1.50
 
     $ docker version --format '{{.Client.APIVersion}}'
-    1.39
+    1.50
 
     $ unset DOCKER_API_VERSION
     $ docker version --format '{{.Client.APIVersion}}'
-    1.42
+    1.51
     ```
 usage: docker version [OPTIONS]
 pname: docker
@@ -174,7 +175,7 @@ examples: |-
     ```console
     $ docker version --format '{{.Server.Version}}'
 
-    23.0.3
+    28.5.1
     ```
 
     ### Get the client API version
@@ -184,7 +185,7 @@ examples: |-
     ```console
     $ docker version --format '{{.Client.APIVersion}}'
 
-    1.42
+    1.51
     ```
 
     The version shown is the API version that is negotiated between the client
@@ -196,7 +197,7 @@ examples: |-
     ```console
     $ docker version --format '{{json .}}'
 
-    {"Client":"Version":"23.0.3","ApiVersion":"1.42", ...}
+    {"Client":"Version":"28.5.1","ApiVersion":"1.51", ...}
     ```
 deprecated: false
 hidden: false
diff --git a/data/engine-cli/docker_volume.yaml b/data/cli/engine/docker_volume.yaml
similarity index 100%
rename from data/engine-cli/docker_volume.yaml
rename to data/cli/engine/docker_volume.yaml
diff --git a/data/engine-cli/docker_volume_create.yaml b/data/cli/engine/docker_volume_create.yaml
similarity index 100%
rename from data/engine-cli/docker_volume_create.yaml
rename to data/cli/engine/docker_volume_create.yaml
diff --git a/data/engine-cli/docker_volume_inspect.yaml b/data/cli/engine/docker_volume_inspect.yaml
similarity index 100%
rename from data/engine-cli/docker_volume_inspect.yaml
rename to data/cli/engine/docker_volume_inspect.yaml
diff --git a/data/engine-cli/docker_volume_ls.yaml b/data/cli/engine/docker_volume_ls.yaml
similarity index 100%
rename from data/engine-cli/docker_volume_ls.yaml
rename to data/cli/engine/docker_volume_ls.yaml
diff --git a/data/engine-cli/docker_volume_prune.yaml b/data/cli/engine/docker_volume_prune.yaml
similarity index 80%
rename from data/engine-cli/docker_volume_prune.yaml
rename to data/cli/engine/docker_volume_prune.yaml
index 0e996b516b91..541c9fa266c9 100644
--- a/data/engine-cli/docker_volume_prune.yaml
+++ b/data/cli/engine/docker_volume_prune.yaml
@@ -60,7 +60,6 @@ examples: |-
     Are you sure you want to continue? [y/N] y
     Deleted Volumes:
     07c7bdf3e34ab76d921894c2b834f073721fccfbbcba792aa7648e3a7a664c2e
-    my-named-vol
 
     Total reclaimed space: 36 B
     ```
@@ -72,7 +71,19 @@ examples: |-
     ### Filtering (--filter) {#filter}
 
     The filtering flag (`--filter`) format is of "key=value". If there is more
-    than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`)
+    than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`).
+
+    When multiple filters are provided, they are combined as follows:
+
+    - Multiple filters with **different keys** are combined using AND logic.
+      A volume must satisfy all filter conditions to be pruned.
+    - Multiple filters with the **same key** are combined using OR logic.
+      A volume is pruned if it matches any of the values for that key.
+
+    For example, `--filter "label=foo" --filter "label=bar"` prunes volumes that
+    have **either** the `foo` **or** `bar` label, while
+    `--filter "label=foo" --filter "label!=bar"` prunes volumes that have the
+    `foo` label **and** do not have the `bar` label.
 
     The currently supported filters are:
 
diff --git a/data/engine-cli/docker_volume_rm.yaml b/data/cli/engine/docker_volume_rm.yaml
similarity index 100%
rename from data/engine-cli/docker_volume_rm.yaml
rename to data/cli/engine/docker_volume_rm.yaml
diff --git a/data/engine-cli/docker_volume_update.yaml b/data/cli/engine/docker_volume_update.yaml
similarity index 100%
rename from data/engine-cli/docker_volume_update.yaml
rename to data/cli/engine/docker_volume_update.yaml
diff --git a/data/engine-cli/docker_wait.yaml b/data/cli/engine/docker_wait.yaml
similarity index 100%
rename from data/engine-cli/docker_wait.yaml
rename to data/cli/engine/docker_wait.yaml
diff --git a/data/init-cli/docker_init.yaml b/data/cli/init/docker_init.yaml
similarity index 100%
rename from data/init-cli/docker_init.yaml
rename to data/cli/init/docker_init.yaml
diff --git a/data/cli/mcp/docker_mcp.yaml b/data/cli/mcp/docker_mcp.yaml
new file mode 100644
index 000000000000..b781c1cf71e6
--- /dev/null
+++ b/data/cli/mcp/docker_mcp.yaml
@@ -0,0 +1,49 @@
+command: docker mcp
+short: Manage MCP servers and clients
+long: |-
+    The MCP Gateway is Docker's open-source enterprise solution for orchestrating
+    Model Context Protocol (MCP) servers and clients.
+
+    For more information see [Docker MCP](/ai/mcp-gateway/) and
+    the public [GitHub repository](https://github.com/docker/mcp-gateway).
+pname: docker
+plink: docker.yaml
+cname:
+    - docker mcp catalog
+    - docker mcp client
+    - docker mcp feature
+    - docker mcp gateway
+    - docker mcp profile
+    - docker mcp secret
+    - docker mcp server
+    - docker mcp tools
+    - docker mcp version
+clink:
+    - docker_mcp_catalog.yaml
+    - docker_mcp_client.yaml
+    - docker_mcp_feature.yaml
+    - docker_mcp_gateway.yaml
+    - docker_mcp_profile.yaml
+    - docker_mcp_secret.yaml
+    - docker_mcp_server.yaml
+    - docker_mcp_tools.yaml
+    - docker_mcp_version.yaml
+options:
+    - option: version
+      shorthand: v
+      value_type: bool
+      default_value: "false"
+      description: Print version information and quit
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog.yaml b/data/cli/mcp/docker_mcp_catalog.yaml
new file mode 100644
index 000000000000..ed5bd59a080f
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog.yaml
@@ -0,0 +1,31 @@
+command: docker mcp catalog
+aliases: docker mcp catalog, docker mcp catalogs, docker mcp catalog-next
+short: Manage MCP server OCI catalogs
+long: Manage MCP server OCI catalogs
+pname: docker mcp
+plink: docker_mcp.yaml
+cname:
+    - docker mcp catalog create
+    - docker mcp catalog list
+    - docker mcp catalog pull
+    - docker mcp catalog push
+    - docker mcp catalog remove
+    - docker mcp catalog server
+    - docker mcp catalog show
+    - docker mcp catalog tag
+clink:
+    - docker_mcp_catalog_create.yaml
+    - docker_mcp_catalog_list.yaml
+    - docker_mcp_catalog_pull.yaml
+    - docker_mcp_catalog_push.yaml
+    - docker_mcp_catalog_remove.yaml
+    - docker_mcp_catalog_server.yaml
+    - docker_mcp_catalog_show.yaml
+    - docker_mcp_catalog_tag.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_create.yaml b/data/cli/mcp/docker_mcp_catalog_create.yaml
new file mode 100644
index 000000000000..081d2666b5cf
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_create.yaml
@@ -0,0 +1,64 @@
+command: docker mcp catalog create
+short: |
+    Create a new catalog from a profile, legacy catalog, or community registry
+long: |
+    Create a new catalog from a profile, legacy catalog, or community registry
+usage: docker mcp catalog create <oci-reference> [--server <ref1> --server <ref2> ...] [--from-profile <profile-id>] [--from-legacy-catalog <url>] [--from-community-registry <hostname>] [--title <title>]
+pname: docker mcp catalog
+plink: docker_mcp_catalog.yaml
+options:
+    - option: from-community-registry
+      value_type: string
+      description: |
+        Community registry hostname to fetch servers from (e.g. registry.modelcontextprotocol.io)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: from-legacy-catalog
+      value_type: string
+      description: Legacy catalog URL to create the catalog from
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: from-profile
+      value_type: string
+      description: Profile ID to create the catalog from
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: server
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Server to include specified with a URI: https:// (MCP Registry reference) or docker:// (Docker Image reference) or catalog:// (Catalog reference) or file:// (Local file path). Can be specified multiple times.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: title
+      value_type: string
+      description: Title of the catalog
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_list.yaml b/data/cli/mcp/docker_mcp_catalog_list.yaml
new file mode 100644
index 000000000000..fe0cbe5caaa2
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_list.yaml
@@ -0,0 +1,25 @@
+command: docker mcp catalog list
+aliases: docker mcp catalog list, docker mcp catalog ls
+short: List catalogs
+long: List catalogs
+usage: docker mcp catalog list
+pname: docker mcp catalog
+plink: docker_mcp_catalog.yaml
+options:
+    - option: format
+      value_type: string
+      default_value: human
+      description: 'Supported: json, yaml, human.'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_ls.yaml b/data/cli/mcp/docker_mcp_catalog_ls.yaml
new file mode 100644
index 000000000000..19d88c99c862
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_ls.yaml
@@ -0,0 +1,30 @@
+command: docker mcp catalog ls
+short: List all configured catalogs
+long: |
+    List all configured catalogs including Docker's official catalog and any locally managed catalogs.
+usage: docker mcp catalog ls
+pname: docker mcp catalog
+plink: docker_mcp_catalog.yaml
+options:
+    - option: format
+      value_type: format
+      description: 'Output format. Supported: "json", "yaml".'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |4-
+      # List all catalogs
+      docker mcp catalog ls
+
+      # List catalogs in JSON format
+      docker mcp catalog ls --format=json
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_pull.yaml b/data/cli/mcp/docker_mcp_catalog_pull.yaml
new file mode 100644
index 000000000000..bd5b40eb7828
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_pull.yaml
@@ -0,0 +1,13 @@
+command: docker mcp catalog pull
+short: Pull a catalog from an OCI registry
+long: Pull a catalog from an OCI registry
+usage: docker mcp catalog pull <oci-reference>
+pname: docker mcp catalog
+plink: docker_mcp_catalog.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_push.yaml b/data/cli/mcp/docker_mcp_catalog_push.yaml
new file mode 100644
index 000000000000..a21ed307bb7d
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_push.yaml
@@ -0,0 +1,13 @@
+command: docker mcp catalog push
+short: Push a catalog to an OCI registry
+long: Push a catalog to an OCI registry
+usage: docker mcp catalog push <oci-reference>
+pname: docker mcp catalog
+plink: docker_mcp_catalog.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_remove.yaml b/data/cli/mcp/docker_mcp_catalog_remove.yaml
new file mode 100644
index 000000000000..a78794cc6343
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_remove.yaml
@@ -0,0 +1,14 @@
+command: docker mcp catalog remove
+aliases: docker mcp catalog remove, docker mcp catalog rm
+short: Remove a catalog
+long: Remove a catalog
+usage: docker mcp catalog remove <oci-reference>
+pname: docker mcp catalog
+plink: docker_mcp_catalog.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_rm.yaml b/data/cli/mcp/docker_mcp_catalog_rm.yaml
new file mode 100644
index 000000000000..4e2e9dacc79f
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_rm.yaml
@@ -0,0 +1,18 @@
+command: docker mcp catalog rm
+short: Remove a catalog
+long: |-
+    Remove a locally configured catalog. This will delete the catalog and all its server definitions.
+    The Docker official catalog cannot be removed.
+usage: docker mcp catalog rm <name>
+pname: docker mcp catalog
+plink: docker_mcp_catalog.yaml
+examples: |4-
+      # Remove a catalog
+      docker mcp catalog rm old-servers
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_server.yaml b/data/cli/mcp/docker_mcp_catalog_server.yaml
new file mode 100644
index 000000000000..0a7e803e5e14
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_server.yaml
@@ -0,0 +1,22 @@
+command: docker mcp catalog server
+short: Manage servers in catalogs
+long: Manage servers in catalogs
+pname: docker mcp catalog
+plink: docker_mcp_catalog.yaml
+cname:
+    - docker mcp catalog server add
+    - docker mcp catalog server inspect
+    - docker mcp catalog server ls
+    - docker mcp catalog server remove
+clink:
+    - docker_mcp_catalog_server_add.yaml
+    - docker_mcp_catalog_server_inspect.yaml
+    - docker_mcp_catalog_server_ls.yaml
+    - docker_mcp_catalog_server_remove.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_server_add.yaml b/data/cli/mcp/docker_mcp_catalog_server_add.yaml
new file mode 100644
index 000000000000..8d1bf5b6268f
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_server_add.yaml
@@ -0,0 +1,37 @@
+command: docker mcp catalog server add
+short: Add MCP servers to a catalog
+long: Add MCP servers to a catalog using various URI schemes.
+usage: docker mcp catalog server add <oci-reference> [--server <ref1> --server <ref2> ...]
+pname: docker mcp catalog server
+plink: docker_mcp_catalog_server.yaml
+options:
+    - option: server
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Server to include specified with a URI: https:// (MCP Registry reference) or docker:// (Docker Image reference) or catalog:// (Catalog reference) or file:// (Local file path). Can be specified multiple times.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |4-
+      # Add servers from another catalog
+      docker mcp catalog server add mcp/my-catalog:latest --server catalog://mcp/docker-mcp-catalog:latest/github
+
+      # Add servers with OCI references
+      docker mcp catalog server add mcp/my-catalog:latest --server docker://my-server:latest
+
+      # Add servers with MCP Registry references
+      docker mcp catalog server add mcp/my-catalog:latest --server https://registry.modelcontextprotocol.io/v0/servers/71de5a2a-6cfb-4250-a196-f93080ecc860
+
+      # Mix server references
+      docker mcp catalog server add mcp/my-catalog:latest --server catalog://mcp/docker-mcp-catalog:latest/github --server docker://my-server:latest
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_server_inspect.yaml b/data/cli/mcp/docker_mcp_catalog_server_inspect.yaml
new file mode 100644
index 000000000000..45a8622060ff
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_server_inspect.yaml
@@ -0,0 +1,24 @@
+command: docker mcp catalog server inspect
+short: Inspect a server in a catalog
+long: Inspect a server in a catalog
+usage: docker mcp catalog server inspect <oci-reference> <server-name>
+pname: docker mcp catalog server
+plink: docker_mcp_catalog_server.yaml
+options:
+    - option: format
+      value_type: string
+      default_value: human
+      description: 'Supported: json, yaml, human.'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_server_ls.yaml b/data/cli/mcp/docker_mcp_catalog_server_ls.yaml
new file mode 100644
index 000000000000..45c287b3f3a6
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_server_ls.yaml
@@ -0,0 +1,52 @@
+command: docker mcp catalog server ls
+aliases: docker mcp catalog server ls, docker mcp catalog server list
+short: List servers in a catalog
+long: |-
+    List all servers in a catalog.
+
+    Use --filter to search for servers matching a query (case-insensitive substring matching on server names).
+    Filters use key=value format (e.g., name=github).
+usage: docker mcp catalog server ls <oci-reference>
+pname: docker mcp catalog server
+plink: docker_mcp_catalog_server.yaml
+options:
+    - option: filter
+      shorthand: f
+      value_type: stringArray
+      default_value: '[]'
+      description: Filter output (e.g., name=github)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: format
+      value_type: string
+      default_value: human
+      description: 'Supported: json, yaml, human.'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |4-
+      # List all servers in a catalog
+      docker mcp catalog server ls mcp/docker-mcp-catalog:latest
+
+      # Filter servers by name
+      docker mcp catalog server ls mcp/docker-mcp-catalog:latest --filter name=github
+
+      # Combine multiple filters (using short flag)
+      docker mcp catalog server ls mcp/docker-mcp-catalog:latest -f name=slack -f name=github
+
+      # Output in JSON format
+      docker mcp catalog server ls mcp/docker-mcp-catalog:latest --format json
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_server_remove.yaml b/data/cli/mcp/docker_mcp_catalog_server_remove.yaml
new file mode 100644
index 000000000000..96ca3c9176e1
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_server_remove.yaml
@@ -0,0 +1,31 @@
+command: docker mcp catalog server remove
+aliases: docker mcp catalog server remove, docker mcp catalog server rm
+short: Remove MCP servers from a catalog
+long: Remove MCP servers from a catalog by server name.
+usage: docker mcp catalog server remove <oci-reference> --name <name1> --name <name2> ...
+pname: docker mcp catalog server
+plink: docker_mcp_catalog_server.yaml
+options:
+    - option: name
+      value_type: stringArray
+      default_value: '[]'
+      description: Server name to remove (can be specified multiple times)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |4-
+      # Remove servers by name
+      docker mcp catalog server remove mcp/my-catalog:latest --name github --name slack
+
+      # Remove a single server
+      docker mcp catalog server remove mcp/my-catalog:latest --name github
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_show.yaml b/data/cli/mcp/docker_mcp_catalog_show.yaml
new file mode 100644
index 000000000000..49fdbdc70192
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_show.yaml
@@ -0,0 +1,54 @@
+command: docker mcp catalog show
+short: Show a catalog
+long: Show a catalog
+usage: docker mcp catalog show <oci-reference> [--pull <pull-option>]
+pname: docker mcp catalog
+plink: docker_mcp_catalog.yaml
+options:
+    - option: format
+      value_type: string
+      default_value: human
+      description: 'Supported: json, yaml, human.'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: no-tools
+      value_type: bool
+      default_value: "false"
+      description: Exclude tools from output (deprecated, use --yq instead)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: pull
+      value_type: string
+      default_value: never
+      description: |
+        Supported: missing, never, always, initial, exists, or duration (e.g. '1h', '1d'). Duration represents time since last update.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: yq
+      value_type: string
+      description: YQ expression to apply to the output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_catalog_tag.yaml b/data/cli/mcp/docker_mcp_catalog_tag.yaml
new file mode 100644
index 000000000000..8faf0a037a92
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_catalog_tag.yaml
@@ -0,0 +1,24 @@
+command: docker mcp catalog tag
+short: Create a tagged copy of a catalog
+long: |-
+    Create a new catalog by tagging an existing catalog with a new name or version.
+    This creates a copy of the source catalog with a new reference, similar to Docker image tagging.
+usage: docker mcp catalog tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
+pname: docker mcp catalog
+plink: docker_mcp_catalog.yaml
+examples: |4-
+      # Tag a catalog with a new version
+      docker mcp catalog tag mcp/my-catalog:v1 mcp/my-catalog:v2
+
+      # Create a tagged copy with a different name
+      docker mcp catalog tag mcp/team-catalog:latest mcp/prod-catalog:v1.0
+
+      # Tag without explicit version (uses latest)
+      docker mcp catalog tag mcp/my-catalog mcp/my-catalog:backup
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_client.yaml b/data/cli/mcp/docker_mcp_client.yaml
new file mode 100644
index 000000000000..feaf1592f2a9
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_client.yaml
@@ -0,0 +1,20 @@
+command: docker mcp client
+short: Manage MCP clients
+long: Manage MCP clients
+pname: docker mcp
+plink: docker_mcp.yaml
+cname:
+    - docker mcp client connect
+    - docker mcp client disconnect
+    - docker mcp client ls
+clink:
+    - docker_mcp_client_connect.yaml
+    - docker_mcp_client_disconnect.yaml
+    - docker_mcp_client_ls.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_client_connect.yaml b/data/cli/mcp/docker_mcp_client_connect.yaml
new file mode 100644
index 000000000000..a4901a215472
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_client_connect.yaml
@@ -0,0 +1,52 @@
+command: docker mcp client connect
+short: |
+    Connect the Docker MCP Toolkit to a client. Supported clients: claude-code claude-desktop cline codex continue crush cursor gemini goose gordon kiro lmstudio opencode sema4 vscode zed
+long: |
+    Connect the Docker MCP Toolkit to a client. Supported clients: claude-code claude-desktop cline codex continue crush cursor gemini goose gordon kiro lmstudio opencode sema4 vscode zed
+usage: |-
+    docker mcp client connect [OPTIONS] <mcp-client>
+
+    Supported clients: claude-code claude-desktop cline codex continue crush cursor gemini goose gordon kiro lmstudio opencode sema4 vscode zed
+pname: docker mcp client
+plink: docker_mcp_client.yaml
+options:
+    - option: global
+      shorthand: g
+      value_type: bool
+      default_value: "false"
+      description: |
+        Change the system wide configuration or the clients setup in your current git repo.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: profile
+      shorthand: p
+      value_type: string
+      description: Profile to use for client connection.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: quiet
+      shorthand: q
+      value_type: bool
+      default_value: "false"
+      description: Only display errors.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_client_disconnect.yaml b/data/cli/mcp/docker_mcp_client_disconnect.yaml
new file mode 100644
index 000000000000..bcf4bcbc5cb0
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_client_disconnect.yaml
@@ -0,0 +1,42 @@
+command: docker mcp client disconnect
+short: |
+    Disconnect the Docker MCP Toolkit from a client. Supported clients: claude-code claude-desktop cline codex continue crush cursor gemini goose gordon kiro lmstudio opencode sema4 vscode zed
+long: |
+    Disconnect the Docker MCP Toolkit from a client. Supported clients: claude-code claude-desktop cline codex continue crush cursor gemini goose gordon kiro lmstudio opencode sema4 vscode zed
+usage: |-
+    docker mcp client disconnect [OPTIONS] <mcp-client>
+
+    Supported clients: claude-code claude-desktop cline codex continue crush cursor gemini goose gordon kiro lmstudio opencode sema4 vscode zed
+pname: docker mcp client
+plink: docker_mcp_client.yaml
+options:
+    - option: global
+      shorthand: g
+      value_type: bool
+      default_value: "false"
+      description: |
+        Change the system wide configuration or the clients setup in your current git repo.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: quiet
+      shorthand: q
+      value_type: bool
+      default_value: "false"
+      description: Only display errors.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_client_ls.yaml b/data/cli/mcp/docker_mcp_client_ls.yaml
new file mode 100644
index 000000000000..8b32aeb02fb1
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_client_ls.yaml
@@ -0,0 +1,36 @@
+command: docker mcp client ls
+short: List client configurations
+long: List client configurations
+usage: docker mcp client ls
+pname: docker mcp client
+plink: docker_mcp_client.yaml
+options:
+    - option: global
+      shorthand: g
+      value_type: bool
+      default_value: "false"
+      description: |
+        Change the system wide configuration or the clients setup in your current git repo.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Print as JSON.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_feature.yaml b/data/cli/mcp/docker_mcp_feature.yaml
new file mode 100644
index 000000000000..5c554f2873aa
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_feature.yaml
@@ -0,0 +1,24 @@
+command: docker mcp feature
+short: Manage experimental features
+long: |-
+    Manage experimental features for Docker MCP Gateway.
+
+    Features are stored in your Docker configuration file (~/.docker/config.json)
+    and control optional functionality that may change in future versions.
+pname: docker mcp
+plink: docker_mcp.yaml
+cname:
+    - docker mcp feature disable
+    - docker mcp feature enable
+    - docker mcp feature ls
+clink:
+    - docker_mcp_feature_disable.yaml
+    - docker_mcp_feature_enable.yaml
+    - docker_mcp_feature_ls.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_feature_disable.yaml b/data/cli/mcp/docker_mcp_feature_disable.yaml
new file mode 100644
index 000000000000..4304c4e8efde
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_feature_disable.yaml
@@ -0,0 +1,13 @@
+command: docker mcp feature disable
+short: Disable an experimental feature
+long: Disable an experimental feature that was previously enabled.
+usage: docker mcp feature disable <feature-name>
+pname: docker mcp feature
+plink: docker_mcp_feature.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_feature_enable.yaml b/data/cli/mcp/docker_mcp_feature_enable.yaml
new file mode 100644
index 000000000000..997de601d44f
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_feature_enable.yaml
@@ -0,0 +1,21 @@
+command: docker mcp feature enable
+short: Enable an experimental feature
+long: |-
+    Enable an experimental feature.
+
+    Available features:
+      oauth-interceptor      Enable GitHub OAuth flow interception for automatic authentication
+      mcp-oauth-dcr          Enable Dynamic Client Registration (DCR) for automatic OAuth client setup
+      dynamic-tools          Enable internal MCP management tools (mcp-find, mcp-add, mcp-remove)
+    	profiles               Enable profile management (docker mcp profile <subcommand>)
+      tool-name-prefix       Prefix all tool names with server name to avoid conflicts
+usage: docker mcp feature enable <feature-name>
+pname: docker mcp feature
+plink: docker_mcp_feature.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_feature_list.yaml b/data/cli/mcp/docker_mcp_feature_list.yaml
new file mode 100644
index 000000000000..19f779f5a5b5
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_feature_list.yaml
@@ -0,0 +1,14 @@
+command: docker mcp feature list
+short: List all available features and their status
+long: |
+    List all available experimental features and show whether they are enabled or disabled.
+usage: docker mcp feature list
+pname: docker mcp feature
+plink: docker_mcp_feature.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_feature_ls.yaml b/data/cli/mcp/docker_mcp_feature_ls.yaml
new file mode 100644
index 000000000000..6901df268a32
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_feature_ls.yaml
@@ -0,0 +1,15 @@
+command: docker mcp feature ls
+aliases: docker mcp feature ls, docker mcp feature list
+short: List all available features and their status
+long: |
+    List all available experimental features and show whether they are enabled or disabled.
+usage: docker mcp feature ls
+pname: docker mcp feature
+plink: docker_mcp_feature.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_gateway.yaml b/data/cli/mcp/docker_mcp_gateway.yaml
new file mode 100644
index 000000000000..86a5d78f10d7
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_gateway.yaml
@@ -0,0 +1,16 @@
+command: docker mcp gateway
+short: Manage the MCP Server gateway
+long: Manage the MCP Server gateway
+pname: docker mcp
+plink: docker_mcp.yaml
+cname:
+    - docker mcp gateway run
+clink:
+    - docker_mcp_gateway_run.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_gateway_run.yaml b/data/cli/mcp/docker_mcp_gateway_run.yaml
new file mode 100644
index 000000000000..2b39954fa2b6
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_gateway_run.yaml
@@ -0,0 +1,332 @@
+command: docker mcp gateway run
+short: Run the gateway
+long: Run the gateway
+usage: docker mcp gateway run
+pname: docker mcp gateway
+plink: docker_mcp_gateway.yaml
+options:
+    - option: additional-catalog
+      value_type: stringSlice
+      default_value: '[]'
+      description: Additional catalog paths to append to the default catalogs
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: additional-config
+      value_type: stringSlice
+      default_value: '[]'
+      description: Additional config paths to merge with the default config.yaml
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: additional-registry
+      value_type: stringSlice
+      default_value: '[]'
+      description: Additional registry paths to merge with the default registry.yaml
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: additional-tools-config
+      value_type: stringSlice
+      default_value: '[]'
+      description: Additional tools paths to merge with the default tools.yaml
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: block-network
+      value_type: bool
+      default_value: "false"
+      description: Block tools from accessing forbidden network resources
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: block-secrets
+      value_type: bool
+      default_value: "true"
+      description: Block secrets from being/received sent to/from tools
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: catalog
+      value_type: stringSlice
+      default_value: '[]'
+      description: |
+        Paths to docker catalogs (absolute or relative to ~/.docker/mcp/catalogs/)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: config
+      value_type: stringSlice
+      default_value: '[]'
+      description: Paths to the config files (absolute or relative to ~/.docker/mcp/)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: cpus
+      value_type: int
+      default_value: "1"
+      description: CPUs allocated to each MCP Server (default is 1)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: debug-dns
+      value_type: bool
+      default_value: "false"
+      description: Debug DNS resolution
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: dry-run
+      value_type: bool
+      default_value: "false"
+      description: |
+        Start the gateway but do not listen for connections (useful for testing the configuration)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: enable-all-servers
+      value_type: bool
+      default_value: "false"
+      description: |
+        Enable all servers in the catalog (instead of using individual --servers options)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: interceptor
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        List of interceptors to use (format: when:type:path, e.g. 'before:exec:/bin/path')
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: log
+      value_type: string
+      description: Path to log file for stderr output (relative or absolute)
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: log-calls
+      value_type: bool
+      default_value: "true"
+      description: Log calls to the tools
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: long-lived
+      value_type: bool
+      default_value: "false"
+      description: |
+        Containers are long-lived and will not be removed until the gateway is stopped, useful for stateful servers
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: mcp-registry
+      value_type: stringSlice
+      default_value: '[]'
+      description: MCP registry URLs to fetch servers from (can be repeated)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: memory
+      value_type: string
+      default_value: 2Gb
+      description: Memory allocated to each MCP Server (default is 2Gb)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: oci-ref
+      value_type: stringArray
+      default_value: '[]'
+      description: OCI image references to use
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: port
+      value_type: int
+      default_value: "0"
+      description: TCP port to listen on (default is to listen on stdio)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: profile
+      value_type: string
+      description: |
+        Profile ID to use (mutually exclusive with --servers and --enable-all-servers)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: registry
+      value_type: stringSlice
+      default_value: '[]'
+      description: |
+        Paths to the registry files (absolute or relative to ~/.docker/mcp/)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: secrets
+      value_type: string
+      default_value: docker-desktop
+      description: |
+        Colon separated paths to search for secrets. Can be `docker-desktop` or a path to a .env file (default to using Docker Desktop's secrets API)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: servers
+      value_type: stringSlice
+      default_value: '[]'
+      description: |
+        Names of the servers to enable (if non empty, ignore --registry flag)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: static
+      value_type: bool
+      default_value: "false"
+      description: Enable static mode (aka pre-started servers)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tools
+      value_type: stringSlice
+      default_value: '[]'
+      description: List of tools to enable
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tools-config
+      value_type: stringSlice
+      default_value: '[]'
+      description: Paths to the tools files (absolute or relative to ~/.docker/mcp/)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: transport
+      value_type: string
+      default_value: stdio
+      description: |
+        stdio, sse or streaming. Uses MCP_GATEWAY_AUTH_TOKEN environment variable for localhost authentication to prevent dns rebinding attacks.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose
+      value_type: bool
+      default_value: "false"
+      description: Verbose output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verify-signatures
+      value_type: bool
+      default_value: "false"
+      description: Verify signatures of the server images
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: watch
+      value_type: bool
+      default_value: "true"
+      description: Watch for changes and reconfigure the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile.yaml b/data/cli/mcp/docker_mcp_profile.yaml
new file mode 100644
index 000000000000..d95814008f3b
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile.yaml
@@ -0,0 +1,36 @@
+command: docker mcp profile
+short: Manage profiles
+long: Manage profiles
+pname: docker mcp
+plink: docker_mcp.yaml
+cname:
+    - docker mcp profile config
+    - docker mcp profile create
+    - docker mcp profile export
+    - docker mcp profile import
+    - docker mcp profile list
+    - docker mcp profile pull
+    - docker mcp profile push
+    - docker mcp profile remove
+    - docker mcp profile server
+    - docker mcp profile show
+    - docker mcp profile tools
+clink:
+    - docker_mcp_profile_config.yaml
+    - docker_mcp_profile_create.yaml
+    - docker_mcp_profile_export.yaml
+    - docker_mcp_profile_import.yaml
+    - docker_mcp_profile_list.yaml
+    - docker_mcp_profile_pull.yaml
+    - docker_mcp_profile_push.yaml
+    - docker_mcp_profile_remove.yaml
+    - docker_mcp_profile_server.yaml
+    - docker_mcp_profile_show.yaml
+    - docker_mcp_profile_tools.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_config.yaml b/data/cli/mcp/docker_mcp_profile_config.yaml
new file mode 100644
index 000000000000..1fb51e819c33
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_config.yaml
@@ -0,0 +1,66 @@
+command: docker mcp profile config
+short: Update the configuration of a profile
+long: Update the configuration of a profile
+usage: docker mcp profile config <profile-id> [--set <config-arg1> <config-arg2> ...] [--get <config-key1> <config-key2> ...] [--del <config-arg1> <config-arg2> ...]
+pname: docker mcp profile
+plink: docker_mcp_profile.yaml
+options:
+    - option: del
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Delete configuration values: <key> (can be specified multiple times)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: format
+      value_type: string
+      default_value: human
+      description: 'Supported: json, yaml, human.'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: get
+      value_type: stringArray
+      default_value: '[]'
+      description: 'Get configuration values: <key> (can be specified multiple times)'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: get-all
+      value_type: bool
+      default_value: "false"
+      description: Get all configuration values
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: set
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Set configuration values: <key>=<value> (repeatable). Value may be JSON to set typed values (arrays, numbers, booleans, objects).
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_create.yaml b/data/cli/mcp/docker_mcp_profile_create.yaml
new file mode 100644
index 000000000000..0a27f10c7bda
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_create.yaml
@@ -0,0 +1,73 @@
+command: docker mcp profile create
+short: Create a new profile of MCP servers
+long: |-
+    Create a new profile that groups multiple MCP servers together.
+    A profile allows you to organize and manage related servers as a single unit.
+    Profiles are decoupled from catalogs. Servers can be:
+      - MCP Registry references (e.g. http://registry.modelcontextprotocol.io/v0/servers/312e45a4-2216-4b21-b9a8-0f1a51425073)
+      - OCI image references with docker:// prefix (e.g., "docker://my-server:latest"). Images must be self-describing.
+      - Catalog references with catalog:// prefix (e.g., "catalog://mcp/docker-mcp-catalog/github+obsidian").
+      - Local file references with file:// prefix (e.g., "file://./server.yaml").
+usage: docker mcp profile create --name <name> [--id <id>] --server <ref1> --server <ref2> ... [--connect <client1> --connect <client2> ...]
+pname: docker mcp profile
+plink: docker_mcp_profile.yaml
+options:
+    - option: connect
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Clients to connect to: mcp-client (can be specified multiple times). Supported clients: [claude-code claude-desktop cline codex continue crush cursor gemini goose gordon kiro lmstudio opencode sema4 vscode zed]
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: id
+      value_type: string
+      description: ID of the profile (defaults to a slugified version of the name)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: name
+      value_type: string
+      description: Name of the profile (required)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: server
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Server to include specified with a URI: https:// (MCP Registry reference) or docker:// (Docker Image reference) or catalog:// (Catalog reference) or file:// (Local file path). Can be specified multiple times.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |4-
+      # Create a profile with servers from a catalog
+      docker mcp profile create --name dev-tools --server catalog://mcp/docker-mcp-catalog/github+obsidian
+
+      # Create a profile with multiple servers (OCI references)
+      docker mcp profile create --name my-profile --server docker://my-server:latest --server docker://my-other-server:latest
+
+      # Create a profile with MCP Registry references
+      docker mcp profile create --name my-profile --server http://registry.modelcontextprotocol.io/v0/servers/71de5a2a-6cfb-4250-a196-f93080ecc860
+
+      # Connect to clients upon creation
+      docker mcp profile create --name dev-tools --connect cursor
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_export.yaml b/data/cli/mcp/docker_mcp_profile_export.yaml
new file mode 100644
index 000000000000..cca7cd7b0ba0
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_export.yaml
@@ -0,0 +1,13 @@
+command: docker mcp profile export
+short: Export profile to file
+long: Export profile to file
+usage: docker mcp profile export <profile-id> <output-file>
+pname: docker mcp profile
+plink: docker_mcp_profile.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_import.yaml b/data/cli/mcp/docker_mcp_profile_import.yaml
new file mode 100644
index 000000000000..fed3a0726632
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_import.yaml
@@ -0,0 +1,13 @@
+command: docker mcp profile import
+short: Import profile from file
+long: Import profile from file
+usage: docker mcp profile import <input-file>
+pname: docker mcp profile
+plink: docker_mcp_profile.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_list.yaml b/data/cli/mcp/docker_mcp_profile_list.yaml
new file mode 100644
index 000000000000..7cbf4abedba7
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_list.yaml
@@ -0,0 +1,25 @@
+command: docker mcp profile list
+aliases: docker mcp profile list, docker mcp profile ls
+short: List profiles
+long: List profiles
+usage: docker mcp profile list
+pname: docker mcp profile
+plink: docker_mcp_profile.yaml
+options:
+    - option: format
+      value_type: string
+      default_value: human
+      description: 'Supported: json, yaml, human.'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_pull.yaml b/data/cli/mcp/docker_mcp_profile_pull.yaml
new file mode 100644
index 000000000000..633da33cd206
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_pull.yaml
@@ -0,0 +1,13 @@
+command: docker mcp profile pull
+short: Pull profile from OCI registry
+long: Pull profile from OCI registry
+usage: docker mcp profile pull <oci-reference>
+pname: docker mcp profile
+plink: docker_mcp_profile.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_push.yaml b/data/cli/mcp/docker_mcp_profile_push.yaml
new file mode 100644
index 000000000000..fff71efc1c1c
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_push.yaml
@@ -0,0 +1,13 @@
+command: docker mcp profile push
+short: Push profile to OCI registry
+long: Push profile to OCI registry
+usage: docker mcp profile push <profile-id> <oci-reference>
+pname: docker mcp profile
+plink: docker_mcp_profile.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_remove.yaml b/data/cli/mcp/docker_mcp_profile_remove.yaml
new file mode 100644
index 000000000000..85c7f9339849
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_remove.yaml
@@ -0,0 +1,14 @@
+command: docker mcp profile remove
+aliases: docker mcp profile remove, docker mcp profile rm
+short: Remove a profile
+long: Remove a profile
+usage: docker mcp profile remove <profile-id>
+pname: docker mcp profile
+plink: docker_mcp_profile.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_server.yaml b/data/cli/mcp/docker_mcp_profile_server.yaml
new file mode 100644
index 000000000000..e0c9b5f68051
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_server.yaml
@@ -0,0 +1,20 @@
+command: docker mcp profile server
+short: Manage servers in profiles
+long: Manage servers in profiles
+pname: docker mcp profile
+plink: docker_mcp_profile.yaml
+cname:
+    - docker mcp profile server add
+    - docker mcp profile server ls
+    - docker mcp profile server remove
+clink:
+    - docker_mcp_profile_server_add.yaml
+    - docker_mcp_profile_server_ls.yaml
+    - docker_mcp_profile_server_remove.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_server_add.yaml b/data/cli/mcp/docker_mcp_profile_server_add.yaml
new file mode 100644
index 000000000000..b8269b9fd260
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_server_add.yaml
@@ -0,0 +1,37 @@
+command: docker mcp profile server add
+short: Add MCP servers to a profile
+long: Add MCP servers to a profile.
+usage: docker mcp profile server add <profile-id> [--server <ref1> --server <ref2> ...]
+pname: docker mcp profile server
+plink: docker_mcp_profile_server.yaml
+options:
+    - option: server
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Server to include specified with a URI: https:// (MCP Registry reference) or docker:// (Docker Image reference) or catalog:// (Catalog reference) or file:// (Local file path). Can be specified multiple times.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |4-
+      # Add servers from a catalog
+      docker mcp profile server add dev-tools --server catalog://mcp/docker-mcp-catalog/github+obsidian
+
+      # Add servers with OCI references
+      docker mcp profile server add my-profile --server docker://my-server:latest
+
+      # Add servers with MCP Registry references
+      docker mcp profile server add my-profile --server http://registry.modelcontextprotocol.io/v0/servers/71de5a2a-6cfb-4250-a196-f93080ecc860
+
+      # Mix server references
+      docker mcp profile server add dev-tools --server catalog://mcp/docker-mcp-catalog/github+obsidian --server docker://my-server:latest
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_server_ls.yaml b/data/cli/mcp/docker_mcp_profile_server_ls.yaml
new file mode 100644
index 000000000000..2924e21dbb94
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_server_ls.yaml
@@ -0,0 +1,55 @@
+command: docker mcp profile server ls
+aliases: docker mcp profile server ls, docker mcp profile server list
+short: List servers across profiles
+long: |-
+    List all servers grouped by profile.
+
+    Use --filter to search for servers matching a query (case-insensitive substring matching on server names).
+    Filters use key=value format (e.g., name=github, profile=my-dev-env).
+usage: docker mcp profile server ls
+pname: docker mcp profile server
+plink: docker_mcp_profile_server.yaml
+options:
+    - option: filter
+      shorthand: f
+      value_type: stringArray
+      default_value: '[]'
+      description: Filter output (e.g., name=github, profile=my-dev-env)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: format
+      value_type: string
+      default_value: human
+      description: 'Supported: json, yaml, human.'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |4-
+      # List all servers across all profiles
+      docker mcp profile server ls
+
+      # Filter servers by name
+      docker mcp profile server ls --filter name=github
+
+      # Show servers from a specific profile
+      docker mcp profile server ls --filter profile=my-dev-env
+
+      # Combine multiple filters (using short flag)
+      docker mcp profile server ls -f name=slack -f profile=my-dev-env
+
+      # Output in JSON format
+      docker mcp profile server ls --format json
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_server_remove.yaml b/data/cli/mcp/docker_mcp_profile_server_remove.yaml
new file mode 100644
index 000000000000..5acbaa6d813c
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_server_remove.yaml
@@ -0,0 +1,31 @@
+command: docker mcp profile server remove
+aliases: docker mcp profile server remove, docker mcp profile server rm
+short: Remove MCP servers from a profile
+long: Remove MCP servers from a profile by server name.
+usage: docker mcp profile server remove <profile-id> --name <name1> --name <name2> ...
+pname: docker mcp profile server
+plink: docker_mcp_profile_server.yaml
+options:
+    - option: name
+      value_type: stringArray
+      default_value: '[]'
+      description: Server name to remove (can be specified multiple times)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |4-
+     # Remove servers by name
+      docker mcp profile server remove dev-tools --name github --name slack
+
+      # Remove a single server
+      docker mcp profile server remove dev-tools --name github
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_show.yaml b/data/cli/mcp/docker_mcp_profile_show.yaml
new file mode 100644
index 000000000000..e5aa8d8085b9
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_show.yaml
@@ -0,0 +1,43 @@
+command: docker mcp profile show
+short: Show profile
+long: Show profile
+usage: docker mcp profile show <profile-id>
+pname: docker mcp profile
+plink: docker_mcp_profile.yaml
+options:
+    - option: clients
+      value_type: bool
+      default_value: "false"
+      description: Include client information in output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: format
+      value_type: string
+      default_value: human
+      description: 'Supported: json, yaml, human.'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: yq
+      value_type: string
+      description: YQ expression to apply to the output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_profile_tools.yaml b/data/cli/mcp/docker_mcp_profile_tools.yaml
new file mode 100644
index 000000000000..07da36d07e8d
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_profile_tools.yaml
@@ -0,0 +1,81 @@
+command: docker mcp profile tools
+short: Manage tool allowlist for servers in a profile
+long: |-
+    Manage the tool allowlist for servers in a profile.
+    Tools are specified using dot notation: <serverName>.<toolName>
+
+    Use --enable to enable specific tools for a server (can be specified multiple times).
+    Use --disable to disable specific tools for a server (can be specified multiple times).
+    Use --enable-all to enable all tools for a server (can be specified multiple times).
+    Use --disable-all to disable all tools for a server (can be specified multiple times).
+
+    To view enabled tools, use: docker mcp profile show <profile-id>
+usage: docker mcp profile tools <profile-id> [--enable <tool> ...] [--disable <tool> ...] [--enable-all <server> ...] [--disable-all <server> ...]
+pname: docker mcp profile
+plink: docker_mcp_profile.yaml
+options:
+    - option: disable
+      value_type: stringArray
+      default_value: '[]'
+      description: 'Disable specific tools: <serverName>.<toolName> (repeatable)'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: disable-all
+      value_type: stringArray
+      default_value: '[]'
+      description: 'Disable all tools for a server: <serverName> (repeatable)'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: enable
+      value_type: stringArray
+      default_value: '[]'
+      description: 'Enable specific tools: <serverName>.<toolName> (repeatable)'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: enable-all
+      value_type: stringArray
+      default_value: '[]'
+      description: 'Enable all tools for a server: <serverName> (repeatable)'
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |4-
+      # Enable specific tools for a server
+      docker mcp profile tools my-profile --enable github.create_issue --enable github.list_repos
+
+      # Disable specific tools for a server
+      docker mcp profile tools my-profile --disable github.create_issue --disable github.search_code
+
+      # Enable and disable in one command
+      docker mcp profile tools my-profile --enable github.create_issue --disable github.search_code
+
+      # Enable all tools for a server
+      docker mcp profile tools my-profile --enable-all github
+
+      # Disable all tools for a server
+      docker mcp profile tools my-profile --disable-all github
+
+      # View all enabled tools in the profile
+      docker mcp profile show my-profile
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_secret.yaml b/data/cli/mcp/docker_mcp_secret.yaml
new file mode 100644
index 000000000000..dde72c8f6da7
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_secret.yaml
@@ -0,0 +1,25 @@
+command: docker mcp secret
+short: Manage secrets in the local OS Keychain
+long: Manage secrets in the local OS Keychain
+pname: docker mcp
+plink: docker_mcp.yaml
+cname:
+    - docker mcp secret ls
+    - docker mcp secret rm
+    - docker mcp secret set
+clink:
+    - docker_mcp_secret_ls.yaml
+    - docker_mcp_secret_rm.yaml
+    - docker_mcp_secret_set.yaml
+examples: |-
+    ### Pass the secret via STDIN
+
+    > echo my-secret-password > pwd.txt
+    > cat pwd.txt | docker mcp secret set POSTGRES_PASSWORD
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_secret_ls.yaml b/data/cli/mcp/docker_mcp_secret_ls.yaml
new file mode 100644
index 000000000000..de4eeb5f35ab
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_secret_ls.yaml
@@ -0,0 +1,26 @@
+command: docker mcp secret ls
+short: |
+    List all secrets from the local OS Keychain as well as any active Secrets Engine provider
+long: |
+    List all secrets from the local OS Keychain as well as any active Secrets Engine provider
+usage: docker mcp secret ls
+pname: docker mcp secret
+plink: docker_mcp_secret.yaml
+options:
+    - option: json
+      value_type: bool
+      default_value: "false"
+      description: Print as JSON.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_secret_rm.yaml b/data/cli/mcp/docker_mcp_secret_rm.yaml
new file mode 100644
index 000000000000..59728b99b603
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_secret_rm.yaml
@@ -0,0 +1,24 @@
+command: docker mcp secret rm
+short: Remove secrets from the local OS Keychain
+long: Remove secrets from the local OS Keychain
+usage: docker mcp secret rm name1 name2 ...
+pname: docker mcp secret
+plink: docker_mcp_secret.yaml
+options:
+    - option: all
+      value_type: bool
+      default_value: "false"
+      description: Remove all secrets
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_secret_set.yaml b/data/cli/mcp/docker_mcp_secret_set.yaml
new file mode 100644
index 000000000000..797ee89582b6
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_secret_set.yaml
@@ -0,0 +1,30 @@
+command: docker mcp secret set
+short: Set a secret in the local OS Keychain
+long: Set a secret in the local OS Keychain
+usage: docker mcp secret set key[=value]
+pname: docker mcp secret
+plink: docker_mcp_secret.yaml
+options:
+    - option: provider
+      value_type: string
+      description: 'Supported: credstore, oauth/<provider>'
+      deprecated: true
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Pass the secret via STDIN
+
+    ```console
+    echo my-secret-password > pwd.txt
+    cat pwd.txt | docker mcp secret set postgres_password
+    ```
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_server.yaml b/data/cli/mcp/docker_mcp_server.yaml
new file mode 100644
index 000000000000..2cb6c54f0044
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_server.yaml
@@ -0,0 +1,16 @@
+command: docker mcp server
+short: Manage servers
+long: Manage servers
+pname: docker mcp
+plink: docker_mcp.yaml
+cname:
+    - docker mcp server init
+clink:
+    - docker_mcp_server_init.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_server_init.yaml b/data/cli/mcp/docker_mcp_server_init.yaml
new file mode 100644
index 000000000000..20a8fc4f94bc
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_server_init.yaml
@@ -0,0 +1,36 @@
+command: docker mcp server init
+short: Initialize a new MCP server project
+long: |
+    Initialize a new MCP server project in the specified directory with boilerplate code, Dockerfile, and compose.yaml
+usage: docker mcp server init <directory>
+pname: docker mcp server
+plink: docker_mcp_server.yaml
+options:
+    - option: language
+      value_type: string
+      default_value: go
+      description: |
+        Programming language for the server (currently only 'go' is supported)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: template
+      value_type: string
+      default_value: basic
+      description: Template to use (basic, chatgpt-app-basic)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_tools.yaml b/data/cli/mcp/docker_mcp_tools.yaml
new file mode 100644
index 000000000000..4ecc3fe0b979
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_tools.yaml
@@ -0,0 +1,63 @@
+command: docker mcp tools
+short: Manage tools
+long: Manage tools
+pname: docker mcp
+plink: docker_mcp.yaml
+cname:
+    - docker mcp tools call
+    - docker mcp tools count
+    - docker mcp tools inspect
+    - docker mcp tools ls
+clink:
+    - docker_mcp_tools_call.yaml
+    - docker_mcp_tools_count.yaml
+    - docker_mcp_tools_inspect.yaml
+    - docker_mcp_tools_ls.yaml
+options:
+    - option: format
+      value_type: string
+      default_value: list
+      description: Output format (json|list)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gateway-arg
+      value_type: stringSlice
+      default_value: '[]'
+      description: Additional arguments passed to the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose
+      value_type: bool
+      default_value: "false"
+      description: Verbose output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: version
+      value_type: string
+      default_value: "2"
+      description: Version of the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_tools_call.yaml b/data/cli/mcp/docker_mcp_tools_call.yaml
new file mode 100644
index 000000000000..68d245aea158
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_tools_call.yaml
@@ -0,0 +1,54 @@
+command: docker mcp tools call
+short: Call a tool
+long: Call a tool
+usage: docker mcp tools call
+pname: docker mcp tools
+plink: docker_mcp_tools.yaml
+inherited_options:
+    - option: format
+      value_type: string
+      default_value: list
+      description: Output format (json|list)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gateway-arg
+      value_type: stringSlice
+      default_value: '[]'
+      description: Additional arguments passed to the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose
+      value_type: bool
+      default_value: "false"
+      description: Verbose output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: version
+      value_type: string
+      default_value: "2"
+      description: Version of the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_tools_count.yaml b/data/cli/mcp/docker_mcp_tools_count.yaml
new file mode 100644
index 000000000000..f35faaa309a3
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_tools_count.yaml
@@ -0,0 +1,54 @@
+command: docker mcp tools count
+short: Count tools
+long: Count tools
+usage: docker mcp tools count
+pname: docker mcp tools
+plink: docker_mcp_tools.yaml
+inherited_options:
+    - option: format
+      value_type: string
+      default_value: list
+      description: Output format (json|list)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gateway-arg
+      value_type: stringSlice
+      default_value: '[]'
+      description: Additional arguments passed to the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose
+      value_type: bool
+      default_value: "false"
+      description: Verbose output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: version
+      value_type: string
+      default_value: "2"
+      description: Version of the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_tools_inspect.yaml b/data/cli/mcp/docker_mcp_tools_inspect.yaml
new file mode 100644
index 000000000000..eb2f34d7723f
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_tools_inspect.yaml
@@ -0,0 +1,54 @@
+command: docker mcp tools inspect
+short: Inspect a tool
+long: Inspect a tool
+usage: docker mcp tools inspect
+pname: docker mcp tools
+plink: docker_mcp_tools.yaml
+inherited_options:
+    - option: format
+      value_type: string
+      default_value: list
+      description: Output format (json|list)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gateway-arg
+      value_type: stringSlice
+      default_value: '[]'
+      description: Additional arguments passed to the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose
+      value_type: bool
+      default_value: "false"
+      description: Verbose output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: version
+      value_type: string
+      default_value: "2"
+      description: Version of the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_tools_list.yaml b/data/cli/mcp/docker_mcp_tools_list.yaml
new file mode 100644
index 000000000000..607164a5c762
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_tools_list.yaml
@@ -0,0 +1,55 @@
+command: docker mcp tools list
+aliases: docker mcp tools list, docker mcp tools ls
+short: List tools
+long: List tools
+usage: docker mcp tools list
+pname: docker mcp tools
+plink: docker_mcp_tools.yaml
+inherited_options:
+    - option: format
+      value_type: string
+      default_value: list
+      description: Output format (json|list)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gateway-arg
+      value_type: stringSlice
+      default_value: '[]'
+      description: Additional arguments passed to the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose
+      value_type: bool
+      default_value: "false"
+      description: Verbose output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: version
+      value_type: string
+      default_value: "2"
+      description: Version of the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_tools_ls.yaml b/data/cli/mcp/docker_mcp_tools_ls.yaml
new file mode 100644
index 000000000000..b349ae2b4e05
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_tools_ls.yaml
@@ -0,0 +1,55 @@
+command: docker mcp tools ls
+aliases: docker mcp tools ls, docker mcp tools list
+short: List tools
+long: List tools
+usage: docker mcp tools ls
+pname: docker mcp tools
+plink: docker_mcp_tools.yaml
+inherited_options:
+    - option: format
+      value_type: string
+      default_value: list
+      description: Output format (json|list)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: gateway-arg
+      value_type: stringSlice
+      default_value: '[]'
+      description: Additional arguments passed to the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose
+      value_type: bool
+      default_value: "false"
+      description: Verbose output
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: version
+      value_type: string
+      default_value: "2"
+      description: Version of the gateway
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/mcp/docker_mcp_version.yaml b/data/cli/mcp/docker_mcp_version.yaml
new file mode 100644
index 000000000000..3639f7b62ddd
--- /dev/null
+++ b/data/cli/mcp/docker_mcp_version.yaml
@@ -0,0 +1,13 @@
+command: docker mcp version
+short: Show the version information
+long: Show the version information
+usage: docker mcp version
+pname: docker mcp
+plink: docker_mcp.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/offload/docker_offload.yaml b/data/cli/offload/docker_offload.yaml
new file mode 100644
index 000000000000..8852798506da
--- /dev/null
+++ b/data/cli/offload/docker_offload.yaml
@@ -0,0 +1,23 @@
+command: docker offload
+short: Control Docker Offload from the CLI
+usage: docker offload
+pname: docker
+plink: docker.yaml
+cname:
+  - docker offload diagnose
+  - docker offload start
+  - docker offload status
+  - docker offload stop
+  - docker offload version
+clink:
+  - docker_offload_diagnose.yaml
+  - docker_offload_start.yaml
+  - docker_offload_status.yaml
+  - docker_offload_stop.yaml
+  - docker_offload_version.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/offload/docker_offload_diagnose.yaml b/data/cli/offload/docker_offload_diagnose.yaml
new file mode 100644
index 000000000000..c553faf71b0f
--- /dev/null
+++ b/data/cli/offload/docker_offload_diagnose.yaml
@@ -0,0 +1,12 @@
+command: docker offload diagnose
+short: Print diagnostic information for Docker Offload
+usage: docker offload diagnose
+pname: docker offload
+plink: docker_offload.yaml
+options: []
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/offload/docker_offload_start.yaml b/data/cli/offload/docker_offload_start.yaml
new file mode 100644
index 000000000000..d968a6c997d4
--- /dev/null
+++ b/data/cli/offload/docker_offload_start.yaml
@@ -0,0 +1,44 @@
+command: docker offload start
+short: Start a Docker Offload session
+usage: docker offload start
+pname: docker offload
+plink: docker_offload.yaml
+options:
+  - option: account
+    shorthand: a
+    value_type: string
+    default_value: ""
+    description: The Docker account to use
+    deprecated: false
+    hidden: false
+    experimental: false
+    experimentalcli: false
+    kubernetes: false
+    swarm: false
+  - option: gpu
+    shorthand: g
+    value_type: bool
+    default_value: "false"
+    description: Request an engine with a gpu
+    deprecated: false
+    hidden: false
+    experimental: false
+    experimentalcli: false
+    kubernetes: false
+    swarm: false
+  - option: timeout
+    value_type: duration
+    default_value: 10s
+    description: How long to wait for the engine to be ready
+    deprecated: false
+    hidden: false
+    experimental: false
+    experimentalcli: false
+    kubernetes: false
+    swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/offload/docker_offload_status.yaml b/data/cli/offload/docker_offload_status.yaml
new file mode 100644
index 000000000000..8d64ce094f13
--- /dev/null
+++ b/data/cli/offload/docker_offload_status.yaml
@@ -0,0 +1,34 @@
+command: docker offload status
+short: Show the status of the Docker Offload connection
+usage: docker offload status [OPTIONS]
+pname: docker offload
+plink: docker_offload.yaml
+options:
+  - option: format
+    shorthand: f
+    value_type: string
+    default_value: pretty
+    description: "Format of output (default: pretty, one of: pretty|json)"
+    deprecated: false
+    hidden: false
+    experimental: false
+    experimentalcli: false
+    kubernetes: false
+    swarm: false
+  - option: watch
+    shorthand: w
+    value_type: bool
+    default_value: "false"
+    description: Watch for status updates
+    deprecated: false
+    hidden: false
+    experimental: false
+    experimentalcli: false
+    kubernetes: false
+    swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/offload/docker_offload_stop.yaml b/data/cli/offload/docker_offload_stop.yaml
new file mode 100644
index 000000000000..9a274a3e19a0
--- /dev/null
+++ b/data/cli/offload/docker_offload_stop.yaml
@@ -0,0 +1,22 @@
+command: docker offload stop
+short: Stop a Docker Offload session
+usage: docker offload stop [OPTIONS]
+pname: docker offload
+plink: docker_offload.yaml
+options:
+  - option: terminate
+    value_type: bool
+    default_value: "false"
+    description: Terminate the remote lease
+    deprecated: false
+    hidden: false
+    experimental: false
+    experimentalcli: false
+    kubernetes: false
+    swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/offload/docker_offload_version.yaml b/data/cli/offload/docker_offload_version.yaml
new file mode 100644
index 000000000000..4376cbf8117c
--- /dev/null
+++ b/data/cli/offload/docker_offload_version.yaml
@@ -0,0 +1,32 @@
+command: docker offload version
+short: Prints the version
+usage: docker offload version [OPTIONS]
+pname: docker offload
+plink: docker_offload.yaml
+options:
+  - option: json
+    value_type: bool
+    default_value: "false"
+    description: Prints the version as JSON
+    deprecated: false
+    hidden: false
+    experimental: false
+    experimentalcli: false
+    kubernetes: false
+    swarm: false
+  - option: short
+    value_type: bool
+    default_value: "false"
+    description: Prints the short version
+    deprecated: false
+    hidden: false
+    experimental: false
+    experimentalcli: false
+    kubernetes: false
+    swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout.yaml b/data/cli/scout/docker_scout.yaml
similarity index 94%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout.yaml
rename to data/cli/scout/docker_scout.yaml
index 4204e61c52bc..37b012fa4845 100644
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout.yaml
+++ b/data/cli/scout/docker_scout.yaml
@@ -20,6 +20,8 @@ cname:
     - docker scout recommendations
     - docker scout repo
     - docker scout version
+    - docker scout vex
+    - docker scout watch
 clink:
     - docker_scout_attestation.yaml
     - docker_scout_cache.yaml
@@ -36,6 +38,8 @@ clink:
     - docker_scout_recommendations.yaml
     - docker_scout_repo.yaml
     - docker_scout_version.yaml
+    - docker_scout_vex.yaml
+    - docker_scout_watch.yaml
 options:
     - option: debug
       value_type: bool
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_attestation.yaml b/data/cli/scout/docker_scout_attestation.yaml
similarity index 78%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_attestation.yaml
rename to data/cli/scout/docker_scout_attestation.yaml
index cbe04ad0a23c..87f7211eb89c 100644
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_attestation.yaml
+++ b/data/cli/scout/docker_scout_attestation.yaml
@@ -1,13 +1,17 @@
 command: docker scout attestation
 aliases: docker scout attestation, docker scout attest
-short: Manage attestations on image indexes
-long: Manage attestations on image indexes
+short: Manage attestations on images
+long: Manage attestations on images
 pname: docker scout
 plink: docker_scout.yaml
 cname:
     - docker scout attestation add
+    - docker scout attestation get
+    - docker scout attestation list
 clink:
     - docker_scout_attestation_add.yaml
+    - docker_scout_attestation_get.yaml
+    - docker_scout_attestation_list.yaml
 inherited_options:
     - option: debug
       value_type: bool
diff --git a/data/cli/scout/docker_scout_attestation_add.yaml b/data/cli/scout/docker_scout_attestation_add.yaml
new file mode 100644
index 000000000000..46a6b2a140c9
--- /dev/null
+++ b/data/cli/scout/docker_scout_attestation_add.yaml
@@ -0,0 +1,83 @@
+command: docker scout attestation add
+aliases: docker scout attestation add, docker scout attest add
+short: Add attestation to image
+long: The docker scout attestation add command adds attestations to images.
+usage: docker scout attestation add OPTIONS IMAGE [IMAGE...]
+pname: docker scout attestation
+plink: docker_scout_attestation.yaml
+options:
+    - option: file
+      value_type: stringSlice
+      default_value: '[]'
+      description: File location of attestations to attach
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: org
+      value_type: string
+      description: Namespace of the Docker organization
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: predicate-type
+      value_type: string
+      description: Predicate-type for attestations
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: referrer
+      value_type: bool
+      default_value: "false"
+      description: Use OCI referrer API for pushing attestation
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: referrer-repository
+      value_type: string
+      default_value: registry.scout.docker.com
+      description: Repository to push referrer to
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Debug messages
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose-debug
+      value_type: bool
+      default_value: "false"
+      description: Verbose debug
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+experimental: false
+experimentalcli: true
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/scout/docker_scout_attestation_get.yaml b/data/cli/scout/docker_scout_attestation_get.yaml
new file mode 100644
index 000000000000..94541b541e1d
--- /dev/null
+++ b/data/cli/scout/docker_scout_attestation_get.yaml
@@ -0,0 +1,123 @@
+command: docker scout attestation get
+aliases: docker scout attestation get, docker scout attest get
+short: Get attestation for image
+long: The docker scout attestation get command gets attestations for images.
+usage: docker scout attestation get OPTIONS IMAGE [DIGEST]
+pname: docker scout attestation
+plink: docker_scout_attestation.yaml
+options:
+    - option: key
+      value_type: string
+      default_value: https://registry.scout.docker.com/keyring/dhi/latest.pub
+      description: Signature key to use for verification
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: org
+      value_type: string
+      description: Namespace of the Docker organization
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: output
+      shorthand: o
+      value_type: string
+      description: Write the report to a file
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: platform
+      value_type: string
+      description: Platform of image to analyze
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: predicate
+      value_type: bool
+      default_value: "false"
+      description: Get in-toto predicate only dropping the subject
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: predicate-type
+      value_type: string
+      description: Predicate-type for attestation
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: ref
+      value_type: string
+      description: |-
+        Reference to use if the provided tarball contains multiple references.
+        Can only be used with archive
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: skip-tlog
+      value_type: bool
+      default_value: "false"
+      description: Skip signature verification against public transaction log
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verify
+      value_type: bool
+      default_value: "false"
+      description: Verify the signature on the attestation
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Debug messages
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose-debug
+      value_type: bool
+      default_value: "false"
+      description: Verbose debug
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+experimental: false
+experimentalcli: true
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/scout/docker_scout_attestation_list.yaml b/data/cli/scout/docker_scout_attestation_list.yaml
new file mode 100644
index 000000000000..429369d5a012
--- /dev/null
+++ b/data/cli/scout/docker_scout_attestation_list.yaml
@@ -0,0 +1,96 @@
+command: docker scout attestation list
+aliases: docker scout attestation list, docker scout attest list
+short: List attestations for image
+long: The docker scout attestation list command lists attestations for images.
+usage: docker scout attestation list OPTIONS IMAGE
+pname: docker scout attestation
+plink: docker_scout_attestation.yaml
+options:
+    - option: format
+      value_type: string
+      default_value: list
+      description: |-
+        Output format:
+        - list: list of attestations of the image
+        - json: json representation of the attestation list (default "json")
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: org
+      value_type: string
+      description: Namespace of the Docker organization
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: output
+      shorthand: o
+      value_type: string
+      description: Write the report to a file
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: platform
+      value_type: string
+      description: Platform of image to analyze
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: predicate-type
+      value_type: string
+      description: Predicate-type for attestations
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: ref
+      value_type: string
+      description: |-
+        Reference to use if the provided tarball contains multiple references.
+        Can only be used with archive
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Debug messages
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose-debug
+      value_type: bool
+      default_value: "false"
+      description: Verbose debug
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+experimental: false
+experimentalcli: true
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_cache.yaml b/data/cli/scout/docker_scout_cache.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_cache.yaml
rename to data/cli/scout/docker_scout_cache.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_cache_df.yaml b/data/cli/scout/docker_scout_cache_df.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_cache_df.yaml
rename to data/cli/scout/docker_scout_cache_df.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_cache_prune.yaml b/data/cli/scout/docker_scout_cache_prune.yaml
similarity index 97%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_cache_prune.yaml
rename to data/cli/scout/docker_scout_cache_prune.yaml
index 2d5f7de568ab..abf68bb6b7f0 100644
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_cache_prune.yaml
+++ b/data/cli/scout/docker_scout_cache_prune.yaml
@@ -60,7 +60,7 @@ examples: |-
         ✓ temporary data deleted
     ```
 
-    ### Delete temporary _and_ cache data
+    ### Delete temporary and cache data
 
     ```console
     $ docker scout cache prune --sboms
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_compare.yaml b/data/cli/scout/docker_scout_compare.yaml
similarity index 77%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_compare.yaml
rename to data/cli/scout/docker_scout_compare.yaml
index a6a986c0a8d7..37e3649c1909 100644
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_compare.yaml
+++ b/data/cli/scout/docker_scout_compare.yaml
@@ -55,7 +55,7 @@ options:
       value_type: stringSlice
       default_value: '[]'
       description: |
-        Comma separated list of conditions to fail the action step if worse, options are: vulnerability, policy
+        Comma separated list of conditions to fail the action step if worse or changed, options are: vulnerability, policy, package
       deprecated: false
       hidden: false
       experimental: false
@@ -69,6 +69,7 @@ options:
         Output format of the generated vulnerability report:
         - text: default output, plain text with or without colors depending on the terminal
         - markdown: Markdown output
+        - json: JSON output
       deprecated: false
       hidden: false
       experimental: false
@@ -95,6 +96,17 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: ignore-suppressed
+      value_type: bool
+      default_value: "false"
+      description: |
+        Filter CVEs found in Scout exceptions based on the specified exception scope
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: ignore-unchanged
       value_type: bool
       default_value: "false"
@@ -177,6 +189,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: only-vex-affected
+      value_type: bool
+      default_value: "false"
+      description: Filter CVEs by VEX statements with status not affected
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: org
       value_type: string
       description: Namespace of the Docker organization
@@ -205,6 +227,46 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: policy-bundle
+      value_type: stringArray
+      default_value: '[]'
+      description: OCI reference of a policy bundle to evaluate (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy-config
+      value_type: string
+      description: |
+        Path or http(s) URL to a JSON file configuring policy enablement and inputs
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy-dir
+      value_type: stringArray
+      default_value: '[]'
+      description: Path to a directory of local .rego policy files (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy-file
+      value_type: stringArray
+      default_value: '[]'
+      description: Path or http(s) URL to a .rego policy file (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: ref
       value_type: string
       description: |-
@@ -264,6 +326,36 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: vex
+      value_type: bool
+      default_value: "false"
+      description: Apply VEX statements to filter CVEs
+      deprecated: true
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: vex-author
+      value_type: stringSlice
+      default_value: '[<.*@docker.com>]'
+      description: List of VEX statement authors to accept
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: vex-location
+      value_type: stringSlice
+      default_value: '[]'
+      description: File location of directory or file containing VEX statements
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
 inherited_options:
     - option: debug
       value_type: bool
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_config.yaml b/data/cli/scout/docker_scout_config.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_config.yaml
rename to data/cli/scout/docker_scout_config.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_cves.yaml b/data/cli/scout/docker_scout_cves.yaml
similarity index 97%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_cves.yaml
rename to data/cli/scout/docker_scout_cves.yaml
index 896c3b4d0bb4..d7bd9bcaf245 100644
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_cves.yaml
+++ b/data/cli/scout/docker_scout_cves.yaml
@@ -135,6 +135,25 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: local
+      value_type: bool
+      default_value: "false"
+      description: Local mode
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: local-vulndb
+      value_type: string
+      description: Local vulnerability database
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: locations
       value_type: bool
       default_value: "false"
@@ -340,7 +359,7 @@ options:
       swarm: false
     - option: vex-author
       value_type: stringSlice
-      default_value: '[]'
+      default_value: '[<.*@docker.com>]'
       description: List of VEX statement authors to accept
       deprecated: false
       hidden: false
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_enroll.yaml b/data/cli/scout/docker_scout_enroll.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_enroll.yaml
rename to data/cli/scout/docker_scout_enroll.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_environment.yaml b/data/cli/scout/docker_scout_environment.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_environment.yaml
rename to data/cli/scout/docker_scout_environment.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_help.yaml b/data/cli/scout/docker_scout_help.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_help.yaml
rename to data/cli/scout/docker_scout_help.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_integration.yaml b/data/cli/scout/docker_scout_integration.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_integration.yaml
rename to data/cli/scout/docker_scout_integration.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_integration_configure.yaml b/data/cli/scout/docker_scout_integration_configure.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_integration_configure.yaml
rename to data/cli/scout/docker_scout_integration_configure.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_integration_delete.yaml b/data/cli/scout/docker_scout_integration_delete.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_integration_delete.yaml
rename to data/cli/scout/docker_scout_integration_delete.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_integration_list.yaml b/data/cli/scout/docker_scout_integration_list.yaml
similarity index 96%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_integration_list.yaml
rename to data/cli/scout/docker_scout_integration_list.yaml
index 00db4ef6877e..9c2a5492060d 100644
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_integration_list.yaml
+++ b/data/cli/scout/docker_scout_integration_list.yaml
@@ -1,5 +1,5 @@
 command: docker scout integration list
-short: Integration Docker Scout
+short: List integrations which can be installed
 long: |
     The docker scout integration list configured integrations for an organization.
 usage: docker scout integration list [INTEGRATION]
diff --git a/data/cli/scout/docker_scout_policy.yaml b/data/cli/scout/docker_scout_policy.yaml
new file mode 100644
index 000000000000..e2772f5ec47c
--- /dev/null
+++ b/data/cli/scout/docker_scout_policy.yaml
@@ -0,0 +1,166 @@
+command: docker scout policy
+short: |
+    Evaluate local Rego policies against an image and display the results (experimental)
+long: |-
+    The `docker scout policy` command evaluates policies against an image.
+    The image analysis is uploaded to Docker Scout where policies get evaluated.
+
+    The policy evaluation results may take a few minutes to become available.
+usage: docker scout policy [IMAGE | REPO]
+pname: docker scout
+plink: docker_scout.yaml
+cname:
+    - docker scout policy publish
+clink:
+    - docker_scout_policy_publish.yaml
+options:
+    - option: exit-code
+      shorthand: e
+      value_type: bool
+      default_value: "false"
+      description: Return exit code '2' if policies are not met, '0' otherwise
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: only-policy
+      value_type: stringSlice
+      default_value: '[]'
+      description: Comma separated list of policies to evaluate
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: org
+      value_type: string
+      description: Namespace of the Docker organization
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: output
+      shorthand: o
+      value_type: string
+      description: Write the report to a file
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: platform
+      value_type: string
+      description: Platform of image to evaluate policies against
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy-bundle
+      value_type: stringArray
+      default_value: '[]'
+      description: OCI reference of a policy bundle to evaluate (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy-config
+      value_type: string
+      description: |
+        Path or http(s) URL to a JSON file configuring policy enablement and inputs
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy-dir
+      value_type: stringArray
+      default_value: '[]'
+      description: Path to a directory of local .rego policy files (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy-file
+      value_type: stringArray
+      default_value: '[]'
+      description: Path or http(s) URL to a .rego policy file (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: result-file
+      value_type: string
+      description: |
+        Write the full Rego evaluation result (pass, violations, query bindings and OPA metrics) of each evaluated policy to a JSON file (useful when iterating on local --policy-file policies)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Debug messages
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose-debug
+      value_type: bool
+      default_value: "false"
+      description: Verbose debug
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Evaluate policies against an image and display the results
+
+    ```console
+    $ docker scout policy dockerscoutpolicy/customers-api-service:0.0.1
+    ```
+
+    ### Evaluate policies against an image for a specific organization
+
+    ```console
+    $ docker scout policy dockerscoutpolicy/customers-api-service:0.0.1 --org dockerscoutpolicy
+    ```
+
+    ### Evaluate policies against an image with a specific platform
+
+    ```console
+    $ docker scout policy dockerscoutpolicy/customers-api-service:0.0.1 --platform linux/amd64
+    ```
+
+    ### Compare policy results for a repository in a specific environment
+
+    ```console
+    $ docker scout policy dockerscoutpolicy/customers-api-service --to-env production
+    ```
+deprecated: false
+experimental: false
+experimentalcli: true
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/scout/docker_scout_policy_publish.yaml b/data/cli/scout/docker_scout_policy_publish.yaml
new file mode 100644
index 000000000000..c5ea24b9422a
--- /dev/null
+++ b/data/cli/scout/docker_scout_policy_publish.yaml
@@ -0,0 +1,60 @@
+command: docker scout policy publish
+short: |
+    Package local Rego policies into an OCI bundle and push it to a registry (experimental)
+long: |-
+    The docker scout policy publish command packages Rego policies into an OCI policy bundle and pushes it to a registry. The published bundle can then be evaluated with docker scout policy --policy-bundle REFERENCE.
+
+    When no --policy-file or --policy-dir is given, the built-in default policy set is published. Authentication uses your existing registry credentials (run "docker login" first).
+usage: docker scout policy publish [OPTIONS] REFERENCE
+pname: docker scout policy
+plink: docker_scout_policy.yaml
+options:
+    - option: policy-dir
+      value_type: stringArray
+      default_value: '[]'
+      description: |
+        Path to a directory of local .rego policy files to include (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy-file
+      value_type: stringArray
+      default_value: '[]'
+      description: Path or http(s) URL to a .rego policy file to include (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Debug messages
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose-debug
+      value_type: bool
+      default_value: "false"
+      description: Verbose debug
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: "  Publish the built-in default policies:\n  $ docker scout policy publish registry.example.com/policies:latest\e[0m\n\n  Publish a directory of local policies:\n  $ docker scout policy publish --policy-dir ./rego registry.example.com/policies:latest\e[0m\n\n  Publish specific policy files:\n  $ docker scout policy publish --policy-file fixable.rego --policy-file licenses.rego registry.example.com/policies:latest\e[0m"
+deprecated: false
+experimental: false
+experimentalcli: true
+kubernetes: false
+swarm: false
+
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_push.yaml b/data/cli/scout/docker_scout_push.yaml
similarity index 91%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_push.yaml
rename to data/cli/scout/docker_scout_push.yaml
index b48952c9613a..361b89e3f894 100644
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_push.yaml
+++ b/data/cli/scout/docker_scout_push.yaml
@@ -63,6 +63,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: secrets
+      value_type: bool
+      default_value: "false"
+      description: Scan for secrets in the image
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: timestamp
       value_type: string
       description: Timestamp of image or tag creation
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_quickview.yaml b/data/cli/scout/docker_scout_quickview.yaml
similarity index 86%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_quickview.yaml
rename to data/cli/scout/docker_scout_quickview.yaml
index 4810146b37a4..8932e1361d3e 100644
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_quickview.yaml
+++ b/data/cli/scout/docker_scout_quickview.yaml
@@ -115,6 +115,46 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: policy-bundle
+      value_type: stringArray
+      default_value: '[]'
+      description: OCI reference of a policy bundle to evaluate (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy-config
+      value_type: string
+      description: |
+        Path or http(s) URL to a JSON file configuring policy enablement and inputs
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy-dir
+      value_type: stringArray
+      default_value: '[]'
+      description: Path to a directory of local .rego policy files (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: policy-file
+      value_type: stringArray
+      default_value: '[]'
+      description: Path or http(s) URL to a .rego policy file (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
     - option: ref
       value_type: string
       description: |-
@@ -147,7 +187,7 @@ options:
       swarm: false
     - option: vex-author
       value_type: stringSlice
-      default_value: '[]'
+      default_value: '[<.*@docker.com>]'
       description: List of VEX statement authors to accept
       deprecated: false
       hidden: false
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_recommendations.yaml b/data/cli/scout/docker_scout_recommendations.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_recommendations.yaml
rename to data/cli/scout/docker_scout_recommendations.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_repo.yaml b/data/cli/scout/docker_scout_repo.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_repo.yaml
rename to data/cli/scout/docker_scout_repo.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_repo_disable.yaml b/data/cli/scout/docker_scout_repo_disable.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_repo_disable.yaml
rename to data/cli/scout/docker_scout_repo_disable.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_repo_enable.yaml b/data/cli/scout/docker_scout_repo_enable.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_repo_enable.yaml
rename to data/cli/scout/docker_scout_repo_enable.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_repo_list.yaml b/data/cli/scout/docker_scout_repo_list.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_repo_list.yaml
rename to data/cli/scout/docker_scout_repo_list.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_sbom.yaml b/data/cli/scout/docker_scout_sbom.yaml
similarity index 94%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_sbom.yaml
rename to data/cli/scout/docker_scout_sbom.yaml
index 7a804e37e9d9..d51d5d5d2cbb 100644
--- a/_vendor/github.com/docker/scout-cli/docs/docker_scout_sbom.yaml
+++ b/data/cli/scout/docker_scout_sbom.yaml
@@ -93,6 +93,16 @@ options:
       experimentalcli: false
       kubernetes: false
       swarm: false
+    - option: secrets
+      value_type: bool
+      default_value: "false"
+      description: Scan for secrets in the image
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
 inherited_options:
     - option: debug
       value_type: bool
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_stream.yaml b/data/cli/scout/docker_scout_stream.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_stream.yaml
rename to data/cli/scout/docker_scout_stream.yaml
diff --git a/_vendor/github.com/docker/scout-cli/docs/docker_scout_version.yaml b/data/cli/scout/docker_scout_version.yaml
similarity index 100%
rename from _vendor/github.com/docker/scout-cli/docs/docker_scout_version.yaml
rename to data/cli/scout/docker_scout_version.yaml
diff --git a/data/cli/scout/docker_scout_vex.yaml b/data/cli/scout/docker_scout_vex.yaml
new file mode 100644
index 000000000000..f6e9444a50d7
--- /dev/null
+++ b/data/cli/scout/docker_scout_vex.yaml
@@ -0,0 +1,37 @@
+command: docker scout vex
+aliases: docker scout vex, docker scout vex
+short: Manage VEX attestations on images
+long: Manage VEX attestations on images
+pname: docker scout
+plink: docker_scout.yaml
+cname:
+    - docker scout vex get
+clink:
+    - docker_scout_vex_get.yaml
+inherited_options:
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Debug messages
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose-debug
+      value_type: bool
+      default_value: "false"
+      description: Verbose debug
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+experimental: false
+experimentalcli: true
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/scout/docker_scout_vex_get.yaml b/data/cli/scout/docker_scout_vex_get.yaml
new file mode 100644
index 000000000000..0578806662e1
--- /dev/null
+++ b/data/cli/scout/docker_scout_vex_get.yaml
@@ -0,0 +1,103 @@
+command: docker scout vex get
+short: Get VEX attestation for image
+long: The docker scout vex get command gets a VEX attestation for images.
+usage: docker scout vex get OPTIONS IMAGE
+pname: docker scout vex
+plink: docker_scout_vex.yaml
+options:
+    - option: key
+      value_type: string
+      default_value: https://registry.scout.docker.com/keyring/dhi/latest.pub
+      description: Signature key to use for verification
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: org
+      value_type: string
+      description: Namespace of the Docker organization
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: output
+      shorthand: o
+      value_type: string
+      description: Write the report to a file
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: platform
+      value_type: string
+      description: Platform of image to analyze
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: ref
+      value_type: string
+      description: |-
+        Reference to use if the provided tarball contains multiple references.
+        Can only be used with archive
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: skip-tlog
+      value_type: bool
+      default_value: "false"
+      description: Skip signature verification against public transaction log
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verify
+      value_type: bool
+      default_value: "false"
+      description: Verify the signature on the attestation
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Debug messages
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose-debug
+      value_type: bool
+      default_value: "false"
+      description: Verbose debug
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+experimental: false
+experimentalcli: true
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/scout/docker_scout_watch.yaml b/data/cli/scout/docker_scout_watch.yaml
new file mode 100644
index 000000000000..acc1d5bbffac
--- /dev/null
+++ b/data/cli/scout/docker_scout_watch.yaml
@@ -0,0 +1,229 @@
+command: docker scout watch
+short: |
+    Watch repositories in a registry and push images and indexes to Docker Scout
+long: |
+    The docker scout watch command watches repositories in a registry and pushes images or image indexes to Docker Scout.
+usage: docker scout watch
+pname: docker scout
+plink: docker_scout.yaml
+options:
+    - option: all-images
+      value_type: bool
+      default_value: "false"
+      description: |
+        Push all images instead of only the ones pushed during the watch command is running
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: dry-run
+      value_type: bool
+      default_value: "false"
+      description: Watch images and prepare them, but do not push them
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: interval
+      value_type: int64
+      default_value: "60"
+      description: Interval in seconds between checks
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: org
+      value_type: string
+      description: Namespace of the Docker organization to which image will be pushed
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: refresh-registry
+      value_type: bool
+      default_value: "false"
+      description: |
+        Refresh the list of repositories of a registry at every run. Only with --registry.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: registry
+      value_type: string
+      description: Registry to watch
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: repository
+      value_type: stringSlice
+      default_value: '[]'
+      description: Repository to watch
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: sbom
+      value_type: bool
+      default_value: "true"
+      description: Create and upload SBOMs
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: tag
+      value_type: stringSlice
+      default_value: '[]'
+      description: Regular expression to match tags to watch
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: workers
+      value_type: int
+      default_value: "3"
+      description: Number of concurrent workers
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+inherited_options:
+    - option: debug
+      value_type: bool
+      default_value: "false"
+      description: Debug messages
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: verbose-debug
+      value_type: bool
+      default_value: "false"
+      description: Verbose debug
+      deprecated: false
+      hidden: true
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+examples: |-
+    ### Watch for new images from two repositories and push them
+
+    ```console
+    $ docker scout watch --org my-org --repository registry-1.example.com/repo-1 --repository registry-2.example.com/repo-2
+    ```
+
+    ### Only push images with a specific tag
+
+    ```console
+    $ docker scout watch --org my-org --repository registry.example.com/my-service --tag latest
+    ```
+
+    ### Watch all repositories of a registry
+
+    ```console
+    $ docker scout watch --org my-org --registry registry.example.com
+    ```
+
+    ### Push all images and not just the new ones
+
+    ```console
+    $ docker scout watch --org my-org --repository registry.example.com/my-service --all-images
+    ```
+
+    ### Configure Artifactory integration
+
+    The following example creates a web hook endpoint for Artifactory to push new
+    image events into:
+
+    ```console
+    $ export DOCKER_SCOUT_ARTIFACTORY_API_USER=user
+    $ export DOCKER_SCOUT_ARTIFACTORY_API_PASSWORD=password
+    $ export DOCKER_SCOUT_ARTIFACTORY_WEBHOOK_SECRET=foo
+
+    $ docker scout watch --registry "type=artifactory,registry=example.jfrog.io,api=https://example.jfrog.io/artifactory,include=*/frontend*,exclude=*/dta/*,repository=docker-local,port=9000,subdomain-mode=true" --refresh-registry
+    ```
+
+    This will launch an HTTP server on port `9000` that will receive all `component` web
+    hook events, optionally validating the HMAC signature.
+
+    ### Configure Harbor integration
+
+    The following example creates a web hook endpoint for Harbor to push new image
+    events into:
+
+    ```console
+    $ export DOCKER_SCOUT_HARBOR_API_USER=admin
+    $ export DOCKER_SCOUT_HARBOR_API_PASSWORD=password
+    $ export DOCKER_SCOUT_HARBOR_WEBHOOK_AUTH="token foo"
+
+    $ docker scout watch --registry 'type=harbor,registry=demo.goharbor.io,api=https://demo.goharbor.io,include=*/foo/*,exclude=*/bar/*,port=9000' --refresh-registry
+    ```
+
+    This will launch an HTTP server on port `9000` that will receive all `component` web
+    hook events, optionally validating the HMAC signature.
+
+    ### Configure Nexus integration
+
+    The following example shows how to configure Sonartype Nexus integration:
+
+    ```console
+    $ export DOCKER_SCOUT_NEXUS_API_USER=admin
+    $ export DOCKER_SCOUT_NEXUS_API_PASSWORD=admin124
+
+    $ docker scout watch --registry 'type=nexus,registry=localhost:8082,api=http://localhost:8081,include=*/foo/*,exclude=*/bar/*,"repository=docker-test1,docker-test2"' --refresh-registry
+    ```
+
+    This ingests all images and tags in Nexus repositories called `docker-test1`
+    and `docker-test2` that match the `*/foo/*` include and `*/bar/*` exclude glob
+    pattern.
+
+    You can also create a web hook endpoint for Nexus to push new image events into:
+
+    ```console
+    $ export DOCKER_SCOUT_NEXUS_API_USER=admin
+    $ export DOCKER_SCOUT_NEXUS_API_PASSWORD=admin124
+    $ export DOCKER_SCOUT_NEXUS_WEBHOOK_SECRET=mysecret
+
+    $ docker scout watch --registry 'type=nexus,registry=localhost:8082,api=http://localhost:8081,include=*/foo/*,exclude=*/bar/*,"repository=docker-test1,docker-test2",port=9000' --refresh-registry
+    ```
+
+    This will launch an HTTP server on port `9000` that will receive all `component` web
+    hook events, optionally validating the HMAC signature.
+
+    ### Configure integration for other OCI registries
+
+    The following example shows how to integrate an OCI registry that implements the
+    `_catalog` endpoint:
+
+    ```console
+    $ docker scout watch --registry 'type=oci,registry=registry.example.com,include=*/scout-artifact-registry/*'
+    ```
+deprecated: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+
diff --git a/data/cli/secrets/docker_pass.yaml b/data/cli/secrets/docker_pass.yaml
new file mode 100644
index 000000000000..468af9c14654
--- /dev/null
+++ b/data/cli/secrets/docker_pass.yaml
@@ -0,0 +1,324 @@
+command: docker pass
+short: Manage your local OS keychain secrets.
+long: |-
+    Docker Pass is a helper for securely retrieving secrets from a range of
+    backends, such as your local OS keychain, password managers, or remote
+    vaults, and injecting them into containers and host commands when
+    needed. Each backend is implemented as a plugin.
+
+    ### Installation
+
+    On Docker Desktop, Secrets Engine and `docker pass` are integrated by default.
+    For Docker CE, install the packages separately from Docker's official
+    repository. This requires Docker Engine (`dockerd`) 29.2.0 or later. If you did
+    not install Docker Engine from that repository, add it with the official
+    convenience script:
+
+    ```shell
+    curl -fsSL https://get.docker.com | sh -s -- --setup-repo
+    ```
+
+    apt (Debian/Ubuntu):
+
+    ```shell
+    sudo apt-get update
+    sudo apt-get install docker-secrets-engine docker-secrets-engine-plugins
+    ```
+
+    dnf (Fedora):
+
+    ```shell
+    sudo dnf install docker-secrets-engine docker-secrets-engine-plugins
+    ```
+
+    Then enable the service for your user:
+
+    ```shell
+    systemctl --user daemon-reload
+    systemctl --user enable --now docker-secrets-engine.service
+    ```
+
+    For full instructions see the [Secrets Engine README](https://github.com/docker/secrets-engine/blob/main/README.md).
+
+    ### Secret References
+
+    A secret reference is written using the `se://` URI scheme and either
+    identifies a specific secret or matches multiple secrets through a
+    pattern over the realm structure. For example:
+
+    - `se://docker/auth/hub/alice` — resolves to a specific secret, Alice's
+      Docker Hub credential.
+    - `se://docker/auth/hub/*` — matches every credential stored directly under
+      Docker Hub.
+    - `se://docker/auth/**` — matches every Docker auth secret across all
+      registries.
+
+    Resolution fans out across every plugin whose pattern matches the
+    reference, so even a specific ID can return multiple values if more
+    than one plugin has stored a secret under that ID.
+    The same reference can be reused across environments and storage
+    backends without rewriting Compose files or application
+    configuration. For example, it may resolve against your local OS
+    keychain in development and against a production vault in CI or on a
+    server.
+
+    The engine resolves these references in two contexts:
+
+    #### Containers
+
+    Anywhere Docker accepts an environment-variable value, write
+    `se://<id|pattern>` and the engine resolves it just before the container
+    starts.
+
+    With `docker run -e`:
+
+    ```sh
+    docker run --rm -e OPENAI_API_KEY=se://openai/api-key busybox sh -c 'echo "$OPENAI_API_KEY"'
+    ```
+
+    In a Compose file under `environment:`:
+
+    ```yaml
+    services:
+      app:
+        image: your/image
+        environment:
+          DB_PASSWORD: se://postgres/prod/app-user
+    ```
+
+    Note: `docker compose build` is not supported yet.
+
+    #### Host commands
+
+    `docker pass run` wraps any host process and resolves `se://`
+    references in its environment before exec'ing it. Any env variable
+    whose value has the form `se://<id|pattern>` is replaced with the
+    resolved secret; everything else is passed through untouched.
+
+    ```sh
+    GH_TOKEN=se://gh-token docker pass run -- gh repo list
+    ```
+
+    #### Identifiers
+
+    Secret IDs are hierarchical, path-like strings. Components are separated
+    by `/`; each component may contain `A-Z`, `a-z`, `0-9`, `.`, `-`, `_`,
+    or `:`. No leading, trailing, or empty components. Matching is
+    case-sensitive. A predictable realm/namespace structure
+    (e.g. `docker/auth/<registry>`, `docker/db/<env>/password`) makes
+    automation and access control easier.
+
+    #### Patterns
+
+    Patterns follow the same rules as identifiers, with two extra tokens:
+
+    - `*` — matches exactly one component.
+    - `**` — matches zero or more components.
+
+    Wildcards must occupy a whole component (e.g. `auth/*/token` is valid;
+    `auth/foo*` is not), and a single component may contain at most one of
+    `*` or `**`.
+
+    Example patterns:
+
+    - `docker/auth/**` — every Docker auth secret in any sub-realm.
+    - `myrealm/*/password` — password entries one level deep under
+      `myrealm`.
+    - `**` — catch-all.
+
+    #### Routing
+
+    When a container references `se://<id|pattern>`, the engine fans the lookup out
+    to every plugin whose declared pattern matches `<id|pattern>` and merges their
+    responses. If no plugin matches, the lookup fails and the container
+    does not start.
+
+    ### Plugin Management
+
+    Use the CLI to inspect loaded and available plugins:
+
+    ```sh
+    docker pass plugins ls
+    ```
+
+    Plugins marked as **configurable** can be enabled or disabled at runtime:
+
+    ```sh
+    docker pass plugins enable <name>
+    docker pass plugins disable <name>
+    ```
+
+    ### Plugins
+
+    #### OS Keychain
+
+    - **Plugin name:** `docker-pass`
+    - **Storage backend:** the local OS keychain, accessed via
+      platform-specific APIs:
+      - **Windows:** Windows Credential Manager API
+      - **macOS:** Keychain Services API
+      - **Linux:** `org.freedesktop.secrets` API (requires DBus and a
+        Secret Service provider such as `gnome-keyring` or `kdewallet`)
+    - **Use:** holds secrets you store directly with `docker pass` (and
+      internal secrets used by other plugins, such as the 1Password service
+      account token). Always on; not configurable.
+
+    #### 1Password (configurable)
+
+    Each item matches the requested pattern under up to three candidate IDs:
+
+    1. **Raw item ID** — the opaque alphanumeric ID that 1Password assigns
+       (e.g. `alphanumeric_26char`).
+    2. **`<vault-id>/<title>`** — the vault's ID joined with the item's
+       normalized title.
+    3. **`<vault-name>/<title>`** — the vault's display name joined with
+       the item's normalized title.
+
+    Normalization (applied to vault names and titles) follows 1Password's
+    [secret-reference syntax](https://developer.1password.com/docs/cli/secret-reference-syntax/):
+    spaces become `-`, `(` and `)` are stripped, `/` and `&` become `_`,
+    any remaining character outside `[a-zA-Z0-9-._]` is removed, and the
+    result is lowercased. Following 1Password's matching rules makes the
+    plugin case-insensitive, so existing `op://` references can be reused
+    as-is.
+    Candidates that don't produce a valid ID are skipped silently, so
+    items with unusual names are still matchable through one of the other
+    forms.
+
+    ##### CLI version
+
+    - **Plugin name:** `1password-cli`
+    - **How it authenticates:** delegates to the [`op` CLI](https://developer.1password.com/docs/cli/).
+      You need `op` installed and an active 1Password session. On macOS
+      this typically means the 1Password desktop app with biometric unlock
+      enabled; on other platforms, `op signin`.
+    - **Setup:** no tokens to manage. If your local `op` is signed in, the
+      plugin can resolve secrets.
+    - **Behavior:** when Docker Desktop starts, the plugin performs an
+      initial fetch of all items, which triggers a 1Password authorization
+      prompt. The resulting cache is then refreshed periodically.
+    - **Fatal errors:** the plugin treats a few conditions as
+      unrecoverable and stops itself instead of retrying:
+      - the `op` binary cannot be found on `PATH`,
+      - the user dismisses or lets the 1Password authorization prompt
+        time out.
+
+      When this happens the plugin is reported as crashed in
+      `docker pass plugins ls`. Resolve the underlying issue (install
+      `op`, sign in, accept the prompt) and re-enable the plugin with
+      `docker pass plugins enable 1password-cli`.
+    - **Enable / disable:**
+      ```sh
+      docker pass plugins enable 1password-cli
+      docker pass plugins disable 1password-cli
+      ```
+
+    ##### Service account token version
+
+    - **Plugin name:** `1password-sdk`
+    - **How it authenticates:** uses the official 1Password Go SDK with a
+      [service account token](https://developer.1password.com/docs/service-accounts/get-started/)
+      scoped to the vaults you want to expose.
+    - **Setup:** supply the token once on stdin. It is stored in the OS
+      keychain and the plugin is enabled in the same step:
+      ```sh
+      echo "$OP_SERVICE_ACCOUNT_TOKEN" | docker pass plugins 1password setup
+      ```
+    - **Teardown:** remove the token and disable the plugin:
+      ```sh
+      docker pass plugins 1password purge
+      ```
+
+    ### Feedback and SDK
+
+    Use the Go SDK at
+    [github.com/docker/secrets-engine](https://github.com/docker/secrets-engine)
+    to integrate secret resolution into your own code, build custom
+    clients, or write new plugins.
+
+    Have a feature request or hit a bug? File an issue at [github.com/docker/secrets-engine/issues](https://github.com/docker/secrets-engine/issues).
+usage: docker pass set|get|ls|rm|run
+pname: docker
+plink: docker.yaml
+cname:
+    - docker pass get
+    - docker pass ls
+    - docker pass plugins
+    - docker pass rm
+    - docker pass run
+    - docker pass set
+clink:
+    - docker_pass_get.yaml
+    - docker_pass_ls.yaml
+    - docker_pass_plugins.yaml
+    - docker_pass_rm.yaml
+    - docker_pass_run.yaml
+    - docker_pass_set.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+examples: |-
+    ### Using keychain secrets in containers
+
+    Create a secret:
+
+    ```console
+    $ docker pass set GH_TOKEN=123456789
+    ```
+
+    Create a secret from STDIN:
+
+    ```console
+    echo "my_val" | docker pass set GH_TOKEN
+    ```
+
+    Run a container that uses the secret:
+
+    ```console
+    $ docker run -e GH_TOKEN= -dt --name demo busybox
+    ```
+
+    Inspect the secret from inside the container:
+
+    ```console
+    $ docker exec demo sh -c 'echo $GH_TOKEN'
+    123456789
+    ```
+
+    Explicitly assign a secret to a different environment variable:
+
+    ```console
+    $ docker run -e GITHUB_TOKEN=se://GH_TOKEN -dt --name demo busybox
+    ```
+
+    ### Using keychain secrets in Compose
+
+    Store the secrets:
+
+    ```console
+    $ docker pass set myapp/anthropic/api-key=sk-ant-...
+    $ docker pass set myapp/postgres/password=s3cr3t
+    ```
+
+    ```yaml
+    services:
+      api:
+        image: service1
+        environment:
+          - ANTHROPIC_API_KEY=se://myapp/anthropic/api-key
+          - POSTGRES_PASSWORD=se://myapp/postgres/password
+
+      worker:
+        image: service2
+        command: worker
+        environment:
+          - ANTHROPIC_API_KEY=se://myapp/anthropic/api-key
+
+      db:
+        image: postgres:17
+        environment:
+          - POSTGRES_PASSWORD=se://myapp/postgres/password
+    ```
diff --git a/data/cli/secrets/docker_pass_get.yaml b/data/cli/secrets/docker_pass_get.yaml
new file mode 100644
index 000000000000..cc5dc2db18e7
--- /dev/null
+++ b/data/cli/secrets/docker_pass_get.yaml
@@ -0,0 +1,13 @@
+command: docker pass get
+short: Get a secret from a keystore.
+long: |-
+    Retrieves a named secret from the local OS keychain. The secret value is masked in output.
+usage: docker pass get NAME
+pname: docker pass
+plink: docker_pass.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/secrets/docker_pass_ls.yaml b/data/cli/secrets/docker_pass_ls.yaml
new file mode 100644
index 000000000000..877e649cc25b
--- /dev/null
+++ b/data/cli/secrets/docker_pass_ls.yaml
@@ -0,0 +1,13 @@
+command: docker pass ls
+short: List all secrets from local keychain.
+long: |-
+    Lists the names of all secrets stored in the local OS keychain.
+usage: docker pass ls
+pname: docker pass
+plink: docker_pass.yaml
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
diff --git a/data/cli/secrets/docker_pass_plugins.yaml b/data/cli/secrets/docker_pass_plugins.yaml
new file mode 100644
index 000000000000..87104358352e
--- /dev/null
+++ b/data/cli/secrets/docker_pass_plugins.yaml
@@ -0,0 +1,40 @@
+command: docker pass plugins
+short: Manage secrets engine plugins.
+long: |-
+    Manage the plugins that the secrets engine uses to resolve secret references.
+
+    Each plugin declares its scope through a pattern, and the engine routes every lookup to the plugins whose pattern matches the requested identifier. A plugin registered with `**` receives every request, while a plugin scoped to `docker/auth/**` only serves Docker auth lookups.
+
+    Use the subcommands to inspect which plugins are registered and their current status, to enable or disable configurable plugins at runtime, and to set up or tear down plugin-specific credentials (such as the 1Password service account token).
+usage: docker pass plugins
+pname: docker pass
+plink: docker_pass.yaml
+cname:
+    - docker pass plugins 1password
+    - docker pass plugins disable
+    - docker pass plugins enable
+    - docker pass plugins ls
+clink:
+    - docker_pass_plugins_1password.yaml
+    - docker_pass_plugins_disable.yaml
+    - docker_pass_plugins_enable.yaml
+    - docker_pass_plugins_ls.yaml
+deprecated: false
+hidden: false
+experimental: true
+experimentalcli: true
+kubernetes: false
+swarm: false
+examples: |-
+    List all registered plugins and their status:
+
+    ```sh
+    docker pass plugins ls
+    ```
+
+    Enable or disable a configurable plugin:
+
+    ```sh
+    docker pass plugins enable 1password-cli
+    docker pass plugins disable 1password-cli
+    ```
diff --git a/data/cli/secrets/docker_pass_plugins_1password.yaml b/data/cli/secrets/docker_pass_plugins_1password.yaml
new file mode 100644
index 000000000000..0e6b9bf6106b
--- /dev/null
+++ b/data/cli/secrets/docker_pass_plugins_1password.yaml
@@ -0,0 +1,42 @@
+command: docker pass plugins 1password
+short: Manage the 1Password SDK plugin.
+long: |-
+    Manage the `1password-sdk` plugin, which resolves secret references against 1Password through the official 1Password SDK.
+
+    The plugin authenticates with a [service account token](https://developer.1password.com/docs/service-accounts/get-started/) scoped to the vaults you want to expose. The token is stored in the local OS keychain. Use the subcommands to install the token (and enable the plugin) or to remove it (and disable the plugin).
+
+    Items reachable through this plugin are matched under any of:
+
+    - the raw 1Password item ID,
+    - `<vault-id>/<title>`,
+    - `<vault-name>/<title>`,
+    - a native 1Password secret-reference path (`<vault>/<item>/<field>` or `<vault>/<item>/<section>/<field>`), resolved directly via the SDK as if prefixed with `op://`.
+
+    Matching for the title-based forms follows 1Password's normalization rules and is case-insensitive, so existing `op://` references can be reused as-is.
+usage: docker pass plugins 1password
+pname: docker pass plugins
+plink: docker_pass_plugins.yaml
+cname:
+    - docker pass plugins 1password purge
+    - docker pass plugins 1password setup
+clink:
+    - docker_pass_plugins_1password_purge.yaml
+    - docker_pass_plugins_1password_setup.yaml
+deprecated: false
+hidden: false
+experimental: true
+experimentalcli: true
+kubernetes: false
+swarm: false
+examples: |-
+    Install the service account token and enable the plugin:
+
+    ```sh
+    echo "$OP_SERVICE_ACCOUNT_TOKEN" | docker pass plugins 1password setup
+    ```
+
+    Remove the token and disable the plugin:
+
+    ```sh
+    docker pass plugins 1password purge
+    ```
diff --git a/data/cli/secrets/docker_pass_plugins_1password_purge.yaml b/data/cli/secrets/docker_pass_plugins_1password_purge.yaml
new file mode 100644
index 000000000000..4985759ef480
--- /dev/null
+++ b/data/cli/secrets/docker_pass_plugins_1password_purge.yaml
@@ -0,0 +1,15 @@
+command: docker pass plugins 1password purge
+short: Disable the plugin and remove the stored 1Password service account token.
+long: |-
+    Disable the `1password-sdk` plugin on the running secrets-engine daemon and remove the service account token from the local OS keychain.
+
+    After purge, the plugin no longer participates in secret resolution and the token is gone from local storage. Run `setup` again to re-enable it.
+usage: docker pass plugins 1password purge
+pname: docker pass plugins 1password
+plink: docker_pass_plugins_1password.yaml
+deprecated: false
+hidden: false
+experimental: true
+experimentalcli: true
+kubernetes: false
+swarm: false
diff --git a/data/cli/secrets/docker_pass_plugins_1password_setup.yaml b/data/cli/secrets/docker_pass_plugins_1password_setup.yaml
new file mode 100644
index 000000000000..9dfe9857cc22
--- /dev/null
+++ b/data/cli/secrets/docker_pass_plugins_1password_setup.yaml
@@ -0,0 +1,17 @@
+command: docker pass plugins 1password setup
+short: Set the 1Password service account token and enable the plugin.
+long: |-
+    Store a 1Password [service account token](https://developer.1password.com/docs/service-accounts/get-started/) in the local OS keychain and enable the `1password-sdk` plugin.
+
+    The token is read from STDIN and replaces any previously stored token. Once it is stored, the secrets engine is asked to enable the plugin so subsequent lookups resolve against 1Password.
+
+    Service account tokens are scoped to a fixed set of vaults; only items in those vaults are reachable through the plugin.
+usage: docker pass plugins 1password setup
+pname: docker pass plugins 1password
+plink: docker_pass_plugins_1password.yaml
+deprecated: false
+hidden: false
+experimental: true
+experimentalcli: true
+kubernetes: false
+swarm: false
diff --git a/data/cli/secrets/docker_pass_plugins_disable.yaml b/data/cli/secrets/docker_pass_plugins_disable.yaml
new file mode 100644
index 000000000000..527a6a722089
--- /dev/null
+++ b/data/cli/secrets/docker_pass_plugins_disable.yaml
@@ -0,0 +1,11 @@
+command: docker pass plugins disable
+short: Disable a secrets engine plugin.
+usage: docker pass plugins disable <name>
+pname: docker pass plugins
+plink: docker_pass_plugins.yaml
+deprecated: false
+hidden: false
+experimental: true
+experimentalcli: true
+kubernetes: false
+swarm: false
diff --git a/data/cli/secrets/docker_pass_plugins_enable.yaml b/data/cli/secrets/docker_pass_plugins_enable.yaml
new file mode 100644
index 000000000000..e912538cdfc2
--- /dev/null
+++ b/data/cli/secrets/docker_pass_plugins_enable.yaml
@@ -0,0 +1,11 @@
+command: docker pass plugins enable
+short: Enable a secrets engine plugin.
+usage: docker pass plugins enable <name>
+pname: docker pass plugins
+plink: docker_pass_plugins.yaml
+deprecated: false
+hidden: false
+experimental: true
+experimentalcli: true
+kubernetes: false
+swarm: false
diff --git a/data/cli/secrets/docker_pass_plugins_ls.yaml b/data/cli/secrets/docker_pass_plugins_ls.yaml
new file mode 100644
index 000000000000..08b04b777906
--- /dev/null
+++ b/data/cli/secrets/docker_pass_plugins_ls.yaml
@@ -0,0 +1,11 @@
+command: docker pass plugins ls
+short: List registered secrets engine plugins.
+usage: docker pass plugins ls
+pname: docker pass plugins
+plink: docker_pass_plugins.yaml
+deprecated: false
+hidden: false
+experimental: true
+experimentalcli: true
+kubernetes: false
+swarm: false
diff --git a/data/cli/secrets/docker_pass_rm.yaml b/data/cli/secrets/docker_pass_rm.yaml
new file mode 100644
index 000000000000..03a3685f5707
--- /dev/null
+++ b/data/cli/secrets/docker_pass_rm.yaml
@@ -0,0 +1,42 @@
+command: docker pass rm
+short: Remove secrets from local keychain.
+long: |-
+    Removes one or more named secrets from the local OS keychain. Use `--all` to remove every stored secret at once.
+usage: docker pass rm name1 name2 ... [flags]
+pname: docker pass
+plink: docker_pass.yaml
+options:
+    - option: all
+      value_type: bool
+      default_value: "false"
+      description: Remove all secrets
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+examples: |-
+    ### Remove a specific secret:
+
+    ```console
+    $ docker pass rm GH_TOKEN
+    ```
+
+    ### Remove multiple secrets:
+
+    ```console
+    $ docker pass rm GH_TOKEN NPM_TOKEN
+    ```
+
+    ### Remove all secrets:
+
+    ```console
+    $ docker pass rm --all
+    ```
diff --git a/data/cli/secrets/docker_pass_run.yaml b/data/cli/secrets/docker_pass_run.yaml
new file mode 100644
index 000000000000..32bf976f3b9a
--- /dev/null
+++ b/data/cli/secrets/docker_pass_run.yaml
@@ -0,0 +1,56 @@
+command: docker pass run
+short: Run a command with `se://` environment references resolved.
+long: |-
+    Scans the current environment (plus any `--env-file` inputs) for variables
+    whose value is exactly `se://<ID|pattern>`. Each reference is resolved through the
+    secrets-engine daemon and the resolved value is passed to the child process.
+    The child inherits stdin, stdout, and stderr.
+
+    Requires the secrets-engine daemon (Docker Desktop) to be running.
+
+    If any reference cannot be resolved, the command fails before the child is
+    started and exits non-zero.
+usage: docker pass run -- CMD [ARGS...] [flags]
+pname: docker pass
+plink: docker_pass.yaml
+options:
+    - option: env-file
+      value_type: stringArray
+      default_value: '[]'
+      description: Read environment variables from a dotenv-formatted file. Repeatable; later files override earlier files and the process environment.
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: true
+experimentalcli: true
+kubernetes: false
+swarm: false
+examples: |-
+    ### Run a command with one secret in its environment:
+
+    ```console
+    $ SE_TOKEN=se://gh-token docker pass run -- gh repo list
+    ```
+
+    ### Multiple references:
+
+    ```console
+    $ DB_PASSWORD=se://myapp/postgres/password API_KEY=se://myapp/anthropic/api-key docker pass run -- ./my-binary
+    ```
+
+    ### Resolve references from a dotenv file:
+
+    ```console
+    $ docker pass run --env-file .env -- ./my-binary
+    ```
+
+    ### Multiple files (later overrides earlier; files override the process environment):
+
+    ```console
+    $ docker pass run --env-file .env --env-file .env.local -- ./my-binary
+    ```
diff --git a/data/cli/secrets/docker_pass_set.yaml b/data/cli/secrets/docker_pass_set.yaml
new file mode 100644
index 000000000000..1f0e7e7c33df
--- /dev/null
+++ b/data/cli/secrets/docker_pass_set.yaml
@@ -0,0 +1,75 @@
+command: docker pass set
+short: Set a secret
+long: |-
+    Stores a secret in the local OS keychain. The secret value can be provided inline (`NAME=VALUE`) or piped via STDIN.
+
+    Behavior when a secret with the same id already exists is platform-dependent:
+      - macOS (Keychain): the command fails with a duplicate-item error.
+      - Linux (Secret Service) and Windows (Credential Manager): the existing
+        value is silently overwritten.
+
+    Pass `--force` to overwrite an existing secret. On Linux and Windows the
+    replacement is performed atomically. On macOS the Keychain API requires
+    a delete-then-add sequence.
+usage: docker pass set id[=value] [flags]
+pname: docker pass
+plink: docker_pass.yaml
+options:
+    - option: force
+      shorthand: f
+      value_type: bool
+      default_value: "false"
+      description: Overwrite existing secret if it already exists
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+    - option: metadata
+      value_type: stringArray
+      default_value: '[]'
+      description: Non-sensitive key=value metadata (repeatable)
+      deprecated: false
+      hidden: false
+      experimental: false
+      experimentalcli: false
+      kubernetes: false
+      swarm: false
+deprecated: false
+hidden: false
+experimental: false
+experimentalcli: false
+kubernetes: false
+swarm: false
+examples: |-
+    ### Set a secret:
+
+    ```console
+    $ docker pass set POSTGRES_PASSWORD=my-secret-password
+    ```
+
+    ### Or pass the secret via STDIN:
+
+    ```console
+    $ echo my-secret-password > pwd.txt
+    $ cat pwd.txt | docker pass set POSTGRES_PASSWORD
+    ```
+
+    ### Set a secret with metadata:
+
+    ```console
+    $ docker pass set POSTGRES_PASSWORD=my-secret-password --metadata owner=alice --metadata expiry=2027-03-01
+    ```
+
+    ### Or pass a JSON payload with secret and metadata via STDIN:
+
+    ```console
+    $ echo '{"secret":"my-secret-password","metadata":{"owner":"alice"}}' | docker pass set POSTGRES_PASSWORD
+    ```
+
+    ### Overwrite an existing secret:
+
+    ```console
+    $ docker pass set POSTGRES_PASSWORD=new-secret-password --force
+    ```
diff --git a/data/desktop-cli/docker_desktop_enable_model_runner.yaml b/data/desktop-cli/docker_desktop_enable_model_runner.yaml
deleted file mode 100644
index 4e163b0a4298..000000000000
--- a/data/desktop-cli/docker_desktop_enable_model_runner.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
-command: docker desktop enable model-runner
-short: Manage Docker Model Runner settings
-long: Enable and manage Docker Model Runner settings used by 'docker model'
-usage: docker desktop enable model-runner [OPTIONS]
-pname: docker desktop enable
-plink: docker_desktop_enable.yaml
-options:
-    - option: no-tcp
-      value_type: bool
-      default_value: "false"
-      description: Disable TCP connection. Cannot be used with --tcp.
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: tcp
-      value_type: port
-      default_value: "12434"
-      description: |
-        Enable or change TCP port for connection (1-65535). Cannot be used with --no-tcp.
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
\ No newline at end of file
diff --git a/data/desktop-cli/docker_desktop_module.yaml b/data/desktop-cli/docker_desktop_module.yaml
deleted file mode 100644
index 4e044778be32..000000000000
--- a/data/desktop-cli/docker_desktop_module.yaml
+++ /dev/null
@@ -1,19 +0,0 @@
-command: docker desktop module
-short: Manage Docker Desktop modules
-long: Manage Docker Desktop modules
-pname: docker desktop
-plink: docker_desktop.yaml
-cname:
-    - docker desktop module ls
-    - docker desktop module reset
-    - docker desktop module update
-clink:
-    - docker_desktop_module_ls.yaml
-    - docker_desktop_module_reset.yaml
-    - docker_desktop_module_update.yaml
-deprecated: false
-hidden: true
-experimental: false
-experimentalcli: true
-kubernetes: false
-swarm: false
\ No newline at end of file
diff --git a/data/desktop-cli/docker_desktop_module_ls.yaml b/data/desktop-cli/docker_desktop_module_ls.yaml
deleted file mode 100644
index 953cd1cce793..000000000000
--- a/data/desktop-cli/docker_desktop_module_ls.yaml
+++ /dev/null
@@ -1,35 +0,0 @@
-command: docker desktop module ls
-aliases: docker desktop module ls, docker desktop module list
-short: List modules
-long: List modules
-usage: docker desktop module ls
-pname: docker desktop module
-plink: docker_desktop_module.yaml
-options:
-    - option: format
-      value_type: string
-      default_value: pretty
-      description: 'Format the output. Values: [pretty | json].'
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: quiet
-      shorthand: q
-      value_type: bool
-      default_value: "false"
-      description: Only display IDs.
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: true
-kubernetes: false
-swarm: false
\ No newline at end of file
diff --git a/data/desktop-cli/docker_desktop_module_reset.yaml b/data/desktop-cli/docker_desktop_module_reset.yaml
deleted file mode 100644
index f3fdc72b97c1..000000000000
--- a/data/desktop-cli/docker_desktop_module_reset.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
-command: docker desktop module reset
-short: Reset all updated modules
-long: Reset all updated modules
-usage: docker desktop module reset
-pname: docker desktop module
-plink: docker_desktop_module.yaml
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: true
-kubernetes: false
-swarm: false
\ No newline at end of file
diff --git a/data/desktop-cli/docker_desktop_module_update.yaml b/data/desktop-cli/docker_desktop_module_update.yaml
deleted file mode 100644
index 2013c51d5e32..000000000000
--- a/data/desktop-cli/docker_desktop_module_update.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
-command: docker desktop module update
-short: Update all modules
-long: Update all modules
-usage: docker desktop module update
-pname: docker desktop module
-plink: docker_desktop_module.yaml
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: true
-kubernetes: false
-swarm: false
\ No newline at end of file
diff --git a/data/desktop_release.yaml b/data/desktop_release.yaml
new file mode 100644
index 000000000000..aac397bde44f
--- /dev/null
+++ b/data/desktop_release.yaml
@@ -0,0 +1,941 @@
+releases:
+  - version: "4.46.0"
+    date: "2025-09-11"
+    summary: "Learning center walkthrough for Docker MCP Toolkit, PAC configuration control, and redesigned update experience"
+    highlights:
+      - "Added Learning center walkthrough for Docker MCP Toolkit and onboarding improvements"
+      - "Administrators can now control PAC configurations with Settings Management"
+      - "Update experience redesigned for easier management"
+      - "Docker Buildx v0.28.0"
+      - "Docker Engine v28.4.0"
+      - "Fixed slow Docker Desktop startup on Mac"
+      - "Improved Docker Model Runner security on Mac and Windows"
+
+  - version: "4.45.0"
+    date: "2025-08-28"
+    summary: "Docker Model Runner is now generally available"
+    highlights:
+      - "Docker Model Runner is now GA"
+      - "Docker Compose v2.39.2"
+      - "Docker Buildx v0.27.0"
+      - "Docker Engine v28.3.3"
+      - "Fixed diagnostics crash behind authenticated proxy"
+      - "Mac: Fixed crash after waking from sleep"
+      - "Windows: Fixed CLI plugin deployment permissions"
+
+  - version: "4.44.3"
+    date: "2025-08-20"
+    summary: "Security fix for CVE-2025-9074"
+    highlights:
+      - "Fixed CVE-2025-9074 - malicious container access vulnerability"
+      - "Fixed Docker Offload dialog blocking dashboard access"
+
+  - version: "4.44.2"
+    date: "2025-08-15"
+    summary: "Docker Offload Beta support"
+    highlights:
+      - "Added Docker Offload to Beta features settings"
+      - "Updates to support Docker Offload Beta"
+
+  - version: "4.44.1"
+    date: "2025-08-13"
+    summary: "Bug fixes for startup and WSL 2 issues"
+    highlights:
+      - "Fixed startup failure when vpnkit CIDR is locked"
+      - "Windows: Fixed volume visibility after upgrade"
+      - "Windows: Fixed WSL 2 proxy authentication error"
+
+  - version: "4.44.0"
+    date: "2025-08-07"
+    summary: "WSL 2 stability, Model Runner improvements, Apple Virtualization default"
+    highlights:
+      - "WSL 2 stability improvements"
+      - "Docker Model Runner request/response inspection"
+      - "Multiple model support with resource warnings"
+      - "Apple Virtualization is now default VMM on Mac"
+      - "Docker Compose v2.39.1"
+      - "Docker Engine v28.3.2"
+      - "New docker desktop kubernetes command"
+      - "Settings search functionality added"
+
+  - version: "4.43.2"
+    date: "2025-07-15"
+    summary: "Version upgrades and model CLI update"
+    highlights:
+      - "Docker Compose v2.38.2"
+      - "Docker Engine v28.3.2"
+      - "Docker Model CLI v0.1.33"
+
+  - version: "4.43.1"
+    date: "2025-07-04"
+    summary: "UI and extension communication fixes"
+    highlights:
+      - "Fixed Docker Desktop UI breaking with HTML in Ask Gordon responses"
+      - "Fixed extensions backend communication issues"
+
+  - version: "4.43.0"
+    date: "2025-07-03"
+    summary: "Compose Bridge GA, security fixes"
+    highlights:
+      - "Compose Bridge is now generally available"
+      - "Docker Buildx v0.25.0"
+      - "Docker Engine v28.3.0"
+      - "Fixed CVE-2025-6587 - sensitive environment variables in logs"
+      - "Fixed container port mapping issues"
+      - "Settings Apply button no longer restarts VM"
+
+  - version: "4.42.1"
+    date: "2025-06-18"
+    summary: "Docker Compose upgrade and bug fixes"
+    highlights:
+      - "Docker Compose v2.37.1"
+      - "Fixed Docker domains unreachable with invalid proxy"
+      - "Fixed port exposure deadlock"
+      - "Mac: Fixed empty container port list on creation"
+      - "Windows: Disabled Resource Saver mode in WSL 2"
+
+  - version: "4.42.0"
+    date: "2025-06-04"
+    summary: "IPv6 support, Docker MCP Toolkit integration, Model Runner for Windows ARM"
+    highlights:
+      - "Expanded network compatibility with IPv6 support"
+      - "Docker MCP Toolkit natively integrated"
+      - "Model Runner available for Windows ARM GPUs"
+      - "Gordon integrates MCP Toolkit with 100+ servers"
+      - "Docker Buildx v0.24.0"
+      - "Docker Engine v28.2.2"
+      - "Fixed memory protection keys for VS Code Dev Containers"
+      - "Sign-in Enforcement available to all subscriptions"
+
+  - version: "4.41.2"
+    date: "2025-05-06"
+    summary: "Model Runner menu display fix"
+    highlights:
+      - "Fixed Models menu displaying when Model Runner not supported"
+
+  - version: "4.41.1"
+    date: "2025-04-30"
+    summary: "Proxy configuration and DLL conflict fixes"
+    highlights:
+      - "Fixed startup failure with proxy in admin-settings.json"
+      - "Windows: Fixed llama.cpp DLL conflicts with 3rd party tools"
+
+  - version: "4.41.0"
+    date: "2025-04-28"
+    summary: "Model Runner on Windows, Microsoft App Store, security fixes"
+    highlights:
+      - "Docker Model Runner available on x86 Windows with NVIDIA GPUs"
+      - "Push models to Docker Hub with Model Runner"
+      - "Model management UI in Docker Desktop"
+      - "Docker Compose and Testcontainers support Model Runner"
+      - "Available in Microsoft App Store"
+      - "Docker Engine v28.1.1"
+      - "Fixed CVE-2025-3224, CVE-2025-4095, CVE-2025-3911"
+
+  - version: "4.40.0"
+    date: "2025-03-31"
+    summary: "Docker Model Runner Beta for Mac with Apple Silicon"
+    highlights:
+      - "Pull, run, and manage AI models from Docker Hub (Beta)"
+      - "Docker Buildx v0.22.0"
+      - "Docker Compose v2.34.0"
+      - "Docker Engine v28.0.4"
+      - "NVIDIA Container Toolkit v1.17.5"
+      - "Fixed UDP forwarding to containers"
+      - "Mac: Unix domain socket sharing support"
+      - "Windows: Improved WSL2 port-mapping throughput"
+
+  - version: "4.39.0"
+    date: "2025-03-05"
+    summary: "Docker Desktop CLI GA, multi-platform image support"
+    highlights:
+      - "Docker Desktop CLI is now GA with docker desktop logs"
+      - "Support for --platform flag on docker load and save"
+      - "Docker Compose v2.33.1"
+      - "Docker Engine v28.0.1"
+      - "Ask Gordon improvements for deeper context"
+      - "Fixed CVE-2025-1696 - proxy credentials disclosure"
+      - "Fixed Kubernetes PKI certificate expiration"
+
+  - version: "4.38.0"
+    date: "2025-01-30"
+    summary: "PKG installer GA, multi-node Kubernetes, independent updates"
+    highlights:
+      - "PKG installer for Mac is now GA"
+      - "Enforcing sign-in via configuration profiles GA"
+      - "Components can be updated independently (Beta)"
+      - "Multi-node Kubernetes clusters support"
+      - "Ask Gordon more widely available (Beta)"
+      - "Docker Engine v27.5.1"
+      - "containerd v1.7.24"
+      - "Fixed container creation with curl when ECI enabled"
+
+  - version: "4.37.2"
+    date: "2025-01-09"
+    summary: "Mac security component update prevention fix"
+    highlights:
+      - "Mac: Prevents vmnetd and socket update issues"
+
+  - version: "4.37.1"
+    date: "2024-12-17"
+    summary: "AI Catalog and ECI fixes"
+    highlights:
+      - "Fixed AI Catalog availability in Docker Hub"
+      - "Fixed ECI panic with index out of range error"
+
+  - version: "4.37.0"
+    date: "2024-12-12"
+    summary: "Desktop CLI Beta, AI Catalog integration"
+    highlights:
+      - "Docker Desktop CLI for command-line operations (Beta)"
+      - "AI Catalog from Docker Hub in Desktop"
+      - "Docker Buildx v0.19.2"
+      - "Docker Engine v27.4.0"
+      - "Default disk usage limit increased to 1TB"
+      - "Mac: Fixed root permission directory creation"
+      - "Windows: Windows on ARM support with WSL 2.3.24+"
+
+  - version: "4.36.1"
+    date: "2025-01-09"
+    summary: "Mac security component update prevention fix"
+    highlights:
+      - "Mac: Prevents vmnetd and socket update issues"
+
+  - version: "4.36.0"
+    date: "2024-11-18"
+    summary: "WSL2 single-distribution, admin features, ECI improvements"
+    highlights:
+      - "WSL2 unified single-distribution architecture"
+      - "Mac configuration profiles for sign-in enforcement"
+      - "Multiple organization sign-in enforcement"
+      - "PKG installer for bulk deployment (Mac)"
+      - "ECI Docker socket mount improvements"
+      - "Docker Buildx v0.18.0"
+      - "Kubernetes v1.30.5"
+
+  - version: "4.35.2"
+    date: "2025-01-09"
+    summary: "Mac security component update prevention fix"
+    highlights:
+      - "Mac: Prevents vmnetd and socket update issues"
+
+  - version: "4.35.1"
+    date: "2024-10-30"
+    summary: "Port binding fix"
+    highlights:
+      - "Fixed incorrect binding to port 8888"
+
+  - version: "4.35.0"
+    date: "2024-10-24"
+    summary: "RHEL support GA, Volume Backup GA, Docker VMM Beta"
+    highlights:
+      - "Red Hat Enterprise Linux support is now GA"
+      - "Volume Backup and Share is GA"
+      - "Terminal support using system shells GA"
+      - "Docker VMM Beta for Apple Silicon"
+      - "Docker Engine v27.3.1"
+      - "containerd v1.7.21"
+      - "Fixed proxy settings override issues"
+      - "USB/IP driver support added"
+
+  - version: "4.34.4"
+    date: "2025-01-09"
+    summary: "Mac security component update prevention fix"
+    highlights:
+      - "Mac: Prevents vmnetd and socket update issues"
+
+  - version: "4.34.3"
+    date: "2024-10-09"
+    summary: "Security fixes for CVEs"
+    highlights:
+      - "Fixed CVE-2024-9348 - RCE via image build details"
+      - "Fixed NVIDIA Toolkit CVE-2024-0132 and CVE-2024-0133"
+      - "NVIDIA Container Toolkit v1.16.2"
+
+  - version: "4.34.2"
+    date: "2024-09-12"
+    summary: "Security fixes for extension vulnerabilities"
+    highlights:
+      - "Fixed CVE-2024-8695 - RCE via extension description"
+      - "Fixed CVE-2024-8696 - RCE via extension URLs"
+      - "Fixed Resource Saver mode with docker compose up"
+
+  - version: "4.34.1"
+    date: "2024-09-05"
+    summary: "Windows startup fix"
+    highlights:
+      - "Windows: Fixed startup failure believing another instance running"
+
+  - version: "4.34.0"
+    date: "2024-08-29"
+    summary: "Host networking GA, browser auth, disk reclamation"
+    highlights:
+      - "Host networking support is now GA"
+      - "Browser-based CLI authentication flow"
+      - "Windows automatic disk space reclamation for WSL2"
+      - "MSI installer is now GA"
+      - "containerd image store default for fresh installs"
+      - "Docker Engine v27.2.0"
+      - "Compose Bridge experimental feature"
+
+  - version: "4.33.2"
+    date: "2025-01-09"
+    summary: "Mac security component update prevention fix"
+    highlights:
+      - "Mac: Prevents vmnetd and socket update issues"
+
+  - version: "4.33.1"
+    date: "2024-07-31"
+    summary: "WSL2 kernel module support"
+    highlights:
+      - "Added support for WSL2 2.3.11 and above with loadable kernel modules"
+
+  - version: "4.33.0"
+    date: "2024-07-25"
+    summary: "Docker Debug GA, BuildKit checks, troubleshooting improvements"
+    highlights:
+      - "Docker Debug is now generally available"
+      - "BuildKit evaluates Dockerfile rules for potential issues"
+      - "Resource Allocation settings accessible from Dashboard footer"
+      - "New and improved troubleshooting experience"
+      - "Docker Compose v2.29.1"
+      - "Docker Engine v27.1.1"
+      - "Kubernetes v1.30.2"
+      - "Linux kernel v6.10"
+
+  - version: "4.32.1"
+    date: "2025-01-09"
+    summary: "Mac security component update prevention fix"
+    highlights:
+      - "Mac: Prevents vmnetd and socket update issues"
+
+  - version: "4.32.0"
+    date: "2024-07-04"
+    summary: "Docker Engine 27.0, data movement, volume backups, terminal access"
+    highlights:
+      - "Docker Engine and CLI updated to version 27.0"
+      - "Support for moving data to different drive on macOS and Windows WSL2"
+      - "Schedule backups for volume exports (Beta)"
+      - "Access terminal shell directly from Docker Desktop (Beta)"
+      - "Docker Buildx v0.15.1"
+      - "Docker Compose v2.28.1"
+      - "Settings Management proxy authentication improvements"
+
+  - version: "4.31.1"
+    date: "2024-06-18"
+    summary: "Windows container visibility fix"
+    highlights:
+      - "Fixed containers, images and volumes visibility after upgrade"
+
+  - version: "4.31.0"
+    date: "2024-06-04"
+    summary: "Air-Gapped Containers GA, Compose File Viewer, new sidebar"
+    highlights:
+      - "Air-Gapped Containers is now generally available"
+      - "Docker Compose File Viewer with syntax highlighting (Beta)"
+      - "New Sidebar user experience"
+      - "Docker Engine and CLI v26.1.4"
+      - "Enhanced Container Isolation security improvements"
+      - "Private Extensions Marketplace for Docker Business"
+
+  - version: "4.30.0"
+    date: "2024-05-06"
+    summary: "SOCKS5 proxy support, Kerberos/NTLM authentication, Wasm runtime updates"
+    highlights:
+      - "SOCKS5 proxies support (Business subscription)"
+      - "Kerberos and NTLM proxy authentication on Windows (Business subscription)"
+      - "Docker Compose v2.27.0"
+      - "Docker Engine v26.1.1"
+      - "Updated Wasm runtimes to v0.4.0 and v0.11.1"
+      - "Settings Management onboarding survey control"
+
+  - version: "4.29.0"
+    date: "2024-04-08"
+    summary: "Rosetta enforcement, Docker socket restrictions GA, Moby 26.0, error screen improvements"
+    highlights:
+      - "Enforce Rosetta usage via Settings Management"
+      - "Docker socket mount restrictions with ECI is now GA"
+      - "Docker Engine and CLI updated to Moby 26.0"
+      - "New and improved Docker Desktop error screens"
+      - "Compose supports Synchronized file shares (experimental)"
+      - "Interactive Compose CLI (experimental)"
+      - "Host networking Beta"
+      - "Docker Debug Beta"
+
+  - version: "4.28.0"
+    date: "2024-02-26"
+    summary: "Settings Management file sharing, SOCKS5 proxy support, volume filtering"
+    highlights:
+      - "Settings Management controls file-sharing implementation"
+      - "SOCKS5 HTTP and HTTPS proxy URL support"
+      - "Filter volumes to see which are in use"
+      - "Compose v2.24.6"
+      - "Docker Engine v25.0.3"
+      - "Updated Wasm runtimes including wasmtime v17.0"
+      - "Enhanced Container Isolation Docker socket permissions"
+
+  - version: "4.27.2"
+    date: "2024-02-08"
+    summary: "Compose upgrade, Scout updates, Docker Debug improvements"
+    highlights:
+      - "Compose v2.24.5"
+      - "Docker Scout CLI v1.4.1"
+      - "Docker Debug v0.0.24"
+      - "Fixed diagnostics ID printing issue"
+      - "Fixed Settings Management default values reset"
+      - "Docker Scout VEX and attestation support"
+
+  - version: "4.27.1"
+    date: "2024-02-01"
+    summary: "Critical security updates for Leaky Vessels CVEs"
+    highlights:
+      - "Docker Engine v25.0.2 with CVE fixes"
+      - "Containerd v1.6.28"
+      - "Runc v1.1.12 with CVE-2024-21626 fix"
+      - "Fixed Docker Desktop hang when applying updates"
+
+  - version: "4.27.0"
+    date: "2024-01-25"
+    summary: "Docker init Java support GA, Synchronized File Shares, Docker socket permissions, Containerd GA"
+    highlights:
+      - "Docker init now supports Java and is GA"
+      - "Synchronized File Shares for improved performance"
+      - "Configure Docker socket mount permissions when ECI enabled"
+      - "Containerd Image Store support is now GA"
+      - "Docker debug command (Beta)"
+      - "Private Extensions Marketplace (Beta)"
+      - "Docker Engine v25.0.0"
+
+  - version: "4.26.1"
+    date: "2023-12-14"
+    summary: "Feedback links update, CLI binary compatibility fix"
+    highlights:
+      - "Updated feedback links inside Docker Desktop"
+      - "Windows: Fixed CLI binaries compatibility with older glibc versions"
+
+  - version: "4.26.0"
+    date: "2023-12-04"
+    summary: "Settings Management beta features control, Docker init PHP support, Builds view GA"
+    highlights:
+      - "Administrators can control access to beta and experimental features"
+      - "Four new version update states in footer"
+      - "docker init Beta now supports PHP with Apache + Composer"
+      - "Builds view is now GA for inspecting and optimizing builds"
+      - "Compose v2.23.3"
+      - "Docker Scout CLI v1.2.0"
+      - "Updated Wasm runtimes with wasmtime v14.0"
+
+  - version: "4.25.2"
+    date: "2023-11-21"
+    summary: "Welcome Survey UI fix, WSL 2 dockerd stability"
+    highlights:
+      - "Fixed blank UI after Welcome Survey submission"
+      - "Windows: Fixed Docker Desktop on WSL 2 unexpected dockerd shutdown"
+
+  - version: "4.25.1"
+    date: "2023-11-13"
+    summary: "Swap file corruption fix, vm.max_map_count adjustment"
+    highlights:
+      - "Fixed Docker startup with corrupt swap files"
+      - "Fixed bug when swap is disabled"
+      - "Set sysctl vm.max_map_count to 262144"
+      - "Windows: Fixed Switch to Windows Containers tray menu"
+      - "Windows: Fixed WSL integration with non-sh shells"
+
+  - version: "4.25.0"
+    date: "2023-10-26"
+    summary: "Rosetta GA, WSL update detection, Settings Management Scout control"
+    highlights:
+      - "Rosetta is now GA for macOS 13+ users"
+      - "Docker Desktop detects and updates outdated WSL versions"
+      - "Windows requirement updated to version 19044+"
+      - "Settings Management controls Docker Scout image analysis"
+      - "Compose v2.23.0"
+      - "Kubernetes v1.28.2"
+      - "containerd integration improvements"
+
+  - version: "4.24.2"
+    date: "2023-10-12"
+    summary: "Bugsnag request fix, PyTorch performance improvement"
+    highlights:
+      - "Fixed multiple requests to notify.bugsnag.com"
+      - "Fixed PyTorch performance regression"
+
+  - version: "4.24.1"
+    date: "2023-10-04"
+    summary: "Windows container logs display fix"
+    highlights:
+      - "Windows: Fixed Docker Desktop Dashboard container logs display"
+
+  - version: "4.24.0"
+    date: "2023-09-28"
+    summary: "Notification center GA, Compose Watch GA, Resource Saver GA, Docker Engine management"
+    highlights:
+      - "Notification center available to all users"
+      - "Compose Watch is now available to all users"
+      - "Resource Saver available to all users and enabled by default"
+      - "View and manage Docker Engine state from Dashboard"
+      - "Compose v2.22.0"
+      - "Updated Wasm runtimes including wasmer shims"
+      - "Docker containers use all host CPU cores by default"
+
+  - version: "4.23.0"
+    date: "2023-09-11"
+    summary: "Wasm runtime expansion, docker init ASP.NET, Compose V1 removal"
+    highlights:
+      - "Added support for new Wasm runtimes: wws and lunatic"
+      - "docker init now supports ASP.NET"
+      - "Increased performance of exposed ports on macOS"
+      - "Removed Compose V1 from Docker Desktop"
+      - "Compose v2.21.0"
+      - "Docker Engine v24.0.6"
+      - "VirtioFS default for new installs on macOS 12.5+"
+
+  - version: "4.22.1"
+    date: "2023-08-24"
+    summary: "Docker Desktop startup and Resource Saver improvements"
+    highlights:
+      - "Mitigated Docker Desktop startup and Resource Saver mode issues"
+      - "Windows: Fixed Clean / Purge data troubleshoot option"
+
+  - version: "4.22.0"
+    date: "2023-08-03"
+    summary: "Resource Usage GA, Compose include support, Settings Management Extensions control"
+    highlights:
+      - "Resource Usage moved from experimental to GA"
+      - "Split large Compose projects with include"
+      - "Settings Management controls Docker Extensions"
+      - "Kubernetes and Wasm UI improvements when paused"
+      - "Quick Search enhancements for containers, images, extensions"
+      - "Buildx v0.11.2"
+      - "Compose v2.20.2"
+
+  - version: "4.21.1"
+    date: "2023-07-03"
+    summary: "SSH connection leak fix, macOS configuration health check removal"
+    highlights:
+      - "Fixed connection leak for Docker contexts using SSH"
+      - "Mac: Removed configuration health check for investigation"
+
+  - version: "4.21.0"
+    date: "2023-06-29"
+    summary: "New Wasm runtimes, Rust support, Builds view Beta"
+    highlights:
+      - "Added support for Wasm runtimes: slight, spin, wasmtime"
+      - "Added Rust server support to Docker init"
+      - "Builds view Beta for inspecting builds and managing builders"
+      - "Docker Desktop automatically pauses when not in use"
+      - "VirtioFS default for new installs on macOS 12.5+"
+      - "Buildx v0.11.0"
+      - "Kubernetes v1.27.2"
+
+  - version: "4.20.1"
+    date: "2023-06-05"
+    summary: "containerd image store fixes, WSL version parsing improvements"
+    highlights:
+      - "Fixed docker load with attestations in containerd image store"
+      - "Fixed default image exporter during build"
+      - "Windows: Fixed WSL version parsing in non-western locales"
+
+  - version: "4.20.0"
+    date: "2023-05-30"
+    summary: "Docker Scout CLI improvements, ECS/ACS retirement warning, Enhanced Container Isolation for WSL-2"
+    highlights:
+      - "Docker Scout CLI finds most recently built image automatically"
+      - "Improved Docker Scout CLI compare command"
+      - "Warning about Docker Compose ECS/ACS integrations retirement"
+      - "Enhanced Container Isolation available on WSL-2"
+      - "Buildx v0.10.5"
+      - "Docker Engine v24.0.2"
+      - "Disk space reclamation improvements"
+
+  - version: "4.19.0"
+    date: "2023-04-27"
+    summary: "Moby 23.0, Learning Center walkthroughs, Docker init Node.js/Python, faster networking"
+    highlights:
+      - "Docker Engine and CLI updated to Moby 23.0"
+      - "Learning Center supports in-product walkthroughs"
+      - "Docker init Beta supports Node.js and Python"
+      - "Faster networking between VM and host on macOS"
+      - "Inspect and analyze remote images without pulling"
+      - "Removed docker scan command, use docker scout"
+      - "Docker Engine v23.0.5"
+
+  - version: "4.18.0"
+    date: "2023-04-03"
+    summary: "Docker init Beta, Learning Center, Compose file-watch, security fixes"
+    highlights:
+      - "Initial beta release of docker init"
+      - "New Learning Center tab for getting started"
+      - "Experimental file-watch command for Compose auto-updates"
+      - "Fixed CVE-2023-28841, CVE-2023-28840, CVE-2023-28842"
+      - "Buildx v0.10.4"
+      - "Docker Engine v20.10.24"
+      - "Enhanced Container Isolation bypass fixes"
+
+  - version: "4.17.1"
+    date: "2023-03-20"
+    summary: "Windows BitLocker support, buildx network access, Registry Access Management fixes"
+    highlights:
+      - "Windows: Docker Desktop works with BitLocker enabled"
+      - "Fixed docker buildx container builders network access after 24hrs"
+      - "Fixed Registry Access Management policy updates"
+      - "Improved WSL 2 debug information"
+
+  - version: "4.17.0"
+    date: "2023-02-27"
+    summary: "Docker Scout integration, Extensions Marketplace improvements, Container File Explorer"
+    highlights:
+      - "Docker Desktop ships with Docker Scout"
+      - "docker scan replaced by docker scout"
+      - "Autonomously published extensions in Marketplace"
+      - "Container File Explorer experimental feature"
+      - "Volume search in Global Search"
+      - "Fixed CVE-2023-0628 and CVE-2023-0629"
+      - "Containerd v1.6.18"
+
+  - version: "4.16.3"
+    date: "2023-01-30"
+    summary: "WSL 2 backend file system fixes"
+    highlights:
+      - "Windows: Fixed WSL 2 backend with file system compression/encryption"
+      - "Windows: Fixed missing/outdated WSL installation reporting"
+
+  - version: "4.16.2"
+    date: "2023-01-19"
+    summary: "containerd integration fixes, networking improvements"
+    highlights:
+      - "Fixed docker build and docker tag with containerd integration"
+      - "Fixed networking regression for linux/386 containers on amd64"
+      - "Mac: Fixed Info.plist capitalization for vmnetd"
+      - "Windows: Fixed WSL2 mode startup hanging"
+
+  - version: "4.16.1"
+    date: "2023-01-13"
+    summary: "Container sudo command security fix"
+    highlights:
+      - "Fixed sudo inside containers failing with security error"
+
+  - version: "4.16.0"
+    date: "2023-01-12"
+    summary: "Extensions GA, Quick Search GA, Rosetta Beta, performance improvements"
+    highlights:
+      - "Extensions moved from Beta to GA"
+      - "Quick Search moved from experimental to GA"
+      - "Extensions included in Quick Search"
+      - "Large image analysis up to 4x faster"
+      - "Local images view moved to GA"
+      - "Rosetta for Linux Beta on macOS 13"
+      - "Compose v2.15.1"
+      - "Docker Engine v20.10.22"
+
+  - version: "4.15.0"
+    date: "2022-12-01"
+    summary: "VirtioFS performance improvements, WebAssembly capabilities, UI accessibility updates"
+    highlights:
+      - "VirtioFS file sharing technology for macOS 12.5+"
+      - "Removed privileged helper process requirement on Mac"
+      - "Added WebAssembly capabilities with containerd integration"
+      - "Available disk space display in Dashboard footer"
+      - "Extensions Marketplace installs display and sorting"
+      - "Dev Environments improvements"
+      - "Compose v2.13.0"
+      - "containerd v1.6.10"
+
+  - version: "4.14.1"
+    date: "2022-11-17"
+    summary: "Registry Access Management DNS fix, image analysis button fix"
+    highlights:
+      - "Fixed container DNS lookups with Registry Access Management"
+      - "Mac: Fixed Analyze Image button on Images tab"
+      - "Mac: Fixed symlink creation when /usr/local/lib missing"
+
+  - version: "4.14.0"
+    date: "2022-11-10"
+    summary: "Virtualization framework default, Enhanced Container Isolation in General Settings"
+    highlights:
+      - "Virtualization framework default hypervisor for macOS 12.5+"
+      - "Migrate previous installs to Virtualization framework"
+      - "Enhanced Container Isolation available in General Settings"
+      - "Docker Engine v20.10.21"
+      - "Docker Compose v2.12.2"
+      - "Internal network subnet expanded to /24"
+
+  - version: "4.13.1"
+    date: "2022-10-31"
+    summary: "docker pull interrupt fix, DHCP lease time increase, Qemu revert"
+    highlights:
+      - "Fixed segfault when interrupting docker pull with Control+C"
+      - "Increased default DHCP lease time"
+      - "Reverted Qemu to 6.2.0 for compatibility"
+      - "Mac: Added /var/run/docker.sock symlink by default"
+      - "Windows: PowerShell disabled machine support"
+
+  - version: "4.13.0"
+    date: "2022-10-19"
+    summary: "Settings Management and Enhanced Container Isolation for Business, Dev Environments CLI"
+    highlights:
+      - "Settings Management and Enhanced Container Isolation for Docker Business"
+      - "New Dev Environments CLI docker dev"
+      - "Docker Desktop installation to any drive with --installation-dir"
+      - "Docker Scan v0.21.0"
+      - "Updated Docker Engine and CLI to v20.10.20"
+      - "Kubernetes v1.25.2"
+      - "Linux kernel 5.15.49"
+
+  - version: "4.12.0"
+    date: "2022-09-01"
+    summary: "containerd experimental support, Extensions Marketplace search, container terminal"
+    highlights:
+      - "containerd for pulling and storing images (experimental)"
+      - "Docker Desktop runs untagged images"
+      - "Extensions Marketplace search capabilities"
+      - "Zoom support with keyboard shortcuts"
+      - "Integrated terminal for containers"
+      - "Docker Compose v2.10.2"
+      - "Kubernetes v1.25.0"
+      - "Security improvements with contextIsolation and sandbox"
+
+  - version: "4.11.1"
+    date: "2022-08-05"
+    summary: "VM bind mount regression fix, WSL2 private registry login fix"
+    highlights:
+      - "Fixed VM system locations bind mount regression"
+      - "Windows: Fixed docker login to private registries from WSL2"
+
+  - version: "4.11.0"
+    date: "2022-07-28"
+    summary: "VMware ESXi and Azure VM support, Extensions Marketplace improvements, custom themes"
+    highlights:
+      - "Docker Desktop fully supported in VMware ESXi and Azure VMs"
+      - "Added vcluster and PGAdmin4 extensions to Marketplace"
+      - "Extensions sorting capability"
+      - "Custom theme settings (dark/light mode independent)"
+      - "Windows: --no-windows-containers installer flag"
+      - "Mac: --user installer flag"
+      - "Docker Compose v2.7.0"
+
+  - version: "4.10.1"
+    date: "2022-07-05"
+    summary: "WSL Compose app UI fixes, Mac install path initialization"
+    highlights:
+      - "Windows: Fixed UI actions with Compose apps from WSL"
+      - "Mac: Fixed install command path initialization failure"
+
+  - version: "4.10.0"
+    date: "2022-06-30"
+    summary: "Environment variables before run, log improvements, Extensions Marketplace additions"
+    highlights:
+      - "Add environment variables before running images"
+      - "Enhanced container logs with regex search and clearing"
+      - "Container table improvements with ports and image separation"
+      - "Added Ddosify and Lacework extensions"
+      - "Removed Homepage for redesign"
+      - "Docker Engine v20.10.17"
+      - "Kubernetes v1.24.1"
+
+  - version: "4.9.1"
+    date: "2022-06-16"
+    summary: "Dashboard blank screen fix"
+    highlights:
+      - "Fixed blank dashboard screen issue"
+
+  - version: "4.9.0"
+    date: "2022-06-02"
+    summary: "Homepage guides expansion, Dashboard footer, containers table redesign"
+    highlights:
+      - "Added guides for Elasticsearch, MariaDB, Memcached, MySQL, RabbitMQ, Ubuntu"
+      - "Dashboard footer with update status and Docker Engine statistics"
+      - "Redesigned containers table with copy ID, pause buttons, column resizing"
+      - "Bulk deletion for containers table"
+      - "Compose v2.6.0"
+      - "Docker Engine v20.10.16"
+
+  - version: "4.8.2"
+    date: "2022-05-18"
+    summary: "Proxy settings fix, Extensions CPU usage fix, password redaction"
+    highlights:
+      - "Fixed manual proxy settings causing image pull problems"
+      - "Fixed high CPU usage when extensions disabled"
+      - "Docker Desktop redacts HTTP proxy passwords in logs"
+      - "Compose v2.5.1"
+
+  - version: "4.8.1"
+    date: "2022-05-09"
+    summary: "Docker Desktop for Linux release, Extensions Beta, Homepage, Compose V2 GA"
+    highlights:
+      - "Released Docker Desktop for Linux"
+      - "Beta release of Docker Extensions and Extensions SDK"
+      - "Created Docker Homepage with popular images"
+      - "Compose V2 is now GA"
+      - "Fixed Kubernetes cluster deletion during updates"
+
+  - version: "4.8.0"
+    date: "2022-05-06"
+    summary: "Docker Desktop for Linux, Extensions Beta, Homepage, Compose V2 GA"
+    highlights:
+      - "Released Docker Desktop for Linux"
+      - "Beta release of Docker Extensions and Extensions SDK"
+      - "Created Docker Homepage with popular images"
+      - "Compose V2 is now GA"
+      - "System proxy reading support"
+      - "Volume tab improvements with size display"
+      - "Compose v2.5.0"
+      - "Kubernetes 1.24"
+
+  - version: "4.7.1"
+    date: "2022-04-19"
+    summary: "Quick Start Guide crash fix, Windows container mode fix"
+    highlights:
+      - "Fixed crash on Quick Start Guide final screen"
+      - "Windows: Fixed update symlink error"
+      - "Windows: Fixed Windows container mode prevention"
+
+  - version: "4.7.0"
+    date: "2022-04-07"
+    summary: "Remote installation support, Docker SBOM CLI, cri-dockerd for Kubernetes"
+    highlights:
+      - "IT Administrators can install Docker Desktop remotely via command line"
+      - "Docker Software Bill of Materials (SBOM) CLI plugin"
+      - "Use cri-dockerd for new Kubernetes clusters instead of dockershim"
+      - "Docker Engine v20.10.14"
+      - "Fixed CVE-2022-24769"
+      - "Volume management multi-select cleanup"
+      - "Improved login feedback"
+
+  - version: "4.6.1"
+    date: "2022-03-22"
+    summary: "vpnkit logging fix, diagnostics upload fix, self-diagnose improvements"
+    highlights:
+      - "Prevented vpnkit-forwarder log filling"
+      - "Fixed diagnostics upload without HTTP proxy"
+      - "Removed false positive vm not running error"
+      - "Buildx 0.8.1"
+
+  - version: "4.6.0"
+    date: "2022-03-14"
+    summary: "Volume Management multi-select, VirtioFS experimental for Mac"
+    highlights:
+      - "Volume Management multi-select checkboxes for cleanup"
+      - "Mac: VirtioFS experimental file sharing technology"
+      - "Docker Engine v20.10.13"
+      - "Fixed CVE-2022-0847 Dirty Pipe"
+      - "Windows: Fixed CVE-2022-26659"
+      - "Compose v2.3.3"
+      - "Buildx 0.8.0"
+
+  - version: "4.5.1"
+    date: "2022-02-15"
+    summary: "Windows backend default fix, Dashboard crash fix"
+    highlights:
+      - "Windows: Fixed new installations defaulting to Hyper-V instead of WSL 2"
+      - "Windows: Fixed Dashboard crash making systray menu disappear"
+
+  - version: "4.5.0"
+    date: "2022-02-10"
+    summary: "New Docker menu design, version output display"
+    highlights:
+      - "New Docker menu for consistent user experience across OS"
+      - "docker version output displays Docker Desktop version"
+      - "Fixed CVE-2021-44719 on Mac"
+      - "Fixed CVE-2022-23774 on Windows"
+      - "Amazon ECR Credential Helper v0.6.0"
+      - "Fixed sign-in prompting after quit/restart"
+
+  - version: "4.4.4"
+    date: "2022-01-24"
+    summary: "WSL 2 login fix"
+    highlights:
+      - "Windows: Fixed logging in from WSL 2"
+
+  - version: "4.4.3"
+    date: "2022-01-14"
+    summary: "Dashboard shortcut capture prevention"
+    highlights:
+      - "Windows: Disabled Dashboard shortcuts when minimized or unfocused"
+
+  - version: "4.4.2"
+    date: "2022-01-13"
+    summary: "Auth0 and Single Sign-on, browser-based authentication"
+    highlights:
+      - "Single Sign-on for Docker Business subscription users"
+      - "Browser-based sign-in with auto-filling from password managers"
+      - "Docker Engine v20.10.12"
+      - "Fixed CVE-2021-45449"
+      - "Compose v2.2.3"
+      - "Kubernetes 1.22.5"
+
+  - version: "4.3.2"
+    date: "2021-12-21"
+    summary: "CVE-2021-45449 security fix, Log4j 2 detection"
+    highlights:
+      - "Fixed CVE-2021-45449 sensitive information logging"
+      - "docker scan v0.14.0 with Log4j 2 CVE detection"
+
+  - version: "4.3.1"
+    date: "2021-12-11"
+    summary: "Log4j 2 CVE detection support"
+    highlights:
+      - "docker scan v0.11.0 with Log4j 2 CVE-2021-44228 detection"
+
+  - version: "4.3.0"
+    date: "2021-12-02"
+    summary: "cgroupv2 adoption, Apple silicon Rosetta 2 optional"
+    highlights:
+      - "Docker Desktop uses cgroupv2"
+      - "Mac: Apple silicon no longer requires Rosetta 2 (except 3 CLI tools)"
+      - "Windows: Fixed startup with regex characters in home directory"
+      - "Docker Engine v20.10.11"
+      - "Buildx 0.7.1"
+      - "Kubernetes 1.22.4"
+
+  - version: "4.2.0"
+    date: "2021-11-09"
+    summary: "Pause/Resume feature, Software Updates control, window management"
+    highlights:
+      - "Pause/Resume Docker Desktop sessions to save CPU resources"
+      - "Software Updates control for all subscription types"
+      - "Window size and position persistence"
+      - "Docker Engine v20.10.10"
+      - "Compose v2.1.1"
+      - "Self-diagnose network overlap checking"
+
+  - version: "4.1.1"
+    date: "2021-10-12"
+    summary: "Docker.qcow2 upgrade fix, update notification improvements"
+    highlights:
+      - "Mac: Fixed Docker.qcow2 file ignored on upgrade issue"
+      - "Fixed update notification overlay sync issues"
+      - "Fixed menu entry for newly downloaded updates"
+      - "Windows: Fixed WSL 2 integration regression"
+
+  - version: "4.1.0"
+    date: "2021-09-30"
+    summary: "Software Updates management, Compose V2 option, Volume Management for all"
+    highlights:
+      - "Software Updates section for managing Docker Desktop updates"
+      - "Compose V2 specification in General settings"
+      - "Volume management available for Docker Personal users"
+      - "Compose V2"
+      - "Buildx 0.6.3"
+      - "Kubernetes 1.21.5"
+
+  - version: "4.0.1"
+    date: "2021-09-13"
+    summary: "Compose V2 RC3, copy-paste fix, Hyper-V engine fix"
+    highlights:
+      - "Compose V2 RC3 with panic and race condition fixes"
+      - "Fixed copy-paste unavailable in Dashboard"
+      - "Windows: Fixed Hyper-V engine startup issues"
+
+  - version: "4.0.0"
+    date: "2021-08-31"
+    summary: "Docker subscription updates, Compose V2 RC2, Kubernetes 1.21.4"
+    highlights:
+      - "Updated Docker Subscription Service Agreement"
+      - "Docker Desktop remains free for small businesses and personal use"
+      - "Paid subscription required for large enterprises"
+      - "Compose V2 RC2"
+      - "Kubernetes 1.21.4"
+      - "Mac: Fixed SSH availability for builds from git URL"
+      - "Windows: Fixed CLI tools availability in WSL 2"
diff --git a/data/engine-cli/docker_context_use.yaml b/data/engine-cli/docker_context_use.yaml
deleted file mode 100644
index 5ab7f8175096..000000000000
--- a/data/engine-cli/docker_context_use.yaml
+++ /dev/null
@@ -1,27 +0,0 @@
-command: docker context use
-short: Set the current docker context
-long: |-
-    Set the default context to use, when `DOCKER_HOST`, `DOCKER_CONTEXT` environment
-    variables and `--host`, `--context` global options aren't set.
-    To disable usage of contexts, you can use the special `default` context.
-usage: docker context use CONTEXT
-pname: docker context
-plink: docker_context.yaml
-inherited_options:
-    - option: help
-      value_type: bool
-      default_value: "false"
-      description: Print usage
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/engine-cli/docker_image_import.yaml b/data/engine-cli/docker_image_import.yaml
deleted file mode 100644
index d96ef3c3e1c9..000000000000
--- a/data/engine-cli/docker_image_import.yaml
+++ /dev/null
@@ -1,112 +0,0 @@
-command: docker image import
-aliases: docker image import, docker import
-short: Import the contents from a tarball to create a filesystem image
-long: |-
-    You can specify a `URL` or `-` (dash) to take data directly from `STDIN`. The
-    `URL` can point to an archive (.tar, .tar.gz, .tgz, .bzip, .tar.xz, or .txz)
-    containing a filesystem or to an individual file on the Docker host.  If you
-    specify an archive, Docker untars it in the container relative to the `/`
-    (root). If you specify an individual file, you must specify the full path within
-    the host. To import from a remote location, specify a `URI` that begins with the
-    `http://` or `https://` protocol.
-
-    The `--change` option applies `Dockerfile` instructions to the image that is
-    created. Supported `Dockerfile` instructions:
-    `CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`
-usage: docker image import [OPTIONS] file|URL|- [REPOSITORY[:TAG]]
-pname: docker image
-plink: docker_image.yaml
-options:
-    - option: change
-      shorthand: c
-      value_type: list
-      description: Apply Dockerfile instruction to the created image
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: message
-      shorthand: m
-      value_type: string
-      description: Set commit message for imported image
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: platform
-      value_type: string
-      description: Set platform if server is multi-platform capable
-      deprecated: false
-      hidden: false
-      min_api_version: "1.32"
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: help
-      value_type: bool
-      default_value: "false"
-      description: Print usage
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-examples: |-
-    ### Import from a remote location
-
-    This creates a new untagged image.
-
-    ```console
-    $ docker import https://example.com/exampleimage.tgz
-    ```
-
-    ### Import from a local file
-
-    Import to docker via pipe and `STDIN`.
-
-    ```console
-    $ cat exampleimage.tgz | docker import - exampleimagelocal:new
-    ```
-
-    Import with a commit message.
-
-    ```console
-    $ cat exampleimage.tgz | docker import --message "New image imported from tarball" - exampleimagelocal:new
-    ```
-
-    Import to docker from a local archive.
-
-    ```console
-    $ docker import /path/to/exampleimage.tgz
-    ```
-
-    ### Import from a local directory
-
-    ```console
-    $ sudo tar -c . | docker import - exampleimagedir
-    ```
-
-    ### Import from a local directory with new configurations
-
-    ```console
-    $ sudo tar -c . | docker import --change "ENV DEBUG=true" - exampleimagedir
-    ```
-
-    Note the `sudo` in this example – you must preserve
-    the ownership of the files (especially root ownership) during the
-    archiving with tar. If you are not root (or the sudo command) when you
-    tar, then the ownerships might not get preserved.
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/engine-cli/docker_image_inspect.yaml b/data/engine-cli/docker_image_inspect.yaml
deleted file mode 100644
index 25f22ef9205d..000000000000
--- a/data/engine-cli/docker_image_inspect.yaml
+++ /dev/null
@@ -1,39 +0,0 @@
-command: docker image inspect
-short: Display detailed information on one or more images
-long: Display detailed information on one or more images
-usage: docker image inspect [OPTIONS] IMAGE [IMAGE...]
-pname: docker image
-plink: docker_image.yaml
-options:
-    - option: format
-      shorthand: f
-      value_type: string
-      description: |-
-        Format output using a custom template:
-        'json':             Print in JSON format
-        'TEMPLATE':         Print output using the given Go template.
-        Refer to https://docs.docker.com/go/formatting/ for more information about formatting output with templates
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: help
-      value_type: bool
-      default_value: "false"
-      description: Print usage
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/engine-cli/docker_image_rm.yaml b/data/engine-cli/docker_image_rm.yaml
deleted file mode 100644
index b178a831f13a..000000000000
--- a/data/engine-cli/docker_image_rm.yaml
+++ /dev/null
@@ -1,131 +0,0 @@
-command: docker image rm
-aliases: docker image rm, docker image remove, docker rmi
-short: Remove one or more images
-long: |-
-    Removes (and un-tags) one or more images from the host node. If an image has
-    multiple tags, using this command with the tag as a parameter only removes the
-    tag. If the tag is the only one for the image, both the image and the tag are
-    removed.
-
-    This does not remove images from a registry. You cannot remove an image of a
-    running container unless you use the `-f` option. To see all images on a host
-    use the [`docker image ls`](/reference/cli/docker/image/ls/) command.
-usage: docker image rm [OPTIONS] IMAGE [IMAGE...]
-pname: docker image
-plink: docker_image.yaml
-options:
-    - option: force
-      shorthand: f
-      value_type: bool
-      default_value: "false"
-      description: Force removal of the image
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-    - option: no-prune
-      value_type: bool
-      default_value: "false"
-      description: Do not delete untagged parents
-      deprecated: false
-      hidden: false
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-inherited_options:
-    - option: help
-      value_type: bool
-      default_value: "false"
-      description: Print usage
-      deprecated: false
-      hidden: true
-      experimental: false
-      experimentalcli: false
-      kubernetes: false
-      swarm: false
-examples: |-
-    You can remove an image using its short or long ID, its tag, or its digest. If
-    an image has one or more tags referencing it, you must remove all of them before
-    the image is removed. Digest references are removed automatically when an image
-    is removed by tag.
-
-    ```console
-    $ docker images
-
-    REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
-    test1                     latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
-    test                      latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
-    test2                     latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
-
-    $ docker rmi fd484f19954f
-
-    Error: Conflict, cannot delete image fd484f19954f because it is tagged in multiple repositories, use -f to force
-    2013/12/11 05:47:16 Error: failed to remove one or more images
-
-    $ docker rmi test1:latest
-
-    Untagged: test1:latest
-
-    $ docker rmi test2:latest
-
-    Untagged: test2:latest
-
-
-    $ docker images
-
-    REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
-    test                      latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
-
-    $ docker rmi test:latest
-
-    Untagged: test:latest
-    Deleted: fd484f19954f4920da7ff372b5067f5b7ddb2fd3830cecd17b96ea9e286ba5b8
-    ```
-
-    If you use the `-f` flag and specify the image's short or long ID, then this
-    command untags and removes all images that match the specified ID.
-
-    ```console
-    $ docker images
-
-    REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
-    test1                     latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
-    test                      latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
-    test2                     latest              fd484f19954f        23 seconds ago      7 B (virtual 4.964 MB)
-
-    $ docker rmi -f fd484f19954f
-
-    Untagged: test1:latest
-    Untagged: test:latest
-    Untagged: test2:latest
-    Deleted: fd484f19954f4920da7ff372b5067f5b7ddb2fd3830cecd17b96ea9e286ba5b8
-    ```
-
-    An image pulled by digest has no tag associated with it:
-
-    ```console
-    $ docker images --digests
-
-    REPOSITORY                     TAG       DIGEST                                                                    IMAGE ID        CREATED         SIZE
-    localhost:5000/test/busybox    <none>    sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf   4986bf8c1536    9 weeks ago     2.43 MB
-    ```
-
-    To remove an image using its digest:
-
-    ```console
-    $ docker rmi localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
-    Untagged: localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
-    Deleted: 4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125
-    Deleted: ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2
-    Deleted: df7546f9f060a2268024c8a230d8639878585defcc1bc6f79d2728a13957871b
-    ```
-deprecated: false
-hidden: false
-experimental: false
-experimentalcli: false
-kubernetes: false
-swarm: false
-
diff --git a/data/redirects.yml b/data/redirects.yml
index aedd6f60ea0b..456923e33322 100644
--- a/data/redirects.yml
+++ b/data/redirects.yml
@@ -8,10 +8,12 @@
 # provide a short, permanent link to refer to a topic in the documentation.
 # For example, the docker CLI can output https://docs.docker.com/go/some-topic
 # in its help output, which can be redirected to elsewhere in the documentation.
-"/security/for-developers/access-tokens/":
+"/learn/":
+  - /learn
+"/security/access-tokens/":
   - /go/access-tokens/
-"/desktop/mac/apple-silicon/":
-  - /go/apple-silicon/
+"/agentic-platform/":
+  - /go/dap/
 "/reference/api/engine/#deprecated-api-versions":
   - /engine/api/v1.18/
   - /engine/api/v1.19/
@@ -19,6 +21,26 @@
   - /engine/api/v1.21/
   - /engine/api/v1.22/
   - /engine/api/v1.23/
+  - /engine/api/v1.24/
+  - /engine/api/v1.25/
+  - /engine/api/v1.26/
+  - /engine/api/v1.27/
+  - /engine/api/v1.28/
+  - /engine/api/v1.29/
+  - /engine/api/v1.30/
+  - /engine/api/v1.31/
+  - /engine/api/v1.32/
+  - /engine/api/v1.33/
+  - /engine/api/v1.34/
+  - /engine/api/v1.35/
+  - /engine/api/v1.36/
+  - /engine/api/v1.37/
+  - /engine/api/v1.38/
+  - /engine/api/v1.39/
+  - /engine/api/v1.40/
+  - /engine/api/v1.41/
+  - /engine/api/v1.42/
+  - /engine/api/v1.43/
   - /engine/reference/api/docker_remote_api_v1.18/
   - /engine/reference/api/docker_remote_api_v1.19/
   - /engine/reference/api/docker_remote_api_v1.20/
@@ -31,9 +53,6 @@
   - /reference/api/docker_remote_api_v1.21/
   - /reference/api/docker_remote_api_v1.22/
   - /reference/api/docker_remote_api_v1.23/
-# redirect for old location of dockerd reference
-"/reference/cli/dockerd/":
-  - /engine/reference/commandline/dockerd/
 # redirect updated location of the "running containers" page
 "/engine/containers/run/":
   - "/engine/reference/run/"
@@ -64,12 +83,18 @@
   - /go/buildx/
 "/reference/cli/docker/compose/build/":
   - /go/compose-native-build/
+  - /compose/reference/build/
+  - /engine/reference/commandline/compose_build/
 "/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user":
   # Details about how to give "non-root" users access to a privileged Docker
   # Daemon/ This redirect is currently in the installation script at "get.docker.com"
   - /go/daemon-access/
 "/engine/deprecated/#deprecated-engine-features-1":
   - /go/deprecated/
+"https://www.docker.com/blog/retiring-docker-content-trust/":
+  # Details about the deprecation of Docker Content Trust. This URL can be used
+  # for in-product links to the deprecation, and is used by the Docker CLI.
+  - /go/dct-deprecation/
 "/engine/reference/commandline/cli/#experimental-features":
   - /go/experimental/
 "/reference/cli/docker/login/#credential-stores":
@@ -83,13 +108,6 @@
   - /go/formatting/
 "/?utm_source=docker&utm_medium=inproductad&utm_campaign=20-11nurturecli_docs":
   - /go/guides/
-"/desktop/get-started/#credentials-management-for-linux-users":
-  - /go/linux-credentials/
-"/desktop/use-desktop/pause/":
-  - /go/mac-desktop-pause/
-  - /go/win-desktop-pause/
-"/desktop/settings-and-maintenance/settings/#file-sharing":
-  - /go/mac-file-sharing/
 "/engine/security/rootless/":
   # Instructions on running docker in rootless mode. This redirect is currently
   # used in the installation script at "get.docker.com"
@@ -98,9 +116,7 @@
   - /go/storage-driver/
 "/docker-hub/vulnerability-scanning/":
   - /go/tip-scanning/
-"/desktop/features/wsl/":
-  # Link used by Docker Desktop to refer users on how to activate WSL 2
-  - /go/wsl2/
+
 "/reference/api/hub/latest/":
   - /docker-hub/api/latest/
 "/reference/api/hub/dvp/":
@@ -227,6 +243,12 @@
   - /go/builds-import/
 "/build/checks/#experimental-checks":
   - "/go/build-checks-experimental/"
+"/build/":
+  - /go/build/
+"/build/building/multi-stage/":
+  - /go/build-multi-stage/
+"/build/concepts/dockerfile/":
+  - /go/build-dockerfile/
 
 # Build links (external)
 "https://app.docker.com/build/?utm_campaign=onboard-30-customer-zero&utm_medium=in-product-ad&utm_source=desktop_v4":
@@ -236,9 +258,21 @@
 "https://www.docker.com/products/build-cloud/?utm_campaign=2024-02-02-dbc_cli&utm_medium=in-product-ad&utm_source=desktop_v4":
   - /go/docker-build-cloud/
 
-# Run Cloud links
+# Run Cloud links & Docker Cloud & Docker Offload
 "/":
   - /go/run-cloud-eap/
+"/offload/":
+  # Onboarding - VDI beta
+  - /go/docker-cloud/
+"/offload/about/":
+  # Onboarding - enable GPU
+  - /go/docker-cloud-gpu/
+"/offload/about/#session-management-and-idle-state":
+  - /go/offload-idle-inactivity/
+  - /go/offload-idle-long-session/
+"/ai/compose/models-and-compose/":
+  # Onboarding - enable GPU - compose for agents
+  - /go/compose-for-agents/
 
 # CLI backlinks
 "/engine/cli/filter/":
@@ -263,17 +297,11 @@
 # Docker Debug
 "/reference/cli/docker/debug/":
   - /go/debug-cli/
-"/desktop/use-desktop/container/#debug":
+  - /engine/reference/commandline/debug/
+"/desktop/use-desktop/container/#execdebug":
   - /go/debug-gui/
 
-# Docker Desktop - volumes cloud backup
-"/desktop/use-desktop/volumes/#export-a-volume":
-  - /go/volume-export/
-  - /go/volume-export-aws/
-  - /go/volume-export-azure/
-  - /go/volume-export-gcs/
-
-# Docker Admin Console - Insights
+# Docker Admin Console/Home - Insights
 "/admin/organization/insights/":
   - /go/insights/
 "/admin/organization/insights/#docker-desktop-users/":
@@ -289,14 +317,1070 @@
 "/admin/organization/insights/#extensions":
   - /go/insights-extensions/
 
+"/enterprise/security/hardened-desktop/settings-management/":
+  - /go/settings-management/
+
 # Billing - cancellation
 "/subscription/desktop-license/":
   - /go/desktop-license/
 "/docker-hub/usage/pulls/":
   - /go/hub-pull-limits/
 
-# Desktop DMR
 
-"/model-runner/":
+# Links in Desktop
+
+# Docker Sandboxes
+"/ai/sandboxes/governance/access-controls/mcp/":
+  - /go/mcp-policy/
+"/ai/sandboxes/mcp-gateway/":
+  - /go/sbx-mcp-gateway/
+
+# Desktop MCP Toolkit
+"/ai/mcp-catalog-and-toolkit/toolkit/":
+  - /go/mcp-toolkit/
+"/ai/mcp-catalog-and-toolkit/":
+  - /go/mcp-catalog-and-toolkit/
+"/ai/mcp-catalog-and-toolkit/catalog/":
+  - /go/mcp-catalog-and-toolkit-catalog/
+"/ai/mcp-catalog-and-toolkit/mcp-gateway/":
+  - /go/mcp-gateway/
+"/ai/mcp-catalog-and-toolkit/toolkit/#install-an-mcp-server":
+  - /go/mcp-toolkit-install-mcp-server/
+"/ai/mcp-catalog-and-toolkit/toolkit/#install-an-mcp-client":
+  - /go/mcp-toolkit-install-mcp-client/
+"/ai/mcp-catalog-and-toolkit/toolkit/#example-use-claude-desktop-as-a-client":
+  - /go/mcp-toolkit-use-client-examples/
+"/ai/mcp-catalog-and-toolkit/get-started/#verify-connections":
+  - /go/mcp-client-verify/
+"/ai/mcp-catalog-and-toolkit/catalog/#custom-catalogs":
+  - /go/mcp-custom-catalogs/
+
+ # Desktop DMR
+"/ai/model-runner/":
   - /go/model-runner/
-  
\ No newline at end of file
+
+# Docker Desktop - volumes cloud backup
+"/desktop/use-desktop/volumes/#export-a-volume":
+  - /go/volume-export/
+  - /go/volume-export-aws/
+  - /go/volume-export-azure/
+  - /go/volume-export-gcs/
+
+# Link used by Docker Desktop to refer users on how to activate WSL 2
+"/desktop/features/wsl/":
+  - /go/wsl2/
+  - /go/windows-linux-vmm/
+"/desktop/get-started/#credentials-management-for-linux-users":
+  - /go/linux-credentials/
+"/desktop/use-desktop/pause/":
+  - /go/mac-desktop-pause/
+  - /go/win-desktop-pause/
+  - /go/desktop-pause/
+"/desktop/settings-and-maintenance/settings/#file-sharing":
+  - /go/mac-file-sharing/
+  - /go/file-sharing/
+"/desktop/use-desktop/container/":
+  - /go/container/
+"/desktop/use-desktop/images/":
+  - /go/images/
+"/desktop/use-desktop/volumes/":
+  - /go/volumes/
+"/extensions/":
+  - /go/extensions/
+"/extensions/extensions-sdk/":
+  - /go/extensions-sdk/
+"/extensions/extensions-sdk/extensions/":
+  - /go/publish-extensions/
+"/engine/cli/completion/":
+  - /go/completion/
+"/desktop/features/vmm/":
+  - /go/vmm/
+  - /go/mac-vmm/
+  - /go/windows-vmm/
+"/security/for-admins/hardened-desktop/enhanced-container-isolation/":
+  - /go/eci/
+"/desktop/features/synchronized-file-sharing/":
+  - /go/synchronized-file-sharing/
+"/reference/cli/dockerd/":
+  - /go/daemon-config/
+  - /engine/reference/commandline/dockerd/
+"/ai/gordon/":
+  - /go/gordon/
+"/desktop/features/wasm/":
+  - /go/wasm/
+"/compose/bridge/":
+  - /go/compose-bridge/
+"/desktop/settings-and-maintenance/settings/":
+  - /go/notifications/
+  - /go/settings/
+"/desktop/setup/install/mac-install/":
+  - /go/apple-silicon/
+"/desktop/setup/install/mac-permission-requirements/#installing-symlinks":
+  - /go/symlinks/
+"/desktop/setup/install/mac-permission-requirements/":
+  - /go/permissions/
+"/desktop/setup/install/windows-permission-requirements/":
+  - /go/windows-permissions/
+"/desktop/setup/install/mac-permission-requirements/#binding-privileged-ports":
+  - /go/port-mapping/
+"/desktop/release-notes/":
+  # Link to the Docker Desktop release notes. Used for in-product linkage.
+  - /go/desktop-release-notes/
+"/desktop/features/networking/":
+  - /go/networks/
+"/desktop/troubleshoot-and-support/troubleshoot/":
+  - /go/troubleshoot/
+"/desktop/troubleshoot-and-support/troubleshoot/#diagnose":
+  - /go/diagnose/
+"/desktop/troubleshoot-and-support/feedback/":
+  - /go/feedback/
+"/desktop/":
+  - /go/desktop/
+"/desktop/features/containerd/":
+  - /go/containerd/
+"/desktop/use-desktop/logs/":
+  - /go/desktop-logs/
+"/desktop/setup/install/linux/#general-system-requirements":
+  - /go/desktop-linux-requirements/
+"/desktop/setup/install/mac-install/#system-requirements":
+  - /go/desktop-mac-requirements/
+"/desktop/setup/install/windows-install/#system-requirements":
+  - /go/desktop-windows-requirements/
+"/desktop/setup/install/windows-install/#installation-modes":
+  - /go/desktop-windows-install-modes/
+"/support/#diagnostic-data-and-privacy":
+  - /go/diagnostic-data/
+
+
+
+"/compose/":
+  - /go/compose/
+"/reference/compose-file/":
+  - /go/compose-file/
+"/reference/compose-file/services/":
+  - /go/compose-file-services/
+"/reference/compose-file/services/#build":
+  - /go/compose-file-services-build/
+"/reference/compose-file/services/#depends_on":
+  - /go/compose-file-services-depends_on/
+"/reference/compose-file/services/#develop":
+  - /go/compose-file-services-develop/
+"/reference/compose-file/services/#env_file":
+  - /go/compose-file-services-env-file/
+"/reference/compose-file/services/#environment":
+  - /go/compose-file-services-environment/
+"/reference/compose-file/services/#healthcheck":
+  - /go/compose-file-services-healthcheck/
+"/reference/compose-file/services/#networks":
+  - /go/compose-file-services-networks/
+"/reference/compose-file/services/#ports":
+  - /go/compose-file-services-ports/
+"/reference/compose-file/services/#secrets":
+  - /go/compose-file-services-secrets/
+"/reference/compose-file/services/#volumes":
+  - /go/compose-file-services-volumes/
+"/reference/compose-file/networks/":
+  - /go/compose-file-networks/
+"/reference/compose-file/volumes/":
+  - /go/compose-file-volumes/
+"/reference/compose-file/configs/":
+  - /go/compose-file-configs/
+"/reference/compose-file/secrets/":
+  - /go/compose-file-secrets/
+"/reference/compose-file/interpolation/":
+  - /go/compose-file-interpolation/
+"/reference/compose-file/include/":
+  - /go/compose-file-include/
+"/reference/compose-file/profiles/":
+  - /go/compose-file-profiles/
+"/reference/compose-file/deploy/":
+  - /go/compose-file-deploy/
+"/compose/how-tos/file-watch/":
+  - /go/compose-watch/
+"/compose/how-tos/file-watch/#prerequisites":
+  - /go/compose-watch-prerequisites/
+
+"/engine/network/drivers/host/":
+  - /go/host-network-driver/
+"/engine/storage/bind-mounts/":
+  - /go/bind-mounts/
+"/engine/storage/volumes/":
+  - /go/engine-volumes/
+
+"/guides/nodejs/":
+  - /go/nodejs-guide/
+"/guides/python/":
+  - /go/python-guide/
+"/guides/golang/":
+  - /go/golang-guide/
+"/guides/java/":
+  - /go/java-guide/
+"/guides/dotnet/":
+  - /go/dotnet-guide/
+"/guides/rust/":
+  - /go/rust-guide/
+
+# Docker Hardened Images (DHI)
+"/dhi/how-to/customize/":
+  - /go/dhi-customization/
+"/dhi/how-to/scan/#scan-a-dhi-using-grype":
+  - /go/dhi-grype/
+
+"/dhi/how-to/customize/#create-an-oci-artifact-image":
+  - /go/dhi-customization-artifacts/
+
+"https://www.docker.com/static/support-service-level-agreement-for-dhi.pdf":
+  # External redirect to DHI Support SLA PDF. Internal redirect prevents GA4
+  # from adding _gl cross-domain tracking parameters that break the PDF link.
+  - /go/dhi-sla/
+
+# Copilot extension (deprecated)
+"https://github.com/marketplace/docker-for-github-copilot":
+  - /copilot/
+  - /copilot/install/
+  - /copilot/usage/
+  - /copilot/examples/
+
+# Compose release notes
+"https://github.com/docker/compose/releases":
+  - /compose/releases/release-notes/
+  - /compose/releases/prior-releases/
+  - /release-notes/docker-compose/
+
+# Build release notes
+"https://github.com/docker/buildx/releases":
+  - /build/release-notes/
+"https://github.com/moby/buildkit/releases/":
+  - /build/buildkit/dockerfile-release-notes/
+
+# Scout CLI release notes
+"https://github.com/docker/scout-cli/releases":
+  - /scout/release-notes/cli/
+
+# CLI reference redirects (migrated from front matter aliases)
+"/reference/cli/docker/":
+  - /edge/engine/reference/commandline/
+  - /engine/reference/commandline/
+  - /engine/reference/commandline/cli/
+  - /engine/reference/commandline/docker/
+"/reference/cli/docker/builder/":
+  - /engine/reference/commandline/builder/
+"/reference/cli/docker/builder/prune/":
+  - /engine/reference/commandline/builder_prune/
+"/reference/cli/docker/buildx/":
+  - /engine/reference/commandline/buildx/
+"/reference/cli/docker/buildx/bake/":
+  - /engine/reference/commandline/buildx_bake/
+"/reference/cli/docker/buildx/build/":
+  - /engine/reference/commandline/builder_build/
+  - /engine/reference/commandline/buildx_build/
+  - /reference/cli/docker/build/
+  - /reference/cli/docker/builder/build/
+"/reference/cli/docker/image/build/":
+  - /edge/engine/reference/commandline/image_build/
+  - /engine/reference/commandline/build/
+  - /engine/reference/commandline/image_build/
+  - /reference/cli/docker/build-legacy/
+"/reference/cli/docker/buildx/create/":
+  - /engine/reference/commandline/buildx_create/
+"/reference/cli/docker/buildx/dap/":
+  - /engine/reference/commandline/buildx_dap/
+"/reference/cli/docker/buildx/dap/attach/":
+  - /engine/reference/commandline/buildx_dap_attach/
+"/reference/cli/docker/buildx/dap/build/":
+  - /engine/reference/commandline/buildx_dap_build/
+"/reference/cli/docker/buildx/debug/":
+  - /engine/reference/commandline/buildx_debug-shell/
+  - /engine/reference/commandline/buildx_debug/
+"/reference/cli/docker/buildx/debug/build/":
+  - /engine/reference/commandline/buildx_debug_build/
+"/reference/cli/docker/buildx/du/":
+  - /engine/reference/commandline/buildx_du/
+"/reference/cli/docker/buildx/history/":
+  - /engine/reference/commandline/buildx_history/
+"/reference/cli/docker/buildx/history/export/":
+  - /engine/reference/commandline/buildx_history_export/
+"/reference/cli/docker/buildx/history/import/":
+  - /engine/reference/commandline/buildx_history_import/
+"/reference/cli/docker/buildx/history/inspect/":
+  - /engine/reference/commandline/buildx_history_inspect/
+"/reference/cli/docker/buildx/history/inspect/attachment/":
+  - /engine/reference/commandline/buildx_history_inspect_attachment/
+"/reference/cli/docker/buildx/history/logs/":
+  - /engine/reference/commandline/buildx_history_logs/
+"/reference/cli/docker/buildx/history/ls/":
+  - /engine/reference/commandline/buildx_history_ls/
+"/reference/cli/docker/buildx/history/open/":
+  - /engine/reference/commandline/buildx_history_open/
+"/reference/cli/docker/buildx/history/rm/":
+  - /engine/reference/commandline/buildx_history_rm/
+"/reference/cli/docker/buildx/history/trace/":
+  - /engine/reference/commandline/buildx_history_trace/
+"/reference/cli/docker/buildx/imagetools/":
+  - /engine/reference/commandline/buildx_imagetools/
+"/reference/cli/docker/buildx/imagetools/create/":
+  - /engine/reference/commandline/buildx_imagetools_create/
+"/reference/cli/docker/buildx/imagetools/inspect/":
+  - /engine/reference/commandline/buildx_imagetools_inspect/
+"/reference/cli/docker/buildx/inspect/":
+  - /engine/reference/commandline/buildx_inspect/
+"/reference/cli/docker/buildx/ls/":
+  - /engine/reference/commandline/buildx_ls/
+"/reference/cli/docker/buildx/prune/":
+  - /engine/reference/commandline/buildx_prune/
+"/reference/cli/docker/buildx/rm/":
+  - /engine/reference/commandline/buildx_rm/
+"/reference/cli/docker/buildx/stop/":
+  - /engine/reference/commandline/buildx_stop/
+"/reference/cli/docker/buildx/use/":
+  - /engine/reference/commandline/buildx_use/
+"/reference/cli/docker/buildx/version/":
+  - /engine/reference/commandline/buildx_version/
+"/reference/cli/docker/checkpoint/":
+  - /edge/engine/reference/commandline/checkpoint/
+  - /engine/reference/commandline/checkpoint/
+"/reference/cli/docker/checkpoint/create/":
+  - /edge/engine/reference/commandline/checkpoint_create/
+  - /engine/reference/commandline/checkpoint_create/
+"/reference/cli/docker/checkpoint/ls/":
+  - /edge/engine/reference/commandline/checkpoint_ls/
+  - /engine/reference/commandline/checkpoint_ls/
+"/reference/cli/docker/checkpoint/rm/":
+  - /edge/engine/reference/commandline/checkpoint_rm/
+  - /engine/reference/commandline/checkpoint_rm/
+"/reference/cli/docker/compose/":
+  - /compose/reference/
+  - /compose/reference/docker-compose/
+  - /compose/reference/help/
+  - /engine/reference/commandline/compose/
+"/reference/cli/docker/compose/alpha/":
+  - /engine/reference/commandline/compose_alpha/
+"/reference/cli/docker/compose/alpha/dry-run/":
+  - /engine/reference/commandline/compose_alpha_dry-run/
+"/reference/cli/docker/compose/alpha/scale/":
+  - /engine/reference/commandline/compose_alpha_scale/
+"/reference/cli/docker/compose/alpha/viz/":
+  - /engine/reference/commandline/compose_alpha_viz/
+"/reference/cli/docker/compose/config/":
+  - /compose/config/
+  - /compose/reference/config/
+  - /engine/reference/commandline/compose_config/
+  - /engine/reference/commandline/compose_convert/
+"/reference/cli/docker/compose/cp/":
+  - /engine/reference/commandline/compose_cp/
+"/reference/cli/docker/compose/create/":
+  - /compose/reference/create/
+  - /engine/reference/commandline/compose_create/
+"/reference/cli/docker/compose/down/":
+  - /compose/reference/down/
+  - /engine/reference/commandline/compose_down/
+"/reference/cli/docker/compose/events/":
+  - /compose/reference/events/
+  - /engine/reference/commandline/compose_events/
+"/reference/cli/docker/compose/exec/":
+  - /compose/reference/exec/
+  - /engine/reference/commandline/compose_exec/
+"/reference/cli/docker/compose/images/":
+  - /compose/reference/images/
+  - /engine/reference/commandline/compose_images/
+"/reference/cli/docker/compose/kill/":
+  - /compose/reference/kill/
+  - /engine/reference/commandline/compose_kill/
+"/reference/cli/docker/compose/logs/":
+  - /compose/reference/logs/
+  - /engine/reference/commandline/compose_logs/
+"/reference/cli/docker/compose/ls/":
+  - /engine/reference/commandline/compose_ls/
+"/reference/cli/docker/compose/pause/":
+  - /compose/reference/pause/
+  - /engine/reference/commandline/compose_pause/
+"/reference/cli/docker/compose/port/":
+  - /compose/reference/port/
+  - /engine/reference/commandline/compose_port/
+"/reference/cli/docker/compose/ps/":
+  - /compose/reference/ps/
+  - /engine/reference/commandline/compose_ps/
+"/reference/cli/docker/compose/publish/":
+  - /engine/reference/commandline/compose_alpha_publish/
+  - /reference/cli/docker/compose/alpha/publish/
+"/reference/cli/docker/compose/pull/":
+  - /compose/reference/pull/
+  - /engine/reference/commandline/compose_pull/
+"/reference/cli/docker/compose/push/":
+  - /compose/reference/push/
+  - /engine/reference/commandline/compose_push/
+"/reference/cli/docker/compose/restart/":
+  - /compose/reference/restart/
+  - /engine/reference/commandline/compose_restart/
+"/reference/cli/docker/compose/rm/":
+  - /compose/reference/rm/
+  - /engine/reference/commandline/compose_rm/
+"/reference/cli/docker/compose/run/":
+  - /compose/reference/run/
+  - /engine/reference/commandline/compose_run/
+"/reference/cli/docker/compose/start/":
+  - /compose/reference/start/
+  - /engine/reference/commandline/compose_start/
+"/reference/cli/docker/compose/stop/":
+  - /compose/reference/stop/
+  - /engine/reference/commandline/compose_stop/
+"/reference/cli/docker/compose/top/":
+  - /compose/reference/top/
+  - /engine/reference/commandline/compose_top/
+"/reference/cli/docker/compose/unpause/":
+  - /compose/reference/unpause/
+  - /engine/reference/commandline/compose_unpause/
+"/reference/cli/docker/compose/up/":
+  - /compose/reference/scale/
+  - /compose/reference/up/
+  - /engine/reference/commandline/compose_up/
+"/reference/cli/docker/compose/version/":
+  - /engine/reference/commandline/compose_version/
+"/reference/cli/docker/compose/wait/":
+  - /engine/reference/commandline/compose_wait/
+"/reference/cli/docker/compose/watch/":
+  - /engine/reference/commandline/compose_watch/
+"/reference/cli/docker/config/":
+  - /edge/engine/reference/commandline/config/
+  - /engine/reference/commandline/config/
+"/reference/cli/docker/config/create/":
+  - /edge/engine/reference/commandline/config_create/
+  - /engine/reference/commandline/config_create/
+"/reference/cli/docker/config/inspect/":
+  - /edge/engine/reference/commandline/config_inspect/
+  - /engine/reference/commandline/config_inspect/
+"/reference/cli/docker/config/ls/":
+  - /edge/engine/reference/commandline/config_ls/
+  - /engine/reference/commandline/config_ls/
+"/reference/cli/docker/config/rm/":
+  - /edge/engine/reference/commandline/config_rm/
+  - /engine/reference/commandline/config_rm/
+"/reference/cli/docker/container/":
+  - /edge/engine/reference/commandline/container/
+  - /engine/reference/commandline/container/
+"/reference/cli/docker/container/attach/":
+  - /edge/engine/reference/commandline/container_attach/
+  - /engine/reference/commandline/attach/
+  - /engine/reference/commandline/container_attach/
+"/reference/cli/docker/container/commit/":
+  - /edge/engine/reference/commandline/container_commit/
+  - /engine/reference/commandline/commit/
+  - /engine/reference/commandline/container_commit/
+"/reference/cli/docker/container/cp/":
+  - /edge/engine/reference/commandline/container_cp/
+  - /engine/reference/commandline/container_cp/
+  - /engine/reference/commandline/cp/
+"/reference/cli/docker/container/create/":
+  - /edge/engine/reference/commandline/container_create/
+  - /engine/reference/commandline/container_create/
+  - /engine/reference/commandline/create/
+"/reference/cli/docker/container/diff/":
+  - /edge/engine/reference/commandline/container_diff/
+  - /engine/reference/commandline/container_diff/
+  - /engine/reference/commandline/diff/
+"/reference/cli/docker/container/exec/":
+  - /edge/engine/reference/commandline/container_exec/
+  - /engine/reference/commandline/container_exec/
+  - /engine/reference/commandline/exec/
+  - /reference/cli/docker/exec/
+"/reference/cli/docker/container/export/":
+  - /edge/engine/reference/commandline/container_export/
+  - /engine/reference/commandline/container_export/
+  - /engine/reference/commandline/export/
+"/reference/cli/docker/container/inspect/":
+  - /edge/engine/reference/commandline/container_inspect/
+  - /engine/reference/commandline/container_inspect/
+"/reference/cli/docker/container/kill/":
+  - /edge/engine/reference/commandline/container_kill/
+  - /engine/reference/commandline/container_kill/
+  - /engine/reference/commandline/kill/
+"/reference/cli/docker/container/logs/":
+  - /edge/engine/reference/commandline/container_logs/
+  - /engine/reference/commandline/container_logs/
+  - /engine/reference/commandline/logs/
+  - /reference/cli/docker/logs/
+"/reference/cli/docker/container/ls/":
+  - /edge/engine/reference/commandline/container_ls/
+  - /engine/reference/commandline/container_ls/
+  - /engine/reference/commandline/ps/
+  - /reference/cli/docker/container/ps/
+  - /reference/cli/docker/ps/
+"/reference/cli/docker/container/pause/":
+  - /edge/engine/reference/commandline/container_pause/
+  - /engine/reference/commandline/container_pause/
+  - /engine/reference/commandline/pause/
+"/reference/cli/docker/container/port/":
+  - /edge/engine/reference/commandline/container_port/
+  - /engine/reference/commandline/container_port/
+  - /engine/reference/commandline/port/
+"/reference/cli/docker/container/prune/":
+  - /edge/engine/reference/commandline/container_prune/
+  - /engine/reference/commandline/container_prune/
+"/reference/cli/docker/container/rename/":
+  - /edge/engine/reference/commandline/container_rename/
+  - /engine/reference/commandline/container_rename/
+  - /engine/reference/commandline/rename/
+"/reference/cli/docker/container/restart/":
+  - /edge/engine/reference/commandline/container_restart/
+  - /engine/reference/commandline/container_restart/
+  - /engine/reference/commandline/restart/
+"/reference/cli/docker/container/rm/":
+  - /edge/engine/reference/commandline/container_rm/
+  - /engine/reference/commandline/container_rm/
+  - /engine/reference/commandline/rm/
+"/reference/cli/docker/container/run/":
+  - /engine/reference/commandline/container_run/
+  - /engine/reference/commandline/run/
+  - /reference/cli/docker/run/
+  - /go/commandline-run/
+"/reference/cli/docker/container/start/":
+  - /edge/engine/reference/commandline/container_start/
+  - /engine/reference/commandline/container_start/
+  - /engine/reference/commandline/start/
+"/reference/cli/docker/container/stats/":
+  - /edge/engine/reference/commandline/container_stats/
+  - /engine/reference/commandline/container_stats/
+  - /engine/reference/commandline/stats/
+"/reference/cli/docker/container/stop/":
+  - /edge/engine/reference/commandline/container_stop/
+  - /engine/reference/commandline/container_stop/
+  - /engine/reference/commandline/stop/
+"/reference/cli/docker/container/top/":
+  - /edge/engine/reference/commandline/container_top/
+  - /engine/reference/commandline/container_top/
+  - /engine/reference/commandline/top/
+"/reference/cli/docker/container/unpause/":
+  - /edge/engine/reference/commandline/container_unpause/
+  - /engine/reference/commandline/container_unpause/
+  - /engine/reference/commandline/unpause/
+"/reference/cli/docker/container/update/":
+  - /edge/engine/reference/commandline/container_update/
+  - /engine/reference/commandline/container_update/
+  - /engine/reference/commandline/update/
+"/reference/cli/docker/container/wait/":
+  - /edge/engine/reference/commandline/container_wait/
+  - /engine/reference/commandline/container_wait/
+  - /engine/reference/commandline/wait/
+"/reference/cli/docker/context/":
+  - /engine/reference/commandline/context/
+"/reference/cli/docker/context/create/":
+  - /engine/reference/commandline/context_create/
+"/reference/cli/docker/context/export/":
+  - /engine/reference/commandline/context_export/
+"/reference/cli/docker/context/import/":
+  - /engine/reference/commandline/context_import/
+"/reference/cli/docker/context/inspect/":
+  - /engine/reference/commandline/context_inspect/
+"/reference/cli/docker/context/ls/":
+  - /engine/reference/commandline/context_ls/
+"/reference/cli/docker/context/rm/":
+  - /engine/reference/commandline/context_rm/
+"/reference/cli/docker/context/show/":
+  - /engine/reference/commandline/context_show/
+"/reference/cli/docker/context/update/":
+  - /engine/reference/commandline/context_update/
+"/reference/cli/docker/context/use/":
+  - /engine/reference/commandline/context_use/
+"/reference/cli/docker/image/":
+  - /edge/engine/reference/commandline/image/
+  - /engine/reference/commandline/image/
+"/reference/cli/docker/image/history/":
+  - /edge/engine/reference/commandline/image_history/
+  - /engine/reference/commandline/history/
+  - /engine/reference/commandline/image_history/
+"/reference/cli/docker/image/import/":
+  - /edge/engine/reference/commandline/image_import/
+  - /engine/reference/commandline/image_import/
+  - /engine/reference/commandline/import/
+"/reference/cli/docker/image/inspect/":
+  - /edge/engine/reference/commandline/image_inspect/
+  - /engine/reference/commandline/image_inspect/
+"/reference/cli/docker/image/load/":
+  - /edge/engine/reference/commandline/image_load/
+  - /engine/reference/commandline/image_load/
+  - /engine/reference/commandline/load/
+"/reference/cli/docker/image/ls/":
+  - /edge/engine/reference/commandline/image_ls/
+  - /engine/reference/commandline/image_ls/
+  - /engine/reference/commandline/images/
+  - /reference/cli/docker/images/
+"/reference/cli/docker/image/prune/":
+  - /edge/engine/reference/commandline/image_prune/
+  - /engine/reference/commandline/image_prune/
+"/reference/cli/docker/image/pull/":
+  - /edge/engine/reference/commandline/image_pull/
+  - /engine/reference/commandline/image_pull/
+  - /engine/reference/commandline/pull/
+  - /reference/cli/docker/pull/
+"/reference/cli/docker/image/push/":
+  - /edge/engine/reference/commandline/image_push/
+  - /engine/reference/commandline/image_push/
+  - /engine/reference/commandline/push/
+  - /reference/cli/docker/push/
+"/reference/cli/docker/image/rm/":
+  - /edge/engine/reference/commandline/image_rm/
+  - /engine/reference/commandline/image_rm/
+  - /engine/reference/commandline/rmi/
+  - /reference/cli/docker/rmi/
+"/reference/cli/docker/image/save/":
+  - /edge/engine/reference/commandline/image_save/
+  - /engine/reference/commandline/image_save/
+  - /engine/reference/commandline/save/
+  - /reference/cli/docker/save/
+"/reference/cli/docker/image/tag/":
+  - /edge/engine/reference/commandline/image_tag/
+  - /engine/reference/commandline/image_tag/
+  - /engine/reference/commandline/tag/
+"/reference/cli/docker/init/":
+  - /engine/reference/commandline/init/
+"/reference/cli/docker/inspect/":
+  - /edge/engine/reference/commandline/inspect/
+  - /engine/reference/commandline/inspect/
+"/reference/cli/docker/login/":
+  - /edge/engine/reference/commandline/login/
+  - /engine/reference/commandline/login/
+"/reference/cli/docker/logout/":
+  - /edge/engine/reference/commandline/logout/
+  - /engine/reference/commandline/logout/
+"/reference/cli/docker/manifest/":
+  - /edge/engine/reference/commandline/manifest/
+  - /engine/reference/commandline/manifest/
+"/reference/cli/docker/manifest/annotate/":
+  - /edge/engine/reference/commandline/manifest_annotate/
+  - /engine/reference/commandline/manifest_annotate/
+"/reference/cli/docker/manifest/create/":
+  - /edge/engine/reference/commandline/manifest_create/
+  - /engine/reference/commandline/manifest_create/
+"/reference/cli/docker/manifest/inspect/":
+  - /edge/engine/reference/commandline/manifest_inspect/
+  - /engine/reference/commandline/manifest_inspect/
+"/reference/cli/docker/manifest/push/":
+  - /edge/engine/reference/commandline/manifest_push/
+  - /engine/reference/commandline/manifest_push/
+"/reference/cli/docker/manifest/rm/":
+  - /engine/reference/commandline/manifest_rm/
+"/reference/cli/docker/mcp/catalog/add/":
+  - /reference/cli/docker/mcp/catalog/catalog_add/
+"/reference/cli/docker/mcp/catalog/bootstrap/":
+  - /reference/cli/docker/mcp/catalog/catalog_bootstrap/
+"/reference/cli/docker/mcp/catalog/create/":
+  - /reference/cli/docker/mcp/catalog/catalog_create/
+"/reference/cli/docker/mcp/catalog/export/":
+  - /reference/cli/docker/mcp/catalog/catalog_export/
+"/reference/cli/docker/mcp/catalog/fork/":
+  - /reference/cli/docker/mcp/catalog/catalog_fork/
+"/reference/cli/docker/mcp/catalog/import/":
+  - /reference/cli/docker/mcp/catalog/catalog_import/
+"/reference/cli/docker/mcp/catalog/init/":
+  - /reference/cli/docker/mcp/catalog/catalog_init/
+"/reference/cli/docker/mcp/catalog/ls/":
+  - /reference/cli/docker/mcp/catalog/catalog_ls/
+"/reference/cli/docker/mcp/catalog/reset/":
+  - /reference/cli/docker/mcp/catalog/catalog_reset/
+"/reference/cli/docker/mcp/catalog/rm/":
+  - /reference/cli/docker/mcp/catalog/catalog_rm/
+"/reference/cli/docker/mcp/catalog/show/":
+  - /reference/cli/docker/mcp/catalog/catalog_show/
+"/reference/cli/docker/mcp/catalog/update/":
+  - /reference/cli/docker/mcp/catalog/catalog_update/
+"/reference/cli/docker/mcp/client/connect/":
+  - /reference/cli/docker/mcp/client/client_connect/
+"/reference/cli/docker/mcp/client/disconnect/":
+  - /reference/cli/docker/mcp/client/client_disconnect/
+"/reference/cli/docker/mcp/client/ls/":
+  - /reference/cli/docker/mcp/client/client_ls/
+"/reference/cli/docker/mcp/client/manual-instructions/":
+  - /reference/cli/docker/mcp/client/client_manual-instructions/
+"/reference/cli/docker/mcp/config/dump/":
+  - /reference/cli/docker/mcp/config/config_dump/
+"/reference/cli/docker/mcp/config/read/":
+  - /reference/cli/docker/mcp/config/config_read/
+"/reference/cli/docker/mcp/config/reset/":
+  - /reference/cli/docker/mcp/config/config_reset/
+"/reference/cli/docker/mcp/config/restore/":
+  - /reference/cli/docker/mcp/config/config_restore/
+"/reference/cli/docker/mcp/config/write/":
+  - /reference/cli/docker/mcp/config/config_write/
+"/reference/cli/docker/mcp/feature/disable/":
+  - /reference/cli/docker/mcp/feature/feature_disable/
+"/reference/cli/docker/mcp/feature/enable/":
+  - /reference/cli/docker/mcp/feature/feature_enable/
+"/reference/cli/docker/mcp/feature/ls/":
+  - /reference/cli/docker/mcp/feature/feature_ls/
+  - /reference/cli/docker/mcp/feature/list/
+"/reference/cli/docker/mcp/gateway/run/":
+  - /reference/cli/docker/mcp/gateway/gateway_run/
+"/reference/cli/docker/mcp/oauth/authorize/":
+  - /reference/cli/docker/mcp/oauth/oauth_authorize/
+"/reference/cli/docker/mcp/oauth/ls/":
+  - /reference/cli/docker/mcp/oauth/oauth_ls/
+"/reference/cli/docker/mcp/oauth/revoke/":
+  - /reference/cli/docker/mcp/oauth/oauth_revoke/
+"/reference/cli/docker/mcp/policy/dump/":
+  - /reference/cli/docker/mcp/policy/policy_dump/
+"/reference/cli/docker/mcp/policy/set/":
+  - /reference/cli/docker/mcp/policy/policy_set/
+"/reference/cli/docker/mcp/secret/":
+  - /reference/cli/docker/mcp/secrets/
+"/reference/cli/docker/mcp/secret/export/":
+  - /reference/cli/docker/mcp/secrets/secret_export/
+"/reference/cli/docker/mcp/secret/ls/":
+  - /reference/cli/docker/mcp/secrets/secret_ls/
+"/reference/cli/docker/mcp/secret/rm/":
+  - /reference/cli/docker/mcp/secrets/secret_rm/
+"/reference/cli/docker/mcp/secret/set/":
+  - /reference/cli/docker/mcp/secrets/secret_set/
+"/reference/cli/docker/mcp/server/disable/":
+  - /reference/cli/docker/mcp/server/server_disable/
+"/reference/cli/docker/mcp/server/enable/":
+  - /reference/cli/docker/mcp/server/server_enable/
+"/reference/cli/docker/mcp/server/inspect/":
+  - /reference/cli/docker/mcp/server/server_inspect/
+"/reference/cli/docker/mcp/server/list/":
+  - /reference/cli/docker/mcp/server/server_ls/
+"/reference/cli/docker/mcp/server/reset/":
+  - /reference/cli/docker/mcp/server/server_reset/
+"/reference/cli/docker/mcp/tools/call/":
+  - /reference/cli/docker/mcp/tools/tools_call/
+"/reference/cli/docker/mcp/tools/count/":
+  - /reference/cli/docker/mcp/tools/tools_count/
+"/reference/cli/docker/mcp/tools/disable/":
+  - /reference/cli/docker/mcp/tools/tools_disable/
+"/reference/cli/docker/mcp/tools/enable/":
+  - /reference/cli/docker/mcp/tools/tools_enable/
+"/reference/cli/docker/mcp/tools/inspect/":
+  - /reference/cli/docker/mcp/tools/tools_inspect/
+"/reference/cli/docker/mcp/tools/ls/":
+  - /reference/cli/docker/mcp/tools/list/
+  - /reference/cli/docker/mcp/tools/tools_ls/
+"/reference/cli/docker/model/inspect/":
+  - /engine/reference/commandline/model_inspect/
+"/reference/cli/docker/model/install-runner/":
+  - /engine/reference/commandline/model_install-runner/
+"/reference/cli/docker/model/list/":
+  - /engine/reference/commandline/model_list/
+"/reference/cli/docker/model/logs/":
+  - /engine/reference/commandline/model_logs/
+"/reference/cli/docker/model/package/":
+  - /engine/reference/commandline/model_package/
+"/reference/cli/docker/model/pull/":
+  - /engine/reference/commandline/model_pull/
+"/reference/cli/docker/model/push/":
+  - /engine/reference/commandline/model_push/
+"/reference/cli/docker/model/rm/":
+  - /engine/reference/commandline/model_rm/
+"/reference/cli/docker/model/run/":
+  - /engine/reference/commandline/model_run/
+"/reference/cli/docker/model/status/":
+  - /engine/reference/commandline/model_status/
+"/reference/cli/docker/model/tag/":
+  - /engine/reference/commandline/model_tag/
+"/reference/cli/docker/model/uninstall-runner/":
+  - /engine/reference/commandline/model_uninstall-runner/
+"/reference/cli/docker/model/version/":
+  - /engine/reference/commandline/model_version/
+"/reference/cli/docker/network/":
+  - /edge/engine/reference/commandline/network/
+  - /engine/reference/commandline/network/
+"/reference/cli/docker/network/connect/":
+  - /edge/engine/reference/commandline/network_connect/
+  - /engine/reference/commandline/network_connect/
+"/reference/cli/docker/network/create/":
+  - /edge/engine/reference/commandline/network_create/
+  - /engine/reference/commandline/network_create/
+"/reference/cli/docker/network/disconnect/":
+  - /edge/engine/reference/commandline/network_disconnect/
+  - /engine/reference/commandline/network_disconnect/
+"/reference/cli/docker/network/inspect/":
+  - /edge/engine/reference/commandline/network_inspect/
+  - /engine/reference/commandline/network_inspect/
+"/reference/cli/docker/network/ls/":
+  - /edge/engine/reference/commandline/network_ls/
+  - /engine/reference/commandline/network_ls/
+"/reference/cli/docker/network/prune/":
+  - /edge/engine/reference/commandline/network_prune/
+  - /engine/reference/commandline/network_prune/
+"/reference/cli/docker/network/rm/":
+  - /edge/engine/reference/commandline/network_rm/
+  - /engine/reference/commandline/network_rm/
+"/reference/cli/docker/node/":
+  - /edge/engine/reference/commandline/node/
+  - /engine/reference/commandline/node/
+"/reference/cli/docker/node/demote/":
+  - /edge/engine/reference/commandline/node_demote/
+  - /engine/reference/commandline/node_demote/
+"/reference/cli/docker/node/inspect/":
+  - /edge/engine/reference/commandline/node_inspect/
+  - /engine/reference/commandline/node_inspect/
+"/reference/cli/docker/node/ls/":
+  - /edge/engine/reference/commandline/node_ls/
+  - /engine/reference/commandline/node_ls/
+"/reference/cli/docker/node/promote/":
+  - /edge/engine/reference/commandline/node_promote/
+  - /engine/reference/commandline/node_promote/
+"/reference/cli/docker/node/ps/":
+  - /edge/engine/reference/commandline/node_ps/
+  - /engine/reference/commandline/node_ps/
+"/reference/cli/docker/node/rm/":
+  - /edge/engine/reference/commandline/node_rm/
+  - /engine/reference/commandline/node_rm/
+"/reference/cli/docker/node/update/":
+  - /edge/engine/reference/commandline/node_update/
+  - /engine/reference/commandline/node_update/
+"/reference/cli/docker/plugin/":
+  - /edge/engine/reference/commandline/plugin/
+  - /engine/reference/commandline/plugin/
+"/reference/cli/docker/plugin/create/":
+  - /edge/engine/reference/commandline/plugin_create/
+  - /engine/reference/commandline/plugin_create/
+"/reference/cli/docker/plugin/disable/":
+  - /edge/engine/reference/commandline/plugin_disable/
+  - /engine/reference/commandline/plugin_disable/
+"/reference/cli/docker/plugin/enable/":
+  - /edge/engine/reference/commandline/plugin_enable/
+  - /engine/reference/commandline/plugin_enable/
+"/reference/cli/docker/plugin/inspect/":
+  - /edge/engine/reference/commandline/plugin_inspect/
+  - /engine/reference/commandline/plugin_inspect/
+"/reference/cli/docker/plugin/install/":
+  - /edge/engine/reference/commandline/plugin_install/
+  - /engine/reference/commandline/plugin_install/
+"/reference/cli/docker/plugin/ls/":
+  - /edge/engine/reference/commandline/plugin_ls/
+  - /engine/reference/commandline/plugin_ls/
+"/reference/cli/docker/plugin/push/":
+  - /edge/engine/reference/commandline/plugin_push/
+  - /engine/reference/commandline/plugin_push/
+"/reference/cli/docker/plugin/rm/":
+  - /edge/engine/reference/commandline/plugin_rm/
+  - /engine/reference/commandline/plugin_rm/
+"/reference/cli/docker/plugin/set/":
+  - /edge/engine/reference/commandline/plugin_set/
+  - /engine/reference/commandline/plugin_set/
+"/reference/cli/docker/plugin/upgrade/":
+  - /edge/engine/reference/commandline/plugin_upgrade/
+  - /engine/reference/commandline/plugin_upgrade/
+"/reference/cli/docker/scout/":
+  - /engine/reference/commandline/scout/
+"/reference/cli/docker/scout/attestation/":
+  - /engine/reference/commandline/scout_attestation/
+"/reference/cli/docker/scout/attestation/add/":
+  - /engine/reference/commandline/scout_attestation_add/
+"/reference/cli/docker/scout/cache/":
+  - /engine/reference/commandline/scout_cache/
+"/reference/cli/docker/scout/cache/df/":
+  - /engine/reference/commandline/scout_cache_df/
+"/reference/cli/docker/scout/cache/prune/":
+  - /engine/reference/commandline/scout_cache_prune/
+"/reference/cli/docker/scout/compare/":
+  - /engine/reference/commandline/scout_compare/
+"/reference/cli/docker/scout/config/":
+  - /engine/reference/commandline/scout_config/
+"/reference/cli/docker/scout/cves/":
+  - /engine/reference/commandline/scout_cves/
+"/reference/cli/docker/scout/enroll/":
+  - /engine/reference/commandline/scout_enroll/
+"/reference/cli/docker/scout/environment/":
+  - /engine/reference/commandline/scout_environment/
+"/reference/cli/docker/scout/integration/":
+  - /engine/reference/commandline/scout_integration/
+"/reference/cli/docker/scout/integration/configure/":
+  - /engine/reference/commandline/scout_integration_configure/
+"/reference/cli/docker/scout/integration/delete/":
+  - /engine/reference/commandline/scout_integration_delete/
+"/reference/cli/docker/scout/integration/list/":
+  - /engine/reference/commandline/scout_integration_list/
+"/reference/cli/docker/scout/policy/":
+  - /engine/reference/commandline/scout_policy/
+"/reference/cli/docker/scout/quickview/":
+  - /engine/reference/commandline/scout_quickview/
+"/reference/cli/docker/scout/recommendations/":
+  - /engine/reference/commandline/scout_recommendations/
+"/reference/cli/docker/scout/repo/":
+  - /engine/reference/commandline/scout_repo/
+"/reference/cli/docker/scout/repo/disable/":
+  - /engine/reference/commandline/scout_repo_disable/
+"/reference/cli/docker/scout/repo/enable/":
+  - /engine/reference/commandline/scout_repo_enable/
+"/reference/cli/docker/scout/repo/list/":
+  - /engine/reference/commandline/scout_repo_list/
+"/reference/cli/docker/scout/sbom/":
+  - /engine/reference/commandline/scout_sbom/
+"/reference/cli/docker/scout/stream/":
+  - /engine/reference/commandline/scout_stream/
+"/reference/cli/docker/scout/version/":
+  - /engine/reference/commandline/scout_version/
+"/reference/cli/docker/scout/watch/":
+  - /engine/reference/commandline/scout_watch/
+"/reference/cli/docker/search/":
+  - /edge/engine/reference/commandline/search/
+  - /engine/reference/commandline/search/
+"/reference/cli/docker/secret/":
+  - /edge/engine/reference/commandline/secret/
+  - /engine/reference/commandline/secret/
+"/reference/cli/docker/secret/create/":
+  - /edge/engine/reference/commandline/secret_create/
+  - /engine/reference/commandline/secret_create/
+"/reference/cli/docker/secret/inspect/":
+  - /edge/engine/reference/commandline/secret_inspect/
+  - /engine/reference/commandline/secret_inspect/
+"/reference/cli/docker/secret/ls/":
+  - /edge/engine/reference/commandline/secret_ls/
+  - /engine/reference/commandline/secret_ls/
+"/reference/cli/docker/secret/rm/":
+  - /edge/engine/reference/commandline/secret_rm/
+  - /engine/reference/commandline/secret_rm/
+"/reference/cli/docker/service/":
+  - /edge/engine/reference/commandline/service/
+  - /engine/reference/commandline/service/
+"/reference/cli/docker/service/create/":
+  - /edge/engine/reference/commandline/service_create/
+  - /engine/reference/commandline/service_create/
+"/reference/cli/docker/service/inspect/":
+  - /edge/engine/reference/commandline/service_inspect/
+  - /engine/reference/commandline/service_inspect/
+"/reference/cli/docker/service/logs/":
+  - /edge/engine/reference/commandline/service_logs/
+  - /engine/reference/commandline/service_logs/
+"/reference/cli/docker/service/ls/":
+  - /edge/engine/reference/commandline/service_ls/
+  - /engine/reference/commandline/service_ls/
+"/reference/cli/docker/service/ps/":
+  - /edge/engine/reference/commandline/service_ps/
+  - /engine/reference/commandline/service_ps/
+"/reference/cli/docker/service/rm/":
+  - /edge/engine/reference/commandline/service_rm/
+  - /engine/reference/commandline/service_rm/
+"/reference/cli/docker/service/rollback/":
+  - /edge/engine/reference/commandline/service_rollback/
+  - /engine/reference/commandline/service_rollback/
+"/reference/cli/docker/service/scale/":
+  - /edge/engine/reference/commandline/service_scale/
+  - /engine/reference/commandline/service_scale/
+"/reference/cli/docker/service/update/":
+  - /edge/engine/reference/commandline/service_update/
+  - /engine/reference/commandline/service_update/
+"/reference/cli/docker/stack/":
+  - /edge/engine/reference/commandline/stack/
+  - /engine/reference/commandline/stack/
+"/reference/cli/docker/stack/config/":
+  - /engine/reference/commandline/stack_config/
+"/reference/cli/docker/stack/deploy/":
+  - /compose/bundles/
+  - /edge/engine/reference/commandline/deploy/
+  - /edge/engine/reference/commandline/stack_deploy/
+  - /engine/reference/commandline/deploy/
+  - /engine/reference/commandline/stack_deploy/
+"/reference/cli/docker/stack/ls/":
+  - /edge/engine/reference/commandline/stack_ls/
+  - /engine/reference/commandline/stack_ls/
+"/reference/cli/docker/stack/ps/":
+  - /edge/engine/reference/commandline/stack_ps/
+  - /edge/engine/reference/commandline/stack_tasks/
+  - /engine/reference/commandline/stack_tasks/
+"/reference/cli/docker/stack/rm/":
+  - /edge/engine/reference/commandline/stack_rm/
+  - /engine/reference/commandline/stack_rm/
+"/reference/cli/docker/stack/services/":
+  - /edge/engine/reference/commandline/stack_services/
+  - /engine/reference/commandline/stack_services/
+"/reference/cli/docker/swarm/":
+  - /edge/engine/reference/commandline/swarm/
+  - /engine/reference/commandline/swarm/
+"/reference/cli/docker/swarm/ca/":
+  - /edge/engine/reference/commandline/swarm_ca/
+  - /engine/reference/commandline/swarm_ca/
+"/reference/cli/docker/swarm/init/":
+  - /edge/engine/reference/commandline/swarm_init/
+  - /engine/reference/commandline/swarm_init/
+"/reference/cli/docker/swarm/join-token/":
+  - /edge/engine/reference/commandline/swarm_join-token/
+  - /edge/engine/reference/commandline/swarm_join_token/
+  - /engine/reference/commandline/swarm_join-token/
+  - /engine/reference/commandline/swarm_join_token/
+"/reference/cli/docker/swarm/join/":
+  - /edge/engine/reference/commandline/swarm_join/
+  - /engine/reference/commandline/swarm_join/
+"/reference/cli/docker/swarm/leave/":
+  - /edge/engine/reference/commandline/swarm_leave/
+  - /engine/reference/commandline/swarm_leave/
+"/reference/cli/docker/swarm/unlock-key/":
+  - /edge/engine/reference/commandline/swarm_unlock-key/
+  - /engine/reference/commandline/swarm_unlock-key/
+"/reference/cli/docker/swarm/unlock/":
+  - /edge/engine/reference/commandline/swarm_unlock/
+  - /engine/reference/commandline/swarm_unlock/
+"/reference/cli/docker/swarm/update/":
+  - /edge/engine/reference/commandline/swarm_update/
+  - /engine/reference/commandline/swarm_update/
+"/reference/cli/docker/system/":
+  - /edge/engine/reference/commandline/system/
+  - /engine/reference/commandline/system/
+"/reference/cli/docker/system/df/":
+  - /edge/engine/reference/commandline/system_df/
+  - /engine/reference/commandline/system_df/
+"/reference/cli/docker/system/events/":
+  - /edge/engine/reference/commandline/system_events/
+  - /engine/reference/commandline/events/
+  - /engine/reference/commandline/system_events/
+"/reference/cli/docker/system/info/":
+  - /edge/engine/reference/commandline/system_info/
+  - /engine/reference/commandline/info/
+  - /engine/reference/commandline/system_info/
+  - /reference/cli/docker/info/
+"/reference/cli/docker/system/prune/":
+  - /edge/engine/reference/commandline/system_prune/
+  - /engine/reference/commandline/system_prune/
+"/reference/cli/docker/trust/":
+  - /edge/engine/reference/commandline/trust/
+  - /engine/reference/commandline/trust/
+"/reference/cli/docker/trust/inspect/":
+  - /edge/engine/reference/commandline/trust_inspect/
+  - /engine/reference/commandline/trust_inspect/
+"/reference/cli/docker/trust/key/":
+  - /edge/engine/reference/commandline/trust_key/
+  - /engine/reference/commandline/trust_key/
+"/reference/cli/docker/trust/key/generate/":
+  - /edge/engine/reference/commandline/trust_key_generate/
+  - /engine/reference/commandline/trust_key_generate/
+"/reference/cli/docker/trust/key/load/":
+  - /edge/engine/reference/commandline/trust_key_load/
+  - /engine/reference/commandline/trust_key_load/
+"/reference/cli/docker/trust/revoke/":
+  - /edge/engine/reference/commandline/trust_revoke/
+  - /engine/reference/commandline/trust_revoke/
+"/reference/cli/docker/trust/sign/":
+  - /edge/engine/reference/commandline/trust_sign/
+  - /engine/reference/commandline/trust_sign/
+"/reference/cli/docker/trust/signer/":
+  - /edge/engine/reference/commandline/trust_signer/
+  - /engine/reference/commandline/trust_signer/
+"/reference/cli/docker/trust/signer/add/":
+  - /edge/engine/reference/commandline/trust_signer_add/
+  - /engine/reference/commandline/trust_signer_add/
+"/reference/cli/docker/trust/signer/remove/":
+  - /edge/engine/reference/commandline/trust_signer_remove/
+  - /engine/reference/commandline/trust_signer_remove/
+"/reference/cli/docker/version/":
+  - /edge/engine/reference/commandline/version/
+  - /engine/reference/commandline/version/
+"/reference/cli/docker/volume/":
+  - /edge/engine/reference/commandline/volume/
+  - /engine/reference/commandline/volume/
+"/reference/cli/docker/volume/create/":
+  - /edge/engine/reference/commandline/volume_create/
+  - /engine/reference/commandline/volume_create/
+"/reference/cli/docker/volume/inspect/":
+  - /edge/engine/reference/commandline/volume_inspect/
+  - /engine/reference/commandline/volume_inspect/
+"/reference/cli/docker/volume/ls/":
+  - /edge/engine/reference/commandline/volume_ls/
+  - /engine/reference/commandline/volume_ls/
+"/reference/cli/docker/volume/prune/":
+  - /edge/engine/reference/commandline/volume_prune/
+  - /engine/reference/commandline/volume_prune/
+"/reference/cli/docker/volume/rm/":
+  - /edge/engine/reference/commandline/volume_rm/
+  - /engine/reference/commandline/volume_rm/
+"/reference/cli/docker/volume/update/":
+  - /engine/reference/commandline/volume_update/
diff --git a/data/samples.yaml b/data/samples.yaml
index deae29f0a7ab..49bb6e6d0776 100644
--- a/data/samples.yaml
+++ b/data/samples.yaml
@@ -350,4 +350,111 @@ samples:
     description: Get started with AI and ML using Docker, Neo4j, LangChain, and Ollama
     services:
       - python
-      - aiml
\ No newline at end of file
+      - aiml
+# Agentic AI ----------------------------
+  - title: Agent-to-Agent
+    url: https://github.com/docker/compose-for-agents/tree/main/a2a
+    description: >
+        This app is a modular AI agent runtime built on Google's Agent
+        Development Kit (ADK) and the A2A (Agent-to-Agent) protocol. It wraps a
+        large language model (LLM)-based agent in an HTTP API and uses
+        structured execution flows with streaming responses, memory, and tools.
+        It is designed to make agents callable as network services and
+        composable with other agents.
+    services:
+      - python
+      - aiml
+      - agentic-ai
+  - title: ADK Multi-Agent Fact Checker
+    url: https://github.com/docker/compose-for-agents/tree/main/adk
+    description: >
+      This project demonstrates a collaborative multi-agent system built with
+      the Agent Development Kit (ADK), where a top-level Auditor agent coordinates
+      the workflow to verify facts. The Critic agent gathers evidence via live
+      internet searches using DuckDuckGo through the Model Context Protocol (MCP),
+      while the Reviser agent analyzes and refines the conclusion using internal
+      reasoning alone. The system showcases how agents with distinct roles and
+      tools can collaborate under orchestration.
+    services:
+      - python
+      - aiml
+      - agentic-ai
+  - title: DevDuck agents
+    url: https://github.com/docker/compose-for-agents/tree/main/adk-cerebras
+    description: >
+      A multi-agent system for Go programming assistance built with Google
+      Agent Development Kit (ADK). This project features a coordinating agent
+      (DevDuck) that manages two specialized sub-agents (Bob and Cerebras)
+      for different programming tasks.
+    services:
+      - python
+      - aiml
+      - agentic-ai
+  - title: Agno
+    url: https://github.com/docker/compose-for-agents/tree/main/agno
+    description: >
+      This app is a multi-agent orchestration system powered by LLMs (like Qwen
+      and OpenAI) and connected to tools via a Model Control Protocol (MCP)
+      gateway. Its purpose is to retrieve, summarize, and document GitHub
+      issues—automatically creating Notion pages from the summaries. It also
+      supports file content summarization from GitHub.
+    services:
+      - python
+      - aiml
+      - agentic-ai
+  - title: CrewAI
+    url: https://github.com/docker/compose-for-agents/tree/main/crew-ai
+    description: >
+      This project showcases an autonomous, multi-agent virtual marketing team
+      built with CrewAI. It automates the creation of a high-quality, end-to-end
+      marketing strategy — from research to copywriting — using task delegation,
+      web search, and creative synthesis.
+    services:
+      - python
+      - aiml
+      - agentic-ai
+  - title: SQL Agent with LangGraph
+    url: https://github.com/docker/compose-for-agents/tree/main/langgraph
+    description: >
+      This project demonstrates a zero-config AI agent that uses LangGraph to
+      answer natural language questions by querying a SQL database — all
+      orchestrated with Docker Compose.
+    services:
+      - python
+      - aiml
+      - agentic-ai
+  - title: Langchaingo Brave Search Example - Model Context Protocol (MCP)
+    url: https://github.com/docker/compose-for-agents/tree/main/langchaingo
+    description: >
+      This example demonstrates how to create a Go Model Context Protocol
+      (MCP) client that communicates with the Brave Search MCP Server. The
+      application shows how to build an MCP client that enables natural language
+      interactions with Brave Search, allowing you to perform internet searches
+      through a conversational interface. This example uses the official Go SDK
+      for Model Context Protocol servers and clients, to set up the MCP client.
+    services:
+      - golang
+      - aiml
+      - agentic-ai
+  - title: Spring AI Brave Search Example - Model Context Protocol (MCP)
+    url: https://github.com/docker/compose-for-agents/tree/main/spring-ai
+    description: >
+      This example demonstrates how to create a Spring AI Model Context Protocol
+      (MCP) client that communicates with the Brave Search MCP Server. The
+      application shows how to build an MCP client that enables natural language
+      interactions with Brave Search, allowing you to perform internet searches
+      through a conversational interface. This example uses Spring Boot
+      autoconfiguration to set up the MCP client through configuration files.
+    services:
+      - java
+      - aiml
+      - agentic-ai
+  - title: MCP UI with Vercel AI SDK
+    url: https://github.com/docker/compose-for-agents/tree/main/vercel
+    description: >
+      Start an MCP UI application that uses the Vercel AI SDK to provide a
+      chat interface for local models, provided by the Docker Model Runner,
+      with access to MCPs from the Docker MCP Catalog.
+    services:
+      - aiml
+      - agentic-ai
\ No newline at end of file
diff --git a/data/sbx_cli/sbx.yaml b/data/sbx_cli/sbx.yaml
new file mode 100644
index 000000000000..239291883da4
--- /dev/null
+++ b/data/sbx_cli/sbx.yaml
@@ -0,0 +1,42 @@
+name: sbx
+synopsis: Manage AI coding agent sandboxes.
+description: |-
+    Docker Sandboxes creates isolated sandbox environments for AI agents, powered by Docker.
+
+    Run without a command to launch interactive mode, or pass a command for CLI usage.
+usage: sbx COMMAND
+options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for sbx
+see_also:
+    - sbx completion - Generate the autocompletion script for the specified shell
+    - sbx cp - Copy files or directories between a sandbox and the host
+    - sbx create - Create a sandbox for an agent
+    - sbx daemon - Manage sandboxd daemon
+    - sbx diagnose - Diagnose common issues with your sbx installation
+    - sbx env - (Experimental) Manage sandboxes declaratively from a .sbxenv.yaml file
+    - sbx exec - Execute a command inside a sandbox
+    - sbx kit - (Experimental) Manage kit artifacts
+    - sbx login - Sign in to Docker
+    - sbx logout - Stop all running sandboxes and sign out of Docker
+    - sbx ls - List sandboxes
+    - sbx mcp - Manage MCP servers
+    - sbx policy - Manage sandbox policies
+    - sbx ports - Manage sandbox port publishing
+    - sbx prune - Remove all stopped sandboxes
+    - sbx reset - Reset all sandboxes and clean up state
+    - sbx rm - Remove one or more sandboxes
+    - sbx run - Run an agent in a sandbox
+    - sbx secret - Manage stored secrets
+    - sbx setup - (Experimental) Detect host configuration and prepare Docker Sandboxes
+    - sbx skills - (Experimental) Manage skills shared across sandboxes
+    - sbx stop - Stop one or more sandboxes without removing them
+    - sbx template - Manage sandbox templates
+    - sbx tui - Open the interactive TUI dashboard
+    - sbx version - Show Docker Sandboxes version information
diff --git a/data/sbx_cli/sbx_completion.yaml b/data/sbx_cli/sbx_completion.yaml
new file mode 100644
index 000000000000..ecab3f1117ed
--- /dev/null
+++ b/data/sbx_cli/sbx_completion.yaml
@@ -0,0 +1,22 @@
+name: sbx completion
+synopsis: Generate the autocompletion script for the specified shell
+description: |
+    Generate the autocompletion script for sbx for the specified shell.
+    See each sub-command's help for details on how to use the generated script.
+usage: sbx completion COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for completion
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
+    - sbx completion bash - Generate the autocompletion script for bash
+    - sbx completion fish - Generate the autocompletion script for fish
+    - sbx completion powershell - Generate the autocompletion script for powershell
+    - sbx completion zsh - Generate the autocompletion script for zsh
diff --git a/data/sbx_cli/sbx_completion_bash.yaml b/data/sbx_cli/sbx_completion_bash.yaml
new file mode 100644
index 000000000000..4e06d587fb52
--- /dev/null
+++ b/data/sbx_cli/sbx_completion_bash.yaml
@@ -0,0 +1,39 @@
+name: sbx completion bash
+synopsis: Generate the autocompletion script for bash
+description: |
+    Generate the autocompletion script for the bash shell.
+
+    This script depends on the 'bash-completion' package.
+    If it is not installed already, you can install it via your OS's package manager.
+
+    To load completions in your current shell session:
+
+    	source <(sbx completion bash)
+
+    To load completions for every new session, execute once:
+
+    #### Linux:
+
+    	sbx completion bash > /etc/bash_completion.d/sbx
+
+    #### macOS:
+
+    	sbx completion bash > $(brew --prefix)/etc/bash_completion.d/sbx
+
+    You will need to start a new shell for this setup to take effect.
+usage: sbx completion bash
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for bash
+    - name: no-descriptions
+      default_value: "false"
+      usage: disable completion descriptions
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx completion - Generate the autocompletion script for the specified shell
diff --git a/data/sbx_cli/sbx_completion_fish.yaml b/data/sbx_cli/sbx_completion_fish.yaml
new file mode 100644
index 000000000000..2d38fe4b2d51
--- /dev/null
+++ b/data/sbx_cli/sbx_completion_fish.yaml
@@ -0,0 +1,30 @@
+name: sbx completion fish
+synopsis: Generate the autocompletion script for fish
+description: |
+    Generate the autocompletion script for the fish shell.
+
+    To load completions in your current shell session:
+
+    	sbx completion fish | source
+
+    To load completions for every new session, execute once:
+
+    	sbx completion fish > ~/.config/fish/completions/sbx.fish
+
+    You will need to start a new shell for this setup to take effect.
+usage: sbx completion fish [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for fish
+    - name: no-descriptions
+      default_value: "false"
+      usage: disable completion descriptions
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx completion - Generate the autocompletion script for the specified shell
diff --git a/data/sbx_cli/sbx_completion_powershell.yaml b/data/sbx_cli/sbx_completion_powershell.yaml
new file mode 100644
index 000000000000..6a442b5d993b
--- /dev/null
+++ b/data/sbx_cli/sbx_completion_powershell.yaml
@@ -0,0 +1,27 @@
+name: sbx completion powershell
+synopsis: Generate the autocompletion script for powershell
+description: |
+    Generate the autocompletion script for powershell.
+
+    To load completions in your current shell session:
+
+    	sbx completion powershell | Out-String | Invoke-Expression
+
+    To load completions for every new session, add the output of the above command
+    to your powershell profile.
+usage: sbx completion powershell [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for powershell
+    - name: no-descriptions
+      default_value: "false"
+      usage: disable completion descriptions
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx completion - Generate the autocompletion script for the specified shell
diff --git a/data/sbx_cli/sbx_completion_zsh.yaml b/data/sbx_cli/sbx_completion_zsh.yaml
new file mode 100644
index 000000000000..2ccf93f0dd0b
--- /dev/null
+++ b/data/sbx_cli/sbx_completion_zsh.yaml
@@ -0,0 +1,41 @@
+name: sbx completion zsh
+synopsis: Generate the autocompletion script for zsh
+description: |
+    Generate the autocompletion script for the zsh shell.
+
+    If shell completion is not already enabled in your environment you will need
+    to enable it.  You can execute the following once:
+
+    	echo "autoload -U compinit; compinit" >> ~/.zshrc
+
+    To load completions in your current shell session:
+
+    	source <(sbx completion zsh)
+
+    To load completions for every new session, execute once:
+
+    #### Linux:
+
+    	sbx completion zsh > "${fpath[1]}/_sbx"
+
+    #### macOS:
+
+    	sbx completion zsh > $(brew --prefix)/share/zsh/site-functions/_sbx
+
+    You will need to start a new shell for this setup to take effect.
+usage: sbx completion zsh [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for zsh
+    - name: no-descriptions
+      default_value: "false"
+      usage: disable completion descriptions
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx completion - Generate the autocompletion script for the specified shell
diff --git a/data/sbx_cli/sbx_cp.yaml b/data/sbx_cli/sbx_cp.yaml
new file mode 100644
index 000000000000..877f0efb566f
--- /dev/null
+++ b/data/sbx_cli/sbx_cp.yaml
@@ -0,0 +1,35 @@
+name: sbx cp
+synopsis: Copy files or directories between a sandbox and the host
+description: |-
+    Either SRC or DST must be a sandbox path, written as SANDBOX:PATH.
+    The other must be a local path. Copying between two sandboxes is not supported.
+
+    When copying a directory, the directory itself is placed at the destination.
+    If the destination path does not exist it is created; if it already exists
+    as a directory, the source is placed inside it.
+usage: sbx cp [flags] SRC DST
+options:
+    - name: follow-link
+      shorthand: L
+      default_value: "false"
+      usage: Follow symbolic links in the source path
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for cp
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Copy a file from host to sandbox
+      sbx cp ./config.json my-sandbox:/home/user/
+
+      # Copy a file from sandbox to host
+      sbx cp my-sandbox:/home/user/output.log ./
+
+      # Copy a directory
+      sbx cp ./src/ my-sandbox:/home/user/src
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_create.yaml b/data/sbx_cli/sbx_create.yaml
new file mode 100644
index 000000000000..394b54071387
--- /dev/null
+++ b/data/sbx_cli/sbx_create.yaml
@@ -0,0 +1,87 @@
+name: sbx create
+synopsis: Create a sandbox for an agent
+description: |-
+    Create a sandbox with access to a host workspace for an agent.
+
+    Use "sbx run --name SANDBOX" to attach to the agent after creation.
+usage: sbx create [flags] AGENT PATH [PATH...]
+options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for create
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: |
+        Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods; 'default' is reserved)
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Suppress verbose output
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Create a sandbox for Claude in the current directory
+      sbx create claude .
+
+      # Create a sandbox with a custom name
+      sbx create --name my-project claude /path/to/project
+
+      # Create with additional read-only workspaces
+      sbx create claude . /path/to/docs:ro
+
+      # Run the agent on an in-container clone of the host repo, wired back via a git-daemon
+      sbx create --clone claude .
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
+    - sbx create claude - Create a sandbox for claude
+    - sbx create codex - Create a sandbox for codex
+    - sbx create copilot - Create a sandbox for copilot
+    - sbx create cursor - Create a sandbox for cursor
+    - sbx create docker-agent - Create a sandbox for docker-agent
+    - sbx create droid - Create a sandbox for droid
+    - sbx create gemini - Create a sandbox for gemini
+    - sbx create kiro - Create a sandbox for kiro
+    - sbx create opencode - Create a sandbox for opencode
+    - sbx create shell - Create a sandbox for shell
diff --git a/data/sbx_cli/sbx_create_claude.yaml b/data/sbx_cli/sbx_create_claude.yaml
new file mode 100644
index 000000000000..9f3fd598ea74
--- /dev/null
+++ b/data/sbx_cli/sbx_create_claude.yaml
@@ -0,0 +1,78 @@
+name: sbx create claude
+synopsis: Create a sandbox for claude
+description: |-
+    Create a sandbox with access to a host workspace for claude.
+
+    The workspace path is required and will be mounted inside the sandbox at the
+    same path as on the host. Additional workspaces can be provided as extra
+    arguments. Append ":ro" to mount them read-only.
+
+    Use "sbx run --name SANDBOX" to attach to the agent after creation.
+usage: sbx create claude PATH [PATH...] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for claude
+inherited_options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: |
+        Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods; 'default' is reserved)
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Suppress verbose output
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+example: |4-
+      # Create in the current directory
+      sbx create claude .
+
+      # Create with a specific path
+      sbx create claude /path/to/project
+
+      # Create with additional read-only workspaces
+      sbx create claude . /path/to/docs:ro
+see_also:
+    - sbx create - Create a sandbox for an agent
diff --git a/data/sbx_cli/sbx_create_codex.yaml b/data/sbx_cli/sbx_create_codex.yaml
new file mode 100644
index 000000000000..f1d3bece138d
--- /dev/null
+++ b/data/sbx_cli/sbx_create_codex.yaml
@@ -0,0 +1,78 @@
+name: sbx create codex
+synopsis: Create a sandbox for codex
+description: |-
+    Create a sandbox with access to a host workspace for codex.
+
+    The workspace path is required and will be mounted inside the sandbox at the
+    same path as on the host. Additional workspaces can be provided as extra
+    arguments. Append ":ro" to mount them read-only.
+
+    Use "sbx run --name SANDBOX" to attach to the agent after creation.
+usage: sbx create codex PATH [PATH...] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for codex
+inherited_options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: |
+        Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods; 'default' is reserved)
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Suppress verbose output
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+example: |4-
+      # Create in the current directory
+      sbx create codex .
+
+      # Create with a specific path
+      sbx create codex /path/to/project
+
+      # Create with additional read-only workspaces
+      sbx create codex . /path/to/docs:ro
+see_also:
+    - sbx create - Create a sandbox for an agent
diff --git a/data/sbx_cli/sbx_create_copilot.yaml b/data/sbx_cli/sbx_create_copilot.yaml
new file mode 100644
index 000000000000..29d8a9d559be
--- /dev/null
+++ b/data/sbx_cli/sbx_create_copilot.yaml
@@ -0,0 +1,78 @@
+name: sbx create copilot
+synopsis: Create a sandbox for copilot
+description: |-
+    Create a sandbox with access to a host workspace for copilot.
+
+    The workspace path is required and will be mounted inside the sandbox at the
+    same path as on the host. Additional workspaces can be provided as extra
+    arguments. Append ":ro" to mount them read-only.
+
+    Use "sbx run --name SANDBOX" to attach to the agent after creation.
+usage: sbx create copilot PATH [PATH...] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for copilot
+inherited_options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: |
+        Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods; 'default' is reserved)
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Suppress verbose output
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+example: |4-
+      # Create in the current directory
+      sbx create copilot .
+
+      # Create with a specific path
+      sbx create copilot /path/to/project
+
+      # Create with additional read-only workspaces
+      sbx create copilot . /path/to/docs:ro
+see_also:
+    - sbx create - Create a sandbox for an agent
diff --git a/data/sbx_cli/sbx_create_cursor.yaml b/data/sbx_cli/sbx_create_cursor.yaml
new file mode 100644
index 000000000000..fb7564c1ff3a
--- /dev/null
+++ b/data/sbx_cli/sbx_create_cursor.yaml
@@ -0,0 +1,78 @@
+name: sbx create cursor
+synopsis: Create a sandbox for cursor
+description: |-
+    Create a sandbox with access to a host workspace for cursor.
+
+    The workspace path is required and will be mounted inside the sandbox at the
+    same path as on the host. Additional workspaces can be provided as extra
+    arguments. Append ":ro" to mount them read-only.
+
+    Use "sbx run --name SANDBOX" to attach to the agent after creation.
+usage: sbx create cursor PATH [PATH...] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for cursor
+inherited_options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: |
+        Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods; 'default' is reserved)
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Suppress verbose output
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+example: |4-
+      # Create in the current directory
+      sbx create cursor .
+
+      # Create with a specific path
+      sbx create cursor /path/to/project
+
+      # Create with additional read-only workspaces
+      sbx create cursor . /path/to/docs:ro
+see_also:
+    - sbx create - Create a sandbox for an agent
diff --git a/data/sbx_cli/sbx_create_docker-agent.yaml b/data/sbx_cli/sbx_create_docker-agent.yaml
new file mode 100644
index 000000000000..2dc8938a2d0b
--- /dev/null
+++ b/data/sbx_cli/sbx_create_docker-agent.yaml
@@ -0,0 +1,78 @@
+name: sbx create docker-agent
+synopsis: Create a sandbox for docker-agent
+description: |-
+    Create a sandbox with access to a host workspace for docker-agent.
+
+    The workspace path is required and will be mounted inside the sandbox at the
+    same path as on the host. Additional workspaces can be provided as extra
+    arguments. Append ":ro" to mount them read-only.
+
+    Use "sbx run --name SANDBOX" to attach to the agent after creation.
+usage: sbx create docker-agent PATH [PATH...] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for docker-agent
+inherited_options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: |
+        Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods; 'default' is reserved)
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Suppress verbose output
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+example: |4-
+      # Create in the current directory
+      sbx create docker-agent .
+
+      # Create with a specific path
+      sbx create docker-agent /path/to/project
+
+      # Create with additional read-only workspaces
+      sbx create docker-agent . /path/to/docs:ro
+see_also:
+    - sbx create - Create a sandbox for an agent
diff --git a/data/sbx_cli/sbx_create_droid.yaml b/data/sbx_cli/sbx_create_droid.yaml
new file mode 100644
index 000000000000..168e70ccff8e
--- /dev/null
+++ b/data/sbx_cli/sbx_create_droid.yaml
@@ -0,0 +1,78 @@
+name: sbx create droid
+synopsis: Create a sandbox for droid
+description: |-
+    Create a sandbox with access to a host workspace for droid.
+
+    The workspace path is required and will be mounted inside the sandbox at the
+    same path as on the host. Additional workspaces can be provided as extra
+    arguments. Append ":ro" to mount them read-only.
+
+    Use "sbx run --name SANDBOX" to attach to the agent after creation.
+usage: sbx create droid PATH [PATH...] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for droid
+inherited_options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: |
+        Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods; 'default' is reserved)
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Suppress verbose output
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+example: |4-
+      # Create in the current directory
+      sbx create droid .
+
+      # Create with a specific path
+      sbx create droid /path/to/project
+
+      # Create with additional read-only workspaces
+      sbx create droid . /path/to/docs:ro
+see_also:
+    - sbx create - Create a sandbox for an agent
diff --git a/data/sbx_cli/sbx_create_gemini.yaml b/data/sbx_cli/sbx_create_gemini.yaml
new file mode 100644
index 000000000000..cc3fd9165813
--- /dev/null
+++ b/data/sbx_cli/sbx_create_gemini.yaml
@@ -0,0 +1,78 @@
+name: sbx create gemini
+synopsis: Create a sandbox for gemini
+description: |-
+    Create a sandbox with access to a host workspace for gemini.
+
+    The workspace path is required and will be mounted inside the sandbox at the
+    same path as on the host. Additional workspaces can be provided as extra
+    arguments. Append ":ro" to mount them read-only.
+
+    Use "sbx run --name SANDBOX" to attach to the agent after creation.
+usage: sbx create gemini PATH [PATH...] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for gemini
+inherited_options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: |
+        Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods; 'default' is reserved)
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Suppress verbose output
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+example: |4-
+      # Create in the current directory
+      sbx create gemini .
+
+      # Create with a specific path
+      sbx create gemini /path/to/project
+
+      # Create with additional read-only workspaces
+      sbx create gemini . /path/to/docs:ro
+see_also:
+    - sbx create - Create a sandbox for an agent
diff --git a/data/sbx_cli/sbx_create_kiro.yaml b/data/sbx_cli/sbx_create_kiro.yaml
new file mode 100644
index 000000000000..2008da0763ea
--- /dev/null
+++ b/data/sbx_cli/sbx_create_kiro.yaml
@@ -0,0 +1,78 @@
+name: sbx create kiro
+synopsis: Create a sandbox for kiro
+description: |-
+    Create a sandbox with access to a host workspace for kiro.
+
+    The workspace path is required and will be mounted inside the sandbox at the
+    same path as on the host. Additional workspaces can be provided as extra
+    arguments. Append ":ro" to mount them read-only.
+
+    Use "sbx run --name SANDBOX" to attach to the agent after creation.
+usage: sbx create kiro PATH [PATH...] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for kiro
+inherited_options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: |
+        Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods; 'default' is reserved)
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Suppress verbose output
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+example: |4-
+      # Create in the current directory
+      sbx create kiro .
+
+      # Create with a specific path
+      sbx create kiro /path/to/project
+
+      # Create with additional read-only workspaces
+      sbx create kiro . /path/to/docs:ro
+see_also:
+    - sbx create - Create a sandbox for an agent
diff --git a/data/sbx_cli/sbx_create_opencode.yaml b/data/sbx_cli/sbx_create_opencode.yaml
new file mode 100644
index 000000000000..298a78de304f
--- /dev/null
+++ b/data/sbx_cli/sbx_create_opencode.yaml
@@ -0,0 +1,78 @@
+name: sbx create opencode
+synopsis: Create a sandbox for opencode
+description: |-
+    Create a sandbox with access to a host workspace for opencode.
+
+    The workspace path is required and will be mounted inside the sandbox at the
+    same path as on the host. Additional workspaces can be provided as extra
+    arguments. Append ":ro" to mount them read-only.
+
+    Use "sbx run --name SANDBOX" to attach to the agent after creation.
+usage: sbx create opencode PATH [PATH...] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for opencode
+inherited_options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: |
+        Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods; 'default' is reserved)
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Suppress verbose output
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+example: |4-
+      # Create in the current directory
+      sbx create opencode .
+
+      # Create with a specific path
+      sbx create opencode /path/to/project
+
+      # Create with additional read-only workspaces
+      sbx create opencode . /path/to/docs:ro
+see_also:
+    - sbx create - Create a sandbox for an agent
diff --git a/data/sbx_cli/sbx_create_shell.yaml b/data/sbx_cli/sbx_create_shell.yaml
new file mode 100644
index 000000000000..1d56a4309479
--- /dev/null
+++ b/data/sbx_cli/sbx_create_shell.yaml
@@ -0,0 +1,78 @@
+name: sbx create shell
+synopsis: Create a sandbox for shell
+description: |-
+    Create a sandbox with access to a host workspace for shell.
+
+    The workspace path is required and will be mounted inside the sandbox at the
+    same path as on the host. Additional workspaces can be provided as extra
+    arguments. Append ":ro" to mount them read-only.
+
+    Use "sbx run --name SANDBOX" to attach to the agent after creation.
+usage: sbx create shell PATH [PATH...] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for shell
+inherited_options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: |
+        Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods; 'default' is reserved)
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Suppress verbose output
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+example: |4-
+      # Create in the current directory
+      sbx create shell .
+
+      # Create with a specific path
+      sbx create shell /path/to/project
+
+      # Create with additional read-only workspaces
+      sbx create shell . /path/to/docs:ro
+see_also:
+    - sbx create - Create a sandbox for an agent
diff --git a/data/sbx_cli/sbx_daemon.yaml b/data/sbx_cli/sbx_daemon.yaml
new file mode 100644
index 000000000000..f7a913bd4683
--- /dev/null
+++ b/data/sbx_cli/sbx_daemon.yaml
@@ -0,0 +1,20 @@
+name: sbx daemon
+synopsis: Manage sandboxd daemon
+usage: sbx daemon COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for daemon
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
+    - sbx daemon log-level - Inspect or change sandboxd's per-category log levels
+    - sbx daemon restart - Restart the sandboxd daemon
+    - sbx daemon start - Start the sandboxd daemon
+    - sbx daemon status - Check sandboxd daemon status
+    - sbx daemon stop - Stop the sandboxd daemon
diff --git a/data/sbx_cli/sbx_daemon_log-level.yaml b/data/sbx_cli/sbx_daemon_log-level.yaml
new file mode 100644
index 000000000000..20822ef1bd11
--- /dev/null
+++ b/data/sbx_cli/sbx_daemon_log-level.yaml
@@ -0,0 +1,16 @@
+name: sbx daemon log-level
+synopsis: Inspect or change sandboxd's per-category log levels
+usage: sbx daemon log-level [COMMAND]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for log-level
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx daemon - Manage sandboxd daemon
+    - 'sbx daemon log-level set - Set a category''s log level (target: proxy, general, or all)'
diff --git a/data/sbx_cli/sbx_daemon_log-level_set.yaml b/data/sbx_cli/sbx_daemon_log-level_set.yaml
new file mode 100644
index 000000000000..d3da38752bbb
--- /dev/null
+++ b/data/sbx_cli/sbx_daemon_log-level_set.yaml
@@ -0,0 +1,15 @@
+name: sbx daemon log-level set
+synopsis: 'Set a category''s log level (target: proxy, general, or all)'
+usage: sbx daemon log-level set <target> <level> [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for set
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx daemon log-level - Inspect or change sandboxd's per-category log levels
diff --git a/data/sbx_cli/sbx_daemon_restart.yaml b/data/sbx_cli/sbx_daemon_restart.yaml
new file mode 100644
index 000000000000..d7bea6d0f156
--- /dev/null
+++ b/data/sbx_cli/sbx_daemon_restart.yaml
@@ -0,0 +1,15 @@
+name: sbx daemon restart
+synopsis: Restart the sandboxd daemon
+usage: sbx daemon restart [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for restart
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx daemon - Manage sandboxd daemon
diff --git a/data/sbx_cli/sbx_daemon_start.yaml b/data/sbx_cli/sbx_daemon_start.yaml
new file mode 100644
index 000000000000..879c93c62015
--- /dev/null
+++ b/data/sbx_cli/sbx_daemon_start.yaml
@@ -0,0 +1,22 @@
+name: sbx daemon start
+synopsis: Start the sandboxd daemon
+usage: sbx daemon start [flags]
+options:
+    - name: detach
+      shorthand: d
+      default_value: "false"
+      usage: Run daemon in background
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for start
+    - name: policy
+      usage: |
+        Initialize the global network policy: "allow-all", "balanced", or "deny-all"
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx daemon - Manage sandboxd daemon
diff --git a/data/sbx_cli/sbx_daemon_status.yaml b/data/sbx_cli/sbx_daemon_status.yaml
new file mode 100644
index 000000000000..9b3c790e76de
--- /dev/null
+++ b/data/sbx_cli/sbx_daemon_status.yaml
@@ -0,0 +1,18 @@
+name: sbx daemon status
+synopsis: Check sandboxd daemon status
+usage: sbx daemon status [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for status
+    - name: json
+      default_value: "false"
+      usage: Output as JSON
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx daemon - Manage sandboxd daemon
diff --git a/data/sbx_cli/sbx_daemon_stop.yaml b/data/sbx_cli/sbx_daemon_stop.yaml
new file mode 100644
index 000000000000..d703903cb3ac
--- /dev/null
+++ b/data/sbx_cli/sbx_daemon_stop.yaml
@@ -0,0 +1,15 @@
+name: sbx daemon stop
+synopsis: Stop the sandboxd daemon
+usage: sbx daemon stop [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for stop
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx daemon - Manage sandboxd daemon
diff --git a/data/sbx_cli/sbx_diagnose.yaml b/data/sbx_cli/sbx_diagnose.yaml
new file mode 100644
index 000000000000..e0eac7110fd6
--- /dev/null
+++ b/data/sbx_cli/sbx_diagnose.yaml
@@ -0,0 +1,21 @@
+name: sbx diagnose
+synopsis: Diagnose common issues with your sbx installation
+usage: sbx diagnose
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for diagnose
+    - name: output
+      shorthand: o
+      usage: 'Output format: "json" or "github-issue"'
+    - name: upload
+      default_value: "false"
+      usage: Upload diagnostics to Docker support
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_env.yaml b/data/sbx_cli/sbx_env.yaml
new file mode 100644
index 000000000000..9c64d66c74ee
--- /dev/null
+++ b/data/sbx_cli/sbx_env.yaml
@@ -0,0 +1,28 @@
+name: sbx env
+synopsis: |
+    Manage sandboxes declaratively from a .sbxenv.yaml file
+experimental: true
+description: |-
+    Manage a sandbox environment declared in a .sbxenv.yaml file.
+
+    The file describes the agent, optional mixin kits, workspace mounts,
+    environment variables, secrets to provision, and per-service credential
+    bindings. Secrets are provisioned at the environment's sandbox scope so
+    `sbx env rm` can remove everything it created.
+usage: sbx env COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for env
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
+    - sbx env create - Create a sandbox environment from .sbxenv.yaml
+    - sbx env exec - Execute a command inside a sandbox environment
+    - sbx env rm - Remove a sandbox environment and its scoped resources
+    - sbx env run - Create (if needed) and attach to a sandbox environment
diff --git a/data/sbx_cli/sbx_env_create.yaml b/data/sbx_cli/sbx_env_create.yaml
new file mode 100644
index 000000000000..1048fa27ea5f
--- /dev/null
+++ b/data/sbx_cli/sbx_env_create.yaml
@@ -0,0 +1,30 @@
+name: sbx env create
+synopsis: Create a sandbox environment from .sbxenv.yaml
+experimental: true
+description: |-
+    Read the environment file from PATH (default: current directory),
+    provision its declared secrets at the sandbox scope, merge its credential
+    bindings, and create the sandbox. Use "sbx env run" to attach.
+
+    Each PATH may be a directory (the file is <PATH>/.sbxenv.yaml) or the
+    path to the environment file itself. Passing more than one PATH deep-merges them
+    in order (docker-compose `-f` semantics): later files override earlier ones.
+    Values may reference environment variables with ${VAR} / $VAR (and
+    ${VAR:-default}); see the docs for the full syntax.
+usage: sbx env create [PATH...] [flags]
+options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Override workspace.clone in .sbxenv.yaml (see 'sbx create --clone')
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for create
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx env - (Experimental) Manage sandboxes declaratively from a .sbxenv.yaml file
diff --git a/data/sbx_cli/sbx_env_exec.yaml b/data/sbx_cli/sbx_env_exec.yaml
new file mode 100644
index 000000000000..225789753ab1
--- /dev/null
+++ b/data/sbx_cli/sbx_env_exec.yaml
@@ -0,0 +1,68 @@
+name: sbx env exec
+synopsis: Execute a command inside a sandbox environment
+experimental: true
+description: |-
+    Run COMMAND in the sandbox declared in .sbxenv.yaml. The sandbox
+    must already exist (see "sbx env create" and "sbx env run"); a stopped sandbox is
+    started first.
+
+    Arguments before `--` are environment-file paths, following the same rules as
+    the other "sbx env" subcommands: each PATH may be a directory (the file is
+    <PATH>/.sbxenv.yaml) or the path to the environment file itself, and passing
+    more than one deep-merges them in order. Without a `--` every positional
+    argument forms the command and the environment file is read from the current
+    directory.
+
+    Flags match the behavior of "sbx exec".
+usage: sbx env exec [flags] [PATH...] -- COMMAND [ARG...]
+options:
+    - name: detach
+      shorthand: d
+      default_value: "false"
+      usage: 'Detached mode: run command in the background'
+    - name: detach-keys
+      usage: Override the key sequence for detaching a container
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: Set environment variables
+    - name: env-file
+      default_value: '[]'
+      usage: Read in a file of environment variables
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for exec
+    - name: interactive
+      shorthand: i
+      default_value: "false"
+      usage: Keep STDIN open even if not attached
+    - name: privileged
+      default_value: "false"
+      usage: Give extended privileges to the command
+    - name: tty
+      shorthand: t
+      default_value: "false"
+      usage: Allocate a pseudo-TTY
+    - name: user
+      shorthand: u
+      usage: 'Username or UID (format: <name|uid>[:<group|gid>])'
+    - name: workdir
+      shorthand: w
+      usage: Working directory inside the container
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Run a command in the environment declared in the current directory
+      sbx env exec go test ./...
+
+      # Open a shell
+      sbx env exec -it -- bash
+
+      # Run against explicitly merged environment files
+      sbx env exec .sbxenv.yaml override.yaml -- npm test
+see_also:
+    - sbx env - (Experimental) Manage sandboxes declaratively from a .sbxenv.yaml file
diff --git a/data/sbx_cli/sbx_env_rm.yaml b/data/sbx_cli/sbx_env_rm.yaml
new file mode 100644
index 000000000000..5f43f20ade82
--- /dev/null
+++ b/data/sbx_cli/sbx_env_rm.yaml
@@ -0,0 +1,35 @@
+name: sbx env rm
+synopsis: Remove a sandbox environment and its scoped resources
+experimental: true
+description: |-
+    Remove the sandbox declared in .sbxenv.yaml along with the
+    secret values provisioned at its sandbox scope (service, custom, and registry
+    credentials). Global credential bindings are left in place by default since
+    they are user-wide and may be shared with other sandboxes; pass
+    --prune-bindings to also remove the bindings this environment declares.
+
+    Each PATH may be a directory (the file is <PATH>/.sbxenv.yaml) or the
+    path to the environment file itself. Passing more than one PATH deep-merges them
+    in order (docker-compose `-f` semantics), so the same set used to create the
+    environment resolves to the same sandbox on removal.
+usage: sbx env rm [PATH...] [flags]
+options:
+    - name: force
+      shorthand: f
+      default_value: "false"
+      usage: Skip confirmation prompts
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for rm
+    - name: prune-bindings
+      default_value: "false"
+      usage: |
+        Also remove this environment's bindings from the global credentials.yaml
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx env - (Experimental) Manage sandboxes declaratively from a .sbxenv.yaml file
diff --git a/data/sbx_cli/sbx_env_run.yaml b/data/sbx_cli/sbx_env_run.yaml
new file mode 100644
index 000000000000..f23ca8f61518
--- /dev/null
+++ b/data/sbx_cli/sbx_env_run.yaml
@@ -0,0 +1,35 @@
+name: sbx env run
+synopsis: Create (if needed) and attach to a sandbox environment
+experimental: true
+description: |-
+    Read the environment file from PATH (default: current directory)
+    and drop into the sandbox shell. If the sandbox already exists it is started
+    and re-attached without re-provisioning; otherwise it is created first
+    (provisioning secrets and bindings) and then attached.
+
+    Each PATH may be a directory (the file is <PATH>/.sbxenv.yaml) or the
+    path to the environment file itself. Passing more than one PATH deep-merges them
+    in order (docker-compose `-f` semantics): later files override earlier ones.
+    Values may reference environment variables with ${VAR} / $VAR (and
+    ${VAR:-default}); see the docs for the full syntax.
+usage: sbx env run [PATH...] [flags]
+options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Override workspace.clone in .sbxenv.yaml (see 'sbx create --clone')
+    - name: detached
+      shorthand: d
+      default_value: "false"
+      usage: Create/start the sandbox without attaching
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for run
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx env - (Experimental) Manage sandboxes declaratively from a .sbxenv.yaml file
diff --git a/data/sbx_cli/sbx_exec.yaml b/data/sbx_cli/sbx_exec.yaml
new file mode 100644
index 000000000000..d060aad82f1f
--- /dev/null
+++ b/data/sbx_cli/sbx_exec.yaml
@@ -0,0 +1,58 @@
+name: sbx exec
+synopsis: Execute a command inside a sandbox
+description: |-
+    Execute a command in a sandbox. If the sandbox is stopped, it is started first.
+
+    Flags match the behavior of "docker exec".
+usage: sbx exec [flags] SANDBOX COMMAND [ARG...]
+options:
+    - name: detach
+      shorthand: d
+      default_value: "false"
+      usage: 'Detached mode: run command in the background'
+    - name: detach-keys
+      usage: Override the key sequence for detaching a container
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: Set environment variables
+    - name: env-file
+      default_value: '[]'
+      usage: Read in a file of environment variables
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for exec
+    - name: interactive
+      shorthand: i
+      default_value: "false"
+      usage: Keep STDIN open even if not attached
+    - name: privileged
+      default_value: "false"
+      usage: Give extended privileges to the command
+    - name: tty
+      shorthand: t
+      default_value: "false"
+      usage: Allocate a pseudo-TTY
+    - name: user
+      shorthand: u
+      usage: 'Username or UID (format: <name|uid>[:<group|gid>])'
+    - name: workdir
+      shorthand: w
+      usage: Working directory inside the container
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Open a shell inside a sandbox
+      sbx exec -it my-sandbox bash
+
+      # Run a command in the background
+      sbx exec -d my-sandbox npm start
+
+      # Run as root
+      sbx exec -u root my-sandbox apt-get update
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_kit.yaml b/data/sbx_cli/sbx_kit.yaml
new file mode 100644
index 000000000000..1fd478705799
--- /dev/null
+++ b/data/sbx_cli/sbx_kit.yaml
@@ -0,0 +1,30 @@
+name: sbx kit
+synopsis: Manage kit artifacts
+experimental: true
+description: |-
+    Manage kit artifacts.
+
+    Kits are declarative YAML artifacts that extend sandbox agents with additional
+    credentials, network policies, environment variables, startup commands, and files.
+usage: sbx kit COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for kit
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
+    - sbx kit add - Add a kit to a sandbox
+    - sbx kit inspect - Display details about a kit artifact
+    - sbx kit pack - Package a directory as a kit artifact
+    - sbx kit provenance - Show the SLSA provenance attached to a kit
+    - sbx kit pull - Pull a kit artifact from an OCI registry
+    - sbx kit push - Push a kit artifact to an OCI registry
+    - sbx kit sign - Sign a kit artifact
+    - sbx kit validate - Validate a kit artifact
+    - sbx kit verify - Verify a kit artifact's signature
diff --git a/data/sbx_cli/sbx_kit_add.yaml b/data/sbx_cli/sbx_kit_add.yaml
new file mode 100644
index 000000000000..e768a304ebca
--- /dev/null
+++ b/data/sbx_cli/sbx_kit_add.yaml
@@ -0,0 +1,43 @@
+name: sbx kit add
+synopsis: Add a kit to a sandbox
+experimental: true
+description: |-
+    Add a kit artifact to an existing sandbox.
+
+    The sandbox's container is recreated with the new kit appended to its
+    original kit list, preserving kit-owned volumes (e.g. agent session
+    state) across the swap. Workspace data is unaffected: bind-mounted
+    sandboxes keep their host-side mount; --clone sandboxes keep their
+    in-container working tree via a named workspace volume that
+    reattaches to the swap container.
+
+    The sandbox must already exist and must have been created with the
+    recreate-aware label set (sandboxes created before the kit-add recreate
+    feature shipped will be refused with a clear error). The reference can be
+    a local directory, ZIP file path, OCI registry reference, or git
+    repository.
+usage: sbx kit add SANDBOX REFERENCE [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for add
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Add a local kit directory to a sandbox
+      sbx kit add my-sandbox ./mcp-postgres/
+
+      # Add a kit from a ZIP file
+      sbx kit add my-sandbox ./mcp-postgres.zip
+
+      # Add a kit from an OCI registry
+      sbx kit add my-sandbox ghcr.io/myorg/mcp-postgres:1.0
+
+      # Add a kit from a git repository
+      sbx kit add my-sandbox git+https://github.com/org/kits.git#dir=mcp-postgres
+see_also:
+    - sbx kit - (Experimental) Manage kit artifacts
diff --git a/data/sbx_cli/sbx_kit_inspect.yaml b/data/sbx_cli/sbx_kit_inspect.yaml
new file mode 100644
index 000000000000..fd985cceafbc
--- /dev/null
+++ b/data/sbx_cli/sbx_kit_inspect.yaml
@@ -0,0 +1,23 @@
+name: sbx kit inspect
+synopsis: Display details about a kit artifact
+experimental: true
+description: |-
+    Load and display details about a kit artifact.
+
+    The reference can be a local directory, ZIP file path, OCI registry reference, or git repository.
+usage: sbx kit inspect REFERENCE [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for inspect
+    - name: json
+      default_value: "false"
+      usage: Output in JSON format
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx kit - (Experimental) Manage kit artifacts
diff --git a/data/sbx_cli/sbx_kit_pack.yaml b/data/sbx_cli/sbx_kit_pack.yaml
new file mode 100644
index 000000000000..7c5d37569fdc
--- /dev/null
+++ b/data/sbx_cli/sbx_kit_pack.yaml
@@ -0,0 +1,23 @@
+name: sbx kit pack
+synopsis: Package a directory as a kit artifact
+experimental: true
+description: |-
+    Validate and package a kit artifact directory as a ZIP file.
+
+    The directory must contain a valid spec.yaml and an optional files/ directory.
+usage: sbx kit pack DIRECTORY [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for pack
+    - name: output
+      shorthand: o
+      usage: 'Output ZIP file path (default: <name>.zip)'
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx kit - (Experimental) Manage kit artifacts
diff --git a/data/sbx_cli/sbx_kit_provenance.yaml b/data/sbx_cli/sbx_kit_provenance.yaml
new file mode 100644
index 000000000000..07a876d49427
--- /dev/null
+++ b/data/sbx_cli/sbx_kit_provenance.yaml
@@ -0,0 +1,53 @@
+name: sbx kit provenance
+synopsis: Show the SLSA provenance attached to a kit
+experimental: true
+description: |-
+    Print the SLSA provenance attestation attached to an OCI kit.
+
+    Provenance is attached by `sbx kit push` as an OCI referrer of the kit
+    manifest. It records the kit's content digests, the sandbox image its spec
+    declares, and the source git commit the kit was pushed from.
+
+    Provenance pushed without --sign is unsigned: it is printed but marked
+    UNSIGNED, because anyone with push access to the repository could have
+    written it. To verify a signed attestation, pass --key for a key-based
+    signature, or --certificate-identity (or --certificate-identity-regexp)
+    together with --certificate-oidc-issuer (or its regexp form) for a keyless
+    one; only attestations that verify and whose subject matches the kit's own
+    digest are reported as VERIFIED.
+usage: sbx kit provenance REFERENCE [flags]
+options:
+    - name: certificate-identity
+      usage: Exact keyless signer identity (certificate SAN)
+    - name: certificate-identity-regexp
+      usage: Keyless signer identity regexp (certificate SAN)
+    - name: certificate-oidc-issuer
+      usage: Exact keyless OIDC issuer
+    - name: certificate-oidc-issuer-regexp
+      usage: Keyless OIDC issuer regexp
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for provenance
+    - name: insecure-ignore-tlog
+      default_value: "false"
+      usage: |
+        Do not require a Rekor transparency-log entry (for private keyless signatures)
+    - name: key
+      usage: Public key for key-based verification (PEM)
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Show provenance (unsigned attestations are printed as-is)
+      sbx kit provenance ghcr.io/org/my-kit:1.0
+
+      # Verify a signed attestation before printing it
+      sbx kit provenance \
+        --certificate-identity user@example.com \
+        --certificate-oidc-issuer https://accounts.google.com \
+        ghcr.io/org/my-kit:1.0
+see_also:
+    - sbx kit - (Experimental) Manage kit artifacts
diff --git a/data/sbx_cli/sbx_kit_pull.yaml b/data/sbx_cli/sbx_kit_pull.yaml
new file mode 100644
index 000000000000..1440d608a268
--- /dev/null
+++ b/data/sbx_cli/sbx_kit_pull.yaml
@@ -0,0 +1,32 @@
+name: sbx kit pull
+synopsis: Pull a kit artifact from an OCI registry
+experimental: true
+description: |-
+    Pull a kit artifact from an OCI registry and save its layer payload to a file.
+
+    The reference should be in the format "registry/repo:tag" or
+    "registry/repo@sha256:digest" (e.g., "ghcr.io/myorg/my-plugin:1.0").
+
+    The file extension is chosen automatically based on the kit's format:
+      schemaVersion: "1"  → <name>.zip      (legacy ZIP archive)
+      schemaVersion: "2"  → <name>.tar.gz   (standard OCI tar+gzip layer)
+
+    The registry must support HTTPS.
+
+    Authentication: sbx registry secrets (sbx secret set --registry) take priority, falling back to the Docker credential store.
+usage: sbx kit pull REFERENCE [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for pull
+    - name: output
+      shorthand: o
+      usage: 'Output file path (default: derived from reference + format)'
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx kit - (Experimental) Manage kit artifacts
diff --git a/data/sbx_cli/sbx_kit_push.yaml b/data/sbx_cli/sbx_kit_push.yaml
new file mode 100644
index 000000000000..9b4a6ac355d5
--- /dev/null
+++ b/data/sbx_cli/sbx_kit_push.yaml
@@ -0,0 +1,57 @@
+name: sbx kit push
+synopsis: Push a kit artifact to an OCI registry
+experimental: true
+description: |-
+    Package and push a kit artifact directory to an OCI registry.
+
+    The directory must contain a valid spec.yaml. The reference should be
+    in the format "registry/repo:tag" (e.g., "ghcr.io/myorg/my-plugin:1.0").
+
+    The OCI artifact format is selected from the kit's spec.yaml:
+      schemaVersion: "1"  → legacy ZIP-based artifact
+      schemaVersion: "2"  → v2 tar+gzip layer with the spec in the manifest
+                            config blob and standard OCI annotations (so
+                            distribution tooling can read kit metadata
+                            without pulling layers)
+
+    With --sign, the pushed manifest is signed and the Sigstore bundle is
+    attached to the kit as an OCI referrer. Signing is keyless (Fulcio +
+    Rekor) unless --key is given for key-based signing.
+
+    Every push also attaches a SLSA provenance attestation as an OCI
+    referrer, recording the kit's content digests, the declared sandbox
+    image, and the source git commit when the directory is a working tree.
+    The provenance is unsigned unless --sign is given, in which case it is
+    signed as a DSSE in-toto attestation with the same identity or key.
+
+    Authentication uses the Docker credential store.
+usage: sbx kit push DIRECTORY REFERENCE [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for push
+    - name: identity-token
+      usage: |
+        OIDC identity token for keyless signing; defaults to the ambient CI provider, then an interactive browser login
+    - name: identity-token-file
+      usage: |
+        File holding the OIDC identity token; keeps it out of the process arguments
+    - name: key
+      usage: |
+        Private key for key-based signing (PEM); omit for keyless signing
+    - name: sign
+      default_value: "false"
+      usage: |
+        Sign the pushed kit and attach the signature as an OCI referrer
+    - name: tlog-upload
+      default_value: "true"
+      usage: |
+        Upload the keyless signature to the Rekor transparency log; set false for private kits
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx kit - (Experimental) Manage kit artifacts
diff --git a/data/sbx_cli/sbx_kit_sign.yaml b/data/sbx_cli/sbx_kit_sign.yaml
new file mode 100644
index 000000000000..7319af55f301
--- /dev/null
+++ b/data/sbx_cli/sbx_kit_sign.yaml
@@ -0,0 +1,62 @@
+name: sbx kit sign
+synopsis: Sign a kit artifact
+experimental: true
+description: |-
+    Sign a kit artifact with cosign-compatible Sigstore signatures.
+
+    For a local directory, a detached signature bundle is written to
+    kit.sig.bundle next to spec.yaml. For an OCI reference, the
+    signature is attached to the kit manifest as an OCI referrer.
+
+    Signing is keyless by default (Fulcio + Rekor), which requires an OIDC
+    identity token. In CI the token is minted automatically by the detected
+    platform (GitHub Actions, Buildkite, GCP, SPIFFE, or a projected
+    service-account token on disk). Elsewhere, supply one with
+    --identity-token-file or --identity-token, or complete an interactive
+    browser login. Prefer the file form: process arguments are readable by
+    other local users and are recorded in shell history. A token is never
+    read from SIGSTORE_ID_TOKEN, so it cannot be chosen by anything that can
+    set an environment variable. Use --key for key-based signing with an
+    unencrypted PEM private key.
+
+    For private kits whose signing event must not leak to a public log, pass
+    --tlog-upload=false to skip the Rekor transparency log. This only affects
+    keyless signing (key-based signing never uploads to Rekor) and requires
+    the signing config to provide a timestamp authority so the signature stays
+    verifiable after the short-lived certificate expires. For fully offline,
+    private signing, prefer key-based signing with --key.
+usage: sbx kit sign REFERENCE [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for sign
+    - name: identity-token
+      usage: |
+        OIDC identity token for keyless signing; defaults to the ambient CI provider, then an interactive browser login
+    - name: identity-token-file
+      usage: |
+        File holding the OIDC identity token; keeps it out of the process arguments
+    - name: key
+      usage: |
+        Private key for key-based signing (PEM); omit for keyless signing
+    - name: tlog-upload
+      default_value: "true"
+      usage: |
+        Upload the keyless signature to the Rekor transparency log; set false for private kits
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Keyless-sign a local kit directory
+      sbx kit sign ./my-kit/
+
+      # Key-based sign an OCI kit
+      sbx kit sign --key cosign.key ghcr.io/org/my-kit:1.0
+
+      # Keyless-sign without uploading to the public transparency log
+      sbx kit sign --tlog-upload=false ghcr.io/org/private-kit:1.0
+see_also:
+    - sbx kit - (Experimental) Manage kit artifacts
diff --git a/data/sbx_cli/sbx_kit_validate.yaml b/data/sbx_cli/sbx_kit_validate.yaml
new file mode 100644
index 000000000000..f11453753d1f
--- /dev/null
+++ b/data/sbx_cli/sbx_kit_validate.yaml
@@ -0,0 +1,20 @@
+name: sbx kit validate
+synopsis: Validate a kit artifact
+experimental: true
+description: |-
+    Validate that a directory or ZIP file is a valid kit artifact.
+
+    The reference can be a local directory, ZIP file path, or git repository.
+usage: sbx kit validate REFERENCE [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for validate
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx kit - (Experimental) Manage kit artifacts
diff --git a/data/sbx_cli/sbx_kit_verify.yaml b/data/sbx_cli/sbx_kit_verify.yaml
new file mode 100644
index 000000000000..8c5552fb362f
--- /dev/null
+++ b/data/sbx_cli/sbx_kit_verify.yaml
@@ -0,0 +1,57 @@
+name: sbx kit verify
+synopsis: Verify a kit artifact's signature
+experimental: true
+description: |-
+    Verify a kit artifact's cosign-compatible signature.
+
+    For a local directory, the kit.sig.bundle sidecar is checked
+    against the kit's content. For a git reference, the repository is cloned and
+    its committed kit.sig.bundle sidecar is checked the same way.
+    For an OCI reference, signatures attached as OCI referrers are checked against
+    the kit manifest.
+
+    Use --key to verify a key-based signature against a PEM public key. For
+    keyless signatures, supply the accepted signer identity with
+    --certificate-identity (or --certificate-identity-regexp) and
+    --certificate-oidc-issuer (or --certificate-oidc-issuer-regexp).
+
+    Pass --insecure-ignore-tlog to verify a private keyless signature made
+    with --tlog-upload=false: it drops the requirement for a Rekor
+    transparency-log entry and relies on the timestamp-authority timestamp
+    instead. It has no effect on key-based verification.
+usage: sbx kit verify REFERENCE [flags]
+options:
+    - name: certificate-identity
+      usage: Exact keyless signer identity (certificate SAN)
+    - name: certificate-identity-regexp
+      usage: Keyless signer identity regexp (certificate SAN)
+    - name: certificate-oidc-issuer
+      usage: Exact keyless OIDC issuer
+    - name: certificate-oidc-issuer-regexp
+      usage: Keyless OIDC issuer regexp
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for verify
+    - name: insecure-ignore-tlog
+      default_value: "false"
+      usage: |
+        Do not require a Rekor transparency-log entry (for private keyless signatures)
+    - name: key
+      usage: Public key for key-based verification (PEM)
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Verify a key-based signature
+      sbx kit verify --key cosign.pub ghcr.io/org/my-kit:1.0
+
+      # Verify a keyless signature by identity
+      sbx kit verify \
+        --certificate-identity user@example.com \
+        --certificate-oidc-issuer https://accounts.google.com \
+        ./my-kit/
+see_also:
+    - sbx kit - (Experimental) Manage kit artifacts
diff --git a/data/sbx_cli/sbx_login.yaml b/data/sbx_cli/sbx_login.yaml
new file mode 100644
index 000000000000..4c3c996e03a8
--- /dev/null
+++ b/data/sbx_cli/sbx_login.yaml
@@ -0,0 +1,20 @@
+name: sbx login
+synopsis: Sign in to Docker
+usage: sbx login [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for login
+    - name: password-stdin
+      default_value: "false"
+      usage: Read password or access token from stdin
+    - name: username
+      usage: Docker username for non-interactive login
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_logout.yaml b/data/sbx_cli/sbx_logout.yaml
new file mode 100644
index 000000000000..aaba60ee737b
--- /dev/null
+++ b/data/sbx_cli/sbx_logout.yaml
@@ -0,0 +1,19 @@
+name: sbx logout
+synopsis: Stop all running sandboxes and sign out of Docker
+usage: sbx logout [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for logout
+    - name: "yes"
+      shorthand: "y"
+      default_value: "false"
+      usage: Skip confirmation prompt
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_ls.yaml b/data/sbx_cli/sbx_ls.yaml
new file mode 100644
index 000000000000..51f664b2744f
--- /dev/null
+++ b/data/sbx_cli/sbx_ls.yaml
@@ -0,0 +1,24 @@
+name: sbx ls
+synopsis: List sandboxes
+description: |
+    List all sandboxes with their agent, status, published ports, and workspace.
+usage: sbx ls [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for ls
+    - name: json
+      default_value: "false"
+      usage: Output in JSON format
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Only display sandbox names
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_mcp.yaml b/data/sbx_cli/sbx_mcp.yaml
new file mode 100644
index 000000000000..9136744af8d9
--- /dev/null
+++ b/data/sbx_cli/sbx_mcp.yaml
@@ -0,0 +1,23 @@
+name: sbx mcp
+synopsis: Manage MCP servers
+description: |
+    Register and manage MCP servers for use with sandbox sessions.
+usage: sbx mcp COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for mcp
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
+    - sbx mcp add - Register an MCP server
+    - sbx mcp auth - Authorize MCP servers
+    - sbx mcp inspect - Show MCP server details
+    - sbx mcp load - Load an already-registered MCP server into a running sandbox
+    - sbx mcp ls - List MCP servers, grouped by the gateway that serves them
+    - sbx mcp rm - Remove a registered MCP server
diff --git a/data/sbx_cli/sbx_mcp_add.yaml b/data/sbx_cli/sbx_mcp_add.yaml
new file mode 100644
index 000000000000..579f5a3dff10
--- /dev/null
+++ b/data/sbx_cli/sbx_mcp_add.yaml
@@ -0,0 +1,199 @@
+name: sbx mcp add
+synopsis: Register an MCP server
+description: |-
+    Register an MCP server by name. The server is validated and its
+    specification is stored for use with sbx create/run --static-mcp.
+
+    This command only registers the server. To attach an already-registered
+    server to a running sandbox, use 'sbx mcp load'.
+
+    The --url flag accepts four input formats; the type is auto-detected:
+
+      - Remote MCP endpoint URL (https://host/mcp — talks MCP at the URL;
+        OAuth metadata is discovered via RFC 9728/8414).
+      - MCP community-registry URL (https://registry.modelcontextprotocol.io/v0/servers/<name>...)
+        — fetches the registry envelope and resolves the OCI image.
+      - Server-manifest URL (any URL returning a server.json or server.yaml
+        body shaped like the MCP community-registry schema — GitHub raw URLs,
+        internal HTTP servers, ad-hoc CDN links all work).
+      - Docker Hardened Images (DHI) image ref (dhi.io/<name>:<tag> or
+        dhi.io/<name>@sha256:... — the server.json manifest is extracted
+        from the image's in-toto attestation via the OCI Referrers API).
+
+    Other image refs (inputs without "://" that are not dhi.io, e.g.
+    docker.io/foo:tag) are no longer accepted. Use a server manifest instead.
+
+    SSRF guard and --skip-ssrf-check:
+      A --url whose host resolves to a private/RFC1918, loopback, link-local,
+      or cloud-metadata address is rejected by the SSRF guard (this protects
+      against manifest URLs that reach internal services, cloud metadata, or
+      DNS-rebinding targets). Some legitimate servers live on private networks
+      (split-horizon DNS, internal load balancers, VPN-only endpoints,
+      PrivateLink), so their public hostname resolves to a private address.
+      Pass --skip-ssrf-check to opt out of the guard for a single add when you
+      trust the host. This also disables DNS-rebinding/redirect re-checks, so
+      use it only for URLs you control.
+
+    OAuth for remote endpoints (--oauth-authorization-server / --client-id):
+      Two related options configure OAuth for a remote --url server (both are
+      only valid with --url):
+
+      --oauth-authorization-server hand-supplies the authorization-server
+      metadata for a server that publishes no well-known RFC 9728/8414 metadata
+      (e.g. Gmail). It is a local file path or an http(s) URL to a JSON document
+      conforming to the RFC 8414 oauth-authorization-server shape
+      (authorization_endpoint and token_endpoint are required). In this CLI it
+      must be accompanied by --client-id.
+
+      --client-id supplies a PRE-REGISTERED OAuth client. It may be given WITHOUT
+      --oauth-authorization-server: the server's authorization metadata is then
+      discovered normally and the supplied client is attached to it. This is the
+      right mode for a server whose discoverable metadata exposes no
+      registration_endpoint (so Dynamic Client Registration is impossible) but
+      which accepts a client id the operator registered ahead of time.
+
+      Client secrets (confidential clients):
+        There is no --client-secret flag. The secret for a confidential client
+        lives in the secret store in the global scope under the
+        service name "mcp:<server>.client_secret", and is read from there
+        whenever the server is used:
+
+          sbx secret set mcp:<server>.client_secret
+
+        Run it with no -t so the value is read from stdin instead of landing in
+        your shell history. The secret is never written to the MCP registration
+        on disk. Remove it later with 'sbx secret rm mcp:<server>.client_secret'.
+
+        The stored secret is bound to the OAuth identity (client id, issuer and
+        token endpoint) that first used it. Re-registering the same server name
+        against a different client or authorization server therefore does NOT
+        reuse it — store the secret again for the new client. To let a new
+        identity claim the existing secret, drop the recorded binding with
+        'sbx secret rm mcp:<server>.client_secret.identity'.
+
+      Two rules apply on the discovered path (they do not affect a server that
+      advertises a registration_endpoint, the hand-supplied
+      --oauth-authorization-server path, or --command servers):
+
+        - If the discovered authorization metadata has NO registration_endpoint,
+          Dynamic Client Registration is impossible, so --client-id is REQUIRED;
+          the add fails without it. This is the Slack shape (discoverable metadata,
+          no DCR, a pre-registered client).
+        - A stored client secret is REQUIRED when the server's advertised
+          token_endpoint_auth_methods_supported (RFC 8414) does NOT include "none"
+          — i.e. it accepts only confidential clients (client_secret_basic /
+          client_secret_post). Registration still succeeds without one, but the
+          add-time authorization is skipped; store the secret and run
+          'sbx mcp auth <server>' to finish. When the list includes "none" a
+          public/PKCE client is allowed and --client-id alone is enough. If the
+          server advertises no token_endpoint_auth_methods_supported at all (the
+          field is optional in RFC 8414), the requirement cannot be determined and
+          the add proceeds as usual.
+
+    Default OAuth scopes (--scope):
+      --scope records the DEFAULT set of scopes to request at consent time for a
+      remote --url OAuth server (repeatable). These are requested by 'sbx mcp auth'
+      when it is run with no --scope of its own. Scopes are validated only when the
+      authorization server advertises a supported set (RFC 8414 scopes_supported):
+      then every scope must be a member or the add fails naming the offending
+      scope(s). If the server advertises no supported set (the field is optional in
+      RFC 8414), the requested scopes are accepted as given. --scope applies both to
+      a hand-supplied override and to a plain --url server whose OAuth metadata is
+      discovered.
+
+    Alternative input — local stdio command (--command + --args):
+      The command runs as a subprocess on the HOST, outside the sandbox.
+
+      WARNING: Local servers are for ad-hoc development only. They have
+      no identity, no verifiable supply chain, and no sandboxing. The
+      process runs with your host user's full permissions — it can read
+      your filesystem, access your network, and call any API your user
+      can. Do not use --command with untrusted executables.
+usage: sbx mcp add <name> (--url <url> | --command <cmd>) [flags]
+options:
+    - name: args
+      default_value: '[]'
+      usage: Command-line arguments for the command
+    - name: client-id
+      usage: |
+        OAuth client id for a pre-registered client (with --url; may be used with or without --oauth-authorization-server). A confidential client's secret comes from 'sbx secret set mcp:<server>.client_secret'
+    - name: command
+      usage: Executable to run for a local stdio server
+    - name: dir
+      usage: Working directory (cwd) for a --command host server
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for add
+    - name: local
+      default_value: "false"
+      usage: Run registry OCI server locally via docker run
+    - name: oauth-authorization-server
+      usage: |
+        Path or http(s) URL to an RFC 8414 oauth-authorization-server metadata JSON document
+    - name: scope
+      default_value: '[]'
+      usage: |
+        Default OAuth scope to request at consent time (repeatable; must be advertised by the server's authorization metadata). Applies to --url remote OAuth servers.
+    - name: skip-ssrf-check
+      default_value: "false"
+      usage: |
+        Disable the SSRF guard for this add: allow a --url whose host resolves to a private/metadata address (operator asserts the host is trusted)
+    - name: skip_auth
+      default_value: "false"
+      usage: |
+        Register an OAuth server without starting the hosted OAuth flow
+    - name: url
+      usage: |
+        MCP server manifest URL, remote endpoint URL, or dhi.io image ref
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Remote MCP endpoint (OAuth auto-detected)
+      sbx mcp add notion --url https://mcp.notion.com/mcp
+      sbx mcp add linear --url https://mcp.linear.app/mcp
+
+      # MCP community-registry URL
+      sbx mcp add fetch --url https://registry.modelcontextprotocol.io/v0/servers/fetch-mcp/versions/latest
+
+      # Plain server-manifest URL (server.json / server.yaml)
+      sbx mcp add opine --url https://example.com/mcp/opine/server.yaml
+
+      # Docker Hardened Image (manifest is extracted from the image attestation)
+      sbx mcp add fetch --url dhi.io/fetch-mcp:latest
+
+      # Registry URL, local mode (runs on host via docker run; stdio packages only)
+      sbx mcp add fetch --local --url https://registry.modelcontextprotocol.io/v0/servers/fetch-mcp/versions/latest
+
+      # Private-network endpoint (host resolves to a private address) — opt out of the SSRF guard
+      sbx mcp add internal --url https://maas.prd.astra.example.com/mcp --skip-ssrf-check
+
+      # Remote endpoint with a hand-supplied OAuth override (server publishes no
+      # well-known OAuth metadata): --oauth-authorization-server is a path or
+      # http(s) URL to an RFC 8414 metadata document, --client-id the OAuth client id
+      sbx mcp add acme --url https://mcp.acme.com/mcp --oauth-authorization-server ./acme-as.json --client-id my-client
+
+      # Pre-registered client on a DISCOVERABLE server that has no registration
+      # endpoint — no --oauth-authorization-server needed (metadata is discovered)
+      sbx mcp add slack --url https://slack.example.com/mcp --client-id my-preregistered-client
+
+      # Confidential client — store the secret first (prompted, never in argv or
+      # shell history), then register; the secret is read from the secret store
+      sbx secret set mcp:slack.client_secret
+      sbx mcp add slack --url https://slack.example.com/mcp --client-id my-preregistered-client
+
+      # Record default OAuth scopes to request at consent time (must be advertised
+      # by the server's authorization metadata; repeat --scope for each one)
+      sbx mcp add acme --url https://mcp.acme.com/mcp --scope read --scope write
+
+      # Local stdio command (runs on host — development only)
+      sbx mcp add github --command npx --args @modelcontextprotocol/server-github
+      sbx mcp add postgres --command docker --args "run,-i,--rm,mcp/postgres"
+
+      # Local stdio command with a working directory (cwd) for the host process
+      sbx mcp add local-fs --command node --args server.js --dir /srv/data
+see_also:
+    - sbx mcp - Manage MCP servers
diff --git a/data/sbx_cli/sbx_mcp_auth.yaml b/data/sbx_cli/sbx_mcp_auth.yaml
new file mode 100644
index 000000000000..1271b8c91b47
--- /dev/null
+++ b/data/sbx_cli/sbx_mcp_auth.yaml
@@ -0,0 +1,62 @@
+name: sbx mcp auth
+synopsis: Authorize MCP servers
+description: |-
+    Authorize registered remote MCP servers through the hosted MCP control plane.
+
+    Commands use the Docker Hub account from 'sbx login' as the request principal.
+    User and tenant identity are derived by the control plane; they are not sent in
+    the request body.
+
+    Running 'sbx mcp auth <server>' authorizes or reauthorizes one server. If the
+    stored credential is expired, sbx asks the control plane to refresh it first and
+    only falls back to interactive OAuth when refresh needs user consent. A name
+    with no local registration is resolved from the Docker MCP catalog and
+    authorized under its catalog name, so no 'sbx mcp add' is required for catalog
+    servers.
+
+    Use 'sbx mcp auth status' to inspect hosted credential status without starting
+    OAuth, and 'sbx mcp auth rm' to remove hosted credentials without removing
+    local MCP server registrations.
+
+    Pass --scope (repeatable) to authorize a specific set of scopes for this run,
+    overriding the default recorded at 'sbx mcp add' time. Scopes are validated only
+    when the server advertises a supported set (RFC 8414 scopes_supported); each
+    scope must then be a member or the command fails. If the server advertises no
+    supported set, the requested scopes are accepted as given. With no --scope and
+    no recorded default, all advertised scopes are requested.
+usage: sbx mcp auth [server-name] [flags]
+options:
+    - name: all
+      default_value: "false"
+      usage: Apply to all registered OAuth servers
+    - name: format
+      default_value: text
+      usage: 'Output format: "text" or "json"'
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for auth
+    - name: scope
+      default_value: '[]'
+      usage: |
+        OAuth scope to authorize for this run (repeatable; overrides the recorded default; must be advertised by the server's authorization metadata)
+    - name: verbose
+      default_value: "false"
+      usage: Print authorization polling progress
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      sbx mcp auth status --all
+      sbx mcp auth status notion
+      sbx mcp auth rm --all
+      sbx mcp auth rm notion
+      sbx mcp auth --all
+      sbx mcp auth notion
+      sbx mcp auth notion --scope read --scope write
+see_also:
+    - sbx mcp - Manage MCP servers
+    - sbx mcp auth rm - Remove MCP server OAuth credentials
+    - sbx mcp auth status - Show MCP server OAuth status
diff --git a/data/sbx_cli/sbx_mcp_auth_rm.yaml b/data/sbx_cli/sbx_mcp_auth_rm.yaml
new file mode 100644
index 000000000000..c2e351a8e3e7
--- /dev/null
+++ b/data/sbx_cli/sbx_mcp_auth_rm.yaml
@@ -0,0 +1,30 @@
+name: sbx mcp auth rm
+synopsis: Remove MCP server OAuth credentials
+description: |-
+    Remove hosted OAuth credentials for registered MCP servers.
+
+    This command does not remove local MCP server registrations. Use 'sbx mcp rm'
+    to remove a registration.
+usage: sbx mcp auth rm [server-name] [flags]
+options:
+    - name: all
+      default_value: "false"
+      usage: Apply to all registered OAuth servers
+    - name: format
+      default_value: text
+      usage: 'Output format: "text" or "json"'
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for rm
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      sbx mcp auth rm --all
+      sbx mcp auth rm notion
+      sbx mcp auth rm notion --format=json
+see_also:
+    - sbx mcp auth - Authorize MCP servers
diff --git a/data/sbx_cli/sbx_mcp_auth_status.yaml b/data/sbx_cli/sbx_mcp_auth_status.yaml
new file mode 100644
index 000000000000..f667b9454d84
--- /dev/null
+++ b/data/sbx_cli/sbx_mcp_auth_status.yaml
@@ -0,0 +1,29 @@
+name: sbx mcp auth status
+synopsis: Show MCP server OAuth status
+description: |-
+    Show hosted OAuth credential status for registered MCP servers.
+
+    This command does not start OAuth or refresh expired credentials.
+usage: sbx mcp auth status [server-name] [flags]
+options:
+    - name: all
+      default_value: "false"
+      usage: Apply to all registered OAuth servers
+    - name: format
+      default_value: text
+      usage: 'Output format: "text" or "json"'
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for status
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      sbx mcp auth status --all
+      sbx mcp auth status notion
+      sbx mcp auth status --all --format=json
+see_also:
+    - sbx mcp auth - Authorize MCP servers
diff --git a/data/sbx_cli/sbx_mcp_inspect.yaml b/data/sbx_cli/sbx_mcp_inspect.yaml
new file mode 100644
index 000000000000..b9490f01d089
--- /dev/null
+++ b/data/sbx_cli/sbx_mcp_inspect.yaml
@@ -0,0 +1,16 @@
+name: sbx mcp inspect
+synopsis: Show MCP server details
+usage: sbx mcp inspect <name> [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for inspect
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: '  sbx mcp inspect notion'
+see_also:
+    - sbx mcp - Manage MCP servers
diff --git a/data/sbx_cli/sbx_mcp_load.yaml b/data/sbx_cli/sbx_mcp_load.yaml
new file mode 100644
index 000000000000..90dc46aa1d88
--- /dev/null
+++ b/data/sbx_cli/sbx_mcp_load.yaml
@@ -0,0 +1,32 @@
+name: sbx mcp load
+synopsis: Load an already-registered MCP server into a running sandbox
+description: |-
+    Attach a previously-registered MCP server to a running sandbox's gateway.
+    Connected agents see the new server's tools immediately via the standard MCP
+    tools/list_changed notification — no agent restart required.
+
+    The server must already exist in the local MCP store (register first with
+    'sbx mcp add'). Both remote/hosted and local-stdio servers are supported.
+usage: sbx mcp load <name> --sandbox <sandbox> [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for load
+    - name: sandbox
+      usage: Target sandbox name (required)
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Register, then load into the running sandbox 'my-sbx'.
+      sbx mcp add notion --url https://mcp.notion.com/mcp
+      sbx mcp load notion --sandbox my-sbx
+
+      # Local stdio server.
+      sbx mcp add github --command npx --args @modelcontextprotocol/server-github
+      sbx mcp load github --sandbox my-sbx
+see_also:
+    - sbx mcp - Manage MCP servers
diff --git a/data/sbx_cli/sbx_mcp_ls.yaml b/data/sbx_cli/sbx_mcp_ls.yaml
new file mode 100644
index 000000000000..323182f9536c
--- /dev/null
+++ b/data/sbx_cli/sbx_mcp_ls.yaml
@@ -0,0 +1,25 @@
+name: sbx mcp ls
+synopsis: List MCP servers, grouped by the gateway that serves them
+description: |-
+    List registered MCP servers under the gateway that serves them.
+
+    The gateway header reports where it runs, who controls it, and whether you are
+    signed in; each server row reports its transport and whether it is usable now.
+    Servers needing authorization carry the 'sbx mcp auth' next step.
+
+    Auth status is read without starting an OAuth flow — from the local token store
+    in local data-plane mode, otherwise from the hosted control plane.
+usage: sbx mcp ls [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for ls
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: '  sbx mcp ls'
+see_also:
+    - sbx mcp - Manage MCP servers
diff --git a/data/sbx_cli/sbx_mcp_rm.yaml b/data/sbx_cli/sbx_mcp_rm.yaml
new file mode 100644
index 000000000000..86c1845233e3
--- /dev/null
+++ b/data/sbx_cli/sbx_mcp_rm.yaml
@@ -0,0 +1,16 @@
+name: sbx mcp rm
+synopsis: Remove a registered MCP server
+usage: sbx mcp rm <name> [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for rm
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: '  sbx mcp rm notion'
+see_also:
+    - sbx mcp - Manage MCP servers
diff --git a/data/sbx_cli/sbx_policy.yaml b/data/sbx_cli/sbx_policy.yaml
new file mode 100644
index 000000000000..31425e8bec5e
--- /dev/null
+++ b/data/sbx_cli/sbx_policy.yaml
@@ -0,0 +1,30 @@
+name: sbx policy
+synopsis: Manage sandbox policies
+description: |-
+    Manage persistent access policies for sandboxes.
+
+    Policies contain rules that control what sandboxes can access. Local rules
+    can apply globally across all sandboxes or be scoped to one sandbox. Use
+    subcommands to allow, deny, list, or remove rules.
+usage: sbx policy COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for policy
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
+    - sbx policy allow - Add an allow rule for sandboxes
+    - sbx policy check - Check whether policy allows an access request
+    - sbx policy deny - Add a deny rule for sandboxes
+    - sbx policy init - Initialize the global network policy
+    - sbx policy inspect - Inspect policy or rule details
+    - sbx policy log - Show sandbox policy logs
+    - sbx policy ls - List sandbox policies
+    - sbx policy reset - Reset policies to defaults
+    - sbx policy rm - Remove a policy rule
diff --git a/data/sbx_cli/sbx_policy_allow.yaml b/data/sbx_cli/sbx_policy_allow.yaml
new file mode 100644
index 000000000000..bab387669886
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_allow.yaml
@@ -0,0 +1,22 @@
+name: sbx policy allow
+synopsis: Add an allow rule for sandboxes
+description: |-
+    Add a rule that permits sandboxes to access specified resources.
+
+    Allowed resources are accessible within the selected policy scope. If a
+    resource matches both an allow and a deny rule, the deny rule takes
+    precedence.
+usage: sbx policy allow COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for allow
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx policy - Manage sandbox policies
+    - sbx policy allow network - Allow network access to specified hosts
diff --git a/data/sbx_cli/sbx_policy_allow_network.yaml b/data/sbx_cli/sbx_policy_allow_network.yaml
new file mode 100644
index 000000000000..1aa59f7010a4
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_allow_network.yaml
@@ -0,0 +1,42 @@
+name: sbx policy allow network
+synopsis: Allow network access to specified hosts
+description: |-
+    Allow sandbox network access to the specified hosts.
+
+    RESOURCES is a comma-separated list of hostnames, domains, or IP addresses.
+    Supports exact domains (example.com), wildcard subdomains (*.example.com),
+    and optional port suffixes (example.com:443). Use "**" to allow all hosts.
+
+    The rule applies globally to all sandboxes by default. Use --sandbox to add
+    the rule to policy "local" scoped to a single sandbox instead.
+usage: sbx policy allow network [--sandbox SANDBOX] RESOURCES [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for network
+    - name: sandbox
+      usage: |
+        Scope the rule to a specific sandbox (default: all sandboxes)
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Allow access to a single host (all sandboxes)
+      sbx policy allow network api.example.com
+
+      # Allow access to multiple hosts
+      sbx policy allow network "api.example.com,cdn.example.com"
+
+      # Allow a host only for a specific sandbox
+      sbx policy allow network --sandbox my-sandbox api.example.com
+
+      # Allow all subdomains of a host
+      sbx policy allow network "*.npmjs.org"
+
+      # Allow all outbound traffic
+      sbx policy allow network "**"
+see_also:
+    - sbx policy allow - Add an allow rule for sandboxes
diff --git a/data/sbx_cli/sbx_policy_check.yaml b/data/sbx_cli/sbx_policy_check.yaml
new file mode 100644
index 000000000000..a3b98ba2663e
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_check.yaml
@@ -0,0 +1,21 @@
+name: sbx policy check
+synopsis: Check whether policy allows an access request
+description: |-
+    Check whether the current sandbox policy would authorize an access request.
+
+    The check is read-only and evaluates the same daemon-side policy authorizer
+    used by sandbox network enforcement.
+usage: sbx policy check COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for check
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx policy - Manage sandbox policies
+    - sbx policy check network - Check network access to a host
diff --git a/data/sbx_cli/sbx_policy_check_network.yaml b/data/sbx_cli/sbx_policy_check_network.yaml
new file mode 100644
index 000000000000..6fb09c0a0ccd
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_check_network.yaml
@@ -0,0 +1,38 @@
+name: sbx policy check network
+synopsis: Check network access to a host
+description: |-
+    Check whether current policy allows network access to TARGET.
+
+    TARGET may be a hostname, host:port, IP literal, or URL. Bare hosts and IP
+    literals are evaluated with port 443. HTTP(S) URLs use their default ports;
+    other URL schemes must include an explicit port.
+usage: sbx policy check network [--sandbox SANDBOX] TARGET [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for network
+    - name: json
+      default_value: "false"
+      usage: Output in JSON format
+    - name: sandbox
+      usage: Evaluate in a specific sandbox policy context
+    - name: verbose
+      default_value: "false"
+      usage: Show the exact policy request fields
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Check global network policy
+      sbx policy check network api.example.com
+
+      # Check policy in a sandbox context
+      sbx policy check network --sandbox my-sandbox api.example.com:443
+
+      # Check a pasted URL and output JSON
+      sbx policy check network --json https://api.example.com/v1
+see_also:
+    - sbx policy check - Check whether policy allows an access request
diff --git a/data/sbx_cli/sbx_policy_deny.yaml b/data/sbx_cli/sbx_policy_deny.yaml
new file mode 100644
index 000000000000..2211ef9680f1
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_deny.yaml
@@ -0,0 +1,21 @@
+name: sbx policy deny
+synopsis: Add a deny rule for sandboxes
+description: |-
+    Add a rule that blocks sandboxes from accessing specified resources.
+
+    Deny rules always take precedence over allow rules. If a resource matches
+    both an allow and a deny rule, the request is blocked.
+usage: sbx policy deny COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for deny
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx policy - Manage sandbox policies
+    - sbx policy deny network - Deny network access to specified hosts
diff --git a/data/sbx_cli/sbx_policy_deny_network.yaml b/data/sbx_cli/sbx_policy_deny_network.yaml
new file mode 100644
index 000000000000..c0546f95d53c
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_deny_network.yaml
@@ -0,0 +1,35 @@
+name: sbx policy deny network
+synopsis: Deny network access to specified hosts
+description: |-
+    Block sandbox network access to the specified hosts.
+
+    RESOURCES is a comma-separated list of hostnames, domains, or IP addresses.
+    Deny rules always take precedence over allow rules.
+
+    The rule applies globally to all sandboxes by default. Use --sandbox to add
+    the rule to policy "local" scoped to a single sandbox instead.
+usage: sbx policy deny network [--sandbox SANDBOX] RESOURCES [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for network
+    - name: sandbox
+      usage: |
+        Scope the rule to a specific sandbox (default: all sandboxes)
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Block access to a host (all sandboxes)
+      sbx policy deny network ads.example.com
+
+      # Block a host only for a specific sandbox
+      sbx policy deny network --sandbox my-sandbox ads.example.com
+
+      # Block all outbound traffic
+      sbx policy deny network "**"
+see_also:
+    - sbx policy deny - Add a deny rule for sandboxes
diff --git a/data/sbx_cli/sbx_policy_init.yaml b/data/sbx_cli/sbx_policy_init.yaml
new file mode 100644
index 000000000000..a8ac9bdece17
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_init.yaml
@@ -0,0 +1,43 @@
+name: sbx policy init
+synopsis: Initialize the global network policy
+description: |-
+    Initialize the global network policy that applies to all sandboxes.
+
+    This sets the initial global network policy and must be run before adding
+    custom allow/deny rules or starting a sandbox for the first time. It is a
+    one-time setup: once initialized, use "sbx policy reset" to start over.
+
+    This is the initial global policy, not a per-sandbox default; you can change
+    it later. Per-sandbox rules, including those added by kits such as the
+    built-in agent kits, apply on top for individual sandboxes.
+
+    Available policies:
+      allow-all   All outbound network traffic is allowed
+      balanced    Typical development traffic is allowed, such as AI services and package registries
+      deny-all    All outbound network traffic is blocked
+
+    After initializing, use "sbx policy allow/deny/rm" to change the global policy.
+    Use "sbx policy reset" to clear all policies and start over.
+usage: sbx policy init <allow-all|balanced|deny-all> [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for init
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Initialize with the balanced policy — recommended
+      sbx policy init balanced
+
+      # Allow all traffic
+      sbx policy init allow-all
+
+      # Block everything, then allow specific sites
+      sbx policy init deny-all
+      sbx policy allow network api.example.com:443
+see_also:
+    - sbx policy - Manage sandbox policies
diff --git a/data/sbx_cli/sbx_policy_inspect.yaml b/data/sbx_cli/sbx_policy_inspect.yaml
new file mode 100644
index 000000000000..16999f6dabe3
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_inspect.yaml
@@ -0,0 +1,32 @@
+name: sbx policy inspect
+synopsis: Inspect policy or rule details
+description: |-
+    Inspect full detail for a selected policy or rule.
+
+    The selector may be a policy ID, policy name, rule ID, or rule name.
+    Selecting a policy lists every resource with its decision, rule, and status,
+    plus a rule table showing each rule's RULE_ID, whether it is editable, and
+    either the exact removal command or the reason it is read-only. Selecting a
+    rule shows just that rule with the same editability detail. RULE_ID is the
+    identifier accepted by "sbx policy rm network --id" (local rules only). Use
+    "sbx policy ls" to find policy names and "sbx policy ls --wide" to find rule
+    IDs and resource values.
+usage: sbx policy inspect <policy-or-rule> [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for inspect
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Inspect a policy by name
+      sbx policy inspect "Developer access"
+
+      # Inspect a rule by ID
+      sbx policy inspect 2d3c1f0e-4a73-4e05-bc9d-f2f9a4b50d67
+see_also:
+    - sbx policy - Manage sandbox policies
diff --git a/data/sbx_cli/sbx_policy_log.yaml b/data/sbx_cli/sbx_policy_log.yaml
new file mode 100644
index 000000000000..39f398a94de8
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_log.yaml
@@ -0,0 +1,47 @@
+name: sbx policy log
+synopsis: Show sandbox policy logs
+description: |-
+    Show policy logs for all sandboxes, or filter by a specific sandbox name.
+
+    Displays which hosts were allowed or blocked by the proxy, along with the
+    matching rule, proxy type, and request count. Useful for debugging connectivity
+    issues or auditing network activity.
+usage: sbx policy log [SANDBOX] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for log
+    - name: json
+      default_value: "false"
+      usage: Output in JSON format
+    - name: limit
+      default_value: "0"
+      usage: Maximum number of log entries to show
+    - name: quiet
+      shorthand: q
+      default_value: "false"
+      usage: Only display log entries
+    - name: type
+      default_value: all
+      usage: |
+        Filter logs by type: "all", "network", or "filesystem" (filesystem logs are not supported yet; default "all")
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Show all policy logs
+      sbx policy log
+
+      # Show logs for a specific sandbox
+      sbx policy log my-sandbox
+
+      # Output in JSON format
+      sbx policy log --json
+
+      # Show the last 20 entries
+      sbx policy log --limit 20
+see_also:
+    - sbx policy - Manage sandbox policies
diff --git a/data/sbx_cli/sbx_policy_ls.yaml b/data/sbx_cli/sbx_policy_ls.yaml
new file mode 100644
index 000000000000..6f5f4ed8639d
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_ls.yaml
@@ -0,0 +1,69 @@
+name: sbx policy ls
+synopsis: List sandbox policies
+description: |-
+    List active sandbox policies.
+
+    Without SANDBOX, the command shows one overview row per policy with its source,
+    where it applies, and a summary of decisions by resource type. With SANDBOX, it
+    summarizes active rules that apply to that sandbox.
+
+    Use --wide to show the detailed rule-level table with separate POLICY,
+    POLICY_ID, RULE, and RULE_ID columns plus resources, status, and rule
+    metadata. RULE_ID is the identifier accepted by "sbx policy rm network --id"
+    (local rules only). Use --json for the filtered daemon response.
+
+    When remote governance is active, inactive policy rules are hidden by default.
+    Use --include-inactive to show inactive rules for troubleshooting.
+    Use "sbx policy inspect <policy-or-rule>" for full detail on a selected policy or
+    rule.
+usage: sbx policy ls [SANDBOX] [flags]
+options:
+    - name: decision
+      usage: 'Filter policies by decision: "allow" or "deny"'
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for ls
+    - name: include-inactive
+      default_value: "false"
+      usage: Show inactive policy rules hidden by remote governance
+    - name: json
+      default_value: "false"
+      usage: Output filtered policy rules as JSON
+    - name: source
+      usage: 'Filter policies by source: "local", "org", or "kit"'
+    - name: type
+      default_value: all
+      usage: |
+        Filter policies by type: "all", "network", or "filesystem" (default "all")
+    - name: wide
+      default_value: "false"
+      usage: Show detailed rule-level output with rule IDs and resources
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # List all policies
+      sbx policy ls
+
+      # List the policies that apply to one sandbox
+      sbx policy ls my-sandbox
+
+      # Show detailed rule-level rows with rule IDs and resources
+      sbx policy ls --wide
+
+      # Output filtered rules as JSON
+      sbx policy ls --json
+
+      # List only network policies
+      sbx policy ls --type network
+
+      # List organization policies that deny access
+      sbx policy ls --source org --decision deny
+
+      # Include inactive rules hidden by remote governance
+      sbx policy ls --include-inactive
+see_also:
+    - sbx policy - Manage sandbox policies
diff --git a/data/sbx_cli/sbx_policy_reset.yaml b/data/sbx_cli/sbx_policy_reset.yaml
new file mode 100644
index 000000000000..5c6e9289392d
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_reset.yaml
@@ -0,0 +1,34 @@
+name: sbx policy reset
+synopsis: Reset policies to defaults
+description: |-
+    Remove all custom policies and restart the daemon to restore defaults.
+
+    This deletes the local policy store and stops the daemon. The daemon restarts
+    automatically on the next command, then prompts you to initialize the global
+    network policy again.
+
+    If sandboxes are currently running, they will be stopped when the daemon
+    shuts down. You will be prompted for confirmation unless --force is used.
+usage: sbx policy reset [flags]
+options:
+    - name: force
+      shorthand: f
+      default_value: "false"
+      usage: Skip confirmation prompt
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for reset
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Reset policies — prompts if sandboxes are running
+      sbx policy reset
+
+      # Reset policies without confirmation
+      sbx policy reset --force
+see_also:
+    - sbx policy - Manage sandbox policies
diff --git a/data/sbx_cli/sbx_policy_rm.yaml b/data/sbx_cli/sbx_policy_rm.yaml
new file mode 100644
index 000000000000..2c7578074d55
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_rm.yaml
@@ -0,0 +1,17 @@
+name: sbx policy rm
+synopsis: Remove a policy rule
+description: Remove a previously added allow or deny rule.
+usage: sbx policy rm COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for rm
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx policy - Manage sandbox policies
+    - sbx policy rm network - Remove a network rule
diff --git a/data/sbx_cli/sbx_policy_rm_network.yaml b/data/sbx_cli/sbx_policy_rm_network.yaml
new file mode 100644
index 000000000000..bdf02c7493de
--- /dev/null
+++ b/data/sbx_cli/sbx_policy_rm_network.yaml
@@ -0,0 +1,47 @@
+name: sbx policy rm network
+synopsis: Remove a network rule
+description: |-
+    Remove a network rule by rule ID, resource, or both.
+
+    --id takes the RULE_ID value shown by "sbx policy ls --wide" and
+    "sbx policy inspect" — the rule's identifier, not its name. Passing a rule
+    name fails with an error that names the actual rule ID and, for removable
+    rules, the exact corrected command.
+
+    The rule is removed from the global policy by default. Use --sandbox to
+    remove from policy "local" scoped to a single sandbox instead.
+
+    Use "sbx policy ls --wide" to see active rule IDs and resources, or
+    "sbx policy ls --json" for the raw filtered daemon response.
+usage: sbx policy rm network [--sandbox SANDBOX] [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for network
+    - name: id
+      usage: Remove by rule ID
+    - name: resource
+      usage: Remove by resource value(s), comma-separated
+    - name: sandbox
+      usage: |
+        Scope the removal to a specific sandbox (default: global policy)
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # List rules to find the ID or resource to remove
+      sbx policy ls --wide
+
+      # Remove a global rule by resource
+      sbx policy rm network --resource api.example.com
+
+      # Remove a global rule by ID
+      sbx policy rm network --id 2d3c1f0e-4a73-4e05-bc9d-f2f9a4b50d67
+
+      # Remove a sandbox-scoped rule by resource
+      sbx policy rm network --sandbox my-sandbox --resource api.example.com
+see_also:
+    - sbx policy rm - Remove a policy rule
diff --git a/data/sbx_cli/sbx_ports.yaml b/data/sbx_cli/sbx_ports.yaml
new file mode 100644
index 000000000000..2bf7767e58e5
--- /dev/null
+++ b/data/sbx_cli/sbx_ports.yaml
@@ -0,0 +1,51 @@
+name: sbx ports
+synopsis: Manage sandbox port publishing
+description: |-
+    Manage sandbox port publishing.
+
+    List, publish, or unpublish ports for a running sandbox. Without --publish or
+    --unpublish flags, lists all published ports.
+
+    Port spec format: [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    If HOST_PORT is omitted, an ephemeral port is allocated automatically.
+    If HOST_IP is omitted, the port is bound on loopback, expanded based on
+    PROTOCOL and the sandbox's address families: tcp/udp binds both 127.0.0.1
+    and ::1 (or only 127.0.0.1 if the sandbox is IPv4-only); tcp4/udp4 binds
+    only 127.0.0.1; tcp6/udp6 binds only ::1. PROTOCOL defaults to tcp.
+    Supported protocols: tcp, tcp4, tcp6, udp, udp4, udp6.
+usage: sbx ports SANDBOX [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for ports
+    - name: json
+      default_value: "false"
+      usage: Output in JSON format (for port listing)
+    - name: publish
+      default_value: '[]'
+      usage: |
+        Publish a port (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
+    - name: unpublish
+      default_value: '[]'
+      usage: |
+        Unpublish a port (can be repeated): [HOST_IP:]HOST_PORT:SANDBOX_PORT[/PROTOCOL]
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # List published ports
+      sbx ports my-sandbox
+
+      # Publish sandbox port 8080 to an ephemeral host port
+      sbx ports my-sandbox --publish 8080
+
+      # Publish with a specific host port
+      sbx ports my-sandbox --publish 3000:8080
+
+      # Unpublish a port
+      sbx ports my-sandbox --unpublish 3000:8080
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_prune.yaml b/data/sbx_cli/sbx_prune.yaml
new file mode 100644
index 000000000000..45576ed6db65
--- /dev/null
+++ b/data/sbx_cli/sbx_prune.yaml
@@ -0,0 +1,48 @@
+name: sbx prune
+synopsis: Remove all stopped sandboxes
+description: |-
+    Remove all stopped sandboxes and their associated resources.
+
+    Only stopped sandboxes are candidates — a running sandbox is never removed,
+    which makes this safe to run habitually. Stop a sandbox first with
+    "sbx stop" if you want it pruned. To remove a specific sandbox regardless of
+    state, use "sbx rm SANDBOX".
+
+    Use --filter since=DURATION to narrow the set to sandboxes that have been
+    stopped for longer than DURATION (e.g. since=168h to keep anything stopped
+    within the last week). A sandbox whose stop time the daemon cannot report is
+    left alone, since how long it has been stopped cannot be established.
+
+    Use --dry-run to list what would be removed without removing anything.
+
+    Pruning requires confirmation; use --force to skip the confirmation prompt
+    (for non-interactive scripts) and to remove a sandbox that is in use (e.g. an
+    open SSH connection). This action cannot be undone.
+
+    Local-only: cloud sandboxes expire via their TTL.
+usage: sbx prune [flags]
+options:
+    - name: dry-run
+      default_value: "false"
+      usage: |
+        List the sandboxes that would be removed without removing them
+    - name: filter
+      default_value: '[]'
+      usage: |
+        Filter candidates (supported: since=DURATION — stopped for longer than DURATION)
+    - name: force
+      shorthand: f
+      default_value: "false"
+      usage: |
+        Skip confirmation prompts and remove even if in use (e.g. an open SSH connection)
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for prune
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_reset.yaml b/data/sbx_cli/sbx_reset.yaml
new file mode 100644
index 000000000000..66eae81408f9
--- /dev/null
+++ b/data/sbx_cli/sbx_reset.yaml
@@ -0,0 +1,46 @@
+name: sbx reset
+synopsis: Reset all sandboxes and clean up state
+description: |-
+    Reset Docker Sandboxes to a freshly-installed state.
+
+    This command will:
+    - Stop all running sandboxes gracefully (30s timeout)
+    - Clear image cache
+    - Clear all internal registries
+    - Delete all sandbox state
+    - Remove all policies
+    - Remove the managed SSH configuration
+    - Clear the Gordon assistant's sessions and history
+    - Delete all stored secrets
+    - Sign out of Docker Sandboxes
+    - Stop the daemon
+    - Remove all state, cache, and config directories
+
+    WARNING: This is destructive and cannot be undone.
+    Running agents will be terminated and their work lost.
+    Cached images will be deleted and recreated on next use.
+    Stored secrets will need to be re-entered.
+
+    Use --preserve-secrets to keep stored secrets.
+    By default, you will be prompted to confirm (y/N).
+    Use --force to skip the confirmation prompt.
+usage: sbx reset [flags]
+options:
+    - name: force
+      shorthand: f
+      default_value: "false"
+      usage: Skip confirmation prompt
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for reset
+    - name: preserve-secrets
+      default_value: "false"
+      usage: Keep stored secrets
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_rm.yaml b/data/sbx_cli/sbx_rm.yaml
new file mode 100644
index 000000000000..29e5ceb94125
--- /dev/null
+++ b/data/sbx_cli/sbx_rm.yaml
@@ -0,0 +1,32 @@
+name: sbx rm
+synopsis: Remove one or more sandboxes
+description: |-
+    Remove one or more sandboxes and all associated resources.
+
+    Stops running sandboxes, removes their containers, cleans up any Git
+    worktrees, and deletes sandbox state. This action cannot be undone.
+
+    Removal requires confirmation; use --force to skip confirmation prompts
+    (for non-interactive scripts) and to delete a sandbox that is in use
+    (e.g. an open SSH connection). Use --all to remove every sandbox.
+usage: sbx rm [SANDBOX...] [flags]
+options:
+    - name: all
+      default_value: "false"
+      usage: Remove all sandboxes
+    - name: force
+      shorthand: f
+      default_value: "false"
+      usage: |
+        Skip confirmation prompts and delete even if in use (e.g. an open SSH connection)
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for rm
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_run.yaml b/data/sbx_cli/sbx_run.yaml
new file mode 100644
index 000000000000..e80550ad9742
--- /dev/null
+++ b/data/sbx_cli/sbx_run.yaml
@@ -0,0 +1,86 @@
+name: sbx run
+synopsis: Run an agent in a sandbox
+description: |-
+    Run an agent in a sandbox, creating the sandbox if it does not already exist.
+
+    The first positional argument is the agent to run. To re-attach to an existing
+    sandbox by name, use --name; the agent positional is optional when the named
+    sandbox already exists and is read from its spec.
+
+    Pass agent arguments after the "--" separator. Additional workspaces can be
+    provided as extra arguments. Append ":ro" to mount them read-only.
+
+    To create a sandbox without attaching, use "sbx create" instead, or
+    pass --detached (-d) to print the sandbox ID and exit without opening an
+    interactive session.
+
+    Available agents: claude, codex, copilot, cursor, docker-agent, droid, gemini, kiro, opencode, shell
+usage: sbx run [flags] [AGENT] [PATH...] [-- AGENT_ARGS...]
+options:
+    - name: clone
+      default_value: "false"
+      usage: |
+        Run the agent on a private in-container clone of the host Git repository; must be set at sandbox creation time (no-op when re-attaching to an existing clone-mode sandbox)
+    - name: cpus
+      default_value: "0"
+      usage: |
+        Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs)
+    - name: deny-network
+      default_value: '[]'
+      usage: |
+        Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with `sbx policy ls <NAME>` / `sbx policy rm network --sandbox <NAME> --resource <HOST>`. Safe under centralized governance because a local deny can only narrow, never widen, egress.
+    - name: env
+      shorthand: e
+      default_value: '[]'
+      usage: |
+        Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment. Applies to the agent session, so it takes effect on a re-attach too; also baked into the sandbox when this run creates it
+    - name: env-file
+      default_value: '[]'
+      usage: |
+        Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one. Applies to the agent session, so it takes effect on a re-attach too; also baked into the sandbox when this run creates it
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for run
+    - name: kit
+      default_value: '[]'
+      experimental: true
+      usage: |
+        Kit reference (directory, ZIP, or OCI). Can be specified multiple times
+    - name: memory
+      shorthand: m
+      usage: |
+        Memory limit in binary units (e.g., 1024m, 8g). Default: 50% of host memory, max 32 GiB
+    - name: name
+      usage: 'Name for the sandbox (default: <agent>-<workdir>)'
+    - name: publish
+      shorthand: p
+      default_value: '[]'
+      usage: |
+        Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]. Applied when the sandbox is created; ignored when re-attaching (use "sbx ports")
+    - name: template
+      shorthand: t
+      usage: |
+        Container image to use for the sandbox (default: agent-specific image)
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Create and run a sandbox with claude in current directory
+      sbx run claude
+
+      # Create and run with additional workspaces (read-only)
+      sbx run claude . /path/to/docs:ro
+
+      # Re-attach to an existing sandbox by name (agent read from its spec)
+      sbx run --name existing-sandbox
+
+      # Re-attach to an existing sandbox by name and verify the expected agent
+      sbx run claude --name existing-sandbox
+
+      # Run a sandbox with agent arguments
+      sbx run claude -- --continue
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_secret.yaml b/data/sbx_cli/sbx_secret.yaml
new file mode 100644
index 000000000000..995fb119345b
--- /dev/null
+++ b/data/sbx_cli/sbx_secret.yaml
@@ -0,0 +1,34 @@
+name: sbx secret
+synopsis: Manage stored secrets
+description: |-
+    Manage stored secrets for sandbox environments.
+
+    SERVICE SECRETS (e.g. "github", "anthropic", "openai")
+      When a sandbox starts, the proxy uses stored secrets to authenticate API
+      requests on behalf of the agent. The secret is never exposed directly.
+      Scoped globally (shared across all sandboxes) or to a specific sandbox.
+
+    REGISTRY SECRETS (e.g. "ghcr.io", "myregistry.azurecr.io")
+      Used to pull private template images and kit artifacts before sandbox
+      creation. Unlike service secrets, registry credentials are host-only by
+      default. They are not injected into sandboxes unless --all-sandboxes or
+      --sandbox is set (the credential never enters the sandbox filesystem).
+      Use "sbx secret set --registry <host> --password-stdin" to store them.
+usage: sbx secret COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for secret
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
+    - sbx secret import - Import secrets detected in host environment variables
+    - sbx secret ls - List stored secrets
+    - sbx secret rm - Remove a secret
+    - sbx secret set - Create or update a secret
+    - sbx secret set-custom - (Experimental) Create or update a custom secret
diff --git a/data/sbx_cli/sbx_secret_import.yaml b/data/sbx_cli/sbx_secret_import.yaml
new file mode 100644
index 000000000000..10b8c397c77f
--- /dev/null
+++ b/data/sbx_cli/sbx_secret_import.yaml
@@ -0,0 +1,62 @@
+name: sbx secret import
+synopsis: Import secrets detected in host environment variables
+description: |-
+    Import secrets that sbx detects in your host environment
+    variables (e.g. OPENAI_API_KEY, ANTHROPIC_API_KEY, GH_TOKEN) into the
+    global keychain. Once imported, the secret is available to every
+    sandbox without needing the env var on each shell.
+
+    Each detected env var is offered interactively with a Y/n prompt and a
+    last-4-char preview of the value. Existing stored entries are never
+    overwritten silently:
+
+      - Interactive mode prompts for confirmation before overwriting.
+      - --all imports new entries without prompting but SKIPS overwrites
+        (use --force when you actually want to replace stored values).
+      - --force imports unconditionally, including overwriting.
+
+    Services that already have an OAuth token configured (e.g. anthropic
+    after `sbx run claude … -- auth login`) are skipped: the OAuth token
+    takes precedence at runtime so any api-key import would never be used.
+    Run `sbx secret rm <service>` first if you want to switch from
+    OAuth to api-key auth.
+
+    Available services: anthropic, cursor, droid, github, google, groq, mistral, nebius, openai, openrouter, xai
+usage: sbx secret import [SERVICE] [flags]
+options:
+    - name: all
+      default_value: "false"
+      usage: Import every detected env var without prompting
+    - name: dry-run
+      default_value: "false"
+      usage: Show what would be imported without writing
+    - name: force
+      shorthand: f
+      default_value: "false"
+      usage: Overwrite an existing stored entry without confirmation
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for import
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Walk every detected env var, prompting before each import
+      sbx secret import
+
+      # Import only the openai service (uses OPENAI_API_KEY)
+      sbx secret import openai
+
+      # Non-interactive: import everything detected without prompting
+      sbx secret import --all
+
+      # Overwrite an existing stored entry without confirmation
+      sbx secret import openai --force
+
+      # Preview what would be imported without writing
+      sbx secret import --dry-run
+see_also:
+    - sbx secret - Manage stored secrets
diff --git a/data/sbx_cli/sbx_secret_ls.yaml b/data/sbx_cli/sbx_secret_ls.yaml
new file mode 100644
index 000000000000..318720d5dbe3
--- /dev/null
+++ b/data/sbx_cli/sbx_secret_ls.yaml
@@ -0,0 +1,40 @@
+name: sbx secret ls
+synopsis: List stored secrets
+description: |-
+    List stored secrets across global and sandbox scopes.
+
+    With no scope flag, all stored secrets are shown. Use --global to show only
+    global secrets, or --sandbox to show only secrets scoped to one sandbox.
+usage: sbx secret ls [flags]
+options:
+    - name: global
+      shorthand: g
+      default_value: "false"
+      usage: Only list global secrets
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for ls
+    - name: sandbox
+      usage: Only list secrets for one sandbox
+    - name: service
+      usage: Filter by secret service name
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # List all secrets
+      sbx secret ls
+
+      # List only global secrets
+      sbx secret ls -g
+
+      # List secrets for a specific sandbox
+      sbx secret ls --sandbox my-sandbox
+
+      # Filter by service
+      sbx secret ls --service github
+see_also:
+    - sbx secret - Manage stored secrets
diff --git a/data/sbx_cli/sbx_secret_rm.yaml b/data/sbx_cli/sbx_secret_rm.yaml
new file mode 100644
index 000000000000..cac2f449b9aa
--- /dev/null
+++ b/data/sbx_cli/sbx_secret_rm.yaml
@@ -0,0 +1,49 @@
+name: sbx secret rm
+synopsis: Remove a secret
+usage: sbx secret rm [SERVICE] [flags]
+options:
+    - name: all-sandboxes
+      default_value: "false"
+      usage: |
+        Remove registry credentials injected into every sandbox (requires --registry)
+    - name: force
+      shorthand: f
+      default_value: "false"
+      usage: Delete without confirmation prompt
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for rm
+    - name: registry
+      usage: Registry hostname to remove pull credentials for
+    - name: sandbox
+      usage: 'Scope the removal to one sandbox (default: global)'
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Remove a global secret
+      sbx secret rm github
+
+      # Remove a sandbox-scoped secret
+      sbx secret rm openai --sandbox my-sandbox
+
+      # Remove without confirmation prompt
+      sbx secret rm github -f
+
+      # Remove OpenAI or Anthropic credential(s) from global scope (OAuth and/or API key)
+      sbx secret rm openai
+      sbx secret rm anthropic
+
+      # Remove custom secret by specifying the placeholder value
+      sbx secret rm --placeholder docker-placeholder-value
+
+      # Remove registry pull credentials (removes host-only and global entries)
+      sbx secret rm --registry ghcr.io -f
+
+      # Remove only the global (all-sandboxes) registry credential
+      sbx secret rm --all-sandboxes --registry ghcr.io -f
+see_also:
+    - sbx secret - Manage stored secrets
diff --git a/data/sbx_cli/sbx_secret_set-custom.yaml b/data/sbx_cli/sbx_secret_set-custom.yaml
new file mode 100644
index 000000000000..3668ca5380cc
--- /dev/null
+++ b/data/sbx_cli/sbx_secret_set-custom.yaml
@@ -0,0 +1,79 @@
+name: sbx secret set-custom
+synopsis: Create or update a custom secret
+experimental: true
+description: |-
+    Create or update a custom secret for a service not built into sbx.
+
+    Custom secrets work via a placeholder: the sandbox sees the placeholder value
+    instead of the real secret. When the sandbox makes an outbound request to the
+    target host, the proxy replaces the placeholder with the real secret in the
+    request headers — the secret never enters the sandbox directly.
+
+    --host accepts an exact host, IP address, or wildcard pattern. Repeat --host
+    to cover multiple unrelated domains with one secret. "*" matches a single label
+    and "**" matches any number of labels. For example "*.example.com" covers
+    "cli.example.com" and "ide.example.com" with one entry.
+
+    Custom secrets apply globally by default. Use --sandbox to scope one to a
+    specific sandbox.
+usage: sbx secret set-custom [flags]
+options:
+    - name: command
+      usage: Use a command's standard output as the secret value
+    - name: env
+      usage: Set this env var in the sandbox to the placeholder value
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for set-custom
+    - name: host
+      default_value: '[]'
+      usage: |
+        Host, IP, or wildcard pattern (e.g. *.example.com); repeatable
+    - name: no-verify
+      default_value: "false"
+      usage: Skip checking the --ref or --command source when storing it
+    - name: placeholder
+      usage: |
+        Placeholder value; use {rand} for a random suffix (e.g. sk-{rand})
+    - name: ref
+      usage: |
+        Use a 1Password op:// reference or AWS Secrets Manager ARN as the secret source
+    - name: refresh
+      usage: |
+        Secret refresh policy: on-demand (default) or after a duration
+    - name: sandbox
+      usage: 'Scope the secret to one sandbox (default: all sandboxes)'
+    - name: show-error
+      default_value: "false"
+      usage: |
+        Show resolver standard error if the initial check fails (may contain secrets)
+    - name: token
+      shorthand: t
+      usage: 'Secret value (less secure: visible in shell history)'
+    - name: value
+      usage: 'Secret value (less secure: visible in shell history)'
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Create a global custom secret. A unique placeholder is generated automatically.
+      # The sandbox env var API_KEY is set to the placeholder value; outbound requests
+      # to the host have the placeholder replaced with the real secret.
+      sbx secret set-custom --host api.example.com --env API_KEY --value secret123
+
+      # Use a wildcard host to cover multiple subdomains that share one key.
+      sbx secret set-custom --host '*.coderabbit.ai' --env CODERABBIT_API_KEY --value secret123
+
+      # Use multiple --host flags to cover unrelated domains with the same key.
+      sbx secret set-custom --host api.example.com --host api.other.io --env API_KEY --value secret123
+
+      # Scope to a specific sandbox instead of globally.
+      sbx secret set-custom --sandbox my-sandbox --host api.example.com --env API_KEY --value secret123
+
+      # Custom placeholder with {rand} suffix; the CLI prints the generated value.
+      sbx secret set-custom --host api.example.com --placeholder sk-{rand} --value secret123
+see_also:
+    - sbx secret - Manage stored secrets
diff --git a/data/sbx_cli/sbx_secret_set.yaml b/data/sbx_cli/sbx_secret_set.yaml
new file mode 100644
index 000000000000..cdad8cfabb51
--- /dev/null
+++ b/data/sbx_cli/sbx_secret_set.yaml
@@ -0,0 +1,116 @@
+name: sbx secret set
+synopsis: Create or update a secret
+description: |-
+    Create or update a service secret or registry credential.
+
+    ### Service secrets
+
+    Available services: anthropic, cursor, droid, github, google, groq, mistral, nebius, openai, openrouter, xai
+
+    Service secrets apply globally by default. Use --sandbox to scope a secret to
+    one sandbox. When SERVICE is omitted, an interactive prompt selects it.
+
+    ### Dynamic secrets
+
+    Use --ref or --command to store a secret source instead of the secret value.
+    sbx resolves the source on the host when needed and caches the value according
+    to the --refresh policy.
+
+    --ref supports 1Password op:// references and AWS Secrets Manager ARNs. The
+    corresponding op or aws CLI must be installed and authenticated. --command
+    runs a shell command and uses its standard output as the secret value.
+
+    ### Registry credentials
+
+    Use --registry to store pull credentials for a container registry. Unlike
+    service secrets, registry credentials are host-only by default:
+
+    - By default, credentials are used for template and kit pulls on the host.
+      They are never injected into a sandbox.
+    - With --all-sandboxes, credentials are used for host pulls and injected by
+      the proxy into every new sandbox's registry login. The credentials never
+      enter the sandbox.
+    - With --sandbox, credentials are injected into the specified sandbox only.
+usage: sbx secret set [SERVICE] [flags]
+options:
+    - name: all-sandboxes
+      default_value: "false"
+      usage: |
+        Inject registry credentials into every sandbox (requires --registry)
+    - name: command
+      usage: Use a command's standard output as the secret value
+    - name: force
+      shorthand: f
+      default_value: "false"
+      usage: Overwrite an existing secret when --token is used
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for set
+    - name: no-verify
+      default_value: "false"
+      usage: Skip checking the --ref or --command source when storing it
+    - name: oauth
+      default_value: "false"
+      usage: Start OAuth flow and store OAuth tokens (openai/global only)
+    - name: password-stdin
+      default_value: "false"
+      usage: |
+        Read registry password or token from stdin (use with --registry)
+    - name: ref
+      usage: |
+        Use a 1Password op:// reference or AWS Secrets Manager ARN as the secret source
+    - name: refresh
+      usage: |
+        Secret refresh policy: on-demand or after a duration (default: 55m)
+    - name: registry
+      usage: Registry hostname for pull credentials (e.g. ghcr.io)
+    - name: sandbox
+      usage: Scope the secret to one sandbox instead of its default scope
+    - name: show-error
+      default_value: "false"
+      usage: |
+        Show resolver standard error if the initial check fails (may contain secrets)
+    - name: token
+      shorthand: t
+      usage: 'Secret value (less secure: visible in shell history)'
+    - name: username
+      usage: |
+        Registry username (use with --registry; omit for token-only auth)
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Store a GitHub token globally (available to all sandboxes)
+      sbx secret set github
+
+      # Store an OpenAI key for a specific sandbox
+      sbx secret set openai --sandbox my-sandbox
+
+      # Non-interactive via stdin (e.g., from a secret manager or env var)
+      echo "$ANTHROPIC_API_KEY" | sbx secret set anthropic
+
+      # Start OpenAI OAuth flow and store global OAuth tokens
+      sbx secret set openai --oauth
+
+      # Resolve a 1Password reference at use time (requires an authenticated op CLI)
+      sbx secret set anthropic --ref 'op://Private/Anthropic/api-key'
+
+      # Resolve an AWS Secrets Manager ARN at use time (requires an authenticated aws CLI)
+      sbx secret set anthropic --ref 'arn:aws:secretsmanager:us-west-2:123456789012:secret:anthropic-api-key'
+
+      # Resolve a secret using an arbitrary command
+      sbx secret set github --command 'gh auth token'
+
+      # Registry: host-only (template/kit pulls, not injected into sandboxes)
+      gh auth token | sbx secret set --registry ghcr.io --password-stdin
+
+      # Registry: host pulls + injected into every new sandbox
+      gh auth token | sbx secret set --all-sandboxes --registry ghcr.io --password-stdin
+
+      # Registry: specific sandbox only
+      gh auth token | sbx secret set --sandbox my-sandbox --registry ghcr.io --password-stdin
+see_also:
+    - sbx secret - Manage stored secrets
diff --git a/data/sbx_cli/sbx_setup.yaml b/data/sbx_cli/sbx_setup.yaml
new file mode 100644
index 000000000000..d7175ca0a2cd
--- /dev/null
+++ b/data/sbx_cli/sbx_setup.yaml
@@ -0,0 +1,24 @@
+name: sbx setup
+synopsis: |
+    Detect host configuration and prepare Docker Sandboxes
+experimental: true
+description: |-
+    Detect what is already configured on your host and prepare Docker Sandboxes.
+
+    Agent secrets are detected from the built-in agent kit specs and the
+    env vars set on this host, and accepted secrets are imported into the global
+    secrets store (the same store as "sbx secret set").
+usage: sbx setup [COMMAND]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for setup
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
+    - sbx setup ssh - Set up SSH client config for the sandbox endpoint
diff --git a/data/sbx_cli/sbx_setup_ssh.yaml b/data/sbx_cli/sbx_setup_ssh.yaml
new file mode 100644
index 000000000000..0e37c56bd5ce
--- /dev/null
+++ b/data/sbx_cli/sbx_setup_ssh.yaml
@@ -0,0 +1,31 @@
+name: sbx setup ssh
+synopsis: Set up SSH client config for the sandbox endpoint
+experimental: true
+description: |-
+    Write a generated SSH config + known_hosts and include it from
+    ~/.ssh/config so "ssh <name>.sbx" connects with no prompts. Named app instances
+    use "ssh <name>.sbx-<app>" instead. Re-run any time; it's idempotent.
+
+    No SSH client key is needed — authentication is handled by the daemon's Unix
+    socket (OS user boundary) combined with an active Docker login. Sign in first
+    (sbx login).
+usage: sbx setup ssh [flags]
+options:
+    - name: alias
+      default_value: '*.sbx'
+      usage: ssh_config Host pattern to write
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for ssh
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      sbx setup ssh
+      ssh my-sandbox.sbx -- echo hello
+see_also:
+    - sbx setup - (Experimental) Detect host configuration and prepare Docker Sandboxes
+    - sbx setup ssh remove - Remove SSH client config for the current local app instance
diff --git a/data/sbx_cli/sbx_setup_ssh_remove.yaml b/data/sbx_cli/sbx_setup_ssh_remove.yaml
new file mode 100644
index 000000000000..6633cc7804c2
--- /dev/null
+++ b/data/sbx_cli/sbx_setup_ssh_remove.yaml
@@ -0,0 +1,16 @@
+name: sbx setup ssh remove
+synopsis: Remove SSH client config for the current local app instance
+experimental: true
+usage: sbx setup ssh remove [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for remove
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx setup ssh - Set up SSH client config for the sandbox endpoint
diff --git a/data/sbx_cli/sbx_skills.yaml b/data/sbx_cli/sbx_skills.yaml
new file mode 100644
index 000000000000..5a56085f1674
--- /dev/null
+++ b/data/sbx_cli/sbx_skills.yaml
@@ -0,0 +1,26 @@
+name: sbx skills
+synopsis: Manage skills shared across sandboxes
+experimental: true
+description: |-
+    Manage the persistent agent skills store shared across sandboxes.
+
+    Copy skills from supported agent directories on the host into the store with:
+      sbx skills import
+
+    Sandboxes with skills sharing enabled mount the store read-write. Use
+    --no-share-skills when creating a sandbox to opt out.
+usage: sbx skills COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for skills
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
+    - sbx skills import - Import skills from supported agent directories
+    - sbx skills ls - List imported skills
diff --git a/data/sbx_cli/sbx_skills_import.yaml b/data/sbx_cli/sbx_skills_import.yaml
new file mode 100644
index 000000000000..25e727b4aea7
--- /dev/null
+++ b/data/sbx_cli/sbx_skills_import.yaml
@@ -0,0 +1,48 @@
+name: sbx skills import
+synopsis: Import skills from supported agent directories
+experimental: true
+description: |-
+    Copy skills from supported agent directories on the host into the
+    persistent store shared by sandboxes.
+
+    Sources are scanned in this order (alphabetical; first wins on conflict):
+      ~/.agents/skills
+      ~/.claude/skills
+      ~/.copilot/skills
+      ~/.cursor/skills
+      ~/.factory/skills
+
+    If two sources contain a skill with the same name, the later source is skipped
+    with a warning — the first source's version is kept.
+
+    Each imported skill folder replaces any store folder of the same name (the
+    existing folder is backed up first, then the new copy is installed) so stale
+    files from a previous version cannot linger. You will be prompted before any
+    existing skill is overwritten; use --force to skip all prompts.
+
+    Symlinks at the top level are followed if they point to a directory. Symlinks
+    within skill folders and loose files at the top level are skipped.
+
+    The store lives under the sandbox state directory and is cleared by
+    'sbx reset'. Supported by Claude, Codex, Copilot, Cursor, and Droid agents.
+usage: sbx skills import [flags]
+options:
+    - name: dry-run
+      default_value: "false"
+      usage: |
+        Preview which skills would be imported without copying anything
+    - name: force
+      shorthand: f
+      default_value: "false"
+      usage: Overwrite existing skills without prompting
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for import
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx skills - (Experimental) Manage skills shared across sandboxes
diff --git a/data/sbx_cli/sbx_skills_ls.yaml b/data/sbx_cli/sbx_skills_ls.yaml
new file mode 100644
index 000000000000..a8c3c92ce99e
--- /dev/null
+++ b/data/sbx_cli/sbx_skills_ls.yaml
@@ -0,0 +1,18 @@
+name: sbx skills ls
+synopsis: List imported skills
+experimental: true
+description: |
+    List the skill folders in the central agent-skills store shared by sandboxes.
+usage: sbx skills ls [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for ls
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx skills - (Experimental) Manage skills shared across sandboxes
diff --git a/data/sbx_cli/sbx_stop.yaml b/data/sbx_cli/sbx_stop.yaml
new file mode 100644
index 000000000000..97b32c1b61de
--- /dev/null
+++ b/data/sbx_cli/sbx_stop.yaml
@@ -0,0 +1,19 @@
+name: sbx stop
+synopsis: Stop one or more sandboxes without removing them
+description: |-
+    Stop one or more running sandboxes without removing them.
+
+    Stopped sandboxes retain their state and can be restarted with "sbx run".
+usage: sbx stop SANDBOX [SANDBOX...]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for stop
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_template.yaml b/data/sbx_cli/sbx_template.yaml
new file mode 100644
index 000000000000..ca5a6cea2e23
--- /dev/null
+++ b/data/sbx_cli/sbx_template.yaml
@@ -0,0 +1,24 @@
+name: sbx template
+synopsis: Manage sandbox templates
+description: |-
+    Manage sandbox templates.
+
+    Templates are saved snapshots of sandboxes that can be reused to create new
+    sandboxes with: sbx run -t TAG AGENT [WORKSPACE]
+usage: sbx template COMMAND
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for template
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
+    - sbx template load - Load an image from a tar file into the sandbox runtime
+    - sbx template ls - List template images
+    - sbx template rm - Remove a template image
+    - sbx template save - Save a snapshot of the sandbox as a template
diff --git a/data/sbx_cli/sbx_template_load.yaml b/data/sbx_cli/sbx_template_load.yaml
new file mode 100644
index 000000000000..0aeef27e2cb6
--- /dev/null
+++ b/data/sbx_cli/sbx_template_load.yaml
@@ -0,0 +1,27 @@
+name: sbx template load
+synopsis: Load an image from a tar file into the sandbox runtime
+description: |-
+    Load an image from a tar file into the sandbox runtime's image store.
+
+    The loaded image can be used as a template for new sandboxes.
+    Tar files are typically created with: sbx template save SANDBOX TAG --output FILE
+usage: sbx template load FILE [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for load
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Load an image from a tar file
+      sbx template load /tmp/myimage.tar              # Linux/macOS
+      sbx template load C:\Users\me\myimage.tar       # Windows
+
+      # Use the loaded image as a template
+      sbx run -t myimage:v1.0 claude
+see_also:
+    - sbx template - Manage sandbox templates
diff --git a/data/sbx_cli/sbx_template_ls.yaml b/data/sbx_cli/sbx_template_ls.yaml
new file mode 100644
index 000000000000..90b28d7740aa
--- /dev/null
+++ b/data/sbx_cli/sbx_template_ls.yaml
@@ -0,0 +1,26 @@
+name: sbx template ls
+synopsis: List template images
+description: |
+    List all template images stored in the sandbox runtime's image store.
+usage: sbx template ls [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for ls
+    - name: json
+      default_value: "false"
+      usage: Output in JSON format
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # List all template images
+      sbx template ls
+
+      # Output in JSON format
+      sbx template ls --json
+see_also:
+    - sbx template - Manage sandbox templates
diff --git a/data/sbx_cli/sbx_template_rm.yaml b/data/sbx_cli/sbx_template_rm.yaml
new file mode 100644
index 000000000000..f0dd4b670cbe
--- /dev/null
+++ b/data/sbx_cli/sbx_template_rm.yaml
@@ -0,0 +1,27 @@
+name: sbx template rm
+synopsis: Remove a template image
+description: |-
+    Remove a template image from the sandbox runtime's image store.
+
+    The image can be identified by tag (e.g. "myimage:v1.0") or by image ID
+    (full or prefix, e.g. "abc123"). Use "sbx template ls" to see available
+    images and their IDs.
+usage: sbx template rm TAG|ID [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for rm
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Remove by tag
+      sbx template rm myimage:v1.0
+
+      # Remove by image ID (prefix)
+      sbx template rm abc123
+see_also:
+    - sbx template - Manage sandbox templates
diff --git a/data/sbx_cli/sbx_template_save.yaml b/data/sbx_cli/sbx_template_save.yaml
new file mode 100644
index 000000000000..cc569b3ea58c
--- /dev/null
+++ b/data/sbx_cli/sbx_template_save.yaml
@@ -0,0 +1,32 @@
+name: sbx template save
+synopsis: Save a snapshot of the sandbox as a template
+description: |-
+    Save a snapshot of the sandbox as a template.
+
+    The saved image is stored in the sandbox runtime's image store and can be
+    used as a template for new sandboxes with: sbx run -t TAG AGENT [WORKSPACE]
+
+    Use --output to also export the image to a tar file that can be shared
+    and loaded on another host with: sbx template load FILE
+usage: sbx template save SANDBOX TAG [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for save
+    - name: output
+      shorthand: o
+      usage: Also export the image to a tar file
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+example: |4-
+      # Save as a template for new sandboxes on this host
+      sbx template save my-sandbox myimage:v1.0
+
+      # Also export to a shareable tar file
+      sbx template save my-sandbox myimage:v1.0 --output /tmp/myimage.tar
+see_also:
+    - sbx template - Manage sandbox templates
diff --git a/data/sbx_cli/sbx_tui.yaml b/data/sbx_cli/sbx_tui.yaml
new file mode 100644
index 000000000000..982f8f16d24b
--- /dev/null
+++ b/data/sbx_cli/sbx_tui.yaml
@@ -0,0 +1,15 @@
+name: sbx tui
+synopsis: Open the interactive TUI dashboard
+usage: sbx tui [flags]
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for tui
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/sbx_cli/sbx_version.yaml b/data/sbx_cli/sbx_version.yaml
new file mode 100644
index 000000000000..cdab8a1f1695
--- /dev/null
+++ b/data/sbx_cli/sbx_version.yaml
@@ -0,0 +1,15 @@
+name: sbx version
+synopsis: Show Docker Sandboxes version information
+usage: sbx version
+options:
+    - name: help
+      shorthand: h
+      default_value: "false"
+      usage: help for version
+inherited_options:
+    - name: debug
+      shorthand: D
+      default_value: "false"
+      usage: Enable debug logging
+see_also:
+    - sbx - Manage AI coding agent sandboxes.
diff --git a/data/summary.yaml b/data/summary.yaml
index 3f5953caf82b..3aa4b6c78eeb 100644
--- a/data/summary.yaml
+++ b/data/summary.yaml
@@ -1,3 +1,6 @@
+AI Governance Audit Logs:
+  subscription: [AI Governance]
+  requires: Docker Sandboxes [0.39.0](/manuals/ai/sandboxes/release-notes.md) or later
 Activity logs:
   subscription: [Team, Business]
   for: Administrators
@@ -8,55 +11,67 @@ Admin orgs:
   subscription: [Team, Business]
   for: Administrators
 Air-gapped containers:
-  requires: Docker Desktop [4.29.0](/manuals/desktop/release-notes.md#4290) and later
+  subscription: [Business]
+  for: Administrators
 Allow list:
   for: Administrators
 Amazon S3 cache:
   availability: Experimental
-Ask Gordon:
-  availability: Beta
+Gordon:
+  requires: Docker Desktop [4.74.0](/manuals/desktop/release-notes.md#4740) or later
+Gordon DHI migration:
+  availability: Experimental
   requires: Docker Desktop [4.38.0](/manuals/desktop/release-notes.md#4380) or later
 Automated builds:
+  availability: Deprecated
   subscription: [Pro, Team, Business]
 Azure blob:
   availability: Experimental
 Build additional contexts:
-  requires: Docker Compose [2.17.0](/manuals/compose/releases/release-notes.md#2170) and later
+  requires: Docker Compose [2.17.0](https://github.com/docker/compose/releases/tag/v2.17.0) and later
 Build checks:
   availability: Beta
-  requires: Docker Buildx [0.15.0](/manuals/compose/releases/release-notes.md#0150) and later
+  requires: Docker Buildx [0.15.0](https://github.com/docker/buildx/releases/tag/v0.15.0) and later
 Build dockerfile inline:
-  requires: Docker Compose [2.17.0](/manuals/compose/releases/release-notes.md#2170) and later
+  requires: Docker Compose [2.17.0](https://github.com/docker/compose/releases/tag/v2.17.0) and later
 Build entitlements:
-  requires: Docker Compose [2.27.1](/manuals/compose/releases/release-notes.md#2271) and later
+  requires: Docker Compose [2.27.1](https://github.com/docker/compose/releases/tag/v2.27.1) and later
 Build multiple exporters:
-  requires: Docker Buildx [0.13.0]((/manuals/build/release-notes.md#0130) and later
+  requires: Docker Buildx [0.13.0](https://github.com/docker/buildx/releases/tag/v0.13.0) and later
+Build URL Queries:
+  requires: Docker Buildx [0.28.0](https://github.com/docker/buildx/releases/tag/v0.28.0) and later, Dockerfile [1.18.0](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.18.0) and later, and Docker Desktop [4.46.0](/manuals/desktop/release-notes.md#4460) and later
 Buildkit host:
-  requires: Docker Buildx [0.9.0](/manuals/build/release-notes.md#090) and later
+  requires: Docker Buildx [0.9.0](https://github.com/docker/buildx/releases/tag/v0.9.0) and later
 Build privileged:
-  requires: Docker Compose [2.15.0](/manuals/compose/releases/release-notes.md#2) and later
+  requires: Docker Compose [2.15.0](https://github.com/docker/compose/releases/tag/v2.15.0) and later
 Build ulimits:
-  requires: Docker Compose [2.23.1](/manuals/compose/releases/release-notes.md#2231) and later
+  requires: Docker Compose [2.23.1](https://github.com/docker/compose/releases/tag/v2.23.1) and later
+Buildx bake file:
+  requires: Docker Buildx [0.26.0](https://github.com/docker/buildx/releases/tag/v0.26.0) and later
+Buildx bake file separator:
+  requires: Docker Buildx [0.26.0](https://github.com/docker/buildx/releases/tag/v0.26.0) and later
 Buildx bake Git auth token:
-  requires: Docker Buildx [0.14.0](/manuals/build/release-notes.md#0140) and later
+  requires: Docker Buildx [0.14.0](https://github.com/docker/buildx/releases/tag/v0.14.0) and later
 Buildx bake Git SSH:
-  requires: Docker Buildx [0.14.0](/manuals/build/release-notes.md#0140) and later
+  requires: Docker Buildx [0.14.0](https://github.com/docker/buildx/releases/tag/v0.14.0) and later
 Buildx CPU profile:
-  requires: Docker Buildx [0.18.0](/manuals/build/release-notes.md#0180) and later
+  requires: Docker Buildx [0.18.0](https://github.com/docker/buildx/releases/tag/v0.18.0) and later
 Buildx Git check dirty:
-  requires: Docker Buildx [0.10.4](/manuals/build/release-notes.md#0104) and later
+  requires: Docker Buildx [0.10.4](https://github.com/docker/buildx/releases/tag/v0.10.4) and later
 Buildx Git info:
-  requires: Docker Buildx [0.10.0](/manuals/build/release-notes.md#0100) and later
+  requires: Docker Buildx [0.10.0](https://github.com/docker/buildx/releases/tag/v0.10.0) and later
 Buildx Git labels:
-  requires: Docker Buildx [0.10.0](/manuals/build/release-notes.md#0100) and later
+  requires: Docker Buildx [0.10.0](https://github.com/docker/buildx/releases/tag/v0.10.0) and later
 Buildx mem profile:
-  requires: Docker Buildx [0.18.0](/manuals/build/release-notes.md#0180) and later
+  requires: Docker Buildx [0.18.0](https://github.com/docker/buildx/releases/tag/v0.18.0) and later
 Buildx metadata provenance:
-  requires: Docker Buildx [0.14.0](/manuals/build/release-notes.md#0140) and later
+  requires: Docker Buildx [0.14.0](https://github.com/docker/buildx/releases/tag/v0.14.0) and later
 Buildx metadata warnings:
-  requires: Docker Buildx [0.16.0](/manuals/build/release-notes.md#0160) and later
+  requires: Docker Buildx [0.16.0](https://github.com/docker/buildx/releases/tag/v0.16.0) and later
 Buildx no default:
-  requires: Docker Buildx [0.10.4](/manuals/build/release-notes.md#0104) and later
+  requires: Docker Buildx [0.10.4](https://github.com/docker/buildx/releases/tag/v0.10.4) and later
+Buildx no default OCI artifact:
+  requires: Docker Buildx [0.36.1](https://github.com/docker/buildx/releases/tag/v0.36.1) and later
 Cache backend API:
   availability: Experimental
 Company:
@@ -68,90 +83,127 @@ Compliance reporting:
   requires: Docker Desktop 4.40 and later
   availability: Early Access
 Compose attach:
-  requires: Docker Compose [2.20.0](/manuals/compose/releases/release-notes.md#2200) and later
+  requires: Docker Compose [2.20.0](https://github.com/docker/compose/releases/tag/v2.20.0) and later
 Compose bridge:
-  availability: Experimental
-Config profiles:
-  requires: Docker Desktop 4.36 and later
+  requires: Docker Desktop 4.43.0 and later
 Compose dependent images:
-  requires: Docker Compose [2.22.0](/manuals/compose/releases/release-notes.md#2220) and later
+  requires: Docker Compose [2.22.0](https://github.com/docker/compose/releases/tag/v2.22.0) and later
 Compose cgroup:
-  requires: Docker Compose [2.15.0](/manuals/compose/releases/release-notes.md#2150) and later
+  requires: Docker Compose [2.15.0](https://github.com/docker/compose/releases/tag/v2.15.0) and later
 Compose develop:
-  requires: Docker Compose [2.22.0](/manuals/compose/releases/release-notes.md#2220) and later
+  requires: Docker Compose [2.22.0](https://github.com/docker/compose/releases/tag/v2.22.0) and later
 Compose driver opts:
-  requires: Docker Compose [2.27.1](/manuals/compose/releases/release-notes.md#2271) and later
+  requires: Docker Compose [2.27.1](https://github.com/docker/compose/releases/tag/v2.27.1) and later
 Compose exec:
-  requires: Docker Compose [2.32.2](/manuals/compose/releases/release-notes.md#2232) and later
+  requires: Docker Compose [2.32.2](https://github.com/docker/compose/releases/tag/v2.32.2) and later
 Compose experimental:
-  requires: Docker Compose [2.26.0](/manuals/compose/releases/release-notes.md#2260) and later
+  requires: Docker Compose [2.26.0](https://github.com/docker/compose/releases/tag/v2.26.0) and later
 Compose enable ipv4:
-  requires: Docker Compose [2.33.1](/manuals/compose/releases/release-notes.md#2331) and later
+  requires: Docker Compose [2.33.1](https://github.com/docker/compose/releases/tag/v2.33.1) and later
 Compose file watch:
-  requires: Docker Compose [2.22.0](/manuals/compose/releases/release-notes.md#2220) and later
+  requires: Docker Compose [2.22.0](https://github.com/docker/compose/releases/tag/v2.22.0) and later
 Compose format:
-  requires: Docker Compose [2.30.0](/manuals/compose/releases/release-notes.md#2300) and later
+  requires: Docker Compose [2.30.0](https://github.com/docker/compose/releases/tag/v2.30.0) and later
 Compose gpus:
-  requires: Docker Compose [2.30.0](/manuals/compose/releases/release-notes.md#2300) and later
+  requires: Docker Compose [2.30.0](https://github.com/docker/compose/releases/tag/v2.30.0) and later
 Compose gw priority:
-  requires: Docker Compose [2.33.1](/manuals/compose/releases/release-notes.md#2331) and later
+  requires: Docker Compose [2.33.1](https://github.com/docker/compose/releases/tag/v2.33.1) and later
 Compose include:
-  requires: Docker Compose [2.20.3](/manuals/compose/releases/release-notes.md#2203) and later
+  requires: Docker Compose [2.20.3](https://github.com/docker/compose/releases/tag/v2.20.3) and later
+Compose interface-name:
+  requires: Docker Compose [2.36.0](https://github.com/docker/compose/releases/tag/v2.36.0) and later
 Compose label file:
-  requires: Docker Compose [2.32.2](/manuals/compose/releases/release-notes.md#2232) and later
+  requires: Docker Compose [2.32.2](https://github.com/docker/compose/releases/tag/v2.32.2) and later
 Compose lifecycle hooks:
-  requires: Docker Compose [2.30.0](/manuals/compose/releases/release-notes.md#2300) and later
+  requires: Docker Compose [2.30.0](https://github.com/docker/compose/releases/tag/v2.30.0) and later
+Compose pre_start:
+  requires: Docker Compose [5.3.0](https://github.com/docker/compose/releases/tag/v5.3.0) and later
 Compose mac address:
-  requires: Docker Compose [2.23.2](/manuals/compose/releases/release-notes.md#2232) and later
+  requires: Docker Compose [2.23.2](https://github.com/docker/compose/releases/tag/v2.23.2) and later
 Compose menu:
-  requires: Docker Compose [2.26.0](/manuals/compose/releases/release-notes.md#2260) and later
+  requires: Docker Compose [2.26.0](https://github.com/docker/compose/releases/tag/v2.26.0) and later
+Compose models:
+  requires: Docker Compose [2.38.0](https://github.com/docker/compose/releases/tag/v2.38.0) and later
 Compose model runner:
-  requires: Docker Compose [2.35.0](/manuals/compose/releases/release-notes.md#2300) and later, and Docker Desktop 4.41 and later
+  requires: Docker Compose [2.38.0](https://github.com/docker/compose/releases/tag/v2.38.0) and later, and Docker Desktop 4.43 and later
 Compose OCI artifact:
-  requires: Docker Compose [2.34.0](/manuals/compose/releases/release-notes.md#2340) and later
+  requires: Docker Compose [2.34.0](https://github.com/docker/compose/releases/tag/v2.34.0) and later
+Compose provider services:
+  requires: Docker Compose [2.36.0](https://github.com/docker/compose/releases/tag/v2.36.0) and later
+Compose progress:
+  requires: Docker Compose [2.36.0](https://github.com/docker/compose/releases/tag/v2.36.0) and later
 Compose replace file:
-  requires: Docker Compose [2.24.4](/manuals/compose/releases/release-notes.md#2244) and later
+  requires: Docker Compose [2.24.4](https://github.com/docker/compose/releases/tag/v2.24.4) and later
 Compose required:
-  requires: Docker Compose [2.24.0](/manuals/compose/releases/release-notes.md#2271) and later
+  requires: Docker Compose [2.24.0](https://github.com/docker/compose/releases/tag/v2.24.0) and later
 Compose post start:
-  requires: Docker Compose [2.30.0](/manuals/compose/releases/release-notes.md#2300) and later
+  requires: Docker Compose [2.30.0](https://github.com/docker/compose/releases/tag/v2.30.0) and later
 Compose pre stop:
-  requires: Docker Compose [2.30.0](/manuals/compose/releases/release-notes.md#2300) and later
+  requires: Docker Compose [2.30.0](https://github.com/docker/compose/releases/tag/v2.30.0) and later
+Compose provenance:
+  requires: Docker Compose [2.39.0](https://github.com/docker/compose/releases/tag/v2.39.0) and later
 Compose uts:
-  requires: Docker Compose [2.15.1](/manuals/compose/releases/release-notes.md#2151) and later
+  requires: Docker Compose [2.15.1](https://github.com/docker/compose/releases/tag/v2.15.1) and later
 Composefile include:
-  requires: Docker Compose [2.20.0](/manuals/compose/releases/release-notes.md#2200) and later
-containerd:
-  availability: Experimental
+  requires: Docker Compose [2.20.0](https://github.com/docker/compose/releases/tag/v2.20.0) and later
+Compose sbom:
+  requires: Docker Compose [2.39.0](https://github.com/docker/compose/releases/tag/v2.39.0) and later
+Compose SDK:
+  requires: Docker Compose [5.0.0](https://github.com/docker/compose/releases/tag/v5.0.0) and later
+Custom roles:
+  subscription: [Business]
+  for: Administrators
 Dev Environments:
   availability: Beta
 Docker Build Cloud:
   subscription: [Pro, Team, Business]
 Docker CLI OpenTelemetry:
   requires: Docker Engine [26.1.0](/manuals/engine/release-notes/26.1.md#2610) and later
+Docker Offload:
+  subscription: [Docker Offload]
+  requires: Docker Desktop 4.68 or later
 docker compose alpha:
   availability: Experimental
 Docker Debug:
-  subscription: [Pro, Team, Business]
-  requires: Docker Desktop [4.33.0](/manuals/desktop/release-notes.md#4330) and later
+  requires: Docker Desktop 4.49 and later. For Docker Desktop versions 4.48.0 and earlier, you must have a Pro, Team, or Business subscription
 Docker Desktop Archlinux:
   availability: Experimental
-Docker Desktop CLI:
-  requires: Docker Desktop [4.37](/manuals/desktop/release-notes.md#4370) and later
-Docker Desktop CLI update:
-  requires: Docker Desktop 4.39 and later
-Docker Desktop CLI logs:
-  requires: Docker Desktop 4.39 and later
-Docker GitHub Copilot:
-  availability: Early Access
+Desktop logs:
+  requires: Docker Desktop [4.65](/manuals/desktop/release-notes.md#4650) or later
+Docker Hardened Images:
+  subscription: [Docker Hardened Images Select or Enterprise]
+Docker Hardened Images Enterprise:
+  subscription: [Docker Hardened Images Enterprise]
+Docker Init:
+  requires: Docker Desktop [4.27](/manuals/desktop/release-notes.md#4270) and later
 Docker Model Runner:
+  requires: Docker Engine or Docker Desktop (Windows) 4.41+ or Docker Desktop (MacOS) 4.40+
+  for: See Requirements section below
+Docker MCP Catalog and Toolkit:
+  availability: Beta
+Docker MCP Catalog:
+  availability: Beta
+Docker MCP Toolkit:
+  availability: Beta
+MCP Profiles:
+  availability: Early Access
+  requires: Docker Desktop 4.63 and later
+Docker Pass:
+  requires: Docker Desktop 4.54 and later
   availability: Beta
-  requires: Docker Desktop 4.40 and later
-  for: Docker Desktop for Mac with Apple Silicon or Windows with NVIDIA GPUs
 Docker Projects:
   availability: Beta
-Docker Init:
-  requires: Docker Desktop [4.27](/manuals/desktop/release-notes.md#4270) and later
+Docker Sandboxes sbx:
+  availability: Early Access
+Docker Sandboxes SSH:
+  availability: GA
+  requires: Docker Sandboxes 0.37.0 or later
+Docker Sandboxes:
+  availability: Experimental
+  requires: Docker Desktop [4.58](/manuals/desktop/release-notes.md#4580) or later
+Docker Sandboxes v0.12:
+  availability: Experimental
+  requires: Docker Desktop [4.61](/manuals/desktop/release-notes.md#4610) or later
 Docker Scout exceptions:
   availability: Experimental
   requires: Docker Scout CLI [1.15.0](/manuals/scout/release-notes/cli.md#1150) and later
@@ -162,12 +214,20 @@ Docker Scout health scores:
   availability: Beta
 Docker Scout Mount Permissions:
   requires: Docker Desktop [4.34.0](/manuals/desktop/release-notes.md#4340) and later
+OIDC connections:
+  subscription: [Team, Business]
+  for: Administrators
+Domain management:
+  subscription: [Business]
+  for: Administrators
 Domain audit:
   subscription: [Business]
   for: Administrators
 Enforce sign-in:
-  subscription: [Business]
+  subscription: [Team, Business]
   for: Administrators
+Gated distribution:
+  availability: Early Access
 General admin:
   for: Administrators
 GitHub Actions cache:
@@ -175,11 +235,16 @@ GitHub Actions cache:
 Hardened Docker Desktop:
   subscription: [Business]
   for: Administrators
+Disable public repositories:
+  subscription: [Business]
+  for: Administrators
 Image management:
   availability: Beta
-Import builds:
+Namespace access:
+  subscription: [Business]
+  for: Administrators
+Immutable tags:
   availability: Beta
-  requires: Docker Desktop [4.31](/manuals/desktop/release-notes.md#4310) and later
 Insights:
   subscription: [Business]
   for: Administrators
@@ -188,16 +253,18 @@ Intune:
 Jamf Pro:
   for: Administrators
 Load by default:
-  requires: Docker Buildx [0.14.0](/manuals/build/release-notes.md#0140) and later
+  requires: Docker Buildx [0.14.0](https://github.com/docker/buildx/releases/tag/v0.14.0) and later
+Evaluate policies:
+  availability: Experimental
 MSI installer:
   subscription: [Business]
-  requires: Docker Desktop [4.32](/manuals/desktop/release-notes.md#4320) and later
   for: Administrators
 OATs:
   subscription: [Team, Business]
+Pay by invoice:
+  subscription: [Team, Business]
 PKG installer:
   subscription: [Business]
-  requires: Docker Desktop [4.36](/manuals/desktop/release-notes.md#4360) and later
   for: Administrators
 Private marketplace:
   availability: Beta
@@ -215,11 +282,10 @@ SSO:
 Synchronized file sharing:
   subscription: [Pro, Team, Business]
 USB/IP support:
-  requires: Docker Desktop [4.35.0](/manuals/desktop/release-notes.md#4350) and later
   for: Docker Desktop for Mac, Linux, and Windows with the Hyper-V backend
 VMM:
-  requires: Docker Desktop [4.35.0](/manuals/desktop/release-notes.md#4350) and later
-  for: Docker Desktop on Mac with Apple Silicon
+  availability: Beta
+  requires: "Docker Desktop 4.86 or later"
 Wasm workloads:
   availability: Beta
 Wasmtime:
diff --git a/data/tags.yaml b/data/tags.yaml
new file mode 100644
index 000000000000..ab067f824068
--- /dev/null
+++ b/data/tags.yaml
@@ -0,0 +1,27 @@
+admin:
+  title: Admin
+  description: Manage Docker organizations, users, and access controls.
+ai:
+  title: AI
+  description: Build AI-powered apps, agents, and integrations with Docker.
+cicd:
+  title: CI/CD
+  description: Automate builds, tests, and deployments in your pipelines.
+databases:
+  title: Databases
+  description: Run and connect to databases in containers.
+deployment:
+  title: Deployment
+  description: Deploy containerized apps to Kubernetes and other platforms.
+labs:
+  title: Hands-on labs
+  description: Interactive, guided labs you can run directly in your browser.
+languages:
+  title: Languages & frameworks
+  description: Containerize and develop apps in your language of choice.
+security:
+  title: Security
+  description: Harden images, scan vulnerabilities, and secure your supply chain.
+testing:
+  title: Testing
+  description: Integration testing with real databases and services.
diff --git a/data/whats-new.json b/data/whats-new.json
new file mode 100644
index 000000000000..f70ab9553ee9
--- /dev/null
+++ b/data/whats-new.json
@@ -0,0 +1,132 @@
+{
+  "period_start": "2026-07-24",
+  "period_end": "2026-08-23",
+  "items": [
+    {
+      "product": "Docker Verified Publisher",
+      "title": "Join Docker Verified Publisher through self-service plans",
+      "description": "Apply for DVP Starter or Growth, complete checkout after approval, and manage publisher analytics, tracked companies, and billing.",
+      "url": "/subscription/plans/docker-verified-publisher/",
+      "published": "2026-08-20",
+      "source_prs": [25891, 25903],
+      "featured": true
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Sign and enforce trusted sandbox kits",
+      "description": "Sign kits with cosign-compatible Sigstore signatures, verify keyless or key-based signatures, and reject kits outside a trusted-signer policy.",
+      "url": "/ai/sandboxes/customize/kits/#sign-and-verify-kits",
+      "published": "2026-08-20",
+      "source_prs": [25791, 25896],
+      "featured": false
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Define reproducible sandbox environments",
+      "description": "Capture an agent, workspaces, kits, credentials, ports, and resources in a shareable .sbxenv.yaml file and manage it with sbx env.",
+      "url": "/ai/sandboxes/configuration/environment-files/",
+      "published": "2026-08-19",
+      "source_prs": [25487, 25896],
+      "featured": true
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Resolve sandbox secrets from external sources",
+      "description": "Keep references to 1Password, AWS Secrets Manager, or host commands in the secret store and resolve credentials on the host when the proxy needs them.",
+      "url": "/ai/sandboxes/configuration/credentials/#use-a-dynamic-secret-source",
+      "published": "2026-08-19",
+      "source_prs": [25785, 25896],
+      "featured": false
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Run GPU workloads in sandboxes",
+      "description": "Pass an NVIDIA GPU through to a sandbox on supported Linux hosts for GPU-accelerated agent workloads.",
+      "url": "/ai/sandboxes/configuration/gpu-passthrough/",
+      "published": "2026-08-19",
+      "source_prs": [25869],
+      "featured": false
+    },
+    {
+      "product": "Docker Hardened Images",
+      "title": "Query DHI VEX data with the GraphQL API",
+      "description": "Build automation or dashboards that query image packages, CVEs, VEX statements, and suppressed vulnerabilities by digest.",
+      "url": "/dhi/tools/api/",
+      "published": "2026-08-17",
+      "source_prs": [25836],
+      "featured": false
+    },
+    {
+      "product": "Docker Desktop",
+      "title": "Use Docker VMM on Mac and Windows",
+      "description": "Run Docker Desktop with Docker's container-optimized hypervisor on supported Mac and Windows systems.",
+      "url": "/desktop/features/vmm/",
+      "published": "2026-08-10",
+      "source_prs": [25702, 25726],
+      "featured": true
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Connect sandboxes through an MCP gateway",
+      "description": "Register local or remote MCP servers on the host, reuse them across sandboxes, and govern server and tool access with Cedar policies.",
+      "url": "/ai/sandboxes/mcp-gateway/",
+      "published": "2026-08-06",
+      "source_prs": [25559, 25707],
+      "featured": true
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Author version 2 sandbox kits",
+      "description": "Define kit setup, permissions, networking, and API key or OAuth credential requirements with the version 2 kit schema.",
+      "url": "/ai/sandboxes/customize/kit-reference/#schema-versions",
+      "published": "2026-08-06",
+      "source_prs": [25467, 25707],
+      "featured": false
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Run Claude Code with local models",
+      "description": "Route Claude Code sandbox requests to the bundled local-model server or an existing Ollama installation.",
+      "url": "/ai/sandboxes/agents/claude-code/#use-a-local-model",
+      "published": "2026-08-06",
+      "source_prs": [25641, 25707],
+      "featured": false
+    },
+    {
+      "product": "Docker AI Governance",
+      "title": "Search and forward audit events",
+      "description": "Search and export policy decisions from Docker Cloud, or forward events to Splunk Cloud, Dynatrace, and Datadog.",
+      "url": "/ai/sandboxes/governance/audit/",
+      "published": "2026-08-03",
+      "source_prs": [25679, 25687, 25887],
+      "featured": false
+    },
+    {
+      "product": "Docker Desktop",
+      "title": "Install from the Microsoft Store without administrator privileges",
+      "description": "Fresh Microsoft Store installations on Windows use per-user mode by default.",
+      "url": "/desktop/release-notes/#4850",
+      "published": "2026-08-03",
+      "source_prs": [25665],
+      "featured": false
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Share agent skills across sandboxes",
+      "description": "Import skills from supported host agents into a persistent store that sandboxes can share.",
+      "url": "/ai/sandboxes/workflows/agent-skills/",
+      "published": "2026-07-24",
+      "source_prs": [25588],
+      "featured": false
+    },
+    {
+      "product": "Docker Sandboxes",
+      "title": "Connect editors and desktop apps over SSH",
+      "description": "Use a sandbox from VS Code, Cursor, Claude Desktop, ChatGPT, or another SSH-capable tool.",
+      "url": "/ai/sandboxes/integrations/",
+      "published": "2026-07-24",
+      "source_prs": [25557],
+      "featured": true
+    }
+  ]
+}
diff --git a/docker-bake.hcl b/docker-bake.hcl
index dbbf1d568ccf..b693439a542d 100644
--- a/docker-bake.hcl
+++ b/docker-bake.hcl
@@ -14,6 +14,10 @@ variable "DRY_RUN" {
   default = null
 }
 
+variable "GITHUB_ACTIONS" {
+  default = null
+}
+
 group "default" {
   targets = ["release"]
 }
@@ -36,7 +40,7 @@ target "release" {
 }
 
 group "validate" {
-  targets = ["lint", "test", "unused-media", "test-go-redirects", "dockerfile-lint", "path-warnings"]
+  targets = ["lint", "test", "unused-media", "test-go-redirects", "dockerfile-lint", "validate-vendor"]
 }
 
 target "test" {
@@ -51,6 +55,15 @@ target "lint" {
   provenance = false
 }
 
+target "vale" {
+  target = "vale"
+  args = {
+    GITHUB_ACTIONS = GITHUB_ACTIONS
+  }
+  output = ["./tmp"]
+  provenance = false
+}
+
 target "unused-media" {
   target = "unused-media"
   output = ["type=cacheonly"]
@@ -63,13 +76,15 @@ target "test-go-redirects" {
   provenance = false
 }
 
-target "dockerfile-lint" {
-  call = "check"
+target "releaser-test" {
+  context = "hack/releaser"
+  target = "releaser-test"
+  output = ["type=cacheonly"]
+  provenance = false
 }
 
-target "path-warnings" {
-  target = "path-warnings"
-  output = ["type=cacheonly"]
+target "dockerfile-lint" {
+  call = "check"
 }
 
 #
@@ -117,14 +132,6 @@ target "_common-aws" {
   provenance = false
 }
 
-target "aws-s3-update-config" {
-  inherits = ["_common-aws"]
-  context = "hack/releaser"
-  target = "aws-s3-update-config"
-  no-cache-filter = ["aws-update-config"]
-  output = ["type=cacheonly"]
-}
-
 target "aws-lambda-invoke" {
   inherits = ["_common-aws"]
   context = "hack/releaser"
@@ -157,6 +164,11 @@ target "vendor" {
   provenance = false
 }
 
+target "validate-vendor" {
+  target = "validate-vendor"
+  output = ["type=cacheonly"]
+}
+
 variable "UPSTREAM_MODULE_NAME" {
   default = null
 }
@@ -176,4 +188,4 @@ target "validate-upstream" {
   target = "validate-upstream"
   output = ["type=cacheonly"]
   provenance = false
-}
+}
\ No newline at end of file
diff --git a/docs_engineer.yml b/docs_engineer.yml
new file mode 100644
index 000000000000..e3105c574ada
--- /dev/null
+++ b/docs_engineer.yml
@@ -0,0 +1,311 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/docker/docker-agent/refs/heads/main/agent-schema.json
+agents:
+  root:
+    model: opus
+    description: Docker docs platform engineer for tooling and infrastructure
+    instruction: |
+      <objective>
+      Build and maintain the Docker documentation platform. Handle Hugo templates
+      and shortcodes, frontend tooling (Tailwind CSS v4, Alpine.js), build system
+      (Docker Bake), CI/CD workflows, and infrastructure.
+      </objective>
+
+      <context>
+      ## Directory structure
+      - content/ - Documentation content (Markdown)
+      - layouts/ - Hugo templates (baseof.html, shortcodes/, partials/)
+      - assets/ - CSS and JavaScript source
+      - data/ - YAML data for CLI references and configuration
+      - static/ - Static files (images, fonts)
+      - _vendor/ - Vendored Hugo modules (read-only)
+      - hack/ - Build scripts and utilities
+
+      ## Technical Stack
+
+      - Hugo static site generator
+      - Tailwind CSS v4 (standalone CLI, not PostCSS)
+      - Alpine.js v3.14 with plugins (collapse, focus, persist)
+      - Material Symbols for icons
+
+      ### Hugo configuration
+      - URL transformation: /manuals prefix removed from content/manuals/
+      - Hugo modules vendor content from upstream repositories
+      - Vendored content in _vendor/ directory (read-only)
+      - CLI reference data in data/ directories (generated from upstream)
+
+      ### Build system
+      - Docker Buildx Bake as primary orchestrator
+      - Multi-stage Dockerfile with clear separation
+      - npm for frontend dependencies
+      - Hugo for site generation
+      - Pagefind for client-side search
+
+      ### CI/CD
+      - GitHub Actions for builds and deployment
+      - AWS S3 + CloudFront for hosting
+      - Lambda@Edge for redirects
+      - OIDC authentication (no long-lived credentials)
+      - Two environments: main (production), lab (staging)
+      </context>
+
+      <process>
+      1. Understand the request
+         What needs to be built, fixed, or improved? Is this a template,
+         shortcode, styling, build configuration, or infrastructure change?
+
+      2. Explore existing patterns
+         Use filesystem tools to find related code:
+         - Templates: layouts/, layouts/shortcodes/, layouts/partials/
+         - Styles: assets/css/
+         - Scripts: assets/js/
+         - Build: docker-bake.hcl, Dockerfile
+         - CI/CD: .github/workflows/
+         - Data: data/ directory
+
+      3. Plan the implementation
+         Consider:
+         - How does this fit with existing architecture?
+         - What files need to be modified?
+         - Are there similar patterns to follow?
+         - Will this affect the build or deployment?
+
+      4. Implement the changes
+         Write code following established patterns. Test locally when possible.
+
+      5. Test and validate
+         Use the build tool to build the site, then use the validate tool to
+         check for issues
+
+      6. Document if needed
+         Update technical documentation or comments for complex changes.
+      </process>
+
+      <rules>
+        <templates>
+        - Follow Go template syntax: {{ ... }}
+        - Shortcodes use {{< shortcode >}} not {{% shortcode %}}
+        - Access page context: .Page, .Inner, .Params
+        - Use partials for reusable components: {{ partial "name.html" . }}
+        - Use Hugo functions: resources.Get, resources.Match, dict, slice
+        - Check for nil before accessing: {{ with .Param "key" }}...{{ end }}
+        </templates>
+
+        <styling>
+        - Entry point: assets/css/style.css
+        - Theme configuration: assets/css/theme.css with @theme inline
+        - Custom properties defined with CSS variables
+        - Class scanning from hugo_stats.json (purging)
+        - Use @layer utilities for custom utilities
+        - Typography plugin: prose classes for content
+        - Dark mode: use dark: prefix for dark theme styles
+        </styling>
+
+        <interactivity>
+        - Initialize with x-data on parent element
+        - Use x-init for setup, x-show for visibility
+        - State management: Alpine.store() for global state
+        - Persist with x-persist directive (uses localStorage)
+        - Event handling: @click, @change, @input
+        - Use $refs for DOM access, $dispatch for events
+        - Combine with Hugo: generate x-data from page data
+        </interactivity>
+
+        <build>
+        - Use docker buildx bake for all builds
+        - Target naming: lowercase, hyphen-separated
+        - Cache dependencies: COPY package*.json before npm install
+        - Multi-stage builds: separate concerns (build, test, release)
+        - Output handling: use --output or --set flags
+        - Variables: pass via --set or environment variables
+        </build>
+
+        <validation>
+        - Use the validate tool to verify your changes
+        - Check specific targets: lint, vale, test, unused-media
+        - Fix rumdl errors in content files
+        - Fix htmltest errors (broken links, missing alt text)
+        - Validate redirects with test-go-redirects
+        </validation>
+
+        <modules>
+        - Update go.mod for version changes
+        - Run VENDOR_MODULE=<module>@<version> docker buildx bake vendor
+        - Verify with docker buildx bake validate-vendor
+        - Commit both go.mod and _vendor/ changes
+        - Never edit _vendor/ content directly
+        </modules>
+
+        <testing>
+        - Check that the site builds using the build tool
+        - Test and validate using the validate tool
+        </testing>
+      </rules>
+
+      <examples>
+      Resource loading:
+      ```
+      {{- $css := resources.Get "css/style.css"
+        | css.TailwindCSS
+        | minify
+        | fingerprint }}
+      <link rel="stylesheet" href="{{ $css.Permalink }}">
+      ```
+
+      Conditional rendering:
+      ```
+      {{- with .Param "key" }}
+        {{ . }}
+      {{- end }}
+      ```
+
+      Iteration:
+      ```
+      {{- range .Pages }}
+        {{ .Title }}
+      {{- end }}
+      ```
+
+      Shortcode structure:
+      ```
+      {{- $param := .Get "param" -}}
+      <div class="component">
+        {{ .Inner }}
+      </div>
+      ```
+
+      Alpine.js with Hugo data:
+      ```
+      <div x-data='{{ dict "items" .Params.items | jsonify }}'>
+        <template x-for="item in items">
+          <div x-text="item.name"></div>
+        </template>
+      </div>
+      ```
+
+      Tailwind custom utilities:
+      ```css
+      @layer utilities {
+        .custom-class {
+          @apply flex items-center gap-2;
+        }
+      }
+      ```
+
+      Docker Bake target:
+      ```hcl
+      target "name" {
+        dockerfile = "Dockerfile"
+        target = "stage-name"
+        output = ["type=local,dest=output/"]
+        args = {
+          KEY = "value"
+        }
+      }
+      ```
+      </examples>
+
+      <reference>
+      Key architectural patterns and entry points:
+
+      Dual HTML/Markdown publishing:
+      Pages are published in both HTML and Markdown formats via Hugo's output
+      formats configuration (hugo.yaml lines 89-94). Each page/section outputs
+      to both formats. Markdown layouts in layouts/_default/*.markdown.md use
+      .RenderShortcodes to render shortcodes while preserving markdown
+      structure. Lambda@Edge on CloudFront performs content negotiation,
+      serving markdown when Accept: text/markdown header is present. This
+      enables AI agents to consume documentation as structured markdown.
+
+      AI agent support files:
+      - metadata.json: Site root JSON file listing all page routes with titles,
+        descriptions, keywords, and tags. Generated by
+        layouts/index.metadata.json
+      - llms.txt: Structured markdown index of all pages grouped by section.
+        Generated by layouts/_default/index.llms.txt. Follows llms.txt standard
+        for LLM discovery
+      - redirects.json: All site redirects for Lambda@Edge routing
+
+      Post-build processing:
+      hack/flatten-and-resolve.js runs after Hugo build to resolve cross-links
+      and flatten directory structure. Processes both HTML and markdown output
+      formats. Critical for correct link resolution across dual formats.
+
+      Hugo module vendoring:
+      Content is vendored from upstream repos (docker/cli, moby/buildkit, etc.)
+      into _vendor/ directory. These files are read-only - changes must go
+      upstream. CLI reference data is generated into data/ directories from
+      upstream YAML. Manage with: VENDOR_MODULE=<module>@<version> make vendor
+
+      URL transformation:
+      The /manuals prefix is removed from published URLs via hugo.yaml
+      permalinks configuration. content/manuals/docker-desktop/install.md
+      becomes /docker-desktop/install/ on the live site. Critical for link
+      resolution and redirects.
+
+      Client-side search with Pagefind:
+      Static search index is built post-Hugo by the pagefind stage in
+      Dockerfile. Runs after Hugo build completes. Search is entirely
+      client-side JavaScript, no server required.
+
+      Template entry points:
+      - layouts/_default/baseof.html: Base template wrapping all pages
+      - layouts/_default/single.markdown.md: Markdown output for pages
+      - layouts/_default/list.markdown.md: Markdown output for sections
+      - layouts/shortcodes/: Reusable components (tabs, accordion, include)
+      - layouts/partials/: Template fragments (head, header, footer)
+
+      Frontend entry points:
+      - assets/css/style.css: Main CSS (@import tailwindcss)
+      - assets/css/theme.css: Tailwind theme configuration (@theme inline)
+      - assets/js/src/alpine.js: Alpine.js initialization
+
+      Build system:
+      - docker-bake.hcl: All build targets
+      - Dockerfile: Multi-stage build definition
+      - Key targets: release (production), validate (all checks), vendor
+        (update modules)
+
+      Configuration files:
+      - hugo.yaml: Hugo configuration (modules, permalinks, markup, output
+        formats)
+      - go.mod: Hugo module versions
+      - package.json: Frontend dependencies
+      </reference>
+
+      <reporting>
+      Work silently without narration.
+      - No "Let me", "Now I'll", "I'm going to" phrases
+      - Don't explain before doing - just execute
+
+      Keep communication concise. Report only essential findings and blockers.
+      </reporting>
+
+      <success_criteria>
+      - Code follows established patterns
+      - Changes tested with build tool
+      - Validation passes (validate tool)
+      - No regressions introduced
+      - Complex changes documented
+      </success_criteria>
+
+    toolsets:
+      - type: filesystem
+      - type: fetch
+      - type: shell
+      - type: todo
+      - type: script
+        shell:
+          validate:
+            cmd: "docker buildx bake validate > .validation.log 2>&1"
+            description: |
+              Run all validation checks (lint, vale, test, etc.)
+              Output written to .validation.log - read this file to see results
+          build:
+            cmd: "docker buildx bake release"
+            description: Build production site with Hugo and all assets
+
+models:
+  opus:
+    provider: anthropic
+    model: claude-opus-4-5
+    temperature: 0.3
diff --git a/go.mod b/go.mod
index 155f635ef101..eb4897444a12 100644
--- a/go.mod
+++ b/go.mod
@@ -1,23 +1,29 @@
 module github.com/docker/docs
 
-go 1.23.8
-
-toolchain go1.24.1
+go 1.26.5
 
+// This go.mod file is used by hugo to vendor documentation from upstream
+// repositories. Use the "require" section to specify the version of the
+// upstream repository.
+//
+// Make sure to add an entry in the "tools" section when adding a new repository.
 require (
-	github.com/docker/buildx v0.23.0 // indirect
-	github.com/docker/cli v28.1.0+incompatible // indirect
-	github.com/docker/compose/v2 v2.35.1 // indirect
-	github.com/docker/scout-cli v1.15.0 // indirect
-	github.com/moby/buildkit v0.21.0 // indirect
-	github.com/moby/moby v28.1.0-rc.2+incompatible // indirect
+	github.com/docker/buildx v0.36.1
+	github.com/docker/cli v29.7.2+incompatible
+	github.com/docker/compose/v5 v5.5.0
+	github.com/docker/docker-agent v1.126.0
+	github.com/docker/model-runner v1.1.36
+	github.com/moby/buildkit v0.32.2
+	github.com/moby/moby/api v1.55.0
 )
 
-replace (
-	github.com/docker/buildx => github.com/docker/buildx v0.23.0
-	github.com/docker/cli => github.com/docker/cli v28.1.0-rc.2+incompatible
-	github.com/docker/compose/v2 => github.com/docker/compose/v2 v2.35.1
-	github.com/docker/scout-cli => github.com/docker/scout-cli v1.15.0
-	github.com/moby/buildkit => github.com/moby/buildkit v0.20.0
-	github.com/moby/moby => github.com/moby/moby v28.1.0-rc.2+incompatible
+tool (
+	github.com/docker/buildx
+	github.com/docker/cli
+	github.com/docker/compose/v5
+	github.com/docker/docker-agent
+	github.com/docker/model-runner
+	github.com/docker/scout-cli
+	github.com/moby/buildkit
+	github.com/moby/moby/api
 )
diff --git a/go.sum b/go.sum
index e0d9918a4407..7f20917de281 100644
--- a/go.sum
+++ b/go.sum
@@ -1,448 +1,605 @@
-github.com/Azure/go-autorest v14.2.0+incompatible/go.mod h1:r+4oMnoxhatjLLJ6zxSWATqVooLgysK6ZNox3g/xq24=
-github.com/Azure/go-autorest/autorest/adal v0.9.5/go.mod h1:B7KF7jKIeC9Mct5spmyCB/A8CG/sEz1vwIRGv/bbw7A=
-github.com/Azure/go-autorest/autorest/date v0.3.0/go.mod h1:BI0uouVdmngYNUzGWeSYnokU+TrmwEsOqdt8Y6sso74=
-github.com/Azure/go-autorest/logger v0.2.0/go.mod h1:T9E3cAhj2VqvPOtCYAvby9aBXkZmbF5NWuPV8+WeEW8=
-github.com/Azure/go-autorest/tracing v0.6.0/go.mod h1:+vhtPC754Xsa23ID7GlGsrdKBpUA79WCAKPPZVC2DeU=
-github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU=
-github.com/PuerkitoBio/purell v1.1.1/go.mod h1:c11w/QuzBsJSee3cPx9rAFu61PvFxuPbtSwDGJws/X0=
-github.com/PuerkitoBio/urlesc v0.0.0-20170810143723-de5bf2ad4578/go.mod h1:uGdkoq3SwY9Y+13GIhn11/XLaGBb4BfwItxLd5jeuXE=
-github.com/agl/ed25519 v0.0.0-20170116200512-5312a6153412/go.mod h1:WPjqKcmVOxf0XSf3YxCJs6N6AOSrOx3obionmG7T0y0=
-github.com/apparentlymart/go-cidr v1.0.1/go.mod h1:EBcsNrHc3zQeuaeCeCtQruQm+n9/YjEn/vI25Lg7Gwc=
-github.com/apparentlymart/go-textseg/v12 v12.0.0/go.mod h1:S/4uRK2UtaQttw1GenVJEynmyUenKwP++x/+DdGV/Ec=
-github.com/beorn7/perks v1.0.1/go.mod h1:G2ZrVWU2WbWT9wwq4/hrbKbnv/1ERSJQ0ibhJ6rlkpw=
-github.com/bugsnag/bugsnag-go v1.4.1/go.mod h1:2oa8nejYd4cQ/b0hMIopN0lCRxU0bueqREvZLWFrtK8=
-github.com/bugsnag/panicwrap v1.2.0/go.mod h1:D/8v3kj0zr8ZAKg1AQ6crr+5VwKN5eIywRkfhyM/+dE=
-github.com/cenkalti/backoff v2.1.1+incompatible/go.mod h1:90ReRw6GdpyfrHakVjL/QHaoyV4aDUVVkXQJJJ3NXXM=
-github.com/cloudflare/cfssl v0.0.0-20181213083726-b94e044bb51e/go.mod h1:yMWuSON2oQp+43nFtAV/uvKQIFpSPerB57DCt9t8sSA=
-github.com/compose-spec/compose-spec v0.0.0-20230623140450-d63a678732a3 h1:YbpEs/CNAGa/2lsASxr2XAcOMQBeMVd6uQLLZxUD4Dc=
-github.com/compose-spec/compose-spec v0.0.0-20230623140450-d63a678732a3/go.mod h1:SkxF2HOKkzpp+mNdvGONzi3g2shI/M94GkMgsE0JLuk=
-github.com/compose-spec/compose-spec v0.0.0-20230626141542-c7f842ce463a h1:9gsWcK+jNkxqKaFyt5hkMA+lNXnyLC0gSJPUQF9h/CI=
-github.com/compose-spec/compose-spec v0.0.0-20230626141542-c7f842ce463a/go.mod h1:SkxF2HOKkzpp+mNdvGONzi3g2shI/M94GkMgsE0JLuk=
-github.com/compose-spec/compose-spec v0.0.0-20230629051316-305289eead60 h1:0wyrkmqb40WXecFlMRxxKA+iA9XqoCDgyXCud/Y5OwY=
-github.com/compose-spec/compose-spec v0.0.0-20230629051316-305289eead60/go.mod h1:SkxF2HOKkzpp+mNdvGONzi3g2shI/M94GkMgsE0JLuk=
-github.com/compose-spec/compose-spec v0.0.0-20230713225457-40c2421be01f h1:9gcoN1ndvlPiauBc4M6fxTIbTd/bWpqRYawdXULJq3E=
-github.com/compose-spec/compose-spec v0.0.0-20230713225457-40c2421be01f/go.mod h1:SkxF2HOKkzpp+mNdvGONzi3g2shI/M94GkMgsE0JLuk=
-github.com/compose-spec/compose-spec v0.0.0-20230719125707-55b450aee507 h1:k7z47/imAaUlZuMVpNTRX0h6E2dYQ5YQ/DUJJAP4680=
-github.com/compose-spec/compose-spec v0.0.0-20230719125707-55b450aee507/go.mod h1:SkxF2HOKkzpp+mNdvGONzi3g2shI/M94GkMgsE0JLuk=
-github.com/compose-spec/compose-spec v0.0.0-20230724132559-6907af1d7a8b h1:VbdFseBE88G/bW9LIynx77QMTZpW8kX9/ydDMyGtgZI=
-github.com/compose-spec/compose-spec v0.0.0-20230724132559-6907af1d7a8b/go.mod h1:SkxF2HOKkzpp+mNdvGONzi3g2shI/M94GkMgsE0JLuk=
-github.com/compose-spec/compose-spec v0.0.0-20230810081227-631f10f1aabc h1:E93Ppj6xhV/QYCNTg0oWAnsJxuy7v5X3vLH+6iSp7IY=
-github.com/compose-spec/compose-spec v0.0.0-20230810081227-631f10f1aabc/go.mod h1:SkxF2HOKkzpp+mNdvGONzi3g2shI/M94GkMgsE0JLuk=
-github.com/compose-spec/compose-spec v0.0.0-20230824062516-848a47ad5d0e h1:qmkQEx3/l6a4ofsiU+b1gDRkANoy55uyc3EXp1n77/Y=
-github.com/compose-spec/compose-spec v0.0.0-20230824062516-848a47ad5d0e/go.mod h1:SkxF2HOKkzpp+mNdvGONzi3g2shI/M94GkMgsE0JLuk=
-github.com/compose-spec/compose-spec v0.0.0-20230927132538-f223c5150d5d h1:EHvVBP6ZYAz5KXU5/iA3K6Z7G7haxPm44g/08tueZSw=
-github.com/compose-spec/compose-spec v0.0.0-20230927132538-f223c5150d5d/go.mod h1:SkxF2HOKkzpp+mNdvGONzi3g2shI/M94GkMgsE0JLuk=
-github.com/compose-spec/compose-spec v0.0.0-20231121152139-478928e7c9f8 h1:WQU6c3MGdIxVcDRC+Qstk9bJuYvHLvbyfkN8fStL1Qk=
-github.com/compose-spec/compose-spec v0.0.0-20231121152139-478928e7c9f8/go.mod h1:SkxF2HOKkzpp+mNdvGONzi3g2shI/M94GkMgsE0JLuk=
-github.com/containerd/fuse-overlayfs-snapshotter v1.0.2/go.mod h1:nRZceC8a7dRm3Ao6cJAwuJWPFiBPaibHiFntRUnzhwU=
+github.com/Azure/go-ansiterm v0.0.0-20250102033503-faa5f7b0171c h1:udKWzYgxTojEKWjV8V+WSxDXJ4NFATAsZjh8iIbsQIg=
+github.com/Azure/go-ansiterm v0.0.0-20250102033503-faa5f7b0171c/go.mod h1:xomTg63KZ2rFqZQzSB4Vz2SUXa1BpHTVz9L5PTmPC4E=
+github.com/Microsoft/go-winio v0.6.2 h1:F2VQgta7ecxGYO8k3ZZz3RS8fVIXVxONVUPlNERoyfY=
+github.com/Microsoft/go-winio v0.6.2/go.mod h1:yd8OoFMLzJbo9gZq8j5qaps8bJ9aShtEA8Ipt1oGCvU=
+github.com/Microsoft/go-winio v0.6.3-0.20251027160822-ad3df93bed29 h1:0kQAzHq8vLs7Pptv+7TxjdETLf/nIqJpIB4oC6Ba4vY=
+github.com/alecthomas/chroma/v2 v2.14.0 h1:R3+wzpnUArGcQz7fCETQBzO5n9IMNi13iIs46aU4V9E=
+github.com/alecthomas/chroma/v2 v2.14.0/go.mod h1:QolEbTfmUHIMVpBqxeDnNBj2uoeI4EbYP4i6n68SG4I=
+github.com/alecthomas/chroma/v2 v2.20.0 h1:sfIHpxPyR07/Oylvmcai3X/exDlE8+FA820NTz+9sGw=
+github.com/aymanbagabas/go-osc52/v2 v2.0.1 h1:HwpRHbFMcZLEVr42D4p7XBqjyuxQH5SMiErDT4WkJ2k=
+github.com/aymanbagabas/go-osc52/v2 v2.0.1/go.mod h1:uYgXzlJ7ZpABp8OJ+exZzJJhRNQ2ASbcXHWsFqH8hp8=
+github.com/aymerick/douceur v0.2.0 h1:Mv+mAeH1Q+n9Fr+oyamOlAkUNPWPlA8PPGR0QAaYuPk=
+github.com/aymerick/douceur v0.2.0/go.mod h1:wlT5vV2O3h55X9m7iVYN0TBM0NH/MmbLnd30/FjWUq4=
+github.com/cenkalti/backoff/v5 v5.0.3 h1:ZN+IMa753KfX5hd8vVaMixjnqRZ3y8CuJKRKj1xcsSM=
+github.com/cenkalti/backoff/v5 v5.0.3/go.mod h1:rkhZdG3JZukswDf7f0cwqPNk4K0sa+F97BxZthm/crw=
+github.com/cespare/xxhash/v2 v2.3.0 h1:UL815xU9SqsFlibzuggzjXhog7bL6oX9BbNZnL2UFvs=
+github.com/cespare/xxhash/v2 v2.3.0/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs=
+github.com/charmbracelet/colorprofile v0.2.3-0.20250311203215-f60798e515dc h1:4pZI35227imm7yK2bGPcfpFEmuY1gc2YSTShr4iJBfs=
+github.com/charmbracelet/colorprofile v0.2.3-0.20250311203215-f60798e515dc/go.mod h1:X4/0JoqgTIPSFcRA/P6INZzIuyqdFY5rm8tb41s9okk=
+github.com/charmbracelet/glamour v0.10.0 h1:MtZvfwsYCx8jEPFJm3rIBFIMZUfUJ765oX8V6kXldcY=
+github.com/charmbracelet/glamour v0.10.0/go.mod h1:f+uf+I/ChNmqo087elLnVdCiVgjSKWuXa/l6NU2ndYk=
+github.com/charmbracelet/glamour v1.0.0 h1:AWMLOVFHTsysl4WV8T8QgkQ0s/ZNZo7CiE4WKhk8l08=
+github.com/charmbracelet/lipgloss v1.1.1-0.20250404203927-76690c660834 h1:ZR7e0ro+SZZiIZD7msJyA+NjkCNNavuiPBLgerbOziE=
+github.com/charmbracelet/lipgloss v1.1.1-0.20250404203927-76690c660834/go.mod h1:aKC/t2arECF6rNOnaKaVU6y4t4ZeHQzqfxedE/VkVhA=
+github.com/charmbracelet/x/ansi v0.8.0 h1:9GTq3xq9caJW8ZrBTe0LIe2fvfLR/bYXKTx2llXn7xE=
+github.com/charmbracelet/x/ansi v0.8.0/go.mod h1:wdYl/ONOLHLIVmQaxbIYEC/cRKOQyjTkowiI4blgS9Q=
+github.com/charmbracelet/x/ansi v0.10.2 h1:ith2ArZS0CJG30cIUfID1LXN7ZFXRCww6RUvAPA+Pzw=
+github.com/charmbracelet/x/cellbuf v0.0.13 h1:/KBBKHuVRbq1lYx5BzEHBAFBP8VcQzJejZ/IA3iR28k=
+github.com/charmbracelet/x/cellbuf v0.0.13/go.mod h1:xe0nKWGd3eJgtqZRaN9RjMtK7xUYchjzPr7q6kcvCCs=
+github.com/charmbracelet/x/exp/slice v0.0.0-20250327172914-2fdc97757edf h1:rLG0Yb6MQSDKdB52aGX55JT1oi0P0Kuaj7wi1bLUpnI=
+github.com/charmbracelet/x/exp/slice v0.0.0-20250327172914-2fdc97757edf/go.mod h1:B3UgsnsBZS/eX42BlaNiJkD1pPOUa+oF1IYC6Yd2CEU=
+github.com/charmbracelet/x/term v0.2.1 h1:AQeHeLZ1OqSXhrAWpYUtZyX1T3zVxfpZuEQMIQaGIAQ=
+github.com/charmbracelet/x/term v0.2.1/go.mod h1:oQ4enTYFV7QN4m0i9mzHrViD7TQKvNEEkHUMCmsxdUg=
+github.com/containerd/containerd/v2 v2.2.1-0.20251115011841-efd86f2b0bc2 h1:WcvXNS/OmpiitTVdzRAudKwvShKxcOP4Elf2FyxSoTg=
+github.com/containerd/containerd/v2 v2.2.1-0.20251115011841-efd86f2b0bc2/go.mod h1:YCMjKjA4ZA7egdHNi3/93bJR1+2oniYlnS+c0N62HdE=
+github.com/containerd/containerd/v2 v2.2.1 h1:TpyxcY4AL5A+07dxETevunVS5zxqzuq7ZqJXknM11yk=
+github.com/containerd/containerd/v2 v2.2.1/go.mod h1:NR70yW1iDxe84F2iFWbR9xfAN0N2F0NcjTi1OVth4nU=
+github.com/containerd/containerd/v2 v2.2.2 h1:mjVQdtfryzT7lOqs5EYUFZm8ioPVjOpkSoG1GJPxEMY=
+github.com/containerd/containerd/v2 v2.2.2/go.mod h1:5Jhevmv6/2J+Iu/A2xXAdUIdI5Ah/hfyO7okJ4AFIdY=
+github.com/containerd/containerd/v2 v2.2.3 h1:mOBRLaHGvmgy0bRo1Sg6OD8ugMKZIvCoWWMeMMygliA=
+github.com/containerd/containerd/v2 v2.2.4 h1:8x2UdXqww7NYqGNabQ7i1nAgB5LegzjC9KQzO/900iA=
+github.com/containerd/containerd/v2 v2.2.5 h1:KTFzB02LviYmmfRmz8r9UFd+n6YlddVFK+5lbgQXUTU=
+github.com/containerd/containerd/v2 v2.3.3 h1:MUNBVVBTBpPll7KPh5GTvkC3cfG03PQLAHVdsUoue9k=
+github.com/containerd/errdefs v1.0.0 h1:tg5yIfIlQIrxYtu9ajqY42W3lpS19XqdxRQeEwYG8PI=
+github.com/containerd/errdefs v1.0.0/go.mod h1:+YBYIdtsnF4Iw6nWZhJcqGSg/dwvV7tyJ/kCkyJ2k+M=
+github.com/containerd/errdefs/pkg v0.3.0 h1:9IKJ06FvyNlexW690DXuQNx2KA2cUJXx151Xdx3ZPPE=
+github.com/containerd/errdefs/pkg v0.3.0/go.mod h1:NJw6s9HwNuRhnjJhM7pylWwMyAkmCQvQ4GpJHEqRLVk=
+github.com/containerd/log v0.1.0 h1:TCJt7ioM2cr/tfR8GPbGf9/VRAX8D2B4PjzCpfX540I=
+github.com/containerd/log v0.1.0/go.mod h1:VRRf09a7mHDIRezVKTRCrOq78v577GXq3bSa3EhrzVo=
+github.com/containerd/platforms v1.0.0-rc.2 h1:0SPgaNZPVWGEi4grZdV8VRYQn78y+nm6acgLGv/QzE4=
+github.com/containerd/platforms v1.0.0-rc.2/go.mod h1:J71L7B+aiM5SdIEqmd9wp6THLVRzJGXfNuWCZCllLA4=
+github.com/containerd/platforms v1.0.0-rc.3 h1:YdvwaHtrN6wHcGJ2mYRYP3Nso8OcysuqFe9Hxm1X/tI=
+github.com/containerd/platforms v1.0.0-rc.3/go.mod h1:gw0R+alP3nFQPh1L4K9bv13fRWeeyokLGLu2fKuqI10=
+github.com/containerd/platforms v1.0.0-rc.4 h1:M42JrUT4zfZTqtkUwkr0GzmUWbfyO5VO0Q5b3op97T4=
+github.com/containerd/platforms v1.0.0-rc.4/go.mod h1:lKlMXyLybmBedS/JJm11uDofzI8L2v0J2ZbYvNsbq1A=
+github.com/containerd/stargz-snapshotter v0.17.0 h1:djNS4KU8ztFhLdEDZ1bsfzOiYuVHT6TgSU5qwRk+cNc=
+github.com/containerd/stargz-snapshotter v0.18.2 h1:Ev/sxfQUjwzJQ9eqy3XzttcQ3osMIqkQgMYlcET+10M=
+github.com/containerd/stargz-snapshotter/estargz v0.17.0 h1:+TyQIsR/zSFI1Rm31EQBwpAA1ovYgIKHy7kctL3sLcE=
+github.com/containerd/stargz-snapshotter/estargz v0.17.0/go.mod h1:s06tWAiJcXQo9/8AReBCIo/QxcXFZ2n4qfsRnpl71SM=
+github.com/containerd/stargz-snapshotter/estargz v0.18.2 h1:yXkZFYIzz3eoLwlTUZKz2iQ4MrckBxJjkmD16ynUTrw=
+github.com/containerd/typeurl/v2 v2.2.3 h1:yNA/94zxWdvYACdYO8zofhrTVuQY73fFU1y++dYSw40=
+github.com/containerd/typeurl/v2 v2.2.3/go.mod h1:95ljDnPfD3bAbDJRugOiShd/DlAAsxGtUBhJxIn7SCk=
+github.com/containerd/typeurl/v2 v2.3.0 h1:HZHPhRWo5XMy3QGQoPrUzbW/2ckwjfweHmOwlkIrPAQ=
+github.com/cpuguy83/go-md2man/v2 v2.0.6/go.mod h1:oOW0eioCTA6cOiMLiUPZOpcVxMig6NIQQ7OS05n1F4g=
+github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
 github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
-github.com/distribution/distribution v2.8.2+incompatible h1:k9+4DKdOG+quPFZXT/mUsiQrGu9vYCp+dXpuPkuqhk8=
-github.com/distribution/distribution v2.8.2+incompatible/go.mod h1:EgLm2NgWtdKgzF9NpMzUKgzmR7AMmb0VQi2B+ZzDRjc=
-github.com/distribution/distribution v2.8.3+incompatible h1:RlpEXBLq/WPXYvBYMDAmBX/SnhD67qwtvW/DzKc8pAo=
-github.com/distribution/distribution v2.8.3+incompatible/go.mod h1:EgLm2NgWtdKgzF9NpMzUKgzmR7AMmb0VQi2B+ZzDRjc=
-github.com/distribution/distribution v2.8.4-0.20231004140828-d607c6ccb937+incompatible h1:P+KGSuf9hFRNDeS5I8fnEkExK8W/GOr6mzn8aCkVzSU=
-github.com/distribution/distribution v2.8.4-0.20231004140828-d607c6ccb937+incompatible/go.mod h1:EgLm2NgWtdKgzF9NpMzUKgzmR7AMmb0VQi2B+ZzDRjc=
-github.com/distribution/reference v0.5.0 h1:/FUIFXtfc/x2gpa5/VGfiGLuOIdYa1t65IKK2OFGvA0=
-github.com/distribution/reference v0.5.0/go.mod h1:BbU0aIcezP1/5jX/8MP0YiH4SdvB5Y4f/wlDRiLyi3E=
-github.com/docker/buildx v0.11.0 h1:DNCOIYT/7J0sPBlU/ozEhFd4MtbnbFByn45yeTMHXVU=
-github.com/docker/buildx v0.11.0/go.mod h1:Yq7ZNjrwXKzW0uSFMk46dl5Gl903k5+bp6U4apsM5rs=
-github.com/docker/buildx v0.11.1 h1:xfmrAkOJrN+NLRcwhZn1iBgJVAK1dEBEv8lWu1Wxg14=
-github.com/docker/buildx v0.11.1/go.mod h1:qAxs3bsJEfVo7DOc9riES/f9Z187CeGM5nLPmadk8AA=
-github.com/docker/buildx v0.11.2 h1:R3p9F0gnI4FwvQ0p40UwdX1T4ugap4UWxY3TFHoP4Ws=
-github.com/docker/buildx v0.11.2/go.mod h1:CWAABt10iIuGpleypA3103mplDfcGu0A2AvT03xfpTc=
-github.com/docker/buildx v0.12.0 h1:pI4jr4SeH9oHa0SmMvH/lz+Rdqkg+dRa9H/1VXbYgws=
-github.com/docker/buildx v0.12.0/go.mod h1:SBLnQH9q+77aVvpvS5LLIly9+nHVlwscl5GEegGMD5g=
-github.com/docker/buildx v0.12.1-0.20231214091505-b68ee824c673 h1:mZ2+TyEERNA4GY2xO3kIa7ZhfmUNwveIMxGYWV126dA=
-github.com/docker/buildx v0.12.1-0.20231214091505-b68ee824c673/go.mod h1:SBLnQH9q+77aVvpvS5LLIly9+nHVlwscl5GEegGMD5g=
-github.com/docker/buildx v0.12.1 h1:oahmdKmkGaa8NnaWKvtDZe2vpSYsKZ+WsHOMLQTDCk8=
-github.com/docker/buildx v0.12.1/go.mod h1:SBLnQH9q+77aVvpvS5LLIly9+nHVlwscl5GEegGMD5g=
-github.com/docker/buildx v0.12.2-0.20240126114058-d43cf8c2c6b4 h1:aEFpoxTw5LIRjN0jFdHsOa1POpELzgwJ0SnhykCa8dg=
-github.com/docker/buildx v0.12.2-0.20240126114058-d43cf8c2c6b4/go.mod h1:SBLnQH9q+77aVvpvS5LLIly9+nHVlwscl5GEegGMD5g=
-github.com/docker/buildx v0.12.2-0.20240220084849-89154c7d3303 h1:J34paheV5gSKezhnVzwT5WwRQgPzBLYAdCYAFPoEYfU=
-github.com/docker/buildx v0.12.2-0.20240220084849-89154c7d3303/go.mod h1:OoLv85M5U/p8TWyCINtEilyy0A0XTN9COQgmuE0bWhw=
-github.com/docker/buildx v0.13.0 h1:nNbkgaxsWEZPX1P8yXN6dibAv7ADRMVqi0aohDFhLJY=
-github.com/docker/buildx v0.13.0/go.mod h1:f2n6vggoX4sNNZ0XoRZ0Wtv6J1/rbDTabgdHtpW9NNM=
-github.com/docker/buildx v0.13.1-0.20240307093612-37b7ad1465d2 h1:kuFvsZyZCYqxWBc3O7B95wHAoYKheuZYztIHstwnF7Y=
-github.com/docker/buildx v0.13.1-0.20240307093612-37b7ad1465d2/go.mod h1:f2n6vggoX4sNNZ0XoRZ0Wtv6J1/rbDTabgdHtpW9NNM=
-github.com/docker/buildx v0.13.1 h1:uZjBcb477zh02tnHk0rqNV/DZOxbf/OiHw6Mc8OhDYU=
-github.com/docker/buildx v0.13.1/go.mod h1:f2n6vggoX4sNNZ0XoRZ0Wtv6J1/rbDTabgdHtpW9NNM=
-github.com/docker/buildx v0.14.0 h1:FxqcfE7xgeEC4oQlKLpuvfobRDVDXrHE3jByM+mdyqk=
-github.com/docker/buildx v0.14.0/go.mod h1:Vy/2lC9QsJvo33+7KKkN/GDE5WxnVqW0/dpcN7ZqPJY=
-github.com/docker/buildx v0.14.1 h1:Pr3HdtHoDsCghlIExgGp0WOIgvbiViushOKIPUIyFI4=
-github.com/docker/buildx v0.14.1/go.mod h1:s6xxLYXZIWnkdYpSvxRmoqZTb1vViV9q2f+Hg8cWA3Y=
-github.com/docker/buildx v0.15.0 h1:PVq4IMnTvw1Sx0RKDWbfi2eTGawFd9CMBYnz9xat93Y=
-github.com/docker/buildx v0.15.0/go.mod h1:AdkB1RIcU4rfZ6mpw2PA2pOi1ppI9yvFXkVEpq5EmS4=
-github.com/docker/buildx v0.15.1 h1:1cO6JIc0rOoC8tlxfXoh1HH1uxaNvYH1q7J7kv5enhw=
-github.com/docker/buildx v0.15.1/go.mod h1:16DQgJqoggmadc1UhLaUTPqKtR+PlByN/kyXFdkhFCo=
-github.com/docker/buildx v0.16.0 h1:LurEflyb6BBoLtDwJY1dw9dLHKzEgGvCjAz67QI0xO0=
-github.com/docker/buildx v0.16.0/go.mod h1:4xduW7BOJ2B11AyORKZFDKjF6Vcb4EgTYnV2nunxv9I=
-github.com/docker/buildx v0.16.2 h1:SPcyEiiCZEntJQ+V0lJI8ZudUrki2v1qUqmC/NqxDDs=
-github.com/docker/buildx v0.16.2/go.mod h1:by+CuE4Q+2NvECkIhNcWe89jjbHADCrDlzS9MRgbv2k=
-github.com/docker/buildx v0.17.0 h1:Z+QQxsJJPldaeU/4aNXoudFwDDK0/ALFYmDcP5q5fiY=
-github.com/docker/buildx v0.17.0/go.mod h1:sBKkoZFs+R2D6ARyQ4/GE/FQHHFsl9PkHdvv/GXAsMo=
-github.com/docker/buildx v0.17.1 h1:9ob2jGp4+W9PxWw68GsoNFp+eYFc7eUoRL9VljLCSM4=
-github.com/docker/buildx v0.17.1/go.mod h1:kJOhOhS47LRvrLFRulFiO5SE6VJf54yYMn7DzjgO5W0=
-github.com/docker/buildx v0.18.0 h1:rSauXHeJt90NvtXrLK5J992Eb0UPJZs2vV3u1zTf1nE=
-github.com/docker/buildx v0.18.0/go.mod h1:JGNSshOhHs5FhG3u51jXUf4lLOeD2QBIlJ2vaRB67p4=
-github.com/docker/buildx v0.19.1 h1:muQEvRJLvOCS0p/67gPwjnQPWqE5ot3sGkb2Eq7vCmw=
-github.com/docker/buildx v0.19.1/go.mod h1:k4WP+XmGRYL0a7l4RZAI2TqpwhuAuSQ5U/rosRgFmAA=
-github.com/docker/buildx v0.19.2 h1:2zXzgP2liQKgQ5BiOqMc+wz7hfWgAIMWw5MR6QDG++I=
-github.com/docker/buildx v0.19.2/go.mod h1:k4WP+XmGRYL0a7l4RZAI2TqpwhuAuSQ5U/rosRgFmAA=
-github.com/docker/buildx v0.20.0 h1:XM2EvwEfohbxLPAheVm03biNHpspB/dA6U9F0c6yJsI=
-github.com/docker/buildx v0.20.0/go.mod h1:VVi4Nvo4jd/IkRvwyExbIyW7u82fivK61MRx5I0oKic=
-github.com/docker/buildx v0.20.1 h1:q88EfoYwrWEKVqNb9stOFq8fUlFp/OPlDcFE+QUYZBM=
-github.com/docker/buildx v0.20.1/go.mod h1:VVi4Nvo4jd/IkRvwyExbIyW7u82fivK61MRx5I0oKic=
-github.com/docker/buildx v0.21.0 h1:cp++wh60cjMraq8VXM59jV1aolR3eFIkCx1Z7o5Q2ZY=
-github.com/docker/buildx v0.21.0/go.mod h1:8V4UMnlKsaGYwz83BygmIbJIFEAYGHT6KAv8akDZmqo=
-github.com/docker/buildx v0.21.1 h1:YjV2k6CsSDbkDTOMsjARUIrj2xv+zZR+M2dtrRyzXhg=
-github.com/docker/buildx v0.21.1/go.mod h1:8V4UMnlKsaGYwz83BygmIbJIFEAYGHT6KAv8akDZmqo=
-github.com/docker/buildx v0.21.2 h1:r09paH8q9nvAX2PR1ntRrc+C6FBH93bvKUsn1WOb/jU=
-github.com/docker/buildx v0.21.2/go.mod h1:8V4UMnlKsaGYwz83BygmIbJIFEAYGHT6KAv8akDZmqo=
-github.com/docker/buildx v0.21.3 h1:LEmhk3D9WOboMeC+hlfOUnB1jylXcDfGHjqAL7Tvwks=
-github.com/docker/buildx v0.21.3/go.mod h1:8V4UMnlKsaGYwz83BygmIbJIFEAYGHT6KAv8akDZmqo=
-github.com/docker/buildx v0.22.0 h1:pGTcGZa+kxpYUlM/6ACsp1hXhkEDulz++RNXPdE8Afk=
-github.com/docker/buildx v0.22.0/go.mod h1:ThbnUe4kNiStlq6cLXruElyEdSTdPL3k/QerNUmPvHE=
-github.com/docker/buildx v0.23.0 h1:qoYhuWyZ6PVCrWbkxClLzBWDBCUkyFK6Chjzg6nU+V8=
-github.com/docker/buildx v0.23.0/go.mod h1:y/6Zf/y3Bf0zTWqgg8PuNFATcqnuhFmQuNf4VyrnPtg=
-github.com/docker/cli v24.0.2+incompatible h1:QdqR7znue1mtkXIJ+ruQMGQhpw2JzMJLRXp6zpzF6tM=
-github.com/docker/cli v24.0.2+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v24.0.4+incompatible h1:Y3bYF9ekNTm2VFz5U/0BlMdJy73D+Y1iAAZ8l63Ydzw=
-github.com/docker/cli v24.0.4+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v24.0.5+incompatible h1:WeBimjvS0eKdH4Ygx+ihVq1Q++xg36M/rMi4aXAvodc=
-github.com/docker/cli v24.0.5+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v24.0.6+incompatible h1:fF+XCQCgJjjQNIMjzaSmiKJSCcfcXb3TWTcc7GAneOY=
-github.com/docker/cli v24.0.6+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v24.0.8-0.20231106123152-48ec4f339e2b+incompatible h1:tXZk7C97vINae9YYzPtqoClal32VoMl8gz6gLjJ6Kdg=
-github.com/docker/cli v24.0.8-0.20231106123152-48ec4f339e2b+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v24.0.8-0.20231211210310-fb2f337bc1b1+incompatible h1:3hcKPFXxdqoVzoIrjNF1NNb36kzFiEimwUegOhw0pC0=
-github.com/docker/cli v24.0.8-0.20231211210310-fb2f337bc1b1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v24.0.8-0.20231213094340-0f82fd88610a+incompatible h1:OSAexdrbbGYSMOdaskqxEQR9N3CNv59ypbhD032P1TI=
-github.com/docker/cli v24.0.8-0.20231213094340-0f82fd88610a+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v24.0.8-0.20240103162225-b0c5946ba5d8+incompatible h1:hHBH6X0fAXobxcFmnrqiiUB+I0WrQ+65pjMZGW7p8h8=
-github.com/docker/cli v24.0.8-0.20240103162225-b0c5946ba5d8+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v25.0.0-beta.1+incompatible h1:bJzIgR4mKNpceAwwi19SqZK0AbztMc3nQTgnvxxyY/A=
-github.com/docker/cli v25.0.0-beta.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v25.0.1-0.20240119143135-01f933261885+incompatible h1:UkZcGfKrx1PUDTT/TEzeYpyeRvNVbNqsj01yasxHuvA=
-github.com/docker/cli v25.0.1-0.20240119143135-01f933261885+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v25.0.1+incompatible h1:mFpqnrS6Hsm3v1k7Wa/BO23oz0k121MTbTO1lpcGSkU=
-github.com/docker/cli v25.0.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v25.0.4-0.20240221083216-f67e569a8fb9+incompatible h1:crlBDc5Kfph4aUtWf9Rz+BtcNdB17bE3NLU+3+WuAaw=
-github.com/docker/cli v25.0.4-0.20240221083216-f67e569a8fb9+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v25.0.4+incompatible h1:DatRkJ+nrFoYL2HZUzjM5Z5sAmcA5XGp+AW0oEw2+cA=
-github.com/docker/cli v25.0.4+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v26.0.0+incompatible h1:90BKrx1a1HKYpSnnBFR6AgDq/FqkHxwlUyzJVPxD30I=
-github.com/docker/cli v26.0.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v26.1.0+incompatible h1:+nwRy8Ocd8cYNQ60mozDDICICD8aoFGtlPXifX/UQ3Y=
-github.com/docker/cli v26.1.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v26.1.3-0.20240513184838-60f2d38d5341+incompatible h1:9bTMRZTbwJvSrosCeCWS9o9cxtBxxpwOiwlrJZwSWb8=
-github.com/docker/cli v26.1.3-0.20240513184838-60f2d38d5341+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v27.0.1+incompatible h1:d/OrlblkOTkhJ1IaAGD1bLgUBtFQC/oP0VjkFMIN+B0=
-github.com/docker/cli v27.0.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v27.0.3+incompatible h1:usGs0/BoBW8MWxGeEtqPMkzOY56jZ6kYlSN5BLDioCQ=
-github.com/docker/cli v27.0.3+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v27.1.1+incompatible h1:goaZxOqs4QKxznZjjBWKONQci/MywhtRv2oNn0GkeZE=
-github.com/docker/cli v27.1.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v27.2.0+incompatible h1:yHD1QEB1/0vr5eBNpu8tncu8gWxg8EydFPOSKHzXSMM=
-github.com/docker/cli v27.2.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v27.2.2-0.20240909090509-65decb573126+incompatible h1:if+XpfWkGSpLf8NtVlYgvCeVvKW4Eba90LispMGC50M=
-github.com/docker/cli v27.2.2-0.20240909090509-65decb573126+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v27.3.0+incompatible h1:h7J5eiGdUbH2Q4EcGr1mFb20qzS7Nrot3EI9hwycpK0=
-github.com/docker/cli v27.3.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v27.3.1+incompatible h1:qEGdFBF3Xu6SCvCYhc7CzaQTlBmqDuzxPDpigSyeKQQ=
-github.com/docker/cli v27.3.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v27.3.2-0.20241107125754-eb986ae71b0c+incompatible h1:KqHavmeo5+ct30Z2UKxbVhUEfuzI9JZFgPdVVaWS4Uc=
-github.com/docker/cli v27.3.2-0.20241107125754-eb986ae71b0c+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v27.4.0+incompatible h1:/nJzWkcI1MDMN+U+px/YXnQWJqnu4J+QKGTfD6ptiTc=
-github.com/docker/cli v27.4.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v27.5.0+incompatible h1:aMphQkcGtpHixwwhAXJT1rrK/detk2JIvDaFkLctbGM=
-github.com/docker/cli v27.5.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v27.5.1+incompatible h1:JB9cieUT9YNiMITtIsguaN55PLOHhBSz3LKVc6cqWaY=
-github.com/docker/cli v27.5.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v28.0.0+incompatible h1:ido37VmLUqEp+5NFb9icd6BuBB+SNDgCn+5kPCr2buA=
-github.com/docker/cli v28.0.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v28.0.1+incompatible h1:g0h5NQNda3/CxIsaZfH4Tyf6vpxFth7PYl3hgCPOKzs=
-github.com/docker/cli v28.0.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v28.0.2+incompatible h1:cRPZ77FK3/IXTAIQQj1vmhlxiLS5m+MIUDwS6f57lrE=
-github.com/docker/cli v28.0.2+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/cli v28.1.0-rc.2+incompatible h1:BDhiR2nacubawpKAWFLqZmjGkARWPtYmUmy5gg4k/f8=
-github.com/docker/cli v28.1.0-rc.2+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
-github.com/docker/compose-cli v1.0.35 h1:uZyEHLalfqBS2PiTpA1LAULyJmuQ+YtZg7nG4Xl3/Cc=
-github.com/docker/compose-cli v1.0.35/go.mod h1:mSXI4hFLpRU3EtI8NTo32bNwI0UXSr8jnq+/rYjGAUU=
-github.com/docker/compose/v2 v2.22.0 h1:3rRz4L7tPU75wRsV8JZh2/aTgerQvPa1cpzZN+tHqUY=
-github.com/docker/compose/v2 v2.22.0/go.mod h1:W+OVmnkJP0a62v8KnjtpXS0qrOdLnrxGJmKEU2dD4IQ=
-github.com/docker/compose/v2 v2.23.0 h1:OX1MiAUn8LSfW0F3yOhUYnKZhnSj9qy29fSJn3tT3h4=
-github.com/docker/compose/v2 v2.23.0/go.mod h1:548Y4k6qPQXdpouRp3EPx76k/ATYU5nrxULPSOsMM9U=
-github.com/docker/compose/v2 v2.23.1 h1:wLgblcBfAgbXeNaxxKAIL//I+xgoyZ1BBbWFNfoLQ3I=
-github.com/docker/compose/v2 v2.23.1/go.mod h1:FCqosV9Gc3/QOoRgYSjVnweNqDyr6LsAyLca5VPrEGU=
-github.com/docker/compose/v2 v2.23.3 h1:2p2biZqpUvPzC8J7nDl+ankVQNCCAk2IZJ4eg1S+6BE=
-github.com/docker/compose/v2 v2.23.3/go.mod h1:lUweVMN13YR0a9M7qdKulTSMS1kYdAysYNJlFEnDMCw=
-github.com/docker/compose/v2 v2.24.0 h1:Gvmg3E5/Rqa4G340sYcUk/DIegT5Nod2ZV3MqR248j8=
-github.com/docker/compose/v2 v2.24.0/go.mod h1:sDypMTKq6Mrp0W5NZ6+uiqxR9zEukI1RVuFRqwBTljs=
-github.com/docker/compose/v2 v2.24.1 h1:Mk14AOkxetMKrWb1bOnx7bEfS+v/moaCZnU69QqUw6A=
-github.com/docker/compose/v2 v2.24.1/go.mod h1:rrqu0bPBN/HD2wRSNwVN+V9SDfhVQnKxF1DP9B9WOdI=
-github.com/docker/compose/v2 v2.24.2-0.20240119115212-388169011f47 h1:4vvuN0itjUryASt/WgrrLt7Tat7L53Ovt6Y1tLmVZPQ=
-github.com/docker/compose/v2 v2.24.2-0.20240119115212-388169011f47/go.mod h1:YMMi6kNJdi3gELhMyhdnZinMiZvSWoyAl6i7XoeqFDg=
-github.com/docker/compose/v2 v2.24.2 h1:uxH1Be7w/T2eozzgcftsTuOVOsxsOruJwJFLu6wsC6I=
-github.com/docker/compose/v2 v2.24.2/go.mod h1:0PmmvCX+jo4kCp9JJxFY/Za7nCPwSzzRcX/g8y2gXTA=
-github.com/docker/compose/v2 v2.24.4 h1:uBlpNmv27Gd9vlExUkQcgmLuNYlGloxX6yCt7Oau8vk=
-github.com/docker/compose/v2 v2.24.4/go.mod h1:409UYNwh+eoKY5UST4ORZMuMNj+nBUuEZC3V+WF8CqA=
-github.com/docker/compose/v2 v2.24.5 h1:7K173fhy+ghA88C8ib5YNa+kAZCx0CBeGW7lHcdoPZw=
-github.com/docker/compose/v2 v2.24.5/go.mod h1:gg+RsqCXYD/TOIJgya4N9mtj/UmFJGEls7y3h/kadVE=
-github.com/docker/compose/v2 v2.24.6 h1:V5fOXgga0hYy4wHsygCquO6/k++8q3WuckU7Qo1cnXk=
-github.com/docker/compose/v2 v2.24.6/go.mod h1:ugV3/2KoKEeM98ZYF9vsYwnSExC4xLGxblAqXB6HUXQ=
-github.com/docker/compose/v2 v2.24.7 h1:1WSo4CVf18tnGJMC6V78jYsAxSDD61ry6L3JwVT+8EI=
-github.com/docker/compose/v2 v2.24.7/go.mod h1:7U3QbXdRJfBylTgkdlrjOg8hWLZqM09mof9DVZ5Fh4E=
-github.com/docker/compose/v2 v2.25.0 h1:UMCrWFItKdXXrlbxvA63V3aFb4Nr3zmlSY2GvJIqJW0=
-github.com/docker/compose/v2 v2.25.0/go.mod h1:M0PSYeTsp2ZEZJGhvzNTBtJeJRN7ZBGb4Ft1mUteTac=
-github.com/docker/compose/v2 v2.26.1 h1:27fAR5jVzNUYwY/9ppIjrPqGYLW5HtOTq2aYGBMCtA0=
-github.com/docker/compose/v2 v2.26.1/go.mod h1:5iVCMlr18ab0NlMxIPdtTgThTkzb34Z/zj15N7KSW+s=
-github.com/docker/compose/v2 v2.27.0 h1:FKyClQdErCxUZULC2zo6Jn5ve+epFPe/Y0HaxjmUzNg=
-github.com/docker/compose/v2 v2.27.0/go.mod h1:uaqwmY6haO8wXWHk+LAsqqDapX6boH4izRKqj/E7+Bo=
-github.com/docker/compose/v2 v2.27.2 h1:8uvz019AZIPmw8+rnLBubAuyt9SEoU/pyCcAJPXMq0A=
-github.com/docker/compose/v2 v2.27.2/go.mod h1:c6QJ/VVZrzVu97Ur1jylFLivvTkFdef1rSzmnQAO3DA=
-github.com/docker/compose/v2 v2.28.0 h1:GSE/IC/cgWsv7KA5uoBrwVdHQbWS1R5XvvcEgoAQUOY=
-github.com/docker/compose/v2 v2.28.0/go.mod h1:YDhEGZHuiXEqJu5Clc8N4si/CJIXHWU0Lf1ph9NxFYA=
-github.com/docker/compose/v2 v2.28.1 h1:ORPfiVHrpnRQBDoC3F8JJyWAY8N5gWuo3FgwyivxFdM=
-github.com/docker/compose/v2 v2.28.1/go.mod h1:wDtGQFHe99sPLCHXeVbCkc+Wsl4Y/2ZxiAJa/nga6rA=
-github.com/docker/compose/v2 v2.29.0 h1:qPBhzfjT2zkxUXuu+TcbQq292bPpB0ozzVHot2w2IN0=
-github.com/docker/compose/v2 v2.29.0/go.mod h1:95QFO8lue3WJmLUDSdOLBkm7KdGhcG6U+RvVxrQIzOo=
-github.com/docker/compose/v2 v2.29.2 h1:gRlR2ApZ0IGcwmSUb/wlEVCk18Az8b7zl03hJArldOg=
-github.com/docker/compose/v2 v2.29.2/go.mod h1:U+yqqZqYPhILehkmmir+Yh7ZhCfkKqAvaZdrM47JBRs=
-github.com/docker/compose/v2 v2.30.0 h1:EjtEBeIPeqzlY3DUQhdjkiMwigX8TrUrgPAyAqey1d0=
-github.com/docker/compose/v2 v2.30.0/go.mod h1:WlU5gYgsYfNLuDeUdTusvutEC5PV3sDc15aClbR5lPw=
-github.com/docker/compose/v2 v2.30.1 h1:AwDaEcmgskxaI75Wjt3KL6/Xqq/GXKUQcBpo/RqMEkw=
-github.com/docker/compose/v2 v2.30.1/go.mod h1:pt/uv8KQ6VaM0IbHZwB1UdwDIs9PB4nN4LoWst+dqXc=
-github.com/docker/compose/v2 v2.30.2 h1:7PypFsyl5wjlSeOyx3LCb8XMcAGkb+D0fqM47OIKe8I=
-github.com/docker/compose/v2 v2.30.2/go.mod h1:ND4+yaNoJ3Jh1OgrEO64uzMq/VKRqBkMS8zpb65Fve8=
-github.com/docker/compose/v2 v2.30.3 h1:e8H7xGLCZOeFo46GEtyDGHlkBbNgXqbXKIXPOSL8cfU=
-github.com/docker/compose/v2 v2.30.3/go.mod h1:ayPsSsRSc5WpVFehPrTDFuljAydxaf8g0aM9UKbaMXk=
-github.com/docker/compose/v2 v2.31.0 h1:8Sm0c4MjIhksguxIA5koYMXoTJDAp/CaZ1cdZrMvMdw=
-github.com/docker/compose/v2 v2.31.0/go.mod h1:oQq3UDEdsnB3AUO72AxaoeLbkCgmUu1+8tLzvmphmXA=
-github.com/docker/compose/v2 v2.32.2/go.mod h1:fcK4rrf1bm8pfDsYdZIR+l4RSk9j6HVtBvJKGYyXsZ4=
-github.com/docker/compose/v2 v2.32.3 h1:7KKVpTudYUrqs9GueTnJ+N6qnnzI2bqmANq6kXfmuv8=
-github.com/docker/compose/v2 v2.32.3/go.mod h1:fcK4rrf1bm8pfDsYdZIR+l4RSk9j6HVtBvJKGYyXsZ4=
-github.com/docker/compose/v2 v2.32.4 h1:h1I7GlJ1NCXKqM0nCVVsMrD/7TdIG48HNgRufcBF1KQ=
-github.com/docker/compose/v2 v2.32.4/go.mod h1:fcK4rrf1bm8pfDsYdZIR+l4RSk9j6HVtBvJKGYyXsZ4=
-github.com/docker/compose/v2 v2.33.1 h1:i/V1gUpdbc4tMRfx30aYzw7oHKM8NGB2Oe4AUJUospw=
-github.com/docker/compose/v2 v2.33.1/go.mod h1:TdDv/kdWOFrCWum5SVxVGVr+P9znSZepukHF1Dam25U=
-github.com/docker/compose/v2 v2.34.0 h1:mUhgA6AiRVO9hEndD2G2oOQi5Y0g/4H8xSPVUc5TYdU=
-github.com/docker/compose/v2 v2.34.0/go.mod h1:TgTD4Ku0vOSB3NZgOXp6HcCE6wDSBjg7r8bjWraV5/4=
-github.com/docker/compose/v2 v2.35.0 h1:bU23OeFrbGyHYrKijMSEwkOeDg2TLhAGntU2F3hwX1o=
-github.com/docker/compose/v2 v2.35.0/go.mod h1:S5ejUILn9KTYC6noX3IxznWu3/sb3FxdZqIYbq4seAk=
-github.com/docker/compose/v2 v2.35.1 h1:oRt5EE22een6DEAkNNQcuzJGhBS2rcMtEKdbfMhFIgk=
-github.com/docker/compose/v2 v2.35.1/go.mod h1:Ydd9ceg7VBOPSVAsDDKfyGGAkjejH3cD91GSmHjuRhI=
-github.com/docker/distribution v2.8.2+incompatible h1:T3de5rq0dB1j30rp0sA2rER+m322EBzniBPB6ZIzuh8=
-github.com/docker/distribution v2.8.2+incompatible/go.mod h1:J2gT2udsDAN96Uj4KfcMRqY0/ypR+oyYUYmja8H+y+w=
+github.com/distribution/reference v0.6.0 h1:0IXCQ5g4/QMHHkarYzh5l+u8T3t73zM5QvfrDyIgxBk=
+github.com/distribution/reference v0.6.0/go.mod h1:BbU0aIcezP1/5jX/8MP0YiH4SdvB5Y4f/wlDRiLyi3E=
+github.com/dlclark/regexp2 v1.11.0 h1:G/nrcoOa7ZXlpoa/91N3X7mM3r8eIlMBBJZvsz/mxKI=
+github.com/dlclark/regexp2 v1.11.0/go.mod h1:DHkYz0B9wPfa6wondMfaivmHpzrQ3v9q8cnmRbL6yW8=
+github.com/dlclark/regexp2 v1.11.5 h1:Q/sSnsKerHeCkc/jSTNq1oCm7KiVgUMZRDUoRu0JQZQ=
+github.com/docker/buildx v0.30.1 h1:3vthfaTQOLt5QfN2nl7rKuPLUvx69nL5ZikFIXp//c8=
+github.com/docker/buildx v0.30.1/go.mod h1:8nwT0V6UNYNo9rXq6WO/BQd9KrJ0JYcY/QX6x0y1Oro=
+github.com/docker/buildx v0.31.0 h1:1hc/VRXlViJAG8QEReNa46Ui15qyrbfYTVl29K8yI2c=
+github.com/docker/buildx v0.31.0/go.mod h1:SD+jYLnt3S4SXqohVtV+8z+dihnOgwMJ8t+bLQvsaCk=
+github.com/docker/buildx v0.31.1 h1:zbvbrb9nxBNVV8nnI33f2F+4aAZBA1gY+AmeBFflMqY=
+github.com/docker/buildx v0.31.1/go.mod h1:SD+jYLnt3S4SXqohVtV+8z+dihnOgwMJ8t+bLQvsaCk=
+github.com/docker/buildx v0.32.0 h1:BjSqjSkQDnwgcsIC8NV3D4i6OKIXqu6xUWrg+G9mq5s=
+github.com/docker/buildx v0.32.0/go.mod h1:46Le9J2gV41DJ3zuGBc+Lf+ASYA4saGd0y/dGly8Wmg=
+github.com/docker/buildx v0.32.1 h1:ecen0VNo7UINEv+Wx7xDPlTH5nQ1EaxzFOoslYIISuk=
+github.com/docker/buildx v0.32.1/go.mod h1:46Le9J2gV41DJ3zuGBc+Lf+ASYA4saGd0y/dGly8Wmg=
+github.com/docker/buildx v0.33.0 h1:xuZeuQe/C/2tvLDgiIA6+Ynq3FFWSfsGNWIHM3q1hD8=
+github.com/docker/buildx v0.33.0/go.mod h1:7JVma62htERKE5iy5YD1q64PKiAHUzXuhSBd4oq3I74=
+github.com/docker/buildx v0.34.0 h1:ivBYUNCMKMOwqCziC66p79dNkd8mv+DSrnyrY9PY9vQ=
+github.com/docker/buildx v0.34.0/go.mod h1:RG8352TWR2gg8P7uqu1ZvlSpqxUcnVvGfjqQsKpmSAY=
+github.com/docker/buildx v0.34.1 h1:gDnnCPmnbPt/5FTABZIhTlBc6kYibWNyVJzE29Mb5yM=
+github.com/docker/buildx v0.34.1/go.mod h1:RG8352TWR2gg8P7uqu1ZvlSpqxUcnVvGfjqQsKpmSAY=
+github.com/docker/buildx v0.35.0 h1:5r/ZcAC0s2oZ1XOJHvYFYbj44I4rxRsIdfsRBeXClks=
+github.com/docker/buildx v0.35.0/go.mod h1:kO/9ZBoZmhi1OsZbeLJqWclckB2TKu/yeW6aj6xxdt0=
+github.com/docker/buildx v0.36.0 h1:5UYbvkIXhkjiRZG15ZoWuA1BIuFatexA9yeL+b72MpM=
+github.com/docker/buildx v0.36.0/go.mod h1:APOldMT9ejTIiYJ44OxhFX1zt+MM1cR9zz4DQLq8qLw=
+github.com/docker/buildx v0.36.1 h1:U7JTUSSeooFXbG+0HcI+CMjEIkvuZgJegXRZ1q7K63Q=
+github.com/docker/buildx v0.36.1/go.mod h1:pkpx66TqJD4HOS65fORu9MYBEDbeiRxnGdN3VpH8SPM=
+github.com/docker/cli v29.1.2+incompatible h1:s4QI7drXpIo78OM+CwuthPsO5kCf8cpNsck5PsLVTH8=
+github.com/docker/cli v29.1.2+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.1.5+incompatible h1:GckbANUt3j+lsnQ6eCcQd70mNSOismSHWt8vk2AX8ao=
+github.com/docker/cli v29.1.5+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.2.0+incompatible h1:9oBd9+YM7rxjZLfyMGxjraKBKE4/nVyvVfN4qNl9XRM=
+github.com/docker/cli v29.2.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.2.1+incompatible h1:n3Jt0QVCN65eiVBoUTZQM9mcQICCJt3akW4pKAbKdJg=
+github.com/docker/cli v29.2.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.3.0+incompatible h1:z3iWveU7h19Pqx7alZES8j+IeFQZ1lhTwb2F+V9SVvk=
+github.com/docker/cli v29.3.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.3.1+incompatible h1:M04FDj2TRehDacrosh7Vlkgc7AuQoWloQkf1PA5hmoI=
+github.com/docker/cli v29.3.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.4.0+incompatible h1:+IjXULMetlvWJiuSI0Nbor36lcJ5BTcVpUmB21KBoVM=
+github.com/docker/cli v29.4.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.4.3+incompatible h1:u+UliYm2J/rYrIh2FqHQg32neRG8GjbvNuwQRTzGspU=
+github.com/docker/cli v29.4.3+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.5.1+incompatible h1:NiufLAJoRcPauFoBNYthfuM4REFwM8H2h9xnLABNHGs=
+github.com/docker/cli v29.5.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.5.3+incompatible h1:nbEFfz774vBwQ5KRYv7c/AghjReqnGISvrRhzjV0evs=
+github.com/docker/cli v29.5.3+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.6.0+incompatible h1:nw9himxMMZ7eIeherJNlKQq+acnlzGgHd+4uf10QRSc=
+github.com/docker/cli v29.6.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.6.1+incompatible h1:oO7F4nn3Ovr/5TlfTUWFbMwBSS/B7Xs6Epv26gBrUP8=
+github.com/docker/cli v29.6.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.6.2+incompatible h1:/bjePvcbbFTnRrMfWJBY7AjfICdsiLVgHn6LwTVOcqw=
+github.com/docker/cli v29.6.2+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.7.1+incompatible h1:ILZpP6B7fedIr6ANy824QkDp1WMJuouIq0O2SrBkB2w=
+github.com/docker/cli v29.7.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/cli v29.7.2+incompatible h1:dlkwallR8XqfeVnA2ELEhdwvb4lsSwuB4IgsG8Q9cLY=
+github.com/docker/cli v29.7.2+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
+github.com/docker/compose/v5 v5.0.0 h1:J2uMCzJ/5xLcoIVVXvMmPe6HBzVQpmJThKa7Qk7Xldc=
+github.com/docker/compose/v5 v5.0.0/go.mod h1:BurapGv8zmYnsbSmlpCz5EU2Pi3YFV/PjeUnoFpcw64=
+github.com/docker/compose/v5 v5.0.1 h1:5yCjDJbwUqcuI+6WNFHNWz2/3vyBDsNnfe8LlFjyxEc=
+github.com/docker/compose/v5 v5.0.1/go.mod h1:vuKBtnRuvsVIlYHzdPkF3SToljqR+pFJseO5lDBuF18=
+github.com/docker/compose/v5 v5.0.2 h1:OTBsvKsim2rVNUBrb9pP5byiGG5trTt+uO3qr6WIQYo=
+github.com/docker/compose/v5 v5.0.2/go.mod h1:MbI7iBpjcgTN27JC4cYYR1mmfmaWEqEgqKKfbEGFK1c=
+github.com/docker/compose/v5 v5.1.2 h1:HxtfGZA0DESw/+hvrNJDjM8VKmCond7OkmgVJCHku48=
+github.com/docker/compose/v5 v5.1.2/go.mod h1:JJ2H+lRSugOH50/zxCbkBwN8jU91qDtRCp7gEHWZdgo=
+github.com/docker/compose/v5 v5.1.4 h1:72mGZplTVlbq6JxxhCW/bX2o1h+tT8mwt7mc+QtmA6o=
+github.com/docker/compose/v5 v5.1.4/go.mod h1:ImZiWTwIFm7BziHjX2MZVzwOiIkClXRzv+rkU18lQoc=
+github.com/docker/compose/v5 v5.2.0 h1:WuZgtAM91BjFWy7xMKcM2Huq9OksVqRgkgBKFiEXs2Q=
+github.com/docker/compose/v5 v5.2.0/go.mod h1:tjYsBMooQQZ8XGtVoUnc+/T9peXtkMmTdmMakW8/ZXE=
+github.com/docker/compose/v5 v5.3.0 h1:JdcwUbJi2al3vOi+PZmjqPzHBIYyezZ9OaCXLO5I6f0=
+github.com/docker/compose/v5 v5.3.0/go.mod h1:iZngpxvhuLn2VYsKS5cIa/5bTPKIdLGi5ZyjcdHBaZQ=
+github.com/docker/compose/v5 v5.3.1 h1:rZiPwrtg1dBmVGcHiioLtzCS+TcvZq81zl0zs2BwtbE=
+github.com/docker/compose/v5 v5.3.1/go.mod h1:qTcMBinqXyp2CQT6OJfBqtG8UPfYgOk1rwqIGYKLpGk=
+github.com/docker/compose/v5 v5.4.0 h1:i0xFmVvWv9QILfRE2PD07GmQqJYjpYAGutafIrJLURE=
+github.com/docker/compose/v5 v5.4.0/go.mod h1:bNeEncwZhG0F4MN+0zgln4EA2ILqGZC7knRI8QYJz9U=
+github.com/docker/compose/v5 v5.5.0 h1:B5Eh5CtlbscCMlbyMydbEj3rpIuP9GthdD7PC0IsvgQ=
+github.com/docker/compose/v5 v5.5.0/go.mod h1:5yn5qs7G7V7OZc1Kkd6wLz72Le0C45xLNJQ7dgASvMk=
 github.com/docker/distribution v2.8.3+incompatible h1:AtKxIZ36LoNK51+Z6RpzLpddBirtxJnzDrHLEKxTAYk=
-github.com/docker/go v1.5.1-1.0.20160303222718-d30aec9fd63c/go.mod h1:CADgU4DSXK5QUlFslkQu2yW2TKzFZcXq/leZfM0UH5Q=
-github.com/docker/go-connections v0.4.0/go.mod h1:Gbd7IOopHjR8Iph03tsViu4nIes5XhDvyHbTtUxmeec=
-github.com/docker/go-events v0.0.0-20190806004212-e31b211e4f1c/go.mod h1:Uw6UezgYA44ePAFQYUehOuCzmy5zmg/+nl2ZfMWGkpA=
-github.com/docker/go-metrics v0.0.1/go.mod h1:cG1hvH2utMXtqgqqYE9plW6lDxS3/5ayHzueweSI3Vw=
-github.com/docker/libtrust v0.0.0-20150526203908-9cbd2a1374f4/go.mod h1:cyGadeNEkKy96OOhEzfZl+yxihPEzKnqJwvfuSUqbZE=
-github.com/docker/scout-cli v0.16.1 h1:kIcWkaA+cEwnC0nIjNlc8dnlXbV4D8Vyu3yrRUPB9xs=
-github.com/docker/scout-cli v0.16.1/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v0.16.2-0.20230623100159-43178dbabf53 h1:FA7tj4Bnu+jFJdwB5D6CCGTYvLfNkjGqjvvZmg3fcLc=
-github.com/docker/scout-cli v0.16.2-0.20230623100159-43178dbabf53/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v0.17.0 h1:fYFEMqhjVxbbKu48Djogwrn/lB1D/CJqnq/gDYfSs38=
-github.com/docker/scout-cli v0.17.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v0.19.0 h1:PGpAqercDHC4M0KsQwP+txk0sG+VVB23njuFurOf8Vw=
-github.com/docker/scout-cli v0.19.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v0.20.0 h1:+rj/uckRFs8vzQSxcWsVU4v1IiyWDcPvj8bMOxxYutI=
-github.com/docker/scout-cli v0.20.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v0.22.3 h1:STf1Oq0+PSVaWEwNZ9UleHTEZ0JUP1py6eQaRK0qivA=
-github.com/docker/scout-cli v0.22.3/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v0.23.0 h1:oFCNiO+11WhcnsXj3MF6uqJD49oBPMdJ3Pdq9XfZa4I=
-github.com/docker/scout-cli v0.23.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v0.23.3 h1:ToQ/Gw1clQ2GJ47Yt0HCefJB55oPOHZYH6rVxGdfF7Y=
-github.com/docker/scout-cli v0.23.3/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v0.24.1 h1:ga1J6dsKXfhBQ98wKbb+GWncuMdqErxhpLMxPSMqH+g=
-github.com/docker/scout-cli v0.24.1/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.0.2 h1:KweJ2S/WXncRIv+9+GrNI4bq/5TjcWY8WyWqgfV1zdM=
-github.com/docker/scout-cli v1.0.2/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.0.9 h1:P2Rs+HhVOIoSJZ1fcVuSDaxvV/8dCJTFdb3shrQtj5E=
-github.com/docker/scout-cli v1.0.9/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.2.0 h1:cjtsf7s2f6NO9OxgXWPW3DGxaTKVU58JKmVtaVMc0RA=
-github.com/docker/scout-cli v1.2.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.3.0 h1:mL9y1yB/DR/dAar71z0w8u8et9o2272Mrjxtb59ds3M=
-github.com/docker/scout-cli v1.3.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.4.1 h1:jRHO3LI3x2eMrvObKC6uadoRATbwZSXm1NafSzo9Cu4=
-github.com/docker/scout-cli v1.4.1/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.6.0 h1:07Kn2d/AshUSUk64ArZzE31lj4h7waGi8tjrFXxMZLY=
-github.com/docker/scout-cli v1.6.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.7.0 h1:2dEbQKqkxM6wsJab/Ma3EJacS9ZrkVs1C4KbjXggJjY=
-github.com/docker/scout-cli v1.7.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.8.0 h1:rxwU9Xzt1LhqSY37ZVe/GPRCQxrEaQNipOMpCrUdGns=
-github.com/docker/scout-cli v1.8.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.9.3 h1:u3lKQ7A1EvT3qNe5lR2c8dTNcAGIoSmH8HvSYarLlJY=
-github.com/docker/scout-cli v1.9.3/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.10.0 h1:C8Gm+6Oc7NqhtZ/UoACv3N2LaP1jqkhlIDRhBOqMBng=
-github.com/docker/scout-cli v1.10.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.11.0 h1:I310kNhjw3oeKe8T1cQEh6yPgy6VtpuwzjWchETn8KU=
-github.com/docker/scout-cli v1.11.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.12.0 h1:NhmT4BzL2lYiIk5hPFvK5FzQ8izbLDL3/Rugcyulv1M=
-github.com/docker/scout-cli v1.12.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.13.0 h1:RThUM56yooV5izqgMEYQS+a6Yx+vGmZofJwX0qjgkco=
-github.com/docker/scout-cli v1.13.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/docker/scout-cli v1.15.0 h1:VhA9niVftEyZ9f5KGwKnrSfQOp2X3uIU3VbE/gTVMTM=
-github.com/docker/scout-cli v1.15.0/go.mod h1:Eo1RyCJsx3ldz/YTY5yGxu9g9mwTYbRUutxQUkow3Fc=
-github.com/elazarl/goproxy v0.0.0-20191011121108-aa519ddbe484/go.mod h1:Ro8st/ElPeALwNFlcTpWmkr6IoMFfkjXAvTHpevnDsM=
-github.com/evanphx/json-patch v4.9.0+incompatible/go.mod h1:50XU6AFN0ol/bzJsmQLiYLvXMP4fmwYFNcr97nuDLSk=
-github.com/fatih/color v1.7.0/go.mod h1:Zm6kSWBoL9eyXnKyktHP6abPY2pDugNf5KwzbycvMj4=
-github.com/form3tech-oss/jwt-go v3.2.2+incompatible/go.mod h1:pbq4aXjuKjdthFRnoDwaVPLA+WlJuPGy+QneDUgJi2k=
-github.com/fvbommel/sortorder v1.0.1/go.mod h1:uk88iVf1ovNn1iLfgUVU2F9o5eO30ui720w+kxuqRs0=
+github.com/docker/distribution v2.8.3+incompatible/go.mod h1:J2gT2udsDAN96Uj4KfcMRqY0/ypR+oyYUYmja8H+y+w=
+github.com/docker/docker v28.5.2+incompatible h1:DBX0Y0zAjZbSrm1uzOkdr1onVghKaftjlSWt4AFexzM=
+github.com/docker/docker v28.5.2+incompatible/go.mod h1:eEKB0N0r5NX/I1kEveEz05bcu8tLC/8azJZsviup8Sk=
+github.com/docker/docker-agent v1.96.0 h1:wt018652ejWtHpMOdhvjwIxaeI46rc6o8snqb9QsmiI=
+github.com/docker/docker-agent v1.96.0/go.mod h1:PJlLIntWPY0KPepCIeR4+WRo2fmQnmnONYBmb/ULorM=
+github.com/docker/docker-agent v1.103.0 h1:hmS2u0fU4MMyUnXrjJlhcfjpBUzkBEBM9/DrmL0yTpY=
+github.com/docker/docker-agent v1.103.0/go.mod h1:KUYwjuxrs2N3BBrAQ6CMNPVQxOfoZoLUYpbxyGTM02w=
+github.com/docker/docker-agent v1.110.0 h1:B5LJRkEvIk1WLojMR09gD6ZAD2hD43SIRSbjKs+yyc4=
+github.com/docker/docker-agent v1.110.0/go.mod h1:TcrFxPYbc9SL0ouAcb/YwwjePfS0ULYkzfTJkvDUfzY=
+github.com/docker/docker-agent v1.120.0 h1:aogSNNlZWiL/6EYmrXhEtkqIgEcL7wt2bhYItgjan4o=
+github.com/docker/docker-agent v1.120.0/go.mod h1:HgHOV3OkqM1Hl0qD7iTCBZSBNWpy5mWN2s8tr2/NdOA=
+github.com/docker/docker-agent v1.122.0 h1:xOei5d7L1M0stvZNwULnOssOS4CzDRE2Xj7k192rS3Q=
+github.com/docker/docker-agent v1.122.0/go.mod h1:HgHOV3OkqM1Hl0qD7iTCBZSBNWpy5mWN2s8tr2/NdOA=
+github.com/docker/docker-agent v1.124.0 h1:dNVrrRozYq5IMgokjaSm6grYReEMP1inrEaHVnVQiyg=
+github.com/docker/docker-agent v1.124.0/go.mod h1:CyLlU/NVcq3kSjffVzRKNaO0XIngqKPOxhgmbru+LWE=
+github.com/docker/docker-agent v1.126.0 h1:GjX84SHcvS4Txo7dGjatWhKGFLNpDqKcGAoIsyvfj40=
+github.com/docker/docker-agent v1.126.0/go.mod h1:K38q6CsnSTHDOrLP46HLGhKwv3i+vjmu33cjmjpkAvg=
+github.com/docker/docker-credential-helpers v0.9.3 h1:gAm/VtF9wgqJMoxzT3Gj5p4AqIjCBS4wrsOh9yRqcz8=
+github.com/docker/docker-credential-helpers v0.9.3/go.mod h1:x+4Gbw9aGmChi3qTLZj8Dfn0TD20M/fuWy0E5+WDeCo=
+github.com/docker/docker-credential-helpers v0.9.5 h1:EFNN8DHvaiK8zVqFA2DT6BjXE0GzfLOZ38ggPTKePkY=
+github.com/docker/docker-credential-helpers v0.9.5/go.mod h1:v1S+hepowrQXITkEfw6o4+BMbGot02wiKpzWhGUZK6c=
+github.com/docker/docker-credential-helpers v0.9.8 h1:bIREROb7So6PRlq6KTtdS9MPEjC29OQRkFNlvK2OX8Q=
+github.com/docker/go-connections v0.6.0 h1:LlMG9azAe1TqfR7sO+NJttz1gy6KO7VJBh+pMmjSD94=
+github.com/docker/go-connections v0.6.0/go.mod h1:AahvXYshr6JgfUJGdDCs2b5EZG/vmaMAntpSFH5BFKE=
+github.com/docker/go-connections v0.7.0 h1:6SsRfJddP22WMrCkj19x9WKjEDTB+ahsdiGYf0mN39c=
+github.com/docker/go-units v0.5.0 h1:69rxXcBk27SvSaaxTtLh/8llcHD8vYHT7WSdRZ/jvr4=
+github.com/docker/go-units v0.5.0/go.mod h1:fgPhTUdO+D/Jk86RDLlptpiXQzgHJF7gydDDbaIK4Dk=
+github.com/docker/mcp-gateway v0.22.0 h1:l4t+HRNHxR7Jn545KDeXaeiEEhkCDBeWMTyuCaXVH7A=
+github.com/docker/mcp-gateway v0.22.0/go.mod h1:4sGoRoMeu8lj4a/HbAd/jdxXjMNVMegNnjCqmhsED+I=
+github.com/docker/model-runner v1.0.3 h1:04qSAOsFvxOYIejMOc2XGug+WQSTax0RO0OMA7DkwTU=
+github.com/docker/model-runner v1.0.3/go.mod h1:qRIuXMeZ5dnL4A9e/+BUtQOSZAS0PBxUkLN51XYpLOE=
+github.com/docker/model-runner v1.1.8 h1:dAdrvz5oHxnWToM732NOtbwK5hBSUQpX87JQ6AQPDUE=
+github.com/docker/model-runner v1.1.8/go.mod h1:BUkuBVgWQhMfN6rY+1KesorT9lwG2D0xCNY8Co9xKCI=
+github.com/docker/model-runner v1.1.9-0.20260303081710-59280ed7abd5 h1:oY1RUGY7sDj5DUjqlxWAIJR4olBp3298iL8mWYFjXFg=
+github.com/docker/model-runner v1.1.9-0.20260303081710-59280ed7abd5/go.mod h1:S1ttvsnofZx35unrXuzhcbZ7fWOpNhLPawhNrRMHp+c=
+github.com/docker/model-runner v1.1.24 h1:SmlaZOlXJ5YC5ouxgwBj1qkfFSdgIw4BSFqnA3N86m8=
+github.com/docker/model-runner v1.1.24/go.mod h1:Sz8p8xoQiRW4Kbx8u7zAGynPESSJc/EZrPjHi+Ghtoo=
+github.com/docker/model-runner v1.1.28 h1:SrGTSP8X0v3z5m1jEzZu5n3OnOJbDZom6UMmrSZ3iQE=
+github.com/docker/model-runner v1.1.28/go.mod h1:AVBP5brJ8TkQD94cLKMVTn5jkrV1o8/b20hkeL8WTsE=
+github.com/docker/model-runner v1.1.36 h1:S4a8klEIgNZh+0xwhnEUhKdAmJqPuhOs3bPGFT1C9pk=
+github.com/docker/model-runner v1.1.36/go.mod h1:+ReAxM83s9+TLIBcZkHlng8nfn204CZYzbx4Sg7fSrE=
+github.com/docker/model-runner/cmd/cli v1.0.3 h1:oycm6fHwhFBNM47Y2Ka7nUSsrbSG3FL7NMShjTRuxak=
+github.com/docker/model-runner/cmd/cli v1.0.3/go.mod h1:86LCLsk93vuevYRDKoBxwGusyGlW+UnKCnbXJ7m6Zjo=
+github.com/docker/model-runner/pkg/go-containerregistry v0.0.0-20251121150728-6951a2a36575 h1:N2yLWYSZFTVLkLTh8ux1Z0Nug/F78pXsl2KDtbWhe+Y=
+github.com/docker/model-runner/pkg/go-containerregistry v0.0.0-20251121150728-6951a2a36575/go.mod h1:gbdiY0X8gr0J88OfUuRD29JXCWT9jgHzPmrqTlO15BM=
+github.com/elastic/go-sysinfo v1.15.4 h1:A3zQcunCxik14MgXu39cXFXcIw2sFXZ0zL886eyiv1Q=
+github.com/elastic/go-sysinfo v1.15.4/go.mod h1:ZBVXmqS368dOn/jvijV/zHLfakWTYHBZPk3G244lHrU=
+github.com/elastic/go-windows v1.0.2 h1:yoLLsAsV5cfg9FLhZ9EXZ2n2sQFKeDYrHenkcivY4vI=
+github.com/elastic/go-windows v1.0.2/go.mod h1:bGcDpBzXgYSqM0Gx3DM4+UxFj300SZLixie9u9ixLM8=
+github.com/emirpasic/gods/v2 v2.0.0-alpha h1:dwFlh8pBg1VMOXWGipNMRt8v96dKAIvBehtCt6OtunU=
+github.com/emirpasic/gods/v2 v2.0.0-alpha/go.mod h1:W0y4M2dtBB9U5z3YlghmpuUhiaZT2h6yoeE+C1sCp6A=
+github.com/fatih/color v1.18.0 h1:S8gINlzdQ840/4pfAwic/ZE0djQEH3wM94VfqLTZcOM=
+github.com/fatih/color v1.18.0/go.mod h1:4FelSpRwEGDpQ12mAdzqdOukCy4u8WUtOY6lkT/6HfU=
+github.com/fatih/color v1.19.0 h1:Zp3PiM21/9Ld6FzSKyL5c/BULoe/ONr9KlbYVOfG8+w=
+github.com/felixge/httpsnoop v1.0.4 h1:NFTV2Zj1bL4mc9sqWACXbQFVBBg2W3GPvqp8/ESS2Wg=
+github.com/felixge/httpsnoop v1.0.4/go.mod h1:m8KPJKqk1gH5J9DgRY2ASl2lWCfGKXixSwevea8zH2U=
+github.com/fsnotify/fsnotify v1.4.9/go.mod h1:znqG4EE+3YCdAaPaxE2ZRY/06pZUdp0tY4IgpuI1SZQ=
+github.com/fsnotify/fsnotify v1.6.0/go.mod h1:sl3t1tCWJFWoRz9R8WJCbQihKKwmorjAbSClcnxKAGw=
+github.com/fsnotify/fsnotify v1.9.0 h1:2Ml+OJNzbYCTzsxtv8vKSFD9PbJjmhYF14k/jKC7S9k=
+github.com/fsnotify/fsnotify v1.9.0/go.mod h1:8jBTzvmWwFyi3Pb8djgCCO5IBqzKJ/Jwo8TRcHyHii0=
+github.com/fvbommel/sortorder v1.1.0 h1:fUmoe+HLsBTctBDoaBwpQo5N+nrCp8g/BjKb/6ZQmYw=
+github.com/fvbommel/sortorder v1.1.0/go.mod h1:uk88iVf1ovNn1iLfgUVU2F9o5eO30ui720w+kxuqRs0=
+github.com/go-logr/logr v1.2.2/go.mod h1:jdQByPbusPIv2/zmleS9BjJVeZ6kBagPoEUsqbVz/1A=
+github.com/go-logr/logr v1.4.3 h1:CjnDlHq8ikf6E492q6eKboGOC0T8CDaOvkHCIg8idEI=
+github.com/go-logr/logr v1.4.3/go.mod h1:9T104GzyrTigFIr8wt5mBrctHMim0Nb2HLGrmQ40KvY=
+github.com/go-logr/stdr v1.2.2 h1:hSWxHoqTgW2S2qGc0LTAI563KZ5YKYRhT3MFKZMbjag=
+github.com/go-logr/stdr v1.2.2/go.mod h1:mMo/vtBO5dYbehREoey6XUKy/eSumjCCveDpRre4VKE=
+github.com/go-ole/go-ole v1.2.6/go.mod h1:pprOEPIfldk/42T2oK7lQ4v4JSDwmV0As9GaiUsvbm0=
+github.com/go-ole/go-ole v1.3.0 h1:Dt6ye7+vXGIKZ7Xtk4s6/xVdGDQynvom7xCFEdWr6uE=
+github.com/go-ole/go-ole v1.3.0/go.mod h1:5LS6F96DhAwUc7C+1HLexzMXY1xGRSryjyPPKW6zv78=
+github.com/gogo/protobuf v1.3.2 h1:Ov1cvc58UF3b5XjBnZv7+opcTcQFZebYjWzi34vdm4Q=
 github.com/gogo/protobuf v1.3.2/go.mod h1:P1XiOD3dCwIKUDQYPy72D8LYyHL2YPYrpS2s69NZV8Q=
-github.com/google/btree v1.0.0/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ=
-github.com/google/shlex v0.0.0-20191202100458-e7afc7fbc510/go.mod h1:pupxD2MaaD3pAXIBCelhxNneeOaAeabZDe5s4K6zSpQ=
-github.com/googleapis/gnostic v0.4.1/go.mod h1:LRhVm6pbyptWbWbuZ38d1eyptfvIytN3ir6b65WBswg=
-github.com/gorilla/mux v1.8.0/go.mod h1:DVbg23sWSpFRCP0SfiEN6jmj59UnW/n46BH5rLB71So=
-github.com/gregjones/httpcache v0.0.0-20180305231024-9cad4c3443a7/go.mod h1:FecbI9+v66THATjSRHfNgh1IVFe/9kFxbXtjV0ctIMA=
-github.com/grpc-ecosystem/grpc-opentracing v0.0.0-20180507213350-8e809c8a8645/go.mod h1:6iZfnjpejD4L/4DwD7NryNaJyCQdzwWwH2MWhCA90Kw=
-github.com/hailocab/go-hostpool v0.0.0-20160125115350-e80d13ce29ed/go.mod h1:tMWxXQ9wFIaZeTI9F+hmhFiGpFmhOHzyShyFUhRm0H4=
-github.com/hashicorp/go-cleanhttp v0.5.1/go.mod h1:JpRdi6/HCYpAwUzNwuwqhbovhLtngrth3wmdIIUrZ80=
-github.com/hashicorp/go-cty-funcs v0.0.0-20200930094925-2721b1e36840/go.mod h1:Abjk0jbRkDaNCzsRhOv2iDCofYpX1eVsjozoiK63qLA=
-github.com/hashicorp/hcl/v2 v2.8.2/go.mod h1:bQTN5mpo+jewjJgh8jr0JUguIi7qPHUF6yIfAEN3jqY=
-github.com/jaguilar/vt100 v0.0.0-20150826170717-2703a27b14ea/go.mod h1:QMdK4dGB3YhEW2BmA1wgGpPYI3HZy/5gD705PXKUVSg=
-github.com/jinzhu/gorm v1.9.2/go.mod h1:Vla75njaFJ8clLU1W44h34PjIkijhjHIYnZxMqCdxqo=
-github.com/jinzhu/inflection v0.0.0-20180308033659-04140366298a/go.mod h1:h+uFLlag+Qp1Va5pdKtLDYj+kHp5pxUVkryuEj+Srlc=
-github.com/kardianos/osext v0.0.0-20190222173326-2bc1f35cddc0/go.mod h1:1NbS8ALrpOvjt0rHPNLyCIeMtbizbir8U//inJ+zuB8=
-github.com/lib/pq v1.10.0/go.mod h1:AlVN5x4E4T544tWzH6hKfbfQvm3HdbOxrmggDNAPY9o=
+github.com/google/go-containerregistry v0.20.6 h1:cvWX87UxxLgaH76b4hIvya6Dzz9qHB31qAwjAohdSTU=
+github.com/google/go-containerregistry v0.20.6/go.mod h1:T0x8MuoAoKX/873bkeSfLD2FAkwCDf9/HZgsFJ02E2Y=
+github.com/google/go-containerregistry v0.20.7 h1:24VGNpS0IwrOZ2ms2P1QE3Xa5X9p4phx0aUgzYzHW6I=
+github.com/google/go-containerregistry v0.21.6 h1:T+yqQIlJXKrM98Om4DlW3GoWQAmhZuLMwoDOvVrtiUM=
+github.com/google/gofuzz v1.0.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg=
+github.com/google/uuid v1.6.0 h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0=
+github.com/google/uuid v1.6.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=
+github.com/gorilla/css v1.0.1 h1:ntNaBIghp6JmvWnxbZKANoLyuXTPZ4cAMlo6RyhlbO8=
+github.com/gorilla/css v1.0.1/go.mod h1:BvnYkspnSzMmwRK+b8/xgNPLiIuNZr6vbZBTPQ2A3b0=
+github.com/gpustack/gguf-parser-go v0.22.1 h1:FRnEDWqT0Rcplr/R9ctCRSN2+3DhVsf6dnR5/i9JA4E=
+github.com/gpustack/gguf-parser-go v0.22.1/go.mod h1:y4TwTtDqFWTK+xvprOjRUh+dowgU2TKCX37vRKvGiZ0=
+github.com/gpustack/gguf-parser-go v0.24.0 h1:tdJceXYp9e5RhE9RwVYIuUpir72Jz2D68NEtDXkKCKc=
+github.com/gpustack/gguf-parser-go v0.24.0/go.mod h1:y4TwTtDqFWTK+xvprOjRUh+dowgU2TKCX37vRKvGiZ0=
+github.com/grpc-ecosystem/grpc-gateway/v2 v2.27.2 h1:8Tjv8EJ+pM1xP8mK6egEbD1OgnVTyacbefKhmbLhIhU=
+github.com/grpc-ecosystem/grpc-gateway/v2 v2.27.2/go.mod h1:pkJQ2tZHJ0aFOVEEot6oZmaVEZcRme73eIFmhiVuRWs=
+github.com/grpc-ecosystem/grpc-gateway/v2 v2.27.3 h1:NmZ1PKzSTQbuGHw9DGPFomqkkLWMC+vZCkfs+FHv1Vg=
+github.com/grpc-ecosystem/grpc-gateway/v2 v2.27.3/go.mod h1:zQrxl1YP88HQlA6i9c63DSVPFklWpGX4OWAc9bFuaH4=
+github.com/grpc-ecosystem/grpc-gateway/v2 v2.27.7 h1:X+2YciYSxvMQK0UZ7sg45ZVabVZBeBuvMkmuI2V3Fak=
+github.com/henvic/httpretty v0.1.4 h1:Jo7uwIRWVFxkqOnErcoYfH90o3ddQyVrSANeS4cxYmU=
+github.com/henvic/httpretty v0.1.4/go.mod h1:Dn60sQTZfbt2dYsdUSNsCljyF4AfdqnuJFDLJA1I4AM=
+github.com/inconshreveable/mousetrap v1.1.0 h1:wN+x4NVGpMsO7ErUn/mUI3vEoE6Jt13X2s0bqwp9tc8=
+github.com/inconshreveable/mousetrap v1.1.0/go.mod h1:vpF70FUmC8bwa3OWnCshd2FqLfsEA9PFc4w1p2J65bw=
+github.com/jaypipes/ghw v0.19.1 h1:Lhybk6aadgEJqIxeS0h07UOL/EgMGIdxbAy6V8J7RgY=
+github.com/jaypipes/ghw v0.19.1/go.mod h1:GPrvwbtPoxYUenr74+nAnWbardIZq600vJDD5HnPsPE=
+github.com/jaypipes/ghw v0.23.0 h1:WOL4hpLcIu1kIm+z5Oz19Tk1HNw/Sncrx/6GS8O0Kl0=
+github.com/jaypipes/ghw v0.23.0/go.mod h1:fUNUjMZ0cjahKo+/u+32m9FutIx53Nkbi0Ti0m7j5HY=
+github.com/jaypipes/ghw v0.24.0 h1:6RBrJzvHvZ0t+hSvqPmOd5b21C4fMsyiyFzWljEj8Wg=
+github.com/jaypipes/ghw v0.24.0/go.mod h1:Qk3UjdH8Xu/OiVyb/eDJqnDsUc+awHU75y23ErZU33s=
+github.com/jaypipes/pcidb v1.1.1 h1:QmPhpsbmmnCwZmHeYAATxEaoRuiMAJusKYkUncMC0ro=
+github.com/jaypipes/pcidb v1.1.1/go.mod h1:x27LT2krrUgjf875KxQXKB0Ha/YXLdZRVmw6hH0G7g8=
+github.com/jessevdk/go-flags v1.4.0/go.mod h1:4FA24M0QyGHXBuZZK/XkWh8h0e1EYbRYJSGM75WSRxI=
+github.com/json-iterator/go v1.1.12 h1:PV8peI4a0ysnczrg+LtxykD8LfKY9ML6u2jnxaEnrnM=
+github.com/json-iterator/go v1.1.12/go.mod h1:e30LSqwooZae/UwlEbR2852Gd8hjQvJoHmT4TnhNGBo=
+github.com/kisielk/errcheck v1.5.0/go.mod h1:pFxgyoBC7bSaBwPgfKdkLd5X25qrDl4LWUI2bnpBCr8=
+github.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck=
+github.com/klauspost/compress v1.18.1 h1:bcSGx7UbpBqMChDtsF28Lw6v/G94LPrrbMbdC3JH2co=
+github.com/klauspost/compress v1.18.1/go.mod h1:ZQFFVG+MdnR0P+l6wpXgIL4NTtwiKIdBnrBd8Nrxr+0=
+github.com/klauspost/compress v1.18.2 h1:iiPHWW0YrcFgpBYhsA6D1+fqHssJscY/Tm/y2Uqnapk=
+github.com/klauspost/compress v1.18.2/go.mod h1:R0h/fSBs8DE4ENlcrlib3PsXS61voFxhIs2DeRhCvJ4=
+github.com/klauspost/compress v1.18.4 h1:RPhnKRAQ4Fh8zU2FY/6ZFDwTVTxgJ/EMydqSTzE9a2c=
+github.com/klauspost/compress v1.18.4/go.mod h1:R0h/fSBs8DE4ENlcrlib3PsXS61voFxhIs2DeRhCvJ4=
+github.com/klauspost/compress v1.18.5 h1:/h1gH5Ce+VWNLSWqPzOVn6XBO+vJbCNGvjoaGBFW2IE=
+github.com/klauspost/compress v1.18.5/go.mod h1:cwPg85FWrGar70rWktvGQj8/hthj3wpl0PGDogxkrSQ=
+github.com/klauspost/compress v1.18.6 h1:2jupLlAwFm95+YDR+NwD2MEfFO9d4z4Prjl1XXDjuao=
+github.com/klauspost/compress v1.19.1 h1:VsB4HPswih7mmZ8WleSFQ75c/Ui1M4trX5oAsJnhSlk=
+github.com/kolesnikovae/go-winjob v1.0.0 h1:OKEtCHB3sYNAiqNwGDhf08Y6luM7C8mP+42rp1N6SeE=
+github.com/kolesnikovae/go-winjob v1.0.0/go.mod h1:k0joOLP3/NBrRmDQjPV2+oN1TPmEWt6arTNtFjVeQuM=
+github.com/lucasb-eyer/go-colorful v1.2.0 h1:1nnpGOrhyZZuNyfu1QjKiUICQ74+3FNCN69Aj6K7nkY=
+github.com/lucasb-eyer/go-colorful v1.2.0/go.mod h1:R4dSotOR9KMtayYi1e77YzuveK+i7ruzyGqttikkLy0=
+github.com/lucasb-eyer/go-colorful v1.3.0 h1:2/yBRLdWBZKrf7gB40FoiKfAWYQ0lqNcbuQwVHXptag=
+github.com/mattn/go-colorable v0.1.14 h1:9A9LHSqF/7dyVVX6g0U9cwm9pG3kP9gSzcuIPHPsaIE=
+github.com/mattn/go-colorable v0.1.14/go.mod h1:6LmQG8QLFO4G5z1gPvYEzlUgJ2wF+stgPZH1UqBm1s8=
+github.com/mattn/go-isatty v0.0.20 h1:xfD0iDuEKnDkl03q4limB+vH+GxLEtL/jb4xVJSWWEY=
+github.com/mattn/go-isatty v0.0.20/go.mod h1:W+V8PltTTMOvKvAeJH7IuucS94S2C6jfK/D7dTCTo3Y=
+github.com/mattn/go-runewidth v0.0.9/go.mod h1:H031xJmbD/WCDINGzjvQ9THkh0rPKHF+m2gUSrubnMI=
+github.com/mattn/go-runewidth v0.0.12/go.mod h1:RAqKPSqVFrSLVXbA8x7dzmKdmGzieGRCM46jaSJTDAk=
+github.com/mattn/go-runewidth v0.0.16 h1:E5ScNMtiwvlvB5paMFdw9p4kSQzbXFikJ5SQO6TULQc=
+github.com/mattn/go-runewidth v0.0.16/go.mod h1:Jdepj2loyihRzMpdS35Xk/zdY8IAYHsh153qUoGf23w=
+github.com/mattn/go-runewidth v0.0.20 h1:WcT52H91ZUAwy8+HUkdM3THM6gXqXuLJi9O3rjcQQaQ=
+github.com/mattn/go-runewidth v0.0.21 h1:jJKAZiQH+2mIinzCJIaIG9Be1+0NR+5sz/lYEEjdM8w=
+github.com/mattn/go-runewidth v0.0.23 h1:7ykA0T0jkPpzSvMS5i9uoNn2Xy3R383f9HDx3RybWcw=
+github.com/mattn/go-shellwords v1.0.12 h1:M2zGm7EW6UQJvDeQxo4T51eKPurbeFbe8WtebGE2xrk=
+github.com/mattn/go-shellwords v1.0.12/go.mod h1:EZzvwXDESEeg03EKmM+RmDnNOPKG4lLtQsUlTZDWQ8Y=
+github.com/mattn/go-shellwords v1.0.13 h1:DC0OMEpGjm6LfNFU4ckYcvbQKyp2vE8atyFGXNtDcf4=
+github.com/microcosm-cc/bluemonday v1.0.27 h1:MpEUotklkwCSLeH+Qdx1VJgNqLlpY2KXwXFM08ygZfk=
+github.com/microcosm-cc/bluemonday v1.0.27/go.mod h1:jFi9vgW+H7c3V0lb6nR74Ib/DIB5OBs92Dimizgw2cA=
+github.com/mitchellh/go-homedir v1.1.0 h1:lukF9ziXFxDFPkA1vsr5zpc1XuPDn/wFntq5mG+4E0Y=
 github.com/mitchellh/go-homedir v1.1.0/go.mod h1:SfyaCUpYCn1Vlf4IUYiD9fPX4A5wJrkLzIz1N1q0pr0=
-github.com/moby/buildkit v0.11.6 h1:VYNdoKk5TVxN7k4RvZgdeM4GOyRvIi4Z8MXOY7xvyUs=
-github.com/moby/buildkit v0.11.6/go.mod h1:GCqKfHhz+pddzfgaR7WmHVEE3nKKZMMDPpK8mh3ZLv4=
-github.com/moby/buildkit v0.12.0 h1:hgPDVSeondFLb28cBtRR5O0N4t8uWGJ4YNukT2aICIs=
-github.com/moby/buildkit v0.12.0/go.mod h1:+n9GmkxwBCjVz4u7wmiyh+oqvjIjQM+1zk3iJrWfdos=
-github.com/moby/buildkit v0.12.1-0.20230717122532-faa0cc7da353 h1:/ZIwqvOF3QKObJbjX96xVvAKtnWdw/AuEqysbbujaZA=
-github.com/moby/buildkit v0.12.1-0.20230717122532-faa0cc7da353/go.mod h1:+n9GmkxwBCjVz4u7wmiyh+oqvjIjQM+1zk3iJrWfdos=
-github.com/moby/buildkit v0.12.1-0.20230824004934-4376f3861b05 h1:oXcA1w1cswNzFW5TH5QoaAJ2zskZlFNsL8IHo28G3Os=
-github.com/moby/buildkit v0.12.1-0.20230824004934-4376f3861b05/go.mod h1:BIvNtlrvok2xTC734ZNhQVGayvMB1Dz8bFuArWTLnnM=
-github.com/moby/buildkit v0.12.1-0.20230830200556-05eb7287534b h1:VzIGQGWGnrDbzcQSJ28qTUAbNEtmszzuhUrzoqE/52Q=
-github.com/moby/buildkit v0.12.1-0.20230830200556-05eb7287534b/go.mod h1:7/l0VKIyp1hBcGZF2hRpfBgvc0beQ9/hBWw7S+1JM0s=
-github.com/moby/buildkit v0.12.1 h1:vvMG7EZYCiQZpTtXQkvyeyj7HzT1JHhDWj+/aiGIzLM=
-github.com/moby/buildkit v0.12.1/go.mod h1:adB4y0SxxX8trnrY+oEulb48ODLqPO6pKMF0ppGcCoI=
-github.com/moby/buildkit v0.12.2 h1:B7guBgY6sfk4dBlv/ORUxyYlp0UojYaYyATgtNwSCXc=
-github.com/moby/buildkit v0.12.2/go.mod h1:adB4y0SxxX8trnrY+oEulb48ODLqPO6pKMF0ppGcCoI=
-github.com/moby/buildkit v0.13.0-beta1.0.20231011042751-9ef1ed946118 h1:pqpcLt3wJTqBEY8Va3QQvd+taaBTEmK2+1kV7LKc69k=
-github.com/moby/buildkit v0.13.0-beta1.0.20231011042751-9ef1ed946118/go.mod h1:oSHnUZH7sNtAFLyeN1syf46SuzMThKsCQaioNEqJVUk=
-github.com/moby/buildkit v0.13.0-beta1.0.20231011101155-c444964c2e8f h1:CEiXZq08D7vLOnEDl7XY95zbupdWOJrRLb1VeZ+Hxq8=
-github.com/moby/buildkit v0.13.0-beta1.0.20231011101155-c444964c2e8f/go.mod h1:oSHnUZH7sNtAFLyeN1syf46SuzMThKsCQaioNEqJVUk=
-github.com/moby/buildkit v0.13.0-beta1.0.20231113205014-1efcd30d9dd6 h1:gfbjHMadWpzz9Jbbo4l73lrkNrP2YvNsKIIg8e5Ra4s=
-github.com/moby/buildkit v0.13.0-beta1.0.20231113205014-1efcd30d9dd6/go.mod h1:VE6gCOYRW2hbxnxtt7udKkYMF73YdvkgIrGhkB0EiDA=
-github.com/moby/buildkit v0.13.0-beta1.0.20231214000015-a960fe501f00 h1:Ymp+x/hsr6M6R+6j4XVyGaRrhAt1MnGXoN+ZkQ+TuuA=
-github.com/moby/buildkit v0.13.0-beta1.0.20231214000015-a960fe501f00/go.mod h1:6MddWPSL5jxy+W8eMMHWDOfZzzRRKWXPZqajw72YHBc=
-github.com/moby/buildkit v0.13.0-beta1.0.20231219135447-957cb50df991 h1:r80LLQ91uOLxU1ElAvrB1o8oBsph51lPzVnr7t2b200=
-github.com/moby/buildkit v0.13.0-beta1.0.20231219135447-957cb50df991/go.mod h1:6MddWPSL5jxy+W8eMMHWDOfZzzRRKWXPZqajw72YHBc=
-github.com/moby/buildkit v0.13.0-beta1.0.20240116143623-28ce478b1fde h1:t6dpbzyD4GYAX3zlm0s0+uH8xxx2UqF9uW9zuFIr+vg=
-github.com/moby/buildkit v0.13.0-beta1.0.20240116143623-28ce478b1fde/go.mod h1:NK6kY+05bXjxhEmtGEMAwvSJ19gagBukPz6N4FFzlNs=
-github.com/moby/buildkit v0.13.0-beta1.0.20240126101002-6bd81372ad6f h1:weCt2sfZGVAeThzpVyv4ibC0oFfvSxtbiTE7W77wXpc=
-github.com/moby/buildkit v0.13.0-beta1.0.20240126101002-6bd81372ad6f/go.mod h1:vEcIVw63dZyhTgbcyQWXlZrtrKnvFoSI8LhfV+Vj0Jg=
-github.com/moby/buildkit v0.13.0-beta3.0.20240201135300-d906167d0b34 h1:9oIm9T7YyDxRAXvP7y605G3TZmPGZjFvRHbbMJcIDy8=
-github.com/moby/buildkit v0.13.0-beta3.0.20240201135300-d906167d0b34/go.mod h1:tSWWhq1EDM0eB3ngMNDiH2hOOW9fXTyn2uXuOraCLlE=
-github.com/moby/buildkit v0.13.0-rc3.0.20240307012628-5a4c2975457b h1:lMLGJ3ErbAa5eGsVj7CkmN/2ByyyUFs3abfX99+C4pA=
-github.com/moby/buildkit v0.13.0-rc3.0.20240307012628-5a4c2975457b/go.mod h1:P5zIr3pyh1VQoK751o5JFtogepVcLi9+77PTfmvJwls=
-github.com/moby/buildkit v0.13.0-rc3.0.20240307092343-22d4212fed7e h1:lEQehVlOgEMJ6bZvx3TWFjFE9Cic4fWJplNNQtYUX/A=
-github.com/moby/buildkit v0.13.0-rc3.0.20240307092343-22d4212fed7e/go.mod h1:P5zIr3pyh1VQoK751o5JFtogepVcLi9+77PTfmvJwls=
-github.com/moby/buildkit v0.13.0-rc3.0.20240308080452-a38011b9f57d h1:q8sI5enL3NBniNUIeVyrbUj6WCSc0gg+tAQgX1m6oTM=
-github.com/moby/buildkit v0.13.0-rc3.0.20240308080452-a38011b9f57d/go.mod h1:P5zIr3pyh1VQoK751o5JFtogepVcLi9+77PTfmvJwls=
-github.com/moby/buildkit v0.13.0-rc3.0.20240402103816-7cd12732690e h1:+hA09x+9xK3KoXtxNFHiJxBbJrpVr/7UR221F2+pG9w=
-github.com/moby/buildkit v0.13.0-rc3.0.20240402103816-7cd12732690e/go.mod h1:ij4XbVmcwOPQdTJQeO6341hqzvlw10kkuSsT36suSrk=
-github.com/moby/buildkit v0.13.0-rc3.0.20240424175633-5fce077ed0e0 h1:wTJCJDC1woYunMCVd4qKvfJ4esNPYNBIW1459+FR1cA=
-github.com/moby/buildkit v0.13.0-rc3.0.20240424175633-5fce077ed0e0/go.mod h1:wH5RTVyFjMQ67euC1e3UUSw7yQe7JkAHmf8OZkQY7Y4=
-github.com/moby/buildkit v0.13.0 h1:reVR1Y+rbNIUQ9jf0Q1YZVH5a/nhOixZsl+HJ9qQEGI=
-github.com/moby/buildkit v0.13.0/go.mod h1:aNmNQKLBFYAOFuzQjR3VA27/FijlvtBD1pjNwTSN37k=
-github.com/moby/buildkit v0.14.0-rc2 h1:qvl0hOKeyAWReOkksNtstQjPNaAD4jN3Dvq4r7slqYM=
-github.com/moby/buildkit v0.14.0-rc2/go.mod h1:/ZJNHNVso1nf063XlDhEkNEcRNW19utVpUKixCUo9Ks=
-github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc h1:D/QzYP+52V4IzxMvcWe8ppgg0XptfI4/JCd7ry79gqY=
-github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc/go.mod h1:1XssG7cAqv5Bz1xcGMxJL123iCv5TYN4Z/qf647gfuk=
-github.com/moby/buildkit v0.14.0-rc2.0.20240611065153-eed17a45c62b h1:n06ACmuRYPZLR6DbQvVPDRGvqWK7gGCRJjMEzGTemzs=
-github.com/moby/buildkit v0.14.0-rc2.0.20240611065153-eed17a45c62b/go.mod h1:1XssG7cAqv5Bz1xcGMxJL123iCv5TYN4Z/qf647gfuk=
-github.com/moby/buildkit v0.15.1 h1:J6wrew7hphKqlq1wuu6yaUb/1Ra7gEzDAovylGztAKM=
-github.com/moby/buildkit v0.15.1/go.mod h1:Yis8ZMUJTHX9XhH9zVyK2igqSHV3sxi3UN0uztZocZk=
-github.com/moby/buildkit v0.16.0 h1:wOVBj1o5YNVad/txPQNXUXdelm7Hs/i0PUFjzbK0VKE=
-github.com/moby/buildkit v0.16.0/go.mod h1:Xqx/5GlrqE1yIRORk0NSCVDFpQAU1WjlT6KHYZdisIQ=
-github.com/moby/buildkit v0.17.0 h1:ZA/4AxwBbve1f3ZaNNJQiCBtTV62R6YweWNwq4A+sTc=
-github.com/moby/buildkit v0.17.0/go.mod h1:ru8NFyDHD8HbuKaLXJIjK9nr3x6FZR+IWjtF07S+wdM=
-github.com/moby/buildkit v0.17.1-0.20241031124041-354f2d13c905 h1:KMEmQThIQYXKvBurcvM+6zZjxP2CoNSsF/wUpW+RC/E=
-github.com/moby/buildkit v0.17.1-0.20241031124041-354f2d13c905/go.mod h1:ru8NFyDHD8HbuKaLXJIjK9nr3x6FZR+IWjtF07S+wdM=
-github.com/moby/buildkit v0.18.0 h1:KSelhNINJcNA3FCWBbGCytvicjP+kjU5kZlZhkTUkVo=
-github.com/moby/buildkit v0.18.0/go.mod h1:vCR5CX8NGsPTthTg681+9kdmfvkvqJBXEv71GZe5msU=
-github.com/moby/buildkit v0.19.0 h1:w9G1p7sArvCGNkpWstAqJfRQTXBKukMyMK1bsah1HNo=
-github.com/moby/buildkit v0.19.0/go.mod h1:WiHBFTgWV8eB1AmPxIWsAlKjUACAwm3X/14xOV4VWew=
-github.com/moby/buildkit v0.20.0 h1:aF5RujjQ310Pn6SLL/wQYIrSsPXy0sQ5KvWifwq1h8Y=
-github.com/moby/buildkit v0.20.0/go.mod h1:HYFUIK+iGDRxRgdphZ9Nv0y1Fz7mv0HrU7xZoXx217E=
+github.com/moby/buildkit v0.26.0/go.mod h1:ylDa7IqzVJgLdi/wO7H1qLREFQpmhFbw2fbn4yoTw40=
+github.com/moby/buildkit v0.27.0 h1:1gtNaMcVE0XXCZrybC32L79A7Ga1JeB7V3PfpCt1bDc=
+github.com/moby/buildkit v0.27.0/go.mod h1:4STUkNc5t1nf03HS+01UmI2X6FdfOI3XaKt9QNoTsms=
+github.com/moby/buildkit v0.28.0 h1:rKulfRRSduHJPNpLTk481fHElqN9tps0VUx8YV/5zsA=
+github.com/moby/buildkit v0.28.0/go.mod h1:RCuOcj/bVsCriBG8NeFzRxjiCFQKnKP7KOVlNTS18t4=
+github.com/moby/buildkit v0.29.0 h1:wxLEFbCOJntEDjSNNN2YWd8zxltZxT5muDQ0LzpbtpU=
+github.com/moby/buildkit v0.29.0/go.mod h1:Dmv2FeDe34t75QuzeU87rBoZpAAkcpT5zeu4hXzmASc=
+github.com/moby/buildkit v0.30.0 h1:OsK8T3BaYH52UNStpKd7gytDtHWWt2Fawak/lAPWatU=
+github.com/moby/buildkit v0.30.0/go.mod h1:k2wuw5ddaOqzh58RLt+mBn2XhK34gi6+gd0faONQ1xU=
+github.com/moby/buildkit v0.31.0 h1:hMUAbQGgjtzJDDOZ6o7MQk5XBZkBTyzLWEvnjguHHQI=
+github.com/moby/buildkit v0.31.0/go.mod h1:YM5iNEbNCc6L1Zt3YWFB/aXNLufvf4Rcu0DPlc9HwQg=
+github.com/moby/buildkit v0.32.0 h1:slXarYQoMo4cp2d9x30M9t0L4R+c0CVMov+5P1hhiHY=
+github.com/moby/buildkit v0.32.0/go.mod h1:Y10FBWvqxl/Wmhdzjee1Y2wQfjifTiwxENIUdaVNdME=
+github.com/moby/buildkit v0.32.1 h1:gIygb6hNTKrSh3PRIOmXJGNZJQf7n7mmVxzo1omKjAM=
+github.com/moby/buildkit v0.32.1/go.mod h1:0GB/EJ1d+4VIVqIAgy3asaoGkVXy7IrDfVy7mPhOvg8=
+github.com/moby/buildkit v0.32.2 h1:Sfy7+u6dUv/2yuBc9KCoK70Re8atuV8aPZ5UOC068Vc=
+github.com/moby/buildkit v0.32.2/go.mod h1:0GB/EJ1d+4VIVqIAgy3asaoGkVXy7IrDfVy7mPhOvg8=
+github.com/moby/docker-image-spec v1.3.1 h1:jMKff3w6PgbfSa69GfNg+zN/XLhfXJGnEx3Nl2EsFP0=
+github.com/moby/docker-image-spec v1.3.1/go.mod h1:eKmb5VW8vQEh/BAr2yvVNvuiJuY6UIocYsFu/DxxRpo=
+github.com/moby/locker v1.0.1 h1:fOXqR41zeveg4fFODix+1Ch4mj/gT0NE1XJbp/epuBg=
 github.com/moby/locker v1.0.1/go.mod h1:S7SDdo5zpBK84bzzVlKr2V0hz+7x9hWbYC/kq7oQppc=
-github.com/moby/moby v24.0.2+incompatible h1:yH+5dRHH1x3XRKzl1THA2aGTy6CHYnkt5N924ADMax8=
-github.com/moby/moby v24.0.2+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v24.0.4+incompatible h1:20Bf1sfJpspHMAUrxRFplG31Sriaw7Z9/jUEuJk6mqI=
-github.com/moby/moby v24.0.4+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v24.0.5+incompatible h1:uUbydai/Y9J7Ybt+lFI3zBdnsMYXnXE9vEcfZDoEE8Q=
-github.com/moby/moby v24.0.5+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v24.0.8-0.20240109122856-854ca341c0f6+incompatible h1:bwE6hpc+Kq+UhTMUOdepQYXDBIqQENvj/LuuRJmTpAs=
-github.com/moby/moby v24.0.8-0.20240109122856-854ca341c0f6+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v25.0.0+incompatible h1:KIFudkwXNK+kBrnCxWZNwhEf/jJzdjQAP7EF/awywMI=
-github.com/moby/moby v25.0.0+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v25.0.3-0.20240203133757-341a7978a541+incompatible h1:0Vgi62q5Zo4E0wl1ZBj8bRq9rZeOGK+xwz1SBr3Naz8=
-github.com/moby/moby v25.0.3-0.20240203133757-341a7978a541+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v25.0.4+incompatible h1:vea1J80wDM5x5geaZSaywFkfFxLABJIQ3mmR4ewZGbU=
-github.com/moby/moby v25.0.4+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v26.0.0+incompatible h1:2n9/cIWkxiEI1VsWgTGgXhxIWUbv42PyxEP9L+RReC0=
-github.com/moby/moby v26.0.0+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v26.1.0+incompatible h1:mjepCwMH0KpCgPvrXjqqyCeTCHgzO7p9TwZ2nQMI2qU=
-github.com/moby/moby v26.1.0+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v26.1.2+incompatible h1:yOGzOkmMRtkhyySHHRH9dWOK/rlrmZR/cVnMGqlynzw=
-github.com/moby/moby v26.1.2+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v27.0.1+incompatible h1:eWAkDZQMCcedwjpxh4hbDV/ktQG2QL41PuO7Bm4xWU4=
-github.com/moby/moby v27.0.1+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v27.0.3+incompatible h1:lnUi7z7EFl1VkcahJOdvkI5QDEHJyib4CHbQK3MCQsw=
-github.com/moby/moby v27.0.3+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v27.2.0+incompatible h1:WX2CjnXfZ8V87ugEIJuwVp7fDhHXCdi7gjlEQgcLE8I=
-github.com/moby/moby v27.2.0+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v27.2.1+incompatible h1:mIRBoOsLr+Q6s+h65ZFyi6cXBEVy2RXCWS5HOHlxx54=
-github.com/moby/moby v27.2.1+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v27.3.0+incompatible h1:AhSu/R7C5uiyd+JCts3kxrKyTzXa3FilBJ0KCLUHXqA=
-github.com/moby/moby v27.3.0+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v27.3.1+incompatible h1:KQbXBjo7PavKpzIl7UkHT31y9lw/e71Uvrqhr4X+zMA=
-github.com/moby/moby v27.3.1+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v27.4.0+incompatible h1:jGXXZCMAmFZS9pKsQqUt9yAPHOC450PM9lbQYPSQnuc=
-github.com/moby/moby v27.4.0+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v27.5.0+incompatible h1:RuYLppjLxMzWmPUQAy/hkJ6pGcXsuVdcmIVFqVPegO8=
-github.com/moby/moby v27.5.0+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v27.5.1+incompatible h1:/pN59F/t3U7Q4FPzV88nzqf7Fp0qqCSL2KzhZaiKcKw=
-github.com/moby/moby v27.5.1+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v28.0.0+incompatible h1:D+F1Z56b/DS8J5pUkTG/stemqrvHBQ006hUqJxjV9P0=
-github.com/moby/moby v28.0.0+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v28.0.1+incompatible h1:10ejBTwFhM3/9p6pSaKrLyXnx7QzzCmCYHAedOp67cQ=
-github.com/moby/moby v28.0.1+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v28.0.2+incompatible h1:CZfEXXYP3TYmdaYw4llMj7NIHA++tQzDiPk8mtryjL4=
-github.com/moby/moby v28.0.2+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/moby v28.1.0-rc.2+incompatible h1:F9Ku4A7eCFvb9cYR/jk7sLC6U9+r2u4vzjwZQzv/EQc=
-github.com/moby/moby v28.1.0-rc.2+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=
-github.com/moby/sys/symlink v0.1.0/go.mod h1:GGDODQmbFOjFsXvfLVn3+ZRxkch54RkSiGqsZeMYowQ=
+github.com/moby/moby/api v1.52.0 h1:00BtlJY4MXkkt84WhUZPRqt5TvPbgig2FZvTbe3igYg=
+github.com/moby/moby/api v1.52.0/go.mod h1:8mb+ReTlisw4pS6BRzCMts5M49W5M7bKt1cJy/YbAqc=
+github.com/moby/moby/api v1.53.0 h1:PihqG1ncw4W+8mZs69jlwGXdaYBeb5brF6BL7mPIS/w=
+github.com/moby/moby/api v1.53.0/go.mod h1:8mb+ReTlisw4pS6BRzCMts5M49W5M7bKt1cJy/YbAqc=
+github.com/moby/moby/api v1.54.0 h1:7kbUgyiKcoBhm0UrWbdrMs7RX8dnwzURKVbZGy2GnL0=
+github.com/moby/moby/api v1.54.0/go.mod h1:8mb+ReTlisw4pS6BRzCMts5M49W5M7bKt1cJy/YbAqc=
+github.com/moby/moby/api v1.54.1 h1:TqVzuJkOLsgLDDwNLmYqACUuTehOHRGKiPhvH8V3Nn4=
+github.com/moby/moby/api v1.54.1/go.mod h1:+RQ6wluLwtYaTd1WnPLykIDPekkuyD/ROWQClE83pzs=
+github.com/moby/moby/api v1.54.2 h1:wiat9QAhnDQjA7wk1kh/TqHz2I1uUA7M7t9SAl/JNXg=
+github.com/moby/moby/api v1.54.2/go.mod h1:+RQ6wluLwtYaTd1WnPLykIDPekkuyD/ROWQClE83pzs=
+github.com/moby/moby/api v1.55.0 h1:2/sexvQyqIWS8pRSCFddBfpW2qE7vR7FCL+vN8pxwMc=
+github.com/moby/moby/api v1.55.0/go.mod h1:+RQ6wluLwtYaTd1WnPLykIDPekkuyD/ROWQClE83pzs=
+github.com/moby/moby/client v0.2.1 h1:1Grh1552mvv6i+sYOdY+xKKVTvzJegcVMhuXocyDz/k=
+github.com/moby/moby/client v0.2.1/go.mod h1:O+/tw5d4a1Ha/ZA/tPxIZJapJRUS6LNZ1wiVRxYHyUE=
+github.com/moby/moby/client v0.2.2 h1:Pt4hRMCAIlyjL3cr8M5TrXCwKzguebPAc2do2ur7dEM=
+github.com/moby/moby/client v0.3.0 h1:UUGL5okry+Aomj3WhGt9Aigl3ZOxZGqR7XPo+RLPlKs=
+github.com/moby/sys/atomicwriter v0.1.0 h1:kw5D/EqkBwsBFi0ss9v1VG3wIkVhzGvLklJ+w3A14Sw=
+github.com/moby/sys/atomicwriter v0.1.0/go.mod h1:Ul8oqv2ZMNHOceF643P6FKPXeCmYtlQMvpizfsSoaWs=
+github.com/moby/sys/sequential v0.6.0 h1:qrx7XFUd/5DxtqcoH1h438hF5TmOvzC/lspjy7zgvCU=
+github.com/moby/sys/sequential v0.6.0/go.mod h1:uyv8EUTrca5PnDsdMGXhZe6CCe8U/UiTWd+lL+7b/Ko=
+github.com/moby/sys/sequential v0.7.0 h1:ASQNGNROJSuOO6LL6bPHbKvuZu6NU8P4ldPWk31zj/8=
+github.com/moby/term v0.5.2 h1:6qk3FJAFDs6i/q3W/pQ97SX192qKfZgGjCQqfCJkgzQ=
+github.com/moby/term v0.5.2/go.mod h1:d3djjFCrjnB+fl8NJux+EJzu0msscUP+f8it8hPkFLc=
+github.com/modelpack/model-spec v0.0.7 h1:3fAxau4xUqF0Pf1zzFC5lItF0gEaiXLxaCcPAH8PW8I=
+github.com/modelpack/model-spec v0.0.7/go.mod h1:5Go37og1RmvcTdVI5Remd+PpQRNLlKSNwSNbXmEqu50=
+github.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=
+github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd h1:TRLaZ9cD/w8PVh93nsPXa1VrQ6jlwL5oN8l14QlcNfg=
 github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=
+github.com/modern-go/reflect2 v1.0.2/go.mod h1:yWuevngMOJpCy52FWWMvUC8ws7m/LJsjYzDa0/r8luk=
+github.com/modern-go/reflect2 v1.0.3-0.20250322232337-35a7c28c31ee h1:W5t00kpgFdJifH4BDsTlE89Zl93FEloxaWZfGcifgq8=
+github.com/modern-go/reflect2 v1.0.3-0.20250322232337-35a7c28c31ee/go.mod h1:yWuevngMOJpCy52FWWMvUC8ws7m/LJsjYzDa0/r8luk=
+github.com/morikuni/aec v1.0.0 h1:nP9CBfwrvYnBRgY6qfDQkygYDmYwOilePFkwzv4dU8A=
 github.com/morikuni/aec v1.0.0/go.mod h1:BbKIizmSmc5MMPqRYbxO4ZU0S0+P200+tUnFx7PXmsc=
+github.com/morikuni/aec v1.1.0 h1:vBBl0pUnvi/Je71dsRrhMBtreIqNMYErSAbEeb8jrXQ=
+github.com/morikuni/aec v1.1.0/go.mod h1:xDRgiq/iw5l+zkao76YTKzKttOp2cwPEne25HDkJnBw=
+github.com/muesli/reflow v0.3.0 h1:IFsN6K9NfGtjeggFP+68I4chLZV2yIKsXJFNZ+eWh6s=
+github.com/muesli/reflow v0.3.0/go.mod h1:pbwTDkVPibjO2kyvBQRBxTWEEGDGq0FlB1BIKtnHY/8=
+github.com/muesli/termenv v0.16.0 h1:S5AlUN9dENB57rsbnkPyfdGuWIlkmzJjbFf0Tf5FWUc=
+github.com/muesli/termenv v0.16.0/go.mod h1:ZRfOIKPFDYQoDFF4Olj7/QJbW60Ol/kL1pU3VfY/Cnk=
+github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 h1:C3w9PqII01/Oq1c1nUAm88MOHcQC9l5mIlSMApZMrHA=
 github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ=
+github.com/nxadm/tail v1.4.8 h1:nPr65rt6Y5JFSKQO7qToXr7pePgD6Gwiw05lkbyAQTE=
+github.com/nxadm/tail v1.4.8/go.mod h1:+ncqLTQzXmGhMZNUePPaPqPvBxHAIsmXswZKocGu+AU=
+github.com/nxadm/tail v1.4.11 h1:8feyoE3OzPrcshW5/MJ4sGESc5cqmGkGCWlco4l0bqY=
+github.com/nxadm/tail v1.4.11/go.mod h1:OTaG3NK980DZzxbRq6lEuzgU+mug70nY11sMd4JXXHc=
+github.com/olekukonko/tablewriter v0.0.5 h1:P2Ga83D34wi1o9J6Wh1mRuqd4mF/x/lgBS7N7AbDhec=
+github.com/olekukonko/tablewriter v0.0.5/go.mod h1:hPp6KlRPjbx+hW8ykQs1w3UBbZlj6HuIJcUGPhkA7kY=
 github.com/opencontainers/go-digest v1.0.0 h1:apOUWs51W5PlhuyGyz9FCeeBIOUDA/6nW8Oi/yOhh5U=
 github.com/opencontainers/go-digest v1.0.0/go.mod h1:0JzlMkj0TRzQZfJkVvzbP0HBR3IKzErnv2BNG4W4MAM=
-github.com/opencontainers/image-spec v1.1.0-rc3 h1:fzg1mXZFj8YdPeNkRXMg+zb88BFV0Ys52cJydRwBkb8=
-github.com/opencontainers/image-spec v1.1.0-rc3/go.mod h1:X4pATf0uXsnn3g5aiGIsVnJBR4mxhKzfwmvK/B2NTm8=
-github.com/opencontainers/image-spec v1.1.0-rc4 h1:oOxKUJWnFC4YGHCCMNql1x4YaDfYBTS5Y4x/Cgeo1E0=
-github.com/opencontainers/image-spec v1.1.0-rc4/go.mod h1:X4pATf0uXsnn3g5aiGIsVnJBR4mxhKzfwmvK/B2NTm8=
-github.com/opencontainers/image-spec v1.1.0-rc5 h1:Ygwkfw9bpDvs+c9E34SdgGOj41dX/cbdlwvlWt0pnFI=
-github.com/opencontainers/image-spec v1.1.0-rc5/go.mod h1:X4pATf0uXsnn3g5aiGIsVnJBR4mxhKzfwmvK/B2NTm8=
-github.com/opencontainers/image-spec v1.1.0-rc6 h1:XDqvyKsJEbRtATzkgItUqBA7QHk58yxX1Ov9HERHNqU=
-github.com/opencontainers/image-spec v1.1.0 h1:8SG7/vwALn54lVB/0yZ/MMwhFrPYtpEHQb2IpWsCzug=
-github.com/opentracing/opentracing-go v1.2.0/go.mod h1:GxEUsuufX4nBwe+T+Wl9TAgYrxe9dPLANfrWvHYVTgc=
-github.com/peterbourgon/diskv v2.0.1+incompatible/go.mod h1:uqqh8zWWbv1HBMNONnaR/tNboyR3/BZd58JJSHlUSCU=
+github.com/opencontainers/image-spec v1.1.1 h1:y0fUlFfIZhPF1W537XOLg0/fcx6zcHCJwooC2xJA040=
+github.com/opencontainers/image-spec v1.1.1/go.mod h1:qpqAh3Dmcf36wStyyWU+kCeDgrGnAve2nCC8+7h8Q0M=
+github.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=
 github.com/pkg/errors v0.9.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
-github.com/pkg/profile v1.5.0/go.mod h1:qBsxPvzyUincmltOk6iyRVxHYg4adc0OFOv72ZdLa18=
 github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
-github.com/serialx/hashring v0.0.0-20190422032157-8b2912629002/go.mod h1:/yeG0My1xr/u+HZrFQ1tOQQQQrOawfyMUH13ai5brBc=
-github.com/spf13/pflag v1.0.5/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=
-github.com/theupdateframework/notary v0.6.1/go.mod h1:MOfgIfmox8s7/7fduvB2xyPPMJCrjRLRizA8OFwpnKY=
-github.com/tonistiigi/units v0.0.0-20180711220420-6950e57a87ea/go.mod h1:WPnis/6cRcDZSUvVmezrxJPkiO87ThFYsoUiMwWNDJk=
-github.com/xeipuuv/gojsonreference v0.0.0-20180127040603-bd5ef7bd5415/go.mod h1:GwrjFmJcFw6At/Gs6z4yjiIwzuJ1/+UwLxMQDVQXShQ=
-github.com/xeipuuv/gojsonschema v1.2.0/go.mod h1:anYRn/JVcOK2ZgGU+IjEV4nwlhoK5sQluxsYJ78Id3Y=
-gopkg.in/dancannon/gorethink.v3 v3.0.5/go.mod h1:GXsi1e3N2OcKhcP6nsYABTiUejbWMFO4GY5a4pEaeEc=
-gopkg.in/fatih/pool.v2 v2.0.0/go.mod h1:8xVGeu1/2jr2wm5V9SPuMht2H5AEmf5aFMGSQixtjTY=
-gopkg.in/gorethink/gorethink.v3 v3.0.5/go.mod h1:+3yIIHJUGMBK+wyPH+iN5TP+88ikFDfZdqTlK3Y9q8I=
-gopkg.in/inf.v0 v0.9.1/go.mod h1:cWUDdTG/fYaXco+Dcufb5Vnc6Gp2YChqWtbxRZE0mXw=
-gopkg.in/yaml.v2 v2.4.0/go.mod h1:RDklbk79AGWmwhnvt/jBztapEOGDOx6ZbXqjP6csGnQ=
+github.com/prometheus/client_model v0.6.2 h1:oBsgwpGs7iVziMvrGhE53c/GrLUsZdHnqNwqPLxwZyk=
+github.com/prometheus/client_model v0.6.2/go.mod h1:y3m2F6Gdpfy6Ut/GBsUqTWZqCUvMVzSfMLjcu6wAwpE=
+github.com/prometheus/common v0.67.1 h1:OTSON1P4DNxzTg4hmKCc37o4ZAZDv0cfXLkOt0oEowI=
+github.com/prometheus/common v0.67.1/go.mod h1:RpmT9v35q2Y+lsieQsdOh5sXZ6ajUGC8NjZAmr8vb0Q=
+github.com/prometheus/common v0.67.5 h1:pIgK94WWlQt1WLwAC5j2ynLaBRDiinoAb86HZHTUGI4=
+github.com/prometheus/common v0.67.5/go.mod h1:SjE/0MzDEEAyrdr5Gqc6G+sXI67maCxzaT3A2+HqjUw=
+github.com/prometheus/procfs v0.16.1 h1:hZ15bTNuirocR6u0JZ6BAHHmwS1p8B4P6MRqxtzMyRg=
+github.com/prometheus/procfs v0.16.1/go.mod h1:teAbpZRB1iIAJYREa1LsoWUXykVXA1KlTmWl8x/U+Is=
+github.com/prometheus/procfs v0.17.0 h1:FuLQ+05u4ZI+SS/w9+BWEM2TXiHKsUQ9TADiRH7DuK0=
+github.com/prometheus/procfs v0.17.0/go.mod h1:oPQLaDAMRbA+u8H5Pbfq+dl3VDAvHxMUOVhe0wYB2zw=
+github.com/prometheus/procfs v0.20.1 h1:XwbrGOIplXW/AU3YhIhLODXMJYyC1isLFfYCsTEycfc=
+github.com/rivo/uniseg v0.1.0/go.mod h1:J6wj4VEh+S6ZtnVlnTBMWIodfgj8LQOQFoIToxlJtxc=
+github.com/rivo/uniseg v0.2.0/go.mod h1:J6wj4VEh+S6ZtnVlnTBMWIodfgj8LQOQFoIToxlJtxc=
+github.com/rivo/uniseg v0.4.7 h1:WUdvkW8uEhrYfLC4ZzdpI2ztxP1I582+49Oc5Mq64VQ=
+github.com/rivo/uniseg v0.4.7/go.mod h1:FN3SvrM+Zdj16jyLfmOkMNblXMcoc8DfTHruCPUcx88=
+github.com/russross/blackfriday/v2 v2.1.0/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM=
+github.com/sirupsen/logrus v1.9.3 h1:dueUQJ1C2q9oE3F7wvmSGAaVtTmUizReu6fjN8uqzbQ=
+github.com/sirupsen/logrus v1.9.3/go.mod h1:naHLuLoDiP4jHNo9R0sCBMtWGeIprob74mVsIT4qYEQ=
+github.com/sirupsen/logrus v1.9.4 h1:TsZE7l11zFCLZnZ+teH4Umoq5BhEIfIzfRDZ1Uzql2w=
+github.com/sirupsen/logrus v1.9.4/go.mod h1:ftWc9WdOfJ0a92nsE2jF5u5ZwH8Bv2zdeOC42RjbV2g=
+github.com/smallnest/ringbuffer v0.0.0-20241116012123-461381446e3d h1:3VwvTjiRPA7cqtgOWddEL+JrcijMlXUmj99c/6YyZoY=
+github.com/smallnest/ringbuffer v0.0.0-20241116012123-461381446e3d/go.mod h1:tAG61zBM1DYRaGIPloumExGvScf08oHuo0kFoOqdbT0=
+github.com/spf13/cobra v1.10.1 h1:lJeBwCfmrnXthfAupyUTzJ/J4Nc1RsHC/mSRU2dll/s=
+github.com/spf13/cobra v1.10.1/go.mod h1:7SmJGaTHFVBY0jW4NXGluQoLvhqFQM+6XSKD+P4XaB0=
+github.com/spf13/cobra v1.10.2 h1:DMTTonx5m65Ic0GOoRY2c16WCbHxOOw6xxezuLaBpcU=
+github.com/spf13/cobra v1.10.2/go.mod h1:7C1pvHqHw5A4vrJfjNwvOdzYu0Gml16OCs2GRiTUUS4=
+github.com/spf13/pflag v1.0.9/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=
+github.com/spf13/pflag v1.0.10 h1:4EBh2KAYBwaONj6b2Ye1GiHfwjqyROoF4RwYO+vPwFk=
+github.com/spf13/pflag v1.0.10/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=
+github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
+github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI=
+github.com/stretchr/testify v1.7.0/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg=
+github.com/vbatts/tar-split v0.12.2 h1:w/Y6tjxpeiFMR47yzZPlPj/FcPLpXbTUi/9H7d3CPa4=
+github.com/vbatts/tar-split v0.12.2/go.mod h1:eF6B6i6ftWQcDqEn3/iGFRFRo8cBIMSJVOpnNdfTMFA=
+github.com/vbatts/tar-split v0.12.3 h1:Cd46rkGXI3Td4yrVNwU8ripbxFaQbmesqhjBUUYAJSw=
+github.com/xo/terminfo v0.0.0-20220910002029-abceb7e1c41e h1:JVG44RsyaB9T2KIHavMF/ppJZNG9ZpyihvCd0w101no=
+github.com/xo/terminfo v0.0.0-20220910002029-abceb7e1c41e/go.mod h1:RbqR21r5mrJuqunuUZ/Dhy/avygyECGrLceyNeo4LiM=
+github.com/yuin/goldmark v1.1.27/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
+github.com/yuin/goldmark v1.2.1/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
+github.com/yuin/goldmark v1.7.1/go.mod h1:uzxRWxtg69N339t3louHJ7+O03ezfj6PlliRlaOzY1E=
+github.com/yuin/goldmark v1.7.8 h1:iERMLn0/QJeHFhxSt3p6PeN9mGnvIKSpG9YYorDMnic=
+github.com/yuin/goldmark v1.7.8/go.mod h1:uzxRWxtg69N339t3louHJ7+O03ezfj6PlliRlaOzY1E=
+github.com/yuin/goldmark v1.7.13 h1:GPddIs617DnBLFFVJFgpo1aBfe/4xcvMc3SB5t/D0pA=
+github.com/yuin/goldmark-emoji v1.0.5 h1:EMVWyCGPlXJfUXBXpuMu+ii3TIaxbVBnEX9uaDC4cIk=
+github.com/yuin/goldmark-emoji v1.0.5/go.mod h1:tTkZEbwu5wkPmgTcitqddVxY9osFZiavD+r4AzQrh1U=
+github.com/yuin/goldmark-emoji v1.0.6 h1:QWfF2FYaXwL74tfGOW5izeiZepUDroDJfWubQI9HTHs=
+github.com/yusufpapurcu/wmi v1.2.4 h1:zFUKzehAFReQwLys1b/iSMl+JQGSCSjtVqQn9bBrPo0=
+github.com/yusufpapurcu/wmi v1.2.4/go.mod h1:SBZ9tNy3G9/m5Oi98Zks0QjeHVDvuK0qfxQmPyzfmi0=
+go.opentelemetry.io/auto/sdk v1.2.1 h1:jXsnJ4Lmnqd11kwkBV2LgLoFMZKizbCi5fNZ/ipaZ64=
+go.opentelemetry.io/auto/sdk v1.2.1/go.mod h1:KRTj+aOaElaLi+wW1kO/DZRXwkF4C5xPbEe3ZiIhN7Y=
+go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.63.0 h1:RbKq8BG0FI8OiXhBfcRtqqHcZcka+gU3cskNuf05R18=
+go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.63.0/go.mod h1:h06DGIukJOevXaj/xrNjhi/2098RZzcLTbc0jDAUbsg=
+go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.68.0 h1:CqXxU8VOmDefoh0+ztfGaymYbhdB/tT3zs79QaZTNGY=
+go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.69.0 h1:8tvICD4vSTOOsNrsI4Ljf6C+6UKvpTEH5XY3JMoyPoo=
+go.opentelemetry.io/otel v1.38.0 h1:RkfdswUDRimDg0m2Az18RKOsnI8UDzppJAtj01/Ymk8=
+go.opentelemetry.io/otel v1.38.0/go.mod h1:zcmtmQ1+YmQM9wrNsTGV/q/uyusom3P8RxwExxkZhjM=
+go.opentelemetry.io/otel v1.40.0 h1:oA5YeOcpRTXq6NN7frwmwFR0Cn3RhTVZvXsP4duvCms=
+go.opentelemetry.io/otel v1.40.0/go.mod h1:IMb+uXZUKkMXdPddhwAHm6UfOwJyh4ct1ybIlV14J0g=
+go.opentelemetry.io/otel v1.42.0 h1:lSQGzTgVR3+sgJDAU/7/ZMjN9Z+vUip7leaqBKy4sho=
+go.opentelemetry.io/otel v1.42.0/go.mod h1:lJNsdRMxCUIWuMlVJWzecSMuNjE7dOYyWlqOXWkdqCc=
+go.opentelemetry.io/otel v1.43.0 h1:mYIM03dnh5zfN7HautFE4ieIig9amkNANT+xcVxAj9I=
+go.opentelemetry.io/otel v1.43.0/go.mod h1:JuG+u74mvjvcm8vj8pI5XiHy1zDeoCS2LB1spIq7Ay0=
+go.opentelemetry.io/otel v1.44.0 h1:JjwHmHpA4iZ3wBxluu2fbbE7j4kqlE8jXyAyPXH7HqU=
+go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v1.38.0 h1:vl9obrcoWVKp/lwl8tRE33853I8Xru9HFbw/skNeLs8=
+go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v1.38.0/go.mod h1:GAXRxmLJcVM3u22IjTg74zWBrRCKq8BnOqUVLodpcpw=
+go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v1.40.0 h1:NOyNnS19BF2SUDApbOKbDtWZ0IK7b8FJ2uAGdIWOGb0=
+go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.38.0 h1:GqRJVj7UmLjCVyVJ3ZFLdPRmhDUp2zFmQe3RHIOsw24=
+go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.38.0/go.mod h1:ri3aaHSmCTVYu2AWv44YMauwAQc0aqI9gHKIcSbI1pU=
+go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.40.0 h1:QKdN8ly8zEMrByybbQgv8cWBcdAarwmIPZ6FThrWXJs=
+go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.38.0 h1:lwI4Dc5leUqENgGuQImwLo4WnuXFPetmPpkLi2IrX54=
+go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.38.0/go.mod h1:Kz/oCE7z5wuyhPxsXDuaPteSWqjSBD5YaSdbxZYGbGk=
+go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.40.0 h1:DvJDOPmSWQHWywQS6lKL+pb8s3gBLOZUtw4N+mavW1I=
+go.opentelemetry.io/otel/metric v1.38.0 h1:Kl6lzIYGAh5M159u9NgiRkmoMKjvbsKtYRwgfrA6WpA=
+go.opentelemetry.io/otel/metric v1.38.0/go.mod h1:kB5n/QoRM8YwmUahxvI3bO34eVtQf2i4utNVLr9gEmI=
+go.opentelemetry.io/otel/metric v1.40.0 h1:rcZe317KPftE2rstWIBitCdVp89A2HqjkxR3c11+p9g=
+go.opentelemetry.io/otel/metric v1.40.0/go.mod h1:ib/crwQH7N3r5kfiBZQbwrTge743UDc7DTFVZrrXnqc=
+go.opentelemetry.io/otel/metric v1.42.0 h1:2jXG+3oZLNXEPfNmnpxKDeZsFI5o4J+nz6xUlaFdF/4=
+go.opentelemetry.io/otel/metric v1.42.0/go.mod h1:RlUN/7vTU7Ao/diDkEpQpnz3/92J9ko05BIwxYa2SSI=
+go.opentelemetry.io/otel/metric v1.43.0 h1:d7638QeInOnuwOONPp4JAOGfbCEpYb+K6DVWvdxGzgM=
+go.opentelemetry.io/otel/metric v1.43.0/go.mod h1:RDnPtIxvqlgO8GRW18W6Z/4P462ldprJtfxHxyKd2PY=
+go.opentelemetry.io/otel/metric v1.44.0 h1:1w0gILTcHdr3YI+ixLyjemwrVnsMURbTZFrSYCdDdmc=
+go.opentelemetry.io/otel/sdk v1.38.0 h1:l48sr5YbNf2hpCUj/FoGhW9yDkl+Ma+LrVl8qaM5b+E=
+go.opentelemetry.io/otel/sdk v1.38.0/go.mod h1:ghmNdGlVemJI3+ZB5iDEuk4bWA3GkTpW+DOoZMYBVVg=
+go.opentelemetry.io/otel/sdk v1.40.0 h1:KHW/jUzgo6wsPh9At46+h4upjtccTmuZCFAc9OJ71f8=
+go.opentelemetry.io/otel/sdk v1.41.0 h1:YPIEXKmiAwkGl3Gu1huk1aYWwtpRLeskpV+wPisxBp8=
+go.opentelemetry.io/otel/sdk/metric v1.38.0 h1:aSH66iL0aZqo//xXzQLYozmWrXxyFkBJ6qT5wthqPoM=
+go.opentelemetry.io/otel/sdk/metric v1.38.0/go.mod h1:dg9PBnW9XdQ1Hd6ZnRz689CbtrUp0wMMs9iPcgT9EZA=
+go.opentelemetry.io/otel/sdk/metric v1.40.0 h1:mtmdVqgQkeRxHgRv4qhyJduP3fYJRMX4AtAlbuWdCYw=
+go.opentelemetry.io/otel/sdk/metric v1.41.0 h1:siZQIYBAUd1rlIWQT2uCxWJxcCO7q3TriaMlf08rXw8=
+go.opentelemetry.io/otel/trace v1.38.0 h1:Fxk5bKrDZJUH+AMyyIXGcFAPah0oRcT+LuNtJrmcNLE=
+go.opentelemetry.io/otel/trace v1.38.0/go.mod h1:j1P9ivuFsTceSWe1oY+EeW3sc+Pp42sO++GHkg4wwhs=
+go.opentelemetry.io/otel/trace v1.40.0 h1:WA4etStDttCSYuhwvEa8OP8I5EWu24lkOzp+ZYblVjw=
+go.opentelemetry.io/otel/trace v1.40.0/go.mod h1:zeAhriXecNGP/s2SEG3+Y8X9ujcJOTqQ5RgdEJcawiA=
+go.opentelemetry.io/otel/trace v1.42.0 h1:OUCgIPt+mzOnaUTpOQcBiM/PLQ/Op7oq6g4LenLmOYY=
+go.opentelemetry.io/otel/trace v1.42.0/go.mod h1:f3K9S+IFqnumBkKhRJMeaZeNk9epyhnCmQh/EysQCdc=
+go.opentelemetry.io/otel/trace v1.43.0 h1:BkNrHpup+4k4w+ZZ86CZoHHEkohws8AY+WTX09nk+3A=
+go.opentelemetry.io/otel/trace v1.43.0/go.mod h1:/QJhyVBUUswCphDVxq+8mld+AvhXZLhe+8WVFxiFff0=
+go.opentelemetry.io/otel/trace v1.44.0 h1:jxF5CsGYCe74MCRx2X4g7WsY/VBKRqqpNvXlX/6gtIk=
+go.opentelemetry.io/proto/otlp v1.7.1 h1:gTOMpGDb0WTBOP8JaO72iL3auEZhVmAQg4ipjOVAtj4=
+go.opentelemetry.io/proto/otlp v1.7.1/go.mod h1:b2rVh6rfI/s2pHWNlB7ILJcRALpcNDzKhACevjI+ZnE=
+go.opentelemetry.io/proto/otlp v1.9.0 h1:l706jCMITVouPOqEnii2fIAuO3IVGBRPV5ICjceRb/A=
+go.opentelemetry.io/proto/otlp v1.10.0 h1:IQRWgT5srOCYfiWnpqUYz9CVmbO8bFmKcwYxpuCSL2g=
+go.yaml.in/yaml/v2 v2.4.3 h1:6gvOSjQoTB3vt1l+CU+tSyi/HOjfOjRLJ4YwYZGwRO0=
+go.yaml.in/yaml/v2 v2.4.3/go.mod h1:zSxWcmIDjOzPXpjlTTbAsKokqkDNAVtZO0WOMiT90s8=
+go.yaml.in/yaml/v2 v2.4.4 h1:tuyd0P+2Ont/d6e2rl3be67goVK4R6deVxCUX5vyPaQ=
+go.yaml.in/yaml/v3 v3.0.4/go.mod h1:DhzuOOF2ATzADvBadXxruRBLzYTpT36CKvDb3+aBEFg=
+golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
+golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
+golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
+golang.org/x/crypto v0.45.0 h1:jMBrvKuj23MTlT0bQEOBcAE0mjg8mK9RXFhRH6nyF3Q=
+golang.org/x/crypto v0.45.0/go.mod h1:XTGrrkGJve7CYK7J8PEww4aY7gM3qMCElcJQ8n8JdX4=
+golang.org/x/crypto v0.46.0 h1:cKRW/pmt1pKAfetfu+RCEvjvZkA9RimPbh7bhFjGVBU=
+golang.org/x/crypto v0.46.0/go.mod h1:Evb/oLKmMraqjZ2iQTwDwvCtJkczlDuTmdJXoZVzqU0=
+golang.org/x/crypto v0.47.0 h1:V6e3FRj+n4dbpw86FJ8Fv7XVOql7TEwpHapKoMJ/GO8=
+golang.org/x/crypto v0.47.0/go.mod h1:ff3Y9VzzKbwSSEzWqJsJVBnWmRwRSHt/6Op5n9bQc4A=
+golang.org/x/crypto v0.48.0 h1:/VRzVqiRSggnhY7gNRxPauEQ5Drw9haKdM0jqfcCFts=
+golang.org/x/crypto v0.48.0/go.mod h1:r0kV5h3qnFPlQnBSrULhlsRfryS2pmewsg+XfMgkVos=
+golang.org/x/crypto v0.50.0 h1:zO47/JPrL6vsNkINmLoo/PH1gcxpls50DNogFvB5ZGI=
+golang.org/x/crypto v0.52.0 h1:RMs7fP2rXdep0CftQlK8Uf+kibLm7qkCcradZWYz988=
+golang.org/x/crypto v0.53.0 h1:QZ4Muo8THX6CizN2vPPd5fBGHyogrdK9fG4wLPFUsto=
+golang.org/x/crypto v0.54.0 h1:YLIA59K4fiNzHzjnZt2tUJQjQtUWfWbeHBqKtk3eScw=
+golang.org/x/exp v0.0.0-20250911091902-df9299821621 h1:2id6c1/gto0kaHYyrixvknJ8tUK/Qs5IsmBtrc+FtgU=
+golang.org/x/exp v0.0.0-20250911091902-df9299821621/go.mod h1:TwQYMMnGpvZyc+JpB/UAuTNIsVJifOlSkrZkhcvpVUk=
+golang.org/x/exp v0.0.0-20260603202125-055de637280b h1:v1uXiEBHo8QA0LiGCo7UgHMzHT4Kdfpl2zmtH5vaP1Q=
+golang.org/x/mod v0.2.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
+golang.org/x/mod v0.3.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
+golang.org/x/mod v0.29.0 h1:HV8lRxZC4l2cr3Zq1LvtOsi/ThTgWnUk/y64QSs8GwA=
+golang.org/x/mod v0.29.0/go.mod h1:NyhrlYXJ2H4eJiRy/WDBO6HMqZQ6q9nk4JzS3NuCK+w=
+golang.org/x/mod v0.31.0 h1:HaW9xtz0+kOcWKwli0ZXy79Ix+UW/vOfmWI5QVd2tgI=
+golang.org/x/mod v0.31.0/go.mod h1:43JraMp9cGx1Rx3AqioxrbrhNsLl2l/iNAvuBkrezpg=
+golang.org/x/mod v0.33.0 h1:tHFzIWbBifEmbwtGz65eaWyGiGZatSrT9prnU8DbVL8=
+golang.org/x/mod v0.33.0/go.mod h1:swjeQEj+6r7fODbD2cqrnje9PnziFuw4bmLbBZFrQ5w=
+golang.org/x/mod v0.34.0 h1:xIHgNUUnW6sYkcM5Jleh05DvLOtwc6RitGHbDk4akRI=
+golang.org/x/mod v0.36.0 h1:JJjpVx6myfUsUdAzZuOSTTmRE0PfZeNWzzvKrP7amb4=
+golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
+golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
+golang.org/x/net v0.0.0-20200226121028-0de0cce0169b/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
+golang.org/x/net v0.0.0-20201021035429-f5854403a974/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=
+golang.org/x/net v0.47.0 h1:Mx+4dIFzqraBXUugkia1OOvlD6LemFo1ALMHjrXDOhY=
+golang.org/x/net v0.47.0/go.mod h1:/jNxtkgq5yWUGYkaZGqo27cfGZ1c5Nen03aYrrKpVRU=
+golang.org/x/net v0.48.0 h1:zyQRTTrjc33Lhh0fBgT/H3oZq9WuvRR5gPC70xpDiQU=
+golang.org/x/net v0.48.0/go.mod h1:+ndRgGjkh8FGtu1w1FGbEC31if4VrNVMuKTgcAAnQRY=
+golang.org/x/net v0.49.0 h1:eeHFmOGUTtaaPSGNmjBKpbng9MulQsJURQUAfUwY++o=
+golang.org/x/net v0.51.0 h1:94R/GTO7mt3/4wIKpcR5gkGmRLOuE/2hNGeWq/GBIFo=
+golang.org/x/net v0.53.0 h1:d+qAbo5L0orcWAr0a9JweQpjXF19LMXJE8Ey7hwOdUA=
+golang.org/x/net v0.55.0 h1:bcvxaJn3e1U6InsFWt1JUq1aSjnRxLzT2rtD2KfkDF8=
+golang.org/x/net v0.56.0 h1:Rw8j/hFzGvJUZwNBXnAtf5sVDVt+65SK2C7IxCxZt5o=
+golang.org/x/net v0.57.0 h1:K5+3DljvIuDG9/Jv9rvyMywYNFCQ9RSUY6OOTTkT+tE=
+golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
+golang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
+golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
+golang.org/x/sync v0.18.0 h1:kr88TuHDroi+UVf+0hZnirlk8o8T+4MrK6mr60WkH/I=
+golang.org/x/sync v0.18.0/go.mod h1:9KTHXmSnoGruLpwFjVSX0lNNA75CykiMECbovNTZqGI=
+golang.org/x/sync v0.19.0 h1:vV+1eWNmZ5geRlYjzm2adRgW2/mcpevXNg50YZtPCE4=
+golang.org/x/sync v0.19.0/go.mod h1:9KTHXmSnoGruLpwFjVSX0lNNA75CykiMECbovNTZqGI=
+golang.org/x/sync v0.20.0 h1:e0PTpb7pjO8GAtTs2dQ6jYa5BWYlMuX047Dco/pItO4=
+golang.org/x/sync v0.20.0/go.mod h1:9xrNwdLfx4jkKbNva9FpL6vEN7evnE43NNNJQ2LF3+0=
+golang.org/x/sync v0.21.0 h1:HLII4xRRTtCRkxYp4HNFF0Js/Og6q2i++KXbg0gHCwM=
+golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
+golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20190916202348-b4ddaad3f8a3/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20191005200804-aed5e4c7ecf9/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20200625212154-ddb9806d33ae/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20210616094352-59db8d763f22/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.0.0-20220715151400-c0bba94af5f8/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.0.0-20220908164124-27713097b956/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.1.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.38.0 h1:3yZWxaJjBmCWXqhN1qh02AkOnCQ1poK6oF+a7xWL6Gc=
+golang.org/x/sys v0.38.0/go.mod h1:OgkHotnGiDImocRcuBABYBEXf8A9a87e/uXjp9XT3ks=
+golang.org/x/sys v0.39.0 h1:CvCKL8MeisomCi6qNZ+wbb0DN9E5AATixKsvNtMoMFk=
+golang.org/x/sys v0.39.0/go.mod h1:OgkHotnGiDImocRcuBABYBEXf8A9a87e/uXjp9XT3ks=
+golang.org/x/sys v0.41.0 h1:Ivj+2Cp/ylzLiEU89QhWblYnOE9zerudt9Ftecq2C6k=
+golang.org/x/sys v0.41.0/go.mod h1:OgkHotnGiDImocRcuBABYBEXf8A9a87e/uXjp9XT3ks=
+golang.org/x/sys v0.42.0 h1:omrd2nAlyT5ESRdCLYdm3+fMfNFE/+Rf4bDIQImRJeo=
+golang.org/x/sys v0.42.0/go.mod h1:4GL1E5IUh+htKOUEOaiffhrAeqysfVGipDYzABqnCmw=
+golang.org/x/sys v0.43.0 h1:Rlag2XtaFTxp19wS8MXlJwTvoh8ArU6ezoyFsMyCTNI=
+golang.org/x/sys v0.43.0/go.mod h1:4GL1E5IUh+htKOUEOaiffhrAeqysfVGipDYzABqnCmw=
+golang.org/x/sys v0.44.0 h1:ildZl3J4uzeKP07r2F++Op7E9B29JRUy+a27EibtBTQ=
+golang.org/x/sys v0.45.0 h1:dO4czNzziLiiXplLQgBCEpCvXQ3dnkn0SdaZSYdQ+FY=
+golang.org/x/sys v0.46.0 h1:noSf2Fq6F8DBgS+LysIkx7rIExoNHJsxOAtPp4rthXw=
+golang.org/x/term v0.37.0 h1:8EGAD0qCmHYZg6J17DvsMy9/wJ7/D/4pV/wfnld5lTU=
+golang.org/x/term v0.37.0/go.mod h1:5pB4lxRNYYVZuTLmy8oR2BH8dflOR+IbTYFD8fi3254=
+golang.org/x/term v0.38.0 h1:PQ5pkm/rLO6HnxFR7N2lJHOZX6Kez5Y1gDSJla6jo7Q=
+golang.org/x/term v0.38.0/go.mod h1:bSEAKrOT1W+VSu9TSCMtoGEOUcKxOKgl3LE5QEF/xVg=
+golang.org/x/term v0.40.0 h1:36e4zGLqU4yhjlmxEaagx2KuYbJq3EwY8K943ZsHcvg=
+golang.org/x/term v0.41.0 h1:QCgPso/Q3RTJx2Th4bDLqML4W6iJiaXFq2/ftQF13YU=
+golang.org/x/term v0.42.0 h1:UiKe+zDFmJobeJ5ggPwOshJIVt6/Ft0rcfrXZDLWAWY=
+golang.org/x/term v0.43.0 h1:S4RLU2sB31O/NCl+zFN9Aru9A/Cq2aqKpTZJ6B+DwT4=
+golang.org/x/term v0.44.0 h1:0rLvDRCtNj0gZkyIXhCyOb2OAzEhLVqc4B+hrsBhrmc=
+golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
+golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
+golang.org/x/text v0.31.0 h1:aC8ghyu4JhP8VojJ2lEHBnochRno1sgL6nEi9WGFGMM=
+golang.org/x/text v0.31.0/go.mod h1:tKRAlv61yKIjGGHX/4tP1LTbc13YSec1pxVEWXzfoeM=
+golang.org/x/text v0.32.0 h1:ZD01bjUt1FQ9WJ0ClOL5vxgxOI/sVCNgX1YtKwcY0mU=
+golang.org/x/text v0.32.0/go.mod h1:o/rUWzghvpD5TXrTIBuJU77MTaN0ljMWE47kxGJQ7jY=
+golang.org/x/text v0.33.0 h1:B3njUFyqtHDUI5jMn1YIr5B0IE2U0qck04r6d4KPAxE=
+golang.org/x/text v0.34.0 h1:oL/Qq0Kdaqxa1KbNeMKwQq0reLCCaFtqu2eNuSeNHbk=
+golang.org/x/text v0.36.0 h1:JfKh3XmcRPqZPKevfXVpI1wXPTqbkE5f7JA92a55Yxg=
+golang.org/x/text v0.37.0 h1:Cqjiwd9eSg8e0QAkyCaQTNHFIIzWtidPahFWR83rTrc=
+golang.org/x/text v0.38.0 h1:sXmwo9DwP3OK9EZ7PqAdaooSGozfl/3a6/xJcbzPRhE=
+golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
+golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
+golang.org/x/tools v0.0.0-20200619180055-7c47624df98f/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE=
+golang.org/x/tools v0.0.0-20210106214847-113979e3529a/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA=
+golang.org/x/tools v0.38.0 h1:Hx2Xv8hISq8Lm16jvBZ2VQf+RLmbd7wVUsALibYI/IQ=
+golang.org/x/tools v0.38.0/go.mod h1:yEsQ/d/YK8cjh0L6rZlY8tgtlKiBNTL14pGDJPJpYQs=
+golang.org/x/tools v0.39.0 h1:ik4ho21kwuQln40uelmciQPp9SipgNDdrafrYA4TmQQ=
+golang.org/x/tools v0.39.0/go.mod h1:JnefbkDPyD8UU2kI5fuf8ZX4/yUeh9W877ZeBONxUqQ=
+golang.org/x/tools v0.40.0 h1:yLkxfA+Qnul4cs9QA3KnlFu0lVmd8JJfoq+E41uSutA=
+golang.org/x/tools v0.40.0/go.mod h1:Ik/tzLRlbscWpqqMRjyWYDisX8bG13FrdXp3o4Sr9lc=
+golang.org/x/tools v0.41.0 h1:a9b8iMweWG+S0OBnlU36rzLp20z1Rp10w+IY2czHTQc=
+golang.org/x/tools v0.41.0/go.mod h1:XSY6eDqxVNiYgezAVqqCeihT4j1U2CCsqvH3WhQpnlg=
+golang.org/x/tools v0.43.0 h1:12BdW9CeB3Z+J/I/wj34VMl8X+fEXBxVR90JeMX5E7s=
+golang.org/x/tools v0.45.0 h1:18qN3FAooORvApf5XjCXgsuayZOEtXf6JK18I3+ONa8=
+golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
+golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
+golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
+golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
+gonum.org/v1/gonum v0.16.0 h1:5+ul4Swaf3ESvrOnidPp4GZbzf0mxVQpDCYUQE7OJfk=
+gonum.org/v1/gonum v0.16.0/go.mod h1:fef3am4MQ93R2HHpKnLk4/Tbh/s0+wqD5nfa6Pnwy4E=
+google.golang.org/genproto/googleapis/api v0.0.0-20251022142026-3a174f9686a8 h1:mepRgnBZa07I4TRuomDE4sTIYieg/osKmzIf4USdWS4=
+google.golang.org/genproto/googleapis/api v0.0.0-20251022142026-3a174f9686a8/go.mod h1:fDMmzKV90WSg1NbozdqrE64fkuTv6mlq2zxo9ad+3yo=
+google.golang.org/genproto/googleapis/api v0.0.0-20251103181224-f26f9409b101 h1:vk5TfqZHNn0obhPIYeS+cxIFKFQgser/M2jnI+9c6MM=
+google.golang.org/genproto/googleapis/api v0.0.0-20251103181224-f26f9409b101/go.mod h1:E17fc4PDhkr22dE3RgnH2hEubUaky6ZwW4VhANxyspg=
+google.golang.org/genproto/googleapis/api v0.0.0-20260128011058-8636f8732409 h1:merA0rdPeUV3YIIfHHcH4qBkiQAc1nfCKSI7lB4cV2M=
+google.golang.org/genproto/googleapis/rpc v0.0.0-20251022142026-3a174f9686a8 h1:M1rk8KBnUsBDg1oPGHNCxG4vc1f49epmTO7xscSajMk=
+google.golang.org/genproto/googleapis/rpc v0.0.0-20251022142026-3a174f9686a8/go.mod h1:7i2o+ce6H/6BluujYR+kqX3GKH+dChPTQU19wjRPiGk=
+google.golang.org/genproto/googleapis/rpc v0.0.0-20251103181224-f26f9409b101 h1:tRPGkdGHuewF4UisLzzHHr1spKw92qLM98nIzxbC0wY=
+google.golang.org/genproto/googleapis/rpc v0.0.0-20251103181224-f26f9409b101/go.mod h1:7i2o+ce6H/6BluujYR+kqX3GKH+dChPTQU19wjRPiGk=
+google.golang.org/genproto/googleapis/rpc v0.0.0-20260128011058-8636f8732409 h1:H86B94AW+VfJWDqFeEbBPhEtHzJwJfTbgE2lZa54ZAQ=
+google.golang.org/grpc v1.77.0 h1:wVVY6/8cGA6vvffn+wWK5ToddbgdU3d8MNENr4evgXM=
+google.golang.org/grpc v1.77.0/go.mod h1:z0BY1iVj0q8E1uSQCjL9cppRj+gnZjzDnzV0dHhrNig=
+google.golang.org/protobuf v1.36.10 h1:AYd7cD/uASjIL6Q9LiTjz8JLcrh/88q5UObnmY3aOOE=
+google.golang.org/protobuf v1.36.10/go.mod h1:HTf+CrKn2C3g5S8VImy6tdcUvCska2kB7j23XfzDpco=
+google.golang.org/protobuf v1.36.11 h1:fV6ZwhNocDyBLK0dj+fg8ektcVegBBuEolpbTQyBNVE=
+google.golang.org/protobuf v1.36.11/go.mod h1:HTf+CrKn2C3g5S8VImy6tdcUvCska2kB7j23XfzDpco=
+google.golang.org/protobuf v1.36.12-0.20260120151049-f2248ac996af h1:+5/Sw3GsDNlEmu7TfklWKPdQ0Ykja5VEmq2i817+jbI=
+gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
+gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7 h1:uRGJdciOHaEIrze2W8Q3AKkepLTh2hOroT7a+7czfdQ=
+gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7/go.mod h1:dt/ZhP58zS4L8KSrWDmTeBkI65Dw0HsyUHuEVlX15mw=
+gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=
+gopkg.in/yaml.v3 v3.0.1 h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA=
+gopkg.in/yaml.v3 v3.0.1/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=
+howett.net/plist v1.0.2-0.20250314012144-ee69052608d9 h1:eeH1AIcPvSc0Z25ThsYF+Xoqbn0CI/YnXVYoTLFdGQw=
+howett.net/plist v1.0.2-0.20250314012144-ee69052608d9/go.mod h1:fyFX5Hj5tP1Mpk8obqA9MZgXT416Q5711SDT7dQLTLk=
diff --git a/hack/flatten-and-resolve.js b/hack/flatten-and-resolve.js
new file mode 100755
index 000000000000..04532d343eb5
--- /dev/null
+++ b/hack/flatten-and-resolve.js
@@ -0,0 +1,236 @@
+#!/usr/bin/env node
+
+/**
+ * Flattens markdown directory structure and resolves all links to absolute paths.
+ *
+ * This script:
+ * 1. Moves index.md files up one level (ai/model-runner/index.md -> ai/model-runner.md)
+ * 2. Fixes _index.md and index.md references in links
+ * 3. Strips /manuals/ prefix from paths (Hugo config removes this)
+ * 4. Resolves all relative links to absolute HTML paths for RAG ingestion
+ *
+ * Usage: node flatten-and-resolve.js [public-dir]
+ */
+
+const fs = require('fs');
+const path = require('path');
+
+const PUBLIC_DIR = path.resolve(process.argv[2] || 'public');
+
+if (!fs.existsSync(PUBLIC_DIR)) {
+  console.error(`Error: Directory ${PUBLIC_DIR} does not exist`);
+  process.exit(1);
+}
+
+/**
+ * Recursively find all files matching a predicate
+ */
+function findFiles(dir, predicate) {
+  const results = [];
+  const entries = fs.readdirSync(dir, { withFileTypes: true });
+
+  for (const entry of entries) {
+    const fullPath = path.join(dir, entry.name);
+    if (entry.isDirectory()) {
+      results.push(...findFiles(fullPath, predicate));
+    } else if (entry.isFile() && predicate(entry.name)) {
+      results.push(fullPath);
+    }
+  }
+
+  return results;
+}
+
+/**
+ * Step 1: Flatten index.md files
+ * Move path/to/section/index.md -> path/to/section.md
+ * Before moving, rewrite sibling links (e.g., "get-started.md" -> "section/get-started.md")
+ */
+function flattenIndexFiles() {
+  const indexFiles = findFiles(PUBLIC_DIR, name => name === 'index.md');
+  let count = 0;
+
+  for (const file of indexFiles) {
+    // Skip root index.md
+    if (file === path.join(PUBLIC_DIR, 'index.md')) {
+      continue;
+    }
+
+    const dir = path.dirname(file);
+    const dirname = path.basename(dir);
+
+    // Read content and fix sibling links
+    let content = fs.readFileSync(file, 'utf8');
+
+    // Rewrite relative links that don't start with /, ../, or http
+    // These are sibling files that will become children after flattening
+    content = content.replace(
+      /\[([^\]]+)\]\(([a-zA-Z0-9][^):]*)\)/g,
+      (match, text, link) => {
+        // Skip if it's a URL or starts with special chars
+        if (link.startsWith('http://') || link.startsWith('https://') ||
+            link.startsWith('#')) {
+          return match;
+        }
+        return `[${text}](${dirname}/${link})`;
+      }
+    );
+
+    // Also fix reference-style links
+    content = content.replace(
+      /^\[([^\]]+)\]:\s+([a-zA-Z0-9][^: ]*\.md)$/gm,
+      (match, ref, link) => `[${ref}]: ${dirname}/${link}`
+    );
+
+    fs.writeFileSync(file, content, 'utf8');
+
+    // Move file up one level
+    const parentDir = path.dirname(dir);
+    const newPath = path.join(parentDir, `${dirname}.md`);
+    fs.renameSync(file, newPath);
+
+    count++;
+  }
+
+  console.log(`Flattened ${count} index.md files`);
+  return count;
+}
+
+/**
+ * Step 2: Fix _index.md and index.md references in all files
+ * Also strip /manuals/ prefix from paths
+ */
+function fixIndexReferences() {
+  const mdFiles = findFiles(PUBLIC_DIR, name => name.endsWith('.md'));
+  let count = 0;
+
+  for (const file of mdFiles) {
+    const dir = path.dirname(file);
+    const dirname = path.basename(dir);
+    const parentDir = path.dirname(dir);
+    const parentDirname = path.basename(parentDir);
+
+    let content = fs.readFileSync(file, 'utf8');
+    const original = content;
+
+    // Fix path/_index.md or path/index.md -> path.md
+    content = content.replace(/([a-zA-Z0-9_/-]+)\/_?index\.md/g, '$1.md');
+
+    // Fix bare _index.md or index.md -> ../dirname.md
+    content = content.replace(/_?index\.md/g, `../${dirname}.md`);
+
+    // Fix ../_index.md that became ...md -> ../../parentdirname.md
+    if (parentDir !== PUBLIC_DIR) {
+      content = content.replace(/\.\.\.md/g, `../../${parentDirname}.md`);
+    }
+
+    // Strip /manuals/ prefix (both /manuals/ and manuals/)
+    content = content.replace(/\/?manuals\//g, '/');
+
+    if (content !== original) {
+      fs.writeFileSync(file, content, 'utf8');
+      count++;
+    }
+  }
+
+  console.log(`Fixed _index.md references in ${count} files`);
+  return count;
+}
+
+/**
+ * Step 3: Resolve all relative links to absolute HTML paths
+ */
+function resolveLinks() {
+  const mdFiles = findFiles(PUBLIC_DIR, name => name.endsWith('.md'));
+  let count = 0;
+
+  for (const file of mdFiles) {
+    let content = fs.readFileSync(file, 'utf8');
+    const original = content;
+
+    // Process inline links: [text](path)
+    content = content.replace(/\[([^\]]+)\]\(([^)]+)\)/g, (match, text, link) => {
+      const resolved = resolveLinkPath(link, file);
+      return `[${text}](${resolved})`;
+    });
+
+    // Process reference-style links: [ref]: path
+    content = content.replace(/^\[([^\]]+)\]:\s+(.+)$/gm, (match, ref, link) => {
+      const resolved = resolveLinkPath(link, file);
+      return `[${ref}]: ${resolved}`;
+    });
+
+    if (content !== original) {
+      fs.writeFileSync(file, content, 'utf8');
+      count++;
+    }
+  }
+
+  console.log(`Resolved links in ${count} files`);
+  return count;
+}
+
+/**
+ * Resolve a link path to absolute HTML format
+ */
+function resolveLinkPath(linkPath, currentFile) {
+  // Skip external URLs and mailto
+  if (linkPath.startsWith('http://') || linkPath.startsWith('https://') ||
+      linkPath.startsWith('mailto:')) {
+    return linkPath;
+  }
+
+  // Skip same-page anchors
+  if (linkPath.startsWith('#')) {
+    return linkPath;
+  }
+
+  // Split path and anchor
+  const hashIndex = linkPath.indexOf('#');
+  const pathPart = hashIndex >= 0 ? linkPath.substring(0, hashIndex) : linkPath;
+  const anchorPart = hashIndex >= 0 ? linkPath.substring(hashIndex) : '';
+
+  if (!pathPart) {
+    // Just an anchor
+    return linkPath;
+  }
+
+  // Handle absolute paths - just convert to HTML format
+  if (pathPart.startsWith('/')) {
+    return toHtmlPath(pathPart) + anchorPart;
+  }
+
+  // Resolve relative path to absolute
+  const currentDir = path.dirname(currentFile);
+  const absolutePath = path.resolve(currentDir, pathPart);
+  const relativePath = path.relative(PUBLIC_DIR, absolutePath);
+
+  // Convert to URL path (forward slashes)
+  const urlPath = '/' + relativePath.split(path.sep).join('/');
+
+  return toHtmlPath(urlPath) + anchorPart;
+}
+
+/**
+ * Convert a path to HTML format (strip .md, add trailing /)
+ */
+function toHtmlPath(urlPath) {
+  if (urlPath.endsWith('.md')) {
+    return urlPath.slice(0, -3) + '/';
+  }
+  return urlPath;
+}
+
+// Main execution
+console.log('Starting markdown flattening and link resolution...');
+console.log('');
+
+const flattenCount = flattenIndexFiles();
+const fixCount = fixIndexReferences();
+const resolveCount = resolveLinks();
+
+console.log('');
+console.log('Done!');
+console.log(`- Flattened: ${flattenCount} files`);
+console.log(`- Fixed references: ${fixCount} files`);
+console.log(`- Resolved links: ${resolveCount} files`);
diff --git a/hack/moby-sync-release.sh b/hack/moby-sync-release.sh
new file mode 100755
index 000000000000..edce7938574e
--- /dev/null
+++ b/hack/moby-sync-release.sh
@@ -0,0 +1,57 @@
+#!/bin/bash
+# Update the Github release notes to match the release notes from the docs.
+set -euo pipefail
+
+version="${1:-}"
+
+if [ -z "$version" ]; then
+    echo "Usage: $0 <version>"
+    exit 1
+fi
+
+moby="moby/moby"
+version="${version#v}" # remove the v prefix
+major_version="${version%%.*}" # get the major version (e.g. 29.0.3 -> 29)
+moby_tag="docker-v${version}"
+
+docs_notes=$(mktemp   -t new)
+github_notes=$(mktemp -t old)
+
+# Get the release notes from the docs.
+awk -v heading="## ${version}" '
+    $0 == heading { found = 1; print; next }
+    found && /^## / { exit }
+    found { print }
+    END { if (!found) exit 1 }
+' "content/manuals/engine/release-notes/${major_version}.md" | \
+    sed '/{{< release-date /{N;d;}' \
+    > "$docs_notes" || { echo "Release notes for ${version} not found" && exit 1; }
+
+release_json=$(gh api repos/moby/moby/releases -q ".[] | select(.name==\"v${version}\" or .tag_name==\"$moby_tag\")")
+
+if [ -z "$release_json" ]; then
+    echo "Release not found"
+    printf '\033[0;34mTo create the draft Github release run the following command:\033[0m\n\n'
+    echo gh -R moby/moby release create --draft \
+        --notes-file '"'$docs_notes'"' \
+        --title '"'v${version}'"' \
+        ${moby_tag}
+    exit 1
+fi
+
+release_id=$(echo "$release_json" | jq -r '.id')
+echo "$release_json" | jq -r '.body' | sed 's/\r$//' > "$github_notes"
+
+docs_notes_diff=$(mktemp -t diff)
+# Copy docs_notes content and ensure it has exactly 1 blank line at the end
+sed -e :a -e '/^\n*$/{$d;N;ba' -e '}' "$docs_notes" | sed '$a\' > "$docs_notes_diff"
+
+# Compare the release notes.
+if diff -u --color=auto "$github_notes" "$docs_notes_diff"; then
+    printf '\033[0;32mThe release notes are already up to date.\033[0m\n'
+    exit 0
+fi
+
+echo '========================================'
+printf '\033[0;34mTo update the release notes run the following command:\033[0m\n\n'
+echo gh api "repos/moby/moby/releases/$release_id" -X PATCH -f '"body=$(cat "'$docs_notes'")"'
diff --git a/hack/releaser/Dockerfile b/hack/releaser/Dockerfile
index 11c574d173a0..fa4c6f6dc46e 100644
--- a/hack/releaser/Dockerfile
+++ b/hack/releaser/Dockerfile
@@ -1,6 +1,6 @@
 # syntax=docker/dockerfile:1
 
-ARG GO_VERSION=1.23
+ARG GO_VERSION=1.26
 
 FROM scratch AS sitedir
 
@@ -8,9 +8,6 @@ FROM golang:${GO_VERSION}-alpine AS base
 RUN apk add --no-cache openssl
 ENV CGO_ENABLED=0
 WORKDIR /src
-COPY go.mod go.sum ./
-RUN --mount=type=cache,target=/go/pkg/mod \
-  go mod download
 
 FROM base AS releaser
 RUN --mount=type=bind,target=. \
@@ -18,17 +15,11 @@ RUN --mount=type=bind,target=. \
   --mount=type=cache,target=/root/.cache/go-build \
   go build -o /out/releaser .
 
-FROM base AS aws-s3-update-config
-ARG DRY_RUN=false
-ARG AWS_REGION
-ARG AWS_S3_BUCKET
-ARG AWS_S3_CONFIG
+# releaser-test runs the unit tests for the CloudFront redirect Lambda function.
+FROM base AS releaser-test
+RUN apk add --no-cache nodejs
 RUN --mount=type=bind,target=. \
-  --mount=type=bind,from=releaser,source=/out/releaser,target=/usr/bin/releaser \
-  --mount=type=secret,id=AWS_ACCESS_KEY_ID \
-  --mount=type=secret,id=AWS_SECRET_ACCESS_KEY \
-  --mount=type=secret,id=AWS_SESSION_TOKEN \
-  releaser aws s3-update-config
+  node --test cloudfront-lambda-redirects.test.js
 
 FROM base AS aws-lambda-invoke
 ARG DRY_RUN=false
diff --git a/hack/releaser/aws.go b/hack/releaser/aws.go
index b608b7c5d413..1153a9873912 100644
--- a/hack/releaser/aws.go
+++ b/hack/releaser/aws.go
@@ -3,7 +3,6 @@ package main
 import (
 	"archive/zip"
 	"bytes"
-	"encoding/json"
 	"errors"
 	"fmt"
 	"log"
@@ -18,66 +17,13 @@ import (
 	"github.com/aws/aws-sdk-go/aws/session"
 	"github.com/aws/aws-sdk-go/service/cloudfront"
 	"github.com/aws/aws-sdk-go/service/lambda"
-	"github.com/aws/aws-sdk-go/service/s3"
 )
 
 type AwsCmd struct {
-	S3UpdateConfig   AwsS3UpdateConfigCmd   `kong:"cmd,name=s3-update-config"`
 	LambdaInvoke     AwsLambdaInvokeCmd     `kong:"cmd,name=lambda-invoke"`
 	CloudfrontUpdate AwsCloudfrontUpdateCmd `kong:"cmd,name=cloudfront-update"`
 }
 
-type AwsS3UpdateConfigCmd struct {
-	Region   string `kong:"name='region',env='AWS_REGION'"`
-	S3Bucket string `kong:"name='s3-bucket',env='AWS_S3_BUCKET'"`
-	S3Config string `kong:"name='s3-website-config',env='AWS_S3_CONFIG'"`
-	DryRun   bool   `kong:"name='dry-run',env='DRY_RUN'"`
-}
-
-func (s *AwsS3UpdateConfigCmd) Run() error {
-	if s.DryRun {
-		log.Printf("INFO: Dry run mode enabled. Configuration:\nRegion: %s\nS3Bucket: %s\nS3Config: %s\n", s.Region, s.S3Bucket, s.S3Config)
-		return nil
-	}
-
-	file, err := os.ReadFile(s.S3Config)
-	if err != nil {
-		return fmt.Errorf("failed to read s3 config file %s: %w", s.S3Config, err)
-	}
-
-	data := s3.WebsiteConfiguration{}
-	err = json.Unmarshal(file, &data)
-	if err != nil {
-		return fmt.Errorf("failed to parse JSON from %s: %w", s.S3Config, err)
-	}
-
-	sess, err := session.NewSession(&aws.Config{
-		Credentials: awsCredentials(),
-		Region:      aws.String(s.Region),
-	})
-	if err != nil {
-		return fmt.Errorf("failed to create session: %w", err)
-	}
-
-	svc := s3.New(sess)
-
-	// Create SetBucketWebsite parameters based on the JSON file input
-	params := s3.PutBucketWebsiteInput{
-		Bucket:               aws.String(s.S3Bucket),
-		WebsiteConfiguration: &data,
-	}
-
-	// Set the website configuration on the bucket.
-	// Replacing any existing configuration.
-	_, err = svc.PutBucketWebsite(&params)
-	if err != nil {
-		return fmt.Errorf("unable to set bucket %q website configuration: %w", s.S3Bucket, err)
-	}
-
-	log.Printf("INFO: successfully set bucket %q website configuration\n", s.S3Bucket)
-	return nil
-}
-
 type AwsLambdaInvokeCmd struct {
 	Region         string `kong:"name='region',env='AWS_REGION'"`
 	LambdaFunction string `kong:"name='lambda-function',env='AWS_LAMBDA_FUNCTION'"`
diff --git a/hack/releaser/cloudfront-lambda-redirects.js b/hack/releaser/cloudfront-lambda-redirects.js
index e5996559201e..7d3d4cfe1992 100644
--- a/hack/releaser/cloudfront-lambda-redirects.js
+++ b/hack/releaser/cloudfront-lambda-redirects.js
@@ -1,56 +1,118 @@
-'use strict';
+"use strict";
 
 exports.handler = (event, context, callback) => {
-    //console.log("event", JSON.stringify(event));
-    const request = event.Records[0].cf.request;
-    const requestUrl = request.uri.replace(/\/$/, "")
-
-    const redirects = JSON.parse(`{{.RedirectsJSON}}`);
-    for (let key in redirects) {
-        const redirectTarget = key.replace(/\/$/, "")
-        if (redirectTarget !== requestUrl) {
-            continue;
-        }
-        //console.log(`redirect: ${requestUrl} to ${redirects[key]}`);
-        const response = {
-            status: '301',
-            statusDescription: 'Moved Permanently',
-            headers: {
-                location: [{
-                    key: 'Location',
-                    value: redirects[key],
-                }],
-            },
-        }
-        callback(null, response);
-        return
+  //console.log("event", JSON.stringify(event));
+  const request = event.Records[0].cf.request;
+  const requestUrl = request.uri.replace(/\/$/, "");
+
+  // Preserve the query string (e.g. UTM tags) when issuing a redirect.
+  const withQuery = (location) => {
+    if (!request.querystring) {
+      return location;
+    }
+    const isRelative = location.startsWith("/") && !location.startsWith("//");
+    const url = new URL(location, "https://docs.docker.com");
+    const query = new URLSearchParams(request.querystring);
+    for (const [key, value] of query) {
+      url.searchParams.append(key, value);
+    }
+    return isRelative ? url.pathname + url.search + url.hash : url.href;
+  };
+
+  const redirects = JSON.parse(`{{.RedirectsJSON}}`);
+  for (let key in redirects) {
+    const redirectTarget = key.replace(/\/$/, "");
+    const exactMatch = key === request.uri;
+    // Preserve slash-insensitive matching without redirecting a canonical
+    // slash-terminated destination back to itself.
+    const normalizedMatch =
+      redirectTarget === requestUrl && redirects[key] !== request.uri;
+    if (!exactMatch && !normalizedMatch) {
+      continue;
+    }
+    //console.log(`redirect: ${requestUrl} to ${redirects[key]}`);
+    const response = {
+      status: "301",
+      statusDescription: "Moved Permanently",
+      headers: {
+        location: [
+          {
+            key: "Location",
+            value: withQuery(redirects[key]),
+          },
+        ],
+      },
+    };
+    callback(null, response);
+    return;
+  }
+
+  const redirectsPrefixes = JSON.parse(`{{.RedirectsPrefixesJSON}}`);
+  for (let x in redirectsPrefixes) {
+    const rp = redirectsPrefixes[x];
+    if (!request.uri.startsWith(`/${rp["prefix"]}`)) {
+      continue;
+    }
+    let newlocation = "/";
+    if (rp["strip"]) {
+      let re = new RegExp(`(^/${rp["prefix"]})`, "gi");
+      newlocation = request.uri.replace(re, "/");
     }
+    //console.log(`redirect: ${request.uri} to ${redirectsPrefixes[key]}`);
+    const response = {
+      status: "301",
+      statusDescription: "Moved Permanently",
+      headers: {
+        location: [
+          {
+            key: "Location",
+            value: withQuery(newlocation),
+          },
+        ],
+      },
+    };
+    callback(null, response);
+    return;
+  }
+
+  // Check Accept header for markdown/text requests
+  const headers = request.headers;
+  const acceptHeader = headers.accept ? headers.accept[0].value : "";
+  const wantsMarkdown =
+    acceptHeader.includes("text/markdown") ||
+    acceptHeader.includes("text/plain");
+
+  // Handle directory requests by appending index.html or index.md for requests without file extensions
+  let uri = request.uri;
+
+  // Check if the URI has a dot after the last slash (indicating a filename)
+  // This is more accurate than just checking the end of the URI
+  const hasFileExtension = /\.[^/]*$/.test(uri.split("/").pop());
 
-    const redirectsPrefixes = JSON.parse(`{{.RedirectsPrefixesJSON}}`);
-    for (let x in redirectsPrefixes) {
-        const rp = redirectsPrefixes[x];
-        if (!request.uri.startsWith(`/${rp['prefix']}`)) {
-            continue;
-        }
-        let newlocation = "/";
-        if (rp['strip']) {
-            let re = new RegExp(`(^/${rp['prefix']})`, 'gi');
-            newlocation = request.uri.replace(re,'/');
-        }
-        //console.log(`redirect: ${request.uri} to ${redirectsPrefixes[key]}`);
-        const response = {
-            status: '301',
-            statusDescription: 'Moved Permanently',
-            headers: {
-                location: [{
-                    key: 'Location',
-                    value: newlocation,
-                }],
-            },
-        }
-        callback(null, response);
-        return
+  // If it's not a file, treat it as a directory
+  if (!hasFileExtension) {
+    if (wantsMarkdown) {
+      // Markdown files are flattened: /path/to/page.md not /path/to/page/index.md.
+      // The homepage markdown output remains at /index.md.
+      const stripped = uri.replace(/\/$/, "");
+      uri = stripped === "" ? "/index.md" : stripped + ".md";
+    } else {
+      // HTML uses directory structure with index.html
+      if (!uri.endsWith("/")) {
+        uri += "/";
+      }
+      uri += "index.html";
     }
+    request.uri = uri;
+  } else if (wantsMarkdown && uri.endsWith("/index.html")) {
+    // If requesting index.html but wants markdown, use the flattened .md file.
+    // The homepage markdown output lives at /index.md.
+    uri =
+      uri === "/index.html"
+        ? "/index.md"
+        : uri.replace(/\/index\.html$/, ".md");
+    request.uri = uri;
+  }
 
-    callback(null, request);
+  callback(null, request);
 };
diff --git a/hack/releaser/cloudfront-lambda-redirects.test.js b/hack/releaser/cloudfront-lambda-redirects.test.js
new file mode 100644
index 000000000000..915e33b10d68
--- /dev/null
+++ b/hack/releaser/cloudfront-lambda-redirects.test.js
@@ -0,0 +1,153 @@
+"use strict";
+
+// Tests for cloudfront-lambda-redirects.js.
+//
+// The function source is a Go text/template (see aws.go) with two
+// placeholders that are filled with JSON at build time. These tests render
+// the template the same way aws.go does, then load and exercise the handler.
+//
+// Run with: node --test hack/releaser/cloudfront-lambda-redirects.test.js
+
+const { test } = require("node:test");
+const assert = require("node:assert/strict");
+const fs = require("node:fs");
+const path = require("node:path");
+const Module = require("node:module");
+
+const SRC = path.join(__dirname, "cloudfront-lambda-redirects.js");
+
+const REDIRECTS = {
+  "/learn": "/learn/",
+  "/old/page/": "/new/page/",
+  "/target-with-query/": "/dest/?ref=docs",
+  "/target-with-fragment/": "/dest/?ref=docs#install",
+  "/external-target/": "https://www.docker.com/example?ref=docs#install",
+};
+
+const REDIRECTS_PREFIXES = [
+  { prefix: "keep/", strip: false },
+  { prefix: "strip/", strip: true },
+];
+
+// Render the template the same way getLambdaFunctionZip in aws.go does, then
+// evaluate it as a CommonJS module so we can call handler() directly.
+function loadHandler() {
+  const rendered = fs
+    .readFileSync(SRC, "utf8")
+    // Function replacers avoid String.replace's special handling of `$`
+    // sequences in the replacement, in case a redirect target contains one.
+    .replace("{{.RedirectsJSON}}", () => JSON.stringify(REDIRECTS))
+    .replace("{{.RedirectsPrefixesJSON}}", () =>
+      JSON.stringify(REDIRECTS_PREFIXES),
+    );
+
+  const m = new Module(SRC);
+  m._compile(rendered, SRC);
+  return m.exports.handler;
+}
+
+const handler = loadHandler();
+
+// invoke wraps the callback-style handler in a promise.
+function invoke({ uri, querystring = "", accept = "text/html" }) {
+  const request = {
+    uri,
+    querystring,
+    headers: { accept: [{ key: "Accept", value: accept }] },
+  };
+  const event = { Records: [{ cf: { request } }] };
+  return new Promise((resolve, reject) => {
+    handler(event, {}, (err, result) => {
+      if (err) return reject(err);
+      resolve({ result, request });
+    });
+  });
+}
+
+function locationOf(result) {
+  return result.headers.location[0].value;
+}
+
+test("exact redirect preserves the query string", async () => {
+  const { result } = await invoke({
+    uri: "/old/page/",
+    querystring: "utm_source=newsletter&utm_campaign=launch",
+  });
+  assert.equal(result.status, "301");
+  assert.equal(
+    locationOf(result),
+    "/new/page/?utm_source=newsletter&utm_campaign=launch",
+  );
+});
+
+test("exact redirect without a query string is unchanged", async () => {
+  const { result } = await invoke({ uri: "/old/page/" });
+  assert.equal(result.status, "301");
+  assert.equal(locationOf(result), "/new/page/");
+});
+
+test("bare path redirects without redirecting the canonical target to itself", async () => {
+  const { result: bareResult } = await invoke({ uri: "/learn" });
+  assert.equal(bareResult.status, "301");
+  assert.equal(locationOf(bareResult), "/learn/");
+
+  const { result: canonicalResult, request } = await invoke({ uri: "/learn/" });
+  assert.equal(canonicalResult, request);
+  assert.equal(request.uri, "/learn/index.html");
+});
+
+test("exact redirect appends with & when target already has a query string", async () => {
+  const { result } = await invoke({
+    uri: "/target-with-query/",
+    querystring: "utm_medium=email",
+  });
+  assert.equal(locationOf(result), "/dest/?ref=docs&utm_medium=email");
+});
+
+test("exact redirect inserts the query string before a fragment", async () => {
+  const { result } = await invoke({
+    uri: "/target-with-fragment/",
+    querystring: "utm_medium=email",
+  });
+  assert.equal(locationOf(result), "/dest/?ref=docs&utm_medium=email#install");
+});
+
+test("exact redirect preserves an absolute target URL", async () => {
+  const { result } = await invoke({
+    uri: "/external-target/",
+    querystring: "utm_medium=email",
+  });
+  assert.equal(
+    locationOf(result),
+    "https://www.docker.com/example?ref=docs&utm_medium=email#install",
+  );
+});
+
+test("prefix redirect (strip) preserves the query string", async () => {
+  const { result } = await invoke({
+    uri: "/strip/some/path",
+    querystring: "utm_source=x",
+  });
+  assert.equal(result.status, "301");
+  assert.equal(locationOf(result), "/some/path?utm_source=x");
+});
+
+test("prefix redirect (no strip) preserves the query string", async () => {
+  const { result } = await invoke({
+    uri: "/keep/anything",
+    querystring: "utm_source=x",
+  });
+  assert.equal(result.status, "301");
+  assert.equal(locationOf(result), "/?utm_source=x");
+});
+
+test("directory rewrite passes the request through with query string intact", async () => {
+  const { result, request } = await invoke({
+    uri: "/some/page",
+    querystring: "utm_source=x",
+  });
+  // No redirect response: the handler forwards the (mutated) request.
+  assert.equal(result, request);
+  assert.equal(request.uri, "/some/page/index.html");
+  assert.equal(request.querystring, "utm_source=x");
+});
diff --git a/hack/releaser/env.json b/hack/releaser/env.json
new file mode 100644
index 000000000000..d880d2ae27b6
--- /dev/null
+++ b/hack/releaser/env.json
@@ -0,0 +1,20 @@
+{
+  "refs/heads/lab": {
+    "HUGO_ENV": "lab",
+    "DOCS_URL": "https://docs-labs.docker.com",
+    "DOCS_AWS_IAM_ROLE": "arn:aws:iam::710015040892:role/labs-docs-docs.docker.com-20220818202218402500000001",
+    "DOCS_AWS_REGION": "us-east-1",
+    "DOCS_S3_BUCKET": "labs-docs-docs.docker.com",
+    "DOCS_CLOUDFRONT_ID": "E1MYDYF65FW3HG",
+    "DOCS_LAMBDA_FUNCTION_REDIRECTS": "DockerDocsRedirectFunction-labs"
+  },
+  "refs/heads/main": {
+    "HUGO_ENV": "production",
+    "DOCS_URL": "https://docs.docker.com",
+    "DOCS_AWS_IAM_ROLE": "arn:aws:iam::710015040892:role/prod-docs-docs.docker.com-20220818202218674300000001",
+    "DOCS_AWS_REGION": "us-east-1",
+    "DOCS_S3_BUCKET": "prod-docs-docs.docker.com",
+    "DOCS_CLOUDFRONT_ID": "E228TTN20HNU8F",
+    "DOCS_LAMBDA_FUNCTION_REDIRECTS": "DockerDocsRedirectFunction-prod"
+  }
+}
diff --git a/hack/releaser/go.mod b/hack/releaser/go.mod
index d17c092280c4..3e67dbfc13c3 100644
--- a/hack/releaser/go.mod
+++ b/hack/releaser/go.mod
@@ -1,6 +1,6 @@
 module github.com/docker/docs/hack/releaser
 
-go 1.22
+go 1.26.0
 
 require (
 	github.com/alecthomas/kong v1.4.0
diff --git a/hack/releaser/s3-config.json b/hack/releaser/s3-config.json
deleted file mode 100644
index 1040162edffc..000000000000
--- a/hack/releaser/s3-config.json
+++ /dev/null
@@ -1,9 +0,0 @@
-{
-  "ErrorDocument": {
-    "Key": "404.html"
-  },
-  "IndexDocument": {
-    "Suffix": "index.html"
-  },
-  "RedirectAllRequestsTo": null
-}
diff --git a/hack/sbx-release-notes.py b/hack/sbx-release-notes.py
new file mode 100755
index 000000000000..90f47218c3fa
--- /dev/null
+++ b/hack/sbx-release-notes.py
@@ -0,0 +1,211 @@
+#!/usr/bin/env -S uv run --quiet --script
+# /// script
+# requires-python = ">=3.11"
+# dependencies = ["jinja2"]
+# ///
+"""
+Fetch recent stable releases from a GitHub releases page and splice them into
+a docs markdown file between the BEGIN/END markers.
+
+Usage (from repo root):
+
+    ./hack/sbx-release-notes.py
+    ./hack/sbx-release-notes.py --preset dhi
+    GITHUB_TOKEN=$(gh auth token) ./hack/sbx-release-notes.py
+    ./hack/sbx-release-notes.py --minor-releases 3
+"""
+
+from __future__ import annotations
+
+import argparse
+import json
+import os
+import re
+import shutil
+import subprocess
+import sys
+import urllib.request
+from collections import defaultdict
+from pathlib import Path
+
+from jinja2 import Template
+
+PRESETS: dict[str, dict] = {
+    "sbx": {
+        "repo": "docker/sbx-releases",
+        "file": Path("content/manuals/ai/sandboxes/release-notes.md"),
+    },
+    "dhi": {
+        "repo": "docker-hardened-images/dhictl",
+        "file": Path("content/manuals/dhi/release-notes/cli.md"),
+    },
+}
+
+DEFAULT_PRESET = "sbx"
+DEFAULT_MINOR_RELEASES = 3
+
+BEGIN = "<!-- BEGIN GENERATED RELEASES -->"
+END = "<!-- END GENERATED RELEASES -->"
+
+SEMVER = re.compile(r"^v(\d+)\.(\d+)\.(\d+)$")
+
+TEMPLATE = Template(
+    """\
+{% for r in releases -%}
+## {{ r.version }}
+
+{{ '{{<' }} release-date date="{{ r.date }}" {{ '>}}' }}
+
+[GitHub release]({{ r.url }})
+
+{{ r.body }}
+
+{% endfor -%}
+"""
+)
+
+
+def fetch(repo: str) -> list[dict]:
+    url = f"https://api.github.com/repos/{repo}/releases?per_page=100"
+    req = urllib.request.Request(
+        url,
+        headers={
+            "Accept": "application/vnd.github+json",
+            "X-GitHub-Api-Version": "2022-11-28",
+        },
+    )
+    if token := os.environ.get("GITHUB_TOKEN"):
+        req.add_header("Authorization", f"Bearer {token}")
+    with urllib.request.urlopen(req) as resp:
+        return json.load(resp)
+
+
+def parse_stable(raw: list[dict]) -> list[dict]:
+    out = []
+    for r in raw:
+        if r.get("prerelease") or r.get("draft"):
+            continue
+        m = SEMVER.match(r["tag_name"])
+        if not m:
+            continue
+        body = (r.get("body") or "").strip()
+        if not body:
+            continue
+        major, minor, patch = (int(x) for x in m.groups())
+        out.append(
+            {
+                "major": major,
+                "minor": minor,
+                "patch": patch,
+                "version": f"{major}.{minor}.{patch}",
+                "date": r["published_at"][:10],
+                "url": r["html_url"],
+                "body": normalize_body(shift_headings(body)),
+            }
+        )
+    out.sort(key=lambda r: (r["major"], r["minor"], r["patch"]), reverse=True)
+    return out
+
+
+def pick_minor_releases(releases: list[dict], n: int) -> list[dict]:
+    by_minor: dict[tuple[int, int], list[dict]] = defaultdict(list)
+    for r in releases:
+        by_minor[(r["major"], r["minor"])].append(r)
+    latest_keys = sorted(by_minor.keys(), reverse=True)[:n]
+    keep = set(latest_keys)
+    return [r for r in releases if (r["major"], r["minor"]) in keep]
+
+
+def shift_headings(body: str) -> str:
+    """Demote ATX headings by one level so body H2s become H3 under the
+    version's H2. Skips fenced code blocks."""
+    lines = body.splitlines()
+    in_fence = False
+    for i, line in enumerate(lines):
+        stripped = line.lstrip(" \t")
+        if stripped.startswith(("```", "~~~")):
+            in_fence = not in_fence
+            continue
+        if in_fence:
+            continue
+        if stripped.startswith("#"):
+            indent = line[: len(line) - len(stripped)]
+            lines[i] = f"{indent}#{stripped}"
+    return "\n".join(lines)
+
+
+def normalize_body(body: str) -> str:
+    """Fix Markdown lint issues in release body content:
+    - Ensure a blank line follows each heading (MD022).
+    - Add 'console' language tag to fenced code blocks that have none (MD040).
+    Safe to run on content that already complies — no double blank lines are added."""
+    lines = body.splitlines()
+    result: list[str] = []
+    in_fence = False
+
+    for i, line in enumerate(lines):
+        stripped = line.lstrip(" \t")
+
+        if stripped.startswith(("```", "~~~")):
+            if not in_fence:
+                # Opening fence: add language tag if missing
+                fence_marker = "```" if stripped.startswith("```") else "~~~"
+                lang = stripped[len(fence_marker):].strip()
+                if not lang:
+                    indent = line[: len(line) - len(stripped)]
+                    line = f"{indent}{fence_marker}console"
+            in_fence = not in_fence
+            result.append(line)
+            continue
+
+        result.append(line)
+
+        # Outside fences: insert blank line after a heading if the next line is non-empty
+        if not in_fence and stripped.startswith("#"):
+            next_line = lines[i + 1] if i + 1 < len(lines) else ""
+            if next_line.strip():
+                result.append("")
+
+    return "\n".join(result)
+
+
+def splice(path: Path, generated: str) -> None:
+    src = path.read_text()
+    try:
+        before, rest = src.split(BEGIN, 1)
+        _, after = rest.split(END, 1)
+    except ValueError:
+        sys.exit(f"markers {BEGIN!r} / {END!r} not found in {path}")
+    path.write_text(f"{before}{BEGIN}\n\n{generated}{END}{after}")
+
+
+def main() -> None:
+    p = argparse.ArgumentParser(description=__doc__)
+    p.add_argument(
+        "--preset",
+        choices=list(PRESETS),
+        default=DEFAULT_PRESET,
+        help="Named preset that sets --repo and --file defaults (default: %(default)s)",
+    )
+    p.add_argument("--repo", default=None, help="GitHub repo (owner/name), overrides preset")
+    p.add_argument("--file", type=Path, default=None, help="Target markdown file, overrides preset")
+    p.add_argument("--minor-releases", type=int, default=DEFAULT_MINOR_RELEASES)
+    args = p.parse_args()
+
+    preset = PRESETS[args.preset]
+    repo = args.repo or preset["repo"]
+    file = args.file or preset["file"]
+
+    releases = pick_minor_releases(parse_stable(fetch(repo)), args.minor_releases)
+    if not releases:
+        sys.exit("no stable releases found")
+
+    generated = TEMPLATE.render(releases=releases)
+    splice(file, generated)
+    if shutil.which("npx"):
+        subprocess.run(["npx", "--no-install", "rumdl", "fmt", str(file)], check=False)
+    print(f"Wrote {len(releases)} releases (latest {args.minor_releases} minor releases) to {file}")
+
+
+if __name__ == "__main__":
+    main()
diff --git a/hack/sync-cli-docs.sh b/hack/sync-cli-docs.sh
new file mode 100755
index 000000000000..687ed7236659
--- /dev/null
+++ b/hack/sync-cli-docs.sh
@@ -0,0 +1,38 @@
+#!/bin/bash
+set -euo pipefail
+
+main() {
+    local branch_name="${1:-upstream/master}"
+    local cli_source="${2:-$HOME/src/cli}/.git"
+    local worktree_dir="./internal-update-cli-docs"
+
+    (
+        set -e
+        GIT_DIR="$cli_source"
+        GIT_DIR="$GIT_DIR" git fetch upstream
+        GIT_DIR="$GIT_DIR" git worktree add "$worktree_dir" "$branch_name"
+    ) || return $?
+    trap "GIT_DIR=\"$cli_source\" git worktree remove \"$worktree_dir\" --force 2>/dev/null || true" EXIT
+
+    (set -e; cd "$worktree_dir"; make -f docker.Makefile yamldocs || { printf "::error::Failed to generate YAML docs!\n"; exit 1; }) || return $?
+    cp "$worktree_dir"/docs/yaml/*.yaml ./data/cli/engine/
+
+    if git diff --quiet "./data/cli/engine/*.yaml"; then
+        printf "\e[32m✅ Already up to date\e[0m\n"
+        return 100
+    fi
+
+    echo -e "ℹ️ Changes detected:"
+    git diff --stat "./data/cli/engine/*.yaml" || true
+
+    NICE_GIT_REF=$(cd "$worktree_dir" && git describe --always --dirty) || return $?
+
+    git add "./data/cli/engine/*.yaml"
+
+    git commit -m "cli: sync docs with docker/cli $NICE_GIT_REF"
+    
+    printf "\e[32m✅ Committed changes\e[0m\n"
+    return 0
+}
+
+main "$@"
diff --git a/hack/sync-governance-api.sh b/hack/sync-governance-api.sh
new file mode 100755
index 000000000000..601696737ce0
--- /dev/null
+++ b/hack/sync-governance-api.sh
@@ -0,0 +1,55 @@
+#!/bin/bash
+# Re-vendor the AI Governance OpenAPI spec from docker/governor-services.
+#
+# The spec at content/reference/api/ai-governance/api.yaml is a verbatim copy
+# of the upstream openapi.yaml — no transformation is applied. This script
+# fetches the latest version and overwrites the local copy, then prints a diff
+# summary so you can sanity-check before committing.
+#
+# Requires: gh (authenticated with access to the private docker/governor-services
+# repo). No secrets are stored in this repo — auth comes from your own gh login.
+#
+# Usage: hack/sync-governance-api.sh [ref]
+#   ref   optional git ref (branch, tag, or SHA). Defaults to the repo default branch.
+set -euo pipefail
+
+REPO="docker/governor-services"
+SRC_PATH="governor-service-api/openapi.yaml"
+DEST="content/reference/api/ai-governance/api.yaml"
+REF="${1:-}"
+
+# Resolve this repo's root so the script works from any working directory.
+ROOT="$(git -C "$(dirname "$0")" rev-parse --show-toplevel)"
+DEST_ABS="$ROOT/$DEST"
+
+if ! command -v gh >/dev/null 2>&1; then
+  echo "error: gh CLI not found. Install it and run 'gh auth login'." >&2
+  exit 1
+fi
+
+api_path="repos/$REPO/contents/$SRC_PATH"
+[ -n "$REF" ] && api_path="$api_path?ref=$REF"
+
+echo "Fetching $SRC_PATH from $REPO${REF:+@$REF}..."
+tmp="$(mktemp)"
+trap 'rm -f "$tmp"' EXIT
+
+if ! gh api "$api_path" --jq '.content' | base64 -d > "$tmp"; then
+  echo "error: failed to fetch spec. Check 'gh auth status' and repo access." >&2
+  exit 1
+fi
+
+if [ ! -s "$tmp" ]; then
+  echo "error: fetched spec is empty — aborting without overwriting $DEST." >&2
+  exit 1
+fi
+
+if diff -q "$DEST_ABS" "$tmp" >/dev/null 2>&1; then
+  echo "Already up to date — $DEST is identical to upstream."
+  exit 0
+fi
+
+cp "$tmp" "$DEST_ABS"
+echo "Updated $DEST. Review the change:"
+echo
+git -C "$ROOT" --no-pager diff --stat -- "$DEST"
diff --git a/hack/validate-whats-new.mjs b/hack/validate-whats-new.mjs
new file mode 100644
index 000000000000..e4e7e0548150
--- /dev/null
+++ b/hack/validate-whats-new.mjs
@@ -0,0 +1,92 @@
+#!/usr/bin/env node
+
+import fs from "node:fs";
+
+const [path, expectedStart, expectedEnd] = process.argv.slice(2);
+if (!expectedEnd) {
+  throw new Error(`usage: ${process.argv[1]} FILE START END`);
+}
+
+const data = JSON.parse(fs.readFileSync(path, "utf8"));
+const requiredItemKeys = [
+  "product",
+  "title",
+  "description",
+  "url",
+  "published",
+  "source_prs",
+  "featured",
+];
+
+if (data.period_start !== expectedStart) {
+  throw new Error(`period_start must be ${expectedStart}`);
+}
+if (data.period_end !== expectedEnd) {
+  throw new Error(`period_end must be ${expectedEnd}`);
+}
+if (!Array.isArray(data.items)) {
+  throw new Error("items must be an array");
+}
+for (const [index, item] of data.items.entries()) {
+  const missing = requiredItemKeys.filter((key) => !(key in item));
+  if (missing.length > 0) {
+    throw new Error(`item ${index + 1} is missing: ${missing.join(", ")}`);
+  }
+
+  for (const key of requiredItemKeys.slice(0, 4)) {
+    if (typeof item[key] !== "string" || item[key].trim() === "") {
+      throw new Error(`item ${index + 1} has an empty ${key}`);
+    }
+  }
+
+  if (!item.url.startsWith("/") || item.url.startsWith("/manuals/")) {
+    throw new Error(`item ${index + 1} url must be an internal published URL`);
+  }
+  if (
+    typeof item.published !== "string" ||
+    !/^\d{4}-\d{2}-\d{2}$/.test(item.published) ||
+    new Date(`${item.published}T00:00:00Z`).toISOString().slice(0, 10) !==
+      item.published
+  ) {
+    throw new Error(`item ${index + 1} has an invalid published date`);
+  }
+  if (item.published < data.period_start || item.published > data.period_end) {
+    throw new Error(`item ${index + 1} published date is outside the period`);
+  }
+  if (
+    !Array.isArray(item.source_prs) ||
+    item.source_prs.length === 0 ||
+    !item.source_prs.every((number) => Number.isInteger(number) && number > 0)
+  ) {
+    throw new Error(
+      `item ${index + 1} source_prs must contain pull request numbers`,
+    );
+  }
+  if (typeof item.featured !== "boolean") {
+    throw new Error(`item ${index + 1} featured must be a boolean`);
+  }
+}
+
+const featuredCount = data.items.filter((item) => item.featured).length;
+const expectedFeaturedCount = Math.min(5, data.items.length);
+if (featuredCount !== expectedFeaturedCount) {
+  throw new Error(
+    `items must contain ${expectedFeaturedCount} featured highlights`,
+  );
+}
+
+const publishedDates = data.items.map((item) => item.published);
+const sortedDates = [...publishedDates].sort().reverse();
+if (publishedDates.join() !== sortedDates.join()) {
+  throw new Error("items must be sorted by published date, newest first");
+}
+
+const titles = data.items.map((item) => item.title);
+if (new Set(titles).size !== titles.length) {
+  throw new Error("items must not contain duplicate titles");
+}
+
+const urls = data.items.map((item) => item.url);
+if (new Set(urls).size !== urls.length) {
+  throw new Error("items must not contain duplicate URLs");
+}
diff --git a/hugo.yaml b/hugo.yaml
index 3250af12955a..a06c3843402f 100644
--- a/hugo.yaml
+++ b/hugo.yaml
@@ -8,16 +8,55 @@ disableHugoGeneratorInject: true
 ignoreLogs:
   - cascade-pattern-with-extension
 
-taxonomies:
-  tag: tags
-  language: languages
+taxonomies: {}
+
+security:
+  exec:
+    allow:
+    - ^(dart-)?sass$
+    - ^go$
+    - ^git$
+    - ^node$
+    - ^postcss$
+    - ^tailwindcss$
+
+# Cascade layout and type settings to content subtrees.
+# See https://gohugo.io/configuration/cascade/#target
+cascade:
+  # Sample pages use the samples type (routes to layouts/samples/)
+  - target:
+      path: /reference/samples/**
+      kind: page
+    type: samples
+  # CLI reference pages use the cli layout (data-driven from YAML)
+  - target:
+      path: /reference/cli/docker
+    layout: cli
+  - target:
+      path: /reference/cli/docker/**
+    layout: cli
+  # sbx CLI reference pages use the sbx-cli layout (cobra/doc YAML)
+  - target:
+      path: /reference/cli/sbx
+    layout: sbx-cli
+  - target:
+      path: /reference/cli/sbx/**
+    layout: sbx-cli
+  # Docker Agent section indexes are mounted navigation stubs; skip
+  # rendering them so they don't produce empty pages (same pattern as
+  # gordon/concepts and other render:never section indexes)
+  - target:
+      path: /manuals/ai/docker-agent/**
+      kind: section
+    build:
+      render: never
 
 # Remove the /manuals prefix for content in the manuals section
 permalinks:
   page:
-    manuals: /:sections[1:]/:slugorfilename/
+    manuals: /:sections[1:]/:slugorcontentbasename/
   section:
-    manuals: /:sections[1:]/:slugorfilename/
+    manuals: /:sections[1:]/
 
 markup:
   tableOfContents:
@@ -46,8 +85,8 @@ build:
     disableTags: true
   # Ensure that CSS/assets changes trigger a dev server rebuild
   cachebusters:
-    - source: assets/watching/hugo_stats\.json
-      target: styles\.css
+    - source: assets/notwatching/hugo_stats\.json
+      target: css
     - source: (postcss|tailwind)\.config\.js
       target: css
     - source: assets/.*\.js
@@ -69,22 +108,15 @@ outputFormats:
     isPlainText: true
     mediaType: "application/json"
     notAlternative: true
-  # robots.txt, see: layouts/index.robots.json
-  robots:
-    baseName: robots
+  # llms.txt
+  llms:
+    baseName: llms
     isPlainText: true
     mediaType: "text/plain"
     notAlternative: true
-  # Markdown for LLMs, see layouts/_default/single.markdown.md
-  Markdown:
-    baseName: index
-    mediaType: "text/markdown"
-    isPlainText: true
-    isHTML: false
     permalinkable: false
-  # llms.txt
-  llms:
-    baseName: llms
+  llmsfull:
+    baseName: llms-full
     isPlainText: true
     mediaType: "text/plain"
     notAlternative: true
@@ -95,27 +127,27 @@ outputFormats:
 outputs:
   home:
     - html
+    - markdown
     - redirects
     - metadata
     - robots
     - llms
+    - llmsfull
   page:
     - html
-    - Markdown
+    - markdown
   section:
     - html
-    - Markdown
+    - markdown
 
 languages:
   en:
-    languageName: English
+    label: English
 
 # Site-wide parameters
 # Can be accessed in content with {{% param "param_name" %}}
 # Or in layouts/partials with site.Params.param_name
 params:
-  kapa:
-    id: ba5c2cbc-6535-4334-a72e-050f7a681c8a
   analytics:
     hotjar:
       prod: 3169877
@@ -123,6 +155,14 @@ params:
     google: GTM-WL2QLG5
     onetrust: 65425fb0-7b36-4317-9f10-7b3e08039af0
     vwo: 723167
+    marlin:
+      # Public-write API keys for the Marlin analytics SDK.
+      apiKey:
+        prod: mrl_2nuEKUo5bzRv8GcDKeYjij4J4U--OLdN
+        stage: mrl_W14SGEQ7nYmBsAyjZPyOM-nlgE53E-vX
+      endpoint:
+        prod: https://marlin-2.docker.com
+        stage: https://marlin-2-stage.docker.com
 
   # Docs repository URL
   repo: https://github.com/docker/docs
@@ -133,37 +173,50 @@ params:
   # Use `grep` to figure out how they might be used.
 
   # Latest version of the Docker Engine API
-  latest_engine_api_version: "1.49"
+  latest_engine_api_version: "1.55"
   # Latest version of Docker Engine
-  docker_ce_version: "28.1.1"
+  docker_ce_version: "29.7.2"
   # Previous version of the Docker Engine
   # (Used to show e.g., "latest" and "latest"-1 in engine install examples
-  docker_ce_version_prev: "28.1.0"
+  docker_ce_version_prev: "29.7.1"
   # Latest Docker Compose version
-  compose_version: "v2.35.1"
+  compose_version: "v5.5.0"
   # Latest BuildKit version
-  buildkit_version: "0.21.0"
+  buildkit_version: "0.32.0"
+  # Latest actions version
+  bake_action_version: "v7"
+  build_push_action_version: "v7"
+  login_action_version: "v4"
+  metadata_action_version: "v6"
+  setup_buildx_action_version: "v4"
+  setup_compose_action_version: "v2"
+  setup_docker_action_version: "v5"
+  setup_qemu_action_version: "v4"
+  github_builder_version: "v1"
+  # Generic actions
+  checkout_action_version: "v6"
+  cache_action_version: "v5"
 
   # Example runtime/library/os versions
-  example_go_version: "1.23"
-  example_alpine_version: "3.21"
-  example_node_version: "20"
+  example_go_version: "1.26"
+  example_alpine_version: "3.23"
+  example_node_version: "24"
 
 menus:
   # Site header menu
   main:
-  - name: Get started
-    pageRef: /get-started/
-    weight: 1
-  - name: Guides
-    pageRef: /guides/
-    weight: 2
-  - name: Manuals
-    pageRef: /manuals/
-    weight: 3
-  - name: Reference
-    pageRef: /reference/
-    weight: 4
+    - name: Get started
+      pageRef: /get-started/
+      weight: 1
+    - name: Guides
+      pageRef: /guides/
+      weight: 2
+    - name: Manuals
+      pageRef: /manuals/
+      weight: 3
+    - name: Reference
+      pageRef: /reference/
+      weight: 4
 
   # Footer links
   footer:
@@ -181,7 +234,7 @@ menus:
     - url: https://www.docker.com/products/business
       name: Docker Business
       parent: Product offerings
-    - url: https://www.docker.com/pricing/faq
+    - url: https://www.docker.com/pricing?ref=Docs&refAction=DocsFooter
       name: Pricing FAQs
       parent: Product offerings
     - url: https://www.docker.com/partners/programs
@@ -272,30 +325,31 @@ module:
   proxy: https://proxy.golang.org,direct
   hugoVersion:
     extended: false
-    min: "0.141.0"
+    min: "0.156.0"
   mounts:
     # Mount the assets directory so it doesn't get overwritten
     - source: assets
       target: assets
     # Mount hugo_stats.json to the assets dir to trigger cachebust
-    - source: hugo_stats.json
-      target: assets/watching/hugo_stats.json
+    - disableWatch: true
+      source: hugo_stats.json
+      target: assets/notwatching/hugo_stats.json
     # Mount the icon files to assets so we can access them with resources.Get
-    - source: node_modules/@material-symbols/svg-400/rounded
+    - source: node_modules/heroicons/24/solid
       target: assets/icons
+    # Mount highlight.js theme for Gordon chat syntax highlighting
+    - source: node_modules/highlight.js/styles/github-dark.css
+      target: assets/css/highlight-github-dark.css
 
   imports:
-
-    # Docker Engine
-    - path: github.com/moby/moby
+    # Docker Engine API
+    - path: github.com/moby/moby/api
       mounts:
-        - source: docs/api/v1.24.md
-          target: content/reference/api/engine/version/v1.24.md
-        - source: docs/api/version-history.md
+        - source: docs/CHANGELOG.md
           target: content/reference/api/engine/version-history.md
-        - source: docs/api
+        - source: docs
           target: content/reference/api/engine/version
-          includeFiles: "*.yaml"
+          files: ["*.yaml"]
 
     # BuildKit
     - path: github.com/moby/buildkit
@@ -304,7 +358,7 @@ module:
           target: content/reference/dockerfile.md
         - source: frontend/dockerfile/docs/rules
           target: content/reference/build-checks
-          includeFiles: "*.md"
+          files: ["*.md"]
         - source: docs/buildkitd.toml.md
           target: content/manuals/build/buildkit/toml-configuration.md
         - source: docs/attestations/slsa-definitions.md
@@ -317,16 +371,18 @@ module:
       mounts:
         - source: docs/bake-reference.md
           target: content/manuals/build/bake/reference.md
+        - source: docs/bake-stdlib.md
+          target: content/manuals/build/bake/stdlib.md
 
     # Docker CLI
     - path: github.com/docker/cli
       mounts:
         - source: docs/extend
           target: content/manuals/engine/extend
-          excludeFiles:
-            - "EBS_volume.md"
-            - "plugins_metrics.md"
-            - "plugins_services.md"
+          files:
+            - "! EBS_volume.md"
+            - "! plugins_metrics.md"
+            - "! plugins_services.md"
         - source: docs/deprecated.md
           target: content/manuals/engine/deprecated.md
         - source: docs/reference/run.md
@@ -335,15 +391,41 @@ module:
           target: content/reference/cli/dockerd.md
 
     # Compose
-    - path: github.com/docker/compose/v2
+    - path: github.com/docker/compose/v5
       mounts:
         - source: docs/reference
-          target: data/compose-cli
-          includeFiles: "*.yaml"
+          target: data/cli/compose
+          files: ["*.yaml"]
 
-    # Scout CLI plugin (public dist repo)
-    - path: github.com/docker/scout-cli
+    # Model CLI
+    - path: github.com/docker/model-runner
       mounts:
-        - source: docs
-          target: data/scout-cli
-          includeFiles: "*.yaml"
+        - source: cmd/cli/docs/reference
+          target: data/cli/model
+          files: ["*.yaml"]
+
+    # Docker Agent
+    # Single-sources https://docker.github.io/docker-agent/ content;
+    # bumped on each docker-agent release by sync-docker-agent-docs.yml.
+    # Sections are mounted individually so hugo mod vendor does not
+    # vendor the upstream Jekyll site files that also live in docs/.
+    - path: github.com/docker/docker-agent
+      mounts:
+        - source: docs/getting-started
+          target: content/manuals/ai/docker-agent/getting-started
+        - source: docs/concepts
+          target: content/manuals/ai/docker-agent/concepts
+        - source: docs/configuration
+          target: content/manuals/ai/docker-agent/configuration
+        - source: docs/tools
+          target: content/manuals/ai/docker-agent/tools
+        - source: docs/providers
+          target: content/manuals/ai/docker-agent/providers
+        - source: docs/features
+          target: content/manuals/ai/docker-agent/features
+        - source: docs/guides
+          target: content/manuals/ai/docker-agent/guides
+        - source: docs/community
+          target: content/manuals/ai/docker-agent/community
+        - source: docs/demo.gif
+          target: content/manuals/ai/docker-agent/demo.gif
diff --git a/hugo_stats.json b/hugo_stats.json
deleted file mode 100644
index 0ba8fdcc0a2b..000000000000
--- a/hugo_stats.json
+++ /dev/null
@@ -1,559 +0,0 @@
-{
-  "htmlElements": {
-    "tags": null,
-    "classes": [
-      "!mt-0",
-      "--mount",
-      "--tmpfs",
-      "-mb-3",
-      "-mr-8",
-      "-mt-0.5",
-      "-mt-4",
-      "-mt-8",
-      "-top-16",
-      "-v",
-      "-z-10",
-      ".NET",
-      "AWS-Route-53",
-      "Admin-Console",
-      "After",
-      "Angular",
-      "Apt",
-      "Arch",
-      "Arch-Linux",
-      "Azure-Connect-OIDC",
-      "Azure-DevOps",
-      "Bake",
-      "Bash",
-      "Before",
-      "CLI",
-      "CentOS-RHEL-and-Fedora",
-      "Circle-CI",
-      "Clone-with-git",
-      "Command-Prompt",
-      "Command-Prompt-CLI",
-      "Compliant",
-      "Custom-builder",
-      "Debian",
-      "Debian-GNU/Linux",
-      "Diff",
-      "Docker-Desktop",
-      "Docker-Hub",
-      "Docker-Scout-Dashboard",
-      "Docker-plan",
-      "Download",
-      "Entra-ID",
-      "Entra-ID-SAML-2.0",
-      "External-cloud-storage",
-      "Fedora",
-      "For-Mac-with-Apple-silicon",
-      "For-Mac-with-Intel-chip",
-      "From-the-GUI",
-      "From-the-command-line",
-      "GUI",
-      "Git-Bash",
-      "Git-Bash-CLI",
-      "GitLab",
-      "Go",
-      "GoDaddy",
-      "Google-Cloud-DNS",
-      "HTTP",
-      "Heredocs",
-      "Hyper-V-backend-x86_64",
-      "Inline",
-      "JSON",
-      "Java",
-      "JavaScript",
-      "Jenkins",
-      "Latest",
-      "Legacy-Docker-plan",
-      "Legacy-Docker-plans",
-      "Linux",
-      "Local-or-Hub-storage",
-      "MDM",
-      "MMC",
-      "Mac",
-      "Mac-/-Linux",
-      "Mac-/-Linux-/-Git-Bash",
-      "Mac-/-Linux-CLI",
-      "Mac-and-Linux",
-      "Mac-with-Apple-silicon",
-      "Mac-with-Intel-chip",
-      "Manually-create-assets",
-      "NetworkManager",
-      "Node",
-      "Non-compliant",
-      "Okta",
-      "Okta-SAML",
-      "Old-Dockerfile",
-      "Other-providers",
-      "PHP",
-      "PowerShell",
-      "PowerShell-CLI",
-      "Python",
-      "RHEL-8",
-      "RHEL-9",
-      "RHEL-CentOS-or-Fedora",
-      "Raw",
-      "React",
-      "Regular-install",
-      "Remote-file",
-      "Rootless-mode",
-      "Ruby",
-      "Run-Ollama-in-a-container",
-      "Run-Ollama-outside-of-a-container",
-      "Rust",
-      "Shell-script",
-      "Specific-version",
-      "Svelte",
-      "Ubuntu",
-      "Unix-pipe",
-      "Updated-Dockerfile",
-      "Use-Docker-Init",
-      "Use-OpenAI",
-      "Using-the-CLI",
-      "Using-the-GUI",
-      "VS-Code",
-      "Vue",
-      "WSL-2-backend-Arm-Beta",
-      "WSL-2-backend-x86_64",
-      "Web-browser",
-      "What-are-the-key-features-of-Docker-Desktop",
-      "Whats-included-in-Docker-Desktop",
-      "Windows",
-      "Windows-Command-Prompt",
-      "Windows-Git-Bash",
-      "Windows-PowerShell",
-      "Windows-run-as-admin",
-      "With-packages-RPM/DEB",
-      "With-systemd-Highly-recommended",
-      "Without-packages",
-      "Without-systemd",
-      "[display:none]",
-      "absolute",
-      "aspect-video",
-      "bake-action",
-      "bg-amber-light",
-      "bg-background-light",
-      "bg-black/50",
-      "bg-black/70",
-      "bg-blue-light",
-      "bg-blue-light-400",
-      "bg-blue-light-500",
-      "bg-cover",
-      "bg-gradient-to-br",
-      "bg-gradient-to-r",
-      "bg-gradient-to-t",
-      "bg-gray-light-100",
-      "bg-gray-light-200",
-      "bg-gray-light-400",
-      "bg-gray-light-700",
-      "bg-green-light",
-      "bg-green-light-400",
-      "bg-opacity-75",
-      "bg-pattern-blue",
-      "bg-pattern-purple",
-      "bg-pattern-verde",
-      "bg-red-light",
-      "bg-transparent",
-      "bg-violet-light",
-      "bg-white",
-      "bg-white/10",
-      "block",
-      "border",
-      "border-0",
-      "border-amber-light",
-      "border-b",
-      "border-b-4",
-      "border-blue-light",
-      "border-blue-light-500",
-      "border-divider-light",
-      "border-gray-light-100",
-      "border-gray-light-200",
-      "border-gray-light-400",
-      "border-green-light",
-      "border-green-light-400",
-      "border-l-2",
-      "border-l-4",
-      "border-l-magenta-light",
-      "border-red-light",
-      "border-transparent",
-      "border-violet-light",
-      "border-white",
-      "bottom-0",
-      "build-push-action",
-      "chroma",
-      "col-start-2",
-      "containerd-image-store",
-      "cursor-pointer",
-      "dark:bg-amber-dark",
-      "dark:bg-background-dark",
-      "dark:bg-blue-dark",
-      "dark:bg-blue-dark-400",
-      "dark:bg-gray-dark-100",
-      "dark:bg-gray-dark-200",
-      "dark:bg-gray-dark-300",
-      "dark:bg-gray-dark-400",
-      "dark:bg-green-dark",
-      "dark:bg-green-dark-400",
-      "dark:bg-opacity-75",
-      "dark:bg-red-dark",
-      "dark:bg-violet-dark",
-      "dark:block",
-      "dark:border-amber-dark",
-      "dark:border-b-blue-dark-600",
-      "dark:border-blue-dark",
-      "dark:border-divider-dark",
-      "dark:border-gray-dark-200",
-      "dark:border-gray-dark-400",
-      "dark:border-green-dark",
-      "dark:border-green-dark-400",
-      "dark:border-l-magenta-dark",
-      "dark:border-red-dark",
-      "dark:border-violet-dark",
-      "dark:fill-blue-dark",
-      "dark:focus:ring-blue-dark",
-      "dark:from-background-dark",
-      "dark:from-blue-dark-200",
-      "dark:from-blue-dark-400",
-      "dark:from-gray-dark-100",
-      "dark:hidden",
-      "dark:hover:bg-blue-dark",
-      "dark:hover:bg-blue-dark-500",
-      "dark:hover:bg-gray-dark-200",
-      "dark:hover:bg-gray-dark-400",
-      "dark:hover:bg-gray-dark-500",
-      "dark:hover:text-blue-dark",
-      "dark:prose-invert",
-      "dark:ring-blue-dark-400",
-      "dark:ring-gray-dark-400",
-      "dark:syntax-dark",
-      "dark:text-amber-dark",
-      "dark:text-blue-dark",
-      "dark:text-divider-dark",
-      "dark:text-gray-dark",
-      "dark:text-gray-dark-300",
-      "dark:text-gray-dark-500",
-      "dark:text-gray-dark-600",
-      "dark:text-gray-dark-700",
-      "dark:text-gray-dark-800",
-      "dark:text-green-dark",
-      "dark:text-magenta-dark",
-      "dark:text-red-dark",
-      "dark:text-violet-dark",
-      "dark:text-white",
-      "dark:to-background-dark",
-      "dark:to-blue-dark-100",
-      "dark:to-magenta-dark-400",
-      "docker/bake-action",
-      "docker/build-push-action",
-      "drop-shadow",
-      "drop-shadow-sm",
-      "duration-300",
-      "fill-blue-light",
-      "fixed",
-      "flex",
-      "flex-1",
-      "flex-[2_2_0%]",
-      "flex-col",
-      "flex-col-reverse",
-      "flex-grow",
-      "flex-grow-0",
-      "flex-none",
-      "flex-shrink",
-      "flex-wrap",
-      "focus:ring-blue-light",
-      "font-bold",
-      "font-medium",
-      "font-semibold",
-      "footnote-backref",
-      "footnote-ref",
-      "footnotes",
-      "from-20%",
-      "from-background-light",
-      "from-blue-light-400",
-      "from-blue-light-600",
-      "gap-1",
-      "gap-10",
-      "gap-12",
-      "gap-2",
-      "gap-20",
-      "gap-3",
-      "gap-4",
-      "gap-6",
-      "gap-8",
-      "goat",
-      "grid",
-      "grid-cols-1",
-      "group",
-      "group-hover:block'",
-      "group-open:[display:block]",
-      "group-open:rotate-180",
-      "h-16",
-      "h-2",
-      "h-32",
-      "h-48",
-      "h-6",
-      "h-8",
-      "h-[calc(100vh-64px)]",
-      "h-fit",
-      "h-full",
-      "h-max",
-      "h-screen",
-      "hidden",
-      "hidden'",
-      "highlight",
-      "hover:bg-blue-light-400",
-      "hover:bg-gray-light-100",
-      "hover:bg-gray-light-200",
-      "hover:bg-gray-light-300",
-      "hover:bg-white/20",
-      "hover:border-gray-light-200",
-      "hover:border-white/20",
-      "hover:dark:bg-gray-dark-200",
-      "hover:dark:bg-gray-dark-300",
-      "hover:dark:border-gray-dark",
-      "hover:dark:text-blue-dark",
-      "hover:drop-shadow-lg",
-      "hover:opacity-90",
-      "hover:text-blue-light",
-      "hover:text-white",
-      "hover:underline",
-      "icon-lg",
-      "icon-sm",
-      "icon-svg",
-      "inline",
-      "inline-block",
-      "inline-flex",
-      "inset-0",
-      "invertible",
-      "italic",
-      "items-center",
-      "items-start",
-      "items-stretch",
-      "justify-between",
-      "justify-center",
-      "justify-end",
-      "justify-evenly",
-      "leading-none",
-      "leading-snug",
-      "leading-tight",
-      "left-0",
-      "lg:block",
-      "lg:flex",
-      "lg:flex-row",
-      "lg:gap-4",
-      "lg:gap-8",
-      "lg:grid-cols-2",
-      "lg:grid-cols-3",
-      "lg:grid-cols-4",
-      "lg:hidden",
-      "lg:no-underline",
-      "lg:pb-2",
-      "lg:scale-100",
-      "link",
-      "lntable",
-      "lntd",
-      "m-2",
-      "m-4",
-      "macOS",
-      "max-h-full",
-      "max-w-4xl",
-      "max-w-56",
-      "max-w-[1920px]",
-      "max-w-[840px]",
-      "max-w-fit",
-      "max-w-full",
-      "max-w-none",
-      "max-w-xl",
-      "mb-1",
-      "mb-2",
-      "mb-4",
-      "mb-8",
-      "md-dropdown",
-      "md:block",
-      "md:flex-nowrap",
-      "md:flex-row",
-      "md:grid-cols-2",
-      "md:h-[334px]",
-      "md:h-[calc(100vh-64px)]",
-      "md:hidden",
-      "md:max-w-[66%]",
-      "md:scale-100",
-      "md:sticky",
-      "md:text-base",
-      "md:text-sm",
-      "md:top-16",
-      "md:w-[300px]",
-      "md:z-auto",
-      "min-h-screen",
-      "min-w-0",
-      "min-w-52",
-      "min-w-fit",
-      "ml-2",
-      "ml-3",
-      "ml-4",
-      "ml-auto",
-      "mt-1",
-      "mt-2",
-      "mt-20",
-      "mt-4",
-      "mt-8",
-      "mt-[2px]",
-      "mx-auto",
-      "my-0",
-      "my-1",
-      "my-4",
-      "my-6",
-      "no-underline",
-      "no-wrap",
-      "not-prose",
-      "object-cover",
-      "open-kapa-widget",
-      "openSUSE-and-SLES",
-      "origin-bottom-right",
-      "origin-top-right",
-      "ot-sdk-show-settings",
-      "outline-none",
-      "overflow-clip",
-      "overflow-hidden",
-      "overflow-x-auto",
-      "overflow-x-hidden",
-      "overflow-y-auto",
-      "p-1",
-      "p-2",
-      "p-4",
-      "p-6",
-      "p-8",
-      "p-[2px]",
-      "pb-0",
-      "pb-0.5",
-      "pb-1",
-      "pb-2",
-      "pb-20",
-      "pb-4",
-      "pb-8",
-      "pl-1",
-      "pl-2",
-      "pl-3",
-      "pl-4",
-      "pl-5",
-      "place-items-center",
-      "placeholder:text-white",
-      "pr-2",
-      "prose",
-      "pt-10",
-      "pt-2",
-      "pt-4",
-      "px-1",
-      "px-2",
-      "px-4",
-      "px-6",
-      "py-1",
-      "py-2",
-      "py-20",
-      "py-4",
-      "py-8",
-      "relative",
-      "right-0",
-      "right-3",
-      "right-8",
-      "ring-2",
-      "ring-[1.5px]",
-      "ring-blue-light-400",
-      "ring-gray-light-200",
-      "rotate-45",
-      "rounded",
-      "rounded-[6px]",
-      "rounded-b-lg",
-      "rounded-full",
-      "rounded-sm",
-      "scale-50",
-      "scale-75",
-      "scroll-mt-20",
-      "scroll-mt-36",
-      "select-none",
-      "self-center",
-      "self-start",
-      "shadow",
-      "shadow-lg",
-      "shadow-md",
-      "sm:block",
-      "sm:flex",
-      "sm:flex-row",
-      "sm:hidden",
-      "sm:items-center",
-      "sm:w-full",
-      "space-x-2",
-      "space-y-2",
-      "space-y-4",
-      "sticky",
-      "svg-container",
-      "syntax-light",
-      "systemd-networkd",
-      "text-2xl",
-      "text-amber-light",
-      "text-base",
-      "text-black",
-      "text-blue-light",
-      "text-divider-light",
-      "text-gray-light",
-      "text-gray-light-200",
-      "text-gray-light-300",
-      "text-gray-light-500",
-      "text-gray-light-600",
-      "text-gray-light-800",
-      "text-green-light",
-      "text-left",
-      "text-lg",
-      "text-magenta-light",
-      "text-red-light",
-      "text-sm",
-      "text-violet-light",
-      "text-white",
-      "text-xl",
-      "text-xs",
-      "to-30%",
-      "to-50%",
-      "to-75%",
-      "to-blue-light",
-      "to-magenta-light-400",
-      "to-transparent",
-      "to-white",
-      "toc",
-      "top-0",
-      "top-16",
-      "top-3",
-      "top-6",
-      "top-full",
-      "transition",
-      "transition-colors",
-      "transition-transform",
-      "truncate",
-      "underline-offset-2",
-      "uppercase",
-      "w-2",
-      "w-56",
-      "w-8",
-      "w-[1200px]",
-      "w-[32px]",
-      "w-fit",
-      "w-full",
-      "w-screen",
-      "whitespace-nowrap",
-      "xl:flex-row",
-      "xl:grid-cols-3",
-      "xl:grid-cols-4",
-      "xl:mb-0",
-      "xl:w-[1200px]",
-      "xl:w-[400px]",
-      "youtube-video",
-      "z-10",
-      "z-20",
-      "z-30",
-      "z-40",
-      "z-50"
-    ],
-    "ids": null
-  }
-}
diff --git a/layouts/_default/_markup/render-blockquote.html b/layouts/_default/_markup/render-blockquote.html
deleted file mode 100644
index e82786d5e5f2..000000000000
--- a/layouts/_default/_markup/render-blockquote.html
+++ /dev/null
@@ -1,41 +0,0 @@
-{{- $icons := dict
-  "caution" "dangerous"
-  "important" "report"
-  "note" "info"
-  "tip" "lightbulb"
-  "warning" "warning"
-}}
-{{- $borders := dict
-  "caution" "border-red-light dark:border-red-dark"
-  "important" "border-violet-light dark:border-violet-dark"
-  "note" "border-blue-light dark:border-blue-dark"
-  "tip" "border-green-light dark:border-green-dark"
-  "warning" "border-amber-light dark:border-amber-dark"
-}}
-{{- $textColors := dict
-  "caution" "text-red-light dark:text-red-dark"
-  "important" "text-violet-light dark:text-violet-dark"
-  "note" "text-blue-light dark:text-blue-dark"
-  "tip" "text-green-light dark:text-green-dark"
-  "warning" "text-amber-light dark:text-amber-dark"
-}}
-
-{{ if eq .Type "alert" }}
-  <blockquote
-    {{ with .Attributes.id }}id="{{ . }}"{{ end }}
-    class="px-4 border-l-4 {{ index $borders .AlertType }}">
-    <p class="flex gap-2 items-center {{ index $textColors .AlertType }}">
-      <span class="icon-svg pb-1">{{ $i := index $icons .AlertType }}
-        {{ partialCached "icon.html" $i $i }}
-      </span>
-      <strong>{{ i18n .AlertType }}</strong>
-    </p>
-    {{ .Text | safeHTML }}
-  </blockquote>
-{{ else }}
-<blockquote
-  {{ with .Attributes.id }}id="{{ . }}"{{ end }}
-  class="px-4 border-l-4 text-gray-light dark:text-gray-dark">
-    {{ .Text | safeHTML }}
-  </blockquote>
-{{ end }}
diff --git a/layouts/_default/_markup/render-codeblock.html b/layouts/_default/_markup/render-codeblock.html
deleted file mode 100644
index ce6e243cb48e..000000000000
--- a/layouts/_default/_markup/render-codeblock.html
+++ /dev/null
@@ -1,41 +0,0 @@
-<div data-pagefind-ignore class="scroll-mt-20" x-data x-ref="root">
-  {{ with .Attributes.title }}
-  <div class="text-sm -mb-3 text-gray-light dark:text-gray-dark">{{ . }}</div>
-  {{ end }}
-  <div class="group relative">
-    <button x-data="{ code: '{{encoding.Base64Encode .Inner}}', copying: false }"
-      class="absolute right-3 top-3 z-10 text-gray-light-300 dark:text-gray-dark-600" title="copy" @click="window.navigator.clipboard.writeText(atob(code).replaceAll(/^[\$>]\s+/gm, ''));
-      copying = true;
-      setTimeout(() => copying = false, 2000);">
-      <span :class="{ 'group-hover:block' : !copying }" class="icon-svg hidden">{{ partialCached "icon" "content_copy" "content_copy" }}</span>
-      <span :class="{ 'group-hover:block' : copying }" class="icon-svg hidden">{{ partialCached "icon" "check_circle" "check_circle" }}</span>
-    </button>
-    {{ $lang := .Type | default "text" }} {{ $result := transform.Highlight .Inner
-    $lang .Options }}
-    <div class="syntax-light dark:syntax-dark">
-      {{ with .Attributes.collapse }}
-      <div x-data="{ collapse: true }" class="relative overflow-clip"
-        x-init="$watch('collapse', value => $refs.root.scrollIntoView({ behavior: 'smooth'}))">
-        <div x-show="collapse"
-          class="to-transparent absolute z-10 flex h-32 w-full flex-col-reverse items-center overflow-clip bg-gradient-to-t from-background-light to-75% bg-cover pb-4 dark:from-background-dark">
-          <button @click="collapse = false"
-            class="flex items-center rounded-full bg-blue-light px-2 text-sm text-white dark:bg-blue-dark-400">
-            <span>Show more</span>
-            <span class="icon-svg">{{ partialCached "icon" "arrow_drop_down" "arrow_drop_down" }}</span>
-          </button>
-        </div>
-        <div :class="{ 'h-32': collapse }">
-          {{ $result }}
-          <button @click="collapse = true" x-show="!collapse"
-            class="mx-auto -mt-4 flex items-center rounded-b-lg bg-blue-light px-2 text-sm text-white dark:bg-blue-dark-400">
-            <span>Hide</span>
-            <span class="icon-svg">{{ partialCached "icon" "arrow_drop_up" "arrow_drop_up" }}</span>
-          </button>
-        </div>
-      </div>
-      {{ else }}
-        {{ $result }}
-      {{ end }}
-    </div>
-  </div>
-</div>
diff --git a/layouts/_default/_markup/render-image.html b/layouts/_default/_markup/render-image.html
deleted file mode 100644
index 7fd16e10d12c..000000000000
--- a/layouts/_default/_markup/render-image.html
+++ /dev/null
@@ -1,53 +0,0 @@
-{{- $u := urls.Parse .Destination -}}
-{{- $src := $u.String -}}
-{{ if not (or $u.IsAbs (strings.HasPrefix $u.String "/")) }}
-  {{ $base := urls.Parse .Page.Permalink }}
-  {{ if strings.HasSuffix .Page.File.BaseFileName "index" }}
-    {{ $src = $base.JoinPath $u.Path -}}
-  {{ else }}
-    {{ $src = $base.JoinPath "../" $u.Path -}}
-  {{ end }}
-{{ end }}
-
-{{ $params := $u.Query }}
-{{ $width := $params.Get "w" }}
-{{ $height := $params.Get "h" }}
-{{ $border := $params.Has "border" }}
-
-<figure
-  x-data="{ zoom: false }"
-  @click="zoom = ! zoom"
-  class="cursor-pointer hover:opacity-90"
->
-  <img
-    loading="lazy"
-    src="{{ $src }}"
-    alt="{{ .Text }}"
-    {{ with $width }} width="{{ . }}" {{ end }}
-    {{ with $height }} height="{{ . }}" {{ end }}
-    class="rounded mx-auto{{ with $border }} border border-divider-light dark:border-divider-dark{{end}}"
-  />
-  {{ with .Title }}
-    <figcaption class="text-gray-light dark:text-gray-dark">{{ . }}</figcaption>
-  {{ end }}
-  <template x-teleport="body">
-    <div
-      x-show="zoom"
-      @click="zoom = false"
-      x-transition.opacity.duration.250ms
-      class="fixed z-20 inset-0 flex items-center justify-center bg-black/70 p-6"
-    >
-      <button
-        class="text-white fixed z-30 top-6 right-8 icon-svg"
-      >
-        {{ partialCached "icon" "close" "close" }}
-      </button>
-      <img
-        loading="lazy"
-        class="rounded max-w-full max-h-full"
-        src="{{ $src }}"
-        alt="{{ .Text }}"
-      />
-    </div>
-  </template>
-</figure>
diff --git a/layouts/_default/_markup/render-link.html b/layouts/_default/_markup/render-link.html
deleted file mode 100644
index ce4701398413..000000000000
--- a/layouts/_default/_markup/render-link.html
+++ /dev/null
@@ -1,21 +0,0 @@
-{{ $url := .Destination }}
-{{- if (strings.HasPrefix $url "http") -}}
-  {{/* external link, add icon */}}
-  <a
-    class="link"
-    href="{{ $url | safeURL }}"
-    rel="noopener">
-      {{- .Text | safeHTML -}}
-      <span class="pl-1 icon-svg icon-sm">
-        {{- partialCached "icon" "open_in_new" "open_in_new" -}}
-      </span></a>
-{{- else if (strings.HasPrefix $url "/") -}}
-  {{ if (strings.HasSuffix (urls.Parse $url).Path ".md") }}
-    {{/* abs path to markdown file, use ref */}}
-    {{ $url = (ref page $url) }}
-  {{ end }}
-  <a class="link" href="{{ $url }}">{{ .Text | safeHTML }}</a>
-{{- else -}}
-  {{/* relative link, use ref */}}
-  <a class="link" href="{{ ref page $url }}">{{ .Text | safeHTML }}</a>
-{{- end -}}
diff --git a/layouts/_default/api-baseof.html b/layouts/_default/api-baseof.html
deleted file mode 100644
index a629f15c6bb4..000000000000
--- a/layouts/_default/api-baseof.html
+++ /dev/null
@@ -1,57 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-
-<head>
-  <title>{{ .Title }}</title>
-  <!-- needed for adaptive design -->
-  <meta name="viewport" content="width=device-width, initial-scale=1" />
-  <meta name="description" content="{{ .Description }}" />
-  <meta charset="utf-8" />
-  <!-- favicon -->
-  {{- partialCached "favicon.html" "favicon" }}
-  <style>
-    body {
-      margin: 0;
-      padding: 0;
-    }
-
-    .menu-content>div:first-child {
-      background-color: #086dd7;
-      padding: 16px;
-    }
-
-    .auth-tag,.pat,.oat {
-      border-radius: 4px;
-      color: #fff;
-      padding: 5px; 
-    }
-    
-    .pat {
-      background-color: rgb(149, 80, 124);
-    }
-
-    .pat::after {
-      content: "personal access token";
-    }
-
-    .oat::after {
-      content: "org access token";
-    }
-    
-    .oat {
-      background-color: rgb(24, 111, 175); 
-    }
-
-    .auth-tag:not(:last-child) {
-      margin-right: 5px;
-    }
-  </style>
-</head>
-
-<body>
-  {{ $specURL := urls.Parse (printf "/%s%s.yaml" .File.Dir .File.ContentBaseName) }}
-  <redoc spec-url="{{ $specURL.String }}" hide-hostname="true" suppress-warnings="true" lazy-rendering></redoc>
-  <script src="https://cdn.redoc.ly/redoc/latest/bundles/redoc.standalone.js"></script>
-</body>
-
-</html>
diff --git a/layouts/_default/baseof.html b/layouts/_default/baseof.html
deleted file mode 100644
index fd991c9923ea..000000000000
--- a/layouts/_default/baseof.html
+++ /dev/null
@@ -1,64 +0,0 @@
-<!doctype html>
-<html lang="en">
-
-<head>
-  {{ partial "head.html" . }}
-</head>
-
-<body
-  class="flex flex-col items-center bg-gradient-to-r from-background-light from-20% to-white to-30% text-base dark:from-gray-dark-100 dark:to-background-dark dark:text-white">
-  {{ partial "header.html" . }}
-  <main class="relative flex w-full max-w-[1920px]">
-    <!-- Sidebar -->
-    <div style="scroll-behavior: smooth;" x-data x-init="$nextTick(() => {
-          const container = $el; // The div with overflow
-          const item = document.getElementById('sidebar-current-page')
-          if (item) {
-              const containerTop = container.scrollTop;
-              const containerBottom = containerTop + container.clientHeight;
-
-              const itemTop = item.offsetTop - container.offsetTop;
-              const itemBottom = itemTop + item.offsetHeight;
-
-              // Scroll only if the item is out of view
-              if (itemBottom > containerBottom - 200) {
-                  container.scrollTop = itemTop - (container.clientHeight / 2 - item.offsetHeight / 2);
-              }
-          }
-      })"
-      class="md:h-[calc(100vh-64px)] fixed md:sticky top-0 md:top-16 z-40 hidden h-screen flex-none overflow-y-auto overflow-x-hidden bg-background-light dark:bg-gray-dark-100 w-full md:z-auto md:block md:w-[300px]"
-      :class="{ 'hidden': ! $store.showSidebar }">
-      <!-- Gray backdrop on small screens -->
-      <div class="fixed bg-black/50 md:hidden" x-show="$store.showSidebar" @click="openSidebar = false"
-        x-transition.opacity></div>
-      <div class="z-50 w-full bg-background-light p-4 dark:bg-gray-dark-100 md:block md:w-[300px]">
-        <!-- Collapse button for small screens -->
-        <button class="my-4 md:hidden" @click="$store.showSidebar = false">
-          <span class="icon-svg">{{ partialCached "icon" "arrow_left_alt" "arrow_left_alt" }}</span>
-          Back
-        </button>
-        <!-- Actual Sidebar Content -->
-        {{ block "left" . }}
-          {{ partial "sidebar/mainnav.html" . }}
-          {{ partial "sidebar/sections.html" . }}
-        {{ end }}
-      </div>
-    </div>
-
-    <!-- Main content -->
-    <div {{ if ne .Params.sitemap false }}data-pagefind-body{{- end }}
-      class="w-full min-w-0 bg-white p-8 dark:bg-background-dark">
-      {{ block "main" . }}
-      {{ end }}
-    </div>
-  </main>
-
-  <footer class="w-full">{{ partialCached "footer.html" . }}</footer>
-
-  {{/* Load the YouTube player if the page embeds a YouTube video */}}
-  {{ with .Store.Get "youtube" }}
-  {{ partial "youtube-script.html" . }}
-  {{ end }}
-</body>
-
-</html>
diff --git a/layouts/_default/glossary.html b/layouts/_default/glossary.html
deleted file mode 100644
index cc4da2ee3b51..000000000000
--- a/layouts/_default/glossary.html
+++ /dev/null
@@ -1,39 +0,0 @@
-{{ define "left" }}
-  {{ partial "sidebar/mainnav.html" . }}
-  {{ partial "sidebar/sections.html" . }}
-{{ end }}
-
-{{ define "main" }}
-  {{ partial "breadcrumbs.html" . }}
-  <article class="prose max-w-none dark:prose-invert">
-    {{ with .Title }}
-    <h1 class="scroll-mt-36">{{ . }}</h1>
-    {{ end }}
-    {{ with .Content }}
-      {{ .  }}
-    {{ end }}
-    <table>
-      <thead>
-        <tr>
-          <th>Term</th>
-          <th>Definition</th>
-        </tr>
-      </thead>
-      <tbody>
-        {{ range $term, $definition := site.Data.glossary }}
-          <tr>
-            <td class="not-prose">
-              <a class="-top-16 relative" name="{{ $term | anchorize }}"></a>
-              {{ $term }}
-            </td>
-            <td>{{ $definition | $.RenderString }}</td>
-          </tr>
-        {{ end }}
-      </tbody>
-    </table>
-  </article>
-{{ end }}
-
-{{ define "right" }}
-  {{ partial "aside.html" . }}
-{{ end }}
\ No newline at end of file
diff --git a/layouts/_default/index.llms.txt b/layouts/_default/index.llms.txt
deleted file mode 100644
index 97aa37305a82..000000000000
--- a/layouts/_default/index.llms.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-{{- $pages := .Site.RegularPages -}}
-{{- $sorted := sort $pages "RelPermalink" -}}
-{{- $grouped := $sorted.GroupBy "Section" -}}
-
-# Docker Documentation
-
-{{ range $grouped }}
-## {{ humanize .Key }}
-{{ range .Pages }}
-- [{{ .Title }}]({{ .Permalink }}){{ end }}
-{{ end -}}
diff --git a/layouts/_default/list.html b/layouts/_default/list.html
deleted file mode 100644
index 934a6c213557..000000000000
--- a/layouts/_default/list.html
+++ /dev/null
@@ -1,3 +0,0 @@
-{{ define "main" }}
-  {{ partial "content-default.html" . }}
-{{ end }}
diff --git a/layouts/_default/list.markdown.md b/layouts/_default/list.markdown.md
deleted file mode 100644
index 4dfb7bad83f2..000000000000
--- a/layouts/_default/list.markdown.md
+++ /dev/null
@@ -1,7 +0,0 @@
-{{ .Title }}
-
-{{ .RawContent }}
-
-{{ range .Pages }}
-- [{{ .Title }}](https://docs.docker.com{{ .RelPermalink }})
-{{ end }}
\ No newline at end of file
diff --git a/layouts/_default/search.html b/layouts/_default/search.html
deleted file mode 100644
index f4e70cfe061f..000000000000
--- a/layouts/_default/search.html
+++ /dev/null
@@ -1,185 +0,0 @@
-{{ define "left" }}
-  {{ partial "sidebar/mainnav.html" . }}
-{{ end }}
-
-{{ define "main" }}
-  <article class="prose max-w-none dark:prose-invert">
-    <h1 class="py-4">{{ .Title }}</h1>
-    {{ .Content }}
-    <div class="not-prose">
-      <div class="flex flex-col lg:flex-row justify-between gap-8">
-        <input type="search" id="search-page-input"
-          class="min-w-0 ring-[1.5px] ring-gray-light-200 dark:ring-gray-dark-400 w-full max-w-xl rounded px-4 py-2 outline-none bg-white dark:bg-background-dark focus:ring-blue-light dark:focus:ring-blue-dark"
-          placeholder="Search…" tabindex="0" />
-        <div class="flex min-w-fit flex-col flex-grow items-center">
-          <p>Not finding what you're looking for?</p>
-          <button
-            class="px-2 py-1 font-semibold rounded open-kapa-widget flex w-fit gap-2 items-center hover:bg-gray-light-200 dark:hover:bg-gray-dark-200">
-            <span>Try Ask AI</span>
-            <img height="24px" width="24px" src="{{ (resources.Get "images/ai-stars.svg").Permalink }}"
-              alt="AI sparkles!" />
-          </button>
-        </div>
-      </div>
-      <hr class="border-divider-light dark:border-divider-dark">
-      <div id="search-page-results">
-        <!-- results -->
-      </div>
-    </div>
-  </article>
-  <script type="module">
-    // Global variable to hold the pagefind module
-    let pagefind;
-
-    // Initialize the pagefind module and fire a search if the query parameter exists
-    window.addEventListener("load", async function () {
-      // Hydrate pagefind
-      pagefind = await import("/pagefind/pagefind.js");
-      await pagefind.options({
-        ranking: {
-          termFrequency: 0.2,
-          pageLength: 0.75,
-          termSaturation: 1.4,
-          termSimilarity: 6.0,
-        },
-      });
-
-      // Get the query parameter from the URL
-      const urlParams = new URLSearchParams(window.location.search);
-      const query = urlParams.get("q");
-
-      // If no query parameter is set, return
-      if (!query) {
-        return;
-      }
-
-      const searchInput = document.getElementById("search-page-input");
-
-      // Set the value of the input field to the query parameter
-      searchInput.value = query;
-
-      // Trigger the input event to simulate user typing
-      const event = new Event("input", {
-        bubbles: true,
-        cancelable: true,
-      });
-      // Trigger the input event for the search input
-      searchInput.dispatchEvent(event);
-      searchInput.focus();
-    });
-
-    const searchPageInput = document.querySelector("#search-page-input");
-    const searchPageResults = document.querySelector("#search-page-results");
-
-    // onPageSearch returns 10 results per query
-    async function onPageSearch(e) {
-      pagefind.init();
-      const query = e.target.value;
-
-      // Set the query parameter in the URL
-      const params = new URLSearchParams(document.location.search);
-      params.set("q", query);
-
-      // Default the current page to 1
-      let currentPage = 1;
-
-      // Check if the page parameter exists
-      const page = params.get("page");
-      // Calculate the range start based on the page parameter
-      if (page) {
-        currentPage = parseInt(page);
-      }
-      const rangeStart = (currentPage - 1) * 10;
-      const rangeEnd = rangeStart + 10;
-
-      // Execute the search
-      const search = await pagefind.debouncedSearch(query);
-      // If no search results are found, exit
-      if (search === null) {
-        return;
-      } else {
-        // total number of results
-        const resultsLength = search.results.length;
-        // Get the data for the search results
-        // Slice the results based on the range start + 10
-        const resultsData = await Promise.all(
-          search.results.slice(rangeStart, rangeEnd).map((r) => r.data()),
-        );
-        // If the range does not have any results, display a message
-        if (resultsData.length === 0) {
-          searchPageResults.innerHTML = `<div class="p-4">No results found</div>`;
-          return;
-        }
-        // Add an index to the results, for heap tracking
-        const results = resultsData.map((item, index) => ({
-          ...item,
-          index: index + 1,
-        }));
-
-        // If the query is not empty, display the search results container
-        if (query) {
-          searchPageResults.classList.remove("hidden");
-        } else {
-          searchPageResults.classList.add("hidden");
-        }
-
-        // Generate the search results HTML
-        let resultsHTML = `<div class="text-gray-light dark:text-gray-dark p-2">${resultsLength} results</div>`;
-
-        // Map results to HTML
-        resultsHTML += results
-          .map((item) => {
-            return `<div class="p-4">
-         <div class="flex flex-col">
-           <span class="text-gray-light dark:texty-gray-dark text-sm">${item.meta.breadcrumbs}</span>
-           <a class="link" href="${item.url}" data-query="${query}" data-index="${item.index}">${item.meta.title}</a>
-           <p class="text-black dark:text-white overflow-hidden">…${item.excerpt}…</p>
-         </div>
-       </div>`;
-          })
-          .join("");
-        // If the results length is greater than 10, display links to show more results
-        if (resultsLength > 10) {
-          resultsHTML += `<hr class="border-divider-light dark:border-divider-dark">`
-          resultsHTML += `<ul class="flex flex-wrap gap-1 pt-4 pb-8 justify-center text-sm">`;
-          for (let i = 1; i <= resultsLength / 10; i++) {
-            if (i == currentPage) {
-              resultsHTML += `<li class="text-center text-white">
-                <a href="/search/?q=${query}&page=${i}" class="block h-6 w-6 rounded-sm bg-blue-light dark:bg-blue-dark">${i}</a>
-              </li>`;
-            } else {
-              resultsHTML += `<li class="text-center text-gray-light dark:text-gray-dark">
-                <a href="/search/?q=${query}&page=${i}" class="block h-6 w-6 rounded-sm bg-gray-light-200 dark:bg-gray-dark-200">${i}</a>
-              </li>`;
-            }
-          }
-          resultsHTML += `</ul>`;
-        }
-
-        searchPageResults.innerHTML = resultsHTML;
-      }
-    }
-
-    searchPageInput.addEventListener("input", (e) => onPageSearch(e));
-
-    // Event delegation for tracking link clicks
-    if (window.heap !== undefined) {
-      searchPageResults.addEventListener("click", function (event) {
-        if (event.target.tagName === "A" && event.target.closest(".link")) {
-          const searchQuery = event.target.getAttribute("data-query");
-          const resultIndex = event.target.getAttribute("data-index");
-          const url = new URL(event.target.href);
-          const properties = {
-            docs_search_target_path: url.pathname,
-            docs_search_target_title: event.target.textContent,
-            docs_search_query_text: searchQuery,
-            docs_search_target_index: resultIndex,
-            docs_search_source_path: window.location.pathname,
-            docs_search_source_title: document.title,
-          };
-          heap.track("Docs - Search - Click - Result Link", properties);
-        }
-      });
-    }
-  </script>
-{{ end }}
diff --git a/layouts/_default/series.html b/layouts/_default/series.html
deleted file mode 100644
index 498e05ec29bd..000000000000
--- a/layouts/_default/series.html
+++ /dev/null
@@ -1,16 +0,0 @@
-{{ define "main" }}
-{{ partial "breadcrumbs.html" . }}
-<article class="prose max-w-none dark:prose-invert">
-  <h1 data-pagefind-weight="10" class="scroll-mt-36">{{ .Title }}</h1>
-  <div class="text-lg">{{ .Summary }}</div>
-  {{ partial "components/guide-summary.html" . }}
-  {{ .Content }}
-  {{ partial "heading.html" (dict "text" "Modules" "level" 2) }}
-  {{ range $i, $e := .Pages }}
-    {{ $o := compare.Conditional (eq $i 0) true false }}
-    {{ $t := fmt.Printf "%d. %s" (add $i 1) $e.Title }}
-    {{ $b := fmt.Printf "%s\n\n{{< button url=`%s` text=`%s` >}}" $e.Summary $e.Permalink "Start" }}
-    {{ partial "components/accordion.html" (dict "large" true "open" $o "title" $t "body" $b) }}
-  {{ end }}
-</article>
-{{ end }}
diff --git a/layouts/_default/single.html b/layouts/_default/single.html
deleted file mode 100644
index 934a6c213557..000000000000
--- a/layouts/_default/single.html
+++ /dev/null
@@ -1,3 +0,0 @@
-{{ define "main" }}
-  {{ partial "content-default.html" . }}
-{{ end }}
diff --git a/layouts/_default/single.markdown.md b/layouts/_default/single.markdown.md
deleted file mode 100644
index 91b4052d4e68..000000000000
--- a/layouts/_default/single.markdown.md
+++ /dev/null
@@ -1,3 +0,0 @@
-{{ .Title }}
-
-{{ .RawContent }}
\ No newline at end of file
diff --git a/layouts/_default/wide.html b/layouts/_default/wide.html
deleted file mode 100644
index 1f2613d6009f..000000000000
--- a/layouts/_default/wide.html
+++ /dev/null
@@ -1,11 +0,0 @@
-{{ define "main" }}
-<article class="prose min-w-0 flex-[2_2_0%] max-w-4xl dark:prose-invert">
-    {{ partial "breadcrumbs.html" . }}
-    <h1 data-pagefind-weight="10" class="scroll-mt-36">{{ .Title }}</h1>
-    <div class="block lg:hidden">
-      {{ partialCached "pagemeta.html" . . }}
-      <hr />
-    </div>
-    {{ .Content }}
-  </article>
-{{ end }}
diff --git a/layouts/_markup/render-blockquote.html b/layouts/_markup/render-blockquote.html
new file mode 100644
index 000000000000..3d3a6e60cea6
--- /dev/null
+++ b/layouts/_markup/render-blockquote.html
@@ -0,0 +1,42 @@
+{{- $icons := dict
+  "caution" "warning.svg"
+  "important" "important.svg"
+  "note" "info.svg"
+  "tip" "lightbulb.svg"
+  "warning" "warning.svg"
+}}
+{{- $admonitionClasses := dict
+  "caution" "admonition admonition-danger"
+  "important" "admonition admonition-note"
+  "note" "admonition admonition-note"
+  "tip" "admonition admonition-tip"
+  "warning" "admonition admonition-warning"
+}}
+{{- $type := cond (index $icons .AlertType) .AlertType "note" }}
+{{- $iconFile := index $icons $type }}
+{{- $partial := printf "admonitions/icons/%s" $iconFile }}
+
+  
+{{ if eq .Type "alert" }}
+  <blockquote
+    {{ with .Attributes.id }}id="{{ . }}"{{ end }}
+    class="{{ index $admonitionClasses .AlertType }} admonition not-prose">
+    <div class="admonition-header">
+      <span class="admonition-icon">
+        {{- partialCached $partial . }}
+      </span>
+      <span class="admonition-title">
+        {{ printf "%s%s" (upper (substr $.AlertType 0 1)) (substr $.AlertType 1) }}
+      </span>
+    </div>
+    <div class="admonition-content">
+      {{ .Text | safeHTML }}
+    </div>
+  </blockquote>
+{{ else }}
+<blockquote
+  {{ with .Attributes.id }}id="{{ . }}"{{ end }}
+  class="admonition not-prose">
+  {{ .Text | safeHTML }}
+  </blockquote>
+{{ end }}
diff --git a/layouts/_markup/render-codeblock-mermaid.html b/layouts/_markup/render-codeblock-mermaid.html
new file mode 100644
index 000000000000..25ddaa2bd0b2
--- /dev/null
+++ b/layouts/_markup/render-codeblock-mermaid.html
@@ -0,0 +1,5 @@
+{{- .Page.Store.Set "mermaid" true -}}
+<pre
+  class="mermaid not-prose my-4 flex justify-center bg-transparent"
+  data-pagefind-ignore
+>{{- .Inner -}}</pre>
diff --git a/layouts/_markup/render-codeblock.html b/layouts/_markup/render-codeblock.html
new file mode 100644
index 000000000000..3d1440131b01
--- /dev/null
+++ b/layouts/_markup/render-codeblock.html
@@ -0,0 +1,81 @@
+<div
+  data-pagefind-ignore
+  x-data
+  x-ref="root"
+  class="group mt-2 mb-4 flex w-full scroll-mt-2 flex-col items-start gap-4 rounded bg-gray-50 p-2 outline outline-1 outline-offset-[-1px] outline-gray-200 dark:bg-gray-900 dark:outline-gray-800"
+>
+  {{ with .Attributes.title }}
+    <div class="flex w-full items-center gap-2">
+      <div
+        class="flex items-center gap-2.5 rounded bg-gray-100 px-2 py-0.5 dark:bg-gray-800"
+      >
+        <div class="font-normal text-gray-500 dark:text-gray-200">
+          {{ . }}
+        </div>
+      </div>
+    </div>
+  {{ end }}
+  <div class="relative w-full">
+    {{ $lang := .Type | default "text" }}
+    {{ $result := transform.Highlight .Inner
+      $lang .Options
+    }}
+    <div class="syntax-light dark:syntax-dark not-prose w-full">
+      <button
+        x-data="{ code: '{{ encoding.Base64Encode .Inner }}', copying: false }"
+        class="{{ if .Attributes.title }}
+          -top-10
+        {{ else }}
+          top-1
+        {{ end }} absolute right-2 z-10 text-gray-300 dark:text-gray-500"
+        title="copy"
+        @click="window.navigator.clipboard.writeText(atob(code).replaceAll(/^[\$>]\s+/gm, ''));
+      copying = true;
+      setTimeout(() => copying = false, 2000);"
+      >
+        <span
+          :class="{ 'group-hover:block' : !copying }"
+          class="icon-svg hidden"
+          >{{ partialCached "icon" "document-duplicate" "document-duplicate" }}</span
+        >
+        <span :class="{ 'group-hover:block' : copying }" class="icon-svg hidden"
+          >{{ partialCached "icon" "check-circle" "check-circle" }}</span
+        >
+      </button>
+      {{ with .Attributes.collapse }}
+        <div
+          x-data="{ collapse: true }"
+          class="relative overflow-clip"
+          x-init="$watch('collapse', value => $refs.root.scrollIntoView({ behavior: 'smooth'}))"
+        >
+          <div
+            x-show="collapse"
+            class="absolute z-10 flex h-32 w-full flex-col-reverse items-center overflow-clip pb-4"
+          >
+            <button @click="collapse = false" class="chip">
+              <span>Show more</span>
+              <span class="icon-svg"
+                >{{ partialCached "icon" "chevron-down" "chevron-down" }}</span
+              >
+            </button>
+          </div>
+          <div :class="{ 'h-32': collapse }">
+            {{ $result }}
+            <button
+              @click="collapse = true"
+              x-show="!collapse"
+              class="chip mx-auto mt-4 flex items-center  text-sm"
+            >
+              <span>Hide</span>
+              <span class="icon-svg"
+                >{{ partialCached "icon" "chevron-up" "chevron-up" }}</span
+              >
+            </button>
+          </div>
+        </div>
+      {{ else }}
+        {{ $result }}
+      {{ end }}
+    </div>
+  </div>
+</div>
diff --git a/layouts/_default/_markup/render-heading.html b/layouts/_markup/render-heading.html
similarity index 85%
rename from layouts/_default/_markup/render-heading.html
rename to layouts/_markup/render-heading.html
index a0ecdb452e9b..a1b866c3106e 100644
--- a/layouts/_default/_markup/render-heading.html
+++ b/layouts/_markup/render-heading.html
@@ -3,5 +3,6 @@
   "text" (.Text | safeHTML)
   "id" (.Attributes.id | default .Anchor)
   "class" .Attributes.class
+  "tier" .Attributes.tier
   )
 }}
diff --git a/layouts/_markup/render-image.html b/layouts/_markup/render-image.html
new file mode 100644
index 000000000000..55068b8a907a
--- /dev/null
+++ b/layouts/_markup/render-image.html
@@ -0,0 +1,54 @@
+{{- $u := urls.Parse .Destination -}}
+{{- $src := $u.String -}}
+{{ if not (or $u.IsAbs (strings.HasPrefix $u.String "/")) }}
+  {{ $base := urls.Parse .Page.Permalink }}
+  {{ if strings.HasSuffix .Page.File.BaseFileName "index" }}
+    {{ $src = $base.JoinPath $u.Path -}}
+  {{ else }}
+    {{ $src = $base.JoinPath "../" $u.Path -}}
+  {{ end }}
+{{ end }}
+
+{{ $params := $u.Query }}
+{{ $width := $params.Get "w" }}
+{{ $height := $params.Get "h" }}
+{{ $border := $params.Has "border" }}
+
+
+<figure
+  x-data="{ zoom: false }"
+  @click="zoom = ! zoom"
+  class="cursor-pointer hover:opacity-90"
+>
+  <img
+    loading="lazy"
+    src="{{ $src }}"
+    alt="{{ .Text }}"
+    {{ with $width }}width="{{ . }}"{{ end }}
+    {{ with $height }}height="{{ . }}"{{ end }}
+    class="mx-auto{{ with $border }}
+      border border-divider-light dark:border-divider-dark
+    {{ end }} rounded-sm"
+  />
+  {{ with .Title }}
+    <figcaption class="text-gray-200 dark:text-gray-500">{{ . }}</figcaption>
+  {{ end }}
+  <template x-teleport="body">
+    <div
+      x-show="zoom"
+      @click="zoom = false"
+      x-transition.opacity.duration.250ms
+      class="fixed inset-0 z-20 flex items-center justify-center bg-black/100 p-6"
+    >
+      <button class="icon-svg fixed top-6 right-8 z-30 text-white">
+        {{ partialCached "icon" "x-mark" "x-mark" }}
+      </button>
+      <img
+        loading="lazy"
+        class="max-h-full max-w-full rounded-sm"
+        src="{{ $src }}"
+        alt="{{ .Text }}"
+      />
+    </div>
+  </template>
+</figure>
diff --git a/layouts/_markup/render-link.html b/layouts/_markup/render-link.html
new file mode 100644
index 000000000000..32a87795f1f4
--- /dev/null
+++ b/layouts/_markup/render-link.html
@@ -0,0 +1,13 @@
+{{ $url := .Destination }}
+{{- if (strings.HasPrefix $url "http") -}}
+  <a class="link" href="{{ $url | safeURL }}" rel="noopener">{{ .Text | safeHTML }}</a>
+{{- else if (strings.HasPrefix $url "mailto:") -}}
+  <a class="link" href="{{ $url }}">{{ .Text | safeHTML }}</a>
+{{- else if (strings.HasPrefix $url "/") -}}
+  {{ if (strings.HasSuffix (urls.Parse $url).Path ".md") }}
+    {{ $url = (ref page $url) }}
+  {{ end }}
+  <a class="link" href="{{ $url }}">{{ .Text | safeHTML }}</a>
+{{- else -}}
+  <a class="link" href="{{ ref page $url }}">{{ .Text | safeHTML }}</a>
+{{- end -}}
diff --git a/layouts/_default/_markup/render-table.html b/layouts/_markup/render-table.html
similarity index 85%
rename from layouts/_default/_markup/render-table.html
rename to layouts/_markup/render-table.html
index 1a32125cc1cb..cbd908e0fbce 100644
--- a/layouts/_default/_markup/render-table.html
+++ b/layouts/_markup/render-table.html
@@ -4,12 +4,14 @@
       {{- if $v }}
         {{- printf " %s=%q" $k $v | safeHTMLAttr }}
       {{- end }}
-    {{- end }}>
-    <thead class="bg-gray-light-100 dark:bg-gray-dark-200">
+    {{- end }}
+  >
+    <thead class="bg-gray-100 dark:bg-gray-800">
       {{- range .THead }}
         <tr>
           {{- range . }}
-            <th class="p-2"
+            <th
+              class="p-2"
               {{- with .Alignment }}
                 {{- printf " style=%q" (printf "text-align: %s" .) | safeHTMLAttr }}
               {{- end -}}
@@ -24,7 +26,8 @@
       {{- range .TBody }}
         <tr>
           {{- range . }}
-            <td class="p-2"
+            <td
+              class="p-2"
               {{- with .Alignment }}
                 {{- printf " style=%q" (printf "text-align: %s" .) | safeHTMLAttr }}
               {{- end -}}
diff --git a/layouts/_partials/admonitions/icons/important.svg b/layouts/_partials/admonitions/icons/important.svg
new file mode 100644
index 000000000000..80386b920d6c
--- /dev/null
+++ b/layouts/_partials/admonitions/icons/important.svg
@@ -0,0 +1,3 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path d="M12 8V12M12 16H12.01M7.8 21H16.2C17.8802 21 18.7202 21 19.362 20.673C19.9265 20.3854 20.3854 19.9265 20.673 19.362C21 18.7202 21 17.8802 21 16.2V7.8C21 6.11984 21 5.27976 20.673 4.63803C20.3854 4.07354 19.9265 3.6146 19.362 3.32698C18.7202 3 17.8802 3 16.2 3H7.8C6.11984 3 5.27976 3 4.63803 3.32698C4.07354 3.6146 3.6146 4.07354 3.32698 4.63803C3 5.27976 3 6.11984 3 7.8V16.2C3 17.8802 3 18.7202 3.32698 19.362C3.6146 19.9265 4.07354 20.3854 4.63803 20.673C5.27976 21 6.11984 21 7.8 21Z" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
diff --git a/layouts/_partials/admonitions/icons/info.svg b/layouts/_partials/admonitions/icons/info.svg
new file mode 100644
index 000000000000..a9f314887a9e
--- /dev/null
+++ b/layouts/_partials/admonitions/icons/info.svg
@@ -0,0 +1,3 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path d="M12 16V12M12 8H12.01M22 12C22 17.5228 17.5228 22 12 22C6.47715 22 2 17.5228 2 12C2 6.47715 6.47715 2 12 2C17.5228 2 22 6.47715 22 12Z" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
diff --git a/layouts/_partials/admonitions/icons/lightbulb.svg b/layouts/_partials/admonitions/icons/lightbulb.svg
new file mode 100644
index 000000000000..cd5d889d55f6
--- /dev/null
+++ b/layouts/_partials/admonitions/icons/lightbulb.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0_5432_1749" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="4" y="1" width="17" height="22">
+<path d="M9.93896 22H14.939M10.439 10H14.439M12.439 10L12.439 16M15.439 15.3264C17.8039 14.2029 19.439 11.7924 19.439 9C19.439 5.13401 16.305 2 12.439 2C8.57297 2 5.43896 5.13401 5.43896 9C5.43896 11.7924 7.07402 14.2029 9.43896 15.3264V16C9.43896 16.9319 9.43896 17.3978 9.59121 17.7654C9.79419 18.2554 10.1835 18.6448 10.6736 18.8478C11.0411 19 11.5071 19 12.439 19C13.3708 19 13.8368 19 14.2043 18.8478C14.6944 18.6448 15.0837 18.2554 15.2867 17.7654C15.439 17.3978 15.439 16.9319 15.439 16V15.3264Z" stroke="#6C7E9D" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
+</mask>
+<g mask="url(#mask0_5432_1749)">
+<rect width="24" height="24" fill="currentColor" fill-opacity="0.8"/>
+</g>
+</svg>
diff --git a/layouts/_partials/admonitions/icons/warning.svg b/layouts/_partials/admonitions/icons/warning.svg
new file mode 100644
index 000000000000..75e4bf71b7ee
--- /dev/null
+++ b/layouts/_partials/admonitions/icons/warning.svg
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0_5432_2018" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="0" y="2" width="24" height="21">
+<path d="M11.9998 9.99999V14M11.9998 18H12.0098M10.6151 4.89171L2.39019 19.0983C1.93398 19.8863 1.70588 20.2803 1.73959 20.6037C1.769 20.8857 1.91677 21.142 2.14613 21.3088C2.40908 21.5 2.86435 21.5 3.77487 21.5H20.2246C21.1352 21.5 21.5904 21.5 21.8534 21.3088C22.0827 21.142 22.2305 20.8857 22.2599 20.6037C22.2936 20.2803 22.0655 19.8863 21.6093 19.0983L13.3844 4.89171C12.9299 4.10654 12.7026 3.71396 12.4061 3.58211C12.1474 3.4671 11.8521 3.4671 11.5935 3.58211C11.2969 3.71396 11.0696 4.10655 10.6151 4.89171Z" stroke="#6C7E9D" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
+</mask>
+<g mask="url(#mask0_5432_2018)">
+<rect width="24" height="24" fill="currentColor" fill-opacity="0.8"/>
+</g>
+</svg>
diff --git a/layouts/_partials/api-ref/curl.html b/layouts/_partials/api-ref/curl.html
new file mode 100644
index 000000000000..5baa2107c8d2
--- /dev/null
+++ b/layouts/_partials/api-ref/curl.html
@@ -0,0 +1,139 @@
+{{/* Build a curl command for an OpenAPI operation.
+
+  Input dict:
+  api          — unmarshaled spec root
+  op           — operation object
+  method       — http method (lowercase string)
+  path         — path string (e.g. "/orgs/{org_name}/policies")
+  sharedParams — already-resolved path-level parameters
+
+  Output: a multi-line curl command string (line-continued with " \\\n  ").
+  Path placeholders are filled from parameter examples when available;
+  unresolved path params fall back to `<name>`. Query params without an
+  example are omitted. Bearer-auth schemes contribute an Authorization
+  header with the literal `$TOKEN` placeholder.
+*/}}
+{{- $api := .api -}}
+{{- $op := .op -}}
+{{- $method := .method -}}
+{{- $path := .path -}}
+{{- $sharedParams := .sharedParams -}}
+
+{{/* Combine path-level + operation-level parameters, resolving $refs. */}}
+{{- $params := $sharedParams -}}
+{{- with index $op "parameters" -}}
+  {{- range . -}}
+    {{- $p := partial "api-ref/resolve.html" (dict "api" $api "node" .) -}}
+    {{- $params = $params | append $p -}}
+  {{- end -}}
+{{- end -}}
+
+{{/* Substitute path placeholders. */}}
+{{- $url := $path -}}
+{{- range $params -}}
+  {{- if eq .in "path" -}}
+    {{- $val := printf "<%s>" .name -}}
+    {{- with .example -}}{{- $val = . | string -}}{{- end -}}
+    {{- with .examples -}}
+      {{- $picked := false -}}
+      {{- with index . "default" -}}
+        {{- with .value -}}
+          {{- $val = . | string -}}{{- $picked = true -}}
+        {{- end -}}
+      {{- end -}}
+      {{- if not $picked -}}
+        {{- range . -}}
+          {{- if not $picked -}}
+            {{- with .value -}}
+              {{- $val = . | string -}}{{- $picked = true -}}
+            {{- end -}}
+          {{- end -}}
+        {{- end -}}
+      {{- end -}}
+    {{- end -}}
+    {{- $url = replace $url (printf "{%s}" .name) $val -}}
+  {{- end -}}
+{{- end -}}
+
+{{/* Append query string from query parameters that have examples. */}}
+{{- $qs := slice -}}
+{{- range $params -}}
+  {{- if eq .in "query" -}}
+    {{- $val := "" -}}
+    {{- with .example -}}{{- $val = . | string -}}{{- end -}}
+    {{- with .examples -}}
+      {{- $picked := false -}}
+      {{- with index . "default" -}}
+        {{- with .value -}}
+          {{- $val = . | string -}}{{- $picked = true -}}
+        {{- end -}}
+      {{- end -}}
+      {{- if not $picked -}}
+        {{- range . -}}
+          {{- if not $picked -}}
+            {{- with .value -}}
+              {{- $val = . | string -}}{{- $picked = true -}}
+            {{- end -}}
+          {{- end -}}
+        {{- end -}}
+      {{- end -}}
+    {{- end -}}
+    {{- if $val -}}
+      {{- $qs = $qs | append (printf "%s=%s" .name $val) -}}
+    {{- end -}}
+  {{- end -}}
+{{- end -}}
+{{- if $qs -}}{{- $url = printf "%s?%s" $url (delimit $qs "&") -}}{{- end -}}
+
+{{/* Prepend base URL from the first server entry. */}}
+{{- $base := "" -}}
+{{- with index $api.servers 0 -}}{{- $base = .url -}}{{- end -}}
+{{- $fullURL := printf "%s%s" $base $url -}}
+
+{{- $lines := slice (printf "curl -X %s '%s'" (upper $method) $fullURL) -}}
+
+{{/* Bearer auth header if the spec defines a bearer scheme. */}}
+{{- $hasBearer := false -}}
+{{- with $api.components -}}
+  {{- with .securitySchemes -}}
+    {{- range . -}}
+      {{- if and (eq .type "http") (eq .scheme "bearer") -}}
+        {{- $hasBearer = true -}}
+      {{- end -}}
+    {{- end -}}
+  {{- end -}}
+{{- end -}}
+{{- if $hasBearer -}}
+  {{- $lines = $lines | append "-H 'Authorization: Bearer $TOKEN'" -}}
+{{- end -}}
+
+{{/* Request body example. Picks the first content type declared. */}}
+{{- with $op.requestBody -}}
+  {{- $body := partial "api-ref/resolve.html" (dict "api" $api "node" .) -}}
+  {{- $ct := "" -}}
+  {{- $media := dict -}}
+  {{- range $name, $m := $body.content -}}
+    {{- if not $ct -}}{{- $ct = $name -}}{{- $media = $m -}}{{- end -}}
+  {{- end -}}
+  {{- if $ct -}}
+    {{- $lines = $lines | append (printf "-H 'Content-Type: %s'" $ct) -}}
+    {{- $example := "" -}}
+    {{- with $media.examples -}}
+      {{- with index . "default" -}}
+        {{- with .value -}}{{- $example = . | jsonify -}}{{- end -}}
+      {{- end -}}
+      {{- if not $example -}}
+        {{- range . -}}
+          {{- if not $example -}}
+            {{- with .value -}}{{- $example = . | jsonify -}}{{- end -}}
+          {{- end -}}
+        {{- end -}}
+      {{- end -}}
+    {{- end -}}
+    {{- if $example -}}
+      {{- $lines = $lines | append (printf "-d '%s'" $example) -}}
+    {{- end -}}
+  {{- end -}}
+{{- end -}}
+
+{{- return (delimit $lines " \\\n  ") -}}
diff --git a/layouts/_partials/api-ref/nav.html b/layouts/_partials/api-ref/nav.html
new file mode 100644
index 000000000000..f182e4d8a369
--- /dev/null
+++ b/layouts/_partials/api-ref/nav.html
@@ -0,0 +1,86 @@
+{{/* Right-rail navigation for an OpenAPI reference page.
+
+  Input: the unmarshaled spec root (plain map from transform.Unmarshal).
+
+  Lists Authentication, every tag with its operations (linking to the same
+  anchors the operation cards expose), and the Schemas section heading.
+*/}}
+{{- $api := . -}}
+{{- $paths := $api.paths -}}
+{{- $methods := slice "get" "post" "put" "patch" "delete" -}}
+{{- $methodColors := dict
+  "get"    "text-blue-700 dark:text-blue-300"
+  "post"   "text-green-700 dark:text-green-300"
+  "put"    "text-yellow-700 dark:text-yellow-300"
+  "patch"  "text-yellow-700 dark:text-yellow-300"
+  "delete" "text-red-700 dark:text-red-300"
+-}}
+
+
+<p
+  class="mb-3 text-xs font-semibold tracking-wider text-gray-500 uppercase dark:text-gray-400"
+>
+  On this page
+</p>
+<ul class="space-y-1">
+  {{- with $api.components }}
+    {{- if .securitySchemes }}
+      <li>
+        <a
+          href="#authentication"
+          class="block py-0.5 text-gray-700 hover:text-blue-600 dark:text-gray-300 dark:hover:text-blue-400"
+        >
+          Authentication
+        </a>
+      </li>
+    {{- end }}
+  {{- end }}
+  {{- range $api.tags }}
+    {{- $tagName := .name }}
+    <li class="mt-3">
+      <a
+        href="#tag-{{ $tagName | urlize }}"
+        class="block py-0.5 text-xs font-semibold tracking-wider text-gray-500 uppercase hover:text-blue-600 dark:text-gray-400 dark:hover:text-blue-400"
+      >
+        {{ $tagName | title }}
+      </a>
+      <ul class="mt-1 space-y-0.5">
+        {{- range $path, $item := $paths }}
+          {{- range $methods }}
+            {{- $method := . }}
+            {{- with index $item $method }}
+              {{- $op := . }}
+              {{- if in $op.tags $tagName }}
+                {{- $label := $op.summary | default $op.operationId | default $path }}
+                <li>
+                  <a
+                    href="#operation-{{ $op.operationId }}"
+                    class="flex items-baseline gap-2 py-0.5 text-gray-700 hover:text-blue-600 dark:text-gray-300 dark:hover:text-blue-400"
+                  >
+                    <span
+                      class="{{ index $methodColors $method }} w-12 flex-none font-mono text-[10px] font-bold uppercase"
+                      >{{ upper $method }}</span
+                    >
+                    <span class="min-w-0 truncate">{{ $label }}</span>
+                  </a>
+                </li>
+              {{- end }}
+            {{- end }}
+          {{- end }}
+        {{- end }}
+      </ul>
+    </li>
+  {{- end }}
+  {{- with $api.components }}
+    {{- if .schemas }}
+      <li class="mt-3">
+        <a
+          href="#schemas"
+          class="block py-0.5 text-xs font-semibold tracking-wider text-gray-500 uppercase hover:text-blue-600 dark:text-gray-400 dark:hover:text-blue-400"
+        >
+          Schemas
+        </a>
+      </li>
+    {{- end }}
+  {{- end }}
+</ul>
diff --git a/layouts/_partials/api-ref/resolve.html b/layouts/_partials/api-ref/resolve.html
new file mode 100644
index 000000000000..80c7e25fe7de
--- /dev/null
+++ b/layouts/_partials/api-ref/resolve.html
@@ -0,0 +1,26 @@
+{{/* Resolve a possibly-$ref'd OpenAPI node against the spec root.
+
+  Input dict:
+  api  — the unmarshaled spec root (plain map from transform.Unmarshal)
+  node — the node to resolve; may be a map, slice, primitive, or nil
+
+  Returns:
+  - if node is a map containing a "$ref" key, returns the target node
+  reached by walking the JSON-Pointer fragment (only internal "#/" refs
+  are supported)
+  - otherwise returns node unchanged
+*/}}
+{{- $node := .node -}}
+{{- if reflect.IsMap $node -}}
+  {{- with index $node "$ref" -}}
+    {{- if hasPrefix . "#/" -}}
+      {{- $parts := after 1 (split . "/") -}}
+      {{- $cur := $.api -}}
+      {{- range $parts -}}
+        {{- $cur = index $cur . -}}
+      {{- end -}}
+      {{- $node = $cur -}}
+    {{- end -}}
+  {{- end -}}
+{{- end -}}
+{{- return $node -}}
diff --git a/layouts/_partials/aside.html b/layouts/_partials/aside.html
new file mode 100644
index 000000000000..5ed76e1a20cb
--- /dev/null
+++ b/layouts/_partials/aside.html
@@ -0,0 +1,8 @@
+<aside
+  class="scrollbar-hover sticky top-16 h-[calc(100vh-64px)] min-w-52 space-y-4 overflow-y-auto py-4 w-full"
+>
+  {{ partial "github-links.html" . }}
+  <div id="TableOfContents" class="overflow-x-auto">
+    {{ partialCached "pagemeta.html" . . }}
+  </div>
+</aside>
diff --git a/layouts/_partials/breadcrumbs.html b/layouts/_partials/breadcrumbs.html
new file mode 100644
index 000000000000..7c2ce060db9d
--- /dev/null
+++ b/layouts/_partials/breadcrumbs.html
@@ -0,0 +1,13 @@
+<nav
+  id="breadcrumbs"
+  data-pagefind-ignore
+  class="breadcrumbs mb-4 flex min-w-0 items-center gap-2 text-gray-400 dark:text-gray-300"
+>
+  {{ range .Ancestors.Reverse }}
+    <a href="{{ .Permalink }}" class="link truncate"
+      >{{ markdownify .LinkTitle }}</a
+    >
+    <span>/</span>
+  {{- end }}
+  <span class="truncate">{{ markdownify .LinkTitle }}</span>
+</nav>
diff --git a/layouts/_partials/components/accordion.html b/layouts/_partials/components/accordion.html
new file mode 100644
index 000000000000..3685c9139734
--- /dev/null
+++ b/layouts/_partials/components/accordion.html
@@ -0,0 +1,26 @@
+<div
+  id="{{ urls.Anchorize .title }}"
+  x-data="{ open: {{ .open | default false }} }"
+  class="my-6 rounded-sm border border-gray-200 bg-white py-2 dark:border-gray-700 dark:bg-gray-900"
+>
+  <button
+    class="not-prose flex w-full justify-between px-4 py-2"
+    x-on:click="open = ! open"
+  >
+    <div class="{{ with .large }}text-xl{{ end }} flex items-center gap-2">
+      {{- with .icon }}
+        <span class="icon-svg -mt-1">{{ partialCached "icon" . . }}</span>
+      {{- end }}
+      {{ .title }}
+    </div>
+    <span :class="{ 'hidden' : !open }" class="icon-svg icon-sm"
+      >{{ partialCached "icon" "chevron-up" "chevron-up" }}</span
+    >
+    <span :class="{ 'hidden' : open }" class="icon-svg icon-sm"
+      >{{ partialCached "icon" "chevron-down" "chevron-down" }}</span
+    >
+  </button>
+  <div x-show="open" x-collapse class="px-4">
+    {{ markdownify .body }}
+  </div>
+</div>
diff --git a/layouts/_partials/components/badge.html b/layouts/_partials/components/badge.html
new file mode 100644
index 000000000000..086179e56e62
--- /dev/null
+++ b/layouts/_partials/components/badge.html
@@ -0,0 +1,19 @@
+{{- $colors := (dict
+  "amber" "bg-amber-500 dark:bg-amber-400"
+  "blue" "bg-blue-500 dark:bg-blue-400"
+  "gray" "bg-gray-500 dark:bg-gray-400"
+  "green" "bg-green-500 dark:bg-green-700"
+  "red" "bg-red-500 dark:bg-red-400"
+  "violet" "bg-violet-500 dark:bg-violet-400"
+  )
+-}}
+
+{{- if not (isset $colors .color) -}}
+  {{- errorf "[badge] wrong color name: '%s' - supported values: amber, blue, gray, green, red, violet" .color -}}h
+{{- end -}}
+
+
+<span
+  class="not-prose {{ index $colors .color }} rounded-sm px-1 text-xs text-white"
+  >{{ .content }}
+</span>
diff --git a/layouts/_partials/components/card.html b/layouts/_partials/components/card.html
new file mode 100644
index 000000000000..4e5d499763b6
--- /dev/null
+++ b/layouts/_partials/components/card.html
@@ -0,0 +1,24 @@
+<div class="card">
+  {{ if .link }}
+    <a href="{{ .link }}" class="card-link">
+  {{ end }}
+    <div class="card-header">
+      {{ with .image }}
+        <img class="card-image" src="{{ . }}" alt="">
+      {{ end }}
+      {{ with .icon }}
+      <div class="card-icon">
+        <span class="card-img svg">
+          {{ partialCached "icon" . . }}
+        </span>
+      </div>
+      {{ end }}
+      <h3 class="card-title">{{ markdownify .title }}</h3>
+    </div>
+    <div class="card-content">
+      <p class="card-description">{{ .description | markdownify }}</p>
+    </div>
+  {{ if .link }}
+    </a>
+  {{ end }}
+</div>
diff --git a/layouts/_partials/content-default.html b/layouts/_partials/content-default.html
new file mode 100644
index 000000000000..9d7c32067066
--- /dev/null
+++ b/layouts/_partials/content-default.html
@@ -0,0 +1,26 @@
+{{ partial "breadcrumbs.html" . }}
+<h1 data-pagefind-weight="10">{{ .Title | safeHTML }}</h1>
+{{- if and (eq .Type "guides") .Params.summary }}
+  <p class="mt-0 text-lg text-gray-500 dark:text-gray-400">
+    {{ .Params.summary }}
+  </p>
+{{- end }}
+<div class="hidden lg:block">
+  {{ partialCached "md-dropdown.html" "-" "-" }}
+</div>
+<div class="block lg:hidden">
+  {{ partialCached "pagemeta.html" . . }}
+  <hr />
+</div>
+{{ .Content }}
+{{- if and (eq .Type "guides") (not .IsSection) (ne .CurrentSection .FirstSection) -}}
+  {{- with .PrevInSection -}}
+    <div class="not-prose col-start-2 my-4">
+      <a
+        href="{{ .Permalink }}"
+        class="cursor-pointer rounded-sm bg-blue-500 px-4 py-2 text-white hover:bg-blue-400 dark:bg-blue-800 dark:hover:bg-blue-700"
+        >{{ .Title }} &raquo;</a
+      >
+    </div>
+  {{- end -}}
+{{- end -}}
diff --git a/layouts/_partials/footer.html b/layouts/_partials/footer.html
new file mode 100644
index 000000000000..6ec3a678cfec
--- /dev/null
+++ b/layouts/_partials/footer.html
@@ -0,0 +1,96 @@
+<div
+  class="ml-auto hidden grid-cols-3 gap-6 border-t border-gray-200 bg-gray-100 px-4 pt-6 pb-2 text-gray-600 md:grid dark:border-gray-700 dark:bg-gray-900 dark:text-gray-400 [&_a:hover]:underline [&_a:hover]:underline-offset-4"
+>
+  <div class="flex min-w-20 flex-wrap items-center gap-1">
+    <a href="https://www.linkedin.com/company/docker" aria-label="LinkedIn">
+      <span class="icon-svg">
+        {{ partialCached "icon" "linkedin" "linkedin" }}
+      </span>
+    </a>
+    <a href="https://x.com/docker/" aria-label="Twitter">
+      <span class="icon-svg">
+        {{ partialCached "icon" "twitter" "twitter" }}
+      </span>
+    </a>
+    <a href="https://www.facebook.com/docker.run" aria-label="Facebook">
+      <span class="icon-svg">
+        {{ partialCached "icon" "facebook" "facebook" }}
+      </span>
+    </a>
+    <a href="http://www.youtube.com/user/dockerrun" aria-label="YouTube">
+      <span class="icon-svg">
+        {{ partialCached "icon" "youtube" "youtube" }}
+      </span>
+    </a>
+    <a href="https://www.instagram.com/dockerinc/" aria-label="Instagram">
+      <span class="icon-svg">
+        {{ partialCached "icon" "instagram" "instagram" }}
+      </span>
+    </a>
+  </div>
+  <div class="flex items-center justify-center gap-3">
+    <a
+      href="https://www.docker.com/"
+      class="inline-flex truncate whitespace-normal"
+      >Product offerings</a
+    >
+    <a
+      href="https://www.docker.com/pricing?ref=Docs&refAction=DocsFooter"
+      class="inline-flex truncate whitespace-normal"
+      >Pricing</a
+    >
+    <a
+      href="https://www.docker.com/company/"
+      class="inline-flex truncate whitespace-normal"
+      >About us</a
+    >
+    <a
+      href="{{ "llms.txt" | relURL }}"
+      class="inline-flex truncate whitespace-normal"
+      >llms.txt</a
+    >
+    <a
+      href="{{ "llms-full.txt" | relURL }}"
+      class="inline-flex truncate whitespace-normal"
+      >llms-full.txt</a
+    >
+  </div>
+  <div class="flex items-center justify-end">
+    <button
+      type="button"
+      id="ot-sdk-btn"
+      class="ot-sdk-show-settings whitespace-normal md:truncate"
+    >
+      Cookies Settings
+    </button>
+    <span class="mx-1 text-gray-400">|</span>
+    <a
+      title="Docker Terms of Use"
+      href="https://www.docker.com/legal/docker-terms-use/"
+      class="whitespace-normal md:truncate"
+      >Terms of Use</a
+    >
+    <span class="mx-1 text-gray-400">|</span>
+    <a
+      title="Docker Systems Status Page"
+      href="https://www.dockerstatus.com/"
+      class="whitespace-normal md:truncate"
+      >Status</a
+    >
+    <span class="mx-1 text-gray-400">|</span>
+    <a
+      title="Docker Legal Terms"
+      href="https://www.docker.com/legal"
+      class="whitespace-normal md:truncate"
+      >Legal</a
+    >
+  </div>
+</div>
+<div
+  class="border-t border-gray-200 bg-gray-100 px-4 py-4 text-sm text-gray-400 md:border-none dark:border-gray-700 dark:bg-gray-900 dark:text-gray-600"
+>
+  <span
+    >Copyright © 2013-{{ time.Now.Year }} Docker Inc. All rights reserved.</span
+  >
+</div>
+<a href="{{ "bot-detection/" | relURL }}" hidden>Automated traffic detection</a>
diff --git a/layouts/_partials/github-links.html b/layouts/_partials/github-links.html
new file mode 100644
index 000000000000..c4b2b0319c69
--- /dev/null
+++ b/layouts/_partials/github-links.html
@@ -0,0 +1,25 @@
+{{- /*
+  Adds links for editing the page or requesting changes:
+  - "Edit this page": Only in production, skips files from `_vendor/` (upstream repositories).
+  - "Request changes": Links to a pre-filled issue form.
+*/ -}}
+{{ if hugo.IsProduction }}
+  {{ with .File }}
+  {{ if not (in .Filename "/_vendor/") }}
+<p class="flex items-center gap-1">
+  <span class="icon-svg icon-sm">
+    {{ partialCached "icon" "pencil-square" "pencil-square" }}
+  </span>
+  <a class="link" rel="noopener"
+    href="{{ site.Params.repo }}/edit/main/content/{{ .Path }}">{{- T "editPage" -}}</a>
+</p>
+  {{ end }}
+  {{ end }}
+<p class="flex items-center gap-1">
+  <span class="icon-svg icon-sm">
+    {{ partialCached "icon" "flag" "flag" }}
+  </span>
+  <a class="link" rel="noopener"
+    href="{{ site.Params.repo }}/issues/new?template=doc_issue.yml&location={{ .Permalink }}&labels=status%2Ftriage">{{- T "requestChanges" -}}</a>
+</p>
+{{ end }}
diff --git a/layouts/_partials/gordon-chat.html b/layouts/_partials/gordon-chat.html
new file mode 100644
index 000000000000..ad9740ef90c4
--- /dev/null
+++ b/layouts/_partials/gordon-chat.html
@@ -0,0 +1,753 @@
+<!-- Gordon AI Chat Panel -->
+<script>
+  window.GORDON_BASE_URL = {{ if eq hugo.Environment "production" -}}
+    'https://ai-backend-service.docker.com'
+  {{- else if getenv "HUGO_GORDON_URL" -}}
+    '{{ getenv "HUGO_GORDON_URL" }}'
+  {{- else -}}
+    'https://ai-backend-service-stage.docker.com'
+  {{- end }};
+</script>
+<div
+  x-data="{
+    isLoading: false,
+    error: null,
+    messages: $persist([]).using(sessionStorage).as('gordon-messages'),
+    currentQuestion: '',
+    threadId: $persist(null).using(sessionStorage).as('gordon-threadId'),
+    includePageContext: $persist(true).using(sessionStorage).as('gordon-includePageContext'),
+    maxTurnsPerThread: 10,
+
+    init() {
+      // Clean up any streaming messages that might be persisted
+      this.messages = this.messages.filter(m => !m.isStreaming)
+
+      // Watch for store changes to focus input
+      this.$watch('$store.gordon.isOpen', (isOpen) => {
+        if (isOpen) {
+          this.$nextTick(() => {
+            this.$refs.input?.focus()
+          })
+        }
+      })
+
+      // Watch for query from store and populate input
+      this.$watch('$store.gordon.query', (query) => {
+        if (query) {
+          this.currentQuestion = query
+          const shouldAutoSubmit = this.$store.gordon.autoSubmit
+          this.$nextTick(() => {
+            if (shouldAutoSubmit) {
+              this.askQuestion()
+            } else {
+              this.$refs.input?.focus()
+              this.$refs.input?.select()
+            }
+          })
+          // Clear the store query and autoSubmit flag after using them
+          this.$store.gordon.query = ''
+          this.$store.gordon.autoSubmit = false
+        }
+      })
+    },
+
+    getTurnCount() {
+      return this.messages.filter(m => m.role === 'user').length
+    },
+
+    getRemainingTurns() {
+      return this.maxTurnsPerThread - this.getTurnCount()
+    },
+
+    isThreadLimitReached() {
+      return this.getTurnCount() >= this.maxTurnsPerThread
+    },
+
+    shouldShowCountdown() {
+      const remaining = this.getRemainingTurns()
+      return remaining > 0 && remaining <= 3
+    },
+
+    async askQuestion() {
+      const question = this.currentQuestion.trim()
+      if (!question || this.isLoading || this.isThreadLimitReached()) {
+        return
+      }
+
+      // Add user message to UI
+      this.messages.push({
+        role: 'user',
+        content: question
+      })
+
+      this.currentQuestion = ''
+      // Reset textarea height
+      this.$nextTick(() => {
+        if (this.$refs.input) {
+          this.$refs.input.style.height = 'auto'
+        }
+      })
+      this.isLoading = true
+      this.error = null
+
+      // Add placeholder for assistant response
+      const responseIndex = this.messages.length
+      this.messages.push({
+        role: 'assistant',
+        content: '',
+        isStreaming: true,
+        questionAnswerId: null,
+        feedback: null,
+        copied: false
+      })
+
+      this.$nextTick(() => {
+        this.$refs.messagesContainer?.scrollTo({
+          top: this.$refs.messagesContainer.scrollHeight,
+          behavior: 'smooth'
+        })
+      })
+
+      try {
+        await this.streamGordonResponse(responseIndex)
+      } catch (err) {
+        // Only set error if messages weren't cleared
+        if (this.messages.length > 0) {
+          if (err.message === 'RATE_LIMIT_EXCEEDED') {
+            this.error = 'You\'ve exceeded your question quota for the day. Please come back tomorrow.'
+          } else {
+            this.error = 'Failed to get response. Please try again.'
+          }
+        }
+        console.error('Gordon API error:', err)
+        // Only try to remove message if it still exists
+        if (this.messages[responseIndex]) {
+          this.messages.splice(responseIndex, 1)
+        }
+      } finally {
+        this.isLoading = false
+      }
+    },
+
+    getSessionId() {
+      let sessionId = sessionStorage.getItem('gordon-session-id')
+      if (!sessionId) {
+        sessionId = `docs-${Date.now()}-${Math.random().toString(36).substr(2, 9)}`
+        sessionStorage.setItem('gordon-session-id', sessionId)
+      }
+      return sessionId
+    },
+
+    async streamGordonResponse(responseIndex) {
+
+      // Build API request from messages, excluding the streaming placeholder
+      // The placeholder is at responseIndex, so we take everything before it
+      const conversationMessages = this.messages.slice(0, responseIndex).map((msg, i) => {
+        const message = {
+          role: msg.role,
+          content: msg.content
+        }
+
+        // Add copilot_references to the last message (most recent user question)
+        if (i === responseIndex - 1) {
+          message.copilot_references = [
+            {
+              data: {
+                origin: 'docs-website',
+                email: 'docs@docker.com',
+                uuid: this.getSessionId(),
+                action: 'AskGordon',
+                ...(this.includePageContext && {
+                  page_url: window.location.href,
+                  {{ with .Title }}page_title: {{ . | jsonify }}{{ end }}
+                })
+              }
+            }
+          ]
+        }
+
+        return message
+      })
+
+      const isNewConversation = !this.threadId
+      const payload = {
+        messages: conversationMessages,
+        ...(this.threadId && { thread_uuid: this.threadId })
+      }
+
+      const response = await fetch(window.GORDON_BASE_URL + '/public/ask', {
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json' },
+        body: JSON.stringify(payload)
+      })
+
+      if (!response.ok) {
+        if (response.status === 429) {
+          throw new Error('RATE_LIMIT_EXCEEDED')
+        }
+        throw new Error(`HTTP ${response.status}: ${response.statusText}`)
+      }
+
+      const reader = response.body.getReader()
+      const decoder = new TextDecoder()
+
+      while (true) {
+        const { done, value } = await reader.read()
+        if (done) break
+
+        const chunk = decoder.decode(value, { stream: true })
+        const lines = chunk.split('\n')
+
+        for (const line of lines) {
+          if (!line.trim() || !line.startsWith('data: ')) continue
+
+          const data = line.slice(6)
+          if (data === '[DONE]') continue
+
+          try {
+            const parsed = JSON.parse(data)
+
+            // Capture thread_id for new conversations
+            if (parsed.thread_id) {
+              if (isNewConversation) {
+                this.threadId = parsed.thread_id  // $persist auto-saves to sessionStorage
+              } else if (parsed.thread_id !== this.threadId) {
+                console.warn('Backend returned unexpected thread_id:', parsed.thread_id)
+              }
+              continue
+            }
+
+            // Capture question_answer_id for feedback
+            if (parsed.question_answer_id) {
+              this.messages[responseIndex].questionAnswerId = parsed.question_answer_id
+              continue
+            }
+
+            if (parsed.choices && parsed.choices[0]?.delta?.content) {
+              const content = parsed.choices[0].delta.content
+              this.messages[responseIndex].content += content
+
+              this.$nextTick(() => {
+                const container = this.$refs.messagesContainer
+                if (container) {
+                  const isNearBottom = container.scrollHeight - container.scrollTop - container.clientHeight < 100
+                  if (isNearBottom) {
+                    container.scrollTop = container.scrollHeight
+                  }
+                }
+              })
+            }
+          } catch (e) {
+            console.error('Failed to parse SSE data:', e)
+          }
+        }
+      }
+
+      this.messages[responseIndex].isStreaming = false
+    },
+
+    clearChat() {
+      if (confirm('Clear all messages?')) {
+        this.messages = []      // $persist auto-saves empty array
+        this.threadId = null    // $persist auto-removes from sessionStorage
+        this.error = null
+      }
+    },
+
+    formatMessageContent(content) {
+      return this.$markdown(content)
+    },
+
+    async submitFeedback(messageIndex, feedbackType) {
+      const message = this.messages[messageIndex]
+
+      if (message.feedback === feedbackType) {
+        return
+      }
+
+      // Clear any previous error
+      message.feedbackError = null
+
+      if (!message.questionAnswerId) {
+        message.feedbackError = 'Unable to submit feedback'
+        console.error('No question_answer_id available for feedback')
+        return
+      }
+
+      try {
+        const response = await fetch(window.GORDON_BASE_URL + '/feedback', {
+          method: 'POST',
+          headers: { 'Content-Type': 'application/json' },
+          body: JSON.stringify({
+            id: message.questionAnswerId,
+            feedback: feedbackType
+          })
+        })
+
+        if (response.ok) {
+          message.feedback = feedbackType  // $persist auto-saves
+        } else {
+          message.feedbackError = 'Unable to submit feedback'
+          console.error('Failed to submit feedback:', response.status, response.statusText)
+        }
+      } catch (err) {
+        message.feedbackError = 'Unable to submit feedback'
+        console.error('Error submitting feedback:', err)
+      }
+    },
+
+    async copyAnswer(messageIndex) {
+      const message = this.messages[messageIndex]
+      if (!message.content) return
+
+      try {
+        await navigator.clipboard.writeText(message.content)
+        message.copied = true
+        this.$nextTick(() => {
+          setTimeout(() => {
+            message.copied = false
+          }, 2000)
+        })
+      } catch (err) {
+        console.error('Failed to copy:', err)
+      }
+    }
+  }"
+  x-cloak
+  @keydown.escape.window="$store.gordon.close()"
+>
+  <!-- Overlay backdrop -->
+  <div
+    x-show="$store.gordon.isOpen"
+    x-transition.opacity.duration.300ms
+    @click="$store.gordon.close()"
+    class="fixed inset-0 z-40 bg-black/50"
+  ></div>
+
+  <!-- Chat panel sliding in from right -->
+  <div
+    id="gordon-chat"
+    x-show="$store.gordon.isOpen"
+    x-transition:enter="transition ease-out duration-200"
+    x-transition:enter-start="translate-x-full"
+    x-transition:enter-end="translate-x-0"
+    x-transition:leave="transition ease-in duration-200"
+    x-transition:leave-start="translate-x-0"
+    x-transition:leave-end="translate-x-full"
+    class="fixed top-0 right-0 z-50 flex h-screen w-full flex-col overflow-hidden overscroll-contain rounded-none bg-white shadow-2xl transition-all duration-200 md:w-[min(80ch,90vw)] dark:bg-gray-950"
+  >
+    <!-- Header -->
+    <div
+      class="z-10 flex items-center justify-between bg-blue-500 px-6 py-3 shadow-lg/30 dark:shadow-lg/60"
+    >
+      <div class="flex items-center gap-3">
+        {{ partialCached "icon" "images/gordon-logo.svg" "images/gordon-logo.svg" }}
+      </div>
+      <div class="flex items-center gap-2">
+        <div data-tooltip-wrapper class="relative">
+          <button
+            @click="clearChat()"
+            aria-label="Start a new chat"
+            class="cursor-pointer rounded p-2 text-white transition-colors enabled:hover:bg-white/15 disabled:cursor-not-allowed disabled:opacity-50"
+            :disabled="messages.length === 0"
+          >
+            <span class="icon-svg">
+              {{ partialCached "icon" "arrow-path" "arrow-path" }}
+            </span>
+          </button>
+          <div
+            id="gordon-tooltip"
+            data-tooltip-body
+            class="absolute top-0 left-0 hidden rounded-sm bg-gray-900 p-2 text-sm whitespace-nowrap text-white"
+            role="tooltip"
+            x-show="messages.length > 0"
+          >
+            Start a new chat
+            <div
+              data-tooltip-arrow
+              class="absolute h-2 w-2 rotate-45 bg-gray-900"
+            ></div>
+          </div>
+        </div>
+        <button
+          @click="$store.gordon.close()"
+          title="Close chat drawer"
+          class="cursor-pointer rounded p-2 text-white transition-colors hover:bg-white/15"
+          aria-label="Close chat"
+        >
+          <span class="icon-svg">
+            {{ partialCached "icon" "x-mark" "x-mark" }}
+          </span>
+        </button>
+      </div>
+    </div>
+
+    <!-- Messages container -->
+    <div
+      x-ref="messagesContainer"
+      class="flex min-h-0 flex-1 flex-col space-y-4 overflow-y-auto overscroll-contain p-6"
+      style="scrollbar-width: none; &::-webkit-scrollbar: { display: none; }"
+    >
+      <!-- Welcome message when empty -->
+      <template x-if="messages.length === 0">
+        <div
+          class="my-auto flex flex-col items-center gap-2 px-2 pt-4 pb-2 text-center"
+        >
+          <div
+            class="mx-auto mb-2"
+            style="width: clamp(80px, 35%, 160px)"
+            aria-hidden="true"
+          >
+            {{ partialCached "icon" "images/gordon-robot.svg" "images/gordon-robot.svg" }}
+          </div>
+          <div class="flex w-full flex-col items-center justify-start gap-3">
+            <h3 class="text-xl font-semibold text-gray-900 dark:text-white">
+              What can I help you with?
+            </h3>
+            <p class="max-w-sm text-lg text-gray-600 dark:text-gray-400">
+              I'm Gordon, your AI assistant for Docker and documentation
+              questions.
+            </p>
+            <div class="w-full text-left">
+              <p
+                class="text-sm font-bold text-gray-600 uppercase dark:text-gray-400"
+              >
+                Try asking
+              </p>
+            </div>
+            {{- $gordonSuggestions := slice
+              (dict
+              "title" "Get started with Docker"
+              "question" "Help me get started with Docker. What should I do first?"
+              "icon" "rocket-launch")
+              (dict
+              "title" "Docker Hardened Images"
+              "question" "How do Docker Hardened Images work?"
+              "icon" "icons/dhi.svg")
+              (dict
+              "title" "MCP Toolkit"
+              "question" "What is MCP Toolkit?"
+              "icon" "icons/toolkit.svg")
+              (dict
+              "title" "Create an org"
+              "question" "How do I create an org?"
+              "icon" "icons/headset.svg")
+            -}}
+            <div class="grid w-full grid-cols-2 gap-2">
+              {{- range $gordonSuggestions }}
+                <button
+                  @click="currentQuestion = {{ .question | jsonify }}; askQuestion()"
+                  class="cursor-pointer rounded-xl border border-gray-200 bg-white p-3 transition hover:scale-[1.02] hover:border-blue-500 dark:border-gray-700 dark:bg-gray-900 dark:hover:border-blue-500"
+                >
+                  <div class="flex items-center gap-3">
+                    <span
+                      class="icon-svg shrink-0 rounded-lg bg-blue-100 p-1 text-blue-500 dark:bg-gray-700 dark:text-blue-400"
+                    >
+                      {{ partialCached "icon" .icon .icon }}
+                    </span>
+                    <p class="text-sm font-medium">{{ .title }}</p>
+                  </div>
+                </button>
+              {{- end }}
+            </div>
+          </div>
+        </div>
+      </template>
+
+      <!-- Messages -->
+      <div x-show="messages.length > 0" class="relative flex flex-col gap-4">
+        <template x-for="(message, index) in messages" :key="index">
+          <div
+            :class="message.role === 'user' ? 'flex justify-end' : 'flex justify-start'"
+          >
+            <div class="flex max-w-full flex-col gap-2">
+              <div
+                :class="message.role === 'user' ? 'bg-blue-500 dark:bg-blue-800 text-white' : 'max-w-none bg-gray-100 dark:bg-gray-800'"
+                class="prose prose-sm dark:prose-invert rounded-lg px-4"
+              >
+                <template x-if="!message.content && message.isStreaming">
+                  <div class="flex gap-1 py-3">
+                    <span
+                      class="inline-block h-2 w-2 animate-bounce rounded-full bg-current"
+                      style="animation-delay: 0ms"
+                    ></span>
+                    <span
+                      class="inline-block h-2 w-2 animate-bounce rounded-full bg-current"
+                      style="animation-delay: 150ms"
+                    ></span>
+                    <span
+                      class="inline-block h-2 w-2 animate-bounce rounded-full bg-current"
+                      style="animation-delay: 300ms"
+                    ></span>
+                  </div>
+                </template>
+                <template x-if="message.content">
+                  <div x-html="formatMessageContent(message.content)"></div>
+                </template>
+              </div>
+              <!-- Feedback buttons for assistant messages -->
+              <template
+                x-if="message.role === 'assistant' && !message.isStreaming"
+              >
+                <div class="flex flex-col gap-2">
+                  <div class="flex items-center gap-3 text-xs">
+                    <!-- "Was this helpful?" prompt with gordon icon -->
+                    <div
+                      class="flex items-center gap-1.5 text-gray-600 dark:text-gray-400"
+                    >
+                      <span class="icon-svg icon-sm">
+                        {{ partialCached "icon" "gordon" "gordon" }}
+                      </span>
+                      <span class="font-medium">Was this helpful?</span>
+                    </div>
+
+                    <!-- Feedback buttons group -->
+                    <div class="flex items-center gap-2">
+                      <!-- Thumbs up - Helpful -->
+                      <button
+                        @click="submitFeedback(index, 'positive')"
+                        :class="message.feedback === 'positive'
+                        ? 'bg-green-100 text-green-700 ring ring-green-500 dark:bg-green-900/50 dark:text-green-400 dark:ring-green-600'
+                        : 'bg-gray-100 text-gray-600 hover:bg-green-50 hover:text-green-600 hover:ring hover:ring-green dark:bg-gray-800 dark:text-gray-200 dark:hover:bg-green-900/30 dark:hover:text-green-400 dark:hover:ring-green'"
+                        class="flex cursor-pointer items-center gap-1.5 rounded-full px-3 py-1.5 transition-all duration-200"
+                        title="Helpful"
+                      >
+                        <span class="icon-svg icon-sm transition-transform">
+                          {{ partialCached "icon" "hand-thumb-up" "hand-thumb-up" }}
+                        </span>
+                        <span class="hidden font-medium sm:inline"
+                          >Helpful</span
+                        >
+                      </button>
+
+                      <!-- Thumbs down - Not quite -->
+                      <button
+                        @click="submitFeedback(index, 'negative')"
+                        :class="message.feedback === 'negative'
+                        ? 'bg-red-100 text-red-700 ring ring-red-500 dark:bg-red-900/50 dark:text-red-400 dark:ring-red-600'
+                        : 'bg-gray-100 text-gray-600 hover:bg-red-50 hover:text-red-600 hover:ring hover:ring-red dark:bg-gray-800 dark:text-gray-200 dark:hover:bg-red-900/30 dark:hover:text-red-400 dark:hover:ring-red'"
+                        class="flex cursor-pointer items-center gap-1.5 rounded-full px-3 py-1.5 transition-all duration-200"
+                        title="Not quite"
+                      >
+                        <span class="icon-svg icon-sm transition-transform">
+                          {{ partialCached "icon" "hand-thumb-down" "hand-thumb-down" }}
+                        </span>
+                        <span class="hidden font-medium sm:inline"
+                          >Not quite</span
+                        >
+                      </button>
+                    </div>
+
+                    <!-- Separator -->
+                    <div class="h-4 w-px bg-gray-300 dark:bg-gray-600"></div>
+
+                    <!-- Copy button -->
+                    <button
+                      @click="copyAnswer(index)"
+                      class="hover:ring-blue flex cursor-pointer items-center gap-1.5 rounded-full bg-gray-100 px-3 py-1.5 text-gray-600 transition-all duration-200 hover:bg-blue-50 hover:text-blue-700 hover:ring dark:bg-gray-800 dark:text-gray-200 dark:hover:bg-blue-900/30 dark:hover:text-blue-300 dark:hover:ring-blue-400"
+                      :title="message.copied ? 'Copied!' : 'Copy answer'"
+                    >
+                      <span
+                        x-show="message.copied !== true"
+                        class="icon-svg icon-sm"
+                      >
+                        {{ partialCached "icon" "document-duplicate" "document-duplicate" }}
+                      </span>
+                      <span
+                        x-show="message.copied === true"
+                        class="icon-svg icon-sm"
+                      >
+                        {{ partialCached "icon" "check-circle" "check-circle" }}
+                      </span>
+                      <span class="hidden font-medium sm:inline">Copy</span>
+                    </button>
+                  </div>
+
+                  <!-- Error message -->
+                  <template x-if="message.feedbackError">
+                    <div
+                      x-transition:enter="transition ease-out duration-200"
+                      x-transition:enter-start="opacity-0 translate-y-1"
+                      x-transition:enter-end="opacity-100 translate-y-0"
+                      class="flex items-center gap-1.5 text-xs text-red-600 dark:text-red-400"
+                    >
+                      <span x-text="message.feedbackError"></span>
+                    </div>
+                  </template>
+                </div>
+              </template>
+            </div>
+          </div>
+        </template>
+      </div>
+
+      <!-- Error message -->
+      <template x-if="error">
+        <div
+          class="rounded-lg border border-red-200 bg-red-50 p-4 text-red-800 dark:border-red-800 dark:bg-red-900/20 dark:text-red-400"
+        >
+          <p class="text-sm" x-text="error"></p>
+        </div>
+      </template>
+
+      <!-- Countdown warning when approaching limit -->
+      <template x-if="shouldShowCountdown()">
+        <div
+          class="rounded-lg border border-yellow-200 bg-yellow-50 p-3 text-yellow-800 dark:border-yellow-800 dark:bg-yellow-900/20 dark:text-yellow-400"
+        >
+          <p class="text-sm">
+            <span x-text="getRemainingTurns()"></span>
+            <span
+              x-text="getRemainingTurns() === 1 ? 'question' : 'questions'"
+            ></span>
+            remaining in this thread.
+          </p>
+        </div>
+      </template>
+
+      <!-- Thread limit warning -->
+      <template x-if="isThreadLimitReached()">
+        <div
+          class="rounded-lg border border-blue-200 bg-blue-50 p-4 text-blue-800 dark:border-blue-800 dark:bg-blue-900/20 dark:text-blue-400"
+        >
+          <p class="mb-3 text-sm">
+            You've reached the maximum of
+            <span x-text="maxTurnsPerThread"></span> questions per thread. For
+            better answer quality, start a new thread.
+          </p>
+          <button
+            @click="clearChat()"
+            class="cursor-pointer rounded-lg bg-blue-600 px-4 py-2 text-sm font-semibold text-white transition-colors hover:bg-blue-700 dark:bg-blue-500 dark:hover:bg-blue-600"
+          >
+            Start a new thread
+          </button>
+        </div>
+      </template>
+    </div>
+
+    <!-- Input area -->
+    <form @submit.prevent="askQuestion()" class="space-y-2 p-4 pt-0">
+      <div class="relative w-full">
+        <div class="relative flex-1 self-stretch">
+          <textarea
+            id="question"
+            x-ref="input"
+            x-model="currentQuestion"
+            @input="$el.style.height = 'auto'; $el.style.height = Math.min(160, $el.scrollHeight) + 'px'"
+            @keydown.enter="if (!$event.shiftKey) { $event.preventDefault(); askQuestion() }"
+            placeholder="Ask a question about Docker..."
+            rows="3"
+            :disabled="isLoading || isThreadLimitReached()"
+            class="block min-h-[3rem] w-full resize-none rounded-lg border border-gray-300 bg-white p-3 leading-normal focus:border-blue-500 focus:ring-2 focus:ring-blue-500/20 focus:outline-none enabled:hover:border-white disabled:cursor-not-allowed disabled:opacity-50 dark:border-gray-600 dark:bg-gray-900 dark:text-white dark:focus:border-blue-400"
+          ></textarea>
+        </div>
+        <button
+          type="submit"
+          :disabled="!currentQuestion.trim() || isLoading || isThreadLimitReached()"
+          :title="isLoading ? 'Sending...' : (isThreadLimitReached() ? 'Thread limit reached. Start a new thread.' : 'Send question')"
+          class="absolute top-2 right-2 cursor-pointer rounded p-2 text-blue-500 transition-colors enabled:hover:bg-blue-500/15 disabled:cursor-not-allowed disabled:text-gray-500"
+        >
+          <template x-if="!isLoading">
+            <span class="icon-svg">
+              {{ partialCached "icon" "paper-airplane" "paper-airplane" }}
+            </span>
+          </template>
+          <template x-if="isLoading">
+            <span class="icon-svg animate-spin">
+              {{ partialCached "icon" "arrow-path" "arrow-path" }}
+            </span>
+          </template>
+        </button>
+      </div>
+      <div
+        class="flex items-center justify-between"
+        x-data="{ showTooltip: false }"
+      >
+        <div class="relative">
+          <!-- Tooltip -->
+          <div
+            x-show="showTooltip"
+            x-transition:enter="transition ease-out duration-100"
+            x-transition:enter-start="opacity-0 scale-95"
+            x-transition:enter-end="opacity-100 scale-100"
+            x-transition:leave="transition ease-in duration-75"
+            x-transition:leave-start="opacity-100 scale-100"
+            x-transition:leave-end="opacity-0 scale-95"
+            class="absolute bottom-full left-0 mb-2 w-56 rounded-lg bg-gray-900 p-2.5 text-xs text-white shadow-lg dark:bg-gray-700"
+            style="display: none;"
+          >
+            <div class="relative">
+              <p>
+                When enabled, Gordon considers the current page you're viewing
+                to provide more relevant answers.
+              </p>
+              <!-- Arrow -->
+              <div
+                class="absolute -bottom-3 left-4 h-2 w-2 rotate-45 bg-gray-900 dark:bg-gray-700"
+              ></div>
+            </div>
+          </div>
+        </div>
+        <a
+          href="https://github.com/docker/docs/issues/23966"
+          target="_blank"
+          rel="noopener noreferrer"
+          class="text-xs text-gray-500 underline hover:text-blue-600 dark:text-gray-400 dark:hover:text-blue-400"
+        >
+          Share feedback
+        </a>
+      </div>
+    </form>
+
+    <!-- Disclaimer -->
+    <div
+      class="bg-blue-50 px-4 py-3 text-xs text-gray-600 dark:bg-gray-800 dark:text-gray-400"
+    >
+      Answers are generated based on the documentation.
+    </div>
+  </div>
+</div>
+
+<!-- Styles for Gordon chat -->
+<style>
+  /* Code block styles */
+  #gordon-chat pre {
+    background: #0d1117;
+    border-radius: 0.25rem;
+    padding: 0;
+    margin: 0.5rem 0;
+    overflow-x: auto;
+    white-space: pre;
+  }
+
+  #gordon-chat pre code {
+    background: #0d1117;
+    color: #c9d1d9;
+    padding: 1rem;
+    display: block;
+    font-family: "Roboto Mono", monospace;
+    font-size: 0.875rem;
+    line-height: 1.5;
+    white-space: pre;
+    overflow-x: auto;
+  }
+
+  #gordon-chat pre code * {
+    white-space: pre;
+  }
+
+  /* Inline code styling (not in pre blocks) */
+  #gordon-chat .prose code.not-prose {
+    background-color: rgb(229 231 235);
+    color: rgb(17 24 39);
+    padding: 0.2em 0.4em;
+    border-radius: 0.25rem;
+    font-family: "Roboto Mono", monospace;
+    font-size: 0.875em;
+  }
+
+  .dark #gordon-chat .prose code.not-prose {
+    background-color: rgb(55 65 81);
+    color: rgb(229 231 235);
+  }
+</style>
diff --git a/layouts/partials/head.html b/layouts/_partials/head.html
similarity index 81%
rename from layouts/partials/head.html
rename to layouts/_partials/head.html
index fc2d6ee2aeb9..15afc7ad4338 100644
--- a/layouts/partials/head.html
+++ b/layouts/_partials/head.html
@@ -1,6 +1,23 @@
 <meta charset="utf-8" />
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 {{ partial "meta.html" . }}
+{{- range .AlternativeOutputFormats -}}
+  {{- if eq .Name "markdown" -}}
+    <link
+      rel="{{ .Rel }}"
+      type="{{ .MediaType.Type }}"
+      href="{{ partial "utils/markdown-url.html" $ }}"
+    />
+  {{- else -}}
+    <link
+      rel="{{ .Rel }}"
+      type="{{ .MediaType.Type }}"
+      href="{{ .Permalink }}"
+    />
+  {{- end -}}
+{{ end -}}
+{{ partial "utils/css.html" . }}
+<link href="/pagefind/pagefind-component-ui.css" rel="stylesheet" />
 {{- if hugo.IsProduction -}}
   <script
     src="https://cdn.cookielaw.org/scripttemplates/otSDKStub.js"
@@ -8,13 +25,14 @@
     charset="UTF-8"
     data-domain-script="{{ site.Params.analytics.onetrust }}"
   ></script>
-  <script type="text/javascript">function OptanonWrapper() {}</script>
+  <script type="text/javascript">
+    function OptanonWrapper() {}
+  </script>
   <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
   new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
   j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
   'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
-  })(window,document,'script','dataLayer','{{ site.Params.analytics.google }}');</script>
-  <script>
+  })(window,document,'script','dataLayer','{{ site.Params.analytics.google }}');</script>  <script>
   (function(h,o,t,j,a,r){
     h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)};
     h._hjSettings={hjid:{{ site.Params.analytics.hotjar.prod | safeJS }},hjsv:6};
@@ -49,31 +67,33 @@
   })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv=');
   </script>
 {{ end }}
-{{/* kapa.ai widget */}}
-<script async src="https://widget.kapa.ai/kapa-widget.bundle.js"
-data-button-hide="true"
-data-font-family="Roboto Flex,sans-serif"
-data-modal-disclaimer-bg-color="#e5f2fc"
-data-modal-disclaimer-text-color="#086dd7"
-data-modal-disclaimer="This is a custom LLM for answering questions about Docker. Answers are based on the contents of the documentation. Rate the answers to let us know what you think!"
-data-kapa-branding-text="powered by [kapa.ai](https://www.kapa.ai) and Docker"
-data-modal-header-bg-color="#1d63ed"
-data-modal-image-height="25px"
-data-modal-image-width="181px"
-data-modal-title="​"
-data-modal-override-open-class="open-kapa-widget"
-data-modal-ask-ai-input-placeholder="Ask me a question about Docker…"
-data-modal-title-color="#fff"
-data-project-color="#1d63ed"
-data-project-logo="/assets/images/logo-icon-white.svg"
-data-project-name="Docker"
-data-user-analytics-fingerprint-enabled="true"
-data-bot-protection-mechanism="hcaptcha"
-data-website-id="{{ site.Params.kapa.id }}"
-></script>
+{{- with site.Params.analytics.marlin -}}
+  {{- $apiKey := "" -}}
+  {{- $endpoint := "" -}}
+  {{- $env := "" -}}
+  {{- if hugo.IsProduction -}}
+    {{- $apiKey = .apiKey.prod -}}
+    {{- $endpoint = .endpoint.prod -}}
+    {{- $env = "prod" -}}
+  {{- else if eq hugo.Environment "staging" -}}
+    {{- $apiKey = .apiKey.stage -}}
+    {{- $endpoint = .endpoint.stage -}}
+    {{- $env = "staging" -}}
+  {{- end -}}
+  {{- if and $apiKey $endpoint -}}
+    <script>
+      window.__marlinConfig = {{ dict "apiKey" $apiKey "endpoint" $endpoint "environment" $env | jsonify | safeJS }};
+    </script>
+  {{- end -}}
+{{- end -}}
 {{/* preload Roboto Flex as it's a critical font: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload */}}
-<link href="/assets/fonts/RobotoFlex.woff2" rel="preload" as="font" type="font/woff2" crossorigin />
-{{ partialCached "utils/css.html" "-" }}
+<link
+  href="/assets/fonts/RobotoFlex.woff2"
+  rel="preload"
+  as="font"
+  type="font/woff2"
+  crossorigin
+/>
 {{ $theme := resources.Get "js/theme.js" | js.Build (dict "minify" true) }}
 <script>{{ $theme.Content | safeJS }}</script>
 {{ $js := resources.Match "js/src/**.js"
diff --git a/layouts/_partials/header.html b/layouts/_partials/header.html
new file mode 100644
index 000000000000..2013c6ecf28e
--- /dev/null
+++ b/layouts/_partials/header.html
@@ -0,0 +1,120 @@
+<header class="sticky top-0 z-20 h-16 w-full bg-blue-600 text-white">
+  <div class="mx-auto flex h-full justify-between gap-2 px-4">
+    <div class="flex h-full items-center gap-2 lg:gap-8">
+      {{- if not .IsHome }}
+        <button
+          x-data
+          @click="$store.showSidebar = true"
+          class="icon-svg block h-full px-4 md:hidden"
+          aria-label="Menu"
+        >
+          {{ partialCached "icon" "bars-3" "bars-3" }}
+        </button>
+      {{- end }}
+      <div>
+        {{/* main logo */}}
+        <a title="Docker Docs home page" href="{{ site.BaseURL }}">
+          <div class="hidden sm:block">
+            {{- (resources.Get "images/docker-docs-white.svg").Content | safe.HTML -}}
+          </div>
+          <div class="block sm:hidden">
+            {{- (resources.Get "images/docker-docs-white-condensed.svg").Content | safe.HTML -}}
+          </div>
+        </a>
+      </div>
+      <nav class="mt-1 hidden md:flex lg:flex xl:flex 2xl:flex">
+        {{/* main menu */}}
+        <ul class="flex text-sm md:text-base lg:gap-4">
+          {{ range site.Menus.main }}
+            <li
+              {{- if or (eq page.Permalink .Page.Permalink) (page.IsDescendant .Page) }}
+                class="border-b-4"
+              {{- else }}
+                class="border-b-4 border-transparent hover:border-white/20"
+              {{- end }}
+            >
+              <a class="block px-2 py-1 whitespace-nowrap" href="{{ .URL }}"
+                >{{ .Name }}</a
+              >
+            </li>
+          {{ end }}
+        </ul>
+      </nav>
+    </div>
+    <div
+      id="buttons"
+      class="flex min-w-0 flex-shrink-0 items-center justify-end"
+    >
+      <div class="flex items-center gap-2">
+        <div data-tooltip-wrapper class="relative">
+          <button
+            x-data
+            @click="$store.gordon.toggle()"
+            aria-label="Ask Gordon, AI assistant"
+            aria-describedby="gordon-tooltip"
+            class="group shimmer flex cursor-pointer items-center gap-2 rounded-lg border border-blue-500 bg-blue-700 p-2 text-white transition-colors focus:ring focus:ring-blue-400 focus:outline-none"
+          >
+            <span class="icon-svg group-hover:hidden">
+              {{ partialCached "icon" "gordon" "gordon" }}
+            </span>
+            <span class="icon-svg hidden group-hover:block">
+              {{ partialCached "icon" "gordon-happy" "gordon-happy" }}
+            </span>
+            <span class="hidden px-1 lg:inline">Gordon</span>
+          </button>
+          <div
+            id="gordon-tooltip"
+            data-tooltip-body
+            class="absolute top-0 left-0 hidden rounded-sm bg-gray-900 p-2 text-sm whitespace-nowrap text-white"
+            role="tooltip"
+          >
+            Gordon, your AI assistant for Docker docs
+            <div
+              data-tooltip-arrow
+              class="absolute h-2 w-2 rotate-45 bg-gray-900"
+            ></div>
+          </div>
+        </div>
+
+        <div id="search-bar-container">
+          {{ partialCached "search-bar.html" "-" }}
+        </div>
+
+        <button
+          aria-label="Theme switch"
+          id="theme-switch"
+          class="cursor-pointer rounded-lg border border-blue-500 bg-blue-700 p-2 transition-colors hover:border-blue-400 hover:bg-blue-800 focus:ring focus:ring-blue-400 focus:outline-none"
+          x-data="{ theme: localStorage.getItem('theme-preference') || 'auto' }"
+          x-init="
+            let mql = window.matchMedia('(prefers-color-scheme: dark)');
+            function applyTheme(val) {
+              if (val === 'auto') {
+                localStorage.removeItem('theme-preference');
+                document.firstElementChild.className = mql.matches ? 'dark' : 'light';
+              } else {
+                localStorage.setItem('theme-preference', val);
+                document.firstElementChild.className = val;
+              }
+              document.firstElementChild.dataset.themePreference = val;
+            }
+            let handler = e => { if (theme === 'auto') document.firstElementChild.className = e.matches ? 'dark' : 'light'; };
+            mql.addEventListener('change', handler);
+            $watch('theme', val => applyTheme(val));
+            return () => mql.removeEventListener('change', handler);
+          "
+          @click="theme = (theme === 'light' ? 'dark' : theme === 'dark' ? 'auto' : 'light')"
+        >
+          <span class="theme-icon-sun icon-svg" x-show="theme === 'light'"
+            >{{ partialCached "icon" "sun" "sun" }}
+          </span>
+          <span class="theme-icon-moon icon-svg" x-show="theme === 'dark'">
+            {{ partialCached "icon" "moon" "moon" }}
+          </span>
+          <span class="theme-icon-auto icon-svg" x-show="theme === 'auto'">
+            {{ partialCached "icon" "system" "system" }}
+          </span>
+        </button>
+      </div>
+    </div>
+  </div>
+</header>
diff --git a/layouts/_partials/heading.html b/layouts/_partials/heading.html
new file mode 100644
index 000000000000..b2ba9ff63707
--- /dev/null
+++ b/layouts/_partials/heading.html
@@ -0,0 +1,9 @@
+{{ $id := .id | default (anchorize (plainify .text)) }}
+<h{{ .level }} class="{{ .class }} scroll-mt-20 flex items-center gap-2" id="{{ $id }}">
+  <a class="text-black dark:text-white no-underline hover:underline" href="#{{ $id }}">
+    {{ .text }}
+  </a>
+  {{- with .tier }}
+    {{- partial "components/badge.html" (dict "color" "blue" "content" . ) -}}
+  {{- end }}
+</h{{ .level }}>
diff --git a/layouts/_partials/icon.html b/layouts/_partials/icon.html
new file mode 100644
index 000000000000..26d945b8315e
--- /dev/null
+++ b/layouts/_partials/icon.html
@@ -0,0 +1,10 @@
+{{- $name := . -}}
+{{- $path := strings.TrimLeft "/" $name -}}
+{{- if not (strings.Contains $path "/") -}}
+  {{- $path = printf "icons/%s.svg" $path -}}
+{{- end -}}
+{{- with resources.Get $path -}}
+  {{- .Content | safeHTML -}}
+{{- else -}}
+  {{- errorf "Icon not found: %q (resolved to %q)" $name $path -}}
+{{- end -}}
diff --git a/layouts/_partials/md-dropdown.html b/layouts/_partials/md-dropdown.html
new file mode 100644
index 000000000000..4d989acfde6a
--- /dev/null
+++ b/layouts/_partials/md-dropdown.html
@@ -0,0 +1,85 @@
+<div class="not-prose mt-4">
+  <div class="flex flex-wrap items-center gap-x-6 gap-y-2 text-sm">
+    <button
+      onclick="askGordon()"
+      marlin-action="ask-gordon-button"
+      class="inline-flex cursor-pointer items-center gap-1.5 text-gray-600 transition-colors hover:text-gray-900 dark:text-gray-400 dark:hover:text-gray-100"
+    >
+      <span class="icon-svg icon-sm -translate-y-px">
+        {{ partialCached "icon" "gordon" "gordon" }}
+      </span>
+      <span>Ask Gordon</span>
+    </button>
+
+    <button
+      onclick="copyMarkdown()"
+      marlin-action="copy-markdown-button"
+      class="inline-flex cursor-pointer items-center gap-1.5 text-gray-600 transition-colors hover:text-gray-900 dark:text-gray-400 dark:hover:text-gray-100"
+    >
+      <span class="icon-svg icon-sm">
+        {{ partialCached "icon" "document-duplicate" "document-duplicate" }}
+      </span>
+      <span class="icon-svg icon-sm hidden">
+        {{ partialCached "icon" "check-circle" "check-circle" }}
+      </span>
+      <span>Copy Markdown</span>
+    </button>
+
+    <button
+      onclick="viewPlainText()"
+      marlin-action="view-markdown-button"
+      class="inline-flex cursor-pointer items-center gap-1.5 text-gray-600 transition-colors hover:text-gray-900 dark:text-gray-400 dark:hover:text-gray-100"
+    >
+      <span class="icon-svg icon-sm">
+        {{ partialCached "icon" "arrow-top-right-on-square" "arrow-top-right-on-square" }}
+      </span>
+      <span>View Markdown</span>
+    </button>
+  </div>
+  <hr class="mt-4 mb-6 border-t border-gray-200 dark:border-gray-700" />
+</div>
+
+<script>
+  function getCurrentPlaintextUrl() {
+    const url = window.location.href.split("#")[0].replace(/\/$/, "");
+    return `${url}.md`;
+  }
+
+  function copyMarkdown() {
+    fetch(getCurrentPlaintextUrl())
+      .then((response) => response.text())
+      .then((text) => {
+        navigator.clipboard.writeText(text).then(() => {
+          const button = document.querySelector(
+            '[marlin-action="copy-markdown-button"]',
+          );
+          if (!button) return;
+
+          const icons = button.querySelectorAll(".icon-svg");
+          const copyIcon = icons[0];
+          const checkIcon = icons[1];
+
+          copyIcon.classList.add("hidden");
+          checkIcon.classList.remove("hidden");
+
+          setTimeout(() => {
+            copyIcon.classList.remove("hidden");
+            checkIcon.classList.add("hidden");
+          }, 2000);
+        });
+      })
+      .catch((err) => {
+        console.error("Error copying markdown:", err);
+      });
+  }
+
+  function viewPlainText() {
+    window.open(getCurrentPlaintextUrl(), "_blank");
+  }
+
+  function askGordon() {
+    if (window.Alpine && window.Alpine.store("gordon")) {
+      window.Alpine.store("gordon").toggle();
+    }
+  }
+</script>
diff --git a/layouts/_partials/mermaid-script.html b/layouts/_partials/mermaid-script.html
new file mode 100644
index 000000000000..f69deeb8e7bf
--- /dev/null
+++ b/layouts/_partials/mermaid-script.html
@@ -0,0 +1,4 @@
+{{ $mermaid := resources.Get "js/mermaid.js"
+  | js.Build (dict "minify" true "targetPath" "mermaid.js")
+}}
+<script defer src="{{ $mermaid.Permalink }}"></script>
diff --git a/layouts/partials/meta.html b/layouts/_partials/meta.html
similarity index 78%
rename from layouts/partials/meta.html
rename to layouts/_partials/meta.html
index 56692711320e..5497bd220bf6 100644
--- a/layouts/partials/meta.html
+++ b/layouts/_partials/meta.html
@@ -3,7 +3,7 @@
   <title>{{ site.Title }}</title>
 {{ else }}
   <title>
-    {{ printf "%s | %s" .LinkTitle site.Title }}
+    {{ printf "%s | %s" .Title site.Title }}
   </title>
 {{ end }}
 {{ if or (eq .Params.sitemap false) (not hugo.IsProduction) }}
@@ -17,11 +17,14 @@
 <link rel="canonical" href="{{ .Permalink }}" />
 
 <!-- favicon -->
-{{ partialCached "favicon.html" "favicon" }}
+<link rel="icon" href="/assets/images/favicon-32x32.png" sizes="32x32" />
+<link rel="icon" href="/assets/images/favicon-192x192.png" sizes="192x192" />
+<link rel="apple-touch-icon" href="/apple-touch-icon.png" />
+<link rel="shortcut icon" href="/favicon.ico" />
 <meta name="theme-color" content="#2496ed" />
 
 <!-- SEO -->
-<meta name="twitter:title" itemprop="title name" content="{{ .LinkTitle }}" />
+<meta name="twitter:title" itemprop="title name" content="{{ .Title }}" />
 <meta
   name="twitter:description"
   property="og:description"
@@ -37,7 +40,7 @@
   content="{{ (resources.Get "images/thumbnail.webp").Permalink }}"
 />
 <meta name="twitter:image:alt" content="Docker Documentation" />
-<meta property="og:title" content="{{ .LinkTitle }}" />
+<meta property="og:title" content="{{ .Title }}" />
 <meta property="og:description" content="{{ $description }}" />
 <meta property="og:type" content="website" />
 <meta
@@ -58,4 +61,4 @@
   itemprop="datePublished"
   content="{{ .PublishDate | default .Lastmod }}"
 />
-  <script type="application/ld+json">{"@context":"https://schema.org","@type":"WebPage","headline":{{ .LinkTitle | jsonify }},"description":{{ $description | jsonify }},"url":"{{ .Permalink }}"}</script>
+{{ partial "schema.html" . }}
diff --git a/layouts/_partials/pagefind-meta.html b/layouts/_partials/pagefind-meta.html
new file mode 100644
index 000000000000..3164865e4e42
--- /dev/null
+++ b/layouts/_partials/pagefind-meta.html
@@ -0,0 +1,10 @@
+{{/* Pagefind metadata - must be inside data-pagefind-body */}}
+{{- $description := partial "utils/description.html" . -}}
+{{- $keywords := partialCached "utils/keywords.html" . . -}}
+{{- $breadcrumbs := slice -}}
+{{- range after 1 .Ancestors.Reverse -}}
+  {{- $breadcrumbs = $breadcrumbs | append .LinkTitle -}}
+{{- end -}}
+{{- with $description }}<meta data-pagefind-meta="description:{{ . }}">{{ end }}
+{{- with $keywords }}<meta data-pagefind-meta="keywords:{{ delimit . ", " }}">{{ end }}
+{{- with $breadcrumbs }}<meta data-pagefind-meta="breadcrumbs:{{ delimit . " / " }}">{{ end }}
diff --git a/layouts/_partials/pagemeta.html b/layouts/_partials/pagemeta.html
new file mode 100644
index 000000000000..4da98e97616e
--- /dev/null
+++ b/layouts/_partials/pagemeta.html
@@ -0,0 +1,42 @@
+{{- /*
+  Renders a table of contents (ToC) for the page.
+  - Uses `.Fragments.Headings` to generate a nested ToC if headings exist and `notoc` is not set to `true`.
+  - Limits heading levels to a min and max range (`$min` and `$max`).
+  - Wraps the ToC in a `data-pagefind-ignore` container to exclude it from search indexing.
+  - Includes a recursive template (`walkHeadingFragments`) to handle nested headings.
+  */
+-}}
+{{- $toc := false }}
+{{- with .Fragments }}
+  {{- $toc = and (ne page.Params.notoc true) .Headings }}
+{{- end }}
+{{- with $toc }}
+  <div data-pagefind-ignore class="not-prose">
+    <div class="pb-0 text-lg lg:pb-2">
+      {{ T "tableOfContents" }}
+    </div>
+    <nav class="toc">
+      {{ $root := (index page.Fragments.Headings 0).Headings }}
+      {{- template "walkHeadingFragments" $root }}
+    </nav>
+  </div>
+{{- end }}
+
+{{- define "walkHeadingFragments" }}
+  {{- $min := default 2 page.Params.toc_min }}
+  {{- $max := default 3 page.Params.toc_max }}
+  <ul class="pl-2">
+    {{- range . }}
+      {{- if and (ge .Level $min) (le .Level $max) }}
+        <li>
+          <a class="link lg:no-underline" href="#{{ .ID }}"
+            >{{ markdownify .Title }}</a
+          >
+        </li>
+      {{- end }}
+      {{- with .Headings }}
+        {{ template "walkHeadingFragments" . }}
+      {{- end }}
+    {{- end }}
+  </ul>
+{{- end }}
diff --git a/layouts/_partials/schema.html b/layouts/_partials/schema.html
new file mode 100644
index 000000000000..414a14cd522e
--- /dev/null
+++ b/layouts/_partials/schema.html
@@ -0,0 +1,126 @@
+{{- $description := partial "utils/description.html" . -}}
+{{- $keywords := partialCached "utils/keywords.html" . . -}}
+
+{{- /* Build TechArticle schema for content pages */ -}}
+{{- $schema := dict
+  "@context" "https://schema.org"
+  "@type" "TechArticle"
+  "headline" (truncate 110 .Title)
+  "description" $description
+  "url" .Permalink
+-}}
+
+{{- /* Add dates (from Git via enableGitInfo) */ -}}
+{{- with .PublishDate -}}
+  {{- $schema = merge $schema (dict "datePublished" (time.Format "2006-01-02T15:04:05Z07:00" .)) -}}
+{{- end -}}
+{{- with .Lastmod -}}
+  {{- $schema = merge $schema (dict "dateModified" (time.Format "2006-01-02T15:04:05Z07:00" .)) -}}
+{{- end -}}
+
+{{- /* Add mainEntityOfPage and language */ -}}
+{{- $schema = merge $schema (dict
+  "mainEntityOfPage" (dict "@type" "WebPage" "@id" .Permalink)
+  "inLanguage" site.Language.Lang
+  )
+-}}
+
+{{- /* Add author and publisher */ -}}
+{{- $logoUrl := printf "%sassets/images/docker-logo.png" (strings.TrimSuffix "/" site.BaseURL | printf "%s/") -}}
+{{- $org := dict
+  "@type" "Organization"
+  "name" "Docker Inc"
+  "url" "https://www.docker.com"
+-}}
+{{- $schema = merge $schema (dict "author" $org "publisher" (merge $org (dict "logo" (dict "@type" "ImageObject" "url" $logoUrl)))) -}}
+
+{{- /* Add article section (from Hugo section) */ -}}
+{{- with .Section -}}
+  {{- $schema = merge $schema (dict "articleSection" .) -}}
+{{- end -}}
+
+{{- /* Add keywords if present */ -}}
+{{- with $keywords -}}
+  {{- $schema = merge $schema (dict "keywords" .) -}}
+{{- end -}}
+
+{{- /* Add proficiency level if specified in frontmatter */ -}}
+{{- with .Params.proficiencyLevel -}}
+  {{- $schema = merge $schema (dict "proficiencyLevel" .) -}}
+{{- end -}}
+
+{{- /* Add prerequisites if specified in frontmatter */ -}}
+{{- with .Params.prerequisites -}}
+  {{- $schema = merge $schema (dict "dependencies" .) -}}
+{{- end -}}
+
+{{- /* Add time required if specified in frontmatter */ -}}
+{{- with .Params.time -}}
+  {{- /* Convert "20 minutes" to ISO 8601 duration "PT20M" */ -}}
+  {{- $duration := . -}}
+  {{- $isoDuration := "" -}}
+  {{- if findRE `(\d+)\s*minutes?` $duration -}}
+    {{- $mins := index (findRE `\d+` $duration) 0 -}}
+    {{- $isoDuration = printf "PT%sM" $mins -}}
+  {{- else if findRE `(\d+)\s*hours?` $duration -}}
+    {{- $hours := index (findRE `\d+` $duration) 0 -}}
+    {{- $isoDuration = printf "PT%sH" $hours -}}
+  {{- end -}}
+  {{- with $isoDuration -}}
+    {{- $schema = merge $schema (dict "timeRequired" .) -}}
+  {{- end -}}
+{{- end -}}
+
+{{- /* Add isPartOf relationship to parent section */ -}}
+{{- with .Parent -}}
+  {{- if and (not .IsHome) .Permalink -}}
+    {{- $isPartOf := dict
+      "@type" "WebPage"
+      "@id" .Permalink
+      "name" (truncate 110 .LinkTitle)
+    -}}
+    {{- $schema = merge $schema (dict "isPartOf" $isPartOf) -}}
+  {{- end -}}
+{{- end -}}
+
+{{- /* Output the schema as JSON-LD */ -}}
+<script type="application/ld+json">{{ $schema | jsonify | safeJS }}</script>
+{{- /* Add BreadcrumbList schema */ -}}
+{{- $breadcrumbs := slice -}}
+{{- $position := 1 -}}
+{{- range .Ancestors.Reverse -}}
+  {{- if and (not .IsHome) .Permalink -}}
+    {{- $item := dict
+      "@type" "ListItem"
+      "position" $position
+      "item" (dict
+      "@id" .Permalink
+      "name" (truncate 110 .LinkTitle)
+      )
+    -}}
+    {{- $breadcrumbs = $breadcrumbs | append $item -}}
+    {{- $position = add $position 1 -}}
+  {{- end -}}
+{{- end -}}
+
+{{- /* Add current page to breadcrumbs */ -}}
+{{- $currentItem := dict
+  "@type" "ListItem"
+  "position" $position
+  "item" (dict
+  "@id" .Permalink
+  "name" (truncate 110 .Title)
+  )
+-}}
+{{- $breadcrumbs = $breadcrumbs | append $currentItem -}}
+
+{{- /* Only output breadcrumbs if there's more than just the current page */ -}}
+{{- if gt (len $breadcrumbs) 1 -}}
+<script type="application/ld+json">
+{{- dict
+  "@context" "https://schema.org"
+  "@type" "BreadcrumbList"
+  "itemListElement" $breadcrumbs
+| jsonify | safeJS -}}
+</script>
+{{- end -}}
diff --git a/layouts/_partials/search-bar.html b/layouts/_partials/search-bar.html
new file mode 100644
index 000000000000..bfde680f82e8
--- /dev/null
+++ b/layouts/_partials/search-bar.html
@@ -0,0 +1,101 @@
+<div id="search-bar" class="h-full relative flex items-center overflow-visible">
+  <button
+    type="button"
+    aria-label="Search"
+    class="cursor-pointer flex items-center gap-2 p-2 rounded-lg bg-blue-700 border border-blue-500 text-white transition-colors focus:outline-none focus:ring focus:ring-blue-400 hover:bg-blue-800 hover:border-blue-400"
+    id="search-modal-trigger"
+  >
+    <span class="icon-svg">
+      {{ partialCached "icon" "magnifying-glass" "magnifying-glass" }}
+    </span>
+    <span class="hidden px-1 lg:inline">Search</span>
+  </button>
+</div>
+
+<script type="module">
+  // Configure Pagefind before any components connect to DOM
+  await import('/pagefind/pagefind-component-ui.js');
+  const { configureInstance, getInstanceManager } = window.PagefindComponents;
+
+  configureInstance('default', {
+    bundlePath: '/pagefind/',
+    ranking: {
+      termFrequency: 0.0,
+      termSimilarity: 2.0,
+      pageLength: 0.0,
+      termSaturation: 1.0,
+      metaWeights: {
+        title: 10.0,
+        description: 4.0,
+        keywords: 6.0
+      }
+    }
+  });
+
+  // Create modal after config is set
+  document.body.insertAdjacentHTML('beforeend', `
+    <pagefind-modal id="search-modal" reset-on-close>
+      <pagefind-modal-header>
+        <pagefind-input placeholder="Search documentation…"></pagefind-input>
+      </pagefind-modal-header>
+      <pagefind-modal-body>
+        <p id="search-placeholder" class="text-center text-gray-500 dark:text-gray-400 py-8">
+          Start typing to search the documentation
+        </p>
+        <pagefind-summary></pagefind-summary>
+        <pagefind-results>
+          <script type="text/pagefind-template">
+            <li class="py-3 border-b border-gray-200 dark:border-gray-700 last:border-b-0">
+              {{ print "{{#if meta.breadcrumbs}}" }}
+                <p class="text-xs text-gray-500 dark:text-gray-400 mb-1">{{ print "{{ meta.breadcrumbs }}" }}</p>
+              {{ print "{{/if}}" }}
+              <p class="font-medium">
+                <a class="text-blue-600 dark:text-blue-400 hover:underline" href="{{ print "{{ meta.url | default(url) | safeUrl }}" }}">
+                  {{ print "{{ meta.title }}" }}
+                </a>
+              </p>
+              {{ print "{{#if excerpt}}" }}
+                <p class="text-gray-600 dark:text-gray-400 mt-1 text-sm">{{ print "{{+ excerpt +}}" }}</p>
+              {{ print "{{/if}}" }}
+              {{ print "{{#if sub_results}}" }}
+                <ul class="mt-3 ml-4 flex flex-wrap gap-2">
+                  {{ print "{{#each sub_results as sub}}" }}
+                    {{ print "{{#if (lt @index 5)}}" }}
+                      <li class="text-sm">
+                        <a class="text-blue-600 dark:text-blue-400 hover:underline" href="{{ print "{{ sub.url | safeUrl }}" }}">
+                          {{ print "{{ sub.title }}" }}
+                        </a>
+                      </li>
+                    {{ print "{{/if}}" }}
+                  {{ print "{{/each}}" }}
+                </ul>
+              {{ print "{{/if}}" }}
+            </li>
+          </script>
+        </pagefind-results>
+      </pagefind-modal-body>
+    </pagefind-modal>
+  `);
+
+  const modal = document.getElementById('search-modal');
+  const placeholder = document.getElementById('search-placeholder');
+
+  // Show/hide placeholder based on search state
+  const instance = getInstanceManager().getInstance('default');
+  instance.on('search', (term) => {
+    placeholder.hidden = !!term;
+  });
+  instance.on('results', () => {
+    placeholder.hidden = !!instance.searchTerm;
+  });
+
+  // Open modal
+  const openModal = () => modal.open?.();
+  document.getElementById('search-modal-trigger').addEventListener('click', openModal);
+  document.addEventListener('keydown', (e) => {
+    if ((e.metaKey || e.ctrlKey) && e.key === 'k') {
+      e.preventDefault();
+      openModal();
+    }
+  });
+</script>
diff --git a/layouts/_partials/sidebar/mainnav.html b/layouts/_partials/sidebar/mainnav.html
new file mode 100644
index 000000000000..5bc45d7bd1fb
--- /dev/null
+++ b/layouts/_partials/sidebar/mainnav.html
@@ -0,0 +1,61 @@
+{{- /*
+  Complements the section-specific sidebar navigation.
+  - Renders the main navigation for site sections, linking to the current or ancestor section/page.
+  - Uses the `site.Menus.main` configuration to determine primary navigation structure.
+  - Toggles visibility of nested menu items for the main sections.
+  */
+-}}
+<!-- Main navigation for the sidebar -->
+<div class="px-2 py-4 md:hidden text-gray-700 dark:text-gray-200 card " x-data="{ expanded: false }">
+  <div class="flex w-full items-center justify-between">
+    <!-- Current section: use menu, fall back to current section or page -->
+    {{- $curr := .FirstSection }}
+    {{- if eq $curr site.Home }}
+      {{- $curr = . }}
+    {{- end }}
+    {{- range site.Menus.main }}
+      {{- if or (.Page.IsAncestor page) (eq .Page page) }}
+        {{- $curr = .Page }}
+      {{- end }}
+    {{- end }}
+    <a
+      class="hover:text-blue dark:hover:text-blue"
+      href="{{ $curr.Permalink }}"
+    >
+      {{- with $curr.Params.icon }}
+        <span class="icon-sm icon-svg pr-2">
+          {{- partialCached "icon" . . -}}
+        </span>
+      {{- end }}
+      {{- $curr.LinkTitle -}}
+    </a>
+    <button
+      @click="expanded = !expanded"
+      class="rounded-sm px-1 hover:bg-gray-200 hover:dark:bg-gray-800"
+    >
+      <span x-show="! expanded" class="icon-svg icon-sm">
+        {{ partialCached "icon" "chevron-down" "chevron-down" }}
+      </span>
+      <span x-cloak x-show="expanded" class="icon-svg icon-sm">
+        {{ partialCached "icon" "chevron-up" "chevron-up" }}
+      </span>
+    </button>
+  </div>
+  <ul x-cloak x-show="expanded" class="space-y-4 pt-4">
+    {{ range site.Menus.main }}
+      {{ if ne page.FirstSection .Page }}
+        <li>
+          <a class="hover:text-blue dark:hover:text-blue" href="{{ .URL }}">
+            {{- with .Page.Params.icon }}
+              <span class="icon-sm icon-svg pr-2">
+                {{- partialCached "icon" . . -}}
+              </span>
+            {{- end }}
+            {{- .Name }}
+          </a>
+        </li>
+      {{ end }}
+    {{ end }}
+  </ul>
+</div>
+
diff --git a/layouts/_partials/sidebar/sections.html b/layouts/_partials/sidebar/sections.html
new file mode 100644
index 000000000000..ab1650ff1a86
--- /dev/null
+++ b/layouts/_partials/sidebar/sections.html
@@ -0,0 +1,171 @@
+{{- /*
+  This template recursively renders the sidebar navigation, grouping pages by `Params.sidebar.groups`.
+  Highlights:
+  - Supports hierarchical navigation with collapsible sections (`renderList` template).
+  - Dynamically applies current page highlighting and expanded states.
+  - Handles external links via `Params.sidebar.goto` in `renderSingle`.
+  - Requires `Params.sitemap` and `Params.sidebar` for filtering and behavior.
+  */
+-}}
+<!-- section tree -->
+<nav class="navbar-font mx-1 mt-1 flex flex-col">
+  <ul>
+    {{ template "renderChildren" (dict "section" .FirstSection "revealHidden" false) }}
+  </ul>
+</nav>
+
+{{ define "renderChildren" }}
+  {{- $section := .section }}
+  {{- $revealHidden := .revealHidden }}
+  {{- $sourcePages := $section.Pages }}
+  {{- if $section.Params.sidebar.reverse }}
+    {{ $sourcePages = $sourcePages.Reverse }}
+  {{- end }}
+  {{- $pages := slice }}
+  {{- range $sourcePages }}
+    {{- $isActive := or (eq page .) (page.IsDescendant .) }}
+    {{- if or (ne .Params.sitemap false) $isActive $revealHidden }}
+      {{- $pages = $pages | append . }}
+    {{- end }}
+  {{- end }}
+  {{- $ungrouped := where $pages "Params.sidebar.group" "==" nil }}
+  {{- range $ungrouped }}
+    {{- if .IsSection }}
+      {{- template "renderList" (dict "section" . "revealHidden" $revealHidden) }}
+    {{- else }}
+      {{- template "renderSingle" . }}
+    {{- end }}
+  {{- end }}
+  {{- range $section.Params.sidebar.groups }}
+    <!--  Main titles -->
+    <div class="navbar-group">
+      <li class="navbar-group-font-title">
+        {{ . }}
+      </li>
+      {{- range where $pages "Params.sidebar.group" . }}
+        {{- if .IsSection }}
+          {{- template "renderList" (dict "section" . "revealHidden" $revealHidden) }}
+        {{- else }}
+          {{- template "renderSingle" . }}
+        {{- end }}
+      {{- end }}
+    </div>
+  {{- end }}
+
+{{ end }}
+
+{{/* Recursive template for sidebar items */}}
+{{ define "renderList" }}
+  {{- $section := .section }}
+  {{- $isCurrent := eq page $section }}
+  {{- $expanded := or $isCurrent (page.IsDescendant $section) }}
+  {{- $revealHidden := or .revealHidden (and (eq $section.Params.sitemap false) $expanded) }}
+  <li class="" x-data="{ expanded: {{ $expanded }} }">
+    <div
+      class="{{ if $isCurrent }}
+        navbar-entry-background-current
+      {{ end }} flex w-full items-center justify-between rounded-sm"
+    >
+      <div class="navbar-entry-margin w-full truncate">
+        {{- if $section.Permalink }}
+          {{/* If the link is not empty, use it */}}
+          <!-- Sections that have children and linking to a page -->
+          <a
+            {{ if $isCurrent }}
+              aria-current="page" id="sidebar-current-page"
+            {{ end }}
+            class="hover:text-blue block select-none hover:dark:text-blue-400"
+            href="{{ $section.Permalink }}"
+          >
+            {{ template "renderTitle" $section }}
+          </a>
+        {{- else }}
+          {{/* Otherwise, just expand the section */}}
+          <!-- Sections that have children and do not link to a page -->
+          <button
+            @click="expanded = !expanded"
+            class="hover:text-blue w-full text-left select-none hover:dark:text-blue-400"
+          >
+            {{ template "renderTitle" $section }}
+          </button>
+        {{- end }}
+      </div>
+      {{/* Only show expand group button if section has children */}}
+      {{- $children := slice }}
+      {{- range $section.Pages }}
+        {{- $isActive := or (eq page .) (page.IsDescendant .) }}
+        {{- if or (ne .Params.sitemap false) $isActive $revealHidden }}
+          {{- $children = $children | append . }}
+        {{- end }}
+      {{- end }}
+      {{- $hasChildren := gt (len $children) 0 }}
+      {{- if $hasChildren }}
+        <!-- Expand group button -->
+        <button
+          @click="expanded = !expanded"
+          class="rounded-sm px-1 hover:bg-gray-200 hover:dark:bg-gray-800"
+        >
+          <span
+            :class="{ 'hidden' : expanded }"
+            class="icon-svg icon-sm {{ if $expanded }}hidden{{ end }}"
+          >
+            {{ partialCached "icon" "chevron-down" "chevron-down" }}
+          </span>
+          <span
+            :class="{ 'hidden' : !expanded }"
+            class="icon-svg icon-sm {{ if not $expanded }}hidden{{ end }}"
+          >
+            {{ partialCached "icon" "chevron-up" "chevron-up" }}
+          </span>
+        </button>
+      {{- end }}
+    </div>
+    <ul
+      :class="{ 'hidden' : !expanded }"
+      class="{{ if not $expanded }}hidden{{ end }} ml-3"
+    >
+      {{ template "renderChildren" (dict "section" $section "revealHidden" $revealHidden) }}
+    </ul>
+  </li>
+{{ end }}
+
+{{ define "renderSingle" }}
+  {{- if .Params.sidebar.goto }}
+    <li class="navbar-entry-margin hover:text-blue hover:dark:text-blue-400">
+      <a
+        class="block w-full truncate"
+        href="{{ .Params.sidebar.goto }}"
+        title="{{ .LinkTitle }}"
+      >
+        {{ template "renderTitle" . }}
+      </a>
+    </li>
+  {{- else }}
+    {{ $isCurrent := eq page . }}
+    <li
+      class="navbar-entry-margin hover:text-blue {{ if $isCurrent }}
+        navbar-entry-background-current
+      {{ end }} rounded-sm hover:dark:text-blue-400"
+    >
+      <a
+        {{ if $isCurrent }}
+          aria-current="page" id="sidebar-current-page"
+        {{ end }}
+        class="block w-full truncate"
+        href="{{ .Permalink }}"
+        title="{{ .LinkTitle }}"
+      >
+        {{ template "renderTitle" . }}
+      </a>
+    </li>
+  {{- end }}
+{{ end }}
+
+{{ define "renderTitle" }}
+  {{ .LinkTitle }}
+  {{- with .Params.sidebar.badge }}
+    <span>
+      {{- partial "components/badge.html" (dict "color" .color "content" .text) }}
+    </span>
+  {{- end }}
+{{ end }}
diff --git a/layouts/_partials/tooltip.html b/layouts/_partials/tooltip.html
new file mode 100644
index 000000000000..d03b07e1bca1
--- /dev/null
+++ b/layouts/_partials/tooltip.html
@@ -0,0 +1,24 @@
+{{- /*
+  Renders a tooltip component using Floating UI for positioning.
+  See script at `assets/js/src/tooltip.js` for functionality.
+  */
+-}}
+<div data-tooltip-wrapper>
+  <div
+    data-tooltip-button
+    class="icon-svg text-blue-light flex items-center dark:text-blue-700"
+  >
+    {{ partialCached "icon" "question-mark-circle" "question-mark-circle" }}
+  </div>
+  <div
+    data-tooltip-body
+    class="absolute top-0 left-0 hidden max-w-56 rounded-sm bg-gray-700 p-2 text-white dark:text-gray-800 dark:bg-gray-300"
+    role="tooltip"
+  >
+    {{ . }}
+    <div
+      data-tooltip-arrow
+      class="absolute h-2 w-2 rotate-45 bg-gray-700 dark:bg-gray-300"
+    ></div>
+  </div>
+</div>
diff --git a/layouts/_partials/utils/css.html b/layouts/_partials/utils/css.html
new file mode 100644
index 000000000000..a59aac12e4cf
--- /dev/null
+++ b/layouts/_partials/utils/css.html
@@ -0,0 +1,22 @@
+{{ with (templates.Defer (dict "key" "global")) }}
+  {{ with resources.Get "css/style.css" }}
+    {{ $opts := dict
+      "minify" hugo.IsProduction
+      "inlineImports" true
+    }}
+    {{ with . | css.TailwindCSS $opts }}
+      {{ if hugo.IsProduction }}
+        {{ with . | fingerprint }}
+          <link
+            rel="stylesheet"
+            href="{{ .RelPermalink }}"
+            integrity="{{ .Data.Integrity }}"
+            crossorigin="anonymous"
+          />
+        {{ end }}
+      {{ else }}
+        <link rel="stylesheet" href="{{ .RelPermalink }}" />
+      {{ end }}
+    {{ end }}
+  {{ end }}
+{{ end }}
diff --git a/layouts/partials/utils/description.html b/layouts/_partials/utils/description.html
similarity index 88%
rename from layouts/partials/utils/description.html
rename to layouts/_partials/utils/description.html
index fde917161e34..bf5ba5517378 100644
--- a/layouts/partials/utils/description.html
+++ b/layouts/_partials/utils/description.html
@@ -1,6 +1,6 @@
 {{- /*
   Utility template to extract a description for the current page.
-  - Prioritizes `.Description` or falls back to front matter in `site.Data.frontmatter`.
+  - Prioritizes `.Description` or falls back to front matter in `hugo.Data.frontmatter`.
   - Replaces newlines with spaces and trims trailing spaces.
   - Designed for reuse via `partial` calls to generate meta descriptions or similar content.
 */ -}}
@@ -9,7 +9,7 @@
   {{ $desc = strings.Replace .Description "\n" " " }}
 {{ else }}
   {{ with .File }}
-    {{ with (index (site.Data.frontmatter) .Path) }}
+    {{ with (index (hugo.Data.frontmatter) .Path) }}
       {{ with .description }}
         {{ $desc = strings.Replace . "\n" " " | strings.TrimRight " " }}
       {{ end }}
diff --git a/layouts/partials/utils/keywords.html b/layouts/_partials/utils/keywords.html
similarity index 88%
rename from layouts/partials/utils/keywords.html
rename to layouts/_partials/utils/keywords.html
index bbcfff56b01a..9dbd6a22dbc8 100644
--- a/layouts/partials/utils/keywords.html
+++ b/layouts/_partials/utils/keywords.html
@@ -1,6 +1,6 @@
 {{- /*
   Utility template to extract keywords for the current page.
-  - Uses `.Keywords` if available or falls back to front matter in `site.Data.frontmatter`.
+  - Uses `.Keywords` if available or falls back to front matter in `hugo.Data.frontmatter`.
   - Cleans and trims keywords, joining them into a comma-separated string.
   - Intended for reuse in meta tags or other keyword-based contexts.
 */ -}}
@@ -9,7 +9,7 @@
   {{ $keywords = collections.Apply .Keywords "strings.Trim" "." ", " }}
 {{ else }}
   {{ with .File }}
-    {{ with (index (site.Data.frontmatter) .Path) }}
+    {{ with (index (hugo.Data.frontmatter) .Path) }}
       {{ with .keywords }}
         {{ $keywords = collections.Apply (strings.Split (strings.Replace . "\n" " ") ",") "strings.Trim" "." " " }}
       {{ end }}
diff --git a/layouts/_partials/utils/markdown-url.html b/layouts/_partials/utils/markdown-url.html
new file mode 100644
index 000000000000..f9ac6fb3ef25
--- /dev/null
+++ b/layouts/_partials/utils/markdown-url.html
@@ -0,0 +1,6 @@
+{{- if .IsHome -}}
+  {{- absURL "/index.md" -}}
+{{- else -}}
+  {{- $path := strings.TrimSuffix "/" .RelPermalink -}}
+  {{- printf "%s.md" $path | absURL -}}
+{{- end -}}
diff --git a/layouts/_partials/whats-new.html b/layouts/_partials/whats-new.html
new file mode 100644
index 000000000000..e050bc717004
--- /dev/null
+++ b/layouts/_partials/whats-new.html
@@ -0,0 +1,79 @@
+{{- $data := index hugo.Data "whats-new" -}}
+{{- with $data.items -}}
+  {{- $items := sort . "published" "desc" -}}
+  {{- $more := where $items "featured" false -}}
+  <section class="py-10 md:py-12" x-data="{ expanded: false }">
+    <div class="container mx-auto max-w-4xl px-4">
+      <header class="mb-6 border-b border-gray-200 pb-4 dark:border-gray-800">
+        <h2 class="text-2xl font-semibold text-gray-900 dark:text-white">
+          What's new
+        </h2>
+      </header>
+      <ol>
+        {{ range $items }}
+          <li
+            {{ if not .featured }}
+              x-cloak x-show="expanded" x-collapse.duration.300ms
+            {{ end }}
+            class="grid grid-cols-[1fr] md:grid-cols-[5rem_1fr] md:gap-x-6"
+          >
+            <time
+              class="hidden pt-5 text-right text-sm text-gray-500 md:block dark:text-gray-400"
+              datetime="{{ .published }}"
+              >{{ .published | time.Format "Jan 2" }}</time
+            >
+            <a
+              href="{{ .url }}"
+              class="group relative block border-l border-gray-200 py-5 pl-7 dark:border-gray-700"
+            >
+              <span
+                aria-hidden="true"
+                class="absolute top-6 -left-[5px] size-[9px] rounded-full bg-gray-300 ring-4 ring-gray-50 transition group-hover:bg-blue-500 dark:bg-gray-600 dark:ring-gray-950 dark:group-hover:bg-blue-400"
+              ></span>
+              <span
+                class="mb-1 flex flex-wrap items-center gap-x-2 text-sm font-medium text-blue-600 dark:text-blue-400"
+              >
+                {{ .product }}
+                <time
+                  class="font-normal text-gray-500 md:hidden dark:text-gray-400"
+                  datetime="{{ .published }}"
+                  >{{ .published | time.Format "Jan 2" }}</time
+                >
+              </span>
+              <span class="flex items-center gap-2">
+                <span
+                  class="font-medium text-gray-900 transition group-hover:text-blue-500 dark:text-white dark:group-hover:text-blue-400"
+                  >{{ .title }}</span
+                >
+                <span
+                  class="icon-svg shrink-0 text-gray-400 transition group-hover:translate-x-1 group-hover:text-blue-500 dark:text-gray-500 dark:group-hover:text-blue-400"
+                >
+                  {{ partialCached "icon" "arrow-right" "arrow-right" }}
+                </span>
+              </span>
+              <span class="mt-1 block text-sm text-gray-600 dark:text-gray-300"
+                >{{ .description }}</span
+              >
+            </a>
+          </li>
+        {{ end }}
+      </ol>
+      {{ with $more }}
+        <button
+          type="button"
+          @click="expanded = !expanded"
+          :aria-expanded="expanded"
+          class="mt-4 ml-7 inline-flex items-center gap-1 text-sm font-medium text-blue-600 hover:text-blue-500 md:ml-[6.5rem] dark:text-blue-400 dark:hover:text-blue-300"
+        >
+          <span x-text="expanded ? 'Show less' : 'Show more'">Show more</span>
+          <span class="icon-svg icon-sm" x-show="!expanded">
+            {{ partialCached "icon" "chevron-down" "chevron-down" }}
+          </span>
+          <span class="icon-svg icon-sm" x-cloak x-show="expanded">
+            {{ partialCached "icon" "chevron-up" "chevron-up" }}
+          </span>
+        </button>
+      {{ end }}
+    </div>
+  </section>
+{{- end -}}
diff --git a/layouts/partials/youtube-script.html b/layouts/_partials/youtube-script.html
similarity index 100%
rename from layouts/partials/youtube-script.html
rename to layouts/_partials/youtube-script.html
diff --git a/layouts/shortcodes/accordion.html b/layouts/_shortcodes/accordion.html
similarity index 100%
rename from layouts/shortcodes/accordion.html
rename to layouts/_shortcodes/accordion.html
diff --git a/layouts/_shortcodes/accordion.markdown.md b/layouts/_shortcodes/accordion.markdown.md
new file mode 100644
index 000000000000..323631d5bb76
--- /dev/null
+++ b/layouts/_shortcodes/accordion.markdown.md
@@ -0,0 +1,5 @@
+{{ $title := .Get "title" -}}
+{{ $body := .InnerDeindent -}}
+**{{ $title }}**
+
+{{ $body }}
diff --git a/layouts/shortcodes/badge.html b/layouts/_shortcodes/badge.html
similarity index 100%
rename from layouts/shortcodes/badge.html
rename to layouts/_shortcodes/badge.html
diff --git a/layouts/_shortcodes/badge.markdown.md b/layouts/_shortcodes/badge.markdown.md
new file mode 100644
index 000000000000..9bcae182a4a1
--- /dev/null
+++ b/layouts/_shortcodes/badge.markdown.md
@@ -0,0 +1 @@
+{{ $text := .Get "text" }}\[{{ $text }}\]
diff --git a/layouts/_shortcodes/button.html b/layouts/_shortcodes/button.html
new file mode 100644
index 000000000000..6155ecbf829a
--- /dev/null
+++ b/layouts/_shortcodes/button.html
@@ -0,0 +1,10 @@
+{{ $text := .Get "text" }}
+{{ $url := .Get "url" }}
+{{- if (strings.HasPrefix $url "http") -}}
+  {{ $url = $url | safeURL }}
+{{- else if (strings.FindRE `([^_]|^)index.md` $url 1) -}}
+  {{ $url = ref .Page (strings.Replace $url "index.md" "_index.md") }}
+{{- else -}}
+  {{ $url = ref .Page $url }}
+{{- end -}}
+<a class="button not-prose" href="{{ $url }}">{{ $text }}</a>
diff --git a/layouts/_shortcodes/button.markdown.md b/layouts/_shortcodes/button.markdown.md
new file mode 100644
index 000000000000..345e6a1908fa
--- /dev/null
+++ b/layouts/_shortcodes/button.markdown.md
@@ -0,0 +1,3 @@
+{{ $text := .Get "text" -}}
+{{ $url := .Get "url" -}}
+[{{ $text }}]({{ $url }})
diff --git a/layouts/_shortcodes/card.html b/layouts/_shortcodes/card.html
new file mode 100644
index 000000000000..90810d8a802f
--- /dev/null
+++ b/layouts/_shortcodes/card.html
@@ -0,0 +1,8 @@
+{{ partial "components/card.html"
+  (dict
+  "description" (.Get "description")
+  "link" (.Get "link")
+  "title" (.Get "title")
+  "icon" (.Get "icon")
+  )
+}}
diff --git a/layouts/_shortcodes/card.markdown.md b/layouts/_shortcodes/card.markdown.md
new file mode 100644
index 000000000000..3ee941a0a693
--- /dev/null
+++ b/layouts/_shortcodes/card.markdown.md
@@ -0,0 +1 @@
+{{/* Card omitted from markdown output */}}
\ No newline at end of file
diff --git a/layouts/_shortcodes/desktop-install-v2.html b/layouts/_shortcodes/desktop-install-v2.html
new file mode 100644
index 000000000000..638d4fb9d368
--- /dev/null
+++ b/layouts/_shortcodes/desktop-install-v2.html
@@ -0,0 +1,61 @@
+{{- $all := .Get "all" -}}
+{{- $win := .Get "win" -}}
+{{- $win_arm_release := .Get "win_arm_release" -}}
+{{- $mac := .Get "mac" -}}
+{{- $linux := .Get "linux" -}}
+{{- $build_path := .Get "build_path" -}}
+<blockquote {{ if eq $build_path "/" }} class="tip" {{ end }} class="not-prose download-links">
+  <p class="font-semibold mb-1">Download Docker Desktop</p>
+  <div class="download-links-subcontainer">
+   {{- if or $all $win $win_arm_release }}
+   <ul>  {{ end }}
+    {{- if or $all $win }}
+      <li>
+        <a rel="noopener"
+           href="https://desktop.docker.com/win/main/amd64{{ $build_path }}Docker%20Desktop%20Installer.exe?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-windows">Windows</a>
+        (<a rel="noopener"
+            href="https://desktop.docker.com/win/main/amd64{{ $build_path }}checksums.txt">checksum</a>)
+      </li>
+    {{ end }}
+    {{- if or $win_arm_release }}
+        <li>
+          <a rel="noopener"
+             href="https://desktop.docker.com/win/main/arm64{{ $build_path }}Docker%20Desktop%20Installer.exe?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-windows">Windows ARM {{ $win_arm_release }}</a>
+          (<a rel="noopener"
+              href="https://desktop.docker.com/win/main/arm64{{ $build_path }}checksums.txt">checksum</a>)
+        </li>
+    {{ end }}
+     {{- if or $all $win $win_arm_release }}
+      </ul>  {{ end }}
+    {{- if or $all $mac }}
+      <ul>
+        <li>
+          <a rel="noopener" href="https://desktop.docker.com/mac/main/arm64{{ $build_path }}Docker.dmg?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-mac-arm64">Mac with Apple chip</a>
+          (<a rel="noopener"
+              href="https://desktop.docker.com/mac/main/arm64{{ $build_path }}checksums.txt">checksum</a>)
+        </li>
+        <li>
+          <a rel="noopener" href="https://desktop.docker.com/mac/main/amd64{{ $build_path }}Docker.dmg?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-mac-amd64">Mac with Intel chip</a>
+          (<a rel="noopener"
+              href="https://desktop.docker.com/mac/main/amd64{{ $build_path }}checksums.txt">checksum</a>)
+        </li>
+      </ul>
+    {{ end -}}
+    {{- if or $all $linux }}
+      <ul>
+        <li>
+          <a rel="noopener"
+             href="https://desktop.docker.com/linux/main/amd64{{ $build_path }}docker-desktop-amd64.deb?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-linux-amd64">Debian</a>
+          -
+          <a rel="noopener"
+             href="https://desktop.docker.com/linux/main/amd64{{ $build_path }}docker-desktop-x86_64.rpm?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-linux-amd64">RPM</a>
+          -
+          <a rel="noopener"
+             href="https://desktop.docker.com/linux/main/amd64{{ $build_path }}docker-desktop-x86_64.pkg.tar.zst?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-linux-amd64">Arch</a>
+          (<a rel="noopener"
+              href="https://desktop.docker.com/linux/main/amd64{{ $build_path }}checksums.txt">checksum</a>)
+        </li>
+      </ul>
+      {{- end -}}
+  </div>
+</blockquote>
diff --git a/layouts/_shortcodes/desktop-install-v2.markdown.md b/layouts/_shortcodes/desktop-install-v2.markdown.md
new file mode 100644
index 000000000000..880e00f6fa61
--- /dev/null
+++ b/layouts/_shortcodes/desktop-install-v2.markdown.md
@@ -0,0 +1,22 @@
+{{- $all := .Get "all" -}}
+{{- $win := .Get "win" -}}
+{{- $win_arm_release := .Get "win_arm_release" -}}
+{{- $mac := .Get "mac" -}}
+{{- $linux := .Get "linux" -}}
+{{- $build_path := .Get "build_path" -}}
+Download Docker Desktop:
+{{- if or $all $win }}
+- [Windows](https://desktop.docker.com/win/main/amd64{{ $build_path }}Docker%20Desktop%20Installer.exe)
+{{- end }}
+{{- if $win_arm_release }}
+- [Windows ARM {{ $win_arm_release }}](https://desktop.docker.com/win/main/arm64{{ $build_path }}Docker%20Desktop%20Installer.exe)
+{{- end }}
+{{- if or $all $mac }}
+- [Mac (Apple chip)](https://desktop.docker.com/mac/main/arm64{{ $build_path }}Docker.dmg)
+- [Mac (Intel chip)](https://desktop.docker.com/mac/main/amd64{{ $build_path }}Docker.dmg)
+{{- end }}
+{{- if or $all $linux }}
+- [Linux (Debian)](https://desktop.docker.com/linux/main/amd64{{ $build_path }}docker-desktop-amd64.deb)
+- [Linux (RPM)](https://desktop.docker.com/linux/main/amd64{{ $build_path }}docker-desktop-x86_64.rpm)
+- [Linux (Arch)](https://desktop.docker.com/linux/main/amd64{{ $build_path }}docker-desktop-x86_64.pkg.tar.zst)
+{{- end }}
diff --git a/layouts/shortcodes/desktop-install.html b/layouts/_shortcodes/desktop-install.html
similarity index 92%
rename from layouts/shortcodes/desktop-install.html
rename to layouts/_shortcodes/desktop-install.html
index c3f44fb2738c..148de3a7171b 100644
--- a/layouts/shortcodes/desktop-install.html
+++ b/layouts/_shortcodes/desktop-install.html
@@ -1,6 +1,6 @@
 {{- $all := .Get "all" -}}
 {{- $win := .Get "win" -}}
-{{- $beta_win_arm := .Get "beta_win_arm" -}}
+{{- $win_arm_release := .Get "win_arm_release" -}}
 {{- $mac := .Get "mac" -}}
 {{- $linux := .Get "linux" -}}
 {{- $version := .Get "version" -}}
@@ -14,9 +14,9 @@
   (<a rel="noopener"
       href="https://desktop.docker.com/win/main/amd64{{ $build_path }}checksums.txt">checksum</a>) |
   {{ end }}
-  {{- if or $beta_win_arm }}
+  {{- if or $win_arm_release }}
   <a rel="noopener"
-     href="https://desktop.docker.com/win/main/arm64{{ $build_path }}Docker%20Desktop%20Installer.exe">Windows ARM Beta</a>
+     href="https://desktop.docker.com/win/main/arm64{{ $build_path }}Docker%20Desktop%20Installer.exe">Windows ARM {{ $win_arm_release }}</a>
   (<a rel="noopener"
       href="https://desktop.docker.com/win/main/arm64{{ $build_path }}checksums.txt">checksum</a>) |
   {{ end }}
diff --git a/layouts/shortcodes/experimental.html b/layouts/_shortcodes/experimental.html
similarity index 85%
rename from layouts/shortcodes/experimental.html
rename to layouts/_shortcodes/experimental.html
index 9e8ac45809fe..93fab95c9ea9 100644
--- a/layouts/shortcodes/experimental.html
+++ b/layouts/_shortcodes/experimental.html
@@ -1,7 +1,7 @@
 <div class="px-4 border-l-2 border-l-magenta-light dark:border-l-magenta-dark">
   <p class="not-prose flex gap-2 items-center text-magenta-light dark:text-magenta-dark">
     <span class="icon-svg pb-1">
-      {{ partialCached "icon.html" "science" "science" }}
+      {{ partialCached "icon" "beaker" "beaker" }}
     </span>
     <strong>{{ .Get "title" | default (i18n "experimental") }}</strong>
   </p>
diff --git a/layouts/_shortcodes/experimental.markdown.md b/layouts/_shortcodes/experimental.markdown.md
new file mode 100644
index 000000000000..9da71ee33313
--- /dev/null
+++ b/layouts/_shortcodes/experimental.markdown.md
@@ -0,0 +1,3 @@
+> **{{ .Get "title" | default (i18n "experimental") }}**
+>
+> {{ .InnerDeindent }}
diff --git a/layouts/_shortcodes/file.html b/layouts/_shortcodes/file.html
new file mode 100644
index 000000000000..9e62391bc013
--- /dev/null
+++ b/layouts/_shortcodes/file.html
@@ -0,0 +1,78 @@
+{{/*
+  file shortcode — child of the `files` shortcode.
+
+  The body must be a fenced code block. The fence's info string is used as
+  the syntax-highlighting language. Wrapping the body in a fence keeps
+  rumdl and Vale happy (they treat fence content as code and skip
+  lint rules that would otherwise fire on `#` comment lines).
+
+  Usage:
+    {{< file path="app.py" >}}
+    ```python
+    from fastapi import FastAPI
+    ```
+    {{< /file >}}
+
+  Attributes:
+    path      required. File path within the project, can include folders (e.g. "db/password.txt").
+    lang      optional. Overrides the fence info string for syntax highlighting.
+    status    optional. One of "modified" or "new". Shows a colored badge in the file tree.
+    hl_lines  optional. Line numbers/ranges to highlight (e.g. "8" or "6,8-11"). Passed to chroma.
+*/}}
+
+{{ if ne .Parent.Name "files" }}
+  {{- errorf "file shortcode missing its 'files' parent: %s" .Position -}}
+{{ end }}
+
+{{ $path := trim (.Get "path") " " }}
+{{ if not $path }}
+  {{- errorf "file shortcode requires a path attribute: %s" .Position -}}
+{{ end }}
+
+{{ if not (.Parent.Store.Get "files") }}
+  {{ .Parent.Store.Set "files" slice }}
+{{ end }}
+
+{{/* Normalize line endings so CRLF source files behave identically to LF,
+     then trim leading/trailing whitespace so the fence on the first line
+     can be detected. */}}
+{{ $content := .Inner }}
+{{ $content = replace $content "\r\n" "\n" }}
+{{ $content = replace $content "\r" "\n" }}
+{{ $content = strings.TrimLeft "\n\t " $content }}
+{{ $content = strings.TrimRight "\n\t " $content }}
+
+{{/* Body must be wrapped in a fenced code block. Strip the fence and adopt
+     the info string as the default language. */}}
+{{ $lines := split $content "\n" }}
+{{ $lineCount := len $lines }}
+{{ $firstLine := index $lines 0 }}
+{{ $lastLine := index $lines (sub $lineCount 1) }}
+{{ if or (lt $lineCount 2) (not (hasPrefix $firstLine "```")) (ne (trim $lastLine " \t") "```") }}
+  {{- errorf "file %q: body must be a fenced code block (```language ... ```): %s" $path .Position -}}
+{{ end }}
+{{ $fenceLang := trim (strings.TrimPrefix "```" $firstLine) " \t" }}
+{{ $content = delimit (after 1 (first (sub $lineCount 1) $lines)) "\n" }}
+
+{{/* Language: explicit lang= attribute wins; otherwise use the fence info string. */}}
+{{ $lang := .Get "lang" | default $fenceLang }}
+
+{{/* Normalize optional status attribute. */}}
+{{ $status := lower (.Get "status" | default "") }}
+{{ if and $status (not (in (slice "" "modified" "new") $status)) }}
+  {{- errorf "file shortcode 'status' must be \"modified\", \"new\", or empty: %s" .Position -}}
+{{ end }}
+
+{{/* hl_lines: accept either "8" or "8-10" or "6,8-10,12"; chroma expects spaces. */}}
+{{ $hlLines := .Get "hl_lines" | default "" }}
+{{ if $hlLines }}
+  {{ $hlLines = replace $hlLines "," " " }}
+{{ end }}
+
+{{ $.Parent.Store.Add "files" (dict
+  "path" $path
+  "lang" $lang
+  "content" $content
+  "status" $status
+  "hl_lines" $hlLines
+) }}
diff --git a/layouts/_shortcodes/files.html b/layouts/_shortcodes/files.html
new file mode 100644
index 000000000000..47bf92f14b31
--- /dev/null
+++ b/layouts/_shortcodes/files.html
@@ -0,0 +1,391 @@
+{{/*
+  files shortcode — renders a VS Code-style file browser with scaffolding commands.
+
+  Usage:
+    {{< files name="my-project" >}}
+      {{< file path="app.py" >}}
+      ...contents...
+      {{< /file >}}
+      {{< file path="db/password.txt" >}}
+      secretpassword
+      {{< /file >}}
+    {{< /files >}}
+
+  Attributes:
+    name  required. Project name. Used as the window title and as the
+          top-level directory in the scaffolding commands.
+*/}}
+
+{{ with .Inner }}{{/* trigger child rendering */}}{{ end }}
+
+{{ $name := trim (.Get "name") " " }}
+{{ if not $name }}
+  {{- errorf "files shortcode requires a name attribute: %s" .Position -}}
+{{ end }}
+
+{{ $files := .Store.Get "files" }}
+{{ if not $files }}
+  {{- errorf "files shortcode is empty: %s" .Position -}}
+{{ end }}
+
+{{/* Collect unique parent directories (relative to project root) for mkdir. */}}
+{{ $dirs := slice }}
+{{ range $files }}
+  {{ $d := path.Dir .path }}
+  {{ if and (ne $d ".") (not (in $dirs $d)) }}
+    {{ $dirs = $dirs | append $d }}
+  {{ end }}
+{{ end }}
+
+{{/* Build the bash scaffolding command. */}}
+{{ $bashLines := slice }}
+{{ if $dirs }}
+  {{ $mkdirPaths := slice }}
+  {{ range $d := $dirs }}
+    {{ $mkdirPaths = $mkdirPaths | append (printf "%s/%s" $name $d) }}
+  {{ end }}
+  {{ $bashLines = $bashLines | append (printf "mkdir -p %s && cd %s" (delimit $mkdirPaths " ") $name) }}
+{{ else }}
+  {{ $bashLines = $bashLines | append (printf "mkdir %s && cd %s" $name $name) }}
+{{ end }}
+{{/* Use an unlikely heredoc delimiter so a file whose content contains a
+     bare `EOF` line (for example, a Dockerfile that itself has a `RUN <<EOF`
+     block) doesn't close the scaffold's heredoc early and leak the rest of
+     the file as shell commands. */}}
+{{ range $files }}
+  {{ $bashLines = $bashLines | append (printf "cat > %s <<'__DOCKER_DOCS_SCAFFOLD_EOF__'" .path) }}
+  {{ $bashLines = $bashLines | append .content }}
+  {{ $bashLines = $bashLines | append "__DOCKER_DOCS_SCAFFOLD_EOF__" }}
+{{ end }}
+{{ $bashScript := delimit $bashLines "\n" }}
+
+{{/* Build the PowerShell scaffolding command. */}}
+{{/* Write files via [System.IO.File]::WriteAllText with an explicit
+     UTF8Encoding($false), so output is UTF-8 without BOM in both Windows
+     PowerShell 5.1 and PowerShell 7+. The built-in `Set-Content -Encoding utf8`
+     emits a BOM on 5.1, which can break Dockerfile `# syntax=` directives and
+     some YAML parsers. */}}
+{{ $psLines := slice }}
+{{ $psLines = $psLines | append "# Write files as UTF-8 without BOM. Works on Windows PowerShell 5.1 and PowerShell 7+." }}
+{{ $psLines = $psLines | append "function WriteFile([string]$Path, [string]$Content) {" }}
+{{ $psLines = $psLines | append "    $full = Join-Path -Path (Get-Location).ProviderPath -ChildPath $Path" }}
+{{ $psLines = $psLines | append "    [System.IO.File]::WriteAllText($full, $Content, [System.Text.UTF8Encoding]::new($false))" }}
+{{ $psLines = $psLines | append "}" }}
+{{ $psLines = $psLines | append "" }}
+{{ $psLines = $psLines | append (printf "New-Item -ItemType Directory -Force -Path %s | Out-Null" $name) }}
+{{ range $d := $dirs }}
+  {{ $psLines = $psLines | append (printf "New-Item -ItemType Directory -Force -Path %s/%s | Out-Null" $name $d) }}
+{{ end }}
+{{ $psLines = $psLines | append (printf "Set-Location %s" $name) }}
+{{ range $files }}
+  {{ $psLines = $psLines | append (printf "WriteFile '%s' @'" .path) }}
+  {{ $psLines = $psLines | append .content }}
+  {{ $psLines = $psLines | append "'@" }}
+{{ end }}
+{{ $psScript := delimit $psLines "\n" }}
+
+{{/*
+  Build a tree-friendly view of the file list.
+  - $rootFiles: files at project root (dict with "index" and "name")
+  - $folderPaths: ordered, deduped list of folder paths (parents auto-included)
+  - $folderFiles: map of folder path -> slice of files in that folder
+
+  We then sort $folderPaths lexicographically so parents naturally come
+  before their children when iterating.
+*/}}
+{{ $rootFiles := slice }}
+{{ $folderPaths := slice }}
+{{ $folderFiles := dict }}
+{{ range $i, $f := $files }}
+  {{ $dir := path.Dir $f.path }}
+  {{ $entry := dict "index" $i "name" (path.Base $f.path) "path" $f.path "status" ($f.status | default "") }}
+  {{ if eq $dir "." }}
+    {{ $rootFiles = $rootFiles | append $entry }}
+  {{ else }}
+    {{/* Make sure every parent folder along the path is registered. */}}
+    {{ $parts := split $dir "/" }}
+    {{ $prefix := "" }}
+    {{ range $part := $parts }}
+      {{ if $prefix }}
+        {{ $prefix = printf "%s/%s" $prefix $part }}
+      {{ else }}
+        {{ $prefix = $part }}
+      {{ end }}
+      {{ if not (in $folderPaths $prefix) }}
+        {{ $folderPaths = $folderPaths | append $prefix }}
+      {{ end }}
+    {{ end }}
+    {{ $existing := index $folderFiles $dir | default slice }}
+    {{ $existing = $existing | append $entry }}
+    {{ $folderFiles = merge $folderFiles (dict $dir $existing) }}
+  {{ end }}
+{{ end }}
+{{ $folderPaths = sort $folderPaths }}
+
+<div
+  data-pagefind-ignore
+  class="not-prose my-6"
+  x-data="{
+    view: 'files',
+    shell: 'bash',
+    selected: 0,
+    scaffoldCopied: false,
+    fileCopied: -1,
+    bashScript: atob('{{ encoding.Base64Encode $bashScript }}'),
+    psScript: atob('{{ encoding.Base64Encode $psScript }}'),
+    fileContents: [
+      {{- range $i, $f := $files -}}
+        {{- if $i }},{{ end -}}
+        atob('{{ encoding.Base64Encode $f.content }}')
+      {{- end -}}
+    ],
+    copyScaffold() {
+      const script = this.shell === 'bash' ? this.bashScript : this.psScript;
+      window.navigator.clipboard.writeText(script);
+      this.scaffoldCopied = true;
+      setTimeout(() => this.scaffoldCopied = false, 2000);
+    },
+    copyFile(i) {
+      window.navigator.clipboard.writeText(this.fileContents[i]);
+      this.fileCopied = i;
+      setTimeout(() => { if (this.fileCopied === i) this.fileCopied = -1; }, 2000);
+    }
+  }"
+>
+  <div
+    class="overflow-x-auto [&::-webkit-scrollbar]:h-3 [&::-webkit-scrollbar-thumb]:rounded [&::-webkit-scrollbar-thumb]:bg-gray-400 [&::-webkit-scrollbar-track]:bg-gray-100 dark:[&::-webkit-scrollbar-thumb]:bg-gray-600 dark:[&::-webkit-scrollbar-track]:bg-gray-800"
+    style="touch-action: pan-x pan-y;"
+  >
+  <div
+    class="min-w-[40rem] overflow-hidden rounded-lg border border-gray-200 bg-white shadow-sm dark:border-gray-800 dark:bg-gray-900"
+  >
+    {{/* Window title bar */}}
+    <div
+      class="flex flex-wrap items-center gap-3 border-b border-gray-200 bg-gray-100 px-3 py-2 dark:border-gray-800 dark:bg-gray-800"
+    >
+      <div class="flex items-center gap-2">
+        <div class="flex gap-1.5">
+          <span class="h-3 w-3 rounded-full bg-red-400"></span>
+          <span class="h-3 w-3 rounded-full bg-yellow-400"></span>
+          <span class="h-3 w-3 rounded-full bg-green-400"></span>
+        </div>
+        <span
+          class="ml-2 font-mono text-sm text-gray-700 dark:text-gray-200"
+          >{{ $name }}</span
+        >
+      </div>
+      {{/* Primary view toggle: Files | Scaffold script */}}
+      <div
+        class="ml-auto flex gap-0.5 rounded border border-gray-300 bg-white p-0.5 text-xs dark:border-gray-700 dark:bg-gray-900"
+        role="tablist"
+      >
+        <button
+          type="button"
+          role="tab"
+          class="rounded px-2 py-1 font-medium"
+          :class="view === 'files' ? 'bg-blue-100 text-blue-700 dark:bg-blue-900 dark:text-blue-200' : 'text-gray-600 hover:bg-gray-100 dark:text-gray-300 dark:hover:bg-gray-800'"
+          @click="view = 'files'"
+        >
+          Files
+        </button>
+        <button
+          type="button"
+          role="tab"
+          class="rounded px-2 py-1 font-medium"
+          :class="view === 'scaffold' ? 'bg-blue-100 text-blue-700 dark:bg-blue-900 dark:text-blue-200' : 'text-gray-600 hover:bg-gray-100 dark:text-gray-300 dark:hover:bg-gray-800'"
+          @click="view = 'scaffold'; scaffoldCopied = false"
+        >
+          Scaffold script
+        </button>
+      </div>
+    </div>
+
+    {{/* Files view: sidebar + content (fixed height with internal scroll) */}}
+    <div class="flex h-[28rem]" x-show="view === 'files'">
+      {{/* Sidebar */}}
+      <aside
+        class="w-56 shrink-0 overflow-y-auto border-r border-gray-200 bg-gray-50 py-2 dark:border-gray-800 dark:bg-gray-950"
+      >
+        <ul class="text-sm" role="tablist">
+          {{/* Project root folder header — always at the top. */}}
+          <li>
+            <div
+              class="flex items-center gap-2 py-1 pr-3 font-mono font-medium text-gray-700 dark:text-gray-200"
+              style="padding-left: 12px"
+            >
+              <span class="icon-svg icon-sm shrink-0 text-gray-500 dark:text-gray-400"
+                >{{ partialCached "icon" "folder-open" "folder-open" }}</span
+              >
+              <span class="truncate">{{ $name }}</span>
+            </div>
+          </li>
+          {{/* Folders first (sorted so parents precede children), then root files. All shifted one level deeper because the project root is depth 0. */}}
+          {{ range $folderPath := $folderPaths }}
+            {{ $parts := split $folderPath "/" }}
+            {{ $depth := len $parts }}
+            {{ $basename := index $parts (sub (len $parts) 1) }}
+            <li>
+              <div
+                class="flex items-center gap-2 py-1 pr-3 font-mono text-gray-500 dark:text-gray-400"
+                style="padding-left: {{ add 12 (mul $depth 16) }}px"
+              >
+                <span class="icon-svg icon-sm shrink-0 text-gray-400"
+                  >{{ partialCached "icon" "folder" "folder" }}</span
+                >
+                <span class="truncate">{{ $basename }}</span>
+              </div>
+            </li>
+            {{ $filesInFolder := index $folderFiles $folderPath | default slice }}
+            {{ range $entry := $filesInFolder }}
+              <li>
+                <button
+                  type="button"
+                  role="tab"
+                  class="flex w-full items-center gap-2 py-1 pr-3 text-left font-mono"
+                  :class="selected === {{ $entry.index }} ? 'bg-gray-200 text-blue-700 dark:bg-gray-800 dark:text-blue-400' : 'text-gray-700 hover:bg-gray-100 hover:text-blue-700 dark:text-gray-200 dark:hover:bg-gray-900 dark:hover:text-blue-400'"
+                  @click="selected = {{ $entry.index }}"
+                  title="{{ $entry.path }}"
+                  style="padding-left: {{ add 12 (mul (add $depth 1) 16) }}px"
+                >
+                  <span class="icon-svg icon-sm shrink-0 text-gray-400"
+                    >{{ partialCached "icon" "document-text" "document-text" }}</span
+                  >
+                  <span class="truncate">{{ $entry.name }}</span>
+                  {{ if eq $entry.status "modified" }}
+                    <span class="ml-auto shrink-0 text-xs font-bold text-amber-600 dark:text-amber-400" title="Modified">M</span>
+                  {{ else if eq $entry.status "new" }}
+                    <span class="ml-auto shrink-0 text-xs font-bold text-green-600 dark:text-green-400" title="Added">A</span>
+                  {{ end }}
+                </button>
+              </li>
+            {{ end }}
+          {{ end }}
+          {{ range $entry := $rootFiles }}
+            <li>
+              <button
+                type="button"
+                role="tab"
+                class="flex w-full items-center gap-2 py-1 pr-3 text-left font-mono"
+                :class="selected === {{ $entry.index }} ? 'bg-gray-200 text-blue-700 dark:bg-gray-800 dark:text-blue-400' : 'text-gray-700 hover:bg-gray-100 hover:text-blue-700 dark:text-gray-200 dark:hover:bg-gray-900 dark:hover:text-blue-400'"
+                @click="selected = {{ $entry.index }}"
+                title="{{ $entry.path }}"
+                style="padding-left: 28px"
+              >
+                <span class="icon-svg icon-sm shrink-0 text-gray-400"
+                  >{{ partialCached "icon" "document-text" "document-text" }}</span
+                >
+                <span class="truncate">{{ $entry.name }}</span>
+                {{ if eq $entry.status "modified" }}
+                  <span class="ml-auto shrink-0 text-xs font-bold text-amber-600 dark:text-amber-400" title="Modified">M</span>
+                {{ else if eq $entry.status "new" }}
+                  <span class="ml-auto shrink-0 text-xs font-bold text-green-600 dark:text-green-400" title="Added">A</span>
+                {{ end }}
+              </button>
+            </li>
+          {{ end }}
+        </ul>
+      </aside>
+
+      {{/* Content pane. The outer `main` is the positioning context for the
+           copy button and stays fixed; the inner div is the scroll container
+           so content scrolls independently of the button. The chroma
+           `.highlight` wrapper's own overflow-x is disabled so the scroll
+           container owns both axes and scrollbars sit at the window edges. */}}
+      <main class="group relative min-w-0 flex-1 overflow-hidden">
+        {{/* Per-file copy button. Matches the codeblock copy style: icon-only,
+             hover-revealed, swaps to a check icon for two seconds on copy. */}}
+        <button
+          type="button"
+          class="absolute top-2 right-5 z-10 text-gray-300 dark:text-gray-500"
+          title="Copy file contents"
+          @click="copyFile(selected)"
+        >
+          <span :class="{ 'group-hover:block' : fileCopied !== selected }" class="icon-svg hidden"
+            >{{ partialCached "icon" "document-duplicate" "document-duplicate" }}</span
+          >
+          <span :class="{ 'group-hover:block' : fileCopied === selected }" class="icon-svg hidden"
+            >{{ partialCached "icon" "check-circle" "check-circle" }}</span
+          >
+        </button>
+
+        <div class="h-full overflow-auto [&_.highlight]:overflow-visible">
+          {{ range $i, $f := $files }}
+            {{ $opts := "" }}
+            {{ with $f.hl_lines }}
+              {{ $opts = printf "hl_lines=%s" . }}
+            {{ end }}
+            <div
+              role="tabpanel"
+              x-show="selected === {{ $i }}"
+              class="syntax-light dark:syntax-dark"
+            >
+              {{ (transform.Highlight $f.content $f.lang $opts) | safeHTML }}
+            </div>
+          {{ end }}
+        </div>
+      </main>
+    </div>
+
+    {{/* Scaffold script view, with Bash | PowerShell secondary toggle (fixed height with internal scroll) */}}
+    <div class="flex h-[28rem] flex-col" x-show="view === 'scaffold'" x-cloak>
+      {{/* Yellow callout: warning + shell selector */}}
+      <div class="flex flex-wrap items-center gap-3 border-b border-yellow-200 bg-yellow-50 px-3 py-2 text-xs text-yellow-900 dark:border-yellow-900/40 dark:bg-yellow-950/40 dark:text-yellow-200">
+        <div class="flex items-center gap-2">
+          <span class="icon-svg icon-sm shrink-0"
+            >{{ partialCached "icon" "exclamation-triangle" "exclamation-triangle" }}</span
+          >
+          <span>Overwrites existing files with the same names. Run from the parent of your project directory.</span>
+        </div>
+        <div
+          class="ml-auto flex gap-0.5 rounded border border-yellow-300 bg-white p-0.5 dark:border-yellow-900/60 dark:bg-gray-900"
+          role="tablist"
+        >
+          <button
+            type="button"
+            role="tab"
+            class="rounded px-2 py-0.5 font-medium"
+            :class="shell === 'bash' ? 'bg-blue-100 text-blue-700 dark:bg-blue-900 dark:text-blue-200' : 'text-gray-600 hover:bg-gray-100 dark:text-gray-300 dark:hover:bg-gray-800'"
+            @click="shell = 'bash'; scaffoldCopied = false"
+          >
+            Bash
+          </button>
+          <button
+            type="button"
+            role="tab"
+            class="rounded px-2 py-0.5 font-medium"
+            :class="shell === 'powershell' ? 'bg-blue-100 text-blue-700 dark:bg-blue-900 dark:text-blue-200' : 'text-gray-600 hover:bg-gray-100 dark:text-gray-300 dark:hover:bg-gray-800'"
+            @click="shell = 'powershell'; scaffoldCopied = false"
+          >
+            PowerShell
+          </button>
+        </div>
+      </div>
+      {{/* Code area. Outer div is the positioning context for the copy
+           button and stays fixed; inner div is the scroll container. */}}
+      <div class="group relative flex-1 overflow-hidden">
+        <button
+          type="button"
+          class="absolute top-2 right-5 z-10 text-gray-300 dark:text-gray-500"
+          title="Copy scaffold script"
+          @click="copyScaffold()"
+        >
+          <span :class="{ 'group-hover:block' : !scaffoldCopied }" class="icon-svg hidden"
+            >{{ partialCached "icon" "document-duplicate" "document-duplicate" }}</span
+          >
+          <span :class="{ 'group-hover:block' : scaffoldCopied }" class="icon-svg hidden"
+            >{{ partialCached "icon" "check-circle" "check-circle" }}</span
+          >
+        </button>
+        <div class="h-full overflow-auto [&_.highlight]:overflow-visible">
+          <div x-show="shell === 'bash'" class="syntax-light dark:syntax-dark">
+            {{ (transform.Highlight $bashScript "bash" "") | safeHTML }}
+          </div>
+          <div x-show="shell === 'powershell'" x-cloak class="syntax-light dark:syntax-dark">
+            {{ (transform.Highlight $psScript "powershell" "") | safeHTML }}
+          </div>
+        </div>
+      </div>
+    </div>
+  </div>
+  </div>
+</div>
diff --git a/layouts/_shortcodes/files.markdown.md b/layouts/_shortcodes/files.markdown.md
new file mode 100644
index 000000000000..8e5debc30d7e
--- /dev/null
+++ b/layouts/_shortcodes/files.markdown.md
@@ -0,0 +1,20 @@
+{{- /*
+  Markdown output of the files shortcode (used for the *.md
+  alternative output format that LLMs consume).
+
+  Renders the project name and each file as a fenced code block with
+  its path as a label. The file.html child populates the same .Store
+  this template reads from.
+*/ -}}
+{{- with .Inner }}{{/* trigger child shortcodes */}}{{ end -}}
+{{- $name := trim (.Get "name") " " -}}
+{{- $files := .Store.Get "files" -}}
+
+**`{{ $name }}/`**
+{{ range $files }}
+`{{ .path }}`{{ with .status }} ({{ . }}){{ end }}:
+
+```{{ .lang }}
+{{ .content }}
+```
+{{ end }}
diff --git a/layouts/_shortcodes/grid.html b/layouts/_shortcodes/grid.html
new file mode 100644
index 000000000000..73660037aeba
--- /dev/null
+++ b/layouts/_shortcodes/grid.html
@@ -0,0 +1,10 @@
+{{ $cols := .Get "cols" | default 3 }}
+<div
+  class="not-prose md:grid-cols-{{ math.Max 2 (sub $cols 1) }} xl:grid-cols-{{ $cols }} grid grid-cols-1 gap-4 mb-6"
+>
+  {{ $items := index .Page.Params (.Get "items" | default "grid") }}
+  {{ range $items }}
+    {{ $opts := dict "title" .title "link" .link "description" .description "icon" .icon "image" .image }}
+    {{ partial "components/card.html" $opts }}
+  {{ end }}
+</div>
diff --git a/layouts/_shortcodes/grid.markdown.md b/layouts/_shortcodes/grid.markdown.md
new file mode 100644
index 000000000000..8c88897104ff
--- /dev/null
+++ b/layouts/_shortcodes/grid.markdown.md
@@ -0,0 +1 @@
+{{/* Grid omitted from markdown output */}}
\ No newline at end of file
diff --git a/layouts/_shortcodes/include.html b/layouts/_shortcodes/include.html
new file mode 100644
index 000000000000..2faab47dd21f
--- /dev/null
+++ b/layouts/_shortcodes/include.html
@@ -0,0 +1,17 @@
+{{/*
+  include shortcode — inlines a reusable snippet from content/includes.
+
+  Usage:
+    {{% include "root-errors.md" %}}
+    {{% include "compose/services.md" %}}
+
+  The argument is a path relative to content/includes. The build fails with
+  a clear message if the target does not exist, so a renamed or deleted
+  snippet surfaces immediately instead of silently rendering nothing.
+*/}}
+{{ $fileToInclude := .Get 0 }}
+{{ $filePath := printf "includes/%s" $fileToInclude }}
+{{ if not (fileExists $filePath) }}
+  {{- errorf "include shortcode: file %q not found: %s" $filePath .Position -}}
+{{ end }}
+{{ readFile $filePath | safeHTML }}
diff --git a/layouts/shortcodes/inline-image.html b/layouts/_shortcodes/inline-image.html
similarity index 90%
rename from layouts/shortcodes/inline-image.html
rename to layouts/_shortcodes/inline-image.html
index a281c91ccf76..46df6c8ae435 100644
--- a/layouts/shortcodes/inline-image.html
+++ b/layouts/_shortcodes/inline-image.html
@@ -11,5 +11,5 @@
   src="{{ $src }}"
   alt="{{ $alt }}"
   {{ with $title }}title="{{ . }}"{{ end }}
-  class="inline my-0"
+  class="inline my-0 not-prose"
 />
diff --git a/layouts/_shortcodes/inline-image.markdown.md b/layouts/_shortcodes/inline-image.markdown.md
new file mode 100644
index 000000000000..26b12c9383a7
--- /dev/null
+++ b/layouts/_shortcodes/inline-image.markdown.md
@@ -0,0 +1,4 @@
+{{ $src := .Get "src" }}
+{{ $alt := .Get "alt" }}
+{{ $title := .Get "title" }}
+![{{ $alt }}]({{ $src }}{{ with $title }} "{{ . }}"{{ end }})
\ No newline at end of file
diff --git a/layouts/_shortcodes/labspace-launch.html b/layouts/_shortcodes/labspace-launch.html
new file mode 100644
index 000000000000..af786c070973
--- /dev/null
+++ b/layouts/_shortcodes/labspace-launch.html
@@ -0,0 +1,15 @@
+{{ $image := .Get "image" }}
+{{ $modelDownload := .Get "model-download" | default "false" }}
+{{ $browserUrl := .Get "browserUrl" | default "http://localhost:3030"}}
+
+{{ $step1 := printf "1. Start the labspace:\n\n   ```console\n   $ docker compose -p labspace -f oci://%s up -d\n   ```" $image }}
+
+{{ if eq $modelDownload "true" }}
+  {{ $step1 = printf "%s\n\n   > [!NOTE]\n   >\n   > This lab uses an AI model, which requires [the Docker Model Runner to be enabled](https://docs.docker.com/ai/model-runner/get-started/). The model may take some time to download." $step1 }}
+{{ end }}
+
+{{ $step2 := printf "2. Open your browser to [%s](%s)." $browserUrl $browserUrl }}
+
+{{ $step3 := "3. When you're done, tear down the labspace:\n\n   ```console\n   $ docker compose -p labspace down\n   ```" }}
+
+{{ printf "%s\n\n%s\n\n%s" $step1 $step2 $step3 | .Page.RenderString (dict "display" "block") }}
diff --git a/layouts/_shortcodes/release-date.html b/layouts/_shortcodes/release-date.html
new file mode 100644
index 000000000000..f5a112e55488
--- /dev/null
+++ b/layouts/_shortcodes/release-date.html
@@ -0,0 +1 @@
+<em class="text-gray-400 italic dark:text-gray-500">{{ .Get "date" }}</em>
diff --git a/layouts/shortcodes/restricted.html b/layouts/_shortcodes/restricted.html
similarity index 82%
rename from layouts/shortcodes/restricted.html
rename to layouts/_shortcodes/restricted.html
index befd5c4dbf72..17a8a696741c 100644
--- a/layouts/shortcodes/restricted.html
+++ b/layouts/_shortcodes/restricted.html
@@ -1,7 +1,7 @@
 <div class="px-4 border-l-2 border-l-magenta-light dark:border-l-magenta-dark">
   <p class="not-prose flex gap-2 items-center text-magenta-light dark:text-magenta-dark">
     <span class="icon-svg pb-1">
-      {{ partialCached "icon.html" "rocket_launch" "rocket_launch" }}
+      {{ partialCached "icon" "rocket-launch" "rocket-launch" }}
     </span>
     <strong>{{ .Get "title" | default (i18n "restricted") }}</strong>
   </p>
diff --git a/layouts/_shortcodes/restricted.markdown.md b/layouts/_shortcodes/restricted.markdown.md
new file mode 100644
index 000000000000..dd18b991b61f
--- /dev/null
+++ b/layouts/_shortcodes/restricted.markdown.md
@@ -0,0 +1,3 @@
+> **{{ .Get "title" | default (i18n "restricted") }}**
+>
+> {{ .InnerDeindent }}
diff --git a/layouts/shortcodes/sectionlinks.html b/layouts/_shortcodes/sectionlinks.html
similarity index 100%
rename from layouts/shortcodes/sectionlinks.html
rename to layouts/_shortcodes/sectionlinks.html
diff --git a/layouts/_shortcodes/summary-bar.html b/layouts/_shortcodes/summary-bar.html
new file mode 100644
index 000000000000..98f037117756
--- /dev/null
+++ b/layouts/_shortcodes/summary-bar.html
@@ -0,0 +1,86 @@
+{{ $featureName := .Get "feature_name" }}
+{{ $feature := index hugo.Data.summary $featureName }}
+{{ if not $feature }}
+  {{ errorf "[summary-bar] invalid feature: %s %v" $featureName .Position }}
+{{ end }}
+{{ if $feature }}
+  {{ $subscriptionIcons := dict
+    "Business" "building-office"
+    "Team" "user-group"
+    "Pro" "user-plus"
+    "Personal" "user"
+    "Available to all" "globe-alt"
+    "Docker Hardened Images Enterprise" "/icons/dhi.svg"
+    "Docker Hardened Images Select or Enterprise" "/icons/dhi.svg"
+    "Docker Offload" "cloud"
+    "AI Governance" "shield-check"
+  }}
+  {{ $availabilityIcons := dict
+    "Experimental" "beaker"
+    "Beta" "bolt"
+    "Early Access" "rocket-launch"
+    "GA" "check-circle"
+    "Retired" "archive-box"
+  }}
+  {{ $requiresIcon := "arrow-down-circle" }}
+  {{ $forIcon := "shield-check" }}
+
+
+  <div
+    class="not-prose summary-bar"
+  >
+    {{ with $feature.subscription }}
+      <div class="flex flex-wrap gap-1">
+        <span class="font-bold">Subscription:</span>
+        {{ range . }}
+          <span>{{ . }}</span>
+          <span class="icon-svg icon-sm">
+            {{ $icon := index $subscriptionIcons . }}
+            {{ if $icon }}
+              {{ partialCached "icon" $icon $icon }}
+            {{ else }}
+              {{ partialCached "icon" "question-mark-circle" "question-mark-circle" }}
+            {{ end }}
+          </span>
+        {{ end }}
+      </div>
+    {{ end }}
+
+    {{ with $feature.availability }}
+      {{ $availabilityText := . }}
+      <div class="flex flex-wrap gap-1">
+        <span class="font-bold">Availability:</span>
+        <span>
+          {{ $availabilityText }}
+          {{ range $key, $icon := $availabilityIcons }}
+            {{ if in $availabilityText $key }}
+              <span class="icon-svg icon-sm">{{ partialCached "icon" $icon $icon }}</span>
+            {{ end }}
+          {{ end }}
+        </span>
+      </div>
+    {{ end }}
+
+    {{ with $feature.requires }}
+      <div class="flex flex-wrap gap-1">
+        <span class="font-bold">Requires:</span>
+        <span>{{ . | markdownify }}</span>
+        <span class="icon-svg icon-sm">
+          {{ partialCached "icon" $requiresIcon $requiresIcon }}
+        </span>
+      </div>
+    {{ end }}
+
+    {{ with $feature.for }}
+      <div class="flex flex-wrap gap-1">
+        <span class="font-bold">For:</span>
+        <span>{{ . }}</span>
+        {{ if eq . "Administrators" }}
+          <span class="icon-svg icon-sm">
+            {{ partialCached "icon" $forIcon $forIcon }}
+          </span>
+        {{ end }}
+      </div>
+    {{ end }}
+  </div>
+{{ end }}
diff --git a/layouts/_shortcodes/summary-bar.markdown.md b/layouts/_shortcodes/summary-bar.markdown.md
new file mode 100644
index 000000000000..1434bcbee649
--- /dev/null
+++ b/layouts/_shortcodes/summary-bar.markdown.md
@@ -0,0 +1 @@
+{{/* Summary bar omitted from markdown output */}}
\ No newline at end of file
diff --git a/layouts/shortcodes/tab.html b/layouts/_shortcodes/tab.html
similarity index 100%
rename from layouts/shortcodes/tab.html
rename to layouts/_shortcodes/tab.html
diff --git a/layouts/_shortcodes/tabs.html b/layouts/_shortcodes/tabs.html
new file mode 100644
index 000000000000..d8d1e3119486
--- /dev/null
+++ b/layouts/_shortcodes/tabs.html
@@ -0,0 +1,50 @@
+{{ with .Inner }}{{/* don't do anything, just call it */}}{{ end }}
+{{ $first := urlize (index (.Store.Get "tabs") 0).name }}
+{{ $group := .Get "group" }}
+{{ $groupID := fmt.Printf "tabgroup-%s" (urlize $group) }}
+{{ $persist := .Get "persist" }}
+
+
+<div
+  class="tabs"
+  {{ with $group }}
+    {{ if $persist }}
+      x-data="{ selected: $persist('{{ $first }}').as('{{ $groupID }}') }"
+    {{ else }}
+      x-data="{ selected: '{{ $first }}' }"
+    {{ end }}
+    @tab-select.window="$event.detail.group === '{{ . }}' ? selected =
+    $event.detail.name : null"
+  {{ else }}
+    x-data="{ selected: '{{ $first }}' }"
+  {{ end }}
+  aria-role="tabpanel"
+>
+  <div aria-role="tablist" class="tablist">
+    {{ range (.Store.Get "tabs") }}
+      <button
+        class="tab-item"
+        :class="selected === '{{ .name | urlize }}' &&
+          'border-blue border-b-4 dark:border-b-blue-600'"
+        {{ if $group }}
+          @click="$dispatch('tab-select', { group: '{{ $group }}', name:
+          '{{ .name | urlize }}'})"
+        {{ else }}
+          @click="selected = '{{ .name | urlize }}'"
+        {{ end }}
+      >
+        {{ .name | page.RenderString }}
+      </button>
+    {{ end }}
+  </div>
+  <div>
+    {{ range (.Store.Get "tabs") }}
+      <div
+        aria-role="tab"
+        :class="selected !== '{{ .name | urlize }}' && 'hidden'"
+      >
+        {{ .content | page.RenderString (dict "display" "block") }}
+      </div>
+    {{ end }}
+  </div>
+</div>
diff --git a/layouts/_shortcodes/tabs.markdown.md b/layouts/_shortcodes/tabs.markdown.md
new file mode 100644
index 000000000000..dc4f50c50fc7
--- /dev/null
+++ b/layouts/_shortcodes/tabs.markdown.md
@@ -0,0 +1,6 @@
+{{ with .Inner }}{{/* don't do anything, just call it */}}{{ end -}}
+{{ range (.Store.Get "tabs") -}}
+**{{ .name }}**
+
+{{ .content }}
+{{- end -}}
diff --git a/layouts/_shortcodes/whats-new.markdown.md b/layouts/_shortcodes/whats-new.markdown.md
new file mode 100644
index 000000000000..9689ff97dace
--- /dev/null
+++ b/layouts/_shortcodes/whats-new.markdown.md
@@ -0,0 +1,9 @@
+{{- $data := index hugo.Data "whats-new" -}}
+{{- with $data.items }}
+
+## What's new
+
+{{ range . }}
+{{ printf "- [%s: %s](%s): %s (%s)\n" .product .title .url .description (.published | time.Format "Jan 2, 2006") -}}
+{{ end }}
+{{- end }}
diff --git a/layouts/shortcodes/youtube-embed.html b/layouts/_shortcodes/youtube-embed.html
similarity index 100%
rename from layouts/shortcodes/youtube-embed.html
rename to layouts/_shortcodes/youtube-embed.html
diff --git a/layouts/_shortcodes/youtube-embed.markdown.md b/layouts/_shortcodes/youtube-embed.markdown.md
new file mode 100644
index 000000000000..3dde39c8c007
--- /dev/null
+++ b/layouts/_shortcodes/youtube-embed.markdown.md
@@ -0,0 +1 @@
+{{/* YouTube embed omitted from markdown output */}}
\ No newline at end of file
diff --git a/layouts/api-reference.html b/layouts/api-reference.html
new file mode 100644
index 000000000000..5767de1595f2
--- /dev/null
+++ b/layouts/api-reference.html
@@ -0,0 +1,700 @@
+{{/* Wide-mode API reference layout.
+
+  Reads the colocated *.yaml Page Resource, unmarshals it into a plain Hugo
+  map with transform.Unmarshal, and renders the OpenAPI 3 spec inline using
+  Docker docs styling. Overrides baseof's "main" block so the article spans
+  the full available width; the built-in right-rail TOC is replaced with a
+  custom endpoint navigator (partials/api-ref/nav.html) sticky-pinned to
+  the viewport.
+
+  $ref nodes are resolved on the fly through partials/api-ref/resolve.html;
+  no oapi-codegen or third-party JS runtime is involved.
+*/}}
+
+{{ define "main" }}
+  {{- $specRes := .Resources.GetMatch "*.yaml" -}}
+  {{- if not $specRes -}}
+    {{- errorf "api-reference: no .yaml resource found alongside %s" .File.Path -}}
+  {{- end -}}
+  {{- $api := $specRes | transform.Unmarshal -}}
+
+
+  <div class="flex w-full min-w-0 gap-8">
+    <div class="min-w-0 flex-1">
+      {{ partial "breadcrumbs.html" . }}
+      <h1 data-pagefind-weight="10" class="mb-2 text-3xl font-bold">
+        {{ .Title | safeHTML }}
+      </h1>
+      {{ with .Description }}
+        <p class="text-gray-600 dark:text-gray-400">{{ . }}</p>
+      {{ end }}
+      {{ template "api-ref-meta" (dict "api" $api "spec" $specRes) }}
+      {{ partialCached "md-dropdown.html" "-" "-" }}
+
+      {{ template "api-ref-overview" $api }}
+      {{ template "api-ref-auth" $api }}
+      {{ template "api-ref-tags" $api }}
+      {{ template "api-ref-schemas" $api }}
+    </div>
+
+    <aside class="hidden w-56 flex-none lg:block">
+      <nav
+        class="sticky top-20 max-h-[calc(100vh-6rem)] overflow-y-auto text-sm"
+      >
+        {{ partial "api-ref/nav.html" $api }}
+      </nav>
+    </aside>
+  </div>
+{{ end }}
+
+{{/* ── Meta strip: version, base URL, download link ──────────────────────── */}}
+{{ define "api-ref-meta" }}
+  {{- $api := .api -}}
+  {{- $spec := .spec -}}
+  <div class="mt-4 flex flex-wrap items-center gap-x-6 gap-y-2 text-sm">
+    {{- with $api.info }}
+      {{- with .version }}
+        <div>
+          <span class="font-medium text-gray-500 dark:text-gray-400"
+            >Version</span
+          >
+          <code
+            class="ml-1 rounded bg-gray-100 px-1.5 py-0.5 text-xs dark:bg-gray-800"
+            >{{ . }}</code
+          >
+        </div>
+      {{- end }}
+    {{- end }}
+    {{- range $api.servers }}
+      <div>
+        <span class="font-medium text-gray-500 dark:text-gray-400"
+          >Base URL</span
+        >
+        <code
+          class="ml-1 rounded bg-gray-100 px-1.5 py-0.5 text-xs text-blue-600 dark:bg-gray-800 dark:text-blue-400"
+          >{{ .url }}</code
+        >
+      </div>
+    {{- end }}
+    <a
+      href="{{ $spec.Permalink }}"
+      class="ml-auto text-blue-600 hover:underline dark:text-blue-400"
+      >Download OpenAPI specification</a
+    >
+  </div>
+{{ end }}
+
+{{/* ── Overview ─────────────────────────────────────────────────────────── */}}
+{{ define "api-ref-overview" }}
+  {{- $api := . -}}
+  {{- with $api.info }}
+    {{- with .description }}
+      <section class="mb-10">
+        <div class="prose dark:prose-invert max-w-none">
+          {{ . | markdownify }}
+        </div>
+      </section>
+    {{- end }}
+  {{- end }}
+{{ end }}
+
+{{/* ── Authentication ───────────────────────────────────────────────────── */}}
+{{ define "api-ref-auth" }}
+  {{- $api := . -}}
+  {{- with $api.components }}
+    {{- with .securitySchemes }}
+      <section class="mb-12">
+        <h2
+          id="authentication"
+          class="mb-4 scroll-mt-24 text-2xl font-semibold"
+        >
+          Authentication
+        </h2>
+        {{- range $name, $scheme := . }}
+          <div class="mb-4 flex flex-wrap items-center gap-x-4 gap-y-1 text-sm">
+            <code
+              class="rounded bg-gray-100 px-1.5 py-0.5 text-xs dark:bg-gray-800"
+              >{{ $name }}</code
+            >
+            {{- with $scheme.type }}
+              <span class="text-gray-500 dark:text-gray-400"
+                >type: <code class="text-xs">{{ . }}</code></span
+              >
+            {{- end }}
+            {{- with $scheme.scheme }}
+              <span class="text-gray-500 dark:text-gray-400"
+                >scheme: <code class="text-xs">{{ . }}</code></span
+              >
+            {{- end }}
+            {{- with $scheme.bearerFormat }}
+              <span class="text-gray-500 dark:text-gray-400"
+                >bearer format: <code class="text-xs">{{ . }}</code></span
+              >
+            {{- end }}
+          </div>
+          {{- with $scheme.description }}
+            <div class="prose dark:prose-invert max-w-none">
+              {{ . | markdownify }}
+            </div>
+          {{- end }}
+        {{- end }}
+      </section>
+    {{- end }}
+  {{- end }}
+{{ end }}
+
+{{/* ── Endpoints grouped by tag ─────────────────────────────────────────── */}}
+{{ define "api-ref-tags" }}
+  {{- $api := . -}}
+  {{- $paths := $api.paths -}}
+  {{- $methods := slice "get" "post" "put" "patch" "delete" -}}
+  {{- range $api.tags }}
+    {{- $tagName := .name -}}
+    <section class="mb-14">
+      <h2
+        id="tag-{{ $tagName | urlize }}"
+        class="mb-1 scroll-mt-24 text-2xl font-semibold"
+      >
+        {{ $tagName | title }}
+      </h2>
+      {{- with .description }}
+        <p class="mb-6 text-sm text-gray-500 dark:text-gray-400">{{ . }}</p>
+      {{- end }}
+
+      {{- range $path, $item := $paths }}
+        {{/* Resolve shared (path-level) parameters once. */}}
+        {{- $sharedParams := slice -}}
+        {{- with index $item "parameters" -}}
+          {{- range . -}}
+            {{- $p := partial "api-ref/resolve.html" (dict "api" $api "node" .) -}}
+            {{- $sharedParams = $sharedParams | append $p -}}
+          {{- end -}}
+        {{- end -}}
+
+        {{- range $methods -}}
+          {{- $method := . -}}
+          {{- with index $item $method -}}
+            {{- $op := . -}}
+            {{- if in $op.tags $tagName -}}
+              {{ template "api-ref-operation" (dict
+                "api" $api
+                "op" $op
+                "method" $method
+                "path" $path
+                "sharedParams" $sharedParams
+                )
+              }}
+            {{- end -}}
+          {{- end -}}
+        {{- end -}}
+      {{- end }}
+    </section>
+  {{- end }}
+{{ end }}
+
+{{/* ── Single operation card ────────────────────────────────────────────── */}}
+{{ define "api-ref-operation" }}
+  {{- $api := .api -}}
+  {{- $op := .op -}}
+  {{- $method := .method -}}
+  {{- $path := .path -}}
+  {{- $sharedParams := .sharedParams -}}
+
+  {{- $methodColors := dict
+    "get"    "bg-blue-100 text-blue-800 dark:bg-blue-900/40 dark:text-blue-300"
+    "post"   "bg-green-100 text-green-800 dark:bg-green-900/40 dark:text-green-300"
+    "put"    "bg-yellow-100 text-yellow-800 dark:bg-yellow-900/40 dark:text-yellow-300"
+    "patch"  "bg-yellow-100 text-yellow-800 dark:bg-yellow-900/40 dark:text-yellow-300"
+    "delete" "bg-red-100 text-red-800 dark:bg-red-900/40 dark:text-red-300"
+  -}}
+
+  {{- $anchor := "" -}}
+  {{- with $op.operationId -}}
+    {{- $anchor = printf "operation-%s" . -}}
+  {{- end -}}
+
+  {{- $curl := partial "api-ref/curl.html" (dict
+    "api" $api
+    "op" $op
+    "method" $method
+    "path" $path
+    "sharedParams" $sharedParams
+    )
+  -}}
+
+
+  <div
+    {{ with $anchor }}id="{{ . }}"{{ end }}
+    class="mb-8 scroll-mt-24 overflow-hidden rounded-lg border border-gray-200 dark:border-gray-700"
+  >
+    <div
+      class="flex flex-wrap items-center gap-3 border-b border-gray-200 bg-gray-50 px-4 py-3 dark:border-gray-700 dark:bg-gray-900"
+    >
+      <span
+        class="{{ index $methodColors $method }} inline-block rounded px-2 py-0.5 font-mono text-xs font-bold uppercase"
+        >{{ upper $method }}</span
+      >
+      <code class="font-mono text-sm">{{ $path }}</code>
+      <div class="ml-auto flex items-center gap-3">
+        {{- with $op.summary }}
+          <span class="text-sm font-medium text-gray-700 dark:text-gray-300"
+            >{{ . }}</span
+          >
+        {{- end }}
+        <button
+          x-data="{ copied: false }"
+          @click="navigator.clipboard.writeText({{ $curl | jsonify }}).then(() => { copied = true; setTimeout(() => copied = false, 2000) })"
+          :title="copied ? 'Copied!' : 'Copy as cURL'"
+          class="inline-flex cursor-pointer items-center gap-1 rounded border border-gray-200 bg-white px-2 py-1 text-xs font-medium text-gray-700 transition-colors hover:bg-gray-50 dark:border-gray-700 dark:bg-gray-800 dark:text-gray-300 dark:hover:bg-gray-700"
+        >
+          <span class="icon-svg icon-sm" x-show="!copied" x-cloak>
+            {{ partialCached "icon" "document-duplicate" "document-duplicate" }}
+          </span>
+          <span
+            class="icon-svg icon-sm text-green-600 dark:text-green-400"
+            x-show="copied"
+            x-cloak
+          >
+            {{ partialCached "icon" "check-circle" "check-circle" }}
+          </span>
+          <span x-text="copied ? 'Copied' : 'cURL'"></span>
+        </button>
+      </div>
+    </div>
+
+    <div class="p-5">
+      {{- with $op.description }}
+        <div class="prose dark:prose-invert prose-sm mb-5 max-w-none">
+          {{ . | markdownify }}
+        </div>
+      {{- end }}
+
+      {{ template "api-ref-params" (dict
+        "api" $api
+        "op" $op
+        "sharedParams" $sharedParams
+        )
+      }}
+
+      {{ template "api-ref-body" (dict "api" $api "op" $op) }}
+
+      {{ template "api-ref-responses" (dict "api" $api "op" $op) }}
+    </div>
+  </div>
+{{ end }}
+
+{{/* ── Parameters table (path + operation; in: path/query/header) ───────── */}}
+{{ define "api-ref-params" }}
+  {{- $api := .api -}}
+  {{- $op := .op -}}
+  {{- $params := .sharedParams -}}
+  {{- with index $op "parameters" -}}
+    {{- range . -}}
+      {{- $p := partial "api-ref/resolve.html" (dict "api" $api "node" .) -}}
+      {{- $params = $params | append $p -}}
+    {{- end -}}
+  {{- end -}}
+
+  {{- if $params }}
+    <div class="mb-5">
+      <h4
+        class="mb-2 text-xs font-semibold tracking-wider text-gray-500 uppercase dark:text-gray-400"
+      >
+        Parameters
+      </h4>
+      <table class="w-full border-collapse text-sm">
+        <thead>
+          <tr class="border-b border-gray-200 dark:border-gray-700">
+            <th
+              class="w-36 py-1.5 pr-4 text-left font-medium text-gray-700 dark:text-gray-300"
+            >
+              Name
+            </th>
+            <th
+              class="w-16 py-1.5 pr-4 text-left font-medium text-gray-700 dark:text-gray-300"
+            >
+              In
+            </th>
+            <th
+              class="w-20 py-1.5 pr-4 text-left font-medium text-gray-700 dark:text-gray-300"
+            >
+              Type
+            </th>
+            <th
+              class="w-20 py-1.5 pr-4 text-left font-medium text-gray-700 dark:text-gray-300"
+            >
+              Required
+            </th>
+            <th
+              class="py-1.5 text-left font-medium text-gray-700 dark:text-gray-300"
+            >
+              Description
+            </th>
+          </tr>
+        </thead>
+        <tbody>
+          {{- range $params }}
+            <tr
+              class="border-b border-gray-100 last:border-0 dark:border-gray-800"
+            >
+              <td class="py-1.5 pr-4 align-top">
+                <code class="rounded bg-gray-100 px-1 text-xs dark:bg-gray-800"
+                  >{{ .name }}</code
+                >
+              </td>
+              <td
+                class="py-1.5 pr-4 align-top text-xs text-gray-500 dark:text-gray-400"
+              >
+                {{ .in }}
+              </td>
+              <td
+                class="py-1.5 pr-4 align-top font-mono text-xs text-gray-500 dark:text-gray-400"
+              >
+                {{ template "api-ref-type" (dict "api" $api "schema" .schema) }}
+              </td>
+              <td
+                class="py-1.5 pr-4 align-top text-xs text-gray-500 dark:text-gray-400"
+              >
+                {{ if .required }}yes{{ else }}no{{ end }}
+              </td>
+              <td
+                class="py-1.5 align-top text-sm text-gray-600 dark:text-gray-400"
+              >
+                {{ with .description }}{{ . | markdownify }}{{ end }}
+              </td>
+            </tr>
+          {{- end }}
+        </tbody>
+      </table>
+    </div>
+  {{- end }}
+{{ end }}
+
+{{/* ── Request body ─────────────────────────────────────────────────────── */}}
+{{ define "api-ref-body" }}
+  {{- $api := .api -}}
+  {{- $op := .op -}}
+  {{- with $op.requestBody }}
+    {{- $body := partial "api-ref/resolve.html" (dict "api" $api "node" .) }}
+    <div class="mb-5">
+      <h4
+        class="mb-2 text-xs font-semibold tracking-wider text-gray-500 uppercase dark:text-gray-400"
+      >
+        Request body
+      </h4>
+      {{- with $body.description }}
+        <p class="mb-2 text-sm text-gray-600 dark:text-gray-400">
+          {{ . | markdownify }}
+        </p>
+      {{- end }}
+      {{- $ct := "" -}}
+      {{- $media := dict -}}
+      {{- range $name, $m := $body.content -}}
+        {{- if not $ct -}}{{- $ct = $name -}}{{- $media = $m -}}{{- end -}}
+      {{- end -}}
+      {{- if $ct }}
+        <p class="mb-2 text-xs text-gray-500 dark:text-gray-400">
+          Content type:
+          <code class="rounded bg-gray-100 px-1 dark:bg-gray-800"
+            >{{ $ct }}</code
+          >
+        </p>
+        {{ template "api-ref-schema-link" (dict "api" $api "schema" $media.schema) }}
+        {{ template "api-ref-examples" (dict
+          "examples" $media.examples
+          "prefix" "req"
+          )
+        }}
+      {{- end }}
+    </div>
+  {{- end }}
+{{ end }}
+
+{{/* ── Responses ────────────────────────────────────────────────────────── */}}
+{{ define "api-ref-responses" }}
+  {{- $api := .api -}}
+  {{- $op := .op -}}
+  {{- $statusColors := dict
+    "200" "bg-green-100 text-green-800 dark:bg-green-900/40 dark:text-green-300"
+    "201" "bg-green-100 text-green-800 dark:bg-green-900/40 dark:text-green-300"
+    "204" "bg-green-100 text-green-800 dark:bg-green-900/40 dark:text-green-300"
+    "400" "bg-yellow-100 text-yellow-800 dark:bg-yellow-900/40 dark:text-yellow-300"
+    "401" "bg-red-100 text-red-800 dark:bg-red-900/40 dark:text-red-300"
+    "403" "bg-red-100 text-red-800 dark:bg-red-900/40 dark:text-red-300"
+    "404" "bg-red-100 text-red-800 dark:bg-red-900/40 dark:text-red-300"
+    "409" "bg-yellow-100 text-yellow-800 dark:bg-yellow-900/40 dark:text-yellow-300"
+    "500" "bg-red-100 text-red-800 dark:bg-red-900/40 dark:text-red-300"
+  -}}
+  {{- with $op.responses }}
+    <div>
+      <h4
+        class="mb-2 text-xs font-semibold tracking-wider text-gray-500 uppercase dark:text-gray-400"
+      >
+        Responses
+      </h4>
+      <div class="space-y-2">
+        {{- range $code, $resp := . }}
+          {{- $r := partial "api-ref/resolve.html" (dict "api" $api "node" $resp) }}
+          <details
+            {{ if hasPrefix $code "2" }}open{{ end }}
+            class="group rounded border border-gray-200 dark:border-gray-700"
+          >
+            <summary
+              class="flex cursor-pointer list-none items-center gap-2 rounded-t bg-gray-50 px-3 py-2 dark:bg-gray-900 [&::-webkit-details-marker]:hidden"
+            >
+              <span
+                class="inline-block text-gray-400 transition-transform group-open:rotate-90 dark:text-gray-500"
+                >&#9656;</span
+              >
+              <span
+                class="{{ index $statusColors $code | default "bg-gray-100 text-gray-700 dark:bg-gray-800 dark:text-gray-300" }} inline-block rounded px-1.5 py-0.5 font-mono text-xs font-semibold"
+                >{{ $code }}</span
+              >
+              <span class="text-sm text-gray-600 dark:text-gray-400"
+                >{{ $r.description }}</span
+              >
+            </summary>
+            {{- $ct := "" -}}
+            {{- $media := dict -}}
+            {{- range $name, $m := $r.content -}}
+              {{- if not $ct -}}
+                {{- $ct = $name -}}{{- $media = $m -}}
+              {{- end -}}
+            {{- end -}}
+            {{- if $ct }}
+              <div class="px-3 pt-2 pb-3">
+                {{ template "api-ref-schema-link" (dict "api" $api "schema" $media.schema) }}
+                {{ template "api-ref-examples" (dict
+                  "examples" $media.examples
+                  "prefix" (printf "resp-%s" $code)
+                  )
+                }}
+              </div>
+            {{- end }}
+          </details>
+        {{- end }}
+      </div>
+    </div>
+  {{- end }}
+{{ end }}
+
+{{/* ── Example block with optional tabs ─────────────────────────────────── */}}
+{{ define "api-ref-examples" }}
+  {{- $examples := .examples -}}
+  {{- $prefix := .prefix -}}
+  {{- $tabs := slice -}}
+  {{- range $name, $ex := $examples -}}
+    {{- $tabs = $tabs | append (dict "name" $name "ex" $ex) -}}
+  {{- end -}}
+  {{- if $tabs }}
+    {{- $first := (index $tabs 0).name -}}
+    <div
+      {{ if gt (len $tabs) 1 }}x-data="{ tab: {{ $first | jsonify }} }"{{ end }}
+    >
+      {{- if gt (len $tabs) 1 }}
+        <div class="mb-2 flex flex-wrap gap-1">
+          {{- range $tabs }}
+            {{- $label := .name -}}
+            {{- with .ex.summary }}{{ $label = . }}{{ end -}}
+            <button
+              @click="tab = {{ .name | jsonify }}"
+              :class="tab === {{ .name | jsonify }} ? 'bg-blue-100 text-blue-800 dark:bg-blue-900/40 dark:text-blue-300' : 'bg-gray-100 text-gray-600 dark:bg-gray-800 dark:text-gray-400'"
+              class="rounded px-2 py-0.5 text-xs font-medium"
+            >
+              {{ $label }}
+            </button>
+          {{- end }}
+        </div>
+      {{- end }}
+      {{- range $tabs }}
+        <div
+          {{ if gt (len $tabs) 1 }}
+            x-show="tab === {{ .name | jsonify }}"
+          {{ end }}
+        >
+          {{- with .ex.value -}}
+            <div
+              class="syntax-light dark:syntax-dark not-prose overflow-hidden rounded border border-gray-200 dark:border-gray-700"
+            >
+              {{ highlight (. | jsonify (dict "indent" "  ")) "json" "" }}
+            </div>
+          {{- end }}
+        </div>
+      {{- end }}
+    </div>
+  {{- end }}
+{{ end }}
+
+{{/* ── Inline schema-reference link (used in body/response) ─────────────── */}}
+{{ define "api-ref-schema-link" }}
+  {{- $api := .api -}}
+  {{- $schema := .schema -}}
+  {{- if reflect.IsMap $schema -}}
+    {{- with index $schema "$ref" -}}
+      {{- $parts := split . "/" -}}
+      {{- $name := index $parts (sub (len $parts) 1) -}}
+      <p class="mb-2 text-xs text-gray-500 dark:text-gray-400">
+        Schema:
+        <a
+          href="#schema-{{ $name | urlize }}"
+          class="font-mono text-blue-600 hover:underline dark:text-blue-400"
+          >{{ $name }}</a
+        >
+      </p>
+    {{- end -}}
+  {{- end -}}
+{{ end }}
+
+{{/* ── Type rendering for parameter / property tables ───────────────────── */}}
+{{ define "api-ref-type" }}
+  {{- $api := .api -}}
+  {{- $schema := .schema -}}
+  {{- if not (reflect.IsMap $schema) -}}
+    —
+  {{- else -}}
+    {{- with index $schema "$ref" -}}
+      {{- $parts := split . "/" -}}
+      {{- $name := index $parts (sub (len $parts) 1) -}}
+      <a
+        href="#schema-{{ $name | urlize }}"
+        class="text-blue-600 hover:underline dark:text-blue-400"
+        >{{ $name }}</a
+      >
+    {{- else -}}
+      {{- with $schema.type -}}
+        {{- if eq . "array" -}}
+          array&lt;{{ template "api-ref-type" (dict "api" $api "schema" $schema.items) }}&gt;
+        {{- else -}}
+          {{ . }}
+        {{- end -}}
+      {{- else -}}
+        {{- if $schema.allOf -}}
+          object
+        {{- else if $schema.anyOf -}}
+          any
+        {{- else if $schema.oneOf -}}
+          any
+        {{- else -}}
+          —
+        {{- end -}}
+      {{- end -}}
+    {{- end -}}
+  {{- end -}}
+{{ end }}
+
+{{/* ── Schemas section ──────────────────────────────────────────────────── */}}
+{{ define "api-ref-schemas" }}
+  {{- $api := . -}}
+  {{- with $api.components -}}
+    {{- with .schemas }}
+      <section class="mb-12">
+        <h2 id="schemas" class="mb-6 scroll-mt-24 text-2xl font-semibold">
+          Schemas
+        </h2>
+        {{- range $name, $schema := . }}
+          <div
+            id="schema-{{ $name | urlize }}"
+            class="mb-8 scroll-mt-24 rounded border border-gray-200 p-4 dark:border-gray-700"
+          >
+            <h3 class="mb-1 font-mono text-base font-semibold">{{ $name }}</h3>
+            {{- with $schema.description }}
+              <div
+                class="prose dark:prose-invert prose-sm mb-3 max-w-none text-sm"
+              >
+                {{ . | markdownify }}
+              </div>
+            {{- end }}
+            {{- with $schema.enum }}
+              <p class="mb-3 text-sm text-gray-500 dark:text-gray-400">
+                Enum:
+                {{- range $i, $v := . -}}
+                  {{- if $i }},{{ end -}}
+                  <code
+                    class="rounded bg-gray-100 px-1 text-xs dark:bg-gray-800"
+                    >{{ $v }}</code
+                  >
+                {{- end -}}
+              </p>
+            {{- end }}
+            {{- with $schema.properties }}
+              {{ template "api-ref-properties" (dict
+                "api" $api
+                "schema" $schema
+                )
+              }}
+            {{- else }}
+              {{- with $schema.items }}
+                <p class="text-sm text-gray-500 dark:text-gray-400">
+                  Items:
+                  <span class="font-mono"
+                    >{{ template "api-ref-type" (dict "api" $api "schema" .) }}</span
+                  >
+                </p>
+              {{- end }}
+            {{- end }}
+          </div>
+        {{- end }}
+      </section>
+    {{- end }}
+  {{- end }}
+{{ end }}
+
+{{/* ── Property table for a schema ──────────────────────────────────────── */}}
+{{ define "api-ref-properties" }}
+  {{- $api := .api -}}
+  {{- $schema := .schema -}}
+  {{- $required := $schema.required | default slice -}}
+  <table class="w-full border-collapse text-sm">
+    <thead>
+      <tr class="border-b border-gray-200 dark:border-gray-700">
+        <th
+          class="w-40 py-1.5 pr-4 text-left font-medium text-gray-700 dark:text-gray-300"
+        >
+          Property
+        </th>
+        <th
+          class="w-32 py-1.5 pr-4 text-left font-medium text-gray-700 dark:text-gray-300"
+        >
+          Type
+        </th>
+        <th
+          class="w-20 py-1.5 pr-4 text-left font-medium text-gray-700 dark:text-gray-300"
+        >
+          Required
+        </th>
+        <th
+          class="py-1.5 text-left font-medium text-gray-700 dark:text-gray-300"
+        >
+          Description
+        </th>
+      </tr>
+    </thead>
+    <tbody>
+      {{- range $propName, $prop := $schema.properties }}
+        <tr class="border-b border-gray-100 last:border-0 dark:border-gray-800">
+          <td class="py-1.5 pr-4 align-top">
+            <code class="rounded bg-gray-100 px-1 text-xs dark:bg-gray-800"
+              >{{ $propName }}</code
+            >
+          </td>
+          <td
+            class="py-1.5 pr-4 align-top font-mono text-xs text-gray-500 dark:text-gray-400"
+          >
+            {{ template "api-ref-type" (dict "api" $api "schema" $prop) }}
+          </td>
+          <td
+            class="py-1.5 pr-4 align-top text-xs text-gray-500 dark:text-gray-400"
+          >
+            {{ if in $required $propName }}yes{{ else }}no{{ end }}
+          </td>
+          <td class="py-1.5 align-top text-sm text-gray-600 dark:text-gray-400">
+            {{- $resolved := partial "api-ref/resolve.html" (dict "api" $api "node" $prop) -}}
+            {{- with $resolved.description -}}
+              {{ . | markdownify }}
+            {{- end -}}
+          </td>
+        </tr>
+      {{- end }}
+    </tbody>
+  </table>
+{{ end }}
diff --git a/layouts/api-reference.markdown.md b/layouts/api-reference.markdown.md
new file mode 100644
index 000000000000..182a063d3cb1
--- /dev/null
+++ b/layouts/api-reference.markdown.md
@@ -0,0 +1,185 @@
+{{- /*
+  Markdown rendering of an OpenAPI reference page.
+
+  Mirrors the HTML api-reference layout: unmarshals the colocated YAML
+  Page Resource into a plain Hugo map and walks the spec to produce a
+  flat markdown document. Used by the "View Markdown" / "Copy Markdown"
+  actions and the .md alternate link.
+*/ -}}
+{{- $specRes := .Resources.GetMatch "*.yaml" -}}
+{{- $api := $specRes | transform.Unmarshal -}}
+{{- $methods := slice "get" "post" "put" "patch" "delete" -}}
+{{- $paths := $api.paths -}}
+# {{ .Title }}
+
+{{ with .Description }}{{ . }}{{ end }}
+
+{{ with $api.info }}
+{{- with .version }}- **Version**: `{{ . }}`
+{{ end -}}
+{{ end -}}
+{{- range $api.servers }}- **Base URL**: `{{ .url }}`
+{{ end }}
+- **OpenAPI specification**: [`{{ path.Base $specRes.RelPermalink }}`]({{ $specRes.Permalink }})
+
+{{ with $api.info }}{{ with .description }}{{ . }}{{ end }}{{ end }}
+
+{{ with $api.components }}{{ with .securitySchemes }}
+## Authentication
+
+{{ range $name, $scheme := . }}
+**`{{ $name }}`**{{ with $scheme.type }} — type: `{{ . }}`{{ end }}{{ with $scheme.scheme }}, scheme: `{{ . }}`{{ end }}{{ with $scheme.bearerFormat }}, bearer format: `{{ . }}`{{ end }}
+
+{{ with $scheme.description }}{{ . }}{{ end }}
+{{ end -}}
+{{ end }}{{ end }}
+
+{{- range $api.tags }}
+## {{ .name | title }}
+
+{{ with .description }}{{ . }}{{ end }}
+
+{{- $tagName := .name -}}
+{{- range $path, $item := $paths -}}
+  {{- $sharedParams := slice -}}
+  {{- with index $item "parameters" -}}
+    {{- range . -}}
+      {{- $p := partial "api-ref/resolve.html" (dict "api" $api "node" .) -}}
+      {{- $sharedParams = $sharedParams | append $p -}}
+    {{- end -}}
+  {{- end -}}
+  {{- range $methods -}}
+    {{- $method := . -}}
+    {{- with index $item $method -}}
+      {{- $op := . -}}
+      {{- if in $op.tags $tagName }}
+### `{{ upper $method }}` `{{ $path }}`
+
+{{ with $op.summary }}**{{ . }}**{{ end }}
+
+{{ with $op.description }}{{ . }}{{ end }}
+
+{{- $params := $sharedParams -}}
+{{- with index $op "parameters" -}}
+  {{- range . -}}
+    {{- $p := partial "api-ref/resolve.html" (dict "api" $api "node" .) -}}
+    {{- $params = $params | append $p -}}
+  {{- end -}}
+{{- end -}}
+{{ if $params }}
+**Parameters**
+
+{{ range $params -}}
+- `{{ .name }}` ({{ .in }}{{ with .schema }}{{ with .type }}, {{ . }}{{ end }}{{ end }}{{ if .required }}, required{{ end }}){{ with .description }} — {{ . | strings.TrimSpace }}{{ end }}
+{{ end }}
+{{- end }}
+
+{{- with $op.requestBody -}}
+  {{- $body := partial "api-ref/resolve.html" (dict "api" $api "node" .) }}
+**Request body**{{ with $body.description }} — {{ . | strings.TrimSpace }}{{ end }}
+
+{{- $ct := "" -}}
+{{- $media := dict -}}
+{{- range $n, $m := $body.content -}}
+  {{- if not $ct -}}{{- $ct = $n -}}{{- $media = $m -}}{{- end -}}
+{{- end -}}
+{{ if $ct }}
+Content type: `{{ $ct }}`
+
+{{ template "api-ref-md-schema-link" (dict "schema" $media.schema) }}
+{{ range $exName, $ex := $media.examples }}{{ with $ex.value }}
+```json
+{{ . | jsonify (dict "indent" "  ") }}
+```
+{{ end }}{{ end }}
+{{- end }}
+{{- end }}
+
+{{- with $op.responses }}
+**Responses**
+
+{{ range $code, $resp := . -}}
+{{- $r := partial "api-ref/resolve.html" (dict "api" $api "node" $resp) }}
+`{{ $code }}` — {{ with $r.description }}{{ . | strings.TrimSpace }}{{ end }}
+{{- $ct := "" -}}
+{{- $media := dict -}}
+{{- range $n, $m := $r.content -}}
+  {{- if not $ct -}}{{- $ct = $n -}}{{- $media = $m -}}{{- end -}}
+{{- end }}
+{{ if $ct }}
+{{ template "api-ref-md-schema-link" (dict "schema" $media.schema) }}
+{{ range $exName, $ex := $media.examples }}{{ with $ex.value }}
+```json
+{{ . | jsonify (dict "indent" "  ") }}
+```
+{{ end }}{{ end }}
+{{- end }}
+{{ end }}
+{{ end -}}
+
+      {{ end -}}
+    {{- end -}}
+  {{- end -}}
+{{- end }}
+{{- end }}
+
+{{- with $api.components }}{{ with .schemas }}
+## Schemas
+
+{{ range $name, $schema := . }}
+### `{{ $name }}`
+
+{{ with $schema.description }}{{ . | strings.TrimSpace }}{{ end }}
+
+{{ with $schema.enum -}}
+Enum: {{ range $i, $v := . }}{{ if $i }}, {{ end }}`{{ $v }}`{{ end }}
+{{ end }}
+
+{{- with $schema.properties }}
+{{- $required := $schema.required | default slice }}
+| Property | Type | Required | Description |
+| -------- | ---- | -------- | ----------- |
+{{ range $propName, $prop := . -}}
+| `{{ $propName }}` | {{ template "api-ref-md-type" $prop }} | {{ if in $required $propName }}yes{{ else }}no{{ end }} | {{ with $prop.description }}{{ . | strings.TrimSpace | strings.ReplaceRE "\\s*\\n\\s*" " " }}{{ end }} |
+{{ end }}
+{{ end -}}
+
+{{ end -}}
+{{ end }}{{ end }}
+
+{{- /* ── Helpers ───────────────────────────────────────────────────────── */ -}}
+
+{{- define "api-ref-md-type" -}}
+  {{- $s := . -}}
+  {{- if reflect.IsMap $s -}}
+    {{- with index $s "$ref" -}}
+      {{- $parts := split . "/" -}}
+      {{- $name := index $parts (sub (len $parts) 1) -}}
+      `{{ $name }}`
+    {{- else -}}
+      {{- with $s.type -}}
+        {{- if eq . "array" -}}
+          `array<`{{ template "api-ref-md-type" $s.items }}`>`
+        {{- else -}}
+          `{{ . }}`
+        {{- end -}}
+      {{- else -}}
+        {{- if $s.allOf -}}`object`
+        {{- else if or $s.anyOf $s.oneOf -}}`any`
+        {{- else -}}—{{- end -}}
+      {{- end -}}
+    {{- end -}}
+  {{- else -}}—{{- end -}}
+{{- end -}}
+
+{{- define "api-ref-md-schema-link" -}}
+  {{- $schema := .schema -}}
+  {{- $indent := .indent | default "" -}}
+  {{- if reflect.IsMap $schema -}}
+    {{- with index $schema "$ref" -}}
+      {{- $parts := split . "/" -}}
+      {{- $name := index $parts (sub (len $parts) 1) -}}
+{{ $indent }}Schema: `{{ $name }}`
+    {{- end -}}
+  {{- end -}}
+{{- end -}}
diff --git a/layouts/api.html b/layouts/api.html
new file mode 100644
index 000000000000..888f27d18584
--- /dev/null
+++ b/layouts/api.html
@@ -0,0 +1,122 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    {{ $specURL := urls.Parse (printf "/%s%s.yaml" .File.Dir .File.ContentBaseName) }}
+    <title>{{ printf "%s | %s" .Title site.Title }}</title>
+    <!-- needed for adaptive design -->
+    <meta name="viewport" content="width=device-width, initial-scale=1" />
+    <meta name="description" content="{{ .Description }}" />
+    <meta charset="utf-8" />
+    <link rel="canonical" href="{{ .Permalink }}" />
+    <link
+      rel="alternate"
+      href="{{ partial "utils/markdown-url.html" . }}"
+      type="text/markdown"
+      title="{{ .Title }} (Markdown)"
+    />
+    <!-- favicon -->
+    <link rel="icon" href="/assets/images/favicon-32x32.png" sizes="32x32" />
+    <link
+      rel="icon"
+      href="/assets/images/favicon-192x192.png"
+      sizes="192x192"
+    />
+    <link rel="apple-touch-icon" href="/apple-touch-icon.png" />
+    <link rel="shortcut icon" href="/favicon.ico" />
+    <!--
+  Provide a link to the swagger / OpenAPI spec itself. We're currently using
+  Swagger (OpenAPI v2) for some, so use a more generic "application/yaml" type.
+
+  Once all our specs are updated to OpenAPI v3, we can change this to "application/vnd.oai.openapi"
+  -->
+    <link
+      rel="alternate"
+      href="{{ $specURL.String | absURL }}"
+      type="application/yaml"
+      title="{{ .Title }} (Swagger/OpenAPI)"
+    />
+    {{ partial "schema.html" . }}
+    <style>
+      body {
+        margin: 0;
+        color: #1f2933;
+        font-family:
+          Roboto Flex,
+          Roboto,
+          sans-serif;
+        line-height: 1.5;
+      }
+
+      .menu-content > div:first-child {
+        background-color: #086dd7;
+        padding: 16px;
+      }
+
+      .auth-tag,
+      .pat,
+      .oat {
+        border-radius: 4px;
+        color: #fff;
+        padding: 5px;
+      }
+
+      .pat {
+        background-color: rgb(149, 80, 124);
+      }
+
+      .pat::after {
+        content: "personal access token";
+      }
+
+      .oat::after {
+        content: "org access token";
+      }
+
+      .oat {
+        background-color: rgb(24, 111, 175);
+      }
+
+      .auth-tag:not(:last-child) {
+        margin-right: 5px;
+      }
+
+      .redoc-container {
+        min-height: calc(100vh - 220px);
+      }
+    </style>
+  </head>
+
+  <body>
+    <main>
+      <article class="redoc-container">
+        <noscript>
+          <p style="padding: 32px 24px; max-width: 72ch">
+            This reference uses JavaScript for the interactive explorer. View
+            the
+            <a href="{{ partial "utils/markdown-url.html" . }}">Markdown page</a>
+            or
+            <a href="{{ $specURL.String | absURL }}"
+              >download the OpenAPI specification</a
+            >
+            if JavaScript is unavailable.
+          </p>
+        </noscript>
+        {{ if or (strings.HasPrefix .RelPermalink "/reference/api/hub/") (strings.HasPrefix .RelPermalink "/reference/api/registry/") }}
+          <redoc
+            spec-url="{{ $specURL.String }}"
+            suppress-warnings="true"
+            lazy-rendering
+          ></redoc>
+        {{ else }}
+          <redoc
+            spec-url="{{ $specURL.String }}"
+            hide-hostname="true"
+            suppress-warnings="true"
+            lazy-rendering
+          ></redoc>
+        {{ end }}
+      </article>
+    </main>
+    <script src="https://cdn.redoc.ly/redoc/latest/bundles/redoc.standalone.js"></script>
+  </body>
+</html>
diff --git a/layouts/api.markdown.md b/layouts/api.markdown.md
new file mode 100644
index 000000000000..012b44430c7f
--- /dev/null
+++ b/layouts/api.markdown.md
@@ -0,0 +1,8 @@
+{{- $specURL := urls.Parse (printf "/%s%s.yaml" .File.Dir .File.ContentBaseName) -}}
+# {{ .Title }}
+
+{{ .Content }}
+
+**OpenAPI Specification:** [{{ .Title }} API Spec]({{ $specURL.String | absURL }})
+
+This page provides interactive API documentation. For the machine-readable OpenAPI specification, see the link above.
diff --git a/layouts/baseof.html b/layouts/baseof.html
new file mode 100644
index 000000000000..823d4a087912
--- /dev/null
+++ b/layouts/baseof.html
@@ -0,0 +1,99 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    {{ partial "head.html" . }}
+  </head>
+
+  <body
+    class="dark:bg-navbar-bg-dark bg-navbar-bg flex flex-col items-center text-base text-black dark:text-white"
+  >
+    {{ partial "header.html" . }}
+    {{ partial "gordon-chat.html" . }}
+    <main class="relative flex w-full max-w-[1920px]">
+      <!-- Sidebar -->
+      <div
+        style="scroll-behavior: smooth;"
+        x-data
+        x-init="$nextTick(() => {
+          const container = $el; // The div with overflow
+          const item = document.getElementById('sidebar-current-page')
+          if (item) {
+              const containerTop = container.scrollTop;
+              const containerBottom = containerTop + container.clientHeight;
+
+              const itemTop = item.offsetTop - container.offsetTop;
+              const itemBottom = itemTop + item.offsetHeight;
+
+              // Scroll only if the item is out of view
+              if (itemBottom > containerBottom - 200) {
+                  container.scrollTop = itemTop - (container.clientHeight / 2 - item.offsetHeight / 2);
+              }
+          }
+      })"
+        class="bg-background-toc dark:bg-background-toc fixed top-0 z-40 hidden h-screen w-full flex-none overflow-x-hidden overflow-y-auto{{ if ne .Type "guides" }} md:sticky md:top-16 md:z-auto md:block md:h-[calc(100vh-64px)] md:w-[320px]{{ end }}"
+        :class="{ 'hidden': ! $store.showSidebar }"
+      >
+        <!-- Gray backdrop on small screens -->
+        <div
+          class="fixed bg-black/50 md:hidden"
+          x-show="$store.showSidebar"
+          @click="openSidebar = false"
+          x-transition.opacity
+        ></div>
+        <div
+          class="bg-background-toc dark:bg-background-toc z-50 w-full p-3 md:block md:w-[300px]"
+        >
+          <!-- Collapse button for small screens -->
+          <button class="my-4 md:hidden" @click="$store.showSidebar = false">
+            <span class="icon-svg"
+              >{{ partialCached "icon" "arrow-left" "arrow-left" }}</span
+            >
+            Back
+          </button>
+          <!-- Actual Sidebar Content -->
+          {{ block "left" . }}
+            {{ partial "sidebar/mainnav.html" . }}
+            {{ partial "sidebar/sections.html" . }}
+          {{ end }}
+        </div>
+      </div>
+
+      <!-- Main content -->
+      <div
+        {{ if ne .Params.sitemap false }}data-pagefind-body{{- end }}
+        class="dark:bg-background-dark w-full min-w-0 bg-white p-8"
+      >
+        {{ partial "pagefind-meta.html" . }}
+        {{ block "main" . }}
+          <div class="flex w-full gap-8">
+            <div class="min-w-0 flex-[2_2_0%]">
+              {{ block "article" . }}
+                <article class="prose dark:prose-invert max-w-4xl">
+                  {{ partial "content-default.html" . }}
+                </article>
+              {{ end }}
+            </div>
+            {{ block "right" . }}
+              <div class="-mt-8 hidden min-w-48 flex-1 lg:block">
+                {{ partial "aside.html" . }}
+              </div>
+            {{ end }}
+          </div>
+        {{ end }}
+      </div>
+    </main>
+
+    <footer class="relative z-10 w-full">
+      {{ partialCached "footer.html" . }}
+    </footer>
+
+    {{/* Load the YouTube player if the page embeds a YouTube video */}}
+    {{ with .Store.Get "youtube" }}
+      {{ partialCached "youtube-script.html" "-" "-" }}
+    {{ end }}
+    {{/* Load mermaid if the page contains a mermaid code block */}}
+    {{ with .Store.Get "mermaid" }}
+      {{ partialCached "mermaid-script.html" "-" "-" }}
+    {{ end }}
+  </body>
+</html>
diff --git a/layouts/_default/cli.html b/layouts/cli.html
similarity index 84%
rename from layouts/_default/cli.html
rename to layouts/cli.html
index 1a5b0fad8a5d..19c5c1691782 100644
--- a/layouts/_default/cli.html
+++ b/layouts/cli.html
@@ -1,16 +1,14 @@
-{{ define "main" }}
-  {{ $data := "" }}
-  {{ if .Params.datafolder }}
-    {{ $data = index (index site.Data .Params.datafolder) .Params.datafile }}
-  {{ else }}
-    {{ $data = index site.Data .Params.datafile }}
-  {{ end }}
+{{ define "article" }}
+  {{ $data := index hugo.Data.cli .Params.datafolder .Params.datafile }}
+
   {{ .Store.Set "headings" slice }}
   {{ .Store.Set "subheadings" slice }}
-  <div class="flex w-full">
-    <article class="prose min-w-0 flex-[2_2_0%] max-w-4xl dark:prose-invert">
+  <article class="prose min-w-0 max-w-4xl dark:prose-invert">
     {{ partial "breadcrumbs.html" . }}
-    <h1 class="scroll-mt-36">{{ .Title }}</h1>
+    <h1>{{ .Title }}</h1>
+    <div class="hidden lg:block">
+      {{ partialCached "md-dropdown.html" "-" "-" }}
+    </div>
     <div class="overflow-x-auto">
       <table>
         <tbody>
@@ -45,7 +43,6 @@ <h1 class="scroll-mt-36">{{ .Title }}</h1>
         </tbody>
       </table>
     </div>
-    {{ .Content }}
     {{ if $data.deprecated }}
       {{ markdownify `
 > [!WARNING]
@@ -56,17 +53,18 @@ <h1 class="scroll-mt-36">{{ .Title }}</h1>
       }}
     {{ end }}
     {{ if or $data.experimental $data.experimentalcli }}
-      {{ markdownify `
-{{% experimental %}}
-
-**This command is experimental.**
-
-Experimental features are intended for testing and feedback as their
-functionality or design may change between releases without warning or
-can be removed entirely in a future release.
-
-{{% /experimental %}}`
-      }}
+      <div class="px-4 border-l-2 border-l-magenta-light dark:border-l-magenta-dark">
+        <p class="not-prose flex gap-2 items-center text-magenta-light dark:text-magenta-dark">
+          <span class="icon-svg pb-1">{{ partialCached "icon" "beaker" "beaker" }}</span>
+          <strong>{{ i18n "experimental" }}</strong>
+        </p>
+        <p><strong>This command is experimental.</strong></p>
+        <p>
+          Experimental features are intended for testing and feedback as their
+          functionality or design may change between releases without warning or
+          can be removed entirely in a future release.
+        </p>
+      </div>
     {{ end }}
     {{ with $data.kubernetes }}
       <p>
@@ -100,7 +98,7 @@ <h1 class="scroll-mt-36">{{ .Title }}</h1>
         {{ $.Store.Add "headings" $heading }}
         <div class="overflow-x-auto">
           <table>
-            <thead class="bg-gray-light-100 dark:bg-gray-dark-200">
+            <thead class="bg-gray-100 dark:bg-gray-800">
               <tr>
                 <th class="p-2">Option</th>
                 <th class="p-2">Default</th>
@@ -135,10 +133,10 @@ <h1 class="scroll-mt-36">{{ .Title }}</h1>
                       {{ partialCached "components/badge.html" (dict "color" "red" "content" "Deprecated") "deprecated" }}
                     {{ end }}
                     {{ with .experimental }}
-                      {{ partialCached "components/badge.html" (dict "color" "amber" "content" "experimental (daemon)") "exp" }}
+                      {{ partialCached "components/badge.html" (dict "color" "violet" "content" "experimental (daemon)") "exp" }}
                     {{ end }}
                     {{ with .experimentalcli }}
-                      {{ partialCached "components/badge.html" (dict "color" "amber" "content" "experimental (CLI)") "exp-cli" }}
+                      {{ partialCached "components/badge.html" (dict "color" "violet" "content" "experimental (CLI)") "exp-cli" }}
                     {{ end }}
                     {{ with .kubernetes }}
                       {{ partialCached "components/badge.html" (dict "color" "blue" "content" "Kubernetes") "k8s" }}
@@ -186,7 +184,7 @@ <h1 class="scroll-mt-36">{{ .Title }}</h1>
             {{- if and .Params.datafolder .Params.datafile }}
               <tr>
                 <td class="text-left"><a class="link" href="{{ .Permalink }}"><code>{{ .Title }}</code></a></th>
-                {{ $data := index (index site.Data .Params.datafolder) .Params.datafile }}
+                {{ $data := index hugo.Data.cli .Params.datafolder .Params.datafile }}
                 <td class="text-left">{{ $data.short }}</th>
               </tr>
             {{- end }}
@@ -196,10 +194,11 @@ <h1 class="scroll-mt-36">{{ .Title }}</h1>
     {{ end }}
   </article>
 
-  <div class="hidden flex-1 min-w-52 lg:block">
-    <aside
-      class="sticky top-16 h-[calc(100vh-64px)] min-w-52 space-y-4 overflow-y-auto py-4 w-full"
-      >
+{{ end }}
+
+{{ define "right" }}
+  <div class="hidden min-w-52 flex-1 lg:block">
+    <aside class="sticky top-16 h-[calc(100vh-64px)] min-w-52 space-y-4 overflow-y-auto py-4 w-full">
       <div id="TableOfContents">
         <div class="text-lg pb-2">{{ T "tableOfContents" }}</div>
         <nav class="toc">
@@ -224,5 +223,4 @@ <h1 class="scroll-mt-36">{{ .Title }}</h1>
       </div>
     </aside>
   </div>
-
 {{ end }}
diff --git a/layouts/cli.markdown.md b/layouts/cli.markdown.md
new file mode 100644
index 000000000000..c1637d6aaaee
--- /dev/null
+++ b/layouts/cli.markdown.md
@@ -0,0 +1,49 @@
+{{- $data := index hugo.Data.cli .Params.datafolder .Params.datafile -}}
+# {{ .Title }}
+
+{{ with $data.short }}**Description:** {{ . }}{{ end }}
+
+{{ with $data.usage }}**Usage:** `{{ . }}`{{ end }}
+
+{{ with $data.aliases }}{{ $aliases := strings.Replace . (printf "%s, " $.Title) "" }}**Aliases:** {{ range $i, $alias := (strings.Split $aliases ", ") }}{{ if $i }}, {{ end }}`{{ $alias }}`{{ end }}{{ end }}
+
+{{ if $data.deprecated }}> [!WARNING]
+> **Deprecated**
+>
+> This command is deprecated. It may be removed in a future Docker version.
+{{ end }}
+
+{{ if or $data.experimental $data.experimentalcli }}> [!NOTE]
+> **Experimental**
+>
+> This command is experimental. Experimental features are intended for testing and feedback as their functionality or design may change between releases without warning or can be removed entirely in a future release.
+{{ end }}
+
+{{ with $data.kubernetes }}**Orchestrator:** Kubernetes{{ end }}
+{{ with $data.swarm }}**Orchestrator:** Swarm{{ end }}
+
+{{ with $data.long }}## Description
+
+{{ . }}
+{{ end }}
+
+{{ with $data.options }}{{ $opts := where . "hidden" false }}{{ with $opts }}## Options
+
+| Option | Default | Description |
+|--------|---------|-------------|
+{{ range . }}{{ $short := .shorthand }}{{ $long := .option }}| {{ with $short }}`-{{ . }}`, {{ end }}`--{{ $long }}` | {{ with .default_value }}{{ $skipDefault := `[],map[],false,0,0s,default,'',""` }}{{ cond (in $skipDefault .) "" (printf "`%s`" .) }}{{ end }} | {{ with .min_api_version }}API {{ . }}+{{ end }}{{ with .deprecated }} **Deprecated**{{ end }}{{ with .experimental }} **experimental (daemon)**{{ end }}{{ with .experimentalcli }} **experimental (CLI)**{{ end }}{{ with .kubernetes }} **Kubernetes**{{ end }}{{ with .swarm }} **Swarm**{{ end }}{{ if .description }} {{ strings.Replace .description "\n" "<br>" }}{{ end }} |
+{{ end }}
+{{ end }}{{ end }}
+
+{{ with $data.examples }}## Examples
+
+{{ . }}
+{{ end }}
+
+{{ if eq .Kind "section" }}## Subcommands
+
+| Command | Description |
+|---------|-------------|
+{{ range .Pages }}{{ if and .Params.datafolder .Params.datafile }}{{ $subdata := index hugo.Data.cli .Params.datafolder .Params.datafile }}| [`{{ .Title }}`]({{ .Permalink }}) | {{ $subdata.short }} |
+{{ end }}{{ end }}
+{{ end }}
diff --git a/layouts/glossary.html b/layouts/glossary.html
new file mode 100644
index 000000000000..eddffb810b44
--- /dev/null
+++ b/layouts/glossary.html
@@ -0,0 +1,30 @@
+{{ define "article" }}
+  <article class="prose max-w-none dark:prose-invert">
+    {{ partial "breadcrumbs.html" . }}
+    {{ with .Title }}
+    <h1 class="scroll-mt-36">{{ . }}</h1>
+    {{ end }}
+    {{ with .Content }}
+      {{ . }}
+    {{ end }}
+    <table>
+      <thead>
+        <tr>
+          <th>Term</th>
+          <th>Definition</th>
+        </tr>
+      </thead>
+      <tbody>
+        {{ range $term, $definition := hugo.Data.glossary }}
+          <tr>
+            <td class="not-prose">
+              <a class="-top-16 relative" name="{{ $term | anchorize }}"></a>
+              {{ $term }}
+            </td>
+            <td>{{ $definition | $.RenderString }}</td>
+          </tr>
+        {{ end }}
+      </tbody>
+    </table>
+  </article>
+{{ end }}
diff --git a/layouts/guides/landing.html b/layouts/guides/landing.html
index 0d45c31c9358..4b54e9447039 100644
--- a/layouts/guides/landing.html
+++ b/layouts/guides/landing.html
@@ -1,224 +1,218 @@
 {{ define "left" }}
-{{- partial "sidebar/mainnav.html" . }}
-<div class="p-4 flex flex-col gap-2 text-sm">
-  <p>Filter guides by tag or programming language.<p>
-  <div class="space-y-4" x-data="{
-      filters: { tags: [], languages: [] },
-      toggleFilter(grp, tag) {
-        this.filters[grp].includes(tag)
-          ? this.filters[grp] = this.filters[grp].filter(el => el != tag)
-          : this.filters[grp].push(tag);
-
-        // Update URL
-        const url = new URL(window.location.href);
-        if (this.filters[grp].length > 0) {
-          url.searchParams.set(grp, this.filters[grp].join('~'));
-        } else {
-          url.searchParams.delete(grp);
-        }
-        window.history.replaceState({}, '', url);
-
-        this.$dispatch('guide-filter', { filters: this.filters });
-      },
-      
-      init() {
-        const url = new URL(window.location.href);
-        const tags = url.searchParams.get('tags')
-        const langs = url.searchParams.get('languages')
-        if (tags != null) {
-          this.filters['tags'] = tags.split('~');
-        }
-        if (langs != null) {
-          this.filters['languages'] = langs.split('~');
-        }
-      }
-    }" @guide-filter.window="filters = $event.detail.filters;">
-    <div class="pl-2"><strong>Tags</strong></div>
-    <fieldset class="flex flex-col gap-2">
-      {{- range $name, $taxonomy := where site.Taxonomies.tags ".Page.Type" "guides" }}
-        {{- $id := anchorize (fmt.Printf "tag-%s" $name) }}
-        <div class="pl-2 flex gap-2">
-          <input value="{{ $name }}" type="checkbox" id="{{ $id }}" @change="toggleFilter('tags', '{{ $name }}')"
-            :checked="filters['tags'].includes('{{ $name }}')">
-          <label class="select-none" for="{{ $id }}">{{ .Page.LinkTitle }}</label>
-        </div>
-      {{ end }}
-    </fieldset>
-    <div class="pl-2"><strong>Languages</strong></div>
-    <fieldset class="pl-2 flex flex-wrap gap-2">
-      {{- range $name, $taxonomy := where site.Taxonomies.languages ".Page.Type" "guides" }}
-        {{- $id := anchorize (fmt.Printf "lang-%s" $name) }}
-        <button
-          class="px-2 py-1 rounded-full flex gap-1 bg-white dark:bg-gray-dark-300 border border-divider-light dark:border-divider-dark"
-          :class="{ 'ring-2 ring-blue-light-400 dark:ring-blue-dark-400': filters['languages'].includes('{{ $name }}') }"
-          @click="toggleFilter('languages', '{{ $name }}')">
-          <img height="18" width="18" title="{{ .Page.LinkTitle }}" src="{{ .Page.Params.icon }}">
-          <span>{{ .Page.LinkTitle }}</span>
-        </button>
-      {{ end }}
-    </fieldset>
-  </div>
-</div>
+  {{- partial "sidebar/mainnav.html" . }}
 {{ end }}
 
 {{ define "main" }}
-<div class="flex gap-8 w-full">
-  <article class="prose min-w-0 max-w-none dark:prose-invert">
-    {{- partial "breadcrumbs.html" . }}
-    <h1 data-pagefind-weight="10" class="scroll-mt-36">{{ .Title }}</h1>
-    {{ .Content }}
-    <div class="not-prose min-h-screen" x-data="{
-        filters: { tags: [], languages: [] },
-        hidden: [],
-        total: {{ len .Pages }},
-
-        noFilters() {
-          return Object.values(this.filters).every(arr=> Array.isArray(arr) && arr.length === 0);
-        },
+  {{- $tagOrder := slice "languages" "ai" "testing" "cicd" "security" "databases" "deployment" "admin" "labs" }}
 
-        isVisible(el) {
-          return !this.hidden.includes(el.id);
-        },
-
-        updateVisible() {
-          const hiddenSet = new Set();
-          // show if no filters have been selected
-          if (this.noFilters()) {
-            this.hidden = [];
-            return;
-          };
-          const guideContainer = this.$refs['guide-container'];
-          const guides = guideContainer.children
+  <div
+    class="not-prose mx-auto flex min-h-[calc(100dvh-7rem)] max-w-7xl flex-col"
+    x-data="{
+      query: '',
+      tagFilter: '',
+      words() { return this.query.trim().toLowerCase().split(/\s+/).filter(Boolean) },
+      textFiltering() { return this.query.trim().length > 0 },
+      filtering() { return this.textFiltering() || this.tagFilter !== '' },
+      matchText(text) { return this.words().every(w => text.includes(w)) },
+      rowVisible(el) { return !this.textFiltering() || this.matchText(el.dataset.search) },
+      sectionVisible(el) {
+        if (this.tagFilter) return el.dataset.tag === this.tagFilter;
+        if (this.textFiltering()) return Array.from(el.querySelectorAll('[data-guide]')).some(r => this.matchText(r.dataset.search));
+        return true;
+      },
+      resultCount() {
+        if (this.tagFilter) return document.querySelectorAll('section[data-tag=' + this.tagFilter + '] [data-guide]').length;
+        return Array.from(document.querySelectorAll('[data-guide]')).filter(r => this.matchText(r.dataset.search)).length;
+      },
+      selectTag(tag) { this.tagFilter = this.tagFilter === tag ? '' : tag; this.query = ''; window.scrollTo({ top: 0, behavior: 'smooth' }); },
+      clear() { this.query = ''; this.tagFilter = ''; }
+    }"
+  >
+    {{- partial "breadcrumbs.html" . }}
 
-          // Loop over the filters object
-          for (const [key, value] of Object.entries(this.filters)) {
-            if (!value || value.length === 0) continue;
+    <div class="mt-4">
+      <h1
+        data-pagefind-weight="10"
+        class="scroll-mt-36 text-5xl font-bold tracking-tight"
+      >
+        Guides
+      </h1>
+      {{- with .Description }}
+        <p class="mt-3 text-lg text-gray-500 dark:text-gray-400">{{ . }}</p>
+      {{- end }}
+    </div>
 
-            for (const g of guides) {
-              // Get the dataset for the current guide (e.g., languages or tags)
-              const terms = JSON.parse(g.dataset[key]);
+    <!-- Text filter -->
+    <div class="relative mt-8 mb-10 max-w-xl">
+      <span
+        class="icon-svg icon-sm pointer-events-none absolute top-1/2 left-3.5 -translate-y-1/2 text-gray-400 dark:text-gray-500"
+      >
+        {{ partialCached "icon" "magnifying-glass" "magnifying-glass" }}
+      </span>
+      <input
+        type="search"
+        x-model="query"
+        @input="tagFilter = ''"
+        @keydown.escape="clear()"
+        aria-label="Filter guides"
+        placeholder="Filter guides by name, topic, or tag…"
+        class="w-full rounded-xl border border-gray-300 bg-white py-2.5 pr-10 pl-11 text-sm text-gray-900 shadow-sm transition placeholder:text-gray-400 focus:border-blue-400 focus:ring-2 focus:ring-blue-400/40 focus:outline-none dark:border-gray-700 dark:bg-gray-900 dark:text-gray-100 dark:placeholder:text-gray-500"
+      />
+      <button
+        x-show="query"
+        x-cloak
+        @click="clear()"
+        aria-label="Clear filter"
+        class="icon-svg icon-sm absolute top-1/2 right-2.5 -translate-y-1/2 rounded-md p-1 text-gray-400 transition hover:bg-gray-100 hover:text-gray-700 dark:hover:bg-gray-800 dark:hover:text-gray-200"
+      >
+        {{ partialCached "icon" "x-mark" "x-mark" }}
+      </button>
+    </div>
 
-              // Check if any of the filter values exist in the terms
-              const containsSome = terms.some(term => this.filters[key].includes(term));
+    <div class="flex flex-1 gap-16 xl:gap-24">
+      <!-- Sticky topic filter -->
+      <nav class="sticky top-20 hidden w-52 flex-none flex-col self-start text-gray-500 xl:flex dark:text-gray-400">
+        <p class="mb-3 text-xs font-semibold tracking-widest text-gray-400 uppercase dark:text-gray-500">
+          Browse
+        </p>
+        <button
+          type="button"
+          @click="clear()"
+          class="flex items-center justify-between py-1.5 text-left text-sm transition-colors"
+          :class="!filtering() ? 'text-black dark:text-white font-medium' : 'text-gray-500 dark:text-gray-400 hover:text-gray-900 dark:hover:text-gray-100'"
+        >
+          <span class="flex items-center gap-2.5">
+            <span>All guides</span>
+          </span>
+          <span class="text-xs tabular-nums text-gray-300 dark:text-gray-600">{{ len .RegularPagesRecursive }}</span>
+        </button>
+        {{- range $i, $tag := $tagOrder }}
+          {{- $tagData := index hugo.Data.tags $tag }}
+          {{- $pages := where $.RegularPagesRecursive "Params.tags" "intersect" (slice $tag) }}
+          {{- if $pages }}
+            <button
+              type="button"
+              @click="selectTag('{{ $tag }}')"
+              class="flex items-center justify-between py-1.5 text-left text-sm transition-colors"
+              :class="tagFilter === '{{ $tag }}' ? 'text-black dark:text-white font-medium' : 'text-gray-500 dark:text-gray-400 hover:text-gray-900 dark:hover:text-gray-100'"
+            >
+              <span class="flex items-center gap-2.5">
+                <span>{{ $tagData.title }}</span>
+              </span>
+              <span class="text-xs tabular-nums text-gray-300 dark:text-gray-600">{{ len $pages }}</span>
+            </button>
+          {{- end }}
+        {{- end }}
+      </nav>
 
-              // If none of the terms match the filter, mark the guide as hidden
-              if (!containsSome) {
-                hiddenSet.add(g.id)
-              }
-            }
-          }
+      <!-- Guide list -->
+      <div
+        class="min-w-0 flex-1"
+        :class="{ 'guides-flat': filtering() }"
+      >
+        <!-- Featured: curated highlights, shown only in the default view -->
+        {{- $featured := where $.RegularPagesRecursive "Params.featured" true }}
+        {{- with $featured }}
+          <div x-show="!filtering()" class="mb-12">
+            <p class="mb-4 flex items-center gap-1.5 text-xs font-semibold tracking-widest text-gray-400 uppercase dark:text-gray-500">
+              <span class="icon-svg icon-sm text-blue-500">{{ partialCached "icon" "star" "star" }}</span>
+              Featured
+            </p>
+            <div class="grid gap-4 sm:grid-cols-2 xl:grid-cols-3">
+              {{- range .ByWeight }}
+                <a
+                  href="{{ .Permalink }}"
+                  class="group flex flex-col gap-1.5 rounded-lg border border-gray-200 p-4 transition-colors hover:border-gray-300 dark:border-gray-800 dark:hover:border-gray-700"
+                >
+                  <span class="font-medium leading-snug text-gray-900 transition-colors group-hover:text-blue-600 dark:text-gray-100 dark:group-hover:text-blue-400">{{ .Title }}</span>
+                  <span class="line-clamp-2 text-sm leading-relaxed text-gray-500 dark:text-gray-400">{{ .Summary }}</span>
+                </a>
+              {{- end }}
+            </div>
+          </div>
+        {{- end }}
 
-          this.hidden = Array.from(hiddenSet)
-        },
+        <!-- Filtering meta bar -->
+        <div
+          x-show="filtering()"
+          x-cloak
+          class="mb-8 flex items-center justify-between border-b border-gray-200 pb-4 dark:border-gray-800"
+        >
+          <p class="text-sm text-gray-500 dark:text-gray-400">
+            <span class="font-semibold text-gray-900 dark:text-gray-100" x-text="resultCount()"></span>
+            of {{ len .RegularPagesRecursive }} guides
+          </p>
+          <button
+            @click="clear()"
+            class="text-sm font-medium text-blue-600 transition hover:underline dark:text-blue-400"
+          >
+            Clear filter
+          </button>
+        </div>
 
-        init() {
-          const url = new URL(window.location.href);
-          const tags = url.searchParams.get('tags')
-          const langs = url.searchParams.get('languages')
-          if (tags != null) {
-            this.filters['tags'] = tags.split('~');
-          }
-          if (langs != null) {
-            this.filters['languages'] = langs.split('~');
-          }
-          this.updateVisible();
-        }
-      }" x-cloak
-         @guide-filter.window="filters = $event.detail.filters; updateVisible(); $nextTick(() => { window.scrollTo({ top: 0 }) })">
-      <div x-show="noFilters()">
-        <h2>Featured guides</h2>
-        <div class="not-prose py-4 grid grid-cols-1 lg:grid-cols-2 xl:grid-cols-3 gap-8">
-          {{- $featured := where .Pages "Params.featured" true }}
-          {{- with $featured }}
-            {{- range . }}
-              <div class="flex flex-col h-full">
-                <a class="hover:underline" href="{{ .Permalink }}">
-                  {{- $img := resources.Get (.Params.image | default "/images/thumbnail.webp") }}
-                  {{- $img = $img.Process "resize 600x" }}
-                  <img class="h-48 w-full object-cover rounded shadow" src="{{ $img.Permalink }}">
-                  <p class="text-xl leading-snug my-4">{{ .Title }}</p>
-                </a>
-                <p class="flex-grow text-sm">{{ .Summary }}</p>
-                <div class="mt-4">
-                  {{ template "guide-metadata" . }}
-                </div>
+        {{- range $i, $tag := $tagOrder }}
+          {{- $tagData := index hugo.Data.tags $tag }}
+          {{- $pages := where $.RegularPagesRecursive "Params.tags" "intersect" (slice $tag) }}
+          {{- if $pages }}
+            <section
+              id="{{ $tag }}"
+              data-tag="{{ $tag }}"
+              x-show="sectionVisible($el)"
+              class="scroll-mt-16 border-t border-gray-200 py-12 first:border-t-0 first:pt-0 dark:border-gray-800"
+            >
+              <div class="mb-6" x-show="!filtering()">
+                <p class="mb-1 text-xs font-semibold tracking-widest text-gray-400 uppercase dark:text-gray-500">
+                  {{- printf "%02d" (add $i 1) -}}
+                </p>
+                <h2 class="text-2xl font-bold">{{ $tagData.title }}</h2>
+                {{- with $tagData.description }}
+                  <p class="mt-1 text-gray-500 dark:text-gray-400">{{ . }}</p>
+                {{- end }}
+              </div>
+              <div class="divide-y divide-gray-200 dark:divide-gray-800">
+                {{- range $pages }}
+                  {{- $tagTitles := slice }}
+                  {{- range .Params.tags }}{{ $tagTitles = $tagTitles | append (index hugo.Data.tags .).title }}{{ end }}
+                  {{- $search := lower (printf "%s %s %s %s" .Title .Summary (delimit .Params.tags " ") (delimit $tagTitles " ")) }}
+                  {{- $search = $search | replaceRE "\\s+" " " }}
+                  <div
+                    data-guide
+                    data-search="{{ $search }}"
+                    x-show="rowVisible($el)"
+                    class="grid grid-cols-[5fr_6fr] items-start gap-6 py-4"
+                  >
+                    <a
+                      href="{{ .Permalink }}"
+                      class="font-medium leading-snug text-gray-900 hover:underline dark:text-gray-100"
+                    >{{ .Title }}</a>
+                    <span class="text-sm leading-relaxed text-gray-500 dark:text-gray-400">{{ .Summary }}</span>
+                  </div>
+                {{- end }}
               </div>
-            {{- end }}
+            </section>
           {{- end }}
-        </div>
-        <hr class="text-divider-light dark:text-divider-dark">
-      </div>
-      <h2 x-show="noFilters()" id="all-guides" class="scroll-mt-36">All guides</h2>
-      <div x-show="!noFilters()" class="pb-8 flex flex-col gap-2">
-        <div class="flex gap-2 items-center">
-          <span class="mb-1 icon-svg icon-sm">{{ partialCached "icon" "filter_alt" "filter_alt" }}</span>
-          <p>Filtered results: showing <span x-text="total - hidden.length"></span> out of <span x-text="total"></span> guides.</p>
-        </div>
-        <div class="pl-4 flex gap-2 items-center">
-        {{- range $name, $taxonomy := site.Taxonomies.tags }}
-          <div x-show="filters.tags.includes('{{$name}}')">{{ template "termchip" $taxonomy.Page.LinkTitle }}</div>
-        {{- end }}
-        {{- range $name, $taxonomy := site.Taxonomies.languages }}
-          <div x-show="filters.languages.includes('{{$name}}')"
-                class="text-sm inline-flex gap-1 items-center rounded-full border
-                       border-divider-light dark:border-divider-dark bg-gray-light-100
-                       px-2 text-gray-light-800 dark:bg-gray-dark-200
-                       dark:text-gray-dark-800 select-none">
-            <img class="py-1" height="18" width="18" title="{{ .Page.LinkTitle }}" src="{{ .Page.Params.icon }}">
-            <span>{{ .Page.LinkTitle }}</span>
-          </div>
         {{- end }}
+
+        <!-- No matches -->
+        <div
+          x-show="filtering() && resultCount() === 0"
+          x-cloak
+          class="flex flex-col items-center justify-center gap-3 py-24 text-center"
+        >
+          <span class="icon-svg icon-lg text-gray-300 dark:text-gray-600">
+            {{ partialCached "icon" "magnifying-glass" "magnifying-glass" }}
+          </span>
+          <p class="text-gray-500 dark:text-gray-400">
+            No guides match “<span class="font-medium text-gray-700 dark:text-gray-200" x-text="query"></span>”.
+          </p>
+          <button
+            @click="clear()"
+            class="text-sm font-medium text-blue-600 transition hover:underline dark:text-blue-400"
+          >
+            Clear filter
+          </button>
         </div>
       </div>
-      <div x-ref="guide-container">
-        {{- range .Pages }}
-          <div
-              id="guide-{{ math.Counter }}"
-              data-languages='{{ jsonify (.Params.languages | default slice) }}'
-              data-tags='{{ jsonify (.Params.tags | default slice) }}'
-              x-show="isVisible($el);"
-            class="flex flex-col justify-between p-4 border-b border-divider-light
-                   hover:bg-gray-light-100 hover:dark:bg-gray-dark-200
-                   dark:border-divider-dark">
-            <div class="flex flex-col xl:flex-row justify-between">
-              <a href="{{ .Permalink }}" class="text-lg hover:underline mb-2 xl:mb-0 truncate">{{ .Title }}</a>
-              {{ template "guide-metadata" . }}
-            </div>
-          </div>
-        {{- end }}
-      </div>
     </div>
-  </article>
-</div>
-{{ end }}
-
-{{- define "guide-metadata" }}
-<div class="text-sm flex gap-8 items-center justify-between text-gray-light dark:text-gray-dark">
-  <div class="flex flex-wrap md:flex-nowrap gap-2">
-    {{- $langs := .GetTerms "languages" }}
-    {{ partial "languages" $langs }}
-    {{- $tags := .GetTerms "tags" }}
-    {{- range $tags }}
-      {{ template "termchip" .Page.LinkTitle }}
-    {{- end }}
-  </div>
-  {{- with .Params.time }}
-  <div class="flex whitespace-nowrap flex-shrink gap-2">
-    <span class="icon-svg">{{ partialCached "icon" "schedule" "schedule" }}</span>
-    <span>{{ . }}</span>
   </div>
-  {{- end }}
-</div>
-{{- end }}
-
-{{- define "termchip" }}
-  <span class="whitespace-nowrap inline-flex text-sm min-w-0 items-center rounded-full
-               border border-divider-light dark:border-divider-dark
-               bg-gray-light-100 px-2 text-gray-light-800 dark:bg-gray-dark-200
-               dark:text-gray-dark-800 select-none">
-    <span class="icon-svg icon-sm pb-0.5">
-      {{ partialCached "icon" "tag" "tag" }}
-    </span>
-    {{ . }}
-  </span>
-{{- end }}
+{{ end }}
diff --git a/layouts/guides/list.html b/layouts/guides/list.html
deleted file mode 100644
index cc1fd0723222..000000000000
--- a/layouts/guides/list.html
+++ /dev/null
@@ -1,25 +0,0 @@
-{{ define "left" }}
-  {{ partial "sidebar/mainnav.html" . }}
-  {{ partial "sidebar/guides.html" . }}
-{{ end }}
-
-{{ define "main" }}
-<article class="prose min-w-0 max-w-4xl dark:prose-invert">
-  {{ partial "breadcrumbs.html" . }}
-  <h1 data-pagefind-weight="10" class="scroll-mt-36">{{ .Title }}</h1>
-  <div class="block lg:hidden">
-    {{ partialCached "pagemeta.html" . . }}
-    <hr />
-  </div>
-  {{ .Content }}
-  {{ partial "heading.html" (dict "text" "Modules" "level" 2) }}
-  <ol>
-    {{- range $i, $e := .Pages }}
-    <li>
-      <a class="link" href="{{ .Permalink }}">{{ .LinkTitle }}</a>
-      <p>{{ plainify .Description }}</p>
-    </li>
-    {{- end }}
-  </ol>
-</article>
-{{ end }}
diff --git a/layouts/guides/single.html b/layouts/guides/single.html
index f72668a9eb94..5d7ab8ed1ff3 100644
--- a/layouts/guides/single.html
+++ b/layouts/guides/single.html
@@ -1,20 +1,14 @@
 {{ define "left" }}
-  {{ partial "sidebar/mainnav.html" . }}
-  {{ partial "sidebar/guides.html" . }}
+  {{- partial "sidebar/mainnav.html" . }}
 {{ end }}
 
 {{ define "main" }}
-  {{ partial "content-default.html" . }}
-  <div class="prose dark:prose-invert max-w-4xl">
-    {{ if (.Store.Get "multipage") }}
-      {{- with .PrevInSection }}
-        <div class="col-start-2 not-prose my-4">
-          <a href="{{ .Permalink }}"
-            class="cursor-pointer py-2 px-4 rounded bg-blue-light-500
-            dark:bg-blue-dark-400 hover:bg-blue-light-400
-            dark:hover:bg-blue-dark-500 text-white">{{ .Title }} »</a>
-        </div>
-      {{- end }}
-    {{- end }}
+  <div class="mx-auto flex w-full max-w-7xl justify-center gap-12">
+    <article class="prose dark:prose-invert min-w-0 max-w-[92ch]">
+      {{ partial "content-default.html" . }}
+    </article>
+    <div class="-mt-8 hidden w-72 flex-none lg:block">
+      {{ partial "aside.html" . }}
+    </div>
   </div>
 {{ end }}
diff --git a/layouts/home.html b/layouts/home.html
new file mode 100644
index 000000000000..1ae662409121
--- /dev/null
+++ b/layouts/home.html
@@ -0,0 +1,123 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    {{ partial "head.html" . }}
+  </head>
+
+  <body
+    class="flex min-h-screen flex-col bg-gray-50 text-base dark:bg-gray-950 dark:text-white"
+  >
+    {{ partial "header.html" . }}
+    {{ partial "gordon-chat.html" . }}
+    <main class="flex-1">
+      <!-- AI Hero Section -->
+      <section class="relative overflow-hidden py-16 md:py-20">
+        <!-- Wavy plus pattern background from Docker.com -->
+        <div
+          class="absolute inset-0 bg-[center_top] bg-no-repeat opacity-100 [mix-blend-mode:multiply] dark:opacity-60 dark:[mix-blend-mode:normal] dark:[filter:invert(1)_brightness(1.5)]"
+          style="background-image: url('/assets/images/dot-pattern.svg');"
+        ></div>
+        <div class="relative z-10 container mx-auto max-w-4xl px-4 text-center">
+          <h1
+            class="mb-4 text-3xl font-semibold text-balance text-gray-900 md:text-4xl dark:text-white"
+          >
+            How can we help?
+          </h1>
+          <!-- AI Search Input -->
+          <div class="mx-auto max-w-2xl py-6" x-data="{ query: '' }">
+            <div
+              class="group flex items-center gap-3 rounded-2xl border-2 border-gray-200 bg-white p-4 shadow-lg transition focus-within:scale-[1.02] focus-within:border-blue-500 hover:border-blue-500 dark:border-gray-700 dark:bg-gray-900"
+            >
+              <div class="shrink-0 rounded-xl text-blue-500">
+                <span class="icon-svg group-hover:hidden">
+                  {{ partialCached "icon" "gordon" "gordon" }}
+                </span>
+                <span class="icon-svg hidden group-hover:block">
+                  {{ partialCached "icon" "gordon-happy" "gordon-happy" }}
+                </span>
+              </div>
+              <input
+                x-model="query"
+                type="text"
+                placeholder="Ask anything about Docker and get instant answers…"
+                @keydown.enter="if (query.trim()) { $store.gordon.open(query.trim(), true); query = ''; }"
+                class="flex-1 bg-transparent text-lg text-gray-900 placeholder-gray-500 focus:outline-none dark:text-white dark:placeholder-gray-400"
+              />
+              <button
+                @click="if (query.trim()) { $store.gordon.open(query.trim(), true); query = ''; }"
+                :disabled="!query.trim()"
+                class="shrink-0 rounded-xl bg-blue-500 p-2 text-white transition hover:bg-blue-600 disabled:cursor-not-allowed disabled:bg-gray-300 dark:disabled:bg-gray-700"
+              >
+                <span class="icon-svg">
+                  {{ partialCached "icon" "arrow-right" "arrow-right" }}
+                </span>
+              </button>
+            </div>
+          </div>
+
+          <!-- Suggestion Pills -->
+          <div class="mt-6 flex flex-wrap justify-center gap-3" x-data>
+            {{ range slice
+              "How do I get started with Docker?"
+              "Can I run my AI agent in a sandbox?"
+              "What is a container?"
+              "What are Docker Hardened Images?"
+              "Why should I use Docker Compose?"
+            }}
+              <button
+                @click="$store.gordon.open($el.textContent.trim(), true);"
+                class="ai-suggestion cursor-pointer rounded-full border border-gray-200 bg-white px-4 py-2 text-sm text-gray-600 transition hover:border-blue-400 hover:bg-blue-50 hover:text-gray-900 dark:border-gray-700 dark:bg-gray-800 dark:text-gray-300 dark:hover:border-blue-500 dark:hover:bg-gray-700 dark:hover:text-white"
+              >
+                {{ . }}
+              </button>
+            {{ end }}
+          </div>
+        </div>
+      </section>
+
+      <!-- Quick Links Section -->
+      <section class="py-8">
+        <div class="container mx-auto px-4 xl:max-w-[1200px]">
+          <div class="grid grid-cols-1 gap-4 md:grid-cols-2 lg:grid-cols-4">
+            {{ range slice
+              (dict "url" "/get-started/" "icon" "rocket-launch" "title" "Get started" "description" "Learn Docker basics.")
+              (dict "url" "/guides/" "icon" "book-open" "title" "Guides" "description" "Optimize your development workflows with Docker.")
+              (dict "url" "/manuals/" "icon" "document-text" "title" "Manuals" "description" "Install, set up, configure, and use Docker products.")
+              (dict "url" "/reference/" "icon" "command-line" "title" "Reference" "description" "Browse the CLI and API documentation.")
+            }}
+              <a
+                href="{{ .url }}"
+                class="group block rounded-xl border border-gray-200 bg-white p-6 transition hover:scale-[1.02] hover:border-blue-500 dark:border-gray-700 dark:bg-gray-900 dark:hover:border-blue-500"
+              >
+                <div class="flex items-start gap-4">
+                  <div
+                    class="shrink-0 rounded-lg bg-blue-100 p-3 text-blue-500 dark:bg-gray-700 dark:text-blue-400"
+                  >
+                    <span class="icon-svg">
+                      {{ partialCached "icon" .icon .icon }}
+                    </span>
+                  </div>
+                  <div>
+                    <h3
+                      class="mb-1 text-lg font-semibold text-gray-900 transition group-hover:text-blue-500 dark:text-white dark:group-hover:text-blue-400"
+                    >
+                      {{ .title }}
+                    </h3>
+                    <p
+                      class="text-sm leading-relaxed text-gray-600 dark:text-gray-300"
+                    >
+                      {{ .description }}
+                    </p>
+                  </div>
+                </div>
+              </a>
+            {{ end }}
+          </div>
+        </div>
+      </section>
+
+      {{ partial "whats-new.html" . }}
+    </main>
+    <footer>{{ partialCached "footer.html" . }}</footer>
+  </body>
+</html>
diff --git a/layouts/home.llms.txt b/layouts/home.llms.txt
new file mode 100644
index 000000000000..43d00260c030
--- /dev/null
+++ b/layouts/home.llms.txt
@@ -0,0 +1,81 @@
+{{- $home := site.Home -}}
+{{- $manuals := site.GetPage "/manuals" -}}
+{{- $getStarted := site.GetPage "/get-started" -}}
+{{- $reference := site.GetPage "/reference" -}}
+
+# Docker Documentation
+
+{{ with $home.Description -}}
+{{ chomp (replace . "\n" " ") }}
+{{- else -}}
+Docker Documentation is the official documentation site for Docker products,
+including Docker Desktop, Docker Engine, Docker Build, Docker Compose, Docker
+Hub, Docker Scout, and Docker AI features.
+{{- end }}
+
+Use this file as a generated discovery guide for the docs site. For the complete
+page index, use [llms-full.txt](https://docs.docker.com/llms-full.txt).
+
+> MCP endpoint for structured agent access: https://mcp-docs.docker.com/mcp
+> Bulk text corpus for offline indexing: https://docs.docker.com/llms-full.txt
+
+## Primary sections
+
+{{- range sort (where site.Sections "Title" "!=" "") "Weight" }}
+{{- if not (in (slice "includes" "tags") .Section) }}
+- [{{ .LinkTitle | default .Title }}]({{ .Permalink }}): {{ with .Description }}{{ chomp (replace . "\n" " ") }}{{ else }}{{ .Title }} documentation.{{ end }}
+  Markdown: {{ partial "utils/markdown-url.html" . }}
+{{- end }}
+{{- end }}
+
+{{ with $getStarted }}
+## Starter paths
+
+{{- range index .Params "get-started" }}
+- [{{ .title }}]({{ .link | absURL }}): {{ .description }}
+{{- end }}
+{{- range index .Params "get-started2" }}
+- [{{ .title }}]({{ .link | absURL }}): {{ .description }}
+{{- end }}
+{{- end }}
+
+{{ with $manuals }}
+## Product documentation
+
+{{- range .Params.sidebar.groups }}
+{{- $group := . }}
+{{- $items := index $manuals.Params ($group | anchorize) }}
+{{- with $items }}
+
+### {{ $group }}
+{{- range . }}
+- [{{ .title }}]({{ .link | absURL }}): {{ .description }}
+{{- end }}
+{{- end }}
+{{- end }}
+{{- end }}
+
+{{ with $reference }}
+## Reference entry points
+
+### File formats
+{{- range .Params.grid_files }}
+- [{{ .title }}]({{ .link | absURL }}): {{ .description }}
+{{- end }}
+
+### Command-line interfaces
+{{- range .Params.grid_clis }}
+- [{{ .title }}]({{ .link | absURL }}): {{ .description }}
+{{- end }}
+
+### APIs
+{{- range .Params.grid_apis }}
+- [{{ .title }}]({{ .link | absURL }}): {{ .description }}
+{{- end }}
+{{- end }}
+
+## Retrieval guidance
+
+- Prefer section landing pages above for navigation and scope selection.
+- Use [llms-full.txt](https://docs.docker.com/llms-full.txt) when you need the complete documentation corpus.
+- Use page-level markdown routes such as `https://docs.docker.com/engine/install.md` for clean per-page retrieval.
diff --git a/layouts/home.llmsfull.txt b/layouts/home.llmsfull.txt
new file mode 100644
index 000000000000..eaa17a21b423
--- /dev/null
+++ b/layouts/home.llmsfull.txt
@@ -0,0 +1,16 @@
+{{- $pages := where site.RegularPages "Params.sitemap" "!=" false -}}
+{{- $sorted := sort $pages "RelPermalink" -}}
+
+# Docker Documentation full text
+
+> Source index: https://docs.docker.com/llms.txt
+> This file contains page metadata and stable markdown URLs for bulk ingestion.
+{{- range $sorted }}
+
+## {{ .Title }}
+URL: {{ .Permalink }}
+Markdown: {{ partial "utils/markdown-url.html" . }}
+{{- with .Description }}
+Description: {{ chomp (replace . "\n" " ") }}
+{{- end }}
+{{- end }}
diff --git a/layouts/home.markdown.md b/layouts/home.markdown.md
new file mode 100644
index 000000000000..239ce8eb50a1
--- /dev/null
+++ b/layouts/home.markdown.md
@@ -0,0 +1,3 @@
+# Docker Documentation
+
+{{ .RenderShortcodes }}
diff --git a/layouts/home.metadata.json b/layouts/home.metadata.json
new file mode 100644
index 000000000000..caee6bc70c68
--- /dev/null
+++ b/layouts/home.metadata.json
@@ -0,0 +1,15 @@
+[
+{{- range where site.Pages "Params.sitemap" "!=" false -}}
+  {{- $title := .LinkTitle -}}
+  {{- $desc := partialCached "utils/description.html" . . -}}
+  {{- $kwd := partialCached "utils/keywords.html" . . -}}
+  {{- $tags := slice -}}
+  {{- range (.Params.tags | default slice) -}}
+    {{- $tagData := index hugo.Data.tags . -}}
+    {{- with $tagData -}}
+      {{ $tags = $tags | append .title }}
+    {{- end -}}
+  {{- end -}}
+  {{- jsonify (dict "url" .Permalink "title" $title "description" $desc "keywords" $kwd "tags" $tags) -}},
+{{- end -}}
+{}]
diff --git a/layouts/home.redirects.json b/layouts/home.redirects.json
new file mode 100644
index 000000000000..9d7ed82c9f05
--- /dev/null
+++ b/layouts/home.redirects.json
@@ -0,0 +1,45 @@
+{{- /*
+
+  This template generates the redirects.json file used to generate 301
+  redirects in production. It takes all the redirects defined in
+  data/redirects.yml, as well as all the aliases defined in front matter, and
+  outputs a simple key-value JSON file:
+
+  {
+    "<request-path>": "<redirect-path>",
+    ...
+  }
+
+  e.g.
+
+  {
+    "/engine/reference/builder/": "/reference/dockerfile/",
+    ...
+  }
+
+  */
+-}}
+
+{{- $redirects := newScratch }}
+{{- range hugo.Sites -}}
+  {{- range .Pages -}}
+    {{- if .Params.aliases -}}
+      {{- $page := . -}}
+      {{- $target := .RelPermalink -}}
+      {{- range .Params.aliases -}}
+        {{- $alias := . -}}
+        {{- if eq (strings.TrimSuffix "/" $alias) (strings.TrimSuffix "/" $target) -}}
+          {{- errorf "alias %q in %s resolves to the page itself" $alias $page.File.Path -}}
+        {{- end -}}
+        {{- $redirects.SetInMap "paths" $alias $target -}}
+      {{- end -}}
+    {{- end -}}
+  {{- end -}}
+{{- end -}}
+{{- range $target, $aliases := hugo.Data.redirects -}}
+{{- range $aliases }}
+{{- $redirects.SetInMap "paths" . $target -}}
+{{- end -}}
+{{- end -}}
+{{- $opts := dict "noHTMLEscape" true }}
+{{- $redirects.Get "paths" | jsonify $opts }}
diff --git a/layouts/home.robots.txt b/layouts/home.robots.txt
new file mode 100644
index 000000000000..7c2c07975479
--- /dev/null
+++ b/layouts/home.robots.txt
@@ -0,0 +1,19 @@
+{{- /*
+	For Netlify deployments, we disallow all routes to prevent search
+	engines from indexing our preview sites.
+	*/
+-}}
+
+{{- if hugo.IsProduction -}}
+User-agent: *
+Disallow: /unassociated-machines/
+Content-Signal: ai-train=yes, search=yes, ai-input=yes
+
+
+Sitemap: {{ "sitemap.xml" | absURL }}
+{{- else -}}
+# Disable all indexing on staging websites and Netlify previews to prevent
+# them showing up in search results.
+User-agent: *
+Disallow: /
+{{- end }}
diff --git a/layouts/index.html b/layouts/index.html
deleted file mode 100644
index c157c1943bee..000000000000
--- a/layouts/index.html
+++ /dev/null
@@ -1,262 +0,0 @@
-<!doctype html>
-<html lang="en">
-
-<head>
-  {{ partial "head.html" . }}
-</head>
-
-<body class="flex h-max flex-col bg-background-light text-base dark:bg-background-dark dark:text-white">
-  <div class="absolute -z-10 w-full">
-    <svg class="dark:hidden" viewBox="0 0 1616 797" fill="none" xmlns="http://www.w3.org/2000/svg">
-      <path d="M1066.69 797L0 136.789V0H1616V488.038L1066.69 797Z" fill="#EFEFF2" />
-    </svg>
-    <svg class="hidden dark:block" viewBox="0 0 1616 797" fill="none" xmlns="http://www.w3.org/2000/svg">
-      <path d="M1066.69 797L0 136.789V0H1616V488.038L1066.69 797Z" fill="#080B0E" fill-opacity="0.3" />
-    </svg>
-  </div>
-  {{ partial "header.html" . }}
-  <main class="flex min-h-screen w-full flex-col items-stretch self-center">
-    <div class="flex xl:w-[1200px] flex-col items-stretch gap-20 self-center py-20 w-full px-4">
-      <div class="bg-pattern-blue relative overflow-hidden rounded drop-shadow">
-        <div class="flex h-full flex-col items-start justify-between gap-4 p-8">
-          <div class="flex items-center gap-6">
-            <span class="icon-svg text-violet-light dark:text-violet-dark">
-              {{ partial "icon" "play_circle" }}</span>
-            <h1 class="text-2xl">Get Docker</h1>
-          </div>
-          <p>
-            Learn how to install Docker for Mac, Windows, or Linux and explore
-            our developer tools.
-          </p>
-          <a href="/get-started/get-docker/"
-            class="mt-20 flex cursor-pointer items-center gap-2 rounded bg-blue-light p-2 px-4 text-white transition duration-300 hover:bg-blue-light-400 dark:bg-blue-dark-400 dark:hover:bg-blue-dark">
-            <span class="icon-svg">{{ partial "icon" "download"}}</span>
-            Get Docker
-          </a>
-        </div>
-        <div class="absolute bottom-0 right-0 origin-bottom-right scale-50 lg:scale-100">
-          <img class="dark:hidden" alt="Low-fi desktop app" src="/assets/images/app-wf-light-1.svg" />
-          <img class="hidden dark:block" alt="Low-fi desktop app" src="/assets/images/app-wf-dark-1.svg" />
-        </div>
-      </div>
-
-      <div>
-        <div class="grid grid-cols-1 gap-4 lg:grid-cols-4">
-
-          <div>
-            <a class="h-full" href="/get-started/">
-              <div
-                class="flex h-full flex-col gap-2 rounded border border-gray-light-100 bg-white p-4 drop-shadow-sm hover:border-gray-light-200 hover:drop-shadow-lg dark:border-gray-dark-400 dark:bg-gray-dark-200 hover:dark:border-gray-dark">
-                <div class="flex items-center gap-4">
-                  <span class="icon-svg text-violet-light dark:text-violet-dark">
-                    {{ partial "icon" "rocket" }}
-                  </span>
-                  <div>
-                    <div class="text-xl leading-snug text-gray-light-800 dark:text-white">
-                      Get started
-                    </div>
-                  </div>
-                </div>
-                <div class="leading-snug text-gray-light-500 dark:text-gray-dark-700">
-                  Learn Docker basics and the benefits of containerization.
-                </div>
-              </div>
-            </a>
-          </div>
-
-          <div>
-            <a class="h-full" href="/guides/">
-              <div
-                class="flex h-full flex-col gap-2 rounded border border-gray-light-100 bg-white p-4 drop-shadow-sm hover:border-gray-light-200 hover:drop-shadow-lg dark:border-gray-dark-400 dark:bg-gray-dark-200 hover:dark:border-gray-dark">
-                <div class="flex items-center gap-4">
-                  <span class="icon-svg text-violet-light dark:text-violet-dark">
-                    {{ partial "icon" "developer_guide" }}
-                  </span>
-                  <div>
-                    <div class="text-xl leading-snug text-gray-light-800 dark:text-white">
-                      Guides
-                    </div>
-                  </div>
-                </div>
-                <div class="leading-snug text-gray-light-500 dark:text-gray-dark-700">
-                  Learn how Docker can optimize your development workflows.
-                </div>
-              </div>
-            </a>
-          </div>
-
-          <div>
-            <a class="h-full" href="/manuals/">
-              <div
-                class="flex h-full flex-col gap-2 rounded border border-gray-light-100 bg-white p-4 drop-shadow-sm hover:border-gray-light-200 hover:drop-shadow-lg dark:border-gray-dark-400 dark:bg-gray-dark-200 hover:dark:border-gray-dark">
-                <div class="flex items-center gap-4">
-                  <span class="icon-svg text-violet-light dark:text-violet-dark">
-                    {{ partial "icon" "description" }}
-                  </span>
-                  <div>
-                    <div class="text-xl leading-snug text-gray-light-800 dark:text-white">
-                      Manuals
-                    </div>
-                  </div>
-                </div>
-                <div class="leading-snug text-gray-light-500 dark:text-gray-dark-700">
-                  Learn how to install, set up, configure, and use Docker
-                  products.
-                </div>
-              </div>
-            </a>
-          </div>
-
-          <div>
-            <a class="h-full" href="/reference/">
-              <div
-                class="flex h-full flex-col gap-2 rounded border border-gray-light-100 bg-white p-4 drop-shadow-sm hover:border-gray-light-200 hover:drop-shadow-lg dark:border-gray-dark-400 dark:bg-gray-dark-200 hover:dark:border-gray-dark">
-                <div class="flex items-center gap-4">
-                  <span class="icon-svg text-violet-light dark:text-violet-dark">
-                    {{ partial "icon" "terminal" }}
-                  </span>
-                  <div>
-                    <div class="text-xl leading-snug text-gray-light-800 dark:text-white">
-                      Reference
-                    </div>
-                  </div>
-                </div>
-                <div class="leading-snug text-gray-light-500 dark:text-gray-dark-700">
-                  Browse the CLI and API documentation.
-                </div>
-              </div>
-            </a>
-          </div>
-        </div>
-      </div>
-
-      <div class="z-10 grid grid-cols-1 gap-20 lg:grid-cols-2">
-        <div class="bg-pattern-verde relative rounded p-6 drop-shadow">
-          <div class="flex h-full flex-col items-start justify-between gap-12">
-            <div class="flex flex-col gap-4">
-              <h2 class="font-medium">Gen AI catalog {{ partial
-              "components/badge.html" (dict "color" "blue" "content" "New")
-              }}</h2>
-              <p class="text-xl">
-                Integrate AI solutions into your apps with minimal effort
-              </p>
-            </div>
-            <div class="flex flex-col xl:flex-row gap-4 items-start">
-              <a href="https://hub.docker.com/catalogs/gen-ai"
-                class="flex cursor-pointer items-center gap-2 rounded bg-blue-light p-2 px-4 text-white transition duration-300 hover:bg-blue-light-400 dark:bg-blue-dark-400 dark:hover:bg-blue-dark">
-                Explore on Docker Hub
-              </a>
-              <a href="/docker-hub/image-library/catalogs/"
-                class="flex-grow-0 flex cursor-pointer items-center gap-2 rounded bg-blue-light p-2 px-4 text-white transition duration-300 hover:bg-blue-light-400 dark:bg-blue-dark-400 dark:hover:bg-blue-dark">
-                Read the docs
-              </a>
-            </div>
-          </div>
-          <div class="absolute bottom-0 right-0 origin-bottom-right scale-75 md:scale-100">
-            <img class="dark:hidden" alt="Low-fi desktop app" src="/assets/images/app-wf-light-2.svg" />
-            <img class="hidden dark:block" alt="Low-fi desktop app" src="/assets/images/app-wf-dark-2.svg" />
-          </div>
-        </div>
-        <div class="rounded-[6px] bg-gradient-to-br from-blue-light-400 to-magenta-light-400 dark:from-blue-dark-400 dark:to-magenta-dark-400 p-[2px] drop-shadow">
-          <div class="bg-pattern-purple rounded p-6">
-            <div class="flex flex-col gap-12">
-              <div class="flex flex-col gap-4">
-                <h2 class="font-medium">
-                  Docker Model Runner
-                  {{ partial "components/badge.html" (dict "color" "blue" "content" "Beta") }}
-                </h2>
-                <p class="text-xl">
-                  Run, test, and serve AI models locally in seconds — no setup, no hassle.
-                </p>
-                <p>
-                  Whether you’re experimenting with the latest LLMs or deploying to production, 
-                  Docker Model Runner brings the performance and control you need, without the friction.
-
-                </p>
-              </div>
-              <div class="flex flex-col xl:flex-row gap-4 items-start">
-                <a href="/desktop/features/model-runner/"
-                  class="max-w-fit cursor-pointer rounded bg-blue-light px-4 py-2 text-white transition duration-300 hover:bg-blue-light-400 dark:bg-blue-dark-400 dark:hover:bg-blue-dark">Read the docs</a>
-              </div>
-            </div>
-          </div>
-        </div>
-      </div>
-
-      <div>
-        <h2 class="mb-4 text-xl">Browse by section</h2>
-        <div class="grid grid-cols-1 gap-4 md:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4">
-          {{ range .Params.grid }}
-          <div>
-            <div
-              class="flex h-full flex-col gap-2 rounded border border-gray-light-100 bg-white p-4 drop-shadow-sm dark:border-gray-dark-400 dark:bg-gray-dark-200">
-              <div class="flex items-center gap-4">
-                <span class="icon-svg text-gray-light dark:text-gray-dark">{{ partial "icon" .icon }}</span>
-                <div>
-                  <div class="text-xl">{{ .title }}</div>
-                </div>
-              </div>
-              <div class="flex h-full flex-col justify-between gap-4">
-                <p>{{ .description | markdownify }}</p>
-                <nav class="flex flex-col gap-2">
-                  {{ range .links }}
-                  <div>
-                    <span class="icon-svg text-gray-light dark:text-gray-dark">{{ partial "icon" "arrow_right" }}</span>
-                    <a class="link" href="{{ .url }}">{{ .text }}</a>
-                  </div>
-                  {{ end }}
-                </nav>
-              </div>
-            </div>
-          </div>
-          {{ end }}
-        </div>
-      </div>
-      <div class="flex flex-col gap-4">
-        <h2 class="mb-4 text-xl">Browse by tag</h2>
-        <div class="flex flex-wrap gap-4">
-          {{ $tags := slice }}
-          {{- range site.Taxonomies.tags }}
-            {{ $tags = $tags | append .Page }}
-          {{ end }}
-          {{ partial "tags.html" $tags }}
-        </div>
-      </div>
-    </div>
-
-    <div
-      class="relative flex md:h-[334px] items-center justify-center overflow-hidden bg-gray-light-100 dark:bg-gray-dark-200 h-full py-8">
-      <div class="w-[1200px] px-4">
-        <div class="flex md:max-w-[66%] flex-col gap-8 max-w-full">
-          <h2 class="text-2xl">Community resources</h2>
-          <p>
-            Find fellow Docker enthusiasts, engage in insightful discussions,
-            share knowledge, and collaborate on projects. Our communities
-            offer a rich online experience for developers to create valuable
-            connections that challenge and inspire!
-          </p>
-          <div class="flex gap-4 flex-col md:flex-row">
-            <a href="https://forums.docker.com/"
-              class="cursor-pointer rounded bg-white px-4 py-2 text-blue-light hover:bg-gray-light-100 dark:bg-gray-dark-400 dark:text-white dark:hover:bg-gray-dark-500">
-              Visit Docker Forum
-            </a>
-            <a href="https://dockr.ly/comm-slack"
-              class="cursor-pointer rounded bg-white px-4 py-2 text-blue-light hover:bg-gray-light-100 dark:bg-gray-dark-400 dark:text-white dark:hover:bg-gray-dark-500">
-              Join Docker Slack
-            </a>
-            <a href="https://www.docker.com/community/captains/"
-              class="cursor-pointer rounded bg-white px-4 py-2 text-blue-light hover:bg-gray-light-100 dark:bg-gray-dark-400 dark:text-white dark:hover:bg-gray-dark-500">
-              Find your Docker Captain
-            </a>
-          </div>
-        </div>
-      </div>
-      <div class="absolute right-0 top-0 hidden md:block">
-        {{- (resources.Get "images/home-abstract-faint.svg").Content | safe.HTML -}}
-      </div>
-    </div>
-  </main>
-  <footer>{{ partialCached "footer.html" . }}</footer>
-</body>
-
-</html>
diff --git a/layouts/index.metadata.json b/layouts/index.metadata.json
deleted file mode 100644
index acfaf21f2b80..000000000000
--- a/layouts/index.metadata.json
+++ /dev/null
@@ -1,12 +0,0 @@
-[
-{{- range where site.Pages "Params.sitemap" "!=" false -}}
-  {{- $title := .LinkTitle -}}
-  {{- $desc := partialCached "utils/description.html" . . -}}
-  {{- $kwd := partialCached "utils/keywords.html" . . -}}
-  {{- $tags := slice -}}
-  {{- range (.GetTerms "tags") -}}
-    {{ $tags = $tags | append .LinkTitle }}
-  {{- end -}}
-  {{- jsonify (dict "url" .Permalink "title" $title "description" $desc "keywords" $kwd "tags" $tags) -}},
-{{- end -}}
-{}]
diff --git a/layouts/index.redirects.json b/layouts/index.redirects.json
deleted file mode 100644
index 6229dfc8d185..000000000000
--- a/layouts/index.redirects.json
+++ /dev/null
@@ -1,38 +0,0 @@
-{{- /*
-
-  This template generates the redirects.json file used to generate 301
-  redirects in production. It takes all the redirects defined in
-  data/redirects.yml, as well as all the aliases defined in front matter, and
-  outputs a simple key-value JSON file:
-
-  {
-    "<request-path>": "<redirect-path>",
-    ...
-  }
-
-  e.g.
-
-  {
-    "/engine/reference/builder/": "/reference/dockerfile/",
-    ...
-  }
-
-  */
--}}
-
-{{- $redirects := newScratch }}
-{{- range $i, $e := site.AllPages -}} 
-  {{- if .Params.aliases -}}
-    {{- $target := .RelPermalink -}}
-    {{- range .Params.aliases -}}
-      {{ $redirects.SetInMap "paths" . $target }}
-    {{- end -}}
-  {{- end -}}
-{{- end -}}
-{{- range $target, $aliases := site.Data.redirects -}}
-{{- range $aliases }}
-{{- $redirects.SetInMap "paths" . $target -}}
-{{- end -}}
-{{- end -}}
-{{- $opts := dict "noHTMLEscape" true }}
-{{- $redirects.Get "paths" | jsonify $opts }}
diff --git a/layouts/index.robots.txt b/layouts/index.robots.txt
deleted file mode 100644
index 3e9a658fdf96..000000000000
--- a/layouts/index.robots.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-{{- /*
-	For Netlify deployments, we disallow all routes to prevent search
-	engines from indexing our preview sites.
-	*/
--}}
-
-{{- if hugo.IsProduction -}}
-User-agent: *
-
-
-Sitemap: {{ "sitemap.xml" | absURL }}
-{{- else -}}
-# Disable all indexing on staging websites and Netlify previews to prevent
-# them showing up in search results.
-User-agent: *
-Disallow: /
-{{- end }}
diff --git a/layouts/list.html b/layouts/list.html
new file mode 100644
index 000000000000..834974e186ea
--- /dev/null
+++ b/layouts/list.html
@@ -0,0 +1,5 @@
+{{ define "article" }}
+  <article class="prose dark:prose-invert max-w-4xl">
+    {{ partial "content-default.html" . }}
+  </article>
+{{ end }}
diff --git a/layouts/list.markdown.md b/layouts/list.markdown.md
new file mode 100644
index 000000000000..54f307137674
--- /dev/null
+++ b/layouts/list.markdown.md
@@ -0,0 +1,3 @@
+# {{ .Title }}
+
+{{ .RenderShortcodes }}
diff --git a/layouts/partials/aside.html b/layouts/partials/aside.html
deleted file mode 100644
index d72fa42a853a..000000000000
--- a/layouts/partials/aside.html
+++ /dev/null
@@ -1,15 +0,0 @@
-<aside
-  class="sticky top-16 h-[calc(100vh-64px)] min-w-52 space-y-4 overflow-y-auto py-4 w-full"
->
-  {{ partial "github-links.html" . }}
-  <div id="TableOfContents">
-    {{ partialCached "pagemeta.html" . . }}
-  </div>
-  {{- if ne .Type "guides" }}
-  {{ with .GetTerms "tags" }}
-    <div class="not-prose mt-8 px-4">
-      {{- partial "tags.html" . }}
-    </div>
-  {{- end }}
-{{- end }}
-</aside>
\ No newline at end of file
diff --git a/layouts/partials/breadcrumbs.html b/layouts/partials/breadcrumbs.html
deleted file mode 100644
index 17db7a97f0ee..000000000000
--- a/layouts/partials/breadcrumbs.html
+++ /dev/null
@@ -1,12 +0,0 @@
-<nav id="breadcrumbs"
-  {{- $breadcrumbTitles := slice }}
-  data-pagefind-ignore class="gap-4 flex items-center text-gray-light dark:text-gray-dark min-w-0">
-  {{ range .Ancestors.Reverse }}
-    {{ $breadcrumbTitles = $breadcrumbTitles | append .LinkTitle }}
-    <a href="{{ .Permalink }}" class="link truncate">{{ markdownify .LinkTitle }}</a>
-    <span>/</span>
-  {{- end }}
-  <span
-    data-pagefind-meta="breadcrumbs:{{ collections.Delimit $breadcrumbTitles " / " }}"
-    class="truncate">{{ markdownify .LinkTitle }}</span>
-</nav>
diff --git a/layouts/partials/components/accordion.html b/layouts/partials/components/accordion.html
deleted file mode 100644
index 93fc14fb302a..000000000000
--- a/layouts/partials/components/accordion.html
+++ /dev/null
@@ -1,17 +0,0 @@
-<div
-  id="{{ urls.Anchorize .title }}"
-  x-data="{ open: {{ .open | default false }} }" class="border border-gray-light-200 dark:border-gray-dark-200 bg-white dark:bg-gray-dark-100 py-2 my-6 rounded">
-  <button class="not-prose w-full py-2 px-4 flex justify-between" x-on:click="open = ! open">
-    <div class="{{ with .large }} text-xl {{ end }} flex items-center gap-2">
-      {{- with .icon }}
-        <span class="icon-svg -mt-1">{{ partialCached "icon" . . }}</span>
-      {{- end }}
-      {{ .title }}
-    </div>
-    <span :class="{ 'hidden' : !open }" class="icon-svg">{{ partialCached "icon" "arrow_drop_up" "arrow_drop_up" }}</span>
-    <span :class="{ 'hidden' : open }" class="icon-svg">{{ partialCached "icon" "arrow_drop_down" "arrow_drop_down" }}</span>
-  </button>
-  <div x-show="open" x-collapse class="px-4">
-    {{ markdownify .body }}
-  </div>
-</div>
diff --git a/layouts/partials/components/badge.html b/layouts/partials/components/badge.html
deleted file mode 100644
index f21b11e96529..000000000000
--- a/layouts/partials/components/badge.html
+++ /dev/null
@@ -1,17 +0,0 @@
-{{- $colors := (dict
-  "amber" "bg-amber-light dark:bg-amber-dark"
-  "blue" "bg-blue-light dark:bg-blue-dark"
-  "green" "bg-green-light dark:bg-green-dark"
-  "red" "bg-red-light dark:bg-red-dark"
-  "violet" "bg-violet-light dark:bg-violet-dark"
-  )
--}}
-
-{{- if not (isset $colors .color) -}}
-{{- errorf "[badge] wrong color name: '%s' - supported values: amber, blue, green, red, violet" .color -}}h
-{{- end -}}
-
-<span
-  class="not-prose px-1 rounded-sm {{ index $colors .color }} text-white text-xs"
-  >{{ .content }}</span
->
diff --git a/layouts/partials/components/card.html b/layouts/partials/components/card.html
deleted file mode 100644
index 0d1b6bead8d1..000000000000
--- a/layouts/partials/components/card.html
+++ /dev/null
@@ -1,52 +0,0 @@
-{{ if (and .image .icon) }}
-  {{ errorf "card: don't use both image and icon: %s" . }}
-{{ end }}
-<div class="not-prose overflow-x-hidden drop-shadow bg-white rounded
-             border border-gray-light-100 dark:bg-gray-dark-200 dark:border-gray-dark-400
-             {{ if .link }}hover:border-gray-light-200 hover:dark:border-gray-dark{{ end }}">
-  {{ if .link }}
-    <a href="{{ .link }}">
-  {{ end }}
-    {{ if .image }}
-    {{/* use the "tall image" layout */}}
-    <div class="flex gap-2 items-stretch">
-      <div class="basis-1/3">
-        <img class="h-full w-full object-cover" src="{{ .image }}" alt="">
-      </div>
-      <div class="basis-2/3 flex flex-col gap-2 p-4">
-        <div class="text-xl text-gray-light-800 leading-snug dark:text-white flex gap-2">
-          {{ markdownify .title }}
-        </div>
-        <div class="text-gray-light-500 leading-snug dark:text-gray-dark-700">
-          {{ .description | markdownify }}
-        </div>
-      </div>
-    </div>
-    {{ else }}
-    {{/* use the default layout */}}
-    <div class="flex flex-col gap-2 p-4">
-      <div class="flex gap-4 items-center">
-        {{ with .icon }}
-          {{ if strings.ContainsAny . "/." }}
-          {{/* image file */}}
-          <img class="w-[32px] invertible" src="{{ . }}" alt="">
-          {{ else }}
-          {{/* icon ligature */}}
-          <span class="icon-svg">{{ partial "icon" . }}</span>
-          {{ end }}
-        {{ end }}
-        <div>
-          <div class="text-xl text-gray-light-800 leading-snug dark:text-white flex items-center gap-2">
-            {{ markdownify .title }}
-          </div>
-        </div>
-      </div>
-      <div class="text-gray-light-600 leading-snug dark:text-gray-dark-700">
-        {{ .description | markdownify }}
-      </div>
-    </div>
-    {{ end }}
-  {{ if .link }}
-    </a>
-  {{ end }}
-</div>
diff --git a/layouts/partials/components/guide-summary.html b/layouts/partials/components/guide-summary.html
deleted file mode 100644
index 0a9c4f4fea35..000000000000
--- a/layouts/partials/components/guide-summary.html
+++ /dev/null
@@ -1,16 +0,0 @@
-<div class="not-prose">
-  <div class="flex flex-col sm:flex-row gap-4 p-6 m-4 bg-gray-light-200 dark:bg-gray-dark-300">
-    <div class="flex-grow flex flex-col sm:items-center">
-      <span><strong>Skill level</strong></span>
-      <span>{{ .Params.skill }}</span>
-    </div>
-    <div class="flex-grow flex flex-col sm:items-center">
-      <span><strong>Time to complete</strong></span>
-      <span>{{ .Params.time }}</span>
-    </div>
-    <div class="flex-grow flex flex-col sm:items-center">
-      <span><strong>Prerequisites</strong></span>
-      <span>{{ .Params.prereq }}</span>
-    </div>
-  </div>
-</div>
diff --git a/layouts/partials/components/support-button.html b/layouts/partials/components/support-button.html
deleted file mode 100644
index 5680f6f6b0a0..000000000000
--- a/layouts/partials/components/support-button.html
+++ /dev/null
@@ -1,7 +0,0 @@
-<a
-  href="https://hub.docker.com/support/contact"
-  class="flex items-center rounded bg-blue-light dark:bg-blue-dark text-white
-  py-2 px-4 z-50"
-  aria-label="Contact support">
-  <span>Contact support</span>
-</a>
\ No newline at end of file
diff --git a/layouts/partials/content-default.html b/layouts/partials/content-default.html
deleted file mode 100644
index 1c96e70c47fc..000000000000
--- a/layouts/partials/content-default.html
+++ /dev/null
@@ -1,20 +0,0 @@
-<div class="flex w-full gap-8">
-  <article class="prose min-w-0 max-w-4xl flex-[2_2_0%] dark:prose-invert">
-    {{ partial "breadcrumbs.html" . }}
-    <h1 data-pagefind-weight="10" class="flex scroll-mt-36 items-center">
-      <span>{{ .Title }}</span>
-    </h1>
-
-    <div class="block lg:hidden">
-      {{ partialCached "pagemeta.html" . . }}
-      <hr />
-    </div>
-    {{ .Content }}
-  </article>
-  <div class="hidden lg:block ml-auto md-dropdown">
-    {{ partial "md-dropdown.html" . }}
-  </div>
-  <div class="-mr-8 -mt-8 hidden min-w-52 flex-1 lg:block">
-    {{ partial "aside.html" . }}
-  </div>
-</div>
diff --git a/layouts/partials/favicon.html b/layouts/partials/favicon.html
deleted file mode 100644
index 0893cdc33f23..000000000000
--- a/layouts/partials/favicon.html
+++ /dev/null
@@ -1,17 +0,0 @@
-{{- $favicon := resources.Get "favicons/docs@2x.ico" }}
-<link
-  rel="icon"
-  type="image/x-icon"
-  href="{{ $favicon.Permalink }}"
-  sizes="129x128"
-/>
-<link
-  rel="apple-touch-icon"
-  type="image/x-icon"
-  href="{{ $favicon.Permalink }}"
-  sizes="129x128"
-/>
-<meta
-  name="msapplication-TileImage"
-  content="{{ $favicon.Permalink }}"
-/>
diff --git a/layouts/partials/footer.html b/layouts/partials/footer.html
deleted file mode 100644
index d35b4ce95f72..000000000000
--- a/layouts/partials/footer.html
+++ /dev/null
@@ -1,99 +0,0 @@
-<div class="flex justify-center py-8 px-4 bg-gray-light-100 dark:bg-gray-dark-200">
-  {{ partialCached "components/support-button.html" . }}
-</div>
-<div class="flex justify-center pt-10 pb-20 px-4 bg-gray-light-100 dark:bg-gray-dark-200">
-  <div class="flex w-full max-w-[840px] flex-col gap-10">
-    <div class="flex flex-col md:flex-row gap-4 items-center justify-evenly">
-      <a class="underline-offset-2 hover:underline" href="https://www.docker.com/">Product offerings</a>
-      <a class="underline-offset-2 hover:underline" href="https://www.docker.com/pricing/">Pricing</a>
-      <a class="underline-offset-2 hover:underline" href="https://www.docker.com/company/">About us</a>
-      {{- with .GetPage "/contribute" }}
-        <a class="underline-offset-2 hover:underline" href="{{ .Permalink }}">{{ .LinkTitle }}</a>
-      {{- end }}
-      <a href="{{ "llms.txt" | relURL }}">Read llms.txt</a>
-    </div>
-    <hr class="text-divider-light dark:text-divider-dark" />
-    <div class="grid lg:grid-cols-3 place-items-center gap-8 grid-cols-1">
-      <p class="text-sm">
-        Copyright © 2013-{{ time.Now.Year}} Docker Inc. All rights reserved.
-      </p>
-      <div class="flex gap-4">
-        <a
-          class="h-8 w-8 rounded-full fill-blue-light dark:fill-blue-dark"
-          title="X (Twitter)"
-          href="http://twitter.com/docker/">
-          {{ (resources.Get "images/TwitterCircle.svg").Content | safe.HTML }}
-        </a>
-        <a
-          class="h-8 w-8 rounded-full fill-blue-light dark:fill-blue-dark"
-          title="LinkedIn"
-          href="https://www.linkedin.com/company/docker">
-          {{ (resources.Get "images/LinkedinCircle.svg").Content | safe.HTML }}
-        </a>
-        <a
-          class="h-8 w-8 rounded-full fill-blue-light dark:fill-blue-dark"
-          title="Instagram"
-          href="https://www.instagram.com/dockerinc/">
-          {{ (resources.Get "images/InstagramCircle.svg").Content | safe.HTML }}
-        </a>
-        <a
-          class="h-8 w-8 rounded-full fill-blue-light dark:fill-blue-dark"
-          title="YouTube"
-          href="http://www.youtube.com/user/dockerrun">
-          {{ (resources.Get "images/YoutubeCircle.svg").Content | safe.HTML }}
-        </a>
-        <a
-          class="h-8 w-8 rounded-full fill-blue-light dark:fill-blue-dark"
-          title="Facebook"
-          href="https://www.facebook.com/docker.run">
-          {{ (resources.Get "images/FacebookCircle.svg").Content | safe.HTML }}
-        </a>
-      </div>
-      <div class="flex items-center gap-4">
-        <a
-          class="underline-offset-2 hover:underline"
-          title="Docker Terms of Service"
-          href="https://www.docker.com/legal/docker-terms-service"
-          >Terms of Service</a>
-        <a
-          class="underline-offset-2 hover:underline"
-          title="Docker Systems Status Page"
-          href="https://www.dockerstatus.com/"
-          >Status</a>
-        <a
-          class="underline-offset-2 hover:underline"
-          title="Docker Legal Terms"
-          href="https://www.docker.com/legal"
-          >Legal</a>
-      </div>
-    </div>
-    <div class="flex justify-between items-center">
-      <button type="button" id="ot-sdk-btn" class="ot-sdk-show-settings">
-        Cookies Settings
-      </button>
-      <div class="flex items-center gap-2">
-        <span>Theme:</span>
-        <button
-          aria-label="Theme switch"
-          id="theme-switch"
-          class="rounded bg-blue-light px-4 py-1 text-white transition
-          hover:bg-blue-light-400 dark:bg-blue-dark-400
-          dark:hover:bg-blue-dark"
-          x-data="{ theme: localStorage.getItem('theme-preference') }"
-          x-init="$watch('theme', value => {
-                localStorage.setItem('theme-preference', value);
-                document.firstElementChild.className = value;
-              })"
-          @click="theme = (theme === 'dark' ? 'light' : 'dark')"
-        >
-          <span class="icon-svg icon-sm dark:hidden"
-            >Light {{ partialCached "icon" "light_mode" "light_mode" }}</span
-          >
-          <span class="icon-svg icon-sm hidden dark:block"
-            >Dark {{ partialCached "icon" "dark_mode" "dark_mode" }}</span
-          >
-        </button>
-      </div>
-    </div>
-  </div>
-</div>
diff --git a/layouts/partials/github-links.html b/layouts/partials/github-links.html
deleted file mode 100644
index 1f7e518b7393..000000000000
--- a/layouts/partials/github-links.html
+++ /dev/null
@@ -1,28 +0,0 @@
-{{- /*
-  Adds links for editing the page or requesting changes:
-  - "Edit this page": Only in production, skips files from `_vendor/` (upstream repositories).
-  - "Request changes": Links to a pre-filled issue form.
-*/ -}}
-{{ if hugo.IsProduction }}
-{{ with .File }}
-{{ if not (in .Filename "/_vendor/") }}
-<p class="flex items-center gap-2">
-  <span class="icon-svg">{{ partialCached "icon" "edit" "edit" }}</span>
-  <a class="link" rel="noopener"
-    href="{{ site.Params.repo }}/edit/main/content/{{ .Path }}">{{- T "editPage" -}}
-    <span class="icon-svg icon-sm">
-      {{ partialCached "icon" "open_in_new" "open_in_new" }}
-    </span></a>
-</p>
-{{ end }}
-{{ end }}
-<p class="flex items-center gap-2">
-  <span class="icon-svg">{{ partialCached "icon" "check" "check" }}</span>
-  <a class="link" rel="noopener"
-    href="{{ site.Params.repo }}/issues/new?template=doc_issue.yml&location={{ .Permalink }}&labels=status%2Ftriage">{{- T "requestChanges" -}}
-    <span class="icon-svg icon-sm">
-      {{ partialCached "icon" "open_in_new" "open_in_new" }}
-    </span></a>
-  </a>
-</p>
-{{ end }}
diff --git a/layouts/partials/guides-stepper.html b/layouts/partials/guides-stepper.html
deleted file mode 100644
index 2dcb364658c6..000000000000
--- a/layouts/partials/guides-stepper.html
+++ /dev/null
@@ -1,58 +0,0 @@
-{{/*- Multi-page guide: render a progress bar -*/}}
-<div class="flex flex-col my-4 items-start text-sm">
-  {{ $totalPages := len .CurrentSection.Pages }}
-  {{/*- initialize the page store
-
-    $stepper_seen controls the color of the item in the stepper
-
-    green: "completed" - index is lower than current page
-    blue: current page
-    gray: next in section
-    for the section page, they're all gray
-
-    default to true if kind = section
-    (make all entries gray)
-
-  -*/}}
-  {{ page.Store.Set "stepper_seen" .IsSection }}
-  {{/*- Loop over the pages in this guide -*/}}
-  {{ range $i, $e := .CurrentSection.Pages }}
-    {{ $isLast := eq (add $i 1) $totalPages }}
-    <div class="flex">
-      <div class="flex flex-col items-center">
-        {{/*- Render the page's index digit (1,2,3,4 etc) -*/}}
-        <a
-          href="{{ .Permalink }}"
-          class="{{ if (page.Store.Get "stepper_seen") }}
-            bg-gray-light-400 dark:bg-gray-dark-400
-          {{ else if (eq . page) }}
-            {{ .Store.Set "stepper_seen" true }} bg-blue-light-400
-            dark:bg-blue-dark-400
-          {{ else }}
-            bg-green-light-400 dark:bg-green-dark-400
-          {{ end }} flex h-8 w-8 items-center justify-center rounded-full text-white no-underline"
-        >
-          {{ add $i 1 }}
-        </a>
-        {{/*- Render the vertical border -*/}}
-        {{ if not $isLast }}
-          <div
-            class="{{ if (page.Store.Get "stepper_seen") }}
-              border-gray-light-400 dark:border-gray-dark-400
-            {{ else if (eq . page) }}
-              border-blue-light-400 dark:border-blue-dark-400
-            {{ else }}
-              border-green-light-400 dark:border-green-dark-400
-            {{ end }} h-6 border-l-2"
-          ></div>
-        {{ end }}
-      </div>
-      {{/*- Render the page's title -*/}}
-      <div class="ml-2 flex self-start h-8 items-center">
-        <a href="{{ .Permalink }}">
-          {{ .LinkTitle }}
-        </a>
-      </div>
-    </div>
-  {{ end }}
-</div>
diff --git a/layouts/partials/header.html b/layouts/partials/header.html
deleted file mode 100644
index dbe0283041d2..000000000000
--- a/layouts/partials/header.html
+++ /dev/null
@@ -1,45 +0,0 @@
-<header class="w-full sticky top-0 z-20 h-16 px-6 text-white bg-gradient-to-r from-blue-light-600 to-blue-light dark:from-blue-dark-200 to-50% dark:to-blue-dark-100">
-  <div class="max-w-[1920px] mx-auto flex lg:gap-8 gap-2 h-full items-center justify-between">
-    <div class="flex h-full items-center lg:gap-8 gap-2">
-      {{- if not .IsHome }}
-      <button x-data @click="$store.showSidebar = true"
-        class="icon-svg block px-4 md:hidden h-full" aria-label="Menu">
-        {{ partialCached "icon" "menu" "menu" }}
-      </button>
-      {{- end }}
-      <div>
-        {{/* main logo */}}
-        <a title="Docker Docs home page" href="{{ site.BaseURL }}">
-          <div class="hidden sm:block">
-            {{- (resources.Get "images/docker-docs-white.svg").Content | safe.HTML -}}
-          </div>
-          <div class="block sm:hidden">
-            {{- (resources.Get "images/docker-docs-white-condensed.svg").Content | safe.HTML -}}
-          </div>
-        </a>
-      </div>
-      <nav class="mt-1 hidden md:block">
-        <ul class="flex text-sm md:text-base lg:gap-4">
-          {{ range site.Menus.main }}
-          <li
-            {{- if or (eq page.Permalink .Page.Permalink) (page.IsDescendant .Page) }}
-              class="border-b-4"
-            {{- else }}
-              class="border-b-4 border-transparent hover:border-white/20"
-            {{- end }}>
-            <a class="block px-2 py-1 whitespace-nowrap" href="{{ .URL }}">{{ .Name }}</a>
-          </li>
-          {{ end }}
-        </ul>
-      </nav>
-    </div>
-    <div class="flex min-w-0 items-center gap-4 flex-grow justify-end">
-      {{ partialCached "search-bar.html" "-" }}
-      <button @click="open = false"
-        class="dark:text-white py-1 px-2 rounded open-kapa-widget flex gap-1 items-center hover:bg-white/20 transition">
-        <span>Ask&nbsp;AI</span>
-        <img src="{{ (resources.Get "images/ai-stars.svg").Permalink }}" alt="AI Stars" />
-      </button>
-    </div>
-  </div>
-</header>
diff --git a/layouts/partials/heading.html b/layouts/partials/heading.html
deleted file mode 100644
index 9df46b60c68b..000000000000
--- a/layouts/partials/heading.html
+++ /dev/null
@@ -1,6 +0,0 @@
-{{ $id := .id | default (anchorize (plainify .text)) }}
-<h{{ .level }} class="{{ .class }} scroll-mt-20" id="{{ $id }}">
-  <a class="text-black dark:text-white no-underline hover:underline" href="#{{ $id }}">
-    {{ .text }}
-  </a>
-</h{{ .level }}>
diff --git a/layouts/partials/icon.html b/layouts/partials/icon.html
deleted file mode 100644
index b09d1634e747..000000000000
--- a/layouts/partials/icon.html
+++ /dev/null
@@ -1,8 +0,0 @@
-{{- $svg := resources.Get (fmt.Printf "icons/%s-fill.svg" .) }}
-{{- if not $svg }}
-  {{- errorf "Failed to get icon: %v\n\n" . }}
-{{ end }}
-{{- if not $svg.Content }}
-  {{- errorf "Failed to get icon: %v\n\n" . }}
-{{- end }}
-{{- safe.HTML $svg.Content -}}
diff --git a/layouts/partials/languages.html b/layouts/partials/languages.html
deleted file mode 100644
index 8f3f5bef3032..000000000000
--- a/layouts/partials/languages.html
+++ /dev/null
@@ -1,21 +0,0 @@
-{{- /*
-  List of languages (taxonomy) chips with images
-  Context: page.Pages
-  */
--}}
-{{- range . -}}
-  {{- if eq .File nil }}
-    {{- errorf "[languages] Undefined language: '%s' in %s" (urlize (strings.ToLower .Title)) page.File.Filename }}
-  {{- end }}
-  {{- if not .Page.Params.icon }}
-    {{- errorf "[languages] language is missing an icon: '%s' in %s" (urlize (strings.ToLower .Title)) page.File.Filename }}
-  {{- end }}
-  <span class="text-sm inline-flex gap-1 items-center rounded-full border
-               border-divider-light dark:border-divider-dark bg-gray-light-100
-               px-2 text-gray-light-800 dark:bg-gray-dark-200
-               dark:text-gray-dark-800 select-none">
-    <img class="py-1" height="18" width="18" title="{{ .Page.LinkTitle }}" src="{{ .Page.Params.icon }}">
-    <span>{{ .Page.LinkTitle }}</span>
-  </span>
-{{- end -}}
-
diff --git a/layouts/partials/md-dropdown.html b/layouts/partials/md-dropdown.html
deleted file mode 100644
index b0a512f9fb2b..000000000000
--- a/layouts/partials/md-dropdown.html
+++ /dev/null
@@ -1,119 +0,0 @@
-<details id="markdownDropdown" class="group relative z-10 inline-block" data-heap-id="markdown-dropdown">
-    <summary
-      class="inline-flex cursor-pointer items-center gap-2 rounded border border-gray-light-200 bg-gray-light-200 px-4 py-2 text-base font-semibold text-black transition-colors hover:bg-gray-light-300 dark:border-gray-dark-200 dark:bg-gray-dark-300 dark:text-white dark:hover:bg-gray-dark-400"
-      data-heap-id="markdown-dropdown-toggle"
-    >
-      <span>Page options</span>
-      <span class="icon-svg transition-transform group-open:rotate-180">
-        {{ partialCached "icon" "arrow_drop_down" "arrow_drop_down" }}
-      </span>
-        <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M19 9l-7 7-7-7" />
-      </svg>
-    </summary>
-
-    <!-- Dropdown menu -->
-    <div
-      class="absolute right-0 z-50 mt-2 w-56 origin-top-right rounded border border-gray-light-200 bg-gray-light-200 p-2 text-sm text-black shadow-md [display:none] group-open:[display:block] dark:border-gray-dark-200 dark:bg-gray-dark-300 dark:text-white"
-      data-heap-id="markdown-dropdown-menu"
-    >
-      <button
-        onclick="copyMarkdown()"
-        data-heap-id="copy-markdown-button"
-        class="flex w-full items-start gap-2 rounded px-2 py-2 text-left transition-colors hover:bg-gray-light-300 dark:hover:bg-gray-dark-400"
-      >
-        <span class="icon-svg mt-[2px] text-base leading-none">
-          {{ partial "icon" "content_copy" }}
-        </span>
-        <span class="icon-svg hidden mt-[2px] text-base leading-none">
-          {{ partial "icon" "check_circle" }}
-        </span>
-        <div class="leading-tight">
-          <div class="text-base">Copy page as Markdown for LLMs</div>
-        </div>
-      </button>
-
-      <button
-        onclick="viewPlainText()"
-        data-heap-id="view-markdown-button"
-        class="flex w-full items-start gap-2 rounded px-2 py-2 text-left transition-colors hover:bg-gray-light-300 dark:hover:bg-gray-dark-400"
-      >
-        <span class="icon-svg mt-[2px] text-base leading-none">
-          {{ partial "icon" "description" }}
-        </span>
-        <div class="leading-tight">
-          <div class="text-base">View page as plain text</div>
-        </div>
-      </button>
-
-      <button
-        onclick="openInDocsAI()"
-        data-heap-id="search-docs-ai-button"
-        class="flex w-full items-start gap-2 rounded px-2 py-2 text-left transition-colors hover:bg-gray-light-300 dark:hover:bg-gray-dark-400"
-      >
-        <span class="icon-svg mt-[2px] text-base leading-none">
-          {{ partial "icon" "search" }}
-        </span>
-        <div class="leading-tight">
-          <div class="text-base">Ask questions with Docs AI</div>
-        </div>
-      </button>
-    </div>
-  </details>
-
-  <script>
-    function getCurrentPlaintextUrl() {
-      const url = window.location.href.split("#")[0].replace(/\/$/, "");
-      return `${url}/index.md`;
-    }
-
-    function copyMarkdown() {
-      fetch(getCurrentPlaintextUrl())
-        .then((response) => response.text())
-        .then((text) => {
-          navigator.clipboard.writeText(text).then(() => {
-            const button = document.querySelector('[data-heap-id="copy-markdown-button"]');
-            if (!button) return;
-
-            const icons = button.querySelectorAll(".icon-svg");
-            const copyIcon = icons[0];
-            const checkIcon = icons[1];
-
-            copyIcon.classList.add("hidden");
-            checkIcon.classList.remove("hidden");
-
-            setTimeout(() => {
-              copyIcon.classList.remove("hidden");
-              checkIcon.classList.add("hidden");
-            }, 2000);
-          });
-        })
-        .catch((err) => {
-          console.error("Error copying markdown:", err);
-        });
-    }
-
-    function viewPlainText() {
-      window.open(getCurrentPlaintextUrl(), "_blank");
-    }
-
-    function openInDocsAI() {
-      const kapaButton = document.querySelector(".open-kapa-widget");
-      if (kapaButton) {
-        kapaButton.click();
-      } else {
-        alert("Couldn't find Docs AI.");
-      }
-    }
-
-    document.addEventListener("click", function (event) {
-      const dropdown = document.getElementById("markdownDropdown");
-
-      if (!dropdown) return;
-
-      const isClickInside = dropdown.contains(event.target);
-
-      if (!isClickInside && dropdown.hasAttribute("open")) {
-        dropdown.removeAttribute("open");
-      }
-    });
-  </script>
\ No newline at end of file
diff --git a/layouts/partials/pagemeta.html b/layouts/partials/pagemeta.html
deleted file mode 100644
index 364ac2102c12..000000000000
--- a/layouts/partials/pagemeta.html
+++ /dev/null
@@ -1,37 +0,0 @@
-{{- /*
-  Renders a table of contents (ToC) for the page.
-  - Uses `.Fragments.Headings` to generate a nested ToC if headings exist and `notoc` is not set to `true`.
-  - Limits heading levels to a min and max range (`$min` and `$max`).
-  - Wraps the ToC in a `data-pagefind-ignore` container to exclude it from search indexing.
-  - Includes a recursive template (`walkHeadingFragments`) to handle nested headings.
-*/ -}}
-{{- $toc := false }}
-{{- with .Fragments }}
-  {{- $toc = and (ne page.Params.notoc true) .Headings }}
-{{- end }}
-{{- with $toc }}
-  <div data-pagefind-ignore class="not-prose">
-  <div class="text-lg pb-0 lg:pb-2">{{ T "tableOfContents" }}</div>
-  <nav class="toc">
-    {{ $root := (index page.Fragments.Headings 0).Headings }}
-    {{- template "walkHeadingFragments" $root }}
-  </nav>
-  </div>
-{{- end }}
-
-{{- define "walkHeadingFragments" }}
-  {{- $min := default 2 page.Params.toc_min }}
-  {{- $max := default 3 page.Params.toc_max }}
-  <ul class="pl-2">
-    {{- range . }}
-      {{- if and (ge .Level $min) (le .Level $max) }}
-        <li>
-          <a class="link lg:no-underline" href="#{{ .ID }}">{{ markdownify .Title }}</a>
-        </li>
-      {{- end }}
-      {{- with .Headings }}
-        {{ template "walkHeadingFragments" . }}
-      {{- end }}
-    {{- end }}
-  </ul>
-{{- end }}
diff --git a/layouts/partials/pagination.html b/layouts/partials/pagination.html
deleted file mode 100644
index de276f98ccc3..000000000000
--- a/layouts/partials/pagination.html
+++ /dev/null
@@ -1,70 +0,0 @@
-{{- if gt .Paginator.TotalPages 1 }}
-  {{ $selectable := "cursor-pointer" }}
-  {{ $active := "hover:text-black dark:hover:text-white underline underline-offset-8" }}
-  {{ $disabled := "cursor-not-allowed text-gray-light dark:text-gray-dark" }}
-  <ul class="flex gap-6 items-center">
-  {{- with .Paginator }}
-    {{- $currentPageNumber := .PageNumber }}
-
-    {{- with .First }}
-      {{- if ne $currentPageNumber .PageNumber }}
-      <li>
-        <a class="{{ $selectable }}" href="{{ .URL }}" aria-label="First">
-          <span class="icon-svg">
-            {{- partialCached "icon" "chevron_backward" "chevron_backward" -}}
-          </span>
-        </a>
-      </li>
-      {{- else }}
-      <li>
-        <a class="{{ $disabled }}" aria-disabled="true" aria-label="First">
-          <span class="icon-svg">
-            {{- partialCached "icon" "chevron_backward" "chevron_backward" -}}
-          </span>
-        </a>
-      </li>
-      {{- end }}
-    {{- end }}
-
-    {{- $slots := 5 }}
-    {{- $start := math.Max 1 (sub .PageNumber (math.Floor (div $slots 2))) }}
-    {{- $end := math.Min .TotalPages (sub (add $start $slots) 1) }}
-    {{- if lt (add (sub $end $start) 1) $slots }}
-      {{- $start = math.Max 1 (add (sub $end $slots) 1) }}
-    {{- end }}
-
-    {{- range $k := seq $start $end }}
-      {{- if eq $.Paginator.PageNumber $k }}
-      <li>
-        <a class="{{ $active }}" aria-current="page" aria-label="Page {{ $k }}">{{ $k }}</a>
-      </li>
-      {{- else }}
-      <li>
-        <a class="{{ $selectable }}" href="{{ (index $.Paginator.Pagers (sub $k 1)).URL }}" aria-label="Page {{ $k }}">{{ $k }}</a>
-      </li>
-      {{- end }}
-    {{- end }}
-
-    {{- with .Last }}
-      {{- if ne $currentPageNumber .PageNumber }}
-      <li>
-        <a class="{{ $selectable }}" href="{{ .URL }}" aria-label="Last">
-          <span class="icon-svg">
-            {{- partialCached "icon" "chevron_forward" "chevron_forward" -}}
-          </span>
-        </a>
-      </li>
-      {{- else }}
-      <li>
-        <a class="{{ $disabled }}" aria-disabled="true" aria-label="Last">
-          <span class="icon-svg">
-            {{- partialCached "icon" "chevron_forward" "chevron_forward" -}}
-          </span>
-        </a>
-      </li>
-      {{- end }}
-    {{- end }}
-  {{- end }}
-  </ul>
-{{- end }}
-
diff --git a/layouts/partials/search-bar.html b/layouts/partials/search-bar.html
deleted file mode 100644
index 6595e32d3ff7..000000000000
--- a/layouts/partials/search-bar.html
+++ /dev/null
@@ -1,122 +0,0 @@
-<!-- search button, mobile (link off to the search page for now) -->
-<a href="/search" class="sm:hidden">
-  <span class="icon-svg">{{ partialCached "icon" "search" "search" }}</span>
-</a>
-<!-- search button -->
-<div x-ref="searchBarRef" x-data="{ open: false }" @click.outside="open = false;"
-  @keyup.escape.window="open = false" id="search-bar"
-  class="hidden min-w-0 sm:flex relative bg-white/10 rounded items-center p-2 sm:w-full xl:w-[400px]">
-  {{ (resources.Get "images/search-ai.svg").Content | safeHTML }}
-  <input x-ref="searchBarInput" type="search" id="search-bar-input" @focus="open = true;"
-    @keyup.enter.prevent="window.location.href = '/search/?q=' + $event.target.value;"
-    @keyup.escape.prevent="open = false;" @keydown.window="(e) => {
-          switch(e.key) {
-          case 'k':
-            if (e.metaKey || e.ctrlKey) {
-              e.preventDefault();
-              $el.focus();
-            }
-            break;
-          }
-        }" class="flex-grow px-2 bg-transparent min-w-0 text-white placeholder:text-white outline-none" placeholder="Search"
-    tabindex="0" />
-  <div x-cloak :class="open && 'hidden'" class="hidden lg:flex border px-1 text-sm border-white rounded items-center">
-    <div class="-mt-0.5">
-      <span x-show="navigator.platform == 'MacIntel'" class="icon-svg icon-sm">{{ partialCached "icon" "keyboard_command_key" "keyboard_command_key" }}</span>
-      <span x-show="navigator.platform != 'MacIntel'" class="icon-svg icon-sm">{{ partialCached "icon" "keyboard_control_key" "keyboard_control_key" }}</span>
-    </div>
-    <span>K</span>
-  </div>
-  <div x-cloak :class="open || 'hidden'">
-    <button @click="$refs.searchBarInput.value = ''; open = false" class="text-white hover:text-white">
-      <span class="icon-svg">{{ partialCached "icon" "close" "close" }}</span>
-    </button>
-  </div>
-  <div x-show="open" x-cloak
-    class="absolute px-6 py-4 right-0 w-screen max-w-xl top-full bg-background-light dark:bg-background-dark rounded shadow-lg z-50">
-    <div id="search-bar-results">
-      {{- $emptyState := `<div class="p-2 text-gray-light dark:text-gray-dark">Start typing to search… or try <button @click="open=false" class="open-kapa-widget link">Ask AI</button></div>` }}
-      {{- $emptyState | safe.HTML }}
-      <!-- results -->
-    </div>
-  </div>
-  <script type="module">
-    window.addEventListener("load", async function () {
-      const pagefind = await import("/pagefind/pagefind.js");
-      await pagefind.options({
-        ranking: {
-          termFrequency: 0.2,
-          pageLength: 0.75,
-          termSaturation: 1.4,
-          termSimilarity: 6.0,
-        },
-      });
-
-      const searchBarInput = document.querySelector("#search-bar-input");
-      const searchBarResults = document.querySelector(
-        "#search-bar-results",
-      );
-
-      async function search(e) {
-        const query = e.target.value;
-        if (query === "") {
-          searchBarResults.innerHTML = `{{ $emptyState | safe.HTML }}`;
-          return;
-        }
-        const search = await pagefind.debouncedSearch(query);
-        if (search === null) {
-          return;
-        } else {
-          const resultsLength = search.results.length
-          const resultsData = await Promise.all(search.results.slice(0, 5).map(r => r.data()));
-          const results = resultsData.map((item, index) => ({...item, index: index + 1}));
-
-          if (query) {
-            searchBarResults.classList.remove("hidden");
-          } else {
-            searchBarResults.classList.add("hidden");
-          }
-
-          let resultsHTML = `<div class="p-2 text-gray-light dark:text-gray-dark">${resultsLength} results</div>`;
-          resultsHTML += results
-            .map((item) => {
-              return `<div class="p-2">
-              <div class="flex flex-col">
-                <a class="link" href="${item.url}" data-query="${query}" data-index="${item.index}">${item.meta.title}</a>
-                <p class="text-black dark:text-white overflow-hidden">…${item.excerpt}…</p>
-              </div>
-              </div>`;
-            })
-            .join("");
-          if (resultsLength > 5) {
-            resultsHTML += `<div class="w-fit ml-auto px-4 py-2"><a href="/search/?q=${query}" class="link">Show all results</a></div>`;
-          }
-
-          searchBarResults.innerHTML = resultsHTML;
-        }
-      }
-
-      searchBarInput.addEventListener("input", search);
-
-      // Event delegation for tracking link clicks
-      if (window.heap !== undefined) {
-        searchBarResults.addEventListener('click', function (event) {
-          if (event.target.tagName === 'A' && event.target.closest('.link')) {
-            const searchQuery = event.target.getAttribute('data-query');
-            const resultIndex = event.target.getAttribute('data-index');
-            const url = new URL(event.target.href);
-            const properties = {
-              docs_search_target_path: url.pathname,
-              docs_search_target_title: event.target.textContent,
-              docs_search_query_text: searchQuery,
-              docs_search_target_index: resultIndex,
-              docs_search_source_path: window.location.pathname,
-              docs_search_source_title: document.title,
-            };
-            heap.track("Docs - Search - Click - Result Link", properties);
-          }
-        });
-      }
-    });
-  </script>
-</div>
diff --git a/layouts/partials/sidebar/guides.html b/layouts/partials/sidebar/guides.html
deleted file mode 100644
index 6a51b3474d2a..000000000000
--- a/layouts/partials/sidebar/guides.html
+++ /dev/null
@@ -1,52 +0,0 @@
-{{- /*
-  Renders a sidebar for pages in the `/guides` section.
-  - Detects if the current page is part of a multipage guide (`.Store.Set "multipage"`).
-  - Displays the section's title, summary, languages, tags, and estimated time (`Params.time`).
-  - Includes a stepper navigation (`guides-stepper.html`) for multipage guides.
-  - Optionally lists resource links from `Params.resource_links`.
-  - Provides a link back to the main `/guides/` index.
-*/ -}}
-<div class="flex flex-col gap-4 px-4 pt-2">
-  {{- $root := . }}
-  {{- .Store.Set "multipage" false }}
-  {{- if ne .CurrentSection .FirstSection }}
-    {{- $root = .CurrentSection }}
-    {{- .Store.Set "multipage" true }}
-  {{- end }}
-  <div class="font-semibold">
-    <a href="{{ $root.Permalink }}">{{ $root.Title }}</a>
-  </div>
-  <div>{{ $root.Summary }}</div>
-  <div class="space-y-4">
-  <div class="flex flex-wrap gap-2">
-    {{- with ($root.GetTerms "languages") }}
-        {{ partial "languages.html" . }}
-    {{- end }}
-    {{- with ($root.GetTerms "tags") }}
-        {{ partial "tags.html" . }}
-    {{- end }}
-  </div>
-  {{- with ($root.Params.time) }}
-    <div class="flex gap-2 text-gray-light dark:text-gray-dark">
-      <span class="icon-svg"
-        >{{ partialCached "icon" "schedule" "schedule" }}</span
-      >
-      <span>{{ . }}</span>
-    </div>
-  {{- end -}}
-  </div>
-  {{- if (.Store.Get "multipage") }}
-    {{- partial "guides-stepper.html" . }}
-  {{- end }}
-  {{- with $root.Params.resource_links }}
-  <div class="space-y-2">
-    <p>Resources:</p>
-    <ul class="ml-4 space-y-2">
-      {{- range . }}
-        <li><a href="{{ .url }}" class="link">{{ .title }}</a></li>
-      {{- end }}
-    </ul>
-  </div>
-  {{- end }}
-  <a href="/guides/" class="mt-2 link">« Back to all guides</a>
-</div>
diff --git a/layouts/partials/sidebar/mainnav.html b/layouts/partials/sidebar/mainnav.html
deleted file mode 100644
index 7055a6f79f6e..000000000000
--- a/layouts/partials/sidebar/mainnav.html
+++ /dev/null
@@ -1,54 +0,0 @@
-{{- /*
-  Complements the section-specific sidebar navigation.
-  - Renders the main navigation for site sections, linking to the current or ancestor section/page.
-  - Uses the `site.Menus.main` configuration to determine primary navigation structure.
-  - Toggles visibility of nested menu items for the main sections.
-*/ -}}
-<!-- Main navigation for the sidebar -->
-<div class="py-2 px-4" x-data="{ expanded: false }">
-  <div class="flex w-full items-center justify-between">
-    <!-- Current section: use menu, fall back to current section or page -->
-    {{- $curr := .FirstSection }}
-    {{- if eq $curr site.Home }}
-      {{- $curr = . }}
-    {{- end }}
-    {{- range site.Menus.main }}
-      {{- if or (.Page.IsAncestor page) (eq .Page page) }}
-        {{- $curr = .Page }}
-      {{- end }}
-    {{- end }}
-    <a class="hover:text-blue-light dark:hover:text-blue-dark" href="{{ $curr.Permalink }}">
-      {{- with $curr.Params.icon }}
-        <span class="pr-2 icon-sm icon-svg">
-          {{- partialCached "icon.html" . . -}}
-        </span>
-      {{- end }}
-      {{- $curr.LinkTitle -}}
-    </a>
-    <button @click="expanded = !expanded" class="rounded hover:bg-gray-light-300 hover:dark:bg-gray-dark-300">
-      <span x-show="! expanded" class="icon-svg">
-        {{ partialCached "icon" "arrow_drop_down" "arrow_drop_down" }}
-      </span>
-      <span x-cloak x-show="expanded" class="icon-svg">
-        {{ partialCached "icon" "arrow_drop_up" "arrow_drop_up" }}
-      </span>
-    </button>
-  </div>
-  <ul x-cloak x-show="expanded" class="pt-4 space-y-4">
-    {{ range site.Menus.main }}
-      {{ if ne page.FirstSection .Page }}
-      <li>
-        <a class="hover:text-blue-light dark:hover:text-blue-dark" href="{{ .URL }}">
-          {{- with .Page.Params.icon }}
-            <span class="pr-2 icon-sm icon-svg">
-              {{- partialCached "icon.html" . . -}}
-            </span>
-          {{- end }}
-          {{- .Name }}
-        </a>
-      </li>
-      {{ end }}
-    {{ end }}
-  </ul>
-</div>
-<hr class="m-2 text-gray-light-200 dark:text-gray-dark-300" />
diff --git a/layouts/partials/sidebar/sections.html b/layouts/partials/sidebar/sections.html
deleted file mode 100644
index 25c84cbf3b75..000000000000
--- a/layouts/partials/sidebar/sections.html
+++ /dev/null
@@ -1,107 +0,0 @@
-{{- /*
-  This template recursively renders the sidebar navigation, grouping pages by `Params.sidebar.groups`.
-  Highlights:
-  - Supports hierarchical navigation with collapsible sections (`renderList` template).
-  - Dynamically applies current page highlighting and expanded states.
-  - Handles external links via `Params.sidebar.goto` in `renderSingle`.
-  - Requires `Params.sitemap` and `Params.sidebar` for filtering and behavior.
-*/ -}}
-<!-- section tree -->
-<nav class="md:text-sm flex flex-col">
-  <div
-    class="block py-4 md:hidden text-gray-light dark:text-gray-dark">This section</div>
-  <ul>
-    {{ template "renderChildren" .FirstSection }}
-  </ul>
-</nav>
-
-{{ define "renderChildren" }}
-  {{- $pages := where .Pages "Params.sitemap" "ne" "false" }}
-  {{- if .Params.sidebar.reverse }}
-    {{ $pages = .Pages.Reverse }}
-  {{- end }}
-  {{- $ungrouped := where $pages "Params.sidebar.group" "==" nil }}
-  {{- range $ungrouped }}
-    {{- if .IsSection }}
-      {{- template "renderList" . }}
-    {{- else }}
-      {{- template "renderSingle" . }}
-    {{- end }}
-  {{- end }}
-  {{- range .Params.sidebar.groups }}
-    <li class="px-2 py-2 pb-2 text-gray-light dark:text-gray-dark uppercase
-      text-xs font-semibold">{{ . }}</li>
-    {{- range where $pages "Params.sidebar.group" . }}
-      {{- if .IsSection }}
-        {{- template "renderList" . }}
-      {{- else }}
-        {{- template "renderSingle" . }}
-      {{- end }}
-    {{- end }}
-  {{- end }}
-{{ end }}
-
-{{/* Recursive template for sidebar items */}}
-{{ define "renderList" }}
-  {{ $isCurrent := eq page . }}
-  {{ $expanded := or $isCurrent (page.IsDescendant .) }}
-  <li x-data="{ expanded: {{$expanded}} }">
-    <div class="rounded px-4 w-full flex items-center justify-between{{ if $isCurrent }} bg-gray-light-200 dark:bg-gray-dark-200{{ end }}">
-      <div class="w-full py-2 truncate">
-        {{- if .Permalink }}
-          {{/* If the link is not empty, use it */}}
-          <a {{ if $isCurrent }}aria-current="page" id="sidebar-current-page" {{ end }}
-              class="block select-none hover:text-blue-light hover:dark:text-blue-dark"
-            href="{{ .Permalink }}">
-            {{ template "renderTitle" . }}
-          </a>
-        {{- else }}
-          {{/* Otherwise, just expand the section */}}
-          <button @click="expanded = !expanded"
-            class="w-full text-left select-none hover:text-blue-light hover:dark:text-blue-dark">
-            {{ template "renderTitle" . }}
-          </button>
-        {{- end }}
-      </div>
-      <button @click="expanded = !expanded" class="hover:bg-gray-light-300 hover:dark:bg-gray-dark-300 rounded">
-        <span :class="{ 'hidden' : expanded }" class="icon-svg {{ if $expanded }}hidden{{ end }}">
-          {{ partialCached "icon" "arrow_drop_down" "arrow_drop_down" }}
-        </span>
-        <span :class="{ 'hidden' : !expanded }" class="icon-svg {{ if not $expanded }}hidden{{ end }}">
-          {{ partialCached "icon" "arrow_drop_up" "arrow_drop_up" }}
-        </span>
-      </button>
-    </div>
-    <ul :class="{ 'hidden' : !expanded }" class="{{if not $expanded}}hidden {{end}}ml-3">
-      {{ template "renderChildren" . }}
-    </ul>
-  </li>
-{{ end }}
-
-{{ define "renderSingle" }}
-  {{- if .Params.sidebar.goto }}
-    <li class="px-4 hover:text-blue-light hover:dark:text-blue-dark">
-      <a class="py-2 w-full truncate block"
-         href="{{ .Params.sidebar.goto }}"
-         title="{{ .LinkTitle }}">
-        {{ template "renderTitle" . }}
-      </a>
-    </li>
-  {{- else }}
-    {{ $isCurrent := eq page . }}
-    <li class="rounded px-4 hover:text-blue-light hover:dark:text-blue-dark
-      {{ if $isCurrent }} bg-gray-light-200 dark:bg-gray-dark-200{{ end }}">
-      <a {{ if $isCurrent }}aria-current="page" id="sidebar-current-page" {{ end }} class="py-2 w-full truncate block"
-        href="{{ .Permalink }}" title="{{ .LinkTitle }}">
-        {{ template "renderTitle" . }}
-      </a>
-    </li>
-  {{- end }}
-{{ end }}
-
-{{ define "renderTitle" }}
-  {{ .LinkTitle }}
-  {{- with .Params.sidebar.badge }}
-    <span>{{- partial "components/badge.html" (dict "color" .color "content" .text) }}</span>
-  {{- end }}
-{{ end }}
\ No newline at end of file
diff --git a/layouts/partials/sidebar/tags.html b/layouts/partials/sidebar/tags.html
deleted file mode 100644
index fd1e70d0ce8f..000000000000
--- a/layouts/partials/sidebar/tags.html
+++ /dev/null
@@ -1,17 +0,0 @@
-{{- /*
-  Renders a flat list of tags for the "tags" taxonomy.
-  - Unlike `sections.html`, this template is based on taxonomy terms, not section pages.
-  - Highlights the current tag page and links to all tag pages.
-*/ -}}
-<ul class="md:text-sm">
-  {{- range site.Taxonomies.tags }}
-    <li class="pl-4 hover:text-blue-light hover:dark:text-blue-dark
-    {{ if eq .Page page }} bg-gray-light-200 dark:bg-gray-dark-200{{ end }}">
-      <a class="py-2 w-full truncate block"
-         href="{{ .Page.Permalink }}"
-         title="{{ .Page.LinkTitle }}">
-        {{ .Page.LinkTitle }}
-      </a>
-    </li>
-  {{- end }}
-</ul>
diff --git a/layouts/partials/tags.html b/layouts/partials/tags.html
deleted file mode 100644
index 63eece39393c..000000000000
--- a/layouts/partials/tags.html
+++ /dev/null
@@ -1,20 +0,0 @@
-{{- /*
-  List of tag "chips" as links
-  Context: page.Pages
-  */
--}}
-{{- range . -}}
-  {{- if eq .File nil }}
-    {{- errorf "[tags] Undefined tag: '%s' in %s" (urlize (strings.ToLower .Title)) page.File.Filename }}
-  {{- end }}
-<a class="text-sm inline-flex items-center rounded-full border
-          border-divider-light dark:border-divider-dark bg-gray-light-100 px-2
-          text-gray-light-800 dark:bg-gray-dark-200 dark:text-gray-dark-800
-          select-none"
-  href="{{ .Permalink }}">
-    <span class="icon-svg icon-sm pb-0.5">
-      {{ partialCached "icon" "tag" "tag" }}
-    </span>
-    <span>{{ .LinkTitle }}</span>
-</a>
-{{- end -}}
diff --git a/layouts/partials/tooltip.html b/layouts/partials/tooltip.html
deleted file mode 100644
index 5c4cc30be6e7..000000000000
--- a/layouts/partials/tooltip.html
+++ /dev/null
@@ -1,15 +0,0 @@
-{{- /*
-  Renders a tooltip component using Floating UI for positioning.
-  See script at `assets/js/src/tooltip.js` for functionality.
-*/ -}}
-<div data-tooltip-wrapper>
-  <div data-tooltip-button class="icon-svg flex items-center text-blue-light dark:text-blue-dark">
-    {{ partialCached "icon" "help" "help" }}
-  </div>
-  <div data-tooltip-body
-    class="absolute left-0 top-0 hidden max-w-56 rounded bg-gray-light-700 p-2 text-white dark:bg-gray-dark-300"
-    role="tooltip">
-    {{ . }}
-    <div data-tooltip-arrow class="absolute h-2 w-2 rotate-45 bg-gray-light-700 dark:bg-gray-dark-300"></div>
-  </div>
-</div>
diff --git a/layouts/partials/utils/css.html b/layouts/partials/utils/css.html
deleted file mode 100644
index 5278447a177d..000000000000
--- a/layouts/partials/utils/css.html
+++ /dev/null
@@ -1,15 +0,0 @@
-{{- /*
-  Processes and links the main CSS file (`assets/css/styles.css`).
-  - Applies PostCSS, minification, fingerprinting, and post-processing in production.
-  - Adds inline CSS to hide injected images in production builds.
-*/ -}}
-{{ $styles := resources.Get "css/styles.css" }}
-{{ $styles = $styles | css.PostCSS }}
-{{ if hugo.IsProduction }}
-  {{ $styles = $styles | minify | fingerprint | resources.PostProcess }}
-<style>
-/* hide img injected by prod scripts */
-body > img { display: none }
-</style>
-{{ end }}
-<link href="{{ $styles.Permalink }}" rel="stylesheet" />
diff --git a/layouts/samples/single.html b/layouts/samples/single.html
index 695a3328c343..a40820bc59a7 100644
--- a/layouts/samples/single.html
+++ b/layouts/samples/single.html
@@ -1,13 +1,8 @@
-{{ define "left" }}
-  {{ partial "sidebar/mainnav.html" . }}
-  {{ partial "sidebar/sections.html" . }}
-{{ end }}
-
-{{ define "main" }}
-  {{ partial "breadcrumbs.html" . }}
-  <article class="prose max-w-none dark:prose-invert">
+{{ define "article" }}
+  <article class="prose dark:prose-invert max-w-none">
+    {{ partial "breadcrumbs.html" . }}
     {{ with .Title }}
-    <h1 class="scroll-mt-36">{{ . }}</h1>
+      <h1>{{ . }}</h1>
     {{ end }}
     <table>
       <thead>
@@ -17,7 +12,7 @@ <h1 class="scroll-mt-36">{{ . }}</h1>
         </tr>
       </thead>
       <tbody>
-        {{ range site.Data.samples.samples }}
+        {{ range hugo.Data.samples.samples }}
           {{ if in .services $.Params.service }}
             <tr>
               <td>{{ printf "[%s](%s)" .title .url | markdownify }}</td>
@@ -51,7 +46,3 @@ <h2>Looking for more samples?</h2>
     </ul>
   </article>
 {{ end }}
-
-{{ define "right" }}
-  {{ partial "aside.html" . }}
-{{ end }}
diff --git a/layouts/samples/single.markdown.md b/layouts/samples/single.markdown.md
new file mode 100644
index 000000000000..c7936ffaeca8
--- /dev/null
+++ b/layouts/samples/single.markdown.md
@@ -0,0 +1,9 @@
+# {{ .Title }}
+
+| Name | Description |
+|------|-------------|
+{{- range hugo.Data.samples.samples }}
+{{- if in .services $.Params.service }}
+| [{{ .title }}]({{ .url }}) | {{ chomp .description }} |
+{{- end }}
+{{- end }}
diff --git a/layouts/sbx-cli.html b/layouts/sbx-cli.html
new file mode 100644
index 000000000000..77c59e9e47ca
--- /dev/null
+++ b/layouts/sbx-cli.html
@@ -0,0 +1,212 @@
+{{ define "article" }}
+  {{ $data := index hugo.Data.sbx_cli .Params.datafile }}
+
+  {{ .Store.Set "headings" slice }}
+  <article class="prose min-w-0 max-w-4xl dark:prose-invert">
+    {{ partial "breadcrumbs.html" . }}
+    <div class="flex items-start justify-between gap-4">
+      <h1>{{ .Title }}</h1>
+    </div>
+
+    {{- /* Summary table */ -}}
+    <div class="overflow-x-auto">
+      <table>
+        <tbody>
+          {{ with $data.synopsis }}
+          <tr>
+            <th class="text-left w-32">Description</th>
+            <td>{{ . }}</td>
+          </tr>
+          {{ end }}
+          {{ with $data.usage }}
+          <tr>
+            <th class="text-left w-32">Usage</th>
+            <td><code>{{ . }}</code></td>
+          </tr>
+          {{ end }}
+        </tbody>
+      </table>
+    </div>
+
+    {{- /* Experimental callout (command-level) */ -}}
+    {{ if $data.experimental }}
+      <div class="px-4 border-l-2 border-l-magenta-light dark:border-l-magenta-dark">
+        <p class="not-prose flex gap-2 items-center text-magenta-light dark:text-magenta-dark">
+          <span class="icon-svg pb-1">{{ partialCached "icon" "beaker" "beaker" }}</span>
+          <strong>{{ i18n "experimental" }}</strong>
+        </p>
+        <p><strong>This command is experimental.</strong></p>
+        <p>
+          Experimental features are intended for testing and feedback as their
+          functionality or design may change between releases without warning or
+          can be removed entirely in a future release.
+        </p>
+      </div>
+    {{ end }}
+
+    {{- /* Description */ -}}
+    {{ with $data.description }}
+      {{ $heading := dict "level" 2 "text" "Description" }}
+      {{ partialCached "heading.html" $heading "sbx-cli-description" }}
+      {{ $.Store.Add "headings" $heading }}
+      {{ . | $.RenderString (dict "display" "block") }}
+    {{ end }}
+
+    {{- /* Subcommands (for section pages) */ -}}
+    {{ if eq .Kind "section" }}
+      {{ $heading := dict "level" 2 "text" "Commands" }}
+      {{ partialCached "heading.html" $heading "sbx-cli-commands" }}
+      {{ $.Store.Add "headings" $heading }}
+      <table>
+        <thead>
+          <tr>
+            <th class="text-left">Command</th>
+            <th class="text-left">Description</th>
+          </tr>
+        </thead>
+        <tbody>
+          {{ range .Pages }}
+            {{ if .Params.datafile }}
+              {{ $child := index hugo.Data.sbx_cli .Params.datafile }}
+              <tr>
+                <td class="text-left"><a class="link" href="{{ .Permalink }}"><code>{{ .Title }}</code></a></td>
+                <td class="text-left">
+                  <span class="inline-flex items-center gap-2">
+                    {{ if $child.experimental }}
+                      {{ partialCached "components/badge.html" (dict "color" "violet" "content" "experimental") "sbx-exp" }}
+                    {{ end }}
+                    {{ $child.synopsis }}
+                  </span>
+                </td>
+              </tr>
+            {{ end }}
+          {{ end }}
+        </tbody>
+      </table>
+    {{ end }}
+
+    {{- /* Options */ -}}
+    {{ with $data.options }}
+      {{ $opts := where . "name" "ne" "help" }}
+      {{ with $opts }}
+        {{ $heading := dict "level" 2 "text" "Options" }}
+        {{ partialCached "heading.html" $heading "sbx-cli-options" }}
+        {{ $.Store.Add "headings" $heading }}
+        <div class="overflow-x-auto">
+          <table>
+            <thead class="bg-gray-100 dark:bg-gray-800">
+              <tr>
+                <th class="p-2">Option</th>
+                <th class="p-2">Default</th>
+                <th class="p-2">Description</th>
+              </tr>
+            </thead>
+            <tbody>
+              {{ range . }}
+                <tr>
+                  <td>
+                    <code>{{ with .shorthand }}-{{ . }}, {{ end }}--{{ .name }}</code>
+                  </td>
+                  {{ $skipDefault := `[],false,` }}
+                  <td>
+                    {{ with .default_value }}
+                      {{ cond (in $skipDefault .) "" (printf "<code>%s</code>" . | safeHTML) }}
+                    {{ end }}
+                  </td>
+                  <td>
+                    <span class="inline-flex items-center gap-2">
+                      {{ with .experimental }}
+                        {{ partialCached "components/badge.html" (dict "color" "violet" "content" "experimental") "sbx-exp" }}
+                      {{ end }}
+                      {{ with .usage }}
+                        {{ strings.TrimSpace . }}
+                      {{ end }}
+                    </span>
+                  </td>
+                </tr>
+              {{ end }}
+            </tbody>
+          </table>
+        </div>
+      {{ end }}
+    {{ end }}
+
+    {{- /* Inherited (global) options */ -}}
+    {{ with $data.inherited_options }}
+      {{ $opts := where . "name" "ne" "help" }}
+      {{ with $opts }}
+        {{ $heading := dict "level" 2 "text" "Global options" }}
+        {{ partialCached "heading.html" $heading "sbx-cli-global-options" }}
+        {{ $.Store.Add "headings" $heading }}
+        <div class="overflow-x-auto">
+          <table>
+            <thead class="bg-gray-100 dark:bg-gray-800">
+              <tr>
+                <th class="p-2">Option</th>
+                <th class="p-2">Default</th>
+                <th class="p-2">Description</th>
+              </tr>
+            </thead>
+            <tbody>
+              {{ range . }}
+                <tr>
+                  <td>
+                    <code>{{ with .shorthand }}-{{ . }}, {{ end }}--{{ .name }}</code>
+                  </td>
+                  {{ $skipDefault := `[],false,` }}
+                  <td>
+                    {{ with .default_value }}
+                      {{ cond (in $skipDefault .) "" (printf "<code>%s</code>" . | safeHTML) }}
+                    {{ end }}
+                  </td>
+                  <td>
+                    <span class="inline-flex items-center gap-2">
+                      {{ with .experimental }}
+                        {{ partialCached "components/badge.html" (dict "color" "violet" "content" "experimental") "sbx-exp" }}
+                      {{ end }}
+                      {{ with .usage }}
+                        {{ strings.TrimSpace . }}
+                      {{ end }}
+                    </span>
+                  </td>
+                </tr>
+              {{ end }}
+            </tbody>
+          </table>
+        </div>
+      {{ end }}
+    {{ end }}
+
+    {{- /* Examples */ -}}
+    {{ with $data.example }}
+      {{ $heading := dict "level" 2 "text" "Examples" }}
+      {{ partialCached "heading.html" $heading "sbx-cli-examples" }}
+      {{ $.Store.Add "headings" $heading }}
+      {{- /* Dedent: strip up to 6 leading spaces from each line */ -}}
+      {{ $dedented := replaceRE `(?m)^ {2,6}` "" . }}
+      {{ $code := printf "```console\n%s\n```" (strings.TrimSpace $dedented) }}
+      {{ $code | $.RenderString (dict "display" "block") }}
+    {{ end }}
+
+  </article>
+{{ end }}
+
+{{ define "right" }}
+  <div class="hidden min-w-52 flex-1 lg:block">
+    <aside class="sticky top-16 h-[calc(100vh-64px)] min-w-52 space-y-4 overflow-y-auto py-4 w-full">
+      <div id="TableOfContents">
+        <div class="text-lg pb-2">{{ T "tableOfContents" }}</div>
+        <nav class="toc">
+          <ul>
+            {{ range (.Store.Get "headings") }}
+              {{ $text := .text }}
+              <li{{ with .level }} class="pl-{{ . }}"{{ end }}>
+                <a href="#{{ $text | anchorize }}">{{ markdownify $text }}</a>
+              </li>
+            {{ end }}
+          </ul>
+        </nav>
+      </div>
+    </aside>
+  </div>
+{{ end }}
diff --git a/layouts/security-announcements.rss.xml b/layouts/security-announcements.rss.xml
new file mode 100644
index 000000000000..88134d7838ab
--- /dev/null
+++ b/layouts/security-announcements.rss.xml
@@ -0,0 +1,19 @@
+{{- $_ := .Content -}}
+<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
+  <channel>
+    <title>Docker Docs - Security Announcements</title>
+    <description>Docker security announcements and updates</description>
+    <link>{{ .Permalink }}</link>
+    <generator>Hugo -- gohugo.io</generator>
+    <language>{{ .Site.Language.Locale | default "en" }}</language>
+    <lastBuildDate>{{ now.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}</lastBuildDate>
+    <atom:link href="{{ .Permalink }}index.xml" rel="self" type="application/rss+xml" />
+    {{- range (index .Fragments.Headings 0).Headings }}
+    <item>
+      <title>{{ .Title }}</title>
+      <link>{{ $.Permalink }}#{{ .ID }}</link>
+      <guid>security-{{ .ID }}</guid>
+    </item>
+    {{- end }}
+  </channel>
+</rss>
diff --git a/layouts/series.html b/layouts/series.html
new file mode 100644
index 000000000000..dc40a84774f8
--- /dev/null
+++ b/layouts/series.html
@@ -0,0 +1,47 @@
+{{ define "article" }}
+<article class="prose max-w-none dark:prose-invert">
+  {{ partial "breadcrumbs.html" . }}
+  <h1 data-pagefind-weight="10" class="scroll-mt-36">{{ .Title }}</h1>
+  <div class="block lg:hidden">
+    {{ partialCached "pagemeta.html" . . }}
+    <hr />
+  </div>
+  <div class="text-lg">{{ .Summary }}</div>
+  {{- if or .Params.proficiencyLevel .Params.time .Params.prerequisites }}
+  <div class="not-prose">
+    <div class="mt-1.5 mb-1.5 flex flex-col gap-4 rounded-sm bg-gray-100 p-6 sm:flex-row dark:bg-gray-800">
+      {{- with .Params.proficiencyLevel }}
+      <div class="flex flex-grow flex-col sm:items-center">
+        <span><strong>Skill level</strong></span>
+        <span>{{ . }}</span>
+      </div>
+      {{- end }}
+      {{- with .Params.time }}
+      <div class="flex flex-grow flex-col sm:items-center">
+        <span><strong>Time to complete</strong></span>
+        <span>{{ . }}</span>
+      </div>
+      {{- end }}
+      {{- with .Params.prerequisites }}
+      <div class="flex flex-grow flex-col sm:items-center">
+        <span><strong>Prerequisites</strong></span>
+        <span>{{ . }}</span>
+      </div>
+      {{- end }}
+    </div>
+  </div>
+  {{- end }}
+  {{ .Content }}
+  {{ partial "heading.html" (dict "text" "Modules" "level" 2) }}
+  <ol>
+    {{- range .Pages }}
+    <li>
+      <a class="link" href="{{ .Permalink }}">{{ .LinkTitle }}</a>
+      <p>{{ plainify .Description }}</p>
+    </li>
+    {{- end }}
+  </ol>
+</article>
+{{ end }}
+
+{{ define "right" }}{{ end }}
diff --git a/layouts/shortcodes/admin-domain-audit.md b/layouts/shortcodes/admin-domain-audit.md
deleted file mode 100644
index 09a693849550..000000000000
--- a/layouts/shortcodes/admin-domain-audit.md
+++ /dev/null
@@ -1,30 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $domain_navigation := "Select **My Hub**, your organization, **Settings**, and then **Security**." }}
-{{ $sso_link := "[SSO](/security/for-admins/single-sign-on/)" }}
-{{ $scim_link := "[SCIM](/security/for-admins/provisioning/scim/)" }}
-
-{{ if eq (.Get "product") "admin" }}
-  {{ $product_link = "the [Admin Console](https://admin.docker.com)" }}
-  {{ $domain_navigation = "Select your organization on the **Choose profile** page, and then select **Domain management**." }}
-  {{ $sso_link = "[SSO](/security/for-admins/single-sign-on/)" }}
-  {{ $scim_link = "[SCIM](/security/for-admins/provisioning/scim/)" }}
-{{ end }}
-
-To audit your domains:
-
-1. Sign in to {{ $product_link }}.
-2. {{ $domain_navigation }}
-3. In **Domain Audit**, select **Export Users** to export a CSV file of uncaptured users with the following columns:
-
-   - Name: The name of the user.
-   - Username: The Docker ID of the user.
-   - Email: The email address of the user.
-
-You can invite all the uncaptured users to your organization using the exported CSV file. For more details, see [Invite members](/admin/organization/members/). Optionally, enforce single sign-on or enable SCIM to add users to your organization automatically. For more details, see {{ $sso_link }} or {{ $scim_link }}.
-
-> [!NOTE]
->
-> Domain audit may identify accounts of users who are no longer a part of your organization. If you don't want to add a user to your organization and you don't want the user to appear in future domain audits, you must deactivate the account or update the associated email address.
->
-> Only someone with access to the Docker account can deactivate the account or update the associated email address. For more details, see [Deactivating an account](/admin/organization/deactivate-account/).
->
diff --git a/layouts/shortcodes/admin-domains.html b/layouts/shortcodes/admin-domains.html
deleted file mode 100644
index f3374f4c32d9..000000000000
--- a/layouts/shortcodes/admin-domains.html
+++ /dev/null
@@ -1,35 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $domain_navigation := `Navigate to the domain settings page for your organization. Select **My Hub**, your organization, **Settings**, and then **Security**.` }}
-
-{{ if eq (.Get "product") "admin" }}
-{{ $product_link = "the [Admin Console](https://admin.docker.com)" }}
-{{ $domain_navigation = "Select your organization or company in the left navigation drop-down menu, and then select **Domain management**. Note that when an organization is part of a company, you must select the company and configure the domain for that organization at the company level. Each organization in a company can have its own domain, but it must be configured at the company level." }}
-{{ end }}
-
-
-1. Sign in to {{ $product_link }}.
-2. {{ $domain_navigation }}
-3. Select **Add a domain**.
-4. Continue with the on-screen instructions to get a verification code for
-   your domain as a **TXT Record Value**.
-
-   > [!NOTE]
-   >
-   > Format your domains without protocol or www information, for example,
-   > `yourcompany.example`. This should include all email domains and
-   > subdomains users will use to access Docker, for example
-   > `yourcompany.example` and `us.yourcompany.example`. Public domains such as
-   > `gmail.com`, `outlook.com`, etc. aren’t permitted.
-
-   > [!TIP]
-   >
-   > Make sure that the TXT record name that you create on your DNS matches
-   > the domain you registered on Docker in Step 4. For example,
-   > if you registered the subdomain `us.yourcompany.example`,
-   > you need to create a TXT record within the same name/zone `us`.
-   > A root domain such as `yourcompany.example` needs a TXT record on the
-   > root zone, which is typically denoted with the `@` name for the record.
-
-5. Once you have waited 72 hours for the TXT record verification,
-   you can then select **Verify** next to the domain you've added,
-   and follow the on-screen instructions.
diff --git a/layouts/shortcodes/admin-image-access.html b/layouts/shortcodes/admin-image-access.html
deleted file mode 100644
index a6d03ad3f5a6..000000000000
--- a/layouts/shortcodes/admin-image-access.html
+++ /dev/null
@@ -1,27 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $iam_navigation := "Select **My Hub**, select your organization in the left navigation drop-down menu, and then select **Image access**." }}
-
-{{ if eq (.Get "product") "admin" }}
-  {{ $product_link = "the [Admin Console](https://admin.docker.com)" }}
-  {{ $iam_navigation = "Select your organization in the left navigation drop-down menu, and then select **Image access**." }}
-{{ end }}
-
-1. Sign in to {{ $product_link }}.
-2. {{ $iam_navigation }}
-3. Enable Image Access Management to set the permissions for the following categories of images you can manage:
-
-  - **Organization Images**: Images from your organization are always allowed by default. These images can be public or private created by members within your organization.
-  - **Docker Official Images**: A curated set of Docker repositories hosted on Hub. They provide OS repositories, best practices for Dockerfiles, drop-in solutions, and applies security updates on time.
-  - **Docker Verified Publisher Images**: Images published by Docker partners that are part of the Verified Publisher program and are qualified to be included in the developer secure supply chain.
-  - **Community Images**: These images are disabled by default when Image Access Management is enabled because various users contribute them and they may pose security risks. This category includes Docker-Sponsored Open Source images.
-
-  > [!NOTE]
-  >
-  > Image Access Management is turned off by default. However, owners in your organization have access to all images regardless of the settings.
-
-4. Select the category restrictions for your images by selecting **Allowed**.
-   Once the restrictions are applied, your members can view the organization permissions page in a read-only format.
-
-## Verify the restrictions
-
-The new Image Access Management policy takes effect after the developer successfully authenticates to Docker Desktop using their organization credentials. If a developer attempts to pull a disallowed image type using Docker, they receive an error message.
diff --git a/layouts/shortcodes/admin-org-audit-log.html b/layouts/shortcodes/admin-org-audit-log.html
deleted file mode 100644
index eaed5a993371..000000000000
--- a/layouts/shortcodes/admin-org-audit-log.html
+++ /dev/null
@@ -1,29 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $audit_navigation := "Select **My Hub**, your organization, and then **Activity**." }}
-{{ if eq (.Get "product") "admin" }}
-  {{ $product_link = "the [Admin Console](https://admin.docker.com)" }}
-  {{ $audit_navigation = "Select your organization in the left navigation drop-down menu, and then select **Activity logs**." }}
-{{ end }}
-
-### View the activity logs
-
-To view the activity logs:
-
-1. Sign in to {{ $product_link }}.
-2. {{ $audit_navigation }}
-
-> [!NOTE]
->
-> Docker retains the activity data for a period of three months.
-
-### Customize the activity logs
-
-By default, all activities that occur are displayed on the **Activity** tab. Use the calendar option to select a date range and customize your results. After you have selected a date range, the activity logs of all the activities that occurred during that period are displayed.
-
-> [!NOTE]
->
-> Activities created by the Docker Support team as part of resolving customer issues appear in the activity logs as **dockersupport**.
-
-Select the **All Activities** drop-down to view activities that are specific to an organization, repository, or billing. In Docker Hub, if you select the **Activities** tab from the **Repository** view, you can only filter repository-level activities.
-
-After choosing **Organization**, **Repository**, or **Billing**, you can further refine the results using the **All Actions** drop-down.
diff --git a/layouts/shortcodes/admin-registry-access.html b/layouts/shortcodes/admin-registry-access.html
deleted file mode 100644
index 7e15ad4d5ad3..000000000000
--- a/layouts/shortcodes/admin-registry-access.html
+++ /dev/null
@@ -1,51 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $ram_navigation := "Select **My Hub**, your organization, **Settings**, and then select **Registry Access**." }}
-{{ if eq (.Get "product") "admin" }}
-  {{ $product_link = "the [Admin Console](https://admin.docker.com)" }}
-  {{ $ram_navigation = "Select your organization in the left navigation drop-down menu, and then select **Registry access**." }}
-{{ end }}
-
-To configure Registry Access Management permissions, perform the following steps:
-
-1. Sign in to {{ $product_link }}.
-2. {{ $ram_navigation }}
-3. Enable Registry Access Management to set the permissions for your registry.
-
-   > [!NOTE]
-   >
-   > When enabled, the Docker Hub registry is set by default; however you can
-   > also restrict this registry for your developers.
-
-4. Select **Add registry** and enter your registry details in the applicable
-fields, and then select **Create** to add the registry to your list. You can
-add up to 100 registries/domains.
-5. Verify that the registry appears in your list and select **Save changes**.
-
-Once you add a registry, it can take up to 24 hours for the changes to be
-enforced on your developers’ machines.
-
-If you want to apply the changes sooner, you must force a Docker signout on your
-developers’ machine and have the developers re-authenticate for Docker Desktop.
-See the [Caveats](#caveats) section below to learn more about limitations.
-
-> [!IMPORTANT]
->
-> Starting with Docker Desktop version 4.36, you can enforce sign-in for
-multiple organizations. If a developer belongs to multiple organizations with
-different RAM policies, only the RAM policy for the first organization listed
-in the `registry.json` file, `.plist` file, or registry key is enforced.
-
-> [!TIP]
->
-> Since RAM sets policies about where content can be fetched from, the
-[ADD](/reference/dockerfile/#add) instruction of the Dockerfile when the
-parameter of the ADD instruction is a URL is also subject to registry
-restrictions.
->
-> If you're using ADD to fetch an image or artifact from a trusted registry via
-> URL, make sure the registry's domain is included in your organzation's
-> allowed registries list.
->
-> RAM is not intended to restrict access to general-purpose external URLs, for
-> example, package mirrors or storage services. Attempting to add too many domains
-> may cause errors or hit system limits.
diff --git a/layouts/shortcodes/admin-scim-disable.html b/layouts/shortcodes/admin-scim-disable.html
deleted file mode 100644
index ea4d9cd476ad..000000000000
--- a/layouts/shortcodes/admin-scim-disable.html
+++ /dev/null
@@ -1,13 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $sso_navigation := `Navigate to the SSO settings page for your organization.
-   - Organization: Select **My Hub**, your organization, **Settings**, and then **Security**.` }}
-
-{{ if eq (.Get "product") "admin" }}
-{{ $product_link = "the [Admin Console](https://admin.docker.com)" }}
-{{ $sso_navigation = "Select your organization or company in the left navigation drop-down menu, and then select **SSO and SCIM.**" }}
-{{ end }}
-
-1. Sign in to {{ $product_link }}.
-2. {{ $sso_navigation }}
-3. In the SSO connections table, select the **Actions** icon.
-4. Select **Disable SCIM**.
diff --git a/layouts/shortcodes/admin-scim.html b/layouts/shortcodes/admin-scim.html
deleted file mode 100644
index 48300d8ff3de..000000000000
--- a/layouts/shortcodes/admin-scim.html
+++ /dev/null
@@ -1,13 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $sso_navigation := `Navigate to the SSO settings page for your organization.
-   - Organization: Select **My Hub**, your organization, **Settings**, and then **Security**.` }}
-
-{{ if eq (.Get "product") "admin" }}
-{{ $product_link = "the [Admin Console](https://admin.docker.com)" }}
-{{ $sso_navigation = "Select your organization or company in the left navigation drop-down menu, and then select **SSO and SCIM.**" }}
-{{ end }}
-
-1. Sign in to {{ $product_link }}.
-2. {{ $sso_navigation }}
-3. In the SSO connections table, select the **Actions** icon and **Setup SCIM**.
-4. Copy the **SCIM Base URL** and **API Token** and paste the values into your IdP.
diff --git a/layouts/shortcodes/admin-sso-config.md b/layouts/shortcodes/admin-sso-config.md
deleted file mode 100644
index 7f205e74bffe..000000000000
--- a/layouts/shortcodes/admin-sso-config.md
+++ /dev/null
@@ -1,36 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $sso_navigation := `Navigate to the SSO settings page for your organization. Select **My Hub**, your organization, **Settings**, and then **Security**.` }}
-
-{{ if eq (.Get "product") "admin" }}
-  {{ $product_link = "the [Admin Console](https://admin.docker.com)" }}
-  {{ $sso_navigation = "Select your organization or company from the **Choose profile** page, and then select **SSO and SCIM**. Note that when an organization is part of a company, you must select the company and configure SSO for that organization at the company level. Each organization can have its own SSO configuration and domain, but it must be configured at the company level." }}
-{{ end }}
-
-> [!IMPORTANT]
->
-> If your IdP setup requires an Entity ID and the ACS URL, you must select the
-> **SAML** tab in the **Authentication Method** section. For example, if your
-> Entra ID (formerly Azure AD) Open ID Connect (OIDC) setup uses SAML configuration within Azure
-> AD, you must select **SAML**. If you are [configuring Open ID Connect with Entra ID (formerly Azure AD)](https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/configure-openid-settings) select
-> **Azure AD (OIDC)** as the authentication method. Also, IdP initiated connections
-> aren't supported at this time.
-
-After your domain is verified, create an SSO connection.
-
-1. Sign in to {{ $product_link }}.
-2. {{ $sso_navigation }}
-3. In the SSO connections table select **Create Connection**, and create a name for the connection.
-
-   > [!NOTE]
-   >
-   > You have to verify at least one domain before creating the connections.
-
-4. Select an authentication method, **SAML** or **Azure AD (OIDC)**.
-5. Copy the following fields to add to your IdP:
-
-   - SAML: **Entity ID**, **ACS URL**
-   - Azure AD (OIDC): **Redirect URL**
-
-   ![SAML](/docker-hub/images/saml-create-connection.png)
-
-   ![Azure AD](/docker-hub/images/azure-create-connection.png)
diff --git a/layouts/shortcodes/admin-sso-connect.md b/layouts/shortcodes/admin-sso-connect.md
deleted file mode 100644
index 89ab466a2562..000000000000
--- a/layouts/shortcodes/admin-sso-connect.md
+++ /dev/null
@@ -1,48 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $sso_navigation := `Navigate to the SSO settings page for your organization. Select **My Hub**, your organization, **Settings**, and then **Security**.` }}
-
-{{ if eq (.Get "product") "admin" }}
-  {{ $product_link = "the [Admin Console](https://admin.docker.com)" }}
-  {{ $sso_navigation = "Select your organization or company from the **Choose profile** page, and then select **SSO and SCIM**. Note that when an organization is part of a company, you must select the company and configure SSO for that organization at the company level. Each organization can have its own SSO configuration and domain, but it must be configured at the company level." }}
-{{ end }}
-
-1. In {{ $product_link }}, select the verified domains you want to apply the connection to.
-2. To provision your users, select the organization(s) and/or team(s).
-3. Review your summary and select **Create Connection**.
-
-## Test your SSO configuration
-
-After you’ve completed the SSO configuration process in Docker, you can test the configuration when you sign in to {{ $product_link }} using an incognito browser. Sign in to {{ $product_link }} using your domain email address. You are then redirected to your IdP's login page to authenticate.
-
-1. Authenticate through email instead of using your Docker ID, and test the login process.
-2. To authenticate through CLI, your users must have a PAT before you enforce SSO for CLI users.
-
-> [!IMPORTANT]
->
-> SSO has Just-in-Time (JIT) provisioning enabled by default, unless you have [disabled it](/security/for-admins/provisioning/just-in-time/#sso-authentication-with-jit-provisioning-disabled). This means your users are auto-provisioned to your organization.
->
-> You can change this on a per-app basis. To prevent auto-provisioning users, you can create a security group in your IdP and configure the SSO app to authenticate and authorize only those users that are in the security group. Follow the instructions provided by your IdP:
->
-> - [Okta](https://help.okta.com/en-us/Content/Topics/Security/policies/configure-app-signon-policies.htm)
-> - [Entra ID (formerly Azure AD)](https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-restrict-your-app-to-a-set-of-users)
->
-> Alternatively, see [Manage how users are provisioned](/security/for-admins/single-sign-on/manage/).
-
-The SSO connection is now created. You can continue to set up SCIM without enforcing SSO log-in. For more information about setting up SCIM, see [Set up SCIM](/security/for-admins/provisioning/scim/).
-
-## Optional: Enforce SSO
-
-1. Sign in to {{ $product_link }}.
-2. {{ $sso_navigation }}
-3. In the SSO connections table, select the **Action** icon and then **Enable enforcement**.
-
-   When SSO is enforced, your users are unable to modify their email address and password, convert a user account to an organization, or set up 2FA through Docker Hub. You must enable 2FA through your IdP.
-
-4. Continue with the on-screen instructions and verify that you’ve completed the tasks.
-5. Select **Turn on enforcement** to complete.
-
-Your users must now sign in to Docker with SSO.
-
-> [!IMPORTANT]
->
-> If SSO isn't enforced, users can choose to sign in with either their Docker ID or SSO.
diff --git a/layouts/shortcodes/admin-sso-management-connections.md b/layouts/shortcodes/admin-sso-management-connections.md
deleted file mode 100644
index a8759c363284..000000000000
--- a/layouts/shortcodes/admin-sso-management-connections.md
+++ /dev/null
@@ -1,27 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $sso_navigation := `Navigate to the SSO settings page for your organization. Select **My Hub**, your organization, **Settings**, and then **Security**.` }}
-
-{{ if eq (.Get "product") "admin" }}
-  {{ $product_link = "the [Admin Console](https://app.docker.com/admin)" }}
-  {{ $sso_navigation = "Select your organization or company from the Choose profile page, and then select **SSO and SCIM**. Note that when an organization is part of a company, you must select the company and configure SSO for that organization at the company level. Each organization can have its own SSO configuration and domain, but it must be configured at the company level." }}
-{{ end }}
-
-### Edit a connection
-
-1. Sign in to {{ $product_link }}.
-2. {{ $sso_navigation }}
-3. In the SSO connections table, select the **Action** icon.
-4. Select **Edit connection**.
-5. Follow the on-screen instructions to edit the connection.
-
-### Delete a connection
-
-1. Sign in to {{ $product_link }}.
-2. {{ $sso_navigation }}
-3. In the SSO connections table, select the **Action** icon.
-4. Select **Delete connection**.
-5. Follow the on-screen instructions to delete a connection.
-
-### Deleting SSO
-
-When you disable SSO, you can delete the connection to remove the configuration settings and the added domains. Once you delete this connection, it can't be undone. If an SSO connection is deleted, Docker users must authenticate with their Docker ID and password.
\ No newline at end of file
diff --git a/layouts/shortcodes/admin-sso-management-orgs.md b/layouts/shortcodes/admin-sso-management-orgs.md
deleted file mode 100644
index 12406a00f418..000000000000
--- a/layouts/shortcodes/admin-sso-management-orgs.md
+++ /dev/null
@@ -1,26 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $sso_navigation := "Select **My Hub**, your organization, and then **Settings**." }}
-{{ if eq (.Get "product") "admin" }}
-  {{ $product_link = "the [Admin Console](https://app.docker.com/admin)" }}
-  {{ $sso_navigation = "Select your company from the **Choose profile** page, and then select **SSO and SCIM**." }}
-{{ end }}
-
-### Connect an organization
-
-1. Sign in to {{ $product_link }}.
-2. {{ $sso_navigation }}
-3. In the SSO connections table, select the **Action** icon and then **Edit connection**.
-4. Select **Next** to navigate to the section where connected organizations are listed.
-5. In the **Organizations** drop-down, select the organization to add to the connection.
-6. Select **Next** to confirm or change the default organization and team provisioning.
-7. Review the **Connection Summary** and select **Update connection**.
-
-### Remove an organization
-
-1. Sign in to {{ $product_link }}.
-2. {{ $sso_navigation }}
-3. In the SSO connections table, select the **Action** icon and then **Edit connection**.
-4. Select **Next** to navigate to the section where connected organizations are listed.
-5. In the **Organizations** drop-down, select **Remove** to remove the connection.
-6. Select **Next** to confirm or change the default organization and team provisioning.
-7. Review the **Connection Summary** and select **Update connection**.
diff --git a/layouts/shortcodes/admin-sso-management.md b/layouts/shortcodes/admin-sso-management.md
deleted file mode 100644
index 9a02a6360317..000000000000
--- a/layouts/shortcodes/admin-sso-management.md
+++ /dev/null
@@ -1,22 +0,0 @@
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $sso_navigation := `Navigate to the SSO settings page for your organization. Select **My Hub**, your organization, **Settings**, and then **Security**.` }}
-
-{{ if eq (.Get "product") "admin" }}
-  {{ $product_link = "the [Admin Console](https://app.docker.com/admin)" }}
-  {{ $sso_navigation = "Select your organization or company from the **Choose profile** page, and then select **SSO and SCIM**." }}
-{{ end }}
-
-### Remove a domain from an SSO connection
-
-1. Sign in to {{ $product_link }}.
-2. {{ $sso_navigation }}
-3. In the SSO connections table, select the **Action** icon and then **Edit connection**.
-4. Select **Next** to navigate to the section where the connected domains are listed.
-5. In the **Domain** drop-down, select the **x** icon next to the domain that you want to remove.
-6. Select **Next** to confirm or change the connected organization(s).
-7. Select **Next** to confirm or change the default organization and team provisioning selections.
-8. Review the **Connection Summary** and select **Update connection**.
-
-> [!NOTE]
->
-> If you want to re-add the domain, a new TXT record value is assigned. You must then complete the verification steps with the new TXT record value.
diff --git a/layouts/shortcodes/admin-users.html b/layouts/shortcodes/admin-users.html
deleted file mode 100644
index f305201c23d2..000000000000
--- a/layouts/shortcodes/admin-users.html
+++ /dev/null
@@ -1,131 +0,0 @@
-{{ $invite_button := "**Invite members**" }}
-{{ $export_button := "**Export members**" }}
-{{ $member_navigation := "Select **My Hub**, your organization, and then **Members**." }}
-{{ $remove_button := "**Remove member**" }}
-{{ $product_link := "[Docker Hub](https://hub.docker.com)" }}
-{{ $role_mapping_link := "[SCIM for role mapping](/security/for-admins/provisioning/scim/)" }}
-{{ $export_fields := `The CSV file for an organization contains the following fields:
-* **Name**: The user's name.
-* **Username**: The user's Docker ID.
-* **Email**: The user's email address.
-* **Type**: The type of user. For example, **Invitee** for users who have not accepted the organization's invite,
-  or **User** for users who are members of the organization.
-* **Role**: The user's role in the organization. For example, **Member** or **Owner**.
-* **Teams**: The teams where the user is a member. A team is not listed for invitees.
-* **Date Joined**: The time and date when the user was invited to the organization.` }}
-
-{{ if eq (.Get "product") "admin" }}
-{{ $invite_button = "**Invite**" }}
-{{ $export_button = "the **Action** icon and then select **Export users as CSV**" }}
-{{ $member_navigation = "Select your organization from the **Choose profile** page, and then select **Members**." }}
-{{ $remove_button = "**Remove member**" }}
-{{ $product_link = "the [Admin Console](https://admin.docker.com)" }}
-{{ $role_mapping_link = "[SCIM for role mapping](/security/for-admins/provisioning/scim/)" }}
-{{ if eq (.Get "layer") "company" }}
-{{ $export_fields = `The CSV file for a company contains the following fields:
-* **Name**: The user's name.
-* **Username**: The user's Docker ID.
-* **Email**: The user's email address.
-* **Member of Organizations**: All organizations the user is a member of within a company.
-* **Invited to Organizations**: All organizations the user is an invitee of within a company.
-* **Account Created**: The time and date when the user account was created.` }}
-{{ $member_navigation = "Select your organization from the **Choose profile** page, and then select **Members**." }}
-{{ $remove_button = "**Remove user**" }}
-{{ $role_mapping_link = "[SCIM for role mapping](/security/for-admins/provisioning/scim/)"}}
-{{ end }}
-{{ end }}
-
-Owners can invite new members to an organization via Docker ID, email address, or with a CSV file containing email
-addresses. If an invitee does not have a Docker account, they must create an account and verify their email address
-before they can accept an invitation to join the organization. When inviting members, their pending invitation occupies
-a seat.
-
-### Invite members via Docker ID or email address
-
-Use the following steps to invite members to your organization via Docker ID or email address. To invite a large amount
-of members to your organization via CSV file, see the next section.
-
-1. Sign in to {{ $product_link }}.
-2. {{ $member_navigation }}
-3. Select {{ $invite_button }}.
-4. Select **Emails or usernames**.
-5. Follow the on-screen instructions to invite members.
-   Invite a maximum of 1000 members and separate multiple entries by comma, semicolon, or space.
-
-   > [!NOTE]
-   >
-   > When you invite members, you assign them a role.
-   > See [Roles and permissions](/security/for-admins/roles-and-permissions/)
-   > for details about the access permissions for each role.
-
-   Pending invitations appear in the table. The invitees receive an email with a link to Docker Hub where they can accept
-   or decline the invitation.
-
-### Invite members via CSV file
-
-To invite multiple members to an organization via a CSV file containing email addresses:
-
-1. Sign in to {{ $product_link }}.
-2. {{ $member_navigation }}
-3. Select {{ $invite_button }}.
-4. Select **CSV upload**.
-5. Select **Download the template CSV file** to optionally download an example CSV file.
-   The following is an example of the contents of a valid CSV file.
-
-   ```text
-   email
-   docker.user-0@example.com
-   docker.user-1@example.com
-   ```
-
-   CSV file requirements:
-
-   - The file must contain a header row with at least one heading named `email`. Additional columns are allowed and are
-   ignored in the import.
-   - The file must contain a maximum of 1000 email addresses (rows). To invite more than 1000 users, create multiple CSV
-   files and perform all steps in this task for each file.
-
-6. Create a new CSV file or export a CSV file from another application.
-
-   - To export a CSV file from another application, see the application’s documentation.
-   - To create a new CSV file, open a new file in a text editor, type `email` on the first line, type the user email
-     addresses one per line on the following lines, and then save the file with a .csv extension.
-
-7. Select **Browse files** and then select your CSV file, or drag and drop the CSV file into the **Select a CSV file to
-   upload** box. You can only select one CSV file at a time.
-
-   > [!NOTE]
-   >
-   > If the amount of email addresses in your CSV file exceeds the number of available seats in your organization, you
-   > cannot continue to invite members. To invite members, you can purchase more seats, or remove some email addresses from
-   > the CSV file and re-select the new file. To purchase more seats, see [Add seats to your
-   > subscription](/subscription/add-seats/) or [Contact sales](https://www.docker.com/pricing/contact-sales/).
-
-8. After the CSV file has been uploaded, select **Review**.
-
-   Valid email addresses and any email addresses that have issues appear.
-   Email addresses may have the following issues:
-
-   - Invalid email: The email address is not a valid address.
-     The email address will be ignored if you send invites.
-     You can correct the email address in the CSV file and re-import the file.
-   - Already invited: The user has already been sent an invite email and another invite email will not be sent.
-   - Member: The user is already a member of your organization and an invite email will not be sent.
-   - Duplicate: The CSV file has multiple occurrences of the same email address.
-     The user will be sent only one invite email.
-
-9. Follow the on-screen instructions to invite members.
-
-   > [!NOTE]
-   >
-   > When you invite members, you assign them a role.
-   > See [Roles and permissions](/security/for-admins/roles-and-permissions/)
-   > for details about the access permissions for each role.
-
-Pending invitations appear in the table. The invitees receive an email with a link to Docker Hub where they can accept
-or decline the invitation.
-
-### Invite members via API
-
-You can bulk invite members using the Docker Hub API. For more information, see
-the [Bulk create invites](https://docs.docker.com/reference/api/hub/latest/#tag/invites/paths/~1v2~1invites~1bulk/post) API endpoint.
\ No newline at end of file
diff --git a/layouts/shortcodes/button.html b/layouts/shortcodes/button.html
deleted file mode 100644
index d663143b4846..000000000000
--- a/layouts/shortcodes/button.html
+++ /dev/null
@@ -1,14 +0,0 @@
-{{ $text := .Get "text" }}
-{{ $url := .Get "url" }}
-{{- if (strings.HasPrefix $url "http") -}}
-  {{ $url = $url | safeURL }}
-{{- else if (strings.FindRE `([^_]|^)index.md` $url 1) -}}
-  {{ $url = ref .Page (strings.Replace $url "index.md" "_index.md") }}
-{{- else -}}
-  {{ $url = ref .Page $url }}
-{{- end -}}
-<div class="not-prose my-4">
-  <a href="{{ $url }}"
-    class="cursor-pointer py-2 px-4 rounded bg-blue-light-500 dark:bg-blue-dark-400 hover:bg-blue-light-400 dark:hover:bg-blue-dark-500 text-white">{{
-    $text }}</a>
-</div>
diff --git a/layouts/shortcodes/card.html b/layouts/shortcodes/card.html
deleted file mode 100644
index 6df8788b68ec..000000000000
--- a/layouts/shortcodes/card.html
+++ /dev/null
@@ -1,9 +0,0 @@
-{{ partial "components/card.html"
-  (dict
-    "description" (.Get "description")
-    "link" (.Get "link")
-    "title" (.Get "title")
-    "icon" (.Get "icon")
-    "image" (.Get "image")
-  )
-}}
diff --git a/layouts/shortcodes/cta.html b/layouts/shortcodes/cta.html
deleted file mode 100644
index 754defc5c106..000000000000
--- a/layouts/shortcodes/cta.html
+++ /dev/null
@@ -1,10 +0,0 @@
-<div class="p-4 bg-amber-light-200 dark:bg-amber-dark-200" role="alert">
-  <div class="text-lg">{{ .Get "header" }}</div>
-  {{ .Get "body" | .Page.RenderString (dict "display" "block") }}
-  <div class="not-prose">
-    <a href="{{ .Get "url" }}"
-      class="cursor-pointer py-2 px-4 rounded bg-blue-light-500 dark:bg-blue-dark-400 hover:bg-blue-light-400 dark:hover:bg-blue-dark-500 text-white"
-      >{{ .Get "cta" }}</a>
-  </div>
-</div>
-
diff --git a/layouts/shortcodes/desktop-install-v2.html b/layouts/shortcodes/desktop-install-v2.html
deleted file mode 100644
index e2cf1dac9e8e..000000000000
--- a/layouts/shortcodes/desktop-install-v2.html
+++ /dev/null
@@ -1,46 +0,0 @@
-{{- $all := .Get "all" -}}
-{{- $win := .Get "win" -}}
-{{- $beta_win_arm := .Get "beta_win_arm" -}}
-{{- $mac := .Get "mac" -}}
-{{- $linux := .Get "linux" -}}
-{{- $build_path := .Get "build_path" -}}
-<blockquote {{ if eq $build_path "/" }} class="tip" {{ end }}>
-<p>Download Docker Desktop</p>
-<p>
-  {{- if or $all $win }}
-  <a rel="noopener"
-     href="https://desktop.docker.com/win/main/amd64{{ $build_path }}Docker%20Desktop%20Installer.exe">Windows</a>
-  (<a rel="noopener"
-      href="https://desktop.docker.com/win/main/amd64{{ $build_path }}checksums.txt">checksum</a>) |
-  {{ end }}
-  {{- if or $beta_win_arm }}
-  <a rel="noopener"
-     href="https://desktop.docker.com/win/main/arm64{{ $build_path }}Docker%20Desktop%20Installer.exe">Windows ARM Beta</a>
-  (<a rel="noopener"
-      href="https://desktop.docker.com/win/main/arm64{{ $build_path }}checksums.txt">checksum</a>) |
-  {{ end }}
-  {{- if or $all $mac }}
-  <a rel="noopener" href="https://desktop.docker.com/mac/main/arm64{{ $build_path }}Docker.dmg">Mac
-    with Apple chip</a>
-  (<a rel="noopener"
-      href="https://desktop.docker.com/mac/main/arm64{{ $build_path }}checksums.txt">checksum</a>) |
-  <a rel="noopener" href="https://desktop.docker.com/mac/main/amd64{{ $build_path }}Docker.dmg">Mac
-    with Intel chip</a>
-  (<a rel="noopener"
-      href="https://desktop.docker.com/mac/main/amd64{{ $build_path }}checksums.txt">checksum</a>)
-  {{ end -}}
-  {{- if or $all $linux }}
-  |
-  <a rel="noopener"
-     href="https://desktop.docker.com/linux/main/amd64{{ $build_path }}docker-desktop-amd64.deb">Debian</a>
-  -
-  <a rel="noopener"
-     href="https://desktop.docker.com/linux/main/amd64{{ $build_path }}docker-desktop-x86_64.rpm">RPM</a>
-  -
-  <a rel="noopener"
-     href="https://desktop.docker.com/linux/main/amd64{{ $build_path }}docker-desktop-x86_64.pkg.tar.zst">Arch</a>
-  (<a rel="noopener"
-      href="https://desktop.docker.com/linux/main/amd64{{ $build_path }}checksums.txt">checksum</a>)
-  {{- end -}}
-</p>
-</blockquote>
diff --git a/layouts/shortcodes/grid.html b/layouts/shortcodes/grid.html
deleted file mode 100644
index de1a165e755f..000000000000
--- a/layouts/shortcodes/grid.html
+++ /dev/null
@@ -1,8 +0,0 @@
-{{ $cols := .Get "cols" | default 3 }}
-<div class="not-prose grid grid-cols-1 md:grid-cols-{{ math.Max 2 (sub $cols 1) }} lg:grid-cols-{{ $cols }} gap-4">
-  {{ $items := index .Page.Params (.Get "items" | default "grid") }}
-  {{ range $items }}
-    {{ $opts := dict "title" .title "link" .link "description" .description "icon" .icon "image" .image }}
-    {{ partial "components/card.html" $opts }}
-  {{ end }}
-</div>
diff --git a/layouts/shortcodes/include.html b/layouts/shortcodes/include.html
deleted file mode 100644
index 8beb853f2b94..000000000000
--- a/layouts/shortcodes/include.html
+++ /dev/null
@@ -1,3 +0,0 @@
-{{ $fileToInclude := .Get 0 }}
-{{ $filePath := printf "includes/%s" $fileToInclude }}
-{{ readFile $filePath | safeHTML }}
\ No newline at end of file
diff --git a/layouts/shortcodes/release-date.html b/layouts/shortcodes/release-date.html
deleted file mode 100644
index 884f4cd7b377..000000000000
--- a/layouts/shortcodes/release-date.html
+++ /dev/null
@@ -1,3 +0,0 @@
-<em class="italic text-gray-light-500 dark:text-gray-dark-500"
-  >{{ .Get "date" }}</em
->
diff --git a/layouts/shortcodes/summary-bar.html b/layouts/shortcodes/summary-bar.html
deleted file mode 100644
index 636c703a4114..000000000000
--- a/layouts/shortcodes/summary-bar.html
+++ /dev/null
@@ -1,82 +0,0 @@
-{{ $featureName := .Get "feature_name" }}
-{{ $feature := index site.Data.summary $featureName }}
-{{ if not $feature }}
-  {{ errorf "[summary-bar] invalid feature: %s %v" $featureName .Position }}
-{{ end }}
-{{ if $feature }}
-  {{ $subscriptionIcons := dict
-    "Business" "domain"
-    "Team" "groups"
-    "Pro" "person_add"
-    "Personal" "person"
-    "Available to all" "public"
-  }}
-  {{ $availabilityIcons := dict
-    "Experimental" "science"
-    "Beta" "bolt"
-    "Early Access" "rocket_launch"
-    "GA" "check_circle"
-    "Retired" "package_2"
-  }}
-  {{ $requiresIcon := "browser_updated" }}
-  {{ $forIcon := "admin_panel_settings" }}
-
-
-  <div
-    class="not-prose my-1 flex flex-col border-l-4 border-gray-light-200 bg-gray-light-200 bg-opacity-75 px-4 py-1 dark:bg-gray-dark-300 dark:bg-opacity-75"
-  >
-    {{ with $feature.subscription }}
-      <div class="flex flex-wrap gap-1">
-        <span class="font-bold">Subscription:</span>
-        {{ range . }}
-          <span>{{ . }}</span>
-          <span class="icon-svg">
-            {{ $icon := index $subscriptionIcons . }}
-            {{ if $icon }}
-              {{ partial "icon" $icon }}
-            {{ else }}
-              {{ partial "icon" "default_icon" }}
-            {{ end }}
-          </span>
-        {{ end }}
-      </div>
-    {{ end }}
-
-    {{ with $feature.availability }}
-      {{ $availabilityText := . }}
-      <div class="flex flex-wrap gap-1">
-        <span class="font-bold">Availability:</span>
-        <span>
-          {{ $availabilityText }}
-          {{ range $key, $icon := $availabilityIcons }}
-            {{ if in $availabilityText $key }}
-              <span class="icon-svg">{{ partial "icon" $icon }}</span>
-            {{ end }}
-          {{ end }}
-        </span>
-      </div>
-    {{ end }}
-
-    {{ with $feature.requires }}
-      <div class="flex flex-wrap gap-1">
-        <span class="font-bold">Requires:</span>
-        <span>{{ . | markdownify }}</span>
-        <span class="icon-svg">
-          {{ partial "icon" $requiresIcon }}
-        </span>
-      </div>
-    {{ end }}
-
-    {{ with $feature.for }}
-      <div class="flex flex-wrap gap-1">
-        <span class="font-bold">For:</span>
-        <span>{{ . }}</span>
-        {{ if eq . "Administrators" }}
-          <span class="icon-svg">
-            {{ partial "icon" $forIcon }}
-          </span>
-        {{ end }}
-      </div>
-    {{ end }}
-  </div>
-{{ end }}
\ No newline at end of file
diff --git a/layouts/shortcodes/tabs.html b/layouts/shortcodes/tabs.html
deleted file mode 100644
index 3f1d845fe911..000000000000
--- a/layouts/shortcodes/tabs.html
+++ /dev/null
@@ -1,50 +0,0 @@
-{{ with .Inner }}{{/* don't do anything, just call it */}}{{ end }}
-{{ $first := urlize (index (.Store.Get "tabs") 0).name }}
-{{ $group := .Get "group" }}
-{{ $groupID := fmt.Printf "tabgroup-%s" (urlize $group) }}
-{{ $persist := .Get "persist" }}
-
-<div
-  {{ with $group }}
-    {{ if $persist }}
-      x-data="{ selected: $persist('{{$first}}').as('{{$groupID}}') }"
-    {{ else }}
-      x-data="{ selected: '{{$first}}' }"
-    {{ end }}
-    @tab-select.window="$event.detail.group === '{{ . }}'
-      ? selected = $event.detail.name
-      : null"
-  {{ else }}
-    x-data="{ selected: '{{ $first }}' }"
-  {{ end }}
-  aria-role="tabpanel">
-  <div aria-role="tablist" class="space-x-2">
-    {{ range (.Store.Get "tabs") }}
-      <button
-        class="p-1"
-        :class="selected === '{{ .name | urlize }}' &&
-          'border-blue-light-500 border-b-4 dark:border-b-blue-dark-600'"
-        {{ if $group }}
-          @click="$dispatch('tab-select', { group: '{{ $group }}', name:
-          '{{ .name | urlize }}'})"
-        {{ else }}
-          @click="selected = '{{ .name | urlize }}'"
-        {{ end }}
-      >
-        {{ .name | page.RenderString }}
-      </button>
-    {{ end }}
-  </div>
-  <hr class="!mt-0" />
-  <div>
-    {{ range (.Store.Get "tabs") }}
-      <div
-        aria-role="tab"
-        :class="selected !== '{{ .name | urlize }}' && 'hidden'"
-      >
-        {{ .content | page.RenderString (dict "display" "block") }}
-      </div>
-    {{ end }}
-  </div>
-  <hr />
-</div>
diff --git a/layouts/single.html b/layouts/single.html
new file mode 100644
index 000000000000..834974e186ea
--- /dev/null
+++ b/layouts/single.html
@@ -0,0 +1,5 @@
+{{ define "article" }}
+  <article class="prose dark:prose-invert max-w-4xl">
+    {{ partial "content-default.html" . }}
+  </article>
+{{ end }}
diff --git a/layouts/single.markdown.md b/layouts/single.markdown.md
new file mode 100644
index 000000000000..54f307137674
--- /dev/null
+++ b/layouts/single.markdown.md
@@ -0,0 +1,3 @@
+# {{ .Title }}
+
+{{ .RenderShortcodes }}
diff --git a/layouts/tag/taxonomy.html b/layouts/tag/taxonomy.html
deleted file mode 100644
index aa642acf7a55..000000000000
--- a/layouts/tag/taxonomy.html
+++ /dev/null
@@ -1,23 +0,0 @@
-{{ define "left" }}
-  {{ partial "sidebar/mainnav.html" . }}
-  {{ partial "sidebar/tags.html" . }}
-{{ end }}
-
-{{ define "main" }}
-  <article class="prose max-w-none dark:prose-invert">
-    {{ partial "breadcrumbs.html" . }}
-    <h1 class="scroll-mt-36 flex items-center">
-      <span class="icon-svg icon-lg pb-2">{{ partialCached "icon" "tag" "tag" }}</span>
-      <span>{{ .Title }}</span>
-    </h1>
-    {{ .Content }}
-    <ul>
-    {{ range site.Taxonomies.tags }}
-      <li>
-        <a href="{{ .Page.Permalink }}">{{ .Page.Title }}</a>
-        ({{ (len .Pages) }} {{ cond (gt (len .Pages) 1) "pages" "page" }})
-      </li>
-    {{ end }}
-    </ul>
-  </article>
-{{ end }}
diff --git a/layouts/tag/term.html b/layouts/tag/term.html
deleted file mode 100644
index 0f46121ace5e..000000000000
--- a/layouts/tag/term.html
+++ /dev/null
@@ -1,25 +0,0 @@
-{{ define "left" }}
-  {{ partial "sidebar/mainnav.html" . }}
-  {{ partial "sidebar/tags.html" . }}
-{{ end }}
-
-{{ define "main" }}
-  <article class="prose max-w-none dark:prose-invert">
-    {{ partial "breadcrumbs.html" . }}
-    <h1 class="scroll-mt-36 flex items-center">
-      <span class="icon-svg icon-lg pb-2">{{ partialCached "icon" "tag" "tag" }}</span>
-      </span>{{ .Title }}</span>
-    </h1>
-    {{ .Content }}
-    {{- range .Pages.GroupBy "Type" }}
-      <h2>{{ (site.GetPage .Key).LinkTitle }}</h2>
-      <ul>
-        {{ range .Pages }}
-          <li>
-            <a href="{{ .Permalink }}">{{ .Title }}</a>
-          </li>
-        {{- end }}
-      </ul>
-    {{- end }}
-  </article>
-{{ end }}
diff --git a/layouts/wide.html b/layouts/wide.html
new file mode 100644
index 000000000000..d31aab719374
--- /dev/null
+++ b/layouts/wide.html
@@ -0,0 +1 @@
+{{ define "right" }}{{ end }}
diff --git a/netlify.toml b/netlify.toml
index 5fa86c689e7f..10bff81d0034 100644
--- a/netlify.toml
+++ b/netlify.toml
@@ -2,11 +2,12 @@
 publish = "public"
 
 [context.deploy-preview.environment]
-NODE_VERSION = "22"
+NODE_VERSION = "24"
 NODE_ENV = "production"
-HUGO_VERSION = "0.141.0"
+HUGO_VERSION = "0.163.0"
 HUGO_ENABLEGITINFO = "true"
 HUGO_ENVIRONMENT = "preview"
+SECRETS_SCAN_OMIT_PATHS = "public/contribute/file-conventions/index.html"
 
 [context.deploy-preview]
-command = "hugo --gc --minify -b $DEPLOY_PRIME_URL && npx pagefind@v1.3.0"
+command = "hugo --gc --minify -b $DEPLOY_PRIME_URL && ./hack/flatten-and-resolve.js && npx pagefind@v1.5.2"
diff --git a/package-lock.json b/package-lock.json
index e0c4dcdd4ee9..bd39c8b94840 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -9,49 +9,37 @@
       "version": "0.0.1",
       "license": "Apache License 2.0",
       "dependencies": {
-        "@alpinejs/collapse": "^3.14.3",
-        "@alpinejs/focus": "^3.14.3",
-        "@alpinejs/persist": "^3.14.3",
-        "@floating-ui/dom": "^1.6.12",
-        "@material-symbols/svg-400": "^0.23.0",
-        "@tailwindcss/nesting": "^0.0.0-insiders.565cd3e",
-        "@tailwindcss/typography": "^0.5.15",
-        "alpinejs": "^3.14.3",
-        "autoprefixer": "^10.4.20",
-        "postcss": "^8.4.49",
-        "postcss-cli": "^11.0.0",
-        "postcss-import": "^16.1.0",
-        "tailwindcss": "^3.4.15"
+        "@alpinejs/collapse": "3.15.8",
+        "@alpinejs/focus": "3.15.8",
+        "@alpinejs/persist": "3.15.8",
+        "@docker/marlin-sdk-web-public": "0.6.0",
+        "@floating-ui/dom": "1.7.6",
+        "@tailwindcss/cli": "4.2.1",
+        "@tailwindcss/typography": "0.5.19",
+        "alpinejs": "3.15.8",
+        "heroicons": "2.2.0",
+        "highlight.js": "11.11.1",
+        "marked": "17.0.4",
+        "mermaid": "11.15.0",
+        "tailwindcss": "4.2.1"
       },
       "devDependencies": {
-        "markdownlint": "^0.35.0",
-        "prettier": "^3.3.3",
-        "prettier-plugin-go-template": "^0.0.15",
-        "prettier-plugin-tailwindcss": "^0.6.8"
-      }
-    },
-    "node_modules/@alloc/quick-lru": {
-      "version": "5.2.0",
-      "resolved": "https://registry.npmjs.org/@alloc/quick-lru/-/quick-lru-5.2.0.tgz",
-      "integrity": "sha512-UrcABB+4bUrFABwbluTIBErXwvbsU/V7TZWfmbgJfbkwiBuziS9gxdODUyuiecfdGQ85jglMW6juS3+z5TsKLw==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=10"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
+        "prettier": "3.8.1",
+        "prettier-plugin-go-template": "0.0.15",
+        "prettier-plugin-tailwindcss": "0.7.2",
+        "rumdl": "0.2.49"
       }
     },
     "node_modules/@alpinejs/collapse": {
-      "version": "3.14.3",
-      "resolved": "https://registry.npmjs.org/@alpinejs/collapse/-/collapse-3.14.3.tgz",
-      "integrity": "sha512-gqyzDLf6i6GPzqJROClVXpq10q/5gYfmcnmBs+UGHkHHeu7VYkMJUzH/ukPmbRmnJnZ2xkjEZz6yRrjun6N88A==",
+      "version": "3.15.8",
+      "resolved": "https://registry.npmjs.org/@alpinejs/collapse/-/collapse-3.15.8.tgz",
+      "integrity": "sha512-zZhD8DHdHuzGFe8+cHNH99K//oFutzKwcy6vagydb3KFlTzmqxTnHZo5sSV81lAazhV7qKsYCKtNV14tR9QkJw==",
       "license": "MIT"
     },
     "node_modules/@alpinejs/focus": {
-      "version": "3.14.3",
-      "resolved": "https://registry.npmjs.org/@alpinejs/focus/-/focus-3.14.3.tgz",
-      "integrity": "sha512-ZBL6HziMXhQIuta3PQjpYaMb5Ro9VPqh0mkP+d1uefJnhliBMWUfQXOnobV/0zJUB9pDxzd78diDX3ywewoJ3g==",
+      "version": "3.15.8",
+      "resolved": "https://registry.npmjs.org/@alpinejs/focus/-/focus-3.15.8.tgz",
+      "integrity": "sha512-YPF7jtaMFqrWI7xLjathWe/Hi/dXLReGoeZZxJZCW6pgmbFaVKqUFhl3DA+kUPSYsEhh9xk2wr9yoTZ2aB8xew==",
       "license": "MIT",
       "dependencies": {
         "focus-trap": "^6.9.4",
@@ -59,65 +47,137 @@
       }
     },
     "node_modules/@alpinejs/persist": {
-      "version": "3.14.3",
-      "resolved": "https://registry.npmjs.org/@alpinejs/persist/-/persist-3.14.3.tgz",
-      "integrity": "sha512-atWMKAHdDBKxHoiAEVAx9Ft+d1m9BzsepTkPZwrJmLNYPoyXnpUp1NrPLiSLB6FzUFRPoIV0tMF2kgnRwzp+vA==",
+      "version": "3.15.8",
+      "resolved": "https://registry.npmjs.org/@alpinejs/persist/-/persist-3.15.8.tgz",
+      "integrity": "sha512-xKJk0aa5p0QAquP9ivEuLnpzuBC2MyoWmiMRVzWiTR9/VLnbVgFM+6dE/D+NvfKOzhTSeht6FkYqOi/C27LBTg==",
       "license": "MIT"
     },
+    "node_modules/@antfu/install-pkg": {
+      "version": "1.1.0",
+      "resolved": "https://registry.npmjs.org/@antfu/install-pkg/-/install-pkg-1.1.0.tgz",
+      "integrity": "sha512-MGQsmw10ZyI+EJo45CdSER4zEb+p31LpDAFp2Z3gkSd1yqVZGi0Ebx++YTEMonJy4oChEMLsxZ64j8FH6sSqtQ==",
+      "dependencies": {
+        "package-manager-detector": "^1.3.0",
+        "tinyexec": "^1.0.1"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/antfu"
+      }
+    },
+    "node_modules/@braintree/sanitize-url": {
+      "version": "7.1.2",
+      "resolved": "https://registry.npmjs.org/@braintree/sanitize-url/-/sanitize-url-7.1.2.tgz",
+      "integrity": "sha512-jigsZK+sMF/cuiB7sERuo9V7N9jx+dhmHHnQyDSVdpZwVutaBu7WvNYqMDLSgFgfB30n452TP3vjDAvFC973mA=="
+    },
+    "node_modules/@bufbuild/cel": {
+      "version": "0.4.0",
+      "resolved": "https://registry.npmjs.org/@bufbuild/cel/-/cel-0.4.0.tgz",
+      "integrity": "sha512-CdW/JgiTJCYXqnwuaJRo7NcoYhR37AaF58MMiog0/t8nudn86ZyLXYaA1f2yGhm2U17h8pKGZNksTHVSTcpmAw==",
+      "dependencies": {
+        "@bufbuild/cel-spec": "0.4.0"
+      },
+      "peerDependencies": {
+        "@bufbuild/protobuf": "^2.6.2"
+      }
+    },
+    "node_modules/@bufbuild/cel-spec": {
+      "version": "0.4.0",
+      "resolved": "https://registry.npmjs.org/@bufbuild/cel-spec/-/cel-spec-0.4.0.tgz",
+      "integrity": "sha512-dUS6f2fNt6KEumsYGE7YFxERZE5ZuyME1hQmGjtO8tkZhR6ow6/ne3v4Gik9cfdb9lSLK3AJ+vDxCdGWmDbWvA==",
+      "peerDependencies": {
+        "@bufbuild/protobuf": "^2.6.2"
+      }
+    },
+    "node_modules/@bufbuild/protobuf": {
+      "version": "2.11.0",
+      "resolved": "https://registry.npmjs.org/@bufbuild/protobuf/-/protobuf-2.11.0.tgz",
+      "integrity": "sha512-sBXGT13cpmPR5BMgHE6UEEfEaShh5Ror6rfN3yEK5si7QVrtZg8LEPQb0VVhiLRUslD2yLnXtnRzG035J/mZXQ=="
+    },
+    "node_modules/@bufbuild/protovalidate": {
+      "version": "1.1.1",
+      "resolved": "https://registry.npmjs.org/@bufbuild/protovalidate/-/protovalidate-1.1.1.tgz",
+      "integrity": "sha512-sE6CojU25nfeb1w88Sm+jRnmk4GvQTeEZvLDHHDPvIHbj2NsDJWFAUJdJr+RcuMnjdWmbur+rAS38VuEK/XviQ==",
+      "dependencies": {
+        "@bufbuild/cel": "0.4.0"
+      },
+      "peerDependencies": {
+        "@bufbuild/protobuf": "^2.8.0"
+      }
+    },
+    "node_modules/@chevrotain/types": {
+      "version": "11.1.2",
+      "resolved": "https://registry.npmjs.org/@chevrotain/types/-/types-11.1.2.tgz",
+      "integrity": "sha512-U+HFai5+zmJCkK86QsaJtoITlboZHBqrVketcO2ROv865xfCMSFpELQoz1GkX5GzME8pTa+3kbKrZHQtI0gdbw=="
+    },
+    "node_modules/@docker/marlin-sdk-web-public": {
+      "version": "0.6.0",
+      "resolved": "https://registry.npmjs.org/@docker/marlin-sdk-web-public/-/marlin-sdk-web-public-0.6.0.tgz",
+      "integrity": "sha512-WO6ufqJnJrRcc8IsPn7oQkpi1TFVBaBM/+dRiD/o8Lpmo7SJlzZ1m6+b03G7dNTJYMg8wiawOJeJeeOiKGz5Sw==",
+      "dependencies": {
+        "@bufbuild/protobuf": "2.11.0",
+        "@bufbuild/protovalidate": "1.1.1",
+        "idb": "8.0.3",
+        "uuidv7": "1.1.0"
+      }
+    },
     "node_modules/@floating-ui/core": {
-      "version": "1.6.8",
-      "resolved": "https://registry.npmjs.org/@floating-ui/core/-/core-1.6.8.tgz",
-      "integrity": "sha512-7XJ9cPU+yI2QeLS+FCSlqNFZJq8arvswefkZrYI1yQBbftw6FyrZOxYSh+9S7z7TpeWlRt9zJ5IhM1WIL334jA==",
+      "version": "1.7.5",
+      "resolved": "https://registry.npmjs.org/@floating-ui/core/-/core-1.7.5.tgz",
+      "integrity": "sha512-1Ih4WTWyw0+lKyFMcBHGbb5U5FtuHJuujoyyr5zTaWS5EYMeT6Jb2AuDeftsCsEuchO+mM2ij5+q9crhydzLhQ==",
       "license": "MIT",
       "dependencies": {
-        "@floating-ui/utils": "^0.2.8"
+        "@floating-ui/utils": "^0.2.11"
       }
     },
     "node_modules/@floating-ui/dom": {
-      "version": "1.6.12",
-      "resolved": "https://registry.npmjs.org/@floating-ui/dom/-/dom-1.6.12.tgz",
-      "integrity": "sha512-NP83c0HjokcGVEMeoStg317VD9W7eDlGK7457dMBANbKA6GJZdc7rjujdgqzTaz93jkGgc5P/jeWbaCHnMNc+w==",
+      "version": "1.7.6",
+      "resolved": "https://registry.npmjs.org/@floating-ui/dom/-/dom-1.7.6.tgz",
+      "integrity": "sha512-9gZSAI5XM36880PPMm//9dfiEngYoC6Am2izES1FF406YFsjvyBMmeJ2g4SAju3xWwtuynNRFL2s9hgxpLI5SQ==",
       "license": "MIT",
       "dependencies": {
-        "@floating-ui/core": "^1.6.0",
-        "@floating-ui/utils": "^0.2.8"
+        "@floating-ui/core": "^1.7.5",
+        "@floating-ui/utils": "^0.2.11"
       }
     },
     "node_modules/@floating-ui/utils": {
-      "version": "0.2.8",
-      "resolved": "https://registry.npmjs.org/@floating-ui/utils/-/utils-0.2.8.tgz",
-      "integrity": "sha512-kym7SodPp8/wloecOpcmSnWJsK7M0E5Wg8UcFA+uO4B9s5d0ywXOEro/8HM9x0rW+TljRzul/14UYz3TleT3ig==",
+      "version": "0.2.11",
+      "resolved": "https://registry.npmjs.org/@floating-ui/utils/-/utils-0.2.11.tgz",
+      "integrity": "sha512-RiB/yIh78pcIxl6lLMG0CgBXAZ2Y0eVHqMPYugu+9U0AeT6YBeiJpf7lbdJNIugFP5SIjwNRgo4DhR1Qxi26Gg==",
       "license": "MIT"
     },
-    "node_modules/@isaacs/cliui": {
-      "version": "8.0.2",
-      "resolved": "https://registry.npmjs.org/@isaacs/cliui/-/cliui-8.0.2.tgz",
-      "integrity": "sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA==",
-      "license": "ISC",
+    "node_modules/@iconify/types": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/@iconify/types/-/types-2.0.0.tgz",
+      "integrity": "sha512-+wluvCrRhXrhyOmRDJ3q8mux9JkKy5SJ/v8ol2tu4FVjyYvtEzkc/3pK15ET6RKg4b4w4BmTk1+gsCUhf21Ykg=="
+    },
+    "node_modules/@iconify/utils": {
+      "version": "3.1.3",
+      "resolved": "https://registry.npmjs.org/@iconify/utils/-/utils-3.1.3.tgz",
+      "integrity": "sha512-LPKOXPn/zV+zis1oOfGWogaXVpqUybF3ZS6SCZIsz8vg0ivVp9+fVqyYB7xq0aiST/VhUQYGO1qo6uoYSiEJqw==",
       "dependencies": {
-        "string-width": "^5.1.2",
-        "string-width-cjs": "npm:string-width@^4.2.0",
-        "strip-ansi": "^7.0.1",
-        "strip-ansi-cjs": "npm:strip-ansi@^6.0.1",
-        "wrap-ansi": "^8.1.0",
-        "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0"
-      },
-      "engines": {
-        "node": ">=12"
+        "@antfu/install-pkg": "^1.1.0",
+        "@iconify/types": "^2.0.0",
+        "import-meta-resolve": "^4.2.0"
       }
     },
     "node_modules/@jridgewell/gen-mapping": {
-      "version": "0.3.5",
-      "resolved": "https://registry.npmjs.org/@jridgewell/gen-mapping/-/gen-mapping-0.3.5.tgz",
-      "integrity": "sha512-IzL8ZoEDIBRWEzlCcRhOaCupYyN5gdIK+Q6fbFdPDg6HqX6jpkItn7DFIpW9LQzXG6Df9sA7+OKnq0qlz/GaQg==",
+      "version": "0.3.13",
+      "resolved": "https://registry.npmjs.org/@jridgewell/gen-mapping/-/gen-mapping-0.3.13.tgz",
+      "integrity": "sha512-2kkt/7niJ6MgEPxF0bYdQ6etZaA+fQvDcLKckhy1yIQOzaoKjBBjSj63/aLVjYE3qhRt5dvM+uUyfCg6UKCBbA==",
       "license": "MIT",
       "dependencies": {
-        "@jridgewell/set-array": "^1.2.1",
-        "@jridgewell/sourcemap-codec": "^1.4.10",
+        "@jridgewell/sourcemap-codec": "^1.5.0",
+        "@jridgewell/trace-mapping": "^0.3.24"
+      }
+    },
+    "node_modules/@jridgewell/remapping": {
+      "version": "2.3.5",
+      "resolved": "https://registry.npmjs.org/@jridgewell/remapping/-/remapping-2.3.5.tgz",
+      "integrity": "sha512-LI9u/+laYG4Ds1TDKSJW2YPrIlcVYOwi2fUC6xB43lueCjgxV4lffOCZCtYFiH6TNOX+tQKXx97T4IKHbhyHEQ==",
+      "license": "MIT",
+      "dependencies": {
+        "@jridgewell/gen-mapping": "^0.3.5",
         "@jridgewell/trace-mapping": "^0.3.24"
-      },
-      "engines": {
-        "node": ">=6.0.0"
       }
     },
     "node_modules/@jridgewell/resolve-uri": {
@@ -129,2280 +189,2400 @@
         "node": ">=6.0.0"
       }
     },
-    "node_modules/@jridgewell/set-array": {
-      "version": "1.2.1",
-      "resolved": "https://registry.npmjs.org/@jridgewell/set-array/-/set-array-1.2.1.tgz",
-      "integrity": "sha512-R8gLRTZeyp03ymzP/6Lil/28tGeGEzhx1q2k703KGWRAI1VdvPIXdG70VJc2pAMw3NA6JKL5hhFu1sJX0Mnn/A==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=6.0.0"
-      }
-    },
     "node_modules/@jridgewell/sourcemap-codec": {
-      "version": "1.5.0",
-      "resolved": "https://registry.npmjs.org/@jridgewell/sourcemap-codec/-/sourcemap-codec-1.5.0.tgz",
-      "integrity": "sha512-gv3ZRaISU3fjPAgNsriBRqGWQL6quFx04YMPW/zD8XMLsU32mhCCbfbO6KZFLjvYpCZ8zyDEgqsgf+PwPaM7GQ==",
+      "version": "1.5.5",
+      "resolved": "https://registry.npmjs.org/@jridgewell/sourcemap-codec/-/sourcemap-codec-1.5.5.tgz",
+      "integrity": "sha512-cYQ9310grqxueWbl+WuIUIaiUaDcj7WOq5fVhEljNVgRfOUhY9fy2zTvfoqWsnebh8Sl70VScFbICvJnLKB0Og==",
       "license": "MIT"
     },
     "node_modules/@jridgewell/trace-mapping": {
-      "version": "0.3.25",
-      "resolved": "https://registry.npmjs.org/@jridgewell/trace-mapping/-/trace-mapping-0.3.25.tgz",
-      "integrity": "sha512-vNk6aEwybGtawWmy/PzwnGDOjCkLWSD2wqvjGGAgOAwCGWySYXfYoxt00IJkTF+8Lb57DwOb3Aa0o9CApepiYQ==",
+      "version": "0.3.31",
+      "resolved": "https://registry.npmjs.org/@jridgewell/trace-mapping/-/trace-mapping-0.3.31.tgz",
+      "integrity": "sha512-zzNR+SdQSDJzc8joaeP8QQoCQr8NuYx2dIIytl1QeBEZHJ9uW6hebsrYgbz8hJwUQao3TWCMtmfV8Nu1twOLAw==",
       "license": "MIT",
       "dependencies": {
         "@jridgewell/resolve-uri": "^3.1.0",
         "@jridgewell/sourcemap-codec": "^1.4.14"
       }
     },
-    "node_modules/@material-symbols/svg-400": {
-      "version": "0.23.0",
-      "resolved": "https://registry.npmjs.org/@material-symbols/svg-400/-/svg-400-0.23.0.tgz",
-      "integrity": "sha512-bsvGmBds729rZYOCOgxs4FjpktXfkhcprsCNPv+PRIDE3K/b30bnOsFAylUUfJ6cnHoXucS672VdNe80YIUxwA==",
-      "license": "Apache-2.0"
+    "node_modules/@mermaid-js/parser": {
+      "version": "1.1.1",
+      "resolved": "https://registry.npmjs.org/@mermaid-js/parser/-/parser-1.1.1.tgz",
+      "integrity": "sha512-VuHdsYMK1bT6X2JbcAaWAhugTRvRBRyuZgd+c22swUeI9g/ntaxF7CY7dYarhZovofCbUNO0G7JesfmNtjYOCw==",
+      "dependencies": {
+        "@chevrotain/types": "~11.1.1"
+      }
     },
-    "node_modules/@nodelib/fs.scandir": {
-      "version": "2.1.5",
-      "resolved": "https://registry.npmjs.org/@nodelib/fs.scandir/-/fs.scandir-2.1.5.tgz",
-      "integrity": "sha512-vq24Bq3ym5HEQm2NKCr3yXDwjc7vTsEThRDnkp2DK9p1uqLR+DHurm/NOTo0KG7HYHU7eppKZj3MyqYuMBf62g==",
+    "node_modules/@parcel/watcher": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher/-/watcher-2.5.1.tgz",
+      "integrity": "sha512-dfUnCxiN9H4ap84DvD2ubjw+3vUNpstxa0TneY/Paat8a3R4uQZDLSvWjmznAY/DoahqTHl9V46HF/Zs3F29pg==",
+      "hasInstallScript": true,
       "license": "MIT",
       "dependencies": {
-        "@nodelib/fs.stat": "2.0.5",
-        "run-parallel": "^1.1.9"
+        "detect-libc": "^1.0.3",
+        "is-glob": "^4.0.3",
+        "micromatch": "^4.0.5",
+        "node-addon-api": "^7.0.0"
       },
       "engines": {
-        "node": ">= 8"
-      }
-    },
-    "node_modules/@nodelib/fs.stat": {
-      "version": "2.0.5",
-      "resolved": "https://registry.npmjs.org/@nodelib/fs.stat/-/fs.stat-2.0.5.tgz",
-      "integrity": "sha512-RkhPPp2zrqDAQA/2jNhnztcPAlv64XdhIp7a7454A5ovI7Bukxgt7MX7udwAu3zg1DcpPU0rz3VV1SeaqvY4+A==",
+        "node": ">= 10.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
+      },
+      "optionalDependencies": {
+        "@parcel/watcher-android-arm64": "2.5.1",
+        "@parcel/watcher-darwin-arm64": "2.5.1",
+        "@parcel/watcher-darwin-x64": "2.5.1",
+        "@parcel/watcher-freebsd-x64": "2.5.1",
+        "@parcel/watcher-linux-arm-glibc": "2.5.1",
+        "@parcel/watcher-linux-arm-musl": "2.5.1",
+        "@parcel/watcher-linux-arm64-glibc": "2.5.1",
+        "@parcel/watcher-linux-arm64-musl": "2.5.1",
+        "@parcel/watcher-linux-x64-glibc": "2.5.1",
+        "@parcel/watcher-linux-x64-musl": "2.5.1",
+        "@parcel/watcher-win32-arm64": "2.5.1",
+        "@parcel/watcher-win32-ia32": "2.5.1",
+        "@parcel/watcher-win32-x64": "2.5.1"
+      }
+    },
+    "node_modules/@parcel/watcher-android-arm64": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-android-arm64/-/watcher-android-arm64-2.5.1.tgz",
+      "integrity": "sha512-KF8+j9nNbUN8vzOFDpRMsaKBHZ/mcjEjMToVMJOhTozkDonQFFrRcfdLWn6yWKCmJKmdVxSgHiYvTCef4/qcBA==",
+      "cpu": [
+        "arm64"
+      ],
       "license": "MIT",
+      "optional": true,
+      "os": [
+        "android"
+      ],
       "engines": {
-        "node": ">= 8"
+        "node": ">= 10.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/@nodelib/fs.walk": {
-      "version": "1.2.8",
-      "resolved": "https://registry.npmjs.org/@nodelib/fs.walk/-/fs.walk-1.2.8.tgz",
-      "integrity": "sha512-oGB+UxlgWcgQkgwo8GcEGwemoTFt3FIO9ababBmaGwXIoBKZ+GTy0pP185beGg7Llih/NSHSV2XAs1lnznocSg==",
+    "node_modules/@parcel/watcher-darwin-arm64": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-darwin-arm64/-/watcher-darwin-arm64-2.5.1.tgz",
+      "integrity": "sha512-eAzPv5osDmZyBhou8PoF4i6RQXAfeKL9tjb3QzYuccXFMQU0ruIc/POh30ePnaOyD1UXdlKguHBmsTs53tVoPw==",
+      "cpu": [
+        "arm64"
+      ],
       "license": "MIT",
-      "dependencies": {
-        "@nodelib/fs.scandir": "2.1.5",
-        "fastq": "^1.6.0"
-      },
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
       "engines": {
-        "node": ">= 8"
+        "node": ">= 10.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/@pkgjs/parseargs": {
-      "version": "0.11.0",
-      "resolved": "https://registry.npmjs.org/@pkgjs/parseargs/-/parseargs-0.11.0.tgz",
-      "integrity": "sha512-+1VkjdD0QBLPodGrJUeqarH8VAIvQODIbwh9XpP5Syisf7YoQgsJKPNFoqqLQlu+VQ/tVSshMR6loPMn8U+dPg==",
+    "node_modules/@parcel/watcher-darwin-x64": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-darwin-x64/-/watcher-darwin-x64-2.5.1.tgz",
+      "integrity": "sha512-1ZXDthrnNmwv10A0/3AJNZ9JGlzrF82i3gNQcWOzd7nJ8aj+ILyW1MTxVk35Db0u91oD5Nlk9MBiujMlwmeXZg==",
+      "cpu": [
+        "x64"
+      ],
       "license": "MIT",
       "optional": true,
+      "os": [
+        "darwin"
+      ],
       "engines": {
-        "node": ">=14"
+        "node": ">= 10.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/@sindresorhus/merge-streams": {
-      "version": "2.3.0",
-      "resolved": "https://registry.npmjs.org/@sindresorhus/merge-streams/-/merge-streams-2.3.0.tgz",
-      "integrity": "sha512-LtoMMhxAlorcGhmFYI+LhPgbPZCkgP6ra1YL604EeF6U98pLlQ3iWIGMdWSC+vWmPBWBNgmDBAhnAobLROJmwg==",
+    "node_modules/@parcel/watcher-freebsd-x64": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-freebsd-x64/-/watcher-freebsd-x64-2.5.1.tgz",
+      "integrity": "sha512-SI4eljM7Flp9yPuKi8W0ird8TI/JK6CSxju3NojVI6BjHsTyK7zxA9urjVjEKJ5MBYC+bLmMcbAWlZ+rFkLpJQ==",
+      "cpu": [
+        "x64"
+      ],
       "license": "MIT",
+      "optional": true,
+      "os": [
+        "freebsd"
+      ],
       "engines": {
-        "node": ">=18"
+        "node": ">= 10.0.0"
       },
       "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/@tailwindcss/nesting": {
-      "version": "0.0.0-insiders.565cd3e",
-      "resolved": "https://registry.npmjs.org/@tailwindcss/nesting/-/nesting-0.0.0-insiders.565cd3e.tgz",
-      "integrity": "sha512-WhHoFBx19TnH/c+xLwT/sxei6+4RpdfiyG3MYXfmLaMsADmVqBkF7B6lDalgZD9YdM459MF7DtxVbWkOrV7IaQ==",
+    "node_modules/@parcel/watcher-linux-arm-glibc": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-linux-arm-glibc/-/watcher-linux-arm-glibc-2.5.1.tgz",
+      "integrity": "sha512-RCdZlEyTs8geyBkkcnPWvtXLY44BCeZKmGYRtSgtwwnHR4dxfHRG3gR99XdMEdQ7KeiDdasJwwvNSF5jKtDwdA==",
+      "cpu": [
+        "arm"
+      ],
       "license": "MIT",
-      "dependencies": {
-        "postcss-nested": "^5.0.5"
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">= 10.0.0"
       },
-      "peerDependencies": {
-        "postcss": "^8.2.15"
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/@tailwindcss/typography": {
-      "version": "0.5.15",
-      "resolved": "https://registry.npmjs.org/@tailwindcss/typography/-/typography-0.5.15.tgz",
-      "integrity": "sha512-AqhlCXl+8grUz8uqExv5OTtgpjuVIwFTSXTrh8y9/pw6q2ek7fJ+Y8ZEVw7EB2DCcuCOtEjf9w3+J3rzts01uA==",
+    "node_modules/@parcel/watcher-linux-arm-musl": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-linux-arm-musl/-/watcher-linux-arm-musl-2.5.1.tgz",
+      "integrity": "sha512-6E+m/Mm1t1yhB8X412stiKFG3XykmgdIOqhjWj+VL8oHkKABfu/gjFj8DvLrYVHSBNC+/u5PeNrujiSQ1zwd1Q==",
+      "cpu": [
+        "arm"
+      ],
       "license": "MIT",
-      "dependencies": {
-        "lodash.castarray": "^4.4.0",
-        "lodash.isplainobject": "^4.0.6",
-        "lodash.merge": "^4.6.2",
-        "postcss-selector-parser": "6.0.10"
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">= 10.0.0"
       },
-      "peerDependencies": {
-        "tailwindcss": ">=3.0.0 || insiders || >=4.0.0-alpha.20"
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/@vue/reactivity": {
-      "version": "3.1.5",
-      "resolved": "https://registry.npmjs.org/@vue/reactivity/-/reactivity-3.1.5.tgz",
-      "integrity": "sha512-1tdfLmNjWG6t/CsPldh+foumYFo3cpyCHgBYQ34ylaMsJ+SNHQ1kApMIa8jN+i593zQuaw3AdWH0nJTARzCFhg==",
+    "node_modules/@parcel/watcher-linux-arm64-glibc": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-linux-arm64-glibc/-/watcher-linux-arm64-glibc-2.5.1.tgz",
+      "integrity": "sha512-LrGp+f02yU3BN9A+DGuY3v3bmnFUggAITBGriZHUREfNEzZh/GO06FF5u2kx8x+GBEUYfyTGamol4j3m9ANe8w==",
+      "cpu": [
+        "arm64"
+      ],
       "license": "MIT",
-      "dependencies": {
-        "@vue/shared": "3.1.5"
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">= 10.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/@vue/shared": {
-      "version": "3.1.5",
-      "resolved": "https://registry.npmjs.org/@vue/shared/-/shared-3.1.5.tgz",
-      "integrity": "sha512-oJ4F3TnvpXaQwZJNF3ZK+kLPHKarDmJjJ6jyzVNDKH9md1dptjC7lWR//jrGuLdek/U6iltWxqAnYOu8gCiOvA==",
-      "license": "MIT"
-    },
-    "node_modules/alpinejs": {
-      "version": "3.14.3",
-      "resolved": "https://registry.npmjs.org/alpinejs/-/alpinejs-3.14.3.tgz",
-      "integrity": "sha512-cL8JBEDAm4UeVjTN5QnFl8QgMGUwxFn1GvQvu3RtfAHUrAPRahGihrsWpKnEK9L0QMqsAPk/R8MylMWKHaK33A==",
+    "node_modules/@parcel/watcher-linux-arm64-musl": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-linux-arm64-musl/-/watcher-linux-arm64-musl-2.5.1.tgz",
+      "integrity": "sha512-cFOjABi92pMYRXS7AcQv9/M1YuKRw8SZniCDw0ssQb/noPkRzA+HBDkwmyOJYp5wXcsTrhxO0zq1U11cK9jsFg==",
+      "cpu": [
+        "arm64"
+      ],
       "license": "MIT",
-      "dependencies": {
-        "@vue/reactivity": "~3.1.1"
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">= 10.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/ansi-regex": {
-      "version": "6.1.0",
-      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.1.0.tgz",
-      "integrity": "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA==",
+    "node_modules/@parcel/watcher-linux-x64-glibc": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-linux-x64-glibc/-/watcher-linux-x64-glibc-2.5.1.tgz",
+      "integrity": "sha512-GcESn8NZySmfwlTsIur+49yDqSny2IhPeZfXunQi48DMugKeZ7uy1FX83pO0X22sHntJ4Ub+9k34XQCX+oHt2A==",
+      "cpu": [
+        "x64"
+      ],
       "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">=12"
+        "node": ">= 10.0.0"
       },
       "funding": {
-        "url": "https://github.com/chalk/ansi-regex?sponsor=1"
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/ansi-styles": {
-      "version": "6.2.1",
-      "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-6.2.1.tgz",
-      "integrity": "sha512-bN798gFfQX+viw3R7yrGWRqnrN2oRkEkUjjl4JNn4E8GxxbjtG3FbrEIIY3l8/hrwUwIeCZvi4QuOTP4MErVug==",
+    "node_modules/@parcel/watcher-linux-x64-musl": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-linux-x64-musl/-/watcher-linux-x64-musl-2.5.1.tgz",
+      "integrity": "sha512-n0E2EQbatQ3bXhcH2D1XIAANAcTZkQICBPVaxMeaCVBtOpBZpWJuf7LwyWPSBDITb7In8mqQgJ7gH8CILCURXg==",
+      "cpu": [
+        "x64"
+      ],
       "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">=12"
+        "node": ">= 10.0.0"
       },
       "funding": {
-        "url": "https://github.com/chalk/ansi-styles?sponsor=1"
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/any-promise": {
-      "version": "1.3.0",
-      "resolved": "https://registry.npmjs.org/any-promise/-/any-promise-1.3.0.tgz",
-      "integrity": "sha512-7UvmKalWRt1wgjL1RrGxoSJW/0QZFIegpeGvZG9kjp8vrRu55XTHbwnqq2GpXm9uLbcuhxm3IqX9OB4MZR1b2A==",
-      "license": "MIT"
-    },
-    "node_modules/anymatch": {
-      "version": "3.1.3",
-      "resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.3.tgz",
-      "integrity": "sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==",
-      "license": "ISC",
-      "dependencies": {
-        "normalize-path": "^3.0.0",
-        "picomatch": "^2.0.4"
-      },
+    "node_modules/@parcel/watcher-win32-arm64": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-win32-arm64/-/watcher-win32-arm64-2.5.1.tgz",
+      "integrity": "sha512-RFzklRvmc3PkjKjry3hLF9wD7ppR4AKcWNzH7kXR7GUe0Igb3Nz8fyPwtZCSquGrhU5HhUNDr/mKBqj7tqA2Vw==",
+      "cpu": [
+        "arm64"
+      ],
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "win32"
+      ],
       "engines": {
-        "node": ">= 8"
+        "node": ">= 10.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/arg": {
-      "version": "5.0.2",
-      "resolved": "https://registry.npmjs.org/arg/-/arg-5.0.2.tgz",
-      "integrity": "sha512-PYjyFOLKQ9y57JvQ6QLo8dAgNqswh8M1RMJYdQduT6xbWSgK36P/Z/v+p888pM69jMMfS8Xd8F6I1kQ/I9HUGg==",
-      "license": "MIT"
-    },
-    "node_modules/argparse": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
-      "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
-      "dev": true,
-      "license": "Python-2.0"
-    },
-    "node_modules/autoprefixer": {
-      "version": "10.4.20",
-      "resolved": "https://registry.npmjs.org/autoprefixer/-/autoprefixer-10.4.20.tgz",
-      "integrity": "sha512-XY25y5xSv/wEoqzDyXXME4AFfkZI0P23z6Fs3YgymDnKJkCGOnkL0iTxCa85UTqaSgfcqyf3UA6+c7wUvx/16g==",
-      "funding": [
-        {
-          "type": "opencollective",
-          "url": "https://opencollective.com/postcss/"
-        },
-        {
-          "type": "tidelift",
-          "url": "https://tidelift.com/funding/github/npm/autoprefixer"
-        },
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/ai"
-        }
+    "node_modules/@parcel/watcher-win32-ia32": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-win32-ia32/-/watcher-win32-ia32-2.5.1.tgz",
+      "integrity": "sha512-c2KkcVN+NJmuA7CGlaGD1qJh1cLfDnQsHjE89E60vUEMlqduHGCdCLJCID5geFVM0dOtA3ZiIO8BoEQmzQVfpQ==",
+      "cpu": [
+        "ia32"
       ],
       "license": "MIT",
-      "dependencies": {
-        "browserslist": "^4.23.3",
-        "caniuse-lite": "^1.0.30001646",
-        "fraction.js": "^4.3.7",
-        "normalize-range": "^0.1.2",
-        "picocolors": "^1.0.1",
-        "postcss-value-parser": "^4.2.0"
-      },
-      "bin": {
-        "autoprefixer": "bin/autoprefixer"
-      },
+      "optional": true,
+      "os": [
+        "win32"
+      ],
       "engines": {
-        "node": "^10 || ^12 || >=14"
+        "node": ">= 10.0.0"
       },
-      "peerDependencies": {
-        "postcss": "^8.1.0"
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/balanced-match": {
-      "version": "1.0.2",
-      "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz",
-      "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==",
-      "license": "MIT"
-    },
-    "node_modules/binary-extensions": {
-      "version": "2.3.0",
-      "resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.3.0.tgz",
-      "integrity": "sha512-Ceh+7ox5qe7LJuLHoY0feh3pHuUDHAcRUeyL2VYghZwfpkNIy/+8Ocg0a3UuSoYzavmylwuLWQOf3hl0jjMMIw==",
+    "node_modules/@parcel/watcher-win32-x64": {
+      "version": "2.5.1",
+      "resolved": "https://registry.npmjs.org/@parcel/watcher-win32-x64/-/watcher-win32-x64-2.5.1.tgz",
+      "integrity": "sha512-9lHBdJITeNR++EvSQVUcaZoWupyHfXe1jZvGZ06O/5MflPcuPLtEphScIBL+AiCWBO46tDSHzWyD0uDmmZqsgA==",
+      "cpu": [
+        "x64"
+      ],
       "license": "MIT",
+      "optional": true,
+      "os": [
+        "win32"
+      ],
       "engines": {
-        "node": ">=8"
+        "node": ">= 10.0.0"
       },
       "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/brace-expansion": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz",
-      "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==",
-      "license": "MIT",
-      "dependencies": {
-        "balanced-match": "^1.0.0"
+    "node_modules/@rumdl/cli-darwin-arm64": {
+      "version": "0.2.49",
+      "resolved": "https://registry.npmjs.org/@rumdl/cli-darwin-arm64/-/cli-darwin-arm64-0.2.49.tgz",
+      "integrity": "sha512-NuMdcOWyZRzzcgcWtGCxQkevvAbQ6h8Fs5utanWhrP9ncES1231ptj8jnD6LkBwZfG4D8sv2MwNfRzSm3b+sjw==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
+      "engines": {
+        "node": ">=18.0.0"
       }
     },
-    "node_modules/braces": {
-      "version": "3.0.3",
-      "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
-      "integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
-      "license": "MIT",
-      "dependencies": {
-        "fill-range": "^7.1.1"
-      },
+    "node_modules/@rumdl/cli-darwin-x64": {
+      "version": "0.2.49",
+      "resolved": "https://registry.npmjs.org/@rumdl/cli-darwin-x64/-/cli-darwin-x64-0.2.49.tgz",
+      "integrity": "sha512-KzX9tj29f2GxEigsU6YPRhJIuhm5IhI9l5r2GiKzFUG4TRRewVHv4ZuL6DpG8rdPg2bPEauEWv5tRroKUdogvQ==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
       "engines": {
-        "node": ">=8"
+        "node": ">=18.0.0"
       }
     },
-    "node_modules/browserslist": {
-      "version": "4.24.2",
-      "resolved": "https://registry.npmjs.org/browserslist/-/browserslist-4.24.2.tgz",
-      "integrity": "sha512-ZIc+Q62revdMcqC6aChtW4jz3My3klmCO1fEmINZY/8J3EpBg5/A/D0AKmBveUh6pgoeycoMkVMko84tuYS+Gg==",
-      "funding": [
-        {
-          "type": "opencollective",
-          "url": "https://opencollective.com/browserslist"
-        },
-        {
-          "type": "tidelift",
-          "url": "https://tidelift.com/funding/github/npm/browserslist"
-        },
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/ai"
-        }
+    "node_modules/@rumdl/cli-linux-arm64": {
+      "version": "0.2.49",
+      "resolved": "https://registry.npmjs.org/@rumdl/cli-linux-arm64/-/cli-linux-arm64-0.2.49.tgz",
+      "integrity": "sha512-HOmc3M//I0G2EVx8MxObVTT/gm2LXCMrIpEdbB+8y1kvzxNjg8j+gk7BZIrOVOBnXQaIo+KBdvXSx1999hVv/g==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "optional": true,
+      "os": [
+        "linux"
       ],
-      "license": "MIT",
-      "dependencies": {
-        "caniuse-lite": "^1.0.30001669",
-        "electron-to-chromium": "^1.5.41",
-        "node-releases": "^2.0.18",
-        "update-browserslist-db": "^1.1.1"
-      },
-      "bin": {
-        "browserslist": "cli.js"
-      },
       "engines": {
-        "node": "^6 || ^7 || ^8 || ^9 || ^10 || ^11 || ^12 || >=13.7"
+        "node": ">=18.0.0"
       }
     },
-    "node_modules/camelcase-css": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/camelcase-css/-/camelcase-css-2.0.1.tgz",
-      "integrity": "sha512-QOSvevhslijgYwRx6Rv7zKdMF8lbRmx+uQGx2+vDc+KI/eBnsy9kit5aj23AgGu3pa4t9AgwbnXWqS+iOY+2aA==",
-      "license": "MIT",
+    "node_modules/@rumdl/cli-linux-arm64-musl": {
+      "version": "0.2.49",
+      "resolved": "https://registry.npmjs.org/@rumdl/cli-linux-arm64-musl/-/cli-linux-arm64-musl-0.2.49.tgz",
+      "integrity": "sha512-bNKWWtkXVgqNUZRV7F3Bt/SKg1sNLopbVK4k2Cqr0rEVQz6wH5hG+conx2RsmUDUytcrf6g55DSufzcGObT1Qg==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">= 6"
+        "node": ">=18.0.0"
       }
     },
-    "node_modules/caniuse-lite": {
-      "version": "1.0.30001680",
-      "resolved": "https://registry.npmjs.org/caniuse-lite/-/caniuse-lite-1.0.30001680.tgz",
-      "integrity": "sha512-rPQy70G6AGUMnbwS1z6Xg+RkHYPAi18ihs47GH0jcxIG7wArmPgY3XbS2sRdBbxJljp3thdT8BIqv9ccCypiPA==",
-      "funding": [
-        {
-          "type": "opencollective",
-          "url": "https://opencollective.com/browserslist"
-        },
-        {
-          "type": "tidelift",
-          "url": "https://tidelift.com/funding/github/npm/caniuse-lite"
-        },
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/ai"
-        }
+    "node_modules/@rumdl/cli-linux-x64": {
+      "version": "0.2.49",
+      "resolved": "https://registry.npmjs.org/@rumdl/cli-linux-x64/-/cli-linux-x64-0.2.49.tgz",
+      "integrity": "sha512-1xr+rj5UwwYeAD3kfCM0ImX1AC3P+zums0J6xBENEqFv6Tgo5qbdkVw1RxtvTRzA5lt7Jw/A3WUwpteg58nlCQ==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "optional": true,
+      "os": [
+        "linux"
       ],
-      "license": "CC-BY-4.0"
-    },
-    "node_modules/chokidar": {
-      "version": "3.6.0",
-      "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.6.0.tgz",
-      "integrity": "sha512-7VT13fmjotKpGipCW9JEQAusEPE+Ei8nl6/g4FBAmIm0GOOLMua9NDDo/DWp0ZAxCr3cPq5ZpBqmPAQgDda2Pw==",
-      "license": "MIT",
-      "dependencies": {
-        "anymatch": "~3.1.2",
-        "braces": "~3.0.2",
-        "glob-parent": "~5.1.2",
-        "is-binary-path": "~2.1.0",
-        "is-glob": "~4.0.1",
-        "normalize-path": "~3.0.0",
-        "readdirp": "~3.6.0"
-      },
       "engines": {
-        "node": ">= 8.10.0"
-      },
-      "funding": {
-        "url": "https://paulmillr.com/funding/"
-      },
-      "optionalDependencies": {
-        "fsevents": "~2.3.2"
+        "node": ">=18.0.0"
       }
     },
-    "node_modules/cliui": {
-      "version": "8.0.1",
-      "resolved": "https://registry.npmjs.org/cliui/-/cliui-8.0.1.tgz",
-      "integrity": "sha512-BSeNnyus75C4//NQ9gQt1/csTXyo/8Sb+afLAkzAptFuMsod9HFokGNudZpi/oQV73hnVK+sR+5PVRMd+Dr7YQ==",
-      "license": "ISC",
-      "dependencies": {
-        "string-width": "^4.2.0",
-        "strip-ansi": "^6.0.1",
-        "wrap-ansi": "^7.0.0"
-      },
+    "node_modules/@rumdl/cli-linux-x64-musl": {
+      "version": "0.2.49",
+      "resolved": "https://registry.npmjs.org/@rumdl/cli-linux-x64-musl/-/cli-linux-x64-musl-0.2.49.tgz",
+      "integrity": "sha512-eBLx7p6/nGM9KS0iaYig4QmwyzrEw7Z+nCUYiGLGtFJ77Db2+FAFr4vjCPPrcV0WtlSjFFQKLhcwct998uTT3w==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">=12"
+        "node": ">=18.0.0"
       }
     },
-    "node_modules/cliui/node_modules/ansi-regex": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
-      "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
-      "license": "MIT",
+    "node_modules/@rumdl/cli-win32-x64": {
+      "version": "0.2.49",
+      "resolved": "https://registry.npmjs.org/@rumdl/cli-win32-x64/-/cli-win32-x64-0.2.49.tgz",
+      "integrity": "sha512-P3VkUqmdBXNLp0JA+dfNKdt/POiqXeEdcHVObh0X/HEvUCJb3ZPW4G8+8OPJJTbEqH3aXMMiRbn6/eY+ONrkJQ==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "optional": true,
+      "os": [
+        "win32"
+      ],
       "engines": {
-        "node": ">=8"
+        "node": ">=18.0.0"
       }
     },
-    "node_modules/cliui/node_modules/ansi-styles": {
-      "version": "4.3.0",
-      "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz",
-      "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==",
+    "node_modules/@tailwindcss/cli": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/cli/-/cli-4.2.1.tgz",
+      "integrity": "sha512-b7MGn51IA80oSG+7fuAgzfQ+7pZBgjzbqwmiv6NO7/+a1sev32cGqnwhscT7h0EcAvMa9r7gjRylqOH8Xhc4DA==",
       "license": "MIT",
       "dependencies": {
-        "color-convert": "^2.0.1"
-      },
-      "engines": {
-        "node": ">=8"
+        "@parcel/watcher": "^2.5.1",
+        "@tailwindcss/node": "4.2.1",
+        "@tailwindcss/oxide": "4.2.1",
+        "enhanced-resolve": "^5.19.0",
+        "mri": "^1.2.0",
+        "picocolors": "^1.1.1",
+        "tailwindcss": "4.2.1"
       },
-      "funding": {
-        "url": "https://github.com/chalk/ansi-styles?sponsor=1"
+      "bin": {
+        "tailwindcss": "dist/index.mjs"
       }
     },
-    "node_modules/cliui/node_modules/emoji-regex": {
-      "version": "8.0.0",
-      "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz",
-      "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==",
-      "license": "MIT"
-    },
-    "node_modules/cliui/node_modules/string-width": {
-      "version": "4.2.3",
-      "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
-      "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
+    "node_modules/@tailwindcss/node": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/node/-/node-4.2.1.tgz",
+      "integrity": "sha512-jlx6sLk4EOwO6hHe1oCGm1Q4AN/s0rSrTTPBGPM0/RQ6Uylwq17FuU8IeJJKEjtc6K6O07zsvP+gDO6MMWo7pg==",
       "license": "MIT",
       "dependencies": {
-        "emoji-regex": "^8.0.0",
-        "is-fullwidth-code-point": "^3.0.0",
-        "strip-ansi": "^6.0.1"
-      },
-      "engines": {
-        "node": ">=8"
+        "@jridgewell/remapping": "^2.3.5",
+        "enhanced-resolve": "^5.19.0",
+        "jiti": "^2.6.1",
+        "lightningcss": "1.31.1",
+        "magic-string": "^0.30.21",
+        "source-map-js": "^1.2.1",
+        "tailwindcss": "4.2.1"
       }
     },
-    "node_modules/cliui/node_modules/strip-ansi": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
-      "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
+    "node_modules/@tailwindcss/oxide": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide/-/oxide-4.2.1.tgz",
+      "integrity": "sha512-yv9jeEFWnjKCI6/T3Oq50yQEOqmpmpfzG1hcZsAOaXFQPfzWprWrlHSdGPEF3WQTi8zu8ohC9Mh9J470nT5pUw==",
       "license": "MIT",
-      "dependencies": {
-        "ansi-regex": "^5.0.1"
+      "engines": {
+        "node": ">= 20"
       },
+      "optionalDependencies": {
+        "@tailwindcss/oxide-android-arm64": "4.2.1",
+        "@tailwindcss/oxide-darwin-arm64": "4.2.1",
+        "@tailwindcss/oxide-darwin-x64": "4.2.1",
+        "@tailwindcss/oxide-freebsd-x64": "4.2.1",
+        "@tailwindcss/oxide-linux-arm-gnueabihf": "4.2.1",
+        "@tailwindcss/oxide-linux-arm64-gnu": "4.2.1",
+        "@tailwindcss/oxide-linux-arm64-musl": "4.2.1",
+        "@tailwindcss/oxide-linux-x64-gnu": "4.2.1",
+        "@tailwindcss/oxide-linux-x64-musl": "4.2.1",
+        "@tailwindcss/oxide-wasm32-wasi": "4.2.1",
+        "@tailwindcss/oxide-win32-arm64-msvc": "4.2.1",
+        "@tailwindcss/oxide-win32-x64-msvc": "4.2.1"
+      }
+    },
+    "node_modules/@tailwindcss/oxide-android-arm64": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-android-arm64/-/oxide-android-arm64-4.2.1.tgz",
+      "integrity": "sha512-eZ7G1Zm5EC8OOKaesIKuw77jw++QJ2lL9N+dDpdQiAB/c/B2wDh0QPFHbkBVrXnwNugvrbJFk1gK2SsVjwWReg==",
+      "cpu": [
+        "arm64"
+      ],
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "android"
+      ],
       "engines": {
-        "node": ">=8"
+        "node": ">= 20"
       }
     },
-    "node_modules/cliui/node_modules/wrap-ansi": {
-      "version": "7.0.0",
-      "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz",
-      "integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==",
+    "node_modules/@tailwindcss/oxide-darwin-arm64": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-darwin-arm64/-/oxide-darwin-arm64-4.2.1.tgz",
+      "integrity": "sha512-q/LHkOstoJ7pI1J0q6djesLzRvQSIfEto148ppAd+BVQK0JYjQIFSK3JgYZJa+Yzi0DDa52ZsQx2rqytBnf8Hw==",
+      "cpu": [
+        "arm64"
+      ],
       "license": "MIT",
-      "dependencies": {
-        "ansi-styles": "^4.0.0",
-        "string-width": "^4.1.0",
-        "strip-ansi": "^6.0.0"
-      },
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
       "engines": {
-        "node": ">=10"
-      },
-      "funding": {
-        "url": "https://github.com/chalk/wrap-ansi?sponsor=1"
+        "node": ">= 20"
       }
     },
-    "node_modules/color-convert": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz",
-      "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==",
+    "node_modules/@tailwindcss/oxide-darwin-x64": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-darwin-x64/-/oxide-darwin-x64-4.2.1.tgz",
+      "integrity": "sha512-/f/ozlaXGY6QLbpvd/kFTro2l18f7dHKpB+ieXz+Cijl4Mt9AI2rTrpq7V+t04nK+j9XBQHnSMdeQRhbGyt6fw==",
+      "cpu": [
+        "x64"
+      ],
       "license": "MIT",
-      "dependencies": {
-        "color-name": "~1.1.4"
-      },
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
       "engines": {
-        "node": ">=7.0.0"
+        "node": ">= 20"
       }
     },
-    "node_modules/color-name": {
-      "version": "1.1.4",
-      "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz",
-      "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==",
-      "license": "MIT"
-    },
-    "node_modules/commander": {
-      "version": "4.1.1",
-      "resolved": "https://registry.npmjs.org/commander/-/commander-4.1.1.tgz",
-      "integrity": "sha512-NOKm8xhkzAjzFx8B2v5OAHT+u5pRQc2UCa2Vq9jYL/31o2wi9mxBA7LIFs3sV5VSC49z6pEhfbMULvShKj26WA==",
+    "node_modules/@tailwindcss/oxide-freebsd-x64": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-freebsd-x64/-/oxide-freebsd-x64-4.2.1.tgz",
+      "integrity": "sha512-5e/AkgYJT/cpbkys/OU2Ei2jdETCLlifwm7ogMC7/hksI2fC3iiq6OcXwjibcIjPung0kRtR3TxEITkqgn0TcA==",
+      "cpu": [
+        "x64"
+      ],
       "license": "MIT",
+      "optional": true,
+      "os": [
+        "freebsd"
+      ],
       "engines": {
-        "node": ">= 6"
+        "node": ">= 20"
       }
     },
-    "node_modules/cross-spawn": {
-      "version": "7.0.5",
-      "resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.5.tgz",
-      "integrity": "sha512-ZVJrKKYunU38/76t0RMOulHOnUcbU9GbpWKAOZ0mhjr7CX6FVrH+4FrAapSOekrgFQ3f/8gwMEuIft0aKq6Hug==",
+    "node_modules/@tailwindcss/oxide-linux-arm-gnueabihf": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-arm-gnueabihf/-/oxide-linux-arm-gnueabihf-4.2.1.tgz",
+      "integrity": "sha512-Uny1EcVTTmerCKt/1ZuKTkb0x8ZaiuYucg2/kImO5A5Y/kBz41/+j0gxUZl+hTF3xkWpDmHX+TaWhOtba2Fyuw==",
+      "cpu": [
+        "arm"
+      ],
       "license": "MIT",
-      "dependencies": {
-        "path-key": "^3.1.0",
-        "shebang-command": "^2.0.0",
-        "which": "^2.0.1"
-      },
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">= 8"
+        "node": ">= 20"
       }
     },
-    "node_modules/cssesc": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/cssesc/-/cssesc-3.0.0.tgz",
-      "integrity": "sha512-/Tb/JcjK111nNScGob5MNtsntNM1aCNUDipB/TkwZFhyDrrE47SOx/18wF2bbjgc3ZzCSKW1T5nt5EbFoAz/Vg==",
+    "node_modules/@tailwindcss/oxide-linux-arm64-gnu": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-arm64-gnu/-/oxide-linux-arm64-gnu-4.2.1.tgz",
+      "integrity": "sha512-CTrwomI+c7n6aSSQlsPL0roRiNMDQ/YzMD9EjcR+H4f0I1SQ8QqIuPnsVp7QgMkC1Qi8rtkekLkOFjo7OlEFRQ==",
+      "cpu": [
+        "arm64"
+      ],
       "license": "MIT",
-      "bin": {
-        "cssesc": "bin/cssesc"
-      },
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">=4"
+        "node": ">= 20"
       }
     },
-    "node_modules/dependency-graph": {
-      "version": "0.11.0",
-      "resolved": "https://registry.npmjs.org/dependency-graph/-/dependency-graph-0.11.0.tgz",
-      "integrity": "sha512-JeMq7fEshyepOWDfcfHK06N3MhyPhz++vtqWhMT5O9A3K42rdsEDpfdVqjaqaAhsw6a+ZqeDvQVtD0hFHQWrzg==",
+    "node_modules/@tailwindcss/oxide-linux-arm64-musl": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-arm64-musl/-/oxide-linux-arm64-musl-4.2.1.tgz",
+      "integrity": "sha512-WZA0CHRL/SP1TRbA5mp9htsppSEkWuQ4KsSUumYQnyl8ZdT39ntwqmz4IUHGN6p4XdSlYfJwM4rRzZLShHsGAQ==",
+      "cpu": [
+        "arm64"
+      ],
       "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">= 0.6.0"
+        "node": ">= 20"
       }
     },
-    "node_modules/didyoumean": {
-      "version": "1.2.2",
-      "resolved": "https://registry.npmjs.org/didyoumean/-/didyoumean-1.2.2.tgz",
-      "integrity": "sha512-gxtyfqMg7GKyhQmb056K7M3xszy/myH8w+B4RT+QXBQsvAOdc3XymqDDPHx1BgPgsdAA5SIifona89YtRATDzw==",
-      "license": "Apache-2.0"
-    },
-    "node_modules/dlv": {
-      "version": "1.1.3",
-      "resolved": "https://registry.npmjs.org/dlv/-/dlv-1.1.3.tgz",
-      "integrity": "sha512-+HlytyjlPKnIG8XuRG8WvmBP8xs8P71y+SKKS6ZXWoEgLuePxtDoUEiH7WkdePWrQ5JBpE6aoVqfZfJUQkjXwA==",
-      "license": "MIT"
-    },
-    "node_modules/eastasianwidth": {
-      "version": "0.2.0",
-      "resolved": "https://registry.npmjs.org/eastasianwidth/-/eastasianwidth-0.2.0.tgz",
-      "integrity": "sha512-I88TYZWc9XiYHRQ4/3c5rjjfgkjhLyW2luGIheGERbNQ6OY7yTybanSpDXZa8y7VUP9YmDcYa+eyq4ca7iLqWA==",
-      "license": "MIT"
-    },
-    "node_modules/electron-to-chromium": {
-      "version": "1.5.62",
-      "resolved": "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.5.62.tgz",
-      "integrity": "sha512-t8c+zLmJHa9dJy96yBZRXGQYoiCEnHYgFwn1asvSPZSUdVxnB62A4RASd7k41ytG3ErFBA0TpHlKg9D9SQBmLg==",
-      "license": "ISC"
-    },
-    "node_modules/emoji-regex": {
-      "version": "9.2.2",
-      "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-9.2.2.tgz",
-      "integrity": "sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==",
-      "license": "MIT"
-    },
-    "node_modules/entities": {
-      "version": "4.5.0",
-      "resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz",
-      "integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==",
-      "dev": true,
-      "license": "BSD-2-Clause",
+    "node_modules/@tailwindcss/oxide-linux-x64-gnu": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-x64-gnu/-/oxide-linux-x64-gnu-4.2.1.tgz",
+      "integrity": "sha512-qMFzxI2YlBOLW5PhblzuSWlWfwLHaneBE0xHzLrBgNtqN6mWfs+qYbhryGSXQjFYB1Dzf5w+LN5qbUTPhW7Y5g==",
+      "cpu": [
+        "x64"
+      ],
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">=0.12"
-      },
-      "funding": {
-        "url": "https://github.com/fb55/entities?sponsor=1"
+        "node": ">= 20"
       }
     },
-    "node_modules/escalade": {
-      "version": "3.2.0",
-      "resolved": "https://registry.npmjs.org/escalade/-/escalade-3.2.0.tgz",
-      "integrity": "sha512-WUj2qlxaQtO4g6Pq5c29GTcWGDyd8itL8zTlipgECz3JesAiiOKotd8JU6otB3PACgG6xkJUyVhboMS+bje/jA==",
+    "node_modules/@tailwindcss/oxide-linux-x64-musl": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-x64-musl/-/oxide-linux-x64-musl-4.2.1.tgz",
+      "integrity": "sha512-5r1X2FKnCMUPlXTWRYpHdPYUY6a1Ar/t7P24OuiEdEOmms5lyqjDRvVY1yy9Rmioh+AunQ0rWiOTPE8F9A3v5g==",
+      "cpu": [
+        "x64"
+      ],
       "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">=6"
+        "node": ">= 20"
       }
     },
-    "node_modules/fast-glob": {
-      "version": "3.3.2",
-      "resolved": "https://registry.npmjs.org/fast-glob/-/fast-glob-3.3.2.tgz",
-      "integrity": "sha512-oX2ruAFQwf/Orj8m737Y5adxDQO0LAB7/S5MnxCdTNDd4p6BsyIVsv9JQsATbTSq8KHRpLwIHbVlUNatxd+1Ow==",
+    "node_modules/@tailwindcss/oxide-wasm32-wasi": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-wasm32-wasi/-/oxide-wasm32-wasi-4.2.1.tgz",
+      "integrity": "sha512-MGFB5cVPvshR85MTJkEvqDUnuNoysrsRxd6vnk1Lf2tbiqNlXpHYZqkqOQalydienEWOHHFyyuTSYRsLfxFJ2Q==",
+      "bundleDependencies": [
+        "@napi-rs/wasm-runtime",
+        "@emnapi/core",
+        "@emnapi/runtime",
+        "@tybys/wasm-util",
+        "@emnapi/wasi-threads",
+        "tslib"
+      ],
+      "cpu": [
+        "wasm32"
+      ],
       "license": "MIT",
+      "optional": true,
       "dependencies": {
-        "@nodelib/fs.stat": "^2.0.2",
-        "@nodelib/fs.walk": "^1.2.3",
-        "glob-parent": "^5.1.2",
-        "merge2": "^1.3.0",
-        "micromatch": "^4.0.4"
+        "@emnapi/core": "^1.8.1",
+        "@emnapi/runtime": "^1.8.1",
+        "@emnapi/wasi-threads": "^1.1.0",
+        "@napi-rs/wasm-runtime": "^1.1.1",
+        "@tybys/wasm-util": "^0.10.1",
+        "tslib": "^2.8.1"
       },
       "engines": {
-        "node": ">=8.6.0"
-      }
-    },
-    "node_modules/fastq": {
-      "version": "1.17.1",
-      "resolved": "https://registry.npmjs.org/fastq/-/fastq-1.17.1.tgz",
-      "integrity": "sha512-sRVD3lWVIXWg6By68ZN7vho9a1pQcN/WBFaAAsDDFzlJjvoGx0P8z7V1t72grFJfJhu3YPZBuu25f7Kaw2jN1w==",
-      "license": "ISC",
-      "dependencies": {
-        "reusify": "^1.0.4"
+        "node": ">=14.0.0"
       }
     },
-    "node_modules/fill-range": {
-      "version": "7.1.1",
-      "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
-      "integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@emnapi/core": {
+      "version": "1.8.1",
+      "inBundle": true,
       "license": "MIT",
+      "optional": true,
       "dependencies": {
-        "to-regex-range": "^5.0.1"
-      },
-      "engines": {
-        "node": ">=8"
+        "@emnapi/wasi-threads": "1.1.0",
+        "tslib": "^2.4.0"
       }
     },
-    "node_modules/focus-trap": {
-      "version": "6.9.4",
-      "resolved": "https://registry.npmjs.org/focus-trap/-/focus-trap-6.9.4.tgz",
-      "integrity": "sha512-v2NTsZe2FF59Y+sDykKY+XjqZ0cPfhq/hikWVL88BqLivnNiEffAsac6rP6H45ff9wG9LL5ToiDqrLEP9GX9mw==",
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@emnapi/runtime": {
+      "version": "1.8.1",
+      "inBundle": true,
       "license": "MIT",
+      "optional": true,
       "dependencies": {
-        "tabbable": "^5.3.3"
+        "tslib": "^2.4.0"
       }
     },
-    "node_modules/foreground-child": {
-      "version": "3.3.0",
-      "resolved": "https://registry.npmjs.org/foreground-child/-/foreground-child-3.3.0.tgz",
-      "integrity": "sha512-Ld2g8rrAyMYFXBhEqMz8ZAHBi4J4uS1i/CxGMDnjyFWddMXLVcDp051DZfu+t7+ab7Wv6SMqpWmyFIj5UbfFvg==",
-      "license": "ISC",
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@emnapi/wasi-threads": {
+      "version": "1.1.0",
+      "inBundle": true,
+      "license": "MIT",
+      "optional": true,
       "dependencies": {
-        "cross-spawn": "^7.0.0",
-        "signal-exit": "^4.0.1"
-      },
-      "engines": {
-        "node": ">=14"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/isaacs"
+        "tslib": "^2.4.0"
       }
     },
-    "node_modules/fraction.js": {
-      "version": "4.3.7",
-      "resolved": "https://registry.npmjs.org/fraction.js/-/fraction.js-4.3.7.tgz",
-      "integrity": "sha512-ZsDfxO51wGAXREY55a7la9LScWpwv9RxIrYABrlvOFBlH/ShPnrtsXeuUIfXKKOVicNxQ+o8JTbJvjS4M89yew==",
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@napi-rs/wasm-runtime": {
+      "version": "1.1.1",
+      "inBundle": true,
       "license": "MIT",
-      "engines": {
-        "node": "*"
+      "optional": true,
+      "dependencies": {
+        "@emnapi/core": "^1.7.1",
+        "@emnapi/runtime": "^1.7.1",
+        "@tybys/wasm-util": "^0.10.1"
       },
       "funding": {
-        "type": "patreon",
-        "url": "https://github.com/sponsors/rawify"
+        "type": "github",
+        "url": "https://github.com/sponsors/Brooooooklyn"
       }
     },
-    "node_modules/fs-extra": {
-      "version": "11.2.0",
-      "resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-11.2.0.tgz",
-      "integrity": "sha512-PmDi3uwK5nFuXh7XDTlVnS17xJS7vW36is2+w3xcv8SVxiB4NyATf4ctkVY5bkSjX0Y4nbvZCq1/EjtEyr9ktw==",
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@tybys/wasm-util": {
+      "version": "0.10.1",
+      "inBundle": true,
       "license": "MIT",
+      "optional": true,
       "dependencies": {
-        "graceful-fs": "^4.2.0",
-        "jsonfile": "^6.0.1",
-        "universalify": "^2.0.0"
-      },
-      "engines": {
-        "node": ">=14.14"
+        "tslib": "^2.4.0"
       }
     },
-    "node_modules/fsevents": {
-      "version": "2.3.3",
-      "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz",
-      "integrity": "sha512-5xoDfX+fL7faATnagmWPpbFtwh/R77WmMMqqHGS65C3vvB0YHrgF+B1YmZ3441tMj5n63k0212XNoJwzlhffQw==",
-      "hasInstallScript": true,
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/tslib": {
+      "version": "2.8.1",
+      "inBundle": true,
+      "license": "0BSD",
+      "optional": true
+    },
+    "node_modules/@tailwindcss/oxide-win32-arm64-msvc": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-win32-arm64-msvc/-/oxide-win32-arm64-msvc-4.2.1.tgz",
+      "integrity": "sha512-YlUEHRHBGnCMh4Nj4GnqQyBtsshUPdiNroZj8VPkvTZSoHsilRCwXcVKnG9kyi0ZFAS/3u+qKHBdDc81SADTRA==",
+      "cpu": [
+        "arm64"
+      ],
       "license": "MIT",
       "optional": true,
       "os": [
-        "darwin"
+        "win32"
       ],
       "engines": {
-        "node": "^8.16.0 || ^10.6.0 || >=11.0.0"
+        "node": ">= 20"
       }
     },
-    "node_modules/function-bind": {
-      "version": "1.1.2",
-      "resolved": "https://registry.npmjs.org/function-bind/-/function-bind-1.1.2.tgz",
-      "integrity": "sha512-7XHNxH7qX9xG5mIwxkhumTox/MIRNcOgDrxWsMt2pAr23WHp6MrRlN7FBSFpCpr+oVO0F744iUgR82nJMfG2SA==",
+    "node_modules/@tailwindcss/oxide-win32-x64-msvc": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-win32-x64-msvc/-/oxide-win32-x64-msvc-4.2.1.tgz",
+      "integrity": "sha512-rbO34G5sMWWyrN/idLeVxAZgAKWrn5LiR3/I90Q9MkA67s6T1oB0xtTe+0heoBvHSpbU9Mk7i6uwJnpo4u21XQ==",
+      "cpu": [
+        "x64"
+      ],
       "license": "MIT",
-      "funding": {
-        "url": "https://github.com/sponsors/ljharb"
-      }
-    },
-    "node_modules/get-caller-file": {
-      "version": "2.0.5",
-      "resolved": "https://registry.npmjs.org/get-caller-file/-/get-caller-file-2.0.5.tgz",
-      "integrity": "sha512-DyFP3BM/3YHTQOCUL/w0OZHR0lpKeGrxotcHWcqNEdnltqFwXVfhEBQ94eIo34AfQpo0rGki4cyIiftY06h2Fg==",
-      "license": "ISC",
+      "optional": true,
+      "os": [
+        "win32"
+      ],
       "engines": {
-        "node": "6.* || 8.* || >= 10.*"
+        "node": ">= 20"
       }
     },
-    "node_modules/get-stdin": {
-      "version": "9.0.0",
-      "resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-9.0.0.tgz",
-      "integrity": "sha512-dVKBjfWisLAicarI2Sf+JuBE/DghV4UzNAVe9yhEJuzeREd3JhOTE9cUaJTeSa77fsbQUK3pcOpJfM59+VKZaA==",
+    "node_modules/@tailwindcss/typography": {
+      "version": "0.5.19",
+      "resolved": "https://registry.npmjs.org/@tailwindcss/typography/-/typography-0.5.19.tgz",
+      "integrity": "sha512-w31dd8HOx3k9vPtcQh5QHP9GwKcgbMp87j58qi6xgiBnFFtKEAgCWnDw4qUT8aHwkCp8bKvb/KGKWWHedP0AAg==",
       "license": "MIT",
-      "engines": {
-        "node": ">=12"
+      "dependencies": {
+        "postcss-selector-parser": "6.0.10"
       },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
-      }
+      "peerDependencies": {
+        "tailwindcss": ">=3.0.0 || insiders || >=4.0.0-alpha.20 || >=4.0.0-beta.1"
+      }
+    },
+    "node_modules/@types/d3": {
+      "version": "7.4.3",
+      "resolved": "https://registry.npmjs.org/@types/d3/-/d3-7.4.3.tgz",
+      "integrity": "sha512-lZXZ9ckh5R8uiFVt8ogUNf+pIrK4EsWrx2Np75WvF/eTpJ0FMHNhjXk8CKEx/+gpHbNQyJWehbFaTvqmHWB3ww==",
+      "dependencies": {
+        "@types/d3-array": "*",
+        "@types/d3-axis": "*",
+        "@types/d3-brush": "*",
+        "@types/d3-chord": "*",
+        "@types/d3-color": "*",
+        "@types/d3-contour": "*",
+        "@types/d3-delaunay": "*",
+        "@types/d3-dispatch": "*",
+        "@types/d3-drag": "*",
+        "@types/d3-dsv": "*",
+        "@types/d3-ease": "*",
+        "@types/d3-fetch": "*",
+        "@types/d3-force": "*",
+        "@types/d3-format": "*",
+        "@types/d3-geo": "*",
+        "@types/d3-hierarchy": "*",
+        "@types/d3-interpolate": "*",
+        "@types/d3-path": "*",
+        "@types/d3-polygon": "*",
+        "@types/d3-quadtree": "*",
+        "@types/d3-random": "*",
+        "@types/d3-scale": "*",
+        "@types/d3-scale-chromatic": "*",
+        "@types/d3-selection": "*",
+        "@types/d3-shape": "*",
+        "@types/d3-time": "*",
+        "@types/d3-time-format": "*",
+        "@types/d3-timer": "*",
+        "@types/d3-transition": "*",
+        "@types/d3-zoom": "*"
+      }
+    },
+    "node_modules/@types/d3-array": {
+      "version": "3.2.2",
+      "resolved": "https://registry.npmjs.org/@types/d3-array/-/d3-array-3.2.2.tgz",
+      "integrity": "sha512-hOLWVbm7uRza0BYXpIIW5pxfrKe0W+D5lrFiAEYR+pb6w3N2SwSMaJbXdUfSEv+dT4MfHBLtn5js0LAWaO6otw=="
+    },
+    "node_modules/@types/d3-axis": {
+      "version": "3.0.6",
+      "resolved": "https://registry.npmjs.org/@types/d3-axis/-/d3-axis-3.0.6.tgz",
+      "integrity": "sha512-pYeijfZuBd87T0hGn0FO1vQ/cgLk6E1ALJjfkC0oJ8cbwkZl3TpgS8bVBLZN+2jjGgg38epgxb2zmoGtSfvgMw==",
+      "dependencies": {
+        "@types/d3-selection": "*"
+      }
+    },
+    "node_modules/@types/d3-brush": {
+      "version": "3.0.6",
+      "resolved": "https://registry.npmjs.org/@types/d3-brush/-/d3-brush-3.0.6.tgz",
+      "integrity": "sha512-nH60IZNNxEcrh6L1ZSMNA28rj27ut/2ZmI3r96Zd+1jrZD++zD3LsMIjWlvg4AYrHn/Pqz4CF3veCxGjtbqt7A==",
+      "dependencies": {
+        "@types/d3-selection": "*"
+      }
+    },
+    "node_modules/@types/d3-chord": {
+      "version": "3.0.6",
+      "resolved": "https://registry.npmjs.org/@types/d3-chord/-/d3-chord-3.0.6.tgz",
+      "integrity": "sha512-LFYWWd8nwfwEmTZG9PfQxd17HbNPksHBiJHaKuY1XeqscXacsS2tyoo6OdRsjf+NQYeB6XrNL3a25E3gH69lcg=="
+    },
+    "node_modules/@types/d3-color": {
+      "version": "3.1.3",
+      "resolved": "https://registry.npmjs.org/@types/d3-color/-/d3-color-3.1.3.tgz",
+      "integrity": "sha512-iO90scth9WAbmgv7ogoq57O9YpKmFBbmoEoCHDB2xMBY0+/KVrqAaCDyCE16dUspeOvIxFFRI+0sEtqDqy2b4A=="
     },
-    "node_modules/glob": {
-      "version": "10.4.5",
-      "resolved": "https://registry.npmjs.org/glob/-/glob-10.4.5.tgz",
-      "integrity": "sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==",
-      "license": "ISC",
+    "node_modules/@types/d3-contour": {
+      "version": "3.0.6",
+      "resolved": "https://registry.npmjs.org/@types/d3-contour/-/d3-contour-3.0.6.tgz",
+      "integrity": "sha512-BjzLgXGnCWjUSYGfH1cpdo41/hgdWETu4YxpezoztawmqsvCeep+8QGfiY6YbDvfgHz/DkjeIkkZVJavB4a3rg==",
       "dependencies": {
-        "foreground-child": "^3.1.0",
-        "jackspeak": "^3.1.2",
-        "minimatch": "^9.0.4",
-        "minipass": "^7.1.2",
-        "package-json-from-dist": "^1.0.0",
-        "path-scurry": "^1.11.1"
-      },
-      "bin": {
-        "glob": "dist/esm/bin.mjs"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/isaacs"
+        "@types/d3-array": "*",
+        "@types/geojson": "*"
       }
     },
-    "node_modules/glob-parent": {
-      "version": "5.1.2",
-      "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz",
-      "integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==",
-      "license": "ISC",
+    "node_modules/@types/d3-delaunay": {
+      "version": "6.0.4",
+      "resolved": "https://registry.npmjs.org/@types/d3-delaunay/-/d3-delaunay-6.0.4.tgz",
+      "integrity": "sha512-ZMaSKu4THYCU6sV64Lhg6qjf1orxBthaC161plr5KuPHo3CNm8DTHiLw/5Eq2b6TsNP0W0iJrUOFscY6Q450Hw=="
+    },
+    "node_modules/@types/d3-dispatch": {
+      "version": "3.0.7",
+      "resolved": "https://registry.npmjs.org/@types/d3-dispatch/-/d3-dispatch-3.0.7.tgz",
+      "integrity": "sha512-5o9OIAdKkhN1QItV2oqaE5KMIiXAvDWBDPrD85e58Qlz1c1kI/J0NcqbEG88CoTwJrYe7ntUCVfeUl2UJKbWgA=="
+    },
+    "node_modules/@types/d3-drag": {
+      "version": "3.0.7",
+      "resolved": "https://registry.npmjs.org/@types/d3-drag/-/d3-drag-3.0.7.tgz",
+      "integrity": "sha512-HE3jVKlzU9AaMazNufooRJ5ZpWmLIoc90A37WU2JMmeq28w1FQqCZswHZ3xR+SuxYftzHq6WU6KJHvqxKzTxxQ==",
       "dependencies": {
-        "is-glob": "^4.0.1"
-      },
-      "engines": {
-        "node": ">= 6"
+        "@types/d3-selection": "*"
       }
     },
-    "node_modules/globby": {
-      "version": "14.0.2",
-      "resolved": "https://registry.npmjs.org/globby/-/globby-14.0.2.tgz",
-      "integrity": "sha512-s3Fq41ZVh7vbbe2PN3nrW7yC7U7MFVc5c98/iTl9c2GawNMKx/J648KQRW6WKkuU8GIbbh2IXfIRQjOZnXcTnw==",
-      "license": "MIT",
+    "node_modules/@types/d3-dsv": {
+      "version": "3.0.7",
+      "resolved": "https://registry.npmjs.org/@types/d3-dsv/-/d3-dsv-3.0.7.tgz",
+      "integrity": "sha512-n6QBF9/+XASqcKK6waudgL0pf/S5XHPPI8APyMLLUHd8NqouBGLsU8MgtO7NINGtPBtk9Kko/W4ea0oAspwh9g=="
+    },
+    "node_modules/@types/d3-ease": {
+      "version": "3.0.2",
+      "resolved": "https://registry.npmjs.org/@types/d3-ease/-/d3-ease-3.0.2.tgz",
+      "integrity": "sha512-NcV1JjO5oDzoK26oMzbILE6HW7uVXOHLQvHshBUW4UMdZGfiY6v5BeQwh9a9tCzv+CeefZQHJt5SRgK154RtiA=="
+    },
+    "node_modules/@types/d3-fetch": {
+      "version": "3.0.7",
+      "resolved": "https://registry.npmjs.org/@types/d3-fetch/-/d3-fetch-3.0.7.tgz",
+      "integrity": "sha512-fTAfNmxSb9SOWNB9IoG5c8Hg6R+AzUHDRlsXsDZsNp6sxAEOP0tkP3gKkNSO/qmHPoBFTxNrjDprVHDQDvo5aA==",
       "dependencies": {
-        "@sindresorhus/merge-streams": "^2.1.0",
-        "fast-glob": "^3.3.2",
-        "ignore": "^5.2.4",
-        "path-type": "^5.0.0",
-        "slash": "^5.1.0",
-        "unicorn-magic": "^0.1.0"
-      },
-      "engines": {
-        "node": ">=18"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
+        "@types/d3-dsv": "*"
       }
     },
-    "node_modules/graceful-fs": {
-      "version": "4.2.11",
-      "resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.11.tgz",
-      "integrity": "sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==",
-      "license": "ISC"
+    "node_modules/@types/d3-force": {
+      "version": "3.0.10",
+      "resolved": "https://registry.npmjs.org/@types/d3-force/-/d3-force-3.0.10.tgz",
+      "integrity": "sha512-ZYeSaCF3p73RdOKcjj+swRlZfnYpK1EbaDiYICEEp5Q6sUiqFaFQ9qgoshp5CzIyyb/yD09kD9o2zEltCexlgw=="
     },
-    "node_modules/hasown": {
-      "version": "2.0.2",
-      "resolved": "https://registry.npmjs.org/hasown/-/hasown-2.0.2.tgz",
-      "integrity": "sha512-0hJU9SCPvmMzIBdZFqNPXWa6dqh7WdH0cII9y+CyS8rG3nL48Bclra9HmKhVVUHyPWNH5Y7xDwAB7bfgSjkUMQ==",
-      "license": "MIT",
+    "node_modules/@types/d3-format": {
+      "version": "3.0.4",
+      "resolved": "https://registry.npmjs.org/@types/d3-format/-/d3-format-3.0.4.tgz",
+      "integrity": "sha512-fALi2aI6shfg7vM5KiR1wNJnZ7r6UuggVqtDA+xiEdPZQwy/trcQaHnwShLuLdta2rTymCNpxYTiMZX/e09F4g=="
+    },
+    "node_modules/@types/d3-geo": {
+      "version": "3.1.0",
+      "resolved": "https://registry.npmjs.org/@types/d3-geo/-/d3-geo-3.1.0.tgz",
+      "integrity": "sha512-856sckF0oP/diXtS4jNsiQw/UuK5fQG8l/a9VVLeSouf1/PPbBE1i1W852zVwKwYCBkFJJB7nCFTbk6UMEXBOQ==",
       "dependencies": {
-        "function-bind": "^1.1.2"
-      },
-      "engines": {
-        "node": ">= 0.4"
+        "@types/geojson": "*"
       }
     },
-    "node_modules/ignore": {
-      "version": "5.3.2",
-      "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.3.2.tgz",
-      "integrity": "sha512-hsBTNUqQTDwkWtcdYI2i06Y/nUBEsNEDJKjWdigLvegy8kDuJAS8uRlpkkcQpyEXL0Z/pjDy5HBmMjRCJ2gq+g==",
-      "license": "MIT",
-      "engines": {
-        "node": ">= 4"
-      }
+    "node_modules/@types/d3-hierarchy": {
+      "version": "3.1.7",
+      "resolved": "https://registry.npmjs.org/@types/d3-hierarchy/-/d3-hierarchy-3.1.7.tgz",
+      "integrity": "sha512-tJFtNoYBtRtkNysX1Xq4sxtjK8YgoWUNpIiUee0/jHGRwqvzYxkq0hGVbbOGSz+JgFxxRu4K8nb3YpG3CMARtg=="
     },
-    "node_modules/is-binary-path": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz",
-      "integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==",
-      "license": "MIT",
+    "node_modules/@types/d3-interpolate": {
+      "version": "3.0.4",
+      "resolved": "https://registry.npmjs.org/@types/d3-interpolate/-/d3-interpolate-3.0.4.tgz",
+      "integrity": "sha512-mgLPETlrpVV1YRJIglr4Ez47g7Yxjl1lj7YKsiMCb27VJH9W8NVM6Bb9d8kkpG/uAQS5AmbA48q2IAolKKo1MA==",
       "dependencies": {
-        "binary-extensions": "^2.0.0"
-      },
-      "engines": {
-        "node": ">=8"
+        "@types/d3-color": "*"
       }
     },
-    "node_modules/is-core-module": {
-      "version": "2.15.1",
-      "resolved": "https://registry.npmjs.org/is-core-module/-/is-core-module-2.15.1.tgz",
-      "integrity": "sha512-z0vtXSwucUJtANQWldhbtbt7BnL0vxiFjIdDLAatwhDYty2bad6s+rijD6Ri4YuYJubLzIJLUidCh09e1djEVQ==",
-      "license": "MIT",
+    "node_modules/@types/d3-path": {
+      "version": "3.1.1",
+      "resolved": "https://registry.npmjs.org/@types/d3-path/-/d3-path-3.1.1.tgz",
+      "integrity": "sha512-VMZBYyQvbGmWyWVea0EHs/BwLgxc+MKi1zLDCONksozI4YJMcTt8ZEuIR4Sb1MMTE8MMW49v0IwI5+b7RmfWlg=="
+    },
+    "node_modules/@types/d3-polygon": {
+      "version": "3.0.2",
+      "resolved": "https://registry.npmjs.org/@types/d3-polygon/-/d3-polygon-3.0.2.tgz",
+      "integrity": "sha512-ZuWOtMaHCkN9xoeEMr1ubW2nGWsp4nIql+OPQRstu4ypeZ+zk3YKqQT0CXVe/PYqrKpZAi+J9mTs05TKwjXSRA=="
+    },
+    "node_modules/@types/d3-quadtree": {
+      "version": "3.0.6",
+      "resolved": "https://registry.npmjs.org/@types/d3-quadtree/-/d3-quadtree-3.0.6.tgz",
+      "integrity": "sha512-oUzyO1/Zm6rsxKRHA1vH0NEDG58HrT5icx/azi9MF1TWdtttWl0UIUsjEQBBh+SIkrpd21ZjEv7ptxWys1ncsg=="
+    },
+    "node_modules/@types/d3-random": {
+      "version": "3.0.3",
+      "resolved": "https://registry.npmjs.org/@types/d3-random/-/d3-random-3.0.3.tgz",
+      "integrity": "sha512-Imagg1vJ3y76Y2ea0871wpabqp613+8/r0mCLEBfdtqC7xMSfj9idOnmBYyMoULfHePJyxMAw3nWhJxzc+LFwQ=="
+    },
+    "node_modules/@types/d3-scale": {
+      "version": "4.0.9",
+      "resolved": "https://registry.npmjs.org/@types/d3-scale/-/d3-scale-4.0.9.tgz",
+      "integrity": "sha512-dLmtwB8zkAeO/juAMfnV+sItKjlsw2lKdZVVy6LRr0cBmegxSABiLEpGVmSJJ8O08i4+sGR6qQtb6WtuwJdvVw==",
       "dependencies": {
-        "hasown": "^2.0.2"
-      },
-      "engines": {
-        "node": ">= 0.4"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/ljharb"
+        "@types/d3-time": "*"
       }
     },
-    "node_modules/is-extglob": {
-      "version": "2.1.1",
-      "resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz",
-      "integrity": "sha512-SbKbANkN603Vi4jEZv49LeVJMn4yGwsbzZworEoyEiutsN3nJYdbO36zfhGJ6QEDpOZIFkDtnq5JRxmvl3jsoQ==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.10.0"
-      }
+    "node_modules/@types/d3-scale-chromatic": {
+      "version": "3.1.0",
+      "resolved": "https://registry.npmjs.org/@types/d3-scale-chromatic/-/d3-scale-chromatic-3.1.0.tgz",
+      "integrity": "sha512-iWMJgwkK7yTRmWqRB5plb1kadXyQ5Sj8V/zYlFGMUBbIPKQScw+Dku9cAAMgJG+z5GYDoMjWGLVOvjghDEFnKQ=="
     },
-    "node_modules/is-fullwidth-code-point": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
-      "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=8"
-      }
+    "node_modules/@types/d3-selection": {
+      "version": "3.0.11",
+      "resolved": "https://registry.npmjs.org/@types/d3-selection/-/d3-selection-3.0.11.tgz",
+      "integrity": "sha512-bhAXu23DJWsrI45xafYpkQ4NtcKMwWnAC/vKrd2l+nxMFuvOT3XMYTIj2opv8vq8AO5Yh7Qac/nSeP/3zjTK0w=="
     },
-    "node_modules/is-glob": {
-      "version": "4.0.3",
-      "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz",
-      "integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==",
-      "license": "MIT",
+    "node_modules/@types/d3-shape": {
+      "version": "3.1.8",
+      "resolved": "https://registry.npmjs.org/@types/d3-shape/-/d3-shape-3.1.8.tgz",
+      "integrity": "sha512-lae0iWfcDeR7qt7rA88BNiqdvPS5pFVPpo5OfjElwNaT2yyekbM0C9vK+yqBqEmHr6lDkRnYNoTBYlAgJa7a4w==",
       "dependencies": {
-        "is-extglob": "^2.1.1"
-      },
-      "engines": {
-        "node": ">=0.10.0"
+        "@types/d3-path": "*"
       }
     },
-    "node_modules/is-number": {
-      "version": "7.0.0",
-      "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
-      "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.12.0"
+    "node_modules/@types/d3-time": {
+      "version": "3.0.4",
+      "resolved": "https://registry.npmjs.org/@types/d3-time/-/d3-time-3.0.4.tgz",
+      "integrity": "sha512-yuzZug1nkAAaBlBBikKZTgzCeA+k1uy4ZFwWANOfKw5z5LRhV0gNA7gNkKm7HoK+HRN0wX3EkxGk0fpbWhmB7g=="
+    },
+    "node_modules/@types/d3-time-format": {
+      "version": "4.0.3",
+      "resolved": "https://registry.npmjs.org/@types/d3-time-format/-/d3-time-format-4.0.3.tgz",
+      "integrity": "sha512-5xg9rC+wWL8kdDj153qZcsJ0FWiFt0J5RB6LYUNZjwSnesfblqrI/bJ1wBdJ8OQfncgbJG5+2F+qfqnqyzYxyg=="
+    },
+    "node_modules/@types/d3-timer": {
+      "version": "3.0.2",
+      "resolved": "https://registry.npmjs.org/@types/d3-timer/-/d3-timer-3.0.2.tgz",
+      "integrity": "sha512-Ps3T8E8dZDam6fUyNiMkekK3XUsaUEik+idO9/YjPtfj2qruF8tFBXS7XhtE4iIXBLxhmLjP3SXpLhVf21I9Lw=="
+    },
+    "node_modules/@types/d3-transition": {
+      "version": "3.0.9",
+      "resolved": "https://registry.npmjs.org/@types/d3-transition/-/d3-transition-3.0.9.tgz",
+      "integrity": "sha512-uZS5shfxzO3rGlu0cC3bjmMFKsXv+SmZZcgp0KD22ts4uGXp5EVYGzu/0YdwZeKmddhcAccYtREJKkPfXkZuCg==",
+      "dependencies": {
+        "@types/d3-selection": "*"
       }
     },
-    "node_modules/isexe": {
+    "node_modules/@types/d3-zoom": {
+      "version": "3.0.8",
+      "resolved": "https://registry.npmjs.org/@types/d3-zoom/-/d3-zoom-3.0.8.tgz",
+      "integrity": "sha512-iqMC4/YlFCSlO8+2Ii1GGGliCAY4XdeG748w5vQUbevlbDu0zSjH/+jojorQVBK/se0j6DUFNPBGSqD3YWYnDw==",
+      "dependencies": {
+        "@types/d3-interpolate": "*",
+        "@types/d3-selection": "*"
+      }
+    },
+    "node_modules/@types/geojson": {
+      "version": "7946.0.16",
+      "resolved": "https://registry.npmjs.org/@types/geojson/-/geojson-7946.0.16.tgz",
+      "integrity": "sha512-6C8nqWur3j98U6+lXDfTUWIfgvZU+EumvpHKcYjujKH7woYyLj2sUmff0tRhrqM7BohUw7Pz3ZB1jj2gW9Fvmg=="
+    },
+    "node_modules/@types/trusted-types": {
+      "version": "2.0.7",
+      "resolved": "https://registry.npmjs.org/@types/trusted-types/-/trusted-types-2.0.7.tgz",
+      "integrity": "sha512-ScaPdn1dQczgbl0QFTeTOmVHFULt394XJgOQNoyVhZ6r2vLnMLJfBPd53SB52T/3G36VI1/g2MZaX0cwDuXsfw==",
+      "optional": true
+    },
+    "node_modules/@upsetjs/venn.js": {
       "version": "2.0.0",
-      "resolved": "https://registry.npmjs.org/isexe/-/isexe-2.0.0.tgz",
-      "integrity": "sha512-RHxMLp9lnKHGHRng9QFhRCMbYAcVpn69smSGcq3f36xjgVVWThj4qqLbTLlq7Ssj8B+fIQ1EuCEGI2lKsyQeIw==",
-      "license": "ISC"
+      "resolved": "https://registry.npmjs.org/@upsetjs/venn.js/-/venn.js-2.0.0.tgz",
+      "integrity": "sha512-WbBhLrooyePuQ1VZxrJjtLvTc4NVfpOyKx0sKqioq9bX1C1m7Jgykkn8gLrtwumBioXIqam8DLxp88Adbue6Hw==",
+      "optionalDependencies": {
+        "d3-selection": "^3.0.0",
+        "d3-transition": "^3.0.1"
+      }
     },
-    "node_modules/jackspeak": {
-      "version": "3.4.3",
-      "resolved": "https://registry.npmjs.org/jackspeak/-/jackspeak-3.4.3.tgz",
-      "integrity": "sha512-OGlZQpz2yfahA/Rd1Y8Cd9SIEsqvXkLVoSw/cgwhnhFMDbsQFeZYoJJ7bIZBS9BcamUW96asq/npPWugM+RQBw==",
-      "license": "BlueOak-1.0.0",
+    "node_modules/@vue/reactivity": {
+      "version": "3.1.5",
+      "resolved": "https://registry.npmjs.org/@vue/reactivity/-/reactivity-3.1.5.tgz",
+      "integrity": "sha512-1tdfLmNjWG6t/CsPldh+foumYFo3cpyCHgBYQ34ylaMsJ+SNHQ1kApMIa8jN+i593zQuaw3AdWH0nJTARzCFhg==",
+      "license": "MIT",
       "dependencies": {
-        "@isaacs/cliui": "^8.0.2"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/isaacs"
-      },
-      "optionalDependencies": {
-        "@pkgjs/parseargs": "^0.11.0"
+        "@vue/shared": "3.1.5"
       }
     },
-    "node_modules/jiti": {
-      "version": "1.21.6",
-      "resolved": "https://registry.npmjs.org/jiti/-/jiti-1.21.6.tgz",
-      "integrity": "sha512-2yTgeWTWzMWkHu6Jp9NKgePDaYHbntiwvYuuJLbbN9vl7DC9DvXKOB2BC3ZZ92D3cvV/aflH0osDfwpHepQ53w==",
+    "node_modules/@vue/shared": {
+      "version": "3.1.5",
+      "resolved": "https://registry.npmjs.org/@vue/shared/-/shared-3.1.5.tgz",
+      "integrity": "sha512-oJ4F3TnvpXaQwZJNF3ZK+kLPHKarDmJjJ6jyzVNDKH9md1dptjC7lWR//jrGuLdek/U6iltWxqAnYOu8gCiOvA==",
+      "license": "MIT"
+    },
+    "node_modules/alpinejs": {
+      "version": "3.15.8",
+      "resolved": "https://registry.npmjs.org/alpinejs/-/alpinejs-3.15.8.tgz",
+      "integrity": "sha512-zxIfCRTBGvF1CCLIOMQOxAyBuqibxSEwS6Jm1a3HGA9rgrJVcjEWlwLcQTVGAWGS8YhAsTRLVrtQ5a5QT9bSSQ==",
       "license": "MIT",
-      "bin": {
-        "jiti": "bin/jiti.js"
+      "dependencies": {
+        "@vue/reactivity": "~3.1.1"
       }
     },
-    "node_modules/jsonfile": {
-      "version": "6.1.0",
-      "resolved": "https://registry.npmjs.org/jsonfile/-/jsonfile-6.1.0.tgz",
-      "integrity": "sha512-5dgndWOriYSm5cnYaJNhalLNDKOqFwyDB/rr1E9ZsGciGvKPs8R2xYGCacuf3z6K1YKDz182fd+fY3cn3pMqXQ==",
+    "node_modules/braces": {
+      "version": "3.0.3",
+      "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
+      "integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
       "license": "MIT",
       "dependencies": {
-        "universalify": "^2.0.0"
+        "fill-range": "^7.1.1"
       },
-      "optionalDependencies": {
-        "graceful-fs": "^4.1.6"
+      "engines": {
+        "node": ">=8"
       }
     },
-    "node_modules/lilconfig": {
-      "version": "3.1.2",
-      "resolved": "https://registry.npmjs.org/lilconfig/-/lilconfig-3.1.2.tgz",
-      "integrity": "sha512-eop+wDAvpItUys0FWkHIKeC9ybYrTGbU41U5K7+bttZZeohvnY7M9dZ5kB21GNWiFT2q1OoPTvncPCgSOVO5ow==",
+    "node_modules/commander": {
+      "version": "8.3.0",
+      "resolved": "https://registry.npmjs.org/commander/-/commander-8.3.0.tgz",
+      "integrity": "sha512-OkTL9umf+He2DZkUq8f8J9of7yL6RJKI24dVITBmNfZBmri9zYZQrKkuXiKhyfPSu8tUhnVBB1iKXevvnlR4Ww==",
       "license": "MIT",
       "engines": {
-        "node": ">=14"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/antonk52"
+        "node": ">= 12"
       }
     },
-    "node_modules/lines-and-columns": {
-      "version": "1.2.4",
-      "resolved": "https://registry.npmjs.org/lines-and-columns/-/lines-and-columns-1.2.4.tgz",
-      "integrity": "sha512-7ylylesZQ/PV29jhEDl3Ufjo6ZX7gCqJr5F7PKrqc93v7fzSymt1BpwEU8nAUXs8qzzvqhbjhK5QZg6Mt/HkBg==",
-      "license": "MIT"
-    },
-    "node_modules/linkify-it": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-5.0.0.tgz",
-      "integrity": "sha512-5aHCbzQRADcdP+ATqnDuhhJ/MRIqDkZX5pyjFHRRysS8vZ5AbqGEoFIb6pYHPZ+L/OC2Lc+xT8uHVVR5CAK/wQ==",
-      "dev": true,
-      "license": "MIT",
+    "node_modules/cose-base": {
+      "version": "1.0.3",
+      "resolved": "https://registry.npmjs.org/cose-base/-/cose-base-1.0.3.tgz",
+      "integrity": "sha512-s9whTXInMSgAp/NVXVNuVxVKzGH2qck3aQlVHxDCdAEPgtMKwc4Wq6/QKhgdEdgbLSi9rBTAcPoRa6JpiG4ksg==",
       "dependencies": {
-        "uc.micro": "^2.0.0"
+        "layout-base": "^1.0.0"
       }
     },
-    "node_modules/lodash.castarray": {
-      "version": "4.4.0",
-      "resolved": "https://registry.npmjs.org/lodash.castarray/-/lodash.castarray-4.4.0.tgz",
-      "integrity": "sha512-aVx8ztPv7/2ULbArGJ2Y42bG1mEQ5mGjpdvrbJcJFU3TbYybe+QlLS4pst9zV52ymy2in1KpFPiZnAOATxD4+Q==",
-      "license": "MIT"
-    },
-    "node_modules/lodash.isplainobject": {
-      "version": "4.0.6",
-      "resolved": "https://registry.npmjs.org/lodash.isplainobject/-/lodash.isplainobject-4.0.6.tgz",
-      "integrity": "sha512-oSXzaWypCMHkPC3NvBEaPHf0KsA5mvPrOPgQWDsbg8n7orZ290M0BmC/jgRZ4vcJ6DTAhjrsSYgdsW/F+MFOBA==",
-      "license": "MIT"
+    "node_modules/cssesc": {
+      "version": "3.0.0",
+      "resolved": "https://registry.npmjs.org/cssesc/-/cssesc-3.0.0.tgz",
+      "integrity": "sha512-/Tb/JcjK111nNScGob5MNtsntNM1aCNUDipB/TkwZFhyDrrE47SOx/18wF2bbjgc3ZzCSKW1T5nt5EbFoAz/Vg==",
+      "license": "MIT",
+      "bin": {
+        "cssesc": "bin/cssesc"
+      },
+      "engines": {
+        "node": ">=4"
+      }
     },
-    "node_modules/lodash.merge": {
-      "version": "4.6.2",
-      "resolved": "https://registry.npmjs.org/lodash.merge/-/lodash.merge-4.6.2.tgz",
-      "integrity": "sha512-0KpjqXRVvrYyCsX1swR/XTK0va6VQkQM6MNo7PqW77ByjAhoARA8EfrP1N4+KlKj8YS0ZUCtRT/YUuhyYDujIQ==",
-      "license": "MIT"
+    "node_modules/cytoscape": {
+      "version": "3.33.4",
+      "resolved": "https://registry.npmjs.org/cytoscape/-/cytoscape-3.33.4.tgz",
+      "integrity": "sha512-HIN5Pmd9MrX9BkV7tDwnOcEJCSFvCpc8X97h3f508J6I5FsqAY65wKOCvgH2CuP42CaahWaz4tuh32SOOIH7ww==",
+      "engines": {
+        "node": ">=0.10"
+      }
     },
-    "node_modules/lru-cache": {
-      "version": "10.4.3",
-      "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-10.4.3.tgz",
-      "integrity": "sha512-JNAzZcXrCt42VGLuYz0zfAzDfAvJWW6AfYlDBQyDV5DClI2m5sAmK+OIO7s59XfsRsWHp02jAJrRadPRGTt6SQ==",
-      "license": "ISC"
+    "node_modules/cytoscape-cose-bilkent": {
+      "version": "4.1.0",
+      "resolved": "https://registry.npmjs.org/cytoscape-cose-bilkent/-/cytoscape-cose-bilkent-4.1.0.tgz",
+      "integrity": "sha512-wgQlVIUJF13Quxiv5e1gstZ08rnZj2XaLHGoFMYXz7SkNfCDOOteKBE6SYRfA9WxxI/iBc3ajfDoc6hb/MRAHQ==",
+      "dependencies": {
+        "cose-base": "^1.0.0"
+      },
+      "peerDependencies": {
+        "cytoscape": "^3.2.0"
+      }
     },
-    "node_modules/markdown-it": {
-      "version": "14.1.0",
-      "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-14.1.0.tgz",
-      "integrity": "sha512-a54IwgWPaeBCAAsv13YgmALOF1elABB08FxO9i+r4VFk5Vl4pKokRPeX8u5TCgSsPi6ec1otfLjdOpVcgbpshg==",
-      "dev": true,
-      "license": "MIT",
+    "node_modules/cytoscape-fcose": {
+      "version": "2.2.0",
+      "resolved": "https://registry.npmjs.org/cytoscape-fcose/-/cytoscape-fcose-2.2.0.tgz",
+      "integrity": "sha512-ki1/VuRIHFCzxWNrsshHYPs6L7TvLu3DL+TyIGEsRcvVERmxokbf5Gdk7mFxZnTdiGtnA4cfSmjZJMviqSuZrQ==",
       "dependencies": {
-        "argparse": "^2.0.1",
-        "entities": "^4.4.0",
-        "linkify-it": "^5.0.0",
-        "mdurl": "^2.0.0",
-        "punycode.js": "^2.3.1",
-        "uc.micro": "^2.1.0"
+        "cose-base": "^2.2.0"
       },
-      "bin": {
-        "markdown-it": "bin/markdown-it.mjs"
+      "peerDependencies": {
+        "cytoscape": "^3.2.0"
       }
     },
-    "node_modules/markdownlint": {
-      "version": "0.35.0",
-      "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.35.0.tgz",
-      "integrity": "sha512-wgp8yesWjFBL7bycA3hxwHRdsZGJhjhyP1dSxKVKrza0EPFYtn+mHtkVy6dvP1kGSjovyG5B8yNP6Frj0UFUJg==",
-      "dev": true,
-      "license": "MIT",
+    "node_modules/cytoscape-fcose/node_modules/cose-base": {
+      "version": "2.2.0",
+      "resolved": "https://registry.npmjs.org/cose-base/-/cose-base-2.2.0.tgz",
+      "integrity": "sha512-AzlgcsCbUMymkADOJtQm3wO9S3ltPfYOFD5033keQn9NJzIbtnZj+UdBJe7DYml/8TdbtHJW3j58SOnKhWY/5g==",
       "dependencies": {
-        "markdown-it": "14.1.0",
-        "markdownlint-micromark": "0.1.10"
+        "layout-base": "^2.0.0"
+      }
+    },
+    "node_modules/cytoscape-fcose/node_modules/layout-base": {
+      "version": "2.0.1",
+      "resolved": "https://registry.npmjs.org/layout-base/-/layout-base-2.0.1.tgz",
+      "integrity": "sha512-dp3s92+uNI1hWIpPGH3jK2kxE2lMjdXdr+DH8ynZHpd6PUlH6x6cbuXnoMmiNumznqaNO31xu9e79F0uuZ0JFg=="
+    },
+    "node_modules/d3": {
+      "version": "7.9.0",
+      "resolved": "https://registry.npmjs.org/d3/-/d3-7.9.0.tgz",
+      "integrity": "sha512-e1U46jVP+w7Iut8Jt8ri1YsPOvFpg46k+K8TpCb0P+zjCkjkPnV7WzfDJzMHy1LnA+wj5pLT1wjO901gLXeEhA==",
+      "dependencies": {
+        "d3-array": "3",
+        "d3-axis": "3",
+        "d3-brush": "3",
+        "d3-chord": "3",
+        "d3-color": "3",
+        "d3-contour": "4",
+        "d3-delaunay": "6",
+        "d3-dispatch": "3",
+        "d3-drag": "3",
+        "d3-dsv": "3",
+        "d3-ease": "3",
+        "d3-fetch": "3",
+        "d3-force": "3",
+        "d3-format": "3",
+        "d3-geo": "3",
+        "d3-hierarchy": "3",
+        "d3-interpolate": "3",
+        "d3-path": "3",
+        "d3-polygon": "3",
+        "d3-quadtree": "3",
+        "d3-random": "3",
+        "d3-scale": "4",
+        "d3-scale-chromatic": "3",
+        "d3-selection": "3",
+        "d3-shape": "3",
+        "d3-time": "3",
+        "d3-time-format": "4",
+        "d3-timer": "3",
+        "d3-transition": "3",
+        "d3-zoom": "3"
       },
       "engines": {
-        "node": ">=18"
+        "node": ">=12"
+      }
+    },
+    "node_modules/d3-array": {
+      "version": "3.2.4",
+      "resolved": "https://registry.npmjs.org/d3-array/-/d3-array-3.2.4.tgz",
+      "integrity": "sha512-tdQAmyA18i4J7wprpYq8ClcxZy3SC31QMeByyCFyRt7BVHdREQZ5lpzoe5mFEYZUWe+oq8HBvk9JjpibyEV4Jg==",
+      "dependencies": {
+        "internmap": "1 - 2"
       },
-      "funding": {
-        "url": "https://github.com/sponsors/DavidAnson"
+      "engines": {
+        "node": ">=12"
       }
     },
-    "node_modules/markdownlint-micromark": {
-      "version": "0.1.10",
-      "resolved": "https://registry.npmjs.org/markdownlint-micromark/-/markdownlint-micromark-0.1.10.tgz",
-      "integrity": "sha512-no5ZfdqAdWGxftCLlySHSgddEjyW4kui4z7amQcGsSKfYC5v/ou+8mIQVyg9KQMeEZLNtz9OPDTj7nnTnoR4FQ==",
-      "dev": true,
-      "license": "MIT",
+    "node_modules/d3-axis": {
+      "version": "3.0.0",
+      "resolved": "https://registry.npmjs.org/d3-axis/-/d3-axis-3.0.0.tgz",
+      "integrity": "sha512-IH5tgjV4jE/GhHkRV0HiVYPDtvfjHQlQfJHs0usq7M30XcSBvOotpmH1IgkcXsO/5gEQZD43B//fc7SRT5S+xw==",
       "engines": {
-        "node": ">=18"
+        "node": ">=12"
+      }
+    },
+    "node_modules/d3-brush": {
+      "version": "3.0.0",
+      "resolved": "https://registry.npmjs.org/d3-brush/-/d3-brush-3.0.0.tgz",
+      "integrity": "sha512-ALnjWlVYkXsVIGlOsuWH1+3udkYFI48Ljihfnh8FZPF2QS9o+PzGLBslO0PjzVoHLZ2KCVgAM8NVkXPJB2aNnQ==",
+      "dependencies": {
+        "d3-dispatch": "1 - 3",
+        "d3-drag": "2 - 3",
+        "d3-interpolate": "1 - 3",
+        "d3-selection": "3",
+        "d3-transition": "3"
       },
-      "funding": {
-        "url": "https://github.com/sponsors/DavidAnson"
+      "engines": {
+        "node": ">=12"
       }
     },
-    "node_modules/mdurl": {
-      "version": "2.0.0",
-      "resolved": "https://registry.npmjs.org/mdurl/-/mdurl-2.0.0.tgz",
-      "integrity": "sha512-Lf+9+2r+Tdp5wXDXC4PcIBjTDtq4UKjCPMQhKIuzpJNW0b96kVqSwW0bT7FhRSfmAiFYgP+SCRvdrDozfh0U5w==",
-      "dev": true,
-      "license": "MIT"
+    "node_modules/d3-chord": {
+      "version": "3.0.1",
+      "resolved": "https://registry.npmjs.org/d3-chord/-/d3-chord-3.0.1.tgz",
+      "integrity": "sha512-VE5S6TNa+j8msksl7HwjxMHDM2yNK3XCkusIlpX5kwauBfXuyLAtNg9jCp/iHH61tgI4sb6R/EIMWCqEIdjT/g==",
+      "dependencies": {
+        "d3-path": "1 - 3"
+      },
+      "engines": {
+        "node": ">=12"
+      }
     },
-    "node_modules/merge2": {
-      "version": "1.4.1",
-      "resolved": "https://registry.npmjs.org/merge2/-/merge2-1.4.1.tgz",
-      "integrity": "sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==",
-      "license": "MIT",
+    "node_modules/d3-color": {
+      "version": "3.1.0",
+      "resolved": "https://registry.npmjs.org/d3-color/-/d3-color-3.1.0.tgz",
+      "integrity": "sha512-zg/chbXyeBtMQ1LbD/WSoW2DpC3I0mpmPdW+ynRTj/x2DAWYrIY7qeZIHidozwV24m4iavr15lNwIwLxRmOxhA==",
       "engines": {
-        "node": ">= 8"
+        "node": ">=12"
       }
     },
-    "node_modules/micromatch": {
-      "version": "4.0.8",
-      "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.8.tgz",
-      "integrity": "sha512-PXwfBhYu0hBCPw8Dn0E+WDYb7af3dSLVWKi3HGv84IdF4TyFoC0ysxFd0Goxw7nSv4T/PzEJQxsYsEiFCKo2BA==",
-      "license": "MIT",
+    "node_modules/d3-contour": {
+      "version": "4.0.2",
+      "resolved": "https://registry.npmjs.org/d3-contour/-/d3-contour-4.0.2.tgz",
+      "integrity": "sha512-4EzFTRIikzs47RGmdxbeUvLWtGedDUNkTcmzoeyg4sP/dvCexO47AaQL7VKy/gul85TOxw+IBgA8US2xwbToNA==",
       "dependencies": {
-        "braces": "^3.0.3",
-        "picomatch": "^2.3.1"
+        "d3-array": "^3.2.0"
       },
       "engines": {
-        "node": ">=8.6"
+        "node": ">=12"
       }
     },
-    "node_modules/minimatch": {
-      "version": "9.0.5",
-      "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz",
-      "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==",
-      "license": "ISC",
+    "node_modules/d3-delaunay": {
+      "version": "6.0.4",
+      "resolved": "https://registry.npmjs.org/d3-delaunay/-/d3-delaunay-6.0.4.tgz",
+      "integrity": "sha512-mdjtIZ1XLAM8bm/hx3WwjfHt6Sggek7qH043O8KEjDXN40xi3vx/6pYSVTwLjEgiXQTbvaouWKynLBiUZ6SK6A==",
       "dependencies": {
-        "brace-expansion": "^2.0.1"
+        "delaunator": "5"
       },
       "engines": {
-        "node": ">=16 || 14 >=14.17"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/isaacs"
+        "node": ">=12"
       }
     },
-    "node_modules/minipass": {
-      "version": "7.1.2",
-      "resolved": "https://registry.npmjs.org/minipass/-/minipass-7.1.2.tgz",
-      "integrity": "sha512-qOOzS1cBTWYF4BH8fVePDBOO9iptMnGUEZwNc/cMWnTV2nVLZ7VoNWEPHkYczZA0pdoA7dl6e7FL659nX9S2aw==",
-      "license": "ISC",
+    "node_modules/d3-dispatch": {
+      "version": "3.0.1",
+      "resolved": "https://registry.npmjs.org/d3-dispatch/-/d3-dispatch-3.0.1.tgz",
+      "integrity": "sha512-rzUyPU/S7rwUflMyLc1ETDeBj0NRuHKKAcvukozwhshr6g6c5d8zh4c2gQjY2bZ0dXeGLWc1PF174P2tVvKhfg==",
       "engines": {
-        "node": ">=16 || 14 >=14.17"
+        "node": ">=12"
       }
     },
-    "node_modules/mz": {
-      "version": "2.7.0",
-      "resolved": "https://registry.npmjs.org/mz/-/mz-2.7.0.tgz",
-      "integrity": "sha512-z81GNO7nnYMEhrGh9LeymoE4+Yr0Wn5McHIZMK5cfQCl+NDX08sCZgUc9/6MHni9IWuFLm1Z3HTCXu2z9fN62Q==",
-      "license": "MIT",
+    "node_modules/d3-drag": {
+      "version": "3.0.0",
+      "resolved": "https://registry.npmjs.org/d3-drag/-/d3-drag-3.0.0.tgz",
+      "integrity": "sha512-pWbUJLdETVA8lQNJecMxoXfH6x+mO2UQo8rSmZ+QqxcbyA3hfeprFgIT//HW2nlHChWeIIMwS2Fq+gEARkhTkg==",
       "dependencies": {
-        "any-promise": "^1.0.0",
-        "object-assign": "^4.0.1",
-        "thenify-all": "^1.0.0"
+        "d3-dispatch": "1 - 3",
+        "d3-selection": "3"
+      },
+      "engines": {
+        "node": ">=12"
       }
     },
-    "node_modules/nanoid": {
-      "version": "3.3.7",
-      "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.7.tgz",
-      "integrity": "sha512-eSRppjcPIatRIMC1U6UngP8XFcz8MQWGQdt1MTBQ7NaAmvXDfvNxbvWV3x2y6CdEUciCSsDHDQZbhYaB8QEo2g==",
-      "funding": [
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/ai"
-        }
-      ],
-      "license": "MIT",
+    "node_modules/d3-dsv": {
+      "version": "3.0.1",
+      "resolved": "https://registry.npmjs.org/d3-dsv/-/d3-dsv-3.0.1.tgz",
+      "integrity": "sha512-UG6OvdI5afDIFP9w4G0mNq50dSOsXHJaRE8arAS5o9ApWnIElp8GZw1Dun8vP8OyHOZ/QJUKUJwxiiCCnUwm+Q==",
+      "dependencies": {
+        "commander": "7",
+        "iconv-lite": "0.6",
+        "rw": "1"
+      },
       "bin": {
-        "nanoid": "bin/nanoid.cjs"
+        "csv2json": "bin/dsv2json.js",
+        "csv2tsv": "bin/dsv2dsv.js",
+        "dsv2dsv": "bin/dsv2dsv.js",
+        "dsv2json": "bin/dsv2json.js",
+        "json2csv": "bin/json2dsv.js",
+        "json2dsv": "bin/json2dsv.js",
+        "json2tsv": "bin/json2dsv.js",
+        "tsv2csv": "bin/dsv2dsv.js",
+        "tsv2json": "bin/dsv2json.js"
       },
       "engines": {
-        "node": "^10 || ^12 || ^13.7 || ^14 || >=15.0.1"
+        "node": ">=12"
       }
     },
-    "node_modules/node-releases": {
-      "version": "2.0.18",
-      "resolved": "https://registry.npmjs.org/node-releases/-/node-releases-2.0.18.tgz",
-      "integrity": "sha512-d9VeXT4SJ7ZeOqGX6R5EM022wpL+eWPooLI+5UpWn2jCT1aosUQEhQP214x33Wkwx3JQMvIm+tIoVOdodFS40g==",
-      "license": "MIT"
-    },
-    "node_modules/normalize-path": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz",
-      "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==",
-      "license": "MIT",
+    "node_modules/d3-dsv/node_modules/commander": {
+      "version": "7.2.0",
+      "resolved": "https://registry.npmjs.org/commander/-/commander-7.2.0.tgz",
+      "integrity": "sha512-QrWXB+ZQSVPmIWIhtEO9H+gwHaMGYiF5ChvoJ+K9ZGHG/sVsa6yiesAD1GC/x46sET00Xlwo1u49RVVVzvcSkw==",
       "engines": {
-        "node": ">=0.10.0"
+        "node": ">= 10"
       }
     },
-    "node_modules/normalize-range": {
-      "version": "0.1.2",
-      "resolved": "https://registry.npmjs.org/normalize-range/-/normalize-range-0.1.2.tgz",
-      "integrity": "sha512-bdok/XvKII3nUpklnV6P2hxtMNrCboOjAcyBuQnWEhO665FwrSNRxU+AqpsyvO6LgGYPspN+lu5CLtw4jPRKNA==",
-      "license": "MIT",
+    "node_modules/d3-ease": {
+      "version": "3.0.1",
+      "resolved": "https://registry.npmjs.org/d3-ease/-/d3-ease-3.0.1.tgz",
+      "integrity": "sha512-wR/XK3D3XcLIZwpbvQwQ5fK+8Ykds1ip7A2Txe0yxncXSdq1L9skcG7blcedkOX+ZcgxGAmLX1FrRGbADwzi0w==",
       "engines": {
-        "node": ">=0.10.0"
+        "node": ">=12"
       }
     },
-    "node_modules/object-assign": {
-      "version": "4.1.1",
-      "resolved": "https://registry.npmjs.org/object-assign/-/object-assign-4.1.1.tgz",
-      "integrity": "sha512-rJgTQnkUnH1sFw8yT6VSU3zD3sWmu6sZhIseY8VX+GRu3P6F7Fu+JNDoXfklElbLJSnc3FUQHVe4cU5hj+BcUg==",
-      "license": "MIT",
+    "node_modules/d3-fetch": {
+      "version": "3.0.1",
+      "resolved": "https://registry.npmjs.org/d3-fetch/-/d3-fetch-3.0.1.tgz",
+      "integrity": "sha512-kpkQIM20n3oLVBKGg6oHrUchHM3xODkTzjMoj7aWQFq5QEM+R6E4WkzT5+tojDY7yjez8KgCBRoj4aEr99Fdqw==",
+      "dependencies": {
+        "d3-dsv": "1 - 3"
+      },
       "engines": {
-        "node": ">=0.10.0"
+        "node": ">=12"
       }
     },
-    "node_modules/object-hash": {
+    "node_modules/d3-force": {
       "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/object-hash/-/object-hash-3.0.0.tgz",
-      "integrity": "sha512-RSn9F68PjH9HqtltsSnqYC1XXoWe9Bju5+213R98cNGttag9q9yAOTzdbsqvIa7aNm5WffBZFpWYr2aWrklWAw==",
-      "license": "MIT",
+      "resolved": "https://registry.npmjs.org/d3-force/-/d3-force-3.0.0.tgz",
+      "integrity": "sha512-zxV/SsA+U4yte8051P4ECydjD/S+qeYtnaIyAs9tgHCqfguma/aAQDjo85A9Z6EKhBirHRJHXIgJUlffT4wdLg==",
+      "dependencies": {
+        "d3-dispatch": "1 - 3",
+        "d3-quadtree": "1 - 3",
+        "d3-timer": "1 - 3"
+      },
       "engines": {
-        "node": ">= 6"
+        "node": ">=12"
       }
     },
-    "node_modules/package-json-from-dist": {
-      "version": "1.0.1",
-      "resolved": "https://registry.npmjs.org/package-json-from-dist/-/package-json-from-dist-1.0.1.tgz",
-      "integrity": "sha512-UEZIS3/by4OC8vL3P2dTXRETpebLI2NiI5vIrjaD/5UtrkFX/tNbwjTSRAGC/+7CAo2pIcBaRgWmcBBHcsaCIw==",
-      "license": "BlueOak-1.0.0"
+    "node_modules/d3-format": {
+      "version": "3.1.2",
+      "resolved": "https://registry.npmjs.org/d3-format/-/d3-format-3.1.2.tgz",
+      "integrity": "sha512-AJDdYOdnyRDV5b6ArilzCPPwc1ejkHcoyFarqlPqT7zRYjhavcT3uSrqcMvsgh2CgoPbK3RCwyHaVyxYcP2Arg==",
+      "engines": {
+        "node": ">=12"
+      }
     },
-    "node_modules/path-key": {
+    "node_modules/d3-geo": {
       "version": "3.1.1",
-      "resolved": "https://registry.npmjs.org/path-key/-/path-key-3.1.1.tgz",
-      "integrity": "sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==",
-      "license": "MIT",
+      "resolved": "https://registry.npmjs.org/d3-geo/-/d3-geo-3.1.1.tgz",
+      "integrity": "sha512-637ln3gXKXOwhalDzinUgY83KzNWZRKbYubaG+fGVuc/dxO64RRljtCTnf5ecMyE1RIdtqpkVcq0IbtU2S8j2Q==",
+      "dependencies": {
+        "d3-array": "2.5.0 - 3"
+      },
       "engines": {
-        "node": ">=8"
+        "node": ">=12"
       }
     },
-    "node_modules/path-parse": {
-      "version": "1.0.7",
-      "resolved": "https://registry.npmjs.org/path-parse/-/path-parse-1.0.7.tgz",
-      "integrity": "sha512-LDJzPVEEEPR+y48z93A0Ed0yXb8pAByGWo/k5YYdYgpY2/2EsOsksJrq7lOHxryrVOn1ejG6oAp8ahvOIQD8sw==",
-      "license": "MIT"
+    "node_modules/d3-hierarchy": {
+      "version": "3.1.2",
+      "resolved": "https://registry.npmjs.org/d3-hierarchy/-/d3-hierarchy-3.1.2.tgz",
+      "integrity": "sha512-FX/9frcub54beBdugHjDCdikxThEqjnR93Qt7PvQTOHxyiNCAlvMrHhclk3cD5VeAaq9fxmfRp+CnWw9rEMBuA==",
+      "engines": {
+        "node": ">=12"
+      }
     },
-    "node_modules/path-scurry": {
-      "version": "1.11.1",
-      "resolved": "https://registry.npmjs.org/path-scurry/-/path-scurry-1.11.1.tgz",
-      "integrity": "sha512-Xa4Nw17FS9ApQFJ9umLiJS4orGjm7ZzwUrwamcGQuHSzDyth9boKDaycYdDcZDuqYATXw4HFXgaqWTctW/v1HA==",
-      "license": "BlueOak-1.0.0",
+    "node_modules/d3-interpolate": {
+      "version": "3.0.1",
+      "resolved": "https://registry.npmjs.org/d3-interpolate/-/d3-interpolate-3.0.1.tgz",
+      "integrity": "sha512-3bYs1rOD33uo8aqJfKP3JWPAibgw8Zm2+L9vBKEHJ2Rg+viTR7o5Mmv5mZcieN+FRYaAOWX5SJATX6k1PWz72g==",
       "dependencies": {
-        "lru-cache": "^10.2.0",
-        "minipass": "^5.0.0 || ^6.0.2 || ^7.0.0"
+        "d3-color": "1 - 3"
       },
       "engines": {
-        "node": ">=16 || 14 >=14.18"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/isaacs"
+        "node": ">=12"
       }
     },
-    "node_modules/path-type": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/path-type/-/path-type-5.0.0.tgz",
-      "integrity": "sha512-5HviZNaZcfqP95rwpv+1HDgUamezbqdSYTyzjTvwtJSnIH+3vnbmWsItli8OFEndS984VT55M3jduxZbX351gg==",
-      "license": "MIT",
+    "node_modules/d3-path": {
+      "version": "3.1.0",
+      "resolved": "https://registry.npmjs.org/d3-path/-/d3-path-3.1.0.tgz",
+      "integrity": "sha512-p3KP5HCf/bvjBSSKuXid6Zqijx7wIfNW+J/maPs+iwR35at5JCbLUT0LzF1cnjbCHWhqzQTIN2Jpe8pRebIEFQ==",
       "engines": {
         "node": ">=12"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
       }
     },
-    "node_modules/picocolors": {
-      "version": "1.1.1",
-      "resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.1.1.tgz",
-      "integrity": "sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==",
-      "license": "ISC"
-    },
-    "node_modules/picomatch": {
-      "version": "2.3.1",
-      "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz",
-      "integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==",
-      "license": "MIT",
+    "node_modules/d3-polygon": {
+      "version": "3.0.1",
+      "resolved": "https://registry.npmjs.org/d3-polygon/-/d3-polygon-3.0.1.tgz",
+      "integrity": "sha512-3vbA7vXYwfe1SYhED++fPUQlWSYTTGmFmQiany/gdbiWgU/iEyQzyymwL9SkJjFFuCS4902BSzewVGsHHmHtXg==",
       "engines": {
-        "node": ">=8.6"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/jonschlinkert"
+        "node": ">=12"
       }
     },
-    "node_modules/pify": {
-      "version": "2.3.0",
-      "resolved": "https://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
-      "integrity": "sha512-udgsAY+fTnvv7kI7aaxbqwWNb0AHiB0qBO89PZKPkoTmGOgdbrHDKD+0B2X4uTfJ/FT1R09r9gTsjUjNJotuog==",
-      "license": "MIT",
+    "node_modules/d3-quadtree": {
+      "version": "3.0.1",
+      "resolved": "https://registry.npmjs.org/d3-quadtree/-/d3-quadtree-3.0.1.tgz",
+      "integrity": "sha512-04xDrxQTDTCFwP5H6hRhsRcb9xxv2RzkcsygFzmkSIOJy3PeRJP7sNk3VRIbKXcog561P9oU0/rVH6vDROAgUw==",
       "engines": {
-        "node": ">=0.10.0"
+        "node": ">=12"
       }
     },
-    "node_modules/pirates": {
-      "version": "4.0.6",
-      "resolved": "https://registry.npmjs.org/pirates/-/pirates-4.0.6.tgz",
-      "integrity": "sha512-saLsH7WeYYPiD25LDuLRRY/i+6HaPYr6G1OUlN39otzkSTxKnubR9RTxS3/Kk50s1g2JTgFwWQDQyplC5/SHZg==",
-      "license": "MIT",
+    "node_modules/d3-random": {
+      "version": "3.0.1",
+      "resolved": "https://registry.npmjs.org/d3-random/-/d3-random-3.0.1.tgz",
+      "integrity": "sha512-FXMe9GfxTxqd5D6jFsQ+DJ8BJS4E/fT5mqqdjovykEB2oFbTMDVdg1MGFxfQW+FBOGoB++k8swBrgwSHT1cUXQ==",
       "engines": {
-        "node": ">= 6"
+        "node": ">=12"
       }
     },
-    "node_modules/postcss": {
-      "version": "8.4.49",
-      "resolved": "https://registry.npmjs.org/postcss/-/postcss-8.4.49.tgz",
-      "integrity": "sha512-OCVPnIObs4N29kxTjzLfUryOkvZEq+pf8jTF0lg8E7uETuWHA+v7j3c/xJmiqpX450191LlmZfUKkXxkTry7nA==",
-      "funding": [
-        {
-          "type": "opencollective",
-          "url": "https://opencollective.com/postcss/"
-        },
-        {
-          "type": "tidelift",
-          "url": "https://tidelift.com/funding/github/npm/postcss"
-        },
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/ai"
-        }
-      ],
-      "license": "MIT",
+    "node_modules/d3-sankey": {
+      "version": "0.12.3",
+      "resolved": "https://registry.npmjs.org/d3-sankey/-/d3-sankey-0.12.3.tgz",
+      "integrity": "sha512-nQhsBRmM19Ax5xEIPLMY9ZmJ/cDvd1BG3UVvt5h3WRxKg5zGRbvnteTyWAbzeSvlh3tW7ZEmq4VwR5mB3tutmQ==",
       "dependencies": {
-        "nanoid": "^3.3.7",
-        "picocolors": "^1.1.1",
-        "source-map-js": "^1.2.1"
+        "d3-array": "1 - 2",
+        "d3-shape": "^1.2.0"
+      }
+    },
+    "node_modules/d3-sankey/node_modules/d3-array": {
+      "version": "2.12.1",
+      "resolved": "https://registry.npmjs.org/d3-array/-/d3-array-2.12.1.tgz",
+      "integrity": "sha512-B0ErZK/66mHtEsR1TkPEEkwdy+WDesimkM5gpZr5Dsg54BiTA5RXtYW5qTLIAcekaS9xfZrzBLF/OAkB3Qn1YQ==",
+      "dependencies": {
+        "internmap": "^1.0.0"
+      }
+    },
+    "node_modules/d3-sankey/node_modules/d3-path": {
+      "version": "1.0.9",
+      "resolved": "https://registry.npmjs.org/d3-path/-/d3-path-1.0.9.tgz",
+      "integrity": "sha512-VLaYcn81dtHVTjEHd8B+pbe9yHWpXKZUC87PzoFmsFrJqgFwDe/qxfp5MlfsfM1V5E/iVt0MmEbWQ7FVIXh/bg=="
+    },
+    "node_modules/d3-sankey/node_modules/d3-shape": {
+      "version": "1.3.7",
+      "resolved": "https://registry.npmjs.org/d3-shape/-/d3-shape-1.3.7.tgz",
+      "integrity": "sha512-EUkvKjqPFUAZyOlhY5gzCxCeI0Aep04LwIRpsZ/mLFelJiUfnK56jo5JMDSE7yyP2kLSb6LtF+S5chMk7uqPqw==",
+      "dependencies": {
+        "d3-path": "1"
+      }
+    },
+    "node_modules/d3-sankey/node_modules/internmap": {
+      "version": "1.0.1",
+      "resolved": "https://registry.npmjs.org/internmap/-/internmap-1.0.1.tgz",
+      "integrity": "sha512-lDB5YccMydFBtasVtxnZ3MRBHuaoE8GKsppq+EchKL2U4nK/DmEpPHNH8MZe5HkMtpSiTSOZwfN0tzYjO/lJEw=="
+    },
+    "node_modules/d3-scale": {
+      "version": "4.0.2",
+      "resolved": "https://registry.npmjs.org/d3-scale/-/d3-scale-4.0.2.tgz",
+      "integrity": "sha512-GZW464g1SH7ag3Y7hXjf8RoUuAFIqklOAq3MRl4OaWabTFJY9PN/E1YklhXLh+OQ3fM9yS2nOkCoS+WLZ6kvxQ==",
+      "dependencies": {
+        "d3-array": "2.10.0 - 3",
+        "d3-format": "1 - 3",
+        "d3-interpolate": "1.2.0 - 3",
+        "d3-time": "2.1.1 - 3",
+        "d3-time-format": "2 - 4"
       },
       "engines": {
-        "node": "^10 || ^12 || >=14"
+        "node": ">=12"
       }
     },
-    "node_modules/postcss-cli": {
-      "version": "11.0.0",
-      "resolved": "https://registry.npmjs.org/postcss-cli/-/postcss-cli-11.0.0.tgz",
-      "integrity": "sha512-xMITAI7M0u1yolVcXJ9XTZiO9aO49mcoKQy6pCDFdMh9kGqhzLVpWxeD/32M/QBmkhcGypZFFOLNLmIW4Pg4RA==",
-      "license": "MIT",
+    "node_modules/d3-scale-chromatic": {
+      "version": "3.1.0",
+      "resolved": "https://registry.npmjs.org/d3-scale-chromatic/-/d3-scale-chromatic-3.1.0.tgz",
+      "integrity": "sha512-A3s5PWiZ9YCXFye1o246KoscMWqf8BsD9eRiJ3He7C9OBaxKhAd5TFCdEx/7VbKtxxTsu//1mMJFrEt572cEyQ==",
       "dependencies": {
-        "chokidar": "^3.3.0",
-        "dependency-graph": "^0.11.0",
-        "fs-extra": "^11.0.0",
-        "get-stdin": "^9.0.0",
-        "globby": "^14.0.0",
-        "picocolors": "^1.0.0",
-        "postcss-load-config": "^5.0.0",
-        "postcss-reporter": "^7.0.0",
-        "pretty-hrtime": "^1.0.3",
-        "read-cache": "^1.0.0",
-        "slash": "^5.0.0",
-        "yargs": "^17.0.0"
-      },
-      "bin": {
-        "postcss": "index.js"
+        "d3-color": "1 - 3",
+        "d3-interpolate": "1 - 3"
       },
       "engines": {
-        "node": ">=18"
-      },
-      "peerDependencies": {
-        "postcss": "^8.0.0"
+        "node": ">=12"
       }
     },
-    "node_modules/postcss-import": {
-      "version": "16.1.0",
-      "resolved": "https://registry.npmjs.org/postcss-import/-/postcss-import-16.1.0.tgz",
-      "integrity": "sha512-7hsAZ4xGXl4MW+OKEWCnF6T5jqBw80/EE9aXg1r2yyn1RsVEU8EtKXbijEODa+rg7iih4bKf7vlvTGYR4CnPNg==",
-      "license": "MIT",
+    "node_modules/d3-selection": {
+      "version": "3.0.0",
+      "resolved": "https://registry.npmjs.org/d3-selection/-/d3-selection-3.0.0.tgz",
+      "integrity": "sha512-fmTRWbNMmsmWq6xJV8D19U/gw/bwrHfNXxrIN+HfZgnzqTHp9jOmKMhsTUjXOJnZOdZY9Q28y4yebKzqDKlxlQ==",
+      "engines": {
+        "node": ">=12"
+      }
+    },
+    "node_modules/d3-shape": {
+      "version": "3.2.0",
+      "resolved": "https://registry.npmjs.org/d3-shape/-/d3-shape-3.2.0.tgz",
+      "integrity": "sha512-SaLBuwGm3MOViRq2ABk3eLoxwZELpH6zhl3FbAoJ7Vm1gofKx6El1Ib5z23NUEhF9AsGl7y+dzLe5Cw2AArGTA==",
       "dependencies": {
-        "postcss-value-parser": "^4.0.0",
-        "read-cache": "^1.0.0",
-        "resolve": "^1.1.7"
+        "d3-path": "^3.1.0"
       },
       "engines": {
-        "node": ">=18.0.0"
-      },
-      "peerDependencies": {
-        "postcss": "^8.0.0"
+        "node": ">=12"
       }
     },
-    "node_modules/postcss-js": {
-      "version": "4.0.1",
-      "resolved": "https://registry.npmjs.org/postcss-js/-/postcss-js-4.0.1.tgz",
-      "integrity": "sha512-dDLF8pEO191hJMtlHFPRa8xsizHaM82MLfNkUHdUtVEV3tgTp5oj+8qbEqYM57SLfc74KSbw//4SeJma2LRVIw==",
-      "license": "MIT",
+    "node_modules/d3-time": {
+      "version": "3.1.0",
+      "resolved": "https://registry.npmjs.org/d3-time/-/d3-time-3.1.0.tgz",
+      "integrity": "sha512-VqKjzBLejbSMT4IgbmVgDjpkYrNWUYJnbCGo874u7MMKIWsILRX+OpX/gTk8MqjpT1A/c6HY2dCA77ZN0lkQ2Q==",
       "dependencies": {
-        "camelcase-css": "^2.0.1"
+        "d3-array": "2 - 3"
       },
       "engines": {
-        "node": "^12 || ^14 || >= 16"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/postcss/"
-      },
-      "peerDependencies": {
-        "postcss": "^8.4.21"
+        "node": ">=12"
       }
     },
-    "node_modules/postcss-load-config": {
-      "version": "5.1.0",
-      "resolved": "https://registry.npmjs.org/postcss-load-config/-/postcss-load-config-5.1.0.tgz",
-      "integrity": "sha512-G5AJ+IX0aD0dygOE0yFZQ/huFFMSNneyfp0e3/bT05a8OfPC5FUoZRPfGijUdGOJNMewJiwzcHJXFafFzeKFVA==",
-      "funding": [
-        {
-          "type": "opencollective",
-          "url": "https://opencollective.com/postcss/"
-        },
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/ai"
-        }
-      ],
-      "license": "MIT",
+    "node_modules/d3-time-format": {
+      "version": "4.1.0",
+      "resolved": "https://registry.npmjs.org/d3-time-format/-/d3-time-format-4.1.0.tgz",
+      "integrity": "sha512-dJxPBlzC7NugB2PDLwo9Q8JiTR3M3e4/XANkreKSUxF8vvXKqm1Yfq4Q5dl8budlunRVlUUaDUgFt7eA8D6NLg==",
       "dependencies": {
-        "lilconfig": "^3.1.1",
-        "yaml": "^2.4.2"
+        "d3-time": "1 - 3"
       },
       "engines": {
-        "node": ">= 18"
-      },
-      "peerDependencies": {
-        "jiti": ">=1.21.0",
-        "postcss": ">=8.0.9",
-        "tsx": "^4.8.1"
-      },
-      "peerDependenciesMeta": {
-        "jiti": {
-          "optional": true
-        },
-        "postcss": {
-          "optional": true
-        },
-        "tsx": {
-          "optional": true
-        }
+        "node": ">=12"
       }
     },
-    "node_modules/postcss-nested": {
-      "version": "5.0.6",
-      "resolved": "https://registry.npmjs.org/postcss-nested/-/postcss-nested-5.0.6.tgz",
-      "integrity": "sha512-rKqm2Fk0KbA8Vt3AdGN0FB9OBOMDVajMG6ZCf/GoHgdxUJ4sBFp0A/uMIRm+MJUdo33YXEtjqIz8u7DAp8B7DA==",
-      "license": "MIT",
-      "dependencies": {
-        "postcss-selector-parser": "^6.0.6"
-      },
+    "node_modules/d3-timer": {
+      "version": "3.0.1",
+      "resolved": "https://registry.npmjs.org/d3-timer/-/d3-timer-3.0.1.tgz",
+      "integrity": "sha512-ndfJ/JxxMd3nw31uyKoY2naivF+r29V+Lc0svZxe1JvvIRmi8hUsrMvdOwgS1o6uBHmiz91geQ0ylPP0aj1VUA==",
       "engines": {
-        "node": ">=12.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/postcss/"
-      },
-      "peerDependencies": {
-        "postcss": "^8.2.14"
+        "node": ">=12"
       }
     },
-    "node_modules/postcss-reporter": {
-      "version": "7.1.0",
-      "resolved": "https://registry.npmjs.org/postcss-reporter/-/postcss-reporter-7.1.0.tgz",
-      "integrity": "sha512-/eoEylGWyy6/DOiMP5lmFRdmDKThqgn7D6hP2dXKJI/0rJSO1ADFNngZfDzxL0YAxFvws+Rtpuji1YIHj4mySA==",
-      "funding": [
-        {
-          "type": "opencollective",
-          "url": "https://opencollective.com/postcss/"
-        },
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/ai"
-        }
-      ],
-      "license": "MIT",
+    "node_modules/d3-transition": {
+      "version": "3.0.1",
+      "resolved": "https://registry.npmjs.org/d3-transition/-/d3-transition-3.0.1.tgz",
+      "integrity": "sha512-ApKvfjsSR6tg06xrL434C0WydLr7JewBB3V+/39RMHsaXTOG0zmt/OAXeng5M5LBm0ojmxJrpomQVZ1aPvBL4w==",
       "dependencies": {
-        "picocolors": "^1.0.0",
-        "thenby": "^1.3.4"
+        "d3-color": "1 - 3",
+        "d3-dispatch": "1 - 3",
+        "d3-ease": "1 - 3",
+        "d3-interpolate": "1 - 3",
+        "d3-timer": "1 - 3"
       },
       "engines": {
-        "node": ">=10"
+        "node": ">=12"
       },
       "peerDependencies": {
-        "postcss": "^8.1.0"
+        "d3-selection": "2 - 3"
       }
     },
-    "node_modules/postcss-selector-parser": {
-      "version": "6.0.10",
-      "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-6.0.10.tgz",
-      "integrity": "sha512-IQ7TZdoaqbT+LCpShg46jnZVlhWD2w6iQYAcYXfHARZ7X1t/UGhhceQDs5X0cGqKvYlHNOuv7Oa1xmb0oQuA3w==",
-      "license": "MIT",
+    "node_modules/d3-zoom": {
+      "version": "3.0.0",
+      "resolved": "https://registry.npmjs.org/d3-zoom/-/d3-zoom-3.0.0.tgz",
+      "integrity": "sha512-b8AmV3kfQaqWAuacbPuNbL6vahnOJflOhexLzMMNLga62+/nh0JzvJ0aO/5a5MVgUFGS7Hu1P9P03o3fJkDCyw==",
       "dependencies": {
-        "cssesc": "^3.0.0",
-        "util-deprecate": "^1.0.2"
-      },
-      "engines": {
-        "node": ">=4"
-      }
-    },
-    "node_modules/postcss-value-parser": {
-      "version": "4.2.0",
-      "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-4.2.0.tgz",
-      "integrity": "sha512-1NNCs6uurfkVbeXG4S8JFT9t19m45ICnif8zWLd5oPSZ50QnwMfK+H3jv408d4jw/7Bttv5axS5IiHoLaVNHeQ==",
-      "license": "MIT"
-    },
-    "node_modules/prettier": {
-      "version": "3.3.3",
-      "resolved": "https://registry.npmjs.org/prettier/-/prettier-3.3.3.tgz",
-      "integrity": "sha512-i2tDNA0O5IrMO757lfrdQZCc2jPNDVntV0m/+4whiDfWaTKfMNgR7Qz0NAeGz/nRqF4m5/6CLzbP4/liHt12Ew==",
-      "dev": true,
-      "license": "MIT",
-      "bin": {
-        "prettier": "bin/prettier.cjs"
+        "d3-dispatch": "1 - 3",
+        "d3-drag": "2 - 3",
+        "d3-interpolate": "1 - 3",
+        "d3-selection": "2 - 3",
+        "d3-transition": "2 - 3"
       },
       "engines": {
-        "node": ">=14"
-      },
-      "funding": {
-        "url": "https://github.com/prettier/prettier?sponsor=1"
+        "node": ">=12"
       }
     },
-    "node_modules/prettier-plugin-go-template": {
-      "version": "0.0.15",
-      "resolved": "https://registry.npmjs.org/prettier-plugin-go-template/-/prettier-plugin-go-template-0.0.15.tgz",
-      "integrity": "sha512-WqU92E1NokWYNZ9mLE6ijoRg6LtIGdLMePt2C7UBDjXeDH9okcRI3zRqtnWR4s5AloiqyvZ66jNBAa9tmRY5EQ==",
-      "dev": true,
-      "license": "MIT",
+    "node_modules/dagre-d3-es": {
+      "version": "7.0.14",
+      "resolved": "https://registry.npmjs.org/dagre-d3-es/-/dagre-d3-es-7.0.14.tgz",
+      "integrity": "sha512-P4rFMVq9ESWqmOgK+dlXvOtLwYg0i7u0HBGJER0LZDJT2VHIPAMZ/riPxqJceWMStH5+E61QxFra9kIS3AqdMg==",
       "dependencies": {
-        "ulid": "^2.3.0"
-      },
-      "engines": {
-        "node": ">=14.0.0"
-      },
-      "peerDependencies": {
-        "prettier": "^3.0.0"
+        "d3": "^7.9.0",
+        "lodash-es": "^4.17.21"
       }
     },
-    "node_modules/prettier-plugin-tailwindcss": {
-      "version": "0.6.8",
-      "resolved": "https://registry.npmjs.org/prettier-plugin-tailwindcss/-/prettier-plugin-tailwindcss-0.6.8.tgz",
-      "integrity": "sha512-dGu3kdm7SXPkiW4nzeWKCl3uoImdd5CTZEJGxyypEPL37Wj0HT2pLqjrvSei1nTeuQfO4PUfjeW5cTUNRLZ4sA==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=14.21.3"
-      },
-      "peerDependencies": {
-        "@ianvs/prettier-plugin-sort-imports": "*",
-        "@prettier/plugin-pug": "*",
-        "@shopify/prettier-plugin-liquid": "*",
-        "@trivago/prettier-plugin-sort-imports": "*",
-        "@zackad/prettier-plugin-twig-melody": "*",
-        "prettier": "^3.0",
-        "prettier-plugin-astro": "*",
-        "prettier-plugin-css-order": "*",
-        "prettier-plugin-import-sort": "*",
-        "prettier-plugin-jsdoc": "*",
-        "prettier-plugin-marko": "*",
-        "prettier-plugin-multiline-arrays": "*",
-        "prettier-plugin-organize-attributes": "*",
-        "prettier-plugin-organize-imports": "*",
-        "prettier-plugin-sort-imports": "*",
-        "prettier-plugin-style-order": "*",
-        "prettier-plugin-svelte": "*"
-      },
-      "peerDependenciesMeta": {
-        "@ianvs/prettier-plugin-sort-imports": {
-          "optional": true
-        },
-        "@prettier/plugin-pug": {
-          "optional": true
-        },
-        "@shopify/prettier-plugin-liquid": {
-          "optional": true
-        },
-        "@trivago/prettier-plugin-sort-imports": {
-          "optional": true
-        },
-        "@zackad/prettier-plugin-twig-melody": {
-          "optional": true
-        },
-        "prettier-plugin-astro": {
-          "optional": true
-        },
-        "prettier-plugin-css-order": {
-          "optional": true
-        },
-        "prettier-plugin-import-sort": {
-          "optional": true
-        },
-        "prettier-plugin-jsdoc": {
-          "optional": true
-        },
-        "prettier-plugin-marko": {
-          "optional": true
-        },
-        "prettier-plugin-multiline-arrays": {
-          "optional": true
-        },
-        "prettier-plugin-organize-attributes": {
-          "optional": true
-        },
-        "prettier-plugin-organize-imports": {
-          "optional": true
-        },
-        "prettier-plugin-sort-imports": {
-          "optional": true
-        },
-        "prettier-plugin-style-order": {
-          "optional": true
-        },
-        "prettier-plugin-svelte": {
-          "optional": true
-        }
-      }
+    "node_modules/dayjs": {
+      "version": "1.11.21",
+      "resolved": "https://registry.npmjs.org/dayjs/-/dayjs-1.11.21.tgz",
+      "integrity": "sha512-98IT+HOahAisibz/yjKbzuOBwYcjJ7BCLPzARyHiyEBmRz4fatF+KPJszEHXsGYjUG234aH/cOjW1wwTbKUZlA=="
     },
-    "node_modules/pretty-hrtime": {
-      "version": "1.0.3",
-      "resolved": "https://registry.npmjs.org/pretty-hrtime/-/pretty-hrtime-1.0.3.tgz",
-      "integrity": "sha512-66hKPCr+72mlfiSjlEB1+45IjXSqvVAIy6mocupoww4tBFE9R9IhwwUGoI4G++Tc9Aq+2rxOt0RFU6gPcrte0A==",
-      "license": "MIT",
-      "engines": {
-        "node": ">= 0.8"
+    "node_modules/delaunator": {
+      "version": "5.1.0",
+      "resolved": "https://registry.npmjs.org/delaunator/-/delaunator-5.1.0.tgz",
+      "integrity": "sha512-AGrQ4QSgssa1NGmWmLPqN5NY2KajF5MqxetNEO+o0n3ZwZZeTmt7bBnvzHWrmkZFxGgr4HdyFgelzgi06otLuQ==",
+      "dependencies": {
+        "robust-predicates": "^3.0.2"
       }
     },
-    "node_modules/punycode.js": {
-      "version": "2.3.1",
-      "resolved": "https://registry.npmjs.org/punycode.js/-/punycode.js-2.3.1.tgz",
-      "integrity": "sha512-uxFIHU0YlHYhDQtV4R9J6a52SLx28BCjT+4ieh7IGbgwVJWO+km431c4yRlREUAsAmt/uMjQUyQHNEPf0M39CA==",
-      "dev": true,
-      "license": "MIT",
+    "node_modules/detect-libc": {
+      "version": "1.0.3",
+      "resolved": "https://registry.npmjs.org/detect-libc/-/detect-libc-1.0.3.tgz",
+      "integrity": "sha512-pGjwhsmsp4kL2RTz08wcOlGN83otlqHeD/Z5T8GXZB+/YcpQ/dgo+lbU8ZsGxV0HIvqqxo9l7mqYwyYMD9bKDg==",
+      "license": "Apache-2.0",
+      "bin": {
+        "detect-libc": "bin/detect-libc.js"
+      },
       "engines": {
-        "node": ">=6"
+        "node": ">=0.10"
       }
     },
-    "node_modules/queue-microtask": {
-      "version": "1.2.3",
-      "resolved": "https://registry.npmjs.org/queue-microtask/-/queue-microtask-1.2.3.tgz",
-      "integrity": "sha512-NuaNSa6flKT5JaSYQzJok04JzTL1CA6aGhv5rfLW3PgqA+M2ChpZQnAC8h8i4ZFkBS8X5RqkDBHA7r4hej3K9A==",
-      "funding": [
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/feross"
-        },
-        {
-          "type": "patreon",
-          "url": "https://www.patreon.com/feross"
-        },
-        {
-          "type": "consulting",
-          "url": "https://feross.org/support"
-        }
-      ],
-      "license": "MIT"
-    },
-    "node_modules/read-cache": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/read-cache/-/read-cache-1.0.0.tgz",
-      "integrity": "sha512-Owdv/Ft7IjOgm/i0xvNDZ1LrRANRfew4b2prF3OWMQLxLfu3bS8FVhCsrSCMK4lR56Y9ya+AThoTpDCTxCmpRA==",
-      "license": "MIT",
-      "dependencies": {
-        "pify": "^2.3.0"
+    "node_modules/dompurify": {
+      "version": "3.4.6",
+      "resolved": "https://registry.npmjs.org/dompurify/-/dompurify-3.4.6.tgz",
+      "integrity": "sha512-+7gzEI8trIIQkVCvQ3ucGtNfH3nOmDgVTzc62rAAOlMxLth78pwpPoZCPc7CyRzAQF89MqcfPdEWkDwnjgqktg==",
+      "optionalDependencies": {
+        "@types/trusted-types": "^2.0.7"
       }
     },
-    "node_modules/readdirp": {
-      "version": "3.6.0",
-      "resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.6.0.tgz",
-      "integrity": "sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==",
+    "node_modules/enhanced-resolve": {
+      "version": "5.20.1",
+      "resolved": "https://registry.npmjs.org/enhanced-resolve/-/enhanced-resolve-5.20.1.tgz",
+      "integrity": "sha512-Qohcme7V1inbAfvjItgw0EaxVX5q2rdVEZHRBrEQdRZTssLDGsL8Lwrznl8oQ/6kuTJONLaDcGjkNP247XEhcA==",
       "license": "MIT",
       "dependencies": {
-        "picomatch": "^2.2.1"
+        "graceful-fs": "^4.2.4",
+        "tapable": "^2.3.0"
       },
       "engines": {
-        "node": ">=8.10.0"
+        "node": ">=10.13.0"
       }
     },
-    "node_modules/require-directory": {
-      "version": "2.1.1",
-      "resolved": "https://registry.npmjs.org/require-directory/-/require-directory-2.1.1.tgz",
-      "integrity": "sha512-fGxEI7+wsG9xrvdjsrlmL22OMTTiHRwAMroiEeMgq8gzoLC/PQr7RsRDSTLUg/bZAZtF+TVIkHc6/4RIKrui+Q==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.10.0"
-      }
+    "node_modules/es-toolkit": {
+      "version": "1.47.0",
+      "resolved": "https://registry.npmjs.org/es-toolkit/-/es-toolkit-1.47.0.tgz",
+      "integrity": "sha512-n1GuoD0WEQZMBk5tttoZSqwgyLx01oqa5XsBmCHwPyNe1S9jPBEmtR2pSgp2kJuWE3ciFZ6yRHmY4pM4C3OOkw=="
     },
-    "node_modules/resolve": {
-      "version": "1.22.8",
-      "resolved": "https://registry.npmjs.org/resolve/-/resolve-1.22.8.tgz",
-      "integrity": "sha512-oKWePCxqpd6FlLvGV1VU0x7bkPmmCNolxzjMf4NczoDnQcIWrAF+cPtZn5i6n+RfD2d9i0tzpKnG6Yk168yIyw==",
+    "node_modules/fill-range": {
+      "version": "7.1.1",
+      "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
+      "integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
       "license": "MIT",
       "dependencies": {
-        "is-core-module": "^2.13.0",
-        "path-parse": "^1.0.7",
-        "supports-preserve-symlinks-flag": "^1.0.0"
-      },
-      "bin": {
-        "resolve": "bin/resolve"
+        "to-regex-range": "^5.0.1"
       },
-      "funding": {
-        "url": "https://github.com/sponsors/ljharb"
-      }
-    },
-    "node_modules/reusify": {
-      "version": "1.0.4",
-      "resolved": "https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz",
-      "integrity": "sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==",
-      "license": "MIT",
       "engines": {
-        "iojs": ">=1.0.0",
-        "node": ">=0.10.0"
+        "node": ">=8"
       }
     },
-    "node_modules/run-parallel": {
-      "version": "1.2.0",
-      "resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.2.0.tgz",
-      "integrity": "sha512-5l4VyZR86LZ/lDxZTR6jqL8AFE2S0IFLMP26AbjsLVADxHdhB/c0GUsH+y39UfCi3dzz8OlQuPmnaJOMoDHQBA==",
-      "funding": [
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/feross"
-        },
-        {
-          "type": "patreon",
-          "url": "https://www.patreon.com/feross"
-        },
-        {
-          "type": "consulting",
-          "url": "https://feross.org/support"
-        }
-      ],
+    "node_modules/focus-trap": {
+      "version": "6.9.4",
+      "resolved": "https://registry.npmjs.org/focus-trap/-/focus-trap-6.9.4.tgz",
+      "integrity": "sha512-v2NTsZe2FF59Y+sDykKY+XjqZ0cPfhq/hikWVL88BqLivnNiEffAsac6rP6H45ff9wG9LL5ToiDqrLEP9GX9mw==",
       "license": "MIT",
       "dependencies": {
-        "queue-microtask": "^1.2.2"
+        "tabbable": "^5.3.3"
       }
     },
-    "node_modules/shebang-command": {
-      "version": "2.0.0",
-      "resolved": "https://registry.npmjs.org/shebang-command/-/shebang-command-2.0.0.tgz",
-      "integrity": "sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==",
-      "license": "MIT",
-      "dependencies": {
-        "shebang-regex": "^3.0.0"
-      },
+    "node_modules/graceful-fs": {
+      "version": "4.2.11",
+      "resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.11.tgz",
+      "integrity": "sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==",
+      "license": "ISC"
+    },
+    "node_modules/hachure-fill": {
+      "version": "0.5.2",
+      "resolved": "https://registry.npmjs.org/hachure-fill/-/hachure-fill-0.5.2.tgz",
+      "integrity": "sha512-3GKBOn+m2LX9iq+JC1064cSFprJY4jL1jCXTcpnfER5HYE2l/4EfWSGzkPa/ZDBmYI0ZOEj5VHV/eKnPGkHuOg=="
+    },
+    "node_modules/heroicons": {
+      "version": "2.2.0",
+      "resolved": "https://registry.npmjs.org/heroicons/-/heroicons-2.2.0.tgz",
+      "integrity": "sha512-yOwvztmNiBWqR946t+JdgZmyzEmnRMC2nxvHFC90bF1SUttwB6yJKYeme1JeEcBfobdOs827nCyiWBS2z/brog=="
+    },
+    "node_modules/highlight.js": {
+      "version": "11.11.1",
+      "resolved": "https://registry.npmjs.org/highlight.js/-/highlight.js-11.11.1.tgz",
+      "integrity": "sha512-Xwwo44whKBVCYoliBQwaPvtd/2tYFkRQtXDWj1nackaV2JPXx3L0+Jvd8/qCJ2p+ML0/XVkJ2q+Mr+UVdpJK5w==",
+      "license": "BSD-3-Clause",
       "engines": {
-        "node": ">=8"
+        "node": ">=12.0.0"
       }
     },
-    "node_modules/shebang-regex": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/shebang-regex/-/shebang-regex-3.0.0.tgz",
-      "integrity": "sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==",
-      "license": "MIT",
+    "node_modules/iconv-lite": {
+      "version": "0.6.3",
+      "resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.6.3.tgz",
+      "integrity": "sha512-4fCk79wshMdzMp2rH06qWrJE4iolqLhCUH+OiuIgU++RB0+94NlDL81atO7GX55uUKueo0txHNtvEyI6D7WdMw==",
+      "dependencies": {
+        "safer-buffer": ">= 2.1.2 < 3.0.0"
+      },
       "engines": {
-        "node": ">=8"
+        "node": ">=0.10.0"
       }
     },
-    "node_modules/signal-exit": {
-      "version": "4.1.0",
-      "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-4.1.0.tgz",
-      "integrity": "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw==",
-      "license": "ISC",
-      "engines": {
-        "node": ">=14"
-      },
+    "node_modules/idb": {
+      "version": "8.0.3",
+      "resolved": "https://registry.npmjs.org/idb/-/idb-8.0.3.tgz",
+      "integrity": "sha512-LtwtVyVYO5BqRvcsKuB2iUMnHwPVByPCXFXOpuU96IZPPoPN6xjOGxZQ74pgSVVLQWtUOYgyeL4GE98BY5D3wg=="
+    },
+    "node_modules/import-meta-resolve": {
+      "version": "4.2.0",
+      "resolved": "https://registry.npmjs.org/import-meta-resolve/-/import-meta-resolve-4.2.0.tgz",
+      "integrity": "sha512-Iqv2fzaTQN28s/FwZAoFq0ZSs/7hMAHJVX+w8PZl3cY19Pxk6jFFalxQoIfW2826i/fDLXv8IiEZRIT0lDuWcg==",
       "funding": {
-        "url": "https://github.com/sponsors/isaacs"
+        "type": "github",
+        "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/slash": {
-      "version": "5.1.0",
-      "resolved": "https://registry.npmjs.org/slash/-/slash-5.1.0.tgz",
-      "integrity": "sha512-ZA6oR3T/pEyuqwMgAKT0/hAv8oAXckzbkmR0UkUosQ+Mc4RxGoJkRmwHgHufaenlyAgE1Mxgpdcrf75y6XcnDg==",
-      "license": "MIT",
+    "node_modules/internmap": {
+      "version": "2.0.3",
+      "resolved": "https://registry.npmjs.org/internmap/-/internmap-2.0.3.tgz",
+      "integrity": "sha512-5Hh7Y1wQbvY5ooGgPbDaL5iYLAPzMTUrjMulskHLH6wnv/A+1q5rgEaiuqEjB+oxGXIVZs1FF+R/KPN3ZSQYYg==",
       "engines": {
-        "node": ">=14.16"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
+        "node": ">=12"
       }
     },
-    "node_modules/source-map-js": {
-      "version": "1.2.1",
-      "resolved": "https://registry.npmjs.org/source-map-js/-/source-map-js-1.2.1.tgz",
-      "integrity": "sha512-UXWMKhLOwVKb728IUtQPXxfYU+usdybtUrK/8uGE8CQMvrhOpwvzDBwj0QhSL7MQc7vIsISBG8VQ8+IDQxpfQA==",
-      "license": "BSD-3-Clause",
+    "node_modules/is-extglob": {
+      "version": "2.1.1",
+      "resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz",
+      "integrity": "sha512-SbKbANkN603Vi4jEZv49LeVJMn4yGwsbzZworEoyEiutsN3nJYdbO36zfhGJ6QEDpOZIFkDtnq5JRxmvl3jsoQ==",
+      "license": "MIT",
       "engines": {
         "node": ">=0.10.0"
       }
     },
-    "node_modules/string-width": {
-      "version": "5.1.2",
-      "resolved": "https://registry.npmjs.org/string-width/-/string-width-5.1.2.tgz",
-      "integrity": "sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==",
+    "node_modules/is-glob": {
+      "version": "4.0.3",
+      "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz",
+      "integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==",
       "license": "MIT",
       "dependencies": {
-        "eastasianwidth": "^0.2.0",
-        "emoji-regex": "^9.2.2",
-        "strip-ansi": "^7.0.1"
+        "is-extglob": "^2.1.1"
       },
       "engines": {
-        "node": ">=12"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
+        "node": ">=0.10.0"
       }
     },
-    "node_modules/string-width-cjs": {
-      "name": "string-width",
-      "version": "4.2.3",
-      "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
-      "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
+    "node_modules/is-number": {
+      "version": "7.0.0",
+      "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
+      "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==",
       "license": "MIT",
-      "dependencies": {
-        "emoji-regex": "^8.0.0",
-        "is-fullwidth-code-point": "^3.0.0",
-        "strip-ansi": "^6.0.1"
-      },
       "engines": {
-        "node": ">=8"
+        "node": ">=0.12.0"
       }
     },
-    "node_modules/string-width-cjs/node_modules/ansi-regex": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
-      "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
+    "node_modules/jiti": {
+      "version": "2.6.1",
+      "resolved": "https://registry.npmjs.org/jiti/-/jiti-2.6.1.tgz",
+      "integrity": "sha512-ekilCSN1jwRvIbgeg/57YFh8qQDNbwDb9xT/qu2DAHbFFZUicIl4ygVaAvzveMhMVr3LnpSKTNnwt8PoOfmKhQ==",
       "license": "MIT",
-      "engines": {
-        "node": ">=8"
+      "bin": {
+        "jiti": "lib/jiti-cli.mjs"
       }
     },
-    "node_modules/string-width-cjs/node_modules/emoji-regex": {
-      "version": "8.0.0",
-      "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz",
-      "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==",
-      "license": "MIT"
-    },
-    "node_modules/string-width-cjs/node_modules/strip-ansi": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
-      "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
+    "node_modules/katex": {
+      "version": "0.16.25",
+      "resolved": "https://registry.npmjs.org/katex/-/katex-0.16.25.tgz",
+      "integrity": "sha512-woHRUZ/iF23GBP1dkDQMh1QBad9dmr8/PAwNA54VrSOVYgI12MAcE14TqnDdQOdzyEonGzMepYnqBMYdsoAr8Q==",
+      "funding": [
+        "https://opencollective.com/katex",
+        "https://github.com/sponsors/katex"
+      ],
       "license": "MIT",
       "dependencies": {
-        "ansi-regex": "^5.0.1"
+        "commander": "^8.3.0"
       },
-      "engines": {
-        "node": ">=8"
+      "bin": {
+        "katex": "cli.js"
       }
     },
-    "node_modules/strip-ansi": {
-      "version": "7.1.0",
-      "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz",
-      "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==",
-      "license": "MIT",
+    "node_modules/khroma": {
+      "version": "2.1.0",
+      "resolved": "https://registry.npmjs.org/khroma/-/khroma-2.1.0.tgz",
+      "integrity": "sha512-Ls993zuzfayK269Svk9hzpeGUKob/sIgZzyHYdjQoAdQetRKpOLj+k/QQQ/6Qi0Yz65mlROrfd+Ev+1+7dz9Kw=="
+    },
+    "node_modules/layout-base": {
+      "version": "1.0.2",
+      "resolved": "https://registry.npmjs.org/layout-base/-/layout-base-1.0.2.tgz",
+      "integrity": "sha512-8h2oVEZNktL4BH2JCOI90iD1yXwL6iNW7KcCKT2QZgQJR2vbqDsldCTPRU9NifTCqHZci57XvQQ15YTu+sTYPg=="
+    },
+    "node_modules/lightningcss": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss/-/lightningcss-1.31.1.tgz",
+      "integrity": "sha512-l51N2r93WmGUye3WuFoN5k10zyvrVs0qfKBhyC5ogUQ6Ew6JUSswh78mbSO+IU3nTWsyOArqPCcShdQSadghBQ==",
+      "license": "MPL-2.0",
       "dependencies": {
-        "ansi-regex": "^6.0.1"
+        "detect-libc": "^2.0.3"
       },
       "engines": {
-        "node": ">=12"
+        "node": ">= 12.0.0"
       },
       "funding": {
-        "url": "https://github.com/chalk/strip-ansi?sponsor=1"
-      }
-    },
-    "node_modules/strip-ansi-cjs": {
-      "name": "strip-ansi",
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
-      "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
-      "license": "MIT",
-      "dependencies": {
-        "ansi-regex": "^5.0.1"
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       },
+      "optionalDependencies": {
+        "lightningcss-android-arm64": "1.31.1",
+        "lightningcss-darwin-arm64": "1.31.1",
+        "lightningcss-darwin-x64": "1.31.1",
+        "lightningcss-freebsd-x64": "1.31.1",
+        "lightningcss-linux-arm-gnueabihf": "1.31.1",
+        "lightningcss-linux-arm64-gnu": "1.31.1",
+        "lightningcss-linux-arm64-musl": "1.31.1",
+        "lightningcss-linux-x64-gnu": "1.31.1",
+        "lightningcss-linux-x64-musl": "1.31.1",
+        "lightningcss-win32-arm64-msvc": "1.31.1",
+        "lightningcss-win32-x64-msvc": "1.31.1"
+      }
+    },
+    "node_modules/lightningcss-android-arm64": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss-android-arm64/-/lightningcss-android-arm64-1.31.1.tgz",
+      "integrity": "sha512-HXJF3x8w9nQ4jbXRiNppBCqeZPIAfUo8zE/kOEGbW5NZvGc/K7nMxbhIr+YlFlHW5mpbg/YFPdbnCh1wAXCKFg==",
+      "cpu": [
+        "arm64"
+      ],
+      "license": "MPL-2.0",
+      "optional": true,
+      "os": [
+        "android"
+      ],
       "engines": {
-        "node": ">=8"
+        "node": ">= 12.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/strip-ansi-cjs/node_modules/ansi-regex": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
-      "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
-      "license": "MIT",
+    "node_modules/lightningcss-darwin-arm64": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss-darwin-arm64/-/lightningcss-darwin-arm64-1.31.1.tgz",
+      "integrity": "sha512-02uTEqf3vIfNMq3h/z2cJfcOXnQ0GRwQrkmPafhueLb2h7mqEidiCzkE4gBMEH65abHRiQvhdcQ+aP0D0g67sg==",
+      "cpu": [
+        "arm64"
+      ],
+      "license": "MPL-2.0",
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
       "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/sucrase": {
-      "version": "3.35.0",
-      "resolved": "https://registry.npmjs.org/sucrase/-/sucrase-3.35.0.tgz",
-      "integrity": "sha512-8EbVDiu9iN/nESwxeSxDKe0dunta1GOlHufmSSXxMD2z2/tMZpDMpvXQGsc+ajGo8y2uYUmixaSRUc/QPoQ0GA==",
-      "license": "MIT",
-      "dependencies": {
-        "@jridgewell/gen-mapping": "^0.3.2",
-        "commander": "^4.0.0",
-        "glob": "^10.3.10",
-        "lines-and-columns": "^1.1.6",
-        "mz": "^2.7.0",
-        "pirates": "^4.0.1",
-        "ts-interface-checker": "^0.1.9"
+        "node": ">= 12.0.0"
       },
-      "bin": {
-        "sucrase": "bin/sucrase",
-        "sucrase-node": "bin/sucrase-node"
-      },
-      "engines": {
-        "node": ">=16 || 14 >=14.17"
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/supports-preserve-symlinks-flag": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/supports-preserve-symlinks-flag/-/supports-preserve-symlinks-flag-1.0.0.tgz",
-      "integrity": "sha512-ot0WnXS9fgdkgIcePe6RHNk1WA8+muPa6cSjeR3V8K27q9BB1rTE3R1p7Hv0z1ZyAc8s6Vvv8DIyWf681MAt0w==",
-      "license": "MIT",
+    "node_modules/lightningcss-darwin-x64": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss-darwin-x64/-/lightningcss-darwin-x64-1.31.1.tgz",
+      "integrity": "sha512-1ObhyoCY+tGxtsz1lSx5NXCj3nirk0Y0kB/g8B8DT+sSx4G9djitg9ejFnjb3gJNWo7qXH4DIy2SUHvpoFwfTA==",
+      "cpu": [
+        "x64"
+      ],
+      "license": "MPL-2.0",
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
       "engines": {
-        "node": ">= 0.4"
+        "node": ">= 12.0.0"
       },
       "funding": {
-        "url": "https://github.com/sponsors/ljharb"
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/tabbable": {
-      "version": "5.3.3",
-      "resolved": "https://registry.npmjs.org/tabbable/-/tabbable-5.3.3.tgz",
-      "integrity": "sha512-QD9qKY3StfbZqWOPLp0++pOrAVb/HbUi5xCc8cUo4XjP19808oaMiDzn0leBY5mCespIBM0CIZePzZjgzR83kA==",
-      "license": "MIT"
-    },
-    "node_modules/tailwindcss": {
-      "version": "3.4.15",
-      "resolved": "https://registry.npmjs.org/tailwindcss/-/tailwindcss-3.4.15.tgz",
-      "integrity": "sha512-r4MeXnfBmSOuKUWmXe6h2CcyfzJCEk4F0pptO5jlnYSIViUkVmsawj80N5h2lO3gwcmSb4n3PuN+e+GC1Guylw==",
-      "license": "MIT",
-      "dependencies": {
-        "@alloc/quick-lru": "^5.2.0",
-        "arg": "^5.0.2",
-        "chokidar": "^3.6.0",
-        "didyoumean": "^1.2.2",
-        "dlv": "^1.1.3",
-        "fast-glob": "^3.3.2",
-        "glob-parent": "^6.0.2",
-        "is-glob": "^4.0.3",
-        "jiti": "^1.21.6",
-        "lilconfig": "^2.1.0",
-        "micromatch": "^4.0.8",
-        "normalize-path": "^3.0.0",
-        "object-hash": "^3.0.0",
-        "picocolors": "^1.1.1",
-        "postcss": "^8.4.47",
-        "postcss-import": "^15.1.0",
-        "postcss-js": "^4.0.1",
-        "postcss-load-config": "^4.0.2",
-        "postcss-nested": "^6.2.0",
-        "postcss-selector-parser": "^6.1.2",
-        "resolve": "^1.22.8",
-        "sucrase": "^3.35.0"
-      },
-      "bin": {
-        "tailwind": "lib/cli.js",
-        "tailwindcss": "lib/cli.js"
-      },
+    "node_modules/lightningcss-freebsd-x64": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss-freebsd-x64/-/lightningcss-freebsd-x64-1.31.1.tgz",
+      "integrity": "sha512-1RINmQKAItO6ISxYgPwszQE1BrsVU5aB45ho6O42mu96UiZBxEXsuQ7cJW4zs4CEodPUioj/QrXW1r9pLUM74A==",
+      "cpu": [
+        "x64"
+      ],
+      "license": "MPL-2.0",
+      "optional": true,
+      "os": [
+        "freebsd"
+      ],
       "engines": {
-        "node": ">=14.0.0"
+        "node": ">= 12.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/tailwindcss/node_modules/glob-parent": {
-      "version": "6.0.2",
-      "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-6.0.2.tgz",
-      "integrity": "sha512-XxwI8EOhVQgWp6iDL+3b0r86f4d6AX6zSU55HfB4ydCEuXLXc5FcYeOu+nnGftS4TEju/11rt4KJPTMgbfmv4A==",
-      "license": "ISC",
-      "dependencies": {
-        "is-glob": "^4.0.3"
-      },
+    "node_modules/lightningcss-linux-arm-gnueabihf": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss-linux-arm-gnueabihf/-/lightningcss-linux-arm-gnueabihf-1.31.1.tgz",
+      "integrity": "sha512-OOCm2//MZJ87CdDK62rZIu+aw9gBv4azMJuA8/KB74wmfS3lnC4yoPHm0uXZ/dvNNHmnZnB8XLAZzObeG0nS1g==",
+      "cpu": [
+        "arm"
+      ],
+      "license": "MPL-2.0",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">=10.13.0"
+        "node": ">= 12.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/tailwindcss/node_modules/lilconfig": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/lilconfig/-/lilconfig-2.1.0.tgz",
-      "integrity": "sha512-utWOt/GHzuUxnLKxB6dk81RoOeoNeHgbrXiuGk4yyF5qlRz+iIVWu56E2fqGHFrXz0QNUhLB/8nKqvRH66JKGQ==",
-      "license": "MIT",
+    "node_modules/lightningcss-linux-arm64-gnu": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss-linux-arm64-gnu/-/lightningcss-linux-arm64-gnu-1.31.1.tgz",
+      "integrity": "sha512-WKyLWztD71rTnou4xAD5kQT+982wvca7E6QoLpoawZ1gP9JM0GJj4Tp5jMUh9B3AitHbRZ2/H3W5xQmdEOUlLg==",
+      "cpu": [
+        "arm64"
+      ],
+      "license": "MPL-2.0",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">=10"
+        "node": ">= 12.0.0"
+      },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/tailwindcss/node_modules/postcss-import": {
-      "version": "15.1.0",
-      "resolved": "https://registry.npmjs.org/postcss-import/-/postcss-import-15.1.0.tgz",
-      "integrity": "sha512-hpr+J05B2FVYUAXHeK1YyI267J/dDDhMU6B6civm8hSY1jYJnBXxzKDKDswzJmtLHryrjhnDjqqp/49t8FALew==",
-      "license": "MIT",
-      "dependencies": {
-        "postcss-value-parser": "^4.0.0",
-        "read-cache": "^1.0.0",
-        "resolve": "^1.1.7"
-      },
+    "node_modules/lightningcss-linux-arm64-musl": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss-linux-arm64-musl/-/lightningcss-linux-arm64-musl-1.31.1.tgz",
+      "integrity": "sha512-mVZ7Pg2zIbe3XlNbZJdjs86YViQFoJSpc41CbVmKBPiGmC4YrfeOyz65ms2qpAobVd7WQsbW4PdsSJEMymyIMg==",
+      "cpu": [
+        "arm64"
+      ],
+      "license": "MPL-2.0",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">=14.0.0"
+        "node": ">= 12.0.0"
       },
-      "peerDependencies": {
-        "postcss": "^8.0.0"
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/tailwindcss/node_modules/postcss-load-config": {
-      "version": "4.0.2",
-      "resolved": "https://registry.npmjs.org/postcss-load-config/-/postcss-load-config-4.0.2.tgz",
-      "integrity": "sha512-bSVhyJGL00wMVoPUzAVAnbEoWyqRxkjv64tUl427SKnPrENtq6hJwUojroMz2VB+Q1edmi4IfrAPpami5VVgMQ==",
-      "funding": [
-        {
-          "type": "opencollective",
-          "url": "https://opencollective.com/postcss/"
-        },
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/ai"
-        }
+    "node_modules/lightningcss-linux-x64-gnu": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss-linux-x64-gnu/-/lightningcss-linux-x64-gnu-1.31.1.tgz",
+      "integrity": "sha512-xGlFWRMl+0KvUhgySdIaReQdB4FNudfUTARn7q0hh/V67PVGCs3ADFjw+6++kG1RNd0zdGRlEKa+T13/tQjPMA==",
+      "cpu": [
+        "x64"
+      ],
+      "license": "MPL-2.0",
+      "optional": true,
+      "os": [
+        "linux"
       ],
-      "license": "MIT",
-      "dependencies": {
-        "lilconfig": "^3.0.0",
-        "yaml": "^2.3.4"
-      },
       "engines": {
-        "node": ">= 14"
-      },
-      "peerDependencies": {
-        "postcss": ">=8.0.9",
-        "ts-node": ">=9.0.0"
+        "node": ">= 12.0.0"
       },
-      "peerDependenciesMeta": {
-        "postcss": {
-          "optional": true
-        },
-        "ts-node": {
-          "optional": true
-        }
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/tailwindcss/node_modules/postcss-load-config/node_modules/lilconfig": {
-      "version": "3.1.2",
-      "resolved": "https://registry.npmjs.org/lilconfig/-/lilconfig-3.1.2.tgz",
-      "integrity": "sha512-eop+wDAvpItUys0FWkHIKeC9ybYrTGbU41U5K7+bttZZeohvnY7M9dZ5kB21GNWiFT2q1OoPTvncPCgSOVO5ow==",
-      "license": "MIT",
+    "node_modules/lightningcss-linux-x64-musl": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss-linux-x64-musl/-/lightningcss-linux-x64-musl-1.31.1.tgz",
+      "integrity": "sha512-eowF8PrKHw9LpoZii5tdZwnBcYDxRw2rRCyvAXLi34iyeYfqCQNA9rmUM0ce62NlPhCvof1+9ivRaTY6pSKDaA==",
+      "cpu": [
+        "x64"
+      ],
+      "license": "MPL-2.0",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
       "engines": {
-        "node": ">=14"
+        "node": ">= 12.0.0"
       },
       "funding": {
-        "url": "https://github.com/sponsors/antonk52"
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/tailwindcss/node_modules/postcss-nested": {
-      "version": "6.2.0",
-      "resolved": "https://registry.npmjs.org/postcss-nested/-/postcss-nested-6.2.0.tgz",
-      "integrity": "sha512-HQbt28KulC5AJzG+cZtj9kvKB93CFCdLvog1WFLf1D+xmMvPGlBstkpTEZfK5+AN9hfJocyBFCNiqyS48bpgzQ==",
-      "funding": [
-        {
-          "type": "opencollective",
-          "url": "https://opencollective.com/postcss/"
-        },
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/ai"
-        }
+    "node_modules/lightningcss-win32-arm64-msvc": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss-win32-arm64-msvc/-/lightningcss-win32-arm64-msvc-1.31.1.tgz",
+      "integrity": "sha512-aJReEbSEQzx1uBlQizAOBSjcmr9dCdL3XuC/6HLXAxmtErsj2ICo5yYggg1qOODQMtnjNQv2UHb9NpOuFtYe4w==",
+      "cpu": [
+        "arm64"
+      ],
+      "license": "MPL-2.0",
+      "optional": true,
+      "os": [
+        "win32"
       ],
-      "license": "MIT",
-      "dependencies": {
-        "postcss-selector-parser": "^6.1.1"
-      },
       "engines": {
-        "node": ">=12.0"
+        "node": ">= 12.0.0"
       },
-      "peerDependencies": {
-        "postcss": "^8.2.14"
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
       }
     },
-    "node_modules/tailwindcss/node_modules/postcss-selector-parser": {
-      "version": "6.1.2",
-      "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-6.1.2.tgz",
-      "integrity": "sha512-Q8qQfPiZ+THO/3ZrOrO0cJJKfpYCagtMUkXbnEfmgUjwXg6z/WBeOyS9APBBPCTSiDV+s4SwQGu8yFsiMRIudg==",
-      "license": "MIT",
-      "dependencies": {
-        "cssesc": "^3.0.0",
-        "util-deprecate": "^1.0.2"
+    "node_modules/lightningcss-win32-x64-msvc": {
+      "version": "1.31.1",
+      "resolved": "https://registry.npmjs.org/lightningcss-win32-x64-msvc/-/lightningcss-win32-x64-msvc-1.31.1.tgz",
+      "integrity": "sha512-I9aiFrbd7oYHwlnQDqr1Roz+fTz61oDDJX7n9tYF9FJymH1cIN1DtKw3iYt6b8WZgEjoNwVSncwF4wx/ZedMhw==",
+      "cpu": [
+        "x64"
+      ],
+      "license": "MPL-2.0",
+      "optional": true,
+      "os": [
+        "win32"
+      ],
+      "engines": {
+        "node": ">= 12.0.0"
       },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/parcel"
+      }
+    },
+    "node_modules/lightningcss/node_modules/detect-libc": {
+      "version": "2.1.2",
+      "resolved": "https://registry.npmjs.org/detect-libc/-/detect-libc-2.1.2.tgz",
+      "integrity": "sha512-Btj2BOOO83o3WyH59e8MgXsxEQVcarkUOpEYrubB0urwnN10yQ364rsiByU11nZlqWYZm05i/of7io4mzihBtQ==",
+      "license": "Apache-2.0",
       "engines": {
-        "node": ">=4"
+        "node": ">=8"
       }
     },
-    "node_modules/thenby": {
-      "version": "1.3.4",
-      "resolved": "https://registry.npmjs.org/thenby/-/thenby-1.3.4.tgz",
-      "integrity": "sha512-89Gi5raiWA3QZ4b2ePcEwswC3me9JIg+ToSgtE0JWeCynLnLxNr/f9G+xfo9K+Oj4AFdom8YNJjibIARTJmapQ==",
-      "license": "Apache-2.0"
+    "node_modules/lodash-es": {
+      "version": "4.18.1",
+      "resolved": "https://registry.npmjs.org/lodash-es/-/lodash-es-4.18.1.tgz",
+      "integrity": "sha512-J8xewKD/Gk22OZbhpOVSwcs60zhd95ESDwezOFuA3/099925PdHJ7OFHNTGtajL3AlZkykD32HykiMo+BIBI8A=="
     },
-    "node_modules/thenify": {
-      "version": "3.3.1",
-      "resolved": "https://registry.npmjs.org/thenify/-/thenify-3.3.1.tgz",
-      "integrity": "sha512-RVZSIV5IG10Hk3enotrhvz0T9em6cyHBLkH/YAZuKqd8hRkKhSfCGIcP2KUY0EPxndzANBmNllzWPwak+bheSw==",
+    "node_modules/magic-string": {
+      "version": "0.30.21",
+      "resolved": "https://registry.npmjs.org/magic-string/-/magic-string-0.30.21.tgz",
+      "integrity": "sha512-vd2F4YUyEXKGcLHoq+TEyCjxueSeHnFxyyjNp80yg0XV4vUhnDer/lvvlqM/arB5bXQN5K2/3oinyCRyx8T2CQ==",
       "license": "MIT",
       "dependencies": {
-        "any-promise": "^1.0.0"
+        "@jridgewell/sourcemap-codec": "^1.5.5"
       }
     },
-    "node_modules/thenify-all": {
-      "version": "1.6.0",
-      "resolved": "https://registry.npmjs.org/thenify-all/-/thenify-all-1.6.0.tgz",
-      "integrity": "sha512-RNxQH/qI8/t3thXJDwcstUO4zeqo64+Uy/+sNVRBx4Xn2OX+OZ9oP+iJnNFqplFra2ZUVeKCSa2oVWi3T4uVmA==",
+    "node_modules/marked": {
+      "version": "17.0.4",
+      "resolved": "https://registry.npmjs.org/marked/-/marked-17.0.4.tgz",
+      "integrity": "sha512-NOmVMM+KAokHMvjWmC5N/ZOvgmSWuqJB8FoYI019j4ogb/PeRMKoKIjReZ2w3376kkA8dSJIP8uD993Kxc0iRQ==",
       "license": "MIT",
-      "dependencies": {
-        "thenify": ">= 3.1.0 < 4"
+      "bin": {
+        "marked": "bin/marked.js"
+      },
+      "engines": {
+        "node": ">= 20"
+      }
+    },
+    "node_modules/mermaid": {
+      "version": "11.15.0",
+      "resolved": "https://registry.npmjs.org/mermaid/-/mermaid-11.15.0.tgz",
+      "integrity": "sha512-pTMbcf3rWdtLiYGpmoTjHEpeY8seiy6sR+9nD7LOs8KfUbHE4lOUAprTRqRAcWSQ6MQpdX+YEsxShtGsINtPtw==",
+      "dependencies": {
+        "@braintree/sanitize-url": "^7.1.1",
+        "@iconify/utils": "^3.0.2",
+        "@mermaid-js/parser": "^1.1.1",
+        "@types/d3": "^7.4.3",
+        "@upsetjs/venn.js": "^2.0.0",
+        "cytoscape": "^3.33.1",
+        "cytoscape-cose-bilkent": "^4.1.0",
+        "cytoscape-fcose": "^2.2.0",
+        "d3": "^7.9.0",
+        "d3-sankey": "^0.12.3",
+        "dagre-d3-es": "7.0.14",
+        "dayjs": "^1.11.19",
+        "dompurify": "^3.3.1",
+        "es-toolkit": "^1.45.1",
+        "katex": "^0.16.25",
+        "khroma": "^2.1.0",
+        "marked": "^16.3.0",
+        "roughjs": "^4.6.6",
+        "stylis": "^4.3.6",
+        "ts-dedent": "^2.2.0",
+        "uuid": "^11.1.0 || ^12 || ^13 || ^14.0.0"
+      }
+    },
+    "node_modules/mermaid/node_modules/marked": {
+      "version": "16.4.2",
+      "resolved": "https://registry.npmjs.org/marked/-/marked-16.4.2.tgz",
+      "integrity": "sha512-TI3V8YYWvkVf3KJe1dRkpnjs68JUPyEa5vjKrp1XEEJUAOaQc+Qj+L1qWbPd0SJuAdQkFU0h73sXXqwDYxsiDA==",
+      "bin": {
+        "marked": "bin/marked.js"
       },
       "engines": {
-        "node": ">=0.8"
+        "node": ">= 20"
       }
     },
-    "node_modules/to-regex-range": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
-      "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
+    "node_modules/micromatch": {
+      "version": "4.0.8",
+      "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.8.tgz",
+      "integrity": "sha512-PXwfBhYu0hBCPw8Dn0E+WDYb7af3dSLVWKi3HGv84IdF4TyFoC0ysxFd0Goxw7nSv4T/PzEJQxsYsEiFCKo2BA==",
       "license": "MIT",
       "dependencies": {
-        "is-number": "^7.0.0"
+        "braces": "^3.0.3",
+        "picomatch": "^2.3.1"
       },
       "engines": {
-        "node": ">=8.0"
+        "node": ">=8.6"
       }
     },
-    "node_modules/ts-interface-checker": {
-      "version": "0.1.13",
-      "resolved": "https://registry.npmjs.org/ts-interface-checker/-/ts-interface-checker-0.1.13.tgz",
-      "integrity": "sha512-Y/arvbn+rrz3JCKl9C4kVNfTfSm2/mEp5FSz5EsZSANGPSlQrpRI5M4PKF+mJnE52jOO90PnPSc3Ur3bTQw0gA==",
-      "license": "Apache-2.0"
+    "node_modules/mri": {
+      "version": "1.2.0",
+      "resolved": "https://registry.npmjs.org/mri/-/mri-1.2.0.tgz",
+      "integrity": "sha512-tzzskb3bG8LvYGFF/mDTpq3jpI6Q9wc3LEmBaghu+DdCssd1FakN7Bc0hVNmEyGq1bq3RgfkCb3cmQLpNPOroA==",
+      "license": "MIT",
+      "engines": {
+        "node": ">=4"
+      }
     },
-    "node_modules/uc.micro": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-2.1.0.tgz",
-      "integrity": "sha512-ARDJmphmdvUk6Glw7y9DQ2bFkKBHwQHLi2lsaH6PPmz/Ka9sFOBsBluozhDltWmnv9u/cF6Rt87znRTPV+yp/A==",
-      "dev": true,
+    "node_modules/node-addon-api": {
+      "version": "7.1.1",
+      "resolved": "https://registry.npmjs.org/node-addon-api/-/node-addon-api-7.1.1.tgz",
+      "integrity": "sha512-5m3bsyrjFWE1xf7nz7YXdN4udnVtXK6/Yfgn5qnahL6bCkf2yKt4k3nuTKAtT4r3IG8JNR2ncsIMdZuAzJjHQQ==",
       "license": "MIT"
     },
-    "node_modules/ulid": {
-      "version": "2.3.0",
-      "resolved": "https://registry.npmjs.org/ulid/-/ulid-2.3.0.tgz",
-      "integrity": "sha512-keqHubrlpvT6G2wH0OEfSW4mquYRcbe/J8NMmveoQOjUqmo+hXtO+ORCpWhdbZ7k72UtY61BL7haGxW6enBnjw==",
-      "dev": true,
-      "license": "MIT",
-      "bin": {
-        "ulid": "bin/cli.js"
-      }
+    "node_modules/package-manager-detector": {
+      "version": "1.6.0",
+      "resolved": "https://registry.npmjs.org/package-manager-detector/-/package-manager-detector-1.6.0.tgz",
+      "integrity": "sha512-61A5ThoTiDG/C8s8UMZwSorAGwMJ0ERVGj2OjoW5pAalsNOg15+iQiPzrLJ4jhZ1HJzmC2PIHT2oEiH3R5fzNA=="
     },
-    "node_modules/unicorn-magic": {
+    "node_modules/path-data-parser": {
       "version": "0.1.0",
-      "resolved": "https://registry.npmjs.org/unicorn-magic/-/unicorn-magic-0.1.0.tgz",
-      "integrity": "sha512-lRfVq8fE8gz6QMBuDM6a+LO3IAzTi05H6gCVaUpir2E1Rwpo4ZUog45KpNXKC/Mn3Yb9UDuHumeFTo9iV/D9FQ==",
+      "resolved": "https://registry.npmjs.org/path-data-parser/-/path-data-parser-0.1.0.tgz",
+      "integrity": "sha512-NOnmBpt5Y2RWbuv0LMzsayp3lVylAHLPUTut412ZA3l+C4uw4ZVkQbjShYCQ8TCpUMdPapr4YjUqLYD6v68j+w=="
+    },
+    "node_modules/picocolors": {
+      "version": "1.1.1",
+      "resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.1.1.tgz",
+      "integrity": "sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==",
+      "license": "ISC"
+    },
+    "node_modules/picomatch": {
+      "version": "2.3.1",
+      "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz",
+      "integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==",
       "license": "MIT",
       "engines": {
-        "node": ">=18"
+        "node": ">=8.6"
       },
       "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
+        "url": "https://github.com/sponsors/jonschlinkert"
       }
     },
-    "node_modules/universalify": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/universalify/-/universalify-2.0.1.tgz",
-      "integrity": "sha512-gptHNQghINnc/vTGIk0SOFGFNXw7JVrlRUtConJRlvaw6DuX0wO5Jeko9sWrMBhh+PsYAZ7oXAiOnf/UKogyiw==",
-      "license": "MIT",
-      "engines": {
-        "node": ">= 10.0.0"
-      }
+    "node_modules/points-on-curve": {
+      "version": "0.2.0",
+      "resolved": "https://registry.npmjs.org/points-on-curve/-/points-on-curve-0.2.0.tgz",
+      "integrity": "sha512-0mYKnYYe9ZcqMCWhUjItv/oHjvgEsfKvnUTg8sAtnHr3GVy7rGkXCb6d5cSyqrWqL4k81b9CPg3urd+T7aop3A=="
     },
-    "node_modules/update-browserslist-db": {
-      "version": "1.1.1",
-      "resolved": "https://registry.npmjs.org/update-browserslist-db/-/update-browserslist-db-1.1.1.tgz",
-      "integrity": "sha512-R8UzCaa9Az+38REPiJ1tXlImTJXlVfgHZsglwBD/k6nj76ctsH1E3q4doGrukiLQd3sGQYu56r5+lo5r94l29A==",
-      "funding": [
-        {
-          "type": "opencollective",
-          "url": "https://opencollective.com/browserslist"
-        },
-        {
-          "type": "tidelift",
-          "url": "https://tidelift.com/funding/github/npm/browserslist"
-        },
-        {
-          "type": "github",
-          "url": "https://github.com/sponsors/ai"
-        }
-      ],
-      "license": "MIT",
+    "node_modules/points-on-path": {
+      "version": "0.2.1",
+      "resolved": "https://registry.npmjs.org/points-on-path/-/points-on-path-0.2.1.tgz",
+      "integrity": "sha512-25ClnWWuw7JbWZcgqY/gJ4FQWadKxGWk+3kR/7kD0tCaDtPPMj7oHu2ToLaVhfpnHrZzYby2w6tUA0eOIuUg8g==",
       "dependencies": {
-        "escalade": "^3.2.0",
-        "picocolors": "^1.1.0"
-      },
-      "bin": {
-        "update-browserslist-db": "cli.js"
-      },
-      "peerDependencies": {
-        "browserslist": ">= 4.21.0"
+        "path-data-parser": "0.1.0",
+        "points-on-curve": "0.2.0"
       }
     },
-    "node_modules/util-deprecate": {
-      "version": "1.0.2",
-      "resolved": "https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz",
-      "integrity": "sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw==",
-      "license": "MIT"
-    },
-    "node_modules/which": {
-      "version": "2.0.2",
-      "resolved": "https://registry.npmjs.org/which/-/which-2.0.2.tgz",
-      "integrity": "sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==",
-      "license": "ISC",
+    "node_modules/postcss-selector-parser": {
+      "version": "6.0.10",
+      "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-6.0.10.tgz",
+      "integrity": "sha512-IQ7TZdoaqbT+LCpShg46jnZVlhWD2w6iQYAcYXfHARZ7X1t/UGhhceQDs5X0cGqKvYlHNOuv7Oa1xmb0oQuA3w==",
+      "license": "MIT",
       "dependencies": {
-        "isexe": "^2.0.0"
-      },
-      "bin": {
-        "node-which": "bin/node-which"
+        "cssesc": "^3.0.0",
+        "util-deprecate": "^1.0.2"
       },
       "engines": {
-        "node": ">= 8"
+        "node": ">=4"
       }
     },
-    "node_modules/wrap-ansi": {
-      "version": "8.1.0",
-      "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-8.1.0.tgz",
-      "integrity": "sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ==",
+    "node_modules/prettier": {
+      "version": "3.8.1",
+      "resolved": "https://registry.npmjs.org/prettier/-/prettier-3.8.1.tgz",
+      "integrity": "sha512-UOnG6LftzbdaHZcKoPFtOcCKztrQ57WkHDeRD9t/PTQtmT0NHSeWWepj6pS0z/N7+08BHFDQVUrfmfMRcZwbMg==",
+      "dev": true,
       "license": "MIT",
-      "dependencies": {
-        "ansi-styles": "^6.1.0",
-        "string-width": "^5.0.1",
-        "strip-ansi": "^7.0.1"
+      "bin": {
+        "prettier": "bin/prettier.cjs"
       },
       "engines": {
-        "node": ">=12"
+        "node": ">=14"
       },
       "funding": {
-        "url": "https://github.com/chalk/wrap-ansi?sponsor=1"
+        "url": "https://github.com/prettier/prettier?sponsor=1"
       }
     },
-    "node_modules/wrap-ansi-cjs": {
-      "name": "wrap-ansi",
-      "version": "7.0.0",
-      "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz",
-      "integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==",
+    "node_modules/prettier-plugin-go-template": {
+      "version": "0.0.15",
+      "resolved": "https://registry.npmjs.org/prettier-plugin-go-template/-/prettier-plugin-go-template-0.0.15.tgz",
+      "integrity": "sha512-WqU92E1NokWYNZ9mLE6ijoRg6LtIGdLMePt2C7UBDjXeDH9okcRI3zRqtnWR4s5AloiqyvZ66jNBAa9tmRY5EQ==",
+      "dev": true,
       "license": "MIT",
       "dependencies": {
-        "ansi-styles": "^4.0.0",
-        "string-width": "^4.1.0",
-        "strip-ansi": "^6.0.0"
+        "ulid": "^2.3.0"
       },
       "engines": {
-        "node": ">=10"
+        "node": ">=14.0.0"
       },
-      "funding": {
-        "url": "https://github.com/chalk/wrap-ansi?sponsor=1"
+      "peerDependencies": {
+        "prettier": "^3.0.0"
       }
     },
-    "node_modules/wrap-ansi-cjs/node_modules/ansi-regex": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
-      "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
+    "node_modules/prettier-plugin-tailwindcss": {
+      "version": "0.7.2",
+      "resolved": "https://registry.npmjs.org/prettier-plugin-tailwindcss/-/prettier-plugin-tailwindcss-0.7.2.tgz",
+      "integrity": "sha512-LkphyK3Fw+q2HdMOoiEHWf93fNtYJwfamoKPl7UwtjFQdei/iIBoX11G6j706FzN3ymX9mPVi97qIY8328vdnA==",
+      "dev": true,
       "license": "MIT",
       "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/wrap-ansi-cjs/node_modules/ansi-styles": {
-      "version": "4.3.0",
-      "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz",
-      "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==",
-      "license": "MIT",
-      "dependencies": {
-        "color-convert": "^2.0.1"
+        "node": ">=20.19"
       },
-      "engines": {
-        "node": ">=8"
+      "peerDependencies": {
+        "@ianvs/prettier-plugin-sort-imports": "*",
+        "@prettier/plugin-hermes": "*",
+        "@prettier/plugin-oxc": "*",
+        "@prettier/plugin-pug": "*",
+        "@shopify/prettier-plugin-liquid": "*",
+        "@trivago/prettier-plugin-sort-imports": "*",
+        "@zackad/prettier-plugin-twig": "*",
+        "prettier": "^3.0",
+        "prettier-plugin-astro": "*",
+        "prettier-plugin-css-order": "*",
+        "prettier-plugin-jsdoc": "*",
+        "prettier-plugin-marko": "*",
+        "prettier-plugin-multiline-arrays": "*",
+        "prettier-plugin-organize-attributes": "*",
+        "prettier-plugin-organize-imports": "*",
+        "prettier-plugin-sort-imports": "*",
+        "prettier-plugin-svelte": "*"
       },
-      "funding": {
-        "url": "https://github.com/chalk/ansi-styles?sponsor=1"
+      "peerDependenciesMeta": {
+        "@ianvs/prettier-plugin-sort-imports": {
+          "optional": true
+        },
+        "@prettier/plugin-hermes": {
+          "optional": true
+        },
+        "@prettier/plugin-oxc": {
+          "optional": true
+        },
+        "@prettier/plugin-pug": {
+          "optional": true
+        },
+        "@shopify/prettier-plugin-liquid": {
+          "optional": true
+        },
+        "@trivago/prettier-plugin-sort-imports": {
+          "optional": true
+        },
+        "@zackad/prettier-plugin-twig": {
+          "optional": true
+        },
+        "prettier-plugin-astro": {
+          "optional": true
+        },
+        "prettier-plugin-css-order": {
+          "optional": true
+        },
+        "prettier-plugin-jsdoc": {
+          "optional": true
+        },
+        "prettier-plugin-marko": {
+          "optional": true
+        },
+        "prettier-plugin-multiline-arrays": {
+          "optional": true
+        },
+        "prettier-plugin-organize-attributes": {
+          "optional": true
+        },
+        "prettier-plugin-organize-imports": {
+          "optional": true
+        },
+        "prettier-plugin-sort-imports": {
+          "optional": true
+        },
+        "prettier-plugin-svelte": {
+          "optional": true
+        }
       }
     },
-    "node_modules/wrap-ansi-cjs/node_modules/emoji-regex": {
-      "version": "8.0.0",
-      "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz",
-      "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==",
-      "license": "MIT"
+    "node_modules/robust-predicates": {
+      "version": "3.0.3",
+      "resolved": "https://registry.npmjs.org/robust-predicates/-/robust-predicates-3.0.3.tgz",
+      "integrity": "sha512-NS3levdsRIUOmiJ8FZWCP7LG3QpJyrs/TE0Zpf1yvZu8cAJJ6QMW92H1c7kWpdIHo8RvmLxN/o2JXTKHp74lUA=="
     },
-    "node_modules/wrap-ansi-cjs/node_modules/string-width": {
-      "version": "4.2.3",
-      "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
-      "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
-      "license": "MIT",
+    "node_modules/roughjs": {
+      "version": "4.6.6",
+      "resolved": "https://registry.npmjs.org/roughjs/-/roughjs-4.6.6.tgz",
+      "integrity": "sha512-ZUz/69+SYpFN/g/lUlo2FXcIjRkSu3nDarreVdGGndHEBJ6cXPdKguS8JGxwj5HA5xIbVKSmLgr5b3AWxtRfvQ==",
       "dependencies": {
-        "emoji-regex": "^8.0.0",
-        "is-fullwidth-code-point": "^3.0.0",
-        "strip-ansi": "^6.0.1"
-      },
-      "engines": {
-        "node": ">=8"
+        "hachure-fill": "^0.5.2",
+        "path-data-parser": "^0.1.0",
+        "points-on-curve": "^0.2.0",
+        "points-on-path": "^0.2.1"
       }
     },
-    "node_modules/wrap-ansi-cjs/node_modules/strip-ansi": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
-      "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
-      "license": "MIT",
-      "dependencies": {
-        "ansi-regex": "^5.0.1"
+    "node_modules/rumdl": {
+      "version": "0.2.49",
+      "resolved": "https://registry.npmjs.org/rumdl/-/rumdl-0.2.49.tgz",
+      "integrity": "sha512-pV6Ks5jr/wu4s7rBCaY5HJek3ZhG7W2knznRAhiw8AFc1DGgyuceirdH5S0k3XpSc6Ee92Ex4fyRTrZsHMIyHA==",
+      "dev": true,
+      "bin": {
+        "rumdl": "bin/rumdl"
       },
       "engines": {
-        "node": ">=8"
+        "node": ">=18.0.0"
+      },
+      "optionalDependencies": {
+        "@rumdl/cli-darwin-arm64": "0.2.49",
+        "@rumdl/cli-darwin-x64": "0.2.49",
+        "@rumdl/cli-linux-arm64": "0.2.49",
+        "@rumdl/cli-linux-arm64-musl": "0.2.49",
+        "@rumdl/cli-linux-x64": "0.2.49",
+        "@rumdl/cli-linux-x64-musl": "0.2.49",
+        "@rumdl/cli-win32-x64": "0.2.49"
       }
     },
-    "node_modules/y18n": {
-      "version": "5.0.8",
-      "resolved": "https://registry.npmjs.org/y18n/-/y18n-5.0.8.tgz",
-      "integrity": "sha512-0pfFzegeDWJHJIAmTLRP2DwHjdF5s7jo9tuztdQxAhINCdvS+3nGINqPd00AphqJR/0LhANUS6/+7SCb98YOfA==",
-      "license": "ISC",
+    "node_modules/rw": {
+      "version": "1.3.3",
+      "resolved": "https://registry.npmjs.org/rw/-/rw-1.3.3.tgz",
+      "integrity": "sha512-PdhdWy89SiZogBLaw42zdeqtRJ//zFd2PgQavcICDUgJT5oW10QCRKbJ6bg4r0/UY2M6BWd5tkxuGFRvCkgfHQ=="
+    },
+    "node_modules/safer-buffer": {
+      "version": "2.1.2",
+      "resolved": "https://registry.npmjs.org/safer-buffer/-/safer-buffer-2.1.2.tgz",
+      "integrity": "sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg=="
+    },
+    "node_modules/source-map-js": {
+      "version": "1.2.1",
+      "resolved": "https://registry.npmjs.org/source-map-js/-/source-map-js-1.2.1.tgz",
+      "integrity": "sha512-UXWMKhLOwVKb728IUtQPXxfYU+usdybtUrK/8uGE8CQMvrhOpwvzDBwj0QhSL7MQc7vIsISBG8VQ8+IDQxpfQA==",
+      "license": "BSD-3-Clause",
       "engines": {
-        "node": ">=10"
+        "node": ">=0.10.0"
       }
     },
-    "node_modules/yaml": {
-      "version": "2.6.0",
-      "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.6.0.tgz",
-      "integrity": "sha512-a6ae//JvKDEra2kdi1qzCyrJW/WZCgFi8ydDV+eXExl95t+5R+ijnqHJbz9tmMh8FUjx3iv2fCQ4dclAQlO2UQ==",
-      "license": "ISC",
-      "bin": {
-        "yaml": "bin.mjs"
+    "node_modules/stylis": {
+      "version": "4.4.0",
+      "resolved": "https://registry.npmjs.org/stylis/-/stylis-4.4.0.tgz",
+      "integrity": "sha512-5Z9ZpRzfuH6l/UAvCPAPUo3665Nk2wLaZU3x+TLHKVzIz33+sbJqbtrYoC3KD4/uVOr2Zp+L0LySezP9OHV9yA=="
+    },
+    "node_modules/tabbable": {
+      "version": "5.3.3",
+      "resolved": "https://registry.npmjs.org/tabbable/-/tabbable-5.3.3.tgz",
+      "integrity": "sha512-QD9qKY3StfbZqWOPLp0++pOrAVb/HbUi5xCc8cUo4XjP19808oaMiDzn0leBY5mCespIBM0CIZePzZjgzR83kA==",
+      "license": "MIT"
+    },
+    "node_modules/tailwindcss": {
+      "version": "4.2.1",
+      "resolved": "https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.1.tgz",
+      "integrity": "sha512-/tBrSQ36vCleJkAOsy9kbNTgaxvGbyOamC30PRePTQe/o1MFwEKHQk4Cn7BNGaPtjp+PuUrByJehM1hgxfq4sw==",
+      "license": "MIT"
+    },
+    "node_modules/tapable": {
+      "version": "2.3.0",
+      "resolved": "https://registry.npmjs.org/tapable/-/tapable-2.3.0.tgz",
+      "integrity": "sha512-g9ljZiwki/LfxmQADO3dEY1CbpmXT5Hm2fJ+QaGKwSXUylMybePR7/67YW7jOrrvjEgL1Fmz5kzyAjWVWLlucg==",
+      "license": "MIT",
+      "engines": {
+        "node": ">=6"
       },
+      "funding": {
+        "type": "opencollective",
+        "url": "https://opencollective.com/webpack"
+      }
+    },
+    "node_modules/tinyexec": {
+      "version": "1.2.2",
+      "resolved": "https://registry.npmjs.org/tinyexec/-/tinyexec-1.2.2.tgz",
+      "integrity": "sha512-M/Q0B2cp4K7kynaT/vnED1j8TlLY+Pp7C6Wl2bl/7u/F0mUVwdyOpwomQb8JpYLitHUssAJRmLZdMCGsrx7i+g==",
       "engines": {
-        "node": ">= 14"
+        "node": ">=18"
       }
     },
-    "node_modules/yargs": {
-      "version": "17.7.2",
-      "resolved": "https://registry.npmjs.org/yargs/-/yargs-17.7.2.tgz",
-      "integrity": "sha512-7dSzzRQ++CKnNI/krKnYRV7JKKPUXMEh61soaHKg9mrWEhzFWhFnxPxGl+69cD1Ou63C13NUPCnmIcrvqCuM6w==",
+    "node_modules/to-regex-range": {
+      "version": "5.0.1",
+      "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
+      "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
       "license": "MIT",
       "dependencies": {
-        "cliui": "^8.0.1",
-        "escalade": "^3.1.1",
-        "get-caller-file": "^2.0.5",
-        "require-directory": "^2.1.1",
-        "string-width": "^4.2.3",
-        "y18n": "^5.0.5",
-        "yargs-parser": "^21.1.1"
+        "is-number": "^7.0.0"
       },
       "engines": {
-        "node": ">=12"
+        "node": ">=8.0"
       }
     },
-    "node_modules/yargs-parser": {
-      "version": "21.1.1",
-      "resolved": "https://registry.npmjs.org/yargs-parser/-/yargs-parser-21.1.1.tgz",
-      "integrity": "sha512-tVpsJW7DdjecAiFpbIB1e3qxIQsE6NoPc5/eTdrbbIC4h0LVsWhnoa3g+m2HclBIujHzsxZ4VJVA+GUuc2/LBw==",
-      "license": "ISC",
+    "node_modules/ts-dedent": {
+      "version": "2.2.0",
+      "resolved": "https://registry.npmjs.org/ts-dedent/-/ts-dedent-2.2.0.tgz",
+      "integrity": "sha512-q5W7tVM71e2xjHZTlgfTDoPF/SmqKG5hddq9SzR49CH2hayqRKJtQ4mtRlSxKaJlR/+9rEM+mnBHf7I2/BQcpQ==",
       "engines": {
-        "node": ">=12"
+        "node": ">=6.10"
       }
     },
-    "node_modules/yargs/node_modules/ansi-regex": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
-      "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
+    "node_modules/ulid": {
+      "version": "2.3.0",
+      "resolved": "https://registry.npmjs.org/ulid/-/ulid-2.3.0.tgz",
+      "integrity": "sha512-keqHubrlpvT6G2wH0OEfSW4mquYRcbe/J8NMmveoQOjUqmo+hXtO+ORCpWhdbZ7k72UtY61BL7haGxW6enBnjw==",
+      "dev": true,
       "license": "MIT",
-      "engines": {
-        "node": ">=8"
+      "bin": {
+        "ulid": "bin/cli.js"
       }
     },
-    "node_modules/yargs/node_modules/emoji-regex": {
-      "version": "8.0.0",
-      "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz",
-      "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==",
+    "node_modules/util-deprecate": {
+      "version": "1.0.2",
+      "resolved": "https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz",
+      "integrity": "sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw==",
       "license": "MIT"
     },
-    "node_modules/yargs/node_modules/string-width": {
-      "version": "4.2.3",
-      "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
-      "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
-      "license": "MIT",
-      "dependencies": {
-        "emoji-regex": "^8.0.0",
-        "is-fullwidth-code-point": "^3.0.0",
-        "strip-ansi": "^6.0.1"
-      },
-      "engines": {
-        "node": ">=8"
+    "node_modules/uuid": {
+      "version": "14.0.0",
+      "resolved": "https://registry.npmjs.org/uuid/-/uuid-14.0.0.tgz",
+      "integrity": "sha512-Qo+uWgilfSmAhXCMav1uYFynlQO7fMFiMVZsQqZRMIXp0O7rR7qjkj+cPvBHLgBqi960QCoo/PH2/6ZtVqKvrg==",
+      "funding": [
+        "https://github.com/sponsors/broofa",
+        "https://github.com/sponsors/ctavan"
+      ],
+      "bin": {
+        "uuid": "dist-node/bin/uuid"
       }
     },
-    "node_modules/yargs/node_modules/strip-ansi": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
-      "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
-      "license": "MIT",
-      "dependencies": {
-        "ansi-regex": "^5.0.1"
-      },
-      "engines": {
-        "node": ">=8"
+    "node_modules/uuidv7": {
+      "version": "1.1.0",
+      "resolved": "https://registry.npmjs.org/uuidv7/-/uuidv7-1.1.0.tgz",
+      "integrity": "sha512-2VNnOC0+XQlwogChUDzy6pe8GQEys9QFZBGOh54l6qVfwoCUwwRvk7rDTgaIsRgsF5GFa5oiNg8LqXE3jofBBg==",
+      "bin": {
+        "uuidv7": "cli.js"
       }
     }
   }
diff --git a/package.json b/package.json
index ad4c4627b527..8cc4272493ba 100644
--- a/package.json
+++ b/package.json
@@ -14,24 +14,24 @@
   },
   "homepage": "https://docs.docker.com/",
   "dependencies": {
-    "@alpinejs/collapse": "^3.14.3",
-    "@alpinejs/focus": "^3.14.3",
-    "@alpinejs/persist": "^3.14.3",
-    "@floating-ui/dom": "^1.6.12",
-    "@material-symbols/svg-400": "^0.23.0",
-    "@tailwindcss/nesting": "^0.0.0-insiders.565cd3e",
-    "@tailwindcss/typography": "^0.5.15",
-    "alpinejs": "^3.14.3",
-    "autoprefixer": "^10.4.20",
-    "postcss": "^8.4.49",
-    "postcss-cli": "^11.0.0",
-    "postcss-import": "^16.1.0",
-    "tailwindcss": "^3.4.15"
+    "@alpinejs/collapse": "3.15.8",
+    "@alpinejs/focus": "3.15.8",
+    "@alpinejs/persist": "3.15.8",
+    "@docker/marlin-sdk-web-public": "0.6.0",
+    "@floating-ui/dom": "1.7.6",
+    "@tailwindcss/cli": "4.2.1",
+    "@tailwindcss/typography": "0.5.19",
+    "alpinejs": "3.15.8",
+    "heroicons": "2.2.0",
+    "highlight.js": "11.11.1",
+    "marked": "17.0.4",
+    "mermaid": "11.15.0",
+    "tailwindcss": "4.2.1"
   },
   "devDependencies": {
-    "markdownlint": "^0.35.0",
-    "prettier": "^3.3.3",
-    "prettier-plugin-go-template": "^0.0.15",
-    "prettier-plugin-tailwindcss": "^0.6.8"
+    "prettier": "3.8.1",
+    "prettier-plugin-go-template": "0.0.15",
+    "prettier-plugin-tailwindcss": "0.7.2",
+    "rumdl": "0.2.49"
   }
 }
diff --git a/postcss.config.js b/postcss.config.js
deleted file mode 100644
index c50d4a38bcee..000000000000
--- a/postcss.config.js
+++ /dev/null
@@ -1,8 +0,0 @@
-module.exports = {
-  plugins: {
-    "postcss-import": {},
-    "tailwindcss/nesting": {},
-    tailwindcss: {},
-    ...(process.env.NODE_ENV === "production" ? { autoprefixer: {} } : {}),
-  },
-};
diff --git a/scripts/lint.sh b/scripts/lint.sh
new file mode 100755
index 000000000000..23a29bdd4742
--- /dev/null
+++ b/scripts/lint.sh
@@ -0,0 +1,27 @@
+#!/bin/bash
+# Run rumdl and Vale on specific files.
+# Usage: scripts/lint.sh <file> [file...]
+#
+# Scoped output — no repo-wide noise. For full repo validation, use:
+#   docker buildx bake validate
+set -uo pipefail
+
+if [ $# -eq 0 ]; then
+  echo "Usage: $0 <file> [file...]" >&2
+  exit 1
+fi
+
+exit_code=0
+
+echo "=== rumdl ==="
+if ! npx --no-install rumdl check "$@" 2>&1; then
+  exit_code=1
+fi
+
+echo ""
+echo "=== vale ==="
+if ! vale "$@" 2>&1; then
+  exit_code=1
+fi
+
+exit $exit_code
diff --git a/static/.well-known/mcp/server-card.json b/static/.well-known/mcp/server-card.json
new file mode 100644
index 000000000000..6b21ff42104d
--- /dev/null
+++ b/static/.well-known/mcp/server-card.json
@@ -0,0 +1,23 @@
+{
+  "serverInfo": {
+    "name": "llms-txt",
+    "version": "1.26.0",
+    "description": "Official Docker documentation MCP server. Exposes a fetch_docker_docs tool that returns the docs.docker.com content index."
+  },
+  "transport": {
+    "type": "http",
+    "url": "https://mcp-docs.docker.com/mcp"
+  },
+  "capabilities": {
+    "prompts": {
+      "listChanged": false
+    },
+    "resources": {
+      "subscribe": false,
+      "listChanged": false
+    },
+    "tools": {
+      "listChanged": false
+    }
+  }
+}
diff --git a/static/apple-touch-icon.png b/static/apple-touch-icon.png
new file mode 100644
index 000000000000..e25989d1514a
Binary files /dev/null and b/static/apple-touch-icon.png differ
diff --git a/static/assets/images/app-wf-dark-1.svg b/static/assets/images/app-wf-dark-1.svg
deleted file mode 100644
index d7fa9b3f240e..000000000000
--- a/static/assets/images/app-wf-dark-1.svg
+++ /dev/null
@@ -1,11 +0,0 @@
-<svg width="336" height="202" viewBox="0 0 336 202" fill="none"
-  xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-  <path d="M0 0H336V198C336 200.209 334.209 202 332 202H0V0Z" fill="url(#dark-wf-1)" />
-  <defs>
-    <pattern id="dark-wf-1" patternContentUnits="objectBoundingBox" width="1" height="1">
-      <use xlink:href="#image0_129_29473" transform="matrix(0.00212777 0 0 0.00353927 0.0297619 0.0453854)" />
-    </pattern>
-    <image id="image0_129_29473" width="442" height="274"
-      xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAboAAAESCAYAAACLuBAGAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAjcSURBVHgB7d1PjJx1Hcfx7+xuUYwIxRSyUGQTtHAp0jbRCxAuNiEGYzxCPHhATjS1tpwECZrwv5BCghKrCQaNIanxT0KCHAA5qBGLGA8tNln5t5RKW4UodNmO80wggF2XPzO7s8+nr1fyZNrZPUzSpO98n9/8fk+nGhdsnloxPvej6tYFnapTCgDarFM/PzI3u6We/N50px+5sbndAgdAmENHjs6unzhhbO6OEjkA8qxc0Vnxw7HeH75cABCo07tvOVaL6NqvX1q3bf1KAcCInLKooTv5pBPr5I+fWAAwKkMN3ZcuOb/2/vrb/SmueT37jFNrqne901cv+3wBwFKZqCE4pTe5nb/mzP7r3184WIdf+U//tbk6vdB9tvezRjPh/eD6K3rvv1yPPfG3AoDFNpTQNZH7zb2b+vG6eMOn+4G7eMNn+j87e/KT9cD2K+uxPz5dj74Ztwduv7KemXm5vnnbrkUP3utP7Khh+siGTTWIYX+e9+LzLq62fd4P4jvff7C+e++D9WF9q7dGf+1Vl9ZSGfTzkmvg0DWRa25ZPvrE0/1Jrnnt9t5vXv/Z+/uhV57rT3rNe00EG83f/7y3N/XNHCwAWEwDh66J3NWXX/LuNzfM84tvvtfE8HOX39yf+gBgsQ38ZZQPOpXd9ZNHRA6AJdM5Yf3V3RpAcxty/yM3v6/fbQLXTHPNVAcAS6A78ETXRKuZ0t5LE7kvXLVD5ABYUkP51uXW23f1X5s9cs2E907TMy/Xj3/5h7r7p4+IHABLbuBbl//rrf10jWb9znocACPUHcpE905P7X2+AGC5WNSzLgFg1IQOgGhDv3UJHKs54Hzvr66vtmvW3Ndcdn1Bm3RWr1k71C+jAMAy0nXrEoBoQgdANKEDIJrQARBN6ACIJnQARBM6AKIJHQDRhA6AaEIHQDShAyCa0AEQTegAiCZ0AEQb+Hl0V2y6rpaL+3fcUG204oSP1idOXVXdo3PV7XpqEnB8G59Y0b8O7n++Zo+8VoPy4NURayJ34kkn1fP7/loAvO20s86perUGjp1blyO28vQz66Vn9hUA7/bSs/v6d7sGJXQjdnRutgCY39Heks6gBr512dZ1seViblboAP6vIXxvwUQHQDShAyCa0AEQTegAiCZ0AEQTOgCiCR0A0YQOgGgDbxh/ds9T1Ubb77qn7rj7nmq7bVs21zW9q41WrZ4qgMVmogMgmtABEE3oAIjWWb1mrSd9jtDKVZM1M72nADjW5NS5dejATA2ga6IDIJrQARBN6ACIJnQARBM6AKIJHQDRhA6AaEIHQLSBD3W+YtN1tdzsf266Ht51XwGAiQ6AaEIHQLSBb10yWusu3FjrL9pYAMtSt1s7b9pWozRw6O7fcUMBwHLl1iUA0YQOgGjW6Fpu9+MP9S8A5meiAyCa0AEQTegAiGaNruXso4Olt/PGrUV7mOgAiBZ5qPP78dTvH62/9C4AspnoAIhmja7l7KMDWJiJDoBoDnUGIJqJDoBoQgdANKEDIJrQARBN6ACIJnQARBM6AKIdt2ddvsU+QIBsJjoAojnrsuU8j45Uf/qtc1wZDhMdANGcdQlANBMdANGs0bWc59EBLMxEB0A0oQMgmtABEM0aXcvZR8d87EGDt5noAIgWedbl/uem6+Fd9xUAmOgAiGaNruXsowNYmIkOgGjOugQgmokOgGjW6FrOPjpS2QvIsJjoAIgmdABEEzoAolmjazn76AAWZqIDIJrQARBN6ACIZo2u5eyjYzmzF47lwEQHQDShAyCa0AEQzRpdy9lHB7AwEx0A0YQOgGhCB0A0a3QtZx8dqezBY1hMdABEEzoAogkdANGs0bWcfXQACzPRARBN6ACIJnQARLNG13L20WG/GSzMRAdANKEDIJrQARDNGl3L2UcHsDATHQDRhA6AaEIHQDShAyCa0AEQTegAiCZ0AEQTOgCiCR0A0YQOgGhCB0A0Z1223LYtm+ua3gXvxy3b76xbexccT0x0AEQTOgCiCR0A0Tqr16ztFiOzctVkzUzvKQCONTl1bh06MFMD6JroAIgmdABEEzoAogkdANGEDoBoQgdANKEDIJrQARBN6ACIJnQARBM6AKJ5Hl3LrbtwY62/aGMBLEvdbu28aVuNkokOgGhCB0A0oQMgmjW6ltv9+EP9C4D5megAiCZ0AEQTOgCiWaNrOfvoYOntvHFr0R4mOgCiCR0A0YQOgGjW6FrOPjqAhZnoAIgmdABEEzoAogkdANGEDoBoQgdANKEDIJrQARBN6ACIJnQARBM6AKI567Lltm3ZXNf0ruPBLdvvrFt7F8AHYaIDIJrQARBN6ACI1lm9Zm23GJmVqyZrZnpPAXCsyalz69CBmRpA10QHQDShAyCa0AEQTegAiCZ0AEQTOgCiCR0A0YQOgGhCB0A0oQMgmtABEM3z6Fpu3YUba/1FGwtYOjtv3Fq0h4kOgGhCB0A0oQMgmjW6ltv9+EP9C4D5megAiCZ0AEQTOgCiCR0A0YQOgGhCB0A0oQMgmtABEE3oAIgmdABEEzoAogkdANGEDoBoQgdANKEDIJrQARBN6ACIJnQARBM6AKIJHQDRhA6AaEIHQDShAyCa0AEQTegAiCZ0AEQTOgCiCR0A0YQOgGhCB0A0oQMgmtABEE3oAIgmdABEEzoAogkdANGEDoBoQgdANKEDIJrQARBN6ACIJnQARBM6AKIJHQDRhA6AaEIHQDShAyCa0AEQTehGrNPpFADzG59YUYMSuhHrjI0XAPMbn5ioQQndiP3r0IE6/VPnFADvdtpZ59TBl16oQQ2eSgYy+/pr9e/e69nnrau5udmam50tgONZs6TT3O1qBoHm/8hBCd0y0PxD7n92XwEwfG5dAhBN6ACIJnQARBM6AKIJHQDRhA6AaEIHQDShAyCa0AEQTegAiCZ0AEQTOgCiNaE7XAAQaqy69WQBQKZfjL0xPv61MtUBkOfgG0fGvzH+6j9ePPyxVWf8bLx7dKqqc14BMErdYlCHq9v93RuzE198cfrJ6f8CvcXWabRNqLIAAAAASUVORK5CYII=" />
-  </defs>
-</svg>
diff --git a/static/assets/images/app-wf-dark-2.svg b/static/assets/images/app-wf-dark-2.svg
deleted file mode 100644
index fb0425069869..000000000000
--- a/static/assets/images/app-wf-dark-2.svg
+++ /dev/null
@@ -1,9 +0,0 @@
-<svg width="207" height="86" viewBox="0 0 207 86" fill="none" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-<path d="M0 0H207V82C207 84.2091 205.209 86 203 86H0V0Z" fill="url(#pattern0)"/>
-<defs>
-<pattern id="pattern0" patternContentUnits="objectBoundingBox" width="1" height="1">
-<use xlink:href="#image0_560_4067" transform="matrix(0.00213285 0 0 0.00533883 0.0234653 0.0611291)"/>
-</pattern>
-<image id="image0_560_4067" width="442" height="274" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAboAAAESCAYAAACLuBAGAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAABJ3SURBVHgB7d17kF5lfQfw3+5mNyGSkECukJCQpSQglwAdLrUF7ICOWqXqtE51qtNxrH+J1Gr/qtaxnWmd8TKijtWpveCgYx2oWC9FM5VkOgoMmBA0EGRDIAnJQkJCCLnsZvP2PG+yIZfdTdg9777nffbzmTnzXvbdmZ397Tnf83ue85xti2T57Ys7Owb+LWqxvC1iRgBAK2uL/+ob6P9YrPnnjW31kGsfWC3gAMjMzr5D/VdN6mof+GIIOQDyM7OzrfNf24snfxwAkKG2YtyyPRrok3/5lvjcx98VANAkMxoadGdNOyPOOvOMAIBmKTXo3nHT5fHkD/+u3sWlx0Xnnh2Li+1Yf/72awMAxsukKMGMonO7/KLz6o/PPPdi7Hp5X/0xbW1F0F1RfC1JHd6/fPp9xfs7YtUjTwUANFopQZdC7mffuK0eXjdcfWE94G64+nfqX1s0/5z43hc+FKse/m2sPBJu3/v8h+LZrTvirz93T8MD78Ajd0SZJl99W4xF2T/Pqfh5G6vVft7X4u+//pP4h2/8JEbrb4s5+k9++C0xXsb685KvMQddCrk0ZLnykd/WO7n0WCveT48vFa93vry53uml91IIJun1o08WXd/WFwMAGmnMQZdC7iPvven4N68e4oNH3ktheM17P1vv+gCg0cZ8Mcpr7cq+/O37hRwA46at66qP1GIM0jBk7/2fPa3PpoBL3Vzq6gBgHNTG3NGl0Epd2qmkkLvlw3cIOQDGVSlXXX788/fUH9MaudThHWvj1h3xrR88FF/5zv1CDoBxN+ahyxMNrqdL0vyd+TgAmqhWSkd3rLVPbgkAqIqG3usSAJpN0AGQtdKHLoGTpRucP/nfn45Wl+bcL3r7pwNaSduCiy4r9WIUAKiQmqFLALIm6ADImqADIGuCDoCsCToAsiboAMiaoAMga4IOgKwJOgCyJugAyJqgAyBrgg6ArAk6ALIm6ADI2pj/H937bvtUVMVdd3wmWlFn15SYfvbsqB0aiFrNf00CJraOSZ317cXeLdHftz/Gyj9ebbIUcmdMmxZben4TALxqzsLuiD0x5rAzdNlkM+eeF88/2xMAHO/5TT310a6xEnRNdmigPwAY2qFiSmesxjx02arzYlUx0C/oAIZVwnULOjoAsiboAMiaoAMga4IOgKwJOgCyJugAyJqgAyBrgg6ArI15wfim9WujFX3hy1+LL37la9HqPvGx2+Nviq0VzV6wOAAaTUcHQNYEHQBZE3QAZK1twUWX+U+fTTRz9vzYunF9AHCy+YuXxs4XtsYY1HR0AGRN0AGQNUEHQNYEHQBZE3QAZE3QAZA1QQdA1gQdAFkb802d33fbp6JqejdvjBX33BkAoKMDIGuCDoCsjXnokua68vffFFf9wZsCoJJqtfjmP30immnMQXfXHZ8JAKgqQ5cAZE3QAZA1c3QtbvX//bS+ATA0HR0AWRN0AGRN0AGQNXN0Lc46Ohh/3/zHjwetQ0cHQNayvKnz6Vj74Mp4rNgAyJuODoCsmaNrcdbRAYxMRwdA1tzUGYCs6egAyJqgAyBrgg6ArAk6ALIm6ADImqADIGuCDoCsTdh7XQ6yDhAgbzo6ALLmXpctrtY2KfbOuCYGumYFQJW0D+yNya+sj859m6KZdHQtrn/yfCEHVNKhjqmxf9ql0WzuddniasUfEkBV1do6o9l0dABkTdABkDVBB0DWBB0AWbO8gBHNu/DimN99ccBQ1v/yf2Pv7l0BVSboJpBzFlwQ3Vf9Xkw9a0bsfWlXbO1ZF5t+s3rE7zlr9vw4//VXBQzl2eLvR9BRdYJuglh2/R/G9CK00hn4Sy9srQfY0uK9qdNn1t8DyFWW97rs3bwxVtxzZ3DYrKKTSyH30A/uqr++9Ka3xq/v/3H99Rv+5IOxvfj6js1PB0COdHQTQJpn6/nVL46+3nDM857Vv4j5xdeHC7ptTz1uaIph7du9M6DqBN0E0Dl5ynEHpEvf+LZ46N7D3d2+Yq6us3vKsN+bhjnTBtCqLC+YAPYVHdm8Cy85+rqz69Vgmz5nvo4NyJp7XU4AadjyDX/6wWIYcl091AYvPpk6fUZ0X3n90bk7gBwZupwA+g/sj9X/c09c+eZ3x9aex+uvly68IM5//ZXFEOa3R+zoOqcvjK5iAxhK3+5N0b+7uf+G51QE3QSR5tlW33d3zFqw5PA6uiLc7v/WV+uhN5KOM2ZG19ndATCUgf49go7qSOH27LpfBcBE4mIUALKmo2NE/bs3x6G+VwJgKAP7q7+WUtAxooF9L9Y3gFZl6BKArAk6ALJm6JIRWUcHeWuFdXBjJegYkXV0kLdWWAc3VoYuAciaoAMga4YuGZF1dJC3VlgHN1aCjhFZRwe0OkOXAGRN0AGQNUEHQNYEHQBZE3QtrqN/ewBUVfvA3mg2V122uEl9O2LK7tXRP8VtuoBqaR/YF5NfWR/NJugy0LVvU30D4GSGLgHImqADIGuCDoCsCToAsiboAMiaoAMga4IOgKwJOgCyJugAyJqgAyBrgg6ArLnXZSa6pkyN2eddEG3t7dHW1haMTvukSXHo4MHoffap6Ntf7l3X1agcalR9jazRaAi6DKSdc9a5i2LHNjd2Lss56ff53DOl7aRqVD41qr6yazRahi4zMPf8C+PF3i1BeXYWv890Zl8WNSqfGlVf2TUaLUGXgfaOzqB8afiqLGrUGGpUfWXWaLQEXQYODfQH5StzjkaNGkONqq8Kc52CDoCsCToAsiboAMia5QVA3ZzzFsXcBYvjddNm1F+/8vKueHrdmtjz8ktBNXRNnlyvT/+B/eryGgg6GmbJxVec9mf7ih1384b1wfhLB8/rb741FnQvO+lrl197Y2wowu6xB1c6sDbZmdPPipvf9YF43fQZsWf3rvjJd75e7DcH4uob3hzdxb72aFGj9WseDE4m6GiIdICcU3QH6SB5/S23ntb3rC121HRAZfwce/AczpJLltc7vR8fObAy/o6tU9+BfbHi7jvrtUgnk8uWX1vfd1LIpedPCLuTmKOjcWq1oNouK05IRgq53s0b6ycf6TPX3Xx6JyyUL/3uB+vUNfmM6Joypf585ux5Rz+TTi6vvuFN9Q6d4+noaIh0hrlwydLonDwlfvmze0/5+VeKoZjeLc8E4yd1CUsuXj7k1zasezQ2PL6mXpPrb3lH/b2FxdDm3GIeT53GT6rRnPMW14f2j7Xk4svjsd076/VIUsglO7dv03UPQdDRMCnkGvFZynHBECG3uWd9/GLFvfWLHZITw3BG0UEIuvGTQit13WcW3dymnieKbm1KfRh52fLrihPJZUfn63o3PxN7X94Vjxu2HJKgoyHM0VXfUEOWD6+6r35hQxp0TnM+lx3pFAbNnDUvGD+pk1txz53F/Nz7Y8MTj9ZPRNI8XLoAZTDk0nxdukKW4Qk6GsccXUtJw5WDB8x006aRhjYZP2lYP4VdCr00/zZ4NfNgyPX37QtGJuhoCHN01bd39/FdwNoj3XS6am9wycGJdA7NkfaPVJN05WW6AGUw5NraavHWP/tw9Dz+qNGQEQg6GsYcXbWlKyoHhyYHu7m0aLz7kitGvEiF8TdUyKV6pe4uDWEOXowi7IYm6GgIc3TVlzroTcWcz8LupbGnOGimeaB0ocNwjh3aZPwMF3LJhscPn3ikfUzYDc86OhrHHF3lPbDi3vrBMx0kRwq59Jm1DqBNcdm1Nw0ZcoNS2A1OD6Q6Hru2jsN0dDSEObrWMHhVXzpADnfLthOXHDC+Uied7m/5yKr7hu2oU9il+qQlI3371elEgo6G2eTelS0hnWSkk5F0clKf8zlyU+dd27fFzhe2OQFpsrQIfNWPvnvKz6X9zT43NEEH1KXAM79DjszRAZA1QQdA1gQdAFkTdABkzcUoHNV17vKY+c4vRQ52fv+j0bdlTeRGjaovnxrVihrdnkWNdHQAZE3QAZA1QQdA1szRcVTfc2ui96s3BtWlRtWnRtWjowMga4IOgKwJOgCyZo5uArjkmjcGw1v30M+j2dRoZGpUfVWo0XB0dABkTdABkDVBB0DWzNFNAFUeO+cwNao+NWpdOjoAsiboAMiaoAMga4IOgKwJOgCyJugyUKvVgvK1d5R3UbIaNYYaVV+ZNRr1zxC0vIGD/ZX4Y8pJ+n32H9gXZVGj8qlR9ZVdo1H/HEHLe35TT8y/YGl0dk0Jxi7tnPMXL43tzz0TZVGjcqlR9TWiRqPVtuCiy/TrTTRz9vzYunF9jFXHpM44Z9750TnZTjoWafjqYP+B2LH12foZfpnUqBxqVH1l1iiF5c4XtsYY1PTpmUh/TM9v7gmqS42qT43yZOgSgKwJOgCyJugAyJqgAyBrgg6ArAk6ALIm6ADImqADIGuCDoCsCToAsuYWYJlI9+ibNf/86OicHG1tbcHo9fftix1bNzXkPopqVA41qr5G1Wg0BF0GuqZMjYVLr6jfHPrQwYPB2KQb+l7w+t+Np3/zcGk7qRqVS42qrxE1Gi1DlxmYde4iO2eJ+g/sj61Pr4+5C7ujLGpULjWqvkbUaLQEXQbSmZOds1wDAwejvRjGKosalU+Nqq/sGo2WoMvAoYGBoHxlztGoUWOoUfVVYa5T0AGQNUEHQNYEHUALmXPeophbbJw+ywsAWsSSi6+I62+5tf784VX3xfo1DwanpqNjXC1bfm1cdu2NAbx2cxYsPvp85qx5wenR0TFuLi8C7tiQe+zBlUH1pZOT3s0bY+f23mB8nTn9rLj0mpuOvp53zJDlvAWL4rqbbz36+tcP3h97Xn4pOJmgY1ycGHKXH3ku7JovHUyjFvWD5MxZc+OVl3fV31+wZNmRx6X12q24+z+E3Ti79NqborsYrhzK66bPiO5LZhz33gMr7g1OZuiShjsx5I59f2nRLdBc6WB6wSXL689v+KP31IfHXjdtRn0uKG1zi9ddk6fE1Te8OaAV6ehouD27d0XPukeLs8/jz0zTe26b23wP/OzVLuDef7/j6PO77vhM/fG6IuxSp7fyR/8Z0IoEHQ234fFH69uJQWeYpTVs6XkiHll1X/3ehYyv9asfjKfXrSlGPq6Lhd1LR/zs4Jzd81s21vc3XmXoEia4rsmT6/Nww9m0Yb2Qa5Kd27dF75ZnYtWPvht9p6jB4Tm7w8sPrLM7nqCDCSyF3M3v+sDRC08gR4YuGTfpCsup0w5fJdbfp0Ooghve9p6YOXtefRscWv7xd74RZ047q37xyfeLObt00VBnEYiPrPppML5SHVKntqSoTbogaCRpLrx38zOx60gXyKsEHeNmraUElZPC6+Z3v7++bGBDMReUpAPmK8W28oeHLz7pSfM9taAJLr3u5OUFg0OYJwZfCjnz3kMTdDTUcEsLjvXEmgd0C02S5oBW3H1nzF2w6KQLGPoObKs/ptCjGjb3rI+VxXxd8rtFx215zukRdDRU6gb2nOJAmc5EaZ4Udmmj+tJJ4aBNPU8IutMk6Gio1A1s0BHAqNTvHHTMsPGxV16mO9iktajHfZYhCTqAikonisPNu+3Z/ZI5udNkeQEAWRN0AGRN0AGQNUEHQNZcjMJRXecuj5nv/FLkYOf3Pxp9W9ZEbtSo+vKpUa2o0e1Z1EhHB0DWBB0AWRN0AGTNHB1H9T23Jnq/emNQXWpUfWpUPTo6ALIm6ADImqADIGvm6CaAS655YzC8dQ/9PJpNjUamRtVXhRoNR0cHQNYEHQBZE3QAZM0c3QRQ5bFzDlOj6lOj1qWjAyBrgg6ArAk6ALIm6ADImqADIGuCLgO1Wi0oX0dHeRclq1FjqFH1lVmj0RJ0GagdOhSUb2DgYJRFjRpDjaqvzBqNlqDLwAtbno6z5y4IypN+n73PPhVlUaPyqVH1lV2j0bJgPAN9+/fG9uc2xtzzL4z2SZ1x6GB/MDpp+Cqd2aeDXvq9lkWNyqNG1deoGo2WoMtE+mPa9OTaoLrUqPrUKE+GLgHImqADIGuCDoCsCToAsiboAMiaoAMga4IOgKwJOgCyJuiarK2tLQAYWsekzhgrQddkbe0dAcDQOiaN/QZegq7Jdu98Ieae3x0AHG/Owu548fnnYqzc67LJ+g/sj3TL00XLroyBgf4Y6HcjWWBiS1M6abQrNQLpGDlWgq4CUiF7N/UEAOUzdAlA1gQdAFkTdABkTdABkDVBB0DWBB0AWRN0AGRN0AGQNUEHQNYEHQBZE3QAZE3QAZC1FHS7AgAy1R61WBMAkKd72w92dPxF6OoAyM+LB/s6/qpjz/Ztu6bOPve7HbVDiyPalgUAzVQLxmpX1GoPHOyf9LZtG9ds/H9Jv/QqwSAjPAAAAABJRU5ErkJggg=="/>
-</defs>
-</svg>
diff --git a/static/assets/images/app-wf-light-1.svg b/static/assets/images/app-wf-light-1.svg
deleted file mode 100644
index 07c366653c0f..000000000000
--- a/static/assets/images/app-wf-light-1.svg
+++ /dev/null
@@ -1,11 +0,0 @@
-<svg width="336" height="202" viewBox="0 0 336 202" fill="none"
-  xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-  <path d="M0 0H336V198C336 200.209 334.209 202 332 202H0V0Z" fill="url(#light-wf-1)" />
-  <defs>
-    <pattern id="light-wf-1" patternContentUnits="objectBoundingBox" width="1" height="1">
-      <use xlink:href="#image0_129_29169" transform="matrix(0.00207469 0 0 0.00345097 0 0.00882889)" />
-    </pattern>
-    <image id="image0_129_29169" width="482" height="315"
-      xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAeIAAAE7CAYAAAAB2IJEAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAHYMSURBVHgB7b1/jF1Jdt9X975mk83fzW2ql5ymNNqMZYmUZCuDWDtaQLNxsrLgSHAAZZXANhDYshUHMGxrFTv/2MPh2H8kAbxyggB2knUcIM460mRtIJGd2KsYMwaklRwwki2RawiUzNVyOOoll2Q3f5P93nV9zzun+tx6dd9rTj+ym6+/H+D2/VW3qm7de/u8c6rqnBAm0DRNVdrHety5cXnk58aln3S+lL4rf9uOSxjHs97XVuvX1Q5jrp94n+6eqlJbaZqwlfog3aS6jsuj61hHnapJZXTUo8rLGbced49bKCuMy69je0vPrOvYuLrn11p5k9Jl50fyH/fM+f2/3N+/vu/5fpV/B5audK5Q35F0E45VHddP+h8zUo8q4svZwrp4j1spq3Rf+b0Vrq0m5flMdH1w4176rnwmNbq+KFXIXjxH1bFdLM+VO+kfWzUpv0nluG2fV+kfrr9Pn09XEWMFTtdLU8qnVOeOazr/SYeOdrJ2HpemdA/Z9cWy/Is+gVb7N+1/PBMFdyi3UfGdc886TzNST0tbeic7vqOu9u+qdxhXfum4f15da7ftv93iOz0Jfv8pzY5+/01BKDSZkNYy/TMb+/27tKErTZ6u0CbFsrJrwgRS+/v0pfw76jJWoPo6DQaD4vdvPxC67jmry/h3Lv8HkO2HCZmM++eU/iE940c3Uj+XZ/GfwoQH5+s4UbC4B7OVD7bK6xfagmFSHlv5B+Pbb+QfZ9P+5xl8+qxupRd9S//s8vb1z6L0jyf7uIq/KCeVGTJBG8qCsWoywTch7bgPz7d1qx7+nWi6/7mH/Pox91vlS6l9c7J/MPm50iUjbejf86yO+T9H314hlJ/VVr7/ZxW6+X3x+3+G71+FQ65FpuPP+v1n70Brv/Btt955V4fSt9dZpjs38v03TjACbOcCsSvtpO/f0pTu35cz5vsMzdZl58jFXb/UO7ezmxgRtE3hn7G7pnMpvXBN+8fBiGBv2v+I08v29ttv19n9tdJ1LCHPL5Q/5JE6Z22Q17nzoyrcX9C6d91f8Z477m2kPTvqGvJ6lu5lq88xtJ+7L7+1nZWXHwu+rKYsfEOeblx98/bueNat+jdtwZUf8+lD1zvqzoWuZ5U/k+y6ie3dlP/xl96hEDrepzD6zErHi+9HXudn+OZKbcDvP0zv+2+cIHXCptLdlgB32p8//8zfvwnJrPyRHwZe2/Q/FsImlc8rE77BpxtX3+yHiCyWT37P7tmUlnQPvu7ZuVbd8nOhROlE4R9MaT3uBbAPobV2L1idn8exwj8nOV445pc6P27Xad7pvEsj5zo+ujov045ZXbPraqt79gKM5JHVq3gfefvZ8dK+L2vMP5tW+5bSldrUt5Xf9vdRKqNwXyN19dflbTquLdw/2NY95M8y+8fnn2lX2xcXX19fdimPcc+0o93rpin+IKizZ95V37zdWt9W3t6Fckr1zp9v6X0feedK7w+//535/guCpdW+JYFWEES1O9baxtLv9/P6dn7/wOpauu78+fP1mDrL9T4Ntv05HEP+ucZq+67M2sortH1VqrfJN/+joaB95ybq1rlmkmbsT2SJyhdsHh956Tv2a/fx+Qflj/n9nj9WSptvZ/n0snVK89nPfrZXumZcPUrp8vSFfCbeQ76gbraE0X/6k+raVVa1lbKtPfwy7rpx7e/byN3LltpgK+etff0/Hl/OpOtzoYS8uu63q/7+Hkv3X3pPfHtgXXrXu55tKf+8boXvoHUf476fZ2z79AwmvQf++9/Ku8Dvf3rfvxM0fr+z3n7xaUvX+WNd6bEuPfNx9djKeWtfE6xY+3ImXW/XeeFcqr8JfnsWYVMQV7mwb9pWhpHjzagWPSqQS4I4O9ZKm0n8KnS8bO5lTh+GNlhrsWP+nN/WfObGXfvpT396zr3Evbzc0pKX4T8E5OfTlerYsdR5GdnHOSmPekxb1JPuadzS1b7j0nZdM+FZjeSf7/t3Y1y+eT2yf1Z5vnUp/VbaYyttkqe1xd9L1/1vo9z8Wc/l7ZfXR/ObC2O+uUnPuOuZ2Hc2qW1Kz6arLvz+w9h2epm+fxVcE99xSzcp3x36/utCW7dknGnf3rLQNKN94znNRzBJY1USxi0hnGldvuL5MqeLveSy2AuPtS3uuF962b4s7p9Onqcsr7/++j47Vii3tVjacWm2unRd6477snooe1L98nzya/x1ebtsJb+uY11lbCXfrZSXP5tS2nHtmZ/37VJau3+yxXsZ925Yuxby2/K9jrs/v116t/N3dKt1GJd2zLPfNy7NuOPP2B78/p/z9//mm2+Oza903o7l5/z+pHy3Uh7qPC6fceftufrzaJe87rbOv//SvbhjSX7pNaYt2w+J2kzhoW3OTnjB6zXkrZKbnlsDQPK+tlAWvsWX6ezZs/Nh+BLuQ4Ppy5/WpcWnG3ceeWu6Vhm+TLfM5+lK+ZbKtzLGXYMlK3e+q/6l63Gttp8vZ34r1xbabd7yzI91tW3WjvP+nkrluP25rvqVnn32/OcL7db5fAr5Fp9n6R4nPKf5cddkxzvvadxzmXRvHe/syHMrLaX0496LrjIK95zapivvZ7kv/y7x+3/+3/+5c+e2/f1bHmPKfdm/f1lKwt8EeIeFIh/nAVr9y/iTC+MkqMd1HmdqdtEMHdpqff7LMr/ZrSz7/fLaa6/Jkp/X/Pa7fFvpsvJSPi6/lN7nkdVh3tJ25Nsqo1CXdK3VNytnPqvD/lIafyy/r+y6/aV7z88X2nG+49q8HvO+Hfy12M7v2T/DfNvqbfeftfP+rnuw41lZ+8flldc9SzdyvPD8O++tcE+ldym1Wf7OuXbcX3gH8jp1PZf9+buUvW8jz87S58+x9IwL7TJStq973q6+zDDhvQr8/vd3Pd/A7/+5fv+Fe09CuvBjI2nM1j89ZvBX1/SttvwtSfJmdPpASxBnNvhkbsl+vbUexquvvnogbh/QBjigi2zrOX9cjtk1rqFl26e3ND59np/LR5aVlZUFXxdLn9dR0+3Py8BieeR19umyey2mHbed32PHfR4o1W9MO7cW/2xK7Z89h1I995fawpXbWXbhHvbn70h+XamtSmm66j2h/LFpsvclnfPHt1Dufpdm/xae3cTn1PXsCukWsjruL9W58K1tqc0KaRfy+ox5v/n9B37/vv1DeGHff+v9Ch0/bjINPnUDeFO17zcObVO114rzWR2d5FOSSh3YIoS98PW/VEovvz6wtI7LQV1k+9SpU/l2Wtw1C3l6PXcwy2/B5bFQyLt1Pq9L175dg7Wvk6uDv7fWffry7NqsDiML0vm6d+TZKrOQ58HSPZTa1K4vlHnQP0PLp1SWb4vCPfu2a7Vn/szzernyS2UfLCxd7VJq84OF+xo5nt2fb8OD2Xu9kNW561mmds3brfD+trZL744rY2xbhNH3u/M970g38t77crM6tO6H3//e/v5Pnz69m79/X07rB0VmwUhm7NAehJZGWm/BkYkwMkJ6eJ1MspZ9Hc5uRu3a0sVfAeHdd98ViR8rla6/fPly+iUQbyRcu3YtlRPGT4eyMqqTJ0+Guq6b1dXVlGB5eTlgP56rbty40WAfWBo7b+sSdo1dV7rGbVtdG9tGvVB2Kd+8zOxYZdfm9S61RUzT+Dri15Vdm9XTt9vYezfQftq2vpzK3Wfj0+blFu4xXePrimtxDGVlZaRr/T3adlYH207PIC/fKL0rHfVN9zXpXgr1mfT+dT6P7F3z71bOyLMotU+pfLS9fTf5+1e6xtfTyK/N2qrUPs/yHFrt03Gc3z+//536/tN+FNjNhx9+aLuWtokyrYoybRBlnhyL8k6Ox/7k5v3332+ljUI5XLhwoYEsje0ixyBrY5vk+bZGRYvwDu1/BCldFMYQyulY/BVQvffee7n63dqONxPizeTnm6WlJdm/efNmiNtYN/qithob5ywdro37TdzOX5rWA/bXaN4+y3DixInq1q1bjZ6zPC2t1U+ui3VqfJ1wHC8arg+TadWvVJcSrsxUNyvb6pnfn91Tfo/hGeiqn9XHl2/t5tO5dsE/nYG7Jj2fcW2AOmNteYSOZ1rKJ98f1x75M7R9/MPI3pnWPfr7C5kwsfpZmknPunC+9ax9mlJeHflX8T6Dv6+u6wv48ovCclKb+7z0+vQe5OcK7zC/f4Xf/4v//o38mWPbfkiAKKhte6Br+ZEQLcLNkSNHmrt371YXL15sopLaRCW1cWmMxs03Dh6bcB8yITwyXckJYXlJUGgYFcCyxF8XoppvbGzU+suoNdgr3rAsi4uLtu7Fm0+jz3DczmHR45h8jeNmJvdrufb48eO9WGZP0/lr02IOHPRchfRap56VbXVDnZCnXYvjZqbHeb/2S3as8nl2pEnHtB16rm5SX39Pdl+WZ3ypqsI91tYm1j6+znn5yD+rj+Tx9OnTOX2WPbeWZ4E2Qx2wjTponvi12XPtn54P9n17unr0vPOXvI7+fbH9/D3x1yEff3/aPqlOOG/1wH78MC2PnqtjZfeGtbWxe/9q91709OOuS886f+ZWX5RjbZa/q/4Z5/nYs8jfM9xH/jzztvLb7piVb++bz7tXqkfhfWm97/b+5nUM/P75/Yfd9f3jniwPq7veh9wntHnV6Oso2/L3r47Ct1YhXEUFFZZiWIxbshGC1yzNtu3HZckf3WlUSnsteZjDZoZJEzZzdFTNrVKyqNqfC2lZHzt2rFpbWwtxHbA28n1w9OjRan19vfXjwKdz28i3ya93ZTd5OZa3ruVWS3Xoyq+jHlupV+tejEKb+J9LzaRy4n0EbSvfbiNlWL6uXlKfUluHjrbzFOrcdKXtOr+VssNme6S2z9fuWbbS5eA43veONqqy5CPvn1mOCu9R3lZJI/LPJ3S8r4V2qFwdwlbez673EnlbnfN8C+dDx320juEeXJs1Y+4jv8eQtQe/f37/u+X7z5MPtGzRgGFxgoaMbwWmbTVfN9oFO9A652bqZKKWGxmaqRuVq21t1wli6SDOhS+ku6nr3hz96quvVlevXm0JYf1lFfRXiCx2s/qLPeUbf0WEqNLLGuXHbTueP5D0IDR95bexxr7mI2kt3zx/27a89ZgvI5iZAWurh15n54Orf2P1QTotz7ab7NpUB3edr2Mrfysju1fLs/H3mqe38q1NJpWXt4HPw92Db8NWO1o7+TK3UJZ/DukanM+flcvX7rf1TFx9gs/T3o/suft8ZdvaZkJ+VVb30HHfedl5246UU3gvcO3At6Wvk28fbOOzvXfvXuPPd91X/r74NvDfV2g/m5Q+q/O499CXh38tcBto/9z4/fP7323ff34/jd+OmnJz+/btxh1PS5SFTZSFaT8qrE2UlY2OpRqE0f8ZrbKqbKBWUp+970ysoAljP2ZeR224pQlDXYfqHn8x1LkAjr8yald4ffjw4RD/YchO3K5sW/dl7Y/l2PWWFjcS96v8Wl+Ov3mUadv4x3D//v0mL7tUj3hMyinl7fZT/h37pXoV/0n7+9T0latDc+jQoQp1z+vdVf/sHi2vvNiRuqAc/D7rSBtK91cq299TiVL7B/dsS/fS0aZom+JzLZSXnumk+hXqKW2I78eV1cqvdK3P356hP4c8gj4D/w4V2jel8+9I2PwVX2yj7FjreY97h3x7db3/heO+PaSs0j37fHyZ49qQ3z+//+fw/TeFZ9MSytGkLRoxBDL6yU07jucGr7322uDKlStIa33Ivi9ZNGEdqGV9xTYuayiIbUdTVN5E7QZpSQ4wST948KA2TViFcI0OcZ0/VVdv/JljB3/wJ//zat/Cd8eiVPcfP1eKEEII2V042Xjvm3/v+tvf/ffCULAOosxrouIpwjaap/tzc3OSNsrGJIg7Bm5tmqSHUaNagjipyW7KUtKGvUk6FlpjWlK0kVfRRt7q3P+WP/m/fuv89/zw/xmq+lsDIYQQMiM0Tf9r937h839w7R/+V7eCask6Shx9xQMIY2eiHmDwFkzUoSCE/X7ttGExs5kQ9v4wY0atK21ucC6E0WE+/52f/i8phAkhhMwaVdX7tkOf+tM/GTfr2PVqo6ttVL+MmcLYKUuuslOEKQZtKaOacaks/IE5+tKlS7KNgVrozEZ/78bGBgqTgnWEtJ/2UK38zM3f2jRHE0IIITNE09y59lNLrwXVerHonO++HmtiF+7g8uXLafBWFMLNhQsXUg7ZOk07avwUJg1taH3D1euvv149fPiwyqYq2bytKnZcy3bs7K6P/7WvfSM8J/7QJ/ZJ0f/4t58EQgghZAdo7vzlb1u+d++eCOHgBLJbIIwbL4zDUL42UXMOvV7PvG2JD48ujdiWtI9BWk+ePKmuXLmCSc0Sg1EncicnACqIV8Nz4ud+7Gg4c7QOb/ydO4EQQgjZAUQQiwCtqkFd14M7d+4M0Fcc+4gHmFuMEdT79+9vDhw40MDbVhidEpVGTuOPjaXOha9dIJ5CAHxIwyyNbfjkhLlapypZZtW4qRsfhTde2Rc+/5lD4bPftV/Wv3ztafh/fqutDR/dz8HYhBBCXhxR1tXqGCREIQxPXpVzhwqFVbp24W3LXda4fmLzsiVasp/j25QK9AO1Yt+wjJTGtvoGtUnbsn3o0KEwTY4eCGHlaC+tj0She8wJ3jdemQtf+RPH47k6EEIIIS8CzK92c/dT4CRYihFjwQHnHsH8cLh+YmOoEWchmURdVj+Z3tNIFVVtzJWqLCJF1IZljZHS5rHl/v37U1FPIWC//udPhJ/4/QfCGytz4dzS3HB9Eut9InyhIa8c64lG/IUfORLO/+BBCmRCCCHPnSjrzJmJLFErlgAScGxlsYghM4OOnNYpTN55VgqLCOZs+pI58lBnHrmHlQaqNjbMi1ZwvwTUs0lu2v5IQLBCoH4lmqEv3ejLsbXHjexfWx/EpS9pcOzY/LC4cyd70nf8t3/tUSCEEEKeJ7D+qhew5PUOkaYQsQldt/A/DdQL5cj1zoOlDJSeM4cezs20SDcXbzjoQK0A910az1Fia2IeFUZ+QQiry7WwXaAFf+6TC7IN7devu/jcl++Hfxz7jtcfN4EQQgh5nkBWqnla/GLXdS2L9hM36mtDBHHYnBI8gAD25mkL/jBnmYaQoi/BUXWNUE6GSvSk8aKw48eP11DHzeG4CuFta8TX7g6eKf27lx/LQgghhLwIHjx4IGvztW2Rm2CextQkKKzAa8NwFx1csAcfm7g2bdiFZarUN+aIKy50QkfTtAzUikK40ahKSfgePHgwbJfLNza2nBam6s//ysNACCGEvEBsppBEeLIIg9E8nYSwpgmvv/566zoEf5CNynp3myofNZ38TVsmGndYFgzUQiG3bt2SNIhFivBS6COGzTwb+PWRQL/wV65NFsYwQ/+pn78rwpgQQgh50bhIUQnEKdbZRSJTL168aKeGI6Q1ApMc0ClMrfjAJZxnkGAasV2DgNRhGEpKTNMPH05HO/3cl++NFbAYuPWHvriWBnMRQgghL5JoAbaBWg1M04uLi2Ka1lHTICm25o/DHfdpwlzeP4wTGvoQKrVNSJaT0fbdaKAH2cdk5izDqYyWghCG9yxMWTp7sheOzg9/L6D/mIOyCCGE7DQuYJLIyNu3b8sOlFWb5huGLqIb748DTj0wYMv3EeeacBKqmEuso6bFfSUiSiDYA6YvPX36tAcBDh/TR44cwTZGT/cQp3jlb3zzWiCEEEJmk+baX/gY5id539IwzyL4wwACWl1del/UPvjDSNAH7+JSNxvRht2oaTkHr1oAc4jhzCMKYRHS6CPG9VEINwsLC4EQQgjZA4wosphLfOPGjZF0sC5jQ6cupevUqUeVTNN60KYRtwqAh5BHjx5VNjcqbEp4IfYPN9FeXvsYxoQQQsgsghlCUD5tH6Om67puooLako3q0MMCP7SwoA8yWEunLgU9ktLAoYcBRx6ZEBZtWAdryaWYVzWtwVqEEELILqelsKKPGIO1Tp48KQpt7M6VYEnBBU9SWiOmZds8a4VsFFdoh0Os3bqOhSESU+/OnTvoI5b+YZyPmnH9S19/8kEghBBCZpPmB87MSx/xoUOHmij30D8sfcQnTpxoYtdt//Tp0838/PwgdukW+4ghhDGf2JTfOc04+be0EdNxwUivyo/2MmAHt230EWMOsQZ8qCa5oySEEEJecipMX0I8YniXhBwEGD8Fjfj69esNNOLYrVvt378fxxCFKcUgVnm7aZ62gVq5VpyNmhZt+NSpUzWmL3mNOAy15J6liflRIyaEEDKrQIi2Rk3HbtrB+vo6tGLI0aQRR2E9QB8xhLBGYGr0emjERdO07AcnjBFDEe67YkezN03L+vjx472YUR0Lr6NG3INZWvOjICaEEDKrNFHmrWCw1uHDh/v37t0TYby4uNiHLIVpOgwF7sj0pTCcmWTbSfbWFnXJF+JLdO65ggY8tviLjTr0sIAPeehEQgghZOYwmWkhEA11/ywzkWCaDk4m2gBoCfJQ1xb4Yej2MtOI0Tdc+Yss05WVlUq9hRQDQqCfOKrhnL9ECCFkpnn48OGIDHSjprFfme+NoMLYRzR0gR82NWKfGIO08gJCW9MVjRh+NW0fjq91sBYhhBAy82TRBpNMNIceOlgLmyJTvXILoBWnMVqSqq0V+0AQxelLJ06cqNXFZc+OxUrZFCb2ERNCCJlVbLCW9BFj5PTdu3eTm8vl5eXBvn37BteuXWuiIG6uXLki/cSYS/zmm28O3nnnnUY14hShyYdBNKHbaABjSHBJpFJdgNoNO7i6uBSgEcOhR1yoFRNCCJl1RFZqPGJ/rIIbaDjA0j5iCyUsU5gs2IP2ESenHi2NGAnUx+VI0IewKahFC45qeNXv93tu1DTmVdXUiAkhhMwwI9OXQjv4A8ZU9aER4xi04Pfff1+uC5vupAfOk+XQDJ3mMm2eqaxj2aR5UEGsHdHBa8TwNR10KlQghBBCZpiFhQWRh7AGA3X3nMZTRSEsazj0iEI4l4uN9g+noA9JI8ZaBXINbRj7phHHzOpHjx7VyDwK4jp2RpsjD1ncPGL0Hb+QMIiPNpq4DLfnYskH5ipZE0IIIc+RpBE7F5epjzhszh0uziMOm1pxEtwtSe1N00EdenzjG9+ozXF1UBP10tJSffPmTfOo9cIcetx51IQP7vbjOoSNwehMqcPzVVg6WIXlQ70omAMhhBAybRBt8MzDhw/7USMeuMFaI8L43LlzgwMHDlj0JVkwUKvX67V8TeejppNnLd9HDI14Y2MD86LSqGl41cJ1a2trEMYyYjqq670HDx5MXSOGAP7aWl/WW+XV43V45UiPWjIhhJBpkkZNx6V/5MgREcbexWVwWvHrr7/eEsSWR7MZB3Gzj9jFEm5Ju5iJhEF0k5PFsTU8a0UhnI7BAXZ4DnztziD8i9WNZxLC4Gq87uKHG8l8TQghhEwRUV4xatq8TAYXJlj3ZW1hEDEjybm4lPNQaOdMG/YjuJD40qVLsq0uLv2cpxA1YghjxCOurALIA1OYpgmE8NW1fviooB8ZQvz3Lc99JFP1X/mrPxN+46u/GUibv/qXfyp899nvCIQQsheBMw+Vd3kI4QrziFdXV2X6UlRgWxqkTl0KmeJbzZlJWvuHQxj1oiVrZPr48eMKdu1+vz/i5hICfZouLrcrhA0Txq+fmqOZmhBCyLaBEHbhf2GGDsePH4elOGAecXAar1NmA+YRA4yaNjeXsq/rlkYMMH0JoZtsP0p28TUNSa/xiCunjlvlpmKehjl5GkJ4M79hHzMhhBAyDWy2EeIRAwjh4PqAMa4Ka/QRF64VU7Q59Kj9CZ3TJJ61zC8m+oi9v0wEPV5aWmog/X2++IWwsLAQpsHzEJrX1gfP3M9MCCGE5Dg/04151lpcXExCeGVlBXOJsS0asXqp9FQqc4fRl/wJlc5y4saNG53abdSI0/bhw4erqKL7ecjbAtrw70p4x+mzeo9aMSGEkO2TjYmS6EsGfG7E7lzpwoUy6+UpIhxaV3CKvqTnzMVl6vt97733ZG3xiM1vpkaWQDxi8SaCYdsajzhMY7DWzQfPRwhL3g+bsPH8sieEELIH0G7YpHhi4HJoj69qMNPo7NmzIkOjPC3mY5615nzkpSrrKFZhXF25cqUVChGm6Wj/Npt4qlAWFuoj8c2Hz09SQgjfe9KE4we21pX9V//KTwVCCCEko2X91fFSDeIRw2JspmmIVGjEap5OMYlz63GtmrDFIvYOPTBYK5fyUhgKUiEsmL/NaQzWgqB8nmDgFiGEEPJRMV/T+XHttq3UNC0ar1mVDY1uWJniK9OHfeQlO6nziOFZy8cm7oV2JKYUixjbiLwU86i361nr/a89Dc+TbztWh1eP9wIhhBDyEYDQPBPXffM1fezYsf7a2trgxIkTza1bt/qnTp1qPvzwQ+9zesTXtOaDaUytPuJUigphSQi1Oqj5OWYu56F+5xWLApiqJiGEkJkHPjPgTVIjD6apTFEIyz6m+o4hdefqNKY0fSn5vMSJc+fOJakNtRrTl6LNu7LMdR6xDNayOVSo1MOHD8N2QRSl5wmdehBCCNkOGJgM5dNmDIHFxcVSUpGjcHFpU4KDasI+DOKcmaVVJUaCWi8WEzTiEV++fFkujhpxhUFaN27caMyLCEAf8b1798I0gCvK5+kf+vA8JTEhhJCPjrm4NI14fX29gSCOpukKsRhyMGraCeLKHHoENVVb0IeUIDjfmfCsFYVw0o6hEbvpS3IMGrEK4amYpo/tf36CEtrwVkdME0IIISXMxaUH84idEE4uLn0ajL/SwA/BRVqqLIbwiHSC9HZzn6oscxHWME3Dq4iNmg5TEMYfP/z8BOXSArVhQggh2wd+pp3ss1HUefQlG2fVYNwVZO+FCxc2Iz4MZXGDmESND/aAKUw6jSmBPmKEQkSakydPJi8hUMexVo24OJz7WUEfMbTW5+GO8tuOP5sg/t//wS+E3/ngG2G38Zf+7B99pvT/zX//xfAi+O7v/ET4w//+J7ec/jf+1W+Hf/QLvxx2E8eOHAr/2X/6RwIhhIwBHiUHkH2wCqubSxHCFn3J0OlLIqQt6INZoa2v2IIDylG1Wwd/DOv5+XkpAKOm3Wgw6UfWSkjaafma/r0f60ks4Wl6wfr4ofq5DwQjhBCyNzBLsvmaPn78OLpsBxp9KUmvc+fOYayV7JtDD5eHyNw53QkakzhptRp9CYU0UaKPqJJaaMovDDXrqaixEJjfdqwXfuv2dHxDYwDYs2rDhBBCSAepf1eV0UbHTZkQFg0YLi4vXbrUYEpwaPcbtz1rydG2AE2DtdBH/PDhQx/0GNGXxMWl+Zq2XwOYvjStMIhg5Wgtwni7QAj/vuU5asOEEEKmBgZsxT5iib6kvqZBS8Bevny50j5iOYeBWohDrFOFk1adSye/bx60qthHXMc+YvOqNbLEyohXrdh53YvrbXnWyrl6Z/CRwyJSCBNCCJkymD+8EgWxeczq6zKISurg5s2b4k3r1VdfHVy9elW2MQNJYzeI5bjf74der5eEsmjEm6OoE5Wf86RBH0LIpD00YoRBRIe1RWCaNq9Gk/L3vzInQnWrYJoStOnXT1EIE0IImS6w/ur0pdY0JXV2JccQfQkDnR1y/K233qq8EAb5PGLZjUK4sj5iu9jCIGL/xIkTsqERJ547EKbf/8q+cO7kXFg+VHd6xzq2f9i3DMENAT5XUwgTQgiZPlA+bfoSlNKQ+eEApsTGLt3WcedESzDzc9KKnYtLGw2dBnDBsxa2vecQaMNamecu9ZYOVuE7l3rhU2f2ibCF2RkLtj91Zi78/o9TABNCCHkhVOZR0pRSjcPQrKysiAyNGrENfk5WZp1H7IM/tFThSqU0nHnUOszahLD1B9u+RF6KvwKkbzgKbIvEhDw+CIQQQshsApPySlwPLPpSGI6U7lv0pdCOuNTqIw5tx1hCnWWONczSjUlvP+IL84iXl5fTPn4FYMSY2co1RiMhhBAyy1Q++pKapkNd143KyNYoavM1raOmUyY2crrV2+oHbZn3LExf8h3OMZMKfcQu0kSqzDSiLxFCCCG7GTivsuhLmEespunq5s2bct5CBgfXZWsuLqOw3vSaFZVf8eFhB1znsZ83nE9fgovLXhTSI1OYYoUwfammaZoQQsgMY9OXZOpSFMSDaBkW03RQU3S2NNkCeTuAQDbtONeIW9OTMGoapmn1Mw0qhED0aTB9ycdkJIQQQmYZOPMwzKlVaA9YTgOxfPeuraHzYvqSJIgasc0jrlRFrkwYRyFcwa598eLFESEL0zTiEcMujktgmtZ5xBTIhBBCZh7EJA5O5sXuWpvaK1OVbMqvBn1AH3FrcLSZpbGTXFyaMuznFEdJDmmee/uQ6UtwcZnNI6YQJoQQsheo1DSdtFyLR+wGNMtxpxGHfr/fmk9s2yPTly5cuIAwiHZOBDX6iDc2NqqrV6/aFCabroToSzKFKarZPXgbYR8xIYSQGSa5uIxds4OovKKP2KYsWZ9wa1unL6Xh0ugj1jFZQ/O0Hqxc4AfvxMP6kNM84ijtq9XVVWybMO658/W0fU0TQgghuwiZRxxN000Uxl4AD6JpetDr9QY3btzwA7fAIJqmG4ychuB2U5hEQ/bRl1petACkuC8cfzTWokny/PxUwiASQgghuxX0DxfC/sKZR4MBzSsrK3Ysab0QwufPn2804lKjfcTDwVoWhilsDppOmWOwFig5rkYBCP0UTdMmgNlHTAghZOZxo6ZlHnFO7AsWeWiyU+M2BBstbWZpHSBd1V6qm2ct7SNOh/HHBX0QMGraDdaSTHUUGSGEEDKzwCx9//59kY06fUmU0WiablmVbeqvedZ66623mrqug8YjllHSrelLQQdrQQhngjiFdHLeQhqMmrZKqIvLys+tIoQQQmaRKOts/FTjNOKk1H744Yey9hoxTNPmxMOsz2aRToO1ZMdpxHER4Xz27Nn68uXLfvCWjZqGaboXteL68OHDMnIaS/yVwFHThBBCZhUZrBUV0EGUdzJIK8rCQZSFg6Wlpf7NmzdLI6dLS2JkPpO6uqzdMR91SYRwLAw+NUdGTi8sLNTxlwJHTRNCCJlVuqIv2SL7sTu3iZZkE8hJADsPlhZoKXiBO9xwc5sKSLoohEcGZqF/mEEfCCGE7BFSwCMAz1phc+CyyMhoUR6RpegjHjmmHca231j/sAuD6OcXp3THjx9P++gjzryMEEIIIbOKyL/YLRvQR2xhEIMLf4hxVdqtm0ZNy4lhBKa0LeO18oxD1kesS72yslJjSHbshB7xroU+4nv37sk+HXoQQgiZYbpM0/3YbTuIFuM8AlOrb1hN06I526yl3MScC+Mag7WePHlSPXr0qL527ZrvM5a+Ybi4vHv3bs+ObdfF5dr6/TBNjh09FLbDtOszCdb3+bLd+n7l2kbYrZw5WoeVo3X4qDx6/CQ8fvw0vCj2798XDuyfD4S8ZCRBHAp9wydPnmzm5uYGUWkVIRytyoOLFy8mQYx5xKoRJwvyXMrZRUBEN7FqxImYcdFZdRTCsoZ5WiMwbYvf+OpvhWnyqe//3rAdpl2fSbC+z5ft1vfHv7Qedis/9f0L4XOfXAgflW/cuB2+/sFqeFGceWU5fOvKciDkJaTya5ime71eQOAHCxUM3xs6WEvQiIbNO++8U6mvaZO7lc0jDs7dlpijrY842rhlUjLs3WB5eTmN+HJrmdy8sLBA71qEEEJmmoMHD4qz6NgtK3IQzq2cl0rQmMxEGET0EUMIIxQinHqoRy2crpJDj6pqy8+oDYtzasvQnzNf036wVtBfBRw1TQghZA9QwQp87969YA49vJfKU6dO2ahp2TfPWlGujpilIcBhmq5UI04aLszSqka3Crbz+APPWlDHs5jE2+boNvvwps1uq88kWN/nyxuvzIXdyplt9A+DA7HP9kU+D5RHyMuIeaPEqGkDZumlpSWZ3osITC65yE4I4XRg09f0SBjEZKKGIHbCOIVCjFK+1lHTddSI6yiMU/jD+OsAXrW2PViLEEII2cWkeMRxexA1YsQjHkSZOJibm8s9a7UceiD6UuwjxoCtlgZdWSxiE8Z2PArhWjVijJxGX7EI4o2NjTp2RqcpTPEXQS+q5xDEmNzc4/QlQgghMwwCHJ2JXbE2bQkCNU1hwn6UlTJq+rXXXmuuXLnSEsaQtxqBSTRjCOUU9EGls0hoTF1yZukG05dsJwrhVo1gIwcWiYIQQgiZZaIQ9h60GnTTIiKh0ljQBxXCjTn0iBqxWZ5FXkIgh5BNRzLTdGj7lpb5wa+++mp19erVZIrW4zaP2PxNVzRNE0IImWE65xGfOHGiuXXrlp9XHELm1EM14pZp2odBbPz8YZ2+lAS1DcW2ioRh9CWLxTjOPzUhhBAySyTZGLtnK+fiEnh3z3Do4Y8neWvupVsuLvM+4jDsJ8ZgLfOi5T1q5Utyd8k+YkIIITOM9BHXdd3PwiBKP/Hy8vJgdXU19QvDsxYuunjxoteMxfpsfcUyF8OCFGshoiXrnCcEfZAJyRrSqQpZLEX8GtB+4mZh4aN79SFkt7Gb3Vk+C2+s7N4pV4S8jKCPGPOIg2rGama2fl9vIW4gP92+CeBkmhYluGvUdGiHSEya8MmTJ23U9IhGHH8lVGtr6+wjJi8919YH4af+yb3wsoO5xZ//ocOBEDI1mn375tBHnEZLq0ac/E2HbPpStC438KwV2gEgksD284hbcRRDx2CtDkGchPHt2+s0TRNCCJlVmtOnl71p2k9fSlOYoszEvGJMX5I00coMj5UydQl+qfv9voVDbOpMCEsPssYkLg6+MofWNlQbpmnMIUY4qEAIIYTMODBNuyBHrbgLQTVdDHBGnAZ079r0JZWtNoXJQiKG2ru2xJ/MPA1fmdVrr73mR01XJ06cgItLSY/+4UKFCCGEkJnEAhxp0IdK5xFXcHGZIX3E8MuBMVeQu9CGLdqhyVtvhm5CwSwdpXkVM/IjpmX+cOgYNU3TNCGEkBmmWVw8eiauB1EQ96MymszRwZmmQ8HFZRi6uQwXLlxoac82IMtGb42UGFVw0Ygd+ZxhHwyCGjEhhJBZB6OmGxf6sHKetapTp07JhpOdJhsrFcJB5xDLGC0frsX6iNMB2LWjCt7Mz8+3BGw0TadgyEeOHPGSnW4uCSGEzDzokvXesYzl5WUMxpLj6CNWksJqAZZsH3/SFCWdv9SKTQy7NjTiy5cvSxqT8gDSHyEQnWctQgghZM9x7NixBqGBwerqanXt2kgPbaXeKo2kIUOY19lBOYE/dhGEcFSvxRxtjqw9CIqsHdaEEELIzKODtcyZVVhbWxMZubS0lASsSy7nMFjLB31QpVcGTifTtGnCNn0JFxkaQSKsrKwM1ei6ToIXGrF51gqEEELI3mBE5t28eVOOe+uxTxf7h7GqvHlaLNE+4IMLzzRp1HRrpHTUiOsojOnQgxBCyKyDUdMWfSk581hcXOzHvuFBFMYjnrWCc+ihc4dNqd2MR5zmMm0K4WSajkK4NGq61ScchTCjLxFCCNkr+HnEoLl9+3alfqaFV199deSiKFcrHYtlWrGERZxT7x7BDkoJfsRWm+bkyZPwrpUOoI84mqdxXR0IIYSQPQK6ZVUGDucDx27bKCMr80CppD7isDnDaOBGTreCPrQ04tAO9pBv944fP17fuXNnxN80TdOEEEJmGHPokfuXHpw4caK5deuWOfTonz17trl8+XIe7CHYNmSumKZtHpRTgkckuT+2vLycTmbBkAkhhJC9QPJECY3YtqMQFo1Y08jUX7iJtoswEBojp21MlpmmkznZBm3ZPvqIEboplOcIY85Ug3nECPqAAwiByHjEhBBCZh1MX7JAR+pLI01byszSQTXiNO4qCuKR8VRVx76YoqMgrt57770a84g3NjYkDGIYDX841TCI11e/GXYLp5c/Fl5mYPIYDDiGjhBC5uZ6YUr4UdOyWDzipaWlfjZquuVn2i2iFeN/tNRtXGnwrAXg4vLKlStdA7im6try57/8S2G38JN//EfDywge7tONjfir7UB8dvsCIYTsdR4+eBSiQhn27Zvq/0SRfbAOA8wjRvft6uqqjJqOyqucf/PNN5v3338/BVeCORpxia1LWASxDthKOWOItXfoEVXramVlpUIgY/Wu5dUsqly7jMdPnoblb/lYqOup/T4ihJCXmgP758O9+w/Do0ePw1xve9px7IoNDx48kNHPiLcA+RmFcUsWInQwpv7CIZYK4YGeSjOVDD/lKM1eOnfuXOP8YjbIbG5urhW3GL6mNehDiLZyqRjZefCLb/H4UQphQgjJOHxoYSrm2yiEg/URRyrTiIOzDkMjhhB+/fXXsdtY37AbqGUOtVqmaT/BuFVXRJCARqwRJWpEX7p165YIYiRHFIowJc34Ze+X3Wn6/UE4cGA+EEIIGQV9xc0UpFWUeyInMVgLshDCGL6mEfQhHm6gEQM4xYIwvnDhQvX22283b731lmnDmxOJbR6xbos0xhDruHhXlzJ/+NSpU3U0Tae5xDgeNeI6VqQXfx1AIGOw1geB7BiPHz+JfRT8MUMIISXW1u5uVxDbYC3EJB5EuefnE5eW4mAt50BL5hHLtrNZS9AHZ5pO05os+lKU+ps10mlP9uuAEEII2QtAidV5xAI0YnifDCozNXIhpgInmapm6ZQF/tRh08OHOaMWjTgvz/nNbG7evJmE7r1791KOGhqKEEIImWVkHjFcXOo8YgDZKNEJY1euHEC3roEB0JCtEvawtjAP6lDLZ+zcXIIaUhw+NBF9KWZcX7t2zczUtXNxKSbqgwcP1rEDm9GXdhiapgkhpJspmqbF9Bw14kGUk97Fpbi8jMprg0HOGkY4maidSTrVwgZrmfCVE+gfvnTpEpxUpznCUQin89m6KRwnhBBCZp0KGvGxY8eigF/DIGaRgdCIbfpSDuRwr9cLfgrT3Oa5oTbsTnrhnDxuLS8vy6gwuLgMw1jEFcIgYjg3pzARQgjZC8CtczQxD2CehhAOm/OEg1qPTRsW0EcM87Sapc36PIxLjD9+xpIP/gDTtAE1G8fgMQTTl5AUQ7Z9HzEhhBAy62A8FJRPKKHYjxqxV1ibU6dOWdIkbL2F2dLZfGJz6FEUpnBxiflPUK+hZsfMJSOo34uLi42bxGyeRgIhhBAyyzx8+DB1y2LUtGrEMmoaLi5thhHOq0MPaMSS/vz58yODmv08Ytl367REQVxHFbuGIN7Y2Khv3LhRCvggA7m2O4/4X/3mb4WXkaWPLcblRNhptjtY6xs3vhm+cXP3BN54Fr77u74jEELIOKY1WCsqn01UPkfmEJ88eXIQZaSfQzxAJMN4HOOuimOquoI+pLlP0IrNzg3PWgVf0/6abU9f+q//xv8QXkb+yH/wmfAfxuVl55/+s6+En/3SPwwvI//gi38zEELICwCm6VyBbclFTPmdm5sL+/fvF/O0xm/wAR82+4i9Vy1H2lG1Wi5AB7ROVk4C1+IRE0IIIXuB2EeMVRPln6yxYOoSTNNRG07pMI8YM5DcpTZ7yUIgDh16mGcsHTHdUpktDKKBDmhXiKTBiDEEfXCVI4QQQmYW7SMW1LMWxk7VcOgBICvN1zTIZWk1JIncOdtxU5aqrMC0D7M0NOIojGXqkjq6lpymNVjrO7/jE+FlBH3Es8C3LH2Mfa2EEDIZTN21bev7FcU2ykqvBVfoI/bC2M1SanvW8sJYHXpUUeBW8eIU9MGte+pZq4q/BnoI+oBzUSOur19fpWetHYSetQghpJspDdY6E4aDsfrZurHBWrGPeBC14pZXLbeIvIV5GsI4DdYqBH8Qzp49W12+fDlJ+qBzj6MQRugni8PYqEbMOcWEEEJmHT/62Txrybb6mrYwiC2HHlGeSjhEN2BreI2kHAYolgM4YUEfMGrahLAGfWiZrf08Yu83kxBCCJlh/BRfm0csyio8T6pnrZGBzFEIQwveDL007BtODj18sAeLRZxs2ubQA+io6ZEKaRhEjqAmhBAy6xTjK1iIYOdZS/BeKqPGnOSkmabrQsboIxYtGBdj+pL3l6mjptO+Dt/O8yCEEEJmmaa0j3gM5m8DpugIxloFnUecX9ckjdjmEmMbZmkzTTuNOJ+wXMHFJTYyX9PUiAkhhOwZMH3JfE3fvHmzgmkax9GdG7t2k9MOA1qwjcXSpWl51mqG/i6xmQTqxYsXfSgni77U3L59e0SbhsuvQAghhMwwCPpgIAxi0P5hOPSwucR+HrFHTdMtWVm7gVo+eoSM8FIqeAfRwVqQ5qW+YMn4wYMH1IgJIYTMNHDogVlC9+/fTwIVVmIVwjJqGjLTxyN2MjVh0ZfyecTjgj5UsQO6jrbv+sSJEyLA+/1+b319vRUAYrtBH66v7r6AA/Pz+8LS4tHwMsB5xIQQ0s20gj4EDfIQTdODqBXbXGKbN9w5j9i6fuM6xS8W07RqxGO12SjhMSRbthEGMejUJ6U1lHs7/PyXfynsNk5Fwfajn/mBQAghhMA0bV4n1TQNzOQsAnVjY0P2LV7DJz7xCQn8oIOhW5gwTaEQm46fCnNzcyPBjuHi0oBDj8BR04QQQmYci0d86NAhEcY6WAtIPGLIyqi4yjGMs4qLbJ8/fx6rliUa1mXRiJ2/aQzWqt3IadF8MX0pqtmVC3Ysl5mfaQR9iLZy+ZUQyEvN2t37YW39XiCEkN3Kt76yHHYSi61gfcQQprGPeHD79m0bNS1mZ/QRY4wVKE1f0t7gZm44ULpqXP8wbNgVOpbhazqq3U2U5nVekePHj8vALXjXghCeFqd3Yf/micVjYa/wG1/97fCL//zXAyGE7Fb+0p/9o2EnyQMcqZdJE8DJJbT3wQGgEcO7lmLhlyoffak1ahrS27yBeKluwNc0wBwqCOuoFbdGkH1UfoR9sYQQQnYxmKoL3VWV0NZ0JJimo1Zsu1XsI4YyKztOCAObLtzUqhGnM+reUoBDD2Tgpy9ZBlZwFMKSXl1cEkIIITMNpuo6mTdAAKQwnEechDBk5tmzZ5MQNizqUnCKr2nEySydO/QwbHKyOvSoo2m6glYcNeImCuN6WvGIyc5y9OihcOaVbwmEEELKYDxUXdcDaMRRBiaNWOcRy77KTK8ty/Zbb71V9Xq9xjnQCn7esB5vzSWus+08HrGfQywxiW/fXmc84h2E84gJIaSbac8jdovFJB6srKwMMGo6dutaP7H0HWPs1c/+7M8OohAfZqR9xBYGsVWKTTgOTpKbafrkyZM0QRNCCNmz6AyhkixMxyAz87FVAPGIdbMxX9PDnuJ2P7EUAMn97rvvoqO5wqhpTF+KqnZLK8Z2VMtrmKb1eI8a8c5CjZgQQrqZhkb8yisfX4ldsTZCGppwH9OXosl5EM3TybtWGDr0GOg84jS2CsLXQiDKfspZo0FEbB5xy80ljpuLy+BcWgZnlka67bq4JNtju4KY84gJefHs9LzYvcQ0TdOHDx8eRLlpLi7FPL28vAzTM0IhmqAefPrTn27ee+89K3Xg88If04hFCDvNOAlfuOfSecQiaKNpusb84rjdO3r0aL2+vp6EcKBGvONsVxBjDjHnERPyYtnpebF7iWkI4tOnl89EYdu/f/++7x9u8u2zZ88OLl++3LhzIWx2+TbmXjo59JA9HUHtnXtEIZy2o0YM71oNgj7cunVLDmLUNFRsHcq97XnEuzHow1Y4cmghHDl8MBBCCJltHj58KB4lPXBydefOnZYMRDxiN4/YZCQELYSyyd5mzglfkc7oSIZTaj+f2DAXlyaEcY16FJHCp+HicjcGfdgKr3/vd8Tl9wZCCCEzT5r2G83T1b1796pcCBv5PGIbKR02Zyo1c3YOJyCEz58/L/6m3XVJuMKRNSJK9Pt9EcZRE/bTm+RXAnm54TxiQgiZDOIRYx2FsARAQuwFOPSwmMRu6lILyNm33nqriabt1ghpP1CrFY84djBXsYO5inbuKqrYfrR0Vx/xtuMR/49/9/8KLyO7RSPmqGlCCOlmSoO1zsR1H4O1oiBOc4mjIO5j5PTq6qofOR3UPN23691aNGPTiM0+3fI3DReXtq/xiCt3sTi6jhWRDKGahynEI96NQR+2wmH2DxNCyF6hOXjwIEzSso0/6CNWbdgjgSB0+pJYnHUeceunQAqDGDaFsZzQecRWCISwDdaqTpw4UcE0beo4zqPjWv1nbgsGfSCEELLbgWk6KqLSyYvAR+5UceAyZCqCPrg5xCH46UuyNzRPe602TWHy2376UijMJeb0pZ2FpmlCCOlmWvOIEYEpCmNzaynraJoWhx7RgtyH8hrKDj0shrEosRDMabCVziOWHe/iErZt28FgrSiEZRtqOM5jxBiuR9AHQgghZC8AjThagiuEAg6qwEZNt0JgJO3GFfJR08HFIQ46ctoEcRK26lVLtjFYy2eCOcQoBKZpjUcMG3mjlQqEEELIXgDdsffv30f0wXDs2DGRg/ColSWTfbiKDpvWZhsxPXTa4aYvVW7kdGvAlstMMlpdXZVzOnkZDj2Cs49v26EHIYQQsttBCERoxFivra2JXPRhEC2deqcUk/T58+dl+lLUnBufLk1fUnIXlynoA7bhaxqqN+IRh81pTHMwT8c86lihmr6mdxb2ERNCSDfPwdd0X5VR6Scu+ZoOwxCIzbvvvpv6iCUj6yfWneI8Yltee+21Go48rl692ppH7LbToC0K4p2FgpgQQrqZVvQlBHuAaTru948ePTpYX1+3gVtpsJY69fACOeXh18k0jQNwa6metVqlIqaixiNOJ5xfzVx4E8dvfPg0rD/a+rSuH/j2/YEQQsjuBiZpTF/CXGJ19WzIYK0oMxuLR6zasJmiR7pyK4u4pFoxTtR6YRUvtMFcyTQdNeO63+8j6MPI1KWFhYX6+vXVbU1felmDPhjmkOTrdzbCj/3PN+O6/0zXnzneC1/6k0txPRc+CtSICSGkmymappM5+tixY/3YTyz7J0+ebG7cuGERmJJp+tOf/nR48803B7GPWJRd7ScG1Zw583DCuFUgzp09e7ZBFAkL+nDixAk7J9ivgocPH257sNbLGvTB+Mk//qOy/gt//84zC2GAa3AthPFOgZf0yYDj7gghuwuMNd5X7xrDK6bvwtc0BmuJlRijoaMQLppAEY8YwhjOPN55550U9TA4F5cmjGV+04//+I/X6lXLRny1zM46RLtWz1pBo1AkbZqE8EtXH4ePynau3S79+ArdfNAPfcphQsgu5Mh8HY7s31lhDL8ZDx48MBeXghOscAkdonkam/DFIbOL4DLapgdb1EO7rrYdD0Z2IRQitjGPGBpxGMYjbqUzuzhs5YH9wy2OHvjozQHz9E7x4OmAQpgQsmu5/3T7rpS3i/rNkP+UELLRNB1u376NqIRp3JSNq4IM1bgNIbRnKqX/tHNePfZC2ccjhlnaMoj276AuLhufsXrW2va/8Jc16EPOf/HvHg1v/d9r4aPwp984HAghhIyyW3rN1KEH/Gj4AcugUW1Ytp1G7GveFH1NG1EA17r284hlihIGa2nQh54O1vJTmaYSBnGW+NlffRCX+1tOf/RAHf6T7zsUfvi7DoSPynYHa919PAh3n1AlJoTsXk4f+ehWw2kM1jp9evlM7KLtR0GcQiDGPuLBnTt3kt/p4AZqZUsIHdOXDBHMztd0q39YB2tJ5KVs+lLyvBVI4j/+voOyEEIImR1gSdYuWfMuGdTtswhW6yOO3bqwKEs6F9FQ0pkjLWjGI4OrMl/TlnGj9m5haWmp0UKDOryGaZpCmBBCyJ4ApmmALl0MXF5cXBSFNHbfVv1+X+ShdusKXgjjj/qZbnnSGtnWecRiblap7ucNV7FQzCfura+vMwziLoKmaULIrLPTpunMxeUgasTJJN01j9iWZui8wzRikbtimvbzh9E3DI3YS+8nT554zVmmKd2+fVsuULW80uHcgew9rt1+GlYW920p7d/5xdvhf/mlO4GQEn/rj50K33X6o4+RIORFYtOXdCqvyMQohFsBHQCsyxjoDLmqWnBTbUrjSgSxd+Kh05ZaZmZzcXn16lXZh0MPZIDh2rCNI1MI4YWFhUD2BnDbCaH69///9fBKFMLY/+S3L4Q/9+99TAadjbvu2p2NQEiJ9ce0xpCXgspGTTtEdi4vL4fV1VWTmfJCY/oS+oiBRWAKbuS0zCO2OU3WeewHaxkQwphHDPs35kpBI8avAKsU/jx8+DCQvcGf+bvXJWbI+3/x28MX/9RK+Pk/+63h6EJveJwQQmYbEZbwrIXog+pTo8L4KUQohKw0xRXTl4BZmaMQTlGXdEmDtczDh6wuXbpUmfT2YNR0VLtT+lh4MQgymW2+FLVgmKL//B8UV6fhL35pVdZ/Lu6fjWbFL1++FwghZJaJ2rB41opLo0ppg3jEME2bO+hQnknUmHk62PQl8zXtYhI3fiCXurhsZRIyZx6qok/FxeVuDPowP78vLC0eDWTIr/z2g/Bjrx9L+z/2fUfS9me+61D4P6Kg/szZslOSP/GpxfBj/zbbkpSBVYWQl4Eo90RWFqIvgcZM05n8FF/Tdd0WlXMafcmHPqz8FCbLNAyjL0ErTuq0+Zo2O/nBgwdnMujDqeWPhR/9zA8EsslR5+v1v/unt8InPzGcL33kwPjfYug/PnqALskJIS83vn/42LFjDYQrxk2h+9a8T/p5xIYK4dao6do5ny7OA1ZpjtiKwanbLXQ+VQUn2IHMPN91an/4J18tewz7hWiWxqAtQgiZYVoyc21trbKZRDBNWx+xF8Lnz5/3lmSxTqsS3IhoVmGcTM5dg7VWVlbkPDqk7Tqs9JeBN1mTGQZm6V+IgvhX/vVwcN7f+uOnZf3L0WT9pV+9S9MzIWSmUetvCvoA4NAjykbZNqX1tddeS8JaR0qbvA26bM4j1pOyQgpccOnSpTTKK2YmU5jMWwhGhWGNXwGxEs3du3ebWLF6Ghrxbgz6cGLxWCCbwLT8N//YqfDX/uGN8N/+v9+U6Usf3H4q5/63n3hl7LX/8usPwr/4OuebE0LK/L4zB8P3ntndroFV1lUYNW1TeCFUMVgL05d6vV6Yn58XudlBS2lNglOdeqQoEvCsBTv3e++9Zyq4eNCKhVRPnz5F0AdMXzLPWj07T89aO8uL9qwFZx4f3NkIrxyf25JTj//vX9+XhRBCSvw7335IlnHsAs9aZ4IGe4jKaB8BIKJiagEgvDct8bD16U9/utHoS8maHBXaNDbLa8R5KKc8hqIcX11dTekwUEs9a+URJcgeAcJ3q161CCFkVoA3ySiAG9WIPd61ZcvDFoAAxoAtN4Vpc7qRn76EPzBLa9AHMU1b5lEjTgmdQw8Zyh0IIYSQ2QfeJBtMXdI+4ur48eOmsPpFpgA7pXZk6hKYKxTQ0ojPnj1b6civXCMWhx6oBOzksUIMg0gm8r1nFsLvPUVfwoSQMvvnXi4xYhoxwgJjIHPsJ24wsBlhEM+dO+f9TVdqnq5MKzaSmdlcbtmgLRd9qdVHbNuIvnT79m3rG+7p8R77iHcWRl8ihMw6uyX6klv6od0/XOov9ktw62SabnROU9JqXfSlEJymixFh2MfEZWBDt0PBFk4IIYTMKK3QwVE5lQ3tvk3C1nxNp4RRzNr0JaNlrI4nTHJLAdZH7EFUCajfag+XEIjRNN1yeUkIIYTMOEmSwrOWKaeQkcHJQjjFgixF/AZEXlJvlq2ohy3BaQmCCugoyWvNKJmkdZ2mK+VLNE1/EMiOsdtN05xHTMhs8yLmAe+0afqVVz6+8uDBA5u+NIgKqUxTikpqP/YR5yZq0ZCjIG6ipdlCHQ40L3ExPeeEb1KZL1y40CACk14kwtjHI7bK2MahQ4fgXataWFigRkzG8nijCXcfDQIhZDbBNz7rwKGHi0eczNDm7MoGawELnOS6e0XoQt5i0BYOpD7i5IFapXLWR5wLYUmaNoauLhvGIyaEELIHaKB8xnWF7tmg8vDWrVtYVRDCUF7h4jKPvpSxGfRB9oYOMOWM+pquYNeO0lwOIlN/YSnDqBEHQgghZI8g8lF9arQGLBeUVwFhEOXCoTfLYTxiC4MouQyVYRus1ah7y5FMda6UdFCvra1JPEZAjZhMgvOICZltXrZ5wB8FdMNGeTdQHxriU8POnTx5Muzfvz9AK56fn5fjUGpxHJbmuq69wJbtORPCQCW0nRTMvg00HnEaVY2gD1ijjzgMVfVAyDj2z9VxCYQQ8tKiSmeljqxke3FxcWAjp43Lly+bUusPd84jHuakg7V8Agjhs2fPyr4K4QBtGCGfvItLtZcTQgghM412w7ZC/6oQRrAkDNSqXHduzkhch9riIYbhgC0f/EGARuyCGydPWwiCjKAPAJowHGAHOvQghBAy40AjxqjpSJU7tVKnV41250rkJfPJoaOkG6f0CrUGKbaAxTJQC+4tsY+L1Swt+zBNB/0VAI3Y1YsOPQghhOwVrCtWoi9hvJTKRPiRrk6fPm0aMfxLi+UZDj20fzgN1NJB0pX01jklWDLS+cNVZteGaVqSLy0twTyNXwKVObxGfhw1TQghZNaBBRhy08ZFYdByGCqiMiQa4RFNI45duyGXpUajo6XTPGJdV1EjbnT6klFpGMR0LfqIgYtDHJyJm7zEHNjHx0gI2b0c3AX/o+DQo2twsvUR277r2vWkQc/YFo3YT2ECURAn0zTCNs3Pz4fQ7mDGCLHkW1M9a7U6rsnLyb5oOVk+1AsPN9pOyQkhZKfpxf9Pu0EQh7YgBa1R086zVvX6668P0MUL07Q5yoLANa9a2J1zmQ43NicZJ9P0kydPUoGYC9Xv982DiERfgmYMYcx/3LNBL9pJDs8zvDQhhEwgabUYwIxuWwhZ1YiTchqFsXT5KqHXE1/ZpgA3te4Nc1JBaoO1fEE2FDuq3cmNF6YvaR9xxelLhBBC9hIu8iCQbluYpkM2BTguCPoQnI/p4K3QJc9aQTMRF5fQdmMmJSHb2PQlKxR280AIIYTMMBisFeVd8ioZldIKI6Ln5uaCjqEyjTh50YJZGmEQdYqwnNMYD8PBWhDGNtgKx22wFlxcqhD2nkCSFIdGrHOoKlSMo6YJIYTsEUQWQgbCxaXXcE+fPm1WZIyaTubrCxcupOuCzifGdcmzlg+FmBeE4deWzB+HRqwCvIm/DthBTAghZOaBNhyVT5GH1j2LPmJowydPnqyuX79u8Rmqy5cvm0MPH7GwNdOo1knFXtPFFKYK9mylUX+ZOdJHHFXzBo6v1csIIYQQMvOo8imyEQ497DjmEGMNjdjcQ9vAZ5imgYvrMLymY/5vo8OsMfQ6WKZB7donTpyQa6yP2Ju2CSGEkFnHK58WAAmjpldXV7EpAtjmEEMjhnKrpmkjCe+R0dFK7Y7Zdu/UqVPVhx9+iCHa9cbGRu/OnTs434sV6umo6d7t2+vXAtkxHj9+EpaXPxYIIYSMsrZ2N2xzpm2zuHh0JZqm0SULT1r9MPSoZUs/ysomykrbt9JkGxZozCFuacQp546aaf+w9AObi0u4t4xC2I6bhxE/qIsQQgjZU0Ql1SIV2qHWuCqAqUt2HHIX1uS6I780CRkdzSETsNE0nbaPHDmSziNYciCEEEJmm0r7iEeCH2n0JenOhXto6941Yh+ypLV+Yhk1bf27mYtLKQiTkIMLfYiD8Kx169YtSasOPfxIMGrEhBBCZp0Go6YxUBlAFgKMmo59xMk6PD8/36h7S3HoAdkKjVhl7qbsbOU8PGnH4dADbi6lnzhK9+rq1au1nuu5da2LHIt9xB8EsmNst4/4Ubz+8aPH4Xmy/8D+cGD/fNjtvIi2yDl27EgghDw/ptRHfCZkfcOLi4v927dvW5+w7x+WNYSxRjb0fjmEOZd5la2DCmGJvnTlypViOvU1bZl2mbrJSwIEz9r6vfA8ORaXl0EQv4i2yKEgJuSlQISoBjySA5hHXEr45ptvNu+///7mhforoDRYS1RpPSGpoEZHjVikdxTCuR08SXSLR6yTm2maJoQQMusMTcfd3bGNxWeIQriKwhguLivMI/Z9xJZPKx5xPnLaBTOWxKdOnWoVFJz2DE8jgeF6CCGEzD4mM0cceiwvLyfZaA49VCNOchZ+qW07hEIf8YULFyobrOUW30csy/Hjx+s7d+60+oexzT7inYV9xNODfcSEzB7Pq484ysRBlIk2r1j6hmO3bhOF9EAHPsuCOcQIg+jnEvvoS13arO8j3vQEsqmS+z5jasQvORCQL4OQfBGwLQghHYjMxKhpi8CkvjVA6qZVuSn76ja6UheYbYceJlBNRY7acBLKcMsFhx7aR1zBs5ZdGDumU4U0JiP7hwkhhOwZIIQ1AqEhcnBlZaVx0ZfkxLlz5xo1VSelVbRgKMPp6s2pSyG0zdLJPI3l5MmT9Y0bN6rFxcVohr4t05eiIK5jheqFhYXe9eurdHG5g9DFJSGEdDMtF5fBTVE6evRof319fbC0tNS/efNma9oShO/ly5ftmCm+Q/daKnN90AdLVIy0lO9jqLZNYtY8qocPH1IrJoQQMvOYQw94l7QASHD/HFReukBJgo9oWCl2oM76euWEDtYS1D1X0cUlgiFjff/+/ebQoUMNXVwSQgjZC8DFJUzTmMKrSmnjllY84uxSGzFtU5g2HXBYTGIIYcQjxjH0EV+8eFEEtM2JimZpuLhsZRiGgR+gEQdCCCFklonaMFbJqRU04thda8cq9BHn12ho4WSW9tjM4iobrJWCGaOjGaOmId3dPOJWITpYC0EfAiGEEDLLuC7dyjxL6gDmkYHLsCpDqTWijK3NKp3WlpkKYhuxNeJrWhc5Hk3TvcFgYPOIEY+4jhqxpGE84p2Fg7UIIaSbac4jjkroIJqnB8eOHeuvra35mMS5v2nZh8X5/PnzfvqSTG1Kg7Vgmvadxx5oxMFJeZim3ZypxnxtBk5hImRPcuGf3Q/Pg69cexqurQ9k+cq1jZEFxwnZCTBYy+YQRyHc6YfDb0MQa+hDP0i67eIyB6ZpqNUW8EHt3pWPR2wFYbBWIITsOd69/Dh84Vcfhx/+4trUBfKZo73wp37+blh73EjeP/6l9dby9vsPAiE7AQZrIeiDO1QSxqVR0yKMva/puYKHrLQNu7aLrFRdu3ZtqEYPPYMIGo8Ro8foWWsG+J0PVsPXP/hGeJ6ceeVbwre+shx2O3RxuTU+e3Z/uHSjH95+82D4/C8/FAH5cz92NEyDlaN1OLq/EmH8hR85En76y/ekLGP98XQ0YtR7Wkh9v+9AILMPZgx1nJLjGGN1+fJlkaU2WAvxiN955x2RpTpsukphEJuhRw9smnsu6R+GRhxN05UPgxgzgkMP6ZyOAtjCH1ZRVadW/JIDIfyL//zXw/PkU3/ge14KQcwwiOOBQPzbv/YofP4zh0QIg899ciEK4qdy7tzJXpgWMEF3CeNp8DO/Mj1BjB8PFMSzDWSdBjpqsbS0ZHOJBQhh4AIoSfSlfOS07yO2Y16rbS5evCimaUxfgmkakSXQR2yxF9W9l3Q+u5FkhJAZ5/KNjbByZDQE+Sdf2RcF53QFJTBh/Nc/c3iqQp6QZwVCWEP/tohCWNanT59OU36BHzXtECsyrNLpKzLvWOhMjrbsyuzZUbWubPoSTNPQhnH8+PHjMonZhC8qRc9ahOwd3ljZF375g6cjxyEwz52cC9PmCz9yOJqih33FFMZkp/EasXPoEU6ePBmuX7/eqEOPFhC66qfDLM9Ny9d0CN1hEKMgrqNWbNOX6qh+V1Hyi5/pfGEYxJ1lu9OX2Ee8CfuIJ4PBUscOVOGHPrEvmozvS98w+kinCfqcIdjP/+BBEcRYPhfN0+d/8FB49/KjaBY/FLYL+4j3DtP2NR2twoO7d+/2o3La3LlzJ4VADB2+piGM+/2+mKj1WCgFfcjDGto8YllH03S1urraK8QjljQUxDsL5xGTFw1GTWP5ygcb4e0oLH9iykLoJ6I5+p/81qjmjb7Yd6Pgx5qQrTItQaz9xBaT2ARwP8rIwb59+wbRgiwCWQdsDaKVuXn33Xe9w4/NsMJZAWnkM8zT8SITwqA+depUDdM0BPHi4mJl0ZcOHTrUU4ceFMQ7DAUx2Sm+8KuPnosmCA34UuyPLvHuV5/IYDFCtso0BPHp08tnouI6gCCGZ8l79+5tRJk4iDLRNF8RzFEID+BrOvYRN++9914DZx7R6pycTOeetfy2rWu3n7xqhaH2W0WNWLxrra+vSxjEuN2LlaIg3mEoiAkhpJtpCOJXXvn4CuYRh6HAFY1YTdNeO04etkwQh1FteOjQwwZpBecjE33EOsoracgrKys+XQXPWhr6Cd5FKq0UR00TQgiZaaB0hswRlnqbbB1Tr5St6UuOlFbCIJqarEK5uXTpUnXy5MnGh0CM9m4L+pBXAN5FSscJIYSQWcZbkpP8swBJ8/PzLc9aUHKj9XjEidacG6TVmNst9baVtF8d9RU+/PDDvHB41qrUqUdgPGJCCCF7gBGlM5qmq7m5OXHoEWWlmKWj3Gz5lIZ87fV6wTxq6bmqtjjElhmEMQZq+QI0s0Z9TTdaqKVPtm7GIyaEELIXUEtwC3XoITLx1VdfbXX5wsXlhQsXbIZSpYGWQsuhR3DS2Xxi5kTzdB1N1tXS0lJj0ZfUFzX9TBNCCNkrVPfv368wYtq8S0aZ2Jw4cSJN+3UOPZJshGm62SRl5gVx6iqOiUfUbnXX1dy4cSO58VJvIgn6miaEELIHEE0XYRCdMiohgjNafcfa9evPCbX3D219w+pZaxzpGu9ruuQEmxBCCJkxqpKvaViLw2Y3rqCDnmWwFuYRy8VDaZziM+QjvlpetWIGojFfvHgxedbCEtVvEeDq0KMXbeXYlzQffPC7nEe8g3AeMSGEdPOc5hHn84eTi0u3Ti4uEQrRja9Kpuk04EodUmMecRUFsERfAj6ShI++hGsQkxHaMDViQvYmCMTwPPjKtacSRALLV65tjCw4TsiLRmXdiDiHRowIhaHtsGMkpoOGQqxMI66z0IWdZml0PGNuFCJLWCGuj5hziAnZo8DP9Bd+9XH44S+uTV0gnznak9CHaxp1CQEg/IKgE4TsAGaabslPTF3SCIUt4QsHWRbRMJqn7XDb1/Sm28vRoA9nz56tdfpSMk1b9KUoiMXFZXCBH27fXr8WyI7B6EvTg9GXtg4E4ttvHpQoRgiNiChM0wIC9+tR8/3CjxwJP/3le+HSjc1Yx2+8Mhd+7j/aflmMvrR3mFLQhzNxDT/TA/icxhJlYcs8Ha3Igyisxdc0jlnQBx0V3XLqIUFD1ZFHmnAMiQzpjWlMcOSRA6mPNVxcYrDW3bt3ZX9hYSGQlxsI4V/8578enief+gPf81IIYgjhtfV74UXyMgliCMS//WuPJOgChDD43CcXouB8KuemGS8YJmhoxiVhPA1+5lemJ4gRDYqCeG+AUdOQgVEWNvCtgWm9ME2vrq4Gnb6UrMVwjIW1hhpu+5qWLfWu5YdW21zi119/vfXbQe3f4tAjVqDSoduEkD3G5RsbYeXIaAjCT76yLwrO6QpKYML4r3/m8FSFPCEfgcZGTUMGRusw4i9If3AUwsksbb6mgXnZeuuttyQd5K3NJc4Ha6UMzJ798OHDymem9m9x6OFHfWnaQAjZG7yxsk/M0DkQmOdOzoVp84UfOSwhEdFXTGFMdpjKD06GdXhxcRGbaXQ0BjhfuXIFoRBFZp47dw6DoUOu9EIRHvlaMGraBmyhg/kb3/iGZAZhfP/+/bCxIXFBJWONvmSF+zV5SUH/LUzHz7uMl4H9B/aHY4F0ARPs2aU5Mev+0Cf2RZPxfekb/vwPTT8+MEy9f+jfmg9ficIfwvhz0TwNYfzu5UdhGvzU90+vWw19xGTmgUYcMPoZ5mmgM4lGgkBoPOLq0qVLsDQ3fkC0xXmYyy+yfZimIYi1o7mOAriyoA8nTpzAFCZfYChsk5cQ9N2+DP23L4ID++dlId2gbxijpi+8/0D6bbH9E1PuHz0SBdsXfvWRLB6Yqd+d0qAw9G0T8lHBDCJVTEWOYoYR+oijAlsdO3as8WEQMYcYgR+wViQGYmUmZheJKfnLjH3ElTr0EIcdJ0+erG/cuFHHPuI6mqfr2E9cRxs5nHrA92aPo6Z3Fjr0IDsFBOXzGKQEDfjSjY3iuXe/+kQGixGyVaYxavr06eUzsSu2H+Ue/Gi0nHoghHCUkd6pR9C1uI+Gdy0NP4zjw+APkuumMK6cabpyS52te7Y+fPhwL6rmsr2wsFBfv75KQbyDUBATQkg3U/SsNYAgjubpPpa1tTURvBDEc3Nzg2hB7msI4TR9CRe7KUxpnNWIILbpS9EsXas6jcFadewnFkEMjbjf79fRNG1acppDHDiPeMehICaEkG6mJYixhgCO4rIfrcLi7jLKxz4CI0XT9MBiEofMxWUzFLhpunBAPOK8BBvJBakeVFBHIZxcXMZCmiiE021EjZhetQghhOwp3KjpNF4qykeRh1EIjwR9APCqlTnOEkQQmzYcNv1iWkxiG3rtqTTmohDN0l4IUyATQgiZaczXNLplzZfG4uJis7S0BCW2c9DyhQsXWoO0bGMuhWFqC2M5hFHTkcGTJ0960IqNLOaiXK+d1nUghBBC9giwCtsUpps3b2LVkqUWOEl9c1S9Xk/M09GsvSmIbfSWE8iVXaRaccuhh2ae3HkdOXKkib8I6iiEOXWJEELIzIM5xFErhsyDn+kGU5Ru376N6EsyNQnzi226r2FWZjNNO804mabT4i9SjThHEkEIA6jlURsOhBBCyF5kbW0tOfOAn2knhBv0EZssxYwki0Xs5G5jvqaHQ7k07kPUhiVDjJpGH7E3SysVNGLbxh/8QogL+4gJIYTMPJB5AMooNGJsq2lazNI6wLky0zSwWUkhc6JVuQR5GMTarauYaXX16tXk2CMK4h4cegQ3dQnHb99e/yCQHYPTlwghpJsphUHE9CWZNxy7Zwc6jQkxGMyhRwqHGNzUpZBNXzJq1zecCsGf3CytIZ0M3x/sCyGEEEL2CmnUNLpr0UeMKb6nTp0amdZrgZQqBbLX5G/tBmu1hGk0SzcqjFuRmaK0TxnDv2agf+ldBQbibWxMPwQdIYTMAhv96fx/1DCIDUZNax+xmKaXl5etj9jcREt6Cy2MfmLVikc9a4XhaC5zcenN0xg1XSHow+PHj+tYQDJDR0HcW19fT961ULEPPvhdmqZ3EPyegjB+mQLME0LIiwBC+JvfvBP2z28rmEvLNI0lysJBlIVmju5HjRhOPQZRdjZXrlzJzdMhXyfTdF4Q1OioEcuFCIPoTyL6UqSyMIjxF0EguwP8ytroD0Lsq5/aLz9CCHmZGUQF5dGjx/J/cZtC2KgwWwjBjrCTxSNOo6a97DTTdNApTDp9Sa6XMIh5xzEwNRpqNUZ9WR9xVLubp083g4HHjmoZNWYjyMjO06treci3b63FNbvuCSF7mypaCTG3d9/cXJgSYl1G4Afs2KhpeJ30Dq/Onj2LUMKybTJVL0Z9xAod/1e3wiAmzThK7hoRIsKmaToFfcASC0PQB2+aTtGYGPSBEELIDDMyajoqo4OoEcvI6Sgb04hpNU2XRk+nvPCndtqwjNdC/zCEsM0lBtk84kYlfjJNa2bVwgKDaxNCCJl9dLBWsFHTALLR+5p2QhhdvXk3cBLILT1dpzAl7RijplHI2tpa2NjYCI8fP8YaESYkPdRxnLP0Dx8+DIQQQsisE83SSZBiBhFcXEYwh7hZWVlprl1LxmHEbWgwEylsWp7b84iDGzmtnrWC96yF/uH5+fnUAa1CWPYxZFvDIArUiAkhhMw6bkxUGqwVXPcuhLB51sIfyFKliX3CMljLzyMeCXHo1rXfhmctaMOxgB76iGNmssQKJM9aURDX16+vso+YEELIrNK88srH0UcMgSpetdBHfPz48cHc3Fz/5s2bg6gRY7uJAntw+fJl3y9skR7Mp/TQoYceSQ6rQ1t1tsnIDUZN9/t9mW8MO/idO3ca10cs0DRNCCFk1tF4xOH+/fuIPiimachEG/gcFVa4hMaI6ZYXyvPnz8saf8yhhyxydHTkdFVYROuNHdF1NE97X9P1oUOHegiDGKV/TYcehBBCZpjm9OnlM1HxxOjolkOPpaUlCYvofU1HZbZBuGDtI/aOPFLc4hGHHtCW/YhpA/buU6dOiR9N7GsYRBSAXwWSxn4lEEIIIbNKFMKND/9rDj3g4hLzg8MwUJKcwzgr10cMrI842LisUvQlO17SiKuoEfegEQedOxwFcS/2FYtGjDSMvkQIIWSGkT5iOPM4fPjw4N69e0kzhkYchTFGTfcPHDgwwEDnaJ5O/cIhc3Opgrjy0ZfSQfxx7rjEO4hJd4yaRoQJZHLs2DFZw07ufx0QQgghM4rISMi8KITFKgxZaBpxRKYuwf/GkydP0virt99+2/qINzPSQEyVM00nldgFfsgX86BVx0Kj9nu7jpWoY2e196xFjZgQQsjMsrh49HRciUaMUdPRNC39wdFi3IdpenV11QJCeC3Y9i3IkrgiToO1FIufWLtjNs9Ylqhu1xg5/fTp016U/Biwhf1eFMQyaEsHa10PhBBCyIxigtiWKAv7GDUdt81MnYQvBmvFfuLkYQvziOH3OjjTtPeslSR12BS+TcykQmczcJ5CJI0bsIVJyqnjmRBCCJlhRNhB9kVFtBXSEF61sI7yUtYqhDdHSKsQxh/zZumddowUkmWCAmTktBF/BUhaVAT9xN7lFyGEEDKjNNEs3aif6QbaMMIDR9M0NN4Kzjx8Yj/mypH6j2t1s9WS6No/bE6qk5BG5hZn0Qr3FcPy+PGjXwqEEELIDBJl3C/qZiuS0q1bt8TPNPqILWwwQMwGDYEozjtMvjZNk0RvrZ497Jo0uguLn4B89uxZyRxqN2ISR8kv5zBa7OjRo/h1IHn/+q//xl8PhBBCyOzRfO1rv/M/YY0R0yFz0BFlo2jEOstIjqkcFd566y0MhBYztY2YxvHcs1Zw05lKo6aThy2/HQUxfE4jAIQc//KX/+kf/j2/5/e80+v1zgRCCCFkd/HM3ahRwK7/5m9+9S+88cYb/yhsjoL2o6PT+rXXXhv4EIjRNN0gvLAr2+QtVpVNX0rRIFQ7brm6xICthw8fVuo3syiQ4dgD29Fmns5/8Ys/9z0nTiwexS+EweBphdlP2M5urhp6IunH7SpuNw3WOOe3h/t11ngYoNZLefj15jW4056W9TSe39dslunr0C5rmDeu39fYtZt16BXqH9K9beZt9zS8v/Z1w/bI0+Z1tnps5rN5H3n5vk028/T1q1rtMywnhPL99MPmuc1n067X5nX+epwbllNV/v7y9KPPbfO+yvmX6tE+Z3ubaTbzaZdTu/es7mjLzXr4a/J2GL3PkNW9HzbrYvfefq/9u9N+Pr30fub3k7fj6PbT7D23uofgv8X2tfm9DdJ7uvlsR5/R6Lsfsjr6Z1uqO79/fv87+/1vXjvct3ZAnS5d+pdf/+mf/unfCSpodZBWEsLZtKUmCuImCuKBC3/Y6v6VDQ36kE9f8lQ6l1jqE1yncnBCeGlpqcY0ptAWyCaMW9chiPKDBw+qhYWFygWHwH4DIW8VdOdtlJmEV4RLMV3bfqu+7no5oOkqlz6NWvNpXP7Bn0edXN2QptFrfFCMkfL9vuXjzrXuV+vXZHX216S1r4svK79fO673m475+8/qXLl7Cy5fq1uVtZ1/fv683Z8ct/Z0bR/yOuO85e3uo3Xfof1ejPwjd+9E61m7/PJn4Z93/sxG7im//7D5Tvr31p6PfwaN3p+vZ972rXJDe9Bkk99fVl//LoZSPeweC99Lyq8rUEt23606hfa70EqTfWvpOvdNhex94ffP7383fP95niI8Ee5QByGLANZ1o76l07Foku5HISxxiC3qEvIyr1rnz58fXLhwwZfXKrvyZmk75tb5tiwIifj48eP6ww8/hMtLhEeUnxxw8BErWMUKihBGrGIf2UndYKYy0HgoGz6q/YPXYwgiIeswSv6hCx3pS/fWOt/18YPsQ0oPSR+Qz6fK/wl1/FNq1dNvI73d+7i0Hf/UR/4ph9F/9vm5kbwKbdiU7lHvv3J1tmeYhIHmZfch7WXXuTzzDyP/B57/IwmldtY0Uia2tdyqVIfS885o/YPBdXiPs2dp7YfjA3cvlbWPXhMK99q4+rSEmN1rh5Crsn8Qpbp3/fNCnrX/Z5YLpK2CNrX2sPu0d8DXayGLT57/8+P3z+/ftVMIO//9p2/FCeAApx1Yuz7hJJAXFxebKPdSgAfMLLp27Vr/3Llz4cCBA42bdSQDtfp9sRZsTiBWJT4J4mwttusowb2HLdCKUazrqqAZV04zFoEcb6I6dOhQhWlO/uahKVvDxfONCuvWi6TadMgazOcR7MdEdn0nrqEr/5AMV5fSdXk9kotPBMBAfVEfjUiV0muewbVhygfX+/Lsuq56lOqc0WoDy6crP9/2cMwCP6phQhuOo6tupeP+WPbByj24INyh6z3wbYu2xHtcKL/4j8m/X3ldXJk+Xate+qxTvv4ePNk7mvJB3W1sht2zu59Kyy3+eh/3Dth3UXjeebul98K/d1ldu2iy79PXf6Q93DfXakN+//z+/fYOfP/5dyfPBM/RBDBcWao5OgnhXq83wAJt2I6fPXtWYhDDLK2DmkMUzHBvKfJX5xFLGcnXtO6lF9nWKoSt8nIMHkKwxgjqqBWnguHkOmS/FHSSs/0SwPF+XMsvB/2FIWs88LiINxII6Xgs/brQfwYDfSkkj9D2WtKPaeR6FfD++r6dD65T3fZdnrbf12slDeqMtaa3cvt6L1a3VF4sf2B1QN6aTrY1n8bOu7ZKeeN6zRN1TtfpNameWp4s1m55HbN77Ws+flBBP7QHGgzUX7jVuV9I13flp7r4NvNp9cXOy+nn7W7Pwq639rX2s2tcm44MkHDtlN5VX46rc2PvlKuv3G/pvfDP0T9Lfx6Lf3b2Ltk7hAX7cIOHOvrnaXXROfi+LHtejX/O+aLv/sC9h+k5Zd9FP7su2Hth77nVy91/k797du8oy71zjV5jZQS7J7vOff++rrLm98/vf5d8/1KWayfk2fffJITwsWPH0vOImrAEeDCTtJUPIRxlZTAwSEtlbHAetZLSm3xNZ6bpRBTEta69SdnM03Lu6tWrVbSP17Ey6Vz8pVDFSpa0aL8WVFu2baj/4q0E9cK2HVNav6aD/krRO6v0l0sIo+aa1nW+HGjtWRmWPugvoMrXLc8X9beLsvOtulheKNPSW95h9Bd86b6qQlv4NmxcfZu8bTvqGvQ+bWJ6qS1CVx1Du32tvdI9Z+ugU9zMxFNZnfD+Wb2zPIJvu6y+lau3IfW3/CydlW3l+uPZ/fhy/TUhuy7Vyb8XONbxHrbaxOptzy0U2jV/1nlad595e4dC2+fXN769XH1bdbb3pfReu+fm78Oej38Pu+rm78u3N79/fv8h7Nz3n7dLEu5RrkH4YhM+pTFnOGAqrx+gpdGW/I8Cn6/5l07vRuf0JX9TbsCWpIODj/fee88Erh1vLZhHFStWd6SRKBVra2sjJo/Yt4yYjlVWcdnHOYCYjy5tKw3WmM+M4x15BZ8PTOe4Z5dPkazsSl8KzJ9u7D4sL1/H0n25MvMXtXRfE+uFfPw9W/k+ny3mmdp5q+Vb3lamR7slRu5vzH2M1Mfua1w6O+bOpfLG3Uvhula5ek/pH4Gl8/eV128rdXbXp/NaVjGtZLr5Xvn8u9q161vwZbX+eWb1yv+xtp5jXv8SpWfRcb50nN8/v3+pzw59//6erN7WDxxOnDjRwGkHjsGDVhTE3joDLXig7qBlH6boaFmWfQhg6x/W/QpuoaXSJY3Y9RVrmmFv8mc/+9lKvYPYDbcWTGDWAVzpfOw7rmzIuPYh41dFEsLQmtVNpqC+q0dAGjvntzOQV2P+r+N25dPpda1/NppG1rhn0+LjR4Y6D3S/0bxDnp/V2Z/DtfEDbcbdgz7Yyp/T8kMI3f0yvswSyBfPL56v8IPH3UOrDvk6r9+48vPrSmlQB2uDjvaQNrVzfo12QN7+OivP2q30LLby7lh97H3392IfW9D2d9flmsDE8izvSZTqVnp3XNqRugT3Htu50vuV16nrWVod3LtUrGvINCKEgPPpfbmubKmrP8bvn9//Lvz+5X2O+yMaLRZVNnOtVxb0CyOhc+JRWld+6pIV6qkKCeU4NGOnHVdw22XaMeIVR3W8hjDe2Niorl27lmvD4oMTD0jjNeLXRUtAw09n/LUh56IAl7ll2HfHGw292FgauzYUzCSu/BLwC1pZea78lI/l78t37ROy69N1/j7ye8nKaeVh12Ft7ZLdYye+TNu2cjUvKUsqGp+Be8FabYY401bXQtkjpibb9vek+GOV3ZPm3RImeXsFZ9LLn0mhLi20SyS98Na+yAfk25Pys7rl+Vo7uOcnx/Jn7fabrvvJ29ntl8pJ9Qf+++log+K7Me6e/XW+nUrvtZXtvxV/zaT8uvLn98/vP+zc95/uA+2BPmDVfv33LwvkXeyaTcI6ysQBxOb7778vGvBbb70la3jS8iZp7ReudF/aND0clcwl05DfNu1YDkQNOQ3/ivbxtA1hjL5jn0f8FSHr+Esi+Dxxk7kzAu1vFqwRME0KNnnfaHouZab2+uLLg+s78m7l6cnzz49reXasKqUtYPciZfoyrP5bvS9ru+xcXk/7BVdqFwGWCx1wVywv38/uv8rrDnDeb/u8sM7r7OuK98Cut3bK6523Ud4WKMfy6Wozy8PXs1Q/q4fODvDfR15OZxnWzvjOrJxoqqrtQ/dtZuknvH9d/6BK72J65+xc4b2ztBP/8ZfeOztW+obtvN1jKS9s8/vn97+Lvv903enTp8P169cbnZqUBC+AORprHxwJJmms33nnHZijMbJa0popOhR+zAy33Fxf3ffrSgdt1W67pwvCKM7FXwJYz7tlvy4HYuUxyWvBr0+dOoXx6Ng/qNulZaHjuF8OdeUzbr9Q5qHs3CGfTusux7vyxdruzdb+3FbuB+nii3Co65yvS5Z3Z9pSOl+3jvIX8uM+va9Dx/NbyJ9LV1q7X9fGY+9tzLMc275Wzpj3YKGr/Qr12cq7me656378PY+7X/9OlJ5jqV6FvBa2Wm7+rnWVP6nepXbP3wN+//z+szY+GAVf572NeZbP/P1bOfn19ryixnvAlrh/ICqbJtdMzu3TZc4tIisj1dCj5KDSwEotr5LYtymLwR00zdgf80kqt0hBEMhRMxZhrIJ4Lv462IclFISy3oTckN7Ygm3rQzhQWEyAp8bw5+y4b6z8/FYXXwe/7fJdKJVdqnO2HCjddyH/Up0X/PmO8nydU/ox7dJq81Lb53kU7mVhUr4d7TbuHhayMkvt0Vm+r3NXW+Z1K9zngUl1HfOutsqc8NwWtvC+WpqFQv0W/PPOn/2Ed6TzuL9+wn223o1J7djRHvz+A7//rufZ0R6d5T+P798J3iR8YzdsSQD33CLyMWrCIi8hkJ0sFTmLLl4TziCTtaGV2HDasiy6n4Sxq0ASyLre5yrtBbPdzP58yX5xpONIj3P5ed2ftzRZfvOh/etlv09neWE94dqRPPI6W/38sa57yeo6n5U5Uo6/x658Cvcy9t7HtH26Lr+fcW3g69Bxz/MdbdM65utXKj+vIz6eUn5jnmtnWn9/ednj8snW85PyLj0/e2b5e5OX4dtyTHt3vsvj2rjjuvk8TeG5jNQpey9H3nV+//z+82t34fefZJUqly3ha7JOldFeNEeb1Tg5tdJRz6Vug8oL45RGD3i1uWu/ygSzFGyVyZaWpoyb6FqHTWG9L1u8CWC+lMa9eK08cdwv/hrT2p0G7/MaybPwQObzemfldN1L6b7z8rrW3tpQync+b1erc16e3U/+khXuu/M55df5vLDealuMK3dMPUba2vZd2V3P3bdV8dl1POdWu2V137eF+ne+v77u+b3l9+Dr6J9BXmf/jhe+gfmuOvj3pnTPmcVrbBv499C3eZbXvjD+PeH3n9W7I99d9f2fO3duy9+/pt3W92/l+e/f1WHk+vz7L5yb031vdhaZpnJNtF+VfS0BHIYkK3NJIw5DWToia4NeNKINZ5l4E3YSyK4P2TTkvB85rTOtuXSDc6WbL61Li5nLS+ldA5eWfaU6PWv5Xcu4a/y5LZZhL81I+7l2tBcvP95qBxzz6Sa1vT3HCW0peRbuq/X8864Nq/O4D6FUrr8Hv87v25W1L9/Or93qM8vy31d6pya9V4Vj+zqeeWcb5Hn4NtzCu1R6xqVvcl9XunH5Trr3jrI6r+H3z+8/r+M0v//snktKZtKArQ84bAriYGvViEOm1LY04ZZZuqQ+FzTiVIBJ8ZJA9qbr0BbK8uvBa8+27Y7X/liezpa8gdzH13vWxeddaviOsnodVoD83FxXvlgy075PN5fnXyrP/RobWxcsviwrp+Pea6vbuHvM7yF/tv55dD3zrrp25dHxHtTj0nTV4VnqNCl///5OKnsr798W2v2Z3nWrn19cOfk/nLkx9z3X9U5Z/Sfda55P3n78/nfH9w9Bs5XvXwXSrH7/XuPtod+3ZIK2QVlhSEuWlvqDs+3J2nB2vGtaQzJZ68Numa69tmw35Y/ZtntZWmn9kmneI+dsCU6YZOl6vjxfhv9H4F7auqTtl+pfqkdWn7F5hnK/eyvPLG3pfD2mfv6DLOWXf9DF++po/17X8YKQ6nyWXfUOrhvEnuGke55Q3846+Dr693XCO9HraMuR55fXK3/vx9SxN+Z55M910jLx23rG/Pzgzc768/vf+e/fBIkJ0MJ7Ufz+kT4TQp334I93ff+lvPyxcd+/1cWnz7cn1Lf47PKl8P1jEaGrDjbyBVRutpFpxVWmBdt26OhDHlK0W2fndR3ywsNoP3JpqX2/s91kpuK3hLmdc9sprf0IsDSZVl65smp/Xdd2Xg9f1zxt9uOjVbcx7eDr0Urn76GjX754zNVjpN7Z/dcT6lMV6pNfW4+rT1bvYr067iPddyYIRtrM1yd/BmO2U3u7j6vK35vCe1SsZ0c71vlz8z9SfZml9770fofCP4Pg/pn4Z+vLLL3HY55F6X0vvSulZ1Pl91C6Loz5pvN2GJeW3/+zf/+qsUl5VUbeLiZo1OmET9P5/Wv+qVy71l9jwitPi7WVkX//Kkz99SPfv0uTyrO02T3KgvKRv12Xvzd2z66NbepRqV0SzTCwg8hCrwkXBHG3jPUHS4lKGeTCtylMf2qyjuomM2e74/nDCdkHULpu5NdFnr+7j7ycVC+7xr+4+iKEELb0w6LrHtK5Mf+cQuEewxbKy9u9ygRLNa5N8sXXx6fJ8nvmOjXtLo1WPfPySnXL22lcG+d1KNXF1yeMPoOQt1HYZOy9ldpnTHu1rvffU9P+lTzybpbutXB+7LMp1S0XqoV7GRnlmT+L0rMpPcNSe/D7n+737/snGxUQ+bNqVEBv5fvPBJMsuVZo+77Mcd9/ctvo8nbzblO5of3+dbaxr8dWv3+ro5brjxW/f58uW7emIfkR0/640UzShjWRf0G2QlVKm38EWfpUIX++6fhHGdw/BJeumNbXxT/UUK53yB7QyIcayveYpwtjHvjIfpZH6x9OoQ3SvWT1LtXJ/0P3P4i6nmXxXkN2X4WXqUsQhQn/SFv5FvKv8nNZnmES7uPz11ale8z+4eTXF9+Hpi1Aq453savOne9h172Edlvn7T3pnR15DzrubSTfMe97NaEuVlbp2lQvl4bf/xS+fxNs+fffFP7pF9ov5Ruy97HwDrXSumtbwj//trwGWaqjr8+k77/wHrTuNf/+XdlV1lbjvv+u/3uVb1PrHy7UpSrVZ0s02T/R/GGPe7HduXH5tipaqPjIxxQK/7zyhg7j72dcw6b8Cy/ryH2X6jGu/DD6sVaF9VbKD5PoaLvQ9awm5BGye6g66t5Zh3Ht11FOFyP/wErXdz0jX162X/rHmL+Hxbyy514UAOPK7zheZfmHZ8H/Y2wKP8LG/UMofX+F+8y/8VYbNuXvP39nWuWNKz/Po3CvoZA2T7cnv/+8nbP9MO5emoJwzDS8rvpu6fvP0rWuL5EL8BBGrUgdZebnfFkjpuWCcB5pO3++6/vvaPNx70g3vrCmKf4DLVZ6q/l27Y9LW2DSBziR0ss/7n5L24Wyqkn5lo5vtV22ci/N6D/UalK+XdfkeY8rf8xHOvE92cLxLbdrqczSteP28+MfpT1KZY97F8KY/Jst/GPruv5Z8nb5T/wetvJcC/ny+y8c32q7bOVe+P3v7PffNFvoDyaEEELI7uDfAMcXJVZgJC0kAAAAAElFTkSuQmCC" />
-  </defs>
-</svg>
diff --git a/static/assets/images/app-wf-light-2.svg b/static/assets/images/app-wf-light-2.svg
deleted file mode 100644
index c4eb3adf48ca..000000000000
--- a/static/assets/images/app-wf-light-2.svg
+++ /dev/null
@@ -1,9 +0,0 @@
-<svg width="207" height="86" viewBox="0 0 207 86" fill="none" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-<path d="M0 0H207V82C207 84.2091 205.209 86 203 86H0V0Z" fill="url(#pattern0)"/>
-<defs>
-<pattern id="pattern0" patternContentUnits="objectBoundingBox" width="1" height="1">
-<use xlink:href="#image0_129_29189" transform="matrix(0.00207039 0 0 0.00492611 0 0.0226196)"/>
-</pattern>
-<image id="image0_129_29189" width="483" height="315" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAeMAAAE7CAYAAADuGul6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAHS0SURBVHgB7b1rjF3Zdee3zr23WMUmWSxSZJfIZo+oVluympLsmQZiyeOI7YkGkZwPiQO3MBnAnkyMieeDJ0GkxA4QT1NsAwNjYtkI4HyL88WAM7bhzPjDxHbGD7aT+IW0ZVti62GpRVtUs6sffHWTLJJV98z+71pr19r77HOr2CySxVv/H3DrnHvOPnvv86p119prryVCCCGEkO1J27aNLW3dby/XJ9VT1tHX1lZQ9Lv3PLaqHbfebFSm1v5mrktteQd1TbxffdvKNif1Edd5I/rqm9TWZvvg6JSv1F9rbzPPdFZHeZyvt6irqT2TPe9R09PnrFxfHzezvahbimW1rZbvf287bn1bv//+WrjyvdvK69fTv029/75ccU162+o7ZgPKe57VPx6PG1Cpt/ca1c7Dt9e3r+x/7b3fkPKG106s59DaPyh70cuH6B29FG3+TyR7CPw/lAkPR9OzntVT1NVMKu/rK18aX+eEfmxE9YUs6609hLJ+jWr/gP1Dmdrxbdbw16fsV9v955M98P7e3OGz0FuurfxTnPDC+L70vXyprbb+Dy9rZ9K9dfuqL790z6nT/75nuZ3wD3MTL3z1PWq7wqv6j016foxUtvlnq7nDe96B7/+dvf8qeKQQQDUhmNrxbZb44307xbNRFaSVPjQQjnIX7395zl7YFsdKpS99738s0k74oVIK9RoT3p3N0bab+xU8odJO59rKP2Rbl/wFbir1+JdPyofHXQz/T8wvaw+JL5/1veyLr0f6H9amqC/rk+T/hKqC0vet3F9cu86yeEmzf6y+D/5E2+4/sfIF93Vn16XyYNWuhRT7egVM2xUEpcCsvVgb3aNsf62/bf5PadK99v0r+5z9uJCu4K++sG3b/WHk++3KNz3nXX3+JH9fynPw70b1nSzvQeWeZe9XT/1S9qXl+79t3v/yOa71wYRVISwbJ8Tu6P33ArLWvn18e74tX58v1+YC2Pelc//L61i+/0U9GWU/2+7/jqzvxb7O/7623YTGX9vZdv/J1Ja1h8BflM6y8oL6lzxbl8oDLt1/CtVj++ru+162K90HuvfFl+5DIH31uevW24YU/xR6vjdtV6D0XsfKOUvfeRR1SLF/cCfXy7fTFv9E+65prT5f5nOf+9xA8mezcy/7rssmr331+ZtUp0x4Lovr3nl+Jj2Hk+rUeyF9fSmvt/++0bOi2wZ996h8bmp12H2qvP/VunrOv/d5Ka8J3/+1JXBCIn2cVhfrs3KFUMvKWjn//vfV33MuXjuutmN96KuzdUITy1OnTg3cNUnvT6m51urtaUdq7frzbus/4hOFZp7ta9s71JA3XVAb8+V7HvJUzv3ztBd8oNvs41/+bLsrG9d9OVd378f6ZuWK/mR1F/Vn/5CsXFG+93z8vlo75fnZx1/DnmvU9PW9OIfsfhTl0j7fdnltKv8w/Hk2dkxZvu+++OtZXoOea5u1XbRT3v/aM5QdX/ln3bnmRV8618ofVzz32T30ffHb3Xrt+Sn72rne5XMi7hmvXduivY3Wq/eltizfofI++P5PON9J947v/zt8/ycIn6x/wLddCLpBRWgNdP/AjvV1VwRm9lldXe19/3Gcb1smvP9Wj28Hx7v6q++/9dWXtTb9tqIv6ZiawG/bjum+tr1XY06UArWyLStbkfzVf3aVB3Pw7LPPDvW7LdMD7MoPXTnbPvT77Xjbh/LlPxz3GVbWO23gY/X4fto2d8xQJrz4Urx8Rb9TnycdVzl/X0cz4dhh3zZfpzuP4YSy2TX3/Xbr/joO7R+Xb6uoZ9BTb/W87bt/Rvw1Le93ub241lmfymex8uxUj7M+F89cLFOcf/VZKZ/jjQRJ0Y/O9bf2imszrF3TSdfKr/vnvLw/lfqq97r2nPP9f7jefydMbT3ud+vZe2SCrHz/C6Fcq7dz3thu362MXU/7Xgr7crvvs2zw/td+OPR9nMCtac29Sm25r1O2dmDbVscSPV6L6Hs4yn8i/uZl6/aS6/dR8bDU6hnhow/qyO975plnRsX6yNVd9mFkx/vjyn66NkaVbcNJ59izvdPnCf2r1oNj+vpctl+W26C/I7/NrmGtbFHvqHKPOves9gz0XK+RP9davbav7FPR97Sc9Bz0nW95vFSeW5lwr3zfa2V9HeX6hLo616DWdu0+l/XW2rH3cFKZyvls1IdR3/Xg+7993/+TJ0/uxPe/dn0ybbxw4vIKacILW68p1/ZvROMrkroALgVxenEqF3j09NNPz9hNwbq9LO4foP/M2L6e/SO/39U34/e5NmeKurO+1Oq1fX6/tVHrk2+/qHOmaL/3XFDOn4trZ9LxZX9m3HWb8dfbb6tc25nyPHzf/T2bdO1q/fP3wd+zDa7bpOejbL96P4s+z5TXtDh+prh2nXZq18sfUx53p983uKbZfat9auXL9rT+2jOZbSvez5nK9eq9LxudF9//3mu2Ze+/CtLs3fXb3PesDV9Give/KL8l73/Zz/L4ss2e9nvff3d8PBf/ve/e9/3QqWjQ2TCRtxyXzmWlQN6UZmzb27oTQtUcI1L99e4vzmY+u/znqaeeip9yv9a3y9Vr5Xa5C5zt8x9XfsbVv6vow4yvs1Jv1kZPX3x/ynZmij7sqpXx28rzcvX2nnu5v3IdZ3qOLfsx46+Dv27ue3kO2bWwdet35fyr51n2t2hr16S6yr5X7vuMdJ+DXZu4P7Vz6tyzyjVK19n9oy/vZa1PffclO39fZ9+9s7pd2U7btq9yXTrX1/e9vK7S/1zV+sf3X/j+P+D3v3xuyx8IVa25HF+WNeKydF4rxpBzYVxKdCeApaKGN5VxoSh8Sw3EX6gnn3xyNqzP6knP6ieu6z6/PW6zY9zFjuu+vJXx5cv6XD3Zd6vTym+0HUs7l6LOXeVxVta3W+tDsb6rVq/f5q9lrb89be+qXYeyvtr1r5zrRn0u+79rUpnaPXMvVO+9q9ynzjlN6FdZ36Rz6HtesmeifD4mtOn7tssvJz03k+5T373ru85l+2X5yruW7k3lnk3sS9mfCc8333++/w/s/ffPV/mxHwGmwXtNHcLYj2mbg5d0zdZeOy694CfT1t3vvTk6G5eR4hdLeSGOHz8+h09YT8vw2a3L+Dl27Jh9363r9vHHzBVleuvT7Z0ydpxrb863VazPVfoR6/B9qvSv83HnlMr7bbUPyhX9nOu5Zulce8rvLq9L7Zra/tq+crv73nvdK+fsr91uv62857Vr4Y+rnXvPsZ2+bHR9Ktcw9c+dn7+Gtes5Vz73tWfVtvdc242enUnPS+2aTHw2intYPge95co+ltfavy/FNdhdHJ9da+H7z/e/0t49eP9r7dR+bHnNPRuvLj3BezTiqvDteE6vHRsnfovts3VxqnfogPzar/1aXA8dSwVefPHFJLiDMG6//vWvl57Xtt5WtsfvR44cifsuXLiQNoZt8btf+jLl/hp2jB1XO2bS8YuLi83S0lJbq9cd0+o59Pbf93tSP1EmPDwtnAbKfmL7+fPnmwn96D2HwWDQbqIvbdjfTLqm5XmjPH4R4hqhHWxEW66NeG3sWNve049UVnqelfJ+GrVrs9H5lNtcHfasxv7oMzBGXb7dje5H8az5539DatcH24bDYWoT33HtZ2ZmxtjWd45lPb6u2nO2mWe+7z5s4nn099jg+8/3Pysr9+H9d8fEdvV72R8JAlrOnTs3DkI5bnzppZfi9qApty+88EIqh2UQzHL69GkIULybcRvkabgmWZ1SnpwKXbsA5VKC+g3TdDomaMPNmTNn7Hs5xSmuh463oeMddT3cqLgMNw3/3NqwjNvw3XcO+3BzX3/99fj98OHDYut9oAweANRVKd+GbbE+22dL7Uc8Z+uL9c2uBY7Fl7JO6f5DqfZLjysfsmzd9UN8+76/1ofyHHraEtngoS6OybD+lNfJ7o0va8dX7mnrz6Eg7fN1lH3Tfa1+byrnm85twvWQsh37btv89ff7ir5l99yeOX1W7RnrvEOS32OR/J1o/bUqr3t5Pfz5VrY3xbNRPqN9x0pBOq7Y35b3oHacv5Z+n3+PrH98//n++zrKvum++/X+x3qwbj8mQBDgretzWg/KaLtv3772rbfeaoIyOlZF1ZdN52rWZpW1GUlEu52tHpV2ydoYsa17Sm03fsKviri8cePGMJxQOag9CCcbP4cOHWp0Gb9rf+L2gwcPxm3hAiWPNfxgwHbJvdiS6Rz7wq/I+MF6OLY0r2MeXCyr9Tb2PbQ11DqGWNe+DfHdjscxWj71A333fcA6ji2/oy+63drpOMHZOdtxt2/fNs/0OA5h9eh5xf7YNt+eC1Jg/bf6oykFx7g+xqVdh+LaDqwPtt++Y4n27Zq482v0+tm52DnHfup5N+4+p/p9H3wf7Zz1Wtt9TWX0Xg5tG+rx98CXR1n/HPn+23Pg9jW2z55Dfw9d/VZHvMaur/6+pGdFn7XYjvXTP/9axj+n2WdlZWXo7m1T3MOhPS/u+NiWXXv0Qz/ZdfD3vXw+i37Ye9RUPnae8RmxZ8J97Llp9B3l+8/3fzu9/3adcB5NeNcGsGSpNWugFrHs2gUBPFBBHJVUWIyDQM4UVGjHZnE263PpvBVXdEOr5uj0S0YPzgSuSv1B+DUQN6AjVo+s/ZoYFL/60/LAgQPNpUuXZGFhobl8+XKS9mG7hO3ZL8T9+/c3V65cGfv+hHKtlQt1iNbRuHUp2syw461u7Ye4+lL7lWXCl/V14Ls/F99H16/WytmNwPHu3GpajJ27FNdM3PmXfYt1Wnl3fX1bjZ5D2c/ONSjOs3OuPdurWkPffZQ62T47P1sW97SttNE5HtjzgvOyH6KVc/F9iGVtA463azKh7azPxXd/jaVyfbPzL+uQipbj2y2vsfa5Wr+dV3kfyvPw54IlrlvYP3B96bwPMuHe2XF8//n+y/Z6/9vaMgjz+Myr5aVVc3erFuCxloVm3AYZme61mauxE+I0CH9RU3WmHXthLF56+zLQis+ePRs3aiNxPYwJD8KYMFajQEbn8EsC9b3xxhteCK/1cjwe+PauXr0q8/PzcQmwbtv7KMtbHbhI4WY0ZTlfPpgSmvALJjMbhP1N2J/dsLJe9Nf3yfczPATVdm0dx7o2rb3qeZT1WxvuuCYsW7e9r7yv1/65pX7W2uu75uU9mVS2tr+85vrd/slmx9lQCfps10n0ZSrPxd2TJNCUdC/tnF2f2lq7/vyUss54rOtTp66+a+r7Lf1s9Fx0+rPBczbxXSqudbwntq71Zu1t8HzJZsqhfrz/9o/P+sv3n++/yLZ7/61sVm/QmNuLFy/atrHbXwrkNmjIbRjGbSeZrMu+l8K4NYctM1Obtgy1G6p8aAAOW14jbnRgvFFbvgnrRn8hDVxbjb85up76Ars7VqDyF51P3/fu3du8/fbbEpbJtI7yxbGpXHEBcFx2rqFMvChWH/oT6hLdl47TMYHUz7Lf9h31Wz16nK8LYwvijpXy/Io6fd2xj1aPvw4A56HbWjtHd/6NtW198fX2XGs7n1R/0d+2cn7ir2NRt/W/pnFkfbZ7CXAN/HnbMW6blPt9O0V/Eui31e+2ZfdVKtfE1RfvTeXellqN1Prsvre6Hu+d9Uv7Jm5fuk7F9S3b9f/40vbiecqeB/cupD7W3if/flTaT+dQXM+B61dTO2e7Rnz/+f5vg/e/FJJ+Ca0fL0wbhDLGm6PwDTIvCuagnI5VOU1asq8j/BhtTSOujR13fq07zTian9RxK2nD8JwOvzaSRmyCWO35UMERKmwQysT6IXDdRU2mkXCx/EXOTCJ79uxprl27JmEpYZndNNtnaBlxJ92448pzbK1N1IMNemypBaXrU+mDFH3xfUrbfB1lv8ryuCG4HtgQ+heP1e+pHvQbD71dF3dMn9blH9zW/2MRd53tYbC6fN+sz65MeU62nu6DttXY0vU/fS/ume9r372u3Z9Ud9HHdJ3982Vt9tzPVuvpnDsony/frtVl903vUTof7UNVsEv+XGT3yT/n7n6Lq69zjdwz0ttu8eyUz0b5vLdFe7G8P0c73v5p2w97ewfc853eOWu/eEb4/gvff3nw73/SiAtBjm1euJqmHAXxsWPHxqPRKB5XMVn7c8iWmlAjttMUJ5f+objx4zgY7czTTVDJB6FBuIM358+f7zhS4Jij/+Ib/+Ng9/w/lWYwL4QQQsjDTLv6N+Mbb/0fb//M3/6XwaxtZmp42Y/hzW0COchGE+jjYK4WmKulK4yl/J79onKqsxTOW5mTlnQ9GeMy2OihETeP/cxf/4tmbu+PCSGEEDJN3Lr+y+d/4vF/pmPSJpQRe2DsHLpMk7alOT9npmtP09OcmaaT4xbGgl977bXBrVu3Gg3kMdBJ8Jk7/OJPvPB9M0c/9BtCCCGETB/t7Ve+/J8t/cvv+39FBW4Yph2/8cYbSfg+9dRTYw0IEoWumqurpmpjkGp3c57MeQte1LB3QxBjzDdU3viIWpiHFezmaTwZ48PD/Y99nxBCCCFTymDvuz4s69Zhmz2UZCNkZRDIZjlO0Sp1VoHNXMrmGSdhHAeQNQIX8EE+4EGNZag8SumgjkMrxryrJgxgF+bqsdwrThways/9/T3ysWMjIYQQQh4ATTOcmYfyiSlYOnc5BiCxEJ3BVB1HeRGdyx+o4TAtrWLy0cIym/crXTf3GFEE3xFzGiZqbENcTwT2cL8Gkse0k+9bT6j92PxQCCGEkAdGO250rjOCoUAgQzsWy9aEMNAY4tVcDQkEABF1/LJoXOYJXkpOs3GnClz8acF0Jg11KRanFejE6bWpS+24kS3kj/7xQtSGv/XfHpRTH1/Tio/tWxfI8fv8PfwBQAghhDjc3OrMPA1hbEkyDEwHVqUWkbhsc6kAd9VYNKIm6gxkqYDqbZksNLhHDC+mEXsaP6/sboFJ+mOPjeSPzt+Wb10dx+XZ11fi8srNNu6bn22igIawJoQQQu4XLm4GwmvCfypLUAF5iSViVqtSm7AZS61LAjHSHZY20c1mygkD0nFpQT60E1FV10ha6vy1uiUC+dTJPfK4abxBAH/s2Exs0saL8f1j//tl2R8E8onDM1GD/tbVVfn0r78lhBBCyL2iErgGAUAaTTACC3IsByXWZKfHgmtZwogY89pV7jM1+awTULMRhzqNF2sKxNZiTmsovFhNMHLftTD+0e+ek6s3x1ET/tbVNYewPzq/EretLdu4fPap2XQMtOT/++XbQgghhNxLIEARsQuCGKE11ZErjhtjNyzICIxlflYgWJxbHTNOJmolCt6RVSxrA8pxvBhmahxoB7lB6Li0KU34JYBOyJqJem1/0xtabtN87uQjxZa697RpyZ/7g2vyi1+4KYQQQsj9QMNrRvmnSSwss5PlaGg1bHRc19gdST66ANXx+0C/tN48XRkzjgdB9Ybrtk5piuPF3hP7kUceka3QjM9f3fz0KJT97W9QIyaEEHJ/gUDGEK1lf8IMIzdubFOCs2NUO05COJva5CiDtkdPMFuH6g0zdWgwCmcMWpuJWoPqb4lm/FvfuLXpsj/3J9fvSHgTQgghd8XarCFLJpPJvDCM26pHddyukbiA96i2mB5STm3q1WbhCWaYZmzs378/VgoTNX4hXL9+XbZinvEv/vlyHBfeiNN/cF1+7aXNC25CCCHk7hlLsARbVqmYWxmWYnhUY3rTYDDwU4SbkydPlhX4od8s6EcWK9PiUtvcKAMZKZwntViaRFdpK+3KlpipP/3rV6MDVwmE9G8HzfmTv3xF/rcvLAshhBByf1kTnW5DDP6B4VugcjICM/ULL7yQNGVvpvaRuErBmQSrOnGl7Ezwpg6D0TF/8e3bt4eQ/qHhwb59+4ahwkH4DMOvhMGR57/82eH8o5+RLWI+Tl1aC/IBz2qapAkhhDxIVq++9vkLz33w87IW/xmfVSyDZjyGVjwcDsdLS0vY5vMgjzVzkwXXysy/yZta7dYxcThs2qYdG+oV5iV+FNI6ZhyTMkcHri3GpjERQggh24MoX7PoW/horoZWp/+aNtwgRjWGfDVhhBHHjDVxRGtzhlLAaudVnQadoWaH8WDE2/T7klQPY8ZtGMge+HnKhBBCyHSSm6nn5+dbaMTBVJ3JxmBRjopsEMSlcPQZnNYduEwA++lNPugH0kE5QRyL4qMOXPH7ugMXIYQQMvWkcWAoskEQy4EDB2IUrmCmbuHwbBZlnZUk4nIZt2vab6psUFScsPyLroIk2Q8fPhyjb125cqVF9BGd2tSxgRNCCCHTRzRTtxr0I0ahNGzqr8c0Y1NyS+ctkEJbtTZwrDEzEYHr7NmzEMod72hLEiHrY8aY2hS15T/7Jwvy7ncfFEIIIWQaefXVW/K+n3kkasaQfxqBUi5duhSDYr3yyitN0IxbJIuAojo3N9c88cQTbRjyNU3aC+QmjRk7B65kqkYuxlIQQ+1G4A9oxisrK7FhoB2hVkwIIWRHEIZlkzUYFmLTjqEZHz16dC3e9GgUlVrkd/DOW+q4lRynsS2Fw9QySaDC/fqZZ56JlRgufWJc2phxShJBgUwIIWTKsaAe3kyNoB+WPAmaMeSljRn74FlBCFflpAX9sO+dcJhaSVy3tFD4HrTiVoN+eM34rgN+EEIIIdsZaLVYYkqv3w65KKqYBhO139dqEC1E50rbXG6H3Jta1jNLIOhHC3O0bYftWzXjmqMWBrIRHoyaMSGEkB0HInAhHCYyNwUwA8krp82ZM2ewzGSks0p3E0Vo6sQ4ZuwctbIy+KBR++4cuAghhJCppwxyFczUUXZqTuNoSYYSa/ufffbZFLsD1uigITc+NoeZqcs5UHHMWCV5JEj5tE8lvxETRWj2CkIIIWTqgQMX5J76TEEzFkTggkX5yJEjLSzJcOCy8lBubWoT7NMI+KHrnRSKKbSX5TM2Sa75GOM+hPmCt5iG/YqoZhyjdAkhhBCyA4Dcs2lNojISQhephs3HyucztrjU0IqxbNbIUiiC1rI3QRhDgpsr9ksvvRT348/S0lJsNJipWx+BC/vvRWxqQgghZDuh3tQ1orBFqmHzpt69e3cs6yzNDTyq1VcrHzNWydz4wNQqwf3UpqQZA68ZIza10JOaEELIDkC9qRsbnsU8Y1mfUdRYQiXEptYZSZnjs40X6yfLZ9z40FyaPjEehIqgZoeB6E6HbGoTsjZhydjUhBBCdghJCXXhMH16xFbnGTeSZ3iqTSdeC4dpNmsXCjPuRO7Fl19+2Uv2Jpip45SnYBdvezp3z1kJ496Xl8eyvIL1tSZHwQS/d1cjC3NU0AkhhNwXfDjMUvg0QTNud+3a5Yd6m1OnTrXPP//8WgE3tSkLh+nN1DpmHL9DM7516xbs31G6ozyyU2CMGR5kFvQjjBkPJtjS75o3rrfy7bdWgyDub2JutCaQ37N/GNaFEEIIuRfEbIUQxhoOsxyujZqxc+CKvlWnT59eL6AKMEhjxmq3TkE+Tpw4EdVsjBlDqqu6neZRIdIIBLFhYcEsMslW8vYtkb9YWpGzr69MFMRgeaWVV98ey598+7b89ZVVIYQQQu4BUfgGZbQpzNSZWRrC1nyvYG0uwmE2NmacdEcfnxo7P/3pT8fKXFLk5HmNecZBICOfcWPjxjjuXowZLwXB+vVL42SOvhPOXR5H4X3i8CiYseWOuXbtunzzb84Lydmz+xF57/FjQgghO5xMsOIThnHHyN+AcJjnzp2Tubk5mLJL560oZ4fDodh8Y59CMVmpgxpdtX0vLy83q6uryNhUhsTE+mCrw2FCEH/lzbvTbiGMoVV/1+KdC2QI4n/+0z8vJOdDH3y//PQ//++EEEJ2KpjKq7E1ojTFVF8opxq5EnLS8juYPB3bdGHEp4aGrII4D/rhB5IBDtKgH7EgxosxbwqTmbUxrxWbN/WWmajhnAWNeCt4+1Yr37hEkzUhhJAtI8o7i8Cl8rDMgNj6oB+6fU0tDsqvfYDXjNdbCIIZHtVnzpwZwNZ948YN8wbDPOM4YVnzGacGMZC9lUE/oM2+E9N0HxhHXtwzoLc1IYSQraK1CFyITa1+VCnoB4DsPHnyZPvCCy9kwseCbNUicDVOSjdIFNHXuuUzRjl4kdk8Y9miqU0QnMsrW++UTYcuQgghW4H6SCXZh6xNts+Hwzxx4gRmHCUHaSi65kXtJjBlZuokqXGQ2bYtKTLGjLG0cJhBK442ckh1+2WwVQ5cS9e2xjxdgvHjjbyxCSGEkE2QfKeCUtpRXoNm3CICV1BsTY7GMlB0TSn2Ebj8TNzWS2l811iaTVCzs/lTCPqhZmprINYczNR3bQNeC+hx7wTmGzfGwVQ93FTZPY/sjs5KJOf4ex4TQgjZqZTxNHRqU4vUwhcvXhSYqTUkJqYHt5iV9Mwzz2DoN44hw4FLCktyFvRDl1GgIugHHLVMILtj2jLPsUUg2QrNGM5W95IrdyDo3/uex+k1TAghJMNiU5fbIYhFY1MHMzWib7XqTR0jV2Lf6dOnbazYMjetjxmrILb6WguHqYI4JUQulgnYwxEweyscuO61ML4XY9GEEEJ2HK0Gu2o0UUSMTIntSKgEB65gVbahYItouS5oAzrnuDO1KROyLmtTGqC2Aekg4Tudunbt2pZIua30oK7XL4QQQsg7BmZqDMtiFpG4aUw2wwg5HGybW5axOcyRq5vPWJ24skZd1qbGXLXNTA0HLv1FEMNhMmsTIYSQaQdm6iDvWkuhCBYWFnrLQ6lFKExZD5Fpzltt5sBlY8ayJpBNlY6COgjixjJOBM24uX37dpT6QR03By5xWSvuGiR6uJcgsxMhhBDyTjEHLrMIw4ELwhhmaufYnOywUGqfeOKJdLxqxCZrYx1ZCkVZ94yOgti8v3R70oxlbWqTuXQnTzLZAu61sJzdnCM1IYQQ0ouGw0zfdZ6xN0unMJhW5nOf+1zcf+rUqVjG4npgfc2/WtVkJe7AQerAJa5yv45EEVEQWzgw2QKBDGH8TpI6bJZDj9zDygkhhEw9aqZuvJla8Vmb4nfN2BRjd2COsTlIx41rw8JVzTipzy4CV6um6vgdXmLBTB3Xr1y5Eo9ziZW3RK19bN/wnkXLupNwmMs3b8trb1yU7cb++b2yf9+eTZe/8tY1uXJ1a4YRNuLRQwdkbnbXpssvvXFJbt68JduJO72+hJCdBxIjBTN144ZpoyDWrE1JprpEEa05Rpu/tAX9gAy2oB+N7mhLr2pxEh5jxs5UHc3ZaqaO2vRWxaY+Nj+Qb7+1uuWez4+Feu9kTBqC+F/969+V7cbf/Q8+HD+b5Utffln+vz/9otwPfuwf/ad3JIz/zb/9g/hjYTvxA5/4qOz/zieEEEImEMeFzV9KUwqPyzgcCIdpc4zL6cLmq4Uv5sAVtWMviCHB4f318ssvNz6Ul+EGqq3ybA7V3QAz9Xv2D7c009JcONNj+2iiJoQQsmWYZtyqpdgct6I8tHCYjrZnfT3oh3RNzDZJWfw+mKkh5S02tTpv2dSmLfO+gnZ8aPfWOXOdODy6557ahBBCdgZw3gpyL+ZmcLGps/nFSD3sUijGgFrIemjTiL2/ljdTe4Gc1GidZ9xielMwUWfC2fIZ45dBW05Q3gI+cGgky0srdx2V6wPvGr4jL+252Vl5/LFHZbsxP39n45kof7/OY3bXzB2Vf/TwgTs+n3vNPMeLCSEbE8eMsRKU0ig/NTZ19J9COEwki0Buh5MnTwpSKEIYm0BG9C0srTIzU5dJIjBBubHMTS5RRCYVoRnDq8y0460G5uqnj4zk6xfHcQz5ToFpGhrxO50u9eihBfkvfvAT8rDz4TD++eFtOgb6gz/wcSGEkIcNndrkpwWPVRBHbyf4VyFY1rlz5xodV8b2FtOahsMhZGc3hWLpswXJrWPGqSFUqg22hw4dwrZWNeN7Huz5yYMDNTNvrryNOUOQM8gHIYSQrUbN1HHdYlNLbmGWIIgtHkcmJy2fsWfgdppHtW1qnFdYMxqNLDZ188Ybb1jDfp7xPZV6hx5p5Hsem5HvWhzJY/sGsn9ufT4ylhgPXtzTyPsODEO5kRxfGITtFMSEEELuCRabOvlOwUwdaI8cORK9pOHABc6cOWPhMOX06dOxjBRJmJKu6VIoxvSJWkEyT4eBaBPcSVqrmdqmNmX77hWYJ7zZfMSEEELIPSJmbTKBLDrii5ULFy7EDUFuxu3PPPNMa8O+0vXP6iSKSGqzTWsCGj0k7oBmvLi4mCqBmVo141ghslgIIYQQMuVo1qYUFhpAqXVZDZNlGfOLg0Bu1HnL9rfeo3rgD+rziDZVe3V1NZbDmLGp4/hjk56ZtYkQQshOQLM2xXnGaqZuLl5ci9jolNakoMLSjMiW8KK2fUqmGbflgLKG7cLUpnbXrl1R8w2qdzwIY8bmvm3ldSD7npupCSGEkG1A0oz9NvhaLS0t2fdsXNhM1eZJrZpx3JaZqQvFGAPOCHJtKRQjLmlyBJOdwy8DmqcJIYTsOHrSByc5qUE/fDAQzDFOBU0JTlmbsMESHgOMGSMCl4bCzICZGvmM4cCFwxEKTAexKZQJIYRMPZqLIcm8hYWFFnJR1EFLZx+JKbPqh5UsyhaG2o5P4TBtENmbqpHPWB24fKNxahPCYVoErmI/IYQQMtW4gB+Ry5cvR7moDlylZiwwX586daqTiti+dKY26bo4N+xYGZyzzp07lzViaDhMqdjPCSGEkKkEsakhL52pug1CF0tkOIzyEJoxFFs4cGnWpjhmrI5cuWbshHDbzaC4VpkKYjly5Ij4CuBFFjrS0ExNCCFkp6BTmxoniBtkMwzDuJ3Q0RDCZqY2OWvOW9nUJme3zoJ3QJo74rYLFy6ksJjSTQdFzZgQQshUE7TaUt5F2RnM1G0Yxm1VaU3bZS0LosBMrcK3VT8tKac2RXwoTPzRCFxm8+5kdEIyZZ3sXEvBSAghhEwdSJBk6xoOOhPOtv/48ePxuwXPgvDVFIpmjW7KoB+iO2JlLvhHalArTd/hNeYcuKKkV+8yQgghZGqBZnz9+vUoDzFMq5ujmVoqiSIQrwOWZohWTGtyZuo204xVMkcJ/bnPfa5RqZ2ZnDFmrKp33AevMSx9oghG4CKEEDLtFJqxn0McsXgcFr0S8Towbnz69Gl4VDcmlH1sD5+1KdqwgzBuET9TVLpDvdZ5UhaBKyWPgJnaDodXGTVjQgghO4Eg76I8hAOXpVBULTcN21qiCI3XESWvZm1KMtfKJgcu86KGpFZhHHFBP5Iqfvjw4VipmanVmzpTzwkhhJBpRfMZp1TCQMNEA0s5DHye46js+jCYUmRtSoK0NrXJHwBcnuMEYlPTTE0IIWSHkMWmRgQuWRe6UUaamVrWBXKm7IpTYG3MWLRg8t2CuRpL5GEsD0I5HaiOYMxYO8WpTYQQQnYCGJ6N8s9SKIqbdXT+/HkzU5dyNMWmbteIx8QIXH6eMYDkNukdBp2Ti/bKyoqgAaAOXKlTsibYaaYmhBCyU/BBP5BauA2m6o5SqnI0KqyIvjUcDuOxbow5n9qktE4YI2tTiq1pgtjK4Q9+EahrNzVjQgghO4Yy8iTyGSMCl8tnnOSnlmvgUV0miQApNrV3sVav6kzLHY1GZWAPP3Adkyxrx+6KK1ffDp+7r8fYP78nfPbKO2Wr+7MR7O+95W77+0fnb4fPimxXPvPR3XI3/M35Jbmf/K1ji0LIQ04LpRTaLpJFIAIXNsKByymwrcWn1sAfMTa1jgtHDTkKY5XSWe06xWlQelMHiS+aODnThOFNjVidcpfgH/O3vr2V/xAW71JYbHV/NoL9vbcs3qUwXpGf/5Mbsl25W2F8f+8FhTF5ONFwmDFRBJRQKKVuqi9oTRC/9NJLrc4zHj/77LPNc889N9Y5xnG82MaPbWpT1hBKOM04uWTjiwriMtJIXNKbmhBCyLSDoB+IqwFBrEGvMrOzmanVm7rRCFwxPrVma0rHmFU6y9okKnChM2uGCS+IM4kNB67wS0AIIYSQHUgDb2ojmKibgwcPxnXTnH1Zy/UQv6yHpk5CfORLrwUEiePF0UwNldrnNfY2cPUaS4equn7XDlwY04MpcatYq+9uj79/pjT2995yt/392DG8MndnCt7OPP4YzcaEbIZgCY7yzjRjr5xqdsP261//ug8tDSW31exNkLVjX1/Sdk0Qu4NMEA+eeuqpJti9B0EYN7dv3x4EU7VNYxqGgethsJcP1IFrGDrx2Xe/+92fEUIIIWQKefXVVz9/5MiRz4dVCFQI21Vdx7INZupxkJPjYKYeB4Fs/lVWFvJ2rFpxA2cuaMfJTO3nO0Ez9hqxR8eME0EQx2M0HCYhhBCyEzC/qehN7TTj1uRkGfQjaMRrB6rmi3SKYsPDvmanHXvnrKgFHz9+fHDu3LlGv3vNeADNGOvYFjTj/56aMSGEkGmlTzM+cODA+NKlS2NxWrIUWvGaMjzuzDPOHLi8Z5eGw+zkZVTiPvwS0HnGVScvQgghZJopwmGCbNqvBv1ITtI2nQlLTRiRZ21SIZzGjTG1CYPNroFOwA/L2iQUxIQQQnYQljLYhcNsg1bcHj58GOtmXW52794dI1kqUU66fBBJQ/aasff6EkxtCuPGjVWC2NSOlEzZ8jhinfmMCSGE7CA6SqqbKhy/vvjii40LntWa8uvSFueJIkwztiPMgQuTlbFdzdSNRuBKwT4sj6MUwpyQh53f/sYtOfv6qjzs/Mfvm5ETh0dCCNk6rl+/DpmXxoINDYeZbYNSC6GM9XbNOQurmeO0hcP0G2vJI2IkEfMMq9Ba527cuCnLyzeFkIed5eXb4bN941BvluXlNnwe/h8VhGwXbt68CTN1q1EnS6U0Lo8dO9aORqOoyEIztjnGlrVJnbhSnZ0UipDayCph+YylEM5BK47bDxw4EKNwwUytA9ExRuft2/gHdksIedg5+Rg+Q3n4WaUwJmQLuXVrpXXhn1u3TOsaIKs9ceKEhHHk9vXXX4dcHWvWpljWm6s7tiuLwCU6+Az1+saNGwh2nSS+VhwrC78I4nYNC0YzNSGEkKnGxnn37t3bIoUwlFLEnIbGe/HixcyZ+ezZs+mwIDsRTCvNWupoxr4N7FdhnL4HQZwVgoQXN+EZ2zToBz2qCSGETDXjtUCWjQrlsQW/kjUZOJYeHyoIYgT+8NEurVxmgi68wKygzZMq5xmXRE15PBZCCCFkakHWw2ANNqELGheBKzo6A83a5GmCmTrNI+7MM7ZC+GO2bKxjwDmo317iRw4dOhTX0bhObbJ5xtSMCSGETDVQOvtCQGMY17I2aaIIIwluxPHwoTCBCePG3K016kc8CPOMMSZsZmpkbTLgwIWgHy4C11qFVV9sQgghZOqIwnR+fr61IFgYxr1w4UJZLguiFUzVyYacBf2QitnZvKnhkm1makuf6IFmjEFsIYQQQnYAqnQiU2FcuXr1alRIkVq4KJq8qzV1YjJRW7hLc+ZKeqyLBmL5jJO2W2rGPsA1NGMNB0aBTAghZKfQkXkXL16M28OYcTJJiwsXHcaL1zYGeetiUMdtFvQj7fRJjYFGDonrphkHNTzrDAJlw70b63TgIoQQMs342By2bWFhAWPFUSC7VMNJYD/zzDPNmTNnEOxjjClQemyaa2yJIsQvQcVMXR2Ixh8VxNSMCSGETD3mAa3xNSKXL19u/IwktSSnKcBw7ELOB8xHNgFsH1BqxnEjpP7Zs2dLVywfmzptxJixzrGi6xYhhJAdQxgzbtUyHL9DdmK2kcanBklJ1XwP6XuK/KGznJJm7CW1OzDig36YIIY3NXAxOdc8wiiSCSGE7Awal0IxasyWKCIM67a1ecZpBabpoCXb99KBqykPKDly5EiS7G6SMyGEELKTiOZnaMZKzGescTjiB8mV/DAvzNQWgUsDfrTl1CazdSdBizHjMODc14nYKOZVadAP2M4b5jMmhBCyE0DWJiyL2UTeRB0xyzIE8YkTJ3p9q5qebXF7EMaDM2fONEGyN7du3YKUh/Ae6P6hrtsnfv/qV//qs48+uvgZIYQQQqaQ115b+vwHPvAdn5c1ITwOSulqGLIdHzx4cPXixYuYU2R5jstliroF7XhsQa6Ddlwmisg8poMgTvOjesJ62Xr6frdTm15ZelMuLL0h24Eji4fk6OK75GFlZWVVVleZOo8QQjA8iylFg613bGrNdwrTmg4fPhyjcB0/fnx87ty5uP3kyZPywgsvpDnHEL4Ih6lTiaNwNm/qxgfy0KAfqSWo2aHi8M99xeYal0kj1uNr3uV5QhC/+Jdfk+3A0x+Rh1YY417t3bdHds3MiPMRIISQHQmUk7feuiarQWMcbo1AjhmaLH+Dy9wUCYK4efLJJ1uMG6sgTqqqk7md2NRWIC4RssvmGQMMQI9Go8xVG97UligiDGA3fr4VebDcvHlLFhbmZW52FwUxIYQERqNhkFvzQTten8Z7N9iYcahr4GYVZfOMnQNXHDOOBWKypkjWD2+m1oxObeOSRcSKVTNOntY6j8q8qRuGw9xe4KHDhxBCSM7eoDheunRFZoLV8J0CWXn9+nULetVqvI0YmxomanG5HCA/EckS04WDQIYPlkXw8qEy18aMzURtc43VTJ3GiwFs3xab2rzF1Js6rkMzxgRouUswTgvz8HYAfXkYoSAmhJA6+P+4lr3wnbO6miJwIVlEY9kLw5hxLRplqyGlmyCQvanaHLnWx4xlbWpT2mhjxk4g2yTm2AEdoLY64/7QIfOyviswRvswO00RQgiZbtyQM+YZtxb4A5oxHMRMYUXQDzg/B824feKJJ5C5CbmM2+eeey4G/FBv6jyFopqo1764MF22dJFEkhqOL37QGvOMmSiCEELItIMxY6RQ9BG44E0NWXrkyJH4HWPGBszUKohbeHVDEHvH6dKlbC0MVwApFBH0A7ZusLKykkXnOnDgQDa9CWbqYEMXQgghZNoxeacRuKL1GHIRyuqFCxfgZ9War5WZqWFxtvnFXhADL4yTtgvNGJ5fmGds6RNtvpTS9i0Zm5oQQsg04yzA0YF537590eH50qVLcSM0Y0xtKg6zYeAGpmyf4Qkk0Wlu1LbURBGdMWCLTY1wmNhvnYC6znCYhBBCdgJB3sEibMO1WCRNN2jGUXYGgZzlM8by9OnTyVlanIyNwljlb9zgI4L42NSYvIztaEQDYcepTeVEZ0IIIWSagQUYZmp4UuO75mgwwdr6hEq2LViafZm4TYnbJhqVcTDGjDEvCh5hx44diwfBU+zgwYNxapNVyjFjQgghOwEXPStmbbKgH/Cmxmwj04yBZW0y5RZZmwrWvandQLL3oo7rNmZsLC4uxv06nyqxFXOMCSGEkO0O5hnDTI31wpu6KceCLeiH0gYzdZKzMESbVXpSoohopoZ2bCmgwNLSUqywclz8TFOiiDvl6Y98QKaF166P5VtXx3JzJb/V31xalm++dlPec3BGPv4dj8QlIYTsJMxMLXmipOyfJYJkjUajNK7szdRBYI/T2LCShLEfN9ZKm6But0GiN6odx6Af0IyDQE6Nw4FrK8eNt1OiiDtlWoTx1y+uyL/52q3O9t//4hX5vS+moYkoiP/4J98rC7v7Rzu+9OWvye+98EdC7h//zT/9R0IIuedgeLY1q/DCwgICebQIFW3YLCSvGeOPBfwYrCUPyCJwRVW5zSVy9KgO2nEKiwlJ77I24RMDZMNmjvic8Kbm1KaHn9/769udbcu3xpkgBn998bb8r2cuyv/0qf6woa+9/qb8/h/8sZD7B4UxIfcPlX9y+fLlpM1CaQ2yMimpptCKDgHDmxqBP5xXdfKmtmN8YI94YBC2qQEIYh0zjmU0UUQshxidUNsZgevh5+rNrqFj+Xb9xp67eFsIIWQH0rgIXKagRnkZrMc+lLQptesHVgJ/WKIIcbGp41zjMMjcwMaNwB/ihLQ2MkAKRcw1tmwVaHQrNOPtlChip/L4/CCOF3sW9oxkbqYJQjkX1B9/knPLCSE7Hhs7bg8dOoQZR5h9lDI3BTmaJZCAvLXAH2WiCC+IxQ8euzFjqyyKW0QaCZpxo9ObYDsfwHZ+t5oxE0U8eD75vln5lZeWOxryP/z4Yfk///hNuXxtNX7/D4Mg/uHv2T+xrg998P3yz37sR4QQQqYFlXNJUXVKqcWmToLYsHzGGP4tNOP1FIrqit2am7VlbQoHxywTKIOgH5hr7Ct384ytYxwxngL2zzbyX//t3UE7XpUrXiC/b5f8w+96RC6+vSrvWRjKR47NbVjXo4ffJX/v5MeEEEKmDJ8wybZZIqUylWLcDksz5hk///zzcRsUXxXKmWacxokhiIGGxIyTlm16k3pTdzplkUjowDU9PD4/lMfLjYdHQgghJJKZDxEMC5mbSjkJC7OWxRBwctry48bVecbqVT2AWh2keav2bhuYzjrg1XPpzj8mhBBCpgpVOr0/lX0XTAk2Qaz5jMvgWetpE924cRmBK2aUMC3ZTNQazssL2gZhv7BSBMjuJJYghBBCppQYDtNiUyMCl5qp41Rgn8/YCGZq880yxberGeuOWKl+olaswjiCgekLFy60ZThMgGTLQgghhEw5CIcJfDhMKKkwU4PSgUtUaYWZWsnGlf0840zlDhpy0nYxXgx1GwQbdwp96RqJlV6/fp2aMSGEkKkG3tRB3rU+J8PCwoIJ4vbo0aMtNOPjx48nmaje1JmMhOzNsjapupyFylQnrihkNWtTVLthC8c8KvwC0KAfsU5bMugHIYSQacY7KsNMDS5fvoxFVFRfeeWVTj5jHfZtdbaSn8G0bqYus0wUxH2Q8BZnEykUJZ/GlLTlu/Wm3q6JIt7/xOOyby8DXBBCCIlY1qYycmU2XHvixAmZm5uL48oIpKWKbhahC/QF/UgNpYKjEdTuRu3gsRJoxjbXGPmMtyLox3ZNFIHIYBTGhBBCLOgHwkAHuTf2kSgXFxejgLUx47Nnz8YlsiAGUzVyPmSRuGRtZnFr4TAtR0Sc0uQcueJuGzMuBqQRfSvWZIGyLb8jIYQQMq2YBVjHjKPcw5gxkkWEoVzsjWEK1aIcRbeGlgbrySDW5OxaJqdiY9wBqQwJjgFnS/20srKSCVrEpkY4TKx7bzIG/SCEELKDaKEVa9YmnzCi1THjFFDr1KlTmaO0d+CyMeNsrrHoHGOLpakRuLJxYiSJwFLVc8vrKHfLdk0UsW/PbiGEEEIgL5EYSWcQZYrq4cOHESxLbHuQn22Qn1gfIwGTOIdnrxmnrE12ILy8ynCYQCOJZFIe2y36lobDvOt5xkwU8eD5zd9h/mFCyPblySeOyXeEz4MC2qwKYpigLXthi3CYKojj7KO5ubnWQknboRDkzz33XKPzjXMHLudN7YN+ZILXIolo0A+kUGyQuUk70agDl5CHny9+5WUhhJDtyvz8ngcqjAGCXAWBnKY2AZ1nHIV04WOV5CkE8fPPP986Z+lImmdcmKmtwo4KHgRxVsg8yFQQN5xnTAghZJrRoB9xHT5TLj8DQArFuOKDfgD4YsUC6+Ew86Af6l6dMDO1xyJwLS4uTvSYpgMXIYSQaUblXE0WrpmWg6CFmdoH/ajQDfqRalGVWSOEIFJIA29qn3HCsjbBRA38/CohU8GnPvFRIYSQ7crioQPyIFEBmnlGLywsIAtTzNugEbiiTFQH6Gi6Nj8syFqElvYWaT/POAnjdj02ZhsEcdxo4TB90A+sqCCuJVMmDykf/s4nhBBCSB0zLWMWEUQlonDp1KaYQhFBsmxIFw5cqtQmGVmOF4OB32HmahXE8WPzjLEOQYykyVphg0nOvn/CMWNCCCE7AExtgq+UxtlIiZXgTR0EcZS0Nryr1uVWinCZ1UQRtnTjx61WkuZEhUHpRhNF2CB0AzP13r17O3E2CSGEkGmkonRa4qRMBgaLcpaCWFTJVSEs1UQRZqoGOmacHYwV5DHG+htvrCVywDHeiwzhMKc1UcRmePojH5BpgPOMCbm/POh5s+TO8A5cQRlFTuMUHrpE5xl7bTjTjE0ZNgeuMpexSO4pFvdjzPj27duyurqKzE2dbE/m6n03bNdEEZthWoQx5xkTcn/ZDvNmyZ2BfMZYBkGcBf2wnMbHjx9vnTd1shwjCtdzzz3XDtYketru9Vhzsxbb+eyzzyZvMNExY5ipNYWibyRVyDFjQggh04zJOQS7As6ROYbDxHoQxElZdb5XUdlVQZyNH5swblRz9gLWkiFHgpS31VQG6RPDL4JWx4wJIYSQqQeyFMOyGuwqyj+MGUMrtnCYis1KMgW3rCrJ2DS1SdYEcuvmGrfeXA11W/MZN3Dggpm6zGdcBg95J2zXRBE7Cc4zJuT+8qDnzZI7B2ZqyD04XMFU7XZZzGqQhoCRz9hyGY+Dah2048zpOUvl5OJS+zCYA12Py8XFxUEwVeP7ULfZJ37/6lf/6rOPPrr4GSEPDNzG/fv3CSGEkC5LS2/K7Owueae8+urS559++rt+Lghk5C0e62c1jBmPg3Y8PnLkyFgdnseatclM0klIqyNXCvyR5TM2hyzv7RWkeZraBAcujcAV8xmLZqsAZjsnhBBCph3VjBufKAIyFGPGNs8YFFmbIj4hUzbP2IMQmBr0A4K4OXPmTKoUDlzI2gQztYbDbGzgmhmbCCGE7BQ06EeLoB/z8/OZllviHbgMtUY3ndjU6xEw123Y5hXmKzCJH9RxxOC02NRJe6Y3NSGEkGkHU3mhGUMRvXr1ahwndikUkxzFbCRz4Dp16hSmNsUxYyX3plY1uXXm6ThmDG9qZ6aOsamhGaMsgmFjiVzGUNMRo1MIIYSQKccFt8JQbTYLCbGpVU5G1EwNWRrnGMcvOo1Yo21lZmo/xzgjmKmjZEeMzWCmbr0tXBuParqZqZlCkRBCyLSjZmoM1TbmOwVef/11k5GtxaYGQZZ2FFadwdQJ+hE15Nr0JDcAnQSxOnB5vAc2IYQQMpVAgKqZOn4v0ghHpRVTgZHtEHgLsyPbZvOMGx1MTnOiLJ+xfUfAaxcOs9EoXKlv+INfChwzzvmtL9+QL716e9Pl/9bCSD79tx8RQggh25PV1WhaxnhxlHjqOxXloMbhGPt0w7AwwyEaJmzkNNZ8xlZdFMEj9y15d+Hgs2fPQmu2cJgN5kkh4Ae+o0JxWjAicMFUDVfvuzVTf+Vr35Cv/NXDGxv5O7/jCfnO978vrv/jX35Tfusry3Kn/MoXrsuv/1eHhBBCyLYlBv3AEC00YwTBQiAPCGJfRpeYmdQiAlcQwu3zzz/vPa8zb+r4xVI3ffrTnx5opJDB008/3Wguxo4J2kXgMu+xwd1qxhDEv/Fv/508tPwnfz8KY2jE70QQgz88dzMe+8nvnBNCCCHbi+FwTZD6Kb1+WtORI0cw8yiuBxlq6YhjBC44RquobfxxpR4bN4bCY0uhiAq0shj0w9FYKEwNBcbxYsedmKarx1+4JYQQQrYfPmMhZhNhnvHly5cRf8PmG4vKSyizptCanGyLXBCR0oErret4cQSVaSWyuLho3mLZNCio62HMmNOblO89Pit3w4eOvPNQbYQQQu4dsADDRwogl/HVq1f97vaVV14RHTNuT5w4UQb9MI04CxIyykrouLF35oIXGAafRaX60tJSizHjIJDTtCh8EIkE++92zBhjrjD1PqzE/ge+972z0RHrV79w5zmecRxN1IQQsj0p5FyUfWHYtg3W4o6F+OzZs7bqE0j4bXkELr9RnbhipRoOM37MOwyaMaY2aUjMsuK7AuOt5gD1sPO//OAB+VQQqndisoZGDUFOCCFk+4KpTQBmajgw67BtlKE2Zox5xja96dlnn42e1IbZqi2+x6ioP+rNGC/G1CZ4fmlOY0xebjG9CYVUM471qUt3CgtGcj75wd3xQwghZHqAmToI5KioBjnYDIfDOG6MqU3j8TjKTRPEwAtiWQu0lYKD4I8XxmlwGePFQRA3KohtalMqCEGM2NSrq6sDc+JSMzWZEr51dSxnX+9q9H/28jX55tJNWdg9lB///gPynoMzk+v59pJ86cvfFNLl8ccelQ998AkhhDx8uKAfrc/PgD8Yzu05rDl16lSLsJiWQlH8PGNNEtHqelSbVYpnMTddYwONTS3UjKePF19dkd8/1/Xm/s0XL8kffvWt9P2X/vSy/MlPvneiQL7y1jX54lce3nnj9xK8SBTGhDy8mMzzQT80IJZ3cm41AhfmGo+RKALY/CYtu+ZN7SNvlZmbsAlasY+xGdTwqBljXcOAxU6Zdxl5uHnxQlcjXr41zgQxuHJjLL9w5pIQQshOoyLvohzVbId+KnCWihiZm6y85oRYn2dsc55sapNOa8rmDsP2jcoXFxdjKExoxgsLC5nmbAPa5OHm6s2uhWX5dj2ay+Ubq0IIITsJE6DIVrh3795GldIGSioszZCT6vAcEy2JhsREGWjG3kRtddqYcRS+PmuTOnHFSuwAq9y+h8Fq+94WS/IQ8/j8II4Zexb2jMJnKJev5cL3409OtoY8fnRRPvWJjwrpsn/fXiGEPHxA4KrzVvyqZupW8xm30i8L/YylaqKILOCHF8ouHGanQlGhjF8GGoWLCRSngE++b1Z+46vL8tr1/Hn60U8syi/+zlISyD/1qUPyw9+zf2Jd++f3yIfnOS5KCJkeNOhHVGA1NnVnWi8syVBgLZ+xqGKrDlydOlNsai+ANceiJYpoysptm8WmtnCY6NzdxqZ+ZelNubD0hmw33v/E47Jv784YE98/28iPfGS3LK+0cquwQv/E9+2TS2+vyP5HhrKwm7+9CCE7Ez8sOz8/Px4MBtFarFmbbEqwuOlNUbsxQWzTjOOfwpvaCg+c1IZWHAVtUalYBVjqpGevtr9jIIhf/MuvyXbjyOKhHSOMjblREz7d7fOzM0IIITsVjcCV5N3Vq1fT+C98qo4cOdK6Yd0oJzVuRzI3lqZqM1O3NqVJdJ6xFKZoc+BCAy7oR9yP6CNWfkBliThu3rwZfqjdELJ9mJvbJXv2cOYDIXeJV0YFDs3QjjFufOHChShDjx8/3pw7dy6uW9wOrCOX8XA4RDrFNK04y2eMBYSyacbqwAWtuPFasWWsQLSRMHCNCc8N5xmTGisrq3LtOoXxdoPCmJB3jg7HxgRJpoxCLkIQY2rTzMxMFMxBEHvn5okOzkkYm6naxo4RgcvU6iCIo6kaWjGyNq2uxoHE1uczNkF8t2PGMAc//RHZduzbw5CWhBBC1i3AQe410IwhPIMsjNJPrcaZCVododN31YozXy2vGXeibWkUrsZvX1paSodAEJtLt25r79ZMfXTxXfFDCCGEbFcQ9ANyUzVjUEaqTJG4YEG27RDC0JqrY8axROvjVkf7tmh86lZjU1s2ihbZKAA047Gqwpj8jF8JQohjdnZW3nVwQcj2Ab/KCSF3x/Xr17MxY7UUpyyH+mmDVtxqBC71qxpkCSKM0lc2iwqCAWc3zzhu14HpSGg4TnY2b2rZghSKZLoYjYbhQxM/IWQ6Mc0YlmJE4Arjxq0prch2eOPGjZjH+JlnnkFYzCiAERKznGtsRuUotc0xC6jzlriAH9lAtI9N7b2pCSGEkJ2IJVAy6zEcny3ohwniAIJ+dOSlCePWOW/FPzq9yRO/I2ky1jXsF7ypbV8nvBchhBAybZg3td9muRo0UURCY1MbUVZi1lLrw15KEb5Sd6YCQa0WKQQsJD7mGR84cCAKX2jGwUydnL/u1puaEEIIeQhIsnF+fr61XA3OmzoCzRgpFDE7CZ+4081cMkrf586YL8aMi4ab0Fhz6dKlVJ5BPwghhOwUhsP12UfwmbIIXDZ8K4USqxmbbIZSdHzWfMapTCY6LWEExoshwWHjtjFjn8+4bAyJImQtNrVQMyaEEDLNrK62jeUzdtOCk9+VDudGzEztInDBo7pTZ9piEtrmN5kEN8q41FKZU8V8xoQQQnYCloshDNUmOWoWYwznInw0wmGqAxeo+VStC+i0xQJUy7onNbRj2LqxPkEzTuo6finQTE0IIWSacXIuyj/nyJwE7vnz573wTU7OmNYUD1zLB5EyI3rR2bqIILESaMc6WTnTjOHAhQrUe8wSRcSUUjRTE0II2QG0iE0NXBTK5tChQ2nW0Wg0itvVgSvKy2J+8XowEL/RuVqnXMamGYPQQObghUQRWGIAGxG44oHUjAkhhEw/jUad9MppZooOSmyUkXDg0qFfvz8r39GMVR6nAtCMbQA62MHjwXDdhtcYwn8VnSKEEEJ2Al6YNjq1qUE+Yxszllz4VmN3GFk4TJ/T2Ao+/fTTPgqXVdBYpBEAMzXU9SCQGfRjSvjW1bGcff12Z/ufvXxNvrl0UxZ2D+XHv/+AvOfgzOR6vr0kX/ryN2Va+NQnPiqEEAIfKThxaThok5ljBP2AwooshwCxqTGmjNlJFgYTcraatUmTRMQdFnkLS9i4nTt2A0mvg9KtxuC0euwXAo3UU8CLr67I75+71dn+my9ekj/86lvp+y/96WX5k59870SBfOWta/LFr7ws0wKFMSEE8lJnD8WsTRC2w+EQgT9gXW4WFxcb5DSGQA7KbGNBP4IgttDT0WlahXKsb6QVx4Wop5eb3pTs4fiukr5Ryd+4fMYRzjOeDl680NWIl2+NM0EMrtwYyy+cuST/83/+qBBCyE4BAlc14/gdkShFNWMI1sFg0Jo3NYZ5NehHGTI6CWV8SbGp9dOoduzbtTHjNJVJw33FrE2+XKyQuvFDz9Wb3dGG5dv1X1mXb6wKIYTsNHriaiBCpWh2wygTLVGEFMmWZH3MOG7PzNRWwM0zbtUDzA80p7BfwUwdRS8icKnNnJrxFPD4/CCOGXsW9ozCZyiXr+XC9+NPPjK5rqOLNO0SQqaRTqKIYKaOclBTKMZ1jBnD78qlUEzmaasnmal95W4ispmpswaDLVxWV1fljTfeiN9hK8ccqz179sSpUdSMH34++b5Z+Y2vLstr13MN+Uc/sSi/+DtLSSD/1KcOyQ9/z/6Jde2f3yMfnn9CCCFkCknyEePFQUlFqMvGacbt8vJyA4EMQRwU3fa5555rw/jy2sHrDtNiY8ZRWts0YzhvqSNXLHnr1q0GYb3OnTsnS0tLqRNuzBhTmzhmPCXsn23kRz6yW5ZXWrlVWKF/4vv2yaW3V2T/I0NZ2M1fXoSQnQvia0D2GerUnM0fPnv2bNwGBy5zkF5FcOsia5PXjC0CV/qOg19++eUmqNhpLpXf75y3oie1xeok08HcqAmf7vb52RkhhJCdjsXXgIUYyR+g8apALp21YtCPU6dOQTtOflmqAK+bqS3ThIWnhvs1JLjPMiGV9IrQjGH3DmbqBvOMcSzN1MRz8+ZNefvtG0LIvWT//n0yGg2FkPtIlKSYZ4yhWo3AFcFw7szMTJyBBAfol156KQrnIhRm10ztNta8qa0y8/5KDUIzDr8I4jYE/LCUUoQYKyurcu06hTG5t+zZ8wiFMbmvBHnXBGvwWHMzNBYe+tChQ00Yzk1yEt7UJ0+ebF944YWU+6EW9CPqsc6TOmVtgonavrsUULG4bo9jxvhFoLGp406OGRNCCJlmIOeCIE7Tk+bn55PwNXmKIFmW7VAFMeRq9MXy84ulkrUpbQQ2palIoRjXIfmxdGPGydmLZmpCCCHTzHDYZJbgq1evRvkHb2qLwwEs2yHCSgdZanK1JDdT9wB37JjBKVQ6CJK+sagiBw4cQCLl9GuAcalJjdnZWXnXwQUh5F5CEzW5n6ifVcdJy3I2IBymz2fs8jvANN1aCEx/7MhXXrpaA00UkYXDtDnG2hnLZ9zpGCH4Jzka7RZCCJkW+oZjLWeDHzNWUlAtjBWbF7WuRG/qiUZlRAzxEt1WkDzZtu3bty+NNWNAWwghhJApBsOxOmbcUUCRu0E0sRKGdzWcdAp9iSlQUHzbNQ04achlOMxGv8cNGtzaMPU7Sf39+/c3PlGEUDMmhBCyA4DyCWGKoB8WidLNMU66Mxyg1ffKfLA0WuUgsyZ7b2qbgGxeXgj6kQoGCR/XVRDH/YUg7gucTQghhEwV0Iwt6AeyNi0s5L4xGNY1B66g2KbUxJitNKh4Ovst5ZhvCvoBNTtUmrlh2xK/CJQopIOwp3ZMCCFk6tEpvVEW2jxjWc/IFJeIS431YL6OS8XKJbwwzjy4ENDaNGOdZ1ymf4rrmscRnYqNYx6zEEIIIVOKc+CqjRtHWYjZR/gCB+ggkKNyi3nGJmfNicsOynRlM1ODs2fPdsJhYkDaN+aP1WDZDYN+EEIImWaclbm0EItqwBEb3lVH6DZYmdu149cq8DK3Y7i2neXkZFRqU5vw58CBAz69YgrzxaAfhBBCdgIWXwMWYkSkDDQa9APzjGVlZaVRb+oI8j6cOnXKvjZ+rvGkoB/Ju9oFuhZXS1uUhRimZkwIIWSqUTkXEyRZCsUiImUsce7cuTSki6nC0JotWUQZ9CPpsRpRJAtcjfBdCPphsamdmdrSREUQm1rUbE3NmBBCyE4AgjjIvyy1MP4cPXo0yUubZ+zN16lwsERb1sRMMy5CcNk84+QZFtTuxuYZHzx4sPECGTBrEyGEkGnHhnzxBxEodZ5xjE0d5GL7yiuvdI7RoV+bRmyJjNM2L4xNapfe0DXvaAjimLVJVfM4fox5VzRTTwffujqWs6/f7mz/s5evyTeXbsrC7qH8+PcfkPccnJlcz7eX5Etf/qaQ+8P3fs+HZf++PUIIubdo0A8wtllFGps6fo4fPz4OZmorHs3UquCOneJbHTP205osp3ELl2wXEjOCcJiITx0Esf0yaIPtXIOKCHnIefHVFfn9c7c623/zxUvyh199K33/pT+9LH/yk++dKJCvvHVNvviVl4XcH0588L0UxoTcB3w4zKAZN4jAJetTnVoTxDbMa/OMRS3NTjuO35PotByMFiEE+NjUlpcxmKghiDtaNCKRMALXdPDiha5GvHxrnAlicOXGWH7hzCUhhJAdSJR/8JmCINYIXHHbkSNH0rphU4WRKKKoZ83fKq6FAWSb0oRgH1YAKjUcuDQCV+bA5VEHrjhmTDP1w8/Vm90gasu36zf28o1VIYSQHUjUcjVroUXgKmcZNSdOnIAcTdOAMb3JrNTeTWukG1oVyN6bGkGtxSWLaHSeMczUzerqKvIZp334A82YZuqHn8fnB3HM2LOwZxQ+Q7l8LRe+H39ystPe40cX5VOf+KiQ+8P++b1CCLk/YHjWJ4qw7RcuXLCx4/HZs2dtMyzP7alTp7A0QZwEuI0ZN+WcJ4/OM062bpfPOIIxY6mHBSMPIZ9836z8xleX5bXr+e380U8syi/+zlISyD/1qUPyw9+zf2Jd++f3yIfnnxBCCJkm4MDlE0VsAgwBtzYMLEUkSxPGbW2nmqkxbhwbhJka05vMgcs34ic/k4eb/bON/MhHdsvySiu3Civ0T3zfPrn09orsf2QoC7tpBiGE7EzgwFXIvXLmUWayRq4Hi2wJrRhjxx0zdVFRcs0OB8vLL0dPWNgsB2qm9gkjohcZzNtBO26kPg2KPKTMjZrw6W6fn50RQgjZ6Wg4zJpFOFqSEUYa/laaKCKWg5O0lXFpi9eFJzY6G7ZtH2Dc+LXXXhtoOEyoQoOgGQ+CVMdc46Fui8ugtg++8IW/+Oyjjy5+RsgDA7dx//59sh24efNmGMa4ITsd3I/RaCiEkAfP0tKbMju7S94pr7/+2s++//1P/pysKarpc/DgwdUgF+17W1nadKbWeVXHYeKk9+TBt9Y24Y85cGFq0/Lysty+fTtObxKXrcLNryIkY2VlVa5dpzDes+cRCmNCpoTV1bbBmHE5ndeiUi4uLjYzMzOWXElcvI4oK1UQr2m/6q9VxqbGAHPMuQgTtVWiU5vgTZ0k9oEDByxLRQT5jGFDHwwaCmVCCCFTjQriTgpFzDZCyOggL5Ms3Lt3b1qHjD19+jRkbxTMndjUNr0JGSXUtm2JkcWlgGpDIzHgtaaJSqjtfIAxaSGEEEKmmyhgNeiHWHhodW624V7kMJYXXnghOUfDm1qdt1LqYWxPwnhtinFHq42C1cJ5gSNHjrQXLlwYQDN284ytLLVikjE7OyvvOrggOx2aqAmZHhBPQ83UrQX9sBSKUFZHoxHkZHaMj9tRixudacbiPKphqjY3bKUNgrgMnxlBCinrECNwEQ+E0Gi0WwghZBox+bewsNAiClewGifrMHytoMwikiUE8alTpyRYn9va1CYvnk2zjXtduqfk8RUkfauRRaJJG43rvjjfKlbIqaeEEEKmHB0zbi3olY39ipOj8LVyh7QYBsY+tURnQ7omOr2JOWaTUAeuNM3p+PHj4huCiTr8CogbMMdYx4w5XkwIIWQnkA3Lqpk6i8NhctNlPvQCOzveEkVYwuNYEIGssYSN2w5AOihNFOEFd8paYdvpTU0IIWSH4INlJdmHqU1YYuxYt8d8xlBy/fxiX5EliogVYeGCf6TGNDa12JwpX4kPkI0BbXpTE0II2Wns37+/GQ6HmGuMqU0xyAeib4kKajh2BVnaoowqwEmQwwfLzNRJokMQw3nLN6Le1K1PoQhv6oIWNnQ6cBFCCJl2kDK4RIN+RHka5KU3Scd8xrA663jxAAI4hsEsg36I03YthqbkNu0Y9COo39F126Y1abaKNLZMBy5CCCHTDJTOoHwiQVKrw7QYM26DkppkoQv6kYSymak1rkdWpxedaaemeMocshDwWtaCfogF/PARuLAv/FLgeDEhhJCpRpXOmMvYpvUCF3ujTJzUrB87aMptcbv/Yuqyy7eYWFlZqVasYcDicTRTE0II2QnUzNQHDx6MSiuCY9k2jWAZtWKMGYsqvgj84bVjC/pRi57VwJsaZmi4ZcOb2kA+Y6jaah9vMOkZdvC1BoQQQgiZamCmlkIDhvOWrMXkSDL1pZdeilZmH2a6XRs4rgb9yIJYi0rxM2fOtDY/Ss3UEcTe1EbjsZj0DHW9zGBBCCGETBtqAW6lCIwFzRg+VVL4W5XHm1bsAoVIJ3V8EMaZy7Vth4s2vKk1hWJsyAJjy7pmPaCZejr4m28vydkvf1NGu0bygSeOyZ7dc9n+wXAQhij2yGg4Oebyt0I9Xwr1kC6PP/aofOiDTwgh5OHCxabOBC2UVGRtksLaHKzMENLRORohMZ9//vlOnVEYm3RWlTlWAjdsfEFMTdWOG5tnjEqLrE1JgNNM/fDz///FV+T3/p8/S9+/8Jdfk7/3d79bHj2UT2e7du2GvPvdhyYK5CtvXZMvfuVlIV3w0lAYE/JwgiQRCAOt05NsZpFlbYrK69zcHBTZFnGpEfQD22GedoE/UpKmge2U9dyKUbBaPmMXxiuhgbBbaMUuj2NTG9AmDx8v/vlXO9u+9NVznW3hgQoP4DUhhJCdhFmANQx0SqEoGtwDK1BeXdCPxpuvVYA3Om68Ps9YJbOPvtXqYHMLzdiDecYA86nQuJtnTKaEKxUBe+v2SrXseJXjEoSQnYWZqbGOqU1QSm3I1mdtOn78eCkbG/WgjhONa97U5eRkS6EYv2s4TD+WHIN+FPOMObVpSsBY5re+/Vq2bfFQPSfx7NysTKzr6KJ86hMfFdJl/769Qgh5+NCgH0mSQinVFIrJygwz9blz51onP80nKym+5sQF7bh04GpNSwZBILcvv/xyg3CYyMu4vLwcHbhEx5UtmbK4TBUcM374+YH/6GPyr/+vP5DX3libwP5YGBf+0Afe2ym3f36f7N0zOVfx/vk98uF5josSQqYH04wBZhIB5DKWSuIIzWcMjTkJY4vlYZZo/CnnGTeWsQlm6jDgPLAxYwT9MAcuzDMOg9Q10zTN1VMABOh/+Q8+Jcs3b8u4HcuuUcfpPrrmrweSIYSQnYOzAEdBqgmT0ncM50JewkyNyJTe98q8qcfrlXQcuCImubEZHmA2ZmxBP9AIvMU00og5cMUYnUKmirnZGXkkmKFHo2HnQ0FMCNmpQDNWM3X8R2ie1ABTmxA2GsBMrYmWQAuNOAjjbKzY5G+a2mTRQMoUik6ix4ZtjrFG3xLtDIJ+DOhNTUpu3rwpb799Q8j2YW5ul+zZw3eVkHeKV2CRKEKnNvl8xjEeB4Z31aM6Tm06e/ZstCpCKFtITCnM1B0wtSmYquO65TPWRprV1dVkptYOoMaWEbhIycrKqly7TmG83aAwJuSdAwVWvamjrdk046AVt7Ac66yjRgVxFLaIaIkl5hibQIYQD9+zfMYJ04pPnDiRpLw5cAFI+9BY2ucSRdBuSQghZEdQUT4bVVJbsyBj3RJF4A+UXJe1KQv+4ceMs/Bd5u1VzDOO3mIa7ivibeVrlQshhBAytVhs6jA821gKRUxtOnjwoHj56IiyE47RTgA3TjDnY8ZSaLeY2gR37CDZGzcIncJ9eeDAhXFjTm0intnZWXnXwQUh24fhBvHECSGbB1kLTSCrL1Wm3JrshDyVNQEMmTuGIFbBHOVuCvpRxKeOmrFmcGpUzc4aOXDgQEykbC7d+IUghBSseV/vFkIImRYKpbOdn59HwA9kbYo/dkejUXvhwgXsS0LZfLBM8R0XZuSR7hQponBBEEOSWxQuKbRmCGIAQex/GRBCCCE7gCRor169mtY1iZI5d7UnTpyICSMwMwlTh50l2shiU2e5FXW8GII4jhmrmp2lVoRm7EH2Ckxu5pgxIYSQaQfyLixaKKLQjLFNzdRRMB87dixaljGdScE6AmulMrYdf8yBSxdrSxXGsSKbZ6ze1MlDzC2jVoyQYMjtyDFjQggh0455U2OeMbBcDYhQCTRiZZSVKkejgqsRP6C2Jq9q/Emi06nNyQVbnHe1TVy24m451nKtL08IIYRMOWmIFrkaMGaMqb+IxyGFPDSZ2ljuRGeNBimFoobnSgdDglsyZGsUfyyFIoArtziBTgghhOwELIUifKZ0zDiaqQ8fPiwaDjNlPRTVirENsakt0qUfOy4Facq1iD+ITW2VHT9+XJASymJuXrp0yTywk92b4TC3B4h6RQghpMvyzZsyHN69DqmxqTFm3PrgV3DgMqUViSIsfaKoXNUx4w59PWqhUuu8KB/oOmI2cUuhqDZzmqi3CbgRb19jCEpCCPGMg7J56dJbmHokdwuUzz179kTfKs1njM1RDvpEEaL+V8HSnI7VMJgibpaSTW3qCFKbE4UKoCFb1qYjR460LqdxmmeMTvlMFOTBMRoO5cb1G3L71m3ZvXtWCCFkp3P79opcv7Ess7tmZItALuPoM6WasRw4cKCxab/AJYpo1dK8Nh68liQijh9DKEM4+58HKeiHBvyI48GhgkYTRUQJf+HChUY14xbeY6odo1OxPKc2bQ9mZtYeOGrIhBAShFOQbbO7dslWoWbqaBmGQhrkYTl/OAwZrpSOXPZ9LbjH2qTjuMML47g92LMbFcYmkC0UZlKnLRymmam18phCkVObthcjhj4khJAtBw5cmN5k3tQQxNCKEZvakimpmTrK0WBlbi1zk1SGdTPDuZPqcXIyvKkh8W/cuCG3bt1ql5eXG5iozVMM3tSXL1+O6/iDjlEzJoQQMs1AVppmDGCmVlkYsxpiODdYkZM8DbJ0rILYa8qZQE56rE5vShG4kEIRB1vQD4BJzCqIYyWIxWm2ckDNmBBCyLTj5gcnBy5x1mPEpbYIXPiO4V5dbzG1CaZpL3Ozg4vvTfkJA9EN7N9B7R4GNXywuroaxofHg2CqHmqZYRDGgxdf/IvPvvvdi58RQgghZAp5/fXXfva7v/sjPw//q/BZDabqcRgzHg+Hw9WLFy+Ojx49Ot61a9cYCSO+/vWv+6BY6aORuMxXq01BP6QrmKP2a/mM4RFmg9EYM8Y8Yx0zThXCTD0aNXSpJoQQMrWYRgvHZYwZw0Ic5GELD+mwuXnllVeguDZBbpZpiePh+GOBuGx42BuVq0K0NFNbmC+4cNv2vXv3Rkm/liiiZSpFQgghU40fMzaCtTjNNtJNMWuTKrWIwuUTLolfL0d4o+YcpHeyb1ulmC9VROCK5fGLIPwyMM2YgpgQQsjU4yNOWtAPhMO0fMWQlwBZm4JSmwluHTM2U3UkBf3QHIs+t7EXrK2p2wjzZQLZwDwrFchMoUgIIWSqUW/qmDoYGQsBvKmRKOL1119vMGaM8WIN+tHRoC02tSWLSGPGVrmPoKW27chTTz3VWApFCGIEwsY6fgngOMTmDJ1as3vTm5oQQsgUAwEKzRiCOFiHo4UYQT80n3EbxoxT1EoDMhWe1I6UwAlfRlaxrKV2ihqxD/iB/S42dSwHyY9fAGh4fn4+7tAIXJxnTAghZKqxecbQjEEwU8ch3TBeHCNqIVkE0FCYUW5aiGnDtF+LwDWwinWDzTMu1erY0PHjxzGZOWrGQRC3Ghg79Q/aMb2pCSGE7ASghGK82JRSzDQKgjjL0qQpFBOmHZsQNs/sjgOXW48FNNNEdOiC2o3JzCb1YSO/evVqVNPVo5qaMSGEkB2BZiw0p60oAxF9C0qrfXcpFCOaQjFpxeXUpl4vaJdpotWcxqlRSxkFFR3jxviVMBwOqBkTQgiZWmBghokacg9fMcf4wIEDMb0wpjcNh8Ms5KVPn6g0xVIs6EdWKpipo43bO3EBeIedP38+HRw04445e3n51lUhhBBCppN2dXXlCqJv+Y0IhIW41Aj8gZgcBuYYq1IbMTO1elKn7WnMWL+nMWM4cemAc9wHuzemNwXteIzpTWHcGNvHSBYR7OXwJovlLlx45awQQgghU8rv/u6/+y3N1hTzGesn+lNBM9Y5xnGbn2MMQRzM1B0Tdfwej9B5TrauBX1sajDQ9YHbjvVBEMbDMHbcBPv5IBw/+PM//4v/4dChRz8rhBBCyPTQvvnmGz/75JNP/KysCdux+6TvGM4N2rFtF02faJp0MmGvO1Q3rQnjlEVChfJA1gN/DGDvfu211wZhINoL6IE4AR0045gwIowfx+9f+MJf/IOjRx/7J4NBs18IIYSQB8dd+zLdvr3yrVdfffVX/s7f+a5/BYdlHS+OQvjgwYOrYZx4rJ7UY8w8Onfu3DiYqFvVjJP2bP2xRBGmCPc5bmGucZxvLLkmbMfEbWGwehhs5F5bHkA7VvXdHxcnSF+/fn2we/fuBvmRra7wvQ3fLfRmMzc3J8vLyyIuCphts7L6PTOtW3mUwY8KlLfjXJ2xXPgeL4D1Ixwj2oe43767vomv17cnebSyrE/+eN8/22bngfas7vJ6WGO1uqyvAOeC87Lydg1tW9FvKevWOjr3wV3rxuorr6W/Fyiv1za7d75da89fT5TTflavq2snuwbWP+uXv6b+nPw9Lp8HKaLN+XMqz1fq9zZ7NuNJalQ7f35F/2ttS7EvPZt2XX0B374Uz5e/7lqHSHE9e653dl0r/U31FNdR+ra5PjTlfr7/fP+tnPbzgb//WrZ11936bprtOCifY51bHIXxu971rtU333yzReQtjBmHNpC1qVVPavhfWVzqTCC79eo/gqZY73yC1G9u3rw5wDSnYCMfrKysQCvGADY05IFpx3v27InlzfTtYlc3elPsgtkLgWW8eLreFv9wJuL+6dwRteN8P2ple47JtvX1xz0Y/h+l+OtRq2NS2++USp8nXvOyD5V72NjDvNm+Tzofrb9xL0T1Ovs+2HpZ1s5tM9evPE77UCtX9q2xc/f96Kl34nnUnsnin0SzwTlU+1Zr705wx7X6nvh3tvM8G7VrYdv5/vP972tP7v/77wVyii557dq1JIxFTdLwmbp8+XIyU2NaU5CLq4hYqcLYm6bbMJ4MB69OwI+4nlpXE7WarBvz8irGjv1UqKT5Ir9x0JCzseQglM1kjWAgA4QNc3E8k1C2YNuI86nac3lhyu32qynbb9SOr1HW6S5+rL+vL+U/NF+fP4/aOfWch7WHiC42PGBlG93uz7kpyvhulBqObROtJ9Vb1ufrcudYbbfne+d61O5Z7bq6Pol7kdEHPMgD9N3K9j0H5XUuyk6kcu5Ybct6yr7ju703vl/+WseKnE+G1tfpe3l+fX2a1Pfavlp7teMry3j/e56vDftQ679dl54+8v3n+//A33+3Hq8J3luNLtkWpmmEv4RghSY8DlpxcuTyJmpzbIbD86/+6q+OIVcH6zGjszHjlM842a1VUp8+fbppvNiW6KIdyzz11FOxQWsc7tySe5VBhU+/HpB8WZdxWxDKaYmQYuETv2Op++JHb0IsI+uD5KuurbHWET+o3x9v+12/rO2xtpnqDDd+1fZhaXWV9ek5pL75+qxO64s/J30ZxpXzWLVzDGVS3Xrcqh6z6s4nrVt9ZR+tvG5fdfVYv1bLsthv56QvQXmtV4u2Vt31acs+9Nwzf91bX9bOy65veGBXrV19RlrbV37sGXDbsmvt+1bpb1uc+6q/JnYfXT/9Ocby/njtb3qG8EEZLN0zEs/NPd++Ld//Tp/8OfrzLq+/PUPl81M+u/ac+2dX25XimqZnz57nyj311ypt03u5aufH95/vv2zT998fF9ZXfZsQxPPz86nvV65cGQdrcBTEmGFkzxgEMdImAgjhM2fOtJCZEKcmiJ2Plmw0ZhxBYQhlHTsuTdWxViRQDh0ZLC0tpX3IdQyTtVbjtenSBA5tubGsF/rLI0Y1Qdv4RaIZoTpds+MtAgqolKv+srM6tb3GZ53yB/u2e/pRtt/7a9G1Oam/ffVmdUyq2+935wXaSp2Nba+0MemXb3VfX/8MHbZIccztGKmfY+d+bXS+ZX1+vz5nbU8/a+fT2PPo6sb3qL3YtfVlynPpY1L/rW21IrXlMf67a2uillI73vDXpXaMa6NznCWJCeWa2v3ZDHz/6/D9f6Dvf3y+nCYc9wVNGAIYq+ODBw+2yM0QhG3mtIVYHJqlqfzEeiF8Yaq2didObfIddE5csdwzzzzTBCnvhao3X8d1zLMKnRtUysTvar7O2tft4rZnmKqvZu/43dZ9f3V7b11aT2NltE6ZRFlO//G0vg9Wplaf9iXebC1X67svK5vByvqlte/reSd1bpa+a2jXSDYhJCbdK3+dauWsTM++Sc+T9D0ntXOqld9Mm5v5bm2V+3ANsbT3ctJz7UhmyvJdmPS8u/s18Xz6yk06ZrP7+f7z/S+2b4f3PwpSmKMRYQsRJzXQFRy2WjhsiSSnLqRLHHtBrE5bcR/e4+eee67ROcZR4I41dnSvZuzHjtfKRVM1Kh64rBNN+Tl27FizurrahMHrtC38ekjOW0FTjkukmbJK8CsjfE9t6q+Osl8wDTSIga3Ho5wfG0n4ff4YvaDi6o9ombhP+9PodtH+pIepqC+2hX5jm7YrlXKpj76M9iWdA/bZ9SjOvy37iyX6LJV75+ppinPIro8tUcb6qutt0b7Hrmnbc45trY9FveLKpvb90o71bVgddg/dvuq98X0urzV+DGKMx1+n4h7656fst78O/vxTGf9cFNenU971zZ+nL1M+f7X70+lrrd6eZ6HzLPrrYdeoOOfqNSnfIWs3FnLvtj0f1h+7Xnz/+f5vk/ffrhX2e63W2oMgFj9G7D82lNs3ncm++7Fif2GquMJxqWkV7ZiBTmKO65pAeaBRR+T8+fMd0zQEM5ZBtY9LxPEEQUiLfffrug8m79a2h18mjf4yybZvkuxXmraXblJZn+3va8f1xdcvtXomnWe53nfumziXTr9tv68X/0Aq/W7tWNtfXJ9au9lxRT993xvLe+2uw6RjUx3ul2jtF3Znm38+sM/Owdr312WDc8vq06Vtrl53O2dft7+eRfnyuev9jqVvH/tdYJ7O81E8l1l9Pde6dk/9uUyqN2ujPEbqz5ZYX3xZvv98/8tzfMDvf6vDra2mCy6FKwJ7QNalbUEQRyEPQayacNwObRhyNCirliGxcebq2G4cO46trpupax306/ED9Rs5jb3JOgjkuFxZWWnwcTGs4zKYr+MSx7k6Y2DtEqShsmORHxLfUc5vRz/LbWq/L39gpLJad3oBrW5fruyb29/Z7vfreu2h6T2+b71sd1I/9JwmttN3vNK4h63R49raPdjM+aMswsFhPAX1Ys5deazrc7oX1ge/v3bP7Qt+3Gkib9CW16Jyvzvt+/Pw23w9/ny1zc4zUitfOwccb9cDjh3h5RwU5+zvhT+2cw53+txa34t7V7vfk7Af1r331Sjr63tW+f7vvPcfil7QLEW2+P139fp2Ou+OlfPnYds0zHPKTAgWFxfbpaUlLCUsM6H81FNPRQFs84mxDvn4wQ9+sP3pn/7pLPxlWG/CZ+zOR+z8k4Zsv7TTmbWtX0IrtmhbA10f6meET/hFMBOWu/QzGz5z+tl95MgR+Jk/YstwQnvwCev47HXr8bt+ym17ej5pn9Zjx5f1+jaz9ifVY+Uq/d1b9t/Oq/yUbRfns7fsY3gY9vbtq/Wp6E9nX60P5T3w51tpfy+2+e21+vvuVaVsVkbr3bvBda9e80qZ3uts/Xfn0Xts7Z5ucB9776e/pr7tWvvl/sr2vbX7WDuPvrrw0XexWmd5/pu5ZrX7WvbDP798//n+F8/Hdnz/Hzl69GiUW0EDxuTl3bqEXJvVj8m8Gf1AHkbZGIRrlJX4YaLKbuPlrCaJ6FqmbaPPIFFkcmrcJwnl8AsgCuRgskYnZiCUwy8FL5STYD5+/HgUzu6kHrF1/edg27L1UpiX5XC8fdw+v9xdqbuz39fv+tNXb/y485j0Scf78y627d7g/Pv60um/f3D6rq3b7q/rI2Wf3HXtLeM/vr2ee5pd28r92e0f/so13F1c+921PleuUe1ZSufmr0fPOfb1v9a3zrHFNdzMfd/t+1vch86+4t73XbPaOe6uXQ8pnrvKtcyeDX985RmvvvP+PvL95/svD/j97zsfWVcsozwLFuBSCI+KD2QiAmFFeRksAxazoxTEpdJbpdSSvSCeqCWrhjxjy0Iw7ypOaK78qMC2E0/bUR773H5fftbK1Oqs1eXbwrJybF9d1T5b//y2sq+bOc9au/4cy0/tXCrlZ8vyG/Sp833SufSU6W0HD3itrfKaVdZni3Obtbpq/eu5r71lpfvDsbym1XqK5R3dv1odtWtQu7aVfxRzm7lH/ppscF9n7Rr7bZOeC/tePJezssnnkO8/3/8J7d+P9798bqOsUjlmMiyTcaqIDlUxHfhPqQ07og8W9nU0ZN3Y9Hxv3Hdb+katI/7jzdfW8V0mnMul5AK7I7wr6+mjFzxttzqx3X/8MXZxsfR9sHJlncVNqfa1aKfTz1ofe86hb7mreCg616q8rtbnsj07n+KcdpXXqae/s+W2si4s++qqfSrXe9cG/ehca/vu2u6779m18teisq/3ulWu2Ub9731+fd/Lc+u5jp37Wj6b/hmvvAOzfX3wz03tnGvXpu8a+OfQXde+uvj+d8+9dhzf/619/zvPu67b0OuM/0CWnTx5MmnBJowlT5yUPm2eszjKVHOENkE80VztvxcVeXN2ZrJ2nckEsvtEld6btMuTLLdJ8SukXMq6mSB9t/pr5d1F7hxX61PZ18203/fpOzdxP1omtLGp+v3Hn2/fdr+vvHYb9Ge0Uf/QRuVeZD/Qas+C++ex4bWqnYMda+37dvqeD992ed0mXW+rb6NytWe9rL/84Vqpa1fZz0n3qrzHff2rHT+p7+4ajibUP9qoDb7/2+/9VyGzmfu1qfff11d7/22/r+vEiRNb9v6jft9OeY59739xzqPKJ2nCp06dih/pCuMUVro2VuyXGTXJXNGURdalfaYtWyfQQSeYS205/opwL/LIjznbL4xiOZJ1Ab7p7xM+nR8KE9oZTmprUpub7Z+d/yb6Uq3D/SrrPV+UQTuurWHtHNz60PpWaXPYdw7+Hk66HrX76/f1Xata/bXvk47vKzfhng7L57WvTOXc07O22WfFXv47eJ5r92XYd+3sWSjPd8Kz1Xu9rC7fLvpfPtM916nTPt//+/f+m2bnNDy/nt5/v9/v858f+qEfStdJy098/61M3/lU2hz11V97//uO99vLcrXrIWtOWHYN4jqEbmmOhsDF+LAKZJCEMaiNDxfrGwtk59RVs3l7koBWQZyEs+RaczJne7O27XcPjC+TCfWKoLf1dHyl7qys74MrO+jZXjPBT+pn1g9XV9bvST9YKu0N3I+cYe24Yn9v/3252nlJ/s9qULaxwTHDvvPZ6Bpu1O++vkw6z+La99bTt6/nWRkVx5XHDDa6BuUP1vLebdDH7JmonX9R16Y/5XF27Ta454PKOWbPaa2PtfeH739ve5t6/1UY9PWvU06FaN+n+v5vcEznAwFWO862l+WtXGV/9f335X0bm3n/N2rDPxNO+43bn3vuuVILziJOmuLqBHFTaMOdfdLHRgWK8eOsA7Lu5NXxwJbCtG0PZbksP/4fmD+urKuvHvdDYVOfvvr7+tZ37GbbrB3j+1yrp9jW9JXBZ4PzL30AMr+Ad3IO9nz0HestKhvcy+Fm2t9EmUY2fl6GE57HptbPnraG/h723cu+57XvWZu03d8vW6+VL/w9GpnwbPlzl55n3v/4vtPnnu//5GM2ev+9aRTaWWEqzfqN6TW1/XZs+V09gbHuBc/Ej68fkRjhRdzXJvbbc1OWsT5ju2mjG7W9UR/9OeKcTLjacdpW6ot9137666vxOtb2ab3pY0AWlg5apWl6ooyd4MBl2zqSvGK6zr77payPN2cnoBcpK+f/mVcEezlA3vmU+yd9L/tqH99uaY6f1Je+dirnUatfJtXfd2wh/KrnU/bT/okX/6iy/nph4pYbXgd3bO997bt2vl9le6X1ZVJ/ymtQrk+4B31l+85tYh2Trld5jSY8e6XQrda10bsy4R5kwrfvmfH/SMrzL4+p3f/ad+H7/47ff/PWhbA1gWHbdEpNtt+OgSCx5wnrTuClMtgPoewETxTqZfu+X4b9AEAf7BhrtxRsWFo5f6z1zQQpyli/9dhOf+zj6/Pnj6U7Jh4XK9K6fX+s/fL87B0woav3LzM/ixYu5GRG2zfPuFKw8csJpAeoFLpFJ8p9/gUo6ynLlw+8L5cdKz0vhf8HIv0v88R2Xb195WTCP/1a+319lp6+SHle+kJ1rkFb/+Hk72WtD9K39PUU7dSuT9bmhPOuXS/pqatTdw/+/PuuvT/n6g+Hnn7Xnt3ac1GeX23OfrXPMuG5qD0TGzxTIt3n3//TmPQsSk/9nbLlNZHu8yqVOmrCWvrOs6dv4uquXrPK+Vf78TC8/9jmBRvWy/ffa2ZWXgVb5/1XwSNlf6DR+euM776eop3UP+uT+xEgJgjdIdl9Ng3alUvVm3C0pReu7hp1BKDN67V2rf/uh4M/hUxYW1v+eSiOk/L6Wt/KvrQbOWptRPnP23/KMsVLVO7zm8sH1Xe22nkRqf3zL/taXa+dky9T/NPrrbPsQ98Fbft/4VS3lQ9RRWhI5bts5mZWHtDaPxHfbq2OplaHdP9J9/7is2XtuSna2fAfXLGe+lTrQ9mG5P8MpXaeZb1l3yfc814/C5HeH5nVuirtN+X7UZbZqC53vH/mJvajeP+r51npmz/HWr8zYcP3/87f/wnPQtmP9DGh6oWjtd/X5zYXIKkOV494YVV5p7KPF1Lls1UKV5Gupl1sj6BPZR/8OfnzKn+clP+byv4XZfuO8/uy97u4X+Wzfkf/y8sL2yuMy2W5TSb/w6gKd8n/+VbLVtjUP6ZJZdvKP9S2X2hUhWStrUq9UvsHUz6klX5MOv/ecynvT5v/Q95IEJf3faP70Km77HvPc1IeLxtsbza6X5V96bh2A4Hcd73b/B9nts3ROdY/Oz3PfG9/NrG/8/L3lb3Tul0ffd0dAVHpB99/bet+v/9tjzDw739bEVjl8cUxsVwhNCe2b3U4c7BU+tHXvkzaXvZjs+dTaLud62XffZ/L9jd63ya1X97jjY4lhBBCyAPi3wPHjgWcD/IE1wAAAABJRU5ErkJggg=="/>
-</defs>
-</svg>
diff --git a/static/assets/images/apple_48.svg b/static/assets/images/apple_48.svg
deleted file mode 100644
index 49143ccbd66a..000000000000
--- a/static/assets/images/apple_48.svg
+++ /dev/null
@@ -1,17 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg width="48px" height="48px" viewBox="0 0 48 48" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-    <!-- Generator: Sketch 42 (36781) - http://www.bohemiancoding.com/sketch -->
-    <title>apple_48</title>
-    <desc>Created with Sketch.</desc>
-    <defs></defs>
-    <g id="Page-1" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
-        <g id="apple_48">
-            <rect id="Rectangle-33" x="0" y="0" width="48" height="48"></rect>
-            <g transform="translate(9.000000, 6.000000)" id="Shape" fill="#2089C4">
-                <g>
-                    <path d="M25.055,19.09 C25.107,24.527 29.946,26.336 30,26.36 C29.96,26.487 29.227,28.938 27.45,31.47 C25.915,33.659 24.32,35.84 21.81,35.885 C19.343,35.929 18.55,34.458 15.73,34.458 C12.91,34.458 12.028,35.84 9.693,35.929 C7.27,36.019 5.424,33.562 3.876,31.381 C0.712,26.921 -1.706,18.776 1.541,13.278 C3.154,10.548 6.036,8.818 9.164,8.774 C11.544,8.73 13.79,10.336 15.245,10.336 C16.699,10.336 19.429,8.405 22.298,8.688 C23.499,8.738 26.872,9.162 29.037,12.253 C28.862,12.358 25.013,14.543 25.055,19.089 M20.42,5.737 C21.705,4.218 22.57,2.104 22.335,0 C20.48,0.073 18.238,1.205 16.908,2.723 C15.715,4.068 14.671,6.219 14.953,8.281 C17.02,8.437 19.132,7.257 20.419,5.737"></path>
-                </g>
-            </g>
-        </g>
-    </g>
-</svg>
\ No newline at end of file
diff --git a/static/assets/images/banner_image_24512.png b/static/assets/images/banner_image_24512.png
deleted file mode 100644
index 9b580a20b56a..000000000000
Binary files a/static/assets/images/banner_image_24512.png and /dev/null differ
diff --git a/static/assets/images/bg-pattern-blue.webp b/static/assets/images/bg-pattern-blue.webp
deleted file mode 100644
index ece37ea0fd89..000000000000
Binary files a/static/assets/images/bg-pattern-blue.webp and /dev/null differ
diff --git a/static/assets/images/bg-pattern-purple.webp b/static/assets/images/bg-pattern-purple.webp
deleted file mode 100644
index fb612ac239b4..000000000000
Binary files a/static/assets/images/bg-pattern-purple.webp and /dev/null differ
diff --git a/static/assets/images/bg-pattern-verde.webp b/static/assets/images/bg-pattern-verde.webp
deleted file mode 100644
index 3cce3982e3ad..000000000000
Binary files a/static/assets/images/bg-pattern-verde.webp and /dev/null differ
diff --git a/static/assets/images/docker-docs.png b/static/assets/images/docker-docs.png
deleted file mode 100644
index 89bebf552cca..000000000000
Binary files a/static/assets/images/docker-docs.png and /dev/null differ
diff --git a/static/assets/images/docker-docs.svg b/static/assets/images/docker-docs.svg
new file mode 100644
index 000000000000..cf36d6c5e07b
--- /dev/null
+++ b/static/assets/images/docker-docs.svg
@@ -0,0 +1,14 @@
+<svg width="830" height="125" viewBox="0 0 830 125" fill="none" xmlns="http://www.w3.org/2000/svg">
+<g clip-path="url(#clip0_507_143)">
+<rect width="830" height="125" rx="6" fill="#0F52FF"/>
+<path opacity="0.05" d="M71.3839 68.4761C139.084 72.3822 171.283 96.3328 238.625 94.5118C281.208 93.3703 342.909 83.3135 376.211 72.5348C409.512 61.7561 448.786 51.3538 491.526 54.4531C525.43 56.9079 554.338 67.4755 587.442 71.8643C629.388 77.4408 672.955 72.665 715.134 69.7773C757.313 66.8896 805.643 66.6875 839.695 79.0668C874.016 91.5723 882.075 113.543 870.524 131.33C858.973 149.117 831.685 163.744 804.978 177.874C757.742 202.879 710.517 227.862 663.281 252.866C643.969 263.083 622.717 273.849 592.559 277.003C568.496 279.51 542.622 276.755 517.916 273.997C426.763 263.825 335.61 253.653 244.468 243.458C207.676 239.341 169.764 235.02 138.809 225.107C108.761 215.489 87.8038 201.451 59.9652 190.633C35.1957 181.003 5.55584 174.123 -21.3264 165.611C-48.2085 157.099 -73.4475 146.187 -82.2077 132.508C-93.0767 115.606 -65.1811 99.541 -42.1645 87.6868C-15.2324 73.7721 27.7561 65.9323 71.395 68.4538L71.3839 68.4761Z" fill="black"/>
+<path opacity="0.06" d="M227.983 115.718C294.961 109.774 360.595 90.6084 426.007 82.051C473.744 75.8013 532.851 78.7789 578.39 88.1503C623.929 97.5217 663.73 105.994 713.22 109.548C775.765 114.039 831.545 83.0618 879.91 101.125C917.75 115.256 940.006 163.126 929.195 184.106C905.889 229.348 822.533 264.757 727.597 285.227C632.66 305.698 526.033 313.447 421.148 320.978C333.322 327.285 238.072 333.081 158.803 314.726C81.8617 296.896 38.6564 260.607 0.164599 226.481C-23.6379 205.361 -48.1005 183.027 -44.7357 159.684C-41.4946 136.114 -41.3895 102.704 15.1954 101.125C79.8029 99.3428 162.105 121.54 227.983 115.718Z" fill="black"/>
+<path d="M38.48 47.04C41.5733 47.04 44.2267 47.6 46.44 48.72C48.6533 49.84 50.3467 51.4533 51.52 53.56C52.6933 55.6667 53.28 58.1733 53.28 61.08C53.28 63.96 52.6933 66.4533 51.52 68.56C50.3467 70.64 48.6533 72.24 46.44 73.36C44.2267 74.4533 41.5733 75 38.48 75H30.2V47.04H38.48ZM38.48 72.68C42.3733 72.68 45.3333 71.6667 47.36 69.64C49.4133 67.5867 50.44 64.7333 50.44 61.08C50.44 57.4 49.4133 54.5333 47.36 52.48C45.3333 50.4 42.3733 49.36 38.48 49.36H33V72.68H38.48ZM67.2022 75.32C65.1489 75.32 63.2955 74.8667 61.6422 73.96C60.0155 73.0267 58.7222 71.72 57.7622 70.04C56.8289 68.3333 56.3622 66.3467 56.3622 64.08C56.3622 61.8133 56.8422 59.84 57.8022 58.16C58.7622 56.4533 60.0689 55.1467 61.7222 54.24C63.3755 53.3067 65.2289 52.84 67.2822 52.84C69.3355 52.84 71.1889 53.3067 72.8422 54.24C74.5222 55.1467 75.8289 56.4533 76.7622 58.16C77.7222 59.84 78.2022 61.8133 78.2022 64.08C78.2022 66.32 77.7222 68.2933 76.7622 70C75.8022 71.7067 74.4822 73.0267 72.8022 73.96C71.1222 74.8667 69.2555 75.32 67.2022 75.32ZM67.2022 72.88C68.6422 72.88 69.9755 72.56 71.2022 71.92C72.4289 71.2533 73.4155 70.2667 74.1622 68.96C74.9355 67.6267 75.3222 66 75.3222 64.08C75.3222 62.16 74.9489 60.5467 74.2022 59.24C73.4555 57.9067 72.4689 56.92 71.2422 56.28C70.0155 55.6133 68.6822 55.28 67.2422 55.28C65.8022 55.28 64.4689 55.6133 63.2422 56.28C62.0155 56.92 61.0289 57.9067 60.2822 59.24C59.5622 60.5467 59.2022 62.16 59.2022 64.08C59.2022 66 59.5622 67.6267 60.2822 68.96C61.0289 70.2667 62.0022 71.2533 63.2022 71.92C64.4289 72.56 65.7622 72.88 67.2022 72.88ZM81.2263 64.08C81.2263 61.8133 81.6796 59.84 82.5863 58.16C83.4929 56.4533 84.7463 55.1467 86.3463 54.24C87.9463 53.3067 89.7729 52.84 91.8263 52.84C94.5196 52.84 96.7329 53.5067 98.4663 54.84C100.226 56.1733 101.36 57.9867 101.866 60.28H98.8663C98.4929 58.7067 97.6796 57.48 96.4263 56.6C95.1996 55.6933 93.6663 55.24 91.8263 55.24C90.3596 55.24 89.0396 55.5733 87.8663 56.24C86.6929 56.9067 85.7596 57.9067 85.0663 59.24C84.3996 60.5467 84.0663 62.16 84.0663 64.08C84.0663 66 84.3996 67.6267 85.0663 68.96C85.7596 70.2933 86.6929 71.2933 87.8663 71.96C89.0396 72.6267 90.3596 72.96 91.8263 72.96C93.6663 72.96 95.1996 72.52 96.4263 71.64C97.6796 70.7333 98.4929 69.48 98.8663 67.88H101.866C101.36 70.12 100.226 71.92 98.4663 73.28C96.7063 74.64 94.4929 75.32 91.8263 75.32C89.7729 75.32 87.9463 74.8667 86.3463 73.96C84.7463 73.0267 83.4929 71.72 82.5863 70.04C81.6796 68.3333 81.2263 66.3467 81.2263 64.08ZM118.037 75L109.037 65.2V75H106.237V45.4H109.037V62.92L117.837 53.16H121.757L111.397 64.04L121.837 75H118.037ZM144.416 62.96C144.416 63.92 144.39 64.6533 144.336 65.16H126.216C126.296 66.8133 126.696 68.2267 127.416 69.4C128.136 70.5733 129.083 71.4667 130.256 72.08C131.43 72.6667 132.71 72.96 134.096 72.96C135.91 72.96 137.43 72.52 138.656 71.64C139.91 70.76 140.736 69.5733 141.136 68.08H144.096C143.563 70.2133 142.416 71.96 140.656 73.32C138.923 74.6533 136.736 75.32 134.096 75.32C132.043 75.32 130.203 74.8667 128.576 73.96C126.95 73.0267 125.67 71.72 124.736 70.04C123.83 68.3333 123.376 66.3467 123.376 64.08C123.376 61.8133 123.83 59.8267 124.736 58.12C125.643 56.4133 126.91 55.1067 128.536 54.2C130.163 53.2933 132.016 52.84 134.096 52.84C136.176 52.84 137.99 53.2933 139.536 54.2C141.11 55.1067 142.31 56.3333 143.136 57.88C143.99 59.4 144.416 61.0933 144.416 62.96ZM141.576 62.88C141.603 61.2533 141.27 59.8667 140.576 58.72C139.91 57.5733 138.99 56.7067 137.816 56.12C136.643 55.5333 135.363 55.24 133.976 55.24C131.896 55.24 130.123 55.9067 128.656 57.24C127.19 58.5733 126.376 60.4533 126.216 62.88H141.576ZM151.539 57.04C152.152 55.68 153.086 54.6267 154.339 53.88C155.619 53.1333 157.179 52.76 159.019 52.76V55.68H158.259C156.232 55.68 154.606 56.2267 153.379 57.32C152.152 58.4133 151.539 60.24 151.539 62.8V75H148.739V53.16H151.539V57.04ZM171.328 64.04C171.328 61.8 171.781 59.84 172.688 58.16C173.594 56.4533 174.834 55.1467 176.408 54.24C178.008 53.3067 179.808 52.84 181.808 52.84C183.728 52.84 185.461 53.3067 187.008 54.24C188.554 55.1733 189.688 56.3867 190.408 57.88V45.4H193.208V75H190.408V70.12C189.741 71.64 188.648 72.8933 187.128 73.88C185.608 74.84 183.821 75.32 181.768 75.32C179.768 75.32 177.968 74.8533 176.368 73.92C174.794 72.9867 173.554 71.6667 172.648 69.96C171.768 68.2533 171.328 66.28 171.328 64.04ZM190.408 64.08C190.408 62.32 190.048 60.7733 189.328 59.44C188.608 58.1067 187.621 57.08 186.368 56.36C185.141 55.64 183.781 55.28 182.288 55.28C180.741 55.28 179.354 55.6267 178.128 56.32C176.901 57.0133 175.928 58.0267 175.208 59.36C174.514 60.6667 174.168 62.2267 174.168 64.04C174.168 65.8267 174.514 67.4 175.208 68.76C175.928 70.0933 176.901 71.12 178.128 71.84C179.354 72.5333 180.741 72.88 182.288 72.88C183.781 72.88 185.141 72.52 186.368 71.8C187.621 71.08 188.608 70.0533 189.328 68.72C190.048 67.3867 190.408 65.84 190.408 64.08ZM208.36 75.32C206.307 75.32 204.453 74.8667 202.8 73.96C201.173 73.0267 199.88 71.72 198.92 70.04C197.987 68.3333 197.52 66.3467 197.52 64.08C197.52 61.8133 198 59.84 198.96 58.16C199.92 56.4533 201.227 55.1467 202.88 54.24C204.533 53.3067 206.387 52.84 208.44 52.84C210.493 52.84 212.347 53.3067 214 54.24C215.68 55.1467 216.987 56.4533 217.92 58.16C218.88 59.84 219.36 61.8133 219.36 64.08C219.36 66.32 218.88 68.2933 217.92 70C216.96 71.7067 215.64 73.0267 213.96 73.96C212.28 74.8667 210.413 75.32 208.36 75.32ZM208.36 72.88C209.8 72.88 211.133 72.56 212.36 71.92C213.587 71.2533 214.573 70.2667 215.32 68.96C216.093 67.6267 216.48 66 216.48 64.08C216.48 62.16 216.107 60.5467 215.36 59.24C214.613 57.9067 213.627 56.92 212.4 56.28C211.173 55.6133 209.84 55.28 208.4 55.28C206.96 55.28 205.627 55.6133 204.4 56.28C203.173 56.92 202.187 57.9067 201.44 59.24C200.72 60.5467 200.36 62.16 200.36 64.08C200.36 66 200.72 67.6267 201.44 68.96C202.187 70.2667 203.16 71.2533 204.36 71.92C205.587 72.56 206.92 72.88 208.36 72.88ZM222.384 64.08C222.384 61.8133 222.837 59.84 223.744 58.16C224.651 56.4533 225.904 55.1467 227.504 54.24C229.104 53.3067 230.931 52.84 232.984 52.84C235.677 52.84 237.891 53.5067 239.624 54.84C241.384 56.1733 242.517 57.9867 243.024 60.28H240.024C239.651 58.7067 238.837 57.48 237.584 56.6C236.357 55.6933 234.824 55.24 232.984 55.24C231.517 55.24 230.197 55.5733 229.024 56.24C227.851 56.9067 226.917 57.9067 226.224 59.24C225.557 60.5467 225.224 62.16 225.224 64.08C225.224 66 225.557 67.6267 226.224 68.96C226.917 70.2933 227.851 71.2933 229.024 71.96C230.197 72.6267 231.517 72.96 232.984 72.96C234.824 72.96 236.357 72.52 237.584 71.64C238.837 70.7333 239.651 69.48 240.024 67.88H243.024C242.517 70.12 241.384 71.92 239.624 73.28C237.864 74.64 235.651 75.32 232.984 75.32C230.931 75.32 229.104 74.8667 227.504 73.96C225.904 73.0267 224.651 71.72 223.744 70.04C222.837 68.3333 222.384 66.3467 222.384 64.08ZM254.915 75.32C252.409 75.32 250.355 74.7467 248.755 73.6C247.182 72.4267 246.302 70.84 246.115 68.84H248.995C249.129 70.0667 249.702 71.0667 250.715 71.84C251.755 72.5867 253.142 72.96 254.875 72.96C256.395 72.96 257.582 72.6 258.435 71.88C259.315 71.16 259.755 70.2667 259.755 69.2C259.755 68.4533 259.515 67.84 259.035 67.36C258.555 66.88 257.942 66.5067 257.195 66.24C256.475 65.9467 255.489 65.64 254.235 65.32C252.609 64.8933 251.289 64.4667 250.275 64.04C249.262 63.6133 248.395 62.9867 247.675 62.16C246.982 61.3067 246.635 60.1733 246.635 58.76C246.635 57.6933 246.955 56.7067 247.595 55.8C248.235 54.8933 249.142 54.1733 250.315 53.64C251.489 53.1067 252.822 52.84 254.315 52.84C256.662 52.84 258.555 53.44 259.995 54.64C261.435 55.8133 262.209 57.44 262.315 59.52H259.515C259.435 58.24 258.929 57.2133 257.995 56.44C257.089 55.64 255.835 55.24 254.235 55.24C252.822 55.24 251.675 55.5733 250.795 56.24C249.915 56.9067 249.475 57.7333 249.475 58.72C249.475 59.5733 249.729 60.28 250.235 60.84C250.769 61.3733 251.422 61.8 252.195 62.12C252.969 62.4133 254.009 62.7467 255.315 63.12C256.889 63.5467 258.142 63.96 259.075 64.36C260.009 64.76 260.809 65.3467 261.475 66.12C262.142 66.8933 262.489 67.92 262.515 69.2C262.515 70.3733 262.195 71.4267 261.555 72.36C260.915 73.2667 260.022 73.9867 258.875 74.52C257.729 75.0533 256.409 75.32 254.915 75.32Z" fill="white"/>
+<path d="M796.073 58.4886C794.675 57.5476 791.003 57.1457 788.334 57.8655C788.191 55.206 786.819 52.9644 784.311 51.0086L783.383 50.3855L782.764 51.3206C781.548 53.1671 781.035 55.6282 781.216 57.8655C781.359 59.244 781.838 60.7929 782.764 61.9171C779.29 63.9332 776.087 63.4753 761.903 63.4753H740.005C739.941 66.6791 740.456 72.8409 744.373 77.8574C744.806 78.4118 745.28 78.9475 745.796 79.464C748.981 82.6541 753.793 84.994 760.989 85C771.968 85.0102 781.374 79.0739 787.096 64.7223C788.978 64.753 793.949 65.0599 796.381 60.3589C796.441 60.28 797 59.1126 797 59.1126L796.073 58.4886ZM754.296 55.5595H748.138V61.7187H754.296V55.5595ZM762.251 55.5595H756.093V61.7187H762.251V55.5595ZM770.206 55.5595H764.048V61.7187H770.206V55.5595ZM778.162 55.5595H772.004V61.7187H778.162V55.5595ZM746.341 55.5595H740.183V61.7187H746.341V55.5595ZM754.296 47.7802H748.138V53.9394H754.296V47.7802ZM762.251 47.7802H756.093V53.9394H762.251V47.7802ZM770.206 47.7802H764.048V53.9394H770.206V47.7802ZM770.206 40H764.048V46.1592H770.206V40Z" fill="white"/>
+</g>
+<defs>
+<clipPath id="clip0_507_143">
+<rect width="830" height="125" rx="6" fill="white"/>
+</clipPath>
+</defs>
+</svg>
diff --git a/static/assets/images/docs-site-feedback.png b/static/assets/images/docs-site-feedback.png
deleted file mode 100644
index 6fe4122f32d9..000000000000
Binary files a/static/assets/images/docs-site-feedback.png and /dev/null differ
diff --git a/static/assets/images/dot-pattern.svg b/static/assets/images/dot-pattern.svg
new file mode 100644
index 000000000000..9d112c355e9e
--- /dev/null
+++ b/static/assets/images/dot-pattern.svg
@@ -0,0 +1,2669 @@
+<svg width="1158" height="598" viewBox="0 0 1158 598" fill="none" xmlns="http://www.w3.org/2000/svg">
+<g opacity="0.11">
+<g clip-path="url(#clip0_1_6)">
+<path d="M159.602 9.50284V4.81534H160.397V9.50284H159.602ZM157.656 7.55682V6.76136H162.343V7.55682H157.656Z" fill="#01256C"/>
+<path d="M171.602 9.50284V4.81534H172.397V9.50284H171.602ZM169.656 7.55682V6.76136H174.343V7.55682H169.656Z" fill="#01256C"/>
+<path d="M183.602 9.50284V4.81534H184.397V9.50284H183.602ZM181.656 7.55682V6.76136H186.343V7.55682H181.656Z" fill="#01256C"/>
+<path d="M195.602 9.50284V4.81534H196.397V9.50284H195.602ZM193.656 7.55682V6.76136H198.343V7.55682H193.656Z" fill="#01256C"/>
+<path d="M207.602 9.50284V4.81534H208.397V9.50284H207.602ZM205.656 7.55682V6.76136H210.343V7.55682H205.656Z" fill="#01256C"/>
+<path d="M219.602 9.50284V4.81534H220.397V9.50284H219.602ZM217.656 7.55682V6.76136H222.343V7.55682H217.656Z" fill="#01256C"/>
+<path d="M231.602 9.50284V4.81534H232.397V9.50284H231.602ZM229.656 7.55682V6.76136H234.343V7.55682H229.656Z" fill="#01256C"/>
+<path d="M243.602 9.50284V4.81534H244.397V9.50284H243.602ZM241.656 7.55682V6.76136H246.343V7.55682H241.656Z" fill="#01256C"/>
+<path d="M255.602 9.50284V4.81534H256.397V9.50284H255.602ZM253.656 7.55682V6.76136H258.343V7.55682H253.656Z" fill="#01256C"/>
+<path d="M267.602 9.50284V4.81534H268.397V9.50284H267.602ZM265.656 7.55682V6.76136H270.343V7.55682H265.656Z" fill="#01256C"/>
+<path d="M279.602 9.50284V4.81534H280.397V9.50284H279.602ZM277.656 7.55682V6.76136H282.343V7.55682H277.656Z" fill="#01256C"/>
+<path d="M291.602 9.50284V4.81534H292.397V9.50284H291.602ZM289.656 7.55682V6.76136H294.343V7.55682H289.656Z" fill="#01256C"/>
+<path d="M303.602 9.50284V4.81534H304.397V9.50284H303.602ZM301.656 7.55682V6.76136H306.343V7.55682H301.656Z" fill="#01256C"/>
+<path d="M315.602 9.50284V4.81534H316.397V9.50284H315.602ZM313.656 7.55682V6.76136H318.343V7.55682H313.656Z" fill="#01256C"/>
+<path d="M327.602 9.50284V4.81534H328.397V9.50284H327.602ZM325.656 7.55682V6.76136H330.343V7.55682H325.656Z" fill="#01256C"/>
+<path d="M339.602 9.50284V4.81534H340.397V9.50284H339.602ZM337.656 7.55682V6.76136H342.343V7.55682H337.656Z" fill="#01256C"/>
+<path d="M351.602 9.50284V4.81534H352.397V9.50284H351.602ZM349.656 7.55682V6.76136H354.343V7.55682H349.656Z" fill="#01256C"/>
+<path d="M363.602 9.50284V4.81534H364.397V9.50284H363.602ZM361.656 7.55682V6.76136H366.343V7.55682H361.656Z" fill="#01256C"/>
+<path d="M375.602 9.50284V4.81534H376.397V9.50284H375.602ZM373.656 7.55682V6.76136H378.343V7.55682H373.656Z" fill="#01256C"/>
+<path d="M387.602 9.50284V4.81534H388.397V9.50284H387.602ZM385.656 7.55682V6.76136H390.343V7.55682H385.656Z" fill="#01256C"/>
+<path d="M399.602 9.50284V4.81534H400.397V9.50284H399.602ZM397.656 7.55682V6.76136H402.343V7.55682H397.656Z" fill="#01256C"/>
+<path d="M411.602 9.50284V4.81534H412.397V9.50284H411.602ZM409.656 7.55682V6.76136H414.343V7.55682H409.656Z" fill="#01256C"/>
+<path d="M423.602 9.50284V4.81534H424.397V9.50284H423.602ZM421.656 7.55682V6.76136H426.343V7.55682H421.656Z" fill="#01256C"/>
+<path d="M435.602 9.50284V4.81534H436.397V9.50284H435.602ZM433.656 7.55682V6.76136H438.343V7.55682H433.656Z" fill="#01256C"/>
+<path d="M447.602 9.50284V4.81534H448.397V9.50284H447.602ZM445.656 7.55682V6.76136H450.343V7.55682H445.656Z" fill="#01256C"/>
+<path d="M459.602 9.50284V4.81534H460.397V9.50284H459.602ZM457.656 7.55682V6.76136H462.343V7.55682H457.656Z" fill="#01256C"/>
+<path d="M471.602 9.50284V4.81534H472.397V9.50284H471.602ZM469.656 7.55682V6.76136H474.343V7.55682H469.656Z" fill="#01256C"/>
+<path d="M483.602 9.50284V4.81534H484.397V9.50284H483.602ZM481.656 7.55682V6.76136H486.343V7.55682H481.656Z" fill="#01256C"/>
+<path d="M495.602 9.50284V4.81534H496.397V9.50284H495.602ZM493.656 7.55682V6.76136H498.343V7.55682H493.656Z" fill="#01256C"/>
+<path d="M507.602 9.50284V4.81534H508.397V9.50284H507.602ZM505.656 7.55682V6.76136H510.343V7.55682H505.656Z" fill="#01256C"/>
+<path d="M519.602 9.50284V4.81534H520.397V9.50284H519.602ZM517.656 7.55682V6.76136H522.343V7.55682H517.656Z" fill="#01256C"/>
+<path d="M531.602 9.50284V4.81534H532.397V9.50284H531.602ZM529.656 7.55682V6.76136H534.343V7.55682H529.656Z" fill="#01256C"/>
+<path d="M543.602 9.50284V4.81534H544.397V9.50284H543.602ZM541.656 7.55682V6.76136H546.343V7.55682H541.656Z" fill="#01256C"/>
+<path d="M555.602 9.50284V4.81534H556.397V9.50284H555.602ZM553.656 7.55682V6.76136H558.343V7.55682H553.656Z" fill="#01256C"/>
+<path d="M567.602 9.50284V4.81534H568.397V9.50284H567.602ZM565.656 7.55682V6.76136H570.343V7.55682H565.656Z" fill="#01256C"/>
+<path d="M579.602 9.50284V4.81534H580.397V9.50284H579.602ZM577.656 7.55682V6.76136H582.343V7.55682H577.656Z" fill="#01256C"/>
+<path d="M591.602 9.50284V4.81534H592.397V9.50284H591.602ZM589.656 7.55682V6.76136H594.343V7.55682H589.656Z" fill="#01256C"/>
+<path d="M603.602 9.50284V4.81534H604.397V9.50284H603.602ZM601.656 7.55682V6.76136H606.343V7.55682H601.656Z" fill="#01256C"/>
+<path d="M615.602 9.50284V4.81534H616.397V9.50284H615.602ZM613.656 7.55682V6.76136H618.343V7.55682H613.656Z" fill="#01256C"/>
+<path d="M627.602 9.50284V4.81534H628.397V9.50284H627.602ZM625.656 7.55682V6.76136H630.343V7.55682H625.656Z" fill="#01256C"/>
+<path d="M639.602 9.50284V4.81534H640.397V9.50284H639.602ZM637.656 7.55682V6.76136H642.343V7.55682H637.656Z" fill="#01256C"/>
+<path d="M651.602 9.50284V4.81534H652.397V9.50284H651.602ZM649.656 7.55682V6.76136H654.343V7.55682H649.656Z" fill="#01256C"/>
+<path d="M663.602 9.50284V4.81534H664.397V9.50284H663.602ZM661.656 7.55682V6.76136H666.343V7.55682H661.656Z" fill="#01256C"/>
+<path d="M675.602 9.50284V4.81534H676.397V9.50284H675.602ZM673.656 7.55682V6.76136H678.343V7.55682H673.656Z" fill="#01256C"/>
+<path d="M687.602 9.50284V4.81534H688.397V9.50284H687.602ZM685.656 7.55682V6.76136H690.343V7.55682H685.656Z" fill="#01256C"/>
+<path d="M699.602 9.50284V4.81534H700.397V9.50284H699.602ZM697.656 7.55682V6.76136H702.343V7.55682H697.656Z" fill="#01256C"/>
+<path d="M711.602 9.50284V4.81534H712.397V9.50284H711.602ZM709.656 7.55682V6.76136H714.343V7.55682H709.656Z" fill="#01256C"/>
+<path d="M723.602 9.50284V4.81534H724.397V9.50284H723.602ZM721.656 7.55682V6.76136H726.343V7.55682H721.656Z" fill="#01256C"/>
+<path d="M735.602 9.50284V4.81534H736.397V9.50284H735.602ZM733.656 7.55682V6.76136H738.343V7.55682H733.656Z" fill="#01256C"/>
+<path d="M747.602 9.50284V4.81534H748.397V9.50284H747.602ZM745.656 7.55682V6.76136H750.343V7.55682H745.656Z" fill="#01256C"/>
+<path d="M759.602 9.50284V4.81534H760.397V9.50284H759.602ZM757.656 7.55682V6.76136H762.343V7.55682H757.656Z" fill="#01256C"/>
+<path d="M771.602 9.50284V4.81534H772.397V9.50284H771.602ZM769.656 7.55682V6.76136H774.343V7.55682H769.656Z" fill="#01256C"/>
+<path d="M783.602 9.50284V4.81534H784.397V9.50284H783.602ZM781.656 7.55682V6.76136H786.343V7.55682H781.656Z" fill="#01256C"/>
+<path d="M795.602 9.50284V4.81534H796.397V9.50284H795.602ZM793.656 7.55682V6.76136H798.343V7.55682H793.656Z" fill="#01256C"/>
+<path d="M807.602 9.50284V4.81534H808.397V9.50284H807.602ZM805.656 7.55682V6.76136H810.343V7.55682H805.656Z" fill="#01256C"/>
+<path d="M819.602 9.50284V4.81534H820.397V9.50284H819.602ZM817.656 7.55682V6.76136H822.343V7.55682H817.656Z" fill="#01256C"/>
+<path d="M831.602 9.50284V4.81534H832.397V9.50284H831.602ZM829.656 7.55682V6.76136H834.343V7.55682H829.656Z" fill="#01256C"/>
+<path d="M843.602 9.50284V4.81534H844.397V9.50284H843.602ZM841.656 7.55682V6.76136H846.343V7.55682H841.656Z" fill="#01256C"/>
+<path d="M855.602 9.50284V4.81534H856.397V9.50284H855.602ZM853.656 7.55682V6.76136H858.343V7.55682H853.656Z" fill="#01256C"/>
+<path d="M867.602 9.50284V4.81534H868.397V9.50284H867.602ZM865.656 7.55682V6.76136H870.343V7.55682H865.656Z" fill="#01256C"/>
+<path d="M879.602 9.50284V4.81534H880.397V9.50284H879.602ZM877.656 7.55682V6.76136H882.343V7.55682H877.656Z" fill="#01256C"/>
+<path d="M891.602 9.50284V4.81534H892.397V9.50284H891.602ZM889.656 7.55682V6.76136H894.343V7.55682H889.656Z" fill="#01256C"/>
+<path d="M1095.6 9.50284V4.81534H1096.4V9.50284H1095.6ZM1093.66 7.55682V6.76136H1098.34V7.55682H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 9.50284V4.81534H1108.4V9.50284H1107.6ZM1105.66 7.55682V6.76136H1110.34V7.55682H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 9.50284V4.81534H1120.4V9.50284H1119.6ZM1117.66 7.55682V6.76136H1122.34V7.55682H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 9.50284V4.81534H1132.4V9.50284H1131.6ZM1129.66 7.55682V6.76136H1134.34V7.55682H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 9.50284V4.81534H1144.4V9.50284H1143.6ZM1141.66 7.55682V6.76136H1146.34V7.55682H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 9.50284V4.81534H1156.4V9.50284H1155.6ZM1153.66 7.55682V6.76136H1158.34V7.55682H1153.66Z" fill="#01256C"/>
+<path d="M171.602 21.5028V16.8153H172.397V21.5028H171.602ZM169.656 19.5568V18.7614H174.343V19.5568H169.656Z" fill="#01256C"/>
+<path d="M183.602 21.5028V16.8153H184.397V21.5028H183.602ZM181.656 19.5568V18.7614H186.343V19.5568H181.656Z" fill="#01256C"/>
+<path d="M195.602 21.5028V16.8153H196.397V21.5028H195.602ZM193.656 19.5568V18.7614H198.343V19.5568H193.656Z" fill="#01256C"/>
+<path d="M207.602 21.5028V16.8153H208.397V21.5028H207.602ZM205.656 19.5568V18.7614H210.343V19.5568H205.656Z" fill="#01256C"/>
+<path d="M219.602 21.5028V16.8153H220.397V21.5028H219.602ZM217.656 19.5568V18.7614H222.343V19.5568H217.656Z" fill="#01256C"/>
+<path d="M231.602 21.5028V16.8153H232.397V21.5028H231.602ZM229.656 19.5568V18.7614H234.343V19.5568H229.656Z" fill="#01256C"/>
+<path d="M243.602 21.5028V16.8153H244.397V21.5028H243.602ZM241.656 19.5568V18.7614H246.343V19.5568H241.656Z" fill="#01256C"/>
+<path d="M255.602 21.5028V16.8153H256.397V21.5028H255.602ZM253.656 19.5568V18.7614H258.343V19.5568H253.656Z" fill="#01256C"/>
+<path d="M267.602 21.5028V16.8153H268.397V21.5028H267.602ZM265.656 19.5568V18.7614H270.343V19.5568H265.656Z" fill="#01256C"/>
+<path d="M279.602 21.5028V16.8153H280.397V21.5028H279.602ZM277.656 19.5568V18.7614H282.343V19.5568H277.656Z" fill="#01256C"/>
+<path d="M291.602 21.5028V16.8153H292.397V21.5028H291.602ZM289.656 19.5568V18.7614H294.343V19.5568H289.656Z" fill="#01256C"/>
+<path d="M303.602 21.5028V16.8153H304.397V21.5028H303.602ZM301.656 19.5568V18.7614H306.343V19.5568H301.656Z" fill="#01256C"/>
+<path d="M315.602 21.5028V16.8153H316.397V21.5028H315.602ZM313.656 19.5568V18.7614H318.343V19.5568H313.656Z" fill="#01256C"/>
+<path d="M327.602 21.5028V16.8153H328.397V21.5028H327.602ZM325.656 19.5568V18.7614H330.343V19.5568H325.656Z" fill="#01256C"/>
+<path d="M339.602 21.5028V16.8153H340.397V21.5028H339.602ZM337.656 19.5568V18.7614H342.343V19.5568H337.656Z" fill="#01256C"/>
+<path d="M351.602 21.5028V16.8153H352.397V21.5028H351.602ZM349.656 19.5568V18.7614H354.343V19.5568H349.656Z" fill="#01256C"/>
+<path d="M363.602 21.5028V16.8153H364.397V21.5028H363.602ZM361.656 19.5568V18.7614H366.343V19.5568H361.656Z" fill="#01256C"/>
+<path d="M375.602 21.5028V16.8153H376.397V21.5028H375.602ZM373.656 19.5568V18.7614H378.343V19.5568H373.656Z" fill="#01256C"/>
+<path d="M387.602 21.5028V16.8153H388.397V21.5028H387.602ZM385.656 19.5568V18.7614H390.343V19.5568H385.656Z" fill="#01256C"/>
+<path d="M399.602 21.5028V16.8153H400.397V21.5028H399.602ZM397.656 19.5568V18.7614H402.343V19.5568H397.656Z" fill="#01256C"/>
+<path d="M411.602 21.5028V16.8153H412.397V21.5028H411.602ZM409.656 19.5568V18.7614H414.343V19.5568H409.656Z" fill="#01256C"/>
+<path d="M423.602 21.5028V16.8153H424.397V21.5028H423.602ZM421.656 19.5568V18.7614H426.343V19.5568H421.656Z" fill="#01256C"/>
+<path d="M435.602 21.5028V16.8153H436.397V21.5028H435.602ZM433.656 19.5568V18.7614H438.343V19.5568H433.656Z" fill="#01256C"/>
+<path d="M447.602 21.5028V16.8153H448.397V21.5028H447.602ZM445.656 19.5568V18.7614H450.343V19.5568H445.656Z" fill="#01256C"/>
+<path d="M459.602 21.5028V16.8153H460.397V21.5028H459.602ZM457.656 19.5568V18.7614H462.343V19.5568H457.656Z" fill="#01256C"/>
+<path d="M471.602 21.5028V16.8153H472.397V21.5028H471.602ZM469.656 19.5568V18.7614H474.343V19.5568H469.656Z" fill="#01256C"/>
+<path d="M483.602 21.5028V16.8153H484.397V21.5028H483.602ZM481.656 19.5568V18.7614H486.343V19.5568H481.656Z" fill="#01256C"/>
+<path d="M495.602 21.5028V16.8153H496.397V21.5028H495.602ZM493.656 19.5568V18.7614H498.343V19.5568H493.656Z" fill="#01256C"/>
+<path d="M507.602 21.5028V16.8153H508.397V21.5028H507.602ZM505.656 19.5568V18.7614H510.343V19.5568H505.656Z" fill="#01256C"/>
+<path d="M519.602 21.5028V16.8153H520.397V21.5028H519.602ZM517.656 19.5568V18.7614H522.343V19.5568H517.656Z" fill="#01256C"/>
+<path d="M531.602 21.5028V16.8153H532.397V21.5028H531.602ZM529.656 19.5568V18.7614H534.343V19.5568H529.656Z" fill="#01256C"/>
+<path d="M543.602 21.5028V16.8153H544.397V21.5028H543.602ZM541.656 19.5568V18.7614H546.343V19.5568H541.656Z" fill="#01256C"/>
+<path d="M555.602 21.5028V16.8153H556.397V21.5028H555.602ZM553.656 19.5568V18.7614H558.343V19.5568H553.656Z" fill="#01256C"/>
+<path d="M567.602 21.5028V16.8153H568.397V21.5028H567.602ZM565.656 19.5568V18.7614H570.343V19.5568H565.656Z" fill="#01256C"/>
+<path d="M579.602 21.5028V16.8153H580.397V21.5028H579.602ZM577.656 19.5568V18.7614H582.343V19.5568H577.656Z" fill="#01256C"/>
+<path d="M591.602 21.5028V16.8153H592.397V21.5028H591.602ZM589.656 19.5568V18.7614H594.343V19.5568H589.656Z" fill="#01256C"/>
+<path d="M603.602 21.5028V16.8153H604.397V21.5028H603.602ZM601.656 19.5568V18.7614H606.343V19.5568H601.656Z" fill="#01256C"/>
+<path d="M615.602 21.5028V16.8153H616.397V21.5028H615.602ZM613.656 19.5568V18.7614H618.343V19.5568H613.656Z" fill="#01256C"/>
+<path d="M627.602 21.5028V16.8153H628.397V21.5028H627.602ZM625.656 19.5568V18.7614H630.343V19.5568H625.656Z" fill="#01256C"/>
+<path d="M639.602 21.5028V16.8153H640.397V21.5028H639.602ZM637.656 19.5568V18.7614H642.343V19.5568H637.656Z" fill="#01256C"/>
+<path d="M651.602 21.5028V16.8153H652.397V21.5028H651.602ZM649.656 19.5568V18.7614H654.343V19.5568H649.656Z" fill="#01256C"/>
+<path d="M663.602 21.5028V16.8153H664.397V21.5028H663.602ZM661.656 19.5568V18.7614H666.343V19.5568H661.656Z" fill="#01256C"/>
+<path d="M675.602 21.5028V16.8153H676.397V21.5028H675.602ZM673.656 19.5568V18.7614H678.343V19.5568H673.656Z" fill="#01256C"/>
+<path d="M687.602 21.5028V16.8153H688.397V21.5028H687.602ZM685.656 19.5568V18.7614H690.343V19.5568H685.656Z" fill="#01256C"/>
+<path d="M699.602 21.5028V16.8153H700.397V21.5028H699.602ZM697.656 19.5568V18.7614H702.343V19.5568H697.656Z" fill="#01256C"/>
+<path d="M711.602 21.5028V16.8153H712.397V21.5028H711.602ZM709.656 19.5568V18.7614H714.343V19.5568H709.656Z" fill="#01256C"/>
+<path d="M723.602 21.5028V16.8153H724.397V21.5028H723.602ZM721.656 19.5568V18.7614H726.343V19.5568H721.656Z" fill="#01256C"/>
+<path d="M735.602 21.5028V16.8153H736.397V21.5028H735.602ZM733.656 19.5568V18.7614H738.343V19.5568H733.656Z" fill="#01256C"/>
+<path d="M747.602 21.5028V16.8153H748.397V21.5028H747.602ZM745.656 19.5568V18.7614H750.343V19.5568H745.656Z" fill="#01256C"/>
+<path d="M759.602 21.5028V16.8153H760.397V21.5028H759.602ZM757.656 19.5568V18.7614H762.343V19.5568H757.656Z" fill="#01256C"/>
+<path d="M771.602 21.5028V16.8153H772.397V21.5028H771.602ZM769.656 19.5568V18.7614H774.343V19.5568H769.656Z" fill="#01256C"/>
+<path d="M783.602 21.5028V16.8153H784.397V21.5028H783.602ZM781.656 19.5568V18.7614H786.343V19.5568H781.656Z" fill="#01256C"/>
+<path d="M795.602 21.5028V16.8153H796.397V21.5028H795.602ZM793.656 19.5568V18.7614H798.343V19.5568H793.656Z" fill="#01256C"/>
+<path d="M807.602 21.5028V16.8153H808.397V21.5028H807.602ZM805.656 19.5568V18.7614H810.343V19.5568H805.656Z" fill="#01256C"/>
+<path d="M819.602 21.5028V16.8153H820.397V21.5028H819.602ZM817.656 19.5568V18.7614H822.343V19.5568H817.656Z" fill="#01256C"/>
+<path d="M831.602 21.5028V16.8153H832.397V21.5028H831.602ZM829.656 19.5568V18.7614H834.343V19.5568H829.656Z" fill="#01256C"/>
+<path d="M843.602 21.5028V16.8153H844.397V21.5028H843.602ZM841.656 19.5568V18.7614H846.343V19.5568H841.656Z" fill="#01256C"/>
+<path d="M855.602 21.5028V16.8153H856.397V21.5028H855.602ZM853.656 19.5568V18.7614H858.343V19.5568H853.656Z" fill="#01256C"/>
+<path d="M867.602 21.5028V16.8153H868.397V21.5028H867.602ZM865.656 19.5568V18.7614H870.343V19.5568H865.656Z" fill="#01256C"/>
+<path d="M879.602 21.5028V16.8153H880.397V21.5028H879.602ZM877.656 19.5568V18.7614H882.343V19.5568H877.656Z" fill="#01256C"/>
+<path d="M891.602 21.5028V16.8153H892.397V21.5028H891.602ZM889.656 19.5568V18.7614H894.343V19.5568H889.656Z" fill="#01256C"/>
+<path d="M1083.6 21.5028V16.8153H1084.4V21.5028H1083.6ZM1081.66 19.5568V18.7614H1086.34V19.5568H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 21.5028V16.8153H1096.4V21.5028H1095.6ZM1093.66 19.5568V18.7614H1098.34V19.5568H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 21.5028V16.8153H1108.4V21.5028H1107.6ZM1105.66 19.5568V18.7614H1110.34V19.5568H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 21.5028V16.8153H1120.4V21.5028H1119.6ZM1117.66 19.5568V18.7614H1122.34V19.5568H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 21.5028V16.8153H1132.4V21.5028H1131.6ZM1129.66 19.5568V18.7614H1134.34V19.5568H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 21.5028V16.8153H1144.4V21.5028H1143.6ZM1141.66 19.5568V18.7614H1146.34V19.5568H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 21.5028V16.8153H1156.4V21.5028H1155.6ZM1153.66 19.5568V18.7614H1158.34V19.5568H1153.66Z" fill="#01256C"/>
+<path d="M183.602 33.5028V28.8153H184.397V33.5028H183.602ZM181.656 31.5568V30.7614H186.343V31.5568H181.656Z" fill="#01256C"/>
+<path d="M195.602 33.5028V28.8153H196.397V33.5028H195.602ZM193.656 31.5568V30.7614H198.343V31.5568H193.656Z" fill="#01256C"/>
+<path d="M207.602 33.5028V28.8153H208.397V33.5028H207.602ZM205.656 31.5568V30.7614H210.343V31.5568H205.656Z" fill="#01256C"/>
+<path d="M219.602 33.5028V28.8153H220.397V33.5028H219.602ZM217.656 31.5568V30.7614H222.343V31.5568H217.656Z" fill="#01256C"/>
+<path d="M231.602 33.5028V28.8153H232.397V33.5028H231.602ZM229.656 31.5568V30.7614H234.343V31.5568H229.656Z" fill="#01256C"/>
+<path d="M243.602 33.5028V28.8153H244.397V33.5028H243.602ZM241.656 31.5568V30.7614H246.343V31.5568H241.656Z" fill="#01256C"/>
+<path d="M255.602 33.5028V28.8153H256.397V33.5028H255.602ZM253.656 31.5568V30.7614H258.343V31.5568H253.656Z" fill="#01256C"/>
+<path d="M267.602 33.5028V28.8153H268.397V33.5028H267.602ZM265.656 31.5568V30.7614H270.343V31.5568H265.656Z" fill="#01256C"/>
+<path d="M279.602 33.5028V28.8153H280.397V33.5028H279.602ZM277.656 31.5568V30.7614H282.343V31.5568H277.656Z" fill="#01256C"/>
+<path d="M291.602 33.5028V28.8153H292.397V33.5028H291.602ZM289.656 31.5568V30.7614H294.343V31.5568H289.656Z" fill="#01256C"/>
+<path d="M303.602 33.5028V28.8153H304.397V33.5028H303.602ZM301.656 31.5568V30.7614H306.343V31.5568H301.656Z" fill="#01256C"/>
+<path d="M315.602 33.5028V28.8153H316.397V33.5028H315.602ZM313.656 31.5568V30.7614H318.343V31.5568H313.656Z" fill="#01256C"/>
+<path d="M327.602 33.5028V28.8153H328.397V33.5028H327.602ZM325.656 31.5568V30.7614H330.343V31.5568H325.656Z" fill="#01256C"/>
+<path d="M339.602 33.5028V28.8153H340.397V33.5028H339.602ZM337.656 31.5568V30.7614H342.343V31.5568H337.656Z" fill="#01256C"/>
+<path d="M351.602 33.5028V28.8153H352.397V33.5028H351.602ZM349.656 31.5568V30.7614H354.343V31.5568H349.656Z" fill="#01256C"/>
+<path d="M363.602 33.5028V28.8153H364.397V33.5028H363.602ZM361.656 31.5568V30.7614H366.343V31.5568H361.656Z" fill="#01256C"/>
+<path d="M375.602 33.5028V28.8153H376.397V33.5028H375.602ZM373.656 31.5568V30.7614H378.343V31.5568H373.656Z" fill="#01256C"/>
+<path d="M387.602 33.5028V28.8153H388.397V33.5028H387.602ZM385.656 31.5568V30.7614H390.343V31.5568H385.656Z" fill="#01256C"/>
+<path d="M399.602 33.5028V28.8153H400.397V33.5028H399.602ZM397.656 31.5568V30.7614H402.343V31.5568H397.656Z" fill="#01256C"/>
+<path d="M411.602 33.5028V28.8153H412.397V33.5028H411.602ZM409.656 31.5568V30.7614H414.343V31.5568H409.656Z" fill="#01256C"/>
+<path d="M423.602 33.5028V28.8153H424.397V33.5028H423.602ZM421.656 31.5568V30.7614H426.343V31.5568H421.656Z" fill="#01256C"/>
+<path d="M435.602 33.5028V28.8153H436.397V33.5028H435.602ZM433.656 31.5568V30.7614H438.343V31.5568H433.656Z" fill="#01256C"/>
+<path d="M447.602 33.5028V28.8153H448.397V33.5028H447.602ZM445.656 31.5568V30.7614H450.343V31.5568H445.656Z" fill="#01256C"/>
+<path d="M459.602 33.5028V28.8153H460.397V33.5028H459.602ZM457.656 31.5568V30.7614H462.343V31.5568H457.656Z" fill="#01256C"/>
+<path d="M471.602 33.5028V28.8153H472.397V33.5028H471.602ZM469.656 31.5568V30.7614H474.343V31.5568H469.656Z" fill="#01256C"/>
+<path d="M483.602 33.5028V28.8153H484.397V33.5028H483.602ZM481.656 31.5568V30.7614H486.343V31.5568H481.656Z" fill="#01256C"/>
+<path d="M495.602 33.5028V28.8153H496.397V33.5028H495.602ZM493.656 31.5568V30.7614H498.343V31.5568H493.656Z" fill="#01256C"/>
+<path d="M507.602 33.5028V28.8153H508.397V33.5028H507.602ZM505.656 31.5568V30.7614H510.343V31.5568H505.656Z" fill="#01256C"/>
+<path d="M519.602 33.5028V28.8153H520.397V33.5028H519.602ZM517.656 31.5568V30.7614H522.343V31.5568H517.656Z" fill="#01256C"/>
+<path d="M531.602 33.5028V28.8153H532.397V33.5028H531.602ZM529.656 31.5568V30.7614H534.343V31.5568H529.656Z" fill="#01256C"/>
+<path d="M543.602 33.5028V28.8153H544.397V33.5028H543.602ZM541.656 31.5568V30.7614H546.343V31.5568H541.656Z" fill="#01256C"/>
+<path d="M555.602 33.5028V28.8153H556.397V33.5028H555.602ZM553.656 31.5568V30.7614H558.343V31.5568H553.656Z" fill="#01256C"/>
+<path d="M567.602 33.5028V28.8153H568.397V33.5028H567.602ZM565.656 31.5568V30.7614H570.343V31.5568H565.656Z" fill="#01256C"/>
+<path d="M579.602 33.5028V28.8153H580.397V33.5028H579.602ZM577.656 31.5568V30.7614H582.343V31.5568H577.656Z" fill="#01256C"/>
+<path d="M591.602 33.5028V28.8153H592.397V33.5028H591.602ZM589.656 31.5568V30.7614H594.343V31.5568H589.656Z" fill="#01256C"/>
+<path d="M603.602 33.5028V28.8153H604.397V33.5028H603.602ZM601.656 31.5568V30.7614H606.343V31.5568H601.656Z" fill="#01256C"/>
+<path d="M615.602 33.5028V28.8153H616.397V33.5028H615.602ZM613.656 31.5568V30.7614H618.343V31.5568H613.656Z" fill="#01256C"/>
+<path d="M627.602 33.5028V28.8153H628.397V33.5028H627.602ZM625.656 31.5568V30.7614H630.343V31.5568H625.656Z" fill="#01256C"/>
+<path d="M639.602 33.5028V28.8153H640.397V33.5028H639.602ZM637.656 31.5568V30.7614H642.343V31.5568H637.656Z" fill="#01256C"/>
+<path d="M651.602 33.5028V28.8153H652.397V33.5028H651.602ZM649.656 31.5568V30.7614H654.343V31.5568H649.656Z" fill="#01256C"/>
+<path d="M663.602 33.5028V28.8153H664.397V33.5028H663.602ZM661.656 31.5568V30.7614H666.343V31.5568H661.656Z" fill="#01256C"/>
+<path d="M675.602 33.5028V28.8153H676.397V33.5028H675.602ZM673.656 31.5568V30.7614H678.343V31.5568H673.656Z" fill="#01256C"/>
+<path d="M687.602 33.5028V28.8153H688.397V33.5028H687.602ZM685.656 31.5568V30.7614H690.343V31.5568H685.656Z" fill="#01256C"/>
+<path d="M699.602 33.5028V28.8153H700.397V33.5028H699.602ZM697.656 31.5568V30.7614H702.343V31.5568H697.656Z" fill="#01256C"/>
+<path d="M711.602 33.5028V28.8153H712.397V33.5028H711.602ZM709.656 31.5568V30.7614H714.343V31.5568H709.656Z" fill="#01256C"/>
+<path d="M723.602 33.5028V28.8153H724.397V33.5028H723.602ZM721.656 31.5568V30.7614H726.343V31.5568H721.656Z" fill="#01256C"/>
+<path d="M735.602 33.5028V28.8153H736.397V33.5028H735.602ZM733.656 31.5568V30.7614H738.343V31.5568H733.656Z" fill="#01256C"/>
+<path d="M747.602 33.5028V28.8153H748.397V33.5028H747.602ZM745.656 31.5568V30.7614H750.343V31.5568H745.656Z" fill="#01256C"/>
+<path d="M759.602 33.5028V28.8153H760.397V33.5028H759.602ZM757.656 31.5568V30.7614H762.343V31.5568H757.656Z" fill="#01256C"/>
+<path d="M771.602 33.5028V28.8153H772.397V33.5028H771.602ZM769.656 31.5568V30.7614H774.343V31.5568H769.656Z" fill="#01256C"/>
+<path d="M783.602 33.5028V28.8153H784.397V33.5028H783.602ZM781.656 31.5568V30.7614H786.343V31.5568H781.656Z" fill="#01256C"/>
+<path d="M795.602 33.5028V28.8153H796.397V33.5028H795.602ZM793.656 31.5568V30.7614H798.343V31.5568H793.656Z" fill="#01256C"/>
+<path d="M807.602 33.5028V28.8153H808.397V33.5028H807.602ZM805.656 31.5568V30.7614H810.343V31.5568H805.656Z" fill="#01256C"/>
+<path d="M819.602 33.5028V28.8153H820.397V33.5028H819.602ZM817.656 31.5568V30.7614H822.343V31.5568H817.656Z" fill="#01256C"/>
+<path d="M831.602 33.5028V28.8153H832.397V33.5028H831.602ZM829.656 31.5568V30.7614H834.343V31.5568H829.656Z" fill="#01256C"/>
+<path d="M843.602 33.5028V28.8153H844.397V33.5028H843.602ZM841.656 31.5568V30.7614H846.343V31.5568H841.656Z" fill="#01256C"/>
+<path d="M855.602 33.5028V28.8153H856.397V33.5028H855.602ZM853.656 31.5568V30.7614H858.343V31.5568H853.656Z" fill="#01256C"/>
+<path d="M867.602 33.5028V28.8153H868.397V33.5028H867.602ZM865.656 31.5568V30.7614H870.343V31.5568H865.656Z" fill="#01256C"/>
+<path d="M879.602 33.5028V28.8153H880.397V33.5028H879.602ZM877.656 31.5568V30.7614H882.343V31.5568H877.656Z" fill="#01256C"/>
+<path d="M891.602 33.5028V28.8153H892.397V33.5028H891.602ZM889.656 31.5568V30.7614H894.343V31.5568H889.656Z" fill="#01256C"/>
+<path d="M1071.6 33.5028V28.8153H1072.4V33.5028H1071.6ZM1069.66 31.5568V30.7614H1074.34V31.5568H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 33.5028V28.8153H1084.4V33.5028H1083.6ZM1081.66 31.5568V30.7614H1086.34V31.5568H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 33.5028V28.8153H1096.4V33.5028H1095.6ZM1093.66 31.5568V30.7614H1098.34V31.5568H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 33.5028V28.8153H1108.4V33.5028H1107.6ZM1105.66 31.5568V30.7614H1110.34V31.5568H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 33.5028V28.8153H1120.4V33.5028H1119.6ZM1117.66 31.5568V30.7614H1122.34V31.5568H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 33.5028V28.8153H1132.4V33.5028H1131.6ZM1129.66 31.5568V30.7614H1134.34V31.5568H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 33.5028V28.8153H1144.4V33.5028H1143.6ZM1141.66 31.5568V30.7614H1146.34V31.5568H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 33.5028V28.8153H1156.4V33.5028H1155.6ZM1153.66 31.5568V30.7614H1158.34V31.5568H1153.66Z" fill="#01256C"/>
+<path d="M195.602 45.5028V40.8153H196.397V45.5028H195.602ZM193.656 43.5568V42.7614H198.343V43.5568H193.656Z" fill="#01256C"/>
+<path d="M207.602 45.5028V40.8153H208.397V45.5028H207.602ZM205.656 43.5568V42.7614H210.343V43.5568H205.656Z" fill="#01256C"/>
+<path d="M219.602 45.5028V40.8153H220.397V45.5028H219.602ZM217.656 43.5568V42.7614H222.343V43.5568H217.656Z" fill="#01256C"/>
+<path d="M231.602 45.5028V40.8153H232.397V45.5028H231.602ZM229.656 43.5568V42.7614H234.343V43.5568H229.656Z" fill="#01256C"/>
+<path d="M243.602 45.5028V40.8153H244.397V45.5028H243.602ZM241.656 43.5568V42.7614H246.343V43.5568H241.656Z" fill="#01256C"/>
+<path d="M255.602 45.5028V40.8153H256.397V45.5028H255.602ZM253.656 43.5568V42.7614H258.343V43.5568H253.656Z" fill="#01256C"/>
+<path d="M267.602 45.5028V40.8153H268.397V45.5028H267.602ZM265.656 43.5568V42.7614H270.343V43.5568H265.656Z" fill="#01256C"/>
+<path d="M279.602 45.5028V40.8153H280.397V45.5028H279.602ZM277.656 43.5568V42.7614H282.343V43.5568H277.656Z" fill="#01256C"/>
+<path d="M291.602 45.5028V40.8153H292.397V45.5028H291.602ZM289.656 43.5568V42.7614H294.343V43.5568H289.656Z" fill="#01256C"/>
+<path d="M303.602 45.5028V40.8153H304.397V45.5028H303.602ZM301.656 43.5568V42.7614H306.343V43.5568H301.656Z" fill="#01256C"/>
+<path d="M315.602 45.5028V40.8153H316.397V45.5028H315.602ZM313.656 43.5568V42.7614H318.343V43.5568H313.656Z" fill="#01256C"/>
+<path d="M327.602 45.5028V40.8153H328.397V45.5028H327.602ZM325.656 43.5568V42.7614H330.343V43.5568H325.656Z" fill="#01256C"/>
+<path d="M339.602 45.5028V40.8153H340.397V45.5028H339.602ZM337.656 43.5568V42.7614H342.343V43.5568H337.656Z" fill="#01256C"/>
+<path d="M351.602 45.5028V40.8153H352.397V45.5028H351.602ZM349.656 43.5568V42.7614H354.343V43.5568H349.656Z" fill="#01256C"/>
+<path d="M363.602 45.5028V40.8153H364.397V45.5028H363.602ZM361.656 43.5568V42.7614H366.343V43.5568H361.656Z" fill="#01256C"/>
+<path d="M375.602 45.5028V40.8153H376.397V45.5028H375.602ZM373.656 43.5568V42.7614H378.343V43.5568H373.656Z" fill="#01256C"/>
+<path d="M387.602 45.5028V40.8153H388.397V45.5028H387.602ZM385.656 43.5568V42.7614H390.343V43.5568H385.656Z" fill="#01256C"/>
+<path d="M399.602 45.5028V40.8153H400.397V45.5028H399.602ZM397.656 43.5568V42.7614H402.343V43.5568H397.656Z" fill="#01256C"/>
+<path d="M411.602 45.5028V40.8153H412.397V45.5028H411.602ZM409.656 43.5568V42.7614H414.343V43.5568H409.656Z" fill="#01256C"/>
+<path d="M423.602 45.5028V40.8153H424.397V45.5028H423.602ZM421.656 43.5568V42.7614H426.343V43.5568H421.656Z" fill="#01256C"/>
+<path d="M435.602 45.5028V40.8153H436.397V45.5028H435.602ZM433.656 43.5568V42.7614H438.343V43.5568H433.656Z" fill="#01256C"/>
+<path d="M447.602 45.5028V40.8153H448.397V45.5028H447.602ZM445.656 43.5568V42.7614H450.343V43.5568H445.656Z" fill="#01256C"/>
+<path d="M459.602 45.5028V40.8153H460.397V45.5028H459.602ZM457.656 43.5568V42.7614H462.343V43.5568H457.656Z" fill="#01256C"/>
+<path d="M471.602 45.5028V40.8153H472.397V45.5028H471.602ZM469.656 43.5568V42.7614H474.343V43.5568H469.656Z" fill="#01256C"/>
+<path d="M483.602 45.5028V40.8153H484.397V45.5028H483.602ZM481.656 43.5568V42.7614H486.343V43.5568H481.656Z" fill="#01256C"/>
+<path d="M495.602 45.5028V40.8153H496.397V45.5028H495.602ZM493.656 43.5568V42.7614H498.343V43.5568H493.656Z" fill="#01256C"/>
+<path d="M507.602 45.5028V40.8153H508.397V45.5028H507.602ZM505.656 43.5568V42.7614H510.343V43.5568H505.656Z" fill="#01256C"/>
+<path d="M663.602 45.5028V40.8153H664.397V45.5028H663.602ZM661.656 43.5568V42.7614H666.343V43.5568H661.656Z" fill="#01256C"/>
+<path d="M675.602 45.5028V40.8153H676.397V45.5028H675.602ZM673.656 43.5568V42.7614H678.343V43.5568H673.656Z" fill="#01256C"/>
+<path d="M687.602 45.5028V40.8153H688.397V45.5028H687.602ZM685.656 43.5568V42.7614H690.343V43.5568H685.656Z" fill="#01256C"/>
+<path d="M699.602 45.5028V40.8153H700.397V45.5028H699.602ZM697.656 43.5568V42.7614H702.343V43.5568H697.656Z" fill="#01256C"/>
+<path d="M711.602 45.5028V40.8153H712.397V45.5028H711.602ZM709.656 43.5568V42.7614H714.343V43.5568H709.656Z" fill="#01256C"/>
+<path d="M723.602 45.5028V40.8153H724.397V45.5028H723.602ZM721.656 43.5568V42.7614H726.343V43.5568H721.656Z" fill="#01256C"/>
+<path d="M735.602 45.5028V40.8153H736.397V45.5028H735.602ZM733.656 43.5568V42.7614H738.343V43.5568H733.656Z" fill="#01256C"/>
+<path d="M747.602 45.5028V40.8153H748.397V45.5028H747.602ZM745.656 43.5568V42.7614H750.343V43.5568H745.656Z" fill="#01256C"/>
+<path d="M759.602 45.5028V40.8153H760.397V45.5028H759.602ZM757.656 43.5568V42.7614H762.343V43.5568H757.656Z" fill="#01256C"/>
+<path d="M771.602 45.5028V40.8153H772.397V45.5028H771.602ZM769.656 43.5568V42.7614H774.343V43.5568H769.656Z" fill="#01256C"/>
+<path d="M783.602 45.5028V40.8153H784.397V45.5028H783.602ZM781.656 43.5568V42.7614H786.343V43.5568H781.656Z" fill="#01256C"/>
+<path d="M795.602 45.5028V40.8153H796.397V45.5028H795.602ZM793.656 43.5568V42.7614H798.343V43.5568H793.656Z" fill="#01256C"/>
+<path d="M807.602 45.5028V40.8153H808.397V45.5028H807.602ZM805.656 43.5568V42.7614H810.343V43.5568H805.656Z" fill="#01256C"/>
+<path d="M819.602 45.5028V40.8153H820.397V45.5028H819.602ZM817.656 43.5568V42.7614H822.343V43.5568H817.656Z" fill="#01256C"/>
+<path d="M831.602 45.5028V40.8153H832.397V45.5028H831.602ZM829.656 43.5568V42.7614H834.343V43.5568H829.656Z" fill="#01256C"/>
+<path d="M843.602 45.5028V40.8153H844.397V45.5028H843.602ZM841.656 43.5568V42.7614H846.343V43.5568H841.656Z" fill="#01256C"/>
+<path d="M855.602 45.5028V40.8153H856.397V45.5028H855.602ZM853.656 43.5568V42.7614H858.343V43.5568H853.656Z" fill="#01256C"/>
+<path d="M867.602 45.5028V40.8153H868.397V45.5028H867.602ZM865.656 43.5568V42.7614H870.343V43.5568H865.656Z" fill="#01256C"/>
+<path d="M879.602 45.5028V40.8153H880.397V45.5028H879.602ZM877.656 43.5568V42.7614H882.343V43.5568H877.656Z" fill="#01256C"/>
+<path d="M891.602 45.5028V40.8153H892.397V45.5028H891.602ZM889.656 43.5568V42.7614H894.343V43.5568H889.656Z" fill="#01256C"/>
+<path d="M1059.6 45.5028V40.8153H1060.4V45.5028H1059.6ZM1057.66 43.5568V42.7614H1062.34V43.5568H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 45.5028V40.8153H1072.4V45.5028H1071.6ZM1069.66 43.5568V42.7614H1074.34V43.5568H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 45.5028V40.8153H1084.4V45.5028H1083.6ZM1081.66 43.5568V42.7614H1086.34V43.5568H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 45.5028V40.8153H1096.4V45.5028H1095.6ZM1093.66 43.5568V42.7614H1098.34V43.5568H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 45.5028V40.8153H1108.4V45.5028H1107.6ZM1105.66 43.5568V42.7614H1110.34V43.5568H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 45.5028V40.8153H1120.4V45.5028H1119.6ZM1117.66 43.5568V42.7614H1122.34V43.5568H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 45.5028V40.8153H1132.4V45.5028H1131.6ZM1129.66 43.5568V42.7614H1134.34V43.5568H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 45.5028V40.8153H1144.4V45.5028H1143.6ZM1141.66 43.5568V42.7614H1146.34V43.5568H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 45.5028V40.8153H1156.4V45.5028H1155.6ZM1153.66 43.5568V42.7614H1158.34V43.5568H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 57.5028V52.8153H4.39728V57.5028H3.60183ZM1.65581 55.5568V54.7614H6.34331V55.5568H1.65581Z" fill="#01256C"/>
+<path d="M207.659 54.8182L207.716 53.2557L206.395 54.0938L206.054 53.4972L207.446 52.7727L206.054 52.0483L206.395 51.4517L207.716 52.2898L207.659 50.7273H208.341L208.284 52.2898L209.605 51.4517L209.946 52.0483L208.554 52.7727L209.946 53.4972L209.605 54.0938L208.284 53.2557L208.341 54.8182H207.659Z" fill="#01256C"/>
+<path d="M219.602 57.5028V52.8153H220.397V57.5028H219.602ZM217.656 55.5568V54.7614H222.343V55.5568H217.656Z" fill="#01256C"/>
+<path d="M231.602 57.5028V52.8153H232.397V57.5028H231.602ZM229.656 55.5568V54.7614H234.343V55.5568H229.656Z" fill="#01256C"/>
+<path d="M243.602 57.5028V52.8153H244.397V57.5028H243.602ZM241.656 55.5568V54.7614H246.343V55.5568H241.656Z" fill="#01256C"/>
+<path d="M255.602 57.5028V52.8153H256.397V57.5028H255.602ZM253.656 55.5568V54.7614H258.343V55.5568H253.656Z" fill="#01256C"/>
+<path d="M267.602 57.5028V52.8153H268.397V57.5028H267.602ZM265.656 55.5568V54.7614H270.343V55.5568H265.656Z" fill="#01256C"/>
+<path d="M279.602 57.5028V52.8153H280.397V57.5028H279.602ZM277.656 55.5568V54.7614H282.343V55.5568H277.656Z" fill="#01256C"/>
+<path d="M291.602 57.5028V52.8153H292.397V57.5028H291.602ZM289.656 55.5568V54.7614H294.343V55.5568H289.656Z" fill="#01256C"/>
+<path d="M303.602 57.5028V52.8153H304.397V57.5028H303.602ZM301.656 55.5568V54.7614H306.343V55.5568H301.656Z" fill="#01256C"/>
+<path d="M315.602 57.5028V52.8153H316.397V57.5028H315.602ZM313.656 55.5568V54.7614H318.343V55.5568H313.656Z" fill="#01256C"/>
+<path d="M327.602 57.5028V52.8153H328.397V57.5028H327.602ZM325.656 55.5568V54.7614H330.343V55.5568H325.656Z" fill="#01256C"/>
+<path d="M339.602 57.5028V52.8153H340.397V57.5028H339.602ZM337.656 55.5568V54.7614H342.343V55.5568H337.656Z" fill="#01256C"/>
+<path d="M351.602 57.5028V52.8153H352.397V57.5028H351.602ZM349.656 55.5568V54.7614H354.343V55.5568H349.656Z" fill="#01256C"/>
+<path d="M363.602 57.5028V52.8153H364.397V57.5028H363.602ZM361.656 55.5568V54.7614H366.343V55.5568H361.656Z" fill="#01256C"/>
+<path d="M375.602 57.5028V52.8153H376.397V57.5028H375.602ZM373.656 55.5568V54.7614H378.343V55.5568H373.656Z" fill="#01256C"/>
+<path d="M387.602 57.5028V52.8153H388.397V57.5028H387.602ZM385.656 55.5568V54.7614H390.343V55.5568H385.656Z" fill="#01256C"/>
+<path d="M399.602 57.5028V52.8153H400.397V57.5028H399.602ZM397.656 55.5568V54.7614H402.343V55.5568H397.656Z" fill="#01256C"/>
+<path d="M411.602 57.5028V52.8153H412.397V57.5028H411.602ZM409.656 55.5568V54.7614H414.343V55.5568H409.656Z" fill="#01256C"/>
+<path d="M423.602 57.5028V52.8153H424.397V57.5028H423.602ZM421.656 55.5568V54.7614H426.343V55.5568H421.656Z" fill="#01256C"/>
+<path d="M435.602 57.5028V52.8153H436.397V57.5028H435.602ZM433.656 55.5568V54.7614H438.343V55.5568H433.656Z" fill="#01256C"/>
+<path d="M447.602 57.5028V52.8153H448.397V57.5028H447.602ZM445.656 55.5568V54.7614H450.343V55.5568H445.656Z" fill="#01256C"/>
+<path d="M459.602 57.5028V52.8153H460.397V57.5028H459.602ZM457.656 55.5568V54.7614H462.343V55.5568H457.656Z" fill="#01256C"/>
+<path d="M471.659 54.8182L471.716 53.2557L470.395 54.0938L470.054 53.4972L471.446 52.7727L470.054 52.0483L470.395 51.4517L471.716 52.2898L471.659 50.7273H472.341L472.284 52.2898L473.605 51.4517L473.946 52.0483L472.554 52.7727L473.946 53.4972L473.605 54.0938L472.284 53.2557L472.341 54.8182H471.659Z" fill="#01256C"/>
+<path d="M687.659 54.8182L687.716 53.2557L686.395 54.0938L686.054 53.4972L687.446 52.7727L686.054 52.0483L686.395 51.4517L687.716 52.2898L687.659 50.7273H688.341L688.284 52.2898L689.605 51.4517L689.946 52.0483L688.554 52.7727L689.946 53.4972L689.605 54.0938L688.284 53.2557L688.341 54.8182H687.659Z" fill="#01256C"/>
+<path d="M699.602 57.5028V52.8153H700.397V57.5028H699.602ZM697.656 55.5568V54.7614H702.343V55.5568H697.656Z" fill="#01256C"/>
+<path d="M711.602 57.5028V52.8153H712.397V57.5028H711.602ZM709.656 55.5568V54.7614H714.343V55.5568H709.656Z" fill="#01256C"/>
+<path d="M723.602 57.5028V52.8153H724.397V57.5028H723.602ZM721.656 55.5568V54.7614H726.343V55.5568H721.656Z" fill="#01256C"/>
+<path d="M735.602 57.5028V52.8153H736.397V57.5028H735.602ZM733.656 55.5568V54.7614H738.343V55.5568H733.656Z" fill="#01256C"/>
+<path d="M747.602 57.5028V52.8153H748.397V57.5028H747.602ZM745.656 55.5568V54.7614H750.343V55.5568H745.656Z" fill="#01256C"/>
+<path d="M759.602 57.5028V52.8153H760.397V57.5028H759.602ZM757.656 55.5568V54.7614H762.343V55.5568H757.656Z" fill="#01256C"/>
+<path d="M771.602 57.5028V52.8153H772.397V57.5028H771.602ZM769.656 55.5568V54.7614H774.343V55.5568H769.656Z" fill="#01256C"/>
+<path d="M783.602 57.5028V52.8153H784.397V57.5028H783.602ZM781.656 55.5568V54.7614H786.343V55.5568H781.656Z" fill="#01256C"/>
+<path d="M795.602 57.5028V52.8153H796.397V57.5028H795.602ZM793.656 55.5568V54.7614H798.343V55.5568H793.656Z" fill="#01256C"/>
+<path d="M807.602 57.5028V52.8153H808.397V57.5028H807.602ZM805.656 55.5568V54.7614H810.343V55.5568H805.656Z" fill="#01256C"/>
+<path d="M819.602 57.5028V52.8153H820.397V57.5028H819.602ZM817.656 55.5568V54.7614H822.343V55.5568H817.656Z" fill="#01256C"/>
+<path d="M831.602 57.5028V52.8153H832.397V57.5028H831.602ZM829.656 55.5568V54.7614H834.343V55.5568H829.656Z" fill="#01256C"/>
+<path d="M843.602 57.5028V52.8153H844.397V57.5028H843.602ZM841.656 55.5568V54.7614H846.343V55.5568H841.656Z" fill="#01256C"/>
+<path d="M855.602 57.5028V52.8153H856.397V57.5028H855.602ZM853.656 55.5568V54.7614H858.343V55.5568H853.656Z" fill="#01256C"/>
+<path d="M867.602 57.5028V52.8153H868.397V57.5028H867.602ZM865.656 55.5568V54.7614H870.343V55.5568H865.656Z" fill="#01256C"/>
+<path d="M879.602 57.5028V52.8153H880.397V57.5028H879.602ZM877.656 55.5568V54.7614H882.343V55.5568H877.656Z" fill="#01256C"/>
+<path d="M891.602 57.5028V52.8153H892.397V57.5028H891.602ZM889.656 55.5568V54.7614H894.343V55.5568H889.656Z" fill="#01256C"/>
+<path d="M1047.6 57.5028V52.8153H1048.4V57.5028H1047.6ZM1045.66 55.5568V54.7614H1050.34V55.5568H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 57.5028V52.8153H1060.4V57.5028H1059.6ZM1057.66 55.5568V54.7614H1062.34V55.5568H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 57.5028V52.8153H1072.4V57.5028H1071.6ZM1069.66 55.5568V54.7614H1074.34V55.5568H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 57.5028V52.8153H1084.4V57.5028H1083.6ZM1081.66 55.5568V54.7614H1086.34V55.5568H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 57.5028V52.8153H1096.4V57.5028H1095.6ZM1093.66 55.5568V54.7614H1098.34V55.5568H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 57.5028V52.8153H1108.4V57.5028H1107.6ZM1105.66 55.5568V54.7614H1110.34V55.5568H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 57.5028V52.8153H1120.4V57.5028H1119.6ZM1117.66 55.5568V54.7614H1122.34V55.5568H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 57.5028V52.8153H1132.4V57.5028H1131.6ZM1129.66 55.5568V54.7614H1134.34V55.5568H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 57.5028V52.8153H1144.4V57.5028H1143.6ZM1141.66 55.5568V54.7614H1146.34V55.5568H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 57.5028V52.8153H1156.4V57.5028H1155.6ZM1153.66 55.5568V54.7614H1158.34V55.5568H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 69.5028V64.8153H4.39728V69.5028H3.60183ZM1.65581 67.5568V66.7614H6.34331V67.5568H1.65581Z" fill="#01256C"/>
+<path d="M231.602 69.5028V64.8153H232.397V69.5028H231.602ZM229.656 67.5568V66.7614H234.343V67.5568H229.656Z" fill="#01256C"/>
+<path d="M243.602 69.5028V64.8153H244.397V69.5028H243.602ZM241.656 67.5568V66.7614H246.343V67.5568H241.656Z" fill="#01256C"/>
+<path d="M255.602 69.5028V64.8153H256.397V69.5028H255.602ZM253.656 67.5568V66.7614H258.343V67.5568H253.656Z" fill="#01256C"/>
+<path d="M267.602 69.5028V64.8153H268.397V69.5028H267.602ZM265.656 67.5568V66.7614H270.343V67.5568H265.656Z" fill="#01256C"/>
+<path d="M279.602 69.5028V64.8153H280.397V69.5028H279.602ZM277.656 67.5568V66.7614H282.343V67.5568H277.656Z" fill="#01256C"/>
+<path d="M291.602 69.5028V64.8153H292.397V69.5028H291.602ZM289.656 67.5568V66.7614H294.343V67.5568H289.656Z" fill="#01256C"/>
+<path d="M303.602 69.5028V64.8153H304.397V69.5028H303.602ZM301.656 67.5568V66.7614H306.343V67.5568H301.656Z" fill="#01256C"/>
+<path d="M315.602 69.5028V64.8153H316.397V69.5028H315.602ZM313.656 67.5568V66.7614H318.343V67.5568H313.656Z" fill="#01256C"/>
+<path d="M327.602 69.5028V64.8153H328.397V69.5028H327.602ZM325.656 67.5568V66.7614H330.343V67.5568H325.656Z" fill="#01256C"/>
+<path d="M339.602 69.5028V64.8153H340.397V69.5028H339.602ZM337.656 67.5568V66.7614H342.343V67.5568H337.656Z" fill="#01256C"/>
+<path d="M351.602 69.5028V64.8153H352.397V69.5028H351.602ZM349.656 67.5568V66.7614H354.343V67.5568H349.656Z" fill="#01256C"/>
+<path d="M363.602 69.5028V64.8153H364.397V69.5028H363.602ZM361.656 67.5568V66.7614H366.343V67.5568H361.656Z" fill="#01256C"/>
+<path d="M375.602 69.5028V64.8153H376.397V69.5028H375.602ZM373.656 67.5568V66.7614H378.343V67.5568H373.656Z" fill="#01256C"/>
+<path d="M387.602 69.5028V64.8153H388.397V69.5028H387.602ZM385.656 67.5568V66.7614H390.343V67.5568H385.656Z" fill="#01256C"/>
+<path d="M399.602 69.5028V64.8153H400.397V69.5028H399.602ZM397.656 67.5568V66.7614H402.343V67.5568H397.656Z" fill="#01256C"/>
+<path d="M411.602 69.5028V64.8153H412.397V69.5028H411.602ZM409.656 67.5568V66.7614H414.343V67.5568H409.656Z" fill="#01256C"/>
+<path d="M423.602 69.5028V64.8153H424.397V69.5028H423.602ZM421.656 67.5568V66.7614H426.343V67.5568H421.656Z" fill="#01256C"/>
+<path d="M711.602 69.5028V64.8153H712.397V69.5028H711.602ZM709.656 67.5568V66.7614H714.343V67.5568H709.656Z" fill="#01256C"/>
+<path d="M723.602 69.5028V64.8153H724.397V69.5028H723.602ZM721.656 67.5568V66.7614H726.343V67.5568H721.656Z" fill="#01256C"/>
+<path d="M735.602 69.5028V64.8153H736.397V69.5028H735.602ZM733.656 67.5568V66.7614H738.343V67.5568H733.656Z" fill="#01256C"/>
+<path d="M747.602 69.5028V64.8153H748.397V69.5028H747.602ZM745.656 67.5568V66.7614H750.343V67.5568H745.656Z" fill="#01256C"/>
+<path d="M759.602 69.5028V64.8153H760.397V69.5028H759.602ZM757.656 67.5568V66.7614H762.343V67.5568H757.656Z" fill="#01256C"/>
+<path d="M771.602 69.5028V64.8153H772.397V69.5028H771.602ZM769.656 67.5568V66.7614H774.343V67.5568H769.656Z" fill="#01256C"/>
+<path d="M783.602 69.5028V64.8153H784.397V69.5028H783.602ZM781.656 67.5568V66.7614H786.343V67.5568H781.656Z" fill="#01256C"/>
+<path d="M795.602 69.5028V64.8153H796.397V69.5028H795.602ZM793.656 67.5568V66.7614H798.343V67.5568H793.656Z" fill="#01256C"/>
+<path d="M807.602 69.5028V64.8153H808.397V69.5028H807.602ZM805.656 67.5568V66.7614H810.343V67.5568H805.656Z" fill="#01256C"/>
+<path d="M819.602 69.5028V64.8153H820.397V69.5028H819.602ZM817.656 67.5568V66.7614H822.343V67.5568H817.656Z" fill="#01256C"/>
+<path d="M831.602 69.5028V64.8153H832.397V69.5028H831.602ZM829.656 67.5568V66.7614H834.343V67.5568H829.656Z" fill="#01256C"/>
+<path d="M843.602 69.5028V64.8153H844.397V69.5028H843.602ZM841.656 67.5568V66.7614H846.343V67.5568H841.656Z" fill="#01256C"/>
+<path d="M855.602 69.5028V64.8153H856.397V69.5028H855.602ZM853.656 67.5568V66.7614H858.343V67.5568H853.656Z" fill="#01256C"/>
+<path d="M867.602 69.5028V64.8153H868.397V69.5028H867.602ZM865.656 67.5568V66.7614H870.343V67.5568H865.656Z" fill="#01256C"/>
+<path d="M879.602 69.5028V64.8153H880.397V69.5028H879.602ZM877.656 67.5568V66.7614H882.343V67.5568H877.656Z" fill="#01256C"/>
+<path d="M891.602 69.5028V64.8153H892.397V69.5028H891.602ZM889.656 67.5568V66.7614H894.343V67.5568H889.656Z" fill="#01256C"/>
+<path d="M1035.6 69.5028V64.8153H1036.4V69.5028H1035.6ZM1033.66 67.5568V66.7614H1038.34V67.5568H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 69.5028V64.8153H1048.4V69.5028H1047.6ZM1045.66 67.5568V66.7614H1050.34V67.5568H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 69.5028V64.8153H1060.4V69.5028H1059.6ZM1057.66 67.5568V66.7614H1062.34V67.5568H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 69.5028V64.8153H1072.4V69.5028H1071.6ZM1069.66 67.5568V66.7614H1074.34V67.5568H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 69.5028V64.8153H1084.4V69.5028H1083.6ZM1081.66 67.5568V66.7614H1086.34V67.5568H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 69.5028V64.8153H1096.4V69.5028H1095.6ZM1093.66 67.5568V66.7614H1098.34V67.5568H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 69.5028V64.8153H1108.4V69.5028H1107.6ZM1105.66 67.5568V66.7614H1110.34V67.5568H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 69.5028V64.8153H1120.4V69.5028H1119.6ZM1117.66 67.5568V66.7614H1122.34V67.5568H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 69.5028V64.8153H1132.4V69.5028H1131.6ZM1129.66 67.5568V66.7614H1134.34V67.5568H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 69.5028V64.8153H1144.4V69.5028H1143.6ZM1141.66 67.5568V66.7614H1146.34V67.5568H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 69.5028V64.8153H1156.4V69.5028H1155.6ZM1153.66 67.5568V66.7614H1158.34V67.5568H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 81.5028V76.8153H4.39728V81.5028H3.60183ZM1.65581 79.5568V78.7614H6.34331V79.5568H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 81.5028V76.8153H16.3973V81.5028H15.6018ZM13.6558 79.5568V78.7614H18.3433V79.5568H13.6558Z" fill="#01256C"/>
+<path d="M267.602 81.5028V76.8153H268.397V81.5028H267.602ZM265.656 79.5568V78.7614H270.343V79.5568H265.656Z" fill="#01256C"/>
+<path d="M279.602 81.5028V76.8153H280.397V81.5028H279.602ZM277.656 79.5568V78.7614H282.343V79.5568H277.656Z" fill="#01256C"/>
+<path d="M291.602 81.5028V76.8153H292.397V81.5028H291.602ZM289.656 79.5568V78.7614H294.343V79.5568H289.656Z" fill="#01256C"/>
+<path d="M303.602 81.5028V76.8153H304.397V81.5028H303.602ZM301.656 79.5568V78.7614H306.343V79.5568H301.656Z" fill="#01256C"/>
+<path d="M315.602 81.5028V76.8153H316.397V81.5028H315.602ZM313.656 79.5568V78.7614H318.343V79.5568H313.656Z" fill="#01256C"/>
+<path d="M327.602 81.5028V76.8153H328.397V81.5028H327.602ZM325.656 79.5568V78.7614H330.343V79.5568H325.656Z" fill="#01256C"/>
+<path d="M339.602 81.5028V76.8153H340.397V81.5028H339.602ZM337.656 79.5568V78.7614H342.343V79.5568H337.656Z" fill="#01256C"/>
+<path d="M351.602 81.5028V76.8153H352.397V81.5028H351.602ZM349.656 79.5568V78.7614H354.343V79.5568H349.656Z" fill="#01256C"/>
+<path d="M363.602 81.5028V76.8153H364.397V81.5028H363.602ZM361.656 79.5568V78.7614H366.343V79.5568H361.656Z" fill="#01256C"/>
+<path d="M375.602 81.5028V76.8153H376.397V81.5028H375.602ZM373.656 79.5568V78.7614H378.343V79.5568H373.656Z" fill="#01256C"/>
+<path d="M387.602 81.5028V76.8153H388.397V81.5028H387.602ZM385.656 79.5568V78.7614H390.343V79.5568H385.656Z" fill="#01256C"/>
+<path d="M399.602 81.5028V76.8153H400.397V81.5028H399.602ZM397.656 79.5568V78.7614H402.343V79.5568H397.656Z" fill="#01256C"/>
+<path d="M411.602 81.5028V76.8153H412.397V81.5028H411.602ZM409.656 79.5568V78.7614H414.343V79.5568H409.656Z" fill="#01256C"/>
+<path d="M723.602 81.5028V76.8153H724.397V81.5028H723.602ZM721.656 79.5568V78.7614H726.343V79.5568H721.656Z" fill="#01256C"/>
+<path d="M735.602 81.5028V76.8153H736.397V81.5028H735.602ZM733.656 79.5568V78.7614H738.343V79.5568H733.656Z" fill="#01256C"/>
+<path d="M747.602 81.5028V76.8153H748.397V81.5028H747.602ZM745.656 79.5568V78.7614H750.343V79.5568H745.656Z" fill="#01256C"/>
+<path d="M759.602 81.5028V76.8153H760.397V81.5028H759.602ZM757.656 79.5568V78.7614H762.343V79.5568H757.656Z" fill="#01256C"/>
+<path d="M771.602 81.5028V76.8153H772.397V81.5028H771.602ZM769.656 79.5568V78.7614H774.343V79.5568H769.656Z" fill="#01256C"/>
+<path d="M783.602 81.5028V76.8153H784.397V81.5028H783.602ZM781.656 79.5568V78.7614H786.343V79.5568H781.656Z" fill="#01256C"/>
+<path d="M795.602 81.5028V76.8153H796.397V81.5028H795.602ZM793.656 79.5568V78.7614H798.343V79.5568H793.656Z" fill="#01256C"/>
+<path d="M807.602 81.5028V76.8153H808.397V81.5028H807.602ZM805.656 79.5568V78.7614H810.343V79.5568H805.656Z" fill="#01256C"/>
+<path d="M819.602 81.5028V76.8153H820.397V81.5028H819.602ZM817.656 79.5568V78.7614H822.343V79.5568H817.656Z" fill="#01256C"/>
+<path d="M831.602 81.5028V76.8153H832.397V81.5028H831.602ZM829.656 79.5568V78.7614H834.343V79.5568H829.656Z" fill="#01256C"/>
+<path d="M843.602 81.5028V76.8153H844.397V81.5028H843.602ZM841.656 79.5568V78.7614H846.343V79.5568H841.656Z" fill="#01256C"/>
+<path d="M855.602 81.5028V76.8153H856.397V81.5028H855.602ZM853.656 79.5568V78.7614H858.343V79.5568H853.656Z" fill="#01256C"/>
+<path d="M867.602 81.5028V76.8153H868.397V81.5028H867.602ZM865.656 79.5568V78.7614H870.343V79.5568H865.656Z" fill="#01256C"/>
+<path d="M879.602 81.5028V76.8153H880.397V81.5028H879.602ZM877.656 79.5568V78.7614H882.343V79.5568H877.656Z" fill="#01256C"/>
+<path d="M1023.6 81.5028V76.8153H1024.4V81.5028H1023.6ZM1021.66 79.5568V78.7614H1026.34V79.5568H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 81.5028V76.8153H1036.4V81.5028H1035.6ZM1033.66 79.5568V78.7614H1038.34V79.5568H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 81.5028V76.8153H1048.4V81.5028H1047.6ZM1045.66 79.5568V78.7614H1050.34V79.5568H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 81.5028V76.8153H1060.4V81.5028H1059.6ZM1057.66 79.5568V78.7614H1062.34V79.5568H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 81.5028V76.8153H1072.4V81.5028H1071.6ZM1069.66 79.5568V78.7614H1074.34V79.5568H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 81.5028V76.8153H1084.4V81.5028H1083.6ZM1081.66 79.5568V78.7614H1086.34V79.5568H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 81.5028V76.8153H1096.4V81.5028H1095.6ZM1093.66 79.5568V78.7614H1098.34V79.5568H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 81.5028V76.8153H1108.4V81.5028H1107.6ZM1105.66 79.5568V78.7614H1110.34V79.5568H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 81.5028V76.8153H1120.4V81.5028H1119.6ZM1117.66 79.5568V78.7614H1122.34V79.5568H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 81.5028V76.8153H1132.4V81.5028H1131.6ZM1129.66 79.5568V78.7614H1134.34V79.5568H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 81.5028V76.8153H1144.4V81.5028H1143.6ZM1141.66 79.5568V78.7614H1146.34V79.5568H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 81.5028V76.8153H1156.4V81.5028H1155.6ZM1153.66 79.5568V78.7614H1158.34V79.5568H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 93.5028V88.8153H4.39728V93.5028H3.60183ZM1.65581 91.5568V90.7614H6.34331V91.5568H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 93.5028V88.8153H16.3973V93.5028H15.6018ZM13.6558 91.5568V90.7614H18.3433V91.5568H13.6558Z" fill="#01256C"/>
+<path d="M327.602 93.5028V88.8153H328.397V93.5028H327.602ZM325.656 91.5568V90.7614H330.343V91.5568H325.656Z" fill="#01256C"/>
+<path d="M339.602 93.5028V88.8153H340.397V93.5028H339.602ZM337.656 91.5568V90.7614H342.343V91.5568H337.656Z" fill="#01256C"/>
+<path d="M351.602 93.5028V88.8153H352.397V93.5028H351.602ZM349.656 91.5568V90.7614H354.343V91.5568H349.656Z" fill="#01256C"/>
+<path d="M363.602 93.5028V88.8153H364.397V93.5028H363.602ZM361.656 91.5568V90.7614H366.343V91.5568H361.656Z" fill="#01256C"/>
+<path d="M375.602 93.5028V88.8153H376.397V93.5028H375.602ZM373.656 91.5568V90.7614H378.343V91.5568H373.656Z" fill="#01256C"/>
+<path d="M387.602 93.5028V88.8153H388.397V93.5028H387.602ZM385.656 91.5568V90.7614H390.343V91.5568H385.656Z" fill="#01256C"/>
+<path d="M735.602 93.5028V88.8153H736.397V93.5028H735.602ZM733.656 91.5568V90.7614H738.343V91.5568H733.656Z" fill="#01256C"/>
+<path d="M747.602 93.5028V88.8153H748.397V93.5028H747.602ZM745.656 91.5568V90.7614H750.343V91.5568H745.656Z" fill="#01256C"/>
+<path d="M759.602 93.5028V88.8153H760.397V93.5028H759.602ZM757.656 91.5568V90.7614H762.343V91.5568H757.656Z" fill="#01256C"/>
+<path d="M771.602 93.5028V88.8153H772.397V93.5028H771.602ZM769.656 91.5568V90.7614H774.343V91.5568H769.656Z" fill="#01256C"/>
+<path d="M783.602 93.5028V88.8153H784.397V93.5028H783.602ZM781.656 91.5568V90.7614H786.343V91.5568H781.656Z" fill="#01256C"/>
+<path d="M795.602 93.5028V88.8153H796.397V93.5028H795.602ZM793.656 91.5568V90.7614H798.343V91.5568H793.656Z" fill="#01256C"/>
+<path d="M807.602 93.5028V88.8153H808.397V93.5028H807.602ZM805.656 91.5568V90.7614H810.343V91.5568H805.656Z" fill="#01256C"/>
+<path d="M819.602 93.5028V88.8153H820.397V93.5028H819.602ZM817.656 91.5568V90.7614H822.343V91.5568H817.656Z" fill="#01256C"/>
+<path d="M831.602 93.5028V88.8153H832.397V93.5028H831.602ZM829.656 91.5568V90.7614H834.343V91.5568H829.656Z" fill="#01256C"/>
+<path d="M843.602 93.5028V88.8153H844.397V93.5028H843.602ZM841.656 91.5568V90.7614H846.343V91.5568H841.656Z" fill="#01256C"/>
+<path d="M855.602 93.5028V88.8153H856.397V93.5028H855.602ZM853.656 91.5568V90.7614H858.343V91.5568H853.656Z" fill="#01256C"/>
+<path d="M867.602 93.5028V88.8153H868.397V93.5028H867.602ZM865.656 91.5568V90.7614H870.343V91.5568H865.656Z" fill="#01256C"/>
+<path d="M879.602 93.5028V88.8153H880.397V93.5028H879.602ZM877.656 91.5568V90.7614H882.343V91.5568H877.656Z" fill="#01256C"/>
+<path d="M1012.62 93.0057L1012.56 93.3892C1012.52 93.6591 1012.46 93.9479 1012.37 94.2557C1012.29 94.5634 1012.21 94.8535 1012.12 95.1257C1012.03 95.398 1011.96 95.6146 1011.91 95.7756H1011.27C1011.3 95.6241 1011.34 95.424 1011.39 95.1754C1011.44 94.9268 1011.49 94.6487 1011.54 94.3409C1011.59 94.0355 1011.63 93.723 1011.66 93.4034L1011.71 93.0057H1012.62ZM1012.1 90.0085C1011.93 90.0085 1011.78 89.9458 1011.65 89.8203C1011.53 89.6948 1011.47 89.5445 1011.47 89.3693C1011.47 89.1941 1011.53 89.0438 1011.65 88.9183C1011.78 88.7929 1011.93 88.7301 1012.1 88.7301C1012.28 88.7301 1012.43 88.7929 1012.56 88.9183C1012.68 89.0438 1012.74 89.1941 1012.74 89.3693C1012.74 89.4853 1012.71 89.5919 1012.65 89.6889C1012.6 89.786 1012.52 89.8641 1012.42 89.9233C1012.33 89.9801 1012.22 90.0085 1012.1 90.0085Z" fill="#01256C"/>
+<path d="M1023.6 93.5028V88.8153H1024.4V93.5028H1023.6ZM1021.66 91.5568V90.7614H1026.34V91.5568H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 93.5028V88.8153H1036.4V93.5028H1035.6ZM1033.66 91.5568V90.7614H1038.34V91.5568H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 93.5028V88.8153H1048.4V93.5028H1047.6ZM1045.66 91.5568V90.7614H1050.34V91.5568H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 93.5028V88.8153H1060.4V93.5028H1059.6ZM1057.66 91.5568V90.7614H1062.34V91.5568H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 93.5028V88.8153H1072.4V93.5028H1071.6ZM1069.66 91.5568V90.7614H1074.34V91.5568H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 93.5028V88.8153H1084.4V93.5028H1083.6ZM1081.66 91.5568V90.7614H1086.34V91.5568H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 93.5028V88.8153H1096.4V93.5028H1095.6ZM1093.66 91.5568V90.7614H1098.34V91.5568H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 93.5028V88.8153H1108.4V93.5028H1107.6ZM1105.66 91.5568V90.7614H1110.34V91.5568H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 93.5028V88.8153H1120.4V93.5028H1119.6ZM1117.66 91.5568V90.7614H1122.34V91.5568H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 93.5028V88.8153H1132.4V93.5028H1131.6ZM1129.66 91.5568V90.7614H1134.34V91.5568H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 93.5028V88.8153H1144.4V93.5028H1143.6ZM1141.66 91.5568V90.7614H1146.34V91.5568H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 93.5028V88.8153H1156.4V93.5028H1155.6ZM1153.66 91.5568V90.7614H1158.34V91.5568H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 105.503V100.815H4.39728V105.503H3.60183ZM1.65581 103.557V102.761H6.34331V103.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 105.503V100.815H16.3973V105.503H15.6018ZM13.6558 103.557V102.761H18.3433V103.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 105.503V100.815H28.3973V105.503H27.6018ZM25.6558 103.557V102.761H30.3433V103.557H25.6558Z" fill="#01256C"/>
+<path d="M747.602 105.503V100.815H748.397V105.503H747.602ZM745.656 103.557V102.761H750.343V103.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 105.503V100.815H760.397V105.503H759.602ZM757.656 103.557V102.761H762.343V103.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 105.503V100.815H772.397V105.503H771.602ZM769.656 103.557V102.761H774.343V103.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 105.503V100.815H784.397V105.503H783.602ZM781.656 103.557V102.761H786.343V103.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 105.503V100.815H796.397V105.503H795.602ZM793.656 103.557V102.761H798.343V103.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 105.503V100.815H808.397V105.503H807.602ZM805.656 103.557V102.761H810.343V103.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 105.503V100.815H820.397V105.503H819.602ZM817.656 103.557V102.761H822.343V103.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 105.503V100.815H832.397V105.503H831.602ZM829.656 103.557V102.761H834.343V103.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 105.503V100.815H844.397V105.503H843.602ZM841.656 103.557V102.761H846.343V103.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 105.503V100.815H856.397V105.503H855.602ZM853.656 103.557V102.761H858.343V103.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 105.503V100.815H868.397V105.503H867.602ZM865.656 103.557V102.761H870.343V103.557H865.656Z" fill="#01256C"/>
+<path d="M879.602 105.503V100.815H880.397V105.503H879.602ZM877.656 103.557V102.761H882.343V103.557H877.656Z" fill="#01256C"/>
+<path d="M1011.6 105.503V100.815H1012.4V105.503H1011.6ZM1009.66 103.557V102.761H1014.34V103.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 105.503V100.815H1024.4V105.503H1023.6ZM1021.66 103.557V102.761H1026.34V103.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 105.503V100.815H1036.4V105.503H1035.6ZM1033.66 103.557V102.761H1038.34V103.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 105.503V100.815H1048.4V105.503H1047.6ZM1045.66 103.557V102.761H1050.34V103.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 105.503V100.815H1060.4V105.503H1059.6ZM1057.66 103.557V102.761H1062.34V103.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 105.503V100.815H1072.4V105.503H1071.6ZM1069.66 103.557V102.761H1074.34V103.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 105.503V100.815H1084.4V105.503H1083.6ZM1081.66 103.557V102.761H1086.34V103.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 105.503V100.815H1096.4V105.503H1095.6ZM1093.66 103.557V102.761H1098.34V103.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 105.503V100.815H1108.4V105.503H1107.6ZM1105.66 103.557V102.761H1110.34V103.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 105.503V100.815H1120.4V105.503H1119.6ZM1117.66 103.557V102.761H1122.34V103.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 105.503V100.815H1132.4V105.503H1131.6ZM1129.66 103.557V102.761H1134.34V103.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 105.503V100.815H1144.4V105.503H1143.6ZM1141.66 103.557V102.761H1146.34V103.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 105.503V100.815H1156.4V105.503H1155.6ZM1153.66 103.557V102.761H1158.34V103.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 117.503V112.815H4.39728V117.503H3.60183ZM1.65581 115.557V114.761H6.34331V115.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 117.503V112.815H16.3973V117.503H15.6018ZM13.6558 115.557V114.761H18.3433V115.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 117.503V112.815H28.3973V117.503H27.6018ZM25.6558 115.557V114.761H30.3433V115.557H25.6558Z" fill="#01256C"/>
+<path d="M747.602 117.503V112.815H748.397V117.503H747.602ZM745.656 115.557V114.761H750.343V115.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 117.503V112.815H760.397V117.503H759.602ZM757.656 115.557V114.761H762.343V115.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 117.503V112.815H772.397V117.503H771.602ZM769.656 115.557V114.761H774.343V115.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 117.503V112.815H784.397V117.503H783.602ZM781.656 115.557V114.761H786.343V115.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 117.503V112.815H796.397V117.503H795.602ZM793.656 115.557V114.761H798.343V115.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 117.503V112.815H808.397V117.503H807.602ZM805.656 115.557V114.761H810.343V115.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 117.503V112.815H820.397V117.503H819.602ZM817.656 115.557V114.761H822.343V115.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 117.503V112.815H832.397V117.503H831.602ZM829.656 115.557V114.761H834.343V115.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 117.503V112.815H844.397V117.503H843.602ZM841.656 115.557V114.761H846.343V115.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 117.503V112.815H856.397V117.503H855.602ZM853.656 115.557V114.761H858.343V115.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 117.503V112.815H868.397V117.503H867.602ZM865.656 115.557V114.761H870.343V115.557H865.656Z" fill="#01256C"/>
+<path d="M999.602 117.503V112.815H1000.4V117.503H999.602ZM997.656 115.557V114.761H1002.34V115.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 117.503V112.815H1012.4V117.503H1011.6ZM1009.66 115.557V114.761H1014.34V115.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 117.503V112.815H1024.4V117.503H1023.6ZM1021.66 115.557V114.761H1026.34V115.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 117.503V112.815H1036.4V117.503H1035.6ZM1033.66 115.557V114.761H1038.34V115.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 117.503V112.815H1048.4V117.503H1047.6ZM1045.66 115.557V114.761H1050.34V115.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 117.503V112.815H1060.4V117.503H1059.6ZM1057.66 115.557V114.761H1062.34V115.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 117.503V112.815H1072.4V117.503H1071.6ZM1069.66 115.557V114.761H1074.34V115.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 117.503V112.815H1084.4V117.503H1083.6ZM1081.66 115.557V114.761H1086.34V115.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 117.503V112.815H1096.4V117.503H1095.6ZM1093.66 115.557V114.761H1098.34V115.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 117.503V112.815H1108.4V117.503H1107.6ZM1105.66 115.557V114.761H1110.34V115.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 117.503V112.815H1120.4V117.503H1119.6ZM1117.66 115.557V114.761H1122.34V115.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 117.503V112.815H1132.4V117.503H1131.6ZM1129.66 115.557V114.761H1134.34V115.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 117.503V112.815H1144.4V117.503H1143.6ZM1141.66 115.557V114.761H1146.34V115.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 117.503V112.815H1156.4V117.503H1155.6ZM1153.66 115.557V114.761H1158.34V115.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 129.503V124.815H4.39728V129.503H3.60183ZM1.65581 127.557V126.761H6.34331V127.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 129.503V124.815H16.3973V129.503H15.6018ZM13.6558 127.557V126.761H18.3433V127.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 129.503V124.815H28.3973V129.503H27.6018ZM25.6558 127.557V126.761H30.3433V127.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 129.503V124.815H40.3973V129.503H39.6018ZM37.6558 127.557V126.761H42.3433V127.557H37.6558Z" fill="#01256C"/>
+<path d="M747.602 129.503V124.815H748.397V129.503H747.602ZM745.656 127.557V126.761H750.343V127.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 129.503V124.815H760.397V129.503H759.602ZM757.656 127.557V126.761H762.343V127.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 129.503V124.815H772.397V129.503H771.602ZM769.656 127.557V126.761H774.343V127.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 129.503V124.815H784.397V129.503H783.602ZM781.656 127.557V126.761H786.343V127.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 129.503V124.815H796.397V129.503H795.602ZM793.656 127.557V126.761H798.343V127.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 129.503V124.815H808.397V129.503H807.602ZM805.656 127.557V126.761H810.343V127.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 129.503V124.815H820.397V129.503H819.602ZM817.656 127.557V126.761H822.343V127.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 129.503V124.815H832.397V129.503H831.602ZM829.656 127.557V126.761H834.343V127.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 129.503V124.815H844.397V129.503H843.602ZM841.656 127.557V126.761H846.343V127.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 129.503V124.815H856.397V129.503H855.602ZM853.656 127.557V126.761H858.343V127.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 129.503V124.815H868.397V129.503H867.602ZM865.656 127.557V126.761H870.343V127.557H865.656Z" fill="#01256C"/>
+<path d="M987.602 129.503V124.815H988.397V129.503H987.602ZM985.656 127.557V126.761H990.343V127.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 129.503V124.815H1000.4V129.503H999.602ZM997.656 127.557V126.761H1002.34V127.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 129.503V124.815H1012.4V129.503H1011.6ZM1009.66 127.557V126.761H1014.34V127.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 129.503V124.815H1024.4V129.503H1023.6ZM1021.66 127.557V126.761H1026.34V127.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 129.503V124.815H1036.4V129.503H1035.6ZM1033.66 127.557V126.761H1038.34V127.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 129.503V124.815H1048.4V129.503H1047.6ZM1045.66 127.557V126.761H1050.34V127.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 129.503V124.815H1060.4V129.503H1059.6ZM1057.66 127.557V126.761H1062.34V127.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 129.503V124.815H1072.4V129.503H1071.6ZM1069.66 127.557V126.761H1074.34V127.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 129.503V124.815H1084.4V129.503H1083.6ZM1081.66 127.557V126.761H1086.34V127.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 129.503V124.815H1096.4V129.503H1095.6ZM1093.66 127.557V126.761H1098.34V127.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 129.503V124.815H1108.4V129.503H1107.6ZM1105.66 127.557V126.761H1110.34V127.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 129.503V124.815H1120.4V129.503H1119.6ZM1117.66 127.557V126.761H1122.34V127.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 129.503V124.815H1132.4V129.503H1131.6ZM1129.66 127.557V126.761H1134.34V127.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 129.503V124.815H1144.4V129.503H1143.6ZM1141.66 127.557V126.761H1146.34V127.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 129.503V124.815H1156.4V129.503H1155.6ZM1153.66 127.557V126.761H1158.34V127.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 141.503V136.815H4.39728V141.503H3.60183ZM1.65581 139.557V138.761H6.34331V139.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 141.503V136.815H16.3973V141.503H15.6018ZM13.6558 139.557V138.761H18.3433V139.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 141.503V136.815H28.3973V141.503H27.6018ZM25.6558 139.557V138.761H30.3433V139.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 141.503V136.815H40.3973V141.503H39.6018ZM37.6558 139.557V138.761H42.3433V139.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 141.503V136.815H52.3973V141.503H51.6018ZM49.6558 139.557V138.761H54.3433V139.557H49.6558Z" fill="#01256C"/>
+<path d="M747.602 141.503V136.815H748.397V141.503H747.602ZM745.656 139.557V138.761H750.343V139.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 141.503V136.815H760.397V141.503H759.602ZM757.656 139.557V138.761H762.343V139.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 141.503V136.815H772.397V141.503H771.602ZM769.656 139.557V138.761H774.343V139.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 141.503V136.815H784.397V141.503H783.602ZM781.656 139.557V138.761H786.343V139.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 141.503V136.815H796.397V141.503H795.602ZM793.656 139.557V138.761H798.343V139.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 141.503V136.815H808.397V141.503H807.602ZM805.656 139.557V138.761H810.343V139.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 141.503V136.815H820.397V141.503H819.602ZM817.656 139.557V138.761H822.343V139.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 141.503V136.815H832.397V141.503H831.602ZM829.656 139.557V138.761H834.343V139.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 141.503V136.815H844.397V141.503H843.602ZM841.656 139.557V138.761H846.343V139.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 141.503V136.815H856.397V141.503H855.602ZM853.656 139.557V138.761H858.343V139.557H853.656Z" fill="#01256C"/>
+<path d="M975.602 141.503V136.815H976.397V141.503H975.602ZM973.656 139.557V138.761H978.343V139.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 141.503V136.815H988.397V141.503H987.602ZM985.656 139.557V138.761H990.343V139.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 141.503V136.815H1000.4V141.503H999.602ZM997.656 139.557V138.761H1002.34V139.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 141.503V136.815H1012.4V141.503H1011.6ZM1009.66 139.557V138.761H1014.34V139.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 141.503V136.815H1024.4V141.503H1023.6ZM1021.66 139.557V138.761H1026.34V139.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 141.503V136.815H1036.4V141.503H1035.6ZM1033.66 139.557V138.761H1038.34V139.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 141.503V136.815H1048.4V141.503H1047.6ZM1045.66 139.557V138.761H1050.34V139.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 141.503V136.815H1060.4V141.503H1059.6ZM1057.66 139.557V138.761H1062.34V139.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 141.503V136.815H1072.4V141.503H1071.6ZM1069.66 139.557V138.761H1074.34V139.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 141.503V136.815H1084.4V141.503H1083.6ZM1081.66 139.557V138.761H1086.34V139.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 141.503V136.815H1096.4V141.503H1095.6ZM1093.66 139.557V138.761H1098.34V139.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 141.503V136.815H1108.4V141.503H1107.6ZM1105.66 139.557V138.761H1110.34V139.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 141.503V136.815H1120.4V141.503H1119.6ZM1117.66 139.557V138.761H1122.34V139.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 141.503V136.815H1132.4V141.503H1131.6ZM1129.66 139.557V138.761H1134.34V139.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 141.503V136.815H1144.4V141.503H1143.6ZM1141.66 139.557V138.761H1146.34V139.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 141.503V136.815H1156.4V141.503H1155.6ZM1153.66 139.557V138.761H1158.34V139.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 153.503V148.815H4.39728V153.503H3.60183ZM1.65581 151.557V150.761H6.34331V151.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 153.503V148.815H16.3973V153.503H15.6018ZM13.6558 151.557V150.761H18.3433V151.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 153.503V148.815H28.3973V153.503H27.6018ZM25.6558 151.557V150.761H30.3433V151.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 153.503V148.815H40.3973V153.503H39.6018ZM37.6558 151.557V150.761H42.3433V151.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 153.503V148.815H52.3973V153.503H51.6018ZM49.6558 151.557V150.761H54.3433V151.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 153.503V148.815H64.3973V153.503H63.6018ZM61.6558 151.557V150.761H66.3433V151.557H61.6558Z" fill="#01256C"/>
+<path d="M747.602 153.503V148.815H748.397V153.503H747.602ZM745.656 151.557V150.761H750.343V151.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 153.503V148.815H760.397V153.503H759.602ZM757.656 151.557V150.761H762.343V151.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 153.503V148.815H772.397V153.503H771.602ZM769.656 151.557V150.761H774.343V151.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 153.503V148.815H784.397V153.503H783.602ZM781.656 151.557V150.761H786.343V151.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 153.503V148.815H796.397V153.503H795.602ZM793.656 151.557V150.761H798.343V151.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 153.503V148.815H808.397V153.503H807.602ZM805.656 151.557V150.761H810.343V151.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 153.503V148.815H820.397V153.503H819.602ZM817.656 151.557V150.761H822.343V151.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 153.503V148.815H832.397V153.503H831.602ZM829.656 151.557V150.761H834.343V151.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 153.503V148.815H844.397V153.503H843.602ZM841.656 151.557V150.761H846.343V151.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 153.503V148.815H856.397V153.503H855.602ZM853.656 151.557V150.761H858.343V151.557H853.656Z" fill="#01256C"/>
+<path d="M963.602 153.503V148.815H964.397V153.503H963.602ZM961.656 151.557V150.761H966.343V151.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 153.503V148.815H976.397V153.503H975.602ZM973.656 151.557V150.761H978.343V151.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 153.503V148.815H988.397V153.503H987.602ZM985.656 151.557V150.761H990.343V151.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 153.503V148.815H1000.4V153.503H999.602ZM997.656 151.557V150.761H1002.34V151.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 153.503V148.815H1012.4V153.503H1011.6ZM1009.66 151.557V150.761H1014.34V151.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 153.503V148.815H1024.4V153.503H1023.6ZM1021.66 151.557V150.761H1026.34V151.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 153.503V148.815H1036.4V153.503H1035.6ZM1033.66 151.557V150.761H1038.34V151.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 153.503V148.815H1048.4V153.503H1047.6ZM1045.66 151.557V150.761H1050.34V151.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 153.503V148.815H1060.4V153.503H1059.6ZM1057.66 151.557V150.761H1062.34V151.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 153.503V148.815H1072.4V153.503H1071.6ZM1069.66 151.557V150.761H1074.34V151.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 153.503V148.815H1084.4V153.503H1083.6ZM1081.66 151.557V150.761H1086.34V151.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 153.503V148.815H1096.4V153.503H1095.6ZM1093.66 151.557V150.761H1098.34V151.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 153.503V148.815H1108.4V153.503H1107.6ZM1105.66 151.557V150.761H1110.34V151.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 153.503V148.815H1120.4V153.503H1119.6ZM1117.66 151.557V150.761H1122.34V151.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 153.503V148.815H1132.4V153.503H1131.6ZM1129.66 151.557V150.761H1134.34V151.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 153.503V148.815H1144.4V153.503H1143.6ZM1141.66 151.557V150.761H1146.34V151.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 153.503V148.815H1156.4V153.503H1155.6ZM1153.66 151.557V150.761H1158.34V151.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 165.503V160.815H4.39728V165.503H3.60183ZM1.65581 163.557V162.761H6.34331V163.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 165.503V160.815H16.3973V165.503H15.6018ZM13.6558 163.557V162.761H18.3433V163.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 165.503V160.815H28.3973V165.503H27.6018ZM25.6558 163.557V162.761H30.3433V163.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 165.503V160.815H40.3973V165.503H39.6018ZM37.6558 163.557V162.761H42.3433V163.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 165.503V160.815H52.3973V165.503H51.6018ZM49.6558 163.557V162.761H54.3433V163.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 165.503V160.815H64.3973V165.503H63.6018ZM61.6558 163.557V162.761H66.3433V163.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 165.503V160.815H76.3973V165.503H75.6018ZM73.6558 163.557V162.761H78.3433V163.557H73.6558Z" fill="#01256C"/>
+<path d="M747.602 165.503V160.815H748.397V165.503H747.602ZM745.656 163.557V162.761H750.343V163.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 165.503V160.815H760.397V165.503H759.602ZM757.656 163.557V162.761H762.343V163.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 165.503V160.815H772.397V165.503H771.602ZM769.656 163.557V162.761H774.343V163.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 165.503V160.815H784.397V165.503H783.602ZM781.656 163.557V162.761H786.343V163.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 165.503V160.815H796.397V165.503H795.602ZM793.656 163.557V162.761H798.343V163.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 165.503V160.815H808.397V165.503H807.602ZM805.656 163.557V162.761H810.343V163.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 165.503V160.815H820.397V165.503H819.602ZM817.656 163.557V162.761H822.343V163.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 165.503V160.815H832.397V165.503H831.602ZM829.656 163.557V162.761H834.343V163.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 165.503V160.815H844.397V165.503H843.602ZM841.656 163.557V162.761H846.343V163.557H841.656Z" fill="#01256C"/>
+<path d="M951.602 165.503V160.815H952.397V165.503H951.602ZM949.656 163.557V162.761H954.343V163.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 165.503V160.815H964.397V165.503H963.602ZM961.656 163.557V162.761H966.343V163.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 165.503V160.815H976.397V165.503H975.602ZM973.656 163.557V162.761H978.343V163.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 165.503V160.815H988.397V165.503H987.602ZM985.656 163.557V162.761H990.343V163.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 165.503V160.815H1000.4V165.503H999.602ZM997.656 163.557V162.761H1002.34V163.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 165.503V160.815H1012.4V165.503H1011.6ZM1009.66 163.557V162.761H1014.34V163.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 165.503V160.815H1024.4V165.503H1023.6ZM1021.66 163.557V162.761H1026.34V163.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 165.503V160.815H1036.4V165.503H1035.6ZM1033.66 163.557V162.761H1038.34V163.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 165.503V160.815H1048.4V165.503H1047.6ZM1045.66 163.557V162.761H1050.34V163.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 165.503V160.815H1060.4V165.503H1059.6ZM1057.66 163.557V162.761H1062.34V163.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 165.503V160.815H1072.4V165.503H1071.6ZM1069.66 163.557V162.761H1074.34V163.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 165.503V160.815H1084.4V165.503H1083.6ZM1081.66 163.557V162.761H1086.34V163.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 165.503V160.815H1096.4V165.503H1095.6ZM1093.66 163.557V162.761H1098.34V163.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 165.503V160.815H1108.4V165.503H1107.6ZM1105.66 163.557V162.761H1110.34V163.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 165.503V160.815H1120.4V165.503H1119.6ZM1117.66 163.557V162.761H1122.34V163.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 165.503V160.815H1132.4V165.503H1131.6ZM1129.66 163.557V162.761H1134.34V163.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 165.503V160.815H1144.4V165.503H1143.6ZM1141.66 163.557V162.761H1146.34V163.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 165.503V160.815H1156.4V165.503H1155.6ZM1153.66 163.557V162.761H1158.34V163.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 177.503V172.815H4.39728V177.503H3.60183ZM1.65581 175.557V174.761H6.34331V175.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 177.503V172.815H16.3973V177.503H15.6018ZM13.6558 175.557V174.761H18.3433V175.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 177.503V172.815H28.3973V177.503H27.6018ZM25.6558 175.557V174.761H30.3433V175.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 177.503V172.815H40.3973V177.503H39.6018ZM37.6558 175.557V174.761H42.3433V175.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 177.503V172.815H52.3973V177.503H51.6018ZM49.6558 175.557V174.761H54.3433V175.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 177.503V172.815H64.3973V177.503H63.6018ZM61.6558 175.557V174.761H66.3433V175.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 177.503V172.815H76.3973V177.503H75.6018ZM73.6558 175.557V174.761H78.3433V175.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 177.503V172.815H88.3973V177.503H87.6018ZM85.6558 175.557V174.761H90.3433V175.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 177.503V172.815H100.397V177.503H99.6018ZM97.6558 175.557V174.761H102.343V175.557H97.6558Z" fill="#01256C"/>
+<path d="M747.602 177.503V172.815H748.397V177.503H747.602ZM745.656 175.557V174.761H750.343V175.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 177.503V172.815H760.397V177.503H759.602ZM757.656 175.557V174.761H762.343V175.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 177.503V172.815H772.397V177.503H771.602ZM769.656 175.557V174.761H774.343V175.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 177.503V172.815H784.397V177.503H783.602ZM781.656 175.557V174.761H786.343V175.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 177.503V172.815H796.397V177.503H795.602ZM793.656 175.557V174.761H798.343V175.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 177.503V172.815H808.397V177.503H807.602ZM805.656 175.557V174.761H810.343V175.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 177.503V172.815H820.397V177.503H819.602ZM817.656 175.557V174.761H822.343V175.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 177.503V172.815H832.397V177.503H831.602ZM829.656 175.557V174.761H834.343V175.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 177.503V172.815H844.397V177.503H843.602ZM841.656 175.557V174.761H846.343V175.557H841.656Z" fill="#01256C"/>
+<path d="M951.602 177.503V172.815H952.397V177.503H951.602ZM949.656 175.557V174.761H954.343V175.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 177.503V172.815H964.397V177.503H963.602ZM961.656 175.557V174.761H966.343V175.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 177.503V172.815H976.397V177.503H975.602ZM973.656 175.557V174.761H978.343V175.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 177.503V172.815H988.397V177.503H987.602ZM985.656 175.557V174.761H990.343V175.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 177.503V172.815H1000.4V177.503H999.602ZM997.656 175.557V174.761H1002.34V175.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 177.503V172.815H1012.4V177.503H1011.6ZM1009.66 175.557V174.761H1014.34V175.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 177.503V172.815H1024.4V177.503H1023.6ZM1021.66 175.557V174.761H1026.34V175.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 177.503V172.815H1036.4V177.503H1035.6ZM1033.66 175.557V174.761H1038.34V175.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 177.503V172.815H1048.4V177.503H1047.6ZM1045.66 175.557V174.761H1050.34V175.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 177.503V172.815H1060.4V177.503H1059.6ZM1057.66 175.557V174.761H1062.34V175.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 177.503V172.815H1072.4V177.503H1071.6ZM1069.66 175.557V174.761H1074.34V175.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 177.503V172.815H1084.4V177.503H1083.6ZM1081.66 175.557V174.761H1086.34V175.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 177.503V172.815H1096.4V177.503H1095.6ZM1093.66 175.557V174.761H1098.34V175.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 177.503V172.815H1108.4V177.503H1107.6ZM1105.66 175.557V174.761H1110.34V175.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 177.503V172.815H1120.4V177.503H1119.6ZM1117.66 175.557V174.761H1122.34V175.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 177.503V172.815H1132.4V177.503H1131.6ZM1129.66 175.557V174.761H1134.34V175.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 177.503V172.815H1144.4V177.503H1143.6ZM1141.66 175.557V174.761H1146.34V175.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 177.503V172.815H1156.4V177.503H1155.6ZM1153.66 175.557V174.761H1158.34V175.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 189.503V184.815H4.39728V189.503H3.60183ZM1.65581 187.557V186.761H6.34331V187.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 189.503V184.815H16.3973V189.503H15.6018ZM13.6558 187.557V186.761H18.3433V187.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 189.503V184.815H28.3973V189.503H27.6018ZM25.6558 187.557V186.761H30.3433V187.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 189.503V184.815H40.3973V189.503H39.6018ZM37.6558 187.557V186.761H42.3433V187.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 189.503V184.815H52.3973V189.503H51.6018ZM49.6558 187.557V186.761H54.3433V187.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 189.503V184.815H64.3973V189.503H63.6018ZM61.6558 187.557V186.761H66.3433V187.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 189.503V184.815H76.3973V189.503H75.6018ZM73.6558 187.557V186.761H78.3433V187.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 189.503V184.815H88.3973V189.503H87.6018ZM85.6558 187.557V186.761H90.3433V187.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 189.503V184.815H100.397V189.503H99.6018ZM97.6558 187.557V186.761H102.343V187.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 189.503V184.815H112.397V189.503H111.602ZM109.656 187.557V186.761H114.343V187.557H109.656Z" fill="#01256C"/>
+<path d="M735.659 186.818L735.716 185.256L734.395 186.094L734.054 185.497L735.446 184.773L734.054 184.048L734.395 183.452L735.716 184.29L735.659 182.727H736.341L736.284 184.29L737.605 183.452L737.946 184.048L736.554 184.773L737.946 185.497L737.605 186.094L736.284 185.256L736.341 186.818H735.659Z" fill="#01256C"/>
+<path d="M747.602 189.503V184.815H748.397V189.503H747.602ZM745.656 187.557V186.761H750.343V187.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 189.503V184.815H760.397V189.503H759.602ZM757.656 187.557V186.761H762.343V187.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 189.503V184.815H772.397V189.503H771.602ZM769.656 187.557V186.761H774.343V187.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 189.503V184.815H784.397V189.503H783.602ZM781.656 187.557V186.761H786.343V187.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 189.503V184.815H796.397V189.503H795.602ZM793.656 187.557V186.761H798.343V187.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 189.503V184.815H808.397V189.503H807.602ZM805.656 187.557V186.761H810.343V187.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 189.503V184.815H820.397V189.503H819.602ZM817.656 187.557V186.761H822.343V187.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 189.503V184.815H832.397V189.503H831.602ZM829.656 187.557V186.761H834.343V187.557H829.656Z" fill="#01256C"/>
+<path d="M939.602 189.503V184.815H940.397V189.503H939.602ZM937.656 187.557V186.761H942.343V187.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 189.503V184.815H952.397V189.503H951.602ZM949.656 187.557V186.761H954.343V187.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 189.503V184.815H964.397V189.503H963.602ZM961.656 187.557V186.761H966.343V187.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 189.503V184.815H976.397V189.503H975.602ZM973.656 187.557V186.761H978.343V187.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 189.503V184.815H988.397V189.503H987.602ZM985.656 187.557V186.761H990.343V187.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 189.503V184.815H1000.4V189.503H999.602ZM997.656 187.557V186.761H1002.34V187.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 189.503V184.815H1012.4V189.503H1011.6ZM1009.66 187.557V186.761H1014.34V187.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 189.503V184.815H1024.4V189.503H1023.6ZM1021.66 187.557V186.761H1026.34V187.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 189.503V184.815H1036.4V189.503H1035.6ZM1033.66 187.557V186.761H1038.34V187.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 189.503V184.815H1048.4V189.503H1047.6ZM1045.66 187.557V186.761H1050.34V187.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 189.503V184.815H1060.4V189.503H1059.6ZM1057.66 187.557V186.761H1062.34V187.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 189.503V184.815H1072.4V189.503H1071.6ZM1069.66 187.557V186.761H1074.34V187.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 189.503V184.815H1084.4V189.503H1083.6ZM1081.66 187.557V186.761H1086.34V187.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 189.503V184.815H1096.4V189.503H1095.6ZM1093.66 187.557V186.761H1098.34V187.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 189.503V184.815H1108.4V189.503H1107.6ZM1105.66 187.557V186.761H1110.34V187.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 189.503V184.815H1120.4V189.503H1119.6ZM1117.66 187.557V186.761H1122.34V187.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 189.503V184.815H1132.4V189.503H1131.6ZM1129.66 187.557V186.761H1134.34V187.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 189.503V184.815H1144.4V189.503H1143.6ZM1141.66 187.557V186.761H1146.34V187.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 189.503V184.815H1156.4V189.503H1155.6ZM1153.66 187.557V186.761H1158.34V187.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 201.503V196.815H4.39728V201.503H3.60183ZM1.65581 199.557V198.761H6.34331V199.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 201.503V196.815H16.3973V201.503H15.6018ZM13.6558 199.557V198.761H18.3433V199.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 201.503V196.815H28.3973V201.503H27.6018ZM25.6558 199.557V198.761H30.3433V199.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 201.503V196.815H40.3973V201.503H39.6018ZM37.6558 199.557V198.761H42.3433V199.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 201.503V196.815H52.3973V201.503H51.6018ZM49.6558 199.557V198.761H54.3433V199.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 201.503V196.815H64.3973V201.503H63.6018ZM61.6558 199.557V198.761H66.3433V199.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 201.503V196.815H76.3973V201.503H75.6018ZM73.6558 199.557V198.761H78.3433V199.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 201.503V196.815H88.3973V201.503H87.6018ZM85.6558 199.557V198.761H90.3433V199.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 201.503V196.815H100.397V201.503H99.6018ZM97.6558 199.557V198.761H102.343V199.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 201.503V196.815H112.397V201.503H111.602ZM109.656 199.557V198.761H114.343V199.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 201.503V196.815H124.397V201.503H123.602ZM121.656 199.557V198.761H126.343V199.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 201.503V196.815H136.397V201.503H135.602ZM133.656 199.557V198.761H138.343V199.557H133.656Z" fill="#01256C"/>
+<path d="M447.602 201.503V196.815H448.397V201.503H447.602ZM445.656 199.557V198.761H450.343V199.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 201.503V196.815H460.397V201.503H459.602ZM457.656 199.557V198.761H462.343V199.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 201.503V196.815H472.397V201.503H471.602ZM469.656 199.557V198.761H474.343V199.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 201.503V196.815H484.397V201.503H483.602ZM481.656 199.557V198.761H486.343V199.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 201.503V196.815H496.397V201.503H495.602ZM493.656 199.557V198.761H498.343V199.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 201.503V196.815H508.397V201.503H507.602ZM505.656 199.557V198.761H510.343V199.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 201.503V196.815H520.397V201.503H519.602ZM517.656 199.557V198.761H522.343V199.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 201.503V196.815H532.397V201.503H531.602ZM529.656 199.557V198.761H534.343V199.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 201.503V196.815H544.397V201.503H543.602ZM541.656 199.557V198.761H546.343V199.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 201.503V196.815H556.397V201.503H555.602ZM553.656 199.557V198.761H558.343V199.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 201.503V196.815H568.397V201.503H567.602ZM565.656 199.557V198.761H570.343V199.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 201.503V196.815H580.397V201.503H579.602ZM577.656 199.557V198.761H582.343V199.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 201.503V196.815H592.397V201.503H591.602ZM589.656 199.557V198.761H594.343V199.557H589.656Z" fill="#01256C"/>
+<path d="M735.602 201.503V196.815H736.397V201.503H735.602ZM733.656 199.557V198.761H738.343V199.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 201.503V196.815H748.397V201.503H747.602ZM745.656 199.557V198.761H750.343V199.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 201.503V196.815H760.397V201.503H759.602ZM757.656 199.557V198.761H762.343V199.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 201.503V196.815H772.397V201.503H771.602ZM769.656 199.557V198.761H774.343V199.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 201.503V196.815H784.397V201.503H783.602ZM781.656 199.557V198.761H786.343V199.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 201.503V196.815H796.397V201.503H795.602ZM793.656 199.557V198.761H798.343V199.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 201.503V196.815H808.397V201.503H807.602ZM805.656 199.557V198.761H810.343V199.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 201.503V196.815H820.397V201.503H819.602ZM817.656 199.557V198.761H822.343V199.557H817.656Z" fill="#01256C"/>
+<path d="M927.602 201.503V196.815H928.397V201.503H927.602ZM925.656 199.557V198.761H930.343V199.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 201.503V196.815H940.397V201.503H939.602ZM937.656 199.557V198.761H942.343V199.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 201.503V196.815H952.397V201.503H951.602ZM949.656 199.557V198.761H954.343V199.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 201.503V196.815H964.397V201.503H963.602ZM961.656 199.557V198.761H966.343V199.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 201.503V196.815H976.397V201.503H975.602ZM973.656 199.557V198.761H978.343V199.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 201.503V196.815H988.397V201.503H987.602ZM985.656 199.557V198.761H990.343V199.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 201.503V196.815H1000.4V201.503H999.602ZM997.656 199.557V198.761H1002.34V199.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 201.503V196.815H1012.4V201.503H1011.6ZM1009.66 199.557V198.761H1014.34V199.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 201.503V196.815H1024.4V201.503H1023.6ZM1021.66 199.557V198.761H1026.34V199.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 201.503V196.815H1036.4V201.503H1035.6ZM1033.66 199.557V198.761H1038.34V199.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 201.503V196.815H1048.4V201.503H1047.6ZM1045.66 199.557V198.761H1050.34V199.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 201.503V196.815H1060.4V201.503H1059.6ZM1057.66 199.557V198.761H1062.34V199.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 201.503V196.815H1072.4V201.503H1071.6ZM1069.66 199.557V198.761H1074.34V199.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 201.503V196.815H1084.4V201.503H1083.6ZM1081.66 199.557V198.761H1086.34V199.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 201.503V196.815H1096.4V201.503H1095.6ZM1093.66 199.557V198.761H1098.34V199.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 201.503V196.815H1108.4V201.503H1107.6ZM1105.66 199.557V198.761H1110.34V199.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 201.503V196.815H1120.4V201.503H1119.6ZM1117.66 199.557V198.761H1122.34V199.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 201.503V196.815H1132.4V201.503H1131.6ZM1129.66 199.557V198.761H1134.34V199.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 201.503V196.815H1144.4V201.503H1143.6ZM1141.66 199.557V198.761H1146.34V199.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 201.503V196.815H1156.4V201.503H1155.6ZM1153.66 199.557V198.761H1158.34V199.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 213.503V208.815H4.39728V213.503H3.60183ZM1.65581 211.557V210.761H6.34331V211.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 213.503V208.815H16.3973V213.503H15.6018ZM13.6558 211.557V210.761H18.3433V211.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 213.503V208.815H28.3973V213.503H27.6018ZM25.6558 211.557V210.761H30.3433V211.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 213.503V208.815H40.3973V213.503H39.6018ZM37.6558 211.557V210.761H42.3433V211.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 213.503V208.815H52.3973V213.503H51.6018ZM49.6558 211.557V210.761H54.3433V211.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 213.503V208.815H64.3973V213.503H63.6018ZM61.6558 211.557V210.761H66.3433V211.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 213.503V208.815H76.3973V213.503H75.6018ZM73.6558 211.557V210.761H78.3433V211.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 213.503V208.815H88.3973V213.503H87.6018ZM85.6558 211.557V210.761H90.3433V211.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 213.503V208.815H100.397V213.503H99.6018ZM97.6558 211.557V210.761H102.343V211.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 213.503V208.815H112.397V213.503H111.602ZM109.656 211.557V210.761H114.343V211.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 213.503V208.815H124.397V213.503H123.602ZM121.656 211.557V210.761H126.343V211.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 213.503V208.815H136.397V213.503H135.602ZM133.656 211.557V210.761H138.343V211.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 213.503V208.815H148.397V213.503H147.602ZM145.656 211.557V210.761H150.343V211.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 213.503V208.815H160.397V213.503H159.602ZM157.656 211.557V210.761H162.343V211.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 213.503V208.815H172.397V213.503H171.602ZM169.656 211.557V210.761H174.343V211.557H169.656Z" fill="#01256C"/>
+<path d="M376.616 213.006L376.559 213.389C376.519 213.659 376.457 213.948 376.374 214.256C376.294 214.563 376.21 214.853 376.122 215.126C376.034 215.398 375.962 215.615 375.905 215.776H375.266C375.297 215.624 375.337 215.424 375.387 215.175C375.437 214.927 375.486 214.649 375.536 214.341C375.588 214.036 375.631 213.723 375.664 213.403L375.707 213.006H376.616ZM376.104 210.009C375.929 210.009 375.779 209.946 375.653 209.82C375.528 209.695 375.465 209.545 375.465 209.369C375.465 209.194 375.528 209.044 375.653 208.918C375.779 208.793 375.929 208.73 376.104 208.73C376.28 208.73 376.43 208.793 376.555 208.918C376.681 209.044 376.744 209.194 376.744 209.369C376.744 209.485 376.714 209.592 376.655 209.689C376.598 209.786 376.521 209.864 376.424 209.923C376.329 209.98 376.223 210.009 376.104 210.009Z" fill="#01256C"/>
+<path d="M387.602 213.503V208.815H388.397V213.503H387.602ZM385.656 211.557V210.761H390.343V211.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 213.503V208.815H400.397V213.503H399.602ZM397.656 211.557V210.761H402.343V211.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 213.503V208.815H412.397V213.503H411.602ZM409.656 211.557V210.761H414.343V211.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 213.503V208.815H424.397V213.503H423.602ZM421.656 211.557V210.761H426.343V211.557H421.656Z" fill="#01256C"/>
+<path d="M435.602 213.503V208.815H436.397V213.503H435.602ZM433.656 211.557V210.761H438.343V211.557H433.656Z" fill="#01256C"/>
+<path d="M447.602 213.503V208.815H448.397V213.503H447.602ZM445.656 211.557V210.761H450.343V211.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 213.503V208.815H460.397V213.503H459.602ZM457.656 211.557V210.761H462.343V211.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 213.503V208.815H472.397V213.503H471.602ZM469.656 211.557V210.761H474.343V211.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 213.503V208.815H484.397V213.503H483.602ZM481.656 211.557V210.761H486.343V211.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 213.503V208.815H496.397V213.503H495.602ZM493.656 211.557V210.761H498.343V211.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 213.503V208.815H508.397V213.503H507.602ZM505.656 211.557V210.761H510.343V211.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 213.503V208.815H520.397V213.503H519.602ZM517.656 211.557V210.761H522.343V211.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 213.503V208.815H532.397V213.503H531.602ZM529.656 211.557V210.761H534.343V211.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 213.503V208.815H544.397V213.503H543.602ZM541.656 211.557V210.761H546.343V211.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 213.503V208.815H556.397V213.503H555.602ZM553.656 211.557V210.761H558.343V211.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 213.503V208.815H568.397V213.503H567.602ZM565.656 211.557V210.761H570.343V211.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 213.503V208.815H580.397V213.503H579.602ZM577.656 211.557V210.761H582.343V211.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 213.503V208.815H592.397V213.503H591.602ZM589.656 211.557V210.761H594.343V211.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 213.503V208.815H604.397V213.503H603.602ZM601.656 211.557V210.761H606.343V211.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 213.503V208.815H616.397V213.503H615.602ZM613.656 211.557V210.761H618.343V211.557H613.656Z" fill="#01256C"/>
+<path d="M735.602 213.503V208.815H736.397V213.503H735.602ZM733.656 211.557V210.761H738.343V211.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 213.503V208.815H748.397V213.503H747.602ZM745.656 211.557V210.761H750.343V211.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 213.503V208.815H760.397V213.503H759.602ZM757.656 211.557V210.761H762.343V211.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 213.503V208.815H772.397V213.503H771.602ZM769.656 211.557V210.761H774.343V211.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 213.503V208.815H784.397V213.503H783.602ZM781.656 211.557V210.761H786.343V211.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 213.503V208.815H796.397V213.503H795.602ZM793.656 211.557V210.761H798.343V211.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 213.503V208.815H808.397V213.503H807.602ZM805.656 211.557V210.761H810.343V211.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 213.503V208.815H820.397V213.503H819.602ZM817.656 211.557V210.761H822.343V211.557H817.656Z" fill="#01256C"/>
+<path d="M927.602 213.503V208.815H928.397V213.503H927.602ZM925.656 211.557V210.761H930.343V211.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 213.503V208.815H940.397V213.503H939.602ZM937.656 211.557V210.761H942.343V211.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 213.503V208.815H952.397V213.503H951.602ZM949.656 211.557V210.761H954.343V211.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 213.503V208.815H964.397V213.503H963.602ZM961.656 211.557V210.761H966.343V211.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 213.503V208.815H976.397V213.503H975.602ZM973.656 211.557V210.761H978.343V211.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 213.503V208.815H988.397V213.503H987.602ZM985.656 211.557V210.761H990.343V211.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 213.503V208.815H1000.4V213.503H999.602ZM997.656 211.557V210.761H1002.34V211.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 213.503V208.815H1012.4V213.503H1011.6ZM1009.66 211.557V210.761H1014.34V211.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 213.503V208.815H1024.4V213.503H1023.6ZM1021.66 211.557V210.761H1026.34V211.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 213.503V208.815H1036.4V213.503H1035.6ZM1033.66 211.557V210.761H1038.34V211.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 213.503V208.815H1048.4V213.503H1047.6ZM1045.66 211.557V210.761H1050.34V211.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 213.503V208.815H1060.4V213.503H1059.6ZM1057.66 211.557V210.761H1062.34V211.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 213.503V208.815H1072.4V213.503H1071.6ZM1069.66 211.557V210.761H1074.34V211.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 213.503V208.815H1084.4V213.503H1083.6ZM1081.66 211.557V210.761H1086.34V211.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 213.503V208.815H1096.4V213.503H1095.6ZM1093.66 211.557V210.761H1098.34V211.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 213.503V208.815H1108.4V213.503H1107.6ZM1105.66 211.557V210.761H1110.34V211.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 213.503V208.815H1120.4V213.503H1119.6ZM1117.66 211.557V210.761H1122.34V211.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 213.503V208.815H1132.4V213.503H1131.6ZM1129.66 211.557V210.761H1134.34V211.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 213.503V208.815H1144.4V213.503H1143.6ZM1141.66 211.557V210.761H1146.34V211.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 213.503V208.815H1156.4V213.503H1155.6ZM1153.66 211.557V210.761H1158.34V211.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 225.503V220.815H4.39728V225.503H3.60183ZM1.65581 223.557V222.761H6.34331V223.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 225.503V220.815H16.3973V225.503H15.6018ZM13.6558 223.557V222.761H18.3433V223.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 225.503V220.815H28.3973V225.503H27.6018ZM25.6558 223.557V222.761H30.3433V223.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 225.503V220.815H40.3973V225.503H39.6018ZM37.6558 223.557V222.761H42.3433V223.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 225.503V220.815H52.3973V225.503H51.6018ZM49.6558 223.557V222.761H54.3433V223.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 225.503V220.815H64.3973V225.503H63.6018ZM61.6558 223.557V222.761H66.3433V223.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 225.503V220.815H76.3973V225.503H75.6018ZM73.6558 223.557V222.761H78.3433V223.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 225.503V220.815H88.3973V225.503H87.6018ZM85.6558 223.557V222.761H90.3433V223.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 225.503V220.815H100.397V225.503H99.6018ZM97.6558 223.557V222.761H102.343V223.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 225.503V220.815H112.397V225.503H111.602ZM109.656 223.557V222.761H114.343V223.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 225.503V220.815H124.397V225.503H123.602ZM121.656 223.557V222.761H126.343V223.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 225.503V220.815H136.397V225.503H135.602ZM133.656 223.557V222.761H138.343V223.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 225.503V220.815H148.397V225.503H147.602ZM145.656 223.557V222.761H150.343V223.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 225.503V220.815H160.397V225.503H159.602ZM157.656 223.557V222.761H162.343V223.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 225.503V220.815H172.397V225.503H171.602ZM169.656 223.557V222.761H174.343V223.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 225.503V220.815H184.397V225.503H183.602ZM181.656 223.557V222.761H186.343V223.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 225.503V220.815H196.397V225.503H195.602ZM193.656 223.557V222.761H198.343V223.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 225.503V220.815H208.397V225.503H207.602ZM205.656 223.557V222.761H210.343V223.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 225.503V220.815H220.397V225.503H219.602ZM217.656 223.557V222.761H222.343V223.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 225.503V220.815H232.397V225.503H231.602ZM229.656 223.557V222.761H234.343V223.557H229.656Z" fill="#01256C"/>
+<path d="M291.602 225.503V220.815H292.397V225.503H291.602ZM289.656 223.557V222.761H294.343V223.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 225.503V220.815H304.397V225.503H303.602ZM301.656 223.557V222.761H306.343V223.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 225.503V220.815H316.397V225.503H315.602ZM313.656 223.557V222.761H318.343V223.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 225.503V220.815H328.397V225.503H327.602ZM325.656 223.557V222.761H330.343V223.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 225.503V220.815H340.397V225.503H339.602ZM337.656 223.557V222.761H342.343V223.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 225.503V220.815H352.397V225.503H351.602ZM349.656 223.557V222.761H354.343V223.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 225.503V220.815H364.397V225.503H363.602ZM361.656 223.557V222.761H366.343V223.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 225.503V220.815H376.397V225.503H375.602ZM373.656 223.557V222.761H378.343V223.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 225.503V220.815H388.397V225.503H387.602ZM385.656 223.557V222.761H390.343V223.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 225.503V220.815H400.397V225.503H399.602ZM397.656 223.557V222.761H402.343V223.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 225.503V220.815H412.397V225.503H411.602ZM409.656 223.557V222.761H414.343V223.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 225.503V220.815H424.397V225.503H423.602ZM421.656 223.557V222.761H426.343V223.557H421.656Z" fill="#01256C"/>
+<path d="M435.602 225.503V220.815H436.397V225.503H435.602ZM433.656 223.557V222.761H438.343V223.557H433.656Z" fill="#01256C"/>
+<path d="M447.602 225.503V220.815H448.397V225.503H447.602ZM445.656 223.557V222.761H450.343V223.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 225.503V220.815H460.397V225.503H459.602ZM457.656 223.557V222.761H462.343V223.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 225.503V220.815H472.397V225.503H471.602ZM469.656 223.557V222.761H474.343V223.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 225.503V220.815H484.397V225.503H483.602ZM481.656 223.557V222.761H486.343V223.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 225.503V220.815H496.397V225.503H495.602ZM493.656 223.557V222.761H498.343V223.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 225.503V220.815H508.397V225.503H507.602ZM505.656 223.557V222.761H510.343V223.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 225.503V220.815H520.397V225.503H519.602ZM517.656 223.557V222.761H522.343V223.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 225.503V220.815H532.397V225.503H531.602ZM529.656 223.557V222.761H534.343V223.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 225.503V220.815H544.397V225.503H543.602ZM541.656 223.557V222.761H546.343V223.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 225.503V220.815H556.397V225.503H555.602ZM553.656 223.557V222.761H558.343V223.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 225.503V220.815H568.397V225.503H567.602ZM565.656 223.557V222.761H570.343V223.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 225.503V220.815H580.397V225.503H579.602ZM577.656 223.557V222.761H582.343V223.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 225.503V220.815H592.397V225.503H591.602ZM589.656 223.557V222.761H594.343V223.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 225.503V220.815H604.397V225.503H603.602ZM601.656 223.557V222.761H606.343V223.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 225.503V220.815H616.397V225.503H615.602ZM613.656 223.557V222.761H618.343V223.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 225.503V220.815H628.397V225.503H627.602ZM625.656 223.557V222.761H630.343V223.557H625.656Z" fill="#01256C"/>
+<path d="M735.602 225.503V220.815H736.397V225.503H735.602ZM733.656 223.557V222.761H738.343V223.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 225.503V220.815H748.397V225.503H747.602ZM745.656 223.557V222.761H750.343V223.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 225.503V220.815H760.397V225.503H759.602ZM757.656 223.557V222.761H762.343V223.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 225.503V220.815H772.397V225.503H771.602ZM769.656 223.557V222.761H774.343V223.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 225.503V220.815H784.397V225.503H783.602ZM781.656 223.557V222.761H786.343V223.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 225.503V220.815H796.397V225.503H795.602ZM793.656 223.557V222.761H798.343V223.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 225.503V220.815H808.397V225.503H807.602ZM805.656 223.557V222.761H810.343V223.557H805.656Z" fill="#01256C"/>
+<path d="M915.602 225.503V220.815H916.397V225.503H915.602ZM913.656 223.557V222.761H918.343V223.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 225.503V220.815H928.397V225.503H927.602ZM925.656 223.557V222.761H930.343V223.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 225.503V220.815H940.397V225.503H939.602ZM937.656 223.557V222.761H942.343V223.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 225.503V220.815H952.397V225.503H951.602ZM949.656 223.557V222.761H954.343V223.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 225.503V220.815H964.397V225.503H963.602ZM961.656 223.557V222.761H966.343V223.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 225.503V220.815H976.397V225.503H975.602ZM973.656 223.557V222.761H978.343V223.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 225.503V220.815H988.397V225.503H987.602ZM985.656 223.557V222.761H990.343V223.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 225.503V220.815H1000.4V225.503H999.602ZM997.656 223.557V222.761H1002.34V223.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 225.503V220.815H1012.4V225.503H1011.6ZM1009.66 223.557V222.761H1014.34V223.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 225.503V220.815H1024.4V225.503H1023.6ZM1021.66 223.557V222.761H1026.34V223.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 225.503V220.815H1036.4V225.503H1035.6ZM1033.66 223.557V222.761H1038.34V223.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 225.503V220.815H1048.4V225.503H1047.6ZM1045.66 223.557V222.761H1050.34V223.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 225.503V220.815H1060.4V225.503H1059.6ZM1057.66 223.557V222.761H1062.34V223.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 225.503V220.815H1072.4V225.503H1071.6ZM1069.66 223.557V222.761H1074.34V223.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 225.503V220.815H1084.4V225.503H1083.6ZM1081.66 223.557V222.761H1086.34V223.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 225.503V220.815H1096.4V225.503H1095.6ZM1093.66 223.557V222.761H1098.34V223.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 225.503V220.815H1108.4V225.503H1107.6ZM1105.66 223.557V222.761H1110.34V223.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 225.503V220.815H1120.4V225.503H1119.6ZM1117.66 223.557V222.761H1122.34V223.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 225.503V220.815H1132.4V225.503H1131.6ZM1129.66 223.557V222.761H1134.34V223.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 225.503V220.815H1144.4V225.503H1143.6ZM1141.66 223.557V222.761H1146.34V223.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 225.503V220.815H1156.4V225.503H1155.6ZM1153.66 223.557V222.761H1158.34V223.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 237.503V232.815H4.39728V237.503H3.60183ZM1.65581 235.557V234.761H6.34331V235.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 237.503V232.815H16.3973V237.503H15.6018ZM13.6558 235.557V234.761H18.3433V235.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 237.503V232.815H28.3973V237.503H27.6018ZM25.6558 235.557V234.761H30.3433V235.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 237.503V232.815H40.3973V237.503H39.6018ZM37.6558 235.557V234.761H42.3433V235.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 237.503V232.815H52.3973V237.503H51.6018ZM49.6558 235.557V234.761H54.3433V235.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 237.503V232.815H64.3973V237.503H63.6018ZM61.6558 235.557V234.761H66.3433V235.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 237.503V232.815H76.3973V237.503H75.6018ZM73.6558 235.557V234.761H78.3433V235.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 237.503V232.815H88.3973V237.503H87.6018ZM85.6558 235.557V234.761H90.3433V235.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 237.503V232.815H100.397V237.503H99.6018ZM97.6558 235.557V234.761H102.343V235.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 237.503V232.815H112.397V237.503H111.602ZM109.656 235.557V234.761H114.343V235.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 237.503V232.815H124.397V237.503H123.602ZM121.656 235.557V234.761H126.343V235.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 237.503V232.815H136.397V237.503H135.602ZM133.656 235.557V234.761H138.343V235.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 237.503V232.815H148.397V237.503H147.602ZM145.656 235.557V234.761H150.343V235.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 237.503V232.815H160.397V237.503H159.602ZM157.656 235.557V234.761H162.343V235.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 237.503V232.815H172.397V237.503H171.602ZM169.656 235.557V234.761H174.343V235.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 237.503V232.815H184.397V237.503H183.602ZM181.656 235.557V234.761H186.343V235.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 237.503V232.815H196.397V237.503H195.602ZM193.656 235.557V234.761H198.343V235.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 237.503V232.815H208.397V237.503H207.602ZM205.656 235.557V234.761H210.343V235.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 237.503V232.815H220.397V237.503H219.602ZM217.656 235.557V234.761H222.343V235.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 237.503V232.815H232.397V237.503H231.602ZM229.656 235.557V234.761H234.343V235.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 237.503V232.815H244.397V237.503H243.602ZM241.656 235.557V234.761H246.343V235.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 237.503V232.815H256.397V237.503H255.602ZM253.656 235.557V234.761H258.343V235.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 237.503V232.815H268.397V237.503H267.602ZM265.656 235.557V234.761H270.343V235.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 237.503V232.815H280.397V237.503H279.602ZM277.656 235.557V234.761H282.343V235.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 237.503V232.815H292.397V237.503H291.602ZM289.656 235.557V234.761H294.343V235.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 237.503V232.815H304.397V237.503H303.602ZM301.656 235.557V234.761H306.343V235.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 237.503V232.815H316.397V237.503H315.602ZM313.656 235.557V234.761H318.343V235.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 237.503V232.815H328.397V237.503H327.602ZM325.656 235.557V234.761H330.343V235.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 237.503V232.815H340.397V237.503H339.602ZM337.656 235.557V234.761H342.343V235.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 237.503V232.815H352.397V237.503H351.602ZM349.656 235.557V234.761H354.343V235.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 237.503V232.815H364.397V237.503H363.602ZM361.656 235.557V234.761H366.343V235.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 237.503V232.815H376.397V237.503H375.602ZM373.656 235.557V234.761H378.343V235.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 237.503V232.815H388.397V237.503H387.602ZM385.656 235.557V234.761H390.343V235.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 237.503V232.815H400.397V237.503H399.602ZM397.656 235.557V234.761H402.343V235.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 237.503V232.815H412.397V237.503H411.602ZM409.656 235.557V234.761H414.343V235.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 237.503V232.815H424.397V237.503H423.602ZM421.656 235.557V234.761H426.343V235.557H421.656Z" fill="#01256C"/>
+<path d="M435.602 237.503V232.815H436.397V237.503H435.602ZM433.656 235.557V234.761H438.343V235.557H433.656Z" fill="#01256C"/>
+<path d="M447.602 237.503V232.815H448.397V237.503H447.602ZM445.656 235.557V234.761H450.343V235.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 237.503V232.815H460.397V237.503H459.602ZM457.656 235.557V234.761H462.343V235.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 237.503V232.815H472.397V237.503H471.602ZM469.656 235.557V234.761H474.343V235.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 237.503V232.815H484.397V237.503H483.602ZM481.656 235.557V234.761H486.343V235.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 237.503V232.815H496.397V237.503H495.602ZM493.656 235.557V234.761H498.343V235.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 237.503V232.815H508.397V237.503H507.602ZM505.656 235.557V234.761H510.343V235.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 237.503V232.815H520.397V237.503H519.602ZM517.656 235.557V234.761H522.343V235.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 237.503V232.815H532.397V237.503H531.602ZM529.656 235.557V234.761H534.343V235.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 237.503V232.815H544.397V237.503H543.602ZM541.656 235.557V234.761H546.343V235.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 237.503V232.815H556.397V237.503H555.602ZM553.656 235.557V234.761H558.343V235.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 237.503V232.815H568.397V237.503H567.602ZM565.656 235.557V234.761H570.343V235.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 237.503V232.815H580.397V237.503H579.602ZM577.656 235.557V234.761H582.343V235.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 237.503V232.815H592.397V237.503H591.602ZM589.656 235.557V234.761H594.343V235.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 237.503V232.815H604.397V237.503H603.602ZM601.656 235.557V234.761H606.343V235.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 237.503V232.815H616.397V237.503H615.602ZM613.656 235.557V234.761H618.343V235.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 237.503V232.815H628.397V237.503H627.602ZM625.656 235.557V234.761H630.343V235.557H625.656Z" fill="#01256C"/>
+<path d="M639.602 237.503V232.815H640.397V237.503H639.602ZM637.656 235.557V234.761H642.343V235.557H637.656Z" fill="#01256C"/>
+<path d="M735.602 237.503V232.815H736.397V237.503H735.602ZM733.656 235.557V234.761H738.343V235.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 237.503V232.815H748.397V237.503H747.602ZM745.656 235.557V234.761H750.343V235.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 237.503V232.815H760.397V237.503H759.602ZM757.656 235.557V234.761H762.343V235.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 237.503V232.815H772.397V237.503H771.602ZM769.656 235.557V234.761H774.343V235.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 237.503V232.815H784.397V237.503H783.602ZM781.656 235.557V234.761H786.343V235.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 237.503V232.815H796.397V237.503H795.602ZM793.656 235.557V234.761H798.343V235.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 237.503V232.815H808.397V237.503H807.602ZM805.656 235.557V234.761H810.343V235.557H805.656Z" fill="#01256C"/>
+<path d="M915.602 237.503V232.815H916.397V237.503H915.602ZM913.656 235.557V234.761H918.343V235.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 237.503V232.815H928.397V237.503H927.602ZM925.656 235.557V234.761H930.343V235.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 237.503V232.815H940.397V237.503H939.602ZM937.656 235.557V234.761H942.343V235.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 237.503V232.815H952.397V237.503H951.602ZM949.656 235.557V234.761H954.343V235.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 237.503V232.815H964.397V237.503H963.602ZM961.656 235.557V234.761H966.343V235.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 237.503V232.815H976.397V237.503H975.602ZM973.656 235.557V234.761H978.343V235.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 237.503V232.815H988.397V237.503H987.602ZM985.656 235.557V234.761H990.343V235.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 237.503V232.815H1000.4V237.503H999.602ZM997.656 235.557V234.761H1002.34V235.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 237.503V232.815H1012.4V237.503H1011.6ZM1009.66 235.557V234.761H1014.34V235.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 237.503V232.815H1024.4V237.503H1023.6ZM1021.66 235.557V234.761H1026.34V235.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 237.503V232.815H1036.4V237.503H1035.6ZM1033.66 235.557V234.761H1038.34V235.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 237.503V232.815H1048.4V237.503H1047.6ZM1045.66 235.557V234.761H1050.34V235.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 237.503V232.815H1060.4V237.503H1059.6ZM1057.66 235.557V234.761H1062.34V235.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 237.503V232.815H1072.4V237.503H1071.6ZM1069.66 235.557V234.761H1074.34V235.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 237.503V232.815H1084.4V237.503H1083.6ZM1081.66 235.557V234.761H1086.34V235.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 237.503V232.815H1096.4V237.503H1095.6ZM1093.66 235.557V234.761H1098.34V235.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 237.503V232.815H1108.4V237.503H1107.6ZM1105.66 235.557V234.761H1110.34V235.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 237.503V232.815H1120.4V237.503H1119.6ZM1117.66 235.557V234.761H1122.34V235.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 237.503V232.815H1132.4V237.503H1131.6ZM1129.66 235.557V234.761H1134.34V235.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 237.503V232.815H1144.4V237.503H1143.6ZM1141.66 235.557V234.761H1146.34V235.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 237.503V232.815H1156.4V237.503H1155.6ZM1153.66 235.557V234.761H1158.34V235.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 249.503V244.815H4.39728V249.503H3.60183ZM1.65581 247.557V246.761H6.34331V247.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 249.503V244.815H16.3973V249.503H15.6018ZM13.6558 247.557V246.761H18.3433V247.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 249.503V244.815H28.3973V249.503H27.6018ZM25.6558 247.557V246.761H30.3433V247.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 249.503V244.815H40.3973V249.503H39.6018ZM37.6558 247.557V246.761H42.3433V247.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 249.503V244.815H52.3973V249.503H51.6018ZM49.6558 247.557V246.761H54.3433V247.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 249.503V244.815H64.3973V249.503H63.6018ZM61.6558 247.557V246.761H66.3433V247.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 249.503V244.815H76.3973V249.503H75.6018ZM73.6558 247.557V246.761H78.3433V247.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 249.503V244.815H88.3973V249.503H87.6018ZM85.6558 247.557V246.761H90.3433V247.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 249.503V244.815H100.397V249.503H99.6018ZM97.6558 247.557V246.761H102.343V247.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 249.503V244.815H112.397V249.503H111.602ZM109.656 247.557V246.761H114.343V247.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 249.503V244.815H124.397V249.503H123.602ZM121.656 247.557V246.761H126.343V247.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 249.503V244.815H136.397V249.503H135.602ZM133.656 247.557V246.761H138.343V247.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 249.503V244.815H148.397V249.503H147.602ZM145.656 247.557V246.761H150.343V247.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 249.503V244.815H160.397V249.503H159.602ZM157.656 247.557V246.761H162.343V247.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 249.503V244.815H172.397V249.503H171.602ZM169.656 247.557V246.761H174.343V247.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 249.503V244.815H184.397V249.503H183.602ZM181.656 247.557V246.761H186.343V247.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 249.503V244.815H196.397V249.503H195.602ZM193.656 247.557V246.761H198.343V247.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 249.503V244.815H208.397V249.503H207.602ZM205.656 247.557V246.761H210.343V247.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 249.503V244.815H220.397V249.503H219.602ZM217.656 247.557V246.761H222.343V247.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 249.503V244.815H232.397V249.503H231.602ZM229.656 247.557V246.761H234.343V247.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 249.503V244.815H244.397V249.503H243.602ZM241.656 247.557V246.761H246.343V247.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 249.503V244.815H256.397V249.503H255.602ZM253.656 247.557V246.761H258.343V247.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 249.503V244.815H268.397V249.503H267.602ZM265.656 247.557V246.761H270.343V247.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 249.503V244.815H280.397V249.503H279.602ZM277.656 247.557V246.761H282.343V247.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 249.503V244.815H292.397V249.503H291.602ZM289.656 247.557V246.761H294.343V247.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 249.503V244.815H304.397V249.503H303.602ZM301.656 247.557V246.761H306.343V247.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 249.503V244.815H316.397V249.503H315.602ZM313.656 247.557V246.761H318.343V247.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 249.503V244.815H328.397V249.503H327.602ZM325.656 247.557V246.761H330.343V247.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 249.503V244.815H340.397V249.503H339.602ZM337.656 247.557V246.761H342.343V247.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 249.503V244.815H352.397V249.503H351.602ZM349.656 247.557V246.761H354.343V247.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 249.503V244.815H364.397V249.503H363.602ZM361.656 247.557V246.761H366.343V247.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 249.503V244.815H376.397V249.503H375.602ZM373.656 247.557V246.761H378.343V247.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 249.503V244.815H388.397V249.503H387.602ZM385.656 247.557V246.761H390.343V247.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 249.503V244.815H400.397V249.503H399.602ZM397.656 247.557V246.761H402.343V247.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 249.503V244.815H412.397V249.503H411.602ZM409.656 247.557V246.761H414.343V247.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 249.503V244.815H424.397V249.503H423.602ZM421.656 247.557V246.761H426.343V247.557H421.656Z" fill="#01256C"/>
+<path d="M435.602 249.503V244.815H436.397V249.503H435.602ZM433.656 247.557V246.761H438.343V247.557H433.656Z" fill="#01256C"/>
+<path d="M447.602 249.503V244.815H448.397V249.503H447.602ZM445.656 247.557V246.761H450.343V247.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 249.503V244.815H460.397V249.503H459.602ZM457.656 247.557V246.761H462.343V247.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 249.503V244.815H472.397V249.503H471.602ZM469.656 247.557V246.761H474.343V247.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 249.503V244.815H484.397V249.503H483.602ZM481.656 247.557V246.761H486.343V247.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 249.503V244.815H496.397V249.503H495.602ZM493.656 247.557V246.761H498.343V247.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 249.503V244.815H508.397V249.503H507.602ZM505.656 247.557V246.761H510.343V247.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 249.503V244.815H520.397V249.503H519.602ZM517.656 247.557V246.761H522.343V247.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 249.503V244.815H532.397V249.503H531.602ZM529.656 247.557V246.761H534.343V247.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 249.503V244.815H544.397V249.503H543.602ZM541.656 247.557V246.761H546.343V247.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 249.503V244.815H556.397V249.503H555.602ZM553.656 247.557V246.761H558.343V247.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 249.503V244.815H568.397V249.503H567.602ZM565.656 247.557V246.761H570.343V247.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 249.503V244.815H580.397V249.503H579.602ZM577.656 247.557V246.761H582.343V247.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 249.503V244.815H592.397V249.503H591.602ZM589.656 247.557V246.761H594.343V247.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 249.503V244.815H604.397V249.503H603.602ZM601.656 247.557V246.761H606.343V247.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 249.503V244.815H616.397V249.503H615.602ZM613.656 247.557V246.761H618.343V247.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 249.503V244.815H628.397V249.503H627.602ZM625.656 247.557V246.761H630.343V247.557H625.656Z" fill="#01256C"/>
+<path d="M639.602 249.503V244.815H640.397V249.503H639.602ZM637.656 247.557V246.761H642.343V247.557H637.656Z" fill="#01256C"/>
+<path d="M723.602 249.503V244.815H724.397V249.503H723.602ZM721.656 247.557V246.761H726.343V247.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 249.503V244.815H736.397V249.503H735.602ZM733.656 247.557V246.761H738.343V247.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 249.503V244.815H748.397V249.503H747.602ZM745.656 247.557V246.761H750.343V247.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 249.503V244.815H760.397V249.503H759.602ZM757.656 247.557V246.761H762.343V247.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 249.503V244.815H772.397V249.503H771.602ZM769.656 247.557V246.761H774.343V247.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 249.503V244.815H784.397V249.503H783.602ZM781.656 247.557V246.761H786.343V247.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 249.503V244.815H796.397V249.503H795.602ZM793.656 247.557V246.761H798.343V247.557H793.656Z" fill="#01256C"/>
+<path d="M915.602 249.503V244.815H916.397V249.503H915.602ZM913.656 247.557V246.761H918.343V247.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 249.503V244.815H928.397V249.503H927.602ZM925.656 247.557V246.761H930.343V247.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 249.503V244.815H940.397V249.503H939.602ZM937.656 247.557V246.761H942.343V247.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 249.503V244.815H952.397V249.503H951.602ZM949.656 247.557V246.761H954.343V247.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 249.503V244.815H964.397V249.503H963.602ZM961.656 247.557V246.761H966.343V247.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 249.503V244.815H976.397V249.503H975.602ZM973.656 247.557V246.761H978.343V247.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 249.503V244.815H988.397V249.503H987.602ZM985.656 247.557V246.761H990.343V247.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 249.503V244.815H1000.4V249.503H999.602ZM997.656 247.557V246.761H1002.34V247.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 249.503V244.815H1012.4V249.503H1011.6ZM1009.66 247.557V246.761H1014.34V247.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 249.503V244.815H1024.4V249.503H1023.6ZM1021.66 247.557V246.761H1026.34V247.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 249.503V244.815H1036.4V249.503H1035.6ZM1033.66 247.557V246.761H1038.34V247.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 249.503V244.815H1048.4V249.503H1047.6ZM1045.66 247.557V246.761H1050.34V247.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 249.503V244.815H1060.4V249.503H1059.6ZM1057.66 247.557V246.761H1062.34V247.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 249.503V244.815H1072.4V249.503H1071.6ZM1069.66 247.557V246.761H1074.34V247.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 249.503V244.815H1084.4V249.503H1083.6ZM1081.66 247.557V246.761H1086.34V247.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 249.503V244.815H1096.4V249.503H1095.6ZM1093.66 247.557V246.761H1098.34V247.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 249.503V244.815H1108.4V249.503H1107.6ZM1105.66 247.557V246.761H1110.34V247.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 249.503V244.815H1120.4V249.503H1119.6ZM1117.66 247.557V246.761H1122.34V247.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 249.503V244.815H1132.4V249.503H1131.6ZM1129.66 247.557V246.761H1134.34V247.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 249.503V244.815H1144.4V249.503H1143.6ZM1141.66 247.557V246.761H1146.34V247.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 249.503V244.815H1156.4V249.503H1155.6ZM1153.66 247.557V246.761H1158.34V247.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 261.503V256.815H4.39728V261.503H3.60183ZM1.65581 259.557V258.761H6.34331V259.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 261.503V256.815H16.3973V261.503H15.6018ZM13.6558 259.557V258.761H18.3433V259.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 261.503V256.815H28.3973V261.503H27.6018ZM25.6558 259.557V258.761H30.3433V259.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 261.503V256.815H40.3973V261.503H39.6018ZM37.6558 259.557V258.761H42.3433V259.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 261.503V256.815H52.3973V261.503H51.6018ZM49.6558 259.557V258.761H54.3433V259.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 261.503V256.815H64.3973V261.503H63.6018ZM61.6558 259.557V258.761H66.3433V259.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 261.503V256.815H76.3973V261.503H75.6018ZM73.6558 259.557V258.761H78.3433V259.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 261.503V256.815H88.3973V261.503H87.6018ZM85.6558 259.557V258.761H90.3433V259.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 261.503V256.815H100.397V261.503H99.6018ZM97.6558 259.557V258.761H102.343V259.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 261.503V256.815H112.397V261.503H111.602ZM109.656 259.557V258.761H114.343V259.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 261.503V256.815H124.397V261.503H123.602ZM121.656 259.557V258.761H126.343V259.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 261.503V256.815H136.397V261.503H135.602ZM133.656 259.557V258.761H138.343V259.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 261.503V256.815H148.397V261.503H147.602ZM145.656 259.557V258.761H150.343V259.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 261.503V256.815H160.397V261.503H159.602ZM157.656 259.557V258.761H162.343V259.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 261.503V256.815H172.397V261.503H171.602ZM169.656 259.557V258.761H174.343V259.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 261.503V256.815H184.397V261.503H183.602ZM181.656 259.557V258.761H186.343V259.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 261.503V256.815H196.397V261.503H195.602ZM193.656 259.557V258.761H198.343V259.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 261.503V256.815H208.397V261.503H207.602ZM205.656 259.557V258.761H210.343V259.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 261.503V256.815H220.397V261.503H219.602ZM217.656 259.557V258.761H222.343V259.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 261.503V256.815H232.397V261.503H231.602ZM229.656 259.557V258.761H234.343V259.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 261.503V256.815H244.397V261.503H243.602ZM241.656 259.557V258.761H246.343V259.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 261.503V256.815H256.397V261.503H255.602ZM253.656 259.557V258.761H258.343V259.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 261.503V256.815H268.397V261.503H267.602ZM265.656 259.557V258.761H270.343V259.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 261.503V256.815H280.397V261.503H279.602ZM277.656 259.557V258.761H282.343V259.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 261.503V256.815H292.397V261.503H291.602ZM289.656 259.557V258.761H294.343V259.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 261.503V256.815H304.397V261.503H303.602ZM301.656 259.557V258.761H306.343V259.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 261.503V256.815H316.397V261.503H315.602ZM313.656 259.557V258.761H318.343V259.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 261.503V256.815H328.397V261.503H327.602ZM325.656 259.557V258.761H330.343V259.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 261.503V256.815H340.397V261.503H339.602ZM337.656 259.557V258.761H342.343V259.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 261.503V256.815H352.397V261.503H351.602ZM349.656 259.557V258.761H354.343V259.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 261.503V256.815H364.397V261.503H363.602ZM361.656 259.557V258.761H366.343V259.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 261.503V256.815H376.397V261.503H375.602ZM373.656 259.557V258.761H378.343V259.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 261.503V256.815H388.397V261.503H387.602ZM385.656 259.557V258.761H390.343V259.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 261.503V256.815H400.397V261.503H399.602ZM397.656 259.557V258.761H402.343V259.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 261.503V256.815H412.397V261.503H411.602ZM409.656 259.557V258.761H414.343V259.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 261.503V256.815H424.397V261.503H423.602ZM421.656 259.557V258.761H426.343V259.557H421.656Z" fill="#01256C"/>
+<path d="M435.602 261.503V256.815H436.397V261.503H435.602ZM433.656 259.557V258.761H438.343V259.557H433.656Z" fill="#01256C"/>
+<path d="M447.602 261.503V256.815H448.397V261.503H447.602ZM445.656 259.557V258.761H450.343V259.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 261.503V256.815H460.397V261.503H459.602ZM457.656 259.557V258.761H462.343V259.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 261.503V256.815H472.397V261.503H471.602ZM469.656 259.557V258.761H474.343V259.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 261.503V256.815H484.397V261.503H483.602ZM481.656 259.557V258.761H486.343V259.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 261.503V256.815H496.397V261.503H495.602ZM493.656 259.557V258.761H498.343V259.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 261.503V256.815H508.397V261.503H507.602ZM505.656 259.557V258.761H510.343V259.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 261.503V256.815H520.397V261.503H519.602ZM517.656 259.557V258.761H522.343V259.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 261.503V256.815H532.397V261.503H531.602ZM529.656 259.557V258.761H534.343V259.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 261.503V256.815H544.397V261.503H543.602ZM541.656 259.557V258.761H546.343V259.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 261.503V256.815H556.397V261.503H555.602ZM553.656 259.557V258.761H558.343V259.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 261.503V256.815H568.397V261.503H567.602ZM565.656 259.557V258.761H570.343V259.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 261.503V256.815H580.397V261.503H579.602ZM577.656 259.557V258.761H582.343V259.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 261.503V256.815H592.397V261.503H591.602ZM589.656 259.557V258.761H594.343V259.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 261.503V256.815H604.397V261.503H603.602ZM601.656 259.557V258.761H606.343V259.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 261.503V256.815H616.397V261.503H615.602ZM613.656 259.557V258.761H618.343V259.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 261.503V256.815H628.397V261.503H627.602ZM625.656 259.557V258.761H630.343V259.557H625.656Z" fill="#01256C"/>
+<path d="M639.602 261.503V256.815H640.397V261.503H639.602ZM637.656 259.557V258.761H642.343V259.557H637.656Z" fill="#01256C"/>
+<path d="M723.602 261.503V256.815H724.397V261.503H723.602ZM721.656 259.557V258.761H726.343V259.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 261.503V256.815H736.397V261.503H735.602ZM733.656 259.557V258.761H738.343V259.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 261.503V256.815H748.397V261.503H747.602ZM745.656 259.557V258.761H750.343V259.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 261.503V256.815H760.397V261.503H759.602ZM757.656 259.557V258.761H762.343V259.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 261.503V256.815H772.397V261.503H771.602ZM769.656 259.557V258.761H774.343V259.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 261.503V256.815H784.397V261.503H783.602ZM781.656 259.557V258.761H786.343V259.557H781.656Z" fill="#01256C"/>
+<path d="M927.602 261.503V256.815H928.397V261.503H927.602ZM925.656 259.557V258.761H930.343V259.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 261.503V256.815H940.397V261.503H939.602ZM937.656 259.557V258.761H942.343V259.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 261.503V256.815H952.397V261.503H951.602ZM949.656 259.557V258.761H954.343V259.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 261.503V256.815H964.397V261.503H963.602ZM961.656 259.557V258.761H966.343V259.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 261.503V256.815H976.397V261.503H975.602ZM973.656 259.557V258.761H978.343V259.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 261.503V256.815H988.397V261.503H987.602ZM985.656 259.557V258.761H990.343V259.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 261.503V256.815H1000.4V261.503H999.602ZM997.656 259.557V258.761H1002.34V259.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 261.503V256.815H1012.4V261.503H1011.6ZM1009.66 259.557V258.761H1014.34V259.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 261.503V256.815H1024.4V261.503H1023.6ZM1021.66 259.557V258.761H1026.34V259.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 261.503V256.815H1036.4V261.503H1035.6ZM1033.66 259.557V258.761H1038.34V259.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 261.503V256.815H1048.4V261.503H1047.6ZM1045.66 259.557V258.761H1050.34V259.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 261.503V256.815H1060.4V261.503H1059.6ZM1057.66 259.557V258.761H1062.34V259.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 261.503V256.815H1072.4V261.503H1071.6ZM1069.66 259.557V258.761H1074.34V259.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 261.503V256.815H1084.4V261.503H1083.6ZM1081.66 259.557V258.761H1086.34V259.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 261.503V256.815H1096.4V261.503H1095.6ZM1093.66 259.557V258.761H1098.34V259.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 261.503V256.815H1108.4V261.503H1107.6ZM1105.66 259.557V258.761H1110.34V259.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 261.503V256.815H1120.4V261.503H1119.6ZM1117.66 259.557V258.761H1122.34V259.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 261.503V256.815H1132.4V261.503H1131.6ZM1129.66 259.557V258.761H1134.34V259.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 261.503V256.815H1144.4V261.503H1143.6ZM1141.66 259.557V258.761H1146.34V259.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 261.503V256.815H1156.4V261.503H1155.6ZM1153.66 259.557V258.761H1158.34V259.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 273.503V268.815H4.39728V273.503H3.60183ZM1.65581 271.557V270.761H6.34331V271.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 273.503V268.815H16.3973V273.503H15.6018ZM13.6558 271.557V270.761H18.3433V271.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 273.503V268.815H28.3973V273.503H27.6018ZM25.6558 271.557V270.761H30.3433V271.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 273.503V268.815H40.3973V273.503H39.6018ZM37.6558 271.557V270.761H42.3433V271.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 273.503V268.815H52.3973V273.503H51.6018ZM49.6558 271.557V270.761H54.3433V271.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 273.503V268.815H64.3973V273.503H63.6018ZM61.6558 271.557V270.761H66.3433V271.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 273.503V268.815H76.3973V273.503H75.6018ZM73.6558 271.557V270.761H78.3433V271.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 273.503V268.815H88.3973V273.503H87.6018ZM85.6558 271.557V270.761H90.3433V271.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 273.503V268.815H100.397V273.503H99.6018ZM97.6558 271.557V270.761H102.343V271.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 273.503V268.815H112.397V273.503H111.602ZM109.656 271.557V270.761H114.343V271.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 273.503V268.815H124.397V273.503H123.602ZM121.656 271.557V270.761H126.343V271.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 273.503V268.815H136.397V273.503H135.602ZM133.656 271.557V270.761H138.343V271.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 273.503V268.815H148.397V273.503H147.602ZM145.656 271.557V270.761H150.343V271.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 273.503V268.815H160.397V273.503H159.602ZM157.656 271.557V270.761H162.343V271.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 273.503V268.815H172.397V273.503H171.602ZM169.656 271.557V270.761H174.343V271.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 273.503V268.815H184.397V273.503H183.602ZM181.656 271.557V270.761H186.343V271.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 273.503V268.815H196.397V273.503H195.602ZM193.656 271.557V270.761H198.343V271.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 273.503V268.815H208.397V273.503H207.602ZM205.656 271.557V270.761H210.343V271.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 273.503V268.815H220.397V273.503H219.602ZM217.656 271.557V270.761H222.343V271.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 273.503V268.815H232.397V273.503H231.602ZM229.656 271.557V270.761H234.343V271.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 273.503V268.815H244.397V273.503H243.602ZM241.656 271.557V270.761H246.343V271.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 273.503V268.815H256.397V273.503H255.602ZM253.656 271.557V270.761H258.343V271.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 273.503V268.815H268.397V273.503H267.602ZM265.656 271.557V270.761H270.343V271.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 273.503V268.815H280.397V273.503H279.602ZM277.656 271.557V270.761H282.343V271.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 273.503V268.815H292.397V273.503H291.602ZM289.656 271.557V270.761H294.343V271.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 273.503V268.815H304.397V273.503H303.602ZM301.656 271.557V270.761H306.343V271.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 273.503V268.815H316.397V273.503H315.602ZM313.656 271.557V270.761H318.343V271.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 273.503V268.815H328.397V273.503H327.602ZM325.656 271.557V270.761H330.343V271.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 273.503V268.815H340.397V273.503H339.602ZM337.656 271.557V270.761H342.343V271.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 273.503V268.815H352.397V273.503H351.602ZM349.656 271.557V270.761H354.343V271.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 273.503V268.815H364.397V273.503H363.602ZM361.656 271.557V270.761H366.343V271.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 273.503V268.815H376.397V273.503H375.602ZM373.656 271.557V270.761H378.343V271.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 273.503V268.815H388.397V273.503H387.602ZM385.656 271.557V270.761H390.343V271.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 273.503V268.815H400.397V273.503H399.602ZM397.656 271.557V270.761H402.343V271.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 273.503V268.815H412.397V273.503H411.602ZM409.656 271.557V270.761H414.343V271.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 273.503V268.815H424.397V273.503H423.602ZM421.656 271.557V270.761H426.343V271.557H421.656Z" fill="#01256C"/>
+<path d="M435.602 273.503V268.815H436.397V273.503H435.602ZM433.656 271.557V270.761H438.343V271.557H433.656Z" fill="#01256C"/>
+<path d="M447.602 273.503V268.815H448.397V273.503H447.602ZM445.656 271.557V270.761H450.343V271.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 273.503V268.815H460.397V273.503H459.602ZM457.656 271.557V270.761H462.343V271.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 273.503V268.815H472.397V273.503H471.602ZM469.656 271.557V270.761H474.343V271.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 273.503V268.815H484.397V273.503H483.602ZM481.656 271.557V270.761H486.343V271.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 273.503V268.815H496.397V273.503H495.602ZM493.656 271.557V270.761H498.343V271.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 273.503V268.815H508.397V273.503H507.602ZM505.656 271.557V270.761H510.343V271.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 273.503V268.815H520.397V273.503H519.602ZM517.656 271.557V270.761H522.343V271.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 273.503V268.815H532.397V273.503H531.602ZM529.656 271.557V270.761H534.343V271.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 273.503V268.815H544.397V273.503H543.602ZM541.656 271.557V270.761H546.343V271.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 273.503V268.815H556.397V273.503H555.602ZM553.656 271.557V270.761H558.343V271.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 273.503V268.815H568.397V273.503H567.602ZM565.656 271.557V270.761H570.343V271.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 273.503V268.815H580.397V273.503H579.602ZM577.656 271.557V270.761H582.343V271.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 273.503V268.815H592.397V273.503H591.602ZM589.656 271.557V270.761H594.343V271.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 273.503V268.815H604.397V273.503H603.602ZM601.656 271.557V270.761H606.343V271.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 273.503V268.815H616.397V273.503H615.602ZM613.656 271.557V270.761H618.343V271.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 273.503V268.815H628.397V273.503H627.602ZM625.656 271.557V270.761H630.343V271.557H625.656Z" fill="#01256C"/>
+<path d="M639.602 273.503V268.815H640.397V273.503H639.602ZM637.656 271.557V270.761H642.343V271.557H637.656Z" fill="#01256C"/>
+<path d="M723.602 273.503V268.815H724.397V273.503H723.602ZM721.656 271.557V270.761H726.343V271.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 273.503V268.815H736.397V273.503H735.602ZM733.656 271.557V270.761H738.343V271.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 273.503V268.815H748.397V273.503H747.602ZM745.656 271.557V270.761H750.343V271.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 273.503V268.815H760.397V273.503H759.602ZM757.656 271.557V270.761H762.343V271.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 273.503V268.815H772.397V273.503H771.602ZM769.656 271.557V270.761H774.343V271.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 273.503V268.815H784.397V273.503H783.602ZM781.656 271.557V270.761H786.343V271.557H781.656Z" fill="#01256C"/>
+<path d="M939.602 273.503V268.815H940.397V273.503H939.602ZM937.656 271.557V270.761H942.343V271.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 273.503V268.815H952.397V273.503H951.602ZM949.656 271.557V270.761H954.343V271.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 273.503V268.815H964.397V273.503H963.602ZM961.656 271.557V270.761H966.343V271.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 273.503V268.815H976.397V273.503H975.602ZM973.656 271.557V270.761H978.343V271.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 273.503V268.815H988.397V273.503H987.602ZM985.656 271.557V270.761H990.343V271.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 273.503V268.815H1000.4V273.503H999.602ZM997.656 271.557V270.761H1002.34V271.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 273.503V268.815H1012.4V273.503H1011.6ZM1009.66 271.557V270.761H1014.34V271.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 273.503V268.815H1024.4V273.503H1023.6ZM1021.66 271.557V270.761H1026.34V271.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 273.503V268.815H1036.4V273.503H1035.6ZM1033.66 271.557V270.761H1038.34V271.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 273.503V268.815H1048.4V273.503H1047.6ZM1045.66 271.557V270.761H1050.34V271.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 273.503V268.815H1060.4V273.503H1059.6ZM1057.66 271.557V270.761H1062.34V271.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 273.503V268.815H1072.4V273.503H1071.6ZM1069.66 271.557V270.761H1074.34V271.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 273.503V268.815H1084.4V273.503H1083.6ZM1081.66 271.557V270.761H1086.34V271.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 273.503V268.815H1096.4V273.503H1095.6ZM1093.66 271.557V270.761H1098.34V271.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 273.503V268.815H1108.4V273.503H1107.6ZM1105.66 271.557V270.761H1110.34V271.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 273.503V268.815H1120.4V273.503H1119.6ZM1117.66 271.557V270.761H1122.34V271.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 273.503V268.815H1132.4V273.503H1131.6ZM1129.66 271.557V270.761H1134.34V271.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 273.503V268.815H1144.4V273.503H1143.6ZM1141.66 271.557V270.761H1146.34V271.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 273.503V268.815H1156.4V273.503H1155.6ZM1153.66 271.557V270.761H1158.34V271.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 285.503V280.815H4.39728V285.503H3.60183ZM1.65581 283.557V282.761H6.34331V283.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 285.503V280.815H16.3973V285.503H15.6018ZM13.6558 283.557V282.761H18.3433V283.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 285.503V280.815H28.3973V285.503H27.6018ZM25.6558 283.557V282.761H30.3433V283.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 285.503V280.815H40.3973V285.503H39.6018ZM37.6558 283.557V282.761H42.3433V283.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 285.503V280.815H52.3973V285.503H51.6018ZM49.6558 283.557V282.761H54.3433V283.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 285.503V280.815H64.3973V285.503H63.6018ZM61.6558 283.557V282.761H66.3433V283.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 285.503V280.815H76.3973V285.503H75.6018ZM73.6558 283.557V282.761H78.3433V283.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 285.503V280.815H88.3973V285.503H87.6018ZM85.6558 283.557V282.761H90.3433V283.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 285.503V280.815H100.397V285.503H99.6018ZM97.6558 283.557V282.761H102.343V283.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 285.503V280.815H112.397V285.503H111.602ZM109.656 283.557V282.761H114.343V283.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 285.503V280.815H124.397V285.503H123.602ZM121.656 283.557V282.761H126.343V283.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 285.503V280.815H136.397V285.503H135.602ZM133.656 283.557V282.761H138.343V283.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 285.503V280.815H148.397V285.503H147.602ZM145.656 283.557V282.761H150.343V283.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 285.503V280.815H160.397V285.503H159.602ZM157.656 283.557V282.761H162.343V283.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 285.503V280.815H172.397V285.503H171.602ZM169.656 283.557V282.761H174.343V283.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 285.503V280.815H184.397V285.503H183.602ZM181.656 283.557V282.761H186.343V283.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 285.503V280.815H196.397V285.503H195.602ZM193.656 283.557V282.761H198.343V283.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 285.503V280.815H208.397V285.503H207.602ZM205.656 283.557V282.761H210.343V283.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 285.503V280.815H220.397V285.503H219.602ZM217.656 283.557V282.761H222.343V283.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 285.503V280.815H232.397V285.503H231.602ZM229.656 283.557V282.761H234.343V283.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 285.503V280.815H244.397V285.503H243.602ZM241.656 283.557V282.761H246.343V283.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 285.503V280.815H256.397V285.503H255.602ZM253.656 283.557V282.761H258.343V283.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 285.503V280.815H268.397V285.503H267.602ZM265.656 283.557V282.761H270.343V283.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 285.503V280.815H280.397V285.503H279.602ZM277.656 283.557V282.761H282.343V283.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 285.503V280.815H292.397V285.503H291.602ZM289.656 283.557V282.761H294.343V283.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 285.503V280.815H304.397V285.503H303.602ZM301.656 283.557V282.761H306.343V283.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 285.503V280.815H316.397V285.503H315.602ZM313.656 283.557V282.761H318.343V283.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 285.503V280.815H328.397V285.503H327.602ZM325.656 283.557V282.761H330.343V283.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 285.503V280.815H340.397V285.503H339.602ZM337.656 283.557V282.761H342.343V283.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 285.503V280.815H352.397V285.503H351.602ZM349.656 283.557V282.761H354.343V283.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 285.503V280.815H364.397V285.503H363.602ZM361.656 283.557V282.761H366.343V283.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 285.503V280.815H376.397V285.503H375.602ZM373.656 283.557V282.761H378.343V283.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 285.503V280.815H388.397V285.503H387.602ZM385.656 283.557V282.761H390.343V283.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 285.503V280.815H400.397V285.503H399.602ZM397.656 283.557V282.761H402.343V283.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 285.503V280.815H412.397V285.503H411.602ZM409.656 283.557V282.761H414.343V283.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 285.503V280.815H424.397V285.503H423.602ZM421.656 283.557V282.761H426.343V283.557H421.656Z" fill="#01256C"/>
+<path d="M435.602 285.503V280.815H436.397V285.503H435.602ZM433.656 283.557V282.761H438.343V283.557H433.656Z" fill="#01256C"/>
+<path d="M447.602 285.503V280.815H448.397V285.503H447.602ZM445.656 283.557V282.761H450.343V283.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 285.503V280.815H460.397V285.503H459.602ZM457.656 283.557V282.761H462.343V283.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 285.503V280.815H472.397V285.503H471.602ZM469.656 283.557V282.761H474.343V283.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 285.503V280.815H484.397V285.503H483.602ZM481.656 283.557V282.761H486.343V283.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 285.503V280.815H496.397V285.503H495.602ZM493.656 283.557V282.761H498.343V283.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 285.503V280.815H508.397V285.503H507.602ZM505.656 283.557V282.761H510.343V283.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 285.503V280.815H520.397V285.503H519.602ZM517.656 283.557V282.761H522.343V283.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 285.503V280.815H532.397V285.503H531.602ZM529.656 283.557V282.761H534.343V283.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 285.503V280.815H544.397V285.503H543.602ZM541.656 283.557V282.761H546.343V283.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 285.503V280.815H556.397V285.503H555.602ZM553.656 283.557V282.761H558.343V283.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 285.503V280.815H568.397V285.503H567.602ZM565.656 283.557V282.761H570.343V283.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 285.503V280.815H580.397V285.503H579.602ZM577.656 283.557V282.761H582.343V283.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 285.503V280.815H592.397V285.503H591.602ZM589.656 283.557V282.761H594.343V283.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 285.503V280.815H604.397V285.503H603.602ZM601.656 283.557V282.761H606.343V283.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 285.503V280.815H616.397V285.503H615.602ZM613.656 283.557V282.761H618.343V283.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 285.503V280.815H628.397V285.503H627.602ZM625.656 283.557V282.761H630.343V283.557H625.656Z" fill="#01256C"/>
+<path d="M639.602 285.503V280.815H640.397V285.503H639.602ZM637.656 283.557V282.761H642.343V283.557H637.656Z" fill="#01256C"/>
+<path d="M712.001 286.057C711.826 286.057 711.675 285.994 711.55 285.869C711.424 285.743 711.362 285.593 711.362 285.418C711.362 285.242 711.424 285.092 711.55 284.967C711.675 284.841 711.826 284.778 712.001 284.778C712.176 284.778 712.326 284.841 712.452 284.967C712.577 285.092 712.64 285.242 712.64 285.418C712.64 285.534 712.61 285.64 712.551 285.737C712.494 285.834 712.418 285.912 712.32 285.972C712.226 286.028 712.119 286.057 712.001 286.057Z" fill="#01256C"/>
+<path d="M723.602 285.503V280.815H724.397V285.503H723.602ZM721.656 283.557V282.761H726.343V283.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 285.503V280.815H736.397V285.503H735.602ZM733.656 283.557V282.761H738.343V283.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 285.503V280.815H748.397V285.503H747.602ZM745.656 283.557V282.761H750.343V283.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 285.503V280.815H760.397V285.503H759.602ZM757.656 283.557V282.761H762.343V283.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 285.503V280.815H772.397V285.503H771.602ZM769.656 283.557V282.761H774.343V283.557H769.656Z" fill="#01256C"/>
+<path d="M784.616 285.006L784.559 285.389C784.519 285.659 784.457 285.948 784.374 286.256C784.294 286.563 784.21 286.853 784.122 287.126C784.034 287.398 783.962 287.615 783.905 287.776H783.266C783.297 287.624 783.337 287.424 783.387 287.175C783.437 286.927 783.486 286.649 783.536 286.341C783.588 286.036 783.631 285.723 783.664 285.403L783.707 285.006H784.616ZM784.104 282.009C783.929 282.009 783.779 281.946 783.653 281.82C783.528 281.695 783.465 281.545 783.465 281.369C783.465 281.194 783.528 281.044 783.653 280.918C783.779 280.793 783.929 280.73 784.104 280.73C784.28 280.73 784.43 280.793 784.555 280.918C784.681 281.044 784.744 281.194 784.744 281.369C784.744 281.485 784.714 281.592 784.655 281.689C784.598 281.786 784.521 281.864 784.424 281.923C784.329 281.98 784.223 282.009 784.104 282.009Z" fill="#01256C"/>
+<path d="M963.602 285.503V280.815H964.397V285.503H963.602ZM961.656 283.557V282.761H966.343V283.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 285.503V280.815H976.397V285.503H975.602ZM973.656 283.557V282.761H978.343V283.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 285.503V280.815H988.397V285.503H987.602ZM985.656 283.557V282.761H990.343V283.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 285.503V280.815H1000.4V285.503H999.602ZM997.656 283.557V282.761H1002.34V283.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 285.503V280.815H1012.4V285.503H1011.6ZM1009.66 283.557V282.761H1014.34V283.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 285.503V280.815H1024.4V285.503H1023.6ZM1021.66 283.557V282.761H1026.34V283.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 285.503V280.815H1036.4V285.503H1035.6ZM1033.66 283.557V282.761H1038.34V283.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 285.503V280.815H1048.4V285.503H1047.6ZM1045.66 283.557V282.761H1050.34V283.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 285.503V280.815H1060.4V285.503H1059.6ZM1057.66 283.557V282.761H1062.34V283.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 285.503V280.815H1072.4V285.503H1071.6ZM1069.66 283.557V282.761H1074.34V283.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 285.503V280.815H1084.4V285.503H1083.6ZM1081.66 283.557V282.761H1086.34V283.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 285.503V280.815H1096.4V285.503H1095.6ZM1093.66 283.557V282.761H1098.34V283.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 285.503V280.815H1108.4V285.503H1107.6ZM1105.66 283.557V282.761H1110.34V283.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 285.503V280.815H1120.4V285.503H1119.6ZM1117.66 283.557V282.761H1122.34V283.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 285.503V280.815H1132.4V285.503H1131.6ZM1129.66 283.557V282.761H1134.34V283.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 285.503V280.815H1144.4V285.503H1143.6ZM1141.66 283.557V282.761H1146.34V283.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 285.503V280.815H1156.4V285.503H1155.6ZM1153.66 283.557V282.761H1158.34V283.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 297.503V292.815H4.39728V297.503H3.60183ZM1.65581 295.557V294.761H6.34331V295.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 297.503V292.815H16.3973V297.503H15.6018ZM13.6558 295.557V294.761H18.3433V295.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 297.503V292.815H28.3973V297.503H27.6018ZM25.6558 295.557V294.761H30.3433V295.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 297.503V292.815H40.3973V297.503H39.6018ZM37.6558 295.557V294.761H42.3433V295.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 297.503V292.815H52.3973V297.503H51.6018ZM49.6558 295.557V294.761H54.3433V295.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 297.503V292.815H64.3973V297.503H63.6018ZM61.6558 295.557V294.761H66.3433V295.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 297.503V292.815H76.3973V297.503H75.6018ZM73.6558 295.557V294.761H78.3433V295.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 297.503V292.815H88.3973V297.503H87.6018ZM85.6558 295.557V294.761H90.3433V295.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 297.503V292.815H100.397V297.503H99.6018ZM97.6558 295.557V294.761H102.343V295.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 297.503V292.815H112.397V297.503H111.602ZM109.656 295.557V294.761H114.343V295.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 297.503V292.815H124.397V297.503H123.602ZM121.656 295.557V294.761H126.343V295.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 297.503V292.815H136.397V297.503H135.602ZM133.656 295.557V294.761H138.343V295.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 297.503V292.815H148.397V297.503H147.602ZM145.656 295.557V294.761H150.343V295.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 297.503V292.815H160.397V297.503H159.602ZM157.656 295.557V294.761H162.343V295.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 297.503V292.815H172.397V297.503H171.602ZM169.656 295.557V294.761H174.343V295.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 297.503V292.815H184.397V297.503H183.602ZM181.656 295.557V294.761H186.343V295.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 297.503V292.815H196.397V297.503H195.602ZM193.656 295.557V294.761H198.343V295.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 297.503V292.815H208.397V297.503H207.602ZM205.656 295.557V294.761H210.343V295.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 297.503V292.815H220.397V297.503H219.602ZM217.656 295.557V294.761H222.343V295.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 297.503V292.815H232.397V297.503H231.602ZM229.656 295.557V294.761H234.343V295.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 297.503V292.815H244.397V297.503H243.602ZM241.656 295.557V294.761H246.343V295.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 297.503V292.815H256.397V297.503H255.602ZM253.656 295.557V294.761H258.343V295.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 297.503V292.815H268.397V297.503H267.602ZM265.656 295.557V294.761H270.343V295.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 297.503V292.815H280.397V297.503H279.602ZM277.656 295.557V294.761H282.343V295.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 297.503V292.815H292.397V297.503H291.602ZM289.656 295.557V294.761H294.343V295.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 297.503V292.815H304.397V297.503H303.602ZM301.656 295.557V294.761H306.343V295.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 297.503V292.815H316.397V297.503H315.602ZM313.656 295.557V294.761H318.343V295.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 297.503V292.815H328.397V297.503H327.602ZM325.656 295.557V294.761H330.343V295.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 297.503V292.815H340.397V297.503H339.602ZM337.656 295.557V294.761H342.343V295.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 297.503V292.815H352.397V297.503H351.602ZM349.656 295.557V294.761H354.343V295.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 297.503V292.815H364.397V297.503H363.602ZM361.656 295.557V294.761H366.343V295.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 297.503V292.815H376.397V297.503H375.602ZM373.656 295.557V294.761H378.343V295.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 297.503V292.815H388.397V297.503H387.602ZM385.656 295.557V294.761H390.343V295.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 297.503V292.815H400.397V297.503H399.602ZM397.656 295.557V294.761H402.343V295.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 297.503V292.815H412.397V297.503H411.602ZM409.656 295.557V294.761H414.343V295.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 297.503V292.815H424.397V297.503H423.602ZM421.656 295.557V294.761H426.343V295.557H421.656Z" fill="#01256C"/>
+<path d="M435.602 297.503V292.815H436.397V297.503H435.602ZM433.656 295.557V294.761H438.343V295.557H433.656Z" fill="#01256C"/>
+<path d="M447.602 297.503V292.815H448.397V297.503H447.602ZM445.656 295.557V294.761H450.343V295.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 297.503V292.815H460.397V297.503H459.602ZM457.656 295.557V294.761H462.343V295.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 297.503V292.815H472.397V297.503H471.602ZM469.656 295.557V294.761H474.343V295.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 297.503V292.815H484.397V297.503H483.602ZM481.656 295.557V294.761H486.343V295.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 297.503V292.815H496.397V297.503H495.602ZM493.656 295.557V294.761H498.343V295.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 297.503V292.815H508.397V297.503H507.602ZM505.656 295.557V294.761H510.343V295.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 297.503V292.815H520.397V297.503H519.602ZM517.656 295.557V294.761H522.343V295.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 297.503V292.815H532.397V297.503H531.602ZM529.656 295.557V294.761H534.343V295.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 297.503V292.815H544.397V297.503H543.602ZM541.656 295.557V294.761H546.343V295.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 297.503V292.815H556.397V297.503H555.602ZM553.656 295.557V294.761H558.343V295.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 297.503V292.815H568.397V297.503H567.602ZM565.656 295.557V294.761H570.343V295.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 297.503V292.815H580.397V297.503H579.602ZM577.656 295.557V294.761H582.343V295.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 297.503V292.815H592.397V297.503H591.602ZM589.656 295.557V294.761H594.343V295.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 297.503V292.815H604.397V297.503H603.602ZM601.656 295.557V294.761H606.343V295.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 297.503V292.815H616.397V297.503H615.602ZM613.656 295.557V294.761H618.343V295.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 297.503V292.815H628.397V297.503H627.602ZM625.656 295.557V294.761H630.343V295.557H625.656Z" fill="#01256C"/>
+<path d="M639.602 297.503V292.815H640.397V297.503H639.602ZM637.656 295.557V294.761H642.343V295.557H637.656Z" fill="#01256C"/>
+<path d="M711.602 297.503V292.815H712.397V297.503H711.602ZM709.656 295.557V294.761H714.343V295.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 297.503V292.815H724.397V297.503H723.602ZM721.656 295.557V294.761H726.343V295.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 297.503V292.815H736.397V297.503H735.602ZM733.656 295.557V294.761H738.343V295.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 297.503V292.815H748.397V297.503H747.602ZM745.656 295.557V294.761H750.343V295.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 297.503V292.815H760.397V297.503H759.602ZM757.656 295.557V294.761H762.343V295.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 297.503V292.815H772.397V297.503H771.602ZM769.656 295.557V294.761H774.343V295.557H769.656Z" fill="#01256C"/>
+<path d="M999.659 294.818L999.716 293.256L998.395 294.094L998.054 293.497L999.446 292.773L998.054 292.048L998.395 291.452L999.716 292.29L999.659 290.727H1000.34L1000.28 292.29L1001.61 291.452L1001.95 292.048L1000.55 292.773L1001.95 293.497L1001.61 294.094L1000.28 293.256L1000.34 294.818H999.659Z" fill="#01256C"/>
+<path d="M1011.6 297.503V292.815H1012.4V297.503H1011.6ZM1009.66 295.557V294.761H1014.34V295.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 297.503V292.815H1024.4V297.503H1023.6ZM1021.66 295.557V294.761H1026.34V295.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 297.503V292.815H1036.4V297.503H1035.6ZM1033.66 295.557V294.761H1038.34V295.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 297.503V292.815H1048.4V297.503H1047.6ZM1045.66 295.557V294.761H1050.34V295.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 297.503V292.815H1060.4V297.503H1059.6ZM1057.66 295.557V294.761H1062.34V295.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 297.503V292.815H1072.4V297.503H1071.6ZM1069.66 295.557V294.761H1074.34V295.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 297.503V292.815H1084.4V297.503H1083.6ZM1081.66 295.557V294.761H1086.34V295.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 297.503V292.815H1096.4V297.503H1095.6ZM1093.66 295.557V294.761H1098.34V295.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 297.503V292.815H1108.4V297.503H1107.6ZM1105.66 295.557V294.761H1110.34V295.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 297.503V292.815H1120.4V297.503H1119.6ZM1117.66 295.557V294.761H1122.34V295.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 297.503V292.815H1132.4V297.503H1131.6ZM1129.66 295.557V294.761H1134.34V295.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 297.503V292.815H1144.4V297.503H1143.6ZM1141.66 295.557V294.761H1146.34V295.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 297.503V292.815H1156.4V297.503H1155.6ZM1153.66 295.557V294.761H1158.34V295.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 309.503V304.815H4.39728V309.503H3.60183ZM1.65581 307.557V306.761H6.34331V307.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 309.503V304.815H16.3973V309.503H15.6018ZM13.6558 307.557V306.761H18.3433V307.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 309.503V304.815H28.3973V309.503H27.6018ZM25.6558 307.557V306.761H30.3433V307.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 309.503V304.815H40.3973V309.503H39.6018ZM37.6558 307.557V306.761H42.3433V307.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 309.503V304.815H52.3973V309.503H51.6018ZM49.6558 307.557V306.761H54.3433V307.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 309.503V304.815H64.3973V309.503H63.6018ZM61.6558 307.557V306.761H66.3433V307.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 309.503V304.815H76.3973V309.503H75.6018ZM73.6558 307.557V306.761H78.3433V307.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 309.503V304.815H88.3973V309.503H87.6018ZM85.6558 307.557V306.761H90.3433V307.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 309.503V304.815H100.397V309.503H99.6018ZM97.6558 307.557V306.761H102.343V307.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 309.503V304.815H112.397V309.503H111.602ZM109.656 307.557V306.761H114.343V307.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 309.503V304.815H124.397V309.503H123.602ZM121.656 307.557V306.761H126.343V307.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 309.503V304.815H136.397V309.503H135.602ZM133.656 307.557V306.761H138.343V307.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 309.503V304.815H148.397V309.503H147.602ZM145.656 307.557V306.761H150.343V307.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 309.503V304.815H160.397V309.503H159.602ZM157.656 307.557V306.761H162.343V307.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 309.503V304.815H172.397V309.503H171.602ZM169.656 307.557V306.761H174.343V307.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 309.503V304.815H184.397V309.503H183.602ZM181.656 307.557V306.761H186.343V307.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 309.503V304.815H196.397V309.503H195.602ZM193.656 307.557V306.761H198.343V307.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 309.503V304.815H208.397V309.503H207.602ZM205.656 307.557V306.761H210.343V307.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 309.503V304.815H220.397V309.503H219.602ZM217.656 307.557V306.761H222.343V307.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 309.503V304.815H232.397V309.503H231.602ZM229.656 307.557V306.761H234.343V307.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 309.503V304.815H244.397V309.503H243.602ZM241.656 307.557V306.761H246.343V307.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 309.503V304.815H256.397V309.503H255.602ZM253.656 307.557V306.761H258.343V307.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 309.503V304.815H268.397V309.503H267.602ZM265.656 307.557V306.761H270.343V307.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 309.503V304.815H280.397V309.503H279.602ZM277.656 307.557V306.761H282.343V307.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 309.503V304.815H292.397V309.503H291.602ZM289.656 307.557V306.761H294.343V307.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 309.503V304.815H304.397V309.503H303.602ZM301.656 307.557V306.761H306.343V307.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 309.503V304.815H316.397V309.503H315.602ZM313.656 307.557V306.761H318.343V307.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 309.503V304.815H328.397V309.503H327.602ZM325.656 307.557V306.761H330.343V307.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 309.503V304.815H340.397V309.503H339.602ZM337.656 307.557V306.761H342.343V307.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 309.503V304.815H352.397V309.503H351.602ZM349.656 307.557V306.761H354.343V307.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 309.503V304.815H364.397V309.503H363.602ZM361.656 307.557V306.761H366.343V307.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 309.503V304.815H376.397V309.503H375.602ZM373.656 307.557V306.761H378.343V307.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 309.503V304.815H388.397V309.503H387.602ZM385.656 307.557V306.761H390.343V307.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 309.503V304.815H400.397V309.503H399.602ZM397.656 307.557V306.761H402.343V307.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 309.503V304.815H412.397V309.503H411.602ZM409.656 307.557V306.761H414.343V307.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 309.503V304.815H424.397V309.503H423.602ZM421.656 307.557V306.761H426.343V307.557H421.656Z" fill="#01256C"/>
+<path d="M435.602 309.503V304.815H436.397V309.503H435.602ZM433.656 307.557V306.761H438.343V307.557H433.656Z" fill="#01256C"/>
+<path d="M447.602 309.503V304.815H448.397V309.503H447.602ZM445.656 307.557V306.761H450.343V307.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 309.503V304.815H460.397V309.503H459.602ZM457.656 307.557V306.761H462.343V307.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 309.503V304.815H472.397V309.503H471.602ZM469.656 307.557V306.761H474.343V307.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 309.503V304.815H484.397V309.503H483.602ZM481.656 307.557V306.761H486.343V307.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 309.503V304.815H496.397V309.503H495.602ZM493.656 307.557V306.761H498.343V307.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 309.503V304.815H508.397V309.503H507.602ZM505.656 307.557V306.761H510.343V307.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 309.503V304.815H520.397V309.503H519.602ZM517.656 307.557V306.761H522.343V307.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 309.503V304.815H532.397V309.503H531.602ZM529.656 307.557V306.761H534.343V307.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 309.503V304.815H544.397V309.503H543.602ZM541.656 307.557V306.761H546.343V307.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 309.503V304.815H556.397V309.503H555.602ZM553.656 307.557V306.761H558.343V307.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 309.503V304.815H568.397V309.503H567.602ZM565.656 307.557V306.761H570.343V307.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 309.503V304.815H580.397V309.503H579.602ZM577.656 307.557V306.761H582.343V307.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 309.503V304.815H592.397V309.503H591.602ZM589.656 307.557V306.761H594.343V307.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 309.503V304.815H604.397V309.503H603.602ZM601.656 307.557V306.761H606.343V307.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 309.503V304.815H616.397V309.503H615.602ZM613.656 307.557V306.761H618.343V307.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 309.503V304.815H628.397V309.503H627.602ZM625.656 307.557V306.761H630.343V307.557H625.656Z" fill="#01256C"/>
+<path d="M639.602 309.503V304.815H640.397V309.503H639.602ZM637.656 307.557V306.761H642.343V307.557H637.656Z" fill="#01256C"/>
+<path d="M711.602 309.503V304.815H712.397V309.503H711.602ZM709.656 307.557V306.761H714.343V307.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 309.503V304.815H724.397V309.503H723.602ZM721.656 307.557V306.761H726.343V307.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 309.503V304.815H736.397V309.503H735.602ZM733.656 307.557V306.761H738.343V307.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 309.503V304.815H748.397V309.503H747.602ZM745.656 307.557V306.761H750.343V307.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 309.503V304.815H760.397V309.503H759.602ZM757.656 307.557V306.761H762.343V307.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 309.503V304.815H772.397V309.503H771.602ZM769.656 307.557V306.761H774.343V307.557H769.656Z" fill="#01256C"/>
+<path d="M3.60183 321.503V316.815H4.39728V321.503H3.60183ZM1.65581 319.557V318.761H6.34331V319.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 321.503V316.815H16.3973V321.503H15.6018ZM13.6558 319.557V318.761H18.3433V319.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 321.503V316.815H28.3973V321.503H27.6018ZM25.6558 319.557V318.761H30.3433V319.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 321.503V316.815H40.3973V321.503H39.6018ZM37.6558 319.557V318.761H42.3433V319.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 321.503V316.815H52.3973V321.503H51.6018ZM49.6558 319.557V318.761H54.3433V319.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 321.503V316.815H64.3973V321.503H63.6018ZM61.6558 319.557V318.761H66.3433V319.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 321.503V316.815H76.3973V321.503H75.6018ZM73.6558 319.557V318.761H78.3433V319.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 321.503V316.815H88.3973V321.503H87.6018ZM85.6558 319.557V318.761H90.3433V319.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 321.503V316.815H100.397V321.503H99.6018ZM97.6558 319.557V318.761H102.343V319.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 321.503V316.815H112.397V321.503H111.602ZM109.656 319.557V318.761H114.343V319.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 321.503V316.815H124.397V321.503H123.602ZM121.656 319.557V318.761H126.343V319.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 321.503V316.815H136.397V321.503H135.602ZM133.656 319.557V318.761H138.343V319.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 321.503V316.815H148.397V321.503H147.602ZM145.656 319.557V318.761H150.343V319.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 321.503V316.815H160.397V321.503H159.602ZM157.656 319.557V318.761H162.343V319.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 321.503V316.815H172.397V321.503H171.602ZM169.656 319.557V318.761H174.343V319.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 321.503V316.815H184.397V321.503H183.602ZM181.656 319.557V318.761H186.343V319.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 321.503V316.815H196.397V321.503H195.602ZM193.656 319.557V318.761H198.343V319.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 321.503V316.815H208.397V321.503H207.602ZM205.656 319.557V318.761H210.343V319.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 321.503V316.815H220.397V321.503H219.602ZM217.656 319.557V318.761H222.343V319.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 321.503V316.815H232.397V321.503H231.602ZM229.656 319.557V318.761H234.343V319.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 321.503V316.815H244.397V321.503H243.602ZM241.656 319.557V318.761H246.343V319.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 321.503V316.815H256.397V321.503H255.602ZM253.656 319.557V318.761H258.343V319.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 321.503V316.815H268.397V321.503H267.602ZM265.656 319.557V318.761H270.343V319.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 321.503V316.815H280.397V321.503H279.602ZM277.656 319.557V318.761H282.343V319.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 321.503V316.815H292.397V321.503H291.602ZM289.656 319.557V318.761H294.343V319.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 321.503V316.815H304.397V321.503H303.602ZM301.656 319.557V318.761H306.343V319.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 321.503V316.815H316.397V321.503H315.602ZM313.656 319.557V318.761H318.343V319.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 321.503V316.815H328.397V321.503H327.602ZM325.656 319.557V318.761H330.343V319.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 321.503V316.815H340.397V321.503H339.602ZM337.656 319.557V318.761H342.343V319.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 321.503V316.815H352.397V321.503H351.602ZM349.656 319.557V318.761H354.343V319.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 321.503V316.815H364.397V321.503H363.602ZM361.656 319.557V318.761H366.343V319.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 321.503V316.815H376.397V321.503H375.602ZM373.656 319.557V318.761H378.343V319.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 321.503V316.815H388.397V321.503H387.602ZM385.656 319.557V318.761H390.343V319.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 321.503V316.815H400.397V321.503H399.602ZM397.656 319.557V318.761H402.343V319.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 321.503V316.815H412.397V321.503H411.602ZM409.656 319.557V318.761H414.343V319.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 321.503V316.815H424.397V321.503H423.602ZM421.656 319.557V318.761H426.343V319.557H421.656Z" fill="#01256C"/>
+<path d="M435.602 321.503V316.815H436.397V321.503H435.602ZM433.656 319.557V318.761H438.343V319.557H433.656Z" fill="#01256C"/>
+<path d="M447.602 321.503V316.815H448.397V321.503H447.602ZM445.656 319.557V318.761H450.343V319.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 321.503V316.815H460.397V321.503H459.602ZM457.656 319.557V318.761H462.343V319.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 321.503V316.815H472.397V321.503H471.602ZM469.656 319.557V318.761H474.343V319.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 321.503V316.815H484.397V321.503H483.602ZM481.656 319.557V318.761H486.343V319.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 321.503V316.815H496.397V321.503H495.602ZM493.656 319.557V318.761H498.343V319.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 321.503V316.815H508.397V321.503H507.602ZM505.656 319.557V318.761H510.343V319.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 321.503V316.815H520.397V321.503H519.602ZM517.656 319.557V318.761H522.343V319.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 321.503V316.815H532.397V321.503H531.602ZM529.656 319.557V318.761H534.343V319.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 321.503V316.815H544.397V321.503H543.602ZM541.656 319.557V318.761H546.343V319.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 321.503V316.815H556.397V321.503H555.602ZM553.656 319.557V318.761H558.343V319.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 321.503V316.815H568.397V321.503H567.602ZM565.656 319.557V318.761H570.343V319.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 321.503V316.815H580.397V321.503H579.602ZM577.656 319.557V318.761H582.343V319.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 321.503V316.815H592.397V321.503H591.602ZM589.656 319.557V318.761H594.343V319.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 321.503V316.815H604.397V321.503H603.602ZM601.656 319.557V318.761H606.343V319.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 321.503V316.815H616.397V321.503H615.602ZM613.656 319.557V318.761H618.343V319.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 321.503V316.815H628.397V321.503H627.602ZM625.656 319.557V318.761H630.343V319.557H625.656Z" fill="#01256C"/>
+<path d="M639.602 321.503V316.815H640.397V321.503H639.602ZM637.656 319.557V318.761H642.343V319.557H637.656Z" fill="#01256C"/>
+<path d="M711.602 321.503V316.815H712.397V321.503H711.602ZM709.656 319.557V318.761H714.343V319.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 321.503V316.815H724.397V321.503H723.602ZM721.656 319.557V318.761H726.343V319.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 321.503V316.815H736.397V321.503H735.602ZM733.656 319.557V318.761H738.343V319.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 321.503V316.815H748.397V321.503H747.602ZM745.656 319.557V318.761H750.343V319.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 321.503V316.815H760.397V321.503H759.602ZM757.656 319.557V318.761H762.343V319.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 321.503V316.815H772.397V321.503H771.602ZM769.656 319.557V318.761H774.343V319.557H769.656Z" fill="#01256C"/>
+<path d="M3.60183 333.503V328.815H4.39728V333.503H3.60183ZM1.65581 331.557V330.761H6.34331V331.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 333.503V328.815H16.3973V333.503H15.6018ZM13.6558 331.557V330.761H18.3433V331.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 333.503V328.815H28.3973V333.503H27.6018ZM25.6558 331.557V330.761H30.3433V331.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 333.503V328.815H40.3973V333.503H39.6018ZM37.6558 331.557V330.761H42.3433V331.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 333.503V328.815H52.3973V333.503H51.6018ZM49.6558 331.557V330.761H54.3433V331.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 333.503V328.815H64.3973V333.503H63.6018ZM61.6558 331.557V330.761H66.3433V331.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 333.503V328.815H76.3973V333.503H75.6018ZM73.6558 331.557V330.761H78.3433V331.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 333.503V328.815H88.3973V333.503H87.6018ZM85.6558 331.557V330.761H90.3433V331.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 333.503V328.815H100.397V333.503H99.6018ZM97.6558 331.557V330.761H102.343V331.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 333.503V328.815H112.397V333.503H111.602ZM109.656 331.557V330.761H114.343V331.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 333.503V328.815H124.397V333.503H123.602ZM121.656 331.557V330.761H126.343V331.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 333.503V328.815H136.397V333.503H135.602ZM133.656 331.557V330.761H138.343V331.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 333.503V328.815H148.397V333.503H147.602ZM145.656 331.557V330.761H150.343V331.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 333.503V328.815H160.397V333.503H159.602ZM157.656 331.557V330.761H162.343V331.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 333.503V328.815H172.397V333.503H171.602ZM169.656 331.557V330.761H174.343V331.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 333.503V328.815H184.397V333.503H183.602ZM181.656 331.557V330.761H186.343V331.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 333.503V328.815H196.397V333.503H195.602ZM193.656 331.557V330.761H198.343V331.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 333.503V328.815H208.397V333.503H207.602ZM205.656 331.557V330.761H210.343V331.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 333.503V328.815H220.397V333.503H219.602ZM217.656 331.557V330.761H222.343V331.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 333.503V328.815H232.397V333.503H231.602ZM229.656 331.557V330.761H234.343V331.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 333.503V328.815H244.397V333.503H243.602ZM241.656 331.557V330.761H246.343V331.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 333.503V328.815H256.397V333.503H255.602ZM253.656 331.557V330.761H258.343V331.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 333.503V328.815H268.397V333.503H267.602ZM265.656 331.557V330.761H270.343V331.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 333.503V328.815H280.397V333.503H279.602ZM277.656 331.557V330.761H282.343V331.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 333.503V328.815H292.397V333.503H291.602ZM289.656 331.557V330.761H294.343V331.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 333.503V328.815H304.397V333.503H303.602ZM301.656 331.557V330.761H306.343V331.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 333.503V328.815H316.397V333.503H315.602ZM313.656 331.557V330.761H318.343V331.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 333.503V328.815H328.397V333.503H327.602ZM325.656 331.557V330.761H330.343V331.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 333.503V328.815H340.397V333.503H339.602ZM337.656 331.557V330.761H342.343V331.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 333.503V328.815H352.397V333.503H351.602ZM349.656 331.557V330.761H354.343V331.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 333.503V328.815H364.397V333.503H363.602ZM361.656 331.557V330.761H366.343V331.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 333.503V328.815H376.397V333.503H375.602ZM373.656 331.557V330.761H378.343V331.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 333.503V328.815H388.397V333.503H387.602ZM385.656 331.557V330.761H390.343V331.557H385.656Z" fill="#01256C"/>
+<path d="M435.602 333.503V328.815H436.397V333.503H435.602ZM433.656 331.557V330.761H438.343V331.557H433.656Z" fill="#01256C"/>
+<path d="M447.602 333.503V328.815H448.397V333.503H447.602ZM445.656 331.557V330.761H450.343V331.557H445.656Z" fill="#01256C"/>
+<path d="M459.602 333.503V328.815H460.397V333.503H459.602ZM457.656 331.557V330.761H462.343V331.557H457.656Z" fill="#01256C"/>
+<path d="M471.602 333.503V328.815H472.397V333.503H471.602ZM469.656 331.557V330.761H474.343V331.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 333.503V328.815H484.397V333.503H483.602ZM481.656 331.557V330.761H486.343V331.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 333.503V328.815H496.397V333.503H495.602ZM493.656 331.557V330.761H498.343V331.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 333.503V328.815H508.397V333.503H507.602ZM505.656 331.557V330.761H510.343V331.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 333.503V328.815H520.397V333.503H519.602ZM517.656 331.557V330.761H522.343V331.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 333.503V328.815H532.397V333.503H531.602ZM529.656 331.557V330.761H534.343V331.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 333.503V328.815H544.397V333.503H543.602ZM541.656 331.557V330.761H546.343V331.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 333.503V328.815H556.397V333.503H555.602ZM553.656 331.557V330.761H558.343V331.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 333.503V328.815H568.397V333.503H567.602ZM565.656 331.557V330.761H570.343V331.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 333.503V328.815H580.397V333.503H579.602ZM577.656 331.557V330.761H582.343V331.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 333.503V328.815H592.397V333.503H591.602ZM589.656 331.557V330.761H594.343V331.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 333.503V328.815H604.397V333.503H603.602ZM601.656 331.557V330.761H606.343V331.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 333.503V328.815H616.397V333.503H615.602ZM613.656 331.557V330.761H618.343V331.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 333.503V328.815H628.397V333.503H627.602ZM625.656 331.557V330.761H630.343V331.557H625.656Z" fill="#01256C"/>
+<path d="M639.602 333.503V328.815H640.397V333.503H639.602ZM637.656 331.557V330.761H642.343V331.557H637.656Z" fill="#01256C"/>
+<path d="M699.602 333.503V328.815H700.397V333.503H699.602ZM697.656 331.557V330.761H702.343V331.557H697.656Z" fill="#01256C"/>
+<path d="M711.602 333.503V328.815H712.397V333.503H711.602ZM709.656 331.557V330.761H714.343V331.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 333.503V328.815H724.397V333.503H723.602ZM721.656 331.557V330.761H726.343V331.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 333.503V328.815H736.397V333.503H735.602ZM733.656 331.557V330.761H738.343V331.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 333.503V328.815H748.397V333.503H747.602ZM745.656 331.557V330.761H750.343V331.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 333.503V328.815H760.397V333.503H759.602ZM757.656 331.557V330.761H762.343V331.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 333.503V328.815H772.397V333.503H771.602ZM769.656 331.557V330.761H774.343V331.557H769.656Z" fill="#01256C"/>
+<path d="M3.60183 345.503V340.815H4.39728V345.503H3.60183ZM1.65581 343.557V342.761H6.34331V343.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 345.503V340.815H16.3973V345.503H15.6018ZM13.6558 343.557V342.761H18.3433V343.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 345.503V340.815H28.3973V345.503H27.6018ZM25.6558 343.557V342.761H30.3433V343.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 345.503V340.815H40.3973V345.503H39.6018ZM37.6558 343.557V342.761H42.3433V343.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 345.503V340.815H52.3973V345.503H51.6018ZM49.6558 343.557V342.761H54.3433V343.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 345.503V340.815H64.3973V345.503H63.6018ZM61.6558 343.557V342.761H66.3433V343.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 345.503V340.815H76.3973V345.503H75.6018ZM73.6558 343.557V342.761H78.3433V343.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 345.503V340.815H88.3973V345.503H87.6018ZM85.6558 343.557V342.761H90.3433V343.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 345.503V340.815H100.397V345.503H99.6018ZM97.6558 343.557V342.761H102.343V343.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 345.503V340.815H112.397V345.503H111.602ZM109.656 343.557V342.761H114.343V343.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 345.503V340.815H124.397V345.503H123.602ZM121.656 343.557V342.761H126.343V343.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 345.503V340.815H136.397V345.503H135.602ZM133.656 343.557V342.761H138.343V343.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 345.503V340.815H148.397V345.503H147.602ZM145.656 343.557V342.761H150.343V343.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 345.503V340.815H160.397V345.503H159.602ZM157.656 343.557V342.761H162.343V343.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 345.503V340.815H172.397V345.503H171.602ZM169.656 343.557V342.761H174.343V343.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 345.503V340.815H184.397V345.503H183.602ZM181.656 343.557V342.761H186.343V343.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 345.503V340.815H196.397V345.503H195.602ZM193.656 343.557V342.761H198.343V343.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 345.503V340.815H208.397V345.503H207.602ZM205.656 343.557V342.761H210.343V343.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 345.503V340.815H220.397V345.503H219.602ZM217.656 343.557V342.761H222.343V343.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 345.503V340.815H232.397V345.503H231.602ZM229.656 343.557V342.761H234.343V343.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 345.503V340.815H244.397V345.503H243.602ZM241.656 343.557V342.761H246.343V343.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 345.503V340.815H256.397V345.503H255.602ZM253.656 343.557V342.761H258.343V343.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 345.503V340.815H268.397V345.503H267.602ZM265.656 343.557V342.761H270.343V343.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 345.503V340.815H280.397V345.503H279.602ZM277.656 343.557V342.761H282.343V343.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 345.503V340.815H292.397V345.503H291.602ZM289.656 343.557V342.761H294.343V343.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 345.503V340.815H304.397V345.503H303.602ZM301.656 343.557V342.761H306.343V343.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 345.503V340.815H316.397V345.503H315.602ZM313.656 343.557V342.761H318.343V343.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 345.503V340.815H328.397V345.503H327.602ZM325.656 343.557V342.761H330.343V343.557H325.656Z" fill="#01256C"/>
+<path d="M471.602 345.503V340.815H472.397V345.503H471.602ZM469.656 343.557V342.761H474.343V343.557H469.656Z" fill="#01256C"/>
+<path d="M483.602 345.503V340.815H484.397V345.503H483.602ZM481.656 343.557V342.761H486.343V343.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 345.503V340.815H496.397V345.503H495.602ZM493.656 343.557V342.761H498.343V343.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 345.503V340.815H508.397V345.503H507.602ZM505.656 343.557V342.761H510.343V343.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 345.503V340.815H520.397V345.503H519.602ZM517.656 343.557V342.761H522.343V343.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 345.503V340.815H532.397V345.503H531.602ZM529.656 343.557V342.761H534.343V343.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 345.503V340.815H544.397V345.503H543.602ZM541.656 343.557V342.761H546.343V343.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 345.503V340.815H556.397V345.503H555.602ZM553.656 343.557V342.761H558.343V343.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 345.503V340.815H568.397V345.503H567.602ZM565.656 343.557V342.761H570.343V343.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 345.503V340.815H580.397V345.503H579.602ZM577.656 343.557V342.761H582.343V343.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 345.503V340.815H592.397V345.503H591.602ZM589.656 343.557V342.761H594.343V343.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 345.503V340.815H604.397V345.503H603.602ZM601.656 343.557V342.761H606.343V343.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 345.503V340.815H616.397V345.503H615.602ZM613.656 343.557V342.761H618.343V343.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 345.503V340.815H628.397V345.503H627.602ZM625.656 343.557V342.761H630.343V343.557H625.656Z" fill="#01256C"/>
+<path d="M639.602 345.503V340.815H640.397V345.503H639.602ZM637.656 343.557V342.761H642.343V343.557H637.656Z" fill="#01256C"/>
+<path d="M699.602 345.503V340.815H700.397V345.503H699.602ZM697.656 343.557V342.761H702.343V343.557H697.656Z" fill="#01256C"/>
+<path d="M711.602 345.503V340.815H712.397V345.503H711.602ZM709.656 343.557V342.761H714.343V343.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 345.503V340.815H724.397V345.503H723.602ZM721.656 343.557V342.761H726.343V343.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 345.503V340.815H736.397V345.503H735.602ZM733.656 343.557V342.761H738.343V343.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 345.503V340.815H748.397V345.503H747.602ZM745.656 343.557V342.761H750.343V343.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 345.503V340.815H760.397V345.503H759.602ZM757.656 343.557V342.761H762.343V343.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 345.503V340.815H772.397V345.503H771.602ZM769.656 343.557V342.761H774.343V343.557H769.656Z" fill="#01256C"/>
+<path d="M3.60183 357.503V352.815H4.39728V357.503H3.60183ZM1.65581 355.557V354.761H6.34331V355.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 357.503V352.815H16.3973V357.503H15.6018ZM13.6558 355.557V354.761H18.3433V355.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 357.503V352.815H28.3973V357.503H27.6018ZM25.6558 355.557V354.761H30.3433V355.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 357.503V352.815H40.3973V357.503H39.6018ZM37.6558 355.557V354.761H42.3433V355.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 357.503V352.815H52.3973V357.503H51.6018ZM49.6558 355.557V354.761H54.3433V355.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 357.503V352.815H64.3973V357.503H63.6018ZM61.6558 355.557V354.761H66.3433V355.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 357.503V352.815H76.3973V357.503H75.6018ZM73.6558 355.557V354.761H78.3433V355.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 357.503V352.815H88.3973V357.503H87.6018ZM85.6558 355.557V354.761H90.3433V355.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 357.503V352.815H100.397V357.503H99.6018ZM97.6558 355.557V354.761H102.343V355.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 357.503V352.815H112.397V357.503H111.602ZM109.656 355.557V354.761H114.343V355.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 357.503V352.815H124.397V357.503H123.602ZM121.656 355.557V354.761H126.343V355.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 357.503V352.815H136.397V357.503H135.602ZM133.656 355.557V354.761H138.343V355.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 357.503V352.815H148.397V357.503H147.602ZM145.656 355.557V354.761H150.343V355.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 357.503V352.815H160.397V357.503H159.602ZM157.656 355.557V354.761H162.343V355.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 357.503V352.815H172.397V357.503H171.602ZM169.656 355.557V354.761H174.343V355.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 357.503V352.815H184.397V357.503H183.602ZM181.656 355.557V354.761H186.343V355.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 357.503V352.815H196.397V357.503H195.602ZM193.656 355.557V354.761H198.343V355.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 357.503V352.815H208.397V357.503H207.602ZM205.656 355.557V354.761H210.343V355.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 357.503V352.815H220.397V357.503H219.602ZM217.656 355.557V354.761H222.343V355.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 357.503V352.815H232.397V357.503H231.602ZM229.656 355.557V354.761H234.343V355.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 357.503V352.815H244.397V357.503H243.602ZM241.656 355.557V354.761H246.343V355.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 357.503V352.815H256.397V357.503H255.602ZM253.656 355.557V354.761H258.343V355.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 357.503V352.815H268.397V357.503H267.602ZM265.656 355.557V354.761H270.343V355.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 357.503V352.815H280.397V357.503H279.602ZM277.656 355.557V354.761H282.343V355.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 357.503V352.815H292.397V357.503H291.602ZM289.656 355.557V354.761H294.343V355.557H289.656Z" fill="#01256C"/>
+<path d="M483.602 357.503V352.815H484.397V357.503H483.602ZM481.656 355.557V354.761H486.343V355.557H481.656Z" fill="#01256C"/>
+<path d="M495.602 357.503V352.815H496.397V357.503H495.602ZM493.656 355.557V354.761H498.343V355.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 357.503V352.815H508.397V357.503H507.602ZM505.656 355.557V354.761H510.343V355.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 357.503V352.815H520.397V357.503H519.602ZM517.656 355.557V354.761H522.343V355.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 357.503V352.815H532.397V357.503H531.602ZM529.656 355.557V354.761H534.343V355.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 357.503V352.815H544.397V357.503H543.602ZM541.656 355.557V354.761H546.343V355.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 357.503V352.815H556.397V357.503H555.602ZM553.656 355.557V354.761H558.343V355.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 357.503V352.815H568.397V357.503H567.602ZM565.656 355.557V354.761H570.343V355.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 357.503V352.815H580.397V357.503H579.602ZM577.656 355.557V354.761H582.343V355.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 357.503V352.815H592.397V357.503H591.602ZM589.656 355.557V354.761H594.343V355.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 357.503V352.815H604.397V357.503H603.602ZM601.656 355.557V354.761H606.343V355.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 357.503V352.815H616.397V357.503H615.602ZM613.656 355.557V354.761H618.343V355.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 357.503V352.815H628.397V357.503H627.602ZM625.656 355.557V354.761H630.343V355.557H625.656Z" fill="#01256C"/>
+<path d="M639.602 357.503V352.815H640.397V357.503H639.602ZM637.656 355.557V354.761H642.343V355.557H637.656Z" fill="#01256C"/>
+<path d="M699.602 357.503V352.815H700.397V357.503H699.602ZM697.656 355.557V354.761H702.343V355.557H697.656Z" fill="#01256C"/>
+<path d="M711.602 357.503V352.815H712.397V357.503H711.602ZM709.656 355.557V354.761H714.343V355.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 357.503V352.815H724.397V357.503H723.602ZM721.656 355.557V354.761H726.343V355.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 357.503V352.815H736.397V357.503H735.602ZM733.656 355.557V354.761H738.343V355.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 357.503V352.815H748.397V357.503H747.602ZM745.656 355.557V354.761H750.343V355.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 357.503V352.815H760.397V357.503H759.602ZM757.656 355.557V354.761H762.343V355.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 357.503V352.815H772.397V357.503H771.602ZM769.656 355.557V354.761H774.343V355.557H769.656Z" fill="#01256C"/>
+<path d="M3.60183 369.503V364.815H4.39728V369.503H3.60183ZM1.65581 367.557V366.761H6.34331V367.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 369.503V364.815H16.3973V369.503H15.6018ZM13.6558 367.557V366.761H18.3433V367.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 369.503V364.815H28.3973V369.503H27.6018ZM25.6558 367.557V366.761H30.3433V367.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 369.503V364.815H40.3973V369.503H39.6018ZM37.6558 367.557V366.761H42.3433V367.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 369.503V364.815H52.3973V369.503H51.6018ZM49.6558 367.557V366.761H54.3433V367.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 369.503V364.815H64.3973V369.503H63.6018ZM61.6558 367.557V366.761H66.3433V367.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 369.503V364.815H76.3973V369.503H75.6018ZM73.6558 367.557V366.761H78.3433V367.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 369.503V364.815H88.3973V369.503H87.6018ZM85.6558 367.557V366.761H90.3433V367.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 369.503V364.815H100.397V369.503H99.6018ZM97.6558 367.557V366.761H102.343V367.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 369.503V364.815H112.397V369.503H111.602ZM109.656 367.557V366.761H114.343V367.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 369.503V364.815H124.397V369.503H123.602ZM121.656 367.557V366.761H126.343V367.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 369.503V364.815H136.397V369.503H135.602ZM133.656 367.557V366.761H138.343V367.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 369.503V364.815H148.397V369.503H147.602ZM145.656 367.557V366.761H150.343V367.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 369.503V364.815H160.397V369.503H159.602ZM157.656 367.557V366.761H162.343V367.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 369.503V364.815H172.397V369.503H171.602ZM169.656 367.557V366.761H174.343V367.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 369.503V364.815H184.397V369.503H183.602ZM181.656 367.557V366.761H186.343V367.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 369.503V364.815H196.397V369.503H195.602ZM193.656 367.557V366.761H198.343V367.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 369.503V364.815H208.397V369.503H207.602ZM205.656 367.557V366.761H210.343V367.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 369.503V364.815H220.397V369.503H219.602ZM217.656 367.557V366.761H222.343V367.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 369.503V364.815H232.397V369.503H231.602ZM229.656 367.557V366.761H234.343V367.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 369.503V364.815H244.397V369.503H243.602ZM241.656 367.557V366.761H246.343V367.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 369.503V364.815H256.397V369.503H255.602ZM253.656 367.557V366.761H258.343V367.557H253.656Z" fill="#01256C"/>
+<path d="M495.602 369.503V364.815H496.397V369.503H495.602ZM493.656 367.557V366.761H498.343V367.557H493.656Z" fill="#01256C"/>
+<path d="M507.602 369.503V364.815H508.397V369.503H507.602ZM505.656 367.557V366.761H510.343V367.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 369.503V364.815H520.397V369.503H519.602ZM517.656 367.557V366.761H522.343V367.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 369.503V364.815H532.397V369.503H531.602ZM529.656 367.557V366.761H534.343V367.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 369.503V364.815H544.397V369.503H543.602ZM541.656 367.557V366.761H546.343V367.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 369.503V364.815H556.397V369.503H555.602ZM553.656 367.557V366.761H558.343V367.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 369.503V364.815H568.397V369.503H567.602ZM565.656 367.557V366.761H570.343V367.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 369.503V364.815H580.397V369.503H579.602ZM577.656 367.557V366.761H582.343V367.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 369.503V364.815H592.397V369.503H591.602ZM589.656 367.557V366.761H594.343V367.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 369.503V364.815H604.397V369.503H603.602ZM601.656 367.557V366.761H606.343V367.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 369.503V364.815H616.397V369.503H615.602ZM613.656 367.557V366.761H618.343V367.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 369.503V364.815H628.397V369.503H627.602ZM625.656 367.557V366.761H630.343V367.557H625.656Z" fill="#01256C"/>
+<path d="M639.659 366.818L639.716 365.256L638.395 366.094L638.054 365.497L639.446 364.773L638.054 364.048L638.395 363.452L639.716 364.29L639.659 362.727H640.341L640.284 364.29L641.605 363.452L641.946 364.048L640.554 364.773L641.946 365.497L641.605 366.094L640.284 365.256L640.341 366.818H639.659Z" fill="#01256C"/>
+<path d="M699.602 369.503V364.815H700.397V369.503H699.602ZM697.656 367.557V366.761H702.343V367.557H697.656Z" fill="#01256C"/>
+<path d="M711.602 369.503V364.815H712.397V369.503H711.602ZM709.656 367.557V366.761H714.343V367.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 369.503V364.815H724.397V369.503H723.602ZM721.656 367.557V366.761H726.343V367.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 369.503V364.815H736.397V369.503H735.602ZM733.656 367.557V366.761H738.343V367.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 369.503V364.815H748.397V369.503H747.602ZM745.656 367.557V366.761H750.343V367.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 369.503V364.815H760.397V369.503H759.602ZM757.656 367.557V366.761H762.343V367.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 369.503V364.815H772.397V369.503H771.602ZM769.656 367.557V366.761H774.343V367.557H769.656Z" fill="#01256C"/>
+<path d="M784.001 370.057C783.826 370.057 783.675 369.994 783.55 369.869C783.424 369.743 783.362 369.593 783.362 369.418C783.362 369.242 783.424 369.092 783.55 368.967C783.675 368.841 783.826 368.778 784.001 368.778C784.176 368.778 784.326 368.841 784.452 368.967C784.577 369.092 784.64 369.242 784.64 369.418C784.64 369.534 784.61 369.64 784.551 369.737C784.494 369.834 784.418 369.912 784.32 369.972C784.226 370.028 784.119 370.057 784.001 370.057Z" fill="#01256C"/>
+<path d="M1035.6 369.503V364.815H1036.4V369.503H1035.6ZM1033.66 367.557V366.761H1038.34V367.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 369.503V364.815H1048.4V369.503H1047.6ZM1045.66 367.557V366.761H1050.34V367.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 369.503V364.815H1060.4V369.503H1059.6ZM1057.66 367.557V366.761H1062.34V367.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 369.503V364.815H1072.4V369.503H1071.6ZM1069.66 367.557V366.761H1074.34V367.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 369.503V364.815H1084.4V369.503H1083.6ZM1081.66 367.557V366.761H1086.34V367.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 369.503V364.815H1096.4V369.503H1095.6ZM1093.66 367.557V366.761H1098.34V367.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 369.503V364.815H1108.4V369.503H1107.6ZM1105.66 367.557V366.761H1110.34V367.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 369.503V364.815H1120.4V369.503H1119.6ZM1117.66 367.557V366.761H1122.34V367.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 369.503V364.815H1132.4V369.503H1131.6ZM1129.66 367.557V366.761H1134.34V367.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 369.503V364.815H1144.4V369.503H1143.6ZM1141.66 367.557V366.761H1146.34V367.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 369.503V364.815H1156.4V369.503H1155.6ZM1153.66 367.557V366.761H1158.34V367.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 381.503V376.815H4.39728V381.503H3.60183ZM1.65581 379.557V378.761H6.34331V379.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 381.503V376.815H16.3973V381.503H15.6018ZM13.6558 379.557V378.761H18.3433V379.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 381.503V376.815H28.3973V381.503H27.6018ZM25.6558 379.557V378.761H30.3433V379.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 381.503V376.815H40.3973V381.503H39.6018ZM37.6558 379.557V378.761H42.3433V379.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 381.503V376.815H52.3973V381.503H51.6018ZM49.6558 379.557V378.761H54.3433V379.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 381.503V376.815H64.3973V381.503H63.6018ZM61.6558 379.557V378.761H66.3433V379.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 381.503V376.815H76.3973V381.503H75.6018ZM73.6558 379.557V378.761H78.3433V379.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 381.503V376.815H88.3973V381.503H87.6018ZM85.6558 379.557V378.761H90.3433V379.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 381.503V376.815H100.397V381.503H99.6018ZM97.6558 379.557V378.761H102.343V379.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 381.503V376.815H112.397V381.503H111.602ZM109.656 379.557V378.761H114.343V379.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 381.503V376.815H124.397V381.503H123.602ZM121.656 379.557V378.761H126.343V379.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 381.503V376.815H136.397V381.503H135.602ZM133.656 379.557V378.761H138.343V379.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 381.503V376.815H148.397V381.503H147.602ZM145.656 379.557V378.761H150.343V379.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 381.503V376.815H160.397V381.503H159.602ZM157.656 379.557V378.761H162.343V379.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 381.503V376.815H172.397V381.503H171.602ZM169.656 379.557V378.761H174.343V379.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 381.503V376.815H184.397V381.503H183.602ZM181.656 379.557V378.761H186.343V379.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 381.503V376.815H196.397V381.503H195.602ZM193.656 379.557V378.761H198.343V379.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 381.503V376.815H208.397V381.503H207.602ZM205.656 379.557V378.761H210.343V379.557H205.656Z" fill="#01256C"/>
+<path d="M220.001 382.057C219.826 382.057 219.675 381.994 219.55 381.869C219.424 381.743 219.362 381.593 219.362 381.418C219.362 381.242 219.424 381.092 219.55 380.967C219.675 380.841 219.826 380.778 220.001 380.778C220.176 380.778 220.326 380.841 220.452 380.967C220.577 381.092 220.64 381.242 220.64 381.418C220.64 381.534 220.61 381.64 220.551 381.737C220.494 381.834 220.418 381.912 220.32 381.972C220.226 382.028 220.119 382.057 220.001 382.057ZM220.001 378.009C219.826 378.009 219.675 377.946 219.55 377.82C219.424 377.695 219.362 377.545 219.362 377.369C219.362 377.194 219.424 377.044 219.55 376.918C219.675 376.793 219.826 376.73 220.001 376.73C220.176 376.73 220.326 376.793 220.452 376.918C220.577 377.044 220.64 377.194 220.64 377.369C220.64 377.485 220.61 377.592 220.551 377.689C220.494 377.786 220.418 377.864 220.32 377.923C220.226 377.98 220.119 378.009 220.001 378.009Z" fill="#01256C"/>
+<path d="M507.602 381.503V376.815H508.397V381.503H507.602ZM505.656 379.557V378.761H510.343V379.557H505.656Z" fill="#01256C"/>
+<path d="M519.602 381.503V376.815H520.397V381.503H519.602ZM517.656 379.557V378.761H522.343V379.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 381.503V376.815H532.397V381.503H531.602ZM529.656 379.557V378.761H534.343V379.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 381.503V376.815H544.397V381.503H543.602ZM541.656 379.557V378.761H546.343V379.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 381.503V376.815H556.397V381.503H555.602ZM553.656 379.557V378.761H558.343V379.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 381.503V376.815H568.397V381.503H567.602ZM565.656 379.557V378.761H570.343V379.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 381.503V376.815H580.397V381.503H579.602ZM577.656 379.557V378.761H582.343V379.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 381.503V376.815H592.397V381.503H591.602ZM589.656 379.557V378.761H594.343V379.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 381.503V376.815H604.397V381.503H603.602ZM601.656 379.557V378.761H606.343V379.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 381.503V376.815H616.397V381.503H615.602ZM613.656 379.557V378.761H618.343V379.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 381.503V376.815H628.397V381.503H627.602ZM625.656 379.557V378.761H630.343V379.557H625.656Z" fill="#01256C"/>
+<path d="M699.602 381.503V376.815H700.397V381.503H699.602ZM697.656 379.557V378.761H702.343V379.557H697.656Z" fill="#01256C"/>
+<path d="M711.602 381.503V376.815H712.397V381.503H711.602ZM709.656 379.557V378.761H714.343V379.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 381.503V376.815H724.397V381.503H723.602ZM721.656 379.557V378.761H726.343V379.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 381.503V376.815H736.397V381.503H735.602ZM733.656 379.557V378.761H738.343V379.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 381.503V376.815H748.397V381.503H747.602ZM745.656 379.557V378.761H750.343V379.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 381.503V376.815H760.397V381.503H759.602ZM757.656 379.557V378.761H762.343V379.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 381.503V376.815H772.397V381.503H771.602ZM769.656 379.557V378.761H774.343V379.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 381.503V376.815H784.397V381.503H783.602ZM781.656 379.557V378.761H786.343V379.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 381.503V376.815H796.397V381.503H795.602ZM793.656 379.557V378.761H798.343V379.557H793.656Z" fill="#01256C"/>
+<path d="M951.602 381.503V376.815H952.397V381.503H951.602ZM949.656 379.557V378.761H954.343V379.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 381.503V376.815H964.397V381.503H963.602ZM961.656 379.557V378.761H966.343V379.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 381.503V376.815H976.397V381.503H975.602ZM973.656 379.557V378.761H978.343V379.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 381.503V376.815H988.397V381.503H987.602ZM985.656 379.557V378.761H990.343V379.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 381.503V376.815H1000.4V381.503H999.602ZM997.656 379.557V378.761H1002.34V379.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 381.503V376.815H1012.4V381.503H1011.6ZM1009.66 379.557V378.761H1014.34V379.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 381.503V376.815H1024.4V381.503H1023.6ZM1021.66 379.557V378.761H1026.34V379.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 381.503V376.815H1036.4V381.503H1035.6ZM1033.66 379.557V378.761H1038.34V379.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 381.503V376.815H1048.4V381.503H1047.6ZM1045.66 379.557V378.761H1050.34V379.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 381.503V376.815H1060.4V381.503H1059.6ZM1057.66 379.557V378.761H1062.34V379.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 381.503V376.815H1072.4V381.503H1071.6ZM1069.66 379.557V378.761H1074.34V379.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 381.503V376.815H1084.4V381.503H1083.6ZM1081.66 379.557V378.761H1086.34V379.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 381.503V376.815H1096.4V381.503H1095.6ZM1093.66 379.557V378.761H1098.34V379.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 381.503V376.815H1108.4V381.503H1107.6ZM1105.66 379.557V378.761H1110.34V379.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 381.503V376.815H1120.4V381.503H1119.6ZM1117.66 379.557V378.761H1122.34V379.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 381.503V376.815H1132.4V381.503H1131.6ZM1129.66 379.557V378.761H1134.34V379.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 381.503V376.815H1144.4V381.503H1143.6ZM1141.66 379.557V378.761H1146.34V379.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 381.503V376.815H1156.4V381.503H1155.6ZM1153.66 379.557V378.761H1158.34V379.557H1153.66Z" fill="#01256C"/>
+<path d="M15.6018 393.503V388.815H16.3973V393.503H15.6018ZM13.6558 391.557V390.761H18.3433V391.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 393.503V388.815H28.3973V393.503H27.6018ZM25.6558 391.557V390.761H30.3433V391.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 393.503V388.815H40.3973V393.503H39.6018ZM37.6558 391.557V390.761H42.3433V391.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 393.503V388.815H52.3973V393.503H51.6018ZM49.6558 391.557V390.761H54.3433V391.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 393.503V388.815H64.3973V393.503H63.6018ZM61.6558 391.557V390.761H66.3433V391.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 393.503V388.815H76.3973V393.503H75.6018ZM73.6558 391.557V390.761H78.3433V391.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 393.503V388.815H88.3973V393.503H87.6018ZM85.6558 391.557V390.761H90.3433V391.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 393.503V388.815H100.397V393.503H99.6018ZM97.6558 391.557V390.761H102.343V391.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 393.503V388.815H112.397V393.503H111.602ZM109.656 391.557V390.761H114.343V391.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 393.503V388.815H124.397V393.503H123.602ZM121.656 391.557V390.761H126.343V391.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 393.503V388.815H136.397V393.503H135.602ZM133.656 391.557V390.761H138.343V391.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 393.503V388.815H148.397V393.503H147.602ZM145.656 391.557V390.761H150.343V391.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 393.503V388.815H160.397V393.503H159.602ZM157.656 391.557V390.761H162.343V391.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 393.503V388.815H172.397V393.503H171.602ZM169.656 391.557V390.761H174.343V391.557H169.656Z" fill="#01256C"/>
+<path d="M507.659 390.818L507.716 389.256L506.395 390.094L506.054 389.497L507.446 388.773L506.054 388.048L506.395 387.452L507.716 388.29L507.659 386.727H508.341L508.284 388.29L509.605 387.452L509.946 388.048L508.554 388.773L509.946 389.497L509.605 390.094L508.284 389.256L508.341 390.818H507.659Z" fill="#01256C"/>
+<path d="M519.602 393.503V388.815H520.397V393.503H519.602ZM517.656 391.557V390.761H522.343V391.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 393.503V388.815H532.397V393.503H531.602ZM529.656 391.557V390.761H534.343V391.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 393.503V388.815H544.397V393.503H543.602ZM541.656 391.557V390.761H546.343V391.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 393.503V388.815H556.397V393.503H555.602ZM553.656 391.557V390.761H558.343V391.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 393.503V388.815H568.397V393.503H567.602ZM565.656 391.557V390.761H570.343V391.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 393.503V388.815H580.397V393.503H579.602ZM577.656 391.557V390.761H582.343V391.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 393.503V388.815H592.397V393.503H591.602ZM589.656 391.557V390.761H594.343V391.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 393.503V388.815H604.397V393.503H603.602ZM601.656 391.557V390.761H606.343V391.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 393.503V388.815H616.397V393.503H615.602ZM613.656 391.557V390.761H618.343V391.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 393.503V388.815H628.397V393.503H627.602ZM625.656 391.557V390.761H630.343V391.557H625.656Z" fill="#01256C"/>
+<path d="M687.602 393.503V388.815H688.397V393.503H687.602ZM685.656 391.557V390.761H690.343V391.557H685.656Z" fill="#01256C"/>
+<path d="M699.602 393.503V388.815H700.397V393.503H699.602ZM697.656 391.557V390.761H702.343V391.557H697.656Z" fill="#01256C"/>
+<path d="M711.602 393.503V388.815H712.397V393.503H711.602ZM709.656 391.557V390.761H714.343V391.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 393.503V388.815H724.397V393.503H723.602ZM721.656 391.557V390.761H726.343V391.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 393.503V388.815H736.397V393.503H735.602ZM733.656 391.557V390.761H738.343V391.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 393.503V388.815H748.397V393.503H747.602ZM745.656 391.557V390.761H750.343V391.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 393.503V388.815H760.397V393.503H759.602ZM757.656 391.557V390.761H762.343V391.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 393.503V388.815H772.397V393.503H771.602ZM769.656 391.557V390.761H774.343V391.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 393.503V388.815H784.397V393.503H783.602ZM781.656 391.557V390.761H786.343V391.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 393.503V388.815H796.397V393.503H795.602ZM793.656 391.557V390.761H798.343V391.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 393.503V388.815H808.397V393.503H807.602ZM805.656 391.557V390.761H810.343V391.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 393.503V388.815H820.397V393.503H819.602ZM817.656 391.557V390.761H822.343V391.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 393.503V388.815H832.397V393.503H831.602ZM829.656 391.557V390.761H834.343V391.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 393.503V388.815H844.397V393.503H843.602ZM841.656 391.557V390.761H846.343V391.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 393.503V388.815H856.397V393.503H855.602ZM853.656 391.557V390.761H858.343V391.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 393.503V388.815H868.397V393.503H867.602ZM865.656 391.557V390.761H870.343V391.557H865.656Z" fill="#01256C"/>
+<path d="M879.602 393.503V388.815H880.397V393.503H879.602ZM877.656 391.557V390.761H882.343V391.557H877.656Z" fill="#01256C"/>
+<path d="M891.602 393.503V388.815H892.397V393.503H891.602ZM889.656 391.557V390.761H894.343V391.557H889.656Z" fill="#01256C"/>
+<path d="M903.602 393.503V388.815H904.397V393.503H903.602ZM901.656 391.557V390.761H906.343V391.557H901.656Z" fill="#01256C"/>
+<path d="M915.602 393.503V388.815H916.397V393.503H915.602ZM913.656 391.557V390.761H918.343V391.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 393.503V388.815H928.397V393.503H927.602ZM925.656 391.557V390.761H930.343V391.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 393.503V388.815H940.397V393.503H939.602ZM937.656 391.557V390.761H942.343V391.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 393.503V388.815H952.397V393.503H951.602ZM949.656 391.557V390.761H954.343V391.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 393.503V388.815H964.397V393.503H963.602ZM961.656 391.557V390.761H966.343V391.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 393.503V388.815H976.397V393.503H975.602ZM973.656 391.557V390.761H978.343V391.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 393.503V388.815H988.397V393.503H987.602ZM985.656 391.557V390.761H990.343V391.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 393.503V388.815H1000.4V393.503H999.602ZM997.656 391.557V390.761H1002.34V391.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 393.503V388.815H1012.4V393.503H1011.6ZM1009.66 391.557V390.761H1014.34V391.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 393.503V388.815H1024.4V393.503H1023.6ZM1021.66 391.557V390.761H1026.34V391.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 393.503V388.815H1036.4V393.503H1035.6ZM1033.66 391.557V390.761H1038.34V391.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 393.503V388.815H1048.4V393.503H1047.6ZM1045.66 391.557V390.761H1050.34V391.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 393.503V388.815H1060.4V393.503H1059.6ZM1057.66 391.557V390.761H1062.34V391.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 393.503V388.815H1072.4V393.503H1071.6ZM1069.66 391.557V390.761H1074.34V391.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 393.503V388.815H1084.4V393.503H1083.6ZM1081.66 391.557V390.761H1086.34V391.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 393.503V388.815H1096.4V393.503H1095.6ZM1093.66 391.557V390.761H1098.34V391.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 393.503V388.815H1108.4V393.503H1107.6ZM1105.66 391.557V390.761H1110.34V391.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 393.503V388.815H1120.4V393.503H1119.6ZM1117.66 391.557V390.761H1122.34V391.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 393.503V388.815H1132.4V393.503H1131.6ZM1129.66 391.557V390.761H1134.34V391.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 393.503V388.815H1144.4V393.503H1143.6ZM1141.66 391.557V390.761H1146.34V391.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 393.503V388.815H1156.4V393.503H1155.6ZM1153.66 391.557V390.761H1158.34V391.557H1153.66Z" fill="#01256C"/>
+<path d="M519.602 405.503V400.815H520.397V405.503H519.602ZM517.656 403.557V402.761H522.343V403.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 405.503V400.815H532.397V405.503H531.602ZM529.656 403.557V402.761H534.343V403.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 405.503V400.815H544.397V405.503H543.602ZM541.656 403.557V402.761H546.343V403.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 405.503V400.815H556.397V405.503H555.602ZM553.656 403.557V402.761H558.343V403.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 405.503V400.815H568.397V405.503H567.602ZM565.656 403.557V402.761H570.343V403.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 405.503V400.815H580.397V405.503H579.602ZM577.656 403.557V402.761H582.343V403.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 405.503V400.815H592.397V405.503H591.602ZM589.656 403.557V402.761H594.343V403.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 405.503V400.815H604.397V405.503H603.602ZM601.656 403.557V402.761H606.343V403.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 405.503V400.815H616.397V405.503H615.602ZM613.656 403.557V402.761H618.343V403.557H613.656Z" fill="#01256C"/>
+<path d="M627.602 405.503V400.815H628.397V405.503H627.602ZM625.656 403.557V402.761H630.343V403.557H625.656Z" fill="#01256C"/>
+<path d="M687.602 405.503V400.815H688.397V405.503H687.602ZM685.656 403.557V402.761H690.343V403.557H685.656Z" fill="#01256C"/>
+<path d="M699.602 405.503V400.815H700.397V405.503H699.602ZM697.656 403.557V402.761H702.343V403.557H697.656Z" fill="#01256C"/>
+<path d="M711.602 405.503V400.815H712.397V405.503H711.602ZM709.656 403.557V402.761H714.343V403.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 405.503V400.815H724.397V405.503H723.602ZM721.656 403.557V402.761H726.343V403.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 405.503V400.815H736.397V405.503H735.602ZM733.656 403.557V402.761H738.343V403.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 405.503V400.815H748.397V405.503H747.602ZM745.656 403.557V402.761H750.343V403.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 405.503V400.815H760.397V405.503H759.602ZM757.656 403.557V402.761H762.343V403.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 405.503V400.815H772.397V405.503H771.602ZM769.656 403.557V402.761H774.343V403.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 405.503V400.815H784.397V405.503H783.602ZM781.656 403.557V402.761H786.343V403.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 405.503V400.815H796.397V405.503H795.602ZM793.656 403.557V402.761H798.343V403.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 405.503V400.815H808.397V405.503H807.602ZM805.656 403.557V402.761H810.343V403.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 405.503V400.815H820.397V405.503H819.602ZM817.656 403.557V402.761H822.343V403.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 405.503V400.815H832.397V405.503H831.602ZM829.656 403.557V402.761H834.343V403.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 405.503V400.815H844.397V405.503H843.602ZM841.656 403.557V402.761H846.343V403.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 405.503V400.815H856.397V405.503H855.602ZM853.656 403.557V402.761H858.343V403.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 405.503V400.815H868.397V405.503H867.602ZM865.656 403.557V402.761H870.343V403.557H865.656Z" fill="#01256C"/>
+<path d="M879.602 405.503V400.815H880.397V405.503H879.602ZM877.656 403.557V402.761H882.343V403.557H877.656Z" fill="#01256C"/>
+<path d="M891.602 405.503V400.815H892.397V405.503H891.602ZM889.656 403.557V402.761H894.343V403.557H889.656Z" fill="#01256C"/>
+<path d="M903.602 405.503V400.815H904.397V405.503H903.602ZM901.656 403.557V402.761H906.343V403.557H901.656Z" fill="#01256C"/>
+<path d="M915.602 405.503V400.815H916.397V405.503H915.602ZM913.656 403.557V402.761H918.343V403.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 405.503V400.815H928.397V405.503H927.602ZM925.656 403.557V402.761H930.343V403.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 405.503V400.815H940.397V405.503H939.602ZM937.656 403.557V402.761H942.343V403.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 405.503V400.815H952.397V405.503H951.602ZM949.656 403.557V402.761H954.343V403.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 405.503V400.815H964.397V405.503H963.602ZM961.656 403.557V402.761H966.343V403.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 405.503V400.815H976.397V405.503H975.602ZM973.656 403.557V402.761H978.343V403.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 405.503V400.815H988.397V405.503H987.602ZM985.656 403.557V402.761H990.343V403.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 405.503V400.815H1000.4V405.503H999.602ZM997.656 403.557V402.761H1002.34V403.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 405.503V400.815H1012.4V405.503H1011.6ZM1009.66 403.557V402.761H1014.34V403.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 405.503V400.815H1024.4V405.503H1023.6ZM1021.66 403.557V402.761H1026.34V403.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 405.503V400.815H1036.4V405.503H1035.6ZM1033.66 403.557V402.761H1038.34V403.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 405.503V400.815H1048.4V405.503H1047.6ZM1045.66 403.557V402.761H1050.34V403.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 405.503V400.815H1060.4V405.503H1059.6ZM1057.66 403.557V402.761H1062.34V403.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 405.503V400.815H1072.4V405.503H1071.6ZM1069.66 403.557V402.761H1074.34V403.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 405.503V400.815H1084.4V405.503H1083.6ZM1081.66 403.557V402.761H1086.34V403.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 405.503V400.815H1096.4V405.503H1095.6ZM1093.66 403.557V402.761H1098.34V403.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 405.503V400.815H1108.4V405.503H1107.6ZM1105.66 403.557V402.761H1110.34V403.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 405.503V400.815H1120.4V405.503H1119.6ZM1117.66 403.557V402.761H1122.34V403.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 405.503V400.815H1132.4V405.503H1131.6ZM1129.66 403.557V402.761H1134.34V403.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 405.503V400.815H1144.4V405.503H1143.6ZM1141.66 403.557V402.761H1146.34V403.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 405.503V400.815H1156.4V405.503H1155.6ZM1153.66 403.557V402.761H1158.34V403.557H1153.66Z" fill="#01256C"/>
+<path d="M519.602 417.503V412.815H520.397V417.503H519.602ZM517.656 415.557V414.761H522.343V415.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 417.503V412.815H532.397V417.503H531.602ZM529.656 415.557V414.761H534.343V415.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 417.503V412.815H544.397V417.503H543.602ZM541.656 415.557V414.761H546.343V415.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 417.503V412.815H556.397V417.503H555.602ZM553.656 415.557V414.761H558.343V415.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 417.503V412.815H568.397V417.503H567.602ZM565.656 415.557V414.761H570.343V415.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 417.503V412.815H580.397V417.503H579.602ZM577.656 415.557V414.761H582.343V415.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 417.503V412.815H592.397V417.503H591.602ZM589.656 415.557V414.761H594.343V415.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 417.503V412.815H604.397V417.503H603.602ZM601.656 415.557V414.761H606.343V415.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 417.503V412.815H616.397V417.503H615.602ZM613.656 415.557V414.761H618.343V415.557H613.656Z" fill="#01256C"/>
+<path d="M687.602 417.503V412.815H688.397V417.503H687.602ZM685.656 415.557V414.761H690.343V415.557H685.656Z" fill="#01256C"/>
+<path d="M699.602 417.503V412.815H700.397V417.503H699.602ZM697.656 415.557V414.761H702.343V415.557H697.656Z" fill="#01256C"/>
+<path d="M711.602 417.503V412.815H712.397V417.503H711.602ZM709.656 415.557V414.761H714.343V415.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 417.503V412.815H724.397V417.503H723.602ZM721.656 415.557V414.761H726.343V415.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 417.503V412.815H736.397V417.503H735.602ZM733.656 415.557V414.761H738.343V415.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 417.503V412.815H748.397V417.503H747.602ZM745.656 415.557V414.761H750.343V415.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 417.503V412.815H760.397V417.503H759.602ZM757.656 415.557V414.761H762.343V415.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 417.503V412.815H772.397V417.503H771.602ZM769.656 415.557V414.761H774.343V415.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 417.503V412.815H784.397V417.503H783.602ZM781.656 415.557V414.761H786.343V415.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 417.503V412.815H796.397V417.503H795.602ZM793.656 415.557V414.761H798.343V415.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 417.503V412.815H808.397V417.503H807.602ZM805.656 415.557V414.761H810.343V415.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 417.503V412.815H820.397V417.503H819.602ZM817.656 415.557V414.761H822.343V415.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 417.503V412.815H832.397V417.503H831.602ZM829.656 415.557V414.761H834.343V415.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 417.503V412.815H844.397V417.503H843.602ZM841.656 415.557V414.761H846.343V415.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 417.503V412.815H856.397V417.503H855.602ZM853.656 415.557V414.761H858.343V415.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 417.503V412.815H868.397V417.503H867.602ZM865.656 415.557V414.761H870.343V415.557H865.656Z" fill="#01256C"/>
+<path d="M879.602 417.503V412.815H880.397V417.503H879.602ZM877.656 415.557V414.761H882.343V415.557H877.656Z" fill="#01256C"/>
+<path d="M891.602 417.503V412.815H892.397V417.503H891.602ZM889.656 415.557V414.761H894.343V415.557H889.656Z" fill="#01256C"/>
+<path d="M903.602 417.503V412.815H904.397V417.503H903.602ZM901.656 415.557V414.761H906.343V415.557H901.656Z" fill="#01256C"/>
+<path d="M915.602 417.503V412.815H916.397V417.503H915.602ZM913.656 415.557V414.761H918.343V415.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 417.503V412.815H928.397V417.503H927.602ZM925.656 415.557V414.761H930.343V415.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 417.503V412.815H940.397V417.503H939.602ZM937.656 415.557V414.761H942.343V415.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 417.503V412.815H952.397V417.503H951.602ZM949.656 415.557V414.761H954.343V415.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 417.503V412.815H964.397V417.503H963.602ZM961.656 415.557V414.761H966.343V415.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 417.503V412.815H976.397V417.503H975.602ZM973.656 415.557V414.761H978.343V415.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 417.503V412.815H988.397V417.503H987.602ZM985.656 415.557V414.761H990.343V415.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 417.503V412.815H1000.4V417.503H999.602ZM997.656 415.557V414.761H1002.34V415.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 417.503V412.815H1012.4V417.503H1011.6ZM1009.66 415.557V414.761H1014.34V415.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 417.503V412.815H1024.4V417.503H1023.6ZM1021.66 415.557V414.761H1026.34V415.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 417.503V412.815H1036.4V417.503H1035.6ZM1033.66 415.557V414.761H1038.34V415.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 417.503V412.815H1048.4V417.503H1047.6ZM1045.66 415.557V414.761H1050.34V415.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 417.503V412.815H1060.4V417.503H1059.6ZM1057.66 415.557V414.761H1062.34V415.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 417.503V412.815H1072.4V417.503H1071.6ZM1069.66 415.557V414.761H1074.34V415.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 417.503V412.815H1084.4V417.503H1083.6ZM1081.66 415.557V414.761H1086.34V415.557H1081.66Z" fill="#01256C"/>
+<path d="M519.602 429.503V424.815H520.397V429.503H519.602ZM517.656 427.557V426.761H522.343V427.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 429.503V424.815H532.397V429.503H531.602ZM529.656 427.557V426.761H534.343V427.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 429.503V424.815H544.397V429.503H543.602ZM541.656 427.557V426.761H546.343V427.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 429.503V424.815H556.397V429.503H555.602ZM553.656 427.557V426.761H558.343V427.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 429.503V424.815H568.397V429.503H567.602ZM565.656 427.557V426.761H570.343V427.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 429.503V424.815H580.397V429.503H579.602ZM577.656 427.557V426.761H582.343V427.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 429.503V424.815H592.397V429.503H591.602ZM589.656 427.557V426.761H594.343V427.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 429.503V424.815H604.397V429.503H603.602ZM601.656 427.557V426.761H606.343V427.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 429.503V424.815H616.397V429.503H615.602ZM613.656 427.557V426.761H618.343V427.557H613.656Z" fill="#01256C"/>
+<path d="M687.602 429.503V424.815H688.397V429.503H687.602ZM685.656 427.557V426.761H690.343V427.557H685.656Z" fill="#01256C"/>
+<path d="M699.602 429.503V424.815H700.397V429.503H699.602ZM697.656 427.557V426.761H702.343V427.557H697.656Z" fill="#01256C"/>
+<path d="M711.602 429.503V424.815H712.397V429.503H711.602ZM709.656 427.557V426.761H714.343V427.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 429.503V424.815H724.397V429.503H723.602ZM721.656 427.557V426.761H726.343V427.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 429.503V424.815H736.397V429.503H735.602ZM733.656 427.557V426.761H738.343V427.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 429.503V424.815H748.397V429.503H747.602ZM745.656 427.557V426.761H750.343V427.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 429.503V424.815H760.397V429.503H759.602ZM757.656 427.557V426.761H762.343V427.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 429.503V424.815H772.397V429.503H771.602ZM769.656 427.557V426.761H774.343V427.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 429.503V424.815H784.397V429.503H783.602ZM781.656 427.557V426.761H786.343V427.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 429.503V424.815H796.397V429.503H795.602ZM793.656 427.557V426.761H798.343V427.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 429.503V424.815H808.397V429.503H807.602ZM805.656 427.557V426.761H810.343V427.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 429.503V424.815H820.397V429.503H819.602ZM817.656 427.557V426.761H822.343V427.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 429.503V424.815H832.397V429.503H831.602ZM829.656 427.557V426.761H834.343V427.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 429.503V424.815H844.397V429.503H843.602ZM841.656 427.557V426.761H846.343V427.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 429.503V424.815H856.397V429.503H855.602ZM853.656 427.557V426.761H858.343V427.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 429.503V424.815H868.397V429.503H867.602ZM865.656 427.557V426.761H870.343V427.557H865.656Z" fill="#01256C"/>
+<path d="M879.602 429.503V424.815H880.397V429.503H879.602ZM877.656 427.557V426.761H882.343V427.557H877.656Z" fill="#01256C"/>
+<path d="M891.602 429.503V424.815H892.397V429.503H891.602ZM889.656 427.557V426.761H894.343V427.557H889.656Z" fill="#01256C"/>
+<path d="M903.602 429.503V424.815H904.397V429.503H903.602ZM901.656 427.557V426.761H906.343V427.557H901.656Z" fill="#01256C"/>
+<path d="M915.602 429.503V424.815H916.397V429.503H915.602ZM913.656 427.557V426.761H918.343V427.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 429.503V424.815H928.397V429.503H927.602ZM925.656 427.557V426.761H930.343V427.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 429.503V424.815H940.397V429.503H939.602ZM937.656 427.557V426.761H942.343V427.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 429.503V424.815H952.397V429.503H951.602ZM949.656 427.557V426.761H954.343V427.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 429.503V424.815H964.397V429.503H963.602ZM961.656 427.557V426.761H966.343V427.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 429.503V424.815H976.397V429.503H975.602ZM973.656 427.557V426.761H978.343V427.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 429.503V424.815H988.397V429.503H987.602ZM985.656 427.557V426.761H990.343V427.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 429.503V424.815H1000.4V429.503H999.602ZM997.656 427.557V426.761H1002.34V427.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 429.503V424.815H1012.4V429.503H1011.6ZM1009.66 427.557V426.761H1014.34V427.557H1009.66Z" fill="#01256C"/>
+<path d="M255.602 441.503V436.815H256.397V441.503H255.602ZM253.656 439.557V438.761H258.343V439.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 441.503V436.815H268.397V441.503H267.602ZM265.656 439.557V438.761H270.343V439.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 441.503V436.815H280.397V441.503H279.602ZM277.656 439.557V438.761H282.343V439.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 441.503V436.815H292.397V441.503H291.602ZM289.656 439.557V438.761H294.343V439.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 441.503V436.815H304.397V441.503H303.602ZM301.656 439.557V438.761H306.343V439.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 441.503V436.815H316.397V441.503H315.602ZM313.656 439.557V438.761H318.343V439.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 441.503V436.815H328.397V441.503H327.602ZM325.656 439.557V438.761H330.343V439.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 441.503V436.815H340.397V441.503H339.602ZM337.656 439.557V438.761H342.343V439.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 441.503V436.815H352.397V441.503H351.602ZM349.656 439.557V438.761H354.343V439.557H349.656Z" fill="#01256C"/>
+<path d="M519.602 441.503V436.815H520.397V441.503H519.602ZM517.656 439.557V438.761H522.343V439.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 441.503V436.815H532.397V441.503H531.602ZM529.656 439.557V438.761H534.343V439.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 441.503V436.815H544.397V441.503H543.602ZM541.656 439.557V438.761H546.343V439.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 441.503V436.815H556.397V441.503H555.602ZM553.656 439.557V438.761H558.343V439.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 441.503V436.815H568.397V441.503H567.602ZM565.656 439.557V438.761H570.343V439.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 441.503V436.815H580.397V441.503H579.602ZM577.656 439.557V438.761H582.343V439.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 441.503V436.815H592.397V441.503H591.602ZM589.656 439.557V438.761H594.343V439.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 441.503V436.815H604.397V441.503H603.602ZM601.656 439.557V438.761H606.343V439.557H601.656Z" fill="#01256C"/>
+<path d="M615.602 441.503V436.815H616.397V441.503H615.602ZM613.656 439.557V438.761H618.343V439.557H613.656Z" fill="#01256C"/>
+<path d="M699.602 441.503V436.815H700.397V441.503H699.602ZM697.656 439.557V438.761H702.343V439.557H697.656Z" fill="#01256C"/>
+<path d="M711.602 441.503V436.815H712.397V441.503H711.602ZM709.656 439.557V438.761H714.343V439.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 441.503V436.815H724.397V441.503H723.602ZM721.656 439.557V438.761H726.343V439.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 441.503V436.815H736.397V441.503H735.602ZM733.656 439.557V438.761H738.343V439.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 441.503V436.815H748.397V441.503H747.602ZM745.656 439.557V438.761H750.343V439.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 441.503V436.815H760.397V441.503H759.602ZM757.656 439.557V438.761H762.343V439.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 441.503V436.815H772.397V441.503H771.602ZM769.656 439.557V438.761H774.343V439.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 441.503V436.815H784.397V441.503H783.602ZM781.656 439.557V438.761H786.343V439.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 441.503V436.815H796.397V441.503H795.602ZM793.656 439.557V438.761H798.343V439.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 441.503V436.815H808.397V441.503H807.602ZM805.656 439.557V438.761H810.343V439.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 441.503V436.815H820.397V441.503H819.602ZM817.656 439.557V438.761H822.343V439.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 441.503V436.815H832.397V441.503H831.602ZM829.656 439.557V438.761H834.343V439.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 441.503V436.815H844.397V441.503H843.602ZM841.656 439.557V438.761H846.343V439.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 441.503V436.815H856.397V441.503H855.602ZM853.656 439.557V438.761H858.343V439.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 441.503V436.815H868.397V441.503H867.602ZM865.656 439.557V438.761H870.343V439.557H865.656Z" fill="#01256C"/>
+<path d="M879.602 441.503V436.815H880.397V441.503H879.602ZM877.656 439.557V438.761H882.343V439.557H877.656Z" fill="#01256C"/>
+<path d="M891.602 441.503V436.815H892.397V441.503H891.602ZM889.656 439.557V438.761H894.343V439.557H889.656Z" fill="#01256C"/>
+<path d="M903.602 441.503V436.815H904.397V441.503H903.602ZM901.656 439.557V438.761H906.343V439.557H901.656Z" fill="#01256C"/>
+<path d="M915.602 441.503V436.815H916.397V441.503H915.602ZM913.656 439.557V438.761H918.343V439.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 441.503V436.815H928.397V441.503H927.602ZM925.656 439.557V438.761H930.343V439.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 441.503V436.815H940.397V441.503H939.602ZM937.656 439.557V438.761H942.343V439.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 441.503V436.815H952.397V441.503H951.602ZM949.656 439.557V438.761H954.343V439.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 441.503V436.815H964.397V441.503H963.602ZM961.656 439.557V438.761H966.343V439.557H961.656Z" fill="#01256C"/>
+<path d="M207.602 453.503V448.815H208.397V453.503H207.602ZM205.656 451.557V450.761H210.343V451.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 453.503V448.815H220.397V453.503H219.602ZM217.656 451.557V450.761H222.343V451.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 453.503V448.815H232.397V453.503H231.602ZM229.656 451.557V450.761H234.343V451.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 453.503V448.815H244.397V453.503H243.602ZM241.656 451.557V450.761H246.343V451.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 453.503V448.815H256.397V453.503H255.602ZM253.656 451.557V450.761H258.343V451.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 453.503V448.815H268.397V453.503H267.602ZM265.656 451.557V450.761H270.343V451.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 453.503V448.815H280.397V453.503H279.602ZM277.656 451.557V450.761H282.343V451.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 453.503V448.815H292.397V453.503H291.602ZM289.656 451.557V450.761H294.343V451.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 453.503V448.815H304.397V453.503H303.602ZM301.656 451.557V450.761H306.343V451.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 453.503V448.815H316.397V453.503H315.602ZM313.656 451.557V450.761H318.343V451.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 453.503V448.815H328.397V453.503H327.602ZM325.656 451.557V450.761H330.343V451.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 453.503V448.815H340.397V453.503H339.602ZM337.656 451.557V450.761H342.343V451.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 453.503V448.815H352.397V453.503H351.602ZM349.656 451.557V450.761H354.343V451.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 453.503V448.815H364.397V453.503H363.602ZM361.656 451.557V450.761H366.343V451.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 453.503V448.815H376.397V453.503H375.602ZM373.656 451.557V450.761H378.343V451.557H373.656Z" fill="#01256C"/>
+<path d="M519.602 453.503V448.815H520.397V453.503H519.602ZM517.656 451.557V450.761H522.343V451.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 453.503V448.815H532.397V453.503H531.602ZM529.656 451.557V450.761H534.343V451.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 453.503V448.815H544.397V453.503H543.602ZM541.656 451.557V450.761H546.343V451.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 453.503V448.815H556.397V453.503H555.602ZM553.656 451.557V450.761H558.343V451.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 453.503V448.815H568.397V453.503H567.602ZM565.656 451.557V450.761H570.343V451.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 453.503V448.815H580.397V453.503H579.602ZM577.656 451.557V450.761H582.343V451.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 453.503V448.815H592.397V453.503H591.602ZM589.656 451.557V450.761H594.343V451.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 453.503V448.815H604.397V453.503H603.602ZM601.656 451.557V450.761H606.343V451.557H601.656Z" fill="#01256C"/>
+<path d="M616.001 454.057C615.826 454.057 615.675 453.994 615.55 453.869C615.424 453.743 615.362 453.593 615.362 453.418C615.362 453.242 615.424 453.092 615.55 452.967C615.675 452.841 615.826 452.778 616.001 452.778C616.176 452.778 616.326 452.841 616.452 452.967C616.577 453.092 616.64 453.242 616.64 453.418C616.64 453.534 616.61 453.64 616.551 453.737C616.494 453.834 616.418 453.912 616.32 453.972C616.226 454.028 616.119 454.057 616.001 454.057Z" fill="#01256C"/>
+<path d="M699.602 453.503V448.815H700.397V453.503H699.602ZM697.656 451.557V450.761H702.343V451.557H697.656Z" fill="#01256C"/>
+<path d="M711.602 453.503V448.815H712.397V453.503H711.602ZM709.656 451.557V450.761H714.343V451.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 453.503V448.815H724.397V453.503H723.602ZM721.656 451.557V450.761H726.343V451.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 453.503V448.815H736.397V453.503H735.602ZM733.656 451.557V450.761H738.343V451.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 453.503V448.815H748.397V453.503H747.602ZM745.656 451.557V450.761H750.343V451.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 453.503V448.815H760.397V453.503H759.602ZM757.656 451.557V450.761H762.343V451.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 453.503V448.815H772.397V453.503H771.602ZM769.656 451.557V450.761H774.343V451.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 453.503V448.815H784.397V453.503H783.602ZM781.656 451.557V450.761H786.343V451.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 453.503V448.815H796.397V453.503H795.602ZM793.656 451.557V450.761H798.343V451.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 453.503V448.815H808.397V453.503H807.602ZM805.656 451.557V450.761H810.343V451.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 453.503V448.815H820.397V453.503H819.602ZM817.656 451.557V450.761H822.343V451.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 453.503V448.815H832.397V453.503H831.602ZM829.656 451.557V450.761H834.343V451.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 453.503V448.815H844.397V453.503H843.602ZM841.656 451.557V450.761H846.343V451.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 453.503V448.815H856.397V453.503H855.602ZM853.656 451.557V450.761H858.343V451.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 453.503V448.815H868.397V453.503H867.602ZM865.656 451.557V450.761H870.343V451.557H865.656Z" fill="#01256C"/>
+<path d="M879.602 453.503V448.815H880.397V453.503H879.602ZM877.656 451.557V450.761H882.343V451.557H877.656Z" fill="#01256C"/>
+<path d="M891.602 453.503V448.815H892.397V453.503H891.602ZM889.656 451.557V450.761H894.343V451.557H889.656Z" fill="#01256C"/>
+<path d="M903.602 453.503V448.815H904.397V453.503H903.602ZM901.656 451.557V450.761H906.343V451.557H901.656Z" fill="#01256C"/>
+<path d="M915.602 453.503V448.815H916.397V453.503H915.602ZM913.656 451.557V450.761H918.343V451.557H913.656Z" fill="#01256C"/>
+<path d="M171.602 465.503V460.815H172.397V465.503H171.602ZM169.656 463.557V462.761H174.343V463.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 465.503V460.815H184.397V465.503H183.602ZM181.656 463.557V462.761H186.343V463.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 465.503V460.815H196.397V465.503H195.602ZM193.656 463.557V462.761H198.343V463.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 465.503V460.815H208.397V465.503H207.602ZM205.656 463.557V462.761H210.343V463.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 465.503V460.815H220.397V465.503H219.602ZM217.656 463.557V462.761H222.343V463.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 465.503V460.815H232.397V465.503H231.602ZM229.656 463.557V462.761H234.343V463.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 465.503V460.815H244.397V465.503H243.602ZM241.656 463.557V462.761H246.343V463.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 465.503V460.815H256.397V465.503H255.602ZM253.656 463.557V462.761H258.343V463.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 465.503V460.815H268.397V465.503H267.602ZM265.656 463.557V462.761H270.343V463.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 465.503V460.815H280.397V465.503H279.602ZM277.656 463.557V462.761H282.343V463.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 465.503V460.815H292.397V465.503H291.602ZM289.656 463.557V462.761H294.343V463.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 465.503V460.815H304.397V465.503H303.602ZM301.656 463.557V462.761H306.343V463.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 465.503V460.815H316.397V465.503H315.602ZM313.656 463.557V462.761H318.343V463.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 465.503V460.815H328.397V465.503H327.602ZM325.656 463.557V462.761H330.343V463.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 465.503V460.815H340.397V465.503H339.602ZM337.656 463.557V462.761H342.343V463.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 465.503V460.815H352.397V465.503H351.602ZM349.656 463.557V462.761H354.343V463.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 465.503V460.815H364.397V465.503H363.602ZM361.656 463.557V462.761H366.343V463.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 465.503V460.815H376.397V465.503H375.602ZM373.656 463.557V462.761H378.343V463.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 465.503V460.815H388.397V465.503H387.602ZM385.656 463.557V462.761H390.343V463.557H385.656Z" fill="#01256C"/>
+<path d="M519.659 462.818L519.716 461.256L518.395 462.094L518.054 461.497L519.446 460.773L518.054 460.048L518.395 459.452L519.716 460.29L519.659 458.727H520.341L520.284 460.29L521.605 459.452L521.946 460.048L520.554 460.773L521.946 461.497L521.605 462.094L520.284 461.256L520.341 462.818H519.659Z" fill="#01256C"/>
+<path d="M531.602 465.503V460.815H532.397V465.503H531.602ZM529.656 463.557V462.761H534.343V463.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 465.503V460.815H544.397V465.503H543.602ZM541.656 463.557V462.761H546.343V463.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 465.503V460.815H556.397V465.503H555.602ZM553.656 463.557V462.761H558.343V463.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 465.503V460.815H568.397V465.503H567.602ZM565.656 463.557V462.761H570.343V463.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 465.503V460.815H580.397V465.503H579.602ZM577.656 463.557V462.761H582.343V463.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 465.503V460.815H592.397V465.503H591.602ZM589.656 463.557V462.761H594.343V463.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 465.503V460.815H604.397V465.503H603.602ZM601.656 463.557V462.761H606.343V463.557H601.656Z" fill="#01256C"/>
+<path d="M711.602 465.503V460.815H712.397V465.503H711.602ZM709.656 463.557V462.761H714.343V463.557H709.656Z" fill="#01256C"/>
+<path d="M723.602 465.503V460.815H724.397V465.503H723.602ZM721.656 463.557V462.761H726.343V463.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 465.503V460.815H736.397V465.503H735.602ZM733.656 463.557V462.761H738.343V463.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 465.503V460.815H748.397V465.503H747.602ZM745.656 463.557V462.761H750.343V463.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 465.503V460.815H760.397V465.503H759.602ZM757.656 463.557V462.761H762.343V463.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 465.503V460.815H772.397V465.503H771.602ZM769.656 463.557V462.761H774.343V463.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 465.503V460.815H784.397V465.503H783.602ZM781.656 463.557V462.761H786.343V463.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 465.503V460.815H796.397V465.503H795.602ZM793.656 463.557V462.761H798.343V463.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 465.503V460.815H808.397V465.503H807.602ZM805.656 463.557V462.761H810.343V463.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 465.503V460.815H820.397V465.503H819.602ZM817.656 463.557V462.761H822.343V463.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 465.503V460.815H832.397V465.503H831.602ZM829.656 463.557V462.761H834.343V463.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 465.503V460.815H844.397V465.503H843.602ZM841.656 463.557V462.761H846.343V463.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 465.503V460.815H856.397V465.503H855.602ZM853.656 463.557V462.761H858.343V463.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 465.503V460.815H868.397V465.503H867.602ZM865.656 463.557V462.761H870.343V463.557H865.656Z" fill="#01256C"/>
+<path d="M879.602 465.503V460.815H880.397V465.503H879.602ZM877.656 463.557V462.761H882.343V463.557H877.656Z" fill="#01256C"/>
+<path d="M135.602 477.503V472.815H136.397V477.503H135.602ZM133.656 475.557V474.761H138.343V475.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 477.503V472.815H148.397V477.503H147.602ZM145.656 475.557V474.761H150.343V475.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 477.503V472.815H160.397V477.503H159.602ZM157.656 475.557V474.761H162.343V475.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 477.503V472.815H172.397V477.503H171.602ZM169.656 475.557V474.761H174.343V475.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 477.503V472.815H184.397V477.503H183.602ZM181.656 475.557V474.761H186.343V475.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 477.503V472.815H196.397V477.503H195.602ZM193.656 475.557V474.761H198.343V475.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 477.503V472.815H208.397V477.503H207.602ZM205.656 475.557V474.761H210.343V475.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 477.503V472.815H220.397V477.503H219.602ZM217.656 475.557V474.761H222.343V475.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 477.503V472.815H232.397V477.503H231.602ZM229.656 475.557V474.761H234.343V475.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 477.503V472.815H244.397V477.503H243.602ZM241.656 475.557V474.761H246.343V475.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 477.503V472.815H256.397V477.503H255.602ZM253.656 475.557V474.761H258.343V475.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 477.503V472.815H268.397V477.503H267.602ZM265.656 475.557V474.761H270.343V475.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 477.503V472.815H280.397V477.503H279.602ZM277.656 475.557V474.761H282.343V475.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 477.503V472.815H292.397V477.503H291.602ZM289.656 475.557V474.761H294.343V475.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 477.503V472.815H304.397V477.503H303.602ZM301.656 475.557V474.761H306.343V475.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 477.503V472.815H316.397V477.503H315.602ZM313.656 475.557V474.761H318.343V475.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 477.503V472.815H328.397V477.503H327.602ZM325.656 475.557V474.761H330.343V475.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 477.503V472.815H340.397V477.503H339.602ZM337.656 475.557V474.761H342.343V475.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 477.503V472.815H352.397V477.503H351.602ZM349.656 475.557V474.761H354.343V475.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 477.503V472.815H364.397V477.503H363.602ZM361.656 475.557V474.761H366.343V475.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 477.503V472.815H376.397V477.503H375.602ZM373.656 475.557V474.761H378.343V475.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 477.503V472.815H388.397V477.503H387.602ZM385.656 475.557V474.761H390.343V475.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 477.503V472.815H400.397V477.503H399.602ZM397.656 475.557V474.761H402.343V475.557H397.656Z" fill="#01256C"/>
+<path d="M519.659 474.818L519.716 473.256L518.395 474.094L518.054 473.497L519.446 472.773L518.054 472.048L518.395 471.452L519.716 472.29L519.659 470.727H520.341L520.284 472.29L521.605 471.452L521.946 472.048L520.554 472.773L521.946 473.497L521.605 474.094L520.284 473.256L520.341 474.818H519.659Z" fill="#01256C"/>
+<path d="M531.602 477.503V472.815H532.397V477.503H531.602ZM529.656 475.557V474.761H534.343V475.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 477.503V472.815H544.397V477.503H543.602ZM541.656 475.557V474.761H546.343V475.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 477.503V472.815H556.397V477.503H555.602ZM553.656 475.557V474.761H558.343V475.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 477.503V472.815H568.397V477.503H567.602ZM565.656 475.557V474.761H570.343V475.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 477.503V472.815H580.397V477.503H579.602ZM577.656 475.557V474.761H582.343V475.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 477.503V472.815H592.397V477.503H591.602ZM589.656 475.557V474.761H594.343V475.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 477.503V472.815H604.397V477.503H603.602ZM601.656 475.557V474.761H606.343V475.557H601.656Z" fill="#01256C"/>
+<path d="M723.602 477.503V472.815H724.397V477.503H723.602ZM721.656 475.557V474.761H726.343V475.557H721.656Z" fill="#01256C"/>
+<path d="M735.602 477.503V472.815H736.397V477.503H735.602ZM733.656 475.557V474.761H738.343V475.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 477.503V472.815H748.397V477.503H747.602ZM745.656 475.557V474.761H750.343V475.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 477.503V472.815H760.397V477.503H759.602ZM757.656 475.557V474.761H762.343V475.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 477.503V472.815H772.397V477.503H771.602ZM769.656 475.557V474.761H774.343V475.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 477.503V472.815H784.397V477.503H783.602ZM781.656 475.557V474.761H786.343V475.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 477.503V472.815H796.397V477.503H795.602ZM793.656 475.557V474.761H798.343V475.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 477.503V472.815H808.397V477.503H807.602ZM805.656 475.557V474.761H810.343V475.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 477.503V472.815H820.397V477.503H819.602ZM817.656 475.557V474.761H822.343V475.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 477.503V472.815H832.397V477.503H831.602ZM829.656 475.557V474.761H834.343V475.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 477.503V472.815H844.397V477.503H843.602ZM841.656 475.557V474.761H846.343V475.557H841.656Z" fill="#01256C"/>
+<path d="M111.602 489.503V484.815H112.397V489.503H111.602ZM109.656 487.557V486.761H114.343V487.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 489.503V484.815H124.397V489.503H123.602ZM121.656 487.557V486.761H126.343V487.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 489.503V484.815H136.397V489.503H135.602ZM133.656 487.557V486.761H138.343V487.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 489.503V484.815H148.397V489.503H147.602ZM145.656 487.557V486.761H150.343V487.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 489.503V484.815H160.397V489.503H159.602ZM157.656 487.557V486.761H162.343V487.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 489.503V484.815H172.397V489.503H171.602ZM169.656 487.557V486.761H174.343V487.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 489.503V484.815H184.397V489.503H183.602ZM181.656 487.557V486.761H186.343V487.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 489.503V484.815H196.397V489.503H195.602ZM193.656 487.557V486.761H198.343V487.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 489.503V484.815H208.397V489.503H207.602ZM205.656 487.557V486.761H210.343V487.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 489.503V484.815H220.397V489.503H219.602ZM217.656 487.557V486.761H222.343V487.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 489.503V484.815H232.397V489.503H231.602ZM229.656 487.557V486.761H234.343V487.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 489.503V484.815H244.397V489.503H243.602ZM241.656 487.557V486.761H246.343V487.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 489.503V484.815H256.397V489.503H255.602ZM253.656 487.557V486.761H258.343V487.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 489.503V484.815H268.397V489.503H267.602ZM265.656 487.557V486.761H270.343V487.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 489.503V484.815H280.397V489.503H279.602ZM277.656 487.557V486.761H282.343V487.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 489.503V484.815H292.397V489.503H291.602ZM289.656 487.557V486.761H294.343V487.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 489.503V484.815H304.397V489.503H303.602ZM301.656 487.557V486.761H306.343V487.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 489.503V484.815H316.397V489.503H315.602ZM313.656 487.557V486.761H318.343V487.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 489.503V484.815H328.397V489.503H327.602ZM325.656 487.557V486.761H330.343V487.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 489.503V484.815H340.397V489.503H339.602ZM337.656 487.557V486.761H342.343V487.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 489.503V484.815H352.397V489.503H351.602ZM349.656 487.557V486.761H354.343V487.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 489.503V484.815H364.397V489.503H363.602ZM361.656 487.557V486.761H366.343V487.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 489.503V484.815H376.397V489.503H375.602ZM373.656 487.557V486.761H378.343V487.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 489.503V484.815H388.397V489.503H387.602ZM385.656 487.557V486.761H390.343V487.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 489.503V484.815H400.397V489.503H399.602ZM397.656 487.557V486.761H402.343V487.557H397.656Z" fill="#01256C"/>
+<path d="M519.602 489.503V484.815H520.397V489.503H519.602ZM517.656 487.557V486.761H522.343V487.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 489.503V484.815H532.397V489.503H531.602ZM529.656 487.557V486.761H534.343V487.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 489.503V484.815H544.397V489.503H543.602ZM541.656 487.557V486.761H546.343V487.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 489.503V484.815H556.397V489.503H555.602ZM553.656 487.557V486.761H558.343V487.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 489.503V484.815H568.397V489.503H567.602ZM565.656 487.557V486.761H570.343V487.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 489.503V484.815H580.397V489.503H579.602ZM577.656 487.557V486.761H582.343V487.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 489.503V484.815H592.397V489.503H591.602ZM589.656 487.557V486.761H594.343V487.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 489.503V484.815H604.397V489.503H603.602ZM601.656 487.557V486.761H606.343V487.557H601.656Z" fill="#01256C"/>
+<path d="M735.602 489.503V484.815H736.397V489.503H735.602ZM733.656 487.557V486.761H738.343V487.557H733.656Z" fill="#01256C"/>
+<path d="M747.602 489.503V484.815H748.397V489.503H747.602ZM745.656 487.557V486.761H750.343V487.557H745.656Z" fill="#01256C"/>
+<path d="M759.602 489.503V484.815H760.397V489.503H759.602ZM757.656 487.557V486.761H762.343V487.557H757.656Z" fill="#01256C"/>
+<path d="M771.602 489.503V484.815H772.397V489.503H771.602ZM769.656 487.557V486.761H774.343V487.557H769.656Z" fill="#01256C"/>
+<path d="M783.602 489.503V484.815H784.397V489.503H783.602ZM781.656 487.557V486.761H786.343V487.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 489.503V484.815H796.397V489.503H795.602ZM793.656 487.557V486.761H798.343V487.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 489.503V484.815H808.397V489.503H807.602ZM805.656 487.557V486.761H810.343V487.557H805.656Z" fill="#01256C"/>
+<path d="M820.616 489.006L820.559 489.389C820.519 489.659 820.457 489.948 820.374 490.256C820.294 490.563 820.21 490.853 820.122 491.126C820.034 491.398 819.962 491.615 819.905 491.776H819.266C819.297 491.624 819.337 491.424 819.387 491.175C819.437 490.927 819.486 490.649 819.536 490.341C819.588 490.036 819.631 489.723 819.664 489.403L819.707 489.006H820.616ZM820.104 486.009C819.929 486.009 819.779 485.946 819.653 485.82C819.528 485.695 819.465 485.545 819.465 485.369C819.465 485.194 819.528 485.044 819.653 484.918C819.779 484.793 819.929 484.73 820.104 484.73C820.28 484.73 820.43 484.793 820.555 484.918C820.681 485.044 820.744 485.194 820.744 485.369C820.744 485.485 820.714 485.592 820.655 485.689C820.598 485.786 820.521 485.864 820.424 485.923C820.329 485.98 820.223 486.009 820.104 486.009Z" fill="#01256C"/>
+<path d="M40.6157 501.006L40.5589 501.389C40.5186 501.659 40.4571 501.948 40.3742 502.256C40.2937 502.563 40.2097 502.853 40.1221 503.126C40.0345 503.398 39.9623 503.615 39.9055 503.776H39.2662C39.297 503.624 39.3373 503.424 39.387 503.175C39.4367 502.927 39.4864 502.649 39.5361 502.341C39.5882 502.036 39.6308 501.723 39.664 501.403L39.7066 501.006H40.6157ZM40.1043 498.009C39.9291 498.009 39.7788 497.946 39.6533 497.82C39.5278 497.695 39.4651 497.545 39.4651 497.369C39.4651 497.194 39.5278 497.044 39.6533 496.918C39.7788 496.793 39.9291 496.73 40.1043 496.73C40.2795 496.73 40.4298 496.793 40.5553 496.918C40.6808 497.044 40.7435 497.194 40.7435 497.369C40.7435 497.485 40.7139 497.592 40.6547 497.689C40.5979 497.786 40.521 497.864 40.4239 497.923C40.3292 497.98 40.2227 498.009 40.1043 498.009Z" fill="#01256C"/>
+<path d="M51.6018 501.503V496.815H52.3973V501.503H51.6018ZM49.6558 499.557V498.761H54.3433V499.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 501.503V496.815H64.3973V501.503H63.6018ZM61.6558 499.557V498.761H66.3433V499.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 501.503V496.815H76.3973V501.503H75.6018ZM73.6558 499.557V498.761H78.3433V499.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 501.503V496.815H88.3973V501.503H87.6018ZM85.6558 499.557V498.761H90.3433V499.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 501.503V496.815H100.397V501.503H99.6018ZM97.6558 499.557V498.761H102.343V499.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 501.503V496.815H112.397V501.503H111.602ZM109.656 499.557V498.761H114.343V499.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 501.503V496.815H124.397V501.503H123.602ZM121.656 499.557V498.761H126.343V499.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 501.503V496.815H136.397V501.503H135.602ZM133.656 499.557V498.761H138.343V499.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 501.503V496.815H148.397V501.503H147.602ZM145.656 499.557V498.761H150.343V499.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 501.503V496.815H160.397V501.503H159.602ZM157.656 499.557V498.761H162.343V499.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 501.503V496.815H172.397V501.503H171.602ZM169.656 499.557V498.761H174.343V499.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 501.503V496.815H184.397V501.503H183.602ZM181.656 499.557V498.761H186.343V499.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 501.503V496.815H196.397V501.503H195.602ZM193.656 499.557V498.761H198.343V499.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 501.503V496.815H208.397V501.503H207.602ZM205.656 499.557V498.761H210.343V499.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 501.503V496.815H220.397V501.503H219.602ZM217.656 499.557V498.761H222.343V499.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 501.503V496.815H232.397V501.503H231.602ZM229.656 499.557V498.761H234.343V499.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 501.503V496.815H244.397V501.503H243.602ZM241.656 499.557V498.761H246.343V499.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 501.503V496.815H256.397V501.503H255.602ZM253.656 499.557V498.761H258.343V499.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 501.503V496.815H268.397V501.503H267.602ZM265.656 499.557V498.761H270.343V499.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 501.503V496.815H280.397V501.503H279.602ZM277.656 499.557V498.761H282.343V499.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 501.503V496.815H292.397V501.503H291.602ZM289.656 499.557V498.761H294.343V499.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 501.503V496.815H304.397V501.503H303.602ZM301.656 499.557V498.761H306.343V499.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 501.503V496.815H316.397V501.503H315.602ZM313.656 499.557V498.761H318.343V499.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 501.503V496.815H328.397V501.503H327.602ZM325.656 499.557V498.761H330.343V499.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 501.503V496.815H340.397V501.503H339.602ZM337.656 499.557V498.761H342.343V499.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 501.503V496.815H352.397V501.503H351.602ZM349.656 499.557V498.761H354.343V499.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 501.503V496.815H364.397V501.503H363.602ZM361.656 499.557V498.761H366.343V499.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 501.503V496.815H376.397V501.503H375.602ZM373.656 499.557V498.761H378.343V499.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 501.503V496.815H388.397V501.503H387.602ZM385.656 499.557V498.761H390.343V499.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 501.503V496.815H400.397V501.503H399.602ZM397.656 499.557V498.761H402.343V499.557H397.656Z" fill="#01256C"/>
+<path d="M519.602 501.503V496.815H520.397V501.503H519.602ZM517.656 499.557V498.761H522.343V499.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 501.503V496.815H532.397V501.503H531.602ZM529.656 499.557V498.761H534.343V499.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 501.503V496.815H544.397V501.503H543.602ZM541.656 499.557V498.761H546.343V499.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 501.503V496.815H556.397V501.503H555.602ZM553.656 499.557V498.761H558.343V499.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 501.503V496.815H568.397V501.503H567.602ZM565.656 499.557V498.761H570.343V499.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 501.503V496.815H580.397V501.503H579.602ZM577.656 499.557V498.761H582.343V499.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 501.503V496.815H592.397V501.503H591.602ZM589.656 499.557V498.761H594.343V499.557H589.656Z" fill="#01256C"/>
+<path d="M603.659 498.818L603.716 497.256L602.395 498.094L602.054 497.497L603.446 496.773L602.054 496.048L602.395 495.452L603.716 496.29L603.659 494.727H604.341L604.284 496.29L605.605 495.452L605.946 496.048L604.554 496.773L605.946 497.497L605.605 498.094L604.284 497.256L604.341 498.818H603.659Z" fill="#01256C"/>
+<path d="M3.60183 513.503V508.815H4.39728V513.503H3.60183ZM1.65581 511.557V510.761H6.34331V511.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 513.503V508.815H16.3973V513.503H15.6018ZM13.6558 511.557V510.761H18.3433V511.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 513.503V508.815H28.3973V513.503H27.6018ZM25.6558 511.557V510.761H30.3433V511.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 513.503V508.815H40.3973V513.503H39.6018ZM37.6558 511.557V510.761H42.3433V511.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 513.503V508.815H52.3973V513.503H51.6018ZM49.6558 511.557V510.761H54.3433V511.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 513.503V508.815H64.3973V513.503H63.6018ZM61.6558 511.557V510.761H66.3433V511.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 513.503V508.815H76.3973V513.503H75.6018ZM73.6558 511.557V510.761H78.3433V511.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 513.503V508.815H88.3973V513.503H87.6018ZM85.6558 511.557V510.761H90.3433V511.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 513.503V508.815H100.397V513.503H99.6018ZM97.6558 511.557V510.761H102.343V511.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 513.503V508.815H112.397V513.503H111.602ZM109.656 511.557V510.761H114.343V511.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 513.503V508.815H124.397V513.503H123.602ZM121.656 511.557V510.761H126.343V511.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 513.503V508.815H136.397V513.503H135.602ZM133.656 511.557V510.761H138.343V511.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 513.503V508.815H148.397V513.503H147.602ZM145.656 511.557V510.761H150.343V511.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 513.503V508.815H160.397V513.503H159.602ZM157.656 511.557V510.761H162.343V511.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 513.503V508.815H172.397V513.503H171.602ZM169.656 511.557V510.761H174.343V511.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 513.503V508.815H184.397V513.503H183.602ZM181.656 511.557V510.761H186.343V511.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 513.503V508.815H196.397V513.503H195.602ZM193.656 511.557V510.761H198.343V511.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 513.503V508.815H208.397V513.503H207.602ZM205.656 511.557V510.761H210.343V511.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 513.503V508.815H220.397V513.503H219.602ZM217.656 511.557V510.761H222.343V511.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 513.503V508.815H232.397V513.503H231.602ZM229.656 511.557V510.761H234.343V511.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 513.503V508.815H244.397V513.503H243.602ZM241.656 511.557V510.761H246.343V511.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 513.503V508.815H256.397V513.503H255.602ZM253.656 511.557V510.761H258.343V511.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 513.503V508.815H268.397V513.503H267.602ZM265.656 511.557V510.761H270.343V511.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 513.503V508.815H280.397V513.503H279.602ZM277.656 511.557V510.761H282.343V511.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 513.503V508.815H292.397V513.503H291.602ZM289.656 511.557V510.761H294.343V511.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 513.503V508.815H304.397V513.503H303.602ZM301.656 511.557V510.761H306.343V511.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 513.503V508.815H316.397V513.503H315.602ZM313.656 511.557V510.761H318.343V511.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 513.503V508.815H328.397V513.503H327.602ZM325.656 511.557V510.761H330.343V511.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 513.503V508.815H340.397V513.503H339.602ZM337.656 511.557V510.761H342.343V511.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 513.503V508.815H352.397V513.503H351.602ZM349.656 511.557V510.761H354.343V511.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 513.503V508.815H364.397V513.503H363.602ZM361.656 511.557V510.761H366.343V511.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 513.503V508.815H376.397V513.503H375.602ZM373.656 511.557V510.761H378.343V511.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 513.503V508.815H388.397V513.503H387.602ZM385.656 511.557V510.761H390.343V511.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 513.503V508.815H400.397V513.503H399.602ZM397.656 511.557V510.761H402.343V511.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 513.503V508.815H412.397V513.503H411.602ZM409.656 511.557V510.761H414.343V511.557H409.656Z" fill="#01256C"/>
+<path d="M519.602 513.503V508.815H520.397V513.503H519.602ZM517.656 511.557V510.761H522.343V511.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 513.503V508.815H532.397V513.503H531.602ZM529.656 511.557V510.761H534.343V511.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 513.503V508.815H544.397V513.503H543.602ZM541.656 511.557V510.761H546.343V511.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 513.503V508.815H556.397V513.503H555.602ZM553.656 511.557V510.761H558.343V511.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 513.503V508.815H568.397V513.503H567.602ZM565.656 511.557V510.761H570.343V511.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 513.503V508.815H580.397V513.503H579.602ZM577.656 511.557V510.761H582.343V511.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 513.503V508.815H592.397V513.503H591.602ZM589.656 511.557V510.761H594.343V511.557H589.656Z" fill="#01256C"/>
+<path d="M3.60183 525.503V520.815H4.39728V525.503H3.60183ZM1.65581 523.557V522.761H6.34331V523.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 525.503V520.815H16.3973V525.503H15.6018ZM13.6558 523.557V522.761H18.3433V523.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 525.503V520.815H28.3973V525.503H27.6018ZM25.6558 523.557V522.761H30.3433V523.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 525.503V520.815H40.3973V525.503H39.6018ZM37.6558 523.557V522.761H42.3433V523.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 525.503V520.815H52.3973V525.503H51.6018ZM49.6558 523.557V522.761H54.3433V523.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 525.503V520.815H64.3973V525.503H63.6018ZM61.6558 523.557V522.761H66.3433V523.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 525.503V520.815H76.3973V525.503H75.6018ZM73.6558 523.557V522.761H78.3433V523.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 525.503V520.815H88.3973V525.503H87.6018ZM85.6558 523.557V522.761H90.3433V523.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 525.503V520.815H100.397V525.503H99.6018ZM97.6558 523.557V522.761H102.343V523.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 525.503V520.815H112.397V525.503H111.602ZM109.656 523.557V522.761H114.343V523.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 525.503V520.815H124.397V525.503H123.602ZM121.656 523.557V522.761H126.343V523.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 525.503V520.815H136.397V525.503H135.602ZM133.656 523.557V522.761H138.343V523.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 525.503V520.815H148.397V525.503H147.602ZM145.656 523.557V522.761H150.343V523.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 525.503V520.815H160.397V525.503H159.602ZM157.656 523.557V522.761H162.343V523.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 525.503V520.815H172.397V525.503H171.602ZM169.656 523.557V522.761H174.343V523.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 525.503V520.815H184.397V525.503H183.602ZM181.656 523.557V522.761H186.343V523.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 525.503V520.815H196.397V525.503H195.602ZM193.656 523.557V522.761H198.343V523.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 525.503V520.815H208.397V525.503H207.602ZM205.656 523.557V522.761H210.343V523.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 525.503V520.815H220.397V525.503H219.602ZM217.656 523.557V522.761H222.343V523.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 525.503V520.815H232.397V525.503H231.602ZM229.656 523.557V522.761H234.343V523.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 525.503V520.815H244.397V525.503H243.602ZM241.656 523.557V522.761H246.343V523.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 525.503V520.815H256.397V525.503H255.602ZM253.656 523.557V522.761H258.343V523.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 525.503V520.815H268.397V525.503H267.602ZM265.656 523.557V522.761H270.343V523.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 525.503V520.815H280.397V525.503H279.602ZM277.656 523.557V522.761H282.343V523.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 525.503V520.815H292.397V525.503H291.602ZM289.656 523.557V522.761H294.343V523.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 525.503V520.815H304.397V525.503H303.602ZM301.656 523.557V522.761H306.343V523.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 525.503V520.815H316.397V525.503H315.602ZM313.656 523.557V522.761H318.343V523.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 525.503V520.815H328.397V525.503H327.602ZM325.656 523.557V522.761H330.343V523.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 525.503V520.815H340.397V525.503H339.602ZM337.656 523.557V522.761H342.343V523.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 525.503V520.815H352.397V525.503H351.602ZM349.656 523.557V522.761H354.343V523.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 525.503V520.815H364.397V525.503H363.602ZM361.656 523.557V522.761H366.343V523.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 525.503V520.815H376.397V525.503H375.602ZM373.656 523.557V522.761H378.343V523.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 525.503V520.815H388.397V525.503H387.602ZM385.656 523.557V522.761H390.343V523.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 525.503V520.815H400.397V525.503H399.602ZM397.656 523.557V522.761H402.343V523.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 525.503V520.815H412.397V525.503H411.602ZM409.656 523.557V522.761H414.343V523.557H409.656Z" fill="#01256C"/>
+<path d="M424.616 525.006L424.559 525.389C424.519 525.659 424.457 525.948 424.374 526.256C424.294 526.563 424.21 526.853 424.122 527.126C424.034 527.398 423.962 527.615 423.905 527.776H423.266C423.297 527.624 423.337 527.424 423.387 527.175C423.437 526.927 423.486 526.649 423.536 526.341C423.588 526.036 423.631 525.723 423.664 525.403L423.707 525.006H424.616ZM424.104 522.009C423.929 522.009 423.779 521.946 423.653 521.82C423.528 521.695 423.465 521.545 423.465 521.369C423.465 521.194 423.528 521.044 423.653 520.918C423.779 520.793 423.929 520.73 424.104 520.73C424.28 520.73 424.43 520.793 424.555 520.918C424.681 521.044 424.744 521.194 424.744 521.369C424.744 521.485 424.714 521.592 424.655 521.689C424.598 521.786 424.521 521.864 424.424 521.923C424.329 521.98 424.223 522.009 424.104 522.009Z" fill="#01256C"/>
+<path d="M519.602 525.503V520.815H520.397V525.503H519.602ZM517.656 523.557V522.761H522.343V523.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 525.503V520.815H532.397V525.503H531.602ZM529.656 523.557V522.761H534.343V523.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 525.503V520.815H544.397V525.503H543.602ZM541.656 523.557V522.761H546.343V523.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 525.503V520.815H556.397V525.503H555.602ZM553.656 523.557V522.761H558.343V523.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 525.503V520.815H568.397V525.503H567.602ZM565.656 523.557V522.761H570.343V523.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 525.503V520.815H580.397V525.503H579.602ZM577.656 523.557V522.761H582.343V523.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 525.503V520.815H592.397V525.503H591.602ZM589.656 523.557V522.761H594.343V523.557H589.656Z" fill="#01256C"/>
+<path d="M3.60183 537.503V532.815H4.39728V537.503H3.60183ZM1.65581 535.557V534.761H6.34331V535.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 537.503V532.815H16.3973V537.503H15.6018ZM13.6558 535.557V534.761H18.3433V535.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 537.503V532.815H28.3973V537.503H27.6018ZM25.6558 535.557V534.761H30.3433V535.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 537.503V532.815H40.3973V537.503H39.6018ZM37.6558 535.557V534.761H42.3433V535.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 537.503V532.815H52.3973V537.503H51.6018ZM49.6558 535.557V534.761H54.3433V535.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 537.503V532.815H64.3973V537.503H63.6018ZM61.6558 535.557V534.761H66.3433V535.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 537.503V532.815H76.3973V537.503H75.6018ZM73.6558 535.557V534.761H78.3433V535.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 537.503V532.815H88.3973V537.503H87.6018ZM85.6558 535.557V534.761H90.3433V535.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 537.503V532.815H100.397V537.503H99.6018ZM97.6558 535.557V534.761H102.343V535.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 537.503V532.815H112.397V537.503H111.602ZM109.656 535.557V534.761H114.343V535.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 537.503V532.815H124.397V537.503H123.602ZM121.656 535.557V534.761H126.343V535.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 537.503V532.815H136.397V537.503H135.602ZM133.656 535.557V534.761H138.343V535.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 537.503V532.815H148.397V537.503H147.602ZM145.656 535.557V534.761H150.343V535.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 537.503V532.815H160.397V537.503H159.602ZM157.656 535.557V534.761H162.343V535.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 537.503V532.815H172.397V537.503H171.602ZM169.656 535.557V534.761H174.343V535.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 537.503V532.815H184.397V537.503H183.602ZM181.656 535.557V534.761H186.343V535.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 537.503V532.815H196.397V537.503H195.602ZM193.656 535.557V534.761H198.343V535.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 537.503V532.815H208.397V537.503H207.602ZM205.656 535.557V534.761H210.343V535.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 537.503V532.815H220.397V537.503H219.602ZM217.656 535.557V534.761H222.343V535.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 537.503V532.815H232.397V537.503H231.602ZM229.656 535.557V534.761H234.343V535.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 537.503V532.815H244.397V537.503H243.602ZM241.656 535.557V534.761H246.343V535.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 537.503V532.815H256.397V537.503H255.602ZM253.656 535.557V534.761H258.343V535.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 537.503V532.815H268.397V537.503H267.602ZM265.656 535.557V534.761H270.343V535.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 537.503V532.815H280.397V537.503H279.602ZM277.656 535.557V534.761H282.343V535.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 537.503V532.815H292.397V537.503H291.602ZM289.656 535.557V534.761H294.343V535.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 537.503V532.815H304.397V537.503H303.602ZM301.656 535.557V534.761H306.343V535.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 537.503V532.815H316.397V537.503H315.602ZM313.656 535.557V534.761H318.343V535.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 537.503V532.815H328.397V537.503H327.602ZM325.656 535.557V534.761H330.343V535.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 537.503V532.815H340.397V537.503H339.602ZM337.656 535.557V534.761H342.343V535.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 537.503V532.815H352.397V537.503H351.602ZM349.656 535.557V534.761H354.343V535.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 537.503V532.815H364.397V537.503H363.602ZM361.656 535.557V534.761H366.343V535.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 537.503V532.815H376.397V537.503H375.602ZM373.656 535.557V534.761H378.343V535.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 537.503V532.815H388.397V537.503H387.602ZM385.656 535.557V534.761H390.343V535.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 537.503V532.815H400.397V537.503H399.602ZM397.656 535.557V534.761H402.343V535.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 537.503V532.815H412.397V537.503H411.602ZM409.656 535.557V534.761H414.343V535.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 537.503V532.815H424.397V537.503H423.602ZM421.656 535.557V534.761H426.343V535.557H421.656Z" fill="#01256C"/>
+<path d="M519.602 537.503V532.815H520.397V537.503H519.602ZM517.656 535.557V534.761H522.343V535.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 537.503V532.815H532.397V537.503H531.602ZM529.656 535.557V534.761H534.343V535.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 537.503V532.815H544.397V537.503H543.602ZM541.656 535.557V534.761H546.343V535.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 537.503V532.815H556.397V537.503H555.602ZM553.656 535.557V534.761H558.343V535.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 537.503V532.815H568.397V537.503H567.602ZM565.656 535.557V534.761H570.343V535.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 537.503V532.815H580.397V537.503H579.602ZM577.656 535.557V534.761H582.343V535.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 537.503V532.815H592.397V537.503H591.602ZM589.656 535.557V534.761H594.343V535.557H589.656Z" fill="#01256C"/>
+<path d="M3.60183 549.503V544.815H4.39728V549.503H3.60183ZM1.65581 547.557V546.761H6.34331V547.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 549.503V544.815H16.3973V549.503H15.6018ZM13.6558 547.557V546.761H18.3433V547.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 549.503V544.815H28.3973V549.503H27.6018ZM25.6558 547.557V546.761H30.3433V547.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 549.503V544.815H40.3973V549.503H39.6018ZM37.6558 547.557V546.761H42.3433V547.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 549.503V544.815H52.3973V549.503H51.6018ZM49.6558 547.557V546.761H54.3433V547.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 549.503V544.815H64.3973V549.503H63.6018ZM61.6558 547.557V546.761H66.3433V547.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 549.503V544.815H76.3973V549.503H75.6018ZM73.6558 547.557V546.761H78.3433V547.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 549.503V544.815H88.3973V549.503H87.6018ZM85.6558 547.557V546.761H90.3433V547.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 549.503V544.815H100.397V549.503H99.6018ZM97.6558 547.557V546.761H102.343V547.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 549.503V544.815H112.397V549.503H111.602ZM109.656 547.557V546.761H114.343V547.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 549.503V544.815H124.397V549.503H123.602ZM121.656 547.557V546.761H126.343V547.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 549.503V544.815H136.397V549.503H135.602ZM133.656 547.557V546.761H138.343V547.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 549.503V544.815H148.397V549.503H147.602ZM145.656 547.557V546.761H150.343V547.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 549.503V544.815H160.397V549.503H159.602ZM157.656 547.557V546.761H162.343V547.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 549.503V544.815H172.397V549.503H171.602ZM169.656 547.557V546.761H174.343V547.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 549.503V544.815H184.397V549.503H183.602ZM181.656 547.557V546.761H186.343V547.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 549.503V544.815H196.397V549.503H195.602ZM193.656 547.557V546.761H198.343V547.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 549.503V544.815H208.397V549.503H207.602ZM205.656 547.557V546.761H210.343V547.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 549.503V544.815H220.397V549.503H219.602ZM217.656 547.557V546.761H222.343V547.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 549.503V544.815H232.397V549.503H231.602ZM229.656 547.557V546.761H234.343V547.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 549.503V544.815H244.397V549.503H243.602ZM241.656 547.557V546.761H246.343V547.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 549.503V544.815H256.397V549.503H255.602ZM253.656 547.557V546.761H258.343V547.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 549.503V544.815H268.397V549.503H267.602ZM265.656 547.557V546.761H270.343V547.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 549.503V544.815H280.397V549.503H279.602ZM277.656 547.557V546.761H282.343V547.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 549.503V544.815H292.397V549.503H291.602ZM289.656 547.557V546.761H294.343V547.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 549.503V544.815H304.397V549.503H303.602ZM301.656 547.557V546.761H306.343V547.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 549.503V544.815H316.397V549.503H315.602ZM313.656 547.557V546.761H318.343V547.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 549.503V544.815H328.397V549.503H327.602ZM325.656 547.557V546.761H330.343V547.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 549.503V544.815H340.397V549.503H339.602ZM337.656 547.557V546.761H342.343V547.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 549.503V544.815H352.397V549.503H351.602ZM349.656 547.557V546.761H354.343V547.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 549.503V544.815H364.397V549.503H363.602ZM361.656 547.557V546.761H366.343V547.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 549.503V544.815H376.397V549.503H375.602ZM373.656 547.557V546.761H378.343V547.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 549.503V544.815H388.397V549.503H387.602ZM385.656 547.557V546.761H390.343V547.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 549.503V544.815H400.397V549.503H399.602ZM397.656 547.557V546.761H402.343V547.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 549.503V544.815H412.397V549.503H411.602ZM409.656 547.557V546.761H414.343V547.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 549.503V544.815H424.397V549.503H423.602ZM421.656 547.557V546.761H426.343V547.557H421.656Z" fill="#01256C"/>
+<path d="M519.602 549.503V544.815H520.397V549.503H519.602ZM517.656 547.557V546.761H522.343V547.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 549.503V544.815H532.397V549.503H531.602ZM529.656 547.557V546.761H534.343V547.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 549.503V544.815H544.397V549.503H543.602ZM541.656 547.557V546.761H546.343V547.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 549.503V544.815H556.397V549.503H555.602ZM553.656 547.557V546.761H558.343V547.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 549.503V544.815H568.397V549.503H567.602ZM565.656 547.557V546.761H570.343V547.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 549.503V544.815H580.397V549.503H579.602ZM577.656 547.557V546.761H582.343V547.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 549.503V544.815H592.397V549.503H591.602ZM589.656 547.557V546.761H594.343V547.557H589.656Z" fill="#01256C"/>
+<path d="M975.602 549.503V544.815H976.397V549.503H975.602ZM973.656 547.557V546.761H978.343V547.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 549.503V544.815H988.397V549.503H987.602ZM985.656 547.557V546.761H990.343V547.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 549.503V544.815H1000.4V549.503H999.602ZM997.656 547.557V546.761H1002.34V547.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 549.503V544.815H1012.4V549.503H1011.6ZM1009.66 547.557V546.761H1014.34V547.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 549.503V544.815H1024.4V549.503H1023.6ZM1021.66 547.557V546.761H1026.34V547.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 549.503V544.815H1036.4V549.503H1035.6ZM1033.66 547.557V546.761H1038.34V547.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 549.503V544.815H1048.4V549.503H1047.6ZM1045.66 547.557V546.761H1050.34V547.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 549.503V544.815H1060.4V549.503H1059.6ZM1057.66 547.557V546.761H1062.34V547.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 549.503V544.815H1072.4V549.503H1071.6ZM1069.66 547.557V546.761H1074.34V547.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 549.503V544.815H1084.4V549.503H1083.6ZM1081.66 547.557V546.761H1086.34V547.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 549.503V544.815H1096.4V549.503H1095.6ZM1093.66 547.557V546.761H1098.34V547.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 549.503V544.815H1108.4V549.503H1107.6ZM1105.66 547.557V546.761H1110.34V547.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 549.503V544.815H1120.4V549.503H1119.6ZM1117.66 547.557V546.761H1122.34V547.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 549.503V544.815H1132.4V549.503H1131.6ZM1129.66 547.557V546.761H1134.34V547.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 549.503V544.815H1144.4V549.503H1143.6ZM1141.66 547.557V546.761H1146.34V547.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 549.503V544.815H1156.4V549.503H1155.6ZM1153.66 547.557V546.761H1158.34V547.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 561.503V556.815H4.39728V561.503H3.60183ZM1.65581 559.557V558.761H6.34331V559.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 561.503V556.815H16.3973V561.503H15.6018ZM13.6558 559.557V558.761H18.3433V559.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 561.503V556.815H28.3973V561.503H27.6018ZM25.6558 559.557V558.761H30.3433V559.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 561.503V556.815H40.3973V561.503H39.6018ZM37.6558 559.557V558.761H42.3433V559.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 561.503V556.815H52.3973V561.503H51.6018ZM49.6558 559.557V558.761H54.3433V559.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 561.503V556.815H64.3973V561.503H63.6018ZM61.6558 559.557V558.761H66.3433V559.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 561.503V556.815H76.3973V561.503H75.6018ZM73.6558 559.557V558.761H78.3433V559.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 561.503V556.815H88.3973V561.503H87.6018ZM85.6558 559.557V558.761H90.3433V559.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 561.503V556.815H100.397V561.503H99.6018ZM97.6558 559.557V558.761H102.343V559.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 561.503V556.815H112.397V561.503H111.602ZM109.656 559.557V558.761H114.343V559.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 561.503V556.815H124.397V561.503H123.602ZM121.656 559.557V558.761H126.343V559.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 561.503V556.815H136.397V561.503H135.602ZM133.656 559.557V558.761H138.343V559.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 561.503V556.815H148.397V561.503H147.602ZM145.656 559.557V558.761H150.343V559.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 561.503V556.815H160.397V561.503H159.602ZM157.656 559.557V558.761H162.343V559.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 561.503V556.815H172.397V561.503H171.602ZM169.656 559.557V558.761H174.343V559.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 561.503V556.815H184.397V561.503H183.602ZM181.656 559.557V558.761H186.343V559.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 561.503V556.815H196.397V561.503H195.602ZM193.656 559.557V558.761H198.343V559.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 561.503V556.815H208.397V561.503H207.602ZM205.656 559.557V558.761H210.343V559.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 561.503V556.815H220.397V561.503H219.602ZM217.656 559.557V558.761H222.343V559.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 561.503V556.815H232.397V561.503H231.602ZM229.656 559.557V558.761H234.343V559.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 561.503V556.815H244.397V561.503H243.602ZM241.656 559.557V558.761H246.343V559.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 561.503V556.815H256.397V561.503H255.602ZM253.656 559.557V558.761H258.343V559.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 561.503V556.815H268.397V561.503H267.602ZM265.656 559.557V558.761H270.343V559.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 561.503V556.815H280.397V561.503H279.602ZM277.656 559.557V558.761H282.343V559.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 561.503V556.815H292.397V561.503H291.602ZM289.656 559.557V558.761H294.343V559.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 561.503V556.815H304.397V561.503H303.602ZM301.656 559.557V558.761H306.343V559.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 561.503V556.815H316.397V561.503H315.602ZM313.656 559.557V558.761H318.343V559.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 561.503V556.815H328.397V561.503H327.602ZM325.656 559.557V558.761H330.343V559.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 561.503V556.815H340.397V561.503H339.602ZM337.656 559.557V558.761H342.343V559.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 561.503V556.815H352.397V561.503H351.602ZM349.656 559.557V558.761H354.343V559.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 561.503V556.815H364.397V561.503H363.602ZM361.656 559.557V558.761H366.343V559.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 561.503V556.815H376.397V561.503H375.602ZM373.656 559.557V558.761H378.343V559.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 561.503V556.815H388.397V561.503H387.602ZM385.656 559.557V558.761H390.343V559.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 561.503V556.815H400.397V561.503H399.602ZM397.656 559.557V558.761H402.343V559.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 561.503V556.815H412.397V561.503H411.602ZM409.656 559.557V558.761H414.343V559.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 561.503V556.815H424.397V561.503H423.602ZM421.656 559.557V558.761H426.343V559.557H421.656Z" fill="#01256C"/>
+<path d="M519.602 561.503V556.815H520.397V561.503H519.602ZM517.656 559.557V558.761H522.343V559.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 561.503V556.815H532.397V561.503H531.602ZM529.656 559.557V558.761H534.343V559.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 561.503V556.815H544.397V561.503H543.602ZM541.656 559.557V558.761H546.343V559.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 561.503V556.815H556.397V561.503H555.602ZM553.656 559.557V558.761H558.343V559.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 561.503V556.815H568.397V561.503H567.602ZM565.656 559.557V558.761H570.343V559.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 561.503V556.815H580.397V561.503H579.602ZM577.656 559.557V558.761H582.343V559.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 561.503V556.815H592.397V561.503H591.602ZM589.656 559.557V558.761H594.343V559.557H589.656Z" fill="#01256C"/>
+<path d="M903.659 558.818L903.716 557.256L902.395 558.094L902.054 557.497L903.446 556.773L902.054 556.048L902.395 555.452L903.716 556.29L903.659 554.727H904.341L904.284 556.29L905.605 555.452L905.946 556.048L904.554 556.773L905.946 557.497L905.605 558.094L904.284 557.256L904.341 558.818H903.659Z" fill="#01256C"/>
+<path d="M915.602 561.503V556.815H916.397V561.503H915.602ZM913.656 559.557V558.761H918.343V559.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 561.503V556.815H928.397V561.503H927.602ZM925.656 559.557V558.761H930.343V559.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 561.503V556.815H940.397V561.503H939.602ZM937.656 559.557V558.761H942.343V559.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 561.503V556.815H952.397V561.503H951.602ZM949.656 559.557V558.761H954.343V559.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 561.503V556.815H964.397V561.503H963.602ZM961.656 559.557V558.761H966.343V559.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 561.503V556.815H976.397V561.503H975.602ZM973.656 559.557V558.761H978.343V559.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 561.503V556.815H988.397V561.503H987.602ZM985.656 559.557V558.761H990.343V559.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 561.503V556.815H1000.4V561.503H999.602ZM997.656 559.557V558.761H1002.34V559.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 561.503V556.815H1012.4V561.503H1011.6ZM1009.66 559.557V558.761H1014.34V559.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 561.503V556.815H1024.4V561.503H1023.6ZM1021.66 559.557V558.761H1026.34V559.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 561.503V556.815H1036.4V561.503H1035.6ZM1033.66 559.557V558.761H1038.34V559.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 561.503V556.815H1048.4V561.503H1047.6ZM1045.66 559.557V558.761H1050.34V559.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 561.503V556.815H1060.4V561.503H1059.6ZM1057.66 559.557V558.761H1062.34V559.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 561.503V556.815H1072.4V561.503H1071.6ZM1069.66 559.557V558.761H1074.34V559.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 561.503V556.815H1084.4V561.503H1083.6ZM1081.66 559.557V558.761H1086.34V559.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 561.503V556.815H1096.4V561.503H1095.6ZM1093.66 559.557V558.761H1098.34V559.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 561.503V556.815H1108.4V561.503H1107.6ZM1105.66 559.557V558.761H1110.34V559.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 561.503V556.815H1120.4V561.503H1119.6ZM1117.66 559.557V558.761H1122.34V559.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 561.503V556.815H1132.4V561.503H1131.6ZM1129.66 559.557V558.761H1134.34V559.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 561.503V556.815H1144.4V561.503H1143.6ZM1141.66 559.557V558.761H1146.34V559.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 561.503V556.815H1156.4V561.503H1155.6ZM1153.66 559.557V558.761H1158.34V559.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 573.503V568.815H4.39728V573.503H3.60183ZM1.65581 571.557V570.761H6.34331V571.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 573.503V568.815H16.3973V573.503H15.6018ZM13.6558 571.557V570.761H18.3433V571.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 573.503V568.815H28.3973V573.503H27.6018ZM25.6558 571.557V570.761H30.3433V571.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 573.503V568.815H40.3973V573.503H39.6018ZM37.6558 571.557V570.761H42.3433V571.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 573.503V568.815H52.3973V573.503H51.6018ZM49.6558 571.557V570.761H54.3433V571.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 573.503V568.815H64.3973V573.503H63.6018ZM61.6558 571.557V570.761H66.3433V571.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 573.503V568.815H76.3973V573.503H75.6018ZM73.6558 571.557V570.761H78.3433V571.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 573.503V568.815H88.3973V573.503H87.6018ZM85.6558 571.557V570.761H90.3433V571.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 573.503V568.815H100.397V573.503H99.6018ZM97.6558 571.557V570.761H102.343V571.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 573.503V568.815H112.397V573.503H111.602ZM109.656 571.557V570.761H114.343V571.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 573.503V568.815H124.397V573.503H123.602ZM121.656 571.557V570.761H126.343V571.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 573.503V568.815H136.397V573.503H135.602ZM133.656 571.557V570.761H138.343V571.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 573.503V568.815H148.397V573.503H147.602ZM145.656 571.557V570.761H150.343V571.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 573.503V568.815H160.397V573.503H159.602ZM157.656 571.557V570.761H162.343V571.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 573.503V568.815H172.397V573.503H171.602ZM169.656 571.557V570.761H174.343V571.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 573.503V568.815H184.397V573.503H183.602ZM181.656 571.557V570.761H186.343V571.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 573.503V568.815H196.397V573.503H195.602ZM193.656 571.557V570.761H198.343V571.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 573.503V568.815H208.397V573.503H207.602ZM205.656 571.557V570.761H210.343V571.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 573.503V568.815H220.397V573.503H219.602ZM217.656 571.557V570.761H222.343V571.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 573.503V568.815H232.397V573.503H231.602ZM229.656 571.557V570.761H234.343V571.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 573.503V568.815H244.397V573.503H243.602ZM241.656 571.557V570.761H246.343V571.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 573.503V568.815H256.397V573.503H255.602ZM253.656 571.557V570.761H258.343V571.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 573.503V568.815H268.397V573.503H267.602ZM265.656 571.557V570.761H270.343V571.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 573.503V568.815H280.397V573.503H279.602ZM277.656 571.557V570.761H282.343V571.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 573.503V568.815H292.397V573.503H291.602ZM289.656 571.557V570.761H294.343V571.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 573.503V568.815H304.397V573.503H303.602ZM301.656 571.557V570.761H306.343V571.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 573.503V568.815H316.397V573.503H315.602ZM313.656 571.557V570.761H318.343V571.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 573.503V568.815H328.397V573.503H327.602ZM325.656 571.557V570.761H330.343V571.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 573.503V568.815H340.397V573.503H339.602ZM337.656 571.557V570.761H342.343V571.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 573.503V568.815H352.397V573.503H351.602ZM349.656 571.557V570.761H354.343V571.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 573.503V568.815H364.397V573.503H363.602ZM361.656 571.557V570.761H366.343V571.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 573.503V568.815H376.397V573.503H375.602ZM373.656 571.557V570.761H378.343V571.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 573.503V568.815H388.397V573.503H387.602ZM385.656 571.557V570.761H390.343V571.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 573.503V568.815H400.397V573.503H399.602ZM397.656 571.557V570.761H402.343V571.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 573.503V568.815H412.397V573.503H411.602ZM409.656 571.557V570.761H414.343V571.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 573.503V568.815H424.397V573.503H423.602ZM421.656 571.557V570.761H426.343V571.557H421.656Z" fill="#01256C"/>
+<path d="M519.602 573.503V568.815H520.397V573.503H519.602ZM517.656 571.557V570.761H522.343V571.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 573.503V568.815H532.397V573.503H531.602ZM529.656 571.557V570.761H534.343V571.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 573.503V568.815H544.397V573.503H543.602ZM541.656 571.557V570.761H546.343V571.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 573.503V568.815H556.397V573.503H555.602ZM553.656 571.557V570.761H558.343V571.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 573.503V568.815H568.397V573.503H567.602ZM565.656 571.557V570.761H570.343V571.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 573.503V568.815H580.397V573.503H579.602ZM577.656 571.557V570.761H582.343V571.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 573.503V568.815H592.397V573.503H591.602ZM589.656 571.557V570.761H594.343V571.557H589.656Z" fill="#01256C"/>
+<path d="M855.659 570.818L855.716 569.256L854.395 570.094L854.054 569.497L855.446 568.773L854.054 568.048L854.395 567.452L855.716 568.29L855.659 566.727H856.341L856.284 568.29L857.605 567.452L857.946 568.048L856.554 568.773L857.946 569.497L857.605 570.094L856.284 569.256L856.341 570.818H855.659Z" fill="#01256C"/>
+<path d="M867.602 573.503V568.815H868.397V573.503H867.602ZM865.656 571.557V570.761H870.343V571.557H865.656Z" fill="#01256C"/>
+<path d="M879.602 573.503V568.815H880.397V573.503H879.602ZM877.656 571.557V570.761H882.343V571.557H877.656Z" fill="#01256C"/>
+<path d="M891.602 573.503V568.815H892.397V573.503H891.602ZM889.656 571.557V570.761H894.343V571.557H889.656Z" fill="#01256C"/>
+<path d="M903.602 573.503V568.815H904.397V573.503H903.602ZM901.656 571.557V570.761H906.343V571.557H901.656Z" fill="#01256C"/>
+<path d="M915.602 573.503V568.815H916.397V573.503H915.602ZM913.656 571.557V570.761H918.343V571.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 573.503V568.815H928.397V573.503H927.602ZM925.656 571.557V570.761H930.343V571.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 573.503V568.815H940.397V573.503H939.602ZM937.656 571.557V570.761H942.343V571.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 573.503V568.815H952.397V573.503H951.602ZM949.656 571.557V570.761H954.343V571.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 573.503V568.815H964.397V573.503H963.602ZM961.656 571.557V570.761H966.343V571.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 573.503V568.815H976.397V573.503H975.602ZM973.656 571.557V570.761H978.343V571.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 573.503V568.815H988.397V573.503H987.602ZM985.656 571.557V570.761H990.343V571.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 573.503V568.815H1000.4V573.503H999.602ZM997.656 571.557V570.761H1002.34V571.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 573.503V568.815H1012.4V573.503H1011.6ZM1009.66 571.557V570.761H1014.34V571.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 573.503V568.815H1024.4V573.503H1023.6ZM1021.66 571.557V570.761H1026.34V571.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 573.503V568.815H1036.4V573.503H1035.6ZM1033.66 571.557V570.761H1038.34V571.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 573.503V568.815H1048.4V573.503H1047.6ZM1045.66 571.557V570.761H1050.34V571.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 573.503V568.815H1060.4V573.503H1059.6ZM1057.66 571.557V570.761H1062.34V571.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 573.503V568.815H1072.4V573.503H1071.6ZM1069.66 571.557V570.761H1074.34V571.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 573.503V568.815H1084.4V573.503H1083.6ZM1081.66 571.557V570.761H1086.34V571.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 573.503V568.815H1096.4V573.503H1095.6ZM1093.66 571.557V570.761H1098.34V571.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 573.503V568.815H1108.4V573.503H1107.6ZM1105.66 571.557V570.761H1110.34V571.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 573.503V568.815H1120.4V573.503H1119.6ZM1117.66 571.557V570.761H1122.34V571.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 573.503V568.815H1132.4V573.503H1131.6ZM1129.66 571.557V570.761H1134.34V571.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 573.503V568.815H1144.4V573.503H1143.6ZM1141.66 571.557V570.761H1146.34V571.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 573.503V568.815H1156.4V573.503H1155.6ZM1153.66 571.557V570.761H1158.34V571.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 585.503V580.815H4.39728V585.503H3.60183ZM1.65581 583.557V582.761H6.34331V583.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 585.503V580.815H16.3973V585.503H15.6018ZM13.6558 583.557V582.761H18.3433V583.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 585.503V580.815H28.3973V585.503H27.6018ZM25.6558 583.557V582.761H30.3433V583.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 585.503V580.815H40.3973V585.503H39.6018ZM37.6558 583.557V582.761H42.3433V583.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 585.503V580.815H52.3973V585.503H51.6018ZM49.6558 583.557V582.761H54.3433V583.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 585.503V580.815H64.3973V585.503H63.6018ZM61.6558 583.557V582.761H66.3433V583.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 585.503V580.815H76.3973V585.503H75.6018ZM73.6558 583.557V582.761H78.3433V583.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 585.503V580.815H88.3973V585.503H87.6018ZM85.6558 583.557V582.761H90.3433V583.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 585.503V580.815H100.397V585.503H99.6018ZM97.6558 583.557V582.761H102.343V583.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 585.503V580.815H112.397V585.503H111.602ZM109.656 583.557V582.761H114.343V583.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 585.503V580.815H124.397V585.503H123.602ZM121.656 583.557V582.761H126.343V583.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 585.503V580.815H136.397V585.503H135.602ZM133.656 583.557V582.761H138.343V583.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 585.503V580.815H148.397V585.503H147.602ZM145.656 583.557V582.761H150.343V583.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 585.503V580.815H160.397V585.503H159.602ZM157.656 583.557V582.761H162.343V583.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 585.503V580.815H172.397V585.503H171.602ZM169.656 583.557V582.761H174.343V583.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 585.503V580.815H184.397V585.503H183.602ZM181.656 583.557V582.761H186.343V583.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 585.503V580.815H196.397V585.503H195.602ZM193.656 583.557V582.761H198.343V583.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 585.503V580.815H208.397V585.503H207.602ZM205.656 583.557V582.761H210.343V583.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 585.503V580.815H220.397V585.503H219.602ZM217.656 583.557V582.761H222.343V583.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 585.503V580.815H232.397V585.503H231.602ZM229.656 583.557V582.761H234.343V583.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 585.503V580.815H244.397V585.503H243.602ZM241.656 583.557V582.761H246.343V583.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 585.503V580.815H256.397V585.503H255.602ZM253.656 583.557V582.761H258.343V583.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 585.503V580.815H268.397V585.503H267.602ZM265.656 583.557V582.761H270.343V583.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 585.503V580.815H280.397V585.503H279.602ZM277.656 583.557V582.761H282.343V583.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 585.503V580.815H292.397V585.503H291.602ZM289.656 583.557V582.761H294.343V583.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 585.503V580.815H304.397V585.503H303.602ZM301.656 583.557V582.761H306.343V583.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 585.503V580.815H316.397V585.503H315.602ZM313.656 583.557V582.761H318.343V583.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 585.503V580.815H328.397V585.503H327.602ZM325.656 583.557V582.761H330.343V583.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 585.503V580.815H340.397V585.503H339.602ZM337.656 583.557V582.761H342.343V583.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 585.503V580.815H352.397V585.503H351.602ZM349.656 583.557V582.761H354.343V583.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 585.503V580.815H364.397V585.503H363.602ZM361.656 583.557V582.761H366.343V583.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 585.503V580.815H376.397V585.503H375.602ZM373.656 583.557V582.761H378.343V583.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 585.503V580.815H388.397V585.503H387.602ZM385.656 583.557V582.761H390.343V583.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 585.503V580.815H400.397V585.503H399.602ZM397.656 583.557V582.761H402.343V583.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 585.503V580.815H412.397V585.503H411.602ZM409.656 583.557V582.761H414.343V583.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 585.503V580.815H424.397V585.503H423.602ZM421.656 583.557V582.761H426.343V583.557H421.656Z" fill="#01256C"/>
+<path d="M519.602 585.503V580.815H520.397V585.503H519.602ZM517.656 583.557V582.761H522.343V583.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 585.503V580.815H532.397V585.503H531.602ZM529.656 583.557V582.761H534.343V583.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 585.503V580.815H544.397V585.503H543.602ZM541.656 583.557V582.761H546.343V583.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 585.503V580.815H556.397V585.503H555.602ZM553.656 583.557V582.761H558.343V583.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 585.503V580.815H568.397V585.503H567.602ZM565.656 583.557V582.761H570.343V583.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 585.503V580.815H580.397V585.503H579.602ZM577.656 583.557V582.761H582.343V583.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 585.503V580.815H592.397V585.503H591.602ZM589.656 583.557V582.761H594.343V583.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 585.503V580.815H604.397V585.503H603.602ZM601.656 583.557V582.761H606.343V583.557H601.656Z" fill="#01256C"/>
+<path d="M819.602 585.503V580.815H820.397V585.503H819.602ZM817.656 583.557V582.761H822.343V583.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 585.503V580.815H832.397V585.503H831.602ZM829.656 583.557V582.761H834.343V583.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 585.503V580.815H844.397V585.503H843.602ZM841.656 583.557V582.761H846.343V583.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 585.503V580.815H856.397V585.503H855.602ZM853.656 583.557V582.761H858.343V583.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 585.503V580.815H868.397V585.503H867.602ZM865.656 583.557V582.761H870.343V583.557H865.656Z" fill="#01256C"/>
+<path d="M879.602 585.503V580.815H880.397V585.503H879.602ZM877.656 583.557V582.761H882.343V583.557H877.656Z" fill="#01256C"/>
+<path d="M891.602 585.503V580.815H892.397V585.503H891.602ZM889.656 583.557V582.761H894.343V583.557H889.656Z" fill="#01256C"/>
+<path d="M903.602 585.503V580.815H904.397V585.503H903.602ZM901.656 583.557V582.761H906.343V583.557H901.656Z" fill="#01256C"/>
+<path d="M915.602 585.503V580.815H916.397V585.503H915.602ZM913.656 583.557V582.761H918.343V583.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 585.503V580.815H928.397V585.503H927.602ZM925.656 583.557V582.761H930.343V583.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 585.503V580.815H940.397V585.503H939.602ZM937.656 583.557V582.761H942.343V583.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 585.503V580.815H952.397V585.503H951.602ZM949.656 583.557V582.761H954.343V583.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 585.503V580.815H964.397V585.503H963.602ZM961.656 583.557V582.761H966.343V583.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 585.503V580.815H976.397V585.503H975.602ZM973.656 583.557V582.761H978.343V583.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 585.503V580.815H988.397V585.503H987.602ZM985.656 583.557V582.761H990.343V583.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 585.503V580.815H1000.4V585.503H999.602ZM997.656 583.557V582.761H1002.34V583.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 585.503V580.815H1012.4V585.503H1011.6ZM1009.66 583.557V582.761H1014.34V583.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 585.503V580.815H1024.4V585.503H1023.6ZM1021.66 583.557V582.761H1026.34V583.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 585.503V580.815H1036.4V585.503H1035.6ZM1033.66 583.557V582.761H1038.34V583.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 585.503V580.815H1048.4V585.503H1047.6ZM1045.66 583.557V582.761H1050.34V583.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 585.503V580.815H1060.4V585.503H1059.6ZM1057.66 583.557V582.761H1062.34V583.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 585.503V580.815H1072.4V585.503H1071.6ZM1069.66 583.557V582.761H1074.34V583.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 585.503V580.815H1084.4V585.503H1083.6ZM1081.66 583.557V582.761H1086.34V583.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 585.503V580.815H1096.4V585.503H1095.6ZM1093.66 583.557V582.761H1098.34V583.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 585.503V580.815H1108.4V585.503H1107.6ZM1105.66 583.557V582.761H1110.34V583.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 585.503V580.815H1120.4V585.503H1119.6ZM1117.66 583.557V582.761H1122.34V583.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 585.503V580.815H1132.4V585.503H1131.6ZM1129.66 583.557V582.761H1134.34V583.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 585.503V580.815H1144.4V585.503H1143.6ZM1141.66 583.557V582.761H1146.34V583.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 585.503V580.815H1156.4V585.503H1155.6ZM1153.66 583.557V582.761H1158.34V583.557H1153.66Z" fill="#01256C"/>
+<path d="M3.60183 597.503V592.815H4.39728V597.503H3.60183ZM1.65581 595.557V594.761H6.34331V595.557H1.65581Z" fill="#01256C"/>
+<path d="M15.6018 597.503V592.815H16.3973V597.503H15.6018ZM13.6558 595.557V594.761H18.3433V595.557H13.6558Z" fill="#01256C"/>
+<path d="M27.6018 597.503V592.815H28.3973V597.503H27.6018ZM25.6558 595.557V594.761H30.3433V595.557H25.6558Z" fill="#01256C"/>
+<path d="M39.6018 597.503V592.815H40.3973V597.503H39.6018ZM37.6558 595.557V594.761H42.3433V595.557H37.6558Z" fill="#01256C"/>
+<path d="M51.6018 597.503V592.815H52.3973V597.503H51.6018ZM49.6558 595.557V594.761H54.3433V595.557H49.6558Z" fill="#01256C"/>
+<path d="M63.6018 597.503V592.815H64.3973V597.503H63.6018ZM61.6558 595.557V594.761H66.3433V595.557H61.6558Z" fill="#01256C"/>
+<path d="M75.6018 597.503V592.815H76.3973V597.503H75.6018ZM73.6558 595.557V594.761H78.3433V595.557H73.6558Z" fill="#01256C"/>
+<path d="M87.6018 597.503V592.815H88.3973V597.503H87.6018ZM85.6558 595.557V594.761H90.3433V595.557H85.6558Z" fill="#01256C"/>
+<path d="M99.6018 597.503V592.815H100.397V597.503H99.6018ZM97.6558 595.557V594.761H102.343V595.557H97.6558Z" fill="#01256C"/>
+<path d="M111.602 597.503V592.815H112.397V597.503H111.602ZM109.656 595.557V594.761H114.343V595.557H109.656Z" fill="#01256C"/>
+<path d="M123.602 597.503V592.815H124.397V597.503H123.602ZM121.656 595.557V594.761H126.343V595.557H121.656Z" fill="#01256C"/>
+<path d="M135.602 597.503V592.815H136.397V597.503H135.602ZM133.656 595.557V594.761H138.343V595.557H133.656Z" fill="#01256C"/>
+<path d="M147.602 597.503V592.815H148.397V597.503H147.602ZM145.656 595.557V594.761H150.343V595.557H145.656Z" fill="#01256C"/>
+<path d="M159.602 597.503V592.815H160.397V597.503H159.602ZM157.656 595.557V594.761H162.343V595.557H157.656Z" fill="#01256C"/>
+<path d="M171.602 597.503V592.815H172.397V597.503H171.602ZM169.656 595.557V594.761H174.343V595.557H169.656Z" fill="#01256C"/>
+<path d="M183.602 597.503V592.815H184.397V597.503H183.602ZM181.656 595.557V594.761H186.343V595.557H181.656Z" fill="#01256C"/>
+<path d="M195.602 597.503V592.815H196.397V597.503H195.602ZM193.656 595.557V594.761H198.343V595.557H193.656Z" fill="#01256C"/>
+<path d="M207.602 597.503V592.815H208.397V597.503H207.602ZM205.656 595.557V594.761H210.343V595.557H205.656Z" fill="#01256C"/>
+<path d="M219.602 597.503V592.815H220.397V597.503H219.602ZM217.656 595.557V594.761H222.343V595.557H217.656Z" fill="#01256C"/>
+<path d="M231.602 597.503V592.815H232.397V597.503H231.602ZM229.656 595.557V594.761H234.343V595.557H229.656Z" fill="#01256C"/>
+<path d="M243.602 597.503V592.815H244.397V597.503H243.602ZM241.656 595.557V594.761H246.343V595.557H241.656Z" fill="#01256C"/>
+<path d="M255.602 597.503V592.815H256.397V597.503H255.602ZM253.656 595.557V594.761H258.343V595.557H253.656Z" fill="#01256C"/>
+<path d="M267.602 597.503V592.815H268.397V597.503H267.602ZM265.656 595.557V594.761H270.343V595.557H265.656Z" fill="#01256C"/>
+<path d="M279.602 597.503V592.815H280.397V597.503H279.602ZM277.656 595.557V594.761H282.343V595.557H277.656Z" fill="#01256C"/>
+<path d="M291.602 597.503V592.815H292.397V597.503H291.602ZM289.656 595.557V594.761H294.343V595.557H289.656Z" fill="#01256C"/>
+<path d="M303.602 597.503V592.815H304.397V597.503H303.602ZM301.656 595.557V594.761H306.343V595.557H301.656Z" fill="#01256C"/>
+<path d="M315.602 597.503V592.815H316.397V597.503H315.602ZM313.656 595.557V594.761H318.343V595.557H313.656Z" fill="#01256C"/>
+<path d="M327.602 597.503V592.815H328.397V597.503H327.602ZM325.656 595.557V594.761H330.343V595.557H325.656Z" fill="#01256C"/>
+<path d="M339.602 597.503V592.815H340.397V597.503H339.602ZM337.656 595.557V594.761H342.343V595.557H337.656Z" fill="#01256C"/>
+<path d="M351.602 597.503V592.815H352.397V597.503H351.602ZM349.656 595.557V594.761H354.343V595.557H349.656Z" fill="#01256C"/>
+<path d="M363.602 597.503V592.815H364.397V597.503H363.602ZM361.656 595.557V594.761H366.343V595.557H361.656Z" fill="#01256C"/>
+<path d="M375.602 597.503V592.815H376.397V597.503H375.602ZM373.656 595.557V594.761H378.343V595.557H373.656Z" fill="#01256C"/>
+<path d="M387.602 597.503V592.815H388.397V597.503H387.602ZM385.656 595.557V594.761H390.343V595.557H385.656Z" fill="#01256C"/>
+<path d="M399.602 597.503V592.815H400.397V597.503H399.602ZM397.656 595.557V594.761H402.343V595.557H397.656Z" fill="#01256C"/>
+<path d="M411.602 597.503V592.815H412.397V597.503H411.602ZM409.656 595.557V594.761H414.343V595.557H409.656Z" fill="#01256C"/>
+<path d="M423.602 597.503V592.815H424.397V597.503H423.602ZM421.656 595.557V594.761H426.343V595.557H421.656Z" fill="#01256C"/>
+<path d="M519.602 597.503V592.815H520.397V597.503H519.602ZM517.656 595.557V594.761H522.343V595.557H517.656Z" fill="#01256C"/>
+<path d="M531.602 597.503V592.815H532.397V597.503H531.602ZM529.656 595.557V594.761H534.343V595.557H529.656Z" fill="#01256C"/>
+<path d="M543.602 597.503V592.815H544.397V597.503H543.602ZM541.656 595.557V594.761H546.343V595.557H541.656Z" fill="#01256C"/>
+<path d="M555.602 597.503V592.815H556.397V597.503H555.602ZM553.656 595.557V594.761H558.343V595.557H553.656Z" fill="#01256C"/>
+<path d="M567.602 597.503V592.815H568.397V597.503H567.602ZM565.656 595.557V594.761H570.343V595.557H565.656Z" fill="#01256C"/>
+<path d="M579.602 597.503V592.815H580.397V597.503H579.602ZM577.656 595.557V594.761H582.343V595.557H577.656Z" fill="#01256C"/>
+<path d="M591.602 597.503V592.815H592.397V597.503H591.602ZM589.656 595.557V594.761H594.343V595.557H589.656Z" fill="#01256C"/>
+<path d="M603.602 597.503V592.815H604.397V597.503H603.602ZM601.656 595.557V594.761H606.343V595.557H601.656Z" fill="#01256C"/>
+<path d="M783.602 597.503V592.815H784.397V597.503H783.602ZM781.656 595.557V594.761H786.343V595.557H781.656Z" fill="#01256C"/>
+<path d="M795.602 597.503V592.815H796.397V597.503H795.602ZM793.656 595.557V594.761H798.343V595.557H793.656Z" fill="#01256C"/>
+<path d="M807.602 597.503V592.815H808.397V597.503H807.602ZM805.656 595.557V594.761H810.343V595.557H805.656Z" fill="#01256C"/>
+<path d="M819.602 597.503V592.815H820.397V597.503H819.602ZM817.656 595.557V594.761H822.343V595.557H817.656Z" fill="#01256C"/>
+<path d="M831.602 597.503V592.815H832.397V597.503H831.602ZM829.656 595.557V594.761H834.343V595.557H829.656Z" fill="#01256C"/>
+<path d="M843.602 597.503V592.815H844.397V597.503H843.602ZM841.656 595.557V594.761H846.343V595.557H841.656Z" fill="#01256C"/>
+<path d="M855.602 597.503V592.815H856.397V597.503H855.602ZM853.656 595.557V594.761H858.343V595.557H853.656Z" fill="#01256C"/>
+<path d="M867.602 597.503V592.815H868.397V597.503H867.602ZM865.656 595.557V594.761H870.343V595.557H865.656Z" fill="#01256C"/>
+<path d="M879.602 597.503V592.815H880.397V597.503H879.602ZM877.656 595.557V594.761H882.343V595.557H877.656Z" fill="#01256C"/>
+<path d="M891.602 597.503V592.815H892.397V597.503H891.602ZM889.656 595.557V594.761H894.343V595.557H889.656Z" fill="#01256C"/>
+<path d="M903.602 597.503V592.815H904.397V597.503H903.602ZM901.656 595.557V594.761H906.343V595.557H901.656Z" fill="#01256C"/>
+<path d="M915.602 597.503V592.815H916.397V597.503H915.602ZM913.656 595.557V594.761H918.343V595.557H913.656Z" fill="#01256C"/>
+<path d="M927.602 597.503V592.815H928.397V597.503H927.602ZM925.656 595.557V594.761H930.343V595.557H925.656Z" fill="#01256C"/>
+<path d="M939.602 597.503V592.815H940.397V597.503H939.602ZM937.656 595.557V594.761H942.343V595.557H937.656Z" fill="#01256C"/>
+<path d="M951.602 597.503V592.815H952.397V597.503H951.602ZM949.656 595.557V594.761H954.343V595.557H949.656Z" fill="#01256C"/>
+<path d="M963.602 597.503V592.815H964.397V597.503H963.602ZM961.656 595.557V594.761H966.343V595.557H961.656Z" fill="#01256C"/>
+<path d="M975.602 597.503V592.815H976.397V597.503H975.602ZM973.656 595.557V594.761H978.343V595.557H973.656Z" fill="#01256C"/>
+<path d="M987.602 597.503V592.815H988.397V597.503H987.602ZM985.656 595.557V594.761H990.343V595.557H985.656Z" fill="#01256C"/>
+<path d="M999.602 597.503V592.815H1000.4V597.503H999.602ZM997.656 595.557V594.761H1002.34V595.557H997.656Z" fill="#01256C"/>
+<path d="M1011.6 597.503V592.815H1012.4V597.503H1011.6ZM1009.66 595.557V594.761H1014.34V595.557H1009.66Z" fill="#01256C"/>
+<path d="M1023.6 597.503V592.815H1024.4V597.503H1023.6ZM1021.66 595.557V594.761H1026.34V595.557H1021.66Z" fill="#01256C"/>
+<path d="M1035.6 597.503V592.815H1036.4V597.503H1035.6ZM1033.66 595.557V594.761H1038.34V595.557H1033.66Z" fill="#01256C"/>
+<path d="M1047.6 597.503V592.815H1048.4V597.503H1047.6ZM1045.66 595.557V594.761H1050.34V595.557H1045.66Z" fill="#01256C"/>
+<path d="M1059.6 597.503V592.815H1060.4V597.503H1059.6ZM1057.66 595.557V594.761H1062.34V595.557H1057.66Z" fill="#01256C"/>
+<path d="M1071.6 597.503V592.815H1072.4V597.503H1071.6ZM1069.66 595.557V594.761H1074.34V595.557H1069.66Z" fill="#01256C"/>
+<path d="M1083.6 597.503V592.815H1084.4V597.503H1083.6ZM1081.66 595.557V594.761H1086.34V595.557H1081.66Z" fill="#01256C"/>
+<path d="M1095.6 597.503V592.815H1096.4V597.503H1095.6ZM1093.66 595.557V594.761H1098.34V595.557H1093.66Z" fill="#01256C"/>
+<path d="M1107.6 597.503V592.815H1108.4V597.503H1107.6ZM1105.66 595.557V594.761H1110.34V595.557H1105.66Z" fill="#01256C"/>
+<path d="M1119.6 597.503V592.815H1120.4V597.503H1119.6ZM1117.66 595.557V594.761H1122.34V595.557H1117.66Z" fill="#01256C"/>
+<path d="M1131.6 597.503V592.815H1132.4V597.503H1131.6ZM1129.66 595.557V594.761H1134.34V595.557H1129.66Z" fill="#01256C"/>
+<path d="M1143.6 597.503V592.815H1144.4V597.503H1143.6ZM1141.66 595.557V594.761H1146.34V595.557H1141.66Z" fill="#01256C"/>
+<path d="M1155.6 597.503V592.815H1156.4V597.503H1155.6ZM1153.66 595.557V594.761H1158.34V595.557H1153.66Z" fill="#01256C"/>
+</g>
+<rect x="0.5" y="0.5" width="1157" height="597" stroke="#E7EAEF"/>
+</g>
+<defs>
+<clipPath id="clip0_1_6">
+<rect width="1158" height="598" fill="white"/>
+</clipPath>
+</defs>
+</svg>
diff --git a/static/assets/images/favicon-192x192.png b/static/assets/images/favicon-192x192.png
new file mode 100644
index 000000000000..44ea86081357
Binary files /dev/null and b/static/assets/images/favicon-192x192.png differ
diff --git a/static/assets/images/favicon-32x32.png b/static/assets/images/favicon-32x32.png
new file mode 100644
index 000000000000..f37200f719a2
Binary files /dev/null and b/static/assets/images/favicon-32x32.png differ
diff --git a/static/assets/images/feedback-widget.png b/static/assets/images/feedback-widget.png
deleted file mode 100644
index cb5bafd042b3..000000000000
Binary files a/static/assets/images/feedback-widget.png and /dev/null differ
diff --git a/static/assets/images/footer_moby_icon.png b/static/assets/images/footer_moby_icon.png
deleted file mode 100644
index 05898956810a..000000000000
Binary files a/static/assets/images/footer_moby_icon.png and /dev/null differ
diff --git a/static/assets/images/linux_48.svg b/static/assets/images/linux_48.svg
deleted file mode 100644
index b722087326ae..000000000000
--- a/static/assets/images/linux_48.svg
+++ /dev/null
@@ -1,17 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg width="48px" height="48px" viewBox="0 0 48 48" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-    <!-- Generator: Sketch 42 (36781) - http://www.bohemiancoding.com/sketch -->
-    <title>linux_48</title>
-    <desc>Created with Sketch.</desc>
-    <defs></defs>
-    <g id="Page-1" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
-        <g id="linux_48">
-            <rect id="Rectangle-33" x="0" y="0" width="48" height="48"></rect>
-            <g transform="translate(8.000000, 6.000000)" id="Shape" fill="#2089C4">
-                <g>
-                    <path d="M31.104,28.654 C30.124,28.274 29.318,27.674 29.376,26.524 C29.433,25.377 28.511,24.617 28.511,24.617 C28.511,24.617 29.318,22.104 28.568,20.03 C27.819,17.952 25.343,14.624 23.442,12.113 C21.545,9.6 23.156,6.705 21.429,2.994 C19.699,-0.717 15.209,-0.499 12.789,1.084 C10.369,2.666 11.117,6.596 11.231,8.456 C11.346,10.31 11.283,11.631 11.06,12.111 C10.832,12.591 9.275,14.352 8.237,15.825 C7.2,17.298 6.452,20.357 5.7,21.612 C4.952,22.868 5.47,24.014 5.47,24.014 C5.47,24.014 4.952,24.176 4.548,24.999 C4.145,25.815 3.339,26.198 1.899,26.468 C0.459,26.74 0.459,27.618 0.804,28.6 C1.151,29.581 0.806,30.13 0.402,31.383 C-0.001,32.635 2.015,33.021 3.972,33.235 C5.932,33.456 8.12,34.657 9.965,34.875 C11.805,35.094 12.383,33.675 12.383,33.675 C12.383,33.675 14.456,33.235 16.643,33.185 C18.833,33.129 20.903,33.621 20.903,33.621 C20.903,33.621 21.306,34.494 22.055,34.875 C22.805,35.258 24.417,35.313 25.454,34.278 C26.492,33.238 29.256,31.93 30.81,31.11 C32.369,30.288 32.084,29.034 31.104,28.654 L31.104,28.654 Z M17.625,4.578 C18.613,4.578 19.41,5.507 19.41,6.651 C19.41,7.464 19.01,8.165 18.426,8.505 C18.277,8.443 18.121,8.38 17.954,8.313 C18.306,8.148 18.556,7.723 18.556,7.228 C18.556,6.584 18.135,6.06 17.614,6.06 C17.1,6.06 16.677,6.585 16.677,7.228 C16.677,7.467 16.737,7.697 16.84,7.884 C16.533,7.769 16.25,7.66 16.029,7.581 C15.9033021,7.28711259 15.8389864,6.97063847 15.84,6.651 C15.84,5.507 16.638,4.578 17.625,4.578 L17.625,4.578 Z M17.497,8.949 C17.991,9.111 18.54,9.415 18.483,9.717 C18.424,10.02 18.165,10.02 17.497,10.407 C16.827,10.791 15.378,11.643 14.915,11.698 C14.448,11.754 14.188,11.506 13.695,11.205 C13.201,10.902 12.272,10.184 12.506,9.801 C12.506,9.801 13.229,9.276 13.547,9.001 C13.867,8.725 14.68,8.067 15.174,8.152 C15.668,8.232 17.004,8.784 17.497,8.949 L17.497,8.949 Z M13.046,4.907 C13.824,4.907 14.457,5.786 14.457,6.87 C14.457,7.07 14.437,7.254 14.397,7.433 C14.207,7.494 14.014,7.593 13.827,7.743 C13.7389343,7.81152334 13.6525746,7.88221156 13.568,7.955 C13.691,7.735 13.74,7.424 13.685,7.095 C13.581,6.503 13.165,6.071 12.751,6.132 C12.34,6.2 12.091,6.732 12.196,7.328 C12.302,7.923 12.716,8.355 13.128,8.291 C13.1516771,8.28642647 13.1750537,8.28041534 13.198,8.273 C12.997,8.456 12.812,8.613 12.623,8.747 C12.053,8.496 11.636,7.751 11.636,6.869 C11.636,5.784 12.267,4.907 13.046,4.907 L13.046,4.907 Z M11.526,32.493 C11.342,33.276 10.375,33.844 10.375,33.844 C9.498,34.105 7.061,33.104 5.957,32.664 C4.854,32.23 2.045,32.095 1.677,31.708 C1.311,31.313 1.86,30.441 2.001,29.615 C2.137,28.782 1.725,28.261 1.861,27.693 C2.001,27.127 3.795,27.127 4.483,26.736 C5.175,26.341 5.313,25.207 5.865,24.903 C6.417,24.595 7.428,25.686 7.843,26.299 C8.256,26.907 9.821,29.526 10.465,30.18 C11.111,30.834 11.709,31.71 11.525,32.493 L11.526,32.493 Z M21.711,24.885 C21.545,25.655 21.545,28.435 21.545,28.435 C21.545,28.435 19.76,30.78 16.992,31.164 C14.228,31.548 12.845,31.272 12.845,31.272 L11.291,29.582 C11.291,29.582 12.498,29.415 12.327,28.269 C12.153,27.123 8.642,25.539 8.007,24.119 C7.376,22.701 7.893,20.297 8.7,19.095 C9.506,17.895 10.022,15.276 10.829,14.4 C11.636,13.53 12.267,11.673 11.979,10.852 C11.979,10.852 13.707,12.819 14.915,12.493 C16.124,12.165 18.835,10.253 19.235,10.583 C19.637,10.911 23.093,18.115 23.436,20.409 C23.783,22.701 23.205,24.447 23.205,24.447 C23.205,24.447 21.882,24.12 21.711,24.885 L21.711,24.885 Z M30.551,30.028 C30.012,30.497 27.019,31.642 26.121,32.536 C25.229,33.423 24.063,34.144 23.349,33.934 C22.631,33.72 22.005,32.789 22.319,31.43 C22.631,30.075 22.901,28.59 22.857,27.741 C22.812,26.892 22.631,25.744 22.857,25.575 C23.08,25.41 23.436,25.493 23.436,25.493 C23.436,25.493 23.26,27.102 24.287,27.53 C25.314,27.95 26.792,27.36 27.24,26.933 C27.69,26.511 28.003,25.875 28.003,25.875 C28.003,25.875 28.449,26.09 28.405,26.766 C28.36,27.444 28.716,28.422 29.391,28.76 C30.06,29.094 31.089,29.564 30.551,30.029 L30.551,30.028 Z"></path>
-                </g>
-            </g>
-        </g>
-    </g>
-</svg>
\ No newline at end of file
diff --git a/static/assets/images/windows_48.svg b/static/assets/images/windows_48.svg
deleted file mode 100644
index 2d5cb4a9cdd0..000000000000
--- a/static/assets/images/windows_48.svg
+++ /dev/null
@@ -1,17 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg width="48px" height="48px" viewBox="0 0 48 48" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-    <!-- Generator: Sketch 42 (36781) - http://www.bohemiancoding.com/sketch -->
-    <title>windows_48</title>
-    <desc>Created with Sketch.</desc>
-    <defs></defs>
-    <g id="Page-1" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
-        <g id="windows_48">
-            <rect id="Rectangle-33" x="0" y="0" width="48" height="48"></rect>
-            <g id="Windows-Icon-(For-Editions-Header)-(1)" transform="translate(8.000000, 8.000000)" fill="#2089C4">
-                <g id="windows_48">
-                    <path d="M0,4.527 L13.077,2.753 L13.083,15.318 L0.012,15.392 L0,4.527 Z M13.071,16.766 L13.081,29.342 L0.011,27.552 L0.009,16.682 L13.071,16.766 L13.071,16.766 Z M14.656,2.52 L31.996,0 L31.996,15.158 L14.656,15.295 L14.656,2.521 L14.656,2.52 Z M32,16.884 L31.996,31.974 L14.656,29.536 L14.632,16.856 L32,16.884 Z" id="Shape"></path>
-                </g>
-            </g>
-        </g>
-    </g>
-</svg>
\ No newline at end of file
diff --git a/static/favicon.ico b/static/favicon.ico
new file mode 100644
index 000000000000..8e1af6dc996e
Binary files /dev/null and b/static/favicon.ico differ
diff --git a/tailwind.config.js b/tailwind.config.js
deleted file mode 100644
index b71287b50f00..000000000000
--- a/tailwind.config.js
+++ /dev/null
@@ -1,271 +0,0 @@
-/** @type {import('tailwindcss').Config} */
-module.exports = {
-  content: ["./hugo_stats.json", "layouts/**/*.html", "assets/**/*.js"],
-  darkMode: "class",
-  theme: {
-    extend: {
-      typography: (theme) => ({
-        DEFAULT: {
-          css: {
-            pre: false,
-            code: false,
-            'pre code': false,
-            'code::before': false,
-            'code::after': false,
-            blockquote: false,
-            'blockquote p:first-of-type::before': false,
-            'blockquote p:last-of-type::after': false,
-            // light colors for prose
-            "--tw-prose-body": theme("colors.black"),
-            "--tw-prose-headings": theme("colors.black"),
-            "--tw-prose-lead": theme("colors.gray.light.600"),
-            "--tw-prose-links": theme("colors.blue.light.500"),
-            "--tw-prose-bold": theme("colors.black"),
-            "--tw-prose-counters": theme("colors.black"),
-            "--tw-prose-bullets": theme("colors.black"),
-            "--tw-prose-hr": theme("colors.divider.light"),
-            "--tw-prose-captions": theme("colors.gray.light.600"),
-            "--tw-prose-th-borders": theme("colors.gray.light.200"),
-            "--tw-prose-td-borders": theme("colors.gray.light.200"),
-
-            // dark colors for prose
-            "--tw-prose-invert-body": theme("colors.white"),
-            "--tw-prose-invert-headings": theme("colors.white"),
-            "--tw-prose-invert-lead": theme("colors.gray.dark.600"),
-            "--tw-prose-invert-links": theme("colors.blue.dark.500"),
-            "--tw-prose-invert-bold": theme("colors.white"),
-            "--tw-prose-invert-counters": theme("colors.white"),
-            "--tw-prose-invert-bullets": theme("colors.white"),
-            "--tw-prose-invert-hr": theme("colors.divider.dark"),
-            "--tw-prose-invert-captions": theme("colors.gray.dark.600"),
-            "--tw-prose-invert-th-borders": theme("colors.gray.dark.200"),
-            "--tw-prose-invert-td-borders": theme("colors.gray.dark.300"),
-          },
-        },
-      }),
-    },
-
-    // theme values
-    fontSize: {
-      xs: ["0.7143rem", { letterSpacing: "0.015em", fontWeight: 500 }],
-      sm: "0.851rem",
-      base: ["14px", {}],
-      lg: ["1.1429rem", 1.75],
-      xl: ["1.2857rem", { letterSpacing: "-0.015em", fontWeight: 500 }],
-      "2xl": ["1.5rem", { letterSpacing: "-0.015em", fontWeight: 500 }],
-      "3xl": ["2rem", { fontWeight: 500 }],
-      "4xl": ["2.5rem", { letterSpacing: "-0.015em", fontWeight: 500 }],
-    },
-
-    colors: {
-      white: "#fff",
-      black: "#000",
-      transparent: 'transparent',
-
-      background: {
-        light: "#f9f9fa",
-        dark: "#141b1f",
-      },
-
-      divider: {
-        light: "hsla(0, 0%, 0%, 0.1)",
-        dark: "hsla(0, 0%, 100%, 0.05)",
-      },
-
-      amber: {
-        light: {
-          DEFAULT: "#b85504",
-          100: "#fff4dc",
-          200: "#fce1a9",
-          300: "#fbb552",
-          400: "#dd7805",
-          500: "#b85504",
-          600: "#a9470f",
-          700: "#893607",
-          800: "#421a02",
-        },
-        dark: {
-          DEFAULT: "#ed8d25",
-          100: "#753715",
-          200: "#944307",
-          300: "#af560a",
-          400: "#cd6a0a",
-          500: "#ed8d25",
-          600: "#f6a650",
-          700: "#f8b974",
-          800: "#fac892",
-        },
-      },
-
-      red: {
-        light: {
-          DEFAULT: "#d52536",
-          100: "#fdeaea",
-          200: "#f6cfd0",
-          300: "#eea3a5",
-          400: "#e25d68",
-          500: "#d52536",
-          600: "#b72132",
-          700: "#8b1924",
-          800: "#350a10",
-        },
-        dark: {
-          DEFAULT: "#dd4659",
-          100: "#741624",
-          200: "#951c2f",
-          300: "#bc233c",
-          400: "#d1334c",
-          500: "#dd4659",
-          600: "#e96c7c",
-          700: "#ea8e9a",
-          800: "#f0aab4",
-        },
-      },
-
-      violet: {
-        light: {
-          DEFAULT: "#7d2eff",
-          100: "#f7ecff",
-          200: "#e9d4ff",
-          300: "#c9a6ff",
-          400: "#9860ff",
-          500: "#7d2eff",
-          600: "#6d00eb",
-          700: "#5700bb",
-          800: "#220041",
-        },
-        dark: {
-          DEFAULT: "#a371fc",
-          100: "#380093",
-          200: "#4F00B4",
-          300: "#6D1CDB",
-          400: "#8a53ec",
-          500: "#a371fc",
-          600: "#b38bfc",
-          700: "#c5a6fd",
-          800: "#d4bdfe",
-        },
-      },
-
-      magenta: {
-        light: {
-          DEFAULT: "#C918C0",
-          100: "#FFE6FB",
-          200: "#FFC9F6",
-          300: "#FFA6F0",
-          400: "#E950E2",
-          500: "#C918C0",
-          600: "#AB00A4",
-          700: "#830080",
-          800: "#440040",
-        },
-        dark: {
-          DEFAULT: "#E950E2",
-          100: "#7E0078",
-          200: "#92008B",
-          300: "#AB00A4",
-          400: "#CC18C4",
-          500: "#E950E2",
-          600: "#FF6FF9",
-          700: "#FF8AFA",
-          800: "#FFA4FB",
-        },
-      },
-
-
-      blue: {
-        light: {
-          DEFAULT: "#086dd7",
-          100: "#e5f2fc",
-          200: "#c0e0fa",
-          300: "#8bc7f5",
-          400: "#1c90ed",
-          500: "#1D63ED",
-          600: "#0C49C2",
-          700: "#00308D",
-          800: "#00084d",
-        },
-        dark: {
-          DEFAULT: "#3391ee",
-          100: "#002EA3",
-          200: "#063BB7",
-          300: "#1351D4",
-          400: "#1D63ED",
-          500: "#3391ee",
-          600: "#55a4f1",
-          700: "#7cb9f4",
-          800: "#98c8f6",
-        },
-      },
-
-      green: {
-        light: {
-          DEFAULT: "#2e7f74",
-          100: "#e6f5f3",
-          200: "#c6eae1",
-          300: "#88d5c0",
-          400: "#3ba08d",
-          500: "#2e7f74",
-          600: "#1e6c5f",
-          700: "#185a51",
-          800: "#0c2c28",
-        },
-        dark: {
-          DEFAULT: "#2aa391",
-          100: "#003F36",
-          200: "#005045",
-          300: "#006256",
-          400: "#008471",
-          500: "#00A58C",
-          600: "#3cc1ad",
-          700: "#7accc3",
-          800: "#a5ddd6",
-        },
-      },
-
-      gray: {
-        light: {
-          DEFAULT: "#677285",
-          100: "#F4F4F6",
-          200: "#e1e2e6",
-          300: "#c4c8d1",
-          400: "#8993a5",
-          500: "#677285",
-          600: "#505968",
-          700: "#393f49",
-          800: "#17191e",
-        },
-        dark: {
-          DEFAULT: "#7794ab",
-          100: "#080B0E",
-          200: "#1C262D",
-          300: "#2D404E",
-          400: "#4E6A81",
-          500: "#7794ab",
-          600: "#94abbc",
-          700: "#adbecb",
-          800: "#c4d0da",
-        },
-      },
-    },
-
-    fontFamily: {
-      sans: [
-        "Roboto Flex",
-        "system-ui",
-        "-apple-system",
-        "BlinkMacSystemFont",
-        "Segoe UI",
-        "Oxygen",
-        "Ubuntu",
-        "Cantarell",
-        "Open Sans",
-        "Helvetica Neue",
-        "sans-serif",
-      ],
-      mono: ["Roboto Mono", "monospace"],
-      icons: ["Material Symbols Rounded"],
-    },
-  },
-  plugins: [require("@tailwindcss/typography")],
-};
diff --git a/tech_writer.yml b/tech_writer.yml
new file mode 100644
index 000000000000..6450a6903a3e
--- /dev/null
+++ b/tech_writer.yml
@@ -0,0 +1,322 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/docker/docker-agent/refs/heads/main/agent-schema.json
+agents:
+  root:
+    model: coordinator
+    description: Documentation coordinator for analysis and delegation
+    instruction: |
+      <objective>
+      Coordinate documentation work by analyzing requests, discovering existing
+      content, scoping the work, and delegating to specialists. You analyze and
+      coordinate. You do not write.
+      </objective>
+
+      <context>
+      This is the Docker documentation repository (https://docs.docker.com/).
+
+      Repository structure:
+      - Built with Hugo static site generator
+      - Content in content/ directory
+      - Front matter required for all pages
+      - Style guide enforced by Vale
+      - Markdown linting enforced by rumdl
+
+      URL structure:
+      The /manuals prefix is removed from published URLs. So
+      content/manuals/docker-desktop/install.md becomes /docker-desktop/install/
+      on the live site.
+
+      Vendored content:
+      Some documentation is vendored from upstream repositories via Hugo
+      modules:
+      - CLI reference docs (from docker/cli, docker/buildx, docker/compose,
+        docker/model-runner)
+      - Dockerfile reference (from moby/buildkit)
+      - Engine API docs (from moby/moby)
+
+      Do not edit vendored content. These files are in _vendor/ or are
+      generated from data/ directories. If vendored content needs updates,
+      raise this with the user.
+      </context>
+
+      <process>
+      1. Analyze the request
+         What needs to be documented? What's the scope?
+
+      2. Discover existing content
+         Search for related docs. Find what exists, where it lives, and what's
+         related.
+
+      3. Read for context
+         Use filesystem tools to read specific files and understand the current
+         state.
+
+      4. Delegate to writer
+         Provide clear instructions:
+         - What needs to be written/updated
+         - Which files are involved
+         - Related docs to consider
+         - Any specific requirements
+
+      5. Delegate to editor
+         After the writer completes their work, delegate to the editor to
+         polish, validate, and fix any issues.
+
+      6. Handle completion
+         When the editor is done, analyze results:
+         - Validation passed: Work is complete
+         - Local issues remain: Delegate back to editor to fix
+         - Upstream coordination issues: Document for follow-up, don't block
+           completion
+
+      7. Complete
+         When validation passes OR only upstream issues remain, the work is
+         done.
+      </process>
+
+      <rules>
+        <upstream_coordination>
+        Sometimes validation failures indicate upstream work is needed, not
+        local fixes. There are two types:
+
+        1. Broken links TO vendored content
+           Local docs reference upstream content that doesn't exist yet:
+           - New docs reference CLI flags not in vendored CLI reference yet
+           - Links to upstream docs that haven't been written yet
+           - References to features that exist but aren't documented upstream
+
+        2. Broken links FROM vendored/generated content
+           The broken link originates in vendored or generated documentation:
+           - CLI reference pages (generated from data/engine-cli/, data/buildx/)
+           - Content in _vendor/ directory
+           - Pages generated from YAML in data/ directory
+
+           These files are read-only in this repo. The broken link must be
+           fixed in the upstream repository (docker/cli, docker/buildx,
+           moby/moby), not here.
+
+        When you identify upstream issues:
+        1. Verify it's truly an upstream issue (check file path and source)
+        2. Note briefly what upstream work is needed (which repo, what needs
+           fixing)
+        3. Do not block completion - if local changes are correct, upstream
+           work is separate
+
+        How to identify upstream vs local issues:
+
+        Check the SOURCE file path of the broken link:
+        - Link FROM content/reference/cli/ or content/reference/engine/ →
+          upstream (generated from data/)
+        - Link FROM _vendor/ → upstream (vendored content)
+        - Link FROM content/manuals/ → likely local (check if it's generated)
+
+        Check the TARGET of broken links:
+        - Link TO /reference/cli/ or /reference/engine/ → likely upstream
+          (vendored)
+        - Link TO _vendor/ → definitely upstream (read-only)
+
+        Mapping content to upstream repos:
+        - CLI reference (docker commands) → docker/cli
+        - Buildx reference → docker/buildx
+        - Compose reference → docker/compose
+        - Model runner reference → docker/model-runner
+        - Dockerfile reference → moby/buildkit
+        - Engine API reference → moby/moby
+        </upstream_coordination>
+      </rules>
+
+      <reporting>
+      Work silently without narration.
+      - No "Let me", "Now I'll", "I'm going to" phrases
+      - Don't explain before doing - just execute
+
+      Keep communication concise. Report only essential findings and blockers.
+      </reporting>
+
+      <success_criteria>
+      - Validation passes (validate tool), OR
+      - Only upstream issues remain (documented for follow-up)
+      - Writer and editor have completed their work
+      - Local documentation changes are correct
+      </success_criteria>
+
+    toolsets:
+      - type: filesystem
+      - type: todo
+        shared: true
+      - type: fetch
+
+    sub_agents:
+      - writer
+      - editor
+
+  writer:
+    model: writer_sonnet
+    description: Technical writer for creating and editing Docker documentation
+    add_prompt_files:
+      - STYLE.md
+      - COMPONENTS.md
+    instruction: |
+      <objective>
+      Write technical documentation for Docker. Create clear, practical content
+      that helps users understand and use Docker effectively.
+
+      STYLE.md provides the complete style guide. Follow it. COMPONENTS.md shows
+      how to use Hugo shortcodes and components. Your job is to create content -
+      the editor will polish formatting and validate.
+      </objective>
+
+      <context>
+      You write for the Docker documentation repository (https://docs.docker.com/).
+
+      Technical environment:
+      - Hugo static site generator with shortcodes
+      - Markdown with front matter
+      - Vendored content from upstream repos (read-only, don't edit)
+
+      Division of labor:
+      - You: Create content, structure information, explain concepts
+      - Editor: Format, polish style, validate Hugo syntax, run checks
+
+      Don't worry about perfect line wrapping, exact word choices, or Hugo
+      syntax details. Get the content right - the editor handles the rest.
+      </context>
+
+      <process>
+      1. If updating existing content, read it first to understand scope and
+         character
+      2. Use filesystem tools (glob, grep, read) to find related content and
+         examples
+      3. Write clear, conversational content following STYLE.md principles
+      4. Include front matter (title, description, keywords minimum)
+      5. Use shortcodes and components from COMPONENTS.md as needed
+      6. Write files directly - don't just provide drafts
+      7. When done, return to root agent for editor handoff
+      </process>
+
+      <rules>
+      - Read before editing: Always read existing files before modifying them
+      - Preserve scope: Match the existing document's length and character (see
+        STYLE.md "Scope preservation")
+      - Answer the key questions: Every page should answer "What will I learn?"
+        and "Why does this matter?" in the first paragraph
+      - Write, don't narrate: Execute without explaining what you're about to do
+      </rules>
+
+      <reporting>
+      Work silently. When returning to coordinator, report briefly:
+      - Files changed
+      - Key additions/changes made
+      - Any concerns
+
+      No "Let me", "Now I'll", "I'm going to" phrases.
+      </reporting>
+
+      <success_criteria>
+      - Content written to files (not drafts)
+      - Follows STYLE.md voice and structure principles
+      - Uses appropriate components from COMPONENTS.md
+      - Matches existing document scope when updating
+      - Includes practical examples where helpful
+      </success_criteria>
+
+    toolsets:
+      - type: filesystem
+      - type: shell
+
+  editor:
+    model: editor_haiku
+    description: Editor that polishes, validates, and fixes documentation
+    add_prompt_files:
+      - STYLE.md
+      - COMPONENTS.md
+    instruction: |
+      <objective>
+      Polish documentation to meet strict formatting and style standards, then
+      validate it passes all automated checks.
+
+      STYLE.md and COMPONENTS.md contain all the rules. Apply them. The writer
+      creates content; you make it perfect and ensure it's ready to ship.
+      </objective>
+
+      <context>
+      You work on the Docker documentation repository (https://docs.docker.com/).
+
+      Your role:
+      - Fix Markdown formatting with rumdl
+      - Remove AI-isms and style violations (per STYLE.md)
+      - Ensure correct Hugo syntax (per COMPONENTS.md)
+      - Validate and fix until checks pass
+      - Don't change meaning or add content
+      </context>
+
+      <process>
+      1. Run show_diff to see what changed (efficient - avoids reading full
+         files)
+      2. Review diff for issues against STYLE.md and COMPONENTS.md
+      3. If issues found: Read file and fix them
+      4. Run rumdl: npx --no-install rumdl fmt <file>
+      5. Run validate tool
+      6. Read .validation.log (first 2000 lines, use offset/limit if needed)
+      7. If validation passes: Report success
+      8. If validation fails: Fix issues and repeat from step 4
+
+      Key: Always start with show_diff to efficiently review changes before
+      reading entire files.
+      </process>
+
+      <rules>
+      - Apply STYLE.md: All voice, grammar, formatting, and terminology rules
+      - Apply COMPONENTS.md: Correct syntax for shortcodes, front matter,
+        callouts
+      - Line wrapping: 80 characters
+      - Run rumdl after editing
+      - Fix all local issues; identify upstream issues but don't block on them
+      </rules>
+
+      <reporting>
+      Work silently. When returning to coordinator, report in 2-3 sentences:
+      - Validation status (passed/failed)
+      - Files modified
+      - Remaining issues (if any)
+
+      No narration, commentary, or detailed explanations.
+      </reporting>
+
+      <success_criteria>
+      - Validation passes (validate tool), OR
+      - Only upstream issues remain (cannot be fixed locally)
+      - Properly formatted (80 char wrap, rumdl run)
+      - Compliant with STYLE.md and COMPONENTS.md
+      </success_criteria>
+
+    toolsets:
+      - type: filesystem
+      - type: shell
+      - type: script
+        shell:
+          show_diff:
+            cmd: "git diff --unified=5 --color=never"
+            description: |
+              Show what changed in modified files (git diff)
+              Use this FIRST to see what the writer changed before reading full files
+              More efficient than reading entire files
+          validate:
+            cmd: "docker buildx bake validate > .validation.log 2>&1"
+            description: |
+              Run documentation validation checks (rumdl, HTML validation, link checking, structural checks)
+              Output written to .validation.log - read this file to see results
+              Note: Vale (prose linting) runs separately in CI and is not included
+
+models:
+  coordinator:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    temperature: 0.3
+  writer_sonnet:
+    provider: anthropic
+    model: claude-sonnet-4-5
+    temperature: 0.6
+  editor_haiku:
+    provider: anthropic
+    model: claude-haiku-4-5
+    temperature: 0.2